플러그인이 해주는 일

tuckit은 웹 페이지로만 써도 됩니다. 다만 쓰시는 AI에 플러그인을 하나 깔면, 보드를 사람이 혼자 채우지 않아도 됩니다.

플러그인이 넣어주는 건 세 가지입니다.

• 세션이 시작될 때 에이전트에게 붙는 짧은 안내
• 세션이 끝나기 전에 한 번 뜨는 알림
• 이름이 붙은 작업 방식 한 묶음

앞의 두 개는 항상 켜져 있습니다. 세 번째는 관련 있을 때만 불려 나옵니다.

Claude Code, Codex CLI, Antigravity CLI 셋 다 똑같은 묶음을 받습니다. 어느 걸 쓰시든 이 페이지의 내용은 같습니다.

처음 시작하기

이미 몇 달째 만들고 있는 게 있는 분을 기준으로 씁니다. 아무것도 없는 상태에서 새로 시작하는 경우라면 10분 따라하기가 더 짧습니다.

코드를 읽을 줄 몰라도 됩니다. 아래에서 사람이 하는 일은 명령어 몇 줄을 붙여넣고, 질문 서너 개에 답하고, 만들 목록을 한 번 승인하는 것뿐입니다.

1. tuckit 계정을 만듭니다

app.tuckit.dev에서 가입하면 조직이 하나 생깁니다. 보드가 비어 있어도 괜찮습니다. 채우는 건 3단계에서 AI가 합니다.

2. 쓰시는 AI에 플러그인을 깝니다

Claude Code라면 세션 안에서 두 줄입니다.

/plugin marketplace add tuck-it/tuckit-plugins

/plugin install tuckit@tuckit-plugins

처음 쓰는 순간 브라우저가 열리면서 허용할지 물어봅니다. 눌러주시면 끝이고, 어디서 긴 문자열을 복사해다 붙이는 과정은 없습니다.

Codex CLI와 Antigravity CLI는 명령어가 다릅니다. 에이전트 연결하기에 AI별로 정리해뒀습니다.

3. 프로젝트 폴더에서 이 한 줄을 칩니다

만들던 프로젝트 폴더에서 AI를 열고, 그대로 붙여넣으시면 됩니다.

tuckit 보드가 비어 있어. adopting-a-project으로 이 프로젝트를 보드에 올려줘.

adopting-a-project는 절차 이름입니다. 이름을 안 대도 대개 알아서 걸리지만, 첫날은 확실하게 이름을 대는 쪽이 낫습니다.

4. 질문 서너 개에 답합니다

AI가 먼저 코드를 훑습니다. 폴더 구조, 최근 2주 커밋, 지금 열려 있는 브랜치와 PR을 봅니다. 다 보고 나서 초안을 만들고, 그다음에 물어봅니다. 빈 종이를 내밀면서 “어떻게 정리할까요”라고 묻지 않는다는 뜻입니다.

물어보는 건 코드를 봐서는 알 수 없는 것들뿐입니다. 대개 “이건 누구 일인가”입니다.

“terraform/ 폴더랑 배포 설정이 보이는데, 이건 따로 맡은 사람이 있나요, 아니면 기능 만든 사람이 그때그때 하나요?”

한 번에 하나씩, 서너 개쯤 물어봅니다. 대부분 고르기만 하면 되는 질문이라 길게 쓸 일은 없습니다. 모르겠으면 모르겠다고 하셔도 됩니다. 답이 갈리지 않는 질문이면 AI가 좁은 쪽을 고르게 되어 있습니다.

“테스트는 어떻게 하세요”, “팀이 몇 명이에요” 같은 건 안 물어봅니다. 답을 들어도 보드가 달라지지 않는 질문은 하지 않도록 되어 있습니다.

5. 만들 목록을 보고 승인합니다

질문이 끝나면 만들 걸 통째로 보여줍니다. 두 덩어리로 나눠서요.

• 영역: 앞으로 카드를 담을 큰 칸입니다. 많아야 세 개를 제안합니다. 하나여도 됩니다.
• 지금 진행 중인 카드: 열려 있는 브랜치나 PR에서 나온 것들입니다. 많아야 다섯 개고, 각각 어디서 나온 건지가 같이 적혀 있습니다.

