팀에 도입하려면

“Jira보다 작다”는 건 주장이지 근거가 아닙니다. 이 페이지가 근거입니다. 배워야 할 것을 하나도 빼지 않고 적어뒀으니, 팀의 한 주가 얼마나 드는지 직접 계산해보시면 됩니다.

다른 사람들에게 쓰게 할 생각이라면 이 페이지를 먼저 읽으시는 게 좋습니다. 계산이 마음에 들면 Jira를 쓰고 있다면이 비교고, 10분 따라하기가 실물 확인입니다.

먼저, 이 사이트에 계속 나오는 두 단어

이미 아시면 건너뛰세요.

코딩 에이전트는 코드를 직접 고치는 AI입니다. Claude Code, Codex CLI, Antigravity 같은 것들이요. 파일을 읽고, 고치고, 명령까지 실행합니다. 채팅봇이 코드를 보여주기만 한다면 에이전트는 직접 바꿉니다.

MCP는 그 AI들이 바깥 도구를 쓸 때 지키는 공용 규격입니다. AI가 캘린더를 읽거나 데이터를 조회할 수 있다면 대체로 이 규격을 통해서입니다. tuckit이 보드를 이 규격으로 열어두기 때문에, 누가 연동을 따로 만들지 않아도 AI가 읽고 씁니다.

웹 화면만 쓸 사람은 둘 다 몰라도 됩니다. AI를 붙이는 사람만 알면 됩니다.

배울 말: 네 개

말	무엇인가	몇 개나 생기나
조직 (`Org`)	계정 안의 큰 묶음. 주소와 카드 번호를 정합니다	프로젝트당 또는 회사당 하나
영역 (`Area`)	큰 분류. `프론트`, `백엔드`, `문서`	처음엔 두세 개
카드 (`Slice`)	일 하나. “해야겠다”부터 끝날 때까지	보드의 대부분
단계 (`Steps`)	카드 안의 순서 있는 할 일	카드당 몇 개

다섯 번째는 없습니다. 가볍게 적어둘 물건도 따로 없고, 커졌을 때 옮겨 담을 물건도 따로 없습니다. 지나가는 생각과 한 분기짜리 일이 같은 카드고, 차이는 그 안에 얼마나 적혀 있느냐입니다.

카드 안에는 서로 다른 일을 하는 칸이 세 개 있습니다. 구조라고 부를 만한 건 이게 전부입니다.

칸	시점	답하는 질문
`Spec`	앞으로	뭘 만들 건가, 왜 만드나
`Constraints`	계속	절대 어긋나면 안 되는 게 뭔가
`Activity`	지나간 일	실제로 무슨 일이 있었나

여기까지가 전부입니다. 화면에 보이는 것들이 같은 내용을 길게 쓴 것입니다.

사람이 판단할 것: 세 개

보드 전체에서 사람의 판단이 필요한 건 세 개뿐입니다.

뭘 만들 것인가 (Spec)
뭘 건드리면 안 되는가 (Constraints)
끝났다는 판정. 다른 무엇으로도 대신할 수 없는 유일한 상태 변경입니다.

나머지는 이 셋에서 계산되거나, 언제든 되돌릴 수 있는 정리 작업입니다.

되돌릴 수 있는 정리 작업은 사람도 AI도 합니다. 카드를 영역에 넣기(영역을 지우면 Inbox로 돌아옵니다), 단계 추가와 체크, 담당자, 태그, 순서. 여기엔 한 번 하면 못 돌리는 게 없어서 아무도 조심할 필요가 없습니다.

아무도 정하지 않는 것들:

Stage. 어디까지 왔는지, 카드 내용에서 그때그때 계산됩니다.
카드가 보드 어느 칸에 있는지. Stage가 정합니다. 그래서 카드를 끌어다 옮길 수 없습니다. 카드를 “정해진 칸”으로 끌어다 놓는다고 정해지지 않으니까요.
카드 번호(ACME-42). 만들 때 조직별로 자동으로 붙습니다.
진행도. 체크된 단계 개수 그 자체입니다.

없어서 안 배워도 되는 것

아래는 “아직 없음”이 아닙니다. 모델에 아예 없고, 팀원들이 이것에 대해 의견을 가질 일이 영영 없습니다.

스프린트, 반복 주기, 속도
스토리 포인트, 공수 추정, 시간 기록
에픽, 이슈 종류 (버그/스토리/작업 구분 없음, 하위 작업 종류 없음)
사용자 정의 필드
설정 가능한 워크플로, 상태 전이 규칙, 필수 입력 규칙
해결 유형
컴포넌트, 릴리스 버전
권한 체계, 이슈별 접근 제어
보드 설정 (스윔레인, 빠른 필터, 저장된 보기)
리포트 빌더, 번다운·속도 차트
자동화 규칙

