투자계약서에서 손해배상 한도나 위약벌 이율 같은 조건을 뽑아내 계산에 쓰려고 하면, 대개 이 질문부터 나옵니다. “PDF 파싱을 해야 하나?”
그대로는 답할 수 없는 질문입니다. ’파싱’이라는 한 단어가 성격이 정반대인 작업 네 가지를 덮고 있기 때문입니다.
파싱이라 불리는 네 가지
① 바이트 → 텍스트. 파일 형식에서 글자를 꺼내는 일입니다. 워드(.docx)나 한글(.hwpx)은 압축파일 안의 XML이라 글자가 그대로 나옵니다. 텍스트 레이어가 있는 PDF는 글자마다 좌표만 있어서, 사람이 읽는 순서로 되짜는 과정에서 줄바꿈과 표가 무너집니다.
② 픽셀 → 텍스트. 스캔본에만 필요합니다. OCR이든 요즘의 비전 AI든, 원문에 없던 글자를 만들어 낼 수 있습니다.
③ 텍스트 → 조건. “제7조 제2항의 ’투자금의 100분의 30’이 손해배상 한도다”를 알아내는 일입니다. 문서 자동화에서 진짜 어려운 곳은 여기입니다.
④ 표 → 값. 엑셀처럼 이미 행과 열이 정해진 것에서 값을 꺼내는 일입니다. 같은 파일은 언제나 같은 결과를 냅니다.
넷을 가르는 선은 쉽다·어렵다가 아닙니다. 시끄럽게 실패하느냐, 조용히 틀리느냐입니다.
①과 ④는 틀리면 프로그램이 멈춥니다. 파일 형식이 어긋났다, 그런 열이 없다 — 사람이 바로 알아챕니다. ②와 ③은 틀려도 아무 일이 일어나지 않습니다. 그럴듯한 숫자가 조용히 들어앉습니다.
그러니 실제로 정해야 할 것은 파싱의 유무가 아닙니다. 조용히 틀리는 단계가 계산에 쓰이는 확정값에 닿게 둘 것인가입니다.
재무제표에는 그물이 있습니다
스캔한 재무제표를 AI로 읽히는 것은 이미 널리 쓰입니다. 그게 성립하는 이유는 판독이 정확해서가 아니라, 재무제표에 자체 검산식이 있기 때문입니다.
자산은 부채와 자본의 합과 같아야 하고, 소계를 더하면 총계가 나와야 합니다. 판독이 틀리면 이 등식이 깨지고 프로그램이 그 자리에서 걸러냅니다. 확률적인 도구를 쓰면서도 안전할 수 있는 것은 이 그물 덕분입니다.
계약 조건에는 그 그물이 없습니다.
- “손해배상액은 투자원금의 100분의 30“을 100분의 80으로 읽어도, 깨지는 등식이 하나도 없습니다.
- “연 8%“가 “연 3%“가 되어도 어떤 합계도 어긋나지 않습니다. 위약벌 예상액만 조용히 틀립니다.
- 부정문이 뒤집힙니다. “…하지 아니한다“에서 줄바꿈에 걸린 ’아니한다’가 탈락하면 의미가 정확히 반대가 되고, 문장은 여전히 자연스럽습니다.
- 별지의 표는 좌표를 되짜는 과정에서 셀 경계가 무너져 값이 옆 행에 붙습니다.
틀린 티가 나지 않는 오답은 검토하는 사람도 의심하지 않습니다. 이것이 계약서 판독이 재무제표 판독보다 위험한 이유입니다.
다만 그물이 아주 없지는 않습니다. 계약의 숫자 중 일부는 서로를 검산합니다. 투자금 ÷ 발행가 = 발행주식수, 발행주식수 ÷ 총발행주식수 = 지분율. 셋 중 둘이 있으면 나머지를 확인할 수 있습니다. 손해배상 한도나 이율에는 쓸 수 없지만, 자릿수를 잘못 옮긴 사고는 여기서 대부분 걸립니다.
문서 형태별로 나눠 보면
| 원본 | ① 디코딩 | ② 판독 | ③ 구조화 | 판정 |
|---|---|---|---|---|
| 정리한 엑셀 | — | — | 사람이 완료 | 파싱 없음 |
| 붙여넣은 텍스트 | 사람이 대신 | — | 확률적 | ③만 남음 |
| 워드 · 한글(hwpx) | 자명 | — | 확률적 | ③만 남음 |
| 구형 한글(hwp) | 난해 | — | 확률적 | 다른 형식 권장 |
| 텍스트 레이어 PDF | 손실 있음 | — | 확률적 | 붙여넣기로 우회 |
| 스캔본 PDF | 불가 | 확률적 | 확률적 | 이중 위험 |
여기서 두 가지가 나옵니다.
하나. 붙여넣기는 ①단계를 코드 없이 없애는 방법입니다. 사용자의 클립보드가 디코더 노릇을 하므로 워드·한글·텍스트 PDF가 한꺼번에 해결됩니다. 그래서 “워드 원본이 있으면 파싱이 필요 없느냐”의 정확한 답은 이렇습니다 — 파일을 여는 파싱은 필요 없습니다. 그러나 ③단계는 문서 형태와 무관하게 그대로 남습니다.
둘. 스캔본만 ②를 요구하고, 거기서는 확률적인 단계가 둘 겹칩니다. 날인과 간인, 수기 정정이 겹친 지면이면 더합니다. 검산식이 없는 상태에서 이 조합을 자동 확정 경로에 두는 것은, 틀린 값을 자신 있게 계산에 넣겠다는 뜻이 됩니다.
위험은 문서 형태보다 항목 종류로 갈립니다
문서 형태로만 나누면 놓치는 것이 있습니다. 계약 조건이라고 다 같은 무게가 아닙니다.
계산에 들어가는 단일 숫자 — 위약벌 이율, 손해배상 한도, 리픽싱 하한, 발행가. 하나만 틀려도 결과가 통째로 틀리고 검산할 방법이 없습니다. 자동 추출한 값을 그대로 확정값으로 쓰지 않습니다.
답이 정해진 선택지 — 리픽싱 방식, 사전동의 항목의 유무와 강도(동의 · 협의 · 통지 · 없음). 답이 유한하니 기계가 비교적 안정적이고, 사람이 검토하는 품도 적게 듭니다. 체크박스를 눈으로 훑는 일이니까요. 자동 채우기가 값어치를 내는 거의 유일한 영역입니다.
서술형 조건 — 위약벌 트리거 사유, 예외 규정, 정의조항. 요약은 되지만 계산에는 들어가지 않습니다. 요약본을 값으로 저장하지 말고 원문 발췌를 그대로 보관하는 편이 낫습니다.
실용적인 결과는 이렇습니다. 워드 원본이 있어도 첫 번째 종류는 사람이 넣습니다. 반대로 스캔본뿐이어도 두 번째 종류는 손이 얼마 들지 않습니다. 사람이 해야 할 일의 총량은 문서 형태보다 항목 구성으로 결정됩니다.
계약 한 건이 문서 한 개는 아닙니다
설계에서 자주 빠뜨리는 사실이 하나 더 있습니다. 투자계약은 문서 하나로 끝나지 않습니다. 본계약 위에 변경합의서 · 부속합의서 · 별지가 얹히고, 나중 문서가 앞의 조건을 덮어씁니다. 리픽싱 조건이나 동의사항이 1년 뒤 합의서로 바뀌는 일은 흔합니다.
본계약만 읽는 자동 추출은 이 경우 최신이 아닌 조건을 자신 있게 내놓습니다. 값의 형태가 멀쩡하니 검토하는 사람도 넘어갑니다.
또 하나, 법적 원본은 날인본이고 워드 파일은 초안입니다. 협상 막바지의 수정이나 수기 정정이 워드에 반영되지 않았을 수 있습니다. 워드가 다루기 쉽다는 것과 워드를 믿어도 된다는 것은 다른 이야기입니다.
그래서 조건값마다 어느 문서의 몇 조에서 왔는지를 붙여 두어야 합니다. 이 구조는 나중에 얹기가 어렵습니다.
지켜야 할 것 네 가지
- 확률적인 단계의 출력은 확정값이 될 수 없습니다. 초안으로만 들어오고, 사람이 확정해야 계산에 쓰입니다.
- 값마다 출처를 기록합니다. 사람이 넣은 값인지, 표에서 읽은 값인지, 기계가 뽑아 놓고 확인을 기다리는 값인지. 반년 뒤에 “이 30%는 어디서 온 숫자인가”를 물었을 때 답이 나와야 합니다.
- 근거 없는 자동 추출은 받지 않습니다. 값과 함께 원문 발췌와 조 번호를 내게 하고, 나란히 놓고 대조합니다.
- 조용한 기본값을 두지 않습니다. 해석하지 못한 표기를 0이나 빈칸으로 바꾸지 말고 검토 목록으로 보냅니다.
그리고 스캔본 자동 판독 경로는 아예 열지 않는 편이 낫습니다. 열어 두면 반드시 쓰이고, 쓰이면 검산 없이 계산에 들어갑니다.
필요한 것은 파싱이 아니라 확정입니다
조건을 엑셀에 정리해 두고 그 표를 읽히는 방식에 파싱이 없는 이유는, 파일이 다루기 쉬워서가 아닙니다. 사람이 확정을 이미 마쳤기 때문입니다. 워드는 파일을 여는 일만 쉬울 뿐 확정 단계는 그대로 남고, 스캔본은 확률적인 단계가 둘 겹치는데 그것을 잡아 줄 그물이 없습니다.
문서를 자동으로 읽히는 일을 계획할 때, “이 문서를 파싱할 수 있는가”보다 먼저 물어야 할 것이 있습니다. 틀렸을 때 무엇이 알려 주는가. 알려 주는 것이 없다면, 그 자리는 사람이 확정해야 합니다.