DX가 최근 400개 이상의 엔지니어링 조직을 대상으로 한 16개월 종단 연구 결과를 발표했습니다. AI 도구 사용량은 65% 증가한 반면, PR 처리량 중앙값은 8%에도 미치지 못했습니다. 대부분의 조직은 5~15% 구간에 머물렀습니다. 의미 있는 변화이지만 일부 벤더가 내세우는 3배, 10배 효율에는 한참 못 미치는 수준입니다.

Microsoft에서 개발자 생산성 연구를 이끄는 Brian Houck은 이렇게 설명했습니다. 코딩은 개발자 업무 시간의 약 14%에 불과하다는 것입니다. 코딩 부분에서 아무리 큰 개선을 이뤄도 만회할 수 있는 시간에는 한계가 있다는 설명입니다.

나머지 86% — 리뷰, 기획, 디버깅, 컨텍스트 전환, 이해관계자와의 조율, 제대로 이해하기도 전에 만들어서 생기는 재작업 같은 일들 — 은 코드를 더 빨리 작성한다고 해서 빨라지지 않습니다.

이는 코딩 도구에 반대하는 주장이 아닙니다. 저도 매일 사용합니다. 하지만 “코딩 도구를 도입한다”만으로는 전략이 될 수 없습니다. 최근 Mintel에서 저는 엔지니어링 팀의 AI 도구 도입을 최적화하는 일을 새롭게 맡게 되었습니다. 팀이 더 빠르게 움직이도록 돕는 것이 제 역할이라면, 어떤 도구가 어떤 팀에 도움이 되는지, 진짜 병목이 어디에 있는지, 팀이 실제로 겪는 문제에 투자를 어떻게 집중해야 하는지를 알아야 합니다. 이는 툴링 문제이기 전에 측정 문제입니다.

DORA는 ‘무엇’은 알려주지만 ‘왜’는 알려주지 않습니다

대부분의 팀은 이미 무언가를 알려줄 수 있는 데이터를 가지고 있습니다. DORA 지표(배포 빈도, 변경 리드 타임, 변경 실패율, 복구 소요 시간)는 그럭저럭 쓸 만한 시그널이지만, 지표를 보유하는 것과 그 의미를 이해하는 것은 전혀 다른 문제입니다.

2년 전 저는 GitLab API를 이용해 레포지토리 활동에서 배포 빈도와 리드 타임을 가져오는 내부 대시보드를 만들었습니다. 엔지니어링 매니저들이 이를 활용하고 있으며, Jira 사이클 타임만 보는 것보다 훨씬 근거 있는 대화를 나눌 수 있게 되었습니다. 하지만 한계도 금방 드러났습니다. 리드 타임이 느려졌다는 사실은 알려주지만 왜 느려졌는지는 알 수 없었습니다. 지표를 스프레드시트로 직접 내보내 패턴을 찾으려는 EM들을 본 적도 있는데, 데이터는 있지만 인사이트는 없다는 분명한 신호였습니다.

측정이 없으면 감에 의존해 일하게 됩니다. 측정은 하지만 맥락이 없으면 차트만 보고 일하게 됩니다.

더 근거 있는 회고

이 간극을 메우기 위해 저는 메트릭을 회고 논의에 끌어들이는 에이전트를 만들고 있습니다. 정량적 데이터와 정성적 맥락을 결합해 ‘왜’를 이해하기 위해서입니다. Jira와 GitLab에서 스프린트 메트릭(현재 스프린트와 직전 두 개 스프린트)을 가져와 LLM에 전달하고, 개별 티켓과 머지 리퀘스트를 조회할 수 있는 도구를 제공합니다. 결과물은 팀 스프린트 회고를 위한 가설과 논의 주제 모음입니다. 데이터가 시사하는 패턴, 던져볼 만한 질문, 더 파고들 만한 실마리들입니다.

이 에이전트가 회고를 자동화하는 것은 아닙니다. 회고는 팀이 자신의 경험을 돌아보는 자리이며, 그 과정이 가치 있는 이유는 인간적인 과정이기 때문입니다. 공동의 이해를 만들고, 메트릭에 드러나지 않는 것들을 수면 위로 끌어올리며, 솔직한 대화를 가능하게 하는 심리적 안전감을 만듭니다. 알고리즘은 이를 대체할 수 없습니다.

이 에이전트가 할 수 있는 일은 질문 하나를 붙잡고 실마리를 풀어가기 시작하는 것입니다. 실제 스프린트에서 나온 몇 가지 예는 다음과 같습니다.

• 사이클 타임 급증. 에이전트는 사이클 타임이 길었던 티켓들이 워크플로우를 어떻게 이동했는지 추적하고, 그중 상당수가 “blocked” 상태를 한 번 이상 반복해서 드나들었다는 점을 짚어냅니다. 단순히 “사이클 타임이 늘었다”가 아니라 “사이클 타임이 늘었고, 많은 티켓이 blocked에 반복적으로 머물렀다 — 기획 단계에서 고려하지 못한 외부 의존성이 있었던 것은 아닐까?”라는 질문을 던지는 것입니다.
• 한 티켓이 3주 동안 끌렸습니다. 에이전트는 연결된 MR들을 따라가며 작업이 세 개 서비스에 걸쳐 분산되어 있음을 찾아냅니다. “이 티켓이 느렸다”가 아니라 “이 티켓은 세 개 서비스에 걸쳐 있었다 — 변경 경계가 제대로 설정된 것일까, 아니면 앞으로도 계속 비용을 치르게 될 결합도 문제를 안고 있는 것은 아닐까?”라는 질문이 됩니다.
• 한 MR이 일주일 동안 리뷰에 머물렀습니다. 에이전트는 diff를 살펴보고 40개 이상의 파일이 변경된 것을 확인합니다. “리뷰가 느리다”가 아니라 “이 MR은 제대로 리뷰하기에는 너무 컸던 것으로 보인다 — 나눠야 할 변경들을 한데 묶는 패턴이 있는 것은 아닐까?”라는 질문을 제시합니다.

이것들은 어디까지나 가설입니다. 팀이 이를 평가하고 반박하며, 어떤 것이 사실에 부합하는지 판단해야 합니다. 목표는 사람이 주도하는 대화의 출발점에서 데이터에 기반한 더 나은 질문을 던지는 것입니다. 전체 맥락을 아는 엔지니어들이 실제로 무슨 일이 일어나고 있는지 돌아볼 수 있도록 하기 위해서입니다.

코드 작성을 넘어선 에이전트

엔지니어링에서 AI에 관한 거의 모든 대화는 결국 코드 작성으로 귀결됩니다. DX 데이터는 생산성 향상이 분명 존재하지만 한계가 있음을 시사합니다. 나머지 86%의 업무에 대부분의 시간이 쓰인다면, 생산성을 높일 여지도 바로 그곳에 있습니다.

회고 에이전트는 코드를 작성하지 않습니다. 팀이 시간을 어디에 쓰고 있는지 파악하고, 그에 대해 더 나은 질문을 던지도록 돕습니다. 제대로 작동한다면, 가장 흥미로운 에이전트 활용 사례가 코딩 에이전트와는 전혀 다른 모습일 수 있음을 보여주는 한 사례가 될 것입니다.

이 글은 시리즈의 첫 번째 글입니다. 다음 글에서는 에이전트가 어떻게 동작하는지 — 데이터 소스, 프롬프팅 방식, 까다로운 지점들을 다룰 예정입니다. 그다음에는 어떻게 도입했으며 실제 사용을 통해 무엇을 배웠는지 공유할 계획입니다.