화면에 보이는 것들

외울 게 많지 않습니다. 덩어리 세 개와 구분 하나가 전부고, 나머지는 tuckit이 알아서 계산합니다.

일부러 이렇게 작게 만들었습니다. AI가 한 번에 다 기억할 수 있을 만큼 작아야 AI가 틀리지 않고, 사람에게 두 번 설명하지 않아도 됩니다.

워크스페이스 (Workspace)

계정 안의 큰 묶음입니다. 회사 하나일 수도 있고 프로젝트 하나일 수도 있습니다. 영역도 카드도 팀원도 전부 워크스페이스 안에 들어갑니다.

워크스페이스에는 주소에 쓰는 짧은 영문 이름이 있습니다. acme라고 지으면 주소가 /acme/board/가 됩니다. 그리고 그걸 대문자로 줄인 이름이 카드 번호에 붙습니다. ACME-42 같은 식으로요.

이 번호가 생각보다 유용합니다. 채팅창에 ACME-42라고만 던져도 사람도 AI도 어느 카드인지 정확히 압니다.

계정 하나가 워크스페이스를 여러 개 가질 수 있습니다. 다만 AI 연결 하나는 워크스페이스 하나에만 닿습니다. 프로젝트를 여러 개 굴린다면 이 선택이 중요해집니다. 프로젝트가 여러 개라면에 정리해뒀습니다.

영역 (Area)

큰 분류입니다. 프론트, 백엔드, 문서, 인프라 같은 것들이요.

자주 바뀌지 않습니다. 카드를 담는 것 말고 하는 일이 없고, 카드가 들어갈 수 있는 곳은 영역뿐입니다. 기능마다 영역을 만들고 있다면 그건 카드로 만들 것이었을 가능성이 높습니다.

카드 (Slice)

일 하나입니다. 누군가 “이거 해야겠다”고 생각한 순간부터 다 끝날 때까지 같은 카드 하나로 갑니다.

작은 일용 물건과 큰 일용 물건이 따로 있지 않습니다. 지나가는 생각도 카드고, 한 분기 내내 붙잡을 일도 카드입니다. 차이는 그 안에 얼마나 적혀 있느냐입니다.

안에 서로 다른 일을 하는 칸이 세 개 있습니다. 이 셋을 섞지 않는 게 tuckit을 쓰는 요령의 대부분입니다.

무엇을 만들 건지. 화면에는 Spec. 무엇을 왜 만드는지 적는 칸입니다. 비어 있으면 아직 안 정했다는 뜻이고, 그게 쓸모 있는 표시입니다. 카드가 완성돼 보이게 하려고 대충 채워두지 마세요.

건드리면 안 되는 것. 화면에는 Constraints. 나중에 이 일을 이어받는 사람이나 AI가 몰라서 사고 칠 만한 것들입니다. “결제 코드는 손대지 말 것”, “이 함수 결과 형식은 청구서 기능이 같이 쓰니 바꾸지 말 것” 같은 문장이요. 세션이 끝나도 남아서 일하는 칸입니다. 아무것도 모르는 사람에게 넘긴다고 생각하고 적으면 됩니다.

어느 영역에 속하나. 화면에는 Area. 비어 있으면 아직 Inbox에 있다는 뜻입니다.

그 밖에 번호(ACME-42), 상태, 담당자, 태그가 붙습니다.

Inbox는 따로 있는 곳이 아닙니다

Inbox는 별도의 목록이나 다른 종류의 물건이 아닙니다. 영역이 안 정해졌고 아직 안 끝난 카드를 부르는 말일 뿐입니다.

어디에 넣을지 정하지 않고 일단 적어두는 건 임시방편이 아니라 정식 경로입니다. 중요하다는 건 알겠는데 어디 속하는지는 모를 때가 자주 있으니까요. 영역을 정하면 Inbox에서 빠지고, 영역을 다시 지우면 돌아옵니다. 양쪽 다 됩니다.

판정 기준 (Done when)

한 문장입니다. 무엇을 봐야 이게 끝났다고 할 수 있나?

명령이 아니라 목격한 장면을 적습니다. “테스트를 돌린다”는 명령이고, 그건 기능이 망가진 채로도 만족시킬 수 있습니다. “만료된 토큰으로 부르면 성공 응답 안에 숨은 에러가 아니라 401이 온다”는 장면이고, 이건 틀린 것으로 밝혀질 수 있습니다. 틀릴 수 있다는 게 이 칸을 적는 유일한 이유입니다.

일을 시작하기 전에 적으세요. 끝난 뒤에 적은 것은 이미 한 일을 옮겨 적은 것이라 어긋날 수가 없고, 어긋날 수 없으면 아무것도 판정하지 못합니다.

확인한 것 (Evidence)

실제로 가서 본 것을 적는 칸입니다. 언제 봤는지가 같이 찍힙니다.

tuckit은 이걸 심사하지 않습니다. 남의 테스트를 대신 돌려줄 수 없고, 그런 척도 안 합니다. tuckit이 하는 일은 이 칸이 비어 있는 동안 카드를 shipped로 넘기지 못하게 막는 것뿐입니다. 그래서 주장이 일 옆에, 다음 사람이 읽는 자리에 남게 됩니다.

이 칸을 비우면 카드가 다시 진행 중으로 돌아갑니다. 되돌릴 수 없는 건 여기 없습니다.

기록 (Activity)

카드 아래에 계속 쌓이는 기록입니다. 무슨 일이 있었는지를 적습니다. 뭘 시도했고, 뭐가 막혔고, 어디에 올렸는지 같은 것들이요. 지우지 않고 계속 붙습니다.

정리하면 칸 세 개가 각각 다른 시점을 맡습니다.

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

사람이 정하는 것과 tuckit이 계산하는 것

