카카오 엔터테인먼트 FE·MSA 환경에서 프론트엔드가 여러 API를 직접 조합할 때 발생하는 복잡성 문제를 BFF(Backend For Frontend) 패턴과 GraphQL로 해결한 카카오페이지 웹팀의 실전 경험을 공유한다. 일반 REST API 구조와 BFF 구조를 비교해 언제 BFF가 유효한지 명확히 짚는다.
핵심 포인트 - 문제 상황: MSA에서 플랫폼(Web/iOS/Android)마다 필요한 데이터가 달라 API가 모든 플랫폼 요구사항을 포함한 과잉 응답 반환. 프론트엔드에서 복잡한 데이터 조합·변환 로직 필요 - 일반 API 구조의 4대 문제: MSA API 엔드포인트 팔로업 이슈, 브라우저 CORS, 플랫폼별 스펙 맞출 때 커뮤니케이션 비용, 화면에 필요한 데이터만 받는 partial response 구현 어려움 - BFF 개념: 플랫폼(프론트엔드)마다 하나의 전용 중간 서버를 두어 프론트엔드 요구사항에 맞게 데이터 조합·가공. "1 FE = 1 BFF"가 원칙 - BFF가 처리하는 것: API 팔로업, CORS 처리, 플랫폼별 인증 방식 통합, partial response(필요한 필드만 선택) - 카카오페이지 선택: iOS/Android/Web 중 Web만 BFF 적용. BFF 구현체로 GraphQL 선택 - GraphQL BFF 효과: 두 개의 REST API 응답을 하나의 GraphQL 쿼리로 통합, 불필요한 필드(create_dt, user_id, response_time 등) 제거, 요청 수 감소
상세 정리 - 다중 플랫폼이 없는 경우 BFF는 불필요 — 카카오페이지도 Web에만 적용한 이유 - BFF는 프론트엔드 개발자가 직접 빌드해야 프론트엔드 요구사항을 정확히 반영 가능 - GraphQL resolver: API 응답을 프론트엔드 모델 타입으로 가공(createUserWithUserVo, createCashWithCashVo) - POST 방식인 GraphQL은 브라우저 네이티브 GET 캐시 대신 라이브러리(Apollo 등) 캐시 활용 - 일반 REST 방식 대비 요청 수 감소: GET /user/get_profile + GET /store/view/cash → 단일 GraphQL 쿼리로 통합 - 렌더링 속도 개선: 프론트엔드에서 복잡한 비즈니스 로직이 줄어 UI 스레드 부담 감소 - BFF 도입 시 고려사항: 추가 서버 운영 부담, BFF 자체 장애 지점 생성, 팀 간 경계 설정
왜 읽나: 카카오페이지의 실제 BFF 도입 과정과 GraphQL 적용 코드를 통해 MSA 프론트엔드 복잡성 해소 전략과 BFF 패턴이 어떤 상황에 적합한지 구체적으로 이해할 수 있다.
Twilio Engineering·Twilio의 Programmable Messaging API로 자체 OTP 솔루션을 운영하던 서비스가 Verify API로 전환하는 방법을 코드 예시와 함께 설명한다. Verify는 OTP 전송·검증을 위한 전용 API로, 전화번호 구매, 토큰 생성, DB 저장·만료 관리를 내부에서 처리해 개발자가 직접 구현할 코드를 크게 줄인다.
요약 이어보기
포스타입·포스타입 백엔드 엔지니어가 벡터 기반 개인화 추천 시스템을 실제 운영하며 맞닥뜨린 성능 장애와 용량 문제를 해결한 과정을 담은 2부다. 수백만 개의 벡터 KNN 검색이 피크 시간대에 전체 Elasticsearch 검색 성능을 흔드는 문제부터 클러스터 OOM 사태까지, 쿼리 최적화와 인프라 분리 두 가지 경로로 근본 해결에 이른다.
요약 이어보기포스타입·포스타입이 태그 기반 추천의 한계를 극복하고 벡터 임베딩 기반 개인화 추천 시스템을 구축한 과정을 담은 1부다. 유사한 콘텐츠가 다른 용어를 쓰거나 동일한 태그가 전혀 다른 톤의 콘텐츠를 가리키는 문제를 임베딩 벡터로 해결하고, OpenSearch의 HNSW ANN 검색으로 수백만 벡터를 실시간 검색하는 시스템을 구축해 구매율 15% 향상을 달성했다.
요약 이어보기