CHAMELEON EVENT LogoCHAMELEON EVENT
← ALL INSIGHTS
12 MIN READEVENT INSIGHT

캠페인 종료 후에도 자산이 남는 이벤트 페이지 설계법

온라인 이벤트는 정해진 기간 동안 운영되고 종료됩니다.

온라인 이벤트는 정해진 기간 동안 운영되고 종료됩니다.

이벤트 오픈
→ 광고 집행
→ 참여자 유입
→ 이벤트 종료
→ 페이지 비공개

많은 이벤트가 이 흐름으로 끝납니다.

다음 캠페인이 시작되면 비슷한 기능을 다시 기획하고 디자인하고 개발합니다.

  • 새로운 룰렛을 다시 제작합니다.
  • 참여자 입력 폼을 다시 만듭니다.
  • 개인정보 동의 화면을 다시 구성합니다.
  • 관리자 페이지를 다시 개발합니다.
  • 쿠폰 발급 기능을 다시 연동합니다.
  • 모바일 QA를 다시 진행합니다.
  • 운영 문서와 체크리스트를 다시 작성합니다.

캠페인의 디자인과 메시지는 달라질 수 있지만 기반 기능은 반복되는 경우가 많습니다.

따라서 이벤트 페이지를 일회성 결과물로만 만들기보다 다음 캠페인에서도 활용할 수 있는 자산으로 설계하면 장기적인 제작 비용과 시간을 줄일 수 있습니다.

이때 자산은 완성된 페이지 하나만 의미하지 않습니다.

다음 항목이 모두 캠페인 자산이 될 수 있습니다.

  • 기획 구조
  • 이벤트 모듈
  • 디자인 시스템
  • 그래픽 원본
  • 콘텐츠 관리 기능
  • 사용자와 참여 데이터 구조
  • 관리자 페이지
  • 분석 체계
  • QA 체크리스트
  • 운영 문서
  • 서버와 배포 계정
  • 소스 코드

일회성 이벤트가 반복해서 비용이 드는 이유

같은 회사에서 매년 비슷한 이벤트를 진행하더라도 담당자와 제작사가 바뀌면 처음부터 다시 시작하는 경우가 있습니다.

이전 자료를 찾기 어렵다

  • 최종 기획서 위치를 모름
  • 디자인 원본을 보유하지 않음
  • 소스 코드가 제작사에만 있음
  • 서버 계정을 전달받지 않음
  • 관리자 사용법이 없음
  • 이벤트 결과 데이터가 여러 파일로 흩어짐

구조가 캠페인 하나에만 맞춰져 있다

  • 문구가 코드에 직접 입력됨
  • 경품 수량을 개발자가 수정해야 함
  • 결과 이미지가 고정됨
  • 이벤트 기간 변경이 어려움
  • 다른 제품으로 교체할 수 없음
  • 회원 연동 방식이 특정 캠페인에만 맞음

종료와 함께 시스템을 삭제한다

이벤트가 끝난 뒤 서버와 페이지를 모두 종료하면서 재사용 가능한 기능까지 사라질 수 있습니다.

이벤트 종료
→ 서버 삭제
→ 코드 분실
→ 다음 캠페인 재개발

이벤트 종료 후 무엇을 보관하고 무엇을 삭제할지 구분해야 합니다.

남길 수 있는 캠페인 자산 10가지

  1. 캠페인 기획 템플릿
  2. 사용자 흐름
  3. 이벤트 기능 모듈
  4. 디자인 시스템
  5. 콘텐츠와 그래픽 원본
  6. 관리자 페이지
  7. 데이터와 분석 구조
  8. QA 시나리오
  9. 운영 문서
  10. 소스·서버·계정

1. 캠페인 기획 템플릿

다음 캠페인에서도 반복해서 확인할 항목을 표준 문서로 만들 수 있습니다.

캠페인 목적:
참여 대상:
유입 채널:
이벤트 방식:
핵심 참여 행동:
경품:
참여 횟수:
인증:
개인정보:
관리자:
예상 트래픽:
성과 지표:
운영 담당:
종료 처리:

이전 캠페인의 문서를 그대로 복사하는 것이 아니라 반복되는 의사결정 항목을 템플릿으로 남기는 것입니다.

이벤트 유형별 기획 템플릿

  • 룰렛
  • 퀴즈
  • 스크래치
  • 성향 테스트
  • 제품 매칭
  • 댓글 이벤트
  • 웹게임

각 유형마다 반복되는 질문이 다릅니다.

룰렛 템플릿 예시

참여 가능 횟수:
당첨 방식:
경품별 수량:
경품별 확률:
중복 당첨:
경품 소진:
결과 재확인:
쿠폰 발급:
부정 참여:

퀴즈 템플릿 예시

문항 수:
정답형·유형형:
문항별 해설:
진행률:
결과 유형:
점수 기준:
결과 카드:
쿠폰 연결:

표준 템플릿이 있으면 다음 프로젝트의 누락과 의사결정 시간을 줄일 수 있습니다.

2. 사용자 흐름

이벤트별 화면은 달라도 기본 참여 흐름은 반복될 수 있습니다.

유입
→ 이벤트 소개
→ 로그인 또는 인증
→ 참여
→ 결과
→ 개인정보
→ 보상
→ 후속 행동

이 구조를 공통 흐름으로 정리해 두면 다음 캠페인에서는 필요한 부분만 변경할 수 있습니다.

공통 예외 흐름

  • 이미 참여함
  • 대상 회원이 아님
  • 이벤트 시작 전
  • 이벤트 종료 후
  • 경품 소진
  • 인증 실패
  • 쿠폰 실패
  • 네트워크 오류
  • 결과 재확인

정상 흐름뿐 아니라 예외 화면까지 자산으로 남겨야 합니다.

3. 이벤트 기능 모듈

룰렛과 퀴즈, 스크래치 같은 기능을 캠페인별 코드에 고정하지 않고 재사용 가능한 모듈로 만들 수 있습니다.

룰렛 모듈

설정할 수 있는 항목:

  • 칸 개수
  • 경품명
  • 경품 이미지
  • 색상
  • 회전 시간
  • 결과 사운드
  • 당첨 결과
  • 참여 횟수
  • 결과 문구

퀴즈 모듈

  • 문항
  • 선택지
  • 정답
  • 해설
  • 이미지
  • 점수
  • 결과 유형
  • 진행률
  • 이전 문항
  • 결과 카드

스크래치 모듈

  • 배경 이미지
  • 포일 이미지
  • 완료 비율
  • 결과
  • 사운드
  • 모바일 제스처
  • 자동 완료

댓글 모듈

  • 입력 글자 수
  • 금칙어
  • 공개 여부
  • 관리자 승인
  • 좋아요
  • 신고
  • 정렬

제품 매칭 모듈

  • 질문
  • 선택지
  • 상품 데이터
  • 점수
  • 가중치
  • 추천 이유
  • 상품 링크

모듈화가 되어 있으면 다음 캠페인에서 디자인과 콘텐츠, 일부 정책만 변경해 활용할 수 있습니다.

모듈과 템플릿은 다르다

템플릿

정해진 화면과 기능 안에서 이미지와 문구를 바꾸는 방식입니다.

장점:

  • 빠른 제작
  • 낮은 비용
  • 검증된 구조
  • 일정 예측

제한:

  • 참여 흐름 변경 어려움
  • 브랜드별 차별화 제한
  • 복잡한 연동 어려움

모듈

기능 단위를 조합해 새로운 흐름을 만드는 방식입니다.

로그인 모듈
+ 퀴즈 모듈
+ 결과 카드
+ 쿠폰 발급
+ 제품 이동

모듈은 템플릿보다 자유도가 높지만 초기 설계와 개발이 더 필요할 수 있습니다.

4. 디자인 시스템

캠페인마다 디자인은 달라져도 기본 UI 요소는 재사용할 수 있습니다.

  • 버튼
  • 입력창
  • 체크박스
  • 팝업
  • 알림
  • 진행률
  • 로딩
  • 오류
  • 결과 카드
  • 관리자 표
  • 모바일 여백
  • 글자 크기

이벤트 디자인 토큰

주요 색상:
보조 색상:
배경:
본문 글자:
제목 글자:
버튼 높이:
모서리:
그림자:
모션 속도:

브랜드별 색상과 폰트를 교체할 수 있도록 만들면 공통 UX를 유지하면서 캠페인 분위기를 바꿀 수 있습니다.

상태별 디자인

  • 기본
  • 누름
  • 비활성
  • 로딩
  • 성공
  • 오류
  • 당첨
  • 미당첨
  • 종료

정상 화면만 디자인 자산으로 남기면 다음 캠페인에서 오류와 예외 화면을 다시 만들어야 합니다.

5. 그래픽과 콘텐츠 원본

최종 이미지 파일만 받으면 문구와 제품을 수정하기 어려울 수 있습니다.

