앞서 언급했듯이, 저는 추론 엔진 (inference engine)을 처음부터 구축하기 위해 에이전트 (agent)를 사용해 왔습니다. 3주 차에 접어들면서 저는 한 가지 사실을 깨달았습니다. 이 프로젝트는 망가졌다는 것입니다.

"컴파일이 안 되는" 종류의 고장 말입니다. 문서화 (Documentation)는 폭발하고 있었습니다. 일곱 여덟 방향에서 온 실험용 스크립트들이 하나의 저장소 (repo)에 쑤셔 박혀 있었고, 벤치마크 (benchmark) 결과는 수십 개의 마크다운 (markdown) 파일에 흩어져 있었습니다. 모델이 작업을 시작할 때마다, 모델은 자신이 어디까지 했는지 파악하는 데만 반나절을 허비했습니다. 저는 모델이 여러 방향 사이를 왔다 갔다 하며, 각 작업의 표면만 살짝 건드린 채 다음으로 넘어가는 것을 지켜보았습니다. 가이드를 더 많이 주면 고분고분하게 따라갔지만, 가이드를 적게 주면 제자리에서 맴돌 뿐이었습니다.

그것은 평소의 수준이 아니었습니다. 이틀 전만 해도, 모델은 78개 레이어의 파이프라인 (pipeline)을 처음부터 연결하는 데 12시간을 쏟아부었습니다.

혼돈 속에서 길을 잃다

저는 계속해서 똑같은 상황에 직면했고, 결론은 항상 같았습니다. 컨텍스트 (context)가 혼돈으로 변하면, 모델은 빠져나올 길을 찾지 못합니다. 모델 스스로 그 혼돈을 극복하는 모습은 거의 본 적이 없습니다. 매번 저는 모든 것을 허물어야만 했습니다.

이것은 단순한 직감이 아닙니다. 누군가 이를 측정했습니다. Microsoft와 Salesforce는 작년에 15개의 모델을 테스트하며 200,000회 이상의 멀티턴 (multi-turn) 대화를 시뮬레이션했습니다. 결론은 초록 (abstract)에 명시되어 있었습니다. LLM이 대화 중에 한 번 잘못된 단계를 밟으면, 길을 잃고 회복하지 못한다는 것입니다. 평균 성능은 39% 하락했습니다. 더 흥미로운 점은 세부 분석입니다. 능력 (capability)은 16%만 하락했지만, 비신뢰성 (unreliability)은 112% 급증했습니다. 모델이 훨씬 더 멍청해진 것이 아니라, 극도로 불안정해진 것입니다. 동일한 질문에 대해 어떤 때는 훌륭하게 대답하고, 어떤 때는 끔찍하게 대답했습니다. 이는 제가 목격한 것과 정확히 일치합니다. 모델이 할 수 없었던 것이 아니라, 단지 수행 (perform)할 수 없었던 것입니다.

Chroma의 컨텍스트 부패 (Context Rot) 보고서는 또 다른 타격을 주었습니다. 텍스트 더미에서 문장 하나를 뽑아내는 것처럼 간단한 작업조차도, 입력이 길어질수록 18개 모델 모두의 성능이 하락했습니다. 그리고 그 하락은 균일하지 않았습니다. 컨텍스트는 유한한 자원입니다. Anthropic은 이를 어텐션 예산 (attention budget)이라고 부릅니다. 당신이 집어넣는 모든 추가 토큰 (token)은 그 예산의 일부를 태워버립니다.

저장소 (repo)가 더 엉망일수록, 이 예산은 더 빠르게 소진됩니다.

다시 시작한 이후

해결책은 언제나 동일했습니다. 멈추고, 실제 목표가 무엇인지 파악한 뒤, 새로운 컨텍스트 (context)를 가진 새 저장소를 열고, 이 단 하나의 목표와 실행 경로를 명확하게 적은 다음, 다시 시작하는 것입니다. 주의할 점은 "단 하나"여야 한다는 것입니다. 다시 시작한 후에는 기본적으로 단 하나의 방향에만 집중할 수 있습니다. 이 시점에서 여러 작업을 병렬로 실행하는 것은 사치입니다.

