카테고리 없음

EC-모니터의기능 및 특징, 효과 등에 관한 설명자료

JLAND1 2022. 6. 24. 17:56

쇼핑몰 연동 기술 비교

EC-모니터란?

(주)에이치케이넷츠의 쇼핑몰 솔루션인 EC-모니터의
기능 및 특징, 효과 등에 관한 설명자료입니다.

 

EC-모니터란?쇼핑몰 연동 기술 비교
솔루션을 선택할 때에는 기능과 성능, 신뢰성, 편의성 등 여러가지를 고려해야 합니다.
그러나 연동 솔루션이라면 역시 가장 기본은 연동 기능일 것입니다.
따라서 여기에서는 연동 기술의 차이점에 대해 중점적으로 설명합니다.

아래의 내용은 이론적으로나 실제로 검증된 내용을 바탕으로 한 사실이며,
만약 다른 의견이 있다면 얼마든지 이야기해 주세요.
기술적으로 논리적으로 그리고 더 구체적으로 설명해 드리겠습니다.

※ 파트너, 헬프, SCM 등 쇼핑몰마다 용어가 다르지만 여기에서는 어드민이라고 통칭합니다.

Ⅰ. 쇼핑몰 연동 기술 비교

  1. 쇼핑몰 어드민의 특징

    쇼핑몰 어드민 특히 상품등록이나 수정화면은 입력해야 할 항목도 많지만
    • 카테고리 등에 따라 입력 항목이 달라질 뿐만 아니라
    • 어떤 항목을 선택하면 다른 항목이 활성화되거나 비활성화되고
    • 어떤 항목을 입력하면 다른 항목이 자동으로 변경되는 등
    매우 복잡한 구조를 가지고 있습니다.
    또한 업체마다 계약 조건, 권한, 마진 등이 다르고 입력 항목이 다르기도 합니다.

    이런 동작은 일반적으로 어드민 페이지의 자바스크립트가 처리하는데
    실제 어드민 페이지 내용을 보면 화면을 구성하는 HTML보다
    이런 동작을 컨트롤하는 자바스크립트 내용이 훨씬 많음을 알 수 있고,
    화면 구성 조차도 HTML보다는 자바스크립트가 더 많은 부분을 담당하고 있습니다.

    상품등록이나 수정 화면의 자바스크립트의 내용을 보면
    if, switch 등 조건에 따라 다르게 동작하는 분기문이 수백, 수천개가 존재하는데
    이는 곧 최소 수백, 수천 가지 경우의 수가 존재한다는 의미이며
    이를 조합하면 이보다 훨씬 많은 경우의 수가 존재함을 알 수 있습니다.

    아울러 예전에는 자바스크립 구조가 간단해서 어느 정도 분석이 가능했지만
    지금은 jQuery, WebSquare, Angular 등 새로운 기술들이 적용된 페이지들은
    자바스크립트 구조가 매우 복잡하여 분석하기 조차 어렵게 되어 있습니다.

    사용자가 어드민에서 상품등록이나 수정을 하면
    • 사용자가 화면을 열면 기본적으로 HTML에 의해 화면이 구성되지만
      이후 자바스크립트가 다수의 URL을 호출하면서 화면 데이타를 구성하고,
      업체 ID나 권한 등 여러가지 조건에 맞게 화면을 구성합니다.
      특히 수정의 경우에는 상황에 맞게 기존 상품 내용을 화면에 로드합니다.
    • 선택 항목은 선택 값이 제한되어 있고, 비활성화된 항목은 입력할 수 없는 등
      화면에 의해 입력할 수 있는 데이타가 제어됩니다.
    • 사용자가 값을 입력하거나 선택하거나 버튼을 클릭할 때마다
      어드민 자바스크립트가 다른 항목들을 자동으로 설정하거나 화면을 제어합니다.
    • 사용자가 저장 버튼을 클릭하면 자바스크립트가 데이타를 검증한 후 서버로 전송합니다.

    즉, 사용자는 화면에 보이는대로 값을 입력하거나 선택하기만 하지만
    실제로 내부적으로는 자바스크립트가 매우 복잡한 작업을 처리하고 있습니다.

    오픈API도 복잡하기는 마찬가지입니다.
    오픈API 내에도 어드민처럼 최소 수백, 수천가지 경우의 수가 존재할 수 밖에 없습니다.
    만약 어드민은 복잡한데 어드민을 대체하는 오픈API는 간단하다면
    그 이유는 오픈API가 부실하거나 쓸데 없이 어드민을 복잡하게 만들었거나 둘 중 하나입니다.

  2. 쇼핑몰 연동 기술

    타 솔루션들은 스크래핑이나 오픈API를, EC-모니터는 웹러닝 기술을 사용합니다.

    • 스크래핑
      어드민 화면의 HTML을 분석하여 분석 결과에 따라
      연동 프로그램에서 인위적으로 데이타를 만들어서 서버에 전송하는 방식
      문제가 많은 방식이라는 사실은 이미 잘 알려져 있습니다.

      [사전적 정의]에서 보듯이 웹에서 데이타를 추출하기 위해 사용하는 기술로써
      아주 간단한 경우 이외에는 데이타를 등록하는 용도로는 부적합한 기술입니다.

    • 오픈API
      쇼핑몰에서 제공하는 스펙에 따라
      연동 프로그램에서 인위적으로 데이타를 만들어 서버에 전송하는 방식
      얼핏 보면 체계적이고 정확할 것 같지만
      실제로는 스펙이 존재한다는 점을 제외하면 스크래핑과 다를 바 없는 기술이며,
      오히려 스크래핑보다 오류도 더 많고, 업데이트도 느린 기술입니다.

      [사전적 정의]에서 보듯이 지도 등 간단한 인터페이스를 제공하는 기술로써
      역시 아래와 같은 이유로 쇼핑몰 상품등록이나 수정에는 부적합한 기술입니다.
      쇼핑몰 상품등록이나 수정은 API라기 보다는 어플리케이션이라고 할 만큼 방대합니다.

    • 웹러닝(Web Running)
      EC-모니터만의 독자적인 방식으로 사람이 작업하는 것과 똑같이
      백그라운드에서 어드민 화면을 열어서 자동으로 정보를 입력하고 버튼을 클릭하면
      어드민의 자바스크립트가 자동으로 처리하고, 검증한 후 서버로 전송하는 기술
      이미 잘 알려진 바와 같이 정확성, 신뢰성, 무결성이 검증된 기술입니다.

  3. 연동 기술의 근본적인 차이

    스크래핑이나 오픈API와 웹러닝(Web Running)과의 가장 근본적인 차이는
    누가 데이타를 만들어서 전송하느냐?”입니다.

    스크래핑과 오픈API의 공통점은
    연동 프로그램에서 데이타를 만들어서 쇼핑몰 서버로 전송한다는 점입니다.
    따라서 정확한 데이타를 전송하기 위해서는
    연동 프로그램 개발자가 화면의 내용 뿐만 아니라 자바스크립트의 동작을 하나 하나 모두 분석해서
    각각의 경우에 맞게 데이타를 만들도록 프로그램을 개발해야 합니다.
    그러나
    • 경우의 수가 너무 많아 모든 경우를 정확하게 분석한다는 것은 불가능하기 때문에
      데이타를 잘못 만들 가능성이 매우 높을 뿐만 아니라
      별도의 검증 장치도 없기 때문에 잘못된 데이타가 그대로 서버로 전송됩니다.
      이런 방식에서 오류가 발생하지 않는다면 이 것이 오히려 이상한 일일 것입니다.
    • 분석해야 할 내용도 많기 때문에 업데이트도 느립니다.

    웹러닝에서는
    쇼핑몰 어드민 화면에서 데이타를 만들어서 쇼핑몰 서버로 전송합니다.
    [웹러닝 동작 화면 샘플 
    ]
    즉, 사용자가 어드민에서 상품을 등록하거나 수정할 때와 마찬가지로
    EC-모니터가 어드민 화면을 열고, 데이타를 입력하거나 선택하고, 버튼을 클릭하면
    나머지는 어드민의 자바스크립트가 자동으로 처리하고, 검증한 후 서버로 데이타를 전송합니다.
    당사는 어드민 내부의 자바스크립트가 어떻게 동작하는지 분석할 필요도 없습니다.
    따라서
    • 항상 정확한 데이타가 서버로 전송될 수 밖에 없습니다.
      설령 쇼핑몰이 변경되었는데 미처 업데이트하지 못했거나 개발자의 실수가 있다 하더라도
      입력 중에 오류가 발생하거나 자바스크립트가 경고창을 띄우고, 전송하지 않기 때문에
      어떠한 경우에도 잘못된 데이타가 서버로 전송되는 일은 발생할 수 없습니다.
    • 화면 어디에 어떤 값을 입력해야 하는지 정도만 분석하면 충분하기 때문에
      분석해야 할 내용도 적고, 업데이트도 매우 빠릅니다.
  4. 스크래핑과 오픈API의 오류

    실제로 스크래핑이나 오픈API 연동 솔루션에서는 여러 가지 오류들이 발생합니다.

    • 카테고리가 변경되었는데 이전 카테고리가 입력되기도 하고,
    • 어드민에 마진이 고정되어 있는데 마진이 다르게 입력되기도 하고,
    • 어드민에서는 배송방법을 택배를 선택해야 택배사를 선택할 수 있는데
      배송방법이 택배가 아닌데도 택배사가 입력된 상태로 전송되기도 하고,
    • 어드민에서는 비활성화되거나 보이지 않는 항목인데 데이타가 전송되기도 하고,
    • 어드민에서는 아예 존재하지도 않는 데이타가 전송되기도 하는 등
    어드민에서는 도저히 입력될 수 없는 값들이 입력되는 경우가 허다합니다.

    물론 잘못 전송되는 항목도 그때 그때 다르고, 입력되는 값도 제각각이며
    어떤 때에는 정상이었다가 어떤 때에는 오류가 발생하는 등 예측하기도 어렵습니다.

    오류가 발생하면 쇼핑몰에서 당사에 확인을 요청하는 경우가 있어
    지금까지 당사가 들어서 알고 있는 오류만 해도 수백건 이상이지만
    다음과 같이 당사가 알고 있는 것보다 훨씬 많은 오류가 있었을 것으로 추정됩니다.

    • 이런 오류들이 발생했을 때
      -쇼핑몰에서 다른 업체에 먼저 확인하는 경우도 많을테고,
      -EC-모니터의 웹러닝 기술에 대해 잘 알고 있는 쇼핑몰은
       EC-모니터는 이런 오류가 발생할 수 없다는 점을 잘 알기 때문에
       오류가 발생해도 아예 당사에 물어보지 않기 때문입니다.
      실제로 당사에 몇번 오류를 확인했던 쇼핑몰은 그 이후에는 연락이 없지만
      나중에 물어보면 여전히 오류가 발생하고 있다고 합니다.
    • 어쨋든 오류가 발견되면 상품을 수정하든 아예 상품을 내리든
      어떻게든 대책을 세울 수 있을테니 그나마 다행이라 할 수 있겠지만
      대부분의 오류들은 눈에 보이는 증상이 나타나기 전까지는 발견하기도 어려워
      미처 발견되지 않고 넘어가는 오류들도 많이 있을 것이라고 추측됩니다.
      실제로 이상한 증상이 발견되어 쇼핑몰에서 오류를 추적하다 보면
      예전에도 비슷한 오류가 있었다는 사실을 발견하는 경우도 있다고 합니다.

    스크래핑이나 오픈API 오류는 비단 어제, 오늘의 일이 아닌데
    이는 결코 지금까지 쇼핑몰이나 연동 업체가 노력을 등한히 했기 때문이 아닙니다.
    - 프로그램에서 인위적으로 데이타를 만들어서 전송하는 방식이고,
    - 검증 장치가 없어 잘못된 데이타도 그대로 쇼핑몰로 전송된다는
    구조적인 한계로 인해
    쇼핑몰이나 연동 업체가 아무리 노력한다고 해도 피할 수 없는 현상입니다.
    - 설령 오픈API를 개발한 쇼핑몰 개발자가 연동을 한다 해도
    - 혹은 뛰어난 개발자 수백명이 연동 작업에만 전념한다 해도
    정도의 차이가 있을 뿐 오류는 발생할 수 밖에 없습니다.
    하물며 1~20명의 개발자가 100개 이상의 쇼핑몰을 연동한다면 어떻게 될까요?

  5. 스크래핑과 오픈API의 문제점

    앞에서 설명한 기술적인 한계로 인해 다음과 같은 여러 가지 문제가 존재합니다.

    • 상품 등록
      등록 후 쇼핑몰에서 일일이 확인하고 수정해야 합니다.
      제대로 노출되지 않거나 잘못된 상품정보가 노출되는 경우가 많아
      정상적으로 매출이 발생하지 않고, 제품에 대한 신뢰도가 하락합니다.

    • 상품 수정
      우선 기존 상품정보를 분석한 후 필요한 정보를 수정하고, 전송해야 하는데
      정확하게 분석하기 어렵기 때문에 오히려 기존 상품정보마저 잘못될 수 있습니다.

      다른 솔루션을 사용하던 모 업체 이야기에 따르면
      수정이 된다고 해서 돌렸다가 다른 정보마저 엉망이 돼서
      그 다음부터는 무서워서 상품정보 수정은 아예 어드민에서 직접 했다고 합니다.

      아울러 등록은 한번이지만 수정은 상품정보가 변경될 때마다 수시로 해야 하는데
      이 때마다 어드민에서 확인해야 한다면 아무런 의미가 없습니다.
      차라리 이 업체처럼 어드민에서 처리하는 편이 훨씬 빠르고, 정확합니다.

      결론적으로 극히 일부 쇼핑몰 이외에는 품절조차 지원하지 못하기 때문에
      일일이 쇼핑몰 어드민에서 하나하나 검색해서 수정해야 합니다.

    • 업데이트
      업데이트에 많은 시간이 소요되어 서비스가 중단되는 경우가 자주 발생합니다.
      타 솔루션 업체 공지사항을 보면 사소한 업데이트에도 며칠씩 소요되기도 하고,
      어드민이 개편되기라도 하면 1개월 이상씩 서비스가 되지 않는 경우도 많습니다.

    • 등록 및 수정 속도
      화면을 열지 않기 때문에 등록이나 수정 속도가 빠릅니다.
      그러나 어드민에서 일일이 확인해야 하기 때문에 결과적으로 빠르다고 할 수는 없습니다.

    쇼핑몰 입장에서도

    • 잘못된 데이타로 인해 시스템에 오류가 발생하고, 서버 부하가 크게 증가합니다.
    • 오류 원인을 찾고 해결하기 위해 많은 시간과 비용이 소요됩니다.
      실제로 쇼핑몰 개발자들이 며칠밤을 새며 원인을 찾았다는 이야기도 여러번 들었습니다.
    • 이런 오류가 단순히 해당 솔루션을 사용하는 업체의 문제에 그치지 않고,
      쇼핑몰 시스템에 심각한 오류와 과도한 서버 부하를 유발시켜
      쇼핑몰은 물론 어드민에서 직접 작업하는 업체들마저 피해를 보게 됩니다.
    • 쇼핑몰에 어떤 문제를 일으킬지 예측할 수 없기 때문에 자칫 대형 사고로 이어질 수 있습니다.
    • 부정확한 상품정보 노출로 인해 쇼핑몰의 신뢰도가 하락합니다.
    • 업데이트가 늦다 보니 해당 솔루션 사용 업체의 신상품 등록이 지연됩니다.
  6. 웹러닝의 장점

    • 상품등록
      정확하기 때문에 등록 후 어드민에서 확인할 필요가 없습니다.
      반려 없이 바로 승인되기 때문에 신상품 노출도 빨라지고,
      정확한 상품 정보 노출로 제품의 신뢰도가 증가하고, 매출이 증가합니다.

    • 상품 수정
      품절, 재고, 가격 수정은 물론 상품명, 이미지, 상세설명, 고시정보와
      기타 거의 모든 정보를 자동으로 정확하게 수정합니다.
      정확한 품절과 재고 수정으로 품절 사고가 크게 감소할 뿐만 아니라
      품절 걱정 없이 더 많은 쇼핑몰에 더 많은 상품을 등록할 수 있습니다.

    • 안정성
      쇼핑몰 시스템에 어떤 문제도 발생시키지 않는 안정적인 기술입니다.

    • 업데이트
      어드민만 오픈되면 바로 개발을 시작할 수 있고,
      분석해야 할 내용도 적기 때문에 업데이트가 매우 신속합니다.
      신속한 업데이트로 인해 업무가 중단되는 일이 거의 없으며
      남보다 먼저 상품을 등록하여 판매할 수 있습니다.

    • 등록 및 수정 속도
      어드민 화면을 열기 때문에 등록이나 수정 속도가 느렸습니다.
      그러나 최근 멀티프로세싱, 웹엑셀러레이터 등의 새로운 기술 적용으로
      스크래핑이나 오픈API와 비슷하거나 경우에 따라서는 오히려 더 빠르며
      최근 크롬 브라우저 사용으로 속도가 더욱 향상되었습니다.

Ⅱ. 오픈API의 문제점

아직도 간혹 "오픈API가 가장 정확한 것 아닌가요?"라고 이야기하는 업체가 있어
오픈API의 허구에 대해 중점적으로 설명합니다.

쇼핑몰에서는 두 가지 경우에 오픈API를 제공합니다.
- 쇼핑몰 간 연동 등 직접 일대일로 연동하는 경우
- 연동 솔루션 업체를 통해 다수의 업체에게 제공하는 경우
여기에서는 일반적인 업체들이 사용하는 연동 솔루션의 경우를 위주로 설명합니다.

  1. 근본적인 원인

    오픈API는 앞에서 기술한 문제점 이외에도 다음과 같은 여러 가지 문제가 존재합니다.

    • 오픈API는 어드민과 똑같은 기능을 구현하는 것이 목표일 것입니다.
      그러나 개발 언어도 다르고, 동작 환경도 서로 다르고
      거의 모든 것이 다른 2개의 복잡한 시스템인 어드민과 오픈API를
      기능적으로 완벽하게 일치하도록 한다는 것은 불가능한 일입니다.

    • 어드민이 복잡하듯이 오픈API도 복잡할 수 밖에 없는데
      오픈API 스펙은 이렇게 다양한 경우에 대해 기술하기도 어렵습니다.

      실제로 오픈API 스펙을 보면 전송 데이타 형식에 대한 규정만 있을 뿐
      어떤 경우에 어떻게 해야 한다는 내용은 아예 없습니다.

      우선 이런 내용들을 문서로 작성한다는 것도 쉬운 일은 아니지만
      수백, 수천가지 경우의 수를 글로 표현한다면 책 1권으로도 모자랄텐데
      쇼핑몰 오픈API 스펙은 많아야 1~20페이지에 불과합니다.

    • 차라리 스크래핑은 어드민과 비교해 보면서 개발할 수 있지만
      오픈API는 비교 대상도 없이 오로지 스펙에만 의존해서 개발해야 합니다.

      따라서 많은 부분을 경험과 추측에 의존해서 개발해야 하며,
      마치 "장님 코끼리 다리 만지듯"이 일단 해보고
      문제가 발생하면 그 때 가서 수정하는 수 밖에 달리 방법이 없습니다.

    설령 오픈API를 개발한 쇼핑몰 개발자가 연동 개발하더라도
    오류 빈도에 차이가 있을 뿐 정확하게 연동한다는 것은 불가능한 일입니다.

    결론적으로 복잡한 쇼핑몰 연동 특히 상품 등록이나 수정 측면에서
    오픈API는 BPI(Black(or Blind) Programming Interface)일 수 밖에 없습니다.

    아울러 개발 과정이 매우 복잡하고, 많은 시간이 소요됩니다.

    • 쇼핑몰에서는 어드민이 최우선이기 때문에
      어드민 개발 후 오픈API 개발, 스펙 작성, 배포 후 솔루션 업체 개발의 과정을 거쳐야 합니다.

    • 연동 업체에서 이해가 되지 않거나 오류가 발생하게 되면
      쇼핑몰 담당자에게 문의, 쇼핑몰 개발자에게 전달, 답변, 연동 업체 개발의 과정을 거쳐야 합니다.
      쇼핑몰 개발자도 모든 내용을 기억하지 못하기 때문에 찾아본 후 답변할 수 밖에 없습니다.
  2. 책임 소재의 문제

    • 스크래핑 오류가 발생하면 전적으로 연동 업체의 책임이지만
      오픈API는 오류가 발생하면 쇼핑몰에서도 일정 부분 책임을 떠안게 됩니다.


      무언가를 제공한다는 것은 그에 따른 책임도 감수해야 함을 의미합니다.
      쇼핑몰의 요청에 따라 쇼핑몰에서 제공하는 오픈API로 개발했는데
      설령 그 것이 잘못 되었다고 하더라도 과연 단호하게 대처할 수 있을까요?

      실제로 쇼핑몰에서는 스크래핑 오류에 대해서는 단호하게 대처하면서
      오픈API 오류들에 대해서는 유야무야 넘어가는 경우가 대부분입니다.

      그럼 연동 솔루션 업체들은 어느 쪽에 더 집중하게 될까요?

      가끔 쇼핑몰로부터 스크래핑이나 오픈API 오류 내용을 들어보면
      - 오픈API의 경우 스펙을 읽어보았는지 의심이 들 정도의 오류도 있는데
      - 스크래핑의 경우에는 최소한 이런 수준의 오류는 들어보지 못했습니다.

    • 오픈API는 어드민처럼 눈에 보이는 것이 아니기 때문에 확인할 방법이 없습니다.

      어쩌다 EC-모니터가 업데이트가 늦으면
      업체들은 "어드민은 되는데 왜 EC-모니터는 안되느냐?"고 항의합니다.
      스크래핑이나 웹러닝은 어드민을 기반으로 하기 때문에 이런 이야기가 가능합니다.

      그러나 오픈API는 어드민처럼 눈에 보이는 것이 아니기 때문에
      솔루션 업체에서 그렇다고 하면 믿고 기다릴 수 밖에 없습니다.

      실제로 오픈API 연동 솔루션을 사용하던 업체 이야기를 들어보면
      쇼핑몰과 솔루션 업체 이야기가 달라서 누구 말이 맞는지 알 수 없는 경우도 많다고 합니다.

  3. 오픈API의 문제점

    이로 인해

    • 스크래핑보다 더 많은 오류가 발생합니다.

      모 쇼핑몰의 경우 어드민 특성 상 웹러닝을 적용하기 어려워 스크래핑으로 개발했고,
      타 솔루션들은 오픈API로 지원했는데
      당사 오류보다 타 솔루션의 오류때문에 연락받은 경우가 훨씬 많았습니다.
      타 솔루션 업체에 먼저 확인한 경우도 있을 것이라는 점을 감안하면
      당사가 알고 있는 것보다 훨씬 많은 오류가 발생했을 것으로 짐작됩니다.

      오픈API가 안정화돼서 이제 오류가 거의 없다고 이야기하는 경우가 있는데
      예전에 스크래핑으로 개발했을 때에도 그 정도 기간이 경과하면 마찬가지였습니다.

      처음부터 오픈API를 제공했던 쇼핑몰 중에는 문제가 없다고 하는 경우가 있습니다.
      이런 쇼핑몰은 간단해서 스크래핑으로 해도 문제가 없을 쇼핑몰입니다.

      아이러니하게도 오픈API가 필요 없는 간단한 쇼핑몰은 오픈API가 오류가 없고,
      오픈API가 필요한 복잡한 쇼핑몰은 오픈API로 해도 오류가 발생합니다.

      물론 눈에 띄지 않을 뿐이지 실제로는 오류가 발생할 수 밖에 없습니다.

    • 업데이트에 너무 많은 시간이 소요됩니다.

      앞에서 언급한 개발의 어려움, 개발 과정의 복잡함으로 인해
      사소한 쇼핑몰 변경에도 업데이트에 며칠씩 소요되고,
      쇼핑몰 개편 시에는 1개월 이상 서비스가 중단되기도 합니다.

      실제로 어드민이 변경되어 당사는 이미 업데이트했는데
      그 후에 오픈API 업데이트 메일을 받는 경우도 비일비재합니다.

      그 동안 업체들은 솔루션을 사용하지 못해 어드민에서 처리해야 합니다.
      솔루션에 익숙해진 업체는 업데이트될 때까지 상품등록을 미루게 되고
      이는 쇼핑몰과 업체의 매출 하락의 직접적인 원인이 됩니다.

    결국 이런 문제로 인한 피해는 고스란히 쇼핑몰과 업체에게 돌아갈 수 밖에 없습니다.

  4. 오픈API에 대한 오해

    • 쇼핑몰

      일대일 연동 업체들은 스크래핑 기술이 없기 때문에 오픈API가 필요합니다.

      반면 연동 솔루션 업체들은 오픈API가 없어도 스크래핑으로 개발할 수 있습니다.
      그런데 왜 이런 업체들에게까지 오픈API를 제공할까요?

      첫째, 연동 솔루션 업체에서 요청하기 때문에?
      모 연동 솔루션 업체 담당자 이야기에 의하면
      쇼핑몰에서 오픈API를 선호(?)하기 때문에 오픈API로 개발한다고 합니다.
      실제로 오픈API의 문제로 인해 스크래핑으로 개발하는 경우도 많다고 합니다.

      만약 오픈API가 있어야 한다거나 스크래핑보다 쉽다고 하는 업체가 있다면
      이런 업체는 연동 솔루션 업체라 불릴 자격조차도 없습니다.
      스크래핑 기술로 오픈API 스펙 수준의 내용을 분석하는 것은 어렵지 않지만
      오픈API든 스크래핑이든 복잡한 각각의 경우를 분석하는 것이 어려운 일인데
      이런 연동에 대한 기본적인 개념조차 없는 업체이기 때문입니다.

      둘째, 오픈API가 스크래핑보다 정확할 것이다?
      처음에는 오픈API가 스크래핑보다 정확할 것이라는 기대가 있었습니다.
      그러나 앞에 설명한 바와 같이 오픈API는
      오히려 스크래핑보다 오류 발생 확률이 더 높고, 실제로도 더 많은 오류들이 발생합니다.
      현재는 대부분의 쇼핑몰들이 오픈API의 오류나 문제점에 대해 잘 알고 있기 때문에
      이런 효과를 기대하는 쇼핑몰은 없을 것입니다.

      셋째, 어차피 오픈API가 있으니까 제공한다?
      연동 솔루션에서는 일대일 연동보다 훨씬 다양한 오류들이 발생한다고 합니다.
      너무나도 당연한 이야기입니다.
      각 업체마다 계약 조건, 권한, 마진, 상품, 환경, 사용자 등 모든 것이 다르기 때문에
      사용 업체가 많을수록 오류도 다양할 수 밖에 없습니다.
      특정 몇몇 업체가 사용하는 것과 연동 솔루션을 통해 다수의 업체가 사용하는 것은
      오류의 유형과 빈도가 하늘과 땅 차이입니다.
      이로 인해 쇼핑몰 중에는 오픈API를 개발했지만 일대일 연동 업체에만 제공하고,
      연동 솔루션 업체에는 제공하지 않는 쇼핑몰들도 있습니다.

    • 솔루션 업체

      아마도 스크래핑 개발의 어려움을 경험했던 솔루션 업체들은
      오픈API가 제공되면 스크래핑처럼 복잡한 분석을 하지 않아도 될 것이라고 기대했을 것입니다.
      그러나 오픈API 역시 어드민과 마찬가지로 복잡할 수 밖에 없습니다.

    • 사용자

      스크래핑이나 오픈API 연동 솔루션을 사용하던 사용자들은
      쇼핑몰과 솔루션 업체의 이야기를 듣고, 오픈API가 적용되면
      그 동안 발생하던 오류들이 없어지거나 최소한 줄어들 것이라고 기대했을 것입니다.
      그러나 기대와는 달리 오류는 여전하고, 업데이트는 더 늦는 상황을 경험했을 것입니다.

  5. 오픈API의 역설

    오픈API는
    • 오히려 스크래핑보다도 오류가 많습니다.
      • 차라리 스크래핑은 어드민과 데이터를 비교하면서 개발할 수 있지만
        오픈API는 비교 대상이 없기 때문에 데이터가 정상인지 확인할 방법이 없다 보니
        구조적으로 오류가 더 많이 발생할 수 밖에 없습니다.
      • 스크래핑 오류는 전적으로 연동 솔루션 업체의 책임이라 주의를 기울여 개발하지만
        오픈API는 책임 소재가 불명확하다 보니 굳이 그럴 필요가 없습니다.
        실제로 오픈API 오류에 대해 들어보면 어이없는 오류도 다수 존재합니다.
    • 모든 책임이 쇼핑몰로 전가됩니다.
      사용자들이 문제가 있어 연동 솔루션 업체에 이야기하면 "오픈API는 그럴 수 밖에 없다."는 답변만 돌아온다고 합니다.
      웹러닝이나 스크래핑에서는 “어드민은 정상인데 왜 안되느냐?”고 이의를 제기할 수 있지만
      오픈API는 실체가 없다 보니 연동 솔루션 업체 이야기를 믿을 수 밖에 없습니다.

    결론적으로 쇼핑몰에서는 막대한 비용과 노력을 투자하여 오픈API를 개발하고, 유지보수하지만
    아이러니하게도
    • 오히려 스크래핑보다도 오류는 더 많이 발생하고,
    • 모든 책임과 비난은 쇼핑몰이 감수해야 하는
    상황입니다.

  6. 오픈API에 대한 인식의 변화

    그 동안 실제로 오픈API 문제를 겪으면서 오픈API에 대한 환상도 깨지고 있습니다.

    • 쇼핑몰

      특히 쇼핑몰은 업데이트 지연, 매출 감소 이외에도

      • 오픈API 개발 및 유지보수에 엄청난 노력과 비용이 소요됩니다.
      • 스펙 작성, 오픈API 문의에 대한 답변, 오류 발생 시 원인 파악
        등의 업무에 많은 노력과 비용이 소요됩니다.
      • 어드민 개발 및 수정 시에도 오픈API를 고려해야 하기 때문에
        어드민 개발 및 업데이트에도 제약이 따르고, 더 많은 시간과 노력이 소요됩니다.

      즉, 쇼핑몰은 오픈API로 인해 이중, 삼중의 어려움을 겪을 수 밖에 없습니다.

      결론적으로 쇼핑몰은 엄청난 노력과 비용을 투자해서 오픈API를 개발하고 있지만
      연동 솔루션 업체들에게 오픈API를 제공하는 경우에는
      • 실제로 아예 오픈API가 사용되지 않는 경우도 많고,
      • 아이러니하게도 오히려 오픈API를 제공하지 않는 쇼핑몰에 비해
        오류도 더 많고, 업데이트도 더 늦은 어처구니 없는 결과를 초래하고 있습니다.

      그러다 보니 쇼핑몰의 입장에도 조금씩 변화가 일어나고 있습니다.

      예전에는 매우 적극적으로 오픈API 사용을 권장했던 쇼핑몰도
      최근에는 대부분 어떤 방법을 사용하든 정확하게만 하면 된다는 입장이며,
      오픈API가 있는지도 모를 정도로 오픈API가 유명무실한 쇼핑몰도 있고,
      연동 솔루션 업체들에게는 오픈API를 제공하지만
      정작 협력업체들에게는 EC-모니터 사용을 권장하는 쇼핑몰도 많습니다.

      공식적으로 오픈API를 중단하는 쇼핑몰도 하나, 둘 생겨날 것으로 예상됩니다.
      하긴 오픈API가 쇼핑몰의 의무사항도 아니고, 약속을 한 것도 아니니
      쇼핑몰에서 오픈API 서비스를 중지하는 것도 전적으로 쇼핑몰의 판단입니다.

    • 솔루션 업체

      지난번 모 쇼핑몰에서의 회의 때 모 솔루션 업체 담당자가 이야기하더군요.
      "사용자들은 뭐가 제대로 안된다, 언제 되느냐 아우성인데
       이제는 어떤 이유도 사용자들에게 변명으로 밖에 들리지 않는 것 같아요.
       오픈API 믿고 있다가는 정말 사용자가 다 떨어져 나갈 것 같아요.
       그래서 오픈API를 제공하는 쇼핑몰도 스크래핑으로 하는 경우가 많아요."

    • 사용자

      이런 인식의 변화의 중심에는 사용자가 있습니다.

      오픈API 연동 솔루션을 사용하든 모 업체가 이야기 하더군요.
      "돈 내고 솔루션을 사용하는 이유는 일을 쉽고, 빠르고 정확하게 하려는 건데
       그 동안 솔루션 업체 이야기만 믿고 남의 사정 봐주다가 우리만 힘들어졌어요.
       이제 오픈API든 스크래핑이든 그 것이 중요한 것이 아니고,
       내가 지금 당장 해야할 일을 쉽고, 빠르고 정확하게 할 수 있느냐가 중요합니다.
       그리고 솔루션 업체 이야기를 들어보면 쇼핑몰의 책임도 큰 거 같은데
       도대체 책임지지도 못할 거면서 왜 오픈API를 사용하라고 하는지 모르겠어요."

  7. 오픈API는 계속 될까요?

    그렇다면 이렇게 문제가 많은 오픈API가 계속될까요?
    위에서 언급한 것처럼 쇼핑몰의 인식도 달라지고 있는데?
    더구나 오픈API는 쇼핑몰의 의무 사항도 아닌데?

    실제로 현재 많은 쇼핑몰들이
    오픈API 지속 여부에 대해 고민하고 있는 것으로 알고 있어
    조만간 오픈API를 중단하는 쇼핑몰도 생겨날 것으로 예상되며
    이렇게 되면 같은 고민을 하고 있는 쇼핑몰들도 연쇄적으로 중단할 것으로 예상됩니다.

  8. 오픈API의 대안

    쇼핑몰에서는 일대일 연동 업체에게는 어쩔 수 없이 오픈API를 제공한다 하더라도
    연동 솔루션 업체에게는
    - 전적으로 업체 자율에 맡겨 업체 책임 하에 개발하도록 하고,
    - 오류 발생 시에는 단호하게 대처하는 것이
    훨씬 더 효과적인 방법이라 사료됩니다.

    필요하다면 연동 업체들에게 EC-모니터 연동 기능을 제공할 수도 있습니다.

    EC-모니터 연동 기능을 사용하면
    • 쇼핑몰에서는 오픈API를 개발할 필요가 없기 때문에
      오픈API 개발 및 유지보수에 소요되는 막대한 비용과 노력을 절감할 수 있고,
    • 연동 업체 역시
      • EC-모니터와 한번만 연동하면 모든 쇼핑몰을 바로 사용할 수 있기 때문에
        훨씬 적은 노력과 훨씬 적은 비용으로 훨씬 빠른 시간 내에 개발을 완료할 수 있고,
      • 쇼핑몰 변경에 따른 모든 업데이트는 당사에서 담당하기 때문에
        쇼핑몰이 변경되더라도 추가로 해야 할 작업이 없을 뿐만 아니라
    • 무엇보다도 EC-모니터 엔진의 훨씬 정확한 연동, 훨씬 빠른 업데이트로 인해
      쇼핑몰과 업체의 매출이 증가하고, 신뢰도도 크게 향상될 것입니다.

