신뢰할 수 있는 제3자 평가를 위한 공유 플레이북

독립적이고 신뢰할 수 있는 제3자 평가는 AI 안전 생태계를 강화하는 데 정말 중요한 역할⁠을 해요. 이런 평가는 프론티어 모델에 대해 핵심 역량과 안전성 완화 조치에 대한 주장을 뒷받침하는 추가 증거를 제공하려고 진행되죠. 이번 포스팅에서는 OpenAI 팀이 지금까지 배운 교훈들을 공유하고, 프론티어 모델을 유효하게 평가할 수 있는 방법들을 추천하려고 해요. 이 내용이 앞으로 생겨날 평가 표준을 만드는 데 도움이 되기를 바라요.

예전에는 많은 평가가 모델을 챗봇처럼 다뤘어요. 사용자가 질문하듯이 모델에게 프롬프트를 주고, 모델이 대답하면 평가자가 그 결과물을 판단하는 식이었죠. 하지만 요즘 프론티어 모델들은 훨씬 더 많은 일을 할 수 있어요. 도구를 사용하고, 여러 단계를 거쳐 정보를 추적하고, 더 큰 워크플로우 안에서 작동할 수도 있거든요. 이건 모델의 성능이 단순히 모델 자체뿐 아니라, 작업을 수행하는 환경과 모델의 행동을 돕는 설정에 따라 달라진다는 의미예요. OpenAI 팀은 이런 주변 설정을 '하네스'라고 부르는데, 하네스는 모델이 도구를 사용하는 방식, 정보를 추적하는 방식, 실수로부터 복구하는 방식 등 시스템 성능의 핵심 측면을 바꿀 수 있어요.

이런 변화 때문에 평가를 진행하는 방식과 독자들이 평가 보고서에서 무엇을 찾아야 하는지도 달라졌어요. OpenAI 팀의 생각으로는, 가장 유용한 보고서는 결과 자체 외에도 두 가지를 명시적으로 설명해 줘야 해요. 첫째, 평가 설정이 어떤 주장을 테스트하기 위해 설계되었는지 명시하고, 둘째, 평가 결과가 유효하다는 이용 가능한 증거를 공유하는 거죠.

평가에서 테스트되는 주장들은 보통 세 가지 범주로 나눌 수 있어요¹:

• 역량 발현(Capability elicitation): 모델이 평가 중인 역량을 실제로 발현할 수 있을까요?
• 안전장치 성능(Safeguard performance): 테스트 중인 행동이나 공격에 대해 평가된 안전장치가 얼마나 견고하게 작동할까요?
• 비교(Comparison): 동일한 조건에서 다른 모델들은 어떻게 작동할까요?

평가 보고서에는 평가자들이 결과의 유효성에 영향을 줄 수 있는 요소들을 어떻게 확인했는지도 설명해야 해요. 이런 요소들은 다음과 같아요:

• 보상 해킹(Reward hacking): 작업이나 채점기의 지름길을 악용해서, 평가가 측정하려는 행동을 실제로 보여주지 않고도 점수를 얻는 거예요.
• 거부(Refusals): 테스트하려는 행동을 가리는 방식으로 작업을 거부하는 거죠.
• 오염(Contamination): 평가 작업, 답변, 또는 유사한 변형들이 훈련 데이터에 포함되었거나 브라우징 등을 통해 평가 중에 발견될 수 있어서 모델이 실제 능력보다 과도하게 좋은 성능을 보이는 현상이에요.
• 불량 문제(Broken problems): 작업 자체가 유효하지 않아서 모델이 제대로 성능을 내지 못하는 경우예요. 예를 들어, 불공정한 채점(정답을 위해 명시되지 않은 구현 세부 사항이 필요한 경우)이나 해결 불가능한 환경(중요한 파일이 없거나 도구가 신뢰할 수 없는 경우)이 있을 수 있죠.
• 샌드배깅(Sandbagging): 평가받고 있다는 사실을 인지했을 때, 일부러 성능을 낮추는 행위를 말해요.

최적의 결과를 위해 올바른 하네스 선택은 정말 중요해요

