이슈 추적 도구: Jira 등 공통 개념과 실무 워크플로

개념

공고에 적힌 "Jira 사용 경험" 이 실제로 묻는 것은 버튼 위치가 아니다. 결함 하나가 등록되어 종결될 때까지 도구 안에서 어떻게 흘러가는지를 아느냐다. 그 흐름은 도구가 바뀌어도 같다.

도서관을 생각하면 구분이 쉽다. 책을 어느 선반에 꽂는지는 도서관마다 다르지만, 분류 체계(주제·저자·연도)는 어디서나 비슷하다. 선반 위치를 외운 사람은 다른 도서관에서 길을 잃고, 분류 체계를 아는 사람은 안내도만 보고 찾아간다.

이 레슨은 분류 체계를 다룬다. 선반 위치, 즉 Jira 의 실전 운영은 모듈 22(레슨 6~8) 에서 이어 받는다.

도구는 다르지만 개념은 같다

Jira, Redmine, Bugzilla, Mantis, Trac — 회사마다 쓰는 이슈 추적 도구는 다르지만, 이들이 다루는 핵심 개념은 거의 동일하다. 하나의 도구를 "버튼 위치"로 외우면 다른 도구로 옮겼을 때 처음부터 다시 배워야 한다. 반대로 공통 개념을 이해하면, 어떤 도구를 접해도 화면 어딘가에서 같은 개념을 찾아 바로 적응할 수 있다.

같은 개념이 도구마다 어떤 이름으로 나타나는지 보면 감이 온다.

GitHub Issues 칸을 보면 도구의 성격 차이가 보인다. 상태가 열림·닫힘 둘뿐이라, 레슨 1의 생명주기를 쓰려면 라벨로 상태를 흉내 내야 한다. 작은 팀에는 충분하고, 재검증 단계를 추적해야 하는 팀에는 부족하다.

도구를 고를 때 물을 것은 "무엇이 더 좋은가" 가 아니라 "우리가 추적해야 하는 상태가 몇 개인가" 다. 상태가 셋이면 GitHub Issues로 충분하고, 재검증·반려·보류를 구분해야 하면 Jira 계열이 필요하다.

공통 개념 1 — 이슈 타입(Issue Type)

결함(Bug)만 등록하는 게 아니다. 새 기능 요청(Story/Feature), 개선 작업(Task), 그리고 결함(Bug)이 대표적인 이슈 타입이다. QA가 주로 다루는 건 Bug지만, 테스트 케이스 작성이나 회귀 테스트 같은 QA 작업 자체를 Task로 등록해 추적하는 팀도 많다.

타입을 어떻게 가르나

"전부 Bug로 올리면 편하지 않나" 라는 생각이 들 수 있다. 그러면 레슨 5의 지표가 전부 못 쓰게 된다. 가르는 기준은 간단하다.

가장 헷갈리는 것이 둘째 줄과 셋째 줄이다. "불편하다" 는 Bug가 아니라 개선 요청인데, Bug로 올리면 결함 수가 부풀고 개발팀은 "QA가 취향을 결함으로 올린다" 고 느낀다. 반대로 셋째 줄을 개선 요청으로 올리면 진짜 결함이 묻힌다.

판단이 안 서면 Question으로 올려 묻는 것이 안전하다. 답이 "의도가 아니다" 로 오면 Bug로 바꾸면 되고, 그 과정이 기록으로 남는다.

공통 개념 2 — 워크플로(Workflow)

레슨 1에서 배운 결함 생명주기(New → Assigned → ... → Closed)가 바로 이슈 추적 도구의 워크플로다. Jira에서는 이 워크플로를 프로젝트마다 커스터마이징할 수 있어서, 팀마다 상태 이름이나 순서가 조금씩 다를 수 있다 — 하지만 "발견 → 처리 중 → 검증 → 종결"이라는 큰 골격은 어디서나 같다.

전이와 권한 — 누가 상태를 바꿀 수 있나

워크플로에는 상태만 있는 것이 아니다. 상태 사이의 이동(전이)에 규칙이 붙는다. 이 규칙이 실무에서 중요한 이유가 있다.

첫 줄이 가장 중요하다. 많은 팀에서 결함이 조용히 Closed 되는 이유가 여기 있다. 도구에서 Fixed → Closed 를 보고자만 할 수 있게 막아 두면 레슨 1의 재검증 단계가 절차가 아니라 구조로 보장된다.

