금요일 오후 6시, 운영 중인 고객 지원 챗봇에서 에러가 쏟아진다. 재시도 로직이 돌아가지만 소용없다. 뉴스를 열면 개인정보보호위원회 공지가 보인다. 사용 중이던 AI 서비스가 방금 국내 제공이 중단됐다. 결정해야 한다 — 지금 당장, 그리고 이 일이 다시 일어났을 때.
개인정보보호위원회는 2025년 2월 15일 18시부터 DeepSeek의 국내 앱 서비스를 중단시켰다. 사용자 입력 프롬프트와 기기 정보를 베이징볼케이노엔진 등 제3자에게 무단 전송한 개인정보 보호법 위반이 근거였다. 조사 착수부터 집행까지 수 주를 넘지 않았다.
정부 AI 차단은 왜 하루아침에 일어나는가
정부가 AI 서비스를 차단할 때 사전 예고 기간을 주지 않는 이유는 구조적이다. 개인정보 보호법 집행의 경우, 위반 사실이 확인되는 순간 즉각 행정처분이 가능하다. 법원 영장 없이도 서비스 제공을 멈출 수 있기 때문에, 기업 입장에서는 뉴스가 나오는 날이 곧 D-day다.
이탈리아 개인정보보호기관 Garante는 2025년 1월 30일 GDPR 위반을 이유로 DeepSeek의 이탈리아 사용자 데이터 처리를 영구 제한하고 Apple·Google 앱스토어에서 앱을 삭제시켰다. 아일랜드·벨기에도 자체 조사를 개시했다. 호주는 같은 달 ‘용납할 수 없는 위험’을 이유로 모든 정부 기기에서 DeepSeek를 금지했고, 대만도 정보보안을 근거로 공공기관 사용을 막았다.
반복되는 차단 근거는 세 가지로 수렴한다. 개인정보 국외 무단 이전, 안보 위험, 각국 개인정보보호법 위반. 이 세 가지가 겹치면 집행 속도는 더욱 빨라진다.
한국은 2026년 1월 22일 AI 기본법을 시행해 EU에 이어 포괄적 AI 규제 법체계를 갖춘 두 번째 국가가 됐다. 채용·의료·금융 등 10개 분야 ‘고영향 AI’ 사업자에게는 위험 관리 체계 수립과 신뢰성 확보 조치가 의무화됐다. 이제 “우리는 AI를 쓰는 기업”이라는 사실 자체가 규제 대상 자격이 된다.
단일 벤더 의존이 위험한 건 이 맥락에서다. AI 모델 하나에 파이프라인 전체를 묶어두면, 그 벤더가 차단될 때 서비스도 함께 멈춘다. 단일 벤더 직접 호출은 곧 단일 장애점이다.
차단 발생 즉시: 골든타임 72시간 행동 체크리스트
차단 확인 직후 72시간이 대응 품질을 결정한다. 다음 체크리스트는 순서대로 실행한다.
0–6시간: 피해 범위 파악
영향받는 서비스·파이프라인·사내 워크플로를 전수 목록화한다. “AI 쓰는 기능 다 찾기”는 이 타이밍에 하기엔 늦다. Notion·스프레드시트에 빈 표를 열고 사용 중인 모델명, 엔드포인트 URL, 호출 빈도, 담당 팀을 한 줄씩 채운다. API 키가 어디에 하드코딩되어 있는지 grep -r "api.deepseek\|DEEPSEEK_API" . 로 전체 레포를 훑는다.
Tier 분류를 즉시 적용한다. 매출 직결(Tier 1), 내부 업무 효율(Tier 2), 실험(Tier 3). Tier 1 목록이 최우선 복구 대상이다.
6–24시간: 임시 대체 가동
Tier 1 파이프라인부터 수동 대체 절차를 가동한다. AI 없이 돌아가는 최소 기능(degraded mode)을 활성화하고, 고객에게는 “일부 기능이 일시적으로 제한됩니다”라는 공식 커뮤니케이션을 내보낸다. 경영진 보고는 원인·영향 범위·복구 예상 일정을 담은 슬라이드 1장으로 간결하게 준비한다.
차단 사유 공문을 개인정보보호위원회 홈페이지 공지를 통해 확인한다. 공식 사유를 알아야 법적 대응 방향이 잡힌다.
24–72시간: 예비 벤더로 절체
사전에 발급해 둔 예비 벤더 API 키로 접속 테스트를 완료하고 Tier 1 파이프라인을 전환한다. 아직 예비 벤더 API 키가 없다면 지금 즉시 발급 신청하되, 심사에 하루 이상 걸릴 수 있으므로 Tier 2·3는 수동 운영으로 버틴다.
전환 후 핵심 지표(응답 정확도·지연시간·에러율)를 기존 기준값과 비교해 회귀 여부를 확인한다. 개인정보보호위원회 가이던스를 검토하고 준수 계획을 문서화해 내부 보관한다.
멀티벤더 아키텍처: Primary·Secondary·Fallback 3단계 설계
사후 대응보다 중요한 건 사전 설계다. 핵심은 추상화 레이어 하나를 두어 벤더 교체 범위를 환경변수 한 줄로 줄이는 것이다.
# 라우터 패턴 — 벤더 교체 시 LLM_BACKEND 값만 바꾼다
ACTIVE_BACKEND = os.environ.get("LLM_BACKEND", "openai")
def call_llm(prompt: str, **kwargs) -> str:
if ACTIVE_BACKEND == "anthropic":
return _call_anthropic(prompt, **kwargs)
elif ACTIVE_BACKEND == "gemini":
return _call_gemini(prompt, **kwargs)
elif ACTIVE_BACKEND == "local":
return _call_ollama(prompt, **kwargs)
return _call_openai(prompt, **kwargs)이 패턴 하나만 있으면 긴급 차단 시 LLM_BACKEND=anthropic 한 줄로 전체 파이프라인이 넘어간다. 전제는 각 벤더의 입출력 스펙을 래퍼 안에서 정규화하는 것이다.
Primary/Secondary 선정 기준
- 한국어 성능: 벤더마다 편차가 크다. 실제 업무 프롬프트로 A/B 테스트를 돌린 결과를 기준으로 삼는다.
- 데이터 처리 지역: 개인정보보호법상 국외 이전 계약 없이 특정 지역으로 데이터를 보내면 그 자체가 차단 사유가 된다. 각 벤더의 데이터 센터 위치와 계약 조건을 반드시 확인한다.
- API 스펙 호환성: OpenAI 호환 API를 제공하는 벤더는 마이그레이션 공수가 적다. 독자 스펙을 쓰는 벤더는 래퍼 개발 비용을 추가로 산정한다.
- 단가: 토큰당 비용은 벤더마다 수 배 차이가 난다. 현재 월 토큰 사용량에 각 벤더 단가를 대입해 예산 영향을 미리 계산해 둔다.
Fallback: 로컬 LLM
인터넷 접속 자체가 차단되는 시나리오까지 대비한다면 Ollama나 vLLM 자체 배포가 최후 방어선이다. ollama run llama3 한 줄로 로컬 추론이 가능하고, 라우터의 "local" 분기가 이 엔드포인트를 가리키게 한다. 품질은 클라우드 대비 낮지만, 완전히 멈추는 것보다는 낫다.
헬스체크·자동 절체 루프
def get_active_backend() -> str:
primary = os.environ.get("LLM_PRIMARY", "openai")
secondary = os.environ.get("LLM_SECONDARY", "anthropic")
if health_check(primary):
return primary
notify_slack(f"⚠️ {primary} 헬스체크 실패, {secondary}로 자동 절체")
return secondary이 루프가 갖춰지면 차단·장애 발생 시 사람이 개입하기 전에 트래픽이 Secondary로 넘어간다.
주요 대체 벤더 전환 실현 가능성 비교
차단 상황에서 바로 꺼낼 수 있는 대체 후보는 현실적으로 네 군데다.
OpenAI (GPT 계열): REST API 스펙이 사실상 업계 표준이 됐다. 대부분의 래퍼 라이브러리가 이 스펙 기준이므로 마이그레이션 공수가 가장 적다. 데이터는 미국에서 처리되며, DPA를 별도로 체결하면 GDPR 준수가 가능하다.
Anthropic Claude: 긴 컨텍스트 처리와 지시 따르기 정확도에서 강점이 있다. API 스펙은 OpenAI와 유사하게 설계되어 있어 래퍼 수정이 크지 않다. 데이터는 AWS 미국·EU 리전에서 처리된다. 한국어 추론 품질은 일반적으로 상위권에 속한다.
Google Gemini: GCP 인프라 위에서 동작하며 구글 Workspace 연동이 필요한 기업에 유리하다. API 스펙이 OpenAI와 달라 래퍼 개발이 필요하다. 이미지+텍스트 혼합 파이프라인이 있다면 우선 검토 대상이다.
Mistral: 유럽 기반 벤더로 데이터가 EU 리전에 머문다. 오픈 가중치 모델을 직접 배포하는 옵션도 있어 규제 리스크를 원천 차단하는 데 유리하다. 한국어 성능은 다른 대형 벤더 대비 열위일 수 있으므로 실제 테스트가 필요하다.
업무 유형별 1순위 기준: 장문 한국어 요약·보고서 생성은 컨텍스트 창이 크고 한국어 품질이 높은 쪽을, 코드 생성·SQL은 API 스펙 호환성이 높은 쪽을, GDPR·개인정보 민감 데이터 처리는 데이터 처리 지역이 명확한 유럽 벤더를 우선한다.
연속성 플랜 실전 수립: 6단계 템플릿
1단계. 인벤토리 작성
다음 칼럼을 기준으로 스프레드시트를 만든다.
| 서비스명 | 벤더 | 모델 | 엔드포인트 | 담당팀 | 월 토큰량 | Tier |
|---|---|---|---|---|---|---|
| 고객지원 챗봇 | DeepSeek | deepseek-chat | api.deepseek.com/v1 | CS팀 | 50M | 1 |
| 코드 리뷰 봇 | OpenAI | gpt-4o | api.openai.com/v1 | 개발팀 | 10M | 2 |
이 표가 없으면 차단 직후 0–6시간을 피해 범위 파악에 통째로 잡아먹힌다.
2단계. 중요도 분류
- Tier 1: 차단 즉시 매출·고객 대응에 직접 영향. 72시간 내 복구 목표.
- Tier 2: 내부 업무 효율. 1주일 내 복구 목표.
- Tier 3: 실험·프로토타입. 복구 일정 유연.
분류 기준을 팀 내에서 명시적으로 합의해 두어야 한다. 위기 상황에서 “이게 Tier 1이냐 2냐”를 논쟁할 시간이 없다.
3단계. 전환 트리거 정의
- 차단 확인 채널: 개인정보보호위원회 공지, 벤더 공식 상태 페이지, Slack
#ai-ops채널 - 의사결정권자: CTO 또는 지정 대리인 1인
- 승인 없이 즉시 절체 가능한 조건: 헬스체크 연속 3회 실패 OR 공식 차단 공지 확인
이 조건을 미리 써 두면 의사결정권자가 자리를 비운 상황에서도 담당자가 혼자 판단하고 실행할 수 있다.
4단계. 전환 드릴 (분기 1회)
실제로 LLM_BACKEND=secondary 로 환경변수를 바꾸고 Tier 1 파이프라인을 Secondary 벤더로 돌려본다. 확인 항목은 세 가지다. 응답 지연시간이 SLA 범위 안에 드는지, 기존 골든셋 30개 케이스 기준으로 출력 품질 회귀가 있는지, LLM_BACKEND=primary 복원까지 걸리는 시간. 드릴을 안 한 플랜은 실전에서 반드시 구멍이 발견된다.
5단계. RTO/RPO 목표 합의
- RTO (Recovery Time Objective): 서비스 중단 허용 시간. Tier 1은 4시간, Tier 2는 24시간처럼 팀이 명시적으로 합의한다.
- RPO (Recovery Point Objective): AI 파이프라인의 경우 대부분 무상태(stateless)이므로 RPO=0이 일반적이나, 파인튜닝 데이터·프롬프트 버전은 별도로 백업 정책을 정한다.
6단계. 정기 검토
플랜의 오너를 1인 지정하고, 다음 트리거 중 하나가 발생하면 플랜을 갱신한다. 신규 주력 벤더 등장 또는 기존 벤더 단종·요금 대폭 변경, AI 기본법·개인정보보호법 시행령 개정, 분기 드릴 결과 RTO 미달. “연 1회”로 고정하는 것보다 트리거 기반으로 관리하는 편이 실용적이다.
한국 AI 기본법·개인정보보호법 준수 체크포인트
벤더를 전환할 때 법적 의무도 함께 점검해야 한다. 놓치면 전환 자체가 새 위반 사유가 된다.
고영향 AI 해당 여부 자가진단
AI 기본법이 지정한 10개 고영향 분야는 채용·교육·의료·금융·신용평가·주거·사법·보험·공공서비스·복지다. 자사 AI가 이 중 하나에서 사람의 권리·이익에 영향을 미치는 결정을 보조한다면 고영향 AI 사업자에 해당한다. 해당한다면 위험 관리 체계 수립, 신뢰성 확보 조치, 영향 평가 기록이 의무다.
국외 이전 계약 갱신
벤더를 바꾸면 개인정보를 처리하는 주체가 바뀐다. 기존 개인정보 처리 위탁 계약서(DPA)는 구 벤더 기준이므로, 신규 벤더와 표준계약(SCC) 또는 바인딩 기업 규칙(BCR) 기반 계약을 새로 체결해야 한다. 이를 생략하면 국외 이전 근거가 없어져 개인정보보호법 위반이 된다. 계약서 검토에 법무팀 최소 3–5 영업일이 필요하므로 72시간 기술 대응과 병렬로 진행해야 한다.
침해·차단 발생 후 신고 의무
개인정보보호법상 개인정보 침해 사고는 인지 후 72시간 이내에 개인정보보호위원회에 신고해야 한다. 제출 서류는 침해 사실 개요, 영향받은 정보주체 수와 항목, 즉각 조치 내용, 재발 방지 계획이다. 정부 차단 자체가 침해 사고는 아니지만, 차단 원인이 된 무단 이전 사실이 자사 서비스에도 해당한다면 신고 의무가 발생할 수 있다.
멀티벤더 환경의 위탁 계약서 관리
벤더가 2개 이상이면 처리 위탁 계약서도 벤더별로 각각 체결해야 한다. 한 계약서에 여러 벤더를 묶는 방식은 각 벤더의 처리 범위·보안 조건이 달라 법적 효력이 불명확해진다. 스프레드시트에 벤더별 계약서 만료일을 함께 관리하면 갱신 누락을 방지할 수 있다.
자주 묻는 질문
Q. DeepSeek 외에 다른 AI 모델도 갑작스럽게 차단될 수 있나요?
충분히 가능하다. 2025년 초 DeepSeek 사태 이후 추가 대형 차단 사례가 아직 공식화되지는 않았지만, 한국 AI 기본법 시행·EU AI Act 적용 확대·각국 개인정보 집행 강화가 맞물리면서 규제 환경은 오히려 더 엄격해지는 방향이다. 미국에서는 정부 기기 대상 DeepSeek 금지 법안(H.R.1121)이 발의됐으나 연방 법률로는 아직 통과되지 않은 상태고, 개별 기관 차원에서 자체 차단이 이루어지고 있다. 중국·러시아 계열 서버에 데이터를 보내는 벤더는 안보 기관의 추가 심사 대상이 될 가능성이 있다.
Q. 멀티벤더 구성을 갖추면 비용이 많이 늘어나지 않나요?
Secondary 벤더는 실제로 호출이 발생하지 않는 한 추가 비용이 없다. API 키 발급 자체는 무료이고, 분기 드릴 때 소량의 테스트 호출 비용만 발생한다. 라우터 레이어를 코드로 추가하는 초기 개발 공수가 통상 1–3일 정도다. 이 공수를 아끼다가 실제 차단 시 수 일간 Tier 1 서비스가 중단되는 것과 비교하면 답이 나온다.
Q. 차단 전에 해당 벤더와 맺은 계약과 선불 크레딧은 어떻게 되나요?
정부 행정처분으로 서비스가 중단된 경우, 계약서의 불가항력(Force Majeure) 조항이 적용되는지 먼저 확인해야 한다. 선불 결제 크레딧이 있다면 환불 또는 유예 가능 여부를 벤더에 공식 문의해 서면으로 받아두는 것이 좋다. 차단이 벤더의 법 위반에서 비롯됐다면 손해배상을 검토할 수 있으나, 국외 기업 대상 집행은 현실적으로 어렵다.
Q. 로컬 LLM(Ollama, vLLM)은 어떤 조직에 적합한가요?
인터넷 망 분리가 필수인 금융·공공 기관, 개인정보 국외 이전 자체를 허용하지 않는 내부 정책을 가진 대기업, 기밀성이 극도로 요구되는 연구소 등에 적합하다. GPU 서버 구축 및 운영 비용이 수반되므로 클라우드 API 비용과 비교해 손익분기를 먼저 계산해야 한다. Ollama는 개발·테스트 환경에, vLLM은 프로덕션 고처리량 환경에 더 적합한 선택이다.