|| WORXPHERE
잡코리아와 알바몬이 30주년을 맞아 ‘리부트데이’를 진행했습니다.
브랜드와 서비스 전반을 다시 정의하는 시점이었고, 메인 화면을 포함한 여러 영역에 변화가 있었습니다.
이번 개편에는 AI 기반 추천 영역 등 사용자에게 직접 보이는 변화도 있었지만, 그와 동시에 전시 시스템의 기반 구조 역시 함께 점검해야 하는 시점이었습니다.
이 글에서는 리부트데이 개편 과정에서 진행한 전시 시스템 재설계와 CPT 광고 전시 현대화에 대해 이야기합니다.
기존 구조: 서로 다른 전시 방식
잡코리아
.NET Framework 기반
DB Batch를 통해 데이터 적재
Kibana 스케줄을 통해 Output Cache(HTML) 사전 생성
요청 시 생성된 HTML을 응답
알바몬
SCDF(Spring Cloud Data Flow) 기반 파이프라인
배치로 데이터를 읽어 가공
캐시에 적재 후 화면에서 조회
두 서비스는 구현 방식은 달랐지만 공통점이 있었습니다.
배치 중심 구조
실시간 반영의 제약
서비스별 개별 구현
확장성과 재사용성의 한계
그리고 하나 더, 중요한 공통점이 있었습니다.
전시 데이터가 특정 저장소에 강하게 의존하고 있었고,
전시 트래픽이 곧 해당 DB 계층에 직접적인 영향을 주는 구조였다는 점입니다.
이는 구조적으로 단일 장애 지점(SPOF)의 가능성을 내포하고 있었습니다.
전시 영역에서 문제가 발생하면, 그 영향이 운영 트랜잭션 계층까지 전파될 수 있는 형태였습니다.
평시에는 큰 문제가 드러나지 않았지만,
트래픽 피크나 장애 상황을 가정하면 구조적 리스크가 존재하는 상태였습니다.
기존 전시는 서비스별로 개별 구현되어 있었고,
배치 중심 구조로 운영되고 있었습니다.
특정 저장소에 대한 의존도가 높아,
전시 트래픽이 운영 DB에 직접적인 영향을 줄 수 있는 구조적 리스크(SPOF 가능성)도 존재했습니다.이번 개편은 단순한 정리가 아니라,
전시를 독립된 레이어로 다시 정의하는 작업이었습니다.
운영 트랜잭션과 분리된 구조 위에서
안정성과 확장성을 확보하는 것이 목표였습니다.이 관점의 전환이 재설계의 출발점이었습니다.excalidrawSpring Batch + RDS + Cache Layer 구조로 전환
기존 MSSQL 기반 DB Batch 및 서비스별 배치 구조를 정리하고,
Spring Batch 기반의 통합 배치 구조로 전환했습니다.
새로운 구조는 다음과 같습니다.
Spring Batch를 통해 전시 데이터 생성
전시 전용 RDS(PostgreSQL)에 저장
별도 애플리케이션이 RDS 데이터를 읽어 Redis에 적재
서비스는 Redis(Cache Layer)를 1차 조회 계층으로 사용
여기서 중요한 점은 Redis 적재를 별도 애플리케이션으로 분리한 것입니다.
이를 통해:
배치 로직과 캐시 적재 로직의 책임 분리
캐시 구조 변경 시 배치 영향 최소화
운영 중 유연한 확장 가능
이라는 구조적 이점을 확보했습니다.
캐시를 1차 조회 계층으로 설계하다
이번 개편에서 가장 중요한 전환은
캐시를 보조 계층이 아닌 정상 경로의 1차 조회 계층으로 설계한 것입니다.
구조는 다음과 같습니다.
클라이언트
→ BFF
→ Redis(Cache Layer)
→ (예외 시) Internal API → RDS
정상 경로에서는 DB를 직접 조회하지 않습니다.
RDS는 데이터 소스 역할에 집중하고,
전시는 Redis를 기준으로 동작합니다.
캐시에는 단순 key-value가 아니라,
페이지 단위로 정리된 전시 데이터를 저장했습니다.
정렬된 광고 리스트
노출 우선순위 계산 결과
광고 메타 정보
전시용 JSON 단위 데이터
즉, 화면이 필요로 하는 형태 그대로를 캐시에 저장했습니다.
이번 전시 구조는 단순한 Cache-Aside 패턴이 아닙니다.
요청 시 데이터를 채우는 방식이 아니라,
Spring Batch와 이벤트 기반 동기화를 통해 데이터를 사전 적재하고
캐시를 1차 데이터 접근 계층으로 두는 Cache-First 전략을 선택했습니다.
리부트데이 전시구조 재설계
생성 일시
2026/03/06 07:06
최종 편집 일시
2026/03/06 07:06
태그
잡코리아
파일과 미디어