같은 Jira, 다른 워크플로우

시작하며

개발자로 일하면서 업무 관리 도구로 Jira를 사용하는 경우가 많았습니다. 그런데 같은 Jira를 쓰더라도 팀마다 운영 방식이 꽤 다릅니다.

정직원으로 일할 때와 프리랜서로 외주 프로젝트에 투입됐을 때, 동일한 Jira라는 도구를 썼지만 티켓을 다루는 방식은 완전히 달랐습니다.

하나는 기능 하나를 직군별로 쪼개서 여러 티켓으로 관리하는 방식이었고, 다른 하나는 기능 하나에 티켓 하나를 두고 담당자를 바꿔가며 릴레이하는 방식이었습니다.

이 글에서는 두 방식의 차이를 정리하고, 어떤 상황에 어떤 방식이 더 맞는지를 경험 기반으로 풀어보겠습니다.

방식 A: 티켓 분리형

정직원 시절 경험한 방식입니다. 하나의 기능을 구현하기 위해 직군별로 티켓을 분리하고, 티켓 간 연관관계를 설정해서 의존성을 관리합니다.

구조

[Epic] 사용자 프로필 개편
  ├── [Task] PRD 문서 작성          → 담당: PM
  ├── [Task] 디자인                 → 담당: 디자이너
  ├── [Task] 백엔드 API 개발        → 담당: 백엔드 개발자
  └── [Task] 프론트엔드 개발         → 담당: 프론트엔드 개발자

연관관계 설정

티켓을 분리한 뒤에는 각 티켓 사이에 의존성을 설정합니다. Jira의 Link 기능을 사용해서 "이 티켓은 저 티켓이 끝나야 시작할 수 있다"는 관계를 명시적으로 걸어두는 방식입니다.

┌─────────────────────────────────────────────────┐
│  Linked Issues                                  │
├─────────────────────────────────────────────────┤
│                                                 │
│  [Design] ── is blocked by ──> [PRD]            │
│                                                 │
│  [FE Dev] ── is blocked by ──> [Design]         │
│                                                 │
│  [BE API] ── is blocked by ──> [PRD]            │
│                                                 │
│  [FE Dev] ── relates to ──> [BE API]            │
│                                                 │
└─────────────────────────────────────────────────┘

이렇게 설정해두면 각 티켓의 상세 화면에서 "이 티켓이 왜 아직 시작 못 하고 있는지"가 바로 보입니다. 예를 들어 프론트엔드 티켓을 열면 Blocked by: [디자인] - In Progress라고 표시되고, 디자인이 Done으로 바뀌는 순간 블로커가 해제됩니다.

흐름

연관관계가 설정된 상태에서 실제 작업 흐름은 다음과 같습니다.

                ┌──> [Design] ──> [FE Dev] ──┐
[PRD] ──────────┤                            ├──> Done
                └──> [BE API] ───────────────┘

각 티켓은 독립적으로 상태가 관리됩니다. PRD가 끝나면 디자인과 백엔드가 동시에 시작할 수 있고, 누가 어디서 막혀있는지가 보드에서 바로 보입니다.

보드에서 보면 이런 모습입니다.

┌─ To Do ──────┐  ┌─ In Progress ─┐  ┌─ Done ────┐
│              │  │               │  │           │
│  FE          │  │  Design       │  │  PRD      │
│  (Blocked)   │  │               │  │           │
│              │  │  BE API       │  │           │
│              │  │               │  │           │
└──────────────┘  └───────────────┘  └───────────┘

디자인이 완료되면 프론트엔드 티켓의 블로커가 풀리면서 자연스럽게 작업 가능 상태가 됩니다.

특징

이 방식의 핵심은 사람이 아니라 시스템이 워크플로우를 가이드한다는 점입니다. 누군가가 "디자인 끝났나요?"라고 물어볼 필요 없이, 블로커가 해제되는 순간 알림이 오고 자연스럽게 다음 작업이 시작됩니다.

• 각 직군별 작업 범위와 진행 상황이 명확하게 분리됨
• blocked by, relates to 같은 연관관계로 병목 지점을 바로 파악 가능
• 각 담당자가 자기 티켓에 코멘트, 시간 추적 등 히스토리를 독립적으로 관리
• 나중에 "이 기능의 디자인은 누가, 언제 했지?" 같은 추적이 쉬움

방식 B: 담당자 릴레이형

프리랜서로 외주 프로젝트에 투입됐을 때 경험한 방식입니다. 하나의 기능에 하나의 티켓을 만들고, 작업 단계에 따라 담당자를 넘겨가며 진행합니다.

구조

[Task] 사용자 프로필 개편
  └── 담당자: PM → 디자이너 → 백엔드 → 프론트엔드 (순차 변경)

흐름

[사용자 프로필 개편] 담당: PM
        │
        │  담당자 변경
        ▼
[사용자 프로필 개편] 담당: 디자이너
        │
        │  담당자 변경
        ▼
[사용자 프로필 개편] 담당: 백엔드
        │
        │  담당자 변경
        ▼
[사용자 프로필 개편] 담당: 프론트엔드
        │
        ▼
      완료

