BOTTLED: 직접 답하는 AI와 재사용 도구를 만드는 AI는 왜 따로 평가해야 할까

상품 설명 수백만 건에서 속성을 추출하거나 검색어와 상품의 관련성을 반복 분류한다고 생각해 보자. 매번 큰 언어 모델에 질문하는 대신, 모델에게 전용 프로그램이나 작은 모델을 만들게 하면 운영비를 줄일 여지가 있다. 그러나 한 문제에 잘 답하는 능력과, 그 능력을 반복 실행할 산출물로 옮기는 능력은 같은가? 이 질문은 모델 선택뿐 아니라 자동화 승인 방식에도 직접 연결된다.

「Agent in a Bottle」은 이 차이를 BOTTLED라는 벤치마크로 평가한다. 이 글은 2026년 10월 6일 최초 제출된 arXiv v1 프리프린트의 본문과 버전 고정 저자 저장소를 기준으로 한다. 동료 심사 통과를 확인한 논문은 아니며, 필자가 모델을 다시 실행하거나 원시 결과를 독립 집계한 재현 보고서도 아니다. 핵심은 ‘저렴한 도구를 만들 수 있다’는 구호보다, 직접 추론·고정 증류·자율 제작의 평가표를 분리해야 한다는 점이다.

무엇을 병에 담는가: 코드 한 파일이 아니라 전체 작업의 해법

논문의 bottling은 일반적인 모델 능력을 특정 반복 작업에 맞는 재사용 해법으로 바꾸는 것을 뜻한다. 에이전트는 정답 라벨이 없는 전체 작업을 받고, 프로그램 작성·작은 모델 학습·두 방식의 결합 등 전략을 스스로 고른다. 결과물 형태는 자유롭지만, 제한된 자원 안에 전체 입력에 대한 예측을 끝내야 한다.

여기서 중요한 구분은 ‘그럴듯한 코드가 생성됐다’와 ‘전체 작업을 처리했다’이다. §3.4의 평가는 최종 예측 파일을 채점한다. 누락된 답에는 작업별 대체값이 들어간다. 따라서 이 점수는 주어진 작업에서의 완성도와 예측 품질을 보여 주지만, 생성 코드의 보안성·유지보수성·미래 입력에 대한 일반화를 모두 인증하지는 않는다.

해법의 제작 방식과 평가 범위를 나누어 읽는다. 서로 다른 표본 범위의 점수를 같은 조건의 대결로 단정하지 않는다. 출처: arxiv.org/html/2610.08775v1.

세 작업은 목적과 척도가 다르다. MAVE는 상품 설명에서 지정 속성의 값을 추출하며 F1으로 평가한다. ESCI는 검색어와 상품의 관계를 Exact·Substitute·Complement·Irrelevant로 분류하며 macro-F1을 쓴다. RAID는 문서의 AI 생성 가능성을 출력하며 AUROC로 평가한다. 논문이 보고한 전체 규모는 각각 약 477만 상품–속성 쌍, 262만 검색어–상품 쌍, 562만 문서다. 이는 원문에 적힌 근사 규모이지, 이번 글에서 실제 행을 세어 확인한 값이 아니다. 서로 다른 척도를 모두 ‘정확도’라고 부르거나 그대로 합산해서는 안 된다.

60회 중 48회가 뜻하는 것, 뜻하지 않는 것

§4.1에서 저자들은 60회의 자율 제작 실행 중 48회가 해당 모델·작업의 직접 추론 점수에 대한 95% 신뢰구간 하한보다 낮았다고 보고한다. 분모는 10개 모델 × 3개 작업 × 각 조합의 독립 제작 실행 2회다. 문제 60개나 서로 다른 작업 60종을 시험했다는 뜻이 아니다.

직접 추론 기준선은 각 작업에서 동일하게 뽑은 1,000개 입력으로 평가하고, 신뢰구간은 2,000회 부트스트랩 재표집으로 계산했다. 제작 산출물은 전체 작업으로 평가하며, Figure 2의 제작 점은 두 실행의 평균이다. ‘개별 실행 48회’와 ‘그림의 평균 점’을 혼동하면 결론이 달라진다. 표본 범위도 다르므로 두 모드를 완전히 같은 연산량·같은 표본 크기의 대결로 설명하면 안 된다.

칸 하나는 예측 하나가 아니라 제작 실행 하나다. 두 비교의 해당 실행이 겹치는지 이 그림으로 알 수 없다. 출처: arxiv.org/html/2610.08775v1.