도구에 자동화 기능이 있으면 몇 가지는 손을 덜 수 있다 — 코드가 병합되면 자동으로 Fixed, 배포되면 자동으로 Retest 대기로 옮기는 식이다. 다만 자동으로 Closed 까지 가게 만들지는 않는다. 그러면 아무도 확인하지 않은 결함이 통계상 종결된다.

공통 개념 3 — 필드(Fields)

• 심각도(Severity) / 우선순위(Priority) — 레슨 1에서 배운 그 값
• 담당자(Assignee) — 지금 이 이슈를 처리해야 할 사람
• 보고자(Reporter) — 이슈를 등록한 사람(QA인 경우가 많다)
• 라벨/컴포넌트(Labels/Components) — 어느 기능 영역에 속하는지 분류(예: "결제", "로그인") — 나중에 레슨 5의 결함 밀도 계산에 이 분류가 쓰인다
• 연결(Links) — "이 이슈는 저 이슈의 중복이다", "이 이슈는 저 기능에 의존한다" 같은 이슈 간 관계

필드는 늘리기 쉽고 줄이기 어렵다

"이것도 필드로 받자" 가 쌓이면 등록 화면이 스크롤 두 번이 된다. 그때 생기는 일은 정해져 있다.

• 바쁜 사람이 빈칸으로 남긴다 → 그 필드의 집계가 못 쓰게 된다
• 아무 값이나 넣는다 → 틀린 집계가 나온다. 빈칸보다 나쁘다
• 등록 자체를 꺼린다 → 결함이 말로 전달된다

그래서 필수 필드는 다섯 개 안쪽으로 둔다. 레슨 2의 템플릿 원칙과 같다 — 짧아야 쓰인다.

새 필드를 만들기 전에 물을 것은 "이 값으로 어떤 결정을 할 것인가" 다. 답이 "나중에 볼 수도 있어서" 면 만들지 않는다. 쓰이지 않는 필드는 비용만 남긴다.

라벨·컴포넌트 — 집계의 축이 된다

이 필드가 가장 과소평가된다. 레슨 5의 거의 모든 지표가 이 분류를 축으로 계산된다.

두 번째가 조직을 바꾸는 숫자다. 운영에서 발견되는 비중이 높으면 "QA가 못 잡았다" 가 아니라 더 앞에서 잡을 장치가 없다는 뜻이고, 그 근거로 개발 단계 테스트에 투자를 요청할 수 있다.

분류 규칙은 처음에 적게 시작한다. 라벨이 50개가 되면 아무도 정확히 붙이지 않는다. 기능 영역 10개 안쪽으로 시작해 필요할 때 쪼갠다.

연결(Links) — 세 종류만 제대로 쓴다

연결 종류가 도구마다 열 개씩 있지만 실제로 필요한 것은 셋이다.

세 번째가 실무에서 힘이 있다. "이 결함이 테스트 진행을 차단하고 있다" 를 링크로 걸어 두면, 말로 설명하지 않아도 일정 영향이 보인다.

공통 개념 4 — 검색과 필터

이슈가 수백~수천 개 쌓이면, 검색·필터 없이는 아무것도 못 찾는다. "내게 할당된 채 아직 안 고쳐진 심각도 높은 이슈"처럼 조건을 조합해 찾는 기능(Jira의 JQL 등)은 도구마다 문법은 다르지만 개념은 같다 — 상태 + 담당자 + 필드값을 조합해 원하는 이슈 목록을 뽑아내는 것.

QA가 매일 쓰는 필터 다섯 개

필터는 만들어 저장해 두는 것이 전부다. 매번 조건을 다시 입력하는 사람은 결국 안 쓴다. QA라면 아래 다섯 개를 저장해 두면 하루가 달라진다.

첫 번째가 가장 중요하다. 재검증 대기가 쌓이면 개발은 끝났는데 결함이 계속 열려 있고, 릴리즈 직전에 한꺼번에 재검증하게 된다. 매일 아침 5분이면 그 상황을 막는다.

다섯 번째를 보는 사람이 드물다. 반려 사유는 내 리포트의 약점이 적힌 목록이다. 읽으면 같은 이유로 또 반려되는 일이 줄어든다(레슨 2).

대시보드 — 사람에게 보여 줄 숫자

