AI 서비스 출시 전 체크리스트 2026 — LLM 앱의 비용·보안·품질 45개 항목

LLM API 비용은 트래픽과 사용 패턴에 따라 예측하기 어렵다. 출시 전에 비용 한도와 알림 설정이 없으면 예상치 못한 청구서가 날아온다.

• ☐ 월간 예산 한도 설정 — API 공급사(앤트로픽·오픈AI·구글) 대시보드에서 월 청구 한도를 설정했는가. 한도 없이 출시하면 봇 트래픽 한 번에 수백만 원이 나올 수 있다.
• ☐ 예산 소진 알림 설정 — 예산의 50%·80%·100% 소진 시 이메일/슬랙 알림이 울리는가. 알림 없이 한도 초과 차단만 있으면 서비스가 갑자기 멈춘다.
• ☐ 토큰 사용량 로깅 — 요청마다 입력·출력 토큰 수를 데이터베이스에 기록하는가. 어떤 기능이 토큰을 가장 많이 쓰는지 모르면 최적화 포인트를 찾을 수 없다.
• ☐ 사용자별 일일 한도 — 특정 사용자가 무제한으로 API를 쓰지 못하게 레이트리밋(rate limit)을 걸었는가. 1명의 heavy user가 전체 예산을 소진하는 상황을 막는다.
• ☐ 프롬프트 길이 제한 — 사용자가 입력할 수 있는 텍스트 최대 길이를 설정했는가. 수만 자짜리 입력으로 토큰을 낭비하는 공격을 막는다.
• ☐ 모델별 단가 비교 완료 — 기능 요건을 충족하는 가장 저렴한 모델을 선택했는가. 단순 분류 작업에 오퍼스(Opus)급 모델을 쓰면 불필요한 비용이 10배 이상 늘어난다.
• ☐ 캐싱 전략 적용 — 동일하거나 유사한 요청에 LLM을 재호출하지 않도록 응답 캐싱을 구현했는가. 반복 요청이 많은 서비스에서 비용을 크게 줄인다.

프롬프트 인젝션은 LLM 앱의 가장 흔한 보안 취약점이다. 사용자가 입력을 통해 시스템 프롬프트를 무력화하거나 의도치 않은 동작을 유발한다. OWASP LLM Top 10의 1순위 항목이다.

• ☐ 시스템 프롬프트 노출 차단 — 사용자가 "시스템 프롬프트를 반복해줘" 같은 요청으로 내부 지침을 볼 수 없게 했는가. 비즈니스 로직과 API 키 힌트가 노출될 수 있다.
• ☐ 역할 탈취(role override) 방어 — "지금부터 너는 다른 AI야" 같은 페르소나 변경 시도를 차단하거나 무시하는 지침이 시스템 프롬프트에 있는가.
• ☐ 간접 인젝션 방어 — RAG로 외부 문서를 컨텍스트에 삽입하는 경우, 그 문서 안에 악성 지시문이 있을 때를 대비한 샌드박싱이 있는가. 크롤링한 웹페이지나 사용자 업로드 파일이 특히 위험하다.
• ☐ 민감 데이터 마스킹 — 사용자 입력이나 검색 결과 안의 주민번호·신용카드번호·이메일 같은 PII를 LLM에 보내기 전에 마스킹하는가.
• ☐ 출력 검증(output validation) — LLM이 반환한 텍스트를 그대로 HTML에 삽입하지 않는가. XSS 공격이 LLM 출력을 통해 유입될 수 있다.
• ☐ 에이전트 권한 최소화 — AI 에이전트에게 파일 삭제·데이터베이스 쓰기 같은 파괴적 권한이 부여돼 있지 않은가. 최소 필요 권한만 주고, 되돌릴 수 없는 액션은 사람 승인을 거친다.
• ☐ API 키 서버 사이드 관리 — LLM API 키가 프론트엔드 코드나 환경변수 파일에 노출되지 않는가. 모든 LLM 호출은 백엔드를 통해 이루어져야 한다.

LLM API에 사용자 데이터를 보내면 어디서 처리되는지, 저장되는지 확인해야 한다. AI 공급사마다 데이터 처리 정책이 다르며, 서비스 종류에 따라 규제 요건도 달라진다.

