저희 모두 한 번쯤은 경험해 보셨을 겁니다. 우버 앱을 열고, 현재 위치와 가고 싶은 목적지를 입력하신 후, 버튼을 한 번 누르면 탑승이 예약됩니다. 그 순간부터 두 가지 일들이 벌어지죠.00:00

한편으로는 승객님의 위치 정보가 우버와 공유되고, 다른 한편으로는 주변 운전자분들의 위치 정보가 고객님께 제공됩니다.00:08

그리고 겉보기에는 아주 간단해 보이는 일이라도, 실제로 Uber에서는 수억 명의 사용자들이 이 시스템을 원활하게 이용할 수 있도록 작동시키려면 엄청난 복잡성을 감수해야 합니다.00:15

배달의 민족 앱이 수많은 배달이사와 백엔드 서비스를 엉망인 네트워크 환경에서도 얼마나 부드럽게 업데이트할 수 있을까요? 한번 살펴봅시다. 배달의 민족은 수백만 대의 배달이사와 사용자 기기, 백엔드 서비스를 일관되게 유지해야 합니다.00:23

실시간에 가깝게, 과거에는 특정 방식에 지나치게 고집했던 우버가 결국 큰 문제에 직면하기도 했습니다. 현재는 앱이 서버에 새로운 데이터를 요청하는 폴링 기반 방식으로 전환했습니다. 간단히 말해서 클라이언트는 서버에 ‘안녕하세요’와 같은 질문을 반복적으로 하는 방식입니다.00:37

근처 운전자분들을 위한 새로운 장소는 있나요? 새로운 장소가 있나요? 새로운 장소가 있나요?00:51

그래서 이건 우버가 창업가 모드로 완전히 간 거였는데, 이 방식으로는 확장성이 없을 거라는 건 분명했어요. 한편, 클라이언트에게 새로운 데이터가 없는 모든 폴링 요청은 결국 서버에 불필요한 부담을 줘요.00:56

배터리 소모도 상당히 많고요. 폴링 요청을 할 때마다 헤더가 추가되어서, 부하가 꽤 걸리는 편입니다.01:08

이로 인해 특정 시점에 Uber 서버로 앱에서 발생하는 네트워크 요청의 80%가 폴링 호출로 이어지는 문제가 발생했습니다. 또한 여러 번의 호출이 필요해지면서 앱의 콜드 스타트 시간이 급격히 증가하는 결과를 초래했습니다.01:15

동시 폴링 호출이 경쟁하면서, 폴링 호출에서 데이터를 가져오는 동안 앱이 UI를 렌더링하는 것을 방해했습니다. 이러한 폴링 문제로 인해 우버는 푸시 기반 통신 방식으로 전환하게 되었습니다.01:27

기존에는 클라이언트가 새로운 데이터를 요청했지만, 이제 서버가 데이터가 준비되면 클라이언트에게 직접 제공하게 되었습니다.01:38

그래서, 그걸 위해서 라면을 만들었어요. 음, 실제로는 인스턴트 라면이 아니고요. RAMEN은 Real-Time Asynchronous Messaging Network의 약자예요.01:44

이론적으로는 이렇게 하면 훨씬 더 잘 작동하지만, 여전히 어려움이 따릅니다. 그래서 이제 클라이언트가 무작정 새로운 데이터를 요청하는 대신, 언제, 무엇을, 어떻게 데이터를 클라이언트에 보낼지 결정하는 로직이 필요하게 됐습니다.01:53

확장 가능한 인프라를 구축하기 위해, 이 세 가지 책임은 분리하기로 결정했습니다.02:07

먼저, Fireball이라는 마이크로 서비스를 도입했는데, 이 서비스는 업데이트를 클라이언트에게 푸시할 시점을 결정하는 역할을 합니다. 쉽게 말해, 다양한 이벤트들을 감지하고, 업데이트를 푸시할 가치가 있는지 판단하는 서비스라고 할 수 있습니다.02:12

