경영진이 묻습니다. "다음 분기에 뭐가 나와요?" PM이 만든 로드맵엔 날짜별 기능이 빽빽한데, 정작 절반은 추정이 흔들리는 항목입니다. 한 달 뒤 일정이 밀리자 "약속을 어겼다"는 말이 나옵니다. 한편 개발 보드엔 이슈가 200개. 무엇이 어느 에픽 소속이고 지금 누가 뭘 하는지 한눈에 안 보입니다. 인프라 담당의 장애 대응은 아예 기록조차 남지 않습니다. 로드맵과 이슈 트래킹은 '우선순위를 시간과 보드에 올리는' 작업입니다. 잘못 올리면 신뢰를 잃고, 잘 올리면 조직이 같은 그림을 봅니다.
- 1Now-Next-Later 로드맵이 불확실성을 다루는 방식을 설명할 수 있다
- 2에픽-이슈 계층으로 큰 목표와 작업을 연결할 수 있다
- 3이슈 워크플로우(상태)·라벨 표준화의 가치를 설명할 수 있다
- 4운영·장애를 이슈로 기록해 toil과 자동화 대상을 식별할 수 있다
로드맵 — 불확실성을 정직하게 표현하기
Now-Next-Later: 가까운 건 선명하게, 먼 건 느슨하게
날짜를 빽빽이 박은 로드맵은 변경될 때마다 '약속 위반'처럼 보입니다. Now-Next-Later는 불확실성을 인정합니다.
NOW (이번 분기, 확정) NEXT (다음, 방향 잡힘) LATER (그 후, 탐색)
─────────────────────────────────────────────────────────────────
• 결제 카드 연동(개발중) • 간편결제 추가 • 글로벌 결제
• 알림 푸시 v1 • 정산 리포트 • AI 추천(검토)
→ 유저스토리·AC 확정 → 에픽 수준 → 한 줄 방향만
가까운 NOW는 [[requirements-prd]]의 유저스토리·인수기준까지 구체적이고, LATER는 방향성만 둡니다. 이렇게 하면 우선순위가 바뀌어도 "Later에 있던 걸 Next로 당겼다"는 자연스러운 서사가 되어 신뢰를 지킵니다. 날짜가 꼭 필요한 외부 약속(규제·계약)만 마일스톤으로 별도 고정합니다.
이슈 트래킹 — 에픽·이슈·워크플로우
큰 목표(에픽)와 작은 작업(이슈)을 계층으로
이슈 트래커(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↔이슈, 이슈↔에픽, 에픽↔로드맵을 연결해 "코드 변경 → 어떤 목표에 기여"를 추적.
운영을 데이터로 만들기 — 직접 점검
인프라/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로 전환하고, 외부 약속이 필요한 소수만 날짜 마일스톤으로 분리합니다. 그 마일스톤엔 의도적으로 버퍼를 둡니다. 그리고 로드맵은 '살아있는 문서'로, 우선순위 변경 시 짧게 소통하는 루틴(월간 로드맵 리뷰)을 만듭니다. 신뢰는 '정확한 예언'이 아니라 '투명한 업데이트'에서 옵니다.
PM은 로드맵으로 "왜 지금 이것"을 이해관계자에게 설득하고, 이슈 트래커로 "지금 어디까지"를 팀과 공유합니다. 인프라/SRE에게 이슈 트래킹은 특히 중요합니다 — 장애·요청·수작업을 빠짐없이 이슈로 남기면, 그 데이터가 곧 "무엇을 자동화하고 무엇에 안정성을 투자할지"의 근거가 됩니다. "인증서 수동 갱신 14회"라는 한 줄 집계가 cert-manager 도입을 정당화하고, 반복 toil을 제거해 팀을 야근에서 구합니다. 로드맵과 이슈는 관리 도구를 넘어, 조직이 무엇에 시간을 쓰는지 보여주는 거울입니다.
이것으로 Phase 2(요구사항·제품관리)를 마칩니다. 다음 Phase에서는 개발자들이 코드를 함께 다루는 기반 — Git과 협업 흐름을 다룹니다.