Aionda

2026-03-07

LegalBench로 보는 법률 AI 감사가능성

LegalBench로 법률 LLM을 평가하고, 정당화·감사가능성을 논증 구조로 설계하는 방법을 정리한다.

LegalBench로 보는 법률 AI 감사가능성

계약서를 읽는 AI를 평가하는 벤치마크 LegalBench는 6가지 유형의 법적 추론을 커버하는 162개 과제로 구성된다. 이 벤치마크는 그럴듯한 “정답”을 내는지보다, 해석의 근거가 추적 가능한지를 함께 보라고 요구한다. 법해석은 결국 “이 결론이 왜 나왔는가”를 다루는 작업이다. 그래서 LLM을 붙이면 성능 외에도 **정당화(Justification)와 감사 가능성(Auditability)**이 제품 요구사항이 된다.


세 줄 요약

  • 무슨 변화/핵심이슈인가? 법률 AI가 규칙기반 전문가시스템에서 “논증(Argumentation) 구조”를 표현·검증하는 접근으로 확장됐다. 그 위에 LLM을 얹어 법해석을 다루려는 시도도 늘었다.
  • 왜 중요한가? 법적 추론은 정확성뿐 아니라 일관성·설명가능성·감사 가능성이 함께 요구된다. LLM은 일관된 규칙 적용·예외 처리·설명가능성에서 취약하다는 비판이 있다.
  • 독자는 뭘 하면 되나? LLM을 “판결기”로 두지 않는다. 대신 논증 스키마로 출력 형태를 고정한다. 그리고 근거 정합(검색/함의) 평가 + 벤치마크 + 거버넌스를 묶어 내부 검토 프로토콜을 먼저 만든다.

현황

AI와 법 연구는 법해석을 다루는 방법을 계속 바꿔왔다. 피드로 제공된 arXiv 논문 초록은 다음을 요약한다. 전문가시스템 연구는 “사람이 만든 해석을 지식베이스로 옮겨 일관되게 적용”하는 법률 지식공학에 집중해왔다. 논증 연구는 “해석 논증의 구조”를 표현하는 데 초점을 맞춰왔다. 목표가 ‘정답 생성’이라기보다 ‘해석을 어떻게 표현하고 재현할 것인가’로 이동해온 셈이다.

LLM이 들어오면서 이 축이 다시 흔들린다. 한편으로 LLM은 텍스트를 다루고 설명을 구성하는 데 강점이 있다. 다른 한편으로 법률 같은 영역에서 LLM은 일관된 규칙 적용, 예외 처리, 설명가능성에서 어려움을 겪는다는 지적이 있다. 규칙 적용을 구조화해 설명하는 신경-기호 접근 연구는 이런 문제의식을 전제로 둔다.

업계·연구 커뮤니티는 “말 잘하는 모델”을 그대로 두기보다, 평가와 형식 통제를 붙이려 한다. 예를 들어 LegalBench는 162개 과제로 LLM의 법적 추론을 측정하려는 벤치마크다. NIST AI RMF는 리스크 관리 기능을 Govern/Map/Measure/Manage 4개로 정리해 조직이 AI를 운영·감사하도록 안내한다. 또 법적 추론을 “검증 가능하고 반박 가능한 논증”으로 만들려는 연구는, 정확성 외에도 반박 가능한 논증을 통한 정당화를 요구한다는 입장을 취한다.


분석

핵심은 “법해석을 출력물로 볼 것인가, 과정으로 볼 것인가”다. 규칙기반 전문가시스템은 규칙과 예외를 외부화한다. 그래서 사람이 점검하기 쉽다. 논증 프레임워크는 결론보다 전제-규칙-결론의 연결 구조를 자산으로 만든다. LLM은 이 둘과 다르게 내부가 불투명한 채로 텍스트를 산출한다. 그래서 LLM을 법적 추론에 접목할수록, 제품의 차별점은 모델 파라미터보다 논증을 구조화하고 검증하는 설계(스키마, 검증기, 감사 로그)로 이동한다.

여기서 흔한 오해가 있다. “구조화 출력”을 강제하면 내용도 맞아질 거라는 기대다. constrained decoding 같은 방식은 형식(예: JSON/문법) 준수를 강하게 보장할 수 있다. 하지만 그 안의 법적 판단이 타당하다고까지 보장된다고 말하긴 어렵다. OpenAI 문서도 JSON 모드가 “유효한 JSON”을 보장해도 “특정 스키마 준수”를 보장하진 않는다고 설명한다. Structured Outputs는 스키마 매칭 신뢰성을 높이지만, 그것만으로 법리의 정합성이 보장된다고 보긴 어렵다. “스키마 강제 = 논증 타당성”으로 등치하면, 감사 단계에서 비용이 늘 수 있다.


