다양한 커리어를 밟아온 멋진 분들과, 함께 일할 수 있는 것은 행운이야

왜 이 책을 읽기 시작했는가

이전에 읽었던 '개발자로 살아남기'라는 책의 연장으로, LINE에 근무하는 개발자 분들은 어떠한 인생을 살아왔고 어떠한 기대를 품고 입사하게 되었나 궁금해졌다. LINE에 입사할 때 받았던 책인데 이제서야 읽었다는 점이 조금 걸리긴 하지만... 사실 자신이 필요할 때 얻는 정보가 더 많이 느끼고 체감이 되는건지라, 지금 읽는 것이 오히려 좋다 생각한다.

책을 읽고 느낀 점

• LINE에 근무하고 계신 12분의 과거와 현재를 알 수 있어 좋았다. 김재석 님의 '100개의 회사가 있다면 100개의 성장 스토리가 있다.'처럼, 사람들은 자신만의 독창적인 발자취를 걸어갈 수 밖에 없고, 그들이 어떠한 마음가짐으로 그 길을 선택했는지 들여다보는 일은 굉장히 흥미롭다.
• 서로 다른 이야기들이지만, 공통적으로 '커뮤니케이션'에 대해 이야기하는 점이 흥미로웠다. 결국에 회사는 이러한 다양한 사람들이 모여 협업해야 하는 장소이기에, 소통이 잘되어야 하는 것이 첫 번째인 듯. 특히, '고맥락 / 저맥락으로 소통하기'는 책을 읽으며 가장 인상 깊어 앞으로 자주 사용하게 될 단어라 생각한다.

1부 - 라인 개발자의 일상

노승헌 - 자유와 책임, 그리고 라인

p26. 라인의 이런 자유로움은 물론 거저 주어지는 것이 아니다. 자유롭게 해보고 싶은 것들을 시도할 기회가 있지만 그런 시도들이 유의미한 결과로 이어질 수 있도록 주인 의식과 책임감을 갖추려는 분위기가 형성되어 있다. (...) 다른 부서와 협업을 하고 함께 서비스를 만들어나가면서 책임감과 주인 의식을 가지고 내 일처럼 일하는 사람은 카운터 파트너로부터 좋은 평가를 얻게 된다. 반면 적극적이지 않고 강 건너 불구경하듯 협업했던 사람이라면 좋은 코멘트를 기대하기 어려울 것이다.

김영환 - 매일이 새로운 20년 차 개발자

p34. 어떤 일을 즐기게 되었을 때 진정으로 그 일을 사랑하게 되고, 그러면 어떤 힘든 상황이 오더라도 쉽사리 포기하지 않게 되는 것 같다.

p40. 내가 게임을 만들 때 같이했던 동료들은 훌륭한 개발 능력과 게임에 대한 열정, 성실한 태도, 원만한 커뮤니케이션 능력 등을 동시에 갖춘 이들이었다. 게임 개발이 아닌 다른 부서로 옮기고 나서도 라인에는 멋진 동료가 너무나도 많다는 사실을 새삼 깨달았다. 그들과 함께 일을 하고 있다는 것만으로도 나 스스로 발전하는 기분이 든다.

p43. 기회는 누구에게나 주어지지만 그 기회를 잡을 준비가 되어 있느냐 아니냐는 각자의 문제라는 것을 요즘 많이 느끼고 있다. 하루를 최선을 다해 사는 것은 어렵지 않다. 어려운 건 매일매일 최선을 다하는 것이다. 지치기도 하고 지루하기도 할 테니까. "내일, 모레에 행복해지기 위해 사는 게 아니라 지금 당장 행복해야 한다." 한창 힘든 시기에 여러 인생의 선배들이 들려준 말이었다. 선물과도 같은 오늘, 행복하기 위해 지금 하는 일을 즐기고 재밌게 생활할 수 있다면 매일 매일 최선을 다하며 살아갈 수 있을 것이다.

김택주 - 글로벌로 출근하는 라인 개발자

