'범정부 AI 공통기반'에 올라가는 문서 전처리 파이프라인, 보안 요건부터 설계하기

왜 '전처리'부터 보안을 고려해야 하는가

행정안전부의 「공공부문 AI 도입·활용 가이드」는 개별 기관의 중복 인프라 구축을 막기 위해 범정부 AI 공통기반 우선 이용을 규정하고 있습니다. 이는 GPU·모델 같은 연산 자원의 공동 이용에 초점이 맞춰진 정책이지만, 그 앞단에 있는 문서 전처리 파이프라인도 같은 보안 원칙 아래에서 설계되어야 합니다. 문서 자체가 대외비이거나 개인정보를 포함하는 경우, "일단 외부 API로 텍스트만 뽑고 나중에 걸러내자"는 접근은 컴플라이언스 리스크를 안고 시작하는 것입니다.

아래는 공공기관 대상 문서 전처리 파이프라인을 설계할 때 고려해야 할 원칙입니다. 특정 공통기반의 기술 사양을 전제하지 않고, 보안 등급이 있는 문서를 다루는 파이프라인에 공통적으로 적용할 수 있는 아키텍처 원칙 위주로 정리했습니다.

1. 문서를 보내기 전에 등급부터 분류한다

전처리 파이프라인의 첫 단계는 변환이 아니라 분류여야 합니다. 문서를 공개/부분공개/대외비 등 등급별로 먼저 나누고, 등급에 따라 처리 경로 자체를 분리하는 것이 이후 모든 설계의 전제가 됩니다. 등급 분류를 사람이 수동으로 하기 어려운 규모라면, 문서 관리 시스템(EDMS)에 이미 태깅된 메타데이터를 최대한 활용하는 편이 새로운 분류 로직을 만드는 것보다 안전합니다.

2. 대외비 문서는 외부 네트워크 호출이 없는 경로로 처리한다

HWP/HWPX 파싱, 표 구조 인식, 텍스트 정제 같은 전처리 단계는 반드시 외부 SaaS API를 거쳐야 하는 작업이 아닙니다. 오픈소스 파서와 온프레미스에서 구동 가능한 경량 모델만으로도 상당 부분 처리할 수 있습니다. 등급이 높은 문서군은 이 온프레미스 경로로만 흐르도록 네트워크 수준에서 강제하는 것이, 애플리케이션 로직에서 "이 문서는 외부로 보내지 않기"를 조건문으로 처리하는 것보다 안전합니다.

3. 변환 결과물도 원문과 동일한 등급으로 취급한다

변환 과정에서 생성되는 중간 산출물(추출된 텍스트, 청크, 임베딩)은 원본 문서의 보안 등급을 그대로 승계해야 합니다. 실무에서 자주 놓치는 지점은, 원본 파일은 접근 통제가 걸려 있는데 변환 후 생성된 텍스트 파일이나 캐시는 별도 저장소에 통제 없이 쌓이는 경우입니다.

4. 파이프라인 로그에 문서 내용이 남지 않게 한다

디버깅을 위해 파이프라인 로그에 문서 원문 일부를 그대로 남기는 경우가 흔합니다. 대외비 문서를 다루는 파이프라인이라면 로그에는 문서 식별자와 처리 상태만 남기고, 실제 내용은 별도의 접근 통제된 저장소에만 존재하도록 분리해야 합니다.

5. 공통기반에 넘기는 시점을 명확히 정의한다

범정부 공통기반의 연산 자원을 활용하는 구간과, 기관 자체 인프라에서 처리하는 구간의 경계를 아키텍처 다이어그램 수준에서 명확히 그어두어야 합니다. "여기까지는 온프레미스, 여기부터는 공통기반"이라는 경계가 모호하면, 등급이 있는 문서의 중간 산출물이 의도치 않게 공통기반으로 넘어가는 경로가 생길 수 있습니다.

6. 변경 이력을 추적 가능하게 남긴다

어떤 문서가 언제 어떤 버전의 파이프라인으로 처리되어 벡터 DB의 어느 청크가 되었는지 추적할 수 있어야, 이후 감사나 문제 발생 시 원인 파악이 가능합니다. 이는 보안 요건이자 동시에 RAG 응답의 신뢰도를 담보하는 장치이기도 합니다.

결론

범정부 AI 공통기반 활용이 표준이 되어가는 흐름 속에서, 그 위에 얹는 문서 전처리 파이프라인의 설계 원칙도 함께 표준화될 필요가 있습니다. 등급 분류를 첫 단계로 두고, 온프레미스와 공통기반의 경계를 명확히 그으며, 중간 산출물까지 원본과 동일하게 통제하는 것이 공공 AI 프로젝트에서 문서 전처리를 설계하는 기본 원칙입니다.

참고 자료

이 글은 범정부 AI 공통기반의 공개된 정책 방향을 참고해 일반적인 아키텍처 설계 원칙을 제안한 것이며, 공통기반의 구체적인 기술 사양이나 API를 전제하지 않습니다. 실제 프로젝트에서는 발주 기관 및 관리 기관이 제공하는 최신 기술 지침을 우선 확인하시길 권장합니다.