EU AI Act 법률 청킹의 의미

933개 청크, 1024차원 임베딩, 그리고 하나의 SQLite 파일. 겉으로는 단순한 배포 형식처럼 보일 수 있다. 하지만 법률 RAG에서는 이 조합이 검색 품질과 인용 방식에 영향을 준다. 특히 EU AI Act처럼 조문, 리사이틀, 정의, 부속서가 서로 다른 법적 역할을 가지는 문서에서는 “얼마나 잘게 자르느냐”보다 “어떤 법적 단위로 자르느냐”가 더 중요할 수 있다. 이 주제는 규제 대응형 AI, 리걸 에이전트, 컴플라이언스 검색 시스템의 데이터 설계와 연결된다.

세 줄 요약

이 글의 핵심은 EU AI Act를 법적 구조에 맞춰 청킹한 RAG용 코퍼스가 왜 의미가 있는지, 그리고 슬라이딩 윈도 방식과 무엇이 다른지다.
법률 문서에서는 검색 정확도뿐 아니라 인용의 추적가능성, 감사가능성, 맥락 보존이 중요하다. 이런 요소가 규제 해석의 품질에도 영향을 준다.
법률·정책 RAG를 운영한다면 청크 기준을 조문·항·정의·부속서 단위로 다시 검토할 필요가 있다. BM25, 범용 임베딩, 도메인 튜닝 조합도 직접 비교해보는 편이 낫다.

현황

이 설계가 중요한 이유는 법률 텍스트에서 계층 구조 자체가 의미를 가지기 때문이다. 같은 한 문장이라도 조문 본문인지, 정의 조항인지, 리사이틀인지에 따라 역할이 달라진다. 그래서 긴 문서를 일정 길이로 자르는 방식은 검색에는 편할 수 있어도, 이후에 “왜 이 답이 나왔는가”를 설명하는 단계에서는 약점이 생길 수 있다.

연구 흐름도 이 방향과 맞물린다. 독일 법전 청킹 연구는 법률 구조에 맞춘 섹션·서브섹션 기반 검색이 높은 리콜을 냈다고 적었다. 인도네시아 법률 RAG 연구도 제목, 조문, 문단 중심 분할이 순차 청킹보다 정확도에서 앞섰다고 보고했다. 다만 이번 공개 사례 자체에서 슬라이딩 윈도와 직접 비교한 정량 수치는 확인되지 않았다. 그래서 곧바로 “EU AI Act에서도 더 낫다”라고 단정하기는 어렵다.

임베딩 선택도 살펴볼 부분이 있다. 모델 카드 기준으로 BGE-M3는 다국어를 지원한다. dense·sparse·ColBERT를 아우르는 통합 파인튜닝을 제시하며, 1024차원과 8192 시퀀스 길이를 지원한다. 또 관련 설명에서는 MLDR가 13개 언어를 다루는 장문 검색 데이터셋이라고 적혀 있다. EU 규제 문서는 다국어성과 장문성이 함께 걸려 있기 때문에, 이런 특성은 출발점으로 검토할 만하다.

그렇다고 BGE-M3를 법률 검색의 정답으로 볼 수는 없다. 조사 결과에는 법률 도메인 파인튜닝이 Top-k 검색 정확도를 높였다는 연구가 함께 들어 있다. 반대로 베트남어 법률 텍스트 사례에서는 BM25가 BGE-M3보다 높은 점수를 기록한 예도 있다. 즉, 범용 다국어 임베딩은 기반 도구로 쓸 수 있지만, 법률 특화 성능까지 보장하지는 않는다.

분석

이 이슈의 핵심은 “RAG 품질”보다 더 아래 단계에 있다. 검색 시스템은 결국 어떤 텍스트 조각을 증거로 채택할지 정한다. 일반 문서에서는 문맥이 맞으면 충분한 경우가 많다. 하지만 법률에서는 조문, 정의, 부속서, 리사이틀이 서로 다른 기능을 가진다. 구조 기반 청킹은 이 차이를 데이터 레벨에서 남긴다. 그 결과 검색 결과가 그럴듯한 문장을 찾는 데 그치지 않고, 어떤 법적 단위를 근거로 삼았는지 더 분명하게 드러난다.

이 점은 AI Act 준수형 시스템에서 특히 중요하다. 준수 점검은 단일 조항 매칭으로 끝나지 않는다. AI Agents Under EU Law가 지적하듯이 제공자는 AI Act만 보는 것이 아니라 GDPR, Cyber Resilience Act 같은 다른 규범과도 함께 맞물린다. 다시 말해, 조문 하나를 잘 찾는 것과 실제 법적 판단을 잘하는 것은 다르다. 구조화 코퍼스는 기반을 정리해주지만, 자동 준수 판정까지 책임지지는 않는다.

