AI가 이제 이전보다 10배 더 많은 PR(Pull Request)을 작성할 수 있게 되었지만, 팀은 여전히 작년과 같은 속도로 이를 검토하고 있습니다.

이 격차는 매 스프린트마다 커지고 있으며, 거의 아무도 이를 추적하지 않고 있습니다.

모두가 축하하는 지표는 잘못되었다

팀들은 PR 수에 열광합니다. “이번 분기에 PR 볼륨을 40% 더 높게 달성했습니다.” 좋습니다! 하지만 누가 그것들을 검토했나요?

AI 코딩 어시스턴트(coding assistants)는 놀라운 코드를 작성합니다. 그들이 추가적인 리뷰어를 만들어주지는 않습니다. 병목 현상은 사라졌습니다. 단지 다운스트림으로 이동했을 뿐입니다.

DORA 지표는 이것을 포착하지 못한다 (아직까지)

DORA(DevOps Research and Assessment) 지표는 리드 타임(lead time), 변경 실패율(change failure rate) 등을 측정하여 엔지니어링 생산성을 정량화합니다.

하지만 여기에는 사각지대가 있습니다. 리드 타임은 첫 커밋부터 프로덕션까지의 시간을 의미합니다. 만약 모든 시니어 엔지니어가 AI가 생성한 diff 더미 속에 파묻혀 있어 PR이 검토 대기열에 3일 동안 머문다면, 이는 느린 리드 타임으로 나타나지만, 아무도 이를 올바른 원인으로 귀속시키지 않습니다.

시스템이 실패하는 방식은 명확하지 않습니다:

→ AI가 더 빠르고 많은 PR을 생성한다
→ 검토 대기열이 부풀어 오른다
→ 리뷰어들이 주의 깊게 읽기보다 훑어본다
→ 변경 실패율이 증가한다
→ 팀은 용량 문제(capacity problem)를 인식하기보다는 “품질 문제”를 탓한다

당신들은 더 빠르게 배포하는 것이 아닙니다. 단지 작업을 더 빠르게 생성하고 있을 뿐입니다. 그것은 같은 일이 아닙니다.

AI 리뷰 부채는 현실이다

“AI Review Debt(AI 리뷰 부채)”라는 용어는 최근 Sumant Thakur가 자신의 Substack에서 만들었으며, 그 어느 때보다 정확합니다. 검토 역량 확장이 수반되지 않은 모든 AI 생성 PR은 부채입니다. 그것은 눈에 띄지 않게 증가합니다.

저는 대부분의 팀들이 이미 이 느낌을 받고 있다고 생각합니다. 시니어 엔지니어들은 압도당하고 있습니다. 주니어들은 Copilot으로 PR을 생성하지만, 아직 서로의 작업을 의미 있게 검토할 수 있는 맥락(context)이 부족합니다. 그 결과, 세 명의 팀원이 모든 것의 병목 현상이 됩니다.

그리고 일반적인 기술 부채와 달리, 아무도 이것을 로드맵에 올리지 않습니다.

아직 깔끔한 해결책이 있다고 생각하지는 않습니다. 하지만 몇 가지 사항들은 올바른 방향으로 나아가고 있는 것으로 보입니다.

→ 리뷰 큐 깊이(review queue depth)와 리뷰 사이클 타임(review cycle time)을 리드 타임(lead time)과 분리하여 측정하세요. 병목 현상을 볼 수 없다면, 해결할 수도 없습니다.
→ PR(Pull Request) 개수를 생산성 지표로 삼아 축하하는 것을 멈추세요. 병합된(Merged) PR이 중요합니다. 열려 있는(Open) PR은 산출물(output)이 아니라 재고(inventory)입니다.
→ 코드 생성 도구에 투자했던 것과 동일한 에너지를 리뷰 도구에 투자하세요. AI 지원 리뷰(AI-assisted review)가 다가오고 있지만, 대부분의 팀은 현재 사용 가능한 것조차 탐색하지 않았습니다.
→ 명시적인 리뷰 용량 제한(review capacity limits)을 설정하세요. 만약 사람이 하루에 약 4~5개의 상당한 규모의 PR을 심도 있게 리뷰할 수 있다면, 그것이 당신의 처리량(throughput) 상한선입니다. 이를 바탕으로 계획을 세우세요.

여기서 불편한 진실은, 리뷰 워크플로우(review workflows)에 대한 재고 없이 AI 코딩과 도구들을 혼합하는 것은 단순히 압박의 대상을 작성자(writers)에서 리뷰어(reviewers)로 옮길 뿐이라는 점입니다. 이것은 도구의 문제가 아니라 팀 설계의 문제입니다.

진짜 위험

이 문제에 대해 제가 우려하는 점은, 리뷰어들이 매우 바쁠 때 PR을 거절(decline)하는 대신 실제로는 더 빨리 병합(merge)해 버릴 수도 있다는 것입니다.

이것은 가장 바람직하지 않은 결과입니다. 속도가 빨라졌다는 환상을 얻는 대신, 품질 저하라는 현실을 마주하게 됩니다. 실패한 변경 사항의 수가 증가합니다. 사람들은 시스템에 대한 신뢰를 잃습니다. 그리고 6개월 후, 모두가 왜 제품이 취약하게 느껴지는지 의문을 갖게 됩니다.

병목 현상은 이동했지만, 조직도(org chart)는 변하지 않았습니다.

만약 놀라운 AI 도구와 기술 덕분에 올해 PR 산출량이 두 배로 늘었다면, 한 가지 질문을 던져보겠습니다. 당신의 리뷰 용량도 두 배로 늘어났습니까? 만약 그 대답이 정말로 '아니오'라면, 당신은 아직 이름 붙이지 못한 부채를 쌓아가고 있는 것입니다.

AI가 생성하는 PR이 계속해서 증가함에 따라, 당신의 팀은 리뷰 부하를 관리하기 위해 어떤 전략을 사용하고 있는지 궁금합니다. 무언가 다르게 하고 계신가요, 아니면 그저 악으로 깡으로 버티고 계신가요?