← 목차 · 케이스 5
여행 예약 플랫폼 프론트엔드 — 이전 회사 시기
2019 ~ 2024 · React · TypeScript · React Native · GraphQL
여행 예약 서비스 두 곳의 프론트엔드를 만들었습니다. 호텔·항공 예약과 결제 플로우를 화면 단위로 만들었고,
뒤에는 투어·티켓 도메인을 처음부터 만들었습니다.
클라이언트 스택은 네이티브 앱 → React Native → 웹으로 옮겨 다녔습니다.
지금 제 손을 떠난 코드이고, 성과를 숫자로 대지 못합니다. 그 이유도 아래에 적었습니다.
기간은 커밋 기록으로 확인되는 범위입니다(재직 기간은 경력표를 봐 주십시오).
이 문서는 배경 → 문제정의 → 해결방안 → 결과 → 정직하게 순서입니다(짧은 케이스라 각 절은 가볍게). 이력서의 이 절은 아래 ①②③ 블록의 첫 문장을 가져갑니다.
배경 — 지금 다루는 도메인을 화면 쪽에서 먼저 만들었습니다
여행 예약 서비스 두 곳의 프론트엔드를 만들었습니다. 상품 상세 · 옵션 선택 · 결제 · 쿠폰처럼 예약이 완성되는 구간이 담당이었고, 클라이언트 스택은 네이티브 앱 → React Native → 웹으로 옮겨 다녔습니다. 프런트엔드 8인 팀이었습니다.
문제정의 — 왜 어려운가
예약 화면은 폼이 아니라 상태 기계입니다. 그리고 그 상태 기계가 중간에 한 번 끊깁니다.
- 결제는 우리 화면 밖에서 일어납니다. 결제 창으로 나갔다가 돌아오면 브라우저 안의 상태는 사라져 있습니다.
돌아온 사용자에게 "처음부터 다시"를 시킬 수는 없습니다. - 되돌릴 수 없는 지점이 있습니다. 예약과 결제는 실행되면 취소·환불 절차로만 되돌아갑니다. 화면 단계마다 검증이 필요합니다.
- 호텔과 항공은 예약 정보의 모양이 다릅니다. 그런데 결제·여행자 정보·약관 동의는 같습니다. 공통과 차이를 잘못 그으면 양쪽이 서로를 망칩니다.
- 운영자가 데이터를 손봐야 하는 영역이 있습니다. 공급사가 보내오는 객실 정보는 자동 매핑만으로 끝나지 않아 사람이 검수합니다.
해결방안 — 무엇을 했나
예약에서 가장 손이 많이 간 곳은 화면 자체가 아니라, 사용자가 우리 화면 밖으로 나갔다 돌아오는 구간이었습니다.
돌아온 사용자에게는 결제가 이미 끝난 상태입니다. 화면이 상태를 잃었다고 해서 처음부터 다시 시킬 수 없습니다.
① 외부 결제로 나갔다 돌아오는 구간에서 화면 상태를 복원해, 결제가 끝난 사용자에게 처음부터 다시 시키지 않았습니다
- 호텔 예약 전 단계를 만들었습니다 — 약관 동의 → 투숙객·객실 정보 → 결제 → 완료. 단계별 검증과 예약 상태 관리를 포함합니다.
- 나가기 전에 필요한 것을 브라우저에 남기고, 돌아온 뒤 그 자리에서 잇습니다. 화면이 상태를 잃었다고 해서 처음부터 다시 시킬 수 없기 때문입니다.
② 항공 예약을 붙이며 호텔과 겹치는 부분을 공통 컴포넌트로 정리하고, 콘텐츠는 헤드리스 CMS와 설정 조회 하나로 합쳤습니다
- 여정·결제·요금 규정 표시가 공통 컴포넌트에 해당합니다. 호텔과 항공은 예약 정보의 모양이 다르지만 결제·여행자 정보·약관 동의는 같습니다.
- FAQ·공지·프로모션을 코드 배포 없이 바꿀 수 있게 하고, 화면마다 따로 쓰던 조회를 설정 조회 하나로 합쳤습니다.
- 운영자용 객실 매핑 검수 도구를 만들었습니다. 자동 매핑 결과에 신뢰도와 출처를 함께 보여 주고, 사람이 승인하거나 반려합니다.
③ 투어·티켓 상품 상세와 검색을 처음부터 만들었고, 네이티브 앱에서 React Native, 웹으로 스택이 세 번 바뀌는 동안 같은 도메인을 따라다녔습니다
- 액티비티·콘텐츠 서비스에서는 앱의 네이티브 화면을 웹으로 다시 만들어 앱 안에서 웹으로 서빙되게 했습니다. 같은 기능을 앱과 웹 양쪽에 두고 점진적으로 옮기는 방식이었습니다.
- 화면을 다시 만드는 일은 매번 있었고, 바뀌지 않은 것은 예약이 무엇을 지켜야 하는가였습니다. 지금 다루는 예약 도메인을 화면 쪽에서 먼저 겪은 구간입니다.
무엇을 버리고 무엇을 샀나
| 버린 것 | 산 것 | 왜 |
|---|---|---|
| 네이티브 화면의 완성도 — 웹으로 옮기면 손에 붙는 감각이 일부 깎입니다 | 배포 주기 — 콘텐츠와 화면을 앱 심사 없이 바꿉니다 | 이 서비스에서 자주 바뀌는 것은 상호작용이 아니라 콘텐츠와 상품 구성이었습니다 |
| 화면별 조회의 자유 — 화면마다 필요한 것만 가져오면 가볍습니다 | 일관성 — 설정 조회 하나로 합쳐 화면 간 값이 어긋나지 않습니다 | 같은 값을 각자 가져오면 화면마다 다른 값이 보이는 사고가 납니다 |
결과 — 측정과 지금 상태
없습니다. 이 시기에는 성과를 숫자로 남기지 못했습니다.
지금 댈 수 있는 것은 "무엇을 만들었나"까지이고, 매출·전환·사용량은 근거가 없어 쓰지 않습니다.
지금 상태 — 제 손을 떠났습니다. 이후 팀이 이어받아 운영했고, 지금 저는 그 코드에 접근하지 않습니다.
정직하게 — 한계
- 성과 수치가 없는 이유는 두 가지입니다. 당시 지표·로그에 지금 접근할 수 없고, 커밋 기록에는 사업 지표가 남지 않습니다.
숫자를 만들어 붙일 수는 있지만 면접에서 되물으면 깨집니다. 그래서 비워 둡니다. - "앱을 만들었다"고 쓰지 않습니다. 앱 저장소는 제가 합류하기 전에 시작됐고, 저는 신규 화면을 만들었고 이후 팀이 이어받았습니다.
제가 연 저장소와 제가 들어가 만든 화면은 다른 이야기라, 이 케이스는 후자만 말합니다. - 위 서술은 커밋 기록에 근거합니다. 제품 문서나 설계 문서를 가지고 있지 않으므로, 의도와 배경은 기억에 기대는 부분이 있습니다.
그런 대목은 면접에서 "기억으로 말씀드리는 것"이라고 밝히겠습니다.