[카테고리:] Web

사내 시스템 구축을 검토하는 회사는 대부분 같은 장면에서 출발합니다. 부서마다 엑셀 파일이 따로 돌고, 같은 숫자를 두 번 세 번 옮겨 적고, 월말이 되면 누군가 남아서 취합합니다. 담당자가 바뀌면 그 파일이 어디 있는지부터 다시 찾아야 합니다. 그래서 시스템을 만들기로 합니다. 예산을 잡고, 개발사를 정하고, 몇 달 뒤에 오픈합니다.

그리고 반년쯤 지나면, 현업 담당자 모니터에 다시 엑셀 파일이 열려 있습니다. 시스템은 살아 있지만 실제 업무는 그 바깥에서 돌아갑니다. 결재만 시스템에 남기고, 진짜 일은 여전히 메신저와 전화로 처리합니다.

이 결과는 개발이 부실해서 생기는 일이 아닙니다. 화면은 다 있고 버튼도 다 눌립니다. 문제는 만들어진 시스템이 실제 업무와 다르게 생겼다는 것입니다. 그리고 그 차이는 개발이 아니라 발주 단계에서 결정됩니다.

디비컨설팅은 100건 이상의 프로젝트를 수행하면서, 대외 서비스보다 오히려 조직 내부에서 쓰는 시스템을 반복적으로 구축해 왔습니다. 가천대학교의 학사관리 시스템, 센터필드·센트로폴리스·그랑서울 등 프라임 오피스 빌딩의 관리 시스템, LS일렉트릭 테크스퀘어의 산업 B2B 거래 플랫폼이 그런 사례입니다. 이 글은 그 과정에서 반복해서 확인한 실패 지점과, 발주 전에 정리하면 대부분 예방되는 여섯 가지를 정리한 것입니다.

사내 시스템이 대외 서비스보다 실패하기 쉬운 이유

같은 규모, 같은 예산이라도 사내 시스템은 고객용 서비스보다 실패 확률이 높습니다. 기술 난도가 높아서가 아닙니다. 요구사항이 존재하는 방식이 다르기 때문입니다.

요구사항이 문서가 아니라 사람 머릿속에 있습니다

고객용 서비스는 기획서가 곧 정답입니다. 아직 없는 것을 만드는 일이니까요. 반면 사내 시스템은 이미 몇 년째 돌아가고 있는 업무를 옮기는 일입니다. 그 업무의 규칙은 문서가 아니라 오래 그 일을 해 온 담당자의 경험 안에 있습니다.

“이 거래처는 세금계산서를 월말에 한 번에 끊습니다”, “이 품목은 재고가 마이너스로 잡혀도 출고를 막으면 안 됩니다” 같은 규칙은 어느 문서에도 적혀 있지 않습니다. 물어보지 않으면 나오지 않고, 물어봐도 담당자는 그게 특별한 규칙이라고 인식하지 못합니다. 너무 당연해서 말할 생각을 못 하는 것입니다. 이런 규칙은 보통 오픈 직후, 시스템이 정상 처리를 거부할 때 처음 드러납니다.

발주 담당자와 실제 사용자가 다릅니다

대외 서비스는 발주하는 쪽과 성과를 보는 쪽이 대체로 같습니다. 사내 시스템은 다릅니다. 예산과 일정을 관리하는 사람은 경영지원이나 전산 담당이고, 매일 그 화면을 쓰는 사람은 영업·물류·회계 현업입니다.

그래서 검수는 통과하는데 현장에서는 쓰이지 않는 상황이 만들어집니다. 발주 담당자는 “요청한 기능이 다 있는지”를 확인하고, 현업은 “이걸로 오늘 일을 끝낼 수 있는지”를 봅니다. 기준이 다르면 결과도 다릅니다. 무엇을 완료로 볼 것인지의 문제는 개발 검수 기준에서 따로 다뤘습니다.

예외 처리가 업무의 절반을 차지합니다

정상 흐름만 놓고 보면 사내 시스템은 단순합니다. 등록하고, 승인하고, 처리하고, 마감합니다. 실제 업무 시간의 상당 부분은 그 바깥에서 소비됩니다. 승인자가 휴가일 때, 이미 마감한 달의 숫자를 고쳐야 할 때, 계약서와 실제 단가가 다를 때 어떻게 할 것인가.

견적서에는 보통 정상 흐름만 적힙니다. 예외 처리는 “협의”라는 두 글자로 넘어갑니다. 그리고 개발이 끝날 무렵 그 협의가 시작되면, 이미 만들어진 구조를 뜯어야 하는 상황이 됩니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 견적서에서 반복적으로 빠지는 항목은 관리자 페이지 개발 글에서도 같은 패턴으로 확인됩니다.

발주 전에 정리할 6가지

아래 여섯 가지는 개발사가 대신 정해 줄 수 없는 항목입니다. 발주사 안에서만 답이 나오고, 답이 없으면 개발 중에 반드시 재작업으로 돌아옵니다.

1. 이 시스템을 매일 여는 사람이 누구인가

부서 이름이 아니라 역할 단위로 적습니다. 하루에 열 번 쓰는 사람과 월말에 한 번 쓰는 사람은 필요한 화면이 다릅니다. 실사용자 서너 명의 이름을 적을 수 없다면, 아직 발주할 준비가 되지 않은 것입니다.

2. 지금 그 업무가 실제로 어떻게 돌아가는가

이상적인 모습이 아니라 현재 모습을 기록합니다. 지금 쓰는 엑셀 서식, 메신저로 오가는 확인 절차, 종이로 남기는 대장까지 포함합니다. 현행 업무를 적어 두지 않으면 개발사는 교과서적인 흐름을 가정하고, 그 가정은 거의 항상 틀립니다. 문서를 어느 수준까지 써야 하는지는 요구사항 정의서에 정리해 두었습니다.

3. 예외 처리를 어디까지 시스템이 감당할 것인가

모든 예외를 시스템에 넣으면 비용이 몇 배가 되고, 아무것도 넣지 않으면 현업이 다시 엑셀을 엽니다. 자주 일어나는 예외는 시스템에 넣고, 드문 예외는 관리자가 수동으로 처리할 수 있는 통로만 열어 두는 식으로 선을 그어야 합니다. 이 선을 발주 전에 긋는 것과 개발 중에 긋는 것은 비용이 전혀 다릅니다. 무엇을 1차에서 빼도 되는지는 MVP 개발 범위 기준을 참고하실 수 있습니다.

4. 기존 데이터를 어떻게 옮길 것인가

사내 시스템에는 항상 과거 데이터가 있습니다. 몇 년치 엑셀, 예전 시스템의 데이터베이스, 부서별로 다르게 적어 온 거래처명이 섞여 있습니다. 어디까지 옮길지, 형식이 안 맞는 값은 누가 정리할지, 정리 작업을 발주사가 할지 개발사가 할지를 먼저 정해야 합니다. 데이터 이관은 견적에서 가장 자주 누락되면서 실제로는 가장 오래 걸리는 작업 중 하나입니다.

5. 기존 시스템·외부 서비스와 무엇을 연동할 것인가

회계 프로그램, 그룹웨어, 사내 인증, 문자·알림톡, 세금계산서 발행처럼 이미 쓰고 있는 것들과 어디서 만날지 정해야 합니다. 연동 대상마다 문서가 있는지, 담당 벤더에게 협조를 받을 수 있는지도 함께 확인해야 합니다. 상대 쪽 문서가 없거나 담당자가 응답하지 않으면, 그 연동은 기술 문제가 아니라 일정 문제가 됩니다.

6. 오픈 이후 누가 바꿔 주는가

