OMS의 쇼핑몰 API 변경 검토, Claude Cowork 스킬로 자동화하기

도입

내가 현재 개발·운영하고 있는 서비스는 OMS(Order Management System)로 여러 쇼핑몰의 주문을 한곳으로 모으고, 상품·배송·취소·반품 같은 업무를 통합해서 처리할 수 있도록 돕는다.

현재 우리 서비스는 네이버, 쿠팡, SSG, 카카오, 11번가, 지마켓을 비롯한 다수의 쇼핑몰과 오픈마켓에 연동되어 있다. 연동 채널이 많을수록 고객이 관리하기는 편해지지만, 개발팀이 계속 살펴봐야 할 외부 변화도 함께 늘어난다.

쇼핑몰은 API와 운영 정책을 수시로 바꾼다.

• 기존 API 종료 또는 신규 버전 전환
• 요청 필수 필드 추가
• 코드값(enum) 변경
• 응답 구조 변경

이런 변경을 놓치면 주문 수집이나 상품·배송 상태 연동에 문제가 생길 수 있기 때문에 변경 공지를 수시로 확인하고, 연동 코드에 영향이 있는지 판단하는 일이 필요하다.

문제는 공지 전달 방식이 쇼핑몰마다 다르다는 점이었다.
어떤 쇼핑몰은 변경 내용을 메일로 보내지만, 어떤 쇼핑몰은 개발자센터 공지사항이나 릴리즈노트에만 등록한다. 즉, 담당자가 메일도 확인하고 여러 사이트를 직접 찾아다니며 새 공지가 있는지 확인해야 했다.

이번에 자동화한 것은 바로 이 과정이다.

흩어진 쇼핑몰 변경 공지를 수집하고, OMS 연동 코드에 미치는 영향까지 확인한다.

기존에는 어떻게 확인했나

기존 업무는 다음과 같은 순서로 진행됐다.

메일로 도착한 변경 안내 확인 및 쇼핑몰별 공지사항·릴리즈노트 직접 방문
  → 연동과 관련된 변경인지 판단
  → 우리 OMS가 해당 API를 사용하는지 코드 검색
  → 대응이 필요한 위치와 내용을 정리

단순히 공지를 읽는 것으로 끝나지 않는다.
예를 들어 반품 접수 API에 필수 필드가 추가된다는 공지가 올라오면, 우리 서비스가 그 API를 실제로 호출하는지, 어느 코드에서 요청을 만드는지까지 찾아야 비로소 영향 여부를 알 수 있다.

이 방식에는 세 가지 문제가 있었다.

1. 공지가 여러 곳에 흩어져 있다

메일로 오는 공지는 메일함에서 확인할 수 있지만, 공지사항에만 올라오는 변경은 담당자가 직접 찾아야 한다. 확인할 쇼핑몰이 늘어날수록 방문해야 할 사이트도 함께 늘어난다.

2. 확인해야 할 공지는 많고, 실제 영향 건은 적다

이벤트, 프로모션, 시스템 점검처럼 연동 코드와 무관한 공지도 많다. 관련 없는 내용인지 알기 위해서라도 사람이 먼저 열어보고 분류해야 했다.

3. 영향 판단에는 코드 검색이 필요하다

API 변경 공지를 찾은 뒤에는 연동 레포에서 사용 여부와 위치를 다시 확인해야 한다. 이 과정을 놓치거나 늦게 처리하면 주문·상품 연동 장애로 이어질 수 있다.

결국 사람이 많은 시간을 쓴 곳은 최종 판단보다 판단해야 할 공지를 찾고, 관련 코드를 대조하는 과정이었다.

무엇을 자동화했나

Claude Cowork 스킬은 변경 공지 확인부터 코드 영향 점검까지 네 단계로 수행한다.

1단계 — 공지 수집

메일로 수신한 변경 안내와 주요 쇼핑몰의 개발자센터 공지사항·릴리즈노트를 정해진 기간 기준으로 수집한다. 각 쇼핑몰마다 공지가 올라오는 위치가 다르기 때문에, 스킬에 점검 대상과 수집 경로를 명시했다.

2단계 — 연동 영향 공지 선별

수집한 공지 중 연동에 영향을 줄 수 있는 변경만 남긴다.

• 엔드포인트 종료와 버전 전환
• 요청 필수 필드 추가·변경
• 코드값 변경
• 응답 필드와 구조 변경

이벤트나 프로모션, 일반 시스템 점검 안내처럼 연동 코드와 무관한 공지는 제외한다.

3단계 — OMS 연동 코드 대조

선별한 공지의 API 경로, 필드명, 코드값 등을 기준으로 연동 레포를 검색한다. 우리 OMS가 해당 API를 실제로 사용하는지 확인하고, 영향 가능성이 있는 파일과 위치를 찾는다.

4단계 — 점검 리포트 작성

결과를 다음 네 가지로 분류한다.

• 영향 — 현재 코드에서 해당 API를 사용하며 대응이 필요한 경우
• 영향 가능성 — 사용 중이지만 추가 판단이 필요한 경우
• 확인 불가 — 공지 내용만으로 결론을 내릴 수 없는 경우
• 스킵 — 연동과 무관해 제외한 경우

이 자동화에서 가장 중요한 원칙은 추측하지 않는 것이다.
영향 여부를 확정할 근거가 부족하면 괜찮을 것이라고 넘기지 않고 확인 불가로 분리한다. 그래야 담당자가 추가로 확인해야 할 항목이 명확해지고, 리포트 전체를 다시 검증하는 일을 줄일 수 있다.

리포트는 무엇을 보여주나

리포트의 목적은 공지를 요약하는 데 있지 않다.
담당자가 어떤 변경에 대응해야 하고, 코드를 어디서 확인해야 하는지 바로 알 수 있어야 한다.

공지 기반 연동 점검 리포트
기간 2026-06-13 ~ 2026-07-13

대상 5개 몰 | 신규 공지 18 | 영향 3 | 영향 가능성 2 | 확인 불가 1

[영향] [쿠팡] 반품접수 API 필수 필드 추가
· 변경      claimType 필드 필수화
· 우리 사용  사용함 — <반품 처리 서비스>:214
· 점검      요청 데이터에 claimType 전송 로직 추가 필요

[영향] [SSG] 취소신청 목록조회 API v2 전환
· 우리 사용  사용함 — <취소 조회 서비스>:88
· 점검      종료 일정 전 v2 엔드포인트 전환 필요

[영향 가능성] [네이버] 정산 응답 구조 변경
· 사유      응답 필드 재편에 따른 파싱 영향 추가 확인 필요

스킵 13건 — 이벤트·시스템 점검 등 연동과 무관한 공지

위 내용은 리포트 형식을 설명하기 위한 예시다.

실제 리포트에는 공지 출처와 변경 내용, 사용 여부, 확인할 파일과 위치, 필요한 대응 방향을 담는다. 코드 본문이나 인증 정보는 포함하지 않는다.

스킵 건수도 함께 남긴다. 결과에 영향 건만 있으면 전체 공지를 제대로 확인한 것인지 알기 어렵다. 제외한 건수를 보여주면 누락한 것이 아니라 확인 후 제외했다는 사실을 알 수 있다.

자동화의 범위

이번 자동화는 공지를 찾고 영향 가능성이 있는 코드를 알려주는 데까지만 담당한다.

코드는 읽기 전용으로 검색하며, 자동으로 수정하거나 커밋하지 않는다. 공지와 코드만으로 판단할 수 없는 내용도 사람이 확인하도록 남겨둔다.

OMS의 주문·배송·정산 연동은 잘못 수정했을 때 영향이 크다. 그래서 반복적인 확인과 대조는 자동화하되, 실제 변경에 대한 결정과 수정은 사람이 담당하도록 범위를 나눴다.

자동화 전후의 변화

가장 큰 변화는 단순한 시간 절감보다 사람이 업무를 시작하는 지점이 달라졌다는 것이다.
이전에는 새 공지가 있는지 찾는 일부터 시작했다면, 이제는 정리된 영향 후보를 보고 대응 여부를 판단하는 일부터 시작한다.

남은 과제

• 쇼핑몰별 공지 형식과 수집 경로를 정리해 점검 대상을 확대한다.
• 자동 실행과 담당자 알림을 연결해 확인 주기를 안정화한다.
• 누락과 오분류를 기록해 자동화 정확도를 측정한다.
• 리포트 이력을 쌓아 쇼핑몰별 변경 빈도와 대응 내역을 관리한다.

다수의 연동 쇼핑몰을 한 번에 모두 자동화하기보다, 주요 쇼핑몰부터 정확도를 확인하며 단계적으로 확대할 계획이다.

마치며

이번에 자동화한 핵심은 쇼핑몰의 변경 자체가 아니라, 변경사항을 찾아 우리 OMS에 미치는 영향을 검토하는 과정이다.

여러 외부 쇼핑몰과 연결되는 OMS에서는 API 변경을 피할 수 없다. 하지만 메일함과 공지사항을 돌아다니며 변경을 찾고, 관련 코드를 반복해서 검색하는 일까지 계속 사람이 할 필요는 없다.

공지는 AI가 모으고, 연동 영향 후보도 AI가 대조한다.
사람은 근거가 정리된 결과를 바탕으로 결정하고 수정한다.

확인과 대조는 자동화하고, 결정은 사람에게 남기는 것.
이번 자동화에서 정한 가장 중요한 기준이다.

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