라인의 개발자들 이야기인데, 프로그래밍 관련 얘기는 아니고 에세이 같은 것이다. 개발자뿐만 아니라 테크 에반젤리스트, 기획자 등의 이야기도 있다.
라인에서는 장애가발생한 직후부터 이미 장애 리포트가 작성되고 근거 자료의 취합이 진행될 뿐만 아니라, 장애 리포트를 공유하는 미팅도 가능한 한 많은 사람과 함께 갖는 문화가 있다. 메일로 장애 리포트가 담긴 위키 주소를 공유하고 장애 공유 미팅을 하면서 사람들은 새로운 아이디어를 내고 장애가 반복되지 않도록 시도할 만한 아이디어들을 제시한다. 같은 배를 타고 있는 동료로서 목적지까지 더 잘 갈 수 있도록 서로를 돕는 이상적인 모습이라고 느꼈다. p. 27
기존에 근무시간 위주로, 이메일 중심으로 이뤄졌던 비동기 커뮤니케이션에서, 수시로 울리는 메신저를 보며 즉각 답하는 실시간 커뮤니케이션으로 전환해야 했는데, 적응하기가 만만치 않았다. 매우 빠르게 이뤄지는 정보 교환과 의사결정이 장점이라면, 업무 집중도가 낮아지고 몰입을 방해한다는 단점도 있었다. -p. 54
여러 국가에서 서비스를 출시하면서 얻은 가장 중요한 교훈을 결론부터 말하자면, 좋은 기능을 가진 서비스를 출시하면 자연스럽게 유저들이 증가할 것이라는 가정이 틀렸음을 인정해야 한다는 것이었다. -p. 62
효율적인 테스트를 위해 유저의 반응을 즉각 파악할 수 있을 정도의 기능을 최소화한 서비스를 빠르게 출시한다. 유저의 반응을 다시 데이터를 통해 분석하고, 설정한 가설의 타당성 여부를 검정한다. 소위 말하는 스로스 해킹이나 린 스타트업 같은 접근법이었다. 가설을 설정하고 실험을 통해 결과를 측정하고 비교하는 과학적 접근 방법을 적용한다면, 서비스 개발과 성공적인 운영뿐만 아니라 피드백 루프까지도 보완할 수 있을 것이라 생각했다. -p. 64
기능 출시 후 반드시 측정이 뒤따라야 한다는 생각도 팀 전체에 공유되었다. -p. 65
팀으로서 같이 따를 원칙과 실천을 정리해놓은 방대한 문서였다.누구든 팀의 프로세스와 프로젝트의 기술적인 얼개를 이해하고 체득할 수 있도록 도와주기 위한 신입 가이드 문서
실제 코드나 기술을 도입하는 데 필요한 배경, 설계, 구현 계획을 담아놓은 테크 스펙
코드를 고치고 정기적으로 배포할 때의 모든 절차를 나열한 가이드
비상 상황에서 참고할 지표(metric) 대응 범위, 행동 방침을 합의해서 규정해 놓은 팀 문서… 가이드들에 담긴 원칙을 끊임없이 참고하고 회고 한다. 지표를 설정해서 지난 실천을 수치화하고 반성하며, 앞으로의 피드백을 공고히 하기 위한 시간도 매일 그리고 매주 함께한다. -p. 85
'고맥락 문화(hight context culture)'라는 단어를 찾았다. 의사소통이 실제로 표현한 내용을 기준으로 이루어지는지, 아니면 여러 다양한 맥락을 고려해서 이루어지는지를 기준으로 고맥락과 저맥락을 구분한다는 개념이다. 인류학자 에드워드 홀이 주장한 내용인데, 일하면서 비슷한 상황을 많이 겪다 보니 기억에 남는 개념이 됐다. 어떤 사람을 한 가지 스타일로 정의할 수 없듯, 나도 상황에 따라 고맥락/저맥락 커뮤니케이션을 하지만, 일을 할 때는 주로 저맥락에 가까운 형태로 의사소통을 하는 편이다. 반면 회사에서는 고맥락 커뮤니케이션을 하는 사람도 흔하게 볼 수 있다. 이 과정에서 서로 이해하는 내용이 달라지는 문제가 생긴다. 상대방의 고맥락을 기준으로 표현한 내용을 내가 저맥락으로 이해한다든가, 그 반대의 상황이 벌어지는 경우가 자주 있었다. 이러다 보니 내 의도를 표현하려면 많은 노력이 들었다….
… 내 스타일에는 최대한 풀어서 설명하는 쪽이 낫다는 결론에 도달했다. 개인적인 이야기를 할 때야 그럴 필요는 없겠지만, 일과 관련해서는 최대한 주변 상황을 설명하고 그 결과 내가 어떤 과정을 거쳐 이런 결론을 내렸는지 일일이 설명하는 방법을 선택했다. 이야기가 길어지고, 끝까지 듣기 전에는 내가 무슨 말을 하려고 한 건지 알기 어렵다는 문제가 있지만 그래도 내 경우 이 방법이 편했다.
어떤 방법을 선택하더라도 상대방이 내 의도를 이해했는지 한 번 더 확인하는 과정을 거치도록 하자. 업무 진행 과정에서 한쪽은 다 설명했다고 생각했는데 받아들이는 쪽은 설명이 부족하다고 느끼는 상황은 자주 일어난다. .. 내가 생각하는 내용을 정확하게 전달하는 데에만 몰두해서 상대방 이양기를 제대로 이해하지 않고 넘어가는 일이 없도록 항상 조심하자. p. 115~117
CHANGELOG에는 이전 버전과 지금 버전의 차이가 풀 리퀘스트 혹은 이슈 단위로 기록되어 있어 구체적으로 어떤 변경이 있었는지를 확인하는게 가능하다. 매일 작업을 하며 젠킨스를 이용해 여러 가지 리포트를 생성하고 있다. Dependency-Check를 통해 혹시 보안 문제가 있는 라이브러리 버전을 이용하고 있는 건 아닌지, 테스트가 실패하는지 등을 확인한다. 테스트가 주요한 로직을 커버하면 새 라이브러리를 적용할 때도 부담이 덜하다. -p 122
CHANGELOG, README를 읽는 습관만으로도 평소 작업에서 생각보다 많은 시간을 절약할 수 있다. -p. 123
시장은 어찌될지 알 수 없기에 조금 손해를 보는 것 같다고 생각할 때가 오히려 가장 적절한 타이밍이란 것을 몸소 느꼈다. -p. 133
해킹을 당할 수는 있지만, 당하더라도 회복이 가능한 사업이 되도록 보안 아키텍처를 구상하는 것, 그리고 이것이 라인의 모든 서비스에 정착할 수 있도록 문화로 만들고 싶다. -p. 171
저성장 중인 소기업은 회사의 규모가 작더라도 스타트업이 아니며, 고성장 중인 대기업은 회사의 규모가 크더라도 스타트업이다. -p. 181
기술 공유를 통해 가장 많이 배우는 사람은 역시 발표자 혹은 글을 쓰는 본인이다. 가르치는 것이 가장 좋은 배우는 방법이라는 말이 있듯이, 내가 안다고 생각해서 글로 정리하기 시작하면 더 많은 것을 정확하게 공부하게 된다. -p. 222