한빛미디어

질문에 답하는 데 머물렀던 챗봇은 이제 사람을 대신해 파일을 수정하고 보고서를 작성하는 에이전트로 진화했습니다. 그러나 실제 업무에서 에이전트는 데모처럼 안정적으로 작동하지 않는 경우가 많습니다. 

에이전트 시대를 연 세 가지 사건과 에이전트가 무너지는 네 가지 실패 패턴, 그리고 같은 모델이라도 실행 환경에 따라 성능이 크게 달라지는 사례를 차례로 살펴보며, 결과를 결정하는 것은 모델이 아니라 모델을 둘러싼 환경이라는 점을 확인해보겠습니다.

에이전트 시대를 연 세 가지 사건

챗봇에서 에이전트로의 전환을 가장 선명하게 보여준 사건들은 2025년 말 이후에 집중되어 있습니다. 이 시기에 여러 기업이 단일 AI 모델에 모든 작업을 맡기는 방식만으로는 안정적인 자동화가 어렵다는 한계를 확인했습니다.

- 사건 1 | 오픈AI의 100만 줄 실험

2026년 2월, 오픈AI의 엔지니어 라이언 로포폴로(Ryan Lopopolo)는 사내 대규모 자동 코딩 실험 결과를 공개했습니다. 소규모 팀이 약 5개월 동안 전체 코드 규모가 약 100만 줄에 이르는 사내 베타 제품을 개발했고, 코드 대부분은 코덱스 에이전트가 생성한 풀 리퀘스트로 만들어졌습니다. 사람은 시스템 구조를 설계하고 결과를 검토하며 실행 환경을 조정하는 데 집중했습니다. 이 실험은 모델 성능만으로는 설명되지 않습니다. 코드 생성부터 검증, 통합, 배포까지 연결한 실행 구조가 있었기 때문에 대규모 작업이 가능했습니다. 이처럼 모델이 안정적으로 작업할 수 있도록 도구와 절차를 유기적으로 연결한 실행 환경을 하네스(Harness)라고 부릅니다.

- 사건 2 | 앤트로픽의 장시간 자율 작업 연구

앤트로픽은 에이전트가 수 시간, 수일에 걸쳐 작업을 안정적으로 이어가는 방법을 다룬 두 개의 보고서를 발표했습니다. 첫 번째 보고서에서는 에이전트를 초기화 에이전트와 코딩 에이전트로 나눴습니다. 초기화 에이전트가 요구사항을 200개 이상의 기능 단위로 분해해 합격 기준과 진행 노트를 만들어두면, 코딩 에이전트는 매 세션 미완성 기능 하나만 골라 작업하고 실제 사용자 관점의 동작 검증을 통과한 경우에만 '완료'로 표시합니다.

두 번째 보고서에서는 계획자, 생성자, 평가자로 역할을 나누고, 동일한 요구사항으로 단일 에이전트와 세 에이전트 분업 구조를 비교했습니다.

• 단일 에이전트 방식: 겉보기에는 완성된 것처럼 보였지만 핵심 기능이 정상적으로 동작하지 않았습니다. 비용은 약 9달러, 소요 시간은 약 20분이었습니다.
• 세 에이전트 분업 방식: 스프라이트 및 레벨 에디터, 정상 동작하는 게임 모드, 보조 기능까지 포함한 완성된 결과를 생성했습니다. 비용은 약 200달러, 소요 시간은 약 6시간이었습니다.

실험에 사용한 모델은 동일했습니다. 차이를 만든 것은 역할 분리와 검증 구조라는 환경 설계, 즉 하네스였습니다.

- 사건 3 | 스트라이프 미니언즈의 매주 1,300건 코드 변경

스트라이프(Stripe)는 사내 코딩 에이전트 시스템인 미니언즈(Minions)로 2026년 초 기준 매주 1,300건 이상의 코드 변경을 자동으로 생성하고 있습니다. 핵심은 블루프린트(Blueprint)라는 작업 구조입니다. 결과가 명확한 단계는 정해진 절차에 따라 처리하고, 판단이 필요한 단계만 AI 모델에 맡기는 방식입니다. 각 작업은 작은 단위로 나눠 독립된 환경에서 동시에 처리하고, 자동 검증과 사람의 최종 검토를 거쳐 반영합니다. 이렇게 많은 작업을 안정적으로 처리할 수 있었던 이유는 모델 자체보다 작업 범위와 검증 절차, 실행 환경, 즉 하네스를 체계적으로 설계했기 때문입니다.

이 세 가지 사례가 보여주는 결론은 같습니다. 에이전트의 성능을 결정하는 것은 모델이 아니라, 모델이 작업하는 '환경'입니다.

에이전트가 무너지는 네 가지 패턴

에이전트는 간단한 요청만으로 코드를 만들고 문서를 요약하며 다음 작업까지 이어갑니다. 하지만 실제 업무에서는 데모처럼 안정적으로 작동하지 않는 경우가 많습니다. 앤트로픽은 이러한 문제를 네 가지 실패 패턴으로 정리했습니다. 사람은 반복 경험으로 실패를 학습하지만, 모델은 호출이 각각 독립적이라 이전 호출의 경험을 스스로 학습하지 못합니다. 그래서 같은 실수를 반복하며, 모델을 둘러싼 외부 시스템이 실패 패턴을 감지하고 통제해야 합니다.

- 패턴 1 | 과도한 작업 범위

"쇼핑몰 애플리케이션을 만들어달라"는 요청을 받으면 에이전트는 계획 없이 데이터 구조, 로그인, 결제, 관리자 화면을 동시에 만들려고 합니다. 처리할 정보가 빠르게 늘고 우선순위가 흐려지면서 일부 기능만 구현된 채 남을 수 있습니다. 이 문제는 작업 범위를 '한 번에 하나의 기능'으로 제한하는 것만으로도 상당 부분 완화됩니다.