보관할 자료

  • 디자인 원본
  • 로고 원본
  • 제품 이미지
  • 배경
  • 캐릭터
  • 일러스트
  • 3D 파일
  • 영상 원본
  • 음원
  • 결과 카드
  • SNS 이미지
  • 폰트 정보
  • 라이선스 정보

파일 구조 예시

/campaign
  /design
  /images
  /video
  /audio
  /copy
  /result-cards
  /sns
  /licenses

파일 이름과 버전을 정리해 두면 다음 캠페인에서 필요한 자료를 찾기 쉽습니다.

문구 원본

이벤트 문구도 별도 문서로 보관할 수 있습니다.

  • 메인 카피
  • 참여 안내
  • 질문
  • 결과
  • 오류
  • 경품 안내
  • 약관
  • 종료 공지
  • 알림톡
  • 이메일
  • CS 답변

페이지 안에 들어간 최종 문구뿐 아니라 채널별 안내 문구도 캠페인 자산입니다.

6. 콘텐츠 관리 기능

문구와 이미지, 경품을 개발자가 직접 수정해야 한다면 다음 캠페인에서도 개발 업무가 반복됩니다.

관리자에서 다음 항목을 변경할 수 있게 만들 수 있습니다.

  • 이벤트 기간
  • 메인 문구
  • 배너
  • 참여 방법
  • 경품
  • 경품 수량
  • 결과 문구
  • 퀴즈 질문
  • 선택지
  • 제품 링크
  • 종료 안내

모든 것을 관리자로 만들 필요는 없다

관리 기능이 많아질수록 개발 비용과 오류 가능성도 증가합니다.

다음 기준으로 구분할 수 있습니다.

운영 중 자주 변경
→ 관리자 기능 필요

캠페인마다 한 번만 변경
→ 설정 파일 또는 개발 반영 가능

거의 변경하지 않음
→ 코드에 고정 가능

실제 운영자가 바꿔야 하는 항목만 관리자에 넣는 것이 좋습니다.

7. 공통 관리자 페이지

캠페인마다 참여자 목록과 다운로드 기능을 새로 만들지 않고 공통 관리자를 운영할 수 있습니다.

캠페인 목록

  • 캠페인명
  • 상태
  • 기간
  • 참여자
  • 경품
  • 담당자
  • 최근 수정

캠페인 상세

  • 참여 통계
  • 참여자
  • 결과
  • 쿠폰
  • 경품 재고
  • UGC 검수
  • 운영 로그
  • 설정

여러 캠페인을 지원하는 구조

통합 관리자
→ 캠페인 A
→ 캠페인 B
→ 캠페인 C

마케팅 담당자는 한 계정에서 과거와 현재 캠페인을 비교할 수 있습니다.

권한

  • 전체 관리자
  • 캠페인 관리자
  • 데이터 열람
  • 콘텐츠 검수
  • 개인정보 다운로드

캠페인별로 접근 권한을 나눌 수 있습니다.

8. 공통 데이터 구조

이벤트 유형마다 데이터가 완전히 다르면 여러 캠페인의 성과를 비교하기 어렵습니다.

공통 데이터를 정할 수 있습니다.

공통 참여 데이터

  • 캠페인
  • 사용자 식별값
  • 유입 채널
  • 참여 시작
  • 참여 완료
  • 결과
  • 쿠폰
  • 공유
  • 제품 클릭
  • 기기
  • 브라우저

이벤트별 추가 데이터

룰렛:

  • 당첨 경품
  • 참여 횟수

퀴즈:

  • 문항별 답변
  • 점수

제품 매칭:

  • 선택 조건
  • 추천 제품

웹게임:

  • 미션
  • 아이템
  • 플레이 시간

공통 지표와 이벤트별 데이터를 분리하면 전체 캠페인 분석과 개별 분석을 함께 할 수 있습니다.

9. 분석 체계

캠페인마다 분석 이벤트 이름이 달라지면 비교가 어렵습니다.

이벤트 A:
quiz_start

이벤트 B:
test_begin

이벤트 C:
start_click

공통 명칭을 정할 수 있습니다.

campaign_view
participation_start
participation_step
participation_complete
result_view
reward_issue
share_click
product_click

공통 퍼널

방문
→ 참여 시작
→ 참여 완료
→ 결과 확인
→ 보상
→ 후속 행동

캠페인별로 같은 기준으로 측정하면 다음 내용을 비교할 수 있습니다.

  • 어느 이벤트가 시작률이 높은가?
  • 어느 이벤트가 완료율이 높은가?
  • 어떤 결과가 공유율이 높은가?
  • 어떤 채널의 참여 품질이 좋은가?
  • 쿠폰 발급 후 제품 클릭이 발생하는가?

