지금, 프로젝트 관리에 Jira 대안이 필요한 이유

이 글은 스위그와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

“AI 덕분에 개발 속도는 몇 배나 빨라졌는데, 왜 제품 출시는 오히려 늦어질까요?”

요즘 Claude Code와 Cursor로 무장한 개발자들이 하루에 완성할 수 있는 기능의 양은 과거와 비교하기 어렵습니다. 그뿐만이 아닙니다. 기획자, 디자이너, 개발자가 팀을 이뤄 몇 달을 매달려야 모습이 보일까말까 하던 서비스가, 이제는 능력 있는 개인이나 소규모 팀에 의해 몇 주 만에 나타나기도 합니다.

몇 년 전 유행하던 사이드 프로젝트와는 질적으로 달라 보입니다. 비즈니스 로직은 정교해졌고, 프로젝트의 규모와 복잡도는 기하급수적으로 커졌습니다. 혼자서 3~4개의 프로덕트를 동시에 돌리는 메이커 역시 더는 낯설지 않은 풍경이죠. ‘만드는 것’의 장벽이 역사상 가장 낮은 시대가 아닐까 생각합니다.

그런데 이상합니다. 제가 만난 분들은 여전히 제품의 배포 일정이 미뤄지고 스프린트마다 ‘못다 한 일’이 쌓여간다고 합니다. 이야기를 듣다 보면 그 이유는 비슷했습니다. 지금의 관리 방식과 도구가 기술의 발전 속도를 따라가지 못했기 때문입니다.

그래서 글을 썼습니다. 우리는 언제까지 ‘진짜 일’이 아니라 ‘티켓’에 시간을 쏟아야 할까요? 지금 AI 시대에 걸맞은, 새로운 프로젝트 관리의 철학이 필요한 시점입니다.

생산성 폭발을 가로막는 숨겨진 병목

문제는 협업이 시작되는 순간부터 나타납니다. 혼자서 일을 정리할 때는 노션 한 페이지면 충분합니다. 하지만 팀이 커지고 다루는 프로젝트가 많아지면 사람들은 불안함을 느낍니다. 그래서 습관적으로 ‘업계 표준’이라 불리는 무거운 프로젝트 관리 툴들을 도입하기 시작합니다. Jira, Asana, Trello 같은 것들이죠.

여기서 모순이 생깁니다. 일할 때는 AI를 써서 광속으로 코드를 짜고 디자인을 뽑아내는데 정작 그 결과물을 관리하기 위해 과거의 행정 업무를 답습하고 있는 것입니다. 결과물에 대한 의견을 조율하고, 핵심 비즈니스를 검토하며, 고객을 만나기도 부족한 시간은 정작 이런 질문에 답하는 데 쓰입니다.

• “Jira 티켓 생성하셨나요?”
• “워크플로우 상태값 업데이트 안 되어 있네요.”
• “이 필드는 필수 입력 사항입니다.”

혁신적인 서비스를 만들기 위해 모인 인재들이 하루 업무 시간의 상당 부분을 툴을 관리하고, 데이터를 입력하고, 현황판을 꾸미는 데 쓰고 있습니다. 화려한 칸반 보드와 보기 좋은 타임라인에 잘 정리된 차트는 남지만, 실행 속도는 느려질뿐더러 데이터에 대한 신뢰 역시 낮아집니다.

어느새 실행(Shipping)을 위해 존재하던 도구들이 지금은 움직임을 가로막는 가장 큰 병목(Bottleneck)이 되어버린 것입니다. 그래서 우리는 다시 질문하게 됩니다.

우리는 더 나은 제품을 만들기 위해 모였는가,

아니면 티켓과 상태값을 관리하기 위해 모였는가.

과거의 프로젝트 관리 도구와 3가지 한계

우리가 도입해 온 기존의 프로젝트 관리 도구들은 대부분 AI 시대 이전에 설계된 유물입니다. 이들은 생산성의 폭발이 필요한 지금, 실무자에게 ‘입력’이라는 제2의 노동을 강요하는 존재로 바뀌었습니다.

1. 모든 SaaS는 당신의 시간을 원한다

IT 업계에는 이미 수많은 SaaS 도구가 자리 잡고 있습니다. Slack과 같은 메신저, GitHub를 비롯한 코드 저장소, Figma 등 디자인 툴, Notion으로 대표되는 문서 도구까지. 각 도구는 자신이 맡은 역할에 최적화되어 있으며 분명히 높은 생산성을 만들어내고는 합니다.

이러한 SaaS는 모두 실제 작업이 이뤄지는 공간입니다. 따라서 사용자가 오래 머무르며 작업 의존도를 높이는 것 자체가 도구의 유용성을 입증하는 지표입니다. 그렇게 주요 SaaS 기업이 체류 시간과 리텐션을 핵심 지표로 삼아 성장해 온 것은 충분히 합리적인 전략이었습니다.

