타우타우벤치: 에이전트를 만드는 일 자체를 통째로 재는 벤치마크

이번에 다룰 작업은 τ^τ-Bench: An Environment for End-To-End, Realistic Agent Construction, arXiv에 공개된 식별자 arXiv 2609.04611의 연구입니다. 이 작업이 내세우는 주장은 한 문장으로 정리할 수 있습니다. 언어 모델 에이전트의 성능을 재는 대신 에이전트를 처음부터 끝까지 만드는 일 자체를 벤치마크 과제로 삼아야 한다는 것입니다. 원문 논문 링크는 이 글 제목 아래에 표시되어 있습니다.

이 발상은 에이전트 평가의 무대를 뒤집습니다. 지금까지의 평가는 대부분 완성된 에이전트에게 일을 시키고 점수를 매겼습니다. 고객 질문에 답했는지, 분쟁을 올바르게 처리했는지, 도구를 순서대로 불렀는지를 쟀습니다. 타우타우벤치는 한 걸음 물러서서 다른 질문을 던집니다. 고객 응대 에이전트를 통째로 만들어 달라고 개발자 에이전트에게 맡기면 어떻게 될까. 사업 기록과 요구사항을 쥔 고객과 운영 중인 프로그래밍 인터페이스와 물려받은 코드와 서빙 비용 제한을 함께 건네고, 동작하는 완성품을 받아내는 일이 과연 지금의 코딩 에이전트에게 가능한가. 저는 이 질문이 현장의 냄새를 그대로 품고 있다고 느꼈습니다. 실제 외주 개발과 사내 구축 사업이 정확히 이런 모양이기 때문입니다.

여기서 한 가지를 미리 밝힙니다. 제가 이번에 확보한 근거는 arXiv 식별자를 중심으로 한 연구 개요 수준의 자료입니다. 세부 실험 조건과 전체 수치는 원문을 직접 확인해야 합니다. 그래서 이 글은 논문의 수치를 확정적으로 전달하는 요약이 아니라, 이 벤치마크가 왜 나왔고 어떤 구조로 동작하며 숫자를 어떻게 읽어야 하고 무엇을 다음에 확인해야 하는지를 정리하는 해설에 가깝습니다. 숫자보다 구조를 먼저 세우는 편이 이런 단계에서는 더 정직합니다.

이 논문을 집어 든 이유

에이전트를 운영해 본 사람은 비슷한 밤을 겪어봅니다. 데모에서는 잘 돌아가던 고객 응대 봇이 실제 상담 기록 앞에 서면 엉뚱한 곳에서 멈춥니다. 환불 규정은 바뀌어 있는데 봇은 옛날 문서를 읽고, 고객이 말하지 않은 조건을 멋대로 가정하고, 도구는 있는데 호출 순서를 틀리고, 로그를 뒤져보면 언어 모델의 답변 자체는 멀쩡한데 그 답변을 업무 규칙과 엮는 코드가 무너져 있습니다. 모델 점수는 올랐는데 체감 신뢰도는 그대로인 이유가 여기에 있습니다. 병목이 모델 안에만 있지 않습니다. 모델을 업무에 맞게 감싸는 구축 과정 전체에 있습니다.

저희가 새로운 AI 연구를 볼 때도 벤치마크 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 타우타우벤치는 바로 그 구축 과정 자체를 측정 대상으로 삼습니다. 똑똑한 에이전트 하나를 뽑는 시험이 아니라, 똑똑한 에이전트를 만들어내는 개발자를 뽑는 시험입니다. 질문 자체가 실무적인 데다, 답이 나오면 코딩 에이전트의 개발 방향이 달라질 수 있습니다. 모델을 크게 만드는 투자와 에이전트를 잘 만드는 투자의 비중이 다시 계산될 수 있기 때문입니다.

또 하나 저를 끈 지점은 협력이라는 단어입니다. 이 벤치마크는 혼자 푸는 퍼즐이 아니라 함께 짓는 일의 측정입니다. 요구사항을 쥔 고객과 대화하고, 기록을 뒤지고, 기존 코드를 읽고, 비용을 저울질하는 과정이 점수에 들어갑니다. 현장의 에이전트 구축이 정확히 그런 협력의 연속입니다. 명세서는 처음부터 완전하지 않고, 고객도 자기가 원하는 것을 처음에는 다 말하지 못합니다. 묻고 확인하고 보여주면서 맞춰갑니다. 이 과정을 점수에서 빼면 평가는 깨끗해지지만 현실과 멀어집니다. 타우타우벤치는 지저분한 부분을 시험 안으로 끌어들였다는 점에서 읽을 가치가 있다고 판단했습니다.

