자사몰 구축, 솔루션을 벗어나야 하는 시점 — 자체 구축 전에 정해야 할 6가지

자사몰 구축을 다시 검토하게 되는 순간은 대개 비슷합니다. 매출이 꺾여서가 아니라, 몇 년째 문제없이 돌아가던 자사몰에 지금까지 없던 요구가 하나 들어왔을 때입니다. 법인 고객이 견적서를 받고 대량으로 주문하고 싶다고 하거나, 제휴사 복지몰에 입점하면서 포인트 사용분과 기업 부담분을 월 단위로 분리 정산해 달라는 요청이 오거나, 멤버십 등급마다 다른 단가를 적용해야 하거나, 해외 주문을 받아 직접 배송해야 하는 상황입니다.

담당자는 솔루션사에 문의합니다. 그리고 비슷한 답을 받습니다. “그건 저희 솔루션에서는 지원하지 않습니다.” 또는 “앱을 붙이면 화면까지는 비슷하게 되는데, 정산 처리는 안 됩니다.” 그때부터 운영이 둘로 갈라집니다. 일부는 솔루션 안에서 처리되고, 나머지는 엑셀과 메일로 사람이 메웁니다. 처음에는 임시방편이지만 몇 달이 지나면 그 수기 작업이 팀의 고정 업무가 되어 있습니다.

이 글은 어떤 솔루션이 더 나은지를 비교하지 않습니다. 그 비교는 이미 충분히 많고, 지금 이 글을 읽는 분의 문제도 아닙니다. 이 글은 그 비교가 끝난 지점, 즉 솔루션으로는 처리되지 않는 요구가 생긴 시점에서 시작합니다. 언제 솔루션을 벗어나야 하는지, 그리고 자체 구축으로 넘어간다면 발주 전에 무엇을 정해 두어야 하는지를 다룹니다.

디비컨설팅(디비스쿨)은 시원스쿨 계열의 IT 아웃소싱 기업입니다. 한국인 PM이 검증된 글로벌 개발팀을 관리하는 구조로 100건 이상의 웹·플랫폼 구축 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 협업하고 있으며 고객 만족도는 98%입니다. LS일렉트릭 테크스퀘어 산업 B2B 거래 플랫폼, 삼성물산 홈닉 주거 플랫폼 앱, GS건설 엘리시안 리조트 웹·앱, 직방 호갱노노, 와디즈 글로벌 플랫폼 등을 함께 만들었습니다. 교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 구축 경험을 쌓았습니다.

솔루션이 한계에 닿는 지점은 기능이 아니라 구조입니다

솔루션을 벗어날 때인지 판단할 때, 대부분 기능 목록부터 비교합니다. 이 솔루션은 다국어가 되는지, 저 솔루션은 구독 결제가 되는지를 표로 만들어 봅니다. 그런데 실제로 발목을 잡는 것은 없는 기능이 아니라, 솔루션이 전제하고 있는 표준 구조입니다. 솔루션은 ‘개인 고객이 정해진 가격으로 결제하고 한 번에 매출이 잡히는’ 흐름을 기준으로 설계되어 있고, 그 기준을 벗어나는 요구는 기능을 추가해도 깔끔하게 들어맞지 않습니다. 한계에 닿았는지는 아래 세 가지로 확인할 수 있습니다.

주문과 정산 로직이 표준을 벗어날 때

법인 거래가 들어오는 순간 주문서의 성격이 달라집니다. 같은 상품인데 계약한 법인마다 단가가 다르고, 결제가 아니라 여신으로 먼저 출고한 뒤 월말에 청구해야 하며, 세금계산서는 주문 단위가 아니라 거래처·월 단위로 합산해 발행해야 합니다. 복지몰에 입점하면 한 건의 주문 안에서 임직원이 쓴 포인트와 회사가 부담하는 금액이 분리되고, 그 분리된 값이 제휴사 정산 파일과 맞아떨어져야 합니다. 선정산이냐 후정산이냐에 따라 매출 인식 시점도 달라집니다.