문제는 이 전략이 모든 종류의 SaaS에 그대로 적용되면서 발생합니다. 관리를 위한 도구마저 사용자의 시간을 뺏고자 ‘체류 시간’을 핵심 지표로 삼은 것입니다. 이제 사람들은 SaaS가 유도한 대로 같은 작업을 여러 번 기록하고 설명해야 하는 상황에 놓입니다. 코드는 코드대로, 디자인은 디자인대로, 논의는 메신저대로 진행되지만, 그 결과를 다시 정리해 입력하는 데 시간을 쓰는 것이 당연한 절차처럼 굳어졌습니다.

2. 관리를 위한 ‘입력’의 이상과 현실

그렇게 도구들이 쌓이고 나면 실무자는 이제 모든 과정에서 일을 위한 일을 해야 합니다. 티켓을 만들고, 매번 상태를 바꾸고, 끝난 뒤에는 다시 정리된 결과를 입력합니다.

이를 위한 촘촘한 필드와 규칙은 ‘체계적인 관리’의 상징처럼 여겨집니다. 하지만 이 구조는 중요한 3가지 전제를 깔고 있습니다. 실무자는 언제나 입력할 여유가 있고, 이 정보는 항상 정확하며, 조금도 지연되지 않는다는 전제입니다.

현실은 다릅니다. 실무자들은 보통 실행에 몰입할수록 입력을 뒤로 미룹니다. 가장 바쁘기에 관리가 중요한 시점일수록 도구의 데이터는 가장 비어 있습니다. 의무감에 기껏 입력한 정보 역시 주관적이라 확실치 않습니다.

이는 마치 택시 기사에게 운전 중에 수기로 운행 일지를 작성하라고 요구하는 것과 비슷합니다. 목적지는 분명한데 택시 기사가 기록을 남기느라 운전에 집중하지 못하면 어떨까요? 결국 도착 시간은 늦어지고 사고의 위험은 커집니다. 기록은 남았을지 몰라도, 그 기록이 만들어진 과정은 결코 효율적이지 않은 겁니다.

3. “그래서, 그 기능 언제 배포되나요?”

이런 흐름의 한가운데 놓인 프로젝트 관리 도구는 또 다른 특징을 가집니다. CRM이나 HR, 회계 시스템은 특정 역할의 사람들이 주로 사용하는 도구입니다. 반면, 프로젝트 관리 도구는 다릅니다. 개발자, 디자이너, 기획자뿐 아니라 영업과 마케팅, 관리자와 경영진까지 모두가 각자의 목적을 가지고 들여다보는 공간으로 쓰입니다.

문제는 이들이 사용하는 언어와 관심사가 모두 다르다는 점입니다. 개발자는 코드와 이슈를 보고 싶어 하고, 디자이너는 산출물과 흐름을 중시합니다. PM은 일정과 우선순위를, 비즈니스팀은 고객 가치와 마감일을, 관리자는 전체 진행 상황과 리스크를 확인하려 합니다. 이 서로 다른 요구를 하나의 도구 안에서 모두 만족시키려다 보니, 프로젝트 관리 도구는 점점 더 많은 필드와 상태값, 복잡한 워크플로우를 가져야 했습니다.

결국 이 복잡성을 담기 위해 이들 도구는 가장 기능적인 언어, 즉 ‘개발자의 언어’를 택합니다. 복잡한 상태 관리, 쿼리로만 움직이는 데이터, 어려운 로직과 자동화가 기본이 된 거죠. 결국 비개발 직군에게 이들 도구는 접근하기 힘든 암호문이 되어버립니다. 어느 순간부터 그들은 Slack으로 돌아와 묻습니다.

"그래서 그 기능, 언제 배포되나요?"

비싼 돈을 내고 툴을 들여와도 소통 비용은 줄어들지 않는 아이러니입니다.

티켓 너머 ‘진짜 일’이 존재하는 공간

그렇다면 진짜 일은 어디에 존재할까요? 본질로 돌아가 봅시다.

1. 실무자의 역할은 ‘입력’이 아닌 ‘실행’

앞서 말한 택시 기사의 예시를 다시 보겠습니다. 오늘날 택시 기사들은 손으로 기록하지 않고도 운전에만 집중할 수 있습니다. ‘미터기’와 ‘GPS’가 있기 때문입니다. 그들이 핸들을 꺾고 엑셀을 밟는 순간, 기계는 자동으로 이동 거리와 요금을 계산하고 주행 경로를 서버에 기록합니다. 모두 운전에 집중할 뿐 그 어떤 관리 행위도 하지 않습니다.

