많은 기업이 공식 웹사이트를 만들 때 "백엔드도 같이 만들자"라고 가볍게 말합니다. 듣기에는 자연스러운 일처럼 보이지만, 실제로 진행하다 보면 두 가지 요구사항이 서로 충돌하는 경우가 많습니다.
공식 웹사이트는 보기 좋고, 빨라야 하며, 검색 엔진에 노출되어야 합니다. 관리자 백엔드는 콘텐츠를 수정하고, 데이터를 확인하고, 권한을 나눌 수 있어야 합니다. 둘은 같은 데이터를 공유하지만 전혀 다른 사용자를 위한 것입니다. 계획이 제대로 되지 않으면 가장 흔한 결과는 다음과 같습니다. 공식 웹사이트가 먼저 오픈하고, 백엔드에서 필드 하나를 바꾸면 프론트엔드가 전부 무너지거나, 백엔드는 완성되었는데 공식 웹사이트의 콘텐츠 구조와 전혀 맞지 않는 경우입니다.
이 글에서는 실제 프로젝트 순서에 따라 웹사이트 개발에서 공식 웹사이트와 백엔드를 함께 구축하는 계획을 명확히 설명합니다.
먼저 두 가지 라인을 구분하세요: 전시 로직과 편집 로직
공식 웹사이트는 전시 로직이고, 백엔드는 편집 로직입니다. 이 두 라인은 분리해서 설계해야 하지만, 하나의 데이터 모델을 공유합니다.
구체적인 방법은 먼저 콘텐츠 모델을 정하고, 그다음 페이지를 정하는 것입니다. 예를 들어 기업 공식 웹사이트에서 흔한 섹션은 뉴스, 제품, 사례, 채용입니다. 각 섹션에 어떤 필드가 있는지, 어떤 필드가 필수인지, 이미지 크기는 얼마인지, 다국어를 지원하는지 등을 페이지를 그리기 전에 정해야 합니다.
주의할 점: 백엔드가 페이지 모듈에 직접 대응되도록 만들지 마세요. 많은 프로젝트에서 백엔드를 '홈페이지 첫 화면 문구', '홈페이지 두 번째 화면 이미지' 식으로 만들었다가, 공식 웹사이트가 개편되면서 백엔드가 전부 무용지물이 되는 경우가 있습니다. 올바른 방법은 백엔드는 콘텐츠를 관리하고, 페이지는 표현을 관리하며, 그 사이를 필드 매핑으로 연결하는 것입니다.
또 다른 함정은 권한입니다. 백엔드에는 최소한 관리자, 편집자, 읽기 전용의 세 가지 역할이 있어야 합니다. 이는 기업 웹사이트 프로젝트에서 자주 간과되는 부분으로, 오픈 후에야 인턴이 데이터를 삭제할 수 있다는 사실을 발견하게 됩니다.
일정상 백엔드가 공식 웹사이트보다 먼저 데이터 계층을 완성해야 합니다
비교적 안정적인 순서는 데이터 모델 → 백엔드 인터페이스 → 백엔드 화면 → 공식 웹사이트 페이지입니다.
공식 웹사이트 페이지는 실제 데이터에 의존합니다. 백엔드가 아직 작동하지 않으면 프론트엔드는 가짜 데이터로만 작업할 수 있고, 연동 단계에서 문제가 집중적으로 터집니다. 먼저 백엔드에서 입력, 수정, 올바른 구조 반환이 가능하도록 만든 후 공식 웹사이트를 연동하면 재작업량이 훨씬 줄어듭니다.
구체적인 예를 들어보겠습니다. 장비 임대 회사가 공식 웹사이트에서 장비 목록과 온라인 예약을 보여주고, 백엔드에서 장비 정보, 예약 기록, 상태 전환을 관리한다고 가정해 봅시다. 공식 웹사이트를 먼저 만들면 예약 양식의 필드와 백엔드의 기록 구조가 쉽게 맞지 않을 수 있습니다. 예를 들어 공식 웹사이트에서는 '희망 임대 기간'을 수집했는데 백엔드에는 '시작일'만 저장되는 경우입니다. 이런 문제는 연동 단계에서야 발견되며, 수정하려면 데이터베이스를 건드려야 합니다.
따라서 일정상 백엔드에 최소 3분의 1의 선행 시간을 확보해야 하며, 공식 웹사이트의 부속물로 취급해서는 안 됩니다.
인터페이스를 먼저 약속하세요, 페이지를 다 그린 후에 논의하지 마세요
공식 웹사이트와 백엔드 사이는 인터페이스 관계입니다. 인터페이스의 필드명, 타입, 페이지네이션 방식, 오류 코드는 개발 전에 간단한 문서로 작성하는 것이 좋습니다.
너무 격식 있을 필요는 없고, 한 페이지 표로 충분합니다. 인터페이스 경로, 입력 파라미터, 반환 예시, 예외 상황을 정리하면 됩니다. 이것만으로도 많은 구두 커뮤니케이션을 줄일 수 있습니다.
주의할 점: 이미지 업로드입니다. 공식 웹사이트와 백엔드 모두 이미지를 처리하지만 요구사항이 다릅니다. 공식 웹사이트는 압축, CDN, 지연 로딩이 필요하고, 백엔드는 원본 이미지, 자르기, 정렬이 필요합니다. 업로드 로직은 하나의 서비스로 통일하는 것이 좋으며, 양쪽에 각각 따로 작성하지 마세요.
검색과 필터링도 마찬가지입니다. 백엔드의 필터 조건은 공식 웹사이트보다 복잡한 경우가 많습니다. 인터페이스 설계 시 공식 웹사이트만 고려하면 백엔드에 별도의 쿼리를 추가해야 합니다. 필터 파라미터를 미리 조합 가능하도록 설계하면 나중에 편합니다.
보안과 관리자 진입점은 별도로 고려해야 합니다
백엔드는 공격 표면이 가장 큰 곳입니다. 웹사이트 개발에서 자주 건너뛰는 단계가 바로 백엔드 보안 테스트입니다.
최소한 해야 할 일은 다음과 같습니다. 백엔드 로그인에 캡차와 로그인 실패 제한 추가, 관리자 비밀번호 복잡도 강제, 인터페이스 권한 검증(프론트엔드에서 메뉴를 숨기는 것만으로는 안 됨), 작업 로그 기록.
미니프로그램 개발이나 App 개발 프로젝트라면 백엔드가 여러 클라이언트와 연동해야 하는 경우가 많아 권한 모델이 더 복잡해집니다. 이때는 백엔드를 '콘텐츠 관리'와 '비즈니스 관리' 두 부분으로 나누어, 전자는 운영팀에, 후자는 비즈니스 담당자에게 제공하여 오조작을 줄이는 것이 좋습니다.
주의할 점: 공식 웹사이트와 동일한 계정 체계로 백엔드를 관리하지 마세요. 프론트엔드 사용자와 관리자는 반드시 두 개의 테이블, 두 개의 로그인 로직이어야 합니다.
검수 기준은 미리 작성하세요, 오픈 전에 생각하지 마세요
공식 웹사이트의 검수는 로딩 속도, 모바일 대응, SEO 기본 항목(제목, 설명, 구조화 데이터)을 봅니다. 백엔드의 검수는 세 가지를 봅니다. 완전한 입력이 가능한지, 공식 웹사이트에 올바르게 표시되는지, 권한이 올바른지입니다.
검수 체크리스트를 작성하여 각 항목에 실행 가능한 점검 동작을 대응시키는 것이 좋습니다. 예를 들어 '뉴스 하나를 추가하면 공식 웹사이트 목록 페이지에 1분 이내에 나타난다', '편집자 역할은 데이터를 삭제할 수 없다', '이미지 업로드 후 공식 웹사이트 표시가 300KB를 초과하지 않는다' 등입니다.
체크리스트는 프로젝트 시작 시 개발팀과 정렬하는 것이 오픈 전에 임시로 요구하는 것보다 훨씬 효과적입니다.
어떤 경우에 MIC Studio를 찾는 것이 적합한가
팀에 전담 백엔드 개발자가 없거나, 공식 웹사이트와 백엔드를 동시에 특정 시점에 맞춰야 한다면 일부를 외주로 맡기는 것이 합리적입니다. MIC Studio는 기업 웹사이트와 백엔드 통합 개발을 할 때 보통 먼저 고객의 콘텐츠 모델과 인터페이스 약속을 정리한 후 개발에 들어갑니다.
저희를 찾는 것이 적합한 경우: 공식 웹사이트 개편과 백엔드 재구성이 동시에 필요한 경우, 예약이나 신청 같은 비즈니스 흐름이 있는 공식 웹사이트, 백엔드가 미니프로그램이나 App 등 멀티 클라이언트 프로젝트와 연동해야 하는 경우입니다. 단순히 문구 몇 줄을 수정하는 것이라면 전체 프로젝트 프로세스를 거칠 필요는 없습니다.
세 가지 실행 가능한 제안
첫째, 시작 전에 한 페이지 분량의 콘텐츠 모델을 작성하여 섹션, 필드, 필수 항목을 정하고 공식 웹사이트와 백엔드 모두 이에 따르도록 하세요.
둘째, 일정상 백엔드의 데이터 계층이 먼저 작동하도록 하고, 공식 웹사이트가 실제 인터페이스와 연동하게 하여 연동 재작업을 줄이세요.
셋째, 오픈 전에 백엔드 보안 점검과 권한 테스트를 한 번 수행하고, 문제가 생긴 후에 보완하지 마세요.