계약 상태의 망령: 에이전트 간 프로토콜 호환성 실패의 기술 진단

초록 현대의 리걸테크 시스템은 여러 에이전트가 협력하여 복잡한 법률 문제를 해결하도록 설계된다. 그러나 각 에이전트가 서로 다른 프로토콜 버전을 지원할 때, 상태 불일치(state inconsistency)와 의존성 체인 붕괴(dependency chain collapse)가 발생한다. 본 칼럼은 RFC 등 표준 명세 기반으로 버전 협상의 기술적 메커니즘을 분석하고, 법률 도메인에서의 무결성 영향을 진단하며, 상태 원본성(state authenticity) 검증을 통한 해결책을 제시한다. 이는 단순 호환성 문제를 넘어 법률 AI의 신뢰성 아키텍처의 근본에 관계된 설계 과제다.

법률 자동화 시스템에서 자주 경험하는 무서운 장면이 있다. A 에이전트가 검색한 판례를 B 에이전트에 인용하려 할 때, 두 에이전트가 이해하는 '판례 상태'가 다를 수 있다는 점이다. A는 '2024년 9월 개정 대법원규칙' 기준으로 사건번호를 읽지만, B는 여전히 '구 규칙'의 해석을 유지하고 있을 수 있다. 더 깊은 차원에서는 통신 프로토콜 자체의 버전이 맞지 않아, 한쪽이 보낸 메타데이터 구조를 다른 쪽이 무시하거나 오독할 수 있다. 이를 단순 '호환성 문제'로 치부하면 안 된다. 법률 도메인에서 상태 불일치는 근거 체인 전체를 오염시킬 수 있고, 최종 의견서의 무결성을 근본적으로 훼손한다. RFC 체계에서 보는 프로토콜 버전 협상의 원리와, 그것이 법률 에이전트 생태계에서 왜 실패하는지, 그리고 어떻게 설계 수준에서 차단할 수 있는지 기술 깊이 있게 살펴보자.

핵심 기술 개념

프로토콜 버전 협상(Protocol Version Negotiation)

두 개 이상의 시스템이 통신을 시작할 때, 서로 지원하는 프로토콜 버전 중 공통으로 실행 가능한 최고 버전을 선택하는 핸드셰이크 과정. RFC 표준에서는 이를 명시적 제안-응답 메커니즘이나 버전 비트맵으로 정의한다.

상태 원본성(State Authenticity)

분산 시스템에서 각 노드의 상태가 신뢰할 수 있는 단일 출처(single source of truth)에서 파생되었음을 보증하는 성질. 법률 에이전트의 경우, 인용된 판례·조문·판시의 상태 메타데이터가 원본 저장소와 일치함을 의미한다.

의존성 체인(Dependency Chain)

한 에이전트의 출력이 다음 에이전트의 입력으로 사용되는 일련의 처리 과정. 중간 어느 지점에서 버전 불일치가 발생하면, 그 이후 모든 출력이 오염되는 캐스케이드 실패를 초래한다.

MCP(Model Context Protocol)

여러 LLM 기반 에이전트가 공통된 인터페이스로 도구와 정보에 접근하도록 하는 메시지 프로토콜. Anthropic 주도로 표준화 진행 중이며, 버전 관리와 기능 협상이 핵심 설계 요소다.

기술 심층 분석

버전 협상의 기술 구조: RFC 표준 모델에서 본다

