본문은 The Concurrent Mind의 글 <Stop Using JIRA: How We Scaled to 50 Engineers Using Only a Markdown File>을 번역한 글입니다. 필자는 프로그래머이자 기술 콘텐츠 크리에이터로, 코드와 창의성, 그 사이에 숨겨진 교훈에 대해 글을 공유하고 있습니다. 이번 글은 복잡한 프로젝트 관리 도구에 지친 한 엔지니어링 리더(필자)가 마크다운 파일 하나로 팀의 업무 방식을 근본적으로 바꾸고, 배포 빈도를 3배로 끌어올린 실험의 기록입니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 각주(*표시)는 '번역자주'입니다.

미리 요점만 콕 집어보면?

JIRA는 나쁜 제품이 아니지만, 대부분의 팀에게는 실제로 존재하지 않는 문제를 위해 설계된 도구입니다.
마크다운 파일 하나(WORK.md)로 프로젝트를 관리한 결과, 배포 빈도는 3배 증가하고 티켓 관리에 쓰던 주당 6시간이 45분으로 줄었습니다.
최고의 프로젝트 관리 시스템은 '사라지는' 시스템, 즉 사용하는 데 드는 시간이 논의하는 데 드는 시간보다 적은 시스템입니다.

모든 것의 시작:JIRA이슈 4,200개를 삭제하게 만든 티켓

제가 JIRA 이슈 4,200개를 일괄 삭제하게 만든 티켓의 이름은 PLAT-4892였습니다. 그 티켓을 찾는 데 11분이 걸렸습니다. 보드 3개를 뒤지고, 에픽 2개를 파헤쳤는데요. ‘리뷰 중(In Review)’ 상태의 태스크들이 무덤처럼 쌓여 있었고, 그것들을 기억하는 엔지니어는 아무도 없었습니다. 겨우 찾아낸 티켓의 설명란에는 “그거 고치기”라고만 적혀 있었고, 담당자는 8개월 전에 퇴사한 사람이었습니다.

그날 오후, 무언가가 제 안에서 끊어졌습니다. 그다음 우리 레포지토리에 들어가 WORK.md라는 파일을 하나 만들었습니다. 그리고 제 커리어를 끝낼 수도 있는 슬랙 메시지를 하나 보냈습니다.

“우리는 JIRA를 그만 씁니다. 다음 주 월요일부터, 이 마크다운 파일이 우리의 전체 프로젝트 관리 시스템입니다.”

CTO는 4초 만에 답장을 보냈습니다. “내 사무실로. 지금 당장.”

모든 걸 끝낼 뻔한 미팅

솔직히 말하자면, 저는 손에 땀을 쥐고 그 의자에 앉았고, 머릿속으로는 사직서를 반쯤 써놓은 상태였습니다.

“엔지니어 12명을 텍스트 파일 하나로 관리하겠다는 거야?” 그가 말했습니다.

“우리는 일을 관리하느라 너무 바빠서, 정작 일 자체를 어떻게 하는지 잊어버렸습니다.” 제가 대답했습니다.

그는 한 시간처럼 느껴지는 시간 동안 저를 쳐다보았습니다. 그리고 예상치 못한 말을 했는데요.

“30일을 줄게. 배포 빈도가 단 한 번이라도 떨어지면, 자네는 끝이야.”

그 후 한 달 동안 저는 제대로 잠들지 못했습니다.

내 직업을 구한 시스템

첫날 우리의 WORK.md는 이렇게 생겼습니다.

# WORK.md - Week of March 8

## Shipping This Week
- [ ] Auth: rate limiting on login (maria)
- [ ] Search: fuzzy matching (dev)
- [ ] API: deprecate v1 endpoints (james)

## Blocked
- Payment refactor waiting on Stripe keys (sarah)
  ^ asked finance Tuesday, following up

## Next Up
- Mobile push notifications
- Dashboard redesign

## Shipped
- March: 0 features (we just started)

