MCP로 쇼핑몰 연동 QA 자동화하기 - 반복 작업을 맡기기까지

쇼핑몰 연동 업무를 하다 보면 테스트할 일이 끊이지 않는다. 신규 쇼핑몰을 붙일 때도 그렇고, 외부 API가 바뀌어 코드를 고친 뒤에도 다시 확인해야 한다.

상품 하나만 보내보면 될 것 같은데, 막상 시작하면 준비할 것이 많았다. 상품을 만들고, 옵션을 넣고, 판매 채널에 맞는 정보를 채운다. 전송에 실패하면 다시 화면을 찾아가 값을 고친다.

이걸 테스트할 때마다 내가 처음부터 입력해야 하나. 반복되는 준비는 AI에게 맡기고, 나는 테스트 조건을 정하고 결과를 살펴보는 데 시간을 쓰고 싶었다.

브라우저 조작을 스킬로 맡겨보는 데서 시작해, 기존 API를 묶은 MCP 서버와 실행 기록을 확인할 모니터까지 만들었다. 이 글에는 그 과정에서 어떤 선택을 했고, 써보면서 무엇이 더 필요해졌는지 남겨본다.

상품 하나 보내는 데 다섯 단계

여기서 채널은 상품을 보내는 쇼핑몰을 뜻한다. 테스트 상품 하나를 채널에 등록하려면 대략 이런 순서를 거친다.

테스트 상품 생성 — 상품명, 이미지, 가격, 옵션을 채운다.
채널용 연동 상품 생성 — 카테고리를 고르고 채널에서 사용할 값을 설정한다.
기본 정보·배송 정보 설정 — 채널과 계정 유형에 맞는 필수값을 채운다.
채널로 전송 — 등록 결과와 채널 응답을 확인한다.
실패한 값 수정 후 재전송 — 거절 사유를 보고 해당 값을 고친다.

한 상품만 확인하면 끝나는 것도 아니다. 온라인 계정과 백화점형 계정, 단일 옵션과 다중 옵션, 신규 등록과 여러 종류의 수정 전송을 조합해 확인해야 했다.

가장 불편했던 것은 마지막 단계였다. 쇼핑몰이 실패 사유를 내려줘도 그 값이 어느 화면에 있는지 찾아가 고쳐야 했다. 실패가 한 번으로 끝나지 않으면 같은 화면을 몇 번씩 오가야 했다.

AI가 화면을 찾아다녀야 할까

먼저 QA 절차를 스킬로 정리해, AI가 브라우저로 관리자 화면을 조작하도록 했다. 어느 메뉴에서 무엇을 입력하고, 전송 결과는 어디서 확인할지 작업 순서를 담았다.

스킬로도 어느 정도는 됐다. 매번 작업 방법을 설명하지 않아도 상품 준비부터 전송 결과 확인까지 맡길 수 있었다.

다만 절차를 정리해두어도 실행할 때는 화면을 읽고 입력 위치를 찾아 이동해야 했다. 조건을 바꿔가며 QA를 반복하다 보니, 이 과정에 드는 시간과 토큰을 줄일 방법을 고민하게 됐다.

상품 하나를 만들 때마다 화면의 구조까지 계속 읽게 할 필요가 있을까. 내가 우선 확인하려던 것은 상품 데이터가 연동 로직을 거쳐 채널에 정상적으로 전달되는가였다.

그래서 관리자 화면이 어떤 API를 호출하는지 하나씩 확인했다. 상품 생성·수정·전송·이력 조회를 업무 단위로 묶고, 각 도구가 받을 입력값을 정했다. 화면에서 사용하던 서버 API를 직접 호출하고, 반복되는 준비 절차는 도구 안에 넣었다.

AI가 MCP를 통해 QA 도구를 사용하고, QA 서버가 테스트 환경 API를 실행하며 사람이 모니터에서 기록을 확인하는 구조 — 기존 화면에서 사용하던 API를 도구로 제공하고, 실행 과정은 모니터에서 확인한다.

주요 도구와 역할은 다음과 같다.

도구	맡긴 일
`create_product`	요청한 옵션 조건에 맞는 `[QA]` 테스트 상품 생성
`edit_product`	기존 상품에서 확인하려는 값 수정
`send_product`	채널 등록·수정 전송과 결과 확인
`get_product_history`	같은 상품으로 시도한 전송과 수정 이력 조회

지금은 Claude에게 이런 식으로 요청한다.

백화점형 계정에 다중옵션 상품 하나 만들어서 등록하고, 전체수정까지 보내 줘.

이 요청에 따라 계정 상태 확인, 상품 생성, 채널 설정, 전송이 이어진다. 이번에 자동화한 범위는 API를 통한 상품 준비와 연동 처리다.

MCP로 연결한 이유

API를 호출하는 스크립트나 CLI를 만들 수도 있었다. 혼자 정해진 순서대로 실행한다면 그 방식도 괜찮았을 것이다.

다만 팀원들도 각자 사용하는 AI에서 같은 도구를 쓸 수 있게 하고 싶었다. 실행 범위와 기록 방식도 서버 한곳에서 관리하면 좋겠다고 생각했다.

그래서 AI 애플리케이션과 외부 도구를 연결하는 공통 규격인 MCP를 사용했다. Claude Code나 데스크톱 앱, Cowork에서 같은 QA 서버에 연결해 도구를 쓰도록 구성했다.

