[소트프웨어 엔지니어링] Software Engineering at Google 읽고 기록 _ Chapter 3

Software Engineering at Google

Curated by Titus Winters, Tom Manshreck & Hyrum Wright

 

7.

 

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Challenges to Learning

 

Sharing expertise across an organization is not an easy task. Without a strong culture of learning, challenges can emerge. Google has experienced a number of these challenges, especially as the company has scaled:

 

조직에 전문 지식을 공유하는 것은 쉬운 작업이 아닙니다. 배움에 대한 강력한 문화가 없으면 문제가 발생할 수 있죠. 회사가 확장됨에 따라서 구글은 다음과 같은 많은 문제들을 경험해왔습니다.

 

 

Lack of psychological safety
An environment in which people are afraid to take risks or make mistakes in front of others because they fear being punished for it. This often manifests as a culture of fear or a tendency to avoid transparency.

 

심리적 안정감의 부족

처벌받을 것 때문에 사람들이 위험을 감수하거나 사람들 앞에서 실수하는 것을 두려워하는 환경입니다. 종종 공포 문화나 투명성을 피하는 경향으로 나타납니다.

 

Information islands
Knowledge fragmentation that occurs in different parts of an organization that don’t communicate with one another or use shared resources. In such an environment, each group develops its own way of doing things. This often leads to the following:

    Information fragmentation
Each island has an incomplete picture of the bigger whole.

    Information duplication
Each island has reinvented its own way of doing something.

    Information skew
Each island has its own ways of doing the same thing, and these might or might not conflict.

 

정보 섬들

서로 소통하지 않거나 공유 자원들을 사용하지 않는 조직의 다른 부서들간에 발생하는 지식 파편화입니다. 이러한 환경에서 각 그룹은 작업을 수행하는 고유한 방법을 개발합니다. 정보 파편화는 다음의 상황들로 종종 이어집니다.

 

    정보 파편화

각 섬은 더 큰 전체에 대한 불완전한 그림을 가집니다.

 

    정보 중복

각 섬은 작업을 수행하는 고유한 방법들을 다시 찾아냅니다.

 

    정보 비대칭

각 섬은 같은 작업을 수행하는 고유한 방법들을 가지고, 이 방법들은 서로 충돌하거나 충돌하지 않을 수 있습니다.

 

Single point of failure (SPOF)
A bottleneck that occurs when critical information is available from only a single person. This is related to bus factor, which is discussed in more detail in Chapter 2.
SPOFs can arise out of good intentions: it can be easy to fall into a habit of “Let me take care of that for you.” But this approach optimizes for short-term efficiency (“It’s faster for me to do it”) at the cost of poor long-term scalability (the team never learns how to do whatever it is that needs to be done). This mindset also tends to lead to all-or-nothing expertise.

 

단일 실패 지점

오직 한 사람만이 중요한 정보를 사용할 수 있을 때 나타나는 병목현상입니다. 챕터 2에서 더 자세하게 논의된 버스 요인과 관련이 있죠.

단일 실패 지점은 좋은 의도에서 생겼을 수 있습니다. "내가 당신을 위해 처리할게요."라는 습관에 빠지기 쉽죠. 그러나 이러한 접근 방법은 단기적인 효율성("그건 내가 하는 게 더 빠르지")를 최적화하고 장기적인 확장성(팀은 해야될 일이 무엇이든 간에 그 방법을 결코 배우지 않습니다. )은 형편없어지는 대가를 치릅니다. 이러한 사고방식은 또한 전부-또는-전무한 전문 지식 상황으로 이어지곤 합니다.

 

All-or-nothing expertise
A group of people that is split between people who know “everything” and novices, with little middle ground. This problem often reinforces itself if experts always do everything themselves and don’t take the time to develop new experts through mentoring or documentation. In this scenario, knowledge and responsibilities continue to accumulate on those who already have expertise, and new team members or novices are left to fend for themselves and ramp up more slowly.

 

전부-또는-전무한 전문 지식

"모든 것"을 아는 사람과 초보자들로 나뉘는, 중간 지점이 거의 없는 사람들의 그룹입니다. 전문가들이 항상 스스로 모든 것을 하고, 모니터링이나 문서를 통해 새로운 전문가를 개발하는데 시간을 쓰지 않는다면 이러한 문제는 종종 자체적으로 강화됩니다. 이러한 시나리오에서  지식과 책임감은 이미 지식을 가진 사람들에게 계속해서 모이고, 새로운 팀원들과 초보자들은 스스로 고투하며 더 천천히 성장하도록 남겨집니다.

 

Parroting
Mimicry without understanding. This is typically characterized by mindlessly copying patterns or code without understanding their purpose, often under the assumption that said code is needed for unknown reasons.

 

앵무새처럼 모방하기

이해하지 못하고 모방합니다. 일반적으로 알 수 없는 이유들로 인해 필요한 코드라는 가정하에 종종, 목적을 이해하지 못한채 패턴이나 코드를 무심코 복사하는 특징이 있습니다.

 

Haunted graveyards
Places, often in code, that people avoid touching or changing because they are afraid that something might go wrong. Unlike the aforementioned parroting, haunted graveyards are characterized by people avoiding action because of fear and superstition.

 

유령이 출몰하는 묘지

사람들이 무언가 잘못되는게 두려워서 만지거나 변경하는 것을 피하는, 종종 코드 안에서의 지점입니다. 앞서 언급한 앵무새처럼 모방하기와는 다르게, 유령이 출몰하는 묘지들은 이러한 두려움과 미신으로 인해 사람들이 행동하는 것을 피하는 것이 특징입니다.

 

 

8.

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Philosophy

 

Software engineering can be defined as the multiperson development of multiversion programs. People are at the core of software engineering: code is an important output but only a small part of building a product. Crucially, code does not emerge spontaneously out of nothing, and neither does expertise. Every expert was once a novice: an organization’s success depends on growing and investing in its people.

 

소프트웨어 공학은 여러 버전의 프로그램들을 여러 사람들이 개발하는 것으로 정의할 수 있습니다. 사람들은 소프트웨어 공학의 핵심입니다. 코드는 중요한 결과물이기는 하나 생산물을 이루는 작은 부분일 뿐입니다. 결정적으로, 코드는 무에서 유로 저절로 생기는 것이 아니고, 전문지식도 그러합니다. 모든 전문가들은 한 때 초보자였습니다. 조직의 성공은  사람들을 기르고 투자하는 것에 달려있습니다.

 

Tribal and written knowledge complement each other. Even a perfectly expert team with perfect documentation needs to communicate with one another, coordinate with other teams, and adapt their strategies over time. No single knowledge-sharing approach is the correct solution for all types of learning, and the particulars of a good mix will likely vary based on your organization. Institutional knowledge evolves over time, and the knowledge-sharing methods that work best for your organization will likely change as it grows. Train, focus on learning and growth, and build your own stable of experts: there is no such thing as too much engineering expertise.

 

전문가 집단과 문서화된 지식은 서로를 보완합니다. 완벽한 문서를 가진 완벽한 전문가 팀일지라도 서로 소통하고 다른 팀과 조정하며 시간이 지남에 따라 전략을 보완해야 합니다. 모든 학습 유형에 관한 한 가지의 지식 공유 방식(전문가에게만 지식 전달, 또는 문서상으로만 지식 전달)은 옳은 해결책이 아니고, 좋은 혼합 방식(전문가와 문서로 지식 공유)의 세부사항은 조직에 따라 다양할 수 있습니다. 조직의 지식은 시간이 지남에 따라 발전하고, 조직에 가장 적합한 지식 공유 방법은 조직이 성장함에 따라 달라질 수 있습니다. 훈련하고, 배움과 성장에 집중하고, 당신만의 전문가 그룹을 세우세요. 너무 과하게 많은 엔지니어링 전문 지식 같은 건 없습니다.

 

 

9.

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Setting the Stage: Psychological Safety

 

Psychological safety is critical to promoting a learning environment.

 

심리적인 안정감은 학습 환경을 조성하는데 중요합니다.

 

An enormous part of learning is being able to try things and feeling safe to fail. In a healthy environment, people feel comfortable asking questions, being wrong, and learning new things. This is a baseline expectation for all Google teams; indeed, our research has shown that psychological safety is the most important part of an effective team.

 

배움의 아주 큰 부분은 무언가를 시도해도 되고, 실패해도 안전하다고 느끼는 것입니다. 건강한 환경에서 사람들은 질문하고, 틀려도 보고, 새로운 것들을 배우는 것에 편안함을 느낍니다. 이것은 모든 구글 팀들의 기본적인 기대치입니다. 실제로, 우리의 결과는 심리적인 안정감이 효율적인 팀의 가장 중요한 부분이라는 것을 보여줍니다.

 

10

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Setting the Stage: Psychological Safety / Mentorship

 

At Google, we try to set the tone as soon as a “Noogler” (new Googler) engineer joins the company. One important way of building psychological safety is to assign Nooglers a mentor—someone who is not their team member, manager, or tech lead—whose responsibilities explicitly include answering questions and helping the Noogler
ramp up. Having an officially assigned mentor to ask for help makes it easier for the newcomer and means that they don’t need to worry about taking up too much of their coworkers’ time.

 

