시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 12편입니다. 11편까지 상용 도구 10개를 해부하며 그 공통의 실패를 정리했어요. 이번 편부터는 다른 세계 — 무료로 받아 직접 서버에 올리는 오픈소스 PMS로 넘어갑니다. 첫 주자는 20년 넘게 살아남은 노장, Redmine입니다. 자체 호스팅·유지보수라는 새 잣대를 더해 같은 질문을 다시 던져 볼게요.
한눈에 보기
- 출시: 2006년, 오픈소스(Ruby on Rails 기반). 2026년 6월 기준 최신 6.1.x
- 분류: 오픈소스 이슈 트래커 겸 프로젝트 관리 도구
- 채택 이론: 이슈 트래킹 중심. 플러그인으로 애자일·칸반 확장 가능
- 비용: 소프트웨어는 무료. 단, 서버 호스팅·설치·유지보수·커스텀 개발 비용은 별도
- 주 타깃: 개발팀, IT부서, 데이터를 자체 서버에 두려는 조직
1. 탄생 배경과 채택한 이론 모델
Redmine은 2006년에 등장한, 이 시리즈에서 가장 오래된 도구입니다. Ruby on Rails로 만들어졌고, 핵심은 이슈 트래킹이에요. 버그·작업·기능을 ‘이슈’로 등록하고 상태·우선순위·담당자를 붙여 추적하는, 개발 조직의 가장 기본적인 관리 방식을 구현했습니다.
상용 도구와 결정적으로 다른 점은 오픈소스이자 자체 호스팅이라는 사실입니다. SaaS처럼 가입해서 쓰는 게 아니라, 소프트웨어를 내려받아 우리 서버에 직접 설치해요. 데이터가 100% 우리 손안에 있죠. 이 “통제권”이 Redmine의 존재 이유입니다. 방법론을 강제하지 않고, 플러그인으로 칸반 보드나 스크럼을 덧붙여 씁니다. PM/PO 입장에서 보면, 도구가 우리에게 일하는 방식을 강요하지 않는다는 건 양날의 검이에요 — 자유로운 만큼 “우리 팀의 프로세스를 우리가 직접 설계해야 한다”는 숙제가 따라옵니다.
2. 핵심 구조와 데이터 모델
Redmine의 구조는 이슈 중심으로 단순합니다.
프로젝트(Project) → 이슈(Issue) → 하위 이슈(Subtask) + 버전·카테고리여기에 간트 차트, 캘린더, 시간 추적, 위키, 포럼이 기본으로 붙고, 역할 기반 접근 제어(RBAC)로 클라이언트·PM·개발자가 같은 프로젝트를 권한별로 봅니다. Git·Subversion 같은 버전 관리 시스템과 연동해 커밋과 이슈를 잇는 것도 강점이에요. 한 인스턴스에서 여러 프로젝트를 관리할 수 있습니다. PM/PO라면 이 RBAC 구조가 특히 반가울 텐데요, 외부 클라이언트에게는 보여줄 것만 열고 내부 개발 논의는 가리는 식으로 권한을 설계할 수 있기 때문입니다.
3. 강점 — 무엇을 잘하는가
Redmine의 강점은 상용 도구가 줄 수 없는 것들입니다.
첫째, 완전한 데이터 통제와 무료입니다. 우리 서버에 설치하니 데이터가 외부로 나가지 않아요. 보안이 민감한 기관·기업, 인트라넷 환경에 적합합니다. 1인당 과금이 없어서, 사용자가 늘어도 라이선스 비용이 0이에요. 사람이 많은 조직일수록 비용 이점이 커집니다.
둘째, 검증된 안정성과 수명입니다. 20년 가까이 살아남아 지금도 활발히 업데이트되고 있어요(2026년 6월에도 신규 버전 출시). 한때 잘 나가다 사라지는 신생 도구와 달리, “내년에도 있을 것”이라는 신뢰가 있습니다. 도구를 고르는 PM/PO에게 이 지속 가능성은 생각보다 중요한 평가 기준이에요 — 1~2년 안에 서비스가 종료되면 마이그레이션 비용이 고스란히 우리 몫이 되니까요.
셋째, 깊은 커스터마이즈와 연동입니다. 오픈소스라 워크플로우·필드를 코드 수준에서 바꿀 수 있고, 플러그인 생태계로 기능을 확장해요. 버전 관리 연동은 개발 조직에 특히 유용합니다.
4. 현장의 복잡성 — 팀원이 안 쓰는 지점
Redmine의 한계는 상용 도구와는 결이 다릅니다. 무료의 대가가 따로 있어요.
무료지만 ‘공짜’는 아닙니다. 소프트웨어는 무료여도, 서버를 마련하고 설치하고 보안 패치를 적용하고 플러그인을 관리하는 일은 전부 우리 몫이에요. 설치 자체가 Ruby on Rails 환경을 다뤄야 해서 비개발자에겐 벽이고, 실제로 “설정하려고 사람을 따로 고용했다”는 사용 후기가 흔합니다. 11편에서 본 ‘구축하는 사람과 쓰는 사람의 분리’가, Redmine에서는 서버 관리자라는 형태로 더 무겁게 나타나요. PM/PO가 도입을 검토한다면, 이 운영 인건비를 “공짜 도구”의 숨은 가격표로 반드시 계산에 넣어야 합니다.
UI가 낡았습니다. 거의 모든 사용자가 입을 모아 지적하는 약점이에요. 버전이 올라가도 인터페이스는 늘 구식이고, 한 동작에 페이지가 새로 로딩되는 옛 방식이 남아 있습니다. Linear·monday 같은 현대적 도구에 익숙한 팀원에게는 진입 자체가 내키지 않아요. “기술자인 나는 괜찮지만, 일반 사용자는 예쁘고 시각적인 걸 원한다”는 관리자의 토로가 이를 압축합니다. 이 시리즈의 핵심 잣대 ‘팀원이 매일 켜고 싶은가’에서, Redmine은 기능과 무관하게 불리해요.
입력 부담은 여기서도 그대로입니다. 게다가 지원은 커뮤니티 포럼에 의존하니, 문제가 생겼을 때 즉각 해결을 보장받지 못해요. 그리고 무엇보다, 이슈 상태를 갱신하고 진행을 기록하는 일은 여전히 사람이 손으로 해야 합니다. 오픈소스라고 입력의 본질적 부담이 사라지는 건 아니에요. 통제권을 얻은 대신, 유지보수와 입력이라는 짐을 모두 떠안는 구조입니다.
5. 한 줄 평
Redmine은 데이터 통제와 무료가 절실하고, 서버를 관리할 기술 역량을 갖춘 개발 조직에게는 20년간 검증된 든든한 선택지입니다. 그러나 낡은 UI와 유지보수 부담 때문에, 다양한 직군이 매일 가볍게 쓰는 도구로는 거리가 멀어요.
짚고 가기: 오픈소스는 “비용”이라는 한 가지 잣대를 극적으로 바꿉니다 — 1인당 과금이 사라져요. 그런데 그 자리에 ‘유지보수’라는 새로운 비용이 들어섭니다. 그리고 정작 이 시리즈의 핵심 문제 — 팀원이 쓰고 싶어 하는가, 입력이 단일한가 — 는 오픈소스라고 풀리지 않아요. 무료는 비용 문제를 풀 뿐, 사용성 문제를 풀지는 못합니다. PM/PO 면접에서 “왜 이 도구를 골랐나요?”라는 질문을 받는다면, 바로 이 트레이드오프를 짚어내는 답이 좋은 평가를 받습니다.
비슷한 고민을 하는 분이 많을 거예요. 어떤 도구를 써봤고 무엇이 안 맞았는지, 누스쿨 커뮤니티에서 서로의 경험을 나눠 보면 도구 선택의 감각이 훨씬 빨리 자랍니다.
다음 편 예고
Redmine이 “오래되고 낡았지만 든든한” 오픈소스라면, 다음 편(13부)의 OpenProject는 다릅니다. 오픈소스이면서도 엔터프라이즈급 기능과 현대적 UI를 노린 도구예요. 자체 호스팅의 통제권을 유지하면서 상용 도구의 세련됨까지 잡으려는 이 시도가, 과연 두 마리 토끼를 잡았는지 살펴보겠습니다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 11. 중간 정리 ① — 상용 도구가 공통으로 무너지는 자리
다음 글: IT 프로젝트 관리 도구 완전 해부 – 13. OpenProject — 엔터프라이즈를 노린 오픈소스
💬 댓글 0