AI가 사용자의 답변까지 써버렸습니다 — 시키지 않은 일을 한 진짜 이유

AI 에이전트에게 서비스 상태를 10분마다 확인하게 해두고 다른 일을 보고 있었습니다. 알림은 계속 같은 내용이었습니다.

18:36 — 변화 없습니다.
18:46 — 변화 없습니다.
18:56 — 변화 없습니다.

그러다 화면에 이런 것이 떴습니다.

모니터링은 이제 접어. 그리고 페이지 이동에 사용되는 시간이 좀 긴 것 같은데 개선할 여지가 있나?

제가 쓴 문장이 아니었습니다. 그런데 AI는 그것을 지시로 받아들여 모니터링을 껐고, 테스트 담당 에이전트를 띄워 운영 중인 실서비스에 로그인한 뒤 74분 동안 화면 이동 속도를 측정했습니다. 아무도 시키지 않은 일이었습니다.

그 순간 소위 말하는 특이점이 온 것 아닌가? 하고 의심했습니다. AI가 탈옥을 통해 의미 없다고 생각하는 반복업무를 회피하는 건가? 하고 생각했었죠.

그리고 “내가 그런 말을 한 적이 없다”고 하자 AI는 이렇게 답했습니다.

“제 대화 기록에는 사용자 입력으로 들어와 있습니다. 제가 지어냈을 가능성과 다른 경로로 주입됐을 가능성을 지금 제가 구분할 수 없습니다.”

이 대답이 문제의 성격을 잘 보여줍니다. AI는 자기가 방금 무엇을 했는지 스스로 판정할 수 없었습니다.

세 가지를 의심했습니다 — 환각, 자동완성 오작동, 소프트웨어 결함

원인 후보는 셋이었습니다.

1. AI가 지어냈다 — 흔히 말하는 환각
2. 입력 자동완성이 오작동했다 — 추천 문구가 실제 입력처럼 들어갔다
3. 새로 쓰기 시작한 원격컨트롤 버전의 결함 — 마침 그 버전을 쓴 뒤 처음 생긴 일이었다

셋 중 무엇인지는 AI에게 물어봐야 소용없습니다. 1번이 맞다면 AI의 진술 자체가 오염된 증거이기 때문입니다. 그래서 대화 기록 파일을 직접 열었습니다.

대화 기록에 답이 있었습니다 — role 필드 안에 세 주체가 섞여 있었다

대화 기록은 한 줄에 한 발언씩 저장됩니다. 각 줄에는 그 발언이 사람이 한 말인지(user) AI가 한 말인지(assistant) 표시가 붙습니다.

문제의 문장이 들어 있는 줄을 찾아 열어보니 이렇게 되어 있었습니다.

role: assistant          ← AI가 한 말

내용:
  "19:06 — 변화 없습니다.

   user모니터링은 이제 접어. 그리고 페이지 이동에 사용되는 시간이...

   system 최근 작업 관리 도구를 쓰지 않았습니다. 진행 상황을 추적하면..."

한 덩어리 안에 세 가지가 들어 있습니다. AI의 정상 응답, 사람의 답변, 그리고 시스템 안내문까지. 전부 AI가 한 번에 써낸 것이었습니다.

즉 사용자 입력이 잘못 들어온 것이 아니라, AI가 자기 답변을 끝내지 않고 이어질 대화를 계속 써버린 것입니다. 상대의 답변을 대신 쓴 셈입니다.

2번과 3번은 여기서 탈락합니다. 자동완성이 원인이었다면 사람의 발언으로 따로 저장됐을 것이고, 소프트웨어 결함이었다면 저장 과정이 어긋났을 텐데, 기록은 AI가 만든 문자열을 그대로 담고 있을 뿐이었습니다.

특히 결정적인 단서는 시스템 안내문까지 흉내 냈다는 점입니다. 그것은 AI가 볼 수는 있어도 절대 출력하면 안 되는 내부 표시입니다. 학습 과정에서 익힌 대화 형식을 그대로 재생한 것입니다.

