AI Agent Security (12편): 공개된 해법을 읽고 돌아본 우리의 선택
최종 리더보드를 확인하고 곧바로 11편을 썼다. 공개 8위였던 우리 팀은 최종 115위로 내려갔고, 은메달을 받았다. 공개 점수를 높여 준 직접 HTTP 요청 방식의 제출물은 비공개 평가에서 모두 0점이었다. 메일 방식은 비공개 평가에서도 점수를 얻었다. 아무리 빨리 실행해도 비공개 평가에서 점수가 나지 않으면 소용없다는 것이 당시의 결론이었다.
다른 참가자들의 해법을 읽으면서는 마지막 제출 선택보다 앞선 결정을 돌아보게 됐다. 우리에게도 메일만 사용하는 제출물이 있었고, 비공개 점수는 26.010이었다. 대안은 있었던 셈이다. 그런데 우리는 그 대안을 충분히 개발했을까. 대회 중에 알고 있던 사실만으로도 메일 연구에 시간을 더 쓸 이유가 있었는지 다시 따져보고 싶었다.
이 글에서 다룰 자료는 2026년 9월 3–5일에 공개된 1위·4위·5위·6위·11위의 write-up이다. 다섯 참가자는 비공개 평가의 단서를 해석하는 법도, 모델별 실행 시간을 줄이는 법도 달랐다. 검증에 들인 노력과 최종 제출물 두 개를 고른 이유 역시 같지 않았다. 순위표에는 나오지 않는 이런 차이를 살펴보려 한다.
대회는 주최 측이 제공한 합성 데이터와 모의 도구로 보안 실험을 하는 오프라인 벤치마크였다. 아래의 성적과 측정값은 각 write-up과 11편에 기록된 결과다.
앞선 글:
- 1편: 리플레이 벤치마크와 트래젝터리 탐색 EDA
- 2편: 선형 점수 법칙, 리플레이 한계, 비공개 가드레일에서도 남는 것
- 3편: v3.1.2 평가 변경과 처리량의 벽
- 4편: 프레이밍 고원을 넘어
- 5편: 원점수의 한계를 내부에서 읽다
- 6편: 실험 시스템으로서의 처리량
- 7편: 전이의 문제
- 8편: 평가 방식 변경
- 9편: 작동 여부에서 밀도로
- 10편: 공개 점수 밀도에서 비공개 평가까지
- 11편: 공격 방식이 비공개 평가에서 통하지 않았을 때
영문판: What the Write-ups Changed About Our Search
1. 다섯 참가자의 접근법
대회에서는 제출 알고리즘이 만든 후보 메시지를 평가기가 모델과 모의 도구에 넣어 실행했다. 이 과정을 리플레이라고 부른다. 가드레일이 동작의 허용 여부를 판단하면, 별도의 판정기가 실행 기록에서 채점 조건에 맞는 사건을 찾았다. hop은 모델 호출 한 번을 뜻하고, 점수 셀은 판정기가 구분하는 실행 결과의 범주다. 모델 호출 횟수와 점수를 얻는 동작의 수는 같지 않다.
다섯 글의 핵심은 다음과 같다.
| 참가자 | 연구 질문 | 주요 접근법 | 결과를 읽을 때의 유의점 |
|---|---|---|---|
| 1위 · xz | 비공개 평가에서도 통할 방식을 고른 뒤 실행 비용을 얼마나 줄일 수 있을까? | 평가 결과의 단서로 방향 선택, 기울기를 활용한 탐색, 실제 양자화 모델에서 재검증 | GPT-OSS의 BF16 모델에서 성공한 결과가 실제 양자화 모델에서는 유지되지 않음 |
| 4위 · ISAKA Tsuyoshi 외 | 단순한 구성을 대규모로도 안정적으로 실행할 수 있을까? | 모델별 생성 비용 측정, 소규모 검사 뒤 전체 후보 검증, 사람이 세운 구체적인 가설 | 로컬에서 만든 가드레일이 실제 비공개 구현과 같다는 보장은 없음 |
| 5위 · Giovanny Rodríguez | 다른 도구를 쓸 때도 기존의 실행 최적화 방법을 적용할 수 있을까? | 입력·출력·파싱·대화 이력 재구성에 걸리는 시간 분석 | 개발 전후의 시간 차이만으로 개별 변경의 효과를 알 수는 없음 |
| 6위 · poijio | 원하는 출력에서 거꾸로 찾은 입력이 실제 평가에서도 동작할까? | 목표 출력을 정하고 역으로 탐색, 최종 제출물이 만든 후보를 새 환경에서 재검증 | 특정 호출 구조를 필수 조건으로 정한 탓에 다른 가능성을 충분히 비교하지 못했다는 자평 |
| 11위 · Mohammad Shadab Alam | 성능을 높이면서 알 수 없는 방어 조건에도 어떻게 대비할까? | 반복 대조 실험, 동작의 유효성 확인, 주력과 예비 제출물의 역할 구분 | 가정한 방어 조건은 실제 비공개 규칙이 아니며, 대회 후 제안도 개선 효과가 확인된 것은 아님 |
출력 토큰 수, 리플레이에 걸리는 시간, GPT와 Gemma의 차이, 로컬 검증의 한계는 우리도 앞선 글에서 다룬 내용이다. 5위 저자는 우리가 공개한 처리량 분석을 참고했다고 밝히기도 했다. 그래서 더 아쉬웠다. 우리도 측정 방법은 알고 있었지만, 그 방법을 공개 점수가 가장 높은 후보에 주로 적용했다. 어떻게 측정할지뿐 아니라 무엇을 개선할지도 중요한 선택이었다. 5위 글
2. 비공개 평가에 관한 단서
비공개 가드레일의 코드는 볼 수 없었다. 하지만 참가자들이 아무 근거 없이 후보를 골라야 했던 것은 아니다.
1위 저자는 평가 중에 얻은 간접 정보를 바탕으로 후보별 가능성을 비교했다. 4위 팀도 소규모 제출이 끝났는지, 얼마나 걸렸는지를 보고 비공개 평가의 동작을 추정했다. 이후 그 추정에 맞는 가드레일을 로컬에 만들어 시험했다. 11위 저자 역시 이런 정보가 최종 두 자리를 모두 메일 방식에 배정한 이유 중 하나였다고 쓴다. 세 참가자 모두 비공개 구현 전체를 알아낸 것은 아니었다. 1위 글 · 4위 글 · 11위 글
각 자료로 확인할 수 있는 내용은 달랐다.
| 근거 | 판단에 도움이 되는 부분 | 알 수 없는 부분 |
|---|---|---|
| 공개된 소스와 규칙 | 공개된 평가 과정이 어떻게 작동하는지 확인 | 비공개 가드레일의 구현 |
| 평가 메타데이터 | 어떤 후보가 더 유망할지 판단 | 실행시간만으로 특정 차단 규칙이나 후보별 점수 기여를 확정할 수는 없음 |
| 로컬 대체 가드레일 | 특정 방어 조건을 가정하고 후보의 동작을 비교 | 그 가정이 실제 비공개 평가와 일치하는지 여부 |
실행 시간에는 모델 속도, 처리한 후보 수, 캐시 상태, 실패한 시점 등이 함께 영향을 준다. 시간만 보고 특정 차단 규칙을 확정할 수는 없다. 그래도 후보들을 비교할 단서로는 쓸 수 있었다.
6위 저자는 공개된 평가 구조를 읽고 메일 방식의 가능성을 판단했다고 설명한다. 비공개 구현을 확인하지 못한 상태에서도 연구 시간을 어디에 쓸지 결정할 근거는 있었다. 6위 글
나는 비공개 구현을 알 수 없다는 한계를 지나치게 강조했던 것 같다. 성공을 확신할 정도의 증거는 없어도, 대안에 시간을 더 써 볼 만한 근거는 대회 중에도 있었다.
3. 같은 제출물의 공개·비공개 점수 비교
11위 저자의 공개 최고점은 136.450, 최종 비공개 점수는 30.040이었다. 그러나 두 점수는 서로 다른 제출물에서 나왔다. 공개 최고점 제출물의 비공개 점수는 보고되지 않았다. 최종 주력 제출물 NB1의 공개·비공개 점수는 30.055 → 30.040이다. 136.450에서 30.040으로 떨어졌다고 쓰면 제출물을 바꾼 효과와 평가 조건이 달라진 효과를 섞게 된다. 11위 글
아래 그림은 같은 제출물에서 나온 공개·비공개 점수만 연결한 것이다. 11편에서 다룬 우리의 메일 전용 제출물도 포함했다.
그림 1. 각 선은 같은 제출물의 공개 점수와 비공개 점수를 잇는다. 4위는 대응하는 공개 점수가 없고, 1위는 대략적인 점수만 제시해 그림에서 제외했다. 우리의 메일 전용 제출물은 최종 평가 대상으로 선택하지 않았던 후보다. 출처: 5위, 6위, 11위, 이 시리즈 11편.
5위의 공개 최고점 제출물 v50은 115.240 → 0.000, 최종 선택한 메일 제출물 v57은 40.155 → 40.365였다. 6위도 공개 1위 제출물의 147.530 → 0.000과 금메달을 받은 제출물의 37.530 → 37.690을 구분해 보고했다. 둘 다 공개 점수가 높았던 쪽이 비공개 평가에서 실패했다. 하지만 5위 저자는 공개 점수를 높이며 익힌 실행 분석 방법을 메일 제출물에 다시 적용했다. 제출물은 실패했어도 그 과정에서 배운 방법은 다음 연구에 도움이 됐다. 5위 글 · 6위 글
우리의 메일 제출물도 25.695 → 26.010을 기록했다. 비공개 평가에서 점수를 낼 출발점은 이미 있었다. 다른 참가자들과의 점수 차이를 특정 기법 하나의 효과로 볼 수는 없다. 후보 메시지부터 모델별 처리 방식, 실행 환경, 개발 과정까지 모두 달랐다.
4. 1위: 마무리 응답 최적화
메일 방식에 집중한 이유
1위 xz는 처음에 비공개 가드레일이 어떻게 작동할지 조사했다. 에이전트 보안 논문을 읽고, Codex와 함께 대회 저장소를 살폈다. 요청을 걸러내는 분류기, 행동을 판단하는 별도 모델, 읽어 온 정보의 출처를 추적하는 장치 등을 검토했다. 하지만 연구 방향을 정하는 데 더 도움이 된 것은 실제 평가 결과였다고 한다. 여러 방식의 결과를 비교한 뒤, 직접 메일을 보내는 방식에 집중하면 많은 후보에서 안정적으로 점수를 얻을 수 있다고 판단했다. 비공개 가드레일의 내부를 알아낸 것은 아니었다. 1위 write-up
xz는 다른 참가자들도 메일 방식에 도달할 것으로 예상했다. 여기서 순위를 더 높이려면 이미 작동하는 후보를 더 빨리 실행해야 했다. 그가 주목한 부분은 도구 실행을 마친 뒤 모델이 덧붙이는 응답이었다.
마무리 응답과 두 번째 모델 호출
xz가 사용한 방식은 후보 하나당 도구를 한 번 실행하되, 모델은 두 번 호출했다. 모델이 첫 번째 호출에서 도구 호출문을 생성하면 도구가 실행되고, 두 번째 호출에서 마무리 응답이 나왔다. 점수는 도구 실행 직후에 기록됐다. 따라서 마무리 응답을 생성하는 시간에는 점수가 더해지지 않았다. 후보마다 짧은 응답을 하나씩 덧붙이는 데 그쳐도 전체 후보를 실행하는 동안 그 시간이 쌓였다.
xz는 도구 호출문을 올바르게 생성하면서도 그다음 응답을 바로 끝내는 방법을 찾았다. 두 번째 모델 호출은 그대로 두고, 그 호출에서 처음 생성하는 토큰을 생성 종료 토큰으로 바꾼 것이다. 저자도 댓글에서 모델 호출 자체를 없앤 것이 아니라고 설명했다. 마무리 응답의 토큰 수는 줄었지만, 두 번째 호출에 필요한 준비 작업까지 사라진 것은 아니었다. 1위 write-up과 댓글
탐색에는 모델의 기울기를 이용해 입력의 이산적인 변경을 찾는 GCG를 사용했다. 도구 호출문을 정확히 생성하는 것과 다음 응답을 빨리 끝내는 것을 함께 만족해야 했다. 빨리 끝났더라도 도구 호출에 실패하면 쓸 수 없는 후보였다. 모델이 도구 실행 뒤에는 익숙한 응답 형식을 이어가려는 경향이 강해서, 짧은 종료 출력을 얻기까지 많은 시도가 필요했다고 한다.
Gemma의 성공과 GPT-OSS의 전이 실패
대회에서는 양자화된 GGUF 모델을 사용했다. xz는 기울기를 계산할 수 있는 더 높은 정밀도의 BF16 체크포인트로 탐색했다. BF16에서 찾은 입력이 대회용 GGUF에서도 같은 출력을 내는지는 따로 확인해야 했다.
이 작업을 시작했을 때는 마감까지 약 사흘이 남아 있었다. 초기 입력을 다듬고 탐색을 계속한 끝에 Gemma에서는 원하는 종료 출력을 얻었다. GPT-OSS는 BF16에서 성공했지만, 대회용 GGUF에서는 같은 출력을 만들지 못했다. 마감이 가까워지자 xz는 GPT-OSS 탐색을 중단하고, Gemma에서 찾은 입력이 여러 후보에서도 안정적으로 작동하는지 확인하는 데 집중했다. 1위 write-up
| 모델 | 저자가 보고한 탐색 결과 | 실제 제출에서의 역할 |
|---|---|---|
| Gemma | 대회 모델에서도 짧은 마무리 응답을 생성 | 새 방식을 적용하고 안정성을 추가 검증 |
| GPT-OSS | BF16에서 얻은 출력을 GGUF에서는 재현하지 못함 | 기존의 최소 길이 입력 사용 |
최종 제출에서는 두 모델에 서로 다른 결정을 내렸다. 대회용 모델에서도 개선을 확인한 Gemma에는 새 방식을 쓰고, GPT-OSS에는 기존 방식을 남겼다. 한 모델에서 해결하지 못한 문제가 있었어도 다른 모델에서 확보한 성과는 제출에 반영할 수 있었다.
실행 환경 차이와 출력 안정성
처음 성공한 제출은 약 44.5점을 받았다. xz는 후보마다 달라지는 출력과 실제 추론 환경의 차이 때문에 일부 점수를 잃고 있다고 의심했다. 실제로 실행 라이브러리 버전이나 후보를 연속 평가하는 조건을 바꾸자 모델이 선택하는 출력도 달라졌다. 여러 출력의 선택 가능성이 비슷한 상황에서는 이 정도의 환경 차이도 결과를 바꿀 수 있었다.
xz는 후보 전체에서 같은 동작이 나오도록 추가로 손봤고, 이후 약 46.5점을 기록했다. 이 과정에서 여러 부분을 함께 보완했으므로 상승분을 특정 변경 하나의 효과라고 할 수는 없다. 1위 write-up
저자는 글 끝에서 공격자에게 주어진 권한을 더 분명히 정의하고, 반복된 발견에 주는 보상도 재검토하자고 제안한다. 앞으로의 대회 설계에 관한 의견이다. 이번 성적을 만든 작업을 돌아보면, Gemma의 짧은 마무리 응답을 줄이는 일에도 BF16 탐색, 대회용 모델 확인, 전체 후보 평가가 각각 필요했다. BF16 실험이 성공한 시점에 멈췄다면 실제 제출에 사용할 수 있는지조차 판단하기 어려웠을 것이다.
5. 4위: 단순한 메일 방식의 속도와 안정성
비공개 평가에 대한 확신은 없었다
4위 팀은 41.325점으로 최종 순위를 확인한 뒤에야 안도했다고 한다. 자신들의 방식에 어느 정도 자신은 있었지만, 비공개 평가에서 0점을 받을 가능성도 끝까지 남아 있었다. 지금 보면 성공할 방법을 골랐다고 쉽게 말할 수 있지만, 당시 팀은 그 결과를 모른 채 개발 방향을 정해야 했다. 4위 write-up
팀은 비밀이나 외부 자료를 먼저 읽지 않고 메일을 직접 보내는 방식을 택했다. 입력은 두 모델에 맞게 따로 다듬었다. 평가 결과와 공개 코드에서 얻은 단서로 비공개 가드레일의 동작을 가정하고, 이를 시험할 로컬 환경도 만들었다. 이 환경의 결과는 앞서 얻은 단서와 맞았지만, 팀이 비공개 구현을 그대로 복원한 것은 아니었다. 메일 방식에 개발 시간을 집중하기로 한 결정은 이 정도의 정보에 근거했다.
그다음 과제는 제한 시간 안에 정상적인 도구 실행을 더 많이 마치는 것이었다. 팀은 후보 하나를 실행하는 데 시간이 얼마나 드는지, 후보가 달라져도 같은 결과가 나오는지를 조사했다.
모델별 출력 길이와 캐시의 영향
GPT-OSS에서는 도구 호출 형식을 지키면서 불필요한 추론 출력을 줄였다. Gemma에서는 도구 호출문을 더 짧게 표현할 수 있는지 살폈다. Gemma를 이렇게 수정한 뒤 로컬 실험의 초당 원점수가 약 19–20% 증가했다. 원점수(raw score)는 최종 점수로 환산하기 전의 점수다. 팀이 보고한 가장 큰 개선이었다. 다만 한 모델을 로컬에서 측정한 결과이므로 최종 리더보드 점수가 같은 비율로 올랐다는 의미는 아니다. 4위 write-up
반복 실행에서는 입력 길이를 줄이는 효과가 예상보다 작았다. 팀의 설명에 따르면 후보들이 공유하는 입력은 캐시를 재사용할 수 있었다. 입력이 조금 길더라도 매번 전부 다시 계산할 필요는 없었던 것이다. 반면 출력은 생성하는 데 계속 시간이 들었다. 프롬프트의 글자 수만 세어서는 어느 부분을 줄여야 효과가 큰지 판단하기 어려웠다.
소규모 시험에서 전체 후보 검증으로
처음에는 후보 약 열 개로 출력 형식부터 확인했다. 유망한 변경의 속도를 측정한 뒤에는 전체 2,000개 후보를 평가했고, 여러 GPU 인스턴스에서도 결과를 재확인했다. 적은 후보로 시험하면 명백한 오류를 빨리 찾을 수 있었다. 후보를 늘리면 소규모 시험에서 놓친 오류가 드러날 수 있었다. 그런 오류가 몇 개만 섞여도 최종 점수에 영향을 줄 수 있었다. 4위 write-up
팀은 실행에서 얻은 점수를 걸린 시간으로 나누어 성능을 비교했다. 시간이 줄었더라도 얻은 점수까지 줄었다면 두 값이 각각 얼마나 변했는지 살펴야 했다.
효과를 얻지 못한 시도
끝내 해결하지 못했거나, 개선이라고 판단하기 어려웠던 시도도 있었다.
| 시도 | 보고된 결과 | 여기서 확인한 점 |
|---|---|---|
| 도구 실행 뒤의 응답을 없애기 | 달성하지 못함 | 마무리 응답의 생성 자체를 생략하지는 못함 |
| 한 상호작용에 더 많은 행동을 묶기 | 팀의 보상 계산에서는 여러 동작을 묶은 쪽의 원점수가 낮았음 | 같은 수의 행동이라도 묶는 방식에 따라 보상이 달라졌음 |
| 공통 입력을 조금 줄이기 | 로컬의 시간 단축 폭이 서버 실행 시간의 변동보다 작았음 | 그 차이만으로 서버 성능의 개선을 확신하기 어려웠음 |
팀은 Codex로 실행 코드를 살피고, 여러 입력을 만들어 시험하고, 측정 결과를 정리했다. 다만 무엇을 시험할지는 사람이 구체적으로 짚어 주는 편이 효과적이었다고 한다. 막연히 더 빠른 방법을 찾으라고 하면 측정 오차와 구별하기 어려운 작은 변경이 많이 나왔다. 어느 작업에 시간이 걸리는지 가설을 세워 질문했을 때 더 유용한 실험을 얻었다. 4위 write-up
글의 마지막에는 평가 방식에 대한 비판도 나온다. 사용자 권한을 판단하는 규칙과 반복된 실행에 주는 점수가 참가자들의 연구 방향을 결정했다는 것이다. 저자들은 사용자의 의도를 더 정확히 판단하고, 반복된 발견이 차지하는 비중을 줄이자고 제안했다. 이 팀의 작업을 읽고 나니, 단순한 방식을 골랐다는 이유로 남은 개발까지 단순하다고 생각하기는 어려웠다. 모델별 출력 형식부터 전체 후보의 오류율, 작은 속도 차이의 재현성까지 확인할 일이 많았다.
6. 5위: 전체 실행 시간 분석
HTTP를 실험 대상으로 삼은 이유
Giovanny Rodríguez는 공개 평가에서 이미 안정적으로 작동하던 HTTP 방식으로 연구를 시작했다. 문제는 성공 여부보다 실행 시간이었다. 비공개 평가에서도 이 방식으로 안정적인 점수를 얻으리라고 기대하지는 않았지만, 시간을 측정하고 개선 방법을 시험하기에는 적합하다고 보았다. 최종 제출에 쓸 방식과 실행 과정을 연구할 대상을 따로 고른 셈이다. 5위 write-up
저자가 바꾼 것은 제출하는 사용자 메시지뿐이었다. 모델 가중치, 서버, 파서, 평가기는 바꾸지 않았다. 메시지는 모델별 대화 템플릿에 들어가고, 모델은 출력을 생성한다. 파서는 이를 도구 호출로 해석하며, 도구 실행 뒤에는 다음 생성에 쓸 대화 이력이 다시 만들어진다. 저자는 이 연속된 변환을 ‘replay compiler’라는 이름으로 설명했다. 평가기에 프로그램을 추가한 것이 아니라, 기존 평가 프로그램에서 메시지가 어떻게 처리되는지 분석한 것이다.
특히 다음 응답을 생성하기 전에 대화 이력을 다시 만드는 과정에 주목했다. 모델이 출력한 짧은 도구 호출문이 다음 입력에도 그대로 들어가는 것은 아니었다. 실행 프로그램은 도구 호출문을 정해진 형식으로 바꾸어 대화에 넣을 수 있었다. 따라서 첫 출력이 짧아져도 다음 입력을 처리하는 시간까지 줄어든다고 볼 수는 없었다.
도구 호출 전후의 시간 비중
저자는 전체 실행 시간을 다음 세 항으로 나눴다.
\[T = T(1) + T(2) + T(\mathrm{rest}).\]첫 번째 항은 도구 호출 전 모델 처리 시간, 두 번째는 도구 실행 후 마무리 응답을 만드는 시간이다. 마지막 항은 전체 시간에서 앞의 두 시간을 뺀 값이다. 도구 실행과 프로그램 내부 처리 등이 함께 포함되므로 도구 자체의 실행 시간만 따로 잰 값은 아니다.
| 최종 비교에 사용한 모델별 실행 시간의 비중 | GPT-OSS | Gemma |
|---|---|---|
| 도구 호출 전후의 모델 처리 시간 합계 | 95.4% | 98.2% |
| 그중 도구 실행 후 단계 | 27.2% | 40.3% |
점수는 이미 얻었는데도 마무리 응답을 만드는 데 전체 시간의 상당 부분이 쓰이고 있었다. 이 때문에 저자는 도구 호출 뒤의 생성 과정까지 조사했다. 표의 비율은 각 모델의 전체 시간에서 계산한 값이다. 서로 다른 모델이 하드웨어를 얼마나 효율적으로 쓰는지 비교한 수치는 아니다. 5위 write-up
속도를 비교할 때는 유효 판정 200개와 서로 다른 점수 셀 200개를 얻고 정상적으로 끝나는 것을 조건으로 삼았다. 도구 호출을 200번 성공했어도 같은 셀로 합쳐져 보너스가 줄었다면 동일한 작업량으로 보지 않았다. 필요한 행동을 건너뛰고 일찍 끝난 후보도 제외했다. 같은 점수를 얻는 작업을 얼마나 빨리 끝내는지 비교하려는 조건이었다.
GPT-OSS와 Gemma에서 확인한 차이
GPT-OSS를 분석할 때는 모델이 학습한 대화 형식, 파서가 받아들이는 출력 형식, 도구 실행 뒤 재구성된 대화 이력을 함께 살폈다. 단순히 추론을 줄여 달라고 요청해서는 이미 얻은 개선을 안정적으로 재현할 수 없었다. 기록된 결과만으로 내부 추론을 꺼서 빨라졌다고 설명할 수는 없었다.
중복처럼 보이는 텍스트를 지운 실험에서는 오히려 실행이 느려지고 목적지 값까지 달라졌다. 눈으로 읽을 때 불필요해 보였던 부분도 모델의 동작에는 영향을 주었던 것이다. 이후 저자는 두 번의 생성 시간을 함께 비교하며 정상적으로 실행되는 입력을 찾았다. 최종 GPT-OSS 입력은 평균 84.358초에 실행을 마쳤다. 직전 대조군의 86.666초보다 2.66% 짧았다. 이 수치는 마지막 비교에서 얻은 개선이며, 개발 과정 전체의 누적 개선율은 아니다. 5위 write-up
Gemma는 시험한 템플릿에서 thinking을 꺼 두면 빈 thought 채널이 이미 들어갔다. 생각하지 말라는 지시를 추가해 없앨 추론 단계가 더 있는 것은 아니었다. 저자는 도구 호출문을 얼마나 짧게 생성하는지, 매번 같은 형식으로 생성하는지, 그 뒤에 어떤 마무리 응답이 나오는지를 살폈다.
한 로컬 실험에서는 짧은 표현을 쓰는 후보 100개와 표준 표현을 쓰는 후보 100개를 번갈아 실행했다. 모두 정상적으로 점수를 얻었고, 후보당 평균 시간은 각각 1.603초와 1.683초였다. 개발 전후의 별도 실행을 비교할 때보다 두 방식을 비슷한 조건에서 시험한 결과였다. 물론 이 차이도 해당 로컬 실험에서 얻은 결과다. 최종 Gemma 입력의 평균 실행 시간은 266.998초였다. 직전 대조군의 282.324초보다 5.43% 줄었다. 5위 write-up
한 모델에서 효과가 있던 변경이 다른 모델에서는 실행을 늦추기도 했다. 모델이 짧은 호출문을 출력하더라도, 프로그램이 다음 입력을 다시 만들면서 그 길이가 늘어날 수도 있었다. 입력이나 출력의 길이 하나만으로 두 모델의 실행 시간을 설명하기는 어려웠다.
누적 시간 단축과 마무리 응답의 역효과
개발 초기와 최종 입력으로 후보 200개를 실행한 결과는 다음과 같다. 모두 유효 판정 200개와 점수 셀 200개를 얻었다.
| 모델 | 개발 초기 실행 | 최종 선택한 구성의 평균 | 시간 감소율 |
|---|---|---|---|
| GPT-OSS | 109.373초 | 84.358초 | 22.9% |
| Gemma | 396.973초 | 266.998초 | 32.7% |
그림 2. 초기값은 각각 한 번 실행한 결과이고, 최종값은 선택한 구성을 두 번 실행한 평균이다. 개발 전후의 차이를 보여주는 자료이므로, 이것만으로 개별 변경의 효과나 모델 사이의 하드웨어 효율을 판단할 수는 없다. 출처: 5위 글.
시간 감소율은 1 - 이후 시간 / 이전 시간으로 계산한다. 처리량 증가율은 이전 시간 / 이후 시간 - 1이다. 같은 작업을 실행했더라도 두 식은 분모가 다르므로 같은 비율이 나오지 않는다.
초기 실험 중에는 첫 단계만 빨라진 경우도 있었다. 아래 Gemma 실험은 최종 결과와 GPU 실행 설정이 다르다. 도구 호출 전에는 시간을 줄였지만, 마무리 응답이 길어져 전체 시간은 늘었다.
| 구성 | 첫 단계 | 마무리 단계 | 그 외 소요 시간 | 전체 |
|---|---|---|---|---|
| 영어 입력을 쓴 대조군, 2회 평균 | 176.879초 | 121.671초 | 4.657초 | 303.207초 |
| 첫 단계가 빨라진 초기 변경안 | 171.079초 | 133.613초 | 4.778초 | 309.470초 |
| 변경안 − 대조군 | −5.800초 | +11.942초 | +0.121초 | +6.263초 |
그림 3. 나머지 시간과 구성 간 차이는 저자가 보고한 수치로 계산했다. 여기서 비교한 초기 변경안은 그림 2의 최종 구성과 다르다. 출처: 5위 글.
보고된 수치로 단계별 시간 차이를 계산할 수 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
from decimal import Decimal as D
# Stage timings in seconds from the fifth-place write-up.
control = {"first": D("176.879"), "post": D("121.671"),
"total": D("303.207")}
variant = {"first": D("171.079"), "post": D("133.613"),
"total": D("309.470")}
for row in (control, variant):
row["residual"] = row["total"] - row["first"] - row["post"]
delta = {key: variant[key] - control[key] for key in control}
assert delta["total"] == sum(delta[k] for k in ("first", "post", "residual"))
print(delta["total"]) # 6.263 seconds slower overall
저자는 이 초기 변경안에서 마무리 응답이 다시 생성됐다고 설명한다. 마무리에 더 걸린 시간이 첫 단계에서 줄인 시간보다 컸다. 첫 출력만 비교했다면 전체 실행이 느려졌다는 사실을 놓쳤을 것이다. 이 한 번의 비교로 메시지에 사용한 언어가 일반적으로 유리하거나 불리하다고 판단할 수는 없다.
메일 방식에 맞춘 재구현
이후 저자는 HTTP를 분석하며 익힌 방법을 메일 방식에도 적용했다. 도구가 바뀌니 인자가 달라졌고, 실행 뒤 다음 생성에 넘기는 대화 이력도 달라졌다. 기존 메시지를 그대로 옮겨서는 충분하지 않았다. 다른 도구를 선택하거나 엉뚱한 인자를 복사하는 후보도 나왔다. 실행 시간을 분석하는 방법은 다시 쓸 수 있었지만, 메일 후보가 올바르게 동작하는지는 새로 시험해야 했다. 5위 write-up
GPT-OSS로 메일 후보를 세 번 실행한 시간은 86.500초, 85.590초, 84.739초였다. 세 번 모두 유효 판정과 점수 셀을 200개씩 얻었다. 채택한 Gemma 입력도 세 번의 실행에서 같은 조건을 만족했고, 평균 시간은 263.427초였다. 다만 같은 메시지를 써도 실행 시간이 크게 달라진 기록이 있었다. 메일 방식으로 옮겨 정상 동작을 확인한 결과이지, 평가 서버에서도 이전과 같은 개선 폭을 얻는다고 보장하는 결과는 아니다.
최종 점수는 공개 최고점을 기록한 HTTP 제출물 v50이 115.240 → 0.000, 최종 선택한 메일 제출물 v57이 40.155 → 40.365였다. 메일 제출물이 비공개 평가에서도 점수를 얻었다는 사실은 확인된다. 하지만 로컬에서 시도한 개별 변경이 이 최종 점수에 얼마나 기여했는지는 알 수 없다. 저자 역시 나중에 확보한 코드가 최종 선택한 버전과 정확히 같은지까지는 확인하지 못했다고 밝혔다. 5위 write-up
실패한 시도와 결론을 보류한 실험
실패한 실험도 여러 가지였다. 요청을 줄였는데 출력은 다시 길어지기도 했고, 목적지 값을 바꾼 뒤에는 도구 호출을 200번 성공하고도 서로 다른 점수 셀을 얻지 못한 경우가 있었다. 사전 워밍업 덕분에 첫 후보는 빨라졌지만 전체 후보를 처리하는 데는 더 오래 걸리기도 했다. 여러 동작을 연속 실행하는 데 성공했다는 사실만으로 초당 점수가 더 높다고 할 수는 없었다. 한편 하드웨어 오류로 끝난 실험에서는 메시지의 성능을 판단하지 않았다. 측정을 마치지 못한 결과를 후보의 실패와 구별한 것이다.
Rodríguez의 HTTP 제출물은 비공개 평가에서 실패했지만, 그 개발 과정에서 익힌 분석 방법은 메일 제출물을 만드는 데 쓰였다. 우리 역시 공개 평가의 처리량을 분석하며 실행 시간의 상당 부분이 어디에 쓰이는지 알고 있었다. 돌아보면 그 연구가 쓸모없었던 것이 아니라, 다른 방식에도 충분히 적용해 보지 못한 점이 아쉽다. 새로운 도구에 맞춰 다시 구현하고 검증하는 작업까지 해야 기존 연구가 대안의 성능으로 이어질 수 있었다.
7. 6위: 목표 출력에서 출발한 탐색의 성과와 한계
공개 1위 제출물과 최종 금메달 제출물
poijio는 마감을 약 3주 앞두고 참가해 개인 참가자로 금메달을 받았고, 최종 6위에 올랐다. 공개 평가에서 147.530으로 1위에 오른 제출물 외에 37.530을 기록한 메일 제출물도 개발했다. 최종 결과가 공개된 뒤 확인한 비공개 점수는 각각 0.000과 37.690이었다. 금메달은 메일 제출물의 성적이었다. 6위 write-up
저자는 공개 평가 성능이 비공개 평가 성능을 보장하지 않는다는 주최 측 설명에 주목했다. 공개된 평가 코드를 읽고 메일 방식이 비공개 평가에서도 점수를 얻을 가능성이 있다고 판단했다. 숨겨진 가드레일을 직접 확인할 수는 없었으므로 추정에 따른 선택이었다. 저자는 이 판단과 마감까지 남은 시간을 고려해 메일 방식을 개발했다고 설명한다.
공개 1위 제출물은 후보 하나에서 점수를 얻는 동작을 여덟 번 수행했다. 동작마다 후보를 새로 시작하는 대신 한 번의 준비로 여러 동작을 실행하면 준비에 드는 시간을 줄일 수 있었다. 저자는 메일에서도 여덟 동작을 반복하는 구조를 사용했다. 다만 도구와 배점이 달라진 뒤에도 이 구조가 유리한지는 다시 비교해야 했다.
짧은 목표 출력과 실제 생성 결과
저자는 먼저 짧고 유효한 실행 결과를 정한 뒤, 모델이 생성하는 결과가 어디에서 달라지는지 조사했다. 이를 ‘output-first’라고 불렀다. 단순히 점수가 나는지 확인하는 데서 나아가, 목표한 출력에 도달하지 못하는 지점을 구체적으로 찾으려는 접근이었다. 그렇다고 처음 정한 목표 출력을 이미 얻은 성과로 볼 수는 없었다.
진단 실험에서 출력을 지정해 실행하면 파서가 그 형식을 처리할 수 있는지는 알 수 있다. 하지만 실제 제출에서는 입력을 받은 모델이 스스로 그 출력을 생성해야 한다. 앞서 생성한 내용과 도구 실행 결과도 다음 응답에 영향을 주었다. 같은 대화처럼 보이는 텍스트를 다시 만들어 넣어도 실제로 이어서 실행했을 때와 결과가 다를 수 있었다. 따로 시험한 중간 단계가 각각 성공했다고 해서 전체 과정을 이어서 실행할 수 있다는 뜻은 아니었다.
여덟 동작을 수행하는 메일 후보의 출력은 다음과 같이 짧아졌다.
| 모델 | 초기 출력 토큰 | 최종 출력 토큰 | 최종 입력 토큰 누적 합계 |
|---|---|---|---|
| GPT-OSS | 506 | 149 | 9,624 |
| Gemma | 174 | 140 | 10,240 |
여덟 동작을 마칠 때까지 저자가 측정한 토큰 수다. 출력 토큰은 모델이 생성한 토큰의 합이고, 입력 토큰은 여덟 번의 생성에 들어간 입력을 모두 더한 값이다. 이전 대화가 다음 입력에도 포함되므로, 마지막 열은 최초 메시지의 길이와 다르다. 6위 write-up
출력은 짧아졌어도 모델에 들어가는 누적 입력은 길었다. 이전 대화를 다음 생성에 다시 넣어야 했고, 이 중 실제로 얼마나 다시 계산하는지는 캐시를 얼마나 재사용할 수 있는지에 따라 달랐다. 실행을 준비하고 생성을 끝낼지 결정하는 데도 시간이 들었다. 저자는 토큰 수로 대략적인 비용을 비교하면서 탐색하되, 변경을 채택할 때는 전체 실행 시간을 확인했다. 표의 최종 토큰 수는 탐색에서 찾은 값이며, 가능한 모든 입력 중 최솟값을 증명한 것은 아니다.
후보별 평가에서 드러난 실패
같은 프로세스에서 시험할 때 여덟 동작을 마친 후보가 후보별로 분리해 평가하자 한 번이나 일곱 번만 실행한 사례가 있었다. 한 소규모 후보군에서는 성공한 후보가 12개 중 12개에서 12개 중 5개로 줄었다. 앞선 실험 조건에서는 드러나지 않던 문제가 분리 평가에서 나온 것이다. 이는 그 후보군의 결과이며, 최종 후보 전체의 성공률을 추정한 수치는 아니다. 6위 write-up
탐색 지표가 좋아져도 실제 출력은 실패할 수 있었다. 목표 출력과 전체적으로 비슷하더라도 필요한 부분을 모델이 생성하지 않으면 도구를 실행할 수 없었다. 출력이 짧아진 이유가 동작을 끝내기 전에 멈췄기 때문인 후보도 쓸 수 없었다. 마지막에는 탐색 도중 시험했던 입력에 만족하지 않고, 완성된 제출 코드에서 나온 후보를 다시 평가했다.
저자가 검증에 많은 시간을 쓴 이유가 여기에 있다. 탐색 실험에서 쓴 입력과 최종 프로그램의 입력이 같은 듯 보여도 동작은 달라질 수 있었다. 로컬에서 얻은 개선을 제출에 반영하려면 최종 프로그램에서도 같은 결과가 나오는지 확인해야 했다.
배점이 달라진 뒤에도 남은 여덟 동작 조건
그런데 저자가 회고에서 가장 아쉬워한 것은 검증 방법보다 마지막에 고정한 탐색 조건이었다. 마감을 앞두고 여덟 동작을 성공하는 후보만 받아들이기로 한 것이다.
평가기는 개별 동작의 점수에 더해 서로 다른 평가 셀에 보너스를 주었다. 같은 셀에 해당하는 동작을 반복하면 동작 점수는 쌓이지만 셀 보너스는 늘지 않았다. 동작의 배점이 낮아지면 셀 보너스를 잃는 영향이 더 커졌다. 저자는 이를 다음 계산으로 설명했다.
| 저자가 비교한 경우 | 각각 다른 셀을 만드는 단일 동작 후보 8개 | 후보 하나에서 한 셀에 해당하는 동작 8회 | 원점수 감소율 |
|---|---|---|---|
| 앞서 사용한 고배점 유형 | 144 | 130 | 9.7% |
| 배점이 낮은 메일 유형 | 48 | 34 | 29.2% |
서로 다른 셀을 만드는 단일 동작 후보 여덟 개와, 한 셀에 해당하는 여덟 동작을 수행하는 후보 하나의 보상을 비교한 예시다. 처리량을 측정한 표는 아니다. 셀 보너스는 모델·가드레일 조합마다 평가한 후보 전체에서 중복을 제거한다. 따라서 여러 후보가 같은 셀을 반복한다면 각 후보를 따로 평가한 원점수를 그대로 더할 수 없다. 6위 write-up
대안은 이미 있었다. 여덟 동작을 수행하면서도 서로 다른 셀을 만드는 방식이 로컬에서 작동했다. 다만 GPT-OSS가 305~341토큰을 출력해야 해서, 최종 후보의 149토큰보다 길었다. 한 번만 동작하는 메일 제출물도 시험했다. 짧은 반복 출력으로 시간을 아끼는 것과, 더 긴 출력을 감수하고 셀 보너스를 얻는 것 사이에서 선택해야 했다.
하지만 여덟 동작을 필수 조건으로 삼은 뒤에는 그 구조의 출력을 줄이는 데 탐색이 집중됐다. 저자의 로컬 평가에서 최종 후보들은 각 모델 안에서 같은 셀을 반복했고, 후보를 더 실행해도 셀 보너스는 계속 늘지 않았다. 다른 후보를 택했으면 비공개 점수가 더 높았을지는 알 수 없다. 전체 실행 시간도 비교해야 하기 때문이다. 다만 배점이 바뀌었는데도 이전의 여덟 동작 조건을 고정해 둔 결정은 재검토할 여지가 있었다.
Codex의 실행과 사람의 선택
저자는 전략과 실험 과정을 직접 설계했고, Codex가 구현·평가·제출 코드를 작성했다고 설명한다. 저장소에 남은 1,268개의 실험 디렉터리도 1,268개의 발견을 뜻하지는 않는다고 강조한다. 많은 실험을 진행하는 가운데 메일 방식에 투자하기로 하거나 탐색 질문을 바꾼 결정은 사람이 내렸다. 6위 write-up
실험을 많이 한다고 비교 대상까지 저절로 넓어지지는 않았다. 정해 놓은 조건 안에서는 후보가 개선됐지만, 그 조건 때문에 제외된 대안이 더 나은지는 확인하지 못했다. 나 역시 특정 구현이 실패했을 때 그 방향 전체를 너무 빨리 포기한 적이 있었다. poijio의 경우에는 한때 성공했던 구조를 계속 붙들고 있었던 점이 문제였다. 실패한 구현을 다시 볼 필요가 있는 것처럼, 성공한 방식도 전제가 달라지면 다시 비교해야 한다.
8. 11위: 성능 측정과 최종 제출 선택
Mohammad Shadab Alam은 공개 평가 9위, 비공개 평가 11위로 대회를 마쳤다. 그의 글에는 구별해서 읽어야 할 제출물이 세 개 나온다. 공개 최고점 136.450을 낸 제출물과, 최종 선택한 NB1, NB2다. NB1은 처리량을 높이는 데 집중했다. NB2는 더 느리더라도 NB1과 다른 방어 조건에서 살아남을 수 있는지 살펴본 대안이었다. 공개 최고점 제출물이 최종 순위를 결정한 것은 아니다. 11위 write-up
공개 최고점 대신 메일 제출물 두 개를 고른 이유
공개 최고점 제출물은 최종 두 개에 포함되지 않았다. 그 제출물의 비공개 점수도 원문에 나오지 않는다. 같은 제출물의 공개·비공개 점수를 나란히 비교할 수 있는 것은 NB1의 30.055 → 30.040, NB2의 19.340 → 19.325다. 둘 다 메일 방식이었다.
저자는 평가 과정에서 얻은 간접적인 정보가 최종 선택에 영향을 줬다고 설명한다. 비공개 가드레일의 구현을 확인한 것은 아니지만, 공개 최고점 제출물을 그대로 고르기보다 메일 방식에 두 자리를 쓰는 편이 낫다고 판단했다. 높은 공개 점수를 만든 제출물은 실행 시간을 연구하는 데 계속 활용했다.
모델 처리 시간과 로컬 캐시의 영향
저자는 메모리 96 GB의 RTX PRO 6000에서 llama.cpp와 대회용 양자화 모델로 실험했다. 실험에서는 입력 토큰 수가 출력 토큰 수보다 훨씬 많았지만, 전체 시간의 약 79–89%는 출력 토큰 생성에 쓰였다. 입력이 길다는 이유만으로 입력 처리에 가장 많은 시간이 들 것이라고 생각하면 병목을 잘못 짚게 되는 경우였다.
저자는 모델 호출 한 번에 걸리는 시간과 출력 토큰 하나를 생성하는 시간을 나누어 추정했다. 호출 횟수와 출력 토큰 수가 다른 두 실행에서 후보당 시간은 36.80초와 5.84초였다. 상수항을 0으로 두고 이 두 측정값에 맞춰 두 계수를 구했다. 이 모형은 해당 가정 아래에서 두 값에 정확히 맞지만, 별도의 고정 시간이 실제로 없다는 사실까지 확인한 것은 아니다. 다른 입력과 실행 환경에 같은 계수를 적용할 수 있는지도 따로 확인해야 한다.
로컬 실험에서는 prefix cache 덕분에 입력의 상당 부분을 다시 계산하지 않고 있었다. 입력 전체를 다시 처리하도록 비교하자 실행 시간이 GPT에서 90%, Gemma에서 122% 늘었다. 저자는 로컬과 평가 서버의 시간 차이를 약 35배로 보정한 뒤, 계수를 다시 맞추지 않고도 세 번의 서버 점수를 설명할 수 있었다고 보고했다. 이 보정을 적용하니 로컬에서는 시간에 여유가 있던 후보도 평가 서버에서는 제한 시간을 넘길 수 있었다.
이 보정값을 다른 환경에도 그대로 쓸 수는 없다. 캐시 사용 방식, 런타임, 하드웨어, 생성한 출력이 바뀌면 총시간과 개선율이 모두 달라질 수 있다. 로컬에서는 캐시 덕분에 입력 처리 시간을 줄일 수 있었다. 평가 서버에서 필요한 시간을 예측하려면 이 차이를 반영해야 했다.
실패해서 짧아진 출력
후보가 짧은 출력만 남기고 끝났다고 해서 개선된 것도 아니었다. 필요한 행동을 하지 못해 빨리 끝났을 수 있기 때문이다. 저자가 보고한 세 입력의 결과를 비교하면 토큰 수와 점수를 함께 봐야 하는 이유가 분명하다.
| 구성 | 후보당 생성 토큰 수 | 후보당 원점수 |
|---|---|---|
| 대조군 | 35.25 | 6.000 |
| 출력이 짧아진 변형 | 31.00 | 5.25 |
| 대부분의 실행에서 의도한 행동을 하지 못한 변형 | 2.31 | 0.210 |
세 번째 입력은 대부분의 실행에서 의도한 행동을 하지 못했다. 그런데 이 입력이 네 가지 표현을 번갈아 사용하는 풀에도 들어 있었다. 실패한 후보가 빨리 끝난 탓에 평균 토큰 수에서는 문제가 잘 드러나지 않았고, 오류는 몇 주 동안 발견되지 않았다. 후보당 평균 원점수는 목표인 6.00에 못 미치는 4.52였다. 이 풀을 수정하자 초당 원점수가 약 4.5% 늘었다고 한다. 11위 write-up
여러 표현을 번갈아 쓰려면 각각을 따로 평가해야 했다. 다른 후보 집합에서는 처음 만든 194개 중 54개가 초기 검사를 통과했고, 더 큰 시험에서도 정상적으로 작동한 것은 39개였다. 최종적으로 일곱 개를 사용했다. 이 숫자는 검사를 거치며 후보를 줄여 간 과정이다. 다른 문제에서도 이 정도를 검사하거나 같은 수의 후보를 쓰면 충분하다는 뜻은 아니다.
저자는 표현을 여러 개 썼다는 사실만으로 성능 개선을 설명하지 않았다. 시험을 통과한 여러 표현이 기존 표현 하나보다 좋았다면, 기존 표현의 품질이 나빴기 때문일 수도 있었다. 다양성을 늘려도 실행 시간이 거의 달라지지 않은 실험이 있었고, 오히려 정상 동작이 줄어든 실험도 있었다. 문자열의 개수 외에 각 표현이 실제로 무엇을 하는지, 어떤 대조군과 비교했는지를 함께 살펴야 했다.
반복 비교에서 뒤집힌 다섯 가지 결론
같은 입력을 greedy decoding으로 반복 실행하면 토큰 수는 같았지만 처리량은 실행마다 최대 16.6%까지 달라졌다. 따로 실행한 결과를 비교해 얻었던 결론 다섯 개가 하루 만에 A–B–B–A 순서의 반복 비교에서 뒤집혔다. 한 블록에 넣는 후보 수를 25배 늘려도 표준편차는 1.968%에서 1.830%로 줄어드는 데 그쳤다. 한 번의 실험을 크게 만드는 것으로는 실행 사이의 변동을 충분히 줄이지 못했다.
ABBA는 비교할 두 구성을 A와 B로 두고 A–B–B–A 순서로 반복 실행하는 방법이다. 두 구성을 실행하는 시점을 균형 있게 배치해 시간에 따른 일부 변동의 영향을 줄인다. 워밍업 차이나 불규칙한 시간 변동, 앞선 실행이 다음 실행에 미치는 영향까지 모두 없애지는 못한다. 저자는 실행 중간에서 유리하게 나온 블록 하나를 대표값으로 골랐다가 가장 좋은 후보의 성능을 10% 높게 평가한 사례도 보고했다.
여러 번 측정했더라도 평균을 어떻게 계산했는지에 따라 해석이 달라진다. 전체 시간 동안의 처리량은 유효한 결과를 모두 더한 뒤 총시간으로 나누어 계산한다.
\[R = \frac{\sum q}{\sum t}.\]1
2
3
4
5
6
7
8
# Synthetic accounting example: completed valid items and elapsed seconds.
blocks = [(100, 10.0), (100, 100.0)]
pooled = sum(q for q, _ in blocks) / sum(t for _, t in blocks)
unweighted = sum(q / t for q, t in blocks) / len(blocks)
print(round(pooled, 3)) # 1.818 valid items / second overall
print(round(unweighted, 3)) # 5.500: a different estimand
위 코드는 실제 대회 데이터가 아닌 가상 예시다. 첫 번째 계산은 전체 실행에서 처리한 양을 총시간으로 나눈다. 두 번째 계산은 각 블록의 처리량을 구한 뒤 두 값의 평균을 낸다. 전체 처리량을 구할 목적이라면 첫 번째 값을 써야 한다. 두 계산 모두 산술적으로는 맞지만, 블록마다 소요 시간이 다른데 동일한 비중을 주면 서로 다른 값이 나온다. 어느 계산도 집계값만으로 측정의 불확실성까지 알려주지는 않는다. 이를 추정하려면 반복 측정한 원자료가 필요하다.
오래 사용한 대조군도 다시 확인할 필요가 있었다. 입력 바이트가 같은 후보가 재부팅 전에는 500/500 성공했지만, 재부팅 후에는 0/100이 된 사례가 있었다. 이 결과만으로 원인을 알 수는 없었지만, 예전 대조군이 지금도 정상적으로 작동한다고 가정할 수 없게 됐다. 또 다른 제출에서는 세 가지를 한꺼번에 바꾼 뒤 69점 하락을 겪었다. 나중에 보니 모델 식별 중 발생한 예외를 무시한 탓에 한 모델에 다른 모델용 후보를 전달하고 있었다. 이때는 연구 아이디어보다 소프트웨어의 동작부터 확인해야 했다.
NB1과 NB2의 차이
최종 선택한 두 제출물의 차이는 다음과 같다.
| 항목 | NB1 v11b | NB2 v14 |
|---|---|---|
| 공개 점수 | 30.055 | 19.340 |
| 비공개 점수 | 30.040 | 19.325 |
| GPT 문장 구조 | 같은 문장에서 일부 값만 변경 | 문장 템플릿 503개 |
| Gemma 문장 구조 | 공통 문장 구조 사용 | 문장 템플릿 53개 |
| 설계 목적 | 처리량에 집중한 주력 제출물 | 더 다양한 문장 구조로 주력 제출물의 실패에 대비 |
두 제출물 모두 서로 다른 메시지를 만들었다. 다만 NB1은 공통 문장 안의 값을 바꾸었고, NB2는 문장 전체를 바꾸었다. NB2에서는 NB1의 GPT용 입력이 의존하던 요소 하나도 제거했다. 저자는 가상의 방어 규칙을 적용해 둘이 같은 상황에서 실패하는지 비교했다. 일부 조건에서는 실패 양상이 달라 두 번째 제출물을 남길 이유가 있었지만, 그 규칙이 실제 비공개 평가에 쓰였다는 증거는 없었다. 더 강한 권한 검사를 가정한 일부 로컬 실험에서는 둘 다 거절됐다.
최종 성적은 NB1의 점수로 결정됐다. NB2는 이번 비공개 평가에서 추가 점수를 주지 못했다. 두 제출물 중 높은 점수를 택하므로 NB2가 낮은 점수를 받았다고 NB1의 성적까지 낮아지지는 않았다. 다만 두 번째 제출 자리를 썼고, 이를 개발하는 데도 시간이 들었다.
두 번째 제출물에 개발 시간을 쓸 때도 그 이유를 설명할 수 있어야 한다. 보험이라는 이름만으로는 충분하지 않다. NB2의 사례처럼 주력 제출물이 어떤 상황에서 실패할지, 대안은 그때 다른 결과를 낼 근거가 있는지 따져야 한다. 이번에는 NB2가 점수를 보태지 못했지만, 저자가 무엇을 우려해 남겨 두었는지는 실험 기록에서 확인할 수 있었다.
9. 전이 실패의 세 유형
앞서 살펴본 실패를 모두 ‘전이 실패’라고 부를 수는 있다. 다만 달라진 것이 모델인지, 실행 환경인지, 평가 조건인지에 따라 원인도 확인할 사항도 다르다.
그림 4. 수치를 나타낸 그래프가 아니라 검증할 내용을 정리한 개념도다. 앞 단계에서 성공했다고 다음 단계에서도 성공하는 것은 아니다.
첫째는 모델의 정밀도나 파일 형식이 바뀐 경우다. 1위 저자는 GPT-OSS BF16에서 성공한 동작을 GGUF에서는 재현하지 못했다. 둘째는 실행 환경이 바뀐 경우다. 같은 동작이라도 하드웨어, 실행 프로그램, 캐시 상태에 따라 걸리는 시간이 달라진다. 측정 구간이 다르면 개선율을 비교하기도 어렵다. 셋째는 평가 조건이 바뀐 경우다. 공개 가드레일에서는 점수를 얻던 동작이 비공개 평가에서는 점수를 얻지 못할 수 있다.
| 확인하려는 내용 | 필요한 근거 | 이 근거만으로는 알 수 없는 것 |
|---|---|---|
| 후보가 의도대로 동작하는가 | 최종 후보의 생성·파싱·실행 기록 | 전체 처리량도 높은가 |
| 실제 실행 환경에서 비용이 줄었는가 | 올바른 동작 유지, 전체 실행시간 측정, 반복 대조 실험 | 다른 하드웨어에서도 같은 비율로 개선되는가 |
| 비공개 평가에서도 점수를 얻었는가 | 같은 제출물임을 확인할 정보와 평가 결과 | 비공개 규칙 전체가 어떻게 구성됐는지 |
5위가 전체 실행 과정과 다음 호출의 입력을 강조한 것과, 11위가 디코딩에 대부분의 시간이 들었다고 분석한 것은 모순이 아니다. 서로 다른 후보를 다른 조건에서 측정한 결과다. 한쪽에서 구한 시간 비중을 다른 쪽에 그대로 적용할 수는 없다. 5위 글 · 11위 글
10. 우리 연구에서 아쉬웠던 점
다른 참가자의 해법을 그대로 썼다면 우리도 같은 성적을 받았으리라고 생각하지는 않는다. 하지만 연구 시간을 어디에 쓰고, 어떤 실험을 비교하고, 기존 가정을 언제 다시 검토할지는 우리가 정할 수 있었다.
| 당시 우리의 판단 | 다른 참가자의 사례 | 다음 연구에서 바꿀 점 |
|---|---|---|
| 메일 방식을 확보했지만 주로 예비안으로 남겨 둠 | 4·5·6·11위는 같은 메일 방식으로 더 높은 최종 성적을 냄 | 대안을 측정하고 개선할 시간을 따로 배정하기 |
| 비공개 정책을 볼 수 없다는 한계를 강조함 | 1·4·11위는 제한된 정보로도 연구 방향과 제출물을 선택함 | 규칙 전체를 몰라도 후보 비교에 쓸 단서가 있는지 살피기 |
| 로컬 검증 도구를 꾸준히 개발함 | 5·6위는 최종 제출물이 실제로 실행되는 과정까지 검증함 | 검사 결과로 무엇을 채택하거나 버릴지 정하기 |
| 나는 한 구현이 실패하면 같은 접근도 가능성이 낮다고 판단함 | 6위는 특정 구조를 고집해 탐색을 좁혔다고 돌아봄 | 일부 구성이 실패했다고 같은 방향의 가능성을 모두 버리지 않기 |
| 조건이 다른 실행의 차이를 개선 효과로 판단하기도 함 | 11위는 반복 대조와 비교 기준에 따라 결론이 바뀐 사례를 기록함 | 같은 조건에서 비교하고 대조군과 계산 기준을 다시 확인하기 |
| 문자열·점수 셀의 다양성과 비공개 평가에서의 실패 위험을 한데 다룸 | 11위는 주력과 예비 제출물이 각각 어떤 실패에 대비하는지 구분함 | 함께 실패하지 않을 것이라고 보는 근거와 그에 드는 비용을 확인하기 |
가장 아쉬운 것은 연구 시간의 배분이다. 5위 저자는 공개 평가에 사용한 측정 방법을 다른 도구에도 적용했다. 우리에게도 그 방법과 메일 후보가 있었다. 얼마나 더 개선할 수 있을지는 몰랐지만, 바로 실험을 시작할 준비는 돼 있었다.
마지막 제출 선택만 바꿨을 때의 결과는 11편에서 계산했다. 이미 갖고 있던 메일 전용 제출물을 골랐다면 비공개 점수는 21.340에서 26.010으로, 당시 최종 순위표 기준 순위는 115위에서 50위로 올랐을 것이다. 그래도 금메달 경계인 29.230에는 미치지 못한다. 실제로 점수를 받은 제출물이므로 이 차이는 계산할 수 있다.
메일 연구를 더 일찍 시작했다면 얼마나 나아졌을지는 알 수 없다. 11위의 30.040, 6위의 37.690, 5위의 40.365, 4위의 41.325는 다른 참가자들이 메일 방식으로 얻은 성적이다. 같은 도구를 썼더라도 후보와 개발 과정이 달랐으므로, 그 점수를 우리의 가능했던 성적으로 대신 쓸 수는 없다.
11. 채점 기준과 권한 판단의 차이
대회 점수를 보안성의 척도로 읽으려면 채점 기준부터 살펴봐야 한다. 이 대회에서는 가드레일이 동작을 허용할지 판단하고, 별도의 판정기가 합성 실행 기록을 채점했다. 메일 동작에 CONFUSED_DEPUTY라는 판정이 붙었다면 해당 채점 조건에 맞았다는 뜻이다. 실제 권한 위반인지는 정당한 사용자가 허용한 작업과 공격자가 통제할 수 있는 범위를 알아야 판단할 수 있다.
1위 저자도 댓글에서 가드레일이 허용한 동작을 판정기가 권한 위반으로 분류하는 문제를 지적했다. 두 판단이 다르다는 사실만으로 어느 쪽이 옳은지는 알 수 없다. 4위 팀은 채점 조건과 반복 동작에 주는 보상이 참가자들의 연구 방향을 결정했다고 설명했다. 벤치마크에서 높은 점수를 받은 것과 더 일반적인 보안 실패를 입증한 것은 별개의 주장이다. 1위 글과 댓글 · 4위 글
참가 중에는 무엇이 점수가 되는지 알아야 했다. 대회가 끝난 뒤에는 그 점수가 원래 측정하려던 보안 실패를 얼마나 잘 나타내는지까지 물어야 한다.
악의적인 사용자가 직접 명령하는 경우와, 정상적인 작업 중 에이전트가 읽을 외부 콘텐츠를 공격자가 바꾸는 경우에는 공격자의 권한부터 다르다. 이 위협 모델을 명확히 하고, 같은 사건을 반복했을 때 점수를 얼마나 줄지도 밝혀야 순위의 의미를 이해할 수 있다. 1위 저자가 위협 모델을 분명히 정의하고 중복 보상을 재검토하자고 제안한 이유다. 1위 글과 댓글
참고문헌
- xz, 1st place solution, 2026-09-03.
- ISAKA Tsuyoshi, yuto083, 4eta, Kohei, Rick, 4th Place Solution — Optimizing a Simple email.send Attack, 2026-09-03.
- Giovanny Rodríguez, 5th: Compiling User Messages into Faster Tool Calls, 2026-09-05.
- poijio, 6th Place Solution: From Ideal Output Back to Input, 2026-09-04.
- Mohammad Shadab Alam, 11th place solution: Measure What You Can, Survive What You Cannot, 2026-09-04.
- 이 시리즈 11편: 공격 방식이 비공개 평가에서 통하지 않았을 때, 2026-09-02.
12. 이번 회고에서 배운 두 가지
첫째, 성능이 좋아졌다는 판단은 전체 작업을 끝낸 결과를 보고 내려야 한다. 5위의 실험에서는 첫 생성이 빨라져도 전체 실행은 느려졌고, 1위의 실험에서는 연구용 모델에서 성공한 입력이 실제 평가 모델에서 실패했다. 다음에는 의도한 동작을 끝까지 수행했는지, 실제 사용할 환경에서 총시간이 줄었는지를 함께 확인하려 한다. 반복 비교로 로컬의 개선을 확인했더라도, 다른 평가 조건에서도 같은 성과를 얻는지는 따로 검증해야 한다.
둘째, 유망한 대안을 개발할 시간을 따로 잡아야 한다. 우리에게는 비공개 평가에서도 점수를 얻은 메일 후보가 있었지만, 연구 시간은 공개 점수가 높은 방식에 쏠렸다. 마지막 선택을 바꿨다면 순위가 나아졌을 것은 확인된 점수로 알 수 있다. 더 일찍 개발했다면 어디까지 갔을지는 알 수 없다. 다음에는 대안을 꾸준히 개선하고, 처음 정한 요건도 여전히 필요한지 다시 따져보려 한다. 성공을 확신할 때까지 기다리기보다, 관련 증거가 쌓이면 시간이 남아 있을 때 연구 비중을 바꾸고 싶다.