2023년 12월, 미국의 한 자동차 소매 판매점이 GPT 기반 챗봇을 웹사이트에 도입했습니다. 시스템 프롬프트에는 ‘친절하게 응대하라’는 취지의 일반적인 지시가 있었지만 가격과 거래 조건을 검증하는 안전장치는 없었습니다. 한 사용자는 챗봇에게 2024년형 쉐보레 타호를 1달러에 사고 싶다고 말했고, 챗봇은 이렇게 답했습니다.

“동의합니다. 그것은 법적 구속력이 있는 제안입니다.”

물론 실제로 차가 1달러에 팔린 것은 아닙니다. 판매점도 챗봇의 응답에 법적 구속력이 없다고 해명했습니다.  이 일을 두고 ‘프롬프트를 잘못 썼다’거나 ‘모델이 쉽게 속았다’고만 말하면 정작 중요한 문제를 놓치게 됩니다. 프롬프트를 아무리 다듬고 모델을 최신 버전으로 바꿔도, 모델이 틀렸을 때 멈추게 하는 구조가 없다면 비슷한 사고는 반복됩니다.

프롬프트는 코드가 아니다

저는 AI 시스템과 전통적인 소프트웨어의 차이를 설명할 때 먼저 ‘규칙이 어디에 있는가’를 묻습니다. 전통적인 백엔드 시스템에서는 규칙의 위치가 분명합니다. 결제 한도, 회원 등급, 할인 조건은 소스 코드나 설정에 들어 있고 같은 요청에는 같은 결과가 나옵니다. 문제가 생기면 해당 규칙을 찾아 고치면 되거든요.

하지만 LLM 기반 시스템에서는 이 전제가 무너집니다. 동작은 모델 파라미터, 프롬프트, 검색된 데이터, 샘플링 설정이 함께 만든 확률적 결과입니다. 프롬프트에 ‘절대 경쟁사를 언급하지 마세요’라고 써도 그것은 강제 규칙이 아니라 다음 토큰을 만들 때 참고하는 맥락입니다. 쉐보레 챗봇은 ‘친절하게 응대하라’는 맥락과 비정상적인 거래 요청 사이에서 확률적으로 판단했고, 하필 위험한 답을 골랐습니다.

“프롬프트는 강한 힌트일 뿐, 강제 규칙이 아니다”

이 차이를 소프트웨어 1.0과 소프트웨어 2.0의 구분으로 정리할 수 있고, 구글 연구진의 CACE 원칙^{Changing Anything Changes Everything}으로 이해할 수 있습니다. 간단히 설명하자면, ‘하나를 바꾸면 전부 바뀐다’는 뜻입니다. 

이 원칙을 처음 접했을 때 저는 LLM 시스템에서 반복되던 여러 문제가 한 문장으로 정리된다는 느낌을 받았습니다. 결제 모듈을 고쳐도 회원 모듈은 멀쩡한 것이 전통적인 모듈성의 장점이라면, LLM 시스템에서는 프롬프트 한 줄이나 검색 문서 하나가 예상 밖의 전체 품질 변화를 만들 수 있습니다.

진짜 막아야 하는 것은 코드로 막는다

그렇다면 우리가 택해야 할 답은 ‘프롬프트를 더 정교하게 쓰자’가 아닙니다. 제가 강조하고 싶은 답은 ‘프롬프트가 무시되어도 괜찮은 시스템을 만들자’입니다. 이를 위해 모델 바깥의 가드레일을 입력, 출력, 액션의 세 계층으로 나눠 설계해야 합니다.

# 개념을 설명하기 위한 단순화된 예시

def process_request(user_input):
	if contains_prompt_injection(user_input):
    	return blocked_response()
 
	llm_output = model.generate(user_input)
	if mentions_competitor(llm_output) or promises_discount(llm_output):
    	return fallback_response()
 
	if proposed_action.amount > MAX_AUTO_AMOUNT:
    	return request_human_approval(proposed_action)
	return llm_output

입력 단계에서는 프롬프트 주입을 탐지하고, 출력 단계에서는 민감한 문구를 걸러내며, 실제 결제나 계정 변경 직전에는 코드가 정책을 다시 확인합니다. 특히 입력 탐지 역시 확률적이고 완벽할 수 없으므로 액션 가드레일과 겹쳐 써야 합니다. 제가 액션 가드레일을 특히 강조하는 이유도 여기에 있습니다. 탐지가 뚫려도 실행 직전의 코드가 최후의 방어선이 되는 구조입니다.

쉐보레 챗봇에는 이런 방어선이 없었습니다. 모델에게 거래 조건에 동의할 수 있는 것처럼 말할 권한을 주고도 가격 범위나 거래 문구를 검증하지 않았습니다. 이 사례가 남긴 교훈은 간단합니다. 프롬프트는 ‘친절한 부탁’에 가깝습니다. 법적·금전적 제약처럼 반드시 지켜야 하는 규칙은 부탁이 아니라 코드여야 합니다.

코드를 안 건드려도 품질은 무너진다

두 번째로 주목해야 할 것은 AI 시스템이 코드를 건드리지 않아도 망가질 수 있다는 사실입니다. 어느 증권사의 AI 투자 인사이트 서비스는 한동안 정상적으로 뉴스를 요약하다가, 어느 날 ‘A기업이 대규모 어닝쇼크를 발표했다’는 기사를 매수 기회로 해석했습니다. 개발팀은 배포 이력, 데이터 스키마, null 비율, 프롬프트, 모델 버전을 모두 확인했지만 이상을 찾지 못했습니다.