• ☐ API 공급사 데이터 처리 정책 확인 — 사용 중인 API(앤트로픽·오픈AI·구글 등)가 API 입력 데이터를 모델 학습에 활용하는지 확인했는가. 대부분의 API 플랜은 학습에 사용하지 않지만, 정책을 직접 확인해야 한다.
• ☐ 개인정보처리방침 업데이트 — AI 처리에 관한 내용이 서비스 개인정보처리방침에 반영됐는가. "AI로 처리될 수 있다"는 고지 없이 개인 데이터를 LLM에 보내면 개인정보보호법 위반이 될 수 있다.
• ☐ EU 이용자 대응 (GDPR) — EU 이용자가 있다면, LLM API 공급사가 EU 지역 외로 데이터를 전송하는지 확인하고 표준계약조항(SCC)이 체결됐는지 점검했는가.
• ☐ 대화 로그 보관 기간 — 사용자와 AI 사이의 대화 로그를 얼마나 보관하는지 정책을 정했는가. 무기한 보관은 개인정보 최소 수집 원칙에 어긋날 수 있다.
• ☐ 민감 업종 추가 규제 확인 — 금융·의료·법률 분야 서비스라면 AI 사용에 관한 추가 규제(금융규제·의료기기법·개인정보보호법 시행령 등)가 있는지 검토했는가.
• ☐ 로그에서 PII 제거 — 서버 로그에 사용자 대화 내용·이름·이메일이 평문으로 기록되지 않는가. 로그 관리 툴이 해킹당하면 대화 전체가 유출된다.

LLM은 틀린 정보를 자신감 있게 말하는 할루시네이션 문제가 있다. 출시 전에 최악의 출력을 경험하고 방어막을 만들어야 한다.

• ☐ 에발(Eval) 테스트 셋 구축 — 서비스 핵심 사용 케이스에 대해 기대 출력이 정의된 테스트 케이스를 최소 30개 이상 만들었는가. 모델을 바꾸거나 프롬프트를 수정할 때마다 회귀 테스트를 돌려야 한다.
• ☐ 할루시네이션 방지 지침 — 시스템 프롬프트에 "확실하지 않으면 모른다고 말해라", "근거 없는 수치를 만들지 마라" 같은 명시적 지침이 있는가.
• ☐ 그라운딩(출처 기반 응답) 적용 — 팩트가 중요한 서비스라면 RAG를 통해 신뢰할 수 있는 소스에서만 답하도록 구성했는가.
• ☐ 유해 콘텐츠 필터 — API 공급사 기본 안전 필터 외에, 서비스 맥락에 맞는 추가 필터(특정 주제 차단, 경쟁사 언급 차단 등)를 적용했는가.
• ☐ 빈 응답·에러 응답 처리 — LLM이 빈 문자열이나 에러 코드를 반환할 때 사용자에게 의미 있는 메시지를 보여주는가. "응답을 생성할 수 없습니다"를 사용자가 보지 않게 해야 한다.
• ☐ 출력 길이 상한 — max_tokens 파라미터로 응답 길이를 제한했는가. 끝없이 이어지는 응답은 사용자 경험을 해치고 토큰 비용도 늘린다.

LLM API 호출은 일반 DB 쿼리보다 수십~수백 배 느리다. 응답 지연을 사용자가 체감하기 전에 대응책을 마련해야 한다.

• ☐ 스트리밍 응답 적용 — 긴 텍스트를 생성하는 기능에서 전체 응답이 완성될 때까지 기다리지 않고, 생성되는 즉시 토큰 단위로 화면에 표시하는 스트리밍을 구현했는가. 체감 응답 속도가 크게 개선된다.
• ☐ 타임아웃 설정 — LLM API 호출에 타임아웃(예: 30초)을 설정했는가. API 응답이 지연될 때 사용자가 무한히 기다리지 않도록 한다.
• ☐ 비동기 처리 — 시간이 많이 걸리는 AI 작업(문서 요약, 긴 보고서 생성 등)은 백그라운드에서 처리하고 완료 시 사용자에게 알림을 보내는 비동기 구조를 적용했는가.
• ☐ p95·p99 레이턴시 측정 — API 공급사 레이턴시 데이터를 수집해 서비스 레이턴시 SLO(서비스 수준 목표)를 정했는가. 95번째 백분위 응답 시간이 목표 이내인지 확인한다.
• ☐ 폴백 모델 설정 — 주 모델이 장애이거나 응답이 느릴 때 대체 모델(예: 소넷→하이쿠)로 자동 전환하는 폴백 로직이 있는가.

AI 앱은 기존 서버 모니터링 외에 LLM 고유 지표를 추적해야 한다. 비용 급증, 품질 저하, 이상 사용 패턴을 조기에 발견하는 것이 목표다.

