결론부터. 문턱은 하네스에서 끝난다. 그 위는 실력이 아니라 상황이다.

3월 말 소스 유출로 하네스 얘기를 한 번 쓴 적이 있다. 그 뒤로 이 위에 이름이 두 개 더 붙었다. 루프 엔지니어링, 그래프 엔지니어링. 그리고 새 이름이 붙을 때마다 같은 말이 따라붙는다. 이걸 안 쓰면 뒤처진다고. 한동안 그 말이 계속 걸렸다. 모델이 이만큼 발전한 시점에, 사용자가 “엔지니어링”에 이렇게까지 기력을 쏟는 게 맞는 방향인가.

한참 굴려본 지금의 답이 위의 두 문장이다. 아래는 그 근거다.

5단계라는 작명

먼저 이름부터 정리한다. 지난 몇 달 사이 이 바닥에는 “엔지니어링”이 다섯 개 쌓였다.

  • 프롬프트 엔지니어링 — 한 번의 질문을 잘 쓴다
  • 컨텍스트 엔지니어링 — 모델이 뭘 보고 답할지를 설계한다
  • 하네스 엔지니어링 — 에이전트를 감싸는 실행 껍데기를 설계한다
  • 루프 엔지니어링 — 그 껍데기를 순환시킨다. 계획 → 실행 → 관찰 → 재시도
  • 그래프 엔지니어링 — 순환을 깨고 노드를 병렬로 벌린다

루프는 Addy Osmani가 6월에 이름을 붙였고, 7월 중순부터는 “이제 루프가 아니라 그래프”라는 담론이 돌았다. 그래프 하네스가 관리해야 한다는 목록을 보면 — 에이전트 간 메시지 라우팅, 노드 실패 격리, 상태 일관성, 동적 노드 생성, 그래프 관측성 — 이건 분산 시스템 설계다. 개발자 개인이 코딩 작업 하나 시키려고 짜야 할 물건의 목록이 아니다.

문제는 다섯 개를 “단계”로 부르는 순간 사다리처럼 보인다는 거다. 1단부터 5단까지, 높이 올라갈수록 고수. 나는 이 작명이 이 판의 가장 큰 착시라고 본다.

사다리가 아니라, 3층짜리 건물과 공구함 두 개

다섯 개는 종류가 다르다.

앞의 셋은 모든 작업에 적용되는 층이다. 프롬프트가 좋아지면 모든 요청이 좋아진다. 컨텍스트가 관리되면 모든 세션이 좋아진다. 하네스가 깔리면 — 권한 경계, 검증 게이트, 프로젝트 규칙, 훅 — 에이전트가 도는 모든 턴이 좋아진다. 보편 레이어다. 여기 들인 노력은 작업 수만큼 곱해져서 돌아온다.

루프와 그래프는 그렇지 않다. 루프는 “사람 없이 반복되어야 한다”는 조건이 걸려야 의미가 생기고, 그래프는 “한 컨텍스트에 안 들어가는 규모”라는 조건이 걸려야 의미가 생긴다. 조건에 안 걸리는 작업 — 일상 작업의 대부분 — 에서는 적용해도 이득이 거의 없고 관리 비용만 남는다. 조건부 공구를 보편 레이어처럼 매 작업에 쓰면 그건 최적화가 아니라 의식(儀式)이다.

그러니까 다섯 단계가 아니다. 3층짜리 건물 하나와, 특정 상황에 여는 공구함 두 개다. 문턱은 3층, 하네스에서 끝난다. 그 위로 올라가는 계단은 애초에 없다. 상황이 오면 공구함을 여는 것뿐이다.

공구조차 이제 제조사가 만든다

그 공구함마저 직접 짤 필요가 없어지고 있다. 최근 릴리즈 노트가 증거다.

그래프 엔지니어링 목록의 첫 항목이었던 에이전트 간 메시지 라우팅은 v2.1.224에서 제품 기능이 됐다(현재 macOS·Linux 한정). Claude Code 세션들이 ListAgents로 서로를 찾고 SendMessage로 텍스트를 주고받는다. 몇 달 전이었으면 MCP나 파일 큐로 손수 짜야 했던 게 툴 두 개다. 루프 쪽도 마찬가지다. 예약 태스크, /goal, 동적 워크플로 — 순환 구조를 사람이 설계할 필요 없이 부르면 된다.

동시에 제조사는 경계선도 같이 긋는다. v2.1.212에서 폭주 방지 상한이 걸렸고(스폰 상한은 문제가 확인된 뒤 v2.1.224에서 다시 풀렸다), v2.1.215와 v2.1.218에서는 에이전트가 스스로 돌리던 /verify, /code-review, /deep-research를 사람이 부를 때만 돌게 되돌렸다. v2.1.222에서는 ultraplan이라는 기능이 통째로 빠졌다. 동적 워크플로의 기본 권고는 에이전트 15개 미만이다. 오케스트레이션을 없애는 게 아니라 제품 안으로 흡수하면서 기본 규모를 작게 잡는 것 — 이게 일관된 결이다.

8월 7일에 나온 advisor는 이 방향의 정점이다. 일하는 에이전트가 턴 중간에 자기와 같거나 더 강한 모델을 불러 조언을 받는 기능인데, 설정이 로스터 한 줄이다. 노드를 열두 개 벌려 서로 검증시키는 대신, 일하는 놈 하나에 더 똑똑한 놈 하나를 붙인다. 그래프를 넓히는 게 아니라 판단력을 빌린다. 그리고 위임 깊이는 한 단계로 막아놨다. 깊은 그래프를 짜라고 만든 물건이 아니라는 뜻이다.