여기서 “이건 빼고”, “이 이름은 이걸로” 하고 고치시면 됩니다. 승인하기 전에는 아무것도 만들어지지 않습니다. tuckit에는 지우는 기능이 없어서, 잘못 만들면 사람이 웹에서 손으로 치워야 하기 때문입니다.

적어둔 TODO는 안 가져옵니다

코드에 흩어진 TODO 주석이나 쌓아둔 이슈 목록은 일부러 안 가져옵니다. 첫날에 검토할 게 백 개 생기고, 그중 실제로 하게 되는 건 몇 개 안 됩니다. 나중에 생각날 때 한 줄씩 던져두는 편이 훨씬 빠릅니다.

6. 보드를 열어보면 이렇게 되어 있습니다

만들어지고 나면 카드가 전부 첫 번째 칸에 있습니다(Needs design). 거의 다 만들어놓은 브랜치에서 나온 카드도 그렇습니다.

고장 난 게 아닙니다. 그 칸은 “이걸 왜 만드는지 아무도 적어놓지 않았다”는 뜻입니다. 브랜치는 있는데 적어둔 게 없으면 그게 맞는 상태입니다. 보드가 첫날 알려주는 첫 번째 사실이라고 보시면 됩니다.

AI는 여기서 멈추고 넘깁니다. 알아서 다음 일로 넘어가지 않습니다. 사람이 처음 보는 보드니까 일단 읽어보시라는 뜻입니다.

7. 하나 골라서 채워봅니다

카드를 하나 열고 번호를 복사해서(ACME-42 같은 모양입니다) 이렇게 말하면 됩니다.

ACME-42, 만들기 전에 뭘 만들 건지부터 같이 정하자.

AI가 질문을 하나씩 던지면서 설계를 맞춰갑니다. 합의가 되면 그 내용을 카드의 무엇을 만들 건지(Spec) 칸에 적습니다. 그러면 카드가 다음 칸으로 넘어갑니다.

여기까지 오면 준비는 끝입니다. 그다음부터는 아래 문장들만 쓰시면 됩니다.

무슨 말을 하면 되나요

외울 문장은 없습니다. 평소 말하듯이 하면 AI가 알아서 맞는 절차를 꺼냅니다. 아래는 그래도 뭘 쳐야 할지 막힐 때 복사해서 쓰시라고 모아둔 것입니다.

하루를 시작할 때

지금 이 프로젝트 상태가 어때?

Inbox에 뭐가 쌓여 있는지 보여줘.

뭘 만들지 정할 때

ACME-42, 만들기 전에 뭘 만들 건지부터 같이 정하자.

ACME-42를 순서대로 단계까지 쪼개줘.

만들라고 시킬 때

ACME-42 이어서 해줘.

ACME-42, 단계마다 다른 에이전트한테 맡기고 매번 검토 붙여줘.

끝났는지 확인할 때

진짜로 돌려보고 확인한 다음에 다 됐다고 말해줘.

ACME-42 머지하고 보드 정리까지 해줘.

뭘 만든 건지 모르겠을 때

이번에 만든 거 내가 이해할 수 있게 설명해줘.

창을 닫기 전에

지금까지 한 거 보드에 정리해줘.

보드가 지저분해졌을 때

열린 카드가 너무 많아. 닫을 만한 거 골라서 이유랑 같이 보여줘.

뭘 칠지 모르겠으면 앱이 써줍니다

카드를 열면 Hand to an agent 버튼이 있습니다. 그 카드가 있는 칸에 맞는 문장을 절차 이름까지 붙여서 만들어줍니다. 복사해서 붙이기만 하면 됩니다.

이 카드는 In progress에 있어서 문장 끝이 (skill: executing-a-slice)로 끝납니다. 카드가 다른 칸으로 옮겨 가면 문장도 같이 바뀝니다.

카드 번호는 그냥 붙여넣어도 됩니다

카드마다 ACME-42 같은 번호가 있고 어디서든 복사됩니다. 대화창에 그대로 붙여넣으시면 AI가 알아서 그 카드를 읽습니다.

---

여기까지가 쓰는 법입니다. 아래부터는 플러그인이 안에서 뭘 하고 있는지에 대한 설명이라, 궁금해질 때 읽으셔도 됩니다.

세션이 시작될 때

