|| WORXPHERE_아홉 개의 데이터 출처를 하나의 홈 응답으로 조립하기까지_
BFF 전시· <이동훈> · 2026년 1월
2026년 1월 28일, 잡코리아 메인 리부트가 런칭됐다.
약 3개월 동안 우리 팀이 맡은 역할은 `BFF Display API`였다.
프론트엔드가 메인 홈을 그리는 데 필요한 데이터를 모아, 가공하고, 한 번에 내려주는 서버다.
이 글은 “완벽한 정답”보다 “그 시점의 최선”을 선택했던 설계 기록이다.
###
- 데이터 출처가 아홉 개라서 단순 집계형 BFF로는
지연 시간을 맞출 수 없었다.
- `Kafka + 전시 DB + Worker`로 조회 전 데이터를 먼저 준비했다.
- 화면 순서/구성은 코드에서 분리해 `Screen/Section` 데이터로 운영 가능하게 만들었다.
> 중편에서는 런타임 오케스트레이션, 하편에서는 안정성 설계와 회고를 다룬다.
— -
## 1. 문제의 시작: 하나의 화면, 아홉 개의 출처
메인 홈은 사용자에게는 “한 화면”이지만,
시스템 입장에서는 여러 도메인의 집합이다.
- 광고 상품 공고 (Redis 기반 사전 가공 데이터)
- 추천 공고 (AI 추천 파이프라인)
- 테마 공고 (검색 엔진)
- 스크랩/최근 본 공고 (개인화 서비스)
- 세그먼트 정보 (세그먼트 API)
- 뉴스/커뮤니티 (콘텐츠 서비스)
- 배너 (배너 운영 시스템)
- 공고 상세 (공고 허브)
- 스마트핏 예산 (스마트핏 서비스)
처음엔 “호출해서 합치면 끝”이라고 생각했다.
하지만 실제 구현에서는 네 가지가 병목이었다.
- 광고 데이터에는 공고 ID만 있어 공고 허브 재조회가 필요했다.
- 추천 응답 포맷이 프론트 DTO와 달라 변환 계층이 필요했다.
- 스크랩 상태는 공고 조회 이후 후처리로 덧씌워야 했다.
- “지원자가 몰리는 공고” 같은 테마는 기간 집계/순위 산정이 필요했다.
핵심 질문은 명확했다.
** 여러 출처의 데이터를 어떤 경계로 조합해야,
홈 응답을 빠르게 유지할 수 있을까? **
— -
## 2. 레거시 의존 제거: 이벤트 기반 전시 DB
기존 구조는 사용자 활동 데이터(스크랩, 지원, 최근 열람 등)를 레거시 `.NET API`에 강하게 의존했다.
새 BFF의 기준으로 보면, 속도와 장애 전파 측면에서 리스크가 컸다.
그래서 읽기 전용 전시 관점의 데이터 계층을 별도로 만들었다.
- 원본 시스템이 변경 이벤트를 발행하고
- Kafka로 이벤트를 수집한 뒤
- Consumer가 전시 최적화 스키마로 적재하고
- BFF는 전시 DB를 우선 조회한다
이 전환으로 얻은 것:
- 레거시 직접 의존 감소
- 조회 성능 개선
- 데이터 신선도 개선
동시에 챙겨야 할 것:
- 이벤트 유실/중복/순서 역전에 대한 보상 로직
- 원본 대비 정합성 검증 배치
— -
## 3. 첫 번째 봉착: 실시간 계산의 한계
모든 처리를 BFF 요청 시점에 몰아넣는 접근은 곧 한계에 부딪혔다.
기간 집계와 순위 계산이 필요한 섹션은 요청당 연산 비용이 컸고, 응답 시간이 빠르게 악화됐다.
그래서 `Worker`와 `BFF`의 책임을 분리했다.
- Worker: 무거운 계산을 주기적으로 선처리
- BFF: 실시간 개인화와 응답 조립에 집중
경계 기준은 단순하게 가져갔다.
- Worker: 느리게 변하거나 비용이 큰 계산
- BFF: 사용자별로 즉시 달라지는 처리
결론적으로, **빠른 BFF 응답은 Worker의 사전 작업이 있어야 성립한다.**
— -
## 4. 두 번째 봉착: 화면 구성의 결정권
화면 순서가 코드에 고정돼 있으면, 작은 변경도 코드 수정-리뷰-배포를 거쳐야 한다.
운영 민첩성이 떨어지고, 실험 비용도 높아진다.
그래서 화면 구성 정보를 코드에서 분리해 `DataStore(Redis)`로 이동했다.
- `Screen`: 세그먼트별 전체 화면 청사진(Section 순서)
- `Section`: 각 영역의 렌더링 정보
이 구조로 배포 없이 가능해진 것:
- 세그먼트별 다른 화면 구성
- A/B 테스트용 화면 버전 분기
-