grep

QA

숫자 속에 숨은 버그를 찾아라!

Luke Lee여기어때

2024년 12월 31일

원문에서 보기 ↗

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

여러분은 ‘정산 도메인 검증’을 들어보신 적이 있으신가요? 혹시 정산 도메인 검증이 어떤 검증을 하는지 짐작이 가시나요?

저는 처음 채용공고에서 ‘정산 도메인 검증’이라는 문구를 접했을 때, ‘소프트웨어나 서비스 검증이 아니라 돈을 검증해야 하는 건가?’ 하는 의문이 들었습니다. 그 당시에는 이 직무가 단순히 금액을 검증하는 일이라고만 생각했지만, 소프트랜딩을 끝내고 지금에 와서 보니, 제 생각은 반쯤 맞고 반쯤 틀렸다는 걸 깨달았습니다.

오늘은 제가 처음 경험한 정산 도메인 검증에 대해 이야기해보려고 합니다. 이 검증이 무엇인지, 왜 중요한지, 그리고 실제로 어떻게 진행되었는지에 대한 제 경험을 공유하려고 합니다.

💰 정산 도메인 검증 이란?

판매된 상품이나 서비스에 대한 매출 및 수익이 올바르게 계산되고, 그 금액이 정확하게 파트너(판매자)나 제휴사 또는 제휴점에게 지급 되는지를 검증하는 것

정산 도메인 검증은 주로 다음을 검증합니다.

🎟️ 레저티켓 매출/정산 시스템 검증을 시작하다

여기어때컴퍼니에 합류하면서 ‘정산 도메인 검증’이라는 직무를 처음 접하게 되었고, 파트 교육을 통해 파트너에게 정확한 정산 금액을 지급할 수 있도록 정산 시스템을 검증하는 직무라는 것을 알게 되었습니다.

레저티켓 서비스는 이미 고객에게 제공되고 있었지만, 내부 R&R 변경과 통합 정산 플랫폼 개발로 인해 매출/정산 시스템과 파트너가 정산내역을 확인할 수 있는 메뉴를 추가하게되어 검증이 필요했습니다. 처음 받아본 레저티켓 매출/정산 기획서는 낯선 용어와 계산식 그리고 정책들로 가득했기에 하나하나 꼼꼼하게 읽고 관련 자료들도 찾아가면서 기획서를 분석하는데 많은 시간을 쏟았습니다.

기획서 분석과 이해를 어느 정도 진행한 후 작성되어 있는 내용들을 바탕으로 테스트케이스를 작성하고 검증을 위한 제휴점 생성과 레저티켓 상품을 생성하는 것으로 검증 준비를 마쳤습니다. 그리고 웹 기능과 웹 내에 노출되는 정산 데이터를 확인하는 검증을 위해 생성한 상품들을 예약하여 정산 데이터가 웹에 동일하게 노출되고 있는지 부터 진행하기 시작했습니다.

🔎 검증 과정 중 시행착오를 줄일 수 있는 요소가 없을까?

정산 금액 검증은 스프레드 시트에 별도의 테이블을 만들어 예약된 티켓 정보와 금액을 기획서에 작성된 계산식에 맞춰 입력하고 최종적으로 파트너에게 정산할 금액을 정산 시스템에서 계산한 금액과 일치하는지 확인하였습니다. 그리고나서 최종 정산 금액을 산정하는 과정에서 틀린 계산은 없는지 확인하는 과정으로 검증을 진행했습니다. 하지만 첫 검증이다 보니 검증하는 과정에서 반복적으로 필요한 데이터를 찾아보게 되었고, 그만큼 시간이 오래 걸렸습니다. 때로는 금액을 잘못 입력하는 상황도 있었고 이로 인해 최종 정산 결과가 시스템에서 정산한 결과와 다르기도 하였습니다. 이런 실수를 경험하면서 ‘어떻게 하면 시행착오를 줄이면서 조금이나마 검증 시간을 단축할 수 있을까?’라는 고민을 하게 되었습니다.