- 패턴 2 | 컨텍스트 불안(Context Anxiety)

컨텍스트 윈도우가 한계에 가까워지면 모델이 서둘러 작업을 끝내는 현상입니다. 답변의 말투는 자신감 있어 보이지만 실제 결과는 불완전할 수 있습니다. 문제는 모델이 자신의 한계를 정확히 인식하지 못한다는 점입니다. 잔여 토큰 수를 실제보다 적다고 판단하면 작업을 조기에 마무리할 수 있습니다. 기존 내용을 짧게 요약하는 컨텍스트 압축은 압축 과정에서 중요한 정보가 손실되고, 컨텍스트의 최대 길이를 늘리는 것은 한계에 도달하는 시점만 늦출 뿐이라 이 문제를 해결하지 못합니다. 대안은 작업을 새 에이전트에게 넘기고 필요한 최소 상태만 복원해 이어가는 컨텍스트 리셋(Context Reset)입니다.

- 패턴 3 | 섣부른 완료 선언

화면이 정상적으로 보이거나 코드 변경이 많다는 이유만으로 모든 기능이 완성됐다고 판단하는 경우입니다. 이를 막으려면 완료 판단을 에이전트 내부에 맡기지 않고 외부에 명시적인 기준을 두어야 합니다. 앤트로픽은 feature_list.json 파일에 기능별 요구사항과 상태를 명시하고, 정해진 조건을 충족했을 때만 완료로 판단하게 해 섣부른 완료 선언을 크게 줄였습니다.

- 패턴 4 | 자기 평가 편향

에이전트에 자신의 결과물을 검토하게 하면 실제보다 긍정적으로 평가하는 경향이 나타납니다. 생성과 평가가 동일한 추론 과정 안에서 이루어지기 때문입니다. 따라서 결과물을 만드는 에이전트와 검사하는 에이전트를 분리하고, 평가 단계에서는 실제 실행 결과를 확인해야 합니다.

네 가지 패턴을 정리하면 다음과 같습니다. 새 에이전트를 설계하거나 기존 시스템을 개선할 때 점검 기준으로 활용할 수 있습니다.

네 가지 패턴의 배경에는 환각과 비용 증가라는 문제가 있습니다. 환각은 대부분 높은 확신과 함께 제시되기 때문에 위험하며, 모델 수준에서 완전히 제거하기 어렵습니다. 비용은 에이전트가 작업 종료 조건을 명확히 이해하지 못할 때 무한 루프, 컨텍스트 비대화, 비효율적인 도구 호출을 거치며 빠르게 증가합니다. 따라서 출처 확인과 실행 결과 검사 같은 외부 검증 절차, 그리고 토큰 예산 관리, 무한 루프 감지, 도구 호출 제한 같은 제어 메커니즘이 함께 필요합니다. 

결국 안정적인 에이전트를 만들기 위해서는 더 뛰어난 모델만으로는 부족합니다. 작업 범위와 완료 기준, 검증 절차, 비용 제한을 포함한 실행 환경, 즉 하네스를 함께 설계해야 합니다.

같은 모델, 다른 환경: 성능 격차와 검증 부채

AI 성능이 기대에 미치지 못하면 보통 더 좋은 모델로 교체하려 합니다. 그러나 실제로는 모델의 차이보다 작업 환경의 차이가 성능에 더 큰 영향을 주는 경우가 많습니다.

모바일 환경의 코드 작업 능력을 평가한 실험 SWE-Bench Mobile에서 동일한 Claude Opus 4.5 모델을 서로 다른 에이전트 환경에 적용한 결과, OpenCode의 성공률은 약 2%였지만 커서에서는 약 12%를 기록했습니다. 같은 모델과 같은 작업 조건에서도 실행 환경, 즉 하네스에 따라 약 6배의 성능 차이가 발생한 것입니다. 

랭체인(LangChain)의 딥 에이전트(Deep Agents) 실험에서도 결과를 스스로 점검하는 절차와 반복 오류 감지, 실패 원인 분석 같은 하네스 개선만으로 Terminal-Bench 2.0 순위가 30위권에서 5위권으로 상승했습니다. 이에 따라 산업에서도 모델 자체의 성능보다 모델이 안정적으로 일할 수 있는 환경을 설계하는 쪽으로 관심이 이동하고 있습니다.

환경 설계가 중요한 이유는 작업 성공률에만 있지 않습니다. AI가 만든 결과물을 통제하고 검증하지 못하면, 생산성이 높아지는 만큼 오류와 위험도 함께 커집니다. AI가 작성하는 코드는 빠르게 늘고 있지만, 이를 확인하고 검증하는 체계는 그 속도를 따라가지 못하고 있습니다. 아마존의 최고기술책임자(CTO) 워너 보겔스(Werner Vogels)는 이처럼 검증되지 않은 AI 코드가 누적되는 현상을 검증 부채(Verification Debt)라고 표현했습니다.

출처: Sonar State of Code 2026, CodeRabbit State of AI vs Human Code Generation 2025, Faros AI AI Productivity Paradox 2025

결국 AI 코딩 도구의 확산만으로는 안정적인 성과를 기대하기 어렵습니다. AI의 작업 범위를 관리하고 결과를 검증하며 오류를 통제하는 환경이 함께 갖춰져야 합니다. 하지만 이러한 환경 설계는 아직 초기 단계에 머물러 있습니다.

위 컨텐츠는 서지영 저자의
『하네스 엔지니어링, 클로드 코드로 내 일을 대신하는 AI 에이전트 만들기』를 재구성하여 작성되었습니다.