카카오페이 홈

Background

• 카카오페이 앱과 카카오톡에서 여러 서비스의 정보를 모아 보여주는 홈 서버 개발·운영
• 허브서버유닛 시기 홈 MAU 1,400만에서 채널서버유닛 시기 2,200만 규모로 확대
• 2023년 Server-Driven UI 도입부터 2025년 FE 개편까지, 기능 출시와 운영에 맞는 구조를 지속적으로 개선

Challenges

서비스 카드 연동 비용 줄이기

• 사용자 요청 한 건에 최대 45개 연동 API를 호출하고, 응답을 하나의 JSON으로 조합해야 하는 환경
• Spring Boot, Kotlin Coroutines, R2DBC 기반으로 논블로킹 IO와 동시 요청 조합 구현
• 서비스 카드 연동 인터페이스를 문서화하고, 규약을 준수하는 카드는 홈 서버의 추가 개발 없이 어드민 설정으로 등록하도록 구성
• Server-Driven UI 규약으로 API 버저닝을 대부분 제거하고, 기존 템플릿을 활용한 기능 출시와 UX 실험을 클라이언트 릴리스 주기에서 분리

실제 변경에 맞춰 내부 계층 정리하기

• 외부 API 변경을 격리하려 헥사고날 아키텍처를 적용했으나, 표준 연동 인터페이스 도입 후에도 내부 Port·Adapter·DTO와 매핑을 함께 수정하는 비용이 남아 있는 상황
• 복잡한 도메인 규칙보다 데이터 조합과 화면 구성이 주된 역할이라는 점을 고려해 관심사별 패키지와 단일 모듈로 정리
• 불필요한 중간 변환을 통합하되, 외부 API 응답과 클라이언트 응답의 DTO 경계는 유지
• 판단 과정은 「Hexagonal Architecture, 진짜 하실 건가요?」에 정리

비동기 코드의 실제 실행 경로 확인하기

• 논블로킹 IO와 동시 요청 조합으로 p90 응답 지연 개선
• 비동기 실행 경로의 blocking 지점을 지속적으로 조사하고 동시성 스케줄러를 개선해 p99 응답 지연도 단축
• 별도 트러블슈팅으로 IDE와 JAR 실행 시 R2DBC 커넥션 풀 초기화 시점이 달라지는 현상 조사
• 로그·lsof와 라이브러리 내부 구현을 확인해 IDE의 Actuator HealthCheck가 먼저 연결을 생성한다는 점을 검증하고, 애플리케이션 시작 시 명시적으로 warmup 수행
• 조사 과정은 「R2DBC Connection Pool 실종 사건」에 정리

FE 개편에 맞춰 데이터와 API 재설계하기

• 기존 템플릿으로 표현할 수 없는 UI는 클라이언트 릴리스가 필요해, Next.js SSR 기반 FE 개편에 맞춰 백엔드 설계·구현 담당
• JSON 컬럼이 늘어나고 필터링할 값이 JSON 내부에 있는 MySQL 구조를 검토한 뒤, 읽기 비중과 콘텐츠 구조의 유연성을 고려해 MongoDB로 전환
• Streaming 과정과 Hydration 이후 호출할 API를 구분하고 호출량을 고려해 응답 구성
• 콘텐츠성 데이터에 로컬 캐시와 Redis Pub/Sub를 적용해 반복 조회 비용 절감
• 기존 기획 히스토리를 정리하고 API 설계, 개발, 데이터 분석까지 협업 주도

Impact

• 요청당 최대 45개 API를 호출하는 환경에서 200+ TPS 처리
• p90 응답 지연 2초 → 500ms 단축
• 구조 정리 PR 기준 코드 8,000줄 이상 감소
• 콘텐츠 조회 DB 쿼리 80% 이상 감소
• 기존 템플릿을 활용한 서비스 카드 출시 기간 5주 이상 → 평균 2~3주 단축
• FE 개편 이후 새로운 UI가 필요한 기능의 릴리스 주기 5–6주 → 2주 단축. 기존 병목은 클라이언트 릴리스에 있었으며, 개편된 화면 제공 방식을 지원하는 백엔드 담당