프론트엔드·백엔드 개발 비용은 각각 얼마인가 — 견적이 나뉘지 않는 이유와 분해 기준

"프론트엔드 비용", "백엔드 견적"으로 검색해도 단가가 잘 나오지 않습니다. 자료를 안 만들어서가 아니라, 실제로 발행되는 견적서 자체가 둘을 나누지 않기 때문입니다.

프리시가 2026년에 발행한 견적서 81건(중복 제거 후 고유 프로젝트)에도 프론트엔드/백엔드로 분류된 항목은 없습니다. 유형은 "API 연동·백엔드", "웹앱·SaaS 플랫폼"처럼 결과물 단위로 잡히고, 그 안에서 화면과 서버가 한 덩어리로 산정됩니다. 이 81건의 견적 중앙값은 38만 원이며, 프로젝트 단위 총액 기준입니다. 소규모·단발성 의뢰가 많은 표본이라 중앙값이 낮게 잡힙니다. 집계 원본은 2026년 견적 81건 리포트에 있습니다.

그래서 이 글은 "프론트 40%, 백엔드 60%" 같은 분해 비율을 제시하지 않습니다. 그런 비율을 낼 표본이 없습니다. 표본 없이 만든 비율은 발주자가 받은 견적을 검증하는 데 쓸 수 없고, 오히려 잘못된 기준을 만듭니다. 대신 각각의 금액을 무엇이 가르는지, 그리고 기존 단가표의 어느 항목이 어느 쪽 일인지를 정리했습니다.

분리해서 발주하면 견적이 나뉘긴 합니다. 다만 나눈다고 총액이 줄지는 않습니다. 두 견적의 합에는 연동 검증 공수와 책임 경계 조율이 보통 빠져 있는데, 이건 통합 발주에서는 한 업체 안에서 처리되던 일입니다. 이 부분은 아래 분리 발주 항목에서 다시 다룹니다.

프론트엔드 외주 견적이 같은 "웹사이트 하나"인데 두세 배 벌어진다면, 대개 아래 네 가지 중 하나가 다릅니다.

1. 화면 수 — 다만 사용자 화면만 세면 안 됩니다. 발주자는 보통 사용자가 보는 화면만 세지만, 실제로는 관리자 화면이 함께 필요한 경우가 많고 그 개수가 사용자 화면보다 많을 수 있습니다. 견적 요청서의 화면 목록에 관리자 화면이 들어 있는지부터 확인하세요.

2. 반응형 대응 범위. PC만인지, 모바일까지인지에 따라 같은 화면의 공수가 달라집니다. 단가표에서 관리자 대시보드의 모바일 화면 대응이 80만 원 가산으로 잡혀 있는 것이 이 항목의 크기를 보여줍니다(가산 기준).

3. 상태 복잡도. 화면이 정보를 보여주기만 하는지, 아니면 입력 중인 값·필터·선택 상태를 계속 들고 있으면서 서로 영향을 주는지의 차이입니다. 정적인 소개 페이지 10장보다 필터와 정렬이 얽힌 조회 화면 2장이 더 비쌀 수 있습니다.

4. 디자인 제공 여부. 완성된 디자인 시안(피그마 등)을 발주자가 주는지, 개발사가 화면 구성까지 잡아야 하는지에 따라 범위가 달라집니다. "알아서 예쁘게"는 범위가 정해지지 않은 요구라서 수정 라운드가 반복되고, 그 비용은 어느 쪽 견적에도 안 잡혀 있다가 나중에 분쟁이 됩니다.

백엔드 견적은 화면처럼 눈에 보이지 않아서 발주자가 검증하기 어렵습니다. 아래 네 가지를 기준으로 보면 금액 차이의 대부분이 설명됩니다.

1. 인증과 권한. "로그인 기능"과 "권한별로 보이는 게 다른 로그인 기능"은 다른 일입니다. 단가표에서 권한 등급 하나 추가가 40만 원 가산인 이유가 여기 있습니다(가산 기준). 등급이 3~4단계로 갈라지면 이 항목에서만 100만 원 이상이 붙습니다.

2. 외부 연동 개수. 결제·소셜 로그인·배송 조회·공공데이터 같은 외부 시스템은 하나 붙을 때마다 별도 공수입니다. 연동은 정상 응답을 받는 부분보다 실패했을 때의 처리가 공수를 차지합니다. 재시도, 토큰 갱신, 웹훅 수신, 로그 기록이 전부 여기 들어갑니다.

3. 실시간 여부. 하루 한 번 갱신되는 데이터와 실시간으로 밀어주는 데이터는 구조가 다릅니다. 단가표에서 API 서버·백엔드 구축의 대규모 구간(1,500만 원 이상, 프로젝트 총액 기준)을 가르는 조건이 실시간·대용량인 것도 같은 이유입니다.

4. 데이터 규모와 구조. 다루는 데이터의 종류와 그들 사이 관계가 늘어날수록 설계 공수가 늘고, 한 번 잘못 잡으면 나중 수정 비용이 큽니다. 데이터 설계가 비용에 미치는 영향은 [데이터베이스 설계가 비용에 미치는 영향](/guide/database-design-impact)에서 따로 다룹니다.

아래는 이미 공개된 단가표 항목을, 그 금액이 주로 어느 쪽 작업에서 발생하는지로 다시 배열한 것입니다. 금액은 원본 그대로이며 새로 만든 수치가 아닙니다. 원본은 소프트웨어 외주 개발 단가표에 있습니다.

