ConnectWiz + WooCommerce
운영 중인 연동양방향 WooCommerce 동기화, 소유권 계약과 함께
대부분의 “Woo 연동”은 가져오기 버튼 하나와 기도로 이루어져 있습니다. 이쪽은 통제되는 양방향 동기화입니다. 데이터 영역마다 어느 시스템이 진실을 소유할지 직접 정하고, 충돌은 조용히 덮어쓰이는 대신 전부 원장에 남습니다.
이커머스
하는 일, 정확히
클릭 한 번으로 연결
표준 WooCommerce 인증 절차가 API 키와 Webhook을 자동으로 발급하고 등록합니다. 키를 복사해 옮기는 의식도, Webhook 체크리스트도 없습니다.
깊이 있는 가져오기
이미지, 카테고리 트리, 정가와 할인가 및 그 적용 기간, GTIN, 태그, 업셀과 크로스셀, 변형별 가격과 이미지까지. 카탈로그가 이름과 가격만 남은 뼈대가 아니라 통째로 들어옵니다.
진짜 역방향 기록
여기서 한 상품 수정이 Woo로 되돌아갈 수 있습니다. 작업별 스위치로 통제하고 예행연습 모드가 붙어 있어서, 무엇이 바뀔지 실제로 바뀌기 전에 볼 수 있습니다.
필드 단위 소유권
영역별로 직접 고르시면 됩니다. 데이터가 Woo에 살지, 여기에 살지, 양방향으로 동기화될지요. 다른 쪽이 소유한 필드는 이유를 화면에 적은 채 읽기 전용으로 표시됩니다. 주인이 둘이라 생기는 난장판은 없습니다.
충돌 원장
실패했거나 충돌한 동기화는 눈에 보이는 원장에 쌓이고, 거기서 해결하고 재시도합니다. 재고 실사 때가 되어서야 발견하는 조용한 덮어쓰기는 없습니다.
주문도 같은 흐름으로
Woo 주문은 출처가 표시된 채로, 채팅 상점·AI·API에서 들어온 주문 옆에 나란히 나타납니다. 표면은 여럿이어도 주문의 진실은 하나입니다.
기술적인 구조
대부분의 연동이 건너뛰는 동기화 엔지니어링
지나칠 만큼 꼼꼼한 연결 핸드셰이크
연결 링크는 15분 뒤 만료됩니다. 콜백은 다른 어떤 처리보다 먼저 사용 완료로 표시하므로, 오래된 자격 증명으로 재전송될 수 없습니다. 그리고 실제로 쓰는 상점 URL은 직접 입력하신 주소이지, 콜백이 주장하는 주소가 아닙니다.
재시도에 견디도록 설계했습니다
Woo는 재시도할 때마다 전송 ID를 새로 매깁니다. 그래서 중복 제거는 그 ID를 일부러 무시하고 메시지 내용을 기준으로 삼습니다. 나가는 쪽에서는 멱등 키를 주문 자체의 메타데이터에 실어 보내고 검색으로 다시 찾습니다. 위험한 경우는 쓰기는 성공했는데 응답이 사라진 상황이기 때문입니다.
관계는 두 번째 패스에서
업셀과 크로스셀은 아직 존재하지 않을 수도 있는 상품을 가리키는 상점 ID로 들어옵니다. 그래서 카탈로그가 다 들어온 뒤 두 번째 패스에서 풉니다. 카테고리 트리는 따로 가져옵니다. 상품 페이로드는 말단 카테고리 이름만 알려 주기 때문입니다.
통화는 한 번, 정확하게 읽습니다
Woo는 통화를 주문 단위로만 알려 주고 상품 단위로는 알려 주지 않습니다. 그래서 카탈로그를 가져오기 전에 상점 설정에서 상점 통화를 한 번 읽습니다. 행마다 추측하지 않습니다.
보수적인 상태 매핑
이행 상태 전송은 두 쪽 용어가 진짜로 일치하는 경우에만 매핑합니다. “반품” 주문을 억지로 옮기지 않고, 대신 주문 메모로 사람에게 전달합니다. 상태 메모는 고객 알림을 끈 채로 등록하므로, Woo가 고객에게 메일을 두 번 보내지 않습니다.
직접 입력한 값이 이깁니다
여기서 사람이 손으로 고친 필드는 가져오기가 덮어쓰지 않습니다. 동기화는 사람을 존중하며, 항목마다 출처 카드에 그 사실을 적어 둡니다.
설정
연결 방식
상점 연결
연결을 누르고 WooCommerce 관리자에서 승인하면, 키와 Webhook이 알아서 등록됩니다.
소유권 선택
데이터 영역마다 진실의 주인을 고르세요. Woo, ConnectWiz, 아니면 양방향입니다.
예행연습 후 실행
역방향 기록 작업을 먼저 예행연습 모드로 돌려 보고, 차이가 맞다 싶으면 실제 실행으로 바꾸세요.
함께 쓰면 강해집니다
함께 쓰는 기능
WordPress 플러그인
로그인한 Woo 고객을 채팅에 자동으로 로그인시키는 것은 플러그인 쪽입니다. 동기화가 이미 알고 있는 바로 그 사람이고, 주문도 함께 붙어 있으며, 다시 가입할 필요가 없습니다.
상품 피드
가져온 카탈로그를 Google Shopping / Meta Commerce 피드로 게시할 수 있습니다. 변형 하나당 한 행, 건너뛴 항목은 이유와 함께 솔직하게, 지어낸 환율 변환은 없습니다. 자세한 내용은 Commerce.
Wiz와 플로우
AI는 “제 주문 어디쯤인가요?”라는 질문에 실시간 상점 데이터로 답하고, 플로우 쪽에서는 커머스 이벤트에 반응할 수 있습니다. 동기화는 나머지 전부가 딛고 서는 바닥입니다.
보안과 보증
지루한 보증
키는 발급받지, 붙여 넣지 않습니다
wc-auth 절차를 통해 상점이 서버 대 서버로 키를 건네줍니다. 저장 시 암호화하고, 사람이 흘릴 만한 복사·붙여넣기 의식이 없습니다.
모든 Webhook을 검증합니다
수신 전송은 상점마다 따로 발급한 시크릿으로 HMAC 서명되고, 비교는 상수 시간으로 합니다. 위조된 “상품 업데이트”는 문 앞에서 튕겨 나갑니다.
상점에 예의를 지킵니다
검증은 됐지만 처리 대상이 아닌 전송에도 성공으로 답합니다. Woo가 연속 5회 실패하면 Webhook을 꺼 버리기 때문입니다. 상점이 저희를 포기하게 두느니 저희가 이상한 것들을 흡수합니다.
SSRF를 막는 외부 요청
상점 URL로 나가는 모든 호출이 외부 요청 가드를 통과합니다. 악의적인 “상점 주소”로 내부 네트워크를 탐색할 수 없습니다.
솔직한 세부 조건
경계를 명시합니다
결제 처리는 하지 않습니다
주문은 동기화하지만, 카드 청구는 상점과 결제 사업자의 몫으로 남습니다. 아닌 척하다가 어설픈 반쪽짜리 은행이 되는 플랫폼을 여럿 봤습니다.
미디어도 소유권을 따릅니다
Woo가 콘텐츠 필드를 소유하는 영역에서는 여기서 읽기 전용입니다. 설계가 그렇습니다. 소유권 계약의 요점은 그 계약이 저희도 묶는다는 것이니까요.
상품 2,000개 상한
가져오기 한 번에 상품 2,000개까지 옮깁니다. 미리 밝혀 둔 엔지니어링 한계입니다. 그보다 큰 카탈로그는 조용히 타임아웃되게 두는 대신 솔직하게 확장 이야기를 나누는 편을 택합니다.
주문은 읽을 뿐, 복사하지 않습니다
상점 주문은 두 번째 원장으로 복제되는 대신 연락처에서 실시간으로 보입니다(1분 캐시, 최근 10건). 진실의 출처를 하나로 두려고 일부러 내린 결정이고, 여기 적어 둡니다.