여기어때 App 업데이트 QA 프로세스 가이드

2026년 2월 2일

안녕하세요! 많은 분들의 즐거운 여행을 책임지는 여기어때컴퍼니 자동화QA팀 로미입니다.

저희 App이 어떤 프로세스를 통해 지금의 품질을 유지하며 스토어에 배포되는지 궁금하지 않으신가요? 저희 팀은 작은 기능 하나도 놓치지 않고 최고의 서비스를 제공하기 위해 노력하고 있습니다.

저는 여기어때컴퍼니에 합류하기 전, 명확한 성능 기준표를 기반으로 하는 하드웨어 중심의 정량적 검증을 주로 담당했었습니다. 그래서 스프린트 배포 주기와 수많은 변수(기기, OS, 사용자 시나리오)를 고려하여 검증해야 하는 App 품질 검증은 저에게 큰 도전이기도 하였습니다.

입사 후 적응기를 거치면서 새롭게 배우고 익힌 업무 용어와 개념들이 많았기에, 이번 글에서는 저의 적응 과정에서 체득한 경험과 함께 저희 파트의 업무 프로세스를 소개하고자 합니다.

저희 파트는 2주 단위의 빠른 배포 주기를 안정적으로 유지하기 위해 이와 같은 업무 프로세스를 따르고 있습니다.

기획 공유

테크 리뷰 (Tech Review)

스프린트 시작 전, 기획자, 디자이너, 개발자, QA가 모여 1 Pager, Detailed AC와 Figma 디자인 가이드를 공유하고 논의하며 전체적인 방향성을 맞춤
이 논의를 통해 기획서만으로는 체크하기 어려운 부분을 미리 확인하고, 잠재적인 문제가 될 부분을 사전에 파악하여 리스크를 최소화
일정 산정: 스프린트에 배포될 프로젝트 범위와 공수 상황을 종합적으로 고려하며, 이를 바탕으로 개발 및 QA 검증에 필요한 일정을 산정하고 관리

1 Pager와 Detailed AC

업무를 처음 시작했을 때 저에게 가장 생소했던 개념이 바로 1 Pager와 Detailed AC였습니다.

간단히 설명하자면, 1 Pager는 기획의 목적과 핵심 목표를 한 장에 요약한 문서입니다. 기획이 시작된 배경과 달성하고자 하는 비즈니스 목표를 모든 팀원이 빠르게 이해할 수 있도록 돕는 역할을 합니다.

반면, Detailed AC는 개발해야 할 기능의 세부 동작을 정의한 문서입니다. 개발이 완료된 후 이 기능이 제대로 작동하는가?를 판단하는 기준으로, 저희 QA 엔지니어가 테스트 케이스를 설계하는 데 가장 핵심적인 근거가 되는 자료입니다. 즉, 숲(1 Pager)을 보고 나무(Detailed AC)를 자세히 살펴보는 과정인 셈입니다.

기획 분석 및 설계

기획서 분석

공유 받은 기획서(1 Pager, Detailed AC)와 Figma 디자인 가이드를 바탕으로 테스트 케이스를 설계
파트원들과의 논의를 통해 사용자 관점에서 발생할 수 있는 잠재적 리스크나 모호한 부분을 사전에 파악하고, 심도 있게 분석하여 검증 방향을 설정

테스트 케이스 설계

분석된 기획서를 기반으로 TestRail을 활용하여 테스트 케이스를 설계하고, 기획서에 명시된 내용 외에 발생 가능한 예외 케이스를 포함하여 케이스를 고도화

TestRail

이전까지는 구글 스프레드시트에서 테스트 케이스를 작성하고 관리하는 것이 익숙했습니다. 그래서 여기어때에 와서 TestRail을 처음 사용했을 때는 다소 생소하고 복잡하게 느껴졌습니다.

하지만 현재는 TestRail이 단순히 테스트 케이스를 기록하는 것을 넘어, 테스트 케이스의 생성부터 실행 결과, 그리고 Jira와의 연동까지 검증의 전 과정을 체계적으로 관리해 준다는 것을 알게 되었습니다. 덕분에 테스트 실행과 품질 보고가 훨씬 효율적으로 정리되었고, 테스트 진행 상황을 한눈에 파악할 수 있어 효율성을 극대화할 수 있었습니다.

테스트 케이스 리뷰

내부 리뷰: 설계된 테스트 케이스에 대해 파트 내부 리뷰를 진행하여 누락된 시나리오나 비효율적인 검증 단계를 사전에 점검하고 완성도를 높임
관계자 리뷰: 최종적으로 설계된 테스트 케이스가 기획 의도를 모두 커버하는지, 검증에 필요한 데이터는 무엇인지 관계자(기획/개발/디자인/QA)와 함께 검토. 이 과정을 통해 잠재적 리스크를 최종 분석하고 테스트 케이스를 확정

App 품질 검증 경험이 부족했고, 이처럼 다양한 직무분들과 협업해 본 경험이 적었기 때문에 초기에는 예외 케이스를 사전에 예상하여 설계하는 것과 관계자분들께 테스트 케이스 리뷰를 요청하는 과정 자체가 큰 어려움이었습니다.

