텔레그램 봇 개발 일지 #4 — Hub-and-Spoke와 specialist subagent

결론부터

메인 채팅 토픽은 conversational hub로 두고, 무거운 프로젝트 작업은 specialist subagent로 dispatch한다. hub는 라우팅·요약·짧은 응답에 집중하고, 8단계짜리 편집·커밋·테스트는 specialist가 자기 cwd에서 끝낸 뒤 1-2문장 보고로 돌아온다. 사용자가 채팅을 계속 칠 수 있는 상태를 유지하는 게 핵심.

왜 hub가 필요한가

3편에서 토픽=프로젝트로 분리했는데, 한 가지 문제가 남았다. 텔레그램은 봇이 turn을 끝내기 전에 "Thinking..." 상태로 멈춰 있는다. 그 turn 안에서 sequential하게 8개 도구 호출이 일어나면 사용자는 몇 분간 키보드가 막혀 있는 느낌을 받는다.

해결: hub turn은 결정·보고만 하고, 실제 일은 다른 컨텍스트로 떠넘긴다.

specialist subagent 구조

각 프로젝트마다 specialist subagent를 정의했다. ~/.claude/agents/에 마크다운으로 둔다.

• daily-feed-specialist → D:/playground/daily-feed만 다룸
• idea-cycles-specialist → D:/playground/idea-cycles만 다룸
• telegram-bot-specialist → D:/playground/telegram-claude-bot만 다룸

호출 패턴은 단순하다.

Agent({
  subagent_type: "daily-feed-specialist",
  description: "Korean news routine tweak",
  prompt: "<사용자 요청 + 필요한 컨텍스트>"
})

각 specialist는 자기 cwd에 들어간 깨끗한 시스템 프롬프트로 시작한다. hub의 잡다한 컨텍스트가 묻어가지 않으니 토큰도 절약되고 판단도 또렷해진다.

hub의 역할

hub가 처리하는 것과 위임하는 것의 경계가 중요하다.

• hub가 직접 — 짧은 질문(스케줄 몇 시야?), 두 프로젝트를 동시에 보는 cross-cutting 요청, 대화의 맥락이 살아있어야 하는 backforth.
• specialist에 dispatch — 한 프로젝트에 국한된 다단계 편집·테스트·커밋, 같은 디렉토리에서 여러 파일을 동시에 만지는 작업.

호출 후 hub가 받는 건 specialist의 1-2 문장 요약이다. 전체 보고서를 그대로 사용자에게 던지지 않는다 — 사용자에게 도착하는 메시지는 hub가 자기 톤으로 다시 다듬어 보낸다.

[specialist 응답]
"새 봇 PID 32824, mcp-server PID 33900, BLOG_API_URL=4322 적용 확인. ..."
 
[hub가 사용자에게]
"봇 재시작 완료(새 PID 32824). MCP 경로도 검증할게요."

다음 편 예고

5편은 라이브 메시지 — 긴 응답을 한 메시지에 점진적으로 갱신하는 throttle, 도구 호출 라인 truncate, 마무리 ✅/⚠️ 핑 메시지로 알림을 깨우는 디테일을 다룬다.