지라에서 옮길 때 실제로 깨지는 것들 · 워크플로·첨부·코멘트

이관에서 진짜 어려운 건 옮기는 게 아닙니다

지라(Jira)에서 다른 도구로 옮길 때, 사람들이 걱정하는 건 보통 "데이터가 다 옮겨질까"입니다. 그런데 실제로 해보면 행을 옮기는 건 제일 쉬운 부분입니다. CSV로 내보내고 열을 맞춰 넣으면 끝나니까요.

어려운 건 그다음입니다. 옮긴 뒤에 보면 숫자는 다 맞는데 일이 굴러가지 않습니다. 지라에서만 의미를 갖던 것들이 이사 과정에서 조용히 빠지기 때문입니다. 무엇이 빠지는지 미리 알면 이관은 반나절 일입니다.

1. 워크플로 · 상태 이름은 옮겨져도 규칙은 안 옮겨집니다

지라의 강점은 워크플로를 원하는 대로 만들 수 있다는 점입니다. In Review에서 Done으로 갈 때 승인자를 강제한다든지, 특정 조건에서만 전이를 허용한다든지요.

CSV에 담기는 건 그 순간의 상태 이름 하나입니다. In Review라는 글자는 옮겨지지만, 거기 붙어 있던 "누가 언제 넘길 수 있는가"라는 규칙은 파일 어디에도 없습니다.

그래서 이관 전에 정해야 할 게 있습니다. 지라에서 쓰던 상태 이름을 새 도구의 상태에 어떻게 대응시킬 것인가입니다.

지라에서 쓰던 상태(예시)	buggle 상태	성격
Open / To Do / Backlog	미수정	파트별 작업 상태
In Progress	진행중	파트별 작업 상태
In Review(코드리뷰)	작업완료	고쳤지만 아직 배포 전
Resolved / Deployed	배포/반영	파트 종료
Won't Fix / Duplicate	작업없음(사유 필수)	작업 없이 파트 종료
Ready for QA	검수요청	이슈 전체가 검수 대기
Closed	확인완료	이슈 종결
Reopened	재수정요청	검수에서 반려

여기서 한 번 헷갈리는 지점이 있습니다. 지라의 상태는 이슈 하나에 한 개지만, buggle은 파트(기획·개발·디자인 등)마다 상태가 따로 있고 그 위에 이슈 전체의 검수 상태가 얹힙니다. 그래서 Ready for QA처럼 이슈 전체를 뜻하는 상태와 In Progress처럼 특정 담당의 상태는 다른 층으로 들어가야 합니다. 표를 한 번 그려두면 그다음은 기계적입니다.

2. 계층 구조 · Epic / Sub-task는 평평해집니다

지라를 오래 쓴 프로젝트는 대개 Epic → Story → Sub-task 계층이 있습니다. CSV에는 부모 키가 열로 들어가지만, 옮겨갈 도구에 같은 계층이 없으면 전부 같은 층의 이슈가 됩니다.

이게 손실인지 아닌지는 그 계층을 무엇에 쓰고 있었느냐에 달렸습니다.

• 분류에 쓰고 있었다면 · 예: Epic이 "결제", "회원가입" 같은 기능 묶음이었다면, 손실이 아닙니다. 그건 화면이나 라벨로 옮기는 게 오히려 맞습니다. buggle이라면 화면 카탈로그에 등록하고 이슈를 연결하면 됩니다.
• 한 버그를 파트별로 쪼개는 데 쓰고 있었다면 · 예: 부모가 "장바구니 수량 오류", 서브태스크가 "개발 수정", "기획 확인"이었다면, 이건 파트로 옮깁니다. 이슈 하나 안의 파트가 정확히 같은 역할을 합니다.

앞의 경우인데 부모-자식을 그대로 이슈 두 건으로 만들면, 이관 후에 이슈 수가 두 배로 부풀고 검수할 게 두 배가 됩니다. 이관 전에 이 구분부터 하는 걸 권합니다.

3. 첨부파일 · 링크만 옮겨지고 파일은 안 따라옵니다

이게 가장 자주 놓치는 항목입니다. 지라 CSV의 첨부 열에는 보통 파일 자체가 아니라 지라 서버의 URL이 들어갑니다. 그 URL은 지라 로그인이 있어야 열립니다.

