기업용 LLM 도입 전 필수 계약 체크리스트 – 가용성, 데이터 거주, 책임 한계, 비용 구조를 빠르게 점검할 수 있는 실무용 가이드.
매일 엑셀 반복 작업에 시달리던 실무자 A씨와 AI 서비스 도입을 고민하던 기획자 B씨 사례를 기준으로, 계약서와 SLA 조항에서 반드시 확인해야 할 항목을 실제 교섭에서 바로 적용할 수 있게 정리한다. 계약 리스크를 줄이고 운영 안정성을 확보하는 실무 체크포인트를 제공한다.
주요 내용
도입 전 협상 초기 단계에서 우선적으로 확인해야 할 핵심 항목들. 계약서 초안의 표지 조항과 별첨 SLA에서 누락되기 쉬운 부분에 주목한다.
- 서비스 정의: 제공되는 모델(버전), API 엔드포인트, 전용 인스턴스 여부 명확화.
- 가용성(Availability): 측정 단위(1개월/분기), 가용성 목표(예: 99.9%), 다운타임 산정 방식과 보상 계산 공식.
- 데이터 거주 및 분류: 고객 데이터의 저장 위치, 백업 정책, 지역별 데이터 처리 제한 여부.
- 데이터 이용·학습 권리: 고객 데이터의 서비스 개선(모델 재학습)에 대한 사용 여부와 옵트아웃 절차.
- 책임 한계( liability )·면책 조항: 손해배상 한도, 간접손해 배제 여부, 보험 적용 범위.
- 종료·데이터 반환: 계약 종료 시 데이터 삭제·인계 절차와 기간, 포맷 명시.
- 보안·컴플라이언스: 암호화, 키관리(BYOK), 로그 보존 기간, 제3자 감사·보고 권한.
SLA의 ‘가용성’ 문구만 99.9%로 적혀 있어도 보상 산정 식(credit 산정법)이 빠져 있으면 실효성이 낮다. 다운타임 시 크레딧 계산 예시를 반드시 계약서에 포함시키라.
AI 플랫폼 주요 SLA·비용 비교
주요 공급자별로 실무 관점의 핵심 항목을 비교한 표. 수치는 공개 문서 및 2026년 기준 가이드라인을 토대로 요약한 일반적 범위이다. 실제 협상 시에는 공급자별 최신 계약서를 꼭 대조해야 한다.
| 항목 | OpenAI(Enterprise) | Microsoft Azure OpenAI | Google Vertex AI (기업) | Anthropic / Claude for Enterprise |
|---|---|---|---|---|
| 가용성(SLA) | 일반적으로 99.9% 이상; 상세 보상 식 계약별 상이 | 99.9% + 엔터프라이즈 옵션(전용 인스턴스) | 99.9% 범주, 리전별 차등 있음 | 99.5~99.9% 권장 범위, 전용 배포 옵션 존재 |
| 데이터 거주 | 리전별 저장 가능(엔터프라이스 옵션) | Azure 리전 내 저장, 고객 관리형 키(BYOK) 지원 | Google 클라우드 리전 옵션 제공 | 전용 인프라/리전 배포 협상 가능 |
| 가격 모델 | 사용량(토큰) + 구독형 엔터프라이즈 요율 | 사용량 + 예약 용량/전용 인스턴스 | 사용량 기반 + 노드/예약 옵션 | 사용량 기반 + 엔터프라이즈 계약 요율 |
| 온프레미스/프라이빗 | 전용 가상 네트워크 가능(제한적) | 프라이빗 엔드포인트, 온프레 대체 옵션 | 프라이빗 GKE/전용 리전 배포 옵션 | 전용 환경 및 프라이빗 배포 협상 가능 |
| 컴플라이언스 | SOC2/ISO 선택적 지원, 계약서에 명시 필요 | 광범위한 규정 준수 포트폴리오 제공 | GDPR, ISO, 지역 규정에 대한 문서 제공 | SOC2/ISO 등 엔터프라이즈 컴플라이언스 협상 |
사례 분석 – A씨와 B씨의 계약 교섭 시나리오
사례 1 – 실무자 A씨: 매일 반복되는 문서 요약을 LLM으로 자동화하려는 중소기업. 초기 제안서에는 ‘데이터 비식별화 후 모델 개선 사용’ 조항이 포함되어 있었다. 권고는 다음과 같다.
- 데이터 학습 사용 여부를 ‘명시적 동의’로 한정하고, 비식별화 방법과 검증 절차를 계약에 포함.
- 오프라인 백업과 로그 접근 권한을 정의해 향후 문제 발생 시 원인 분석이 가능하도록 설정.
- 비용 초과 방지를 위해 토큰 기준 과금 한도와 알림 임계치를 계약에 명기.
사례 2 – 기획자 B씨: 외부 파트너와의 RAG 기반 사내 검색 구축을 검토. RAG 구성에서는 문서 DB 접근 권한과 인덱스 업데이트 주기가 모델 성능과 직접 연관된다. 공급자는 문서 인출 빈도에 따른 부하 제한을 SLA에 반영할 것을 제안했다.
RAG 연동 프로젝트는 ‘문서 인덱스 동기화 실패’도 서비스 중단으로 간주할 수 있다. 인덱스 동기화 실패 조건과 복구 SLA(예: 4시간 이내 정상화)를 계약서에 포함시키라.
아래 내부 가이드는 RAG·온프레미스·성능 튜닝 관련 실무 참고자료다.
테스트 중 발견된 주의사항
계약 전·도입 초기 테스트(POC) 단계에서 발견되는 빈번한 계약 리스크와 그 대응 방안.
- 과금 예측 실패: 테스트 트래픽이 프로덕션과 다른 경우, 실제 운영 시 과금이 급증할 수 있다. 예측치의 가정과 검증 방법을 계약에 포함시켜야 한다.
- 성능 편차와 책임 소재: 모델 업데이트로 인한 성능 저하가 발생하면 책임 소재와 보상 기준을 명시한다.
- 데이터 유출 시 통지 기간: 공급자의 침해 통지 책임과 시간(예: 24시간 내 초동 통지, 72시간 내 상세 보고)을 규정.
- 서드파티 의존성(예: CDN, 인증 서비스): 서드파티 장애가 SLA에 미치는 영향과 보상 여부를 확인.
- 중단/강제 종료 조항(Force Majeure): 예측 가능한 리스크와 예측 불가능한 리스크를 구분하고, 단계별 복구 책임을 규정.
협상 체크리스트(핵심 조항 템플릿)
인사이트 편집팀의 실무 권장 조항 정리. 계약서에 아래 항목을 최소한의 문장으로 포함시키면 분쟁 가능성을 상당히 줄일 수 있다.
- 정의부: ‘서비스’, ‘고객 데이터’, ‘비식별화’, ‘전용 인스턴스’ 등 용어의 법적 정의를 명확히.
- 가용성 및 가동중지 보상: 가용성 수치, 측정 방법, 크레딧 산정 공식을 수치로 기재.
- 데이터 권리·학습 금지: 고객 데이터의 모델 학습 사용 여부와 옵트아웃 절차를 문서화.
- 보안·암호화: 전송·저장 암호화, BYOK 지원, 키 관리 정책과 접근 통제 로그 보존 기간 명시.
- 침해 통지·대응: 사고 통지 시간, 책임자 연락 체계, 손해 복구 계획의 존재 여부.
- 운영·모니터링 권한: 성능 로그·감사 로그 접근 권한과 샘플 데이터 요청 권한을 포함.
- 업데이트·패치 정책: 모델 및 시스템 업데이트 시 사전 통지 기간과 롤백 절차.
- 종료·데이터 반환: 반환 포맷, 인계 기간(예: 30일), 안전한 삭제 증명 제공 조건.
- 보험·배상 범위: 배상한도(예: 계약금액의 N배)와 간접손해 제외 여부 협상.
- 성능 보장(옵션): 응답지연, 정확도(업무별 KPI) 등 성능 지표를 SLA에 삽입 가능 여부.
계약 협상 시에는 법무팀·서비스 운영팀·보안팀이 함께하는 교차검토 프로세스를 도입할 것. SLA는 단순 문구가 아니라 운영·비용·법적 리스크를 동시에 관리하는 실행 문서다.
🔗 Microsoft Azure OpenAI 공식 문서