10. QA 체크리스트

이벤트마다 처음부터 QA 항목을 작성하지 않고 공통 체크리스트를 자산으로 남길 수 있습니다.

공통 QA

  • 시작 전
  • 진행 중
  • 종료 후
  • 로그인
  • 참여 횟수
  • 중복 요청
  • 개인정보
  • 결과
  • 쿠폰
  • 관리자
  • 모바일
  • 인앱 브라우저
  • 트래픽
  • 장애

유형별 QA

  • 룰렛
  • 퀴즈
  • 스크래치
  • 댓글
  • 웹게임
  • 제품 추천

이전 프로젝트에서 발견된 오류를 다음 체크리스트에 추가하면 캠페인을 진행할수록 품질 관리 체계가 좋아집니다.

11. 운영 문서

이벤트 운영 경험은 담당자가 바뀌면 사라지기 쉽습니다.

다음 문서를 남길 수 있습니다.

  • 운영 일정
  • 담당자 연락망
  • 관리자 사용법
  • 장애 대응
  • 참여자 문의 답변
  • 부정 참여 기준
  • 당첨자 선정
  • 경품 발송
  • 개인정보 파기
  • 종료 절차
  • 결과 보고

운영 매뉴얼 예시

쿠폰 발급 실패 발생
→ 관리자에서 실패 목록 확인
→ 외부 쿠폰 시스템 상태 확인
→ 재발급 실행
→ 사용자 안내
→ 처리 결과 기록

다음 캠페인에서 같은 문제가 발생하면 대응 시간을 줄일 수 있습니다.

12. 소스 코드와 계정

이벤트 페이지의 재사용을 위해 소스와 운영 계정을 인계받아야 합니다.

확인할 항목

  • 소스 코드 저장소
  • 배포 계정
  • 서버
  • 데이터베이스
  • 도메인
  • CDN
  • 파일 저장소
  • 분석 도구
  • 소셜 로그인
  • 문자·이메일
  • 쿠폰 API
  • 관리자 계정

계정 소유

가능하면 클라이언트가 장기적으로 관리할 주요 계정은 클라이언트 명의로 생성하는 것이 좋습니다.

클라이언트 소유 계정
→ 제작사에 작업 권한 부여
→ 프로젝트 종료 후 권한 회수

제작사 개인 계정에만 시스템이 연결되면 계약 종료 후 이전이 어려울 수 있습니다.

이벤트를 종료할 때 무엇을 삭제할까?

자산을 남기는 것과 개인정보를 계속 보관하는 것은 다른 문제입니다.

남길 수 있는 항목

  • 익명화된 성과 데이터
  • 소스 코드
  • 디자인
  • 운영 문서
  • 공통 기능
  • QA 기록
  • 통계
  • 장애 기록

삭제 또는 파기가 필요할 수 있는 항목

  • 참여자 이름
  • 휴대전화 번호
  • 이메일
  • 배송 주소
  • 회원 식별 정보
  • 원본 응모 데이터

개인정보와 운영 자산을 분리해야 합니다.

캠페인 기능과 문서
→ 보관

참여자 개인정보
→ 정책에 따라 파기

구체적인 보유와 파기 기준은 캠페인과 데이터 성격에 맞게 내부 담당자나 전문가의 검토를 받는 것이 좋습니다.

재사용을 고려한 데이터 구조

캠페인을 코드에 직접 고정하면 재사용이 어렵습니다.

고정형 구조

MORROW 룰렛
→ MORROW 경품
→ MORROW 문구
→ MORROW 결과

설정형 구조

캠페인
→ 이벤트 유형
→ 브랜드
→ 경품
→ 문구
→ 기간
→ 결과

관리자나 설정 파일에서 캠페인 정보를 바꿀 수 있으면 새로운 이벤트를 추가하기 쉽습니다.

재사용 가능한 이벤트 페이지 구조

공통 시스템
- 로그인
- 인증
- 개인정보
- 참여 기록
- 쿠폰
- 관리자
- 분석

이벤트 모듈
- 룰렛
- 퀴즈
- 스크래치
- 성향 테스트
- 제품 매칭

캠페인 콘텐츠
- 브랜드
- 이미지
- 문구
- 경품
- 결과

공통 시스템과 이벤트 기능, 캠페인 콘텐츠를 분리하면 변경 범위를 줄일 수 있습니다.

어디까지 공통화해야 할까?

