온프레미스란 무엇인가: 문서를 밖으로 내보내지 않고 AI를 쓰는 방법 완전 정리

온프레미스(On-Premise)란, 외부 사업자의 클라우드가 아니라 고객사가 직접 관리하는 내부 서버에 모델과 시스템을 설치해 운영함으로써 처리 대상 데이터가 조직 경계를 벗어나지 않도록 구성하는 방식입니다.

온프레미스가 요건이 되는 이유

문서를 보낼 수 없는 조직이 있습니다.

클라우드 서비스가 일반화되면서 대부분의 소프트웨어 도입 논의는 어떤 서비스를 쓸지에서 시작합니다. 그런데 금융과 공공에서는 그 앞에 다른 질문이 놓입니다. 이 문서를 밖으로 내보낼 수 있는가 하는 질문입니다. 여신 심사 서류에는 개인의 소득과 계좌 정보가 담기고, 피해 구제 신청서에는 피해자의 신원과 사건 내용이 담깁니다. 이런 문서를 외부 서버로 전송하는 구성은 내부 규정과 감독 규정 양쪽에서 걸립니다.

그래서 이들 조직에서 온프레미스는 여러 선택지 가운데 하나가 아니라 통과해야 하는 요건입니다. 성능이 아무리 좋아도 내부 설치가 불가능한 솔루션은 검토 목록에서 먼저 빠집니다. 도입 검토의 첫 관문이 기술 평가가 아니라 배포 방식 확인인 이유입니다.

온프레미스의 정확한 정의: 클라우드 방식과 무엇이 다른가

클라우드 방식과 온프레미스, 세 가지 축의 차이

첫째, 대상이 다릅니다. 클라우드 방식에서 고객사가 관리하는 것은 요청과 응답의 규격뿐입니다. 온프레미스에서는 서버와 가속기, 컨테이너 환경, 저장소, 접근 권한까지 고객사의 관리 범위에 들어옵니다. 관리할 것이 늘어나는 대신 통제할 수 있는 범위도 그만큼 넓어집니다.

둘째, 목표가 다릅니다. 클라우드 방식의 목표는 빠르게 붙여 쓰는 것입니다. 온프레미스의 목표는 데이터를 내보내지 않으면서 운영 규모의 처리량을 안정적으로 감당하는 것입니다. 앞의 방식이 도입 속도를 우선한다면 뒤의 방식은 통제 가능성을 우선합니다.

셋째, 성과지표가 다릅니다. 클라우드 방식은 응답 시간과 처리량 한도를 봅니다. 온프레미스는 여기에 더해 폐쇄망 설치 가능 여부, 필요한 가속기 사양, 모델 갱신 절차, 감사 로그 요건, 장애 대응 체계를 함께 봅니다. 실제 구성에서는 추론과 문서 처리 전 과정이 내부망에서 수행되고, 권한 관리와 처리 이력 기록, 운영 환경과 검수 환경의 분리가 함께 제공됩니다.

두 방식은 대체 관계가 아닙니다. 초기 검증은 외부 호출로 빠르게 진행하고 운영 단계에서 내부 설치로 옮기는 경로가 흔합니다. 그래서 검토 시점에 확인해야 할 것은 지금 쓰는 방식이 아니라 같은 엔진으로 두 방식을 모두 제공하는지 여부입니다.

도입을 결정하기 전에 확인할 온프레미스의 5가지 요건

실제 구축에 들어가는 온프레미스의 5가지 요건

첫째, 폐쇄망에서 설치가 완결되어야 합니다. 설치 과정에서 외부 저장소에 접속해 구성 요소를 내려받는 구조라면 인터넷이 차단된 환경에서 작업이 멈춥니다. 필요한 이미지와 모델 가중치를 반입 매체로 옮겨 설치할 수 있는지 확인이 필요합니다.