사내 시스템은 오픈이 끝이 아니라 시작입니다. 조직이 바뀌면 결재선이 바뀌고, 제도가 바뀌면 항목이 바뀝니다. 이 변경을 누가, 어느 속도로 처리할지 정해 두지 않으면 시스템은 6개월 만에 현실과 어긋나고, 그 시점에 현업은 엑셀로 돌아갑니다. 출시 이후의 대응 책임을 어떻게 정의하는지는 서버 운영·유지보수에서 자세히 다뤘습니다.

세 가지 발주 방식, 무엇이 실제로 다른가

사내 시스템을 맡길 때 선택지는 보통 세 가지입니다. 단가만 비교하면 판단을 그르치기 쉽습니다. 사내 시스템에서 진짜 변수는 현업의 업무 규칙을 누가 캐낼 것인가이기 때문입니다.

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

표에서 사내 시스템에만 해당하는 줄은 맨 윗줄입니다. 대외 서비스라면 기획서를 영어로 번역해 해외 팀에 넘기는 방식이 성립합니다. 그러나 사내 시스템의 요구사항은 번역할 원본 자체가 없습니다. 경리 담당자에게 마감 절차를 묻고, 창고 담당자에게 재고가 안 맞을 때 어떻게 하는지 물어야 나옵니다. 이 인터뷰는 한국어로, 그 조직의 맥락을 아는 사람이 해야 합니다.

그래서 사내 시스템에서 해외 직접 발주는 단가가 싸도 위험한 선택이 됩니다. 개발 실력의 문제가 아니라, 요구사항을 캐내는 일이 발주사 담당자에게 통째로 넘어오기 때문입니다. 사내에 그 일을 전담할 사람이 없다면 그 방식은 성립하지 않습니다. 왜 외주가 납기 후 분쟁으로 끝나는지는 IT 외주 구조에서 더 자세히 정리했습니다.

디비컨설팅이 이 문제를 다루는 방식

IT 아웃소싱 구조에서 한국인 PM은 통역이 아니라 요구사항의 책임자입니다. 진행은 다섯 단계로 나뉩니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 사내 시스템에서는 이 단계에 현업 인터뷰가 포함됩니다. 뒤에 생기는 재작업 대부분이 이 단계에서 제거됩니다.
2. 개발팀 구성 — 프로젝트 성격에 맞춰 2~4주 안에 전담팀을 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 고객사 담당자가 하루를 조율에 쓰지 않아도 되는 구조입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 배포합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원합니다.

사내 시스템에서 특히 중요한 것은 1단계와 5단계입니다. 1단계에서 현업의 규칙을 꺼내지 못하면 완성도와 무관하게 안 쓰이는 시스템이 되고, 5단계에서 문서 없이 인계받으면 조직이 바뀔 때마다 손을 댈 수 없게 됩니다.

실제 구축 사례

디비컨설팅이 수행한 프로젝트 가운데 내부 운영 시스템 성격이 강한 사례입니다.

• 가천대학교 — 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처(글펍) 커뮤니티 서비스
• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 웹·앱 통합 구축

교육, 금융·핀테크, 제조·물류, 이커머스, 스마트빌딩·IoT 등에서 구축 경험을 보유하고 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 부서별로 엑셀이 흩어져 있고, 같은 데이터를 여러 번 입력하고 있는 기업
• 업무 규칙이 담당자 경험에 의존하고 있어 인수인계마다 혼선이 생기는 조직
• 사내에 개발 인력이 없거나, 있어도 기존 시스템 운영만으로 여력이 없는 기업
• 기존 시스템이 현재 업무와 어긋나 있어 개편 여부를 판단해야 하는 기업
• 국내 개발사 견적이 예산을 넘지만 품질과 한국어 커뮤니케이션은 포기할 수 없는 기업

반대로, 이런 경우에는 권하지 않습니다

• 현업 담당자가 인터뷰에 응할 시간이 전혀 없는 경우. 사내 시스템은 발주사의 시간이 최소한은 필요합니다. 그 시간을 낼 수 없다면 어느 개발사가 맡아도 결과는 같습니다.
• 표준 패키지로 충분한 업무인 경우. 일반적인 회계나 급여처럼 시장 솔루션이 성숙한 영역은 구독형 제품이 더 저렴하고 안전합니다.
• 무엇을 개선할지 아직 정하지 못한 경우. “시스템이 있으면 나아질 것 같다”는 단계라면 개발보다 업무 정리가 먼저입니다.
• 이번 달 안에 오픈해야 하는 경우. 데이터 이관과 연동이 있는 사내 시스템은 그 일정에 맞추기 어렵습니다.

자주 묻는 질문

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

발주사는 한국인 PM하고만 한국어로 소통합니다. 현업 인터뷰, 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과 직접 영어로 대화하실 일은 없습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 사내 시스템이라면 현재 쓰고 계신 엑셀 서식을 보여 주시는 것이 기획서보다 정확할 때가 많습니다.

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

등급별 단가에 투입 기간을 곱하는 방식이며, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 사내 시스템은 데이터 이관과 연동 범위에 따라 편차가 크므로 이 두 항목을 별도로 확인하시기 바랍니다. 국내 채용 대비 평균 40~60% 절감이 일반적인 범위입니다.

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

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 사내 시스템은 오픈 이후 변경 요청이 이어지는 특성이 있어, 축소된 형태로 유지 인력을 남기는 방식을 많이 선택하십니다.

소스코드는 누구 소유인가요?

발주사 귀속입니다. API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 사내 시스템에서는 이 조건이 특히 중요합니다. 코드와 문서를 확보하지 못하면 이후 어떤 작은 수정도 원 개발사를 거쳐야 하고, 그 의존이 몇 년간 이어지기 때문입니다.

정리

사내 시스템 구축의 성패는 개발 실력보다 요구사항을 캐내는 능력에서 갈립니다. 그 요구사항은 문서가 아니라 현업 담당자의 경험 안에 있고, 한국어로 묻고 조직의 맥락을 이해해야 나옵니다. 실사용자, 현행 업무, 예외 처리 범위, 데이터 이관, 연동 대상, 오픈 이후 변경 주체 — 이 여섯 가지를 발주 전에 정리해 두시면 대부분의 재작업은 발생하지 않습니다. 그리고 이 질문들을 대신 물어 줄 사람이 사내에 없다면, 그 역할을 맡는 한국인 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로 커버되는 범위라면 신규 개발이 필요하지 않습니다
• 요구사항이 2주 단위로 바뀌는 초기 검증 단계 — 이 구간은 최소 기능만 빠르게 만들어 검증한 뒤 발주하는 편이 낫습니다

자주 묻는 질문

관리자 페이지도 처음부터 만들어야 하나요? 오픈소스 어드민을 쓰면 안 되나요?

써도 됩니다. 데이터 조회와 기본 등록·수정 수준이라면 오픈소스 어드민 프레임워크로 개발 기간을 줄일 수 있고, 실제로 그렇게 구성하는 경우도 있습니다. 다만 권한 등급이 여러 단계로 나뉘거나 승인·반려 같은 상태 흐름이 들어가면 기성 도구를 커스터마이징하는 비용이 직접 만드는 비용을 넘어서는 구간이 옵니다. 판단 기준은 도구 자체가 아니라 앞서 정리한 여섯 가지 항목의 복잡도입니다. 상담 단계에서 이 부분을 먼저 검토하고 방식을 정합니다.

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

