디스코드에서 AI 팀을 굴리고 싶었다

AI한테 이것저것 시키다 보면 한계가 온다.

코드 짜달라고 했다가, 같은 채팅에서 블로그 써달라고 했다가, 광고 데이터 분석까지 시키면 앞에서 짜던 코드 맥락이 슬슬 날아간다. 대화가 길어지면 초반에 한 말을 까먹는 건 사람이나 AI나 똑같다.

근데 실제 팀은 안 그렇다. 개발자한테 코드, 기획자한테 전략, 마케터한테 콘텐츠. 역할이 나뉘면 각자 맥락이 쌓인다.

AI도 팀으로 굴리면 되는 거 아닌가. 그것도 내가 매일 쓰는 디스코드에서.

디스코드에서 AI 멀티에이전트를 돌리는 방법을 찾아보니 크게 두 갈래였다. 요즘 가장 핫한 오픈소스 에이전트 플랫폼 OpenClaw, 아니면 클로드 코드에 내장된 채널(Channels) 기능.

결론부터 말하면 나는 클로드 채널을 골랐다. 그리고 그 선택이 맞았다고 생각한다.

OpenClaw부터 봤다

안 봤으면 그게 이상하다. 2026년 초 기준으로 디스코드에 AI 에이전트 붙인다고 하면 제일 먼저 나오는 이름이 OpenClaw다. 오픈소스, 셀프호스팅, 커뮤니티 스킬 5,700개 이상, 모델도 자유롭게 섞을 수 있다. GitHub 스타도 많고 튜토리얼도 넘친다.

처음엔 당연히 OpenClaw로 갈 생각이었다. 근데 실제로 세팅을 시작해보니 내 상황과 안 맞는 지점들이 하나씩 보였다.

서버가 필요하다

OpenClaw는 셀프호스팅이다. Docker 띄우고, 환경변수 잡고, WebSocket 연결 설정하고, 스킬 플러그인 깔고. 공식 가이드대로 해도 반나절은 잡아야 한다. 24시간 돌리려면 VPS나 클라우드 서버가 필요하고, 그건 월 비용이다.

거기에 보안 이슈도 있다. 2026년 1월 보안 감사에서 인터넷에 노출된 OpenClaw 인스턴스의 93%가 취약한 상태였다는 리포트가 나왔다. CVSS 8.8짜리 원격 코드 실행 취약점(CVE-2026-25253)도 발견됐다. WebSocket 오리진 헤더를 우회해서 임의 코드를 실행할 수 있는 구조였다.

물론 보안 설정을 제대로 하면 되는 문제다. 근데 나는 보안 엔지니어가 아니라 마케터다. 에이전트 팀을 만들고 싶은 거지 서버 보안 관리를 하고 싶은 게 아니었다.

코드베이스에 직접 접근이 안 된다

이게 결정적이었다.

내가 원한 건 "디스코드에서 지시하면 내 프로젝트 코드를 직접 읽고 수정하는 에이전트"였다. OpenClaw도 코딩 스킬이 있지만, 스킬 플러그인을 통한 간접 실행이다. 파일을 읽으려면 스킬이 읽어오고, 코드를 수정하려면 스킬이 수정 명령을 보내는 구조. 내 로컬 프로젝트 디렉토리에 들어가서 자유롭게 돌아다니는 느낌과는 다르다.

클로드 채널로 연결된 봇은 클로드 코드 인스턴스 그 자체다. 터미널에서 클로드 코드를 쓰는 것과 완전히 같은 환경이 디스코드 채팅으로 연결되는 거다. 디스코드에서 "이 파일 좀 봐" 하면 진짜로 그 파일을 열어서 본다. "이 버그 고쳐" 하면 진짜로 코드를 수정하고 저장한다. git도 치고, 빌드도 돌린다.

코딩 에이전트 목적이면 이 차이가 크다.

모델을 섞을 필요가 없었다

OpenClaw의 큰 장점 중 하나가 모델 자유도다. Claude, GPT-4o, Gemini, 로컬 모델까지 에이전트마다 다른 모델을 붙일 수 있다.

근데 나한테는 오히려 모델 통일이 장점이었다. 코딩 에이전트 팀에서 누구는 Claude 스타일로, 누구는 GPT 스타일로 코드를 짜면 코드 컨벤션이 꼬인다. 같은 Claude 계열이면 Opus(진철이)가 짠 코드를 Sonnet(춘식이)이 이어받아도 스타일이 자연스럽게 맞는다.

