결론 먼저
사람이 AI에게 코딩을 시키는 방식은 프롬프트 → 컨텍스트 → 하네스 → 루프 네 단계로 바뀌어 왔다. 네 단계는 계단식 대체가 아니라 도구 상자의 확장이다. 뒤 단계가 앞 단계를 버리는 게 아니라 부분집합으로 품는다. 그러니 "요즘은 루프래" 하고 앞 단계를 건너뛰면 안 된다. 어느 단계를 쓸지는 트렌드가 아니라 작업 규모와 본인 이해도가 정한다 25 11.
비교표
네 단계는 다루는 대상이 점점 바깥으로 넓어진다. 말 거는 법 → 건네줄 정보 → 일할 환경 → 반복 자체 순이다 11 5.
| 단계 | 핵심 질문 | 다루는 대상 | 비유 | 부딪히는 천장 |
|---|---|---|---|---|
| 1. 프롬프트 엔지니어링 | "뭘 물어볼까" | 프롬프트 1개 | "잘 해 줘"라고 부탁하기 | 프로젝트를 모른다 |
| 2. 컨텍스트 엔지니어링 | "뭘 보여줄까" | 주입할 정보 | 필요한 자료를 책상에 깔아주기 | 알아도 어긴다 |
| 3. 하네스 엔지니어링 | "어떤 환경에서 일하게 할까" | 모델을 뺀 환경 전체 | 야생말에 마구(馬具) 씌우기 | 사람이 계속 개입해야 한다 |
| 4. 루프 엔지니어링 | "반복 자체를 자동화할까" | 사람의 2·3번째 개선 프롬프트 | 프롬프팅하는 나 자신을 줄이기 | 작은 일에는 과하다 |
| 5. 그래프 엔지니어링 | "자율성을 어디까지 회수할까" | 에이전트 사이의 경로 | 자율 주행을 선로 위에 올리기 | 나온 지 한 달, 검증이 없다 |
"25년이 컨텍스트(혹은 에이전트)의 해였다면 26년은 하네스의 해"라는 표현이 반복된다. 루프는 그 위에서 가장 최근에 등장한 축이다 5 21 25.
1단계 — 프롬프트 엔지니어링
ChatGPT 초창기에 가장 먼저 자리 잡은 방식이다. 역할 주기, 단계별 지시, 예시 넣기, "공학용 계산기 GUI"처럼 구체적으로 요청하기 같은 기법이 여기 속한다 5 11.
천장은 두 겹이다. 프로젝트 스택·코드 구조·DB 스키마를 모르면 말을 아무리 잘해도 소용이 없다. 그리고 "DB 호출하지 마"라고 써 둬도 또 어긴다. 부탁이지 강제가 아니기 때문이다 11.
2단계 — 컨텍스트 엔지니어링
2025년까지의 중심축이다. 코드·문서·규칙 중에서 지금 필요한 것을 골라 모델에게 건네주는 기술이다. 레이지·조건부 로딩(.claude/rules glob), 세컨드 브레인과 /memory, /clear로 컨텍스트 위생 관리, MCP 토큰 관리 같은 것들이 여기 들어간다 7 10.
여기서도 천장이 나온다. 정보를 다 알아도 "엉뚱한 짓"은 못 막는다. DB 스키마를 멋대로 바꾸는 식이다. 정보의 문제가 아니라 규칙과 울타리의 문제이기 때문이다 11.
3단계 — 하네스 엔지니어링
2026년, "하네스의 해"의 축이다. 컨텍스트 파일(CLAUDE.md), 자동 강제(린터·아키텍처 테스트·훅), 자가교정 루프, 가비지 컬렉션을 묶어 환경 전체를 설계한다 11 14.
다만 한 번 만든 하네스가 영원하지는 않다. 모델이 좋아지면 낡은 제약이 오히려 방해가 되고 제품 내장 기능과 중복된다. 그래서 '하네스 다이어트'가 필요하다 24.
4단계 — 루프 엔지니어링
가장 최근 트렌드다. 사람이 두 번째, 세 번째로 던지던 개선 프롬프트까지 자동화한다. Act→Observe→Decide→Repeat 루프를 돌려 통과 기준(예: 유사도 90%)에 닿을 때까지 스스로 반복하게 만든다. 다이나믹 워크플로우의 ultra code가 그 예다 25 23.
작은 프로젝트나 MVP에는 과하다. 한 번에 끝낼 일을 루프로 돌리면 토큰과 시간만 쓴다. 게다가 "루프를 어떻게 디자인할까"를 고민하는 순간 결국 다시 하네스 엔지니어링으로 돌아온다 25.
5단계 — 그래프 엔지니어링, 진화가 아니라 반작용
2026년에 이름 하나가 더 붙었다. 그런데 이건 앞의 넷과 성질이 다르다. 방향이 반대다 30.
앞의 네 단계는 사람이 쥐고 있던 것을 하나씩 에이전트에게 넘기며 바깥으로 넓어졌다. 그래프 엔지니어링은 루프가 넘겨준 자율성을 도로 회수한다. 일을 서브 태스크로 쪼개고, 잘했으면 이쪽 못했으면 저쪽이라는 분기를 사람이 다시 정해 준다.
그래서 "2024년 LangGraph 시절로 되돌아간 것 아니냐"는 비판이 붙는다. 실제로 구조는 닮았다. 다만 통제하는 이유가 달라졌다는 반론이 있다. 예전에는 LLM이 멍청해서 막았지만, 지금은 의도한 대로 가게 하려고 막는다 30.
모순③. 정반대 평가도 있다. 그래프가 앞 단계들의 상위 호환이자 자연스러운 연장이라는 관점이다. 근거는 각 단계가 무엇을 설계했는지를 나란히 놓아 보면 드러난다 31.
| 단계 | 설계 대상 |
|---|---|
| 프롬프트 | AI가 무슨 말을 듣는지 |
| 컨텍스트 | AI가 무엇을 알고 있는지 |
| 루프 | AI가 어떻게 반복해서 행동하는지 |
| 그래프 | 여러 AI가 어떤 구조 안에서 함께 움직이는지 |
이 관점에서 그래프는 루프를 밀어내지 않는다. 노드 하나하나 안에 루프를 넣을 수 있고, 몇 개의 노드를 묶어 독립적인 루프로 굴릴 수도 있다. 어느 쪽이 맞다기보다, 시스템 전체를 보면 되감기이고 노드 단위로 보면 품는 관계라고 읽는 편이 정확하다.
이 위키가 그래프를 5단계로 적어 두긴 했지만, 확정된 방법론으로 읽으면 안 된다. 나온 지 한 달 된 말이고(2026-08 기준) 관련 포스트의 99%가 AI 슬롭처럼 보인다는 혹평이 함께 붙는다. 대담의 결론도 **"하네스까지만 배워도 하려는 문제는 대부분 풀린다"**였다 30.
그 앞에도 역사가 있었다
이 네 단계는 갑자기 시작된 게 아니다. 2023년에 이미 Auto-GPT, BabyAGI 같은 에이전트가 있었고, 하는 일은 지금과 크게 다르지 않았다. 도구를 부르고 문제를 푸는 구조는 같았다. 다만 맥락이 길어지면 성능이 무너져 전부 실패했다 30.
그래서 LLM 여러 개를 체인이나 모듈로 이어 붙이는 워크플로우가 나왔고, 앤드류 응의 에이전틱 워크플로우(계획·도구 사용·중간 점검)가 널리 퍼졌다. 2024년에는 LangGraph가 그 흐름을 그래프로 굳혔다. 2025년에는 도구를 계속 부르며 스스로 진행하는 에이전트 하나가 그 워크플로우를 통째로 흡수했다. Claude Code가 그 결과다 30.
쉽게 말하면 이렇다. 모델 성능이 오를 때마다 사람이 짜 두던 플로우가 모델 안으로 빨려 들어가고, 그러면 사람들은 더 어려운 일을 시키고, 그걸 통제하려고 더 높은 층에 새 이름이 붙는다. 팽창하는 과정인 셈이다 30.
상호보완(누적)이지 대체가 아니다
이 네 축의 가장 중요한 성질은 순서대로 졸업하는 것이 아니라 전부 필요한 상호보완적 축이라는 점이다 11. 다음 단계가 나왔다고 앞 단계가 폐기되지 않는다. 더 큰 바깥 레이어가 앞 단계를 부분집합으로 흡수한다.
- 프롬프트 엔지니어링은 사라지지 않고, 하네스라는 더 큰 환경 설계 안의 한 요소로 남는다 11.
- 컨텍스트 엔지니어링은 하네스의 4대 기둥 중 하나(컨텍스트 파일)로 흡수된다 5.
- 루프 엔지니어링은 하네스 위에서 작동한다. "무엇을 하고 하면 안 되는지의 룰을 정의"하는 순간 다시 하네스 엔지니어링으로 회귀한다 25.
쉽게 말하면 각 단계는 앞 단계의 천장을 한 겹씩 넘는 누적적 추상화다. 프롬프트의 천장(프로젝트를 모름)을 컨텍스트가, 컨텍스트의 천장(알아도 어김)을 하네스가, 하네스의 천장(사람이 반복 개입해야 함)을 루프가 넘는다 11 25.
역할 변화와 맞물린다
이 진화는 개발자 역할의 변화의 "선수 → 감독" 상향 이동과 정확히 맞물린다. 단계가 올라갈수록 사람이 손으로 하는 일은 줄고, 환경과 규칙과 루프를 설계하는 일이 늘어난다.
"인간은 조종하고, 에이전트는 실행한다(Humans steer, agents execute)"는 말에서 '조종'이 곧 하네스 설계다. 코드 한 줄을 짜던 엄밀함이 시스템을 설계하는 엄밀함으로 옮겨 가는 **"엄밀함의 재배치"**인 셈이다 11 14.
같은 모델이라도 환경을 설계한 사람과 그냥 시킨 사람의 격차가 10배까지 벌어진다. $9 vs $200 일화가 이를 뒷받침한다 13 5.
주의 / 논쟁: 최신이 항상 정답은 아니다
진화 서사를 "뒤로 갈수록 우월하다"로 오독하면 안 된다. 여러 자료가 두 가지를 명시적으로 경고한다.
루프·다이나믹 워크플로우는 규모에 맞아야 한다
사이드 프로젝트, MVP, PMF 탐색 단계의 작은 작업이라면 이야기가 다르다. 프론티어 모델 성능이 워낙 좋아서 ultra code나 max로 한 번에 끝낼 수 있다. 이걸 굳이 루프로 반복하면 루프 짜는 시간·도는 시간·토큰만 낭비된다.
SVG처럼 한 번에 그릴 수 있는 걸 루프로 돌리는 건 말이 안 된다. "right tool for the right job"이라는 것이다 25. "새 개념들은 사실 추상화가 높아진 것일 뿐 완전히 새로 생긴 건 많지 않다"는 조언도 같은 맥락이다 25.
하네스도 무한정 쌓는 게 아니라 덜어내야 한다
'하네스 다이어트'라 부르는 이야기다. 모델 성능이 좋아지면 예전에 강제로 묶어야 했던 행동이 불필요해진다. 게다가 Claude Code·Codex·Cursor 자체가 이미 하나의 하네스 레이어다.
그 위에 낡은 하네스를 또 얹으면 제품 내장 기능과 중복되어 오히려 에이전트를 방해한다. 지금은 "무엇을 더 붙일까"가 아니라 "불필요한 것을 어떻게 덜어낼까"의 타이밍이고, 한 달에 한두 번 점검이 권장된다 24. 다이나믹 워크플로우의 '하네스 레거시 스캔/다이어트' 워크플로우가 이를 실연한 사례다 24.
함께 읽기
- 프롬프트 엔지니어링 — 1단계, "뭘 물어볼까"
- 컨텍스트 엔지니어링 — 2단계, "뭘 보여줄까"
- 하네스 엔지니어링 — 3단계, 환경 전체 설계 (서사의 중심)
- 루프 엔지니어링 — 4단계, 반복 자체의 자동화
- 그래프 엔지니어링 — 5단계, 자율성을 되감는 반대 방향
- 에이전틱 코딩 — 말(에이전트) 훈련과 마구(하네스) 제작의 짝
- 개발자 역할의 변화 — "선수 → 감독" 상향 이동
- 다이나믹 워크플로우 — 동적 하네스 생성 / 하네스 다이어트