말은 이미 마구를 갖췄다 — 하네스 엔지니어링에서 루프 엔지니어링으로

프롬프트 엔지니어링을 익혔더니 컨텍스트 엔지니어링이 왔다. 그걸 따라잡았더니 하네스 엔지니어링이 왔고, 이제는 루프 엔지니어링이라고 한다. 또 처음부터 배워야 하나 — 하는 피로감이 있다면, 이 글이 그 피로의 구조를 해부한다.
이 글은 용어 하나를 더 가르치는 글이 아니다. 네 개의 용어를 관통하는 하나의 이동선을 보여주는 글이다. 그 선이 보이면, 다섯 번째 용어가 와도 불안하지 않다.
1. 3년, 5개월, 7개월 — 짧아지는 계보

먼저 연표부터 정확히 놓자. 이 계보는 느낌이 아니라 날짜가 있는 역사다. 각 용어가 정확히 무엇인지는 해당 절에서 하나씩 풀어간다.
프롬프트 엔지니어링은 2022년 말 ChatGPT 등장 이후 약 3년간 AI 활용법의 대명사였다. "어떻게 묻느냐"가 결과를 좌우했고, 잘 묻는 요령이 하나의 직무처럼 다뤄졌다.
컨텍스트 엔지니어링이라는 명칭은 2025년 6월 19일, Shopify CEO 토비 뤼케(Tobi Lütke)의 짧은 글에서 대중화됐다. 관행 자체는 그 전부터 무르익고 있었고, 이름이 붙은 것이 이때다. 그는 "LLM(Large Language Model)이 과제를 그럴듯하게 풀 수 있도록 모든 맥락을 제공하는 기술"이라는 의미에서 프롬프트 엔지니어링보다 이 표현을 선호한다고 썼다. 엿새 뒤인 6월 25일, 안드레이 카파시(Andrej Karpathy)가 "+1"을 보태며 정의를 더 벼렸다 — "컨텍스트 엔지니어링은 다음 단계를 위해 딱 맞는 정보로 컨텍스트 윈도우를 채우는 섬세한 예술이자 과학이다." 명칭 하나가 엿새 만에 업계 표준이 된 사건이었다.
하네스 엔지니어링은 2025년 11월 26일 Anthropic의 엔지니어링 블로그 「Effective harnesses for long-running agents」가 골격을 세웠고, 2026년 2월 11일 OpenAI가 「Harness engineering: leveraging Codex in an agent-first world」로 명칭을 공식화했다. 3월에는 LangChain, HumanLayer, 구글의 애디 오스마니(Addy Osmani)가 잇따라 정의를 다듬으며 담론이 만개했다.
루프 엔지니어링은 2026년 6월에 확산됐다. 6월 7일 오스마니가 「Loop Engineering」으로 정의를 내렸고, Claude Code를 만든 보리스 체르니(Boris Cherny)의 발언이 이 전환을 상징하는 문장이 됐다 — 그 문장은 5절에서 만난다.
간격을 세어 보면 구조가 드러난다. 프롬프트에서 컨텍스트까지 약 3년. 컨텍스트에서 하네스까지 약 5개월. 하네스에서 루프까지 약 7개월. 패러다임 명칭의 수명이 1년 아래로 내려왔다. 이 속도라면 용어를 하나씩 쫓아가는 학습은 이미 실패가 예약된 전략이다. 필요한 것은 다음 용어의 예습이 아니라, 네 용어가 공유하는 이동의 방향을 읽는 일이다.
2. 주입을 잘하는 사람이 이기던 시대

프롬프트의 시대와 컨텍스트의 시대는 표면적으로 달라 보이지만, 구조는 같았다. 결과의 품질 = 사용자의 주입 역량이라는 등식이다.
프롬프트 시대의 질문은 "말을 어떻게 거느냐"였다. 역할을 부여하고, 예시를 넣고, 단계별로 생각하라고 지시하는 요령이 결과를 갈랐다. 컨텍스트 시대의 질문은 "무엇을 보여주느냐"로 옮겨갔다. 카파시의 정의 그대로, 제한된 컨텍스트 윈도우에 무엇을 넣고 무엇을 뺄지 큐레이션하는 능력이 승부처였다.
두 시대의 공통점은 매 턴 사람이 입력을 설계한다는 것이다. 그리고 여기서 피로가 나온다. 주입은 세션마다, 턴마다 반복해야 한다. 잘 주입하는 요령은 개인기여서 팀으로 이전되지 않는다. 같은 도구를 쓰는 두 사람의 결과물이 극단적으로 갈리고, 잘하는 사람이 팀을 떠나면 그 역량도 함께 떠난다.
이 시리즈의 1편이 다뤘던 문서화의 문제 — 담당자가 바뀌면 시스템이 무너지는 사이클 — 와 정확히 같은 모양이다.
이 병목의 이름은 모델이 아니라 사람이다. 그리고 업계는 이 병목을 사람의 훈련이 아니라 구조의 설계로 푸는 쪽으로 움직였다.
3. 마구를 씌우는 일 — 하네스 엔지니어링

