토스쇼핑 Open API 상품 선별 시스템 v2.3.1: 카테고리별 수집과 운영 검증 (개발기 11편)

토스쇼핑 Open API 상품 선별 시스템을 v1.8.0의 상품 1개 테스트에서 v2.3.1의 카테고리별 수집 기반 운영 파이프라인까지 확장했습니다. 실제 카테고리별 베스트 상품 수집(실행 13)과 카테고리 분산·재선정 제외 검증(실행 14) 결과를 정리한 개발기 11편입니다. 다만 AI 평가는 여전히 ChatGPT 상품 평가 프로젝트에서 수동으로 진행하며, 블로그·SNS 게시가 자동 완료된 것은 아닙니다.

토스쇼핑 Open API 상품 선별 시스템, 10편 이후 달라진 점

10편에서는 플러그인 v1.8.0으로 상품 1개(스파클 생수)를 대상으로 상품 조회부터 선별 결과 DB 저장까지의 workflow를 처음부터 끝까지 검증했습니다. 당시에는 AI API 자동 호출이 없었고, 평가는 ChatGPT에서 수동으로 진행했습니다.

이번 11편은 그 이후 v2.3.1까지의 변화를 기록합니다. 한 줄로 요약하면 상품 1개를 조회하고 저장하던 테스트 시스템을, 카테고리별 상품 수집과 AI 기반 평가를 거쳐 게시 준비가 가능한 상품을 선정하는 운영 파이프라인으로 발전시킨 과정입니다. 버전별 기능 목록보다 각 기능이 왜 필요했는지, 어떤 문제가 있었는지, 실제 실행에서 무엇이 확인됐는지를 중심으로 적었습니다.

v1.8.0에서 v2.3.1까지의 발전 과정

10편 이후의 개발은 크게 네 단계로 나눌 수 있습니다. 각 버전 사이의 세부 변경 사항 중 확인되지 않은 부분은 채우지 않고, 확인된 기능과 테스트 결과만 적습니다.

쉐어링크 발급과 기존 링크 재사용의 첫 구현은 쉐어링크 발급 구현(v1.9.0) 글에서 따로 다뤘습니다. 1편부터 9편까지의 내용은 1편 API 키 발급, 2편 OAuth·Health 테스트, 3편 베스트 상품 조회, 4편 상품 상세 조회, 5편 쉐어링크 발급 테스트, 6편 DB 저장, 7편 상세 정보 갱신, 8편 일괄 상세 조회, 9편 선별용 데이터 구조에서 확인할 수 있습니다.

v2.2.0: 반복 운영을 위한 관리 기능

여러 상품을 반복해서 선정하다 보니 같은 상품이 계속 후보에 오를 수 있다는 점이 운영상의 문제가 됐습니다. v2.2.0에서는 이를 다루는 기능을 추가했습니다.

• 최근 선정 상품의 재선정을 일정 기간 제외하는 기능 (기본 제외 기간 7일)
• 후보 다양화를 위한 수집 모드
• 평가용 JSON, 평가 결과 JSON, 최종 추천 JSON을 선정 실행별로 저장하는 기능
• 최근 선정 제외 결과와 저장된 JSON을 확인할 수 있는 관리 화면

이 시점의 카테고리 다양화는 전체 베스트 상품을 가져온 뒤 내부에서 카테고리별로 분산하는 방식이었습니다. 카테고리별 API를 직접 호출하는 방식과는 다르다는 점을 구분해 둡니다.

v2.2.0 실제 테스트에서는 상품 10개를 가져온 뒤 최근 선정 상품 8개를 제외해 평가 대상 2개를 만들었습니다. 최종 2개 선정과 게시 준비까지 완료했고, 실행 JSON 저장도 정상 동작했습니다.

카테고리별 수집 기능이 필요했던 이유

전체 베스트 목록에서 상품을 가져와 내부에서 카테고리를 나누는 방식은 원하는 카테고리의 상품을 직접 확보하기 어렵다는 한계가 있었습니다. 목록에 없는 카테고리의 상품은 분산 로직이 아무리 좋아도 후보가 될 수 없기 때문입니다. 그래서 실제로 카테고리를 지정해 베스트 상품을 가져오는 호출 방식을 찾아야 했습니다.

실제 카테고리 API 진단과 v2.3.0 구현

여러 엔드포인트를 실제로 호출해 진단한 끝에 다음 호출 방식이 동작하는 것을 확인했습니다.

카테고리 목록
/openapi/categories

카테고리별 베스트 상품
/openapi/products/best-categories/{categoryId}?size={N}

v2.3.0은 이 경로를 사용해 카테고리별 베스트 상품을 수집하도록 만든 버전입니다. 이 버전의 실제 테스트가 실행 13입니다.

실행 13: 카테고리별 수집과 선정 workflow의 첫 연결

수집 단계는 성공했지만, 최종 결과를 분석하자 특정 최상위 카테고리 계열에 선정 상품이 몰리고 비슷한 상품군이 중복 선정된 것이 확인됐습니다. 이 결과에서 수집 단계의 카테고리 다양화와 최종 선정 단계의 다양화는 서로 다른 문제라는 점을 확인했습니다. 다양한 카테고리에서 후보를 가져와도, 선정 단계에서 점수 순서대로만 고르면 결과가 한쪽으로 쏠릴 수 있습니다.