발주사는 한국인 PM하고만 한국어로 소통합니다. 개발팀과 직접 영어로 회의하실 필요가 없습니다. 요구사항 정의, 일정 관리, 산출물 검수는 PM의 책임입니다. 개발팀에 전달할 명세를 작성하고, 결과물이 요구사항과 맞는지 확인한 뒤 발주사에 보고하는 것까지가 PM의 업무 범위입니다. 관리자 페이지처럼 국내 업무 관행이 그대로 반영되어야 하는 영역일수록 이 구조의 차이가 크게 나타납니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 완성된 기획서나 화면 설계서가 없어도 개략 견적을 드릴 수 있습니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 희망 일정과 예산 범위 정도만 있으면 됩니다. 상담 과정에서 운영 시나리오와 권한 구조를 함께 정리하며 범위를 구체화하고, 그 결과를 반영해 정식 견적을 작성합니다. 기획서를 먼저 만들어야 문의할 수 있는 것은 아닙니다.

오픈 후에 관리자 기능을 추가할 수 있나요? 팀 규모 조정이 가능한가요?

둘 다 가능합니다. 오픈 이후 운영하면서 필요해지는 관리자 기능은 유지보수 또는 추가 개발로 진행합니다. 초기 단계에서 권한 구조와 데이터 설계를 잡아 두기 때문에, 나중에 화면을 추가하기 쉬운 상태로 남습니다. 계약 형태는 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에 팀 규모를 늘리거나 줄이는 조정도 가능합니다.

소스코드는 누가 소유하나요?

소스코드는 발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이후 다른 개발사에 유지보수를 맡기거나 사내 개발팀이 이어받는 것도 가능합니다. 특정 업체에 묶여서 시스템을 계속 맡길 수밖에 없는 상황을 만들지 않는 것이 인계의 기준입니다. 계약서에서 이 조항을 어떻게 확인해야 하는지는 개발 외주 계약서, 서명 전에 반드시 확인할 7가지 조항에 정리해 두었습니다.

정리

관리자 페이지 개발이 견적에서 빠지는 것은 가격의 문제가 아니라 정의의 문제입니다. 누가 쓰고, 무엇을 바꾸고, 무엇을 승인하고, 어디서 확인하는지를 발주 전에 문서로 만들어 두면 견적은 비교 가능한 형태가 되고, 만들지 않으면 그 비용은 오픈 직전에 청구됩니다. 그리고 이 정의는 개발 단가를 깎아서 해결되는 영역이 아닙니다. 운영 시나리오를 한국어로 묻고 정리하고 검수까지 책임지는 한국인 PM이 프로젝트 안에 있는지가 결과를 가릅니다.

웹 플랫폼 개발을 문의한 회사가 견적서를 받고 가장 자주 하는 말은 이것입니다. “우리는 홈페이지 하나 만들려는 건데, 왜 이 금액이 나오나요?” 반대 방향의 사고도 똑같이 자주 일어납니다. 홈페이지 견적을 기준으로 예산을 확정했는데, 개발이 시작되고 두 달쯤 지나 회원 등급, 정산, 관리자 권한, 알림 이야기가 순서대로 올라오면서 일정과 비용이 동시에 무너집니다.

두 상황의 원인은 하나입니다. 발주서에 적힌 ‘홈페이지 제작’이라는 한 단어가, 실제로 만들어야 하는 것과 다른 대상을 가리키고 있었던 것입니다. 이 글은 홈페이지와 웹 플랫폼을 가르는 기준이 무엇이고, 그 구분을 개발이 시작되기 전에 어떻게 확정하는지를 다룹니다.

디비컨설팅은 100건이 넘는 웹·앱·플랫폼 구축을 수행했고, 50개 이상의 글로벌 파트너사와 함께 개발팀을 운영합니다. 삼성물산 주거 플랫폼 ‘홈닉’, GS건설 엘리시안 리조트 웹·앱 통합 구축, 직방 ‘호갱노노’ 부동산 데이터 서비스, LS일렉트릭 ‘테크스퀘어’ 산업 B2B 거래 플랫폼, 가천대학교 학사관리 시스템이 모두 여기에 포함됩니다. 아래에 정리한 구분 기준은 이 프로젝트들에서 반복적으로 확인된 것입니다.

같은 ‘웹’인데 견적이 갈리는 이유

화면 수는 비용을 설명하지 못합니다

발주 담당자가 견적을 요청할 때 가장 먼저 세는 것은 화면 수입니다. “메인, 소개, 서비스, 문의, 이렇게 열 개 정도요.” 그런데 개발 공수는 화면 수와 비례하지 않습니다. 열 개의 화면이 모두 정해진 내용을 보여주기만 하는 페이지라면 작업량은 예측 가능합니다. 반면 그 중 한 화면이 ‘로그인한 사용자가 자기 신청 내역을 보고, 상태에 따라 취소하거나 수정할 수 있는’ 화면이라면, 화면 하나 뒤에 회원 체계·상태 관리·권한 검증·이력 기록이 함께 붙습니다.

같은 화면 수에서 견적이 크게 벌어지는 것은 개발사가 부풀렸기 때문이 아니라, 화면 뒤에 무엇이 붙는지를 서로 다르게 읽었기 때문입니다. 견적 금액 자체가 어떤 항목으로 구성되는지는 홈페이지 제작 비용 구조를 정리한 글에서 별도로 다뤘습니다.

진짜 기준은 ‘누가 무엇을 바꿀 수 있는가’입니다

홈페이지는 회사가 정보를 내보내는 창구입니다. 내용을 바꾸는 사람은 관리자 한 명이고, 방문자는 읽습니다. 웹 플랫폼은 다릅니다. 여러 종류의 사용자가 각자 데이터를 만들고 바꾸며, 그 변경이 다른 사용자에게 영향을 줍니다. 임차인이 신청하면 관리사무소 담당자의 목록이 바뀌고, 판매자가 재고를 수정하면 구매자의 화면이 바뀝니다.

이 차이가 개발에서 갈라지는 지점은 ‘데이터를 신뢰할 수 있게 만드는 비용’입니다. 읽기만 하는 사이트는 잘못된 값이 들어올 경로가 거의 없습니다. 여러 사용자가 동시에 쓰는 시스템은 권한, 중복 처리, 동시 수정, 실패한 작업의 복구를 모두 설계해야 합니다. 화면에는 보이지 않지만 공수의 상당 부분이 여기에 들어갑니다.

범위가 늦게 확정되면 이미 만든 것을 버리게 됩니다

가장 비싼 실패는 처음부터 큰 것을 만드는 게 아니라, 작은 것으로 시작한 뒤 중간에 큰 것으로 바꾸는 경우입니다. 회원 개념이 없다고 전제하고 만든 구조에 뒤늦게 로그인과 권한을 넣으려면, 화면만 고치는 것으로 끝나지 않습니다. 데이터를 저장하는 방식 자체를 다시 잡아야 하고, 그 시점에 이미 만들어 둔 화면 대부분이 영향을 받습니다.

초기에 30%를 아끼고 2차 작업에서 80%를 더 쓰는 일은 드물지 않습니다. 반대로 처음부터 플랫폼으로 설계했는데 실제로는 소개 페이지만 필요했던 경우도 낭비입니다. 결론은 규모를 키우거나 줄이는 게 아니라, 발주 전에 어느 쪽인지 확정하는 것입니다.

홈페이지인지 웹 플랫폼인지 가르는 네 가지 질문

기술 용어 없이 답할 수 있는 질문 네 개면 구분이 됩니다. 오른쪽 칸에 하나라도 해당하면, 만들려는 것은 홈페이지가 아니라 웹 플랫폼입니다.

질문	홈페이지 제작	웹 플랫폼 개발
사용자가 로그인해야 하는가	필요 없음 (관리자만)	여러 종류의 사용자가 로그인
사용자가 데이터를 만드는가	문의 폼 정도	등록·수정·삭제가 서비스의 본체
역할에 따라 화면이 달라지는가	모두 같은 화면	권한별로 다른 화면과 기능
다른 시스템과 연동되는가	거의 없음	결제·인증·알림·외부 API 등

