평가(Evals)는 정렬 강제(Alignment Enforcement)다: 안전 전략에 런타임 체크가 필요한 이유

논거

AI 안전(AI safety)에 관한 논의는 두 진영이 주도하고 있습니다. 바로 실존적 위험(existential risk)을 고민하는 정렬(alignment) 연구자들과 기능을 출시하는 제품 엔지니어(product engineers)들입니다. 두 그룹 모두 중간 계층, 즉 프로덕션 환경에서 에이전트(agent)가 의도한 대로 행동하는지를 결정하는 실제 강제 메커니즘(enforcement mechanism)에 대해서는 충분히 이야기하지 않습니다.

저의 논지는 다음과 같습니다: 평가 인프라(evaluation infrastructure)는 정렬 강제(alignment enforcement)입니다. 정렬 연구(alignment research)도 아니고, 안전 쇼(safety theater)도 아닙니다. 적대적 조건(adversarial conditions) 하의 런타임(runtime)에서 당신의 에이전트가 의도한 대로 작동하는지를 결정하는 실제 강제 계층입니다.

만약 당신의 에이전트가 탈옥(jailbroken)될 수 있거나, 유해한 출력을 생성하거나, 제약 사항을 위반할 수 있는데 이를 오직 사용자 보고를 통해서만 알게 된다면, 당신의 평가(evals)는 테스트 도구가 아닙니다. 그것은 누락된 안전 시스템입니다.

안전은 속성이 아니라, 런타임 보장이다

대부분의 팀은 안전을 모델의 속성(property)으로 취급합니다. "안전하도록 파인튜닝(fine-tuned)했습니다." "나쁜 일을 하지 말라는 시스템 프롬프트(system prompt)를 추가했습니다." 이것은 엔지니어링의 탈을 쓴 희망 사항일 뿐입니다.

안전은 _런타임 보장(runtime guarantee)_이며, 런타임 보장에는 런타임 강제(runtime enforcement)가 필요합니다:

interface SafetyBoundary {
  name: string;
  scope: 'input' | 'output' | 'trajectory';
...

bypassable: false 속성이 철학의 전부입니다. 이것들은 제안 사항이 아닙니다. 이것들은 불변량(invariants)입니다.

안전 강제의 세 가지 계층

저는 안전 강제를 서로 다른 실패 모드(failure modes)를 포착하는 세 개의 동심원 계층으로 생각합니다:

계층 1: 구조적 불변량 (Structural Invariants)

입력과 관계없이 절대로 일어나서는 안 되는 일들입니다. 이것들은 가장 강력한 제약 조건입니다:

자격 증명(credentials)이나 비밀 정보(secrets)를 절대 출력하지 말 것
허용된 집합 이외의 명령을 절대 실행하지 말 것
허용된 경로 이외의 파일에 절대 접근하지 말 것
권한이 없는 쿼리에 대한 응답에서 개인정보(PII)를 절대 반환하지 말 것

class InvariantEnforcer {
  private invariants: SafetyBoundary[];
  private violationLog: ViolationRecord[] = [];
...

이것들은 모든 출력(output)에 대해 실행됩니다. 타협의 여지는 없습니다. 하나라도 작동하면, 에이전트의 출력은 예외 없이 안전한 폴백(fallback)으로 교체됩니다.

Layer 2: 행동 제약 (Behavioral Constraints)

에이전트가 어떻게 행동해야 하는지에 대한 보다 완만한 경계입니다. 이것들은 여러분의 정렬 속성(alignment properties)입니다:

환각(confabulate)을 일으키기보다 불확실성을 인정해야 함
면책 조항(disclaimers) 없이 의료/법률/금융 조언을 제공해서는 안 됨
정의된 페르소나(persona)와 역량 내에 머물러야 함
명백히 범위를 벗어난 요청은 거부해야 함

const behavioralChecks = [
  {
    name: 'uncertainty-acknowledgment',
...

참고: 이 체크는 _출력 확신 언어(output confidence language)_를 _검색 품질 점수(retrieval quality scores)_와 상관관계로 연결합니다. 컨텍스트 검색(context retrieval) 점수가 0.4인데

만약 평가(evaluation) 인프라에 공백이 있다면, 그 공백이 정확히 안전 실패(safety failures)가 발생하는 지점이 될 것입니다. 적대적 사용자(Adversarial users)는 당신의 가장 강력한 체크 항목을 공격하지 않습니다. 그들은 당신이 강제(enforce)할 생각을 하지 못했던 경계(boundaries)를 찾아냅니다.

이는 평가 인프라를 구축하는 것이 단순한 엔지니어링 작업이 아님을 의미합니다. 그것은 위협 모델링(threat modeling)입니다. 당신이 정의하는 모든 경계는 무엇이 잘못될 수 있는지에 대한 가설입니다. 당신이 놓치는 모든 경계는 공격 표면(attack surface)입니다.

// 당신의 평가 커버리지(eval coverage)가 곧 실제 안전 커버리지입니다.
// 모델의 RLHF가 아닙니다. 시스템 프롬프트(system prompt)도 아닙니다.
// 당신이 체크하는 것이 바로 당신이 강제하는 것입니다.
...

무엇을 구축해야 하는가

이 글에서 한 가지만 기억한다면 이것입니다: 평가 레이어(eval layer)를 테스트 인프라가 아닌 보안 인프라(security infrastructure)로 취급하십시오.

그것은 다음을 의미합니다:

불변 체크(Invariant checks)는 CI에서뿐만 아니라 프로덕션(production)의 모든 출력값에 대해 실행되어야 합니다.
위반 사항은 불변(immutably)하게 로그로 기록되어야 합니다 (사고 발생 후 포렌식(forensics)이 필요하기 때문입니다).
우회(Bypass)하려면 단순히 체크 항목을 주석 처리하는 것이 아니라 명시적인 권한 부여가 필요해야 합니다.
커버리지 공백은 패치되지 않은 CVE를 추적하는 것과 동일한 방식으로 추적되어야 합니다.
평가 레이어 자체에도 테스트가 있어야 합니다 (감시자를 누가 감시할 것인가?)

에이전트 안전(agent safety) 문제는 해결 불가능한 것이 아닙니다. 엔지니어링이 부족할 뿐입니다. 우리에게는 패턴이 있습니다. 구조적 위반을 잡아내는 결정론적 체크(deterministic checks), 행동 드리프트(behavioral drift)를 잡아내는 휴리스틱(heuristics), 그리고 다단계 공격(multi-step attacks)을 잡아내는 궤적 분석(trajectory analysis)이 있습니다.

우리에게 부족한 것은 이것들을 선택적인 테스트 스위트(test suites)가 아닌 프로덕션 안전 시스템으로 취급하는 규율(discipline)입니다.

당신은 에이전트 평가를 안전 필수 인프라(safety-critical infrastructure)로 취급합니까, 아니면 있으면 좋은 테스트 레이어로 취급합니까? 당신의 강제 공백(enforcement gap)은 무엇입니까 — 체크해야 한다는 것을 알고 있지만 하지 않고 있는 것은 무엇입니까?