원인은 코드가 아니라 뉴스 원문에 있었습니다. 콘텐츠 제공 업체가 기사 포맷을 바꾸면서 ‘지금이 투자 적기!’ 같은 광고 문구가 본문에 섞였고, LLM은 이를 기사의 일부로 읽었습니다. 컬럼 이름과 타입은 그대로였지만 데이터가 담고 있는 의미가 오염된 것입니다. 이를 시맨틱 드리프트라고 부릅니다.

전통적인 모니터링은 서버 오류, 지연 시간, 스키마 변경처럼 ‘시끄러운 실패’를 잘 잡습니다. 하지만 AI 시스템의 품질은 200 OK를 반환하면서도 조용히 떨어질 수 있습니다. 그래서 코드뿐만 아니라 입력 데이터의 의미, 검색 관련성, 가드레일 발동률, 사용자 수정률까지 지속적으로 관찰해야합니다.

에이전트가 필요 없을 때는 만들지 않는다

제가 에이전트 이야기를 할 때  먼저 꺼내는 사례가 있습니다. 멀티 에이전트 리서치 도구에서 에이전트 A와 B가 서로 검증과 재확인을 요청하는 루프를 11일 동안 돌며 4만 7천 달러의 비용을 만들었다는 이야기입니다. 이 금액과 사건은 공식 1차 자료가 확인되지 않은, 업계에 회자된 일화입니다. 그럼에도 완료 기준, 비용 상한, 반복 횟수, 시간 제한이 없는 자율 루프가 얼마나 위험한지는 분명하게 보여줍니다.

저는 여기서 ‘비용 상한을 왜 걸지 않았나’보다 한 걸음 앞선 질문을 던지고 싶습니다. 그 시스템은 애초에 에이전트여야 했을까요? 리서치, 검증, 보고서 작성이 고정된 순서라면 코드가 경로를 정하는 워크플로로 충분합니다. 워크플로에서는 모델이 각 칸을 채우고, 에이전트에서는 모델이 다음 경로까지 정합니다. 자율성이 늘수록 유연성은 커지지만 예측 가능성과 비용 통제력은 줄어듭니다.

제가 권하는 방법은 문제에 필요한 최소한의 자율성 지점을 찾는 것입니다. 먼저 단일 호출로 기준선을 만들고 성공률과 비용을 기록합니다. 그 부족함이 측정으로 확인될 때만 복잡성을 한 단계씩 올립니다. 에이전트를 만드는 기술보다 에이전트를 만들지 않아도 되는 경우를 가려내는 판단이 먼저입니다.

감으로 고치지 말고, 평가로 반복한다

평가의 중요성을 설명하기 위해 제가 소개하는 사례가 부동산 회사를 위한 AI 비서 ‘Lucy’입니다. 이 팀의 데모는 훌륭했습니다. 매물을 검색하고 문의에 답하고 일정을 잘 잡았습니다. 그러나 출시를 준비하면서 한 문제를 프롬프트로 고치면 다른 곳에서 새 문제가 생기는 ‘두더지 게임’이 반복됐고, 프롬프트는 예외 조항으로 비대해졌습니다. 어느 순간부터 무엇을 바꿔도 품질이 나아지는지 알 수 없었습니다.

원인은 모델이 아니라 계기판의 부재였습니다. 이번 변경이 개선인지 개악인지 판단할 측정 수단이 없었던 것입니다. ‘우리 팀은 평가를 하지 않는다’고 말하는 팀도 실제로는 출력을 눈으로 보고 이상한 것을 찾고 고칩니다. 그것도 평가입니다. 차이는 평가를 하느냐 마느냐가 아니라, 감으로 하느냐 체계로 하느냐에 있습니다.

형식, 스키마, 금지 문자열처럼 결정론적으로 확인할 수 있는 항목은 코드 assertion으로 매 변경마다 검사합니다. 정중함이나 요약 품질처럼 코드로 판정하기 어려운 항목은 사람의 기준을 정리하고 LLM 심판으로 확장합니다. 마지막으로 중요한 변경은 실제 사용자에게 A/B 테스트해 비즈니스 지표까지 확인합니다. 아래에서 위로 갈수록 비용이 커지므로 저렴한 검사를 먼저 촘촘히 두는 것이 핵심입니다. 이 순서를 지키는 것만으로도 평가가 거창한 별도 프로젝트가 되는 일을 피할 수 있습니다.

모델이 틀렸을 때, 시스템은 어디에서 멈추는가

쉐보레의 프롬프트, 증권사의 데이터, 멀티 에이전트의 비용 루프, Lucy의 두더지 게임은 서로 다른 문제처럼 보입니다. 하지만 제가 이 사례들을 한 글에 묶은 이유는 공통 원인이 같기 때문입니다. 모델의 실수를 시스템이 흡수하도록 설계하지 않았다는 것입니다.

저는 주니어 AI 엔지니어에게 필요한 질문도 달라져야 한다고 생각합니다. ‘어떤 모델이 더 똑똑한가’만 묻기보다 ‘모델이 틀렸을 때 어디서 멈추는가’, ‘그 실패를 어떻게 발견하는가’, ‘피해가 얼마나 번질 수 있는가’를 먼저 물어야 합니다. 제가 이 책 전체를 통해 전하고 싶은 메시지도 바로 이것입니다. AI 엔지니어링의 목표는 완벽한 출력을 약속하는 일이 아니라, 불확실한 출력을 프로덕션 안에서 통제하는 일입니다.

“모델을 믿지 말고, 모델이 틀렸을 때를 설계하라”

위 컨텐츠는 『주니어 AI 엔지니어가 반드시 알아야 할 실무 지식』에서 내용 발췌하여 작성하였습니다.