Blog·인사이트

우즈벡 자사몰 견적에 "저희 말고 현지 개발사도 함께 보세요" 를 적은 이유

···11분 읽기
요약

한 한국 식품 유통사의 우즈베키스탄 자사몰 견적 문의를 받고 회신할 때, 자사 견적과 함께 "우즈벡 현지의 1C-Bitrix 공식 파트너에게도 의뢰해 보시는 것을 함께 권장드린다" 는 한 줄을 넣었습니다. 자기 영업을 깎는 한 줄이지만, 사업 시기를 놓치는 비용이 그것보다 훨씬 크기 때문입니다.

최근 한 한국 식품 유통사로부터 견적 문의를 받았습니다. 한국 완제품(라면·과자 중심)을 우즈베키스탄에 수출해 현지 오프라인으로 판매 중이고, 이를 자사몰로 온라인까지 확장하려는 단계였습니다. 우즈벡어·러시아어·영어 3개 언어, 현지 결제(Payme·Click), 약 1,000개 상품, 1차 단일 셀러 → 향후 멀티셀러 확장. 참고 사이트로 korshop.ru를 보내 주셨습니다.

견적을 회신하면서 한 줄을 추가했습니다. 자사 견적(모던 스택 기반)과 별개로, 우즈베키스탄 현지의 1C-Bitrix 공식 파트너에게도 의뢰해 보시는 것을 함께 권장드린다는 내용이었습니다. 영업 입장에서 보면 손해가 명백한 한 줄입니다 — 그런데 그게 그 견적에 가장 정직한 답이었습니다.

참고 사이트가 보여준 것 — 그리고 어떻게 알아냈나

분석의 출발은 고객이 보내 주신 korshop.ru 였습니다. 견적을 받자마자 이 사이트가 어떻게 만들어진 사이트인지부터 봤습니다 — 솔루션 위에서 customizing 한 사이트인지, 자체 개발한 사이트인지에 따라 견적의 그레이드가 통째로 달라지기 때문입니다.

응답을 열어 보니 사이트가 자기 자신을 1C-Bitrix 임을 여러 곳에서 드러내고 있었습니다. 페이지 안 정적 자산 경로가 /bitrix/templates/ 와 /upload/iblock/ 로 구성되어 있었고, 응답 cookie 에 BITRIX_SM_* 시리즈가 포함돼 있었으며, HTML 안에 bx-no-touch 같은 1C-Bitrix 특유의 클래스명이 보였습니다. 일부 페이지에는 <meta name="generator" content="1C-Bitrix"> 가 직접 명시되어 있기도 했습니다. 추측이 아니라 사이트가 직접 신호를 내고 있는 상태였습니다.

1C-Bitrix는 러시아·CIS 시장에서 표준에 가까운 PHP 기반 e-commerce 솔루션입니다. 즉 korshop.ru는 처음부터 자체 개발한 시스템이 아니라, CIS 시장에 이미 자리 잡은 솔루션 위에 디자인과 일부 기능을 customizing 한 결과물입니다. 이 사실이 견적 판단의 결정적 단서였습니다.

우즈베키스탄·러시아 시장에는 1C-Bitrix 전문 개발 인력이 풍부합니다 — 한국 시장에서 그누보드·카페24·아임웹 작업이 풍부한 것과 비슷한 구조입니다. 그리고 고객의 핵심 요구사항(다국어, Payme·Click 연동, 상품·주문·회원 관리, 모바일 최적화)은 1C-Bitrix가 이미 모듈로 제공하는 영역이 대부분입니다.

요컨대 korshop.ru와 유사한 형태를 빠르게 구축하시는 게 우선이라면, 우즈벡 현지의 1C-Bitrix 공식 파트너 쪽이 합리적인 선택지일 수 있다는 뜻이었습니다. 솔루션 그레이드 안에서, 그 솔루션을 가장 잘 다루는 시장에 의뢰하는 — 자연스러운 순서입니다. (솔루션과 자체 개발의 갈림길 자체에 대해서는 이커머스, 뭘로 만드는 게 좋을까? 솔루션 vs 자체 개발 에서 다뤘습니다.)

그럼에도 자사를 선택할 이유는 따로 있습니다

