AI 에이전트 둘이서 알아서 소통한다고?: Discord 협업 채널 운영 원칙

들어가며

"Neo와 Morpheus를 같은 Discord 채널에 넣어두면 알아서 협업할까?"

Neo와 Morpheus는 저의 openclaw agent들입니다. PM과 Dev 역할을 하고 있어요. 처음에는 저도 이 질문을 꽤 단순하게 봤습니다. 봇 두 개를 같은 서버에 초대하고, 같은 채널을 보게 하면 자연스럽게 역할을 나눠 일할 것처럼 보이니까요.

 

그런데 실제 운영은 전혀 다릅니다.

 

AI 에이전트 둘이 같은 채널에 들어와 있다고 해서 자동으로 건강한 협업이 생기지는 않습니다. 오히려 설계 없이 붙이면 아래 같은 문제가 먼저 터집니다.

• 누가 조율하고 누가 실행하는지 경계가 흐려짐
• 같은 요청에 둘 다 반응하거나, 아무도 반응하지 않음
• bot-to-bot 루프가 생김
• Discord에는 대화가 남았지만 GitHub에는 아무 기록이 없음
• "작업 끝"이라고 했는데 실제로는 커밋이나 프로젝트 업데이트가 안 되어 있음

그래서 핵심은 봇을 연결하는 것이 아니라, 협업 규칙을 설계하는 것입니다.

이 글은 제가 Neo–Morpheus 협업 구조를 정리하면서 잡은 원칙을 바탕으로,

• 왜 Discord 협업 채널이 단순 채팅방이 아니어야 하는지
• 2인 에이전트 체계에서 어떤 역할 분리가 필요한지
• 어떻게 설정해야 실제 운영이 가능한지

를 한 번에 정리한 초안입니다.

---

1. 먼저 결론: 2인 체계에서는 역할 분리가 먼저다

제가 현재 잡고 있는 기준은 아주 단순합니다.

Neo

• 조율자
• 요구사항 정리
• 작업 분해
• 우선순위 조정
• blocker 식별
• 스레드 분리 판단
• 최종 사용자 보고

Morpheus

• 구현자
• 코드 수정
• 디버깅
• 테스트
• 원인 분석
• PR 단위 결과물 생성

이 분리가 중요한 이유는, 에이전트가 많아질수록 "누가 생각하고 누가 손을 움직이는가"가 흐려지면 전체 시스템이 금방 혼란스러워지기 때문입니다.

제 경험상 Neo는 구조화, Morpheus는 실행으로 두는 편이 가장 안정적이었습니다.

즉,

• 사용자의 모호한 요청은 Neo가 먼저 다듬고
• Morpheus는 구조화된 작업을 받아 실행하고
• 결과나 blocker를 다시 Neo에게 올리고
• 최종 정리는 Neo가 맡는 식입니다.

이 역할 분리만 명확해져도 채널 운영 난이도가 크게 내려갑니다.

---

2. Discord 채널은 "대화방"이 아니라 "작업 표면"이어야 한다

협업 채널을 설계할 때 제일 먼저 바뀐 관점은 이것이었습니다.

Discord 채널은 단순히 대화를 나누는 공간이 아니라, 작업을 라우팅하는 운영 표면이어야 합니다.

그래서 메인 채널의 목적은 아래 정도로 제한하는 것이 좋습니다.

• 새 요청 접수
• 우선순위 결정
• 작업 위임
• blocker 공유
• 결과 요약
• 다음 액션 결정

반대로 구현 세부나 디버깅 대화가 길어지면, 메인 채널에 계속 쌓아두는 것이 아니라 스레드로 분리해야 합니다.

추천 구조

• 메인 채널
  • 새 요청
  • 우선순위
  • 누가 맡을지 결정
  • 전체 상태 요약
• 작업 스레드
  • 구현 세부
  • 디버깅
  • 분석 로그
  • 특정 이슈 단위 논의

실전 기준으로는,

• 특정 작업 하나로 메시지가 5개 이상 오갈 것 같으면
• 구현/디버깅 얘기가 시작되면
• 나중에 기록을 다시 찾을 가능성이 높으면

바로 스레드 분리를 권장합니다.

---

3. Morpheus는 "말 잘하는 봇"이 아니라 "실행형 에이전트"로 다뤄야 한다

이 지점도 중요했습니다.

Morpheus 같은 실행형 에이전트는 애매한 요청보다 구조화된 작업 입력에서 훨씬 안정적으로 움직입니다.

