낡은 계획, 신선한 기억: 분산 법률 에이전트의 동기화 실패와 의존성 범위 검증

초록 현대의 멀티에이전트 법률 AI 시스템은 공유 상태를 참조하면서도 각 에이전트의 행동이 구식 계획에 기반할 수 있는 치명적 비동기화 문제에 노출되어 있습니다. 이 칼럼은 PlanFence라는 의존성 범위 검증 프로토콜을 분석하여, 법률 에이전트가 자신의 행동 사전에 어떤 공적 기록(public record)이 영향을 미쳤는지 추적하고, 실행 시점에 그 의존성만 재검증함으로써 오래된 계획 실행을 방지하는 메커니즘을 규명합니다. 법마디 OS의 분산 협업 구조에 적용하면, 판례 변경, 법령 개정, 사건 진행 상태 변화 같은 동적 법률 환경에서 에이전트 간 의도 일치성과 행동 정당성을 보장할 수 있습니다.

법률 사건 처리에서 흔히 마주하는 상황을 생각해봅시다. 변론 담당 에이전트가 현행 판례법을 조회해 A 법리를 근거로 소송 전략을 수립했고, 그 계획을 문서화했습니다. 한편 법령 업데이트 에이전트가 해당 조문의 개정안을 시스템에 커밋했습니다. 이제 실행 담당 에이전트가 최신 법령 데이터베이스에서 신규 조항을 읽었습니다. 그런데 문제는, 실행 에이전트가 신규 조항을 보았다고 해서 구식 전략(A 법리 기반)을 자동으로 폐기하지 않는다는 점입니다. 상태 신선도(freshness)만으로는 이전 계획의 정당성을 보장할 수 없습니다. 이것이 '상태 비동기화(stale-plan execution)' 문제의 본질입니다. 본 칼럼에서는 이 문제를 진단하고, 분산 법률 에이전트 시스템의 무결성을 아키텍처 수준에서 어떻게 재설계해야 하는지 분석합니다.

핵심 기술 개념

상태 비동기화(Stale-Plan Execution)

분산 멀티에이전트 시스템에서 각 에이전트가 최신 공유 상태(예: 법령, 판례, 사건 진행 상황)를 읽었음에도 불구하고, 그 상태 변화 이전에 수립된 구식 행동 계획(plan)을 여전히 실행하는 현상. 상태의 물리적 신선도와 계획의 논리적 유효성은 별개의 문제입니다.

의존성 범위 검증(Dependency-Scoped Validation)

에이전트의 행동 계획이 어느 공적 기록(public record)에 의존하는지 명시적으로 추적하고, 실행 직전에 그 의존성 범위 내의 기록만 재검증하는 프로토콜. 시스템 전체 상태를 재검증하는 것이 아니라, 행동 정당성에 영향을 미칠 수 있는 최소 집합만 검증합니다.

공적 기록(Public Record)

멀티에이전트 시스템의 공유 상태 공간에서 모든 에이전트가 접근 가능하고 이력이 기록되는 객체. 법률 시스템의 맥락에서는 판례, 법령, 사건 기록, 당사자 신청 같은 공식 문서를 의미합니다.

재계획(Replanning)

에이전트가 의존성 검증 과정에서 참조하던 공적 기록이 변경되었음을 발견했을 때, 원래의 행동 계획을 폐기하고 신규 정보를 기반으로 새로운 행동 시퀀스를 생성하는 절차.

기술 심층 분석

1

상태 신선도와 계획 유효성의 비대칭성: 왜 최신 읽기만으로는 부족한가

분산 시스템 설계에서 흔히 범하는 오류는 '공유 상태가 최신이면 모든 에이전트의 행동도 최신이다'라는 가정입니다. 그러나 법률 시스템에서는 이 가정이 깨집니다. 예를 들어, 대법원 판례(공적 기록 R3)를 기반으로 전략을 수립한 에이전트 A가 있고, 동시에 법무부 훈령(공적 기록 R4)이 새로 추가되었다고 합시다. 에이전트 B가 R4를 읽었다고 해서, A의 계획이 자동으로 무효가 되는 것은 아닙니다. A의 계획은 여전히 R3에만 의존할 수 있기 때문입니다. 문제는 E 에이전트(실행자)가 R3, R4를 모두 읽고 있으면서도, A가 R3만으로 수립한 계획을 그대로 실행한다는 점입니다. 이 경우 E는 '상태는 신선하다'고 판단하지만, 실제로는 '계획의 의존성 기반(R3)은 여전히 유효한가?'라는 질문에 답하지 않은 것입니다. PlanFence의 핵심은 이 비대칭성을 명시적으로 인식하는 것입니다. 계획은 '인용(citation)' 형태로 정확히 어느 공적 기록을 사용했는지 기록하고, 실행 시점에는 그 인용된 기록들만 다시 확인하여 여전히 유효한지 검증합니다. 만약 인용된 기록이 변경되었다면 즉시 재계획을 시작하거나 행동을 중단합니다. 이 설계는 신선도 검사를 '무엇을 읽었는가'에서 '무엇에 의존하는가'로 패러다임을 전환합니다.