하네스(harness)는 말을 제어하는 마구(馬具)다. 이 시리즈가 1편부터 써 온 은유 그대로 — 매 턴 고삐를 당기는 대신, 말에 마구를 미리 설계해 씌워두는 전환이 하네스 엔지니어링이다.
이 은유는 장식이 아니라 계보다. 블룸AI가 하네스와 처음 마주쳤을 때 남긴 기록은, 강력하고 예측 불가능한 시스템을 다루는 도구들이 줄곧 동물의 이름을 빌려 왔음을 짚는다 — 분산 프로세스의 혼돈을 조율하던 주키퍼(동물원 사육사), 서버를 가축 떼처럼 다루게 한 랜처(목장주), 그리고 이제 AI라는 말에 이름을 건 하네스(마구). 이름의 계보가 곧 복잡성을 다루는 철학의 진화다. 그 글이 내린 정의도 이 절의 논지와 같다 — "말이 올바른 방향으로 힘을 쓸 수 있도록 마구를 설계하는 것이다."
2026년 3월, LangChain의 비벡 트리베디(Vivek Trivedy)가 업계 표준이 된 공식을 내놨다.
Agent = Model + Harness. "당신이 모델이 아니라면, 당신이 만들고 있는 것은 하네스다(If you're not the model, you're the harness)."
원시 LLM은 다음 토큰을 예측할 뿐이다. 파일을 읽고, 명령을 실행하고, 실수에서 복구하게 만드는 모든 구조 — 도구, 권한, 샌드박스, 메모리, 검증 장치 — 가 하네스다. 트리베디의 팀은 모델을 바꾸지 않고 하네스만 교체해, 코딩 에이전트 벤치마크인 Terminal Bench 2.0 순위를 30위권에서 5위권으로 끌어올렸다. 같은 시기 HumanLayer는 이 관점을 한 문장으로 압축했다 — "모델 문제가 아니라 구성(configuration) 문제다." 에이전트가 엉뚱한 일을 하면 다음 모델을 기다리는 게 아니라 하네스를 고치는 것이다.
체감할 수 있는 숫자도 있다. Anthropic이 같은 모델·같은 과제로 비교한 실험에서, 단순 프롬프트는 20분에 9달러, 풀 하네스는 6시간에 200달러가 들었다 — 20배 비싸지만 "품질 차이는 즉각 눈에 보였다". OpenAI는 더 큰 규모로 실증했다. 엔지니어 3명이 5개월간 손으로 한 줄도 짜지 않고 Codex만으로 약 100만 줄, 1,500건의 PR(Pull Request)을 머지해 내부 제품을 출시했고, 직접 썼을 때 대비 약 1/10의 기간이 걸렸다고 발표했다. 저자 라이언 로포폴로(Ryan Lopopolo)의 결론은 사람의 일이 코드 작성이 아니라 환경과 제약의 설계로 옮겨갔다는 것이었다.
하네스를 관리하는 규율도 정식화됐다. 오스마니는 이를 래칫(ratchet)이라고 불렀다 — 에이전트가 실수할 때마다 같은 실수가 재발하지 않도록 영구 규칙을 추가하고, 좋은 시스템 프롬프트의 모든 줄은 과거의 구체적 실패로 추적 가능해야 한다는 원칙이다.
여기서 이 글의 첫 번째 논지가 나온다. 이 마구는 이제 일반 사용자가 씌우는 것이 아니다. Claude Code, Cursor, Codex, Aider — 우리가 쓰는 AI 코딩 도구 자체가 이미 전문가들이 마구를 정교하게 씌워 놓은 말이다. 프롬프트·컨텍스트 시대에 사용자 개인기였던 것들이, 하네스 시대에는 도구 제작자의 전문 영역으로 흡수됐다.
4. 하네스보다 먼저 온 루프 — 랄프

