Saryong Kang Senior Developer Relations Engineer @ Google Japan Google의 개발문화와 프로세스(2)

Disclaimer ● 기본적으로 공개된 내용에 기초하고 있지만, 해석은 어디까지나 개인 의견입니다. ● 아무리 성공 사례라고 해도 도입의 이유는, ○ "구글이 한다니까" ‍♂ ○ "나 or 우리 조직에 필요하고 AND 적합하니까" ‍♂

Disclaimer 2 ● Google은 Culture 문서에서 feedback의 중요성을 명시적으로 언급하고 언급하고 있지는 않음 ● Feedback 문화 자체에 대해서는 Netflix, McKinsey와 같은 조직을 참고하는 것을 추천 ○ eg. "규칙 없음” by 리드 헤이스팅스, 에린 마이어 https://ridibooks.com/books/510001020

I. 서론: Google 면접에서 떨어진 후, 더 가고 싶어진 이야기

성장에 대한 고민 ● 개발을 손 떼면서 반대로 보이게 된 것 ○ 주니어→시니어로의 성장은 저절로 되지 않는다 ○ When the Advanced Beginner doesn’t care enough to interact with the broader community and for whatever reason doesn’t have much interaction with peers, ...

Expert Beginner ● 성장 vs 자존감에서 후자에 더 무게중심 ○ 부정적 feedback에 지나치게 거부 반응 ○ Low hanging fruit에 집착 ○ “난 이미 알 건 다 알아” ● 참고: ○ [번역]더 이상 배우려 하지 않는 개발자 : Expert Beginner의 등장 ○ [번역]소프트웨어 집단의 부패:Expert Beginner의 유산

Google 인터뷰를 받으면서 배운 점 ● 나보다 훨씬 훌륭한 엔지니어들도 합격이 잘 안 되는 이유: ○ 단순히 개발만 잘 하는 사람을 원하지 않는다. 대신..

II. Google의 feedback 문화

Google의 피드백 문화 - lead by example ● Google에서는 “업무 지시”, 혹은 “필수 교육”이라고 하는 개념이 거의 없음. ● 리더는 “나의 충고는..." 같은 어법을 절대로 쓰지 않음 ○ 대신 리더는 항상 피드백에 열려있음

Google tgif (and more!) ● 매주 목요일 CEO가 사원들의 질문에 대답 ○ 예의를 차리지 않고 하는 예리한 질문이 많으나, 고맙게 받아들이고 성의있게 답변 ● 모든 부문/부서별로 매달 혹은 매분기 당 같은 이벤트가 있음 → 모든 리더들은 부서원들의 어떤 질문과 피드백에도 마음이 열려있음 ● Googlegeist - 전 직원의 기탄 없는 의견을 수집, 전략에 반영

그로 인한 낙수 효과 ● 자연스럽게 서로 솔직한 피드백을 주고 받는 문화가 있음 ● 인사평가도 360도 실명 평가

문화적인 차이 ● High-context vs low-context → Generous high를 지향: 솔직한 존중

피드백의 기술 Start by stating the purpose of the feedback session “I want to have a discussion about…” ; “I wanted to share some thoughts on…” ; “I wanted us to together evaluate…” Give feedback on strengths FACTS State the facts: “I have observed that…” ; “The report that you prepared was…” ; “The initiative that you undertook...”; “You did a great job at…” +Illustrate why it was good IMPACT State what effect it had, e.g., you felt inspired, motivated, clients were happy, stakeholders were appreciative: “It made me feel…” ; “This resulted in…”: “The feedback we got on this was…” RECOMMENDATION Reinforce the positive behavior: “I recommend you to continue doing… / do more of this… / build on this strength...” ; “Could you coach me/the team on…” Give feedback on development areas FACTS State the facts: “On the other hand, there are a few areas that I feel you could consider working on. I have observed that…” ; “During the meeting I noticed that…” ; “However, while working together I observed that” IMPACT State what effect it had, e.g., you felt intimidated, confused, clients were unhappy, stakeholders were dissatisfied: “It made me feel…” ; “This resulted in…”: “The feedback we got on this was…” RECOMMENDATION Make a recommendation going forward: “My recommendation to you is…” ; “In order to address this I suggest you…” ; “You might find it helpful to try doing…” ; “In future you might want to avoid...” Pause; Listener to acknowledge and ask any clarifying questions if any Thank the person (applies to both)

개인적인 경험 ● 새로운 시도, but.. ○ My manager of manager wasn’t happy about that and didn’t bless me. ● 평생 경험한 적 없는 일 - 1주일 뒤, 10분간, 놀라울 정도로 구체적으로 사과 받다!

열렬한(?) 칭찬 문화 ● Remarkable한 성과를 보면 반드시 칭찬함 ○ 하지만 sandwich를 위한 의례적 칭찬은 지양 - 상대가 잘한 점, 고칠 점을 정확히 알 수 있도록 ● Peer bonus ○ 받으면 월급에 추가됨, 그리고..

III. Google의 Code Review (문제 해결 위주로)

용어 설명 ● 개발자 ● 리뷰어: 주로 해당 코드의 Owner(코드의 원작자, 혹은 같은 팀 담당자) 중 하나가 담당 ● 코드베이스 == 코드 리포지토리 ● 변경/추가된 새로운 코드들 == PR == MR == CL