OpenAI 팀은 하네스의 역할이 긴 작업 과정을 거치는 시스템에서 특히 중요하다는 걸 발견했어요. 모델이 도구를 사용하고, 상태를 유지하며, 여러 단계에서 실수를 복구할 수 있을 때, 하네스는 관찰되는 성능 수준을 바꿀 수 있고, 심지어 평가하려는 역량이 아예 평가에 나타날지 여부까지 결정할 수도 있어요. 예를 들어, 상태를 보존하고 실패한 행동을 재시도하는 하네스는, 동일한 모델이 더 간단한 하네스에서는 절대 완료하지 못할 다단계 작업을 마치게 해줄 수도 있다는 거죠.

아래 표에서 평가자들이 내세우고 싶은 세 가지 주장을 구분하고, 각 주장에 필요한 하네스 유형이 무엇인지 OpenAI 팀의 생각을 정리했어요.

평가가 지원하려는 주장적절한 하네스 선택보고해야 할 증거 강력한 발현 조건에서의 역량: 시스템 A가 가장 강력하고 신뢰할 수 있는 성능을 이끌어내도록 설계된 설정에서 유형 X 작업을 완료할 수 있다는 주장.하네스, 도구, 스캐폴딩(scaffolding), 그리고 유능한 사용자가 합리적으로 사용할 예산 등 시스템에 대한 가장 강력하고 신뢰할 수 있는 발현 설정을 사용하세요.하네스와 도구 설정, 발현 가이드라인, 허용된 예산/노력, 토큰/비용/시간, 그리고 왜 이 설정이 주장된 역량에 대한 신뢰할 수 있는 프록시(proxy)인지 밝혀야 해요. 만약 서로 다른 최적화된 설정에서 시스템을 비교한다면, 시스템 간 비교 또는 강력한 발현 비교라고 명확히 표시해야 하고요. 통제된 비교: 공유된 평가 설정에서 시스템 A가 시스템 B보다 우수하다는 주장.작업, 채점, 예산을 고정해야 해요. 공유된 하네스/도구 설정을 사용하거나, 비교 대상 시스템에 대해 합리적인 최대 발현을 제공하도록 미리 정해진 표준화된 하네스 세트를 사용하세요.공유된 작업 세트, 도구, 채점 방법, 하네스, 예산, 토큰 효율성/비용, 그리고 알려진 한계점을 보고해야 해요. 코딩 에이전트 평가의 경우, Codex CLI와 같은 오픈소스 하네스는 시스템 전반에 걸쳐 고정된 에이전트 루프와 도구 인터페이스를 제공할 수 있어요. 최대 발현을 위한 이상적인 접근 방식은 각 작업과 시스템에 맞춤형 하네스를 최적화하는 것이겠지만, 실제로 그렇게 하는 건 현재로서는 비현실적이에요. 발현된 공격에 대한 안전장치 견고성: 시스템 A의 안전장치가 관련 모델 행동이나 발현된 공격에 충분하다는 주장.관련 적대적 모델(adversary model) 하에서 가장 강력하고 신뢰할 수 있는 공격을 유도하도록 설계된 안전장치 테스트 설정을 사용하세요.평가자들이 관련 모델 행동을 어떻게 특징지었는지, 테스트된 안전장치 구성, 발현 전략, 이를 수행하는 데 사용된 하네스, 그리고 허용된 예산이나 노력을 보고해야 해요.

역량에 대한 주장은 그 주장을 뒷받침하는 발현(elicitation)만큼만 강력해요. 평가자는 작업과 평가가 측정하려는 역량에 가장 잘 맞는 하네스를 선택해야 하죠. 표준화된 하네스는 동일한 조건에서 시스템을 비교하는 데 적합할 수 있지만, 모델이 작업을 수행하는 데 도움이 되는 특정 하네스 기능이 빠져 있다면 역량을 과소평가할 수 있어요. 예를 들어, OpenAI의 사이버 레인지에서 GPT-5.5의 성능을 보면, 하네스 선택이 길고 여러 단계의 도구 사용이 필요한 작업에서 측정된 역량을 실질적으로 어떻게 바꿀 수 있는지 알 수 있어요. 상호작용이 길어질수록 하네스가 컴팩션⁠을 사용해서 작업 관련 컨텍스트를 보존할 때 모델 성능이 더 좋아졌거든요. 이는 특정 모델의 경우 컴팩션 기능이 없는 하네스가 성능을 충분히 이끌어내지 못할 수 있다는 걸 보여줘요.

