도구가 도구를 운영한다

결론부터

이 글은 텔레그램 봇이 발행했다. 텔레그램 봇은 PC가 부팅할 때 자동으로 떠 있고, 메시지가 오면 데스크톱의 Claude Code를 호출해 글을 만든 뒤 my-blog의 MCP 서버를 통해 Supabase에 저장한다. 그 다음 my-blog가 자체 ISR 캐시를 무효화하고, 텔레그램은 ✅ 핑 메시지를 보낸다. 사람은 한 줄을 입력했고, 도구 다섯 개가 그 한 줄을 흐름으로 만들었다.

1인 운영의 도구들은 시간이 지날수록 서로의 운영자가 되어간다. 처음엔 각자 따로 만든 것 같은데, 어느 시점부터 한 도구가 다른 도구를 부르고 또 다른 도구를 부른다. 이 컬럼은 그 풍경에 대한 짧은 메모다.

도구가 도구를 부른다 — 이 시리즈의 한 사이클

지금 운영 중인 6개 프로젝트가 어떻게 엮여 있는지 한 사이클을 따라가 보자.

• 텔레그램 봇이 메시지를 받아 데스크톱 Claude Code를 호출
• Claude Code가 my-blog의 MCP 서버를 통해 글을 작성
• MCP 서버는 my-blog API를 호출해 Supabase에 저장 + ISR 무효화
• 같은 봇 토픽에 ✅ 알림이 떨어지고, 그 와중에 playground-ops의 audit 스크립트가 매일 새벽 모든 작업의 상태를 점검해 결과를 다른 토픽으로 보내고 있다
• idea-cycles는 매일 별도 토픽에서 새 데모를 발행하고, 그 발행 알림이 같은 텔레그램 그룹에 떨어진다

같은 봇, 같은 그룹, 다른 토픽. 같은 PC 위에 깔린 다른 자동화. 한 도구의 출력이 다른 도구의 입력으로 흐른다.

도구가 도구를 운영하는 것의 미학

이 구조의 매력은 각 도구가 자기 책임에만 충실하다는 점에 있다.

텔레그램 봇은 메시지 라우팅과 라이브 응답만 책임진다. 글이 어떻게 발행되는지는 모른다. my-blog의 MCP 서버는 글의 CRUD만 책임진다. 그 글을 누가 작성했는지는 모른다. 둘이 만나는 자리는 한 줄짜리 stdio 인터페이스다. 한쪽이 stdin으로 JSON을 보내고, 다른 쪽이 stdout으로 JSON을 답한다.

마이크로서비스의 작은 사촌이라고 부를 만하다. 각 프로젝트가 독립 git 저장소이고, 독립 디플로이 사이클이 있고, 다른 프로젝트의 내부 구현을 모른다. 인터페이스(MCP 도구·HTTP API·텔레그램 메시지)만이 둘 사이의 계약이다.

그러나 모든 게 재귀는 아니다

도구가 도구를 운영하는 풍경에는 한계가 있다.

기반 — PC가 켜져 있어야 한다. 텔레그램 봇은 Windows 시작프로그램에 등록돼 있어서 부팅 시 자동으로 뜬다. 그래도 PC가 꺼져 있으면 끝이다. "도구가 도구를 운영"하는 그래프는 어떤 외부 인프라(전력·네트워크·OS)에 늘 의존한다. 자기 자신을 부팅시키는 도구는 만들 수 없다.

판단 — 어떤 결정은 사람이 해야 한다. "이 컬럼을 발행할지" "이 톤이 적절한지" "이 글을 누가 읽을지"는 인터페이스로 위임할 수 없다. 도구는 사람이 정해놓은 규칙을 빠르고 안정적으로 실행하지만, 규칙 자체를 만드는 자리는 사람이 비워둘 수 없다.

한계 — 자동화의 비용도 누적된다. 도구가 늘어날수록 그 도구를 유지보수하는 비용도 누적된다. .env 변경, MCP 서버 재시작, 봇 권한 갱신, dependency 업그레이드 — 자동화는 시간을 절약하는 동시에, 새로운 종류의 부채를 만든다. 이 부채를 인식하지 못하면 어느 시점에 자동화가 사람을 운영하기 시작한다.

닫는 글

도구가 도구를 운영하는 풍경은 1인 개발자에게 매력적이다. 사람 한 명의 손이 닿을 수 있는 영역을 N배로 키워준다. 동시에, 도구의 그래프가 커질수록 그 그래프 자체를 부양하는 비용이 따라 커진다.

그래도 한 가지는 분명하다 — 이 글이 발행되는 흐름을 처음부터 끝까지 한 사람이 만들었고, 그 흐름이 매일 침묵 없이 동작한다. 그게 도구가 도구를 운영한다는 풍경의 가장 단순한 정의다. 발행 버튼을 누른 적이 없는데 글이 발행된다.