카테고리 없음

PM을 위한 AI 실무 사전 7편 — 청킹, 바이너리 파싱, diff 알고리즘

makewithai 2026. 8. 8. 17:03

누구나법률 7장(기업형 계약 분석 엔진 만들기)에서 나온 개념: 텍스트 청킹, 바이너리 파일 파싱, diff(비교) 알고리즘, 규칙 기반 판정.

청킹(Chunking) — LLM에게 긴 문서를 나눠서 주는 기술

모든 LLM은 한 번에 처리할 수 있는 텍스트 양(컨텍스트 길이)에 한계가 있다. 문서가 그 한계보다 길면, 통째로 넣을 수 없다. 청킹은 긴 문서를 의미 있는 단위로 쪼개서, 나눠서 처리한 뒤 결과를 다시 합치는 기법이다.

여기서 실무적으로 중요한 건 "어디서 자르는가"다. 그냥 글자 수로 뚝뚝 자르면, 문장이나 조항 중간이 잘려서 문맥이 끊긴다. 그러면 LLM이 잘린 조각만 보고 엉뚱하게 판단할 수 있다. 그래서 이 프로젝트에서는 계약서의 자연스러운 구조 단위(제N조)를 기준으로 잘랐다. 문서 종류에 따라 "자연스러운 경계"는 다르다 — 코드라면 함수 단위, 회의록이라면 화자 발언 단위처럼, 문서의 구조를 이해하고 그 구조를 따라 잘라야 한다.

또 하나 중요한 지점 — 나눠서 분석하면 "전체를 봐야만 알 수 있는 것"을 놓치기 쉽다. 이 프로젝트에서는 "이 계약 유형에 필수인데 빠진 조항"이 정확히 그런 경우였다. 조각 하나만 보면 판단할 수 없는 질문은, 모든 조각을 합친 뒤 별도 단계에서 처리하도록 순서를 분리해야 한다.

바이너리 파일 파싱 — 사람이 읽는 파일과 컴퓨터가 저장하는 방식은 다르다

워드나 한글 같은 문서 프로그램은 텍스트를 그냥 문자로 저장하지 않는다. 서식, 이미지, 표 같은 정보까지 같이 담아야 하니, 자체적인 내부 구조(포맷)를 쓴다. 이 구조를 열어서 원하는 정보(순수 텍스트)만 뽑아내는 게 "파싱"이다.

포맷은 크게 두 갈래로 나뉜다.

  • 개방형 표준 포맷(예: HWPX, DOCX) — 실제로는 ZIP 압축 파일 안에 XML이 들어있는 구조다. 압축을 풀고 XML을 읽으면 되니, 별도 라이브러리 없이도 표준 도구로 다룰 수 있다.
  • 독점 바이너리 포맷(예: 옛 HWP, 옛 DOC) — 그 프로그램 회사가 정한 고유한 바이트 구조를 그대로 써야 한다. 스펙 문서를 찾아 레코드 구조를 이해하고, 압축이 걸려있으면 그 압축 방식까지 알아야 읽을 수 있다. 훨씬 손이 많이 간다.

실무 판단: 처음 보는 파일 포맷을 지원해야 한다면, 그 포맷이 "실제로는 ZIP+XML"인지부터 확인하는 게 좋다. 요즘 나온 포맷은 대부분 이 구조를 따르기 때문에, 생각보다 쉽게 풀릴 때가 많다.

Diff 알고리즘 — 두 버전이 어떻게 다른지 자동으로 찾기

두 텍스트를 비교해서 "뭐가 삭제되고 뭐가 추가됐는지"를 찾는 걸 diff라고 한다. 코드 버전 관리(git)에서 흔히 보는 그 빨간줄/초록줄이 diff의 결과물이다.

diff를 만들려면 먼저 "어느 부분과 어느 부분이 같은 것의 다른 버전인지" 매칭부터 해야 한다. 문서가 완전히 똑같은 순서로 안 바뀌었을 수도 있으니(조항이 추가되거나 순서가 바뀌면), 단순히 줄 번호로 비교하면 안 된다. 이 프로젝트에서는 조항번호 → 제목 유사도 → 본문 유사도 순서로 단계적으로 매칭했다 — 가장 확실한 기준부터 시도하고, 안 되면 점점 느슨한 기준으로 넘어가는 방식이다.

매칭이 끝나면, 매칭된 쌍끼리만 단어 단위로 세부 비교를 한다. 이때 "무엇이 바뀌었나"뿐 아니라 "그 변화가 우리에게 유리한가 불리한가"까지 자동으로 판정하게 만들면, 단순 비교 도구를 넘어 실제 의사결정에 쓸 수 있는 도구가 된다.

diff 매칭 3단계, 조항번호로 먼저 매칭 시도 후 실패하면 제목 유사도, 그마저 실패하면 본문 유사도로 단계적 매칭

규칙 기반 판정 — "일반적으로 위험한가"와 "우리 기준에 맞는가"는 다른 질문

AI가 계약서를 보고 "위험하다/안전하다"를 판단하는 건 일반적인 법적 기준에 기반한다. 하지만 실제 기업은 각자 다른 내부 기준(예: "손해배상 한도는 반드시 계약금액 100% 이상이어야 한다")을 갖고 있다. 이건 AI가 스스로 알 수 없는 정보다 — 회사마다 다른 규칙을 명시적으로 등록해두고, 계약서를 그 규칙과 하나씩 대조하는 방식이 필요하다.

이런 구조를 설계할 때 핵심은 규칙에 "중요도"를 매겨두는 것이다. 모든 위반을 동일하게 취급하면, 진짜 치명적인 위반(반드시 협상해야 하는 것)이 사소한 위반들 사이에 묻힌다. 이 프로젝트에서는 규칙마다 critical/important/optional 등급을 매기고, critical 위반만 따로 "반드시 협상 필요" 목록으로 분리했다.

누구나법률 시리즈는 다음 편(지금, 그리고 앞으로 — 로드맵)이 에필로그로 마무리된다. 에필로그에 새로 정리할 기술 개념이 나오면 이 실무 사전 시리즈도 이어가고, 없으면 이 편이 마지막이 된다.