Home 03. 지식 공유
Post
Cancel

03. 지식 공유

조직에는 배움의 문화가 자리 잡혀 있어야 하고, 그러려면 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다.

3.1 배움을 가로막는 장애물

  1. 심리적 안전 부족 - 불이익이 두려워서 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경
  2. 정보 섬 - 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화(정보 파편화, 정보 중복, 정보 왜곡)
  3. 단일 장애점 - 중요한 정보를 한 사람이 독점하면 병목이 생긴다. 좋은 의도에서 ‘내가 다 처리하지’라는 마음은 단기 효율은 높여줄지 몰라도 장기 확장성을 희생하는 꼴이다.
  4. 전부 아니면 전무 전문성 - 조직 구성원이 모든 것을 아는 사람과 아무것도 모르는 초심자로 나뉜다. 이렇게 되면 지식과 책임은 계속 이미 전문가가 된 사람들에게 집중되고, 새로운 팀원이나 초심자들은 그들만의 울타리에 같혀 드리게 성장하게 된다.
  5. 앵무새처럼 흉내내기 - 이해하지 못한 상태로 흉내만 내는 것
  6. 유령의 묘지 - 무언가 잘못될 게 두려워서 아무도 손대지 않는 영역을 말한다.

3.2 철학

소프트웨어 엔지니어링을 여러 버전의 프로그램을 여러 사람이 참여해 개발하는 일이라고도 정의할 수 있다. 소프트웨어 엔지니어링에서 가장 중요한 요소는 사람이다. 조직의 성패는 인력에 얼마나 투자해서 잘 키워내는냐에 달려 있다.

  • 전문가가 일대일로 해주는 조언 - 어떤 측면에서는 매우 효과적이지만 확장성이 부족하여 팀이 커지면 그리 유용하지 못하다.
  • 문서화된 지식 - 조직 전체로 퍼뜨릴 수 있고, 확장성이 좋으나 개별 학습자가 처한 특수한 상황에는 다소 적합하지 않고, 유지보수 비용이 많이 든다.
  • 현장 지식

현장 지식과 문서화된 지식은 서로를 보완해준다. 심지어 모두가 전문가로 구성되고 완벽한 문서로 무장한 팀이라 해도 서로 소통하고 다른 팀과 협력하고 때로는 다른 팀의 전략을 수용해야 한다.

3.3 판 깔아주기: 심리적 안전

심리적 안전은 학습 환경을 조성하는 데 매우 중요하다. 먼저 자신이 이해하지 못한 게 있음을 인정해야 무언가를 배울 수 있다.

배움에는 무언가를 시도하다가 실패해도 안전하다는 인식이 엄청나게 중요하다. 건강한 환경에서라면 사람들은 질문을 던지고, 틀리고, 새로운 지식을 얻는 걸 편안하게 생각한다.

3.3.1 멘토 제도

멘토 제도는 신규 입사자에게 심리적 안전을 심어주는 효과적인 방법이다. 멘토는 멘티가 누구에게 조언을 구해야 할지 알 수 없을 때 찾아갈 수 있는 안전망이 되어 준다.

3.3.2 큰 그룹에서의 심리적 안전

대부분의 사람은 낯선 이들로 구성된 큰 그룹을 찾기보다는 바로 옆 동료에게 도움을 요청하는 걸 더 편하게 생각한다. 하지만 일대일 방식은 확장하기 어렵다. 그룹 방식은 일대일보다 확장성이 좋지만 두려움은 더 크게 느낀다. 그래서 큰 그룹에서는 심리적 안전이 더욱 중요해진다. 그룹의 모든 구성원이 안전한 환경을 만들고 유지하는 역할을 함께 해줘야 한다. 신규 입사자는 부담없이 질문할 수 있게 해주고, 성장 중인 전문가는 기존 전문가들이 자신의 답변에서 허점을 찾아 공격할지 모른다는 두려움 없이 도움의 손길을 내밀 수 있도록 해야 한다

이처럼 안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화이다.

[그룹내 안티패턴]

  • 기초적인 질문이나 실수를 가려내서 질문한 사람을 꾸짖는다.
  • 자신의 지식을 뽐낼 목적으로 설명한다.
  • 잘난 체하고 비난하며 건설적이지 못한 방식으로 대응한다.
  • 승자와 패자를 가리는 논쟁 형식으로 상호작용이 이루어진다.

3.4 내 지식 키우기

3.4.1 질문하기

항상 배우고 항상 질문하라 초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것이다. 동료들이 가장 훌륭한 정보 소스일 경우가 많으니 이 귀중한 자원을 충분히 활용하도록 하자, 또 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이자