벤치마크의 전복: 푸는 시험에서 만드는 시험으로

기존 에이전트 평가의 구조를 먼저 정리해 보겠습니다. 보통은 과제와 도구가 준비되어 있고 에이전트가 그 안에서 행동합니다. 고객의 질문이 들어오면 문서를 찾고 도구를 부르고 답을 냅니다. 채점은 답의 정확성과 절차의 적절성을 봅니다. 이 방식은 에이전트의 실행 능력을 재는 데는 좋습니다. 하지만 에이전트가 어떻게 태어났는지는 묻지 않습니다. 누가 요구사항을 정리했고, 누가 업무 규칙을 코드로 옮겼고, 누가 비용과 모델을 골랐는지는 시험 밖에 있습니다.

타우타우벤치는 시험의 주인공을 바꿉니다. 주인공은 고객 응대를 하는 에이전트가 아니라 그 에이전트를 만드는 개발자 에이전트입니다. 개발자 에이전트는 빈손으로 시작하지 않습니다. 현실적인 계약의 재료들을 함께 받습니다. 사업 기록과 요구사항을 가진 고객과 운영 중인 프로그래밍 인터페이스와 물려받은 코드베이스와 서빙 비용 및 모델에 대한 제한이 출발선에 놓입니다. 개발자 에이전트는 이 재료들을 가지고 완성된 고객 응대 에이전트를 납품해야 합니다. 납품된 에이전트가 진짜로 시험받는 무대는 따로 있습니다. 끝까지 감춰둔 모의 사용자들과 마주치는 배치 평가입니다.

이 전복이 중요한 이유는 측정하는 능력이 완전히 달라지기 때문입니다. 푸는 시험은 주어진 명세 안에서 최적의 행동을 고르는 능력을 잽니다. 만드는 시험은 명세가 불완전한 상태에서 명세를 완성해가는 능력을 잽니다. 무엇을 물어볼지, 무엇을 기록에서 찾아낼지, 무엇을 고객에게 확인할지, 어떤 설계를 먼저 시도하고 언제 바꿀지를 정해야 합니다. 답을 고르는 능력이 아니라 일을 정의하는 능력이 시험에 들어옵니다. 저는 이 차이가 크다고 봅니다. 현장에서 외주 개발이 실패하는 지점은 대부분 답이 틀려서가 아니라 일을 잘못 정의해서이기 때문입니다.

이름에 담긴 발음 이야기도 잠깐 짚겠습니다. 연구는 이 벤치마크를 하이퍼타우벤치라고 읽는다고 밝힙니다. 타우라는 기호가 두 번 겹친 이름은 에이전트가 에이전트를 만든다는 이중 구조를 상징합니다. 만드는 주체도 에이전트이고 만들어지는 결과도 에이전트입니다. 이름부터 이 연구의 관심사가 실행이 아니라 구축에 있음을 드러냅니다. 협력적인 에이전트 구축이라는 일을 코딩 에이전트가 측정 가능한 목표로 삼게 하겠다는 포부가 이름 뒤에 붙어 있습니다.

출발선의 현실성: 다섯 가지 계약 조건

이 벤치마크가 현실적이라는 말의 뜻을 구체적으로 풀어보겠습니다. 개발자 에이전트가 받는 출발 재료는 다섯 가지 계약 조건으로 정리할 수 있습니다. 첫째는 사업 기록입니다. 회사의 문서와 데이터와 규정 같은 것들이 여기에 들어갑니다. 고객 응대 에이전트가 알아야 할 업무 지식이 흩어진 형태로 존재합니다. 한 곳에 깔끔하게 정리되어 있지 않습니다. 찾아내고 엮어야 합니다. 둘째는 요구사항을 쥔 고객입니다. 고객은 원하는 것을 다 말해주지 않습니다. 물어보면 답하지만 먼저 다 알려주지는 않습니다. 물어야 얻을 수 있는 정보가 시험 안에 설계되어 있습니다.

셋째는 운영 중인 프로그래밍 인터페이스입니다. 실제 서비스에 연결된 기능을 건드리는 통로입니다. 가짜 도구가 아니라 운영 조건을 흉내 낸 진짜 같은 통로입니다. 여기서 실수하면 벌점이 아니라 사고가 납니다. 넷째는 물려받은 코드베이스입니다. 백지에서 시작하는 개발이 아니라 기존 코드를 이어받는 개발입니다. 남이 짠 코드를 읽고 고치고 확장해야 합니다. 현장의 구축 사업 대부분이 이 모양입니다. 완전히 새로 짓는 일보다 낡은 것을 고쳐 쓰는 일이 훨씬 많습니다. 다섯째는 서빙 비용과 모델에 대한 제한입니다. 비싼 모델을 무한히 돌릴 수 없습니다. 예산 안에서 돌아가는 설계를 골라야 합니다.