새 창을 열면 에이전트가 사람보다 먼저 짧은 안내를 받습니다. 내용을 우리말로 옮기면 이렇습니다.

이 프로젝트는 tuckit에 기록됩니다. 지금 상태가 어떤지, 앞으로 뭘 할 건지, 나중에 하기로 미뤄둔 게 뭔지는 코드나 마크다운 파일이 아니라 tuckit에 있습니다. “지금 어디까지 왔지” 같은 질문은 보드를 먼저 읽고 답하세요. 일을 시작하기 전에 보드에 이미 그 카드가 있는지 확인하고, 있으면 그걸 이어가세요.

하는 일은 하나입니다. 에이전트가 코드를 뒤져서 추측하는 대신 보드를 읽게 만드는 것.

매일의 흐름에서 “이렇게 물어보세요”라고 알려드린 문장들을 대신 쳐주는 셈입니다. 그래서 대부분의 날은 직접 시킬 일이 없습니다.

이 안내는 tuckit을 한 번도 안 여는 세션에도 똑같이 들어갑니다. 그래서 일부러 짧게 유지합니다. 자세한 설명은 필요할 때만 읽히는 쪽으로 빼뒀습니다.

세션이 끝나기 전

에이전트가 대화를 마치려고 할 때 알림이 한 번 뜹니다.

보드에 관해 바뀐 게 없으면 아무 말 없이 그냥 끝납니다. 실제로 대부분의 세션이 이쪽입니다. 바뀐 게 있으면 에이전트가 끝나기 전에 한 바퀴 정리합니다.

1. 사실이 아니게 된 카드를 닫습니다. 오늘 한 일 때문에 필요 없어진 카드, 중복으로 만들어둔 카드, 알고 보니 틀린 지적 같은 것들입니다. 닫는다고 지워지지 않습니다. 내용과 기록은 그대로 읽히고, “이걸 할 사람이 있다”는 주장만 내려갑니다.
2. 뭘 했는지 카드에 적습니다. 끝낸 단계를 체크하고, 무슨 일이 있었는지를 기록에 남깁니다.
3. 새로 만들 카드는 먼저 보여주고 확인을 받습니다.

세 번째가 이 알림에서 제일 중요한 부분입니다.

새 카드는 한 번에 모아서 물어봅니다

에이전트는 사람이 카드를 닫는 속도보다 훨씬 빠르게 할 일을 발견합니다. 발견할 때마다 카드를 하나씩 만들면 보드는 한 달이면 아무도 안 읽는 목록이 됩니다.

그래서 에이전트는 세션 내내 발견한 것을 모아뒀다가, 끝날 때 한 번에 보여줍니다. 한 줄에 하나씩, 어디에 넣을 건지와 왜 카드가 될 만한지를 붙여서요. 사람이 고른 것만 만들어집니다.

같이 딸려 오는 게 하나 더 있습니다. 에이전트가 우선순위 숫자도 같이 제안합니다. 물어보는 건 한 번뿐이니 순위도 같은 자리에서 묻는 겁니다.

여기서 숫자를 고쳐주면 에이전트가 이유를 한 번 되묻습니다.

“TP-42를 3이 아니라 1로 두신 이유가 뭔가요?”

이 한 줄이 이 흐름 전체에서 제일 값어치 있는 부분입니다. 빈 설정 화면 앞에 앉혀놓고 “우선순위 기준을 적어보세요”라고 하면 아무도 못 씁니다. 틀린 순위가 눈앞에 있을 때는 왜 틀렸는지 바로 나옵니다. 그렇게 나온 문장이 조직의 우선순위 기준으로 쌓이고, 다음부터 에이전트가 그 기준을 읽고 순위를 매깁니다.

어디에 넣을지까지는 안 정해도 됩니다. 승인만 하면 Inbox에 쌓이고, 나중에 몰아서 정리하면 됩니다.

이름이 붙은 작업 방식

여기서부터가 플러그인의 큰 쪽입니다.

에이전트에게 “이럴 땐 이렇게 한다”를 글로 적어둔 절차서가 여러 개 들어옵니다. 이런 걸 스킬이라고 부릅니다. 항상 읽히는 게 아니라, 상황이 맞을 때만 에이전트가 꺼내 읽습니다.

전부 외울 필요는 없습니다. 아래는 어떤 게 있는지 알아두는 용도입니다. 뭔가 빠뜨린 것 같을 때 이름을 대서 직접 시킬 수 있으니까요.