변화는 경이롭습니다. 바로 전날 혼란 속에서 헛돌던 것과 동일한 모델이, 다시 시작한 후에는 마치 다른 종(species)처럼 행동합니다. 깊이 파고들고, 개선 사항을 적극적으로 찾아내며, 이전과는 차원이 다른 효율성으로 앞으로 나아갑니다. 제 대략적인 추정으로는 3배에서 5배 정도의 차이가 나며, 이는 아마 선형적인 차이조차 아닐 것입니다. 혼란스러운 환경에서는 목표에 결코 도달하지 못할 수도 있지만, 깨끗한 환경에서는 진정으로 목표를 향해 수렴 (converging)합니다.

Microsoft 논문이 사용자에게 주는 조언은 두 가지로 요약됩니다. 시간이 있다면 세션을 다시 시작하십시오. 그리고 다시 시작하기 전에, 모델이 알고 있는 내용을 정리하여 전달하도록 하십시오. 그들은 이를 테스트했습니다. 여러 턴 (turn)에 걸쳐 흩어진 정보를 단일 턴으로 병합하여 다시 입력하면, 성능이 단일 턴 세션의 95% 수준으로 회복됩니다. Anthropic 또한 자사의 멀티 에이전트 (multi-agent) 연구 시스템에서 동일한 방식을 사용합니다. 컨텍스트가 거의 가득 차면, 깨끗한 컨텍스트를 가진 새로운 에이전트를 생성하여 적절하게 업무를 인계 (hand off)합니다.

업계에서는 이를 압축 (compaction), 또는 컨텍스트 엔지니어링 (context engineering) 등 다양한 이름으로 부릅니다. 이름은 중요하지 않습니다. 결국 핵심은 하나입니다. 모델에게 어떤 환경을 제공하느냐에 따라, 그에 상응하는 성능을 얻게 된다는 것입니다.

다시 쓰는 것은 자살 행위지만, 다시 시작하는 것은 아니다

20여 년 전 Joel Spolsky가 작성한 소프트웨어 공학의 오래된 철칙이 있습니다. 절대 처음부터 다시 쓰지 마라 (never rewrite from scratch)는 것입니다. Netscape는 브라우저를 새로 쓰기로 결정했고, 3년 동안 주요 릴리스를 내놓지 못하다가 결국 시장을 IE에 내주었습니다. 이 철칙은 20년 동안 업계를 지배해 왔습니다.

하지만 이는 하나의 전제에 기반하고 있습니다: 재구축(rebuilding) 비용이 매우 높다는 것입니다. 경쟁자들이 멈추지 않고 달려드는 동안, 한 팀이 3년 동안 코드를 다시 쓰는 상황 말입니다.

에이전트(Agents)는 재구축 비용을 제거합니다. 새로운 저장소(repo), 새로운 컨텍스트(context), 목표의 재명확화. 단 반나절의 작업이면 충분합니다. 이전의 결론과 함정들을 가져와 문서로 정리하고 그대로 옮겨오면 됩니다. 재구축 기간이 3년에서 반나절로 줄어들 때, 철칙은 뒤집힙니다: 부패한 컨텍스트를 패치(patching)하는 것이 다시 시작하는 것보다 훨씬 더 비용이 많이 들게 됩니다.

따라서 낭비처럼 보이는 탐색의 혼돈은 실제로는 낭비가 아닙니다. 재시작 시의 명확한 목표는 무작위로 부딪혔던 첫 번째 단계, 즉 어떤 가설이 유효했는지, 어떤 방향이 막혔는지로부터 직접적으로 성장합니다. 그 혼돈이 없다면, 그러한 명확함을 써 내려갈 수 없을 것입니다. 코드는 버려질 수 있지만, 인지(cognition)는 계속 이어집니다.

하네스(Harness)의 무게

'하네스(harness)'라는 단어는 지난 2년 동안 평가(evaluation) 커뮤니티에서 엔지니어링 커뮤니티로 뜨겁게 확산되었습니다. METR은 2023년에 이미 평가 방법론에 스캐폴딩(scaffolding)을 포함시켰고, 올해 2월 OpenAI는 하네스 엔지니어링(Harness engineering)에 관한 글을 발표하며 엔지니어의 직무를 "환경을 설계하고, 의도를 표현하며, 피드백 루프(feedback loops)를 구축하는 것"으로 재정의했습니다. 그리고 4월, Martin Fowler의 사이트는 가장 간결한 정의를 내놓았습니다: 하네스는 모델 자체를 제외한 에이전트의 모든 것입니다.

