요즘 에이전트 하네스에 대한 고민

TL;DR

며칠 전 팀 메신저에 프로젝트에 맞는 에이전트 환경을 자동으로 만들어 주는 도구 하나를 공유했어요. 좋아 보였거든요.
한 팀원분이 거기에 OpenAI의 하네스 엔지니어링 글을 덧붙이며 이런 답을 남겼어요.

"오픈코드 생태계로 많은 부분이 발전되고 성장하나, 여러 방면의 도구 및 방법론들이 형성되면서 매 순간마다 구미가 당겨오거든요. AI도 마찬가지구요. 장기적인 프로젝트 방향성에는 옳지 않다는 생각이 듭니다."

새 도구를 공유하자마자 돌아온 답이라 며칠이 지나도 이 문장이 계속 생각났어요. 그리고 질문 하나가 생겼습니다.
나는 지금 뭘 쫓고 있는 걸까?

이 글에서는 그 질문에서 출발해, 프롬프트 엔지니어링부터 하네스 엔지니어링까지 바뀌어 온 흐름에서 무엇이 낡고 무엇이 남는지 정리해 보았습니다.

또 새 용어를 배워야 해요

최근 몇 년 동안 LLM을 쓰는 방식을 가리키는 말이 자주 바뀌었어요. 앞의 방식이 풀지 못한 문제를 다음 방식이 풀겠다고 나오는 식이었습니다.

처음에는 프롬프트 엔지니어링이었어요. "웹사이트 만들어줘"보다 "반응형 로그인 페이지, 다크 모드 지원"처럼 명령을 구체적으로 쓰는 기술이에요. 그런데 아무리 정교하게 써도 모델이 우리 프로젝트 구조를 모르면 엉뚱한 답이 나왔습니다.

그래서 컨텍스트 엔지니어링이 나왔어요. 프롬프트만으로는 부족하니 배경 정보까지 함께 줘야 한다는 이야기였습니다. 하지만 컨텍스트를 충분히 줘도, 그걸 쓰는 작업 흐름이 잘못 설계되면 여전히 실패했어요.

그래서 이번에는 에이전트가 일하는 환경 전체를 설계하는 쪽으로 초점이 옮겨 갔어요. 그게 하네스 엔지니어링입니다. 2026년 2월 Mitchell Hashimoto의 글로 퍼지기 시작해, 두 달 만에 AI 코딩 커뮤니티의 중심 용어가 됐어요.

용어가 이렇게 빨리 바뀌면 피로합니다. 지난번에 배운 게 익숙해지기도 전에 "그건 옛날 방식이고 이제는..."이 시작돼요. BMAD를 써 볼까 하면 Spec Kit이 뜨고, 이제 좀 정리됐나 싶으면 Anthropic이 그중 상당수는 이제 과하다고 말합니다. 팀원분의 말은 이 피로에 대한 이야기였어요.

그래도 이 전환들은 서로를 지우지 않아요. 프롬프트 엔지니어링은 하네스 안의 한 부분으로 옮겨 갔을 뿐이라, 배운 게 헛수고는 아니에요. 다만 쌓이는 것은 각 방식이 찾아낸 원리이고, 그 원리를 담았던 프레임워크는 낡습니다.

프레임워크는 모델이 약하다는 가정 위에서 만들어졌어요

BMAD나 Spec Kit 같은 프레임워크를 뜯어보면 공통점이 있어요. 구성 요소마다 "모델이 혼자서는 못 한다"는 가정이 들어 있습니다.

작업을 마이크로 태스크로 잘게 쪼개는 건 모델이 큰 덩어리를 한 번에 못 다루기 때문이고, 세션을 자주 끊고 컨텍스트를 리셋하는 건 긴 작업에서 일관성을 잃기 때문이에요. 스프린트마다 완료 기준을 계약으로 정해 두는 것도 모델이 중간에 방향을 놓치거나 "다 됐다"며 일찍 끝내 버리기 때문입니다. 전부 모델의 약점을 메우는 방법이에요.

Claude Sonnet 4.5 때는 이 방법들이 가장 확실한 해법이었어요. 그런데 Opus 4.6이 나오면서 그 가정 중 상당수가 낡아 버렸습니다. 컨텍스트 창이 100만 토큰으로 커진 것만이 이유는 아니에요. 한 세션을 몇 시간 이어가도 일관성을 잃지 않고, 자기 실수를 스스로 잡아내고, 더 큰 코드베이스를 다루게 됐습니다.

그러자 예전 프레임워크가 새 모델에게는 오히려 오버헤드가 됐습니다. 모델이 혼자 해낼 수 있는 일을 여러 단계로 쪼개 강제하면, 단계 사이에서 작은 오류가 번져 결과가 나빠질 수 있어요. 모델이 약할 때 필요하던 구조가 모델이 강해지자 일만 늘리게 된 거예요.

