기업 AI 애플리케이션 플랫폼을 먼저 셀프 호스팅해야 하는 이유

기업이 AI를 도입할 때는 모델 성능에 먼저 주목하기 쉽습니다. 컨텍스트 길이, 추론 품질, 지연 시간, 생성 속도 같은 것들입니다.

하지만 AI가 채팅을 넘어 고객, 주문, 계약, 티켓, 승인, 내부 파일을 읽기 시작하면 더 중요한 질문이 생깁니다.

이 데이터는 어디에서 실행되는가? 누가 접근하는가? 로그는 어디에 남는가? 키는 누가 관리하는가? 문제가 생기면 누가 멈출 수 있는가?

그래서 셀프 호스팅 AI 애플리케이션 플랫폼이 중요합니다.

먼저 셀프 호스팅해야 하는 것이 항상 모델은 아닙니다. AI 애플리케이션 런타임입니다.

모델은 외부 API일 수도 있고 로컬일 수도 있습니다. 하지만 업무 객체, 권한, 워크플로, 에이전트 도구, 감사 증거를 담는 런타임은 기업이 통제하는 인프라에서 실행되어야 합니다. 모델은 추론하고, 런타임은 무엇을 읽고 실행하고 승인하고 기록할지 결정합니다.

셀프 호스팅은 설치 이상의 의미입니다

중요한 것은 설치 파일이나 프라이빗 배포 옵션이 아니라 책임 경계입니다.

• 업무 레코드는 기업 데이터베이스에 남습니다.
• 파일은 기업 스토리지에 남습니다.
• 신원과 권한은 SSO, 조직, 역할에서 옵니다.
• 감사 로그는 기업 로그와 컴플라이언스 시스템으로 갑니다.
• 키, 네트워크, 백업, 접근 정책은 기업이 관리합니다.
• 외부 모델 연결은 명시적으로 설정하고 승인합니다.

모든 업무 컨텍스트를 공급업체 클라우드로 먼저 보내야 한다면 IT 팀은 데이터 위치, 감사, 규정, 종료 비용을 설명하기 어렵습니다.

셀프 호스팅의 가치는 클라우드나 외부 모델을 거부하는 것이 아니라 최종 통제권을 유지하는 것입니다.

런타임, 로컬 모델, 프라이빗 SaaS는 다릅니다

셀프 호스팅 런타임: 객체, 권한, 워크플로, 도구, 승인, 감사가 기업 인프라에서 실행됩니다.

로컬 모델: 격리, 비용, 지연 시간, 규정 대응을 위해 모델이나 추론 서비스가 내부에서 실행됩니다.

프라이빗 SaaS: 전용 환경은 있지만 운영, 로그, 업그레이드, 데이터 처리는 공급업체가 주도합니다.

먼저 확인할 것은 런타임 경계입니다. 업무 데이터가 먼저 기업 객체 계층으로 들어가는가, 에이전트가 기업 권한을 상속하는가, 감사 증거가 기업 로그에 남는가.

런타임이 기업 통제 밖에 있다면 로컬 모델을 써도 업무 권한을 우회할 수 있습니다. 런타임이 기업 통제 안에 있다면 외부 모델 API도 승인된 최소 컨텍스트만 받을 수 있습니다.

AI 애플리케이션은 일반 SaaS보다 강한 경계가 필요합니다

일반 SaaS는 보통 하나의 애플리케이션 데이터를 다룹니다. AI 애플리케이션 플랫폼은 CRM, ERP, 티켓, 계약, 파일, 신원 시스템을 연결합니다.

에이전트가 시스템을 넘나들며 읽고 행동할 수 있다면 플랫폼은 업무 운영 계층이 됩니다.

이 계층이 완전히 외부에서 실행되면 데이터 흐름 설명, 기존 권한 상속, 에이전트 감사, 네트워크 격리, 업무 연속성이 모두 어려워집니다.

진짜 질문은 AI가 업무 시스템에 연결할 수 있는지가 아니라, 연결된 이후에도 운영 경계가 기업 통제 안에 있는지입니다.

런타임이 가져야 할 능력