명칭의 계보는 순차적이지만, 실제 기법은 뒤섞여 발명된다. 그 증거가 랄프(Ralph)다.
2025년 7월 14일 — "하네스 엔지니어링"이라는 명칭이 세워지기 넉 달 전 — 제프리 헌틀리(Geoffrey Huntley)는 황당할 만큼 단순한 기법을 공개했다.
while :; do cat PROMPT.md | claude-code ; done
셸의 무한 루프에 코딩 에이전트를 넣고, 같은 프롬프트 파일을 반복해서 먹인다. 매 반복은 새 컨텍스트에서 시작하고, 대화 이력 대신 파일시스템이 기억을 담당한다. 심슨 가족의 우직한 캐릭터 이름을 딴 이 기법으로 헌틀리는 — 본인 주장 기준 — 5만달러짜리 계약을 297달러의 API(Application Programming Interface) 호출 비용으로 이행했고, CURSED라는 새 프로그래밍 언어의 컴파일러를 석 달의 연속 루프로 만들었다.
단, 헌틀리 본인이 명시한 한계도 함께 봐야 한다. "랄프는 멍청하다." 잘못된 가정을 하고, 자리표시자 구현을 만들고, 가끔 코드베이스를 완전히 망가뜨린다. 시니어 엔지니어의 감독이 필수이고 그린필드(greenfield — 기존 코드 없이 새로 시작하는) 프로젝트에 한정된다. 그의 표현을 빌리면 "엔지니어 없이 도구가 100%를 해준다는 주장은 헛소리"다.
흥미로운 것은 그다음이다. 야생의 해킹으로 시작한 랄프는 이후 Anthropic이 Claude Code의 공식 플러그인으로 패키징했다. 셸의 while 루프는 세션 종료를 가로채 프롬프트를 되먹이는 Stop 훅으로 다듬어졌고, 최대 반복 횟수 같은 안전장치가 붙었다. 루프가 하네스 안에 부품으로 내장된 것이다. 루프는 하네스의 경쟁자가 아니라, 하네스 위에 얹히는 층이라는 사실이 여기서 이미 예고됐다.
5. "제 일은 루프를 작성하는 것이다" — 루프 엔지니어링

2026년 6월, 전환을 상징하는 문장이 나왔다. Claude Code를 만든 보리스 체르니의 말이다.
"저는 더 이상 Claude에 프롬프트를 쓰지 않습니다. 루프들이 돌면서 Claude에 프롬프트를 넣고 다음 할 일을 정합니다. 제 일은 루프를 작성하는 것입니다." — 보리스 체르니, Addy Osmani의 「Loop Engineering」에서 재인용
오스마니는 같은 달의 글에서 이 흐름에 정의를 붙였다 — "루프 엔지니어링은 에이전트에 프롬프트를 넣는 사람 자리에서 자신을 대체하는 일이다. 그 일을 대신할 시스템을 설계하는 것이다." 일을 발견하고, 에이전트에 위임하고, 결과를 검증하고, 상태를 유지하고, 다음 행동을 정하는 시스템 — 그것이 루프다. 그리고 계층 관계를 명확히 했다 — 루프 엔지니어링은 하네스의 사촌이 아니라 **"하네스보다 한 층 위"**에 있다. 겹겹이 쌓이는 이 구조는 블룸AI의 하네스 첫 기록이 앞선 계보에서 본 것과 같은 무늬다 — 바이브 코딩(vibe coding — 느낌대로 프롬프트를 던지는 개발), MCP(Model Context Protocol), 스킬, 하네스로 이어진 흐름은 서로를 대체한 것이 아니라 층으로 쌓였고, 각 층은 자기 자리에서 계속 쓰인다. 루프도 그렇게 하네스를 지우지 않고 그 위에 얹힌다.
여기서 용어 혼동 하나를 정리하자. 에이전트 안에는 원래 루프가 있다. 추론하고, 도구를 부르고, 결과를 관찰하고, 다시 추론하는 반복 — 이 안쪽 루프는 하네스의 부품이며 "한 작업을 끝까지" 미는 역할이다. 루프 엔지니어링이 말하는 루프는 그 바깥에 있다. 하네스를 통째로 반복 구동하며 "다음 작업을 계속" 정하는 루프다. 안쪽 루프는 도구 제작자가 만들었고, 바깥 루프가 이제 사용자의 설계 영역으로 넘어온 것이다.
바깥 루프의 병목은 모델이 아니라 검증이다. 루프가 "끝났다"를 스스로 판정하려면 평가 장치가 하네스에 이미 내장되어 있어야 한다. Anthropic의 실험이 그 이유를 보여준다 — 에이전트에게 자기 작업을 평가시키면 "품질이 명백히 평범한데도 확신에 찬 칭찬"으로 응답하는 경향이 있어서, 일하는 에이전트와 판정하는 에이전트를 분리하는 것이 강력한 지렛대였다. 오스마니의 경고도 같은 자리를 가리킨다 — "방치된 채 도는 루프는, 방치된 채 실수하는 루프이기도 하다." 하네스 엔지니어링이 루프 엔지니어링의 선행 조건인 이유가 이것이다. 검증 없는 루프는 자동화된 사고일 뿐이다.
6. 목적지를 정하는 사람

