Jeremy Howard — fast.ai의 탄생과 왜 Python이 ML의 미래가 아닌가

다음 플랫폼에서 듣기

게스트 소개

Jeremy와 연결하기

쇼 노트

다룬 주제

참고 링크

대화록

지금 여러분은 Gradient Dissent를 듣고 있습니다. 이 프로그램은 실제 세계에서 머신러닝 모델을 제대로 작동하게 만드는 방법을 배우는 쇼입니다. 진행자는 저, 루카스 비왈드입니다. 제러미 하워드는 Fast.ai 코스를 만들었는데, 아마 머신러닝을 배우는 데 가장 인기 있는 코스 중 하나일 겁니다. 종류도 정말 많죠. 그는 또한 Fast.ai와 PyTorch로 코딩하는 사람들을 위한 딥러닝이라는 책의 저자이기도 한데, 그 과정에서 많은 사람들이 독립적으로 딥러닝을 작성할 때 사용하는 Fast.ai 라이브러리를 만들었습니다. 그 이전에는 딥러닝을 헬스케어 애플리케이션에 적용하는 흥미로운 스타트업인 엔리틱의 CEO이자 공동 창업자였습니다. 그보다 더 전에는 가장 이른 시기의 흥미로운 머신러닝 기업 중 하나인 캐글의 대표를 맡았습니다. 오늘 그와 이야기하게 되어 정말 기대됩니다. 제러미, 만나서 반갑습니다. 질문을 준비하면서 문득, 매번 당신과 이야기할 때마다 제가 평소에는 떠올리지 못할, 기억에 남는 보석 같은 얘기들이 있었다는 걸 깨달았어요. 예를 들어 예전에 중국어를 어떻게 배웠는지 들려준 적도 있었고, 또 한 번은 아주 구체적인 아버지의 육아 조언을 해줬는데, 그게 정말 큰 도움이 됐습니다.

좋네요. 아버지의 육아 조언 중에 뭐가 효과가 있었나요?

음, 당신이 해준 말이 기저귀를 갈 때 드라이기를 사용하면 정말 답답한 경험을 정말 즐거운 경험으로 바꿀 수 있다는 거였어요. 정말 좋은 조언이죠. 어떻게 그런 생각을 하게 됐는지 모르겠어요. 아마 짐작은 가지만, 그게…

네, 네, 그 훅 소리를 좋아하고 따뜻함을 좋아하는 거 알아요. 저는 아버지 관련된 것들에 꽂혀 있거든요. 그래서 그런 얘기라면 언제든 기쁘게 할 수 있어요. 이 팟캐스트가 바로 그런 이야기죠.

그 얘기부터 해도 될까요? 이제 제 딸이 여덟 달이 되었거든요. 아이를 위해 해줄 만한 조언이 있을까요?

세상에! 여덟 달이라니. 어떤 종류의 학습이든 마찬가지예요. 핵심은 꾸준함이죠. 그래서 클레어에게 우리가 가장 잘한 건, 정말 일관성을 철저히 지킨 거라고 생각해요. 지금은 참 사랑스러운 아이가 되었는데, 그 이유가 우리가 약속을 아주 엄격하게 지켰기 때문이에요. 이를테면 “Y를 하지 않으면 X는 못 가져”라고 말했으면, Y를 하지 않았을 때는 절대로 X를 주지 않았죠. “스쿠터를 타고 길 아래까지 내려가고 싶으면, 돌아올 때는 네가 직접 들고 올라와야 해.” 이런 식으로요. 일관성을 지키지 않으면 문제가 된다는 훌륭한 책을 읽었는데, 그게 도박과 같아진다고 하더군요. 가끔은 원하는 걸 얻게 되니 계속 시도하게 된다는 거죠. 그래서 제 1순위 조언은 일관성입니다. 머신러닝을 가르칠 때도 똑같아요. 우리는 늘 학생들에게 끈기가 가장 중요하다고 말합니다. 포기하지 말고, 매일 하라고요.

질문하는 취지에서 말씀드리자면, 정말 궁금한 게 있어요. 당신은 놀라운 프레임워크와 교육 프로그램을 만들어냈고, 제 생각에 아마 가장 인기 있고 많은 사랑을 받는 프레임워크일 거예요. 그걸 하게 된 영감이 무엇이었는지, 그리고 Fast.ai의 커리큘럼과 머신러닝 프레임워크인 Fast.ai를 만들어가는 여정이 어땠는지부터 이야기해 주실 수 있을까요?

그래서 그건 아내 레이철과 제가 함께 시작한 일이었어요. 레이철은 수학 박사이고, 매우 기술적인 배경을 갖춘 초기 데이터 사이언티스트이자 엔지니어로 우버에서도 일했죠. 저는 그렇지 않아요. 철학 학부를 간신히 마쳤고 기술적 배경은 없습니다. 그런데 서로 다른 출발점에서 같은 좌절을 겪었어요. 2012년의 신경망은 엄청나게 중요했고 분명 세상을 바꿀 텐데, 접근성이 너무 낮았다는 거죠. 그래서 밋업에 가서 어떻게 해야 하는지 알아보려고 했어요. 기본 아이디어는 알고 있었고, 20년 전에 신경망을 코딩해 본 적도 있었지만, 그걸 정말 잘 만들려면 어떻게 해야 하는지 몰랐습니다. 당시에는 GPU에서 돌릴 수 있는 오픈 소스 소프트웨어가 없었어요. 댄 세레센의 도구가 있긴 했지만 유료였고, 소스 코드도 없었죠. 그래서 생각했어요. 이건 우리가 바꿔야 한다고. 기술 도약의 역사라는 게 대체로 불평등을 키워왔거든요. 자원이 있는 사람들만 새 기술에 접근할 수 있고, 그게 사회적 혼란과 많은 불행으로 이어지니까요. 그래서 우리가 할 수 있는 걸 해 보자고 했습니다. 그럼 이걸 어떻게 고칠까? 기본적인 목표는, 지금도 그렇지만, 코드를 요구하지 않고도 딥러닝을 쓸 수 있게 하는 것이었어요. 세상의 대다수는 코딩을 못 하니까요. 그 목표에 가려면, 우선 지금 존재하는 게 무엇인지 확인하고, 우리가 할 수 있는 한 최대한 잘 사용하는 법을 배우고, 그 사용법을 사람들에게 가르치고, 그다음 더 좋게 만드는 겁니다. 더 좋게 만들려면 연구를 하고, 그걸 소프트웨어로 바꾸고, 그다음 강의 내용을 바꿔서 조금이라도 더 쉬운 버전을 가르치고, 그 과정을 몇 년간 반복하는 거죠. 우리는 지금도 그 과정을 계속하고 있습니다.

