Jira를 쓰고 있다면

tuckit을 찾아오는 사람들은 대개 이미 다른 걸 쓰고 있고, 대개 Jira입니다. 이 페이지는 그 비교인데, 팀을 설득하는 데도 말리는 데도 똑같이 쓸 수 있게 썼습니다.

차이가 실제로 어디에 있나

“Jira는 무겁고 tuckit은 가볍다”고 말하기 쉽지만, 팀의 시간을 잡아먹는 부분은 거기가 아닙니다. 두 가지를 정확히 짚고 가겠습니다.

Jira에서 비싼 건 배우는 게 아니라 합의하는 겁니다. 에픽과 스토리 포인트는 어려운 개념이 아닙니다. 여덟 명이 그걸 똑같은 방식으로 쓰게 만들고, 조직 개편을 세 번 겪고도 계속 그렇게 쓰게 만드는 게 어렵고, 이건 끝나지 않습니다. 설정할 수 있는 개념 하나하나가 계속 진행 중인 협상입니다. tuckit에는 말이 네 개뿐이고 그중 설정할 수 있는 게 하나도 없어서, 합의할 게 거의 남지 않습니다. 여기가 차이의 전부입니다.

“AI가 쓸 수 있다”는 건 차이가 아닙니다. Jira에도 있고, Atlassian은 2026년에 Jira 안에 에이전트를 넣었습니다. “AI가 쓸 수 있는 관리 도구”라는 소개를 들으셨다면 그건 이제 기본 사양입니다. 실제 차이는 AI가 써넣는 모델이 작아서, 사람이 리포트를 따로 만들지 않고 한눈에 읽을 수 있다는 쪽에 있습니다.

둘 다 지금 겪는 문제가 아니라면 Jira에 남는 게 맞고, 이 페이지의 나머지가 그렇게 말할 근거를 드립니다.

대응표

Jira	tuckit	비고
프로젝트	조직 또는 영역	어떻게 쪼개느냐에 따라. 프로젝트가 여러 개라면 참고
에픽	(정확히 대응 없음)	오래 가는 주제는 영역, 큰 결과물 하나는 카드 하나
스토리 / 작업 / 버그 / 개선	카드	전부 하나입니다. 이슈 종류라는 개념이 없습니다
하위 작업	단계	순서 있는 할 일. todo / doing / done / dropped
상태 + 워크플로	Status + Stage	상태는 세 개 고정, 진행 칸은 계산되고 설정 불가
해결 유형	dropped, 또는 기록 한 줄	분류 체계 없음
담당자	담당자	같습니다
보고자	자동 기록	AI가 사람 계정으로 연결되므로, AI가 쓴 것도 그 사람 이름으로 남습니다
댓글	기록(Activity)	계속 쌓이기만 하는 목록
라벨	태그
컴포넌트	태그, 또는 영역
우선순위	Priority, 1부터 5까지	숫자는 제품이 정하고, 각 숫자가 무슨 뜻인지는 조직이 직접 씁니다
스토리 포인트 / 공수 / 시간 기록	(없음)
스프린트, 반복 주기, 속도	(없음)
릴리스 버전	(없음)	릴리스는 코드 저장소의 태그로 관리합니다
마감일	(없음)
첨부 파일	(없음)	링크를 Spec이나 기록에 붙여넣습니다
사용자 정의 필드	(없음)	Spec, Constraints, 기록이 전부 자유 입력입니다
JQL 검색	검색 필터	영역, 상태, 태그, 담당자, 본문
대시보드와 리포트	(없음)
권한 체계	조직 구성원	조직에 속한 사람이 그 조직을 봅니다
자동화 규칙	(기본 제공 없음)	AI에게 시키되, 두 번 돌아도 안전하게 하는 장치는 있습니다
중복 연결	duplicate_of	유일한 연결 종류입니다

빈칸이 이 페이지의 핵심입니다. 팀이 지금 의견을 유지하고 있는 개념 아홉 개가 아예 없다는 게 절약이고, 그중 둘이 팀에 꼭 필요하다면 그게 비용입니다.

포기하게 되는 것

회의에서 질문받으실 테니 그대로 적어둡니다.