팀의 리더든 새로운 멤버든 항상 무언가 배울 게 있는 환경에서 살아야 한다. 그렇지 않으면 더 이상 성장하지 못할 것이다.

3.4.2 맥락 이해하기

새로운 것을 이해하는 것 뿐만 아니라 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함된다.

엔지니어들은 너무 성급하게 ‘이건 잘못됐어’라고 결론 짓는 경향이 있다. 생소한 코드, 언어, 패러다임을 접했을 때는 더욱 심하다. 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해야 한다. 우선 코드의 목적과 맥락을 이해하고, 그런 다음 변경하려는 방향이 여전히 더 나은지 고민해야 한다.

3.5 질문 확장하기: 커뮤니티에 묻기

무언가를 일대일로 배울 때는 기록하는 습관을 기르자, 개인이 기록해둔 지식을 공유하는 것도 유익하지만 더 큰 커뮤니티에 도움을 청하는 것도 좋다.

3.5.1 그룹 채팅

질문은 있는데 적합한 사람으로부터 도움을 받기 어려울 때가 있다. 누구에게 물어봐야할지 모르겠거나 물어보려는 사람이 바빠서일 경우도 있다. 이런 상황이라면 그룹 채팅이 효과적이다. 동시에 여러 사람에게 질문을 던질 수 있고 시간이 허락되는 사람들끼리 빠르게 대화를 주고 받으며 답을 찾기 때문이다.

그룹 채팅은 간단한 질문에 적합하다. 체계화된 구조가 있는 게 아니라서 본인이 적극적으로 참여하지 않는 대화에서는 의미 있는 정보를 뽑아내기 어려울 수 있다.

3.5.2 메일링 리스트

공개 메일링 리스트에 질문을 던지는 건 그룹 채팅에 질문하는 것과 상당히 비슷하다. 잠재적으로 답을 줄 수 있는 수많은 사람에게 질문이 전달되고, 해당 메일링 리스트를 구독하는 모두가 그 질문으로부터 배울 수 있다. 그룹 채팅과 다른 점은 더 많은 사람과 공유하기 쉽다는 점이다. 메일 내용은 검색 가능한 아카이브로 보관되고 그룹 채팅보다 구조가 잘 갖춰져 있다.

메일링 리스트는 맥락 정보가 많이 필요한 복잡한 질문이 적합하고, 그룹 채팅처럼 빠르게 주고 받는 대화에는 취약하다.

3.5.3 YAQS:질의응답 플랫폼

YAQS는 구글 내부에서 사용하는 스택오퍼플로와 유사한 플랫폼이다.

3.6 지식 확장하기: 누구나 가르칠 게 있다.

가르친다는 건 전문가의 전유물이 아니다. 전문성은 다차원 벡터이다. 누구나 영역별로 다양한 수준의 전문성을 갖추고 있다. 구글 엔지니어들은 다음과 같이 다양한 방식으로 다른 사람들 가르친다.

3.6.1 오피스 아워

오피스 아워는 누군가가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트이다. 당장 급한데 오피스 아워까지 기다리는건 고문이기 때문에 지식 공유를 목적으로 오피스 아워를 최우선으로 활용하는 경우는 거의 없다. 그래도 전문가와 직접 대면할 기회를 제공하기 때문에 문제가 불명확하여 어떻게 질문해야 할지 모를 때나 문서화되지 않은 특수한 문제에 맞닥뜨렸을 때 특히 유용하다.

3.6.2 기술 강연과 수업

구글의 engEDU팀은 구글 엔지니어부터 전 세계의 학생들을 포함한 다양한 청중에게 컴퓨터 과학을 교육하는 데 중점을 두고 있다. 또 g2g프로그램을 운영하여 구글러라면 누구든 가입하여 동료 직원들을 위한 수업을 개설하거나 참석할 수 있게 했다.

[수업의 결과를 극대화하는 조건]

  • 자주 복잡한 주제를 다뤄야 한다. 수업은 개설 비용이 크므로 해결해야 할 분명한 요구가 있을 때 만들어져야 한다.
  • 주제가 비교적 안정적이어야 한다. 내용이 자주 바뀌면 수업 교제를 고치는 데 시간이 많이 든다.
  • 직접적인 도움없이 학생 혼자 쉽게 익힐 수 있는 주제라면 혼자석 학습할 수 있는 매체가 더욱 효과적이므로 질문에 답해주고 일대일로 도와줄 수 있는 교사가 있어야 효과적이다.
  • 수업을 정기적으로 개설해도 될 만큼 수요가 많아야 한다.

