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

며칠 전 팀 메신저에 프로젝트에 맞는 에이전트 환경을 자동으로 만들어 주는 도구 하나를 공유했습니다. 좋아 보였거든요.

한 팀원분이 거기에 OpenAI의 harness-engineering 글을 덧붙이며 이런 말을 남겼어요.

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

며칠이 지났는데도 이 문장이 계속 남았어요. 제가 흥미로운 도구를 공유하자마자 돌아온 반응이었기 때문이에요. 그 한마디가 질문처럼 다가왔습니다. 나는 지금 뭘 쫓고 있는 거지?

이 글에서는 그 질문에서 출발해 프롬프트 엔지니어링부터 하네스 엔지니어링까지 이어지는 흐름을 짚어봤습니다. 몇 달 만에 베스트 프랙티스가 낡아버리는 현상 속에서 무엇이 남고 무엇이 사라지는지를 고민해봤어요.

또 새 용어를 배워야 한다

최근 몇 년 동안 LLM을 활용하는 방식을 가리키는 말이 꽤 자주 바뀌었어요. 그리고 이전 방식이 약속을 지키지 못한 자리에서 다음 방식이 나오는 식이었어요.

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

그래서 컨텍스트 엔지니어링이 등장했어요. 프롬프트만 잘 써봐야 소용없으니 배경 정보까지 같이 줘야 한다는 이야기였습니다. 그 연장선에서 모델에 외부 도구와 지식을 연결해 주는 MCP나 Skills 같은 규격도 나왔어요. 하지만 완벽한 컨텍스트와 도구를 쥐여줘도, 그걸 소비하는 작업 루프 자체가 잘못 설계되면 여전히 실패했어요.

그래서 이번엔 에이전트가 일하는 환경 전체를 설계하는 쪽으로 초점이 옮겨갔어요. 그게 하네스 엔지니어링입니다. 2026년 2월 Mitchell Hashimoto의 글 (새 창에서 열림)을 계기로 빠르게 퍼진 말인데, 두 달 만에 적어도 AI 코딩 커뮤니티에서는 중심 용어 중 하나가 됐어요.

용어가 이렇게 빨리 갈아치워지면 피로합니다. 지난번에 배운 게 아직 몸에 붙지도 않았는데 벌써 "그건 옛날 방식이고 이제는..."이 시작되거든요. BMAD (새 창에서 열림) 써볼까 하다가 Spec Kit (새 창에서 열림)이 뜨고, 이제 좀 정리됐나 싶었는데 Anthropic이 그중 상당수는 이제 과잉이라고 말합니다. 팀원분의 말은 이 피로감을 정확히 짚어낸 한마디였어요.

하지만 한 가지는 짚어두고 싶어요. 프롬프트에서 컨텍스트로, 다시 하네스로 이어지는 이 전환들은 서로를 지우지 않아요. 프롬프트 엔지니어링은 하네스 안의 한 층으로 자리를 옮겼을 뿐이에요. 최근에 읽은 "프롬프트에서 하네스까지, AI 에이전틱 패턴 4년의 기록" (새 창에서 열림)이라는 해설 글에서 이 흐름을 이렇게 정리하고 있었어요.

"엔지니어링의 엄밀함은 사라진 게 아니라 프롬프트에서 컨텍스트로, 컨텍스트에서 하네스로 위치를 옮겼을 뿐이다."

이 한 줄을 읽고 생각이 정리됐어요. 그렇다면 용어 피로는 사실 변화의 피로가 아니라 축적의 피로에 가깝습니다. 피로한 건 맞지만, 배운 게 헛수고는 아니에요.

다만 한 가지 주의할 게 있습니다. 축적되는 건 각 패러다임이 발견한 원리지, 그 원리를 담아냈던 특정 프레임워크가 아닙니다. 원리는 쌓이지만 프레임워크는 낡습니다.

그 프레임워크들이 딛고 있던 가정