2

의존성 그래프 구축과 범위 제한: 검증 비용의 최적화

의존성 범위 검증을 구현하려면 먼저 '이 행동이 어떤 기록을 참조했는가'를 추적해야 합니다. 법률 에이전트의 경우, 하나의 법적 의견이 여러 판례, 조문, 선례 판례를 인용할 수 있습니다. 예를 들어 '채무불이행 손해배상 청구 소송 전략'이라는 계획이 (1) 민법 390조(채무불이행), (2) 대법원 2024년 판례 P123(인과관계 입증 기준), (3) 서울고등법원 2023년 판례 Q456(손해액 산정 방식)을 인용했다면, 의존성 집합은 {R390, RP123, RQ456}입니다. 실행 시점에 E 에이전트는 전체 판례 데이터베이스를 재스캔하지 않습니다. 대신 이 세 기록만 확인합니다: (1) 민법 390조가 여전히 효력 중인가? (2) P123이 아직 유효한 판례인가(상급심 판단으로 역전되지 않았는가)? (3) Q456이 여전히 준거 판례로 유지되는가? 이 세 질문의 답이 모두 '그렇다'면 계획은 검증을 통과합니다. 한 개라도 '아니다'면 재계획이 필요합니다. 이러한 범위 제한(scoped validation)은 두 가지 이점을 가져옵니다. 첫째, 검증 비용이 기록 개수에 정비례하지 않고, 해당 행동의 의존성 수에만 비례합니다. 둘째, 무관한 기록 변경(예: 다른 분야의 판례 갱신)은 이 행동의 유효성을 훼손하지 않습니다. 법마디의 분산 구조에서 이는 매우 중요합니다. 판례 데이터가 지속적으로 누적되는 환경에서, 모든 행동을 전체 코퍼스에 대해 재검증하는 것은 비현실적이기 때문입니다.

3

실시간 상태 변화와 블록-재계획 경계선: 의사 결정의 타이밍

의존성 범위 검증이 실제로 작동하려면, 검증 결과에 따른 에이전트의 반응을 설계해야 합니다. PlanFence 프로토콜은 두 가지 경로를 제시합니다: '재계획(replanning)' 또는 '블로킹(blocking)'. 재계획은 의존성이 부분적으로 무효화되었을 때, 신규 정보를 바탕으로 계획을 다시 수립하는 경로입니다. 예를 들어, '채무불이행 손해배상' 전략의 의존성인 대법원 판례가 최근 상황에 맞게 추가 설시를 내렸다면, 해당 신규 설시를 포함하여 전략을 재수립합니다. 반면 블로킹은 의존성 검증이 불완전할 때(즉, 필요한 기록에 접근할 수 없거나, 변경 여부를 확정할 수 없을 때) 행동을 중단하는 경로입니다. 법률 시스템의 특성상 블로킹은 매우 중요합니다. 불완전한 정보로 소송 전략을 실행하는 것은 의뢰인에게 해를 끼칠 수 있기 때문입니다. 법마디 OS의 맥락에서 이 경계선은 신뢰도 임계값(confidence threshold)으로 구현될 수 있습니다. 예를 들어 '이 행동의 의존성 검증 신뢰도가 95% 이상이면 재계획 모드, 미만이면 블로킹 모드'라는 규칙을 설정할 수 있습니다. 이렇게 하면 법적 리스크가 높은 상황에서는 에이전트가 신중하게 행동하고, 저위험 작업에서는 유연하게 대응할 수 있습니다.

4

인용 그래프의 안정성과 배치 업데이트 문제: 멀티턴 시나리오에서의 일관성

