Jira 티켓 200개, 어디부터 시작해야 할까?

04 Dec, 2025
- 배포

월요일 아침의 선물

출근했다. Jira 열었다. 미해결 티켓 203개.

금요일에 180개였는데. 주말 사이 23개가 더 생겼다. 핫픽스 배포했다가 새 버그가 나온 거다. 예상했다.

커피 한 잔 마시고 화면을 봤다. P1, P2, P3, P4가 뒤섞여 있다. 어떤 건 상태가 “재확인 필요”, 어떤 건 “개발 완료 대기”. 정리 안 된 티켓이 반은 넘는다.

팀장이 슬랙 보냈다. “민수야, 이번 주 목표 티켓 30개 처리. 가능하지?”

30개. 하루에 6개씩이다. 재현 시간, 확인 시간, 리포트 작성 빼면 불가능하다. 하지만 “네” 라고 답장했다. 어차피 할 거니까.

우선순위라는 이름의 정치

P1부터 봤다. 41개다.

심각도 높음, 긴급 처리. 그런데 진짜 긴급한 건 10개도 안 된다. 나머지는 누군가 급하다고 우긴 것들이다.

“로그인 안 됨” - P1 맞다. “프로필 이미지 안 뜸” - P2인데 기획자가 P1 박았다. “특정 기종에서 폰트 이상” - P3이다. 근데 대표님 폰이라서 P1.

우선순위는 기술적 판단이 아니다. 정치다.

개발팀장은 자기 팀 버그는 P3로 낮추고 싶어 한다. 기획팀은 자기가 만든 기능 버그는 P1로 올리고 싶어 한다. 영업팀은 클라이언트가 말한 건 뭐든 P1이다.

결국 내가 판단해야 한다. 실제 사용자 영향도로.

기준을 만들었다. 엑셀에 정리했다.

P1 (10개)

앱 크래시
핵심 기능 동작 안 함
데이터 손실 가능성
보안 이슈

P2 (35개)

주요 기능 오작동
특정 기종 크래시
UI 심각하게 깨짐
결제 관련 오류

P3 (98개)

부가 기능 오류
텍스트 오타
디자인 의도와 다름
특정 상황에서만 재현

P4 (60개)

개선 제안
극히 드문 케이스
차기 버전 고려
스펙 논의 필요

재분류했다. 기획자한테 메신저 왔다. “민수님, 제가 P1 올린 건데요?”

“사용자 영향도 낮아서 P2로 조정했습니다.”

“근데 팀장님이 중요하다고 하셨거든요.”

“팀장님께 제가 말씀드릴게요.”

이런 대화를 5번 했다. 점심 전에.

현실적인 처리 계획

10개 P1부터 시작했다.

하지만 순서가 있다. 재현 가능한 것부터다.

“특정 조건에서 크래시” - 재현 스텝 불명확. 개발자한테 물어봐야 함. 나중. “로그인 실패” - 바로 재현 가능. 지금. “결제 오류” - QA 서버에서 테스트 가능. 지금.

엑셀에 컬럼 추가했다.

재현 가능 여부
예상 소요 시간
의존성 (다른 티켓이나 개발자 답변 필요)
테스트 환경 (Dev/QA/Prod)

P1 10개 계획 세웠다.

즉시 처리 가능: 4개 (2시간)
개발자 확인 필요: 3개 (대기 후 1시간)
특수 환경 필요: 2개 (내일 오전)
재현 불가: 1개 (리포터 추가 정보 요청)

4개부터 시작했다.

첫 번째 버그. 로그인 화면에서 백버튼 누르면 크래시.

재현했다. Charles로 네트워크 확인했다. API 응답은 정상. 앱 로그 확인. Null Pointer Exception.

스크린샷 3장, 로그 파일, 재현 스텝 정리해서 Jira 업데이트. 개발자 assign. 20분 걸렸다.

두 번째 버그. 결제 완료 후 화면 멈춤.

재현 안 됨. QA 서버에서는. Prod에서만 발생한다는 리포트. 운영팀한테 Prod 로그 요청. 대기.

세 번째로 넘어갔다.

효율이다. 막힌 건 넘어가고 진행 가능한 것부터. 하루 종일 한 티켓만 붙잡고 있을 수 없다.

오후 3시. P1 4개 처리했다. P2 시작했다.

리소스 관리의 현실

하루에 처리 가능한 티켓 수는 정해져 있다.

