도구 도입 전 측정하기: 엔지니어링 내 AI 투자가 향해야 할 곳

Microsoft에서 개발자 생산성 연구를 이끄는 Brian Houck는 다음과 같이 설명했습니다: 코딩은 개발자 주당 업무 시간의 약 14%를 차지합니다. 따라서 코딩 부분에서 상당한 이득을 얻더라도 회복할 수 있는 범위는 제한적입니다.

나머지 86%인 리뷰(review), 계획(planning), 디버깅(debugging), 컨텍스트 스위칭(context-switching), 이해관계자와의 의견 조율(stakeholder back-and-forth), 그리고 무언가 제대로 이해되기 전에 구축되어 발생하는 재작업(rework) 등은 코드를 작성하는 속도가 빨라졌다고 해서 더 빨라지지 않습니다.

이것이 코딩 도구에 반대하는 주장은 아닙니다. 저도 매일 사용합니다. 하지만 "코딩 도구를 배포하는 것"은 전략이 아니며, 저는 최근 Mintel에서 새로운 집중 분야로 엔지니어링 팀이 AI 도구를 채택하는 방식을 최적화하는 업무를 맡게 되었습니다. 제 업무가 팀의 속도를 높이는 데 도움을 주는 것이라면, 어떤 도구가 어떤 팀에 도움이 되는지, 실제 병목 현상(bottlenecks)이 어디에 있는지, 그리고 팀이 실제로 겪고 있는 문제에 어떻게 투자를 집중할 수 있는지를 알아야 합니다. 이는 도구의 문제이기 이전에 측정(measurement)의 문제입니다.

DORA는 '무엇'을 알려줄 뿐, '왜'는 알려주지 않습니다

대부분의 팀은 이미 무언가를 알려줄 수 있는 데이터를 보유하고 있습니다. DORA 지표(배포 빈도(deployment frequency), 변경 리드 타임(lead time for changes), 변경 실패율(change failure rate), 복구 시간(time to restore))는 합리적인 신호이지만, 지표를 보유하는 것과 그 의미를 이해하는 것은 별개의 문제입니다.

2년 전, 저는 GitLab API를 사용하여 저장소 활동에서 배포 빈도와 리드 타임을 가져오는 내부 대시보드를 구축했습니다. 저희 엔지니어링 매니저(EM)들은 이를 사용하며, 이는 Jira의 사이클 타임(cycle time)만 사용하는 것보다 대화를 위한 더 근거 있는 기반을 제공해 주었습니다. 하지만 그 한계는 빠르게 드러났습니다. 리드 타임이 느려졌다는 것은 알려주지만, 왜 그런지는 이해하도록 도와주지 않습니다. 저는 패턴을 파악하기 위해 지표를 스프레드시트로 수동 추출하여 사용하는 EM들과 대화해 왔는데, 이는 데이터는 존재하지만 통찰(insight)은 없다는 명확한 신호입니다.

측정(measurement)이 없다면 우리는 느낌(vibes)에 의존해 일하게 됩니다. 측정은 있지만 맥락(context)이 없다면 우리는 차트(charts)에 의존해 일하게 됩니다.

더 근거 있는 회고 (A more grounded retrospective)

그 간극을 메우기 위해, 저는 정량적(quantitative) 데이터와 정성적(qualitative) 데이터를 결합하여 '왜' 그런 일이 일어났는지 이해할 수 있도록 지표를 회고(retro) 논의에 가져오는 에이전트(agent)를 구축해 왔습니다. 이 에이전트는 Jira와 GitLab에서 스프린트 지표(현재 스프린트 및 이전 두 개의 스프린트)를 가져와 LLM에 입력하며, 개별 티켓(ticket)과 머지 리퀘스트(merge request)를 조회할 수 있는 도구들을 갖추고 있습니다. 그 결과물은 팀의 스프린트 회고를 위한 일련의 가설(hypotheses)과 논의 사항(discussion points)입니다. 즉, 데이터가 시사하는 패턴, 질문할 가치가 있는 문제, 더 깊이 파고들 가치가 있는 실마리(threads) 등을 제공합니다.

이것은 회고를 자동화하는 것이 아닙니다. 회고란 팀이 스스로의 경험을 되돌아보는 과정이며, 그 과정은 인간적이기 때문에 가치가 있습니다. 회고는 공동의 이해(shared understanding)를 구축하고, 지표에 나타나지 않는 것들을 표면화하며, 솔직한 대화를 가능하게 하는 심리적 안전감(psychological safety)을 형성합니다. 알고리즘은 이를 대체할 수 없습니다.

이 도구가 할 수 있는 일은 질문을 받아 그 실마리를 풀어가기 시작하는 것입니다. 실제 스프린트에서 얻은 몇 가지 사례는 다음과 같습니다:

• 사이클 타임(Cycle time) 급증. 에이전트는 사이클 타임이 높아진 티켓들이 워크플로우(workflow)를 어떻게 통과했는지 분석하여, 많은 티켓이 "차단됨(blocked)" 상태를 한 번 이상 반복해서 오갔음을 드러냅니다. 단순히 "사이클 타임이 늘어났다"가 아니라, "사이클 타임이 늘어났고, 많은 티켓이 차단됨 상태에 반복적으로 머물렀습니다. 계획 단계에서 고려하지 못한 외부 의존성(external dependency)이 있었나요?"라고 질문합니다.
• 티켓 하나가 3주 동안 지속됨. 에이전트는 연결된 MR(Merge Request)들을 추적하여 작업이 세 개의 서비스에 걸쳐 분산되어 있음을 찾아냅니다. "이 티켓은 처리가 느렸다"가 아니라, "이 티켓은 세 개의 서비스에 영향을 주었습니다. 변경 경계(change boundary)가 적절한 위치에 있나요, 아니면 앞으로도 계속 나타날 결합도 비용(coupling tax)을 지불하고 있는 건가요?"라고 질문합니다.
• MR이 리뷰 상태로 일주일간 방치됨. 에이전트는 차이점(diff)을 살펴보고 40개 이상의 파일이 변경되었음을 발견합니다. "리뷰가 느리다"가 아니라, "이 MR은 제대로 리뷰하기에는 너무 컸을 가능성이 높습니다. 변경 사항을 하나로 묶는 패턴이 있는데, 이를 분리해야 하는 것은 아닌가요?"라고 질문합니다.

이것들은 여전히 가설입니다. 팀은 이를 평가하고, 반박하고, 어떤 것이 사실인지 결정해야 합니다. 목표는 데이터에 기반한 더 나은 질문을 던짐으로써, 모든 맥락을 파악하고 있는 엔지니어들이 실제로 무슨 일이 일어나고 있는지 성찰할 수 있는 인간 주도 대화의 시작점을 만드는 것입니다.

작성(Authoring)을 넘어선 에이전트

엔지니어링 분야의 AI에 관한 거의 모든 대화는 기본적으로 코드 작성(writing code)으로 귀결됩니다. DX 데이터는 생산성 향상이 실제로 일어나고 있지만 한계가 있음을 시사합니다. 만약 나머지 86%의 작업이 대부분의 시간을 차지하는 영역이라면, 바로 그곳에 생산성을 높일 여지가 있습니다.

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

이 글은 시리즈의 첫 번째 글입니다. 다음 포스트에서는 에이전트가 어떻게 작동하는지, 즉 데이터 소스, 프롬프팅(prompting) 접근 방식, 그리고 까다로운 부분들에 대해 다룹니다. 그 이후에는 우리가 이를 어떻게 배포했는지, 그리고 실제 사용을 통해 무엇을 배웠는지에 대해 다룰 예정입니다.