같은 견적서 안에 자사를 선택할 경우의 강점도 함께 적었습니다. 그 강점이 명확해야 고객도 두 옵션을 같은 잣대로 비교할 수 있기 때문입니다.

  • 한국 본사와의 한국어 직접 소통 — 의사결정·기능 변경 요청·운영 이슈 대응이 한국 본사 시점에서 끊김 없이 이뤄집니다. 현지 파트너와의 시차·언어 매개 비용이 사라집니다.
  • 한국 법인 명의 계약 — 세금계산서 처리, 법적 책임 소재, 향후 분쟁 시 한국 법체계 안에서의 처리. 해외 계약과 본질적으로 다른 영역입니다.
  • 모던 스택의 자유도 — Next.js + 자체 백엔드 기반이라 디자인 자유도, 모바일 성능, SEO 측면에서 솔루션 customizing 보다 유리합니다. 브랜드 자사몰 색깔을 강하게 가져가야 한다면 차이가 큽니다.
  • 한국 본사 시스템과의 연동 — 향후 본사 ERP·재고·정산과의 연동이 자연스럽습니다. 솔루션 안에서 customizing 으로 풀기 어려운 영역입니다.

같은 결과물의 가격 비교가 아니라, 우선순위가 무엇이냐에 따라 답이 달라지는 비교입니다. 빠른 시장 진입과 비용 효율이 우선이면 현지 1C-Bitrix 파트너 쪽이 유리할 수 있고, 한국 본사 통합 운영·브랜드 자유도·법적 책임이 우선이면 자사 쪽이 더 합리적입니다.

견적서를 정직하게 만드는 다른 장치들

"현지 파트너도 함께 보시라" 는 한 줄이 가장 두드러지지만, 그 외에도 견적서 안에 정직성을 담는 작은 장치들이 있습니다.

포함과 제외를 모두 명시합니다. 회계 ERP 자동 연동, 외부 마켓플레이스 입점(Wildberries·Ozon 등), 모바일 앱, SNS 마케팅 자동화, 검색·추천 엔진 — 이번 견적에서는 모두 1차 제외로 정리했습니다. 1차에 다 넣으면 일정·비용이 부풀고, 정작 가장 중요한 "현지에서 빠르게 팔리기 시작하는" 단계가 늦어집니다. 제외 항목을 명시해야 나중에 "그건 별도입니다" 라는 분쟁이 생기지 않습니다.

인프라 계약은 고객사가 직접 하시도록 권장했습니다. Google Cloud·AWS 가입과 설정은 저희가 안내드리지만 계약 자체는 고객사 명의로 직접. 개발사가 인프라 청구를 대행하면 사이에 마진이 붙고 — 무엇보다 고객사가 자기 인프라를 직접 통제할 수 없는 구조가 됩니다. 운영을 길게 가져가실 거라면 처음부터 직접 계약이 맞습니다.

PG 가맹은 PG사와 고객사가 직접 진행하시는 것이 원칙입니다. 사업자 심사가 포함되는 영역이라 개발사가 중간에 개입할 수 없습니다. 이번 케이스에서는 우즈벡 법인과 UZS 계좌 보유가 이미 확인된 상태였습니다 — 가맹의 출발선은 통과한 셈입니다. 다만 한국 기준으로 PG 가맹 심사가 통상 3~4주 소요되고, 우즈벡 Payme·Click 도 비슷하거나 더 길어질 수 있습니다. 일정에 미리 반영해 두지 않으면 개발이 끝났는데 결제만 못 붙는 시점이 생깁니다.

또 하나의 흔한 케이스 — 가맹 심사 단계에서 사이트가 먼저 필요한 경우입니다. PG사가 심사 과정에서 실제 동작하는 사이트의 결제 흐름을 확인하려는 경우인데, 이때는 임시 데모 페이지 형태로 결제 호출 흐름까지 미리 준비해 드립니다. 가맹 완료 후 API 키와 문서(또는 PG사 시스템 접속 권한)를 자사로 전달해 주시면 본 결제 모듈을 연동하는 구조가 표준입니다. 가맹을 개발사가 대행한다는 견적은 그 자체가 위험 신호일 수 있습니다. (PG 직접 계약과 솔루션 수수료 구조 비교는 커머스 PG 직접 계약 vs 솔루션: 수수료 구조의 진실 에서 다뤘습니다.)

호스팅 마이그레이션은 별도 비용으로 명시합니다. 추후 우즈벡 현지 호스팅으로 옮기실 가능성이 있다면, 초기 셋업 시점의 변경은 견적 안에 포함되지만 운영 중인 서버를 옮기는 경우는 별도 마이그레이션 비용이 발생한다는 점을 명시했습니다. 운영 단계의 변경은 데이터 이전·DNS 전환·다운타임 관리·재테스트가 모두 따라붙기 때문입니다.

