재작년에도 Jira를 한 번 깔아본 적이 있습니다. 2주 쓰고 아무도 안 들어가서 조용히 묻혔어요.
이번엔 상황이 달랐습니다. 올해 12월 말에 끝나는 과제가 하나 있는데, 산출물 15종하고 성과지표 12종을 기한 안에 끝내고 "끝냈다는 증거"까지 남겨야 하는 조건이었거든요. 엑셀 일정표로는 증거가 안 남습니다. 파일을 덮어쓰면 어제 상태가 사라지니까요.
그래서 10월 6일부터 다시 깔았습니다. 11일간의 기록이고, 중간에 제가 잘못 잡았다가 뒤집은 게 두 군데 있습니다. 그 부분이 이 글의 핵심입니다.
10/6 — 스페이스를 하나로 가려다 둘로 쪼갰다
처음엔 스페이스 하나로 가려고 했습니다. 팀이 크지 않으니 굳이 나눌 이유가 없다고 봤어요.
이슈를 30개쯤 올려보고 바로 접었습니다.
올라온 이슈를 보니 성격이 완전히 달랐어요.
- 11월 말까지 공인시험 성적서 받기 — 기한이 월 단위, 한 달간 상태가 안 바뀜
- 주문 목록 금액 콤마 안 찍히는 거 수정 — 오늘 시작해서 오늘 끝남
이 둘이 한 보드에 섞이니까, 개발 이슈가 올라올 때마다 월 단위 일정이 화면 아래로 밀려났습니다. 보드를 열면 당장 급한 것만 보이고 정작 기한 놓치면 큰일 나는 건 안 보여요.
그래서 둘로 나눴습니다.
스페이스 보드 담는 것
| 사업관리 | 칸반 | 산출물 15종, 성과지표 12종, 월별 마일스톤, 행정 증빙 |
| 개발 | 스크럼 | 에픽 5개 아래 스토리·작업·버그 |
칸반이냐 스크럼이냐로 한참 봤는데, 결국 제가 쓴 기준은 하나였습니다. 기한이 월 단위면 칸반, 주 단위로 끊어 도는 일이면 스크럼. 사업관리 쪽은 스프린트라는 개념이 아예 안 맞더라고요.
10/7 — 상태를 7개로 만들었다가 3개로 줄였다
여기가 첫 번째 삽질입니다.
처음에 워크플로를 이렇게 짰어요.
해야 할 일 → 진행 중 → 검토 대기 → 승인 대기 → 완료
↘ 보류 ↘ 재작업 요청
현실을 반영한 것 같아서 뿌듯했습니다. 실제 결재 흐름이 저렇거든요.
이틀 쓰고 알았습니다. 상태가 많으면 사람들이 상태를 안 바꿉니다.
"이거 검토 대기인가 승인 대기인가?" 하고 1초 고민하는 순간 그냥 창을 닫아버려요. 그래서 보드가 거짓말을 시작합니다. 실제로는 끝난 일이 이틀째 "진행 중"에 박혀 있는 거죠.
세 개로 줄였습니다.
해야 할 일 / 진행 중 / 완료. 끝.
대신 규칙을 하나 붙였습니다. "진행 중"은 작업을 시작할 때 미리 옮긴다. 코드 고치기 전에, 문서 쓰기 전에 먼저 옮기는 거예요. 저도 처음엔 반대로 했습니다. 일 다 하고 나중에 한꺼번에 옮겼는데, 그러면 그날 뭘 했는지 기억이 안 나서 기록이 뭉개집니다.
검토·승인 단계는 상태 대신 댓글로 남기기로 했습니다. 어차피 증거로 필요한 건 "누가 언제 확인했나"지, 보드 컬럼이 아니었어요.
10/9 — 아침에 눈으로 보드 훑는 걸 포기했다
이슈가 200개를 넘어가니까 보드를 눈으로 훑는 게 불가능해졌습니다.
Jira에는 검색 조건을 저장해두는 기능이 있습니다. 9개 만들었는데, 매일 여는 건 결국 세 개였어요.
1. 3일 이상 미갱신
project in (사업관리, 개발) AND status != Done
AND updated <= -3d ORDER BY updated ASC
사흘 동안 아무 변화 없는 미완료 이슈. 썩고 있는 일을 잡아내는 용도입니다.
2. 기한 초과
duedate < now() AND status != Done ORDER BY duedate ASC
3. 미배정
assignee IS EMPTY AND status != Done
목표는 셋 다 0건입니다. 아침에 이 세 개만 눌러보면 10초 만에 상황 파악이 끝납니다.
솔직히 이거 만들기 전과 후가 제일 차이 컸어요. 보드는 "뭐가 있는지"를 보여주는데, 필터는 "뭐가 문제인지"를 보여줍니다. 매일 봐야 하는 건 후자더라고요.
10/12 — 커밋 메시지에 이슈 키 넣기
GitLab을 붙였습니다. 설정 자체는 10분이면 끝납니다.
하는 일은 하나예요. 커밋 메시지 맨 앞에 이슈 키를 쓰면, 그 커밋이 해당 이슈의 댓글로 자동으로 달립니다.
git commit -m "DEV-142 주문 목록 금액 콤마 미표시 수정"
이것만 지키면 나중에 "이 코드는 왜 바뀐 거죠?"라는 질문에 이슈 번호 하나로 답이 끝납니다. 과제 품질관리 요구사항에 "요구사항 변경 이력 추적"이 있었는데, 이게 그대로 증거가 됐어요.
한 발 더 나가면 main 병합 커밋에 Closes DEV-142를 쓰면 이슈가 자동 완료됩니다.
근데 저희는 이건 안 씁니다.
main 병합이 곧 운영 자동 배포로 연결돼 있거든요. 그러면 Closes를 쓰는 순간 "배포됨 = 완료"가 돼버립니다. 배포랑 검증은 다른 얘기라서요. 이유는 아래에서 설명합니다.
10/14~16 — 여기서 제일 크게 배웠다
통합테스트를 돌렸습니다. 테스트 케이스 79개.
- 통과 58
- 실패 10
- 미수행 11
실패분을 전부 결함 이슈로 등록했습니다. 등록할 때 세 가지는 꼭 적게 했어요. TC 번호 / 재현 절차 / 기대 결과. 이게 없으면 사흘 뒤에 본인이 올린 이슈를 본인이 못 알아봅니다. 실제로 겪었습니다.
8건을 처리했는데, 여기서 제일 큰 교훈이 나왔습니다.
수정하고 바로 완료 누르면 안 됩니다.
처음 네 건은 이렇게 처리했어요. 고치고 → 로컬에서 확인하고 → 병합하고 → 완료. 깔끔하죠.
근데 배포된 운영 화면에서 같은 TC로 다시 돌려봤더니, 두 건에서 추가 원인이 나왔습니다. 로컬에서는 통과했는데 운영 환경에서는 아니었던 거예요. 재검증을 안 했으면 "고쳤다고 적어놓은 버그"가 그대로 남아 있었을 겁니다. 더 나쁜 건, Jira에 "완료"로 찍혀 있으니 아무도 다시 안 봤을 거라는 점이에요.
그래서 완료 조건을 바꿨습니다.
운영 화면에서 같은 TC로 재검증 → 그 결과를 표로 댓글에 남김 → 그다음 완료
Closes를 안 쓰는 이유가 이겁니다. 자동 완료는 이 단계를 건너뛰어 버려요.
셋팅은 이틀, 정착은 아직도 진행 중
스페이스 만들고 이슈 올리고 필터 저장하는 데 실제로 이틀 걸렸습니다. 어렵지 않았어요.
어려운 건 사람들이 상태를 매일 바꾸게 만드는 일이었습니다.
가이드 문서 두 개 쓰고, 안내 메일 보내고, 계정 열어줬습니다. 그래도 일주일 뒤에 "3일 이상 미갱신" 필터를 누르면 이슈가 쌓여 있어요. 게을러서가 아닙니다. 일은 했는데 Jira에 옮겨 적는 걸 잊은 거죠.
효과 본 건 두 가지였습니다.
하나, 계정을 10명 이내로 줄였습니다. 전원에게 계정을 주는 대신 파트 단위로 묶었어요. 전원 배포하면 "누군가 하겠지"가 되는데, 파트당 한 명이면 그 사람이 안 하면 티가 납니다. 갱신율이 이때부터 올라갔습니다.
둘, 읽으라고 하는 대신 시켰습니다. 가이드 배포하고 끝내는 게 아니라, 자기 이슈 하나를 "진행 중 → 댓글 → 완료"로 직접 처리해보게 했어요. 한 번 해보면 그다음부터는 알아서 합니다. 글로 읽은 건 안 남더라고요.
정리
11일 해보고 남은 결론은 생각보다 단순합니다.
- 상태는 3개. 늘리면 아무도 안 바꿉니다
- 필터는 매일 보는 3개. 미갱신 / 기한 초과 / 미배정, 전부 0건 목표
- 완료는 재검증 다음에. 배포됐다고 끝난 게 아닙니다
- 일정의 절반은 정착에. 도구 설치는 이틀이면 됩니다
혹시 Jira나 다른 이슈 트래커 도입을 고민 중이시라면, 기능 조사에 쓰는 시간을 줄이고 "어떻게 매일 열게 만들까"에 그 시간을 쓰시는 걸 권합니다. 저는 재작년에 그걸 몰라서 한 번 실패했어요.
다음 글에서는 여기에 Claude를 붙여서 자연어로 이슈를 조회하고 등록해본 과정을 적어보려고 합니다. "지난주에 내가 완료한 이슈 뭐 있었지?"를 그냥 물어보면 답이 나오는데, 되는 것과 안 되는 것이 꽤 갈리더라고요. 그 경계를 정리해볼 생각입니다.
'개발' 카테고리의 다른 글
| 서버 디스크가 꽉 찼을 때 — 도커 이미지부터 정리하자 (0) | 2026.09.23 |
|---|---|
| 은행 API가 개인정보를 흘린다면, 제일 먼저 볼 4곳 (0) | 2026.07.19 |
| Docker에서 Claude Code, Codex 승인 계속 물어볼 때 해결 방법 (0) | 2026.06.09 |
| [Claude 블로그 자동화] Python Flask + RSS 자동 수집 시스템 만들기 2편 (0) | 2026.05.29 |