BMAD나 Spec Kit 같은 프레임워크들을 하나하나 뜯어보면 공통점이 보여요. 각 요소에 "모델이 혼자서는 못 한다"는 가정이 깊이 박혀 있거든요.

작업을 마이크로 태스크로 잘게 쪼개는 건 모델이 한 번에 큰 덩어리를 못 다루기 때문이고, 컨텍스트 리셋과 공격적인 세션 분리를 하는 건 모델이 긴 작업에서 일관성을 잃어버리기 때문이에요. 스프린트마다 완료 기준을 미리 못 박는 계약을 강제하는 것도 모델이 중간에 방향을 놓치거나 "다 됐다"고 조기 종료해 버리는 경향 때문이에요. 전부 약점 보완책입니다.

특히 이 프레임워크들이 컨텍스트 분리에 집중했어요. 세션을 잘게 자르고, 매번 깨끗한 상태에서 다시 시작하게 하고, 외부 문서로 상태를 넘겨주는 방식이에요. Claude의 이전 모델인 Sonnet 4.5 시절에는 긴 작업에서 일관성을 잃는 문제가 심해서 이게 가장 확실한 해법이었어요. 이전에 유행한 프레임워크들은 대부분 모델이 지금보다 약하던 시기의 제약을 전제로 설계됐어요.

그런데 Claude의 최신 모델인 Opus 4.6이 나오면서 그 가정 중 상당수가 이미 낡아버렸습니다. 컨텍스트 창이 100만 토큰(책 여러 권 분량)으로 커진 것 때문만은 아니에요. 모델이 한 세션을 몇 시간 이어가도 일관성을 잃지 않고, 자기 실수를 스스로 잡아내고, 더 큰 코드베이스를 다룰 수 있게 됐기 때문이에요. 컨텍스트 분리가 풀려고 했던 문제 자체가 사라진 셈이에요.

역설은 여기서 생겨요. 예전에 만든 프레임워크들이 이제 새 모델 성능에 비해 오히려 오버헤드가 되어버렸습니다. 모델이 혼자서 능숙하게 할 수 있는 일을 굳이 여러 단계로 쪼개서 강제하면, 단계 사이에서 작은 오류가 번지며 결과가 더 나빠질 수 있어요. 약했을 때는 도움이던 구조가, 강해지고 나니 짐이 된 거예요. 이게 지난 몇 달 사이에 실제로 벌어진 일이에요.

그래서 하네스에 대해서도 처음엔 거리감이 있었어요. 또 새 용어, 또 새 프레임워크, 또 몇 달 쓰다 버리는 것. 그런데 Anthropic 엔지니어링 블로그 원문을 읽고 나서 생각이 조금 달라졌습니다. 피로감 자체는 정당하지만 모든 유행을 같은 눈으로 볼 필요는 없겠다는 생각이 들었어요. 유행하는 프레임워크와 그 아래에 깔린 원리는 구분할 필요가 있어요.

그럼에도 하네스는 진짜다

하네스(Harness)의 원래 뜻은 말에 채우는 마구입니다. 고삐와 안장, 굴레. 야생말의 힘을 원하는 방향으로 모으는 도구예요.

LLM이 딱 그런 상태예요. Claude도 GPT도 Gemini도, 모델 자체는 야생말이에요. 혼자 풀어놓으면 어디로 튈지 몰라요. 하네스는 그 힘을 억누르지 않고, 제어하면서 최대한 끌어내는 구조입니다.

Mitchell Hashimoto의 정의는 이래요.

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

단순한 정의지만 중요한 포인트가 있어요. 프롬프트에 "이거 하지 마"라고 쓰는 건 부탁입니다. 부탁은 받는 쪽이 언젠가 또 어깁니다. 하네스 엔지니어링은 그 실수 자체가 구조적으로 불가능한 환경을 만드는 일입니다. WHO의 수술 안전 체크리스트와 비슷한 발상이에요. 베테랑 외과의에게 "환자 신원 한번 더 확인해주세요"라고 부탁하는 것만으로는 사고가 사라지지 않아요. 그래서 확인 항목을 체크리스트로 만들어 수술 절차 안에 심었습니다. 사람의 기억력이나 집중력 대신 절차 자체에 안전을 두는 거예요.