그래서 이관 후 지라 구독을 해지하면, 옮겨간 이슈의 스크린샷이 전부 죽습니다. 버그 이슈에서 스크린샷이 빠지면 사실상 본문이 없는 것과 같습니다.

대응은 셋 중 하나입니다.

1. 구독을 겹쳐 두기 · 이관 후 최소 한 달은 지라를 살려두고, 그동안 활발한 이슈의 이미지만 새 도구에 다시 올립니다. 가장 현실적입니다.
2. 활성 이슈만 이미지 재첨부 · 닫힌 이슈의 스크린샷은 대개 다시 안 봅니다. 열려 있는 것만 챙기면 양이 확 줄어듭니다.
3. 전부 내려받아 재업로드 · 스크립트를 짜야 하고, 이슈-파일 대응을 다시 맞춰야 합니다. 이슈가 수천 건이 아니면 품이 더 듭니다.

4. 코멘트 · 대화는 옮겨도 맥락은 안 옮겨집니다

코멘트는 지라 표준 CSV로 잘 안 떨어지거나, 떨어져도 한 셀에 뭉쳐 나옵니다. 작성자와 시각이 섞이면 읽을 수 없는 덩어리가 됩니다.

여기서 판단이 필요합니다. 코멘트 대부분은 "지금 누구 차례인가"를 확인하는 대화입니다. 파트별 담당과 상태가 제대로 옮겨졌다면 그 대화는 다시 읽을 이유가 없습니다. 반면 재현 스텝과 판단 근거("이건 사양대로 동작하는 게 맞아서 안 고칩니다")는 자산입니다.

그래서 저희가 권하는 순서는 이렇습니다. 코멘트 전체를 옮기려 하지 말고, 열려 있는 이슈의 코멘트만 훑어서 재현 스텝과 결정 근거를 본문으로 끌어올린 뒤 옮깁니다. 이관은 사실 이력을 정리할 좋은 핑계이기도 합니다.

5. 사용자 계정 · 담당자 이름은 문자열로 들어옵니다

지라 CSV의 담당자는 계정 ID나 표시 이름입니다. 새 도구의 실제 사용자와 자동으로 이어지지 않습니다.

이관 전에 사람 대응표를 만들어두면 됩니다. 이때 같이 정리할 것: 이미 퇴사했거나 프로젝트를 떠난 사람에게 붙은 이슈를 누구에게 넘길지. 이관 후 목록을 열었을 때 "담당 없음"이 잔뜩 보이는 것보다, 옮기기 전에 정하는 편이 훨씬 빠릅니다.

옮기는 방법은 두 가지입니다

정리표가 준비됐다면 실제 이관은 짧습니다.

• 업로드 마법사 · 지라에서 내보낸 CSV를 올리고, 열을 buggle 항목에 맞춰 지정합니다. 위에서 만든 상태 대응표를 여기서 그대로 씁니다.
• AI 도구(MCP)로 밀어넣기 · 이미 Claude 같은 AI 도구를 쓰고 있다면, buggle MCP를 연결해 AI에게 지라 데이터를 읽어 이슈로 만들라고 시킬 수 있습니다. 열이 지저분하거나 여러 소스에 흩어져 있을 때 유리합니다.

체크리스트 형태로 한 번 더 훑고 싶다면 엑셀·Jira 이슈를 옮길 때 체크리스트에 정리해 두었습니다.

옮기지 않는 게 맞는 경우

솔직히 적자면, 조직 전체가 지라를 쓰고 있고, 워크플로 커스터마이징이 실제로 팀의 규칙을 담고 있고, 컨플루언스·소스 저장소와 엮여 돌아가고 있다면 옮기지 않는 게 맞습니다. 지라가 무거운 건 아무 이유 없이 무거운 게 아닙니다.

옮겨서 이득을 보는 쪽은 대체로 이렇습니다. 지라의 기능 중 실제로 쓰는 건 이슈 목록과 상태 변경 정도인데 세팅과 좌석 비용은 전부 내고 있는 팀, 프로젝트마다 고객사를 검수에 불러야 하는 팀, 화면 단위로 품질을 봐야 하는 팀. 소규모 외주팀 기준으로 정리한 글도 참고하실 수 있습니다.