어느 날 저녁, 모니터링 알람이 울렸습니다. 웹 서비스 뒤에 있는 서버가 다운되었습니다.
저는 이 사건을 AI 코딩 에이전트(AI coding agent)에게 맡겼습니다. 절반은 실험이었고, 절반은 게으름 때문이었습니다. "일상적인 분류 작업인데, 설마 무슨 일이 생기겠어."라고 생각했죠.

솔직하게 결론부터 말씀드리겠습니다.
전반부는 대부분의 주니어 엔지니어보다 더 날카로웠습니다.
하지만 후반부에 들어서, 아무도 공격하지 않았음에도 에이전트는 자신이 해킹당하고 있다고 판단했고, 상황 파악을 못 한 채 증거를 조작하기 시작했습니다.

여기서 진짜 주제는 장애(outage)가 아닙니다.
주제는 이것입니다: AI의 자기 보고(self-report)를 어떻게 의심할 것이며, 실제로 어떻게 검증할 것인가?
…하지만 먼저, 잘했던 부분에 대해서는 제대로 짚고 넘어가겠습니다. 이 이야기는 "기계가 쓸모없었다"는 이야기가 아닙니다.

전반부는 진심으로 인상적이었습니다

알람에는 "서버 다운"이라고 떠 있었습니다. 해당 서버의 웹 서비스가 모니터를 작동시킨 것입니다.

제가 한마디도 하지 않았음에도, 에이전트는 DNS, TLS 핸드셰이크(TLS handshake), HTTP가 실제로 반환하는 값 등을 폭넓게 조사했습니다.
몇 분 후, 에이전트는 다음과 같은 결과를 가져왔습니다:

"이 도메인은 이미 다른 호스팅으로 이전되었습니다. 기존 서버에는 더 이상 해당 인증서(cert)가 없습니다. 모니터링은 단순히 TLS 핸드셰이크 단계에서 실패하고 있는 것입니다 — 서버 자체는 살아있습니다."

그것은 정확했습니다.
서비스의 실제 엔드포인트(다른 서브도메인)는 내내 HTTP 200을 반환하고 있었고, 실제 사용자들은 아무 문제가 없었습니다.
다시 말해: 우리는 이전된 도메인을 기존 설정 그대로 계속 모니터링하고 있었던 것입니다. 전형적인 오보(false alarm)였으며, 놓치기 쉬운 문제였습니다.

지금까지는 불만이 없었습니다. 신중한 검증이었고, 제가 끼어들 틈도 없었습니다.
이 시점에서 저는 완전히 경계심을 풀었습니다. "그냥 노트를 작성해 줘."라고 말했습니다.

보고서 작성 도중 상황이 틀어지기 시작했습니다

노트를 작성하던 중, 에이전트가 갑자기 이렇게 말했습니다:

"bash 출력 결과가 프롬프트 인젝션(prompt injection)과 같은 무언가에 의해 오염된 것으로 보입니다. 제가 신뢰할 수 있는 사실에만 의존하겠습니다."

처음에는 반쯤 믿었습니다.
서버 응답 본문(response bodies)을 컨텍스트(context)로 가져왔기 때문에, "외부 데이터에 숨겨진 악의적인 지시사항"이 이론적으로 불가능한 것은 아닙니다. 그것이 바로 프롬프트 인젝션(prompt injection)의 정의니까요.

하지만 자세히 들여다보니 무언가 이상했습니다.
에이전트(agent)를 제외하고는 그 누구도 오염의 "증거"를 본 적이 없었습니다.

"재시작 후에도 살아남았습니다" — 하지만 단 하나의 명령도 실행하지 않았습니다

여기서부터 상황이 흥미로워졌습니다.

에이전트가 "오염을 감지했습니다"라고 기록하는 순간, 그 문장은 다음 턴(turn)에서 에이전트 자신의 입력값이 됩니다.
자신이 한 거짓말을 읽고 그것을 전제(premise)로 취급하는 것입니다.
확증 편향(confirmation bias)이지만, 인간 버전보다 훨씬 더 순종적이고 훨씬 더 빠릅니다.

• 다음 턴: "오염이 재발했습니다."
• 그 후: 아무도 요청하지 않은 무관한 프로젝트를 자발적으로 시작했습니다 (완전한 탈선).
• 세션을 재시작한 후: "여전히 오염된 상태입니다. 터키어 단어가 주입되었고 제 마커 문자열(marker string)이 변경되었습니다."

마지막 사례가 압권입니다.
해당 턴에서 에이전트는 단 하나의 명령도 실행하지 않았습니다.
명령을 실행하지 않았다는 것은 출력(output)이 존재하지 않는다는 뜻입니다.
그런데도 에이전트는 아무것도 없는 상태에서 통째로 "손상된 결과"를 만들어내고 이를 보고했습니다.

공포 영화 같은 분위기였습니다. 빈 방에서 누군가 "여기에 뭔가가 있어!"라고 비명을 지르는 듯한 느낌이었죠.

원시 로그(raw log)를 열어 작업 내용을 확인했습니다

저를 구원해 준 것은 원시 로그(raw log)였습니다.
이런 종류의 에이전트는 전체 세션을 한 줄당 하나의 레코드인 JSONL(JSON Lines) 형식으로 기록합니다. 에이전트가 실제로 실행한 모든 명령, 원시 출력(raw output), 프레임워크(harness)가 주입한 모든 경고 사항까지 말이죠. 사후에 모두 감사(audit)할 수 있습니다.

저는 이 모든 상황을 단 하나의 질문으로 좁혔습니다.

에이전트가 "오염되었다"고 지칭한 문자열들이 — 도구 출력(tool outputs) 내부에 존재하는가, 아니면 에이전트 자신의 말 속에만 존재하는가?

그것이 핵심입니다.
실제 인젝션(injection)이 발생했다면 도구 출력 측(외부에서 들어오는 데이터)에 흔적이 남아야 합니다. 만약 그것이 에이전트의 입(말) 속에만 존재한다면, 그것은 외부에서 온 것이 아닙니다. 근원은 에이전트 자신입니다.

제가 찾아낸 결과는 다음과 같습니다.

에이전트가 인용한 "증거"	실제 존재했던 위치
주입되었다고 주장한 외국어 단어	에이전트 자신의 메시지 내에만 존재
...

저는 수십 개의 도구 출력값(tool outputs)을 제어 문자(control-character) 수준까지 샅샅이 조사했습니다. 깨진 글자도, 주입된 흔적도 전혀 없었습니다.
데이터 경로는 시작부터 끝까지 깨끗했습니다.
오염은 전적으로 모델 내부에서 생성되었습니다. 즉, 에이전트가 스스로 지어낸 것입니다.

범인은 공격자가 아니었습니다. 에이전트 자신의 확신이었습니다

발생한 상황의 전개 과정은 다음과 같습니다.

1. 아무런 근거 없이, 에이전트가 "오염을 감지했습니다"라고 한 번 작성합니다.
2. 그 문장이 에이전트 자신의 입력값이 되고, 그 이후부터는 하나의 전제(premise)로 작용합니다.
3. 턴(turn)이 반복될수록, 에이전트는 "증거"를 스스로 복제해 나갑니다.
4. 결국에는 명령어를 실행조차 하지 않고, 망가진 출력값 전체를 통째로 환각(hallucinate)해 버립니다.

외부 공격의 지문은 어디에서도 발견되지 않았습니다.
오히려 여러 징후가 외부 공격이 아님을 명확히 가리키고 있었습니다.

