01문제
이 조직의 의사결정은 문서로 이뤄진다. 초안이 오가고, 상급자가 변경추적을 켠 채로 고치고, 코멘트로 질문을 달고, 최종본이 PDF로 굳는다. 자동화를 붙이려면 이 문서들을 읽어야 하는데, 일반적인 텍스트 추출은 본문만 긁고 변경추적과 코멘트를 버린다. 그런데 조직 입장에서 중요한 정보는 대개 버려지는 쪽에 있다. 누가 무엇을 왜 고쳤는지가 최종 문장보다 더 많은 것을 말해 준다.
기존 방법은 두 가지였고 둘 다 막혔다. 첫째, 오피스 프로그램을 서버에 띄워 변환하는 방식은 무거운 데스크톱 의존을 파이프라인에 끌어들이고 실패 시 원인 추적이 어렵다. 둘째, 변환기를 그냥 통과시키는 방식은 변경추적을 삭제하거나 반대로 취소선 텍스트를 본문에 섞어 버려 원본보다 나쁜 입력을 만든다.
여기에 한국어 조건이 하나 더 붙었다. 스캔된 한국어 PDF의 표와 레이아웃이 깨지면 그 문서는 요약 단계에서 조용히 왜곡된다. 읽기 실패가 눈에 보이는 오류로 나타나지 않는다는 점이 이 문제의 위험한 부분이다.
02제약
- 데스크톱 오피스 의존 제거. 서버에서 GUI 프로그램을 띄우는 구성은 쓰지 않는다. 순수 라이브러리로 처리해야 한다.
- 왕복 무손실. 읽고 다시 쓰는 과정에서 변경추적·코멘트가 사라지면 실패다. 형식 규격을 직접 다뤄야 한다.
- 한국어 우선. 영문 문서에서 잘 되는 것으로는 판단하지 않는다. 한국어 표·주석·줄바꿈에서 검증한다.
- 실무자가 쓸 수 있어야 한다. 파이프라인을 아는 사람만 쓸 수 있으면 도입 효과가 특정 인원에 묶인다.
- 검증 없는 개선 주장 금지. 빨라졌다는 체감이 아니라 같은 과업을 두 번 돌려 나온 수치로 말한다.
03접근
1) 규격을 직접 다뤘다
DOCX의 변경추적과 코멘트를 문서 규격(OOXML) 수준에서 읽고 쓰는 라이브러리를 만들었다. 중간 변환기를 거치지 않으므로 무엇이 왜 사라졌는지 추적할 수 있고, 외부 오피스 설치가 필요 없다.
2) 왕복 검사를 개발 규칙으로 못 박았다
기능을 추가할 때마다 문서를 변환해 되돌린 뒤 원본과 같아지는지 확인하는 왕복 테스트를 기본 규칙으로 채택했다. 이 규칙 때문에 초기 사이클에서 여러 번 설계를 되돌렸지만, 그 대가로 "특정 문서에서만 조용히 깨지는" 부류의 결함이 초기에 걸러졌다.
3) v1에서 v4까지 반복했다
한 번에 완성하지 않고 네 번의 사이클로 나눴다. 각 사이클은 실패하는 문서 유형을 먼저 확보하고 그것을 통과시키는 방식으로 진행했다. 최종적으로 테스트 48건이 라이브러리에 남아 회귀를 막는다.
4) 스캔 PDF는 비전 모델로 읽고 조판으로 검증했다
스캔된 한국어 PDF는 텍스트 추출로 표를 살릴 수 없어 비전 기반 문서 파서를 붙였고, 결과를 조판 엔진으로 다시 렌더해 원본과 비교하는 방식으로 확인했다. 표가 깨졌는지를 눈으로 볼 수 있게 만든 것이 핵심이다.
5) 실무자에게는 스킬로 포장했다
파이프라인을 라이브러리로만 남기면 쓰는 사람이 개발자에 한정된다. 그래서 에이전트가 바로 호출할 수 있는 스킬 형태로 패키징해, 문서를 던지면 처리 절차가 자동으로 선택되게 했다.
6) 효과를 A/B로 측정했다
스킬 도입 효과를 체감으로 말하지 않기 위해 동일 과업을 스킬 없이 한 번, 스킬을 붙여 한 번 수행하는 파일럿을 돌렸다. 처리 시간과 도구 호출 횟수를 같이 기록해 개선이 어디에서 나왔는지 분리했다.
04결과
| 항목 | 실측 |
|---|---|
| 동일 과업 처리 시간 | 67초 → 31초 |
| 처리 시간 단축률 | 55% |
| 도구 호출 횟수 | 절반으로 감소 |
| 라이브러리 회귀 테스트 | 48건 |
| 변환에 필요한 데스크톱 오피스 설치 | 0건 |
| 개발 사이클 | 4회 (v1-v4) |
변경추적과 코멘트가 살아 있는 상태로 문서를 파이프라인에 넣을 수 있게 되면서, 보고 문서의 수정 이력 자체가 자동화의 입력이 됐다. 최종본만 읽던 흐름에서 "무엇이 왜 바뀌었는지"까지 읽는 흐름으로 바뀐 것이 실제 변화다.
05재현 가능한 부분
다음은 고객사 고유 정보 없이 이식할 수 있는 산출물이다.
- DOCX 변경추적·코멘트 처리 라이브러리. 규격 수준 읽기·쓰기, 데스크톱 오피스 의존 없음, 회귀 테스트 48건 포함.
- 왕복 무손실 테스트 규칙. 변환 후 복원 결과를 원본과 비교하는 개발 기본 규칙과 실패 유형 목록.
- 스캔 PDF 검증 루프. 비전 파서로 읽고 조판 엔진으로 다시 렌더해 표·레이아웃 손상을 눈으로 확인하는 절차.
- 에이전트 스킬 패키징 골격. 문서 유형에 따라 처리 경로를 자동 선택하는 구성과 실패 시 사람에게 넘기는 조건.
- A/B 측정 방식. 동일 과업을 도구 유무로 두 번 돌려 처리 시간과 도구 호출 횟수를 함께 기록하는 파일럿 설계.
재현되지 않는 것은 고객사의 문서 서식, 결재 흐름, 그리고 실제 보고 내용이다. 서식이 바뀌면 실패하는 문서 유형도 바뀌므로, 이식할 때는 그 조직의 실패 문서를 먼저 모으는 편이 정확하다.
문서 기반 업무를 자동화 흐름에 넣고 싶다면
bk@bkan.dev 문의 폼은 두지 않는다. 메일 한 통이면 된다.