단순 계산. 근무 8시간.

회의 1시간
점심 1시간
이메일/슬랙 응대 1시간
실제 작업 시간 5시간

버그 하나당 평균 소요 시간.

재현: 15분
원인 파악: 20분
리포트 작성: 15분
개발자 커뮤니케이션: 10분
총 60분

하루 5개가 현실적이다.

근데 예상 밖 변수가 있다.

재현 안 되는 버그: +30분
디바이스 세팅 시간: +20분
긴급 이슈 터짐: +1시간
기획 스펙 확인: +30분

실제로는 하루 3-4개다.

주 5일이면 15-20개. 팀장이 원하는 30개가 안 된다.

솔직하게 말했다. “30개는 어렵습니다. 현실적으로 20개 목표 잡겠습니다.”

“왜 안 돼?”

“평균 처리 시간이 1시간인데, 예상 외 이슈 대응 시간 빼면 하루 4개가 한계입니다.”

“야근하면 되지 않아?”

“야근해도 집중력 떨어지면 버그 놓칩니다. 그럼 배포 후 더 큰 문제 됩니다.”

팀장 표정이 안 좋았다. 하지만 인정했다. “알았어. 20개 목표로 하자.”

숫자로 말하니까 통했다. 감정이 아니라 데이터로.

배치의 기술

200개를 20개씩 나눴다. 10주 걸린다.

현실성 없다. 그 사이 새 티켓이 100개는 더 생긴다.

다른 방법이 필요하다. 배치 처리.

비슷한 버그끼리 묶었다.

로그인 관련 (8개)

한 번에 테스트 환경 세팅
연속으로 처리하면 컨텍스트 스위칭 없음
2시간 안에 끝

결제 플로우 (12개)

QA 서버 결제 테스트 계정 필요
한 번에 몰아서 테스트
3시간

UI 버그 (25개)

디바이스별 확인
스크린샷 찍으면서 체크리스트
2시간

특정 기종 이슈 (15개)

해당 디바이스 세팅 한 번만
4시간

월요일: 로그인 + 회원가입 관련 화요일: 결제 플로우 수요일: UI 버그 집중 목요일: 특정 기종 테스트 금요일: 긴급 이슈 대응 + 정리

효율이 올라갔다. 컨텍스트 스위칭이 줄었다. 테스트 환경 세팅을 반복 안 해도 됐다.

첫 주에 23개 처리했다. 목표보다 3개 더.

커뮤니케이션 비용

버그 처리보다 시간 많이 드는 게 있다. 설명이다.

개발자: “이거 재현 안 되는데요?” 나: “재현 스텝 Jira에 있습니다.” 개발자: “그대로 했는데 안 돼요.” 나: “화면 공유 해드릴까요?” 개발자: “네.”

화면 공유 10분. 재현 보여줌.

개발자: “아 제 빌드가 달라서 그런가 봐요.” 나: ”…”

이런 일이 하루에 5번.

그래서 리포트 양식 만들었다.

[재현 스텝]
1. 앱 실행
2. 로그인 (테스트 계정: qa_test01)
3. 마이페이지 진입
4. 프로필 수정 버튼 탭
5. 닉네임 입력 (20자 이상)
6. 저장 버튼 탭
→ 크래시 발생

[환경]
- 빌드: v2.3.1 (build 451)
- OS: Android 13
- 기기: Galaxy S23
- 서버: QA 서버

[로그]
(첨부)

[기대 동작]
닉네임 저장 후 완료 토스트 메시지

[실제 동작]
앱 크래시, 재실행 시 닉네임 변경 안 됨

[추가 정보]
iOS에서는 정상 동작 확인

이렇게 쓰니까 “재현 안 돼요” 가 줄었다.

하지만 여전히 질문은 온다.

기획자: “이거 버그예요 스펙이에요?” 나: “스펙 문서에는 A인데 실제는 B입니다.” 기획자: “음… 원래 B가 맞는 것 같은데.” 나: “그럼 스펙 문서 수정해주세요.” 기획자: “네, 근데 이미 개발된 거 바꾸기 애매한데…”

이런 대화 20분. 결론은 “다음 회의 때 논의”.

티켓 상태를 “Pending - 스펙 확인 중”으로 바꿨다. 내 할 일 목록에서 뺐다. 안 그러면 계속 신경 쓰인다.

포기의 기술

200개를 다 할 수 없다는 걸 인정했다.

