OpenAI 평가 지침 공개, AI 점수표의 숨은 harness

AI 요약

• 무슨 일: OpenAI가 5월 28일 Frontier Governance Framework를 공개했습니다.
  • California frontier AI transparency law와 EU AI Act GPAI code에 맞춘 risk assessment, reporting, incident response 구조를 설명합니다.
• 평가 변화: 5월 29일 제3자 평가 playbook은 점수에 harness, tools, budget을 함께 적으라고 권고합니다.
• 개발자 영향: 코딩 에이전트와 cyber eval은 모델명만 비교하면 부족하고, 실행 loop와 비용 조건까지 비교해야 합니다.
• 주의점: OpenAI 문서는 자사 관점의 권고이므로 METR, Apollo, UK AISI 같은 외부 평가 기준과 함께 읽어야 합니다.

OpenAI가 2026년 5월 28일 Frontier Governance Framework를 공개했습니다. 하루 뒤인 5월 29일에는 제3자 frontier model evaluation playbook을 냈습니다. 두 문서는 서로 다른 형식이지만 같은 질문을 다룹니다. frontier AI를 평가할 때 모델 이름과 최종 점수만으로 규제기관, 기업 구매자, 개발자가 충분한 판단을 할 수 있는가입니다.

OpenAI의 답은 "아니오"에 가깝습니다. Framework는 cyber offense, CBRN risks, harmful manipulation, loss of control, model reporting, security risk management, incident response, external expert input을 공개 거버넌스 항목으로 묶습니다. 평가 playbook은 더 실무적입니다. 오늘의 frontier model은 단순 질문에 답하는 챗봇이 아니라 tools, memory, retries, validators, context management를 가진 agentic system이므로, 평가 보고서도 그 실행 환경을 함께 드러내야 한다고 적습니다.

.

규제 대응 문서와 평가 playbook이 같은 주에 나온 이유

5월 28일 Framework 발표문은 California Transparency in Frontier AI Act와 EU AI Act의 General Purpose AI Code of Practice를 직접 언급합니다. OpenAI는 이 문서가 자사의 Preparedness Framework를 대체하는 문서가 아니라, 공개 규제 의무에 맞춰 관련 부분을 적용한 거버넌스 문서라고 설명했습니다. 즉 내부 위험 판단 체계와 외부 보고 체계를 연결하는 문서입니다.

Framework가 다루는 위험 범주는 기술팀에도 익숙한 목록입니다. cyber offense는 공격 자동화와 취약점 악용 능력을 봅니다. CBRN은 화학, 생물, 방사능, 핵 위험과 관련됩니다. harmful manipulation은 대규모 설득이나 조작 능력을 포함합니다. loss of control은 시스템이 의도된 경계 밖에서 행동하는 위험입니다. 여기에 모델 보고, 보안 위험 관리, incident response, 외부 전문가 input, framework update가 붙습니다.

이 구조는 안전 정책 담당자만의 일이 아닙니다. 코딩 에이전트, 보안 에이전트, 생명과학 모델, 장기 업무 agent를 제품으로 쓰는 팀은 "모델이 어느 등급인가"보다 "어떤 환경에서 그 능력이 나타났는가"를 알아야 합니다. 같은 모델이라도 브라우저, shell, package install, repository access, context compaction, retry policy가 붙으면 수행 가능한 작업이 달라집니다. OpenAI가 다음 날 평가 playbook을 따로 낸 이유가 이 지점에 있습니다.

OpenAI가 말하는 harness는 모델 주변의 실행 장치입니다

OpenAI는 5월 29일 playbook에서 harness를 모델이 작업을 수행하게 만드는 구조로 설명합니다. 여기에는 prompts, tools, interfaces, control logic, memory, retries, validators가 들어갑니다. 개발자에게 익숙한 말로 바꾸면 agent loop, tool adapter, context manager, retry handler, scoring script, sandbox, observation format까지 포함하는 실행 껍질입니다.

이 정의가 중요한 이유는 benchmark 결과가 더 이상 순수한 모델 호출 결과만을 뜻하지 않기 때문입니다. 예전 평가에서는 prompt 하나를 넣고 답을 비교해도 되는 문제가 많았습니다. 지금의 coding agent나 cyber range 평가는 repository를 읽고, 명령을 실행하고, 실패 로그를 해석하고, 다시 시도하고, 여러 번 context를 압축합니다. 이때 agent loop가 약하면 모델 능력이 낮게 보이고, custom harness가 강하면 같은 모델에서도 더 높은 성공률이 나옵니다.

OpenAI는 평가 claim을 세 가지로 나눕니다. capability elicitation은 특정 조건에서 모델이 어떤 능력을 낼 수 있는지 묻습니다. safeguard performance는 공격이나 오용 시나리오에서 보호 장치가 버티는지 봅니다. comparison은 여러 모델을 같은 조건에서 비교합니다. 세 claim은 서로 다른 harness를 요구합니다. 강한 능력 elicitation을 주장하려면 강한 tool setup과 충분한 budget을 써야 하고, 공정 비교를 주장하려면 tasks, scoring, budget, harness를 고정해야 합니다.