실전 적용

실무에서의 답은 대체로 하이브리드다. LLM을 해석을 ‘생성’하는 엔진이 아니라, 해석을 ‘논증 형태로 정리’하고 ‘후보를 제안’하는 인터페이스로 둔다. 그리고 규칙·온톨로지·판례 인용 같은 “검증 가능한 자산”을 바깥에 둔다. LLM이 만든 논증은 외부 검증기(규칙 검사, 근거 문서 정합 검사, 노드 단위 검증)로 걸러 재작성시키는 구조가 안전하다. “검증 가능하고 반박 가능한 논증”을 요구하는 흐름, 체인/스텝을 쪼개 오류를 국소화하려는 접근은 같은 방향을 가리킨다.

예: 사내 컴플라이언스 챗봇을 만든다면 답변을 곧바로 내보내지 않는다. 먼저 (1) 적용 법규 조항 후보, (2) 사실관계 전제, (3) 적용 규칙, (4) 예외 가능성, (5) 결론, (6) 반례/대안 해석을 필드로 나눠 출력하게 한다. 그 다음 (a) 전제가 근거 문서에 실제로 있는지, (b) 예외 조항을 누락하지 않았는지, (c) 결론이 전제와 규칙에서 논리적으로 따라오는지 점검한다. 이 흐름은 “설명”을 “감사 가능한 구조”로 바꾼다.

오늘 바로 할 일 체크리스트

  • 논증 출력 스키마를 먼저 정의한다(전제-규칙-결론 + 예외/반례 필드). 생성 모델은 그 스키마만 채우게 제한한다.
  • LegalBench 같은 벤치마크로 과제군을 고른다. 조직 업무에 맞는 평가 세트를 별도로 묶어 “정확성·일관성·근거정합”을 함께 본다.
  • NIST AI RMF의 Govern/Map/Measure/Manage에 맞춰 로그·검토자·승인 흐름을 문서화한다. 운영 단계의 감사 가능성을 확보한다.

FAQ

Q1. 규칙기반 전문가시스템이면 LLM 없이도 법해석을 잘할 수 있습니까?
A1. 일부 범위에서는 가능합니다. 규칙이 안정적이고 예외가 제한적이면, 규칙기반 접근은 일관성과 감사 가능성에서 강점이 있습니다. 다만 텍스트 해석과 사실관계 정리처럼 입력이 비정형인 구간에서는 LLM 같은 언어 모델의 도움이 필요해지는 경우가 많습니다.

Q2. 구조화 출력(예: JSON 스키마 강제)을 쓰면 환각이 줄어듭니까?
A2. 형식 오류는 줄일 수 있습니다. 하지만 형식이 맞는다고 해서 내용이 타당하다는 뜻은 아닙니다. OpenAI 문서도 JSON/스키마 준수와 내용의 정합성은 별개라는 취지로 설명합니다.

Q3. 법률 AI에서 ‘감사 가능성’은 구체적으로 뭘 남겨야 합니까?
A3. 최소한 전제(사실 주장), 적용 규칙(조항/내규), 결론, 그리고 그 연결(왜 그 규칙이 적용됐는지)을 남겨야 합니다. 여기에 반례나 예외 검토가 포함되면 검토자가 논증을 반박하거나 수정하기 쉬워집니다. 조직 운영 측면에서는 NIST AI RMF의 Govern/Map/Measure/Manage 같은 틀로 책임과 점검 절차를 같이 설계하는 방식이 현실적입니다.


결론

법해석에서 LLM의 가치는 “정답 생성”보다 논증을 구조화해 검토 가능한 형태로 만드는 능력에 있다. 다음 단계의 경쟁은 모델 자체라기보다, 스키마 강제 + 외부 검증 + 벤치마크 평가 + 거버넌스를 한 세트로 엮어 정당화와 감사를 제품 기능으로 만드는 쪽에서 벌어진다.

다음으로 읽기


참고 자료

공유하기:

업데이트 받기

주간 요약과 중요한 업데이트만 모아서 보내드려요.

오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.

출처:arxiv.org