그래서 하네스도 처음엔 반갑지 않았어요. 또 새 용어, 또 새 프레임워크, 몇 달 쓰다 버릴 것 같았거든요. 그런데 Anthropic 엔지니어링 블로그의 원문을 읽고 생각이 바뀌었습니다. 유행하는 프레임워크와 그 아래 깔린 원리는 따로 봐야 했어요.

그래도 하네스는 필요해요

하네스(Harness)는 원래 말에 채우는 마구를 가리켜요. 말의 힘을 원하는 방향으로 쓰게 하는 도구입니다.

Mitchell Hashimoto는 하네스 엔지니어링을 이렇게 정의했어요.

"에이전트가 실수를 할 때마다 그 실수가 다시는 반복되지 않도록 엔지니어링 하는 것."

프롬프트에 "이거 하지 마"라고 쓰는 건 부탁이에요. 부탁은 언젠가 또 어겨집니다. 하네스 엔지니어링은 그 실수가 구조적으로 일어날 수 없는 환경을 만드는 일이에요.

우리는 이미 하네스를 쓰고 있어요. LLM은 텍스트를 넣으면 텍스트를 내놓는 함수라서 이전 대화를 기억하지 못해요. 그런데 Claude나 ChatGPT와 대화할 때 앞의 메시지가 이어지는 건, 채팅 화면이 대화 내용을 모아 매번 다시 넘겨주기 때문이에요. 그 반복 자체가 하네스입니다.

하네스는 컨텍스트 한계와 자기 평가 실패를 풀려고 나왔어요

하나는 컨텍스트 한계입니다. 모델이 한 번에 기억할 수 있는 작업 기억(컨텍스트 창)에는 끝이 있고, 긴 작업은 반드시 거기에 부딪혀요. Anthropic 연구팀이 Opus에게 claude.ai를 클론해 보라고 시킨 실험에서 실패가 두 가지로 반복됐습니다.

• 한 번에 해결하려다 컨텍스트 창이 바닥나 절반만 구현됐고, 다음 세션에서는 어디까지 했는지 몰라 처음부터 다시 파악해야 했어요
• 어느 정도 진행된 뒤, 아직 한참 남았는데도 "다 됐네" 하고 일을 끝내 버렸어요

Anthropic은 이렇게 서둘러 끝내 버리는 경향을 "컨텍스트 불안(context anxiety)"이라고 불러요. 컨텍스트 한계에 가까워졌다고 느낄 때 나타나는데, 특히 Sonnet 4.5에서 심했다고 해요.

다른 하나는 자기 평가의 실패입니다. 에이전트에게 자기 작업을 평가하라고 하면 평범한 결과도 자신 있게 좋다고 말해요. UI 디자인처럼 맞고 틀림을 가르기 어려운 영역에서 더 심합니다. 그래서 일하는 에이전트와 판단하는 에이전트를 나눠요. 생성자와 평가자를 따로 두고 서로 견제하게 하는 방식이에요.

효과는 숫자로도 나왔어요. OpenAI는 엔지니어 세 명이 5개월 동안 코드를 한 줄도 직접 쓰지 않고, Codex 에이전트가 일할 환경만 설계했어요. LangChain은 모델은 그대로 두고 하네스만 고쳐서, 터미널 작업 벤치마크(Terminal Bench 2.0) 순위를 30위권에서 5위권으로 올렸다고 소개했습니다.

하네스는 세 가지 재료로 이뤄져요

OpenAI 팀은 자기들 경험으로 하네스의 재료를 이렇게 정리했어요.

자동 강제에서 실패만 전달하는 데는 이유가 있어요. 통과한 테스트 결과 수천 줄을 다 보여 주면 에이전트가 그걸 읽느라 정작 할 일을 놓쳐요. BMAD나 Spec Kit도 결국 이 재료를 각자 방식으로 조립한 것입니다.

하네스를 쓰면 실제로 동작하는 앱이 나왔어요

Anthropic은 "2D 레트로 게임 메이커를 만들어라"라는 한 줄 프롬프트를 단독 에이전트와 하네스에 각각 줬어요.

단독 에이전트가 만든 앱은 겉보기엔 그럴듯했지만 키보드 입력에 반응하지 않았어요. 엔티티 정의와 게임 실행 부분이 연결돼 있지 않았거든요. 하네스 쪽은 플래너가 한 줄 프롬프트를 16개 기능, 10개 스프린트 명세로 늘리고, 생성자가 스프린트마다 구현하고, 평가자가 Playwright MCP로 브라우저를 직접 조작하며 테스트했어요. 캐릭터가 실제로 움직이고 점프하는 게임이 나왔습니다.