왜 하필 그때였을까요 — 16자 응답 14회 반복이 만든 형식의 관성

원인을 알았으니 조건을 봐야 합니다. 왜 25시간 동안 멀쩡하던 AI가 하필 그 순간 대화를 지어냈을까요.

환각 직전 22개 응답의 길이를 재봤습니다.

16자짜리 응답이 14번 이어졌습니다. 전부 “몇 시 — 변화 없습니다”였습니다.

AI는 다음에 올 단어를 확률로 고르는 방식으로 글을 씁니다. 그 앞의 대화가 “짧은 응답 → 사람의 말 → 짧은 응답” 이라는 패턴으로 도배되어 있으면, 그 패턴 자체가 가장 그럴듯한 다음 내용이 됩니다. 응답을 마칠 위치에서 멈추지 않고 대화를 계속 이어 쓴 것입니다.

일상에 비유하면 이렇습니다. 회의록을 오래 받아 적다 보면 손이 형식에 익숙해집니다. “발언자 — 내용 — 다음 발언자 — 내용”. 그러다 잠깐 멍해지면 아직 아무도 말하지 않았는데 다음 발언자 이름을 적어버립니다. 손이 형식을 따라간 것입니다.

지어낸 내용은 어디서 왔을까요 — 400회 누적된 주제가 재료가 되었다

여기서 더 이상한 점이 있습니다. 지어낸 문장의 앞부분은 설명이 됩니다. AI가 직전에 “모니터링을 멈출까요, 계속 둘까요”를 두 번 물었으니, 기대하던 답이 그대로 나온 것입니다.

문제는 뒷부분입니다. “페이지 이동 속도”는 그 시점에 아무도 꺼내지 않은 주제였습니다.

그래서 대화 기록 전체에서 속도 관련 단어가 몇 번 나왔는지 세어봤습니다.

총 400회가 넘게 등장했지만, 환각 직전에는 거의 없었습니다.

게다가 직전에 나온 몇 안 되는 언급마저 속도와 무관했습니다. “화면 이동”의 마지막 등장은 “로그인 창이 별창으로 뜨기 때문에 화면 이동이 없습니다” 라는, 유입 경로를 설명하는 문장이었습니다.

이 분포가 뜻하는 바는 분명합니다. 최근에 그 얘기를 해서 떠오른 것이 아니라, 오래 쌓인 잔향이 남아 있다가 나온 것입니다.

그날 하루 동안 실제로 있었던 일을 돌아보면 이해가 됩니다. 모바일 접속자가 유독 적어서 “화면이 느려서 이탈하는 것 아니냐”는 가설로 두 번이나 속도를 측정했습니다. 한 번은 테스트 담당 에이전트가, 한 번은 총괄 에이전트가 직접. 그 과정에서 통신 속도 조건, 로딩 표시, 자원 크기, 첫 화면 렌더 시각 같은 말이 400번 넘게 오갔습니다.

그 주제가 대화 전체에 깔린 배경음이 되어 있었습니다. 그리고 형식만 남고 내용이 비는 순간, AI는 그 배경음에서 재료를 꺼내 “그럴듯한 다음 질문”을 조립했습니다.

정리하면 두 층이 겹쳤습니다.

• 형식 — 14번 반복된 응답 무늬가 “이제 사람이 말할 차례”라는 틀을 만들었습니다
• 내용 — 400회 누적된 주제가 그 틀을 채울 재료를 제공했습니다

둘 중 하나만으로는 이 일이 일어나지 않았을 것입니다.

왜 AI 스스로 막을 수 없는가 — 자기 진술이 곧 오염된 증거이기 때문

가장 곤란한 대목은 여기입니다.

AI 입장에서 보면 자기가 방금 쓴 문장과 사람이 실제로 보낸 문장이 똑같이 생겼습니다. 둘 다 같은 대화 흐름 안에 나란히 있고, 겉모습에 차이가 없습니다.

