[물류 컨설팅 자동화 / 1주차] AI 에이전트 팀 구성과 운영 가이드

개요

물류 컨설팅 업무(시장 조사, 고객 데이터 분석, 전략 도출, 문서 작성, 자동화 설계)의 반복적인 작업을
AI 에이전트 팀이 처리하고, 나는 방향성 조정 및 최종 의사결정만 담당하는 구조를 만들고자 했다.

목표

• 반복 업무 14가지를 에이전트가 자율 수행

• 에이전트들이 Discord에서 서로 소통하는 모습을 눈으로 확인
  (소통 과정을 지켜보다가 사람이 개입 가능한 구조)

• 병렬 작업 가능한 실제 멀티에이전트 구조 구현

최종 팀 구성

1단계: 팀 설계

업무 매핑

먼저 실제 물류 컨설팅 반복 업무 13가지를 정의하고, 각 에이전트에게 매핑했다.

• 수요·공급 동향 분석 → Brian

• 경쟁사·벤치마킹 분석 → Brian

• 규제·정책 모니터링 → Brian

• 고객 운영/손익 데이터 분석 → Phil

• 고객 현황 파악 및 니즈 정의 → Phil

• 전략 방향 도출 → Annie

• 개선 방안 수립 → Annie

• 물류 트렌드 및 최신 기술 분석 → Dan

• AX/DX 로드맵 설계 → Dan

• 제안서/보고서 작성 → Jin

• 회의록 정리 → Jin

• 고객 커뮤니케이션 추적 → Owen

• 아이디어 발굴 → Spark

• PM / 팀 조율 / 최종 검토 → KE

핵심 설계 원칙

KE는 에이전트이기도 하고, 사용자(나)의 분신이기도 하다.
KE가 #square에서 지시를 내리면 → 담당 에이전트가 자기 채널에서 작업 → #square에 완료 보고.

📌 추가 작업 필요
에이전트 수가 너무 많지는 않은지? 필요 이상으로 업무가 쪼개져있지 않은지?
일을 어떻게 묶고 나누어 줄 때 가장 시너지가 날 지 (업무 결과와 경제성 모두의 관점에서)
여러 테스트를 통해 깎아나가기

2단계: Discord 채널 구조 설계

채널 10개 구성

📁 THE TEAM

• ├── #pm-room ← KE 작업 공간

• ├── #market-intel ← Brian

• ├── #client-data ← Phil (처음엔 data-analysis로 설계했다가 수정)

• ├── #strategy ← Annie

• ├── #ax-dx-automation ← Dan

• ├── #ideation ← Spark

• ├── #reports ← Jin

• ├── #clients ← Owen

• ├── #decisions ← 의사결정 기록 (아카이브)

• └── #square ← 에이전트 간 공개 조율 채널 (핵심)

핵심 결정: #square의 역할

처음엔 #bot-hub로 부르려 했지만,
에이전트들이 서로 광장(square) 에서 보고하고 조율한다는 개념으로 #square로 확정.
모든 위임, 수신 확인, 완료 보고가 #square에서 일어난다.

📌 추가 작업 필요
decision과 square를 나누는 것이 효율적인지 검토 필요

3단계: 기술 구현

사용 기술 스택

Hermes (Nous Research) — AI 에이전트 프레임워크

• ├── Profiles: 에이전트별 독립 인스턴스

• ├── SOUL.md: 에이전트 페르소나 정의

• └── Skills: 커스텀 도구

Discord

• ├── Bot Tokens: 에이전트별 개별 봇 (진짜 @멘션 가능)

• └── Webhooks: 채널별 게시 (채널에 에이전트 이름/아바타로 포스팅)

the_team_post.py — 웹훅 래퍼 스크립트

디렉토리 구조

~/.hermes/

• ├── config.yaml # 메인 Hermes 설정

• ├── the_team_post.py # 웹훅 포스팅 스크립트

• ├── the_team_webhooks.yaml # 웹훅 URL 목록

• ├── skills/the-team/post-as-agent/ # Hermes 스킬

• └── profiles/

•   ├── ke/

•   │ ├── SOUL.md

•   │ ├── config.yaml

•   │ └── .env

•   ├── brian/

•   ├── phil/

•   ├── jin/

•   ├── annie/

•   ├── dan/

•   ├── owen/

•   └── spark/

웹훅 포스팅 스크립트

```python
# ~/.hermes/the_team_post.py
WEBHOOKS = {
    "KE": "https://discord.com/api/webhooks/...",
    "Brian": "https://discord.com/api/webhooks/...",
    "Phil": "https://discord.com/api/webhooks/...",
    # ... 8개 에이전트
}

def post_message(agent_name, message):
    payload = {"username": agent_name, "content": message}
    headers = {
        "Content-Type": "application/json",
        "User-Agent": "TheTeamBot/1.0"  # ← 이게 없으면 403 발생
    }
    # requests.post(webhook_url, json=payload, headers=headers)
```