p51. 아마존이 그 전까지 일했던 스타트업과는 다르게 좀 더 성숙된 조직과 문화를 가지고 있었다고 느낄 수 있었던 지점은 다양했다. 우선 팀 내부적으로 목표가 분명했고 사람들의 역할도 체계적으로 나뉘어 있었다. 팀의 비즈니스도 탄탄했다. 기술적으로는 이전 스타트업에서 내가 손수 구축해야 했던 많으 시스템, 예를 들면 모니터링이나 배포 등이 이미 잘 갖춰져 있어 효율적으로 맡은 업무에 집중할 수 있었다. (...) 관련 업무에 전문성을 지닌 시니어 개발자가 많아 시스템에 문제가 발생했을 때 토론과 배움의 기회를 갖고, 소통과 협력을 통해 시스템을 개선해나갈 수 있었던 것은 아마존과 같은 대기업에서 느낄 수 있던 장점이었다.

p53. 돌이켜보면 새로운 기회 앞에서 주저하지 않고 도전을 선택했던 것이 개발자로서 나 자신이 성장할 수 있는 동력이자, 스타트업에서 글로벌 기업까지, 시스템에서 백엔드까지 여러 포지션에서 다양한 경험을 할 수 있었던 바탕이었음을 깨달았다.

p56. 개발자의 성장과 역량 개발의 한 축은 장애와 트러블에 대응하며 문제해결 능력을 키워나가는 데 있지 않나 하는 생각을 하게 되었다.

p58. 그러나 중요한 깨달음은 다양한 문화와 언어, 국적 출신의 다양한 성격과 장점을 지닌 사람이 함께 일할 때 조직의 역동성이 강화되고, 다각적인 시각에서 고품질의 서비스와 솔류션을 제시할 수 있다는 점이다. 개인의 의견 차이로, 문화적 오해와 몰이해로, 언어 차이로 어려움을 겪기도 하고, 본연의 업무보다 커뮤니케이션에 시간과 노력이 집중될 때도 물론 있다. 하지만 다양한 관점이 모여 민주적이고 수평적인 토론이 이루어지고 개선이 이루어질 때, 팀이 성숙하고 조직이 성장한다는 점은 분명했다.

p62. 여러 국가에서 서비스를 출시하면서 얻은 가장 주요한 교훈을 결론부터 말하자면, 좋은 기능을 가진 서비스를 출시하면 자연스럽게 유저들이 증가할 것이라는 가정이 틀렸음을 인정해야 한다는 것이었다. (...) 유저의 니즈에 대한 근거는 무엇인가, 서비스의 우선순위는 무엇인가, 서비스 업데이트 후 개선 여부를 어떻게 검증할 것인가, 이 세 가지 질문에 대한 답을 찾기 위해 끈질기게 매달렸다.

2부 - 개발자가 되는 법

김정엽 - '문송'하지 않은 철학도의 개발 이야기

p75. 아리송한 난제를 붙잡고 씨름하는 가운데, 철학자들과 개발자들은 모두 헛소리하기를 두려워하지 않는다. 오히려 실패 가능성을 당연한 사실로 받아들인다. 겹겹이 쌓아 올린 치밀한 철학적 논증도 허점이 있을 수 있고, 촘촘한 방어 논리를 갖춘 코드도 버그가 있을 때가 허다하기 때문이다. (...) "부디, 결코 헛소리하기를 겁내지 말라! 그렇지만 네 헛소리에 귀를 기울여야 한다." 비트겐슈타인이 철학에 관해서 했던 말과 같이 실패를 담담하게 살펴보고 해결책을 부지런히 엮어나가는 자세는, 훌륭한 철학자와 개발자에게서 똑같이 찾을 수 있는 덕목이자 '덕심'인 셈이다.

p77. 결국 내가 개발자로서 일하고 싶었던 가장 큰 이유는, 내 생각이 현실에 빠르게 힘을 보태는 모습을 보고 싶은 욕망이 아닐까 싶다. 내 생각을 따라 짜맞춘 기호들에 따라 컴퓨터가 움직이는 모습을 보는 경험에는, 마약과도 같은 즉각적인 보상이 있다.