전체 시스템이 이게 전부였습니다. 워크플로우도 없고, 커스텀 필드도 없고, 오후 내내 잡아먹는 *그루밍 세션도 없었습니다. 그저 태스크, 담당자, 블로커가 모두에게 보이는 것, 그게 전부였습니다.

*백로그 그루밍(Backlog Grooming): 백로그 항목을 검토하고 정리하는 정기 회의

이 파일은 우리 *모노레포에 들어 있었습니다. 버전 관리는 Git이 처리했고, 모든 변경은 풀 리퀘스트를 거쳤습니다. 무언가를 끝내면 체크박스에 표시했고, 막히면 맥락과 함께 적어뒀습니다.

*모노레포(Monorepo): 여러 프로젝트의 코드를 하나의 저장소에서 관리하는 방식

다시는 돌아가지 않겠다고 확신한 순간

그렇게 19일 차, 우리의 배포 빈도가 2배로 뛰었습니다. 더 열심히 일해서가 아니었는데요. ‘일에 대한 일’을 그만뒀기 때문입니다. *스탠드업은 45분짜리 상태 보고 쇼에서 8분짜리 실제 커뮤니케이션으로 바뀌었습니다. 엔지니어들은 더 이상 “그 티켓 어디 있어?”라고 묻지 않게 되었습니다. 답은 항상 같은 파일, 같은 장소에 있었으니까요.

*스탠드업(Standup): 매일 아침 짧게 진행하는 팀 미팅

한 시니어 개발자가 있었습니다. 3년 동안 모든 프로세스 변경에 불만을 제기하던 사람이었습니다. 그가 제 자리로 걸어와서 이렇게 말했는데요. “이걸 인정하기 싫지만, 태어나서 처음으로 다른 사람들이 뭘 하고 있는지 실제로 알게 됐어요.”

바로 그때 알았습니다. 우리가 진짜 무언가를 찾았다는 것을 말이죠.

3년 후, 엔지니어 50명

그렇게 우리는 다시는 JIRA로 돌아가지 않았습니다. 배포 빈도는 3배가 되었습니다. 그리고 티켓 관리에 쓰는 주당 시간은 6시간에서 45분으로 줄었습니다. “이 티켓 어디 있어?”라는 슬랙 메시지는 완전히 사라졌습니다. 하지만 숫자로는 실제로 무엇이 바뀌었는지 담아낼 수 없었는데요.

엔지니어들은 상태를 업데이트하는 대신 서로 대화하기 시작했습니다. 소프트웨어는 프로세스가 아니라, 사람이 만드는 것이라는 사실을 다시 기억하게 되었습니다.

아무도 듣고 싶어 하지 않는 불편한 진실

JIRA는 나쁜 제품이 아닙니다. 제가 말하고 싶은 건 JIRA를 쓰지 말자는 말을 하려는 것이 아닙니다. 다만 대부분의 팀이 실제로 가지고 있지 않은 문제를 위해 설계된 제품이라는 겁니다. 우리는 “진짜 회사는 JIRA를 쓴다”는 이유로 이 제품을 도입했습니다. 복잡함이 성숙함처럼 느껴져서 설정을 이리저리 만졌습니다. 그 고통이 프로페셔널함의 대가라고 생각했기에 참고 견뎠죠.

그러나 고통의 원인은 비용이 아니라, 낭비였습니다. 최고의 프로젝트 관리 시스템은 ‘사라지는 시스템’입니다. 사용하는 데 걸리는 시간이, 그것에 대해 논의하는 데 걸리는 시간보다 적은 시스템 말입니다.

우리에게 그 답은 마크다운 47줄이었습니다. 그렇게 3년째입니다. 현재 엔지니어는 50명이지만, 나는 그날 오후, “마침내 더는 못 참겠다고 결심”한 이후로 단 한 번도 티켓 관리 시스템을 열어본 적이 없습니다.

여러분의 생각은 어떠신가요?

<원문>

Stop Using JIRA: How We Scaled to 50 Engineers Using Only a Markdown File