개발자 생산성: 무엇이 10배 차이를 만드나

생산성 차이는 왜 곱으로 벌어지나

달리기나 벽돌 쌓기처럼 선형인 일에서 열 배 차이는 불가능하다. 하지만 프로그래밍은 설계다. 아키텍처를 맡지 않아도 구현하는 순간 「어떻게 구현할지」라는 하위 설계를 한다. 설계에서는 경험·지식·쓸모없는 부분을 알아보는 눈이 더해지는 게 아니라 곱해진다.

그래서 차이는 목표만 주어지고 방법이 열려 있을수록 커진다. 도구와 구현 방식이 정해진 일에서는 국소적인 설계만 바꿀 수 있지만, 목표 중심의 일에서는 경로 자체를 바꾸고 명세 일부를 통째로 없애 같은 목표에 훨씬 적은 노력으로 닿을 수 있다.

10배를 만드는 요소

요소	내용
하위 작업 구현력	함수 하나, 알고리즘 하나를 기본 명령형 구문으로 빠르게 짜는 능력. 이론에 밝은데 구현이 느린 사람보다 정렬 알고리즘도 모르지만 빨리 짜는 사람이 일을 더 끝내기도 한다
경험: 패턴 매칭	반복되는 문제의 이미 검증된 해법 목록. 설계 시간을 줄이고, 단순함의 가장 큰 적인 설계 실수를 막는다
집중: 실제 시간	코드를 쓴 시간이 아니라 그 시간의 질이 중요하다. 내부 요인(미루기, 흥미 부족, 수면·운동 부족)과 외부 요인(잦은 회의, 칸막이 없는 사무실, 끼어드는 동료)을 줄인다
설계 희생: 5%를 버려 90%를 얻는다	핵심이 아닌 목표가 설계 복잡성의 큰 몫을 차지하거나 핵심 목표를 방해하면 그 목표를 버린다. 메시지 브로커 Disque는 메시지 순서를 최선 노력(best-effort)으로만 보장하기로 하자 가용성, 질의 언어, 클라이언트 상호작용, 단순함, 성능이 모두 나아졌다
단순함	복잡성의 두 원인은 설계 희생을 거부하는 것과 설계 실수의 누적이다. 잘못 든 길은 다시 설계되지 않고 그 실수를 감싸는 또 다른 복잡한 해법을 부른다. 머릿속에서 작은 개념 증명을 여러 개 돌려 가장 직접적인 설계에서 출발하고, 복잡한 해법이 필요해 보이면 완전히 다른 대안까지 오래 고민한 뒤에만 그 길로 간다(소프트웨어 복잡성)
완벽주의 경계	측정하기 쉬운 지표(벤치마크 수치)나 남의 평가에 맞춰 설계를 다듬으면 견고함·단순함·납기를 놓친다
지식: 약간의 이론	자료구조, 계산의 근본 한계, 특정 문제에 맞는 알고리즘을 「있다는 것」만이라도 안다. 스트림의 고유 항목 수를 세야 할 때 약간의 오차를 받아들이는 설계 희생과 확률적 카디널리티 추정(HyperLogLog)을 함께 알면 느리고 메모리를 먹는 정확한 해법을 피한다(현실 시스템을 움직이는 알고리즘)
저수준: 기계 이해	CPU, 커널, 시스템 콜의 동작을 모르면 고급 언어에서도 나중에 근본적인 재설계가 필요한 문제를 만든다
디버깅	버그에 대한 정보를 점진적으로 모아 합리적인 단계로 고치는 능력, 그리고 애초에 버그가 적은 단순한 코드를 쓰는 태도(디버깅 사고법)

이 요소들을 합친 실천이 기회주의적 프로그래밍(opportunistic programming) 이다. 매 단계에서 최소 노력으로 사용자에게 최대 효과를 내는 기능부터 고른다.

Bell Labs, 3M, HP의 엔지니어 천여 명을 대상으로 한 연구에서, 관리자와 동료가 함께 고른 「스타」와 평범한 성과자 사이에 IQ·성격·사회성·조직 요인 45가지의 측정 가능한 차이가 없었다. 관리자와 동료가 꼽은 스타 명단은 절반만 겹쳤다. 차이는 머릿속에 든 것이 아니라 그것을 쓰는 방식, 곧 업무 전략에 있었다. 스타는 타고나지 않고 만들어진다.