P4 60개는 사실상 안 한다. “차기 버전 검토” 라벨 붙이고 백로그로 보냈다.

P3 중에서도 “재현 불가” 30개는 “추가 정보 필요” 상태로 리포터한테 돌려보냈다. 1주일 안에 답 안 오면 자동 종료.

실제 처리 대상은 110개.

이것도 많다. 하지만 200개보다 심리적으로 낫다.

팀장한테 보고했다. “P4 60개는 다음 분기로 이관하겠습니다.”

“왜?”

“리소스 대비 사용자 영향도가 낮습니다. 대신 P1, P2를 2주 안에 정리하겠습니다.”

“음… 알았어.”

전부 다 하려고 하면 중요한 것도 못 한다. 포기할 걸 정하는 것도 능력이다.

진행 상황 추적

매일 아침 30분. 엑셀 업데이트했다.

[주간 목표]
목표: 20개
완료: 23개
진행중: 5개
블록: 3개

[티켓 상태]
Open: 176개 (203→176, -27)
In Progress: 8개
Pending: 12개
Resolved: 15개 (이번 주)

숫자가 보이니까 뿌듯했다. 203에서 176. 한 주만에 27개 줄었다.

물론 새로 생긴 것도 있다. 하지만 처리 속도가 더 빠르다.

팀장한테 주간 리포트 보냈다. 슬랙에 공유했다.

개발팀장이 답했다. “오 민수님 고생 많으시네요.”

인정받는 기분. 나쁘지 않다.

자동화의 유혹

P3 중에 반복 작업이 많다.

“5개 기종에서 UI 확인” - 30분씩 5번, 2시간 반. “20개 화면 레이아웃 체크” - 1시간.

자동화하면 30분으로 줄어든다.

문제는 자동화 스크립트 짜는 데 5시간 걸린다는 거다.

계산했다. 이 테스트를 앞으로 10번 이상 할 거면 본전이다.

UI 회귀 테스트는 매 배포마다 한다. 2주에 한 번. 1년이면 26번.

투자 가치 있다.

퇴근 후 집에서 Appium 튜토리얼 봤다. 2시간.

간단한 스크립트 짰다. 5개 화면 자동 캡처. 1시간 걸렸다.

아직 완벽하지 않다. 하지만 시작했다.

다음 주부터 하나씩 자동화 케이스 늘리기로 했다.

실전 팁

200개 티켓 앞에서 멘붕 안 오려면.

1. 일단 분류부터 우선순위 재조정. 30분 투자해서 전체 보기.

2. 배치 처리 비슷한 것끼리 묶어서. 컨텍스트 스위칭 줄이기.

3. 블로킹 이슈 따로 관리 진행 안 되는 건 Pending 처리. 내 리스트에서 빼기.

4. 매일 목표 작게 하루 5개. 달성 가능한 숫자.

5. 숫자로 추적 엑셀이든 뭐든. 진행 상황 시각화.

6. 커뮤니케이션 효율화 리포트 템플릿. 반복 질문 줄이기.

7. 포기할 것 정하기 P4는 과감히 백로그로. 집중력 분산 방지.

8. 자동화 조금씩 반복 작업부터. 5시간 투자해서 20시간 아끼기.

한 달 후

4주 지났다.

Jira 티켓 128개. 203에서 75개 줄었다.

물론 새로 생긴 것도 있다. 하지만 관리 가능한 수준이다.

팀장이 말했다. “민수야, 이번 달 티켓 처리율 좋던데?”

“네, 배치 처리 방식 바꿔서요.”

“다른 팀원들도 좀 공유해줘.”

오후에 팀 회의. 내 방법 설명했다. 15분.

신입 QA가 물었다. “그럼 우선순위는 누가 정해요?”

“우리가 정해야죠. 사용자 영향도 기준으로.”

“근데 기획팀에서 P1 올리면요?”

“데이터로 설명하세요. 사용자 몇 명한테 영향 가는지, 얼마나 자주 발생하는지.”

신입이 고개 끄덕였다.

회의 끝나고 슬랙에 정리 문서 공유했다. 내가 쓴 엑셀 템플릿이랑 우선순위 기준표.

3명이 따봉 달았다.

티켓은 계속 쌓인다. 하지만 이제 안다. 전부 다 할 필요 없다는 걸. 중요한 것부터, 효율적으로, 숫자로 증명하면서. 그게 프로고 살아남는 방법이다.