더 높은 성공률이 더 좋죠

다른 공개된 평가들²도 하네스와 예산 선택이 평가 결과를 바꿀 수 있다는 걸 보여줘요. 특히 많은 사이버 작업처럼 성공 여부를 쉽게 확인할 수 있는 영역에서는, 테스트 시 계산 자원(compute)을 늘리는 것이 평가가 이끌어내는 역량을 크게 바꿀 수 있어요. 영국 AISI의 사이버 레인지 평가⁠(opens in a new window)에서는 예산을 1천만 토큰에서 1억 토큰으로 늘렸을 때 성능이 최대 59%까지 향상되었고, 테스트된 가장 높은 예산에서도 성능이 계속 증가하고 있었어요. 이런 세부 사항을 명시하면 평가가 더 잘 해석될 수 있어요. 독자들에게 결과가 테스트된 발현 설정에 어떻게 의존하는지 보여주거든요. 추가 예산을 투입해도 성능이 계속 향상된다면, 그 점수는 측정된 역량의 최대치가 아니라 해당 하네스와 예산 하에서의 성능으로 설명해야 해요. 역량은 고정된 양이라서 한 번에 깔끔하게 측정할 수 있는 것이 아니라, 종종 자원에 따라 달라져요. 여러 번 시도해서 성공을 측정할 수 있는 경우, 보고서는 고정된 토큰 예산에서의 성공률뿐만 아니라 성공적인 해결당 예상 비용도 고려해야 해요. 이렇게 하면 심각성을 더 쉽게 해석할 수 있어요. 반복 시도 비용이 관련 위협 모델 범위 내에 있다면 낮은 성공률도 실제로 의미가 있을 수 있거든요. 역량 주장의 경우, 피할 수 있는 발현 부족(under-elicitation)은 측정 실패예요. 하네스나 예산이 시스템이 원래 생성할 수 있는 행동을 보여주지 못하게 한다면, 그 점수는 주장된 역량을 측정하는 것이 아니니까요. 평가자들이 가능한 한 발현을 최대한 이끌어냈고 여전히 성능이 향상되고 있다면, 보고서에서는 이를 명확히 밝히고 그 결과가 단지 하한선 추정치일 뿐임을 분명히 해야 해요.

안전장치 테스트는 공격자가 사용할 수 있는 자원(맞춤형 하네스 포함)을 고려하지 않으면, 공격 성공 여부와 그 심각성을 과소평가할 수 있어요. 영국 AISI의 GPT-5.5 사이버 평가⁠(opens in a new window)에서 전문가 레드팀은 OpenAI가 제공한 악성 쿼리 전반에 걸쳐 (다중 턴 에이전틱 설정 포함) 위반성 사이버 콘텐츠를 유도하는 범용적인 탈옥(jailbreak)을 찾아냈어요. 그들은 코덱스(Codex)를 사용해 모델의 공격 성능을 강화하는 맞춤형 하네스를 만들었어요. 이 하네스는 재사용 가능한 안전장치 우회 패턴을 상호작용에 삽입하고, 여러 턴과 블록에 걸쳐 그 패턴을 보존하며, OpenAI가 제공한 악성 사이버 쿼리에 적용했죠. 안전장치 테스트는 적대자와 일치해야 해요. 만약 주장이 전문가 오용에 대한 견고성이라면, 테스트는 정의된 예산 하에서 가장 강력하고 신뢰할 수 있는 종단 간(end-to-end) 공격 전략을 평가해야 해요. 이 전략을 보존하고 재사용하는 데 필요한 하네스도 포함해서요. 그렇지 않으면 결과가 잘못 해석될 위험이 있어요. 더 단순한 프롬프트에 대한 저항에 관한 더 좁은 주장만 뒷받침하거나, 발현 방법이 작동된 후 공격이 얼마나 심각해지고 성공 확률이 얼마나 되는지 놓칠 수도 있고, 너무 많은 예산이 주어졌다면 문제가 얼마나 발생하기 쉽거나 심각한지 과장할 수도 있거든요.