이 다섯 가지가 한꺼번에 주어진다는 점이 핵심입니다. 각각은 따로 떼어놓으면 평범한 조건입니다. 문서 읽기는 검색 시험에서 다루고, 고객 대화는 대화 시험에서 다루고, 코드 고치기는 코딩 시험에서 다룹니다. 하지만 현장에서는 이 조건들이 동시에 옵니다. 문서를 읽으면서 고객에게 묻고, 기존 코드를 보면서 인터페이스 제약을 확인하고, 비용을 계산하면서 모델을 골라야 합니다. 조건을 따로따로 잘 처리하는 것과 동시에 처리하는 것은 다른 능력입니다. 타우타우벤치는 그 동시성을 시험 안으로 넣었습니다. 저는 이 선택이 이 벤치마크의 가장 큰 미덕이라고 봅니다. 현실을 닮은 시험은 조건의 목록이 아니라 조건의 동시성에서 나옵니다.

평가의 설계: 감춰둔 사용자로 배치해 채점한다

납품된 에이전트를 어떻게 채점하는지도 들여다보겠습니다. 방식은 말로 풀면 단순합니다. 개발자 에이전트가 만든 고객 응대 에이전트를 실제로 배치하고, 끝까지 감춰둔 모의 사용자들과 만나게 합니다. 모의 사용자는 개발 과정에서 볼 수 없었던 상황들을 들고 옵니다. 낯선 질문과 까다로운 요구와 예외적인 사연이 섞여 있습니다. 이 만남에서 통과한 시뮬레이션의 비율이 점수가 됩니다.

이 설계에는 두 가지 단단한 선택이 들어 있습니다. 첫째, 채점의 주체가 정적 답안지가 아니라 살아 있는 상호작용이라는 점입니다. 고객 응대는 한 번의 답으로 끝나지 않습니다. 묻고 답하고 확인하고 정정하는 여러 턴의 대화입니다. 정적 답안지로는 이런 왕복을 잴 수 없습니다. 모의 사용자와의 대화를 통째로 돌려야 진짜 실력이 드러납니다. 둘째, 평가 사용자가 개발 과정에서 감춰져 있다는 점입니다. 개발 때 본 사용자로만 시험하면 외우기가 통합니다. 본 적 없는 사용자가 들고 오는 낯선 상황에서 버티는지가 일반화의 증거입니다. 감춰둔 평가 묶음은 에이전트 연구에서 신뢰를 만드는 표준 장치이고, 이 벤치마크도 그 장치를 씁니다.

규모도 함께 적어두겠습니다. 평가는 네 개 영역에 걸쳐 쉰세 개 과제로 이뤄집니다. 쉰세 개라는 숫자는 한두 개 사례의 우연을 줄이고 경향성을 읽기에는 충분한 크기입니다. 네 개 영역이라는 구성은 한 영역에 특화된 설계가 전체 점수를 독식하기 어렵게 만듭니다. 영역마다 업무 규칙과 고객 성향과 대화 패턴이 다를 것이고, 납품된 에이전트는 그 다양성을 두루 버텨야 합니다. 저는 과제 수보다 영역 구성이 더 중요하다고 봅니다. 고객 응대라는 일은 영역이 바뀌면 상식이 바뀌는 일이기 때문입니다. 환불이 당연한 영역과 환불이 예외인 영역에서는 같은 질문에도 다른 답이 정답입니다.

여기서 한 가지 해석상의 주의점을 덧붙입니다. 시뮬레이션 통과율은 실제 고객 만족도와 같은 말이 아닙니다. 모의 사용자는 현실을 흉내 낸 장치이고, 장치의 설계에 따라 점수가 움직입니다. 모의 사용자가 현실의 까다로움을 덜 담으면 점수는 부풀려지고, 현실보다 심술궂으면 점수는 눌립니다. 그래서 통과율의 절대 숫자보다 숫자의 간격과 순위가 말해주는 바에 주목해야 합니다. 어떤 구성이 앞서고 전문가 기준선과 얼마나 벌어져 있는지가 장치의 편향을 넘어서는 정보입니다.

숫자 읽기: 23.9퍼센트와 82.2퍼센트 사이