v2.3.1: 카테고리 분산과 브랜치 선정 상한

v2.3.1은 v2.3.0의 실제 카테고리별 수집 기능을 유지하면서, 선정 결과가 편중되는 문제를 줄이는 방향으로 개선한 버전입니다.

• 카테고리 후보를 앞에서부터 단순 선택하지 않고 카테고리 계층과 브랜치를 고려
• 동일하거나 유사한 상품군의 중복 선정 억제
• 같은 2단계 카테고리 브랜치에 대한 선정 상한 설정
• 관련 설정을 관리 화면에서 조절할 수 있도록 개선
• 선정 결과와 보정 내역을 확인할 수 있도록 개선

브랜치 선정 상한은 상품 수집량을 제한하는 설정이 아니라 최종 선정 결과의 편중을 제한하는 설정입니다. 현재 기본값은 브랜치당 최대 3개입니다.

설정 화면 패키징 오류와 수정

개발 중 설정 화면에 문제가 생겨 수정 패키지를 다시 만들었습니다. 수정본을 설치한 뒤 설정 내용 버튼이 정상적으로 표시되는 것까지 확인했고, 이후 테스트는 수정본으로 진행했습니다.

실행 14: v2.3.1 운영 테스트

v2.3.1 수정본에서 다음 설정으로 다시 실행했습니다.

• 카테고리 수: 5개
• 카테고리당 상품 수: 5개
• 재선정 제외 기간: 7일

이전 실행에서 선정된 8개 상품이 7일 재선정 제외 규칙에 따라 평가 대상에서 빠졌고, 남은 17개를 평가해 5개를 선정했습니다. 신규 저장 4개와 기존 갱신 21개는 대부분의 상품이 이미 DB에 있었다는 의미이며, 중복 상품이 새 레코드로 쌓이지 않고 갱신으로 처리된 것을 확인할 수 있었습니다.

최종 선정 상품은 무선 이어폰 2개, 차렵이불 1개, 접이식 의자 1개, 충전기 1개였습니다.

동일 상품군 중복에 대한 판단

일부 상품은 같은 카테고리 경로를 공유했습니다. 다만 최종 추천 상품이 반드시 모두 서로 다른 상품군일 필요는 없다고 판단했습니다. 따라서 동일 상품군 중복이 완벽하게 사라졌다고 보지 않습니다. 지금 단계의 목표는 카테고리별 수집과 선정 파이프라인을 안정적으로 운영하는 것이고, 다양성 제약을 더 강하게 거는 대신 실제 운영 데이터를 먼저 쌓기로 했습니다.

현재 전체 workflow와 자동·수동 단계 구분

카테고리 목록 조회
→ 카테고리별 베스트 상품 수집
→ 중복 상품 처리
→ 상품 DB 저장 및 갱신
→ 상품 상세 정보 갱신
→ 최근 선정 상품 제외
→ 평가 후보 생성
→ 평가용 JSON 생성
→ ChatGPT 상품 평가 프로젝트에서 평가
→ 평가 결과 JSON 입력
→ 선정 점수와 상태 저장
→ 최종 상품 선정
→ 쉐어링크 발급 또는 재사용
→ 최종 추천 JSON 생성
→ ready 상태 확인

현재 확인된 한계

• AI 평가가 수동이라 평가 단계에서 사람의 개입이 필요합니다.
• 선정 결과에서 동일 카테고리 경로를 공유하는 상품이 일부 남아 있습니다.
• 카테고리별 API 경로는 운영 환경에서 동작을 확인했을 뿐, 공식 문서로 전체 명세를 확인한 것은 아닙니다.
• 실제 블로그 게시, SNS 활용 결과와 클릭·유입·수익 데이터는 아직 없으므로 수익성이나 성과가 검증된 것은 아닙니다.

운영 단계에서 확인할 항목

당분간은 새 기능을 계속 추가하기보다 운영 데이터를 관찰하는 데 집중할 계획입니다.

• 카테고리별 API 호출 성공률 추이
• 반복 실행에서 최근 선정 제외 기능이 정상 동작하는지 여부
• 재선정 제외가 누적되면서 평가 후보가 부족해지는지 여부
• 선정 상품의 실제 블로그 게시·SNS 콘텐츠 활용 결과
• 클릭·유입·수익 데이터가 확보된 이후의 성과 평가

충분한 운영 근거가 생기기 전에는 새로운 선정 규칙이나 큰 구조 변경을 서둘러 추가하지 않을 예정입니다.

마무리

10편의 상품 1개 테스트가 workflow가 이어지는지를 확인한 단계였다면, v2.3.1까지의 개발은 실제 카테고리별 수집, 반복 실행을 위한 재선정 제외, 선정 결과의 분산 제어를 갖춘 운영용 파이프라인을 만드는 과정이었습니다. 실행 13과 14에서 수집과 선정, 게시 준비 상태까지 이어지는 것을 확인했지만, 수동 평가 단계와 성과 검증이라는 남은 과제는 그대로입니다. 다음 글에서는 운영 데이터를 바탕으로 확인된 내용을 이어서 기록하겠습니다.