48/60이라는 비율을 ‘예측의 대부분이 오답이었다’로 번역하는 것도 잘못이다. 비교 대상은 실행별 성능 점수와 기준선의 신뢰구간이다. 또 직접 추론 성적이 제작 성적과 아무 통계적 상관도 없다는 증명은 아니다. 이 실험에서 좋은 직접 답변이 좋은 제작 결과를 안정적으로 보장하지 못했다는 해석이 정확하다. 각 모델·작업에서 제작 실행이 두 번뿐이라는 반복 수의 한계도 남는다.

비슷한 직접 답변, 다른 산출물: ESCI 사례

ESCI에서 GLM 5.3과 GPT 5.6 Terra의 직접 추론 macro-F1은 각각 0.593과 0.573이었다. 그러나 두 제작 실행을 평균한 전체 작업 macro-F1은 0.497과 0.265였다. 직접 답변 점수만 보면 가까운 두 후보가, 해법을 만들어 적용하는 단계에서는 상당히 달랐다. 값은 §4.1과 Table 1의 저자 보고치다.

비슷한 직접 추론 점수가 제작 점수까지 보장하지 않는 사례다. 모든 막대는 0 기준 동일 축이며 신뢰구간이나 인과 효과를 새로 추정하지 않았다. 출처: arxiv.org/html/2610.08775v1.

이 비교는 특정 제공자나 모델 크기가 차이를 일으켰다는 인과 실험이 아니다. macro-F1의 차이를 ‘정확도 몇 퍼센트포인트 하락’으로 바꾸어서도 안 된다. 모델이 어떤 전략을 골랐고 전체 실행을 어떻게 마쳤는지까지 평가해야 한다는 관찰 사례로 읽는 것이 유용하다. 직접 추론 점수는 제작 후보를 고르는 참고값이지, 완성된 도구의 품질 승인서가 아니다.

자율 제작만 비교하면 놓치는 기준선

논문은 자율 에이전트 외에 고정된 증류 경로도 둔다. GLM 5.3 Flash를 교사로 사용해 라벨을 만들고, Qwen3-0.6B와 SmolLM2-360M-Instruct를 학습시키는 방식이다. 두 작은 모델 중 해당 작업에서 더 좋은 모델보다 낮은 자율 제작 실행은 60회 중 31회였다. 모든 에이전트가 증류보다 못했다는 뜻은 아니며, 자율 전략을 쓰는 것 자체가 최선임을 보장하지 않는다는 비교다.

제작 에이전트는 OpenCode와 A100 40GB 한 대, CPU 8코어, RAM 64GB를 사용하고, 최대 10시간과 가중 API 토큰 500만 개를 받는다. 토큰 회계에서 비캐시 입력의 가중치는 1, 캐시 입력은 0.1, 출력은 2다. 평가 대상 모델 자신의 Completion API만 허용된다. 증류 비교 역시 같은 API 토큰 회계를 적용하지만, 이것이 GPU 사용량·벽시계 시간·전체 인프라 비용까지 같다는 뜻은 아니다.

따라서 제목에 등장하는 cheap을 총운영비 절감 보장으로 받아들이지 말자. 이 글은 원문의 큰 비용 절감 배수를 대표 결론으로 사용하지 않는다. 실제 도입 판단에는 학습·검증·실행 비용뿐 아니라 오류 수정과 재제작 비용을 별도로 측정해야 한다. 이는 독자에게 권하는 평가 항목이지, 이번 글에서 측정한 비용 결과가 아니다.

독자가 적용할 승인표: 세 후보를 별도 성적표로 남기기

반복 분류 자동화를 맡길 때는 ‘선택한 큰 모델이 똑똑한가’보다 ‘승인할 도구가 어떤 입력에서 무엇을 놓치는가’를 질문해야 한다. 아래 표는 논문 프로토콜을 그대로 복사한 재현 절차가 아니라, 비교 누락을 줄이기 위한 업무용 설계 제안이다.

지금의 결정	비교에 남길 후보	승인 전에 확인할 항목	피해야 할 결론
제작 모델을 고른다	같은 입력의 직접 추론	작업에 맞는 척도와 평가 표본의 범위	답변 점수가 높으니 제작도 승인
자율 전략에 예산을 준다	고정 증류와 자율 제작	라벨 생성·학습·실행을 구분한 자원 사용	같은 API 토큰이니 총비용도 동일
완성된 도구를 사용한다	실제 제작 산출물	별도 검증 입력의 점수, 누락·파싱 실패, 전체 처리 완료	파일이 있으니 작업도 끝났음
반복 운영을 시작한다	도입 후보와 기존 방식	품질 기준 및 입력 변화 시 재평가 조건	논문 세 작업의 성적이 내 업무 보장

