외부 LLM vs 온프레미스 LLM — 비용·보안·성능 3축 비교

01질문이 잘못됐습니다

"우리는 외부 API를 쓸까, 사내에 모델을 세울까?" — 이 질문으로 시작하면 회의는 결론 없이 끝납니다. 보안팀은 온프레미스를, 재무는 외부 API를, 개발팀은 품질을 이유로 외부를 밀고, 각자 옳기 때문입니다.

질문을 바꿔야 합니다. "어떤 데이터를 어느 모델로 보낼 것인가." 전사 단일 선택이 아니라 데이터 등급별 배분 문제로 놓는 순간, 세 부서의 요구가 동시에 충족됩니다.

023축 비교

표에서 가장 중요한 줄은 '사내 맥락 이해' 입니다. 양쪽 모두 '낮음'입니다. 사내 데이터를 아는 AI를 원한다면 필요한 건 모델 선택이 아니라 RAG(검색 증강 생성) 이며, 이건 외부·사내 어느 쪽을 골라도 똑같이 별도로 만들어야 합니다. 모델 논쟁에 3개월을 쓰고 정작 지식 파이프라인을 안 만드는 것이 가장 흔한 실패입니다.

03손익분기는 어디인가

온프레미스가 비용 면에서 유리해지는 지점은 두 변수로 결정됩니다.

• 호출량 — 전사 일상 사용(요약·검색·초안)은 생각보다 토큰을 많이 씁니다. 사용자가 늘수록 외부 API 비용은 선형으로 증가하지만, 온프레미스는 증가하지 않습니다.
• 상각 기간 — GPU 서버를 3년으로 상각한다고 보고 월 환산 비용을 계산해, 같은 기간 예상 API 청구액과 비교합니다.

실무적 결론은 이렇습니다.

소수 인원의 실험 단계 → 외부 API가 압도적으로 합리적입니다. 사내 GPU를 먼저 사는 건 낭비입니다.

전사 상시 사용 + 민감 데이터 포함 → 온프레미스가 비용·리스크 양쪽에서 유리해집니다.

주의할 함정은 "온프레미스는 공짜" 라는 착시입니다. 하드웨어 값보다 운영 인건비가 더 큽니다. 모델 업데이트, 장애 대응, 성능 튜닝을 누가 맡을지 정하지 않은 온프레미스 계획은 6개월 뒤 방치됩니다.

04정답: 하이브리드 라우팅

둘을 고르는 대신, 분류 라벨을 기준으로 호출 경로를 자동으로 가르는 층을 하나 두십시오.

이 구조의 장점은 세 가지입니다.

• 비용 — 트래픽의 대부분을 차지하는 일반 업무 질의는 외부 API로 처리해 GPU 투자 규모를 줄입니다.
• 보안 — 민감 데이터는 물리적으로 나가지 않습니다. 정책이 아니라 코드로 강제됩니다.
• 전환 가능성 — 나중에 사내 모델 성능이 올라가면 라우팅 비율만 조정하면 됩니다. 애플리케이션을 다시 만들 필요가 없습니다.

05컴키의 구현

컴키는 이 라우팅을 제품 기본 동작으로 넣었습니다.

• 일지·문서마다 [경영] / [리더] / [일반] 정보 분류가 붙고, LLM 호출 레이어가 분류를 보고 목적지를 결정합니다.
• [경영]·인사·급여 데이터는 외부로 나가지 않는 것을 넘어 임베딩 생성 자체를 하지 않습니다. 벡터 형태의 간접 유출까지 차단하기 위해서입니다.
• 사내 모델은 온프레미스 Qwen 계열을 연동해 사용하며, 환경설정에서 외부/사내 전환이 가능합니다.
• 모든 호출은 사용량 로그로 집계되어, 어느 경로로 얼마나 쓰였는지 관리자 화면에서 확인됩니다.

06자주 묻는 질문