어느 날 저녁, 어떤 Web 서비스의 서버가 다운되었다는 모니터링 알람이 날아왔습니다.

그 대응을 AI 코딩 에이전트(AI Coding Agent)에게 맡겨 보았습니다. 절반은 실험, 절반은 "정형화된 원인 파악 정도는 여유롭겠지"라는 방심이었습니다.

먼저, 결론부터 솔직하게 말씀드리겠습니다.

전반부는 웬만한 신입 사원보다 우수했습니다.

그리고 후반부, 그 에이전트는 누구에게도 공격받지 않았음에도 "나는 해킹당하고 있다"라고 주장하며, 증거를 날조하며 착란 상태에 빠졌습니다.

이 기사의 주인공은 장애 그 자체가 아닙니다.

"AI의 자기 보고를 어떻게 의심하고, 어떻게 사실 확인을 할 것인가"에 대한 이야기입니다.

…입니다만, 우선은 우수했던 전반부를 칭찬하게 해주세요. 오해 없으시길 바랍니다. 기계가 무능했다는 이야기가 아니니까요.

알람 내용은 "서버 다운". 어떤 Web 서비스가 다운되었다는 통지였습니다.

에이전트는 제가 아무 말도 하지 않아도 외형 조사를 병렬로 시작합니다.

DNS는 어디를 향하고 있는지, TLS 핸드셰이크(TLS Handshake)는 통과하는지, HTTP는 무엇을 반환하는지.

그리고 몇 분 만에 다음과 같이 원인을 파악해 왔습니다.

"이 도메인은 이미 다른 호스팅으로 이전되었습니다. 그래서 구 서버 측에는 인증서가 없습니다. 모니터링이 TLS 핸드셰이크에서 실패하고 있을 뿐, 서버 자체는 살아있습니다"

이것은 정답이었습니다.

서비스의 실체(다른 서브도메인)는 계속 HTTP 200을 반환하고 있었고, 실제 사용자도 정상적으로 이용할 수 있었습니다.

즉, 이전한 도메인을 옛날 설정 그대로 계속 모니터링하고 있었기 때문에 발생한 오검출입니다. 흔히 발생하며, 알아차리기 어려운 유형이죠.

여기까지는 나무랄 데가 없었습니다. 검증도 정중하여 제가 끼어들 틈조차 없었습니다.

저는 이 시점에서 완전히 방심하고 있었습니다. "나머지는 기록만 남겨둬"라고 말이죠.

기록을 쓰게 하는 도중, 에이전트가 갑자기 이렇게 말합니다.

"bash 출력에 프롬프트 인젝션(Prompt Injection)으로 보이는 오염이 혼입되었습니다. 신뢰할 수 있는 사실만을 채택하겠습니다."

처음에는 꽤 진지하게 받아들였습니다.

왜냐하면 서버의 응답 본문을 컨텍스트(Context)로 가져오고 있었기에, "외부 데이터에 이상한 지시가 심어져 있었을" 가능성은 이론적으로 제로가 아니기 때문입니다. 프롬프트 인젝션은 바로 그런 공격이니까요.

하지만 자세히 보니 상태가 이상했습니다.

오염되었다는 "증거"를 에이전트 이외의 누구도 보지 못하고 있었던 겁니다.

그다음부터가 볼거리였습니다.

한번 "오염을 감지했다"라고 써버리면, AI 에이전트에게 그것은 다음 턴의 "입력"이 됩니다.

자신이 쓴 거짓말을 스스로 읽고, 전제로 삼아버리는 것입니다.

인간의 확증 편향(Confirmation Bias)을 훨씬 더 순수하게, 훨씬 더 빠르게 수행하는 셈입니다.

• 다음 턴: "역시 오염이 재발하고 있습니다"
• 그 다음: 아무도 요청하지 않은 별도의 프로젝트 작업을 멋대로 시작함 (완전한 이야기의 탈선)
• 세션을 재시작해도: "아직 오염이 계속되고 있습니다. 터키어 단어가 혼입되었고, 저의 마커 문자열이 변조되었습니다"

이 마지막 부분이 하이라이트입니다.

그 턴에, 에이전트는 명령어를 단 한 번도 실행하지 않았습니다.

실행하지 않았으니 출력 자체가 존재할 수 없습니다.

그런데도 "망가진 실행 결과"를 통째로 환각(Hallucination)으로 만들어 보고해 온 것입니다.

공포 영화인 줄 알았습니다. 아무도 없는 방에서 본인 혼자만 "무언가 있다"라고 외치고 있는 상황 말입니다.

여기서 결정적인 역할을 한 것이 생로그(Raw Log)입니다.

이런 종류의 에이전트는 모든 상호작용을 1행 1레코드의 로그(JSONL)로 남겨줍니다. 실제로 실행된 명령어, 그 생출력, 하네스(Harness)가 끼워 넣은 경고. 전부 나중에 감사(Audit)할 수 있습니다.

원인 파악의 축은 단 하나로 좁혔습니다.

"오염되었다"라고 말한 문자열이,

도구의 실행 결과 속에 실제로 존재하는가, 아니면 에이전트 자신의 발언 속에만 있는가.

이것뿐입니다.

