Cal Newport의 Slow Productivity를 읽은 건 작년 가을이다. 팀 시니어가 추천해줬다. "이거 한 번 읽어봐, 너한테 필요한 내용이 있을 거야." 읽었다. 핵심은 세 가지. 적은 일을 하되, 자연스러운 페이스로 하고, 퀄리티에 집착하라.

책을 덮고 이틀 동안 생각했다. 좋은 말이다. 근데 이 사람은 미국 대학 교수다. 자기 시간을 자기가 통제할 수 있는 사람이다. 나는 서울의 스타트업에서 일하는 2년 차 프론트엔드 개발자다. 스프린트는 2주고, PM은 "빠르게"를 입에 달고 살고, 슬랙은 24시간 울린다.

그래도 시도해봤다. 4개월 동안. 어떤 건 살아남았고 어떤 건 첫 주에 죽었다.

첫 번째 원칙이 충돌한 곳#

Newport의 첫 번째 원칙은 "적은 일을 한다(Do fewer things)"다. 동시에 진행하는 일의 수를 줄이라는 거다. 수학적으로도 맞는 이야기다. 세 개의 작업을 병렬로 하면 컨텍스트 스위칭 비용이 생기고, 각각의 진행 상황을 추적하는 것 자체가 인지 부하가 된다.

11월 첫째 주. Jira 보드에서 내 "In Progress" 티켓을 세봤다. 7개. API 연동 작업 2개, 버그 수정 2개, 디자인 QA 1개, 문서 작성 1개, 레거시 마이그레이션 1개. 매일 아침 스탠드업에서 7개의 상태를 보고했다. "이건 진행 중이고, 이건 블로킹이고, 이건 대기 중이고..." 보고하는 것만으로 15분이 지나갔다.

WIP(Work in Progress)를 3개로 제한하기로 했다. 팀 리드와 이야기했다. "내 WIP 제한을 3으로 하고 싶다." 의외로 쉽게 수락됐다. "좋은 생각이야. 나도 예전에 그렇게 했었어."

첫째 주는 괜찮았다. 3개에 집중하니까 하루에 하나는 확실히 마무리됐다. 이전에는 7개를 왔다 갔다 하면서 하나도 못 끝내는 날이 많았다.

문제는 둘째 주에 터졌다. 프로덕션에서 결제 관련 버그가 나왔다. PM이 슬랙에 올렸다. "이거 오늘 안에 핫픽스 나가야 합니다." WIP가 이미 3개인데 4번째 일이 들어온 거다. "적은 일을 한다"는 원칙을 지킬 것인가, 프로덕션 이슈를 잡을 것인가. 당연히 프로덕션 이슈를 잡았다. WIP 4개.

그 주에 핫픽스가 두 건 더 나왔다. WIP는 6개가 됐다. 원래로 돌아간 거다.

이 경험에서 배운 건 이거다. "적은 일을 한다"는 원칙은 내가 통제할 수 있는 일에서만 작동한다. 프로덕션 이슈, 급한 비즈니스 요청, 다른 팀의 블로킹 이슈 같은 건 내가 통제할 수 없다. 한국 스타트업에서 "그건 제 WIP 제한에 포함되지 않습니다"라고 말하는 건, 이론적으로는 맞지만 현실에서는 "이 사람 무슨 소리야" 소리를 듣는다.

살아남은 전략: 기본값을 바꾸기#

그래서 원칙을 수정했다. "항상 적은 일을 한다"가 아니라, "기본값을 적은 일로 설정한다."

평상시에는 WIP 3개를 유지한다. 급한 일이 터지면 기본값을 깨고 대응한다. 불이 꺼지면 다시 기본값으로 돌아온다. 핵심은 '돌아오는' 거다. 예전에는 불이 꺼진 뒤에도 WIP가 높은 상태로 유지됐다. 핫픽스 끝났는데도 "이참에 이것도 같이 하자"고 다른 작업을 추가해버리는 습관이 있었다.

기본값을 3으로 설정해두면, 불 끄고 나서 "아, 다시 3개로 돌아가야지"라는 의식이 생긴다. 완벽하지는 않다. 근데 기본값이 없을 때보다 확실히 WIP가 낮게 유지된다.

Derek Sivers가 쓴 글에 비슷한 이야기가 있다. "If you're not saying 'Hell yeah!', say no." 새로운 일이 들어왔을 때, 그게 진짜 지금 해야 하는 건지 질문하라는 거다. "이거 지금 해야 하나?"라고 한 번만 물어봐도 상당수의 일이 걸러진다. "급하지 않은데 급한 척하는" 일이 생각보다 많다.