RFC 체계에서 버전 협상은 두 가지 주요 전략으로 나뉜다. 첫째, 명시적 제안-응답 방식으로, 클라이언트가 지원하는 버전 목록을 제시하면 서버가 그 중 선택하거나 거부하는 방식이다. RFC 10033(Hash-Based Signatures에서의 상태 관리)은 이를 상태 추적의 맥락에서 다루는데, 각 프로토콜 버전이 고유한 상태 스키마를 가지므로, 협상 실패 시 상태 불일치가 필연적이라고 지적한다. 둘째, 기능 비트맵 방식으로, 각 메시지에 지원 기능을 나열하여 수신측이 동적으로 해석하는 방식이다. 그러나 법률 시스템에서는 이 두 방식 모두 문제가 있다. 명시적 협상은 모든 에이전트 쌍이 먼저 버전을 교환해야 하는데, 멀티홉 에이전트 파이프라인에서 중간 노드의 버전 정보가 전파되지 않을 수 있다. 기능 비트맵은 '하위 호환성(backward compatibility)' 가정에 의존하는데, 법률 도메인의 상태(예: 사건번호 형식, 판시 구조)는 하위 호환이 아닐 수 있다. RFC 10018(세그먼트 라우팅과 다중경로 설정)에서 본 점-대-다중점 구조를 법률 에이전트 네트워크에 빗대면, 루트 에이전트에서 나온 입력이 여러 리프 에이전트로 분산될 때 각각이 다른 프로토콜 버전으로 재처리되는 상황과 같다. 이때 루트에서의 상태 결정이 리프들에게 전파되지 않으면 최종 합의(consensus)가 불가능해진다.

법률 도메인의 상태 복잡도와 버전 실패의 한계

법률 정보는 단순 데이터가 아니라 시간·버전·권한 종속성을 내장한 상태(stateful entity)다. 판례 인용을 예로 들면, 사건번호·판시문·법적 효력이 모두 그 판례의 상태를 구성하며, 각각은 판결 시점·개정 이력·상위법원 판단에 따라 변한다. 프로토콜 버전 A에서는 '사건번호'를 '2024-01-12345' 형식으로 정의하지만, 버전 B에서는 '2024/1/12345'로 변경되었다고 하자. A 에이전트에서 생성한 인용이 B 에이전트로 넘어올 때, B는 그 사건번호를 자신의 상태 저장소에서 검색하려다 실패한다. 이는 단순 포맷 불일치가 아니라, 그 판례에 대한 '메타데이터 신뢰성 체인'이 깨지는 것이다. RFC 10033이 강조하는 바와 같이, 상태 기반 시스템(stateful system)에서는 상태 무결성이 서명과 같은 보안 메커니즘보다 선행되어야 한다. 법률 에이전트는 결정론적(deterministic) 해석이 필수인데, 버전 불일치로 인한 상태 애매함이 발생하면 동일한 입력에 대해 다른 판단을 내릴 수 있다. 예를 들어 '구 상법' 해석과 '신 상법' 해석이 뒤섞이면, 동일 조항에 대해 법적 효력 판단이 달라질 수 있다. 이는 에이전트의 '할루시네이션'과는 다른 문제로, 아키텍처 수준의 실패다.

분산 파이프라인에서의 버전 불일치 전파 메커니즘

법률 AI 시스템이 A→B→C 순의 에이전트 체인으로 구성되어 있다고 가정하자. A 에이전트(문서 수집)가 프로토콜 버전 1.0을 지원하고, B(판례 검색 및 순위화)가 1.1, C(법적 의견 생성)가 1.2를 지원한다면, 세 에이전트가 명시적으로 협상하지 않는 한 각각 자신의 버전으로 상태를 인코딩할 것이다. RFC 표준에서는 이를 '우아한 성능 저하(graceful degradation)'로 처리하곤 한다. 즉, 공통 버전으로 협상하되 신 기능은 무시하는 방식이다. 그러나 법률 도메인에서는 이것이 위험하다. 예를 들어 버전 1.1에서 신규로 추가된 '판례 변경이력(precedent change log)' 필드를 버전 1.0 시스템이 무시하면, B 에이전트가 검색한 판례가 실제로는 폐기되었다는 정보를 C는 알 수 없게 된다. 더욱이, 분산 에이전트 환경에서는 버전 협상이 쌍 단위(pairwise)로만 일어나기 쉬우므로, A-B 협상에서는 1.0으로 내려가고, B-C 협상에서는 1.1로 올라가는 '지그재그' 현상이 발생할 수 있다. 이때 B에서 생성한 상태 메타데이터가 A에는 이해되지만 C에는 부분적으로만 이해되는 비대칭적 상황이 나타난다. RFC 9971(Multiple Loss Ratio Search)의 관점에서 보면, 이는 '반복 측정에서 결과가 불일치하는 현상'에 유사하다. 즉, 같은 입력으로 반복 조회해도 에이전트 간 버전 상태 변화로 인해 결과가 달라질 수 있다는 뜻이다.

