BFF 서버에 SSE를 도입한 이유: 전시 서버의 통신 구조 재설계

들어가며 배달의민족에서 음식을 주문할 때 카테고리를 누르면 만나는 화면, 바로 가게목록입니다. 사용자가 가게를 탐색하는 첫 관문이자, 가장 트래픽이 많은 지면 중 하나입니다. 이 글은 그 가게목록 지면의 통신 구조를 재설계한 이야기입니다. 클라이언트가 여러 서버에 각각 요청을 보내던 구조를 하나의 API로 통합하고(1지면 1API), 통합이 만들어낼 병목을 SSE(Server-Sent Events) 스트리밍으로 풀어낸 두 번의 의사결정 과정을 소개합니다. ‘가게목록’이 가게목록이 아니게 되기까지 배달의민족 초기 가게목록 지면은 담백했습니다. 화면에는 말 그대로 가게 리스트만 있었습니다. 이름 그대로의 ‘가게목록’이었습니다. 지금의 가게목록은 어떨까요? 한 지면을 위에서 아래까지 펼쳐 보았습니다. 같은 지면이 맞나 싶을 정도로 많은 것이 생겼습니다. 상단 광고배너 상단 큐레이션 가게 리스트 사이사이에 들어가는 큐레이션 가게 리스트 사이사이에 들어가는 광고배너 다른 가게목록 주제로 넘어가는 테마배너 영역 처음에는 큐레이션 하나가 추가된 정도였습니다. 그런데 서비스가 성장하면서 큐레이션은 점점 늘었고, 극단적인 지면 기준으로는 한 화면에 들어가는 구좌(지면 안의 전시 영역 단위)가 12개에 이릅니다. 지면의 이름은 여전히 ‘가게목록’이었습니다. 하지만 실체는 더 이상 가게목록이 아니었습니다. 가게 리스트에 테마배너, 큐레이션, 광고배너가 섞여 편성되는 하나의 통합 전시 지면이 되어 있었습니다. 문제는 이름과 실체의 괴리가 통신 구조에도 그대로 남아 있었다는 점입니다. 하나의 지면을 그리기 위해 N개의 서버와 통신하다 구좌가 하나 추가될 때마다 클라이언트는 그 구좌의 담당 서버에 요청을 하나씩 추가해 왔습니다. 그 결과, 사용자가 가게목록에 진입하는 순간 클라이언트는 여러 서버에 각각 요청을 보내야 하는 구조가 되었습니다. 일부 구좌는 같은 서버를 바라보기도 하지만, 하나의 지면에 클라이언트가 통신해야 하는 여러 서버가 얽혀 있다는 사실은 변하지 않습니다. 호출 플로우도 단순하지 않았습니다. 먼저 지면 편성을 조회하는 API를 호출하고, 그 편성 결과에 따라 각 구좌의 서버들을 병렬로 호출하는 두 단계의 연쇄 구조였습니다. 이 구조가 만드는 고통은 입장마다 달랐습니다. 클라이언트 입장. 하나의 지면을 그리기 위해 다수의 서버와 통신해야 했습니다. 지면에 새로운 구좌가 하나 생길 때마다, 클라이언트는 그 구좌의 담당 서...