물론 한국 스타트업에서 "그건 hell yeah가 아닌데요"라고 말하면 좀 이상하다. 대신 나는 이렇게 표현한다. "이거 이번 스프린트에 꼭 들어가야 하는 건가요, 아니면 다음 스프린트에 넣어도 되나요?" 같은 질문이 충분히 받아들여진다.

두 번째 원칙이 충돌한 곳#

Newport의 두 번째 원칙은 "자연스러운 페이스로 일한다(Work at a natural pace)"다. 스프린트가 끝날 때마다 탈진하면 다음 스프린트 퍼포먼스가 떨어지니까, 지속 가능한 속도로 일하라는 거다.

여기서 한국 스타트업 문화와 정면으로 부딪힌다.

"빠르게"는 한국 스타트업의 기본 언어다. "빠르게 실행하고 빠르게 실패하라." "속도가 경쟁력이다." 스프린트 회고에서 "이번 스프린트 속도가 좀 느렸어요"라는 말이 나오면 긴장감이 도는 분위기. "느리다"는 거의 욕이다.

12월에 시도한 게 있다. 스프린트에 티켓을 넣을 때 평소보다 20%를 줄여봤다. 보통 스프린트에 13포인트를 가져갔는데, 10포인트만 가져갔다. 이유를 물으면 "코드 퀄리티에 더 시간을 쓰고 싶다"고 했다.

결과는 복합적이었다.

좋았던 것: PR 올리기 전에 코드를 한 번 더 읽을 여유가 생겼다. 변수명이 명확한지, 불필요한 복잡도가 없는지, 미래의 내가 이해할 수 있는지. 10분 정도 더 쓰는 건데, 리뷰에서 받는 코멘트가 확 줄었다. 리뷰어의 시간을 아끼는 셈이다. PR도 작게 쪼개게 됐다. 이전에는 기능 하나를 통째로 개발하고 변경 파일 20~30개짜리 PR을 올렸는데, 여유가 생기니까 자연스럽게 작은 단위로 나누게 됐다. 리뷰가 빠르고 머지 충돌도 거의 안 난다.

안 좋았던 것: PM이 "이번 스프린트 벨로시티가 떨어졌는데, 괜찮아요?"라고 물어왔다. 수치상으로 줄었으니까 당연한 질문이다. "퀄리티에 시간을 더 쓰고 있다"고 설명했지만, 퀄리티는 수치로 보여주기 어렵다. 벨로시티는 숫자로 보이지만, "리뷰 코멘트가 줄었다"거나 "버그 발생률이 떨어졌다"는 건 증명이 느리다.

이게 "자연스러운 페이스"를 적용할 때의 진짜 어려움이다. 느린 게 장기적으로 빠르다는 건 맞는데, 스프린트 단위로 성과를 측정하는 환경에서 "장기적"이라는 말은 설득력이 약하다. 스프린트 회고는 2주마다 오고, "3개월 후에 결과가 나올 거예요"는 받아들여지지 않는다.

세 번째 원칙만 살아남았다#

Newport의 세 번째 원칙은 "퀄리티에 집착한다(Obsess over quality)"다. 세 가지 중에서 이것만 거의 온전히 살아남았다.

이유가 있다. 퀄리티 향상은 속도를 크게 희생하지 않으면서도 실천할 수 있기 때문이다. PR 올리기 전에 10분 더 투자하는 건, 스프린트 벨로시티에 거의 영향이 없다. 근데 그 10분이 리뷰어의 30분을 아끼고, 나중에 터질 버그를 막는다.

구체적으로 바꾼 습관 세 가지가 있다.

커밋 전에 diff를 읽는다. git diff --staged를 습관적으로 확인한다. "이 변경이 왜 필요한가?"를 스스로 질문한다. 이 단계에서 불필요한 console.log 제거, 의미 없는 변경 되돌리기, 주석 업데이트 같은 작은 것들을 잡는다. 30초짜리 습관인데 효과가 크다.

"일단 돌아가면 됐지"를 경계한다. 예전에는 기능이 동작하면 바로 PR을 올렸다. 지금은 한 번 더 물어본다. "이걸 6개월 뒤에 내가 다시 봤을 때 이해할 수 있나?" PR 설명에 "TODO: 나중에 리팩토링"이라고 적어놓고 한 번도 돌아가지 않은 게 몇 개인지 모른다. 그래서 TODO를 적고 싶은 충동이 들면, 차라리 지금 5분 더 써서 정리한다.

