많은 대표님들이 프로젝트 착수 시 이런 말을 합니다. 공식 웹사이트와 백엔드를 함께 만들면 편하다고요.
듣기에는 합리적으로 들리지만, 실제로는 가장 실패하기 쉬운 조합입니다. 공식 웹사이트는 고객을 대상으로 하며, 추구하는 것은 로딩 속도, 시각적 표현, 전환 경로입니다. 관리자 백엔드는 내부 직원을 대상으로 하며, 추구하는 것은 데이터 정확성, 운영 효율, 명확한 권한입니다. 두 가지는 목표가 다르기 때문에 하나의 프로젝트에 억지로 밀어 넣으면 결국 공식 웹사이트는 지연되고 백엔드는 미완성품이 되기 쉽습니다.
아래에서는 실제 프로젝트 진행 순서에 따라 이 문제를 나누어 설명하겠습니다.
먼저 두 개의 라인을 구분하라: 전시 라인과 비즈니스 라인
기획의 첫 단계는 페이지를 그리는 것이 아니라 경계를 나누는 것입니다.
공식 웹사이트는 전시 라인에 속하며, 핵심은 콘텐츠 표현과 리드 확보입니다. 관리자 백엔드는 비즈니스 라인에 속하며, 핵심은 데이터 입력, 심사, 통계입니다. 이 두 라인은 하나의 도메인과 하나의 계정 체계를 공유할 수 있지만, 코드 구조, 반복 주기, 검수 기준은 분리되어야 합니다.
흔한 잘못된 방식은 백엔드를 공식 웹사이트의 부속 기능으로 취급하여, 먼저 공식 웹사이트를 만들고 백엔드는 "겸사겸사 몇 개 페이지 추가"하는 것입니다. 그 결과 백엔드에는 독립적인 데이터 모델 설계가 없고, 필드는 전부 임시로 추가되며, 3개월 후에는 아무도 감히 수정하지 못하게 됩니다.
더 안정적인 방식은 먼저 백엔드의 데이터 구조를 정하고, 공식 웹사이트가 그 데이터를 소비하도록 하는 것입니다. 예를 들어 공식 웹사이트의 제품 페이지, 뉴스 페이지, 사례 페이지의 콘텐츠는 모두 백엔드에서 입력하고, 프론트는 표시만 담당합니다. 이렇게 하면 공식 웹사이트를 개편할 때 백엔드를 건드릴 필요가 없고, 백엔드에 필드를 추가할 때 공식 웹사이트도 자동으로 따라갈 수 있습니다.
데이터 모델을 먼저 정하고, 페이지는 나중에 그려라
이것은 전체 웹사이트 개발에서 가장 쉽게 건너뛰면서도 가장 비용이 많이 드는 단계입니다.
구체적인 시나리오를 들어보겠습니다. 장비 판매를 하는 기업이 공식 웹사이트와 관리자 백엔드 시스템을 구축하려고 합니다. 백엔드에서는 제품 분류, 제품 파라미터, 대리점 정보, 견적 문의 기록을 관리해야 합니다. 처음부터 페이지를 기준으로 프로토타입을 그리면 "제품 목록 페이지", "제품 상세 페이지" 같은 페이지 수준 설계가 되기 쉽고, 나중에 파라미터가 분류에 따라 달라져야 한다는 것을 발견하면 수정은 곧 재작업이 됩니다.
올바른 순서는 먼저 엔티티를 나열하는 것입니다. 제품, 분류, 파라미터 항목, 대리점, 견적 문의서, 각 엔티티에 어떤 필드가 있고 서로 어떤 관계인지. 이것을 표 구조도로 그린 후 페이지를 논의합니다.
데이터 모델을 잘못 정하면 이후 모든 페이지가 재작업입니다. 이 단계에서 2~3일을 더 쓰면 이후 2주간의 분쟁을 줄일 수 있습니다.
권한과 계정 체계는 처음부터 여지를 남겨라
백엔드에서 나중에 요구사항을 추가하기 가장 쉬운 부분이 권한입니다.
처음에는 관리자와 일반 직원 두 가지 역할만 있을 수 있지만, 출시 반년 후에는 "지역 매니저는 본인 지역 데이터만 볼 수 있다", "재무는 주문 금액만 볼 수 있고 상태는 변경할 수 없다" 같은 요구사항이 생깁니다. 계정 체계가 처음부터 고정된 2단계 역할이라면, 이후 역할을 추가할 때마다 코드를 수정해야 합니다.
웹사이트 개발 단계에서 역할 + 권한 포인트 구조로 만드는 것을 권장합니다. 권한 포인트는 모듈별로 나누며, 예를 들어 제품 관리, 주문 조회, 데이터 내보내기 등입니다. 역할은 권한 포인트를 자유롭게 조합할 수 있습니다. 이렇게 하면 이후 역할 추가는 설정만 하면 되고 배포할 필요가 없습니다.
공식 웹사이트 쪽도 미리 명확히 생각해야 합니다. 회원 로그인이 필요한지, 백엔드 계정과 연동해야 하는지. 공식 웹사이트에 예약, 신청 같은 기능이 있다면 사용자 데이터와 백엔드 고객 데이터가 동일한 체계인지 두 개인지, 이 결정은 미니프로그램 개발과 App 개발 단계에서 재사용할 수 있는지에 영향을 미칩니다.
일정은 끝까지 병렬로 하지 말고, 시차를 두고 납품하라
많은 프로젝트가 실패하는 이유는 만들지 못해서가 아니라 검수 리듬이 흐트러졌기 때문입니다.
공식 웹사이트와 백엔드를 동시에 개발하고 동시에 납품한다는 것은 같은 시점에 완전히 다른 두 가지를 검수해야 한다는 뜻입니다. 테스트 리소스가 부족하고 문제가 쌓이며, 어느 단계의 책임인지 아무도 명확히 말할 수 없습니다.
더 현실적인 일정은 백엔드가 먼저 사용 가능한 버전을 내놓고, 공식 웹사이트가 나중에 연결하는 것입니다. 백엔드에서 콘텐츠 관리와 핵심 비즈니스 프로세스를 먼저 돌리고, 공식 웹사이트는 실제 데이터에 직접 연결하여 페이지를 만듭니다. 이렇게 하면 공식 웹사이트 검수 시 가짜 데이터가 아닌 실제 데이터를 보게 되어 문제가 더 일찍 드러납니다.
시간이 촉박하다면 반대로 할 수도 있습니다. 공식 웹사이트는 정적 버전을 먼저 출시하여 대외 전시를 보장하고, 백엔드는 두 차례에 나누어 납품합니다. 다만 주의할 점은, 정적 버전 출시 후 반드시 언제 백엔드를 연결할지 명확히 해야 합니다. 그렇지 않으면 장기적으로 두 세트의 콘텐츠를 유지하게 되기 쉽습니다.
보안과 테스트, 마지막까지 미루지 마라
백엔드는 내부 데이터를 다루므로 보안 테스트를 출시 일주일 전에야 해서는 안 됩니다.
기본 항목에는 로그인 실패 횟수 제한, 권한 우회 접근 테스트, 파일 업로드 유형 검증, 인터페이스 파라미터 검증이 포함됩니다. 이러한 것들은 개발 단계에서 하면 비용이 매우 낮지만, 출시 후에 보완하려면 아키텍처를 수정해야 합니다. 백엔드에 외부 인터페이스가 있다면 역방향 테스트도 한 차례 수행하여 인터페이스가 우회될 수 있는지, 파라미터가 변조될 수 있는지 확인해야 합니다.
공식 웹사이트 쪽은 폼 제출과 파일 업로드를 중점적으로 봐야 합니다. 많은 기업 웹사이트가 스팸 견적 문의로 가득 차는 것은 폼에 기본 검증이 없기 때문입니다.
어떤 경우에 MIC Studio를 찾는 것이 적합한가
팀에 전담 백엔드와 프론트엔드가 없거나, 있지만 일정을 맞출 수 없다면 공식 웹사이트와 백엔드를 함께 외부 팀에 맡기는 것이 합리적입니다.
적합한 경우는 대략 다음과 같습니다. 요구사항이 이미 비교적 명확하고, 어떤 데이터를 관리해야 하는지, 공식 웹사이트에서 무엇을 전시해야 하는지 알고 있는 경우. 백엔드와 공식 웹사이트가 동일한 데이터를 사용하고 두 세트의 콘텐츠를 유지하고 싶지 않은 경우. 향후 미니프로그램 개발이나 App 개발을 계획하고 있어 기본 인터페이스를 재사용하고 싶은 경우.
덜 적합한 경우는 요구사항이 아직 계속 변하고 있고, 어떤 필드를 관리해야 하는지조차 명확히 생각하지 못한 경우입니다. 이런 단계에서는 바로 개발하는 것보다 요구사항 정리를 먼저 하는 것이 더 경제적입니다.
MIC Studio는 이런 프로젝트에서 먼저 데이터 구조와 권한 설계를 제시하고, 확인 후 페이지와 인터페이스 개발로 넘어가며, 기업 웹사이트와 백엔드를 동시에 추진하되 검수는 분리하여 진행합니다.
세 가지 실행 가능한 제안
첫째, 착수 시 먼저 한 페이지의 데이터 목록을 작성하세요. 백엔드에서 관리할 모든 엔티티와 필드를 나열하세요. 그림을 그릴 필요 없이 글로 명확히 나열하면 됩니다. 이 한 장의 종이가 이후 요구사항 변경의 절반을 막아줍니다.
둘째, 공식 웹사이트와 백엔드를 분리하여 검수하세요. 백엔드가 먼저 비즈니스 프로세스를 돌리고, 공식 웹사이트가 실제 데이터에 연결되도록 하세요. 양쪽이 모두 끝난 후 함께 테스트하지 마세요.
셋째, 권한과 보안은 개발 단계에서 하세요. 역할 권한 포인트 구조, 인터페이스 검증, 로그인 제한은 출시 전 마무리 작업이 아니라 아키텍처의 일부입니다.
공식 웹사이트와 백엔드를 함께 만드는 것은 문제없습니다. 문제는 그것들을 두 개의 것으로 계획했는지 여부입니다.