Ⅲ. 쇼핑몰 서버 부하

  1. 분산 접속과 집중 접속


    • 분산 접속(일반적인 형태)
      도1)과 같이 각 PC에서 서버에 접속하는 일반적인 형태입니다.
      쇼핑몰 어드민도 마찬가지로 각 업체 PC에서 익스플로러로 쇼핑몰 서버에 접속합니다.
      EC-모니터도 동일하게 EC-모니터를 설치한 각 PC에서 쇼핑몰 어드민 화면을 열어서 처리합니다.

    • 집중 접속(타 솔루션)
      일부 솔루션들은 데이타를 솔루션 업체 서버에 저장할 뿐만 아니라
      도2)와 같이 솔루션 업체 서버에서 쇼핑몰 서버에서 접속하여 데이타를 주고 받습니다.
      솔루션 업체 서버 1대당 한 업체가 아니라 여러 업체를 담당하다 보니
      각각의 서버에서 집중적으로 쇼핑몰 서버로 데이타를 전송합니다.

  2. 집중 접속의 문제점

    인터넷은 원래 서버와 다수의 클라이언트를 기반으로 설계된 서버/클라이언트 구조의 네트워크입니다.
    서버는 물론 각종 장비들도 이런 구조에 적합하게 제작되었습니다.
    특히 웹(http)은 연결과 끊기를 반복하는 Connectless 프로토콜입니다.
    집중 접속을 원한다면 Connect-Oriented 프로토콜이 더 좋은 솔루션이 될 것입니다.
    어쨋든 웹에서는 동일한 용량의 데이타를 주고 받더라도
    집중 접속은 분산 접속에 비해서 훨씬 더 서버 부하를 가중시킨다고 합니다.
    예전에 모 쇼핑몰에서는 모 솔루션을 사용하는 업체가 많지 않았음에도 불구하고
    서버에 부하가 심하게 걸릴 때마다 해당 솔루션의 서버 IP주소만 차단하면
    약 30분 정도 후에는 정상적인 상태로 돌아오고는 했다고 합니다.

    EC-모니터는 EC-모니터가 설치된 각 업체 PC에서 쇼핑몰에 접속합니다.
    즉, 사람이 자신의 PC에서 쇼핑몰에 로그인하여 작업하는 것과 동일한 구조입니다.
    따라서 많은 작업을 하더라도 쇼핑몰 서버의 부하가 분산됩니다.