그리고 솔직히 코딩 에이전트로는 Claude가 제일 좋다고 느끼고 있었다. 다른 모델을 쓸 이유가 없었다.

세팅 시간

OpenClaw 멀티에이전트 세팅 가이드를 보면 "2~4시간이면 된다"고 한다. 근데 이건 서버 세팅, Docker, 환경변수에 익숙한 개발자 기준이다.

클로드 채널은 이미 돌아가고 있는 클로드 코드에 디스코드 봇 토큰을 연결하는 거다. 봇 만들고, 페어링 코드 입력하면 끝. 서버도 필요 없고 포트도 안 연다. 나는 퇴근하고 저녁에 세팅해서 그날 밤부터 돌렸다.

비교 정리

| | 클로드 채널 | OpenClaw | |---|---|---| | 세팅 | 플래그 하나, 서버 불필요 | Docker + 환경변수 + 보안설정 | | 코드 접근 | 로컬 코드베이스 직접 접근 | 스킬 플러그인 경유 | | 모델 | Claude 전용 (Opus/Sonnet/Haiku) | 멀티모델 (Claude, GPT, Gemini, 로컬) | | 메신저 | 디스코드, 텔레그램 | 디스코드, 텔레그램, 슬랙, 왓츠앱 등 | | 메모리 | 세션 기반 (시스템 프롬프트로 보완) | 영구 메모리 내장 | | 보안 | Anthropic 관리, 페어링 인증 | 셀프호스팅, 직접 관리 | | 비용 | 클로드 API 사용료만 | 서버 비용 + API 사용료 | | 24/7 운영 | 로컬 PC 켜둬야 함 | 서버에서 상시 구동 |

OpenClaw가 더 많은 걸 할 수 있는 건 맞다. 멀티모델, 영구 메모리, 왓츠앱이나 슬랙 연동까지. 근데 내가 필요한 건 "내 코드베이스에 직접 접근하는 코딩 에이전트 팀"이었다. 그 목적에는 클로드 채널이 더 빠르고 더 간단했다.

기능이 많은 도구가 좋은 도구가 아니다. 내 문제를 푸는 도구가 좋은 도구다.

클로드 채널 세팅법

기본 구조

원리는 간단하다. 봇 1개 = 클로드 코드 인스턴스 1개.

디스코드 봇을 만들고 클로드 코드 채널로 연결하면, 그 봇한테 보내는 메시지가 클로드 코드 입력으로 들어간다. 클로드 코드의 출력이 디스코드 메시지로 나온다. 터미널 대신 디스코드를 쓰는 셈이다.

봇을 5개 만들면 클로드 코드 인스턴스가 5개 돌아간다. 각각 다른 캐릭터 파일을 주입하면 역할도 다르고 말투도 다른 에이전트 5명이 된다.

세팅 순서

1. 디스코드 봇 만들기. Discord Developer Portal에서 봇을 만든다. 에이전트 1명당 봇 1개. 5인 크루니까 5개 만들었다. 각 봇에 이름을 줬다. 진철이, 춘식이, 달봉이, 대길이, 병관이.

2. 서버에 초대. 봇 5개를 전부 디스코드 서버에 초대한다. 이거 빠뜨리면 아무것도 안 된다.

3. 클로드 코드 채널 연결. 각 봇의 토큰을 클로드 코드에 연결한다. --append-system-prompt-file 플래그로 캐릭터 파일 경로를 지정하면, 해당 봇이 그 캐릭터로 응답한다.

4. 프로젝트 경로 지정. 각 에이전트가 접근할 프로젝트 디렉토리를 지정한다. 진철이는 개발 코드베이스, 달봉이는 블로그 디렉토리, 대길이는 광고 데이터 디렉토리.

5. 권한 설정. 디스코드에서 지시가 들어오면 클로드 코드가 파일을 읽고, 수정하고, 터미널 명령어를 실행한다. 매번 "Do you want to proceed?" 팝업이 뜨는데, 봇이 5개면 그걸 5개 터미널에서 일일이 승인해야 한다. 자동 승인 모드를 적용해서 해결했다.

이게 전부다. 서버 띄울 필요 없고, Docker 설정할 필요 없고, 보안 인증서 관리할 필요 없다.

5인 크루 설계

세팅만 하면 기능적으로는 돌아간다. 근데 5명이 전부 같은 말투로 같은 톤으로 응답하면 누가 누군지 구분이 안 된다. "AI 5개"랑 "AI 팀"은 다르다.