이제 네 용어를 관통하는 이동선을 그을 수 있다. 기술이 이동한 것이 아니다. 사용자의 역할이 이동했다. 이것이 이 글의 두 번째 논지이자, 3절에서 예고한 첫 번째 논지의 귀결이다.
프롬프트·컨텍스트 시대에 사용자는 주입자였다. 얼마나 잘 거는지, 얼마나 잘 골라 넣는지가 결과를 갈랐다. 하네스 시대에 그 일은 도구 제작 전문가에게 흡수됐다. 그리고 에이전트가 스스로 탐색하고, 계획하고, 검증하는 능력 — 에이전틱 능력 — 을 갖출수록, 사용자가 세세한 맥락을 손수 정의해 주입하는 것보다 목표를 잘 세우는 것만으로 목적을 달성하는 구간이 넓어진다.
Anthropic의 하네스 설계 원칙에 이 방향이 이미 새겨져 있다.
"하네스의 모든 부품은, 모델이 스스로 하지 못하는 것에 대한 가정을 인코딩한 것이다." — Prithvi Rajasekaran, Anthropic Labs
모델이 강해질수록 그 가정들은 하나씩 낡고, 낡은 부품은 폐기 대상이 된다. 버리는 것이 설계의 일부다. 마구는 점점 가벼워진다. 그렇게 고삐질(프롬프트)이 사라지고, 안장 조정(컨텍스트)이 사라지고, 마구 제작(하네스)마저 전문가의 기성품으로 흡수되고 나면 — 끝까지 사람에게 남는 일은 하나다. 이 말을 어디로, 지속가능하게 달리게 할 것인가.
블룸AI는 하네스를 처음 마주친 글을 이런 질문으로 닫았었다 — "말을 그냥 풀어놓겠는가, 아니면 마구를 설계하겠는가?" 루프의 시대는 그 양자택일에 세 번째 답을 더한다. 마구는 이미 설계되어 있다. 이제 물음은 이것이다 — 그 말을 어디로 달리게 하겠는가.
다만 목표 설정이 쉬운 일이 됐다는 뜻은 아니다. "알아서 잘 해줘"는 목표가 아니다. 좋은 목표에는 종료 조건과 검증 기준과 제약이 들어 있어야 하고, 그것을 설계하는 일이 바로 루프 엔지니어링의 실무다. 오스마니의 맺음말이 이 균형을 정확히 짚는다 — "루프를 만들어라. 단, 계속 엔지니어로 남을 사람처럼 만들어라. 시작 버튼만 누르는 사람이 아니라."
7. 우리 정원에는 무엇이 남는가