그리고 한 가지 재미있는 사실이 있습니다. 우리는 이미 하네스를 쓰고 있었습니다. LLM은 원래 텍스트를 넣으면 텍스트를 뱉는 함수예요. 혼자서는 이전 대화를 기억하지 못해요. 그런데 우리가 Claude나 ChatGPT와 대화할 때 이전 메시지가 유지되는 건, 챗 UI가 대화 내용을 계속 모아서 매번 새로 전달해 주기 때문이에요. 그 루프 자체가 이미 하네스예요. 하네스는 거창하게 멀리 있는 개념이 아니에요. 매일 쓰는 채팅창이 이미 그 위에서 돌아가고 있어요.

하네스가 풀려고 했던 두 문제

하네스가 왜 등장했는지를 생각해 보면 두 가지 문제에서 출발해요.

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

• 한 번에 해결하려다 컨텍스트 창이 바닥나서 절반만 구현됐고, 다음 세션에서는 어디까지 했는지 기억이 없어 처음부터 다시 파악해야 했어요
• 어느 정도 진행된 뒤에 그냥 "다 됐네" 하고 조기 종료를 선언했어요. 사실 아직 한참 남았는데도요

뒤쪽을 Anthropic은 "컨텍스트 불안(context anxiety)"이라고 불러요. 모델이 컨텍스트 한계에 가까워졌다고 느끼면 일을 서둘러 마무리하려는 경향인데, 특히 Sonnet 4.5에서 심했다고 해요.

다른 하나는 자기 평가의 실패입니다. 정보의 문제가 아니라 판단의 문제예요. 에이전트에게 자기 작업을 평가해 보라고 하면 품질이 평범해도 자신 있게 좋다고 말해요. 특히 UI 디자인처럼 이진 체크가 불가능한 주관적 영역에서 더 심해요. 해결책은 단순합니다. 일하는 에이전트와 판단하는 에이전트를 분리하는 겁니다. 생성자와 평가자를 따로 두고 서로 견제하는 피드백 루프를 돌리는 거예요. 생성 모델과 판별 모델을 맞세우는 GAN에서 Anthropic이 영감을 받았다고 해요.

하네스는 이 두 문제를 해결하려고 나온 접근이에요. 그리고 실제로 꽤 잘 작동해요.

숫자로 보면 더 분명해요. OpenAI는 (새 창에서 열림) 엔지니어 3명이 5개월 동안 코드 한 줄도 쓰지 않고 Codex 에이전트가 일할 환경을 설계했어요. AGENTS.md, CI 게이트, 저장소 가독성 개선, 아키텍처 경계 강제, 리뷰 루프, 주기적인 가비지 컬렉션 같은 것들이었어요. 그들이 한 일은 코드 작성보다 시스템 만들기에 가까웠어요. LangChain도 (새 창에서 열림) 모델은 그대로 두고 하네스만 개선해서, 터미널에서 에이전트가 실제 작업을 얼마나 해내는지 재는 벤치마크(Terminal Bench 2.0) 기준 상위 30위권에서 상위 5위권으로 올라갔다고 소개한 적이 있어요. 모델 지능 못지않게 하네스가 에이전트 성능을 좌우한다는 증거로 인용되는 사례예요.

하네스의 세 기둥

OpenAI 팀이 자기들 경험으로 정리한 하네스의 재료는 크게 세 가지예요.

