챗봇이 이상한 답을 내놓으면 대화는 그걸로 끝입니다. 다시 물어보면 그만이죠. 그런데 에이전트가 작업 도중에 잘못된 판단을 내리면 이야기가 다릅니다. 멈추지 않고 계속 나아가는 겁니다. 잘못된 값으로 다음 도구를 호출하고, 그 결과 위에 또 다른 작업을 쌓아 올립니다. 사람이 뭔가 이상하다고 느낄 때쯤이면, 이미 몇 단계나 잘못된 길을 걸어온 뒤일 수 있죠.

MachineLearningMastery가 AI 에이전트 프로젝트를 반복적으로 무너뜨리는 구조적 실수들을 정리했습니다. 모델 자체보다 아키텍처와 메모리 설계, 도구를 다루는 방식에서 문제가 생긴다는 게 핵심입니다. 에이전트를 직접 설계하는 개발자를 겨냥한 글이지만, Claude Code처럼 이미 만들어진 에이전트 도구를 매일 쓰는 사람에게도 “이 도구가 왜 가끔 이렇게 굴까”를 이해하는 단서가 됩니다.

출처: Building AI Agents? Here Are Some Anti-Patterns to Avoid – MachineLearningMastery

왜 에이전트의 실수는 눈덩이처럼 불어나는가

언어 모델은 질문에 답만 합니다. 하지만 에이전트는 과제를 처리합니다. 무엇을 할지 판단하고, 도구를 고르고, 결과를 보고 다음 행동을 조정하는 일련의 과정을 거치죠. 이 순환 구조가 에이전트를 강력하게 만드는 동시에, 실패하는 방식도 완전히 다르게 만듭니다.

자율적으로 움직이는 에이전트는 단계를 거칠 때마다 상태를 쌓아 올립니다. 두 번째 단계에서 도구를 잘못 호출하면 다섯 번째 단계에서 참조할 맥락 자체가 어긋나죠. 오래된 메모리 하나가 세 단계 뒤의 판단을 왜곡시키기도 합니다. 사용자 눈에 뭔가 잘못됐다고 보일 무렵이면, 에이전트는 이미 잘못된 전제 위에서 여러 행동을 실행한 뒤일 가능성이 큽니다. 에이전트의 실패가 단순히 “더 심각한” 게 아니라 “질적으로 다른” 이유입니다.

도구가 늘어날수록, 에이전트는 더 헷갈린다

에이전트에게 도구를 하나 더 쥐여줄 때마다, 모델은 다음 행동을 정할 때마다 그 도구까지 함께 고려해야 합니다. 도구가 많아질수록 잘못된 선택을 할 확률이 늘고, 프롬프트 크기도 커지며, 어디서 왜 틀렸는지 추적하기도 어려워집니다. 특히 비슷한 역할을 하는 도구가 여럿 있으면, 모델은 효율적인 경로 대신 헷갈리는 경로를 택하기 쉽습니다.

이건 에이전트를 여러 개로 쪼개는 것으로 해결되지 않을 때가 많습니다. 오히려 범위가 좁고 잘 설계된 단일 에이전트가, 온갖 역할을 떠맡은 비대한 에이전트보다 나은 성과를 내는 경우가 흔합니다. 팀들이 흔히 저지르는 실수는 아직 검증도 안 된 단계에서 멀티 에이전트 구조부터 설계하는 것입니다. 조율 비용이 예상보다 훨씬 빠르게 늘어나기 때문에, 먼저 단일 에이전트로 어디까지 가능한지 확인하고 나서 필요할 때만 나누는 편이 안전합니다.

컨텍스트가 길어질수록, 기억은 오히려 흐려진다

작업이 길어지면 처음엔 정확했던 정보도 점점 낡아갑니다. 데이터가 바뀌고, 초반에 받아온 도구 결과가 더 이상 유효하지 않게 되는 경우도 생기죠. 이런 현상은 “컨텍스트 로트”라 불리는데, 컨텍스트 창에 담긴 토큰이 늘어날수록 모델이 정보를 정확히 떠올리는 능력이 오히려 떨어지는 걸 가리킵니다.

컨텍스트 창은 계속 채워 넣기만 하면 되는 창고가 아니라, 채울수록 효용이 줄어드는 한정된 자원으로 다뤄야 합니다. 오래 실행되는 에이전트일수록 이 문제는 예외가 아니라 기본적으로 마주치는 조건입니다. 낡은 도구 결과는 토큰 한도에 다가갈 때 자동으로 정리하고, 도구 응답에서 필요한 부분만 뽑아 쓰고, 하나의 큰 결과가 나머지 맥락을 다 밀어내지 않도록 크기에 상한을 두는 식의 대응이 필요합니다. 에이전트가 이상한 소리를 하기 시작한 뒤에야 손대는 건 이미 늦은 대응입니다.

쓰기 권한은 읽기 권한과 다른 위험이다

언어 모델은 자신 있는 말투로 틀린 답을 내놓을 수 있습니다. 그런데 에이전트가 실제 서비스에 직접 값을 쓰거나 사용자에게 메시지를 보낼 권한까지 갖고 있다면, 그 잘못된 판단이 곧바로 현실에 반영됩니다. 읽기 작업과 쓰기 작업은 서로 다른 위험 범주이고, 처음부터 그렇게 구분해서 다뤄야 합니다.

실무에서는 쓰기 작업이 실행되기 전에 출력을 검증하는 절차, 에이전트가 건드릴 수 있는 범위를 제한하는 장치, 그리고 되돌리기 어려운 작업에는 사람의 확인을 거치도록 하는 구조가 필요하죠. 도구마다 기본적으로 넓은 권한을 주는 대신, 그 도구가 실제로 지닌 위험 수준에 맞춰 권한 경계를 설계하는 게 핵심입니다.

결국 설계 순서의 문제

원문은 이 외에도 프롬프트를 코드에 박아 넣지 말고 구성 요소로 분리하라는 조언, 그리고 실제 배포 전에 예상 밖의 입력으로 미리 테스트해야 한다는 지적도 함께 다룹니다. 관통하는 메시지는 하나입니다. 단순하게 시작하고, 관측 가능하게 만들고, 측정된 근거가 있을 때만 복잡성을 더하라는 것입니다. 안티패턴들은 대부분 이 순서를 거꾸로 밟았을 때 나타납니다.

내가 직접 에이전트를 설계하지 않더라도, 이런 구조를 알아두면 쓰던 도구가 왜 가끔 엉뚱한 답을 반복하는지, 왜 대화가 길어질수록 맥락을 놓치는지 짐작할 실마리가 생깁니다. 도구가 똑똑해 보이는 것과, 그 안의 설계가 얼마나 신중한지는 별개의 문제라는 걸 보여주는 사례입니다.