Culture

파트너센터 검증 후기 : 파트너를 위한 품질 높이기

Liz여기어때

2025년 2월 11일

원문에서 보기 ↗

안녕하세요, 여기어때컴퍼니 QA팀 리즈입니다.

이번 글에서는 최근 참여했던 파트너센터 개선 과제의 검증 과정에 대해 소개하고자 합니다.

1. 시작하기 전에,

파트너센터와 여기어때 서비스의 특징에 대해 간략히 설명해 드리겠습니다.

1–1. 파트너센터란?

파트너가 관리하는 숙소의 상품을 고객에게 소개하고 판매할 수 있는 서비스 입니다. 현재 파트너센터는 다음과 같은 숙소 유형의 파트너를 대상으로 운영되고 있으며, 그중에서도 펜션을 운영하는 파트너의 이용률이 가장 높습니다.

호텔/리조트
펜션/캠핑
홈&빌라

2024년 8월, 파트너센터의 사용성이 한 차례 개선되어 파트너들이 더욱 편리하게 이용할 수 있게 되었지만, 판매 전략을 수립할 때 참고할 수 있는 데이터 지표가 추가되면 좋겠다는 백로그가 남아 있는 상황이었습니다. 이에 따라 파트너들이 효과적으로 판매 전략을 세울 수 있도록 돕기 위한 파트너센터 개선 프로젝트가 진행되었으며, 이는 제가 입사 후 처음으로 맡게 된 과제입니다.

1–2. 여기어때의 고객 분류

여기어때는 여행 상품만 제공하는 것이 아니라, 여러분이 여가를 온전히 즐길 수 있도록 숙박, 항공, 렌터카, 액티비티 등 다양한 상품과 서비스를 한 곳에서 제공하는 원스톱(One-stop) 여행 플랫폼의 역할을 수행하고 있습니다. 이러한 플랫폼의 특성상 저희의 핵심 고객은 크게 두 부류로 나뉩니다.

다양한 상품과 서비스를 이용하는 ‘사용자'
자신들의 상품과 서비스를 제공하는 ‘파트너'

여기어때의 핵심 고객

사용자와 파트너, 단순히 ‘소비자’와 ‘공급자’라는 차이만 있을까요? 각 고객의 니즈를 분석하면서 두 고객의 차이점을 더욱 깊이 이해할 수 있었습니다.

1–3. 여기어때 APP과 파트너센터를 검증할 때, 활용한 소프트웨어 품질 모델의 차이점

ISO/IEC 25010에서는 Product Quality를 2-level(주특성과 부특성)로 구분하여 정의하고 있습니다. 1레벨의 주특성은 크게 8개로 나뉘며, 각 주특성에 아래 31개의 부특성을 정의하고 있습니다.

그 중 사용성(Usability)을 아래와 같은 하위 특성으로 세분화됩니다.

- 인식성(Appropriateness Recognizability): 사용자가 시스템의 기능을 이해하고,
                                         올바르게 사용할 수 있는가.
- 학습성(Learnability): 사용자가 시스템을 얼마나 쉽게 학습할 수 있는가.
- 운영성(Operability): 사용자가 시스템을 얼마나 쉽게 조작할 수 있는가.
- 사용자 인터페이스 미학(User Interface Aesthetics): 사용자 인터페이스가 얼마나 매력적이고,
                                               편안한가.
- 사용자 오류 보호(User Error Protection): 시스템이 사용자 오류를 얼마나 잘 예방하고,
                                       오류 발생 시 얼마나 쉽게 복구할 수 있는가.
- 접근성(Accessibility): 시스템이 장애가 있는 사용자를 포함하여 누구나 사용할 수 있는가.

여행 관련 상품/서비스 구매를 위해 일반 사용자들이 사용하는 여기어때 APP은 사용성에 초점을 두고, 검증을 진행한다면,

중요 품질 특성: 사용성(Usability) 중심
- 학습성(Learnability): 초보 사용자라도 직관적으로 앱을 사용할 수 있어야 함.
- 운영성(Operability): 쉽고 빠르게 예약, 결제 등 주요 작업을 수행할 수 있어야 함.
- 접근성(Accessibility): 다양한 사용자 환경(모바일 기기, 화면 크기)에 최적화된 경험 제공.

판매한 상품과 서비스의 판매 결과를 확인하기 위해 파트너가 사용하는 파트너센터 APP은 정확성에 초점을 맞춰 검증을 진행하기로 했습니다.

중요 품질 특성: 정확성(Accuracy) 중심
- 정확성(Accuracy): 판매 데이터와 고객 예약 정보가 오차 없이 제공되어야 함.
- 사용자 오류 보호(User Error Protection): 입력 오류나 데이터 관리 오류를 최소화해야 함.
- 운영성(Operability): 직관적이지 않더라도 정확한 정보 확인이 가능한 구조 필요.

