앞 글에 이어서 두번째로 북태평양 상공(...)에서 작성하는 글. NVIDIA GTC 다녀오고 나서 금방 쓰려고 했다가 일이 바빠서 못 쓰고 결국 다음 출장 비행기(...) 안에서 쓰게 되었다. (이 블로그는 글의 작성날짜만 기록하는데, 앞글과 날짜를 같게 하니 순서가 반대로 나와서 일부러 하루 뒤로 지정했다)

지난 3월 16일부터 25일까지 산호세에서 열리는 NVIDIA GPU Tech Conference (GTC)에 회사 동료들과 함께 세션 발표 및 Inception Partner 부스를 하러 다녀왔다. 이는 작년 한국에서 진행했던 NVIDIA AI Conference에서 Inception Award를 수상하면서 얻은 기회였고, 우리 회사로서는 해외진출의 첫 발을 내딛는 중요한 이정표이기도 했다.

한 마디로 소감을 요약하면, 발표든 부스든 했을 때 찾아와서 질문하는 내용 자체도 다르고 사람들의 반응도 완전히 달랐다는 것이다. 우리나라에서도 꽤 많은 수의 업계·커뮤니티 컨퍼런스에 발표나 부스 형식으로 참가해봤는데, 대부분 Backend.AI 제품 소개를 하고 나면 가격이나 세일즈 정책부터 물어보거나 시니어 엔지니어분들의 경우 kubernetes (k8s) 안 써도 괜찮아요? 내지는 안 썼는데 팔 수 있겠어요? 같은 걱정(?)을 한다. 이제 영업망을 꾸려가고 있는 스타트업으로서 가격에 대한 내부 기준표가 있기는 하지만 아직은 수익화보다는 고객 확보 관점에서 case-by-case로 협상 및 맞춤전략을 적용해야 하는 경우가 많아서 바로 현장에서 대답하기 어려운 경우가 많고, 왜 다른 크고 잘 되고 있는 오픈소스를 가져다 쓰지 않았냐는 점에 대해서는 우리가 이 프로젝트를 시작할 때는 k8s가 쓸만하지 못했다는 점이나 설계 목표가 달라서 바로 적용이 어려운 부분이 있어서인데 이렇게 답하면 뭔가 불안해하는 듯한 눈빛이 돌아온다. 한국에서 컨퍼런스에 부스 업체로 참가하고 나면 뭔가 우리가 크게 잘못하고 있는 건가 하는 느낌마저 들 정도였으니까.

그런데 여기서는 일단 사람들 반응 자체가 직접 개발했다는 점을 굉장히 크게 칭찬하고 높게 평가하였다. 물론 미국 특유의 과장된 "very good" 표현임을 감안하더라도, 세부 내용을 설명하며 대화를 주고받아보면 직접 필요한 문제를 찾아서 해결하고 그걸 하나의 완결된 제품 형태로 만들어냈다는 점에 높은 점수를 주는 느낌이다. 우리가 나름 기술적 강점으로 내세우는 컨테이너 수준 GPU 가상화의 경우도 사실 그 기술을 만든 내 입장에서는 컨테이너 기반 환경에서 어떻게 하면 레거시 라이브러리의 자원 제약을 올바로 구현할 수 있을까—수업 데모 진행하다가 실제 서버 터져본 경험을 바탕으로—에서 출발해서 CUDA에도 비슷한 아이디어를 적용하다보니 나온 일종의 부산물이다. 즉, 처음부터 GPU 가상화를 목표로 삼아서 만든 게 아니라, 컨테이너 기반 환경의 연산자원 제공 서비스를 만드는 과정에서 나온 여러 문제들 중 하나를 해결한 것뿐이다. 이곳 참관객들은 이러한 스토리텔링에 매료되는 것 같았다.

며칠 동안 GTC 부스 운영하고 나서 문득 RiseML이라는 독일의 스타트업이 생각났다. 우리가 나름대로 잠재적 경쟁사가 될 수 있다고 보고 생각날 때마다 한번씩 동향을 살펴보던 곳인데, GTC 기간 중 검색해보니 올해 초에 망했다. 이 회사는 철저하게 k8s에 집중해서 모든 기능을 k8s와 그 플러그인으로 구현한, CLI를 통해 원하는 만큼 자원량을 가지는 컨테이너를 프로비저닝하고 접속하고 코드를 돌릴 수 있게 해주는 플랫폼을 개발하고 있었다. 즉, GPU를 포함한 연산자원을 딥러닝이나 머신러닝 하는 사람들이 쉽게 쓸 수 있게 해주겠다는 컨셉을 공유한 셈이다. 게다가 블로그 글에서 cachefilesd를 도입해서 I/O 성능을 높인 사례라든지 TPU가 처음 나왔을 때 발빠르게 GPU와의 비교 벤치마크를 기사로 작성해서 주요 개발자 커뮤니티에 공유해 회자되는 등 상당히 기술 마케팅 관점에서도 잘 하고 있기도 했다. 심지어 우리 내부에서는 기술 블로그를 저 회사처럼 쓰면 좋겠다는 이야기도 했었을 정도였다.