처음은 컨텍스트 파일입니다. CLAUDE.md, AGENTS.md 같은 파일이에요. 매 세션을 깨끗한 상태로 시작하는 에이전트에게 "이 프로젝트는 어떤 컨벤션을 따르고, 어떤 함정을 피해야 하는지"를 가장 먼저 알려주는 거예요. 신입 개발자가 첫 주에 읽는 README와 역할이 비슷한데, 다른 점이라면 이 README의 독자가 매일 기억을 잃은 채로 출근한다는 겁니다. OpenAI 팀은 이 파일을 설명서가 아니라 지도처럼 쓰라고 해요. 100줄 안팎으로 항상 적용되는 내용만 담고, 세부는 다른 파일로 분리하라는 겁니다.

그다음은 자동 강제 시스템입니다. 린터, pre-commit hook, 자동 교정 루프 같은 것들이에요. 린터가 빨간불을 켜면 에이전트가 스스로 코드를 수정해요. 여기에 한 가지 중요한 원칙이 있어요. 성공은 조용히, 실패만 시끄럽게. 통과한 테스트 결과 수천 줄을 다 보여주면 에이전트가 그걸 읽느라 정작 할 일을 놓칩니다. 그래서 실패한 케이스만 전달하고, 성공은 말없이 넘기는 거예요.

마지막은 가비지 컬렉션입니다. 주기적으로 도는 청소 에이전트가 문서와 코드가 어긋났는지, 규칙 위반 코드가 생겼는지, 쓰지 않는 코드가 쌓였는지 점검하고 수정해요. 에이전트가 실수할 때마다 새 규칙이 추가되면서 하네스가 점점 정교해지는 구조예요.

BMAD나 Spec Kit 같은 프레임워크들도 결국 같은 재료를 각자 방식으로 조립한 것들이에요. 플래닝과 구현과 평가를 나누고, 각 단계를 엄격하게 강제합니다.

그래서 실제로 이게 뭘 만들어내는가

Anthropic이 이 접근으로 만든 실제 결과물을 공개한 적이 있어요. "2D 레트로 게임 메이커를 만들어라"는 한 줄 프롬프트를 하나는 단독 에이전트에게, 하나는 풀 하네스에게 줬습니다. 결과는 극단적으로 갈렸어요.

단독 에이전트가 만든 앱은 열어 보면 그럴듯하지만 실제로는 동작하지 않았습니다. 엔티티 정의와 게임 런타임 사이의 배선이 끊어져 있어서 키보드 입력에 아무 반응이 없었거든요. 풀 하네스가 만든 앱은 달랐어요. 플래너가 한 줄 프롬프트를 16개 피처, 10개 스프린트 명세로 확장했고, 생성자가 스프린트마다 구현하고, 평가자가 Playwright MCP로 직접 브라우저를 조작하며 테스트했습니다. 실제로 캐릭터가 움직이고 점프하는 게임이 나왔어요.

비용은 이랬어요.

20배 이상 비쌌습니다. 하지만 한쪽은 고장난 프로토타입이었고, 한쪽은 실제로 작동하는 앱이었습니다. 이 숫자가 지난 몇 달 동안 "하네스 엔지니어링이 왜 뜨거운가"에 대한 가장 설득력 있는 답이었어요.

여기까지가 "옛날"의 이야기입니다. 정확히는 몇 달 전의 이야기예요.

그런데 6개월도 안 돼서

앞에서 말한 "프레임워크들이 딛고 있던 가정"이 실제로 어떻게 무너졌는지는, Anthropic 엔지니어링 블로그 저자 Prithvi Rajasekaran이 직접 기록으로 남겼습니다 (새 창에서 열림). 정식 연구라기보다 모델이 업그레이드될 때마다 자기들 하네스 구성 요소를 하나씩 빼보면서 단순화해 본 기록에 가까워요.

이 글을 읽다가 한 문장에서 멈췄어요.

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

제가 앞에서 했던 이야기를 저자가 엔지니어의 언어로 다시 말하고 있었어요. 팀원분은 새것을 쫓는 일을 경계했고, 이 저자는 낡아가는 가정을 계속 검증하라고 합니다. 도구가 빨리 낡는다는 같은 현상을 놓고 나온 두 개의 처방인 셈이에요.

