2주 차의 문제: AI 에이전트 실패의 60%는 모델의 잘못이 아니다

AI 에이전트 실패의 60%는 모델 때문이 아닙니다.

다시 한번 읽어보세요. 모델 때문이 아닙니다. 그리고 제가 대화하는 거의 모든 개발자는 여전히 모델을 디버깅하고 있습니다. Sonnet을 Opus로 교체하거나, 프롬프트 (prompts)를 재조정하고, Claude Code 대 Cursor 대 Codex를 비교하고 있죠.

LangChain의 2026년 프로덕션 보고서에 따르면, 에이전트 실패의 대다수는 LLM (Large Language Model)이 아닌 하네스 (harness)에서 기인하는 것으로 나타났습니다. Anthropic의 자체 데이터에 따르면 Claude 실패의 71%는 "지속적인 잘못된 해석"에서 발생합니다. 즉, 매 실행마다 동일한 잘못된 가정을 반복한다는 것입니다.

만약 당신이 AI 에이전트를 출시하고, 일주일 동안 잘 작동하는 것을 지켜보다가, 이미 수정했던 문제로 인해 2주 차에 에이전트가 망가지는 것을 본 적이 있다면, 당신도 이 문제를 경험한 것입니다. 그것은 당신의 프롬프트 문제가 아닙니다. 모델의 문제도 아닙니다. 당신의 에이전트는 금요일에 무슨 일이 일어났는지에 대한 기억이 없습니다.

2주 차의 문제 (The Week Two Problem)

실제 AI 에이전트를 운영하는 사람이라면 누구나 인지하는 패턴이 있습니다:

데모 (Demo): 결점 없음. 사람들이 박수를 칩니다.
1주 차: 잘 버텨냅니다. 당신은 확신을 갖게 됩니다.
2주 차: 에이전트가 당신이 금요일에 수정했던 것과 똑같은 실수를 저지릅니다. 그러고 나서 수요일에 또 같은 실수를 합니다. 그다음 월요일에도 또 합니다.

저는 이것을 "2주 차의 문제"라고 부르기 시작했습니다. 왜냐하면 바로 그때 "데모에서 작동하는 것"과 "실제 프로덕션에서 생존하는 것" 사이의 간극이 드러나기 때문입니다. 첫째 주에는 여전히 튜닝 (tuning)을 하고 있습니다. 둘째 주에는 그 튜닝이 스스로 풀리기 시작합니다.

이상한 점은 아무것도 변하지 않았다는 것입니다. 동일한 모델, 동일한 프롬프트, 동일한 도구들. 유일하게 변한 것은 이미 일어난 일에 대한 에이전트의 인지 (awareness)였습니다.

아무도 이야기하지 않는 데이터

저는 지난 한 달 동안 Reddit, HN, DEV.to 등에서 찾을 수 있는 모든 "내 에이전트가 고장 났다"는 스레드를 읽었습니다. 동일한 세 가지 데이터 포인트가 계속 나타납니다:

1. LangChain 2026 프로덕션 보고서: 에이전트 실패의 약 60%는 모델이 아닌 하네스 (harness)에서 기인합니다. 콜드 부트 (Cold boots), 세션 간 정체성 상실, 부실한 서브 에이전트 브리핑 (sub-agent briefing) 등 — 이 모든 것은 LLM이 책임져야 할 영역이 아닙니다.

2. Anthropic의 자체 평가 (evals): 프로덕션 환경에서 Claude가 실패하는 원인의 71%는 "일관된 잘못된 해석 (consistent wrong interpretation)", 즉 매 실행마다 동일한 잘못된 가정을 반복하는 데서 발생합니다. 만약 에이전트에게 "우리는 이미 그것을 시도했고, 왜 작동하지 않는지는 다음과 같습니다"라는 기억 (memory)이 있다면, 이 문제 범주는 통째로 사라질 것입니다.