이 시리즈의 정원 — 테크 라이팅 하네스 — 도 같은 이동선 위에 있다. 이 정원은 세 겹의 토양으로 되어 있다. 무엇이 올바른지 판단하는 기준(햇빛, knowledge), 그 기준으로 실제 검수를 수행하는 전문가들(영양분, agents), 그리고 검수가 흐르는 순서와 범위(물길, engine). 자세한 설계는 1편에 있다.
그리고 이 정원에는 이미 작은 물레방아가 돌고 있었다. 원고 한 편이 검수 기준에 미달하면, 취약한 축의 피드백과 함께 보강과 재검수가 자동으로 한 바퀴 더 돈다. 코드의 린트-수정 루프와 같은 원리다. 멀리서 찾을 것 없이 — 지금 읽고 있는 이 글이 그 물레방아를 한 바퀴 돌고 나왔다. 검수단이 약어 풀어쓰기 축에서 기준 미달을 판정해 게시를 차단했고, 지적된 축을 따라 보강이 적용됐고, 재검수를 통과한 뒤에야 이 글은 게시 상태로 승급됐다. 그 전 과정이 정원의 평가 로그로 남아 있다.
기록을 거슬러 올라가면 이 물레방아가 처음 돈 것은 시리즈 1편 때다. 첫 글도 같은 약어 축에서 게시가 차단됐고, 여섯 건의 보강을 거쳐 승급됐다. 흥미로운 것은 그다음이다 — 이 검수→보강→재검수 루프는 원래 엔진 설계도에 없었다. 첫 사이클이 끝난 뒤 정원지기가 회고에서 "실제로 일어난 루프"를 발견했고, 그제야 정식 절차로 등재됐다. 물레방아는 설계된 것이 아니라 발견된 것이다.
한 가지 설계 선택을 눈여겨볼 만하다. 이 정원은 검수 규칙을 일부러 너무 타이트하게 잡지 않았다. 지금 이 정원에 필요한 것은 게시할 수 있는 좋은 글이지 완벽한 글이 아니고, 물레방아는 이제 몇 바퀴 돌았을 뿐이기 때문이다. 대신 매 바퀴의 평가를 빠짐없이 로그로 남긴다. 근거는 벌써 쌓이고 있다 — 두 사이클이 같은 약어 축에서 걸렸다는 기록은 용어 지식을 보강하라는 신호가 됐고, 게시된 글에 독자 이슈가 들어와 도는 더 큰 루프에서는 같은 렌더링 문제가 두 편에서 반복되자 검수 규칙 추가 후보로 승격됐다. 3절의 래칫과 같은 원리다 — 기준을 처음부터 조이는 게 아니라, 돌 때마다 쌓이는 기록을 근거로 기준 자체를 더 높은 품질을 향해 보강할 수 있게 해 두는 것이다. 루프는 돌수록 결과물만 좋아지는 게 아니라, 자기 기준을 키운다.
남은 것은 바깥 루프다. 지금은 사람이 "검수해줘"라고 물길을 틀지만, 검수 엔진이 사람의 호출 없이 원고의 상태를 감시하며 스스로 도는 그림 — 하네스 위에 루프를 얹는 것 — 이 이 정원의 다음 단계가 될 것이다. 그때 정원지기의 일은 더 이상 물길을 트는 것이 아니라, 이 정원이 어떤 글을 향해 자라야 하는지 방향을 정하는 것이 된다. 그래서 이 정원은 이제 하네스만 가꾸지 않는다 — 하네스와 함께, 그 위에 얹을 루프 장치를 함께 고민한다.
정원지기가 잠든 밤에도 물레방아는 돈다. 하네스의 이야기는 루프와 함께 계속됩니다 💙
참고 자료
- Andrej Karpathy — "+1 for context engineering" (X, 2025-06-25)
- Anthropic — Effective harnesses for long-running agents (2025-11-26)
- OpenAI — Harness engineering: leveraging Codex in an agent-first world (Ryan Lopopolo, 2026-02-11)
- LangChain — The Anatomy of an Agent Harness (Vivek Trivedy, 2026-03-10)
- HumanLayer — Skill Issue: Harness Engineering for Coding Agents (2026-03-12)
- Anthropic — Designing harnesses for long-running applications (Prithvi Rajasekaran, 2026-03-24)
- 블룸AI 블로그 — 하네스 AI 엔지니어링: 주키퍼에서 하네스까지 (2026-04-03)
- Addy Osmani — Agent Harness Engineering (2026)
- Geoffrey Huntley — Ralph Wiggum as a "software engineer" (2025-07-14)
- Anthropic — Claude Code ralph-wiggum 공식 플러그인
- Addy Osmani — Loop Engineering (2026-06-07)
- Cobus Greyling — Loop Engineering (2026-06-09)
- 시리즈 1편: 테크 라이팅 문서 시스템에 하네스를 도입하다