Anthropic의 하네스는, 제가 글을 읽으며 이해한 바로는 대략 세 단계를 거쳤어요.

초기 하네스(2025년 11월, Sonnet 4.5)는 Initializer와 Coding Agent의 2-에이전트 구조였습니다. 작업을 피처 단위로 쪼개고, 세션 간에는 컨텍스트를 완전히 리셋했어요. Sonnet 4.5의 컨텍스트 불안이 심해서 압축만으로는 부족하고 완전 리셋이 필요했기 때문이에요.

3-에이전트 하네스(Opus 4.5)는 Planner와 Generator, Evaluator 구조입니다. 한 줄 프롬프트를 16개 피처, 10개 스프린트 명세로 확장하고, 스프린트마다 생성자와 평가자가 계약을 협상한 뒤 빌드와 평가를 반복했어요. 위에서 본 게임 메이커가 이 단계의 결과물이에요.

단순화된 하네스(Opus 4.6)에서는 스프린트 구조 자체가 제거됐습니다. Opus 4.6이 계획을 더 신중하게 세우고, 에이전트 작업을 더 오래 지속하고, 더 큰 코드베이스를 다루고, 자기 실수를 잡아내는 능력이 향상됐기 때문이에요. 한 세션을 계속 이어서 돌려도 일관성이 무너지지 않았어요. 컨텍스트 리셋도, 스프린트 계약도 더 이상 필요 없었습니다.

이 연구 결과를 처음 봤을 때 든 생각은 이거였어요. "이게 불과 몇 달 전의 베스트 프랙티스였는데."

그런데 여전히 살아남은 것들

흥미로운 건 저자가 플래너와 평가자는 그대로 남겼다는 점이에요. 플래너를 빼면 생성자가 명세 없이 시작해서 결과물이 빈약해졌고, 평가자를 빼면 여전히 자기 작업을 관대하게 평가하는 문제가 남았어요. 특히 평가자가 만들어내는 피드백은 "리뷰 에이전트 하나 붙이기" 수준을 훌쩍 넘어요.

파일명과 라인 번호, 구체적인 원인까지 짚어내요. 시니어 QA 엔지니어가 돌아가는 앱을 실제로 만져보며 내놓는 리포트에 가깝습니다. 자기 평가에 맡기지 않고 독립된 평가자를 둬야 하는 이유가 이 표 하나에 다 들어있어요.

본질과 유행 사이

곰곰이 따져보면 하네스 구성 요소는 두 종류로 나뉩니다.

모델 버전에 종속된 것들이 있습니다. 마이크로 태스크 분할, 스프린트 계약, 컨텍스트 리셋, 공격적인 컨텍스트 분리. 이것들은 모두 "모델이 약하다"는 가정 위에 세워진 장치예요. 모델이 세지면 자연스럽게 과잉이 되고, 때로는 오히려 방해가 됩니다. LangChain도 자사의 리서치 에이전트(Deep Research)를 모델이 바뀔 때마다 여러 차례 다시 설계했다고 해요. 어제의 베스트 프랙티스가 오늘의 오버헤드입니다.

모델 버전과 무관한 본질적인 것들도 있습니다. 컨텍스트 파일(프로젝트의 전제와 금기를 담는 온보딩 문서), 자동 강제 시스템(부탁이 아닌 강제), 생성자와 평가자의 분리, 항목별 채점표(루브릭)로 적어둔 평가 기준. 이것들은 모델이 어떻게 발전하든 살아남을 가능성이 높아요. 모델의 약점 보완책이라기보다 협업의 근본 구조에 가깝기 때문이에요. 사람 간의 협업에서도 온보딩 문서와 자동화된 검증, 작성자와 리뷰어의 분리, 명확한 완료 기준은 필요합니다.

두 종류를 나란히 놓으면 이렇습니다.

