Todoist 자동화는 정리부터 만들었다

Todoist를 Claude Code에 MCP로 붙여 triage부터 계획·실행까지 자동화한 순서

1편(내가 Todoist를 고른 이유)에서, Todoist가 API/MCP라는 구멍을 열어둔 게 결정적이었다고 했다. 이번 편은 그 구멍에 스킬을 붙여 자동화한 이야기다. 단, 지금 쓰는 순서(던지기→정리→계획→실행)대로 만든 게 아니다. 나는 정리부터 만들었다.

먼저, 할일을 데이터로 만들기

스킬을 붙이려면 할일을 코드로 읽고 쓸 수 있어야 했다. 그래서 Todoist를 Claude Code(CLI 에이전트)에 MCP로 연결했다.

매끄럽진 않았다. 처음엔 OAuth 방식 서버(ai.todoist.net/mcp)로 등록했는데 계속 “Needs authentication” 상태였다. claude mcp auth todoist 를 쳤더니 unknown command 'auth'. 그 명령은 없었다. 해결은 단순했다. 헤더에 개인 토큰을 직접 넣어서 재등록.

claude mcp remove todoist 2>/dev/null || true
claude mcp add todoist -t http https://mcp.todoist.com/mcp \
  -H "Authorization: Bearer <개인_API_토큰>"

Connected 뜨고 세션 재시작하니 도구가 잡혔다. 이제부터가 진짜다.

제일 급한 건 정리였다 (그래서 triage부터)

내 인박스엔 막 던져둔 아이디어가 쌓여 있었다. 보통 출퇴근 전철에서 떠오르는 대로 던지니까, 집에 오면 정리 안 된 더미가 그대로 기다린다. 던지는 건 Todoist가 이미 잘 받아주니까(1편), 내게 진짜 아쉬운 건 그 다음이었다. 쌓인 걸 한 번에 정리하는 것. 그래서 제일 먼저 만든 게 분류 스킬(/triage)이다.

분류라고 하면 단순해 보이는데, 핵심은 기준을 한 군데에 모은 것이었다. “이 폴더(프로젝트)는 Todoist의 이 섹션” 같은 매핑 표 하나를 단일 출처(SSOT)로 두고, 막연한 건 구체화하고 날짜까지 붙이게 했다. 던져진 더미가 프로젝트별로 착착 갈라지는 걸 보니 그제서야 인박스가 인박스 같았다.

정리되니 계획이, 계획되니 실행이

정리된 할일은 그냥 목록이 아니라 다룰 수 있는 데이터가 됐다. 그러니 다음이 자연스럽게 따라왔다.

정리된 걸 의존관계 있는 실행 계획으로 묶는 스킬(/plan-todo), 그 계획을 무인으로 돌리는 실행(/goal). 정리 → 계획 → 실행으로 이어지는 사이클이 생겼다. 여기까지는 “쌓인 걸 어떻게든 굴러가게 만들자”는 한 방향이었다.

마지막 조각은 ‘던지기’였다

사이클을 돌리다 보니 빈 곳이 보였다. 입구다. 떠오른 걸 폰으로 인박스에 던지는 길은 1편 때부터 있었지만, 그건 나중에 triage를 거쳐야 했다. 정작 책상에서 작업하다 떠오른 건, 그 자리에서 바로 사이클에 태우는 길이 없었다.

계기는 구체적이었다. 바로 이 ‘Todoist 블로그’를 쓰려던 참이었는데, 작업하던 자리에서 이걸 triage 단계를 거치지 않고 곧장 넣어서 바로 계획(build)을 돌리고 싶었다. 그래서 던지기 스킬(/todo)을 만들었다. 넣는 순간 작업 중인 폴더 맥락으로 분류·내용까지 채워서, triage를 안 거쳐도 바로 계획에 태울 수 있게.

그러니까 /todo는 사이클의 시작점인데, 만든 건 제일 마지막이었다. 정리가 급해서 시작했고, 사이클을 굴리다 입구가 필요해져서 마지막에 뚫은 셈이다. (블로그라 시리즈로 묶고 발행하는 곁가지도 붙었지만, 그건 본 줄기는 아니다.)