이 중에 팀이 진짜로 쓰는 게 있을 겁니다. 그건 tuckit을 쓰지 않을 정당한 이유고, Jira를 쓰고 있다면에서 설득하려 들지 않고 그대로 적어뒀습니다.

한 사람당 드는 설정 비용

한 번만 하고 다시 안 합니다.

app.tuckit.dev에서 가입. 이메일과 비밀번호, 또는 Google이나 GitHub 계정.

쓰는 AI에 두 줄 입력. Claude Code라면 정말 이게 전부입니다.

/plugin marketplace add tuck-it/tuckit-plugins
/plugin install tuckit@tuckit-plugins

AI가 tuckit을 처음 쓸 때 브라우저에 뜨는 화면에서 Allow 누르기.

긴 문자열을 만들어서 복사하고 어딘가에 저장하고 주기적으로 갈아주는 과정은 없습니다. 최소한 일반적인 경로에서는요. 자격 증명은 운영체제 키체인에 들어가고 알아서 갱신됩니다. 다른 AI들과, 지금 유일하게 토큰이 필요한 경우(Codex)는 에이전트 연결하기에 있습니다.

역할별로 첫날 알아야 할 것

웹 화면만 여는 사람. PM, 디자이너, 상황만 보는 대표. 말 네 개와 문장 하나면 됩니다. 무엇을 만들지 칸이 비어 있으면 아직 안 정한 것이다. 이게 교육의 전부입니다. 처음 봐도 보드를 제대로 읽습니다. 칸이 누군가 설정해둔 절차가 아니라 현재 상태를 그대로 비춘 것이기 때문입니다.

AI를 붙이는 사람은 위의 두 단어를 더 알고 명령어 두 줄을 칩니다. MCP 도구 열한 개를 외울 필요는 없습니다. 그건 AI가 서버에서 직접 읽습니다.

팀에 세팅하는 사람은 하나를 더 압니다. 영역은 담당 범위지 기능이 아닙니다. 기능마다 영역을 만들고 있다면 그건 카드로 만들 것이었습니다. 초반에 제일 흔한 실수인데, 클릭 한 번으로 고쳐집니다. 카드를 영역 사이로 옮기는 건 공짜니까요.

진짜로 시간이 드는 것

네 가지입니다. 기능 목록만 봐서는 아무도 안 익혀집니다.

Status와 Stage를 섞습니다. Status는 사람이 내린 판정(open, shipped, dropped)이고 저장됩니다. Stage는 지금 뭐가 필요한지(needs_design → needs_steps → executing → ready_to_ship)를 계산한 것이고 저장되지 않습니다. 진행 상황은 Stage에서, 결정은 Status에서 읽습니다. 습관이 잘못 들기 전에 긴 설명을 10분 읽는 게 남는 장사입니다.

끝낼 때 적는 습관이 진짜 비용입니다. 세션이 끝날 때 결정이 채팅 기록이 아니라 보드로 가야 tuckit이 맞는 상태로 유지됩니다. 플러그인이 알림을 넣어주지만 알림은 강제가 아닙니다. 이건 기능이 아니라 규율이고, 3주 뒤에도 보드를 열어볼 가치가 있느냐를 결정하는 게 이겁니다. 어색하지 않게 되기까지 두세 세션쯤 잡으세요. 매일의 흐름이 이 습관을 적어둔 글입니다.

빈 칸이 표시라는 걸 받아들이기 어려워합니다. 다른 도구들은 전부 양식을 채우면 칭찬해주기 때문입니다. 여기서는 Spec이 비어 있는 게 아무도 아직 안 정했다는 표시고, AI가 제일 먼저 알아채는 것도 그겁니다. 대충 한 줄 채워두면 안 정해진 일이 정해진 것처럼 보입니다. 사람에게도 AI에게도요.

영역을 기능 단위로 만듭니다. 위에서 말한 그 실수인데, 고치기 쉬운 대신 눈치 채기까지 몇 주가 걸립니다.

정리하면

화면에 보이는 것들이 10분이고, 읽어야 할 건 그거 하나입니다. 설정은 5분 안쪽. 습관은 두세 세션.

아무도 대신 줄여줄 수 없는 부분은 이 정도로 작은 모델이 우리 팀에 맞는지 판단하는 것이고, 그게 다음 페이지입니다.

어디로 갈까요

Jira를 쓰고 있다면: 대응표, 포기하는 것, 그리고 Jira에 남는 게 맞는 경우.
10분 따라하기: 보드 하나와 붙은 AI 하나.
화면에 보이는 것들: 말 네 개를 자세히.