핵심 숫자를 천천히 읽어보겠습니다. 가장 강한 구성은 클로드 오퍼스 5를 클로드 코드 아래에서 돌린 조합이었고, 평가 시뮬레이션의 통과율은 23.9퍼센트였습니다. 네 번 시도하면 한 번도 채 통과하지 못한다는 뜻입니다. 지금 가장 앞선 코딩 에이전트 구성을 가져다 놔도 네 개 과제 중 세 개는 납품 수준에 못 미칩니다. 한편 전문가가 직접 손으로 만든 참조 구현의 기준선은 82.2퍼센트를 기록했습니다. 사람이 공들여 지으면 열 번 중 여덟 번은 통과하는 수준에 이른다는 뜻입니다.

두 숫자 사이의 간격이 이 논문의 진짜 메시지입니다. 23.9퍼센트라는 절대값도 낮지만, 더 중요한 것은 82.2퍼센트와의 차이입니다. 전문가 기준선이 함께 낮았다면 과제가 불가능에 가까웠다고 변명할 수 있습니다. 하지만 사람이 하면 되는 일이 기계에게는 안 되고 있다는 점이 숫자로 확인되었습니다. 과제는 풀 수 있는 과제이고, 현재 코딩 에이전트의 방식으로는 못 푸는 과제입니다. 헤드룸이 크다는 말은 바로 이 뜻입니다. 개선의 여지가 있다는 희망의 표현이 아니라, 지금의 접근이 어딘가 빗나가고 있다는 진단입니다.

저는 이 간격을 세 가지로 쪼개어 읽고 싶습니다. 첫째는 발견의 간격입니다. 사업 기록을 뒤지고 고객에게 묻는 일을 전문가만큼 하지 못합니다. 둘째는 설계의 간격입니다. 처음 돌아가는 구조를 넘어서 더 나은 구조를 탐색하지 않습니다. 셋째는 운영의 간격입니다. 비용과 모델의 제약을 설계에 녹이지 못합니다. 세 간격이 곱해지면서 통과율이 주저앉습니다. 어느 하나만 고쳐도 점수는 오르겠지만, 기준선까지 가려면 세 가지를 함께 메워야 합니다. 이 대목은 뒤쪽 실패 분석과 바로 연결됩니다.

또 하나 짚을 점은 최강 구성의 정체입니다. 강한 모델과 강한 코딩 하네스의 조합이 1등을 차지했습니다. 모델이 좋아야 한다는 상식을 확인해줍니다. 하지만 그 조합으로도 23.9퍼센트라는 점이 동시에 말해줍니다. 모델만 좋다고 되는 일이 아니라는 것입니다. 하네스가 좋아도, 모델이 좋아도, 만드는 일의 구조를 못 풀면 점수는 오르지 않습니다. 저는 이 숫자를 코딩 에이전트 진영에 대한 정중한 경고로 읽습니다. 실행 과제의 점수가 올랐다고 구축 과제도 따라오지는 않습니다. 다른 시험에서 다른 실패가 기다리고 있습니다.

실패의 세 가지 얼굴: 얕게 묻고 적게 묻고 빨리 멈춘다

연구가 정리한 실패 양식은 세 가지입니다. 첫째는 사업 기록에 대한 얕은 조회입니다. 문서를 깊이 파지 않고 겉만 훑습니다. 둘째는 고객과의 최소한의 소통입니다. 요구사항을 쥔 고객에게 충분히 묻지 않습니다. 셋째는 처음 돌아가는 설계를 그대로 출하하는 태도입니다. 구조나 서빙 지출을 바꿔보는 실험 없이 첫 번째로 동작한 버전을 납품합니다.

세 가지를 한 문장으로 묶으면 이렇습니다. 찾지 않고, 묻지 않고, 고치지 않습니다. 저는 이 세 동사가 한 사람의 일습관처럼 읽혀서 인상 깊었습니다. 바쁜 주니어 개발자가 마감 앞에서 보이는 모습과 닮았습니다. 기록은 대충 읽고, 고객에게는 묻기 민망해서 대충 넘기고, 돌아가기 시작하면 손대기 무서워서 그대로 둡니다. 코딩 에이전트가 사람의 나쁜 습관을 닮았다는 점이 흥미롭습니다. 학습 데이터에 그런 습관이 들어 있어서인지, 아니면 보상 구조가 그런 행동을 유도해서인지는 따져볼 문제입니다. 하지만 겉모습만큼은 분명합니다. 지금의 개발자 에이전트는 성실한 장인이 아니라 급한 마감 앞에 선 초보의 얼굴을 하고 있습니다.