다국어 운영 — AI 1차 번역 + 우즈벡 직원 검수의 두 갈래

다국어 사이트라는 한 줄 뒤에는 운영 단계의 무거움이 숨어 있습니다. 사이트가 우즈벡어·러시아어·영어를 지원한다는 건 콘텐츠가 추가되거나 바뀔 때마다 세 번 작업해야 한다는 뜻이기 때문입니다. 그 부담을 운영자가 직접 짊어지는 형태로 만들면 결국 한두 달 만에 다국어가 사실상 멈춥니다.

그래서 콘텐츠를 두 갈래로 나눠 처리합니다.

① 사이트 고정 텍스트 (i18n). 메뉴·버튼·안내 메시지·푸터·법적 고지 등 사이트 골격에 박히는 텍스트입니다. 영어 기준으로 번역 필요 항목을 자동으로 리스트업한 뒤 구글 스프레드시트로 정리합니다. 1차로 AI 번역(우즈벡어·러시아어)을 채워 둔 상태로 시트를 우즈벡 현지 직원분에게 전달드리면, 직원분이 검수·수정 후 시트를 자사로 회신해 주시고, 저희가 시트의 검수본을 사이트에 적용합니다. 이후 신규 텍스트가 생기면 시트의 빈 행만 채우는 형태로 같은 사이클이 반복됩니다.

② 동적 콘텐츠 (상품). 1,000개의 상품 — 그리고 그 이후 추가될 상품들 — 의 이름·설명·옵션을 매번 시트로 빼고 적용하는 흐름은 운영 부담이 너무 큽니다. 그래서 관리자 페이지의 상품 등록 폼 안에 3개 언어 입력란을 함께 표시합니다. 운영자가 한 번 등록하면 3개 언어가 동시에 사이트에 반영되는 구조입니다. 한국어로 먼저 입력한 뒤 "AI 번역" 버튼으로 세 언어를 자동 채우고 검수만 하시는 흐름도 옵션으로 제공합니다.

결제 통화는 UZS(우즈벡 숨) 단일로 처리합니다. 3개 언어를 지원하더라도 통화를 셋으로 가져가는 건 환율 노출과 정산 복잡성을 통째로 올리는 결정이라, 자사몰의 1차 운영에는 어울리지 않는다고 봤습니다.

멀티셀러 — 미루는 것과 1차에 반영하는 것의 차이

1차 오픈에는 단일 셀러 구조로 진행하기로 했습니다. 그렇다고 멀티셀러를 1차 DB에서 완전히 빼 두면, 나중의 마이그레이션 비용이 견적의 적지 않은 부분이 될 수 있습니다. 그래서 절차를 둘로 나눠 다뤘습니다.

1차에 만들지 않는 것 — 비즈니스 로직. 운영자 권한 분리, 셀러별 정산 흐름, 셀러별 환불 책임 분리, 셀러 onboarding UI 등이 여기에 해당합니다. 운영 데이터 없이 처음부터 만들면 결국 추측 기반의 설계가 됩니다. 셀러마다 정산 주기가 다를지, 수수료 구조가 단일일지 차등일지, 환불 책임이 셀러별인지 자사 통합인지 — 이런 결정은 실제 셀러를 한두 곳 모셔 본 뒤에야 비로소 보입니다.

1차에 반영해 두는 것 — DB 구조. 상품·주문·정산·재고 테이블에 seller_id 같은 식별자 컬럼을 처음부터 두고, 단일 셀러 운영 동안에는 모든 레코드가 자사 단일 값을 가집니다. 주문 안의 라인 아이템마다 어떤 셀러의 상품인지 식별이 가능한 형태로 둡니다. 정산 모델도 1셀러 = 자사라는 단순한 형태로 시작하지만, 정산 단위 자체는 셀러별로 떨어질 수 있게 컬럼 구조를 잡습니다.

이 둘을 함께 가져가면, 1차 → 2차 전환 시점에 데이터 마이그레이션은 사실상 필요하지 않고 새 셀러를 추가하면서 비즈니스 로직(권한·UI·정산 분리)을 붙이는 것이 작업의 본체가 됩니다. 그게 결국 1차 견적에 들어가는 약간의 추가 설계 비용으로 2차의 큰 마이그레이션 비용을 사 두는 거래입니다.