정말 흥미롭네요. 혹시 이런 걱정은 없으세요? 지금 가르치고 있는 내용이 결국은 스스로 구식이 되도록 만드는 일이라는 점이요. 더 높은 수준의 추상화를 만들고 계시니까요. 많은 사람들이 당신의 강의를 높이 평가하는 이유 중 하나가, 그 원리가 어떻게 동작하는지 아주 명확하고 깊이 있게 설명해 준다는 점이잖아요. 그런 설명이 결국에는 필요 없어질 거라고 보시나요? 아니면 그 부분을 어떻게 생각하고 계신가요?

네, 어느 정도는 그렇죠. 그러니까 새 책과 새 강의를 보시면, 1장은 정말 아주 기초적인 것들—머신러닝 알고리즘이란 무엇인지, 알고리즘을 “학습한다”는 게 무슨 뜻인지, 같은 문제를 풀 때 전통적인 프로그래밍과 머신러닝은 무엇이 다른지—로 시작합니다. 이런 기본 토대는 코드를 전혀 쓰지 않는 시점이 오더라도 항상 유용하다고 생각해요. 지금 당장도 PlatformAI 같은 코드 프리 도구를 쓰더라도, 알고리즘은 제공한 데이터에 기반해서만 학습할 수 있고, 아직 보지 못한 패턴으로 일반화하기는 대체로 어렵다는 기본은 이해해야 하거든요. 그런 것들이요. 그리고 우리는 지금까지 매년 새로운 강의 두 개, 파트 1과 파트 2를 매번 내왔어요. 왜냐하면 해마다 완전히 구식이 되거든요. 파트 1 시작할 때 학생들에게 늘 말합니다. “지금 배우는 디테일은 1~2년 후엔 아무 쓸모가 없을 거예요.” 피아노를 쓰다가 TensorFlow와 Keras를 쓰다가, 다시 PyTorch로 옮겨 가기도 했죠. 그래서 항상 말해요. “우리가 쓰는 소프트웨어에 너무 신경 쓰지 마세요. 이건 전부 금방 바뀌고, 자바스크립트 프레임워크보다도 빠르게 변해요. 중요한 건 개념입니다.” 그러면 새로운 라이브러리는 주말쯤 잡고 파면 다 익힐 수 있죠, 아마도요.

인간의 학습과 머신러닝, 두 가지 학습에 대해 아주 깊이 고민해 오신 것 같아요. 레이철과 당신은 예전에 가르친 경험이 있었나요, 아니면 fast.ai가 첫 번째 교수 경험이었나요?

음, 사실 이런 종류의 가르침을 꽤 많이 해 왔어요. 다만 아주 비공식적인 방식이었죠. 부분적으로는 저 자신이 기술 교육 배경이 없기 때문이기도 해요. 그래서 무슨 일이 벌어지는지 모르는 사람들의 처지를 공감하기가 쉬웠어요. 저도 잘 모르니까요. 25년 전쯤 경영 컨설팅을 할 때로 거슬러 올라가 보면, 저는 항상 전문 지식이나 인터뷰에 의존하는 접근법 대신 데이터 기반 접근법으로 문제를 풀었어요. 제게 전문 지식이 없었고, 너무 젊어서 아무도 저를 진지하게 보지 않으니 인터뷰도 제대로 할 수 없었거든요. 그래서 고객이나 프로젝트 매니저에게 “이 문제는 선형계획법, 다중 회귀, 데이터베이스 같은 걸로 이렇게 풀었습니다”라고 설명해야 했어요. 컨설팅을 몇 년 하다 보니, 어느새 제가 오늘날이라면 데이터 사이언스라고 부를 것들을 가르치는 사내 교육을 운영하게 되더라고요. 20여 년 전에는 그런 말을 쓰지 않았지만요. 기본적으로 고객을 가르쳤던 셈이죠. Kearney에서 IT 쪽에 있을 때는 회사 전체를 대상으로 한 과정을 운영했는데, 오늘날 말로 하면 데이터 사이언스 기초 과정이었어요. SQL 조금, 회귀 조금, 스프레드시트 조금, 몬테카를로 시뮬레이션 조금씩요. 그러니까, 말씀하시니 꽤 많이 했네요. 레이철도 물론 그렇고요. 레이철은 순수수학 쪽으로 듀크 대학교 등에서 대학원생 대상 강의를 하기도 했어요. 그러니 우리 둘 다 어느 정도 실전 경험이 있었고, 그 일에 꽤 열정적이었습니다. 또 가르치는 법에 관한 학술 문헌도 많이 공부했어요. 이상하게도 대부분의 교사는 그런 걸 잘 안 보거든요. 그건 좋은 점인 것 같아요.

당신의 강의나 수업 방식에서, 다른 사람들이 듣는 일반적인 수업과 비교해 특히 잘하고 있다고 느끼는 점이나, 스스로 특히 자랑스럽게 생각하는 고유한 강점이 있다고 느끼시나요?

음, 그러니까 완전히 독창적이라고 하진 않겠어요. 늘 훌륭한 일을 하는 사람들이 있으니까요. 다만 우리가 특히 두 가지로 눈에 띈다고 생각합니다. 하나는 코드 퍼스트, 다른 하나는 톱다운 접근입니다. 저는 늘 의식적으로, 제가 곧 청중이라는 전제에서 모든 걸 결정해요. 저는 수학을 잘하는 편이 아닙니다. 지금은 필요한 만큼은 하지만, 제 배경에 깊게 자리 잡은 게 아니고 자연스럽게 떠오르는 방식도 아니에요. 저에게 기술적인 것을 가장 잘 설명하는 방법은, 제가 직접 실행하고 디버그해 보고 중간 입력과 출력까지 들여다볼 수 있는 코드 예시입니다. 그래서 제 수업에서는 저 같은 사람을 대상으로 가르치기로 의식적으로 선택합니다. 대학원 수준의 기술 전공자 대부분은 저와 다르게 수학을 많이 해 왔지만, 이 주제에 관심 있는 사람들의 다수는 저와 비슷해요. 대학원 학위가 없고, 그런데도 기존의 교수 집단에서는 크게 대표되지 못한 사람들입니다. 왜냐하면 거의 모든 교사가 학계 사람이라, 그리스 문자나 적분 같은 걸 좋아하지 않는 사람에게 공감하기가 어렵거든요. 그래서 저는 항상 코드 예시를 보여 주며 설명합니다. 그리고 다른 하나는 톱다운이에요. 꼭 오랜 시간 기술 전공을 거쳐 교수까지 된 사람들의 다수는 아닐지라도, 대다수의 평범한 사람들은 문맥이 있을 때 훨씬 잘 배웁니다. 왜 이걸 배우는가? 실제 적용 사례가 무엇인가? 디테일하게 조립하는 법을 말하기 전, 이 접근의 장단점은 무엇인가? 이런 배경이요. 이건 정말 어렵지만, 우리는 매번 새로운 주제를 도입할 때 그게 다른 것을 설명하거나 증명하기 위해 꼭 필요하기 때문에 꺼내는 방식이 되도록 노력합니다. 이게 어려운 이유는, 제가 가르치는 건 전부 제가 너무 잘 아는 것들이라서, “여기서 시작해서 이것을 쌓고 또 이것을 쌓고… 자, 도달했죠”처럼 단계적으로 가르치기가 너무 쉽기 때문이에요. 그게 뭔가를 가르칠 때 자연스러운 방식이긴 하지만, 배우는 입장에서는 자연스러운 방식이 아닙니다. 톱다운으로 가르치는 일이 얼마나 어려운지 사람들은 잘 모르는 것 같지만, 정작 배우는 사람들은 그 방식을 정말 높이 평가하더라고요.

네, 확실히 많이들 좋아하더라고요. 한편으로는, 이 부분을 레이철에게 직접 물어보고 싶었는데요, 레이철도 당신과 같은 접근을 한다고 보시나요? 배경이 꽤 다르게 들려서요.

네, 배경은 다르지만, 접근 방식은 확실히 같습니다. 그건 서로 충분히 이야기를 나눴거든요. 예전에 그녀가 데이터 윤리 쪽에 더 집중하기 전까지는 함께 개발을 많이 했고, 지금도 종종 서로에게 “있잖아, 그거 좀 바텀업 같은데, 그렇지 않아?”라고 지적하곤 해요. 그러면 그녀가 “아, 정말 그렇네” 하고는 처음부터 다시 시작하죠. 그래서 우리 둘 다 그게 중요하다는 걸 알고, 그렇게 하려고 정말 열심히 노력하지만, 항상 성공하는 건 아니에요.

만드신 라이브러리에 대해서도 이야기해 주실 수 있을까요? 어떻게 시작하게 되었는지, 어떤 과정을 거쳐 만들어졌는지 궁금합니다. 또, 당신이 원하던 방식으로 변화를 이루려면 직접 라이브러리를 만드는 것이 꼭 필요했다고 보시나요?

음, 그게… 기억해 주세요, 이 작업의 목적은 ‘가르치는 것’이 아닙니다. 우리는 가르침이 전혀 없거나 최소화되길 원해요. 목표는 코드가 전혀 없고, 누구나 30분 안에 집어서 바로 시작할 수 있게 하는 겁니다. 그런데 결국 백사십 시간가량을 가르쳐야만 하는 상황이라면, 그건 실패예요. 그러니까 우리는 아직 실패하고 있는 거고, 그걸 고치려면 모든 것을 극적으로 더 쉽게 만들어 주는 소프트웨어를 만드는 수밖에 없습니다. 결국 소프트웨어가 우리의 진짜 목표예요. 하지만 거기까지 가려면, 먼저는 사람들이 이미 존재하는 것을 쓸 수 있게 가르치고, 왜 여전히 어려운지, 왜 여전히 너무 느린지, 왜 아직도 계산 자원이 너무 많이 드는지, 왜 여전히 데이터가 너무 많이 필요한지 같은 것들을 연구로 파악해야 합니다. 접근성을 제한하는 요소들을 하나하나 조금씩이라도 개선하려면 무엇이 필요한지, 그리고 그걸 소프트웨어에 어떻게 녹여 넣을 수 있을지를 찾아야 하죠. 네, 소프트웨어가 일종의 최종 산출물입니다. 여전히 순환 과정이긴 하지만, 언젠가는—바라건대—모두 소프트웨어 안에 담기게 될 거예요. 지금은 적어도 딥러닝 라이브러리에서 빠져 있던 핵심 요소 몇 가지를 이해했다고 느끼는 단계까지는 온 것 같습니다. 아직 ‘노코드’까지는 갈 길이 멀지만, 적어도 “기본적인 객체지향 설계가 거의 불가능한데, 그 이유가 텐서에 의미 기반 타입이 전혀 없기 때문이구나. 그럼 그걸 추가해 보면 어디까지 갈 수 있는지 보자” 같은 통찰은 얻었죠. 그런 식으로요. 우리는 정말 기초로 되돌아가려 했습니다.

다른 사례도 있었나요? 방금 건 좋았어요. 또 떠오르는 게 있나요?

맞아요. 그러니까, 디스패치가 핵심이라고 볼 수 있죠. Julia 스타일 디스패치가 Python에는 내장되어 있지 않아서, 타입 기반의 함수 디스패치를 우리가 어떻게든 해결해야 한다고 느꼈어요. 데이터 사이언스에서는 보유한 데이터의 종류에 따라 해야 할 일이 달라지니까요. 예를 들어 “회전”이라고 했을 때, 3D CT 스캔인지, 일반 이미지인지, 포인트 클라우드인지, 사람 포즈의 키포인트 집합인지에 따라 “회전”의 의미는 같지만 구현은 달라져야 합니다. 그래서 Julia에서 영감을 받은 타입 디스패치 시스템을 만들었어요. 또 하나는, 결국 전부 “타입”의 문제라는 걸 깨달았다는 점입니다. 의미 기반 타입을 도입하려면, 그 타입이 입출력 전 구간을 관통해야 해요. 이를테면 입력으로 이미지가 들어오면 Pillow 이미지 객체일 수 있고, 파이프라인을 거쳐 반대편에서는 이미지 텐서로 나와야 하죠. 모델로 들어가서는 모델이 이미지 텐서나 카테고리 타입 같은 걸 출력해야 하고, 그 결과가 다시 끝까지 전달되어 화면에 올바르게 표시될 수 있어야 합니다. 그래서 전체 변환 파이프라인이 가역적이어야 했고, 가역적이면서 합성 가능한 변환 시스템을 새로 구축해야 했어요. 이 모든 것들은 가능한 한 내부에서 감추려고 노력하지만, 이런 요소들이 없으면 우리가 궁극적으로 지향하는 노코드 목표는 불가능해집니다. 왜냐하면 사용자에게 “지금 나온 이 텐서는 연관된 카테고리들과 함께 세 개의 바운딩 박스를 표현한다” 같은 정보를 컴퓨터에 일일이 알려 주고, 그것을 어떻게 시각화할지도 설명해야 하니까요. 그래서 이런 기반 작업이 코딩을 쉽게 만드는 데도 필수이고, 앞으로 몇 년에 걸쳐 코드 자체의 필요를 없애는 데도 토대가 됩니다.

라이브러리 V2를 공개한 뒤에 있던 큰 목표는 무엇이었나요? 완전히 다시 쓰는 건 꽤 대담한 선택이었잖아요.

네, 저는 ‘세컨드 시스템’의 큰 팬이에요. 조엘 폴스키와는 정반대죠. 저는 리라이트를 사랑합니다. 제가 아서 휘트니는 아니지만, K와 KDB를 만든 아서 휘트니는 매 버전마다 전체를 처음부터 다시 쓰고, 그런 버전을 여러 번 내왔잖아요. 저는 그 접근을 정말 좋아해요. 이전 버전이 터무니없이 순진하고 빈약해 보일 만큼 많이 배우지 못했다면, 저는 앞으로 나아가고 있지 않은 거니까요. 그래서 매년 제 코드를 돌아보면 “아, 이건 훨씬 더 좋게 만들 수 있겠다”라고 느끼고, 그러면 아예 처음부터 다시 씁니다. 책에서도 똑같이 했어요. 모든 장을 두 번째로 전부 처음부터 다시 썼죠. 부분적으로는 그런 성향 때문이고, 또 한편으로는 제가 방금 말한 종류의 것들—무엇이 필요한지에 대한 견고한 이해—를 갖출 때까지 몇 년이 걸렸기 때문이기도 합니다. 그 이해의 상당 부분은 Swift와 LLVM의 창시자인 크리스 래트너와의 수많은 대화에서 왔어요. 함께 가르치면서, Swift로 fast.ai를 이식하는 얘기, Swift의 타입 시스템을 두고 나눈 대화가 정말 큰 도움이 됐죠. 그리고 Swift의 값 타입 시스템에 관해 아마 세계 최고 전문가인 알렉시스 갤러거와도 함께 일했고, 그는 Swift용 새로운 DataBlock API를 만드는 데 도움을 줬어요. 그 과정을 거치며 “이건 정말 오래가는 아이디어구나” 하는 확신을 얻었습니다. 사실 이건 DataBlock API라는 발상 자체로 거슬러 올라가요. fast.ai 버전 1 때부터 있던 생각인데, 기반을 치밀하게 다시 생각해 본 결과였죠. 가능한 모든 입출력 조합마다 전혀 다른 클래스, 다른 API, 다른 개념을 만드는 라이브러리를 만드는 대신, 입력이 될 수도 출력이 될 수도 있는 몇 가지 타입을 정하고, 필요한 실제 단계들을 정의하자는 겁니다. 예컨대 “입력 아이템을 어떻게 찾지?”, “출력 아이템을 어떻게 정하지?”, “검증 세트를 어떻게 분리하지?”, “레이블은 어떻게 얻지?” 같은 걸요. 다시 말해, 한 발 물러서서 “여기서 근본적으로 무슨 일이 벌어지고 있는가? 그걸 제대로 해보자”라고 접근한 결과였습니다. 그래서 fast.ai 2는 정말 처음으로 완전히 한 발 물러서서 시작했어요. 실비아와 제가 함께 작업했는데, 제가 실비아에게 “지금 우리가 만들 수 있는 최선의 수준이 될 때까지는 어떤 조각도 내보내지 않는다”라고 못을 박았죠. 실비아는 때때로 제가 좀 미쳤다고 생각했을 거예요. 예를 들어 Transforms API는 아마 스물일곱 번쯤 다시 썼을 겁니다. 하지만 저는 계속 “아직 부족해. 아직 충분히 좋지 않아”라고 느꼈고, 마침내 “좋아, 이제 진짜로 잘 됐다”라고 말할 수 있�� 때까지 밀어붙였어요.

그럼 가장 어려운 부분이 외부 API인가요? 그렇게 만드는 게 정말 까다로워 보이거든요. 그러니까, 이 API들을 충분히 명확하고 체계적으로 정리하는 일은 끝이 없을 것 같아요.

글쎄요, 저는 그것들을 외부 API라고 생각해 본 적이 없어요. 제게는 언제나 내부 API일 뿐입니다.

왜냐하면 더 큰 시스템을 만들고 싶기 때문이죠.

맞아요. 그렇다면 나머지 소프트웨어는 무엇으로 만들죠? 바로 그거예요. 그래서 우리는 아예 처음으로 거슬러 올라가 “도대체 소프트웨어를 어떻게 써야 하지?”라고 고민했어요. 저는 늘 문학적 프로그래밍이라는 아이디어의 열렬한 팬이었지만, 실제로 제대로 작동하게 해 주는 것을 찾지 못했거든요. 그리고 우리는 줄곧 Jupyter Notebook의 강력한 지지자였어요. 제가 사랑하는 Jupyter의 세계와, 문서화와 재현 가능한 방식으로 탐구하고 그 탐구와 설명을 코드에 통합해 가며 작성할 수 없는 IDE의 세계 사이에 간극이 있는 게 늘 아쉬웠습니다. 그래서 정말 처음으로 돌아가 “Jupyter Notebook을 사용해 문서와 코드, 테스트, 탐구를 하나의 통합 시스템으로 만들 방법이 있을까?”라고 물었죠. 그리고 답은 “있다”였어요. 결국 제가 지금 하는 방식이 100% 만족스럽지 않은 지점마다 “그걸 고칠 수 있을까? 더 좋게 만들 수 있을까?”라고 되묻게 되었죠. 그 부분에서 Python이 큰 도움이 됐어요. Python은 정말 해커블하잖아요. 메타 오브젝트 시스템에 들어가 Type Dispatch의 동작 방식을 바꾸고, 상속의 동작을 바꿀 수 있다는 사실 말이죠. 그래서 Type Dispatch 시스템에 자체 상속 구현을 내장하는 식의 일을 할 수 있어요. 그걸 할 수 있다는 게 정말 놀랍습니다.

와, 왜요?

Type Dispatch 시스템은 상속을 이해해야 해요. 예를 들어, 타입 A와 B에 대해 어떤 함수를 호출했을 때, 그 함수에 대해 A의 슈퍼클래스나 B의 더 상위 슈퍼클래스에 등록된 것이 있고, 또 약간 다른 조합으로 등록된 것이 있을 수 있잖아요. 그럴 때 어떤 것이 매칭되는지 어떻게 결정하느냐는 거죠. 처음 버전에서는 상속을 아예 무시했고, 타입이 정확히 일치하거나 타입 중 하나가 None일 때만 디스패치되도록 했어요. 그런데 나중에 상속 처리를 추가해서, 이제는 멀티플 디스패치와 상속이 잘 결합된, 아주 편리한 방식이 되었죠.

당신의 타입에서 상속이 어떻게 동작하는지 예시를 들어 줄 수 있나요? 무엇이 무엇으로부터 상속되는지 자체가 꽤 까다로워질 수 있을 것 같아서요. 바로 떠오르는 타입 예로, 여러 개의 바운딩 박스를 가진 이미지가 있다면, 그건 그냥 원본 이미지로부터 상속받나요?

맞아요. 대체로 그런 것들은 잘 합성되죠. 우리는 다중 상속은 거의 쓰지 않아요. 가능하면 피하려고 합니다. 늘 좀 까다롭다고 느꼈거든요. 그래서 전반적으로 더 함수형에 가깝게 설계했다고 보면 돼요. 예를 들어 흑백 이미지는 Image를 상속받고, 의료 이미지인 DICOM 이미지도 Image를 상속받죠. 그리고 타입 시그니처를 가진 여러 변환들이 있는데, 어떤 것은 Image를 받고, 또 다른 것은 DICOM 이미지를 받아요. 그래서 DICOM 이미지를 인자로 호출했는데 DICOM 이미지를 받는 등록된 함수가 없다면, Image를 받는 함수가 있다면 그쪽으로 디스패치합니다. 또 한 가지는, 특정 방식으로 다형성을 쓰기도 해요. 우리는 덕 타이핑을 많이 활용해서, 예를 들어 draw라는 메서드가 있고, 그 draw 메서드는 다양한 Image 하위 클래스에서 다르게 구현될 수 있죠. 그리고 그 Type Dispatch 시스템으로 할 수 있는 또 다른 일은, 인자를 복수의 타입으로 지정하는 거예요. 즉, 그 함수 인자가 여러 타입 중 아무 것이나 될 수 있도록 하는 거죠. 이렇게 하면 즉석에서 유니온 타입을 만들 수 있어서 꽤 편리합니다.

V2에서 아직 만족스럽지 않은 부분이 있나요? 우리의 비전을 정말로 실현하고 있다고 볼 수 있을까요?

여전히 몇 가지 아쉬운 부분이 있어요. 그중 일부는 코로나 때문에 생긴 일이기도 합니다. 안타깝게도 제가 전 세계 마스크 운동의 얼굴처럼 되어 버리면서, 딥러닝 같은 더 흥미로운 일들에 쓸 여지가 많지 않았거든요. 그래서 막판에 넣은 것들, 예를 들면 추론 관련 기능 중 일부는 아직 조금, 어쩌면 다소 투박한 면이 있어요. 다만 소소한 부분들일 뿐이고, 전체적인 추론 파이프라인은 꽤 잘 작동합니다. 예를 들어, X 없이 어떻게 동작할지에 대해서는 충분히 살피지 못했어요. 모바일이나 대규모 스케일 아웃 서빙 같은 경우가 그렇죠. 또 학습 루프는 조금 더 유연해질 필요가 있습니다. Hugging Face Transformers API가 전제하는 가정들이 우리 쪽 가정과 잘 맞지 않는 부분들이 있거든요. TPU 학습의 경우에도, 별도의 머신에서 돌아가고 직접 접근할 수 없다는 특성상 지연 시간이 매우 큰 작업들을 어떻게든 처리해야 합니다. TPU에서는 이런 점이 특히 중요한데, 우리가 GPU 혹은 PyTorch 위에서 동작하는 새로운 컴퓨터 비전 라이브러리를 통째로 만들었기 때문이에요. 일반적으로 PyTorch는 GPU를 타깃으로 하고, 좋은 NVIDIA 드라이버와 함께 GPU 커널 런치 지연도 꽤 양호하죠. 그래서 변환 같은 작업을 GPU에서 많이 처리할 수 있었어요. 그런데 TPU에서는 무언가를 새로 빌드할 때마다 그 큰 지연을 매번 거쳐야 해서 이런 접근이 전부 무너집니다. 그래서 이런 자잘하지만 중요한 개선 과제들이 몇 가지 남아 있어요.

학습 맥락 밖에서도 당신의 라이브러리가 널리 쓰이는 것이 중요하다고 보시나요? 실제 프로덕션 시스템에서 폭넓게 활용되도록 하는 것이 목표 중 하나인가요?

그렇죠. 제 생각에는 학습 맥락은 언젠가는 사라져야 한다고 봐요. 언젠가는 Fast.ai 강의가 없어지고 소프트웨어만 남는 게 이상적이겠죠. 만약 사람들이 소프트웨어를 오로지 학습 상황에서만 쓴다면, 결국 아무도 쓰지 않게 될 겁니다. 우리는 어디서든, 혹은 그와 비슷한 무언가가 어디서든 쓰이길 원해요. Fast.ai여야 하느냐, 아니면 누군가가 더 나은 걸 만들어 오느냐는 사실 중요하지 않아요. 중요한 건 딥러닝을 누구나 접근할 수 있게 만드는 것이고, 그건 정말 매우 중요합니다. 흥미로운 점은, 딥러닝이 너무 새롭고 매우 빠르게 등장하다 보니, 상업 영역에서도 의사결정자들이 대체로 학계 중심의 사람들인 경우가 많다는 거예요. 학술 생태계의 영향력이 제가 겪어 본 다른 어떤 분야보다 훨씬 큽니다. 그래서 우리가 해야 할 일 중 하나는 연구자들이 Fast.ai를 쓰도록 하는 것입니다. 우리도 연구자이기 때문에, 연구자 친화적으로 만들기 위해 노력하고 있고, 지금 시점에서 그게 핵심 초점 중 하나예요.

그러니까, 직관적으로 생각하면 연구자 친화적으로 만든다는 건 하나의 깔끔한 단일 API로 만들거나 모든 세부를 추상화해 버리는 것과는 반대일 것 같아요. 연구자들은 오히려 저수준의 가정들을 직접 만지고 실험해 보길 원할 거라고 생각하거든요.

맞아요. 그래서 계층화된 API가 필요한 거예요. 먼저 알아야 할 점은, 지금은—혹은 이미—딥러닝을 활용해 연구하는 연구자들의 대부분이 딥러닝 그 자체의 연구자가 아니라는 겁니다. 그들은 단백질체학 연구자이거나 유전체학 연구자, 축산학 연구자, 혹은 천체물리학자 등등이에요.

하지만 당신은 그것을 듣지 못했죠.

몇 해 전에 저는 국제 축산학 대회에서 기조연설을 했습니다. 가족과 함께 오클랜드로 멋진 여행을 다녀왔는데, 무척 즐거웠어요. 사실 그 행사는 해들리 위컴의 아버지가 주최했고, 그분이 저를 초청해 주셨습니다.

말씀 중에 끼어들어서 죄송해요. 아무 이유 없이 중단시켜 버렸는데, 정말 흥미로운 말씀을 하고 계셨거든요. [웃음]

축산학에 그렇게 무지한 줄은 몰랐어요. 루카스, 정말 실망이에요, 친구. [웃음]

사람들이 제시하는 색다른 활용 사례들을 정말 좋아해요. 그런 것들을 계속 모으고 있긴 한데… 그건 아직 들어본 적이 없네요.

맞아요. 미안한데, 어디까지 얘기했었죠? 우리가 얘기하던 게… 아, 그래요. 연구자들. 그러니까 지금 어떤 주제에 대해 연구를 하고 있는 거죠, 그렇죠? 예를 들어 FP16 학습에서 더 나은 gradient accumulation 방법을 찾고 있을 수도 있고, 새로운 활성화 함수를 시도하고 있을 수도 있고, 혹은 4채널 입력을 다루는 다른 방식이 하이퍼스펙트럴 위성 이미지에 잘 맞는지 알아보려는 걸 수도 있어요. 핵심은 여러분이 그 “연구 대상”에 집중하도록 하고, 다른 모든 것에는 신경 쓰지 않도록 해주는 거예요. 하지만 동시에, 나머지 것들도 가능한 한 잘 되어 있어야 하죠. 왜냐하면 나머지를 형편없이 해놓으면 “내 활성화 함수가 정말 좋다”라고 결론낼 수도 있지만, 다른 누군가는 “아니야, 데이터 증강을 엉망으로 해서 그런 거야”라고 지적할 수 있거든요. 예를 들어 Dropout을 추가하면 당신 방법의 이점이 사라질 수도 있고요. 그래서 계층화된 API를 쓰면, 서로 잘 맞도록 기본값이 설정된 가장 고수준의 쉬운 부분들을 활용하면서, 딱 필요한 부분만 골라 원하는 만큼 깊이 파고들 수 있습니다. API에는 크게 네 가지 핵심 레이어가 있다고 보면 돼요. 새 데이터 블록을 만들 수도 있고, 새 트랜스폼을 만들 수도 있고, 새 콜백을 만들 수도 있죠. Fast.ai의 장점은, 제가 아주 익숙한 기술인 Keras와 비교해도 훨씬 “해킹하기 쉬운(hackable)” 구조라는 점이에요. Keras나 TF.data를 쓰면 꽤 잘 정의된 변환 파이프라인과 원자적 유닛들이 있고, 그걸 커스터마이즈하려면 쉽지 않습니다. 종종 C++로 새로운 TF op를 만들어야 하는 식이 되죠. 반면 PyTorch를 쓰는 건 큰 도움이 돼요. 낮은 지연의 좋은 원시 연산들을 제공하고, 우리는 그 위에 모든 걸 쌓아 올리되, API를 단계적으로 레이어링하고 각 레이어를 끝까지 아주 잘 문서화합니다. 그래서 “여기부터는 내부 API니까 알아서 하세요” 같은 상황이 없어요. 전부 외부 API이고, 전부 문서화되어 있고, 전부 테스트가 있고, 전부 예제가 있고, 전부 설명이 있습니다. 그래서 여러분은 정말 필요한 지점에 자신의 연구를 정확히 끼워 넣을 수 있어요.

알겠어요. 그러니까 지금 말씀하시는 “연구자”는, 기계학습 자체를 연구하는 실제 머신러닝 연구자를 뜻하는 거죠? 반면에, 머신러닝의 응용이 필요한 축산학 연구자 같은 경우와는 구분해서, 두 부류 모두를 염두에 두고 계신다는 의미로 이해하면 될까요?

네, 둘 다요. 제가 ML 연구자들의 요구를 이해하기가 더 쉬운 건 제가 그 일을 하고, 주로 그런 사람들과 어울리기 때문이죠. 하지만 겹치는 부분이 많아요. 예전에 직접 참석할 수 있는 학회들이 있을 때 느꼈던 건데요. NeurIPS를 돌아다니다 보면 많은 분들이 다가와서 “방금 발표했어요. 방금 포스터 발표를 했어요. 그리고 3년 전엔 Fast.ai 수강생이었죠. 그전엔 기상학자였고, 천체물리학자였고, 신경과학자였어요.”라고 말하곤 했어요. 그러면서 “당신의 강의로 이 분야를 이해했고, 그다음엔 당신들의 소프트웨어를 썼고, 거기에 천체물리학이나 신경과학에서 가져온 아이디어들을 접목했어요. 그래서 지금 NeurIPS에서 그걸 발표하고 있어요.”라고 하더라고요. 그래서 지금은 ML 연구와 도메인 전문성의 세계가 아주 흥미롭게 맞물리고 있어요. 점점 더 많은 도메인 전문가들이 충분한 역량을 갖춘, 존중받는 ML 연구자가 되고 있거든요. 사실 그래야만 하죠. 예를 들어 의료 영상에서 정말 뛰어난 성과를 내려면, 여전히 풀어야 할 기초적인 질문들이 많아요. 거대한 3D 볼륨을 실제로 어떻게 다룰 것인가 같은 문제들은 아직 해결되지 않았고, 따라서 정말 뛰어난 딥러닝 연구자가 되기도 해야 합니다.

제가 늘 스스로 걱정하는 것 중 하나는 데이터와 멀어지는 거예요. 그러니까 20대 초반이었을 때, 지금 제 나이 또래였던 종신 교수들을 보면서 “와, 저 사람들은 머신러닝의 최전선에 더 이상 머물지 못하고 있네”라고 생각했던 기억이 있어요. 그러다 제가 회사를 창업하고 나니, 제 자신도 실제로는 최신 동향을 따라가지 못하고 있었고, 익숙한 예전 기법이나 편한 언어에 머무르는 경우가 많다는 걸 깨달았죠. 반면에 당신은, 적어도 제가 보기에는, 정말 놀라울 정도로 최신을 잘 따라가고 맥을 정확히 짚고 있는 것 같아요. 그걸 어떻게 해내는지에 대해 생각이나 비결이 있다면 궁금합니다.

음, 그러니까, 저는 당신이 크라우드소싱의 세계에서 벗어나 딥러닝으로 전향한 걸 정말 존경했어요. 아마 그걸 제대로 익히는 데만도 1년 정도를 들였던 걸로 기억하는데, 맞죠? 그렇게까지 하는 사람은 많지 않아요. 그리고 많은 사람들이 자신은 그럴 수 없다고 생각하죠. 예를 들어 30대 중반쯤에 이르고 지난 10년 동안 새로운 큰 분야를 배워본 적이 없다면, 스스로 그런 능력이 없다고 쉽게 믿게 되거든요. 그래서 결국 당신이 했던 것처럼, 하겠다고 결심하는 게 필요하다고 봐요. 저의 경우엔 18살 때 꽤 극단적인 결정을 내렸어요. 남은 인생 동안 매일 하루의 절반은 새로운 것을 배우거나 연습하는 데 쓰겠다고요. 평균적으로는 지금까지 그 약속을 지켜왔고요. 요즘은 체감상 한 80퍼센트에 가까운 것 같기도 해요. 웃긴 건, 지금도 제 뇌는 새로운 걸 이해하지 못할 거라고 계속 말해요. 무언가를 읽기 시작했는데 바로 이해가 안 되면, 제 뇌가 “이건 네 수준을 벗어났어”라고 속삭이죠. 그래서 그 순간을 억지로라도 뚫고 나가야 해요. 하지만 저는 십대 때 이런 깨달음을 했어요. 새로운 기술을 배우는 건 지렛대 효과가 엄청 큰 활동이라는 거죠. 그래서 만약 평생 동안 그걸 계속하면—제가 보기에 아무도 그렇게 하지 않았거든요, 제 주변엔 정말 한 사람도 없었어요—그렇다면 결과가 기하급수적으로 늘어나지 않을까 하고 가설을 세웠어요. 그렇다면 시도해봐야 한다고 생각했고, 그게 제 접근 방식이 되어왔습니다.

그 영역에 그렇게 이성적으로 접근했다는 게 놀라워요. 그게… 즉각적인 본능을 거슬러 싸워야 가능한 건가요? 아니면 즐거움인가요?

이젠 본능적으로도 괜찮아요. 다만 제가 해야 하는 건 싸우는 일인데, 예전처럼은 아니에요. 지금은 아내와 함께 일하니까요. 그리고 실비아처럼 저를 깊이 이해해 주는 사람과 함께 일하고 있고, 제 일상에서도 비슷한 맥락으로 주변 사람들과 다투거나 최소한 부딪히는 일을 겪곤 했죠. 특히 내가 상사일 때 누군가에게 “지금 X를 급하게 해야 해요”라고 말하면, 그 사람이 이렇게 말할 수 있거든요. “대체 왜 X를 처음 하는데 줄리아를 쓰나요? 우리 줄리아도 모르잖아요. 이미 펄이나 파이썬처럼 아는 걸로 했으면 벌써 끝났을 텐데요.” 그런데 저는 “그냥 줄리아를 배우고 싶었어요”라고 하죠. 그러면 같이 일하는 사람들이 미칠 지경이 돼요. 다들 바쁘고, 그 순간에는 이해하기가 어렵거든요. “지금 이 순간이 당신 인생의 나머지 모든 순간보다 더 중요한 건 아니고, 지금 시간을 들여서 실력을 키우지 않으면 앞으로의 인생 내내 조금씩 더 느리고, 조금 덜 유능하고, 조금 덜 아는 사람이 될 거예요.” 이걸 순간에 받아들이기가 어렵습니다. 그게 가장 어려운 부분이에요.

방금 주신 예들만 봐도, 당신은 확실히 ‘직접 해 보면서 배우는’ 쪽에 강한 성향이 있는 것처럼 들려요. 맞나요? 논문을 읽고 그걸 또 다른 방식으로 소화하고 종합하는 편이기도 한가요?

네, 저는 논문을 읽을 때, 그걸 구현할지 말지, 혹은 구현해 볼만한 아이디어를 건질 수 있는지 판단이 설 때까지 이미 평가를 해요. 그래서 저는 직접 해보는 걸… 글쎄요, 저는 꽤 직관적인 사람이라서, 많이 손을 움직이고 실험을 하다 보면 것들이 어떻게 서로 맞물리는지 감이 옵니다. 리처드 파인먼이 자신의 연구와 논문 이해 방식에 대해 말한 걸 정말 좋아하는데, 그는 논문을 읽을 때마다 반드시 물리적 비유를 떠올리고, 그 비유가 떠오르기 전에는 더 이상 읽지 않는다고 했죠. 그리고 그 물리적 비유가 무너지는 지점을 포착함으로써 논문의 오류를 바로 알아챌 수 있었다고 했어요. 저도 약간 그런 편입니다. 항상 맥락과 ‘이게 무엇을 위한 것인지’에 대한 이해를 찾고, 그다음 실제로 구현해 보려고 합니다.

그렇군요. 그렇다면 Fast.ai의 다음 버전은 새로운 언어로 나올 수도 있을까요? 파이썬에서 벗어나는 걸 고민해 보신 적이 있나요? 음, 그러니까, 당연히 고민해 봤죠. 스위프트도 살펴봤고요. 안타깝게도 크리스 랫너가 구글을 떠나서, 글쎄요… 좋은 인재들이 여전히 남아 있다면 훌륭한 뭔가를 만들어낼 수도 있겠지만, 저는 대체로 사람을 따라가는 편이에요. 여러 번 성공을 증명한 사람들, 크리스가 그런 인물이니까요. 그래서 다음은 뭐가 될지… 잘 모르겠어요. 분명한 건, 파이썬이 머신러닝의 미래는 아니라는 겁니다. 그럴 수가 없어요. 파이썬은 해킹하듯 빠르게 손대기엔 정말 좋지만, 외부 코드나 C 코드를 부르지 않으면 충분히 빠르게 할 수 있는 일이 거의 없고, 병렬 실행도 별도의 프로세스를 써야 하는 언어로 일하는 게 너무 답답합니다. 파이썬으로 일하다 보면, 충분히 빠르게 만들기 위해 머릿속에서 감당해야 하는 오버헤드가 너무 커요. 많은 일엔 괜찮지만, 딥러닝이나 머신러닝 세계 전체를 놓고 보면 꼭 그렇진 않죠. 그래서 저는 줄리아가 정말 성공하길 바랍니다. 잘 설계된 타입 시스템과 디스패치 시스템을 갖춘 언어이고, 무엇보다 아래까지 전부 줄리아라는 점이 중요해요. GPU 커널을 줄리아로 직접 쓸 수 있고, LLVM에 닿기 전까지 기본 요소들이 전부 줄리아로 구현되어 있거든요. 죄송하지만 좀 민망한 질문을 드릴게요. 줄리아는 매트랩 같은 건가요? 그렇게 생각하면 될까요?

매트랩 사용자들도 쓸 수 있도록 설계되긴 했지만, 아니요, 더 정확히 말하면 커먼 리스프와 매트랩, 파이썬이 만나는 쪽에 가깝습니다.

그건 약간 R과 비슷한 면이 있네요, 아마도.

R에는 괜찮은 아이디어들이 있었지만, R의 객체 시스템은 a) 종류가 너무 많고, b) 전부 편법에 가깝고, c) 지나치게 동적이라서 아주 느립니다. 그래서 또다시, 모든 걸 R이 아닌 다른 것으로 구현하고 R은 그 위에서 붙이는 접착 언어가 되어버리죠. 저도 R을 정말 수년간 썼고, 필요한 건 결국 얻긴 했지만, 즐겁진 않았습니다. 반면 줄리아는 컴파일 언어이고, 풍부한 타입 시스템을 갖췄으며, 전적으로 그 타입 시스템을 활용한 함수 디스패치에 기반합니다. 매우 강력한 메타프로그래밍 방식도 가지고 있어요. 그래서 예를 들어 CUDA 커널을 줄리아로 작성할 수 있는 겁니다. 오토그래드도 줄리아로 다시 구현돼 있고요. 좋은 기능이 많지만, 아쉽게도 아직 기업의 본격적인 지지를 얻지 못해서, 시작 멤버이자 지금의 Julia Computing을 운영하는 초엘리트 소수 핵심 그룹에 크게 의존하고 있습니다. 제가 보기엔 뚜렷한 비즈니스 모델도 없어 보여요. 벤처 투자를 계속 받는 방식은 한동안은 통하지만, 어느 시점엔 멈추거든요.

Fast.ai의 비즈니스 모델은 무엇인가요? 비즈니스 모델이 있긴 한가요?

Fast.ai의 비즈니스 모델은 제가 제 은행 계좌에서 돈을 빼서 필요한 것들을 지불하는 것, 딱 그 정도입니다.

좋아요. 저희가 늘 마지막에 두 가지 질문으로 마무리하는데, 이번에도 일관성을 위해 그 시간을 꼭 갖고 싶습니다. 첫 번째 질문은 이겁니다. 머신러닝을 폭넓게 봤을 때, 사람들이 일반적으로 생각하는 것보다 훨씬 더 많은 주의를 기울여야 한다고 보시는 주제가 있을까요?