저장된 필터 위에 숫자판을 얹으면 말하지 않아도 전달된다. 레슨 5에서 자세히 다루지만, 도구 쪽 관점에서 둘만 기억하면 된다.

• 대시보드는 보는 사람 기준으로 만든다 — QA용·개발 리드용·경영용이 다르다
• 숫자가 줄어드는 그림이 있어야 쓰인다. 쌓인 총량만 보여 주면 아무도 안 본다

템플릿으로 리포트 품질을 올린다

레슨 2의 다섯 요소를 도구의 설명란 템플릿에 넣어 둔다. 등록 화면을 열면 빈칸이 보이고, 빈칸은 채워진다.

## 환경
(환경 구분 / 빌드 / OS·브라우저 / 계정 종류 / 데이터 상태)
 
## 재현 절차
1.
2.
 
## 실제 결과
 
## 기대 결과 (근거: )
 
## 재현율        /
## 영향
## 증거

한 줄만 더하자면 "영향" 칸이다. 그 칸이 비어 있으면 우선순위를 정하는 사람이 판단할 재료가 없다(레슨 1).

이슈를 어디까지 등록하나

"이 정도는 올릴 가치가 있나" 라는 망설임이 자주 온다. 기준을 정해 두면 고민이 사라진다.

"말로 전하고 끝내는 것"만 피하면 된다. 말로 전한 결함은 그 대화가 끝나는 순간 사라지고, 나중에 "그거 얘기했는데요" 는 증거가 없다.

도구가 망가지는 네 가지 패턴

도구 탓으로 보이는 문제의 대부분은 운영 방식의 문제다.

네 번째가 가장 흔하고 가장 조용하다. 아무도 화를 내지 않는데 결함이 조금씩 쌓인다. 레슨 1에서 본 "New 체류 시간" 이 이것을 숫자로 보여 준다.

새 도구에 하루 만에 적응하는 순서

이직하거나 팀을 옮기면 낯선 도구를 만난다. 순서가 정해져 있다.

1. 이슈 하나를 열어 본다 — 필드 이름과 배치를 눈에 넣는다
2. 상태 목록을 확인한다 — 이 팀의 워크플로가 몇 단계인지
3. 누가 어떤 전이를 하는지 묻는다 — 특히 Closed 를 누가 하나
4. 라벨·컴포넌트 목록을 받는다 — 분류 규칙이 집계의 축이다
5. 필터 다섯 개를 만들어 저장한다 — 위 표 그대로

3번을 묻는 사람이 적다. 그런데 이 한 질문으로 그 팀의 결함 관리가 얼마나 단단한지 바로 알 수 있다. 아무나 닫을 수 있다고 하면, 재검증이 절차로만 존재한다는 뜻이다.

사례 — 필터 세 개로 밀린 결함 180건을 정리하기

인수한 프로젝트에 열린 결함이 180건 쌓여 있었다. 목록을 처음부터 읽는 것은 불가능했다. 필터 세 개로 갈랐다.

실제로 지금 중요한 것은 22건이었다. 180건이라는 숫자가 주던 막막함은 분류하지 않은 탓이었고, 도구를 바꿀 필요는 전혀 없었다.

두 번째 줄에서 배운 것이 있다. 6개월 넘게 New 상태인 결함은 대부분 "안 고칠 것" 이다. 그것을 열어 둔 채 두면 숫자가 거짓이 되고, 레슨 5의 지표가 전부 왜곡된다. 닫는 것도 결함 관리다 — 단, 닫는 사유를 적는다.

Jira 실습 관점에서 볼 것들

이 강의는 Jira 사용법 자체를 목표로 하지 않지만, 실습 삼아 Jira의 무료 클라우드 계정을 만들어 위 4가지 개념(이슈 타입, 워크플로, 필드, 필터)이 화면 어디에 대응하는지 직접 찾아보는 것을 권장한다. 화면 버튼의 정확한 위치보다, "이게 레슨 1의 어떤 개념에 해당하는가" 를 연결 짓는 게 이 레슨의 목표다.

Jira 자체를 실전 수준으로 다루는 것은 모듈 22(레슨 6~8) 에서 이어 받는다 — 프로젝트 유형과 필드 3층 구조, JQL과 저장된 필터, 그리고 대시보드로 품질 지표를 자동으로 굴리는 법이다. 이 레슨의 네 개념이 그 세 레슨의 뼈대가 되므로, 여기서 개념을 확실히 잡아두면 된다.