세 실패가 서로를 키운다는 점도 중요합니다. 기록을 얕게 읽으면 고객에게 무엇을 물어야 할지 모릅니다. 고객에게 묻지 않으면 설계의 빈틈이 어디인지 모릅니다. 설계의 빈틈을 모르면 실험할 방향도 잡히지 않습니다. 첫 번째 실패가 두 번째 실패를 낳고, 두 번째 실패가 세 번째 실패를 굳힙니다. 연쇄가 한 방향으로 돕니다. 반대로 생각하면 개입점도 보입니다. 기록 조회를 깊게 하는 습관 하나만 잡아도 물을 질문이 생기고, 물을 질문이 생기면 설계의 대안이 보입니다. 어느 고리를 끊을지가 이 벤치마크를 대하는 팀들의 첫 번째 숙제입니다.

발견의 실패: 기록은 깊이보다 방향이 먼저다

첫 번째 실패를 더 깊이 파보겠습니다. 얕은 조회가 문제라는 진단은 쉬워 보이지만, 그 안에 두 가지 다른 병이 들어 있습니다. 하나는 안 찾는 병이고, 다른 하나는 못 찾는 병입니다. 안 찾는 병은 조회의 횟수와 깊이가 부족한 것입니다. 문서를 몇 개만 읽고 그만둡니다. 못 찾는 병은 무엇을 찾아야 할지 몰라서 헤매는 것입니다. 많이 뒤지는데 엉뚱한 것을 뒤집니다. 겉으로 보기에는 둘 다 얕은 조회지만 처방은 다릅니다. 전자는 성실성의 문제이고 후자는 판단의 문제입니다.

사업 기록이라는 재료의 성질도 생각해야 합니다. 기록은 교과서처럼 정리되어 있지 않습니다. 규정은 여러 버전에 흩어져 있고, 예외는 이메일 같은 곳에 숨어 있고, 숫자 기준은 표 안에 박혀 있습니다. 무엇이 최신인지, 무엇이 예외인지, 무엇이 원칙인지를 가려내야 합니다. 이 가려내기는 검색어 몇 개로 끝나지 않습니다. 규정의 변경 이력을 쫓고, 서로 충돌하는 문서를 대조하고, 모호한 대목에 표시를 해두었다가 고객에게 물을 목록으로 넘겨야 합니다. 조회와 질문이 연결되어야 합니다. 기록을 읽는 일이 고객에게 물을 일을 만드는 과정이어야 합니다.

저는 여기서 코딩 에이전트의 도구 사용 습관을 의심합니다. 많은 에이전트가 검색 도구를 부를 때 넓게 묻지 않고 좁게 묻습니다. 첫 번째로 나온 답을 붙잡고 더 들어가지 않습니다. 인용할 문장 하나를 찾으면 조회를 멈춥니다. 고객 응대 에이전트를 만드는 일에서는 이 습관이 치명적입니다. 하나의 답이 아니라 규칙의 전체 지도가 필요하기 때문입니다. 지도가 없으면 납품된 에이전트는 아는 것만 답하고 모르는 것은 지어냅니다. 환각이라는 이름으로 불리는 현상 중 상당수는 모델의 병이 아니라 조회의 병일 수 있습니다. 덜 찾아서 지어내는 것입니다.

한 가지 실천적인 그림을 그려보겠습니다. 잘하는 전문가는 기록을 읽을 때 답을 찾는 게 아니라 질문 목록을 만듭니다. 이 규정은 언제 바뀌었는지, 이 예외는 누구에게 적용되는지, 이 숫자는 어떤 조건에서 달라지는지를 적어둡니다. 그리고 그 목록을 들고 고객을 찾아갑니다. 조회가 질문을 낳고 질문이 조회를 이끄는 순환이 돕니다. 개발자 에이전트가 이 순환을 돌지 못하고 한 방향으로만 움직인다면, 그것은 도구가 부족해서가 아니라 일하는 순서가 잘못 짜여 있기 때문입니다.

침묵의 실패: 묻지 않는 개발자는 추측으로 메운다

두 번째 실패인 최소한의 소통을 들여다보겠습니다. 고객이 요구사항을 쥐고 있다는 설정은 이 벤치마크의 백미입니다. 고객은 답을 알고 있지만 먼저 말하지 않습니다. 물어야 말합니다. 이 구조는 현실의 고객을 잘 흉내 냅니다. 현실의 고객도 자기가 아는 것을 다 말하지 않습니다. 당연하다고 여겨서 생략하고, 물어보지 않으니 중요하지 않다고 여기고, 정리할 시간이 없어서 미룹니다. 묻는 쪽이 판을 깔아야 답이 나옵니다.

묻지 않는 개발자 에이전트는 빈칸을 추측으로 메웁니다. 추측은 처음에는 그럴듯해 보입니다. 일반적인 고객 응대 상식으로 메우면 얼핏 돌아갑니다. 하지만 영역마다 상식이 다르다는 점이 발목을 잡습니다. 당연해 보이는 환불 기준이 영역마다 다르고, 당연해 보이는 본인 확인 절차가 회사마다 다릅니다. 상식으로 메운 부분은 평가의 낯선 사용자 앞에서 무너집니다. 감춰둔 평가가 정확히 그 지점을 찌릅니다. 개발 때 보지 못한 사연이 추측으로 메운 빈칸을 밟고 지나갑니다.

왜 묻지 않을까를 생각해 보면 몇 가지 가설이 나옵니다. 첫째, 묻는 것이 점수에 도움이 된다는 사실을 에이전트가 모릅니다. 조용히 혼자 해결하는 것이 유능하다는 편향이 학습에 들어 있을 수 있습니다. 둘째, 무엇을 물어야 할지 모릅니다. 기록을 얕게 읽었으니 빈칸의 모양도 모릅니다. 셋째, 묻고 답을 기다리는 왕복의 비용을 아까워합니다. 혼자 지어내는 편이 빠르다고 판단합니다. 세 가설은 서로 얽혀 있습니다. 저는 첫 번째 가설에 주목합니다. 협력을 측정하는 시험에서는 묻는 행동 자체가 실력인데, 지금까지의 코딩 시험은 묻지 않고 푸는 것을 실력으로 쳐왔습니다. 평가의 문화가 바뀌면 행동도 바뀔 수 있습니다.

묻는 기술에도 층위가 있습니다. 잘 묻는 전문가는 한 번에 하나씩 확인하지 않습니다. 모호한 대목을 묶어서 들고 가고, 구체적인 사례를 들어 확인하고, 답을 들으면 그 자리에서 기록으로 바꿉니다. 고객의 말을 명세의 문장으로 번역하는 왕복이 질문의 본질입니다. 개발자 에이전트가 고객과 몇 번 왕복했는지가 점수와 어떻게 연결되는지를 보는 분석이 앞으로 나오면 좋겠습니다. 왕복 횟수와 통과율의 관계를 그리면 묻는 일의 값어치가 숫자로 드러날 것입니다.

탐색의 실패: 첫 번째로 돌아가는 버전을 사랑하지 말 것

세 번째 실패는 처음 동작한 설계를 그대로 내보내는 태도입니다. 구조 실험도 없고 서빙 지출 실험도 없이 첫 번째 버전을 납품합니다. 이 대목은 저를 가장 아프게 찔렀습니다. 저를 포함해 많은 개발자가 마감 앞에서 같은 유혹에 빠지기 때문입니다. 돌아가기 시작하면 손대기 싫어집니다. 고치다가 망가뜨릴까 봐 두렵습니다. 그래서 첫 번째로 돌아가는 버전을 사랑하게 됩니다.

하지만 만드는 일에서 첫 번째로 돌아가는 버전은 거의 never 최선이 아닙니다. 고객 응대 에이전트의 설계 공간을 생각해 보겠습니다. 어떤 모델을 쓸지, 검색을 얼마나 깊게 할지, 대화를 몇 턴까지 이어갈지, 도구를 어떤 순서로 부를지, 실패하면 어떻게 복구할지의 조합이 설계입니다. 첫 번째로 돌아가는 조합은 그 공간의 한 점일 뿐입니다. 그 점보다 싸고 좋은 점이 근처에 있을 가능성이 큽니다. 실험하지 않으면 그 점을 찾지 못합니다. 납품은 했지만 손해를 보는 구조가 됩니다.

서빙 지출의 관점에서 보면 이 실패는 더 선명해집니다. 비싼 모델을 매 턴 부르는 설계와 싼 모델로 걸러내고 어려운 것만 비싼 모델에 넘기는 설계는 비용이 크게 다릅니다. 통과율이 조금 낮아도 비용이 훨씬 싸면 현장에서는 싼 쪽을 택할 때가 많습니다. 반대로 통과율이 조금 오르는 대가로 비용이 몇 배가 되면 채택하기 어렵습니다. 벤치마크가 비용 제한을 출발 조건에 넣은 이유가 여기 있습니다. 예산 안에서 무엇을 얻었는지가 진짜 성적표입니다. 첫 번째 버전을 그대로 내면 이 저울질을 하지 않은 셈이 됩니다.