순위	전략	평범한 성과자의 이해	스타의 실천
1	주도성(blazing trails)	내 일을 더 잘하려고 최신 자료를 공부하는 것, 회식 준비 같은 자잘한 자원봉사	핵심 업무를 끝내면서 직무 기술서 밖의 책임을 맡는다. 동료와 팀을 위한 추가 노력을 한다. 직무 사이의 빈틈에서 생기는 중요한 일을 맡아 끝까지 해낸다. 큰 혁신은 작은 주도의 긴 사슬 끝에 온다
2	누가 아는지 알기(knowing who knows)	소문망, 헤드헌터와의 인맥	누구도 일에 필요한 지식의 50~80%밖에 모른다. 모자란 부분을 메울 전문가와 미리 양방향 관계를 맺는다. 스타의 네트워크는 사람이 맞고, 빠르다. 사내 게시판에 질문을 올려 받은 40개의 서로 모순된 답보다 아는 사람 둘에게 건 전화가 낫다
3	능동적 자기 관리	일정·예산·명세 안에 끝내는 것	그건 월급 받고 하는 기본이다. 스스로 기회를 만들고, 일을 고르고, 회사에 대한 가치를 높일 재능·경험 포트폴리오를 쌓는다
4	큰 그림 보기	내 관점에서 같은 주장을 반복	고객, 경쟁사, 동료, 경영진의 관점을 바꿔 가며 본다. 문제와 해법을 기록하고 다시 읽으며 패턴 인식을 기른다
5	올바른 팔로워십	지시를 군말 없이 따르고 리더를 위협하지 않기	좋은 2인자가 된다. 득점보다 도움이 중요할 때가 많다. 리더에게 문제를 미리 알리고, 의견을 되받아 주고, 결정에 독립적·비판적 판단으로 이의를 제기하면서 조직의 목표를 함께 이룬다
6	공동 소유로서의 팀워크	협조하며 내 몫을 하기	목표 설정, 약속, 일정, 성과를 함께 소유한다. 모두가 팀의 일원이라고 느끼게 하고, 갈등을 다루고, 남의 문제 해결을 돕는다
7	소문자 리더십(small-l leadership)	큰 비전과 카리스마의 대문자 리더십	공식 권한 없이 전문성과 영향력으로 동료를 하나의 과제에 모은다. 동료의 필요·역량·포부를 고려하고, 이미 안다고 생각해도 먼저 묻는다
8	조직 감각(street smarts)	아첨하거나, 사내 정치에 집착하거나 무시하기	큰 조직에는 정당한 이해관계 충돌이 있다는 것을 받아들인다. 갈등을 피할 때와 정면으로 다룰 때를 알고, 잠재적 적을 동맹으로 만든다
9	보여 주고 말하기(show and tell)	화려한 발표와 긴 메모로 경영진 눈에 띄기	어떤 정보를 누구에게 넘길지 고르고, 특정 청중에 맞는 형식으로 설득한다. 청중에 맞는 메시지, 또는 메시지에 맞는 청중을 고른다

신입 시기의 주도는 작아도 된다. 경력이 쌓이면 더 어렵고 위험한 주도를 기대받는다. 성과를 드러내는 구체적인 방법은 일하면서 성장하기, 평판은 평판 쌓기에 있다.

팀의 속도: 스프린트와 마라톤

속도는 하나가 아니다. 단기 속도(스프린트) 와 장기 속도(마라톤) 는 함께 가질 수 없다. 전력으로 한 달 100을 내는 페이스는 수년짜리 제품 개발 거리에서 유지되지 않는다.

모드	모습	결과
극단적 스프린트	하루 12시간 이상, 주말 없이	잠깐 빠르지만 건강과 사람을 잃는다
적당한 스프린트	잦은 야근이 일상	실수와 기술 부채가 쌓여 결국 느려진다
마라톤	하루 6~8시간, 쉬고 운동하고 문제를 곱씹을 여유	지속 가능한 기준 페이스
인터벌	짧은 스프린트 뒤 충분한 마라톤 기간	평균 속도가 마라톤보다 높고, 출시를 이룬 성취감이 동기가 된다

반복 개발(이터레이션)은 작은 마감의 연속이다. 이터레이션에 약속한 스토리를 다 끝내려고 무리하면 큰 마감과 같은 부작용이 난다. 범위를 줄이고 끝내지 못할 스토리를 빼는 것이 맞는 대응이다.

장기 속도를 정하는 요인은 다음과 같다.