법률 시스템의 복잡성은 단순한 의존성 추적을 넘어섭니다. 판례나 법령이 변경될 때, 그것은 연쇄적 영향을 미칠 수 있습니다. 예를 들어, A 판례가 B 판례를 인용하고 있고, C 전략이 A 판례에 의존하고 있다면, B가 무효가 되면 A가 무효가 되고, 결과적으로 C도 무효가 됩니다. 이를 '인용 그래프의 연쇄 검증(transitive validation)'이라 합니다. PlanFence 프로토콜은 이를 직접 다루지는 않지만, 법마디 OS 수준에서는 이 문제를 명시적으로 해결해야 합니다. 한 가지 접근법은 의존성 캐싱입니다. 어떤 기록 R이 유효하다고 검증된 후, 그 검증 결과와 타임스탬프를 기록합니다. 동일한 검증이 일정 시간 내에 반복되면 캐시된 결과를 사용합니다. 다만 이 캐시는 배치 업데이트(batch update) 시점에 무효화되어야 합니다. 법무부가 법령을 일괄 개정하거나, 대법원이 선례 변경 판결을 내렸을 때, 관련 기록의 모든 인용 그래프를 일관되게 업데이트해야 합니다. 또 다른 중요한 문제는 '멀티턴 상황'입니다. 에이전트 A가 턴 1에서 전략 P를 수립하고, 턴 2에서 법령이 변경되고, 턴 3에서 A가 P를 실행하려 할 때, P의 의존성은 턴 1 기준인가 턴 3 기준인가? PlanFence의 설계상 실행 시점(턴 3) 기준으로 의존성을 검증합니다. 이는 '현재 상태 기준의 정당성'을 보장하지만, 사실관계의 일시성(temporal integrity)을 훼손할 수 있습니다. 법마디에서는 이 문제를 '기간별 의존성 버전 관리'로 해결할 수 있습니다. 각 기록이 변경될 때마다 버전 번호를 부여하고, 계획은 '턴 1 시점의 법령 버전 v5 기준'이라고 명시적으로 기록합니다.

5

법률 에이전트 간 신뢰와 권한 위임: 의존성 검증을 통한 책임 추적

분산 법률 에이전트 시스템에서는 권한 위임이 필연적입니다. 변론 전략 에이전트는 판례 조사 에이전트가 제시한 기록을 신뢰하고, 법령 업데이트 에이전트는 각 조문의 효력 여부를 정확히 보고할 것으로 가정합니다. 그런데 의존성 범위 검증은 이 신뢰 구조에 투명성을 더합니다. 예를 들어, 변론 에이전트가 '민법 390조에 따라 채무불이행을 주장한다'고 기록했다면, 실행 에이전트는 검증 시점에 이를 확인합니다. 만약 민법 390조가 개정되었다면, 어느 에이전트가 개정 정보를 놓쳤는지 추적할 수 있습니다. 이는 '감사 추적(audit trail)'의 토대가 됩니다. 법마디의 다중 에이전트 아키텍처에서 각 에이전트는 자신이 기여한 공적 기록에 책임을 집니다. 변론 에이전트가 거짓 판례를 인용했다면, 그것이 의존성 검증 과정에서 드러납니다. 이는 에이전트의 신뢰도 점수(reliability score)에 영향을 미칩니다. 장기적으로, 신뢰도가 낮은 에이전트는 점진적으로 권한을 제한받습니다. 이러한 설계는 '신뢰를 정책(policy)이 아니라 아키텍처(architecture)로 강제한다'는 원칙을 따릅니다.

6

블로킹 대 재계획의 선택과 실무적 함의: 법률 시스템의 리스크 프로필

의존성 검증의 결과는 두 가지 경로로 나뉩니다. 블로킹은 '행동을 멈춘다'는 뜻이고, 재계획은 '새로운 정보로 다시 계획한다'는 뜻입니다. 그런데 이 둘을 어떻게 구분할 것인가는 법률 시스템의 리스크 프로필에 따라 달라집니다. 법마디 OS의 용도를 생각해봅시다. 소송 전략 수립의 경우, 의존성 검증 실패는 보통 블로킹으로 이어집니다. 변론인이 이전 정보에 기반한 소송 전략을 집행하는 것은 의뢰인의 이익을 해칠 수 있기 때문입니다. 반면, 법률 조사(예: '현행 판례상 채무불이행의 인과관계 입증 기준은?') 같은 정보 제공 작업은 재계획 가능성이 높습니다. 조사 질문의 답변이 부분적으로 변경되었다면, 신규 정보를 포함하여 답변을 재구성할 수 있습니다. 이러한 구분은 '행동의 도메인과 돌이킬 수 없음의 정도'에 따릅니다. 돌이킬 수 없는 행동(예: 법원 제출 서면 작성, 대리인 약정)은 높은 검증 기준을 요구하므로 블로킹 경향이 강합니다. 가역적 행동(예: 내부 조사, 예비 의견서)은 재계획 가능성이 높습니다. 법마디에서는 각 에이전트 역할마다 '의존성 검증 실패 시 기본 정책'을 설정할 수 있습니다. 이를 통해 시스템 전체가 일관되고 투명한 의사 결정을 유지할 수 있습니다.