그래서, 이런 이벤트는 사용자께서 택시를 요청하는 경우일 수도 있고, 운전기사님이 배차를 수락하는 경우일 수도 있고, 또 그래요… 탑승자나 운전기사의 새로운 위치 정보일 수도 있습니다.02:24

위치 정보가 매우 자주 변경될 수 있지만, 모든 작은 변화를 반드시 보낼 필요는 없습니다. 따라서 Fireball은 새로운 위치 정보를 이전 위치 정보와 비교하여 충분히 변경되었을 경우에만 전송할 수 있습니다. 예를 들어서요.02:32

그리고 파이어볼이 푸시를 실행해야 한다고 결정하면, 해당 정보를 유버의 API 게이트웨이로 전송합니다.02:43

이 게이트웨이는 이제 최소한의 푸시 데이터를 확인하고, 클라이언트에게 필요한 전체 데이터를 수집하는 역할을 합니다. 예를 들어, 사용자 로케일, 사용하시는 운영체제 등이 있습니다.02:50

마침내 클라이언트는 라만 서버에 직접 연결되며, 결정된 페이로드가 클라이언트로 전송됩니다.03:01

라마(Raman)은 내부적으로 어떻게 작동하나요? 원래 SSE, 즉 서버 전송 이벤트 기반으로 구축되었고, 라마는 결국 그 위에 기술을 덧씌워 만들어진 프로토콜입니다. 최소한 한 번의 전송이 보장되도록 하는 것이 특징이죠.03:07

클라이언트에 이벤트가 푸시될 때, 확실히 그곳에 도달하도록 해야 합니다.03:19

요즘에는 gRPC를 사용하도록 변경했는데, 양방향으로 메시지를 주고받을 수 있게 해 주거든요. 그래서 이제 서버가 언제든지 클라이언트에게 데이터를 보낼 수 있는 푸시 방식이 아니라, 클라이언트도 서버와 데이터를 주고받을 수 있게 된 거죠.03:23

그래서 이 인프라를 통해 우버는 이제 효율적으로 데이터를 클라이언트에게 보낼 수 있습니다. 하지만 여전히 큰 과제는 남아 있었습니다. 결국 우버는 전 세계 수백만 개의 위치에 대한 실시간 업데이트를 매분 받습니다.03:36

그러면 특정 고객이 중요하게 생각하는 위치 정보만 어떻게 전송할 수 있을까요?03:48

음, 말씀하신 대로 주변 운전자들의 위치 정보를 활용하는 방법이 있을 것 같습니다. 예를 들어, 승객의 위치를 파악한 후 모든 운전자와의 거리를 계산하여 특정 반경 내에 있는 운전자들만 보여주는 방식도 가능합니다. 하지만 규모가 커지면 수백만 명의 위치 정보를 계산해야 하므로, 효율적인 접근 방식이 필요할 수 있습니다.03:53

수백만 명의 활성 사용자들의 거리 정보로 인해 서버에 과도한 부담이 발생하게 됩니다. 그래서 우버는 훨씬 더 획기적인 방법인 공간 분할 방식을 개발했습니다.04:08

그것의 핵심적인 아이디어는 지리적 공간을 가지고, 이를 더 작은 영역으로 나누는 것입니다. 그런 다음 운전자의 위치를 파악하여 명확한 영역에 매핑할 수 있습니다.04:18

이 방법을 사용하면 더 이상 수백만 건의 거리를 계산할 필요 없이, 우리 지역과 주변 지역에 있는 드라이버만 확인하면 됩니다. 하지만 세계를 사각형으로 나누는 데에는 큰 문제가 있습니다.04:27

정사각형은 이웃하는 꼭짓점들까지의 거리가 모두 동일하지 않아서, 이를 '모서리 편향'이라고 부르게 됩니다.04:39

보시는 정사각형의 대각선 방향에 있는 정사각형들은 위나 좌우 방향에 있는 정사각형들보다 더 멀리 떨어져 있습니다. 최소한 대략적인 반경으로라도 주변 운전자들에게 간단하게 문의할 수 있다면 훨씬 더 좋지 않을까요?04:45

그래서 우버는 H3라는 오픈 소스 육각형 공간 인덱스를 개발했습니다.04:58

그래서 세계를 사각형으로 나누는 대신, 벌집 구조처럼 육각형으로 나눕니다. 각 육각형은 주변의 모든 것들과 동일한 거리를 유지하고 있습니다. 따라서 주어진 GPS 좌표에 대해 H3는 해당 좌표가 어느 육각형 안에 있는지 계산한 후, 그 H3 코드를 반환합니다.05:03

인덱스를 사용하고, 모든 운전자까지 거리를 계산하는 대신, 작성자 셀에서 K단계 이내에 있는 헥스, 즉 소위 K링을 요청하게 됩니다. 예를 들어 K가 1이라면, 첫 번째 이웃 계층이 포함되는데, 총 7개의 셀로 구성됩니다.05:17

k가 2와 같다면, 두 번째 이웃 계층도 포함됩니다.05:33

이 새로운 시스템 덕분에 시간 복잡도를 O of n, 즉 활동 운전자 수가 수백만 명에 달할 수 있는 경우에서, O of k squared plus O of m, 여기서 k는 반경이고 m은 주변 운전자 수로 정의되는 경우로 효과적으로 줄일 수 있습니다.05:36

이것은 즉, 주변에 100명의 운전자가 있을 때, 우버는 잠재적으로 수백만 명의 운전자를 검토하는 대신, 그 100명의 운전자만 확인하면 된다는 의미입니다.05:51

이 새로운 전략의 놀라운 점은 단순히 근처 운전자들을 찾는 데 사용할 수 있는 것뿐만 아니라, 우버에게 정말 중요한 훨씬 더 많은 부분에도 활용될 수 있다는 것입니다.05:59

예를 들어, 도착 예상 시간을 예측하거나 수요 예측과 같은 기능을 위해 동적인 가격 구간을 만들 수 있습니다. 그리고 이제 공간 인덱스를 통해 Uber가 서버 측 부하를 최적화하는 데 큰 도움을 받고 있습니다.06:08

라이더의 위치를 수신한 이후부터, 서버는 주변 운전자 위치를 훨씬 빠르게 조회하여 고객 앱에 더 빠른 응답을 제공할 수 있게 되었습니다. 하지만 이는 표면적인 부분일 뿐이며, 특히 모바일 앱의 경우 인터넷 연결이 항상 안정적이라고 보장할 수 없습니다.06:20

언제나 그렇듯이, 특히 우버와 같은 차량 공유 앱의 경우, 대부분의 사용자들이 집에서 사용하지 않기 때문에 안정적인 와이파이 연결보다는 셀룰러 데이터를 사용하는 경향이 높습니다. 그렇다면 우버 엔지니어들은 모바일 앱이 원활하게 작동하도록 어떤 방식으로 최적화했을까요?06:34

네트워크 환경이 좋지 않더라도 아주 부드럽게 작동하며, 살펴봐야 할 두 가지 사항이 있습니다. 우선, 모바일 기기 간의 네트워크 지연 시간을 어떻게 최소화할 수 있는지 확인해야 합니다.06:49

앱과 서버를 어떻게 최적화해야 할까요? 그리고 GPS 업데이트를 자주 받지 못하더라도 앱이 매끄럽게 느껴지도록 어떻게 해야 할까요? 우선 네트워크 트래픽을 빠르게 유지하는 것부터 시작해 보겠습니다. 여기서 우버는 이른바 엣지 서버를 사용합니다.06:58