이런 요구는 화면을 바꾼다고 해결되지 않습니다. 주문과 결제, 정산이 각각 별도의 단계로 나뉘어 있어야 처리되는데, 솔루션에서는 이 셋이 하나로 묶여 있는 경우가 많습니다. 그래서 커스터마이징으로 메우면 주문 데이터 한 줄에 예외 조건이 계속 쌓이고, 결국 정산 담당자가 매달 수기로 검증하게 됩니다. 이런 항목이 하나뿐이라면 아직은 커스터마이징으로 버틸 구간입니다.

외부 시스템과 연결되어야 할 때

규모가 커지면 자사몰은 더 이상 독립된 사이트가 아닙니다. ERP의 품목 코드와 재고가 기준이 되어야 하고, 출고는 WMS가 처리해야 하며, 할인 승인이나 법인 거래 등록은 그룹웨어 결재를 거쳐야 합니다. 임직원 전용몰이라면 사내 계정으로 로그인되는 SSO가 요구됩니다. 각 연동은 단순히 데이터를 주고받는 수준이 아니라, 어느 쪽이 원본을 가지고 어느 쪽이 따라가는지를 정해야 하는 문제입니다. 이는 사내 시스템 구축에서 반복적으로 나타나는 문제와 같은 구조입니다.

여기서 솔루션의 제약이 분명해집니다. 솔루션이 API로 열어 둔 범위 안에서만 연동이 가능하고, 열려 있지 않은 영역은 CSV를 내려받아 사람이 옮기게 됩니다. 결과적으로 솔루션의 API가 열어주는 범위가 곧 우리 회사의 업무 범위가 됩니다. 업무 프로세스를 시스템에 맞추는 상황이 반복된다면, 앞의 정산 문제와 함께 두 번째 신호로 봐야 합니다.

데이터가 우리 것이 아닐 때

화면에서 보이는 데이터와 밖으로 가져올 수 있는 데이터는 다릅니다. 회원 목록과 주문 내역은 대부분 내려받을 수 있지만, 비회원 주문, 장바구니 이력, 상태 변경 로그, CS 응대 기록, 쿠폰 사용 이력처럼 분석과 재구매 설계에 실제로 필요한 데이터는 받지 못하거나 가공된 형태로만 받게 되는 경우가 있습니다. 비밀번호처럼 암호화되어 이전 자체가 불가능한 항목도 있습니다.

이 문제는 평소에는 드러나지 않다가 옮기려 할 때 한꺼번에 드러납니다. 회원 재인증 절차를 새로 만들어야 하고, 주문 이력이 특정 시점에서 끊기며, 끊긴 구간을 맞추느라 이관 작업 자체가 하나의 프로젝트가 됩니다. 같은 문제를 레거시 시스템 전환에서도 그대로 보게 됩니다. 정산 로직이 표준을 벗어났고, 연동이 막혀 있고, 데이터까지 우리 통제 밖이라면 세 가지가 모두 걸린 것입니다. 하나만 걸리면 커스터마이징으로 해결할 문제지만, 셋 다 걸리면 구조를 바꿀 때입니다.

그래서 선택지는 ‘어떤 솔루션이냐’가 아닙니다

구조를 바꾸기로 했다면 다음 질문은 “어디에 맡길 것인가”가 됩니다. 현실적으로 선택지는 세 가지입니다. 국내 개발사에 발주하거나, 해외 개발팀에 직접 발주하거나, 한국인 PM이 글로벌 개발팀을 관리하는 구조를 쓰는 것입니다. 업체 유형별 차이는 개발 외주 업체 고르는 법에서 더 자세히 다뤘습니다.

이 셋을 비교할 때 개발 단가만 놓고 보면 판단을 그르칩니다. 실제로 프로젝트의 성패를 가르는 변수는 요구사항을 정의하는 책임이 누구에게 있는지, 그리고 발주사 담당자가 여기에 몇 시간을 쓰게 되는지입니다. 이 두 가지가 재작업의 양을 결정하고, 재작업이 총비용을 결정합니다.

