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

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

Jira가 잘하는 것

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

문제는 그 위에 프로젝트 전체 계획까지 얹으려 할 때 생긴다. 도구가 나빠지는 것이 아니라, 원래 하던 일과 다른 종류의 일을 요구하는 것이다.

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

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

같은 트리처럼 보여도 쓰임이 다르다. 한쪽은 계속 바뀌는 목록이고, 한쪽은 지키기로 약속한 문서다. 이 차이에서 3가지 어긋남이 나온다.

어긋남 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를 다듬을 차례고, "이게 전부인가, 언제 끝나는가"라면 계획의 층을 세울 차례다.