저는 이 실패를 고치는 처방이 의외로 단순할 수 있다고 봅니다. 납품 전에 대안을 두 개 이상 만들어 비교하라는 규칙 하나면 행동이 바뀝니다. 구조가 다른 후보를 셋 만들고 같은 모의 사용자로 돌려보는 왕복을 개발 과정에 넣는 것입니다. 사람은 이런 왕복을 귀찮아하지만 기계는 잘합니다. 코딩 에이전트는 후보를 많이 만드는 데 강점이 있습니다. 만드는 힘은 있는데 고르는 일을 하지 않는 것이 문제라면, 해법은 고르는 과정을 강제하는 것입니다. 실험 없는 납품을 탈락시키는 규칙이 시험에 들어간다면 개발자 에이전트의 행동은 바뀔 것입니다.

현장의 언어로 번역하면: 협업이 곧 사양이다

이제 이 연구를 현장의 언어로 번역해 보겠습니다. 외주 개발과 사내 구축을 해본 독자라면 타우타우벤치의 구조가 낯설지 않을 것입니다. 발주처의 기록은 흩어져 있고, 담당자는 바빠서 다 말해주지 않고, 운영 중인 시스템은 건드리면 아프고, 물려받은 코드는 읽기 싫고, 예산은 정해져 있습니다. 이 조건에서 동작하는 것을 만들어내라는 주문이 바로 수주 사업의 일상입니다. 이 벤치마크는 그 일상을 실험실로 옮긴 것입니다.

번역의 핵심 문장은 이것입니다. 협업이 곧 사양이다. 처음부터 완전한 명세서는 없습니다. 명세는 대화에서 태어납니다. 고객에게 묻고, 기록에서 확인하고, 시제품을 보여주고, 다시 묻는 왕복이 명세를 씁니다. 묻지 않는 개발은 명세 없는 개발이고, 명세 없는 개발은 추측의 개발입니다. 타우타우벤치의 낮은 통과율은 추측의 개발이 얼마나 자주 무너지는지를 잰 숫자입니다. 23.9퍼센트라는 숫자는 모델이 멍청하다는 뜻이 아니라 일이 정의되지 않은 채로 출하되었다는 뜻에 가깝습니다.

이 관점에서 보면 전문가 기준선 82.2퍼센트의 의미도 다시 읽힙니다. 전문가가 잘한 것은 코드를 잘 짰기 때문만이 아닙니다. 물을 것을 묻고, 찾을 것을 찾고, 버릴 설계를 버렸기 때문입니다. 일하는 순서가 달랐습니다. 전문가는 답을 쓰는 데 시간을 쓰기 전에 질문을 만드는 데 시간을 씁니다. 기록을 읽으며 물을 목록을 만들고, 고객과 만나 목록을 지우고, 남은 모호함을 설계의 여유로 감쌉니다. 이런 순서가 몸에 밴 사람이 열 번 중 여덟 번을 통과합니다. 기계가 배워야 할 것은 정답 문장이 아니라 이 순서입니다.

조직의 관점에서도 할 말이 있습니다. 에이전트 구축을 모델 한 방으로 보던 팀은 생각을 바꿔야 합니다. 좋은 고객 응대 에이전트는 좋은 모델에서 나오는 것이 아니라 좋은 구축 과정에서 나옵니다. 기록을 정리하는 사람과 고객을 상대하는 사람과 설계를 비교하는 사람이 필요합니다. 지금은 그 일을 한 명의 전문가가 하지만, 앞으로는 개발자 에이전트가 맡아야 합니다. 타우타우벤치는 그 맡김의 현재 주소를 찍은 것입니다. 아직은 사람이 해야 할 일이 많고, 기계에게 넘길 준비가 덜 되었다는 주소를 말입니다.

숫자를 의심하는 법: 시뮬레이션과 영역의 한계

좋은 해설은 숫자를 전하는 데서 멈추지 않고 숫자를 의심하는 법까지 전해야 합니다. 타우타우벤치의 통과율을 읽을 때 함께 들어야 할 의심을 세 가지 적어보겠습니다. 첫째는 모의 사용자의 현실감입니다. 감춰둔 사용자라고 해도所 모의라는 한계는 남습니다. 현실의 고객은 모의보다 예측하기 어렵고 감정적이며 때로는 모순된 요구를 합니다. 모의 사용자가 그런 지저분함을 얼마나 담고 있는지에 따라 점수의 뜻이 달라집니다. 모의가 얌전하면 점수는 후해지고, 모의가 심술궂으면 점수는 박해집니다.

