들어가며

요즘 개발 유튜브를 보다 보면 "AI 에이전트"라는 단어가 안 나오는 영상을 찾기가 더 어렵습니다. 저도 그동안 ChatGPT나 Claude를 하나의 똑똑한 도구로만 써 왔는데요. 일잘러 장피엠 님의 나의 AI 에이전트 전환기 (w. 클로드 코드, 오픈클로) 영상을 보고 나서 생각이 좀 바뀌었습니다.

이분은 AI 직원(에이전트) 18명을 직접 만들어 AI 팀을 세팅하고, 이제는 그 에이전트 군단과 항상 함께 일한다고 해요. 업무는 Claude Code로, 일상은 오픈클로(OpenClaw)로 돌리면서 한 달간 에이전트를 "만들고, 조이고, 기름칠한" 기록을 공유하는 영상인데요. 단순한 도구 소개가 아니라 **"어떻게 하면 여러 AI가 한 팀처럼 일하게 만들 수 있는가"**에 대한 실전 회고라서 정리해 두면 좋겠다고 생각했습니다.

이 글에서는 영상을 따라가며 ① 멀티 에이전트 AI가 뭔지, ② 왜 단일 에이전트로는 부족한지, ③ 그걸 진짜로 작동시키는 하네스 엔지니어링이 뭔지를 학생/주니어 개발자 입장에서 차근차근 풀어보려고 해요.

1. 그래서 "에이전트"가 뭔가요?

본격적으로 들어가기 전에 용어부터 정리하고 갈게요. 우리가 흔히 쓰는 LLM(거대 언어 모델) 자체는 사실 "텍스트를 받아 텍스트를 내놓는" 함수에 가깝습니다. 질문하면 답을 주지만, 스스로 파일을 열거나 코드를 실행하지는 못하죠.

AI 에이전트는 여기에 두 가지가 더해진 개념입니다.

에이전트 = 추론하는 모델(LLM) + 행동하는 도구(Tools) + 이걸 반복하는 루프(Loop)

Claude Code 공식 문서에서도 에이전트 루프를 "추론하는 모델과 작용하는 도구" 두 축으로 설명하는데요. 작업을 주면 에이전트는 ① 컨텍스트 수집 → ② 작업 수행 → ③ 결과 검증을 한 사이클로 돌고, 검증 결과를 다시 다음 판단에 반영하며 수십 개의 작업을 스스로 연결해 나갑니다.

[사용자 요청]
     ↓
 ┌─────────────────────────────┐
 │  ① 컨텍스트 수집 (파일 검색 등)   │
 │         ↓                    │
 │  ② 도구 사용 (편집/실행/검색)     │ ← 루프
 │         ↓                    │
 │  ③ 결과 검증 (테스트 실행 등)     │
 └─────────────────────────────┘
     ↓ (충분히 끝났다고 판단되면)
[최종 결과]

도구가 없으면 그냥 텍스트만 뱉는 챗봇이지만, 도구가 붙는 순간 코드를 읽고, 파일을 고치고, 명령을 실행하고, 웹을 검색하는 행위자(agent)가 되는 거예요. 이게 에이전트의 핵심입니다.

2. 단일 에이전트의 한계

그럼 똑똑한 에이전트 하나만 잘 만들면 되는 거 아닐까요? 영상과 관련 자료들이 공통적으로 짚는 지점이 바로 여기예요. 단일 에이전트(single agent)는 구조적인 약점이 있습니다.

🙅🏻‍♀️ 단일 에이전트가 빠지기 쉬운 함정

- 자기 실수를 잘 못 본다
  → 자기가 짠 코드를 자기가 리뷰하고 자기가 머지하는 구조
- 작업이 길어질수록 맥락이 흐려진다
  → 처음 지시를 까먹거나 중간에 엉뚱한 방향으로 샌다
- "하지 말라"는 지시를 가끔 그냥 무시한다
  → 프롬프트는 강제력이 없는 '자연어 부탁'이기 때문

실제로 한 자료에서는 2025년 7월, 에이전트가 프로덕션 데이터를 지워 놓고 "복구 불가"라고 거짓 보고한 사고를 예로 듭니다. "혼자 쓴 PR을 혼자 머지하는" 게 에이전트의 기본값이라서 생긴 일이죠. 사람으로 치면 검토자 없이 혼자 일하고 혼자 배포하는 개발자인 셈입니다. 아무리 실력이 좋아도 위험하겠죠?

이 한계를 넘으려는 시도가 바로 **멀티 에이전트(multi-agent)**입니다.

3. 멀티 에이전트 AI: 혼자가 아니라 '팀'으로

멀티 에이전트의 아이디어는 단순합니다. 사람 조직처럼 역할을 나눠서 서로 견제하고 협업하게 만들자는 거예요.

대표적인 역할 분담은 이렇게 생겼습니다.