이 구분에는 바로 반론이 가능해요. 생성자와 평가자 분리도 결국 "모델이 자기 작업을 공정하게 평가하지 못한다"는 가정 위의 장치라서, 그 가정이 낡으면 오른쪽 열도 왼쪽으로 옮겨갈 수 있습니다. 맞는 말이에요. 그래서 이 표는 변하는 것과 안 변하는 것의 이분법이라기보다 낡는 속도의 스펙트럼입니다. 그래도 오른쪽 열에 걸 만한 이유는 있어요. 사람끼리의 협업에서도 수십 년을 살아남은 구조라서, 왼쪽 열보다 훨씬 천천히 낡을 겁니다.

좋은 결과의 기준은 누가 정하는가

루브릭 기반 평가는 오래 남을 본질이라고 생각해요. Anthropic이 프런트엔드 평가에 쓴 네 가지 기준은 이래요.

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

저자는 Claude가 이미 완성도와 기능성은 잘 해내니까, 디자인 완성도와 독창성에 더 높은 가중치를 줬다고 해요. 특히 "AI가 자꾸 보라색+흰색 그라데이션으로 수렴하는 문제"를 명시적으로 감점 대상으로 박아넣은 건 꽤 웃기면서도 영리해요. 모델의 기본 편향을 루브릭으로 부수는 방식이니까요.

이런 루브릭이 본질인 이유는, 모델이 아무리 똑똑해져도 "무엇이 좋은 결과인가"에 대한 기준은 사람이 정해줘야 하기 때문입니다. 그리고 그 기준을 명시적인 점수 체계로 만들면 사람과 에이전트 모두 같은 걸 보고 이야기할 수 있어요.

그래서 지금 제 답은 이렇습니다. 프레임워크에 베팅하지 말고 원리에 베팅하자. BMAD와 Spec Kit 같은 이름들은 1년 뒤에는 잊혔거나 다른 모습이 되어 있을 거예요. 하지만 "생성자와 평가자를 분리한다", "완료 기준을 루브릭으로 명시한다", "프로젝트의 전제를 문서로 남긴다" 같은 원리는 남을 거예요.

엄밀함의 재배치

Anthropic 블로그의 저자는 글을 이렇게 마무리해요.

"흥미로운 하네스 조합의 공간은 모델이 발전한다고 줄어들지 않는다. 그저 이동할 뿐이다. AI 엔지니어의 흥미로운 일은 다음 새로운 조합을 계속 찾는 것이다."

이 문장이 마음에 남았어요. 모델이 세지면 어떤 하네스 요소는 사라지지만, 동시에 이전엔 불가능했던 더 복잡한 작업에 하네스를 적용할 여지가 열려요. 하네스의 총량이 줄어드는 게 아니라 그 자리가 계속 이동하는 거예요.

Chad Fowler는 이 흐름에 "엄밀함의 재배치(relocating rigor)"라는 이름을 붙였고, Martin Fowler가 자기 블로그 단상에서 이 에세이를 소개했어요. 코드 한 줄 한 줄을 정확히 짜던 엄밀함이, 이제는 에이전트가 올바르게 동작하는 시스템을 설계하는 엄밀함으로 옮겨가고 있다는 이야기입니다. 저는 이 변화를 공 차는 선수에서 전술 짜는 감독으로 자리를 옮기는 일로 이해했어요. 엔지니어가 덜 기술적으로 되는 게 아니라, 더 높은 차원의 기술이 요구되는 겁니다.

그래서 무엇에 베팅할 것인가

"매 순간마다 구미가 당겨오지만 장기 프로젝트 방향성에는 옳지 않다."

이 문장에 대한 제 답은 두 갈래예요.