처음에는 내 PC에서 돌렸고, 지금은 서버에 올려 함께 쓰고 있다. 작업 절차가 바뀌면 서버 쪽을 고쳐 반영한다.

AI가 한 일을 다시 확인하려면

API로 작업을 맡길 수 있게 되자, 이번에는 결과를 어떻게 확인할지가 고민됐다. 어떤 API를 어떤 값으로 호출했고, 우리 서버와 채널은 각각 무엇을 응답했는지 내가 볼 수 있어야 했다.

실패 원인을 확인하려고 관리자 화면을 처음부터 다시 찾아다녀야 한다면, 맡겨서 줄인 수고를 검토할 때 다시 들이게 될 것 같았다. 그래서 도구 호출마다 실행 기록을 남기고, 요청·응답과 채널의 거절 사유를 한곳에서 확인할 모니터를 만들었다.

AI 활동 모니터에서 실패한 상품 전송을 선택하고, 채널이 모델명의 특수문자를 거절한 응답을 확인하는 예시 — 전송 실행을 열면 어느 단계에서 실패했는지와 채널의 거절 사유를 함께 확인할 수 있다. 예시 데이터.

예시에서는 모델명에 허용되지 않는 문자가 있어 등록이 거절됐다. 수정 후 재전송까지 확인하려면, 한 번의 요청·응답만으로는 부족했다. 그래서 같은 상품의 전송 시도와 그 사이에 바뀐 값을 묶어 상품 이력 화면을 만들었다.

같은 상품의 첫 번째 전송이 실패하고 모델명을 수정한 뒤 두 번째 전송에 성공한 과정을 모아 보여주는 상품 이력 예시 — 실패 → 모델명 수정 → 재전송 성공. 같은 상품에서 무엇을 바꿨는지 이어서 볼 수 있다. 예시 데이터.

이제는 요약에서 확인할 부분을 고른 뒤, 해당 실행의 응답과 변경값을 열어본다.

어디까지 실행하게 둘 것인가

사내 AI 활용 발표 후기에서 도구를 연결할수록 권한도 정해야 한다고 썼다. 이번에는 상품을 만들고 고치는 것에 더해, 외부 채널로 보내는 동작까지 허용해야 했다.

프롬프트에 주의사항을 적는 것만으로는 부족하다고 생각했다. 호출할 수 있는 주소와 바꿀 수 있는 데이터를 서버 코드에서 검사하도록 했다.

대상	적용한 제한
호출 주소와 기능	테스트 환경 주소와 메뉴·API를 허용 목록으로 관리하고, 호출 직전에 확인
DB 접근	API가 없는 조회에만 사용하고 읽기 전용으로 제한
채널 전송	테스트용 전송 대상이 확인되지 않은 채널은 사람이 허용한 뒤 전송
테스트 데이터와 기록	상품명에 `[QA]`와 생성 시각을 붙이고, 기록에서 토큰·비밀번호를 가림

관리자 서비스의 테스트 환경과 판매 채널의 테스트 서버는 별개라, 외부로 전송할 대상도 따로 확인했다. 다른 서비스의 코드를 고쳐야 해결되는 문제라면 분석 내용을 남기고 사람이 이어서 확인하도록 했다.

처음 만드는 AI 에이전트 서비스를 읽을 때도 Tool의 입력 구조와 설명이 중요하다고 느꼈다. 직접 만들어보니 설명에는 사용법뿐 아니라 어디까지 실행할 수 있고, 실패하면 무엇을 확인해야 하는지까지 있어야 했다.

써보면서 달라진 것과 남은 고민

계정과 옵션 조건을 바꿔가며 상품을 만들고, 등록과 수정 전송을 확인하는 데 사용하고 있다. 준비 작업을 맡기고 나니 다음에 어떤 조합을 확인할지 살펴보기 편해졌다.

입력과 기대 결과가 고정된 테스트는 코드로 남겨두려 한다. 지금은 조건을 바꿔 실행해보고, 실패한 응답을 살펴보며 값을 조정하는 과정에 이 도구를 쓰고 있다.

다음으로 다듬고 싶은 것은 도구의 응답이다. 사람이 원인을 확인하려면 상세 원문이 필요하지만, AI가 다음 행동을 정할 때마다 전부 읽어야 할까. 결과 요약과 오류 코드, 수정에 필요한 항목을 먼저 주고 원문은 필요할 때 조회하는 방식도 살펴보려 한다.

마치며 - 도구를 연결한 다음에 할 일

시작은 테스트할 때마다 반복되는 준비를 줄이고 싶다는 생각이었다. 브라우저 조작을 스킬로 맡겨본 뒤, 화면을 거칠 필요가 없는 작업은 API 도구로 옮겼고 여러 AI에서 쓰도록 MCP로 연결했다.

직접 만들어보니 실행을 맡긴 만큼 확인할 방법도 같이 만들어야 했다. 어디까지 바꿀 수 있는지 정하고, 요청과 응답을 내가 다시 볼 수 있어야 업무에 쓸 수 있었다. 새로운 업무를 맡길 때도 실행 절차와 검토할 기준을 함께 정해보려 한다.

피드백은 언제나 환영입니다.

목차