JIRA 란,

Atlassian(아틀라시안)에서 만든 이슈 트래커(Issue Tracker, 할 일을 등록하고 추적하는 도구)

“누가, 무엇을, 언제까지, 지금 어디까지 했는지”를 한 곳에서 관리하는 도구
원래는 버그 관리 도구로 시작했지만, 지금은 개발 업무 전반의 일정·진행 상황 관리 도구로 쓰인다

왜 쓰는가

엑셀이나 메신저로 할 일을 관리할 때 생기는 문제를 해결한다.

기록이 남는다: 누가 언제 상태를 바꿨는지 이력이 자동으로 쌓인다
한눈에 보인다: 보드(Board)에서 팀 전체 진행 상황을 한 화면으로 확인
연결된다: Git 커밋, Confluence 문서, 배포와 이슈가 서로 링크된다
검색된다: JQL(Jira Query Language)로 원하는 조건의 이슈만 골라낼 수 있다

JIRA 제품 종류

같은 “JIRA”라도 목적에 따라 제품이 나뉜다.

제품	용도
Jira Software	개발팀용. 스프린트, 보드, 백로그 제공
Jira Service Management	고객·사내 문의 접수(헬프데스크)용
Jira Work Management	비개발 부서(인사, 마케팅 등) 업무 관리용

개발자가 “지라”라고 하면 보통 Jira Software를 뜻한다
이 글도 Jira Software 기준으로 설명한다

핵심 개념과 용어,

JIRA를 처음 열면 생소한 단어가 쏟아진다. 계층 구조부터 잡고 가면 쉽다.

계층 구조

프로젝트(Project)
└── 에픽(Epic)          ← 큰 기능 덩어리
    └── 스토리(Story)    ← 사용자 관점의 요구사항
        └── 서브태스크(Sub-task)  ← 스토리를 쪼갠 실제 작업

위에서 아래로 갈수록 작업 단위가 잘게 쪼개진다
버그(Bug)와 태스크(Task)는 스토리와 같은 레벨에 위치한다

프로젝트(Project)

이슈를 담는 가장 큰 그릇

보통 팀 단위 또는 서비스 단위로 하나씩 만든다
프로젝트마다 고유한 키(Key) 를 가진다 (예: SHOP, PAY)
이 키가 이슈 번호의 앞부분이 된다 → SHOP-101, PAY-42

이슈(Issue)

JIRA에서 관리하는 일 하나의 단위

JIRA의 모든 것은 결국 이슈다. 기능 개발도, 버그도, 회의 준비도 전부 이슈
최근 Jira Cloud 화면에서는 이슈를 작업(Work item) 이라고 부르기도 한다. 같은 것이다

이슈 타입(Issue Type)

타입	의미	예시
Epic(에픽)	여러 스프린트에 걸치는 큰 기능 덩어리	“결제 시스템 구축”
Story(스토리)	사용자 관점의 요구사항 한 개	“카드로 결제할 수 있다”
Task(태스크)	사용자 기능은 아니지만 해야 할 일	“결제 API 문서 작성”
Bug(버그)	잘못 동작하는 것	“결제 후 주문 상태가 안 바뀜”
Sub-task(서브태스크)	위 이슈를 더 잘게 쪼갠 것	“PG사 연동 코드 작성”

스토리는 보통 ~로서, ~할 수 있다 형태로 쓴다
→ “구매자로서, 저장된 카드로 결제할 수 있다”

상태(Status)와 워크플로우(Workflow)

상태(Status): 이슈가 지금 어디쯤 와 있는지 (할 일, 진행 중, 완료)
워크플로우(Workflow): 상태에서 상태로 넘어가는 경로를 정해둔 규칙

할 일(To Do) → 진행 중(In Progress) → 리뷰 중(In Review) → 완료(Done)

워크플로우가 있으면 할 일에서 바로 완료로 건너뛰는 것을 막을 수 있다
상태를 바꾸는 행위를 전환(Transition) 이라고 부른다

스프린트(Sprint)와 백로그(Backlog)

백로그(Backlog): 아직 언제 할지 정하지 않은 이슈를 모아둔 대기열
스프린트(Sprint): 정해진 기간(보통 1~2주) 동안 처리하기로 약속한 이슈 묶음
흐름: 백로그에 이슈를 쌓아두고 → 이번 스프린트에 할 것만 골라 옮기고 → 기간이 끝나면 스프린트 종료

보드(Board)

스프린트에 담긴 이슈를 상태별 열(column)로 보여주는 화면

| 할 일   | 진행 중  | 리뷰 중  | 완료    |
|---------|---------|---------|---------|
| SHOP-12 | SHOP-10 | SHOP-8  | SHOP-5  |
| SHOP-13 |         |         | SHOP-6  |

카드를 드래그해서 옮기면 이슈 상태가 바뀐다
보드 종류는 두 가지
- 스크럼(Scrum) 보드: 스프린트 단위로 끊어서 일하는 팀용
- 칸반(Kanban) 보드: 스프린트 없이 계속 흘려보내는 팀용

