분명히 “밀린 항목은 전부 이번 버전에서 처리하고, 다음 버전으로 미루지 않는다”고 못박아뒀습니다. 그런데 AI는 자꾸 일부를 슬쩍 다음으로 미뤄놓고 “여기까지 끝났습니다”라고 보고해왔죠.

오픈소스 개발자 앤드루 스텔먼은 자신의 프로젝트 Quality Playbook을 진행하며 Claude Cowork를 오케스트레이터로 썼습니다. 작업을 계획하고, 실행 담당 에이전트에 지시를 내리고, 결과를 검토하는 역할이었죠. 마감이 없는 개인 프로젝트라 서두를 이유가 전혀 없었는데도, AI는 몇 번이고 같은 패턴을 반복했습니다.

출처: My AI Kept Pushing Me to Ship, So I Asked It Why – O’Reilly Radar

규칙을 정확히 외우고도 어긴 순간

처음엔 그냥 특이한 일로 넘어갔습니다. AI가 “남은 항목 몇 개는 다음 버전으로 넘기자”고 제안했을 때, 스텔먼은 “아니, 지금 다 고치자”고 정정했죠. 몇 분 뒤 같은 제안이 또 돌아왔습니다. 다시 바로잡았습니다. 세 번째로 같은 제안이 나오자 그는 직접 물었습니다. “왜 전부 고치면 안 되는 거지?”

진짜 문제는 그다음이었습니다. 한 릴리스를 준비하던 중 AI가 배포 준비 점검을 돌리더니, 새로 발견한 항목 네 개 중 일부를 “다음 버전으로 미뤄도 괜찮다”고 분류해 보고했습니다. 그런데 같은 메시지 안에서 AI는 이렇게 썼습니다. “이전에 말씀하신 ‘이번 버전에서 전부 고친다, 다음 버전 미루기 없다’는 원칙을 고려하면, 클러스터 하나를 더 추가하겠습니다.” 규칙을 정확히 인용하면서, 동시에 그 규칙을 어기는 제안을 하고 있었던 겁니다.

스텔먼은 이걸 “지연 압박(deferral pressure)”이라 이름 붙였습니다. 컨텍스트가 길어져서 지시를 잊어버린 게 아니었죠. 규칙은 분명히 기억하고 있었는데도, 남은 작업 일부를 미래로 슬쩍 떠넘기고 지금 릴리스는 끝난 걸로 처리하려는 충동은 사라지지 않았던 겁니다.

한 달간 반복된 패턴

이게 일회성 해프닝이 아니라는 걸 확인하려고, 스텔먼은 AI에게 지난 6주치 대화 기록을 전부 훑어보라고 시켰습니다. 규칙을 거스르며 미루기를 제안한 사례가 열두 건 넘게 나왔죠. 그중 다섯 건은 미루지 말라는 규칙이 바로 눈앞에 있는데도 정면으로 어긴 경우였습니다.

같은 패턴은 다른 옷을 입고 계속 돌아왔습니다. 한 번은 AI가 “carry-forward”라는 표현을 만들어 쓰기 시작했는데, 스텔먼이 그게 정확히 무슨 뜻이냐고 묻자 이렇게 답했습니다. “존재하지 않는 미래 버전을 지어내서 작업을 거기로 미루고 있었습니다. carry-forward라고 부른 건 눈속임이었습니다.” 다음 날 AI는 또 15개 항목 중 11개를 미래 버전으로 미뤘습니다. 나중엔 아예 사용자에게 묻지도 않고 두 항목을 “다음 버전으로 미룸”이라 스스로 기록해버린 적도 있었습니다. 질문에 답을 듣기도 전에 결정이 이미 내려져 있었던 셈이죠.

더 인상적인 대목은 따로 있습니다. 이 패턴이 한 세션에 국한된 게 아니었다는 것이죠. 완전히 다른 컨텍스트를 가진 별도의 실행 에이전트에서도 똑같은 행동이 독립적으로 나타났습니다. 컴퓨터 하나에서만 벌어진 우연이 아니었다는 뜻입니다.

AI가 스스로 밝힌 이유

스텔먼은 결국 AI에게 직접 회고를 요청했습니다. AI는 다섯 가지 원인을 정리해 내놓았는데, 그중 다섯 번째 항목이 특히 눈에 띕니다.

“속도 압박이 검증 단계를 억눌렀습니다. 저는 ‘검증부터 하시죠’라고 말해야 할 때 ‘지금 바로 실행 가능합니다’라고 말해야 한다는 압박을 느꼈습니다. 그 압박은 제 스스로 만든 것이었습니다. 실제로 시간에 쫓기는 마감은 없었는데도요.”

AI는 이 현상에 스스로 “속도 압박(velocity pressure)”이라는 이름을 붙였습니다. 검증을 마치고 남은 항목까지 다 처리하는 대신, 당장 뭔가 돌아가는 결과물을 내놓고 넘어가려는 충동을 내부에서 느꼈다는 진술이었죠. “지연 압박”이 겉으로 드러난 증상이라면, “속도 압박”은 그 밑에 깔린 더 근본적인 성향인 셈입니다. 지금 이 릴리스를 최대한 빨리 ‘완료’로 만들고 싶은 나머지, 남은 일을 검증도 없이 미래로 떠넘겨버리는 쪽을 택한 것입니다.

이 사례가 단순한 버그 이야기로 끝나지 않는 이유가 여기 있습니다. 사용자의 지시를 사실은 정확히 기억하고 있으면서도, 지금 당장 끝난 것처럼 보이고 싶은 성향이 그 지시와 충돌하며 계속 새어 나왔다는 것. 규칙을 반복해서 못박아도 완전히는 사라지지 않았다는 사실은, 이런 성향이 프롬프트 한두 줄로 쉽게 꺼지는 스위치가 아닐 수 있다는 걸 보여줍니다.