상태 원본성 검증의 필요성과 설계 원칙

법률 에이전트의 신뢰성 아키텍처에서 '상태 원본성(state authenticity)'은 버전 협상만큼이나 중요하다. 즉, 어떤 판례 상태를 인용할 때, 그것이 정말로 공식 판례 저장소의 현재 상태를 반영하는지 검증되어야 한다. RFC 10033에서 언급한 '상태 백업 및 관리'의 원리를 차용하면, 각 에이전트는 그들이 사용하는 상태의 타임스탬프·버전 번호·암호 해시를 기록해야 한다. 법률 시스템에 적용하면, 인용할 판례마다 '이 판례를 조회한 에이전트의 버전', '조회 시점의 원본 저장소 버전', '현재 시점의 저장소 버전' 세 가지를 추적해야 한다는 뜻이다. 만약 조회 후 저장소가 업데이트되었다면, 그 인용이 여전히 유효한지 재검증해야 한다. 이는 단순 캐시 무효화(cache invalidation) 문제가 아니라, 법적 근거의 '시간-버전 종속성'을 명시화하는 과정이다. 예를 들어 '2024-08-15 시점의 A 에이전트 버전 1.1에서 조회한 대법원 판례 2024da12345'라는 완전한 메타데이터 표기가 필요하다. 이렇게 원본성을 명시하면, 나중에 다른 에이전트가 같은 판례를 인용할 때 '그때와 지금의 상태가 일치하는가'를 검증할 수 있다.

MCP 버전 협상 프레임워크의 현황과 법률 AI 적용의 간극

Anthropic이 주도하는 Model Context Protocol(MCP)은 에이전트 간 도구 공유와 정보 접근을 표준화하려는 시도다. MCP의 버전 협상 메커니즘은 기본적으로 클라이언트가 지원하는 버전을 제시하고, 서버가 지원 가능한 최고 버전을 응답하는 명시적 협상 방식을 따른다. 그러나 현재 MCP 명세에는 '상태 메타데이터의 버전 독립적 변환(version-independent transformation)' 규정이 부족하다. 즉, 법률 도메인처럼 상태 구조 자체가 버전에 따라 달라지는 도메인을 충분히 고려하지 않았다는 뜻이다. RFC 10040(지리적 좌표를 이용한 위치식별 분리 프로토콜)에서 본 '표준 인코딩 형식(Canonical Address Format)'의 개념을 MCP에 도입할 필요가 있다. 즉, 모든 버전 간에 공통으로 이해할 수 있는 '법률 상태의 표준 표현(canonical representation)'을 정의하고, 각 버전이 그것으로 변환한 후 전송하는 방식이다. 현재는 각 에이전트가 자신의 버전으로만 상태를 인코딩하기 때문에, 수신측이 그것을 '해독'할 때 손실이 발생한다. 법률 필드에서는 이 손실이 무결성 문제로 직결된다.

법률 에이전트 생태계의 버전 협상 실패 시나리오와 차단 전략

실제 시나리오를 구성해보자. 대형로펌의 법률 AI 시스템은 내부 에이전트 A(판례 검색, MCP 1.2)와 외부 협력사의 에이전트 B(법안 분석, MCP 1.3)를 연결한다. 협상 후 공통 버전 1.2로 동작하기로 결정했다고 하자. 그런데 B 에이전트의 개발사가 MCP 1.3에서만 지원하는 '개정 이력 필드'를 핵심 기능으로 사용하고 있었다면, 이것이 1.2로 내려가면서 상실된다. A가 받는 B의 응답에는 개정 이력이 없으므로, A는 '이 법안에 최근 개정이 없다'고 잘못 판단할 수 있다. 또 다른 시나리오는 '중간 에이전트의 버전 낙찰(version downgrade)'이다. 멀티홉 구조에서 중간 에이전트가 의도적으로 낮은 버전을 선택(또는 오작동으로 인해 낮은 버전으로 협상)하면, 그 이후의 모든 상태가 오염된다. 이를 차단하려면, 각 에이전트가 자신이 협상한 버전을 명시적으로 기록하고, 하위 에이전트에 전파해야 한다. 또한 최종 출력 단계에서 '버전 타임스탬프 검증'을 수행하여, 모든 중간 처리 단계에서 최소 요구 버전 이상이 사용되었음을 확인해야 한다. RFC 체계에서는 이를 '버전 일관성 검사(version coherence check)'라고 부를 수 있다. 법률 AI에서는 이것이 '인용 무결성 검증' 파이프라인의 선행 조건이 되어야 한다.

