회사에서 협업 도구로 Jira를 사용하고 있다. 팀에 합류한 뒤 자연스럽게 Jira를 쓰기 시작했지만 사용할수록 익숙하게 쓰는 것과 제대로 이해하고 쓰는 것은 다르다는 생각이 들었다. Epic, Story, Task의 차이, 스프린트 운영 방식 같은 개념들을 얼핏 알고는 있었지만 막상 설명하려고 하면 흐릿한 부분이 많았다. 이번 글에서는 Atlassian 공식 문서를 바탕으로 Jira의 핵심 개념을 다시 정리하고, 실무에서 헷갈리기 쉬운 포인트들을 함께 정리해보려고 한다.
1. Jira란
Atlassian이 만든 프로젝트 관리 도구다. 원래 버그 트래킹 용도로 시작했지만 지금은 팀 업무 전반을 관리하는 플랫폼으로 쓰인다.
공식 문서 기준으로 역할은 네 가지다.
| Planning | 이슈를 생성하고 스프린트를 계획한다 |
| Tracking | 업무 우선순위와 진행 상태를 실시간으로 가시화한다 |
| Release | 개발 완료 현황을 기반으로 제품 출시를 관리한다 |
| Report | 번다운 차트, 속도 보고서 등으로 팀 효율을 측정한다 |
보드 유형은 두 가지다. Scrum 보드는 Sprint 단위로 기간을 정해 일을 관리하고, Kanban 보드는 시간 제한 없이 요청 순서대로 처리한다. 우리 팀은 Scrum 보드를 쓰기 때문에 이 글도 Scrum 기준으로 정리했다.
2. 애자일과 스크럼
Jira의 용어는 전부 애자일·스크럼에서 나온다. 이 배경을 모르면 용어가 맥락 없이 느껴진다.
애자일
2001년 Agile Manifesto에서 시작된 개발 방법론이다. 핵심은 크게 한 번 출시하는 대신, 작게 빠르게 만들어 계속 개선한다는 것이다.
스크럼
애자일을 구현하는 프레임워크 중 가장 많이 쓰인다. 핵심은 Sprint라는 짧은 반복 주기다.
스크럼에는 세 가지 역할이 있다.
| Product Owner (PO) | 제품 방향과 우선순위를 결정한다. 백로그를 관리한다 |
| Scrum Master | 스크럼 프로세스를 관리하고 팀의 방해물을 제거한다 |
| Development Team | 실제로 제품을 만드는 팀. 개발자, 디자이너, QA 등 5~9명 |
전체 흐름은 이렇다.
[Product Backlog] → [Sprint Planning] → [Sprint 실행] → [Sprint Review] → [Retrospective]
↑ |
└──────────────────────────── 다음 스프린트 ──────────────────────────────┘
이 흐름이 Jira에서 그대로 구현된다.
3. Issue Type
이슈(Issue)는 Jira에서 관리하는 모든 업무 항목의 총칭이다. 기능 요청, 버그, 기술 작업 등 모든 것이 이슈다. 이슈 안에 유형(Type)이 있고 계층 구조는 다음과 같다.
Initiative — 조직 전체의 연간 목표·전략
└── Epic — 여러 스프린트에 걸친 큰 기능 단위
├── Story — 사용자에게 가치를 주는 기능
├── Task — 기술적·관리적 작업
└── Bug — 발생한 결함·오류
└── Sub-task — Story/Task를 더 작게 쪼갠 단위
처음에는 Story랑 Task 구분이 제일 헷갈렸다. 아래에서 하나씩 정리한다.
Epic
여러 스프린트에 걸쳐 진행되는 큰 기능 단위다. 단일 스프린트 안에서 끝나지 않는다.
Atlassian 공식 정의: 에픽은 더 작은 사용자 스토리로 나눌 수 있는 큰 사용자 스토리다.
프로젝트의 마일스톤 역할을 한다. PO가 리더십에 보고할 때는 에픽 단위로 이야기하고, 개발팀 내부에서는 스토리 단위로 이야기한다.
에픽과 하위 스토리 예시를 보면 규모가 감이 잡힌다.
에픽 하위 스토리 예시
| 회원 관리 시스템 | 회원가입, 로그인/로그아웃, 비밀번호 재설정, 회원 탈퇴 |
| 쇼핑몰 결제 시스템 | 장바구니, 주문서 작성, PG 연동, 주문 내역 조회 |
| 모바일 앱 v2.0 리뉴얼 | 홈 화면 개편, 푸시 알림, 다크모드 지원 |
에픽 하나는 보통 2~4개 스프린트에 걸쳐 완료된다. "회원 관리 시스템" 에픽이라면 스프린트 1에서 회원가입·로그인을, 스프린트 2에서 비밀번호 재설정·탈퇴를 처리하는 식이다.
Story
최종 사용자 관점에서 기능을 서술한 것이다. 기준은 사용자에게 직접적인 가치를 주는가다.
작성 공식이 있다.
[역할]로서, 나는 [기능/행위]를 원한다. 왜냐하면 [이유/목적] 때문이다.
기술 용어가 아닌 비즈니스 언어로 작성하는 것이 원칙이다. JWT 토큰 재발급 로직 구현은 스토리가 아니다.
올바른 스토리와 잘못된 스토리를 비교하면 차이가 명확하다.
올바른 스토리 | 잘못된 스토리
| "구매자로서, 주문 내역을 조회하고 싶다. 배송 현황을 확인하기 위해서다." | "주문 내역 API 개발" |
| "사용자로서, 비밀번호를 분실했을 때 이메일로 재설정하고 싶다." | "JWT 토큰 재발급 로직 구현" |
| "관리자로서, 사용자 목록을 엑셀로 내보내고 싶다." | "엑셀 export 기능 BE 작업" |
잘못된 예시들은 기술 구현 설명이라 태스크나 서브태스크에 해당한다.
잘 쓴 스토리가 갖춰야 할 조건으로 INVEST 원칙이 있다.
약자 의미
| Independent | 다른 스토리에 의존하지 않는다 |
| Negotiable | 구현 방법은 협의 가능하다 |
| Valuable | 사용자에게 명확한 가치를 준다 |
| Estimable | 공수를 추정할 수 있다 |
| Small | 하나의 스프린트 안에 완료 가능하다 |
| Testable | 완료 여부를 테스트로 확인할 수 있다 |
Task
사용자와 직접 관련 없는 기술적·관리적 작업이다.
- 개발 서버 Docker 환경 설정
- CI/CD 파이프라인 구성
- API 설계 문서 작성
- 데이터베이스 인덱스 최적화
- SSL 인증서 갱신
Story와 Task 구분이 헷갈릴 때 판단 기준은 하나다.
이 작업이 사용자 경험에 직접 영향을 주는가? — Yes면 Story, No면 Task다.
상황 판단 이유
| 비밀번호 규칙 안내 문구 추가 | Story | 사용자가 직접 보고 혜택을 받는다 |
| 비밀번호 유효성 검사 로직 리팩토링 | Task | 사용자에게 보이지 않는 내부 작업이다 |
| 결제 완료 후 이메일 발송 기능 | Story | 사용자가 이메일을 받는 경험이다 |
| 이메일 발송 서버 설정 | Task | 인프라 작업, 사용자 무관이다 |
팀마다 기준이 다를 수 있으니 팀 기존 이슈를 먼저 살펴보는 게 낫다.
Bug
서비스에서 발생한 결함·오류를 기록하는 유형이다.
잘 작성된 버그 티켓 예시
제목: [주문 완료 화면] 결제 후 주문번호가 표시되지 않음
재현 절차:
1. 상품을 장바구니에 담는다
2. 주문서를 작성하고 결제를 진행한다
3. 결제 완료 후 주문 완료 화면에 진입한다
예상 동작: 주문번호와 예상 배송일이 표시된다
실제 동작: 주문번호 영역이 비어 있고 "undefined"가 출력된다
환경: Chrome 122 / macOS 14.3 / 웹 v2.1.0
우선순위: High
스크린샷: (첨부)
재현 절차가 불명확한 버그 티켓은 개발자가 재현조차 못 하고 닫히는 경우가 많다. 귀찮더라도 구체적으로 적는 게 결국 빠르다.
Sub-task
Story나 Task를 더 잘게 쪼갠 단위다. 모든 서브태스크가 완료되어야 부모 이슈가 완료된다.
"사용자 로그인 기능" 스토리의 서브태스크 예시:
Story: 사용자로서, 이메일과 비밀번호로 로그인하고 싶다
└── 로그인 화면 UI 구현 (FE) — 담당: A / 예상: 1일
└── 로그인 API 개발 (BE) — 담당: B / 예상: 1일
└── JWT 토큰 발급·검증 로직 (BE) — 담당: B / 예상: 0.5일
└── 로그인 실패 처리 및 에러 메시지 — 담당: A / 예상: 0.5일
└── 단위 테스트 작성 — 담당: B / 예상: 1일
└── QA 확인 — 담당: C / 예상: 0.5일
서브태스크로 쪼개면 누가 무엇을 하는지 명확해지고 진행률도 숫자로 파악된다.
이슈 유형 요약
| 유형 | 크기 | 기간 | 핵심 특징 | 주로 작성하는 사람 |
| Epic | 매우 큼 | 여러 스프린트 | 여러 Story의 묶음, 마일스톤 | PO / 팀장 |
| Story | 중간 | 1 스프린트 이내 | 사용자 가치 중심, 비기술 언어 | PO / 기획자 |
| Task | 중간 | 1 스프린트 이내 | 기술·관리 작업, 사용자 무관 | 개발자 / 팀원 |
| Bug | 작음 | 빠르게 처리 | 결함 기록, 재현 절차 포함 | QA / 누구나 |
| Sub-task | 매우 작음 | 1~3일 | Story/Task의 하위 단위 | 개발자 |
4. Sprint
Sprint는 팀이 제품 백로그의 작업을 완료하는 고정된 기간이다.
Atlassian 공식 정의: 스프린트는 사용 가능하며 잠재적으로 릴리스 가능한 제품의 증분을 만드는 동안, 설정된 양의 작업을 완료하기 위해 팀이 일하는 정해진 짧은 기간이다.
기간 선택
기간 특징
| 1주 | 피드백이 빠르지만 Planning·Review·Retro 오버헤드가 크다 |
| 2주 | 가장 일반적. 대부분의 팀이 여기서 시작한다 |
| 4주 | 큰 기능을 다룰 때. 중간 피드백이 느리다는 단점이 있다 |
운영 흐름
1단계 — 스프린트 생성
Backlog 화면에서 스프린트 만들기를 클릭하면 이름, 시작일, 종료일, 목표를 입력하는 폼이 나온다.
스프린트 목표(Sprint Goal)는 이번 스프린트가 끝났을 때 달성해야 할 것을 한 줄로 정의한다. 목표가 명확할수록 스프린트 중 범위 논쟁이 줄어든다.
예: "회원 관리 에픽 중 로그인/로그아웃 기능 완료"
예: "결제 시스템 1차 — PG 연동 및 주문서 작성까지"
2단계 — 이슈 할당
백로그에서 이번 스프린트에 처리할 이슈를 드래그해 넣는다. 팀의 평균 속도(Velocity)를 기준으로 처리 가능한 스토리 포인트 안에서 선택한다.
이슈를 고르는 기준
- 우선순위가 높은 것 먼저
- 스프린트 목표와 직접 연관된 것 우선
- 선행 이슈가 있는 경우 의존 관계 확인
스프린트 도중에 이슈를 추가하는 것은 가능하지만, 팀 합의 없이 범위를 늘리면 스프린트 목표가 흐려진다.
3단계 — 스프린트 시작
스프린트 시작을 클릭하면 해당 이슈들이 Active Sprint 보드에 나타난다. 한 번에 하나의 스프린트만 활성화할 수 있다.
4단계 — 진행
- Daily Standup에서 보드를 보며 진행 상황을 공유한다
- 이슈 상태를 실시간으로 업데이트한다
- 번다운 차트로 남은 작업량을 확인한다
- 블로커가 생기면 즉시 팀에 공유한다
5단계 — 스프린트 종료
스프린트 완료를 클릭한다. 완료되지 않은 이슈는 다음 스프린트나 백로그로 자동 이동한다. 이후 Sprint Review → Retrospective 순으로 진행한다.
5. Backlog
백로그는 해야 할 일들의 우선순위가 매겨진 목록이다. 위에 있을수록 우선순위가 높다.
Product Backlog vs Sprint Backlog
구분 Product Backlog Sprint Backlog
| 관리자 | Product Owner | 팀 전체 |
| 내용 | 제품 전체의 모든 할 일 | 이번 스프린트에 선택된 이슈 |
| 기간 | 제품 생명주기 전체 | 현재 스프린트 기간 |
우선순위 기준
백로그 순서는 단순히 급한 순서가 아니다. PO가 아래 기준을 종합해 결정한다.
| 비즈니스 가치 | 사용자·비즈니스에 얼마나 큰 영향을 주는가 |
| 리스크 | 늦게 처리할수록 손해가 커지는가 |
| 의존 관계 | 다른 이슈의 선행 조건인가 |
| 구현 복잡도 | 빠르게 처리할 수 있는가 |
백로그 그루밍
다음 스프린트를 준비하는 정기 회의다. 보통 스프린트 중반에 1~2시간 진행한다.
그루밍에서 하는 것
- 불필요해진 이슈를 닫거나 중복 이슈를 합친다
- 새 요구사항이 생기면 이슈를 추가한다
- 비즈니스 상황이 바뀌었다면 우선순위를 재조정한다
- 내용이 불명확한 이슈는 담당자·기준·범위를 구체화한다
- 다음 스프린트에 올라갈 이슈의 스토리 포인트를 부여한다
그루밍이 잘 된 백로그는 상위 이슈에 스토리 포인트가 붙어 있고, 완료 기준(Definition of Done)이 명시되어 있으며, 의존 관계가 이슈 링크로 연결되어 있다.
반대로 그루밍이 안 된 백로그는 이슈 제목만 있고 설명이 없거나, 스토리 포인트가 없어 스프린트 계획을 세울 수 없거나, 몇 달 전에 만들어진 이슈가 방치되어 있는 경우가 많다.
6. Scrum Board
현재 스프린트의 이슈를 칸반 방식으로 시각화한 화면이다. 기본 컬럼은 세 가지고 팀에 따라 In Review, QA, Blocked 등을 추가한다.
[ To Do ] → [ In Progress ] → [ In Review ] → [ Done ]
이슈를 드래그해 컬럼 간 이동으로 상태를 업데이트한다. 개발 시작 시 In Progress, PR 오픈 후 In Review, 머지 완료 후 Done으로 옮긴다. 상태를 몰아서 업데이트하는 게 가장 흔한 실수다. 하루치를 한꺼번에 닫으면 팀 전체가 잘못된 정보를 보게 된다.
번다운 차트
X축은 날짜, Y축은 남은 스토리 포인트다.
포인트
|
30| \ <- 이상선
| \
20| \___ <- 실제선
| \__
10| \
| \___
0|________________\
1일 3일 5일 7일 9일
- 실제선이 이상선 위 → 뒤처지고 있다
- 실제선이 이상선 아래 → 예상보다 빠르다. 백로그에서 이슈를 추가할 수 있다
- 선이 수평으로 이어짐 → 그날 완료된 이슈가 없다
7. Story Point
이슈의 상대적 복잡도와 공수를 나타내는 단위다. 시간(hour)이 아니다.
시간으로 측정하지 않는 이유는 개발자마다 속도가 다르고, 같은 사람도 컨디션·요구사항 명확도·기술 숙련도에 따라 편차가 크기 때문이다. 팀이 합의한 상대적 크기를 쓰는 게 더 현실적이다.
피보나치 수열
보통 피보나치 수열(1, 2, 3, 5, 8, 13, 21…)을 사용한다. 숫자 간격이 커질수록 불확실성도 크다는 의미가 포함된다.
포인트 의미 예시
| 1 | 아주 간단함 | 버튼 색상 변경, 오탈자 수정 |
| 2 | 간단함 | 간단한 UI 컴포넌트 추가 |
| 3 | 보통 | 기존 기능에 옵션 추가 |
| 5 | 복잡 | 새 화면 개발, API 연동 |
| 8 | 매우 복잡 | 여러 API + 상태 관리 포함 기능 |
| 13 이상 | 너무 큼 | 더 작게 쪼개는 것을 권장 |
플래닝 포커
스토리 포인트를 추정할 때 쓰는 방법이다.
- PO 또는 스크럼 마스터가 스토리를 설명한다
- 각자 추정값을 고른다
- 동시에 공개한다 — 순서대로 공개하면 앞 사람 숫자에 영향을 받는 앵커링 바이어스가 생긴다
- 가장 높은 숫자와 가장 낮은 숫자를 고른 사람이 이유를 설명한다
- 합의될 때까지 반복한다
추정 시 자주 생기는 문제들:
문제 대처
| 요구사항이 불명확해서 추정이 안 된다 | PO에게 질문하고 명확해진 후 재추정한다 |
| 팀원 간 추정값 차이가 너무 크다 (1 vs 8) | 양쪽 이유를 듣고 합의한다. 차이가 큰 것 자체가 요구사항이 불명확하다는 신호다 |
| 이슈가 너무 커서 추정하기 어렵다 | 13 이상이 나오면 더 작게 쪼갠다 |
| 매번 같은 사람 추정값에 모두 동의한다 | 동시 공개가 제대로 되고 있는지 확인한다 |
속도(Velocity)
팀이 한 스프린트에 완료한 스토리 포인트의 합이다. 3~5개 스프린트를 거친 후 평균 속도를 계산하면 다음 스프린트 계획 시 처리 가능한 양을 예측할 수 있다.
속도가 갑자기 낮아졌다면 원인을 파악하는 게 좋다. 멤버 부재, 요구사항 변경, 기술 부채 등이 원인인 경우가 많다.
8. 스크럼 세레모니
세레모니 시점 시간 목적
| Sprint Planning | 스프린트 시작일 | 2~4시간 | 이슈 선택, 스토리 포인트 합의, 스프린트 목표 설정 |
| Daily Standup | 매일 아침 | 15분 이내 | 어제 한 일 / 오늘 할 일 / 블로커 공유 |
| Sprint Review | 스프린트 종료일 | 1~2시간 | 결과물 시연, 이해관계자 피드백 수렴 |
| Retrospective | 스프린트 종료 후 | 1~2시간 | 잘된 것 / 개선할 것 / 다음에 시도할 것 |
| Grooming | 스프린트 중반 | 1~2시간 | 다음 스프린트 이슈 준비, 우선순위 정리 |
9. 실전 팁
정리하면서 앞으로 내가 신경 써야겠다 싶은 것들도 같이 적어둔다.
상태를 실시간으로 업데이트한다.
작업을 시작하면 바로 In Progress로 옮긴다. 몰아서 업데이트하면 팀 전체가 잘못된 정보를 보게 된다.
이슈 번호를 브랜치명과 커밋에 붙인다.
feature/PROJ-123-login처럼 이슈 번호를 브랜치명에 포함하면 Jira가 코드와 이슈를 자동으로 연결한다. 나중에 "이 코드가 어떤 기능인지" 추적할 때 유용하다.
이슈에 맥락을 남긴다.
작업 중 결정한 것, 발견한 문제, 참고 링크 등을 댓글로 기록해두면 나중에 도움이 된다. 빈 이슈는 쓸모가 없다.
이슈가 너무 크면 Sub-task로 쪼갠다.
어디서부터 시작해야 하지라는 생각이 든다면 이슈가 너무 큰 것이다.
팀의 관례를 먼저 파악한다.
Story와 Task 구분 기준, 스토리 포인트 기준은 팀마다 다르다. 공식 문서보다 우리 팀 기존 이슈를 먼저 살펴보는 게 빠르다.
블로커를 숨기지 않는다.
이슈가 막혔을 때 혼자 안고 있으면 팀 전체의 속도가 느려진다. Jira에 블로커 링크를 달거나 댓글로 상황을 남긴다.
마치며
Epic은 큰 기능 묶음, Story는 사용자 가치, Task는 기술 작업, Bug는 결함, Sub-task는 실행 최소 단위. Sprint는 1~4주 반복 주기, Backlog는 모든 할 일의 목록이다.
용어가 정리되고 나니 팀 대화가 훨씬 잘 들린다. 더 쓰다 보면 추가할 내용이 생길 것 같아서 계속 업데이트할 예정이다.
참고 자료