AI 프로젝트 킥오프 회의에 가면 보통 모델 얘기로 시작해요. 어떤 모델을 쓸지, 파인튜닝을 할지, RAG를 할지. 그런데 저희 경험상 프로젝트가 멈추는 지점은 거의 항상 데이터가 어디 있고 어떤 상태인지 확인하는 순간이에요.
"데이터는 많아요"의 실체
"저희 데이터 많아요"라는 말을 들으면 저희는 이렇게 물어요.
- 그 데이터가 어떤 형식인가요? → HWP, PDF, 스캔 이미지, 엑셀, 이메일 첨부, 그룹웨어 게시글…
- 어디에 있나요? → 파일 서버, 개인 PC, 복합기 스캔 폴더, 퇴사한 분의 메일함…
- 같은 종류의 문서가 같은 양식인가요? → "대체로요" (= 아니요)
"많다"는 건 맞아요. 그런데 쓸 수 있는 상태가 아니에요. 비정형 문서를 AI가 읽을 수 있는 데이터로 바꾸는 작업, 이게 전처리고, 저희는 프로젝트 시간의 절반 이상이 여기 든다고 봐요.
전처리가 하는 일
이 블로그에서 반년 동안 쓴 글의 대부분이 사실 전처리예요.
- 파일을 여는 것부터예요. HWP 네이티브 파싱(1월), HWPX(1월), 스캔 PDF 기울기 보정과 OCR.
- 구조를 복원해요. 표(2월), 헤딩 계층(1월 27일), 각주, 도면이면 표제란·부품표(2월).
- 쓸 수 있는 단위로 나눠요. RAG 청크(3월 17일), 추출 필드(6월).
- 원본 위치를 붙여요. 모든 글에 나오는
src예요.
모델은 이 위에 올라가요. 전처리가 틀리면 모델이 아무리 좋아도 틀린 걸 똑똑하게 틀려요.
왜 자꾸 과소평가되냐면요
전처리는 데모에 안 나와요. 데모에서는 깨끗한 문서 한 장을 보여 주니까요. 그리고 "파일 열기"가 어려운 일이라고 아무도 생각 안 해요. 저희도 처음엔 HWP 파서를 2주짜리로 잡았었어요. 몇 달 걸렸어요.
또 하나, 전처리 문제는 조직 문제랑 얽혀 있어요. 문서가 개인 PC에 있으면 모으는 것부터 권한과 절차가 필요해요. 양식이 팀마다 다르면 통일하자는 얘기가 나오고, 그건 기술 문제가 아니에요.
저희가 하는 방식
1. 모델 얘기 전에 문서 샘플부터 받아요. 종류별로 수십 장. 이걸 저희 파서에 돌려 보면 전처리 난이도가 바로 나와요. "이 양식은 되는데 이건 안 돼요"가 첫 번째 결과물이에요.
2. 전처리 결과를 그 자체로 산출물로 봐요. 모델 없이도 "문서가 구조화된 데이터가 됐다"는 건 가치가 있어요. 검색이 되고, 통계가 되고, 다른 시스템에 넣을 수 있어요. 전처리를 모델의 부속이 아니라 독립된 단계로 계획하면 프로젝트가 중간에 멈춰도 남는 게 있어요.
3. 전처리 품질을 지표로 재요. 표 추출은 숫자 셀 정합률(2월 3일), 문서 구조는 헤딩 복원율, 이런 식으로요. "모델 정확도"만 재면 전처리에서 난 문제가 모델 탓으로 보여요.
4. 처음부터 원본 위치를 남겨요. 나중에 붙이려면 다시 해야 해요. 전처리 설계 첫날에 정해야 해요.
한 가지 더: 전처리는 끝나지 않아요
새 양식이 들어오고, 복합기가 바뀌어서 스캔 품질이 달라지고, 한/글 버전이 올라가요. 전처리 파이프라인은 한 번 만들고 끝이 아니라 운영이에요. 저희가 전처리 단계마다 신뢰도를 남기고 모니터링하는 이유예요.
정리
- AI 프로젝트의 병목은 모델이 아니라 조직 안의 비정형 문서예요.
- 전처리를 독립된 단계로 계획하고, 그 품질을 따로 재세요.
- 원본 위치는 첫날부터 남기세요.
- 전처리는 운영이에요. 끝나지 않아요.
다음 주는 에이전트 권한 설계예요. 4월에 쓴 "뚝딱" 설계 글을 일반화해서, 에이전트에게 실행 권한을 줄 때 꼭 같이 설계해야 할 것들을 정리할게요.