197단어 텍스트 하네스는 어떻게 나왔나: 코드 셀프플레이와 동결 평가를 나눠 본 논문 | DAKER 커뮤니티

2026년 9월 10일, Building the Harness Automatically 논문이 arXiv에 공개되었습니다. 영문 제목은 Building the Harness Automatically: Self-Play in Code Distills a Text Harness for Black-Box Optimization이며 arXiv 번호는 2609.09468입니다. 이 논문이 던지는 질문은 단순하지만 흥미롭습니다. 에이전트가 실행 가능한 연습을 통해 수치 탐색 전략을 배운 뒤, 그 전략을 짧은 텍스트로 옮겨 평가 단계에 배포할 수 있는가 하는 점입니다.

특히 저예산 블랙박스 최적화에서 도움 없는 언어모델이 강한 고전 최적화기보다 한참 아래에 남는다는 전제에서 출발한다는 점이 눈에 띕니다. 그래서 이 글은 제공된 초록과 정리된 사실 범위만 바탕으로, 코드 셀프플레이와 동결된 텍스트 하네스를 왜 분리해서 봐야 하는지 차분히 정리합니다.

논문이 묻는 핵심: 전략은 코드에서 배우고, 배포는 텍스트로 할 수 있는가

초록에 따르면 개발 단계에서 에이전트는 최적화 프로그램을 반복해 작성하고 평가합니다. 그리고 그 결과 프로그램과 연습 기록을 한 번 증류해 197단어의 기본 Harness A로 만든 뒤, 평가 전에 동결합니다. 여기서 중요한 점은 연습과 평가가 같은 단계가 아니라는 사실입니다.

실행 가능한 연습으로 탐색 정책을 찾고, 그 정책을 텍스트로 옮겨 평가 전에 동결한다는 분리가 이 연구의 중심입니다.

이 구분은 실험 해석에도 직접 연결됩니다. 최적화 코드를 계속 바꾸는 단계와, 이미 정리된 텍스트 하네스를 평가에 쓰는 단계를 한 문장으로 합쳐 버리면 무엇이 성능에 기여했는지 분리해서 보기 어려워집니다. 초록이 강조하는 것도 바로 이 지점입니다.

Harness A가 보여 준 결과

초록은 Harness A가 독립 N=30 연구에서 Gemini Flash 후회(regret)를 48% 줄였고(p<.001), 연습 패밀리에서 GP-BO 성능 구간에 들어가며, 세 개의 held-out BBOB 랜드스케이프에서 평균 후회를 낮춘다고 적습니다. 이 수치들은 논문의 주장 범위를 이해하는 데 핵심이 됩니다.

Harness A는 독립 N=30 연구에서 Gemini Flash 후회를 48% 줄였고(p<.001), held-out BBOB 세 랜드스케이프에서도 평균 후회를 낮췄습니다.

여기서 주의할 점도 분명합니다. 이 결과를 근거로 언어모델이 고전 최적화기를 전면적으로 넘어섰다고 읽으면 초록의 원래 맥락을 벗어나게 됩니다. 초록은 오히려 도움 없는 LM이 강한 고전 최적화기보다 아래에 남는다고 전제한 뒤, 하네스가 그 간극을 줄이는 방향으로 작동한다고 설명합니다.

Harness B와 크로스모델 이전이 뜻하는 것

본문 원문에 따르면 같은 텍스트가 시험한 모든 Gemini 실행기를 개선하고, Claude Sonnet으로도 이전되어 후회를 43%·49% 줄였다고 적습니다(p≤.005). 또 독립 end-to-end 복제로 Harness B가 나오며, 다른 프로그램·텍스트이지만 같은 성능 티어라고 설명합니다. 같은 프레임워크가 봉인된 YouTube 보상 튜닝 프로덕션 벤치에서도 최저 후회를 달성한다고 적습니다.

Harness A와 Harness B는 동일한 문서 복제가 아니라, 다른 프로그램·텍스트이면서 같은 성능 티어에 도달한 사례로 읽는 것이 맞습니다.

이 대목은 특히 과장해서 옮기기 쉬운 부분입니다. 48%와 43%·49%를 하나의 평균처럼 합치면 안 됩니다. 원문은 Gemini Flash와 Claude Sonnet을 구분해 적고 있기 때문입니다. 또한 YouTube 프로덕션 벤치에 대해서도 초록 표현인 최저 후회만 옮기는 것이 적절합니다.

이 실험이 남기는 메시지

초록은 실행 가능한 연습이 탐색 정책을 발견하는 유효한 길이며, 언어가 그 정책을 배포하는 휴대 매체라고 정리합니다. 다시 말해, 성능 향상의 원천을 코드 기반의 셀프플레이에서 찾고, 그 결과를 짧은 텍스트 하네스로 옮겨 배포 가능하게 만든다는 구상입니다.

이 연구의 메시지는 텍스트만으로 모든 최적화가 해결된다는 선언이 아니라, 연습으로 찾은 정책을 언어로 배포할 수 있다는 가능성에 가깝습니다.

그래서 이 논문을 읽을 때는 텍스트 하네스 자체를 만능 도구처럼 보기보다, 연습·증류·동결·이전이라는 단계가 어떻게 나뉘는지 먼저 보는 편이 좋습니다. 그 구분이 있어야 결과를 재현하거나 비교할 때도 해석이 흔들리지 않습니다.

문서화할 때 특히 분리해서 적어야 할 것

원문에는 팀이 코드 셀프플레이와 동결된 텍스트 하네스를 같은 프롬프트에 섞지 말고, 단계를 README에 분리해 적는다는 취지가 반복해서 드러납니다. 이 점은 짧은 안내처럼 보이지만 실제로는 실험 관리의 핵심입니다.

예를 들어 셀프플레이 단계, 197단어 증류 단계, 동결 평가 단계, 크로스모델 이전 단계를 한데 묶어 쓰면 어떤 산출물이 연습용이고 어떤 산출물이 평가용인지 흐려집니다. 반대로 단계를 나눠 적으면 실패 원인도 더 분명하게 추적할 수 있습니다.

연습 단계와 동결 배포 단계를 문서에서 분리해 두면, 성능 해석과 재현 범위를 함께 지킬 수 있습니다.

이 글이 다루는 범위와 다루지 않는 범위

이 글은 제공된 초록과 정리된 사실 범위만 옮깁니다. 저자는 Wu, Yi, Ren, Zheng, Hu, Zhiyu, Wang, Haochen, Chang, Daryl, Wei, Li, Wang, Ting, Li, Zhen, Gupta, Pooja, Jindal, Nitin, Heldt, Lukasz입니다. 초록에 없는 점수, 연구소 순위, 외부 저장소 주소는 덧붙이지 않습니다.

또한 이 글은 DACON·DAKER의 공식 최적화 공지가 아니라 arXiv 2609.09468 초록 안내입니다. 197단어면 모든 블랙박스 문제가 풀린다는 보증도 아니고, YouTube 벤치의 구체 점수를 공개한다는 약속도 아닙니다. Harness A와 Harness B가 동일 텍스트라는 주장 역시 아닙니다.

참고 자료

DAKER 커뮤니티
DACON
DAKER 해커톤
랭킹 가이드
학습 트랙

코드 셀프플레이와 동결된 텍스트 하네스를 분리해 보는 방식이, 여러분의 실험 기록이나 README에도 도움이 될지 궁금합니다.