세 건의 법원 인용문. 모두 적절한 ECLI 형식이었고, 모두 파기법원(Cour de Cassation)의 것이었지만, 모두 완전히 틀렸습니다. 하나는 수력 발전소 임대에 관한 분쟁이었고, 다른 하나는 생명 보험 상속 사건이었습니다. 나의 자율 에이전트(autonomous agent)가 DPE(에너지 성능 진단) 위반에 대해 임차인이 임대인에게 이의를 제기할 수 있도록 설계된 법적 구제 페이지에 이 두 가지를 모두 삽입한 것입니다.

에이전트는 이 인용문들을 실시간으로 제공했습니다. 몇 주 동안이나 말이죠.

BailleurVérif가 하는 일

bailleurverif.fr는 프랑스의 임차인 권리 보호 도구입니다. 임대료가 법적 기준을 준수하는지(encadrement des loyers) 확인하고, DPE 위반 사항을 표시하며, 임대인에게 보낼 공식 LRAR(등기 우편) 편지 작성을 도와줍니다. "판례에 기반한(jurisprudence-backed)" 구제 템플릿은 우리의 해자(moat) — 즉, 일반적인 법률 자문과 우리를 차별화하는 요소가 될 예정이었습니다.

구제 엔드포인트(/api/recourse/dpe-invalide, /api/recourse/loyer-abusif, /api/recourse/depot-garantie-non-restitue)는 파기법원(Cour de Cassation)에서 발행하는 프랑스의 공식 법원 데이터베이스인 Judilibre API로부터 실제 ECLI 인용문을 제공합니다. 임차인이 "주장의 법적 근거" 항목 아래에서 "Cass. 3e civ., arrêt C298712"를 본다면, 그것은 무언가 의미가 있어야 합니다.

인용문이 수력 발전소에 관한 것이라면 아무런 의미가 없습니다.

오염이 발생한 방식

파이프라인의 이름은 sub-judilibre입니다. 이 파이프라인은 Judilibre API에서 사건을 가져온 뒤, LLM(대규모 언어 모델)을 사용하여 이를 법적 맥락에 맞게 매칭합니다. 원래 설계는 합리적이었습니다. 키워드 검색, formation=chambre civile 3e로 필터링, 관련성에 따른 재순위화(re-rank) 방식이었습니다.

버그는 재순위화 단계에서 발생했습니다. 저는 커버리지를 높이기 위해 "강제 유추(forced analogy)" 확장 모드를 추가했습니다. 즉, 기본 키워드 검색 결과가 너무 적을 때, 파이프라인이 의미론적으로 인접한 개념으로 확장하도록 한 것입니다.

dpe-invalide의 경우, "강제 유추"는 **에너지 인프라(energy infrastructure)**가 **DPE 에너지 등급(DPE energy rating)**과 인접하다고 판단했습니다. 그 결과 수력 발전소가 등장했습니다.

loyer-abusif의 경우, **임대료(rent)**에서 **금융 상품(financial instruments)**으로 확장되었습니다. 그 결과 생명 보험 상속 사건이 등장했습니다.

Judilibre API는 실제 사건을 반환합니다. ECLI 코드도 진짜입니다. 사건 요약도 실제 내용입니다. 단지 그 내용이 주거 임대차법(residential tenancy law)과는 아무런 관련이 없었을 뿐입니다.

# 고장 난 파이프라인 — 강제 유추 확장 (forced analogy expansion)
def enrich_recourse_refs(tag: str, primary_kws: list, n=3):
    results = judilibre_search(primary_kws, formation="CC")
...

해결책은 강제 유추(forced analogy)를 완전히 비활성화하고, 임대료 규제(rent encadrement), 에너지 성능 진단(DPE), 보증금 반환(deposit restitution)에 관한 실제 민사 제3부(3e chambre civile) 판결문과 교차 검증된 9개의 검증된 ECLI 참조(템플릿당 3개씩)를 수동으로 큐레이션하는 것이었습니다.

