Claude Code를 통해 GTD를 조직의 프로토콜로 만든 이야기

이 기사의 실시 기록 (2026년 5월): Claude Code로 AI 에이전트 복수체를 운용하는 과정에서, GitHub Issues의 @claude 라벨을 사용한 위임 프로토콜을 설계 및 운용 중. 2026-05-29 시점에 누적 38건의 위임 실적 있음. GTD의 「Inbox/Next/Waiting」 분류가 그대로 AI 위임 인터페이스로서 기능한다는 것을 발견한 기록.

AI와의 상호작용이 늘어나던 어느 날, 나는 Claude의 메모리를 정리하려다 예상치 못한 발견을 했다.

메모리의 개수는 처음에는 58건이었다. 주간 리뷰(Weekly Review)를 할 때마다 비워내어 52건이 되었고, 더 정리하여 지금은 35건(2026-05-29 실측)으로 안정되어 있다. 정리하면서 깨달았다. 불필요한 「언젠가 확인하자」가 대량으로 쌓여 있었다. 「나중에 쓸지도 모르는 설정값」, 「어쩌면 필요해질 운영 메모」. 인간의 머릿속과 완전히 똑같은 상태가 되어 있었다.

이것은 GTD가 말하는 「오픈 루프 (Open Loop)」다, 라고 생각한 순간 시야가 확 트였다.

메모리를 정리하다 보니 GTD가 보였다

GTD를 아는 사람에게는 「그대로잖아」라는 말을 들을지도 모르겠지만, 나는 실제로 정리 작업을 손으로 움직여 보기 전까지 AI의 메모리와 GTD가 동일한 형태의 문제를 가지고 있다는 것을 의식하지 못했다.

GTD의 근본적인 통찰은 「머릿속에 미결 사항을 두지 않는 것」이다. 하려고 생각하는 것, 신경 쓰이는 것, 언젠가 확인하려고 생각하는 것——이것들을 머리 밖으로 꺼내 신뢰할 수 있는 시스템에 맡김으로써, 머리는 「지금 여기에 있는 일」에 집중할 수 있다.

AI의 메모리도 마찬가지였다. 메모리에 「언젠가 한다」가 쌓이면, 매 세션마다 불필요한 정보를 끌고 오게 된다. 처리되지 않은 채 남은 메모리는 GTD의 용어로 말하자면 오픈 루프다.

정리한 메모리의 내용을 보면 3가지 패턴으로 분류할 수 있었다. 나는 GitHub Issues를 GTD의 todo 시스템으로 사용하고 있으며(자세한 내용은 후술), 태스크는 그곳에 전기(transcribe)하고 있다:

• 정말로 필요한 운영 메모 → 남김
• todo로 옮길 수 있는 태스크 → Issue에 전기하여 메모리에서 삭제
• 이미 해결된 판단 메모 → 삭제

이 3가지 분류가 그대로 GTD의 「수집(Collection) → 처리(Processing) → 정리(Organizing)」와 대응하고 있었다.

AI의 메모리와 GTD는 구조가 같았다

「GTD는 어렵지 않아?」라고 느끼는 사람도 많을 것이다. GTD에는 독특한 용어 체계가 있어 전체상을 이해하려고 하면 책 한 권 분량의 개념이 나온다. 다만, 이 기사에서 사용하는 GTD는 훨씬 심플하다. 「Inbox / Next / Waiting / Someday」라는 4가지 분류만 알고 있으면 충분하며, 도구는 GitHub Issues와 라벨만으로 충분하다.

AI 메모리와 GTD의 대응 관계를 정리하면 다음과 같다:

AI 메모리의 상태	GTD의 개념	대처
「언젠가 확인하자」의 퇴적	Inbox (미처리 수집)	주간 리뷰로 분류
...

「주간 리뷰로 메모리를 비워내는 것」은 이제 매주의 습관이 되었다. 리뷰 과정에서 GitHub Issue에 전기할 수 있는 것은 Issue로, 판단이 끝난 것은 삭제한다. 메모리에는 「Claude Code가 매 세션에서 참조하는 운영상의 사실」만을 남긴다.

