Jira에서 WBS 관리가 어려운 이유 — 그리고 공존하는 법

Jira에서 WBS 관리가 어려운 것은 Jira가 부족해서가 아니라, 이슈 트래커와 WBS가 서로 다른 질문에 답하는 도구이기 때문이다. Jira는 "지금 누가 무엇을 하고 있는가"에 답하고, WBS는 "전체 범위가 무엇이고 언제 끝나는가"에 답한다. 이 글은 두 도구의 세계관이 어긋나는 세 지점을 짚고, 어느 한쪽을 버리는 대신 각자의 자리에 두는 공존 전략을 다룬다.

Jira가 잘하는 것

먼저 분명히 하자. 개발 실행의 추적에서 Jira는 사실상의 표준이다. 이슈의 생성·할당·상태 전이, 스프린트 운영, 백로그 우선순위, 코드·배포와의 연결까지 — 실행의 흐름을 다루는 데 이만큼 다듬어진 도구는 드물다. 개발팀이 Jira를 쓰고 있다면 그것은 대개 옳은 선택이다.

문제는 그 위에 프로젝트 전체의 계획까지 얹으려 할 때 시작된다. 도구가 나빠지는 것이 아니라, 도구에게 다른 종류의 일을 시키는 것이다.

WBS와 이슈 계층은 다른 질문에 답한다

Jira의 계층(에픽·스토리·하위 작업)은 언뜻 WBS의 트리와 닮았다. 하지만 둘은 태생이 다르다. 이슈 계층은 일을 하기 위한 구조다. 백로그에 쌓이고, 스프린트에 담기고, 끝나면 닫힌다. WBS는 범위를 약속하기 위한 구조다. 전체가 빠짐없이 분해되었는지 검증되고, 승인되면 변경 통제의 대상이 된다.

같은 트리처럼 보여도, 한쪽은 흐르는 물이고 한쪽은 계약서다. 이 차이에서 세 가지 어긋남이 나온다.

어긋남 1 — 100% Rule과 백로그의 유동성

WBS의 첫 규율은 100% Rule이다. 자식들의 합이 부모의 전부여야 하고, 빠진 일이 없어야 한다. 반면 백로그는 설계상 유동적이다. 이슈는 수시로 생기고 쪼개지고 버려진다. 그것이 백로그의 미덕이다.

그래서 이슈 목록으로 범위 완전성을 검증하려 하면 곧 벽에 닿는다. "이 에픽들이 프로젝트의 전부인가?"라는 질문에 백로그는 답하도록 설계되지 않았다. 이 긴장은 애자일과 WBS의 대립이 아니다 — WBS와 애자일은 싸우지 않는다에서 다뤘듯, What의 분해와 How의 실행은 애초에 다른 층의 일이다.

어긋남 2 — 일정 계산과 기준선

이슈에는 마감일을 적을 수 있고, 타임라인 뷰나 플러그인으로 막대를 볼 수도 있다. 하지만 프로젝트 일정 관리가 요구하는 것은 막대가 아니라 계산이다. 작업 사이의 종속성에서 날짜가 도출되고, 선행이 밀리면 후행이 따라 밀리고, critical path가 보이고, 승인 시점의 baseline과 현재를 비교할 수 있어야 한다.

이슈 트래커의 시간 단위는 스프린트라는 상자이지, 종속성으로 이어진 날짜의 사슬이 아니다. "3주 뒤에 끝나나요?"라는 질문에 벨로시티로 추정할 수는 있어도, 계산으로 답하기는 어렵다.

어긋남 3 — 보고의 언어

경영진과 고객은 스토리 포인트와 번다운으로 묻지 않는다. 단계(Phase)가 어디까지 왔는지, 마일스톤이 지켜지는지, 원래 계획 대비 얼마나 밀렸는지를 묻는다. 그 언어의 어휘가 WBS·간트·baseline이다.

보고 때마다 이슈 데이터를 단계 언어로 번역해 슬라이드를 만드는 PM이 많다. 번역 비용도 문제지만, 더 큰 문제는 완료의 정의다. 이슈의 "Done"과 검수 가능한 완료기준은 다른 것이다 — 완료기준을 문장으로 박는 방법은 WBS Dictionary 작성법에서 다뤘다.

공존 전략 — 계획·통제는 WBS, 실행은 Jira

답은 둘 중 하나를 버리는 것이 아니라 층을 나누는 것이다.

1. 범위는 WBS로 먼저. 프로젝트 착수 시 전체 범위를 WBS로 분해하고 100% Rule로 검증한다. 골격을 빠르게 세우는 데는 AI로 WBS 초안을 만든 실험 같은 방식도 있다.
2. Work Package까지만 계획의 정본. WBS의 최하위 칸(Work Package)이 Jira의 에픽이나 이슈 묶음과 대응한다. 그 아래의 실행 — 하위 작업, 스프린트 배치, 담당 — 은 전적으로 Jira의 영역이다.
3. 일정·기준선은 WBS 쪽에서. 종속성·CPM·baseline·마일스톤은 계획 도구가 계산하고, 보고는 여기서 나간다.
4. 진척만 주기적으로 올린다. 스프린트가 끝날 때 Work Package 단위의 진척률만 계획 쪽에 반영한다. 이슈 하나하나를 미러링하지 않는 것이 이 전략의 핵심이다 — 접점이 넓어지면 이중 관리가 시작된다.

접근 방식 비교 — 실행의 흐름과 범위의 약속

표의 두 열은 경쟁 관계가 아니다. 같은 프로젝트의 다른 층이고, 잘 돌아가는 조직은 대개 둘 다 가지고 있다.

Jira 안에서 해결하는 게 맞는 경우

별도 도구 없이 Jira 생태계 안에 머무는 것이 나은 상황도 분명히 있다.

• 조직 전체가 Jira 중심이고, 보고를 받는 쪽도 Jira를 열어보는 문화인 경우
• 관리 단위가 한두 팀의 개발 프로젝트라 Phase·마일스톤 보고 요구가 약한 경우
• WBS Gantt-Chart·Structure·BigPicture 같은 Jira 플러그인으로 필요한 계층·간트를 이미 충족하는 경우

이 경우 도구를 늘리는 것보다 플러그인 계열을 먼저 검토하는 편이 자연스럽다. 도구 수는 그 자체가 비용이다.

함께 살펴볼 만한 도구들

• Jira 플러그인 계열(WBS Gantt-Chart·Structure·BigPicture) — Jira 안에 남으면서 계층·간트를 보강하는 선택.
• Jira 자체의 타임라인·로드맵 기능 — 에픽 수준의 큰 그림이 필요한 정도라면 추가 도구 없이 충분할 수 있다.
• wbsgantt — 우리가 만드는 도구다. 계획·통제 층을 Jira 밖에 두는 공존 전략의 계획 쪽 — WBS 정본, 계산되는 간트, baseline, 고객·경영진용 읽기 전용 공유 링크를 담당한다. Jira와의 자동 연동은 없다 — 접점을 Work Package 진척 입력으로 좁게 유지하는 운영을 전제한다.

어느 길이든, 출발점은 도구가 아니라 질문이다. 지금 조직이 답하지 못하는 질문이 "지금 무엇을 하는가"라면 Jira를 다듬을 일이고, "전부인가, 언제 끝나는가"라면 계획의 층을 세울 일이다.