실무에서 가장 자주 놓치는 것은 세 번째입니다. “관리자 페이지는 당연히 있는 거죠”라고 넘어갔다가, 개발 중반에 관리자·운영자·본사 담당자가 서로 다른 권한을 가져야 한다는 사실이 드러나는 경우가 많습니다. 이 항목들을 발주 전에 문서로 정리하는 방법은 요구사항 정의서를 어디까지 써야 하는지 정리한 글에 담았습니다. 기존 사이트를 고칠지 새로 만들지 판단해야 한다면 웹사이트 리뉴얼 판단 기준을 먼저 보시는 것이 순서입니다.

그래서 실제 선택지는 세 가지입니다

구분이 끝나면 다음 질문이 옵니다. “웹 플랫폼이라는 건 알겠는데, 어디에 맡겨야 하나요?” 이 지점에서 많은 회사가 국내 개발사 견적과 해외 개발자 단가를 나란히 놓고 비교합니다. 그런데 실제로 비교해야 하는 항목은 단가가 아니라 요구사항을 정의하고 통제하는 책임이 누구에게 있는가입니다.

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

해외 직접 발주가 계산상 가장 싸 보이는데도 총비용이 기대만큼 내려가지 않는 이유는 명확합니다. 단가에서 아낀 만큼을 발주사 담당자의 시간으로 지불하기 때문입니다. 요구사항을 영어로 정의하고, 시차를 넘어 일정을 조율하고, 산출물이 요구사항과 맞는지 검수하는 일이 전부 발주사 몫으로 넘어옵니다. 내부에 개발 조직이 없는 회사는 이 역할을 수행할 사람이 애초에 없습니다.

디비컨설팅의 IT 아웃소싱 구조가 세 번째 칸인 이유가 이것입니다. 단가는 글로벌 기준으로 가져가되, 요구사항 정의·일정 관리·검수는 한국인 PM이 한국어로 책임집니다. 발주사는 개발팀을 관리하지 않습니다. 견적 대비 실제 정산 금액이 벌어지는 구조에 대해서는 IT 외주개발 비용이 견적보다 더 나오는 이유에서 더 자세히 다뤘습니다.

디비컨설팅이 범위를 통제하는 방식

범위가 흔들리는 문제는 의지로 해결되지 않습니다. 절차로 막습니다. 웹 개발 외주 프로젝트는 다음 5단계로 진행됩니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 위의 네 가지 질문이 여기서 확정됩니다. 이 단계가 이후 재작업의 대부분을 제거합니다.
2. 개발팀 구성 — 확정된 범위에 맞춰 전담팀을 2~4주 안에 구성합니다. 범위를 먼저 정하고 팀을 짜는 순서를 바꾸지 않습니다.
3. 프로젝트 개발 — 애자일로 진행하며 진행 상황을 투명하게 공유합니다. 고객사 담당자가 하루를 개발팀 조율에 쓰지 않도록 PM이 그 역할을 맡습니다.
4. 테스트 및 배포 — QA 프로세스를 거친 뒤 배포합니다. 권한별 화면과 데이터 정합성은 여기서 별도로 검증합니다.
5. 운영 및 유지보수 — API 명세, DB 스키마, 배포 절차 문서까지 인계하고 장기 지원을 이어갑니다.

1단계에 시간을 쓰는 것이 전체 일정을 늦추는 것처럼 보이지만, 실제로는 반대입니다. 범위가 개발 중반에 바뀌면 이미 만든 것을 버리게 되고, 그 손실은 기획 기간보다 항상 큽니다.

실제 구축 사례

아래는 모두 ‘홈페이지’가 아니라 여러 사용자 역할과 데이터 흐름을 가진 웹 플랫폼으로 설계된 프로젝트입니다.

• 삼성물산 — 홈닉 · 주거 플랫폼 앱. 입주민과 관리 주체가 서로 다른 화면과 권한으로 같은 데이터를 다룹니다.
• GS건설 — 엘리시안 리조트 · 리조트 웹과 앱 통합 구축. 예약·시설·운영 데이터가 한 체계로 묶입니다.
• LS일렉트릭 — 테크스퀘어 · 산업 B2B 거래 플랫폼. 공급자와 수요자의 매칭 로직이 서비스의 본체입니다.
• 직방 — 호갱노노 · 부동산 데이터 서비스.
• 하나투어 — 하나오픈챗 · 여행 상담 채팅 서비스.
• 가천대학교 · 학사관리 시스템. 학생·교직원·관리자의 권한 분리가 설계의 출발점입니다.
• 센터필드 · 센트로폴리스 · 그랑서울 · 프라임 오피스 빌딩 관리 시스템.
• 교보생명 사내벤처(글펍) · 커뮤니티 서비스.

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 여러 종류의 사용자가 쓰는 서비스를 만들어야 하지만, 내부에 개발 조직이 없는 기업
• 국내 개발사 견적이 예산을 넘지만 품질과 소통을 포기할 수 없는 기업
• 이전 외주 프로젝트가 범위 변경으로 무너진 경험이 있는 기업
• 출시 이후에도 기능을 계속 늘려갈 계획이 있는 기업

반대로 권하지 않습니다

• 정말로 소개용 홈페이지만 필요한 경우. 회사 소개와 문의 폼이 전부라면 플랫폼 설계는 과잉입니다. 이 경우 필요한 범위만 별도로 안내드립니다.
• 2주 안에 무조건 출시해야 하는 경우. 요구 분석과 팀 구성만으로도 그 이상이 필요합니다. 일정이 고정되어 있다면 범위를 줄이는 논의가 먼저입니다.
• 무엇을 만들지 결정할 사람이 없는 경우. PM이 요구사항을 정의하더라도 최종 결정은 발주사가 합니다. 결정권자가 없는 프로젝트는 범위가 계속 흔들립니다.

자주 묻는 질문

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

발주사는 한국인 PM과 한국어로만 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수가 모두 PM의 책임입니다. 개발팀과 직접 영어로 회의하실 필요가 없습니다.

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

등급별 단가에 투입 기간을 곱하는 방식이며, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 어느 항목이 늘어나면 어느 금액이 움직이는지 보이는 형태로 드립니다. 국내 인력 채용 대비 평균 40~60%의 비용 절감이 가능합니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 위의 네 가지 질문에 답해 보신 내용을 함께 보내주시면 정확도가 크게 올라갑니다.

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

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 1차 출시 후 인원을 줄여 운영 체제로 전환하는 방식도 자주 쓰입니다.

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

발주사에 귀속됩니다. 소스코드와 함께 API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 이후 다른 업체로 이관하거나 내부 인력으로 운영하시는 데 제약이 없습니다. 계약서에서 이 조항을 어떻게 확인해야 하는지는 개발 외주 계약서 확인 사항에 정리해 두었습니다.

정리

웹 플랫폼 개발과 홈페이지 제작을 가르는 것은 예산 규모나 화면 수가 아니라, 여러 종류의 사용자가 각자 데이터를 만들고 바꾸는 구조인지 여부입니다. 로그인·데이터 생성·권한별 화면·외부 연동 중 하나라도 해당하면 설계 방식 자체가 달라지고, 그 사실을 개발 중반에 발견하는 것이 외주 프로젝트에서 가장 비싼 실수입니다. 발주 전에 네 가지 질문에 답을 정하고, 그 답을 문서로 확정할 책임을 누가 지는지까지 정하면 견적은 예측 가능해집니다.