구글에서 우리는 누글러(Noogler, 새로운 구글 직원) 엔지니어가 회사에 가능한 빨리 참여하도록 분위기를 조성하려고 노력합니다. 심리적 안정감을 만드는 중요한 하나의 방법은 누글러에게 멘토(누글러의 팀 멤버, 매니저, 기술 리더가 아닌 사람으로 말이죠)를 지정하는 것입니다. 멘토는 질문에 답하고 누글러를 돕는 명시적인 확실한 책임을 가지고 있습니다. 질문하기 위해 공식적으로 지정된 멘토가 있는 것은 신규 입사자가 더 쉽게 질문하도록 돕고 신규입사자들이 동료들의 시간을 너무 빼았는 것이 아닌가 라는 걱정을 할 필요없도록 합니다.

 

Mentorship formalizes and facilitates learning, but learning itself is an ongoing process. There will always be opportunities for coworkers to learn from one another, whether it’s a new employee joining the organization or an experienced engineer learning a new technology. With a healthy team, teammates will be open not just to answering but also to asking questions: showing that they don’t know something and learning from one another.

 

 멘토링은 배움을 공식화하고 가능하게 하지만, 배움 자체는 지속적인 과정입니다. 항상 동료들이 서로에게  배우는 기회들이 있을 겁니다. 새로운 직원이 입사하거나 숙련된 엔지티너가 새로운 기술을 배우든지 간 말입니다. 건강한 팀과 함께 팀원들은 답변하는 것뿐만이 아니라 질문하는 것에도 열려 있을 겁니다. 자신들이 모르는 것을 보여주고, 서로에게 배우는 거죠.

 

11

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Setting the Stage: Psychological Safety / Psychological Safety in Large Groups

 

Table 3-1. Group interaction patterns 조직 상호작용 패턴들

Recommended patterns (cooperative) 권장 패턴들(협력적)	Antipatterns (adversarial) 반대 패턴 (적대적)
Basic questions or mistakes are guided in the proper direction 기본적인 질문이나 실수는 적절한 방향으로 안내됩니다.	Basic questions or mistakes are picked on, and the person asking the question is chastised 기본적인 질문이나 실수를 고르고 그 질문을 하는 사람을 꾸중합니다.
Explanations are given with the intent of helping the person asking the question learn 설명은 질문을 하는 사람의 학습을 돕기위한 목적으로 제공됩니다.	Explanations are given with the intent of showing off one’s own knowledge 설명이 자신의 지식을 자랑하는 목적으로 제공됩니다.
Responses are kind, patient, and helpful 친절하고 인내심있으며 도움이 되는 반응/답변을 합니다.	Responses are condescending, snarky, and unconstructive 잘난 체하고 짜증내며 건설적이지 않은 반응/답변을 합니다.
Interactions are shared discussions for finding solutions 해결책을 찾기 위해 의견을 공유하는 상호작용을 합니다.	Interactions are arguments with “winners” and “losers” "승자"와 "패자"가 논쟁하는 상호작용을 합니다.

These antipatterns can emerge unintentionally: someone might be trying to be helpful but is accidentally condescending and unwelcoming. We find the Recurse Center’s social rules to be helpful here:

No feigned surprise (“What?! I can’t believe you don’t know what the stack is!”)
Feigned surprise is a barrier to psychological safety and makes members of the group afraid of admitting to a lack of knowledge.

No “well-actuallys”
Pedantic corrections that tend to be about grandstanding rather than precision.

No back-seat driving
Interrupting an existing discussion to offer opinions without committing to the conversation

No subtle “-isms” (“It’s so easy my grandmother could do it!”)
Small expressions of bias (racism, ageism, homophobia) that can make individuals feel unwelcome, disrespected, or unsafe.

 

이러한 반대 패턴들은 의도하지 않게 나타날 수 있습니다. 누군가가 도움이지 되고자 노력했으나 뜻하지않게 잘난체하고 달가워하지 않을 수 있습니다. Recurse 센터의 사회적 규칙들이 여기에 도움이 되는 것을 알았습니다.

 

놀라는 척하지 마세요("뭐?! 스택이 뭔지 모르다니!")

놀라는 척은 심리적 안정감에 장벽이 되고, 그 조직의 일원들이 지식의 부족을 인정하는 것을 두려워하게 합니다.

 

"음, 실제로는 말이지" 금지

학식이 깊어 보이기 위한 정정은 정확성보다는 과시하기 위한 의도로 사용됩니다. 

 

뒷자리에서 운전 금지

대화에 참여하지 않으면서 의견만을 제시하기 위해 기존 토론을 중단시키는 것입니다.

 

