홈페이지에 백엔드는 언제 필요할까? 랜딩페이지부터 업무시스템까지
랜딩페이지를 만들 때도 백엔드가 필요하다고 생각하는 경우가 있다. 반대로 로그인, 예약, 결제와 파일 업로드가 있는 서비스를 단순 홈페이지처럼 구성하려는 경우도 있다.
백엔드가 필요한지는 페이지 수나 디자인 복잡도로 결정되지 않는다. 브라우저를 닫아도 남아야 하는 데이터가 있는지, 사용자마다 다른 권한이 필요한지, 외부에 공개하면 안 되는 비밀정보를 사용해야 하는지가 기준이다.
듀오랩스가 홈페이지와 맞춤 웹서비스를 설계할 때도 모든 프로젝트에 같은 구성을 적용할 필요는 없다. 정적인 랜딩페이지는 백엔드 없이 시작하고, 문의, 콘텐츠 관리, 회원 기능과 업무 흐름이 생길 때 필요한 기능만 단계적으로 추가하는 편이 운영하기 쉽다.
백엔드는 무엇을 하는가?
백엔드는 사용자의 화면 뒤에서 다음 역할을 맡는다.
- 브라우저를 닫아도 남아야 하는 데이터 저장
- 로그인과 세션 관리
- 사용자, 부서, 회사별 접근 권한 확인
- 이메일, 문자, 결제 같은 외부 서비스 연동
- API 키와 비밀번호처럼 공개하면 안 되는 정보 보호
- 파일 업로드와 다운로드 권한 관리
- PDF 생성, AI 처리, 대량 메일처럼 오래 걸리는 작업 실행
- 변경 기록, 오류 로그, 백업과 복구 지원
화면에서 보이지 않는다고 해서 모두 백엔드인 것은 아니다. 정적인 HTML, CSS와 이미지를 CDN에서 제공하는 일은 일반적으로 정적 호스팅 영역이다. 반대로 아주 작은 문의 양식 하나도 서버에서 비밀 키를 사용하거나 문의 내용을 저장한다면 최소한의 백엔드가 필요하다.
1단계: 백엔드가 필요 없는 랜딩페이지
다음과 같은 구성은 정적 페이지로 충분한 경우가 많다.
- 회사와 서비스 소개
- 가격 또는 상품 안내
- 이미지, 영상과 포트폴리오
- 전화, 이메일, 카카오톡 연결
- 지도와 SNS 링크
- 개인정보를 저장하지 않는 기본 방문 통계
콘텐츠가 코드나 정적 파일에 들어 있고 사용자가 데이터를 제출하지 않는다면 별도 DB와 로그인 기능이 필요하지 않다. 빌드된 파일을 CDN에 배포하면 서버 패치와 DB 백업 업무도 없다.
기술 용량과 이용 약관은 따로 확인해야 한다. Vercel Hobby는 현재 개인·비상업 용도로 제한되므로 고객사나 영업용 랜딩페이지에는 적합하지 않다. 상업용 프로젝트는 Vercel Pro 같은 업무용 플랜이나 다른 정적 호스팅을 검토한다. Vercel Hobby 안내, Vercel 이용약관
Cloudflare Pages는 정적 파일 요청을 무료로 제공하며 무료 플랜에도 빌드와 프로젝트 한도가 넉넉하다. 정적 랜딩페이지의 기술적 요구에는 잘 맞지만 고객 프로젝트에 적용하기 전에는 당시의 약관과 지원 범위를 다시 확인한다. Cloudflare Pages 가격, Cloudflare Pages 제한
2단계: 문의 접수만 필요한 최소 백엔드
문의 양식이 추가되면 사용자가 입력한 내용을 어딘가로 전달해야 한다. 이때 전체 DB를 구축할 필요는 없지만 다음 기능은 필요하다.
- 입력값 검증
- 스팸과 자동 제출 방지
- IP 또는 세션 기준 속도 제한
- 이메일이나 업무 채널로 문의 전달
- 접수 성공과 실패 상태 기록
- 개인정보 수집 안내와 보존 기준
구현 방식은 외부 폼 서비스, Vercel Function, Cloudflare Worker 중에서 선택할 수 있다. 문의를 이메일로만 전달할지, 관리자 화면에서 상태를 관리할지에 따라 범위가 달라진다.
이메일 전달만 필요하다면 작은 함수 하나로 충분할 수 있다. 문의 담당자, 상담 상태, 메모, 검색과 통계가 필요해지면 DB를 추가하는 편이 자연스럽다.
3단계: 고객이 직접 콘텐츠를 수정하는 홈페이지
회사 소개와 공지, 포트폴리오를 비개발자가 자주 수정해야 한다면 CMS나 관리 화면이 필요하다. 이때 필요한 백엔드는 다음과 같다.
- 관리자 로그인
- 게시물과 이미지 저장
- 작성 중, 검토 중, 공개 상태 관리
- 예약 공개와 수정 기록
- 관리자별 권한
- 삭제와 복구
콘텐츠 수정 횟수가 적다면 개발자가 정적 파일을 변경해 다시 배포하는 방식이 더 단순할 수 있다. 고객이 매주 내용을 바꾸거나 여러 명이 검토한다면 CMS의 가치가 커진다.
CMS를 붙였다고 모든 페이지를 매 요청마다 서버에서 만들 필요는 없다. 콘텐츠가 바뀔 때 정적 페이지를 다시 생성하면 빠른 정적 배포와 편리한 관리 화면을 함께 사용할 수 있다.
4단계: 로그인과 데이터가 있는 맞춤 웹서비스
회원가입, 예약, 고객 관리, 신청 내역처럼 사용자마다 다른 화면을 제공하려면 인증과 DB가 필요하다.
| 필요한 기능 | 백엔드가 맡는 역할 | 대표 선택지 |
|---|---|---|
| 회원가입과 로그인 | 계정, 세션, 비밀번호 재설정 | Supabase Auth |
| 고객·예약·신청 관리 | 데이터 저장, 조회와 변경 | Supabase Database |
| 사용자별 권한 | 본인, 담당자, 관리자 데이터 분리 | PostgreSQL RLS |
| 관리자 화면 | 역할 확인, 변경 기록 | Supabase와 애플리케이션 API |
| 알림 | 이메일, 문자, 앱 내 알림 | 서버 함수와 외부 발송 서비스 |
Supabase처럼 인증, PostgreSQL과 RLS를 함께 제공하는 관리형 백엔드는 작은 팀이 맞춤 웹서비스를 시작할 때 유용하다. 다만 테이블을 만들었다고 권한이 자동으로 완성되는 것은 아니다. 브라우저에서 접근하는 모든 업무 데이터에 RLS를 적용하고 역할별 조회, 추가, 수정, 삭제를 각각 시험해야 한다. Supabase RLS 가이드
5단계: 파일과 오래 걸리는 작업이 있는 업무시스템
사내 업무시스템에는 첨부 파일, 보고서 생성, 대량 메일, 엑셀 내보내기와 AI 작업이 자주 추가된다. 이 단계에서는 요청을 받은 API가 모든 일을 끝낼 때까지 기다리게 하지 않는다.
파일은 브라우저가 서명된 URL로 R2나 S3 같은 객체 저장소에 직접 올리고, 애플리케이션은 파일의 권한과 상태를 관리한다. 대용량 파일 직접 업로드 설계
오래 걸리는 작업은 큐와 워커로 분리한다. 사용자는 작업 ID를 받고 화면에서 대기 중, 처리 중, 완료, 실패와 취소 상태를 확인한다. 백그라운드 작업과 작업 큐
실시간 기능도 요구사항에 맞춰 선택한다. 몇 초 늦어도 되는 상태는 Polling으로 충분할 수 있고, 서버에서 화면으로 진행률만 보낼 때는 SSE를 검토한다. 채팅이나 공동 작업처럼 양방향 통신이 핵심일 때 WebSocket이나 관리형 Realtime을 선택한다.
기능별로 필요한 백엔드를 정리하면
| 프로젝트 기능 | 권장 백엔드 범위 |
|---|---|
| 정적 회사 소개 | 없음 |
| 문의 양식 | 작은 서버 함수 또는 외부 폼 서비스 |
| 공지와 포트폴리오 관리 | CMS 또는 간단한 DB와 관리자 인증 |
| 회원가입과 예약 | 인증, DB와 권한 정책 |
| 결제 | 서버 API, 결제 요청과 webhook 검증 |
| 파일 첨부 | 객체 저장소, 서명 URL과 파일 메타데이터 |
| 실시간 알림 | SSE, WebSocket 또는 관리형 Realtime |
| PDF·AI·대량 메일 | 작업 큐와 워커 |
| 사내 업무시스템 | 인증, DB, 권한, 감사 기록, 백업과 모니터링 |
백엔드 도입 전에 물어볼 질문
- 브라우저를 닫아도 남아야 할 데이터가 있는가?
- 로그인한 사용자마다 볼 수 있는 정보가 다른가?
- API 키나 결제 비밀정보를 숨겨야 하는가?
- 사용자가 파일이나 개인정보를 제출하는가?
- 외부 서비스가 결과를 webhook으로 알려 주는가?
- 한 요청 안에서 끝내기 어려운 작업이 있는가?
- 실패한 작업을 다시 실행하거나 취소해야 하는가?
- 고객이나 관리자가 콘텐츠를 직접 수정해야 하는가?
모두 아니라면 정적 페이지로 시작할 가능성이 높다. 하나라도 해당한다면 그 요구를 처리할 최소한의 백엔드를 선택한다.
듀오랩스 서비스에 적용하는 방법
듀오랩스의 홈페이지와 웹서비스 상품은 다음처럼 구분할 수 있다.
랜딩페이지 기본형
정적 페이지, 고객 도메인, HTTPS와 기본 검색 노출을 제공한다. 별도 DB는 사용하지 않는다.
랜딩페이지 문의형
기본형에 문의 양식, 스팸 방지와 이메일 전달을 추가한다. 문의 관리 화면이 필요하면 DB를 선택 사항으로 둔다.
홈페이지 관리형
CMS 또는 관리자 화면, 콘텐츠 상태와 이미지 관리를 제공한다. 고객의 수정 빈도에 따라 정적 재배포와 동적 조회를 선택한다.
맞춤 웹서비스
Vercel 같은 웹 플랫폼과 Supabase 같은 관리형 백엔드를 조합해 로그인, DB, 권한과 업무 데이터를 제공한다.
사내 업무시스템
맞춤 웹서비스 구성에 파일, 감사 기록, 백업, 모니터링, 롤백과 필요 시 워커를 추가한다. 사내 시스템 운영 체크리스트 30가지
듀오랩스가 보는 기준
좋은 웹서비스 구성은 사용할 수 있는 기술을 모두 넣는 것이 아니다. 현재 고객에게 필요한 기능을 가장 단순한 구조로 제공하고, 데이터와 권한이 생기는 시점에 책임 있는 백엔드를 추가하는 것이다.
랜딩페이지에는 백엔드가 없어도 된다. 문의에는 작은 함수면 충분할 수 있다. 회원과 업무 데이터가 생기면 인증, DB와 권한 정책이 필요하고, 긴 작업이 생기면 큐와 워커가 필요하다.
이 경계를 명확히 하면 고객은 사용하지 않는 인프라 비용을 줄일 수 있고, 듀오랩스는 프로젝트 범위와 유지관리 책임을 더 정확하게 설명할 수 있다.
함께 읽기
- 홈페이지 플랫폼 이전 체크리스트: 도메인, SEO, 콘텐츠, 폼, 분석 데이터홈페이지 플랫폼 이전은 새 화면을 만드는 작업만이 아닙니다. 기존 URL과 검색 노출, 도메인과 회사 메일, 게시물과 이미지, 문의 폼, 분석 태그까지 함께 옮겨야 비로소 이전이 끝납니다.
- 아임웹과 카페24에서 맞춤 개발로 넘어가야 하는 8가지 신호아임웹이나 카페24로 시작한 사이트가 성장하면 어느 순간 “이제 맞춤 개발을 해야 할까?”라는 질문이 생깁니다. 관리자 화면 밖의 엑셀 작업이 늘고, 앱과 외부 서비스를 계속 붙이는데도 업무가 매끄럽지 않기 때문입니다.
- 아임웹 vs WordPress vs Webflow vs Framer: 회사 홈페이지 제작 도구 비교회사 홈페이지를 만들 때 반드시 Next.js 같은 개발 프레임워크가 필요한 것은 아닙니다. 회사 소개, 서비스 설명, 구축 사례와 문의 접수가 중심이라면 홈페이지 빌더나 CMS가 더 빠르고 운영하기 쉬울 수 있습니다.
- 여러 회사를 지원하는 SaaS의 데이터는 어떻게 분리해야 할까?한 애플리케이션을 여러 회사가 함께 사용하는 SaaS에서는 로그인보다 테넌트 경계가 더 중요하다. 사용자가 정상적으로 로그인했더라도 다른 회사의 계약, 직원, 파일, 검색 결과를 볼 수 있다면 인증은 성공했지만 데이터 격리는 실패한 것이다.
- 사내 시스템 공개 전 확인해야 할 운영 체크리스트 30가지사내 시스템은 외부 고객 서비스보다 사용자가 적다는 이유로 공개 전 점검이 짧아지기 쉽다. 하지만 결재, 계약, 인사, 회계처럼 업무의 기준이 되는 시스템은 한 번의 권한 오류나 데이터 손실도 실제 업무 중단으로 이어진다.