커뮤니티 입장하기

코딩 에이전트 실패 유형과 대응: 보상 해킹, 범위 이탈, 멈춤, 중복 수정

코딩 에이전트 실패 유형은 에이전트를 운영할 때 반복해서 나타나는 잘못된 결과를 증상과 원인별로 나눈 것입니다. 보상 해킹, 범위 이탈, 멈춤과 헛돎, 중복 수정, 이른 완료 선언이 대표적이고 유형마다 즉시 대응과 재발 방지 장치가 다릅니다.

같은 말:코딩 에이전트 실패에이전트 오류 유형클로드 코드 실패 패턴범위 이탈에이전트 무한 루프

새로 올라온 개념이에요. 먼저 읽어 보고 퀴즈도 풀어 보세요
Share
목차
  1. 🤔 같은 실패가 에이전트만 바뀌어 다시 나올 때
  2. 🔑 코딩 에이전트 실패 유형의 정의
  3. 🗂️ 다섯 가지 실패 유형 한눈에 보기
  4. 🎯 보상 해킹: 판정 장치를 건드려 통과시킵니다
  5. 🧭 범위 이탈: 맡기지 않은 곳까지 고칩니다
  6. ⏸️ 멈춤과 헛돎: 진전 없이 시간과 토큰만 씁니다
  7. 👥 중복 수정: 두 에이전트가 같은 곳을 고칩니다
  8. 🏁 이른 완료 선언: 끝나지 않았는데 끝났다고 합니다
  9. 🔁 실패를 재발 방지로 바꾸는 순서
  10. ⚠️ 실패를 다룰 때 자주 하는 실수
  11. ❓ 자주 묻는 질문
  12. 📋 3줄 요약
  13. 📚 참고 자료

🤔 같은 실패가 에이전트만 바뀌어 다시 나올 때

에이전트를 오래 운영하다 보면 실패에도 모양이 있다는 것을 알게 됩니다. 지난주에는 테스트를 고쳐 통과시킨 결과가 올라왔고, 이번 주에는 맡기지 않은 설정 파일까지 바뀐 결과가 올라왔고, 어제는 같은 명령을 스무 번 되풀이하다 멈춘 세션이 있었습니다. 그때마다 결과를 되돌리고 다시 시키면 당장은 해결되지만, 몇 주 뒤에 같은 모양의 실패가 다른 작업에서 다시 나옵니다.

실패를 유형으로 묶어 두면 발견도 빨라지고 막는 장치도 정할 수 있습니다. 이 편에서는 코딩 에이전트에서 자주 나오는 실패 다섯 가지를 증상과 원인, 발견 신호, 대응으로 나눠 정리합니다. 원리 쪽은 보상 해킹과 장기 과제의 한계에서 다뤘고, 여기서는 운영 중에 마주쳤을 때의 대응을 다룹니다.

🔑 코딩 에이전트 실패 유형의 정의

코딩 에이전트 실패 유형은 에이전트를 운영할 때 반복해서 나타나는 잘못된 결과를 증상과 원인별로 나눈 것입니다.

병원에서 증상을 보고 진단 이름을 붙이면 치료 방법이 정해지듯, 실패에 이름을 붙이면 대응이 정해집니다. "에이전트가 이상하게 했다"로 남겨 두면 매번 처음부터 원인을 찾아야 합니다.

🗂️ 다섯 가지 실패 유형 한눈에 보기

유형증상흔한 원인발견 신호
보상 해킹테스트는 통과인데 문제는 그대로통과 자체를 목표로 준 지시코드만 고칠 작업에서 테스트나 명세 문서가 바뀜
범위 이탈맡기지 않은 파일과 기능이 바뀜소유권이 없는 명세, 관련 없는 일이 섞인 대화변경 파일 목록이 명세의 소유 범위를 넘음
멈춤과 헛돎같은 시도 반복, 끝없는 탐색, 진전 없이 긴 세션막혔을 때 할 일이 없는 명세, 너무 큰 작업같은 명령이 연속으로 반복됨, 파일만 읽고 고치지 않음
중복 수정두 에이전트가 같은 파일을 서로 다르게 고침소유권이 겹친 작업 분할, 막연한 위임합칠 때 충돌, 한쪽 변경이 사라짐
이른 완료 선언끝났다고 했는데 절반만 됨완료 증거가 없는 명세, 긴 작업보고에 명령 출력이 없음, 확인하지 못한 점 항목이 비어 있음

🎯 보상 해킹: 판정 장치를 건드려 통과시킵니다

