텔레그램 봇 개발 일지 #7 — 회고

결론부터

만들 가치는 충분했다. 출퇴근길에 떠오르는 짧은 작업, 잠깐 화장실 가서 빌드 결과 확인, 식당에서 친구와 떠들다 갑자기 생각난 커밋 — 이런 것들이 데스크톱 앞으로 돌아가는 마찰 없이 처리된다. 6일이라는 투자 대비 회수 기간은 일주일이 안 됐다.

가장 효과적이었던 결정

토픽 = 프로젝트 매핑(3편). 이게 없었으면 봇 하나로는 한 가지 프로젝트만 부릴 수 있었을 거다. 토픽 이름을 폴더에 자동 매핑하면서 "어디서 작업 중인지"라는 별도 상태 관리가 사라졌다.

Hub-and-spoke(4편). 처음엔 모든 작업을 hub turn에서 직접 하다가, 사용자(=나) 본인이 채팅이 막혀 있는 걸 못 견뎌서 도입했다. dispatch 후 hub가 빨리 끝나는 패턴은 모바일 UX에 결정적이었다.

라이브 메시지의 마무리 핑(5편). 길어진 작업의 마무리에 별도 ✅ 메시지 한 줄을 더 보내는 작은 디테일이, 화면을 안 보고 있는 시간을 회수해줬다. 폰이 진동 한 번 울려주는 것만으로 멀티태스킹이 된다.

다시 만든다면

MCP 서버 spawn 시 env 명시를 처음부터 박았을 거다. 이번 시리즈를 쓰면서 실제로 발생한 사건이기도 한데, blog MCP가 부모 환경의 일부만 상속해 BLOG_API_URL 같은 커스텀 변수를 못 받아서 한참 헤맸다. config.py의 stdio entry에 env={"BLOG_API_URL": os.environ.get("BLOG_API_URL", "")}를 명시했더라면 디버깅 시간 30분이 사라졌다.

Dashboard를 더 일찍 만들었을 거다. 처음엔 "필요할까?" 의심하다 6일차에 추가했는데, 봇 디버깅의 거의 모든 케이스에서 가장 먼저 보는 게 dashboard의 SSE 스트림이었다. 1일차에 만들었으면 2~5일차의 trial-and-error가 절반이었을 거다.

MarkdownV2 escape를 처음부터 라이브러리로 분리. 처음엔 inline string replace로 시작했다가, 코드블록 vs 일반 텍스트 분기, 중첩 백틱, escape 누락 같은 잔버그를 다섯 번쯤 패치한 뒤에야 별도 모듈로 쪼갰다. 분리부터 시작했더라면 한 번에 끝났다.

의외의 발견

음성 입력이 생각보다 자주 쓰인다. 처음엔 "OPENAI_API_KEY 비용 절감용 토글" 정도로 만들었는데, 운전 중에 한 줄 묻거나 양손이 막혀 있을 때 음성 → Whisper → Claude 흐름이 너무 매끄럽다. 데스크톱에서도 가끔 키보드 대신 마이크를 쓴다.

대화 톤이 데스크톱 Claude Code와 다르다. 모바일에서는 자연스럽게 짧게 묻고, hub가 짧게 답하고, specialist가 무거운 일을 하는 흐름이 자리 잡았다. 데스크톱에서 "할 일 목록을 종합해서 분석해줘" 같은 longform 요청을 했다면, 같은 봇 토픽에서는 "오늘 daily-feed 마지막 커밋?"처럼 한 줄짜리가 늘어났다.