개념
도구 비교표는 왜 답을 주지 않는가
"테스트 관리 도구 추천"을 검색하면 비교표가 쏟아진다. 기능 목록에 체크 표시가 줄지어 있고, 대부분의 도구가 대부분의 칸에 체크가 있다. 읽고 나면 오히려 더 못 고르겠다.
이유는 단순하다. 기능은 수렴하고, 차이는 다른 데 있기 때문이다. 어떤 도구든 케이스를 만들고 실행하고 결과를 기록한다. 실제로 팀을 가르는 것은 기능 유무가 아니라 우리 팀의 조건과 도구의 전제가 맞는가 이다.
이 모듈의 앞선 레슨들에서 도구를 하나씩 봤다. 이 레슨은 그것들을 놓고 고르는 방법 을 다룬다. 그리고 대부분의 팀이 마주치는 더 현실적인 질문 — "지금 쓰는 걸 갈아타야 하나" — 에도 답한다.
판단 축 다섯 개
도구 선택은 이 다섯 질문의 답으로 거의 결정된다.
축 1 — Jira를 쓰는가, 그리고 얼마나 깊게 쓰는가
가장 강력한 축이다. Jira가 조직의 중심이고 요구사항·결함·스프린트가 전부 거기 있다면, Jira 안에서 도는 도구(Xray·Zephyr Scale)의 이점이 크다. 화면 전환이 없고 추적성이 자연스럽게 생긴다.
반대로 Jira를 결함 추적 정도로만 쓴다면 그 이점이 작아지고, 독립형 도구(TestRail·Qase 등)의 전용 화면이 더 편하다. 모듈 22 레슨 1에서 본 "Jira 종속"이라는 대가도 함께 고려해야 한다.
축 2 — 자동화 결과를 함께 봐야 하는가
자동화 비중이 높다면 API·CLI의 품질 이 도구의 실질적 성능이다. 수동 케이스 UI가 아무리 좋아도, CI 결과를 밀어 넣기가 번거로우면 자동화 결과는 결국 CI 로그에만 남는다.
확인할 것 — 표준 리포트 형식(JUnit XML 등)을 바로 받는가, 케이스 매핑 방식이 명확한가, 실행 회차가 자동으로 쌓이는가. 앞 레슨의 trcli가 그 예다.
축 3 — 추적성을 어느 수준까지 요구받는가
모듈 25에서 본 규제·인증 도메인이라면 요구사항 ↔ 케이스 ↔ 실행 ↔ 결함 매트릭스와 감사 리포트가 필수다. 이게 필요하면 선택지가 크게 좁아진다 (Xray, PractiTest, HP ALM 계열, TestRail의 References 활용 등).
일반 웹 서비스라면 여기에 과투자할 이유가 없다.
축 4 — 예산과 라이선스 모델
사용자당 과금이 대부분인데, 누구까지 계정이 필요한가 가 실제 비용을 결정한다. 결과를 보기만 하는 PO·기획자에게도 유료 계정이 필요한 도구가 있고, 읽기 전용은 무료이거나 저렴한 도구가 있다.
무료·오픈소스가 필요하다면 TestLink 같은 선택지가 있지만, 대가는 셀프호스팅 운영 비용과 UI의 노후함 이다. 모듈 22 레슨 3에서 본 그대로다.
축 5 — 셀프호스팅이 필요한가
망 분리, 데이터 반출 금지, 보안 규정 때문에 클라우드를 못 쓰는 조직이 국내에 적지 않다. 이 조건 하나로 후보의 절반이 사라진다. 가장 먼저 확인해야 할 축인데 마지막에 발견되는 경우가 많다.
후보들의 성격 — 기능이 아니라 성향으로
앞의 다섯 축 위에 놓고 보면 각 도구의 자리가 보인다.
| 도구 | 성향 한 줄 | 특히 잘 맞는 조건 |
|---|---|---|
| TestRail | 케이스 저장소와 실행 이력 분리가 명확한 표준형 | 수동 회귀 비중이 있고, 회차별 이력 비교가 중요한 팀 |
| Xray / Zephyr Scale | Jira 안에서 모든 것이 끝남 | Jira가 조직의 중심이고 추적성이 중요할 때 |
| Qase | API 우선·현대적 UI, 개발자 친화 워크플로 | 자동화 비중이 높고 가벼운 도입을 원하는 팀 |
| PractiTest | 대시보드 커스터마이즈와 상세 보고가 강점 | 요구사항이 복잡하고 보고 요구가 많은 중견 조직 |
| Kualitee | 테스트·결함·요구사항 모듈이 한 묶음, 비용 효율 | 별도 결함 도구 없이 한 도구로 끝내고 싶을 때 |
| Testmo / Testiny | 수동·자동 결과 통합, 가벼운 설정 | 모듈 22 레슨 2 참고 |
| TestLink | 무료 오픈소스, 셀프호스팅 | 예산이 0이고 운영 인력이 있을 때 |
| HP ALM 계열 | 엔터프라이즈 통합·감사 대응 | 규제 산업, 기존 자산이 있는 대기업 |
이 표를 그대로 결론으로 쓰지 말 것. 도구의 기능과 가격 정책은 자주 바뀌고, 여기 적힌 성향은 방향을 잡기 위한 것이다. 실제 선정에서는 반드시 현재 시점의 공식 자료와 직접 시험이 필요하다.
갈아타야 하는가 — 대개는 아니다
여기서 방향을 한 번 틀자. 실무에서 훨씬 자주 나오는 질문은 "무엇을 고를까"가 아니라 "지금 쓰는 걸 바꿔야 하나" 다. 그리고 대부분의 경우 답은 "아니오"다.
도구를 바꿔서 해결되는 문제와 아닌 문제를 가르는 것이 먼저다.
| 증상 | 진짜 원인 | 도구 교체로 해결되나 |
|---|---|---|
| 케이스가 3,000개인데 아무도 다 못 돈다 | 케이스 설계·정리 문제 | 아니오 |
| 케이스가 최신 상태가 아니다 | 유지보수 프로세스 부재 | 아니오 |
| 자동화 결과가 따로 논다 | 연동을 안 했을 뿐 | 대체로 아니오(연동부터) |
| 결과를 보고할 때마다 수작업 | 리포트 설정 미숙 | 대체로 아니오 |
| 사용자당 비용이 감당 안 된다 | 라이선스 모델 불일치 | 예 |
| 망 분리 규정을 못 맞춘다 | 배포 형태 불일치 | 예 |
| API가 없어 CI 연동이 불가능 | 도구의 구조적 한계 | 예 |
윗줄 네 개가 도구를 바꿔도 그대로 따라오는 문제 다. 새 도구에 그대로 옮겨 심으면 6개월 뒤 같은 상태가 된다. 실제로 흔히 벌어지는 일이고, 그때는 "도구가 또 문제"라는 결론이 나온다.
판단 기준: 지금 도구의 구조적 한계 때문에 막히는 것이 있는가? 없다면 문제는 도구가 아니라 운영에 있다.
이사 비용 — 무엇이 옮겨지고 무엇이 사라지는가
교체를 결정했다면, 실제로 무엇을 잃는지 알고 시작해야 한다.
| 자산 | 이전 난이도 | 비고 |
|---|---|---|
| 테스트 케이스(본문) | 쉬움 | CSV·API로 대체로 옮겨진다 |
| 섹션·폴더 구조 | 중간 | 계층 표현 방식이 달라 손질이 필요 |
| 커스텀 필드 | 중간 | 필드 유형이 1:1로 대응되지 않는다 |
| 요구사항·결함 링크 | 어려움 | 외부 도구 연동 방식이 도구마다 다르다 |
| 과거 실행 이력 | 가장 어려움 | 사실상 옮겨지지 않는다고 보는 편이 안전하다 |
| 첨부파일 | 중간 | 용량·API 제한에 걸리는 경우가 많다 |
| 리포트·대시보드 설정 | 어려움 | 개념이 달라 재작성이 대부분 |
과거 실행 이력이 핵심이다. 모듈 7 레슨 1에서 배운 대로, 테스트 관리 도구를 쓰는 이유의 절반이 "같은 케이스가 회차별로 어땠는가"인데, 그 이력이 이사에서 가장 먼저 사라진다.
그래서 현실적인 전략은 둘 중 하나다.
- 동결 후 이전 — 기존 도구를 읽기 전용으로 남겨두고 새 도구에서 새로 시작한다. 과거 이력은 조회용으로만 유지한다. 가장 흔하고 안전한 방식이다.
- 핵심만 이전 — 최근 1~2개 릴리즈의 이력만 요약 형태로 옮기고 나머지는 버린다.
전량 이전을 시도하다 몇 달을 쓰고 결국 포기하는 사례가 많다. 이력은 옮기는 것이 아니라 남겨두는 것 이라고 생각하는 편이 낫다.
선정 절차 — 데모가 아니라 PoC로
영업 데모는 항상 잘 돌아간다. 우리 데이터로 우리 시나리오를 돌려봐야 안다. 2주 안에 끝나는 PoC 설계는 이렇다.
1주차 — 준비
· 실제 케이스 50~100개를 후보 도구에 이관해본다
(이 과정 자체가 이관 난이도 측정이다)
· 실제 사용자 계정 구조를 만든다(QA·개발·PO·읽기전용)
2주차 — 세 가지 시나리오를 끝까지 돌린다
① 회차 실행: 런 생성 → 결과 기록 → 리포트 출력
② 자동화 연동: CI에서 결과 업로드 → 화면에서 확인
③ 추적: 요구사항 하나를 골라 케이스·결과·결함까지 따라가기
판정 — 미리 정한 기준으로만 평가한다마지막 줄이 중요하다. 평가 기준을 미리 문서로 정하지 않으면, 화면이 예쁜 도구가 이긴다. 모듈 4에서 배운 대로 판정 기준은 실행 전에 정한다.
평가표는 이런 형태가 좋다.
| 항목 | 가중치 | 도구 A | 도구 B | 근거 |
|---|---|---|---|---|
| 다섯 축 중 필수 조건 충족 | 통과/탈락 | 못 맞추면 탈락 | ||
| 회차 실행 흐름의 손 편함 | 3 | 실제로 20회차 돌려본 느낌 | ||
| 자동화 연동 소요 시간 | 3 | 첫 결과 업로드까지 몇 시간 | ||
| 추적 리포트 | 2 | 요구사항 커버리지가 나오는가 | ||
| 총 소유 비용(3년) | 3 | 읽기 전용 사용자 포함 | ||
| 이관 난이도 | 2 | 1주차에서 실측 |
총 소유 비용을 3년으로 잡는 이유 는 도구 교체 주기가 대체로 그 정도이기 때문이다. 1년 가격만 보면 초기 할인에 속기 쉽다.
도입 실패의 전형적 경로
도구를 잘 골라도 실패한다. 자주 보이는 경로 셋이다.
1) 관리자만 쓰는 도구가 된다. QA 리드만 케이스를 만들고 나머지는 스프레드시트로 돌아간다. 원인은 대개 초기 구조가 너무 복잡 하거나 계정이 부족 해서다.
2) 케이스는 쌓이는데 실행 기록이 없다. 도입 초기에 케이스 마이그레이션에 힘을 다 쓰고, 정작 실행 습관을 못 만든 경우다. 케이스 100개로 시작해 실행을 돌리는 편이, 3,000개를 옮겨놓고 아무도 안 도는 것보다 낫다.
3) 자동화 결과가 끝내 안 붙는다. "나중에 연동하자"가 영원히 나중이 된다. 도입 시점에 CI 연동을 첫 스프린트 안에 끝내야 한다. 그 뒤로는 우선순위에서 계속 밀린다.
실무에서 왜 필요한가
QA 경력이 쌓이면 "우리 팀 도구 좀 정해주세요"라는 요청을 받게 된다. 그때 필요한 것은 도구 지식이 아니라 조건을 질문으로 바꾸는 능력 이다. 다섯 축을 순서대로 물어보면 대부분의 경우 후보가 두세 개로 좁혀지고, 그 뒤는 PoC로 결정된다.
더 자주 쓰이는 것은 교체를 말리는 능력 이다. "케이스가 관리가 안 되니 도구를 바꾸자"는 제안에, 그 문제가 도구 때문인지 운영 때문인지 가려서 말할 수 있어야 한다. 교체는 몇 달의 비용과 이력 손실을 수반하는 결정이고, 원인이 운영에 있다면 그 비용을 치르고도 같은 자리에 선다.
그리고 이 사고 틀은 테스트 관리 도구에만 쓰이지 않는다. 모듈 11에서 배운 자동화 도구 선정, 모듈 21의 성능 도구, 모듈 22 전체가 같은 구조다 — 조건 → 필수 탈락 기준 → 실제 시나리오 검증 → 미리 정한 기준으로 판정.