JIRA는 코드의 흐름과 짝지어 가는 작업 단위 — 이슈/티켓 — 의 흐름이다. Sprint, ticket lifecycle, Git/GitHub 연동이 한 짝으로 움직이면 매일의 컨텍스트 전환 비용이 줄어든다.
이슈와 워크플로우
JIRA의 핵심은 두 가지로 요약된다 — 이슈와 그 위의 워크플로우.
이슈는 작업의 단위다. 각 이슈는 type(Story, Task, Bug, Epic, Subtask), 상태, 담당자, 그리고 자유로운 메타데이터(라벨, 우선순위, 스토리 포인트)를 갖는다. JIRA를 쓴다는 건 결국 이 이슈를 만들고, 묶고, 상태를 전이시키는 일의 누적이다.
워크플로우는 이슈가 거치는 상태 전이 규칙이다. 가장 단순한 흐름은 다음과 같다.
flowchart LR
Open[Open] --> InProgress[In Progress]
InProgress --> InReview[In Review]
InReview --> Done[Done]
InReview --> InProgress
Open --> Closed[Closed]
각 화살표가 한 전이에 해당한다. 팀 프로세스에 따라 상태와 전이 규칙을 커스터마이징하는데, 단순할수록 사람이 따라가기 쉽고, 복잡할수록 자동화로만 다룰 만한 영역이 된다.
워크플로우 디자인의 핵심은 상태 수를 절제하는 것이다. “Pending Review”, “Ready for QA”, “QA in Progress”, “Ready for Release” 같이 미세하게 쪼개진 상태가 늘면 매일 상태를 옮기는 데 더 많은 시간을 쓰게 되고, 결국 사람들이 상태를 무시하기 시작한다.
Sprint
Sprint는 시간 박스 안에 이슈 묶음을 두는 단위다. 보통 1주에서 2주 길이가 흔하고, 그 시간 안에 묶인 이슈들이 끝나는 것을 목표로 한다.
Sprint의 라이프사이클은 세 단계로 나뉜다.
- Sprint Planning: 백로그에서 이슈를 골라 다음 Sprint에 담는다. 팀 capacity와 이슈 estimate를 비교해 무리하지 않는 양으로 잡는다.
- Sprint 진행: 이슈를 In Progress → In Review → Done으로 전이시킨다. 매일 standup으로 진행 상황과 막힘을 공유한다.
- Sprint Review/Retro: 끝에서 결과를 확인하고 회고한다. 무엇이 끝났고, 무엇이 carry over 됐고, 다음 Sprint를 어떻게 더 잘할지.
Sprint scope creep — 진행 중에 이슈가 계속 추가되는 — 이 가장 흔한 문제다. 한번 Planning한 scope를 지키지 못하면 Sprint가 단순한 시간 분할로만 남고, planning의 의미가 약해진다. 긴급 이슈가 들어와야 한다면 같은 양의 다른 이슈를 빼는 트레이드오프를 명시하는 게 안전판이다.
이슈 계층
대부분의 팀이 다음 계층을 사용한다.
| 계층 | 의미 | 예시 |
|---|---|---|
| Epic | 큰 단위의 작업 묶음, 보통 여러 Sprint에 걸침 | “결제 시스템 v2 마이그레이션” |
| Story | 사용자 가치 단위. 한 Sprint 안에서 끝남 | “사용자가 카드 정보를 저장할 수 있다” |
| Task | 기술적 작업 단위 | “결제 API 엔드포인트 구현” |
| Bug | 결함 보고 | “결제 실패 시 에러 메시지 누락” |
| Subtask | Story/Task 안의 더 작은 작업 단위 | “결제 API 단위 테스트 작성” |
이 계층은 강제가 아니라 컨벤션이라, 팀이 자기 흐름에 맞춰 변형해서 쓴다. Story와 Task의 구분이 모호한 팀은 둘을 합쳐 쓰기도 하고, Subtask 대신 체크리스트로 처리하는 팀도 있다.
핵심은 Epic과 Story의 분리다. 한 Sprint에 안 들어가는 큰 작업은 Epic으로 묶고 Story 단위로 쪼개야, Sprint planning에서 다룰 수 있는 단위가 된다.
Git/GitHub 연동
JIRA가 Git/GitHub과 짝지어 가면 이슈와 코드 변경이 자동으로 묶인다. 컨벤션은 단순하다.
branch 이름에 이슈 키 포함
feature/PROJ-123-add-search
PROJ-123이 이슈 키인 것을 JIRA가 인식한다.
commit 메시지에 이슈 키
PROJ-123: add search endpoint
이 commit이 PROJ-123 이슈에 속한다는 것을 JIRA가 자동 연결한다.
PR title 또는 body에 이슈 키
PROJ-123: Add search endpoint
closes PROJ-123
PR이 열리면 JIRA가 이슈 화면에 PR 링크를 노출한다. PR 상태(open/merged) 변화도 자동으로 동기화된다.
Smart commits는 commit 메시지에서 이슈 상태를 직접 전이시키는 문법이다. PROJ-123 #close나 PROJ-123 #time 2h처럼 적으면, commit이 머지될 때 이슈가 close되거나 작업 시간이 기록된다.
이 연동의 가장 큰 가치는 컨텍스트 손실 방지다. 이슈 화면에서 commit·PR을 바로 보고, GitHub PR에서 이슈 링크로 바로 이동할 수 있으면, “이 코드가 왜 이렇게 됐는가"를 추적하는 비용이 크게 줄어든다.
JIRA Automation
JIRA에는 이슈 상태 전이를 자동으로 트리거하는 룰 엔진이 있다.
자주 쓰이는 패턴 몇 가지:
- PR open 시 In Review 전이: 이슈에 연결된 PR이 열리면 이슈를 자동으로 In Review로 옮김
- PR merged 시 Done 전이: PR이 main에 머지되면 이슈를 Done으로
- Sprint 종료 시 미완료 이슈 carry over: 완료되지 않은 이슈를 다음 Sprint로 자동 이동
- Bug 우선순위에 따른 SLA 알림: P1 버그가 24시간 이상 In Progress 상태면 Slack 알림
- 담당자 자동 할당: 특정 라벨이 붙은 이슈를 자동으로 팀의 on-call에게 할당
자동화는 작게 시작해야 한다. 한꺼번에 복잡한 룰 묶음을 만들면 디버깅이 어려워지고, 잘못된 룰이 이슈를 임의로 옮기는 사고가 일어난다. PR ↔ 상태 동기화 같은 단순한 룰부터 시작해 신뢰가 쌓이면 확장하는 게 안전하다.
흔한 함정
이슈와 commit이 분리됨
이슈 키 컨벤션을 강제하지 않으면 commit이 이슈와 자동 연결되지 않는다. 결과적으로 JIRA는 PM 도구로만 쓰이고, 코드 흐름은 GitHub에서만 추적되는 분리가 일어난다. branch naming rule을 lint로 강제하거나, PR template에 이슈 키 입력 필드를 두는 식의 안전판이 필요하다.
워크플로우가 너무 복잡
5개 이상의 상태 + 다중 분기 + 승인 단계가 들어간 워크플로우는 사람이 따라가지 못한다. 결국 사람들은 “Done이 되어야 할 이슈"를 그냥 Done으로 옮기고 중간 상태를 건너뛰는 식으로 우회한다. 단순한 워크플로우 + 자동화로 보강하는 쪽이 거의 항상 낫다.
Sprint scope creep
Planning 후에도 새 이슈가 계속 들어오면 Sprint가 시간 분할 의미만 남는다. 긴급 이슈가 들어와야 한다면 같은 양을 빼는 트레이드오프를 강제하는 룰이 안전판이다. PM이나 팀 리드가 그 결정을 진다.
“이슈를 위한 이슈”
작은 작업까지 이슈를 만들고 메타데이터를 채우는 데 시간을 쓰면, 이슈 시스템 자체가 일을 만든다. 어떤 작업이 이슈가 될 가치가 있는가에 대한 팀 합의가 필요하다 — 보통 “다른 사람과 동기화가 필요한 작업"이 좋은 기준이다.
시리즈 정리
이 시리즈는 개발자가 매일 쓰는 협업 도구 네 요소를 다뤘다.
- Git (1편) — 변경의 그래프. commit / branch / merge·rebase
- GitHub PR (2편) — 그래프 위 협업 레이어. PR 단위 설계 + Code Review
- GitHub Actions (3편) — 자동 검증과 배포. workflow / job / step
- JIRA (4편) — 그래프와 짝지어 가는 작업 단위. 이슈 + Sprint + Git/GitHub 연동
네 도구는 서로 다른 추상을 갖지만 짝지어 갈 때 가장 빛난다. 이슈 키가 branch·commit·PR을 따라 흐르고, PR이 자동 검증을 통과하고, 머지가 이슈 상태를 자동 전이시키는 흐름. 그 자동화가 매일의 컨텍스트 전환 비용을 줄이고, 팀의 속도가 그 위에서 만들어진다.