tuckit이 뭔가요?

AI 에이전트로 개발해 보셨다면, 특히 팀에서 여러 사람이 각자 AI를 쓰고 있다면 이런 일을 겪어보셨을 겁니다.

월요일에 AI와 “이건 나중에 고치자”, “여기는 절대 건드리지 마”라고 정해 뒀습니다. 화요일에 동료의 AI가 같은 코드를 맡았습니다. 그 AI에게는 아무도 그 얘기를 하지 않았습니다. 두 AI 모두 일을 잘했는데, 결과물이 서로 맞지 않습니다. 이 기능이 끝났느냐고 누가 물으면 답은 채팅 창 두 개에 흩어져 있고, 둘이 서로 다릅니다.

tuckit은 그런 결정을 적어두는 웹 페이지입니다. 작업마다 무엇을 보면 끝난 것인지, 실제로 확인해 보니 어땠는지도 함께 적힙니다. 사람이 열어서 읽고 쓸 수 있고, 팀의 AI도 모두 같은 페이지를 직접 읽고 씁니다.

화면부터 보겠습니다

지금 만들고 있는 것들이 카드로 놓여 있습니다. 왼쪽에서 오른쪽으로 갈수록 완성에 가깝습니다.

• Needs design: 하기로는 했는데 뭘 만들지 아직 안 정한 것
• Done when?: 뭘 만들지는 정했는데, 뭘 보면 됐다고 할지를 아직 안 정한 것
• In progress: 기준은 정해졌고 아직 아무도 그걸 못 본 상태
• Ready to ship: 누가 실제로 확인하고 본 것을 적어놨고, 사람이 “됐다”고 하면 되는 것

카드는 끌어다 옮길 수 없습니다. 내용이 채워지면 tuckit이 알아서 옮깁니다. 그래서 보드를 볼 때 “저 카드가 저기 있는 게 맞나”를 의심할 필요가 없습니다. 카드 위치는 누가 옮겨놓은 게 아니라 내용을 그대로 비춘 것이니까요.

카드를 하나 열면

카드 하나가 “일 하나”입니다. tuckit은 이걸 슬라이스(Slice)라고 부릅니다. 이름은 중요하지 않고, 안에 뭐가 들었는지가 중요합니다. 칸이 네 개 있습니다.

무엇을 만들 건지. 화면에는 Spec이라고 표시됩니다. 아직 안 정했으면 비워두세요. 비어 있는 게 “아직 안 정했음”이라는 표시입니다. 급한 마음에 한 줄 적어두면 AI가 정해진 줄 알고 그냥 만들기 시작합니다.

건드리면 안 되는 것. 화면에는 Constraints. “결제 관련 코드는 손대지 말 것”, “로그인 화면 디자인은 그대로 둘 것” 같은 문장을 적는 칸입니다. AI가 이 일을 이어받을 때 제일 먼저 읽습니다.

뭘 보면 된 건지. 화면에는 Done when. 무엇을 봐야 “끝났다”고 할 수 있는지를 한 문장으로 적는 칸입니다. “테스트를 돌린다”는 시키는 말이라, 그걸 다 해도 기능은 여전히 망가져 있을 수 있습니다. “저장하고 다시 열어도 날짜가 그대로다”는 본 것을 적은 말이고, 틀렸다는 게 드러날 수 있습니다. 일을 시작하기 전에 적어야, 못 맞출 수 있는 기준이 됩니다.

실제로 본 것. 화면에는 Evidence. 누가 가서 확인한 다음에 채우는 칸입니다. tuckit은 이 내용이 맞는지 판단하지 않습니다. 테스트를 대신 돌려주지도 않고요. 대신 이 칸이 비어 있는 동안에는 카드를 “끝났다”로 넘기지 못하게 막습니다.

그 아래에는 무슨 일이 있었는지가 기록(Activity)으로 쌓입니다. 뭘 시도했고 뭐가 안 됐는지 같은 것들이요.

어디에 넣을지 모르겠을 때

뭔가 발견했는데 어디에 넣을지 모르겠을 때가 있습니다. 제목만 적어서 던져두면 Inbox에 쌓입니다. 나중에 몰아서 정리하면 되고, 정리했다가 다시 빼도 됩니다. 되돌릴 수 없는 동작은 없습니다.

그래서 뭐가 달라지나요

AI에게 “이거 해줘”라고 시키면, AI가 일을 시작하기 전에 이 보드를 먼저 읽습니다. 지금까지 뭘 만들었는지, 뭘 하기로 했는지, 뭘 건드리면 안 되는지가 거기 적혀 있기 때문에 짐작이 아니라 이미 정한 것에서 시작합니다.