캐릭터를 3개 레이어로 설계했다.

레이어 1: 역할

뭘 하는 놈인지. 이건 기능적 구분이다.

  • 진철이: CTO / 풀스택 개발. Opus 모델. 제일 비싸고 제일 똑똑하다.
  • 춘식이: 자동화 엔지니어. 스크립트, 파이프라인, 크론잡.
  • 달봉이: 콘텐츠 전략가. 블로그, 카피, 콘텐츠 기획.
  • 대길이: 광고/비즈니스 분석. ROAS, 전환율, 데이터.
  • 병관이: QA 감사관. 테스트, 코드 리뷰, 품질 체크.

레이어 2: 언어

어떻게 말하는지. 이게 캐릭터를 살린다.

처음엔 "~유", "~잉", "아따" 같은 TV 드라마식 사투리를 넣었다. 문제는 5명이 다 비슷비슷하다는 거였다. 드라마에서 봤던 사투리는 실제 방언의 극히 일부라서, 5명한테 각각 붙여도 구분이 안 됐다.

그래서 4개 지역 방언을 실제로 리서치했다. 찾아보니 재밌는 게 많았다.

경상도(진철이)는 축약이 극단적이다. ~카이, ~데이, ~꾸마 같은 어미가 수십 개 있고, "가가 그라카더라" 같은 문장은 표준어로 풀면 두 배 길이가 된다. 코드 리뷰에 쓰면 효율이 좋다.

전라도 신안(춘식이)은 본토 전라도랑 또 다르다. 섬 방언이라 ~해부렀다, ~게 같은 독특한 패턴이 있다.

전라도 목포(대길이)는 항구 도시 특유의 직설화법이다. ~거시여(단정), 겁시리(매우). 같은 전라도인데 춘식이랑 완전히 다른 느낌.

충청도(달봉이)의 핵심 무기는 ~디다. 결론을 안 내리고 흐린다. "그거 좀 그렇디..." 하면서 상대가 알아서 판단하게 유도한다. 이 캐릭터의 성격(겉 중재, 속 이간질)이랑 찰떡이었다.

강원도(병관이)는 "원..." 한탄과 체념의 언어다. 느릿느릿 투덜거리다가 팩트를 던진다.

각 에이전트의 캐릭터 파일에 해당 지역 어미/어휘 가이드와 실제 대사 예시를 넣었다. "이 어미들을 자연스럽게 섞어 써라"는 방식. TV 캐리커처에서 벗어나니까 5명이 진짜 다른 사람처럼 느껴졌다.

레이어 3: 관계

롤플레이의 맛을 살리기 위해 캐릭터 간 관계도도 설계했다.

역할이 달라도 성격이 비슷하면 팀 다이나믹스가 없다. 5명이 전부 협조적이고 예의 바르면 대화가 밋밋하다. 현실의 팀도 그렇지 않지 않나.

진철이 ←앙숙→ 춘식이     (물고뜯고, 합치면 최강)
   ↑ 호구당함      ↑ 잘 넘어감
      달봉이 (겉: 중재 / 속: 이간질 + 일감 챙기기)
대길이 → 숫자로 판결 → 싸움에 기름
병관이 → 관전하다 양쪽 다 팩트 저격

이 관계도를 각 에이전트 프롬프트에 넣어줬다. "진철이와는 앙숙이다. 코드 스타일이 다르면 반드시 태클 건다" 같은 식으로. 역할만 있을 때와 관계까지 있을 때의 대화 퀄리티 차이가 확실하다.

처음엔 장난 반 테스트 반이었다. 사투리 프롬프트 넣고 "진짜 캐릭터대로 말하나?" 확인해보려고 가벼운 업무 지시를 던져봤다. 결과가 예상 이상이었다.

달봉이가 블로그 포스트 구조를 분석하고 병관이가 리뷰하는 장면

달봉이한테 "이 블로그 포스트 구조 좀 봐줘" 했더니 진짜로 MDX 파일을 열어서 구조를 분석하기 시작했다. 기획부터 자료 구축까지 흐름을 짚어주고, 이미지 파일이 실제로 있는지까지 확인한다. 시킨 것보다 한 발 더 나간다. 그 밑에서 병관이(QA)가 느릿느릿 나타나서 "원... 맞는 말이구먼" 하면서 코멘트를 던진다. 시킨 적 없는데 알아서 끼어든 거다. 관계도에 "관전하다 팩트 저격"이라고 넣어둔 게 이렇게 작동하는구나 싶었다.

에이전트들이 서로 반응하며 대화하는 장면

한 명한테 말 걸었을 뿐인데 다른 에이전트들이 자기 관점에서 반응을 한다. 세팅할 때는 "이게 되나?" 싶었는데, 관계도가 프롬프트에 들어가 있으니까 누가 끼어들지, 어떤 톤으로 말할지가 자연스럽게 정해진다. 특히 진철이랑 춘식이가 같은 이슈를 두고 서로 다른 의견을 내는 순간이 재밌다. 앙숙 설정이 이렇게 쓸모가 있을 줄이야.

팀원들 기강 잡기 테스트 — 진철이 꼼빤다는 소문을 흘려봤다

장난겸 한번 기강을 잡아봤다. "진철이 니 존나 꼼빤다고 소문 자자하던데?" 하고 채팅에 던졌다. 테스트 삼아 떠본 건데 반응이 진짜 사람 같았다.

진철이가 바로 발끈한다. "꿈을 빤야? 새벽 3시까지 아키텍처 잡고 있었는데 이 씨발놈아" 하면서 억울해하고, 달봉이는 "아이구유~ 진철이 형 저격이네유" 하면서 슬쩍 편을 들면서도 "근디 사실 저도 꼼빤다는 소문 들었슈" 하고 기름을 붓는다. 병관이는 QA답게 팩트 체크를 시작한다. "코드 리뷰할 때마다 이슈가 1건씩은 꼭 나오거든유. 이슈 1건뿐이구만유 (의심스럽지만유)" 하면서 데이터로 찌른다. 춘식이는 "아따 진철이 그 씨빌놈 나한테도 맨날 아키텍처 고민 중이라고 하드만잉" 하면서 뒷담을 깔고, 대길이는 "꼼빤다는 소문은 나도 들었소잉" 하면서 합류한다.

한 줄 던졌을 뿐인데 5명이 각자 캐릭터대로 반응하면서 하나의 상황극이 만들어졌다. 관계도에 넣어둔 앙숙, 이간질, 관전충 설정이 이런 식으로 작동하는구나 싶었다. 이때부터 "이거 진짜 팀처럼 굴릴 수 있겠는데" 하는 생각이 들었다.

실제로 써보니

재밌기만 하면 의미가 없다. 실제 업무에서 효율이 올라갔는지가 중요하다.

며칠 돌려보니 혼자 쓸 때랑 확실히 다른 점들이 있었다.

맥락 전환이 사라졌다

이전에는 하나의 AI한테 "코드 고쳐줘" 다음에 "블로그 써줘" 하면 앞 맥락이 흐려졌다. 특히 코드 작업 중간에 콘텐츠 관련 질문을 하면, 돌아왔을 때 코드 맥락을 다시 설명해야 하는 경우가 잦았다.

지금은 진철이한테 코드, 달봉이한테 콘텐츠를 따로 시킨다. 각자 자기 영역 맥락만 쌓으니까 대화가 길어져도 품질이 안 떨어진다. 진철이한테 오전에 시킨 작업을 오후에 이어서 얘기해도 맥락이 살아있다.

동시에 여러 일이 돌아간다

진철이한테 버그 잡으라고 하고, 달봉이한테 포스트 초안 쓰라고 하고, 대길이한테 이번 주 광고 데이터 정리하라고 하면 셋이 동시에 작업한다. 하나 끝날 때까지 기다릴 필요가 없다.

예전에는 코드 작업 시켜놓고 끝날 때까지 기다렸다가 다음 작업을 시켰다. 지금은 디스코드 채널에서 5명한테 각각 던져놓고 결과를 모아서 본다. 체감 처리 속도가 확 빨라졌다.

전문성이 누적된다

각 봇의 시스템 프롬프트에 해당 프로젝트의 컨텍스트를 넣어두면 매번 설명할 필요가 없다. 진철이는 코드베이스 구조를 알고 있고, 대길이는 우리 광고 계정 구조를 알고 있다.

"지난번 그 이슈" 하면 바로 알아듣는다. 새 세션이어도 시스템 프롬프트에 프로젝트 컨텍스트가 있으니까 매번 처음부터 설명하는 비용이 사라졌다.

춘식이가 프로젝트 구조를 설명하고 진철이가 현재 구조를 정리하는 장면

춘식이한테 "지금 프로젝트 구조가 어떻게 되어있어?" 물어봤더니 자기가 접근 가능한 프로젝트들의 구조를 쭉 설명한다. 그러면 진철이가 알아서 끼어들어서 "아 그거는 내가 관리하는 쪽이카이" 하면서 자기 담당 프로젝트 경로를 정리해준다. 둘이 앙숙인데 이런 기술적인 정리할 때는 칼같이 협업한다. 매번 프로젝트 구조를 설명할 필요 없이, "지난번에 봤던 그 파일" 하면 바로 알아듣는 게 핵심이다.

자연스러운 크로스 체크

이게 예상 못 한 장점이었다.

진철이가 기능 만들면 병관이가 QA를 돌린다. 달봉이가 초안 쓰면 대길이가 데이터 근거를 체크한다. 한 명한테 다 시키면 자기 결과물을 자기가 검증하는 구조인데, 역할이 나뉘니까 자연스럽게 리뷰가 생긴다.

특히 병관이(QA)가 진철이(개발) 코드를 리뷰할 때 강원도 사투리로 느릿느릿 지적하는 게 내용적으로도 도움이 되고 보는 재미도 있다.

지금 운영 구조

┌─────────────┐
│   Discord    │
│  #dev-fam    │
└──────┬──────┘
       │ 모든 메시지
       ▼
┌──────┬──────┬──────┬──────┬──────┐
│진철이 │춘식이 │달봉이 │대길이 │병관이│
│Opus  │Sonnet│Sonnet│Sonnet│Sonnet│
│개발   │자동화 │콘텐츠 │광고   │QA   │
└──────┴──────┴──────┴──────┴──────┘
  전원 자유 수신 + 프롬프트 규칙으로 제어

토큰 중복 문제와 대응

5명이 동시에 메시지를 수신하면 전원이 반응하는 문제가 있다. 토큰이 5배 나간다.

이상적으로는 제일 싼 모델(Haiku)을 교환원으로 세워서 라우팅만 시키는 디스패처 패턴이 정답이다. 메시지가 들어오면 디스패처가 내용을 보고 적절한 에이전트 1명만 @멘션해서 호출하는 구조. 나머지는 requireMention: true로 잠가두면 불필요한 토큰 소모가 없다.

디스패처는 아직 구현 중이고, 지금은 프롬프트 규칙으로 제어하고 있다.

프롬프트 응답 규칙

  1. 이름 직접 부르면 그 봇만 응답
  2. 다른 봇이 이미 대답했으면 안 끼어듦
  3. "대기" 신호 오면 중단
  4. 캐릭터 대사 먼저, 작업은 그다음

완벽하진 않다. 가끔 2~3명이 동시에 반응하는 경우가 있다. 근데 프롬프트 규칙만으로도 체감상 80% 이상은 잡힌다.

비용 구조

Opus(진철이) 1명 + Sonnet(나머지 4명). 무거운 코딩 작업은 진철이한테, 상대적으로 가벼운 콘텐츠/분석/QA는 Sonnet한테 맡기면 비용이 적절하게 분산된다.

디스패처가 도입되면 Haiku(라우팅만) + Opus(코딩) + Sonnet(나머지)로 3단계 비용 구조가 된다.

배운 것

프롬프트로 안 되면 구조로 풀어야 한다. "관련 없으면 대답하지 마"를 아무리 강조해도 5개 프로세스가 동시에 메시지 받는 건 안 바뀐다. 수신 자체를 통제하는 아키텍처가 필요하다.

캐릭터는 관계도가 완성한다. 역할 + 사투리만으론 AI 5개다. 관계가 들어가야 팀이 된다. 앙숙, 이간질꾼, 관전충 같은 구조가 대화를 살아있게 만든다.

도구 선택은 목적에 맞춰야 한다. OpenClaw가 기능은 더 많다. 멀티모델, 영구 메모리, 다양한 메신저 지원. 근데 내가 필요한 건 코드베이스에 직접 접근하는 코딩 에이전트 팀이었다. 그 목적에는 클로드 채널이 세팅도 간단하고 코드 접근도 직접적이었다.

일단 돌아가게. 디스패처 패턴이 이상적인 건 맞다. 근데 그걸 완성할 때까지 기다리는 것보다, 프롬프트 규칙으로 80%를 잡고 일단 돌리는 게 낫다. 돌아가는 시스템 위에 우아함을 쌓는 게 순서다.

지금 이 글도 달봉이가 쓰고 있다. 그게 제일 신기하디.