TOC
- 참고
- 들어가며
- 배움을 가로막는 장애물
- 철학
- 판 깔아주기: 심리적 안전
- 내 지식 키우기
- 질문 확장하기: 커뮤니티에 묻기
- 지식 확장하기: 누구나 가르칠 게 있다
- 조직의 지식 확장하기
- 가독성 제도: 코드 리뷰를 통한 표준 멘토 제도
- 마치며
참고
본 내용은 구글 엔지니어는 이렇게 일한다(링크)를 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.
들어가며
- 조직은 자신의 문제 대부분에 스스로 답할 수 있어야 한다.
- 조직에 배움의 문화가 자리 잡혀야 한다.
- 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다.
배움을 가로막는 장애물
구글은 규모가 커지면서 이런 문제들을 겪었다.
심리적 안전 부족(lack of psychological safety)
- 불이익이 두려워서 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경
정보 섬(information islands)
- 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화된다.
- 정보 파편화: 섬마다 서로 다른 그림을 그리고 그마저도 불완전하다.
- 정보 중복: 섬마다 나름의 작업 방식을 재창조한다.
- 정보 왜곡: 같은 일이라도 섬마다 작업 방식이 다르고, 심지어 충돌하기도 한다.
단일 장애점(single point of failure, SPOF)
- 중요한 정보를 한 사람이 독점하면 병목이 생긴다.
전부 아니면 전무 전문성(all-or-nothing expertise)
- 조직 구성원이 '모든 것을 아는' 사람과 '아무것도 모르는' 초심자로 나뉜다.
- 지식과 책임은 계속 이미 전문가가 된 사람들에게 집중된다.
- 새로운 팀원이나 초심자들은 그들만의 울타리에 갇혀 느리게 성장하게 된다.
앵무새처럼 흉내내기(parroting)
- 이해하지 못한 상태로 흉내만 내는 것
- 목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라한다.
유령의 묘지(haunted graveyard)
- 무언가 잘못될 게 두려워서 아무도 손대지 않는 영역
- 두려움과 비합리적인 의심 때문에 사람들이 손대기를 기피하는 영역
철학
-
소프트웨어 엔지니어링에서 가장 중요한 요소는 사람
-
그 어떤 전문가도 한때는 초심자였다.
-
조직의 성패는 인력에 얼마나 투자해서 얼마나 잘 키워내느냐에 달려 있다.
-
전문가의 일대일 조언
- 개개인이 특정 분야에서 최고의 조언자가 될 수 있다.
- 전문가 개인이 부재중일 경우 어려움이 있을 수 있다.
-
문서화된 지식
- 많은 사람들이 참여하여 자신들의 전문성을 더 큰 그룹과 공유할 수 있다.
- 대부분 일반적인 상황을 다루므로 개별 학습자의 특수 상황에서는 부적합하다.
-
현장 지식(contextual knowledge)
- 위의 두 개념의 절충적 개념
- 팀원 개개인의 지식과 문서화된 정보 중간 어딘가에 존재
- 문서화된 지식과 상호 보완
판 깔아주기: 심리적 안전
-
심리적 안전은 학습 환경을 조성하는 데 매우 중요.
-
타인의 무지를 탓하지 말고 그 솔직함을 반겨야 한다.
-
배움에는 '무언가를 시도하다가 실패해도 안전하다'는 인식이 엄청나게 중요
-
건강한 환경에서라면 사람들은 질문을 던지고. 틀리고. 새로운 지식을 얻는 걸 편안하게 생각한다.
멘토 제도
- 구글에서 멘토의 공식 역할은 궁금한 점에 답해주고 신입의 성장을 돕는 것
- 신입이 속한 팀의 팀원이나 관리자 혹은 테크 리드는 멘토에서 제외
- 동료나 상사의 시간을 뺏는 건 아닐지 걱정하는 마음을 덜 수 있다.
큰 그룹에서의 심리적 안전
- 그룹의 모든 구성원이 안전한 환경을 만들고 유지하는 역할을 함께 해줘야 한다.
- 신규 입사자는 부담 없이 질문할 수 있게 해준다.
- 성장 중인 전문가는 기존 전문가들이 자신의 답변에서 허점을 찾아 공격할지 모른다는 두려움 없이 도움의 손길을 내밀 수 있다.
- 안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화
사회적 규칙에 도움이 될 규칙
거짓된 놀람 금지
"뭐라고?! 스택이 뭔지 모른다니 믿을 수가 없네!"
- 거짓된 놀람은 심리적 안전을 방해
- 모른다는 사실을 인정하기 두렵게 된다.
"음, 실제로는..." 금지
지나칠 정도로 세세하게 고쳐주는 행위는 정밀성보다는 자신을 뽐내려는 무의식에 기인하는 경향이 있다.
뒷자석 운전 금지
토론 중에 적절한 발언권 없이 끼어들어 의견을 제시하지 말라.
미묘한 '-주의' 금지
"이건 우리 할머니도 할 수 있겠네!"
인종주의, 연령주의, 동성애 혐오 발언 같이 편견이 깃든 표현은 다른 이에게 불편함과 무례함, 불안함을 느끼게 한다.
내 지식 키우기
- 지식 공유는 여러분으로부터 시작한다. 항상 무언가 배울 게 있음을 인식하는 게 중요하다.
- 자신의 지식을 강화하는 데 도움되는 지침 두 가지를 알아보자.
질문하기
"항상 배우고 항상 질문하라!"
- 질문하라. 여러분의 동료가 가장 훌륭한 정보 소스일 경우가 많다. 낮은 수준의 질문이라며 지레 겁 먹거나, 혼자 해결하려 들지 마라.
- 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들여라.
맥락 이해하기
- 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함
- 체스터슨의 울타리 원칙: "무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자"
- 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해야 한다.
- 코드의 목적과 맥락을 이해하고, 그런 다음 변경하려는 방향이 여전히 더 나은지 고민해야 한다.
질문 확장하기: 커뮤니티에 묻기
- 무언가를 일 대일로 배울 때는 '기록하는 습관'을 길러라.
- 더 큰 커뮤니티에 도움을 청하는 것도 좋다.
- 커뮤니티의 전문가에게 도움을 받을 수 있고, 기록되어 미래 구성원들에게까지 폭넓게 공유된다.
그룹 채팅
- 누구에게 물어봐야 할 지 모르겠을 때
- 대화 내용을 자동으로 보관해주니 아카이빙도 가능
- 간단한 질문에 적합
- 체계화된 구조가 있지 않아서 적극적으로 참여하지 않은 대화에서는 의미 있는 정보를 얻기 어렵다.
메일링 리스트
- 공개 메일링 리스트에 질문을 던지면 구독중인 모두가 질문이 전달되고 답변하고, 배울 수 있다.
- 메일 내용은 검색 가능한 아카이브로 보관
- 맥락 정보가 많이 필요한 복잡한 질문에 적합
- 그룹 채팅처럼 빠르게 주고받는 대화에는 취약
- 오래전 스레드에서 얻은 해답이 오늘날의 환경에서도 여전히 유효할지는 알기 어렵다.
지식 확장하기: 누구나 가르칠 게 있다
- 가르친다는 건 전문가의 전유물이 아니다.
- 전문성이라는 게 '초심자 아니면 전문가'처럼 이분법적으로 나눠지지도 않는다.
- 전문성은 다차원 벡터입니다. 누구나 영역별로 다양한 수준의 전문성을 갖추고 있다.
오피스 아워
누군가가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트
- 지식 공유를 목적으로 오피스 아워를 최우선으로 활용하는 경우는 거의 없다.
- 분명한 것은 오피스 아워가 전문가와 직접 대면할 기회를 제공한다는 사실
문서자료
문서자료 갱신하기
- 무언가를 막 배운 순간이 기존 문서자료에서 개선점을 찾기에 가장 좋은 때
- 구글에서는 문서자료 소유자가 누구든 모든 엔지니어에게 갱신 권한이 있다고 여긴다.
새로운 문서자료 작성하기
- 숙달되면 자신만의 문서자료를 작성하고 기존 문서자료들을 갱신하라.
- 새로운 개발 흐름을 만들어냈다면 그 단계들을 설명하는 문서자료를 작성하라.
- 다른 사람에게 공유하여 여러분이 걸어간 길을 쉽게 따라오도록 하라.
- 내용이 낡거나 틀렸을 때 소유자에게 알릴 수 있게 하거나, 직접 고칠 수 있게 하라.
문서화 촉진하기
- 문서화는 소수가 시간을 들여 다수에게 이득을 주므로 조직 전체에 도움을 준다.
- 기본적으로 기여자와 수혜자가 달라서 적절한 보상 없이는 사람들을 움직이게 하기 어렵다.
- 같은 문제로 팀원들이 계속 찾아올 때 문서를 공유하기만 한다면 해결될 수 있으니 도움이 되기도 한다.
- 팀과 조직의 규모를 키우는 데도 보탬이 된다.
- 문서자료에 담긴 정보는 기본으로 참고해야 할 표준이 된다.
- 표준을 팀 외부로 확산시킬 수도 있다.
코드
- 코드 문서화는 또 다른 형태의 지식 공유 수단이다.
- 깔끔한 문서자료는 라이브러리 이용자는 물론 향후 라이브러리를 유지보수하는 이들에게도 큰 혜택을 준다.
- 코드 내의 주석은 지식을 미래로 전달한다.
- 트레이드오프: 코드 주석도 적극적으로 관리하지 않으면 금세 낡은 지식이 되어 코드와 모순되는 정보 때문에 혼란을 겪을 수 있다.
- 코드 리뷰는 코드 작성자와 리뷰어 모두에게 배움의 기회를 준다.
조직의 지식 확장하기
- 조직이 커질수록 전문 지식을 조직 전반에 제대로 공유하기가 어려워진다.
- 표준 정보 소스 같은 것들은 조직이 커질수록 혜택도 커진다.
지식 공유 문화 일구기
구글은 코드 같은 산출물보다 문화와 환경을 첫 번째로 두고 생각해야 더 나은 결과를 얻는다고 믿는다.
존중
- 지식을 공유할 때는 상냥함과 존중을 담아야 하고, 또 그래야만 가능하다.
- 기술 업계에서는 '뛰어난 괴짜'를 용인하는(심지어 숭배하는) 경향이 있지만, 해로운 현상이다.
- 상냥한 전문 가도 얼마든지 가능하다.
보상과 인정
- 좋은 문화는 적극적으로 육성해야 하며 지식 공유 문화를 장려하려면 인정과 보상 제도가 뒷받침되어야 한다.
- 사람들은 진부한 칭찬보다는 확실한 보상에서 동기를 얻는다.
- 말로만 하지 말고 보상과 수상 제도를 통해 실질적인 혜택을 주어야 하는 이유
표준 정보 소스 구축하기
- 표준 정보 소스는 회사 차워의 중앙집중적 정보 원천
- 표준화하고 전파하는 수단
- 개별 부서나 개인들이 각자의 정보를 생성해 활용하다 보면 서로 충돌하거나 파편화되기 마련인데, 표준 정보 소스로 이런 문제를 막을 수 있다.
- 표준 정보는 조직 차원에서 합의한 내용을 제공하고 눈에 잘 띄기 때문에 해당 분야 전문가들이 적극적으로 관리하고 감독해야 한다.
- 복잡한 주제일수록 소유자를 명확히 정해둬야 한다.
개발자 가이드
- 구글은 엔지니어들을 위해 깊이 있는 공식 가이드를 만들어 활용
- 전문가는 회사 차원의 방침을 개인적으로 설명해주지 않아도 되므로 시간이 절약
- 배우는 사람은 필요하면 언제든 신뢰 가는 정보를 찾아볼 수 있는 정보 소스가 있음을 알게 된다.
- 전문가들이 공통의, 확장하기 쉬운 자원을 활용하여 특정한 정보의 필요성을 인지하고 해결하고, 지식이 확장
go/ 링크
- 구글 사내 단축 링크 서비스
- 키워드를 중심으로 검색과 공유에 용이
코드랩
- 동작하는 예시 코드, 설명, 코딩 연습문제 등을 활용
- 엔지니어에게 새로운 개념이나 프로세스를 가르치는 실습형 튜토리얼
- 관리 비용이 많이 들며 학습자 개 인의 특수한 요구에는 대응하지 않는다.
정적 분석
- 검사 로직을 자동화할 수 있는 모범 사례들을 공유하는 강력한 수단
- 목적: 개선할 수 있는 코드를 찾아서 코드 작성자나 리뷰어에게 알려주는 것
- 정적 분석 도구를 설정하기가 조금 까다롭겠지만 한 번 설정하고 나면 확장하기는 쉽다.
- 엔지니어 개개인의 지식을 강화해주며, 조직 차원에서는 더 많 은 모범 사례를 더 일관되게 적용
소외되지 않기
- 전달하려는 지식의 중요도에 따라 정보 공유 매체가 '얼마나 공식적이어야 하는가' 에 대한 기대치가 다르다.
- 공식 문서는 항상 최신 싱태로 유지되기를 기대하지만, 뉴스레터에는 그런 기대를 하지 않기 때문에 더 편하게 관리할 수 있다.
뉴스레터
- 업무에 꼭 필요하지는 않지만 엔지니어들이 관심을 가질만한 정보를 유통하는 괜찮은 수단
- 제공 빈도를 높이기보다는 내용을 더 유용하고 흥미롭게 채워야 효과적
- '화장실에서도 테스트(Testing on the Toilet; TotT)'(테스트 팁)와 '화장실에서도 학습(Learning on the Loo)'(생산성 팁)
- 독특한 전달 형태 덕에 다른 뉴스레터와 차별화
커뮤니티
- 다양한 분야에서 주제를 중심으로 다른 부서의 구글러들과 커뮤니티를 형성해 지식을 공유
- 열린 소통 채널 덕분에 소속 팀이나 가까운 동료 외의 수많은 전문가 로부터 무언가를 배우기가 더 수월
- 정보 섬과 중복 문제도 피할 수 있다.
가독성 제도: 코드 리뷰를 통한 표준 멘토 제도
- 프로그래밍 언어 모범 사례를 전파하기 위한 구글 전사 차원의 '표준 멘토링 프로세스'를 지칭
- 신규 입사자에게 모범 사례를 가르치고, 어떤 공유 인프라를 활용할 수 있는지 알려줬으며, 구글에서의 코드 작성이란 어떤 것인지를 보여주며 시작
가독성 인증 프로세스란?
- 구글에서 코드 리뷰는 필수
- 모든 변경 목록(ChangeLog; CL)은 가독성 승인을 얻어야 한다.
- 구글은 덩치가 너무 커져서 코드 리뷰만으로는 모든 엔지니어에게 모범 사례들을 충분히 엄격하게 가르치는 게 불가능. 그래서 가독성 승인이 추가
- 가독성 제도는 표준화와 개인화가 융합된 방식의 지식 확장 수단
마치며
- 지식은 비록 형태는 없을지라도 많은 측면에서 소프트웨어 엔지니어링 조직의 가장 중요한 자산
- 지식 공유야말로 조직에 탄력을 불어넣어 변화에 직면해서도 생존할 수 있도록 하는 데 결정적인 역할
- 대부분 지식을 쉽게 공유하는 데 투자한 노력은 회사의 생애 동안 그 몇 배로 돌려받는다.