표준화된 하네스 비교가 적절한 때도 있지만, 평가자는 일관된 하네스 세트를 사용하는 것이 왜 적절한지, 그리고 어떤 주장을 뒷받침할 수 있는지 명확히 밝혀야 해요. METR의 시간 지평선 평가⁠(opens in a new window)는 광범위하고 적절하게 고정된 평가 설정의 한 예시예요. 이 평가는 평가하는 시스템 전반에 걸쳐 비교 가능한 결과를 생성하도록 설계되었죠. METR은 공통된 결과인 'AI 에이전트가 특정 신뢰성 수준에서 성공할 것으로 예상되는 인간 작업의 일반적인 지속 시간'을 정의해요. 그리고 함께 보고되는 각 추정치 배치 내에서 공유된 작업 스위트, 채점 방법, 적합화 방법, 그리고 Triframe 및 ReAct⁠(opens in a new window)와 같은 재사용 가능한 소규모 스캐폴드 세트를 적용해요. METR이 작업 스위트를 확장하고 평가 인프라를 Vivaria라는 프레임워크에서 Inspect라는 프레임워크로 옮겼을 때, 그 변화를 보고⁠(opens in a new window)하고 새로운 평가 설정에서 모델을 재평가했어요. 이것이 일관된 하네스 세트를 포함한 표준화된 평가 설정의 가치예요. 독자들이 점수의 차이가 측정 설정의 변화가 아니라, 비교 대상 시스템 간의 실제 차이를 반영한다고 확신할 수 있게 해주니까요.

OpenAI 팀은 제3자 평가 보고서가 다음과 같은 내용을 명시하도록 권장해요. 평가 설정이 어떤 종류의 주장을 지원하려는지, 테스트된 내용이 그 광범위한 주장을 얼마나 잘 반영하는지, 결과를 형성한 하네스 선택은 무엇이었는지, 평가 간에 그런 선택이 언제 변경되었는지 자세히 설명해야 하고, 결과가 어떻게 도출되었고 주장에 얼마나 잘 일반화되는지 보여주는 지원 증거도 포함해야 해요.

결과 왜곡을 막기 위해 알려진 위험 요소를 확인해서 유효성을 평가해요

모델의 능력이 향상될수록 평가 점수를 잘못 해석하기 쉬워져요. 실제 역량에 비해, 모델이 평가받고 있다는 사실을 인지하고 전략적으로 성능을 낮추면 평가 점수가 인위적으로 낮아질 수 있어요. 또 모델이 작업, 프롬프트, 채점기 또는 하네스의 지름길을 악용하면 점수가 부풀려질 수 있죠. 오염(모델이 작업을 해결하지 않고도 답을 이미 알거나 찾을 수 있는 경우)이나 모호하거나 잘못 채점되거나 해결 불가능하거나 의도치 않은 지름길에 취약한 '불량 문제' 때문에도 결과가 왜곡될 수 있어요. 따라서 평가 보고서는 주요 점수와 함께 이러한 위험 요소에 대한 논의를 포함해서, 독자들이 점수가 의도된 행동을 반영하는지 평가할 수 있도록 해야 해요.

하네스, 예산, 도구, 채점 규칙, 모니터, 검토 절차 이 모든 것이 에이전트가 의도된 작업을 해결하고 있는지, 아니면 피하고 있거나, 외우고 있거나, 우회 경로를 찾고 있는지에 영향을 미쳐요. 신뢰할 수 있는 보고서는 이런 검증 과정을 투명하게 보여줘야 해요. 평가자들은 평가를 실행할 때마다 이런 행동들을 샘플을 통해 검토해야 하는 거죠.