기사의 역할은 사고 없이 운전하는 것이고, 관리 도구의 역할은 그 운전의 결과를 정확히 읽어내는 것입니다. 만약 기사에게 운전 중에 일지를 쓰게 한다면 운전의 질도, 기록의 정확성도 동시에 떨어질 수밖에 없습니다.

프로젝트도 크게 다르지 않습니다. 이 작업의 경로에서 실무자가 해야 할 역할은 ‘입력’이 아니라 ‘실행’입니다. 그리고 그 실행은 이미 각자의 작업 공간에서 실시간으로 흔적을 남기고 있습니다.

2. 진짜 일이 있는 현장

우리는 흔히 Jira 티켓이나 간트 차트가 프로젝트의 현황이라고 착각합니다. 하지만 그것은 누군가에 의해 가공된 2차 정보일 뿐입니다. 프로젝트의 관리 대상들은 ‘실제로 일하는 공간’에 있습니다.

• 개발자의 진척도는 티켓의 상태값이 아니라, Git에 올라가는 코드(Commit, PR)에 있습니다.
• 디자이너가 만든 버전들은 작업 로그가 아니라, Figma의 수정 내역(History)에 담겨 있습니다.
• 팀의 의사결정은 회의록 문서가 아니라, Slack의 대화 스레드 속에 살아 있습니다.

지금 대부분의 팀에서 실무자가 사용하는 도구는 정해져 있습니다. 개발자는 코드 저장소에서 일하고, 디자이너는 디자인 툴에서 사고하며, 팀의 논의는 메신저와 문서 위에서 이루어집니다. 이 흐름을 바꾸는 것은 쉽지 않을뿐더러 바꿀 필요도 없습니다. 이처럼 진실의 원천(Source of Truth)은 실무자들이 일하는 공간에 실시간으로 쌓이고 있습니다.

그럼에도 우리는 진짜 흐름이 쌓이는 현장을 외면한 채, 실무자를 관리 도구에 ‘적응시키는 것’이 문제의 해답이라고 믿어왔습니다. 실무자의 상황을 어떻게 관리 도구 안으로 끌고 올지만 고민해 온 것입니다.

‘입력’시키지 않아도 ‘흐름’을 알 수 있는 관리

관리 도구가 실무자의 일하는 방식을 대체하려는 순간, 그 도구는 관리 도구로서 실패합니다. 관리의 역할은 일을 ‘시키는 것’이 아니라, 이미 일어나고 있는 실행을 읽고, 연결하고, 판단할 수 있는 상태로 만드는 것입니다. 그래서 관리의 출발점은 언제나 계획이 아니라 실행이어야 합니다. 계획은 실행으로 이어질 때 의미가 있고, 실행의 흔적은 이미 현장에 남아 있기 때문입니다.

1. 사람들이 툴이 쓰지 않는 진짜 이유: ‘입력’과 ’방해’

저희 팀은 ‘뤼이도’라는 프로젝트 관리 툴을 만들고 있습니다. 뤼이도와 함께 현장에서 관리에 발목 잡혀 대안을 고민하는 팀을 만나보면 상황은 비슷했습니다. 관리자들은 “Jira를 도입했는데 아무도 안 써요.”라고 말하고, 실무자들은 “실제 일하는 시간보다, 관리하는 일이 더 많아요.”라고 말했습니다.

처음에는 기존 도구의 고질적인 문제 몇 가지만 바꿔보겠다고 생각했습니다. Jira와 같은 기존의 프로젝트 관리 툴은 분명 현장의 체계를 바꾸었다고 믿었기 때문입니다. IT라는 영역의 애매모호한 업무 태스크를 일관성 있게 통제할 표준을 만들어 주었죠. 무엇보다 갈수록 복잡해지는 기술 프로젝트에 관리라는 행위가 없으면 일은 산으로 갈 것입니다.

그래서 뤼이도 역시 기존의 성공 공식을 따랐습니다. 관리 화면을 더 보기 좋고 쓰기 좋게 만드는 데 집중한 것입니다. 초기에는 반응도 괜찮았습니다. 사용자의 리텐션과 체류 시간이 높은 것을 보며 환호했죠. 그렇게 “사용자들이 우리 툴을 자주 쓰는구나, 우리가 잘하고 있구나”라고 생각했습니다.

하지만 현장의 목소리를 듣고 나서야 그것이 오만한 착각이었음을 깨달았습니다. 실무자들에게 잦은 접속은 생산성이 아니라 방해(Interruption)였습니다. 코딩하다가 들어와서 티켓 옮기고, 디자인하다가 들어와서 댓글 달고…. 레거시 툴의 문제를 해결하겠다고 나섰지만, 결국 똑같이 실무자의 발목을 잡고 있었던 것입니다.