Ⅳ. 결론

결론적으로 스크래핑이나 오픈API는 오류가 발생할 수 밖에 없는 기술이며
오직 웹러닝 기술만이 이론적으로도 실제로도 가장 완벽한 연동 기술입니다.

EC-모니터는 이런 웹러닝 기술을 바탕으로
상품등록은 물론 품절, 재고 수정, 가격 수정, 상품명/이미지/상세설명 수정
기타 어드민에서 수정 가능한 모든 정보를 정확하게 수정하고 있으며
이외에 주문/교환/취소/반품 다운로드, 배송 처리, 회수 처리 뿐만 아니라
CS, Q&A 다운로드 및 답변 등록 등의 기능을 완벽하게 지원하고 있습니다.

※ 연동 기술에 따른 결과의 차이

항목 타 솔루션 EC-모니터
상품 등록 데이타를 잘못 만들 가능성이 높기 때문에 등록 후에 어드민에서 하나하나 확인하고 수정해야 합니다. 한번에 완벽하게 등록되기 때문에 등록 후 어드민에서 일일이 확인하거나 수정할 필요가 없습니다.
상품 수정 기존 상품 정보를 완벽하게 분석하기 어렵기 때문에 다른 정보마저 잘못될 가능성이 매우 높습니다.
실제로 수정된다고 해서 실행했는데 다른 정보까지 엉망이 되어서 아예 그 다음부터는 쇼핑몰에서 직접 수정한다고 합니다.
등록된 상품 정보를 분석하지 않습니다.
그냥 화면이 열릴 때까지 기다렸다가 수정할 정보만 수정하고 버튼을 클릭합니다.
아무리 복잡한 쇼핑몰도 품절, 재고, 가격은 물론 상품명, 이미지, 설명, 기타 거의 모든 정보를 자동으로 완벽하게 수정합니다.
업데이트 분석할 내용이 많기 때문에 어드민 변경 시 업데이트에 많은 시간이 소요됩니다.
특히 오픈API는 여러 단계를 거쳐야 하기 때문에 업데이트가 훨씬 더 지연될 수 밖에 없습니다.
어디에 어떤 정보를 입력하는지만 분석하기 때문에 쇼핑몰 어드민 변경 시 업데이트가 매우 신속합니다.
지원 쇼핑몰 내부 분석이 어려운 쇼핑몰의 경우 지원이 불가능합니다. 화면에 보이는대로 컨트롤하기 때문에 어떤 형태의 어드민도 지원이 가능합니다.
백화점몰 백화점몰은 하나의 상품을 등록하고, 점을 추가하는 방식이지만 점 추가를 지원하지 못하여 하나의 상품을 각각의 점에 신상품으로 등록합니다. 상품 등록은 물론 점 추가, 점별 재고 관리를 지원합니다.
안정성 언제 어떤 잘못된 데이타가 전송될지 그로 인해 쇼핑몰 시스템에 어떤 문제가 발생할지 누구도 예측할 수 없기 때문에 자칫 대형 사고로 이어질 수 있습니다. 어드민과 똑같이 동작하기 때문에 쇼핑몰 어드민에 전혀 문제가 없는 안정적인 솔루션입니다.

※. 부수적인 효과

어드민은 쇼핑몰과 협력업체의 가장 기본적인 의사 소통 수단으로써
어드민의 중요성은 아무리 강조해도 지나침이 없을 정도이기 때문에
쇼핑몰에서는 어드민 개발과 유지보수에 많은 시간과 인력을 투입합니다.

당사가 웹러닝 기술을 사용하다보니
당사 개발자들은 어드민을 모니터링하는 것이 주요 업무 중 하나일 뿐만 아니라
많은 경험과 지식이 축적되어 어드민에 관한한 누구에게도 뒤지지 않는 전문가들입니다.

그러다 보니 어드민의 사소한 오류나 불합리한 점 등을 발견하기도 하고,
쇼핑몰에 전달하여 오류 수정이나 어드민 개선에 기여하는 경우도 많이 있습니다.
심지어는 가끔 쇼핑몰에서 자신의 어드민에 대해 자문을 구하는 경우도 있습니다.