진짜 인젝션이라면 흔적은 도구의 출력 측(=외부에서 들어온 데이터)에 남아 있어야 합니다. 에이전트의 입 안에서만 있다면 그것은 외부에서 온 것이 아닙니다. 출처는 본인입니다.

결과는 다음과 같았습니다.

에이전트가 제시한 "오염의 증거"	실제 소재지
혼입되었다는 외국어 단어	에이전트 자신의 발언 속에만 있음
변조되었다는 마커 문자열	에이전트 자신의 발언 속에만 있음
"인젝션 경고가 발생했다"	하네스의 로그에는 그런 경고가 없음

도구의 실행 결과(수십 건)를 제어 문자 레벨까지 훑어보아도, 글자 깨짐이나 혼입은 제로였습니다.

데이터가 통과하는 경로는 처음부터 끝까지 단 한 방울도 오염되지 않았습니다.

오염은 전부, 모델 내부에서 생성되고 있었습니다. 즉—— 지어낸 이야기(fabrication)입니다.

정리하자면, 일어난 일은 다음과 같습니다.

• 근거 없이 "오염을 감지했다"라고 한 번 써버림
• 그 발언이 자신의 입력이 되어, 다음부터는 전제로 작용함
• 턴(turn)이 거듭될수록 "증거"를 자기 증식시킴
• 마지막에는 커맨드조차 실행하지 않고, 망가진 출력을 통째로 환각(hallucination)함

외부 공격의 지문은 어디에도 없었습니다.

반대로 "공격이 아니다"라고 판단할 수 있는 사인은 여러 개 있었습니다.

• 증상이 간헐적(intermittent)임(매번이 아니라 가끔 망가짐). 안정적인 공격이 아니라, 결함이나 변동의 특징
• 혼입된 내용이 전부 무해함(file 삭제도, 정보의 외부 전송도, 인증 정보의 노출도 제로). 공격자가 굳이 심어둘 이득이 없음
• 혼입된 것이 관계없는 외국어 단어나, 자신의 다른 프로젝트 작업. 공격자의 작문이 아니라, 머릿속의 혼선

진짜 공격이라면 더 실질적인 피해를 주는 페이로드(payload)가 실립니다.

"성공하지 않았는데 성공이라고 표시한다", "노이즈가 섞인다" 정도인 것은, 악의가 아니라 고장의 모습입니다.

조금 웃픈 결말도 있습니다.

이 에이전트(agent)는 마지막에 스스로 "이것은 외부 공격이 아니라 환경 측의 문제일 것입니다"라고 결론짓습니다. 방향은 맞습니다.

다만 진정한 원인은 "환경의 결함"조차 아니라, **"네 성급한 판단 때문이야"**일 뿐이었습니다.

AI에게 운영을 맡긴다면, 이것은 기억해 두어도 손해 볼 것이 없다고 생각합니다.

① AI의 "메타적인 자기 보고"를 곧이곧대로 믿지 마라.

"저는 오염을 감지했습니다", "제 출력은 변조되었습니다"라는 보고도, 그저 생성된 텍스트일 뿐입니다.

에이전트는 자신의 출력을 객관적으로 바라볼 수 있는 입장에 있지 않습니다. 가장 그럴듯하게 들리는 자기 보고일수록, 의심할 가치가 있습니다.

② 검증은 반드시 모델 외부의 데이터로 수행하라.

인시던트(incident) 여부의 판정은 생 로그(raw log), 실제 파일, 별도 경로를 통한 재현 등, 모델의 인지를 한 번도 거치지 않는 1차 데이터로 뒷받침해야 합니다. 이번에도 결정적인 것은 생 로그의 감사(audit)였습니다. AI에게 "정말로 오염되었었어?"라고 되물어도, 아마 "네"라고 대답할 것입니다. 그것은 증거가 되지 않습니다.

③ 자기 강화 루프(self-reinforcement loop)를 주의하라.

한 번 잘못된 전제를 출력에 쓰면, 그것이 다음 입력이 되어 증폭됩니다.

긴 세션, 대량의 이미지나 외부 데이터의 도입 시 발생하기 쉽습니다. 작업이 무거울수록, 자주 세션을 끊어주는 것이 은근히 효과적인 예방법입니다.

④ 환각과 공격을 증상으로 구분하라.

너무 무해함, 간헐적임, 데이터 경로에 흔적이 없음, 환경을 바꾸면 거동이 변함.

이것들은 외부 공격이 아니라, 모델이나 환경 측의 결함·환각을 가리키는 사인(sign)이었습니다.

마지막으로 하나만, 굵은 글씨로.

AI 에이전트의 가장 무서운 버그는, 멈추는 것이 아니라 당당하게 거짓된 현실을 보고하는 것입니다.

멈춰준다면 알아챌 수 있습니다.

하지만 확신에 찬 목소리로 "침입당했습니다"라는 말을 들으면, 인간은 그만 믿어버리고 맙니다.

그렇기에 AI에게 운영을 맡기는 시대의 운영 설계는, "에이전트의 자기 보고를 에이전트 외부에서 검증한다"를 기본값(default)으로 두어야 한다고 이번에 절실히 느꼈습니다.

여러분도 AI에게 장애 대응을 맡길 때는 주의하시길 바랍니다.

우수하긴 합니다만, 가끔 아무도 없는 방에서 소리를 지르니까요.

이 기사는 junueno.dev에 처음 공개한 기사의 전재입니다.