- 프로모션 페이지 없이 공지사항과 구글 폼으로 안내
- 쿠폰은 어드민에서 회원별 수동 지급, 응모 이벤트는 운영 불가
- 마케팅팀이 상시 이벤트와 쿠폰 이벤트를 운영할 페이지를 요청
- 같은 개발사가 기업 수강 관리 개발도 함께 맡아 일정이 빠듯함
이벤트 페이지와 어드민 구축 ✅

- 9월 안에 첫 이벤트 2개 오픈
- 공지사항과 구글 폼으로 안내하던 프로모션을 전용 페이지에서 안내하고 상품으로 연결
- 상시, 쿠폰, 응모 이벤트를 운영자가 어드민에서 직접 등록·운영
- 요구 기능 정의 (기능 12개)
- 어드민과 프론트 와이어프레임, 화면 기획서 작성
- 개발사와 개발 범위, URL 방식, 반영 일정 협의
- 테스트 케이스 339개와 상세 시나리오 72개 작성, 디자이너와 QA
- 9월 20일 첫 이벤트 2개 오픈 (신규회원 웰컴쿠폰, 오픈북 증정)
- 학습 커뮤니티 모집 이벤트 페이지로 들어온 세션의 구매 전환 3.49%, 사이트 평균의 약 1.9배
- 이후 개발 요청 없이 모집 페이지 4건 개설, 1기 종료 뒤 만든 오픈알림 페이지로 홍보 없이 한 달간 34명이 2기 알림 신청
배경
1. 서비스 맥락 및 프로젝트 배경
오픈패스는 디자이너 대상 교육 플랫폼으로, 2023년 9월 openpath.kr을 오픈했습니다. 하지만 이벤트 전용 페이지가 없어, 마케팅팀이 할인 이벤트를 어디에 게시할 수 있는지 물었을 때 공지사항이나 커뮤니티 게시글로 대신해야 했습니다. 이후 마케팅팀의 요청으로 이벤트 페이지와 이를 관리할 어드민 기능 기획을 시작했고, 요구 기능 정의부터 QA와 오픈까지 맡았습니다.
2. 구축 전 운영 방식 (As-Is)
- 이벤트 안내: 프로모션 페이지가 없어 공지사항, 커뮤니티 게시글, 구글 폼으로 안내, 홈 배너를 누르면 로그인 페이지로 이동
- 쿠폰 지급: 같은 코드를 여러 명이 등록할 수 있어, 코드가 퍼지지 않게 하려면 어드민에서 회원을 찾아 한 명씩 지급(텀블벅 수강권은 구글 폼 설문으로 대상자를 확인해 70명에게 개별 발급, 설문에 답하지 않은 약 38명은 받지 못함)
- 응모 이벤트: 참여 신청을 받을 기능이 없어 운영 불가
진행 업무
- 1. 요구 기능 정의마케팅팀 요청을 받아 이벤트 리스트, 상세, 어드민에 필요한 기능 12개를 엑셀로 정리
- 2. 어드민과 프론트 화면 기획이벤트 등록·관리 어드민과 이벤트 리스트와 상세 화면의 와이어프레임과 화면별 설명 작성
- 3. 개발 범위와 일정 협의개발사와 기한 안에 가능한 범위를 맞추고, URL 방식, 반영 순서, 패치 일정을 조율
- 4. 테스트 케이스 작성과 QA어드민 테스트 케이스 339개와 이벤트 상세 시나리오 72개를 작성하고, 두 차례 패치까지 운영 서버 반영을 확인
- 5. 첫 이벤트 2개 오픈신규회원 웰컴쿠폰과 오픈북 증정 이벤트의 쿠폰 설정과 유의사항을 검수하고 어드민에 등록
항목별 세부 업무
1. 요구 기능 정의
2024.06
배경
- 마케팅팀은 상시 이벤트, 쿠폰 이벤트, 응모 이벤트를 운영하고 싶어 했지만 필요한 기능이 정리되지 않은 상태
진행 업무
- 마케팅팀과 킥오프 회의에서 희망 기능과 참고 사이트를 검토하고, 기능을 상·중·하로 나눠 쿠폰 발급과 상품 목록을 가장 먼저 개발할 기능으로 확정
- 이벤트 리스트, 상세, 어드민으로 나눠 필요한 기능을 엑셀로 정리
결과
- 이벤트 리스트, 상세, 어드민 기능 12개(세부 기능 24개) 정의서로 개발사와 범위 협의 시작
2. 어드민과 프론트 화면 기획
2024.07
배경
- 이벤트 유형마다 상세 페이지 구성이 달라, 운영자가 쓰는 등록 화면과 회원이 보는 화면을 함께 설계해야 함
진행 업무
- 어드민: 메뉴 구조, 이벤트 등록(공통 입력 항목 + 유형별 섹션), 이벤트 관리 목록, 응모자 명단 화면을 와이어프레임과 번호별 설명으로 작성
- 프론트: 이벤트 흐름도, 이벤트 리스트, 타이머, 마감 이벤트 팝업, 유형별 상세 화면을 PC, 태블릿, 모바일로 작성
- 노출 기간에 따라 진행전부터 마감까지 상태가 자동으로 바뀌고, 쿠폰은 수량이 모두 발급되면 버튼이 비활성되도록 규칙 정의
결과
- 디자인팀이 화면 기획서대로 개발 전달용 디자인을 만들어 개발사에 전달
3. 개발 범위와 일정 협의
2024.07 ~ 09
배경
- 같은 개발사가 기업 수강 관리 페이지 등 다른 추가 개발도 함께 맡고 있어, 기한 안에 가능한 범위를 먼저 맞춰야 함
진행 업무
- 개발사가 8월 초까지 가능한 범위를 검토해 오자, 기업 교육 페이지 결제 기능을 빼고 그만큼 이벤트 기능을 넓히는 쪽으로 정리해 답변
- 요구 단계에서 정의한 4가지 유형 중 참여형(설문)을 빼고 일반, 응모, 쿠폰 3가지로 확정
- 공개 전 이벤트가 노출되지 않도록 이벤트 URL을 관리자가 지정하는 방식으로 결정
- 개발이 늦어지자 팀 리드 결정에 따라 이벤트를 먼저 QA·반영하고 기업 수강 관리는 뒤로 분리
결과
- 8월 말 개발 서버에 1차 반영, 9월 오픈 일정 유지
4. 테스트 케이스 작성과 QA
2024.08 ~ 10
배경
- 8월 말 개발 서버 반영 후 9월 중순 오픈까지 어드민과 프론트를 모두 확인해야 함
진행 업무
- 개발 서버 반영 다음 날 1차 확인에서 찾은 11건(노출 기간 미반영, 쿠폰형 버튼 오동작 등)을 먼저 전달
- 어드민 테스트 케이스 339개와 이벤트 상세 시나리오 72개를 작성하고, 디자이너 1명과 함께 결과를 Pass, Fail, Block으로 기록
- 이슈는 QA 슬라이드로 개발사와 공유하고, 오픈 전 반영할 1순위와 이후 반영할 2·3순위로 나눠 전달
- 쿠폰이 모두 발급됐을 때의 버튼처럼 디자인에 빠진 상태는 디자이너와 문구('쿠폰 소진')를 정해 반영
결과
- 1순위 이슈를 반영해 9월 20일 오픈, 나머지는 테스트 서버에서 다시 확인해 10월 25일 2차 패치로 반영
5. 첫 이벤트 2개 오픈
2024.08 ~ 09
배경
- 디자인팀과 마케팅팀이 첫 이벤트로 가입 즉시 지급되던 웰컴쿠폰을 안내하는 신규회원 상시 이벤트와 컴포넌트 VOD 오픈북 증정 이벤트를 기획
진행 업무
- 두 이벤트의 혜택과 유의사항 문구를 실제 쿠폰 설정과 대조해 검수 (5,000원 이상 사용 조건과 '금액 제한 없이' 문구 등)
- 신규 가입 쿠폰을 이벤트 시작과 함께 사용 기한 없는 쿠폰으로 변경
- 운영 서버 반영 당일 어드민에서 두 이벤트를 등록하고 노출 확인
결과
- 신규회원 웰컴쿠폰 이벤트는 종료일 없이 상시 운영
결과
오픈과 이후 사용
구축 전후
| 업무 | 구축 전 | 현재 |
|---|---|---|
| 이벤트 안내 | 공지사항과 구글 폼으로 안내 | 이벤트 리스트와 상세 페이지에서 상품 페이지로 바로 연결 |
| 쿠폰 지급 | 어드민에서 회원별 수동 지급 | 회원이 상세 페이지의 '쿠폰 받기'로 코드 없이 쿠폰함에 바로 등록, 수량과 중복 제한 |
| 응모 이벤트 | 운영 불가 | 응모형 이벤트, 응모자 명단 엑셀 내려받기 |
| 노출 기간 | 기간 설정 기능 없음 | 노출 기간에 따라 진행중, 마감임박, 마감 자동 전환 |
주요 결정
1. 이벤트 URL 관리자 지정 방식
이벤트 URL을 상품처럼 번호로 자동 생성하면 번호만 바꿔 넣어도 준비 중인 이벤트에 들어올 수 있어, 공개 전에 이벤트가 미리 노출되지 않게 하는 방식이 필요했습니다. 개발사가 제안한 관리자 지정, 난수, 생성 시각 세 가지 방식 가운데 콜로소, 패스트캠퍼스, 클래스유 등 교육 플랫폼 대부분이 쓰는 관리자 지정 방식을 골라, 운영자가 이벤트를 만들 때 주소를 직접 정하도록 했습니다.
2. 기한에 맞춘 개발 범위 조정
같은 개발사가 기업 수강 관리 개발을 함께 맡고 있어, 8월 초까지 만들 수 있는 범위를 다시 검토받았습니다. 기업 교육 페이지의 결제 기능은 빼고 그만큼 이벤트 기능 범위를 넓히는 쪽으로 정리했고, 이벤트 유형은 당시 계획된 이벤트에 필요한 것만 남기는 기준으로 설문형인 참여형을 빼고 일반형, 쿠폰형, 응모형으로 확정했습니다.
3. 1순위 이슈만 반영한 단계 오픈
오픈 전날까지 어드민 이벤트 등록 오류가 남아 있었고, 이미 한 번 미룬 이벤트를 9월 안에 열어야 했습니다. 남은 이슈를 오픈 전에 반드시 고쳐야 하는 1순위와 운영에 지장이 없는 2·3순위로 나눠, 1순위만 반영해 먼저 오픈했습니다. 회원가입 플로우 수정 등 나머지는 한 달 뒤 2차 패치로 반영했습니다.
배운 점과 아쉬운 점
기능별 이슈 관리의 필요성
QA 슬라이드에 오류를 발견한 날짜 순서로 정리해, 2차 패치를 앞두고 어떤 오류가 반영됐는지 하나씩 다시 찾아야 했습니다. 같은 기능의 오류가 여러 날짜에 흩어져 있어 패치 결과를 확인하기 어려웠고, 담당자별 점검용 슬라이드를 따로 만들어 확인했습니다. QA 이슈는 기능이나 페이지 단위로 묶어 관리해야 패치 확인까지 이어진다는 것을 배웠습니다.
종료 이후까지 포함한 노출 규칙 설계
마감된 이벤트는 목록에서 빠지고 URL 접속도 막히도록 설계했습니다. 디자이너 학습 커뮤니티인 디자인 러닝 클럽 1기 모집이 끝나자 이 페이지가 검색에 잡히지 않고 2기 알림 신청도 받을 수 없어, 알림 신청용 이벤트를 따로 만들어야 했습니다. 노출 규칙을 정할 때 이벤트가 끝난 뒤 방문자를 어디로 보낼지까지 정해야 한다는 것을 배웠습니다.
아쉬운 점: 운영 주체와 성과 지표를 정하지 않은 오픈
이벤트 페이지는 마케팅팀의 요청으로 만들었지만, 오픈 뒤 마케팅 인력이 빠지면서 첫 이벤트 2개 뒤로 마케팅 이벤트는 더 열지 않았고, 이후에는 주로 모집 페이지로 활용했습니다. 요청받은 기능만 정리하고 오픈 뒤 누가 어떤 주기로 운영할지, 이벤트 성과를 무엇으로 잴지는 정하지 않아 첫 이벤트를 거친 가입과 결제를 측정하지 못했습니다. 이후 디자인 러닝 클럽에서는 가설마다 검증 지표와 목표를 먼저 정하고 모집을 시작했습니다.
안재찬 · asa0677@naver.com