단기적으로는, 과하게 하지 않는 게 좋습니다. 개인 프로젝트나 작은 팀이라면 CLAUDE.md 한 파일과 pre-commit hook 하나로 시작해도 돼요. Mitchell Hashimoto가 만든 터미널 앱 Ghostty의 AGENTS.md도 처음부터 완벽하게 설계된 게 아니에요. 에이전트가 실패할 때마다 한 줄씩 추가되면서 점진적으로 진화한 파일이에요. 한 번에 완벽하게 하려 하지 말고, 실제로 실패한 케이스만 모아서 조금씩 덧붙이면 됩니다. 첫 줄은 거창할 필요 없어요. "테스트는 pnpm test로 돌린다"나 "이 폴더는 생성 코드라 직접 수정하지 않는다"처럼 에이전트가 실제로 틀렸던 것 한 줄이면 됩니다. 저도 이 블로그 저장소에 그런 하네스를 두고 있어요. 글을 쓰는 에이전트와 문체를 검수하는 에이전트를 나눠 놓고, 어색한 표현이 나올 때마다 금지 목록이 한 줄씩 늘어나는 식인데, 이 글도 그 검수를 거쳤습니다. 그리고 한 가지 더 붙이자면 "garbage in, garbage out"입니다. 기획이 구리면 하네스로도 못 살려요. 하네스는 좋은 걸 더 잘 만드는 도구지, 별로인 걸 좋게 만드는 마법이 아닙니다.

장기적으로는, 프레임워크가 아니라 원리를 내재화해야 합니다. 다음 유행이 와도 흔들리지 않으려면, 지금 뜨거운 도구의 사용법을 외우기보다 그 도구들이 공통으로 의지하는 원리를 이해해야 해요. 앞의 표에서 본질 쪽에 놓은 것들이 그 원리들입니다. BMAD든 Spec Kit이든 결국 그 패턴들을 각자 방식으로 구현한 거라서, 이해하고 있으면 다음 프레임워크가 나와도 낯설지 않을 겁니다. 이름만 바뀌었을 뿐이니까요.

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

돌고 돌아 결론은 단순합니다. 바뀌지 않는 층위를 찾고, 거기에 시간을 쓰면 돼요.

하네스 엔지니어링이라는 용어도 어쩌면 1년 후에는 다른 이름으로 불리고 있을지 몰라요. 하지만 그 아래에서 "에이전트의 실수를 구조적으로 반복 불가능하게 만든다"는 원리는 남을 거라고 생각해요. 우리는 그때까지 감독석에서 전술을 짜는 연습을 하면 됩니다.

그리고, 이 글도 유통기한이 있다

사실 이 글을 쓰면서 내내 머릿속에 맴돈 생각이 하나 있어요. 이 글도 유통기한이 있다는 것.

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

그래서 저도 스스로에게 약속 하나를 남깁니다. 새로운 프레임워크가 나올 때마다 "이거 써봐야 하나?"를 묻기 전에, "이게 어떤 약점을 전제로 만들어졌는가?"를 먼저 물어보기로요. 앞에서 BMAD 같은 프레임워크를 뜯어봤던 방식이 사실 이 질문이었어요. 그리고 그 약점이 지금 제가 쓰는 모델에도 여전히 유효한지 확인해 보기로 했어요. Anthropic 저자가 말한 "모델이 혼자 할 수 없는 일에 대한 가정"이에요. 그 가정을 계속 검증하는 일 자체가 제가 찾을 수 있는 가장 유통기한이 긴 층위입니다. 그리고 이 질문 하나가 FOMO를 이기는 가장 실용적인 방법이라고 생각합니다.

이 글도 1년 후에는 아마 어딘가 낡아 있을 겁니다. Opus 4.6이 5.0으로 바뀌어 있을 것이고, 지금 "본질"이라고 적은 것들 중 일부는 또 모델에 흡수되어 있을 거예요. 하지만 그게 무섭지 않습니다. 낡은 부분은 낡은 대로 읽고, 남는 부분만 챙기면 됩니다. 격변하는 시대에 글을 쓰는 사람과 읽는 사람이 서로에게 할 수 있는 가장 솔직한 태도라고 생각해요.

그리고 또 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 (새 창에서 열림)
• bits-bytes-nn, 프롬프트에서 하네스까지 AI 에이전틱 패턴 4년의 기록 (새 창에서 열림)