홈페이지 제작 비용을 알아보려고 세 곳에 견적을 요청하면, 돌아오는 금액의 폭이 당황스러울 만큼 넓습니다. 한 곳은 수백만 원을 말하고, 다른 곳은 수천만 원을 말하고, 마지막 한 곳은 금액을 주지 않은 채 “요구사항을 좀 더 들어봐야 한다”고 답합니다. 같은 자료를 보내고 같은 참고 사이트를 보여드렸는데도 그렇습니다.

이 시점에서 대부분의 담당자는 누가 금액을 부풀리고 있는지를 판단하려 합니다. 그런데 실제로는 세 곳 모두 정직하게 산정했을 가능성이 높습니다. 세 곳이 서로 다른 물건의 가격을 말했기 때문입니다.

한국어에서 “홈페이지”라는 단어는 회사 소개 다섯 페이지짜리 사이트부터, 회원이 매일 로그인해서 쓰는 웹 서비스까지 전부를 가리킵니다. 발주사가 어느 쪽을 원하는지 정하지 않은 상태로 견적을 요청하면, 각 업체는 자기가 평소에 만드는 것을 기준으로 답합니다. 금액이 열 배 차이 나는 이유는 개발 단가가 아니라 정의입니다.

이 글은 “홈페이지”라고 불리는 세 가지 다른 물건을 구분하는 기준, 유형별로 비용을 결정하는 요소, 그리고 유형에 따라 맞는 파트너가 왜 달라지는지를 정리합니다. 웹 개발 외주를 검토하기 시작하셨다면, 견적을 요청하기 전에 읽어 보시기 바랍니다.

디비컨설팅은 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 프로젝트별 개발팀을 구성합니다. 고객 만족도는 98%입니다. 직방 호갱노노(부동산 데이터 서비스), LS일렉트릭 테크스퀘어(산업 B2B 거래 플랫폼), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 가천대학교 학사관리 시스템처럼 사용자가 매일 접속하는 웹 서비스를 구축해 왔습니다. 디비컨설팅은 시원스쿨(Siwon School) 계열사입니다. 회사에 대한 자세한 내용은 디비컨설팅 소개에서 확인하실 수 있습니다.

“홈페이지” 한 단어가 가리키는 세 가지 물건

견적을 요청하기 전에 정해야 하는 것은 예산 규모가 아닙니다. 만들려는 것이 아래 셋 중 어디에 속하는지입니다.

	브로슈어형 홈페이지	기능형 웹사이트	웹 플랫폼(웹 서비스)
목적	회사·제품을 보여주는 것	문의·예약·신청을 처리하는 것	사용자가 반복해서 쓰는 것
핵심 산출물	디자인과 콘텐츠	입력 폼과 관리자 기능	데이터 구조와 API
로그인·회원 관리	없음	제한적	필수
비용을 결정하는 것	페이지 수, 디자인 수준	기능 개수	데이터 모델, 예외 처리
발주 후 변경 비용	낮음	보통	매우 높음
출시 후 운영 부담	거의 없음	낮음	지속적
적합한 파트너	제작 대행사	소규모 개발사	요구사항 정의 + 전담 개발팀

브로슈어형 홈페이지 — 비용은 페이지 수에서 나옵니다

회사 소개, 사업 영역, 오시는 길, 문의 폼 정도로 구성된 사이트입니다. 데이터가 쌓이지 않고, 사용자가 로그인하지 않으며, 관리자가 손볼 것도 콘텐츠뿐입니다. 이 유형에서 견적을 좌우하는 것은 페이지 수와 디자인의 완성도이고, 대부분 제작 대행사가 템플릿 기반으로 빠르게 만들어 줍니다.

여기에 해당한다면 개발사를 찾을 이유가 없습니다. 제작 대행사에 맡기시는 것이 빠르고 저렴합니다. 저희에게 문의하실 필요도 없습니다.

기능형 웹사이트 — 비용은 기능 개수에서 나옵니다

브로슈어형에 처리 기능이 붙은 형태입니다. 상담 신청을 받아 담당자에게 배정하고, 예약 현황을 관리자 화면에서 보고, 신청서를 엑셀로 내려받습니다. 데이터가 쌓이기 시작하지만 아직 사용자가 매일 들어오는 서비스는 아닙니다.

이 유형은 기능 목록을 문장으로 적을 수 있으면 견적도 어느 정도 정확해집니다. 문제는 기능 목록을 적는 순간 대부분의 회사가 “그러면 이것도 되어야 하는데”를 발견한다는 점입니다. 그 발견이 계약 전에 일어나면 견적이 정확해지고, 계약 후에 일어나면 추가 비용이 됩니다.

웹 플랫폼 — 비용은 눈에 보이지 않는 곳에서 나옵니다

사용자가 계정을 만들고, 데이터를 올리고, 서로 상호작용하고, 결제하거나 정산하는 서비스입니다. 매물 데이터를 보여주는 부동산 서비스, 기업 간 거래를 중개하는 B2B 플랫폼, 수강생과 강의 이력을 관리하는 학습 시스템이 여기에 속합니다.

이 유형에서 비용을 결정하는 것은 화면 수가 아닙니다. 데이터를 어떤 구조로 저장할지, 권한을 어떻게 나눌지, 그리고 정상적으로 흘러가지 않는 경우를 어디까지 처리할지가 결정합니다. 결제가 중간에 실패하면, 두 사람이 같은 것을 동시에 신청하면, 승인 담당자가 퇴사하면 어떻게 되는지 — 이런 질문의 개수가 개발 기간을 정합니다. 화면으로는 보이지 않기 때문에 발주사가 견적서를 보고 “화면 스무 개인데 왜 이렇게 비싼가”라고 느끼는 지점이 정확히 여기입니다.

같은 이유로, 웹 플랫폼은 발주 후에 구조를 바꾸는 비용이 유형 중 가장 높습니다. 데이터 구조를 바꾸면 그 위에 올라간 모든 화면과 기능이 함께 움직입니다. 서비스 개발에서 가장 비싼 비용이 코드가 아니라 사람을 관리하는 시간인 이유도 여기에 있습니다.

유형이 정해지지 않으면 견적은 계산될 수 없습니다

업체는 자기가 아는 유형으로 답합니다

“중고 거래 홈페이지를 만들고 싶습니다”라는 한 문장을 받으면, 제작 대행사는 상품 목록 화면이 있는 사이트를 떠올리고 수백만 원을 말합니다. 플랫폼을 만들어 온 개발사는 회원, 거래, 정산, 신고 처리, 분쟁 처리를 떠올리고 수천만 원을 말합니다. 둘 다 자기가 상상한 물건의 가격을 정직하게 답한 것입니다.

발주사가 세 곳의 견적을 나란히 놓고 비교할 수 없는 이유가 여기 있습니다. 비교는 같은 물건에 대해서만 가능합니다. 유형을 정하지 않은 채 여러 곳에서 받은 견적은 데이터가 아니라 소음입니다.

잘못된 유형의 파트너에게 발주하면 비용은 두 번 듭니다

가장 비싼 실수는 웹 플랫폼이 필요한 회사가 가장 낮은 견적을 준 제작 대행사에 발주하는 경우입니다. 초반 몇 주는 순조롭습니다. 화면이 나오고 디자인이 붙습니다. 문제는 사용자가 늘고 데이터가 쌓이기 시작할 때 나타납니다. 관리자 화면이 느려지고, 권한을 나눠야 하는데 나눌 수 없고, 통계를 뽑아야 하는데 그 형태로 저장되어 있지 않습니다.