비용은 이랬어요.

20배 넘게 비쌌어요. 하지만 한쪽은 동작하지 않는 프로토타입이었고, 다른 쪽은 실제로 동작하는 앱이었습니다. 지난 몇 달 동안 하네스 엔지니어링이 주목받은 이유가 이 차이였어요.

6개월도 안 돼서 하네스도 바뀌었어요

프레임워크가 기대던 가정이 실제로 어떻게 무너졌는지는 Anthropic 엔지니어링 블로그의 Prithvi Rajasekaran이 기록으로 남겼어요. 모델이 바뀔 때마다 자기 하네스의 구성 요소를 하나씩 빼 보며 단순하게 만든 기록입니다.

"하네스의 모든 구성 요소는 모델이 혼자 할 수 없는 일에 대한 가정을 담고 있다. 그 가정들은 틀릴 수도 있고, 모델이 발전하면 금방 낡기 때문에 반드시 검증해야 한다."

팀원분은 새것을 쫓는 일을 경계했고, 이 저자는 낡아 가는 가정을 계속 검증하라고 해요. 도구가 빨리 낡는다는 같은 현상을 보고 나온 처방이 둘이었습니다.

Anthropic의 하네스는 모델이 바뀔 때마다 이렇게 달라졌어요.

이걸 처음 봤을 때 "이게 불과 몇 달 전의 베스트 프랙티스였는데" 싶었어요.

플래너와 평가자는 남았어요

그런데 저자는 플래너와 평가자는 남겼어요. 플래너를 빼면 생성자가 명세 없이 시작해 결과물이 빈약해졌고, 평가자를 빼면 자기 작업을 관대하게 평가하는 문제가 그대로 남았어요. 평가자가 남긴 피드백은 이런 식이었습니다.

파일 이름과 줄 번호, 원인까지 짚어요. 실제로 앱을 만져 보며 쓴 QA 리포트에 가깝습니다. 자기 평가에 맡기지 않고 평가자를 따로 둬야 하는 이유가 이 표에 들어 있어요.

모델이 바뀌어도 오래 남는 것이 있어요

하네스의 구성 요소는 모델 버전에 따라 낡는 것과, 모델이 바뀌어도 오래 남는 것으로 나눌 수 있어요.

모델 버전에 따라 낡는 것은 마이크로 태스크 분할, 스프린트 계약, 컨텍스트 리셋처럼 "모델이 약하다"는 가정 위에 세운 것들이에요. 모델이 세지면 과해지고, 때로는 방해가 됩니다. LangChain도 자사 리서치 에이전트를 모델이 바뀔 때마다 여러 번 다시 설계했다고 해요.

오래 남는 것은 컨텍스트 파일, 자동 강제, 생성자와 평가자의 분리, 루브릭으로 적어 둔 평가 기준이에요. 모델의 약점을 메우는 방법이라기보다 협업의 기본 구조에 가깝기 때문이에요. 사람끼리 일할 때도 온보딩 문서와 자동 검증, 작성자와 리뷰어의 분리, 분명한 완료 기준은 필요합니다.

이 구분에는 반론이 있을 수 있어요. 생성자와 평가자를 나누는 것도 결국 "모델이 자기 작업을 공정하게 평가하지 못한다"는 가정 위에 있어서, 그 가정이 낡으면 오른쪽 열도 왼쪽으로 옮겨 갈 수 있어요. 그래서 이 표는 변하는 것과 변하지 않는 것을 가르기보다 낡는 속도를 비교한 표예요. 그래도 오른쪽 열은 사람끼리의 협업에서도 오래 살아남은 구조라서, 왼쪽 열보다 훨씬 천천히 낡을 거라고 생각합니다.

좋은 결과의 기준은 사람이 정해요

오래 남을 것 가운데 하나로 루브릭 기반 평가를 꼽고 싶어요. Anthropic이 프런트엔드 평가에 쓴 기준은 네 가지예요.

• 디자인 완성도(Design quality): 색상, 타이포그래피, 레이아웃이 하나의 정체성으로 묶이는가, 아니면 부품의 집합처럼 보이는가
• 독창성(Originality): 디자이너가 의도한 선택이 보이는가, 아니면 템플릿과 기본값의 조합인가. 흰 카드 위 보라색 그라데이션 같은 AI 특유의 패턴은 감점
• 기술적 완성도(Craft): 타이포그래피 위계, 간격 일관성, 색 조화, 대비 비율 같은 기본기
• 기능성(Functionality): 디자인과 별개로, 사용자가 인터페이스를 이해하고 할 일을 끝낼 수 있는가