3.6.3 문서 자료

문서자료는 독자가 무언가를 배우도록 돕는 것을 최우선 목표로 하는 기록된 지식이다.

  1. 문서자료 갱신하기 - 무언가를 막 배운 순간이 기존 문서자료에서 개선점을 찾기에 가장 좋은 때이다. 처음 배우는 단계에서 문서자료의 실수나 빠진 부분을 발견한다면 곧바로 고쳐라
  2. 새로운 문서자료 작성하기 - 숙달되면 자신만의 문서자료를 작성하고 기존 문서자료들을 갱신해봐라. 그리고 피드백할 방법이 있어야 한다.
  3. 문서화 촉진하기 - 문서자료를 작성하려면 시간과 노력이 드는데, 코딩할 시간에서 뺏어와야 하기 때문이다. 문서화는 팀과 조직의 규모를 키우는 데도 보탬이 된다.

3.6.4 코드

코드도 지식이라는 사실을 인지하느냐 여부가 코드 가독성과 명확성에 간접적으로 영향을 줄 때가 많다.

코드 문서화는 또 다른 형태의 지식 공유 수단이다. 깔끔한 문서자료는 라이브러리 이용자는 물론 향후 라이브러리를 유지보수하는 이들에게도 큰 혜택을 준다. 또 코드 리뷰는 코드 작성자와 리뷰어 모두에게 배움의 기회를 준다. 구글은 가독성 프로세스라는 것을 두어 코드 리뷰를 통한 멘토링 제도를 표준화했다.

3.7 조직의 지식 확장하기

조직이 커질수록 전문 지식을 조직 전반에 제대로 공유하기가 어렵다. 가령 표준 정보 소스 같은 것들은 조직이 커질수록 혜택도 커진다.

3.7.1 지식 공유 문화 일구기

많은 회사에서 조직 문화를 사람 사이의 문제로 치부한다. 하지만 구글은 산출물보다 문화와 환경을 첫 번째로 두고 생각해야 더 나은 결과를 얻는다고 믿는다.

  1. 존중 - 몇몇 개인의 나쁜 행동 때문에 팀 혹은 커뮤니티 전체가 초심자에게 버티기 가혹한 환경으로 변하기도 한다. 지식을 공유할 때는 상냥함과 존중을 담아야 하고, 또 그래야만 가능하다. 기술 업계에서는 뛰어난 괴짜를 용인하는 경향이 있지만 이는 해로운 현상이다. 상냥한 전문가도 얼마든지 가능하다.
  2. 보상과 인정 - 구글은 회사 표준의 성과 검토와 승진 기준부터 동료 사이에서 주고 받는 상에 이르기까지 다양한 성과 인정 제도를 운영한다.예) 동료 상여 제도, 쿠도스(공개칭찬)제도가 있다.

3.7.2 표준 정보 소스 구축하기

표준 정보 소스는 회사 차원의 중앙집중적 정보 원천으로 전문가의 지식을 표준화하고 전파하는 수단이다. 조직 내 모든 엔지니어에게 공통으로 필요한 정보를 담아두는 최선의 도구이기도 하다. 개별 부서나 개인들이 각자의 정보를 생성해 활용하다 보면 서로 충돌하거나 파편화되기 마련인데 표준 정보 소스로 이런 문제를 막을 수 있다.

그리고 표준 정보는 조직 차원에서 합의한 내용을 제공하고 눈에 잘 띄기 때문에 해당 분야 전문가들이 적극적으로 관리하고 감독해야 한다.

중앙의 표준 정보 소스를 만들고 관리하는 일에는 비용과 시간이 많이 들며 모든 정보가 조직 차원에서 공유될 필요는 없다. 그래서 이 일에 얼마나 투자할지를 계산할 때는 누구를 위한 정보인지를 고려해야 한다.

  1. 개발자 가이드 - 가이드에 익숙한 전문가가 후임 엔지니어에게 적시에 알맞은 링크를 보내줄 수 있다. 전문가는 개인적으로 설명해줄 필요가 없어 시간이 절약되고 배우는 사람도 필요하면 언제든 신뢰 가는 정보를 찾아볼 수 있는 정보 소스가 있음을 알게 된다.
  2. go/ 링크 - 구글 내에서 쓰는 URL 단축 서비스이다. 구글 내부의 참조 대부분은 하나 이상의 내부 go/ 링크를 가지고 있다.
  3. 코드랩 - 코드랩은 동작하는 예시 코드, 설명, 코딩 연습 문제등을 활용해 엔지니어에게 새로운 개념이나 프로세스를 가르치는 실습형 튜토리얼이다.
  4. 정적 분석 - 정적 분석 도구는 검사 로직을 자동화할 수 있는 모범 사례들을 공유하는 강력한 수단이다.

3.7.3 소외되지 않기

업무를 수행하려면 반드시 필요한 정보들이 있다. 또 상대적으로 덜 중요한 정보도 있다. 이런 전달하려는 지식의 중요도에 따라 정보 공유 매체가 얼마나 공식적이어야 하는가에 대한 기대치가 다르다.

  1. 뉴스레터 - 뉴스레터는 업무에 꼭 필요하지는 않지만 엔지니어들이 관심을 가질만한 정보를 유통하는 괜찮은 수단이다. 이런 종류의 정보는 제공 빈도를 높이기 보다는 내용을 더 유용하고 흥미롭게 채워야 효과적이다.
  2. 커뮤니티 - 커뮤니티를 통한 소통은 열린 소통 채널이라 수많은 전문가로부터 무언가를 배우기가 더 수월하다.

3.8 가독성 제도 : 코드 리뷰를 통한 표준 멘토 제도

구글에서 가독성 제도는 단순한 코드 가독성 이상을 의미한다. 전사 차원의 표준 멘토링 프로세스를 지칭하는 것으로써 언어 이디엄, 코드 구조, API 설계, 공통 라이브러리의 올바른 사용법, 문서화, 테스트 커버리지 등의 전문 지식을 광범위하게 다룬다.

3.8.1 가독성 인증 프로세스란?

구글에서 코드 리뷰는 필수이다. 모든 변경 목록(CL)은 가독성 승인을 얻어야 한다. 가독성 승인이란 해당 언어의 가독성 자격증이 있는 누군가가 해당 CL을 승인했다는 표시이다.

가독성 자격증을 받은 엔지니어라 함은 특정 프로그래밍 언어를 사용하여 구글의 모범 사례와 코딩 스타일에 맞는 명확하고 관용적이고 유지보수하기 쉬운 코드를 일관되게 작성하는 사람이라는 뜻이 된다.

리뷰어는 특정 언어를 깊이 이해하고, 다른 사람의 코드를 검토하며 가르쳐야 하므로 항상 최고 수준을 유지해야 한다. 또 가독성 제도는 공격용 무기가 아닌, 가장 우선시되고 중요한 멘토링 수단이자 협업 수단으로 생각하고 행동해야 한다.

3.8.2 가독성 인증 프로세스를 두는 이유

코드는 작성되는 횟수보다 훨씬 많이 읽히며, 구글의 규모와 구글이 매우 큰 모노리포를 이용한다는 점을 감안하면 그 차이는 훨씬 커진다.

가독성 제도는 엔지니어들에게 소속 팀에서 통용되는 현장 지식 이상을 전달하는 매우 큰 장점을 선사한다. 또 일관성을 강화하고 정보 섬을 없애고 확립된 표준에서 벗어나는 일을 막기 쉽다는 게 장점이다. 코드베이스 전체가 일관될 때 얻는 가치는 아무리 강조해도 부족한다.

가독성 제도는 코드 리뷰가 길어진다는 단기적인 비용과 코드 품질 개선, 리포지터리 차원의 코드 일관성 향상, 엔지니어 전문성 향상에서 절약하는 장기적인 비용을 의식적으로 맞바꾸는 제도이다.

3.9 마치며

지식은 형태는 없을지라도 많은 측면에서 소프트웨어 엔지니어링 조직의 가장 중용한 자산이다. 개방적이고 정직한 지식 공유를 장려하는 문화는 지식을 조직 전반에 효율적으로 전파하여 날이 갈수록 조식이 더 확장되도록 해준다. 대부분 지식을 쉽게 공유하는 데 투자한 노력은 회사의 생애 동안 그 몇 배로 돌려받는다.

3.10 핵심 정리

  • 심리적 안전은 지식 공유 환경을 조성하기 위한 토대이다.
  • 작게 시작하라 질문하고 기록하라
  • 직원들이 전문가와 문서화된 자료 모두로부터 필요한 도움을 쉽게 얻을 수 있도록 하라
  • 자신의 전문 지식을 가르치고 전파하는 사람들을 격려하고 보상하는 체계적인 제도를 마련하라
This post is licensed under CC BY 4.0 by the author.

02. 팀워크 이끌어내기

04. 공정 사회를 위한 엔지니어링