일이 끝나면 AI가 다시 보드에 적습니다. 뭘 했는지, 뭐가 막혔는지, 다음에 뭘 하기로 했는지. 창을 닫아도 남아 있고, 동료의 AI나 다음에 쓰는 다른 AI도 그대로 읽습니다.

읽고 쓰는 건 양쪽 다 할 수 있습니다. AI가 할 수 있는 건 사람도 웹 화면에서 할 수 있고, 반대도 마찬가지입니다. 한쪽이 쓰고 다른 쪽이 받아가는 구조가 아니라 같은 화면을 같이 씁니다.

설치하면 따라오는 것

보드가 있다고 저절로 그렇게 되지는 않습니다. AI가 읽을 수 있는 보드는, 여전히 사람이 손으로 채우는 보드입니다.

그래서 tuckit의 나머지 절반은 AI에 한 줄로 설치하는 것이고, 거기 들어가는 건 일하는 방식입니다. 세 가지가 같이 들어옵니다.

• 연결이 이미 되어 있습니다. 따로 등록할 서버도, 창마다 들고 다닐 토큰도 없습니다.
• 두 순간이 생깁니다. 세션이 시작될 때 AI를 git log가 아니라 보드로 보내고, 끝나기 전에 그날 발견한 것들을 카드로 만듭니다. 목록을 먼저 보여주고 나서요.
• 이름이 붙은 작업 방식 한 묶음. 뭘 만들지 정하기, 만들기, 다 됐다고 하기 전에 실제로 확인하기, 머지하기, 끝나고 정리하기. 각각이 만들어낸 것을 마크다운 파일이 아니라 카드에 적습니다. 다음 세션이 그 파일을 못 찾을 일이 없게요.

세 번째를 대개 가볍게 보십니다. 보드를 읽을 수 있는 AI와, 보드를 실제로 맞는 상태로 남겨두는 AI의 차이가 여기서 갈립니다.

Claude Code, Codex CLI, Antigravity 셋 다 똑같은 묶음을 받습니다. 설치하면 따라오는 것에 하나씩 적어뒀습니다.

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

코딩 에이전트. 코드를 직접 고치는 AI입니다. Claude Code, Codex CLI, Antigravity 같은 것들이요. 채팅창에 코드를 보여주기만 하는 게 아니라 파일을 직접 열어서 고치고 실행까지 합니다. 이 사이트에서는 줄여서 “에이전트”라고 씁니다.

MCP. 에이전트가 바깥 도구를 쓸 때 지키는 공용 규격의 이름입니다. tuckit이 이 규격을 따르기 때문에, 누가 따로 연동을 만들지 않아도 에이전트가 보드를 읽고 쓸 수 있습니다. 이름만 알면 되고 내용은 몰라도 됩니다.

이 두 단어 말고는 새로 배울 게 별로 없습니다. 웹 화면만 쓸 거라면 둘 다 몰라도 됩니다.

어디로 갈까요

일단 해보고 싶어요가입하고, AI를 붙이고, AI가 첫 카드를 채우는 걸 보는 데까지. 10분 정도 걸립니다.

세션을 여러 개 돌리고 있어요창 여러 개가 각각 뭘 했는지 모르겠고, 내가 만든 게 뭔지 설명하기 어려울 때.

팀에 도입할지 보는 중이에요팀원들이 배워야 할 것 전부와, 없어서 못 하는 일들.

Jira를 쓰고 있어요뭐가 뭐에 대응하는지, 뭘 포기하게 되는지, 언제 Jira에 남는 게 맞는지.

tuckit이 하지 않는 것

• 대화 기록을 기억해주는 기능이 아닙니다. 특정 대화나 특정 AI 제품에 묶여 있지 않습니다. 쓰던 AI를 바꿔도 보드는 그대로입니다.
• 일반적인 이슈 관리 도구가 아닙니다. 스프린트도, 마감일도, 담당 공수도 없습니다. Jira를 쓰고 있다면에 없는 것들을 다 적어뒀습니다.
• AI 전용이 아닙니다. 웹 화면은 개발자용 디버깅 창이 아니라 그냥 쓰라고 만든 화면입니다.

아직 안 쓴 것

찾다가 시간 버리지 마시라고 미리 적어둡니다.

• 변경 내역 페이지.

제품 소개가 필요하다면 tuckit.dev가 그쪽입니다.