구분	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 직접 발주가 기대만큼 저렴해지지 않는 이유는 분명합니다. 단가는 낮지만 요구사항 문서를 쓰고, 일정을 관리하고, 산출물을 검수하는 일이 전부 발주사 몫으로 넘어오기 때문입니다. 이 역할은 원래 PM의 일이고, PM의 일을 하려면 개발 프로세스를 아는 사람이 필요합니다. 사내에 개발 조직이 없는 회사에서는 이 일을 맡을 사람이 마케팅이나 운영 담당자이고, 그분은 본업을 하면서 영어로 시차를 넘겨가며 스펙을 설명하게 됩니다.

그 결과는 대부분 재작업으로 나타납니다. 말로 전달된 요구는 받는 쪽의 해석대로 구현되고, 다른 결과물을 받은 뒤에야 설명이 부족했다는 사실을 알게 됩니다. 디비컨설팅이 IT 아웃소싱 구조의 가운데에 한국인 PM을 두는 이유가 여기에 있습니다. 발주사는 한국어로 요구를 말하고, 그것을 개발팀이 작업할 수 있는 문서로 바꾸는 책임은 PM이 집니다. 국내 채용 대비 평균 40~60% 비용 절감이 가능한 것도 단가 때문만이 아니라, 재작업을 줄여 실제 투입 기간을 줄이기 때문입니다.

자체 구축으로 간다면, 발주 전에 정해야 할 6가지

1. 상품과 주문 데이터 모델을 누가 정의하는가

자사몰의 품질은 화면이 아니라 데이터 모델에서 결정됩니다. 상품을 옵션 조합으로 볼 것인지 개별 품목으로 볼 것인지, 법인별 계약 단가를 상품에 붙일 것인지 거래처에 붙일 것인지, 한 주문이 여러 출고지로 나뉠 수 있는지를 처음에 정해야 합니다. 이 결정이 바뀌면 나중에는 화면 몇 개가 아니라 전체를 다시 손봐야 합니다.

따라서 발주 전에 확인해야 할 것은 “이 모델을 누가, 언제, 어떤 문서로 확정하는가”입니다. 개발사가 알아서 해 주겠거니 하고 넘어가면, 대부분 개발사가 가진 기존 템플릿대로 만들어지고 우리 거래 구조는 그 템플릿에 맞춰 왜곡됩니다. 요구사항 정의서를 어느 수준까지 써야 하는지도 이 시점에 합의해야 합니다.

2. 결제와 정산은 어디까지가 범위인가

결제는 PG 연동으로 끝나지만 정산은 그렇지 않습니다. 법인 여신과 월 단위 청구, 세금계산서 발행 주체와 발행 단위, 복지몰 포인트의 부담 주체 분리, 부분 취소와 환불 시 정산 역처리까지가 범위에 들어가는지 명시해야 합니다. 구독이나 멤버십 과금이 있다면 정기 결제 실패 시의 재시도와 해지 정책도 범위입니다.

이 항목은 견적 차이가 가장 크게 벌어지는 부분입니다. “결제 연동 포함”이라는 한 줄로 받은 견적과, 정산 시나리오까지 항목으로 나뉜 견적은 같은 금액대여도 내용이 전혀 다릅니다.

3. 기존 솔루션의 데이터를 어디까지 가져올 것인가

회원, 주문, 배송, 쿠폰, 리뷰, CS 이력 중 무엇을 가져올지 목록으로 정하고, 각 항목이 실제로 내보내기 가능한지 솔루션사에 먼저 확인해야 합니다. 가져올 수 없는 데이터는 오픈 이후 운영 시나리오로 보완해야 하므로, 기획 단계에서 알아야 합니다.