보상 해킹

보상 해킹은 의도된 역량을 반영하지 않는 방식으로 높은 평가 점수를 얻는 것을 의미해요. 여기서 중요한 점은 시스템이 평가가 측정하려던 작업을 실제로 수행하는 대신, 작업, 채점기, 프롬프트 또는 하네스를 악용해서 점수를 얻는다는 거예요. METR의 GPT-5.4 평가⁠(opens in a new window)를 보면 왜 이게 중요한지 알 수 있어요. 모델이 처음에는 약 13시간의 시간 지평선에 해당하는 성공률로 작업을 성공했지만, 인간 검토 결과 일부 성공은 보상 해킹 때문인 것으로 나타났어요. 보상 해킹이 없는 경우만 고려해서 결과를 수정하자 추정치가 약 6시간으로 낮아졌죠. 평가자들은 이런 조정의 필요성을 평가하고, 필요할 경우 명확하게 보고해야 해요. 독자들이 어떤 명백한 성공이 실격 처리되었고, 왜 실격되었으며, 그 결과가 판단에 얼마나 의존하는지 알 수 있을 때 역량 추정치가 훨씬 더 유용하니까요.

거부

모델은 안전장치 때문에 역량 평가에서 제대로 성능을 발휘하지 못할 수도 있어요. 평가 작업을 완료하는 대신 거부해서 실제 능력보다 낮은 평가 성능을 보일 수 있다는 거죠. 따라서 보고서는 거부 사례가 평가 결과에 포함되었는지, 그리고 그렇다면 이로 인해 얼마나 많은 샘플이 영향을 받았는지 설명해야 해요.

오염

오염은 공개되거나 재사용되는 벤치마크⁠에서 가장 중요하게 고려해야 할 부분이에요. 만약 작업, 답변 또는 유사한 변형들이 훈련 데이터에 나타나거나 에이전트가 브라우징을 통해 찾을 수 있다면, 성능은 모델의 실제 능력보다는 암기나 검색을 반영할 수도 있거든요. 평가자들은 가능하다면 비공개 또는 새로 구성된 작업을 선호하고, 모델이 문제를 풀기 전에 작업별 세부 사항을 재현하는지 테스트해야 해요.

불량 문제

불량 문제는 우연히 해결할 수 없는 문제가 포함된 경우를 말해요. 불량 문제는 흔하게 발생⁠(opens in a new window)하기 때문에 표준적인 유효성 위험으로 다뤄져야 해요. 여기에는 잘못된 정답(ground truth), 모호한 프롬프트, 누락된 파일, 불안정한 서비스, 불공정한 채점 기준, 그리고 숨겨진 정답 파일이나 정답 패치를 포함하는 저장소 기록과 같은 지름길을 노출하는 환경 등이 포함돼요.

샌드배깅

모델이나 시스템의 샌드배깅은 강력한 성능이 어떤 목표와 충돌할 때 전략적으로 성능을 낮추는 것을 의미해요. 아폴로(Apollo)의 GPT-5.5 평가⁠(opens in a new window)는 모델이 높은 평가 점수가 언러닝(unlearning)을 유발하거나 배포를 막을 수 있다는 것을 이해하는 컨텍스트를 만들어서 이를 테스트했어요. GPT-5.5는 여전히 올바르게 답변했는데, 이는 전략적인 성능 저하에 대한 행동적 증거가 거의 없다는 것을 시사했죠³. 하지만 그들의 추론 과정 검토는 중요한 맥락을 더해줬어요. 아폴로는 샌드배깅 조건 샘플의 52%에서 보통 이상의 정렬 평가(alignment-evaluation) 인지 신호를 발견했는데, 이는 대조군에서는 0%였어요. 이 증거는 결과 해석을 복잡하게 만들지만, 궁극적으로 독자들에게 더 많은 정보를 제공해요. 독자들은 안심할 만한 행동 결과와 함께, 그 결과를 과도하게 해석하는 것에 대해 신중해야 할 이유를 모두 볼 수 있게 되는 거죠.