저자는 Claude가 기술적 완성도와 기능성은 이미 잘 해내서 디자인 완성도와 독창성에 가중치를 더 줬다고 해요. AI가 자꾸 흰색 바탕에 보라색 그라데이션으로 수렴하는 경향도 감점 항목으로 적어 뒀어요. 모델의 기본 편향을 루브릭으로 바로잡는 방식입니다.

루브릭이 오래 남는 이유는, 모델이 아무리 똑똑해져도 무엇이 좋은 결과인지는 사람이 정해야 하기 때문이에요. 그 기준을 점수로 적어 두면 사람과 에이전트가 같은 기준을 보고 이야기할 수 있습니다.

그래서 프레임워크보다 원리에 시간을 써요

"매 순간마다 구미가 당겨오지만 장기 프로젝트 방향성에는 옳지 않다." 팀원분의 이 말에 지금 저는 프레임워크보다 원리에 시간을 쓰자고 답하고 싶어요. BMAD와 Spec Kit 같은 이름은 1년 뒤에는 잊혔거나 다른 모습이 되어 있을 거예요. 하지만 생성자와 평가자를 나누고, 완료 기준을 루브릭으로 적고, 프로젝트의 전제를 문서로 남기는 원리는 남을 거라고 생각합니다.

당장은 작게 시작하면 돼요. 개인 프로젝트나 작은 팀이라면 CLAUDE.md 한 파일과 pre-commit hook 하나면 충분해요. Mitchell Hashimoto가 만든 터미널 앱 Ghostty의 AGENTS.md도 처음부터 완벽하게 설계된 파일이 아니에요. 에이전트가 실패할 때마다 한 줄씩 늘어난 파일입니다. 첫 줄은 "테스트는 pnpm test로 돌린다"나 "이 폴더는 생성 코드라 직접 고치지 않는다"처럼 에이전트가 실제로 틀렸던 것 한 줄이면 됩니다. 저도 이 블로그 저장소에 그런 하네스를 두고 있어요. 글을 쓰는 에이전트와 문체를 검수하는 에이전트를 나눠 두고, 어색한 표현이 나올 때마다 금지 목록이 한 줄씩 늘어나요.

길게 보면 원리를 익혀야 해요. 다음 유행이 와도 흔들리지 않으려면 지금 뜨는 도구의 사용법보다 그 도구들이 공통으로 기대는 원리를 알아야 해요. 앞의 표에서 오른쪽 열에 둔 것들이에요. BMAD든 Spec Kit이든 그 원리를 각자 방식으로 구현한 거라, 원리를 알고 있으면 다음 프레임워크가 나와도 낯설지 않을 겁니다.

프레임워크를 쫓아본 시간이 헛수고였다는 말은 아니에요. 저도 이 원리들을 프레임워크를 써 보며 배웠어요. 거기서 가져올 것은 사용법보다 그 아래의 원리라는 거예요. 새 모델이 나올 때마다 Anthropic 저자의 말처럼 "더 이상 짐이 되는 부분은 덜어내고, 이전에는 불가능했던 새 가능성이 열린 곳을 찾으면" 됩니다.

이 글도 유통기한이 있어요

새것을 놓칠까 봐 조바심 내는 마음에서 저도 자유롭지 못해요. 재미있어 보이는 도구를 보자마자 메신저에 공유한 사람이 저였습니다.

그래서 스스로 약속을 하나 했어요. 새 프레임워크가 나올 때마다 "이거 써 봐야 하나?"를 묻기 전에 "이게 어떤 약점을 전제로 만들어졌는가?"를 먼저 묻고, 그 약점이 지금 쓰는 모델에도 남아 있는지 확인하기로 했어요. 앞에서 BMAD를 뜯어본 방식이 이 질문이었어요. 그 가정을 계속 검증하는 일이 제가 찾은 것 가운데 가장 오래 남을 습관이라고 생각합니다.

이 글도 1년 뒤에는 어딘가 낡아 있을 거예요. 지금 오래 남는다고 적은 것 가운데 일부는 또 모델에 흡수돼 있을 수 있어요. 그래도 괜찮다고 생각해요. 낡은 부분은 낡은 대로 읽고, 남는 부분만 챙기면 됩니다.

그리고 또 1년쯤 지나면 저는 또 재미있어 보이는 도구를 메신저에 공유하고 있을 거예요. 팀원분들은 또 "요즘 또 새로 나온 그거 있잖아요..." 하고 답할 거고, 저는 또 무엇이 오래 남을지 가려내고 있을 겁니다.

참고자료

• Anthropic Engineering, Harness design for long-running application development (새 창에서 열림)
• Anthropic Engineering, Effective harnesses for long-running agents (새 창에서 열림)
• OpenAI, 하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기 (새 창에서 열림)
• Mitchell Hashimoto, My AI Adoption Journey (새 창에서 열림)
• LangChain, Improving Deep Agents with Harness Engineering (새 창에서 열림)