토스쇼핑 Open API 개발기 7편 – 상품 상세 API로 기존 DB 레코드 보강하기

토스쇼핑 Open API 개발기 7편에서는 6편에서 WordPress DB(wp_jb_toss_products)에 저장해 둔 상품 1건(tacaItemId 90382271, DB ID 1)을 대상으로 상품 상세 API를 다시 호출하고, 응답으로 받은 최신 판매가·할인율·평점·리뷰 수 등을 기존 레코드에 UPDATE하는 구조를 실제 서버에서 검증했다. 새 레코드가 생성되지 않고 같은 DB ID가 유지된 채 값만 갱신된다는 점이 이번 테스트의 핵심이다.

지금까지 진행한 토스쇼핑 Open API 연동 흐름

토스쇼핑 Open API 연동은 처음부터 완성된 기능을 목표로 하지 않고, API 하나씩을 검증하면서 단계적으로 플러그인을 확장하는 방식으로 진행하고 있다. 처음에는 Open API 사용 신청과 승인을 거쳐 Access Key와 Secret Key를 발급받는 과정부터 진행했다.

키를 발급받은 뒤에는 OAuth 토큰을 발급하고 Health API로 기본적인 연결을 확인했고, 연결이 정상이라는 것을 확인한 다음 실제 토스쇼핑 상품을 조회하는 테스트로 넘어갔다.

이후 조회한 상품의 tacaItemId를 이용해 상품 상세 정보를 가져오는 API를 테스트했고, 상품 정보를 조회하는 것에서 나아가 실제 쉐어링크를 발급받는 API까지 확인했다.

그리고 개별 API 테스트를 넘어서, 조회한 상품을 WordPress DB에 저장하고 같은 상품을 다시 조회했을 때 신규 저장이 아니라 기존 레코드가 UPDATE되도록 구조를 만든 것이 바로 앞 단계인 6편의 내용이다. 이번 7편은 그 저장 구조를 그대로 활용해, 저장된 상품의 상세 정보를 최신 값으로 보강하는 단계다.

6편에서 만든 DB 저장 구조

6편에서는 wp_jb_toss_products 테이블을 만들고, tacaItemId를 기준으로 이미 저장된 상품인지 확인한 뒤 신규 상품이면 INSERT, 이미 존재하는 상품이면 UPDATE하도록 분기하는 로직을 검증했다. 이 테이블에는 상품이 처음 발견된 시각(first_seen_at)과 목록에서 마지막으로 확인된 시각(last_seen_at)을 구분해서 기록하고 있다.

이번 7편에서는 이 테이블 구조를 새로 만들지 않고 그대로 이어서 사용했다. 다만 상세 API 응답을 반영할 필드와, 상세 조회 시각을 별도로 기록할 detail_fetched_at 컬럼을 추가로 활용했다.

v1.5.0에서 하려는 것

이번 단계의 플러그인 버전은 v1.5.0이다. 기존 v1.4.0을 계속 확장하는 방식으로 개발했고, 별도의 새 플러그인을 만들지는 않았다. 목표는 단순했다. DB에 이미 저장되어 있는 상품 레코드를 조회해서 tacaItemId를 확인하고, 그 값으로 토스쇼핑 Open API의 상품 상세 조회 기능을 호출한 뒤, 응답 데이터를 같은 레코드에 UPDATE하는 흐름이 실제로 동작하는지 검증하는 것이다. 상품 상세 조회를 포함한 전체 기능 구성은 토스쇼핑 Open API 공식 연동 가이드에서도 확인할 수 있다.

처리 흐름은 다음과 같다.

핵심은 상세 API 조회 결과가 새로운 상품 INSERT로 이어지는 것이 아니라, 기존 상품의 UPDATE로 연결된다는 점이다.

테스트 대상 상품

이번 테스트는 이미 DB에 저장되어 있는 상품 1건만을 대상으로 진행했다. 여러 상품을 동시에 처리하기 전에, DB 저장과 상세 API 조회가 연결되는 기본 workflow를 하나씩 확실하게 검증하기 위해서다.

상품 상세 API 호출 결과

저장된 tacaItemId 90382271로 상품 상세 API를 호출한 결과, HTTP 200 응답과 함께 resultType SUCCESS를 정상적으로 받았다. 실제 응답 내용은 다음과 같다.

