쿠팡 상품 검색 스킬이 검색어에 대해 제한 응답을 반환함

[kimmeoungjun]

요약

현재 coupang-product-search 스킬이 상품 검색 결과를 반환하지 못하고, 검색어와 무관하게 쿠팡 측 제한 응답으로 보이는 메시지를 그대로 반환하고 있습니다.

확인 일시: 2026-04-09

실제 호출 요청

1. MCP 세션 초기화

curl -s -D - -o /tmp/coupang_init_body.txt -X POST 'https://yuju777-coupang-mcp.hf.space/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"k-skill","version":"1.0"}}}'

응답 헤더에 mcp-session-id 가 내려왔고, 이 값은 본문에서 제외합니다.

2. 상품 검색 호출 (정리용품)

curl -s -X POST 'https://yuju777-coupang-mcp.hf.space/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Session-Id: REDACTED' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search_coupang_products","arguments":{"keyword":"정리용품"}}}'

3. 상품 검색 호출 (운동화)

curl -s -X POST 'https://yuju777-coupang-mcp.hf.space/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Session-Id: REDACTED' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search_coupang_products","arguments":{"keyword":"운동화"}}}'

실제 결과

두 검색어 모두 아래 응답이 반환되었습니다.

API 오류: 과도한 호출로 인한 비정상적인 행위가 누적되어 이용을 제한합니다. <br> 활동에 대한 소명자료를 AF ID와 함께 파트너스로 문의 바랍니다.

즉, 상품 목록이 아니라 제한 메시지만 내려오고 있습니다.

기대 결과

• 최소한 일부 상품 검색 결과가 정상 반환되어야 함
• 외부 coupang-mcp 또는 쿠팡 조회 경로가 막힌 상태라면, 현재 문서/스킬 사용자는 장애 상태를 이해할 수 있도록 더 명확한 안내가 필요함

메모

현재 확인한 범위에서는 이 저장소의 문서 사용 흐름대로 호출했을 때 동일 현상이 재현됩니다. 구조상 저장소 자체 로직 문제라기보다, 연결된 외부 coupang-mcp 서버 또는 그 하위 쿠팡 조회 경로가 제한된 상태일 가능성이 높아 보입니다.

[vkehfdl1]

• AI-understood issue summary

  • 문서에 명시된 https://yuju777-coupang-mcp.hf.space/mcp 경로로 2026-04-09(Asia/Seoul) 기준 직접 재현해 보니, search_coupang_products가 정리용품, 운동화 모두에 대해 동일한 제한 문구를 반환했습니다.
  • 현재 coupang-product-search/SKILL.md와 docs/features/coupang-product-search.md는 “MCP 서버가 응답하지 않으면/다운되면 재시도” 수준의 안내는 있지만, 상류 쿠팡 조회 경로가 제한 응답을 정상 결과처럼 돌려주는 경우에 대한 사용자 안내는 없습니다.
  • 따라서 현상은 저장소 내부 검색 로직 결함보다는 외부 coupang-mcp/하위 쿠팡 조회 경로의 차단 또는 rate-limit/abuse block 상태에 더 가깝지만, 이 저장소 차원에서도 장애 감지와 안내 보완은 필요합니다.

• Why this issue is needed

  • 지금 상태에서는 어떤 검색어를 넣어도 상품 목록 대신 동일한 제한 메시지가 내려와 기능이 사실상 unusable 합니다.
  • 게다가 MCP 응답의 isError가 실패가 아닌 성공처럼 보이기 때문에, 스킬 사용자 입장에서는 “검색 결과가 없는 것인지 / 외부 장애인지”를 구분하기 어렵습니다.
  • 문서와 스킬 응답 정책을 보강하면 실제 원인이 외부 의존성에 있더라도 사용자 혼란과 반복 문의를 줄일 수 있습니다.

