시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 3편입니다. 1·2편에서 프로젝트 관리 이론과 IT 프로젝트의 특수성을 다뤘습니다. 이번 편부터 본격적인 도구 해부에 들어갑니다. 첫 대상은 개발 조직의 사실상 표준, Jira입니다. 강력하기로 유명한 이 도구가 왜 정작 비개발 팀원에게는 높은 벽이 되는지 같은 잣대로 뜯어봅니다.
한눈에 보기
- 출시: 2002년, 호주 Atlassian
- 분류: 이슈 트래커에서 출발한 애자일 PMS
- 채택 이론: 스크럼·칸반 (애자일 중심)
- 과금(2026년 6월 기준): 무료(최대 10명) / Standard 약 $7.91 / Premium 약 $14.54 (1인당 월, 연간 결제 기준) / Enterprise 별도 견적
- 주 타깃: 소프트웨어 개발팀, IT 조직
1. 탄생 배경과 채택한 이론 모델
Jira는 2002년 버그 추적 도구로 출발했다. 이름부터가 “Gojira(고질라)”에서 따온 것으로, 원래는 소프트웨어의 결함(이슈)을 추적하려는 도구였다. 그러다 애자일이 업계를 휩쓸면서, Jira는 스크럼과 칸반을 정면으로 끌어안고 애자일 프로젝트 관리의 대표 도구로 변신했다.
그래서 Jira의 뼈대에는 1편에서 본 애자일 이론이 그대로 박혀 있다. 스프린트로 일을 끊고, 백로그에 쌓고, 보드에서 흘려보낸다. 애자일을 도구로 가장 충실하게 구현한 제품을 꼽으라면 많은 사람이 Jira를 든다. 이론적 정통성만큼은 의심할 여지가 없다.
2. 핵심 구조와 데이터 모델
Jira가 세상을 쪼개는 방식은 계층적이다. 기본 구조는 이렇다.
에픽(Epic) → 스토리(Story)·태스크(Task)·버그(Bug) → 서브태스크(Sub-task)에픽은 큰 기능 단위이고, 그 아래 스토리나 태스크가 실제 작업이며, 다시 서브태스크로 잘게 쪼갠다. 상위 프로젝트(Project)가 이 모든 것을 담는 그릇이다. 1편에서 본 WBS의 “큰 일을 작은 단위로 분해”하는 사고가 거의 그대로 구현된 셈이다.
다만 기본 계층은 3단(에픽-스토리-서브태스크)으로 고정돼 있고, 그 위에 이니셔티브 같은 단계를 더 얹으려면 상위 요금제(Premium 이상)나 별도 부가기능이 필요하다. 구조를 내 조직에 맞게 바꾸는 데에도 돈과 권한이 든다는 뜻이다.
3. 강점 — 무엇을 잘하는가
Jira의 강점은 분명하다. 공정하게 인정하고 가자.
첫째, 압도적인 커스터마이즈 능력이다. 워크플로우, 필드, 화면, 권한을 거의 무한히 주무를 수 있다. 복잡한 개발 프로세스를 가진 조직일수록 Jira의 유연함이 빛난다.
둘째, 개발 도구와의 깊은 연동이다. GitHub, Bitbucket, CI/CD 파이프라인과 자연스럽게 물리고, 커밋과 이슈가 연결된다. 개발자가 코드와 작업을 한 흐름에서 관리할 수 있다.
셋째, 생태계다. Atlassian 마켓플레이스에는 수천 개의 부가기능이 있어, 웬만한 요구사항은 플러그인으로 해결된다. 무료 플랜도 10명까지는 꽤 쓸 만해서, 작은 개발팀이 시작하기에 진입 자체는 어렵지 않다.
4. 현장의 복잡성 — 팀원이 안 쓰는 지점
문제는 여기서부터다. Jira의 강점인 “강력함”은 그대로 약점의 뿌리가 된다.
학습곡선이 가파르다. Jira에 처음 들어온 사람은 에픽·스토리·스프린트·백로그·보드 같은 용어의 벽 앞에서 멈칫한다. 개발자에게는 익숙한 말이지만, 기획·디자인·마케팅처럼 함께 일하는 비개발 직군에게는 외국어에 가깝다. 2편에서 말한 “설명 없이 쓸 수 있는가”라는 잣대에서 Jira는 분명히 불리하다.
설정과 권한이 과하다. 제대로 굴리려면 워크플로우를 짜고 권한을 설계해야 하는데, 이건 사실상 전담 관리자의 일이다. Atlassian조차 500명당 1명꼴의 관리 인력을 권할 정도다. 도구를 쓰기 위해 도구를 관리하는 사람이 필요한 구조다.
비용이 숨어 있다. 표면 가격은 1인당 월 8달러 안팎이지만, 실제 총비용은 마켓플레이스 플러그인, 문서 도구 Confluence 별도 구독, 관리 인력까지 더하면 기본 라이선스의 2~3배에 이르는 것으로 알려져 있다. 게다가 11명이 되는 순간 무료에서 유료로 전원 전환되는 구조라, 팀이 커질수록 부담이 비선형으로 커진다.
그리고 가장 본질적인 문제. 결국 PM과 개발 리드의 도구가 된다. 비개발 팀원은 복잡함에 밀려 들어오지 않고, 진행 상황은 누군가 대신 입력해준다. 2편에서 짚은 “보고를 위한 보고”가 여기서 그대로 재현된다. 도구는 강력한데, 그 강력함을 실제로 누리는 사람은 팀의 일부뿐이다.
5. 한 줄 평
Jira는 복잡한 개발 프로세스를 가진 중대형 엔지니어링 조직에는 최고의 도구다. 그러나 다양한 직군이 섞인 팀, 단순함이 필요한 팀에게는 과한 무기다. 강력함과 “모두가 쓰는 것”은 다른 문제라는 이 시리즈의 화두를, Jira는 가장 선명하게 보여준다.
짚고 가기: Jira의 강력함은 진짜다. 하지만 그 강력함을 쓰려면 전담 관리자, 별도 비용, 그리고 학습할 의지가 있는 팀원이 필요하다. 셋 중 하나라도 없으면, Jira는 ‘PM만 쳐다보는 비싼 대시보드’가 된다. 우리가 시리즈 끝에서 만날 질문 — 팀원이 설명 없이 바로 쓰는 도구는 불가능한가? — 의 출발점이 바로 여기다.
다음 편 예고
Jira가 “강력하지만 복잡한” 쪽 끝이라면, 다음 편(04부)의 ClickUp은 정반대 약속을 내건다. “하나의 도구로 모든 걸 다 하라(One app to replace them all)”는 슬로건이다. 그런데 모든 걸 다 하겠다는 도구는 과연 그 약속을 지킬까, 아니면 또 다른 복잡성의 늪일까. 다음 편에서 해부한다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 02. IT 프로젝트의 특수성
다음 글: IT 프로젝트 관리 도구 완전 해부 – 04. ClickUp — 모든 걸 다 하는 도구의 역설
