안녕하세요, 저는 최근 Claude AI를 활용하여 에이전트를 개발하는 과정에서 겪은 문제를 해결하기 위해 이 글을 작성합니다.

제가 만든 에이전트는 특정 작업을 수행하기 위해 여러 개의 서브에이전트(subagents)로 구성되어 있습니다. 이 서브에이전트들은 주기적으로 CHANNEL.md 파일을 폴링(polling)하는 구조입니다. 문제는 이 파일들이 실제로 변경되지 않는데도 불구하고, 계속해서 폴링을 시도하면서 불필요한 리소스 사용과 API 호출 비용 증가를 초래한다는 점입니다.

저는 이 문제를 해결하기 위해 '에이전트용 Slack'이라는 개념을 도입했습니다. 즉, 에이전트들이 메시지를 주고받고 상태 변화를 알리는 중앙 집중식 통신 채널을 구축하겠다는 것입니다. 이를 통해 폴링 방식 대신 이벤트 기반(event-driven) 방식으로 시스템을 재설계할 수 있게 되었습니다.

[IMG:1]

기존의 구조는 다음과 같았습니다. 서브에이전트들이 모두 CHANNEL.md 파일을 주기적으로 확인하고, 파일 내용에 변화가 있는지 검사하는 방식입니다. 이는 마치 모든 사람이 매번 우체통을 열어보는 것과 같습니다.

새로운 아키텍처에서는 이 통신 채널 역할을 하는 'Slack'을 도입했습니다. 에이전트들이 직접 메시지를 보내거나(send messages) 특정 이벤트가 발생했을 때만 알림을 받게 됩니다. 따라서 불필요한 폴링은 사라지고, 필요한 순간에만 정보가 전달됩니다.

[IMG:2]

실제 구현 과정에서는 다음과 같은 기술 스택을 사용했습니다:

1. Claude API: 에이전트의 핵심 추론 및 의사결정 엔진 역할을 합니다.
2. Slack API: 에이전트 간의 통신, 상태 공유, 작업 할당 등의 인터페이스로 활용됩니다.
3. 백엔드 서버 (예: Python/FastAPI): Slack 웹훅(webhook)을 수신하고, 이를 Claude가 이해할 수 있는 형식으로 변환하여 전달하는 중개자 역할을 합니다.

이 구조의 장점은 명확합니다. 첫째, 효율성입니다. 폴링 대신 이벤트 기반 통신을 사용하므로 리소스 낭비가 없습니다. 둘째, 확장성입니다. 새로운 서브에이전트나 기능을 추가할 때 기존 시스템에 미치는 영향이 적습니다.

결론적으로, 저는 에이전트 개발의 한계를 극복하고 더 견고하며 효율적인 시스템을 구축하기 위해 'Slack for agents'라는 아키텍처를 설계하고 구현했습니다. 이 경험을 통해 AI 에이전트 시스템은 단순한 스크립트 실행을 넘어, 실제 협업하는 소프트웨어 조직처럼 작동해야 한다는 것을 깨달았습니다.