카드가 있는 칸이 곧 다음에 쓸 절차입니다

매일의 흐름에서 칸마다 할 일이 하나씩 정해져 있다고 말씀드렸습니다. 플러그인은 그 할 일마다 절차를 하나씩 붙여둔 것입니다.

카드가 있는 칸	절차 이름	카드에 남는 것
Needs design	designing-a-slice	질문을 하나씩 던져 설계를 맞춰간 다음, 합의된 내용을 무엇을 만들 건지(Spec)에 적습니다
Needs steps	breaking-down-a-slice	건드리면 안 되는 것(Constraints)을 먼저 적고, 그다음 순서대로 쪼갠 단계(Steps)를 답니다
In progress	executing-a-slice	단계를 하나씩 해나가면서 그때그때 상태를 바꿉니다. 미루기로 한 건 새 카드가 됩니다
In progress (단계가 서로 안 얽혀 있으면)	delegating-a-slice	위와 같은데, 단계마다 다른 에이전트에게 맡기고 매번 검토를 붙입니다
Ready to ship	shipping-a-slice	진짜로 돌려보고 나서 브랜치를 넣고, 뭘 내보냈는지 기록을 남깁니다. “끝났다”고 찍는 건 사람에게 물어봅니다

오른쪽 칸의 내용이 전부 카드 안에 들어간다는 게 핵심입니다. 설계도, 주의사항도, 진행 상황도 파일이 아니라 카드에 적힙니다. 다음 세션은 그 파일이 어디 있는지 몰라도 카드만 열면 됩니다.

delegating-a-slice가 그 차이를 제일 잘 보여줍니다. 단계를 맡은 에이전트에게 카드 번호와 단계 번호만 주면 나머지는 스스로 읽어 갑니다. 따로 지시문 파일을 만들 필요가 없고, 그래서 지시문이 보드와 어긋날 일도 없습니다. 컨트롤러 쪽 대화가 중간에 잘려도 보드를 다시 읽으면 어디까지 했는지 나오니, 이미 끝난 단계를 다시 시키지 않습니다.

일하는 도중에 불려 나오는 것들

칸과 상관없이, 지금 하고 있는 일의 방식을 정하는 절차들입니다. 보통 위의 절차들이 알아서 부르고, 사람이 직접 불러도 됩니다.

절차 이름	언제	보드에 남는 것
writing-tests-first	코드를 쓰기 전에	예외를 두기로 합의했으면 그 내용이 건드리면 안 되는 것에 한 줄 붙습니다
verifying-before-claiming	“다 됐다”고 말하기 전에	없습니다. 그 말을 해도 되는지만 판단합니다
debugging-systematically	버그나 테스트 실패를 만났을 때	알아낸 규칙은 건드리면 안 되는 것으로, 과정은 기록으로, 관련 없는 버그는 Inbox 카드로
requesting-a-review	검토를 받아야 할 때	없습니다. 지적사항을 만들어냅니다
receiving-a-review	지적사항을 받았을 때, 고치기 전에	지금 안 고칠 것들은 카드 후보로 정리되고, 승인하면 만들어집니다
explain-change	뭘 만든 건지 진짜로 이해해야 할 때	없습니다. 아래를 보세요

verifying-before-claiming은 짧지만 이 목록에서 제일 자주 걸립니다. 에이전트가 “고쳤습니다”라고 말하기 전에 실제로 돌려보고 결과를 확인하게 만드는 절차입니다. 단계에 체크를 하기 전에도 걸립니다.

debugging-systematically에는 멈추는 지점이 하나 정해져 있습니다. 같은 문제를 세 번 고쳐서 세 번 다 실패하면 네 번째를 시도하지 않습니다. 대신 “이건 구조 문제라서 이 자리에서 못 고친다”는 결론을 카드로 만들고 멈춥니다.

만든 걸 설명해야 할 때

explain-change는 다른 것들과 성격이 다릅니다. 보드에 아무것도 안 씁니다.

에이전트가 쓴 코드 뭉치 하나를 골라서 웹 페이지 한 장으로 만들어줍니다. 뭘 하려던 것이었는지(카드에 적힌 그 문장을 그대로 끌어옵니다), 지금 코드가 실제로 무슨 일을 하는지, 그리고 마지막에 이해했는지 확인하는 문제 몇 개가 붙습니다.

