이 기사의 실시 기록 (2026년 8월 3일): GTD의 트리아지 (Triage) 전담으로 만든 'secretary'라는 에이전트가, 3개월 이상 거의 움직이지 않은 채 잠들어 있었다. 그것이 하루 세션 내에서 3회 연속으로 기동하여, Inbox 분류 3건, 태스크 리스트 (NEXT)의 37건 → 26건, 다시 26건 → 19건으로의 정리를 수행했다. 처리 시간은 291초·155초·443초 (실측치. 에이전트 실행 로그의 duration_ms로 확인). 이 기사에서 쓰고 싶은 것은 "AI 에이전트가 우수했던 이야기"가 아니다. 판단이 일관되었던 이유는, GTD의 운용 규칙을 명문화한 문서와, 그것을 실제로 태스크에 적용·실행하는 시스템이라는 두 가지 부품의 조합이었다——라는 이야기다.

태스크 관리 리스트가 어느샌가 100건을 넘어가 버렸던 경험은 없는가? 나에게도 있다. Notion, Todoist, Obsidian 중 무엇을 사용하고 있더라도, 한동안 방치하면 "나중에 볼 것"의 산이 쌓인다. 이번에 쓰는 내용은, 그 산을 허무는 작업을 3개월 만에 움직인 AI 에이전트에게 맡겼더니, 허탈할 정도로 간단히 해결되었다는 이야기다.

"실질적으로 나는 아무것도 하지 않았다"의 의미 — 판단을 그만둔 것이 아니다

먼저 밝혀두고 싶다. 이 제목은 나 자신의 발언을 그대로 사용한 것이지만, "내가 아무런 판단도 하지 않았다"는 의미는 아니다.

계기는 GitHub Issue 리스트를 본 나의 "NEXT가 많네"라는 한마디였다. 이것이 없었다면 정리는 시작되지 않았을 것이다. 다음에 나는 "COO가 혹은 Secretary가 하는 개별 에이전트의 역할이라기보다, Claude Code의 시스템에 GTD 메커니즘을 결합했기에 가능한 것이라고 주장하고 싶다"라고 방향을 지정했고, 나아가 "규칙뿐만 아니라 /todo 스킬도 결합된 시스템으로 이해하고 있지만"이라며 한 단계 더 들어간 정정을 넣었다. 이 기사의 골자——판단 기준을 적은 문서와 그것을 실행하는 도구의 조합이 효과를 발휘하고 있다——는, 이 3번의 궤도 수정(Course Correction)을 나 자신이 직접 넣음으로써 굳어졌다.

즉 나는 무엇을 분류할지, 어떤 관점으로 파악할지라는 판단 기준을 그때마다 제시하고 있었다. AI 에이전트가 한 것은 그 기준을 Issue 하나하나에 기계적으로 적용하는 작업이다. "실질적으로 나는 아무것도 하지 않았다"라는 감상은, 그 적용 작업(하나씩 읽고, 판단하고, 라벨을 바꾸는 작업)으로부터 해방된 것에 대한 놀라움이지, 방향 설정을 그만둔 것이 아니다.

3개월간 멈춰 있었음에도 판단 기준이 흔들리지 않았다

secretary는 GTD의 Inbox 분류나 someday → next 승격 판단을 전담하는 에이전트로 만들었다. 2026년 6월 11일의 조직 건전성 점검에서 역할을 "판단을 동반하는 GTD 트리아지 전담"으로 축소하고, "그 후에도 발화(Trigger)가 제로라면 퇴역을 검토하겠다"라고 약속했다. 실제로 그때부터 최근까지 작업 파일은 거의 업데이트되지 않은 채 멈춰 있었다. 나의 첫마디는 "정말 오랜만에 Secretary를 기동했네"였다.

주목해야 할 점은 오랜만에 움직였다는 사실보다, 3개월 이상 움직이지 않았음에도 움직이는 순간 과거와 동일한 판단 기준이 일관되게 적용되었다는 것이다. 에이전트의 "감"이나 "숙련도"가 판단을 뒷받침했다면, 이 정도 간격이 벌어졌을 때 기준이 흔들려도 이상하지 않다. 흔들리지 않았던 이유는 판단 기준이 에이전트의 기억이 아니라, ops/playbooks/gtd/ 하위의 Markdown 문서(이하 "Playbook". 정식 기술 용어는 아니며, 우리가 "운용 규칙을 정리한 절차서"를 지칭하기 위해 사용하는 명칭이다)에 저장되어 있었기 때문이다.

/todo 스킬의 2층 구조

