플러스프로젝트 배경
인터넷이 닿지 않는 폐쇄망 안에서 기술 매뉴얼을 영어와 한국어로 번역해야 했다. 문서는 표와 도면이 많은 정비·절차서였고, 데이터를 외부로 내보낼 수 없다는 게 절대 조건이었다. 금융·제조·공공처럼 규제로 클라우드를 쓰지 못하는 현장에서 흔히 겪는 제약이다. 사람이 일일이 번역하던 문서 한 건을 검토에 넘기기까지 걸리는 시간을 줄이는 게 목표였다.
프로젝트 성과
처리 시간 −58% (역발상 양자화)
6페이지 문서 기준 35분에서 13분으로. 병목이던 LLM 생성을 위해 양자화를 낮춰 GPU에 100% 적재하고 표 셀 호출을 90회→9회로 묶었다. 9개 샘플 품질 대조에서 저하 항목은 없었다.
용어 일관성 70.5→86.5
100점 만점 기준. 문서 단위 용어 캐시로 첫 번역을 이후 등장에 주입하고, 규칙 위반은 사후 교정했다. 같은 문단은 재번역 없이 재사용한다.
외부망 의존 0
클라우드 API·CDN 없이 로컬 GPU와 로컬 캐시로 전 구성요소를 폐쇄망 안에서 구동한다. 데이터가 망 밖으로 나가지 않는다.
동시성 결함 17건 → 0
감사에서 찾은 동시성 결함을 전건 수정했다. SQLite WAL로 동시 쓰기 충돌을 거의 차단하고 GPU 작업은 한 건씩 직렬화했다.
289페이지 문서 무손실 처리
제목·문단·표셀 3,771개 블록을 폴백 없이 완주했다. 완성 산출물이 폐기되던 회귀도 함께 잡았다.
핵심 기능
로컬 LLM 번역
외부망 없이 로컬 GPU의 오픈 LLM으로 영어와 한국어를 오간다. 데이터가 폐쇄망 밖으로 나가지 않는다.
진행 단계
요건·아키텍처
2025.07
폐쇄망 제약을 정리하고 PDF 파싱→번역→산출물 파이프라인과 로컬 LLM 구성을 설계했다.
프로젝트 상세
데이터를 밖으로 못 보내니 클라우드 번역 API도, 온라인 LLM 호출도 처음부터 후보에서 빠졌다. 품질만 보면 상용 API가 편했겠지만, 데이터가 나가는 순간 요건 위반이다. 대신 로컬 GPU 한 대에 오픈 LLM(qwen 계열)을 올리고, 용어집은 RAG(문서에서 관련 대목을 찾아 프롬프트에 함께 넣어 주는 방식)로 붙여, 전 구성요소가 폐쇄망 안에서만 돌게 만들었다. 외부 CDN이나 클라우드 의존이 하나
