[Book - 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2] 2. 주변 친구

Posted Jan 20, 2026

By Yn3 40 min read

앱 사용자 가운데 본인 위치 정보 접근 권한을 허락한 사용자에 한해 인근의 친구 목록을 보여주는 시스템이다.

1단계: 문제 이해 및 설계 범위 확정

지리적으로 얼마나 가까워야 '주변에 있다'고 할 수 있나요?
>> 5마일
>> 이 수치는 설정 가능해야 함

실제 상황에서는 직선 이동이 힘들텐데, 거리는 두 사용자 사이의 직선거리라고 가정해도 될까요?
>> yes

얼마나 많은 사용자가 이 앱을 사용하나요?
10억 명을 가정하고, 그 가운데 10% 정도가 이 기능을 활용한다고 생각해도 될까요?
>> yes

사용자의 이동 이력을 보관해 두는 것이 좋을까요?
>> yes

친구 관계에 있는 사용자가 10분 이상 비활성 상태면 해당 사용자를 주변 친구 목록에서 사라지도록 해야 할까요?
아니면 마지막으로 확잉ㄴ한 위치를 표시하도록 할까요?
>> 사라지게

사생활 및 데잍어 보호법도 고려해야 할까요?
>> 풀이 과정이 복잡해질 수 있으니 생략

기능 요구사항

사용자는 모바일 앱에서 주변 친구를 확인할 수 있어야 한다.
- 주변 친구 목록에 보이는 각 항목에는 해당 친구까지의 거리, 그리고 해당 정보가 마지막으로 갱신된 시각이 함께 표시되어야 한다.
이 친구 목록은 몇 초마다 한 번씩 갱신되어야 한다.

비기능 요구사항

낮은 지연 시간
- 주변 친구의 위치 변화가 반영되는 데 너무 오랜 시간이 걸리지 않아야 한다.
안정성
- 시스템은 전반적으로 안정적이어야 하지만, 때로 몇 개 데이터가 유실되는 것 정도는 용인할 수 있다.
결과적 일관성
- 위치 데이터를 저장하기 위해 강한 일관성을 지원하는 데이터 저장소를 사용할 필요는 없다.
- 복제본의 데이터가 원본과 동일하게 변경되기까지 몇 초 정도 걸리는 것은 용인할 수 있다.

개략적 규모 추정

‘주변 친구’는 5마일(8km) 반경 이내 친구로 정의
친구 위치 정보는 30초 주기로 갱신
평균적으로 매일 주변 친구 검색 기능을 활용하는 사용자는 1억 명으로 가정
동시 접속 사용자의 수는 DAU 수의 10%로 가정
평균적으로 한 사용자는 400명의 친구를 갖는다고 가정하고, 그 모두가 주변 친구 검색 기능을 활용한다고 가정
이 기능을 제공하는 앱은 페이지당 20명의 주변 친구를 표시하고, 사용자의 요청이 있으면 더 많은 주변 친구를 보여 준다.

QPS 계산
QPS = 1억 DAU X 10% / 30초 =~ 334,000

2단계: 개략적 설계안 제시 및 동의 구하기

개략적 설계안

메시지를 효과적으로 전송하기 위해 백엔드는 어떤 역할을 해야할까?

모든 활성 상태 사용자의 위치 변화 내역을 수신한다.
사용자 위치 변경 내역을 수신할 때마다 해당 사용자의 모든 활성 상태 친구를 찾아서 그 친구들의 단말로 변경 내역을 전달한다.
두 사용자 사이의 거리가 특정 임계치보다 먼 경우에는 변경 내역을 전송하지 않는다.

여기에는 큰 규모에 적용하기 쉽지 않다는 문제가 있다.
주어진 문제의 가정은 활성 상태의 동시 접속 사용자가 천만 명 정도라는 것이다.

그 모두가 자기 위치 정보를 30초마다 갱신한다고 하면 초당 334,000번의 위치 정보 갱신을 처리해야 하고,
사용자 1명이 400명의 친구를 갖고 그 가운데 10%가 인근에서 활성화 상태라고 가정하면,
334,000 X 400 X 10% = 1400만 건의 위치 정보 갱신 요청을 처리해야 한다.

