시리즈 안내
이 글은 누스쿨 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 3편입니다. 1·2편에서 프로젝트 관리 이론과 IT 프로젝트의 특수성을 다뤘습니다. 이번 편부터 본격적인 도구 해부에 들어갑니다. 첫 대상은 개발 조직의 사실상 표준, Jira입니다. PM·PO 이직 준비자라면 “Jira 써보셨나요?”를 면접에서 한 번쯤 들어봤을 거예요. 강력하기로 유명한 이 도구가 왜 정작 비개발 팀원에게는 높은 벽이 되는지, 같은 잣대로 뜯어봅니다.
한눈에 보기
- 출시: 2002년, 호주 Atlassian
- 분류: 이슈 트래커에서 출발한 애자일 PMS
- 채택 이론: 스크럼·칸반 (애자일 중심)
- 과금(2026년 6월 기준): 무료(최대 10명) / Standard 약 $7.91 / Premium 약 $14.54 (1인당 월, 연간 결제 기준) / Enterprise 별도 견적
- 주 타깃: 소프트웨어 개발팀, IT 조직
1. 탄생 배경과 채택한 이론 모델
Jira는 2002년 버그 추적 도구로 출발했습니다. 이름부터가 “Gojira(고질라)”에서 따온 것으로, 원래는 소프트웨어의 결함(이슈)을 추적하려는 도구였어요. 그러다 애자일이 업계를 휩쓸면서, Jira는 스크럼과 칸반을 정면으로 끌어안고 애자일 프로젝트 관리의 대표 도구로 변신했습니다.
그래서 Jira의 뼈대에는 1편에서 본 애자일 이론이 그대로 박혀 있습니다. 스프린트로 일을 끊고, 백로그에 쌓고, 보드에서 흘려보내는 구조입니다. 애자일을 도구로 가장 충실하게 구현한 제품을 꼽으라면 많은 사람이 Jira를 듭니다. PM 면접에서 “어떤 협업 도구를 써봤나요?”라는 질문에 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는 분명히 불리합니다. PM·PO를 목표로 이직을 준비한다면, “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 프로젝트의 특수성 — 건설 PM 이론이 깨지는 지점
💬 댓글 0