그리고 그것은 사실 전 세계에 흩어져 있는 수백, 어쩌면 수천 개의 서버들일 뿐입니다. 각 서버는 주변 사용자들을 담당하는데, 베를린에 있는 사용자가 캘리포니아 서버와 통신하는 대신...07:11

프랑크푸르트와 같이 비교적 가까운 서버들을 사용하며, 이러한 엣지 서버는 근처 드라이버와 사용자들을 위한 주요 요청 진입점 역할을 할 뿐만 아니라, 관련 데이터를 모두 캐싱하여 데이터 접근 속도를 더욱 빠르게 합니다.07:24

일반적인 4G 연결 환경을 고려할 때, 이 변경 사항만으로도 1만 킬로미터 떨어진 원격 서버와 비교하여 로컬 서버와 통신할 때 요청 처리 속도가 약 100밀리초 정도 더 빨라질 수 있습니다.07:36

서버가 종료되더라도 새로운 위치 데이터가 동일한 간격으로 안정적으로 도착할 것이라는 보장은 없습니다.07:48

모바일 앱에서는 결국 연결 끊김을 언제든지 고려해야 합니다. 자, 그럼 우버 앱이 20초 동안 운전자로부터 세 개의 위치 업데이트를 받는 상황을 가정해 봅시다.07:53

이제 서버로부터 새로운 위치 정보가 들어올 때, 위치가 한 좌표에서 다른 좌표로 갑자기 이동하지 않도록 하는 것이 목표입니다.08:03

그래서 대신, 몇몇 알려진 위치 정보를 활용하여 운전자의 새로운 현재 위치를 예측할 수 있는 방법을 마련해야 합니다. 새로운 정보가 전송되지 않더라도요.08:09

그리고 이를 위해 우버는 '데드 레코닝'이라고 불리는 방식을 사용하는데, 이는 마지막으로 알려진 속도와 방향을 유지했다면 운전자가 어디에 위치해야 하는지를 예측하려고 시도합니다. 그런 다음, '칼만 필터'라고 불리는 것들과 함께 사용되는데, 이 필터는 이러한 정보를 결합합니다.08:20

예상 좌표와 실제 측정 좌표를 비교하여 사용합니다. 결국 이렇게 해야 자동차 마커가 부드럽게 움직일 수 있는데, 새로운 측정 좌표가 마지막 예측 좌표와 상당히 다를 때에도요. 그런데 음모론자 여러분을 위한 내용도 좀 있습니다.08:33

실제로 우버 앱에서 존재하지 않는 가짜 차량을 보여준다는 주장과 논의가 제기되고 있습니다. 존재하지 않는 차량이라면 당연히 서비스 사이트의 위치 업데이트를 들을 필요도 없고, 인위적으로 조작할 수도 있을 것입니다.08:46

더 많은 운전자들이 승객에게 사각지대를 보여주지 않아 경쟁사 앱을 사용하게 만들 수 있습니다. 이러한 유령차 현상은 Uber에서 부인하는 사항입니다.09:01

하지만 이 영상에서 보여주는 것은, 겉보기에는 단순해 보이는 인터페이스들이 종종 가장 복잡한 백엔드를 가지고 있다는 것입니다. 특히 규모를 확장해야 할 때는 더욱 그렇죠. 그리고 이번 영상에서는 새로운 시도를 해봤는데, 이 영상 제작에 많은 노력이 들어갔습니다. 그래서 여러분의 피드백이 정말 필요합니다.09:09

혹시 이해가 안 되시는 부분은 없으셨나요? 가끔씩 이런 영상들을 더 보시고 싶으신가요?09:22

혹시 그렇다면, 다음에 어떤 앱을 살펴봐 드릴까요? 모바일 개발, 특히 카톤이 관심 있으신 분들이라면, 그와 관련된 다양한 심층 튜토리얼을 위해 구독해주세요. 시청해주셔서 정말 감사합니다. 다음 영상에서 또 만나요. 멋진 한 주 나머지 보내세요. 안녕히 가세요.09:27