여기가 유일하게 헷갈리는 부분이고, 헷갈리면 습관이 잘못 듭니다. 나누는 기준은 하나입니다. 누가 정하는가.

Status는 사람이 내린 판정입니다. open(진행 중), shipped(끝냈다), dropped(안 하기로 했다) 셋 중 하나입니다. 저절로 바뀌지 않습니다.

Stage는 tuckit이 계산한 것입니다. 카드 안에 뭐가 들었는지를 보고 그때그때 계산합니다. 어디에도 저장하지 않고, 사람도 AI도 직접 바꿀 수 없습니다.

Stage	무슨 뜻인가	다음 칸으로 넘기려면
needs_design	무엇을 만들지 칸이 비어 있습니다	뭘 만들지 정해서 적습니다
needs_done_when	정하긴 했는데 뭘 봐야 끝인지가 없습니다	판정 기준을 적습니다
executing	기준은 있고 아직 아무도 확인 안 했습니다	만들고, 가서 봅니다
ready_to_ship	확인한 것이 적혔습니다	사람이 “됐다”고 정합니다
shipped / dropped	끝난 것. Status를 따라갑니다	없음

그러니까 진행 상황을 손으로 옮기는 일은 없습니다. 무엇을 만들지 적고, 주의할 걸 적고, 뭘 봐야 끝인지 적고, 실제로 본 것을 적으면 위치는 알아서 따라옵니다. 손으로 하는 건 마지막 하나뿐인데, “이제 됐다”는 계산으로 나오는 게 아니라 판단이기 때문입니다.

진행 상황은 Stage에서, 결정은 Status에서 읽으세요. open이라는 것만으로는 얼마나 진행됐는지 알 수 없고, ready_to_ship이면 사람 차례라는 뜻입니다.

보드

보드는 카드를 Stage별로 모아놓은 화면입니다. Status가 아니라요. 진행 중인 일만 네 칸에 나옵니다.

카드를 끌어다 옮길 수 없습니다. 위치가 안의 내용에서 나오기 때문입니다. 카드를 “무엇을 만들지 정해진 칸”으로 끌어다 놓는다고 정해지는 게 아니니까요.

끝난 것(Shipped)과 안 하기로 한 것(Dropped)은 칸으로 만들지 않고 보드 아래에 개수로 둡니다. 눌러서 볼 수는 있고요. 끝난 일이 진행 중인 일의 자리를 차지하지 않게 하려는 겁니다.

처음부터 끝까지

1. 생각나거나 요청받은 것을 영역 없이 카드로 적어둡니다. Inbox에 들어갑니다.
2. 할 만하다 싶으면 영역을 정해줍니다. 되돌릴 수 있습니다.
3. 뭘 만들지 정해서 Spec에 적습니다. needs_design을 벗어납니다.
4. 무엇을 보면 됐다고 할지를 판정 기준에 적습니다. executing이 됩니다.
5. 만든 뒤 실제로 확인하고, 본 것을 확인한 것에 적습니다. ready_to_ship이 됩니다.
6. 끝났다고 정합니다. 사람 몫은 이거 하나입니다.

나중에 하기로 한 것도 보드에 있어야 합니다. 하기로 정한 건 영역까지 붙여서, 막연한 생각은 영역 없이 Inbox에 두면 됩니다. 대화창에만 있는 건 없는 겁니다.

예를 하나 끝까지

월요일에 Safari에서 회원가입이 안 되는 걸 발견했습니다. Safari에서 회원가입 실패라고 제목만 적고 카드를 만듭니다. 영역이 없으니 Inbox에 있고, 무엇을 만들지 칸이 비어 있으니 needs_design입니다. 들인 노력은 제목 한 줄뿐입니다.

수요일에 이건 고쳐야겠다고 정합니다. 프론트 영역에 넣습니다. Inbox에서 빠지고 그 영역의 할 일 목록에 들어갑니다. 무엇을 고칠지는 아직 모르니 여전히 needs_design입니다.

목요일에 AI와 원인을 찾아냅니다. AI가 찾은 내용을 Spec에 적습니다. 그리고 Constraints에 이렇게 적습니다. 날짜 처리 코드는 청구서 내보내기 기능이 같이 쓴다. 결과 형식은 바꾸지 말 것. 세션이 끝나도 남아서 일하는 게 이 문장입니다. Stage는 저절로 needs_done_when이 됩니다.

이어서 판정 기준을 적습니다. 청구서 내보내기에 날짜를 넣고 저장한 뒤 다시 열면 같은 날짜가 나온다. Stage가 executing이 됩니다.

일을 끝낸 뒤 실제로 내보내기를 열어 저장하고 다시 열어 보고, 본 것을 확인한 것에 적습니다. 어디에 올렸는지 기록도 남깁니다. 확인한 것에 시각이 찍히는 순간 ready_to_ship이 됩니다.

카드를 손으로 옮긴 적은 한 번도 없습니다. 사람이 정한 건 영역, 무엇을 만들지, 주의할 것 세 개뿐이고, 남은 건 “진짜 됐다”를 정하는 것 하나입니다.

이제 안 쓰는 말들

예전에 쓴 글에서 Org(조직), Ticket, Plan 같은 말을 보셨을 수 있습니다. 셋 다 없어졌습니다. Ticket과 Plan은 카드 하나로 합쳐졌습니다. 뭘 하는 일인지 알기도 전에 물건 종류부터 고르게 만드는 게 문제였기 때문입니다. 그리고 조직은 워크스페이스가 됐습니다. 요금이 워크스페이스 단위로 붙는데, 조직을 세 개씩 가진 사람은 없기 때문입니다.

지금 쓰는 말은 워크스페이스, 영역, 카드, 판정 기준, 확인한 것. 이게 전부입니다.