라쿠텐 API와 Amazon MWS 기사를 지금 다시 읽어보면 ― SP-API 시대의 설계는 어떻게 바뀌었나

8월 21일
4분 분량

저희 블로그에는 2020~2023년경에 쓴 「라쿠텐 상품 검색 API 사용법」이나 「Amazon MWS의 시작 방법」 같은 기사가 남아 있습니다. 라쿠텐 API는 지금도 현역이지만, MWS는 이제 존재하지 않습니다. 이번에는 이 두 오래된 기사를 되돌아보면서, 「지금의 나라면 어떻게 다시 만들까」를 생각해 봅니다. 비슷한 자동화 시스템을 앞으로 만들 분께 참고가 되면 좋겠습니다.

API設計の大進化を示す図解。左側にある単純接続のシステムから、右側のAmazon SQSやLambdaと連携するサーバレスアーキテクチャへと進化する過程を描写。

되돌아볼 두 기사

・라쿠텐 상품 검색 API 사용법(2020년경): 앱 ID 취득 → 검색 파라미터 → URL을 조립해 요청, 이라는 소박한 구성

・Amazon MWS의 시작 방법(2020년경): AWS 액세스 키·시크릿 키를 사용한 인증, Scratchpad에서의 동작 확인

둘 다 「셀러의 상품 리서치를 자동화하고 싶다」는 같은 동기에서 쓴 기사입니다. 당시는 아직 API 1개를 단발로 두드리기만 하는, 소박한 만듦새였습니다.

MWS는, 이제 존재하지 않는다

우선 전제로, Amazon MWS(Marketplace Web Service)는 2024년 3월 31일로 완전히 종료되었습니다. 지금 MWS 기사를 읽어도, 적혀 있는 엔드포인트는 이제 동작하지 않습니다.

MWS에서 SP-API(Selling Partner API)로의 이전은, AWS IAM을 사용한 서명 인증(Signature Version 4)이 필수였던 시대에서, 훨씬 심플한 OAuth 방식 인증으로 바뀐 큰 전환점이었습니다. 지금의 SP-API 개발에서는, 당시 기사에 쓴 AWS 액세스 키·시크릿 키 취득 절차는 일절 불필요합니다.

기술 기사를 쓸 때의 교훈으로서도 은근히 중요한 이야기입니다. 「인증 방식」을 다루는 기사는, 서비스의 사양 변경으로 가장 먼저 진부화됩니다. 저희 과거 기사에서도, 인증 관련만은 주의 문구를 덧붙이도록 하고 있습니다.

당시의 설계: API 1개를 단발로 두드리기만

라쿠텐 API 기사도 MWS 기사도, 당시의 설계 사상은 공통되었습니다.

・원하는 정보를, 1회의 API 호출로 직접 가지러 간다

・레이트 제한은 특별히 의식하지 않고, 필요할 때 필요한 만큼 두드린다

・결과는 그 자리에서 확인하거나, 기껏해야 로그에 남기는 정도

이것은 당시의 용도(월에 수십 건, 수동으로 리서치할 상품을 확인하는 정도)에는 충분한 설계였습니다. 프로그램이라기보다 「브라우저로 클릭클릭 하는 작업을, 코드로 대체한」 정도의 위치였습니다.

지금의 설계: 비동기·레이트 제어·하한 보호의 3종 세트

현재, 저희가 운용하고 있는 Amazon FBM(자체 발송)의 리서치·가격 자동 조정 시스템은, 같은 「Amazon 상품 정보를 자동으로 가지러 간다」는 목적이라도, 구성이 완전히 다른 것이 되었습니다.

1. SQS를 끼워 비동기화한다

당시의 「필요할 때 직접 두드린다」에서, 「큐에 쌓아, Lambda가 순서대로 처리한다」는 구성으로 바뀌었습니다. SP-API에는 엄격한 레이트 제한이 있기 때문에, 직접 두드리는 설계로는 금방 429 에러(레이트 초과)에 부딪힙니다. SQS FIFO 큐를 끼움으로써, 처리 속도를 컨트롤하면서 대량의 ASIN을 처리할 수 있게 됩니다.

쇼에이샤 ／ Lambda·SQS 등 AWS 서비스를 조합한 구성의 기초를 배우고 싶은 분께. 이번 같은 비동기 처리 설계를 이해하는 토대가 되는 한 권.

2. 지수 백오프로 리트라이한다

그래도 429는 발생합니다. 당시라면 「에러가 나면 포기」로 끝났을 것을, 지금은 자동으로 리트라이하는 설계로 하고 있습니다. 고정된 대기 시간이 아니라, 실패할 때마다 대기 시간을 배로 늘리는 지수 백오프를 넣음으로써, 레이트 제한이 걸린 상황에서도 자동적으로 차분하게 재시도할 수 있습니다.