즉 엄청난 양의 갱신 내역을 사용자 단말로 보내야 한다.

설계안

우선 소규모 백엔드를 위한 개략적 설계안부터 만들어 보자.

로드밸런서

RESTful API 서버 및 양방향 유상태(stateful) 웹소켓 서버 앞단에 위치한다.

부하를 고르게 분산하기 위해 트래픽을 서버들에 배분하는 역할을 한다.

RESTful API 서버

무상태(stateless) API 서버의 클러스터로서, 통상적인 요청/응답 트래픽을 처리한다.

이 API 계층은 친구를 추가/삭제하거나 사용자 정보를 갱신하는 등의 부가적인 작업을 처리한다.

웹소켓 서버

친구 위치 정보 변경을 거의 실시간에 가깝게 처리하는 유상태 서버 클러스터다.

각 클라이언트는 그 가운데 한 대와 웹소켓 연결을 지속적으로 유지한다.
검색 반경 내 친구 위치가 변경되면 해당 내역은 이 연결을 통해 클라이언트로 전송된다.

주변 친구 기능을 이용하는 클라리언트의 초기화도 담당한다.
모바일 클라이언트가 시작되면, 온라인 상태인 모든 주변 친구 위치를 해당 클라이언트로 전송하는 역할을 하는 것이다.

레디스 위치 정보 캐시

Redis는 활성 상태 사용자의 가장 최근 위치 정보를 캐시하는 데 사용한다.

레디스에 보관하는 캐시 항목에는 TTL 필드가 있다.
이 기간이 지나면 해당 사용자는 비활성 상태로 바뀌고 그 위치 정보는 캐시에서 삭제된다.
캐시에 보관된 정보를 갱신할 때는 TTL도 갱신한다.

레디스가 아니라도 TTL을 지원하는 키-값 저장소는 캐시로 활용할 수 있다.

사용자 DB

사용자 데이터 및 사용자의 친구 관계 정보를 저장한다.

위치 이동 이력 DB

사용자의 위치 변동 이력을 보관한다.

Redis Pub/Sub 서버

Redis Pub/Sub은 초경량 메시지 버스로, 새로운 채널을 생성하는 것은 아주 값싼 연산이다.

본 설계안의 경우 웹소켓 서버를 통해 수신한 특정 사용자의 위치 정보 변경 이벤트는 해당 사용자에게 배정된 Pub/Sub 채널에 발행한다.

해당 사용자의 친구 각각과 연결된 웹소켓 ㅇ녀결 핸들러는 해당 채널의 구독자로 설정되어 있다.
따라서 특정 사용자의 위치가 바뀌면 해당 사용자의 모든 친구의 웹소켓 연결 핸들러가 호출된다.

각 핸들러는 위치 변경 이벤트를 수신할 친구가 활성 상태면 거리를 다시 계산한다.
새로 계산한 거리가 검색 반경 이내면 갱신된 위치와 갱신 시각을 웹소켓 연결을 통해 해당 친구의 클라이언트 앱으로 보낸다.

주기적 위치 갱신

모바일 클라이언트는 항구적으로 유지되는 웹소켓 연결을 통해 주기적으로 위치 벼경 내역을 전송한다.

모바일 클라이언트가 위치가 변경된 사실을 로드밸런서에 전송
로드밸런서는 그 위치 변경 내역을 해당 클라이언트와 웹소켓 서버 사이에 설정된 연결을 통해 웹소켓 서버로 전송
웹소켓 서버는 해당 이벤트를 위치 이동 이력 DB에 저장
웹소켓 서버는 새 위치를 위치 정보 캐시에 보관
웹소켓 서버는 Redis Pub/Sub 서버의 해당 사용자 채널에 새 위치를 발행 (3~5까지의 각 당계는 병렬로 수행)
Redis Pub/Sub 채널에 발행된 새로운 위치 변경 이벤트는 모든 구독자에게 broadcast
메시지를 받은 웹소켓 서버, 즉 상기 웹소켓 연결 핸들러가 위치한 웹소켓 서버는 새 위치를 보낸 사용자와 메시지를 받은 사용자 사이의 거리를 새로 계산
7에서 계산한 거리가 검색 반경을 넘지 않는다면, 새 위치 밋 해당 위치로의 이동이 발생한 시각을 해당 구독자의 클라이언트 앱으로 전송