쓰는 순서와 만든 순서는 반대였다

지금 쓸 때는 던지기 → 정리 → 계획 → 실행, 한 줄로 흐른다. 그런데 만든 순서는 정리 → 계획 → 실행 → 던지기였다. 제일 급한 정리부터 손대고, 사이클을 굴리면서 비는 칸을 하나씩 채운 결과다.

실제로 한 프로젝트에서 돌려보니 후련했다. 머릿속에 “이거 언제 다 하지” 하고 쌓여 있던 게 계획서 한 장으로 정리되니 체감이 컸다.

집에 오면 이렇게 돌린다

던지는 길은 둘이다. 이동하거나 딴생각하다 아이디어가 떠오르면 폰에서 Todoist 앱으로 인박스에 그냥 던진다(1편 때부터 하던 거고 /todo와는 상관없다). /todo는 책상에 앉아 작업할 때 쓴다. 그 프로젝트 폴더에서 떠오른 걸 맥락까지 붙여 넣어두면 triage를 건너뛰고 바로 계획에 올라간다.

처리는 집에 와서 한 번에 한다.

/triage: 낮 동안 폰으로 던져둔 인박스 더미를 한 번에 정리한다.
프로젝트 폴더로 들어가 /plan-todo: 그 프로젝트 할일이 plan-todo.md 계획서로 묶인다.
/goal plan-todo.md: 그 계획서를 무인으로 돌린다.

폰으로 던진 건 인박스에, 작업 중 /todo로 넣은 건 이미 프로젝트에 분류돼 있다. 집에 오면 정리·계획·실행 한 바퀴가 끝이다. 돌려놓고 나는 결과만 본다.

왜 스킬부터 만들고, 쓰면서 깎았나

이 순서 밑에는 내 작업 방식이 깔려 있다. 기능을 한 번에 완성하려 하지 않고, 일단 스킬로 만들어 등록해놓고 쓰면서 깎는다. 이유는 세 가지다.

반복을 묶는다. 자주 하는 일을 스킬로 묶어두면 매번 똑같이 지시할 필요가 없다. 한 번 만들면 그 다음부턴 한 단어로 부른다.
행동을 고정한다. 한 번 정한 방식을 다음에도 그대로 하게 박아두는 거라, 그때그때 달라지거나 빠뜨리는 실수가 준다.
써봐야 부족한 게 보인다. 머리로 완벽하게 설계해도 실제로 굴려보기 전엔 뭐가 거슬리는지 모른다. 그래서 완성형을 그리는 대신 일단 돌려놓고, 거슬리는 걸 그 자리에서 깎는다.

triage를 먼저 만든 것도, 던지기를 마지막에 뚫은 것도 다 이 방식의 결과다. 제일 급한 조각부터 만들어 굴리고, 굴리다 비는 칸이 보이면 그때 채웠다.

정리

한 방에 다 설계하고 시작했으면 아마 못 끝냈을 거다. 예전엔 그러다 흐지부지된 적이 많았다. 이번엔 제일 급한 정리부터 만들어 굴렸고, 사이클이 돌기 시작하니 다음에 뭐가 필요한지가 저절로 드러났다.

물론 완벽하진 않다. plan-todo가 묶은 계획이 늘 깔끔한 건 아니고, 결과를 보고 다시 손대는 날도 있다. 그리고 무인으로 돌리는 만큼 토큰을 꽤 태운다. 사람이 직접 처리하는 것보다 비용은 분명히 더 든다. 그래도 머릿속에서 굴러다니던 걸 계획서 한 장으로 떨궈놓고 돌려버리는 후련함이, 적어도 나한텐 그 값을 했다.

자동화는 큰 설계에서 출발할 필요가 없다. 제일 아쉬운 것 하나부터 스킬로 만들어 굴려보면, 그 다음 조각은 알아서 보인다.