3일 코드 리뷰 문제 (그리고 실제로 당신이 부담하고 있는 비용)

Source: Dev.to

A developer posted this on Reddit recently:

“People often take around a week to review my changes… having to wait half a sprint is pretty insane in my opinion.”

Their team runs two‑week sprints, and reviews take a week. They suggested a “same‑or‑next‑day” turnaround and got “interesting looks from a couple people, like I was saying something crazy or being unreasonable.” When they asked their teammates how long reviews should take, most said “3‑4 days.” The thread that followed had over 50 responses.

What struck me wasn’t the advice—it was how wildly different “normal” looks across teams.

---

최근 한 개발자가 Reddit에 올린 글:

“사람들이 내 변경 사항을 검토하는 데 보통 일주일 정도 걸려요… 스프린트 절반을 기다려야 한다는 건 제 생각에 꽤 미친 짓이에요.”

그들의 팀은 2주 스프린트를 진행하고, 리뷰는 일주일이 걸립니다. 그들은 “당일 혹은 다음 날” 검토를 제안했지만 “몇몇 사람들은 내가 미친 짓을 하거나 비현실적인 요구를 하는 것처럼 흥미로운 표정을 지었다.” 라는 반응을 받았습니다. 팀원들에게 리뷰가 얼마나 걸려야 하는지 물었을 때, 대부분은 **“3~4일”**이라고 답했습니다. 그 뒤에 이어진 스레드에는 50개가 넘는 답변이 달렸습니다.

내가 놀란 건 조언 자체가 아니라, 팀마다 “보통”이 얼마나 다르게 보이는가였어요.

가능한 것과 받아들여지는 것 사이의 격차

리뷰를 우선시하는 팀

“우리 팀은 같은 날 혹은 다음 날에 처리하고, 가능한 한 작고 집중된 변경 세트를 선호합니다.”
“팀 리더로서 리뷰를 받으면 한 시간 안에 완료하려고 합니다. 이것은 제 직무 설명에 포함되어 있으며 팀 속도에 영향을 줍니다.”
“제 Jira 지표는 모든 클라이언트 회사에 대해 20시간 미만(오픈에서 머지까지)이며, 여기에는 코멘트 처리, 변경 요청, 잠재적 재작업이 포함됩니다.”

느린 기준을 가진 팀

“예전 팀은 같은 날에 끝냈습니다. 그 다음 팀은 일주일이 걸렸고, 지금 팀은 2‑3일이 보통입니다.”
“현재 계약을 시작했을 때 리뷰는 1‑3주가 걸렸습니다.”

같은 산업. 같은 종류의 일. 완전히 다른 기대치.

대기 비용의 실제

한 답변이 이를 요약했습니다:

“어떤 대기라도 나쁘며 여러 면에서 비용이 듭니다—컨텍스트 전환, 병합 충돌, 버그를 작성 후 15분이 아니라 일주일 뒤에 발견하는 경우 등.”

원 게시자는 실제 영향을 이렇게 설명했습니다:

“나는 다른 팀원보다 빠르기 때문에, 이 팀에서 내 MR이 마치 기차 차량처럼 쌓여요… 나는 실제로 새로운 작업을 잡는 것을 피하고 있습니다. 컨텍스트 과부하를 피하려면 현재 진행 중인 일을 마무리해야 하니까요.”

다시 읽어보세요. 개발자는 리뷰 프로세스가 따라가지 못하기 때문에 의도적으로 속도를 늦추고 있습니다. 그는 깨진 시스템을 보완하기 위해 자신의 처리량을 관리하고 있습니다.

다른 답변은 이 문제를 더 넓은 연구와 연결했습니다:

“많은 조직에 큰 문제이며, 이를 해결하면 이득이 있습니다 (참조: Accelerate by Dr. Forsgren).”

Accelerate 연구()에 따르면, 엘리트 팀은 커밋부터 프로덕션까지의 리드 타임을 시간 단위로 측정합니다—몇 주가 아니라 말이죠. 리뷰만 해도 3‑4 일이 걸린다면, 이미 고성능 팀이 엔드‑투‑엔드로 달성하는 수준을 초과한 것입니다.

고성능 팀이 실제로 하는 일

리뷰를 차단 요소로 다루고, 백로그 항목이 아니라

