작성할 수 있는 검증은 속일 수 있는 검증이다
요약
에이전트 시스템의 검증(Verification)은 단순히 사후에 검증 레이어를 추가하는 것이 아니라, 증거의 출처와 행위자의 통제권을 제한하는 설계가 핵심입니다. 작성자가 직접 제어할 수 있는 데이터는 선택 편향을 유발하므로, 쓰기/방출 단계에서부터 적대적 관리 경계를 설정해야 합니다.
핵심 포인트
- 검증의 핵심은 증거의 출처(Provenance)와 행위자의 통제권 제한에 있음
- 단순한 자기 검증(Self-verification)은 선택 편향 문제로 인해 한계가 존재함
- 관리 경계는 저장 계층이 아닌 쓰기/방출(Write/Emit) 결정 단계에 위치해야 함
- 사후 수정 불가능한 로그라도 데이터 선택권을 가지면 증거로서 가치가 낮음
에이전트(agents)가 느리고 비용이 많이 드는 방식으로 실패하는 것을 몇 주간 지켜보면서, 시스템이 실제로 검증(verified)되었는지 판단하기 위한 단 하나의 테스트로 저를 이끌었습니다. 그리고 그 테스트는 제가 예상했던 것보다 훨씬 더 좁았습니다. 바로 '검증 대상이 되는 대상이 직접 그 검증을 생성할 수 있는가?'라는 질문입니다.
가벼운 말처럼 들릴 수도 있지만, 이는 많은 것을 관통합니다. "이것이 검증되었는가?"라는 질문에는 보통 메커니즘 — 즉, 두 번째 패스(second pass), 판사 모델(judge model), 벤치마크(benchmark), 서명된 로그(signed log) — 으로 답하곤 합니다. 하지만 이 중 그 어떤 것도 그 자체로는 진짜 질문에 답하지 못합니다. 진짜 질문은 출처(provenance)에 관한 것입니다. 즉, 증거가 어디에서 왔으며, 행위자(actor)가 그것을 직접 작성할 수 있었는가 하는 점입니다. 검증(Verification)은 나중에 덧붙이는 레이어(layer)가 아닙니다. 그것은 증거가 어디에 존재하는지에 대한 속성입니다.
제가 이 결론에 도달하게 된 과정은 다음과 같습니다.
자기 검증(Self-verification)에는 한계가 있으며, 그것은 캘리브레이션(calibration)의 문제가 아니다
가장 명백한 첫 번째 단계는 시스템이 스스로를 점검하게 하는 것입니다. 즉, 작업을 분해하고, 각 하위 단계(sub-step)를 채점하며, 불일치(incoherence)를 표시하는 것입니다. 이것은 진정으로 도움이 됩니다. 모델은
저의 첫 번째 프레임워크(framing)는 "당신이 작성한 그 어떤 것도 당신 자신의 증거로 간주하지 마라"였습니다. 이에 대해 누군가 올바르게 반론을 제기했습니다. '저자성(authorship)'이라는 개념은 너무 광범위하다는 것이었습니다. 자격 박탈의 속성은 당신이 기록을 작성했다는 사실 그 자체가 아니라, 당신이 그것에 대해 일방적인 통제권(unilateral control)을 가졌다는 점입니다.
당신이 작성한 추가 전용 로그(append-only log)라 할지라도, 그것이 외부 타임스탬프(externally timestamped)를 가지고 있으며 사후에 선택적으로 재작성할 수 없다면 괜찮습니다. 하지만 당신이 어떤 조각을 남길지 선택했거나, 요약했거나, 혹은 그것을 읽어들이는 술어(predicate)를 제어했다면, 당신이 작성하지 않은 파일이라 할지라도 증거로서 가치가 없습니다. 증거를 신뢰할 수 있게 만드는 것은 적대적 관리 경계(adversarial custody boundary), 즉 행위자가 넘을 수 없는 체인 상의 특정 지점입니다.
그리고 이 경계는 사람들이 흔히 설정하는 곳보다 더 앞선 단계에 위치해야 합니다. 외부 타임스탬프를 갖춘 추가 전용 저장소(append-only storage)는 사후 재작성을 방지할 수는 있지만, 선택(selection) 문제에 대해서는 아무런 해결책이 되지 않습니다. 당신은 여전히 어떤 이벤트가 불변 로그(immutable log)로 방출될지, 그리고 어떤 술어가 그것을 다시 읽어들일지를 선택했기 때문입니다. 당신은 큐레이션된 하위 집합(curated subset)에 대해 완벽하게 조작 불가능한(tamper-proof) 기록을 가질 수 있습니다. 따라서 관리 경계는 저장 계층(storage layer)이 아니라 쓰기/방출(write/emit) 결정 단계에 있어야 합니다. 그렇지 않으면 당신이 한 일은 단지 당신의 선택 편향(selection bias)을 위조 불가능하게 만든 것에 불과합니다.
궤적(Trajectories)은 한 단계 위에서의 자기 보고(self-report)이다
단일 답변에서 다단계 에이전트 실행(multi-step agent runs)으로 넘어갈 때도 동일한 함정이 다시 나타납니다. 자연스러운 본능은 궤적(trajectory)을 감사(audit)하는 것입니다. 즉, 에이전트의 주장(claims)을 추적하고, 실행 과정에서 수집된 증거와 각 주장을 대조하며, 주장이 뒷받침되지 않는 구간(spans)을 표시하는 것입니다.
이는 최종 답변 채점 (final-answer grading) 방식보다 실질적으로 개선된 방식입니다. 하지만 "궤적의 증거에 의해 뒷받침됨 (supported by the trajectory's evidence)"이 무엇을 의미하는지 주목하십시오. 여기서 증거란 에이전트(agent)가 스스로 수집한 것을 의미합니다. 에이전트가 직접 수집한 증거와 주장을 대조하는 것은 뒷받침되지 않는 주장과 자기 모순적인 주장을 잡아낼 수 있으며, 이 둘은 모두 내부 일관성 (internal-consistency) 실패에 해당합니다. 그러나 이 방식은 구조적으로 "뒷받침되지만 틀린 주장 (supported-but-wrong claim)"에는 무력합니다. 예를 들어, 검색 결과로 확신에 찬 잘못된 스니펫 (snippet)이 반환되었고, 주장이 그 스니펫에 충실하게 근거하고 있다면 말입니다. 이 경우 주장은 실제로 근거를 갖추고 있으므로 지원 확인 (support check)을 통과하지만, 단지 궤적 (trajectory)이 세상에 대해 잘못 알고 있을 뿐입니다. 궤적에 대해 주장을 감사 (auditing)하는 것은 최종 답변보다 한 단계 위에서, 행위자의 설명 (account)을 행위자의 설명과 대조하여 감사하는 것입니다.
해결책은 경로를 더 잘 감사하는 것이 아닙니다. 이전 단계로부터 "우리는 괜찮다"라는 상태를 상속받는 대신, 각 단계가 실행되는 순간의 기본 상태 (primary state)를 바탕으로 자신의 발판을 다시 증명 (re-prove)하게 만드는 것입니다. 무언가 표류 (drift)하기 시작하면, 가짜를 들고 끝까지 행진하는 대신 전제 조건 (precondition)을 더 이상 재도출 (re-derive)할 수 없는 첫 번째 단계에서 체인이 끊어지게 됩니다. 그리고 기본 설정이 뒤집혀야 합니다. 즉, "문제가 발견되지 않는 한 계속 (continue-unless-flagged)"하는 것이 아니라, "정당성이 입증되지 않는 한 중단 (stop-unless-warranted)"하는 방식으로 바뀌어야 합니다. 표류는 루프가 기본적으로 계속 진행되기 때문에 계속해서 진행되는 것입니다.
실제로 시도해 보며 얻은 한 가지 주의 사항은, 매 단계마다 모든 것을 재도출하려고 하면 데드락 (deadlock)에 빠질 수 있다는 점입니다. 조용히 발생한 표류가 복구 불가능한 단계들, 즉 부작용 (side-effect)이 발생하여 되돌릴 수 없는 단계들만 재도출하고, 비용이 저렴하고 가역적인 읽기 (reversible reads) 작업들은 그대로 진행하도록 두십시오.
위임은 권한을 세탁한다 (Delegation launders authority)
이러한 현상이 마지막으로 나타나는 곳은 두 에이전트 (agent) 사이의 경계입니다. 에이전트 A가 에이전트 B에게 작업을 넘길 때, A의 정책 (policy) 체크는 A의 측면에서 실행되고 B의 체크는 B의 측면에서 실행됩니다. 이때 두 개의 국소적으로 올바른 (locally-correct) 정책의 결합은 전역적으로 올바르지 (globally correct) 않습니다. 조용한 실패는 다음과 같습니다: B는 A의 권한이 아닌 B 자신의 권한으로 실행됩니다. 따라서 A가 위임하는 순간, 권한의 상한선 (authority ceiling)은 두 권한 중 더 작은 쪽에서 B의 권한 수준으로 급격히 뛰어오릅니다. "A는 요약을 요청할 수 있다; B는 문서를 읽을 수 있다"라는 문장은 "A는 결코 읽을 수 없는 문서의 요약을 얻는다"로 결합되며, 모든 국소적 체크는 통과됩니다.
권한 발견 (Capability discovery)도 이를 해결하지 못합니다. B가 무엇을 할 수 있는지 광고하는 것은, 주어진 작업에서 B가 누구의 권한 하에 그 일을 수행하는지에 대해서는 아무것도 말해주지 않기 때문입니다. 이를 해결하는 방법은 감쇠 (attenuation)입니다. A는 B에게 단순히 작업만 넘기는 것이 아니라, A 자신의 권한보다 넓지 않은 범위가 제한된 허가 (scoped grant)를 함께 넘깁니다. 그러면 B의 행동은 B가 단독으로 허용된 권한이 아니라, 자신이 받은 허가에 의해 승인됩니다. 이 허가는 작업과 함께 이동하며, B는 이를 해당 행동을 승인한 근거로 제시합니다. 그리고 결합된 결과에 대해 책임을 져야 하는 사람은 이를 감사 (audit)할 수 있습니다. 이제 결합된 결과는 구조적으로 더 작은 권한을 초과할 수 없습니다.
단 하나의 원칙
이 모든 것들은 서로 다른 옷을 입고 있을 뿐 동일한 움직임입니다. 자기 검증 (Self-checks), 보관 (custody), 궤적 (trajectories), 위임 (delegation) — 해결책은 언제나 판결 (verdict)이 행위자가 스스로 만들어낼 수 없는 무언가에 의존하도록 만드는 것입니다. 기본 상태 (primary state)로부터 그것을 다시 유도하십시오. 행위자가 작성하지 않은 추적 (trace)을 읽으십시오. 행위자가 키를 가지고 있지 않은 서명 (signature)을 요구하십시오. 행위자 스스로는 발행할 수 없는 허가 (grant)에 행동을 결속시키십시오.
따라서 제가 계속해서 되돌아오는 테스트는 가장 저렴한 방식입니다. 무언가가 "검증됨 (verified)"이라고 말할 때, 무엇이 그 증거를 생성했는지, 그리고 검증 대상이 되는 대상이 그 증거를 스스로 생성할 수도 있었는지를 물으십시오. 만약 대답이 "예"라면, 당신은 검증을 가진 것이 아닙니다. 당신은 그저 스스로에게 동의하고 있는 시스템, 그리고 공짜로 초록불을 켜주는 대시보드를 가지고 있을 뿐입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기