숙박 큐레이션 플랫폼 프런트엔드 2022–2024

한눈에 보기

핵심 작업 세 가지를 먼저 꼽으면 이렇습니다.

1. 일본어 다국어 지원 — i18next 도입, URL 경로 기반 언어 상태 관리, 일본어 조판 특성에 맞춘 CSS 최적화 (§1)
2. 무한 스크롤 성능 개선 — Intersection Observer + SWR. React-Query·SSR 재조회를 후보로 두고 요구사항·납기 기준으로 선택 (§2)
3. 웹→앱 전환 UX 개편과 이벤트 태깅 기반 구축 — 모바일 웹 앱 설치 CTA, GA4 + Firebase 웹뷰 동기화. 전사 캠페인이 성과를 측정할 수 있게 만든 기반 작업 (§3)

문서를 정리하면서 순서를 바꿨습니다. 원래는 아홉 개 절을 시간 순으로 늘어놨는데, 다시 읽어보니 선택의 근거가 남아 있는 작업은 넷뿐이었어요. 그 넷을 앞으로 올리고 나머지는 5절에 묶었습니다. "무엇을 했는가"만 남은 항목까지 같은 비중으로 늘어놓으면, 근거가 있는 항목까지 같이 묽어지더군요.

지표 표기 원칙 이 문서의 수치 중 전사 캠페인·마케팅 성과에 해당하는 것은 해당 절에 담당 범위를 따로 명시했습니다. 제가 한 일과 팀이 함께 낸 결과를 섞지 않으려고 구분해 적었어요. 그리고 측정하지 않은 것은 수치 없이 적었습니다.

1. 일본어 다국어 지원 — 언어 상태를 어디에 둘 것인가

문제. 해외 사용자가 자신의 언어로 서비스를 이용하지 못해 이탈이 발생했습니다. 특히 일본어는 한자와 특수 문자를 많이 써서 글자 크기·줄 간격 조정이 필요했고, 번역 과정에서 원본과 차이가 생겨 중요한 정보가 제대로 전달되지 않는 문제도 있었습니다.

한 일.

• i18next 도입 — 번역 데이터를 JSON으로 관리해 필요한 언어만 동적으로 로딩하도록 구성했습니다. 다국어 포맷팅과 복수형 처리가 이미 갖춰져 있어 직접 만들 이유가 없었어요.
• 초기엔 목업 데이터로 선행 개발 — API가 준비되기 전에 다국어 기능을 미리 구현·테스트했습니다.
• 일본어 조판에 맞춘 CSS 조정 — 글자 크기·줄 간격을 조정하고 word-break를 추가해 시각적 안정성을 확보했습니다.
• 백엔드 협업 — 다국어 데이터를 admin·host URL의 REST API로 받고, i18next와 옵셔널 체이닝으로 데이터가 없거나 지연될 때도 앱이 죽지 않게 처리했습니다.

이 절의 판단 — 언어 상태를 URL에 둘 것인가, 쿠키·localStorage에 둘 것인가.

SEO 노출과 URL 공유 가능성을 우선순위로 뒀습니다. 글로벌 사용자 확보가 목적인 작업에서 "검색에 안 잡히는 다국어"는 목적을 절반만 달성하는 거라고 봤어요.

성과. 별도 정량 지표가 아니라 CS 문의 감소와 사용자 피드백 기반의 정성적 개선으로 확인했습니다. 이후 글로벌 사용자 유입이 늘어나는 흐름도 함께 관찰했지만, 그건 이 작업만의 결과가 아니라 수치로 적지 않습니다.

2. 무한 스크롤 성능 개선 — SWR을 고른 이유

문제. 숙소 이미지를 스크롤로 탐색할 때마다 새 데이터를 API로 불러왔는데, 네트워크 부하가 생기고 간헐적으로 데이터가 누락됐습니다. 데이터가 최신 상태인지 확인하기도 어려웠고요.

한 일. Intersection Observer API로 무한 스크롤을 구현해 스크롤 시점에 필요한 이미지만 로딩되게 했습니다.

이 절의 판단 — 데이터 페칭 도구 선택.

이 유즈케이스의 핵심이 캐시 무효화와 포커스 리페칭, 데이터 신선도 유지라는 점이 갈림길이었습니다. 그게 SWR의 기본값이라 설정을 거의 안 해도 됐고, 납기 안에서 가장 적은 위험으로 요구사항을 덮을 수 있었어요. 이후 프리오더·프로모션 페이지로 확장 가능한지도 확인했습니다.

성과. 페이지 로드 속도가 개선되고 콘텐츠가 끊김 없이 노출됐습니다. 다만 개선 폭을 숫자로 재두지 않았습니다 — 지금 돌아보면 이 작업이야말로 측정하기 쉬웠던 작업(요청 수, 렌더 시점)인데 안 했어요.