방향	요인	내용
높인다	기술과 경험	책을 사 주고, 컨퍼런스에 보내고, 학습 시간을 준다. 주 하루를 학습에 쓰면 단기 속도는 약 20% 줄지만 학습하는 사람이 모이고 떠나지 않는다. 출시 직전이면 미루고 마라톤 구간에서 한다
높인다	도메인 이해	문제 영역을 잘 알수록 잘못 만드는 일이 준다
높인다	리팩터링과 자동 테스트	버릴 프로토타입이나 아무도 다시 고치지 않을 코드가 아니라면 자동 테스트가 장기 속도를 지킨다
깎는다	시스템 복잡성, 기술 부채	부채의 이자는 시간이 갈수록 커진다. 부채 0은 비경제적이지만 쌓이는 속도를 관리한다(기술 부채)
깎는다	느리거나 불안정한 테스트	피드백이 늦어지고 결과를 믿지 않게 된다
깎는다	카우보이 코딩	리뷰·테스트 없이 밀어붙인 코드가 나중의 속도를 빼앗는다
단기만 높인다	마감, 초과 근무	짧게는 효과가 있지만 반복하면 품질과 사람을 잃는다
깎는다	사람 교체가 잦은 팀, 오픈 스페이스, 메신저 알림, 멀티태스킹	모두 집중을 깨뜨린다

집중을 지키는 법

집중 블록 잡기와 알림 줄이기 같은 기본 원칙은 업무 습관에 있다. 여기서는 프로그래머에게 맞춘 조정만 다룬다.

프로그래머용 뽀모도로

뽀모도로는 25분 집중과 5분 휴식을 반복하는 기법이다. 프로그래머에게는 이런 의미가 있다.

집중된 작은 마감의 연속이다. 마감은 동기가 되고, 내 시간을 스스로 통제한다는 감각(자율성)도 동기를 높인다.
뽀모도로 네 개를 묶으면 깊은 작업(deep work) 한 블록이 된다. 처음에는 네 개 한 블록을 목표로 하고, 익숙해지면 하루 8개, 좋은 날 12개(순수 집중 코딩 약 6시간)까지 간다.
시작 전에 할 일을 쪼개 계획한다. 계획이 길면 그것을 첫 뽀모도로로 쓴다. 방해 요소는 두 번째 화면으로 옮기고 휴대폰은 무음으로, 확인은 휴식 시간에 한다. 동료에게 이 기법을 쓴다고 알리면 대개 협조한다.

원래 규칙	프로그래머용 조정
방해받으면 타이머를 처음부터 다시	동료의 짧은 질문에 머릿속에 있는 지식으로 답하고 여전히 집중 상태라면 리셋하지 않는다. 리셋 자체의 짜증이 방해보다 크다
뽀모도로 개수로 하루를 잰다	개수는 코드 줄 수처럼 생산성 지표가 아니다. 회의·메일·대화·리뷰도 팀에 필수인 일이다
하루 할당량을 지킨다	남을 돕는 역할(리드, 도메인 전문가)이 되면 코딩 할당량을 4개 정도로 낮춘다. 리드의 일은 코드로 문제를 푸는 것만이 아니라 남을 돕는 것이다
모든 일에 쓴다	짧은 집중이 필요한 혼자 하는 일에 가장 잘 맞는다. 몰입(flow)이나 협업이 필요한 일에는 안 맞는다. 다만 회의·발표·페어 프로그래밍의 시간 상자로는 쓸 만하다

집중을 지키는 태도

원칙	내용
한 번에 하나	여러 일을 동시에 시작하지 않는다. 지쳐서 일하면 실수가 늘고 전환 비용으로 시간을 잃는다. 너무 피곤해서 코드를 못 짜겠으면 잔다
머리를 비우고 시작	일하기 전과 점심시간에 SNS·메일을 보지 않는다. 보면 새 걱정거리가 머리에 들어온다
초심자의 마음	전문가라도 매일 초심자처럼 기술을 본다. 고침을 받아들이기 쉽고, 경험 없는 사람의 좋은 생각도 보인다
자아를 내려놓기	기술은 자랑거리가 아니다. 자아가 강한 프로그래머는 배우지 않는다. 고수에게서도 초보에게서도 배운다
할 말이 없으면 말하지 않기	동료의 시간을 낭비하지 않는다. 좋은 생각이 나오면 내 것이 아니어도 지지한다
다른 일도 하기	프로그래밍 밖의 활동(운동, 취미)이 시야를 넓히고 머리를 쉬게 한다

정리

프로그래밍은 설계라서 개인 차이가 곱으로 벌어진다. 방법이 열린 일일수록 더 그렇다.
가장 큰 지렛대는 설계 희생과 단순함이다. 핵심 아닌 5%를 버리고, 설계 실수를 덧대지 말고 되돌린다.
스타와 평범함의 차이는 재능이 아니라 업무 전략이다. 주도성, 아는 사람 네트워크, 큰 그림, 팔로워십과 소문자 리더십.
팀 속도는 마라톤을 기본으로 하고 스프린트는 짧게, 회복과 함께 쓴다. 기술 부채·느린 테스트·잦은 인력 교체가 장기 속도를 깎는다.
집중은 지키는 것이다. 뽀모도로는 도구일 뿐이니 규칙보다 집중 상태를 기준으로 조정한다.

버그 제보