정리하면, 조건에 걸리는 작업이 진짜로 왔을 때조차 필요한 건 엔지니어링이 아니라 호출이다. 기능이 있다는 걸 알고, 언제 쓸지 판단하고, 부르면 끝. 배울 가치가 “구현 능력”에서 “존재 인지와 적용 판단”으로 줄었다.

에이전트가 망하는 방식

에이전트를 매일 굴리다 보면 망하는 패턴이 보인다. 그리고 그 패턴이 이 글의 진짜 근거다.

에이전트는 기법이 부족해서 망하지 않는다. 내가 루프를 안 짜서, 그래프를 안 벌려서 결과물이 망가진 기억이 없다. 망하는 방식은 거의 하나다. 그럴듯한데 틀린 전제를 잡고, 그 위에 성실하게 쌓는 것. 문법도 맞고 테스트도 통과하는데 현장에서는 그렇게 안 돌아가는 결과물. 이때 그걸 구하는 건 더 정교한 오케스트레이션이 아니라 “야, 그 테이블은 실적 확정 후에는 안 건드려”라는 한 문장이다. 도메인을 아는 사람의 정정 한 줄이 에이전트의 탐색 범위를 가지째 쳐낸다. 툴 호출 열 번과 시행착오 세 바퀴가 그 한 줄로 사라진다.

반대 경우를 상상해보면 더 선명하다. 도메인을 모르는 사용자가 오케스트레이션만 화려하면 어떻게 되나. 틀린 것을 병렬로 열두 개 만든다. 오케스트레이션은 생산 속도를 올리는 도구지 방향을 잡아주는 도구가 아니다. 방향이 틀렸으면 속도는 손해를 증폭시킨다. 더 나쁜 건, 그 열두 개가 서로 교차검증까지 마치고 나온다는 거다. 틀렸는데 자신감 있는 결과물. 그걸 걸러낼 눈이 없으면 그대로 납품된다.

생성 비용은 모델이 발전할수록 가파르게 떨어진다. 그런데 “이게 맞는 답인가”를 판정하는 비용은 그 속도로 안 떨어진다. 병목은 생성이 아니라 검증이고, 검증 능력의 실체가 도메인 지식이다. 문서에 있는 지식은 에이전트가 채워준다. 진짜 격차는 문서에 없는 데 있다. 고객이 말하지 않은 진짜 요구사항, 요구사항 자체가 틀렸다는 판단, 이 시스템이 왜 이렇게 기형적으로 생겼는지의 역사. 어디에도 적혀 있지 않아서 에이전트도 못 채운다.

그래서 같은 모델을 쓰는데 결과물이 갈린다면, 갈라놓은 건 대체로 기법이 아니라 출력에서 뭐가 틀렸는지 알아보는 눈이다.

그럼 공구함은 언제 여나

조건부 공구라고 했으니 조건을 적는다. 셋이다.

규모. 한 컨텍스트에 안 들어가는가. 파일 300개 마이그레이션은 쪼개는 것 말고 방법이 없다. 기법이 아니라 물리적 제약이다.

반복성. 같은 구조로 열 번 이상 돌리는가. 한 번 쓰고 버릴 작업에 그래프를 짜면 짜는 비용이 결과보다 크다.

검증 가능성. 각 노드의 출력이 기계적으로 판정되는가. 판정이 안 되면 병렬로 벌린 만큼 검증 부채만 는다.

셋 다 걸리면 공구함을 연다. 하나만 걸리면 그냥 시킨다. 그리고 “이 판단이 맞나 싶어서” 그래프를 벌리려던 거라면 그건 규모 문제가 아니라 판단력 문제고, 그때는 노드를 늘리는 게 아니라 더 강한 모델을 부르는 게 맞다. advisor가 정확히 그 자리에 있다. 메시가 화려한 개인기 없이 적은 터치로 수비를 제치는 것과 같은 이치다 — 화려함을 뺀 게 아니라 군더더기를 뺀 거다.

마무리 — 문턱과 복리

하네스까지는 실력이다. 넘어야 하고, 안 넘으면 자기 지식을 에이전트에게 전달하지 못한다. 도메인 고수라도 컨텍스트를 세션 하나에 다 욱여넣고 검증 없이 받아쓰면 그 지식은 결과물에 반영되지 않는다.

그런데 그 문턱은 하네스에서 끝난다. 루프와 그래프는 다음 계단이 아니라 상황용 공구고, 그 공구조차 이제 제품에 들어 있다. 거기에 계속 공을 들이는 게 실력처럼 보이는 것 — 그게 “5단계”라는 작명이 만든 착시다.

기법은 문턱이고, 도메인은 복리다. 문턱은 몇 주면 넘고 모델이 발전할수록 낮아진다. 도메인은 연 단위로 쌓이고 모델이 발전할수록 오히려 희소해진다. 다들 같은 모델을 쓰는 시대에 결과물의 차이는 프롬프트에 뭐라고 쓰는지가 아니라 출력에서 뭐가 틀렸는지 알아보는 눈에서 나온다.

그래서 요즘 나는 에이전트를 더 많이 굴리는 연습이 아니라, 더 빨리 멈춰 세우는 연습을 한다. 그게 남는 장사다.

참고: