많은 사장님들이 프로젝트를 시작할 때 이런 말을 하십니다: 공식 웹사이트와 관리자 백엔드를 함께 만들자, 어차피 다 웹사이트니까.
듣기에는 비용도 아끼고 수고도 덜 것 같지만, 실제로 진행하다 보면 두 가지 요구사항이 서로 충돌하고, 일정은 계속 밀리고, 예산은 계속 늘어나는 경우가 많습니다.
문제는 함께 만들 수 있느냐가 아니라, 두 가지 일의 경계를 먼저 명확히 그었느냐에 있습니다. 공식 웹사이트는 고객이 보는 것이고, 관리자 백엔드는 내부 사람들이 쓰는 것입니다. 두 가지의 목표, 리듬, 검수 기준은 완전히 다릅니다. 아래에서는 실제 프로젝트 경험을 바탕으로 계획 방안을 풀어 설명하겠습니다.
一、먼저 「함께 만들기」를 두 개의 라인으로 나누고, 하나의 요구사항 문서로 섞지 마세요
가장 흔한 실패 현장: 요구사항 문서에 백 가지를 썼는데 공식 웹사이트와 백엔드가 뒤섞여 있고, 개발을 절반쯤 하다 보니 공식 웹사이트의 표시 로직이 백엔드의 필드 설계에 의존해야 하는데 백엔드는 아직 확정되지 않은 경우입니다.
비교적 안정적인 방법은 두 개의 요구사항으로 나누되 하나의 데이터 모델을 공유하는 것입니다.
- 공식 웹사이트 라인: 컬럼 구조, 페이지 수, 콘텐츠 표시 형식, SEO 요구사항, 모바일 대응
- 백엔드 라인: 누가 로그인하는지, 무엇을 조작할 수 있는지, 데이터는 어디서 오는지, 심사 프로세스는 어떻게 진행되는지
- 공유 부분: 콘텐츠 필드, 이미지 규격, 분류 체계, 상태 흐름
구체적인 시나리오를 들어보겠습니다. 산업 장비를 만드는 기업 웹사이트를 리뉴얼하면서 동시에 뉴스를 직접 발행하고, 제품을 업로드하고, 문의를 확인할 수 있는 백엔드가 필요한 상황입니다. 처음부터 「제품」이라는 필드를 명확히 정한다면 — 이름, 모델명, 파라미터 표, 메인 이미지, 상세 이미지, 소속 카테고리, 게시/비게시 상태 — 공식 웹사이트의 제품 목록 페이지와 백엔드의 제품 관리 페이지를 동시에 개발할 수 있어 백엔드가 완성될 때까지 기다릴 필요가 없습니다.
함정 회피 알림: 「백엔드는 대충 만들면 된다」는 말로 프로젝트를 시작하지 마세요. 백엔드가 권한, 심사, 로그를 다루기 시작하면 작업량이 공식 웹사이트보다 적지 않습니다.
二、기술 선택은 양쪽을 모두 고려하고, 한쪽만 편하게 하려 하지 마세요
공식 웹사이트와 관리자 백엔드를 함께 개발할 때 기술 스택 선택은 후기 유지보수 비용에 직접 영향을 미칩니다.
일반적인 조합은 세 가지입니다:
1. 하나의 프레임워크로 전부 처리: 프론트엔드와 백엔드를 분리하지 않고 공식 웹사이트와 백엔드가 하나의 프로젝트에 있습니다. 장점은 빠르고 비용이 낮다는 것; 단점은 공식 웹사이트 트래픽과 백엔드 작업이 서로 영향을 주고 후기 확장이 번거롭다는 것입니다.
2. 프론트엔드와 백엔드 분리, 공식 웹사이트와 백엔드가 인터페이스 공유: 공식 웹사이트는 서버 사이드 렌더링 또는 정적화로 SEO를 보장하고, 백엔드는 프론트엔드 프레임워크로 인터랙션을 구현합니다. 현재 기업 웹사이트에서 비교적 주류인 선택입니다.
3. 공식 웹사이트 정적화 + 백엔드 독립 배포: 공식 웹사이트는 CDN을 사용하고, 백엔드는 별도로 내부망에 두거나 접근 제한을 추가합니다. 보안성이 더 좋아 데이터에 민감한 비즈니스에 적합합니다.
프로젝트 후기에 미니프로그램 개발이나 App 개발로 확장할 가능성이 있다면 인터페이스 설계에 미리 여지를 남겨야 합니다. 예를 들어 콘텐츠 인터페이스의 반환 구조를 통일하면 미니프로그램과 App에서 바로 재사용할 수 있어 다시 작성할 필요가 없습니다.
함정 회피 알림: 백엔드 주소에 admin 같은 기본 경로를 사용하지 말고, 로그인 인터페이스에 빈도 제한을 추가하세요. 이는 웹사이트 보안 테스트에서 가장 기초적인 점검 항목이지만 많은 프로젝트가 출시 전에 전혀 하지 않습니다.
三、인터페이스와 권한 모델이 후기 요구사항 변경 비용을 결정합니다
백엔드가 잘 만들어졌는지는 인터페이스가 얼마나 예쁜지가 아니라 두 가지를 봅니다: 인터페이스가 명확한지, 권한을 유연하게 조절할 수 있는지.
인터페이스 측면에서는 개발 전에 인터페이스 목록을 먼저 작성하여 최소한 다음을 명확히 쓰는 것을 권장합니다:
- 경로와 요청 방식
- 입력 필드와 타입
- 반환 구조
- 에러 코드 의미
- 로그인 필요 여부, 필요한 역할
권한 측면에서는 처음부터 복잡한 RBAC를 만들지 마세요. 중소기업 웹사이트 개발 프로젝트에서는 보통 세 가지 역할이면 충분합니다: 슈퍼 관리자, 콘텐츠 편집자, 읽기 전용 조회. 비즈니스가 실제로 복잡해지면 그때 확장하세요.
여기 실제 교훈이 하나 있습니다. 어느 교육 기관의 공식 웹사이트에서 강좌를 표시하고 백엔드에서 강좌 게시와 비게시를 지원해야 했습니다. 처음에 권한이 분리되지 않아 마케팅 부서 사람이 강좌를 직접 삭제할 수 있었고, 실수로 판매 중인 강좌를 삭제하여 공식 웹사이트가 동시에 오류를 일으켰습니다. 나중에 「삭제 시 2차 확인 + 작업 로그」를 추가하고 나서야 문제가 해결되었습니다.
함정 회피 알림: 삭제, 일괄 수정, 내보내기 같은 작업에는 반드시 로그와 2차 확인이 있어야 합니다. 이는 요구사항 추가가 아니라 기본입니다.
四、출시 리듬: 공식 웹사이트는 먼저 출시하고, 백엔드는 단계별로 납품
많은 사람들이 전부 완성해야 출시할 수 있다고 생각하지만, 사실 그럴 필요는 없습니다.
비교적 합리적인 리듬은:
- 1단계: 공식 웹사이트 정적 페이지 + 기본 백엔드 (콘텐츠 발행, 이미지 업로드)
- 2단계: 문의, 폼, 데이터 통계
- 3단계: 권한 세분화, 작업 로그, 데이터 내보내기
공식 웹사이트를 먼저 출시하면 검색엔진에 최대한 빨리 수집될 수 있고, 비즈니스 부서에서 먼저 사용하며 의견을 제시할 수 있습니다. 백엔드를 단계별로 납품하면 개발 부담이 적고 재작업 비용도 낮습니다.
예약类 비즈니스, 예를 들어 매장 예약, 강좌 체험 수업이라면 백엔드에서 시간 충돌, 정원 제한, 알림을 고려해야 합니다. 이런 요구사항은 미니프로그램 개발로 처리하는 것이 더 적합합니다. 공식 웹사이트는 표시와 유입을 담당하고, 미니프로그램은 전환과 유지를 담당하며, 백엔드가 데이터를 통합 관리합니다.
함정 회피 알림: 출시 전에 반드시 폼 제출, 이미지 업로드, 권한 전환, 모바일 표시를 포함한 완전한 테스트를 한轮 해야 합니다. 많은 문제는 개발이 안 한 것이 아니라 테스트를 못 한 것입니다.
五、어떤 경우에 MIC Studio를 찾는 것이 적합한가
다음과 같은 상황이라면 자체 팀을 구성하거나 개인 개발자를 찾는 것이 비용 효율적이지 않을 수 있습니다:
- 공식 웹사이트와 관리자 백엔드를 함께 만들어야 하는데 내부에 요구사항을 명확히 쓸 사람이 없는 경우
- 기존 기업 웹사이트가 있고, 리뉴얼과 동시에 백엔드를 추가하려는데 데이터 마이그레이션 문제가 걱정되는 경우
- 웹사이트 개발 + 미니프로그램 개발 + App 개발 멀티 플랫폼 연동이 필요한 경우
- 출시 전에 웹사이트 보안 테스트나 역방향 테스트를 통해 인터페이스와 권한 취약점을 점검하고 싶은 경우
MIC Studio의 방식은 먼저 요구사항을 공식 웹사이트 라인과 백엔드 라인으로 나누고, 이해할 수 있는 계획을 제시한 후 견적과 일정을 논의하는 것입니다. 기능을 쌓지 않고, 큰 그림을 그리지 않으며, 먼저 경계를 명확히 합니다.
마지막 세 가지 실행 가능한 제안
1. 필드를 먼저 쓰고, 페이지를 나중에 쓰세요. 콘텐츠 모델을 정해야 공식 웹사이트와 백엔드를 병행 개발할 수 있습니다.
2. 인터페이스 목록과 권한 표를 개발 전에 확인하세요. 이 두 문서가 후기 논쟁을 대량으로 줄여줍니다.
3. 공식 웹사이트를 먼저 출시하고, 백엔드를 단계별로 납품하세요. 전부 완성될 때까지 기다리지 말고, 일찍 출시하면 일찍 수집되고 일찍 사용됩니다.
관리자 백엔드와 공식 웹사이트를 함께 만드는 것은 불가능한 것이 아니라, 계획을 명확히 세운 후 해야 하는 것입니다. 경계를 명확히 생각하는 것이 요구사항 백 가지를 더 쓰는 것보다 더 유용합니다.