한줄 요약
정치·규제 리스크로 AI 모델이 갑자기 꺼질 수 있다는 사실이 현실이 됐다.
최근 미국에서 벌어진 한 사건이 AI 기반 서비스를 만들고 운영하는 모든 팀에 경고를 날렸다. 최첨단 LLM이 출시 며칠 만에 정부 지시로 전면 차단된 것이다. 해당 모델을 핵심 기능으로 쓰던 서비스들은 예고 없이 멈췄고, 복구 시점도 불확실했다. 외주 개발로 AI 서비스를 구축한 팀이라면 이 사건을 단순한 해외 이슈로 넘기면 안 된다.
이 사건이 왜 외주 개발 현장에 직접적인 문제인가?
외주로 개발된 AI 서비스 대부분은 특정 API에 강하게 묶여 있다. 챗봇, 문서 요약, 코드 자동화, 추천 엔진, 기능의 중심에 외부 LLM API를 호출하는 구조가 자리한다. 이 구조 자체가 문제는 아니다. 문제는 그 API가 언제든 꺼질 수 있다는 가정을 설계에 반영했느냐다.
개발 단계에서는 "가장 좋은 모델"을 기준으로 아키텍처를 잡는 경우가 많다. 성능 좋은 단일 모델에 의존하는 코드가 서비스 전체에 깔려 있으면, 그 모델이 사라지는 순간 대체재를 꽂는 것조차 수일에서 수주가 걸린다. 외주 개발 완료 후 내부 유지보수 인력이 없는 팀이라면 상황은 더 심각하다.
"모델 교체"가 단순 작업이 아닌 이유
LLM을 교체하는 건 라이브러리 버전 올리는 것과 다르다. 프롬프트 설계, 응답 파싱 로직, 토큰 비용 구조, 컨텍스트 윈도우 크기, 출력 형식, 이 모든 게 모델마다 다르다. 한 모델에 최적화된 프롬프트가 다른 모델에서는 전혀 다른 결과를 낸다.
실제로 외주 개발 현장에서는 특정 모델의 동작 방식에 맞춰 비즈니스 로직 자체를 감아버린 사례도 많다. 이 경우 모델 교체는 부분 리팩토링이 아니라 핵심 기능의 재설계로 이어진다. 개발 비용과 일정이 처음부터 다시 잡힌다는 의미다.
지금 당장 확인해야 할 세 가지
첫째, 서비스의 핵심 기능이 단일 외부 모델 API에 얼마나 깊이 연결돼 있는지 파악해야 한다. 기능별로 의존 지점을 정리하는 것만으로도 리스크의 윤곽이 잡힌다.
둘째, 폴백(fallback) 구조가 있는지 확인한다. 주력 모델이 응답하지 않을 때 보조 모델로 자동 전환되는 로직이 있는지, 혹은 기능을 일시 비활성화하고 사용자에게 안내하는 흐름이라도 있는지 따져봐야 한다.
셋째, 오픈소스 모델이나 온프레미스 배포 옵션을 비상 시나리오로 검토해둘 필요가 있다. 평소에 쓰지 않더라도, "이 기능은 이 오픈소스 모델로도 돌릴 수 있다"는 경로를 알고 있는 것과 모르는 것은 다르다.