모든 것을 하나의 거대한 이벤트 플랫폼으로 만들 필요는 없습니다.

공통화를 지나치게 크게 시작하면 초기 비용과 복잡도가 높아질 수 있습니다.

공통화하기 좋은 영역

  • 로그인
  • 참여 기록
  • 개인정보
  • 경품 재고
  • 쿠폰 발급
  • 관리자
  • 분석
  • 기본 UI
  • QA

캠페인별로 자유롭게 둘 영역

  • 메인 비주얼
  • 카피
  • 인터랙션 연출
  • 사운드
  • 세계관
  • 결과 카드
  • 제품 메시지

기반은 공통으로 유지하고 사용자에게 보이는 경험은 캠페인에 맞게 바꾸는 방식이 적합할 수 있습니다.

단계적으로 자산화하는 방법

1단계: 문서와 원본부터 남긴다

  • 기획서
  • 디자인 원본
  • 소스 코드
  • 관리자 매뉴얼
  • QA 체크리스트
  • 성과 데이터

별도 플랫폼 개발 없이도 시작할 수 있습니다.

2단계: 반복 기능을 모듈화한다

  • 로그인
  • 응모폼
  • 룰렛
  • 퀴즈
  • 쿠폰
  • 관리자
  • 분석

두세 번 반복된 기능부터 공통화할 수 있습니다.

3단계: 통합 관리자를 만든다

여러 캠페인을 한곳에서 관리하고 과거 데이터를 비교합니다.

4단계: 내부 이벤트 플랫폼으로 확장한다

마케팅 담당자가 새로운 캠페인을 생성하고 콘텐츠를 설정할 수 있는 구조로 발전시킬 수 있습니다.

처음부터 4단계를 목표로 과도한 기능을 만들기보다 실제 반복되는 업무를 기준으로 단계적으로 발전시키는 것이 좋습니다.

캠페인 자산 목록

기획
[ ] 캠페인 기획서
[ ] 사용자 흐름
[ ] 정책
[ ] 화면 목록

디자인
[ ] 디자인 원본
[ ] 이미지 원본
[ ] 영상·음원
[ ] 폰트·라이선스
[ ] 결과 카드

개발
[ ] 소스 코드
[ ] 저장소
[ ] 배포 문서
[ ] 데이터 구조
[ ] API 문서

운영
[ ] 관리자 계정
[ ] 관리자 매뉴얼
[ ] 운영 일정
[ ] 장애 대응
[ ] CS 답변
[ ] 경품 발송 절차

분석
[ ] 참여 데이터
[ ] 공통 지표
[ ] 채널별 성과
[ ] 종료 리포트
[ ] 개선 항목

계정
[ ] 서버
[ ] 도메인
[ ] 데이터베이스
[ ] 분석 도구
[ ] 문자·이메일
[ ] 외부 API

제작 견적에서 확인할 항목

  • 소스 코드가 전달되는가?
  • 디자인 원본이 제공되는가?
  • 공통 이벤트 모듈을 다시 사용할 수 있는가?
  • 재사용 시 추가 비용은 어떻게 되는가?
  • 서버와 계정은 누구 소유인가?
  • 관리자 기능을 다음 캠페인에서도 사용할 수 있는가?
  • 참여 데이터 구조가 문서화되는가?
  • 운영 매뉴얼이 제공되는가?
  • 다음 제작사가 유지보수할 수 있는가?
  • 개인정보와 일반 자산이 분리되는가?

마무리

캠페인 종료 후 자산이 남는 이벤트 페이지는 단순히 이전 페이지를 복사해서 다시 쓰는 구조가 아닙니다.

다음 요소를 체계적으로 남기는 것입니다.

기획 경험
+ 기능 모듈
+ 디자인 원본
+ 관리자
+ 데이터
+ 운영 문서
+ 소스와 계정

모든 캠페인을 동일한 템플릿으로 만들 필요는 없습니다.

브랜드와 제품, 캠페인 메시지는 매번 새롭게 표현하되 반복되는 시스템과 업무는 재사용할 수 있습니다.

공통 기반
→ 안정성과 효율

캠페인별 경험
→ 차별성과 브랜드 표현

첫 이벤트부터 거대한 플랫폼을 만들기보다 기획서와 원본, 소스, QA 문서를 제대로 인계받는 것부터 시작하는 것이 좋습니다.

이후 반복되는 룰렛과 퀴즈, 쿠폰, 관리자 기능을 순서대로 모듈화하면 이벤트를 진행할수록 제작 속도와 운영 품질을 높일 수 있습니다.