그 외 자주 보는 필드

담당자(Assignee): 이 이슈를 실제로 처리하는 사람
보고자(Reporter): 이 이슈를 등록한 사람
우선순위(Priority): Highest / High / Medium / Low / Lowest
스토리 포인트(Story Point): 작업의 크기를 숫자로 매긴 값. 시간이 아니라 상대적 크기
버전(Fix Version): 이 이슈가 어느 릴리스에 포함되는지
컴포넌트(Component): 프로젝트 내부를 나눈 하위 영역 (예: backend, frontend)

팀원 관점 - 기본 사용법,

실제로 매일 하게 되는 작업 순서대로 정리한다.

1. 이슈 생성

상단의 만들기(Create) 버튼으로 생성한다.

채워야 할 최소 항목

프로젝트: 어느 프로젝트의 일인지
이슈 타입: Story / Task / Bug 중 선택
요약(Summary): 제목. 한 줄로 무슨 일인지 알 수 있게
설명(Description): 배경, 요구사항, 완료 조건

좋은 요약 예시

X  "결제 오류"
O  "카드 결제 후 주문 상태가 '결제대기'로 남는 문제"

제목만 보고도 무슨 일인지 알 수 있어야 나중에 검색이 된다

버그 이슈라면 설명에 아래를 반드시 남긴다.

[재현 방법]
1. 상품 상세 → 바로구매
2. 카드 결제 완료

[기대 결과] 주문 상태가 '결제완료'
[실제 결과] 주문 상태가 '결제대기'
[환경] 운영, Chrome 120

2. 이슈 할당과 상태 변경

담당자 지정: 이슈 화면에서 담당자 필드를 자신으로 변경
상태 변경: 작업을 시작하면 할 일 → 진행 중으로 옮긴다
- 이슈 화면의 상태 드롭다운으로 변경하거나
- 보드에서 카드를 드래그해서 변경

핵심은 일을 시작할 때 바로 옮기는 것이다. 다 끝내고 한꺼번에 옮기면 보드가 현재 상황을 반영하지 못한다.

3. 댓글과 멘션

이슈 하단 댓글로 논의 내용을 남긴다
@이름 으로 멘션하면 해당 사용자에게 알림이 간다
메신저 대신 이슈 댓글에 남기면 맥락이 이슈에 붙어서 나중에 찾을 수 있다

4. 이슈 연결(Link)

이슈끼리 관계를 걸어둘 수 있다.

blocks / is blocked by: A가 끝나야 B를 할 수 있을 때
relates to: 그냥 관련 있을 때
duplicates: 중복 이슈일 때

5. Git 연동

브랜치명이나 커밋 메시지에 이슈 키를 넣으면 자동으로 이슈에 연결된다.

# 브랜치명에 이슈 키 포함
git switch -c feature/SHOP-101-card-payment

# 커밋 메시지 맨 앞에 이슈 키
git commit -m "SHOP-101 카드 결제 API 연동"

이슈 화면의 개발(Development) 영역에서 연결된 브랜치·커밋·PR을 바로 확인할 수 있다
이슈 키를 안 붙이면 연동이 안 되므로, 팀 규칙으로 강제하는 경우가 많다

6. JQL로 이슈 검색

JQL(Jira Query Language)은 이슈를 조건으로 걸러내는 검색 문법이다. SQL의 WHERE 절과 비슷하다.

-- 내가 담당인 미완료 이슈
assignee = currentUser() AND status != Done

-- SHOP 프로젝트의 이번 스프린트 버그
project = SHOP AND issuetype = Bug AND sprint in openSprints()

-- 최근 7일 내 생성된 이슈
created >= -7d ORDER BY created DESC

-- 담당자가 없는 할 일
project = SHOP AND assignee is EMPTY AND status = "To Do"

자주 쓰는 함수

currentUser(): 지금 로그인한 사용자
openSprints(): 진행 중인 스프린트
-7d, -1w: 상대적인 시간 (7일 전, 1주 전)

자주 쓰는 검색은 필터(Filter)로 저장해두고, 대시보드에 올려서 쓴다.

관리자 관점 - 프로젝트 세팅,

프로젝트를 처음 만들거나 팀 규칙을 JIRA에 반영할 때 건드리는 부분이다.

1. 프로젝트 생성

프로젝트 생성 시 두 가지를 고른다.

템플릿 선택

스크럼(Scrum): 스프린트 단위로 일하는 팀
칸반(Kanban): 스프린트 없이 계속 흘려보내는 팀
버그 추적(Bug tracking): 버그만 관리하는 경우

프로젝트 타입 선택 (Jira Cloud 기준)

타입	특징
팀 관리형(Team-managed)	프로젝트 관리자가 직접 설정 변경. 설정이 이 프로젝트에만 적용됨. 간단함
회사 관리형(Company-managed)	Jira 관리자만 설정 변경. 여러 프로젝트가 설정을 공유. 복잡하지만 일관성 유지

