안녕하세요. 한국신용데이터 품질개선팀 QA Engineer Diana(염수빈)입니다. QA로 첫 커리어를 시작한 지 7개월, 매일 새로운 기술과 넓은 시야를 배워나가고 있습니다.
이번 캐시노트 마켓 포인트 정책 QA는 그동안 조금씩 쌓아온 AI와의 협업 경험을 실제 업무에 본격적으로 적용해본 사례입니다. 기획 분석 기간 동안 PRD(Product Requirements Document)를 학습시킨 AI에게 검증 도구 제작을 온전히 맡기고, QA 기간에는 그 도구로 케이스를 돌리며 결함을 잡아냈습니다. "AI 덕분에 내 역량보다 훨씬 넓은 범위의 업무를 다루는 게 어렵지 않은 시대가 됐다"는 걸 이번 프로젝트로 체감했습니다. ("QA가 직접 도구를 만들었다"가 포인트가 아닙니다.)
무엇을 검증해야 하는가
캐시노트 마켓은 사장님들이 사업장 운영에 필요한 유·무형 상품을 구매하는 이커머스 플랫폼입니다. 마켓팀은 회원 혜택을 꾸준히 고도화해왔는데, 이번엔 캐시노트 스탠다드 멤버십 회원 대상 포인트 적립 정책이 새로 도입됐습니다. 단순히 포인트 계산만 맞는지 보면 될 줄 알았는데, 막상 뜯어보니 훨씬 복잡했습니다.
회원 멤버십 유형에 따라 적립률이 다르게 적용되고
상품 > 카테고리 > 입점사 > 기본 순으로 4단계 폴백이 적용되며
포인트 상태는 적립 예정 / 완료 / 취소 / 회수 네 가지로 나뉘고
취소·회수는 지급 전/후로 다시 나뉘며
쿠폰·포인트 결제와 부분/전체 취소·환불에 따라 비율 계산까지 필요했습니다
이걸 매번 손으로 검증하다가는 아무리 테스트케이스를 잘 짜도 과부하가 올 것 같았습니다. 처음엔 익숙한 엑셀 수식으로 계산해보려 했지만, 결국 하나하나 시트에 옮겨 적어야 하는 한계와 검증하기 힘든 예외 케이스가 너무 많았습니다. "직접 판매가를 입력하지 않아도, 옮겨 적지 않아도 구매 과정에서 자동으로 포인트를 계산해주면 좋겠다"는 생각이 들었습니다.
마침 이전에 마켓 E2E 자동화 프로젝트를 진행하면서, 마켓팀 백엔드 개발자 Cooper, Dante께서 만들어주신 결제 상태 제어용 크롬 확장 프로그램의 도움을 받아 쓴 경험이 있었습니다. "비슷한 방식으로 포인트 검증 도구도 만들 수 있지 않을까"라는 아이디어가 여기서 시작됐습니다.
정책부터 학습시켰습니다
Claude Code의 '스킬' 기능으로 마켓 포인트 전용 스킬을 만들고, PRD 문서·플로우차트·어드민 프로토타입을 학습시켜 항상 같은 도메인 기준으로 답하도록 설정했습니다. 그러니 매번 PRD를 다시 설명할 필요 없이 "PRD 케이스 7번 회수 로직 위젯에 추가해줘" 한 줄로 콘텍스트가 통했습니다.
요구사항을 자연어로 전달하면 AI가 코드를 생성하고, 브라우저에서 실제 동작을 확인한 뒤, 버그나 개선사항을 다시 자연어로 피드백하는 흐름을 반복했습니다.
요구사항을 자연어로 전달
↓
AI가 코드 생성
↓
브라우저에서 실제 동작 확인
↓
버그 / 개선사항을 다시 자연어로 피드백
↓ (반복)
위젯이 어떻게 동작하는가
위젯의 핵심 아이디어는 한 줄로 정리됩니다. 위젯이 자체적으로 정책을 해석해서 계산한 뒤, 백엔드 응답과 비교한다. 백엔드가 준 값을 그대로 띄우면 "응답이 오는지"만 확인할 수 있지, "정확히 계산됐는지"는 검증할 수 없기 때문입니다.
정책 가져오기. 위젯의 추출 기능을 실행하면 마켓 파트너센터에 등록된 데이터(기본·상품·카테고리·입점사 룰과 상품 정보)를 한 번에 가져와 chrome.storage.local에 버전별로 누적 저장합니다. 이때 산정 로직(우선순위 폴백, 라운딩, 등급 분기 등)은 가져오지 않고, PRD 기반으로 위젯이 직접 구현합니다.
자동 계산과 비교. 이후 마켓 페이지에 들어갈 때마다 위젯이 우측에 자동으로 노출되며, 그 페이지의 상품·결제 정보를 추출해 상품의 offerId, 카테고리 ID, 벤더 순으로 4단계 폴백을 매칭해 적립금을 계산합니다. 같은 어드민 룰을 위젯과 백엔드가 각자 해석해 결과를 내고, 두 값을 비교해 같으면 통과, 다르면 실패로 표시합니다.
어드민 룰 (raw 정책) ┐
├─→ 위젯 정책 엔진 (PRD 코드) → QA 계산값
│ ↕
│ 비교
│ ↕
마켓 웹 expectedPoints ┘ → 백엔드 계산값
복합 결제 자동 분배. 가장 까다로웠던 부분은 복합 결제 케이스였습니다. 예를 들어 장바구니에 상품 두 개를 담고, 하나에는 상품 전용 5,000원 쿠폰을 사용한 다음, 주문서에 포인트 3,000원까지 추가로 차감하는 경우를 생각해보겠습니다. PRD 기준("적립 기준 금액은 실 결제 금액")대로라면 쿠폰·포인트 사용액을 상품별로 비율 분배한 뒤 적립률을 적용해야 합니다. 사람이 손으로 하면 쿠폰·포인트 분배 → 단가 산정 → 라운딩(1차) → 적립금 산출 → 라운딩(2차) → 수량 반영 → 전체 합산까지 여러 단계를 거쳐야 했는데, 위젯은 이 계산을 페이지에서 자동으로 추출해 한 번에 처리해줍니다.
모드 전환. 같은 위젯이지만 주문 전/후로 다른 모드를 씁니다. 주문 전에는 매칭 결과와 계산 과정을 다 펼쳐 보여주는 '검증 모드'로, 케이스를 하나하나 추적할 수 있게 했습니다. 주문 후에는 '결과 모드'로 전환돼, 예상 적립 금액과 적립 상태를 HERO 박스로 크게 띄우고 세부 정보는 토글로 접어둡니다. 여기에는 취소·회수 시점의 비율 계산을 대신해주는 시뮬레이터도 함께 붙여, 직접 계산기를 두드릴 일이 없어졌습니다.
시간이 줄어드니, 버그가 더 잘 보였습니다
처음 목표는 '시간 단축'이었지만, 실제로 더 크게 체감한 효과는 테스트 범위 자체가 넓어졌다는 점이었습니다. 예전엔 미리 추려둔 몇 가지 상품으로만 검증했다면, 이제는 위젯이 자동 계산을 해주니 마켓에 등록된 임의의 상품으로도 똑같이 검증할 수 있게 됐습니다. 그렇게 케이스를 넓혀가다 보니 배송 옵션·판매 조건 조합에서 미처 시나리오로 잡아두지 않았던 버그가 자연스럽게 드러났습니다. 위젯이 "버그를 찾아준 것"이라기보다는 "버그를 찾을 시간과 시야를 만들어준 것"에 가깝습니다.
| 위젯 없을 때 | 위젯 사용 시 |
케이스당 검증 시간 | 약 5~7분 | 약 1분 (80% 감소) |
정책 변경 시 대응 | 엑셀 수식 다 재작업 | 어드민에서 자동 추출 |
부분 취소 계산 | 계산기 들고 손계산 | 시뮬레이터 사용 |
이번 프로젝트를 마치고 가장 크게 남은 건 "필요하면 만들면 되지"라는 사고의 전환이었습니다. 시작할 땐 망설였지만, 막상 부딪쳐보니 잘 만드는 것보다 무엇을, 왜, 어떻게 만들지를 정확히 정의하며 한 줄씩 지시하는 게 훨씬 중요했습니다. 완벽한 그림을 그리고 시작하기보다, 일단 시작하며 정의해나가는 편이 결과적으로 더 빨랐습니다.
신입 QA로서 아직 배울 게 훨씬 많지만, 이번 프로젝트로 AI와 함께라면 제가 할 수 있는 일의 경계가 예상보다 훨씬 넓어진다는 걸 알게 됐습니다. 완성된 도구 하나보다, 문제를 마주했을 때 접근할 수 있는 방법의 폭이 넓어졌다는 게 진짜 얻은 것이었습니다. 이 확장된 시야는 다음 프로젝트에서도 계속 저와 함께 갈 것 같습니다.
안녕하세요. 한국신용데이터 품질개선팀 QA Engineer Diana(염수빈)입니다. QA로 첫 커리어를 시작한 지 7개월, 매일 새로운 기술과 넓은 시야를 배워나가고 있습니다.
이번 캐시노트 마켓 포인트 정책 QA는 그동안 조금씩 쌓아온 AI와의 협업 경험을 실제 업무에 본격적으로 적용해본 사례입니다. 기획 분석 기간 동안 PRD(Product Requirements Document)를 학습시킨 AI에게 검증 도구 제작을 온전히 맡기고, QA 기간에는 그 도구로 케이스를 돌리며 결함을 잡아냈습니다. "AI 덕분에 내 역량보다 훨씬 넓은 범위의 업무를 다루는 게 어렵지 않은 시대가 됐다"는 걸 이번 프로젝트로 체감했습니다. ("QA가 직접 도구를 만들었다"가 포인트가 아닙니다.)
무엇을 검증해야 하는가
캐시노트 마켓은 사장님들이 사업장 운영에 필요한 유·무형 상품을 구매하는 이커머스 플랫폼입니다. 마켓팀은 회원 혜택을 꾸준히 고도화해왔는데, 이번엔 캐시노트 스탠다드 멤버십 회원 대상 포인트 적립 정책이 새로 도입됐습니다. 단순히 포인트 계산만 맞는지 보면 될 줄 알았는데, 막상 뜯어보니 훨씬 복잡했습니다.
회원 멤버십 유형에 따라 적립률이 다르게 적용되고
상품 > 카테고리 > 입점사 > 기본 순으로 4단계 폴백이 적용되며
포인트 상태는 적립 예정 / 완료 / 취소 / 회수 네 가지로 나뉘고
취소·회수는 지급 전/후로 다시 나뉘며
쿠폰·포인트 결제와 부분/전체 취소·환불에 따라 비율 계산까지 필요했습니다
이걸 매번 손으로 검증하다가는 아무리 테스트케이스를 잘 짜도 과부하가 올 것 같았습니다. 처음엔 익숙한 엑셀 수식으로 계산해보려 했지만, 결국 하나하나 시트에 옮겨 적어야 하는 한계와 검증하기 힘든 예외 케이스가 너무 많았습니다. "직접 판매가를 입력하지 않아도, 옮겨 적지 않아도 구매 과정에서 자동으로 포인트를 계산해주면 좋겠다"는 생각이 들었습니다.
마침 이전에 마켓 E2E 자동화 프로젝트를 진행하면서, 마켓팀 백엔드 개발자 Cooper, Dante께서 만들어주신 결제 상태 제어용 크롬 확장 프로그램의 도움을 받아 쓴 경험이 있었습니다. "비슷한 방식으로 포인트 검증 도구도 만들 수 있지 않을까"라는 아이디어가 여기서 시작됐습니다.
정책부터 학습시켰습니다
Claude Code의 '스킬' 기능으로 마켓 포인트 전용 스킬을 만들고, PRD 문서·플로우차트·어드민 프로토타입을 학습시켜 항상 같은 도메인 기준으로 답하도록 설정했습니다. 그러니 매번 PRD를 다시 설명할 필요 없이 "PRD 케이스 7번 회수 로직 위젯에 추가해줘" 한 줄로 콘텍스트가 통했습니다.
요구사항을 자연어로 전달하면 AI가 코드를 생성하고, 브라우저에서 실제 동작을 확인한 뒤, 버그나 개선사항을 다시 자연어로 피드백하는 흐름을 반복했습니다.
요구사항을 자연어로 전달
↓
AI가 코드 생성
↓
브라우저에서 실제 동작 확인
↓
버그 / 개선사항을 다시 자연어로 피드백
↓ (반복)
위젯이 어떻게 동작하는가
위젯의 핵심 아이디어는 한 줄로 정리됩니다. 위젯이 자체적으로 정책을 해석해서 계산한 뒤, 백엔드 응답과 비교한다. 백엔드가 준 값을 그대로 띄우면 "응답이 오는지"만 확인할 수 있지, "정확히 계산됐는지"는 검증할 수 없기 때문입니다.
정책 가져오기. 위젯의 추출 기능을 실행하면 마켓 파트너센터에 등록된 데이터(기본·상품·카테고리·입점사 룰과 상품 정보)를 한 번에 가져와 chrome.storage.local에 버전별로 누적 저장합니다. 이때 산정 로직(우선순위 폴백, 라운딩, 등급 분기 등)은 가져오지 않고, PRD 기반으로 위젯이 직접 구현합니다.
자동 계산과 비교. 이후 마켓 페이지에 들어갈 때마다 위젯이 우측에 자동으로 노출되며, 그 페이지의 상품·결제 정보를 추출해 상품의 offerId, 카테고리 ID, 벤더 순으로 4단계 폴백을 매칭해 적립금을 계산합니다. 같은 어드민 룰을 위젯과 백엔드가 각자 해석해 결과를 내고, 두 값을 비교해 같으면 통과, 다르면 실패로 표시합니다.
어드민 룰 (raw 정책) ┐
├─→ 위젯 정책 엔진 (PRD 코드) → QA 계산값
│ ↕
│ 비교
│ ↕
마켓 웹 expectedPoints ┘ → 백엔드 계산값
복합 결제 자동 분배. 가장 까다로웠던 부분은 복합 결제 케이스였습니다. 예를 들어 장바구니에 상품 두 개를 담고, 하나에는 상품 전용 5,000원 쿠폰을 사용한 다음, 주문서에 포인트 3,000원까지 추가로 차감하는 경우를 생각해보겠습니다. PRD 기준("적립 기준 금액은 실 결제 금액")대로라면 쿠폰·포인트 사용액을 상품별로 비율 분배한 뒤 적립률을 적용해야 합니다. 사람이 손으로 하면 쿠폰·포인트 분배 → 단가 산정 → 라운딩(1차) → 적립금 산출 → 라운딩(2차) → 수량 반영 → 전체 합산까지 여러 단계를 거쳐야 했는데, 위젯은 이 계산을 페이지에서 자동으로 추출해 한 번에 처리해줍니다.
모드 전환. 같은 위젯이지만 주문 전/후로 다른 모드를 씁니다. 주문 전에는 매칭 결과와 계산 과정을 다 펼쳐 보여주는 '검증 모드'로, 케이스를 하나하나 추적할 수 있게 했습니다. 주문 후에는 '결과 모드'로 전환돼, 예상 적립 금액과 적립 상태를 HERO 박스로 크게 띄우고 세부 정보는 토글로 접어둡니다. 여기에는 취소·회수 시점의 비율 계산을 대신해주는 시뮬레이터도 함께 붙여, 직접 계산기를 두드릴 일이 없어졌습니다.
시간이 줄어드니, 버그가 더 잘 보였습니다
처음 목표는 '시간 단축'이었지만, 실제로 더 크게 체감한 효과는 테스트 범위 자체가 넓어졌다는 점이었습니다. 예전엔 미리 추려둔 몇 가지 상품으로만 검증했다면, 이제는 위젯이 자동 계산을 해주니 마켓에 등록된 임의의 상품으로도 똑같이 검증할 수 있게 됐습니다. 그렇게 케이스를 넓혀가다 보니 배송 옵션·판매 조건 조합에서 미처 시나리오로 잡아두지 않았던 버그가 자연스럽게 드러났습니다. 위젯이 "버그를 찾아준 것"이라기보다는 "버그를 찾을 시간과 시야를 만들어준 것"에 가깝습니다.
위젯 없을 때
위젯 사용 시
케이스당 검증 시간
약 5~7분
약 1분 (80% 감소)
정책 변경 시 대응
엑셀 수식 다 재작업
어드민에서 자동 추출
부분 취소 계산
계산기 들고 손계산
시뮬레이터 사용
이번 프로젝트를 마치고 가장 크게 남은 건 "필요하면 만들면 되지"라는 사고의 전환이었습니다. 시작할 땐 망설였지만, 막상 부딪쳐보니 잘 만드는 것보다 무엇을, 왜, 어떻게 만들지를 정확히 정의하며 한 줄씩 지시하는 게 훨씬 중요했습니다. 완벽한 그림을 그리고 시작하기보다, 일단 시작하며 정의해나가는 편이 결과적으로 더 빨랐습니다.
신입 QA로서 아직 배울 게 훨씬 많지만, 이번 프로젝트로 AI와 함께라면 제가 할 수 있는 일의 경계가 예상보다 훨씬 넓어진다는 걸 알게 됐습니다. 완성된 도구 하나보다, 문제를 마주했을 때 접근할 수 있는 방법의 폭이 넓어졌다는 게 진짜 얻은 것이었습니다. 이 확장된 시야는 다음 프로젝트에서도 계속 저와 함께 갈 것 같습니다.