데이터를 불러오는 중입니다...
외부 파트너사의 예약 API를 연동하여 골프 예약 및 마이페이지 기능을 구축하는 프로젝트를 단독으로 수행했습니다. 예약 데이터의 주도권이 전적으로 외부 시스템에 있는 한계 속에서, 안정적인 예약 흐름을 보장하고 외부 장애로부터 내부 시스템과 사용자 경험(UX)을 방어하는 아키텍처를 설계하는 데 집중했습니다.
모든 예약 데이터가 파트너사 서버에 존재했기 때문에, 두 가지 구조적 리스크가 동시에 존재했습니다.
| 대안 | 접근 | 기각 사유 |
|---|---|---|
| 서버 큐잉 | 서버에서 요청을 큐에 넣고 중복 필터링 | PHP 요청당 프로세스 모델에서 서버 사이드 큐 유지 불가, Redis 등 별도 인프라 필요 |
| DB 기반 잠금 | 예약 요청 시 DB에 잠금 레코드 생성 | 외부 API가 데이터 원본이므로 내부 DB 상태와의 동기화 문제 발생 |
| 클라이언트 선제 차단 + UX 장애 격리 (채택) | 프론트에서 중복 차단, 외부 장애를 사용자에게 우아하게 안내 | — |
추가 인프라 없이 가장 빠르게 적용 가능하며 사용자 경험을 직접 제어할 수 있다는 점에서 채택했습니다.
500)로 처리하지 않고, HTTP 상태 코드와 응답 시간에 따라 분기하는 안내 로직을 설계했습니다. 타임아웃(30초 초과) 시 "일시적 혼잡" 안내, 서버 에러(5xx) 시 "잠시 후 재시도" 안내로, 외부 장애가 당사 서비스 신뢰도 하락으로 이어지지 않도록 했습니다.초기에는 모든 cURL 통신 로그를 메인 비즈니스 DB에 직접 INSERT했습니다. 수개월 만에 수백만 건 이 적재되면서 두 가지 심각한 문제가 동시에 발생했습니다.
| 대안 | 접근 | 기각 사유 |
|---|---|---|
| DB 파티셔닝 | 월별 파티셔닝 또는 아카이빙 | 쓰기 비율 99%인 로그 특성에 부적합, 근본적 DB 부하 미해결 |
| 별도 로그 DB | 로그 전용 DB 구축 | 인프라 비용 증가, 소규모 프로젝트에 과도한 구성 |
| 파일 시스템 + 인메모리 버퍼링 (채택) | DB 완전 우회, 버퍼링으로 I/O 최소화 | — |
로그는 쓰기가 99% 이상이고 실시간 쿼리가 불필요하므로, 파일 시스템이 가장 적합하며 추가 인프라 없이 즉시 적용 가능하다고 판단했습니다.
try-catch로 격리. 파일 권한 오류나 디스크 부족이 발생해도 메인 예약 트랜잭션에 영향 없음이 챌린지의 기술적 상세(버퍼링 구현, 설계 근거, 코드 레벨 분석)는 인사이트 외부 연동 시스템에서의 로깅 분리와 버퍼링 전략 에서 깊이 있게 다루고 있습니다.
winston + winston-daily-rotate-file을 경험하며, 로그 레벨 분리와 자동 파기 정책의 필요성을 체득했습니다. ELK 스택 기반 중앙 집중형 수집 체계로 확장하여 운영 가시성을 확보할 것입니다.