미묘한 "-즘" 금지("이건 우리 할머니가 하실 수 있을 정도 쉬운데!")

개인이 불편하고 존중받지 못하거나 불안함을 느끼게 하는 (인종, 나이, 동성애 등의)편견이 담긴 짧은 표현들입니다.

 

 

12

 

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Setting the Stage: Psychological Safety / Growing Your Knowledge / Ask Questions

 

It doesn’t matter whether you’re new to a team or a senior leader: you should always be in an environment in which there’s something to learn. If not, you stagnate (and should find a new environment).

 

당신이 팀의 새로운 사람이든, 시니어 리더이든 상관없이, 당신은 항상 무언가를 배울 환경에 있어야 합니다. 그렇지 않다면 정체됩니다. (그리고 새로운 환경을 찾아야 합니다.)

 

It’s especially critical for those in leadership roles to model this behavior: it’s important not to mistakenly equate “seniority” with “knowing everything.” In fact, the more you know, the more you know you don’t know. Openly asking questions  or expressing gaps in knowledge reinforces that it’s OK for others to do the same.

 

지도자 역할을 하는 사람들이 이러한 행동을 본보기로 보여주는 것이 중요합니다. "상급자임"이 "모든 것을 다 안다"라고 잘못되게 동일시 하지 않는 것이 중요합니다. 사실, 더 많이 알수록 모르는 게 더 많아집니다. 공개적으로 질문을 하거나 지식의 격차를 드러내는 것은 다른 사람들도 똑같이 하도록 합니다.

 

On the receiving end, patience and kindness when answering questions fosters an environment in which people feel safe looking for help. Making it easier to overcome the initial hesitation to ask a question sets the tone early: reach out to solicit questions, and make it easy for even “trivial” questions to get an answer. Although engineers could probably figure out tribal knowledge on their own, they’re not here to work in a vacuum. Targeted help allows engineers to be productive faster, which in turn makes their entire team more productive.

 

질문을 받는 쪽에서는 말이죠, 질문에 답할 때의 인내심과 친절함이 사람들이 도움을 요청할 때 편안함을 느끼는 환경을 만듭니다. 질문하는 데 처음의 주저함을 쉽게 극복하게 하면 분위기가 일찍 조성됩니다. 질문을 얻기 위해 손을 내밀고, "사소한" 질문들 조차 답을 쉽게 얻도록 합니다. 엔지니어들이 아미 스스로 쉽게 알아낼 수 있는 사소한 지식일지라도, 그들은 아무 것도 없는 진공상태에서 일하려고 여기 있는 것이 아닙니다. 목표로 삼은 도움은 엔지니어들의 생산성을 더 빠르게 높이고, 결과적으로 팀 전체의 생산성을 증진시킵니다.

 

13

 

위치 : PART II Culture / Chapter 3: Knowledge Sharing / Setting the Stage: Psychological Safety / Growing Your Knowledge / Understand Context

 

Consider the principle of “Chesterson’s fence”: before removing or changing something, first understand why it’s there.

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

"체스톤의 울타리" 원칙을 고려합시다. 무언가를 제거하거나 바꾸기 전에, 왜 이것이 거기 있는지 먼저 이해하는 것입니다.

 

무언가 개혁하는 문제에 있어서, 변형시키는 것과는 다르게, 한 가지 분명하고 단순한 원리가 있습니다. 아마 역설이라고 불릴 원칙입니다. 특정 기관이나 법에 그러한 경우가 존재하는데요, 간단하게 길을 가로질러서 울타리나 문이 세워져있다고 해봅시다. 더 현대적인 개혁가는 유쾌하게 다가가서 "이것의 용도를 모르겠네요. 치워버리죠."라고 말합니다. 더 지적인 개혁가는 다음과 같이 답할 겁니다 "용도를 모르겠다면, 이것을 치워버리라고 말할 수가 없습니다. 가서 생각하세요. 그리고, 다시 돌아와서 내게 이것의 용도를 말해줄 수 있을 때에 이것의 파괴를 허용합니다."

 

Seek out and understand context, especially for decisions that seem unusual. After you’ve understood the context and purpose of the code, consider whether your change still makes sense. If it does, go ahead and make it; if it doesn’t, document your reasoning for future readers.

 

특히 비정상적인 결정들에 대해서 맥락을 찾아서 이해하세요. 그 맥락과 코드의 목적을 이해한 후에, 당신의 수정사항이 여전히 의미가 있는지 생각하세요. 의미가 있다면 계속 진행하시고 수정하세요. 그렇지 않다면, 미래의 독자들을 위해 당신의 추론을 문서화하세요.