3. 웹→앱 전환 UX 개편과 이벤트 태깅

문제. 팬데믹 이후 해외여행 수요가 늘면서 서비스 구조를 웹 중심에서 앱 중심으로 바꿔야 했습니다. 그런데 모바일 웹 방문자가 앱으로 넘어갈 명시적인 채널이 없었고, 웹/앱 사용자 행동 데이터도 분리돼 있어 캠페인 효과를 측정할 수 없는 상태였습니다.

한 일.

1. 모바일 웹 상단 앱 설치 CTA — 모바일 유입만 타깃팅해 상단에 앱 다운로드 CTA를 노출했습니다. 캠페인 기간이 아닌 평상시 트래픽에서도 전환이 일어나도록 상시 노출 구조로 설계했어요.
2. GA4 + Firebase 이벤트 태깅과 웹뷰 동기화 — GA4 핵심 이벤트와 구글 애즈 전환 태깅을 프런트엔드에서 작업하고, 앱 내 웹뷰에서 Firebase / JavaScript 핸들러로 이벤트가 동기화되도록 구현했습니다. 이 작업으로 마케팅·데이터 팀이 Looker 대시보드에서 퍼널·전환·재방문을 한 뷰에서 보게 됐습니다.
3. 앱 설치 유도 랜딩·프로모션 구조 정비 — 캠페인 소재와 일관되게 노출되도록 이미지 구성과 CTA 위치를 재배치하고, 예약 시작·구매 완료 등 인앱 액션을 위한 웹 측 이벤트 포인트를 정리했습니다.

이 작업의 성격을 한 줄로 적으면 — 전환을 늘린 작업이자, 전환을 셀 수 있게 만든 작업입니다. 아래 수치가 존재할 수 있는 이유가 2번이에요.

성과 (담당 범위 및 그에 기여한 전사 캠페인 지표).

담당 범위 명시: 아래 수치는 2023.07~09 마케팅·데이터·디자인·개발팀이 함께 진행한 전사 그로스해킹 캠페인의 최종 지표이며, 문화체육관광부 그로스해킹 기반 관광기업 데이터 활용지원 용역사업 우수사례 보고서에 기록된 결과입니다. 프런트엔드 개발자로서 제가 담당한 범위는 웹→앱 전환 경로 구현과 이벤트 태깅 기반 구축이며, 이 작업이 캠페인 측정과 전환 유도를 가능하게 한 기반이 되었습니다.

• 상반기 대비 앱 설치율 약 600% 증가, 업계 평균 대비 앱 설치 비용 약 70% 절감
• 주요 이벤트 배너 클릭률 약 42% 증가 (충성 고객의 앱 사용량 증가에 따른 변화)
• 목표 전환율 8% 대비 평균 23.45% 달성 (7월 6.27% → 8월 30.26% → 9월 33.37%)
• 3차 캠페인 기간 앱 설치 4,622건 기록 (기존 월평균 1,400~1,500건 대비 유의미한 상승)

4. 개인화 마케팅 도구 연동 — 배포 없이 실험할 수 있게

문제. 프로모션과 기획전이 동시에 여럿 돌아가고 숙소별 혜택도 달랐습니다. 사용자 세그먼트(디바이스, 신규/재방문, 유입 UTM, 접속 지역)에 따라 다른 배너·팝업을 보여줘야 했는데, 코드 배포 없이는 노출 조건과 문구를 바꿀 수 없어 마케팅 실행 속도가 지연되고 실험 사이클이 길어졌습니다.

한 일.

1. 스마트 배너·팝업 SaaS(코드앤버터) 연동 — 마케팅 팀이 노출 조건(페이지·디바이스·UTM·쿠키·신규/재방문)을 직접 설정하도록 스크립트를 통합하고, 각 페이지에서 팝업·배너가 트리거되도록 DOM 컨테이너와 위치 포인트를 정리했습니다.
2. 제외 조건과 사용자 식별 포인트 설계 — 숙소 호스트·내부 사용자를 팝업 대상에서 빼도록 쿠키·로그인 상태·페이지 컨텍스트를 식별하는 포인트를 마련했습니다.
3. 쿠폰 랜딩·앱 설치 팝업 진입 경로 정비 — 3절의 웹→앱 전환 작업과 연계됩니다.

여기서의 판단은 "무엇을 프런트엔드가 들고 있지 않을 것인가"였습니다. 노출 조건을 코드에 두면 조건이 바뀔 때마다 배포가 필요합니다. 조건 설정 권한을 마케팅 팀에 넘기고 프런트엔드는 트리거 지점과 식별 포인트만 제공하는 쪽을 골랐어요. 그 대가로 외부 SaaS 의존이 하나 늘었습니다.

성과 (담당 범위 및 그에 기여한 전사 마케팅 지표).

