전시 딜 내재화 프로젝트 회고: MongoDB 기반 데이터 구축과 API 개선

전시 딜 조회를 OracleDB 기반 반정규화 테이블에서 MongoDB 기반 컬렉션으로 옮기면서, 대량 트래픽에서의 응답 지연과 운영 복잡도를 함께 줄였다.

기존에는 상품 정보는 MongoDB, 딜 정보는 OracleDB에서 각각 조회해 조합했기 때문에 매 호출마다 두 개의 DB 연결이 필요했고, 이슈가 나면 딜과 상품을 각각 추적해야 했다. Oracle Serving 테이블의 생성 로직과 갱신 주기도 다른 팀에 의존해야 해서 단위 테스트와 즉각적인 대응이 어려웠다.

이 전환은 THOR 플랫폼의 연장선에서 진행됐다. THOR는 전시서비스 개발팀이 필요한 정보만 직접 구축·운용하는 MongoDB 기반 데이터 플랫폼으로, PL/SQL 기반 Oracle Serving 테이블의 한계와 유지보수 비용을 줄이기 위한 구조였다.

전환 작업은 영향 범위가 넓고 데이터가 유기적으로 변한다는 점 때문에 단순 치환으로 끝나지 않았다. 기존에 딜 정보를 쓰는 API가 약 60개였고, 각 API마다 실제 사용 필드와 변환 로직이 조금씩 달라서, 최종적으로는 as-is vs to-be API 응답 비교용 validation 프로세스를 함께 넣어 검증했다.

데이터 구축은 Spring Batch, Kafka, MongoDB 조합으로 구성했다.

• Oracle Serving 테이블의 생성 로직에서 필요한 딜 정보 추출 부분을 분리해 수집 배치를 만들었다.
• 타임딜의 정확도를 높이기 위해 타임딜상품 정보 갱신 배치를 추가했다.
• 데이터가 많은 딜은 별도 배치로 나누고, thread-pool=5 멀티스레드로 수집 속도를 높였다.
• 추출된 딜 정보는 Zero Payload 방식으로 Kafka에 발행해 키만 전달했다.
• 적재 단계에서는 토픽을 배치별로 분리하고, 큰 볼륨의 딜은 concurrency=3으로 consume해 lag를 빠르게 줄였다.
• API 조회 시 부담을 줄이기 위해 가공 로직을 구축 단계로 집중시키고, 조회 필드에 맞춰 단일·복합 인덱스를 설계했다.

검증도 두 단계로 나눴다. 처음에는 MongoDB 신규 컬렉션과 Oracle 기존 테이블의 총 건수와 차집합, 랜덤 샘플을 비교했고, 이후에는 5분, 10분, 20분 단위 스케줄러로 실제 API 응답값을 비교하도록 범위를 넓혔다. 비교 결과는 Logstash와 ELK 스택으로 모아 대시보드에서 확인했다.

운영 중에는 몇 가지 시행착오도 있었다.

• 딜 하위의 embedded document로 상품 정보를 넣었더니, 딜 갱신 시점에만 하위 상품 정보가 갱신되어 최신 상품 정보가 반영되지 않는 경우가 생겼다. 결국 임베디드 상품 정보 활용을 중단하고 로직을 단순화했다.
• 예상보다 데이터가 16만 건에서 37만 건으로 급증하면서 수집 배치 시간이 10분까지 늘어났고, 그 사이 딜이 미노출되는 문제가 발생했다. 이를 멀티스레딩 강화와 배치 분리, 토픽 분리로 해결했다.
• 롤백 플랜을 지나치게 세분화하면 오히려 긴급 상황에서 혼란이 커진다는 점을 확인했다. 이후 롤백 장치와 단계를 최소화해 1단계 롤백 중심으로 단순화했다.
• 초기 검증은 적재 데이터만 대상으로 해서 API 레벨 문제를 놓칠 수 있었고, 최종적으로는 응답 결과 비교가 더 중요하다는 결론에 도달했다.

결과적으로 Oracle 커넥션 제거로 대량 트래픽에서의 응답 지연이 크게 개선됐고, 딜 갱신 속도도 빨라져 행사 기간 중 데이터 급증에도 더 안정적으로 대응할 수 있게 됐다. 디버깅 포인트도 Oracle과 MongoDB를 오가던 구조에서 MongoDB 중심으로 단순화됐다.

향후에는 최초 적재 이후 갱신이 필요 없는 필드와 계속 갱신해야 하는 필드를 더 명확히 분리하고, 이벤트 기반 CDC 플랫폼 Casita를 통해 딜 정보를 받아오는 방향도 검토하고 있다. 상품 정보와 딜 정보를 로직상 더 명확히 분리하면 유지보수성은 한 단계 더 올라갈 수 있다.