“PR은 차단 요소로 간주하고 가능한 빨리 처리해야 합니다.”
“제가 참여한 최고의 팀에서는, 추가 코드를 작성하기 전에 하루를 시작할 때 보류 중인 MR을 검토하는 것이 지침이었습니다.”

명시적인 시간 합의를 갖는다

“대부분의 코드 리뷰에 대해 24시간 내 회신을 기대합니다.”
“필수 리뷰어에게는 각 반복마다 24시간 회신을 기대합니다… 24시간이 지나면 알림이 발송됩니다.”
“최대 4시간. 그 이후에는 리뷰를 위해 사람들에게 DM을 보냅니다.”

변경을 작고 검토 가능하게 유지한다

“커밋 크기를 줄이는 법을 배웠습니다. 이제 제 커밋은 … 모든 변경을 하루 안에 검토합니다. 티켓과 변경을 작게 유지해 읽고 이해하기 쉽도록 합니다.”

리뷰를 업무의 일부로 만들고, 방해가 되지 않게 한다

“우리는 모든 머지 요청에 대해 같은 날 코드 리뷰를 진행하며, 제출 후 1시간 이내에 완료하는 것을 목표로 합니다. 우리 모두 코드가 머지되기 때문에, 다른 사람에게 리뷰를 받는 것이 우리에게 필요한 만큼 중요합니다. 결국 평균적으로 맞춰집니다.”

왜 아무것도 변하지 않는가

스레드에서 가장 솔직한 관찰:

“상황은 비현실적이지만, 동시에 불안할 정도로 정상적이며 조직은 증거가 아무리 많이 나와도 그들의 부실한 프로세스를 벗어나기가 매우 느리다.”

팀들은 긴 리뷰가 해롭다는 것을 알고 있다. 많은 사람들이 Accelerate를 읽고 일주일 된 코드로 다시 전환하는 컨텍스트 스위칭의 고통을 느꼈다. 그럼에도 프로세스가 지속되는 이유는:

• 가시성 부족 – 보지 못하는 것을 개선할 수 없다. 데이터가 없으면 “리뷰가 느리다”는 느낌일 뿐이며 쉽게 무시된다.
• 기준선 부재 – 팀에게 정상적인 것이 무엇인가? 이번 스프린트가 이전보다 나쁜가? 추적이 없으면 알 수 없다.
• 책임감 결여 – 24시간 합의는 누가 위반됐는지 알 수 없으면 의미가 없다.

원래 작성자가 그 기능 장애를 완벽히 포착했다:

“팀이 사람보다 프로세스를 우선시하고, 그 뒤에 애자일이라고 주장한다.”

프로세스를 디버깅하라, 팀을 디버깅하지 마라

당신의 리뷰는 설계한 시스템이 허용하는 만큼 정확히 걸린다.
리뷰가 느린 이유는 개발자가 게으르기 때문이 아니다. 워크플로우는 당신이 설계했으며, 재설계도 당신의 책임이다. 디버깅이 가시성에서 시작하듯이, 리뷰 프로세스도 마찬가지다.

배포가 실패하면 원인을 추측하지 않고 로그를 확인하고, 오류를 추적하고, 깨진 라인을 찾는다. 리뷰 프로세스도 같은 방식으로 다루어야 한다:

• 아이템이 실제로 리뷰에 머무는 시간은 얼마나 될까?
• 어떤 전환이 느린가?
  • 개발 완료 → 리뷰 진행 중?
  • 리뷰 진행 중 → 리뷰 완료?
  • 리뷰 완료 → 테스트 진행 중?
• 24시간 합의가 지켜지고 있는가?

이 질문들은 모두 데이터를 수집한다면 쉽게 답할 수 있다.

저는 **Time In Status**의 리드 개발자이다.

[3‑day code review problem](?utm_source=...&utm_medium=...&utm_campaign=...&utm_content=3day-code-review-problem) by Smart Guess — it shows you how long Jira issues spend in each status, so you can see where work waits, spot review bottlenecks before they pile up, and finally have data for those “why did this take so long?” conversations.

이 앱은 Jira 이슈가 각 상태에 머무는 시간을 보여주어 작업이 어디서 대기하고 있는지 파악하고, 리뷰 병목 현상이 쌓이기 전에 발견하며, “왜 이렇게 오래 걸렸나요?”라는 대화에 필요한 데이터를 제공한다.