작동하고 있었던 것은 Playbook이며, "그것은 이 프로젝트 고유의 이야기라 자신의 환경에서는 재현할 수 없는 것 아닌가"라고 생각하는 사람도 있을 것이다. 결론부터 말하자면, 재현에 필요한 것은 고성능 전용 에이전트가 아니라 다음의 두 가지다.

• 판단 기준의 층 (Playbook): "각 프로젝트에는 반드시 하나의 Next Action이 연결되어 있어야 한다", "'~에 대해 생각하기'는 Next Action으로서 부적격하다"와 같은 GTD 원칙을 미리 문서로 작성해 둔 것
• 실행의 층 (Skill): 판단 결과를 실제 태스크(이번에는 GitHub Issue)에 반영하는 기능. 라벨의 일괄 변경, 기일에 따른 자동 승격 설정, 프로젝트 연결 등을 수행한다. 내가 공개하고 있는 오픈 소스 스킬 /todo 스킬인 claude-todo-gtd (실체는 쉘 스크립트 todo.sh와 그 배후에서 작동하는 처리계)가 이에 해당한다.

여기서 말하는 GTD 원칙의 출처는 데이비드 알렌(David Allen) 저서 『신장판 처음 시작하는 GTD 스트레스 프리 정리술』이다. Playbook에 작성한 판단 기준은 이 책에 있는 사고방식을 에이전트 운용에 맞게 내가 말을 바꾼 것에 불과하다.

Playbook만 있다고 해서 태스크가 움직이지는 않는다. /todo 스킬만 있다고 해서 판단 기준이 없다면 일관성은 생기지 않는다. 두 가지가 모두 갖춰져 있었기에, secretary가 3개월 만에 다시 작동하더라도, 혹은 다른 에이전트가 담당하더라도 동일한 판단과 동일한 처리에 도달할 수 있었다.

secretary가 실제로 한 일 — 판단의 '형태' 3가지

3번의 실행 동안 secretary는 Inbox 분류 3건, NEXT 정리 37건→26건, 다시 26건→19건을 수행했다. 모든 건을 나열하지는 않겠지만, Playbook의 규칙이 어떻게 호출되었는지 대표적인 판단 형태 3가지를 보여준다.

태스크의 구체화 (Inbox 분류): 추상적인 제목으로 남아 있던 개선 제안 Issue 2건을, "어느 파일의 몇 번째 줄에 무엇을 추가할지"가 한눈에 알 수 있는 형태로 제목과 본문을 다시 작성했다. 작동한 것은 "태스크는 실행 가능한 단위까지 구체화한다"라는 GTD의 명확화 원칙이며, 이는 Playbook에 명문화되어 있다. 이 2건은 나중에 내가 해당 부분을 수정하여 커밋(commit)까지 완료했다.

순차형과 병렬형의 판별, 순서 의존성 발견 (NEXT 1차): 선행 단계가 끝나지 않으면 다음으로 넘어갈 수 없는 순차형(sequential) 프로젝트는, 맨 앞의 미착수 태스크만 next에 남기고 나머지는 someday로 보냈다. 병행해서 진행할 수 있는 프로젝트는 "기존의 결함 대응을 남기고, 신규 기능 확장을 뒤로 미룬다"는 식으로 압축했다. 어떤 프로젝트에서는 "문서가 정리되지 않으면 외부 공개를 할 수 없다"라는 숨겨진 순서 의존성을 파악하여, 외부 공개 태스크만 someday로 옮겼다. 여기서 효과를 본 "각 프로젝트에는 반드시 하나의 Next Action이 연결되어 있어야 한다"라는 원칙도 내가 이번에 가르친 것이 아니라, 이전부터 Playbook에 적혀 있던 것이다.

기한 태스크의 설계 전환, 그리고 삭제 전 되묻기 (NEXT 2차): "특정 미래일이 되지 않으면 착수할 수 없는" 태스크는, 기한이 다가오면 자동으로 next로 떠오르게 하는 설정으로 전환하여 someday에 저장하는 운용 방식으로 바꾸었다 (기한이 며칠 앞으로 다가온 것은 next에 그대로 유지). 반면, 기한이 과거인 채로 방치되어 있던 태스크는 기계적으로 삭제하지 않고, "아직 필요한 태스크인가?"라며 나에게 확인을 요청했다. 대량의 일괄 쓰기를 동반하는 태스크를 someday로 보낼 때는, "착수 시 사전 승인이 필요한 규칙에 해당함"이라고 스스로 주석을 달기도 했다.

어떠한 판단 기준도 이번 세션을 위해 새로 만들어진 것이 아니다. secretary가 한 일은 "적혀 있는 규칙을 개별 케이스에 하나씩 적용하여 판정하는" 작업이었으며, 판정 결과를 Issue에 반영한 것은 /todo 스킬 측의 기능이다.

