만든 것보다 쓴 것이 먼저 오는 페이지입니다. 제가 관여한 저장소와 회사 이름은 아래 글 속에서 필요할 때만 나옵니다.
무엇을 만들 줄 아는지는 코드가 말해 줍니다. 무엇을 아는지는 결국 설명해 봐야 알게 되더군요. 그래서 배운 것을 그때그때 적습니다. 틀린 글도 지우지 않고 위에 정정만 붙여 둡니다.
리뷰 대기 시간이 평균 32시간까지 늘었을 때, 우리는 먼저 사람을 의심했습니다. 알림을 늘리고, 당번을 정하고, 회고에서 서로를 채근했습니다. 아무것도 나아지지 않았습니다.
숫자를 다시 봤을 때 눈에 들어온 것은 변경 줄 수였습니다. 400줄이 넘는 PR의 평균 대기 시간은 400줄 미만의 여섯 배였습니다. 리뷰어는 미루고 있던 것이 아니라, 40분짜리 작업을 여는 것을 미루고 있었습니다.
그래서 규칙을 하나만 바꿨습니다. 400줄이 넘으면 나눠 올린다. 강제하지 않고 봇이 코멘트만 달게 했습니다. 두 달 뒤 대기 시간은 9시간이 됐습니다.
덧붙임(2026.07) — 이 글을 읽은 분이 "우리 팀은 줄 수보다 파일 수가 문제였다"고 알려 주셨습니다. 맞는 지적입니다. 요지는 줄 수가 아니라, 리뷰를 미루게 만드는 비용이 무엇인지 각 팀이 직접 재 봐야 한다는 것입니다.
타입을 붙이면 주석이 필요 없다는 말을 오래 믿었습니다. 실제로 인자의 모양과 반환값은 타입이 훨씬 정확하게 말해 줍니다. 주석은 낡지만 타입은 컴파일러가 지켜 주니까요.
그런데 타입이 절대 말해 주지 않는 것이 있습니다. 왜 이 함수가 존재하는지, 왜 이 순서여야 하는지, 어떤 경우에 쓰면 안 되는지. `Promise<void>`는 이 함수가 실패하면 어떻게 되는지 한 글자도 알려 주지 않습니다.
지금은 이렇게 나눕니다. 무엇인지는 타입이, 왜인지는 주석이. 그리고 왜를 못 적겠으면 대개 설계가 덜 된 것이었습니다.
가장 많이 본 회고의 마지막 줄은 "확인 절차를 강화한다"였습니다. 그 문장이 쓰인 뒤 같은 장애가 다시 난 경우를 여러 번 봤습니다.
사람은 대체로 그 순간 합리적으로 보이는 선택을 합니다. 그러니 물어야 할 것은 "왜 확인하지 않았나"가 아니라 "왜 확인하지 않는 편이 그때는 더 그럴듯했나"입니다. 배포 창이 좁아서였는지, 알림이 너무 많아 무뎌져서였는지, 롤백이 무서웠는지.
회고에서 이 질문을 하기 시작하자 조치 항목이 달라졌습니다. "강화한다" 대신 "롤백을 3분 안에 끝나게 만든다" 같은 것이 남았습니다.
한동안 이슈함을 열지 못했습니다. 열면 답해야 하고, 답하려면 코드를 다시 읽어야 하고, 그럴 시간이 없다는 사실을 확인하게 되니까요. 그렇게 쌓인 이슈가 200개가 넘었을 때 저장소를 접을 생각까지 했습니다.
결국 한 것은 답장이 아니라 고지였습니다. README 맨 위에 지금 이 프로젝트에 쓸 수 있는 시간이 주당 두 시간이고, 그래서 어떤 종류의 이슈에 먼저 답하는지를 적었습니다.
놀랍게도 이슈가 줄지는 않았지만, 화가 난 사람은 거의 사라졌습니다. 사람들이 견디지 못했던 것은 느린 답장이 아니라 예측할 수 없는 침묵이었습니다.
응답 시간을 800ms에서 200ms로 줄인 뒤, 저는 120ms를 향해 2주를 더 썼습니다. 아무도 요구하지 않았고, 아무도 체감하지 못했습니다.
지금은 시작하기 전에 세 줄을 먼저 적습니다. 지금 얼마인가, 얼마가 되면 충분한가, 그 판단의 근거는 무엇인가. 세 번째 줄이 가장 어렵습니다. 대개 근거는 사용자 쪽에 있는데 우리는 대시보드만 보고 있기 때문입니다.
충분함을 숫자로 적어 두면 개선은 끝날 수 있는 일이 됩니다. 끝낼 수 없는 일은 결국 다른 일을 잡아먹습니다.