정산 금액 검증에서 사용하는 데이터는 예약내역에서 데이터를 가져와서 계산하기 때문에 대부분 예약 내역 조회를 통해 찾을 수 있었습니다. 예약 내역에서 구매 수량, 구매 일자, 구매 금액, 할인 금액, 쿠폰 금액 등 다양한 데이터가 노출되고 있었지만, 추가로 보이는 데이터가 더 있다면 검증 과정 중에 계산 실수나 시행착오를 줄일 수 있을 것 같았습니다. 그래서 예약과 관련된 여러 데이터와 개발팀에서 사용하는 API 목록을 함께 확인해 보았습니다. 예약 정보에서 데이터를 가져오기 때문에 레저티켓 예약내역 API를 먼저 확인해 보았고 쿠폰 정보는 예약내역에서 사용된 쿠폰 번호를 찾은 후 쿠폰 내역 조회 API를 통해 사용된 쿠폰에 대한 데이터를 확인할 수 있었습니다. API에서 추가로 찾은 데이터는 아래 두 가지였습니다.

일반적으로 예약 내역에서 정산에 필요한 데이터 확인 → 정산 항목 및 계산식 검증 → 결과 확인 순으로 검증을 진행하고 있습니다. 그렇지만 이번에는 예약 내역에서 필요한 데이터는 관련 API를 통해 확인하였고 원하는 데이터만 보기 쉽게 별도로 추출하였습니다. 그래서 할인 금액, 쿠폰 금액, 사용된 포인트 금액을 가지고 계산하는 부분은 조금 더 쉽게 정산 금액을 산출할 수 있어 검증 시간, 잘못 입력하는 실수 모두 줄일 수 있었습니다. 아래에서는 제가 이번에 진행했던 검증 방법을 소개하겠습니다.

검증에 필요한 데이터 선별 및 수집

기존에는 정산에 필요한 데이터를 보기 위해서 예약내역 조회를 진행하고 조회 내역에서 데이터를 확인하여 검증을 진행하였지만, 시행착오를 최대한 줄이기 위해 정산과 관련이 있는 API 를 사용해 보았습니다.

먼저 검증에 필요한 데이터를 선별하고 수집하기 위해 레저티켓 예약 내역 조회 API를, Python을 사용하여 호출하였습니다. 이때 API 호출 주소에는 조회하고자 하는 예약 번호를 파라미터로 입력해 주었습니다. 아래와 같이 예약 번호로 API를 호출하는 코드를 작성하여 응답 결과를 받아 왔습니다.

def ticket_order(self, order_number):
    order_response = self.get_order_response(order_number)
    order_response.raise_for_status()
    if order_response.status_code == 200:
        # API 응답을 출력
        print(json.dumps(order_response.json(), indent=4))
        # 각각의 데이터들을 저장
        order_data = order_response.json()

아래는 레저티켓 예약 내역 조회 API 호출을 통해 정리한 데이터입니다. 예약 및 티켓 데이터, 쿠폰 번호를 얻을 수 있었고, 쿠폰 내역 조회 API에서는 사용자가 예약 시 사용했던 쿠폰 정보를 받아와 보기 편하게 출력해 주었습니다.

----- 예약 데이터 -----
회원유형: BASIC
판매 금액: 47970
...
총 할인A: 11630
총 할인B: 8920
결제 금액: 36681
취소수수료: 6547
쿠폰번호: 123456789AA
----- 티켓 데이터 -----
티켓 1
  티켓 상태 : 취소
  티켓 사용일 : -
  티켓 취소일 : 2024-08-30
  할인A: 4450
  할인B: 3400
  판매 금액: 18330
티켓2
  ...

위와 같이 API 결과를 받아 정리한 데이터를 직, 간접적으로 사용할 수 있게 되었고 두 가지 데이터를 찾아냈습니다 !!

검증 과정에서 예약 번호만 입력하면 API 호출을 통해 검증에 필요한 데이터를 가져올 수 있게 되었습니다. 그리고 추가로 필요하던 데이터를 얻어올 수 있어서 예약 내역 조회 페이지를 확인하지 않고 API 호출 결과만 가지고 검증을 진행하였습니다.

계산식 및 각 항목의 데이터 입력