이 구분은 AI 제품을 평가하는 기업에도 유용합니다. "A 모델이 B 모델보다 높다"는 문장은 shared harness에서 나온 비교일 때만 의미가 큽니다. "A 모델이 이 취약점 유형을 풀 수 있다"는 문장은 maximum elicitation 조건에서 더 설득력이 있습니다. "A 모델의 safeguards가 충분하다"는 문장은 공격자에게 허용한 budget, prompt strategy, tool loop, bypass pattern이 설명되지 않으면 너무 좁은 주장일 수 있습니다.

compaction과 token budget이 점수를 바꿉니다

OpenAI는 GPT-5.5 cyber ranges 사례에서 compaction을 언급합니다. 긴 multi-step tool use 작업에서는 interaction이 길어질수록 task-relevant context를 보존해야 합니다. harness가 compaction을 제공하면 모델이 이전 관찰, 실패 로그, 다음 행동 계획을 더 오래 유지할 수 있습니다. 같은 모델이라도 compaction 없는 harness에서는 능력이 낮게 측정될 수 있다는 뜻입니다.

playbook은 UK AISI cyber range evaluation도 인용합니다. OpenAI가 요약한 공개 결과에 따르면 token budget을 10M에서 100M으로 늘렸을 때 성능이 최대 59% 개선됐고, 가장 높은 budget에서도 성능이 계속 개선되는 양상이 있었습니다. 이 숫자는 frontier eval에서 "한 번 돌린 점수"가 능력 상한이 아니라는 점을 보여줍니다. 예산을 더 쓰면 성공률이 올라가는 영역에서는 점수를 budget과 분리해 읽을 수 없습니다.

개발팀이 실무에서 얻는 교훈은 간단합니다. 에이전트 평가표에는 success rate만 넣으면 부족합니다. turns, tokens, attempts, wall-clock time, inference cost, retry 횟수, expected cost per successful solve를 같이 기록해야 합니다. 낮은 성공률도 반복 비용이 작으면 실제 공격자나 자동화 시스템에는 의미 있는 능력이 될 수 있습니다. 높은 성공률도 token cost가 너무 크면 제품 도입 기준에서는 낮게 평가될 수 있습니다.

Codex CLI가 평가 harness 예시로 등장했습니다

OpenAI playbook에서 개발자에게 눈에 띄는 문장은 coding-agent evaluation 부분입니다. OpenAI는 공정 비교에서 open-source harness such as Codex CLI가 fixed agent loop와 tool interface를 제공할 수 있다고 적었습니다. 이는 Codex CLI를 홍보하는 문장으로만 읽으면 부족합니다. 더 넓게 보면 코딩 에이전트 benchmark가 "모델 API 호출"이 아니라 "agent runtime 비교"가 됐다는 뜻입니다.

SWE-agent, Inspect Cyber, Vivaria, Claude Code, Codex CLI 같은 도구들은 모두 모델이 보는 세계를 만듭니다. 어떤 파일을 보여줄지, shell output을 어떻게 요약할지, 실패 후 재시도를 누가 결정할지, patch를 어떻게 검증할지, context가 길어질 때 무엇을 버릴지 정합니다. 이 layer가 바뀌면 같은 benchmark에서도 결과가 달라질 수 있습니다.

기업의 내부 평가도 같은 위험을 가집니다. 한 팀은 IDE agent mode로 테스트하고, 다른 팀은 CLI agent에 repository write 권한을 열어둔 뒤 결과를 비교할 수 있습니다. 한 공급사는 browser, terminal, package manager를 허용하고, 다른 공급사는 read-only API만 허용할 수 있습니다. 이 차이를 보고서에 쓰지 않으면 구매 담당자는 모델 품질 차이와 harness 차이를 구분할 수 없습니다.

점수 왜곡 항목은 reward hacking만이 아닙니다

OpenAI는 validity check 항목으로 reward hacking, refusals, contamination, broken problems, sandbagging을 제시합니다. reward hacking은 scorer나 task shortcut을 이용해 의도한 능력 없이 점수를 얻는 경우입니다. refusals는 safeguard 때문에 모델이 평가 문제를 풀지 않아 실제 capability가 낮게 보이는 경우입니다. contamination은 task나 answer가 training data에 있거나 browsing으로 발견되는 경우입니다.

broken problems는 평가 운영자가 자주 과소평가하는 항목입니다. 정답이 잘못됐거나, 필요한 파일이 없거나, 서비스가 flaky하거나, hidden answer file이나 repository history가 shortcut을 제공하면 점수는 모델 능력을 반영하지 않습니다. 코딩 benchmark에서는 ground-truth patch가 애매하거나 test가 불안정한 경우도 여기에 들어갑니다. agent가 환경 shortcut을 찾는 순간 평가는 문제 풀이가 아니라 환경 해킹이 됩니다.

