Bugzilla·MantisBT·Redmine — 오픈소스 결함 추적 3종

개념

세 도구는 "태생"이 다르다

Bugzilla, MantisBT, Redmine은 모두 무료로 내려받아 직접 서버에 설치해 쓰는 오픈소스 도구다. 셋 다 결함을 등록하고 추적한다는 점에서는 같아 보이지만, 각자 태어난 배경이 다르고 그 배경이 지금의 성격을 그대로 결정한다. 이 레슨의 핵심은 기능 목록을 외우는 것이 아니라 "어떤 팀이 어떤 이유로 이걸 고르는가"를 이해하는 것이다.

Bugzilla — 대규모 오픈소스 프로젝트의 결함 추적기

Bugzilla는 모질라(Firefox를 만드는 그곳)가 자기 프로젝트의 결함을 관리하려고 만들어 20년 넘게 실제로 써온 도구다. 태생이 "전 세계에서 쏟아지는 수십만 건의 버그 리포트를 감당해야 하는 프로젝트"였기 때문에, 결함 필드가 매우 세분화되어 있다 — 심각도·우선순위는 기본이고 플랫폼(x86/ARM), 운영체제, 버전, 대상 마일스톤까지 따로 필드로 나뉜다.

이 세분화가 Bugzilla의 강점이자 부담이다. "윈도우에서만 재현되는 버그"를 조건으로 걸러내는 일이 자연스럽게 되지만, 필드가 많다는 건 결함 하나 등록할 때 채울 칸도 많다 는 뜻이다. Mozilla, Linux 커널, Apache 같은 프로젝트가 방대한 결함량을 실제로 버텨낸 이력이 있다는 신뢰성이 이 도구를 여전히 살아 있게 만든다.

MantisBT — 가볍게 시작하는 결함 추적

MantisBT(Mantis Bug Tracker)는 Bugzilla와 같은 일을 하되 훨씬 가볍다. PHP + MySQL만 있으면 설치가 끝나고, 관리 화면도 단순해서 처음 도구를 도입하는 팀이 하루 안에 운영을 시작할 수 있다.

필드가 적다는 건 표현력이 떨어진다는 뜻이기도 하지만, 소규모 팀에서는 오히려 장점이 된다. 5명짜리 팀에 "대상 마일스톤"과 "플랫폼" 필드를 강제하면 대부분 빈칸으로 남거나 아무렇게나 채워져서, 있으나 마나 한 데이터가 쌓인다. 팀 규모에 비해 과한 도구는 데이터 품질을 떨어뜨린다.

Redmine — 원래는 프로젝트 관리 도구다

Redmine을 앞의 두 도구와 나란히 놓는 것은 사실 조금 어색하다. Redmine은 결함 추적기로 태어난 게 아니라 프로젝트 관리 도구 로 태어났고, 이슈 추적은 그 안의 여러 기능 중 하나이기 때문이다. 간트차트, 일정, 위키, 문서 저장소, 시간 기록(공수 입력)이 한 곳에 들어 있다.

그래서 Redmine을 고르는 팀의 동기는 다르다. "결함을 추적하고 싶다"가 아니라 "일정·문서·결함을 한 시스템에서 보고 싶다" 가 이유인 경우가 많다. 별도의 위키와 별도의 버그 트래커를 오가는 대신 하나로 합치려는 선택이다. 반대로 결함 추적만 필요한 팀에게는 안 쓰는 기능이 화면을 차지하는 부담이 된다.

언제 무엇을 고르는가

도구가 바뀌어도 원칙은 그대로다

모듈 6 레슨 1에서 배운 결함 생명주기(New → Assigned → Fixed → Retest → Closed)와 심각도·우선순위의 구분, 그리고 좋은 결함 리포트의 조건은 세 도구 어디에서나 똑같이 적용된다. 화면 배치와 필드 이름은 다르지만 심각도·우선순위·재현 단계라는 필드가 없는 결함 추적 도구는 존재하지 않는다. 모듈 6 레슨 4에서 정리한 공통 개념(이슈 타입·워크플로·필드· 필터)을 기준으로 새 도구의 화면을 대조하면, 처음 보는 도구도 30분이면 파악된다.

실무에서 왜 필요한가

