||
글. 신영민(Gladi) / 서비스QA팀
안녕하세요. 여기어때컴퍼니 서비스QA팀 글라디입니다.
오늘은 입사 후 겪은 업무 변화에 대해 이야기해보려고 하는데요.
QA라는 직무의 틀은 같지만, 검증 대상, 즉 업무 영역이 바뀐다고 해서 검증 과정이 얼마나 달라지는지 한번 이야기해보겠습니다.
전시 QA는 ‘보이는 것’을 검증하는 일입니다. 화면이 예쁘게 나왔는지, 클릭하면 반응하는지, 사용자가 헤매지 않는지. 결과가 눈 앞에 바로 보이니까 직관적이고 재밌었습니다. 저는 지금까지 전시 영역에서 검증 업무를 주로 해왔습니다.
그런데 여기어때컴퍼니에 합류하면서 맡게 된 것은 기존과 다르게 ‘보이지 않는 것’을 검증하는 일이었습니다. 예약과 정산, 숫자와 정책으로요.
처음에는 ‘기본적인 QA 방식은 비슷하니 금방 적응하겠지’라고 생각했지만, 막상 업무를 시작하니 검증 방법부터 사고 방식까지 완전히 달라져야 한다는 걸 깨달았습니다. 이 글에서는 직접 경험한 예약·정산 QA의 차이점과, 그 과정에서 마주한 어려움을 어떻게 극복했는지 저만의 노하우를 공유하겠습니다
전시·예약·정산 QA, 무엇이 다를까?
전시(Front Display): “실시간으로, 빠르게, 보기 좋게”
2. 예약(Reservation): “미리 정하고, 흐름을 이어가게”
3. 정산(Settlement): “돈이 오가는 곳, 정확한 계산”
업무 영역이 바뀌면서 달라진 것들
전시 QA의 중심은 사용자가 실제로 마주하는 화면이었습니다. UX/UI를 해치지 않으면서 빠르고 직관적으로 보여주는 것이 테스트의 핵심이었죠. 그래서 복잡한 구성보다는 상품 가격, 혜택 정보, 버튼 상태, 문구, 필터처럼 눈에 바로 보이는 영역을 중심으로, ‘사용자가 어떻게 사용할까?’라는 관점에서 자연스럽게 접근하게 됐습니다.
반면, 예약·정산 QA는 데이터의 정합성이 중심이었습니다. 사용자에게 보이는 화면이 아니라, 금액 계산을 위한 수식이 맞는지, 배치 순서에 따라 데이터가 제대로 흘러가는지, 최종 금액이 정확하게 계산되는지를 검증하는 것이 핵심이었죠.
특히 예약·정산은 실제 돈이 움직이는 영역이기 때문에, 다양한 경우의 수를 충분히 고려하지 않으면 바로 금전적 오류로 이어질 수 있었습니다. 단 1원의 차이도 문제가 될 수 있는 영역이라, 무엇보다 정확성이 중요하다는 걸 느꼈습니다.
새로운 영역에서 마주한 어려움
가장 달랐던 부분은 결과를 확인하는 방식과 시간이었습니다.
전시 QA에서는 API를 호출하면 화면에 바로 노출되고, 결과를 즉시 확인할 수 있었습니다.
반면 예약·정산 QA는 데이터를 생성하고, 배치가 실행된 후에야 결과를 확인할 수 있었습니다.
즉, 물리적인 시간이 필요했죠.
또한 단순히 TC를 작성하는 것을 넘어, 계산식과 정책을 반영한 상태 테이블을 설계해야 했는데, 처음 해보는 작업이라 많이 헤매고 전시 QA와 비교했을 때 준비부터 시작해서 전체적인 새로운 방식에 익숙해지는 데 시간이 필요했습니다.
어려움을 기회로 바꾼 과정
예약·정산 업무 내용은 꾸준히 복습하며 정리했습니다. 특히 상태 테이블처럼 처음 접하는 문서는 기존 완성본을 참고해 분석하고, 이해되지 않는 부분은 주저 없이 빠르게 도움을 요청했습니다. 이를 통해 업무 흐름을 안정적으로 익힐 수 있었습니다.
또한 기획 및 정책 문서를 분석할 때는 단편적인 내용만 보지 않고, 과거 이력과 변경 히스토리까지 함께 파악하며 전체 맥락을 이해하려 노력했습니다. 이러한 접근을 통해 어려웠던 부분들을 점차 극복할 수 있었습니다.
세 영역을 경험하며 넓어진 시야
QA는 단순한 테스트 수행자가 아니라 서비스 구조를 읽고 분석하는 역할입니다.
전시는 사용자 관점 : “사용자가 어떻게 경험하는가?”
예약은 데이터 전달 관점 : “전시 → 예약 → 결제 → 정산을 안정적으로 연결”
정산은 금전 관점 : “정확한 숫자가 끝까지 맞는가?”
전시 QA에서 시작해서 예약·정산까지 경험하게 되었고, QA 엔지니어로서 업무 영역이 확실히 넓어졌습니다. 이는 추상적 표현이 아닌 실제로 흐
전시·예약·정산 QA, 무엇이 다를까?
전시(Front Display): “실시간으로, 빠르게, 보기 좋게”
2. 예약(Reservation): “미리 정하고, 흐름을 이어가게”
3. 정산(Settlement): “돈이 오가는 곳, 정확한 계산”
업무 영역이 바뀌면서 달라진 것들
전시 QA의 중심은 사용자가 실제로 마주하는 화면이었습니다. UX/UI를 해치지 않으면서 빠르고 직관적으로 보여주는 것이 테스트의 핵심이었죠. 그래서 복잡한 구성보다는 상품 가격, 혜택 정보, 버튼 상태, 문구, 필터처럼 눈에 바로 보이는 영역을 중심으로, ‘사용자가 어떻게 사용할까?’라는 관점에서 자연스럽게 접근하게 됐습니다.
반면, 예약·정산 QA는 데이터의 정합성이 중심이었습니다. 사용자에게 보이는 화면이 아니라, 금액 계산을 위한 수식이 맞는지, 배치 순서에 따라 데이터가 제대로 흘러가는지, 최종 금액이 정확하게 계산되는지를 검증하는 것이 핵심이었죠.
특히 예약·정산은 실제 돈이 움직이는 영역이기 때문에, 다양한 경우의 수를 충분히 고려하지 않으면 바로 금전적 오류로 이어질 수 있었습니다. 단 1원의 차이도 문제가 될 수 있는 영역이라, 무엇보다 정확성이 중요하다는 걸 느꼈습니다.
새로운 영역에서 마주한 어려움
가장 달랐던 부분은 결과를 확인하는 방식과 시간이었습니다.
전시 QA에서는 API를 호출하면 화면에 바로 노출되고, 결과를 즉시 확인할 수 있었습니다.
반면 예약·정산 QA는 데이터를 생성하고, 배치가 실행된 후에야 결과를 확인할 수 있었습니다.
즉, 물리적인 시간이 필요했죠.
또한 단순히 TC를 작성하는 것을 넘어, 계산식과 정책을 반영한 상태 테이블을 설계해야 했는데, 처음 해보는 작업이라 많이 헤매고 전시 QA와 비교했을 때 준비부터 시작해서 전체적인 새로운 방식에 익숙해지는 데 시간이 필요했습니다.
어려움을 기회로 바꾼 과정
예약·정산 업무 내용은 꾸준히 복습하며 정리했습니다. 특히 상태 테이블처럼 처음 접하는 문서는 기존 완성본을 참고해 분석하고, 이해되지 않는 부분은 주저 없이 빠르게 도움을 요청했습니다. 이를 통해 업무 흐름을 안정적으로 익힐 수 있었습니다.
또한 기획 및 정책 문서를 분석할 때는 단편적인 내용만 보지 않고, 과거 이력과 변경 히스토리까지 함께 파악하며 전체 맥락을 이해하려 노력했습니다. 이러한 접근을 통해 어려웠던 부분들을 점차 극복할 수 있었습니다.
세 영역을 경험하며 넓어진 시야
QA는 단순한 테스트 수행자가 아니라 서비스 구조를 읽고 분석하는 역할입니다.
전시는 사용자 관점 : “사용자가 어떻게 경험하는가?”
예약은 데이터 전달 관점 : “전시 → 예약 → 결제 → 정산을 안정적으로 연결”
정산은 금전 관점 : “정확한 숫자가 끝까지 맞는가?”
전시 QA에서 시작해서 예약·정산까지 경험하게 되었고, QA 엔지니어로서 업무 영역이 확실히 넓어졌습니다. 이는 추상적 표현이 아닌 실제로 흐