이때 남은 선택지는 두 가지뿐입니다. 그 위에 계속 덧붙이거나, 데이터 구조부터 다시 만드는 것입니다. 전자는 손댈 때마다 비용이 올라가고, 후자는 이미 쓴 예산을 버리는 일입니다. 초기에 아낀 금액보다 재구축 비용이 큰 경우가 드물지 않습니다. IT 외주개발 비용이 견적보다 항상 더 나오는 구조와 같은 패턴입니다.

이미 만들어 둔 사이트가 있고 그것을 계속 쓸 수 있는지 판단해야 하는 상황이라면, 고칠 것과 다시 만들 것을 가르는 기준을 먼저 확인하시기 바랍니다. 판단의 순서가 다릅니다.

발주 전에 필요한 것은 디자인 시안이 아니라 요구사항입니다

많은 회사가 견적을 받기 전에 참고 사이트를 모으고 디자인 이미지를 준비합니다. 도움이 되기는 하지만, 견적의 정확도를 결정하는 것은 그것이 아닙니다. 누가 쓰는지, 무엇을 저장하는지, 어떤 권한이 있는지, 잘못된 경우를 어디까지 막을지가 정해져야 개발 기간이 계산됩니다.

이 문서를 어디까지 써야 하는지는 요구사항 정의서, 어디까지 써야 할까에 따로 정리해 두었습니다. 다만 여기서 한 가지는 미리 말씀드릴 필요가 있습니다. 사내에 개발팀이나 PM이 없는 회사가 이 문서를 혼자 쓰기는 대체로 어렵습니다. 그리고 이 문서를 누가 쓰는지가, 다음 장의 선택을 결정합니다.

웹 플랫폼을 만들어야 한다면, 선택지는 셋입니다

만들려는 것이 세 번째 유형으로 확인되었다면, 이제 남은 질문은 누구와 만들 것인가입니다. 실무에서 검토되는 경로는 셋입니다.

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

이 표에서 가장 중요한 줄은 개발 단가가 아니라 “요구사항 정의 책임”입니다. 해외 직접 발주가 기대만큼 저렴해지지 않는 이유가 정확히 여기에 있습니다. 시간당 단가는 분명히 내려갑니다. 그러나 무엇을 만들 것인지 정의하는 일이 통째로 발주사에게 넘어옵니다. 데이터 구조를 정하고, 예외 상황을 정리하고, 산출물을 검수하고, 시차를 넘겨 가며 영어로 조율하는 일을 발주사 담당자가 직접 해야 합니다.

사내에 개발팀과 PM이 있는 회사라면 가능합니다. 그러나 개발 조직이 없는 회사가 해외 개발팀을 직접 운영하는 것은 사실상 어렵습니다. 요구사항을 정의할 사람이 없는 상태에서 개발이 시작되면, 낮은 단가로 잘못된 것을 빠르게 만들게 됩니다. 그리고 재작업 비용은 단가가 낮다고 해서 낮아지지 않습니다. 앞에서 본 것처럼 웹 플랫폼은 구조를 되돌리는 비용이 가장 큰 유형입니다. 문제가 개발사가 아니라 구조에 있다고 말씀드리는 이유입니다.

그래서 실제 의사결정 문제는 어느 국가의 개발자를 쓰느냐가 아닙니다. 요구사항을 누가 정의하고, 그 결과에 누가 책임지는가입니다. 세 번째 선택지, 즉 한국인 PM이 한국어로 요구사항을 정의하고 검수까지 책임지면서 검증된 글로벌 개발팀이 구현을 맡는 구조가 이 질문에 답합니다. 발주사는 국내 채용 대비 평균 40~60%의 비용 절감을 가져가면서, 커뮤니케이션과 정의 책임은 국내 발주와 동일한 조건으로 유지합니다. 디비컨설팅의 IT 아웃소싱이 제공하는 것이 이 구조입니다.

디비컨설팅이 비용을 통제하는 5단계

1. 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 이 단계에서 가장 먼저 확정하는 것이 앞에서 이야기한 유형입니다. 브로슈어형으로 충분한 영역과 플랫폼으로 만들어야 하는 영역을 문장으로 가릅니다. 재작업의 대부분은 여기서 사라집니다. 범위가 문서로 있으면, 개발 중에 발견되는 일이 아니라 계약 전에 합의되는 일이 되기 때문입니다.

2. 개발팀 구성

확정된 요구사항에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할만 넣습니다. 범위가 먼저 정해졌기 때문에 팀을 과하게 잡을 이유도, 부족하게 잡아 중간에 늘릴 이유도 줄어듭니다.

3. 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자는 영어로 개발자와 조율하지 않습니다. 한국인 PM하고만 한국어로 이야기하고, 산출물을 확인하고, 다음 우선순위를 정합니다. 담당자가 하루를 커뮤니케이션에 쓰지 않는 것이 이 구조의 목적입니다.

4. 테스트 및 배포

QA 프로세스를 거친 뒤 릴리스합니다. 웹 플랫폼에서는 화면이 뜨는지만 보는 것으로 부족합니다. 결제 실패, 동시 요청, 권한 없는 접근처럼 정상적으로 흘러가지 않는 경로를 함께 검증합니다.

5. 운영 및 유지보수

문서와 함께 인계합니다. API 명세, DB 스키마, 배포 절차를 남기고 장기 지원을 이어갑니다. 다음에 기능을 추가하거나 개발사를 바꾸실 때, 시스템을 다시 읽는 데 몇 주를 쓰지 않도록 하는 것이 이 단계의 역할입니다.

실제 수행 프로젝트

• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• 가천대학교 — 학사관리 시스템
• 센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 삼성물산 홈닉 — 주거 플랫폼 앱
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스
• 와디즈 — 글로벌 플랫폼

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 실서비스를 운영 중인 기업들과 함께 진행한 프로젝트입니다. 전체 목록은 포트폴리오에서 보실 수 있습니다.

이런 기업에 적합합니다

• 만들려는 것이 단순 홈페이지가 아니라 사용자가 계정을 만들고 데이터를 쌓는 웹 서비스인 기업
• 여러 곳에서 견적을 받았지만 금액 차이가 너무 커서 무엇을 기준으로 비교해야 할지 모르는 기업
• 사내에 개발팀이나 PM이 없어 요구사항을 문서로 정의할 사람이 없는 기업
• 해외 개발 비용을 검토했지만 직접 관리할 인력이 없어 실행하지 못한 기업
• 출시 이후에도 기능 추가와 운영이 계속 이어질 서비스를 준비하는 기업

반대로, 권하지 않습니다

• 필요한 것이 회사 소개 페이지 다섯 장짜리 브로슈어형 홈페이지라면, 제작 대행사에 맡기시는 것이 빠르고 저렴합니다. 저희 구조는 과합니다.
• 사내에 개발팀과 PM이 이미 있고 요구사항을 직접 정의할 수 있는 기업이라면, 파트너 없이 해외 인력을 직접 운영하시는 편이 낫습니다.
• 요구사항을 문서로 정의하는 과정을 생략하고 바로 개발부터 시작하기를 원하신다면, 저희와는 맞지 않습니다. 저희가 비용을 줄이는 방식이 정확히 그 단계에 있기 때문입니다.
• 이미 만들어 둔 시스템에서 배너나 문구만 바꾸는 작업이라면, 기존 유지보수 업체가 더 빠릅니다.

자주 묻는 질문

홈페이지인지 웹 플랫폼인지 저희도 아직 모릅니다. 견적을 받을 수 있나요?

가능합니다. 오히려 그 판단을 함께 하는 것이 첫 단계입니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 일정과 예산 범위만 정리되어 있으면 개략 견적을 드릴 수 있습니다. 기획서나 디자인 시안은 없어도 됩니다. 상세 정의는 1단계인 상담 및 요구 분석에서 함께 문서로 만듭니다.