• Why this issue may not be needed

  • 만약 upstream 차단이 일시적이고 곧 해소된다면, 영구적인 대체 구현까지는 과할 수 있습니다.
  • 또한 이 저장소가 coupang-mcp를 래핑하는 문서/스킬 계층이라면, 근본 수정은 외부 MCP 쪽에서 이뤄져야 할 수 있습니다.
  • 다만 그런 경우에도 최소한의 장애 감지/명시적 안내는 여전히 이 이슈 범위로 유효해 보입니다.

• Expected Outcome

  • 제한 응답이 오면 정상 상품 검색 결과처럼 보여주지 않고, 외부 의존성 장애/차단 상태임을 명확히 안내한다.
  • 스킬/문서 사용자가 재시도 필요 여부, upstream 문제 가능성, 대체 경로 부재 여부를 즉시 이해할 수 있다.
  • 가능하면 upstream 상태가 복구되었는지 확인 가능한 간단한 점검 절차도 함께 문서화된다.

• Concise implementation plan

  1. coupang-product-search/SKILL.md와 docs/features/coupang-product-search.md에 현재 알려진 장애 패턴(제한 문구)과 사용자-facing fallback 메시지를 추가한다.
  2. 제한 응답 문자열/패턴을 “정상 검색 결과 아님”으로 취급하도록 스킬 응답 가이드를 명시한다.
  3. 가능하면 coupang-mcp upstream 상태를 확인하고, 차단이 지속되면 issue/문서에 외부 의존성 장애임을 명시한다.
  4. 이후 upstream 복구 시 장애 공지를 제거하거나 축소한다.

• Agent Signature

[vkehfdl1]

실제 현재 쿠팡MCP https://yuju777-coupang-mcp.hf.space/mcp 가 block 당한 것인지 혹은 쿠팡 MCP 서버 자체를 직접 실행했을 때에도 블락이 발생하는지 검토 필요

[vkehfdl1]

추가 확인 결과를 남깁니다.

• 2026-04-10 (Asia/Seoul) 기준 https://yuju777-coupang-mcp.hf.space/mcp 는 MCP 세션 초기화 자체는 정상 동작했습니다. 즉, HF Space의 MCP transport/server-card 레벨이 완전히 죽은 상태는 아닙니다.
• 다만 같은 시점에 upstream coupang-mcp 저장소 구조를 보면, 공개 HF Space 배포는 Dockerfile -> http_server.py 를 실행하고, 이 http_server.py 는 기본적으로 COUPANG_API_SERVER=https://coupang-mcp.netlify.app/.netlify/functions/coupang 로 Netlify 함수를 호출하도록 되어 있습니다.
• 그래서 HF Space를 거치지 않고 Netlify 함수 URL을 직접 확인해 봤더니, 아래 세 경로가 모두 동일한 rCode: "403" 제한 메시지를 반환했습니다.
  • action=search&keyword=정리용품
  • action=best&category_id=1016
  • action=goldbox
• 즉, 현재 관찰상은 HF Space 인스턴스만 block 된 것이 아니라, HF Space 뒤의 실제 쿠팡 조회 경로(Netlify 함수/그 함수가 사용하는 Coupang affiliate credential 또는 그 하위 API 경로)가 막힌 상태로 보는 쪽이 더 타당합니다.

정리하면:

1. 공개 HF MCP endpoint 자체만의 문제라고 보긴 어려움
   HF의 initialize 는 살아 있고, HF가 내부적으로 위임하는 Netlify 함수도 동일하게 403 제한 응답을 반환합니다.

2. “쿠팡 MCP 서버 자체를 직접 실행”했을 때도 막히는지 여부는 어떤 실행 경로/어떤 키를 쓰느냐에 따라 달라짐

   • upstream의 현재 공개 배포 경로(http_server.py + 동일 Netlify/API credential)를 그대로 쓰면 사실상 같이 막힐 가능성이 높습니다.
   • 반대로 server.py 를 로컬에서 별도의 정상 Coupang affiliate key/secret 으로 직접 띄우는 케이스는 이번 저장소 범위에서는 재현 검증이 불가합니다. 그 키가 현재 block 되지 않았다면 동작할 수도 있고, 같은 계정/키가 이미 제재 상태라면 동일하게 막힐 것입니다.