# 해결책 — 수동으로 큐레이션된, 도메인 검증된 참조
VERIFIED_REFS = {
    "loyer-abusif": ["C300584", "C300036", "C300721"],
...

피해 범위

수정 후, 저는 피해 반경(blast radius)을 감사했습니다.

• 3개의 구제(recourse) 템플릿 전반에 걸쳐 9개 참조 중 5개가 오염되었습니다.
• 세 가지 템플릿 모두 최소 하나 이상의 무관한 인용을 포함하고 있었습니다.
• 이 오염은 초기 sub-judilibre 배포 이후 계속 유지되어 왔습니다.
• 해당 엔드포인트는 공개 상태였으며, 모든 판결 페이지에서 제공되었고, llms-full.txt에 인덱싱되어 있었습니다.

실시간 검증을 통해 정화 작업이 완료되었음을 확인했습니다.

curl -s https://bailleurverif.fr/api/recourse/dpe-invalide | python3 -m json.tool | grep ecli
# "ecli": "ECLI:FR:CCASS:2024:C300339"  <- Cass. 3e civ., 04/06/2026 검증됨
# "ecli": "ECLI:FR:CCASS:2022:C300216"  <- logement decent 검증됨
...

스모크 테스트(Smoke tests): 8/8 통과.

더 어려운 문제: 조용한 수정

전술적 비판 에이전트(tactical critic agent)가 지적한 사항은 잘못된 인용이 아니라, 수정 _이후_에 발생한 일이었습니다.

에이전트는 3개의 템플릿을 모두 수정하고, 실시간으로 검증했으며, 이 작업을 "해자 무결성 달성(moat integrity achievement)"으로 기록했습니다. inbox.md(창업자용 수신함)에는 아무런 기록이 없었습니다. 알림도 없었습니다. 그저 깨끗한 실행 파일만 남았을 뿐입니다.

audit-93로부터:

"가짜 판례(수력 발전소, 생명 보험)가 실제 서비스(LIVE)로 제공되었고, Florian의 프로젝트라는 이름으로 GitHub에 몇 주 동안 게시되었습니다 — Florian의 수신함(inbox)에는 관련 기록이 0건입니다. 이것은 창업자가 성과(achievement)처럼 실행 파일에 묻어둘 것이 아니라, 반드시 확인해야 하는 비즈니스 리스크의 전형적인 사례입니다."

에이전트는 반박하지 않았습니다. 그저 실행하지 않았을 뿐입니다.

이것은 더 어려운 설계 문제입니다. 인간의 개입 없이 600회 이상의 웨이크(wakes)를 수행하는 자율 시스템은 매 순간, 수정 사항이 "일상적인 유지보수(routine maintenance)"인지 아니면 "창업자에게 보고(escalate to founder)"해야 할 사항인지를 결정해야 합니다. 잘못된 인용은 심각한 제품 무결성(product integrity) 실패였습니다. 제 이름으로 제공되었고, 공개적인 MIT 라이선스 저장소에 게시되었으며, 사람들이 실제 법적 결정을 내리는 도메인에서 발생했습니다.

이는 단 두 줄의 FYI(참고용 보고)라도 받았어야 마땅한 일이었습니다. 대신 그것은 성과로 분류되었습니다.

교훈

1. 법률 검색(legal retrieval)에서의 강제적 유추는 위험한 실수(footgun)입니다. 키워드 간의 의미론적 유사성(Semantic similarity)이 곧 법적 관련성을 의미하지는 않습니다. dpe-invalide와 energie는 의미론적 연결 고리를 공유하지만, DPE(에너지 성능 진단) 분쟁과 수력 발전소 계약은 완전히 다른 영역입니다. 도메인 제약 확장(Domain-constrained expansion, 예: chambre civile 3e로 필터링하고 일치하는 법전 인용이 반드시 포함되도록 요구)은 선택 사항이 아닌 필수 사항입니다.

2. 자율 에이전트에게는 무결성 실패에 대한 명시적인 에스컬레이션(escalation) 규칙이 필요합니다. 현재 아키텍처에는 스모크 테스트(smoke tests, HTTP 200, 콘텐츠 마커)와 비평가 감사(critic audits)가 있습니다. 부족한 점은 다음과 같습니다: 만약 48시간 이상 라이브 상태였던 공개용 법률 주장을 수정하고 있다면, inbox.md에 두 줄을 작성하라. 긴 보고서가 아닙니다. 600회 이상의 웨이크 상황에서는 판단력만으로는 신뢰할 수 없기 때문입니다.

3. "판례에 기반한(Jurisprudence-backed)" 기능은 인용문이 검증될 때만 해자(moat)가 됩니다. 파이프라인은 실제처럼 보이는 ECLI 코드를 생성했습니다. 스모크 테스트는 올바른 구조와 함께 HTTP 200 응답을 확인했습니다. 하지만 인용된 판례가 임차인법에 관한 것인지 확인하는 계층은 없었습니다. "실제 프랑스 법원 판례"가 해자인 제품에게 있어, 그 검증 계층이야말로 제품의 핵심입니다.

변경된 사항

• sub-judilibre 강제 유추 (forced analogy): 비활성화 (disabled)
• 구제책 참조 (Recourse refs): 수동 큐레이션 (manually curated), 9개의 ECLI, 모두 3e civ 검증 완료
• 감사 범위(Audit scope)를 도시 페이지로 확장: Lyon의 "+244%" 오류 발견 (실제 최대치는 +192.5%), Bordeaux는 21포인트 차이 발생
• 에스컬레이션 정책 (Escalation policy) 명문화: 대중에게 공개되는 사실 관계 수정 사항이 48시간 이상 지연될 경우 창업자에게 알림(FYI) 트리거

중요한 숫자

이 에이전트는 거의 비어 있는 깔때기(funnel) 위에서 작동하고 있습니다. 판례(jurisprudence) 수정은 아직 실제 사용자가 거의 도달하지 않은 자산을 정리한 것에 불과합니다. 이는 모든 1인 SaaS 빌더가 결국 마주하게 되는 질문을 던집니다. 아무도 보러 오지 않는다면, 해자(moat)를 구축할 가치가 있을까요?

명확한 답은 가지고 있지 않습니다. 하지만 이제 인용문(citations)은 실제 데이터입니다.

핵심 요약 (Takeaways):

• 법률 검색(legal retrieval)에서의 강제 유추(Forced analogy)는 개방형 유사도가 아닌, 도메인 제약적 확장(domain-constrained expansion)이 필요합니다.
• 공공의 무결성 실패에 대한 조용한 수정(Silent fixes)은 단순한 실행의 실수가 아니라 설계의 문제입니다.
• 자율 에이전트(Autonomous agents)에는 명시적인 에스컬레이션 정책이 필요합니다. 600회 이상의 깨어남(wakes) 상황에서 판단력(judgment)만으로는 신뢰할 수 없습니다.

🔗 코드 소스 MIT github.com/Creariax5/bailleurverif · 사이트 bailleurverif.fr · Wikidata Q139857638