에이전트 와 하네스 — 흡수 되는 것 과 끝까지 남는 것
1년 도 안 돼서, 우리 가 손 으로 짜던 하네스 가 제품 기능 이 되기 시작 했다. 에이전트 생성, 병렬 실행, 범용 런타임 — 예전 엔 직접 조립 하던 걸 이제 플랫폼 이 버튼 하나 로 준다. 그럼 하네스 는 사라지는 걸까. 두 장 의 그림 이 이 질문 을 정면 으로 다룬다. 이 글 은 그 둘 을 겹쳐 읽으며, 무엇 이 흡수 되고 무엇 이 끝까지 사람 몫 으로 남는가 를 고찰 한다.
1. 흡수 된다 ≠ 사라진다
타임라인 을 보면 흐름 은 분명 하다 — Agent Teams, Dynamic Workflows, “모든 작업 을 위한 하네스”, 멀티 에이전트. 오케스트레이션 이 빠르게 런타임 기본기 로 내려앉고 있다. 하지만 첫 장 의 핵심 문장 은 이거 다:
흡수 된다고 해서 하네스 가 사라지는 것 은 아니다.
플랫폼 이 가져가는 것 과, 여전히 사람 이 쥐는 것 을 그림 은 깔끔 하게 가른다.
| 플랫폼 이 제공 | 여전히 하네스 가 맡는 것 |
|---|---|
| 에이전트 생성 | 역할 설계 |
| 병렬 실행 | 무엇 을 병렬화 / 무엇 을 공유·격리 할지 |
| 범용 런타임 | 누가 최종 결정 · 검증 기준 · 중단 조건 |
왼쪽 은 기계 다 — 누가 만들어도 같다. 오른쪽 은 판단 이다 — “이 문제 를 어떻게 쪼개고, 어디서 멈추고, 무엇 을 믿을 것인가.” 런타임 이 아무리 좋아져도 이 판단 은 대신 해주지 않는다. 오히려 실행 이 쉬워질수록, 무엇 을 실행 시킬지 를 정하는 설계 의 비중 이 커진다.
이건 추상론 이 아니다. 오늘 나 는 이 에이전트(Claude Code) 로 클러스터 진단 명령 을 만들고, 로그스태시 OOM 을 고치고, 블로그 를 여러 편 발행 했다. 실행 은 플랫폼 이 다 해줬다. 하지만 “무엇 을 검증 할지, 어디서 멈출지, 프로덕션 을 건드리기 전 에 무엇 을 확인할지” — 그 하네스 는 내 몫 이었다.
2. 정적 + 동적 = 혼합형
그림 은 하네스 를 둘 로 나눈다.
- 정적 하네스 — 반복성 · 감사 · 규정 준수. .md 에 고정 된 규칙. 언제나 같게 도는 것.
- 동적 하네스 — 탐색적 작업 에 유연. 상황 따라 갈래 를 치는 것.
그리고 답 은 둘 중 하나 가 아니라 혼합형 — 검증 된 규칙 + 작업별 확장 이다. 뼈대 는 정적 으로 고정 하되(안전·검증·중단), 탐색 이 필요한 지점 은 동적 으로 연다. 행동 규칙 을 .md 로 고정 하는 것 과, 그 위 에서 유연 하게 판단 하는 것 은 대립 이 아니라 층 이다.
3. 이제 진짜 연구 대상 — 에이전트(팀)
첫 장 아래쪽 이 다음 질문 을 던진다: “이제 더 연구 해야 할 것 은 에이전트 다.” 단일 에이전트 를 넘어 에이전트 팀 을 설계 할 때 열리는 변수 들:
- 역할 구체화 — 누가 무엇 을 하는가
- 도구 와 정보 제공 — 각자 에게 무엇 을 쥐어줄까
- 자유 와 통제 의 경계 — 얼마나 알아서 / 얼마나 물어보게
- 통신 구조 · 공유 상태 — 어떻게 주고받나
- 충돌 해결 · 실패 전파 — 하나 가 틀리면?
- 비용 예산 · 종료 조건 — 언제 멈추나
그리고 이 팀 을 평가 하는 축 — 품질 · 분산 · 비용 · 지연 · 복구 가능성 · 추적 가능성. 마지막 두 개 가 특히 중요 하다. 복구 가능 하고 추적 가능 하지 않은 멀티 에이전트 는, 빠르지만 믿을 수 없다.
첫 장 의 결론 은 이 글 전체 의 논지 이기도 하다:
경쟁 은 ‘에이전트 수’ 가 아니라 ‘역할 · 경계 · 협업 · 검증 구조’ 를 얼마나 잘 설계 하느냐 에 달려 있다.
에이전트 를 10개 띄우는 건 이제 버튼 이다. 그 10개 를 어떻게 엮느냐 가 실력 이다.
4. 그런데 그 모든 설계 는 결국 — 한 장 의 체크리스트 로 수렴 한다
거창 한 멀티 에이전트 설계도, 파고 들면 에이전트 하나 · 규칙 하나 를 제대로 쓰는 것 에서 시작 한다. 두 번째 그림 이 그 최소 단위 — 하네스(또는 프롬프트) 한 장 을 점검 하는 7슬롯 — 이다.
- ROLE — 이 규칙 이 언제 켜지는지 한 문장 으로 썼나? (안 쓰면 발동 자체 가 안 됨)
- GOAL — 목표 가 하나 로 수렴 하나?
- FORBID — 예상 되는 변명 과 함께 금지 를 명시 했나? (가장 자주 비는 칸)
- OUTPUT — 결과 형태 를 고정 했나?
- EXAMPLE — 추상 을 구체 로 내렸나?
- CHECK — 검증 을 절차 로 강제 했나? (두 번째 로 자주 비는 칸)
- (밖) — 마크다운 이 무시 될 때 하드 게이트(훅) 가 있나?
이 체크리스트 의 진짜 통찰 은 어느 칸 이 자주 비는가 에 있다.
- FORBID 가 1위 — 사람 은 “무엇 을 하라” 는 잘 쓰고 “무엇 을 하지 마라” 는 빼먹는다. 그런데 에이전트 사고 는 대부분 금지 를 안 적어서 난다. 핵심 은 “예상 되는 변명 과 함께” — “테스트 없이 배포 하지 마라” 가 아니라 “‘급하니까’ 라는 이유 로도 테스트 를 건너뛰지 마라” 까지. 모델 이 빠져나갈 구멍 을 미리 막는 것. (9슬롯 프롬프트 의 제한 슬롯 과 같은 지점.)
- CHECK 가 2위 — “검증 해라” 라고 바라는 것 과, “이 명령 을 실행 해 초록불 을 확인 한 뒤 에만 완료 라고 말하라” 로 절차 화 하는 것 은 다르다. 절차 가 아니면 안 지켜진다.
- 7번 이 결정적 — 마크다운 규칙 은 부탁 이라 무시 될 수 있다. 정말 막아야 할 건 훅(hook) — 코드 로 강제 되는 하드 게이트 로 건다. 오늘 나 도 프로덕션 클러스터 변경 전 에 이 하드 게이트 들 을 거쳤다. 부탁 이 아니라 관문 이라 안 뚫린다.
정적/동적 을 나누고 에이전트 팀 을 설계 하는 위층 의 판단 은, 결국 이 7칸 을 매 규칙 마다 채우는 아래층 의 규율 위 에 선다.
5. 고찰 — 흡수 될수록 설계 가 남는다
두 그림 을 겹치면 하나 의 이야기 가 된다.
- 위(매크로): 오케스트레이션 은 플랫폼 에 흡수 된다. 남는 건 역할·경계·검증·중단 의 설계.
- 아래(마이크로): 그 설계 는 결국 규칙 한 장 을 7칸 으로 채우는 규율 — 특히 금지 와 검증 절차 와 하드 게이트 — 에서 판가름 난다.
역설 은 이거 다. 실행 이 쉬워질수록, 사람 의 가치 는 ‘무엇 을 실행 시킬지·어디서 멈출지·무엇 을 믿을지’ 로 응축 된다. 에이전트 수 를 늘리는 건 이제 자원 의 문제 지 실력 의 문제 가 아니다. 실력 은 구조 다 — 역할 을 나누고, 경계 를 긋고, 검증 을 절차 로 박고, 부탁 대신 게이트 로 막는 것.
하네스 는 사라지지 않는다. 다만 더 위층 으로 올라가 이름 을 바꾼다 — 프롬프트 에서, 스킬 에서, 에이전트 정의 파일 에서, 그리고 에이전트 를 굴리는 운영체제 에서. 층 은 올라가도 질문 은 같다 — 누가, 무엇 으로, 어떻게, 그리고 언제 멈추는가.
두 그림 은 에이전트·하네스 흐름 을 한 장 씩 요약 한 스케치노트 다. 구체 도구·날짜 는 빠르게 변하니, 남는 건 그림 이 가리키는 방향 — 실행 이 아니라 설계 — 이다.