p78. 개발자로 일하고 싶다는 내 마음은 창작 욕구와 인정 욕구의 합이라고도 말할 수 있을 것 같다. 개발에는 기여 (contribution)에 대한 인정 (credit)이 분명하다. (...) 서버 릴리즈 노트에 내가 작업한 코드 이름이 적혀 있는 모습을 볼 때 얻는 보람은 '명예'나 '금전적 보상'과는 다른 차원의 즐거움이다.

p81. 내가 지금 개발자로서 실제로 보고 접하는 개발 업무의 스펙트럼은 폭넓고 선명하다. 코딩을 하고 git을 다루는 도메인 지식도 중요하지만, 사람들과 같이 이야기하고 practice를 구축하는 일도 개발 일의 큰 부분을 차지한다. 특정 전공이나 커리어만으로는 메울 수 없는 스펙트럼 위에서, 다른 전공이나 직업 출신의 개발자가 활약할 수 있는 스펙트럼의 대역도 가지각색이다. 그러니 나도 전직 철학도라는 닥지가 붙은 코딩 머신으로 전락할 필요가 없었다. 부족한 전문 지식을 채워나가면서, 내가 아직 미치지 못하는 스펙트럼의 다른 구석을 채워나가면 되는 것이다.

p87. 원칙을 되새기며 문서를 유지 보수하는 일은 결코 쉽지 않다. 만약 우리 팀이 눈앞의 문제를 처리하고 넘기는 데만 급급했다면 어땠을까. 변칙적으로 문제를 처리해나가는 팀원 각각의 경험치는 어마어마했을지 모른다. 하지만 그렇게 얻는 경험치는 느낌적인 느낌의 집적일 뿐이다. 팀원들이 앞서 경험하고 체득했던 것들을 내가 전수받을 수도 없었을 테다. 느낌은 전수되지도 않고 일관되지도 않은 탓이다. 주니어 개발자로서 불안한 느낌이 아닌 공고한 원칙을 체화하는 과정에서, 팀의 실천과 소통은 내게 큰 버팀목이 된다.

하태호 - 주니어 개발자의 성장기 + 개발 공부 팁

p92. 생활 속에 긍정적인 변화를 가져오는 프로그램을 만들 수 있는 좋은 개발자가 되고 싶었다. 그런 개발자가 되기 위해서는 내가 열심히 노력해야 할 뿐만 아니라 좋은 개발자로 성장할 수 있는 환경에 있어야 한다고 생각했다.

p96. 내가 속한 팀의 개발자들은 개발 연차와 상관없이 서로 '님' 호칭을 사용하며 자유롭게 질문하고 생각과 의견을 제시하는 편이다. 이러한 조직 문화 덕분에 다양한 질문과 의견이 모이면서 더 깊은 수준의 고민도 쉽게 해결할 수 있고, 나와 같은 주니어 개발자들도 능동적으로 업무를 진행할 수 있어서 빠르게 성장할 수 있다.

p103. 문제를 해결해야 하다 보니 평소에도 기술 블로그나 뉴스를 꾸준히 읽으며 노력하는 편이다. 내가 더 공부해야 할 것이 있거나 기술적인 고민이 있을 때 언제든지 부담 없이 질문하고 논의할 수 있는 환경에 있다는 것도 성장에 많은 도움이 되는 것 같다. 질문을 하는 사람으로서는 모르는 내용을 어떻게 질문해야 할지 계속 고민해야 하고, 질문을 받는 경우에는 내가 답변해야 하는 내용을 먼저 머릿속에서 정리해서 답변해야 한다.

강윤신 - 내가 미리 알았으면 좋았을 개발 생활 팁

