AI 에이전트 개발 병목은 개발자 — 서브에이전트·워크트리로 개발 루프 자동화하는 법

핵심 메시지

• 데모는 쉽게 만들지만 프로덕션에서 무너진다. 원인은 모델 성능이 아니라 버그를 고쳐 배포하기까지의 '개발 루프 속도'다.
• 모델은 3~4개월마다, 칩은 1년마다 새로 나오고 프레임워크는 매일 등장한다. 갈아끼우기 쉬운 것에 기대지 말고 자신의 작업 루프를 자동화해야 한다.
• 핵심 도구는 네 가지다. 병렬 서브에이전트, 조직의 작업 방식을 담은 스킬, 외부 시스템을 잇는 MCP 도구, 그리고 모든 것을 한 화면에 모으는 최소한의 UX.
• 버그 티켓 접수부터 배포까지 9단계 중 사람이 반드시 필요한 지점은 처음과 마지막뿐이라는 것이 발표자의 주장이다.
• 사람은 검증자로 남아야 하지만 처리량의 상한선이 되어서는 안 된다. 인간의 주의력은 유한하기 때문이다.

쉽게 이해하기

2026년 7월 30일 AI Engineer 채널에 공개된 이 발표는 금융 분야 AI 에이전트를 만드는 회사 Auditoria AI의 데이터 사이언티스트 Ramana Siddanth Emani가 맡았다. 제목은 "당신의 금융 에이전트의 병목은 바로 당신"이다. 발표자는 청중을 비난하려는 뜻이 아니라며, 개발자가 쓰는 작업 환경(하네스)이 곧 에이전트 품질의 상한선이 된다는 점을 짚었다.

그가 지적한 현실은 이렇다. 컨퍼런스에서 보는 화려한 데모는 만들기 쉽다. 코드를 쓰는 일 자체가 쉬워졌기 때문이다. 그러나 그 데모가 파일럿을 거쳐 실제 고객에게 넘어가면 에이전트는 한 번도 본 적 없는 데이터를 만나고, 프로덕션 버그는 시간 단위로 쌓인다. 여기서 더 좋은 모델이나 더 빠른 GPU, 새 프레임워크를 답으로 삼기 쉽지만 그것들은 기다리면 저절로 바뀌는 변수다. 실시간으로 버그를 고쳐낼 수 있는지를 결정하는 것은 개발자 자신의 루프 속도다.

발표는 네 가지 기본 요소를 제시한다. 첫째는 서브에이전트다. 최근 하네스는 서브에이전트를 얼마든지 띄울 수 있고, 이때 깃 워크트리가 짝이 된다. 워크트리는 격리된 폴더이므로 여러 에이전트가 같은 파일을 두고 충돌하지 않고 병렬로 일한다. 발표자는 램 48GB의 맥북에서 50개의 워크트리를 동시에 굴려 각각 다른 작업을 처리할 수 있다고 말한다. 작업의 출처는 이미 존재한다. QA가 올린 지라 티켓 하나하나가 별도의 워크트리가 된다. 둘째는 스킬이다. 조직의 축적된 작업 방식을 스킬로 정리해두면 에이전트가 매번 올바른 절차를 따른다. 셋째는 MCP 도구로, 로그 시스템이든 인증 게이트웨이든 고객 데이터가 어디에 있어도 연결된다. 넷째는 최소한의 UX다.

실제 흐름은 이렇게 그려진다. QA가 버그 티켓을 올리면 에이전트가 요구사항을 해석하고 근본 원인을 분석하며 트레이스와 로그를 끌어온 뒤, 별도 워크트리에서 테스트 주도로 수정 코드를 작성한다. 로컬에서 종단 테스트를 돌리고 PR을 올려 팀 리뷰를 받은 뒤 병합하고, 도커 이미지를 만들어 개발·스테이지 환경에 차례로 배포한 다음 QA에 알린다. 발표자는 이 아홉 단계 중 사람이 필요한 지점을 1단계와 9단계로 본다. 에이전트가 무슨 일을 하는지 보는 사람, 그리고 결과를 검증하는 사람만 있으면 된다는 것이다. 그래서 쿠버네티스 서비스와 파드, 시스템 로그, 지라 티켓, 깃허브 PR, 코딩 에이전트 세션을 하나의 위젯에 모으는 최소 UX를 강조한다. 창을 여러 개 띄우고 모니터 사이로 고개를 돌리는 횟수 자체가 배포 속도를 깎기 때문이다.

금융이라는 도메인은 이 그림에 제약을 더한다. 규제와 정책이 계속 바뀌고, AI가 없던 시절에는 사람 감사자가 코드를 검토하고 컨트롤러가 컴플라이언스에 서명했다. 에이전트가 에이전트를 리뷰하는 구조에서는 책임 소재가 흐려진다. 문제가 터졌을 때 "AI가 그랬다"고 말할 수는 없다. 그럼에도 발표자는 자기 자신을 루프에서 덜어내는 방향을 제시한다. 프로덕션 실패를 입력으로 삼아 하네스를 매일 조금씩 개선하고, 며칠간 버그 티켓 다섯~여섯 개를 처리한 뒤 에이전트에게 그 과정의 병목을 목록으로 뽑게 해 하나씩 없애는 식이다. 한 달을 그렇게 쌓으면 한 문장으로 지시하는 수준에 이른다고 말한다. 목표와 루프를 함께 설정하는 방식, 반복되는 고객 사용 패턴을 배경에서 압축해 시스템 개선에 쓰는 '드리밍'도 같은 맥락에서 소개된다.

주요 인사이트

• 이 발표의 관점 전환은 '더 좋은 모델을 기다리는 대신 내 작업 루프를 고친다'는 데 있다. 모델·칩·프레임워크는 외부에서 개선되지만 개발 루프는 각 팀이 직접 만들어야 하는 유일한 자산이다.
• 병렬 서브에이전트의 전제 조건이 격리라는 점이 실무적으로 중요하다. 워크트리 없이 여러 에이전트를 같은 작업 공간에 풀면 서로의 변경을 덮어쓰며 속도 이득이 사라진다.
• 지라 티켓과 QA 리포트처럼 이미 존재하는 작업 큐를 그대로 에이전트의 입력으로 쓰라는 조언은 새 파이프라인을 만들 필요가 없다는 뜻이다. 발표자는 사람이 작업을 줄 세우는 일부터 에이전트에게 넘기라고 말한다.
• 규제 산업에서는 자동화 수준보다 책임 소재 설계가 먼저다. 감사와 승인 절차가 있는 조직에서는 '사람이 검증자로 남는다'는 원칙이 자동화의 조건이 된다.
• 자동화의 진짜 지표로 '고개를 돌리는 횟수'를 든 점이 눈에 띈다. 도구가 늘어날수록 컨텍스트 전환 비용이 커지므로, 화면을 하나로 합치는 일이 곧 처리량 개선이 된다.

자주 묻는 질문

관련 AI 소식