Problem: 심리적인 저항 ● 리뷰어가 남이 자기가 짠 부분을 바꾸는 것에 지나치게 민감 ● 코드 리뷰의 Standard 1: ○ 개발자는 반드시 코드를 발전시켜야 한다. ○ 코드베이스에 아무 개선사항을 올리지 않는다면 코드베이스도 나아지지 않는다. ○ 리뷰어가 기존 코드에 대한 변경에 너무 까다롭게 대하면, 개발자가 향후 코드를 개선해갈 의지를 잃는다.

Google의 Owner 개념 ● 구글은 Owner 개념이 다름 ○ 무엇보다 작성자는 Googley 해야함: 초기 구현 시의 높은 책임! (특히 테스트) ○ 대신, 한 번 짜고 나면, Owner는 자기가 짠 코드에 대한 Review 책임만을 가짐. (예외: beyonce rule, 긴급 사태) ○ 기능 변경, 버그 수정이 요구될 경우, Owner 대신 해당 수정이 필요한 사람이 수정하는 것을 적극 권장

P: 일정에 밀려 낮은 품질 코드를 승인하고자 하는 유혹을 받음 ● 코드 리뷰의 Standard 2 ○ 리뷰어는 전체적인 코드 품질이 낮아지지 않도록 할 책임이 있다 ● 코드 리뷰의 Standard 3 ○ 리뷰어는 자기가 리뷰한 코드에 대해 ownership과 책임을 가진다 ○ 그러므로 코드베이스의 품질이 충분한 지 꼼꼼히 봐야한다

일반적으로, 리뷰어는 코드가 완벽하지 않더라도, 전체적인 코드 품질을 증가시키는 상태까지 도달했다면, 이를 승인해주는 방향으로 생각해야 한다.

Google 코드 리뷰의 Standard ● Key Point: 세상에 완벽한(perfect) 코드는 없다. 더 나은(better) 코드가 있을 뿐 ● 리뷰어는 승인의 전제로 개발자가 코드의 아주 세부사항까지 깔끔하게 만들 것을 요구하면 안 된다. ● 중요한 것은 지속적인 개선을 목표로 하는 것 ● 대체로 시스템의 유지보수성, 가독성을 높이고 있다면, "완벽하지 않다”는 이유로 승인을 몇 일 이상 끌어선 안 됨

P: 지적을 주고 받는 가운데 감정적이 되는 경우가 종종 있음 ● 상호 존중 / 논리적인 이유 설명 / 대안 제시 ○ ‍♂ 병행(concurrency)으로 수행해도 큰 이점이 없는데 왜 쓰레드를 쓰셨어요? ○ ‍♂ 여기에서는 병렬 구조로 인한 복잡성 대비 성능상 이점이 보이지 않네요. 성능에 크게 차이가 없으니 해당 코드는 단일 쓰레드에서 실행하는게 최선인 것 같습니다. ● 충돌이 생길 경우, 만나서 대화를 통해 해결하는 것을 강력 추천

P: 코드 리뷰 적체 현상 ● Speed vs Interruption ○ 리뷰어는, 몰입 상태가 아니라면 즉시 리뷰한다. ○ 최악의 사태에도 업무일 기준 하루는 넘기지 않는다. ○ 신청 → 승인까지 걸리는 시간이 짧은 것보다, 리뷰 메시지가 빨리 오가는 것이 중요

IV. Google의 코드 리뷰 Best Practice

Best Practices ● Be polite and Professional ○ 사람이 나쁜 게 아니라 코드가 나쁜 것

Best Practices ● Write Small Changes ○ 하나의 PR에는 하나의 독립적인 변화만 있어야 한다! ○ 왜? ■ 리뷰가 빠르다. 더 빈틈없는 리뷰를 받을 수 있다. 버그가 발생할 가능성이 적다. 거절됐을 때 낭비되는 시간이 적다. 코드를 머지하기 쉽다. 제대로 설계하기 용이하다. 리뷰에 의존하지 않고 다른 작업을 하고 있을 수 있다. 문제가 생겼을 때 되돌리기 쉽다. ○ 대략 100 line 정도가 좋음. 1,000 line은 너무 큼 (Java / C++ 기준)

Best Practices ● Write Good Change Descriptions ○ 좋은 설명문은 PR이 무얼 하고 있는지 첫 줄에 설명한다. ○ 본문에는 어떤 문제를 해결하는지, 왜 이렇게 해결했는지, 그리고 코드에 대한 설명도 있고 해당 PR에 대한 배경 설명과 추후 발전 방향이 포함될 수도 있다.

Best Practices ● Keep Reviewers to a Minimum

Best Practices ● Automate Where Possible ○ lint를 적극 활용! ○ 사소한 스타일에 대한 것들은 custom lint rule로 정의

여기까지 모든 코드리뷰 관련 내용은 여기에서.. ● Code Review Developer Guide ○ https://google.github.io/eng-practices/review/ ○ 한글 번역 by 노수진 님: https://soojin.ro/blog/google-code-review-guide

Thank You https://speakerdeck.com/saryong