본격 멀티셀러 구현 시점은 1차 오픈 후 3~4개월, 실제 운영 데이터를 보신 다음에 재검토하시는 것을 권장드렸습니다.

국내 문의에도 같은 방식으로 답합니다 — 솔루션으로 풀리면 솔루션을 권합니다

이번 우즈벡 케이스가 특별해서 현지 파트너를 함께 추천한 건 아닙니다. 국내 쇼핑몰 제작 문의가 들어올 때도 처음 하는 일은 같습니다 — 이 사업이 어떤 그레이드에서 풀어야 하는 문제인지를 먼저 판별합니다.

실제로 들어오는 국내 문의의 상당수는 카페24·그누보드·아임웹 같은 솔루션 선에서 충분히 풀리는 경우입니다. 핵심 기능(상품 등록·결제·배송·관리자) 이 솔루션 안에 이미 갖춰져 있고, 디자인과 일부 customizing 만 더하면 사업이 출발할 수 있는 상태인 경우가 많습니다. 이번 우즈벡 케이스에서 1C-Bitrix 파트너를 권해 드린 것과 같은 방식으로, 국내 문의에도 "저희와 자체 개발로 가실 필요는 없고, 카페24·그누보드·아임웹 작업이 주력인 회사 쪽이 맞을 것입니다" 라고 답하고 솔루션을 함께 추천드립니다.

저희 회사가 실제로 받아야 하는 일은 솔루션의 가정을 더 이상 따라갈 수 없는 사업입니다. 매출 규모가 수백억 이상이라 솔루션의 운영 한계(데이터 양·트래픽·정산 처리)와 부딪히는 경우, 멀티셀러·중개·정산 구조처럼 솔루션이 처음부터 가정한 단일 셀러 모델과 어긋나는 경우, 위치 기반 상품처럼 일반 e-commerce 솔루션이 다루지 않는 데이터 모델이 필요한 경우 — 이런 사업들이 자체 개발 그레이드에 들어와야 하는 이유 그 자체가 됩니다.

그러니까 이번 우즈벡 견적의 "현지 1C-Bitrix 파트너도 함께 보시라" 는 한 줄은, 국내에서 매주 하는 "카페24·그누보드 쪽이 맞을 것입니다" 와 정확히 같은 종류의 답입니다. 시장이 바뀌었을 뿐 판단 절차는 동일합니다.

왜 자기 영업을 깎는 한 줄을 적었는가

자사 견적과 현지 1C-Bitrix 파트너를 함께 권한다는 한 줄은 영업 입장에서 깎이는 한 줄입니다. 그럼에도 이걸 적는 이유는 단순합니다 — 고객의 사업이 잘되는 게 결국 우리에게도 좋고, 잘못된 그레이드 선택의 가장 큰 비용은 사업 시기를 놓치는 것이라는 사실 때문입니다.

견적사가 자기 견적만을 옹호하는 견적은, 그 자체로 하나의 신호입니다. 모든 요구가 "다 된다" 고 답하는 견적도, 자기 견적이 모든 상황의 정답이라고 말하는 견적도 — 같은 종류의 무한 약속입니다. 실제로 만들어야 하는 쪽은 자기 견적의 한계를 함께 말할 수밖에 없습니다.

이번 케이스에서 고객은 두 옵션을 함께 검토하실 것이고, 어느 쪽으로 결정하시든 그 결정은 더 나은 정보 위에서 이뤄질 것입니다. 만약 자사를 선택하신다면, 그 선택은 가격이 아니라 한국 본사 통합·법적 책임·브랜드 자유도라는 분명한 이유 위에서 이뤄지는 선택이 됩니다 — 그게 처음부터 우리가 받고 싶은 종류의 일입니다.

정리

견적은 가격표가 아닙니다. 그 가격으로 무엇이 만들어지고, 어떤 그레이드에서 풀어야 하는 문제이며, 같은 그레이드 안에서 누가 만드는 것이 더 나은가 — 이 모든 판단을 같이 적는 문서입니다. 그 안에 "저희 말고 다른 곳이 더 나을 수 있다" 는 가능성이 빠져 있다면, 그 견적은 정직한 견적이 아닙니다.

외주 개발 견적을 어떻게 판단하는지의 큰 그림은 외주 개발 견적, 어떻게 판단할까? 에 정리해 두었습니다.

*해외 자사몰·다국어 e-commerce·CIS 시장 진출 관련 견적 문의는 프로젝트 상담으로 부탁드립니다. 개발 계약과 무관하게 견적 자문을 제공합니다.*


견적,외주개발,해외진출,자사몰,우즈베키스탄,CIS,Bitrix,다국어,멀티셀러,PG
다른 포스팅
Blog·인사이트

우즈벡 자사몰 견적에 "저희 말고 현지 개발사도 함께 보세요" 를 적은 이유

···11분 읽기

최근 한 한국 식품 유통사로부터 견적 문의를 받았습니다. 한국 완제품(라면·과자 중심)을 우즈베키스탄에 수출해 현지 오프라인으로 판매 중이고, 이를 자사몰로 온라인까지 확장하려는 단계였습니다. 우즈벡어·러시아어·영어 3개 언어, 현지 결제(Payme·Click), 약 1,000개 상품, 1차 단일 셀러 → 향후 멀티셀러 확장. 참고 사이트로 korshop.ru를 보내 주셨습니다.

견적을 회신하면서 한 줄을 추가했습니다. 자사 견적(모던 스택 기반)과 별개로, 우즈베키스탄 현지의 1C-Bitrix 공식 파트너에게도 의뢰해 보시는 것을 함께 권장드린다는 내용이었습니다. 영업 입장에서 보면 손해가 명백한 한 줄입니다 — 그런데 그게 그 견적에 가장 정직한 답이었습니다.

참고 사이트가 보여준 것 — 그리고 어떻게 알아냈나

분석의 출발은 고객이 보내 주신 korshop.ru 였습니다. 견적을 받자마자 이 사이트가 어떻게 만들어진 사이트인지부터 봤습니다 — 솔루션 위에서 customizing 한 사이트인지, 자체 개발한 사이트인지에 따라 견적의 그레이드가 통째로 달라지기 때문입니다.

응답을 열어 보니 사이트가 자기 자신을 1C-Bitrix 임을 여러 곳에서 드러내고 있었습니다. 페이지 안 정적 자산 경로가 /bitrix/templates/ 와 /upload/iblock/ 로 구성되어 있었고, 응답 cookie 에 BITRIX_SM_* 시리즈가 포함돼 있었으며, HTML 안에 bx-no-touch 같은 1C-Bitrix 특유의 클래스명이 보였습니다. 일부 페이지에는 <meta name="generator" content="1C-Bitrix"> 가 직접 명시되어 있기도 했습니다. 추측이 아니라 사이트가 직접 신호를 내고 있는 상태였습니다.

1C-Bitrix는 러시아·CIS 시장에서 표준에 가까운 PHP 기반 e-commerce 솔루션입니다. 즉 korshop.ru는 처음부터 자체 개발한 시스템이 아니라, CIS 시장에 이미 자리 잡은 솔루션 위에 디자인과 일부 기능을 customizing 한 결과물입니다. 이 사실이 견적 판단의 결정적 단서였습니다.

우즈베키스탄·러시아 시장에는 1C-Bitrix 전문 개발 인력이 풍부합니다 — 한국 시장에서 그누보드·카페24·아임웹 작업이 풍부한 것과 비슷한 구조입니다. 그리고 고객의 핵심 요구사항(다국어, Payme·Click 연동, 상품·주문·회원 관리, 모바일 최적화)은 1C-Bitrix가 이미 모듈로 제공하는 영역이 대부분입니다.

요컨대 korshop.ru와 유사한 형태를 빠르게 구축하시는 게 우선이라면, 우즈벡 현지의 1C-Bitrix 공식 파트너 쪽이 합리적인 선택지일 수 있다는 뜻이었습니다. 솔루션 그레이드 안에서, 그 솔루션을 가장 잘 다루는 시장에 의뢰하는 — 자연스러운 순서입니다. (솔루션과 자체 개발의 갈림길 자체에 대해서는 이커머스, 뭘로 만드는 게 좋을까? 솔루션 vs 자체 개발 에서 다뤘습니다.)

그럼에도 자사를 선택할 이유는 따로 있습니다

