issue 트래커로 만드는 세 개의 열로 이루어진 공개 로드맵

공개 로드맵은 여러분이 만들고자 하는 것의 목록이며, 고객이 볼 수 있는 곳에 발행된다. 일을 하고 있는 단어는 의도다. 로드맵은 미래에 대한 일련의 약속이며, 그 위의 모든 항목은 여러분이 지키거나, 아니면 지키지 않은 것으로 보이게 될 것들이다. 그것이 로드맵을 발행하는 이유이며, 동시에 대부분의 공개 로드맵이 한 분기 안에 낡아버리는 이유이기도 하다. 살아남는 버전은 작고, 이미 유지하고 있는 데이터로부터 도출되며, 저 끝에서 체인지로그와 연결되어 있어서, 아무도 다시 입력하지 않아도 약속이 사실이 된다.

공개 로드맵은 무엇을 위한 것인가

공개 로드맵은 요청을 가진 고객에게, 그것이 출시되기 전에 그 요청이 들려졌다는 것을 알려준다. 그것은 루프를 닫는 것의 이른 절반이다. “계획됨”은 “누군가 이것을 읽었는가”라는 질문에 답하고, “구축 중”은 “실제로 일어나고 있는가”에 답한다. 둘 다 마지막 단계, 즉 출시되었을 때 요청자에게 알리는 것을 대신하지는 못하지만, 둘 다 그 사이에 물어보는 사람의 수를 줄여준다.

그것은 팀을 위해서도 한 가지 역할을 한다. 공개적인 약속을 강제하는 것이며, 이는 아무도 만들지 않을 사백 개의 항목을 조용히 품고 있는 백로그에 대해 알려진 가장 저렴한 치료법이다.

고정된 순서의 세 개 열이면 충분하다. 네 번째 열(“검토 중”, “리뷰 중”, “백로그”)은 좋은 의도가 박물관이 되어가는 곳이며, 고객이 가장 먼저 무시하는 법을 배우는 열이기도 하다.

로드맵을 공개해야 하는가

작고 정직하게 유지할 수 있다면 공개하라. 대안이 “할 수도 있음”이 잔뜩 나열된 긴 목록이라면 비공개로 유지하라. 공개 로드맵의 대가는 그것을 발행하는 것 자체와는 무관하다. 그 위의 모든 항목은 이제 누군가 지원팀에서, 영업 전화에서, 갱신 대화에서 물어볼 질문이 된다. 여러분이 만들 열 개의 항목은 자산이다. 만들지도 모를 예순 개의 항목은 왜 안 만들었는지에 대한 예순 번의 미래 대화다.

발행하지 않을 정직한 이유가 두 가지 있다. 여러분의 계획이 한 분기보다 빨리 바뀌거나, 경쟁사가 고객보다 여러분의 로드맵을 더 꼼꼼히 읽는 경우다. 둘 다 실재하며, 둘 다 아무것도 발행하지 않는 것이 아니라 더 적게 발행하는 것으로 답할 수 있다. “구축 중”만 공개하고 “계획됨”은 내부에 두어도, 요청자에게 자신의 issue가 움직이고 있다는 것은 여전히 전달된다.

GitHub issue로부터 공개 로드맵을 어떻게 만드는가

이미 추적하고 있는 issue에 열마다 라벨을 붙이고, 라벨이 붙은 issue를 로드맵으로 렌더링하라. 아무것도 다시 입력되지 않고, 로드맵은 실제 작업으로부터 어긋날 수 없으며, 고객의 요청으로 시작된 바로 그 issue가 정체성을 바꾸지 않은 채 열들을 통과해 나간다.

우리가 운영하는 메커니즘은 이렇다.

1. 열마다 하나의 라벨, 고정된 접두사와 함께: roadmap:planned, roadmap:building, roadmap:shipped. 연결된 저장소 안에서 이 중 하나를 가진 모든 issue는 그 열에 나타난다. 셋 중 아무것도 없는 issue는 로드맵에 없으며, 그것이 대부분의 issue이고, 그것이 옳다.
2. 열은 항상 같은 순서로 나열된 배열이다. 계획됨, 구축 중, 출시됨. 이름을 키로 하는 맵이 아니므로, 독자(혹은 위젯)는 절대 순서를 추측할 필요가 없다.
3. issue가 두 개의 라벨을 가지면, 가장 진행된 쪽이 이긴다. 누군가 roadmap:planned를 제거하기 전에 roadmap:shipped를 먼저 추가할 것이다. “가장 마지막에 도착한 웹훅”으로 움직이는 상태 기계는 전달 순서에 따라 항목을 서로 다른 열에 놓게 될 것이다. 라벨 집합만으로 판단하면, 이벤트가 어떤 순서로 도착하든 답은 같아진다.
4. 출시됨은 다른 것들과 마찬가지로 라벨 상태다. issue에 roadmap:shipped가 붙거나, 그 라벨을 단 채로 닫히면 카드가 옮겨진다. 카드 자체는 체인지로그 항목으로 링크되지 않는다. 세부 내용은 그 issue를 닫은 pull request로부터 초안이 작성된 항목에 있다.
5. 데이터로 제공하라. 로드맵은 그 세 개의 열을 가진 JSON 문서이며, 체인지로그 피드와 같은 캐시 헤더로 나란히 발행되어서, 문서 사이트, 위젯, 상태 페이지가 두 번째 통합 없이 그것을 렌더링할 수 있다. 피드 문서에 정확한 형태가 있다.

라벨 하나는 관리자에게 요구하기에 작은 것이며, 그것이 통합의 전부다. 동기화를 유지해야 할 보드도 없고, 로그인해야 할 별도의 도구도 없으며, 고객이 접수한 요청이 곧 로드맵 위의 항목이다. 출시되어도 그것은 같은 항목이다.

공개 로드맵에는 무엇을 담지 말아야 하는가

날짜, 추정치, 그리고 아홉 달 후에 질문받으면 곤란해질 만한 것은 담지 말아야 한다. 날짜는 전형적인 실수다. 로드맵 위의 한 분기는 영업 자료 속의 확약이 되고, 그것은 “당신은 Q3라고 했잖아요”라는 제목의 티켓이 된다. 열만으로도 충분히 전달된다. “구축 중”은 이미 “누군가 그것에 매달릴 만큼 가까운 시일 안에”를 의미한다.

내부 백로그도 담지 말아야 한다. 삼백 개의 항목을 가진 로드맵은 약속이 아니라 검색 문제이며, 자신의 요청을 212번째 자리에서 찾은 고객은 여러분이 말할 의도가 없었던 무언가를 알게 된 것이다.

로드맵은 체인지로그와 어떻게 연결되는가

로드맵과 체인지로그는 같은 issue들을 두 쪽에서 서술하며, 하나는 미래를 위해, 하나는 과거를 위해 있다. 별도의 보드에서 카드를 옮기는 사람은 없다. 관리자는 이미 작업하고 있던 issue의 라벨을 바꾸고, 그 pull request로부터 항목의 초안이 작성되며, 사람이 그 항목을 승인하면 위젯 피드백이 그 issue가 된 요청자는 그 issue에서 통보받는다. 카드를 출시됨으로 옮기는 것은 여전히 별도의 단계, 즉 roadmap:shipped 라벨이므로 같은 검토의 일부로 만들어라. 항목을 승인한다고 그것이 대신 이루어지지는 않는다.

이것은 피드백 루프 글이 체인지로그 쪽에서 서술하는 것과 같은 루프이며, 로드맵은 그 한가운데서 고객이 보는 것이다. 체인지로그 도구 정리는 어떤 제품이 로드맵 뷰를 제공하고 어떤 제품이 그것을 별도의 보드로 취급하는지를 다루며, 그것이 정확성을 유지하는지를 결정하는 차이다.

좋은 공개 로드맵은 어떤 모습인가

짧아 보이고, 그 위의 모든 항목이 누군가 열어볼 수 있는 issue다. 시험은 고객이 어떤 항목에서 그 뒤의 논의로, 그리고 출시된 항목에서 실제로 무엇이 바뀌었는지 설명하는 항목으로 갈 수 있는가다. 들어갈 방법이 없는 기능 이름들의 목록인 로드맵은 브로슈어일 뿐이다.

위젯이 가져올 JSON으로서 작성된 구체적인 예시다.

{
  "columns": [
    { "column": "planned", "hasMore": false, "items": [
      { "id": "6b0c1f...", "column": "planned",
        "publicTitle": "Saved views on the inbox",
        "publicDescription": "Keep a filter you use often and come back to it.",
        "publishedAt": "2026-09-16T10:04:11.000Z" }
    ]},
    { "column": "building", "hasMore": false, "items": [
      { "id": "71a4e2...", "column": "building",
        "publicTitle": "Roadmap column in the widget",
        "publicDescription": "See what is coming without leaving the page.",
        "publishedAt": "2026-09-12T08:20:02.000Z" }
    ]},
    { "column": "shipped", "hasMore": false, "items": [
      { "id": "5c9d70...", "column": "shipped",
        "publicTitle": "Feedback filed as labelled issues",
        "publicDescription": "Widget submissions arrive as issues your triage already handles.",
        "publishedAt": "2026-09-02T15:41:37.000Z" }
    ]}
  ],
  "enabled": true,
  "language": "en"
}

세 개의 열에 걸친 세 개의 항목만으로도 더없이 좋은 공개 로드맵이 된다. 무엇이 오고 있는지, 무엇이 일어나고 있는지, 무엇이 일어났는지를 말해주며, 그 모든 줄이 확인 가능하다. Now/Next/Later부터 성과 기반까지 다른 다섯 가지 레이아웃은 샘플 항목과 함께 제품 로드맵 예시에 실려 있다.

FAQ

공개 로드맵에는 몇 개의 항목이 있어야 하는가? 방어할 수 있는 만큼 최소한으로. 작은 제품이라면 모든 열을 합쳐 열 개 미만이 보통이며, “계획됨”에 서른 개 넘게 있는 것은 로드맵의 옷을 입은 백로그다.

공개 로드맵에 날짜가 있어야 하는가? 아니다. 열은 기한을 만들지 않고도 순서를 전달한다. 고객이 날짜를 필요로 한다면, 그것은 로드맵 항목이 아니라 대화의 문제다.

고객이 로드맵 항목에 투표해야 하는가? 투표는 무엇이 중요한지가 아니라 누가 나타났는지를 측정한다. 오늘 사용하고 있는 우회 방법을 설명하는 issue의 코멘트 하나가 쉰 표보다 가치가 있으며, 그것은 투표자에게 무언가를 치르게 만드는데, 그것이 핵심이다.

취소된 로드맵 항목은 어떻게 되는가? 라벨을 제거하고 issue에 이유를 밝혀라. 공개적인 “이것은 하지 않겠다”는 루프의 일부이며, 대부분의 팀이 결코 보내지 않는 메시지다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 도구 비교