스타트업이나 SI 프로젝트, 사내 시스템을 다루는 팀에서는 Jira 라이선스 비용 때문에 오픈소스 도구를 쓰는 경우가 흔하다. 특히 외부망 접속이 막힌 금융·공공 프로젝트에서는 클라우드 SaaS 자체를 쓸 수 없어서 사내 서버에 설치하는 Redmine이나 MantisBT가 사실상 유일한 선택지가 되기도 한다.

QA로 입사한 첫날 받아든 도구가 Jira가 아니라 Redmine일 가능성은 생각보다 높다. 이때 "Jira만 써봤는데요"가 아니라 "이슈 타입이 어디 있는지 찾아보겠습니다"라고 말할 수 있는 것이 이 레슨의 목표다. 또한 도구 도입을 검토하는 자리에서 "우리 팀 규모에는 이게 과하다" 는 판단을 근거를 갖고 말할 수 있으면 신뢰를 얻는다.

실습 과제

과제 1 — 팀 상황에 도구 배정하기 (8분)

아래 세 팀에 Bugzilla·MantisBT·Redmine 중 무엇을 추천할지 고르고, 이유를 한 줄씩 적어본다.

1. 개발자 3명·QA 1명의 신규 스타트업. 지금까지 결함을 엑셀로 관리했고, 다음 주부터 도구를 쓰고 싶다
2. 사내망에서만 동작하는 공공 시스템 구축 프로젝트. 일정 관리와 산출물 문서를 별도 도구로 관리하다 보니 흩어져서 힘들다
3. 데스크톱 앱을 윈도우·macOS·리눅스 세 환경에 배포하며, 환경별로만 재현되는 결함이 자주 나온다

과제 2 — 공통 필드 찾아보기 (10분)

세 도구 중 하나를 골라 공식 사이트의 데모나 스크린샷을 찾아본 뒤, 모듈 6 레슨 4의 공통 개념 네 가지(이슈 타입 / 워크플로 / 필드 / 필터)가 그 도구 화면의 어디에 대응하는지 표로 적는다. 대응하는 것을 못 찾은 개념이 있다면, 정말 없는 것인지 이름만 다른 것인지 확인해본다.

자가 체크리스트

• Bugzilla·MantisBT·Redmine이 각각 어떤 배경에서 만들어졌는지 설명할 수 있다
• Redmine이 결함 추적기가 아니라 프로젝트 관리 도구에서 출발했다는 점과, 그것이 선택 이유에 어떻게 작용하는지 안다
• 팀 규모·제약(사내망, 예산)에 따라 세 도구 중 무엇을 추천할지 근거를 들어 말할 수 있다
• 도구가 달라도 심각도·우선순위·재현 단계라는 필드는 공통으로 존재한다는 것을 안다
• 팀 규모에 비해 필드가 과한 도구가 오히려 데이터 품질을 떨어뜨리는 이유를 설명할 수 있다

흔한 실수

• 기능이 많은 도구가 좋은 도구라고 생각한다. 5명짜리 팀에 Bugzilla의 세분화된 필드를 강제하면 대부분 빈칸이거나 엉터리 값으로 채워진다 — 집계가 불가능한 데이터가 쌓일 뿐이다.
• "Jira를 안 쓰니 결함 관리 수준이 낮다"고 단정한다. 도구 이름이 아니라 생명주기가 지켜지는지, 리포트에 재현 단계가 있는지가 수준을 결정한다.
• Redmine을 단순한 무료 Jira 대체품으로만 본다. 간트차트·위키·공수 기록을 안 쓰면 Redmine을 고른 이유의 절반이 사라진다.
• 도구를 옮기면서 상태(워크플로) 이름을 그대로 옮기지 않는다. 도구별 기본 상태 이름이 다르다고 팀의 결함 생명주기까지 바꿔버리면, 이전 결함 통계와 비교가 끊긴다.

참고 자료

• Bugzilla 공식 문서 — 필드 구성과 설치 가이드
• MantisBT 공식 사이트 — 데모 인스턴스로 화면을 직접 볼 수 있다
• Redmine 공식 가이드 — 이슈 추적 외 프로젝트 관리 기능 전반
• ISTQB Glossary — Defect Management Tool — 결함 관리 도구의 공식 용어 정의