같은 견적서 안에 자사를 선택할 경우의 강점도 함께 적었습니다. 그 강점이 명확해야 고객도 두 옵션을 같은 잣대로 비교할 수 있기 때문입니다.

  • 한국 본사와의 한국어 직접 소통 — 의사결정·기능 변경 요청·운영 이슈 대응이 한국 본사 시점에서 끊김 없이 이뤄집니다. 현지 파트너와의 시차·언어 매개 비용이 사라집니다.
  • 한국 법인 명의 계약 — 세금계산서 처리, 법적 책임 소재, 향후 분쟁 시 한국 법체계 안에서의 처리. 해외 계약과 본질적으로 다른 영역입니다.
  • 모던 스택의 자유도 — Next.js + 자체 백엔드 기반이라 디자인 자유도, 모바일 성능, SEO 측면에서 솔루션 customizing 보다 유리합니다. 브랜드 자사몰 색깔을 강하게 가져가야 한다면 차이가 큽니다.
  • 한국 본사 시스템과의 연동 — 향후 본사 ERP·재고·정산과의 연동이 자연스럽습니다. 솔루션 안에서 customizing 으로 풀기 어려운 영역입니다.

같은 결과물의 가격 비교가 아니라, 우선순위가 무엇이냐에 따라 답이 달라지는 비교입니다. 빠른 시장 진입과 비용 효율이 우선이면 현지 1C-Bitrix 파트너 쪽이 유리할 수 있고, 한국 본사 통합 운영·브랜드 자유도·법적 책임이 우선이면 자사 쪽이 더 합리적입니다.

견적서를 정직하게 만드는 다른 장치들

"현지 파트너도 함께 보시라" 는 한 줄이 가장 두드러지지만, 그 외에도 견적서 안에 정직성을 담는 작은 장치들이 있습니다.

포함과 제외를 모두 명시합니다. 회계 ERP 자동 연동, 외부 마켓플레이스 입점(Wildberries·Ozon 등), 모바일 앱, SNS 마케팅 자동화, 검색·추천 엔진 — 이번 견적에서는 모두 1차 제외로 정리했습니다. 1차에 다 넣으면 일정·비용이 부풀고, 정작 가장 중요한 "현지에서 빠르게 팔리기 시작하는" 단계가 늦어집니다. 제외 항목을 명시해야 나중에 "그건 별도입니다" 라는 분쟁이 생기지 않습니다.

인프라 계약은 고객사가 직접 하시도록 권장했습니다. Google Cloud·AWS 가입과 설정은 저희가 안내드리지만 계약 자체는 고객사 명의로 직접. 개발사가 인프라 청구를 대행하면 사이에 마진이 붙고 — 무엇보다 고객사가 자기 인프라를 직접 통제할 수 없는 구조가 됩니다. 운영을 길게 가져가실 거라면 처음부터 직접 계약이 맞습니다.

PG 가맹은 PG사와 고객사가 직접 진행하시는 것이 원칙입니다. 사업자 심사가 포함되는 영역이라 개발사가 중간에 개입할 수 없습니다. 이번 케이스에서는 우즈벡 법인과 UZS 계좌 보유가 이미 확인된 상태였습니다 — 가맹의 출발선은 통과한 셈입니다. 다만 한국 기준으로 PG 가맹 심사가 통상 3~4주 소요되고, 우즈벡 Payme·Click 도 비슷하거나 더 길어질 수 있습니다. 일정에 미리 반영해 두지 않으면 개발이 끝났는데 결제만 못 붙는 시점이 생깁니다.

또 하나의 흔한 케이스 — 가맹 심사 단계에서 사이트가 먼저 필요한 경우입니다. PG사가 심사 과정에서 실제 동작하는 사이트의 결제 흐름을 확인하려는 경우인데, 이때는 임시 데모 페이지 형태로 결제 호출 흐름까지 미리 준비해 드립니다. 가맹 완료 후 API 키와 문서(또는 PG사 시스템 접속 권한)를 자사로 전달해 주시면 본 결제 모듈을 연동하는 구조가 표준입니다. 가맹을 개발사가 대행한다는 견적은 그 자체가 위험 신호일 수 있습니다. (PG 직접 계약과 솔루션 수수료 구조 비교는 커머스 PG 직접 계약 vs 솔루션: 수수료 구조의 진실 에서 다뤘습니다.)

호스팅 마이그레이션은 별도 비용으로 명시합니다. 추후 우즈벡 현지 호스팅으로 옮기실 가능성이 있다면, 초기 셋업 시점의 변경은 견적 안에 포함되지만 운영 중인 서버를 옮기는 경우는 별도 마이그레이션 비용이 발생한다는 점을 명시했습니다. 운영 단계의 변경은 데이터 이전·DNS 전환·다운타임 관리·재테스트가 모두 따라붙기 때문입니다.

다국어 운영 — AI 1차 번역 + 우즈벡 직원 검수의 두 갈래