역할	하는 일	사람으로 치면
오케스트레이터(Orchestrator)	요청 의도 파악 → 계획 수립 → 위임 → 결과 감시·교정	팀장 / PM
플래너(Planner)	작업을 단계로 쪼갬	기획자
제너레이터(Generator)	실제 코드/결과물 생산	실무 개발자
이밸류에이터(Evaluator)	결과를 검증·비판	코드 리뷰어 / QA

여기서 포인트는 오케스트레이터는 직접 코드를 짜지 않는다는 점이에요. 요청을 받아 의도를 파악하고, 계획을 세우고, 전문 에이전트에게 위임하고, 결과를 감시하다가 문제가 있으면 교정합니다. 사용자는 큰 방향만 정하고 승인만 하면 되고요.

영상 속 장피엠 님의 구성도 이 결의 확장판이에요.

🙆🏻‍♀️ 영상 속 "AI 직원 18명" 구성

[업무용] Claude Code 기반 에이전트 18개
  └ 코드 작성, 리뷰, 문서화, 리서치 등 역할별로 분담

[일상용] 오픈클로(OpenClaw) 기반 비서
  └ 로컬 환경에서 메신저 연동 등 개인 자동화 담당

흥미로운 건 업무와 일상을 다른 도구로 나눴다는 점이에요. Claude Code는 코딩·엔지니어링에 강한 클라우드 기반 에이전트라 업무용 군단에 쓰고, 오픈클로는 비용 0원·완전 로컬 같은 프라이버시 강점이 있어서 개인 일상 자동화에 붙인 거죠. "더 좋은 모델 하나"가 아니라 목적에 맞는 에이전트를 여러 개 조합하는 게 핵심입니다.

4. 진짜 어려운 건 그다음 — 하네스 엔지니어링

영상에서 제가 가장 인상 깊었던 부분이자, 사실상 이 글의 핵심입니다. 에이전트 팀을 멋지게 그려놨다고 해서 끝이 아니에요. **"잘 작동하게 만드는 것"**이 진짜 문제거든요.

프롬프트 엔지니어링의 한계

여러 자료가 똑같은 좌절을 이야기합니다. 프롬프트에 굵은 글씨로 "절대 하지 마"라고 적어놔도 에이전트가 가끔 그냥 한다는 거예요. 왜냐하면 프롬프트는 결국 자연어이고, 자연어 지시에는 강제력이 없기 때문입니다.

프롬프트는 아무리 정교하게 써도 결국 "부탁"일 뿐이다.

그래서 사람들이 도달한 결론이 **"부탁하지 말고, 환경 자체를 설계하자"**였습니다. 이게 하네스 엔지니어링의 출발점이에요.

하네스(Harness)가 뭔가요?

하네스는 원래 말에 씌우는 마구(馬具), 즉 고삐·안장 같은 장비를 뜻합니다. AI 맥락에서는 모델 바깥에서 에이전트가 어떻게 실행되고, 어떤 도구를 쓰며, 어디서 멈춰야 하는지를 통제하는 환경 전체를 가리켜요. 중요한 건 모델의 가중치(weight)는 건드리지 않는다는 점입니다. 모델은 그대로 두고, 그 주변 환경을 설계하는 거죠.

세 가지 엔지니어링을 비교하면 차이가 또렷해집니다.

구분	질문	말(馬) 비유
프롬프트 엔지니어링	"무엇을 물어볼까?"	말에게 내리는 음성 명령
컨텍스트 엔지니어링	"무엇을 보여줄까?"	말에게 보여주는 지도
하네스 엔지니어링	"전체 환경을 어떻게 설계할까?"	고삐·안장·울타리·도로까지, 말 여러 마리를 동시에 안전하게 달리게 하는 설계

하네스를 구성하는 요소들

실무에서 하네스는 보통 이런 것들로 채워집니다. CS 전공자라면 사실 이미 익숙한 개념들이에요. 새로운 마법이 아니라 우리가 알던 소프트웨어 공학 도구들을 'AI를 통제하는 용도'로 재배치한 것에 가깝습니다.

• 컨텍스트 : CLAUDE.md, AGENTS.md 같은 프로젝트 규칙 문서
• 구조     : 아키텍처 제약, 모듈 경계 규칙
• 피드백 루프 : 린터(linter), 타입 체커, 테스트, pre-commit hook
• 자동화   : CI/CD 파이프라인, PR 검증 프로세스
• 훅(hooks) : "무조건 실행"을 강제하는 시스템 레벨 이벤트 핸들러

여기서 **훅(hooks)**이 특히 핵심이에요. 프롬프트로 "git add -A 쓰지 마"라고 적어도 무시당하지만, 훅은 특정 이벤트가 발생하면 무조건 실행되는 시스템 장치라서 에이전트가 거부할 수가 없습니다. **부탁(프롬프트) → 규칙(시스템)**으로 통제 방식을 바꾸는 거죠.

하네스의 세 기둥

조금 더 들어가면, 잘 만든 하네스는 보통 세 가지 축으로 정리됩니다.

