에이전트 기반 코딩을 도입한 대부분의 팀은 병목이 생성에서 검토로 옮겨가며, 이 과정을 개선하지 않으면 실질적인 속도 향상은 거의 없습니다.
매일 밤 수백 명의 엔지니어가 수백만 건의 테스트를 실행하는 대규모 CI 환경에서 가장 가치 있는 에이전트 작업은 코드 생성이 아니라 담당자 연결과 분류입니다.
유용한 에이전트 결과물은 면밀한 검토를 견디며, 단순히 패턴을 찾는 데 그치지 않고 인과관계를 설명합니다.
생성 계층보다 증거 수집 및 컨텍스트 구성 계층을 설계하는 일이 더 중요합니다.
에이전트 기반 코딩에 관한 논의는 여전히 대부분 더 많은 코드를 더 빠르게 작성한다는 단순한 약속에서 출발합니다.
때로는 에이전트가 작업을 계획하고 PR을 생성하며 사람의 개입을 최소화한 채 변경 사항을 배포한다는 더 야심 찬 비전으로 확장되기도 합니다. 하지만 대부분의 엔지니어링 팀이 단기적으로 얻을 수 있는 가장 확실한 가치는 그보다 구체적인 데 있습니다. 바로 반복 작업의 비용을 줄이는 것입니다.
소프트웨어 제공은 단순한 코드 생성이 아닙니다. 코드 작성은 검토, 테스트, 배포는 물론 문제 발생 시 조사까지 포함하는 긴 순환 과정의 한 단계일 뿐입니다. 검토 과정을 재설계하지 않고 에이전트 기반 코딩을 도입한 대부분의 팀은 병목을 후속 단계로 옮길 뿐입니다.
생성 속도만 높인다고 해서 팀 전체가 저절로 빨라지는 것은 아닙니다. 검토와 검증, 신뢰 확보에 더 많은 노력이 들게 될 수도 있습니다.
많은 엔지니어링 환경에서 비용이 많이 드는 부분은 초안을 만드는 일이 아니라 확신을 얻는 일입니다.
변경 사항이 실제로 문제를 해결했거나 시스템을 개선했는가? 다른 곳에 회귀 문제가 생기지는 않았는가? 실패 원인은 코드, 환경, 테스트, 종속성 중 어디에 있는가? 제안된 수정안은 원인을 해결하는가, 아니면 눈에 보이는 증상만 해소하는가?
에이전트는 엔지니어를 대체해서가 아니라 복잡한 증거를 체계적으로 1차 검토할 수 있기 때문에 도움을 줄 수 있습니다. 로그를 살펴보고, 최근 변경 사항을 비교하고, 관련 신호를 요약하고, 유력한 원인을 추적하고, 검사를 실행한 뒤 사람이 따져 볼 수 있는 결과물을 반환합니다.
많은 팀에서 에이전트를 활용해 가장 큰 효과를 얻는 방법은 처음부터 코드를 생성하게 하는 것이 아닙니다. 사람이 몇 시간 동안 직접 조사하기 전에 문제의 탐색 범위를 좁히는 것입니다.
이는 대규모 디버깅 워크플로에서 특히 분명하게 드러납니다. 수백 명의 엔지니어가 수정한 코드베이스 전반에서 매일 밤 수백만 건의 테스트를 실행하는 CI를 상상해 보세요. 실제로 저희 고객사 한 곳이 이런 환경을 운영하고 있습니다. 문제가 발생하면 담당자를 찾아 연결하기가 어렵습니다. 문제의 원인은 애플리케이션 코드나 종속성, 테스트 하네스 또는 스택의 다른 부분에 있을 수 있습니다. 로그가 기가바이트 단위로 쌓일 수 있으며, 문제를 처음 발견한 팀이 담당 팀이 아닐 수도 있습니다.
이런 워크플로에서는 에이전트 하나가 수정 코드를 작성하도록 하는 방식이 자연스럽지 않습니다. 문제의 범위를 빠르게 좁히는 시스템에 적합한 워크플로입니다.
유용한 파이프라인이라면 로그를 가져오고, 관련 증거를 선별하고, 중요한 내용을 요약하고, 샌드박스에서 코드를 검사한 뒤 신뢰도 점수와 추적 가능한 근거, 권장 후속 조치를 포함한 체계적인 근본 원인 분석을 제공할 수 있습니다. 신뢰도 점수를 산출하기 위해 해당 분야 전문가가 에이전트의 초기 결과물을 평가합니다. 그 결과를 LLM 심사 모델에 입력하면 사람의 판단과 일관성을 유지하면서 이후의 점수 산정을 자동화할 수 있습니다.
목표는 엔지니어의 판단을 없애는 것이 아니라 검토자가 더 탄탄한 출발점에서 시작하도록 돕는 것입니다. 회귀 문제 분류, PR 검토, 테스트 복구, 릴리스 검증, 배포 후 조사는 모두 같은 특성을 공유합니다. 많은 증거와 검토가 필요하고 모호한 부분도 많습니다. 에이전트에 엔지니어링 프로세스를 대체하라고 요구하는 것이 아니라, 그 프로세스가 원활히 진행되도록 지원하게 하는 것입니다.
이러한 이유로 팀은 이런 시스템의 평가 방법도 신중하게 정해야 합니다.
에이전트가 단독으로 인상적인 결과물을 만들 수 있는지를 묻는 것은 잘못된 접근입니다. 더 나은 질문은 다른 부분에 부담을 주지 않으면서 실제 워크플로를 개선하는지 여부입니다.
즉, 결과물이 검증할 수 있을 만큼 구체적인지, 단순히 패턴을 찾는 데 그치지 않고 인과관계를 설명하는지, 검토를 더 어렵게 만들지 않고 수월하게 하는지를 살펴봐야 합니다. 그럴듯한 답변과 유용한 답변은 다릅니다. 실제로 팀은 면밀한 검토를 견디고 확인할 수 있는 구체적인 근거를 제공하는 에이전트 결과물을 신뢰합니다.
더 중요한 교훈은 유용한 에이전트 기반 시스템에 생성 외에도 많은 요소가 필요하다는 것입니다. 증거를 수집하고 컨텍스트를 구성하는 방식, 결과물을 검사하는 방식, 불확실성을 검토자에게 제시하는 방식이 모두 중요합니다.
이러한 이유로 에이전트 기반 엔지니어링의 가까운 미래가 단번에 완전한 자율성으로 도약하는 모습일 가능성은 낮습니다. 오히려 에이전트가 팀의 조사, 검토, 검증, 개선을 지원하고 각 단계 사이에서 낭비되는 노력을 줄이는 정교한 순환 과정들이 등장할 가능성이 큽니다.
완전한 자율화라는 더 큰 비전에 비하면 덜 획기적으로 들릴 수 있지만, 실제 현장에서 유용한 시스템이 자리 잡는 과정은 오히려 이런 모습에 가깝습니다.