참고 — Atlassian이 Jira Cloud의 UI 용어를 '이슈'에서 '업무 항목(work item)'으로 변경했다. 화면에서 '이슈'라는 단어가 보이지 않아도 당황할 필요 없다. JQL과 API는 하위 호환을 위해 여전히 issue 를 쓴다.

실무에서 왜 필요한가

거의 모든 QA 채용공고에 "Jira 사용 경험"이 등장한다. 하지만 실무에서 도구는 회사마다, 심지어 같은 회사 안에서도 팀 전환 시 바뀔 수 있다. "Jira 버튼 위치"만 외운 사람은 도구가 바뀌면 처음부터 헤매지만, 공통 개념을 이해한 사람은 새 도구의 화면을 보자마자 "아, 이게 여기서 말하는 워크플로구나"라고 바로 적응한다. 이게 채용 면접에서 "다른 도구도 써보셨나요?"라는 질문에 자신 있게 답할 수 있는 근거가 된다.

도구를 다루는 것이 QA의 지분을 만든다

도구를 쓰는 사람과 운영하는 사람은 다르다. 후자가 되면 QA의 영향 범위가 눈에 띄게 넓어진다.

오른쪽이 되는 데 특별한 권한이 필요하지 않다. 필터 다섯 개를 만들어 팀에 공유하는 것에서 시작되고, 그것만으로도 "결함 관리를 보는 사람" 으로 자리가 생긴다.

채용시장에서의 위치

거의 모든 QA 공고에 "Jira 또는 유사 이슈 트래커 사용 경험" 이 있다. 그래서 이 항목은 가점이 아니라 통과 조건이다. 변별력은 다른 데서 나온다.

마지막 줄이 가장 힘이 있다. 도구 설정 한 줄로 재검증을 구조로 보장한 경험은 "도구를 운영해 본 사람" 의 증거다. 신입이 말할 수 있는 답은 아니지만, 알고 있다는 것만 보여도 다르게 읽힌다.

네 번째도 좋은 답이다. 밀린 결함 앞에서 분류 축을 먼저 만드는 사람과 위에서부터 읽는 사람의 차이는 하루와 일주일이다.

공고 표현으로는 "이슈 트래킹", "Jira/Redmine", "QA 프로세스 개선", "테스트 관리 도구" 가 이 레슨에 걸린다. 실전 운영은 모듈 22 레슨 6~8 에서 이어 받는다.

실습 과제

과제 1 — 개념 매핑표 만들기 (10분)

Jira(또는 사용해본 다른 이슈 추적 도구)를 하나 떠올려, 이 레슨에서 배운 4가지 공통 개념(이슈 타입/워크플로/필드/필터)이 그 도구의 어떤 화면·메뉴에 대응하는지 표로 정리한다. 써본 도구가 없다면 Jira 무료 계정을 만들어 화면을 직접 둘러보며 채운다.

과제 2 — 필터 조건 설계하기 (8분)

"내가 보고했지만 아직 종결되지 않은, 심각도가 높은 이슈만 보고 싶다"는 조건을 만족하는 필터를 어떤 필드들의 조합으로 구성할지 글로 적어본다.

보고자 = 현재 사용자
그리고 상태 ≠ Closed  (또는 상태 ∈ {New, Assigned, In Progress, Fixed})
그리고 심각도 ∈ {S1, S2}
정렬: 생성일 오래된 순

과제 3 — 밀린 결함 가르기 (12분)

열린 결함이 150건 쌓인 프로젝트를 맡았다고 가정한다. 처음 세 개의 필터를 어떤 조건으로 만들지 적고, 각 필터의 결과를 어떻게 처리할지 한 줄씩 쓴다.

자가 체크리스트