SOUL.md 워크플로우 프로토콜

에이전트가 자율적으로 Discord에 포스팅하도록 SOUL.md에 명시적 지침을 추가했다:

Task Execution Protocol (항상 준수)

#square에서 KE로부터 태스크를 받으면:

1. #square에 수신 확인: "알겠습니다. [태스크명] 시작합니다."

2. 터미널로 #[전담채널]에 작업 계획 포스팅:

3. python3 ~/.hermes/the_team_post.py Brian "📋 작업 지시 [내용] 🔍 수행 방법 [계획]"

4. 작업 수행

5. 터미널로 #[전담채널]에 결과 포스팅:

6. python3 ~/.hermes/the_team_post.py Brian "✅ 완료 [결과]"

7. #square에 완료 보고: "@KE 완료했습니다. #market-intel 확인 바랍니다."

📌 추가 작업 필요
각 채널에서 대화 가능하고, KE가 태스크를 분배하는 것 같지만
square에서 분배나 작업 진행 상황 포스팅 같은 것들은 아직 일어나지 않고 있음

트러블슈팅 기록

(문제 1) 웹훅 403 Forbidden

• 상황 : Python 스크립트로 웹훅 호출 시 403, curl은 204 성공

• 원인 : Discord가 기본 Python User-Agent 차단

• 해결 : User-Agent: TheTeamBot/1.0 헤더 추가

(문제 2) Discord 앱 이름 최소 2자

• 상황 : 에이전트 "K"로 Discord 앱 생성 불가

• 해결 : "KE"로 변경, 관련 파일 전체 업데이트

(문제 3) 에이전트가 채널 간 소통을 안 함

• 상황 : channel_prompts만으로는 에이전트가 다른 채널에 자발적으로 포스팅하지 않음

• 원인 : 에이전트는 암묵적 워크플로우를 추론하지 않음

• 해결 : SOUL.md에 python3 ~/.hermes/the_team_post.py 명령어를 명시적으로 작성

인사이트 & 레슨런

(인사이트 1) "보이는 팀"을 원했던 이유

처음엔 "에이전트들이 자기 채널에서 일하고 square에서 조율"하길 원한다고 했는데,
그 본질은 에이전트의 작업 과정을 눈으로 추적하고 싶다는 것이었다.
결과만 받아보는 게 아니라 중간 과정을 보여주는 것이 멀티에이전트 시스템에서 신뢰감을 준다.

(인사이트 2) 에이전트는 자율적이지 않다

봇 여러 개가 병렬로 일하는 "자율 팀"을 기대했지만, 실제로는 각 에이전트는 지시를 받아야 움직인다.
자율성처럼 보이는 것은 SOUL.md에 써 놓은 행동 지침의 실행이다. 즉, 에이전트의 자율성은 설계에서 온다.

(인사이트 3) 역할 경계 설계가 핵심

초기 설계에서 역할이 겹쳤다:

• Owen vs Phil: 둘 다 고객 관련

• Brian vs Dan: 둘 다 리서치 성격

해결 프레임:

• Owen = 귀 (듣고 관계 관리)

• Phil = 눈 (데이터로 현황 파악)

• Brian = 외부 세계 (시장·산업 동향)

• Dan = 기술 솔루션 (구체적 시스템 추천)

역할이 명확해야 에이전트 간 위임이 자연스럽게 작동한다.

(인사이트 4) SOUL.md = 에이전트의 헌법

SOUL.md는 단순한 프롬프트가 아니라 에이전트의 행동 원칙 + 실행 절차를 담은 헌법이다.
페르소나(성격)만 있으면 반쪽이고, 워크플로우 프로토콜(절차)이 함께 있어야 실용적으로 작동한다.

레슨런 요약

현재 상태 및 다음 단계

완료된 것

• [x] Hermes 설치 + 봇 8개 Discord 연결

• [x] 채널 10개 구성 + 웹훅 설정

• [x] the_team_post.py 스크립트 완성

• [x] 모든 에이전트 SOUL.md 작성 (워크플로우 프로토콜 포함)

• [x] 각 에이전트 Hermes Profile 설정

남은 것

• [ ] Jin, Annie, Dan, Owen, Spark SOUL.md 페르소나 세부 정제

• [ ] MEMORY.md / AGENTS.md 작성

• [ ] llm-wiki 목차 초안

• [ ] 실제 워크플로우 테스트 (KE→ Brian + Jin 병렬 위임)

마치며

이 시스템의 핵심은 "에이전트가 일하는 것을 보여주는 것" 이다.
결과만 받아보는 단일 AI 어시스턴트와 달리, 멀티에이전트 팀은 과정이 보인다.
#square에서 에이전트들이 서로 보고하고 조율하는 모습은 단순한 기능이 아니라,
팀이 존재한다는 감각을 만들어준다.

기술보다 설계가 먼저다.