AI에 문서를 넣기 전에 통과해야 하는 세 관문 — 형식·접근권·파싱 품질. HWP·DRM·파라미터 한 줄이 만든 현장 실패에서 추출한 사전 점검 체크리스트.
— 데이터 파이프라인, 보이지 않는 세 개의 관문
파이프라인은 완성된 것처럼 보였다.
문서는 들어갔고, Pod는 정상 기동했고, 요청도 수신하고 있었다. 그런데 RAG 기반 질의응답 결과가 나오지 않았다.
원인은 파싱 엔진을 호출하는 코드 한 줄이었다. 설정값 하나.
그런데 이 에피소드에 도달하기까지, 이 팀은 이미 두 개의 관문을 통과한 상태였다.
형식의 관문. 접근권의 관문. 그리고 파싱 품질의 관문.
지난 편(6편)에서 PoC 이후 운영 안정화를 다뤘다면, 이번 글은 그 운영이 가치를 내려면 반드시 통과해야 하는 선행 조건을 짚는다. 업계에서 기업 정보의 70~80%가 비정형에 해당한다고 추정되는 환경에서[1], AI에 넣기 전에 먼저 읽을 수 있어야 한다.
형식의 벽. 먼저 열 수 있어야 한다.
착수 미팅이 끝난 뒤, 우리가 담당자에게서 들은 말이다.
"주 문서가 한글(HWP)입니다."
에이전트 도입 설계가 시작된 시점이었다. 어떤 데이터를 AI에 넣을 것인가를 논의하는 자리에서, 그 데이터의 대부분이 HWP 형식이라는 사실이 뒤늦게 드러났다. PDF나 DOCX라면 오픈소스 파싱 엔진으로 처리할 수 있다. HWP는 다르다. 폐쇄망·상용 운영 환경에서 안정적으로 처리하려면 한컴 계열 라이선스나 별도 파싱 모듈이 필요하다.
당시 내부 견적으로 단일 서버 환경 기준 서버, OS, 라이선스를 합쳐 1,000만 원 이내. 문제는 금액이 아니었다. 그 비용이 사업비에 포함되어 있지 않았다는 것이다.
고객사 담당자의 말이 이 에피소드를 요약한다.
"처음 듣는 얘기라 따로 안 담았다."
HWP는 단순 구현 문제가 아니다. 예산 문제이고, 계획 문제이며, 범위 문제다. PoC 단계에서 "어떤 파일을 처리할 것인가"를 논의할 때, 기술 요건이 아니라 도입 설계 요건으로 다뤘어야 했다. 우리가 여러 PoC를 거치며 반복해서 마주친 공백이다.
한 에너지 공기업에서는 상황이 한 겹 더 복잡했다. 경영평가 실적 문서들이 HWP 형식이었는데, 그 파일들에 DRM까지 걸려 있었다. 파싱 전에 두 개의 관문을 통과해야 했다. 열 수 있는가, 그리고 암호가 풀려 있는가.
HWP는 한국 공공기관과 금융권에서 수십 년간 사실상 표준으로 사용된 문서 포맷이다. 정부 발표에 따르면 2026년 5월부터 지방정부 온나라시스템에도 hwp 첨부 제한과 개방형 포맷 전환이 확대될 예정이다[2]. 그러나 이미 축적된 기존 HWP 문서는 여전히 주력 데이터로 남는다. TIF 스캔 문서도 같은 구조다. 금융 계열사 A그룹에서 우리가 직접 본 장면이다. 업무 담당자들이 TIF 파일을 일일이 PDF로 수동 변환해 업로드하고 있었다. 파이프라인이 올라가 있는 동안, 데이터 입구는 수작업이었다.
"어떤 파일을 AI에 넣을 수 있는지 확인하기 전에, 그 파일을 열 수 있는지부터 확인해야 했다."
접근권의 벽. 복호화 파이프라인.
금융사 H의 내부 개발자가 슬랙에 메모를 남겼다.
"DRM 업체는 우리 장비에 서버 띄우고 가이드 문서 주고 끝. 저 서버는 K8s 바깥에 있고, 우리는 K8s 안 Pod에서 연결해야 한다. 그 삽질 과정입니다."
기업 내부 문서에 DRM이 걸려 있다는 건 이 업계에서 예외적인 상황이 아니다. 우리가 금융·공공·제조 프로젝트를 거치며 반복적으로 마주친 게 내부 문서 DRM이다. AI 시스템이 처리할 수 있는 건 복호화된 텍스트뿐이다. 그 사이에 복호화 파이프라인이 있어야 한다.
구조적 문제는 하나다. DRM 서버는 K8s 바깥에 있다. AI 파이프라인 Pod는 K8s 안에 있다. 네트워크 경계가 다르다. DRM 업체는 서버를 설치하고 가이드 문서를 넘기면 자기 역할이 끝이다. 그 서버와 AI 시스템을 연결하는 것은 도입팀의 몫이다.
이 구조는 금융사 H에서만 반복된 것이 아니었다.
금융 계열사 A그룹에서는 착수 보고 단계에서 DRM 요구사항이 추가됐다. "내부 문서 업로드 시 복호화 개발 필요." 한 에너지 공기업에서는 경영평가 실적 문서들이 zip으로 압축된 채 DRM까지 걸린 상태로 업로드됐다. 묶음 해제, 복호화, 파싱 — 세 단계가 순서대로 작동해야 했다.
고객사마다 DRM 벤더가 달랐다. 각각 연동 개발이 필요했고, E2E 테스트까지 포함하면 고객사당 통상 2~4주가 소요됐다. 반복이 쌓이자 내부에서 문서를 작성했다.
"나중에 다른 온프렘 고객사 DRM 하실 때 읽으셔도 늦지 않습니다."
DRM 연동이 once-for-all이 아닌 이유는 두 가지다. 고객사마다 벤더가 다르고, 망마다 정책이 다르다. 금융권은 내부망·외부망 통제 요건 때문에 Pod와 DRM 서버 간 통신 경로를 별도로 설계해야 한다[3]. AI 시스템이 문서에 접근하려면 복호화 파이프라인이 먼저 존재해야 한다. 그리고 그 파이프라인은 도입 범위에 처음부터 들어가 있어야 한다.
열 수 있는가(관문 1), 암호가 풀려 있는가(관문 2). 두 관문은 모두 데이터에 '접근'하는 문제였다. 이제 접근의 문제를 넘어, 해석의 문제로 들어선다.
파싱 품질의 벽. 그리고 실제 원인.
글의 시작으로 돌아온다.
두 관문을 통과한 금융 계열사 A그룹의 팀은 마침내 MinerU 파싱 엔진 앞에 도달했다. 문서는 열렸고, DRM은 풀렸고, 이제 텍스트가 구조화되어 AI에 들어갈 차례였다. 그런데 MinerU 0.2.0 업그레이드 직후, 온프렘 3개 망 전체에서 MinerU 기반 OCR 파싱 작업이 동시에 실패했다.
저축은행 망, 캐피탈 망, 그룹사 망. 셋 다.
Pod는 정상 기동이었다. 요청도 수신하고 있었다. 그런데 파싱 결과가 나오지 않았다. 한국어가 깨졌다. 이미지 인식이 실패했다.
우리 팀이 먼저 의심한 건 이미지 손상이었다. 폐쇄망에서 USB로 반입한 18GB짜리 MinerU 컨테이너 이미지에 손상이 생겼을 가능성을 먼저 확인하는 건 자연스러운 반응이다. 레이어 31개의 SHA256을 전부 검증하고 Harbor에서 재반입했다. 10분이 넘게 걸렸다.
손상이 없었다.
원인은 MinerU를 호출하는 데이터 수집(Data Ingest) 코드에 있었다. formula_enable=true로 파라미터가 설정되어 있었다. 수식 추출 모드가 켜진 상태에서 한글 주변의 특수 기호·문장부호 일부가 수식 기호 패턴과 유사하게 인식되어 오분류를 일으킨 것이다. 한국어를 수식으로 읽고 있었다.
수정은 true → false. 배포는 바로 됐다. 3개 망이 즉시 복구됐다.
18GB 재압축에 쓴 시간은 전부 불필요했다.
이 일에서 우리가 얻은 교훈은 두 방향이다.
첫 번째는 디버깅 순서다. 폐쇄망에서 이미지 재반입은 비용이 크다. 인프라를 먼저 의심하는 건 직관적이지만, 파라미터 설정 같은 소프트웨어 레이어를 먼저 확인했다면 시간을 아낄 수 있었다. 인프라보다 코드가 더 자주 변한다.
두 번째는 기본값의 위험이다. 이 사례에서 formula_enable=true는 한국어 문서와 충돌하는 파라미터였다. 언어별 특수성이 파싱 엔진 기본값과 맞지 않는 지점이 있을 수 있다. 파싱 엔진을 도입할 때 실제 고객사 문서로 파라미터를 검증하지 않으면, 운영에 올라가고 나서야 발견한다.
그리고 세 관문을 통과하고 나서도, 문서 파이프라인 외부에서 들어오는 데이터가 있다면 그 품질도 별도로 관리해야 한다.
한 금융사의 음성봇이 정식 운영에 들어간 지 3개월이 지났을 때, 고객사 담당자가 1,400여 건의 문제 발화를 수집해 왔다. 크리티컬한 할루시네이션도 포함돼 있었다. 원인은 문서가 아니었다. STT, 음성 인식이었다.
음성 인식 결과가 그대로 RAG 입력으로 들어갔다. 깨진 텍스트가 들어가자 뜬금없는 답변이 나왔다. 입력 데이터의 품질이 AI 출력 품질의 상한선이 됐다.
담당자의 말이 이 상황을 담고 있었다.
"아직 내부적으로도 완성도가 있다고 판단하지 못하고 있어서 자랑스럽게 내세우지 못하는 입장입니다."
문서 파이프라인이 완성됐다는 것과, AI에 들어가는 데이터가 깨끗하다는 것은 다른 얘기다. 음성, OCR, 크롤링, 수작업 입력 — 각 경로마다 품질 기준이 별도로 필요하다.
세 에피소드는 우연히 다른 고객사에서 생긴 별개의 문제가 아니다. 데이터 파이프라인을 구성하는 세 개의 레이어가 각각 어떻게 실패하는지를 보여주는 패턴이다.
관문 1: 형식. 관문 2: 접근권. 관문 3: 파싱 품질.
이 순서는 의존 관계다. 관문 1을 통과하지 못하면 관문 2는 의미 없다. 관문 2가 막히면 관문 3에 도달할 수 없다. 그리고 관문 3은 — 가장 기술적으로 정교한 문제처럼 보이지만 — 실제로는 파라미터 하나의 문제였다.
파이프라인 설계를 시작하기 전에 주요 업무 문서 포맷을 목록화한다.
"어떤 파일을 AI에 넣을 것인가"는 기술 요건이 아니라 도입 설계 요건이다. PoC 범위를 정할 때 확인해야 한다. 오픈 이후에 발견하면 추경 예산 사안이 된다.
내부 문서에 DRM이 걸려 있는가를 확인한다.
DRM 연동은 고객사마다 벤더가 다르고 수 주가 소요된다. 도입 계획에 포함하지 않으면 오픈 직후 발견한다.
파싱 엔진을 실제 고객사 문서로 검증한다.
formula_enable, layout_mode 등 주요 파라미터 기본값 문서 검토우리가 맡은 데이터 분석 에이전트 기획서에 "주간 보고 PPT에서 표 추출"이 요건으로 들어가 있었다. PM은 당연히 된다고 가정했다. 개발팀은 "현재 MCP 툴로 분석 안 됨"으로 표시해뒀다. 두 가정이 기획서 안에 공존하고 있었고, 아무도 충돌을 인지하지 못했다. 구조화가 안 된 데이터는 에이전트도 쓸 수 없다.
세 관문을 통과한 뒤에도 한 가지가 남는다. 문서 파이프라인 외에 AI에 들어가는 다른 경로가 있는가.
음성(STT), OCR 스캔, 크롤링, 수작업 입력 — 각 경로의 데이터 품질이 관리되고 있는가. 파싱 엔진이 정상이어도 STT 오인식이 섞이면 RAG 출력의 상한선은 거기서 정해진다.
도입 전에 이 비용들이 "보이지 않는" 이유가 있다. 기술 스펙서에 등장하지 않는다. PoC 요건 정의에 포함되지 않는 경우가 많다. AI 서버, 모델, 라이선스를 중심으로 예산이 짜인다.
이 비용의 소유자는 누구인가. HWP 라이선스는 사업팀이 계획하고 구매팀이 집행하지만, 필요성을 먼저 인식하는 쪽은 AI 엔지니어링 팀이다. DRM 연동은 보안팀·인프라팀·벤더가 함께 설계해야 하지만 도입 계획에서는 빠지기 쉽다. 파이프라인 구축 비용이 '보이지 않는' 것은 특정 팀의 실수가 아니라, 초기 단계에서 유관 부서가 함께 데이터의 전체 생애주기를 점검하지 않을 때 생기는 구조적 공백이다.
핵심 트레이드오프는 하나다.
파이프라인 구축 비용은 도입 전에 범위에 넣으면 프로젝트 비용이다. 도입 후에 발견하면 운영 사고다.
"처음 듣는 얘기라 따로 안 담았다"는 발언이 사업비 항목 추가로 끝난 것은 운이 좋은 경우다. 오픈 이후 발견된 DRM 연동 이슈는 일정 지연으로 이어진다. formula_enable 버그는 3개 망의 파싱 작업을 동시에 멈췄다.
비용을 숨기는 것이 아니라, 보이지 않아서 빠진 것이다. PoC 단계에서 데이터 파이프라인 점검을 명시적으로 수행하면 이 비용들이 드러난다.
이 중 하나라도 "아니오"라면, 데이터 파이프라인이 조용히 실패하고 있을 가능성이 있다.
1. 형식: 우리 조직의 주요 업무 문서 포맷은 무엇인가? HWP, TIF, 스캔 PDF — 지금 AI 파이프라인이 이것을 처리할 수 있는가, 아니면 담당자가 수작업으로 변환하고 있는가?
2. 접근권: 내부 문서에 DRM이 걸려 있는가? AI 파이프라인이 DRM 서버와 통신할 수 있는 경로가 설계되어 있는가?
3. 파싱 품질: 파싱 엔진의 언어 설정이 한국어에 맞게 되어 있는가? 기본값 그대로 운영 중이지는 않은가? 실제 고객사 문서 샘플로 파싱 품질을 검증한 리포트가 있는가?
4. 구조화 범위: PPT/PDF 내 표 데이터가 에이전트 요건에 포함되어 있는가? 현재 파이프라인이 표를 구조화해서 입력하고 있는가?
5. 입력 품질: 음성, OCR, 크롤링 등 문서 외 경로로 들어오는 데이터의 품질이 관리되고 있는가?
1편부터 7편까지, 우리가 온프렘 AI를 세우고 운영하며 직접 겪은 현장을 기록해왔다.
배포 문제, 보안 설계, GPU 최적화, 사일런트 장애, 에이전트 연동, 운영 안정화, 그리고 데이터 파이프라인. AI 도입 계획서에는 없지만, 실제 구축과 운영 현장에서 반드시 마주치는 문제들이 있다. 이 시리즈는 그 목록을 우리 팀이 현장에서 직접 뽑아왔다.
마지막 편에서는 이 모든 경험을 하나의 프레임워크로 압축합니다. 어떤 플랫폼을 선택할 것인가 — 기술 스펙이 아니라 운영 조건으로 판단하는 방법입니다.
파이프라인이 완성됐다는 것과, AI가 실제로 쓸 수 있는 데이터가 있다는 것은 같은 말이 아닙니다. 당신의 파이프라인이 세 관문을 모두 통과했는지, 확인하셨습니까?
이 글의 사례들은 온프레미스 AI 구축 엔지니어링 팀의 운영 경험에서 추출했습니다. 고객사명과 담당자명은 모두 익명입니다.
출처
[1] IDC & Seagate, Data Age 2025: The Digitization of the World — From Edge to Core (2018). 비정형 데이터가 글로벌 데이터스피어의 다수를 차지한다고 기술. "70~80%" 수치는 이 보고서를 포함한 업계 복수 기관(Gartner, IDC 등)이 공통적으로 제시하는 추정치. URL: https://www.seagate.com/files/www-content/our-story/trends/files/Seagate-WP-DataAge2025-March-2017.pdf
[2] 파이낸셜뉴스·뉴시스 보도 (2026-04-23~24), 「공공기관 HWPX 전환 확대 시행」 — 행정안전부·국가인공지능전략위원회 공동 발표 인용. 2026년 5월 지방정부 온나라시스템 hwp 첨부 제한, 10월 온메일·공직자통합메일 확대 예정. 법령 근거: 「행정업무의 운영 및 혁신에 관한 규정」 제5조 개정 추진 중. URL: https://www.fnnews.com/news/202604241001326749 | https://www.newsis.com/view/NISX20260423_0003603780
[3] 「전자금융감독규정」 — 제15조(해킹 방지대책: 내부통신망 분리·차단), 제31~34조(암호화 통신·비밀번호 보관). 금융기관이 규제 준수를 위해 내부문서에 DRM을 적용하는 실무적 근거. 2025년 2월 개정 시행(원칙 중심 전환). URL: https://law.go.kr/행정규칙/전자금융감독규정
올거나이즈의 온프레미스 AI 구축 경험을 통해, 금융·제조·공공·IT서비스 현장에서 도입 검토 → 운영 전환 → 장기 운영 파트너십을 하나의 흐름으로 설계해 왔습니다. HWP 라이선스부터 DRM 복호화 파이프라인, 파싱 엔진 튜닝까지 — 데이터 파이프라인 구축 경험을 기반으로, 지금 팀이 서 있는 지점부터 이야기를 시작할 수 있습니다.
