QA 회고

최근에 오랜 기간 개발해온 프로젝트의 1차 마감을 끝내고,
약 3주간 QA를 진행했습니다.
아직 QA는 현재진행형이지만, 이제 고지가 눈앞에 다가온 시점입니다.
그래서 이번 QA 과정을 간략하게 돌아보고자 합니다.

LAH는 그동안 서비스 최초 개발, 개선 개발, 리뉴얼 개발, 추가 개발 등
다양한 프로젝트를 진행해왔습니다.
각 프로젝트의 성격과 형식은 다르지만, 프로덕트 배포 전에는 항상 QA 과정을 거칩니다.
이 과정에서 크고 작은 시행착오를 겪으며,
우리 조직에 가장 적합한 QA 프로세스를 찾아가는 중입니다.

이번 프로젝트는 서비스를 최초로 개발하는 작업이었습니다.
‘최초’라는 단어가 주는 무게는 기본적으로도 상당한데,
특히 이번 프로젝트는 규모도 컸기 때문에
필연적으로 개발해야 할 양도 많고, QA 해야 할 작업량도 많았습니다.

과거 자사 서비스를 최초 개발했을 때를 떠올려보면,
서비스 규모가 큰 상황과 오픈을 최대한 앞당기고자 하는 두 가지 조건을 충족하기 위해
QA와 개발을 병행하는 방법을 시도한 적이 있습니다.
개발 범위를 나눠 먼저 완료된 부분에 대해서는 QA를 진행하면서
동시에 나머지 범위를 계속 개발하는 방식이었습니다.
이론적으로는 매우 효율적인 방식이었지만, 실제로는 예상치 못한 문제들이 많았습니다.

QA 중에는 병목 현상을 일으키는 버그들이 발생했고,
이 버그들이 해결되지 않으면 전체 범위에 대한 테스트가 불가능했기 때문에
개발팀은 기존 작업을 중단하고 QA 수정을 진행해야 했습니다.
또한 QA 기간과 QA 수정 기간을 분리하려 했지만,
수정으로 인한 사이드 이펙트가 발생해 긴급 수정이 필요할 때도 있었고,
결국 두 기간을 완전히 분리하는 것이 어려웠습니다.
결과적으로는 개발과 QA 수정 작업이 병렬로 진행되었고,
하나에 집중하기 어려운 환경이 되면서 우리가 기대했던 효과적인 구조는 아니라고 판단했습니다.

그래서 이번 QA는 전체 개발을 완료한 후 QA를 진행했고,
QA 기간과 QA 수정 기간을 분리했습니다.
QA 기간 동안 개발팀은 다른 개발 작업을 진행하지 않고
테스트에 병목이 되는 이슈만 가능한 빠르게 수정함으로써
전체 QA가 원활하게 진행될 수 있도록 운영했습니다.
개발팀의 신속한 대응 덕분에 예정된 기간 내에 QA를 마칠 수 있었습니다.

다만 여전히 고민은 남아 있습니다.
특히 규모가 큰 프로젝트의 경우, QA 작업량이 많고
배포 직전 마감에 맞춰 높은 강도로 작업이 진행되기 때문에 모두에게 인내심이 요구됩니다.
같은 양의 일도 새로운 내용이거나 중간에 환기할 수 있는 포인트가 있으면 덜 힘들겠지만,
QA는 결국 끝을 봐야 하는 최전방이고,
문제가 해결될 때까지 작업을 해야 하기 때문에 피로감이 더욱 가중되는 것 같습니다.
이 때문에 QA 기간에는 인내심이 정말 중요하다는 생각이 들 정도입니다.

우리에게 가장 잘 맞는 현명한(?) QA 방법론을 찾는 것은, 앞으로도 숙제일 것입니다.
다만 하나의 정답이 있다기보다는, 상황에 따라 최선의 선택을 하고
그 선택이 최고의 결과로 이어지도록 노력하는 것이 우리가 할 수 있는 일이라고 생각합니다.

---