다국어 사이트라는 한 줄 뒤에는 운영 단계의 무거움이 숨어 있습니다. 사이트가 우즈벡어·러시아어·영어를 지원한다는 건 콘텐츠가 추가되거나 바뀔 때마다 세 번 작업해야 한다는 뜻이기 때문입니다. 그 부담을 운영자가 직접 짊어지는 형태로 만들면 결국 한두 달 만에 다국어가 사실상 멈춥니다.

그래서 콘텐츠를 두 갈래로 나눠 처리합니다.

① 사이트 고정 텍스트 (i18n). 메뉴·버튼·안내 메시지·푸터·법적 고지 등 사이트 골격에 박히는 텍스트입니다. 영어 기준으로 번역 필요 항목을 자동으로 리스트업한 뒤 구글 스프레드시트로 정리합니다. 1차로 AI 번역(우즈벡어·러시아어)을 채워 둔 상태로 시트를 우즈벡 현지 직원분에게 전달드리면, 직원분이 검수·수정 후 시트를 자사로 회신해 주시고, 저희가 시트의 검수본을 사이트에 적용합니다. 이후 신규 텍스트가 생기면 시트의 빈 행만 채우는 형태로 같은 사이클이 반복됩니다.

② 동적 콘텐츠 (상품). 1,000개의 상품 — 그리고 그 이후 추가될 상품들 — 의 이름·설명·옵션을 매번 시트로 빼고 적용하는 흐름은 운영 부담이 너무 큽니다. 그래서 관리자 페이지의 상품 등록 폼 안에 3개 언어 입력란을 함께 표시합니다. 운영자가 한 번 등록하면 3개 언어가 동시에 사이트에 반영되는 구조입니다. 한국어로 먼저 입력한 뒤 "AI 번역" 버튼으로 세 언어를 자동 채우고 검수만 하시는 흐름도 옵션으로 제공합니다.

결제 통화는 UZS(우즈벡 숨) 단일로 처리합니다. 3개 언어를 지원하더라도 통화를 셋으로 가져가는 건 환율 노출과 정산 복잡성을 통째로 올리는 결정이라, 자사몰의 1차 운영에는 어울리지 않는다고 봤습니다.

멀티셀러 — 미루는 것과 1차에 반영하는 것의 차이

1차 오픈에는 단일 셀러 구조로 진행하기로 했습니다. 그렇다고 멀티셀러를 1차 DB에서 완전히 빼 두면, 나중의 마이그레이션 비용이 견적의 적지 않은 부분이 될 수 있습니다. 그래서 절차를 둘로 나눠 다뤘습니다.

1차에 만들지 않는 것 — 비즈니스 로직. 운영자 권한 분리, 셀러별 정산 흐름, 셀러별 환불 책임 분리, 셀러 onboarding UI 등이 여기에 해당합니다. 운영 데이터 없이 처음부터 만들면 결국 추측 기반의 설계가 됩니다. 셀러마다 정산 주기가 다를지, 수수료 구조가 단일일지 차등일지, 환불 책임이 셀러별인지 자사 통합인지 — 이런 결정은 실제 셀러를 한두 곳 모셔 본 뒤에야 비로소 보입니다.

1차에 반영해 두는 것 — DB 구조. 상품·주문·정산·재고 테이블에 seller_id 같은 식별자 컬럼을 처음부터 두고, 단일 셀러 운영 동안에는 모든 레코드가 자사 단일 값을 가집니다. 주문 안의 라인 아이템마다 어떤 셀러의 상품인지 식별이 가능한 형태로 둡니다. 정산 모델도 1셀러 = 자사라는 단순한 형태로 시작하지만, 정산 단위 자체는 셀러별로 떨어질 수 있게 컬럼 구조를 잡습니다.

이 둘을 함께 가져가면, 1차 → 2차 전환 시점에 데이터 마이그레이션은 사실상 필요하지 않고 새 셀러를 추가하면서 비즈니스 로직(권한·UI·정산 분리)을 붙이는 것이 작업의 본체가 됩니다. 그게 결국 1차 견적에 들어가는 약간의 추가 설계 비용으로 2차의 큰 마이그레이션 비용을 사 두는 거래입니다.

본격 멀티셀러 구현 시점은 1차 오픈 후 3~4개월, 실제 운영 데이터를 보신 다음에 재검토하시는 것을 권장드렸습니다.

국내 문의에도 같은 방식으로 답합니다 — 솔루션으로 풀리면 솔루션을 권합니다

