소감

bullet point 형태로 책이 뒤덮여 있다고 해야되나? 모든 구절이 암기할 만한 핵심 요약 포인트처럼 느껴져서 초반부분은 좀 버거웠다. 그러나 곧 이 포맷에 익숙해졌다.

내가 생각하는 좋은 개발자, 좋은 직장인, 좋은 필멸자 마인드셋을 더 구체화한 책이었다. 실제로 이런 식으로 말하고 행동하는 자를 한 명 보고 나니까... 굉장히 여러가지로 느낀 점이 많았다.

핵심은 측정과 회고. 그리고 굳이 하나 더 꼽자면, "이거 꼭 해야돼요?"

좋았던 구절들

서론

어려운 기술 문제가 발생할 때 폴에게 "이 문제를 어떻게 해결할까?" 라고 물어보면 폴은 왜 이걸 우리가 해결해야 하지?"라고 불쾌하게 대단하곤 했다. 그는 불가능해 보이는 문제를 굳이 풀려고 노력하기보다 가정 자체에 의문을 제기해서 간단히 우회할 방법을 찾아낼 때가 많았다. (...) 대부분 그가 옳았다. 우리가 세운 신생 기업의 성패를 좌우하지 않는 프로젝트에 소중한 엔지니어링 자원을 투입할 이유가 없었기 때문이다.

1장. 마인드셋

레버리지 = 생산량/투자시간

레버리지를 늘리는 세 가지 방법 : 투자시간 줄이기, 생상량 늘리기, 레버리지가 높은 활동으로 전환하기

근무 시간을 활용해서 새로운 기술을 발전시켜라 (회사의 코어 코드 읽기, 관심있는 프로젝트 설계 논의에 자발적으로 참석하라, 다양한 프로젝트에 참여하라, 모르는 코드에 뛰어들어라)

목록을 한 곳으로 모아라. 그러면 우선순위 정하기에 집중할 수 있다. 그래야 하는 이유는, 모든 업무의 레버리지를 정확하게 예상하기 어렵기 때문이다. 즉, 계속 계획을 수정해야 하기 때문이다.

일단 성과를 내기 시작하면 회의 불참, 회신 지연, 급하지 않은 버그 수정 연기에 불평하는 사람을 대부분 없어질 것이다.

중요하지만 급하지 않은 활동에 집중하라. 이 활동에 대한 투자 부족이 급한 일들을 근본적으로 처리하는 방법일 수 있다.

일정에 집중하는 시간 블록의 길이를 최대한 길게 유지하라.

"(외부상황)한 순간이 온다면 (액션)할 것이다"라는 식으로 계획을 세워라.

우선순위를 정하는 핵심 기술은 회고를 통해 우선순위를 재정비하는 것이다.

2장. 전략

지속적 배포는 제품의 성장에 중요한 역할을 했다. (...) (기능을 선보이는 방식에 대해) 근본적인 변화가 일어나기 때문이다.

"만약 수동으로 두 번 이상으로 해야 하는 일이 생기면 세 번째에는 도구를 작성하라"

시간 절약 도구를 찾거나 만드는 것으로는 충분치 않다. 그 혜택을 최대로 누리려면 팀에 도구 도입률을 높여야 한다. 그러기 위해 가장 좋은 방법은 그 도구가 실제로 시간을 절약해 준다는 것을 증명하는 것이다.

나는 도입률을 높이기 위해 시간을 더 투자해 빌드 프로세스를 이클립스에 연결했다. 이로써 전환 비용을 낮추고 다른 팀원들도 새로운 시스템을 도입하도록 설득할 수 있었다.

여러분이 만든 도구가 시간을 절약한다는 사실을 증명하면 얻을 수 있는 이점이 또 있다. 관리자나 동료가 앞으로 더 많은 아이디어를 탐색해볼 자율권을 준다는 것이다. (...) 가치를 증명하라.

최대한 빨리 승인을 받는 데 집중하라. 가장 신경 쓰는 부분이 무엇인지 의사 결정권자에게 분명히 물어보고, 관련 세부사항을 제대로 파악하고 구현하라. (...) 승인을 마지막으로 미루지 마라.