p115. '고맥락 문화 (high context culture)'라는 단어는, 의사소통이 실제로 표현한 내용을 기준으로 이루어지는지, 아니면 여러 다양한 맥락을 고려해서 이루어지는지를 기준으로 고맥락과 저맥락을 구분한다는 인류학자 에드워드 홀이 주장한 개념이다. 어떤 사람을 한 가지 스타일로 정의할 수 없듯, 나도 상황에 따라 고맥락/저맥락 커뮤니케이션을 하지만, 일을 할 때는 주로 저맥락에 가까운 형태로 의사소통을 하는 편이다. 반면 회사에서는 고맥락 커뮤니케이션을 하는 사람도 흔하게 볼 수 있다. 이 과정에서 서로 이해하는 내용이 달라지는 문제가 생긴다. 상대방이 고맥락을 기준으로 표현한 내용을 내가 저맥락으로 이해한다든가, 그 반대의 상황이 벌어지는 경우가 자주 있었다. (...) 예를 들어 내 말을 듣는 상대방이 지금 대화 주제를 처음 듣는다고 가정해보기도 했다. 상대방은 이 주제를 처음 듣는다고 가정하면 대화 진행 시 어떤 주제에 대한 설명을 먼저 하고 이후 단계로 넘어가야 한다. 그러다 보니 이 주제가 왜 나오게 됐는지, 중간에 검토했던 다른 내용은 어떤 게 있었는지, 각각의 선택지에 대해 어떤 판단을 내렸고 결과적으로 어떤 방법을 선택했는지 시간 순서대로 나열해야 했다. 혹은 반대로, 상대방은 관련 주제에 경험이 많고 지금까지 어떤 일이 있었는지에 대해 충분히 알고 있다고 가정해보기도 했다. 이 경우에는 결과만 간결하게 전달하는 형태로 설명했다. 결과를 먼저 이야기하고, 중간에 있었던 중요한 상황들은 이후에 설명하는 형태로 대화하는 방법을 이용했었다. 다만, 내가 의도한 내용과는 여러 가지로 다르게 이해하는 사람도 많았고, 가끔은 내용이 잘못 전달되어서 분위기가 험악해지기도 해 내 스타일에는 최대한 풀어서 설명하는 쪽이 낫다는 결론에 도달했다.

p117. 내 의견을 전달하는 일도 중요하지만, 상대방의 의견을 받아들이는 일도 중요하다. 내가 생각하는 내용을 정확하게 전달하는 데에만 몰두해서 상대방 이야기를 제대로 이해하지 않고 넘어가는 일이 없도록 항상 조심하자.

p117. 보통 첫 출근을 하면 HR과 간단한 OJT를 하고, 각 팀에서 온 인솔자와 자리로 간다. 사회성이 좋은 개발자도 있겠지만, 낯을 가리는 개발자도 많기에 스트레스가 쌓이는 경우도 존재한다. 이럴 때는 뭔가 할 일을 주는 편이 좋다. 출근해서 다른 팀원들은 바쁘게 돌아다니는데 혼자 앉아 있으면 별생각이 다 들기 마련이니까. 그래서 팀에 처음 온 분에게 관련 문서 링크를 모아서 메일로 전달한다. 메일에는 환영 인사, 개발 환경 소개, 개발 환경 구축에 관한 온보딩 문서 링크가 들어 있다. 팀에 새로 온 사람이 빨리 적응하도록 기본적인 내용을 모아놓았다. 링크를 따라가다 보면 우리 팀이 무슨 일을 하는지, 팀에서 어떤 기술을 이용하고 있는지를 알게 했다.

p121. 개인적으로는 간단한 셸 스크립트나 RSS 등을 통해서 주요 라이브러리의 새 버전 출시 소식을 항상 접하고 있다.

p122. 개인적으로는 출근하자마자 터미널을 열고 brew update && brew upgrade && brew cleanup 명령으로 하루를 시작한다. 맥에서 이용 중인 개발 관련 프로그램들이 업데이트되는 걸 보면 꼭 CHANGELOG를 확인한다. 특히 CHANGELOG에는 이전 버전과 지금 버전의 차이가 풀 리퀘스트 혹은 이슈 단위로 기록되어 있어 구체적으로 어떤 변경이 있었는지를 확인하는 게 가능하다. 보통 소소한 문제들이 해결되었거나, 반복적인 작업을 줄여주는 기능이 추가되었기 때문에 CHANGELOG를 읽는 버릇만 들여도 큰 도움이 된다.