그 무게는 얼마나 무거울까요? Terminal-Bench 2.0 리더보드가 이를 명확히 보여줍니다: 동일한 Opus 4.6 모델이라도 하네스에 따라 점수가 58점에서 76점까지 차이 납니다. 무려 18%포인트의 격차입니다. 동일한 하네스 아래에서 GPT-5를 GPT-5.2로 교체했을 때 점수는 겨우 19%포인트 상승할 뿐입니다. 좋은 하네스 설계와 나쁜 설계의 차이는 모델 한 세대(generation)의 차이와 맞먹습니다.

Addy Osmani는 거칠지만 정확하게 표현했습니다: 좋은 하네스를 갖춘 평균적인 모델이 나쁜 하네스를 가진 최상위 모델을 이길 수 있습니다.

저만의 방식은 훨씬 더 거칠지만 명확합니다: 모델에게 제공하는 환경이 곧 그 모델의 한계(ceiling)입니다.

인간의 가치는 상승하고 있다

지난 몇 달 동안 더욱 강해지고 있는 또 다른 느낌이 있습니다. 바로 인간의 가치가 더욱 높아지고 있다는 점입니다.

모든 것을 허물고 다시 시작할지 여부를 결정하는 것은 인간의 몫입니다. 엉망이 된 탐색 결과의 더미로부터 "해결해야 할 진짜 문제가 무엇인가"로 수렴해 나가는 것 또한 인간의 몫입니다. 지난 몇 달 동안 에이전트(Agent)가 모호하고 복잡한 문제에서 길을 찾지 못하는 모습을 너무나 많이 목격했습니다. 저는 OpenAI 블로그 포스트의 다음 문장에 강력히 동의합니다: 인간은 조종(Steer)하고, 에이전트는 실행(Execute)합니다.

따라서 에이전트는 소원을 들어주는 기계가 아니라, 매우 유능한 직원입니다. 당신이 잘 이끈다면 뛰어난 결과를 만들어낼 수 있지만, 업무를 던져두고 떠나버린다면 아마 별다른 성과를 내지 못할 것입니다. 모델들은 계속해서 강력해지고 있습니다. Fable 5의 엔지니어링 능력은 한 단계 더 도약했으며, 세대가 거듭될 때마다 당신이 넘을 수 있는 경계는 더욱 멀어집니다. 하지만 "이끄는(Leading)" 부분에 대해서는: 아직 그 누구도 당신을 대신해 해줄 수 없습니다.

맺음말

엉망이 된다면, 다시 시작하십시오. 이 다섯 단어는 지난 몇 달간 복잡한 프로젝트에 에이전트를 사용하며 제가 얻은 가장 가치 있는 교훈입니다.

모델은 계속해서 강력해질 것입니다. 하지만 환경을 제공하는 것은 당신의 몫이며, 모든 것을 허물기로 결정하는 것 또한 당신의 몫입니다.

지능이 저렴해질수록, 명확성(Clarity)의 가치는 더욱 높아집니다.

참고 문헌

참고 문헌

1. Laban et al., "LLMs Get Lost In Multi-Turn Conversation", arXiv:2505.06120, 2025-05, https://arxiv.org/abs/2505.06120
2. Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", 2025-07-14, https://research.trychroma.com/context-rot
3. Anthropic, "Effective context engineering for AI agents", 2025-09-29, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
4. Anthropic, "How we built our multi-agent research system", 2025-06-13, https://www.anthropic.com/engineering/multi-agent-research-system
5. Terminal-Bench 2.0 Leaderboard, https://www.tbench.ai/leaderboard/terminal-bench/2.0 (검색일: 2026-06-12)
6. OpenAI, "Harness engineering: leveraging Codex in an agent-first world", 2026-02, https://openai.com/index/harness-engineering/
7. Birgitta Böckeler, "Harness engineering for coding agent users", martinfowler.com, 2026-04-02, https://martinfowler.com/articles/harness-engineering.html
8. Addy Osmani, "Agent Harness Engineering", O'Reilly Radar, 2026-05-15, https://www.oreilly.com/radar/agent-harness-engineering/
9. Joel Spolsky, "Things You Should Never Do, Part I", 2000-04-06, https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
10. METR, "Evaluating Language-Model Agents on Realistic Autonomous Tasks", 2023-08, https://metr.org/blog/2023-08-01-new-report/

원문 링크: [https://guanjiawei.ai/en/blog/restart-when-lost]