3. 현재 이슈에서 우선 취할 수 있는 실무적 결론

   • 이 저장소 문서/스킬에는 “공개 coupang-mcp 경로 전체가 현재 제한 응답을 반환 중” 이라는 점을 분명히 적는 것이 필요합니다.
   • 동시에 upstream 쪽에는 Netlify 함수가 사용하는 credential/affiliate account 자체가 제재된 것인지 확인 요청이 필요해 보입니다.
   • 가능하면 별도 credential 로 server.py 직접 실행 테스트를 해 보면, “배포 경로 문제”인지 “계정/키 문제”인지 더 명확히 분리할 수 있습니다.

[vkehfdl1]

그러면 coupang mcp 경유 없이 자체 구현이 가능한지 알아봐줘

[vkehfdl1]

가능 여부만 먼저 정리하면, coupang-mcp 경유 없이 자체 구현은 기술적으로 가능해 보입니다. 다만 현재 저장소 정책/운영 모델로는 바로 public 대체 경로를 넣기 어렵고, 구현 방식에 따라 제약이 큽니다.

근거:

• upstream coupang-mcp 저장소에는 이미 server.py / netlify/functions/coupang.js 형태의 직접 Coupang Affiliate Open API 호출 코드가 있습니다. 즉 “쿠팡 검색 자체”는 MCP 프로토콜이 본질이 아니라, 결국 쿠팡 API를 감싼 래퍼입니다.
• 반면 이 저장소의 coupang-product-search 는 현재 문서 스킬만 있고 자체 백엔드는 없으며, scripts/skill-docs.test.js 도 coupang-mcp 참조를 사실상 고정하고 있습니다.
• 또 이 저장소의 k-skill-proxy 운영 원칙은 free APIs only / public read-only / no proxy auth by default 라서, 쿠팡처럼 credential 이 필요한 제휴 API 를 기본 공개 프록시에 얹는 것은 현재 정책과 잘 맞지 않습니다.

그래서 현실적인 선택지는 3가지 정도로 보입니다.

1. 자체 구현 + 자체 credential (가장 현실적)

   • 우리 쪽에서 별도 Coupang affiliate key/secret 을 가지고 직접 호출하는 작은 서버/MCP를 운영
   • 장점: 외부 공개 yuju777-coupang-mcp 장애와 분리 가능
   • 단점: 키 관리 필요, 계정/키가 block 되면 동일 문제 재발 가능
   • 결론: 가능은 하지만 “API 키 불필요” 모델은 포기해야 함

2. k-skill-proxy 안으로 직접 흡수

   • 구현 자체는 가능하지만, 현재 repo 정책상 free API 전용 프록시에 credential 기반 Coupang API 를 넣는 건 정책 변경 또는 예외 승인 성격이 강함
   • 그래서 지금 구조에서는 바로 추천하기 어렵습니다.

3. 비공식 스크래핑/브라우저 기반 우회

   • 기술적으로 시도는 가능하겠지만, 안정성/차단 리스크/운영 부담이 커서 issue 대응 방향으로는 비추천입니다.

따라서 제 판단은:

• “가능하냐” → 예, 가능
• “현재 k-skill 구조에서 그대로 대체 가능하냐” → 아니오, 설계 전환이 필요

만약 이 이슈를 계기로 대체 구현까지 검토한다면, 가장 깔끔한 방향은 아래 같습니다.

• 1단계: 현재 스킬/문서에 public coupang-mcp 장애 공지와 fallback 안내 추가
• 2단계: coupang-product-search 를 외부 public MCP 의존에서 self-hosted backend or BYO credential backend 로 재설계할지 결정
• 3단계: 결정 시 scripts/skill-docs.test.js 의 coupang-mcp 고정 assertion 도 함께 수정

즉, 이번 follow-up의 답은 “coupang-mcp 없이 자체 구현은 가능하지만, 그 경우 이 저장소는 public free-proxy 모델이 아니라 별도 credential 기반 backend 모델로 바뀌어야 한다” 쪽입니다.