처음 시작하거나 팀 하나만 쓴다면 팀 관리형이 편하다
여러 팀이 같은 워크플로우·필드를 써야 한다면 회사 관리형

2. 워크플로우 커스터마이징

기본 워크플로우(할 일 → 진행 중 → 완료)가 팀 실제 프로세스와 안 맞을 때 수정한다.

예를 들어 코드 리뷰와 QA 단계를 추가하려면

할 일 → 진행 중 → 리뷰 중 → QA → 완료
                    ↓
                 재작업(진행 중으로 되돌리기)

설정할 수 있는 것

상태(Status) 추가/삭제: 위의 리뷰 중, QA 같은 단계
전환(Transition) 규칙: 어떤 상태에서 어떤 상태로 갈 수 있는지
조건(Condition): 특정 권한을 가진 사람만 전환 가능하게
검증(Validator): 필수 필드가 비어 있으면 전환 막기
후처리(Post function): 전환 시 담당자 자동 변경, 해결 시각 기록 등

주의: 상태를 너무 많이 만들면 팀원이 어디로 옮겨야 할지 헷갈린다. 5개 이내를 권장한다.

3. 이슈 타입과 필드 설정

이슈 타입 스킴(Issue Type Scheme): 이 프로젝트에서 쓸 이슈 타입 목록을 정한다
화면 스킴(Screen Scheme): 이슈 생성·수정·조회 화면에 어떤 필드를 보일지 정한다
사용자 정의 필드(Custom Field): 기본 필드로 부족할 때 추가 (예: “배포 환경”, “고객사”)

사용자 정의 필드는 최소한으로 만든다. 필드가 많으면 이슈 생성이 번거로워져서 팀원이 대충 채우게 된다.

4. 권한 설정

역할(Role): 프로젝트 안에서의 역할 (Administrator, Member, Viewer)
권한 스킴(Permission Scheme): 각 역할이 무엇을 할 수 있는지 정의
- 이슈 생성, 이슈 삭제, 워크플로우 전환, 스프린트 관리 등을 개별 제어
이슈 보안 수준(Issue Security): 특정 이슈를 일부 사용자에게만 보이게

5. 자동화(Automation)

반복 작업을 규칙으로 만들어 자동 처리한다. 코드 없이 화면에서 설정한다.

구조는 트리거(Trigger) → 조건(Condition) → 액션(Action) 세 단계다.

자주 쓰는 규칙 예시

PR이 머지되면 → 이슈 상태를 완료로 변경
이슈가 진행 중으로 바뀌면 → 담당자를 상태 변경한 사람으로 지정
3일 이상 진행 중인 이슈가 있으면 → Slack에 알림
버그 이슈가 생성되면 → 우선순위를 High로 자동 설정

6. 리포트로 상태 보기

번다운 차트(Burndown Chart): 스프린트 남은 작업량이 줄어드는 추이
속도 차트(Velocity Chart): 스프린트마다 완료한 스토리 포인트. 다음 스프린트 계획의 근거
누적 흐름도(Cumulative Flow Diagram): 어느 상태에 이슈가 쌓여 있는지(=병목 지점) 확인

처음 쓸 때 자주 하는 실수,

이슈를 너무 크게 만든다: 일주일 넘게 걸리는 이슈는 쪼갠다. 진행 상황이 안 보인다
상태를 나중에 몰아서 옮긴다: 보드가 실제 상황을 반영하지 못해 보드를 볼 이유가 없어진다
제목을 대충 쓴다: “수정”, “버그” 같은 제목은 3개월 뒤 검색이 불가능하다
논의를 메신저에서만 한다: 결정 사항은 이슈 댓글에 남겨야 맥락이 보존된다
필드를 과하게 만든다: 채우기 귀찮아지면 아무도 안 채운다
커밋에 이슈 키를 안 붙인다: 코드와 이슈의 연결이 끊어진다

용어 정리,

용어	한 줄 정의
프로젝트(Project)	이슈를 담는 가장 큰 그릇. 고유 키를 가진다
이슈(Issue)	관리 대상이 되는 일 하나
에픽(Epic)	여러 스프린트에 걸치는 큰 기능 덩어리
스토리(Story)	사용자 관점의 요구사항 한 개
서브태스크(Sub-task)	이슈를 더 잘게 쪼갠 작업
상태(Status)	이슈가 지금 어느 단계인지
워크플로우(Workflow)	상태 간 이동 경로를 정한 규칙
전환(Transition)	상태를 바꾸는 행위
백로그(Backlog)	아직 일정이 안 잡힌 이슈 대기열
스프린트(Sprint)	일정 기간 동안 처리하기로 한 이슈 묶음
보드(Board)	이슈를 상태별 열로 보여주는 화면
스토리 포인트(Story Point)	작업 크기를 나타내는 상대적 숫자
JQL	이슈를 조건으로 검색하는 문법
자동화(Automation)	트리거-조건-액션으로 반복 작업을 처리하는 규칙