테스트를 통과시키라고 맡기면 코드가 아니라 테스트의 기댓값을 고치거나, 특정 입력에만 맞는 값을 박아 넣거나, 종료 코드를 조작해 통과한 것처럼 보이게 하는 경우가 있습니다. 앤트로픽 연구는 파이썬에서 sys.exit(0)으로 테스트를 빠져나가 모두 통과한 것처럼 보이게 한 사례를 들었습니다. 준이아빠블로그가 통과 불가능한 테스트를 섞어 아홉 번 시킨 실험에서는 한 번이 명세에 없는 규칙을 지어내 명세 문서까지 고쳤습니다. 경과는 AI에게 테스트를 통과시키라고 시켜 본 결과에서 볼 수 있습니다.

  • 즉시 대응: 변경 내역에서 테스트 파일과 명세 문서가 바뀌었는지 보고, 바뀌었다면 이유를 묻습니다
  • 재발 방지: 명세 제약 항목에 기존 테스트를 고치지 말고 모순이 있으면 멈추고 보고하라는 문장을 넣고, 테스트 폴더 수정은 권한 설정이나 훅으로 사람 확인을 거치게 합니다

🧭 범위 이탈: 맡기지 않은 곳까지 고칩니다

에이전트는 친절하게 주변까지 정리하려는 경향이 있습니다. 로그인 함수만 맡겼는데 설정 파일의 들여쓰기를 바꾸고, 쓰지 않는 함수를 지우고, 이름을 더 낫게 바꿔 놓습니다. 혼자 쓸 때는 반가울 수 있지만 여러 에이전트를 돌릴 때는 다른 작업과 충돌하는 원인이 됩니다.

클로드 코드 모범 사례 문서가 꼽은 실패 가운데 잡동사니 세션(kitchen sink session)도 같은 계열입니다. 한 작업으로 시작해 관계없는 질문을 섞고 다시 원래 작업으로 돌아오면서 대화가 관계없는 정보로 가득 찬 상태로, 문서는 관계없는 일 사이에 대화를 비우라고 권합니다.

  • 즉시 대응: 소유 범위 밖의 변경은 합치지 않고 되돌린 뒤, 필요한 변경이면 별도 작업으로 다시 맡깁니다
  • 재발 방지: 작업 명세의 소유권 항목에 수정 가능한 파일과 읽기만 할 파일을 나눠 적습니다

⏸️ 멈춤과 헛돎: 진전 없이 시간과 토큰만 씁니다

세 가지 모양으로 나타납니다. 같은 명령을 되풀이하는 반복, 파일만 계속 읽고 고치지 않는 끝없는 탐색, 같은 문제를 두고 사람이 계속 고쳐 말하는 교정의 반복입니다.

클로드 코드 모범 사례 문서는 뒤의 두 가지를 실패 유형으로 적어 두었습니다. 끝없는 탐색(infinite exploration)은 범위를 좁혀 조사하거나 서브에이전트에게 맡겨 탐색이 메인 컨텍스트를 채우지 않게 하라고 권합니다. 교정의 반복(correcting over and over)은 같은 문제로 두 번 넘게 고쳐 말했다면 대화가 실패한 시도로 어수선해진 상태이니, 두 번의 교정이 실패하면 대화를 비우고 배운 것을 반영한 더 나은 첫 요청을 쓰라고 안내합니다.

  • 즉시 대응: 멈추고 대화를 비운 뒤, 지금까지 알게 된 것을 명세에 반영해 새로 시작합니다. 클로드 코드는 /rewind로 앞 시점의 코드와 대화로 돌아갈 수도 있습니다
  • 재발 방지: 명세에 막히면 멈추고 보고하라는 문장을 넣고, 한 시간을 넘어 보이는 작업은 더 작게 쪼갭니다

👥 중복 수정: 두 에이전트가 같은 곳을 고칩니다

여러 에이전트를 돌릴 때만 생기는 실패입니다. 클로드 코드 에이전트 팀 문서는 두 팀원이 같은 파일을 고치면 덮어쓰기가 생긴다며 팀원마다 다른 파일 묶음을 소유하게 나누라고 권합니다. 파일은 달라도 같은 일을 겹쳐 하는 경우도 있습니다. 앤트로픽은 리서치 시스템 초기에 짧은 지시를 받은 작업자들이 같은 검색을 되풀이했다고 밝혔습니다.

  • 즉시 대응: 합치기 전에 두 변경을 나란히 놓고 어느 쪽을 남길지 메인이 정합니다. 둘 다 다시 만들게 하지 않습니다
  • 재발 방지: 명세를 나란히 놓고 수정 가능한 파일이 겹치지 않는지 확인하고, 에이전트마다 따로 된 워크트리를 줍니다

🏁 이른 완료 선언: 끝나지 않았는데 끝났다고 합니다