둘째, 필요한 가속기 사양이 명확해야 합니다. 시각언어모델 기반 처리는 연산량이 크기 때문에 가속기 없이는 실용적인 속도가 나오지 않습니다. 월 처리량과 피크 시간대의 집중도를 기준으로 필요한 규모를 산정하고, 증설 경로를 함께 확인해 두는 편이 좋습니다.

셋째, 모델 갱신 절차가 통제 가능해야 합니다. 외부 모델은 사업자 판단으로 갱신되어 성능이 예고 없이 바뀝니다. 내부 설치에서는 새 버전을 검증한 뒤 승인 절차를 거쳐 반영하고 필요하면 이전 버전으로 되돌릴 수 있어야 합니다.

넷째, 감사 대응 요건을 충족해야 합니다. 누가 어떤 문서를 언제 처리했고 어떤 값이 수정되었는지가 기록으로 남아야 합니다. 역할별 접근 제어와 처리 이력 보관은 금융과 공공 감사에서 반복적으로 요구되는 항목입니다.

다섯째, 운영 인력의 부담을 계산해야 합니다. 내부 설치는 고객사가 서버와 컨테이너 환경을 함께 안고 가는 방식입니다. 모니터링 도구와 장애 알림, 정기 점검 절차가 함께 제공되는지, 공급사의 원격 지원 범위가 어디까지인지를 계약 전에 정리해 두시기 바랍니다.

온프레미스의 실제 적용 방법

배포 구조를 계층으로 나눕니다

설치 설계는 기능을 계층으로 나누는 데서 시작합니다. 문서를 받는 응용 계층, 인식과 구조화를 수행하는 모델 계층, 결과와 원본을 보관하는 데이터 계층, 업무 시스템과 연결하는 연계 계층으로 구분해 두면 이후 증설과 교체가 수월합니다.

실제 구성에서는 컨테이너 기반으로 각 계층을 배치하고, 가속기 자원은 모델 계층에만 할당하는 방식이 일반적입니다. 관계형 데이터베이스에 처리 이력과 결과 메타데이터를 두고, 원본 파일은 객체 저장소에 두며, 작업 대기열과 캐시를 별도로 운영하는 구성이 널리 쓰입니다.

검수와 운영 환경을 분리합니다

내부 설치의 장점은 데이터가 나가지 않는다는 데만 있지 않습니다. 검수 환경을 운영 환경과 분리해 둘 수 있다는 점도 실무에서는 큽니다. 새로운 서식이 들어왔을 때 검수 환경에서 추출 기준을 먼저 시험하고, 결과를 확인한 뒤 승인 절차를 거쳐 운영에 반영하는 흐름을 만들 수 있습니다.

이 구조가 갖춰지면 운영 중 변경이 사고로 이어지는 위험이 줄어듭니다. 반대로 두 환경을 나누지 않으면 서식 하나를 추가할 때마다 운영 성능이 흔들릴 여지가 생깁니다.

국내 환경에서의 온프레미스

국내에서 온프레미스 요건을 만드는 가장 직접적인 규정은 망분리입니다. 업무망과 인터넷망이 분리되어 있으면 외부 API 호출 자체가 차단되므로, 내부 설치 외에 다른 선택지가 없습니다.

금융권에서는 전자금융감독규정과 금융보안원의 가이드라인에 맞춘 구성이 요구됩니다. 공공에서는 기관별 보안 지침과 개인정보 처리 기준이 추가로 적용됩니다. 두 영역 모두 개인정보의 국외 이전이 사실상 불가능하다는 점이 공통 조건입니다.

한 가지 더 고려할 것은 국산 문서 형식입니다. 폐쇄망 안에서 한글 워드프로세서 문서를 변환하려면 관련 처리 구성 요소도 함께 내부에 설치되어야 합니다. 이 부분이 빠지면 설치는 끝났는데 실제 접수 문서를 열지 못하는 상황이 생깁니다.

자주 묻는 질문