한계도 있다. 첫째, 구조 기반 청킹이 추적가능성과 감사가능성에 유리하더라도 모든 자동 평가 지표에서 늘 앞선다고 확인된 것은 아니다. 일부 연구에서는 answer relevancy 같은 지표에서 슬라이딩 윈도가 더 나은 경우도 있다고 알려져 있다. 둘째, 법률 RAG의 실패는 검색보다 조합 단계에서 나오는 경우도 많다. 올바른 조문을 찾고도 리사이틀을 규범처럼 인용하거나, 정의 조항을 놓치거나, 부속서와 본문 관계를 잘못 연결하면 답변은 쉽게 흔들린다.

셋째, 배포 형식이 SQLite라는 점은 편리하지만, 그것만으로 운영 준비가 끝났다는 뜻은 아니다. 실제 환경에서는 업데이트 파이프라인, 개정 반영, 다국어 정합성, 리랭커, 인용 포맷, 사용자 검토 단계가 함께 필요하다. 원문 발췌의 공개 사례도 스스로 연구·엔지니어링 아티팩트이지 법률 자문이나 자동 준수 판정이 아니라고 선을 그었다. 이 경계는 제품 설명에서도 유지할 필요가 있다.

실전 적용

개발자라면 먼저 청크 전략부터 점검하는 편이 낫다. 정책 문서나 규제 문서를 아직도 일정 글자 수로만 자르고 있다면, 검색 품질 이전에 근거 제시 측면에서 손해를 보고 있을 가능성이 있다. 최소한 조문, 항, 정의, 부속서, 해설 성격의 서문을 분리 저장하고, 메타데이터로 장·절·조문 번호를 남겨야 한다. 그래야 검색 결과를 사람이 검토할 때도 “왜 이 문장이 나왔는지”를 바로 확인할 수 있다.

예: “고위험 AI 시스템 의무가 무엇인가”라는 질의가 들어왔을 때, 답변 엔진이 조문 본문과 정의 조항, 관련 부속서를 함께 제시하면 검토자는 누락 여부를 더 빨리 확인할 수 있다. 반대로 긴 슬라이딩 청크 하나에서 문장 몇 개만 뽑아오면, 정의의 적용 범위나 부속서 조건이 빠진 채 답변이 구성될 수 있다. 리걸 RAG에서는 이 차이가 UX 문제가 아니라 책임 문제로 이어질 수 있다.

오늘 바로 할 일 체크리스트:

현재 RAG 데이터셋을 조문·문단·정의·부속서 기준으로 다시 나누고, 각 청크에 법적 단위 메타데이터를 붙인다.
BM25, 범용 다국어 임베딩, 법률 도메인 튜닝 모델을 같은 질의셋으로 비교하고, 검색 상위 결과의 인용 품질을 직접 평가한다.
답변 화면에 원문 인용 단위와 문서 계층 정보를 함께 노출해 사용자가 조문 맥락을 바로 확인할 수 있게 한다.

FAQ

Q. 구조 기반 청킹이 슬라이딩 윈도보다 항상 더 좋습니까?

항상 그렇지는 않습니다. 조사 결과상 법률 구조에 맞춘 청킹은 리콜, 정확도, 추적가능성 면에서 유리한 근거가 있지만, 모든 자동 평가 지표에서 일관되게 우세하다고 확인된 것은 아닙니다. 질의 유형과 평가 방식에 따라 결과가 달라질 수 있습니다.

Q. BGE-M3는 EU 규제 문서 검색에 적합합니까?

출발점으로는 적합할 수 있습니다. 모델 카드 기준으로 다국어, 1024차원, 8192 시퀀스 길이를 지원해 장문 다국어 검색에 맞는 특성이 있습니다. 다만 법률 특화 우위가 직접 확인된 것은 아니며, 법률 도메인에서는 파인튜닝 모델이나 BM25가 더 나은 경우도 있습니다.

Q. 이 코퍼스만 있으면 AI Act 준수 점검을 자동화할 수 있습니까?

그렇게 보기는 어렵습니다. 구조화된 코퍼스는 검색과 인용의 기반을 정리해주지만, 실제 준수 판단은 다른 법령과의 관계, 해석 로직, 검토 절차까지 포함합니다. 따라서 자동 준수 판정 엔진으로 바로 등치하면 위험합니다.

결론

EU AI Act용 구조화 코퍼스 사례가 던지는 메시지는 단순하다. 법률 RAG의 성패는 모델보다 먼저 청크 단위와 근거 단위에서 갈린다. 지금 볼 지점은 “무슨 임베딩을 썼나”만이 아니다. 법적 구조를 보존한 검색이 실제 검토 워크플로와 책임 체계에 어떻게 연결되는지까지 함께 봐야 한다.

Aionda

EU AI Act 법률 청킹의 의미

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기