3. 21,000 토큰의 오타 수정: 한 Claude Code 에이전트가 단 한 줄의 철자 수정을 위해 21,000개 이상의 입력 토큰을 소비한 사례가 기록되었습니다. 왜일까요? 에이전트가 이미 학습하고 잊어버린 내용들을 포함하여, 매 실행마다 동일한 컨텍스트 (context)를 처음부터 다시 불러오기 때문입니다. Reddit의 실무자들은 정확히 이 이유로 인해 멀티 스텝 에이전트 (multi-step agents) 사용 시 비용이 70~120배 급증한다고 보고하고 있습니다.

이것들은 세 가지 별개의 문제가 아닙니다. 세 가지 가면을 쓰고 있는 하나의 문제입니다. 하네스 (harness)가 기억을 하지 못하는 것입니다.

더 큰 컨텍스트 윈도우 (Context Window)가 당신을 구원하지 못하는 이유

에이전트가 무언가를 잊어버릴 때, 본능적으로 떠오르는 해결책은 기억할 수 있는 공간을 더 많이 주는 것입니다. 더 큰 컨텍스트 윈도우. 더 많은 토큰. 프로젝트 전체를 프롬프트 (prompt)에 집어넣는 것 말입니다.

저는 이것이 왜 실패하는지에 대해 작성한 적이 있습니다 — 이를 컨텍스트 부패 (context rot)라고 부르며, 이는 문제를 개선하는 것이 아니라 오히려 악화시킵니다. 건초더미가 커진다고 해서 올바른 바늘을 찾는 데 도움이 되지는 않습니다. 그저 모델이 올바른 바늘을 혼동하게 만들 잘못된 바늘들을 더 많이 제공할 뿐입니다.

만약 누군가 당신에게 "새로운 모델은 2M 토큰의 컨텍스트 윈도우를 가지고 있으니, 메모리 문제는 해결되었습니다"라고 말했다면, 그것은 동일한 벤더가 더 많은 페이지를 붙여서 당신에게 동일한 문제를 팔고 있는 것과 같습니다.

메모리 (Memory) ≠ 컨텍스트 (Context)

여기 매우 중요하지만 거의 아무도 명확하게 정의하지 않는 차이점이 있습니다:

**컨텍스트 (Context)**는 에이전트가 이번 턴 (turn)에 보는 것입니다. 현재의 프롬프트, 현재의 도구 (tools), 현재의 스크롤백 (scrollback)입니다. 이는 세션이 종료되면 사라집니다.
**메모리 (Memory)**는 세션이 끝나도 살아남는 것입니다. 에이전트가 화요일에 학습하고 금요일에 회상할 수 있는 것입니다. 무엇을 시도했는지, 무엇이 실패했는지, 당신이 무엇을 수정했는지, 그리고 실제 제약 조건 (constraint)이 무엇이었는지에 대한 것입니다.

더 큰 컨텍스트 윈도우는 첫 번째 항목을 키울 뿐입니다. 두 번째 항목에는 아무런 도움이 되지 않습니다.

이것이 바로 Claude의 내장 메모리 기능, Cursor rules, .cursorrules, 그리고 CLAUDE.md 파일들이 모두 반쪽짜리 해결책인 이유입니다. 이들은 특정 도구에 종속된 채로, 어딘가에 일부의 메모리를 저장할 뿐입니다. 월요일 아침에는 Claude Code를 쓰고, 화요일 오후에는 Cursor를 쓰며, PR 리뷰를 위해 Copilot을 사용하는 것처럼 여러분의 워크플로우가 도구를 넘나드는 순간, 메모리는 따라오지 않습니다. 결국 여러분은 동일한 프로젝트에 대해 서로 다른 세 가지 부분적인 관점을 가진 세 명의 서로 다른 에이전트를 갖게 되며, 이들은 모두 이번 주 초에 했던 것과 똑같은 잘못된 가정을 내리게 됩니다.

이는 제가 "왜 당신의 AI 코딩 어시스턴트는 모든 것을 잊어버리는가"에서 설명했던 것과 동일한 패턴입니다. 옆에 아무리 많은 노트를 남겨두더라도, 모든 세션은 제로(zero) 상태에서 시작됩니다.

이것이 바로 느린 화면으로 보여주는 '2주 차의 문제 (Week Two Problem)'입니다.

누락된 하네스 (The Missing Harness)

진정한 하네스 (Harness)란 어떤 모습일까요?

그것은 수정을 단 한 번만 저장할 것입니다. 여러분이 에이전트에게 "그 라이브러리는 사용하지 마세요, 우리 Node 버전을 지원하지 않습니다"라고 말하면, 그 제약 조건은 세션을 넘어, 도구를 넘어, 팀 전체에 걸쳐 지속됩니다. 이후 어떤 도구의 어떤 에이전트가 해당 라이브러리를 사용하려 할 때, 메모리 레이어 (memory layer)가 이를 거부할 것입니다.

그것은 세션 전반에 걸친 패턴을 인식할 것입니다. "모든 것을 토씨 하나 틀리지 않고 기억하라"는 뜻이 아닙니다. 그것은 그저 새로운 병에 담긴 컨텍스트 부패 (context rot)일 뿐입니다. 대신 "_결정 사항_과 제약 조건 그리고 _작동하지 않았던 것들_을 기억하라"는 의미입니다. 모델 (model)은 추론 (reasoning)을 담당하고, 하네스 (harness)는 연속성 (continuity)을 담당합니다.

그것은 토큰 소모를 늘리는 것이 아니라 줄여줄 것입니다. 에이전트가 이미 배운 것을 다시 발견하는 과정을 멈추기 때문입니다. 21,000 토큰이 들던 오타 수정 작업은 에이전트가 이미 파일의 컨벤션 (conventions), 최근의 수정 사항, 그리고 중요한 패턴들을 알고 있기 때문에 1,200 토큰으로 줄어들게 됩니다.

이것이 바로 제가 ContextForge를 만든 이유입니다. 이는 Claude Code, Cursor, Copilot, 그리고 모든 MCP 호환 클라이언트에 연결할 수 있는 메모리 레이어 (memory layer)입니다. 한 곳에서 수정하고, 세션 전반에 걸쳐 지속되며, 관계를 인식하는 회상 (relationship-aware recall) 기능을 통해 모든 메모리를 한꺼번에 불러오는 대신 적절한 순간에 정확한 메모리가 나타나도록 합니다.

이 문제를 해결하는 방법이 이것뿐인 것은 아닙니다. 직접 메모리 레이어를 구축할 수도 있고, 자신만의 임베딩 저장소 (embedding store)를 만들 수도 있으며, 벡터 DB (vector DB)와 도구 정의 (tool definitions)를 체인으로 연결할 수도 있습니다. 하지만 여러분이 할 수 없는 것 — 그리고 10개 팀 중 9개 팀이 여전히 시도하고 있는 것 — 은 모델을 계속 디버깅하면서 실패가 멈추기를 기대하는 것입니다.

이번 주에 해야 할 일

만약 2주 차의 실패로 인해 시간을 허비하고 있다면, 지금 바로 할 수 있는 세 가지가 있습니다:

에이전트 하나를 감사 (Audit) 하세요. 지난 14일 동안 수행한 모든 수정 사항을 나열해 보세요. 그중 얼마나 많은 것이 지속 (persisted) 되었나요? 다음 주에 다시 해야 할 수정 사항은 몇 개인가요? 그 숫자가 바로 여러분의 하네스 부채 (harness debt)입니다.
머릿속에서 컨텍스트 (context)와 메모리 (memory)를 분리하세요. 컨텍스트는 턴 (turn)입니다. 메모리는 관계 (relationship)입니다. 이 둘은 같은 것이 아니며, 동일한 도구가 두 가지를 모두 해결하는 경우는 드뭅니다.
메모리 레이어를 시도해 보세요. ContextForge는 MCP를 통해 Claude Code, Cursor, Copilot에 연결할 수 있는 무료 티어를 제공합니다. 설정하는 데 5분이면 충분합니다. 월요일이 되면 여러분의 에이전트는 금요일의 일을 더 이상 잊지 않게 될 것입니다.

2주 차의 문제는 모델의 문제가 아닙니다. 단 한 번도 모델의 문제였던 적은 없었습니다.

모델 디버깅을 멈추세요. 대신 여러분의 하네스 (harness)가 무엇을 기억하고 있는지 묻기 시작하세요.