배경
GitHub Issue를 기반으로 개발 및 QA 진행 상태를 관리했습니다. 개발자가 이슈에 ‘Dev Test Done’ 라벨을 추가하면 해당 이슈는 자동으로 ‘In QA’ 상태로 전환되는 구조였습니다.
따라서 ‘In QA’는 개발자의 테스트가 완료되었다는 의미일 뿐, 수정사항이 실제 QA 환경에 배포되었다는 것을 의미하지 않았습니다.
QA 환경의 배포 시점에 따라 일부 이슈만 반영되기도 했기 때문에, ‘In QA’ 상태만으로는 해당 이슈의 검증 가능 여부를 판단하기 어려웠습니다.
실측을 통한 문제 확인
이슈 기록과 실제 QA 환경의 차이를 확인하기 위해 조사 당시 ‘In QA’ 상태의 이슈 19건을 확인했습니다.
| 확인 항목 | 결과 |
|---|---|
| In QA 상태 이슈 | 19건 |
| 기록과 실제 QA 환경 상태가 다른 이슈 | 11건 |
| 배포일이 있지만 QA 환경에 반영되지 않은 이슈 | 7건 |
전체 19건 중 11건, 약 58%에서 이슈에 기록된 내용과 실제 QA 환경의 반영 상태가 일치하지 않았습니다.
특히 7건은 배포일이 기록되어 있었지만, 실제 QA 환경에서는 수정사항을 확인할 수 없었습니다. 따라서 ‘In QA’ 상태뿐 아니라 기록된 배포일만으로도 실제 검증 가능 여부를 신뢰하기 어려웠습니다.
기존 확인 방식
QA 담당자는 검증을 시작하기 전에 다음 과정을 수기로 진행해야 했습니다.
- In QA 상태인 이슈 확인
- 이슈와 연결된 브랜치 및 수정사항 확인
- QA 환경에 적용된 GitHub 브랜치 확인
- 해당 수정사항이 QA 배포 대상에 포함되었는지 비교
- 검증 가능한 이슈와 아직 배포되지 않은 이슈 구분
QA 환경 배포가 진행될 때마다 실제 반영된 이슈가 달라졌기 때문에, 같은 확인 절차를 반복해야 했습니다.
수동 관리 방식의 한계
기록과 실제 QA 환경의 불일치를 줄이기 위해, 초기에는 개발자가 QA 환경 배포 여부를 GitHub 이슈에 수동으로 기록·관리하도록 요청하는 방식으로 대응했습니다.
하지만 이 방식에도 다음과 같은 한계가 있었습니다.
- 개발자가 배포할 때마다 관련 이슈를 직접 확인하고 관리해야 함
- 여러 이슈가 한 번에 배포되면 반복 작업이 증가함
- 수작업 특성상 기록 누락이나 오입력 가능성이 있음
- 기록이 정확하게 유지되기 위해 지속적인 관리가 필요함
- QA도 기록의 정확성을 확인하기 위해 브랜치를 다시 비교해야 함
개발자의 수동 기록만으로는 실제 반영 상태와의 불일치를 완전히 방지하기 어려웠으며, 개발자와 QA 양쪽에 반복적인 확인 업무가 발생하고 있었습니다.
개선 목표
이슈에 작성된 상태나 배포일에 의존하지 않고, GitHub의 실제 반영 정보를 기준으로 현재 QA 환경에서 검증 가능한 이슈를 확인하고자 했습니다.
현재 ‘In QA’ 상태인 이슈 중 실제 QA 환경에서 검증할 수 있는 이슈는 무엇인가?
이를 통해 개발자가 배포 정보를 반복적으로 기록·전달하는 공수와 QA가 이슈별 브랜치를 수기로 비교하는 공수를 함께 줄이고자 했습니다.
자동화 도구 개발
기존에 수기로 진행하던 GitHub 브랜치 확인 절차를 자동화하는 도구를 개발했습니다.
issue branch ↔ qa branch
팀원이 같은 요청과 기준으로 QA 환경 배포 여부를 확인
도구를 통해 다음 정보를 확인할 수 있도록 구성했습니다.
- In QA 상태인 이슈 조회
- 이슈와 관련된 브랜치 및 수정사항 확인
- QA 환경에 적용된 브랜치 정보 확인
- 이슈의 수정사항과 QA 환경 반영 내역 비교
- 현재 검증 가능한 이슈와 미배포 이슈 구분
- 기록과 실제 반영 상태가 다른 이슈 식별
이슈의 상태나 기록된 배포일을 그대로 신뢰하는 대신, GitHub의 실제 반영 정보를 기준으로 QA 가능 여부를 판단하도록 했습니다.
이를 통해 개발자가 매번 배포 정보를 수동으로 기록·전달하는 부담을 줄이고, QA 담당자도 여러 이슈와 브랜치를 개별적으로 비교하지 않아도 검증 대상을 확인할 수 있도록 개선했습니다.
팀 내 활용을 위한 스킬 등록
자동화 도구를 개인적으로 사용하는 데 그치지 않고, 팀원들이 쉽게 활용할 수 있도록 스킬로 등록했습니다.
팀원은 GitHub의 브랜치 구조나 도구의 내부 동작 방식을 자세히 알지 못해도, 정해진 요청을 통해 현재 QA 환경에서 검증 가능한 이슈를 확인할 수 있습니다.
스킬 등록을 통해 다음과 같은 활용이 가능해졌습니다.
- 별도의 실행 방법을 학습하지 않고 자동화 기능 사용
- 필요한 시점에 QA 환경 반영 여부 확인
- 팀원 간 동일한 기준과 절차로 검증 대상 판단
- 신규 팀원도 기존 확인 절차를 쉽게 활용
- 특정 담당자에게 의존하지 않는 확인 과정 구축
개선 전후
| 구분 | 개선 전 | 개선 후 |
|---|---|---|
| 판단 기준 | In QA 상태와 기록된 배포일 | GitHub의 실제 반영 정보 |
| 개발자 업무 | QA 환경 배포 여부를 수동으로 기록·관리 | 반복적인 기록 및 전달 부담 감소 |
| QA 업무 | 이슈와 브랜치를 수기로 비교 | 자동화 결과로 검증 대상 확인 |
| 미배포 이슈 확인 | 담당자가 이슈별로 판단 | 검증 가능·미배포 이슈 자동 구분 |
| 정확성 | 담당자의 기록 여부에 의존 | 실제 브랜치 반영 정보를 기준으로 판단 |
| 팀 내 사용 | 담당자별 확인 방법에 의존 | 등록된 스킬을 통해 동일한 방식으로 확인 |
기여 내용
- In QA 상태가 실제 QA 환경 배포 여부와 무관한 프로세스 문제 발견
- In QA 이슈 19건을 조사해 11건의 기록·실제 상태 불일치 확인
- 배포일이 있지만 QA 환경에 반영되지 않은 이슈 7건 확인
- 개발자가 배포 정보를 수동으로 관리하는 대응 방식의 한계 파악
- GitHub의 실제 정보를 기준으로 QA 환경 반영 여부를 확인하는 도구 개발
- 개발자의 반복적인 기록·전달 업무 감소
- QA의 이슈별 브랜치 확인 및 검증 대상 분류 업무 자동화
- 팀원들이 동일한 방식으로 사용할 수 있도록 자동화 도구를 스킬로 등록
경험의 의미
QA 과정에서 발생한 불편함을 개인적인 반복 업무로만 판단하지 않고, 실제 이슈를 조사해 문제의 규모를 수치로 확인했습니다.
또한 개발자에게 정확한 기록을 계속 요청하는 방식에 의존하지 않고, 반복적인 관리 업무 자체를 자동화할 수 있는 방법을 고민했습니다.
그 결과 개발자의 배포 정보 관리 부담과 QA의 브랜치 확인 업무를 함께 줄였으며, 자동화 도구를 팀 공용 스킬로 등록해 개인의 업무 개선을 팀 전체가 재사용할 수 있는 방식으로 확장했습니다.