Read Original
#Frontend

여기어때 해외투어 프론트엔드 구축기록

여기어때 해외투어 프론트엔드 구축기록
01

Summary

단 2명의 개발자가 25주 만에 웹과 앱 웹뷰 37개 화면을 완벽 구축한 모노레포 생존기

재사용 가능한 아키텍처와 치밀한 API 분리 전략으로 개발 속도와 안정성을 극대화한 프론트엔드 연동 노하우

여기어때 프론트엔드 팀이 모노레포 기반으로 신규 해외투어 서비스를 25주 동안 구축한 실전 프로젝트 기록입니다. 기존 시스템 기반 재활용, Storybook 중심의 단계별 개발, mock 및 API 계층 설계, 웹/앱 웹뷰 간 통합 브릿지 처리 등 실무 프론트엔드 엔지니어링의 핵심 패턴들을 다룹니다.

  • 01기존 항공 모노레포 아키텍처 재사용을 통해 초기 환경 구축 시간을 절감하고 50개의 공용 컴포넌트 구축
  • 02Storybook 스토리 123개와 테스트 케이스 492개를 작성하여 API 미완성 상태에서도 디자이너 검수 및 QA 안정성 확보
  • 03API transport 함수 내부에서만 mock을 반환하도록 설계하여 실 API 전환 시 단 9줄 추가로 리팩토링 완수
  • 04결제 실패 및 뒤로가기 이탈 방지를 위해 자식 네이티브 웹뷰와 브릿지를 활용한 이커머스 결제 파이프라인 완성
  • 05Socket.IO 대신 순수 브라우저 WebSocket과 REST 폴백 기반의 독립 실시간 채팅 앱 구축

RECOMMENDATION

모노레포 도입을 고민 중이거나 백엔드 API 완성을 기다리지 않고 UI 개발을 병행해야 하는 프론트엔드 엔지니어 및 테크 리드에게 추천합니다.

The Problem

개발자 단 2명이서 25주 동안 웹과 앱 웹뷰를 아우르는 37개 라우트와 실시간 해외투어 채팅 시스템 등 광범위한 프론트엔드 영역을 구축해야 했습니다. 또한 백엔드 API가 완성되기 전에 UI 개발 및 정책 검증을 동시에 진행해야 하는 난관이 있었습니다.

The Solution

기존 항공 서비스에서 검증된 모노레포 아키텍처와 Provider 스택을 재사용하고, 아토믹 컴포넌트부터 페이지까지 순차 개발하는 단계별 방식을 채택했습니다. Storybook으로 디자이너 검수 환경을 구성하고, API 계층을 호출 함수 내부로 격리하여 mock 데이터에서 실 API 전환 시 화면 코드 수정을 최소화했습니다.

The Result

37개 라우트 오픈과 공유 패키지 내 50개 컴포넌트 생성을 달성하였으며, QA 기간 중 발생한 280건의 티켓을 81%의 3일 내 처리율로 해결했습니다. 출시 이후에도 CDN 파라미터 최적화만으로 상품 이미지 전송량을 90% 감축하는 정량적 성과를 거두었습니다.

Trade-off

화면 우선 개발 방식으로 인해 동일한 API 호출 함수가 중복 생성되는 혼란이 발생하여 위치 규칙을 재정의해야 했습니다. 또한 공유 패키지 변경이 기존 모노레포 내 다른 서비스(항공)에 영향을 줄 위험이 있어, master 브랜치 기반 분기 및 역머지 금지 등의 엄격한 브랜치 관리 규칙을 감수해야 했습니다.

03

Key Concepts

Concept · 01

모노레포 공유 패키지 (Monorepo Shared Package)

여러 서비스나 앱 간에 공통으로 사용하는 컴포넌트, 유틸리티, 디자인 시스템 등을 하나의 레포지토리 내 격리된 패키지로 관리하는 구조입니다.

  • 기존 항공 서비스에서 검증된 Provider 스택 및 디자인 시스템(YDS)을 재사용함
  • 해외투어 프로젝트 추진 과정에서 발생한 결제 UI, 이미지 모달 등 50개 컴포넌트를 공용 패키지에 추가 분리함
Concept · 02

API Transport 계층 격리

화면 컴포넌트가 직접 API를 호출하지 않고, 전송 전용 함수(transport)만을 호출하도록 분리하여 내부 데이터 처리 로직 및 Mock 전환을 독립시킨 설계 패턴입니다.

  • Mock 데이터를 transport 함수 내부에서만 반환하여 실 API 전환 시 화면 코드 변경을 15줄 이내로 최소화함
  • 소비 범위에 따라 앱 공용, 도메인, 화면 폴더로 API 함수 위치 규칙을 문서화하여 중복 저장을 방지함
Concept · 03

자식 네이티브 웹뷰 (Child Native WebView)

메인 웹뷰 위에서 결제 등 독립적인 외부 세션을 처리한 뒤 부모 웹뷰로 결과값 전달 및 이탈 없이 복귀하기 위해 사용되는 네이티브 브릿지 기반 웹뷰 패턴입니다.

  • PG 결제창 진입 시 결제창 내 뒤로가기 누름에 따른 주문서 데이터 유실을 방지하기 위해 사용함
  • 자식 웹뷰가 결제 결과를 localStorage에 저장을 마친 후 닫히면 부모 웹뷰가 이를 감지해 처리 확인 페이지로 전환함