해외 개발자와 직접 소통해야 하나요?

아닙니다. 발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 모두 PM의 책임입니다. 개발팀과의 커뮤니케이션은 PM이 처리하므로, 발주사 담당자가 영어로 회의에 들어가거나 시차를 맞출 일은 없습니다.

비용은 어떻게 산정됩니까?

투입 인력의 등급별 단가와 투입 기간을 기준으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 단계에 얼마가 들어가는지 확인하실 수 있습니다. 범위가 바뀌면 어느 항목이 얼마나 움직이는지도 같은 기준으로 설명드립니다. 페이지 수 기준의 정액 견적이 아니라, 무엇을 만드는지에 따라 산정되는 구조입니다.

프로젝트 중간에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에도 범위와 일정에 맞춰 인원을 조정합니다. 웹 플랫폼은 초기에 설계·기획 비중이 크고 후반에 개발·QA 비중이 커지므로, 실제로 조정이 필요한 경우가 많습니다.

소스코드 소유권은 누구에게 있습니까?

발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 웹 플랫폼에서 이 조건은 특히 중요합니다. 데이터 구조 문서가 없으면 다음 개발사가 시스템을 읽는 데만 몇 주를 쓰게 되고, 그 비용은 다음 프로젝트 예산에 그대로 붙습니다. 그 상황을 만들지 않는 것이 저희 계약의 기본 조건입니다.

정리

홈페이지 제작 비용의 견적이 업체마다 열 배씩 다른 것은 시장이 불투명해서가 아닙니다. 발주사와 업체가 같은 단어로 서로 다른 물건을 이야기하고 있기 때문입니다. 브로슈어형 홈페이지, 기능형 웹사이트, 웹 플랫폼은 비용을 결정하는 요소가 다르고, 발주 후 변경 비용이 다르고, 맞는 파트너가 다릅니다. 그래서 견적을 여러 곳에서 더 받는 것보다, 만들려는 것이 어느 유형인지 먼저 정하는 것이 예산을 훨씬 크게 좌우합니다. 그리고 사내에 개발팀이 없는 회사가 그 정의를 혼자 해내기는 어렵습니다. 지금 받으신 견적들이 왜 이렇게 다른지부터 함께 정리해 드립니다.

웹사이트 리뉴얼을 검토하기 시작하는 시점은 회사마다 놀라울 만큼 비슷합니다. 5년 전에 만든 사이트가 아직 돌아가기는 합니다. 다만 모바일에서 표와 이미지가 깨지고, 첫 화면이 뜨는 데 몇 초가 걸립니다. 관리자 페이지는 만들어 준 개발사만 손댈 수 있어서, 카테고리 하나를 추가하려면 메일을 보내고 이틀을 기다립니다. 영업팀이 요청한 상담 신청 폼 하나를 붙이는 데 처음 들었던 금액보다 높은 견적이 돌아옵니다. 그 개발사는 이미 담당자가 두 번 바뀌었고, 지금 남아 있는 사람은 이 시스템을 처음 설계한 사람이 아닙니다.

그래서 회의를 잡습니다. 그리고 그 회의는 대개 결론 없이 끝납니다. 지금 있는 것을 고쳐 쓸 것인지, 아니면 아예 다시 만들 것인지 판단할 기준이 회사 안에 없기 때문입니다.

이것은 취향의 문제가 아니라 예산의 문제입니다. 똑같이 “리뉴얼”이라고 부르지만, 부분 개선과 전면 재구축 사이에서 비용은 열 배까지 벌어집니다. 그리고 대부분의 회사는 이 판단을 내린 다음에 발주하는 것이 아니라, 발주한 다음에 판단하게 됩니다. 비용이 통제되지 않는 진짜 이유가 여기에 있습니다.

이 글은 고칠 것과 다시 만들 것을 가르는 기준, 그리고 그 기준을 누가 세워야 하는지를 정리합니다. 이미 웹 개발 외주를 검토 중이시라면, 발주서를 쓰기 전에 먼저 읽어 보시기 바랍니다.

디비컨설팅은 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 프로젝트별 개발팀을 구성합니다. 고객 만족도는 98%입니다. 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 직방 호갱노노(부동산 데이터 서비스), LS일렉트릭 테크스퀘어(산업 B2B 거래 플랫폼) 등 국내 대기업의 실서비스를 함께 만들어 왔습니다. 디비컨설팅은 시원스쿨(Siwon School) 계열사입니다. 회사에 대한 자세한 내용은 디비컨설팅 소개에서 확인하실 수 있습니다.

리뉴얼 프로젝트의 견적은 왜 계속 올라가는가

리뉴얼이 실패하는 방식은 몇 가지로 정해져 있습니다. 기술이 부족해서가 아니라, 발주 구조가 같은 자리에서 반복해서 무너지기 때문입니다. 신규 개발에서도 같은 구조적 문제가 반복되지만, 리뉴얼에서는 기존 시스템이라는 변수가 하나 더 붙습니다.

리뉴얼의 범위를 발주 전에 아무도 정의하지 않습니다

대부분의 리뉴얼은 “디자인만 좀 바꾸면 된다”에서 출발합니다. 그런데 새 디자인을 얹으려면 지금의 화면 구조로는 안 된다는 사실이 드러납니다. 화면 구조를 바꾸려니 데이터가 그 형태로 저장되어 있지 않습니다. 결국 처음에는 손댈 생각이 전혀 없었던 데이터 구조까지 열게 됩니다.

이 확장은 개발사가 욕심을 부려서 생기는 것이 아닙니다. 범위가 처음부터 정의된 적이 없기 때문에, 작업을 시작한 뒤에야 하나씩 발견되는 것입니다. 발주사 입장에서는 요청한 적 없는 일이 계속 추가되는 것처럼 보이고, 개발사 입장에서는 하지 않으면 완성이 안 되는 일입니다. 양쪽 다 맞는 말이라서 협상으로 풀리지 않습니다.

기존 시스템을 만든 개발사가 문서를 남기지 않았습니다

리뉴얼은 신규 개발과 다릅니다. 이미 돌아가고 있는 시스템을 읽는 일부터 시작합니다. 그런데 API 명세도, DB 스키마도, 배포 절차도 문서로 남아 있지 않은 경우가 많습니다. 남아 있는 것은 코드뿐이고, 그 코드를 쓴 사람은 이미 회사에 없습니다.

그러면 새 개발사는 견적에 “분석 기간”을 넣습니다. 그 기간은 정확히 예측되지 않기 때문에 넉넉하게 잡히고, 그럼에도 부족해서 다시 늘어납니다. 초기 견적의 1.5배가 되는 일은 드물지 않습니다. 앞선 프로젝트가 문서를 남기지 않았다는 이유 하나로, 이번 프로젝트의 예산이 올라가는 구조입니다. 서비스 개발에서 가장 비싼 비용이 사람을 관리하는 시간인 이유도 같은 자리에 있습니다.

고칠 것과 다시 만들 것을 섞어서 발주합니다

가장 비용이 많이 드는 실수입니다. 유지보수로 충분한 영역과 재구축이 필요한 영역이 하나의 발주서 안에 섞여 들어갑니다. 개발사는 어느 쪽 기준으로 견적을 내야 할지 알 수 없으므로, 리스크를 얹어서 산정하거나 일단 낮게 부르고 진행 중에 조정합니다.

어느 쪽이든 발주사에게는 같은 결과입니다. 견적이 계속 움직이고, 일정이 밀리고, 회사 안에서 “그래서 이 프로젝트 얼마짜리냐”에 답할 수 있는 사람이 없어집니다. 이것이 문제가 개발사가 아니라 구조에 있다고 말씀드리는 이유입니다.