RiseML은 왜 망했을까? 그쪽 내부 사정은 잘 모르겠지만, GTC에서의 반응으로 유추해보건대, 크게 2가지 이유가 아니었나 싶다. 첫번째는 너무나 k8s에 의존한 나머지, 자신들만의 강점을 내세우기가 어려웠을 거라는 점이다. 직접 제품 매뉴얼을 내려받아 살펴보기도 했는데, 훌륭한 integration을 했다는 느낌이긴 한데 그중의 8할은 이미 있는 k8s에서 가져온 느낌이랄까. 물론 integration을 잘 하는 것도 매우 어려운 일이고 그 일 자체에 대한 가치를 부정하는 건 아니지만, 핵심기술이 자신의 것이 아니라는 점은 회사의 장기적 생존전략(특히 초기 기술 스타트업에 대한 가치평가 관점)에서 약점으로 작용할 수 있다. 두번째는 GUI의 부재다. 우리도 작년 말~올해 초 몇몇 고객을 확보하면서 절실하게 필요성을 깨닫고 불완전하나마 계속 선공개 및 피드백을 받아 개선해나가고 있는데, 연산플랫폼의 사용자들 중 SW엔지니어 배경을 가지지 않은 사람들이 상당히 많다. 우리 고객 중에도 아예 터미널 사용법 자체를 모르는 경우도 있을 정도다. RiseML은 개발자가 보기에 꽤 준수한 CLI를 제공했지만 타겟 고객층의 나머지 절반을 잡는 데 실패한 것일지도 모른다. 독일의 시장 환경이 어떤지 모르지만, 어쩌면, 우리나라에서였다면 대형 IT 고객사들로부터 k8s 기반 플랫폼 개발 수주를 받아 살아남을 수 있었을는지도 모를 일이다.

최근에 여러 경로를 통해 BitFusion이라는 곳에서 만든 FlexDirect라는 GPU 가상화 솔루션을 접했다. 돌이켜보니 여기도 비슷한 문제를 겪을 수 있겠다는 생각이 들었다. 이곳의 핵심 제품인 FlexDirect는 Ethernet으로 사용 가능한 원격 GPU farm 솔루션이다. AWS의 Elastic GPU 기능과 개념 상으로는 거의 같은데, 하나의 GPU를 쪼개서 여러 노드나 VM이 쓸 수 있게 하는 기능을 지원한다는 점에서 우리의 GPU 가상화 기술과 비교되는 부분이 있다.¹ 네트워크 기반 원격 연결이라는 점에서 아키텍처 구성을 매우 유연하게 할 수 있다는 장점을 지니지만(예를 들면 CPU 노드는 A 클라우드를 쓰고 GPU 노드는 B 클라우드에서 돌린다거나, CPU/GPU 노드의 스케일링을 별도로 한다거나), 네트워크를 타기 때문에 10 Gbps 이상의 고대역폭과 저지연 환경이 받쳐주지 않으면 필연적으로 성능 오버헤드가 발생할 수밖에 없다. 특히 내가 박사과정 때 10~40 Gbps급 Ethernet을 가지고 패킷 처리 프레임워크를 개발해본 경험에 의하면 고속네트워킹을 사용하는만큼 CPU 노드의 성능 오버헤드가 추가로 더 생기는 구조이다. 앞으로 NVIDIA와 Mellanox가 뭔가 합작해서 GPU와 NIC 간의 통신을 극적으로 최적화한다면 일정 부분 해결될 수 있는 문제이긴 하나, 마찬가지로 제품의 가장 핵심을 구성하는 기술이 BitFusion이 아닌 다른 누군가의 손에 의해 좌지우지되는 결과가 될 수 있는 것이다.

거꾸로 돌아와서, 그러면 과연 우리는 잘 하고 있는가?

나와 우리 회사 초기 멤버들이 처음 Backend.AI 프로젝트를 구상하기 시작한 것은 2015년이다. 그때 나는 ACM EuroSys에 NBA 프레임워크로 논문을 발표했고, 이 학회에서 Google이 Borg 프레임워크에 대한 논문을 발표하였다. 이 Borg를 오픈소스화하여 3개월 뒤 v1.0을 찍은 것이 바로 지금의 Kubernetes다. 그러니까 우리가 처음 Backend.AI를 만들려고 할 때는 k8s가 그다지 쓸만하지 않았다는 얘기고, 이듬해인 2016년에서야 nvidia-docker가 나와서 GPU를 컨테이너에 붙여서 쓸 수 있겠네 하는 정도였다. 그 상황에서 컨테이너 안에 여러가지 연산소프트웨어들을 설치하고 돌려보니 온갖 문제들이 발생했고, 이걸 하나씩 해결함과 동시에 어떻게 하면 연산소프트웨어만 쓸 줄 알고 인프라 관리를 하나도 모르는 사람이 이 시스템을 쓸 수 있게 할 것인가라는 관점에서 제품 개발을 진행하였다. 그러다보니 남들이 문제를 겪기 전에 먼저 문제를 겪은 것들이 많았고, 어떤 경우에는 해결하고보니 다른 곳에서도 뒤이어 솔루션을 발표하는 걸 지켜보기도 했다.