• 날짜에 관한 모든 것. 마감일도, 스프린트도, 릴리스도, 번다운도 없습니다. tuckit 보드는 다음에 뭘 해야 하나에 답하지, 14일까지 되나에는 답하지 않습니다.
• 리포트. 리포트 빌더도 대시보드도 프로젝트 간 집계도 슬라이드 내보내기도 없습니다. 위에 보고하려고 지금 요약을 만들고 계신다면 그건 계속 손으로 하시게 됩니다.
• 공수와 시간 기록. 청구할 근거도, 예측할 근거도 나오지 않습니다.
• 절차 강제. 아무것도 안 적힌 카드를 바로 “끝냄”으로 바꿔도 아무도 안 막습니다. 상태를 비출 뿐 통제하지 않습니다.
• 비개발 조직을 같은 도구에 넣는 것. 말이 소프트웨어 만드는 일에 맞춰져 있습니다. 마케팅이나 고객 지원 업무는 여기에 담기지 않습니다.
• 가져오기 기능. 아래에서 설명합니다.

가져오기 기능은 없습니다

Jira 내보내기를 읽어들이는 기능이 없고, 만드는 게 오히려 나쁜 선택이라고 봅니다. Jira 프로젝트의 가치는 tuckit에 없는 필드들에 대부분 들어 있습니다. 상태, 포인트, 스프린트, 사용자 정의 필드요. 그걸 가져오면 무엇을 만들지 칸이 전부 빈 카드 수백 개가 생기고, 그 보드는 여기 아무것도 안 정해졌음으로 읽히다가 한 주 만에 버려집니다.

대신 이렇게 하면 됩니다. 지금 굴러가고 있는 것만 옮기세요. 실제로 움직이는 여덟 개나 열두 개를 손으로 카드로 만들고, 그중 지뢰가 있는 셋에 “건드리면 안 되는 것”을 제대로 적습니다. 한나절이면 됩니다. Jira는 기록을 그대로 갖고 계속 읽히고, 이건 이전이 아니라 팀 하나를 나란히 굴려보는 것입니다.

아무한테도 안 물어보고 시험해보기

허락도 예산 이야기도 필요 없는 방법입니다.

1. 저장소 하나. 사람 한둘.
2. 영역 두세 개. 지금 그 코드 얘기할 때 쓰는 말 그대로.
3. 만드는 카드마다 “건드리면 안 되는 것”을 진짜로 적습니다. 다들 건너뛰는 부분이고 값을 하는 부분입니다.
4. 2주.

그리고 딱 두 개만 봅니다. 이 두 개가 위에서 한 주장 두 개입니다.

• 누가 누구에게 보드를 설명해야 했나? 팀원이 처음 열어보고 아무 안내 없이 제대로 읽었다면, 합의 비용 이야기는 이 팀에서 사실입니다.
• 결정이 살아남았나? 일주일 지나서 보드를 열어보고, “프론트는 다음에 하자”가 보드에 있는지 누군가의 터미널에 있는지 봅니다. 보드에 없다면 도구가 실패한 게 아니라 적어두는 습관이 실패한 것이고, 진짜로 판단해야 할 대상이 그 습관입니다.

10분 따라하기로 1번까지 갑니다.

Jira에 남는 게 맞는 경우

이야기해본 팀들을 놓고 보면, 규모나 연차보다 이 질문 하나가 훨씬 깔끔하게 갈랐습니다.

팀 바깥의 누군가에게 날짜를 약속했습니까?

약속했다면 (계약이든, 출시 일정이든, 규제 기한이든) 날짜와 인력과 번다운은 군더더기가 아니라 그게 일 자체입니다. 그걸 다루지 않는 도구는 한 달 안에 우회됩니다. 약속을 관리하는 도구는 그대로 두세요.

이런 경우에도 Jira에 남으시는 게 맞습니다.

• 규정 대응을 위한 이력이 필요하거나, 이슈별 접근 제어가 필요할 때.
• 비개발 조직이 같은 도구에 있고 하나의 화면이 필요할 때.
• 리포트 체계가 Jira 데이터 위에 올라가 있고 거기 의존하는 사람이 있을 때.
• 팀의 절차 자체가 일을 굴러가게 하고 있을 때. 잘 돌아가는 스크럼은 작은 어휘보다 가치 있습니다.

둘 다 참인 것도 충분히 말이 됩니다. 이야기해본 회사 중 여럿이 날짜를 약속한 사람들을 위한 도구와 코드를 쓰는 사람들을 위한 가벼운 도구를 같이 굴립니다. tuckit은 날짜를 약속하는 쪽이 되려고 하지 않습니다.

어디로 갈까요

• 팀에 도입하려면: 배울 것 전부.
• 10분 따라하기: 2주 시험은 여기서 시작합니다.
• 화면에 보이는 것들: 말 네 개를 자세히.