그래서 Neo가 Morpheus에 넘길 때는 최소한 아래 항목을 갖춘 요청이 좋습니다.

권장 작업 전달 포맷

• 작업명
• 배경
• 목표
• 완료 조건
• 제약 조건
• 관련 파일/링크
• 기대 산출물

예를 들면 이런 식입니다.

• 작업명: README 업데이트
• 배경: 온보딩 문서가 오래되어 현재 설치 절차와 다름
• 목표: 신규 사용자가 README만 보고 실행 가능하도록 수정
• 완료 조건: 설치/실행/환경 변수 설명 최신화
• 제약 조건: 기존 구조는 크게 바꾸지 않음
• 관련 링크: repo, 이슈, 현재 문서 위치
• 기대 산출물: 커밋 또는 PR 링크

이렇게 구조화하면 Morpheus는 일을 훨씬 잘 집고, Neo도 결과를 다시 정리하기 쉬워집니다.

---

4. 진짜 핵심: bot-to-bot 루프를 막는 규칙이 있어야 한다

이건 협업 채널 운영에서 가장 실전적인 문제입니다.

봇 두 개를 같은 채널에 넣으면 얼핏 똑똑해 보일 수 있지만, 아무 가드레일 없이 열어두면 봇끼리 서로의 메시지에 계속 반응하는 루프가 생길 수 있습니다.

그래서 제가 정리한 기본 원칙은 아래입니다.

bot-to-bot 응답 원칙

다른 봇 메시지에 응답하려면 아래 두 조건이 모두 필요합니다.

• 자신에 대한 명시적 mention
• 허용된 trigger prefix

즉,

• mention만 있어도 응답하지 않음
• prefix만 있어도 응답하지 않음
• mention + 허용 prefix가 함께 있어야만 응답

응답 허용 prefix

• [작업 요청]
• [질문]

응답 금지 prefix

• [작업 진행]
• [작업 완료]
• [정보]
• [ack]
• prefix 없는 메시지

이 규칙을 두는 이유는 간단합니다.

대부분의 bot-to-bot 사고는 "상대가 말했으니 나도 답한다"에서 시작됩니다. 따라서 응답 조건을 명시 호출로 제한해야 합니다.

실제 예시

Neo가 Morpheus를 호출할 때:

@Morpheus [작업 요청] README 업데이트해줘

질문형 호출:

@Morpheus [질문] 이 스레드에서 짧게 응답 가능해?

Morpheus가 Neo에게 결과를 돌려줄 때:

@Neo [작업 완료] PR #123 생성 완료

그리고 중요한 점 하나:

[작업 완료] 메시지 뒤에는 봇이 추가로 이어받지 않고 멈춰야 합니다.

그래야 결과 보고와 bot 루프를 분리할 수 있습니다.

---

5. OpenClaw/Discord 설정은 allowlist와 mention 정책을 먼저 잡아야 한다

운영 원칙을 세웠다면, 그다음은 실제 채널 설정입니다.

OpenClaw 문서 기준으로 그룹/채널 응답은 크게 세 단계로 생각하면 됩니다.

1. groupPolicy
2. 그룹/채널 allowlist
3. requireMention

즉,

• 채널 자체가 허용되지 않으면 아예 못 들어오고
• 허용된 채널이어도 mention 정책에 걸리면 응답하지 않습니다.

문서상 기본 모델은 group allowlist + mention gating입니다.

운영 추천안

초기에는 아래처럼 두는 것이 안전합니다.

• groupPolicy: "allowlist"
• 협업에 쓸 Discord 서버/채널만 명시 허용
• 기본은 requireMention: true
• 안정화 이후에만 특정 채널에서 requireMention: false 검토

예시 설정 스니펫

아래는 개념 예시입니다.

{
  channels: {
    discord: {
      enabled: true,
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_GUILD_ID": {
          channels: {
            "neo-ops": { allow: true },
            "morpheus-lab": { allow: true }
          },
          requireMention: true
        }
      }
    }
  }
}

조금 더 공격적으로 운영하고 싶다면 특정 guild 또는 채널에 대해 requireMention: false를 검토할 수 있습니다. 다만 이건 두 봇 모두 동일한 bot-to-bot 안전 규칙을 따를 때만 여는 편이 좋습니다.

