요약 — SI 업체 선정에서 가장 많이 놓치는 것은 단가의 구성입니다. 국내 SI 견적은 대부분 인건비(M/M)에 묶여 있어 업체를 바꿔도 구조적으로 큰 차이가 나지 않습니다. 비용이 실제로 달라지는 지점은 어느 나라의 인력이 구현을 맡는가입니다. 이 글은 SI 단가가 어떻게 만들어지는지, 해외 개발팀으로 전환할 때 무엇이 절감되고 무엇이 위험해지는지를 정리합니다.
SI 업체를 비교할 때 실제로 비교해야 하는 것
SI(System Integration) 프로젝트 견적을 서너 곳에서 받아보면 금액이 비슷하게 수렴하는 경우가 많습니다. 우연이 아닙니다. 국내 SI 단가는 대부분 투입 인력 × 기간(M/M, Man-Month)으로 산정되고, 등급별 단가는 한국소프트웨어산업협회가 공표하는 SW기술자 평균임금을 기준선으로 삼기 때문입니다.
즉 업체를 바꾸는 것은 대체로 같은 단가표 안에서 공급자만 바꾸는 일입니다. 견적서 세 장을 비교하는 것보다, 그 견적이 어떤 구조 위에서 만들어졌는지를 보는 편이 훨씬 유효합니다.
견적서에서 확인해야 할 네 가지
투입 인력의 등급 구성 — 초급·중급·고급·특급 비율. 같은 총액이라도 고급 2명과 초급 4명은 결과가 다릅니다.
실제 투입률 — 0.5 M/M로 잡힌 인력이 몇 개의 다른 프로젝트를 병행하는지. 명목 투입과 실제 투입의 차이가 지연의 주된 원인입니다.
하도급 구조 — 계약 상대와 실제 개발 주체가 다른 경우가 많습니다. 2차·3차 하도급이 들어가면 단가는 그대로인데 품질 통제력은 떨어집니다.
유지보수 조건 — 검수 후 하자보수 기간, 그 이후의 연간 유지보수율(보통 개발비의 10~15%).
국내 SI 시장의 구조적 제약
비용을 떠나, 지금 국내 SI 프로젝트를 어렵게 만드는 조건이 몇 가지 있습니다.
인력 수급
중급 이상 개발자의 공급이 수요를 따라가지 못합니다. 그 결과 프로젝트 착수 시점에 약속된 인력 구성이 유지되지 않거나, 투입이 지연되거나, 등급이 낮은 인력으로 대체되는 일이 반복됩니다. 이것은 특정 업체의 성실성 문제가 아니라 시장 전체의 조건입니다.
단가의 하방 경직성
인건비 기반 산정은 물가와 임금을 따라 올라갈 뿐 내려가지 않습니다. 같은 범위의 프로젝트가 3년 전보다 비싸졌다면 대부분 이 때문입니다.
범위 변경 비용
M/M 계약에서 요구사항이 바뀌면 곧바로 추가 M/M으로 환산됩니다. 착수 시점에 요구사항을 완벽히 확정하기 어려운 프로젝트일수록 최종 비용이 초기 견적에서 멀어집니다.
해외 개발팀으로 전환하면 무엇이 달라지는가
구현 인력을 해외 팀으로 옮기면 단가의 기준선 자체가 바뀝니다. 디비컨설팅의 경우 한국인 PM이 기획·요구사항 정의·일정 관리·품질 검수를 맡고, 인도 개발팀이 구현을 담당하는 구조입니다. 100건 이상의 프로젝트에서 국내 개발 대비 평균 56%의 비용 절감이 나왔습니다.
다만 절감의 출처를 정확히 이해하는 편이 좋습니다. 이 차이는 개발자의 역량 차이에서 오는 것이 아니라 인건비 시장의 차이에서 옵니다. 같은 수준의 결과물을 더 싸게 만드는 것이지, 싼 만큼 덜 만드는 것이 아닙니다. 그리고 그 차이가 유지되려면 조건이 필요합니다.
이 구조가 작동하기 위한 조건
위험
이 구조에서의 대응
언어와 커뮤니케이션
발주사는 한국인 PM하고만 한국어로 소통합니다. 해외 팀과 직접 대화할 일이 없습니다.
시차
인도와 한국은 3시간 30분 차이로, 근무시간이 상당 부분 겹칩니다. 미주·유럽 대비 실시간 대응이 쉽습니다.
요구사항 해석 오류
요구사항 정의서를 한국인 PM이 작성하고 개발 착수 전에 발주사 승인을 받습니다. 해석의 책임이 국내에 있습니다.
품질 편차
검수 기준을 계약서에 명시하고, 산출물 단위로 국내에서 1차 검수한 뒤 발주사에 전달합니다.
인수인계
문서·소스·배포 환경을 국내 기준으로 정리해 전달합니다.
솔직하게, 이 구조가 맞지 않는 경우
모든 프로젝트에 적합하지는 않습니다. 다음에 해당한다면 국내 SI가 더 나을 수 있습니다.
망분리·상주 개발이 계약 조건인 경우 — 공공 및 일부 금융 프로젝트는 물리적 상주를 요구합니다.
요구사항이 매일 바뀌는 초기 탐색 단계 — 문서화 부담이 절감폭보다 클 수 있습니다.
국내 레거시 시스템과의 밀착 연동이 대부분인 경우 — 특히 문서화되지 않은 사내 시스템이 많다면 현장 접근성이 더 중요합니다.
전체 규모가 매우 작은 경우 — 관리 오버헤드가 절감분을 상쇄합니다.
실제 수행 사례
디비컨설팅이 이 구조로 수행한 엔터프라이즈 프로젝트입니다.
삼성물산 — 홈닉: 입주민 커뮤니티, 시설 예약, IoT 기기 제어, 컨시어지 연동을 통합한 스마트홈 플랫폼
LS일렉트릭 — 테크스퀘어: 대기업 사내 기술 플랫폼 설계 및 구축
GS건설 — 엘리시안 리조트: 리조트 예약·이용 웹 및 앱
하나투어 — 하나오픈챗: 여행 커뮤니케이션 서비스
가천대학교: 학사관리 시스템
메가존 — 복지몰: 상품·주문·결제·회원 관리를 포함한 사내 이커머스
모두 발주사가 한국인 PM과 한국어로 소통하고, 구현은 인도 개발팀이 담당한 프로젝트입니다.
전환을 검토할 때의 순서
현재 견적의 M/M 구성을 확인합니다. 등급별 인원과 기간이 나와 있지 않다면 먼저 요청하세요. 비교의 출발점입니다.
요구사항 정의서가 있는지 확인합니다. 없다면 이것부터 만드는 편이 좋습니다. 어느 업체와 하든 범위가 정의되지 않은 계약은 비용이 예측되지 않습니다.
상주·망분리 요건이 있는지 확인합니다. 있다면 해외 전환은 검토 대상이 아닙니다.
동일 범위로 두 구조의 견적을 받아 비교합니다. 총액이 아니라 범위·검수 기준·유지보수 조건을 나란히 놓고 봅니다.
자주 묻는 질문
SI 업체와 개발 외주는 다른 것입니까?
실무에서는 거의 같은 의미로 쓰입니다. SI는 전통적으로 기존 시스템 통합과 대규모 구축 사업을, 개발 외주는 단일 서비스 개발을 가리키는 경우가 많지만 경계는 뚜렷하지 않습니다. 계약 형태(도급/준위임)와 산정 방식이 실질적인 차이를 만듭니다.
56% 절감은 모든 프로젝트에 적용됩니까?
아닙니다. 100건 이상 프로젝트의 평균이며, 범위·기간·요구사항 안정성에 따라 달라집니다. 상주가 필요하거나 레거시 연동 비중이 큰 프로젝트에서는 절감폭이 줄어듭니다. 정확한 수치는 범위가 정의된 뒤에야 산출됩니다.
중간에 요구사항이 바뀌면 어떻게 됩니까?
변경은 어느 구조에서든 비용입니다. 다만 요구사항 정의서를 기준으로 변경분을 식별하고 영향 범위를 먼저 산정한 뒤 진행합니다. 구두 합의로 반영하고 나중에 정산하는 방식은 쓰지 않습니다.
소스코드와 지식재산권은 누구에게 있습니까?
계약에 따라 발주사에 귀속됩니다. 인수인계 시 소스·문서·배포 환경을 함께 전달합니다.
다음 단계
현재 검토 중인 SI 프로젝트의 범위가 정리되어 있다면 동일 범위로 비교 견적을 드릴 수 있습니다. 요구사항이 아직 정리되지 않았더라도 괜찮습니다 — 범위를 함께 정의하는 단계부터 시작합니다.
SI 프로젝트 비교 견적
같은 범위로 국내 견적과 비교해 보세요
디비컨설팅은 100건 이상의 프로젝트를 수행했습니다. 한국인 PM이 요구사항 정의와 일정 관리를 맡고 인도 개발팀이 구현을 담당하는 구조로 국내 개발 대비 평균 56%의 비용 절감을 만듭니다. 삼성물산, GS건설, LS일렉트릭, 하나투어, 가천대학교 등과 함께 일했습니다.
사내 시스템 구축을 검토하는 회사는 대부분 같은 장면에서 출발합니다. 부서마다 엑셀 파일이 따로 돌고, 같은 숫자를 두 번 세 번 옮겨 적고, 월말이 되면 누군가 남아서 취합합니다. 담당자가 바뀌면 그 파일이 어디 있는지부터 다시 찾아야 합니다. 그래서 시스템을 만들기로 합니다. 예산을 잡고, 개발사를 정하고, 몇 달 뒤에 오픈합니다.
그리고 반년쯤 지나면, 현업 담당자 모니터에 다시 엑셀 파일이 열려 있습니다. 시스템은 살아 있지만 실제 업무는 그 바깥에서 돌아갑니다. 결재만 시스템에 남기고, 진짜 일은 여전히 메신저와 전화로 처리합니다.
이 결과는 개발이 부실해서 생기는 일이 아닙니다. 화면은 다 있고 버튼도 다 눌립니다. 문제는 만들어진 시스템이 실제 업무와 다르게 생겼다는 것입니다. 그리고 그 차이는 개발이 아니라 발주 단계에서 결정됩니다.
디비컨설팅은 100건 이상의 프로젝트를 수행하면서, 대외 서비스보다 오히려 조직 내부에서 쓰는 시스템을 반복적으로 구축해 왔습니다. 가천대학교의 학사관리 시스템, 센터필드·센트로폴리스·그랑서울 등 프라임 오피스 빌딩의 관리 시스템, LS일렉트릭 테크스퀘어의 산업 B2B 거래 플랫폼이 그런 사례입니다. 이 글은 그 과정에서 반복해서 확인한 실패 지점과, 발주 전에 정리하면 대부분 예방되는 여섯 가지를 정리한 것입니다.
사내 시스템이 대외 서비스보다 실패하기 쉬운 이유
같은 규모, 같은 예산이라도 사내 시스템은 고객용 서비스보다 실패 확률이 높습니다. 기술 난도가 높아서가 아닙니다. 요구사항이 존재하는 방식이 다르기 때문입니다.
요구사항이 문서가 아니라 사람 머릿속에 있습니다
고객용 서비스는 기획서가 곧 정답입니다. 아직 없는 것을 만드는 일이니까요. 반면 사내 시스템은 이미 몇 년째 돌아가고 있는 업무를 옮기는 일입니다. 그 업무의 규칙은 문서가 아니라 오래 그 일을 해 온 담당자의 경험 안에 있습니다.
“이 거래처는 세금계산서를 월말에 한 번에 끊습니다”, “이 품목은 재고가 마이너스로 잡혀도 출고를 막으면 안 됩니다” 같은 규칙은 어느 문서에도 적혀 있지 않습니다. 물어보지 않으면 나오지 않고, 물어봐도 담당자는 그게 특별한 규칙이라고 인식하지 못합니다. 너무 당연해서 말할 생각을 못 하는 것입니다. 이런 규칙은 보통 오픈 직후, 시스템이 정상 처리를 거부할 때 처음 드러납니다.
발주 담당자와 실제 사용자가 다릅니다
대외 서비스는 발주하는 쪽과 성과를 보는 쪽이 대체로 같습니다. 사내 시스템은 다릅니다. 예산과 일정을 관리하는 사람은 경영지원이나 전산 담당이고, 매일 그 화면을 쓰는 사람은 영업·물류·회계 현업입니다.
그래서 검수는 통과하는데 현장에서는 쓰이지 않는 상황이 만들어집니다. 발주 담당자는 “요청한 기능이 다 있는지”를 확인하고, 현업은 “이걸로 오늘 일을 끝낼 수 있는지”를 봅니다. 기준이 다르면 결과도 다릅니다. 무엇을 완료로 볼 것인지의 문제는 개발 검수 기준에서 따로 다뤘습니다.
예외 처리가 업무의 절반을 차지합니다
정상 흐름만 놓고 보면 사내 시스템은 단순합니다. 등록하고, 승인하고, 처리하고, 마감합니다. 실제 업무 시간의 상당 부분은 그 바깥에서 소비됩니다. 승인자가 휴가일 때, 이미 마감한 달의 숫자를 고쳐야 할 때, 계약서와 실제 단가가 다를 때 어떻게 할 것인가.
견적서에는 보통 정상 흐름만 적힙니다. 예외 처리는 “협의”라는 두 글자로 넘어갑니다. 그리고 개발이 끝날 무렵 그 협의가 시작되면, 이미 만들어진 구조를 뜯어야 하는 상황이 됩니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 견적서에서 반복적으로 빠지는 항목은 관리자 페이지 개발 글에서도 같은 패턴으로 확인됩니다.
발주 전에 정리할 6가지
아래 여섯 가지는 개발사가 대신 정해 줄 수 없는 항목입니다. 발주사 안에서만 답이 나오고, 답이 없으면 개발 중에 반드시 재작업으로 돌아옵니다.
1. 이 시스템을 매일 여는 사람이 누구인가
부서 이름이 아니라 역할 단위로 적습니다. 하루에 열 번 쓰는 사람과 월말에 한 번 쓰는 사람은 필요한 화면이 다릅니다. 실사용자 서너 명의 이름을 적을 수 없다면, 아직 발주할 준비가 되지 않은 것입니다.
2. 지금 그 업무가 실제로 어떻게 돌아가는가
이상적인 모습이 아니라 현재 모습을 기록합니다. 지금 쓰는 엑셀 서식, 메신저로 오가는 확인 절차, 종이로 남기는 대장까지 포함합니다. 현행 업무를 적어 두지 않으면 개발사는 교과서적인 흐름을 가정하고, 그 가정은 거의 항상 틀립니다. 문서를 어느 수준까지 써야 하는지는 요구사항 정의서에 정리해 두었습니다.
3. 예외 처리를 어디까지 시스템이 감당할 것인가
모든 예외를 시스템에 넣으면 비용이 몇 배가 되고, 아무것도 넣지 않으면 현업이 다시 엑셀을 엽니다. 자주 일어나는 예외는 시스템에 넣고, 드문 예외는 관리자가 수동으로 처리할 수 있는 통로만 열어 두는 식으로 선을 그어야 합니다. 이 선을 발주 전에 긋는 것과 개발 중에 긋는 것은 비용이 전혀 다릅니다. 무엇을 1차에서 빼도 되는지는 MVP 개발 범위 기준을 참고하실 수 있습니다.
4. 기존 데이터를 어떻게 옮길 것인가
사내 시스템에는 항상 과거 데이터가 있습니다. 몇 년치 엑셀, 예전 시스템의 데이터베이스, 부서별로 다르게 적어 온 거래처명이 섞여 있습니다. 어디까지 옮길지, 형식이 안 맞는 값은 누가 정리할지, 정리 작업을 발주사가 할지 개발사가 할지를 먼저 정해야 합니다. 데이터 이관은 견적에서 가장 자주 누락되면서 실제로는 가장 오래 걸리는 작업 중 하나입니다.
5. 기존 시스템·외부 서비스와 무엇을 연동할 것인가
회계 프로그램, 그룹웨어, 사내 인증, 문자·알림톡, 세금계산서 발행처럼 이미 쓰고 있는 것들과 어디서 만날지 정해야 합니다. 연동 대상마다 문서가 있는지, 담당 벤더에게 협조를 받을 수 있는지도 함께 확인해야 합니다. 상대 쪽 문서가 없거나 담당자가 응답하지 않으면, 그 연동은 기술 문제가 아니라 일정 문제가 됩니다.
6. 오픈 이후 누가 바꿔 주는가
사내 시스템은 오픈이 끝이 아니라 시작입니다. 조직이 바뀌면 결재선이 바뀌고, 제도가 바뀌면 항목이 바뀝니다. 이 변경을 누가, 어느 속도로 처리할지 정해 두지 않으면 시스템은 6개월 만에 현실과 어긋나고, 그 시점에 현업은 엑셀로 돌아갑니다. 출시 이후의 대응 책임을 어떻게 정의하는지는 서버 운영·유지보수에서 자세히 다뤘습니다.
세 가지 발주 방식, 무엇이 실제로 다른가
사내 시스템을 맡길 때 선택지는 보통 세 가지입니다. 단가만 비교하면 판단을 그르치기 쉽습니다. 사내 시스템에서 진짜 변수는 현업의 업무 규칙을 누가 캐낼 것인가이기 때문입니다.
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
현업 인터뷰 가능 여부
가능
사실상 어려움
가능
요구사항 정의 책임
개발사
발주사 본인
한국 PM
커뮤니케이션 언어
한국어
영어
한국어
발주사 담당자 투입 시간
보통
매우 많음
적음
재작업 리스크
낮음
높음
낮음
개발 단가
높음
낮음
낮음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
표에서 사내 시스템에만 해당하는 줄은 맨 윗줄입니다. 대외 서비스라면 기획서를 영어로 번역해 해외 팀에 넘기는 방식이 성립합니다. 그러나 사내 시스템의 요구사항은 번역할 원본 자체가 없습니다. 경리 담당자에게 마감 절차를 묻고, 창고 담당자에게 재고가 안 맞을 때 어떻게 하는지 물어야 나옵니다. 이 인터뷰는 한국어로, 그 조직의 맥락을 아는 사람이 해야 합니다.
그래서 사내 시스템에서 해외 직접 발주는 단가가 싸도 위험한 선택이 됩니다. 개발 실력의 문제가 아니라, 요구사항을 캐내는 일이 발주사 담당자에게 통째로 넘어오기 때문입니다. 사내에 그 일을 전담할 사람이 없다면 그 방식은 성립하지 않습니다. 왜 외주가 납기 후 분쟁으로 끝나는지는 IT 외주 구조에서 더 자세히 정리했습니다.
디비컨설팅이 이 문제를 다루는 방식
IT 아웃소싱 구조에서 한국인 PM은 통역이 아니라 요구사항의 책임자입니다. 진행은 다섯 단계로 나뉩니다.
상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 사내 시스템에서는 이 단계에 현업 인터뷰가 포함됩니다. 뒤에 생기는 재작업 대부분이 이 단계에서 제거됩니다.
개발팀 구성 — 프로젝트 성격에 맞춰 2~4주 안에 전담팀을 구성합니다.
프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 고객사 담당자가 하루를 조율에 쓰지 않아도 되는 구조입니다.
테스트 및 배포 — QA 프로세스를 거쳐 배포합니다.
운영 및 유지보수 — 문서와 함께 인계하고 장기 지원합니다.
사내 시스템에서 특히 중요한 것은 1단계와 5단계입니다. 1단계에서 현업의 규칙을 꺼내지 못하면 완성도와 무관하게 안 쓰이는 시스템이 되고, 5단계에서 문서 없이 인계받으면 조직이 바뀔 때마다 손을 댈 수 없게 됩니다.
실제 구축 사례
디비컨설팅이 수행한 프로젝트 가운데 내부 운영 시스템 성격이 강한 사례입니다.
가천대학교 — 학사관리 시스템
센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
교보생명 — 사내벤처(글펍) 커뮤니티 서비스
삼성물산 — 홈닉, 주거 플랫폼 앱
GS건설 — 엘리시안 리조트 웹·앱 통합 구축
교육, 금융·핀테크, 제조·물류, 이커머스, 스마트빌딩·IoT 등에서 구축 경험을 보유하고 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.
현업 담당자가 인터뷰에 응할 시간이 전혀 없는 경우. 사내 시스템은 발주사의 시간이 최소한은 필요합니다. 그 시간을 낼 수 없다면 어느 개발사가 맡아도 결과는 같습니다.
표준 패키지로 충분한 업무인 경우. 일반적인 회계나 급여처럼 시장 솔루션이 성숙한 영역은 구독형 제품이 더 저렴하고 안전합니다.
무엇을 개선할지 아직 정하지 못한 경우. “시스템이 있으면 나아질 것 같다”는 단계라면 개발보다 업무 정리가 먼저입니다.
이번 달 안에 오픈해야 하는 경우. 데이터 이관과 연동이 있는 사내 시스템은 그 일정에 맞추기 어렵습니다.
자주 묻는 질문
해외 개발팀인데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 현업 인터뷰, 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과 직접 영어로 대화하실 일은 없습니다.
기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 사내 시스템이라면 현재 쓰고 계신 엑셀 서식을 보여 주시는 것이 기획서보다 정확할 때가 많습니다.
비용은 어떻게 산정되나요?
등급별 단가에 투입 기간을 곱하는 방식이며, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 사내 시스템은 데이터 이관과 연동 범위에 따라 편차가 크므로 이 두 항목을 별도로 확인하시기 바랍니다. 국내 채용 대비 평균 40~60% 절감이 일반적인 범위입니다.
팀 규모를 중간에 조정할 수 있나요?
가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 사내 시스템은 오픈 이후 변경 요청이 이어지는 특성이 있어, 축소된 형태로 유지 인력을 남기는 방식을 많이 선택하십니다.
소스코드는 누구 소유인가요?
발주사 귀속입니다. API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 사내 시스템에서는 이 조건이 특히 중요합니다. 코드와 문서를 확보하지 못하면 이후 어떤 작은 수정도 원 개발사를 거쳐야 하고, 그 의존이 몇 년간 이어지기 때문입니다.
정리
사내 시스템 구축의 성패는 개발 실력보다 요구사항을 캐내는 능력에서 갈립니다. 그 요구사항은 문서가 아니라 현업 담당자의 경험 안에 있고, 한국어로 묻고 조직의 맥락을 이해해야 나옵니다. 실사용자, 현행 업무, 예외 처리 범위, 데이터 이관, 연동 대상, 오픈 이후 변경 주체 — 이 여섯 가지를 발주 전에 정리해 두시면 대부분의 재작업은 발생하지 않습니다. 그리고 이 질문들을 대신 물어 줄 사람이 사내에 없다면, 그 역할을 맡는 한국인 PM이 있는 구조가 필요합니다. 웹 개발 외주를 검토 중이시라면 이 기준부터 확인해 보시기 바랍니다.
무료 상담
비슷한 플랫폼을 만들고 계신가요?
디비컨설팅은 100건 이상의 웹·앱·플랫폼 구축 경험이 있습니다. 기획 단계에서 놓치기 쉬운 부분부터 함께 점검해 드립니다.
서버 운영 유지보수는 개발이 끝난 뒤에 생각하면 이미 늦습니다. 출시 당일까지는 모두가 화면을 보고 있습니다. 그런데 그 다음 주 화요일 새벽 두 시, 결제가 되지 않는다는 문의가 쌓이기 시작하면 상황이 완전히 달라집니다. 발주사 담당자는 개발사 PM에게 전화를 걸지만 받지 않습니다. 아침이 되어 연락이 닿으면, 프로젝트를 만들었던 개발자는 이미 다른 프로젝트에 배정되었다는 답을 듣습니다. 계약서에는 ‘유지보수 1년’이라고 적혀 있습니다. 그런데 그 한 줄이 지금 이 장애를 누가 몇 시간 안에 고치는지는 아무것도 정해주지 않습니다.
디비컨설팅은 100건 이상의 웹·앱·플랫폼 프로젝트를 구축하고 운영까지 이어받아 왔습니다. 삼성물산 홈닉, GS건설 엘리시안 리조트, 하나투어 하나오픈챗, LS일렉트릭 테크스퀘어, 가천대학교 학사관리 시스템처럼 출시 이후에도 계속 돌아가야 하는 시스템들입니다. 그 경험에서 반복적으로 확인한 것은, 운영 단계의 사고가 기술 문제로 시작되는 경우는 드물다는 사실입니다. 대부분은 ‘누가 책임지는지’를 발주 단계에서 정하지 않은 결과로 나타납니다.
출시 직후가 가장 위험한 구간인 이유
개발 기간 중에는 모든 관심이 프로젝트에 집중되어 있습니다. 개발자도 배정되어 있고, PM도 매주 회의를 잡고, 문제가 생기면 그 자리에서 잡힙니다. 문제는 검수가 끝나고 잔금이 지급된 다음부터입니다. 프로젝트 조직은 해산되고, 시스템은 그때부터 실제 사용자를 받기 시작합니다. 관심이 가장 낮아지는 시점과 부하가 가장 높아지는 시점이 겹칩니다.
실사용자는 테스트 데이터처럼 행동하지 않습니다
검수 환경에서는 수십 건의 데이터로 확인합니다. 실제 서비스에서는 첫 주에 수천 건이 들어옵니다. 동시 접속, 이미지 업로드 용량, 푸시 발송량, 결제 재시도 같은 항목은 실사용 트래픽을 받아본 뒤에야 한계가 드러납니다. 개발 검수 단계에서 기능이 모두 통과했다는 것과, 실제 부하에서 견딘다는 것은 다른 이야기입니다.
장애는 대부분 코드가 아니라 연결 지점에서 납니다
운영 중 실제로 서비스를 멈추는 원인은 대개 외부와 맞닿은 부분입니다. 결제 대행사 인증서 만료, 문자·알림톡 발송 한도 초과, 도메인이나 SSL 인증서 갱신 누락, 서버 디스크 용량 초과, 외부 API 사양 변경. 어느 것도 개발사가 잘못 만들어서 생긴 문제가 아닙니다. 그래서 ‘하자보수’에 해당하지 않고, 그래서 아무도 자기 일이라고 생각하지 않습니다.
만든 사람이 남아 있지 않으면 대응 시간이 몇 배로 늘어납니다
같은 장애를, 그 코드를 직접 쓴 개발자는 한 시간 안에 원인을 찾습니다. 처음 보는 개발자는 구조를 파악하는 데만 이틀이 걸립니다. 문서가 없으면 더 걸립니다. 유지보수 계약이 ‘월 몇 시간 지원’ 형태로만 되어 있으면, 발주사는 그 파악 시간까지 자기 비용으로 지불하게 됩니다.
SLA를 꼼꼼히 써도 해결되지 않는 부분
이 문제를 검색하면 대부분 ‘SLA를 제대로 쓰라’는 조언이 나옵니다. 응답 시간, 복구 시간, 가동률을 숫자로 못 박으라는 것입니다. 맞는 조언이고, 개발 외주 계약서에 반드시 들어가야 하는 항목입니다.
다만 SLA는 약속을 문서로 만드는 장치이고, 그 약속을 실행할 사람이 남아 있는지는 다른 문제입니다. 프로젝트 단위로 발주하면, 개발사는 납품 시점에 그 인력을 다음 프로젝트로 옮깁니다. 계약상 ‘4시간 내 응답’은 지켜집니다. 접수 담당자가 4시간 안에 접수했다는 뜻이기 때문입니다. 실제로 코드를 열어볼 사람이 언제 붙는지는 SLA에 적혀 있지 않습니다.
그래서 운영 문제는 조항의 문제가 아니라 팀 연속성의 문제입니다. 계약서를 강하게 쓰는 것보다, 만든 팀이 남는 구조로 발주하는 것이 먼저입니다.
발주사가 실제로 선택하는 세 가지 구조
운영을 누가 맡느냐는 결국 어떤 구조로 발주했는지에 따라 결정됩니다. 선택지는 세 가지입니다.
국내 개발사 (프로젝트 단위)
해외 직접 발주
한국 PM + 글로벌 개발팀
개발 단가
높음
낮음
낮음
출시 후 인력 잔류
낮음
보통
높음
장애 시 1차 응답 주체
접수 창구
발주사 본인
한국 PM
업무시간 외 장애 대응
어려움
발주사가 직접 대응
시차를 활용해 커버
커뮤니케이션 언어
한국어
영어
한국어
발주사 담당자 투입 시간
보통
매우 많음
적음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
해외에 직접 발주하면 단가는 분명히 내려갑니다. 문제는 운영 단계입니다. 장애가 났을 때 상황을 정리하고, 우선순위를 정하고, 영어로 지시하고, 조치 결과를 검증하는 일이 전부 발주사 담당자에게 넘어옵니다. 사내에 그 일을 할 개발 인력이 없다면, 절감한 단가는 담당자의 밤과 주말로 지불됩니다.
반대로 시차는 제대로 설계하면 오히려 자산입니다. 한국 시간 새벽은 인도 기준으로 업무 시간입니다. 한국인 PM이 접수와 판단을 맡고 글로벌 개발팀이 그 시간대에 손을 대는 구조라면, 국내 개발사가 ‘내일 오전에 확인하겠습니다’라고 답하는 시간에 이미 조치가 진행됩니다.
인수 전에 정해야 할 6가지
운영을 넘겨받기 전에 다음 여섯 가지는 문서로 확정하시기를 권합니다. 여섯 항목 모두 개발이 끝난 뒤에는 협상력이 급격히 떨어지는 항목입니다.
1. 장애 등급과 등급별 대응 시간
‘신속히 대응’은 기준이 아닙니다. 서비스 전체 중단, 핵심 기능 장애, 일부 화면 오류를 등급으로 나누고, 등급별로 최초 응답 시간과 임시 복구 목표를 각각 적으십시오. 특히 ‘최초 응답’과 ‘복구 착수’를 구분해서 쓰는 것이 중요합니다. 이 둘을 한 문장으로 합쳐 두면 접수만으로 의무가 이행됩니다.
2. 대응 시간대와 시차 처리 주체
평일 09-18시인지, 24시간인지, 주말과 공휴일은 어떻게 되는지를 명시합니다. 해외 인력이 포함된 팀이라면 시차를 누가 흡수하는지가 핵심입니다. 발주사가 영어로 직접 연락해야 하는 구조인지, 한국인 PM이 창구가 되는 구조인지에 따라 담당자의 실제 부담이 완전히 달라집니다.
3. 서버·도메인·계정의 명의
클라우드 계정, 도메인, SSL 인증서, 앱스토어와 구글 플레이 개발자 계정, 결제 대행사 가맹점 계정. 이것들이 개발사 명의로 되어 있으면 나중에 업체를 바꿀 때 서비스를 인질로 잡힌 상태가 됩니다. 가능하면 전부 발주사 명의로 개설하고, 개발사에는 접근 권한만 부여하십시오. 이미 개발사 명의로 진행되었다면 개발사 교체를 검토하기 전에 명의 이전 절차부터 확인해야 합니다.
4. 운영 서버 배포 권한과 절차
누가 운영 서버에 코드를 반영할 수 있는지, 반영 전에 누구의 승인이 필요한지, 문제가 생겼을 때 되돌리는 절차가 무엇인지를 정합니다. 권한이 한 사람에게만 있으면 그 사람이 휴가일 때 서비스가 멈춥니다. 반대로 아무나 반영할 수 있으면 원인 추적이 불가능해집니다.
5. 하자보수와 유지보수의 경계
계약한 기능이 명세대로 동작하지 않는 것은 하자이고 무상입니다. 새 기능을 추가하는 것은 유상입니다. 분쟁은 그 사이에서 발생합니다. 외부 API 사양이 바뀌어서 연동이 깨진 경우, OS 버전이 올라가서 화면이 틀어진 경우, 사용자가 늘어서 느려진 경우는 어느 쪽인지 미리 적어두어야 합니다. 비용 산정 구조 자체는 앱 유지보수 비용에서 항목별로 정리해 두었습니다.
6. 원 개발 인력의 잔류 여부와 인계 문서
가장 중요하지만 가장 자주 빠지는 항목입니다. 만든 개발자 중 몇 명이 운영 기간에도 남는지, 남지 않는다면 무엇을 문서로 남기는지를 확정하십시오. 최소한 API 명세, DB 스키마, 배포 절차, 외부 연동 계정 목록, 알려진 이슈 목록은 인계 대상이어야 합니다. 이 문서가 없으면 나머지 다섯 항목을 아무리 잘 써도 대응 속도가 나오지 않습니다.
디비컨설팅이 운영을 이어받는 방식
IT 아웃소싱을 전담팀 형태로 진행하기 때문에, 운영은 별도 단계가 아니라 같은 팀이 계속 맡는 구간입니다. 진행 절차는 다섯 단계입니다.
상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 이 단계에서 운영 기준까지 함께 정의합니다. 장애 등급, 대응 시간대, 계정 명의를 개발 착수 전에 정해두면 인수 시점의 협상이 사라집니다. 무엇을 문서로 정리해야 하는지는 요구사항 정의서에서 다뤘습니다.
개발팀 구성 — 전담팀을 2~4주 안에 구성합니다. 인력 단위가 아니라 팀 단위로 배정되기 때문에, 출시 이후에도 같은 인원이 유지됩니다.
프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 것이 기준입니다.
테스트 및 배포 — QA 프로세스를 거친 뒤 배포합니다. QA를 전담 조직이 맡는지 개발자가 겸하는지의 차이는 QA 전담팀에서 설명했습니다.
운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다. 소스코드는 발주사에 귀속되며, API 명세·DB 스키마·배포 절차 문서까지 인계 대상입니다.
구조의 핵심은 단순합니다. 발주사는 한국인 PM 한 사람과 한국어로 소통하고, 그 PM이 요구사항 정의·일정·검수·장애 접수와 판단을 책임집니다. 글로벌 개발팀을 발주사가 직접 관리하지 않습니다.
출시 후에도 계속 돌아가고 있는 시스템들
운영을 감당할 수 있는지는 실제로 운영해 본 시스템으로 판단하시는 편이 정확합니다.
삼성물산 — 홈닉 · 주거 플랫폼 앱. 입주민이 매일 쓰는 서비스로, 중단이 곧 민원이 되는 유형입니다.
GS건설 — 엘리시안 리조트 · 리조트 웹과 앱 통합 구축. 예약이 몰리는 성수기 부하를 전제로 설계했습니다.
하나투어 — 하나오픈챗 · 여행 상담 채팅 서비스. 실시간 응답이 서비스 품질 그 자체인 구조입니다.
LS일렉트릭 — 테크스퀘어 · 산업 B2B 거래 플랫폼.
직방 — 호갱노노 · 부동산 데이터 서비스.
가천대학교 · 학사관리 시스템. 수강신청처럼 특정 시점에 부하가 집중되는 시스템입니다.
센터필드 · 센트로폴리스 · 그랑서울 · 프라임 오피스 빌딩 관리 시스템.
교보생명 · 사내벤처(글펍) 커뮤니티 서비스.
교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.
이런 기업에 적합합니다
사내에 개발 인력이 없거나 한두 명뿐이어서, 장애 시 판단을 내려줄 사람이 없는 기업
이미 출시한 서비스가 있는데 만든 개발사와 연락이 잘 되지 않는 기업
구축과 운영을 한 팀에 맡겨 인계 손실을 줄이고 싶은 기업
실사용자가 매일 쓰는 서비스여서 중단 시간이 그대로 비용이 되는 기업
웹 개발 외주 또는 앱 개발 외주를 준비 중이면서, 발주 단계에서 운영 조건까지 함께 정하고 싶은 기업
반대로 권하지 않습니다
사내에 운영 조직이 이미 있는 경우. 인프라 담당과 백엔드 인력이 상시 대기하는 조직이라면, 외부에 운영을 맡기는 것이 오히려 단계를 늘립니다. 필요한 구간만 인력 단위로 보강하는 편이 낫습니다.
내부 정책상 외부 인력의 운영 서버 접근이 불가능한 경우. 접근 권한 없이 장애 대응을 위탁하면 책임만 이전되고 조치는 되지 않습니다.
월 운영 예산을 전혀 잡지 않은 경우. 구축비만 확보하고 운영비를 0으로 두면, 어떤 구조를 택하든 두세 달 안에 같은 문제가 반복됩니다. 이 경우에는 구축 범위를 줄여서 운영 예산을 확보하는 것이 먼저입니다.
단순 서버 임대나 모니터링 도구만 필요한 경우. 그것은 호스팅 업체의 영역이고, 개발팀을 붙일 필요가 없습니다.
자주 묻는 질문
해외 개발팀이 대응하는데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 장애 접수, 상황 판단, 우선순위 결정, 조치 결과 확인이 모두 PM 책임입니다. 발주사가 영어로 개발자에게 직접 지시하는 상황은 발생하지 않습니다.
소스코드와 서버는 누구 소유가 되나요?
소스코드는 발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계 대상입니다. 서버와 클라우드 계정도 발주사 명의로 개설하는 것을 권장하며, 저희는 필요한 접근 권한만 받아 운영합니다. 언제든 다른 업체로 이관하거나 내부 인력으로 전환할 수 있는 상태를 유지하는 것이 원칙입니다.
다른 회사가 만든 시스템의 운영만 맡길 수 있나요?
가능합니다. 다만 인계 자료의 상태를 먼저 확인해야 합니다. 소스코드 접근, 서버와 계정 권한, DB 구조, 외부 연동 목록이 확보되는지에 따라 착수 시점이 달라집니다. 자료가 부족하면 구조 파악 기간을 별도로 잡고, 그 결과를 문서로 남긴 뒤 운영에 들어갑니다.
기획서나 문서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 운영 위탁의 경우에는 현재 서비스 주소, 월 사용자 규모, 최근 발생한 장애 유형 정도만 알려주시면 검토가 가능합니다.
운영 중에 팀 규모를 조정할 수 있나요?
가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중에도 조정할 수 있습니다. 출시 직후 몇 달은 인력을 두텁게 두고 안정화된 뒤 축소하는 방식이 일반적입니다.
정리
서버 운영 유지보수에서 실제로 문제가 되는 것은 계약서에 적힌 시간이 아니라, 그 시간을 지킬 사람이 남아 있는지입니다. 장애 등급, 대응 시간대, 계정 명의, 배포 권한, 하자와 유지보수의 경계, 원 개발 인력의 잔류 여부 — 이 여섯 가지를 인수 전에 문서로 정해두면 대부분의 분쟁이 사라집니다. 그리고 이 여섯 가지가 자연스럽게 지켜지는 구조는 구축과 운영을 같은 팀이 맡고, 그 팀과의 소통을 한국인 PM이 책임지는 형태입니다. IT 외주에서 분쟁이 반복되는 이유도 결국 같은 지점에 있습니다.
무료 상담
인도 개발팀, 직접 관리하지 않아도 됩니다
디비컨설팅은 한국인 PM이 요구사항 정의부터 일정 관리까지 책임집니다. 언어와 시차 부담을 고객사가 떠안지 않는 구조로 진행됩니다.
다국어 서비스 개발은 대부분 이런 순간에 시작됩니다. 국내에서 잘 돌아가던 앱에 일본 바이어나 동남아 파트너의 문의가 들어옵니다. 대표가 기존 개발사에 전화를 겁니다. “영어랑 일본어만 추가하면 되죠?” 며칠 뒤 돌아온 견적은 처음 앱을 만들 때와 크게 다르지 않은 금액입니다. 화면이 늘어난 것도 아닌데 왜 이런 숫자가 나오는지 납득이 되지 않습니다.
납득이 되지 않는 이유는 질문이 틀렸기 때문입니다. 다국어 서비스 개발에서 번역은 가장 마지막에, 가장 싸게 끝나는 일입니다. 비용과 일정을 실제로 결정하는 것은 언어가 아니라 그 언어를 쓰는 나라의 결제 수단, 개인정보 규정, 서버 위치, 시차, 그리고 그 모든 것을 누가 정의하느냐입니다.
디비컨설팅은 100건이 넘는 웹·앱·플랫폼 프로젝트를 진행했고, 50곳 이상의 글로벌 파트너사와 함께 일합니다. 와디즈의 글로벌 플랫폼, 삼성물산 홈닉, GS건설 엘리시안 리조트 웹·앱, 하나투어 하나오픈챗을 구축했습니다. 고객 만족도는 98%이고, 전담 개발팀은 평균 2~4주 안에 구성됩니다. 아래 내용은 그 과정에서 반복해서 확인한 것들입니다.
왜 다국어 견적은 ‘번역비’로 끝나지 않는가
번역은 마지막 작업이지만, 다국어는 첫 설계입니다
국내 전용으로 만든 서비스는 화면에 보이는 문구가 코드 안에 그대로 박혀 있는 경우가 많습니다. 빠르게 만들기에는 이 방식이 편하기 때문입니다. 문제는 언어를 하나 추가하려는 순간 드러납니다. 문구를 바꾸려면 그 문구가 들어 있는 화면을 전부 다시 열어야 합니다.
처음부터 국제화 구조를 깔아두면 언어 추가는 언어 파일 하나를 넣는 작업입니다. 나중에 깔면 이미 완성된 화면 전체를 다시 만지는 작업이 됩니다. 견적이 두 배가 되는 지점이 정확히 여기입니다. 개발사가 비싸게 부르는 것이 아니라, 하지 않아도 됐을 일을 지금 하게 되는 것입니다.
길이 문제도 함께 옵니다. 한국어 기준으로 잡은 버튼에 독일어 문장을 넣으면 넘칩니다. 일본어는 줄바꿈 규칙이 다르고, 아랍어는 화면이 오른쪽에서 왼쪽으로 흐릅니다. 이것은 번역가가 해결할 수 있는 문제가 아니라 웹 개발 외주 단계에서 화면 설계로 풀어야 하는 문제입니다.
화면 수는 그대로인데 검수량은 몇 배가 됩니다
국내 전용 앱은 한국어 화면 하나만 확인하면 됩니다. 3개 언어를 지원하는 앱은 언어마다 레이아웃이 깨지는 지점이 다르고, iOS와 Android가 글꼴을 다르게 처리하며, 국가마다 결제 흐름이 갈라집니다. 확인해야 하는 경우의 수가 곱셈으로 늘어납니다.
견적서에 이 검수 비용이 보이지 않는다면, 그 견적은 저렴한 것이 아니라 항목이 빠진 것입니다. 출시 직전에 “언어별로 다시 봐야 한다”는 이야기가 나오고, 그때부터 일정이 밀립니다. 무엇을 완료로 볼 것인지 미리 정하는 문제는 개발 검수 기준에서 따로 다뤘습니다.
결제·법규·인프라는 언어와 함께 따라옵니다
언어를 추가한다는 것은 사실상 나라를 추가한다는 뜻입니다. 나라가 추가되면 결제 수단이 달라지고, 통화와 세금 표기가 달라지고, 개인정보를 어디에 어떻게 보관해야 하는지가 달라집니다. 서버를 어느 지역에 둘 것인지도 결정해야 합니다.
여기서 많은 프로젝트가 멈춥니다. 이 항목들은 개발 이슈이기 이전에 사업 결정이기 때문입니다. 어느 나라에 먼저 들어갈지, 현지 법인을 세울지, 결제를 국내에서 받을지 현지에서 받을지는 개발사가 대신 정해줄 수 없습니다. 그런데 이 결정이 없으면 개발도 시작할 수 없습니다.
시차는 비용이 아니라 속도의 문제입니다
해외 개발팀과 직접 일해 본 회사들이 공통적으로 이야기하는 어려움은 단가가 아니라 왕복 시간입니다. 오전에 보낸 질문의 답이 다음 날 아침에 옵니다. 답이 질문의 의도와 다르면 하루가 더 갑니다. 사흘이면 끝날 논의가 일주일이 됩니다. 이 지연은 견적서 어디에도 적혀 있지 않지만 일정에는 그대로 반영됩니다.
해외 출시 전에 정해야 할 6가지
견적을 받기 전에 아래 여섯 가지가 정해져 있으면 프로젝트의 성격이 달라집니다. 정해져 있지 않으면 개발사는 가장 넓은 범위를 가정해서 견적을 내고, 그 결과가 “왜 이렇게 비싸냐”는 반응으로 돌아옵니다.
대상 국가 — 언어가 아니라 국가를 먼저 정합니다. “영어 버전”은 범위가 아니고, “미국 출시”는 범위입니다. 결제·법규·서버 위치가 전부 여기서 갈립니다.
국제화 구조를 지금 깔 것인가 — 당장은 언어 하나만 추가하더라도, 2차·3차 국가 계획이 있다면 지금 구조를 깔아두는 편이 총비용이 낮습니다. 계획이 없다면 굳이 지금 깔 이유도 없습니다. 이건 예산이 아니라 로드맵으로 판단할 문제입니다.
결제를 어디서 받을 것인가 — 국내 결제사로 해외 카드를 받을 것인지, 현지 결제 수단을 붙일 것인지에 따라 연동 난이도와 정산 구조가 완전히 달라집니다. 개발 항목이기 이전에 자금 흐름의 문제입니다.
개인정보를 어디에 보관할 것인가 — 국가에 따라 데이터를 자국 내에 두도록 요구하는 경우가 있습니다. 이 결정이 뒤집히면 서버 구성과 배포 파이프라인을 다시 만들어야 합니다. 가장 늦게 발견되고 가장 비싸게 고치는 항목입니다.
언어별 QA를 어디까지 볼 것인가 — 모든 언어를 동일한 깊이로 검수할지, 1차 국가만 전수 검수하고 나머지는 핵심 화면만 볼지 미리 정합니다. 정하지 않으면 출시 직전에 정하게 되고, 그때는 일정을 미루는 것 외에 선택지가 없습니다.
출시 후 문구는 누가 갱신할 것인가 — 언어가 늘어나면 운영 부담도 같이 늘어납니다. 프로모션 문구 하나를 바꿔도 언어 수만큼 바꿔야 합니다. 사내에서 직접 관리할지, 개발사가 맡을지, 관리자 화면에서 처리할 수 있게 만들지를 개발 전에 정해야 합니다.
여섯 가지 모두 개발사가 대신 정해줄 수 없는 항목입니다. 그런데 여섯 가지 모두 정해지지 않으면 개발을 시작할 수 없습니다. 다국어 프로젝트가 어려운 진짜 이유가 여기에 있습니다. 기술 난이도가 아니라 결정의 밀도가 높습니다.
실제 선택지는 세 가지입니다
다국어 서비스를 만들기로 했다면 발주 방식은 결국 세 가지 중 하나입니다. 언어를 몇 개 지원할지보다 이 선택이 결과를 더 크게 좌우합니다.
항목
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
개발 단가
높음
낮음
낮음
다국어 구조 설계 경험
회사마다 편차
있음
있음
요구사항 정의 책임
개발사
발주사 본인
한국 PM
커뮤니케이션 언어
한국어
영어
한국어
시차 대응 부담
없음
발주사가 감당
PM이 흡수
발주사 담당자 투입 시간
보통
매우 많음
적음
재작업 리스크
낮음
높음
낮음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
해외 직접 발주가 매력적으로 보이는 이유는 단가 한 줄 때문입니다. 그런데 다국어 프로젝트에서 발주사가 실제로 감당하게 되는 것은 단가가 아니라 정의와 조율입니다. 어떤 화면이 어떤 언어에서 어떻게 보여야 하는지, 결제 실패는 어떻게 처리할지, 이번 스프린트에서 무엇을 완료로 볼지를 영어로, 시차를 넘어, 매일 결정해야 합니다.
사내에 이 역할을 할 사람이 있다면 해외 직접 발주는 합리적인 선택입니다. 없다면 그 일은 대표나 기획자에게 넘어가고, 결국 본업이 멈춥니다. 세 번째 열은 단가를 낮추는 구조가 아니라 정의 책임을 한국어로 처리하는 구조입니다. 이 차이는 IT 외주가 분쟁으로 끝나는 이유에서 더 자세히 다뤘습니다.
디비컨설팅이 이 구조를 통제하는 방식
상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 다국어 프로젝트에서는 이 단계에서 대상 국가, 지원 언어, 결제 수단, 개인정보 처리 방식을 확정합니다. 뒤에서 생기는 재작업 대부분이 여기서 제거됩니다. 어디까지 적어야 하는지는 요구사항 정의서 글을 참고하시면 됩니다.
개발팀 구성 — 확정된 범위에 맞춰 전담팀을 평균 2~4주 안에 구성합니다.
프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사가 하루를 개발팀 조율에 쓰지 않습니다.
테스트 및 배포 — 언어별·국가별 QA를 거친 뒤 배포합니다.
운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다. 언어를 추가로 붙일 때 다시 처음부터 시작하지 않도록 구조와 절차를 남깁니다.
1차 출시 범위를 어디까지 자를지 고민 중이라면 MVP 개발 범위를, 앱과 웹 중 무엇을 먼저 만들지 정하지 못했다면 앱 개발과 웹 개발 비교를 먼저 읽어보시길 권합니다.
실제로 만든 것들
와디즈 — 글로벌 플랫폼
삼성물산 — 홈닉, 주거 플랫폼 앱
GS건설 — 엘리시안 리조트 웹·앱 통합 구축
하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
직방 — 호갱노노, 부동산 데이터 서비스
가천대학교 — 학사관리 시스템
교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.
이런 기업에 적합합니다
국내 서비스가 이미 검증되었고, 이제 해외로 확장하려는 기업
사내에 개발 인력이 없거나 소수여서 해외 팀을 직접 관리하기 어려운 기업
처음부터 다국어를 전제로 서비스를 설계하려는 기업
두 개 이상의 국가에 동시에 대응해야 하는 기업
반대로, 이런 경우에는 권하지 않습니다
이미 국제화 구조가 깔려 있고 언어 하나만 추가하면 되는 경우. 구조를 만든 기존 개발사에 맡기는 편이 빠르고 저렴합니다.
진출 국가가 아직 정해지지 않은 경우. 국가가 정해져야 결제·법규·인프라가 정해지고, 그래야 견적이 의미를 가집니다. 사업 판단을 먼저 마치는 것이 순서입니다.
정말 번역만 필요한 경우. 화면 구조를 손대지 않아도 된다면 번역 업체가 맞는 파트너입니다.
자주 묻는 질문
해외 개발팀인데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 영어로 개발팀과 직접 이야기하실 필요가 없습니다. 이 구조에 대한 자세한 설명은 IT 아웃소싱 페이지에 정리되어 있습니다.
다국어 개발 비용은 어떻게 산정되나요?
등급별 단가와 투입 기간을 기준으로 산정하고, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해서 제시합니다. 다국어 프로젝트에서는 언어별 QA와 국가별 결제 연동이 별도 항목으로 들어갑니다. 견적이 회사마다 달라지는 구조는 모바일 앱 개발 견적과 서비스 개발 비용에서 설명했습니다.
기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 다국어 프로젝트라면 여기에 대상 국가만 추가로 알려주시면 됩니다.
진출 국가가 늘어나면 팀 규모도 조정할 수 있나요?
가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중에도 조정할 수 있습니다. 1차 국가로 출시한 뒤 2차 국가를 붙이는 방식이 실제로 가장 자주 쓰이는 형태입니다.
이미 만든 서비스에 다국어를 붙이는 것과, 처음부터 다국어로 만드는 것은 얼마나 차이가 나나요?
금액보다 작업의 성격이 다릅니다. 처음부터 다국어를 전제로 만들면 국제화 구조를 설계에 포함하는 일이고, 나중에 붙이면 이미 완성된 화면을 하나씩 다시 여는 일입니다. 후자는 화면 수에 비례해서 늘어나기 때문에, 서비스가 클수록 차이도 커집니다. 다만 이미 만든 서비스라도 화면 구조가 정리되어 있으면 예상보다 수월한 경우가 있어, 실제 견적은 코드를 확인한 뒤에 드리는 것이 정확합니다.
소스코드와 번역 리소스의 소유권은 누구에게 있나요?
발주사에 귀속됩니다. 소스코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 인계해 드립니다. 언어 파일도 마찬가지입니다. 나중에 개발사를 바꾸더라도 번역 자산을 다시 만들 필요가 없습니다.
정리
다국어 서비스 개발의 비용을 결정하는 것은 언어의 개수가 아니라 구조를 언제 깔았는지, 그리고 국가별 결정을 누가 정의하는지입니다. 번역은 이 두 가지가 끝난 뒤에 붙는 가장 쉬운 단계입니다. 해외로 나가기로 했다면 첫 번째 질문은 “몇 개 언어를 지원할까”가 아니라 “어느 나라에, 무엇을 기준으로, 누가 정의해서 들어갈까”여야 합니다. 사내에 그 정의를 맡을 사람이 없다면, 한국어로 정의를 받아 글로벌 팀에 전달하는 구조가 가장 현실적인 답입니다. 앱 개발 외주를 검토 중이시라면 이 기준부터 확인해 보시기 바랍니다.
무료 상담
비슷한 플랫폼을 만들고 계신가요?
디비컨설팅은 100건 이상의 웹·앱·플랫폼 구축 경험이 있습니다. 기획 단계에서 놓치기 쉬운 부분부터 함께 점검해 드립니다.
개발 검수는 개발사가 “완료됐습니다”라고 통보한 순간에 시작하는 일이 아닙니다. 그런데 실제로는 그 순간에 처음 시작하는 회사가 대부분입니다.
화면을 열어 봅니다. 로그인이 됩니다. 목록이 보이고 버튼이 눌립니다. 겉으로는 문제가 없습니다. 담당 팀장은 이 화면을 보고 승인 여부를 판단해야 합니다. 그런데 무엇을 기준으로 판단할지가 손에 없습니다. 계약서에는 “상호 협의하여 검수한다”고만 적혀 있습니다. 기획 단계의 요구사항은 메신저와 메일과 회의록에 흩어져 있습니다. 어떤 기능은 빠진 것 같은데, 빠진 것인지 애초에 범위가 아니었는지 확인할 문서가 없습니다.
그래서 대개 이렇게 끝납니다. “일단 오픈하고 수정하죠.” 잔금을 지급합니다. 다음 주에 결제 오류가 나옵니다. 개발사에 연락하면 그건 추가 개발이라는 답이 옵니다. 이 시점에 발주사가 쓸 수 있는 카드는 없습니다. 이미 승인했고, 이미 지급했습니다. 절반 이상의 외주 프로젝트가 납기 후 분쟁으로 끝나는 이유도 대부분 여기서 갈립니다.
이 글의 근거
디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 관리하는 방식으로 100건 이상의 프로젝트를 수행했습니다. 협업 중인 글로벌 파트너사는 50개 이상이고, 고객 만족도는 98%입니다.
이 숫자를 먼저 말씀드리는 이유는 하나입니다. 프로젝트가 100건을 넘기면 실패하는 지점이 반복적으로 보입니다. 그리고 그 지점은 대부분 기술이 아닙니다. 개발 검수를 승인할 기준이 계약 시점에 문서로 존재하지 않았다는 것, 그 한 가지입니다.
아래는 그 반복을 정리한 내용입니다.
개발 검수가 실패하는 구조적인 이유
검수 기준이 계약 시점에 없었습니다
검수는 비교 작업입니다. 비교에는 대상이 두 개 필요합니다. 완성된 결과물과, 처음에 합의한 기준입니다. 기준이 없으면 검수는 비교가 아니라 감상이 됩니다. “괜찮아 보이는데요”와 “좀 부족한 것 같은데요” 사이에서 회의가 끝나고, 결론은 목소리가 큰 쪽으로 납니다.
기준은 개발이 끝난 뒤에 만들 수 없습니다. 결과물을 본 다음에 쓰는 기준은 이미 결과물에 맞춰진 기준입니다. 그래서 요구사항 정의서를 어디까지 써야 하는지가 검수의 출발점입니다.
“동작한다”와 “요구사항을 충족한다”를 구분하지 않았습니다
개발사가 시연하는 것은 “동작한다”입니다. 발주사가 확인해야 하는 것은 “요구사항을 충족한다”입니다. 이 둘은 자주 다릅니다.
정산 기능을 예로 들겠습니다. 화면에서 숫자가 나옵니다. 동작합니다. 그런데 부분 환불이 섞인 달의 정산 금액이 맞는지는 화면을 눌러서 알 수 없습니다. 시연은 성공 경로만 보여줍니다. 요구사항 충족 여부는 실패 경로에서 갈립니다.
검수 담당자가 개발 내용을 모릅니다
검수를 맡는 사람은 보통 그 업무를 가장 잘 아는 실무 팀장입니다. 업무는 압니다. 그러나 이 기능이 어떤 데이터를 어디에 어떻게 쌓고 있는지는 모릅니다. 그래서 질문을 만들 수 없습니다. 개발사가 “그건 구조상 그렇게 됩니다”라고 답하면 검증할 방법이 없습니다.
담당자의 잘못이 아닙니다. 발주사 안에 개발 언어로 질문할 수 있는 사람이 없는 상태로 프로젝트를 시작한 결과입니다.
잔금 지급과 검수 승인이 같은 시점에 묶여 있습니다
많은 계약서가 검수 승인일에 잔금을 지급하도록 되어 있습니다. 이 구조에서는 승인하는 순간 협상력이 사라집니다. 승인 이후에 발견된 문제는 전부 추가 요청이 되고, 추가 요청은 대부분 유상입니다. 최종 비용이 견적의 1.5배가 되는 일은 드물지 않습니다. 개발 외주 계약서에서 서명 전에 확인할 조항에 이 지급 구조가 포함되어야 하는 이유입니다.
선택지는 세 개입니다. 차이는 “누가 검수 기준을 쓰는가”입니다
발주 방식을 정할 때 보통 단가를 비교합니다. 그런데 결과를 결정하는 변수는 단가가 아니라, 검수 기준을 누가 쓰는가입니다.
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
검수 기준 작성 책임
개발사
발주사 본인
한국 PM
검수 소통 언어
한국어
영어
한국어
발주사 담당자 투입 시간
보통
매우 많음
적음
재작업 리스크
낮음
높음
낮음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
해외 개발팀에 직접 발주하는 방식이 기대만큼 싸지 않은 이유가 여기 있습니다. 단가는 내려갑니다. 대신 국내 개발사가 해 주던 일 하나가 발주사로 넘어옵니다. 요구사항을 영어로 명세하고, 검수 항목을 정의하고, 결과물을 항목별로 대조하는 일입니다.
이 일은 발주사의 시니어급 인력만 할 수 있습니다. 그리고 몇 주가 걸립니다. 그 시간은 견적서에 나타나지 않습니다. 회사에서 가장 바쁜 사람의 일정에서 조용히 빠져나갑니다.
핵심은 이것입니다. 검수 기준을 정의하는 일은 없어지지 않습니다. 누군가는 해야 합니다. 국내 개발사에 맡기면 비용으로 지불하고, 해외에 직접 발주하면 발주사 담당자의 시간으로 지불합니다. 한국인 PM을 두는 IT 아웃소싱 방식은 그 일을 맡을 사람을 프로젝트 안에 두는 방식입니다.
디비컨설팅이 검수를 통제하는 방식
진행 방식은 5단계입니다. 각 단계가 검수 관점에서 무엇을 남기는지를 기준으로 설명하겠습니다.
① 상담 및 요구 분석 — 한국인 PM이 발주사와 한국어로 요구사항을 정리하고 문서화합니다. 이 문서가 검수 기준의 원본이 됩니다. 기능 단위로 “무엇이 되면 완료인지”를 이 단계에서 적습니다. 기획서가 없는 상태로 오시는 경우가 많고, 그 상태를 전제로 시작합니다.
② 개발팀 구성 — 정리된 요구사항에 맞춰 2~4주 내에 전담팀을 구성합니다. 팀을 먼저 만들고 요구사항을 거기에 맞추지 않습니다. 순서가 반대가 되면 범위가 팀 사정에 맞춰 휘어집니다.
③ 프로젝트 개발 — 진행 상황을 투명하게 공유합니다. 마지막에 한 번 검수하는 대신, ①에서 만든 문서의 항목이 하나씩 닫히는 것을 확인합니다. 몰아서 하는 검수는 이미 늦은 검수입니다.
④ 테스트 및 배포 — QA를 거친 후 릴리즈합니다. 이 시점의 확인 대상은 화면이 아니라 ①의 문서입니다. QA 전담팀이 없는 개발사를 피해야 하는 이유가 이 단계에서 드러납니다.
⑤ 운영 및 유지보수 — 운영을 이어가고, 인계 시에는 문서와 함께 넘깁니다. 소스코드, API 명세, DB 스키마, 배포 절차가 포함됩니다. 출시 이후의 비용 구조는 앱 유지보수 비용에서 따로 정리했습니다.
발주사가 영어로 소통하는 구간은 없습니다. 요구사항 정의, 일정, 검수는 한국인 PM의 책임입니다.
인수 전에 확인할 6가지
인수 전 개발 검수에서 확인할 항목은 여섯 개입니다. 각 항목 뒤에, 그것이 가능하려면 발주 시점에 무엇이 있어야 했는지를 함께 적었습니다. 대부분은 지금 만들 수 없는 것입니다.
1. 요구사항 정의서 대비 기능 대조표
기능 목록을 받는 것과, 요구사항 정의서의 각 항목에 결과물을 1:1로 붙인 표를 받는 것은 다릅니다. 후자를 요구하십시오. 항목마다 구현 여부, 확인 방법, 확인한 사람이 적혀 있어야 합니다.
이 표는 요구사항 정의서가 있어야 만들 수 있습니다. 문서가 없으면 대조표는 결국 개발사가 만든 기능 목록이 됩니다.
2. 소스코드와 저장소 이관, 그리고 귀속
전체 소스코드와 저장소를 넘겨받으십시오. 소유권이 발주사에 귀속되는지 계약서에서 확인하십시오. 압축 파일 하나가 아니라 커밋 이력이 남은 저장소 단위로 받는 것이 맞습니다. 외부 서비스 계정과 키도 인계 대상입니다.
이 조항은 계약서에 있거나 없습니다. 인수 시점에 새로 협상할 수 없습니다.
3. API 명세 · DB 스키마 · 배포 절차 문서
이 세 가지가 없으면 다음 개발사는 코드를 읽는 데만 몇 주를 씁니다. 배포 절차는 “누가 어떤 명령으로 어디에 올리는지”가 한 문서에 정리되어 있어야 합니다. 특정 담당자의 머릿속에 있는 상태는 인계가 아닙니다. 개발사를 교체해야 하는 상황에서 이 문서의 유무가 이관 비용을 결정합니다.
4. 더미 데이터가 아닌 실사용 데이터 기준 테스트
시연은 대부분 정리된 데이터로 진행됩니다. 실제 데이터는 지저분합니다. 공백이 들어간 이름, 누락된 값, 예상보다 긴 텍스트, 과거 시스템에서 옮겨온 이력이 섞여 있습니다. 이관 데이터나 실제 운영 데이터로 다시 확인하십시오. 여기서 나오는 문제가 오픈 직후 장애의 대부분입니다.
5. 장애와 예외 상황에서의 동작
결제가 중간에 실패했을 때, 외부 API가 응답하지 않을 때, 같은 요청이 두 번 들어왔을 때 무엇이 남는지 확인하십시오. 정상 경로는 대체로 동작합니다. 사고는 예외에서 납니다. 로그가 남는지, 실패한 거래를 나중에 찾을 수 있는지도 함께 보십시오.
6. 잔금 지급 시점과 검수 승인의 분리
검수 승인일과 잔금 지급일을 같은 날로 두지 마십시오. 승인 후 일정 기간의 하자보수 기간을 두고, 그 기간이 지난 뒤에 잔금을 지급하는 구조가 안전합니다. 하자보수의 범위도 문서로 정해 두십시오. “버그는 무상, 신규 기능은 유상”만으로는 부족합니다. 다툼은 그 경계에서 생깁니다.
이것도 계약 조항입니다. 인수 직전에 만들 수 없습니다.
이 방식으로 만든 서비스
삼성물산 홈닉 — 주거 플랫폼 앱
GS건설 엘리시안 리조트 — 리조트 웹·앱 통합
하나투어 하나오픈챗 — 여행 상담 채팅
직방 호갱노노 — 부동산 데이터 서비스
LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
가천대학교 학사관리 시스템
공통점은 규모가 아니라 검수 난이도입니다. 대기업과 대학은 내부 승인 절차가 있고, 문서 없이 인수하지 않습니다. 요구사항 정의서와 인계 문서가 처음부터 갖춰져야 통과되는 프로젝트들입니다. 전체 구축 사례는 포트폴리오에서 확인하실 수 있습니다.
내부에 시니어 개발자와 QA가 이미 있고, 요구사항 정의서와 검수 기준을 직접 쓸 수 있는 조직이라면 굳이 필요하지 않습니다. 이 경우 개발 인력만 확보하는 방식이 더 저렴합니다.
며칠 안에 결과물이 필요한 일이라면 맞지 않습니다. 전담팀 구성에 2~4주가 필요합니다.
요구사항을 정리할 시간을 전혀 낼 수 없는 상황이라면 시작하지 않는 편이 낫습니다. ① 단계에는 발주사의 시간이 반드시 들어갑니다. 몇 주가 아니라 몇 차례의 회의 수준이지만, 그것도 어렵다면 결과가 좋지 않습니다.
자주 묻는 질문
해외 개발팀이면 의사소통은 어떻게 됩니까?
발주사는 한국인 PM과 한국어로만 소통합니다. 개발팀과 직접 회의하거나 영어로 문서를 쓰는 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과의 소통에서 생기는 오해는 PM이 흡수해야 하는 비용이고, 발주사로 넘기지 않습니다.
기획서가 없는데 검수 기준을 정할 수 있습니까?
가능합니다. 그리고 그 상태로 시작하는 경우가 더 많습니다. 첫 상담에 필요한 것은 네 가지입니다. 해결하려는 문제, 주요 사용자, 반드시 있어야 하는 기능 3~5개, 일정과 예산의 범위입니다. 이 네 가지가 있으면 요구사항 정의서를 만들 수 있고, 그 문서가 검수 기준이 됩니다. 기획서를 완성한 뒤에 오시라고 말씀드리지는 않습니다. 그 작업이 사실 가장 어려운 부분입니다.
소스코드 소유권은 어떻게 됩니까?
발주사에 귀속됩니다. 소스코드와 저장소 전체를 인계하고, API 명세, DB 스키마, 배포 절차 문서까지 함께 넘깁니다. 다른 회사로 유지보수를 옮기더라도 문서만으로 이어받을 수 있는 상태로 인계하는 것을 원칙으로 합니다. 이 조건은 계약서에 명시합니다.
팀 규모는 조정할 수 있습니까?
전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있습니다. 진행 중에도 조정이 가능합니다. 초기 개발에는 인원을 늘리고 안정화 이후에 줄이는 형태가 일반적입니다.
검수에서 문제가 나오면 어떻게 됩니까?
요구사항 정의서에 있는 항목이 충족되지 않았다면 저희 책임으로 처리합니다. 정의서에 없던 요구라면 범위 변경으로 보고 일정과 비용을 다시 협의합니다. 이 구분이 가능한 이유는 ① 단계에서 만든 문서가 있기 때문입니다. 문서가 없으면 모든 논의가 “원래 그렇게 말했는지”를 다투는 일이 됩니다.
정리
개발 검수는 마지막 단계의 확인 절차처럼 보이지만, 실제로는 발주 시점에 결정되는 일입니다. 검수 기준은 개발이 끝난 뒤에 만들 수 없습니다. 결과물을 보고 쓴 기준은 결과물을 통과시키는 기준이 되기 때문입니다. 그래서 질문은 “어떻게 검수할 것인가”가 아니라 “발주 시점에 검수 기준을 쓸 사람이 우리 회사 안에 있는가”입니다. 있다면 개발 인력만 확보하면 됩니다. 없다면 그 역할을 대신 맡을 한국인 PM이 필요합니다. 단가를 비교하기 전에 이 질문을 먼저 정리하시는 것을 권합니다.
무료 견적
우리 프로젝트, 비용은 얼마나 들까요?
아이디어 단계여도 괜찮습니다. 해결하려는 문제와 필수 기능만 알려주시면, 한국인 PM이 검토 후 가견적과 예상 일정을 회신드리겠습니다.
UI/UX 디자인 외주를 맡겨 두 달 가까이 시안을 다듬고 경영진 보고까지 마쳤는데, 개발사에서 받은 답이 “이 디자인은 이 예산과 일정으로는 구현이 어렵습니다”였다면 어떨까요. 시안 비용은 이미 지불했고, 프로젝트는 시작도 하기 전에 일정이 밀립니다. 앱이나 웹 서비스 구축을 준비해 본 담당자라면 낯설지 않은 장면일 것입니다.
이 글은 “디자인은 디자인 에이전시에 따로 맡겨야 하나, 개발사에 한꺼번에 맡겨야 하나”를 고민하는 분들을 위해 썼습니다. 결론부터 말씀드리면, 사내에 기획자와 디자이너가 없는 기업이 디자인과 개발을 분리 발주하면 총비용은 거의 예외 없이 올라갑니다. 문제는 시안의 품질이 아니라 시안과 구현 사이의 간극이기 때문입니다.
디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 이끌어 기획·디자인·개발을 한 팀으로 수행하는 IT 아웃소싱 기업입니다. 지금까지 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 협업하며 고객 만족도 98%를 유지하고 있습니다. 삼성물산, GS건설, 하나투어 같은 기업들이 디비컨설팅과 함께 서비스를 구축했습니다.
디자인과 개발이 갈라질 때 생기는 5가지 문제
UI/UX 디자인 외주를 별도 에이전시에 맡기고 구현을 개발사에 넘기는 구조에서는, 아래 다섯 가지 문제가 거의 정해진 수순처럼 나타납니다. 하나씩 짚어 보겠습니다.
1. 구현 가능성이 검증되지 않은 시안
디자인 에이전시의 시안 단계에는 개발자가 없습니다. 화면은 아름답지만, 그 화면을 채울 데이터가 어디서 와야 하는지, 그 애니메이션이 실제 기기에서 성능을 낼 수 있는지, 연동할 외부 API가 그 정보를 제공하기는 하는지는 아무도 검증하지 않습니다. 구현 난이도가 예산을 넘어선다는 사실은 개발 견적 단계, 심하면 개발 도중에야 드러납니다. 그때 시안을 고치면 디자인 비용이 다시 발생하고, 고치지 않으면 개발 비용이 불어납니다.
2. 수정 책임의 공백
개발 단계에서 화면이 시안과 다르게 나왔을 때, 에이전시는 “구현의 문제”라 하고 개발사는 “시안이 실제 데이터를 고려하지 않았다”고 답합니다. 둘 다 틀린 말이 아니라는 점이 발주사를 가장 힘들게 합니다. 계약이 두 개로 나뉘어 있으니 책임을 물을 단일 주체가 없고, 수정 비용을 결국 발주사가 떠안게 되는 일이 드물지 않습니다.
3. 커뮤니케이션 비용이 두 배가 됩니다
에이전시와 개발사는 서로 직접 소통할 계약상 의무가 없습니다. 그래서 발주사 담당자가 중간 전달자가 됩니다. 디자인 의도를 개발사에 설명하고, 기술 제약을 다시 에이전시에 전달하고, 양쪽 회의에 모두 들어갑니다. 본업이 따로 있는 담당자에게 이 역할이 얹히는 순간 전달 과정에서 맥락이 빠지고, 의사결정은 눈에 띄게 느려집니다.
4. 화면 낱장 시안은 개발 단계에서 흩어집니다
에이전시의 산출물은 보통 주요 화면의 시안입니다. 그러나 실제 서비스에는 로딩, 오류, 빈 목록, 예외 입력처럼 시안에 없는 상태가 화면마다 존재합니다. 색상·간격·컴포넌트 규칙이 정리된 디자인 시스템 없이 낱장 시안만 넘어오면, 개발팀은 빈 부분을 각자의 판단으로 메우게 되고 화면이 늘어날수록 결과물의 일관성은 무너집니다.
5. 오픈 이후 유지보수의 단절
서비스는 오픈이 끝이 아닙니다. 버튼 하나를 바꾸고 화면 하나를 추가할 때마다 디자인 에이전시와 개발사를 각각 다시 불러야 한다면, 계약 두 건과 조율 비용이 매번 반복됩니다. 현실에서는 개발사가 임의로 수정하면서 디자인 일관성이 서서히 무너지거나, 번거로움 때문에 수정 자체를 미루게 되는 경우가 많습니다.
세 가지 발주 구조, 총비용은 어디서 갈리는가
그렇다면 웹 개발 외주나 앱 개발 외주를 앞둔 기업의 선택지는 크게 세 가지입니다. 각 구조를 총비용 관점에서 비교하면 다음과 같습니다.
비교 항목
디자인 에이전시 + 개발사 분리 발주
국내 개발사 일괄 발주
한국 PM + 기획·디자인·개발 통합팀 (디비컨설팅 방식)
시안-구현 정합성 검증 시점
개발 착수 이후 (가장 늦음)
계약 후 내부 검토 단계
시안 단계부터 상시 검증
수정 책임 소재
불분명 — 양사 간 공방
개발사 단일 책임
한국 PM 단일 책임
발주사 담당자 투입 시간
많음 (중간 전달자 역할)
보통
적음 (PM이 단일 창구)
총비용 관점
재작업으로 상승 위험 높음
국내 인건비 구조로 높음
낮음 (재작업 최소화 + 글로벌 개발 단가)
분리 발주의 견적 합계는 언뜻 저렴해 보일 수 있습니다. 그러나 표의 첫 줄, 정합성 검증 시점이 늦어질수록 재작업 비용은 커집니다. 국내 일괄 발주는 책임 구조는 깔끔하지만 인건비 부담이 큽니다. 사내에 별도 제품팀이 없는 기업이라면, 기획·디자인·개발이 처음부터 한 팀으로 움직이고 책임자가 한 명인 세 번째 구조가 총비용이 가장 낮습니다.
디비컨설팅은 이 간극을 어떻게 없애는가 — 5단계 프로세스
디비컨설팅의 프로젝트는 다섯 단계로 진행됩니다. 각 단계는 앞서 말씀드린 다섯 가지 문제를 하나씩 구조적으로 차단하도록 설계되어 있습니다.
1단계 · 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 재작업의 대부분은 이 단계가 부실할 때 생기므로, 가장 공을 들이는 단계입니다.
2단계 · 개발팀 구성 — 프로젝트 전담팀을 2~4주 안에 구성합니다. 기획자, 디자이너, 개발자가 처음부터 한 팀이며, 시안이 나오기 전에 개발자가 구현 가능성을 함께 검토합니다.
3단계 · 프로젝트 개발 — 애자일 방식으로 진행 상황을 투명하게 공유합니다. 발주사 담당자는 중간 전달자가 아니라 의사결정자로만 참여합니다.
4단계 · 테스트 및 배포 — QA 프로세스를 거쳐 시안과 구현의 정합성, 예외 상태까지 검증한 뒤 배포합니다.
5단계 · 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원합니다. 오픈 후 화면을 고칠 때 두 회사를 다시 부를 필요가 없습니다.
1단계의 산출물이 곧 기획 문서, 즉 요구사항 정의서입니다. 이 문서가 왜 견적과 일정의 정확도를 좌우하는지는 요구사항 정의서 작성 가이드에서 자세히 다뤘습니다.
같은 팀 안에서 설계된 UI/UX — 실제 프로젝트
아래는 디비컨설팅이 구축한 프로젝트의 일부입니다. 공통점은 하나입니다. 이 서비스들의 UI/UX는 별도 디자인 에이전시가 아니라 개발과 같은 팀 안에서 설계되고 검증됐다는 점입니다.
삼성물산 홈닉 — 주거 플랫폼 앱
GS건설 엘리시안 리조트 — 웹·앱 통합 구축
하나투어 하나오픈챗 — 여행 상담 채팅 서비스
LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
교보생명 사내벤처 글펍 — 커뮤니티 서비스
센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
더 많은 사례는 구축 사례 페이지에서 확인하실 수 있습니다. 이 구조의 장점은 품질만이 아닙니다. 검증된 글로벌 개발팀을 활용하기 때문에, 국내 개발 인력을 직접 채용해 운영하는 경우와 비교하면 평균 40~60%의 비용 절감 효과가 있습니다.
이런 기업에 적합합니다 — 그리고 권하지 않는 경우
통합 구조가 모든 기업에 정답인 것은 아닙니다. 솔직하게 구분해 드리면 다음과 같습니다. 먼저 적합한 경우입니다.
사내에 기획자·디자이너가 없어 발주사 담당자가 중간 전달자가 될 수밖에 없는 기업
신규 서비스를 처음 만드는 기업 — 요구사항이 개발 과정에서 구체화되기 때문에 한 팀 구조의 이점이 가장 큽니다
이미 사내 디자인팀과 디자인 시스템이 갖춰져 있고 구현 인력만 필요한 경우 — 이때는 개발 파트너만 붙이는 편이 효율적입니다
브랜드 아이덴티티(BI·로고) 작업만 필요한 경우 — 이 영역은 디자인 전문 에이전시가 맞습니다
자주 묻는 질문
해외 개발팀이라던데, 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수까지 모두 PM의 책임입니다. 글로벌 개발자와의 협업은 팀 내부에서 이루어지며, 발주사 담당자가 영어를 쓸 일은 없습니다.
비용은 어떻게 산정되나요?
인력 등급별 단가에 투입 기간을 곱하는 방식이 기본입니다. 견적서에는 기획, 디자인, 개발, QA, 배포, 유지보수가 항목별로 구분되어 제시되므로, 어느 단계에 얼마가 들어가는지 확인하고 범위를 조정하실 수 있습니다.
기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 희망 일정과 예산 범위만 정리되어 있으면 개략 견적을 드릴 수 있습니다. 처음부터 모든 기능을 다 만들 필요는 없습니다. 첫 버전에 어디까지 담을지는 MVP 개발 범위를 정하는 방법을 참고하시면 좋습니다.
디자인 시안만 따로 요청할 수도 있나요?
가능합니다. 다만 권하지는 않습니다. 이 글에서 말씀드린 대로, 시안 단계에서 구현 가능성이 검증되지 않으면 그 비용은 개발 단계에서 재작업으로 되돌아옵니다. 시안만 필요하시더라도 개발 관점의 검토가 붙어 있는 시안인지 반드시 확인하시길 권합니다.
소스코드와 디자인 산출물의 소유권은 누구에게 있나요?
발주사에 귀속됩니다. 디자인 원본 파일은 물론 소스코드, API 명세, DB 스키마, 배포 절차 문서까지 인계해 드립니다. 소유권과 인계 범위는 계약서에 명시해 두는 것이 안전한데, 확인해야 할 조항은 개발 외주 계약서에서 반드시 확인할 조항에 정리해 두었습니다.
정리
UI/UX 디자인 외주의 진짜 비용은 시안 가격이 아니라 시안과 구현 사이의 간극에서 발생합니다. 시안이 아무리 훌륭해도 구현 단계에서 검증이 시작되면 재작업, 책임 공방, 일정 지연이 뒤따르고, 그 비용은 결국 발주사의 몫이 됩니다. 기획·디자인·개발이 한 팀으로, 한 명의 한국 PM 아래에서 움직이는 구조라면 그 간극 자체가 생기지 않습니다. 지금 검토 중인 프로젝트가 있다면, 디자인 시안을 발주하기 전에 통합 구조의 견적을 먼저 받아 비교해 보시기 바랍니다.
무료 상담
비슷한 플랫폼을 만들고 계신가요?
디비컨설팅은 100건 이상의 웹·앱·플랫폼 구축 경험이 있습니다. 기획 단계에서 놓치기 쉬운 부분부터 함께 점검해 드립니다.
앱스토어 심사 거절 통보는 대부분 가장 나쁜 타이밍에 도착합니다. 개발사로부터 “개발 완료” 보고를 받고, 출시일을 확정하고, 보도자료와 광고 집행 일정까지 잡아 둔 상태에서 애플이나 구글의 거절 메일이 오는 것입니다. 개발사에 문의하면 돌아오는 답은 대개 한 문장입니다. “수정해서 재제출하겠습니다.” 언제까지, 무엇을, 왜 고치는지에 대한 설명은 없습니다. 그 사이 마케팅 일정은 그대로 흘러가고, 출시가 몇 주씩 밀리는 일은 이 업계에서 전혀 드물지 않습니다.
디비컨설팅은 100건 이상의 프로젝트를 수행하며 98%의 고객 만족도를 유지해 왔습니다. 그 과정에서 반복적으로 확인한 패턴이 하나 있습니다. 심사 단계에서 일정이 무너지는 프로젝트에는 공통점이 있다는 것입니다. 스토어 심사 대응을 “누가 책임지는지”가 계약 어디에도 명시되어 있지 않다는 점입니다.
심사 거절이 반복되는 진짜 이유
앱스토어 심사 거절은 운이 나빠서 생기는 사고가 아닙니다. 애플과 구글의 심사 가이드라인은 공개되어 있고, 거절 사유의 대부분은 심사 기준을 아는 사람이라면 제출 전에 예측할 수 있는 것들입니다. 그런데도 거절이 반복되는 이유는 기술 문제가 아니라 구조 문제입니다.
발주사 입장에서 “개발 완료”와 “출시 완료”는 같은 말처럼 들립니다. 그러나 계약서상 두 지점 사이에는 공백이 있는 경우가 많습니다. 개발사는 기능 구현까지를 자신의 범위로 보고, 스토어 제출은 형식적인 마지막 절차로 취급합니다. 발주사는 심사 기준을 모르기 때문에 확인할 방법이 없습니다. 결과적으로 권한 설계, 결제 구조, 심사용 계정 준비, 완성도 기준 같은 심사 통과의 핵심 요건을 아무도 소유하지 않은 채 제출 버튼이 눌립니다.
내부에 개발 조직이 없는 기업이 앱 개발 외주를 맡길 때 이 공백은 더 커집니다. 개발사가 보내온 결과물이 심사 기준을 충족하는지 발주사가 스스로 검증할 수 없기 때문입니다. 이것이 핵심입니다. 심사 거절은 제출하는 순간에 발생하지만, 그 원인은 몇 주 혹은 몇 달 전 개발 단계의 의사결정에서 이미 만들어져 있습니다.
가장 자주 걸리는 6가지 리젝 사유
아래 여섯 가지는 애플과 구글이 공개한 심사 가이드라인에서 반복적으로 문제가 되는 대표 유형입니다. 주목할 점은 여섯 가지 모두 제출 시점이 아니라 개발 초기의 결정에서 비롯된다는 사실입니다.
1. 완성도 미달
크래시, 명백한 버그, “준비 중입니다” 같은 플레이스홀더 콘텐츠가 남아 있는 앱은 애플 가이드라인 2.1이 요구하는 최소 완성도에 미달해 거절됩니다. 이것은 마지막 주에 테스트를 며칠 더 한다고 해결되는 문제가 아닙니다. 프로젝트 초기에 “어느 수준을 완성으로 볼 것인가”라는 QA 기준을 합의하지 않았기 때문에 생기는 문제입니다. 완성 기준이 문서화되어 있지 않으면 개발사의 “다 됐습니다”와 심사자의 판단은 다를 수밖에 없습니다.
2. 권한·개인정보 처리 미비
카메라, 위치, 연락처 같은 권한을 요청하면서 그 목적을 사용자에게 설명하지 않거나, 개인정보처리방침 URL이 누락된 경우입니다. 권한을 어디에 쓸지, 방침 문서를 누가 작성해 어디에 게시할지는 요구사항 정의 단계에서 결정되어야 할 항목입니다. 개발이 끝난 뒤에 “방침 페이지가 필요하다더라”는 사실을 처음 알게 되는 구조라면, 이미 설계 단계에서 심사 요건이 빠져 있었다는 뜻입니다.
3. 결제 정책 위반
디지털 콘텐츠나 구독처럼 인앱결제(IAP) 대상인 기능을 외부 결제 링크로 연결하면 거절됩니다. 결제 구조는 수수료와 직결되기 때문에 개발사가 임의로 정할 수 없고, 발주사가 사업 모델 차원에서 판단해야 하는 사안입니다. 이 논의가 개발 착수 전에 이루어지지 않으면, 결제 모듈을 다 만들어 놓고 심사 단계에서 구조를 통째로 바꾸는 최악의 재작업이 발생합니다.
4. 메타데이터 불일치
스토어에 올린 스크린샷과 설명이 실제 앱 기능과 다르면 거절 사유가 됩니다. 흔한 원인은 단순합니다. 개발 도중 기능이 바뀌었는데 스토어 등록 자료는 초기 기획서 기준으로 만들어지는 것입니다. 개발 산출물과 스토어 자산을 한 사람이 함께 관리하지 않으면, 두 문서는 시간이 지날수록 반드시 어긋납니다.
5. 심사용 데모 계정 미제공
로그인이 필요한 앱인데 심사자가 쓸 수 있는 데모 계정을 제공하지 않으면, 심사자는 핵심 기능을 확인할 수 없어 그대로 거절합니다. 기술적으로는 사소해 보이지만 실제로 매우 자주 발생하는 유형입니다. 심사자용 계정과 테스트 데이터를 누가 준비하는지가 업무 분장에 없기 때문입니다. 개발사는 발주사 일이라 생각하고, 발주사는 그런 것이 필요한지조차 모릅니다.
6. 최소 기능성 미달
기존 웹사이트를 웹뷰로 감싼 수준의 앱은 “앱으로서의 고유한 가치가 없다”는 이유로 거절됩니다. 이것은 코딩 품질의 문제가 아니라 기획 단계의 문제입니다. 웹뷰 중심으로 갈지, 네이티브로 갈지, 아니면 크로스플랫폼 앱 개발 방식으로 양쪽 스토어를 함께 노릴지는 착수 전에 심사 기준까지 고려해 결정해야 합니다. 견적을 낮추기 위해 웹뷰를 선택해 놓고 심사에서 막히면, 절감했다고 믿었던 비용은 재개발 비용으로 돌아옵니다.
여섯 가지의 공통점이 보이실 것입니다. 어느 것도 제출 직전의 체크리스트로 막을 수 없습니다. 전부 요구사항 정의와 설계 단계에서 결정되는 사안이고, 내부 개발 조직이 없는 발주사가 스스로 감시할 수 있는 영역이 아닙니다.
어느 나라가 아니라 어떤 구조에 발주할 것인가
그렇다면 발주사가 실제로 선택할 수 있는 것은 무엇일까요. 개발사를 더 다그치는 것도, 심사 가이드라인을 직접 공부하는 것도 근본 해법이 아닙니다. 선택지는 발주 구조입니다. 앱 개발 기간과 비용만 놓고 국내와 해외를 비교하는 경우가 많지만, 실제 차이를 만드는 것은 “개발 완료에서 출시 완료까지의 공백을 누가 소유하는가”입니다.
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
개발 단가
높음
낮음
낮음
요구사항 정의 책임
개발사
발주사 본인
한국 PM
스토어 심사 대응
개발사 (계약 범위에 따라 다름)
발주사 본인
한국 PM
커뮤니케이션 언어
한국어
영어
한국어
발주사 담당자 투입 시간
보통
매우 많음
적음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
국내 개발사는 언어 장벽이 없지만 단가가 높고, 심사 대응이 계약 범위에 들어 있는지는 회사마다 다릅니다. 해외 직접 발주는 단가는 낮지만 요구사항 정의부터 심사 대응까지 전부 발주사 담당자가 영어로 직접 감당해야 하므로, 내부 전문 인력이 없다면 절감분이 담당자 인건비와 재작업 비용으로 사라집니다. 세 번째 구조는 글로벌 개발팀의 단가를 취하되, 요구사항 정의와 심사 대응이라는 두 개의 공백을 한국 PM이라는 단일 책임자에게 귀속시키는 방식입니다.
디비컨설팅은 심사 리스크를 이렇게 통제합니다
디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 관리하는 IT 아웃소싱 구조로 프로젝트를 수행합니다. 발주사는 처음부터 끝까지 한국인 PM과 한국어로만 소통하며, 심사 대응은 별도 옵션이 아니라 5단계 프로세스 안에 포함되어 있습니다.
1단계 — 상담 및 요구 분석. 요구사항을 한국어로 문서화합니다. 이 단계에서 권한 설계, 결제 구조, 심사용 계정 준비, 개인정보처리방침 같은 스토어 심사 요건이 함께 정의됩니다. 앞서 본 여섯 가지 리젝 사유가 발생하는 지점이 바로 여기이므로, 여기서 문서로 못 박으면 재작업의 대부분이 사라집니다. 첫 발주라면 MVP 개발 범위를 이 단계에서 함께 좁혀 심사 리스크와 예산을 동시에 통제합니다.
2단계 — 개발팀 구성. 50개 이상의 글로벌 파트너사 네트워크에서 프로젝트에 맞는 전담팀을 2~4주 내에 구성합니다.
3단계 — 프로젝트 개발. 애자일 방식으로 진행하며, 진행 상황을 투명하게 공유합니다. 개발 중 기능이 바뀌면 PM이 스토어 등록 자료와의 정합성까지 함께 관리합니다.
4단계 — 테스트 및 배포. QA를 거쳐 출시하며, 스토어 제출 대응이 이 단계의 정식 업무입니다. 심사에서 거절이 나오면 PM이 거절 사유를 분석하고 수정과 재제출을 관리합니다. “수정해서 재제출하겠다”는 통보가 아니라, 무엇을 왜 고치고 언제 다시 제출하는지가 발주사에게 한국어로 보고됩니다.
5단계 — 운영 및 유지보수. 출시 후 문서와 함께 인계하며, 운영 단계의 지원 범위와 앱 유지보수 비용을 항목별로 명확히 구분해 제시합니다.
이 구조로 국내 채용 대비 평균 40~60%의 비용 절감을 유지하면서도, 심사 대응의 책임 소재가 계약과 프로세스에 명시됩니다.
내부에 iOS/Android 출시 경험이 있는 개발팀이 이미 있는 기업 — 심사 대응을 자체 소화할 수 있으므로 이 구조의 이점이 크지 않습니다.
스토어 출시가 아니라 사내 배포용 앱만 필요한 기업 — 심사 자체가 없으므로 더 저렴한 다른 선택지가 있습니다.
자주 묻는 질문
해외 개발팀인데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 모두 PM의 책임이며, 글로벌 개발팀과의 커뮤니케이션은 발주사 업무 범위에 들어오지 않습니다.
심사에서 거절되면 재심사 대응은 누가 하나요?
재심사 대응은 테스트·배포 단계의 일부로 프로세스에 포함되어 있습니다. 앱스토어 심사 거절이 발생하면 PM이 거절 사유를 분석하고, 수정 범위와 재제출 일정을 관리해 발주사에 보고합니다.
기획서가 없는데 견적이 가능한가요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 희망 일정과 예산 범위만 정리되어 있으면 개략 견적을 산출할 수 있습니다. 상세 요구사항 문서화는 1단계에서 함께 진행합니다.
비용은 어떻게 산정되나요?
투입 인력의 등급별 단가에 투입 기간을 곱해 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 단계에 비용이 쓰이는지 명확히 확인하실 수 있습니다.
소스코드와 스토어 계정 소유권은 누구에게 있나요?
소스코드는 발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 함께 인계하며, 스토어 개발자 계정도 발주사 명의로 개설하는 것을 권장합니다. 개발사가 바뀌어도 서비스 운영이 끊기지 않는 구조를 만들기 위해서입니다.
정리
앱스토어 심사 거절은 제출 버튼을 누르는 순간이 아니라 발주 구조를 정하는 순간에 이미 결정됩니다. 권한 설계, 결제 구조, 심사용 계정, 완성도 기준은 전부 개발 초기의 의사결정이고, 내부 개발 조직이 없는 기업이 이를 스스로 감시할 방법은 없습니다. 따라서 물어야 할 질문은 “심사에 통과할 수 있는 개발사인가”가 아니라 “요구사항 정의부터 재심사 대응까지, 출시 완료를 계약과 프로세스로 책임지는 구조인가”입니다. 심사 대응까지 책임지는 구조로 발주하는 것이 출시 일정을 지키는 가장 확실한 방법입니다.
무료 상담
비슷한 플랫폼을 만들고 계신가요?
디비컨설팅은 100건 이상의 웹·앱·플랫폼 구축 경험이 있습니다. 기획 단계에서 놓치기 쉬운 부분부터 함께 점검해 드립니다.
외주 개발 보안은 대개 견적이 끝난 다음에 문제가 됩니다. 개발사를 정하고, 금액을 맞추고, 착수 일정까지 잡아 둔 상태에서 사내 정보보안 담당자나 법무 검토가 들어옵니다. 질문은 거의 항상 같은 세 가지입니다. 개발자가 어느 나라에 있습니까. 우리 고객 데이터에 접근합니까. 사고가 나면 누구에게 책임을 묻습니까.
이 세 질문에 문서로 답하지 못하면 프로젝트는 그 자리에서 멈춥니다. 개발사의 기술이 부족해서가 아닙니다. 통제 구조를 설명할 수 있는 사람이 발주사 안에 없기 때문입니다. 그리고 이 검토는 착수 직전이 아니라 개발사를 고르는 단계에서 이미 끝나 있어야 하는 일입니다.
디비컨설팅은 삼성물산, GS건설, 하나투어, 직방, LS일렉트릭, 교보생명, 가천대학교 등과 100건 이상의 웹·앱·플랫폼 프로젝트를 수행해 왔습니다. 대기업 건설·상사, 보험, 대학, 산업 B2B 플랫폼이 모두 포함됩니다. 그 과정에서 반복해서 확인한 것이 있습니다. 보안 문제는 개발팀이 해외에 있어서 생기는 것이 아니라, 통제 지점이 계약서와 프로세스 어디에도 정의되지 않아서 생깁니다.
사고는 “해외라서” 나지 않습니다
국내 개발사에 맡기든 해외 팀에 맡기든 실제로 문제가 생기는 자리는 같습니다. 다만 국내 발주에서는 그 자리가 관행으로 덮여 있고, 해외 발주에서는 덮이지 않은 채 드러납니다. 반복해서 나타나는 구멍은 세 개입니다.
계정이 사람이 아니라 팀 단위로 발급됩니다
서버, 코드 저장소, 관리자 페이지 계정을 개발사에 하나씩 넘기고 “개발팀에서 알아서 쓰세요”로 끝나는 경우가 많습니다. 이 상태에서는 누가 언제 무엇을 봤는지 기록이 남지 않습니다. 인력이 교체되어도 계정은 그대로 남고, 계약이 끝나도 회수 대상이 특정되지 않습니다.
사고가 났을 때 발주사를 실제로 곤란하게 만드는 것은 유출 자체보다 경로를 특정할 수 없다는 사실입니다. 감사에도, 고객 문의에도 답할 근거가 없습니다.
실제 데이터가 개발 환경으로 넘어갑니다
테스트를 제대로 하려면 실제와 비슷한 데이터가 필요합니다. 그래서 운영 데이터베이스를 그대로 복사해 개발 환경에 붓는 일이 흔하게 일어납니다. 이 순간 고객 이름, 연락처, 결제 이력이 관리 범위 밖으로 나갑니다.
이 결정은 보통 계약서에 없습니다. 개발 중반에 실무자끼리 구두로 정해집니다. 발주사 담당자가 승인한 기억조차 없는 경우가 드물지 않습니다.
계약 상대와 코드를 만지는 사람이 다릅니다
해외 개발사나 프리랜서 플랫폼을 통해 직접 발주하면, 계약서에 서명한 주체와 실제로 코드를 쓰는 사람이 서로 다른 나라에 있는 구조가 만들어집니다. 재하도급이 한 단계 더 들어가면 발주사는 최종 작업자가 누구인지 알지 못합니다.
이 구조에서 비밀유지 약정은 서류로만 존재합니다. 위반을 확인할 방법도, 실행할 관할도 발주사 쪽에 없기 때문입니다. IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조와 같은 뿌리에서 나오는 문제입니다.
발주 전에 문서로 확인해야 할 다섯 가지
보안 인증서를 받아 보는 것보다 아래 다섯 개의 답을 문서로 받는 편이 실제로 더 효과가 있습니다. 인증은 조직의 상태를 말해 주지만, 아래 항목은 이 프로젝트에서 무엇이 어떻게 다뤄지는지를 말해 주기 때문입니다.
1. 접근 권한 — 누가, 어떤 계정으로, 무엇에
투입 인력별로 계정을 따로 발급하는지, 접근 대상이 역할에 맞게 제한되는지, 접속 기록이 남는지를 확인하십시오. 요청할 문서는 한 장이면 됩니다. 이름, 역할, 접근 대상 시스템, 권한 수준이 적힌 표입니다. 이 표를 만들 수 없다는 답이 돌아온다면 그 답 자체가 결론입니다.
2. 개발·테스트 데이터 — 실데이터를 쓸 것인가
원칙은 쓰지 않는 것이고, 대안은 가명 처리한 데이터셋입니다. 불가피하게 실데이터가 필요한 구간이 있다면 그 구간과 기간, 승인 절차를 요구사항 정의서 단계에서 미리 적어 두어야 합니다. 개발 중반에 정하면 대부분 편한 쪽으로 결정됩니다.
3. 개인정보 처리 위탁과 국외 이전
개인정보가 포함된 시스템을 외부에 맡기면 위탁 관계가 생기고, 처리 인력이 국외에 있으면 국외 이전 문제가 따라옵니다. 확인할 것은 두 가지입니다. 위탁 계약이 문서로 존재하는지, 그리고 수탁자로 누가 적히는지입니다.
계약 상대가 국내 법인이면 발주사의 책임 추적 지점이 국내에 남습니다. 재위탁이 있다면 그 범위와 대상을 그 법인이 문서로 관리하고, 발주사는 한 단계만 확인하면 됩니다. 반면 해외 개발사와 직접 계약하면 위탁 관계의 관리 책임이 통째로 발주사에게 넘어옵니다. 단가를 아끼려던 결정이 법무·보안 업무를 발주사 내부로 옮겨오는 결정이 되는 지점입니다.
4. 코드와 산출물이 누구 계정에 보관되는가
이 항목은 순서 하나로 결과가 뒤집힙니다. 개발사 조직 계정에 저장소를 만들고 발주사를 초대하는 방식이면, 계약이 끝날 때 나가는 쪽이 발주사입니다. 반대로 발주사 계정에 저장소를 두고 개발 인력을 초대하면, 종료 시점에 초대를 해제하는 것으로 끝납니다.
서버와 클라우드 계정도 같습니다. 결제 수단이 개발사 카드로 등록되어 있으면 인프라의 소유권이 개발사에 있는 것과 같은 상태가 됩니다. 착수 첫 주에 정하면 비용이 들지 않고, 종료 직전에 정하려 하면 협상 사안이 됩니다.
5. 종료 시점의 회수 절차
계약 종료일에 무엇이 회수되는지 목록으로 받아 두십시오. 계정 비활성화, 로컬 사본 삭제 확인, 외부 연동 서비스의 키 재발급, 문서 인계입니다. 특히 결제·문자 발송·지도·푸시처럼 개발사 계정으로 붙어 있는 외부 서비스는 계약이 끝나도 서비스의 일부가 개발사 손에 남습니다.
이 다섯 항목은 별도 보안 부속서로 만들기보다 개발 외주 계약서의 산출물·검수 조항과 한 묶음으로 두는 편이 실효성이 있습니다. 부속서는 읽히지 않지만 검수 기준은 대금과 연결되어 있기 때문입니다.
세 가지 발주 방식은 보안에서 이렇게 갈립니다
한국 기업이 실제로 마주하는 선택지는 “국내냐 해외냐”가 아닙니다. 위의 다섯 항목을 누가 정의하고 누가 관리하는가로 갈립니다.
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
계약 상대
국내 법인
해외 법인 또는 개인
국내 법인
보안 요구사항 작성
개발사
발주사 본인
한국 PM
접근 권한 관리 주체
개발사
발주사 본인
한국 PM
최종 작업자 확인
가능
어려움
가능
사고 시 책임 추적
가능
어려움
가능
커뮤니케이션 언어
한국어
영어
한국어
개발 단가
높음
낮음
낮음
발주사 담당자 투입 시간
보통
매우 많음
적음
해외 직접 발주가 위험한 이유는 개발자의 국적이 아닙니다. 통제의 주체가 발주사 본인으로 넘어오기 때문입니다. 보안 요구사항을 영어로 쓰고, 계정 권한 표를 직접 관리하고, 위탁·이전 문서를 직접 챙길 인력이 사내에 있다면 직접 발주가 가장 쌉니다. 정말 그렇습니다. 그 인력이 없는 회사에서만 단가 절감이 법무·보안 업무로 되돌아옵니다.
인도를 비롯한 해외 개발 시장이 단순 인력 공급에서 관리 체계를 갖춘 파트너십으로 이동해 온 배경은 인도 IT 아웃소싱의 진화에 따로 정리해 두었습니다.
디비컨설팅이 이 지점들을 통제하는 방식
IT 아웃소싱 프로젝트는 다음 5단계로 진행됩니다. 위의 다섯 항목이 각 단계 어디에서 정해지는지 함께 적었습니다.
상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 실데이터 사용 여부, 개인정보가 지나가는 구간, 접근이 필요한 시스템 범위를 이 단계에서 확정합니다. 개발 중반에 구두로 정해지는 일이 없도록 하는 것이 목적입니다.
개발팀 구성 — 전담팀을 2~4주 안에 구성합니다. 팀이 확정되면 인력별 계정과 권한 수준이 표로 정리됩니다. 팀 계정 하나를 넘기는 방식이 아닙니다.
프로젝트 개발 — 애자일로 진행하며 진행 상황을 투명하게 공유합니다. 발주사는 한국인 PM하고만 한국어로 소통하고, 개발팀과의 영어 소통과 권한 관리는 PM이 맡습니다.
테스트 및 배포 — QA 프로세스를 거쳐 릴리스합니다.
운영 및 유지보수 — 문서와 함께 인계합니다. 소스코드는 발주사 귀속이며 API 명세서, DB 스키마, 배포 절차 문서까지 넘깁니다.
핵심은 계약 상대가 한국 법인이라는 점입니다. 발주사는 국내에서 계약하고, 국내에서 책임을 묻고, 한국어 문서로 검수합니다. 개발 인력이 어디에 있든 발주사가 관리해야 하는 대상은 한 곳으로 모입니다.
이 구조로 만든 것들
삼성물산 — 홈닉, 주거 플랫폼 앱
GS건설 — 엘리시안 리조트 웹·앱 통합 구축
하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
직방 — 호갱노노, 부동산 데이터 서비스
LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
교보생명 — 사내벤처 글펍, 커뮤니티 서비스
가천대학교 — 학사관리 시스템
센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
와디즈 — 글로벌 플랫폼
100건 이상의 프로젝트, 50개 이상의 글로벌 파트너사, 고객 만족도 98%. 다른 사례는 포트폴리오에서 확인하실 수 있습니다.
이런 기업에 적합합니다
고객 개인정보나 결제 정보가 지나가는 서비스를 외부에 맡겨야 하는데, 사내에 보안 요구사항을 정의할 인력이 없는 기업
내부 정보보안 검토나 그룹사 심사를 통과해야 하는데 제출할 문서를 개발사에서 받지 못하고 있는 기업
사내에 보안 담당자와 개발 리드가 이미 있는 기업. 권한 표와 위탁 문서를 직접 관리하실 수 있다면 해외 인력을 직접 계약하는 편이 더 쌉니다. 저희 구조의 가치가 정확히 그 관리 업무에 있기 때문입니다.
망분리 환경 안에서만 개발이 가능한 프로젝트. 물리적으로 격리된 내부망 상주가 조건이라면 원격 전담팀 구조는 맞지 않습니다.
2~3주 안에 결과물이 필요한 프로젝트. 전담팀 구성에만 2~4주가 걸립니다.
가장 낮은 견적이 유일한 기준인 발주. 권한 분리, 가명 데이터셋 준비, 문서 인계를 계약에 넣으면 견적은 올라갑니다. 그 차액이 무엇을 사는 것인지가 이 글의 내용입니다.
자주 묻는 질문
개인정보가 포함된 시스템도 맡길 수 있나요?
가능합니다. 다만 상담 단계에서 개인정보가 지나가는 구간을 먼저 정리하고, 개발·테스트에 실데이터를 쓰지 않는 것을 기본으로 설계합니다. 위탁 계약과 접근 권한 표는 착수 전에 문서로 확정합니다. 국외 이전 고지가 필요한 경우 그 범위도 이 단계에서 정리합니다.
소스코드 소유권은 어떻게 되나요?
발주사 귀속입니다. API 명세서, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이후 유지보수를 다른 회사가 맡아도 이어받을 수 있는 상태로 넘기는 것을 기준으로 삼습니다. 저장소와 클라우드 계정을 발주사 명의로 두는 것도 같은 이유입니다.
해외 개발팀인데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수가 모두 PM의 책임 범위입니다. 개발팀과의 영어 소통은 PM이 담당하며 발주사가 부담하지 않습니다. 보안 관련 요청도 같은 경로로 처리됩니다.
기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 개인정보나 결제가 포함되는지만 함께 알려주시면 보안 관련 공수도 처음부터 견적에 반영합니다.
비용은 어떤 기준으로 산정되나요?
등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시합니다. 견적이 착수 후에 늘어나는 구조적 이유는 IT 외주개발 비용이 견적을 넘어서는 지점에 정리해 두었습니다.
진행 중에 팀 규모를 조정할 수 있나요?
가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 인력이 빠질 때 계정 회수와 권한 해제가 함께 처리되는 것이 조정 절차의 일부입니다.
정리
외주 개발 보안에서 실제로 갈리는 것은 개발자가 어느 나라에 있느냐가 아니라, 접근 권한·실데이터 사용·위탁 관계·저장소 소유·종료 시 회수를 누가 정의하고 관리하느냐입니다. 이 다섯 가지를 발주사가 직접 관리할 수 있다면 해외에 직접 발주하는 것이 가장 저렴합니다. 관리할 사람이 없다면, 단가를 아끼는 결정이 법무와 보안 업무를 사내로 옮겨오는 결정이 됩니다. 이미 진행 중인 프로젝트에서 이 문서들을 받지 못하고 있다면 개발사 교체를 언제 결정해야 하는지를 함께 검토해 보시기 바랍니다.
무료 상담
인도 개발팀, 직접 관리하지 않아도 됩니다
디비컨설팅은 한국인 PM이 요구사항 정의부터 일정 관리까지 책임집니다. 언어와 시차 부담을 고객사가 떠안지 않는 구조로 진행됩니다.
개발사 교체를 검색해서 이 글을 보고 계신다면, 아마 지난 몇 주 동안 거의 같은 내용의 주간 보고를 반복해서 받고 계실 겁니다. 진행률은 지난달에도 80%였고 이번 달에도 80%입니다. 데모는 매번 “거의 다 됐다”는 설명과 함께 열리지만, 화면 두세 개를 넘기면 멈춥니다. 수정 요청에 답이 오는 데 이틀이 걸리고, 그 답은 대개 “확인 후 회신드리겠습니다”입니다.
이 상태에서 가장 먼저 드는 생각은 교체가 아니라 계산입니다. 이미 지급한 기성금이 얼마인지, 여기서 손을 떼면 그 돈이 어떻게 되는지, 새로 시작하면 처음부터 다시 해야 하는 것은 아닌지를 먼저 따지게 됩니다. 그래서 대부분의 발주사는 필요한 시점보다 훨씬 오래 버팁니다. 한 달만 더 기다려 보자는 판단이 세 번 반복되면 분기가 지나가 있습니다.
이 글은 개발사 교체를 언제 결정해야 하는지, 결정 전에 무엇을 확보해야 하는지, 교체할 곳을 어떤 기준으로 골라야 하는지를 순서대로 정리했습니다. 미리 말씀드리면 결론은 “더 좋은 개발사를 찾으십시오”가 아닙니다. 첫 번째 개발사가 실패한 이유는 대개 그 회사의 성의 문제가 아니라 발주 구조의 문제이고, 같은 구조를 가진 다른 회사로 옮기면 같은 일이 다시 일어납니다.
디비컨설팅은 100개 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 협업하며, 고객 만족도 98%를 유지하고 있습니다. 삼성물산, GS건설, LS일렉트릭, 하나투어, 가천대학교의 서비스를 구축했습니다. 아래 내용은 그 과정에서 반복적으로 확인한 패턴입니다.
개발사 교체가 논의되는 프로젝트의 공통 구조
멈춘 프로젝트를 들여다보면, 원인이 담당 개발자의 역량보다 앞선 단계에 있는 경우가 많습니다. 계약 시점에 이미 정해진 세 가지 구조 때문에 프로젝트는 대체로 같은 방식으로 멈춥니다. 저희가 IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조를 따로 정리한 이유도 여기에 있습니다.
요구사항이 문서로 존재하지 않습니다
착수 시점에 발주사가 받은 문서가 제안서와 견적서뿐인 경우가 많습니다. 화면 정의서, 기능 명세, 예외 처리 규칙이 없는 상태로 개발이 시작되면 이후의 모든 논의가 기억에 의존하게 됩니다. 회의에서 이야기한 기능이 빠져 있을 때 발주사는 “분명히 말씀드렸다”고 하고, 개발사는 “그 범위는 계약에 없었다”고 합니다. 양쪽 다 거짓말을 하는 것이 아니라 판단할 근거가 없는 것입니다.
이 구조에서는 분쟁이 사실 확인이 아니라 협상으로 흐릅니다. 그리고 협상은 대개 발주사에게 불리합니다. 개발사는 남은 일정과 투입 인력을 알고 있고 발주사는 모르기 때문입니다. 요구사항 문서는 개발을 잘하기 위한 부속물이 아니라, 분쟁이 생겼을 때 사실관계를 확정하는 장치입니다.
진행률 보고를 검증할 방법이 없습니다
“80%”라는 숫자는 검증 가능한 형태가 아닙니다. 무엇을 기준으로 80%인지, 남은 20%에 어떤 작업이 포함되는지가 정의되어 있지 않기 때문입니다. 진행률이 몇 달째 같은 자리에 머무는 프로젝트는 일이 아예 진행되지 않아서가 아니라, 처음부터 진행률을 셀 수 있는 단위로 쪼개지 않았기 때문에 그렇게 보입니다.
검증 가능한 보고는 숫자가 아니라 상태로 옵니다. 어떤 기능이 테스트 서버에 올라가 있고, 어떤 기능이 검수 대기이고, 어떤 항목이 아직 착수되지 않았는지가 목록으로 나와야 합니다. 발주사가 직접 눌러 볼 수 있는 테스트 환경이 없다면, 지금 받고 있는 진행률은 근거를 확인할 수 없는 숫자입니다.
산출물과 소스코드가 개발사 안에만 있습니다
세 번째 구조가 교체를 가장 어렵게 만듭니다. 소스코드가 개발사 계정의 저장소에만 있고, 서버와 도메인과 각종 API 키가 개발사 명의로 발급되어 있고, 데이터베이스 구조를 아는 사람이 그쪽 개발자 한 명뿐인 상태입니다. 이때 교체는 계약 해지의 문제가 아니라 이관의 문제가 됩니다.
교체를 망설이게 만드는 것은 이미 쓴 돈입니다. 하지만 실제로 비용을 키우는 것은 결정을 미루는 시간입니다. 이미 지급한 금액은 교체를 하든 하지 않든 회수되지 않는 반면, 지연되는 동안 발생하는 비용 — 시장 진입 시점을 놓치는 손실, 담당자가 조율에 쓰는 시간, 그리고 매달 늘어나는 이관 범위 — 은 계속 새로 발생합니다. 판단 기준은 “지금까지 얼마를 썼는가”가 아니라 “이 개발사와 계속 갔을 때 남은 일정 안에 완료될 근거가 있는가”입니다.
교체 전에 확인할 6가지
교체를 결정했다면, 통보 전에 확보해야 할 것이 있습니다. 순서가 중요합니다. 해지 의사를 먼저 전달하면 협조를 받기 어려워지는 경우가 많기 때문에, 아래 항목은 가능한 한 통보 이전에 확인하시는 편이 안전합니다.
1. 소스코드와 형상관리 접근 권한이 우리에게 있는지
Git 저장소에 발주사 계정으로 접근할 수 있는지 확인하십시오. 볼 것은 세 가지입니다. 저장소의 소유 계정이 누구인지, 전체 커밋 이력을 내려받을 수 있는지, 현재 운영 중인 버전이 어느 브랜치인지입니다. 개발사가 완성된 파일만 압축해서 전달하는 방식이라면 이력이 없는 코드를 받게 되고, 다음 개발사는 왜 그렇게 구현했는지를 알 수 없습니다. 서버, 도메인, 클라우드, 외부 API 계정의 명의도 같은 기준으로 확인하십시오.
2. 산출물 범위가 문서로 존재하는지
계약서에 적힌 산출물 목록과 실제로 받은 문서를 나란히 놓고 비교하십시오. 최소한 기획서(화면 정의서), API 명세, 데이터베이스 스키마, 배포 절차서 네 가지는 있어야 다음 개발사가 이어받을 수 있습니다. 특히 배포 절차서가 없으면 코드를 받아도 서비스를 다시 띄우지 못하는 상황이 생깁니다. 없다면 지금 요청하십시오. 계약 관계가 유지되는 동안이 이 요청이 통하는 마지막 시점입니다.
3. 중도 해지 조항과 기성 정산 기준
계약서에서 해지 통보 기간, 귀책사유 판단 방식, 기성 정산 기준, 지연배상금 조항을 먼저 확인하십시오. 기성 정산이 투입 공수 기준인지 완료 산출물 기준인지에 따라 정산 금액이 크게 달라집니다. 완료 산출물 기준이라면, 2번에서 확인한 문서 상태가 그대로 협상 근거가 됩니다. 다음 계약에서 같은 상황을 피하려면 개발 외주 계약서에서 서명 전에 확인할 조항을 함께 보시는 것이 좋습니다. 이 단계에서 오간 메일과 회의록을 시간순으로 정리해 두시는 것도 실무적으로 도움이 됩니다.
4. 이어받을 수 있는 상태인지, 재개발이 빠른지
감정이 아니라 기준으로 판단해야 하는 항목입니다. 다음 중 해당하는 것이 많다면, 재개발이 이어받기보다 빠른 경우도 있습니다.
코드에 주석과 문서가 거의 없고, 함수·변수 이름만으로 의도를 알 수 없다
데이터베이스 구조가 정리되지 않아 화면 하나를 고치면 다른 화면이 깨진다
테스트 코드가 전혀 없어 수정 후 정상 동작을 수동으로만 확인할 수 있다
사용된 프레임워크나 라이브러리 버전이 이미 지원 종료 상태다
완료로 보고된 기능 중 실제로 동작하는 비율이 절반 이하다
반대로 기능이 화면 단위로 분리되어 있고, 데이터 구조가 정리되어 있고, 배포가 재현 가능하다면 이어받는 편이 유리합니다. 판단 방식 자체는 고칠 것과 다시 만들 것을 가르는 기준과 같습니다. 다만 이 판단은 코드를 열어 보지 않고는 할 수 없습니다. 교체 후보 업체에 기존 코드 진단을 먼저 요청하시고, 진단 없이 견적부터 제시하는 곳은 한 번 더 확인해 보시는 것이 좋습니다.
5. 지식재산권과 소스코드 소유권이 누구에게 귀속되는지
계약서에 소유권 귀속 조항이 있는지, 있다면 누구에게 귀속되는지 확인하십시오. 이 조항이 아예 빠져 있거나, 개발사가 저작권을 보유하고 발주사에 사용권만 부여하는 형태로 되어 있는 경우가 적지 않습니다. 후자라면 코드를 받아도 다음 개발사가 자유롭게 수정하고 배포할 수 있는지가 불확실해집니다. 제3자 라이브러리나 상용 솔루션이 포함된 경우, 그 라이선스가 발주사 명의로 이전 가능한지도 함께 확인하십시오.
6. 다음 개발사에게 넘길 인수 패키지를 어떻게 확보할 것인지
교체는 해지로 끝나지 않고 인수로 끝납니다. 통보 전에 인수 패키지 목록을 문서로 만들어 두시고, 해지 합의서에 그 목록과 인계 기한을 명시하십시오. 최소 구성은 다음과 같습니다.
전체 소스코드와 커밋 이력
데이터베이스 스키마와 운영 데이터 백업
서버·도메인·클라우드·외부 API 계정의 명의 이전
기획서, API 명세, 배포 절차서
미완료 기능 목록과 알려진 결함 목록
인계 후 일정 기간의 질의 응답 창구
마지막 항목이 실무에서 가장 자주 빠집니다. 인계 직후에는 반드시 질문이 생기는데, 그 시점에 연락이 닿지 않으면 문서가 있어도 시간이 걸립니다.
교체할 곳을 고르는 기준
여기까지가 실무 준비입니다. 그런데 준비를 다 하고 새 업체와 계약해도 6개월 뒤에 같은 자리에 서 있는 경우가 있습니다. 회사 이름만 바뀌고 구조가 그대로였기 때문입니다.
앞에서 정리한 세 가지 — 문서화되지 않은 요구사항, 검증 불가능한 진행률, 개발사 안에만 있는 산출물 — 는 특정 회사의 문제가 아니라 발주 방식의 문제입니다. 그래서 후보를 볼 때 확인해야 하는 것은 포트폴리오의 화려함이 아니라, 이 세 가지가 누구의 책임으로 정의되어 있는지입니다. 현실적으로 선택지는 세 가지입니다.
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
개발 단가
높음
낮음
낮음
요구사항 정의 책임
개발사
발주사 본인
한국 PM
커뮤니케이션 언어
한국어
영어
한국어
발주사 담당자 투입 시간
보통
매우 많음
적음
재작업 리스크
낮음
높음
낮음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
국내 개발사는 한국어로 소통하고 요구사항 정의도 맡아 주지만 단가가 높습니다. 예산이 맞지 않으면 인력 등급이나 투입 기간을 줄이게 되고, 그 지점에서 앞의 구조가 다시 생깁니다. 방금 겪은 프로젝트가 국내 개발사였다면, 비슷한 조건으로 다시 계약하는 것은 같은 구조를 한 번 더 시도하는 선택입니다.
해외 팀에 직접 발주하는 방식은 단가가 분명히 낮습니다. 문제는 표에서 굵게 표시한 두 칸입니다. 요구사항을 정의하는 책임과 매일의 조율 부담이 발주사 본인에게 넘어옵니다. 사내에 개발 조직과 PM이 있는 회사라면 이 방식이 가장 저렴합니다. 그런데 지금 개발사 교체를 검토하는 회사는 대부분 사내에 그 역할을 할 사람이 없습니다. 없는 상태에서 영어와 시차를 끼고 팀을 관리하면, 낮은 단가로 시작해도 재작업이 쌓여 총비용은 기대만큼 내려가지 않습니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 항목별로 어떻게 벌어지는지는 IT 외주개발 비용 비교에 정리해 두었습니다.
남는 것은 세 번째 열입니다. 개발 단가는 해외 직접 발주와 같은 수준이고, 요구사항 정의와 일정 관리와 검수는 한국인 PM이 책임집니다. 발주사는 한국어로 한 사람과만 이야기합니다. 특별히 새로운 방식은 아닙니다. 국내 개발사가 담당했던 관리 역할과 해외 팀의 단가를 분리해 결합한 것이고, 프로젝트를 멈추게 한 세 가지 항목의 책임 소재를 계약 단계에서 확정해 두는 방식입니다. 디비컨설팅의 IT 아웃소싱이 이 구조로 운영됩니다.
디비컨설팅이 이관을 진행하는 방식
1. 상담 및 요구 분석
비즈니스 목표와 기술 요구사항을 한국어로 문서화하는 단계입니다. 이관 프로젝트에서는 여기에 하나가 더 붙습니다. 기존 산출물의 상태를 진단합니다. 소스코드와 데이터베이스 구조를 열어 보고, 이어받을 범위와 다시 만들어야 하는 범위를 나눠 문서로 정리합니다. 이 단계에서 확정된 문서가 이후의 재작업을 대부분 없앱니다. 견적이 이 단계 이후에 확정되는 이유도 같습니다.
2. 개발팀 구성
진단 결과에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할과 인력 등급을 확정하고 한국인 PM이 팀에 배정됩니다. 발주사는 이 PM을 통해서만 커뮤니케이션합니다. 글로벌 개발팀을 어떻게 검증하고 운영하는지는 인도 IT 아웃소싱의 진화에서 더 자세히 다뤘습니다.
3. 프로젝트 개발
애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 스프린트 단위로 동작하는 결과물이 테스트 환경에 올라가고, 발주사는 진행률 숫자가 아니라 실제 화면으로 확인합니다. 개발팀과의 일정 조율, 우선순위 정리, 이슈 처리는 PM이 맡습니다. 발주사 담당자가 조율에 하루를 쓰지 않습니다.
4. 테스트 및 배포
QA 프로세스를 거친 뒤 배포합니다. 이관 프로젝트에서는 신규 기능 테스트와 함께, 기존에 동작하던 기능이 그대로 동작하는지 확인하는 회귀 테스트가 특히 중요합니다. 배포 절차는 다른 사람이 그대로 따라 할 수 있는 형태로 문서화합니다.
5. 운영 및 유지보수
문서와 함께 인계하고 장기 지원을 이어갑니다. 소스코드, API 명세, 데이터베이스 스키마, 배포 절차서가 발주사에 남습니다. 분명히 말씀드리면, 지금의 문제는 이 단계가 없었기 때문에 생겼습니다. 첫 번째 개발사가 문서 없이 코드만 들고 있었기 때문에 교체가 어려워졌고, 그 상태가 협상에서 그대로 불리하게 작용했습니다. 인계 문서는 다음 개발사를 위한 것이 아니라, 발주사가 언제든 선택할 수 있는 상태를 유지하기 위한 것입니다.
실제 구축 사례
삼성물산 — 홈닉, 주거 플랫폼 앱
GS건설 — 엘리시안 리조트, 리조트 웹·앱 통합 구축
하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
직방 — 호갱노노, 부동산 데이터 서비스
가천대학교 — 학사관리 시스템
산업군은 교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT에 걸쳐 있습니다. 도메인이 달라도 요구사항을 한국어로 확정하고 검수 기준을 먼저 정한 뒤 진행하는 방식은 동일하게 적용됩니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.
이런 기업에 적합합니다
사내에 개발 조직이나 PM이 없어, 요구사항 정의부터 맡길 곳이 필요한 경우
진행 중인 프로젝트가 멈춰 있고, 기존 산출물 진단부터 시작해야 하는 경우
국내 개발사 견적이 예산을 넘지만 품질 기준은 낮추고 싶지 않은 경우
해외 팀 수준의 단가는 필요하지만 영어 커뮤니케이션과 시차 조율은 감당할 수 없는 경우
소스코드와 문서를 반드시 자사에 남겨야 하는 경우
이어받는 대상이 모바일 서비스라면 앱 개발 외주, 웹 서비스나 플랫폼이라면 웹 개발 외주 쪽 진행 방식을 함께 참고하시면 됩니다.
반대로, 권하지 않습니다
사내에 개발 조직과 PM이 이미 있고 단가만 낮추려는 경우 — 해외 팀에 직접 발주하시는 편이 더 저렴합니다.
남은 작업이 며칠 수준의 소규모 수정인 경우 — 팀을 구성하는 시간이 작업 시간보다 길어집니다.
요구사항을 끝까지 확정하지 않고 일단 시작하려는 경우 — 이 방식은 첫 번째 실패의 원인과 동일합니다. 저희와 하셔도 같은 결과가 나옵니다.
업체 선정 기준이 최저 단가 하나인 경우 — 그 기준에는 항상 더 낮은 곳이 있고, 지금 상황이 그 결과일 수 있습니다.
자주 묻는 질문
해외 개발팀인데 의사소통은 어떻게 됩니까?
발주사는 한국인 PM하고만 한국어로 소통합니다. 해외 개발팀과 직접 이야기하는 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임이며 회의도 한국 시간 기준으로 진행됩니다. 영어로 스펙을 다시 쓰거나 시차에 맞춰 새벽에 회의를 잡는 일은 발주사 쪽에서 발생하지 않습니다.
이관 비용은 어떻게 산정됩니까?
인력 등급별 단가와 투입 기간을 기준으로 산정하고, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 이관 프로젝트는 기존 산출물 진단 결과에 따라 이어받는 범위가 달라지므로, 진단 이후에 범위와 금액이 확정됩니다. 진단 전 금액은 개략 견적이며, 확정 시 차이가 어디에서 발생했는지도 함께 설명드립니다.
기획서가 없는데 견적이 가능합니까?
가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 일정과 예산의 범위만 있으면 개략 견적을 드릴 수 있습니다. 멈춰 있는 프로젝트라면 기존 화면과 코드가 기획서 역할을 일부 대신하기도 합니다. 기획서를 만들어 오시는 것이 아니라, 기획서를 만드는 일부터 함께하는 것이 1단계입니다.
팀 규모를 조정할 수 있습니까?
가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중에도 조정할 수 있습니다. 이관 초기에는 진단과 정리에 인력을 집중하고 이후 개발 인력을 늘리는 형태로 구성할 수 있습니다.
소스코드 소유권은 누구에게 있습니까?
발주사에 귀속됩니다. 소스코드만이 아니라 API 명세, 데이터베이스 스키마, 배포 절차 문서까지 인계 대상에 포함합니다. 이 항목을 강조하는 이유는, 지금 개발사 교체가 어려워진 원인이 대부분 여기에 있기 때문입니다. 코드와 지식이 개발사 한쪽에만 있으면 발주사는 협상에서 선택권을 잃고, 남는 선택지는 계속 끌려가는 것뿐입니다. 소유권과 인계 문서를 계약 단계에서 확정해 두면, 다음에는 교체를 검토할 일이 생겨도 그것이 위기가 아니라 그냥 선택이 됩니다.
정리
개발사 교체는 회사를 바꾸는 일이 아니라 구조를 바꾸는 일이어야 합니다. 요구사항이 문서로 남는지, 진행률을 발주사가 직접 확인할 수 있는지, 소스코드와 문서가 발주사에 귀속되는지 — 이 세 가지가 계약서에 정해져 있지 않으면 다음 개발사에서도 같은 주간 보고를 받게 됩니다. 지금 비교해야 할 것은 후보들의 포트폴리오보다 이 세 가지의 책임 소재이고, 사내에 개발 조직이 없다면 그 책임을 한국어로 대신 지는 PM 층이 구조 안에 반드시 있어야 합니다.
무료 견적
우리 프로젝트, 비용은 얼마나 들까요?
아이디어 단계여도 괜찮습니다. 해결하려는 문제와 필수 기능만 알려주시면, 한국인 PM이 검토 후 가견적과 예상 일정을 회신드리겠습니다.
관리자 페이지 개발이 빠진 견적서는 언제나 싸 보입니다. 같은 요구사항을 주고 두 업체에서 견적을 받았는데 한쪽이 눈에 띄게 저렴하다면, 총액을 비교하기 전에 항목을 한 줄씩 대조해 보시기 바랍니다. 사용자 화면은 회원가입, 로그인, 목록, 상세, 결제, 마이페이지까지 화면 단위로 촘촘하게 적혀 있는데, 운영 화면은 아예 없거나 “관리자 페이지 1식”이라는 한 줄로 끝나 있는 경우가 많습니다.
그 한 줄에 무엇이 들어가는지 물어보면 답은 대체로 비슷합니다. “기본적인 CRUD는 포함됩니다.” 그런데 실제 운영에 필요한 것은 기본적인 CRUD가 아닙니다. 누가 어떤 데이터를 볼 수 있는지, 가격과 정책을 개발자 없이 바꿀 수 있는지, 환불 요청을 누가 승인하는지, 고객이 전화로 문의했을 때 담당자가 어느 화면에서 이력을 확인하는지가 필요합니다. 이 항목들은 “1식” 안에 들어 있지 않습니다.
그래서 같은 문장이 오픈 직전에 반복됩니다. “이건 어디서 바꾸나요?” 이 시점에 추가되는 관리자 기능은 이미 확정된 데이터 구조와 권한 설계 위에 얹어야 하므로, 처음부터 반영했을 때보다 비쌉니다. 관리자 기능이 뒤늦게 붙으면서 초기 견적을 넘기는 일은 드물지 않습니다. 이건 개발사가 부정직해서 생기는 문제가 아닙니다. 정의하지 않은 것을 견적에 담을 방법이 없기 때문에 생기는 문제입니다.
디비컨설팅은 100건 이상의 프로젝트를 수행하면서, 관리자 화면이 사실상 제품의 본체인 시스템을 여러 번 만들어 왔습니다. 삼성물산 홈닉 주거 플랫폼, GS건설 엘리시안 리조트 웹·앱, LS일렉트릭 테크스퀘어 산업 B2B 거래 플랫폼, 가천대학교 학사관리 시스템, 센터필드·센트로폴리스 프라임 오피스 빌딩 관리 시스템이 그렇습니다. 이런 시스템은 사용자 화면보다 운영 화면에서 승부가 납니다. 아래 내용은 그 관점에서 정리한 것입니다.
왜 관리자 페이지는 항상 견적에서 빠지는가
발주사는 사용자 화면만 상상한다
기획 회의에서 그려지는 화면은 거의 예외 없이 고객이 보는 화면입니다. 서비스를 처음 구상할 때 우리는 사용자 입장에서 앱을 켜고, 상품을 고르고, 결제하는 장면을 떠올립니다. 반면 운영자가 매일 아침 무엇을 확인하고 무엇을 눌러야 하는지는 상상 대상이 아닙니다.
사용자 화면은 겪어 보지 않아도 그릴 수 있지만, 관리자 화면은 실제로 운영해 본 사람만 정의할 수 있습니다. 그리고 신규 서비스에는 아직 운영해 본 사람이 없습니다. 백오피스가 견적에서 빠지는 첫 번째 이유가 여기 있습니다.
개발사는 “관리자 페이지 1식”으로 방어한다
개발사도 이 항목이 위험하다는 것을 압니다. 그런데 발주사가 운영 시나리오를 주지 않았으므로 공수를 산정할 근거가 없습니다. 이때 개발사가 택할 수 있는 방법은 두 가지입니다. 넉넉하게 잡아서 견적을 올리거나, 최소한으로 잡고 나중에 협의하거나.
경쟁 견적 상황에서는 후자가 이깁니다. 그래서 “관리자 페이지 1식”은 게으름의 결과가 아니라 방어의 결과입니다. 범위가 정의되지 않은 항목을 크게 잡으면 수주에서 밀리기 때문에, 최소한으로 잡아 두고 착수 후에 다시 이야기하는 구조가 만들어집니다. 발주사는 싼 견적을 골랐다고 생각하지만, 실제로는 정의되지 않은 범위를 나중에 협상하기로 하고 계약한 것입니다. 같은 요구사항인데 견적이 크게 갈리는 다른 이유는 홈페이지 제작 비용, 왜 업체마다 열 배씩 다른가에서 따로 정리했습니다.
운영 시나리오는 오픈 직전에야 드러난다
관리자 기능의 필요성은 개발 중에 발견되지 않습니다. 운영을 실제로 시작하는 순간 발견됩니다. 배너를 교체해야 하고, 특정 회원의 등급을 수동으로 바꿔야 하고, 잘못 올라간 상품을 내려야 하고, 어제 결제 취소가 몇 건인지 세어야 합니다.
이 요청들이 한꺼번에 쏟아지는 시점은 대체로 오픈 2주 전입니다. 개발 일정은 이미 끝나 가고, 데이터 구조와 권한 체계는 확정되어 있습니다. 이 상태에서 관리자 기능을 추가하면 화면 하나를 새로 그리는 일이 아니라 설계를 건드리는 일이 됩니다. 비용과 일정이 함께 움직이는 이유입니다.
발주 전에 정의해야 할 6가지
아래 여섯 가지는 기획서가 없어도, 회의 한 번이면 대부분 답할 수 있는 질문입니다. 발주 전에 이 정도만 정리해 두면 견적서의 “1식”은 대부분 화면 단위로 쪼개집니다. 요구사항 문서를 어느 수준까지 준비해야 하는지는 요구사항 정의서, 어디까지 써야 할까에서 별도로 다뤘습니다.
1. 누가 쓰는가 — 권한 등급
관리자 페이지를 사용할 사람의 역할을 나열하고, 각 역할이 볼 수 있는 데이터와 할 수 있는 행위를 구분해야 합니다. 운영자, 고객 응대 담당자, 정산 담당자, 외부 협력사, 시스템 관리자는 각각 다른 화면을 봐야 합니다. 정의하지 않으면 모든 계정이 전체 권한을 갖게 됩니다. 아르바이트 인력이 전 회원의 개인정보와 매출 데이터를 열람할 수 있는 상태로 오픈하게 되고, 이걸 나중에 나누는 작업은 화면 수정이 아니라 재설계입니다.
2. 무엇을 직접 바꿔야 하는가 — 콘텐츠·가격·정책의 수정 범위
배너, 공지, 약관, 상품 가격, 할인율, 배송비 기준, 알림 문구 중에서 개발자 없이 바꿔야 하는 항목을 지정해야 합니다. 기준은 하나입니다. 한 달에 한 번 이상 바뀌는가. 정의하지 않으면 그 값들은 코드나 DB에 고정되고, 문구 한 줄을 바꾸는 데도 유지보수 요청과 배포가 필요해집니다. 운영 속도가 개발사 일정에 묶이는 상태가 여기서 시작됩니다.
3. 무엇을 봐야 하는가 — 통계와 리포트의 실제 사용 목적
“통계 화면 필요합니다”는 요구사항이 아닙니다. 그 숫자를 누가, 얼마나 자주, 무엇을 결정하기 위해 보는지가 요구사항입니다. 주간 회의에 올릴 매출 추이인지, 마케팅 채널별 유입 대비 가입 전환인지, 정산을 위한 기간별 거래 내역인지에 따라 필요한 집계 구조가 전혀 다릅니다. 목적 없이 만든 대시보드는 오픈 후 아무도 보지 않고, 정작 필요한 숫자는 매번 개발팀에 쿼리를 요청해서 받게 됩니다.
4. 무엇을 승인해야 하는가 — 결재·검수·상태 변경 흐름
환불, 입점 승인, 게시물 검수, 정산 확정처럼 담당자가 판단해서 상태를 바꾸는 흐름을 정리해야 합니다. 누가 요청하고, 누가 승인하고, 반려되면 어디로 돌아가고, 그 기록이 어디에 남는지까지가 한 세트입니다. 이 흐름은 화면 하나가 아니라 상태 값과 이력 테이블 설계에 직접 영향을 줍니다. 나중에 추가하면 이미 쌓인 데이터를 마이그레이션해야 하므로 비용이 가장 크게 뛰는 항목 중 하나입니다.
5. 문제가 생기면 어디서 확인하는가 — 로그, 이력, 고객 문의 대응
고객이 “결제했는데 처리가 안 됐다”고 전화했을 때, 담당자가 어느 화면에서 무엇을 보고 답할 수 있어야 하는지를 정해야 합니다. 주문 상태 변경 이력, 관리자 조작 로그, 결제 대사 내역, 발송된 알림 기록이 여기에 해당합니다. 이 화면이 없으면 모든 고객 문의가 개발팀 확인 요청으로 넘어갑니다. 운영 인력이 아니라 개발 인력이 고객 응대에 묶이는 구조가 됩니다.
6. 밖으로 내보내야 하는가 — 엑셀 다운로드, 기존 시스템 연동
데이터를 시스템 밖으로 꺼내야 하는지, 꺼낸다면 어떤 형태인지 확인해야 합니다. 실무에서는 엑셀 다운로드가 거의 항상 필요하고, 그다음이 기존 ERP·회계·CRM과의 연동입니다. 연동은 상대 시스템의 규격에 맞춰야 하므로, 우리 쪽 설계만으로 끝나지 않습니다. 발주 시점에 언급되지 않으면 이 작업은 통째로 견적 밖에 있습니다.
여섯 가지 중에서 견적을 가장 크게 흔드는 항목은 3번, 4번, 6번입니다. 통계는 집계 구조를, 승인 흐름은 상태 설계와 이력을, 외부 연동은 상대 시스템 규격을 건드리기 때문입니다. 나머지 항목이 화면을 늘리는 일이라면, 이 세 가지는 구조를 바꾸는 일입니다.
세 가지 발주 방식의 차이
국내 개발사
해외 직접 발주
한국 PM + 글로벌 개발팀
개발 단가
높음
낮음
낮음
요구사항 정의 책임
개발사
발주사 본인
한국 PM
커뮤니케이션 언어
한국어
영어
한국어
발주사 담당자 투입 시간
보통
매우 많음
적음
재작업 리스크
낮음
높음
낮음
총비용 관점
비쌈
기대만큼 안 싸다
실질 절감
세 방식의 진짜 차이는 개발 단가가 아니라 요구사항을 정의하는 책임이 어디에 있는가입니다. 국내 개발사에 맡기면 정의 작업의 상당 부분을 개발사가 대신하지만, 그 인건비가 단가에 포함되어 있습니다. 해외에 직접 발주하면 단가는 확실히 내려가는 대신, 정의 책임 전체가 발주사 담당자에게 넘어옵니다.
이 차이가 가장 선명하게 드러나는 지점이 관리자 페이지입니다. 사용자 화면은 참고할 서비스가 많아서 영어로 설명하기가 비교적 수월합니다. 반면 백오피스는 우리 회사의 업무 방식 그 자체입니다. 정산 담당자와 운영자의 권한이 어떻게 다른지, 환불 승인 절차가 어떤 단계를 거치는지, 세금계산서 발행 시점이 언제인지를 영어 문서로 옮겨서 시차를 두고 합의해야 합니다. 이 과정이 한 번에 끝나는 경우는 거의 없고, 오해가 발견되는 시점은 대체로 산출물을 받은 뒤입니다.
결론은 단순합니다. 사내에 운영 시나리오를 정의하고 문서로 만들 사람이 없다면, 해외 개발팀을 직접 관리하는 방식은 관리자 페이지에서 반드시 무너집니다. 절감한 단가는 재작업과 담당자의 시간으로 되돌아 나갑니다. 디비컨설팅의 IT 아웃소싱 구조는 이 지점을 겨냥합니다. 개발은 검증된 글로벌 팀이 맡아 국내 채용 대비 평균 40~60%의 비용을 절감하되, 요구사항을 한국어로 정의하고 결과에 책임지는 역할은 한국인 PM이 프로젝트 안에서 수행합니다.
디비컨설팅은 이 부분을 어떻게 통제합니까
아래는 디비컨설팅이 웹 개발 외주 프로젝트를 진행하는 5단계이며, 각 단계에서 관리자 페이지가 어떻게 다뤄지는지 함께 정리했습니다.
1. 상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 이 단계에서 사용자 화면보다 운영 시나리오를 먼저 뽑아냅니다. 앞의 여섯 가지 질문을 그대로 물어 권한 등급표와 상태 변경 흐름을 먼저 확정하고, 그 결과를 견적서에 화면 단위로 반영합니다. “관리자 페이지 1식”이라는 항목이 남지 않도록 하는 작업이 여기서 끝납니다.
2. 개발팀 구성 — 프로젝트 성격에 맞는 전담팀을 2~4주 내에 구성합니다. 관리자 화면의 비중이 큰 프로젝트, 예를 들어 권한 체계가 복잡하거나 기존 시스템과 연동해야 하는 경우에는 백엔드와 데이터 설계 인력의 비중을 그에 맞춰 잡습니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 관리자 화면은 사용자 화면과 함께 스프린트에 배치해서, 오픈 직전에 몰리지 않게 합니다. 발주사 담당자는 개발팀과 시차를 두고 조율하는 데 하루를 쓰지 않습니다. 확인해야 할 사항은 한국인 PM이 정리해서 전달합니다.
4. 테스트 및 배포 — QA를 거쳐 릴리즈합니다. 테스트 범위에 관리자 계정별 권한 검증을 포함합니다. 각 등급이 볼 수 없어야 할 데이터를 실제로 볼 수 없는지, 승인 흐름이 반려와 재요청까지 정상 동작하는지를 확인합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원을 제공합니다. 관리자 페이지 사용 방법, 권한 부여 절차, 데이터 내보내기 방법을 포함한 운영 문서를 함께 넘깁니다. 담당자가 바뀌어도 인수인계가 가능한 상태로 남기는 것이 목적입니다.
이런 기업에 적합합니다
운영자가 매일 사용하는 백오피스가 서비스의 핵심인 경우 — 커머스, 예약, 정산, 회원 관리, 시설·자산 관리 시스템
사내에 IT 담당자는 있지만 요구사항 정의와 일정 관리를 전담할 PM이 없는 경우
국내 견적이 예산을 넘어서지만, 요구사항을 영어로 직접 관리할 여력은 없는 경우
기존 ERP·회계·CRM과 연동해야 해서 규격 협의와 검수 책임을 맡길 창구가 필요한 경우
반대로 권하지 않습니다
관리자 화면이 사실상 필요 없는 단순 소개형 홈페이지 — 워드프레스나 국내 빌더가 더 빠르고 저렴합니다. 두 가지를 어떻게 구분하는지는 웹 플랫폼 개발과 홈페이지 제작의 차이를 참고하시기 바랍니다
사내에 운영 기획자와 PM이 모두 있어 요구사항 정의부터 검수까지 직접 감당할 수 있는 조직 — 해외 개발팀에 직접 발주하는 편이 비용상 유리합니다
기존 SaaS의 어드민 기능으로 충분히 해결되는 경우 — 커머스 솔루션이나 예약 SaaS로 커버되는 범위라면 신규 개발이 필요하지 않습니다
써도 됩니다. 데이터 조회와 기본 등록·수정 수준이라면 오픈소스 어드민 프레임워크로 개발 기간을 줄일 수 있고, 실제로 그렇게 구성하는 경우도 있습니다. 다만 권한 등급이 여러 단계로 나뉘거나 승인·반려 같은 상태 흐름이 들어가면 기성 도구를 커스터마이징하는 비용이 직접 만드는 비용을 넘어서는 구간이 옵니다. 판단 기준은 도구 자체가 아니라 앞서 정리한 여섯 가지 항목의 복잡도입니다. 상담 단계에서 이 부분을 먼저 검토하고 방식을 정합니다.
해외 개발팀인데 의사소통은 어떻게 하나요?
발주사는 한국인 PM하고만 한국어로 소통합니다. 개발팀과 직접 영어로 회의하실 필요가 없습니다. 요구사항 정의, 일정 관리, 산출물 검수는 PM의 책임입니다. 개발팀에 전달할 명세를 작성하고, 결과물이 요구사항과 맞는지 확인한 뒤 발주사에 보고하는 것까지가 PM의 업무 범위입니다. 관리자 페이지처럼 국내 업무 관행이 그대로 반영되어야 하는 영역일수록 이 구조의 차이가 크게 나타납니다.
기획서가 없는데 견적을 받을 수 있나요?
가능합니다. 완성된 기획서나 화면 설계서가 없어도 개략 견적을 드릴 수 있습니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 희망 일정과 예산 범위 정도만 있으면 됩니다. 상담 과정에서 운영 시나리오와 권한 구조를 함께 정리하며 범위를 구체화하고, 그 결과를 반영해 정식 견적을 작성합니다. 기획서를 먼저 만들어야 문의할 수 있는 것은 아닙니다.
오픈 후에 관리자 기능을 추가할 수 있나요? 팀 규모 조정이 가능한가요?
둘 다 가능합니다. 오픈 이후 운영하면서 필요해지는 관리자 기능은 유지보수 또는 추가 개발로 진행합니다. 초기 단계에서 권한 구조와 데이터 설계를 잡아 두기 때문에, 나중에 화면을 추가하기 쉬운 상태로 남습니다. 계약 형태는 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에 팀 규모를 늘리거나 줄이는 조정도 가능합니다.
소스코드는 누가 소유하나요?
소스코드는 발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이후 다른 개발사에 유지보수를 맡기거나 사내 개발팀이 이어받는 것도 가능합니다. 특정 업체에 묶여서 시스템을 계속 맡길 수밖에 없는 상황을 만들지 않는 것이 인계의 기준입니다. 계약서에서 이 조항을 어떻게 확인해야 하는지는 개발 외주 계약서, 서명 전에 반드시 확인할 7가지 조항에 정리해 두었습니다.
정리
관리자 페이지 개발이 견적에서 빠지는 것은 가격의 문제가 아니라 정의의 문제입니다. 누가 쓰고, 무엇을 바꾸고, 무엇을 승인하고, 어디서 확인하는지를 발주 전에 문서로 만들어 두면 견적은 비교 가능한 형태가 되고, 만들지 않으면 그 비용은 오픈 직전에 청구됩니다. 그리고 이 정의는 개발 단가를 깎아서 해결되는 영역이 아닙니다. 운영 시나리오를 한국어로 묻고 정리하고 검수까지 책임지는 한국인 PM이 프로젝트 안에 있는지가 결과를 가릅니다.
무료 견적
우리 프로젝트, 비용은 얼마나 들까요?
아이디어 단계여도 괜찮습니다. 해결하려는 문제와 필수 기능만 알려주시면, 한국인 PM이 검토 후 가견적과 예상 일정을 회신드리겠습니다.
