JIRA의 복잡한 프로세스를 work.md 하나로 관리할 수 있을까?

-이슈 트래킹 도구의 본질과 문서 중심 개발에 대한 고찰

https://yozm.wishket.com/magazine/detail/3617
 
애자일 조직이라면 대부분 JIRA를 사용한다.
상태 값은 수십 개, 워크플로는 복잡하고, 이슈 타입은 세분화되어 있다.
그러다 보면 이런 질문이 생긴다.

이 복잡한 프로세스를 굳이 써야 하는가?
work.md 파일 하나로 관리할 수는 없을까?

이 글은 그 가능성과 한계를 현실적으로 분석해본 기록이다.

---

1. JIRA의 본질은 “상태 관리 시스템”이다

JIRA는 단순한 할 일 목록이 아니다.

• 상태 전이 (To Do → In Progress → Review → Done)
• 권한 기반 승인
• 히스토리 추적
• 이슈 링크 (Epic, Story, Task)
• 보고용 통계 (Burn-down, Velocity)
• 외부 시스템 연동 (Git, CI, Slack)

즉, JIRA는 조직 규모가 커질수록 필요해지는 통제 장치다.

---

2. work.md는 무엇인가?

work.md는 Git 저장소 안의 하나의 마크다운 파일이다.
예시:

 

 

# Sprint 12

## TODO
- [ ] 결제 취소 API 구현
- [ ] 정산 배치 리팩토링

## DOING
- [ ] Settlement Index 구조 개선

## DONE
- [x] Payment 도메인 테스트 추가

 

장점은 명확하다.

• Git과 동일한 이력 관리
• 브랜치 기반 변경 관리 가능
• PR과 함께 변경 내역 추적 가능
• 도구 종속성 없음

---

3. work.md로 JIRA를 대체할 수 있는가?

✅ 가능한 경우

• 1~3인 소규모 팀
• 개인 프로젝트
• 기술 실험 프로젝트
• 명확한 오너십이 있는 구조

이 경우 work.md는 오히려 더 효율적이다.
왜냐하면:

• 상태 전이 규칙이 단순함
• 승인 프로세스가 간단함
• 의사결정 비용이 낮음

---

❌ 어려운 경우

• 10명 이상 팀
• 기획/디자인/QA 분리 구조
• 고객 보고가 필요한 프로젝트
• SLA 기반 운영 프로젝트

이 경우 JIRA의 장점이 드러난다.

• 누가 언제 무엇을 했는지 추적 가능
• 상태 기반 통계 자동화
• 이슈 간 의존성 관리
• 승인 로그 보존

work.md로는 자동 통계, 승인 추적, 크로스 팀 협업을 구현하기 어렵다.

---

4. Git 중심 워크플로로 대체하는 전략

JIRA를 완전히 대체하는 대신,
Git 기반 프로세스로 단순화할 수는 있다.
예시 전략:

 

 

work.md = 계획 관리
PR = 작업 단위
CI = 품질 검증
SonarCloud = 품질 게이트
GitHub Issues = 최소 이슈 관리

 

이 구조라면:

• JIRA 없이도 품질 관리 가능
• 변경 이력 Git에 통합
• 자동화 중심 운영

---

5. JIRA가 복잡해지는 이유

JIRA가 복잡한 게 아니라,
조직이 복잡해진 것이다.

• 승인 단계가 늘어나고
• 이해관계자가 늘어나고
• 보고 체계가 요구되고
• 책임 소재가 분리된다

JIRA는 그 복잡성을 “도구로 표면화”한 것이다.

---

6. 현실적인 결론

개인 개발자 / 기술 중심 팀

work.md + GitHub Issues + PR + CI
→ 충분히 운영 가능

대규모 조직 / SI / 외주 프로젝트

JIRA 필요
다만, JIRA를 쓴다고 해서 개발 생산성이 올라가는 것은 아니다.
프로세스를 단순화하지 않으면 도구는 오히려 비용이 된다.

---

7. 전략적 관점

질문은 이것이다.

우리는 “관리”를 위해 일하는가,
아니면 “제품”을 만들기 위해 일하는가?

work.md는 개발자 중심 사고다.
JIRA는 조직 중심 사고다.
둘 중 무엇을 선택할지는
팀의 성격과 프로젝트 성격에 달려 있다.

---

마무리

JIRA를 work.md 하나로 대체하는 것은
기술적으로 가능하지만, 조직적으로는 쉽지 않다.
도구의 복잡성을 줄이기 전에
조직의 복잡성을 먼저 줄여야 한다.