프로젝트 문의
메뉴

이벤트 페이지 제작, 매번 개발 요청 없이 빠르게 여는 구조

발행

요약

이벤트 페이지가 매번 개발 요청이 되는 이유는 페이지를 한 장씩 코드로 새로 만들기 때문입니다. 반복되는 부분을 섹션 템플릿으로 묶고 문구, 일정, 이미지를 설정 파일이나 CMS 항목으로 빼면 두 번째 이벤트부터는 마케팅팀이 입력하고 미리보기로 검수한 뒤 예약 시각에 공개할 수 있습니다. 개발은 이벤트마다 시그니처 연출 하나에만 씁니다.

이벤트 페이지가 매번 개발 요청이 되는 이유는 페이지를 한 장씩 코드로 새로 만들기 때문입니다. 반복되는 부분을 섹션 템플릿으로 묶고, 문구와 일정과 이미지를 설정 파일이나 CMS 항목으로 빼면 두 번째 이벤트부터는 개발 없이 열 수 있습니다. 마케팅팀이 내용을 입력하고, 미리보기 링크로 검수하고, 예약한 시각에 공개합니다. 개발팀은 이벤트마다 시그니처 연출 하나에만 시간을 씁니다.

왜 이벤트 페이지마다 개발 요청이 생기나

규모가 있는 회사일수록 이벤트 페이지가 개발 대기열에 쌓입니다. 원인은 대개 네 가지입니다.

페이지가 코드에 박혀 있습니다

문구, 날짜, 이미지 경로가 페이지 코드 안에 직접 적혀 있으면 오탈자 하나를 고칠 때도 개발자가 필요합니다. 마케팅팀이 바꾸고 싶은 것은 내용인데, 내용과 코드가 한 파일에 섞여 있어서 생기는 일입니다.

공통 레이아웃이 없습니다

이벤트마다 디자인 시안을 새로 받고 처음부터 구현하면, 지난 이벤트에서 만든 일정표와 혜택 목록을 다시 만듭니다. 비슷한 화면을 매번 새로 짜니 일정도 매번 비슷하게 걸립니다.

추적 코드와 신청 폼을 매번 다시 연결합니다

분석 태그, 광고 전환 태그, 신청 폼과 저장소 연결을 페이지마다 따로 붙이면 빠뜨리기 쉽습니다. 이벤트가 끝난 뒤 "신청 버튼 클릭이 집계되지 않았다"는 사실을 알게 되는 경우가 여기서 나옵니다.

검수와 배포 대기열을 함께 탑니다

이벤트 페이지 수정도 일반 기능 개발과 같은 리뷰와 배포 절차를 거치면, 하루짜리 문구 변경이 다음 배포 일정까지 기다립니다.

호스팅형 사이트 빌더로 이벤트 페이지를 따로 만드는 방법도 있습니다. 첫 페이지는 빠르지만 본 사이트와 디자인, 도메인 경로, 분석 설정이 분리되기 쉽고, 빌더가 제공하는 블록 밖의 연출이 필요해지면 다시 개발 요청으로 돌아옵니다.

해법은 페이지가 아니라 틀을 만드는 것입니다

재사용 섹션을 몇 개만 정합니다

이벤트 페이지는 생각보다 구성이 비슷합니다. 히어로, 일정, 혜택, 신청 폼, 유의사항 다섯 칸이면 대부분을 덮습니다. 이 다섯 섹션을 컴포넌트로 만들고, 템플릿 하나에 슬롯으로 배치합니다. 섹션 수를 늘리기보다 각 섹션의 선택지를 두세 가지로 두는 편이 관리하기 쉽습니다.

내용은 코드 밖으로 뺍니다

문구, 날짜, 이미지, 버튼 문구는 설정 파일이나 CMS 항목 하나에 모읍니다. 새 이벤트는 이 항목을 하나 더 만드는 일이 됩니다.

slug: spring-showcase   # 이벤트 한 건의 설정 예시, 값은 자리표시자
open_at: "2027-03-02T10:00:00+09:00"
close_at: "2027-03-20T23:59:00+09:00"
hero:
  title: "봄 신제품 체험전"
  variant: signature   # 이 이벤트만의 맞춤 연출
schedule:
  - { date: "2027-03-21", label: "오프라인 체험" }
benefits: ["사전 신청자 안내 자료", "현장 상담"]
form: signup-basic
notice: "신청 정보는 행사 안내에만 사용합니다."

미리보기 링크로 검수합니다

공개 전에 내용을 입력하면 바로 확인할 수 있는 미리보기 주소가 있어야 합니다. 검수자는 개발 환경 없이 링크만 열어 모바일과 데스크톱 화면을 확인합니다. 미리보기 주소는 검색에 노출되지 않게 막아 둡니다.

예약 공개와 자동 종료를 둡니다

open_at과 close_at을 정해 두면 공개 시각에 맞춰 누군가 배포 버튼을 누를 필요가 없습니다. 종료 시각이 지나면 신청 폼이 닫히고 종료 안내로 바뀌게 하면, 마감 이후 신청이 들어오는 일도 막습니다.

분석 이벤트를 공통으로 정합니다

페이지 조회, 히어로 통과, 신청 시작, 신청 완료처럼 측정할 이벤트 이름을 한 번 정하고 템플릿에 심어 둡니다. 모든 이벤트 페이지가 같은 이름으로 집계되니 이벤트끼리 비교할 수 있고, 태그를 빠뜨릴 일도 없습니다.

맞춤으로 남기는 것은 한 가지입니다

틀을 쓰면 페이지가 비슷해질까 걱정하는 경우가 많습니다. 방문자가 기억하는 것은 대개 한 장면입니다. 그래서 이벤트마다 시그니처 순간 하나에만 개발 시간을 씁니다. 작업 사례를 하나 들면, K뷰티와 AI를 주제로 한 살롱의 이벤트 페이지는 420vh 길이의 스크롤 히어로에서 종이가 찢어지며 three.js로 만든 한옥 갤러리 장면이 열리고, 신청은 같은 페이지에서 받습니다. 이런 장면이 맞춤으로 만들 한 가지이고, 일정과 혜택과 폼은 반복되는 칸입니다.

무거운 연출을 얹을 때는 속도 지표를 같이 봅니다. web.dev는 LCP를 뷰포트에 보이는 가장 큰 이미지, 텍스트 블록, 영상의 렌더 시간으로 정의하고, 75번째 백분위수 기준 2.5초 이하를 목표로 제시합니다. 이미지, 영상 포스터, 텍스트 블록이 LCP 후보이므로 첫 화면에는 제목 텍스트나 포스터 이미지를 먼저 보여 주고 3D 장면은 그 뒤에 불러오는 구성이 안전합니다.

세 가지 방식 비교

기준 호스팅형 사이트 빌더 페이지 매번 새로 개발 템플릿 시스템
첫 페이지 속도 빠름 느림 느림 (틀을 함께 만듦)
열 번째 페이지 속도 보통 (매번 블록 조립) 느림 (매번 처음부터) 빠름 (항목 입력)
디자인 자유도 빌더 블록 범위 안 높음 섹션 범위 안 + 맞춤 연출 1개
수정 주체 마케팅팀 개발팀 마케팅팀 (연출은 개발팀)
SEO 제어 빌더가 허용하는 범위 전부 가능 템플릿에 한 번 설정

이벤트를 1년에 한두 번 연다면 빌더나 단건 개발로 충분할 수 있습니다. 여러 번 연다면 템플릿 시스템이 누적으로 빠릅니다.

이벤트 페이지의 검색 기본

Google의 Event 구조화 데이터는 이벤트를 찾고 참석하기 쉽게 보여 주는 기능에 쓰입니다. 필수 속성은 name, startDate(ISO 8601 형식), location(장소 이름과 주소)입니다. 조건이 있습니다. 실제 장소에서 열리는 행사여야 하고, 기간 한정 판매나 "지금 구매하세요" 같은 구매 유도, 쿠폰과 상품권은 대상이 아니며, 오프라인 요소가 없는 온라인 행사도 지원하지 않습니다. 할인 프로모션 페이지에는 이 마크업을 넣지 않습니다.

행사가 취소되면 마크업을 지우지 않고 기존 값을 그대로 둔 채 eventStatus만 EventCancelled로 바꾸라고 안내합니다. 연기되어 새 날짜가 정해지지 않았다면 원래 startDate를 유지하고 EventPostponed를 씁니다.

종료 시각이 정해진 페이지에는 robots 메타 태그의 unavailable_after를 쓸 수 있습니다. 지정한 날짜 이후 검색 결과에 해당 페이지를 보여 주지 말라는 규칙이며, 날짜는 ISO 8601 같은 널리 쓰이는 형식이어야 하고 형식이 틀리면 무시됩니다. 종료 후에도 페이지를 기록으로 남길 계획이라면 이 규칙은 넣지 않습니다.

이벤트가 끝난 뒤 페이지 처리

종료된 페이지는 세 갈래로 정리합니다.

  • 유지: 매년 다시 여는 행사라면 같은 주소에 종료 안내와 다음 일정 알림 신청을 둡니다. 신청 폼은 닫습니다.
  • 리디렉션: 후속 행사나 상시 페이지처럼 이어지는 내용이 있으면 서버에서 301로 보냅니다. Google은 301 같은 영구 리디렉션을 대상 페이지가 대표 URL이라는 신호로 쓰고 검색 결과에 새 주소를 보여 줍니다. 302 같은 임시 리디렉션은 원래 주소를 보여 줍니다.
  • 삭제: 남길 이유가 없으면 404나 410을 반환합니다. Google은 429를 제외한 4xx 응답을 같은 방식으로 다루며, 이미 색인된 URL이라면 색인에서 제거합니다. 빈 페이지나 오류 문구를 200 응답으로 보여 주면 Search Console에서 soft 404로 표시됩니다.

템플릿에 종료 후 처리 방식을 선택 항목으로 넣어 두면 이벤트마다 개발자에게 다시 묻지 않아도 됩니다.

맡기기 전에 준비할 것

  • 1년 동안 열 이벤트의 종류와 대략의 횟수
  • 매번 바뀌는 항목과 고정 항목 목록 (히어로, 일정, 혜택, 폼, 유의사항 기준)
  • 페이지를 직접 입력하고 공개할 담당자와 검수자
  • 신청 데이터를 받을 곳 (CRM, 스프레드시트, 메일)과 개인정보 동의 문구
  • 측정할 분석 이벤트 이름과 광고 전환 태그 목록
  • 지난 이벤트 페이지 두세 개와 좋았던 점, 아쉬웠던 점
  • 종료 후 처리 원칙 (유지, 리디렉션, 삭제)

업체에 물어볼 질문

  • 새 이벤트를 열 때 개발자 없이 할 수 있는 일과 개발자가 필요한 일을 나눠서 알려 줄 수 있나요?
  • 내용은 어디에서 입력하나요? 설정 파일인가요, CMS 항목인가요?
  • 미리보기 링크와 예약 공개, 자동 종료가 기본으로 들어가나요?
  • 분석 이벤트와 전환 태그는 템플릿에 한 번 넣나요, 페이지마다 넣나요?
  • 시그니처 연출을 넣을 때 LCP 같은 속도 기준을 어떻게 검수하나요?
  • 이벤트가 끝난 페이지는 어떤 방식으로 처리하도록 설계하나요?
  • 템플릿에 섹션을 추가할 때는 어떤 절차와 비용 기준이 적용되나요?

이 질문에 구체적으로 답하는 업체라면 첫 페이지만이 아니라 열 번째 페이지까지 생각하고 있는 곳입니다.

출처

자주 묻는 질문

이벤트 페이지는 호스팅형 사이트 빌더로 만드는 편이 가장 빠르지 않나요?

첫 페이지는 빠른 경우가 많습니다. 다만 브랜드 사이트와 디자인, 도메인 경로, 분석 설정이 따로 놀기 쉽고, 빌더 블록 밖의 연출이 필요해지면 결국 개발 요청으로 돌아옵니다. 이벤트를 1년에 여러 번 연다면 템플릿 구조를 한 번 만드는 쪽이 누적으로 빠릅니다.

템플릿으로 만들면 이벤트마다 페이지가 다 비슷해 보이지 않나요?

섹션 순서와 폼 구조는 같아도 됩니다. 방문자가 기억하는 것은 히어로 연출, 색, 사진 같은 한두 가지입니다. 이벤트마다 시그니처 연출 하나를 맞춤으로 만들고 나머지는 템플릿에 맡기면 같은 틀에서도 다른 이벤트로 보입니다.

이벤트가 끝난 페이지는 지워야 하나요?

세 가지 중에 고릅니다. 다시 열 행사라면 종료 안내와 함께 유지하고, 이어지는 페이지가 있으면 그 페이지로 영구 리디렉션(301)하고, 남길 이유가 없으면 404나 410으로 삭제합니다. Google은 4xx 응답을 받은 URL을 색인에서 제거한다고 안내합니다.

이벤트 페이지에 Event 구조화 데이터를 넣으면 검색에 더 잘 나오나요?

Google의 이벤트 검색 기능 대상이 될 수는 있지만 조건이 있습니다. 실제 장소에서 열리는 행사여야 하고, 기간 한정 할인이나 쿠폰 같은 판매 프로모션은 대상이 아닙니다. 필수 속성은 name, startDate, location입니다.

외주를 맡길 때 무엇을 먼저 정해야 하나요?

1년 동안 열 이벤트의 종류와 횟수, 매번 바뀌는 항목과 고정 항목, 페이지를 직접 고칠 담당자, 신청 데이터를 받을 곳, 측정할 이벤트 목록입니다. 이 다섯 가지가 정해지면 템플릿 범위가 정해집니다.

이 글과 관련된 작업이 필요하다면 알려 주세요.

프로젝트 문의