p127. 프로그래밍은 결국 커뮤니케이션이라고 생각한다. 사람과 컴퓨터의 대화, 같이 일하는 동료들과의 커뮤니케이션에서 시작한다. 그 방법이 코드일 때도 있고, 블로그나 스택오버플로 글이 되기도 하고, 말로 하는 대화가 되기도 한다. 이 글을 읽는 독자가 새로운 지식에 목말라 있고, 항상 더 나아질 방법을 찾는 사람이라면, 프로그래밍에 대해 알아보길 권한다. 꼭 직업으로 개발자를 선택하지 않더라도, 세상과 대화하는 다른 방법을 이해할 수 있을 테니까 말이다.

3부 - 라인에서 새로운 도약을 꿈꾸는 사람들

이홍규 - 블록체인 최고 테크니컬 디렉터의 선택

p133. 시장은 어찌될지 알 수 없기에, 조금 손해를 보는 것 같다고 생각할 때가 오히려 가장 적절한 타이밍이라는 것을 몸소 느꼈다. 이후 여러 스타트업 대표들을 알고 지내며, 그들도 나와 비슷한 경험을 꼭 한 번씩 했다는 이야기를 들었는데, 그 덕분에 내가 상시 기억하게 된 법칙이 되었다.

p134. 아직 성숙하지 않은 시장에서 10보 빠른 시점에 시도한 사업은 성공하기 매우 어렵다는 사실을 이때 뼈저리게 느끼게 되었다. 몸소 체험한 후에야 남들보다 무조건 더 빨리, 먼저 시작하는 게 능사는 아니라는 교훈을 얻게 되었다.

p135. 하지만 좋은 사람들과의 인연은 반드시 새로운 행운을 가져온다. 회사를 정리한 후 입사한 다음 회사에서 나는 이전 회사의 좋은 동료들과 다시 한 번 같이 일할 기회를 가지게 되었다. 우리는 다 함께 한마음으로 꾸준히 회사를 성장시켜나갔고, 그결과 M&A를 통해 exit까지 성공적으로 이루며 유의미한 성과를 거뒀다. 그 어떤 순간에도 가장 소중한 것은 결국 사람이라는 것을 깨닫게 해준 소중한 경험이다.

p144. 라인의 주요 오피스는 한국, 일본, 대만, 태국, 인도네시아, 베트남 등지에 있고 이러한 많은 나라의 사업/개발/기획 담당자들과 함께 소통하며 프로젝트를 협업하며 진행한다. (...) 내가 맡고 있는 프로젝트 중에는 일본과 한국에서 나누어 개발하고, QA는 일본, 중국에서 나누어 진행하는 것도 있다. 그만큼 글로벌하다.

p145. 구글의 CEO였던 에릭 슈미트가 셰릴 샌드버그 (현 페이스북 COO)에게 한 조언이 있다. "로켓에 올라타세요. 회사가 빠르게 성장할 때에는 많은 충격이 있고 커리어는 알아서 성장하게 되어 있습니다. 그런데 회사가 빠르게 성장하지 못하고 회사의 미션이 별로 얘기가 안 될 때에는 정체와 사내 정치가 시작됩니다. 로켓에 자리가 나면 그 자리가 어디 위치했는지 따지지 마세요. 우선 올라타세요." 라인이 메신저 플랫폼에만 머물러 있었다면 로켓이 아닐 수도 있다고 생각한다. 안에 들어와서 보았을 때, 모든 경영진이 현실에 안주하지 않고 도전 정신을 가지고 새로운 시장을 개척해나가고 있는 라인은 분명이 로켓이라고 생각한다. 이 로켓이 달까지 갈지 태양계 밖을 벗어나 먼 우주로 나갈지는 모르지만 나는 라인이라는 로켓에 무조건 올라탔고 가장 멀리까지 날아가기 위해 열심히 도전하고 달려가고 있다.