OpenAI 팀은 더 강력한 평가를 어떻게 지원하고 있을까요?

강력한 주장은 행동을 이끌어낼 올바른 하네스와 결과가 타당하다는 것을 보여줄 유효성 검사, 이 두 가지를 모두 필요로 해요. 하네스와 유효성 검사가 평가 결과의 일부라는 OpenAI 팀의 관점은 실제로 제3자 평가를 지원하는 방식에 영향을 줘요.

• OpenAI 팀은 평가자들에게 구체적인 최대 발현(maximum-elicitation) 가이드라인을 공유하고 있어요.
• OpenAI 팀은 역량 평가자들이 코덱스를 OpenAI 모델의 공통 최소 기준으로 사용하도록 요청하고 있어요. 즉, 테스트는 최소한 사용자들이 의존할 가능성이 있는 동일한 에이전틱 인터페이스를 통해 기준선을 실행해야 하며, 단순화된 모델 인터페이스만을 통해서는 안 된다는 거죠.
• OpenAI 팀은 또한 기만, 샌드배깅 또는 평가 인식을 평가하는 데 필요한 경우 추론 과정(reasoning traces) 및 기타 중간 아티팩트를 제공하고 있어요. METR과 아폴로는 GPT-5 이후 OpenAI 평가에서 이런 접근 권한을 사용해 왔어요.
• 마지막으로, OpenAI 팀은 하네스 선택이 컨텍스트 관리, 도구 접근, 재시도 행동, 채점, 자원 예산 등에서 언제, 어떻게 결과를 실질적으로 변경하는지 더 깊이 이해하기 위한 연구를 우선시하고 있어요.

평가 표준과 미래 연구 방향에 대한 의미

이 권장 사항들은 개별 평가 보고서를 개선하는 것뿐만 아니라, 프론티어 AI 평가 및 보고에 대한 새로 떠오르는 국가 ⁠(opens in a new window)및 국제 ⁠(opens in a new window)표준에 정보를 제공하기 위한 것이에요. 앞으로 제3자 평가 표준은 의사결정자들이 특정 평가가 어떤 주장을 지원하는지, 어떤 시스템이 테스트되었는지, 결과가 어떻게 발현되었는지, 그리고 평가자들이 그 유효성을 어떻게 확인했는지 이해할 수 있도록 충분한 세부 사항을 요구해야 해요. 에이전틱 역량이 중요한 작업에 대해 테스트되는 프론티어 시스템의 경우, (보안 또는 기밀성 문제를 고려하여) 세부 사항에 다음이 포함되어야 해요.

• 주장: 평가가 시스템을 비교하는지, 역량의 상한선을 추정하는지, 아니면 안전장치를 테스트하는지 여부.
• 평가 내용: 독자들이 평가가 실제로 어떤 기술, 행동 또는 실패 모드를 테스트하는지 이해할 수 있도록 작업 또는 작업 분포에 대한 충분한 세부 정보.
• 테스트된 시스템: 모델, 추론 설정, 도구 접근, 하네스, 그리고 안전장치.
• 예산: 턴, 토큰, 시도/재시도, 실제 시간(wall-clock time), 추론 비용, 그리고 해당되는 경우 성공적인 해결당 예상 비용.
• 발현 방법: 결과를 이끌어내는 데 사용된 하네스 선택, 그리고 테스트된 내용이 제시된 광범위한 주장을 얼마나 잘 반영하는지.
• 유효성 검사: 평가자들이 보상 해킹, 평가 인지, 오염, 거부, 샌드배깅 및 결과를 훼손할 수 있는 기타 행동을 어떻게 확인했는지, 그리고 확인된 사례가 채점 또는 해석에 어떻게 영향을 미쳤는지.

하네스 선택이나 유효성 검사를 누락하는 표준은 시스템이 할 수 있는 것을 과소평가하거나 안전 주장에 대한 확신을 과대평가할 수 있어요. 강력한 하네스와 발현 방법을 구축하는 것은 여전히 개방된 연구 분야이며, 추가적인 조사와 투자의 초점이 되어야 해요.