12만 건 이력 조회에 멈춰 선 도면함, 감사 대응이 드러낸 대용량 문서 인프라의 바닥

연간 수만 건의 도면과 계약서가 쌓이는 엔지니어링 업계에서 정기 외부 감사는 시스템 한계를 시험하는 현장이다. 최근 한 중견 플랜트 엔지니어링 기업의 전산실은 감사관이 특정 연도 프로젝트 문서 12만 건의 최종 승인본과 수정 이력을 요구하자 조회 기능이 멈춰 서는 상황을 겪었다. 단순 파일 서버 형태로 운영하던 문서관리 체계가 5테라바이트(TB)를 넘어가면서 인덱스 색인이 깨지고 다중 쿼리 요청을 버텨내지 못한 탓이다.

단일 스토리지의 한계와 감사 지연

이 회사는 프로젝트별로 네트워크 드라이브 폴더를 생성하고 그룹웨어 결재 문서와 연동해 두는 방식을 유지해왔다. 사업 초기에는 문제가 없었으나, 3년 치 데이터가 100만 건을 넘어서자 일괄 로그 추출 시 서버 응답 속도가 분 단위로 늘어났다.

감사팀이 요구한 시점별 문서 버전 대조 작업은 수작업으로 전환됐다. 수백 메가바이트(MB)에 달하는 3D CAD 파일과 수백 쪽에 이르는 시방서가 섞여 있는 탓에 검색 엔진이 메모리 부족 오류를 뿜어냈다. 현장 엔지니어들이 개별 PC에 임시 저장해둔 복사본과 중앙 저장소의 문서 버전이 어긋나는 정황도 드러났다. 감사 대응 일정은 계획보다 2주가량 밀렸다.

메타데이터 분리와 스토리지 티어링

전산 조직은 전자문서관리(EDMS) 인프라의 확장성(Scalability) 확보를 최우선 과제로 올리고 아키텍처 점검에 들어갔다. 파일 본체와 메타데이터의 저장 구조를 분리하고, 감사 대상 기간에 따라 저장소를 차등 배치하는 방식을 도입했다.

진행 중인 프로젝트와 최근 1년 치 문서는 고성능 플래시 스토리지에 유지하고, 감사가 완료된 과거 데이터는 읽기 전용 콜드 스토리지로 자동 이관되도록 경로를 재구성했다. 검색 인덱싱 엔진도 분산 노드로 나누어 특정 부서의 대용량 문서 색인 작업이 전사 감사 쿼리에 영향을 주지 않도록 격리했다.

구분	개편 전 (단일 스토리지)	개편 후 (분산 티어링)
저장 구조	파일 및 속성 단일 서버 집중	본체 오브젝트 및 메타 DB 분리
검색 방식	디렉터리 순차 스캔	분산 인덱스 엔진 적용
이력 추적	폴더별 텍스트 로그 분산	결재 연동 단일 감사 로그 뷰
10만 건 로그 추출	15분 이상 (타임아웃 빈번)	1분 내외 수렴

"과거 문서를 단순히 쌓아두는 것과 언제든 감사관 앞에서 무결성을 입증할 수 있게 꺼내는 것은 인프라 차원에서 완전히 다른 문제"라는 게 이번 시스템 개편을 총괄한 인프라팀장의 설명이다.

이력 추적의 자동화와 버전 정합성

인프라 확장과 함께 문서 생명주기 관리 체계도 손질했다. 설계 변경(ECO)이 발생할 때마다 그룹웨어 결재선을 거쳐 승인된 문서만 새 버전으로 덮어쓰지 않고 상위 버전 번호를 매겨 병렬 보관하도록 강제했다.

임의 수정이나 로컬 다운로드 후 재업로드 과정에서 생기는 버전 꼬임은 감사 과정에서 신뢰성을 떨어뜨리는 핵심 요인이다. 개편 이후에는 결재 승인 즉시 고유 해시값이 생성돼 메타데이터와 결합되므로, 대용량 감사 로그를 추출할 때 문서 위변조 여부가 자동으로 검증된다. 대용량 파일의 업로드와 조회가 반복되는 환경에서도 감사 로그 생성에 걸리는 병목을 줄여내는 구조를 만들었다.

데이터 증가율 예측이 사후 비용 막는다

엔지니어링이나 제조 플랜트처럼 파일 용량이 급격히 불어나는 조직에서는 도입 단계부터 데이터 증가율을 보수적으로 잡아야 한다. 문서 건수 증가에 맞춰 스토리지와 컴퓨팅 자원을 독립적으로 늘릴 수 있는 스케일아웃 구조인지, 대량 쿼리 발생 시 결재나 업무 결재선 화면에 지연이 발생하지 않는지 사전에 부하 테스트를 거치는 작업이 필요하다. 시스템 규모가 커질수록 감사 로그 추출 성능은 인프라 안정성을 가늠하는 척도가 된다.