많은 대표님들이 프로젝트를 시작할 때 이렇게 말합니다. 공식 웹사이트와 백엔드를 함께 만들면 편하다고요.
듣기에는 합리적이지만, 실제로 진행하면 가장 흔히 세 가지 상황이 발생합니다. 공식 웹사이트가 먼저 오픈했는데 백엔드는 아직 수정 중이거나, 백엔드 필드가 바뀌자 공식 웹사이트 페이지 전체를 다시 작업해야 하거나, 양쪽을 각각 다른 사람에게 맡겨 API가 맞지 않아 서로 기다리게 되는 경우입니다.
문제는 “함께 구축하는 것”이 아니라 계획 순서가 없다는 것에 있습니다. 아래에서는 실제 프로젝트 경험을 바탕으로 이 일을 풀어 설명하겠습니다.
먼저 백엔드의 데이터를 정하고, 그다음 공식 웹사이트의 페이지를 정한다
공식 웹사이트는 표현 계층이고, 관리자 백엔드는 데이터 계층입니다. 순서가 뒤바뀌면 재작업은 거의 불가피합니다.
구체적인 장면을 예로 들어보겠습니다. 산업 장비 회사가 공식 웹사이트를 개편하면서 동시에 백엔드를 만들어 영업 담당자가 제품 파라미터, 사례, 뉴스를 직접 업데이트하도록 하려 한다고 가정해 봅시다. 먼저 공식 웹사이트 첫 페이지를 그리고 나서 백엔드에 어떻게 입력할지 생각하면, 흔히 백엔드 필드가 매우 임의적으로 설계됩니다. 예를 들어 “제품 특징”에 리치 텍스트 상자 하나만 두었는데 공식 웹사이트에서는 세 개를 나란히 보여주고 싶어 하면, 결국 편집자가 수동으로 레이아웃을 잡아야 하고 반년 뒤에는 콘텐츠가 엉망이 됩니다.
더 안정적인 방법은 먼저 콘텐츠 모델을 나열하는 것입니다. 제품에는 어떤 필드가 있는지, 사례는 어떤 제품과 연결되는지, 뉴스에 분류가 필요한지, 이미지에 여러 사이즈가 필요한지 등입니다. 필드가 정해지면 공식 웹사이트의 페이지 구조는 자연스럽게 나옵니다.
주의할 점: 백엔드 필드를 데이터베이스 필드와 그대로 동일하게 만들지 마세요. 편집자가 보는 필드명은 이해하기 쉬운 말로 해야 하고, 기술 필드는 별도로 저장해야 합니다. 그렇지 않으면 운영 담당자는 두 번 입력하다가 유지보수를 포기하게 됩니다.
API를 먼저 정하고, 양쪽이 다 끝난 뒤 연동하지 말 것
공식 웹사이트와 백엔드를 동시에 개발할 때 가장 큰 시간 낭비는 연동 작업입니다.
개발 첫 주에 API 문서를 정하는 것을 권장합니다. 비록 종이 위의 약속이라도 목록 API가 무엇을 반환하는지, 페이지네이션 파라미터 이름은 무엇인지, 이미지 주소는 상대 경로인지 전체 URL인지 정해야 합니다. 프런트엔드는 가짜 데이터로 페이지를 먼저 동작시키고, 백엔드는 같은 약속에 맞춰 출력할 수 있습니다.
여기서 놓치기 쉬운 세부 사항이 있습니다. 공식 웹사이트와 미니프로그램 개발은 종종 같은 API 세트를 공유합니다. 기업이 이후 예약 미니프로그램도 만들 계획이라면, 백엔드 API 설계에서 모바일용 필드 축소를 미리 고려해야 합니다. PC용 대형 필드를 전부 반환하지 마세요. App 개발도 마찬가지입니다. API 버전 번호를 처음부터 넣어두면 이후 변경이 훨씬 수월해집니다.
주의할 점: API 필드 이름에 중국어와 영어를 섞지 말고, 하나의 API에 세 가지 용도를 넣지 마세요. API가 두 개 더 늘어나더라도 만능 API 하나를 만들지 않는 편이 낫습니다.
권한과 배포 프로세스는 첫 버전에서 명확히 정해야 한다
관리자 백엔드에는 관리자 역할만 있는 것이 아닙니다.
실제 프로젝트에서 흔한 역할은 최소한 슈퍼 관리자, 콘텐츠 편집자, 영업 또는 지역 책임자입니다. 첫 버전에서 계정 하나만 만든다면, 나중에 권한을 추가할 때 데이터 테이블을 수정해야 하므로 처음부터 설계하는 비용보다 훨씬 커집니다.
배포 프로세스도 같습니다. 공식 웹사이트 콘텐츠가 검토 후 게시되어야 하는지, 뉴스 게시에 초안이 필요한지 등은 “나중에 논의할” 기능이 아니라 테이블 구조에 영향을 주는 요소입니다.
실행 가능한 방법은 콘텐츠 테이블에 상태 필드(초안, 검토 대기, 게시됨)를 추가하고, 역할 테이블에 작업 범위를 추가하는 것입니다. 첫 버전에서는 두 개 역할만 열어두더라도 구조는 미리 준비해 두세요.
주의할 점: 권한을 페이지 안에 하드코딩하지 마세요. 프런트엔드에서 버튼을 숨기는 것은 권한 제어가 아닙니다. API 계층에서 반드시 검증해야 합니다. 기업 웹사이트가 문의와 고객 정보를 다루는 경우에는 특히 중요합니다.
출시 일정은 두 단계로 나누고, 한 번의 배포에 묶지 말 것
공식 웹사이트와 백엔드를 함께 구축한다고 해서 함께 출시해야 하는 것은 아닙니다.
더 안정적인 일정은 백엔드를 먼저 출시해 콘텐츠 입력을 정상화하고, 공식 웹사이트를 이후에 배포해 실제 데이터로 채우는 것입니다. 이렇게 하면 공식 웹사이트가 처음 공개될 때 콘텐츠가 완성된 상태가 되고, 출시 후에 보충하지 않아도 됩니다.
시간이 촉박하다면 공식 웹사이트의 정적 버전을 먼저 올리고 백엔드를 병행 개발한 뒤, 둘째 주에 데이터 소스를 전환할 수도 있습니다. 전제는 페이지 구조가 앞서 정한 콘텐츠 모델에 맞춰져 있어 전환 시 레이아웃을 바꾸지 않아도 되는 것입니다.
주의할 점: 출시 전에 보안 테스트 시간을 확보하세요. 기업 웹사이트는 폼 제출과 백엔드 로그인을 다루므로 흔한 인젝션, 권한 우회, 취약한 비밀번호 문제를 점검해야 합니다. 이 작업량은 웹사이트 개발 자체와 별개이므로 계획에서 빠뜨리지 마세요.
어떤 경우에 MIC Studio를 찾는 것이 적합한가
팀에 안정적인 프런트엔드와 백엔드 인력이 있다면 위 순서대로 자체 일정을 잡으면 되고, 외부 개입은 필요 없습니다.
하지만 다음 경우에는 외부 팀을 찾는 것이 시간을 더 아낄 수 있습니다. 첫째, 공식 웹사이트 개편과 백엔드를 동시에 시작하는데 내부에 담당자가 한 명뿐이라 요구사항과 일정을 연결해 줄 사람이 필요한 경우. 둘째, 기존 시스템에 미니프로그램 개발이나 App 개발을 추가해야 하고 API를 재사용해야 해서 누군가 먼저 데이터 구조를 정리해야 하는 경우. 셋째, 출시 전에 웹사이트 보안 테스트나 리버스 테스트가 필요한데 내부에 해당 경험이 없는 경우입니다.
MIC Studio는 이런 프로젝트를 맡을 때 보통 먼저 요구사항 정리와 필드 목록 작성 라운드를 진행한 뒤 웹사이트 개발 일정에 들어가며, 진행하면서 수정하는 일을 피합니다. 순위를 약속하지 않고 과장된 홍보도 하지 않으며, 경계와 공기를 명확히 설명하는 것이 더 중요합니다.
실행 가능한 세 가지 제안
1. 프로젝트 첫 주에는 콘텐츠 모델과 역할 목록을 먼저 산출하고, 그다음 페이지를 그리세요. 필드가 정해지지 않았다면 디자인 시안을 서두르지 마세요.
2. API 문서와 프런트엔드 가짜 데이터를 동시에 시작하면 연동 시간을 절반 이상 줄일 수 있습니다.
3. 출시는 백엔드 선행, 공식 웹사이트 후속으로 나누고, 그 사이에 보안 테스트와 콘텐츠 채우기 시간을 두세요.
이 세 가지를 마치면 공식 웹사이트와 관리자 백엔드를 함께 구축하는 일은 더 이상 리스크가 아니라 비용을 아끼는 선택이 됩니다.