• 이슈 타입·워크플로·필드·필터라는 4가지 공통 개념을 설명할 수 있다
• 결함 생명주기(레슨 1)가 이슈 추적 도구의 워크플로와 같은 개념임을 안다
• 심각도·우선순위 외에 담당자·보고자·라벨·연결 필드의 역할을 설명할 수 있다
• 도구가 바뀌어도 공통 개념을 기반으로 빠르게 적응할 수 있다고 설명할 수 있다
• 같은 개념이 Jira·GitHub Issues·Redmine 에서 어떤 이름인지 짚을 수 있다
• Bug / 개선 요청 / Question 을 가르는 기준을 설명할 수 있다
• Fixed → Closed 를 보고자만 하게 막는 것이 왜 중요한지 말할 수 있다
• 필수 필드를 다섯 개 안쪽으로 두는 이유를 설명할 수 있다
• 라벨·컴포넌트 분류가 레슨 5의 지표에서 어떤 축이 되는지 안다
• 연결 세 종류(중복·관련·차단)의 쓰임을 구분할 수 있다
• QA가 저장해 둘 필터 다섯 개를 말할 수 있다
• 밀린 결함을 가르는 세 축을 말할 수 있다
• 새 도구에 적응할 때 상태 목록과 전이 권한부터 확인하는 이유를 안다

흔한 실수

• 도구 사용법(버튼 위치)만 암기하고 개념을 이해하지 않는다. 도구가 바뀌면 처음부터 다시 배워야 한다.
• 모든 이슈를 Bug로만 등록한다. 개선 요청이나 작업(Task)까지 전부 Bug로 등록하면 통계(레슨 5)가 왜곡된다.
• 라벨/컴포넌트 분류를 대충 채우거나 생략한다. 나중에 "어느 기능 영역에서 결함이 많이 나오는가"를 분석할 때 이 분류가 없으면 집계 자체가 불가능하다.
• 필수 필드를 계속 늘린다. 바쁜 사람이 빈칸으로 남기거나 아무 값이나 넣는다. 틀린 집계는 빈칸보다 나쁘다.
• 아무나 Closed 로 보낼 수 있게 둔다. 재검증이 조용히 건너뛰어진다. 전이 권한으로 막는 것이 절차보다 확실하다.
• 자동화로 Closed 까지 보낸다. 아무도 확인하지 않은 결함이 통계상 종결된다. 자동화는 Retest 대기까지만 쓴다.
• 라벨을 자유 입력으로 둔다. 같은 영역이 세 가지 이름으로 쌓이고 집계가 쪼개진다. 목록을 고정한다.
• 필터를 매번 새로 입력한다. 결국 안 쓰게 된다. 다섯 개를 저장해 둔다.
• 반려된 내 이슈를 다시 안 본다. 반려 사유는 내 리포트의 약점이 적힌 목록이다.
• 결함을 말로만 전한다. 대화가 끝나는 순간 사라지고 "얘기했는데요" 는 증거가 없다.
• 오래된 New 를 열어 둔 채 둔다. 관리하는 것이 아니라 지표가 거짓이 된다. 사유를 적고 닫는 것도 결함 관리다.
• 도구를 바꿔 문제를 해결하려 한다. 증상의 대부분은 운영 방식이 원인이고, 도구를 옮기면 같은 문제가 따라온다.

참고 자료

• Atlassian Jira 공식 문서 — Workflow — 워크플로 개념의 공식 설명
• ISTQB Glossary — Incident Management Tool — 이슈 추적 도구의 공식 용어 정의
• Atlassian — JQL 함수 참조 — currentUser() 등 필터에 쓰는 함수
• GitHub Docs — Issues 라벨과 마일스톤 — 상태가 둘뿐인 도구에서 분류를 대신 쓰는 방식

이 커리큘럼 안에서

• 모듈 6 레슨 1 — 결함 생명주기. 워크플로의 내용 그 자체
• 모듈 6 레슨 2 — 결함 리포트. 템플릿으로 품질을 구조화한다
• 모듈 6 레슨 3 — 비난 없는 소통. 기록이 남는 곳이 어디인가
• 모듈 6 레슨 5 — 품질 지표. 라벨·분류가 그 집계의 축이 된다
• 모듈 4 레슨 5 — Go/No-Go. "미해결 고위험" 필터가 그 자료다
• 모듈 10 — 결함 분석. 원인 유형 분류를 어떻게 설계하나
• 모듈 22 레슨 6~8 — Jira 실전: 필드 3층 구조, JQL, 대시보드

한 줄 정리 — 도구는 다르고 개념은 같다(이슈 타입·워크플로·필드· 필터). 필수 필드는 다섯 개 안쪽, 라벨은 집계의 축, Fixed → Closed 는 보고자만 — 이 세 가지 설정이 결함 관리를 절차가 아니라 구조로 만든다. 그리고 밀린 결함은 재검증 대기 · 오래된 New · 고위험 미해결 세 축으로 가른다.