조만간, 테이블 맞은편에 앉은 누군가가 질문을 던질 것입니다. 고객사의 보안 팀, 감사관, 인수 기업의 실사 엔지니어, 규제 기관, 혹은 새벽 2시의 당신일 수도 있습니다.

"왜 이 에이전트가 그런 행동을 하도록 허용된 것입니까?"

"작동하는가"가 아닙니다. 데모(demo)가 그 질문에 답하며, 데모는 저렴합니다. "얼마나 성능이 좋은가"도 아닙니다. 벤치마크(benchmark)가 타인의 테스트 세트를 통해 그 질문에 답합니다. 질문의 핵심은 왜 그것이 **허용(allowed)**되었는가입니다. 언어 모델(language model)이 당신의 고객과 자금 근처에서 작동하도록 결정한 구체적인 근거는 무엇이며, 그 논리가 1년 뒤 당신에게 다시 전달되었을 때도 유효할 것인가 하는 점입니다.

우리는 채팅, 음성, 전화, SMS 등 모든 것의 밑바탕에 하나의 결정론적 코어(deterministic core)를 두고 거래를 수행하는 AI 에이전트(AI agent)를 구축합니다. 이전 에세이에서 우리는 언어 모델이 대화를 주도하는 동안 해당 코어가 모든 결정을 내려야 한다고 주장했습니다. 두 번째 에세이에서는 글을 쓰는 모델이 결코 채점하는 모델이 되어서는 안 된다고 주장했습니다. 이 에세이는 세 번째 막이며, 앞선 두 단계가 무엇을 향해 구축되었는지를 묻습니다. 즉, 에이전트의 개발이 완료되었을 때, 실제로 무엇이 그것을 프로덕션(production) 환경에 투입하도록 승인하는가에 대한 질문입니다.

우리의 답변은 화려하지 않습니다. 출시 리뷰도, 리더보드(leaderboard)도, 승인 회의도 아닙니다. 바로 **파일(file)**입니다.

주제의 특성상 이 에세이가 어떤 성격인지에 대해 언급하겠습니다. 앞선 두 에세이는 우리가 무엇을 구축하고 측정했는지를 보고했으며, 모든 주장에는 영수증(receipt)이 있었습니다. 이번 에세이는 그 영수증보다 더 나아갑니다. 여기서 설명하는 시스템은 실제 프로덕션에서 작동 중이지만, 이어지는 내용의 일부는 **우리가 수행한 작업으로부터의 추론(extrapolation)**입니다. 즉, 구축된 시스템이 가리키는 결론을 종이 위에서 도출한 것이며, 아직 실행 중인 것은 아닙니다. 저는 그 경계를 넘을 때마다 표시를 할 것입니다. 측정된 것과 추론된 것 사이의 경계를 흐리는 인증에 관한 에세이는 스스로 설정한 기준에 미달할 것이기 때문입니다.

Part I — 데모가 답할 수 없는 질문

형식적인 절차를 걷어내고 보면, "이 에이전트는 프로덕션에서 실행될 수 있다"라는 주장은 네 가지 사항을 단언하는 것입니다:

1. 그 권한은 제한적입니다 (Its authority is bounded). 해당 에이전트가 내릴 수 있는 결정의 목록은 알려져 있고 유한하며, 그 목록에 없는 모든 것은 권장되지 않는 것이 아니라 불가능합니다.
2. 입력값은 출처에 의해 신뢰됩니다 (Its inputs are trusted by origin). 에이전트가 처리하는 모든 데이터 조각은 출처(provenance)를 가지며, 단순한 존재 여부가 아니라 출처가 해당 데이터로 무엇을 할 수 있는지를 결정합니다.
3. 그의 발언은 측정됩니다 (Its words are measured). 모델이 자유롭게 내뱉는 모든 말은 모델이 아닌 다른 무언가에 의해 증거를 바탕으로 평가되었습니다.
4. 모든 과정은 재현 가능합니다 (All of it replays). 누구라도 나중에 무엇이 승인되었는지, 어떤 증거를 바탕으로 했는지 정확히 재구성하고 그 추론 과정을 직접 확인할 수 있습니다.