여기서 바로 읽을 수 있는 것이 하나 있습니다. 백엔드는 단독 항목으로 단가가 잡혀 있는데, 프론트엔드는 단독 항목이 없습니다. "웹사이트·웹앱" 줄은 화면과 서버가 합쳐진 금액입니다. 프론트엔드만 떼어낸 시장 단가가 잘 안 보이는 것은 이런 구조 때문입니다.

기능 단위 가산 단가를 보면 조금 더 나눠 볼 수 있습니다. 아래는 관리자 대시보드 기본형(350만 원, 프로젝트 총액)에 붙는 가산 항목입니다.

화면 한 장을 더 그리는 일(60만 원)과 권한 등급 하나를 더 만드는 일(40만 원)의 금액대가 크게 다르지 않습니다. 화면은 눈에 보이고 권한은 안 보이지만 값은 비슷하다는 뜻이고, 견적서에서 "권한 3단계"를 한 줄로 적어놓은 항목이 실제로는 화면 두세 장 값이라는 의미이기도 합니다.

다만 이 매핑은 어디까지나 항목의 무게중심입니다. 어느 항목도 100% 한쪽만은 아닙니다. 조회 화면 한 장에는 그 데이터를 내려주는 서버 작업이 붙고, 권한 등급 하나에는 그것을 반영하는 화면 분기가 붙습니다. 비율로 쪼개려면 그 프로젝트의 실제 작업 내역이 필요하고, 그건 단가표가 아니라 견적서의 산출 근거에서 나옵니다.

분리 발주가 유리한 경우

이미 한쪽이 있을 때. 운영 중인 서버에 화면만 새로 붙이거나, 화면은 사내에서 만들고 서버만 맡기는 경우입니다. 이때는 애초에 나눌 것도 없이 한쪽만 발주하는 것이 맞습니다.

사내에 한쪽 담당자가 있을 때. 프론트 개발자가 사내에 있고 백엔드만 외주라면, 그 사람이 API 명세를 검토할 수 있으니 경계에서 사고가 잘 안 납니다.

규모가 커서 병렬로 가야 할 때. 다만 이 경우엔 양쪽을 조율할 사람이 발주자 쪽에 있어야 합니다.

통합 발주가 유리한 경우

처음부터 만드는 소규모 프로젝트. 나눠서 얻는 이득보다 조율 비용이 큽니다.

발주자 쪽에 API 명세를 검토할 사람이 없을 때. 이 조건이 사실상 결정적입니다. 명세를 읽을 사람이 없는 상태로 분리 발주하면, 양쪽이 서로 상대 탓을 하는 상황에서 판단할 사람이 아무도 없습니다.

분리 발주의 숨은 비용을 솔직히 적으면 세 가지입니다. 첫째, 연동 검증 공수입니다. 화면과 서버를 붙여서 실제로 동작시키는 작업은 양쪽 견적 어디에도 안 들어 있는 경우가 많습니다. 둘째, 책임 경계입니다. 화면이 안 뜨는 원인이 응답 형식인지 화면 처리인지를 가리는 데 시간이 들고, 이 시간은 아무도 청구하지 않다가 결국 일정으로 나타납니다. 셋째, 일정 동기화입니다. 백엔드가 늦으면 프론트는 대기하지만 프론트 계약의 기간은 흘러갑니다.

그래서 견적 두 개의 합이 통합 견적보다 작아 보인다면, 그 차액이 위 세 가지 중 어디에 숨어 있는지부터 확인하는 게 맞습니다. 흔히 "풀스택 외주"로 한 사람에게 통으로 맡기는 선택도 같은 맥락입니다. 조율 비용은 사라지지만, 한 사람의 강한 쪽과 약한 쪽이 그대로 결과물의 편차가 됩니다.

프론트/백엔드가 얽힌 견적서에서 나중에 문제가 되는 지점은 대체로 정해져 있습니다.

1. API 명세를 누가 쓰는가. 어떤 주소로 무엇을 요청하면 무엇이 돌아오는지를 정리한 문서입니다. 이걸 백엔드가 쓰는지, 프론트가 요구사항을 주는지, 아니면 아무도 안 쓰는지를 확인하세요. 분리 발주에서 가장 자주 비는 항목입니다.

2. 경계가 어디인가. 예를 들어 엑셀 내보내기는 화면에서 만드는 일일 수도 있고 서버에서 파일을 만들어 내려주는 일일 수도 있습니다. 어느 쪽 견적에 들어 있는지 항목으로 확인하세요.

3. 화면 목록에 관리자 화면이 포함됐는가. 사용자 화면만 세고 계약한 뒤 관리자 화면이 추가 견적으로 오는 경우가 많습니다.

4. 연동 테스트 환경이 범위인가. 결제 같은 외부 연동은 실제 결제가 발생하지 않는 테스트 환경 세팅이 별도 작업입니다.

5. 배포와 유지보수의 범위. 만든 것을 서버에 올려 돌아가게 하는 작업은 개발과 별개입니다. 유지보수는 연 단위로 보면 개발비의 연 10~20%를 잡는 것이 일반적인데(월 비율이 아니라 연 비율입니다), 이때 프론트만인지 서버 운영까지인지를 명시해야 합니다. 산정 방식은 [유지보수 비용과 SLA 기준](/guide/maintenance-cost-sla)에 정리돼 있습니다.

견적서를 항목 단위로 읽는 방법 전반은 외주 견적서 읽는 법에서 다룹니다.