이 메커니즘의 최대 효과는 「메모리에 두지 않아도 되는 정보를 Issue에 맡김으로써, Claude가 세션 시작 시 불필요한 정보를 끌고 오지 않게 되었다」는 점이다.

GitHub Issue도 같은 해답으로 수렴하고 있었다

AI의 메모리 관리에서 GTD의 구조를 발견했을 때, 문득 깨달았다. 내가 GitHub Issue로 태스크 관리를 하는 방식도 같은 구조가 아닌가.

• Issue = 수집 (Inbox). 신경 쓰이는 것은 전부 Issue로 던진다
• next 라벨 = 다음에 할 일 (Next Action)
• waiting 라벨 = 외부 대기 (Waiting)
• someday 라벨 = 언젠가 함 (Someday)
• Milestone = 프로젝트

나도 모르는 사이에 GitHub의 라벨 시스템으로 GTD를 재발명하고 있었던 것이다.

「인간도 AI도 도구도, 오픈 루프라는 동일한 문제를 해결하려고 하면 GTD와 유사한 구조로 수렴한다」는 가설이 머릿속에 떠올랐다. 그리고 다음 질문이 생겨났다: AI의 태스크는 어디에 둘 것인가?

인간의 태스크는 GitHub Issue로 관리하고 있다. 그렇다면 AI에게 위임한 태스크도 같은 시스템으로 관리할 수 있지 않을까.

@claude

레이블이란 무엇인가——GitHub Issue에서 AI에게 위임하는 시스템

GitHub의 @claude

레이블은 제가 Claude Code 운영을 위해 만든 커스텀 레이블입니다 (공식 기능이 아니라, 제가 개인적으로 명명한 독자적인 운용 방식). 일반 태스크와 구별하기 위한 레이블일 뿐이며, '이 Issue는 Claude가 담당한다'라는 의미를 담고 있습니다.

시스템은 간단합니다. 인간 담당 태스크에는 @me (또는 단순히 담당자가 없음), Claude 담당 태스크에는 @claude 레이블을 붙입니다. GTD 레이블(next/waiting/someday)과 조합함으로써, 'Claude가 다음에 할 일', 'Claude가 외부를 기다리는 것'이 한눈에 파악되는 상태를 만듭니다. 후술할 /todo 커맨드를 사용하면 커맨드라인에서 Issue 조작을 한 번에 할 수 있지만, 레이블만 수동으로 붙여도 위임은 성립합니다.

@claude

레이블로 인간과 AI가 같은 시스템에 존재하게 하다

'실제로 쓸 수 있나?'라는 의문은 당연합니다. 그래서 구체적인 운영 사례 3가지를 소개하겠습니다. 모두 2026-05-29 시점 기준으로 실제로 사용하고 있는 시스템입니다 (누적 38건, 오픈 2건).

GitHub Issue에 @claude 레이블을 만들고, Claude가 담당하는 태스크에 붙입니다. 이것만으로도 AI와 인간이 같은 Issue 트래커 안에서 태스크를 주고받을 수 있게 됩니다.