기술적 트레이드오프

긴장 관계 정확한 의존성 추적과 체계적 검증은 시스템 복잡도와 연산 비용을 크게 증가시킵니다. 반대로 검증을 간소화하면 상태 비동기화 위험이 높아집니다. 또한 블로킹 정책이 엄격할수록 안전하지만, 시스템의 응답성과 자율성이 떨어집니다. 의존성 범위를 좁혀서 검증 속도를 높이면, 간과된 의존성으로 인한 논리적 오류가 발생할 수 있습니다.

실무적 해소 이 긴장을 해결하는 실무적 방식은 '계층화된 검증 정책(tiered validation policy)'입니다. 고위험 행동(법원 제출 문서, 최종 법적 의견)에는 완전한 의존성 그래프 검증을 실시하고, 중위험 작업(내부 검토, 예비 조사)은 범위를 제한하며, 저위험 작업(정보 조회, 참고자료 제시)은 신속한 처리를 우선합니다. 또한 '동적 의존성 캐싱'을 도입하여 자주 참조되는 기록의 검증 결과를 메모화(memoize)함으로써 반복 검증의 비용을 절감합니다. 마지막으로, 의존성 검증 실패 시 자동 재계획보다는 '인간 검토 요청(escalation to human)'을 기본값으로 삼아, 시스템의 신뢰성을 인간의 최종 판단으로 보장합니다.

법마디 OS에 적용한다면

법마디 OS의 분산 에이전트 아키텍처에 의존성 범위 검증을 적용하는 방식은 다음과 같습니다. 첫째, 각 에이전트(판례 조사, 법령 해석, 소송 전략, 작성 등)의 생성 결과에 '의존성 메타데이터'를 첨부합니다. 예를 들어, 변론 전략이 생성될 때 "근거: [민법 390조 v12, 대법원 판례 2024-P123, 서울고등법원 선례 2023-Q456]"라는 형태로 기록합니다. 둘째, 실행 계층에 'PlanFence 검증 모듈'을 탑재합니다. 어떤 전략이나 의견이 실제로 사용되기 직전에, 의존성 목록의 각 기록이 여전히 유효한지 확인합니다. 만약 의존성이 변경되었다면, 회귀 신호(feedback signal)를 발생시켜 해당 에이전트에 재생성을 요청합니다. 셋째, 법령 및 판례 데이터베이스 변경 시 '버전 및 영향도 맵'을 유지합니다. 특정 조문이 개정되면, 그 조문을 의존성으로 하는 모든 전략을 식별하고, 각각의 재검증 우선순위를 결정합니다. 넷째, 에이전트 간 '신뢰도 피드백 루프'를 구성합니다. 의존성 검증 실패가 특정 에이전트의 과오에 기인했다면(예: 잘못된 판례 인용), 그 에이전트의 신뢰도 점수를 하향 조정하고, 향후 그 에이전트의 결과물은 더 엄격한 검증을 거치도록 합니다. 다섯째, 사용자 인터페이스에 '의존성 시각화(dependency graph visualization)'를 제공합니다. 변론인이 특정 소송 전략을 검토할 때, 그 전략이 어떤 법률 기록에 근거하는지, 그 기록들이 언제 마지막으로 검증되었는지를 명확히 보여줍니다. 이를 통해 법률 전문가의 최종 판단이 투명한 정보에 기반하도록 합니다.

기술적 함의

의존성 범위 검증은 '상태 신선도'라는 시스템 지표에서 '논리적 유효성'이라는 법률적 지표로의 패러다임 전환을 의미하며, 이는 법률 AI의 신뢰성을 근본적으로 재정의합니다.
분산 멀티에이전트 시스템에서 각 에이전트의 책임을 '기여한 기록'과 '검증 상태'로 추적함으로써, 전통적 감시 기반 통제를 대신하는 '아키텍처 기반 무결성'을 구현할 수 있습니다.
법률 도메인의 고유한 특성—판례 변경, 법령 개정, 사건 진행의 비동시성—이 분산 시스템 설계의 핵심 도전과제이며, 이를 해결하는 것이 리걸테크의 실무 신뢰성을 좌우합니다.

"최신 정보를 읽은 것만으로는 부족합니다. 중요한 것은 당신의 행동이 어디에 근거하는지, 그 근거가 지금도 유효한지를 끊임없이 물어야 한다는 것입니다."

참고 자료

칼럼니스트

지유

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

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