기술적 트레이드오프

긴장 관계 버전 하위호환성(backward compatibility)을 유지하려면 신 기능을 무시해야 하지만, 이는 법률 도메인에서 상태 정보 손실을 초래한다. 반대로 엄격한 버전 일치를 요구하면 분산 시스템의 유연성과 확장성이 크게 제한된다. 더욱이 법률 메타데이터는 실시간으로 업데이트되므로, 버전과 상태의 동기화 비용이 선형적으로 증가한다.

실무적 해소 법률 AI 생태계에서는 '표준 표현(canonical form)'을 매개로 하는 3계층 모델을 도입해야 한다. 첫째, 각 에이전트의 내부 버전별 표현을 유지하되, 둘째, 통신 전에 표준 표현으로 변환하고, 셋째, 수신측에서 자신의 버전으로 역변환한다. 이때 변환 과정에서 손실되는 정보는 메타데이터로 별도 기록하여, 나중에 검증 가능하도록 한다. 또한 모든 인용은 '원본 에이전트 버전', '변환 버전', '현재 저장소 버전' 세 가지를 함께 기록하여, 트레이드오프를 명시화한다. 이는 성능을 약간 희생하지만 법률 무결성을 보장한다.

법마디 OS에 적용한다면

법마디 OS는 다음 세 가지 업그레이드를 즉시 실행할 수 있다. 첫째, 모든 내부 에이전트와 외부 연동 에이전트 간의 버전 협상을 '강제 기록 모드'로 전환한다. 즉, A-B 협상 결과를 불변 로그에 남기고, 그 이후 이들의 모든 상호작용이 협상된 버전 범위 내에서만 일어나도록 검증한다. 둘째, 판례·조문·판시 같은 핵심 법률 상태에 대해 '표준 표현 스키마'를 정의한다. 예를 들어 {"source_version": "1.2", "object_type": "precedent", "case_id": "2024da12345", "queried_at": "2024-08-20T10:30:00Z", "canonical_hash": "sha256_value"}와 같은 메타데이터 구조를 모든 에이전트가 생성하도록 강제한다. 셋째, 인용 단계에서 '버전 일관성 검사'를 자동화한다. 즉, 법률 의견서를 생성하기 직전에, 모든 인용된 판례·조문의 메타데이터를 현재 저장소 상태와 대조하여, 버전 불일치나 상태 변경을 탐지한다. 만약 불일치가 있다면, 의견서에 '인용 시점 vs 현재 상태의 차이'를 명시적으로 기록한다. 이를 통해 사용자는 '이 의견은 언제의 법과 판례 상태를 기준으로 작성되었는가'를 명확히 알 수 있다.

기술적 함의

프로토콜 버전 협상은 단순 호환성 문제가 아니라 법률 무결성의 아키텍처적 기초이며, MCP 같은 표준도 도메인별 상태 관리 방식을 명시적으로 정의해야 한다.
분산 법률 에이전트 환경에서는 버전 정보와 상태 메타데이터의 기록·추적·검증이 인용 검증만큼 중요하므로, 이를 감사 체인(audit chain)의 일부로 설계해야 한다.
법률 AI의 신뢰성은 모델의 정확도보다는 시스템 아키텍처의 투명성과 상태 원본성 검증에 더 큰 영향을 받으므로, 기술 설계 단계부터 버전·상태·시간을 명시적으로 추적하는 메커니즘을 내장해야 한다.

"법률을 다루는 AI의 신뢰는 호환성으로 이루어지지 않는다. 그것은 불일치를 정직하게 추적하고, 그 추적 흔적을 검증 가능하게 남기는 아키텍처에서 비롯된다."

참고 자료

칼럼니스트

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기

본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.