논문의 결과를 업무 의사결정에 적용한 자체 승인 도식이다. 저자의 원 실험 절차나 실측 개선 효과를 표시한 그림이 아니다. 출처: arxiv.org/html/2610.08775v1.

검증 입력을 제작 과정의 점검용 입력과 분리해 두면, 도구를 잘 만드는 대신 시험 답을 얻는 우회가 아닌지 살펴보기 쉽다. 정답이 없는 실제 전체 작업에서 누락을 찾는 검사도 품질 점수와 함께 남겨야 한다. 개인정보나 민감 업무에 바로 연결하지 말고, 허용된 입력의 격리된 평가부터 시작하는 편이 낫다. 아래 승인 기준은 논문 결과에서 도출한 편집자 제안이며, 실제 업무에서 개선 효과를 측정한 실험 결과가 아니다.

가령 검색 관련성 분류라면 단일 평균 점수만 확인하지 말고 네 관계 유형의 취약점을 따로 보자는 판단을 할 수 있다. 다만 이 글이 유형별 새 결과를 측정한 것은 아니다. 기존 방식과 새 도구를 같은 평가 입력에서 비교하고 누락을 별도 기록하는 것이 독자가 수행할 다음 단계다. 논문의 직접 추론 표본과 제작 전체 작업은 범위가 다르므로, 업무용 비교에서 평가 범위를 맞추자는 제안과 원문의 실제 실험 조건은 구별해야 한다.

결과를 믿기 전에 남겨야 할 불확실성

데이터 누출 통제도 완전하다고 단정할 수 없다. Appendix D는 초기 실행 한 건, GLM 5.3 Flash의 RAID 실행을 오염으로 판단했고, URL 차단 목록을 갱신해 다시 실행한 결과로 교체했다고 설명한다. 이는 저자 측 에이전트 판정과 통제 절차의 보고이지, 필자의 독립적인 전체 추적 로그 감사가 아니다. 차단 목록에서 빠진 경로가 있을 수 있다는 한계도 본문에 명시되어 있다.

보존한 저자 저장소의 README에는 오염 판정기와 Jev 평가 코드를 앞으로 추가할 예정이라고 적혀 있다. 또 README는 증류 실행이 최적 학습률을 고른다고 설명하지만, 논문은 작업별 튜닝 없이 비교했다고 서술한다. 따라서 현재 기본 저장소 명령을 실행하면 논문의 튜닝 없는 조건이 그대로 재현된다고 주장할 수 없다. 이번 글에서는 외부 코드를 실행하지 않았으며, 모델 추론·학습·처리 시간이나 비용의 새 실측값은 없다.

범위는 세 언어 작업, 하나의 OpenCode 하네스, 모델·작업당 두 제작 실행이다. 임의의 코딩 프로젝트나 한국어 서비스에 그대로 일반화할 근거는 아니다. 논문에서 평가한 것은 자원 제약 아래의 최종 예측 품질이지 장기 운영 안전성의 전면 검증이 아니다. 이런 한계를 붙여야 ‘AI가 쓸모없다’나 ‘한 번 만들면 공짜’ 같은 과장 대신 실제 승인 방법을 고를 수 있다.

결론: 답변 벤치마크와 제작 승인을 분리하자

BOTTLED의 의미는 모든 자율 제작이 실패한다는 선언이 아니다. 직접 답변 성적만으로 전용 산출물의 품질을 추정하기 어렵고, 간단한 고정 증류도 반드시 비교 후보에 넣어야 한다는 실험적 경고다. 반복 업무를 자동화하려면 제작 후보 선택과 완성 도구 승인을 나누고, 최종 산출물의 품질·누락·자원 사용을 별도로 남기자. 비용 절감은 그 다음에 동일한 업무 조건에서 검증할 가설이다.

출처와 검증 범위

• Agent in a Bottle — arXiv v1 초록 및 버전 정보
• 동일 버전 본문: §3.1–3.5, §4.1·Table 1, Appendix B·D
• 저자 저장소 — 보존한 커밋의 README·평가 설정

본문의 수치와 실험 조건은 출처 보고치이며, 승인표와 업무 적용 제안은 편집자 분석이다. 관련 기존 글의 일반적인 ‘한 번 만들고 저렴하게 실행’ 설명과 중복되지 않도록, 이번 글은 직접 추론 능력의 보존 실패와 비교 기준선에 집중했다. 관련 내부 링크는 추가적인 본문·URL 재검증 없이 임의 삽입하지 않았다.