# 지수 백오프의 골격(실제로는 SP-API 호출 전반에 공통화하고 있음)
MAX_RETRIES = 10
wait = 2
for attempt in range(MAX_RETRIES):
    try:
        response = call_sp_api()
        return response
    except Exception as e:
        if attempt == MAX_RETRIES - 1:
            raise
        time.sleep(wait)
        wait = min(wait * 2, 60)

📚 관련 서적

▶ AWS運用入門改訂第2版 (AWS 운용 입문 개정 제2판)

쇼에이샤 ／ 움직이면 끝이 아니라 「계속 운용하기」 위한 요령을 정리한 한 권. 에러 대응이나 비용 관리의 사고방식이 실무에 직결.

3. 가격의 하한을 「망가뜨리지 않는」 설계로 한다

가격 자동 조정 기능을 만들 때, 가장 무서운 것은 「버그가 나서 한없이 가격 인하가 계속되는」 사고입니다. 당시 같은 단발 API 호출의 발상으로는, 이 대책을 뒤로 미루기 쉬웠습니다.

지금의 설계에서는, Amazon Listings Items API로 관리되고 있는 셀러 센트럴의 하한 가격(minimum_seller_allowed_price)을 그대로 참조하여, 새 가격은 반드시 하한 가격으로 클립한 후 업데이트하도록 하고 있습니다.

# 가격 업데이트 전에 반드시 하한으로 클립한다
new_price = calculate_new_price(competitor_price)
floor_price = get_listing_min_price(sku)  # Listings Items API에서 취득
final_price = max(new_price, floor_price)
update_price(sku, final_price)

하한 가격을 자체 DB에서 이중 관리하는 안도 검토했지만, 셀러 센트럴의 값과 어긋날 리스크를 피하기 위해, Amazon 측 데이터를 그대로 정답으로 쓰는 설계로 정착했습니다. 하한이 미설정인 SKU에는, 현재 가격의 10% 할인을 초기값으로 일괄 투입하고, 이후로는 프로그램 측에서 하한 자체를 변경하지 않는다는 규칙으로 하고 있습니다.

설계가 바뀐 이유는 「사고를 겪은 경험」

솔직히 말해, 이 3가지 변경은 어느 것도 「처음부터 보였던」 것은 아닙니다. DynamoDB 비용이 급증한 이야기나, SQS에 메시지가 33만 건 쌓인 이야기는, 이전에 이 블로그에서도 쓴 그대로입니다. 실제로 아픈 경험을 한 후에야, 설계에 손이 들어갔습니다.

돌이켜보면, 당시의 기사도 「그 시점에서는 옳은」 설계였습니다. 처리 건수가 월에 수십 건이라면, 단발 API 호출로 전혀 문제없습니다. 설계를 꼬이게 하는 가장 큰 요인은, 규모의 변화를 알아차리지 못하고 같은 만듦새를 끌고 가는 것이라고 생각합니다. 건수가 늘어나면 「비동기화」「레이트 제어」「하한 보호」의 3가지는, 이른 시기에 검토할 가치가 있습니다.

또 하나의 변화: 스크래핑에서 API로

당시의 기사에는 쓰지 않았지만, 이 몇 년 사이 또 하나 크게 바뀐 것이, 데이터 취득 수단 그 자체입니다. 예전에는 BeautifulSoup을 사용한 스크래핑으로 데이터를 취득하던 장면도, 지금은 SP-API나 Keepa의 API 등, 공식적으로 허가된 수단으로의 전환을 진행하고 있습니다.

스크래핑은 손쉬운 반면, 사이트 구조 변경으로 간단히 망가지고, Amazon 같은 플랫폼에서는 계정 정지 리스크도 따릅니다. 공식 API가 준비되어 있다면, 다소 수고가 들어도 그쪽을 쓰는 편이, 긴 안목으로 보면 운용 비용은 낮아집니다.

정리

2020년의 기사와 지금의 구현을 나란히 놓고, 바뀐 점을 정리하면 이 3가지입니다.

・단발의 직접 호출 → SQS를 끼운 비동기 처리

・에러 시에는 포기 → 지수 백오프로 자동 리트라이

・가격 보호 없음 → Amazon 측의 하한 가격을 반드시 참조하여 클립

기술 기사는 쓴 순간부터 진부화가 시작됩니다. 특히 인증 방식이나 요금 체계처럼 「서비스 측의 사정으로 바뀌는 부분」은, 몇 년 단위로 재검토가 필요합니다. 그렇다고 해도, 당시의 기사를 부끄럽게 여길 필요는 없어서, 「그 시점에서 최선이었던 설계의 기록」으로 남겨 두면, 이렇게 되돌아봤을 때 자신의 성장이 보이는 자료가 됩니다.

Amazon SP-API를 사용한 자동화 시스템의 설계·구축으로 곤란하실 때는, 로빈 플래닝 합동회사로 부담 없이 상담해 주세요. 레이트 제한 대응부터 가격 보호 구조까지, 실제로 사고를 겪으며 배운 노하우로 도와드립니다.