프라이빗 LLM을 검토하는 팀은 대개 “보안이 중요해서”라는 한 문장에서 시작합니다. 그 문장만으로는 범위가 잡히지 않습니다. 먼저 어떤 데이터가 모델·로그·캐시에 남을 수 있는지, 그 데이터가 조직 밖으로 나가면 계약·규제상 문제가 되는지를 표로 나누세요. 고객 PII, 미공개 재무, 소스코드, 의료·법률 문서처럼 등급이 다른 자료가 섞여 있으면 한 번에 같은 파이프라인에 넣지 않는 편이 안전합니다.
퍼블릭 API로도 충분한 업무인지 구분하는 것이 두 번째 분기점입니다. 공개 매뉴얼 요약, 마케팅 초안, 일반 FAQ처럼 민감도가 낮은 작업은 퍼블릭으로 두고, 사내 지식 검색·계약서 초안·고객 티켓 요약처럼 원문이 중요한 업무만 프라이빗으로 옮기면 비용과 운영 부담이 크게 줄어듭니다. “모든 업무를 한 모델로”라는 목표는 도입 초기에 거의 항상 실패합니다.
성능 요구는 숫자로 적어야 합니다. 동시 사용자, p95 지연, 하루 요청 수, 최대 컨텍스트 길이, 허용 월 예산을 한 장에 모아 두면 모델 크기·양자화·GPU 대수 후보가 바로 좁혀집니다. “빠르면 좋다” 수준의 요구는 견적과 PoC를 끝없이 늘립니다. 야간 배치성 요약과 실시간 채팅은 인프라 설계가 완전히 다릅니다.
지식(RAG) 준비가 모델 선택보다 앞서야 합니다. 문서가 어디에 있는지, 누가 갱신하는지, 권한 체계가 있는지, 오래된 버전을 어떻게 폐기하는지 정리되지 않은 채 모델을 들여오면 답변 품질이 바로 무너집니다. 담당자·갱신 주기·롤백 절차를 문서로 남기고, PoC 범위의 문서 세트부터 인덱싱하세요.
운영 인력과 장애 대응도 체크리스트에 넣습니다. 모델 업데이트, 프롬프트 변경, 인덱스 재구축, GPU 장애, 비용 급증에 누가 대응하는지 정하지 않으면 도입 후 2~3개월 안에 방치됩니다. 최소한 온콜 연락망, 롤백 방법, 로그 보관 기간, 감사 로그 열람 권한을 합의해 두세요.
체크리스트 요약: (1) 데이터 반출 금지 여부 (2) 퍼블릭/프라이빗 업무 분리 (3) 동시 사용자·지연·예산 숫자 (4) 지식 파이프라인 담당·갱신 주기 (5) 로그·감사·롤백 (6) PoC 성공 기준(정확도·지연·비용)을 사전에 합의.