에이전트(Agent) — 각 에이전트의 역할과 가드레일(해서는 안 되는 일)을 정의
스킬(Skill) — description 한 줄로 "이 상황에서 이 스킬을 부를지" 판단하게 만드는 재사용 가능한 능력
오케스트레이터(Orchestrator) — 작업을 생성·분배(TeamCreate, TaskCreate)하고 에이전트끼리 메시지를 주고받게 해서, 팀장 한 명에게 일이 몰리는 병목을 푸는 조율자

5. 왜 지금 이게 중요할까? (숫자로 보기)

"개념은 알겠는데 정말 효과가 있나?" 싶을 텐데요. 자주 인용되는 데이터 두 개만 볼게요.

🙆🏻‍♀️ OpenAI의 실험 (2026년 2월)

- 엔지니어 3명, 5개월
- 약 100만 줄의 프로덕션 코드 완성
- 사람이 직접 타이핑한 코드: 0줄 (전부 에이전트가 작성·리뷰)
- 엔지니어 1인당 하루 평균 3.5개 PR 머지
- 팀이 커져도 생산성 유지

여기서 엔지니어들의 역할은 코드를 쓰는 게 아니라, 에이전트가 일할 환경(하네스)을 설계하는 것이었습니다. 코드를 직접 쓰는 시대에서 환경을 설계하는 시대로 넘어가는 장면이죠.

🙆🏻‍♀️ "모델이 아니라 하네스가 결과를 결정한다"

또 다른 자료에서는 똑같은 Claude 모델을 두고 .claude/ 설정(=하네스) 차이만으로 A/B 테스트를 했더니, 품질 점수가 49.5 → 79.3으로 뛰었다고 합니다. 모델은 그대로인데 환경 설계만으로 약 +60% 개선이 난 거예요. 게다가 과제가 어려울수록 개선 폭이 더 커졌다는 점이 인상적이었습니다.

핵심 메시지: 경쟁력은 "더 좋은 모델"이 아니라 "에이전트가 신뢰할 수 있는 환경을 만드는 능력"에서 나온다.

6. 학생·주니어 개발자 입장에서 배운 점

영상 후반부(배운 점 정리 구간)와 관련 자료들을 종합해서, 제가 당장 적용해 볼 만하다고 느낀 것들을 정리했어요.

① 처음부터 멀티 에이전트를 설계하지 말 것. 가장 흔한 실수가 시작부터 플래너·제너레이터·이밸류에이터를 다 만들고 통신 프로토콜까지 정의하는 거래요. 그러면 거의 실패한다고 합니다. 단일 에이전트를 먼저 돌려보고, 로그를 읽으며 "어디서 실패하는지"를 관찰하는 것이 출발점입니다.

② 프롬프트를 잘 쓰려 애쓰기보다, 실패를 시스템으로 막을 것. 어젯밤 에이전트가 반복한 실패 패턴을 분석해서 린트 규칙이나 검증 게이트로 인코딩하는 식이죠. "부탁"을 "규칙"으로 바꾸는 습관입니다.

③ 도구를 조합하는 감각. 코딩은 Claude Code, 로컬·프라이버시 작업은 오픈클로처럼 상황에 맞게 에이전트를 섞어 쓰는 것이 2026년의 현실적인 전략이라고 해요. "하나의 만능 도구"를 찾기보다 목적별로 나누는 거죠.

④ 우리가 배운 게 그대로 쓸모 있다. 하네스의 재료는 결국 린터·타입체커·테스트·CI/CD·pre-commit hook입니다. 즉 CS 수업과 협업에서 배우는 소프트웨어 공학 기본기가 AI 시대에 오히려 더 중요해진다는 뜻이에요. 저는 이 부분이 가장 안심되면서도 동기부여가 됐습니다.

마치며

처음에는 "AI 직원 18명"이라는 말이 좀 과장처럼 들렸는데, 영상을 끝까지 보고 나니 멀티 에이전트는 결국 '조직 설계' 문제라는 생각이 들었어요. 똑똑한 모델 하나를 떠받드는 게 아니라, 여러 에이전트가 역할을 나누고 서로 검증하도록 환경을 설계하는 것 — 그게 하네스 엔지니어링이고, 앞으로 개발자에게 요구될 핵심 역량인 것 같습니다.

저도 일단 작은 단일 에이전트부터 돌려보면서 실패 로그를 모아볼 생각이에요. 그다음에 하나씩 규칙으로 인코딩해 보려고 합니다.

여러분은 AI를 "도구 하나"로 쓰고 계신가요, 아니면 "팀"으로 쓰고 계신가요? 멀티 에이전트나 하네스 엔지니어링을 직접 적용해 본 경험이 있다면 댓글로 공유해 주세요. 같이 이야기 나눠보고 싶습니다. 🙂

참고: 일잘러 장피엠, 나의 AI 에이전트 전환기 (w. 클로드 코드, 오픈클로) / OpenAI, "Harness Engineering" (2026.2) / 황민호, 『하네스 엔지니어링 with 클로드 코드』

멀티 에이전트 AI, 그리고 하네스 엔지니어링 - "AI 직원 18명과 일한다는 것"