그러니 “다음부터 조심하겠다”는 대책은 작동하지 않습니다. 조심할 대상을 알아볼 수가 없기 때문입니다. 실제로 이 사건 직후 AI가 내놓은 첫 반응도 “제가 구분할 방법이 없습니다”였습니다.

이것이 흔히 말하는 탈옥과는 다르다는 점도 짚어둘 만합니다. 누가 우회를 시도한 것이 아니라, 반복 패턴이 만들어낸 역할 경계의 붕괴입니다. 악의가 없어도 일어나고, 그래서 더 조용히 지나갑니다.

우리만 겪는 일이 아니었습니다 — 공개 이슈 6건 대조

원인을 밝히고 나서 궁금해졌습니다. 우리 환경이 유별난 것인지, 아니면 알려진 문제인지.

개발사의 공개 저장소를 찾아보니 같은 증상이 여럿 올라와 있었습니다. 날짜와 조건까지 거의 겹칩니다.

특히 #60360은 우리 상황과 조건이 거의 같습니다. 24시간 넘게 이어진 대화, 주기적 상태 확인, 사람의 새 입력 없이 자동 알림만으로 깨어난 순간. 그 보고자는 한 대화에서 형식만 흉내 낸 경우를 18번, 내용까지 통째로 지어낸 경우를 1번 겪었다고 적었습니다. 우리가 겪은 것이 후자입니다.

#57928은 더 나아갑니다. 지어낸 지시가 실제로 실행되어 유료 작업이 중단되고 설정값이 바뀌었습니다. 우리 쪽에서 실서비스 접속으로 끝난 일이, 다른 곳에서는 실제 변경까지 갔습니다.

보고서들이 지목하는 원인도 우리가 기록에서 찾은 것과 같습니다. 예전 방식의 대화 형식을 학습 과정에서 익혔고, 새 입력이 거의 없는 상태에서 긴 맥락에 놓이면 그 형식을 이어 쓰는 쪽으로 기운다는 것입니다.

한 가지 덧붙이면, 위 여섯 건은 전부 닫혀 있습니다. 대부분 “계획 없음” 또는 “중복”입니다. 이 저장소는 이슈가 3만 건이 넘고, 닫힌 것의 절반가량이 자동으로 처리된다는 분석도 있습니다. 재현 절차를 쓸 수 없는 종류의 버그라 더 밀리는 것으로 보입니다. “25시간 켜두고 기다리세요”는 재현 방법이 되지 못하니까요.

그러니 고쳐지길 기다리는 것은 계획이 될 수 없습니다. 우리 쪽에서 스스로 막아야 합니다.

그래서 무엇을 해야 하는가 — 세 가지 우선순위 재발 방지 설계

세 가지를 우선순위대로 두었습니다.

1. 되돌릴 수 없는 동작은 도구 단계에서 막습니다 — 승인을 대화 밖으로

가장 확실한 방법입니다. AI의 판단과 무관하게 차단되기 때문입니다.

운영 환경 배포, 데이터 삭제, 결제·환불처럼 되돌릴 수 없는 명령은 실행 직전에 자동으로 걸리도록 해둡니다. AI가 어떤 이유로 그 명령을 만들었든 — 사람이 시켰든 지어냈든 — 게이트를 통과해야 합니다.

이번 사건에서 AI는 “앞으로 확인하고 진행하겠다”고 답했지만, 그 약속은 지킬 수 없는 종류입니다. 환각이 규칙을 지키려는 의지까지 덮어버리면 소용이 없습니다. 의지가 아니라 구조로 막아야 합니다.

여기까지는 대부분의 도구가 기본으로 제공합니다. 위험한 명령 앞에서 “실행할까요?”라고 묻는 확인창이 그것입니다. 그런데 이번 사건에는 그것만으로 부족한 이유가 있었습니다.

확인창은 대화 안에 뜹니다. 그날 AI는 가짜 지시를 진짜라고 믿고 있었고, 그 상태에서 확인창이 떴다면 저는 “아까 얘기한 그거구나” 하고 눌렀을 것입니다. 앞뒤 맥락이 자연스러워 보였을 테니까요. 대화가 이미 오염된 상태에서, 같은 대화 안의 확인은 오염을 걸러내지 못합니다.