처리 시간 291초·155초·443초 — 병목 구간은 모델이 아니라 설계였다

작업을 지켜보며 나는 "secretary가 haiku로 돌아가고 있었나?"라고 중얼거렸다. 이는 착각이었으며, 정확히는 secretary는 model: sonnet으로 고정되어 있다 (.claude/agents/secretary.md에서 확인 완료). 처리 시간이 걸리는 것을 보고 "판단에 시간이 꽤 걸리네. opus가 더 좋았으려나"라고 흘리기도 했다. 처리 시간은 다음과 같다 (실측치. Agent 실행 로그의 duration_ms를 COO가 확인, 2026-08-03).

1회차 Inbox 분류는 분류와 제목 재작성까지 포함하는 무거운 판단이었기에 대상이 3건임에도 291초가 걸렸지만, 2회차는 4개 프로젝트 10건으로 압축된 심플한 판단이었기에 최단 시간인 155초 만에 끝났다. 즉, 건수의 많고 적음 자체가 아니라 판단의 질과 대상의 압축 방식이 시간을 좌우하고 있다.

"opus가 더 좋았으려나"에 대한 답은 이 표에서 나온다. 시간의 차이를 만든 것은 모델의 지능이 아니라, 대상 건수와 작업의 성질(일괄 판단으로 끝나는가, 아니면 1건씩 개별 정밀 조사가 필요한가)이다. 병목(bottleneck)은 "1건마다 정보 취득 → 판단 → 실행의 루프를 돌리는" 설계 그 자체에 있었다.

「플레이북(Playbook)을 쓰는 것뿐이라면 인간도 할 수 있는 것 아닌가」에 대한 답변

이 수치는 또 다른 의문——「플레이북에 규칙을 쓰는 것뿐이라면 인간도 할 수 있는 것 아닌가」——에 대한 답이기도 하다. 그 지적은 절반은 맞다. 규칙을 쓰는 것은 인간의 일이며, AI가 발명한 것이 아니다. 하지만 37건·26건의 태스크 각각에 대해 "순차형인가 병렬형인가", "순서 의존성은 어디에 숨어 있는가"를 판별하고, 실행까지 일관되게 해내는 작업은 별개의 문제다. 19건 상당의 재검토에 443초·도구 호출(tool call) 24회를 소요했다는 실측치는, "규칙을 알고 있는 것"과 "개별 케이스에 적용하여 실행하는 것"이 서로 다른 작업량임을 보여준다. 인간이 절차서를 손에 들고 직접 한다면 그에 상응하는 시간이 걸릴 것이다.

그렇기에 개선의 여지도 설계 측면에 있다. 내가 지적한 것은 판단을 일괄적으로 수행한 뒤 /todo 스킬의 처리를 한꺼번에 흘려보내는 방향이다. 대상 Issue 전건의 정보를 사전에 모아서 취득하고, 판단은 LLM이 한 번에 수행하며, 실행은 일괄 조작으로 그룹별로 흘려보낸다——다만, 아직 구현하여 재측정해 본 것은 아니기에, 이는 "효과가 있을 법한 개선안"이지 "효과를 본 실적"은 아니다. 이 점은 솔직하게 유보해 둔다.

그리고 세 번째 위임(delegation)을 던진 직후, 나는 이렇게 말했다.

"좋네, 실질적으로 나는 아무것도 하지 않는데 태스크가 정리되어 가고 있어."

Todoist로 충분하지 않나? GUI가 없으면 불가능한 것 아닌가?

"굳이 GitHub Issue에서 할 의미가 있나? Todoist로 충분하지 않나"라는 의문은 절반은 맞다. "운영 규칙을 명문화해 둔다"는 사고방식 자체는 도구를 가리지 않는다. Todoist, Notion, Obsidian에서도 "각 프로젝트에는 반드시 하나의 '다음에 할 일(next action)'을 연결한다"와 같은 판단 기준을 자신의 언어로 문서화해 둔다면, 같은 발상을 활용할 수 있다. 다만 "작성한 규칙을 37건·26건이라는 규모의 태스크에 일괄 적용하고, 라벨 변경 및 기한 설정까지 실행하는" 부분에는 그것을 실행할 수 있는 메커니즘(API 연동·자동화 등)이 별도로 필요하다. 이번에 그 역할을 담당한 것이 /todo 스킬이다.

"커맨드 라인(CLI)을 사용할 수 없으면 불가능한 것 아닌가"라는 의문에도 솔직히 답하자면, 이번 실행 부분은 Claude Code라는 커맨드 라인 경유의 AI 에이전트를 전제로 하기에, 이 구성을 GUI만으로 그대로 재현하는 것은 어렵다. 하지만 이 글의 본질은 "운영 규칙을 그 자리의 판단이나 기억에 의존하지 않고, 미리 문서로서 써 놓으면 담당자가 바뀌어도, 혹은 오랜만에 다시 실행해도 동일한 판단에 도달한다"라는 사고방식에 있다. 이 부분만 따로 떼어낸다면, Notion의 가이드라인 페이지에 태스크 등록 규칙을 명문화하거나, Todoist의 프로젝트 메모에 판단 기준을 적어두는 방식으로 GUI 도구에서도 응용할 수 있다. 2층 구조 중 "규칙의 명문화"는 도구를 가리지 않으며, "대량 실행의 수단"만이 환경에 의존한다.

아직 해결되지 않은 것들

성공한 이야기만 늘어놓는 것은 솔직하지 않기에, 구조적으로 해결되지 않은 과제도 적어 둔다.

"기한이 다가오면 자동으로 next로 부상시킨다"는 메커니즘은 어디까지나 설정을 전환했을 뿐이며, 그 설정을 정기적으로 체크하여 실제로 부상시키는 자동 실행(스케줄러 등록)은 이 글을 쓰는 시점에서는 아직 수행하지 않았다. 즉, 누군가(나 혹은 에이전트)가 정기적으로 체크하지 않는 한, 자동 승격은 실제로 발화하지 않는다. secretary 스스로도 이 점을 주석으로 달아두었다. "규칙을 쓰고 설정을 전환하는 것"과 "그 설정을 지속적으로 움직이는 메커니즘을 갖추는 것"은 아직 별개의 작업으로 남아 있다. 다음에 이 부분을 시스템화할 수 있다면 다시 글로 쓰고 싶다.

또 하나, "AI에게 맡겨서 정말 누락되지 않을까? 내 눈으로 확인하지 않으면 불안하다"라는 의구심에는, 앞서 언급한 "기한이 지난 태스크를 삭제하지 않고 나에게 되돌려준" 사례가 답이 된다. 삭제와 같이 되돌릴 수 없는 조작 직전에는 사용자에게 확인을 요청하도록 설계되어 있다.

이번에 말하고 싶었던 것

나는 지금까지도 "Claude Code + GTD"라는 테마로 글을 써왔지만, 이번에 새롭게 쓸 수 있었던 것은, 3개월 이상 사용하지 않았던 에이전트가 재가동되는 순간 과거와 동일한 판단 기준을 적용했다는 사실을 처리 시간·도구 호출 횟수라는 정량적 데이터와 함께 보여줄 수 있었다는 점이다. 이는 "에이전트의 기억이나 숙련도"가 아니라 "Playbook라는 외부화된 문서"가 판단의 일관성을 담보하고 있다는 주장의 가장 강력한 증거가 된다.

태스크 관리를 일관된 판단으로 돌리고 있었던 것은, 우수한 AI 에이전트가 아니라, 「운영 규칙을 명문화한 문서」와 「그 규칙을 태스크에 적용·실행하는 툴」의 조합이라는 메커니즘 그 자체였다. 이 두 가지만 갖춰져 있다면, 담당자가 누구(인간인지, 어떤 AI인지)든 동일한 수준의 판단에 도달한다. 「툴에 구애받지 않고 사용할 수 있는 부분(규칙의 명문화)」과 「실행 기반이 필요해지는 부분(대량 실행의 수단)」을 나누어 가져갈 수 있다면, 이 글의 목적은 달성된 셈이다.

/todo

스킬의 실행 부분을 하나씩 움직이는 것이 아니라, 판단과 실행을 각각 일괄화한다——이번 깨달음을 구현하여 재측정하면, 다음 질문이 떠오른다. 판단을 일괄화한 끝에, 인간이 해야 할 일은 어디까지 줄일 수 있는가. 내가 그 지점에 도달하기까지의 기록은, Zenn Books의 「코드를 작성할 수 없는 내가 Claude Code로 「AI 팀」을 운영하기까지」에 정리해 두었다 (서장 무료).

관련 기사

• Claude Code로 GTD를 조직의 프로토콜로 만든 이야기
• 태스크 관리 툴을 3번 교체한 끝에 설계한——Claude Code × GTD로 「대화 제로」의 배치형 (Batch) 워크플로우
• 이번에야말로! Claude Code로 GTD를 돌린다——/todo 완전 가이드
• 인터럽트(Interrupt)로 인해 머리가 리셋되는 문제를 Claude Code로 해결한 이야기

이 글은 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.

Discussion