PR 크기를 작게 유지한다. 변경 파일이 10개를 넘으면 쪼갤 수 있는지 먼저 생각한다. 작은 PR은 리뷰어가 제대로 읽는다. 큰 PR은 "뭐 잘 했겠지" 하고 LGTM을 찍는다. 사실상 리뷰가 안 되는 거다. 작은 PR을 자주 올리면 매일 "뭔가를 완료했다"는 피드백을 받는다. 이 성취감 사이클이 페이스를 유지하는 데 도움이 된다.

빠르게의 함정#

Slow Productivity를 시도하면서 "빠르게"에 대해 다시 생각하게 됐다.

바쁜 것과 생산적인 것은 다르다. Newport가 쓴 표현으로는 "pseudo-productivity(가짜 생산성)." 슬랙에 항상 온라인이고, 커밋 그래프가 초록색으로 가득하고, 스프린트에 티켓이 많으면 일 잘하는 개발자라는 공식. 이 공식을 나도 믿었다. 스탠드업에서 "어제 이것저것 했어요"라고 말하면 뿌듯했다. 할 일 목록이 길수록 내가 가치 있는 사람인 것 같았다.

작년 10월에 그 공식이 깨졌다. 프로젝트 사이의 3일 텀이 있었는데, "허투루" 보내기 싫어서 코드베이스의 eslint 룰을 전면 정리하겠다고 했다. 이틀 동안 설정을 만지고 수백 개의 warning을 수정했다. 금요일에 PR을 올렸는데 변경 파일이 47개. 리뷰하는 사람이 기겁했고, 다른 팀원의 PR과 머지 충돌이 8건 터졌다. 그 해결에 또 시간이 날아갔다.

바빴다. 근데 생산적이지 않았다. 오히려 마이너스였다. 그 3일을 다음 프로젝트의 요구사항을 미리 읽는 데 썼으면 훨씬 나았을 거다. 아니면 그냥 쉬었으면 더 나았을 거다.

11월에도 비슷한 실수를 했다. 스프린트 중간에 "시간이 남아서" 공통 컴포넌트 라이브러리의 메이저 버전을 업그레이드했다. Breaking change. 다른 팀원들의 브랜치에서 빌드가 깨졌다. 수습에 반나절이 날아갔다.

두 경우 모두, "바빠 보이기 위한" 일이었다. Sivers가 쓴 글에 이런 문장이 있다. "Successful people have narrow focus, protect themselves against time-wasters, and say no to almost everything." 좁은 집중, 시간 낭비 차단, 거의 모든 것에 거절. 나는 반대를 하고 있었다. 넓은 분산, 시간 채우기, 모든 것에 수락.

4개월의 결산#

Slow Productivity를 한국 스타트업에서 100% 적용하는 건 불가능했다. 정직하게 말하면 절반도 안 됐다.

급한 핫픽스가 터지면 "적은 일을 한다"는 원칙이 무너진다. 릴리즈 일정이 타이트하면 "자연스러운 페이스"는 사치다. PM이 "다음 주까지 무조건 나가야 해요"라고 하면 야근을 해야 한다.

근데 기본값을 바꾼 건 의미가 있었다. 기본 WIP를 3으로 설정하고, 기본 PR 크기를 작게 유지하고, 기본적으로 코드를 한 번 더 읽는 습관. 이 기본값들이 급한 일이 없는 날의 70%를 더 낫게 만들었다.

Newport의 책에서 가장 오래 남는 문장이 있다. "항상 전력 질주하는 사람은 정말 급할 때 더 빨리 뛸 수가 없다. 이미 최대 속도니까." 70%로 달리다가 필요할 때 100%를 쓰는 게 장기적으로 지속 가능하다. 4개월의 경험으로는, 이전보다 야근이 줄었고, 일에 대한 스트레스가 줄었고, 코드 퀄리티는 올라갔다. 숫자로 증명하기 어려운 것들이다. 체감은 확실하다.

한국 스타트업에서 Slow Productivity는 책에 나오는 대로는 안 된다. 근데 부분적으로, 기본값으로, 틈새에서 적용하면 조금씩 작동한다. 조금씩이 모이면 꽤 큰 차이가 된다. 이건 아직 실험 중이라 확신은 없다. 앞으로 어떻게 될지는 더 해봐야 알 거다.