이번 우즈벡 케이스가 특별해서 현지 파트너를 함께 추천한 건 아닙니다. 국내 쇼핑몰 제작 문의가 들어올 때도 처음 하는 일은 같습니다 — 이 사업이 어떤 그레이드에서 풀어야 하는 문제인지를 먼저 판별합니다.

실제로 들어오는 국내 문의의 상당수는 카페24·그누보드·아임웹 같은 솔루션 선에서 충분히 풀리는 경우입니다. 핵심 기능(상품 등록·결제·배송·관리자) 이 솔루션 안에 이미 갖춰져 있고, 디자인과 일부 customizing 만 더하면 사업이 출발할 수 있는 상태인 경우가 많습니다. 이번 우즈벡 케이스에서 1C-Bitrix 파트너를 권해 드린 것과 같은 방식으로, 국내 문의에도 "저희와 자체 개발로 가실 필요는 없고, 카페24·그누보드·아임웹 작업이 주력인 회사 쪽이 맞을 것입니다" 라고 답하고 솔루션을 함께 추천드립니다.

저희 회사가 실제로 받아야 하는 일은 솔루션의 가정을 더 이상 따라갈 수 없는 사업입니다. 매출 규모가 수백억 이상이라 솔루션의 운영 한계(데이터 양·트래픽·정산 처리)와 부딪히는 경우, 멀티셀러·중개·정산 구조처럼 솔루션이 처음부터 가정한 단일 셀러 모델과 어긋나는 경우, 위치 기반 상품처럼 일반 e-commerce 솔루션이 다루지 않는 데이터 모델이 필요한 경우 — 이런 사업들이 자체 개발 그레이드에 들어와야 하는 이유 그 자체가 됩니다.

그러니까 이번 우즈벡 견적의 "현지 1C-Bitrix 파트너도 함께 보시라" 는 한 줄은, 국내에서 매주 하는 "카페24·그누보드 쪽이 맞을 것입니다" 와 정확히 같은 종류의 답입니다. 시장이 바뀌었을 뿐 판단 절차는 동일합니다.

왜 자기 영업을 깎는 한 줄을 적었는가

자사 견적과 현지 1C-Bitrix 파트너를 함께 권한다는 한 줄은 영업 입장에서 깎이는 한 줄입니다. 그럼에도 이걸 적는 이유는 단순합니다 — 고객의 사업이 잘되는 게 결국 우리에게도 좋고, 잘못된 그레이드 선택의 가장 큰 비용은 사업 시기를 놓치는 것이라는 사실 때문입니다.

견적사가 자기 견적만을 옹호하는 견적은, 그 자체로 하나의 신호입니다. 모든 요구가 "다 된다" 고 답하는 견적도, 자기 견적이 모든 상황의 정답이라고 말하는 견적도 — 같은 종류의 무한 약속입니다. 실제로 만들어야 하는 쪽은 자기 견적의 한계를 함께 말할 수밖에 없습니다.

이번 케이스에서 고객은 두 옵션을 함께 검토하실 것이고, 어느 쪽으로 결정하시든 그 결정은 더 나은 정보 위에서 이뤄질 것입니다. 만약 자사를 선택하신다면, 그 선택은 가격이 아니라 한국 본사 통합·법적 책임·브랜드 자유도라는 분명한 이유 위에서 이뤄지는 선택이 됩니다 — 그게 처음부터 우리가 받고 싶은 종류의 일입니다.

정리

견적은 가격표가 아닙니다. 그 가격으로 무엇이 만들어지고, 어떤 그레이드에서 풀어야 하는 문제이며, 같은 그레이드 안에서 누가 만드는 것이 더 나은가 — 이 모든 판단을 같이 적는 문서입니다. 그 안에 "저희 말고 다른 곳이 더 나을 수 있다" 는 가능성이 빠져 있다면, 그 견적은 정직한 견적이 아닙니다.

외주 개발 견적을 어떻게 판단하는지의 큰 그림은 외주 개발 견적, 어떻게 판단할까? 에 정리해 두었습니다.

*해외 자사몰·다국어 e-commerce·CIS 시장 진출 관련 견적 문의는 프로젝트 상담으로 부탁드립니다. 개발 계약과 무관하게 견적 자문을 제공합니다.*


견적,외주개발,해외진출,자사몰,우즈베키스탄,CIS,Bitrix,다국어,멀티셀러,PG
다른 포스팅
WebGL프로젝트 상담