개념
먼저 알아둘 용어 변화 — 이슈가 업무 항목이 되었다
Jira를 오랜만에 열었거나 자료를 검색해 본 사람은 용어가 어긋나서 당황할 수 있다. Atlassian이 Jira Cloud의 UI 용어를 "이슈(issue)"에서 "업무 항목(work item)"으로 바꿨기 때문이다. 플랜별로 순차 적용됐고, 지금 화면에서는 "이슈 만들기" 대신 "만들기", "이슈"라는 단어 대신 "업무 항목" 또는 "작업"이 보인다.
중요한 것은 바뀐 것이 표시 용어뿐 이라는 점이다.
| 예전 표현 | 지금 | |
|---|---|---|
| 화면 용어 | 이슈(Issue) | 업무 항목(Work item) |
| JQL | issuetype = Bug | 그대로 동작(하위 호환 유지) |
| REST API | /rest/api/3/issue/... | 그대로 |
| URL·키 | QA-123 | 그대로 |
| 워크플로·필드·권한 | 동작 변화 없음 |
그래서 이 레슨은 화면 설명에는 '업무 항목'을, JQL·API 문맥에서는 'issue'를 쓴다. 실무에서도 팀원마다 두 단어를 섞어 쓰게 되는데, 같은 것을 가리킨다 는 사실만 알면 혼선은 없다. 자료를 검색할 때 2025년 이전 글은 전부 "이슈"로 쓰여 있으니 참고하면 된다.
모듈 6(레슨 4)에서 "도구는 다르지만 개념은 같다"고 배웠다. 여기에 한 줄 더한다 — 같은 도구 안에서도 이름은 바뀐다. 개념을 붙잡아야 오래 간다.
프로젝트는 무엇을 담는 그릇인가
Jira에서 프로젝트 는 업무 항목이 담기는 그릇이자, 워크플로·필드· 권한 설정이 적용되는 단위다. QA가 프로젝트를 직접 만들 일은 많지 않지만, 프로젝트가 어떻게 설정돼 있느냐가 우리 일의 상당 부분을 결정한다. 결함에 어떤 필드를 넣을 수 있는지, 어떤 상태로 옮길 수 있는지, 누가 볼 수 있는지가 전부 프로젝트 설정에서 나온다.
프로젝트를 만들 때 정하는 것은 크게 셋이다.
1) 템플릿 — 스크럼이냐 칸반이냐
| 칸반 | 스크럼 | |
|---|---|---|
| 작업 단위 | 흐름(연속적) | 스프린트(1~4주 반복) |
| 계획 방식 | 우선순위 큐에서 당겨 씀 | 스프린트 시작 시 범위 확정 |
| 대표 지표 | 리드 타임, WIP | 벨로시티, 번다운 |
| QA에게 주는 차이 | 언제든 새 작업이 들어옴 → 회귀 범위가 유동적 | 범위가 고정 → 테스트 계획을 세우기 쉬움 |
| 잘 맞는 팀 | 운영·유지보수·서비스 데스크 | 기능 개발 팀 |
모듈 7(레슨 4)에서 배운 방법론 차이가 도구 설정으로 나타나는 지점이다. QA 입장에서 실질적인 차이는 마지막 줄에 있다 — 칸반 팀에서는 "이번에 무엇을 테스트해야 하는가"가 계속 변한다.
2) 프로젝트 유형 — 팀 관리형이냐 회사 관리형이냐
이 선택이 나중에 가장 많은 영향을 준다.
| 팀에서 관리(Team-managed) | 회사에서 관리(Company-managed) | |
|---|---|---|
| 설정 주체 | 팀이 직접 | Jira 관리자 |
| 설정 공유 | 프로젝트마다 독립 | 여러 프로젝트가 스키마를 공유 |
| 워크플로 편집 | 제한적 | 자유롭게 편집 |
| 권한 체계 | 액세스 레벨 중심(단순) | 세밀한 권한 스키마 |
| 시작 속도 | 빠름 | 느림(관리자 협의 필요) |
| 적합한 규모 | 소규모·단일 팀 | 여러 팀·표준화가 필요한 조직 |
QA가 알아둬야 할 실무 포인트 두 가지.
- 회사 관리형에서는 한 프로젝트의 설정 변경이 같은 스키마를 쓰는 다른 프로젝트에 영향을 준다. "결함 필드 하나 추가해주세요"가 간단한 요청이 아닌 이유다.
- 팀 관리형 → 회사 관리형 전환은 간단한 작업이 아니다. 나중에 전사 표준화가 예상된다면 처음부터 회사 관리형으로 시작하는 편이 낫다.
3) 액세스 수준
| 수준 | 누가 볼 수 있나 | 무엇을 할 수 있나 |
|---|---|---|
| 비공개(Private) | 관리자 + 명시적으로 추가된 사람 | 검색·디렉터리에도 노출되지 않음 |
| 제한(Limited) | 로그인한 모든 사용자 | 보기·댓글만 가능(생성·편집 불가) |
| 공개(Open) | 로그인한 모든 사용자 | 보기·생성·편집 가능 |
보안 검증이나 취약점 이슈를 다루는 프로젝트라면 비공개가 기본이다. 모듈 23에서 다루는 보안 테스트 결과를 전사 공개 프로젝트에 그대로 올리는 것은 그 자체로 사고다.
업무 항목의 계층 구조
Jira는 작업을 계층으로 관리한다. 기본 계층은 이렇다.
[상위 플랜에서 추가 가능]
Initiative / 전략 목표 ← 여러 에픽을 묶는 상위 레벨
│ (Premium 이상의 플랜 기능)
┌────▼─────────────────────────────────────┐
│ Epic (에픽) │ 큰 기능·프로젝트 단위
└────┬─────────────────────────────────────┘
┌────▼──────────┬──────────────┬───────────┐
│ Story (스토리) │ Task (작업) │ Bug (버그) │ 표준 레벨
└────┬──────────┴──────────────┴───────────┘
┌────▼─────────────────────────────────────┐
│ Sub-task (하위 작업) │ 더 잘게 쪼갠 단위
└──────────────────────────────────────────┘각 유형의 성격은 이렇게 구분된다.
- Epic — 여러 스토리로 쪼개지는 큰 기능 단위. "결제 수단 확대"
- Story — 사용자 관점에서 정의된 요구사항. "사용자는 카카오페이로 결제할 수 있다". 모듈 2에서 배운 사용자 스토리가 여기에 들어온다
- Task — 사용자 가치로 표현되지 않는 작업. "결제 모듈 라이브러리 업그레이드"
- Bug — 결함. QA가 가장 많이 만드는 유형
- Sub-task — 위 항목들을 더 쪼갠 단위
- Initiative 같은 에픽 위 계층은 플랜에 따라 제공 여부가 다르다. 기본 계층은 Epic 아래라고 기억하고, 상위 계층이 보인다면 그 조직이 상위 플랜에서 계층을 추가한 것이다
QA는 무엇을 어디에 등록하는가. 실무에서 자주 헷갈리는 지점이라 기준을 정리해둔다.
| 상황 | 등록 위치 |
|---|---|
| 기능이 명세대로 동작하지 않음 | Bug |
| 명세 자체가 잘못됨·모호함 | Story에 댓글 + 필요시 별도 Task(문서 수정) |
| 테스트 케이스 작성·회귀 수행 같은 QA 작업 | Task(스프린트에 넣어 가시화) |
| 결함이 아니지만 개선하면 좋은 것 | Improvement(있다면) 또는 Task |
| 큰 결함이 여러 화면에 걸쳐 있음 | Bug 하나 + Sub-task로 화면별 분리 |
세 번째 줄을 강조하고 싶다. QA 작업을 Jira에 등록하지 않으면 그 일은 조직에서 보이지 않는다. 스프린트 회고에서 "QA가 병목"이라는 말이 나오는데 정작 QA의 작업량은 아무 데도 기록돼 있지 않은 상황이 흔하다. 테스트 설계·환경 구축·회귀 수행을 Task로 올리는 것만으로도 논의의 근거가 생긴다.
업무 항목을 만드는 세 가지 경로
같은 결과를 만드는 세 경로가 있고, 각각 쓰기 좋은 상황이 다르다.
| 경로 | 위치 | 언제 쓰나 |
|---|---|---|
| 상단 [만들기] 버튼 | 어디서든 | 테스트 중 결함을 발견했을 때 — 맥락 전환 없이 바로 |
| 백로그의 [+ 만들기] | 백로그 화면 | 계획 회의 중 여러 건을 연속으로 넣을 때 |
| 보드의 [+ 만들기] | 칸반·스크럼 보드 | 진행 중인 스프린트에 즉시 넣어야 할 때 |
목록을 보는 방식도 넷이다 — 목록(List), 보드(Board), 백로그(Backlog), 검색(Issue Search). QA가 가장 많이 쓰게 되는 것은 검색이고, 그 이야기는 다음 레슨에서 JQL로 이어진다.
연결(Link) 유형 — 관계를 남기면 나중에 설명이 필요 없다
업무 항목끼리 관계를 걸 수 있다. QA 실무에서 특히 값을 하는 네 가지다.
| 유형 | 의미 | QA가 쓰는 상황 |
|---|---|---|
| 차단함(blocks / is blocked by) | 한쪽이 다른 쪽의 진행을 막음 | "이 결함 때문에 해당 스토리를 검증할 수 없다" |
| 복제됨(clones) | 복제본 관계 | 같은 결함을 다른 버전·브랜치에도 등록할 때 |
| 중복됨(duplicates) | 중복 | 이미 등록된 결함을 다시 발견했을 때 |
| 관련됨(relates to) | 느슨한 연관 | 같은 원인일 가능성이 있는 결함들 묶기 |
'차단함'이 가장 강력한 도구다. "테스트를 못 하고 있습니다"라고 말로 하는 것과, 스토리 화면에 "QA-412에 의해 차단됨"이 표시되는 것은 전달력이 완전히 다르다. 모듈 6(레슨 3)에서 배운 비난 없는 소통 원칙에도 맞는다 — 사람을 지목하지 않고 상태를 드러내는 방식이기 때문이다.
'중복됨'을 쓸 때 주의할 점도 있다. 중복으로 닫기 전에 재현 조건이 정말 같은지 확인해야 한다. 증상만 같고 원인이 다른 결함을 중복으로 닫으면 하나는 영영 고쳐지지 않는다.
필드 3층 구조 — 결함 리포트 품질을 구조로 강제하기
여기가 이 레슨에서 가장 실무적인 부분이다. 모듈 6(레슨 2)에서 좋은 결함 리포트의 조건을 배웠다 — 재현 절차, 실제 결과와 기대 결과, 증거. 그런데 아무리 교육해도 사람은 빈칸을 비워둔다. 이걸 구조로 강제할 수 있다.
Jira의 필드 설정은 세 층으로 되어 있다.
① 사용자 지정 필드 (Custom Field)
"재현 단계", "발견 환경", "브라우저", "빌드 번호" 같은
필드를 만든다. 텍스트·선택목록·날짜·사용자 선택 등 유형 선택
↓
② 필드 구성 (Field Configuration)
각 필드의 동작을 정의한다 —
필수인가? 숨김인가? 기본값은? 설명 문구는?
↓
③ 필드 구성 구성표 (Field Configuration Scheme)
어떤 업무 유형에 어떤 구성을 적용할지 연결한다 —
Bug → 재현 단계 필수 / Task → 예상 소요 시간 필수이 3층을 이해하면 QA가 할 수 있는 제안이 달라진다.
"결함 리포트에 재현 절차를 꼭 써주세요"(→ 지켜지지 않음)
↓
"Bug 유형에 '재현 단계' 필드를 필수로 걸고, 설명 문구에 '1. 2. 3. 번호로 작성' 예시를 넣어주세요"(→ 구조가 강제함)
필수 필드를 늘리는 것에는 대가가 있다. 등록이 번거로워지면 사람들이 결함을 아예 등록하지 않거나, 필수 칸에 "-"를 채워 넣는다. 그래서 실무 기준은 이렇다 — 필수는 3~5개를 넘기지 않는다. 나머지는 설명 문구와 템플릿으로 유도한다.
프로젝트 수준에서 설정하는 경로(프로젝트 설정 → 업무 유형 → 유형 선택· 편집)와 글로벌 수준(설정 → 이슈 → 필드)의 차이도 알아두면 좋다. 팀 관리형은 대체로 프로젝트 안에서, 회사 관리형은 글로벌 스키마에서 결정된다. 그래서 회사 관리형 프로젝트에서 필드 하나 바꾸는 요청은 관리자를 거쳐야 하고, 다른 프로젝트에 영향이 없는지 확인이 필요하다.
일괄 편집 — 손으로 100번 클릭하지 않기
릴리즈 후 "이번 버전에서 해결된 결함 47건에 픽스 버전을 붙여주세요" 같은 요청이 온다. 하나씩 열어서 고치면 한 시간이 걸린다.
일괄 편집(Bulk Edit) 은 검색 결과에서 더보기(···) → 일괄 편집으로 들어간다. 대상 선택 → 수정할 필드 값 입력 → 확인 순서다.
QA가 실제로 쓰게 되는 경우들이다.
- 릴리즈 후 픽스 버전·레이블 일괄 부여
- 담당자 퇴사·조직 개편에 따른 담당자 이관
- 종료된 스프린트에 남은 항목의 재배치
- 오래된 결함의 일괄 상태 정리(주의해서)
주의 두 가지. 일괄 편집은 되돌리기가 어렵다. 실행 전에 검색 조건이 정확한지 반드시 확인하고, 건수가 예상과 다르면 멈춘다. 그리고 알림이 대량 발송될 수 있으므로, 큰 건은 알림 옵션을 확인하고 실행한다.
실무에서 왜 필요한가
QA는 Jira를 가장 많이, 가장 오래 쓰는 직군 중 하나다. 하루의 상당 시간이 결함 등록·검색·상태 갱신에서 흘러간다. 그래서 이 도구를 화면 기준으로 익히는 것과 구조 기준으로 익히는 것의 차이가 몇 년치 생산성으로 누적된다.
특히 필드 3층 구조를 이해하는 QA는 조직에서 위치가 달라진다. 결함 리포트 품질 문제를 교육으로 풀려는 사람과 구조로 푸는 사람 의 차이다. 전자는 매번 같은 요청을 반복하고, 후자는 한 번 설계해두고 문제를 없앤다. 후자의 제안은 프로젝트 관리자·Jira 관리자와 대화가 되는 언어로 나온다.
프로젝트 유형과 액세스 수준 지식도 실제로 쓰인다. "이 결함을 협력사와 공유해도 되나요", "왜 나는 이 프로젝트가 안 보이나요" 같은 질문에 답할 수 있는 사람이 팀에 한 명은 있어야 하는데, 그 사람이 QA인 경우가 많다.