요즘 에이전트 하네스에 대한 고민
몇 달 전의 베스트 프랙티스가 이미 낡고 있습니다. 그래서 뭘 쫓아야 하는지 고민해봤습니다.
몇 달 전의 베스트 프랙티스가 이미 낡고 있습니다. 그래서 뭘 쫓아야 하는지 고민해봤습니다.
며칠 전 팀 메신저에 revfactory/harness라는 프로젝트를 공유했습니다. 프로젝트에 맞는 에이전트 환경을 자동으로 생성해 주는 도구인데, 좋아 보였습니다.
한 팀원분이 거기에 OpenAI의 harness-engineering 글을 덧붙이며 이런 말을 남겼습니다.
"오픈코드 생태계로 많은 부분이 발전되고 성장하나, 여러 방면의 도구 및 방법론들이 형성되면서 매 순간마다 구미가 당겨오거든요. AI도 마찬가지구요. 장기적인 프로젝트 방향성에는 옳지 않다는 생각이 듭니다."
며칠이 지났는데도 이 문장이 계속 남았습니다. 제가 흥미로운 도구를 공유하자마자 돌아온 반응이었기 때문이에요. 그 한마디가 질문처럼 다가왔습니다. 나는 지금 뭘 쫓고 있는 거지?
이 글에서는 그 질문에서 출발해서, 프롬프트 엔지니어링부터 하네스 엔지니어링까지 이어지는 흐름을 짚어보고, 몇 달 만에 베스트 프랙티스가 낡아버리는 현상 속에서 무엇이 남고 무엇이 사라지는지를 고민해봤습니다.
최근 몇 년 동안 LLM을 활용하는 방식을 가리키는 말이 꽤 자주 바뀌었습니다. 그리고 각 전환은 이전 방식이 약속을 지키지 못한 지점에서 다음이 태어나는 식이었습니다.
처음에는 프롬프트 엔지니어링이었습니다. "웹사이트 만들어줘"보다 "반응형 로그인 페이지, 다크 모드 지원"처럼 구체적으로 명령을 잘 거는 기술이요. 그런데 아무리 정교하게 써도 모델이 우리 프로젝트 구조를 모르면 엉뚱한 답이 나왔습니다.
그래서 컨텍스트 엔지니어링이 등장했습니다. 프롬프트만 잘 써봐야 소용없으니 배경 정보까지 같이 줘야 한다는 이야기였죠. 그 연장선에서 MCP와 Skills 같은 장치들도 나왔습니다. 하지만 완벽한 컨텍스트와 도구를 쥐여줘도, 그걸 소비하는 작업 루프 자체가 잘못 설계되면 여전히 실패했습니다.
그래서 이번엔 루프 자체를 설계하는 쪽으로 초점이 옮겨갔습니다. 그게 하네스 엔지니어링입니다. 2026년 2월 Mitchell Hashimoto의 글을 계기로 빠르게 퍼진 말인데, 두 달 만에 적어도 AI 코딩 커뮤니티에서는 중심 용어 중 하나가 됐습니다.
용어가 이렇게 빨리 갈아치워지면 피로합니다. 지난번에 배운 게 아직 몸에 붙지도 않았는데 벌써 "그건 옛날 방식이고 이제는..."이 시작되거든요. BMAD 써볼까 하다가 Spec Kit이 뜨고, 이제 좀 정리됐나 싶었는데 Anthropic이 "그중 상당수는 이제 과잉입니다"라고 합니다. 팀원 분의 말은 이 피로감을 정확히 짚어낸 한마디였습니다.
하지만 한 가지는 짚어두고 싶습니다. 프롬프트 → 컨텍스트 → 하네스로 이어지는 이 전환들은 서로를 지우는 게 아닙니다. 프롬프트 엔지니어링은 사라진 게 아니라 하네스 안의 한 층으로 자리가 이동했을 뿐이에요. 최근에 읽은 "프롬프트에서 하네스까지 — AI 에이전틱 패턴 4년의 기록"이라는 해설 글에서 이 흐름을 이렇게 정리하고 있었습니다.
"엔지니어링의 엄밀함은 사라진 게 아니라 프롬프트에서 컨텍스트로, 컨텍스트에서 하네스로 위치를 옮겼을 뿐이다."
이 한 줄이 꽤 정곡을 찔렀습니다. 그렇다면 용어 피로는 사실 변화의 피로가 아니라 축적의 피로에 가깝습니다. 피로한 건 맞지만, 배운 게 헛수고는 아니에요.
다만 한 가지 주의할 게 있습니다. 축적되는 건 각 패러다임이 발견한 원리지, 그 원리를 담아냈던 특정 프레임워크가 아닙니다. 원리는 쌓이지만 프레임워크는 낡습니다.
BMAD나 Spec Kit 같은 프레임워크들을 하나하나 뜯어보면 공통점이 보입니다. 각 요소에 "모델이 혼자서는 못 한다"는 가정이 깊이 박혀 있거든요.
작업을 마이크로 태스크로 잘게 쪼개는 건 모델이 한 번에 큰 덩어리를 못 다루기 때문이고, 컨텍스트 리셋과 공격적인 세션 분리를 하는 건 모델이 긴 작업에서 일관성을 잃어버리기 때문입니다. 스프린트마다 완료 기준을 미리 못 박는 계약을 강제하는 것도 모델이 중간에 방향을 놓치거나 "다 됐다"고 조기 종료해 버리는 경향 때문이고요. 전부 약점 보완책입니다.
특히 대부분의 프레임워크가 컨텍스트 분리에 집중했습니다. 세션을 잘게 자르고, 매번 깨끗한 상태에서 다시 시작하게 하고, 외부 문서로 상태를 넘겨주는 방식이요. Sonnet 4.5 시절에는 모델이 긴 작업에서 일관성을 잃는 문제가 심해서 이게 핵심 돌파구였습니다. 이전에 유행했던 프레임워크들은 전부 이 시기의 제약을 전제로 설계된 것들입니다.
그런데 Opus 4.6이 나오면서 그 가정 중 상당수가 이미 낡아버렸습니다. 100만 토큰 컨텍스트 창 때문만은 아닙니다. 모델이 한 세션을 몇 시간 이어가도 일관성을 잃지 않고, 자기 실수를 스스로 잡아내고, 더 큰 코드베이스를 다룰 수 있게 됐기 때문이에요. 컨텍스트 분리가 풀려고 했던 문제 자체가 사라진 셈입니다.
역설은 여기서 생깁니다. 예전에 만든 프레임워크들이 이제 새 모델 성능에 비해 오히려 오버헤드가 되어버렸습니다. 모델이 혼자서 능숙하게 할 수 있는 일을 굳이 여러 단계로 쪼개서 강제하면, 작은 오류 하나가 연쇄적으로 전파되면서 결과가 더 나빠집니다. 약했을 때는 도움이던 구조가, 강해지고 나니 짐이 된 거예요. 이게 지난 몇 달 사이에 실제로 벌어진 일입니다.
그래서 하네스에 대해서도 처음엔 거리감이 있었습니다. 또 새 용어, 또 새 프레임워크, 또 몇 달 쓰다 버리는 것. 그런데 Anthropic 엔지니어링 블로그 원문을 읽고 나서 생각이 조금 달라졌습니다. 피로감 자체는 정당한데, 모든 유행을 같은 눈으로 볼 필요는 없다는 것이요. 유행하는 프레임워크와 그 아래에 깔린 원리는 구분할 필요가 있습니다.
하네스(Harness)의 원래 뜻은 말에 채우는 마구입니다. 고삐, 안장, 굴레. 야생말을 경마장에 풀어놓으면 본능대로 날뛰지만, 마구를 채우면 그 힘이 올바른 방향으로 집중됩니다. 마구가 말을 느리게 만드는 게 아니에요. 오히려 원하는 경로로 빠르고 정확하게 달리게 합니다.
LLM이 딱 그런 상태입니다. Claude, GPT, Gemini — 모델 자체는 야생말이에요. 혼자 풀어놓으면 어디로 튈지 모릅니다. 하네스는 그 힘을 억누르는 게 아니라 제어하면서 최대한 끌어내기 위한 구조입니다.
Mitchell Hashimoto의 정의는 이렇습니다.
"에이전트가 실수를 할 때마다 그 실수가 다시는 반복되지 않도록 엔지니어링 하는 것."
단순한 정의지만 중요한 포인트가 있습니다. 프롬프트에 "이거 하지 마"라고 쓰는 건 부탁입니다. 부탁은 언젠가 또 실수하죠. 하네스 엔지니어링은 그 실수 자체가 구조적으로 불가능한 환경을 만드는 일입니다. WHO의 수술 안전 체크리스트와 비슷한 발상이에요. 베테랑 외과의에게 "환자 신원 한번 더 확인해주세요"라고 부탁하는 것만으로는 사고가 사라지지 않습니다. 그래서 현대 수술실은 체크리스트의 모든 항목에 사인이 들어가기 전까지는 다음 단계로 넘어갈 수 없는 절차로 만들어 뒀어요. 사람의 기억력이나 집중력이 아니라 절차 자체에 안전을 내장하는 거죠.
그리고 한 가지 재미있는 사실이 있습니다. 우리는 이미 하네스를 쓰고 있었습니다. LLM은 원래 텍스트를 넣으면 텍스트를 뱉는 함수에 불과합니다. 혼자서는 이전 대화를 기억하지 못해요. 그런데 우리가 Claude나 ChatGPT와 대화할 때 이전 메시지가 유지되는 건, 챗 UI가 대화 내용을 계속 모아서 매번 새로 전달해 주기 때문입니다. 그 루프 자체가 이미 하네스예요. 하네스는 거창하게 멀리 있는 개념이 아니라, 매일 쓰는 채팅창이 이미 그 위에서 돌아가고 있습니다.
하네스가 왜 등장했는지를 생각해 보면, 두 가지 문제에서 출발합니다.
첫째, 컨텍스트 부패(Context Rot)입니다. Anthropic 연구팀이 Opus에게 claude.ai를 클론해 보라고 시킨 실험이 있었습니다. 두 가지 실패 패턴이 반복됐는데요. 한 번에 해결하려다 컨텍스트 창이 바닥나서 절반만 구현됐고, 다음 세션에서는 어디까지 했는지 기억이 없어 처음부터 다시 파악해야 했습니다. 또 하나는 어느 정도 진행된 뒤에 그냥 "다 됐네" 하고 조기 종료를 선언해 버리는 경우였습니다. 사실 아직 한참 남았는데도요. Anthropic은 이 현상을 "컨텍스트 불안(context anxiety)"이라고 부릅니다. 모델이 컨텍스트 한계에 가까워졌다고 느끼면 일을 서둘러 마무리하려는 경향인데, 특히 Sonnet 4.5에서 심했다고 합니다.
둘째, 자기 평가의 실패입니다. 정보의 문제가 아니라 판단의 문제예요. 에이전트에게 자기 작업을 평가해 보라고 하면 품질이 평범해도 자신 있게 좋다고 말합니다. 특히 UI 디자인처럼 이진 체크가 불가능한 주관적 영역에서 더 심해요. 해결책은 단순합니다. 일하는 에이전트와 판단하는 에이전트를 분리하는 겁니다. 이게 Anthropic이 Generative Adversarial Networks(GAN)에서 영감을 받은 대목이에요. 생성자와 평가자를 따로 두고 적대적 피드백 루프를 돌립니다.
하네스는 이 두 문제를 해결하려고 나온 접근입니다. 그리고 실제로 꽤 잘 작동합니다.
숫자로 보면 더 분명해요. OpenAI는 엔지니어 3명이 5개월 동안 코드 한 줄도 쓰지 않고 Codex 에이전트가 일할 환경을 설계했습니다. AGENTS.md, CI 게이트, 저장소 가독성 개선, 아키텍처 경계 강제, 리뷰 루프, 주기적인 가비지 컬렉션 같은 장치들이었습니다. 결론적으로 그들이 한 일은 코드를 쓰는 게 아니라 시스템을 만드는 일에 가까웠습니다. LangChain도 모델은 그대로 두고 하네스만 개선해 Terminal Bench 기준 상위 30위권에서 상위 5위권으로 올라갔다고 소개한 적이 있습니다. 모델의 지능이 아니라 하네스가 에이전트 성능을 좌우한다는 증거로 자주 인용되는 사례입니다.
지금까지 정리된 하네스의 구성 요소는 세 가지입니다.
첫째는 컨텍스트 파일입니다. CLAUDE.md, AGENTS.md 같은 파일이요. 비유하면 모델이 CPU라면 컨텍스트 파일은 부팅 시 가장 먼저 읽히는 설정 파일에 가깝습니다. 매 세션마다 깨끗한 상태로 시작하는 에이전트에게 "이 프로젝트는 어떤 컨벤션을 따르고, 어떤 함정을 피해야 하는지"를 가장 먼저 알려주는 거예요. 신입 개발자가 첫 주에 읽는 README와 역할이 비슷한데, 다른 점이라면 이 README의 독자가 매일 기억을 잃은 채로 출근한다는 겁니다. OpenAI 팀은 이 파일을 쓸 때 "1,000페이지 설명서가 아니라 지도를 줘라"는 원칙을 강조했습니다. 60줄 이하로, 항상 적용되는 내용만, 세부는 다른 파일로 분리하라고요.
둘째는 자동 강제 시스템입니다. 린터, pre-commit hook, 자동 교정 루프 같은 것들이요. 린터가 빨간불을 켜면 에이전트가 스스로 코드를 수정합니다. 여기에 한 가지 중요한 원칙이 있습니다.
"성공은 조용히, 실패만 시끄럽게(Success is silent, failure is loud)."
통과한 테스트 결과 4,000줄을 다 보여주면 에이전트가 그걸 읽느라 정작 할 일을 놓칩니다. 그래서 실패한 케이스만 전달하고, 성공은 말없이 넘기는 거예요.
셋째는 가비지 컬렉션입니다. 주기적으로 도는 청소 에이전트가 문서와 코드가 어긋났는지, 규칙 위반 코드가 생겼는지, 쓰지 않는 코드가 쌓였는지 점검하고 수정합니다. 에이전트가 실수할 때마다 새 규칙이 추가되면서 하네스가 점점 정교해지는 구조입니다.
이 세 기둥 위에서 BMAD, Spec Kit, Jesse, GSD 같은 프레임워크들이 나왔습니다. 각자 구현은 다르지만 근본적으로 하려는 건 비슷해요. 플래닝과 구현과 평가를 분리하고, 각 단계를 엄격하게 강제하는 것입니다.
Anthropic이 이 접근으로 만든 실제 결과물을 공개한 적이 있습니다. "2D 레트로 게임 메이커를 만들어라"는 한 줄 프롬프트를 하나는 단독 에이전트에게, 하나는 풀 하네스에게 줬습니다. 결과는 극단적으로 갈렸습니다.
단독 에이전트가 만든 앱은 열어 보면 그럴듯하지만 실제로는 동작하지 않았습니다. 엔티티 정의와 게임 런타임 사이의 배선이 끊어져 있어서 키보드 입력에 아무 반응이 없었거든요. 풀 하네스가 만든 앱은 달랐습니다. 플래너가 한 줄 프롬프트를 16개 피처, 10개 스프린트 명세로 확장했고, 생성자가 스프린트마다 구현하고, 평가자가 Playwright MCP로 직접 브라우저를 조작하며 테스트했습니다. 실제로 캐릭터가 움직이고 점프하는 게임이 나왔습니다.
비용은 다음과 같습니다.
20배 이상 비쌌습니다. 하지만 한쪽은 고장난 프로토타입이었고, 한쪽은 실제로 작동하는 앱이었습니다. 이 숫자가 지난 몇 달 동안 "하네스 엔지니어링이 왜 뜨거운가"에 대한 가장 설득력 있는 답이었습니다.
여기까지가 "옛날"의 이야기입니다. 정확히는 몇 달 전의 이야기예요.
앞에서 말한 "프레임워크들이 딛고 있던 가정"이 실제로 어떻게 무너졌는지는, Anthropic 엔지니어링 블로그 저자 Prithvi Rajasekaran이 직접 기록으로 남겼습니다. 형식적인 ablation study는 아니고, 모델이 업그레이드될 때마다 자기들 하네스 구성 요소를 하나씩 빼보면서 단순화해 본 과정에 가깝습니다.
이 글을 읽다가 한 문장에서 멈췄습니다.
"하네스의 모든 구성 요소는 모델이 혼자 할 수 없는 일에 대한 가정을 담고 있다. 그 가정들은 틀릴 수도 있고, 모델이 발전하면 금방 낡기 때문에 반드시 검증해야 한다."
제가 앞에서 했던 이야기를 저자가 엔지니어의 언어로 다시 말하고 있었습니다. 그리고 이게 팀원분의 말과 정반대 각도에서 같은 현상을 가리키고 있었어요. 같은 문제에 대한 두 개의 처방인 셈입니다.
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이 계획을 더 신중하게 세우고, 에이전트 작업을 더 오래 지속하고, 더 큰 코드베이스를 다루고, 자기 실수를 잡아내는 능력이 향상됐기 때문입니다. 한 세션을 계속 이어서 돌려도 일관성이 무너지지 않았어요. 컨텍스트 리셋도, 스프린트 계약도 더 이상 필요 없었습니다.
이 연구 결과를 처음 봤을 때 든 생각은 이거였습니다. "이게 불과 몇 달 전의 베스트 프랙티스였는데."
흥미로운 건 저자가 플래너와 평가자는 그대로 남겼다는 점입니다. 플래너를 빼면 생성자가 명세 없이 시작해서 결과물이 빈약해졌고, 평가자를 빼면 여전히 자기 작업을 관대하게 평가하는 문제가 남았습니다. 특히 평가자가 만들어내는 피드백은 이런 수준이었습니다.
| 계약 조건 | 평가자 발견 |
|---|---|
| 사각형 채우기 도구가 드래그로 영역을 채울 수 있어야 함 | FAIL — 도구가 시작점과 끝점에만 타일을 놓음. fillRectangle 함수는 있지만 mouseUp에서 제대로 호출되지 않음 |
| 배치된 엔티티 스폰 포인트를 선택하고 삭제할 수 있어야 함 | FAIL — LevelEditor.tsx:892의 Delete 키 핸들러가 selection과 selectedEntityId를 둘 다 요구하지만, 엔티티 클릭 시 selectedEntityId만 설정됨 |
| 애니메이션 프레임을 API로 재정렬할 수 있어야 함 | FAIL — PUT /frames/reorder 라우트가 /{frame_id} 뒤에 정의돼서 FastAPI가 'reorder'를 정수로 파싱하려다 422 에러 반환 |
파일명과 라인 번호, 그리고 구체적인 원인까지 짚어냅니다. 이건 그냥 "리뷰 에이전트 붙이기" 수준이 아니라 시니어 QA 엔지니어가 돌아가는 앱을 실제로 만져보며 내놓는 리포트에 가깝습니다. 왜 자기 평가가 아니라 독립된 평가자가 필요한지가 이 표 하나에 다 들어있어요.
곰곰이 따져보면 하네스 구성 요소가 두 종류로 갈리는 것 같습니다.
모델 버전에 종속된 것들이 있습니다. 마이크로 태스크 분할, 스프린트 계약, 컨텍스트 리셋, 공격적인 컨텍스트 분리. 이것들은 모두 "모델이 약하다"는 가정 위에 세워진 장치입니다. 모델이 세지면 자연스럽게 과잉이 되고, 때로는 오히려 방해가 되죠. LangChain은 자사 블로그에서 Deep Research를 여러 차례 재설계한 경험을 남기기도 했습니다. 어제의 베스트 프랙티스가 오늘의 오버헤드입니다.
모델 버전과 무관한 본질적인 것들도 있습니다. 컨텍스트 파일(프로젝트의 전제와 금기를 담는 온보딩 문서), 자동 강제 시스템(부탁이 아닌 강제), 생성자와 평가자의 분리, 루브릭 기반의 명시적 평가 기준. 이것들은 모델이 어떻게 발전하든 살아남을 가능성이 높습니다. 왜냐하면 이건 모델의 약점을 보완하는 장치가 아니라, 협업의 근본 구조에 가깝기 때문이에요. 사람 간의 협업에서도 온보딩 문서와 자동화된 검증, 작성자와 리뷰어의 분리, 명확한 완료 기준은 필요합니다.
| 구분 | 모델 의존적 (유행) | 본질적 (원리) |
|---|---|---|
| 계획 | 마이크로 태스크 분할, 세세한 기술 명세 | 제품 수준의 고수준 계획, 유저 스토리 |
| 구현 | 스프린트 계약, 컨텍스트 리셋 | CLAUDE.md / AGENTS.md, Hooks |
| 평가 | — | 생성자-평가자 분리, 루브릭 기반 평가 |
| 유지 | 공격적 컨텍스트 분리 | 가비지 컬렉션, 실패 피드백 루프 |
특히 루브릭 기반 평가는 오래 남을 본질이라고 생각합니다. Anthropic이 프런트엔드 평가에 사용한 네 가지 기준은 이렇습니다.
저자는 Claude가 이미 완성도와 기능성은 잘 해내니까, 디자인 완성도와 독창성에 더 높은 가중치를 줬다고 합니다. 특히 "AI가 자꾸 보라색+흰색 그라데이션으로 수렴하는 문제"를 명시적으로 감점 대상으로 박아넣은 건 꽤 웃기면서도 영리합니다. 모델의 기본 편향을 루브릭으로 부수는 방식이니까요.
이런 루브릭이 본질인 이유는, 모델이 아무리 똑똑해져도 "무엇이 좋은 결과인가"에 대한 기준은 사람이 정해줘야 하기 때문입니다. 그리고 그 기준을 명시적인 점수 체계로 만들면 사람과 에이전트 모두 같은 걸 보고 이야기할 수 있습니다.
그래서 지금 제 답은 이렇습니다. 프레임워크에 베팅하지 말고 원리에 베팅하자. BMAD, Spec Kit, Jesse, GSD — 이 이름들은 아마 1년 뒤에 지금과 매우 다른 풍경에 놓여 있지 않을까요. 하지만 "생성자와 평가자를 분리한다", "완료 기준을 루브릭으로 명시한다", "프로젝트의 전제를 문서로 남긴다" 같은 원리는 남을 것 같다고 생각합니다.
Anthropic 블로그의 저자는 글을 이렇게 마무리합니다.
"흥미로운 하네스 조합의 공간은 모델이 발전한다고 줄어들지 않는다. 그저 이동할 뿐이다. AI 엔지니어의 흥미로운 일은 다음 새로운 조합을 계속 찾는 것이다."
이 문장이 마음에 남았습니다. 모델이 세지면 어떤 하네스 요소는 사라지지만, 동시에 이전엔 불가능했던 더 복잡한 작업에 하네스를 적용할 여지가 열립니다. 하네스의 총량이 줄어드는 게 아니라 그 자리가 계속 이동하는 거예요.
사실 이 신호는 이미 있습니다. 그리고 이게 이 글의 시작이기도 해요. 도입에서 언급한 revfactory/harness — 제가 팀 메신저에 공유했던 바로 그 프로젝트가 사실 이 방향에 서 있습니다. 이건 "하네스를 만드는 하네스"예요. 에이전트가 스스로 자기 작업 환경을 구성하는 미래의 초기 형태로 볼 수 있습니다. 며칠 전만 해도 저에게는 그냥 "재미있는 도구"였는데, Anthropic 저자의 글을 읽고 나니 같은 프로젝트가 다른 의미로 보였습니다.
Martin Fowler가 블로그 단상(fragment)에서 Chad Fowler의 말을 인용하며 이 흐름을 "relocating rigor"라는 프레임으로 설명한 적이 있습니다. 코드 한 줄 한 줄을 정확히 짜던 엄밀함이, 이제는 에이전트가 올바르게 동작하는 시스템을 설계하는 엄밀함으로 옮겨가고 있다는 이야기예요. 공을 차는 선수에서 전술을 짜는 감독으로. 엔지니어가 덜 기술적으로 되는 게 아니라, 더 높은 차원의 기술이 요구되는 겁니다.
"매 순간마다 구미가 당겨오지만 장기 프로젝트 방향성에는 옳지 않다."
이 문장에 대한 제 답은 두 갈래입니다.
단기적으로는, 과하게 하지 않는 게 좋습니다. 개인 프로젝트나 작은 팀이라면 CLAUDE.md 한 파일과 pre-commit hook 하나로 시작하는 걸로 충분한 경우가 많습니다. Mitchell Hashimoto가 만든 Ghostty의 AGENTS.md도 처음부터 완벽하게 설계된 게 아니에요. 에이전트가 실패할 때마다 한 줄씩 추가되면서 점진적으로 진화한 파일입니다. 한 번에 완벽하게 하려 하지 말고, 실제로 실패한 케이스만 모아서 조금씩 덧붙이면 됩니다. 그리고 한 가지 더 — "garbage in, garbage out"입니다. 기획이 구리면 하네스로도 못 살려요. 하네스는 좋은 걸 더 잘 만드는 도구지, 별로인 걸 좋게 만드는 마법이 아닙니다.
장기적으로는, 프레임워크가 아니라 원리를 내재화해야 합니다. 다음 유행이 와도 흔들리지 않으려면, 지금 뜨거운 도구의 사용법을 외우는 게 아니라 그 도구들이 공통적으로 의지하고 있는 원리를 이해해야 합니다. 생성자-평가자 분리, 명시적 완료 기준, 온보딩 문서, 자동 강제. 이 네 가지만 확실히 잡으면 다음 프레임워크가 나와도 낯설지 않을 겁니다. 이름만 바뀌었을 뿐이니까요. 그리고 새 모델이 나올 때마다 Anthropic 저자가 말했듯 "더 이상 짐이 되는 부분은 덜어내고, 이전에는 불가능했던 새 가능성이 열린 곳을 찾으면" 됩니다.
돌고 돌아 결론은 단순합니다. 바뀌지 않는 층위를 찾고, 거기에 시간을 쓰면 됩니다.
하네스 엔지니어링이라는 용어도 어쩌면 1년 후에는 다른 이름으로 불리고 있을지 모릅니다. 하지만 그 아래에서 "에이전트의 실수를 구조적으로 반복 불가능하게 만든다"는 원리는 남을 거라고 생각해요. 우리는 그때까지 감독석에서 전술을 짜는 연습을 하면 됩니다.
사실 이 글을 쓰면서 내내 머릿속에 맴돈 생각이 하나 있습니다. 이 글도 유통기한이 있다는 것.
X든 유튜브든 뉴스레터든, 매일 새로운 도구가 나오고 새로운 프레임워크가 소개되고 새로운 모범 사례가 선언됩니다. 그리고 다음 주면 또 다른 모범 사례가 그 자리를 차지해요.
이 속도가 만드는 감정이 FOMO(Fear of Missing Out)입니다. 그리고 저는 이 감정에서 자유롭지 못해요. 이 글의 시작이 바로 그거였으니까 — 재미있어 보이는 새 도구를 발견하자마자 메신저에 공유한 사람이 저였습니다.
그런데 이 글을 쓰면서 점점 분명해진 게 있습니다. 매일 바뀌는 도구와 프레임워크를 쫓아다니는 건 끝없는 러닝머신 위를 뛰는 것과 비슷해요. 아무리 빨리 뛰어도 제자리입니다. 러닝머신에서 내려오는 유일한 방법은 덜 변하는 층위에 시간을 투자하는 것입니다.
그래서 저도 스스로에게 약속 하나를 남깁니다. 새로운 프레임워크가 나올 때마다 "이거 써봐야 하나?"를 묻기 전에, "이게 어떤 약점을 전제로 만들어졌는가?"를 먼저 물어보기로요. 그리고 그 약점이 지금 제가 쓰는 모델에도 여전히 유효한지 확인해보기로 했습니다. Anthropic 저자가 말한 "모델이 혼자 할 수 없는 일에 대한 가정" — 그 가정을 계속 검증하는 일 자체가 제가 찾을 수 있는 가장 유통기한이 긴 층위입니다. 그리고 이 질문 하나가 FOMO를 이기는 가장 실용적인 방법이라고 생각합니다.
이 글도 1년 후에는 아마 어딘가 낡아 있을 겁니다. Opus 4.6이 5.0으로 바뀌어 있을 것이고, 지금 "본질"이라고 적은 것들 중 일부는 또 모델에 흡수되어 있을 거예요. 하지만 그게 무섭지 않습니다. 낡은 부분은 낡은 대로 읽고, 남는 부분만 챙기면 됩니다. 격변하는 시대에 글을 쓰는 사람과 읽는 사람이 서로에게 할 수 있는 가장 솔직한 태도라고 생각해요.
그리고 또 1년쯤 지나서, 저는 또 뭔가 재미있어 보이는 도구를 메신저에 공유하고 있을 겁니다. 팀원분들은 또 "요즘 또 새로 나온 그거 있잖아요..." 하며 답해올 것이고, 저는 또 피로할 것이고, 또 고민할 것이고, 또 뭐가 본질인지 고르려고 애쓸 겁니다. 그 반복 자체가 이 시대를 살아가는 방식이라고 생각합니다.
