Google I/O 2019

by Joongi Kim

3년 전에 회사분들이 Google I/O에 간다고 했을 때 나는 박사 디펜스 2주 전이라 눈물을 머금고(...) 못갔더랬다. 이번에는 다행히 갈 수 있는 상황이 되었고 다같이 3년만에 (나 빼고) 다시 Google I/O 이벤트에 참석하였다. 그때 정규님을 비롯하여 I/O에 다녀오시고 나서 다들 엄청나게 욕(...)했는데, 이전까지는 컨벤션 센터 등 실내에서 진행하다가 그해 처음으로 Shoreline Amphitheater라는 Google Plex 근처의 야외공연장과 그 주차장을 행사장으로 활용하면서 온갖 운영상의 문제점들이 발생했기 때문이다. (게다가 I/O 참가자들에게 나눠주는 giveaway–미출시 하드웨어 샘플 같은...–도 없었다고...) 다행히 올해는 보안검색도 원활하게 진행되었고 등록 배지 수령이나 키노트 입장도 매끄러웠다. 특히 세션들은 아예 사전 예약을 받아서 일반 대기자와 사전 예약자의 줄을 구분하는 식으로 해준 덕분에 (아예 너무 많이 신청해서 넘친 경우 빼고) 제 시간에 들어가서 모두 들을 수 있었다. 하지만 3년 만에 눈에 띄는 giveaway가 없는 I/O에 다시 당첨. ㅠㅠ

개인적으로는 하나의 회사가 자신들의 기술과 그 로드맵을 가지고 이런 규모의 행사를 열 수 있다는 것, 그리고 거기에 전세계의 개발자들이 호응해서 이렇게나 많이 찾아와서 이야기도 듣고 개발에 대한 조언도 얻어간다는 것 자체가 대단한 일이라 느껴진다. 하지만 아쉬운 부분도 있었는데, TensorFlow Dev Summit과 Cloud Next 등 원래 I/O에서 함께 다루던 주제들이 별도의 이벤트로 떨어져나가면서 상대적으로 I/O는 Android와 Web 기술에만 집중했다는 점이다. (정규님의 경우 Cloud Next에도 GDE 자격으로 초청을 받았으나 NVIDIA GTC와 일주일 정도 차이로 붙어있어서 일정 상 무리인 관계로 정규님을 포함하여 모두가 직접 참가는 포기) 물론 AI, ML 관련 세션이나 샌드박스 등은 함께 진행되었지만 왠지 앞의 두 행사의 재탕 기분이랄까.

오히려 내가 주목했던 부분은 AI + Software + Hardware를 모두 아우르는 "holistic" 접근 방법을 취하고 있다는 점(물론 구글이 가진 규모의 경제 덕분에 가능한...)이나, privacy 논란을 의식한 듯 on-device ML에 대한 강조가 많이 나왔다는 점이다. 구글 CEO인 순디피차이의 키노트에서도 이런 내용들이 강조되었고, 이후 개별 관련 세션에서도 그랬다. 한 가지 예상치 못했던 장면도 있었는데, 키노트가 진행될 때 야외극장 상공에 누군가가 경비행기를 직접 몰고 꼬리에 "GOOGLE CONTROL IS NOT PRIVACY"라는 빨간색 글자를 붙인 채 계속 맴돌았다. (관중들 중 일부가 갑자기 뒤를 돌아봐서 알게 되었다) 아마도 구글이 정보생활에 너무 깊숙히 침투하면서 사생활 침해를 걱정하는 단체나 개인이 기획한 퍼포먼스가 아니었을까 싶다.

