경영진이 묻습니다. "다음 분기에 뭐가 나와요?" PM이 만든 로드맵엔 날짜별 기능이 빽빽한데, 정작 절반은 추정이 흔들리는 항목입니다. 한 달 뒤 일정이 밀리자 "약속을 어겼다"는 말이 나옵니다. 한편 개발 보드엔 이슈가 200개. 무엇이 어느 에픽 소속이고 지금 누가 뭘 하는지 한눈에 안 보입니다. 인프라 담당의 장애 대응은 아예 기록조차 남지 않습니다. 로드맵과 이슈 트래킹은 '우선순위를 시간과 보드에 올리는' 작업입니다. 잘못 올리면 신뢰를 잃고, 잘 올리면 조직이 같은 그림을 봅니다.
- 1Now-Next-Later 로드맵이 불확실성을 다루는 방식을 설명할 수 있다
- 2에픽-이슈 계층으로 큰 목표와 작업을 연결할 수 있다
- 3이슈 워크플로우(상태)·라벨 표준화의 가치를 설명할 수 있다
- 4운영·장애를 이슈로 기록해 toil과 자동화 대상을 식별할 수 있다
로드맵 — 불확실성을 정직하게 표현하기
Now-Next-Later: 가까운 건 선명하게, 먼 건 느슨하게
날짜를 빽빽이 박은 로드맵은 변경될 때마다 '약속 위반'처럼 보입니다. Now-Next-Later는 불확실성을 인정합니다.
| NOW (이번 분기, 확정) | NEXT (다음, 방향 잡힘) | LATER (그 후, 탐색) |
|---|---|---|
| 결제 카드 연동(개발중) | 간편결제 추가 | 글로벌 결제 |
| 알림 푸시 v1 | 정산 리포트 | AI 추천(검토) |
| → 유저스토리·AC 확정 | → 에픽 수준 | → 한 줄 방향만 |
가까운 NOW는 요구사항 정의의 유저스토리·인수기준까지 구체적이고, LATER는 방향성만 둡니다. 이렇게 하면 우선순위가 바뀌어도 "Later에 있던 걸 Next로 당겼다"는 자연스러운 서사가 되어 신뢰를 지킵니다. 날짜가 꼭 필요한 외부 약속(규제·계약)만 마일스톤으로 별도 고정합니다.
확대
위 그림처럼 Now는 AC까지 구체화된 진행 중 항목, Next는 방향이 잡힌 에픽 수준, Later는 방향성만 담아 불확실성을 정직하게 표현합니다.
이슈 트래킹 — 에픽·이슈·워크플로우
큰 목표(에픽)와 작은 작업(이슈)을 계층으로
이슈 트래커(Jira, GitHub Issues, Linear)는 일을 계층과 상태로 관리합니다.
에픽: "결제 시스템 구축" ← 로드맵의 한 항목과 연결
- 스토리: 카드 결제 연동 —
In Progress - 스토리: 환불 처리 —
Backlog - 태스크: 결제 모니터링 추가 —
Backlog(인프라 작업도 여기) - 버그: 중복 결제 방지 —
Review
상태 워크플로우(표준): Backlog → To Do → In Progress → In Review → Done
핵심 실천:
- 상태 표준화: 모든 이슈가 같은 단계를 거쳐야 진행률·병목을 집계할 수 있다.
- 라벨:
type:bug/feature/ops,priority:P0~P3,area:payment등으로 필터·자동화. - 연결: PR↔이슈, 이슈↔에픽, 에픽↔로드맵을 연결해 "코드 변경 → 어떤 목표에 기여"를 추적.
확대
위 그림처럼 에픽(큰 목표)은 여러 스토리(기능 단위)를 묶고, 각 스토리는 담당자가 있는 태스크로 분해되어 전체 진행률을 집계할 수 있습니다.
확대
위 그림처럼 이슈가 Backlog → To Do → In Progress → Review → Done 상태를 거치도록 표준화하면 진행률 집계와 자동 알림이 가능해집니다.
운영을 데이터로 만들기 — 직접 점검
인프라/SRE의 장애·요청을 이슈로 남기면 '반복되는 수작업(toil)'이 데이터로 드러나 자동화 우선순위가 됩니다.
# GitHub Issues 예: 라벨별 최근 90일 이슈 수
gh issue list --label ops --state all --search "created:>2026-03-15" --json title | jq length
# 어떤 ops 작업이 반복되는지(제목 패턴)
gh issue list --label ops --state all --json title --jq '.[].title' | sort | uniq -c | sort -rn | head
14 인증서 수동 갱신 요청 ← 14번 반복! 자동화 1순위(cert-manager/ACME)
9 배포 후 캐시 수동 퍼지
7 신규 서버 방화벽 룰 추가 요청
3 디스크 풀 알람 대응
→ 반복 1위 "인증서 수동 갱신"을 자동화하면 분기 14건의 toil 제거
echo '라벨별 이슈 집계 → 반복 수작업 식별'- 같은 제목의 ops 이슈가 분기 10회 이상 반복되면 → 명백한 자동화 대상(toil). 그 작업의 자동화를 다음 스프린트 백로그에 올린다
- incident 라벨 이슈의 평균 해결시간(생성→닫힘)이 길어지면 → MTTR 악화. 온콜·런북·알람 체계 점검 신호
- P0/P1 이슈가 특정 area(예: payment)에 몰리면 → 그 영역의 안정성 투자(테스트·모니터링) 우선순위를 올린다
- 운영 작업이 이슈로 안 남고 슬랙·구두로만 처리되면 → 데이터가 없어 개선 못 함. "기록 안 된 일은 측정도 개선도 안 된다"
상황: 분기 로드맵에 기능별 출시 날짜를 못 박아 경영진·영업에 공유했는데, 한 기능의 외부 의존(결제사 심사)이 지연되자 연쇄로 전체가 밀리고 "PM이 약속을 못 지킨다"는 인식이 생깁니다.
원인: 불확실성이 큰 항목까지 확정 날짜로 표현했습니다. 소프트웨어 일정은 본질적으로 추정인데, 날짜 약속은 작은 변동도 '실패'로 보이게 만듭니다.
진단 — 로드맵 점검:
□ 날짜가 박힌 항목 중 외부 의존·미확정 추정이 섞였나?
□ 이해관계자가 로드맵을 '확정 계약'으로 받아들이고 있나?
□ 변경 시 업데이트·소통 루틴이 있나?
해결: 내부 개발 항목은 Now-Next-Later로 전환하고, 외부 약속이 필요한 소수만 날짜 마일스톤으로 분리합니다. 그 마일스톤엔 의도적으로 버퍼를 둡니다. 그리고 로드맵은 '살아있는 문서'로, 우선순위 변경 시 짧게 소통하는 루틴(월간 로드맵 리뷰)을 만듭니다. 신뢰는 '정확한 예언'이 아니라 '투명한 업데이트'에서 옵니다.
심화 — 트래커는 방치해도 죽고, 조여도 죽는다
심화: 백로그 파산과 프로세스 과잉 — 트래커가 현실에서 분리되는 두 경로
이슈 트래킹의 실패는 도구를 안 써서가 아니라, 대부분 두 극단에서 옵니다 — 방치해서 무덤이 되거나, 조여서 사람들이 도구 밖으로 도망가거나. 양쪽 다 결과는 같습니다: 보드가 현실을 반영하지 않게 됩니다.
- 백로그 파산(backlog bankruptcy): 백로그가 수백 건이고 하위 80%는 2년째 아무도 열지 않는다면, 그것은 우선순위 도구가 아니라 죄책감 보관소입니다. 처방은 백로그에 상한을 두고(팀이 2~3분기 안에 실제로 할 수 있는 분량), 6개월 이상 미착수·논의 없는 이슈는 주기적으로 일괄 닫는 것입니다. "정말 중요하면 다시 올라온다"가 이 정리의 근거입니다 — 닫는 것은 잊는 것이 아니라 목록을 다시 믿을 수 있게 만드는 일입니다.
- 프로세스 과잉 → 그림자 작업: 필수 필드가 9개, 상태가 12개가 되면 이슈 만들기가 귀찮아진 사람들은 슬랙 DM과 구두로 일을 주고받기 시작합니다. 그 순간부터 보드는 일부만 비추는 창이 되고, 보드 기반의 모든 집계(진행률·병목·toil)는 허수가 됩니다. 신호는 이슈 연결 없이 머지되는 PR의 비율 증가입니다. 처방: 상태는 집계에 실제로 쓰는 것만 남기고, 필수 필드는 최소화해 '이슈 생성 30초'를 지킵니다.
- 금요일 몰아서 갱신: 보드가 실시간 작업 현황이 아니라 주간 보고 직전에 일괄 갱신된다면, 체류 시간·병목 데이터는 전부 허구입니다. 상태 전환을 보고 행위가 아니라 작업 흐름에 묶어야 합니다 — PR 열리면 In Progress, 머지되면 Done으로 가는 자동 전환이 사람의 성실함보다 믿을 만합니다.
- 규모에 맞는 무게: 5인 팀에 대기업식 워크플로우는 과잉이고, 50인 조직에 스프레드시트는 부족입니다. 도구의 무게는 조직에 맞추되, 어느 규모든 지킬 불변식은 두 가지뿐입니다 — 일은 트래커에 있다, 그리고 상태는 현실이다. 이 둘이 깨지면 나머지 기능은 전부 장식입니다.
상황: 관리 강화를 위해 이슈 생성 시 필수 필드(스토리 포인트·컴포넌트·마감일·승인자 등 8개)를 늘리고 상태를 12단계로 세분화한 분기. 보드는 어느 때보다 깔끔한데 팀은 계속 야근입니다. PM은 보드 기준으로 "여유 있다"고 판단해 부서 요청을 계속 수락했고, 팀원들은 "보드에 없는 일이 절반"이라고 호소합니다. 분기 회고에서 집계해 보니 머지된 PR 중 이슈가 연결된 비율이 87%에서 41%로 떨어져 있었습니다.
원인: 프로세스를 조인 뒤 이슈 생성 비용이 커지자, 급한 요청들이 슬랙 DM과 회의 구두 지시로 흘렀습니다. 성실한 사람일수록 트래커를 우회해서라도 일을 받아 처리했고, 그 결과 보드는 실제 부하의 절반만 비추는 창이 됐습니다. 과소 표시된 보드를 근거로 일을 더 수락하는 악순환 — 도구를 조인 것이 오히려 가시성을 파괴한 사례입니다.
진단: 두 숫자를 잽니다. ① 최근 분기 머지 PR 중 이슈 연결 비율의 추이(급락 시점이 프로세스 변경 시점과 일치하는지) ② 팀원별로 최근 2주간 실제 수행한 일과 보드상 담당 이슈를 대조(이 팀은 1인 평균 실작업 12건 중 보드 표시 5건). 슬랙에서 "이것 좀 봐주세요"류 DM 요청을 샘플링하면 그림자 유입 경로가 확정됩니다.
해결: ① 필수 필드를 3개(제목·유형·담당)로 줄이고 상태를 5단계로 되돌립니다 — 나머지 정보는 필요해진 시점에 채웁니다 ② 이슈 링크 없는 PR에 봇이 "관련 이슈가 있나요?"를 묻는 소프트 가드를 답니다 ③ '트래커에 없으면 일정에 없는 일' 원칙을 세우되, 리더가 먼저 지킵니다 — DM으로 온 요청을 리더가 직접 이슈로 옮긴 뒤 그 링크로 답하는 것이 어떤 공지보다 효과적입니다. 두 달 뒤 연결 비율이 83%로 회복됐고, 보드가 다시 현실이 되자 "여유 있다"는 오판도 사라졌습니다.
PM은 로드맵으로 "왜 지금 이것"을 이해관계자에게 설득하고, 이슈 트래커로 "지금 어디까지"를 팀과 공유합니다. 인프라/SRE에게 이슈 트래킹은 특히 중요합니다 — 장애·요청·수작업을 빠짐없이 이슈로 남기면, 그 데이터가 곧 "무엇을 자동화하고 무엇에 안정성을 투자할지"의 근거가 됩니다. "인증서 수동 갱신 14회"라는 한 줄 집계가 cert-manager 도입을 정당화하고, 반복 toil을 제거해 팀을 야근에서 구합니다. 로드맵과 이슈는 관리 도구를 넘어, 조직이 무엇에 시간을 쓰는지 보여주는 거울입니다.
이것으로 Phase 2(요구사항·제품관리)를 마칩니다. 다음 Phase에서는 개발자들이 코드를 함께 다루는 기반 — Git과 협업 흐름을 다룹니다.
실전 랩으로 손에 익히기: 로드맵·이슈 트래킹 실습 — 로드맵을 now/next/later로, 이슈 보드를 WIP·라벨로 설계합니다.
관련 모듈로 더 깊이: