윌 폴콘 — Lightning을 ML의 애플로 만들기



에피소드 소개

Lightning AI와 연결하기

웹사이트
트위터
링크드인
채용

듣기

타임스탬프

YouTube에서 시청하기

전체 대본

인트로

사용자는 늘 점진적인 이야기를 할 거예요. 항상 이걸 좀 더 낫게 만들어 달라고 하죠. “아이폰 같은 걸 원해요”라고는 절대 말하지 않아요. 대신 “블랙베리 키보드가 옆으로 밀려 나오게 해줄 수 있나요?” 같은 요청을 하겠죠. 그런 입력은 보통 제품을 개선하는 데는 도움이 되지만, 도약적인 제품을 만드는 데는 도움이 되지 않잖아요?

현실 세계의 머신러닝을 다루는 프로그램, Gradient Dissent를 듣고 계십니다. 진행은 루카스 비왈트입니다.

윌리엄 팔콘은 경력을 해군 네이비 실 훈련생으로 시작해 iOS 개발자를 거쳐, 현재는 PyTorch Lightning이라는 매우 성공적인 ML 프레임워크를 만들고, 스스로를 머신러닝을 위한 OS라고 부르는 멋진 웹사이트 Lightning AI를 운영하는 Lightning.AI의 CEO가 되었습니다. 오늘 이 주제에 대해 자세히 이야기해 볼 거예요. 정말 재미있는 대화였고, 여러분도 즐기시길 바랍니다.

당신의 배경 이야기로 시작하면 재미있을 것 같아요. 이 팟캐스트에 Navy SEAL 훈련을 거친 분들은 많지 않거든요. Lightning을 창업하게 된 과정을 포함해, 당신의 이야기를 조금 들려주시겠어요?

SEAL 훈련에서 FAIR까지

네, 좋아요. 저는 원래 베네수엘라 출신이에요. 많은 분들이 아실지 모르겠지만, 거기서 태어나고 자랐습니다. 그래서 영어는 제 두 번째 언어라 오늘 몇 군데에서 실수하는 모습을 보실 수도 있어요. 하지만 코드에는 당신이 어떤 언어를 쓰는지는 중요하지 않죠. 그게 참 좋은 점입니다.

10대 때 이곳으로 이주했고, 결국 미군에 들어가 BUD/S로 알려진 SEAL 훈련을 받았습니다. 몇 년 동안 그곳에 있었어요. BUD/S를 아시는 분이라면, 제가 272기와 277기에 있었다는 걸 아실 텐데, 꽤 의미 있는 경험이었습니다. 다만 부상을 당해 나오게 되었고, 정보 업무를 많이 수행하는 SEAL 팀 중 한 곳에 배치되어 근무하게 됐습니다. 아주 흥미로운 팀이었어요. 개인적으로 아랍어도 취미 삼아 배우다 보니 할 줄 알았고, 그곳에서 멋진 일들을 많이 했습니다.

그리고 제가 다시 훈련으로 복귀해야 할 때가 왔을 무렵—아마 2012년이나 2013년에 이라크에서 철수하던 때였죠—해군에서 제게 전역하거나, 조종사가 되거나 하는 선택지를 줬고, 저는 전역을 선택했습니다. 아마 그때 탑건을 봤다면 조종사로 남았을지도 모르겠지만요. 어쨌든 정말 좋은 시간이었고, 그곳에서 의미 있는 일을 많이 했습니다. 그 시간을 매우 뜻깊게 생각해요. 그 경험이 이후에 제가 하는 모든 일에서 성공할 수 있는 기반을 만들어줬다고 생각합니다. 군대를 떠나기 전까지는 학교에는 별로 관심이 없었다는 것도 그때 깨달았죠.

그다음에는 어떻게 머신러닝을 시작하게 되었나요?

콜롬비아에서 학부 과정을 하고 있었어요. 아마 2013년쯤이었을 거예요. 그때 사람들한테서 ‘머신러닝’이라는 걸 처음 들었습니다. 당시엔 수학이나 이런 분야에 별로 관심이 없었죠.

처음에는 전공을 컴퓨터 과학으로 시작했어요. 이유는 잘 모르겠지만, CS 수업들은 재미있었지만 가장 흥미롭지는 않았습니다. 어느 순간부터 수학에 더 끌리더라고요. 그리고 2013년에 통계나 수학을 하면서 코드를 만지고 있었다면, SVM이나 랜덤 포레스트 같은 것들을 안 마주치는 게 거의 불가능했죠.

첫 번째 신경망 수업을 들었던 게 기억나요. 그때 수업에서 “이미지가 이렇게 있으면요”라고 하면서, 예전에 얀 [LeCun]이 회전목마 음악과 함께 만든 그 EMNIST 데모를 다들 봤을 거라고 했죠. 그런데 저는 당시엔 이게 왜 유용한지 모르겠더라고요. 여기서 어떤 가치를 봐야 하는지도 잘 안 보였고요. 그러고 정말 오랜 시간이 지나서, 결국 제 박사 과정 지도교수 중 한 분으로 얀과 함께 일하게 됐습니다.

학부 시절 어느 순간에는 흥미가 생겨서 금융 쪽으로 갔어요. 트레이딩 플로어에서 딥러닝을 써 보려고 했죠. 요즘은 금융 분야가 딥러닝에 그리 알레르기 반응을 보이지 않는 편이지만, 그때는 관측 가능성 문제들 때문에 정말 꺼려했거든요. 그래서 그 환경이 마음에 들지 않아 다시 학교로 돌아갔고, 계산신경과학을 시작했습니다. 거기서 딥러닝을 제대로 배우게 되었고, 그때부터 머신러닝에 깊이 빠져들었어요.

그러니까 과학의 본질은 신경 활동을 해독하고 뇌가 어떻게 작동하는지 이해하려는 시도예요. 저는 여전히 그 문제에 매우 큰 관심이 있습니다. 제 동기 대부분도 사실 과학을 추구하는 데서 나오죠. 그런데 과학이 앞으로 나아가고 해야 할 일을 하게 만들 도구들이 너무 제한적이라는 점을 자주 느낍니다.

라이트닝 스트레스 테스트

그렇다면 라이트닝을 시작할 때는 무엇을 보셨던 건가요? 가장 초기에 어떤 문제를 해결하려고 했던 건지 궁금합니다.

라이트닝을 시작했을 때 저는 아직 학부생이었어요. 2015년쯤이었죠. 연구를 하고 있었고, 라이트닝 그 자체를 만들겠다고 시작한 건 아니었어요. 그냥 제가 내부적으로 쓰던 연구용 코드였죠. 제가 최적화하려고 했던 건, 제약 없이 유연함을 유지하면서도 같은 코드를 계속 다시 쓰지 않고 가능한 한 빨리 아이디어를 실험할 수 있는 방법이었어요.

연구자로서 최악의 상황은 어떤 걸 도입해 놓고 6개월 동안 연구를 진행하다가, 막판 몇 달에 갑자기 막혀서 ‘망했다, 전부 갈아엎어야 하네’ 하고, 그 과정에서 그동안의 결과까지 신뢰를 잃게 되는 거예요. 그래서 제게 가장 중요한 건 유연성이었습니다. 제가 해결하려고 했던 것의 대부분이 바로 그 부분이었죠. 그리고 세월이 지나면서… 저는 2019년까지 오픈 소스로만 했고, 거기까지 가는 데 대략 4~5년이 걸렸습니다.

그 기간 동안 제가 했던 일은 정말 다양한 아이디어를 시도해 보는 것이었어요. 제 첫 연구 분야는 신경과학이었고, 그때는 주로 GAN과 VAE를 많이 활용했습니다. 그다음 박사 과정을 시작하면서 NLP로 넘어갔죠. [경휴] 조는 seq2seq와 어텐션 논문의 주요 저자 중 한 명입니다.

그래서 제가 처음으로 했던 일은 어텐션을 처음부터 직접 구현하고, seq2seq 네트워크 같은 것들을 만들어 보면서 배우는 것이었어요. 이런 걸 해 보신 분들은 알겠지만 정말 거칩니다. 절대 쉬운 일이 아니죠. 루카스도 이걸 여러 번 구현해 본 걸로 알고 있어요.

저도 한 번 해 보려고 했는데, 말씀하신 대로 절대 만만치 않더군요. 처음에는 겁먹을ほど까지는 아닐지도 모르겠어요. 잘은 모르겠지만요. 아마 당신이 했을 때는 지금보다 참고할 자료가 더 적었겠죠.

맞아요. 그때는 전부 직접 만들어야 했죠. 요즘은 어텐션 헤드 같은 걸 그냥 꽂아 쓰면 되지만, 그때는 전부 직접 계산해야 했어요. 게다가 PyTorch가 어떤 기능은 지원하지도 않아서 막히기 일쑤였고, 정말 혼란스러웠죠. 그래서 많이 거칠고 힘들었습니다.

그다음 그걸 바탕으로 복소수에 대해 작업을 시작했어요. 조가 GRU 유닛도 소개했기 때문에, 우리는 복소수 GRU에 대해 연구를 시작했죠. 그 핵심 아이디어는 그래디언트가 폭주하거나 0으로 사라지는 문제를 줄이는 데 도움이 되도록 하는 것이었어요. 특히 오디오에서는 정규화 기법 등을 함께 쓰면 복소수가 그런 데 유용하거든요. 다만 PyTorch가 복소수를 제대로 지원하기 시작한 건 불과 1년 전쯤부터였어요.

그래서 아직 풋풋한 박사 과정생이던 제가 거기 앉아서, “좋아, 이 복소수 라이브러리를 전부 내가 구현해야겠네”라고 생각했죠. 실제로 그렇게 해서 오픈 소스로 공개했어요. 엄청 느리니 쓰지 마세요. 지금은 PyTorch 걸 쓰는 게 훨씬 낫습니다. 결국, 일을 끝내기 위해서라면 필요한 건 뭐든 하겠다는 태도였던 거죠.

그 모든 배움을 거치면서 결국 컴퓨터 비전과 자기지도 학습 연구로 오게 됐어요. 얀과 함께 일하면 언젠가는 자기지도 학습을 안 할 수가 없다고 생각해요. 그래서 저도 자연스럽게 빠져들었죠. 아마 2019년쯤이었을 거예요. 붐이 일기 전이죠. 정확히는 세상이 알기 전—사실 사람들은 그 전부터 여러 해 동안 이걸 해 오고 있었거든요.

그 모든 과정이 Lightning을 철저히 스트레스 테스트했죠. 그래서 오픈 소스로 공개될 즈음에는 꽤 유연해졌습니다. 이걸로 많은 일을 할 수 있다는 걸 알고 있었어요. FAIR에 합류했을 때는 “이거에도 쓸 수 있나요? 저거에도 되나요?” 같은 질문이 정말 많았고, 저는 “물론이죠. 방법을 보여드릴게요”라고 했습니다. 다만 활용할 수 있는 경우의 수가 너무 많다 보니, 그걸 다 설명하는 데 시간이 끝없이 걸렸습니다.

지금은 웬만한 어떤 것에도 통할 수 있다는 게 분명해졌지만, 그때는 그렇지 않았어요. 그리고 우리는 여전히 해 나가면서 배웁니다. 가끔 어떤 분이 특정 용도에는 유연하지 않다고 발견하면, 그걸 고치고 계속 나아가죠. 다만 과정이 길어요. 여기까지 오는 데 정말 많은 시간이 걸렸습니다.

TensorFlow와 다른 프레임워크 대신 PyTorch를 선택한 이유

그렇다면 2015년으로 돌아가 보면, 그때 PyTorch가 실제로 쓰이고 있었나요? 그땐 그냥 Torch였죠, 맞죠? 이런 것들이 어떤 해에 나왔는지 기억을 더듬고 있어요. 설령 가능했다 해도, 2015년에 PyTorch 위에 무언가를 만든다는 건 꽤 이례적인 선택이었을 텐데요. 그게 어떻게 가능했나요?

음, 제 초기 버전은 PyTorch 위에서 만든 게 아니었어요. 처음에는 Theano로 시작했습니다. 당시엔 주로 Theano와 sklearn을 썼죠. 아마 다들 하는 것처럼, 모델에 .fit을 붙여서 쓰기 시작했고, 거기서부터 점점 확장해 나갔습니다. 그게 제 최초 버전이었고, Theano 기반이었어요. Theano 다뤄본 적 있나요? 루카스, 언제 시작하셨는지 모르겠네요.

Theano를 조금 만져본 것 같긴 한데, 아주 조금이요. 아마 Theano 위에 Keras를 얹어서 썼던 것 같아요. 그걸로 제 시절이 드러나겠네요.

맞아요. 정말 짜증이 났었죠. 개념 증명용으로는 훌륭했어요, 분명히요. 그래서 바로 Keras를 쓰기 시작했고, 그 덕분에 막혀 있던 것들을 많이 풀 수 있었던 것 같아요. 그런데 어느 순간 한계에 부딪히게 되죠. 지금은 달라졌을지 모르지만, 그때는 그랬어요. 그래서 그런 일이 있었고, 그때 제가 “좋아, 결국 TensorFlow로 가야겠네”라고 생각했죠. 사실 피하고 싶었거든요.

제 첫 버전은 사실 TensorFlow 위에서 만들었습니다. 그런데 몇 년 뒤에 PyTorch가 나오자마자 전부 PyTorch로 다시 썼어요. 주된 이유는 PyTorch가 더 수학적으로 느껴졌기 때문이에요. 수학이 눈에 보였고, 더 쉬웠죠. 반면 TensorFlow에서는 그 위에 또 하나의 중첩된 층, 일종의 메타언어가 있었거든요. 물론 지금은 많이 달라졌지만, 당시엔 우리가 그런 환경에서 일했죠.

그래서 그때는 정말 실험적이었죠. 당시 Torch는 다루기가 아주 어려웠어요. 아, 미안해요. 쓰는 건 쉬웠는데, 설치 같은 게 정말 힘들었습니다.

정말 흥미롭네요. Keras의 방식에서 영감을 받은 부분이 있었나요? 아니면 Lightning이 Keras의 일부와는 대조적인 방향이었다고 보시나요? 그때 그걸 어떻게 생각하셨는지 궁금합니다. 제 느낌엔 Lightning이 PyTorch에서 하는 역할이, Keras가 TensorFlow에서 하는 역할과 비슷하다고 보이거든요. 그렇게 보는 건 지나치게 단순화했거나 틀린 걸까요?

맞아요. 그러니까, 제가 처음 Lightning을 내고 Torch 쪽에 올렸을 때, 겉보기에는 비슷해 보여서 “PyTorch를 위한 Keras”라고 부르긴 했어요. 하지만 실제로는 그렇지 않았죠. 그래서 이런 혼란의 원인이 제가 됐을 수도 있겠네요, 아쉽지만요. 방금도 말했듯이 저는 Theano도 쓰고, Keras도 쓰고, TensorFlow도 쓰고, scikit-learn도 썼어요. 그래서 제 영감의 상당 부분이 분명히 이런 것들에서 온 건 사실입니다.

제가 머신러닝에 들어가기 전에는 아이폰 개발자였어요. 오랫동안 iOS에서 일했습니다. 그래서 사람들이 콜백 같은 걸로 들여오는 많은 아이디어들은 사실 70~80년대부터 Objective‑C에서 도입된 개념들이에요. 모바일이나 웹에서 일해봤다면 이런 아이디어들을 이미 접해 보셨을 겁니다.

제 영감의 많은 부분은 사실 API의 단순함—예를 들어 .fit 같은 것—에서 왔고, 그건 대부분 sklearn의 영향을 받은 것 같아요. 그리고 콜백 같은 것들에 대해서는… 사실 저는 콜백에 꽤 반대했었습니다. 알고 보니 훅 이름들—그리고 제가 이름을 붙인 방식을 보면—그 상당수가 Objective‑C와 그 아주 긴 이름들에서 영감을 받았어요. 당신이 Objective‑C로 시작했다고 했으니 무슨 말인지 잘 아실 거예요. 정말 문법 자체가 굉장히 길잖아요.

Objective‑C를 좋아하신다니 조금 놀랍네요. 대부분의 사람들은 그걸 싫어하는 것 같거든요. 사람들이 Objective‑C를 싫어하는 이유 중 하나가 장황함이라고들 하는데, 말씀을 들어보니 그 안에 나름의 합리성이 있다고 보시는 것 같아요.

맞아요. 그러니까, 문법이 장황하면 오히려 고민할 게 없어서 좋더라고요. 이름이 너무 짧으면 “이게 무슨 뜻이지?” 하게 되는 게 싫어요. Objective‑C는 “이것도 로드했고, 저것도 로드했고, 또 저것도 로드했다” 같은 식이잖아요. 그러면 “아, 이해돼. 다 읽어보니까 납득되네” 하게 되죠.

모두에게서 영감을 받았다고 생각해요. Keras에서 정말 마음에 들었던 건 제공되는 피드백이었죠. 요약 테이블 같은 것도 그렇고—그런 부분은 Keras에서 영감을 받았습니다. 그러니까 여러 가지가 결합된 결과라고 할 수 있지만, 제가 깊이 고민해 온 대부분의 것들은 근본적으로 Objective‑C와 iOS 세계관에서 비롯됐다고 말하고 싶어요. 실제로 지금의 Lightning 앱—우리가 Lightning에 도입한 새로운 추상화들—을 보면 그와 비슷한 점이 많습니다. 그런 요소들을 훨씬 더 많이 담고 있거든요.

시간이 지나면서 많은 것이 변했다고 생각해요. 하지만 이제는 Lightning이 고유한 정체성을 갖고 독자적인 방향으로 성장했다고 봅니다. 업계 표준이 되기를 바라는 하나의 톤과 패러다임으로 자리 잡기 시작했죠. 특히 API와 작성 방식에서 많은 분들에게 영감을 줬으면 합니다. 규모가 커져도 잘 작동한다고 믿거든요. 그래서 사람들이 우리의 API를 가져다가 무엇인가를 해도 전혀 불쾌하지 않습니다. 최소한 우리가 ML을 표준화한다는 뜻이니까요. 그건 모두에게 이익이니까요.

Lightning 플랫폼의 구성 요소

Lightning API에서 처음 만들 당시 주변에 있던 것들과 비교해 확실히 달랐고, 특히 자랑스럽게 생각하는 부분은 무엇인가요?

Lightning에서 핵심은 두 가지라고 생각해요. 바로 LightningModule과 Trainer입니다. 모두가 사용하는 두 요소이고, 함께 쓰면 대부분의 보일러플레이트를 깔끔하게 추상화할 수 있죠. 그게 제가 가장 자랑스럽게 생각하는 부분이에요. 특히 Trainer는 정말 많은 변화가 있었고, 좋은 API이기 때문에 Lightning 바깥의 여러 분야에서도 표준처럼 자리 잡기 시작했다고 봅니다. 결국 핵심은 단순함이에요. 지금 무슨 일이 벌어지는지 투명하게 보고, 바꿔볼 수 있고, 그러면 정말 마법처럼 일이 돌아가는 그 경험 말이죠.

솔직히 말하면, 최근에 우리가 Lightning 작업으로 공개한 새로운 것들—Lightning Flow와 Lightning 앱—이 특히 자랑스럽습니다. 이걸 제대로 고민하고 방향을 잡는 데 몇 년이 걸렸어요. 모델을 만드는 과정에서 얻은 아이디어를 어떻게 확장해서 엔드 투 엔드 ML 워크플로, 연구 워크플로, 프로덕션 파이프라인까지—그 모든 것—로 일반화할 수 있을까? 그건 결코 쉬운 일이 아닙니다.

우리는 Lightning 다운 방식으로 만들고 싶었어요. Lightning의 정신과 DNA를 담아, 사용하는 순간 ‘아, 이건 Lightning이구나’ 하고 느낄 수 있게요. 그 점이 정말 자랑스럽습니다. 그리고 그것은 팀의 공동 노력으로 이뤄낸 결과입니다.

이 모든 것은 말하자면 전적으로 팀의 공동 노력입니다. 제가 몇 가지 아이디어의 씨앗을 뿌리긴 했지만, 커뮤니티와 특히 Lightning 팀이 없었다면 우리는 여기까지 올 수 없었을 겁니다.

맞아요. 방금 출시한 Lightning 런치에 대해 꼭 이야기해 보고 싶어요. 정말 인상 깊었거든요. 그런데 그 얘기로 들어가기 전에 하나 궁금한 게 있어요. 예전에 PyTorch에 Ignite라고, 제 기억으로는 Lightning과 꽤 비슷한 무언가가 있었던 순간이 있었어요. 아니면 최소한 PyTorch 팀은 Lightning과 비슷하다고 생각했던 것 같고요. 궁금한 건—그때 당신이 실제로 Facebook에서 일하고 있었던 걸로 아는데… Facebook에서 일하던 시기에, Facebook이 당신 것이랑 다소 경쟁적인 소프트웨어를 동시에 만들고 있던 건가요? 그거 좀 어색하지 않았나요? 그 당시엔 경쟁처럼 느껴졌나요?

자, 두 가지가 있어요. 첫째, Ignite는 PyTorch가 만든 것도 아니고 Facebook 제품도 아닙니다. 서드파티 제품이고, 그들이 하는 일은 문서를 호스팅하는 것뿐이에요. 실제로 Facebook이나 PyTorch가 만든 게 아닙니다. 문서가 구성된 방식 때문에 그렇게 보일 뿐이죠. 이게 첫 번째입니다.

두 번째로, 그때 저는 연구자이자 학생이었고 말 그대로 논문을 쓰는 데 집중하고 있었지, 머신러닝용 소프트웨어를 만들고 있지 않았습니다. 도구를 이것저것 써 보면서 둘러보고 있던 게 아니라서, 무엇이 나와 있는지 전혀 몰랐어요. 주변에 뭐가 있는지도 몰랐습니다. 제가 사용했던 것들이 제가 실제로 알고 있던 전부였죠.

연구를 해 오셨으니까, 분명 이런 생각을 한 적이 많을 거예요. “와, 저건 멋진데 난 내 연구에만 집중하니까 쓸 일은 없겠네.”

완전히요.

연구자들이 시야를 좁게 가져가는 건 꽤 흔한 일이라고 생각해요. 그리고 실제로 출시되고 나서야 알프레도 칸지아니 같은 분들이랑 다른 사람들이 “와, 이거 약간 이런 거네” 하고 반응했죠. 그러자 저도 “오, 흥미롭네. 그게 뭐지?” 하고 살펴봤고, 보니까 “아, 대략 이런 느낌이긴 한데, 자기만의 DNA가 있네”라고 생각했어요.

그래도 놀랄 일은 아니죠. 연구에서는 흔히 있는 일입니다. 어떤 계기로 막혔던 문제가 풀리면 여러 사람이 각자 병렬로 비슷한 주제를 파기 시작하고, 그러면 비슷한 아이디어가 여기저기서 떠오르게 됩니다. 하지만 막상 결과물이 나와 보면, 최종적으로는 아주 다른 것들이 됩니다.

저는 늘 이렇게 비유해요. 당신이랑 제가 “자, 사람 얼굴을 한번 그려 보자”고 하고, 제가 그 얼굴을 묘사만 해 준다고 해도, 분명 우리는 같은 걸 하려 해도 서로 다르게 그리게 될 거예요.

페이스북에서 시작한 라이트닝 출시

라이트닝을 중심으로 실제로 회사를 창업하게 된 계기는 무엇이었나요? 그 여정은 어땠는지 궁금합니다.

정말 흥미로운 게, 라이트닝의 첫 번째 도입자가 페이스북이었고, 그 덕분에 기업용 기능들을 아주 빠르게 갖추게 되었죠. 사실 저는 상당히 짜증이 났어요. 그때는 말 그대로 박사 과정을 하려고 하고 있었거든요.

회사 내부에는 사람들이 서로 메시지를 주고받는 Workplace라는 도구가 있는데, 페이스북 팀에서 계속 알림을 보냈어요. FAIR가 아니라 실제로 재밌는 것들을 만드는 팀이요. 그런데 저는 그걸 확인하지 않았죠. 이메일로 연락을 주고받으려고도 했는데, 제가 이메일을 잘 챙기는 편이 아니라 그걸 무려 4개월 동안 정말로 안 봤던 거예요.

그러다 제 매니저가 와서는 “야, 너 Workplace 꼭 확인해봐”라고 하더라고요. 제가 “왜요?”라고 했죠. 그랬더니 페이스북 팀들이 “안녕하세요, 당신 걸 써보고 싶어요”라고 한 거예요. 그래서 제가 “이거 박사과정 프로젝트예요. 왜 그걸 쓰려고 하세요?”라고 했죠. 그랬더니 “괜찮아요. 더 좋게 만드는 걸 도와줄게요”라고 해서, 제가 “알겠어요” 했습니다.

그래서 그들이 가져가서 작업을 시작했고, 그때부터 그 팀과 정말 긴밀하게 지내고 있어요. 그런데 진짜 놀라웠던 건, 대기업들이 바로 쓰기 시작했다는 거예요. 누가 PR을 올리면 “이거 고쳐줄 수 있어요?”라고 하는데, 저는 “아니요, 전 안 해요. 당신들이 하는 FFT 연구인지 뭔지 모르겠고, 그거 고치고 싶지 않아요”라고 했죠. 그랬더니 “하지만 저는 블룸버그에 있어요”라고 하길래, “그거 멋지네요. 알겠어요. 도와드려야겠네요” 했습니다.

개발자로서는 그게 가장 짜릿하죠. “좋아. 내가 만든 게 진짜로 쓰이고 있어. 대박이네.” 이런 느낌이니까요. 그래서 그런 사례가 수백 개 쌓였을 때 생각했어요. “알겠어. 사람들은 지금 우리가 방금 출시한 것처럼 더 큰 문제에서 진짜 고생하고 있구나. 그렇다면 이걸 제대로, 의미 있게 해결하자.” 그런데 막상 해보니 혼자서는 할 수 없고, 엄청난 자금과 사람, 기타 자원이 필요하더라고요. 그렇게 해서 우리가 여기까지 오게 된 겁니다.

그게 몇 년이었죠? 2019년인가요?

네, 2019년 여름이었어요. 그리고 2019년 12월에 페이스북을 떠났고요. 그래서 2020년 1월에 회사를 시작했어요. COVID 두 달 전이었죠. 루카스, 당신은 몇몇 회사를 세워 성공을 거두셨고, COVID 시기에 회사를 만드는 게 얼마나 어려운지 잘 아실 거예요.

리더십과 연구의 공통점

음, 그러니까 지금이 2022년 여름이잖아요. 회사 규모가 얼마나 되나요?

지금은 전 세계에 약 60명 정도이고, 주로 뉴욕, 샌프란시스코, 런던에 모여 있지만 다른 곳에도 사람들이 있어요. 회사에서 제가 정말 자랑스럽게 생각하는 게 하나 있어요. 저는 미국 출신도, 실리콘밸리 출신도 아니에요. 그래서 그런 정체성이 회사의 DNA가 된 것 같아요. 20개국에서 온 사람들이 정말 많고, 모두가 여러 언어를 할 수 있어서 놀라워요. 꽤 멋져요. 정말 국제적인 분위기가 느껴지거든요. 뉴욕의 스타트업으로서는 아주 좋아요. 바로 그런 용광로 같은 환경이 우리가 원하는 거니까요.

정말 대단하네요. 연구자, 영업, 개발자에서 갑자기 규모가 꽤 큰 회사를 이끄는 자리로 오게 된 경험은 어땠나요? 지금도 스스로 생각할 시간이나 직접 코드를 작성할 시간은 있으신가요?

좋은 질문이네요. 이렇게 되묻고 싶어요. 회사를 만드는 일이 일종의 연구 같다고 느끼지 않나요? 비슷한 점이 정말 많지 않나요?

비슷한 점이 있긴 하다고 생각해요. 그런데 먼저 말씀해 보세요. 어떤 점이 비슷하다고 보시나요?

그러면 연구에서는 무엇을 하나요? 가설을 세우고, 대부분의 경우 그 가설이 틀렸다는 걸 확인하게 됩니다. 빠르게 시도해 보고, 다음 것으로 넘어가면서 아이디어를 계속 시험해 보다 보면 잘 작동하는 것을 찾게 되고, 그러면 그걸 깊이 파고들죠. 그건 회사를 운영하는 것과 다르지 않습니다.

차이점은 사람을 통해서 해야 한다는 거예요. 그게 정말 어렵습니다. 혼자서 만드는 일이 아니죠. 이걸 자꾸 잊습니다. 의미 있는 무언가를 만들고 싶다면 팀이 있어야 하고, 혼자서는 할 수 없습니다. 여기서 말씀드리고 싶은 게 있는데, 방금 라이트닝이 출시되기까지 5년 정도 걸렸다고 했잖아요. 만약 그때 지금의 팀과 함께했다면 아마 1년 만에도 가능했을 겁니다. 뛰어난 사람들과 함께 빨리 맞춰 일하면 훨씬 빨라지거든요. 저는 혼자서 “뭐든 다 해낸”다는 식의 개념을 좋아하지 않습니다. 그런 건 통하지 않아요. 저도 그렇게 하지 않습니다.

정말 놀라운 여정이었어요. 회사를 만드는 일은 사람을 통해 이뤄져야 하고, 그게 정말 어렵습니다. 사람을 관리하고, 비전을 제시해 모두가 같은 비전을 향해 나아가게 하는 일—심지어 최종 결과가 어떻게 나올지 아무도 모르는 상황에서요. 이건 정말 어렵습니다. 왜냐하면 60명에게 의심을 내려놓고 “알겠어요, 해봅시다. 거기에 도달하면 그때 무엇인지 확인하죠.”라고 말해 달라고 요청하는 일이니까요.

리더로서 그런 균형을 자주 고민해야 합니다. 솔직히 말해 군에서 보낸 첫 6년은, 비록 모두가 하는 SEAL 전체 훈련을 마치지도 않았고 정식 SEAL이 되지도 않았지만, 제가 겪었던 일들—특히 소규모 팀을 이끌고 훈련하고 SEAL 팀에서 활동했던 경험—이 실제로 큰 도움이 됐다고 생각해요. 정보도 없고 자원도 제한된 상황에서, 어떻게 공격적인 성향의 사람들을 아주 빠르게 하나의 목표로 향하게 만들 것인가? 딱 그거죠.

군대에서 얻은 교훈

정말 흥미롭네요. 그 부분을 좀 더 들려주세요. 정말 궁금합니다. 군대에서 리더십에 대해 배운 것 중에 회사 운영에 적용한 것은 무엇인가요?

맞아요. 그러니까, 초급 장교로 BUD/S에 가면… 저는 SEAL 훈련을 시작할 때 스무 살이었어요. 300명 규모의 기수를 맡게 됐죠. 말도 안 되잖아요. 모든 것에 책임을 져야 합니다 — 그들의 장비, 그들의 위치 — 그리고 모두가 18, 19살이에요. 다들 시내에 나가 말썽을 부리고, 정말 어리석은 짓들을 하죠. 사람 문제를 산더미처럼 감당해야 합니다. 그리고 당신은 스무 살에, 현장에서 일을 배우는 중인 거예요.

그리고 첫 번째 SEAL 팀에 배치되면 팀을 맡게 되는데, 그곳 사람들은 30년, 40년을 버틴 베테랑들이죠. 모든 면에서 당신보다 훨씬 뛰어납니다. 그런 상황에서 가르치려 드는 태도로, “내가 왔다. 큰소리치는 상사다. 내 방식대로 하겠다”라는 식으로 나서면 끝입니다. 그렇게는 절대 돌아가지 않아요.

군 전체를 대신해 말할 수는 없지만, SEAL 팀과 특수작전에서는 항상 앞에서 이끄는 법을 배웁니다. 장교라면 가장 빨리 달리거나, 가장 잘 수영하는 사람이어야 하죠. 늘 선두에서 이끌기 때문입니다. 그건 지금도 제가 지키는 원칙입니다.

그래서 지금은 늘 코딩만 하고 있지는 않은 거예요. 하지만 팀이 특정 수준에 도달하길 원하고, 제가 밀어붙이면 그 수준에 충분히 도달할 수 있습니다. 문이 있으면 제가 먼저 들어가고, 항상 가장 먼저 거기에 도착하겠다는 마음가짐 같은 것도 큰 부분을 차지한다고 생각해요. 그런 교훈들이 많은 부분에서 이어집니다.

민간에서는 이걸 뭐라고 부르든 — 리더십이든 뭐든 — 저는 스무 살 때부터 그게 몸에 밴 셈입니다.

정말 흥미롭네요. 전 세계에 분산된 고도로 기술적인 인재들로 이루어진 회사를 경영하는 것과, 18~19살로 이루어진 팀을 이끄는 것 사이에, 당신이 뜻밖이라고 느낀 두드러진 차이가 있나요?

네, 맞아요. 군대에서는 굉장히 독단적입니다. 결정을 내리면 그걸로 끝이에요. 이의 제기도, 질문도 없습니다. 물론 사람들의 의견을 듣고, 모두가 의견을 낼 수는 있죠. 하지만 결국 내가 한마디 하면 그대로 실행됩니다. 되돌아보는 일도 없어요. 민간 세계에서는, 세상에, 질문이 엄청나고 이런저런 얘기가 끝없이 나옵니다. 그래서 그 세계에서 어떻게 살아가는지를 정말 배워야 해요. 흥미롭죠. 제가 몇 년간 금융권에서 보낸 시간이 양쪽을 잇는 가장 좋은 중간 지대였다고 생각합니다.

실제로 많은 베테랑들이 아마 이런 이유로 민간 사회에 적응하기 어려워한다고 생각해요. 군대에서 일을 처리하는 방식이 너무 다르니까요. 그래서 사람들에게 그 방식으로 대할 수는 없고, 결국 정서 지능을 배워야 합니다.

금융은 일종의 하이브리드한 초공격적인 환경이지만, 그래도 사람들과 어떻게 소통해야 하는지는 배워야 합니다. 이걸 보고 있는 베테랑들이 있다면, 먼저 금융권에 가서 부드럽게 연착륙하는 법을 배우고 그다음에 테크로 가라고 권하고 싶어요. 테크 업계에서는 디자이너와 크리에이티브 등 아주 다른 사람들과 일하게 되거든요.

정말 멋지네요. 이건 완전 곁다리 질문이지만, 그냥 궁금해서 여쭤볼게요. 실리콘밸리에서는 군과 테크가 협력할 때 종종 마찰이 많다고 느낄 때가 있거든요. 그런 점에 대해 생각해 보신 적 있나요? Lightning의 군사용 활용을 기대하시나요? 그리고 그 사이에서 일종의 ‘번역자’ 역할을 하실 수 있다고 보시나요? 이 문제를 어떻게 바라보고 계신지 궁금합니다.

맞아요. 제 생각에 군대에서의 AI 얘기만 나오면 다들 “자율 무기! 어쩌고!”로 바로 가는 것 같아요. 물론 그건 아주 극단적인 활용이고, 저는 그런 용도를 지지하고 싶지 않습니다. 우리 누구도 그걸 원하지 않죠. 특히 제가 직접 겪어 본 몇몇 상황을 떠올리면, 그런 걸 더 가능하게 만드는 건 절대 바람직하지 않다는 게 분명하니까요.

하지만 사람들이 잘 모르는 점은, 이런 도구들 중 일부는 긍정적인 방식으로도 활용될 수 있다는 거예요. 예를 들어—글쎄요, 각 요소마다 판단이 갈릴 테니 깊게 들어가고 싶지는 않지만—여전히 좋은 방향으로 사용할 수 있는 방법들이 있습니다.

번역이요, 그렇죠? 현장에 나가서 새로운 마을에서 누군가를 만나는데 서로 말이 통하지 않을 때, 어떻게 하시겠어요? 전쟁 동안 군이 아프가니스탄과 이라크에서 해온 일의 상당 부분은 현지 주민들의 마음을 얻는 데 초점이 맞춰져 있었습니다. 마을 사람들과 연결을 만들고, 무슨 일이 벌어지는지 이해하려고 노력하고, 나라를 재건하려는 시도들이었죠. 저는 이런 일들의 상당 부분을 실제로 AI가 촉진할 수 있다고 생각해요, 그렇지 않나요?

부상자요. 부상자가 발생하면 무언가를 요청해야 합니다. 당사자가 말을 못 할 수도 있으니 통역이 필요할 때도 있고요. 그렇게 유용한 활용 사례가 많지만, 결국 다른 것들과 마찬가지죠.

그러니까, 인터넷을 이용해 오랫동안 소식 끊긴 가족을 찾을 수 있냐고요? 물론이죠. 하지만 사람을 불법적으로 거래하는 데 쓰일 수도 있냐고요? 네, 그럴 수도 있습니다. 그럼 어떻게 할 건가요, 그냥 인터넷을 없애버릴 건가요? 알다시피 이건 어렵습니다. 간단한 답은 없어요.

PyTorch Lightning에서 Lightning AI로의 확장

좋아요. 새로 나온 Lightning 웹사이트에 대해 이야기해 주세요. 이걸 어떻게 이야기하는 게 가장 좋을까요? 운영 체제로서의 Lightning 말이죠. 이걸 어떻게 구상했고, 어떻게 만들었는지 궁금합니다. 정말 인상적인 데모와 함께 아주 훌륭한 론칭이었어요. 여기서의 과정과 비전에 대해 듣고 싶습니다.

네, 맞아요. 오늘 Lightning.ai에 들어가 보면 Lightning 커뮤니티를 위한 새 홈페이지를 보실 수 있어요. 먼저 짚고 넘어가야 할 점은 PyTorch Lightning이 성장했다는 겁니다.

이제 이 프로젝트의 이름은 PyTorch Lightning이 아니라 Lightning입니다. 예전에는 PyTorch Lightning일 때 모델을 만드는 한 가지 일만 할 수 있었죠. 그건 멋지지만, 모델을 만들고 나면 그 주변에 해야 할 일이 정말 많습니다. 데이터를 정리해야 하고, 피처 스토어도 필요합니다. 실험을 관리해야 하고, 여러분이 하고 있는 것처럼 결과를 분석하고 무슨 일이 일어나고 있는지 이해하는 작업도 많이 해야 합니다.

우리가 지금 프레임워크에서 가능하게 한 것—이제 프레임워크는 Lightning입니다—은 모델을 구축할 수 있게 해주는 것입니다. 그건 여전히 할 수 있습니다. 하지만 이제 연구 워크플로나 프로덕션 파이프라인을 만들고 싶을 때도, 프레임워크 안에서 Lightning 방식으로 그 작업을 할 수 있습니다.

그리고 우리가 진짜로 하고 싶은 일은 사람들이 최고 수준의 도구들을 서로 엮어 쓸 수 있게 해주는 것입니다. 그래서 우리는 이것을 머신러닝을 위한 접착제라고 생각하고 있어요. 예를 들어 내가 Weights & Biases의 “기능 X”를 다른 것과 함께 쓰고 싶다면, 당연히 그렇게 할 수 있어야 하잖아요?

그래서 저는 우리를 애플처럼 생각해 주셨으면 합니다. 우리가 사실상 아이폰에 해당하는 것을 내놓고 있어서, 사람들이 그 위에 앱을 만들 수 있게 하려는 거죠 — 각자 앱을 만들어 배포할 수 있도록요. 다만 이 앱들은 단순한 데모가 아니라 매우 복잡한 워크플로입니다. 실제로는 분산 클라우드 환경에서 실행되는 엔드투엔드 프로덕션 워크플로나 연구 워크플로이고, 최고 수준의 도구들을 서로 엮어 구성합니다. 그래서 오늘날 Lightning AI는 이러한 앱들이 게시되는 허브 역할을 합니다. 새로운 머신러닝 프로젝트를 시작하려 한다면, 거기에 가서 본인이 하고 있는 것과 유사한 것을 찾고, 몇 분 안에 자신의 인프라에서 빠르게 실행한 다음, 코드를 바꿔 바로 진행할 수 있습니다.

제가 정말 기대하는 부분이 몇 가지 있어요 — 그리고 이건 우리 둘이 계속 이야기해 온 주제이기도 하죠 — 파트너들과 어떤 통합을 해볼 수 있을까 하는 겁니다. 예를 들어 Weights & Biases의 훌륭한 도구들을 어떻게 활성화해서, 사람들이 지금은 아마 불가능한 방식으로 자신의 앱에 정말 멋지게 임베드할 수 있게 할까, 이런 거죠. 결국 핵심은 그 지점에 있습니다.

모든 프레임워크와 모든 도구와 파트너십을 맺어, 그들이 최고의 역량을 발휘하도록 돕고 커뮤니티에 가진 강점을 최선의 형태로 제공하게 하고 싶습니다. 그래서 우리가 목표로 하는 바가 바로 그거라고 생각합니다.

이건 얼마나 오래 준비해 온 건가요? 제가 이해하기로는 PyTorch Lightning 때와는 꽤 다른 비전처럼 보이는데요. 처음 공개했을 때, 어떻게 그 방향에 이르게 되었나요? 그리고 회사를 시작했을 때부터 줄곧 이런 구상을 하고 있었던 건가요?

네, 맞아요. 처음부터 그게 분명한 비전이었습니다. 초기에 구축하는 건 정말 어렵죠. 그걸 위해 발로 뛰어야 하고요. 하지만 PyTorch Lightning이 이미 그 많은 부분을 시작해 놓았어요. 우리가 그 초기 파트너들 중 가장 먼저 참여한 편이었거든요. 그러니까, PyTorch Lightning이 처음 출시되던 때로 돌아가 보면, 아마 2019년—5월이었는지 6월이었는지—그때는 이미 여러 프레임워크가 돌아가고 있었죠.

그리고 실험을 모니터링하려고 해도 정말 어려웠죠. 무언가를 꼭 연동해야 했거든요. 그래서 TensorBoard가 있었���, 아마 그때쯤이면 여러분도 이미 서비스를 시작��고 있었던 것 같아요. 그런데 이런 도구들이 존재하긴 해도 사람들이 잘 몰랐어요. 설치되어 있지도 않았고, 쓰기도 쉽지 않았으니까요. 그래서 우리가 처음 했던 일 중 하나가… 저 개인적으로 TensorBoard를 썼어요. 그때도 쓰면서 이렇게 생각했죠. “알죠? 이걸 내가 직접 띄우고 싶진 않아요. 그냥 이 도구가 알아서 해주면 좋겠어요.”

우리는 그걸 거기에 통합하기 시작했고, 곧바로 당신들 사용자들이 와서 “저기, Weights & Biases도 추가할 수 있나요?” 같은 요청을 하기 시작했죠. 그래서 우리는 그런 추상화를 고안했고, 그랬더니 사람들이 암묵적으로 그 기능을 쓸 수 있게 됐습니다. 도구들이 서로 연결되기 시작했기 때문에 정말 놀라웠어요.

그래서 그 비전은 그때 이미 시작됐어요. 그리고 가속기 쪽을 보면… 우리가 Accelerate라는 API를 만들었는데, 다양한 하드웨어에서 학습할 수 있게 해주는 도구입니다. 2020년 여름에 만든 거고, Lightning 전반을 구동하지만, 본질은 그거예요. CPU, GPU, TPU 사이를 자유롭게 오갈 수 있도록 해줍니다. 우리가 그걸 끊김 없이 할 수 있게 한 첫 번째 프레임워크였다고 생각해요.

PyTorch는 TPU를 위한 XLA와 GPU를 지원했지만, 코드를 계속해서 다시 써야 했습니다. 그래서 우리는 처음으로 GPU와 TPU를 이렇게 간단히 오갈 수 있는 기능을 도입했어요. 그건 정말 판도를 바꿨습니다. 그렇게 통합이 이뤄졌기 때문에 정말 대단한 변화였죠.

그때부터 플랫폼으로 변모하기 시작했죠. 그래서 저는 “좋아, 이런 걸 더 많이 하려면 어떻게 해야 하지?”라고 생각했습니다. 다만 모델 안에서만 움직이면 할 수 있는 일이 제한적이에요. 반면에 피처 스토어, 배포 같은 것들을 이야기하기 시작하면, 그보다 한 단계 더 높은 수준의 무언가가 필요합니다.

또 저는 게으르고 새로운 걸 배우는 걸 싫어해서, 이렇게 생각했죠. “좋아, PyTorch Lightning을 쓰지 않더라도 이미 프로덕션 시스템을 만들 줄 알 만큼, Lightning만큼 쉽게 만들려면 어떻게 해야 하지?” 그래서 그런 방향으로 제품을 내놨습니다. 어려웠던 부분은 Lightning과 똑같은 느낌을 구현하는 일이었어요. 그 DNA가 뭘까? 사용자 경험이 어떻게 느껴져야 할까?

제품 개발과 고객 피드백을 어떻게 바라보시는지 궁금합니다. 개인적인 비전에서 출발해 많은 것을 만들어 오신 느낌이었거든요. 지금 하시는 일에서 직관이 차지하는 비중은 얼마나 되고, 반대로 “X, Y, Z 같은 걸 해주는 기능을 만들어줄 수 있나요?”처럼 사용자 요청에서 비롯되는 부분은 얼마나 되나요? 제품 개발 프로세스는 어떻게 진행되나요?

맞아요. 아마 이 질문을 하기엔 제가 최악의 사람일 겁니다. 남들이 뭘 하는지는 전혀 신경 쓰지 않거든요. 정말로요. 다른 사람들이 뭘 하는지 보지도 않고, 관심도 없습니다. 우리는 우리가 하려는 일을 할 거고, 제가 흥미롭다고 생각하는 것들을 해 나갈 겁니다.

우리는 기본적으로 우리가 하고자 하는 일에 대한 가설을 세울 겁니다. 그리고 물론 사용자와 그들의 행동을 지켜볼 거예요. 하지만 사용자에게만 의존하면… 참고로 우리는 사용자와 늘 대화합니다. 그걸 안 하겠다는 얘기는 아니에요. 피드백도 적극적으로 반영합니다. 다만 사용자는 늘 점진적인 것만 말해줍니다. “여길 더 좋게 해달라”는 요구를 하죠. “아이폰을 원한다”고 말해주지는 않아요. 대신 “블랙베리 키보드를 옆으로 밀어서 나오게 해줄 수 있나요?” 같은 요구를 하게 마련이죠.

그래서 그럴 땐 마인드셋을 달리해야 합니다. 말을 곧이곧대로 믿지 말고 걸러서 들어야 하죠. 사용자 의견은 받아들이되, 솔직히 말해 그 피드백은 보통 제품을 개선하는 데는 도움이 되지만, 도약적인 제품을 만들게 해주지는 않습니다.

그래서 다시 말하지만, 남들이 뭘 하고 있는지는 정말로 신경 쓰지 않습니다. 저는 머신러닝을 위해 해야 한다고 믿는 일을 할 것이고, 그게 우리가 다음에 만들 것들입니다. 그리고 가끔은 틀리고, 가끔은 맞습니다.

적합한 인재 채용

당신이 하는 유형의 일을 위해서는 머신러닝 배경을 가진 사람을 채용하는 것이 중요하다고 보나요? 아니면 운영, 엔지니어링, 데이터베이스 같은 배경을 가진 사람들을 더 찾나요?

무엇보다도 저는 사람들이 창의적이고 추진력이 있으며 어떤 방식으로든 흥미로운지 여부를 가장 중요하게 봅니다. 그러니까, 각자 뚜렷한 관심을 가지고 있고 똑같이 찍어낸 듯한 사람은 아닌지요. 그게 첫 번째 기준입니다.

그다음에는, 맞아요, 여러분이 각자 잘하는 분야에서 잘하기를 바랍니다. 그게 무엇이든요. 특히 머신러닝의 경우에는, 있으면 정말 좋고, 제발 뭐든 확실히 알고 다루길 바랍니다. Lightning 팀에 있다면 1000% 알아야 합니다. 그리고 Lightning 팀의 모든 구성원은 박사 학위자이거나 박사 과정 출신이라서, 모두 이 분야의 전문가들입니다.

하지만 그 주변의 다른 모두에게는, 각자 잘하는 일에서 정말 뛰어나기만 하면 됩니다. 그 지식을 어떻게 얻었는지는 신경 쓰지 않아요. 정말로 상관없습니다. 기억하세요, 저는… 음, 결국엔 좋은 학교에 가긴 했지만, 제 인생의 대부분 동안은 그렇지 않았거든요. 그래서 그런 건 별로 중요하게 생각하지 않았습니다. 그러니 머신러닝이 반드시 결정적인 조건은 아니라고 봐요. 맡는 역할에 따라 달라질 뿐이죠. 물론, 제가 틀렸을 수도 있습니다…

Lightning 팀은 더 큰 회사 조직에서 어떤 역할을 하나요? 두 팀의 차이는 무엇인가요?

그러니까 Lightning 팀은 오픈 소스 전반을 담당합니다. 그리고 클로즈드 소스를 맡는 팀도 따로 있죠. 여러분이 Lightning 앱을 로컬에서 돌리면 전부 무료 기능을 쓰는 겁니다. 클라우드에서 실행할 때는 일부 사유 기술을 사용하게 되고요. Lightning 앱은 포크하거나 클론해서, 모델까지 포함해 전부 로컬에서 실행할 수 있습니다. 하지만 클라우드에서 돌리고 싶다면 “클라우드에서 실행”을 선택하면 됩니다.

그리고 그 일들은 이제 Lightning 팀이 아닌 다른 사람들이 만들고 있습니다. 이들은 인프라 엔지니어이기도 하고 데이터베이스 전문가이기도 하며, 정말 다양한 배경을 가진 사람들이죠. 세상에는 미지의 요소가 아주 많기 때문에, 그런 다양성이 언제나 더 낫다고 생각합니다.

그리고 우리 둘 다 알고 있듯이 ML은 계속 진화하고 있고, 다음에 무엇을 만들어야 할지 아무도 확신할 수 없습니다. 그래서 어느 정��는 연구자의 관점을 유지해야 합니다.

Lightning의 미래

당장 Lightning 플랫폼 위에서 만들어지길 바라는 대표적인 애플리케이션이 있나요? 앞으로 무엇에 가장 기대하고 계신가요?

지금 가장 먼저 떠오르는 건 오랫동안 함께해 온 핵심 파트너들—여러분 같은 팀—과의 협업을 통해 우리가 만든 도구들의 보급을 더 널리 확대하고, 가시성을 높이며, 사람들이 자유롭게 조합해 쓸 수 있게 하는 일입니다. 당장은 이런 직계 파트너들에 집중하고 있어요. 여기에는 일부 클라우드 제공업체도 있고, 일부 하드웨어 제조사도 있으며, 그 밖의 파트너들도 포함됩니다. 오랜 시간 아주 좋은 관계를 유지해 온 분들이죠. 그래서 우선은 그분들의 도구가 가장 먼저 잘 작동하도록 지원하는 데 초점을 맞추고 있습니다.

기능 측면에서는, 예를 들어 추론을 정말 좋은 방식으로 수행할 수 있게 하는 데 집중하고 싶습니다. 그래서 SageMaker 팀 같은 클라우드 제공업체들과 협력하고 있습니다. 그리고 데이터로 무언가를 하려는 분들을 위해서는 Snowflake나 Databricks 같은 업체들과도 협력해 이런 기능을 가능하게 하고 싶습니다. 또, 요즘 새롭게 시도되는 라벨링 관련 작업들도 있습니다.

그래서 여러분이 그 분야에서 뭘 하고 계신지는 모르지만, 어떤 영역이든 기꺼이 협력하고 싶습니다. 제가 보기에 지금은 모델 개발과 바로 맞닿아 있는 일들이 중요합니다. 더 할 수 있는 일은 많지만, 우선은 이 부분에 집중하고자 합니다.

PyTorch가 아닌 프레임워크들과도 협업할 계획이 있나요? scikit 통합이나 XGBoost 같은 것들은 좋아하시나요? 그런 것들도 범위에 포함되나요?

네, 맞아요. 정말 놀라워요. 사람들이 Lightning을 별의별 용도로 다 쓰는데, 실제로 sklearn을 Lightning에서 돌린 경우도 있더라고요. 어떻게 한 건지 저도 모르겠어요.

정말 멋지네요.

저는 “이걸 어떻게 하고 있는 거죠?”라고 했어요.

하지만 솔직히 말하면, 저는 모든 프레임워크를 다 통합하고 싶어요. 전반적으로는 PyTorch를 좋게 보고 있지만, TensorFlow, JAX, Keras 같은 것들에 반대하는 건 전혀 아니에요. 그쪽과의 어떤 파트너십이든 환영이고, 해당 도구들이 잘 작동하도록 지원하는 일에도 물론 기꺼이 함께할 겁니다.

다시 말해, 우리는 예전과 비교해 정말 많이 발전해서 이제는 “이제 훨씬 더 많은 것을 지원할 수 있게 되었고” — 예전에는 사실상 대역폭 문제였죠 — “이제 더 많이 지원할 수 있으니 그렇게 하겠다”라고 말하는 지점에 와 있습니다. 그리고 그 파트너들도 환영받는다고 확실히 하고 싶어요. 그래서 네, 우리는 어떤 프레임워크와도 기쁘게 협업합니다.

그냥 궁금해서요. 왜 장기적으로 PyTorch를 더 선호하시나요?

이런 프레임워크들은 기능적으로 상당히 수렴해 온 것 같아요. 저는 최근에 TensorFlow를 다시 써보진 않았는데, 아마 많이 달라졌겠죠. 저희는 이미 PyTorch에서 많은 작업을 해왔기 때문에, 그 사용자 경험을 계속 개선해 나가는 데 더 기대를 걸고 있어요.

구글이 다른 쪽과도 파트너십을 원한다면, 저희도 기꺼이 함께할 겁니다. 다만 모든 것을 잘할 수는 없다고 생각하고, 그래서 기업으로서 집중하는 것이 중요하다고 봅니다. 특히 PyTorch와 관련해서는, 지금은 연구는 물론 프로덕션에서도 사실상 표준이 되었다고 생각해요. 그리고 그 팀이 지금도 경계를 계속 넓혀 가는 데 매우 훌륭한 성과를 내고 있다고 굳게 믿습니다.

그래서 에너지, 팀이 사안을 바라보는 방식—프로덕션 워크로드와 추론을 다루는 접근 방식까지—이 정말 독특하고 다르다고 생각해요. 저는 그런 독특하고 색다른 생각을 좋아하는 편이라 자연스럽게 그쪽에 끌립니다.

회사를 키우고 팀을 확장하면서 제가 겪는 어려움 중 하나가… 서로 관점과 비전이 조금씩 다른, 아주 창의적이고 똑똑한 사람들을 많이 채용하게 되다 보니, 방향을 맞추고 일관성을 유지하는 일이 항상 굉장히 큰 일처럼 느껴진다는 점이에요. 인원이 60명까지 늘어나는 과정에서 그런 문제가 있었다면, 그걸 어떻게 풀어오셨는지 궁금합니다.

그렇죠. 모두의 의견을 최대한 반영하는 게 중요하지만, 동시에 분명한 관점을 가져야 해요. 그게 차이를 만듭니다. 각자 하고 싶은 말만 하고 결국 각자 원하는 대로 해버리면, 결국은 응집력이 없는 결과가 나오거든요. 그래서 어느 정도는 미운 사람이 되더라도 “좋아, 이해해. 하지만 우리는 이 방향으로 갈 거야. 그냥 그렇게 하는 거야.”라고 말해야 할 때가 있어요. 그런 식의 작은 결정들이 수없이 쌓여서 방향이 정해집니다.