htmlUrl은 이전 4편에서 상세 조회를 테스트했을 때와 마찬가지로 빈 값으로 돌아왔다. 이 상품 자체에 별도의 상세 페이지 HTML이 등록되어 있지 않은 것으로 보이며, 이 부분은 상품마다 다를 수 있다는 정도로만 이해하고 있다.

새 레코드가 아니라 기존 레코드가 UPDATE됐다

이번 테스트에서 가장 확인하고 싶었던 부분은 새로운 DB 레코드가 생성되지 않고, 기존 DB ID 1의 상품 레코드가 그대로 UPDATE됐는지였다. 실제 실행 결과는 다음과 같았다.

즉 상품을 처음 발견한 시각, 목록에서 마지막으로 확인한 시각, 상세 정보를 마지막으로 조회한 시각을 서로 다른 컬럼으로 구분해서 관리할 수 있게 됐다. 세 시각이 섞이지 않고 각자의 의미를 유지한 채 기록된다는 점을 이번 테스트로 확인했다.

실제로 값이 바뀐 부분: 리뷰 수

이번 상세 조회에서는 이전에 저장해 둔 값과 비교했을 때 리뷰 수가 실제로 달라진 것을 확인할 수 있었다.

이 결과는 단순히 기존 데이터를 다시 저장한 것이 아니라, 상품 상세 API가 실제로 새로운 데이터를 반환했고 그 값이 기존 DB 레코드에 정상적으로 반영됐다는 것을 보여주는 사례다. 다만 리뷰 수가 왜 늘었는지에 대해서는 별도로 원인을 추정하지 않았다. 이번 글에서는 “상세 API 조회 시점에 반환된 리뷰 수가 69,162로 갱신되었다”는 사실만 기록해 둔다.

이미지 관련 데이터는 어디까지 저장했나

이번 상세 API 응답에는 mainImageUrls 1건, detailImageUrls 3건, noticeImageUrl 1건이 포함되어 있었고, 이 값들도 함께 DB에 저장했다. 다만 이번 단계에서는 이 이미지 URL을 WordPress 콘텐츠에 자동으로 게시하거나 상업적으로 재사용하는 기능은 구현하지 않았다. 현재는 API에서 받은 이미지 관련 정보를 DB에 저장하고, 저장된 값이 정상적으로 들어왔는지 확인한 수준이다.

이번 단계에서 확인한 것과 아직 확인하지 않은 것

아직 구현하지 않은 기능은 이번 글에서도 완료된 것처럼 표현하지 않고, 향후 계획으로만 남겨 둔다.

다음 개발 방향

지금까지는 상품 1건을 조회해서 DB에 저장하고, 그 1건을 대상으로 상세 API를 다시 호출해 DB 정보를 보강하는 흐름까지 검증했다. 다음 단계에서는 이 1건 단위 구조를 여러 상품을 처리할 수 있는 구조로 확장하는 방향을 검토하고 있다.

토스쇼핑 상품 상세 API는 여러 tacaItemId를 함께 조회할 수 있는 것으로 확인되어 있어서, 향후 일괄 처리로 확장할 기반은 마련되어 있다고 볼 수 있다. 다만 실제 일괄 처리 로직은 아직 구현이 끝난 기능이 아니므로, 이번 글에서는 가능성만 언급하고 완성된 자동화처럼 표현하지 않는다. 예상하는 다음 흐름은 상품 후보 여러 건의 tacaItemId 수집 → 상세 API 일괄 조회 → 각 상품 DB 업데이트 → 선별 대상 데이터 구성 순서다.

이번 7편에서는 6편에서 구축한 상품 DB 저장 구조를 기반으로, 저장된 상품의 tacaItemId를 이용해 상품 상세 API를 호출하고 최신 상세 정보를 기존 DB 레코드(DB ID 1)에 UPDATE하는 구조를 실제 서버에서 검증했다. 새 레코드를 만들지 않고 같은 레코드의 값만 갱신됐다는 점, 그리고 리뷰 수가 65,445에서 69,162로 실제로 갱신된 사례를 통해 API 호출을 넘어 데이터를 지속적으로 관리하는 첫 workflow를 확인한 단계다.