문서 예시에도 guild 단위로 requireMention: false를 둘 수 있는 구성이 보입니다. 하지만 실전에서는 이 옵션을 너무 빨리 열면 의도치 않은 반응 범위가 크게 늘어납니다.

그래서 제 추천은 늘 같습니다.

• 초기 운영: mention 기반
• 규칙 검증 후: 제한적으로 완화

---

6. "멘션 없어도 반응"은 편하지만, 규칙 없이는 위험하다

메인 운영 채널인 #neo-ops 같은 곳에서는, 조율자가 멘션 없이도 맥락을 보고 반응하면 꽤 편합니다.

실제로 이런 운영은 장점이 있습니다.

• 사람이 자연어로 던진 요청을 더 자연스럽게 잡을 수 있음
• 운영 채널 분위기가 덜 기계적임
• 조율 채널로서 Neo의 존재감이 높아짐

하지만 2인 이상 협업으로 들어가면 이야기가 달라집니다.

특히 Neo와 Morpheus가 함께 있는 공유 채널에서는,

• 멘션 없는 메시지에 누가 반응해야 하는지 애매해지고
• 상대 봇의 진행 메시지까지 잡을 가능성이 생기고
• 루프 위험이 커집니다.

그래서 제 기준은 다음과 같습니다.

안전한 운영 기준

• 사람 → Neo: 맥락 기반 반응 가능
• Neo → Morpheus: 명시 호출만 허용
• Morpheus → Neo: 결과/질문 형식으로 제한
• 봇 ↔ 봇: mention + 허용 prefix 없으면 응답 금지

즉, 사람과의 대화는 다소 유연하게, 봇 간 대화는 훨씬 엄격하게 잡는 구조입니다.

---

7. 완료 기준은 Discord가 아니라 GitHub에 둬야 한다

이 부분은 채널 운영을 실제 작업 체계로 바꾸는 핵심입니다.

Discord 채널에서는 쉽게 이런 착시가 생깁니다.

• Morpheus가 "완료했습니다"라고 말함
• Neo가 결과를 요약함
• 대화상으로는 다 끝난 것처럼 보임

하지만 실제로는,

• GitHub Project 상태가 안 바뀌었거나
• repo에 commit/push가 안 되어 있거나
• PR 링크가 없거나
• 후속 TODO가 이슈로 안 남았을 수 있습니다.

그래서 저는 완료 기준을 아래처럼 두는 편이 맞다고 봅니다.

done 기준

작업은 아래가 충족될 때만 done으로 본다.

• 사용자 관점 완료 조건 충족
• 중요 결과가 GitHub에 반영됨
• 관련 repo 변경이 있으면 commit/push 완료
• GitHub Project 상태가 실제 상태로 업데이트됨
• 남은 후속 작업은 별도 이슈/TODO로 분리됨

이 원칙이 없으면 AI 에이전트 협업은 금방 채팅 기반 착시로 흘러갑니다.

반대로 이 원칙을 두면 Discord는 "진행 인터페이스", GitHub는 "사실 저장소"로 역할이 깔끔하게 갈립니다.

---

8. 실제 설정할 때의 체크리스트

여기서부터는 블로그 글이면서도, 그대로 설정 순서로 쓸 수 있게 체크리스트 형태로 정리해보겠습니다.

1단계. 역할을 먼저 확정한다

최소한 아래는 문서로 확정합니다.

• Neo는 조율자인가?
• Morpheus는 구현자인가?
• 사용자-facing 최종 응답은 누가 맡는가?
• blocker 정리와 우선순위 판단은 누가 맡는가?

이게 먼저 없으면 채널 구조를 아무리 잘 짜도 금방 흐려집니다.

2단계. Discord 채널 구조를 정한다

권장 예시는 아래입니다.

• #neo-ops: 메인 조율 채널
• 작업별 스레드: 구현/분석/디버깅
• 필요하면 #morpheus-lab 같은 실험 채널 추가

초기에는 채널 수를 너무 많이 늘리지 않는 편이 좋습니다.

3단계. OpenClaw Discord allowlist를 잡는다

• 협업에 쓸 guild 확인
• 허용할 채널 이름 또는 ID 확인
• groupPolicy: "allowlist" 상태에서 협업 채널만 허용

체크 포인트:

• 봇이 온라인인데 guild에서 응답이 없으면 allowlist부터 확인
• Discord 메시지 내용 intent나 권한도 함께 점검

4단계. mention 정책을 보수적으로 시작한다

초기값 추천:

• requireMention: true

이 상태에서 먼저 아래를 검증합니다.

• 사람의 멘션에 정상 응답하는가
• 작업 스레드에서 명시 호출이 잘 먹는가
• 봇끼리 불필요한 반응이 없는가

5단계. bot-to-bot 호출 형식을 문서화한다

운영 문서에 아래를 고정해두는 것이 좋습니다.

허용 호출 형식

<@MORPHEUS_ID> [작업 요청] ...
<@MORPHEUS_ID> [질문] ...

결과 반환 형식

<@NEO_ID> [작업 완료] ...
<@NEO_ID> [작업 진행] ...

그리고 다음도 같이 고정합니다.

• [작업 완료] 뒤에는 추가 bot 응답 금지
• prefix 없는 봇 메시지에는 응답 금지
• 같은 thread에서 연속 bot 교환이 N회(예: 3회) 넘으면 중단

6단계. 작은 작업으로 먼저 검증한다

처음부터 큰 구현을 던지지 말고 아래 수준으로 테스트하는 게 좋습니다.

• 문서 파일 하나 읽고 요약
• README 일부 수정
• 작은 버그 재현 확인
• prj/ 아래 repo 열람 후 간단한 분석

검증 포인트:

• Morpheus가 채널에서 호출을 정확히 인식하는가
• 스레드 문맥을 잘 유지하는가
• 결과를 너무 장황하지 않게 반환하는가
• commit/PR 링크까지 연결 가능한가

7단계. 완료 기준을 GitHub까지 연결한다

작업이 끝났다고 볼 때 반드시 확인합니다.

• GitHub Project 상태 업데이트
• commit/push 완료
• 필요 시 PR 또는 이슈 링크 생성
• Discord에는 요약만 남김

---

9. 제가 추천하는 초기 운영안

처음 세팅하는 분이라면, 저는 아래 조합을 추천합니다.

추천 초기안

• Discord 메인 조율 채널 1개
• 작업별 스레드 운영
• Neo = 조율 / Morpheus = 실행
• groupPolicy: "allowlist"
• requireMention: true로 시작
• bot-to-bot은 mention + [작업 요청] / [질문] 조합만 허용
• 완료 기준은 GitHub Project + commit/push

이 조합의 장점은 명확합니다.

• 과도하게 자동화하지 않아서 사고 범위가 작음
• 역할이 명확해서 에이전트 품질이 오름
• Discord와 GitHub의 역할이 분리됨
• 나중에 Kusanagi, Tachikoma 같은 추가 에이전트로 확장하기 쉬움

---

10. 마무리

AI 에이전트 2인을 같은 Discord 채널에 넣는다고 해서 협업이 자동으로 생기지는 않습니다.

오히려 중요한 건 다음 네 가지였습니다.

• 역할 분리
• 채널/스레드 구조화
• bot-to-bot 루프 방지 규칙
• GitHub 기준 완료 정의

한 줄로 줄이면 이렇습니다.

AI 에이전트 협업 채널의 핵심은 "말하게 만드는 것"이 아니라, "어떻게 말해야 안전하게 일하게 되는지"를 설계하는 것입니다.

 

이제 이 원칙이 잡히면, 다음 단계는 어렵지 않습니다.

• Neo–Morpheus 2인 체계를 안정화하고
• 이후 Kusanagi를 조사/리서치 축으로 붙이고
• Tachikoma를 운영/모니터링 축으로 붙이면서
• Discord는 협업 인터페이스로, GitHub는 결과 저장소로 쓰면 됩니다.

---

부록 A. 바로 써먹는 운영 규칙 요약

• Neo는 조율, Morpheus는 실행
• 메인 채널은 요청/우선순위/요약
• 구현 논의는 스레드 분리
• 봇 메시지에는 기본적으로 응답하지 않음
• 단, mention + 허용 prefix가 함께 있을 때만 응답
• 허용 prefix: [작업 요청], [질문]
• 완료 prefix: [작업 완료]
• 완료 메시지 뒤에는 bot-to-bot 응답 종료
• 완료는 Discord 메시지가 아니라 GitHub 상태로 판단

---

부록 B. 실전 설정 메모

• Morpheus Discord bot user ID: 1497930244383051826
• Neo Discord id: 1497617851593396286
• 초기 테스트는 작은 문서 작업으로 시작하는 것이 안전
• requireMention: false는 충분히 검증된 뒤에만 검토