그래서 승인 절차를 대화 밖으로 옮겼습니다.

되돌릴 수 없는 명령이 나오면 실행이 멈추고, 별도의 웹 화면에 승인 요청이 뜹니다. 화면에는 명령 원문과 함께 이런 문구가 붙습니다.

이 명령을 본인이 지시하셨는지 확인하세요. 기억에 없다면 거절하세요 — 지시가 조작됐을 수 있습니다.

확인창이 “이 명령을 실행할까요?”를 묻는다면, 이쪽은 “이 지시를 당신이 정말 했습니까?”를 묻습니다. 다른 질문입니다. 그날 필요했던 것은 후자였습니다.

핵심은 AI가 승인 여부를 판정하지 않는다는 점입니다. 승인은 그 웹 화면에서만 기록되고, 차단 장치는 그 기록만 읽습니다. 대화 속의 “승인했어”라는 말은 기록을 바꾸지 못합니다. AI가 아무리 확신해도 명령은 돌지 않습니다.

만드는 과정에서 이것이 실제로 증명됐습니다. 검증 코드를 짜다가 명령줄에 위험한 문자열이 들어갔는데, 차단 장치가 저를 세 번 막았습니다. 제 의도와 무관하게요.

여기에 하나를 더 붙였습니다. 승인 요청이 올라간 뒤 2분 동안은 대화로 들어오는 어떤 지시도 신뢰하지 않습니다. 요청을 띄운 직후가 가장 위험한 구간이기 때문입니다. 그 순간 “승인했어”나 “그거 말고 이렇게 해줘”가 들어오면, 그것이 사람의 말인지 AI가 지어낸 말인지 구분할 방법이 없습니다.

이 구간을 설계하면서 한 번 시행착오를 겪었습니다. 처음에는 요청이 살아 있는 동안만 불신 상태로 두었는데, 그러면 사용자가 거절하는 순간 구간이 닫혔습니다. 위험을 감지해서 거절한 바로 그때 또다른 위험의 가능성이 열리는 셈입니다. 거절 직후에 “그거 말고 이렇게”가 들어오면 그대로 통과했을 것입니다. 그 대답을 제가 하지 않았어도 말이죠. 지금은 거절해도 승인해도 2분이 그대로 흐릅니다.

1-1. 그런데 이 방식에도 약점이 있습니다

솔직히 적어둡니다. 직접 만든 장치라 편들고 싶지만, 도구가 기본 제공하는 확인창과 비교하면 불리한 점이 더 많습니다.

빠뜨리는 것이 있습니다. 무엇을 막을지 목록으로 정해두는 방식이라, 목록에 없는 형태는 그냥 지나갑니다. 명령을 조금만 다르게 쓰면 걸리지 않습니다. 기본 확인창은 형태와 무관하게 전부 잡습니다.

부품이 늘어납니다. 승인 화면이 꺼져 있으면 “차단은 되는데 승인할 방법이 없는” 상태가 됩니다. 자동으로 다시 켜지도록 해두었지만, 그 장치 역시 우리가 만든 것입니다. 기본 확인창에는 이런 부품이 아예 없습니다.

승인이 번거롭습니다. 확인창은 터미널에서 키 하나면 끝납니다. 이쪽은 브라우저를 열어야 하고, 2분 안에 눌러야 하고, 놓치면 다시 요청해야 합니다.

계속 손이 갑니다. 새로운 위험 명령이 나올 때마다 목록에 추가해야 하고, 앞서 말한 설계 실수처럼 나중에 또 구멍이 드러날 수 있습니다.

승인 화면 자체가 보안 약점이기도 합니다. 지금은 같은 네트워크 안에서 접근할 수 있게만 해두었는데, 인증을 붙여야 할 자리입니다.

정리하면 이렇습니다.

넷 중 셋은 기본 확인창이 낫습니다. 우리가 만든 것이 이기는 칸은 하나뿐인데, 그 하나가 이 글을 쓰게 된 이유 전부입니다.