예약내역이나 API에서 확인한 데이터를, 검증을 위한 테이블에 작성하는 단계입니다. 입력한 데이터를 기반으로 계산식을 사용하여 검증 시 각 항목에 대한 정산 금액과 최종 정산 금액을 산출하게 됩니다.

계산식 및 항목별 데이터 입력은 다음과 같이 진행하고 있습니다.

  1. 계산식과 각 항목의 금액 검증을 위해 스프레드시트에 위와 같은 템플릿 작성
  2. 예약 내역 또는 API 호출 결과를 정리해 놓은 데이터를 각각의 필드에 금액 입력
  3. 티켓별 결제금액, 티켓별 포인트 사용 금액, 쿠폰 사용 금액, 정산 금액 등 계산식을 입력하여 금액 산출

정산 금액 검증

해당 테스트에 사용된 상품은 테스트 상품으로 상품 금액, 할인, 쿠폰, 수수료율 등이 임의로 설정된 상품입니다. 위 테이블은 검증 단계에서 입력한 정산 데이터(금액)를 기반으로 항목별 계산식을 포함하고 있으며, 판매 금액과 수수료가 정확하게 산정되었는지, 각종 할인, 쿠폰, 포인트가 올바르게 반영되었는지, 정산 주기와 정산 금액이 적절하게 처리되는지, 그리고 취소 및 환불로 인한 정산 처리가 정확히 이루어졌는지 검증하고 있습니다.

검증 결과를 확인하는 과정에서 Admin 및 파트너 웹에 표시된 정산 금액과 수기로 정산한 금액이 차이가 나는 경우, 왜 이러한 불일치가 발생했는지를 파악하기 위해 아래와 같은 단계로 검토를 진행합니다.

  1. 불일치한 항목의 기획 및 계산식 검토 기획서에 명시된 계산식과 시스템에서 실제로 적용된 계산식을 비교하여 불일치의 원인을 파악합니다. 이를 통해 수식이 잘못 적용 되었거나, 데이터 입력 과정에서 오류가 발생했는지 확인합니다.
  2. 개발 및 PO와 논의 검토 과정에서 확인된 오류나 불일치한 계산식은 개발 및 PO와 논의를 통해 원인을 명확히 하고, 명확한 이해를 위해 담당 PO가 계산식이나 기획 수정을 진행합니다.
  3. 수정된 계산식 기반으로 재검증 수정된 계산식이 적용되면, 동일한 데이터를 바탕으로 정산 금액을 다시 산출하고 Admin 및 파트너 웹의 금액과 재 비교합니다. 이를 통해 변경 사항이 올바르게 반영되었는지 확인테스트를 진행하고 리그레션 테스트 시 해당 케이스를 추가하여 진행합니다.

이번 프로젝트에서는 다양한 예약 조건의 데이터를 만들어 검증하였는데, 예약하는 티켓의 수량도 다를 수 있고 할인이나 쿠폰 등 예약 조건이 사용자마다 다를 수 있기 때문에 최대한 많은 유형의 데이터를 만들어서 확인하였습니다. 어떠한 변수와 상황에서도 정확한 정산이 이루어져야 하므로 ‘설마 이런 유형으로 예약이나 취소하는 상황이 생길까?’ 하는 유형들을 정말 많이 고민하고 고려해야 했습니다. 그리고 이 과정에서 포인트, 쿠폰, 예약 도메인에 대한 이해도가 요구되어 많은 것을 배울 수 있었던 프로젝트였습니다.

마무리,

여기어때는 숙박 외에도 사용자들에게 다양한 서비스를 제공하고 있습니다. 이를 위해 여러 파트너와 제휴하고 있으며, 파트너들에게 정확한 정산을 하기 위해서는 정산 금액은 철저하게 검증하는 과정을 수없이 반복하고 있습니다. 이 검증 과정은 단순히 금액을 맞추는 것이 아닌 파트너들과의 신뢰를 쌓아가는 매우 중요한 과정이라 생각합니다. 앞으로도 사용자와 파트너에게 신뢰할 수 있는 서비스를 제공하는 데 끊임없이 노력하겠습니다.

감사합니다.