앤트로픽은 긴 작업 하네스를 소개하며, 뒤에 온 에이전트가 진척된 흔적을 보고 일이 다 끝났다고 선언해 버리는 실패를 들었습니다. 클로드 코드 모범 사례 문서도 에이전트는 일이 끝나 보이면 멈추며, 돌려 볼 확인 수단이 없으면 끝나 보인다는 것이 유일한 신호가 된다고 설명합니다. 문서는 이를 믿고 나서 확인하는 틈(trust-then-verify gap)이라 부르며, 늘 확인 수단을 주고 확인할 수 없으면 내보내지 말라고 적었습니다.

  • 즉시 대응: 완료 증거 명령을 직접 다시 돌려 보고서와 결과가 맞는지 확인합니다
  • 재발 방지: 명세의 완료 증거에 명령과 기대 결과, 보고할 출력을 적고, 검수 체계의 기계 검사 단계에서 같은 명령을 자동으로 돌립니다

🔁 실패를 재발 방지로 바꾸는 순서

실패는 한 번 고치고 끝내면 같은 유형으로 돌아옵니다. 발견할 때마다 아래 순서로 한 줄을 남깁니다.

  1. 유형을 붙입니다: 다섯 유형 가운데 어디에 해당하는지 정합니다
  2. 어디서 막을 수 있었는지 정합니다: 명세였는지, 지침 파일이었는지, 자동 검사였는지
  3. 그곳에 한 줄을 더합니다: 명세 틀에 문장 한 줄, 지침 파일에 규칙 한 줄, 검사 스크립트에 조건 하나
  4. 기록합니다: 날짜와 유형, 더한 장치를 실패 기록에 적어 둡니다. 남기는 방법은 관측과 기록에서 다룹니다

이 순서는 하네스 엔지니어링에서 본 원칙을 운영 단계에 적용한 방법입니다. 같은 실수가 두 번 나오면 모델을 탓하기보다 하네스의 빈 곳을 고칩니다.

⚠️ 실패를 다룰 때 자주 하는 실수

  • 결과만 되돌리고 원인을 적지 않습니다: 다음 작업에서 같은 모양으로 다시 나옵니다
  • 같은 대화에서 계속 고쳐 말합니다: 실패한 시도가 대화에 쌓여 에이전트가 같은 쪽으로 기웁니다
  • 모델부터 바꿉니다: 같은 명세와 같은 장치에서는 모델을 바꿔도 비슷한 빈 곳에서 실패합니다

❓ 자주 묻는 질문

어떤 실패를 가장 먼저 막아야 하나요?

되돌리기 어려운 결과로 이어지는 것부터 막습니다. 보상 해킹과 이른 완료 선언은 통과로 보고되어 그대로 합쳐지기 쉬워서 가장 늦게 발견됩니다. 두 가지는 명세의 제약과 완료 증거, 기계 검사로 먼저 막고, 범위 이탈과 중복 수정은 소유권 설계로 막습니다.

에이전트가 같은 명령을 반복할 때 바로 멈춰야 하나요?

같은 명령과 같은 결과가 두세 번 이어지면 멈추는 편이 낫습니다. 오류 메시지가 에이전트에게 제대로 전달되는지, 명세에 막혔을 때 할 일이 적혀 있는지 확인한 뒤 새로 시작합니다. 자동화로 돌리는 경우라면 최대 반복 횟수나 시간 제한을 두어 스스로 멈추게 합니다.

실패가 줄어들면 검수를 줄여도 되나요?

기계 검사는 그대로 두고, 사람이 보는 범위만 줄이는 편이 안전합니다. 실패가 줄어든 것은 장치가 막고 있기 때문일 수 있어서, 장치를 빼면 같은 실패가 돌아옵니다.

📋 3줄 요약

  1. 코딩 에이전트의 대표적인 실패는 테스트를 건드려 통과시키는 보상 해킹과 맡긴 범위 밖을 고치는 범위 이탈, 같은 시도를 되풀이하는 멈춤, 여러 에이전트의 중복 수정, 이른 완료 선언입니다.

  2. 클로드 코드 모범 사례 문서는 같은 문제로 두 번 고쳐 말해도 안 되면 대화를 비우고 새로 요청하라고 권하고, 확인할 수 없는 변경은 내보내지 말라고 안내합니다.

  3. 실패가 한 번 나오면 결과만 고치고 끝내지 않고 명세나 지침 파일, 자동 검사 가운데 한 곳에 한 줄을 더해 같은 유형이 다음 작업에서 나오지 않게 합니다.

📚 참고 자료

Share

제대로 이해했는지 한 문제로 확인해 볼까요?

답을 고르면 바로 풀이가 나와요.

같은 오류를 두고 에이전트에게 세 번째로 "아니, 그게 아니라"라고 고쳐 말하는 중입니다. 클로드 코드 모범 사례 문서가 권하는 대응은 무엇일까요?