이 목록에서 무엇이 빠져 있는지 주목하십시오: 바로 _개발자의 자신감(the builder's confidence)_입니다. "우리가 만들었고 잘 작동한다"라는 말은 개발자가 자신의 숙제에 스스로 점수를 매기는 것과 같습니다. 이는 두 번째 에세이에서 단일 문장이 아닌 에이전트 전체 규모로 독립성을 구축하기 위해 다섯 파트에 걸쳐 다루었던 바로 그 이해관계의 충돌(conflict of interest)입니다. 모델은 자신의 글에 스스로 점수를 매겨서는 안 되며, 팀은 자신의 에이전트를 인증할 수 없습니다. 팀이 부정직해서가 아니라, 인센티브가 한 방향을 향하고 있으며, 말하자면 그 가중치(weights)가 이미 고착되어 있기 때문입니다.

첫 번째 에세이는 하나의 요청(request) 안에서 결정자(decider)와 서술자(narrator)를 분리했습니다. 두 번째 에세이는 하나의 빌드(build) 안에서 평가자(evaluator)와 작성자(writer)를 분리했습니다. 인증(Certification)은 한 단계 더 높은 수준에서 동일한 절단을 수행합니다. 즉, 구축하는 당사자(the party that admits)와 인정하는 것(the thing that admits)을 분리하는 것입니다. 그리고 저희의 관점에서 인정하는 당사자는 위원회가 되어서는 안 됩니다. 그것은 바로 증거(the evidence)여야 합니다.

제2부 — 증거 파일 (The evidence file)

다음 내용은 구축되고 측정된 것입니다 — 이것은 우리가 오늘날 우리 자신의 에이전트를 위해 생성할 수 있는 파일입니다.

권한(Authority)은 기분이 아니라 목록입니다. 우리 모델이 주문을 제출하면, 요청은 서버 측 함수(server-side function) 하나에 도달하며, 해당 함수는 다섯 가지 유형의 결과 중 하나로 응답합니다 — 주문 완료(order placed), 연락 필요(contact needed), 확인을 위한 연락(contact to confirm), 장바구니 비어 있음(cart empty), 또는 사유 코드가 포함된 실패(failure with a reason code). 그 목록이 바로 돈에 대한 에이전트의 권한입니다. 그 외의 다른 일은 일어날 수 없습니다. 왜냐하면 코어(core)가 반환하는 것 외에는 아무것도 없기 때문입니다. 이것이 증거 파일(evidence file)에 포함되어야 할 첫 번째 요소이자 확인 비용이 가장 저렴한 요소입니다: 바로 열거된 결정들(enumerated decisions)입니다. 만약 그 목록을 글로 적을 수 없다면, 당신의 에이전트는 제한된 권한(bounded authority)을 가진 것이 아니라, 단지 경향성(tendencies)을 가질 뿐입니다.

진지함(Seriousness)은 코드에 무엇을 넣을지에 대한 기준이 아닙니다. 결정론(Determinism)이 기준입니다. 모든 "중요한" 것을 결정론적인 코어(deterministic core)로 옮기고 싶은 유혹이 생깁니다. 하지만 그것은 잘못된 테스트입니다. 코드로 옮겨지는 것은 "코드 실행 시점에 알 수 있는 정답(code-time-knowable correct answer)"이 있는 것들입니다 — 임계값(thresholds), 조회(lookups), 멱등성(idempotency), 필수 고지 사항(required disclosures) 등이 그것입니다. 진정한 판단(judgment call)을 강제로 코드에 집어넣으려 한다면, 그것을 조잡한 대리 지표(proxy)로 축소시키거나, 뒷문으로 모델을 몰래 들여보내게 되어 코어를 신뢰할 수 있게 만들었던 바로 그 속성을 파괴하게 됩니다. 판단이 필요할 때 취해야 할 올바른 조치는 두 번째 에세이에서 설명한 방식입니다: 모델은 **타입화된 판결(typed verdict)**을 내보내고, 코어는 그에 따른 **행동(action)**을 결정합니다. 판단은 모델에 의해 측정되고, 결과(consequence)는 코드에 의해 소유됩니다. 이와 동일한 분리가 재귀적으로 적용됩니다.

우리가 이제 규칙으로 취급하는 하나의 따름정리(corollary)가 있습니다: 에이전트(agent)는 결정 규칙이 이미 배포 가능한 형태 — 즉, 문서화된 정책(policy), 기존의 검증된 시스템, 또는 거버넌스가 적용된 모델 — 로 존재하는 경우에만 결정을 내릴 수 있다는 것입니다. 규칙이 어디에도 존재하지 않는 곳, 즉 호출이 진정으로 재량적인(discretionary) 경우에는 에이전트도, 당신의 프롬프트(prompt)도 그 규칙을 만들어낼 수 없습니다. 에이전트는 _인지(perception)_를 수행합니다: 무질서한 입력을 읽고, 구조를 추출하며, 요약본을 작성합니다. 결정은 사람 또는 포착된 로직(captured logic)이 내립니다. 이것은 제한적으로 들릴 수 있지만, 실제로는 해방감을 줍니다. 왜냐하면 엄청난 양의 가치 있는 작업들이 자동화되지 않았던 이유는 로직이 없어서가 아니라, _입력값(inputs)_이 비구조화된 상태로 들어왔기 때문입니다. 규칙은 언제나 문서로 작성되어 있었습니다. 다만 읽기(reading) 단계에서 차단되었을 뿐입니다. 그리고 읽기야말로 바로 이 모델들이 존재하는 목적입니다.

출처(Provenance), 그리고 소모되는 증거. 첫 번째 에세이에서 이 메커니즘을 자세히 다루었으므로 요약하자면 다음과 같습니다: 우리의 핵심 신뢰는 데이터가 어디에서 왔는지 — 이번 턴에 제공되었는지, 이번 세션에서 확립되었는지, 혹은 이전에 파일로 존재했는지 — 에 따라 결정됩니다. 그리고 각 출처는 서로 다른 것을 승인합니다. 세션 증거(Session evidence)는 일회용 토큰으로, 그것이 보증하는 주문(order)에 의해 소모되므로, 두 번째 주문이 첫 번째 주문의 증거에 올라탈 수 없습니다. 제출(Submissions)은 카트(cart)를 원자적(atomically)으로 점유하므로, 타임아웃(timeout)을 재시도하는 모델은 새로운 쌍을 발행하는 대신 동일한 주문을 재생합니다. 이 문장들 각각은 어딘가에서 단위 테스트(unit test) 역할을 수행하며, 바로 그것이 이 문장들을 아키텍처 슬라이드가 아닌 증거로 만듭니다.

게이트(gate)는 대시보드가 아닙니다. 우리의 판사(judge) — 작성자와는 다른 모델이며, 동일한 작성 표준을 읽는 모델 — 는 타입이 지정된 평결(typed verdicts)을 내리고, 각 주장(claim)을 있는 그대로 인용하며, 대조 확인한 증거 경로(evidence path)를 명시하고, 플래그(flag)가 지정된 주장과 함께 통과(cleared)된 주장들을 보고합니다. 하지만 인증(certification)에서 중요한 세부 사항은 평결 이후에 일어나는 일입니다. 즉, 근거 설정 실패(grounding failures)는 머지(merge)를 차단하며, 품질은 트렌드로 추적됩니다. 하나는 게이트(gate)이고 다른 하나는 게이지(gauge)입니다. 이 둘을 혼동하는 것이 평가(eval) 프로그램이 실패하는 방식입니다. 빌드를 실패하게 만들 수 없는 체크(check)는 통제(control)가 아닙니다. 그것은 의견만 담긴 대시보드일 뿐입니다.

모든 것은 재생(replay)됩니다. 판정된 모든 실행(run)은 자신이 본 것, 즉 프롬프트(prompt), 제공된 증거(evidence), 평결(verdict), 모델 및 버전을 유지합니다. 프롬프트 버전과 지식 콘텐츠는 캐시 키(cache keys)로 해싱(hashed)되므로, 캐시된 출력 중 알 수 없는 프롬프트로부터 생성된 것은 결코 존재할 수 없습니다. 표준을 수정하면 그에 의존하는 모든 것이 설계상(by design) 재생성됩니다. 모든 프롬프트 변경 사항에는 변경 로그(changelog) 항목이 포함됩니다: 변경을 강제한 사례, 이유, 변경 내용, 그리고 판정된 검증(judged verification)까지 말입니다. 두 번째 에세이에서는 재확인할 수 없는 평결은 도구가 아니라 기분(mood)이라고 말했습니다. 한 단계 더 나아가면 동일한 법칙이 적용됩니다. 재생(replay)할 수 없는 인증은 결정이 아닙니다. 그것은 의견일 뿐입니다.

제3부 — 지도, 그리고 비어 있는 열

이 부분은 시스템이 아니라 감사(audit)입니다. 우리가 작성하지 않은 표준에 따라 종이 위에서 수행되는 실제 작업입니다.

자신의 아키텍처(architecture)에 대한 확신은 가치가 거의 없습니다. 결국 위의 에세이들은 구축자(builder)가 하는 말이기 때문입니다. 그래서 최근에 우리는 적대적(adversarial)인 방식을 취했습니다. 우리는 두 가지 패턴 — 핵심 결정(core-decides), 판사 측정(judge-measures) — 을 가져와서 NIST의 AI 위험 관리 프레임워크(AI Risk Management Framework)와 EU AI 법(EU AI Act)의 고위험 조항에서 추출한 25가지 요구사항 앞에 놓았습니다. 우리의 프롬프트를 읽어본 적도 없고 우리에게 아무런 채무도 없는 사람들이 작성한 프레임워크입니다.

결과로 나온 지도는 세 가지 색상으로 나타났습니다: 10개 요구사항 충족, 10개 부분 충족, 그리고 나머지는 비어 있음(open).

Covered(충족) 항목들은 정확히 예측 가능한 위치에 군집해 있었으며, 이는 그 자체로 유용한 점검 지표가 됩니다. 정확성(Accuracy)과 진실성(Truthfulness)은 심판(judge)의 존재 이유 그 자체입니다. 견고성(Robustness)과 신뢰성(Reliability)은 멱등성(idempotency), 채널 간 일관성(cross-channel consistency), 재시도 안전성(retry-safety)을 의미합니다. 로깅(Logging)과 추적 가능성(Traceability) 측면에서, 타입이 지정된 결과물(typed outcomes)은 구조적으로(by construction) 감사 가능합니다. 이미 값(value)인 결정에 로깅을 추가하는 것이 아니기 때문입니다. 독립적인 측정(Independent measurement)은 작성자가 아닌 보정된 평가자(calibrated evaluator)를 의미합니다. NIST의 용어로 표현하자면, 심판은 측정(Measure) 함수이고 핵심은 관리(Manage) 함수이며, 이 두 패턴은 구현된 두 개의 박스로 나타납니다.

Partial(부분 충족) 항목은 아키텍처가 도움을 주지만 완결짓지는 못하는 영역입니다: 데이터 거버넌스(data governance), 투명성(transparency), 인간의 감독(human oversight) 등이 여기에 해당합니다. 핵심 요소는 감독을 가능하게 만듭니다. 사람이 검토할 수 있는 투명하고, 로깅되었으며, 설명 가능한 결정은 단순히 승인(rubber-stamp)만 해야 하는 모델의 출력보다 엄격히 더 낫습니다. 하지만 '가능하다'는 것이 '완료되었다'는 것과 같지는 않습니다. 최종 사용자에게 정보를 공개하는 것(Disclosure) 또한 이 영역에 속하며, 이는 교훈적인 사례를 제공합니다. 우리가 출시하는 모든 에이전트는 채팅, 음성, 전화 등 모든 채널에서 첫 문장에 자신을 AI라고 소개합니다. — "안녕하세요, 당신의 AI 어시스턴트 Kai입니다. 오늘 무엇을 도와드릴까요?" — 하지만 이 문장은 강제된 게이트(enforced gate)가 아니라 설정 가능한 인사말(configurable greeting)에 존재합니다. 즉, 상인이 이를 편집하여 없애버릴 수도 있다는 뜻입니다. 기본적으로 처리된다는 것(Handled by default)이 구조적으로 보장된다는 것(guaranteed by construction)과 같지는 않으며, 이 둘을 모호하게 만드는 지도는 스스로를 과찬하는 것에 불과할 것입니다.

마지막으로 open(미충족) 열이 있으며, 여기서 우리에게 이번 과제의 틀을 다시 짜게 만든 발견이 있었습니다. 미충족 항목들은 다음과 같았습니다: 책임(accountability)과 소유권(ownership). 제3자 및 벤더 모델의 거버넌스(Governance). 편향성(Bias) 및 공정성(fairness) 검토. 개인정보(Privacy) 및 개인식별정보(PII) 처리. 런타임 모니터링(Runtime monitoring) 및 사고 대응(incident response).

그 목록을 두 번 읽어보십시오. 모든 미결 항목은 조직적인(organizational) 문제입니다. 그중 단 하나도 당신이 설계할 수 있는 게이트(gate)가 아닙니다. 어떤 타입화된 결과물(typed outcome)도 책임 있는 소유자(accountable owner)를 만들어내지 못하며, 어떤 판사(judge)의 판결도 새벽 3시에 사고 채널(incident channel)에 인력을 배치하지 못합니다. 어떤 캐시 키(cache key)도 벤더(vendor)를 검토하지 않습니다. 아키텍처(architecture)는 정확히 조직도(org chart)가 시작되는 지점에서 끝이 났습니다. 이는 아키텍처의 실패가 아닙니다. 인증(certification)이 엔지니어링 문제로서의 성격을 잃는 지점을 발견한 것입니다. 모든 항목이 '그린(green)'으로 나온 감사(audit) 결과가 있었다면, 우리가 우리 자신을 완만하게 감사했다는 사실 외에는 아무것도 알려주지 않았을 것입니다.

동일한 작업 과정에서 얻은 또 하나의 정직한 발견은, 우리를 놀라게 했기에 공유합니다. "고위험 주장(high-stakes claim)"과 "고위험 시스템(high-risk system)"은 서로 다른 축입니다. EU AI 법(EU AI Act)에 따르면, 상거래 에이전트(commerce agent)는 제한적 위험(limited-risk)에 해당합니다. 이 에이전트의 법적 의무는 진실성이 아니라 공개(disclosure)입니다. 이 법은 틀린 문장이 얼마나 비용이 많이 드느냐가 아니라, 도메인(domain)에 따라 등급을 나눕니다. 우리의 가드레일(guardrail) 작업은 법령이 요구하기 때문이 아니라, 잘못된 약속이 판매자에게 입히는 비용이라는 상업적 근거에 의해 정당화됩니다. 팀들은 양방향 모두에서 준수(compliance) 압박을 과장하곤 하지만, 이 지도는 실제로 어떤 힘이 밀어붙이고 있는지에 대해 정직함을 유지하게 해줍니다.

그리고 감사는 우리가 이전에 명명하지 않았던 이음새(seam)를 드러냈습니다. 판사(judge)는 개발(development) 단계에서 작동합니다. 작성자의 프롬프트(prompt)가 어디서 새어나가는지 찾기 위해 출력을 채점한 뒤, 결정론적 게이트(deterministic gates)가 감시하고 있는 운영(production) 단계에서는 물러납니다. 이는 즉, 런타임(runtime) 시점에는 서사(narration)를 독립적으로 검증하는 것이 아무것도 없음을 의미합니다. 모델이 실제 고객에게 내뱉는 단어들은 정규 표현식(regex)과 잠금된 사실(locked facts)을 통과할 뿐, 그 외에는 아무것도 거치지 않습니다. 오늘날 우리의 리스크 프로필(risk profile) 관점에서 이는 합리적인 트레이드오프(trade-off)입니다. 하지만 이 이음새를 명명함으로써, 다음 메커니즘이 무엇이어야 하는지를 정확히 알 수 있게 됩니다. 그리고 바로 그 지점에서 증거(receipts)는 끝이 납니다.

제4부 — 추론 (Extrapolations)

경계선은 바로 여기입니다. 아래의 모든 내용은 위 작업으로부터의 추론(extrapolation)입니다. 구축된 시스템을 바탕으로 종이 위에서 논의된 내용이며, 아직 실행 중인 것은 아닙니다. 만약 우리가 당신에게 이 내용을 다른 방식으로 읽게 내버려 둔다면, 우리 자신의 판사(judge)가 우리에게 플래그(flag)를 표시할 것입니다.

첫 번째 추론: 발화(utterance)가 아닌 결과(consequence)를 차단하십시오. 고객이 문장을 들은 후에는 일괄 검사(batch-check)를 할 수 없습니다. 이미 발화된 단어에 대한 느린 검사는 모니터링(monitoring)일 뿐, 가드레일(guardrail)이 아닙니다. 하지만 당신은 *결과(consequence)*를 차단할 수 있습니다. 되돌릴 수 없는 단계를 즉시 그리고 멱등(idempotently)하게 캡처하십시오. 예를 들어, 주문이 접수될 때 '검토 대기 중'으로 표시하는 것입니다. 그런 다음 캡처와 이행(fulfillment) 사이의 시간적 여유(window) 동안, 지연 시간 예산(latency budget)을 전혀 고려할 필요가 없는 환경에서 강력한 판사(judge)를 실행하십시오. 즉, 전체 전사 데이터(transcript)를 전체 증거 파일(evidence file)과 대조하며 판사가 원하는 만큼 충분한 시간을 갖게 하는 것입니다. 결정론적 코드(Deterministic code)는 판결을 읽고, 무언가가 배송되거나, 청구되거나, 실제로 구현되기 전에 이를 승인, 보류 또는 수정합니다.