GuideME App

트래블러와 현지 가이드를 매칭하고 예약·결제·알림·정산까지 처리하는 여행 가이드 매칭 플랫폼

소속: (주)가이드미
기간: 2024.12 - 2026.01
역할: 백엔드 개발자 (백엔드 및 인프라 전반 단독 담당)
기술: NestJS · TypeScript · PostgreSQL · PostGIS · Redis · RabbitMQ · Docker · AWS · GitHub Actions

(주)가이드미 — GuideME App 백엔드 개발

출처: 이력서

(주)가이드미(2024.04 - 2026.01, 정규직 개발팀 사원)에서 2024.12 - 2026.01 동안 여행 가이드 매칭 앱 GuideME의 백엔드 개발자로 일했습니다. RabbitMQ 기반 비동기 프로세스를 설계해 서비스, 요청, 푸시알림 등의 상태를 자동 감지 및 업데이트하여 운영 효율성과 데이터 일관성을 향상했습니다. Redis 캐싱을 적용해 자주 조회되는 여행/가이드 데이터를 캐싱하여 API 응답 속도를 약 40% 개선했습니다. 조회 빈도가 높은 데이터 구조 설계 시 인덱싱 및 쿼리 최적화를 반영했습니다. 주문 및 결제 모듈(주문·결제 이력 관리, PG 연동 및 취소 처리)과 주기별 자동 정산 프로세스를 구축했고, NestJS, Redis, RabbitMQ를 Docker로 컨테이너화해 배포 속도와 환경 일관성을 확보했습니다.

GuideME App — 인프라 구성과 기획·협업

출처: 이력서

AWS EC2, RDS, S3, CloudFront, Route53을 활용해 개발·운영 환경을 구축 및 배포했고, AWS Free Tier를 전략적으로 활용해 초기 개발 비용을 최소화했습니다. 기존 앱 기획서를 분석하고 신규 기능 기획에 참여해 기술적 제약사항을 고려한 구현 방향을 제안했습니다. 기획자 및 디자이너와 협업해 상품 구조 및 예약 플로우를 개선하며 사용자 경험(UX) 개선에 기여했고, 개발 초기 단계부터 기술 스펙 정의 및 API 문서화(Swagger)를 주도했습니다. 서비스는 구글 플레이스토어와 애플 앱스토어에 출시되어 있습니다.

RabbitMQ 기반 비동기 이벤트 분리와 실패 메시지 격리 정책

출처: 포트폴리오

문제

예약 처리 과정에 알림·정산 등 외부 연동이 동기 방식으로 묶여 있어 외부 API의 응답 지연이나 에러가 메인 예약 요청까지 실패로 이어졌습니다. 또 실패 메시지를 일률적으로 재처리하면서 이미 유효하지 않은 요청까지 반복 실행되어 컨슈머의 객체 생성이 누적되고 힙 메모리가 급증했습니다.

해결

동기 순차 처리와 비동기 이벤트 분리를 비교한 뒤, 핵심 상태 변경 후 RabbitMQ로 이벤트를 발행하고 즉시 응답하는 비동기 방식을 선택했습니다. 일시적 실패(네트워크/외부 API 타임아웃)는 Message Header의 retry_count 기준으로 최대 N회 재처리하고, 영구적 실패(유효하지 않은 요청/상태 변경 불가능)는 requeue: false로 즉시 제외했으며, 반복 실패 메시지는 DLQ(Dead Letter Queue)로 격리해 수동 추적했습니다. MessageQueuePort 인터페이스를 정의하고 RabbitMQ 구현체를 주입해 도메인 로직이 특정 메시지 브로커에 의존하지 않도록 설계했습니다.

결과

메인 트랜잭션과 비동기 후속 처리를 분리해 외부 연동 지연/장애의 전파를 차단했고, 무의미한 재시도를 막고 반복 실패 메시지를 DLQ로 격리하는 오류 제어 구조를 확보했습니다.

Version Key 기반 캐시 무효화

출처: 포트폴리오

문제

'내 주변 가이드 찾기' 기능은 PostGIS 반경 검색과 함께 가이드 승인 상태, 서비스 가능 여부, 차단 관계 등 복잡한 조건을 동시 조회합니다. DB 부하를 줄이려 Redis Cache-Aside를 도입했지만 검색 조건이 사용자별로 달라 Cache Key도 사용자 단위로 생성되었고, 가이드 위치가 바뀌면 영향받는 수많은 사용자별 Cache Key를 식별해 개별 삭제하는 것이 불가능에 가까웠습니다.

해결

영향받는 Key 개별 추적/삭제(사용자 수에 비례해 I/O 오버헤드 급증), TTL 기반 자연 만료(만료 전까지 정합성 오류 데이터 노출), 검색 단위 Version Key를 비교해 Version Key 방식을 선택했습니다. Cache Key에 검색 기능의 Version을 포함(nearby-guide:v1:{userId}:...)하고, 검색 결과에 영향을 주는 업데이트가 발생하면 Redis의 global:nearby-guide:version 값을 올려(v1 → v2) 이후 요청은 새 Key를 보고 이전 캐시는 TTL로 자연 소멸되게 했습니다.

결과

사용자별 Cache Key를 직접 추적하거나 삭제하지 않고도 O(1)로 캐시 정합성을 유지하는 무효화 구조를 확보했고, Redis 캐싱 적용으로 API 응답 속도를 약 40% 개선했습니다.