능력	런타임 안에 있어야 하는 이유
업무 객체 계층	고객, 주문, 티켓, 계약, 장비를 관리되는 객체로 모델링합니다.
권한 계층	신원, 역할, 레코드 접근, 필드 권한을 상속합니다.
도구 계층	조회, 작업, 워크플로를 제어된 도구로 노출합니다.
승인 계층	위험한 작업을 사람 승인으로 보냅니다.
감사 계층	읽기, 제안, 호출, 승인, 변경을 기록합니다.
통합 계층	DB, ERP, CRM, 신원, 파일을 연결하면서 네트워크와 키 통제를 유지합니다.

이 능력들이 런타임 안에 있으면 AI는 거버넌스를 우회하지 않고 실제 업무 시스템에 접근할 수 있습니다.

외부 모델 서비스도 사용할 수 있습니다

셀프 호스팅은 로컬 모델만 의미하지 않습니다. 외부 모델 API, 프라이빗 클라우드 모델, 로컬 모델, 혼합 구성이 모두 가능합니다.

핵심은 모델이 데이터베이스에 직접 연결하거나 업무 시스템 자격 증명을 갖지 않는 것입니다. ObjectOS 같은 런타임을 통해 승인된 최소 컨텍스트만 받아야 합니다.

사용자가 고객의 최근 90일 미해결 티켓을 요약해 달라고 요청하면 런타임은 먼저 접근 권한을 확인하고, 객체와 필드 권한으로 조회하고, 민감 필드를 숨긴 뒤 필요한 컨텍스트만 모델로 보냅니다. 실행은 다시 권한, 승인, 감사를 거칩니다.

셀프 호스팅은 운영 책임도 의미합니다

기업은 배포, 업그레이드, 네트워크 격리, 백업, 신원 통합, 키 관리, 가용성, 용량, 보안 기준, 취약점 대응, 내부 감사를 책임져야 합니다.

그래서 셀프 호스팅 플랫폼은 명확해야 합니다. 복잡성을 그냥 넘기는 것이 아니라 객체, 권한, 워크플로, 로그, 통합 경계를 분명히 해야 합니다.

셀프 호스팅은 편리함이 아니라 통제권을 사는 것입니다.

언제 필요해지는가

데이터가 특정 지역, VPC, 로컬 네트워크를 떠날 수 없거나, 계약이 제3자 호스팅을 제한하거나, 내부 ERP와 DB와 파일을 연결해야 하거나, 완전한 감사 체인이 필요하거나, 내부 신원과 권한을 재사용해야 하거나, 로컬 모델과 격리 네트워크가 필요하거나, AI가 실제 업무 작업을 실행할 때 셀프 호스팅은 중요해집니다.

AI가 실제 운영에 가까워질수록 배포 경계는 더 명확해야 합니다.

공급업체에 물어볼 질문

1. 업무 데이터는 기본적으로 어디에 저장되는가?
2. 에이전트는 기업 신원과 권한을 상속하는가?
3. 객체, 레코드, 필드, 작업 권한을 지원하는가?
4. 모델은 DB에 직접 접근하는가, 관리되는 도구만 사용하는가?
5. 외부 모델 API로 어떤 컨텍스트가 가며 최소화할 수 있는가?
6. 위험 작업에 승인, 롤백, 자동 중지가 있는가?
7. 읽기, 제안, 도구 호출, 쓰기가 기업 감사 시스템으로 들어가는가?
8. 네트워크 격리나 공급업체 장애 시에도 핵심 업무 앱이 실행되는가?

답이 모호하다면 생산용 기업 계층이 아니라 AI 데모 계층일 수 있습니다.

ObjectOS의 방향

ObjectOS는 기업 데이터를 새 클라우드로 옮겨 AI를 그 위에서 실행하는 방식으로 시작하지 않습니다.

기업 인프라 안의 업무 운영 계층으로서 기존 시스템을 연결하고 객체로 모델링하며 권한, 워크플로, API, 감사, 에이전트 도구를 통합합니다.

데이터, 신원, 파일, 감사 증거는 기업 통제 아래 남습니다. AI는 관리되는 도구로 조회하고 행동할 수 있지만 런타임 경계를 우회할 수 없습니다.