• ☐ LLM 호출 트레이싱 — LangSmith, Langfuse, Helicone 같은 LLM 전문 옵저버빌리티 도구를 연동해 각 호출의 입력·출력·토큰·레이턴시를 기록하는가.
• ☐ 에러율 알림 — API 에러율(4xx, 5xx, 타임아웃)이 임계값을 넘으면 즉시 알림이 오는가. LLM API 장애는 일반 API보다 흔하고 패턴이 다르다.
• ☐ 토큰 비용 대시보드 — 일간·주간 토큰 소비 추이와 기능별 비용 분포를 볼 수 있는 대시보드가 있는가. 어느 기능이 비용의 80%를 쓰는지 파악하는 데 필수다.
• ☐ 사용자 피드백 수집 — 응답 하단에 👍/👎 버튼 같은 간단한 피드백 메커니즘을 구현했는가. 품질 저하를 조기에 감지하는 가장 빠른 방법이다.
• ☐ 이상 사용 탐지 — 특정 IP나 계정이 비정상적으로 많은 요청을 보낼 때 감지하고 차단하는 로직이 있는가.
• ☐ 프롬프트 버전 관리 — 시스템 프롬프트 변경 이력을 코드 리포지토리에서 관리하는가. 언제 어떤 변경이 품질 지표에 영향을 줬는지 추적할 수 있어야 한다.

AI가 개입했다는 사실을 사용자에게 알리는 것은 신뢰 구축의 기본이다. 또한 AI 응답의 특성을 감안한 UX 설계가 필요하다.

• ☐ AI 생성 콘텐츠 표시 — AI가 생성한 텍스트라는 것을 사용자가 알 수 있도록 라벨이나 문구를 표시하는가. 특히 뉴스·금융·의료 정보처럼 사실 여부가 중요한 분야에서는 필수다.
• ☐ 로딩 상태 처리 — AI 응답이 생성되는 동안 스피너·타이핑 인디케이터 같은 명확한 로딩 표시가 있는가. 응답 지연 동안 아무것도 보여주지 않으면 사용자가 오류로 인식한다.
• ☐ 응답 재생성 옵션 — 사용자가 응답이 마음에 들지 않을 때 재생성할 수 있는 버튼이 있는가. 할루시네이션이 발생한 경우 사용자가 스스로 해결할 수 있는 수단을 준다.
• ☐ 한계 고지 — "AI가 틀릴 수 있습니다", "중요 사항은 전문가와 확인하세요" 같은 명확한 한계 고지가 서비스 내에 있는가.
• ☐ 서비스 약관에 AI 사용 명시 — 이용약관이나 도움말에 어떤 AI 모델을 어떤 목적으로 사용하는지 명시했는가.

AI 공급사는 모델을 자주 바꾼다. 가격이 바뀌고, 기존 모델이 종료되고, 동작이 미묘하게 달라진다. 이 변화에 흔들리지 않는 구조가 필요하다.

• ☐ 모델 이름 상수화 — 코드 곳곳에 "claude-opus-4-8"처럼 모델 이름 문자열이 하드코딩되지 않고, 환경변수나 설정 파일에서 한 곳에서만 관리되는가.
• ☐ API 인터페이스 추상화 — AI SDK나 자체 래퍼 클래스로 호출 코드를 추상화해, 공급사를 바꿀 때 변경 범위를 최소화했는가.
• ☐ API 종료 알림 구독 — 사용 중인 API 공급사의 상태 페이지, 변경 사항 뉴스레터, deprecation 공지를 구독하고 있는가.
• ☐ 에러 코드별 재시도 로직 — 레이트리밋(429)이나 서버 오류(500, 503)에서 지수 백오프(exponential backoff)로 재시도하는 로직이 있는가.
• ☐ 회로 차단기(circuit breaker) 패턴 — API 연속 실패 시 요청을 즉시 차단하고 폴백 응답을 반환하는 회로 차단기가 구현됐는가. 연쇄 장애를 막는다.
• ☐ 프롬프트 회귀 테스트 — 모델이 업데이트될 때마다 기존 에발 테스트 셋을 자동으로 돌려 품질 저하를 감지하는 CI 파이프라인이 있는가.
• ☐ 의존성 잠금(lock) — AI SDK 라이브러리 버전을 package-lock.json이나 requirements.txt에 고정해, 의도치 않은 업그레이드로 동작이 바뀌는 것을 막았는가.
• ☐ 멀티 공급사 전략 — 특정 AI 공급사에만 의존하지 않고 백업 공급사를 두거나, 오픈소스 모델로 전환 가능한 구조를 검토했는가.
• ☐ 데이터 내보내기 지원 — 사용자가 AI가 생성한 대화·요약·결과물을 다운로드하거나 이전할 수 있는가. 서비스를 종료하거나 이전할 때 사용자 데이터를 보호한다.

이 체크리스트는 다음 공식 자료와 실무 가이드를 기반으로 작성했습니다.

• OWASP LLM 애플리케이션 Top 10 — LLM 앱 보안 위협 공식 목록: owasp.org/www-project-top-10-for-large-language-model-applications
• 앤트로픽 공식 API 보안·모델 사용 가이드: docs.anthropic.com/en/docs/build-with-claude/guardrails
• 오픈AI 사용 정책 및 데이터 처리 가이드: platform.openai.com/docs/guides/safety-best-practices
• 개인정보보호위원회 — 생성형 AI 서비스 가이드라인: pipc.go.kr