이승진 - 라인 개발자가 된 세계적 화이트 해커의 이야기

p160. 스타트업은 누구에게나 어렵지만, 특히 엔지니어 성향이 강한 사람들이 모여서 하기엔 매우 어려운 도전이다. 어려운 점은 수백 가지가 있었지만 이 회사를 경영하면서 느낀 문제점 세 가지만 이야기하자면,

1. 직원들의 전문 영역인 기술 능력을 다른 영역에까지 기대하기 된다는 점이다. 당시만 해도 나는 어떤 한 분야를 잘하는 사람이라면, 다른 분야도 잘할 수 있을 거라 생각했는데 그것은 잘못된 판단이었다.
2. 최첨단을 지향하는 해커들이 모여 있다 보니, 엔지니어로서 하고 싶은 연구와 돈을 벌 수 있는 연구와 괴리가 있다는 점이었다. 이것은 업계에서 실력 있는 사람일수록 빠져들기 쉬운 함정이다. 하고 싶은 것과 비즈니스를 위해 해야 할 것은 분명히 다르기 때문이다.
3. 너무 geek한 엔지니어들만 모이면 스타트업 생태계를 꾸리기가 어렵다. 기술도 중요하지만 사업을 추진할 여러 능력도 필요하다.

p168. 실제 우리 팀은 채용을 할 때 지원자의 커뮤니케이션 능력을 가장 우선순위로 보기 위해 노력한다. 기술 능력은 직무를 수행하기 위해 필요한 필수 요소일 뿐이다. 외부와 소통하지 않으며 어두운 곳에서 컴퓨터만 두드리는 해커는 사실 그렇게 많지 않다. 오히려 업계에서 더 좋은 대우를 받는 해커는 사회적인 능력과 함께 기술이 갖춰진 사람들이다.

p170. 서로의 상황에 대해 이해하면 좋은 관계로 프로젝트를 잘 진행할 수 있다. 각자 분야와 개성이 다르고 서로 엔지니어적인 특징을 가진 사람들이 서로의 역할과 목표를 달성하기 위한 과정이 순탄치는 않다는 것, 그럼에도 라인의 직원들은 이를 좋은 방향으로 이끌기 위해 노력한다는 것을 말하고 싶었다. 무엇보다도, 실력이 좋은 엔지니어들과 일하는 것은 축복이다. 다른 모든 단점은 이것으로 상쇄될 수 있다.

김재석 - 성장에 목마른 내가 라인에 온 이유

p179. 밖에 있을 때는 라인이 내부에서 어떤 도구를 사용하는지 궁금했는데, 나중에 들어와서 놀란 점은, 위키와 버그 추적 시스템을 활발하게 활용한다는 점을 제외하면 다른 어떤 마법도 존재하지 않았다는 것이다. 반대로 이야기하면, 잘 기록하고 다른 사람의 기록을 잘 읽는다느느 기본이 기업의 강력한 자산이 될 수도 있다는 뜻이다.

p181. 저성장 중인 소기업은 회사의 규모가 작더라도 스타트업이 아니며, 고성장 중인 대기업은 회사의 규모가 크더라도 스타트업이다. 나는 20대에 작지만 스타트업이 아닌 회사를 많이 만나보았다. 이들은 자신들의 조직이 작기 때문에 스타트업이라고 입을 모아 주장했지만, 시장 규모가 지나치게 작거나, 리더 그룹이 현재의 회사 이익에 충분히 만족하고 있거나, 비전의 부재로 조직력이 빠르게 약화되고 있는 회사들이었다.

p182. 회사에 합류할 때는, 직원으로서 월급을 받기 위해 들어간다는 생각하는 거이 아니라 투자자의 관점에서 회사를 바라보는 것이 좋다. 그런 시야 아래에서는 어떤 회사가 스타트업에 준하는 곳인지 더 명확한 기준을 가질 수 있다. 월급을 받는 것보다 중요한 건 내 시간을 어떤 종목에 투자하고 있는 것인지 정확히 이해하는 것이라고 생각한다.

