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%에 대부분의 시간이 쓰인다면, 생산성을 높일 여지도 바로 그곳에 있다.

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

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