저만 그런 게 아니라, 팀원들에게도 분명한 관점을 가지라고 독려합니다. 그건 Lightning에서 우리가 갖고 있는 철학과 같아요. “좋아. 상속을 쓰는 방식이 마음에 안 들어? 괜찮아. 그럼 다른 걸 쓰면 돼. 우리는 이렇게 만들어야 한다고 생각하고, 그걸로 충분해.”

자기지도학습에서 알고리즘 복잡도 줄이기

마무리는 항상 두 가지 질문으로 하는데, 오늘도 꼭 그 두 가지를 여쭤보고 싶어요. 먼저 마지막에서 두 번째 질문입니다. 시간이 조금 더 있다면, 혹은 머신러닝 연구 전반에서 다른 주제를 다룰 여유가 생긴다면, 어떤 일을 해보고 싶으신가요?

지금 다시 연구만 한다면, 아마 자기지도학습 방향을 계속 이어 갔을 거라고 확신해요. 그 분야의 연구는 지금도 꾸준히 따라보고 있습니다.

이와 관련해 1년 전에 논문을 냈고, 오늘은 그 내용을 이야기해 보겠습니다. 자기지도학습에서 최근에 밀어붙여진 많은 진전들—즉, 여러 발전들—이 꼭 방법론 자체, 예를 들어 음성 샘플을 이렇게 저렇게 쓰는 식의 기법 차이에 의해 주도된 것은 아니라고 봅니다. 실제로는 변환(transform)들이 그 진전을 이끌고 있다고 생각합니다.

그래서 예전에 우리가 발표한 논문—제가 계속 이어서 하고 싶다고 답했던 그 주제인데요—에서 보여준 바는, 요란한 요령 하나 없이도 평범한 VAE만으로 SimCLR에 거의 근접한 성능을 낼 수 있다는 것이었습니다. 실제로 우리는 ELBO 손실의 항 하나를 제거하기도 했어요. 그게 가능했던 이유는 SimCLR에서 쓰는 변환들을 가져와 그대로 활용했기 때문입니다. 다만 우리는 부정 샘플을 생성하는 방식을 변환으로 처리했고, 그다음 원본을 복원하는 식으로 접근했습니다.

그게 실제로 아주 좋은 학습 신호를 만들어냈어요. 그리고 그 실험이 제게, 또 우리 그룹에도 보여준 건, 화려한 부정 샘플링 알고리즘이나 정보이론 같은 걸 끌어다 붙여서 뭔가 그럴듯하게 만드는 게 핵심이 아니라는 점이었죠. 제 생각에 우리는 그런 요소들의 대부분을 변환(transform)에 집어넣고 있고, 실제로는 그 변환들이 성능을 떠받치고 있는 겁니다. 이건 데이터 사이언티스트들이 오래전부터 말해 온 것과도 일치하죠. 결국 관건은 데이터예요. 정말로 데이터가 전부입니다.

결국 우리가 가진 지식을, 특히 이미지에 대해서는, 전부 변환에 쏟아붓게 된 셈이더군요. 그 점은 조금 아쉽지만, 최소한 저는 그 방향을 계속 탐구할 것 같습니다. 어떻게 하면 이런 알고리즘들의 복잡성을 줄일 수 있을까 하는 주제요. 별의별 꼼수는 원치 않습니다. 기묘한 러닝 레이트 스케줄러 같은 것도 다 빼고 싶어요. 왜 동작하는지 분명히 이해하고, 무엇 때문에 그런 동작을 하는지 정확히 짚어낼 수 있는, 아주 단순한 VAE 손실 같은 기본적인 방식이면 좋겠습니다.

그리고 제 생각에는 자기지도학습이 길을 잃었습니다. 요즘 논문들 대부분이 “이걸 하는 완전 새로운 기법!”이라고 하지만, 막상 보면 “아, 이 작은 항 하나 바꿨네” 수준이거든요. 그러면 “제발 좀…” 하는 말이 절로 나옵니다.

파편화된 ML 생태계

흥미롭네요. 마지막 질문입니다. 페이스북이나 Bloomberg 같은 기업, 혹은 그 밖의 조직들이 실제 문제에 머신러닝을 적용해 프로덕션에 배포해 제대로 동작하게 만들려고 할 때, 그러니까 “이 아이디어를 머신러닝으로 해보자”에서 출발해 실제 배포·운영까지 가는 과정에서, 2022년 여름 현재 가장 큰 병목은 어디에 있다고 보시나요?

기대와 현실 밈 있잖아요. 우리가 늘 보는 게 딱 그거라고 생각해요.

응. 왜 그런데?

제가 보기에는 그냥 미지수인 경우가 정말 많아요. 그러니까, 워낙 새롭다 보니 프로덕션 시스템에서 스트레스 테스트를 해 보면 뭔가가 깨지고, “아, 내 챗봇이 인종차별적이네” 같은 일이 벌어지죠. 그러면 “그래, 그동안 아무도 챗봇을 실제로 써 본 적이 없었잖아” 하고요. 당연히 그런 교훈을 얻게 되는 거죠.

그래서 우리가 새롭게 알아가는 미지수가 정말 많습니다. 하지만 요즘은 도구가 폭발적으로 늘어난 반면, 그 도구들을 함께 어떻게 써야 하는지에 대한 표준이 없다는 점이 크게 작용한다고 봐요. 저는 그게 오늘날 우리를 발목 잡는 가장 큰 이유 중 하나라고 생각합니다.

그 문제를 해결할 방법은 여러 가지가 있다고 생각해요. 방금 우리가 소개한 것들로 분명히 그 문제에 도전하고 있다고 봅니다. 그래서 솔직히 그게 큰 부분을 차지한다고 생각해요. 다만 그건 어디까지나 일부일 뿐이라고 봅니다.

또 다른 문제는 이런 파편화라고 생각해요. 모두가 이걸로 시작해서 저걸로 넘기고, 또 그다음으로 넘기고, 그러다 ONNX를 쓰고, 거기에 또 이것저것을 붙이라고 하죠. 그런데 표준만 있고 모두가 함께 맞춰서 일하면, 실제로 훨씬 잘할 수 있습니다.

솔직히 말해, ML 분야에는 건전하지 못하고 이상한 경쟁 구도가 있다고 생각해요. 여러분, 이건 거대한 시장입니다. 이걸 위해 돈을 지불할 사람들이 정말 많아요. 하나의 도구냐 다른 도구냐의 문제가 아니라, 모두가 여러 도구를 함께 쓰고 있습니다. 이런 불건강한 경쟁이 사실 많은 문제를 야기하고 있어요. 커뮤니티가 더 협력하고, 프레임워크 간, 오픈 소스 프로젝트 간, 그리고 여러분 같은 도구와의 소통과 협업이 더 나아진다면, 훨씬 쉬워질 겁니다. 서로 대화가 이루어지면, 페이스북의 어떤 엔지니어가 “아, 저 사람들이 이것만 해 줬다면 훨씬 쉬웠을 텐데” 하면서 여섯 달을 허비할 필요가 없겠죠.

아웃트로

좋네요. 함께 일할 방법을 찾아볼 수 있으면 좋겠습니다.

그 한 사람만 떠올리세요. 그 사람만 생각하세요. “내가 당신의 커리어를 되찾아 드릴게요. 걱정하지 마세요. 그게 목표예요.”

알겠어요. 이 방송을 듣고 계시다면, 저희가 응원하고 있습니다. 꼭 잘 되게 해 드릴게요. 좋아요. 고마워요, 윌. 정말 즐거웠습니다. 좋은 대화였어요.

네. 초대해 주셔서 감사합니다. 정말 즐거웠어요. 그리고, 여러분이 하고 계신 모든 일의 큰 팬입니다. ML 커뮤니티를 위해 해 오신 모든 일에도 감사드립니다.

멋져요, 저도요.