좋은 지표는 시간이 흐르는 동안 효율성을 측정하고, 현재 하는 활동과 그 대신 할 수 있었던 활동을 비교할 수 있게 해준다. (...) 현재 내가 하는 일의 진행 상황을 측정할 방법이 있을까? 만약 내가 하는 일이 핵심 지표에 영향을 미치지 못한다면 할 가치가 있을까? 또는 내가 놓치고 있는 핵심 지표가 있을까?

'수정한 버그의 수'보다 '수정하지 않은 버그의 수'가 더 좋은 지표다. 전자는 일부러 쉬운 버그를 만들도록 유도한다. 같은 맥락에서, '등록한 사용자 수'보다 '등록한 사용자 수의 주간 성장률'이 좋은 지표다. 후자를 통해 성장 속도가 둔화되고 있는지를 알 수 있다. 마찬가지로, '주간 활성 사용자'보다 '이번주 가입한 사용자의 활성률'이 좋은 지표다. 후자는 제품의 변화가 새로운 사용자 집단에게 어떤 영향을 미쳤는지 파악할 수 있게 도와준다.

지표는 1) 가장 큰 효과를 내고 2) 실행하기 좋으며 3) 즉각 반응하되 견고한 것이 좋다.

쉴리스에게 데이터 오용으로부터 우리 스스로를 보호할 방법을 묻자, 그는 최선의 방책은 의심이라고 했다.

"지체하지 말고 피드백을 받으세요. 어떤 부분이 효과가 있는지 알아내세요. 그렇게 하는 것이 무턱대고 만들고 전부 제대로 했을 거라 착각하는 것보다 훨씬 나아요. 왜냐하면 전부 제대로 만드는 것은 불가능하니까요."

10%의 노력만으로 유용성을 검증할 수 있다면 베스트다.

피드백을 개방적으로 수용하라. 코드를 일찍, 자주 커밋하라. 철저한 사람에게 리뷰를 부탁하라. 맥락 공유를 위해 (병렬로 하나씩 맡지 말고) 팀 프로젝트로 다같이 하나씩 진행하라. 논란의 여지가 있는 기능은 먼저 승인 받아라.

"(보상을 포함해) 어떤 의사 결정을 내리든 이를 위한 피드백 과정이 있어야 합니다. 피드백 과정이 없으면 그냥... 추측하는 겁니다."

프로젝트를 더 작은 작업들로 분해하라. 추정을 최상의 시나리오가 아닌 확률 분포로 생각하라 ("6주 안에 끝날 확률이 80%"). 인원이 추가된다고 시간이 단축된다고 생각하지 마라 (온보딩 시간 필요). 타임 박스를 정하라 ("조사에 3일 걸릴 것이다" 대신 "3일 내에 찾은 데이터로 최선의 판단을 할것이다"). 다른 이들이 추정에 이의를 제기하도록 허용하라.

명확한 목표가 있으면 "그거 하는 김에 이것도 하면 좋지 않겠어요?"를 막기 쉽다. (...) "해결하려는 문제가 정확히 무엇인지 아주 명확히 해둔 것이 프로젝트 범위에 속하는 것과 그렇지 않은 것을 구분하는 데 도움이 되었습니다."

구체적인 목표를 정의하는 것보다 더 효과적인 것은 목표 달성을 위해 측정할 수 있는 마일스톤을 세우는 것이다. 그러면 "거의 다 했어요" 대신에 "X, Y는 완료되었어요"라고 말할 수 있다. 각각의 마일스톤에 목표 완료일까지 있으면 더욱 좋을 것이다.

가장 위험한 영역부터 처리하면 추정 오류를 찾아내는 데 도움이 된다.

"두 번째 시스템(e.g., 차세대 프로젝트) 은 인간이 설계한 가장 위험한 시스템이다. 일반적으로 두 번째 시스템은 첫 번째 시스템에서 조심스럽게 피했던 모든 아이디어와 장식을 사용해 과하게 설계하는 경향이 있다." (...) 두 번째 시스템은 지나친 자신감 탓에 일정이 지연되기 쉽다.

팀 차원에서 초과 근무를 해야 할 때는 다음 사항을 명심하라. 1) 지금까지 타임라인이 지연된 주요 원인을 모두가 이해하고 공유하라 2) 프로젝트 계획과 타임라인을 현실적으로 수정하라 3) 수정한 타임라인보다 더 지연된다면 전력 질주를 포기하라 (알고보니 마라톤 중간인 경우가 있다)