아래 사례를 통해 흐름을 다시 살펴보자.

사용자 1의 위치가 변경되면 그 변경 내역은 사용자 1과의 연결을 유지하고 있는 웹소켓 서버에 전송
해당 변경 내역은 Redis Pub/Sub 서버 내의 사용자 1 전용 채널로 발행
Redis Pub/Sub 서버는 해당 변경 내역을 모든 구독자에게 브로드캐스트
위치 변경 내역을 보낸 사용자와 구독자 사이의 거리, 즉 이 경우에는 사용자 1과 2 사이의 거리가 검색 반경을 넘지 않을 경우 새로운 위치는 사용자 2의 클라이언트로 전송

이 계산 과정은 해당 채널의 모든 구독자에게 반복 적용된다.
한 사용자의 위치가 바뀔 때마다 한 사용자당 평균 400명의 친구가 있으면 10%(가량이 주변에서 온라인 상태일 것으로 가정)인 40건의 위치 정보 전송이 발생할 것이다.

API 설계

웹소켓: 사용자는 웹소켓 프로토콜을 통해 위치 정보 변경 내역을 전송하고 수신한다.

최소한 아래 API는 구비되어야 한다.

[서버 API] 주기적인 위치 정보 갱신
- 요청: 클라이언트는 위도, 경도, 시각 정보를 전송
- 응답: 없음
[클라이언트 API] 클라이언트가 갱신된 친구 위치를 수신하는 데 사용할 API
- 전송되는 데이터: 친구 위치 데이터와 변경된 시각을 나타내는 타임스탬프
[서버 API] 웹소켓 초기화 API
- 요청: 클라이언트는 위도, 경도, 시각 정보를 전송
- 응답: 클라이언트는 자기 친구들의 위치 데이터를 수신
[클라이언트 API] 새 친구 구독 API
- 요청: 웹소켓 서버는 친구 ID 전송
- 응답: 가장 최근의 위도, 경도, 시각 정보 전송
[클라이언트 API] 구독 해지 API
- 요청: 웹 소켓 서버는 친구 ID 전송
- 응답: 없음

HTTP 요청: API 서버는 친구를 추가/삭제하거나 사용자 정보를 갱신하는 등의 작업을 처리할 수 있어야 한다.

데이터 모델

위치 정보 캐시와 위치 이동 이력 DB만 살펴보자.

위치 정보 캐시

위치 정보 캐시는 ‘주변 친구’ 기능을 켠 활성 상태 친구의 가장 최근 위치를 보관한다.

키	값
사용자 ID	{위도, 경도, 시각}

위치 정보 저장에 DB를 사용하지 않는 이유는?

‘주변 친구’ 기능은 사용자의 현재 위치만을 이용한다.
따라서 사용자 위치는 하나만 보관하면 충분하다.

읽기 및 쓰기 연산 속도가 빠른 Redis는 이런 목적에 아주 적합하다.
또한 TTL을 지원하므로 더 이상 활성 상태가 아닌 사용자 정보를 자동으로 제거할 수도 있다.

‘주변 친구’ 기능이 활용하는 위치 정보에 대해서는 영속성을 보장할 필요가 없으므로,
Redis 서버에 장애가 발생하면 다른 새 서버로 바꾼 다음 갱신된 위치 정보가 캐시에 채워지기를 기다려도 충분하다.

위치 이동 이력 DB

사용자의 위치 정보 변경 이력을 다음 스키마를 따르는 테이블에 저장한다.

| user_id | latitude | longitude | timestamp | |———|———-|———–|———–|

우리가 필요로 하는 것은 막대한 쓰기 연산 부하를 감당할 수 있고, 수평적 규모 확장이 가능한 DB다.
Cassandra는 그런 요구를 잘 부합한다.

RDB도 사용할 수는 있으나 이력 데이터의 양이 서버 한 대에 보관하기에는 너무 많을 수 있으므로 sharding이 필요하다.

3단계: 상세 설계

규모를 늘려 나가면서 병목 및 그 해결책을 찾는 데 집중해 보자.

중요 구성요소별 구모 확장성