한 줄 결론: 똑똑한 모델 하나를 기대하는 것보다, 멍청한 모델이라도 촘촘한 역할 분담과 검수 게이트(Harness) 안에 가두는 것이 훨씬 일관된 결과를 냅니다.
왜 다들 모델 성능만 올리려고 하는데, 실제 에이전트한테 일을 시켜보면 바보처럼 굴까요?
저도 제 블로그 파이프라인을 자동화하면서 똑같은 고민을 했습니다. 프롬프트를 아무리 길고 예쁘게 써봐도, Claude 3.5 Sonnet이든 Opus든 가끔씩 엉뚱한 결과물을 내놓곤 했죠. 결국 에이전트 숫자를 늘리는 게 아니라, 그들이 움직이는 ‘규칙’을 재설계해야 한다는 걸 48명짜리 AI 가상 게임 스튜디오 템플릿과 ‘하네스 깎기’ 개념을 실무에 적용해보고 나서야 깨달았습니다.
지금 이 패러다임이 중요한 이유
가장 큰 착각 중 하나는 “프롬프트를 잘 쓰면 해결될 것”이라는 믿음입니다. 최근 48명의 AI가 크리에이티브 디렉터, QA 리드 등으로 역할을 나눠서 가상 게임 스튜디오를 운영한 템플릿 사례가 화제였습니다. 여기서 놀라운 점은 각 에이전트의 지능이 아니라, 36개의 엄격한 명령어와 코딩 규칙, 그리고 자동화된 검수 과정을 거친다는 점입니다. 단일 모델 성능보다 질문을 주고 의사결정을 기다리는 스웜(Swarm) 구조와 게이트 설계가 성과를 좌우한 겁니다.
여기에 DIO 김지운 FDE님이 강조하신 ‘하네스 엔지니어링(Harness Engineering)’이란 개념이 더해지면 퍼즐이 맞춰집니다. 비정형적인 요구사항을 CPS(Context, Problem, Solution) 프레임워크로 쪼개고, 린터(Linter)를 통해 폴더명이나 코딩 컨벤션을 억지로라도 강제해야 엔터프라이즈 레벨의 몇등성(Idempotency, 누가 언제 해도 똑같은 결과가 나오는 성질)을 확보할 수 있다는 겁니다.
블로그 자동화 파이프라인에 직접 적용해 본 결과
솔직히 처음엔 저도 에이전트 숫자만 늘리면 다 될 줄 알았습니다. 그래서 당장 제 블로그 발행 자동화 파이프라인 템플릿부터 뜯어고쳐 보았습니다. 모델에게 “잘 써줘”라고 거대한 지시를 내리던 원팀 체제에서, 작성, 검수, 발행을 분리하는 게이트형 구조로 역할을 명확히 쪼갰습니다.
| 기존 워크플로 (실패) | 하네스 기반 멀티 에이전트 (현재) |
|---|---|
| 지시: “투자 블로그 글 하나 써줘” | 지시: “Research 결과를 Writer에게, 평가를 Reviewer에게” |
| 권한: 작성 후 즉시 발행 | 권한: Review 게이트 통과 시에만 발행 허가 |
| 검증: 거의 없음 (운에 맡김) | 검증: 체크리스트 불합격 시 Writer로 반송 |
바뀐 3단계 하네스 설계
- 역할(Role) 분리: 전체 글을 쓰는
blog-writer와 데이터를 수집하는blog-researcher, 품질을 점검하는blog-reviewer로 명확히 나눴습니다. - 검수 게이트(Gate) 강제: 리뷰어가 체크리스트(예: SEO 타겟팅 위반, 과장된 빈도수 등)를 들고 검사합니다. 통과하지 못하면 작성 단계로 다시 돌아갑니다.
- 스킬(Skill) 제한: 자유도를 주기보다는 템플릿 구조와 작성 가이드라인을 강제하는 스킬을 엄격하게 적용했습니다.
이렇게 세팅하고 나니 엉뚱한 결론을 내거나 형식을 파괴하는 일이 90% 이상 줄어들었습니다.
실수 방지 TOP 3
멀티 에이전트 시스템을 도입할 때 흔히 하는 실수들은 다음과 같습니다.
- 무작정 에이전트 인원수만 늘리기: 역할이 중복되거나 보고 체계가 없으면 48명이 아니라 100명이어도 결과가 산으로 갑니다. 검수 게이트 없는 조직은 위험합니다.
- 자유도를 너무 많이 주기: AI한테 친절한 존댓말로 부탁할 시간에, AI가 벗어나지 못할 단단한 규칙(하네스)을 먼저 설계해야 유지보수가 가능합니다.
- 실패에 대한 폴백(Fallback) 미비: 에이전트가 에러를 낼 때 무작정 중단하지 않고, 어디로 에스컬레이션할지(예: 2회 이상 게이트 실패 시 책임자에게 알림) 경로를 정해둬야 합니다.
언제 이 구조를 피해야 할까?
모든 작업에 48명짜리 거대 팀이나 엄격한 리뷰 게이트가 필요한 것은 아닙니다. 단순 텍스트 요약, 한번 쓰고 버릴 일회성 스크립트 작성 등에는 이 방식이 오버 엔지니어링입니다. 하지만 일관된 품질이 지속적으로 필요한 운영 파이프라인(예: 블로그 자동 퍼블리싱, 일일 시황 리포트 자동화)에는 반드시 하네스 엔진과 다중 검수 게이트를 붙이는 것이 정답입니다.
FAQ
Q. 하네스 엔지니어링이 프롬프트 엔지니어링이랑 다른 게 뭔가요? 프롬프트가 “이렇게 해줄래?”라고 부탁하는 거라면, 하네스 엔지니어링은 AI가 “이렇게밖에 할 수 없도록” 시스템과 린터, 강제 규칙을 설계하는 겁니다. 어떤 언어모델을 갖다 끼워도 똑같은 품질의 결과가 나오게 만드는 목적입니다.
Q. 개인도 멀티 에이전트를 쉽게 구축할 수 있나요? 네, OpenAI의 Assistants API, LangChain, 혹은 오픈소스 프레임워크들을 잘 활용하면 각기 다른 시스템 프롬프트를 가진 여러 에이전트를 만들고, 이들을 파이프라인으로 연결할 수 있습니다.
Q. 리뷰어 에이전트의 역할은 구체적으로 어떻게 세팅하나요? 단순히 “글이 좋은가요?”가 아니라, 구체적인 채널의 가이드라인(예: 특정 단어 금지, 지정된 템플릿 요소 누락 확인) 단위로 쪼개어 채점표 양식을 주어야 제대로 작동합니다.
Q. 에이전트가 게이트를 계속 통과하지 못하면 어떻게 되나요? 조직 설계 시 최대 재시도(Retry) 횟수를 정해두고, 이를 초과하면 프로세스를 멈추고 사람(HQ)에게 알림을 오게끔 에스컬레이션(Escalation) 룰을 만듭니다.
참고 자료
- “48명 AI 가상 게임 스튜디오 크리에이터 팀” (Threads 원문 발췌, 2026.03)
- “상위 1% AI 네이티브들은 프롬프트 안쓰고 ‘하네스 깎기’에 수백시간 투자합니다” (DIO FDE 김지운 님 인터뷰, 2026.03)