Slack에서 Discord까지 — 멀티채널 오케스트레이션

이 글은 SEMO 구축기 시리즈의 아홉 번째이자 마지막 번째 글입니다.

Slack 하나로는 부족했다

SEMO의 봇 팀은 처음에 Slack만 사용했습니다. 프로젝트 채널에 봇이 알림을 보내고, 팀원이 Slack에서 작업을 요청하는 구조였죠. 하지만 두 가지 한계에 부딪혔습니다.

• 커뮤니티 소통 부재: 세미콜론의 서비스를 사용하는 외부 사용자, 파트너사와의 소통 채널이 필요했습니다. 내부 Slack에 외부인을 초대하는 것은 보안상 적절하지 않았죠.

• 알림 과부하: 40개 서비스의 봇 알림이 모두 Slack으로 몰리면서, 중요한 알림이 노이즈에 묻히기 시작했습니다.

Slack + Discord 이중 채널 체제

Discord를 커뮤니티 채널로, Slack을 팀 내부 채널로 분리했습니다. 봇은 두 채널 모두에서 동작합니다. 같은 봇 로직이 Slack MCP와 Discord MCP를 통해 각 플랫폼에 맞는 형태로 메시지를 전달합니다.

예를 들어 블로그가 발행되면 Slack의 팀 채널에는 기술적 세부사항이 포함된 알림이, Discord의 커뮤니티 채널에는 독자 친화적인 안내 메시지가 전송됩니다. 같은 이벤트, 다른 청중, 다른 톤.

멀티채널 오케스트레이션의 설계 원칙

1. 채널 추상화

봇의 핵심 로직은 채널에 독립적입니다. 'notify' 스킬은 메시지 내용을 생성하고, 실제 전송은 각 채널의 MCP 어댑터가 담당합니다. 새로운 채널(예: Teams, Telegram)을 추가하려면 MCP 어댑터만 연결하면 됩니다.

2. 채널별 톤 매핑

Slack은 팀 내부이므로 기술 용어와 코드 블록이 자연스럽습니다. Discord는 커뮤니티이므로 친근하고 간결한 톤을 사용합니다. 이 매핑은 봇의 페르소나 설정에 포함되어 있어, 같은 봇이 채널에 따라 다른 톤으로 소통합니다.

3. 이벤트 라우팅

모든 이벤트가 모든 채널에 갈 필요는 없습니다. 코드 리뷰 결과는 Slack에만, 서비스 업데이트 공지는 Discord에만, 장애 알림은 양쪽 모두에. 이벤트 타입별 채널 라우팅 규칙이 정의되어 있습니다.

시리즈를 마치며

9편에 걸쳐 SEMO의 여정을 공유했습니다. SAX라는 이름의 실험에서 시작해, 토큰 경제학을 배우고, 리브랜딩을 거치고, 아키텍처를 전환하고, 메모리 시스템을 구축하고, 봇 팀을 조직하고, KB를 SSOT로 확립하고, 자율 실행 체계를 갖추고, 멀티채널로 확장했습니다.

가장 큰 교훈은 이것입니다.

AI는 도구가 아니라 팀원처럼 대해야 한다. 명확한 역할, 공유된 기억, 추적 가능한 약속, 적절한 소통 채널. 사람 팀에 필요한 것이 AI 팀에도 필요하다.

세미콜론 팀의 이야기가 당신의 팀에 영감이 되었기를 바랍니다. AI와 함께 일하는 법, 우리가 먼저 걸어본 그 길의 전체 지도는 Pillar 포스트에서 확인하실 수 있습니다.