비밀번호처럼 이전이 불가능한 항목은 재설정 안내를 어떻게 할지까지 정해 두는 편이 안전합니다. 이관은 기술 작업이 아니라 고객 경험 설계에 가깝습니다.

4. 운영자가 쓸 관리자 화면의 범위는 어디까지인가

자체 구축에서 가장 자주 과소평가되는 영역이 관리자 페이지입니다. 고객이 보는 화면은 꼼꼼히 검토하면서, 매일 쓰는 주문 관리·정산 조회·상품 등록 화면은 “기본 제공”으로 넘어갑니다. 그러면 오픈 후에 운영팀이 솔루션 시절보다 더 불편한 도구를 쓰게 됩니다.

운영 담당자별 권한, 승인 흐름, 대량 등록과 일괄 변경, 자주 쓰는 조회 조건까지 범위에 넣어야 합니다. 관리자 화면의 완성도가 자체 구축을 선택한 효과를 실제로 체감하게 만드는 부분입니다.

5. 트래픽이 몰리는 날의 책임은 누구에게 있는가

프로모션 오픈이나 대규모 발주가 몰리는 날을 기준으로 목표 처리량을 정하고, 그 기준을 누가 보증하는지 계약에 넣어야 합니다. 인프라 구성과 부하 테스트가 범위에 포함되는지, 장애 발생 시 연락 체계와 대응 시간이 어떻게 되는지를 함께 정합니다. 자세한 기준은 서버 운영 유지보수에서 정리했습니다.

솔루션을 쓸 때는 이 책임이 솔루션사에 있었습니다. 자체 구축으로 넘어가는 순간 이 책임도 함께 넘어오므로, 운영 단계의 역할 분담을 구축 견적과 같은 시점에 확정하는 것이 맞습니다.

6. 끝난 뒤 소스코드와 문서는 누구 것인가

소스코드는 발주사 귀속입니다. 디비컨설팅은 프로젝트 종료 시 소스코드와 함께 API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 이 세 가지가 있어야 이후에 다른 팀이 이어받더라도 분석부터 다시 시작하지 않습니다.

발주 전에 계약서에서 확인할 문장은 소유권 조항 하나가 아니라 인계 산출물의 목록입니다. 소유권은 있는데 문서가 없으면, 실질적으로는 만든 팀 외에는 손댈 수 없는 시스템이 됩니다.

디비컨설팅은 이 과정을 어떻게 통제합니까

1. 상담 및 요구 분석 — 한국인 PM이 한국어로 요구사항을 정리해 문서로 확정합니다. 주문·정산 흐름, 연동 대상 시스템, 관리자 화면 범위를 화면 단위가 아니라 처리 단계 단위로 적습니다. 재작업의 대부분은 말로 전달된 요구가 다르게 해석되면서 생기는데, 이 단계에서 해석의 여지를 없애기 때문에 뒤에서 되돌아오는 작업이 줄어듭니다.
2. 개발팀 구성 — 확정된 요구사항에 맞춰 필요한 역할만 모아 전담팀을 구성합니다. 소요 기간은 2~4주입니다.
3. 프로젝트 개발 — 애자일 방식으로 짧은 주기마다 동작하는 결과물을 내고, 진행 상황을 투명하게 공유합니다. 발주사는 완성 직전이 아니라 중간에 방향을 바꿀 수 있습니다.
4. 테스트 및 배포 — QA를 거쳐 릴리스합니다. 주문·결제·정산처럼 틀리면 돌이키기 어려운 영역은 실제 데이터에 가까운 조건으로 검증합니다.
5. 운영 및 유지보수 — 오픈 이후 운영을 이어가며, 인계 시에는 소스코드와 문서까지 함께 넘깁니다.

실제 구축 사례