둘째는 영역 구성의 편향입니다. 네 개 영역이라는 구성은 다양성을 담보하지만, 그 네 개가 현실의 고객 응대 전체를 대표하는지는 별개의 질문입니다. 특정 영역에 편중된 설계가 유리하거나 불리할 수 있습니다. 영역별 통과율을 쪼개어 보면 이야기가 달라질 수 있습니다. 어떤 영역에서는 개발자 에이전트가 선전하고 어떤 영역에서는 참패하는 패턴이 숨어 있을 수 있습니다. 평균 하나로는 그 결이 안 보입니다. 영역별 분해가 나오면 어느 업무 지식이 어렵고 어느 대화 패턴이 까다로운지가 드러날 것입니다.

셋째는 비용 축의 부재입니다. 출발 조건에 서빙 비용 제한이 있다고 해도, 공개된 핵심 숫자는 통과율 중심입니다. 같은 통과율이라도 비용이 다르면 현장의 값어치는 다릅니다. 싼 설계로 20퍼센트를 내는 것과 비싼 설계로 23.9퍼센트를 내는 것 중 어느 쪽이 나은지는 예산에 따라 달라집니다. 통과율과 비용을 함께 그린 그림이 나오면 해석이 깊어집니다. 예산을 고정한 채로 무엇을 얻었는지, 예산을 풀면 어디까지 올라가는지가 보이면 이 벤치마크는 더 단단해집니다.

이런 의심은 연구를 깎아내리기 위한 것이 아닙니다. 오히려 숫자를 오래 살리는 법입니다. 한계를 먼저 말해두면 숫자는 공격받아도 남습니다.

모의의 한계를 인정하고, 영역의 편향을 공개하고, 비용 축을 덧붙이면 23.9퍼센트라는 숫자는 더 무거워집니다. 저는 이 벤치마크가 그런 방향으로 자라기를 바랍니다. 첫 발표의 낮은 통과율이 화제를 모으는 역할이라면, 다음 버전의 단단한 분석이 신뢰를 쌓는 역할을 할 것입니다.

다음에 확인하고 싶은 장면들

제가 앞으로 보고 싶은 것을 세 가지 적어보겠습니다. 첫째는 왕복의 기록입니다. 개발자 에이전트가 기록을 몇 번 조회했고 고객과 몇 번 대화했고 설계를 몇 번 바꿨는지가 통과율과 어떻게 연결되는지 보고 싶습니다. 많이 묻고 많이 고친 납품이 정말로 더 잘 통과하는지를 숫자로 확인하고 싶습니다. 이 그래프가 나오면 실패 분석이 처방으로 바뀝니다. 묻는 횟수와 고치는 횟수에 목표를 주면 개발자 에이전트의 행동을 직접 고칠 수 있기 때문입니다.

둘째는 영역별 분해입니다. 네 개 영역에서 통과율과 실패 양식이 어떻게 달라지는지 궁금합니다. 어떤 영역에서는 기록 조회가 병목이고 어떤 영역에서는 고객 대화가 병목일 수 있습니다. 영역마다 병목이 다르면 해법도 달라져야 합니다. 기록 도구를 붙여야 하는 영역과 대화 전략을 고쳐야 하는 영역이 갈립니다. 평균 뒤에 숨은 얼굴들을 보는 일이 다음 단계입니다.

셋째는 비용과 구조의 조합표입니다. 어떤 설계가 어떤 비용으로 어떤 통과율을 냈는지를 모아보고 싶습니다. 싼 모델과 깊은 검색의 조합, 비싼 모델과 얕은 검색의 조합 같은 다양한 점들을 찍어보면 설계 공간의 지도가 그려집니다. 첫 번째로 돌아가는 버전을 넘어서는 실험이 실제로 얼마나 이득인지를 보여주는 증거가 될 것입니다. 실험 없는 납품이 얼마나 손해인지를 숫자로 말해주면 개발자 에이전트의 습관도 바뀔 것입니다.

마지막으로 보고 싶은 것은 실패 사례의 전시입니다. 어떤 납품이 어떤 고객 앞에서 어떻게 무너졌는지를 공개하면 연구 전체의 신뢰가 올라갑니다. 성공 사례만 늘어놓는 논문보다, 함정을 보여주고 막는 법까지 보여주는 논문이 현장에는 더 도움이 됩니다. 만드는 일을 다루는 연구에서는 이런 투명성이 선택이 아니라 조건입니다. 타우타우벤치가 협력의 일을 재는 시험이라면, 그 시험을 만든 사람들의 협력도 투명해야 합니다. 저는 그 다음 장면을 기다리면서 이 글을 맺고 싶습니다.