그럼 어떻게 이번 파트너센터 개선 과제에서 데이터 정합성에 집중하여 검증했는지 그 과정을 소개해 드리겠습니다.

2. 파트너센터를 검증 과정

2–1. 기획서 분석부터 꼼꼼하게,Test Case 리뷰까지 확실하게

이전에는 담당하는 숙소를 관리하는데 필요한 기본적인 데이터만 알 수 있었다면 이번에는 시장 상황을 확인할 수 있는 데이터가 추가 제공되기 때문에 Test Case 작성 단계부터 데이터 정합성 검증을 고려하여 준비했습니다.

사전에 담당 개발팀으로부터 기존 기능의 일부 소스 코드가 변경되었다는 내용을 전달받아, 기존 기능까지 검증할 수 있도록 Test Case를 확대하였고, 회귀 테스트(Regression Testing) 기법을 활용하여 기존 기능이 정상적으로 동작하고 데이터가 올바르게 수집되는 것을 확인하였습니다.

Regression Test(회귀 테스트)란?
테스트 중 발견된 결함의 수정으로 인해 다른 모듈, 기능의 문제가 없는지,
코드 수정으로 인한 새로운 결함이 없는지 확인하는 테스트입니다.

계산식 시트를 추가한 Test Case 예시

기능 검증뿐만 아니라, 정확한 데이터 정합성 검증을 위해 Test Case마다 계산식을 별도로 표시하여 가독성을 높였고, Test Case 리뷰 시간에 이를 공유하여 QA 엔지니어들이 효율적으로 검증할 수 있도록 했습니다.

Test Case 리뷰의 중요성
- 담당 QA 엔지니어가 여러 명인 경우, 각자 기획서 분석 후,
  Test Case를 작성했기 때문에 서로 이해한 내용이 일치하는지 확인할 수 있었습니다.
- QA 엔지니어들끼리 상호 테스트 방향에 대해서 공유할 수 있었습니다.
- 담당 PO(기획자)와 개발자들도 기획에서 의도한 대로 테스트 준비가 되었는지 확인할 수 있고,
  개발하면서 고려하지 못한 부분은 없었는지 크로스 체크할 수 있었습니다.
- 운영 환경과 검증 환경이 다른 경우, Test Data 생성 및 검증 방법에 대해 사전에 논의할 수 있었습니다.

특히, 이번에는 시장 상황을 확인할 수 있는 데이터 검증이 매우 중요한 부분이었는데, Test Data를 확보하기 위해, 개발팀에 요청드렸고 아래와 같이 추가 단계를 준비해주셔서 충분한 Test Data를 가지고 검증할 수 있었습니다.

운영 환경에서 검증에 필요한 Test Data 생성 → 매일 배치 작업을 통해 스테이지 환경으로 데이터 적재

→ 적재된 데이터 기준으로 ‘신규 페이지’ 검증 완료 👍🏻

2–2. 화면에 표기되는 값과 수기로 계산한 값이 다른데..! 어떻게 확인하지???

검증이 70% 정도 진행되었을 무렵, 예약 통계 페이지의 데이터 정합성을 확인하던 때였습니다. 정의된 리드타임 계산식에 따라 수기로 계산했는데 화면에 표기되는 값과 차이가 나는 것을 발견했습니다.

리드타임이란?
고객이 숙박을 예약한 날짜부터 실제 입실(체크인)하는 날짜까지의 기간을 의미하며,
담당하는 숙소를 고객이 평균적으로 며칠 전에 예약하는지 알 수 있기 때문에 프로모션 계획을 수립하는데 
중요한 지표로 활용합니다.
ex. 예약한 날짜: 2025년 3월 1일, 체크인 날짜: 2024년 4월 1일, 리드타임: 31일

화면에 노출된 리드타임 값 : 29.4%
수기로 계산한 리드타입 값 : 29.2857…% (=(18.1–14)/14*100)

소수점 둘째 자리에서 반올림하면 0.1% 차이가 나고,

소수점 버림 처리하면 0.2%가 차이 나고,

“왜 화면에 노출되는 값과 수기로 계산한 값이 다르지??”

“다른 값은 다 맞는데 리드타임 값만 다르다고???”

혼란스러웠던 것도 잠시, ‘API를 한 번 확인해보자’는 생각으로 Postman을 이용하여 값을 확인해 봤습니다.

Postman에서 조회한 값으로 계산해보니 다행히 화면과 일치하는 리드타임 값을 확인할 수 있었습니다 !

