웹 플랫폼 개발과 홈페이지 제작은 다릅니다 — 발주 전에 구분해야 하는 이유

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

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

디비컨설팅은 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 스키마, 배포 절차 문서까지 인계합니다. 이후 다른 업체로 이관하거나 내부 인력으로 운영하시는 데 제약이 없습니다. 계약서에서 이 조항을 어떻게 확인해야 하는지는 개발 외주 계약서 확인 사항에 정리해 두었습니다.

정리

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