예시 1: 스킬 버그 수정 위임 (Issue #1321)

제목: bug: /todo의 --label 옵션 지정이 제목에 혼입됨

레이블: next + @claude + p3

Issue 본문에는 '증상・재현 절차・수정 제안(A/B/C 안)・SSoT 파일 경로'를 작성합니다. 제가 Issue를 등록하고 @claude 레이블을 붙이면, 다음 Claude Code 세션에서 이 태스크가 포착됩니다. Claude는 skill-dev 에이전트를 통해 수정하고, 완료 후 Issue를 닫습니다.

핵심은 '무엇을 전달할지(재현 절차)', '어디를 고칠지(SSoT 파일 경로)', '어떤 안인지(제안 번호)'가 본문에 명문화되어 있는 것입니다. Claude가 판단 없이 움직일 수 있는 상태를 만드는 것이 중요합니다.

예시 2: 공개 대기 관리 (Issue #1374)

제목: 하테나 공개: claude-code-natural-consult-to-todo

레이블: waiting + @claude + #공개대기

스케줄 관리는 제가 합니다(공개 시각 지정), 실행은 Claude가 담당합니다(공개 스크립트 실행・결과 확인・Issue 닫기). waiting + @claude의 조합이 '타이밍을 기다리는 Claude 담당 태스크'를 한눈에 보여줍니다.

예시 3: 분석 → 판단 위임 (Issue #1351)

제목: GSC 관찰 기반 CTR 저조 기사 리라이트 판단 (writer 위임)

레이블: next + @claude + p2

제가 Google Search Console의 데이터와 URL을 Issue에 적어 등록합니다. Claude가 슬래그 특정 → 쿼리 확보 → writer에게 리라이트 판단 위임을 실행합니다. '분석한 결과를 어떻게 처리할지(별 태스크로 분리)'까지 본문에 적어두면, Claude가 망설임 없이 움직일 수 있습니다.

3가지 실례에 공통되는 패턴

요소	작성 방식
제목	'누가 무엇을 할지' 명기 ([skill-dev] 접두사, 하테나 공개: 접두사)
레이블	@claude + GTD 레이블 (next/waiting) 조합
본문	절차・SSoT・완료 조건이 작성되어 있음 (Claude가 판단 없이 움직일 수 있도록)

이 3가지 요소만 갖춰져 있다면, 제가 세션에서 Issue를 열고 Claude에게 '이 Issue 처리해줘'라고 말하는 것만으로 위임이 성립합니다.

내일부터 시도할 수 있는 최소 절차

'AI의 메모리라든지, 진입 장벽이 높을 것 같다'는 느낌은 이해합니다. 하지만 시작 방법은 놀랍도록 간단합니다. GitHub Issues와 레이블만 있으면 바로 GTD 위임 시스템이 작동합니다.

@claude

레이블 만들기

단계 1: GitHub 리포지토리의 Settings → Labels에서 @claude 레이블을 생성합니다.

• 색상: #FBCA04

（黄色, 눈에 띄는 색） - 설명:
Claude가 담당할 태스크

GTD 레이블도 함께 만들면 관리가 용이합니다:

next

（다음에 할 일） -
waiting

（외부 대기） -
someday

（언젠가 할 일）

이 레이블 체계와 /todo 슬래시 커맨드(slash command)는 claude-todo-gtd라는 이름으로 OSS(Open Source Software)로 공개하고 있다. Claude Code 설정에 통합하면 Issue 조작을 명령어 한 번으로 수행할 수 있게 된다. 설정 절차와 모든 기능의 사용법은 「이번에야말로! Claude Code로 GTD를 돌리는 /todo 완전 가이드」에 정리해 두었다.

단계 2: AI에게 위임할 내용을 Issue에 작성하기

위임하고 싶은 태스크를 Issue로 등록한다. 작성해야 할 내용:

제목: 「[누구에게][무엇을] 원하는가」 (예: [writer] GTD 기사의 H2-3를 작성하라)

본문: 절차 · 자료의 위치 · 완료 조건

레이블: @claude + next

요령은 "내가 한다면 무엇을 할 것인가"를 쓰는 것이다. Claude는 절차서를 읽고 움직일 수 있다. 판단까지 맡기고 싶다면 판단 기준을, 실행만 맡기고 싶다면 절차를 작성한다.

실제 Issue 본문은 이 정도 볼륨이면 충분하다:

## 할 일
- `/todo`의 `--label` 옵션 구현을 skill-dev에서 수정하기
## 재현 절차
...

"무엇을 · 어디서 · 어떻게 확인할 것인가"라는 3가지 요소가 있다면, Claude는 판단 없이도 움직일 수 있다.

단계 3: weekly review 시 「Claude의 담당 Issue」 확인하기

자신의 GTD weekly review 타이밍에 @claude 레이블이 붙은 Issue를 확인한다:

• 완료된 Issue를 close한다
• 정체된 Issue에 내용을 추가한다
• 새로 위임할 수 있는 사항을 Issue로 등록한다

이 사이클을 일주일 동안 돌리는 것만으로도, "AI와 내가 동일한 GTD 시스템 안에 있는" 상태가 된다. 기존의 GTD 습관에 레이블 하나를 추가하는 것만으로 시작할 수 있다. 주간 리뷰가 컨텍스트 스위칭(context switching) 후 복귀에 어떻게 기능하는지는 「중단으로 인해 머리가 리셋되는 문제를 Claude Code로 해소한 이야기」에서 자세히 다루고 있다.

덧붙여, AI의 메모리 관리(58건 → 35건으로 정리)는 별개의 이야기지만, "주간 리뷰에서 메모리를 확인하고 Issue로 옮길 수 있는 것은 옮긴다"라는 습관을 병행하면, 메모리와 Issue의 역할 분담이 자연스럽게 정립된다.

GTD는 인간의 인지 문제를 해결하기 위한 프레임워크였다

여기까지 작성하며 다시 한번 확인할 수 있는 것이 있다.

GTD가 "머릿속의 오픈 루프(open loop)를 밖으로 꺼낸다"라는 발명을 해낸 것은 인간의 뇌라는 특정 시스템을 향한 것이었다. 하지만 실제로 보면 AI의 메모리 관리에서도, GitHub의 Issue 트래커에서도, "오픈 루프를 가진 시스템은 모두 GTD가 유효하다"라는 구조가 나타난다.

인간의 뇌, AI의 메모리, 태스크 관리 도구 — 이들 모두 "처리되지 않은 정보가 쌓이면 시스템의 기능이 저하된다"라는 동일한 문제를 가지고 있다. GTD는 특정 도구나 기술을 위한 노하우가 아니라, 정보를 처리하는 시스템 전반에 적용할 수 있는 원칙이었던 것이다.

AI 팀을 갖게 되면서 나의 GTD는 개인의 생산성 도구에서 인간과 AI의 협업 프로토콜(protocol)로 변했다. @claude 레이블이 그 인터페이스가 되어주고 있다.

한 가지 솔직하게 적어두자면, 이 메커니즘은 아직 완성되지 않았다. @claude 레이블이 붙은 Issue를 Claude가 자율적으로 가져가 처리하는 사이클은 매주 GTD 리뷰 세션에서 수동으로 트리거하고 있다. "Claude가 스스로 자신의 Issue를 능동적으로 처리하기 시작하는" 자동화는 향후의 과제다.

당신의 AI Inbox에는 지금 몇 건의 메시지가 쌓여 있는가?

AI에게 무언가를 "나중에 부탁하자"라고 생각만 한 채, 어디에도 적어두지 않은 오픈 루프가 머릿속에 몇 개나 있는지 세어보길 바란다. 그것을 GitHub Issue에 적어내고 @claude 레이블을 붙이는 것만으로, 다음 세션부터 위임이 시작된다.

GTD가 다음에 해결할 것은 당신과 AI 사이에 쌓여가는 오픈 루프일지도 모른다.

함께 읽기

• 코드를 작성할 줄 모르는 내가 Claude Code로 「AI 팀」을 만들기까지 (Zenn Book Vol.1) — AI 팀을 제로에서부터 구축하는 과정
• 코드를 작성할 줄 모르는 내가 Claude Code로 「AI 팀」을 운영하기까지 (Zenn Book Vol.2) — 팀을 지속적으로 운용하는 과정
• 코드를 작성할 줄 모르는 내가 Claude Code를 통해 「AI 팀」과 계속 써 내려가기까지 (Zenn Book Vol.3) — 블로그 집필 스토리 (준비하기·쓰기·전달하기·회수하기)

Amazon 어소시에이트 링크: GTD의 원전은 데이비드 알렌(David Allen) 저 「스트레스 프리 업무 기술 ─ 일과 인생을 컨트롤하는 52가지 법칙」(영어 원저명은 "Getting Things Done")이다. 본 기사에서 언급한 「오픈 루프 (Open Loop)」, 「인박스 (Inbox)」, 「위클리 리뷰 (Weekly Review)」의 개념이 체계화되어 있다.

이 기사는 はてなブログ (Hatena Blog) 에서의 크로스 포스트입니다.

Discussion