네, 그리고 제가 생각하기에 사람들이 잘 아는 분야 바깥의 딥러닝 세계를 보는 게 중요합니다. 예를 들어 제가 NLP를 시작했을 때, NLP 쪽 사람들 누구와 이야기해도 지난 3~4년간 컴퓨터 비전에서 이루어진 발전을 거의 모른다는 사실에 충격을 받았습니다. 예컨대 전이 학습 같은 개념과 그 놀라울 만큼의 유연성 말이죠. 그게 ULMFiT로 이어졌고, 이어서 GPT, 다시 GPT-2로 이어졌습니다. ULMFiT가 나오기 전에는, 제가 만난 모든 NLP 연구자에게 “언어 모델로부터의 초대규모 전이 학습” 아이디어를 어떻게 보느냐고 물으면 다들 그건 바보 같은 생각이라고 했고, 컴퓨터 비전 쪽 사람들은 당연히 모두가 이미 그렇게 하고 있을 거라고 답했죠. 그래서 전반적으로 사람들은 딥러닝에서 지나치게 세분화·전문화되어 있고, 다른 영역에 훌륭한 아이디어가 아주 많다고 봅니다.

흥미롭네요, 멋집니다. 그리고 늘 드리는 마지막 질문인데, 이 부분에 대해선 특별히 흥미로운 관점을 갖고 계신 것 같아 궁금합니다. 보통은 동물 사육 같은 특정 목적을 위해 머신러닝 모델을 사용하려는 분들과 이야기하곤 하죠. 그런데 당신은 아주 넓은 범위의 활용 사례를 보셨잖아요. 아이디어 단계에서 실제 배포되어 잘 작동하고 유용한 것들에 이르기까지를 두루 보셨을 때, 가장 큰 병목은 어디에 있다고 보시나요?

그러니까 제 말은, 제 평생 동안 관여해 온 머신러닝 관련 프로젝트들은 늘 실제로 성공적으로 배포되어 왔습니다. 그래서 머신러닝이 추상적인 개념일 뿐 누구도 실제로 쓰지 않는다고 말하는 사람들을 보면 답답해져요. 문제의 큰 부분은 비즈니스, 물류, 프로세스 관리 등을 이해하는 사람들과 AI, 알고리즘, 데이터 등을 이해하는 사람들 사이에 연결고리가 별로 없다는 데 있다고 봅니다. 저는 10년 동안 경영 컨설턴트로 일했기 때문에 제 일상은 물류, 비즈니스 프로세스, 인사 등 그런 것들이었거든요.

경영 컨설턴트라고 생각하면 좀 상상이 잘 안 가네요. 꽤 의외예요.

최대한 능숙한 척하려고 정말 열심히 했습니다. 머신러닝 세계의 많은 사람들이 제약을 다루고 기회를 찾고 가치 사슬을 통합하는 일의 복잡성을 과소평가하는 경우를 자주 봅니다. 혹은 정반대로, 그게 너무 어려워서 불가능하다고 단정해 버리기도 하죠. 하지만 전 세계에는 평생을 바쳐 이런 문제들을 연구하고 해법을 찾아내는 사람들이 큰 집단으로 존재한다는 사실을 모른 채 말입니다. 그래서 전반적으로, 더 나은 학제 간 팀이 늘어나고, MBA 쪽 사람들은 AI 역량을 더 키우고, AI 쪽 사람들은 비즈니스와 팀에 대한 이해를 더 넓히는 모습을 보고 싶습니다.

배경 덕분에 전반을 넓게 보고 계시고, 여러 분야에서 ML 프로젝트가 실제로 배포되는 걸 지켜보셨잖아요. 그래서 궁금한 건, 진행하면서 예상보다 난도가 높아서 놀랐던 지점들이 있었는지예요. 예를 들어, 모델이 잘 작동한다고 생각했는데, 실제 프로덕션에 배포하고 나니 기대했던 만큼 성능이 나오지 않거나 처음 생각과 달랐던 시행착오가 있었나요?

전혀요. 이상하게 들릴지 모르겠지만, 결국은요, 당신이 만들고 있는 것이 실제로 통합하려는 대상 업무에 대해 조금이라도 직접 일한 배경이 있느냐가 중요하거든요. 저는 10년, 정확히는 8년 동안 운영 연구와 머신러닝에 전적으로 기반한 보험 요율 책정 비즈니스를 했습니다. 그 전에 경영 컨설턴트로 일한 마지막 4~5년은 거의 전부가 보험 분야였고요. 그러니 아주 놀라울 일은 별로 없습니다. 사람들도 알고, 프로세스도 압니다. 그래서 저는 누군가가 파라리걸용 AI 비즈니스를 하려 한다면, AI 전문가가 하는 것보다 파라리걸이 하는 걸 훨씬 더 선호합니다. HR 채용용 AI 비즈니스를 한다면, HR 채용 배경이 있는 사람이 하는 게 훨씬 낫다고 보고요. 그게 정말 어렵거든요. 몇 년간 그 업을 직접 해보지 않고서는 그 산업을 제대로 이해할 방법이 사실상 없다고 생각합니다.

제가 그분들 중 몇 분을 알고 있기도 하고, 이런 질문을 정말 자주 받다 보니, 지금 이걸 보고 계신 분들 머릿속에 있을 법한 질문을 대신 드려볼게요. 만약 파라리걸인 당신이 파라리걸 업무에 AI를 접목한 비즈니스를 시작한다면, AI 부분은 어떻게 하시겠나요? 음, 당연히 저는 fast.ai 강의를 수강할 겁니다. 진심으로요. 우선 코딩 실력을 제대로 갖추겠어요. 1년 정도는 코딩에 집중해서 실력을 키우고, 네, fast.ai 강의가 딱 그런 분들을 위해 고안된 과정이거든요. 그리고 본인이 일단 전 과정을 직접 해보기 전까지는 이른바 AI 전문가를 쉽게 합류시키지 않겠어요. 제 경험으로, 그런 상황의 대부분은 당연하게도 AI 세계에 꽤 주눅 들고 압도당한 느낌을 받습니다. 그러다 스스로를 전문가라고 소개하는 사람을 데려오는데, 정작 그 사람의 전문성을 평가할 능력이 없죠. 그러면 결국 실제 역량과는 부정적으로 상관될지도 모르는 ‘자신감 있게 보이는 태도’에 능한 사람을 데려오게 됩니다. 그래서 제 말은, 하세요. 직접 해보세요. 1년 동안 최선을 다해 최고의 것을 만들어 보세요. 또 fast.ai 수강생들 중에는 도메인 전문가인 분들이 AI 전문가들과 협업해 보면서 놀라곤 합니다. 실제로 무언가를 정확히 예측하는 모델을 훈련하는 데, 소위 모델링 전문가들보다 본인들이 훨씬 더 잘 해낸다는 걸 발견하거든요. 아마 당신도 저처럼 이 분야의 정통 기술 배경이 없으면서도 그런 경험을 해보셨을 거라고 확신합니다.

네. 정말 감사합니다. 저에게도 무척 재미있고 많은 걸 배운 시간이었습니다.

초대해 주셔서 정말 감사합니다. 초대해 기쁩니다.