그 과정에서 우리가 다른 큰 회사들(Google이라거나 Docker라거나...)에 비해 관련 agenda를 먼저 선점하지 못한 것은 아쉬운 부분이다. 하지만 3명짜리 스타트업에서 할 수 있는 것은 많지 않았고, 꾸준히 PyCon을 비롯해 다양한 컨퍼런스에서 발표한 것과 Backend.AI 자체를 오픈소스로 공개해둔 것이 그나마 부족한 영업력을 보완하는 하나의 돌파구였다. 다행히 그런 과정을 통해 나름의 영업 성과들이 있었고, Backend.AI의 기초에 대해 어느 정도 확신을 가지게 된 후에는 "거인의 어깨에 올라타자"는 컨셉을 가지게 되었다. AWS나 NVIDIA와 경쟁하는 것이 아니라, 그들이 정책적·사업적 이유로 만들지 못하는 틈새 기술을 가지고 그들의 이름과 영업망에 올라타자는 것. 좋은 투자자들을 만나고 자체적인 기술력을 나름대로 인정받고 있는 덕분에 조금은 더 긴 호흡으로 갈 수 있는 행운이 함께하고 있기에 가능한 전략이기도 하다.

그래서 이번 GTC를 비롯해 올해의 샌프란시스코 출장들이 더욱 큰 의미로 다가온다. TensorFlow Dev Summit 때에는 Bay Area AI Meetup에 가서 실리콘밸리의 MLaaS 스타트업들이 어떤 agenda를 가지고 가는지 살펴보았고, GTC에서는 자신만의 agenda와 기술 개발에 대한 스토리텔링을 가지고 있는 것이 얼마나 실리콘밸리에 어필할 수 있는지 알게 되었다. 우리가 영업적 스케일이 딸려서 그렇지 미국 기준으로도 잘 하는 축에 든다는 자신감도 생겼다. Backend.AI에 적용한 GPU 가상화 기술도 처음부터 의도한 설계라기보다는 우리가 푸는 문제의 범위에 맞춰서 만들다보니 그리 된 것에 가깝지만, 다행히 비슷한 목적을 가진 다른 기술들과 비교했을 때 장점으로 볼 수 있는 부분이나 배경 기술의 로드맵에 잘 올라탈 수 있는 형태라는 점에서 일단 접근방법이 (운 좋게도) 좋았구나 싶다.²

한편으로 드는 소회는—박사과정때도 느꼈던 것이지만—여러가지 일을 합해서잘 해주는 프레임워크를 가지고 한눈에 알아보기 쉬운 마케팅 phrase를 만들기가 정말 어렵다는 것이다. 대학원 때 패킷 처리 파이프라인을 좋은 성능으로 "쉽게" 그리고 "덜 실수하며" 만들 수 있다는 점을 결국 논문 작성을 위한 차별점으로 풀어내지 못했고, CPU/GPU 간의 동적 부하분산 알고리즘을 넣고 거기에 방점을 찍고 나서야 제대로 논문을 발표할 수 있었다. (박사과정 3년차가 되어서야 겨우 처음 발표한 그 full paper가 바로 EuroSys 논문이다.) 지금도 비슷한 것이, 연산자원을 쉽고 편하게 쓸 수 있다는 점만으로는 고객 설득이 어려웠는데(더군다나 제대로 된 GUI도 없이!), GPU 가상화라는 어떤 하나의 기술적 마일스톤을 찍고나니 그걸 지렛대 삼아 좀더 쉽게 사람들을 설득할 수 있게 되었다. 무언가 tipping point를 지난 느낌이라고 해야 하나. 이런 종류의 일은 3년은 해야 뭐가 나오는구나 싶기도 하다.

개인적으로도, 회사 차원에서도 일련의 출장을 통해 많은 성장과 회고를 할 수 있었다. 우리도 스스로 실리콘밸리를 지향점에 두고 있기는 했지만, 막상 현실은 한국에 있기에 그 감을 못 느끼고 있었는데 사실은 나쁘지 않게, 괜찮게 하고 있었다는 느낌이 왔다. 이제 이를 잘 동력삼아 다음 단계로 나아갈 때가 된 것 같다. 한국에서는 소프트웨어 분야 기준 아직 밑바닥부터 뭔가 만들어서 잘 되어본 경험이 별로 축적되어 있지 않은 것 같은데, 그러한 관점에서 하나의 좋은 선례가 되고 싶다는 개인적인 소망이 있다. 앞으로 잘 해봐야지.