축제 방문까지 레드카펫 설계하기
'경마장을 털어라' 랜딩페이지와 예약페이지 회고
Neverland - 피터팬 '꿈 속 나라' 네버랜드 같은 부산을 꿈꾸며
네버랜드는 부산 전역을 무대로 삼아 재미있는 일을 만듭니다. 의류, 건축, 기획, 디자인, 개발, 사진, 세무 분야 전문가가 모여 깊이 몰두하고 자신의 경험과 기술을 새롭게 조합해 나가며 유형의 결과물을 창작해요. 저희 네버랜드와 즐겁게 놀아줄 여러분 환영합니다!
랜딩페이지 제작기
우리가 만든 축제를 처음 소개하는 순간
먼저 타 행사나 축제들의 랜딩페이지 레퍼런스를 조사했어요. 일반적으로 [행사 소개] - [내부 프로그램 소개] - [공간 구성] - [리워드 및 상품] - [예약 안내] - [주최 및 후원사]로 구성되어 있었고 저희 또한 안내할 요소들이 이와 유사했기에 참고하여 틀을 잡았습니다.
초기 회의에서 원석님과 Framer를 사용해보자라는 의견이 있었지만 저희가 원하는 양식을 명확하게 찾지 못했고 민우님에게 업무가 배정되며 무산되었는데요. 레퍼런스를 조사하며 대부분의 랜딩페이지가 Framer로 제작된 점을 알게되어 차후에 적용해보길 다짐했습니다. 개발에 소요되는 리소스가 줄어드는 점도 크지만 무엇보다 인터렉션과 반응형에 대한 고민을 덜어도 되어 좋아보였어요.
https://content.29cm.co.kr/campaign/2025/02/12/inventario
UI는 영화제인 만큼 영화가 돋보일 수 있도록 상영될 영화의 포스터와 스틸컷 이미지를 크게 배치해 시각적으로 집중시켰습니다. 내부에 삽입되는 지도나 아이콘은 전체 컨셉에 맞춰 일러스트에서 모두 픽셀화 작업을 거친 뒤 SVG 파일로 불러와 피그마에서 배치했어요.
접근주의! 수정에 많이 날카롭습니다
문제는 상영될 영화와 예산이 고려된 리워드가 완벽하게 선정되지 않은 상황에서 예약 오픈 일자는 정해져있는 상황이었습니다. 예약 페이지가 랜딩페이지를 통해 접근되는 플로우였기에 적어도 예약이 시작될 하루 전까지는 모든 작업이 완료되어야 하는 일정이었죠. 우선 큰 맥락만 정하고 세부적인 내용들은 그때마다 결정되는 사안들을 반영해 정교하게 다듬어나갔습니다. 날카로운 건 농담이고 반복적인 수정 요청에도 웃어넘기는 멋진 사람들이에요.
안내가 너무 불친절해요
참가자에게 받은 뼈 아픈 조언으로부터 개선점을 찾을 수 있었습니다. 기획을 주도한 입장에서 우리가 열심히 만든 결과물을 잘 보여주기에만 급급하지 않았나 싶어요. 물론 행사를 단정하고 심미적으로 담아내는 것도 중요하지만 랜딩페이지는 정보 전달이라는 공지 채널의 역할도 함께 수행해야 함을 깨달았습니다. 예약을 오픈한 뒤 208명의 참가자로부터 문의가 들어왔거든요. 참가자의 22.1%이니 결코 작은 수치는 아니죠. 그 중 절반 이상이 행사 진행에 대한 추가적인 정보를 얻고자 하셨고요.
행사 진행과 관련되어 CS로 접수된 문의 사항 중 일부CS를 실시간으로 모니터링하며 1) 셔틀버스 시간표 2) 타임라인 3) 방문 방법 등 문의사항이 많았던 순서대로 개선하기 시작했어요. 저와 디자인팀은 답이 될 수 있는 정보들을 이미지로 제작하였고 민우님은 선별적으로 탐색할 수 있도록 랜딩페이지 내에서 외부 페이지 및 자료들을 연동해주셨습니다. 민수님은 이를 총괄하며 문자메시지 안내를 통해 업데이트된 웹 페이지나 카카오톡 / 인스타 채널에 접근하지 못한 분들에게 혹여나 미흡할 수 있었던 전달 경로를 보완해주셨어요.
다음이 있다면 이렇게 해야지
1. 여러 입장이 지닌 낯선 시선을 빌려오기
행사의 타켓층이 보편화되어 있다면 반드시 거쳐야 할 단계라고 생각했습니다. 반려견을 동반하는 사람, 아이와 함께 오는 가족들, 연인이나 친구, 장거리에서 찾아주시는 사람들, 휠체어를 타고 오는 사람 등. 각자의 여건에 따라 어떤 요소가 중요하고 어디에 먼저 주목하는지 상이했거든요. 이 정도면 충분하겠지 했던 지점들이 다른 조건에 놓은 참가자에게는 충분히 장애물이 될 수 있음을 알게 되었습니다. 때로는 소수를 위한 고민이 모두에게 더 편한 사용성으로 이어지기도 하듯 여러 입장에서 상상하고 관찰하면서 질문을 던져보면 선한 파급력을 기대할 수도 있지 않을까요.
2. 정보들의 위계를 정립한 뒤 흐름을 설계하기
이번에는 조급한 마음이 앞서다보니 유사 행사들의 레퍼런스를 그대로 답습했어요. 주체가 우리가 아닌 여러 행사들에 초점이 맞춰진거죠. 그러다보니 셔틀버스가 운영되거나 기존의 영화제 구성과 다르게 복합적인 프로그램이 존재하는 등 정작 저희 행사에만 적용되는 특징들은 누락되거나 뒷 순위로 밀려났습니다.
다음에는 1) 우리가 전해야 할 정보들을 먼저 모은 뒤 2) 중요도를 기준으로 분류하고 3) 시선이 흩어지거나 부담스럽거나 않게 정리하려 합니다. 첫 단추가 될 본질적인 정보에 대해서는 몰입도를 높이고 보조적인 정보는 검색을 하거나 문의를 거치지 않아도 각자의 필요에 따라 쉽게 탐색할 수 있었으면 좋겠습니다. 최종적으로는 다각적인 행사에 적용 가능한 UX 템플릿으로 만들어 제작 효율성과 지속 가능성을 높이는게 목표에요. 이런 아쉬움은 행사 기획에 대한 내공이 쌓이면서 점차 다듬어질 문제라 바라봅니다.
챗봇, FAQ, 보드 등 정보 전달을 목적으로 수집하고 있는 레퍼런스들예약페이지 제작기
2주만에 사업자 개설 0에서부터 결제 구현 100까지 만들기
'유료로 전환하더라도 특정 인원에게 집중된 혜택과 관리가 제공되는게 어떨까요' 내부에서 등장한 민수님의 의견으로 유료 참가비 + 한정된 선착순 모집이라는 큰 조건이 정해졌습니다. 무작정 많은 인원의 모집을 목표하기보다 참가자들의 질적 만족도를 우선으로 한 결정이었어요. 하지만 돈이 오고가는 관계를 법적으로 검토하고 서비스로 구현하기에는 거쳐야 할 여러 허들이 있었습니다. 인터파크 같은 외부 이커머스 서비스에 판매도 고려해보았으나 불확실한 심사 기간과 높은 수수료로 인해 개발 범위가 확장되더라도 외부 인프라를 활용하지 않고 저희가 통제할 수 있는 영역으로 가져오기로 했어요.
무통장 입금으로 결제가 이뤄지기에 입금 데이터와 대조를 위해 예약자(Main Booker : 입금자명과 동일해야 하는 사람) / 동행자(Companion : 예약자가 함께 예약한 사람)로 구분한 뒤 참가자에게 받아야 할 정보들을 정리해 DB 테이블을 만들었습니다.
다음으로 아래 3가지 결정되는 전제들을 토대로 1) 데이터 처리 기간(1차 예약 이후 입금 전까지 유효화 상태 유지) 2) 입금 확인 시 대조해야 할 데이터 항목(입금자명이 불일치하거나 동명이인일 경우) 등 여러 조건들을 민우님과 의논하며 플로우를 구체화해 나갔습니다.
1. 법인 / 개인사업자 등록 결정 → 외부 결제 API 검토 → 무통장 입금으로 결정
2. 양일 정해진 참가 인원을 선착순으로 카운팅
3. 카카오톡 비즈니스 채널 개설 검토 → 알림 경로를 문자메세지 일괄 통일 / 공지는 카카오톡 채널 사용
곳곳에서 누수된 문제와 이를 보수한 과정들
1. 동명이인 판별 로직 설계와 입금자명 정의
민우님과 참가자가 예약 퍼널에서 겪을 수 있는 여러 변수들을 최대한 잘게 쪼개었습니다. 그 중 하나에서 1) 동일한 이름을 어떻게 구분하지 → 2) 1차 예약 데이터 유효기간 정책을 정의하자 → 3) 1차 예약 데이터 유효기간 내에 동일한 이름이 존재할 경우에는 → 4) 결제 금액 데이터를 대조하면 어떨까 → 5) 대부분이 2, 3인 예약이라 공통된 데이터 값이 대부분일텐데 어렵지 않을까 라는 집요한 논의가 이뤄졌는데요.
그 결과 입금자명 = '예약 대표자 성함 + 휴대폰 번호 뒷 4자리'로 설정하자는 정책이 만들어졌습니다. 대신 '입금자명 변경 기능'을 수행해야 한다는 인지적 허들이 생겨났고 이를 낮추기 위해 가이드(주요 핀테크 앱과 상위 점유율 6개 은행 앱의 입금자명 변경 기능 화면을 캡쳐) 장치를 추가했습니다. 마지막까지 민우님과 사용자 여정에서 외부 은행 앱 진입 시점을 가정하고 가이드의 노출 지점까지 정밀하게 설계한 기억도 납니다.
걱정이 현실이 되듯 이 단계에 부딪쳐 입금자명을 잘못 기재했다는 약 50개가 넘는 CS 문의가 들어왔어요. 하지만 예약 데이터가 남아있는 상태에서 동명이인으로 입금되면 이를 시스템적으로 판별할 방법이 없었고 개인적으로 연락을 취하더라도 참가자의 답변에 의존할 수 밖에 없었습니다. 때문에 이는 피해야 할 가장 큰 리스크라고 판단했기에 되돌아보더라도 해당 정책이 잘못되었다고 보지는 않아요. 모든 예외 상황을 완벽히 처리하기 보다는 한정된 자원을 우선순위에 맞춰 효율적으로 사용하는 방안이 실질적인 해답이 될 수 있다는 점을 배웠습니다.
2. 참가자 등록 제한 로직 설계
예약과 별개로 외부에서 결제가 이뤄지는 무통장 입금의 특성 상 입금을 두고 예약 완료와 확정까지 시간 간극이 발생해요. 오픈 하루 전 민수님께서 1차 예약 완료 시점에서 제한된 참가자 수를 카운팅 · 제어할 수 없다는 문제를 짚어주셨습니다. 당시 시스템은 입금 완료 인원 기준으로만 카운팅되었기 때문에 예약 페이지가 닫힌 이후에도 이전에 예약만 해둔 사용자가 입금을 진행할 경우 정원을 초과하는 상황이 발생했습니다. 초과 입금자에게는 상황을 안내하고 환불을 진행해야 하는 불편함이 요구되었죠. 무엇보다 형성될 부정적 신뢰가 가장 우려되었어요.
작업 일정은 촉박했지만 갑작스럽게 예약이 집중될 상황을 고려한다면 반드시 해결해야 할 문제였습니다. 민수님의 의견과 민우님의 검토를 거쳐 예약 완료 후 페이지 내에서 노출되던 계좌번호를 문자 발송 방식으로 전환하여 최대 444명에게만 제공하기로 결정했습니다. 입금에 필요한 핵심 정보인 계좌번호를 한 단계 더 필터링해 제공하는 방식으로 위험을 최소화하고자 한거죠. 실제로 예약 마감 시점에는 약 20명 내외로 오차 범위가 축소되었고 이 인원 또한 여건이 확보되어 모두 수용할 수 있었습니다.
변경된 로직 구조와 대기 상태가 추가되면서 수정된 메세지 폼3. 공통 예약 정보 입력 단일화 및 UX 개편
UX가 이미 확정된 상태에서 투어버스 이용 여부·셔틀 탑승 여부·행선지 등 추가 예약 정보가 생겼습니다. 이에 대해 기존 페이지에 새로운 입력 블록만 단순 추가하는 방식으로 대응하다 보니 성격이 다른 정보들이 한 화면에 뒤섞여 페이지가 과도하게 길어지고 사용자 플로우도 분리되지 않는 문제가 발생했습니다.
받아야 할 정보 개수가 정해진 상태에서 사용자 입력 자체를 줄일 수는 없지만 인지적 부담을 최소화하는 방법은 분명 존재합니다. '하나의 화면에서 하나의 액션만 시키라'는 '1 thing for 1 page' 원칙처럼 사람의 인지 능력은 생각보다 협소하죠. 만약 다시 기회가 주어진다면, 예약 정보를 아래와 같이 분류하고 입력 순서를 조정해 단계별로 분리해서 기획했을 것 같아요.
1) 참가의 핵심적인 정보 : 일자, 인원 (기존에는 최종 단계 이후 예약 가능 여부가 피드백 되었다면 해당 정보를 입력하는 초기 화면에서 반환하는 실시간 조회 기능이 있었어도 좋았을 것 같습니다)
2) 참가의 부수적인 정보 : 교통수단, 귀가 시 행선지, 투어버스 탑승 여부
3) 입금 확인 시 대조될 정보 : 예약자 이름, 예약자 휴대폰 번호 (입금자명 관련 고지 필요)
4) 모든 참가자로부터 받아야 할 정보 : 이름, 휴대폰 번호, 티셔츠 사이즈 (이 중 티셔츠 사이즈는 타 예약 정보와 결합될 필요가 없는 독립 항목)
또한, 기존에는 공통된 정보라도 예약자와 동행자로 구분해 입력받았습니다. 모든 정보의 입력 절차를 아는 저희 운영자 입장에서는 인식할 수 없는 문제였지만 다음 페이지를 예측하지 못하는 예약자 입장은 달랐습니다. 본인들이 입력한 정보에 대해서 동행자는 언제, 어디서, 선택할 수는 있는지 질문을 받았거든요. 속성이 같은 정보를 단절된 환경에서 요구하면 어색한 맥락이 만들어진다는 사실을 깨달았어요. 무리임을 알지만 CS를 참고해 민우님께 티셔츠 사이즈만이라도 별도의 페이지로 분리해주시길 요청드렸습니다.
티셔츠 사이즈 선택과 관련되어 CS로 접수된 문의 사항 중 일부다음이 있다면 이렇게 해야지
1. 어드민 관리자 계정 개설하기
일반적으로 어드민 계정에서 기대하는 기능의 범위는 데이터의 확인과 수정이 합쳐진 관리 권한입니다. 그러나 이번에는 어드민이 작업 범위에서 제외되어 있었고, 민우님께서 참가자 현황 조회라는 최소한의 기능만 구현해 만들어주신 간소화된 페이지가 전부였어요. 이로 인해 참가자 정보 수정 / 입금 처리 등 DB를 직접 다뤄야 하는 모든 작업은 민우님을 거쳐야만 진행할 수 있는 구조가 되었습니다. CS를 총괄하던 민수님과 개발자 민우님에게 업무가 집중되고 프로세스 또한 길어지는 한계를 인지하고 있었지만 당시에 할 수 있었던 최선은 접수된 사항을 노션 보드로 정리하고 순차적으로 처리할 수 있는 환경을 구축하는 것이었습니다.
어드민을 고도화한다면 저는 먼저 사용자가 예약을 완료한 뒤 어떤 상태 값이 생성되는지 그리고 각 단계에 따라 어떤 문제와 알림이 발송되는지를 정의할 것 같습니다. 1) 1차 예약 완료 및 입금 전 (입금 대상자 / 대기자) → 2) 입금 후 예약 확정 → 3) 티셔츠 제작 중 → 4) 택배 포장 중 → 5) 택배 배송 중 → 6) 배송 완료 이렇게 6단계로 나뉜다면 단계별로 저희가 지원할 수 있는 범위가 명확해지면서 고객의 요청에 대해 구조적으로 대응할 수 있을거라 생각합니다. 예를 들어 티셔츠 사이즈를 변경하고 싶다는 요청에 대해서는 2단계 이후로 넘어가면 불가능하다라고 상태 값에 기반한 즉각적인 판단이 가능하게 되겠죠. 더불어 '어떤 정보가 고려되는지' / '어떤 문제가 발생할 수 있는지' / '어떻게 대응할 것인지'에 대한 질문에 답이 도출되면 이를 구현할 기능의 작업도 이뤄져야 할 것입니다.
3단계 이후부터는 민수님만 절차를 파악하고 있었기 때문에 택배 관련 대응 업무가 집중되었거든요. 고객별 진행 절차가 투명하게 공유된다면 다른 팀원들도 고객 소통에 적극 참여할 수 있지 않을까 기대해봅니다.
2. 환불 기준 정책 수립하기
환불 약관이 없던 것은 아니었지만 준비 일정이 수정되는 과정에서 세부 정책이 충분히 재검토 및 정교화되지 못한 채 운영되었습니다. 이로 인해 환불 요청이 들어왔을 때 일관된 기준을 적용하기는 어려웠죠. 예로 예약 페이지는 닫혔으나 아직 티셔츠 발주는 들어가지 않은 시점에 올바른 답은 무엇일까요. 정답은 없지만 참가가 유료로 전환된 시점부터 환불을 비롯한 클레임에 대한 관련 정책은 냉정하고 객관적으로 언급되어야 했습니다. 이번 영화제는 참가자들에게 이익이 되는 혜택으로 가득 채워졌지만 이는 결국 과도한 비용이자 손해로 돌아올 수 있다는 의미이기도 했으니까요. 참가자들의 공정한 경험을 보장하면서도 저희의 손해를 최소화하는 적정선을 찾기 위해 사전 면밀한 논의가 필요했다고 느꼈습니다.
3. 타 서비스의 무통장 입금 예약 로직 살펴보기
사전 조사도 진행했지만 무통장 입금은 대부분 외부 결제 API가 제공하는 가상계좌를 통해 입금 확인이 이뤄지는 구조였습니다. 당시에는 범위를 벗어나는 영역이라 기억만 하고 있었는데요. 차후 여러 이커머스 서비스를 사용하면서 자체적으로 무통장 입금을 지원하는 곳이라면 해당 방법으로 시도해 세밀하게 살펴보려 합니다. 나아가 만약 다음 프로젝트에서 외부 결제 API를 붙일 수 있다면 결제 수행 절차까지 퍼널에 포함되기에 트랜젝션 처리나 동시성 제어에 대해서도 깊이있는 검토가 필요할 것 같습니다.
정리하며
여기에 나오는 이름 비슷한 두 분. 민수님은 PM, 민우님은 개발자입니다! 서비스의 본질을 꿰뚫는 민수님의 통찰력과 수많은 실패에도 무던하게 대처한 민우님의 의연함이 아니었다면 어렵지 않았을까 싶어요. 완성된 결과보다 과정 속에서 얻은 배움과 시행착오에 집중하다보니 잘한 점보다는 개선해야 할 영역이 크게 차지되지 않았나 싶은데 2주라는 숨가쁜 일정에도 불구하고 큰 오류없이 잘 작동되어준 것만 해도 큰 성과라 생각합니다. 어떻게든 목표를 달성하겠다는 의지와 앞으로 쌓아나갈 가능성이 고르게 담긴 회고였으면 좋겠습니다.