3장. 장기적 가치에 투자하기

자동 테스트는 코드를 망가뜨릴까 봐 코드 조각을 수정하거나 개선하기를 두려워하는 문화를 바꾼다.

1) 코드를 리뷰하는 문화를 확립하고 2) 좋은 추상화를 통해 어려운 문제를 단순화하고 3) 자동 테스트로 코드 품질을 향상시키고 4) 기술 부채를 관리하라 (가장 큰 이자를 발생시키는 부채에 집중하라)

인스타그램 팀은 설계를 검토할 때 "이것이 가장 간단한가?" 또는 "지금 작성 중인 기능을 위해 완전히 새로운 시스템을 만드는 것이 가장 간단한 방법일까? 라고 물었다. 답이 "아니오"라면 다른 접근법을 떠올렸다.

스티브 잡스는 (...) "문제를 해결하려 시도할 때 처음 떠올리는 해결책은 매우 복잡한데 대부분의 사람들은 거기서 멈춥니다. 하지만 포기하지 말고 문제를 붙들고 양파처럼 껍질을 더 벗겨내다 보면 종종 매우 우아하고 간단한 해결책에 도달할 수 있습니다. 대부분이 거기에 도달할 때까지 시간이나 에너지를 들이지 않는 것뿐입니다."

컴퓨터가 할 수 있는 일을 할 때마다 자동화할 가치가 있는지 자문하라.

존슨은 자동화를 메커니즘 자동화와 의사결정 자동화, 두 가지 유형으로 구분했다. 일련의 단계로 이루어진 메커니즘을 자동화하는 것은 간단하고 테스트하기도 쉽다. 그러나 의사 결정 과정을 자동화하는 것은 매우 어렵다.

멱득성 있게 만들 수 없다면 적어도 일괄 처리를 재시도하거나 (중간 지점에) 재진입할 수 있도록 구성하는 것이 도움이 된다.

어떤 프로젝트를 책임지는 유일한 개발자가 되면 자신의 가치가 올라간다는 잘못된 통념이 존재한다. (...) 여러분이 프로젝트의 병목이라면 다른 작업을 할 유연성이 사라진다. 급하게 처리해야 하는 버그가 더 자주 전달된다. (...) 그저 그 시스템에 관해 가장 잘 아는 사람이라는 이유로 관련 문제에 대응하고 유지보수하고 기능을 수정하고 버그를 수정하는데 꽤 많은 시간을 쏟느라 새로운 것을 배우거나 만들 자유시간을 가지기 어려워진다.

난 항상 지원자에게 이 질문을 던졌다. "XXX의 엔지니어링 문화에서 좋았던 점과 싫었던 점은 각각 무엇이었나요?"

이러한 관점이 레버리지가 높은 활동만 추구해야 한다는 뜻일까? 아니다. 그러면 너무 지칠 것이다. 우리는 여행, 하이킹, 살사댄스, 가족이나 친구와 함께하기 등 다양한 여가 활동을 즐긴다. 그럴 때는 그런 시간이 높은 영향력을 내는지 우리 시간을 최적으로 활용하는 것인지 전혀 신경쓰지 않으며, 또 그렇게 해야 마땅하다. 단, 우리가 직업적 목표나 인생의 목표를 이루는 데 레버리지는 올바른 활동에 집중하게 도와주는 강력한 프레임워크다

여담

이 책은 모 회사의 천재 개발자 E 님과 토의하면서 진행했다. 너무 좋은 시간이었고, 그 분이 (도움이 전혀 안된다고 생각해서) 더이상 참여 안할까봐 열심히 질문을 준비해갔던 것이 기억에 남는다. 그 때 남겨놨던 메모 중 하나를 발췌해본다:

나 혼자만이 이 책의 내용대로 실천하려고 한다면, 업무 외적인 시간까지 쏟을 수밖에 없고, 확신은 없지만… 그렇게 한다면 다른 팀원들이 (유용하다고 느낄경우) 따라올 것이라는 믿음을 가져야 한다. 그렇게 생각한다.