선택지는 셋입니다 — 그리고 진짜 쟁점은 개발 단가가 아닙니다

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

표에서 가장 중요한 줄은 개발 단가가 아니라 “요구사항 정의 책임”입니다. 해외 직접 발주가 기대만큼 저렴해지지 않는 이유가 정확히 여기에 있습니다. 시간당 단가는 분명히 내려가지만, 무엇을 만들 것인지 정의하는 일이 통째로 발주사에게 넘어옵니다. 화면 단위로 기능을 쪼개고, 예외 상황을 정리하고, 산출물을 검수하고, 시차를 넘겨 가며 커뮤니케이션하는 일을 발주사 담당자가 직접 해야 합니다.

사내에 개발팀과 PM이 있는 회사라면 가능합니다. 그러나 개발 조직이 없는 회사가 해외 개발팀을 직접 운영하는 것은 사실상 불가능에 가깝습니다. 요구사항을 정의할 사람이 없는 상태에서 개발이 시작되면, 저렴한 단가로 잘못된 것을 빠르게 만들게 됩니다. 그리고 재작업 비용은 단가가 낮다고 해서 낮아지지 않습니다. 오히려 커뮤니케이션 비용이 붙어서 국내 발주보다 총비용이 커지는 경우도 있습니다. IT 외주개발 비용이 견적보다 항상 더 나오는 구조에서 같은 패턴을 확인하실 수 있습니다.

그래서 실제 의사결정 문제는 “인도냐 베트남이냐”가 아닙니다. “요구사항을 누가 정의하고, 그 결과에 누가 책임지는가”입니다. 세 번째 선택지, 즉 한국인 PM이 한국어로 요구사항을 정의하고 검수까지 책임지면서 글로벌 개발팀이 구현을 맡는 구조가 유일하게 이 질문에 답합니다. 발주사는 국내 채용 대비 평균 40~60%의 비용 절감을 가져가면서도, 커뮤니케이션과 정의 책임은 국내 발주와 동일한 조건으로 유지합니다. 디비컨설팅의 IT 아웃소싱이 제공하는 것이 이 구조입니다.

디비컨설팅이 리뉴얼을 통제하는 5단계

1. 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 어느 영역을 고치고 어느 영역을 다시 만들지, 이 단계에서 문장으로 확정합니다. 앞서 이야기한 재작업의 대부분은 여기서 사라집니다. 범위가 문서로 있으면 개발 중에 발견되는 일이 아니라 계약 전에 합의되는 일이 되기 때문입니다.

2. 개발팀 구성

확정된 요구사항에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할만 넣습니다. 범위가 먼저 정해졌기 때문에 팀을 과하게 잡을 이유도, 부족하게 잡아 중간에 늘릴 이유도 줄어듭니다.

3. 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자는 영어로 개발자와 조율하지 않습니다. 한국인 PM하고만 한국어로 이야기하고, 산출물을 확인하고, 다음 스프린트 우선순위를 정합니다. 담당자가 하루를 커뮤니케이션에 쓰지 않는 것이 이 구조의 목적입니다.

4. 테스트 및 배포

QA 프로세스를 거친 뒤 릴리스합니다. 리뉴얼은 기존 사용자와 기존 데이터가 있는 상태에서 전환하는 작업이므로, 기능 검증만이 아니라 전환 자체를 검증합니다.

5. 운영 및 유지보수

문서와 함께 인계합니다. API 명세, DB 스키마, 배포 절차를 남기고 장기 지원을 이어갑니다. 이번 리뉴얼이 비쌌던 이유가 앞선 개발사가 문서를 남기지 않은 것이었다면, 다음 리뉴얼에서 같은 일이 반복되지 않도록 하는 것이 이 단계의 역할입니다.

실제 수행 프로젝트

• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 직방 호갱노노 — 부동산 데이터 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 실서비스를 운영 중인 기업들과 함께 진행한 프로젝트입니다. 전체 목록은 포트폴리오에서 보실 수 있습니다.

이런 기업에 적합합니다

• 웹사이트나 웹 서비스가 오래되어 리뉴얼이 필요하지만, 사내에 개발팀이나 PM이 없는 기업
• 기존 개발사에서 문서를 넘겨받지 못해 인수인계가 막혀 있는 기업
• 해외 개발 비용을 검토했지만 직접 관리할 인력이 없어 실행하지 못한 기업
• 개발 예산을 줄여야 하지만 커뮤니케이션 품질은 국내 발주 수준으로 유지해야 하는 기업
• 리뉴얼 이후에도 기능 추가와 운영이 계속 이어질 서비스를 가진 기업

반대로, 권하지 않습니다

• 사내에 개발팀과 PM이 이미 있고 요구사항을 직접 정의할 수 있는 기업이라면, 이 구조는 굳이 필요하지 않습니다. 파트너 없이 해외 인력을 직접 운영하시는 편이 낫습니다.
• 2주 안에 끝내야 하는 단순 페이지 수정이나 배너 교체라면 과한 구조입니다. 기존 유지보수 업체에 맡기시는 것이 빠르고 저렴합니다.
• 요구사항을 문서로 정의하는 과정 자체를 생략하고 바로 개발부터 시작하기를 원하신다면, 저희와는 맞지 않습니다. 저희가 비용을 줄이는 방식이 정확히 그 단계에 있기 때문입니다.

자주 묻는 질문

해외 개발자와 직접 소통해야 하나요?

아닙니다. 발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 모두 PM의 책임입니다. 개발팀과의 커뮤니케이션은 PM이 처리하므로, 발주사 담당자가 영어로 회의에 들어가거나 시차를 맞출 일은 없습니다.

비용은 어떻게 산정됩니까?

투입 인력의 등급별 단가와 투입 기간을 기준으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 단계에 얼마가 들어가는지 확인하실 수 있습니다. 범위가 바뀌면 어느 항목이 얼마나 움직이는지도 같은 기준으로 설명드립니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 일정과 예산 범위만 정리되어 있으면 개략 견적을 드릴 수 있습니다. 상세 기획은 1단계인 상담 및 요구 분석에서 함께 문서로 만듭니다.

프로젝트 중간에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에도 범위와 일정에 맞춰 인원을 조정합니다. 리뉴얼은 초기 단계에 설계·기획 비중이 크고 후반에 개발·QA 비중이 커지므로, 실제로 조정이 필요한 경우가 많습니다.

소스코드 소유권은 누구에게 있습니까?

발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이번 리뉴얼의 비용이 올라간 원인이 앞선 개발사가 아무 문서도 남기지 않은 것이었다면, 그 상황을 다시 만들지 않는 것이 저희 계약의 기본 조건입니다. 다음 개발사가 누가 되든, 시스템을 읽는 데 다시 몇 주를 쓰지 않아도 되도록 넘겨드립니다.

정리

웹사이트 리뉴얼에서 예산을 결정하는 것은 개발 단가가 아니라 요구사항 정의입니다. 고칠 것과 다시 만들 것을 발주 전에 문서로 가르면 견적은 움직이지 않고, 가르지 못하면 어떤 단가로 발주해도 비용은 올라갑니다. 그리고 사내에 개발팀이 없는 회사가 이 정의를 혼자 해내기는 어렵습니다. 한국인 PM이 한국어로 범위를 확정하고 검수까지 책임지며, 검증된 글로벌 개발팀이 구현을 맡는 구조가 필요한 이유입니다. 지금 사이트의 어느 부분을 고치고 어느 부분을 다시 만들어야 할지 판단이 서지 않으신다면, 그 판단부터 함께 정리해 드립니다.