의외의 지점에서 굉장히 재미있었던 주제가 하나가 있었는데, 바로 게임 스트리밍 서비스인 Stadia의 Deep Dive 기술 세션이었다. 기존에도 NVIDIA, Steam, PlayStation, XBOX 등의 게임 플랫폼들이 클라우드 기반의 게임 스트리밍 서비스들을 다수 선보였으나, 아직까지는 입력지연 문제나 프레임 유지 문제를 제대로 해결하기보다는 하드웨어 영상 인코딩·디코딩에 의존해 가능성을 보여주는 정도에 머물렀다면, Stadia는 바로 이 기술 이슈들을 직접적으로 파고 들었다. 예를 들면 전용 컨트롤러는 스트리밍을 받아 음성·영상을 출력하는 PC와 통신하는 것이 아니라, 직접 WiFi에 연결되어 바로 Stadia 서버와 통신을 주고받는다거나, 영상·음성·진동 등 피드백 종류에 따라 뇌에서의 인지 과정이 어떤 지연시간 특성을 가지는지 고려해서 타이밍을 미세 조정한다거나, 동영상 인코딩·디코딩 방식 자체도 I/P/B frame 유형1을 직접 제어하는 식으로 해서 bitrate와 quality의 균형을 꾀한다거나 등등. 이때 발표에서 "balancing act"라는 표현을 사용하였는데, 역시 NBA 생각이 나지 않을 수 없었다. (NBA에서 말하는 balancing act는 CPU와 GPU 중 어디로 패킷을 더 많이 보내야 전체 throughput이 올라갈 수 있는가 하는 관점에서 그 균형점을 찾는 것이라면, Stadia에서는 latency와 video quality 사이의 균형을 찾는 문제다.) 게다가 네트워크 분야에서 가장 핵심 문제라고 할 수 있는 congestion control 또한 packet loss뿐만 아니라 게이머와 클라우드 사이의 라우터들이 가지고 있는 버퍼에 packet이 쌓이지 않게끔 하고자 최적화했다는 점에서 연구실 선배인 창현형의 dxTCP 논문이 생각나지 않을 수 없었다.2

이번 Google I/O는 특별한 발표나 부스 운영에 대한 부담 없이 기술세션들을 둘러볼 수 있는 시간으로, 어떻게 보면 잠시 한 템포 쉬어가는 부분이라고 할 수 있었다. 내용 구성 측면에서 아쉬운 부분도 없지 않았지만, Stadia와 같이 박사전공과 깊은 관련이 있는 내용도 나오고 해서 상당히 재밌었고, 정규님과 함께 ML GDE 및 GDG Korea 분들과도 함께 할 수 있는 시간이 있어서 좋았다. ML 관련된 내용의 리뷰는 정규님이 상세하게 적어둔 것이 있으므로 링크로 대신한다. 우리도 언젠가 I/O 같은 개발자 이벤트를 열 수 있는 날이 올까?


  1. 대략 동영상 스트리밍을 보면서 이렇게 구현하지 않았을까 짐작만 했지 실제로는 나도 이 세션을 통해 처음 알게 되었는데, I 프레임은 JPEG처럼 전체 화면 이미지를 한방에 보내고, P 프레임은 앞의 프레임과의 차이점만 보내고, B 프레임은 미래에 보내질 프레임과 합성할 수 있는 정보를 미리 보내는 것이라고 한다. Stadia에서는 낮은 지연시간을 구현하기 위해 B 프레임을 생략하고, P 프레임을 위주로 사용하되 congestion 발생 시 P 프레임에 견줄 만큼 작은 크기로 최적화된 I 프레임들을 선택적으로 보내는 방식을 사용한다. 특히 congestion control을 할 때 패킷 바이트 수가 아닌 비디오 프레임 단위를 사용함으로써 하나의 프레임을 전송 도중 패킷이 쪼개져 발생할 수 있는 예측 불가능한 지연시간을 최소화하고자 하였다.

  2. 발표에서는 Van Jacobson의 BBR을 사용했다고 밝혔는데, dxTCP는 10 Gbps 이상의 고속 네트워크로 이뤄진 데이터센터 내부망에 한정하여 congestion 문제를 해결하기 위해 마이크로초 단위의 고정밀 congestion 측정에 기반한 congestion window 크기 조절 방법이라면, BBR은 일반 인터넷(WAN) 환경에서도 쓸 수 있는 방식으로(이렇게 하려면 기존에 사용되고 있는 CUBIC과 같은 TCP congestion control 알고리즘과 호환성이 있어야 한다) 패킷 전송 사이의 간격을 조절하는 것으로, 네트워크 장비들의 buffer queue 길이를 latency를 통해 간접측정함으로써 RTT(round-trip time)를 최소로 유지하면서 delivery rate(단위 시간 당 실제 전송에 성공하는 바이트 수)를 최대화하고자 하는 기본 목표는 공유하지만 접근 방식이 다르다고 볼 수 있다. 참고로 CUBIC은 latency를 보지 않고 packet loss만을 congestion이 발생했다는 신호로 해석하기 때문에 delivery rate이 아닌 BDP (bandwidth-delay product; 특정 시점에 네트워크에 전송 중인 상태의 "in-flight" 바이트 수) 자체를 최대화하는 방향(즉, 네트워크 장비들의 packet buffer를 꽉꽉 채우는)으로 동작하게 된다. CUBIC을 설계한 Van Jacobson은 이 방식이 네트워크 장비들의 버퍼가 작을 때에만 유효한 것으로, 현재의 고성능 네트워크 장비에는 어울리지 않기 때문에 BBR을 새로 만들었다고 밝히고 있다.