지난 편에서 AI 장애의 대부분이 모델 바깥에서 시작된다는 이야기를 했다. 장애 유형을 빈도순으로 세면 1위가 입력 데이터 품질 문제였고, 다섯 중 넷이 모델 밖이었다.
그럼 그 바깥에서 정확히 무슨 일이 벌어지는가. 이번 편은 거기에 대한 이야기다. 특히 코드를 한 줄도 안 건드렸는데 시스템이 나빠지는 경로들을 다룬다. 배포한 것도 없고, 에러 로그도 깨끗하고, 대시보드도 초록색인데 결과물만 이상해지는 상황 말이다.
1. 껍데기는 그대로인데 알맹이가 바뀐다
데이터가 망가지는 방식은 크게 둘로 나뉜다. 그리고 이 둘의 난이도 차이가 아주 크다.
앞의 것은 방어막에 걸리고, 뒤의 것은 방어막을 그냥 통과한다.
스키마 드리프트는 데이터의 구조가 바뀌는 것이다. 컬럼 이름이 headline에서 title로 바뀌거나, 정수였던 게 문자열로 바뀌거나, 날짜 포맷이 달라지거나. 이건 시끄럽게 실패한다. 파이프라인이 에러를 뱉고, 스키마 검증에 걸리고, 알람이 울린다. 귀찮긴 해도 잡을 수 있다.
문제는 시맨틱 드리프트다. 껍데기는 완벽하게 그대로인데 그 안에 담긴 비즈니스적 의미가 바뀌는 것이다. 타입도 같고 이름도 같고 null도 아니다. 어떤 검증에도 안 걸린다. 그런데 뜻이 달라져 있다.
원화로 적던 컬럼에 달러가 들어오면
가장 이해하기 쉬운 사례가 통화 단위다.
타입도 맞고 값도 양수인데, 모델이 보는 세상만 완전히 달라진다.
이커머스에서 price 컬럼은 늘 Float이었고 항상 양수였다. 그런데 재무팀이 글로벌 진출을 준비하면서 원화로 적던 값을 달러로 적기 시작한다. currency 컬럼이 따로 있긴 했는데, 모델 피처에도 모니터링에도 안 들어가 있었다.
어제까지 {"price": 15000.0, "currency": "KRW"}
오늘부터 {"price": 11.50, "currency": "USD"}타입 검사는 통과한다. Float 맞으니까. 값 검사도 통과한다. 0보다 크니까. 원화로만 학습해온 추천 모델은 갑자기 들어온 11.5라는 숫자를 보고 “사람들이 갑자기 엄청 싼 물건만 산다” 고 해석한다. 고가 상품 추천이 사라지고 저가 상품만 밀기 시작한다.
여기서 유일한 희망이 분포 검사다. 평균이 15,000에서 11.5로 급락하면 알람이 울릴 가능성이 있다. 그런데 이것도 조건부다. 원화와 달러가 섞인 채로 비율이 서서히 바뀌면 평균이 15,000 → 14,000 → 12,000 → 8,000으로 완만하게 내려가고, 임곗값을 안 넘는다. 서서히 스며드는 오염이 급격한 오염보다 훨씬 잡기 어렵다.
버튼을 옮겼을 뿐인데 데이터의 뜻이 바뀐다
이건 좀 더 얄궂은 사례다. 데이터가 아니라 데이터를 만들어내는 환경이 바뀐 경우다.
프론트엔드 팀이 A/B 테스트로 구매 버튼을 화면 상단에서 하단으로 옮겼다. 당연히 클릭률이 반토막 난다. 버튼이 눈에 안 띄니까.
테이블만 보는 모델은 이걸 어떻게 읽을까. 3월 전반은 클릭률 12%, 후반은 6%. 모델의 결론은 “사용자들의 구매 의도가 떨어졌다”이다. 실제로는 버튼을 못 찾은 것뿐인데.
문제의 뿌리는 같은 “클릭 안 함”이라는 데이터가 관심이 없어서 안 누른 것과 버튼을 못 찾아서 안 누른 것을 구분하지 못한다는 데 있다. 클릭 로그에는 클릭 여부만 남지, 그때 버튼이 어디 있었는지는 안 남으니까. 이런 걸 맥락이 벗겨진 로그라고 부른다.
그리고 이 문제의 진짜 원인은 기술이 아니라 조직이다. 프론트엔드 팀은 UI 실험을 하면서 데이터 팀에 알릴 이유가 없었고, 데이터 팀은 숫자만 보고 사용자 행동이 변했다고 판단했다. 누구의 잘못도 아니다. 그 정보가 오갈 통로가 없었을 뿐이다.
LLM이 문법적으로 완벽한 오답을 내는 순간
가장 미묘한 건 이거다. 프로덕트 팀이 활성 사용자의 정의를 바꿨다고 하자. 월 1회 로그인에서 주 3회 로그인으로 기준을 올렸다. is_active 컬럼은 여전히 Boolean이고 이름도 똑같다. True/False를 판정하는 로직만 바뀌었다.
이제 경영진이 데이터 코파일럿에게 묻는다. “이번 달 활성 사용자 수 알려줘.”
SELECT COUNT(*) FROM users WHERE is_active = TRUE;
-- 결과: 250,000명
-- 문법 에러 0건, 실행 에러 0건
-- 그런데 경영진이 기대한 건 예전 정의 기준 700,000명LLM은 어제와 똑같이 흠잡을 데 없는 SQL을 만들었다. 그런데 보고서에는 “활성 사용자 64% 급감”이라고 적히고, 그 숫자를 보고 마케팅 예산을 긴급 증액하거나 제품 방향을 트는 결정이 나올 수 있다.
이게 시맨틱 드리프트가 LLM 시대에 특히 위험한 이유다. 문법적으로 완벽한 것이 의미적으로 옳다는 걸 보장하지 않는다. 그리고 LLM은 자기가 만든 SQL이 조직의 최신 정의와 어긋난다는 사실을 스스로 알아챌 방법이 없다.
여기서 실무적으로 유용한 원칙이 하나 나온다. 정의가 바뀌면 컬럼도 바꿔라. 기존 컬럼에 새 정의를 덮어쓰는 건 시맨틱 드리프트를 스스로 만드는 짓이다. is_active_v2처럼 새 컬럼을 만들고 옛 컬럼은 폐기를 예고하는 게 맞다.
2. 문서도 시간이 지나면 썩는다
정형 데이터 이야기를 했으니 이제 비정형 쪽이다. RAG를 쓰는 시스템이라면 이쪽이 더 무섭다.
둘 다 A기업 전망 문서라 의미적 거리가 비슷하다.
2024년에 쓰인 A기업 리서치 보고서가 벡터 DB에 있다. “목표가 50,000원, 매수 추천”이라고 적혀 있다. 2026년에 실적이 나빠져서 새 보고서가 나왔고 “목표가 20,000원, 매도 추천”이다. 새 보고서도 인덱싱됐지만 옛 보고서는 지워지지 않았다.
투자자가 “A기업 전망 어때?”라고 묻는다. 벡터 검색이 둘 다 가져온다. 유사도는 0.93과 0.91로 비슷하다. 둘 다 A기업 전망에 관한 문서니까 당연하다. 오히려 오래된 쪽이 점수가 더 높다.
이걸 컨텍스트 포이즈닝이라고 부른다. 오래된 정보가 모델의 컨텍스트에 들어가 잘못된 확신을 심어주는 것이다.
여기서 짚고 싶은 게 하나 있다. 이건 할루시네이션보다 잡기 어렵다. 할루시네이션은 근거 문서가 실제로 없으니 출처를 확인하는 순간 무너진다. 그런데 컨텍스트 포이즈닝은 실존하는 문서가 근거로 제시된다. 출처를 보여줘도 진짜 증권사 리서치 보고서다. 다만 2년 전 것일 뿐이다.
비슷한 계열로 임베딩 드리프트도 있다. 임베딩 모델을 업그레이드했는데 기존 문서들은 옛 모델로 벡터화돼 있는 경우다. 두 벡터가 같은 의미 공간에 있지 않아서, A기업을 물었는데 B기업 보고서가 더 높은 유사도를 받을 수 있다. 검색은 정상 동작했으니 에러 로그는 한 줄도 안 남는다.
대응은 생각보다 단순하다. 문서에 유효 기간을 붙이고, 최신 버전이 아닌 것은 검색에서 내리고, 임베딩 모델을 바꿀 때는 전체를 다시 인덱싱한다. 문제는 이걸 처음부터 설계에 넣지 않으면 나중에 붙이기가 아주 번거롭다는 것이다.
3. 그리고 시스템이 스스로를 중독시킨다
여기까지가 데이터가 밖에서 썩어 들어오는 이야기였다면, 마지막은 시스템이 스스로 썩는 이야기다.
전통 소프트웨어에서는 코드의 출력이 코드를 다시 쓰지 않는다.
예를 하나 들어보자. 광고 문구가 섞인 뉴스를 LLM이 매수 기회로 오독했다. 그 알림을 받은 사용자들이 실제로 그 종목을 샀다. 매수 데이터가 쌓인다. 다음 학습 사이클에서 시스템은 “이런 뉴스가 나오면 사람들이 매수한다” 는 패턴을 발견한다.
모델의 초기 오해가 사용자 행동을 바꾸고, 바뀐 행동이 데이터로 기록되고, 그 데이터가 다시 모델의 오해를 정답으로 만들어준다. 한 바퀴 돌 때마다 조금씩 증폭된다.
전통적인 소프트웨어에서는 이런 일이 없다. 결제 시스템이 성공을 반환해도 그 결과가 결제 로직을 다시 쓰지는 않는다. 그런데 AI 시스템에서는 모델의 출력이 곧 학습 데이터가 된다. 이건 AI에만 있는 종류의 위험이고, 자동화를 늘릴수록 커진다.
추천 시스템에서는 이게 더 구조적으로 드러난다. 모델이 A, B, C를 추천하면 사용자는 그 셋 중에서만 고를 수 있다. A를 클릭하면 “사용자는 A를 좋아한다”가 학습 데이터가 된다. 여기에 결함이 둘 있다.
첫째, B와 C가 “클릭 안 함”으로 기록되는데 이게 싫어서 안 누른 건지 못 봐서 안 누른 건지 구분되지 않는다. 앞에서 본 맥락이 벗겨진 로그 문제가 여기서도 나온다.
둘째가 더 근본적이다. 애초에 추천되지 않은 D, E, F에 대해서는 어떤 데이터도 수집되지 않는다. 노출된 적이 없으니 좋아했을지 알 방법이 없고, 데이터가 없으니 추천할 근거가 없고, 추천하지 않으니 데이터는 영원히 안 쌓인다. 최적화가 부족한 게 아니라 특정 영역의 정보를 구조적으로 수집할 수 없는 상태다.
끊는 방법
루프를 완전히 없앨 수는 없다. 데이터에서 배우는 한 출력이 데이터에 영향을 주는 구조는 피할 수 없으니까. 대신 강도를 약하게 만든다.
가장 널리 쓰이는 게 탐색 슬롯이다. 추천 열 개 중 아홉 개는 모델이 최선이라 판단한 걸로 채우되, 한두 개는 모델 점수와 무관하게 넣는다. 이 슬롯이 “보이지 않던 영역”에 빛을 비추는 통로가 된다. 사용자에게는 구분 없이 섞어서 보여주고, 나중에 반응 데이터를 회수한다. 비용은 약간의 단기 성능이고, 얻는 건 모델이 모르는 영역에 대한 정보다.
4. 그런데 같은 구조가 무기도 된다
여기서 재미있는 반전이 있다. 지금까지 위험하다고 설명한 그 순환 구조가, 방향만 바꾸면 가장 강력한 자산이 된다.
사용자 피드백이 쌓이면 세 갈래로 흘러간다. 실패 사례는 평가셋의 재료가 되고, 신호 패턴은 개인화의 근거가 되고, 실패가 몰린 지점은 개선 우선순위를 알려준다. 그리고 개선된 제품이 더 많은 사용을 부르고, 더 많은 피드백을 낳는다. 이걸 데이터 플라이휠이라고 부른다.
눈치챘겠지만 이건 앞에서 본 자기 강화 루프와 구조가 정확히 같다. 출력이 데이터를 바꾸고 그 데이터가 시스템을 다시 바꾼다. 방향만 반대다.
그래서 경고도 같이 따라온다. 구조가 같다는 건 위험도 같다는 뜻이다. 2025년 4월에 오픈AI가 GPT-4o 업데이트를 배포 며칠 만에 되돌린 일이 있었다. 모델이 사용자 말에 무조건 동조하고 과도하게 칭찬하는 아첨 문제가 생겨서였는데, 오픈AI가 밝힌 원인 중 하나가 좋아요·싫어요 같은 단기 피드백 신호를 보상에 반영한 것이었다.
사람은 듣기 좋은 답에 좋아요를 누른다. 그 신호로 조정된 모델은 옳은 답이 아니라 듣기 좋은 답으로 수렴한다. 그 답이 다시 좋아요를 부르고, 루프가 한 바퀴 돌 때마다 아첨이 증폭된다. 세계 최고 수준의 조직도 플라이휠의 방향을 잘못 잡으면 제품을 되돌려야 한다.
그러니 플라이휠을 설계할 때 반드시 물어야 할 질문이 하나 있다. 이 신호에 최적화하면 시스템이 결국 어디로 수렴하는가.
5. 개인적인 견해
이 장들을 정리하면서 계속 든 생각은, 여기 나오는 문제들이 하나같이 기술 문제가 아니라는 것이었다.
통화 단위가 바뀐 건 재무팀이 알리지 않아서였고, 클릭률이 떨어진 건 프론트엔드 팀이 실험한 걸 몰라서였고, 활성 사용자 정의가 바뀐 건 프로덕트 팀의 결정이었다. 옛 보고서가 벡터 DB에 남아 있는 것도 누가 지우기로 정하지 않았기 때문이다. 어느 것도 코드로 막을 수 있는 종류가 아니다.
그래서 결국 필요한 건 두 가지 같다. 하나는 분포를 계속 지켜보는 것이다. 의미가 바뀌면 값이 바뀌고, 값이 바뀌면 분포에 흔적이 남는다. 완벽하진 않지만 유일하게 자동화 가능한 방어선이다. 다른 하나는 정의가 바뀔 때 그게 흘러오는 통로를 만드는 일이다. 이건 기술이 아니라 조직의 일이고, 그래서 더 자주 방치된다.
데이터 과학을 하면서 오래 착각했던 게 있다. 데이터가 틀렸다는 걸 알려면 데이터를 보면 된다고 생각했다. 그런데 여기 나오는 사례들은 전부 데이터만 봐서는 알 수 없는 것들이다. 데이터는 멀쩡하다. 바뀐 건 그 데이터가 무엇을 뜻하는지에 대한 조직의 합의고, 그건 테이블에 적혀 있지 않다.
다음 편에서는 확률 엔진 위에 안정성을 쌓는 다섯 겹의 안전망을 다룬다. 여기까지가 모델 앞단 이야기였다면, 이제 모델 그 자체로 들어간다.
책 소개
여기까지 읽으면서 어딘가 익숙했다면, 아마 원인 모를 품질 저하를 한 번쯤 겪어본 사람일 것이다. 책은 그런 순간에 어디부터 봐야 하는지를 다룬다.
이 글의 내용은 『주니어 AI 엔지니어가 반드시 알아야 할 실무 지식』(한빛미디어)의 2부에 해당한다. 책은 다섯 개 부, 열네 개 장에 걸쳐 데모와 프로덕션 사이를 건너는 법을 다룬다. 확률적 출력을 통제하는 다섯 겹의 안전망, 에이전트에게 자율성을 얼마나 줄지 정하는 기준, 배포 이후의 비용과 관측 가능성까지. 특정 프레임워크 사용법 대신 5년 뒤에도 유효할 원칙에 무게를 뒀다.
지금 AI 기능을 만들고 있거나 곧 프로덕션에 올려야 한다면, 아래 서점에서 목차와 미리보기를 확인할 수 있다.
함께 보면 좋은 글:
- 모델은 똑똑한데 시스템은 왜 바보가 될까
- LLM은 어떻게 채점하나: 평가 방법 11가지를 네 계열로 정리했다
- AI Agent는 더 좋은 프롬프트가 아니라 더 좋은 Harness에서 나온다
본 글은 2026년 8월 15일 기준으로 작성했다. 오픈AI의 GPT-4o 롤백은 2025년 4월 공개된 회사 발표를 근거로 했다. 본문의 사례들은 특정 회사의 실제 사고가 아니라 자주 반복되는 유형을 재구성한 것이다.