담당 범위 명시: 아래 수치는 코드앤버터 스마트 배너/팝업 도입 이후 기록된 전사 마케팅 성과 지표이며, 코드앤버터 고객 성공 사례 블로그에 공개된 결과입니다. 프런트엔드 개발자로서 제가 담당한 범위는 외부 마케팅 도구 연동과 팝업 노출/제외 조건의 프런트엔드 기반 제공이며, 캠페인 기획·소재·타깃팅 조건 설계는 마케팅 팀에서 수행했습니다.

• 프로모션 홍보 배너: 배너 노출 후 매출 약 246% 상승
• 모바일 웹 앱 설치 유도 팝업: 전주 대비 앱 설치 약 92% 증가
• 쿠폰 발급 팝업: 쿠폰 발급량 약 41% 증가

캠페인 사이클이 짧아졌고, 프런트엔드 개발 리소스를 핵심 서비스 기능에 돌릴 수 있었습니다.

5. 그 외 담당 작업

아래는 "이렇게 했다"는 남았지만 선택의 근거까지는 남지 않은 작업들입니다. 하나씩 절로 늘어놓는 대신 묶었습니다.

컴포넌트 기반 스타일링 체계. 전역 CSS 충돌이 잦았고, 특히 외부에서 가져온 CSS 파일이 우선순위 문제를 일으켜 특정 요소가 안 보이는 일이 반복됐습니다. 정적 스타일은 CSS Modules, 동적 스타일은 Styled-Components의 props로 역할을 나눠 정리했어요. 성과는 하나로 정리됩니다 — 외부 CSS가 일으키던 전역 우선순위 충돌이 사라졌습니다. "품질·유지보수성 향상"류는 수치로 확인한 게 없어 적지 않습니다.

프리오더·프로모션 페이지. 숙소 이미지를 세로로 나열해 계속 스크롤해야 하던 레이아웃에 이미지 슬라이더를 붙였고, 프로모션과 프리오더의 데이터 구조를 통합해 마케팅 팀이 페이지 간 데이터를 함께 분석할 수 있게 했습니다. GA4·UTM 기반 분석 환경을 갖추고 배포 테스트 페이지로 간단한 A/B를 돌려 초기 탐색 패턴을 확인했어요. 해외 사용자 비중이 큰 페이지라 국가 코드를 관리자에서 별도 관리하고 엑셀로 데이터를 넣는 기능도 백엔드와 함께 붙였습니다.

검색. 입력 중 나가던 요청을 디바운스로 줄였습니다. 인근 지역 데이터를 검색 결과에 반영한 건 백엔드 작업이었고 저는 그 결과를 화면에 얹었습니다 — "검색 정확도 향상"은 제 작업의 성과가 아니라서 갈라 적습니다.

가격 표시와 할인 관리. 고객 화면에는 최소~최대 가격을 명시하고 할인 옵션이 있으면 할인가와 기본가를 시각적으로 구분했습니다. 관리자에서는 복잡한 할인 목록을 중요도 3분류로 나누고 셀렉트 박스를 재구성했으며, 메인과 관리자가 같은 가격 데이터 구조를 쓰도록 맞췄습니다. A/B로 표시 방식을 비교해 하나를 채택했지만, 전환율 수치는 3·4절처럼 담당 범위를 갈라 적을 근거 자료가 남아 있지 않아 적지 않습니다.

알림 시스템 내부 전환. 외부 연동으로 운영되던 알림을 내부 시스템으로 옮겼습니다. 실제 효과는 알림 문구와 대상을 외부 업체를 거치지 않고 직접 고칠 수 있게 됐다는 것이고, 관리자 페이지의 알림 추가·수정·삭제 UI를 한 화면으로 정리한 것까지가 제 범위였습니다.

돌아보면

• 선택의 근거가 남은 작업은 넷뿐이었습니다. 2년을 아홉 개 절로 적었는데, 다시 읽으니 나머지 다섯은 "무엇을 했다"에서 멈춰 있었어요. 당시에 판단을 안 한 게 아니라 기록을 안 한 겁니다. 이후 프로젝트에서 대안 비교표를 남기는 습관이 여기서 나왔습니다.
• 측정하지 않은 것이 많습니다. 무한 스크롤은 요청 수와 렌더 시점을, 스타일링은 충돌로 인한 핫픽스 건수를 셀 수 있었는데 안 셌습니다. 전사 캠페인 지표는 남아 있는데 정작 제 작업의 효과를 보여주는 수치가 없다는 게 이 문서의 가장 큰 공백입니다.
• 가장 값어치 있던 작업은 전환을 늘린 게 아니라 전환을 셀 수 있게 만든 것이었습니다(3절). 화면을 만드는 일과 그 화면의 효과를 측정 가능하게 만드는 일은 다른 일이고, 후자를 할 수 있으면 앞의 결과가 숫자로 남습니다.

참고 : 사이트 화면