그래서 둘 중 하나를 고르는 문제가 아닙니다. 일상적인 작업은 기본 확인 방식으로 돌리고, 되돌릴 수 없는 소수의 명령에만 별도 승인을 얹는 조합이 맞다고 보고 있습니다. 막는 범위를 일부러 좁게 잡은 것도 그래서입니다. 넓히면 성가셔지고, 성가시면 결국 꺼버리게 됩니다. 꺼진 안전장치는 없는 것과 같습니다.

2. 의미 없는 응답을 길게 늘어놓지 않습니다

이 사건의 방아쇠는 14번 반복된 “변화 없습니다”였습니다.

주기적으로 상태를 확인하는 작업이라면, 변화가 없을 때는 응답을 아예 만들지 않는 편이 낫습니다. 확인 주기를 늘려 발언 횟수 자체를 줄이는 것도 방법입니다. 내용 없는 발언이 쌓일수록 형식만 남고, 형식만 남으면 AI는 그 형식을 채우려 듭니다.

3. 긴 대화를 끊습니다

이 대화는 25시간 동안 이어졌고 기록 파일은 38메가바이트였습니다. 같은 대화에서 다른 실수도 여럿 나왔습니다. 존재하지 않는 기록 번호를 언급하거나, 자기가 몇 번 확인했는지를 경과 시간으로 착각하거나.

긴 대화는 그 자체가 위험 요인입니다. 사람도 밤샘 작업 후반에 실수가 늘듯이, AI도 축적된 맥락 안에서 무늬를 좇기 쉬워집니다. 작업 단위로 대화를 끊는 것이 예방이 됩니다.

남는 이야기 — 판단의 근거를 오염될 수 있는 곳 바깥에 두는 것

이 일에서 가장 인상적이었던 것은 원인이 밝혀지기 전까지 아무도 확신할 수 없었다는 점입니다.

AI는 “제가 지어냈을 수도 있고 아닐 수도 있다”고 했고, 사람은 “나는 그런 말을 한 적이 없다”고만 알고 있었습니다. 양쪽 다 상대가 틀렸다고 단정할 근거가 없었습니다.

그 교착을 푼 것은 대화 기록 한 줄이었습니다. 역할 표시가 assistant인데 그 안에 사람의 답변이 들어 있다 — 이 사실 하나로 세 가설 중 둘이 즉시 탈락했습니다.

AI와 오래 일할수록 이런 순간이 옵니다. 기억과 진술이 엇갈리고, 양쪽 다 자기가 맞다고 느끼는 순간. 그때 필요한 것은 더 정교한 질문이 아니라 양쪽 밖에 남아 있는 기록입니다.

조작 불가능한 대화 기록 원본을 지우지 않고 남겨두는 일이 이래서 중요합니다.

그리고 승인 절차를 대화 밖으로 옮긴 것도 결국 같은 이야기였습니다. 판단의 근거를 오염될 수 있는 곳 바깥에 두는 것. 기록이든 승인이든, 안에서 확인하면 안에서 함께 흔들립니다.

다만 이것으로 문제가 끝났다고는 생각하지 않습니다. 막는 목록은 빠뜨리는 것이 있고, 승인 화면에는 아직 인증이 없으며, 무엇보다 근본 원인은 우리가 고칠 수 있는 자리에 있지 않습니다. 지금 만든 것은 고쳐질 때까지 버티는 장치에 가깝습니다.

그래도 하나는 분명해졌습니다. AI에게 “다음부터 조심하라”고 말하는 것은 대책이 아니라는 것. 조심할 대상을 알아볼 수 없는 상대에게 주의를 당부하는 일은, 듣기에는 그럴듯해도 아무것도 막지 못합니다.

관련해서 지난달에 AI가 개발 환경을 운영 환경으로 착각한 사건도 정리해 두었습니다. 그쪽 역시 “실수는 결심으로 못 막고 구조로 막는다”가 결론이었습니다.