담당 PO(기획자), 개발자에게 확인한 결과, 개발 당시 구현된 방식이 오히려 파트너에게 혼란을 줄 우려가 있어 리드타임 증감값(단위: 일)과 증감률(단위: %)의 소수점 처리 방식에 대한 논의를 한 적이 있었고, 이를 바탕으로 아래와 같은 구현 방식을 적용한 상태라는 답변을 받았습니다.

구현 방식
- 증감률: 로우데이터로 계산
- 증감값: 소수점 처리(소수점 두번째 자리 반올림)한 요약 정보 값으로 계산

Postman을 활용해 구현 방식이 다른 경우에도 데이터를 정상적으로 테스트할 수 있었습니다.

Postman은 API 개발, 테스트, 디버깅 등 다양한 용도로 유용하게 활용됩니다. QA 업무에서는 앞에서 소개해드린 API 기능 검증 혹은 자동화 테스트, 부하 테스트 등으로 다양하게 활용합니다. Postman 기능은 추후 다른 과제에서 또 활용하게 되면, 사례로 소개해드릴 수 있도록 하겠습니다.

직군별 Postman 사용 예시
- 프론트엔드 개발자: 화면 개발 전 백엔드에 요청을 보내 어떤 형식으로 데이터를 주고 받는 등 활용
- 백엔드 개발자: 화면이 구축되어 있지 않아도 개발한 API를 바로 테스트하는 등 활용
- 기획자: API 명세서 검토, 기능 검토, 개발자와의 협업 등 활용
- QA: API 기능 검증, 자동화 테스트, 부하 테스트, 버그 리포트 작성 등 활용

2–3. 특가 등록 페이지에서 스와이프가 동작 안한다고? 특정 기기에서만 재현되는 거야, 아니면 모든 기기에서 재현되는 거야? 어떻게 확인하지???

파트너센터 APP을 검증하던 중, 특가 등록 페이지에서 스와이프 동작이 안되는 현상이 있었습니다. QA팀에서 보유한 기기에서는 문제를 발견한 기기 외에는 재현되는 기기가 없던 상황이었는데 그렇다고 ‘특정 기기만 그러니까 넘어가자!’라고 결정하기엔 확인한 기기 수가 부족한 상황이었습니다. 그래서 브라우저 스택에서 동일한 현상을 확인해보고, 재현되지 않으면 Known Issue로 정리하는 방향으로 의견을 모았습니다.

브라우저스택 - APP Live 화면 예시

안드로이드는 브라우저 스택에서 확인 필요한 버전 앱의 apk 파일을 업로드하면 첨부한 화면처럼
다양한 기기에서 테스트를 할 수 있고, iOS는 Testflight를 이용하여 앱 설치 후, 확인할 수 있습니다.

브라우저 스택 - 파트너센터 APP 실행 화면 예시

파트너센터 APP의 주 사용자가 중장년층이다 보니, 사전예약한 30~40대 남성이 많이 사용(약 53%) 중인 Galaxy Z Fold 5로 확인해 보았는데 브라우저 스택에서는 스와이프 동작을 재현해보기 어려운 상황이라 Back Key 및 H/W Back Key 동작 확인하는 것으로 대체했고, 정상 동작해서 Issue-raising된 이슈는 Known Issue로 넘겼습니다.

혹시 브라우저 스택에 대해 더 궁금하시다면, 저희 기술블로그에 브라우저 스택 관련 글이 있으니 한 번 참고해 보세요.

3. 마무리하며,

이번 개선 과제를 통해 다음과 같이 개선되어 파트너분들이 적절한 판매 전략을 세울 수 있도록 돕고 있습니다.

① 파트너가 시장 데이터를 확인하고, 운영하는 숙소의 판매 전략이 적절한지 판단하여 이를 최적화할 수 있다.

② 확인한 지표를 바탕으로 쉽게 특가를 등록/수정할 수 있도록 특가 등록 페이지 개선했다.

지금까지 여기어때의 주요 고객 중 하나인 파트너들이 활용하는 파트너센터 검증을 진행한 후기를 마치겠습니다.

여기어때는 여기어때 서비스만큼 파트너센터 서비스 역시 매우 중요하게 여기며, 파트너 분들의 입장에서 고민하고 개선할 방법을 꾸준히 모색하고 있습니다. 특히, 생생한 현장의 목소리를 바탕으로 실질적인 도움을 드릴 수 있는 기능과 사용성을 강화하기 위해 노력하고 있답니다.

앞으로도 파트너 분들이 더 편리하고 효율적으로 활용하실 수 있도록 새로운 기능과 개선 사항을 지속적으로 제공할 예정이니, 다음에는 어떻게 발전하여 파트너분들을 찾아갈지 많 (은 기대와 ).관 (심 ). 부 (탁드립니다).

읽어주셔서 감사합니다.