일회성 점검이 아니라 서비스 완성도를 끌어올리는 운영 프로세스로 만든 QA
들어가며
프로젝트를 진행하면서 내가 중요하게 본 것은 “기능을 구현했다”에서 끝나지 않는 것이었다.
실제로 서비스는 구현 이후에 더 많은 문제가 드러난다. 화면 흐름이 의도와 다르게 이어지기도 하고 기능은 동작하지만 사용자가 기대한 결과와 다르게 보이기도 하며 페이지 간 데이터 표현이나 정책 반영 방식이 미묘하게 어긋나는 경우도 많다.
특히 HotSpot은 사용자 페이지와 관리자 페이지가 함께 존재하고 정책 적용·가족 구성·사용량 조회·알림 같은 기능들이 서로 연결되어 있었기 때문에 단순한 개별 기능 테스트만으로는 전체 완성도를 보장하기 어려웠다.
나는 이 지점에서 QA를 단순히 “배포 전 마지막 확인” 정도로 보면 안 된다고 생각했다. 오히려 개발과 개선을 계속 연결해주는 운영 프로세스로 다뤄야 한다고 봤다.
그래서 우리 팀은 1차, 2차, 3차 MVP 단계마다 QA Board를 운영했고 최종 통합 테스트까지 전 과정을 같은 흐름 안에서 관리했다.
테스트를 따로따로 하면 개선이 쌓이지 않는다
프로젝트 초반에는 테스트 결과가 각자 머릿속이나 채팅, 회의에서만 공유되면 충분할 것처럼 보일 수 있다. 하지만 실제로는 이런 방식이 금방 한계를 드러낸다.
- 누가 어떤 상황에서 문제를 발견했는지 흐려지고
- 기대한 동작과 실제 결과가 어떻게 달랐는지 기록이 남지 않으며
- 같은 문제가 반복 보고되거나 반대로 놓치기도 쉽고
- 수정이 끝난 뒤에도 무엇이 해결됐고 무엇이 남았는지 추적하기 어렵다
특히 MVP를 여러 차례 거치며 기능이 계속 추가되고 수정되는 프로젝트에서는 테스트도 그때그때 흩어져 있으면 개선의 이력 자체가 쌓이지 않는다. 나는 이 문제를 보면서 QA의 핵심은 단순히 오류를 찾는 것이 아니라 문제를 발견하고 우선순위를 정하고 수정하고 다시 확인하는 흐름을 구조화하는 것이라고 생각하게 됐다.
QA Board를 중심으로 테스트와 개선 흐름을 한 곳에 모았다
그래서 우리 팀은 QA Board를 별도로 운영했다.
핵심은 테스트 결과를 단순 나열하는 것이 아니라 하나의 이슈가 발견부터 해결까지 어떤 흐름을 거쳤는지 한눈에 보이도록 만드는 것이었다.
각 테스트 케이스마다 다음을 명확히 기록했다.
- 어떤 상황에서 테스트했는지
- 기대한 결과가 무엇인지
- 실제 결과가 어떻게 나왔는지
- 오류인지, 수정 요청인지, UI/UX 개선인지
- 우선순위가 어느 정도인지
- 담당자와 처리 상태가 어떻게 되는지
이렇게 정리해두니 문제를 발견하는 순간 끝나는 것이 아니라 그 이슈가 논의 사항인지, 기능 오류인지, 사용자 경험 개선 포인트인지까지 함께 분류할 수 있었다.
또한 1차, 2차, 3차 MVP와 최종 통합 테스트를 같은 체계 안에서 관리하면서 QA를 특정 시점의 이벤트가 아니라 프로젝트 전체를 따라가는 연속적인 관리 과정으로 만들 수 있었다.
Jira와 연결해 추적 가능성을 높였다
내가 특히 중요하게 본 부분은 “발견된 문제를 어떻게 끝까지 추적할 것인가”였다.
QA Board에 이슈가 등록되어 있어도 실제 개발 작업과 연결되지 않으면 결국 다시 따로 관리해야 하고 시간이 지나면 누가 어떤 방식으로 수정했는지 흐려질 수 있다. 그래서 우리는 QA 항목을 Jira 티켓과 연결해 발견된 이슈가 실제 수정 작업으로 어떻게 이어졌는지 추적 가능하게 만들었다.
이 방식의 장점은 분명했다. 첫째, QA 결과가 단순 기록으로 남지 않고 실제 개발 작업으로 바로 이어졌다. 둘째, 수정 완료 후 다시 QA Board에서 상태를 갱신하면서 해결 여부를 명확히 확인할 수 있었다. 셋째, 나중에 돌아봤을 때도 특정 문제가 어떤 티켓으로 처리되었는지 연결 관계를 쉽게 볼 수 있었다.
즉 QA와 개발이 분리된 흐름이 아니라 발견 → 수정 → 재검증이 하나의 운영 루프로 이어지도록 만든 것이다.
단순 오류 수정이 아니라 UI/UX 개선에도 활용했다
이 과정에서 의미 있었던 점은 QA Board가 단순 버그 관리 도구로만 쓰이지 않았다는 것이다.
실제 운영 단계에서 테스트를 반복하다 보면 기능이 틀린 것은 아니지만 사용자 입장에서 불편하거나 어색한 부분들이 계속 보인다. 예를 들어 정보가 표시되는 순서, 버튼 위치나 속도, 레이아웃 정렬, 용어 표현, 데이터 단위 표기처럼 치명적인 오류는 아니지만 서비스 경험에 영향을 주는 요소들이다.
우리는 이런 항목들도 QA Board 안에서 별도로 분류하고 관리했다. 그 결과 QA는 단순히 에러를 잡는 과정이 아니라 UI/UX 완성도를 반복적으로 다듬는 과정으로 확장될 수 있었다.
이 부분이 중요했던 이유는 실제 사용자 입장에서 서비스 품질은 기능의 정오뿐 아니라 이용 흐름이 얼마나 자연스러운가로도 결정되기 때문이다. QA를 통해 이 지점을 꾸준히 다듬는 것이 프로젝트의 완성도를 높이는 데 큰 역할을 했다고 느꼈다.
테스트가 흩어지지 않고 개선이 누적되기 시작했다
QA Board를 운영하면서 가장 크게 느낀 변화는 테스트가 더 이상 일회성 확인으로 끝나지 않았다는 점이다. 이전 같으면 테스트 중 발견된 문제들이 개별적으로 흩어졌을 내용들이 QA Board 안에서는 모두 같은 형식으로 기록되고 상태가 관리되었다. 덕분에 지금 어떤 문제가 열려 있는지, 어떤 문제가 이미 수정되었는지, 어떤 항목이 우선적으로 처리되어야 하는지가 훨씬 명확해졌다.
또한 MVP 단계별로 QA를 반복하면서 기능 구현 이후의 수정과 개선이 누적되는 흐름을 눈으로 확인할 수 있었다. 이건 단순히 문제가 줄었다는 의미를 넘어 프로젝트가 점점 더 안정화되고 있다는 감각을 팀 전체가 공유할 수 있게 되었다는 점에서 의미가 컸다.
특히 최종 통합 테스트 단계에서는 이전 MVP 단계에서 쌓아온 QA 이력이 있었기 때문에 단순히 새 문제를 찾는 것을 넘어 기존 문제 재발 여부까지 함께 점검할 수 있었다. 즉 QA Board는 테스트 기록이면서 동시에 안정화의 이력으로도 작동했다.
QA는 테스트 문서가 아니라 운영 체계다
이 경험을 통해 내가 가장 크게 배운 것은ㅠQA는 단순히 체크리스트를 채우는 일이 아니라는 점이었다.
좋은 QA는
- 문제를 발견하게 해주고
- 기대값과 실제값의 차이를 명확히 보여주며
- 우선순위를 정하게 만들고
- 수정 작업과 연결해주고
- 다시 검증할 수 있게 만드는
운영 체계에 가깝다.
특히 여러 단계의 MVP를 거치는 프로젝트에서는 QA를 마지막 점검으로 두는 것이 아니라 개발과 함께 계속 굴러가는 프로세스로 만들 때 훨씬 큰 효과를 낼 수 있다는 걸 느꼈다. 이 경험을 통해 서비스 완성도는 기능을 많이 만드는 것만으로 높아지지 않는다는 걸 더 분명히 배웠다.
오히려 중요한 것은 발견된 문제를 얼마나 구조적으로 관리하고 개선 사이클로 연결하느냐였다.
마무리
우리 팀은 1차, 2차, 3차 MVP와 최종 통합 테스트까지 QA Board를 일관되게 운영하면서 테스트 전 과정을 체계적으로 관리했다.
각 테스트 케이스별로 상황, 기대값, 실제값을 기록해 기능 불일치와 예외 상황을 빠르게 식별했고, Jira 티켓과 연결해 수정 과정까지 추적 가능하게 만들었다. 그 결과 단순 버그 수정뿐 아니라 UI/UX 개선까지 반복적으로 반영할 수 있었다.
이 경험을 통해 나는 QA를 단순한 점검이 아니라
서비스 완성도를 높이기 위해 문제를 발견하고, 추적하고, 개선으로 연결하는 운영 프로세스
로 바라보게 되었다.