p183. 결국 좋은 아이디어를 쟁취하는 조직은 아이러니하게도 그 아이디어가 좋은지, 좋지 않은지 불명확한 시점에서 시작하는 경향이 있다.

p185. 100개의 회사가 있다면 100개의 성장 스토리가 있다. 창업 시기, 창업자의 역량, 성향, 자본 등 여러 조건에 맞춰 회사는 자신에게 최적의 성장 전략을 취하고 이는 모두가 제각기 다른 모습을 갖추고 있기 때문이다.

p186. 이제 막 새로 시작한 스타트업은 아무것도 없기 때문에, 그리고 살기 위해 새로운 시장을 찾아 나선다. 어느 정도 시장 내 고객 기반을 갖추게 되면, 그 이후부터는 기존 고객을 중심으로 후속 사업을 구상하게 되고 실제로 이 편이 사업 성장의 성공률이 높은 편이다. 하지만, 그 점이 되려 어느 정도의 시장을 가진 회사가 완전히 새로운 분야를 도전하는 것을 어렵게 하고 심리적으로 발목을 잡는 경향이 있다.

p187. 역할적으로 제한된 브랜치로 글로벌 사업을 전개하는 것은, 비교적 적은 준비가 필요하기 때문에 많은 기업이 취하고 있는 형태다. 하지만 이는 본사의 의존도가 높아지며 여러 한계를 가지게 되기도 한다. 가령 본사에서는 모든 것을 할 수 있는 반면, 지역 브랜치에서는 해당 지역 영업, 혹은 프로그래머가 있더라도 지역 최적화 중심의 업무만으로 범위를 제한하는 회사들이 많다. 이런 구조는 결국 본사 직원과 그 외 지역 직원 사이의 차별을 야기한다.

p188. 회사 전반의 정보가 문서화가 잘되어 있다면 어떤 장점이 있을까? 우선 회사 내 정보 중 휘발되는 것이 거의 없기 때문에 회사 내 활동 경험이 집단적으로 축적될 수 있다. 기록이 없이 사람에 의존하는 회사의 경우, 특정 직원이 회사를 떠남과 동시에 집단적으로 같은 실수를 반복하는 모습을 많이 볼 수 있다. 특히 중요한 프로젝트에서는 이런 일로 때문에 같은 실수를 하느라 시간을 1~2년 낭비하기도 한다. 충실한 문서화의 두 번째 장점은 써보는 문화와 함께 찾아보는 문화 또한 발달하게 된다는 점이다. 정보를 잘 알만한 사람을 찾아서 짊누하는 것보다 위키를 검색해보는 것이 더 빠르고 더 정확한 결과로 이어지기 때문에 검색이 습관화되고 이는 회사 내 정보 교류를 무척 효율적으로 만들어준다. 결국 충실한 문서화 역량은 회사가 새로운 도전을 하는 데 용기를 준다. 문서화를 통해 우리는 실패를 자산화할 수 있기 때문이다. 다음 도전을 할 때 이전의 실패에 대해 복기하고, 그 위에서 새로운 도전을 할 수 있다면 모든 도전은 실패했어도 단지 실패로 끝나는 것이 아니라 다음 성공을 위한 교훈이 될 수 있다.

4부 - 개발자라고 개발만 하나요?

이서연 - 오픈소스 매니저가 일하는 법

p205. 사실 나는 처음에는 의견을 내는 것을 어려워했다. 나보다 경험이 풍부한 사람들의 의견이 옳을 테니 따르는 것이 당연하다고 생각했었다. 그런데 이따금 '왜?'에 대한 의문이 해결되지 않을 때가 있었다. 지금은 최대한 순간 순간의 대화에 집중하고 궁금한 것은 바로 질문하려고 한다. 이렇게 서로에 대한 존중을 바탕으로 한 대화는 언제나 빠르고 오해 없이 의사결정이 이루어진다.

박민우 - 테크 에반젤리스트 그게 뭐죠?