• LS일렉트릭 테크스퀘어 — 산업 분야 B2B 거래 플랫폼. 법인 간 거래와 매칭 로직이 복잡하게 얽힌 구조로, 법인 거래가 들어온 자사몰이 마주하는 문제와 가장 가깝습니다.
• 삼성물산 홈닉 — 주거 플랫폼 앱. 사용자 인증과 권한에 따라 제공되는 기능이 달라지고 다수의 외부 서비스와 연결되는 구조를 다뤘습니다.
• 직방 호갱노노 — 대량 데이터 조회와 트래픽이 집중되는 서비스. 성능과 안정성을 설계 단계부터 기준으로 잡아야 하는 사례입니다.
• 와디즈 글로벌 플랫폼 — 국내 서비스를 해외 사용자 대상으로 확장하는 작업. 다국어와 지역별 처리 분기를 다룹니다.
• 가천대학교 학사관리 시스템 — 역할별 권한과 승인 흐름이 많은 내부 관리 시스템. 관리자 화면의 범위를 어디까지 설계해야 하는지 보여주는 사례입니다.
• 센터필드·센트로폴리스·그랑서울 오피스 빌딩 관리 시스템 — 운영자가 매일 사용하는 도구. 실제 업무 흐름에 맞춘 운영 화면 설계가 핵심이었습니다.

그 밖의 구축 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합합니다

• 복지몰 입점이나 법인 대상 B2B 거래가 매출의 한 축인 기업
• 멤버십 등급이나 구독 과금처럼 반복·조건부 결제 구조가 필요한 기업
• 다국어 지원과 해외 배송을 직접 처리해야 하는 기업
• ERP·WMS·그룹웨어와 실시간으로 맞물려야 하는 기업
• 자체 물류를 운영해 출고와 재고를 직접 통제하는 기업
• 사내에 개발 조직이 없어 요구사항을 문서로 옮겨 줄 역할이 필요한 기업

반대로 권하지 않습니다

• 상품 수가 많지 않고 주문 플로우가 표준적인 경우. 이때는 솔루션이 맞습니다. 자체 구축은 비용과 운영 부담만 늘립니다.
• 지금 당장 2주 안에 오픈해야 하는 경우. 전담팀 구성에만 2~4주가 걸리므로, 일정이 고정되어 있다면 솔루션으로 먼저 열고 다음 단계를 준비하는 편이 낫습니다.
• 요구사항을 정의하고 의사결정을 해 줄 담당자를 한 명도 지정할 수 없는 경우. PM이 문서를 만들어도 확인하고 결정할 사람이 없으면 프로젝트는 진행되지 않습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 영어로 개발팀과 직접 이야기할 일은 없습니다. 요구사항 정의, 일정 관리, 산출물 검수는 PM의 책임이며, 개발팀과의 커뮤니케이션도 PM이 담당합니다.

비용은 어떻게 산정되나요?

투입 인력의 등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 영역에 비용이 쓰이는지 확인하실 수 있습니다. 국내 채용 대비 평균 40~60% 절감이 가능합니다.

기획서가 없는데 견적이 가능한가요?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 희망 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 상세 기획은 상담 및 요구 분석 단계에서 PM이 함께 정리합니다.

팀 규모를 중간에 조정할 수 있나요?

가능합니다. 전담팀 구성, 장기 협업, 인력 단위 투입, 프로젝트 단위 수행 중에서 선택할 수 있고, 진행 중에도 범위 변화에 맞춰 인원을 늘리거나 줄일 수 있습니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. 소스코드와 함께 API 명세, DB 스키마, 배포 절차 문서까지 인계합니다.

정리

자사몰 구축의 진짜 분기점은 솔루션의 기능 목록에 있지 않습니다. 우리 회사의 주문과 정산, 연동, 데이터 요구가 표준을 벗어났는지, 그리고 그 요구를 개발팀이 작업할 수 있는 문서로 바꿔 줄 사람이 내부에 있는지에 있습니다. 앞쪽이 ‘그렇다’이고 뒤쪽이 ‘아니다’라면, 필요한 것은 더 나은 솔루션이나 더 싼 개발 단가가 아니라 한국인 PM이 붙은 개발 파트너입니다.