와우배달

음식점, 고객, 라이더 사이의 배달 과정을 서버에서 처음부터 끝까지 연결했습니다.

회원과 가게, 메뉴, 주문, 결제, 배차 기능을 REST API로 구현한 개인 프로젝트입니다. 기능을 많이 만드는 데서 멈추지 않고, 실제 서비스라면 트래픽이 몰리는 지점과 데이터가 충돌하는 순간을 먼저 찾았습니다.

주변 가게 검색 방식부터 동시 배차, 외부용 주문번호, 캐시와 배포 구조까지 대안을 비교하고 선택한 이유를 코드와 문서로 남겼습니다.

단순 좌표 조회에서 시작해 네 가지 방법을 비교한 뒤, 이 프로젝트에는 S2 Geometry가 가장 적합하다고 판단했습니다.

위도와 경도의 최솟값·최댓값만 조회하면 실제 원형 반경 밖의 가게까지 읽게 됩니다. 밀집 지역에서는 결과가 커지고 같은 범위 조회가 겹쳐 DB 부담도 커집니다. GeoHash와 QuadTree도 검토했지만 경계 처리와 운영 복잡도를 함께 줄이기에는 S2 셀이 더 적합했습니다.

구현에서는 15개의 주요 도로명을 밀집 지역 목록으로 두었습니다. 목록에 포함되면 2km·Level 13, 그 외에는 4km·Level 12의 셀 토큰을 만들어 가게 데이터에 저장된 토큰과 비교합니다. 실제 인구 밀집도를 실시간으로 계산한 것은 아니며, 검색 전략을 확인하기 위한 정적 기준입니다.

같은 주문을 여러 라이더가 눌러도 배차는 한 번만 완료되어야 합니다.

낙관적 락, 비관적 락, MySQL 네임드 락을 비교했습니다. 여러 애플리케이션 인스턴스가 같은 값을 확인하고 DB 락 부담을 늘리지 않도록 Redis Set을 사용했습니다. 주문 ID를 key로, 고정 문자열을 member로 넣는 SADD는 최초 요청에서 1을 반환하고 이미 값이 있으면 0을 반환합니다. 이 반환값으로 첫 요청만 배차 단계로 보내고 나머지는 중복 요청으로 처리했습니다.

다만 이것은 Redisson이나 SETNX로 만든 완전한 분산락이 아닙니다. 현재 코드에는 TTL과 락 소유자 정보가 없으며, 배달 완료 시 Set 값을 지우는 방식입니다. Redis 등록 뒤 DB 처리에 실패하면 값이 남을 수 있다는 한계가 있습니다.

DB의 ID는 숨기고, 고객이 확인하는 주문번호와 가게번호를 따로 만들었습니다.

증가형 ID는 짧고 관리하기 쉽지만 주문량을 짐작하게 합니다. 반대로 긴 UUID를 그대로 보여주면 고객센터에서 읽고 전달하기 어렵습니다. UUID v4를 36진법으로 바꾼 뒤 7자리만 사용해 내부 정보 노출과 사용 편의 사이의 균형을 잡았습니다.

7자리 36진수로 만들 수 있는 값은 약 783억 개지만 충돌 가능성이 0이 되는 것은 아닙니다. 주문번호에는 DB unique constraint를 두어 마지막 단계에서 중복 저장을 막았습니다. 실제 운영이라면 제약조건 예외가 발생했을 때 새 번호를 생성해 다시 저장하는 흐름과 가게 public ID의 고유 제약도 추가해야 합니다.

자주 읽는 가게 정보는 Redis에서 먼저 찾고, 수정될 때만 캐시를 비웁니다.

같은 가게 상세 요청이 반복될 때마다 MySQL을 조회하지 않도록 Cache Aside 흐름을 적용했습니다. 첫 요청은 DB에서 읽어 Redis에 저장하고, 이후 요청은 캐시에서 반환합니다. 가게 정보가 바뀌면 해당 키를 지워 다음 조회에서 최신 값을 다시 채웁니다.

가게 상세 캐시의 TTL은 3분으로 두었습니다. 수정 요청에서는 같은 key를 제거해 다음 조회가 DB를 거치게 했습니다. 캐시 적용과 삭제는 Spring Boot 통합 테스트로 확인했지만, 동시 사용자 수에 따른 응답 시간과 DB 조회 감소량은 아직 측정하지 않았습니다.

학습용 개인 프로젝트의 비용을 기준으로 AWS 구조를 설계했습니다.

NLB의 고정 IP를 거쳐 ALB가 HTTP 요청을 나누고, Private Subnet의 애플리케이션과 데이터 영역으로 전달합니다. MySQL, Redis, Kafka는 비용을 고려해 EC2의 Docker 컨테이너에서 운영하고 Jenkins로 배포 흐름을 이어가는 구조로 정리했습니다.

현재 저장소에서 바로 확인할 수 있는 배포 자산은 Dockerfile과 Kafka용 docker-compose입니다. NLB·ALB·Subnet·Jenkins 구조는 README에 남긴 설계안이며, Terraform이나 CloudFormation으로 재현 가능한 상태는 아닙니다.

기능을 더 붙이기 전에 실패했을 때 복구할 수 있는 구조와 재현 가능한 검증 환경부터 만드는 것이 우선입니다.

프로젝트를 다시 점검하면서 설계 문서에서 기대한 수준과 실제 코드 사이의 차이를 정리했습니다. 아래 항목은 이미 해결했다고 포장하지 않고, 다음 구현에서 우선 처리할 기술 부채로 남겼습니다.

기술 부채를 먼저 정리한 뒤 MSA로 나눈다면, Redis 세션을 그대로 옮기지 않는 쪽으로 검토했습니다.

모든 서비스가 하나의 세션 저장소를 바라보면 확장할수록 Redis 의존성과 결합도가 커집니다. API Gateway에서 공통 인증을 처리하고, 각 서비스는 필요한 최소 정보만 담은 토큰을 검증하는 방향을 검토했습니다. JWT도 강제 로그아웃과 정보 변경을 즉시 반영하기 어렵고, 만료 시간을 줄이면 갱신 비용이 늘기 때문에 서비스 규모에 맞춘 설계가 필요합니다.

회원가입부터 가게 조회, 주문과 결제, 라이더 배차까지 배달 서비스의 주요 흐름을 API로 구현했습니다. 각 기능을 단순히 연결하는 데서 끝내지 않고, 위치 검색의 정확도와 조회 부하, 동시성, 외부 정보 노출, 운영 비용까지 하나의 서비스 관점에서 검토했습니다.

동시에 구현하지 못한 부분도 분명합니다. Redis Set은 완전한 분산락이 아니고, Kafka에는 Outbox와 DLQ가 없으며, AWS 설계는 IaC로 재현되지 않습니다. 대신 어디까지 구현했고 무엇을 더 검증해야 하는지 구분해 다음 작업의 우선순위를 정할 수 있게 됐습니다.