p221. evangelist의 사전적 의미는 '전도사'이다. 그래서 테크 에반젤리스트를 '기술 전도사'로 옮기기도 한다. 최근에는 개발자 지지자 (developer advocate)라고 하기도 한다. 앞에서 썼듯 개발자를 대상으로 기술을 시장에 전파하고 확산하는 역할을 하지만, 기존의 기술 영업처럼 매출 목표를 가지고 있지는 않으며, 마케팅이나 교육 같은 방법을 주로 사용한다. 개발자들을 이해하고 소통해야 하기 때문에 소프트웨어 개발을 할 수 있어야 하지만 코딩보다는 글이나 발표를 통해 기술 공유를 하므로 개발 관련 다양한 커뮤니케이션을 즐기는 사람들에게 적합한 일이다.

p222. 기술 공유를 통해 가장 많이 배우는 사람은 역시 발표자 혹은 글을 쓰는 본인이다. 가르치는 것이 가장 좋은 배우는 방법이라는 말이 있듯이, 내가 안다고 생각해서 글로 정리하기 시작하면 더 많은 것을 정확하게 공부하게 된다. 기술 공유는 다른 사람, 또 나 자신의 성장에 도움이 되는 것은 물론이고, 공유를 통해서 사람들의 의견을 듣고 소통하게 되므로 거기서 다양한 사람과의 관계가 형성된다. 냉철한 피드백을 통해 내가 성장하기도 하고, 그 주제에 대한 비즈니스 기회가 생기기도 하고, 채용으로 연결되기도 한다. 무엇보다 같은 주제에 관심 있는 사람들과 이야기할 기회가 생긴다는 것이 가장 큰 즐거움이다.

p228. 유명 블로거인 변정훈 님은 블로그를 쓰는 이유 중 하나가 '미래의 나 자신을 위해서'라고도 했다. 자신이 지금 공부한 것을 미래에 다시 찾아볼 때 블로그만 한 것이 없으며, 또 에버노트 같은 곳에 메모로 간단하게 적는 것보다 블로그에 적어두어야 나중에 실제로 써먹을 수 있는 형태의 지식이 된다고 한다.

배권한 - 개발자 커뮤니티와 함께 성장하다

p244. 그동안 엔지니어로 일하면서 많은 사람들과 일을 해왔지만 커뮤니티를 경험하기 이전의 나는 주로 받기만 하는 사람이었다. 그저 기술만을 찬양하던 나였지만 커뮤니티를 운영하면서 많은 것을 경험하고 배우게 되었다. 전혀 다른 분야의 사람들과 같이 일하는 방법을 배우게 되었고, 다양한 사람과 함께 일할 때는 다양한 관점이 있음을 알게 되었다. 어떤 일이든 당연한 것은 하나도 없기 때문에, 다른 사람의 입장에서도 생각할 수 있어야 함께 일할 수 있었다. 예전에는 이렇게 생각하지 않아서 힘들 때가 많았다. 하지만 나 자신의 생각을 바꾸고 나니 다른 방식으로 생각을 할 수 있게 된 것 같다. 파이콘에서는 준비위원회가 행사 준비만 하는 것이 아니라 자신이 참가자이자 커뮤니티의 일원이라고 생각한다.

p248. 파이콘 APAC 2017에서 PSF의 이사였던 제시카 매켈러가 발표한 '프로그래머의 마인드'라는 키노트에서였다. (http://bit.ly/33LIuFV) 프로그래밍은 우리가 생각하는 방법을 바꿔서 세상과 소통하고 디버깅할 수 있게 한다. 프로그래머는 시스템을 마스터하게 되고 시스템을 바꾼다. 프로그래밍에는 법칙이 존재하지만, 프로그래머에게는 그 법칙을 바꿀 힘이 있다. 사회도 마찬가지로 하나의 법칙이고 시스템이므로 불만스러운 부분이 있다면, 누군가 먼저 행동함으로써 고치고 디버깅할 수 있다고 본다. 행동한다면 가능하다고 생각한다.