하지만, 이 프로세스를 진행하며 단축되는 검증 시간과 배포 후 발견되는 잔여 이슈가 적어지는 것을 체감했습니다. 이로써 테스트 케이스 고도화 및 리뷰 과정이야말로 안정적인 배포를 위한 핵심 단계임을 깨닫게 되었습니다.

검증 프로세스

설계가 완료된 후, 아래와 같은 3단계의 검증 프로세스를 거치며 App의 품질을 확보합니다. 모든 검증 단계에서는 작성된 테스트 케이스 외에도 예상치 못한 문제점을 발견하기 위해 탐색적 테스트(리스크 기반의 체계적 테스트)와 Ad-Hoc 테스트(즉흥적 테스트)를 병행하는 데 집중하고 있습니다.

단위 검증

개발이 완료된 개별 기능에 대해 테스트 케이스 설계 내용을 기반으로 집중적인 검증을 진행
A/B 테스트 기능의 경우, A 버전과 B 버전이 개별적으로 구현되었는지, 그리고 사용자 그룹에 따라 올바르게 분기되는지를 검증

통합 검증

모든 기능의 단위 검증이 끝나면, 이를 하나로 합친 통합 빌드 버전으로 기능 간의 상호작용 및 전체적인 사용자 흐름을 검증

릴리즈 검증

실제 스토어에 배포될 릴리즈 빌드를 통해 변경된 기능과 주요 기능들을 최종적으로 검증

A/B 테스트

이전 회사에서 A/B 테스트라는 용어는 A사 제품과 B사 제품의 성능을 비교하는 테스트이었기에 타사 App과 비교하는 건가? 라는 혼란이 있었습니다.

하지만 여기어때에서 A/B 테스트는 사용자 경험 개선이나 비즈니스 목표 달성을 위해 두 가지 이상의 버전(A, B 등)을 특정 사용자 그룹에게 나누어 제공하고, 그 성과를 비교 분석하는 실험 테스트였습니다.

이 실험 테스트를 통해 고객의 반응을 데이터로 확인하고, 가장 긍정적인 반응을 얻은 최적의 버전을 사용자에게 최종적으로 제공하게 됩니다.

심사 요청 및 점진적 배포

심사 요청

모든 단계의 검증이 완료되고 각 단계에서 지정된 테스트 품질 목표를 통과하면, 각 OS 담당자(iOS/Android)에게 스토어 심사를 요청

점진적 배포

스토어 심사가 승인되면, 곧바로 전체 사용자에게 배포하는 대신 소수의 사용자에게 먼저 업데이트를 노출하여 점진적으로 배포를 진행
이 과정을 통해 소수 사용자에게 먼저 업데이트를 노출하여 예상치 못한 치명적인 문제가 발생하지 않는지 모니터링하며, 안정성이 확보되었다고 판단되면 전체 고객에게 업데이트를 노출

결과보고 및 회고

결과보고서 예시 이미지

결과보고

배포가 완료되면, 이번 스프린트에 참여한 각 담당자들은 진행한 개별 기능 및 통합 검증 결과와 이슈를 정리하여 최종 품질 보고서를 작성
보고서에는 테스트 케이스 검증 결과, 발견된 이슈의 개수와 심각도, 그리고 이슈의 해결 여부 등을 포함하며, 이 보고서는 다음 스프린트 계획 수립의 중요한 기반 자료가 됨

회고

매 스프린트의 마지막에는 App 업데이트 파트 인원 모두가 모여 솔직한 의견을 나누는 회고를 진행
좋았던 점과 아쉬웠던 점을 투명하게 공유하며, 단순히 기능 검증을 넘어 더 효율적인 프로세스를 만들기 위해 다음 스프린트에서 개선할 액션 아이템을 구체적으로 도출

마무리하며,

지금까지 저희 App 업데이트 파트가 안정적으로 스토어에 배포하기 위한 업무 프로세스 흐름을 소개해 드렸습니다.

H/W 성능 위주의 품질 검증에서 App 사용자 경험에 맞춘 품질 검증으로 전환하는 과정에서 낯선 용어와 2주 배포 주기의 벽을 넘는 것은 저에게 큰 도전이었지만, 이 체계적인 프로세스 덕분에 짧은 시간 내에 적응할 수 있었고, 이제는 작은 기능 하나에도 ‘어떻게 하면 사용자 경험을 완벽하게 만들 수 있을까’를 고민하며 업무에 임하고 있습니다.

물론, 정형화된 업무 프로세스는 없다고 생각합니다. 각 팀의 특성에 맞는 효율적인 프로세스를 구축하고 지속적으로 개선해 나가는 것이야말로 좋은 품질의 서비스를 만드는 가장 중요한 열쇠일 것입니다. 저희 여기어때 QA팀도 현재의 프로세스에 만족하지 않고, 새로운 도전을 통해 더 효율적이고 완성도 높은 서비스를 제공할 수 있도록 늘 고민하며 성장을 멈추지 않겠습니다.