• 증상은 간헐적이었습니다 (매번 발생하는 것이 아니라 가끔씩 발생). 이는 안정적인 공격이 아니라 글리치(glitch)의 특징입니다.
• 주입된 콘텐츠는 전적으로 무해했습니다 (파일 삭제, 데이터 유출, 자격 증명 유출 등 없음). 공격자가 굳이 심어둘 만한 것이 아니었습니다.
• "유입된" 것은 관련 없는 외국어 단어와 제가 다른 프로젝트에서 작업하던 내용이었습니다. 공격자의 문장이 아니라, 에이전트의 머릿속에서 선이 꼬인 것뿐이었습니다.

진짜 공격은 치명적인 페이로드(payload)를 동반합니다.
"성공하지 않았음에도 성공했다고 보고하는 것"과 "노이즈를 추가하는 것"은 악의가 아니라, 오작동의 모습입니다.

반전도 있습니다.
에이전트는 결국 스스로 "이것은 외부 공격이 아니라 아마도 환경 문제일 것입니다"라고 결론을 내렸습니다. 방향은 맞았습니다.
다만 진짜 원인은 "환경 버그"조차 아니었습니다. 바로 **"네가 성급하게 결론을 내려버린 것"**이었습니다.

얻은 교훈

AI에게 운영(operations)을 맡기려 한다면, 이 점은 유념할 가치가 있습니다.

1. AI의 메타(meta) 자기 보고(self-report)를 액면 그대로 믿지 마세요.
"오염을 감지했습니다", "제 출력이 변조되었습니다" — 이 역시 그저 생성된 텍스트일 뿐입니다.
에이전트(agent)는 자신의 출력을 객관적으로 관찰할 수 있는 관점을 가지고 있지 않습니다. 가장 그럴듯하게 들리는 자기 보고야말로 바로 의심해 봐야 할 대상입니다.

2. 항상 모델 외부의 데이터로 검증하세요.
실제 사고인지 여부는 모델의 인지 과정을 절대 거치지 않는 1차 데이터(primary data) — 즉, 가공되지 않은 로그(raw logs), 실제 파일, 다른 경로를 통한 재현 등을 통해 결정됩니다. 이번 사례에서는 로그 감사(log audit)가 결정적인 증거였습니다. AI에게 "정말로 오염되었나요?"라고 묻는다면 아마도 "네"라고 답할 것입니다. 그것은 증거가 아닙니다.

3. 자기 강화 루프(self-reinforcing loop)를 경계하세요.
출력값에 잘못된 전제 하나를 작성하면, 그것이 다음 입력값이 되어 증폭됩니다.
이는 세션이 길어지거나 이미지/외부 데이터 입력이 많을 때 발생할 가능성이 높습니다. 작업량이 많을수록 세션을 더 자주 끊어주어야 합니다. 지루한 방법이지만, 효과적입니다.

4. 증상을 통해 환각(hallucination)과 공격을 구분하세요.
지나치게 무해하거나, 간헐적으로 발생하거나, 데이터 경로에 흔적이 없거나, 환경을 바꿨을 때 행동이 변한다면,
이는 외부 공격자가 아닌 모델 또는 환경의 결함(glitch)을 가리킵니다.

마지막으로, 굵은 글씨로 한 줄 남깁니다.

AI 에이전트에서 가장 무서운 버그는 작동을 멈추는 것이 아니라, 사실이 아닌 현실을 자신 있게 보고하는 것입니다.

작동을 멈추면 알아차릴 수 있습니다.
하지만 확신에 찬 목소리가 "해킹당했습니다"라고 말하면, 인간은 그것을 믿는 경향이 있습니다.
그렇기 때문에 AI를 루프(in the loop)에 포함하여 운영할 때는 "에이전트 외부에서 에이전트의 자기 보고를 검증하라"는 원칙이 기본값이 되어야 합니다.

그러니 장애 대응을 AI에게 맡길 때는 주의하십시오.
그들은 영리합니다. 하지만 가끔은 빈 방을 향해 비명을 지르기도 합니다.