여기서 깊이 깨달은 것이 있습니다. 기존 도구의 ‘입력 기반 관리’ 구조는 필연적으로 놓치는 것들이 존재한다는 것입니다. 입력에 의존하면 정보는 언제나 한 박자 늦어집니다. 서로 일을 확인하느라 다시 묻고 정리하다 보면, 흐름이 끊기고 결정이 늦어지다 출시가 미뤄집니다.

더 큰 문제는 이러한 입력의 시간이 몰입을 깬다는 데 있습니다. 상태를 입력하기 위해 일을 잠시 멈추면 사람들은 다시 몰입 상태로 돌아오기까지 더 많은 시간이 필요합니다. 결국 사람들이 도구를 쓰지 않는 이유는 관리가 싫어서가 아니라, 입력으로 흐름이 끊기는 경험이 싫기 때문입니다.

2. 도구에 들어오지 못하게 했더니, 더 깊게 머문다

그래서 방향을 완전히 틀었습니다. 목적은 하나였습니다. “실무자가 우리 툴에 들어오지 않게 만들자.”

GitHub, Figma, Slack처럼 그들이 이미 머무르고 있는 도구에 우리가 찾아가기로 했습니다. 그들이 뤼이도를 의식하지 않고 일해도, 뤼이도의 프로젝트 관리 화면에 업무 데이터가 쌓이게 했습니다.

아이러니하게도 접속에 대한 강요를 없애자, 제품 내에 체류하는 시간이 비약적으로 늘어났습니다. 과거에는 입력을 위해 5분씩 10번 들어왔다면, 이제 입력은 시스템에 맡기고 분석과 의사결정을 위해 하루 3~4시간씩 깊게 머물기 시작한 것입니다. 신뢰할 수 있는 데이터가 자동으로 쌓이니 사람들은 ‘히스토리 탐색’과 ‘다음 전략 수립’이라는 진짜 관리 업무를 하러 들어오게 되었습니다.

이것이 우리가 발견한 좋은 관리의 본질이었습니다. 입력을 강요해 만든 데이터는 쓰레기가 되지만, 입력을 없앤 데이터는 자산이 됩니다.

3. 지금, Jira의 대안이 필요한 이유

저희 팀이 현장에서 발견한 진짜 해결책은 더 많은 필드도, 더 정교한 워크플로우도 아니었습니다.

실행과 관리가 분리되지 않은 프로젝트 관리의 새로운 구조였습니다. 더는 입력 기반 관리가 폭발하는 생산성을 가로막아서는 안 된다는 철학이었습니다. 이제는 관점을 바꿔야 합니다.

좋은 프로젝트 관리란 입력이 없어도 흐름이 보이는 데 있습니다. 그저 예쁜 칸반이 아닌 실제 현장의 데이터, 멈춰서서 입력하지 않아도 알아서 모이는 구성이 필요합니다. 새로운 시대의 프로젝트 관리 도구는 그 흐름을 쉽게 파악하고 관여하는 일에만 집중해야 합니다.

사람이 도구에 맞추는 시대에서, 도구가 사람의 행동을 이해하는 시대로의 이동이 필요합니다.

마치며

우리는 종종 착각에 빠집니다. 밀린 Jira 티켓을 정리하고, 회의록을 깔끔하게 다듬고 나면 묘한 뿌듯함이 밀려옵니다. “오늘 하루, 참 열심히 살았다” 싶은 안도감도 함께 옵니다. 대시보드가 비워지는 것만으로 우리는 무언가를 해냈다는 느낌을 받습니다.

하지만 한 번쯤은 냉정하게 물어야 합니다. 그것이 정말 ‘일’이었을까요? 티켓 상태를 완료로 바꾸는 행위가 고객에게 어떤 가치를 주었나요? 회의록 정리 자체가 제품의 버그를 고쳤을까요?

실무자는 본질적으로 실행하는 사람입니다. 코드를 쓰고, 디자인을 만들고, 문제를 해결해야 합니다. 특히 AI로 1인당 생산성이 비약적으로 높아진 지금, 사람이 써야 할 시간은 더욱더 ‘본질적인 일’에 가까워져야 합니다. 일을 위한 일(Work about Work)이 주는 가짜 성취감을 경계해야 합니다. 그것만으로는 제품은 단 1mm도 전진하지 않습니다.

그래서 지금 필요한 변화는 ‘일의 관리’를 바라보는 관점의 변화입니다. 관리가 많아질수록 일이 잘된다고 믿는 대신 관리할 필요가 줄어드는 구조를 만들고 있는지를 물어야 합니다. 좋은 팀은 관리하지 않는 팀이 아니라, 관리 때문에 흐름이 끊기지 않는 팀입니다. 비효율을 걷어내 본질에 집중하려는 팀에게 필요한 건 오직 이 질문뿐입니다.

우리는 일을 관리하고 있는가,

아니면 그저 관리한다는 착각 속에 있는가.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.