브랜치, PR, 커밋 구간 중 아무거나 가리키면 됩니다.

이번에 만든 거 내가 이해할 수 있게 설명해줘.

만들어진 걸 보고도 뭘 만든 건지 설명을 못 하겠는 상황이라면 이게 그걸 위한 도구입니다.

보드를 읽을 수 있게 유지하는 것들

카드는 만들기도 공짜고 놔두기도 공짜입니다. 그래서 그냥 두면 보드는 “다 맞는 말인데 아무도 안 읽는” 상태로 갑니다. 이 두 개가 그걸 막습니다.

절차 이름	언제	하는 일
reconciling-the-board	세션이 끝날 때, 또는 지금 당장 정리하고 싶을 때	위의 “세션이 끝나기 전”에서 설명한 그 정리입니다
clearing-the-board	열린 카드가 아무도 안 읽을 만큼 많아졌을 때	닫을 후보와 이유를 목록으로 보여주고, 승인한 것만 닫습니다

reconciling-the-board가 세션 끝 알림이 가리키는 그 절차입니다. 알림은 찌르기만 하고, 실제 순서는 여기 들어 있습니다.

clearing-the-board는 “몇 달 된 거”가 아니라 왜 이건 죽은 건지를 이유로 댑니다. 오래됐다는 건 이유가 아니니까요. 그리고 절대 혼자 닫지 않습니다.

닫는 건 지우는 게 아닙니다

카드를 닫으면 dropped 상태가 됩니다. 제목도 내용도 기록도 그대로 남아서 나중에 검색됩니다. 없어지는 건 “이걸 할 사람이 있다”는 주장 하나뿐입니다.

물어보지 않고는 안 하는 것들

에이전트가 사람 확인 없이 하지 않는 게 몇 가지 정해져 있습니다. 알아두면 편합니다.

• 새 카드를 만드는 것. 세션 중에 발견한 것들은 모아뒀다가 끝에 한 번에 물어봅니다.
• 카드를 닫는 것. clearing-the-board는 목록만 내놓습니다.
• 첫 영역과 첫 카드를 만드는 것. adopting-a-project도 마찬가지입니다.
• “끝났다”고 찍는 것. 이건 계산이 아니라 판단이라서 사람 몫입니다.

사람이 이번 세션에 명시적으로 “이거 카드로 만들어둬”라고 시킨 건 예외입니다. 이미 승인된 것으로 봅니다.

알아두면 좋은 것

Codex CLI 쪽은 아직 실물 확인이 안 됐습니다. 문서에 적힌 형식대로 만들어져 있지만, 돌아가는 Codex에 실제로 설치해서 확인해본 적이 없습니다. 시작 안내나 끝 알림이 안 뜨면 에이전트 연결하기의 Codex 항목을 보세요.

Superpowers를 쓰고 계시다면 같이 켜지 마세요. 여기 들어 있는 절차 중 몇 개는 Superpowers에서 갈라져 나온 것입니다. 바꾼 건 하나입니다: 원본이 마크다운 파일에 쓰던 것을 보드에 씁니다. 둘 다 켜두면 같은 상황에서 두 절차가 겹치고, 어느 쪽이 이기느냐에 따라 설계가 파일로 갈지 카드로 갈지 갈립니다. 이 플러그인은 그걸 대신하는 물건입니다.

Python 3이 있어야 합니다. 시작·끝 알림이 작은 스크립트를 돌립니다. 따로 설치할 패키지는 없습니다.

어디로

• 매일의 흐름: 플러그인 없이도 통하는 습관 쪽입니다. 이 페이지는 그걸 자동으로 해주는 부분이고요.
• 화면에 보이는 것들: Spec이 뭐고 칸이 왜 네 개인지가 아직 헷갈리시면 여기부터요.
• 에이전트 연결하기: 설치가 잘 안 될 때.
• MCP 도구: 에이전트가 보드에 대고 할 수 있는 일 전부.
• 소스는 tuck-it/tuckit-plugins에 있고 MIT입니다. 절차서는 전부 읽을 수 있는 마크다운 파일이라, 마음에 안 드는 부분은 고쳐서 쓰셔도 됩니다.