하나의 티켓이 사람 사이를 순차적으로 이동하는 구조입니다. 보드에서는 항상 티켓 하나만 보이기 때문에 깔끔하지만, 기획 코멘트, 디자인 피드백, 개발 이슈가 한 티켓에 전부 섞이다 보니 내부적으로 필요한 정보를 찾으려면 긴 히스토리를 스크롤해야 합니다.

특징

• 관리가 단순하고, 보드가 깔끔함
• 전체 흐름이 한 티켓 안에 담겨있어 맥락 파악이 쉬울 수 있음
• 단, 담당자 변경 히스토리가 묻히기 쉬움

두 방식 비교

실제로 겪은 차이

담당자 파악의 차이

분리형에서 가장 좋았던 건 누가 무엇을 해야 하는지가 명확했다는 점입니다. 각 티켓에 담당자가 고정되어 있으니, 보드만 봐도 "디자인은 누가 하고 있고, 백엔드는 어디까지 진행됐는지"가 바로 보였습니다. 문제가 생겼을 때도 해당 티켓을 열면 담당자, 코멘트, 변경 히스토리가 전부 남아있어서 추적이 쉬웠습니다.

릴레이형에서는 이 부분이 불편했습니다. 진행 중일 때는 담당자가 바뀌는 타이밍이 명확하지 않아서, 서로 상대방이 하고 있겠거니 하고 넘어가는 상황이 생겼습니다. 결국 "끝났나요?"를 슬랙으로 물어보는 소통 비용이 추가로 발생했습니다.

끝난 뒤에도 마찬가지였습니다. 티켓 하나에 담당자가 계속 바뀌다 보니 현재 담당자만 보이고, 이전에 누가 어떤 부분을 담당했는지는 히스토리를 뒤져야 알 수 있었습니다. 프로덕션에서 버그가 터졌을 때 "이 기능의 백엔드는 누가 개발했지?"를 빠르게 찾아야 하는데, 티켓 코멘트를 하나하나 읽어야 했습니다.

특히 프리랜서로 투입된 입장에서는 이게 더 힘들었습니다. 정직원이 아니다 보니 팀원 전체를 알지 못하고, Jira의 특정 메뉴나 필터 접근이 제한된 경우도 있었습니다.

릴레이형이 잘 돌아갈 때

릴레이형이 무조건 나빴던 건 아닙니다. 만약 팀 내에서 담당자가 바뀔 때마다 코멘트를 남기는 규칙이 잘 지켜진다면, 티켓 하나에 기획부터 개발까지 전체 흐름이 담기기 때문에 오히려 분리형보다 맥락 파악이 쉬울 수 있습니다. 여러 티켓을 돌아다닐 필요 없이 하나만 읽으면 되니까요.

다만 이건 결국 사람에 의존하는 방식입니다. 히스토리를 꼼꼼하게 남기는 건 시스템이 강제하는 게 아니라 담당자의 습관에 달려있기 때문에, 어떤 티켓은 맥락이 잘 정리되어 있지만 어떤 티켓은 담당자만 바뀌고 코멘트가 거의 없는 경우가 많았습니다.

스프린트 리뷰와 업무 정리

스프린트가 끝나고 리뷰할 때도 차이가 있었습니다. 분리형에서는 직군별로 완료한 티켓 수와 스토리 포인트를 바로 확인할 수 있었습니다. 릴레이형에서는 "이번 스프린트에 프론트엔드가 얼마나 기여했는가"를 수치로 보여주기가 어려웠습니다.

분리형에서는 내가 담당한 티켓이 그대로 내 업무 이력으로 남았습니다. 평가 기간에 "지난 분기에 뭘 했지?"를 정리할 때, 내 이름으로 된 티켓 목록만 필터링하면 됐습니다. 릴레이형에서는 내가 관여한 티켓을 찾으려면 담당자 변경 히스토리를 하나하나 추적해야 했습니다.

어떤 상황에 어떤 방식이 맞을까

두 방식 중 무조건 하나가 정답인 건 아닙니다. 팀의 상황에 따라 적합한 방식이 다릅니다.

티켓 분리형이 맞는 경우

• 직군이 2개 이상이고, 의존성 관리가 필요한 팀
• 스프린트 단위로 직군별 생산성을 추적하고 싶은 팀
• 의존성이 복잡한 기능을 자주 다루는 팀
• 프로세스가 어느 정도 성숙해서 티켓 관리에 투자할 여력이 있는 팀

담당자 릴레이형이 맞는 경우

• 팀 규모가 작고(3~5명), 구두 커뮤니케이션으로 충분한 팀
• 작업 흐름이 거의 항상 순차적인 팀
• Jira 관리 자체에 시간을 쓰고 싶지 않은 팀
• 빠르게 치고 빠지는 단기 프로젝트

마무리

같은 Jira를 쓰더라도 팀이 어떻게 운영하느냐에 따라 경험이 완전히 달라집니다.

정직원일 때는 프로세스가 체계적으로 잡혀있어서 당연하다고 생각했던 것들이, 프리랜서로 다른 팀에 들어가보니 전혀 당연하지 않았습니다. 도구는 결국 도구일 뿐이고, 중요한 건 팀이 어떤 방식으로 일하기로 합의했는가입니다.

어떤 방식을 선택하든, "왜 이렇게 하는가"를 팀원 모두가 이해하고 있다면 그게 그 팀에게는 맞는 방식이라고 생각합니다.