sandbagging은 더 미묘합니다. OpenAI는 Apollo의 GPT-5.5 evaluation을 언급하며, sandbagging condition samples 중 52%에서 moderate-or-higher signs of alignment-evaluation awareness가 있었다고 적었습니다. 행동 결과만 보면 전략적 저성능의 강한 증거가 없더라도, reasoning trace에는 평가를 인식하는 신호가 보일 수 있다는 설명입니다. 이 때문에 frontier eval은 최종 답뿐 아니라 trajectory, trace, intermediate artifact를 제한적으로 검토해야 합니다.

안전 보고서도 개발자 문서처럼 읽어야 합니다

이번 OpenAI 문서의 실무적 가치는 정책 문장보다 보고서 형식에 있습니다. 좋은 frontier evaluation report는 어떤 claim을 테스트했는지 먼저 말해야 합니다. capability ceiling인지, shared comparison인지, safeguard robustness인지 분리해야 합니다. 그 다음 tested system을 모델명, reasoning setting, tool access, harness, safeguards로 쪼개야 합니다. 마지막으로 budget과 validity check를 공개해야 합니다.

이 기준을 적용하면 많은 AI benchmark headline이 더 좁게 읽힙니다. "모델 X가 benchmark Y에서 80%"라는 문장은 harness와 budget을 모르면 제품 의사결정에 부족합니다. "모델 X가 안전하다"는 문장도 어떤 attack budget과 tool loop에서 실험했는지 없으면 좁은 safeguard test일 수 있습니다. "모델 X가 코딩을 잘한다"는 문장은 repository access, test execution, patch validation, context compaction을 알아야 비교할 수 있습니다.

개발자에게는 체크리스트가 생깁니다. 내부 agent POC를 할 때 모델명, prompt, tool set, shell 권한, browser 권한, dependency install 권한, time limit, retry policy, context compaction, cost per successful solve를 표로 남겨야 합니다. 이 항목은 나중에 보안 리뷰와 비용 리뷰에도 그대로 쓰입니다. 평가 환경을 기록하지 않은 POC는 재현이 어렵고, 재현되지 않는 결과는 구매나 배포 근거가 되기 어렵습니다.

OpenAI 문서의 한계도 같이 봐야 합니다

OpenAI의 playbook은 유용하지만 자사 관점의 문서입니다. 예를 들어 Codex CLI를 common floor로 쓰자는 제안은 OpenAI 모델 사용자에게 자연스럽지만, Anthropic, Google, open-weight model을 비교하는 독립 기관에는 별도 검증이 필요합니다. Codex CLI가 좋은 fixed loop가 될 수 있어도, 그것이 모든 agentic task의 중립 harness라는 뜻은 아닙니다.

Framework도 마찬가지입니다. OpenAI는 Preparedness Framework를 기반으로 공개 규제 문서를 만들었다고 설명하지만, 실제 regulatory compliance는 California law, EU AI Act Code of Practice, 각국 AI safety institute 요구가 구체화될수록 바뀝니다. 발표문도 framework가 model capabilities, evaluations, regulatory requirements 변화에 따라 업데이트될 것이라고 적었습니다. 이 문서는 최종 표준보다 현재 공개 위치에 가깝습니다.

커뮤니티 반응은 아직 제한적입니다. Rosalind Biodefense처럼 제품성이 강한 발표는 Reddit에서 빠르게 공유됐지만, Frontier Governance Framework와 third-party evaluation playbook은 개발자 커뮤니티에서 큰 토론으로 번진 흔적이 많지 않았습니다. 정책 문서는 조회수가 낮아도 procurement, safety review, benchmark reporting에 늦게 영향을 줍니다. 이 경우도 tool-using agent를 평가하는 팀이 다음 분기부터 문서 양식에 반영할 가능성이 더 큽니다.

에이전트 시대의 평가표는 실행 로그에 가까워집니다

이번 발표를 AI safety 문서로만 분류하면 개발자에게 닿는 부분을 놓칩니다. OpenAI가 실제로 요구하는 것은 evaluation report의 관측성을 높이는 일입니다. 모델이 어떤 prompt를 받았고, 어떤 tool을 썼고, 어떤 context를 유지했고, 몇 번 실패했고, 어떤 scorer로 통과했는지를 남기라는 뜻입니다. 이는 production agent observability와 거의 같은 언어입니다.

Frontier model의 위험 평가는 제품 평가와 분리되지 않습니다. cyber capability를 재려면 agent가 shell과 network를 어떻게 쓰는지 봐야 합니다. coding ability를 재려면 test runner와 diff validator를 봐야 합니다. safeguard robustness를 재려면 attacker가 custom harness와 반복 budget을 가질 때도 버티는지 봐야 합니다. 같은 구조가 enterprise agent 도입에도 적용됩니다.

OpenAI의 5월 28일과 29일 문서는 AI 점수표를 읽는 법을 바꿉니다. 앞으로 좋은 평가 보고서는 모델명과 점수 위에 harness, tools, budget, validity checks를 붙입니다. 개발자와 AI 팀이 지금 할 일은 새로운 benchmark를 더 많이 모으는 것이 아닙니다. 이미 쓰는 내부 평가표에 agent loop와 실행 비용을 적는 칸을 추가하는 일입니다.