온라인 이벤트 제작사 선정 체크리스트: 기획·개발·운영까지 확인할 것
온라인 이벤트 제작사를 찾을 때 포트폴리오의 디자인만 보고 결정하기 쉽습니다.
- #이벤트 제작사
- #온라인 이벤트 외주
- #제작사 선정
- #이벤트 개발
- #발주 체크리스트
온라인 이벤트 제작사를 찾을 때 포트폴리오의 디자인만 보고 결정하기 쉽습니다.
- 비주얼이 화려합니다.
- 애니메이션이 많습니다.
- 유명 브랜드 프로젝트가 있습니다.
- 웹게임 화면이 재미있어 보입니다.
- 견적이 저렴합니다.
- 제작 기간이 짧습니다.
이런 요소도 중요합니다.
하지만 실제 이벤트는 화면이 완성된 뒤부터 운영이 시작됩니다.
기획
→ 디자인
→ 개발
→ QA
→ 오픈
→ 참여자 운영
→ 경품
→ 개인정보
→ 결과 보고
따라서 제작사를 선정할 때는 예쁜 페이지를 만들 수 있는가뿐 아니라 다음 질문을 확인해야 합니다.
- 참여 정책을 구체적으로 설계할 수 있는가?
- 경품 재고와 쿠폰을 안전하게 처리할 수 있는가?
- 관리자 페이지가 필요한 수준으로 제공되는가?
- 모바일과 인앱 브라우저 QA를 진행하는가?
- 개인정보와 경품 배송 구조를 이해하고 있는가?
- 트래픽 폭주와 외부 API 장애에 대응할 수 있는가?
- 오픈 중 누가 모니터링하고 문제를 해결하는가?
- 종료 후 데이터와 소스, 운영 문서를 받을 수 있는가?
온라인 이벤트 제작사는 단순한 웹디자인 업체가 아니라 기획과 시스템, 운영을 함께 연결하는 파트너에 가깝습니다.
제작사 선정의 8개 기준
- 목적과 참여 구조를 이해하는가?
- 실제 개발 범위를 설명할 수 있는가?
- 관리자와 운영 기능을 함께 설계하는가?
- 경품·쿠폰·개인정보 경험이 있는가?
- 모바일·성능·트래픽을 검토하는가?
- QA 범위와 완료 기준이 명확한가?
- 오픈 이후 대응 방식이 있는가?
- 결과물과 계정, 소스를 인계하는가?
1. 먼저 캠페인 목적을 물어보는가?
좋은 제작사는 처음부터 원하는 게임 형식만 묻지 않습니다.
룰렛을 만들고 싶습니다.
라는 요청에도 다음을 확인할 수 있습니다.
- 왜 룰렛을 사용하는가?
- 회원가입이 목표인가?
- 제품 구매가 목표인가?
- 팝업 방문이 목표인가?
- 모든 참여자에게 혜택을 주는가?
- 즉시 당첨인가, 추첨인가?
- 반복 참여가 필요한가?
- 예상 참여자는 몇 명인가?
- 어떤 데이터를 봐야 하는가?
같은 룰렛이라도 목적에 따라 구조가 달라집니다.
신규 회원 룰렛
→ 가입·쿠폰·첫 구매
팝업 룰렛
→ 현장 QR·중복 사용·교환
일일 룰렛
→ 재참여·자정 초기화·알림
형식보다 목적에서 기획을 시작하는지 확인해야 합니다.
2. 참여 정책을 문장으로 정리하는가?
개발 전 다음 내용을 문서로 확정해야 합니다.
- 참여 대상
- 이벤트 기간
- 참여 횟수
- 사용자 식별
- 당첨 방식
- 중복 당첨
- 경품 수량
- 소진 후 처리
- 오류 시 결과
- 재접속
- 부정 참여
- 개인정보
- 발송 일정
좋지 않은 상태
하루 한 번 정도로 해주세요.
구체적인 상태
회원 ID 기준 하루 1회
매일 한국 시간 0시 초기화
실물 경품은 기간 중 1회
쿠폰은 중복 가능
정책이 불명확하면 개발과 디자인이 끝난 뒤에도 기능이 계속 바뀔 수 있습니다.
3. 기능 목록이 아니라 사용자 흐름을 제시하는가?
단순 기능 목록
룰렛
로그인
쿠폰
관리자
사용자 흐름
광고 유입
→ 이벤트 소개
→ 로그인
→ 참여 가능 여부
→ 서버 결과 저장
→ 룰렛 연출
→ 쿠폰 발급
→ 제품 이동
→ 결과 재확인
사용자 흐름이 있어야 누락된 화면과 예외 상황을 찾을 수 있습니다.
4. 정상 흐름뿐 아니라 예외 흐름을 설명하는가?
이벤트에서는 다음 상황이 반드시 발생할 수 있습니다.
- 버튼 중복 클릭
- 네트워크 오류
- 애니메이션 중 페이지 종료
- 쿠폰 API 실패
- 경품 소진
- 로그인 세션 만료
- 이벤트 종료 직전 요청
- 여러 기기
- 관리자 실수
- 외부 서비스 장애
제작사가 다음 질문에 어떻게 답하는지 확인합니다.
결과는 언제 확정되나요?
쿠폰 발급이 실패하면 어떻게 되나요?
새로고침하면 결과가 바뀌나요?
재고 1개에 여러 명이 참여하면요?
5. 서버에서 결과를 안전하게 처리하는가?
실제 경품이 있는 이벤트에서는 브라우저 화면만으로 결과를 결정하면 안 될 수 있습니다.
권장 흐름:
참여 요청
→ 서버 자격 확인
→ 결과 결정
→ 결과 저장
→ 경품 재고 차감
→ 화면 연출
확인할 항목
- 중복 요청 방지
- 재고 동시 처리
- 결과 재확인
- 참여 횟수
- 서버 시간
- 관리자 로그
- 쿠폰 발급 상태
제작사가 애니메이션만 구현하고 실제 당첨 로직을 클라이언트에 맡기는지 확인해야 합니다.
6. 관리자 페이지 범위
관리자는 단순히 참여자 목록을 보는 화면이 아닙니다.
운영에 필요한 기능
- 전체 참여
- 사용자 검색
- 결과
- 경품별 재고
- 쿠폰 상태
- 발급 실패
- 재처리
- 당첨자
- 배송 상태
- 부정 참여 검토
- 콘텐츠 승인
- 공지 변경
- 일시 중지
- 엑셀 다운로드
- 처리 이력
이벤트마다 필요한 기능은 다릅니다.
모든 기능을 넣을 필요는 없지만 오픈 중 실제로 누가 무엇을 해야 하는지 기준으로 관리자 범위를 정해야 합니다.
7. 관리자 권한
전체 관리자
운영자
콘텐츠 검수자
경품 담당자
개인정보 담당자
모든 담당자가 전체 연락처와 주소를 볼 필요는 없습니다.
확인할 항목
- 역할별 접근
- 개인정보 마스킹
- 엑셀 다운로드 권한
- 결과 수정 권한
- 처리 이력
- 관리자 로그인 보안
8. 개인정보를 화면만이 아니라 운영까지 고려하는가?
응모폼에 동의 체크박스를 넣는 것만으로 개인정보 설계가 끝나는 것은 아닙니다.
수집
→ 관리자 접근
→ 경품사 전달
→ 보관
→ 삭제
제작사에 확인할 질문
- 일반 참여자와 당첨자의 정보가 분리되는가?
- 배송 주소는 당첨자에게만 받는가?
- 관리자에서 정보가 마스킹되는가?
- 누가 다운로드할 수 있는가?
- 파기 기능이 있는가?
- 백업과 다운로드 파일은 어떻게 처리하는가?
- 외부 업체 전달 기록을 남길 수 있는가?
구체적인 동의와 보유 기간은 발주사의 담당자 검토가 필요하지만 제작사는 이를 시스템에 반영할 수 있어야 합니다.
9. 쿠폰 연동 경험
쿠폰 이벤트에서는 다음 상태가 필요할 수 있습니다.
당첨
발급 중
발급 완료
발급 실패
재발급
사용
만료
확인할 질문
- 쿠폰은 어디에서 생성되는가?
- 외부 API 한도는 무엇인가?
- 발급 실패 건은 저장되는가?
- 관리자에서 재처리할 수 있는가?
- 같은 쿠폰이 중복 발급될 수 있는가?
- 실제 결제 화면에서 조건을 검수하는가?
쿠폰 당첨과 발급 성공을 하나의 상태로 처리하면 오류 대응이 어려울 수 있습니다.
10. 경품 재고
즉시 당첨과 선착순 이벤트에서는 정확한 재고 처리가 중요합니다.
남은 수량 1개
→ 동시 요청 10건
→ 당첨 1건
이 시나리오를 실제로 QA하는지 확인합니다.
경품 관리 기능
- 전체 수량
- 남은 수량
- 일별 배분
- 소진
- 대체 결과
- 관리자 변경
- 변경 이력
11. 트래픽 예상과 부하 테스트
제작사가 서버를 크게 쓰면 된다고만 답하는지 확인해야 합니다.
필요한 질문
- 문자와 광고 대상은 몇 명인가?
- 특정 시각에 오픈하는가?
- 최고 동시 접속 예상은 얼마인가?
- 로그인과 쿠폰 API의 처리 한도는 얼마인가?
- 대기열이 필요한가?
- 정적 파일은 CDN을 사용하는가?
- 데이터베이스 병목은 없는가?
- 부하 테스트 기준은 무엇인가?
부하 테스트 범위
첫 화면 조회
참여 API
재고 차감
로그인
쿠폰 발급
중복 클릭
외부 API 실패
12. 모바일과 인앱 브라우저 QA
브랜드 이벤트는 모바일 유입이 많습니다.
다음 환경을 실제로 테스트하는지 확인합니다.
- iPhone Safari
- Android Chrome
- 삼성 인터넷
- 카카오톡 인앱 브라우저
- 인스타그램 인앱 브라우저
- 네이버 앱
- 작은 화면
- 저사양 기기
- 느린 네트워크
PC 브라우저 한두 개에서만 확인하는 QA로는 부족할 수 있습니다.
13. 접근성
- 텍스트 대비
- 충분한 버튼 크기
- 색상 외 상태 표시
- 영상 자막
- 사운드 없이 참여
- 애니메이션 건너뛰기
- 스크래치 대체 버튼
- 결과 텍스트
캠페인의 핵심 혜택을 가능한 많은 사용자가 확인할 수 있게 하는지 살펴봅니다.
14. QA 문서를 제공하는가?
테스트 완료라는 문장보다 어떤 항목을 검수했는지 확인할 수 있어야 합니다.
QA 문서 예시
| 항목 | 조건 | 결과 | 상태 |
|---|---|---|---|
| 첫 참여 | 정상 회원 | 쿠폰 발급 | 완료 |
| 중복 참여 | 같은 날 재접속 | 차단 | 완료 |
| 발급 실패 | API 오류 | 재처리 목록 | 완료 |
| 재고 1개 | 동시 요청 | 1명 당첨 | 완료 |
| 종료 후 | API 요청 | 참여 차단 | 완료 |
포함할 내용
- 테스트 계정
- 기기·브라우저
- 정상·오류 시나리오
- 수정 내역
- 재검수
- 미해결 사항
15. 완료 기준
프로젝트가 언제 완료된 것으로 보는지 정해야 합니다.
디자인 전달
개발 서버 배포
QA 완료
운영 서버 오픈
관리자 인계
소스 전달
이벤트 종료
단순히 페이지가 보이는 시점을 완료로 잡으면 실제 운영 기능과 장애 대응이 빠질 수 있습니다.
완료 기준 예시
합의된 기능 구현
주요 QA 완료
운영 서버 배포
관리자 계정 인계
소스와 문서 전달
오픈 리허설 완료
16. 오픈 리허설
실제 오픈과 같은 흐름으로 리허설을 진행할 수 있습니다.
광고 링크
→ 모바일 접속
→ 로그인
→ 참여
→ 쿠폰
→ 관리자
→ 제품 구매
참여자
- 발주사 마케팅팀
- 운영팀
- CS
- 제작사
- 쿠폰·경품 업체
- 개인정보 담당자
각 담당자가 자기 업무를 확인합니다.
17. 오픈 중 대응
확인할 내용
- 오픈 시간에 누가 대기하는가?
- 장애 연락 채널은 무엇인가?
- 응답 목표는 어느 정도인가?
- 광고 중단 결정자는 누구인가?
- 이벤트 일시 중지 기능이 있는가?
- 사용자 공지는 누가 작성하는가?
- 외부 업체 장애는 누가 연락하는가?
오픈 중 대응이 추가 비용인지 기본 범위인지 견적에서 확인해야 합니다.
18. 유지보수와 운영 지원
개발 유지보수
- 버그 수정
- 브라우저 업데이트
- 서버 장애
- 외부 API 변경
이벤트 운영
- 경품 재고
- 당첨자
- 쿠폰 재발급
- 콘텐츠 검수
- 문의 대응
- 결과 리포트
두 업무는 서로 다릅니다.
제작사가 어디까지 담당하고 발주사가 무엇을 해야 하는지 구분해야 합니다.
19. 종료 후 업무
이벤트 종료 뒤에도 다음 업무가 남습니다.
- 신규 참여 차단
- 당첨자 선정
- 결과 공지
- 경품 발송
- 문의 대응
- 개인정보 파기
- 결과 데이터
- 서버 종료
제작 계약이 이벤트 종료일에 바로 끝나면 시스템 지원이 필요한 시점에 담당자가 없을 수 있습니다.
20. 소스와 계정 인계
받아야 할 수 있는 항목
- 소스 코드
- 저장소
- 서버 계정
- 도메인
- CDN
- 데이터베이스
- 외부 API 계정
- 분석 도구
- 관리자 계정
- 배포 방법
- 환경 변수 목록
- 운영 문서
제작사 개인 계정에 모든 자산이 묶이지 않도록 해야 합니다.
21. 디자인 원본과 라이선스
- 디자인 파일
- 이미지
- 아이콘
- 폰트
- 음원
- 영상
- 3D 에셋
- 캐릭터
- 외부 라이브러리
상업적 이용과 캠페인 종료 후 재사용 가능 범위를 확인해야 합니다.
폰트와 음원 라이선스가 이벤트 도메인과 기간에 맞는지 검토해야 합니다.
22. 재사용 범위
다음 캠페인에서 같은 시스템을 사용할 계획이 있다면 구조를 모듈화할 수 있습니다.
공통 시스템
- 회원 연동
- 쿠폰
- 결과 저장
- 관리자
- GA4
- 개인정보 파기
캠페인별 변경
- 디자인
- 질문
- 결과
- 경품
- 카피
초기 제작비는 높아질 수 있지만 반복 캠페인의 일정과 비용을 줄일 수 있습니다.
23. 견적 범위를 비교할 때
같은 룰렛 이벤트 견적이라도 포함 범위가 다를 수 있습니다.
| 항목 | 제작사 A | 제작사 B |
|---|---|---|
| 기획 | 포함 | 발주사 제공 |
| 디자인 | 포함 | 템플릿 |
| 서버 결과 처리 | 포함 | 기본 |
| 관리자 | 재고·쿠폰·로그 | 목록 |
| 부하 테스트 | 포함 | 제외 |
| 오픈 대응 | 포함 | 별도 |
| 종료·파기 | 포함 | 제외 |
| 소스 인계 | 포함 | 별도 |
총금액만 비교하면 실제 운영에 필요한 추가 비용을 놓칠 수 있습니다.
24. 견적서에서 확인할 항목
기획:
화면 수:
디자인:
반응형:
프론트엔드:
백엔드:
관리자:
회원 연동:
쿠폰:
외부 API:
서버:
부하 테스트:
QA:
오픈 대응:
유지보수:
종료 업무:
소스 인계:
라이선스:
25. 일정
온라인 이벤트 일정은 디자인과 개발 기간만으로 계산하지 않습니다.
정책 확정
→ 화면 기획
→ 디자인
→ 개발
→ 외부 연동
→ 콘텐츠 입력
→ QA
→ 운영 리허설
→ 수정
→ 오픈
외부 쿠폰과 회원 API, 개인정보 검토, 경품 확정이 늦으면 전체 일정에 영향을 줍니다.
일정표 예시
1주 차
→ 목적·정책·외부 연동 확정
2주 차
→ UX·화면 기획
3~4주 차
→ 디자인·개발
5주 차
→ 기능 연동·관리자
6주 차
→ QA·부하 테스트
7주 차
→ 운영 리허설·수정
8주 차
→ 오픈
실제 일정은 이벤트 복잡도에 따라 달라집니다.
26. 제작사에게 제공해야 할 자료
- 캠페인 목적
- 브랜드 가이드
- 제품 정보
- 참여 정책
- 경품
- 회원 구조
- 쿠폰 API
- 개인정보 문구
- 약관
- 일정
- 예상 트래픽
- 유입 채널
- 성과 KPI
- 담당자
발주 자료가 늦어지면 제작사가 빠르더라도 일정이 지연될 수 있습니다.
27. 커뮤니케이션
확인할 내용
- 프로젝트 담당자
- 의사결정자
- 정기 회의
- 피드백 채널
- 수정 요청 형식
- 승인 기준
- 긴급 연락
- 회의록
- 일정 변경
요청을 메신저와 이메일, 문서 여러 곳에 분산하면 누락될 수 있습니다.
28. 포트폴리오를 볼 때
화면 이미지뿐 아니라 다음을 확인합니다.
- 어떤 목적의 이벤트였는가?
- 실제 기능은 무엇이었는가?
- 회원과 쿠폰을 연동했는가?
- 관리자 범위는 무엇인가?
- 예상 참여 규모는 얼마였는가?
- 운영과 장애 대응을 했는가?
- 결과는 어떻게 측정했는가?
- 비슷한 업종보다 비슷한 문제를 해결했는가?
디자인 업종이 다르더라도 필요한 시스템 문제를 해결한 경험이 더 중요할 수 있습니다.
29. 지나치게 저렴한 견적
저렴한 견적 자체가 문제는 아닙니다.
다만 다음 항목이 빠졌을 수 있습니다.
- 백엔드
- 안전한 결과 저장
- 관리자
- 쿠폰 실패 처리
- 모바일 QA
- 부하 테스트
- 오픈 대응
- 개인정보 파기
- 소스 인계
템플릿과 단순 프론트 이벤트라면 비용이 낮을 수 있습니다.
실제 경품과 회원, 쿠폰, 운영이 필요한 캠페인이라면 포함 범위를 자세히 확인해야 합니다.
30. 지나치게 짧은 일정
룰렛 이벤트 3일 완성
이 가능할 수 있는 조건:
- 기존 템플릿
- 회원 연동 없음
- 쿠폰 연동 없음
- 관리자 없음
- 경품 없음
- 단순 홍보 페이지
반대로 다음 기능이 있다면 더 많은 검토가 필요합니다.
- 신규 디자인
- 회원·인증
- 쿠폰
- 관리자
- 실물 경품
- 개인정보
- 대규모 트래픽
- 웹게임
- 외부 API
제작 일정이 짧다는 사실보다 어떤 범위가 제외되는지 확인해야 합니다.
제작사 미팅 질문
1. 이 이벤트의 핵심 목표를 어떻게 이해했나요?
2. 참여 결과는 언제, 어디에서 확정되나요?
3. 중복 클릭과 재접속은 어떻게 처리하나요?
4. 쿠폰 발급 실패는 어떻게 복구하나요?
5. 관리자에서 무엇을 할 수 있나요?
6. 어떤 모바일 환경을 QA하나요?
7. 예상 트래픽과 부하 테스트 기준은 무엇인가요?
8. 오픈 중 장애 대응은 어떻게 진행하나요?
9. 종료 후 개인정보 파기는 어떻게 지원하나요?
10. 소스·서버·계정은 어떻게 인계되나요?
제작사 비교표
| 평가 항목 | 배점 | 제작사 A | 제작사 B |
|---|---|---|---|
| 목적·기획 이해 | 15 | ||
| 디자인·브랜드 | 15 | ||
| 개발 구조 | 15 | ||
| 관리자·운영 | 15 | ||
| 경품·쿠폰 경험 | 10 | ||
| QA·트래픽 | 10 | ||
| 일정·커뮤니케이션 | 10 | ||
| 인계·유지보수 | 10 | ||
| 합계 | 100 |
가격 외의 기준을 함께 평가할 수 있습니다.
발주 체크리스트
[ ] 캠페인 목적과 KPI가 정의되어 있다.
[ ] 참여 대상·횟수·당첨 정책이 확정되어 있다.
[ ] 경품 수량과 쿠폰 조건이 확정되어 있다.
[ ] 사용자 흐름과 예외 흐름이 문서화되어 있다.
[ ] 관리자 기능과 권한이 정의되어 있다.
[ ] 개인정보 수집·보관·파기 구조가 검토되었다.
[ ] 외부 API와 담당자가 확정되어 있다.
[ ] 예상 트래픽과 오픈 시간이 공유되었다.
[ ] 모바일·인앱 브라우저 QA 범위가 있다.
[ ] 부하 테스트와 운영 리허설이 일정에 포함되어 있다.
[ ] 오픈 중 대응 시간과 담당자가 정해져 있다.
[ ] 종료 후 추첨·발송·파기 지원 범위가 있다.
[ ] 소스·계정·디자인 원본 인계가 명시되어 있다.
[ ] 외부 에셋과 폰트의 라이선스가 확인되었다.
[ ] 수정 횟수보다 완료 기준이 명확하게 정의되어 있다.
계약 전 최종 확인 양식
이벤트명:
목적:
최종 KPI:
참여 정책:
당첨 정책:
경품:
회원:
쿠폰:
개인정보:
관리자:
트래픽:
외부 API:
QA:
오픈 대응:
종료 운영:
유지보수:
소스 인계:
디자인 인계:
라이선스:
총일정:
총비용:
추가 비용 조건:
완료 기준:
마무리
온라인 이벤트 제작사를 선정할 때 가장 중요한 것은 가장 화려한 화면이나 가장 낮은 견적만 비교하는 것이 아닙니다.
목적을 이해하는 기획
+ 안전한 참여 처리
+ 실제 운영 관리자
+ 충분한 QA
+ 오픈 대응
+ 명확한 인계
이 전체 범위를 함께 확인해야 합니다.
온라인 이벤트는 사용자가 참여하는 화면뿐 아니라 경품과 쿠폰, 개인정보, 트래픽, 운영까지 연결된 시스템입니다.
어떤 결과물을 언제까지 어떻게 완성하고, 오픈 이후 누가 책임지고 운영할 것인지 명확하게 설명할 수 있는 제작사를 선택하는 것이 중요합니다.
RELATED INSIGHTS