Transcript
00:00:00AI, 소프트웨어 개발 및 온갖 신기술에 대해 이야기를 나누는 'Better Start' 팟캐스트에 오신 것을 환영합니다.
00:00:06저는 진행자를 맡은 리차드이고, 오늘 함께할 분들은...
00:00:08제임스입니다. 안녕하세요.
00:00:10앤드루스입니다. 안녕하세요.
00:00:11그리고 저는 빈센트입니다. 안녕하세요.
00:00:12빈센트, 오프더레코드 때 말씀하셨듯이 키보드를 정말 많이 가지고 계시잖아요.
00:00:16어떻게 빠져들게 되셨는지 이야기해 주시겠어요?
00:00:18네.
00:00:19좋습니다. 보통 사람들이 제 유튜브를 보시면 다들 이렇게 생각해요.
00:00:23'와, 저 사람 키보드가 기괴할 정도로 많네' 하고요.
00:00:25하지만 그 시작은 나름 꽤 슬픈 이야기였습니다.
00:00:27제가 이쪽 손에 상당히 심각한 반복사용수근관증후군(RSI)을 겪었거든요.
00:00:30지금은 완치됐지만, 일반 키보드를 쓸 때
00:00:35엔터 키를 누를 때마다 손목을 오른쪽으로 까딱여야 하는 시기가 있었어요.
00:00:39아, 그게 정말 너무 고통스러웠죠.
00:00:40정말 안 좋은 습관이었어요.
00:00:41운동을 하거나 키를 누르기 전에 손을 미리 들어 올리는 식으로 더 좋은 습관을 가질 수도 있지만요.
00:00:47어쨌든 심각한 손목 통증이 생기니까 이런 생각이 들더군요.
00:00:50'인체공학적인 환경에 투자를 해야겠구나, 키보드를 알아보는 게 좋겠다'라고요.
00:00:55 그런데 유튜브에 있는 리뷰들 다수가 너무 형편없다는 걸 알게 됐습니다.
00:00:59어느 정도 이해는 돼요. 긍정적인 리뷰를 남겨주면
00:01:02키보드 업체에서 좋은 소리만 계속해 주니까 샘플을 또 협찬해 줄 테니까요.
00:01:07하지만 리뷰를 보는 입장에선 단점도 듣고 싶잖아요.
00:01:09그래서 생각했죠. '내가 직접 해야겠다' 하고요.
00:01:12제품들을 리뷰할 때 장점도 당연히 다루겠지만,
00:01:16인터넷에 단점까지 솔직하게 말하는 사람 한 명쯤은 있어야 하지 않겠어요.
00:01:19그게 결국 제 첫 영상 4개로 이어졌고, 마침내 맘에 쏙 드는 키보드 하나에 정착했습니다.
00:01:25Glove80이라는 제품인데요.
00:01:25손목에 문제가 있다면 아주 훌륭한 기본 선택지죠.
00:01:28그런데 사람들이 알아보더니 제품을 보내주기 시작했습니다.
00:01:31제 뒤에 보이는 키보드 전부까지는 아니지만, 대부분 제 사비로 산 게 아니에요.
00:01:36그렇게 이 모든 일이 시작된 거죠.
00:01:37결국 인터넷상의 낯선 사람들에게 온갖 물건을 받는 유튜버 같은 존재가 되어 버린 건데,
00:01:42그중 일부는 기꺼이 리뷰하고 있습니다.
00:01:44요약하자면 그런 이야기예요.
00:01:46그리고 시간이 지나면서 그게 좀 더 취미에 가까워지죠.
00:01:48그래서 엄청 화려한 스위치 같은 것들을 탐구하기 시작하는 겁니다.
00:01:52요즘도 가끔 그렇게 하고 계시나요?
00:01:54채널에서 키보드 리뷰 같은 거요?
00:01:56네, 그건 제 개인 채널에서 하고 있어요.
00:01:58어느 시점이 되면, 커다랗고 멋진 이목을 끄는 키보드들은
00:02:06이미 다 써보게 되거든요.
00:02:07그러고 나면 점점 더 매니아틱한 분야로 파고들게 되죠.
00:02:10하지만 제 입장에선 즐거운 취미인 이상 계속할 겁니다.
00:02:13더 이상 재미없어지면 그때 그만둘 수도 있겠죠.
00:02:15하지만 그전까지는, 유튜브용 촬영을 할 때 훌륭한 배경이 되어주기도 하고요.
00:02:19취미 활동에 도움이 된다고 볼 수 있겠네요.
00:02:22네, 저는 키보드 쪽은 그렇게 깊게는 잘 몰라요.
00:02:24아, 죄송해요. 제임스 말씀하세요.
00:02:25저도 그 취미에 입문해보려고 했었다는 말을 하려던 참이었어요.
00:02:26하지만 시작하기엔 돈이 꽤 많이 드는 취미더라고요.
00:02:30요즘엔 저렴한 키보드로도 꽤 괜찮게 입문할 수 있다고 생각해요.
00:02:33하지만 제 입문은 딱 거기서 끝났죠.
00:02:35'여기서 더 깊이 파고들면 돈이 엄청 깨지겠구나' 싶었어요.
00:02:39그건 확실히 맞는 말씀입니다.
00:02:40그리고 전 특정 키보드를 사라고 추천하는 걸 싫어해요. 돈이 많이 드는 일이니까요.
00:02:45피해야 할 행동에 대해 경고해 드리는 건 아주 좋지만,
00:02:48뭘 사야 할지 정해주는 건 싫어요. 직접 알아내셔야 하니까요.
00:02:51다만 이 주제 전체에 대해 한 가지 말씀드리고 싶은 건, 어느 순간이 되면 이른바 '인체공학 키보드'냐 아니냐의 문제가 아니게 된다는 겁니다.
00:02:58좌우 대칭 형태의 화려한 키보드 같은 거 말이죠.
00:03:00어떤 시점부터는 '직접 펌웨어를 플래싱해서 마음대로 커스텀할 수 있는 키보드를 원해'라고 생각하게 돼요.
00:03:05쓸모없는 버튼인 캡스락을 백스페이스로 변경할 수 있도록 설정하는 식이죠.
00:03:11그러면 손이 이동해야 하는 거리가 줄어드니까요.
00:03:13아니면 Whisper나 원하는 앱을 실행하도록 만들 수도 있고요.
00:03:17키보드 자체를 완전히 원하는 대로 설정해두면, 노트북이나 다른 기기를 바꿀 때도 좋은 습관을 그대로 가져갈 수 있죠.
00:03:25그리고 Vim 설정에 관심이 있는 분들께 말씀드리자면, 예, Vim은 당연히 설정해서 쓸 수 있죠.
00:03:30거기에 키보드까지 함께 맞춰서 설정할 수 있다고 상상해 보세요.
00:03:33인체공학적이라는 점을 차치하고서라도 엄청나게 생산적이고, 하드웨어를 직접 커스텀할 수 있다는 건 정말 매력적인 일이죠.
00:03:41네, 그 부분은 저도 동의합니다.
00:03:44하지만 커스텀이 가능하다는 걸 알고 사기가 쉽지 않아요. 시중에 키보드는 많지만 펌웨어 수정이 불가능한 경우가 많으니까요.
00:03:52그래도 소프트웨어 대안들이 있긴 합니다.
00:03:54Mac에서 인기가 많은 Karabiner-Elements나 Kanata 같은 프로그램이 있죠.
00:03:59그런 솔루션들에 대해선 어떻게 생각하시나요?
00:04:01Mac만 쓰신다면 그렇게 하셔도 된다고 봅니다.
00:04:04하지만 전 리눅스도 쓰거든요.
00:04:05그래서 둘 다 지원하는 게 필요해요.
00:04:07그리고 Keychron이나 NuPhy 같은 키보드조차 내부적으로 QMK라는 펌웨어를 탑재해서 나옵니다.
00:04:14NuPhy와 Keychron 모두 그 위에 자체적인 반독점적 소프트웨어를 구축하고 있죠.
00:04:20완전한 오픈소스만큼 자유롭진 않지만, 그래도 꽤 훌륭합니다.
00:04:23키 위치를 바꾸는 정도는 전부 손쉽게 설정할 수 있어요.
00:04:26그러니 아주 좋죠.
00:04:27그쪽 소프트웨어의 유일한 단점은, 요즘엔 얼마나 바뀌었는지 모르겠지만 보통 '홈 로우 모디파이어(Home Row Mods)'라는 기능이 지원되지 않는다는 점입니다.
00:04:35키를 톡 톡 누를 수도 있지만, 꾹 길게 누를 수도 있잖아요. 대문자를 쓸 때 Shift 키를 누르는 것처럼요.
00:04:41그런데 왜 굳이 Shift만 그렇게 쓰겠어요?
00:04:43'J' 키의 경우 짧게 누르면 그냥 'J'지만,
00:04:45길게 꾹 누르고 있으면 Shift 역할을 하게 만들 수 있죠.
00:04:47그런 식이면 손을 전혀 움직이지 않고도 Shift뿐만 아니라 Command, Control, Alt까지 사용할 수 있습니다.
00:04:53양손 모두 그렇게 설정할 수 있죠.
00:04:55말 그대로 가능성은 무궁무진합니다.
00:04:56온갖 신기한 설정들을 다 할 수 있어요.
00:04:58하지만 키를 꾹 누르는 입력 시간 판정 같은 건 Keychron이나 NuPhy 소프트웨어로는 보통 설정할 수가 없습니다.
00:05:05그러려면 더 깊이 들어가야 해요.
00:05:06Vial 같은 다른 오픈소스 소프트웨어를 쓰며 세부 설정을 해야 하죠.
00:05:11어쨌든 길게 말했지만 이게 제 취미입니다.
00:05:13밤새도록 이야기할 수도 있지만, 그래서 제가 키보드를 이렇게 많이 가지고 있는 거예요.
00:05:16유튜브 때문에 약간 걷잡을 수 없이 커진 취미죠. 영상을 만들기 시작하면 제조사들이 막 몰려들거든요.
00:05:22질문하려던 참이었는데, 대가 없이 그냥 보내주나요? 아니면 “단점은 리뷰하지 말아달라”는 요구조건을 붙이기도 하나요?
00:05:31조건을 붙이기도 하죠.
00:05:31그럼 전 그냥 무시합니다.
00:05:33아, 실제로 이런 일이 있었어요. 한번은 어떤 키보드에서 정말 불편한 점을 발견했거든요.
00:05:41특정 브랜드 이름을 밝히진 않겠습니다.
00:05:42하지만 업체 측에 그 부분을 언급하긴 했어요.
00:05:45“다 마음에 들지만
00:05:48이 두 가지가 좀 아쉬워서 언급하려고 합니다”라고요.
00:05:50그러면 그쪽에서 “저희 제휴 링크(어필리에이트) 제공해 드릴 수 있는 거 아시죠?”라는 식으로 나와요.
00:05:55영상 설명란 하단에 제휴 링크를 넣을 수 있다고 은근히 압박을 주는 거죠.
00:05:58하지만 저는 제휴 링크는 절대 하지 않는다는 원칙이 있어요.
00:06:01그런 원칙이 있으니까 이 일이 더 순수한 취미로 남을 수 있어요. 제게 연락해 오는 사람들도 정직한 리뷰에 진심인 분들이니까요.
00:06:09또 무슨 일이 있었냐면, 키보드를 설계하는 단계부터 제 피드백을 요청하는 회사가 몇 군데 있었어요.
00:06:16그건 약간 애매한 경계선에 걸쳐있긴 하죠. 제 의견이 반영된 제품이라면 나중에 리뷰를 할 때 아무래도 긍정적으로 좋게 말할 확률이 높아지니까요.
00:06:25과거에 그런 요청을 수락한 적이 있긴 한데, 제조사가 정말 새롭고 흥미로운 시도를 할 때만 응했습니다.
00:06:30그런 순간에는 그냥 제 호기심이 이성을 앞서버리거든요.
00:06:33그렇군요.
00:06:33충분히 이해가 됩니다.
00:06:35이제 키보드 이야기는 조금 줄여볼까요.
00:06:38키보드 얘기는 나중에 더 해도 되니까요.
00:06:40여기 있는 우리 대부분, 저를 포함해서 자바스크립트나 타입스크립트를 주로 쓰는 개발자들인데요.
00:06:47잘은 모르겠지만, 앤드루스도 그렇잖아?
00:06:50맞아요.
00:06:51좋습니다.
00:06:52알다시피 빈센트는 대단한 파이썬 전문가시죠.
00:06:54우리 팟캐스트 패널 중에도 파이썬을 다루는 분이 한 분 계신데
00:06:56안타깝게도 오늘 방송에는 참여하지 못하셨습니다.
00:06:59하지만 흥미로운 시간이 될 거예요.
00:07:01파이썬 개발자들끼리 나누는 대화라기보다는 저희에게 개념을 설명해 주시는 느낌이 되겠지만요.
00:07:07그럼 먼저 무슨 일을 하시는지, 어떤 분이신지 자기소개부터 부탁드립니다.
00:07:12좋습니다.
00:07:12안녕하세요, 빈센트라고 합니다.
00:07:13분명히 해두자면 저도 자바스크립트를 조금 다루긴 합니다.
00:07:16그렇군요.
00:07:16하지만 아무래도 파이썬 생태계 쪽으로 더 잘 알려져 있죠.
00:07:19파이썬 분야 안에서도 다양한 생태계가 존재하는데요.
00:07:22웹 개발을 하는 분들도 계시죠.
00:07:23Django, Flask, FastAPI 같은 프레임워크를 들어보셨을 겁니다.
00:07:27많은 분들이 그런 걸 사용하시죠.
00:07:28하지만 요즘 파이썬의 주된 유스케이스가 뭐냐고 묻는다면,
00:07:32대부분 데이터 관련 작업입니다.
00:07:33머신러닝이나 데이터 프레임 라이브러리 같은 것들이죠.
00:07:36그게 바로 제 전문 분야이기도 하고요.
00:07:37암스테르담에서 주최를 도왔던 'PyData'라는 컨퍼런스도 있습니다.
00:07:40그게 제 약력에 대한 간단한 소개이고요.
00:07:42scikit-learn 플러그인도 몇 개 만들었습니다.
00:07:44많은 분들이 그걸로 절 알고 계시죠.
00:07:45데이터 분야의 여러 오픈소스 기업들에서도 일했습니다.
00:07:49spaCy, Explosion, Rasa, scikit-learn 같은 이름을 들어보셨을지도 모르겠네요.
00:07:53그런 곳들이 제 경력입니다.
00:07:54지금은 Marimo라는 회사에서 일하고 있어요.
00:07:56반년 정도 전에 인수되었죠.
00:07:58저희가 하는 일을 쉽게 설명하자면, 최근 점점 더 인기를 끌고 있는 새로운 파이썬 노트북을 제공한다는 것입니다.
00:08:05Jupyter의 차세대 진화 버전으로 보셔도 됩니다.
00:08:07사람들이 보통 그렇게 표현하곤 하죠.
00:08:10네, 다운로드 수 기준으로 주당 5% 정도씩 성장하고 있어요.
00:08:14현재 저희 평균 수치가 그렇습니다.
00:08:151년 만에 프로젝트가 11배나 성장하는 걸 직관했는데, 정말 재미있는 경험이었죠.
00:08:21그게 제가 하는 일이고, 현재 가장 집중하고 있는 부분입니다.
00:08:23거기서 엔지니어링 작업도 조금 하고, 그로스(성장) 팀에도 속해 있습니다.
00:08:26그게 제 주요 활동이라 할 수 있죠.
00:08:29이 새로운 노트북을 활용할 멋지고 재미있는 신규 유스케이스들을 찾아내려고 노력하고 있어요.
00:08:33소규모 팀의 일원으로 일하면서 말이죠.
00:08:36지금은 9명 정도 되는 것 같아요.
00:08:38여전히 비교적 작은 규모죠.
00:08:40어쨌든 그게 지금까지 해온 일이고, 지금 주력하고 있는 분야입니다.
00:08:43좋네요.
00:08:44제가 틀렸을 수도 있는데, 데이터 분야를 독학하셨다는 글을 어디서 읽은 적이 있거든요.
00:08:48맞나요?
00:08:49저는 계량경제학과 경영과학(OR)을 전공했습니다.
00:08:51응용 수학 배경지식이 확실히 있었고, 그게 분명 도움이 됐죠.
00:08:55하지만 대학에서 가르쳐준 프로그래밍 수업은 OxMetrics 같은 언어들이었어요.
00:09:01진짜 엄청난 계량경제학 덕후라면 유용할지도 모르겠지만요.
00:09:04실무 세상에서는 전혀 쓸모가 없는 것들이었죠.
00:09:06결국 심경의 결정적인 변화가 찾아온 건 D3라는 게 출시된 걸 보았을 때였습니다.
00:09:12D3가 처음 나왔을 무렵에 딱 졸업을 앞두고 있었거든요.
00:09:15그걸 보고 '와, 이거 진짜 대박이다' 싶었죠.
00:09:18종이 위에 수학 공식을 푸는 것도 아주 멋지지만,
00:09:20그걸 컴퓨터 안에서 인터랙티브한 시각화로 구현해낼 수 있다면, '이건 무조건 배워야 해'라는 생각이 들었어요.
00:09:26그래서 파이썬이나 R 개발자들을 위한 툴을 만들 수 있을 정도로 딱 필요한 만큼 독학했습니다. 파이썬 개발자 대부분은 자바스크립트를 배우지 않으니까요.
00:09:34하지만 전 D3로 시작했죠.
00:09:36결국 다른 사람들은 만들지 않을, 웹상에서 파이썬과 연동되는 화려하고 인터랙티브한 툴들을 전부 직접 구축하게 되었어요.
00:09:42그 덕분에 파이썬 생태계에 발을 들여놓을 수 있었습니다.
00:09:46그러고 나서 파이썬을 독학으로 깊이 파고들었죠.
00:09:48그게 제 이야기의 한 부분이고요.
00:09:50또 다른 비하인드 스토리는, 졸업할 때 '프로그래밍이라는 게 나한테 안 맞나?' 고민을 많이 했었어요.
00:09:57저는 성격이 외향적인 편인데, 프로그래머 중엔 외향적인 사람이 많지 않았거든요.
00:10:00확신이 없었던 거죠.
00:10:01스스로 의문이 들었어요.
00:10:03그래서 배낭여행을 떠나 라틴아메리카를 길게 여행했습니다.
00:10:06네덜란드에서 독립 계약자로 외주받은 간단한 파이썬 작업거리도 챙겨서 떠났죠.
00:10:11여행 중에 문득 이런 생각이 드는 저녁들이 있더라고요.
00:10:16'클럽에 갈 수도 있겠지만, 오늘은 코딩이나 하면서 놀고 싶다'라고요.
00:10:19그게 훨씬 더 재밌게 느껴졌어요.
00:10:20그게 저한테는 강력한 신호였죠. '프로그래밍에 확실히 적성이 맞긴 하구나' 하는 깨달음이요.
00:10:24그래서 제가 살고 있는 네덜란드로 돌아왔을 때, 여기에 올인해야겠다고 다짐했습니다.
00:10:31이국적인 곳에서 클럽 노는 것보다 프로그래밍을 하고 싶다면, 프로그래밍에 올인해서 필요한 걸 전부 독학하는 게 맞으니까요.
00:10:38마블 히어로의 탄생 비화 같은 이야기라고 볼 수 있겠네요.
00:10:44멋지네요.
00:10:46다른 분의 질문 순서를 새치기하는 건 아닌지 모르겠는데, 그 히어로 탄생 서사에서 강좌를 개설하고 가르치는 'Calm Code'라는 사이트를 만드신 걸로 아는데요.
00:11:02그걸 제작하게 된 계기는 무엇이었나요?
00:11:04좋은 질문입니다.
00:11:04제가 느낀 한 가지는, 오븐이 어떻게 작동하는지는 가르쳐줄 수 있어도
00:11:12그게 요리하는 법까지 알려주는 건 아니라는 점이었어요.
00:11:14그리고 점차 대부분의 강좌가 매뉴얼에 가깝고, 피자를 진짜 맛있게 구우려면 도우를 공중에 이렇게 던지는 법부터 익혀야 한다는 식의 강의는 부족하다고 느끼기 시작했어요. 기계의 작동 원리와는 무관하지만 피자를 잘 만들려면 꼭 배워야 하는 단계인데도요.
00:11:29인터넷에 있는 교육 자료와 이전 직장에서 제가 했던 작업들을 돌아보면서, 기존의 가르침 방식에 넌더리가 난 순간들이 몇 번 있었습니다.
00:11:39어떤 건 그냥 2분 만에 설명하고 더 멋진 내용으로 넘어갈 수도 있잖아요.
00:11:44그래서 Calm Code라는 걸 실험적으로 시작하게 됐어요. 주말마다 더 쉽게 설명할 수 있겠다 싶은 도구 몇 개를 골라봤죠.
00:11:51보통 2~3분짜리 영상 5개 정도로 이루어진 강좌를 만들곤 했습니다.
00:11:56그럼 30분 만에 파이썬의 특정 주제가 무엇인지 확실히 감을 잡을 수 있게 되죠.
00:12:01컨텍스트 매니저나 제너레이터 같은 주제들 말입니다.
00:12:04그런 걸 설명하는 데 한 시간씩이나 걸릴 필요는 없거든요.
00:12:07알찬 3분짜리 영상 5개만 있으면 바로 직접 써볼 수 있습니다.
00:12:11그리고 그 프로젝트를 지금까지 계속 유지해 오고 있어요.
00:12:14한 5~6년 전쯤에 만들기 시작했던 것 같네요.
00:12:17요즘은 이놈의 LLM들 때문에 인기가 훨씬 줄어들었지만요.
00:12:21그래도 총 100만 명 정도는 웹사이트를 방문했고, 그중 일부는 여러 강좌를 수강했습니다.
00:12:27결국 유료 회원으로 전환한 분들도 계셨고요.
00:12:29강좌의 99%는 무료입니다.
00:12:31서버 비용을 충당하는 데 보탬이 되도록 몇 개만 유료로 제공하고 있죠.
00:12:34그래도 여전히 한 달에 수백 명, 많게는 천 명 정도가 사이트를 이용해 주고 있어서 계속 유지하고 있습니다.
00:12:41가장 재미있는 건, 암스테르담 모임에 갔을 때 브라질에서 온 분이 느닷없이 다가와서 “Calm Code 만드신 분 맞죠?” 하고 알아보는 일이에요.
00:12:50그럼 저는 “네, 맞아요. 지구 반대편에서 오신 분이라니 반갑네요” 하고 인사하죠.
00:12:53네, 5년 전에 시작한 제 취미 프로젝트입니다.
00:12:56덕분에 지금까지도 멋지고 반가운 순간들을 많이 경험하고 있어요.
00:12:59하지만 이제 아주 활발하게 운영하진 않습니다.
00:13:02항상 재미있는 사이드 프로젝트를 만드는 편인데,
00:13:04이것도 그중 하나였죠.
00:13:07돌아보면 억만장자가 되진 못했어도—그것도 전혀 상관없지만—인지도를 얻었고, 5년이 지난 지금도 확실히 그 덕을 보고 있어요.
00:13:17그렇죠.
00:13:18사실 여쭤보고 싶었던 게 있는데, 네덜란드에는 어떻게 정착하게 되셨나요?
00:13:24제가 네덜란드 사람이라서 가능했죠.
00:13:26아, 네덜란드 분이시군요.
00:13:28억양으로는 전혀 몰랐어요.
00:13:28영어를 꽤 자연스럽게 구사해서 그럴 거예요.
00:13:32미국에서 태어나긴 했지만, 부모님은 네덜란드 분이세요.
00:13:38그래서 고등학교나 대학 과정은 다 여기서 마쳤죠.
00:13:41하지만 중학교 시절에는 미국으로 돌아가서 생활했습니다.
00:13:47보스턴에서 1년, 캘리포니아에서 1년을 보냈죠.
00:13:50소셜 미디어가 나오기 전 시대 이야기인데요.
00:13:53그래서 미국 친구들과 펜팔이 되었고, 몇 년 동안 계속 편지를 주고받았어요.
00:13:59소중한 사람들과 늘 영어로 소통하며 지냈기 때문에, 억양이 거의 사라지지 않은 것 같아요.
00:14:07하지만 네덜란드 사람들은 대체로 영어를 정말 잘하더군요. 암스테르담에 갈 때마다 다들 영어를 유창하게 해요.
00:14:13저희 세대만의 비결이 있다면, 프랑스나 독일과 달리 영어 영화에 항상 네덜란드어 자막을 넣어서 봤다는 점이에요.
00:14:22다른 나라들은 전부 더빙을 했거든요.
00:14:23한 세대 동안 그렇게 자라다 보니, 네덜란드인 전체가 영어를 꽤 잘하게 된 겁니다.
00:14:28주변 이웃 국가들은 그렇지 못한 반면에 말이죠.
00:14:29그러니 많은 미국 기업들이 베를린 대신 암스테르담에 지사를 세우는 것도 전혀 이상한 일이 아니죠.
00:14:36이유야 더 많겠지만요.
00:14:39어쨌든 미국에서 유년기를 일부 보낸 덕분에 이런 억양이 생긴 건데요.
00:14:42이웃들도 제가 진짜 네덜란드인이라는 걸 알아차리기까지 시간이 좀 걸릴 정도였어요.
00:14:48참 재밌고 묘한 일이죠.
00:14:51그래도 지금은 미국인이라기보단 네덜란드인에 훨씬 가깝습니다.
00:14:55멋지네요.
00:14:56아까 슬쩍 스치듯 말씀하신 “이놈의 LLM들” 이야기로 돌아가 볼게요.
00:15:00파이썬과 데이터 과학에 깊이 관여해 오신 분이라 LLM과 AI의 미래에 큰 기대를 걸고 계실 줄 알았는데요.
00:15:08어떤 관점을 가지고 계신가요?
00:15:09찬성 쪽인가요, 아니면 반대 쪽인가요?
00:15:12맹목적으로 낙관하는 부류도 있고, 극단적으로 회의적인 부류도 있죠.
00:15:16저는 그 중간쯤인 보라색 입장 같아요.
00:15:17낙관할 수 있는 이유도 충분히 보지만, 동시에 우려스러운 부분도 많이 보입니다.
00:15:23정말 멋지다고 생각하는 부분도 있고, 참 마음에 안 드는 부분도 있죠.
00:15:27예를 들어 유튜브에서 Hermes에 대해 공부해 보고 싶다고 해봅시다.
00:15:31다들 “Hermes, Hermes” 하니까 말이죠.
00:15:34그래서 알아보려고 검색창에 넣는 겁니다.
00:15:35Hermes를 검색하고 Hermes가 뭔지 침착하고 알기 쉽게 설명해 주는 영상을 찾으려고 하면,
00:15:42상위 10개 영상의 썸네일이 어떨지 상상이 가시나요?
00:15:46그 영상들의 오프닝이 어떨지 그려지시나요?
00:15:48어떤 기술의 작동 방식을 차분하게 설명해 주는 차분하고 유익한 영상일까요?
00:15:52아니면 과장된 자극으로 가득하고, 모니터 화면보다 자기 얼굴을 카메라에 들이대는 유튜버 영상일까요?
00:15:58그리고 이게 새로운 표준이 되어버린 걸까요?
00:16:00제가 LLM 관련해서 마음에 안 드는 게 바로 이겁니다.
00:16:01실제 작동 방식이나 배운 점을 나누기보다는 과도한 하이프가 형성되어 있어요.
00:16:07“인터넷에서 강의 팔아서 돈 벌고 싶다”는 식의 반응이 태반이죠.
00:16:10LLM이 그런 거품을 훨씬 크게 키워 놓았습니다.
00:16:13그 점이 정말 마음에 들지 않아요.
00:16:16저는 담담하게 핵심을 이해하고 의견을 주고받는 분위기를 선호하거든요.
00:16:21무언가를 배우는 본질은 그런 데 있다고 생각합니다.
00:16:23우리에겐 동료가 필요할 뿐이에요.
00:16:26거창한 '구루' 같은 사람을 원하는 게 아닙니다.
00:16:29그저 “함께 하나씩 알아가 보자”는 태도를 바라는 거죠.
00:16:34또 아쉬운 점은, LLM으로 텍스트를 주고
00:16:41이 문장이 긍정적인 감정인지 아닌지 판별해 달라고 할 수 있잖아요.
00:16:47칭찬인지 아닌지 구분하는 것처럼요.
00:16:48그런 분류 작업을 한다고 치고,
00:16:50거기에 LLM을 쓸 수도 있죠.
00:16:52하지만 이건 전통적인 머신러닝 기법으로도 충분히 잘 작동하거든요.
00:16:56그런데 무슨 문제든 일단 LLM 딱지부터 붙이고 보려는 기이한 현상이 벌어지고 있어요. 가장 간단한 방법이 뭔지 한 걸음 물러서서 고민하기보다는 말이죠.
00:17:05단순히 긍/부정을 판단하자고 굳이 대규모 LLM까지 끌어들여 과도하게 에너지를 낭비할 필요는 없잖아요.
00:17:11사람들이 한 단계 물러서서 가장 간단한 솔루션을 고민하지 않게 만든다는 점도 문제입니다.
00:17:16다들 다짜고짜 LLM에 몰두하려고만 하는데, 스스로 생각하는 과정도 여전히 중요하거든요.
00:17:22제가 제일 좋아하는 취미는 새 문제가 생겼을 때 컴퓨터를 끄고 펜과 종이를 들고 공원이나 바에 가서, 원시인처럼 오롯이 제 머리로 고민해 보는 겁니다.
00:17:33그런 과정을 거치는 사람들이 점점 줄어드는 것 같아요.
00:17:35여기까지가 제가 보는 부정적인 측면들입니다.
00:17:37하지만 당연히 부인할 수 없는 뛰어난 유용성도 존재하죠.
00:17:40예를 들어 “비디오 게임을 만들고 싶은데
00:17:43Lua 언어는 해본 적이 없네.
00:17:45Love 2D 프레임워크로 기본 틀만 빠르게 짜볼 수 있을까?” 할 때 정말 유용합니다.
00:17:48시행착오를 훨씬 줄이면서 진입장벽을 낮추고 바로 배움으로 이어질 수 있게 해주니까요.
00:17:55정말 멋진 일이죠.
00:17:56다만 그런 방식으로 배우려면 절제력이 필요합니다.
00:17:58슬롯머신에 동전을 넣듯 “게임 하나 만들어줘, 버그 없이”라고 요청하고 결과를 기다리고 싶은 유혹에 빠지기 쉽거든요.
00:18:06그런 식으로 안이해지는 유혹은 저도 좋아하지 않습니다.
00:18:08하지만 올바르게 활용하면서 때때로 직접 코드도 작성하고 기본을 놓치지 않는다면, 엄청나게 많은 일들을 해낼 수 있어요.
00:18:15예전에는 불가능했던 일들을 가능하게 만들어 주죠.
00:18:16예를 하나 들어보자면, Marimo라는 파이썬 노트북이 있는데요. 자바스크립트 진영에 익숙한 Observable 노트북과 매우 비슷합니다.
00:18:26거기서 “파이썬을 새로운 방식으로 제어할 수 있는 이런 특이한 위젯이 있으면 좋겠다” 싶을 때 바로 활용해 볼 수 있죠.
00:18:34아주 간단한 예로,
00:18:35저기 8-BitDo 컨트롤러 몇 개가 놓여 있잖아요.
00:18:39브라우저에는 게임패드 API 기능이 내장되어 있습니다.
00:18:42버튼을 누르면 파이썬에서 특정 동작이 실행되게 만들면 아주 근사하겠죠.
00:18:46브라우저 API와 위젯을 파이썬에 손쉽게 연결할 방법이 있다면 정말 좋겠다고 생각했어요.
00:18:50마침 AnyWidget이라는 규격이 있더군요.
00:18:52브라우저 문서에 파묻히지 않고도 프로토타입을 제작해서, 파이썬을 다루는 유용한 방식인지 빠르게 검증할 수 있었습니다.
00:18:59LLM을 활용해 파이썬 작업을 할 때, LLM이 제대로 답했는지 확인하기 위해 데이터를 검증해야 하는 경우가 있거든요.
00:19:06입력 텍스트가 있고 LLM이 출력한 라벨이 있으면, 사용자가 “O, X, O, X, 맞음, 틀림” 하고 확인해 주는 식이죠.
00:19:12이제 Marimo 노트북에서 게임 컨트롤러라는 아주 인체공학적인 장치로 그 작업을 할 수 있게 되었습니다.
00:19:18LLM 덕분에 이런 시스템을 만드는 과정이 굉장히 쉬워졌어요.
00:19:22물론 코드가 올바른지 직접 검토는 해야겠지만요.
00:19:24자바스크립트 고수가 아니더라도 첫 단추를 쉽게 꿸 수 있고, 그 과정에서 배움을 얻을 수도 있습니다.
00:19:33그건 분명 장점이죠.
00:19:34하지만 기술에 붙은 과도한 거품은 전혀 도움이 안 됩니다.
00:19:38그 부분이 정말 마음에 안 드는 점이에요.
00:19:40사실 새로운 현상도 아니긴 합니다.
00:19:41데이터 과학이나 머신러닝 때도 똑같이 겪었던 일이니까요.
00:19:43항상 반복되는 패턴이죠.
00:19:45다만 이번에는 과대광고가 유독 더 심하게 느껴질 뿐입니다.
00:19:48정확한 원인은 집어내기 어렵지만요.
00:19:51다시 말씀드리지만, 낙관할 수 있는 긍정적인 이유도 아주 많습니다.
00:19:54Marimo에서 LLM을 구동하게 만든 방식도 정말 근사하거든요.
00:19:56지도나 각종 데이터로 엄청 빠르게 다양한 실험을 해볼 수 있죠.
00:20:00하지만 강좌나 파는 사람이 너무 많다 보니, 팟캐스트 같은 데서 신뢰할 만한 정보 출처를 찾기가 어려운 게 현실입니다.
00:20:07진행자님도 마찬가지로 느끼시죠?
00:20:08LLM이 아닌 주제와 LLM 주제로 영상을 만들 때, AI 관련 수요가 워낙 많다 보니 일반적인 주제로 훌륭한 단독 영상을 만들기가 더 어려워졌음을 체감하실 겁니다.
00:20:19AI 영상 댓글에는 비판적이거나 거부감을 드러내는 의견이 더 많이 달리는 편인데, 정작 조회수는 훨씬 높게 나오더라고요.
00:20:29겉으로 표현은 안 해도 속으로는 다들 관심이 있다는 뜻이겠죠.
00:20:32겉으로 티를 안 낼 뿐이고요.
00:20:34결국 사람들은 끊임없이 AI의 새로운 트렌드만을 좇고 있는 것 같아요.
00:20:40그리고 끊기 힘든 굴레에 빠져들게 되죠.
00:20:45이와 관련된 엉뚱한 일화 하나 소개해 드릴게요.
00:20:481800년대 '다이너마이트 기구 사건'이라고 하면 뭔지 아시나요?
00:20:53아니요, 모릅니다.
00:20:54네.
00:20:55좀 뜬금없는 이야기 같지만 곧 본론으로 돌아올 겁니다.
00:20:591800년대 후반, 그러니까 나폴레옹 시대 무렵에도 과학이라는 개념은 존재했잖아요?
00:21:08실증주의가 유용하다는 건 알았지만, 날씨를 예측하는 건 불가능에 가까웠습니다.
00:21:14하지만 그에 대한 수요는 엄청났죠.
00:21:16날씨를 예측할 수만 있다면 가뭄이 언제 올지 알 수 있으니까요. 당시엔 식량 안보가 완벽하지 않았죠?
00:21:23그러니 날씨 예보에 대한 수요가 하늘을 찔렀던 겁니다.
00:21:27반면 공급은 Zero였어요. 예측법을 아는 사람이 없었으니까요. 그런데 수요만 폭발적일 때 나타나는 기이한 현상이 있죠. 바로 사기꾼들이 공급자로 등장한다는 겁니다.
00:21:37어디서나 벌어지는 필연적인 일이죠.
00:21:38게다가 날씨를 예측하는 것보다, 날씨를 조작할 수 있다고 믿게 만드는 편이 돈이 훨씬 되었거든요.
00:21:43그편이 사기치기 훨씬 좋았죠.
00:21:45당시에는 큰 전투가 끝나면 비가 내린다는 맹신이 널리 퍼져 있었습니다.
00:21:49나폴레옹도 그렇게 믿었고, 남북전쟁을 치른 장군들도 그렇게 믿었다는 기록이 남아있죠.
00:21:56그러자 G로 시작하는 이름의 한 인물이 나타나 미국 의회를 설득해 지원금을 받아냈습니다. 하늘에 다이너마이트를 실은 기구와 연을 띄워 폭발시키면 인공우를 내리게 할 수 있다면서요.
00:22:12이게 실제로 있었던 일입니다.
00:22:13지금 가치로 수백만 달러에 달하는 돈을 비를 내리겠다며 공중에 터뜨려 날려 버린 거죠.
00:22:19물론 시간이 지나면서 사기극임이 밝혀졌고, 사람들도 더는 속지 않게 되었습니다.
00:22:26이후 통신 기술이 발전하면서 기상 데이터를 공유할 수 있게 되었고, 그게 현대 기상 예보의 모태가 되었죠.
00:22:35그런데 “AI를 어떻게 바라봐야 하는가”에 대한 지금의 폭발적인 관심과 수요를 볼 때마다, 그때와 너무나 똑같다는 생각이 듭니다.
00:22:40아무도 명확히 답해주지 못하는 지식에 대한 수요가 크다 보니, 자칫하면 약장수들에게 속아 넘어가기 딱 좋은 환경이죠.
00:22:48이런 현상으로부터 자신을 지키는 가장 좋은 방법은 화려함 대신 '지루해 보이는 전문가'들을 찾는 겁니다.
00:22:53강의를 팔 생각 없이, 그저 담담하게 데이터와 인사이트를 공유하는 연구자들 말입니다.
00:23:00과거의 폭파 실험 사건에서 교훈을 얻는다면, 지금 우리에게 가장 필요한 태도가 바로 이런 게 아닐까 싶네요.
00:23:08기후 변화를 해결하려면 막대한 AI와 데이터 센터가 필요하다고들 말하는 상황이 떠오르네요.
00:23:17그 과정이 환경에 미칠 영향은 아무도 언급하지 않은 채, 결국엔 해결될 거라는 식으로요.
00:23:23사우스 파크에 나오는 속옷 요정 에피소드 같기도 해요.
00:23:271단계: 속옷을 모은다.
00:23:282단계: 뭔지 모름. 3단계: 돈을 번다.
00:23:31속옷을 훔치다 보면 어떻게든 억만장자가 될 거라는 막연한 논리처럼 말이죠.
00:23:35글쎄요.
00:23:36사람들을 의심하게 만드는 또 다른 사례는, 트위터 같은 데서 AI를 엄청나게 찬양하는 사람들을 볼 때예요.
00:23:43계정을 들어가서 이전 글을 몇 개만 내려보면, 결국 암호화폐나 NFT 이야기로 연결되더라고요.
00:23:47그저 트래픽이 몰리는 다음 유행으로 갈아탔을 뿐인 거죠.
00:23:51전혀 진정성이 느껴지지 않아요.
00:23:54하지만 그중에도 흥미로운 기록을 남기는, 말하자면 '좋은 의미로 진중한' 사람들도 있습니다.
00:24:00Simon Willison이 대표적인 예인데, 꽤 인지도도 높죠.
00:24:04그분은 언론인처럼 객관적 시각을 유지하려 하고, 오류가 있으면 솔직히 사과하는데 이게 마땅한 태도라고 봅니다.
00:24:11요즘 즐겨 듣는 팟캐스트 중에도 추천하고 싶은 게 있어요.
00:24:16Corey라는 분인데, 비디오 게임 프로그래머 출신이거든요.
00:24:20더보기란에 링크를 남겨둘게요.
00:24:22그분의 태도도 “나는 베테랑 C++ 개발자이고
00:24:25AI는 전혀 모르며, 딱히 배울 생각도 없다”는 식이에요.
00:24:28대신 교수인 친구를 초대해서 정기적으로 인터뷰를 진행하죠.
00:24:30특정 주제에 대해 대화를 나누는 식인데요.
00:24:33화려하진 않지만 내용이 알차서 유용한 참고가 될 겁니다.
00:24:38어쨌든 다들 비슷하게 체감하고 계시는 보편적인 현상일 텐데요.
00:24:44적어도 저나 Marimo 채널 입장에서는, AI와의 연동 방식을 다루는 콘텐츠를 제작해야 한다는 일종의 부채감이 들기도 합니다.
00:24:51그래서 실제로 다루고 있기도 하고요.
00:24:53하지만 AI 없이도 해낼 수 있는 멋진 작업들 역시 적극적으로 소개하려 애쓰고 있어요.
00:24:57인터랙티브 기능이나 흥미로운 데이터셋 탐구 같은 것들 말이죠.
00:25:00그런 거 분석해 보는 재미가 있거든요.
00:25:01얼마 전에는 레고 제품군 전체의 가격 데이터를 전부 수집해 봤습니다.
00:25:07“이제 아빠가 됐으니 레고 재테크 방법을 알아봐야겠어”라는 핑계로 말이죠.
00:25:11직접 데이터 분석까지 진행했어요.
00:25:13전체 제품 대시보드를 구축해서, 브릭당 단가가 가장 합리적인 제품이 무엇인지 찾아봤죠.
00:25:19이런 소소하고 유쾌한 작업들을 즐깁니다.
00:25:21레고랑 키보드 중에 어떤 취미가 돈이 더 많이 들까요?
00:25:25요즘 레고 가격이 만만치 않긴 하죠.
00:25:27재미있는 사실이 하나 있는데요.
00:25:31마블 라이선스 레고 세트를 사면, 레고사가 IP 사용료를 내야 하니까
00:25:39가격 대비 실제 브릭 개수는 적을 거라는 루머가 인터넷에 돌더라고요.
00:25:45분석해 보니 통계적으로 유의미한 차이는 없는 것으로 밝혀졌습니다.
00:25:49하지만 그런 것들은 직접 조사해 볼 수 있습니다.
00:25:52아까 새로운 형태의 주피터 노트북인 마리모(Marimo)를 언급하셨잖아요.
00:25:59자바스크립트 세계에는 완전히 똑같은 건 없지만, 웹사이트인 옵저버블(Observable)이 그에 해당한다고 하셨고요.
00:26:04옵저버블이 상당히 가깝다고 봅니다.
00:26:07네, 매우 비슷하고 유사한 역할을 하죠.
00:26:09하지만 그런 스타일로 코드를 읽고 쓰며 리서치하는 방식이 자바스크립트에서는 파이썬만큼 인기를 얻지 못했는데요.
00:26:18그 점에 대해 한 말씀 해주실 수 있나요?
00:26:19이유가 뭐라고 생각하시나요?
00:26:21제 생각에 자바스크립트 개발자들이 하는 일은 대부분 웹사이트 제작일 겁니다.
00:26:27100%는 아닌 게, 다른 분야 작업도 가능하니까요.
00:26:29하지만 대개는 웹사이트나 최소한 온라인 경험을 구축하는 일입니다.
00:26:34그 중에서도 대부분은 웹사이트 제작이죠.
00:26:37웹사이트를 만들 때는 원하는 바가 명확합니다.
00:26:39여기에 로그인 기능을 넣고, 이쪽에 버튼을 두는 식이죠.
00:26:42사용자 흐름도 필요하고요.
00:26:43보기 좋아야 하고 상호작용도 뛰어놀아야 합니다.
00:26:45기본적으로 그런 사고방식인 셈이죠.
00:26:48반면 파이썬 쪽의 사용 사례를 생각해보면 단순히 언어 자체의 차이가 아닙니다.
00:26:53미지의 데이터셋이 하나 주어졌는데,
00:26:55그 안에 뭐가 들었는지 전혀 모르는 상황인 거죠.
00:26:57그리고 이탈률이나 전력망 수요처럼 데이터셋이 다루는 무엇인가를 예측하고 싶어 합니다.
00:27:04그러려면 대화형 탐색에 매우 특화된 코딩 환경이 필요해집니다.
00:27:09그것을 위해 빠르게 수정하고 다른 차트를 확인할 수 있는 프론트엔드 형태가 필요하죠.
00:27:17동시에 그 많은 데이터를 실제 처리할 라이브러리도 필요합니다.
00:27:20자바스크립트는 늘 유연한 언어였지만,
00:27:23데이터 영역에서는 약간 부족했고, 할 수 있는 것이 제한적이었습니다.
00:27:27기가바이트 단위 데이터로 머신러닝을 하려면 격차가 존재했죠.
00:27:33파이썬이 그 격차를 훌륭히 채워줍니다.
00:27:35아직 데이터셋을 훑어보지도 않아서 뭘 해야 할지 모를 때, 실험해 볼 대화형 환경이 필요합니다.
00:27:44그렇군요.
00:27:45바로 그 지점에서 노트북이 진가를 발휘합니다.
00:27:46IDE도 훌륭하긴 하지만,
00:27:49어디서 차트를 시각화할 수 있을까요?
00:27:51거의 불가능에 가깝죠.
00:27:53사실 데이터셋이나 데이터프레임 같은 객체를 가져와서 빠른 그룹화 연산 등을 수행하고,
00:28:01원하는 차트를 즉시 그려낼 수 있는 능력, 그것이 노트북의 시작이었습니다.
00:28:05그 모든 차트를 대화형으로 자유롭게 만드는 공간이죠.
00:28:09LLM 시대가 되고 사람들이 미래를 예측하려 하지만,
00:28:14적어도 당분간은 데이터 작업에 파이썬이 쓰이지 않는 미래는 상상하기 어렵습니다.
00:28:18전혀 그려지지 않네요.
00:28:20파이썬이 정확히 그 지점을 채워준 겁니다.
00:28:23리차드의 질문에 덧붙이자면, 수많은 저급 언어들을 두고 왜 파이썬이 머신러닝의 표준 언어가 되었는지 늘 궁금했습니다.
00:28:35C++이나 러스트 같은 언어가 아니라 왜 파이썬이었을까요?
00:28:39그것도 같은 이유와 연결됩니다.
00:28:40차트를 하나 만든다고 해봅시다.
00:28:42코드를 컴파일하고 차트가 나올 때까지 기다리고 싶으신가요?
00:28:46아니면 대화형으로 바로 보길 원하시나요?
00:28:48대화형 작업을 가능하게 하는 언어라면 동적 언어 REPL이어야만 합니다.
00:28:55여기서 컴파일 언어는 전부 제외되죠.
00:28:58대신 파이썬에서 자주 쓰는 편법이 있습니다.
00:29:01파이썬은 C언어 바인딩이 훌륭하거든요.
00:29:03무거운 수치 연산 라이브러리 중 폴라스(Polars)라는 데이터프레임 라이브러리가 있습니다.
00:29:07이건 전부 러스트로 작성되었죠.
00:29:09파이썬은 실제 런타임이라기보다는 UI 역할에 가깝습니다.
00:29:12행렬 연산을 다루는 넘파이(NumPy)도 있습니다.
00:29:15그건 BLAS나 C 같은 저급 언어로 작성되어 있죠.
00:29:18그저 파이썬 바인딩이 연결되어 있을 뿐입니다.
00:29:20핵심은 데이터를 어떻게 가공할지 쉽게 작성하고 자유롭게 테스트해 보는 것입니다.
00:29:28다른 형태의 차트로 바꿔보고 싶을 수도 있으니까요.
00:29:30이 모든 게 극도로 상호작용적이어야 합니다.
00:29:31중간에 컴파일러가 끼어든다고 생각해 보세요.
00:29:34개발 경험이 결코 매끄럽지 않을 겁니다.
00:29:35그래서 지금의 자리에 오게 된 것이라 봅니다.
00:29:38파이썬은 필요할 때 저급 언어로 바인딩을 만드는 능력이 탁월합니다.
00:29:43그러면서도 개발자 경험은 대화형으로 유지해주죠.
00:29:46맞아요, 저도 간단한 스크립트 작성용으로 가장 먼저 배운 언어가 파이썬이었어요. 접근성이 아주 좋았거든요.
00:29:53Mac에서 뭐든 다 처리해 주는 느낌이었죠.
00:29:54말씀대로 데이터 다룰 때도요.
00:29:56스크립트 하나만 짜면 알아서 처리됐죠.
00:29:58다른 언어만큼 엄격하지도 않은 것 같았고요.
00:30:01이미 다른 언어를 아는 상태에서 파이썬으로 넘어가는 건 아주 쉬웠습니다.
00:30:05맞습니다. 파이썬은 한 사람의 머릿속에 쉽게 들어오는 언어라는 평가가 적절해 보입니다.
00:30:11주말 동안 습득한 지식들이 그다음 주말에도 머릿속에 고스란히 남아있죠.
00:30:17러스트의 장점도 충분히 인정합니다만,
00:30:20제대로 된 문장 하나를 쓰기 위해 숙지해야 할 문법이 너무나 방대합니다.
00:30:28그만한 이유가 있긴 하지만, 파이썬 프레임워크들은 저마다 조금씩 다르게 동작하더라도
00:30:35언어 자체는 꽤 미니멀하면서 동시에 극도로 유연합니다.
00:30:39그렇죠.
00:30:41노트북 이야기로 돌아가자면, 몇 년 전 NLP 언어를 다룰 때 경험이 떠오르네요.
00:30:47이전 직장에서 전체 공정에 노트북만 사용했던 적이 있습니다.
00:30:51오디오 파일을 넘겨주면 백그라운드에서 실행되어 텍스트로 추출해 주는 형태였죠.
00:31:00네.
00:31:01한 셀에 입력을 넣으면 다음 셀로 넘어가는 구조였겠네요.
00:31:05파형으로 변환된 뒤 텍스트로 변환되는 식이죠.
00:31:07Shift+Enter를 계속 누르면서 넘어가면
00:31:10노트북 끝에서 결과물을 얻게 되는 거죠.
00:31:12그 점이 참 마음에 듭니다.
00:31:13맞아요.
00:31:13전체 과정이 다 보이죠.
00:31:14노트북으로는 원하는 거의 모든 걸 할 수 있습니다.
00:31:17라이브러리를 다운로드하는 등 여러 작업이 가능하죠.
00:31:18노트북으로 해본 가장 특이한 작업은 어떤 거였나요?
00:31:23제가 즐겨 하는 일이 있는데, 독특하긴 하지만 브라우저가 제공하는 기능을 적극 활용하는 편입니다.
00:31:34파이썬에는 없는 GPU 렌더링 트릭 같은 것들이 브라우저에는 있거든요.
00:31:37파이썬의 우수한 수학 라이브러리로 연립방정식을 정의한 뒤,
00:31:43실제 렌더링은 브라우저의 GPU에서 처리하도록 구성하는 겁니다.
00:31:47그런 식의 연동이 가능하죠.
00:31:48가장 엉뚱했던 작업을 꼽아보자면,
00:31:51좋습니다.
00:31:52제가 '미분방정식'이라고 하면 다들 재채기 소리로 듣나요, 아니면 뭔지 알고 계신가요?
00:31:58확인차 물어봅니다.
00:31:59솔직히 저는 전혀 모르겠습니다.
00:32:01알겠습니다.
00:32:01물리학 분야에서는 대상의 상태를 직접 설명하긴 어렵지만, 그것이 어떻게 변화하는지 설명하긴 쉬운 경우가 있습니다.
00:32:13물리학 특유의 현상이죠.
00:32:14변화 양상을 수학적으로 묘사하는 편이 훨씬 수월할 때가 있습니다.
00:32:18그것을 미분방정식이라고 부릅니다.
00:32:20속도나 가속도는 알고 있지만, 6단계 뒤의 상태를 예측하고 싶을 때
00:32:28어떻게 접근해야 할까요?
00:32:30거기에 쓰이는 것이 미분방정식입니다.
00:32:31대학 수업을 듣긴 했지만, 쓸 일이 없어 미분방정식을 완벽히 이해하진 못했었습니다.
00:32:37그러다 비디오 게임과 관련된 '란체스터 법칙'이라는 미분방정식을 알게 되었죠.
00:32:42'에이지 오브 엠파이어'에서 두 군대가 격돌해 전면전을 벌이는 상황을 상상해 보세요.
00:32:48레드팀과 블루팀 병력들이 한데 엉켜 싸우는 겁니다.
00:32:53어느 군대가 이기고 병력이 얼마나 남을지 예측할 수 있을까요?
00:32:56승리한 대규모 군대의 생존자는 몇 명일까요?
00:33:00네.
00:33:00이때 쓰이는 란체스터 법칙이라는 미분방정식은, 아군 손실이 상대 군대의 규모에 비례한다는 개념입니다.
00:33:10나를 겨누고 있는 칼날의 수와 같으니까요.
00:33:13이런 식을 세워 푸는 과정을 란체스터 방정식이라고 합니다.
00:33:18흥미롭다고 생각하긴 했지만,
00:33:20수식과 기호만 봐서는 잘와닿지 않았죠.
00:33:24하지만 자바스크립트로 충돌 감지 기능이 포함된 전투 시뮬레이터를 직접 구현할 수 있었습니다.
00:33:30그걸 파이썬 노트북 안의 위젯으로 띄워 시뮬레이션을 돌린 뒤 데이터 파일로 기록했죠.
00:33:38그리고 파이썬으로 란체스터 법칙이 실제로 성립하는지 검증했습니다.
00:33:43결과는 들어맞았고요.
00:33:44제가 마침내 미분방정식을 이해하게 된 장황한 배경 이야기입니다.
00:33:48란체스터 법칙을 직접 시뮬레이션해 보면서 깨달은 거죠.
00:33:50파이썬 위젯을 활용해서요.
00:33:52이 과정의 상당 부분이 프론트엔드에서 처리되는데, 충돌 감지가 일어나는 모습을 시각적으로 보여주어 훌륭한 대화형 경험을 만들어주기 때문입니다.
00:34:03그리고 연산과 차트 작성 단계에서 다시 파이썬으로 돌아오는 구조입니다.
00:34:07제가 노트북으로 시도해 본 관습을 벗어난 작업 중 가장 공들인 사례입니다.
00:34:12미분방정식을 이해하려고 전투 시뮬레이터를 만드는 사람은 흔지 않으니까요.
00:34:18학교에서 미분방정식을 가르칠 때도 아주 유용한 방식이 될 것 같네요.
00:34:23다음 단계는 당연히 '에이지 오브 엠파이어' 게임으로 시도해 보는 거겠죠.
00:34:26그것도 정말 재미있겠네요.
00:34:27스타크래프트나 요즘 친구들이 하는 최신 게임으로 해도 좋고요.
00:34:32노트북의 가장 큰 장점은 무언가를 이해하고자 할 때 극도로 맞춤화된 경험을 제공한다는 점입니다.
00:34:39특히 최근에는 LLM 연동도 아주 잘 되어 있으니까요.
00:34:42LLM이 파일 작성은 잘하지만, 디버깅할 때 파일을 실행하고 터미널 출력을 확인하는 유기적 과정에는 헛도는 작업이 많습니다.
00:34:53그 상황에서는 번거로운 반복 루프가 발생하죠.
00:34:56저희는 LLM이 접근할 수 있는 가상의 메모장 파일 방식을 고안했습니다.
00:35:02LLM은 일반 파일처럼 그 메모장에 내용을 기록할 수 있습니다.
00:35:06이 파일은 파이썬 컨텍스트 매니저를 통해 노트북의 모든 변수에 접근 가능하도록 설계되었습니다.
00:35:12따라서 클로드(Claude)는 모든 것을 출력할 필요 없이 메모리에 있는 변수를 즉시 들여다볼 수 있습니다.
00:35:20LLM과 노트북을 결합하면 상상력을 마음껏 발휘해 다방면으로 확장할 수 있습니다.
00:35:29가능성이 무궁무진한 기분이 들죠.
00:35:32다만 노트북 내에서 LLM을 쓸 때는 한 번에 1~2개 셀 정도만 생성하도록 유도하는 편입니다.
00:35:38전체 노트북을 한 번에 다 만들어달라고는 절대 하지 않는데, 작업 흐름을 직접 파악하고 싶기 때문입니다.
00:35:43진행 상황을 이해하고 중간에 방향을 수정하거나 조정하려는 목적이죠.
00:35:46때로는 스스로 함수를 직접 구현하며 제대로 이해했는지 확인하고 싶기도 하고요.
00:35:53노트북 내부의 동작 과정을 직접 눈으로 확인하는 환경은 분명 매력적입니다.
00:35:56매우 인터랙티브한 경험을 만들어낼 수 있죠.
00:35:58그리고 그런 방식 덕분에 디버깅하는 것도 참 즐거워지는데, 예전에 추천 엔진 같은 수치 시스템을 몇 개 다뤄봤을 때도 항상 그랬거든요.
00:36:09차트는 필수적이었습니다.
00:36:10대안이 없을 정도죠.
00:36:12REPL 환경에서는 그런 시각화를 얻을 수 없습니다.
00:36:13반드시 노트북 같은 환경이 필요하죠.
00:36:15네.
00:36:15추천 엔진을 직접 만들어본 적은 없어서 완벽히 공감하긴 어렵지만,
00:36:20이런 작업에서 차트가 주는 시각적 효과가 얼마나 큰지는 이해할 수 있습니다.
00:36:26차트 없이 추천 시스템을 디버깅하는 건 매우 까다롭습니다.
00:36:30주말 사이에 오류가 발생했다면,
00:36:34정확히 언제 문제가 시작됐는지 찾아내야 하니까요.
00:36:36그럴 때 과정을 시각화해 줄 차트가 간절해집니다.
00:36:39대시보드에 일부 지표를 띄워둘 수도 있겠지만,
00:36:41어떤 차트가 필요할지 사전에 알 수 없는 상황에서는 유연한 환경이 필수적입니다.
00:36:47바로 이 지점에서 파이썬 노트북의 장점이 빛을 발합니다.
00:36:51추천 엔진 디버깅을 하던 단계에서 마리모의 그로스 팀에 합류하고 지금처럼 마이크와 카메라 세팅을 갖추기까지 어떤 과정이 있었나요?
00:37:00좋은 질문입니다.
00:37:00몇 가지 독특한 계기들이 있었는데요.
00:37:02암스테르담의 컨설팅 회사에서 일하면서 'PyData Amsterdam'이라는 인지도 높은 컨퍼런스를 시작했습니다.
00:37:10바로 PyData 암스테르담이죠.
00:37:1110년이 지난 지금까지도 잘 운영되고 있습니다.
00:37:12시작을 꽤 잘 끊은 셈이죠.
00:37:14저 혼자 만든 건 아니었고,
00:37:16여러 동료들과 함께 만들어낸 성과입니다.
00:37:18그러면서 무대에 서는 일에도 점차 익숙해졌습니다.
00:37:21대학 시절에는 네덜란드의 유명 코미디 바에서 바텐더로 일한 적도 있었거든요.
00:37:29여름에 극장이 쉬는 기간에는 암스테르담에서 가이드 투어를 진행했습니다.
00:37:33코미디언들의 농담을 빌려와 화요일마다 2시간 간격으로 새로 찾아오는 관광객들에게 던져보곤 했죠.
00:37:40자연스럽게 대중 앞에 서는 편안함을 배우게 되었습니다.
00:37:42행사 기획뿐만 아니라 여러 PyData 행사의 발표자로도 자주 나섰죠.
00:37:46발표 신청이 채택되는 것도 어렵지 않았습니다.
00:37:48꿀팁을 드리자면, 컨퍼런스 발표 채택률을 높이려면 심사 위원으로 일정 기간 활동해 보는 것이 좋습니다.
00:37:54제출된 발표 제안서가 어떤 기준으로 평가되는지 파악할 수 있거든요.
00:37:59무대가 익숙해진 덕에 다양한 행사들을 찾아다녔습니다.
00:38:02그러다 'Spacey in Real Life'라는 행사에 참석하게 되었죠.
00:38:05스파시(spaCy)나 익스플로전(Explosion)을 들어보셨는지 모르겠지만, 파이썬 초기의 대표적인 NLP 패키지 중 하나입니다.
00:38:13현장을 둘러보던 중 스파시 창업자들이 다가왔습니다.
00:38:16“뱅상, 워크숍 데모 발표를 인상 깊게 봤습니다.”
00:38:19“유튜브 콘텐츠 제작을 아주 잘하실 것 같네요.”
00:38:21흥미로운 제안이었죠. 영상 제작 경험은 없었지만 NLP를 배워보고 싶던 참이었습니다.
00:38:27그래서 제가 배움을 얻는 대신 제안을 하나 건넸습니다.
00:38:32“작업물의 정확성을 검증해 주신다면 기꺼이 영상 제작을 맡겠습니다.”
00:38:37그렇게 협업이 시작되었죠.
00:38:40그들의 유튜브 채널에서 제작한 영상들은 기대 이상의 큰 호응을 얻었습니다.
00:38:47그걸 보고 챗봇 스타트업인 라자(Rasa)에서 스파시 영상이 인상적이었다며 먼저 연락을 주었습니다.
00:38:56규모가 큰 연구팀을 보유하고 있었기에 연구진 대상 데브렐(Developer Advocate) 역할을 맡아줄 사람이 필요했던 거죠.
00:39:02당시 라자 사용자 다수가 내부 알고리즘을 제대로 이해하지 못하고 있던 상황이었습니다.
00:39:07그래서 알고리즘 작업도 하면서 이를 잘 설명할 사람도 필요했던 거죠.
00:39:12그래서 한동안 그 일을 했습니다.
00:39:13그러다 SpaCy를 만드는 Explosion 팀으로 돌아갔어요.
00:39:16그쪽도 디벨로퍼 어드보킷이 필요해서 거기서 일했죠.
00:39:18거기서 Probable이라는 그룹으로 옮겼습니다.
00:39:22scikit-learn 팀 같은 곳이었는데요.
00:39:23그곳도 DevRel 담당자를 두고 싶어 했습니다.
00:39:26거기서 팟캐스트를 진행했는데, Marimo의 창립자인 Akshay를 게스트로 모셨어요. 지금 제 상사죠.
00:39:33알고 보니 그 친구와 제가 같은 중학교를 나왔더라고요.
00:39:36팟캐스트 시작 전에 스몰 토크를 하다가, 10살에서 12살 때쯤 같은 수학 선생님께 배웠다는 걸 알게 됐습니다.
00:39:44그래서 금방 친해졌고, 나중에 그 팀이 투자를 받게 되면서 생각했죠. '이 노트북 진짜 물건이네.'
00:39:48'내가 예상치 못한 부분들까지 제대로 잡아주네' 하고요.
00:39:50이야기가 좀 길어졌지만, 그렇게 지금 이 위치까지 오게 됐습니다.
00:39:53그래서 훨씬 전부터 컨설턴트로 일하긴 했지만, 사이드 활동이나 서브 퀘스트를 하다 보면, 그걸 충분히 하는 것만으로도 메인 퀘스트가 업데이트될 수 있다는 걸 깨닫게 되죠.
00:40:03사람들의 이야기를 듣는 건 늘 흥미로워요. 테크 유튜브 영상을 만드는 게 흔한 직업은 아니니까요.
00:40:10따로 전공이 있는 것도 아니고, 대학에서 가르쳐주는 것도 아니잖아요.
00:40:14그래서 이 일에 어떻게 입문했는지, 카메라 앞에서 어떻게 자연스러워졌는지, 대본은 어떻게 쓰는지—대본을 쓰시는지는 모르겠지만—장비는 어떻게 갖췄는지 스토리를 듣는 게 재미있네요.
00:40:23저는 대본을 절대 안 씁니다.
00:40:24대본을 안 쓰신다고요?
00:40:25네.
00:40:25어떻게 그게 가능한지 궁금하네요.
00:40:27유튜브 영상을 만들긴 하지만, 그게 제 일의 전부가 아니거든요.
00:40:32그리고 예전에 Calm Code라는 걸 진행하면서 영상을 정말 많이 만들었는데, 그 영상들에는 제 얼굴이 전혀 안 나옵니다.
00:40:41그렇게 하니 편집이 훨씬 쉬워지더라고요.
00:40:43말을 실수해도 제 얼굴 화면을 맞출 필요가 없으니까요.
00:40:46오디오랑 비디오를 컷 편집해서 금방 끝낼 수 있었죠.
00:40:50그래서 Marimo 영상을 만들 때 가장 신경 쓰는 건 전달할 핵심 이야기나 명확한 설명, 즉 설명할 가치가 있는 내용이 있는가 하는 점입니다.
00:40:57자리에 앉아서 '도입부는 어떻게 하고 흐름은 어떻게 가져갈까?' 하고 대략적인 구상을 하긴 합니다.
00:41:04하지만 제가 무언가를 제대로 배운 좋은 순간들을 돌이켜보면, 보통 술집에서 친구와 있을 때였어요. 맥주 잔을 어디다 놓죠?
00:41:14맥주 받침대였나요?
00:41:14영어로는 코스터(coaster)라고 하죠?
00:41:16코스터를 뒤집어서 아주 좁은 공간에 핵심 개념만 쓱쓱 그림으로 그려 설명해주곤 했죠.
00:41:22보통 그거면 충분하고, 실제 사람들이 원하는 것도 바로 그런 겁니다.
00:41:245분짜리 영상을 본다고 Marimo 전문가가 되는 건 아니지만, 딱 하나의 핵심 개념을 명확히 이해시켜서 '이 조건에서 나한테 필요하겠구나'를 알게 해주고, 시간을 낭비하지 않는 알찬 5분짜리 설명을 제공하는 거죠.
00:41:39그걸 잘 전달하려면 너무 깊게 고민하지 않는 게 답입니다.
00:41:43잘 준비된 노트북을 열고 녹화 버튼을 눌러 내용을 설명한 뒤, 추임새나 쓸데없는 부분만 잘라내면 끝입니다.
00:41:52그러면 작업이 끝나는 거죠.
00:41:53저는 이게 아주 좋은 접근법이라고 생각합니다.
00:41:57어느 정도 타당한 말씀이네요.
00:41:59'노트북을 준비해두고 화면에 떠 있는 걸 읽기만 한다'고 말할 수도 있겠지만요.
00:42:03하지만 정면 카메라를 빤히 보면서 프롬프터만 읽는 건 너무 인위적이라고 생각해요.
00:42:09물론 공식 발표 같은 걸 할 때는 회사 차원에서 정확한 단어를 쓰는 게 중요하니까 프롬프터를 쓸 수도 있죠.
00:42:18하지만 화면에 띄워진 대본을 그대로 읽는 건 너무 정없이 느껴집니다. 물론 그 방식이 아주 잘 들어맞는 영상들도 몇몇 있긴 하지만요.
00:42:293Blue1Brown 같은 채널처럼요.
00:42:30그분은 애니메이션을 활용해서 대단한 수학 설명 영상들을 만들잖아요.
00:42:34분명 대본 작업을 꼼꼼히 할 테고, 그 종류의 콘텐츠에는 그 방식이 최선일 겁니다.
00:42:38계속 그렇게 하셔야죠.
00:42:39정말 훌륭하니까요.
00:42:40하지만 저는 설명이 잘 담긴 영상 2편을 일주일에 올리는 게 목표이고, 너무 부담을 갖지 않음으로써 혼자서도 주 2회 업로드를 유지하고 조회수도 좋게 나오는 것 같아요.
00:42:51그러니 굳이 무리해서 과하게 제작할 이유가 없는 거죠.
00:42:55그리고 어떤 분들은 영상 특유의 엉뚱함이나 소박함을 좋아한다고 말씀해주시더라고요.
00:42:59조회수를 최대한 쥐어짜 내려는 게 아니라,
00:43:01그저 이 한 가지 개념을 설명하려는 것뿐이니까요.
00:43:02본인에게 필요 없는 내용이라 시작 10초 만에 나간다고 해도 저는 전혀 상관없습니다.
00:43:07관심을 가지고 들어주는 분들에게 이 영상이 정말 유익하기만 하면 되니까요.
00:43:12진심으로요.
00:43:12게다가 저희 채널 누적 조회수가 거의 200만 회에 다다르고 있어요.
00:43:16조만간 소소하게 기념할 만한 마일스톤을 달성하게 됩니다.
00:43:19물론 결과를 기쁜 마음으로 지켜보고 자랑도 할 겁니다.
00:43:22수치가 올라가는 건 좋은 거니까요.
00:43:25하지만 꼭 연연해하지는 않아요.
00:43:26결국 제가 가장 중요하게 생각하는 건 유튜브 채널 덕분에 더 많은 사람이 Marimo를 한번 써보게 되는 것이고,
00:43:31저희가 만드는 프로젝트들을 알게 되는 거니까요.
00:43:34목표는 사람들이 Marimo를 사용하는 것이지, 유튜브 조회수를 올리는 게 아닙니다.
00:43:38더 큰 그림에 비하면 조회수는 훨씬 부차적인 문제죠.
00:43:44맞는 말씀입니다.
00:43:45그렇다면 어떤 주제로 영상을 만들지 어떻게 결정하시나요?
00:43:48Marimo를 둘러보다가 '아, 이 기능은 영상으로 다루기 어렵겠는데' 하고 파악하시나요?
00:43:54아니면 레딧을 둘러보며 사람들이 뭘 어려워하는지 보시나요?
00:43:56주제 선정을 어떻게 하시는지 궁금해요.
00:43:59마침 재미있는 이야기를 꺼내셨네요.
00:43:59오늘 아침 레딧에 '무엇이든 물어보세요'가 아니라 '무엇이든 알려주세요'라는 글을 올렸거든요.
00:44:03'제 이름은 뱅상입니다.'
00:44:04'Marimo 영상을 만들고 있어요.'
00:44:05'어떤 주제로 영상을 만들까요?' 하고요.
00:44:06그럼 흥미로운 제안들이 많이 들어옵니다.
00:44:08그것도 하나의 방법이죠.
00:44:10Marimo를 처음 시작했을 때 저희 생각은 'Jupyter와 구분되는 Marimo만의 핵심 개념 몇 가지가 있다'는 것이었습니다.
00:44:17Jupyter는 이미 사람들이 잘 알고 있는 도구이고,
00:44:19Marimo는 조금 다르니까요.
00:44:20네.
00:44:20그러니 그 차이점을 아주 명확하게 설명해야겠다고 생각했죠.
00:44:22그 차이점이 장애물이 되거나 사람들이 헤매는 지점이 될 수 있으니까요.
00:44:25그래서 생각했죠.
00:44:25'이런 특이한 엣지 케이스들에 대해 최소한 영상 하나씩은 만들어두자.'
00:44:29'누군가 검색했을 때 바로 찾아볼 수 있도록 말이죠.'
00:44:33그 작업을 마무리하고 나서,
00:44:34'다음은 뭘까?' 고민했죠.
00:44:35다양한 사용자 커뮤니티가 있잖아요.
00:44:37예를 들어 Airflow를 즐겨 사용하는 그룹이 있고,
00:44:39이건 파이썬 스케줄러 중 하나죠.
00:44:41Prefect라는 다른 스케줄러를 쓰는 그룹도 있고요.
00:44:43Flask나 Django 같은 웹 프레임워크 사용자도 있죠.
00:44:46그 사람들의 니즈는 저마다 다를 겁니다.
00:44:47그래서 특정 그룹에게 '이 팁 진짜 유용하겠다' 싶을 만한 데모 영상을 만들 수 있었죠.
00:44:53아니면 '이 스크립트를 쓰면 Marimo를 훨씬 유용하게 쓸 수 있습니다' 같은 내용을 다루는 겁니다.
00:44:57Django에는 흥미로운 ORM 기능이 있는데,
00:44:59이를 Marimo와 깔끔하게 연결하려면 간단한 스크립트 팁을 하나 활용해야 하거든요.
00:45:02한 번 적용해두면 작업이 정말 쉬워집니다.
00:45:05그게 두 번째 단계였습니다.
00:45:07기본적인 준비 작업을 마친 지금 단계에서는, '이 주제가 나를 흥분시키는가?'에 좀 더 집중하고 있습니다.
00:45:13마케팅이란 결국 열정을 주고받는 것이니까요.
00:45:17제가 어떤 주제에 큰 열정을 느낀다면, 그 흥분 때문에라도 반드시 영상을 만들어야 합니다.
00:45:21그러면 다른 사람들도 열정을 느끼게 될 테니까요.
00:45:23그중 일부는 '아주 멋진 LLM 활용 팁이 있으니 꼭 영상으로 만들어야지' 같은 경우도 있지만,
00:45:29제가 정말 좋아하는 건 '이 새로운 위젯 덕분에 문제를 완전히 다른 방식으로 접근할 수 있네' 하는 종류입니다.
00:45:35예를 들면 란체스터 법칙에 관한 영상이 그랬죠.
00:45:37정말 즐겁게 만들었던 영상이었습니다.
00:45:39물론 세상의 흐름에 따라 반드시 다뤄야 하는 영상들도 있죠.
00:45:43시의성이 조금 있는 주제들요.
00:45:44저희를 인수한 회사는 CoreWeave라는 곳입니다.
00:45:50엄청나게 큰 GPU 공급업체죠.
00:45:52OpenAI가 이들의 고객사 중 하나입니다.
00:45:54이해를 돕자면 GPU를 대여해주는 회사인 거죠.
00:45:56최근 벤치마크 결과를 발표했는데, 자신들이 Kimi K2.6을 가장 빠르게 제공하는 공급업체임을 보여줬어요.
00:46:02그렇군요.
00:46:03네.
00:46:03그건 직접 들여다볼 가치가 있다고 생각했죠.
00:46:05'와, 진짜 빠르네' 싶었거든요.
00:46:06그렇죠.
00:46:07정말 속도가 빠른 LLM이니까, 이걸 Marimo에 어떻게 연동할 수 있는지에 대한 영상을 하나 만들 생각입니다.
00:46:12좋네요.
00:46:12일리가 있습니다.
00:46:13그럼요.
00:46:13여전히 제 스스로가 열정을 느끼고 있고요.
00:46:15적어도 지금까지는 그 점을 가장 최우선으로 지향하려고 합니다.
00:46:19정말 멋진 태도네요.
00:46:20그 마음을 나누시는 거잖아요.
00:46:21열정은 대본으로 짜낼 수 있는 게 아니니까요.
00:46:22절대로 인위적으로 연출할 수 없죠.
00:46:23열정은 대본대로 안 되죠.
00:46:25당연히 그렇죠.
00:46:26그런 진심이 영상 너머로 잘 전달되는 게 참 좋습니다.
00:46:30아까 CoreWeave가 Marimo를 인수했다고 말씀하셨는데요.
00:46:34인수 이후 달라진 점이 있나요?
00:46:36CoreWeave 전용 유튜브 채널을 새로 만드시나요?
00:46:38일상 업무에는 어떤 변화가 있었는지 궁금합니다.
00:46:40CoreWeave 채널은 이미 따로 있습니다.
00:46:42조직도를 설명해 드리자면, 이미 아는 분도 계실 텐데요.
00:46:44Weights & Biases라는 회사가 있습니다.
00:46:47머신러닝에 관심이 있으시다면 들어보셨을 겁니다.
00:46:49모르셔도 상관은 없고요.
00:46:50저희를 인수하기 약 5개월 전에 CoreWeave가 Weights & Biases를 먼저 인수했어요.
00:46:55그래서 조직도를 보면 최상위에 CoreWeave, 그 아래 Weights & Biases, 그리고 그 아래에 저희가 있는 구조죠.
00:47:00어떻게 보면 전체 회사에서 소프트웨어 부문을 담당하는 격이라 볼 수 있습니다.
00:47:03거대한 서버 팜을 관리하는 일과는
00:47:08완전히 다른 분야인 셈이죠.
00:47:10어느 정도 말을 돌려 표현하자면, 제가 느낀 바로는 CoreWeave 분들이 저희의 성장을 진심으로 응원해주고 있다는 겁니다.
00:47:18저희가 주당 5%씩 성장하며 10배 성장을 이뤄냈는데,
00:47:21그 점을 아주 맘에 들어 하더라고요.
00:47:22저희가 일을 잘해나가고 있다는 사실도 잘 알고 있고요.
00:47:25그래서 '협업하고 싶은 게 있다면 언제든 편하게 말하라'고 해줍니다.
00:47:29필요하다면 유튜브 콜라보 영상도 흔쾌히 함께 찍어주겠다고 하면서요.
00:47:33정말 좋습니다.
00:47:34하지만 지금까지 '반드시 협업해야 한다' 같은 위로부터의 지시나 강요는 전혀 없었습니다.
00:47:41굳이 차이점을 꼽자면 슬랙 채널 규모가 훨씬 커졌다는 거죠. 전에는 9명뿐이었는데
00:47:46지금은 거의 1,000명에 육박하거든요.
00:47:48'이 스레드는 패스, 저 채널도 패스' 하면서 정리해야 하는 지경이죠.
00:47:53그런 신경을 써야 하는 것 말고는 별반 다를 게 없습니다.
00:47:55진짜 그래요.
00:47:56저희의 성장을 눈으로 보고 있고, 이대로 계속 잘 해주기만을 바라고 있으니까요.
00:48:00최근에 저희가 새로 시작한 일이 하나 있긴 합니다.
00:48:02구글에 Colab이라는 서비스가 있잖아요.
00:48:04GPU를 제공하는 구글의 Jupyter Notebook 같은 건데요.
00:48:07이번 월요일에 Molab 환경에서 CoreWeave Marimo Notebook을 출시했습니다.
00:48:11이제 거기서 노트북을 생성하면 엄청나게 고성능인 Blackwell GPU를 무료로 쓸 수 있죠.
00:48:18아주 흥미로운 실험인데요, 이런 제품을 출시하고 나면 다음 일주일 내내 부정 이용이나 악용 방지에만 매달려야 하거든요.
00:48:26그 고성능 GPU를 탐내는 사람들이 정말 많으니까요.
00:48:28덕분에 이번 주 저희 슬랙 채널이 아주 시끌벅적했습니다.
00:48:31하지만 이건 인수가 없었다면 시도조차 못 했을, 인수 덕분에 가능해진 첫 번째 작업입니다.
00:48:38이전에는 없던 막강한 리소스에 접근할 수 있게 되었으니까요.
00:48:42질문하려던 내용에서 약간 벗어난 이야기일 수도 있는데요.
00:48:46최근 공급망 공격 사례가 정말 많이 발생하고 있잖아요.
00:48:50PyPI를 비롯해 파이썬 생태계에도 타격이 꽤 컸던 걸로 압니다.
00:48:54이런 보안 공격을 받지 않기 위한 조언이 있으신가요?
00:48:57저도 PyPI를 사용해보긴 했는데요.
00:48:58솔직히 말씀드리면 저는 npm이나 최소 릴리스 연령 같은 설정에 대해서는 훨씬 더 잘 알고 있거든요.
00:49:03파이썬에서는 그걸 어떻게 설정하나요?
00:49:04아니면 전혀 다른 방식을...
00:49:06비슷한 도구들이 존재합니다.
00:49:07예를 들어서...
00:49:10자바스크립트 생태계에서는 npm 명령어를 사용하는 작업이 많다면,
00:49:14요즘 파이썬 환경에서는 uv 명령어를 사용하죠.
00:49:16예전에는 pip을 주로 사용했었는데요.
00:49:20Rust를 아주 잘 다루는 개발자 집단이 파이썬용으로 훨씬 빠른 도구를 만들어낸 거죠.
00:49:25그게 바로 uv입니다.
00:49:27역할은 거의 비슷합니다.
00:49:28가장 좋은 방법은 접촉면을 최소한으로 줄이는 것입니다.
00:49:32잘 알고 있고 신뢰할 수 있는 프로젝트의 의존성만 사용하는 거죠.
00:49:35요즘처럼 누구든 AI 바이브 코딩으로 파이썬 패키지를 뚝딱 만들어내는 시대에는 더욱 그렇습니다.
00:49:39외부 의존성 범위를 최대한 작게 유지하세요.
00:49:42검증되고 안정적인 패키지 위주로 사용하는 게 좋습니다.
00:49:45그리고 가능하다면 정말 중요한 오픈소스 패키지에는 후원을 해주는 문화가 자리 잡으면 좋겠네요.
00:49:49몇몇 핵심 웹 프레임워크들을 예로 들어보면요.
00:49:52Starlette을 유지 보수하는 인원이 단 3명이라고 해봅시다.
00:49:56Starlette 기반 위에 FastAPI가 올라가 있고,
00:49:59저희 Marimo를 비롯해 수많은 프레임워크가 이를 바탕으로 작동하거든요.
00:50:01Starlette 프로젝트가 무너지는 건 절대 원치 않죠.
00:50:03엄청나게 큰 위험을 초래할 테니까요.
00:50:05그러니까요.
00:50:05그런 연관 패키지들에 대한 공동 후원을 고민해 보는 것도 좋은 방법입니다.
00:50:09하지만 그 외에는 수많은 요청을 거절하고 공격 노출 면적을 최소화하는 것이야말로 실질적으로 할 수 있는 최선의 방법이죠.
00:50:16그래서, 잘 모르는 사람이… 아, 죄송합니다.
00:50:18요즘은 매주 사이버 공격이 발생하는 것 같다고 말하려던 참이었어요.
00:50:21정말 좋은 조언이네요.
00:50:22모두가 그런 최신 보안 동향을 잘 파악하고 있어야겠어요.
00:50:26지난 대화에서 비디오 관련 사이드 프로젝트를 하나 진행 중이라고 언급하셨죠?
00:50:33저희에게 소개해 주셨고, 지난번에 대화도 나눠본 엘리엇 이야기인데요.
00:50:37두 분은 어떤 관계인가요?
00:50:39네.
00:50:39좋습니다.
00:50:39엘리엇은 유튜브 채널을 하나 운영하고 있어요.
00:50:43'Dreams of Code'라는 채널인데요.
00:50:44항상 괜찮은 유튜버라고 생각해 왔죠.
00:50:48그러다 그 친구를 훨씬 더 존경하게 만든 계기가 있었어요.
00:50:52한 달 반 정도 영상을 안 올리더라고요.
00:50:54'왜 안 올리지?' 하고 궁금했죠.
00:50:55보통은 주 1회 영상을 올리잖아요.
00:50:57대부분의 유튜버들이 그러니까요.
00:50:58하지만 그는 6주 동안 자취를 감췄어요.
00:51:00그러더니 돌아와서 본격적으로 Rust 프로그램을 짜고 있었다더군요.
00:51:03LLM 요소를 살짝 곁들여서 잘라낼 구간을 파악해 주는 괜찮은 영상 편집기를 만들려 했던 거죠.
00:51:10직접 한번 써봤는데요.
00:51:11살펴보면서 '지금까지 나온 영상 편집용 LLM 툴들은 전부 맘에 안 들었는데'
00:51:19'아직 내가 실질적으로 쓸 만한 수준의 앱은 아니지만'
00:51:24'넘어야 할 산이 보이긴 해도, 제대로 만든다면 정말 근사한 물건이 나오겠구나' 싶더군요.
00:51:31그래서 먼저 연락을 취했죠.
00:51:32'만들고 계신 건 좋은데, 버그 목록을 좀 공유해 드립니다' 하고요.
00:51:36제대로 된 버그 리포트를 보낸 거의 초기 인물 중 하나였을 거예요.
00:51:39그렇게 계속 연락을 이어가게 되었죠.
00:51:41그 친구는 영상 편집 영역에 주력하고, 저는 썸네일 편집 영역에 집중하는 편이에요.
00:51:48유튜브 썸네일 제작을 최대한 단순하게 만들고 싶거든요.
00:51:52제 요구사항은 굉장히 간단해요.
00:51:54제 사진이나 누군가의 사진 주위에 흰색 테두리를 손쉽게 넣는 식이죠.
00:52:00그런 소소한 작업을 편하게 하거나 배경 제작을 훨씬 단순화해 주는 수준을 원해요.
00:52:05그래서 저만의 툴을 바이브 코딩으로 만들어봤죠.
00:52:09한편으로는 '이거 혹시 상품으로 팔 수도 있지 않을까?' 하는 생각도 들더군요.
00:52:14속으로 그런 생각을 좀 해봤죠.
00:52:15진짜 괜찮은 아이디어인지는 아직 확신이 안 서지만요.
00:52:17몇몇 사람들이 저한테 연락해서 만드신 게 꽤 유용해 보인다고 하더군요.
00:52:21솔직히 고백하자면, 전 Swift 언어를 잘 모릅니다.
00:52:25앱을 직접 만들고 애정을 갖게 되면서 이제 조금 알게 된 정도죠.
00:52:29어느 정도 유지보수를 하고 싶긴 하거든요.
00:52:30그래서 나름 좋은 파일 구조를 잡으려고 이런저런 노력을 기울이죠.
00:52:34하지만 근본적인 오류가 생겼을 때, 약간의 수정조차 AI 툴에 완전히 의존해야 한다는 사실이 찜찜하더군요.
00:52:41지금 제 단계에서는 혼자 쓰기엔 멋진 도구예요.
00:52:47지인들에게 공유하는 것 정도는 부담이 없죠.
00:52:51하지만 이걸 정식으로 판매하는 게 맞는지 결정하기엔 아직 한참 멀었습니다.
00:52:56지금은 딱 그런 상태입니다.
00:52:58다들 비슷한 경험이 있으실 텐데, 혼자 쓸 툴을 바이브 코딩으로 만드는 건 정말 쉽습니다.
00:53:03하지만 판매할 수 있는 수준의 프로그램으로 만드는 건 품질의 기준 자체가 완전히 다르잖아요?
00:53:09개인적으로 그 문제는 아직 답을 찾지 못했어요.
00:53:12매일 쓰는 툴인데도 이런 고민이 드는 게 참 묘해요.
00:53:14유튜브 영상을 만들 때마다 기존에 써본 어떤 툴보다 훨씬 좋아서 항상 이 앱을 쓰게 되거든요.
00:53:21하지만 잘 모르겠네요.
00:53:21엘리엇의 입장을 대신 말씀드리자면 (본인이 직접 말하는 게 더 정확하겠지만),
00:53:27엘리엇은 코드를 진짜 직접 다 작성하는 편인 것 같아요.
00:53:30'내가 애정을 갖고 소유한 프로젝트'라는 감정이 훨씬 강하고, Rust 공부도 더 하고 싶어 하죠.
00:53:35여러모로 삼박자가 잘 맞아떨어진 케이스예요.
00:53:39저는 아이도 있고 가정과 본업이 있다 보니
00:53:42앱을 제대로 유지보수할 만큼 Swift를 깊이 있게 배울 시간이 지금은 없습니다.
00:53:46그래도 계속 만들면서 이런저런 실험을 해보는 중인 건 사실이에요.
00:53:50맞는 말입니다.
00:53:51요즘 다들 비슷한 기분을 느끼실 것 같아요.
00:53:53자기한테 필요한 도구를 바이브 코딩으로 만드는 건 정말 간단하잖아요.
00:53:55다만 제대로 된 소프트웨어에서 '괜찮음'과 '훌륭함'의 차이를 인지하는 순간,
00:54:00책임감을 가지려 할수록 마음의 부담이 꽤 커지죠.
00:54:04저도 워크플로우 구석구석에 쓰려고 바이브 코딩으로 만든 앱이 수두룩하거든요.
00:54:09제품으로 출시할 수도 있겠지만, 그 순간 내 컴퓨터뿐만 아니라 모든 사용자 환경에서 잘 작동하는지 확인해야 하니까요.
00:54:16그리고 코드의 소유권에 대해 하신 말씀처럼, 그것들 대부분이 바이브 코딩으로 만들어졌잖아요.
00:54:20솔직히 내일 당장 삭제돼도 바이브 코딩으로 다시 만들면 그만이라 원하는 결과물만 나온다면 내부 코드엔 신경을 안 쓸 겁니다.
00:54:28그래서 실제로 제품으로 내려면 면밀히 검토하고 제대로 만들어졌는지 확인하는 작업이 많이 필요하죠.
00:54:34방금 말씀하신 '애정'이라는 단어가 핵심이라고 생각해요.
00:54:38제가 경험한 일 중 꽤 흥미로운 이야기가 하나 있는데요.
00:54:43Lua 언어로 가장 간단한 플랫포머 비디오 게임 데모를 만들어봤어요.
00:54:4910년 전 브렛 빅터가 언급했던 개념이기도 한데요.
00:54:52캐릭터가 발판으로 점프해서 다음 발판으로 넘어가야 하는데 겨우 안 닿거나 점프에 실패하는 상황이 눈에 띄더군요.
00:54:59발판을 더 가깝게 옮기거나 중력 값을 조정하는 등 몇 가지 수치를 조절해야 했죠.
00:55:04이걸 Claude와 대화하면서 수정하고 싶진 않았어요. 너무 답답할 게 뻔하니까요.
00:55:08그런 식의 대화는 정말 피하고 싶었죠.
00:55:10그래서 제가 선택한 해결책은 새 IDE를 만드는 것이었습니다.
00:55:13이름은 'Scrub'이에요.
00:55:14수요일 밋업에서 공개했었죠.
00:55:17이 IDE의 핵심은 모든 정수와 실수 값을 드래그로 조절할 수 있다는 겁니다.
00:55:21숫자를 클릭해서 좌우로 문지르면 수치가 변경돼요.
00:55:24정수가 바뀌는 동시에 디스크의 파일도 즉시 저장됩니다.
00:55:27Lua와 Love2D에는 멋진 기능이 있어서 화면이 새로 렌더링될 때마다
00:55:33프레임 단위로 체크를 하는데요.
00:55:35디스크에 새 파일이 생기면 모든 모듈을 즉시 다시 로드할 수 있죠.
00:55:38컴파일러를 거칠 필요가 전혀 없는 겁니다.
00:55:42변수를 실시간으로 수정하면서 게임에 즉각 반영되는 걸 볼 수 있죠.
00:55:46정말 멋진 데모예요.
00:55:47그런데 전혀 예상치 못했던 점은, 코드를 직접 확인하고 만져볼 수 있게 되자
00:55:51코드에 훨씬 더 큰 애정을 갖게 되었다는 겁니다.
00:55:54언제든 쉽게 수치를 조절하며 테스트할 수 있도록
00:55:58모든 변수를 정돈해 두고 싶어졌거든요.
00:56:00for 루프 안의 정수를 바로 바꿀 수도 있으니까
00:56:03오브젝트 생성 개수를 2개에서 10개로 순식간에 늘릴 수도 있죠.
00:56:05AI가 자동으로 생성해 주는 여타 코드보다
00:56:10훨씬 더 능동적으로 코드베이스를 만지게 되더군요.
00:56:11코드에 애정을 갖는 것이 핵심이라는 걸 바로 깨달았습니다.
00:56:14코드에 애정을 가질 방법을 찾는다면 나머지는 자연스럽게 따라오니까요.
00:56:18제가 AI 코딩에서 가장 아쉽게 느끼는 부분도 바로 그점입니다.
00:56:21스스로를 상아탑에 가둬두게 되고 개발자와 코드 사이의 거리가 너무 멀어지는 느낌이죠.
00:56:27문제가 생겼을 때, 전 늘 대기업에서 구르는 말단 코더 입장이었거든요.
00:56:34상아탑 안에서 정장 입고 앉아있는 경영진을 향해 불만을 토로하곤 했죠.
00:56:38그런데 Claude를 쓰면 내가 바로 그 경영진이 되는 겁니다.
00:56:41이런 실험이 정말 마음에 들었던 건 '어떻게 하면 코드에 더 애정을 갖게 할 수 있을까?'를 보여줬기 때문이에요.
00:56:47언제나 유의미한 시도죠.
00:56:49노트북 이야기로 다시 돌아가 보자면,
00:56:50노트북 환경이 좋은 이유도 바로 그 때문입니다.
00:56:52필요한 차트를 즉시 보여주니 코드에 조금 더 애착이 생기죠.
00:56:55슬라이더 같은 위젯을 가져오면 수치나 설정을 직접 조정하며 노는 재미도 있습니다.
00:57:01상호작용이 가능해지니까요.
00:57:03하루 종일 쳐다봐야 하는 정적인 파일과는 다릅니다.
00:57:07아무튼 '애정'이라는 단어를 쓰셨는데,
00:57:09그게 앞으로 가장 중요한 화두가 될 거라고 봅니다.
00:57:12'어떻게 해야 소프트웨어에 대한 애정을 유지할 수 있을까?' 하는 점이요.
00:57:15주의하지 않으면 그 애정의 부재가 독이 될 테니까요.
00:57:18맞아요. 기술적으로 이제 코드를 찍어내는 건 너무나 저렴해졌잖아요.
00:57:22Claude한테 부탁하면 금방 써주니까요.
00:57:24진짜 중요한 건 그 코드에 가치를 더하는 일이죠.
00:57:27예전에는 앱 하나를 만들려면 몇 시간씩 직접 앉아서 코드를 짜야 했습니다.
00:57:32작업자의 노력과 시간이 가치로 녹아있었죠.
00:57:34하지만 이젠 프롬프트 한 번으로 돌아가는 것처럼 보이는 걸 얻을 수 있어요.
00:57:39다만 진짜 좋은 코드인지 확인하려면 코드를 직접 들여다보아야겠죠.
00:57:42'Claude가 작업과 사고는 대신해 줄 수 있어도, '이해'까지 대신해 줄 수는 없다'는 말이 기억나네요.
00:57:48이해하는 과정만큼은 스스로 챙겨야 하잖아요?
00:57:50저도 그 부분에 큰 가치를 두고 싶습니다.
00:57:53'코드를 이해하지도 못하는데 이걸 팔아도 될까?' 하는 두려움은
00:57:57사실 굉장히 무서운 일이니까요.
00:57:58사용자의 기밀 정보를 다루는 프로그램이라면 더욱 그렇고요.
00:58:03소소하게 재미있는 일화가 하나 더 있는데요.
00:58:05기억력을 좀 훈련하고 싶어서 암기 카드 앱을 직접 만들었어요.
00:58:08AI가 일을 다 해줘서 내가 외울 게 줄어들더라도
00:58:13기억력이 감퇴하지 않도록 뇌 운동은 계속하고 싶었거든요.
00:58:16그래서 remember.cards라는 잊어버리기 힘든 이름의 앱을 만들었죠.
00:58:21그러고 나서 '암기 카드는 LLM으로 만들면 되겠다' 싶더군요.
00:58:24LLM을 활용하기 딱 좋은 용도잖아요.
00:58:26제가 만들고 싶었던 카드는 전 세계 언어로 '감사합니다'를 모은 거였어요.
00:58:31루마니아어로는 'multumesc'인데, 단어가 참 예쁘죠.
00:58:34카드 앞면에는 '루마니아어로 감사합니다가 무엇인가요?'라고 적히고
00:58:37뒷면에는 'multumesc'라고 나오는 방식입니다.
00:58:40Claude한테 전체 카드를 만들어달라고 했고, 금방 만들어줬어요.
00:58:44첫 번째 카드가 뭔지 아세요?
00:58:46'영어'로 '감사합니다'는 무엇일까요?
00:58:48Claude를 활용해 무언가를 학습하는 과정을 완벽하게 보여주는 사례죠.
00:58:51엄청나게 많은 양의 자료를 생성해 주기는 합니다.
00:58:54꽤 놀라울 정도죠.
00:58:55하지만 동시에 아무런 실질적 맥락 이해도 하지 못한다는 게 명백하잖아요.
00:58:58암기 카드와 관련해서 깨달은 게 또 있는데, 카드를 Claude한테 맡기면 안 되겠더군요.
00:59:03제가 직접 수동으로 작성해야 합니다.
00:59:05진짜 학습이 목적이라면, 나중에 복습하는 것보다 직접 받아 적는 행위 자체가 기억에 훨씬 더 도움이 되니까요.
00:59:13작성 과정에 직접 관여하는 편이 Claude에게 전부 외주 주는 것보다 뇌 연동에 훨씬 효과적입니다.
00:59:18무언가를 직접 알고 깨닫는 건 즐거운 일이기도 하잖아요?
00:59:20단순히 '편하다'는 이유로 지적 활동까지 맡겨버리진 말자는 거죠.
00:59:26개발 쪽 일을 하지 않는 친구들과 얘기하면서 저도 비슷한 경험을 했어요. 직장에서 ChatGPT나 Claude를 쓰기 시작했더라고요.
00:59:33어떤 친구는 '이 부분은 AI가 틀렸더라고' 하고 말하면서도
00:59:37바로 다음 문장에서 '그래도 난 모든 일에 AI를 써.'
00:59:39'새로운 분야 배울 때 무조건 쓰지' 이러더군요.
00:59:41그래서 제가 '네가 잘 아는 분야라서 ChatGPT 오류를 잡아낸 걸 잊었어?'라고 해줬죠.
00:59:46전혀 모르는 분야를 배울 때도 똑같이 잘못된 정보가 섞여 들어간다는 걸 명심해야 합니다.
00:59:51AI가 틀릴 수도 있다는 걸 잊으면 안 돼요.
00:59:54새로운 걸 배우려고 ChatGPT에 물어보기 시작하는 순간, 틀렸는지 맞았는지 구분을 못 하게 되니까요.
00:59:59절대적인 사실로 그대로 받아들이면 안 됩니다.
01:00:02맞아요. 무언가를 직접 알아가는 과정 자체가 즐겁기도 하죠.
01:00:06저는 그런 식으로 대처하는 편이에요.
01:00:08Claude가 모든 걸 할 수 있다는 건 멋진 일입니다.
01:00:11단지 제 욕심일 뿐이에요.
01:00:12AI가 다 해주길 원치 않아요.
01:00:13당당하게 밝힐 수 있는 제 주관이죠.
01:00:16하지만 각자 상황에 맞춰 활용법을 찾아가는 게 맞겠죠.
01:00:20그리고 제가 느낀 조언을 하나 덧붙이자면,
01:00:26다들 비슷한 경험이 있으신지 궁금하네요.
01:00:29LLM이 우리 대신 모든 코드를 실행할 수 있게 된다는 전제가 맞다면,
01:00:34결국 인간인 우리가 해야 할 핵심 기여는 LLM이 수행할 좋은 아이디어를 내는 일 아닐까요?
01:00:42LLM이 아이디어 구상에도 도움이 될까요?
01:00:44제가 느낀 건, 좋은 아이디어를 내려면 요즘엔 컴퓨터에서 최대한 멀어져야 한다는 점이에요.
01:00:50아이와 시간을 보내거나 종이와 펜을 들고 술집에 가서 창의적인 영감을 자극하는 거죠.
01:00:56컴퓨터 앞을 벗어나 있을 때 번뜩이는 아이디어가 떠오르고, 그걸 잊지 않게 메모해 두기만 하면 됩니다.
01:01:02Claude는 그런 창의적 발상 영역엔 정말 쥐약이거든요.
01:01:07그렇죠?
01:01:07Take-Two 대표의 인터뷰가 떠오르네요. 누군가 'AI가 게임을 만드는데, 사람들이 대작 게임을 쏟아낼까 봐 걱정되지 않나요?'라고 물었죠.
01:01:17그가 답하길 '게임을 만드는 건 늘 가능했고 쉬웠지만, 창의적인 신규 아이디어는 AI가 줄 수 없으니 직접 내야 한다'고 했어요.
01:01:27공감합니다. 저 역시 새로운 아이디어는 직접 떠올리곤 하니까요.
01:01:31맞아요. AI는 유용한 아이디어를 내놓는 것도 못하고 '디테일한 정성'을 쏟지도 못해요. 스팀에서 판매될 만한 가치 있는 게임을 완성하려면 그 정성이 필수적인데 말이죠.
01:01:40청취자 여러분, 디테일과 정성이 진정 중요하다는 사실을 꼭 기억해 주세요.
01:01:46AI 영화 제작 논란과도 일맥상통하는데, AI는 인간이 이미 해놓은 작업만 학습했기 때문에 완전히 새로운 걸 창조하지 못합니다.
01:01:58물론 인간도 타인에게 영감을 받긴 하지만, 약간 결이 다른 문제죠.
01:02:04AI에게 매우 독창적인 스타일을 만들어달라고 할 수는 없으니까요.
01:02:10독창적인 스타일은 오직 본인만이 소유할 수 있습니다.
01:02:13반례가 있는지 궁금한데, 저는 아직 찾지 못했어요.
01:02:19스트리밍 시대가 되면서 영화나 영상의 질이 더 나아졌나요?
01:02:23제가 느껴본 건…
01:02:25시간을 투자할 가치가 있을 만큼 정말 훌륭해서 저녁 시간을 기꺼이 비우고 본 영화 시리즈는 딱 하나 떠오르는데요.
01:02:31바로 '나이브스 아웃' 시리즈입니다.
01:02:33정말 잘 만든 추리 영화죠.
01:02:35진짜 완성도가…
01:02:37그런데 그 영화를 보면서 '왜 내가 안도감을 느끼지?' 싶은 생각이 들더군요.
01:02:41원래는 좋은 영화가 매주 나와줘야 정상 아닌가요?
01:02:43'플래닛 어스'나 할리우드처럼... 왜 2년에 한 번 꼴로만 좋은 영화가 나오는 걸까요?
01:02:50그러다 이런 생각이 들었죠. '마찬가지 상황이...'
01:02:52컴퓨터 코드의 진화에서 진정한 진보처럼 느껴지는 프로젝트들이 몇몇 등장하긴 했지만,
01:03:00지금 LLM이 있는데도 우리가 만들 수 있는 훌륭한 소프트웨어가 10배로 늘어나진 않았잖아요?
01:03:06'잠깐만,'
01:03:07'뭔가 이상한데?' 싶은 거죠.
01:03:09그런 고민을 혼자 해보고 있어요.
01:03:12모든 게 쉬워졌다는 증거는 이렇게 많은데,
01:03:15왜 모든 게 나아지진 않는 걸까요?
01:03:17넷플릭스나 디즈니+ 같은 스트리밍 서비스를 예로 드셨는데요.
01:03:22스트리밍이 가능해졌으니 좋은 콘텐츠를 만들기도 쉬워졌어야 한다는 말씀인가요?
01:03:28그런 의미인가요?
01:03:29확실히...
01:03:30그러니까...
01:03:31단어 선택을 신중히 해야겠네요, 맞는 말씀입니다.
01:03:34넷플릭스를 비유로 든 건 기대만큼의 퀄리티가 나오지 않는다는 걸 느껴서예요.
01:03:40넷플릭스를 보는 사람이 그렇게 많고 수요가 엄청나다면 그만큼 공급도 따라와야 할 것 같잖아요.
01:03:48하지만 우리가 받는 공급은 '질'이 아니라 '양'에 불과한 느낌이죠.
01:03:53LLM에서도 비슷한 일이 일어나고 있는 것 같아요.
01:03:56작성되는 코드는 많아졌지만, 제가 관심 가질 만한 코드가 늘어난 건 아니거든요.
01:04:01전 여전히 뛰어난 웹 프레임워크처럼 예전부터 존재했던, 즐겨 쓰고 유지보수하고 싶은 코드에 관심이 가요.
01:04:06하지만 에어비앤비가 지금 더 뛰어난 웹 앱이 되었나요?
01:04:11부킹닷컴이 지금 더 나은 웹 앱이 되었나요?
01:04:13예전에는 절대 불가능했던, 전세를 역전시킬 만한 코드의 사례가 지금 있냐는 거죠.
01:04:20원격으로 일하고 계시는군요.
01:04:21정곡을 찌르셨네요.
01:04:22제가 정말 두려워하는 부분을 정확히 짚으셨어요.
01:04:272년 전만 해도 안정적이었던 앱 다수가 이제는 그렇지 않다는 걸 느껴요.
01:04:33버그가 점점 많이 늘어나고 있는데, 다들 제대로 검증도 안 하고 느낌대로 기분 내키는 대로 기능을 얹어서인 것 같아요.
01:04:41가장 안정적인 앱조차 더 이상 안정적이지 않은 시점이 올 것 같습니다.
01:04:47그 말씀을 하실 때 아마 깃허브를 염두에 두신 것 같네요.
01:04:50아닐 수도 있지만요.
01:04:50깃허브가 가장 두드러진 예시이긴 하죠.
01:04:54하지만 언급하신 부킹닷컴 같은 일반 사용자용 앱들도 그래요.
01:04:58치명적인 버그가 터지기까지 한 2주 정도 남아있는 느낌입니다.
01:05:03모르겠네요.
01:05:04또 다른 우려도 있을 수 있죠.
01:05:08사람들이 프로그래밍하는 방식에 이런 식으로 익숙해지면 어떻게 될까요?
01:05:12지금 엄청난 지식이 침식되고 있고, 이를 해결하는 데 필요한 지식마저 함께 사라지면 어쩌죠?
01:05:18은퇴한 사람들을 제때 다시 불러올 수 있을까요?
01:05:21정말 필요할 때요. 이상한 소리 같지만 잘 모르겠습니다.
01:05:27지극히 개인적인 경험이지만 몇 번 순간 깨달은 게 있어요.
01:05:31Marimo에서도 때때로 LLM을 쓰지만, 다들 각자 'LLM을 완벽히 신뢰할 수는 없다'는 결론에 다다른 느낌이에요.
01:05:39그리고 내 실력이 완전히 퇴화하는 것도 원치 않고요.
01:05:43동료들을 대변해서 하는 말이라 100% 정확하다고 장담할 수는 없지만,
01:05:46저희 중 상당수는 무엇이 코드에 반영되는지 진심으로 신경 쓰고 있어요.
01:05:50그래서 AI로 대충 짜놓은 코드라면 다른 동료가 직접 수동으로 검수하길 원하죠.
01:05:54Marimo가 굉장히 안정적인 소프트웨어가 되는 걸 중요하게 생각하니까요.
01:05:59다른 프로젝트들에서도 이런 방식이 얼마나 유지될지는 모르겠네요.
01:06:04방금 하신 말씀과 비슷하게, 저도 늘 같은 의문이 들어요.
01:06:08다들 “AI가 회사에서 주니어 역할을 대신한다”고 하잖아요.
01:06:12“그럼 20년 뒤에는 누가 시니어 역할을 하지?” 싶은 거죠.
01:06:16주니어들을 다 대체해 버리면, 예전처럼 과정을 거치며 배우는 파이프라인은 누구를 거쳐 가나요?
01:06:24글쎄요, 틀린 말은 아니죠.
01:06:26하지만 제가 주니어였을 때 기여했던 가장 큰 가치들을 돌이켜보면,
01:06:33코드 자체보다는 “이 문제는 이런 방식으로 접근하면 안 됩니다”라는 식이었어요.
01:06:38예를 들어, 제가 발표했던 유튜브 강연 영상들이 좀 있는데요.
01:06:43처음 추천 시스템을 만들었던 곳이 네덜란드의 BBC 같은 곳이었어요.
01:06:47거기서 “조회수를 늘리는 것보다 전체 카탈로그가 고루 소비되는 게 중요하다”고 했죠.
01:06:53사람들이 클릭할 만하면서도 추천 결과에 다양성이 있길 원했어요.
01:06:57다양성과 실제 시청 여부에 신경 쓴 거죠.
01:06:59낚시성 클릭을 원치 않았어요.
01:07:00클릭 후 영상을 실제로 끝까지 봐야 했죠.
01:07:03박사들은 다들 “딥러닝, 텐서플로가 미래다, 도입하자”라고 말했죠.
01:07:09그리고 저도 그 자리에 있었는데, 전 농담조로 이렇게 말했어요.
01:07:13“그런 걸 하기 전에 우선 A/B 테스트 시스템부터 만들어야 하지 않을까요?”
01:07:16추천 시스템을 A/B 테스트조차 못 하면 아무 의미가 없으니까요.
01:07:21이야기를 약간 의역하긴 했지만, 박사들은 “좋아요, 그럼 2주 후에 다시 얘기하죠”라고 했어요.
01:07:26그리고 2주 뒤에 다시 와서는 “추천 시스템은 다 만들었나요?”라고 묻더군요.
01:07:29“네.”
01:07:30“좋아요, 이제 텐서플로 작업을 합시다.”
01:07:32“텐서를 굴려봐야지.”
01:07:33저는 또 “아뇨, 기존 추천 시스템이 이미 구축되어 있으니까,
01:07:38추천 구좌 3개(1번, 2번, 3번 항목)의 순서를
01:07:43무작위로 섞어서 위치 편향이 있는지 확인해보죠”라고 했죠.
01:07:45A/B 테스트를 본격적으로 하기 전에 알아보면 좋을 테니까요.
01:07:48다시 돌아와서는 “이제 시작해도 되나?” 하시길래
01:07:50“A/B 테스트 시스템에 편향이 없는지 확인하려 한다”고 했죠.
01:07:52A/B 테스트 시스템에 편향이 없는지 확인하고 싶으니 그 테스트부터 하자고요.
01:07:56이런 식의 밀당이 몇 주간 계속되었습니다.
01:07:58결국 박사님들이 “이제 드디어 본작업을 할 수 있나?” 했을 때,
01:08:01“좋습니다, 그런데 시청 중인 다음 화를 그냥 추천하는 방식도 테스트해보고 싶어요”라고 했어요.
01:08:07박사님들은 수학이나 텐서플로 같은 복잡한 작업에만 골몰하느라,
01:08:11시청 중인 프로그램의 다음 에피소드를 추천한다는 간단한 아이디어를 완전히 놓치고 있었던 거죠.
01:08:16이게 주니어의 본분이라고 주장하려는 건 아니지만, 때로는 시니어를 향해 “더 간단한 방법은 없나요?”라고 질문할 주니어가 필요해요.
01:08:26“딥러닝은 잘 모르지만, 이 방식이 더 낫지 않나요?”처럼요.
01:08:30의욕 넘치는 신입 특유의 개성이 가져오는 이점이 커요.
01:08:35저처럼 처자식이 있는 연배의 사람들은 떠올리기 힘든 생각들이죠.
01:08:40제가 두려워하는 건 바로 그 부분입니다.
01:08:41기존 관습에 얽매이지 않고 고정관념을 깰 수 있는 주니어가 곁에 있을 때
01:08:48좋은 아이디어가 많이 나온다고 생각해요.
01:08:52“미래에도 엔지니어가 남아있을까?”보다 이런 공백이 더 우려스럽죠.
01:08:55때로는 바퀴를 새로 발명해야 할 때가 있는데, 사람들이 그걸 발견하지 못하는 기분이에요.
01:09:02개인적으로 저는 이 점이 더 염려됩니다.
01:09:05오픈소스 생태계도 마찬가지잖아요?
01:09:07새로운 아이디어를 낼 젊은 피가 계속 필요합니다.
01:09:10“시니어가 계속 남아있을까?”의 문제가 아니라,
01:09:13“새로운 아이디어의 원천은 어디가 될 것인가?”의 문제죠.
01:09:15LLM을 쓰는 50대 개발자에게서 나오진 않을 겁니다.
01:09:17비판적인 질문을 던지고 더 나은 길을 고민하는 사람에게서 나와야 하죠.
01:09:25보통 그런 사람들은 40~50대가 아니라 20~30대입니다.
01:09:30맞아요, 다들 AI에 조금은 덜 집착하는 시점이 와야 한다고 봅니다.
01:09:34지금은 거품이 너무 심하고, 다음 기술이나 플러그인에만 매몰되어 있어요.
01:09:39열기가 좀 식고 나면 흥미로운 아이디어들이 세상에 나올 수 있겠죠.
01:09:44만들 수 있는 멋진 것들이 정말 많으니까요.
01:09:46여전히 흥미진진해야 할 영역입니다.
01:09:48하지만 아직 눈에 띄는 멋진 결과물을 많이 보지 못해 걱정이긴 해요.
01:09:52여전한 고민거리죠.
01:09:55하지만 한 가지 말씀드리자면,
01:09:58자랑 하나만 할게요.
01:09:59Marimo는 예외적으로 참 멋진 사례입니다. 주기적으로 노트북 경진대회를 열거든요.
01:10:03거기서 나오는 결과물들이 정말 재미있어요.
01:10:05사람들이 아주 깊이 파고들면서 창의성을 발휘하죠.
01:10:08LLM을 썼더라도 구상했던 아이디어가 멋지다는 게 확실히 느껴져요.
01:10:13LLM은 그걸 구현해 준 도구일 뿐이고요.
01:10:15창의성을 발휘하려는 훌륭한 시도가 돋보이는데, 볼 때마다 참 보기 좋습니다.
01:10:19제임스, 무슨 말씀 하려 하셨나요?
01:10:21최근 트위터에서 기업들이 개발자 개인당 토큰 비용이 얼마나 드는지, 대비 수익은 얼마나 나는지 파악하기 시작했다는 글을 많이 봤어요.
01:10:30일부 회사들은 “개발자들에게 토큰을 무제한 제공하겠다”고 했었잖아요.
01:10:34문제는 Claude 인스턴스 20개를 띄워놓고 20가지 다른 방식으로 시도한다는 겁니다.
01:10:39그러고는 겨우 기능 하나 추가하는 식이죠.
01:10:42비용이 엄청나게 많이 들어요.
01:10:44차분히 앉아서 미리 계획을 세우고 진행했다면 비용이 훨씬 적게 들었을 텐데요.
01:10:49그래서 이 단속을 시작하겠다는 기업들이 제법 보이더라고요.
01:10:53맞아요, 듣기로 Claude 측에서 “개인이면
01:10:59월 100달러 요금제를 써도 되지만,
01:11:01기업 사용자는 엔터프라이즈 플랜이라 토큰당 과금하겠다”고 했다더군요.
01:11:08한편으로는 안도가 됩니다. 지능을 조금 더 쓰도록 강제하니까요.
01:11:13기계에 입력하기 전에 펜과 종이로 먼저 풀어보게 만들 테니까요.
01:11:18동료와 화이트보드에 적어가며 고민하거나요.
01:11:20'실용적인 엔지니어' 게르겔리가 올린 흥미로운 트윗을 읽었는데 (참고로 기량이 뛰어난 팟캐스트입니다,
01:11:27강력 추천해요),
01:11:29그가 흥미로운 트윗을 올려서 봤는데, 예전에는 어떤 일을 하려고 할 때 괜찮은 아이디어인지 확신이 안 서면
01:11:36동료 어깨를 툭툭 치면서 이게 좋은 생각인지 아닌지 같이 이야기를 나누곤 했잖아요
01:11:41그 과정에서 서로 배우는 점이 있었고요.
01:11:43하지만 요즘은 LLM과 대화하죠.
01:11:45동료 어깨를 두드리는 일이 줄었어요.
01:11:47귀중한 배움의 기회들이 사라지고 있다는 뜻입니다.
01:11:51그런 측면도 있죠?
01:11:52LLM은 상대를 지나치게 치켜세워 주는 경향이 있으니까요.
01:11:56무조건 아이디어가 훌륭하다고만 답해줍니다.
01:11:58조금만 잘하는 척하면 스탠스를 홀딱 바꿔버리고요.
01:12:02전문가 둘이 나누는 비판적 대화에서 얻는 게 정말 많았는데 말이죠.
01:12:08지켜봐야겠네요.
01:12:09가장 황당했던 건, 고급 키보드를 사던 사람들이
01:12:15“이제 타이핑을 안 하니까 인체공학 키보드가 필요 없겠는데?”라고 말한다는 점이에요.
01:12:20본인 셋업은 어떻게 되나요?
01:12:22Claude Code를 쓰나요?
01:12:24아니면 그 뭐냐...
01:12:25Codex?
01:12:26Cursor 파인가요?
01:12:27C로 시작하는 도구들 중에요?
01:12:29저는 다양한 것을 시도해 보는 편입니다.
01:12:33절대적인 최고 표준(SOTA)이라는 건 존재하지 않는다고 봐요.
01:12:39실제로 존재하지 않죠.
01:12:40하지만 합리적인 기본값 위주로 생각하곤 해요.
01:12:42Conductor라는 도구가 있는데 무척 마음에 듭니다.
01:12:45Codex와 Claude 양쪽에 연동해 쓸 수 있어요.
01:12:51미리 밝혀두자면
01:12:53그쪽 관계자들과 사업적으로 약간 얽혀있으니, 방금 한 말은 걸러 들으셔도 됩니다.
01:12:58하지만 저에게는 매우 훌륭한 기본 옵션이에요.
01:13:00가장 좋은 점은 갑자기 아이디어가 떠올랐을 때 “이게 될까?” 하고
01:13:06작업 공간을 띄워 테스트해 본 뒤 다른 일로 쉽게 넘어갈 수 있다는 거죠.
01:13:10OpenCode도 좋아하는데 다양한 오픈소스 모델을 사용해 볼 수 있어서예요.
01:13:14그래서 즐겨 쓰는 편입니다.
01:13:16Py도 많이 써요. MoLab에서 GPU 샌드박스를 실행할 수 있는데, 쉽게 말해 GPU가 탑재된 파이썬 샌드박스 같은 거죠.
01:13:28로컬 LLM이 스케치패드 기법으로 거기에 연결되도록 할 수 있어요.
01:13:34단, LLM이 로컬 파일 건드리는 건 절대 사절입니다.
01:13:38샌드박스의 존재 이유가 그 내부에서만 작업하고 수정하게 하는 거니까요.
01:13:41로컬 환경에 영향을 주고 싶지 않아요.
01:13:43Py의 진짜 멋진 점은 툴 호출 이벤트가 발생할 때마다 그걸 감지해서
01:13:48“수정 명령인가?”를 확인하고
01:13:50“그럼 차단.”
01:13:51클라우드 파일만 수정할 수 있게 제어할 수 있어요.
01:13:53“읽기 명령인가?” 싶으면
01:13:54“스킬 파일 두 개에 대해서만 허용” 형태로 설정 가능하죠.
01:13:58그런 유연성이 놀랍습니다.
01:14:00그래서 그쪽을 집중적으로 파고드는 중이에요.
01:14:06그리고 제가 하는 또 다른 일은 대략 이런 건데요.
01:14:11다시 수학 강좌를 들으며 진짜 어려운 수학 문제들을 풀고 있어요.
01:14:15엄청 어렵다기보단 10년 만에 수학을 하려니 어렵게 느껴지는 거죠.
01:14:19제가 Marimo 팀에 기여할 수 있는 제 핵심 가치는 신선한 시연(데모)을 보여주는 거라, 흥미로운 스토리를 기획하는 능력에 가깝죠.
01:14:31그래서 컴퓨터 앞에만 너무 오래 앉아 있지 않고, 밖에서도 흥미로운 삶을 사는 사람이 되려고 노력 중입니다.
01:14:42예를 들어 보컬 코치에게 첫 레슨을 받기 시작했어요. 독특한 시도죠?
01:14:51유튜브를 한다면 그리 엉뚱한 일도 아닙니다.
01:14:53목소리의 원리를 배우다 보면 흥미로운 것들이 정말 많아요.
01:14:55“관련 의료 데이터셋이 있을까?” 고민하게 되고
01:14:58그걸 데모로 활용하면 재미있겠더라고요.
01:15:00현실 세계로 나가 직접 체험하기 때문에 가능한 생각입니다.
01:15:05제 주된 관심사는 “창의성을 잘 유지할 수 있을까?”예요.
01:15:09거기서 재미있고 유익한 Marimo의 기능들이 나오니까요.
01:15:13그러려면 Marimo 코드베이스도 가끔 깊이 파고들어야 하지만, 환기할 시간도 필요합니다.
01:15:17그런 균형을 유지하려 노력하고 있어요.
01:15:21매우 바람직한 방향 같네요.
01:15:22컴퓨터에 지나치게 갇히지 않고 현실 세계와도 연결되어 있으니까요.
01:15:27저는 기술의 버블 안에 자주 갇히곤 하거든요.
01:15:32“이웃들은 왜 ChatGPT나 Claude를 안 쓸까?” 싶은 거죠.
01:15:36삶이 훨씬 편해질 텐데 그 존재조차 모르는 것 같아요.
01:15:40일반인들이 저희 같은 사람들에 비해 AI를 얼마나 아는지 비교해 보면 흥미롭습니다.
01:15:46그나저나 진행자분 이야기도 궁금하네요.
01:15:47좋아요, 이제 역할 바꾸기를 해보죠.
01:15:48제가 짧게 질문 하나 드릴게요.
01:15:51충분히 상상이 가는데, 회사 유튜브 채널을 운영하고 계시잖아요.
01:15:55조회수가 일종의 성장 목표일 수밖에 없을 것 같아요.
01:15:59조회수가 급락하는 건 원치 않으실 테니까요.
01:16:01하지만 그만큼 이번 주 트렌드 주제를 놓치지 않아야 한다는 압박감도 있을 것 같은데요.
01:16:07하지만 그게 항상 본인이 가장 흥미를 느끼는 주제는 아닐 수도 있잖아요.
01:16:11어떤 콘텐츠를 만들지 회의를 할 때 실제로 고민되는 부분인가요?
01:16:16다 같이 순번제로 정하는 건지 모르겠지만, 유튜브 팀에 인원이 여러 명 계시니까요.
01:16:21누가 먼저 말씀하실지 모르겠지만, 정말 인기 있는 주제라도 제가 딱히 관심이 없는 경우가 가끔 있어요.
01:16:31James도 그랬는지는 모르겠는데, 저는 새 모델이 나올 때마다 영상으로 만들다가 이제 그만뒀거든요. 소폭 업데이트에는 별 관심이 없어서요.
01:16:38맞아요, 어느 순간 다 그게 그거 같아지죠.
01:16:42그래서 일정 시간이 지나 흥미가 안 가면 결국 안 만들게 되더라고요.
01:16:47전에는 인기 있다는 이유로 제작하곤 했지만, 요즘은 점점 안 그러려고 해요.
01:16:54카메라 앞에서 열정적으로 임하는 편이 영향이 크기도 하니까요, 그렇죠?
01:17:01맞아요, 흥미가 없는 것에 열정을 연기하기란 정말 어렵죠.
01:17:06비슷하게, 모델 출시 건도 4.8이 나왔을 땐 영상을 안 만들었지만, 최근 Gemini가 나왔을 땐 만들었어요. 단순히 벤치마크가 높아진 것 이상의 무언가가 있었거든요.
01:17:17신규 모델 발표가 “5% 더 좋아졌습니다” 수준이라 요즘은 좀 지루한 단계인 것 같아요.
01:17:23게다가 요즘 AI가 코딩을 너무 잘해서 차별점을 보여주기도 힘들죠.
01:17:28예전에는 “이 웹사이트 만든 것 좀 봐요” 했다면, 지금은 다들 지나치게 잘하거든요.
01:17:33처음엔 버튼 하나, 카드 하나 만들었을 때 “와, 제법 그럴듯한데?” 했었죠.
01:17:40하지만 이젠 웹사이트 전체를 바이브 코딩으로 훌륭하게 완성해 냅니다.
01:17:44그래서 막 출시된 모델로 복잡한 변화를 영상에서 보여주기가 쉽지 않아요.
01:17:47저는 차라리 2~3주 기다렸다가 실제 코드베이스에서 진짜로 사용해 보고 어떻게 작동하는지 확인하는 방식을 더 선호해요.
01:17:59하지만 저희가 주제를 다루는 방식도 마음에 들어요.
01:18:02뉴스를 다루며 트렌드를 놓치지 않는 면이 좋더라고요.
01:18:06무엇이 실제로 유용한지, 무엇이 과장 마케팅인지 가려내려고 노력하죠.
01:18:13그리고 때로는 개인 프로젝트 같은 주제로 영상을 다루기도 하고요.
01:18:18곧 나올 영상 중 하나는 Zed 에디터로 갈아탄 이야기인데, 신선하면서도 검증된 에디터죠.
01:18:23맞아요, Zed 정말 멋지죠.
01:18:25저도 Zed로 갈아탔거든요.
01:18:27Zed 관련해서는 영상거리가 꽤 나오죠.
01:18:29정말 괜찮아요.
01:18:30네, 그런 식으로 콘텐츠 기획을 접근하고 있어요.
01:18:33흥미롭네요.
01:18:33개인적으로 느낀 점인데, 과거에 Pandas, TensorFlow, Spark 열풍을 다 겪어봤거든요.
01:18:41이 모든 하이프 사이클을 지나왔죠.
01:18:43보통 문법 자체는 별로 흥미롭지 않아요.
01:18:47진짜 흥미로운 건 문제를 바라보는 관점을 바꿔주는 도구일 때예요.
01:18:50결국 도구 자체보다는 그 생각의 전환이 더 핵심인 거죠.
01:18:54예를 들어, 아까 말한 클라우드 플랫폼에서 이제 GPU를 사용할 수 있게 됐잖아요.
01:19:01그렇다면 내가 작성하는 코드에 대한 접근 방식도 달라져야 할까요?
01:19:04제가 해본 한 가지 시도는 외판원 문제(TSP)를 풀기 위한 알고리즘이었어요.
01:19:09모든 도시를 순회하는 경로를 찾는 문제죠.
01:19:10연산 복잡도가 엄청나서 관련 학술 논문도 수없이 많아요.
01:19:16그런데 GPU가 있다면 재미있는 발상을 해볼 수 있어요. 모든 도시 쌍을 메모리에 올릴 수 있다면,
01:19:24모든 쌍을 올려두고 GPU에게 어떤 순서를 뒤집어야 할지 물어보는 거죠.
01:19:30한 번에 싹 처리할 수 있으니까요.
01:19:32잠깐, 이건 CPU용 알고리즘을짤 때와는 완전히 다른 접근 방식이잖아요.
01:19:36이 방식을 일반 CPU 방식과 성능 비교(벤치마크) 해볼 수 있겠더라고요.
01:19:41문제에 접근하는 핵심은 문법이 아니라,
01:19:45GPU가 작동하는 개괄적인 메커니즘인 거죠.
01:19:47그런 부분에 대해서는 정말 열정적으로 이야기할 수 있어요.
01:19:51반면에 단순 문법 자체는 지루하기 짝이 없죠.
01:19:54하지만 진정한 스토리텔링은 바로 그런 지점에서 나온다고 생각해요.
01:19:57유튜브를 볼 때도 더 많은 크리에이터가 이런 방식으로 접근해주길 바라게 돼요.
01:20:01단순 성능 수치 발표보다, 새로운 도구 덕분에 문제를 재정의하는 관점이 훨씬 근사한 이야기를 만들어내거든요.
01:20:09하지만 새로운 모델이 나올 때마다 표정으로 엄청 오버하는 전형적인 유튜버들이 꼭 있죠.
01:20:17막상 영상 보면 “그냥 수치 좀 올랐네” 수준인데 말이죠.
01:20:19참 지루한 영상이죠.
01:20:21어쨌든 별로 흥미롭지 않아요.
01:20:23단순 주제가 아니라 좋은 스토리 중심으로 영상을 구성하는 건 정말 좋은 아이디어예요.
01:20:30참 흥미로운 접근법입니다.
01:20:32조회수 같은 성과로 이어질지는 모르겠지만요.
01:20:36하지만 흥미로운 서사를 바탕으로 이야기를 풀어내는 건 제작자 입장에서도 정말 즐거운 작업이죠.
01:20:44유튜브의 고전적인 아이러니인데, 개인적으로 가장 애착이 가는 영상이 오히려 조회수는 제일 낮더라고요.
01:20:53저도 그래요.
01:20:53전 그 영상 좋았어요.
01:20:56주제에 너무 몰입한 나머지 본인 흥분에 찌들어 설명을 너무 빠르게 넘기지 않도록 주의해야 해요.
01:21:04나만큼 관심 없는 사람에게도 이게 왜 흥미로운지 납득시키는 과정이 필요하니까요.
01:21:11쉽게 간과하곤 하는 단계죠.
01:21:14저는 혼자 마인드 컨트롤 게임을 하곤 하는데, 언젠가 Gemini가 모든 유튜브 영상을 요약해주는 시대가 오겠죠.
01:21:23지금도 어느 정도 가능하긴 하지만요.
01:21:25어떤 채널들은 영상의 절반은 유용하고 절반은 쓸데없거든요.
01:21:30영상을 볼지 말지 결정하기 전에 요약부터 먼저 받아볼 수 있을까요?
01:21:33그럼에도 어떤 크리에이터나 영상은 “그냥 직접 보고 싶다”는 생각이 들 때가 있어요.
01:21:39요약을 봤음에도 불구하고 직접 시청하고 싶어지는 거죠.
01:21:41정확히 그 요소가 뭔지는 모르겠지만, 제가 쫓고자 하는 가치가 바로 그거예요.
01:21:44요약본을 읽었어도 본 영상을 꼭 확인하고 싶게 만드는 콘텐츠를 만드는 거죠.
01:21:50네.
01:21:51저희 채널에 대해 느낀 점이 하나 있는데요, 비디오 모델을 주제로 콘텐츠를 만들면,
01:22:03사람들이 이상할 정도로 관심을 안 가지더라고요.
01:22:07Marimo 채널도 혹시 독자들이 유독 외면하는 특정 주제가 있는지 궁금해요.
01:22:15특정 데이터셋이라든가, 유독 반응이 안 좋은 주제가 있나요?
01:22:23일반적으로 유튜브 숏츠 같은 경우, 시각적인 위젯 요소를 보여주면 반응이 꽤 좋습니다.
01:22:31직관적으로 눈에 띄다 보니 숏츠 포맷에 잘 들어맞거든요.
01:22:35예쁜 그래프 같은 게 나오면 조회수가 잘 나와요.
01:22:39반면에, Marimo 단축키만 다룬 영상도 하나 있거든요.
01:22:44단축키를 하나씩 짚어주며 익히게 도와주는 내용이죠.
01:22:49기억에 잘 남도록 암기법 같은 것까지 동원하고요.
01:22:51당연히 이미 Marimo를 잘 쓰고 있는 코어 사용자들만 좋아할 영상이죠.
01:22:55Marimo가 뭔지도 모르는 사람이 단축키 영상을 볼 리가 없잖아요?
01:22:59대중적인 콘텐츠는 아니죠.
01:23:00저희에겐 Marimo를 열렬히 지지하는 핵심 코어층이 존재하는 한편,
01:23:10아직 사용해 보지 않은 잠재 유저가 훨씬 많아요.
01:23:13그래서 일부 영상은 그들의 호기심을 자극해 찍먹해 보게 유인하는 용도로 만듭니다.
01:23:21타깃층도 다양해서, 웹 개발자에 맞춘 맞춤형 영상을 만들면 그들이 좋아하고,
01:23:28요즘은 대중화된 AI 엔지니어 타깃 영상도 있죠.
01:23:31KimiK 2.6 영상 때 흥미로웠던 점은, 코드 품질만 보면 단연 “열등한 모델”이라는 거예요.
01:23:41하지만 속도가 워낙 빨라서 의외로 실용적일 수 있죠.
01:23:43다음 셀 생성이 빠르니까 코드를 완벽히 신뢰하진 않더라도 비판적인 시각으로 검토하며 쓰기 좋거든요.
01:23:49이런 코딩 방식도 한 번쯤 시도해 볼 만하죠.
01:23:54AI 관심층에게 일반 IDE와는 다른 Marimo만의 활용법을 보여줄 수 있는 거예요.
01:24:00그럼 꽤나 반응이 괜찮죠.
01:24:01그런 식으로 접근할 수도 있어요.
01:24:03결국 제가 조금이라도 흥미를 느끼면 일단 영상을 제작합니다.
01:24:10지금은 숏츠를 올리면 기본 3,000회, 일반 영상은 2,000회 이상 조회수가 나와요.
01:24:18대단한 수치는 아니지만, 2,000회면 최소 1,000명은 봤다는 뜻이잖아요.
01:24:21엄청난 일이죠.
01:24:231,000명에게 메시지를 전달하는 건 일상적인 경험이 아니니까요.
01:24:26가끔 1만 회를 찍는 영상도 있지만, 꾸준히 2,000회가 나와주는 것도 아주 만족스럽습니다.
01:24:32시청자의 “질”이 얼마나 중요한지도 고려해야죠.
01:24:37OpenAI가 인수했던 팟캐스트, TBPN인가 하는 거 기억하시나요?
01:24:42스포티파이 상위권 팟캐스트에 비하면 절대적인 조회수는 높지 않았어요.
01:24:47하지만 주요 청취자가 VC 투자자 같은 핵심 타깃층이었기 때문에 OpenAI가 높게 평가한 거죠.
01:24:56개발 관련 콘텐츠도 비슷해요.
01:24:58저희는 시작할 때부터 초급 개발자 눈높이에 맞춰 일일이 설명하지 말자는 원칙이 있었어요.
01:25:04지루하게 느낄 테니까요.
01:25:06시니어 개발자가 보는데 “패키지 설치법은 이렇습니다” 하고 있으면 곤란하죠.
01:25:11NPM 패키지 설치법 정도는 다들 알잖아요.
01:25:14거기에 30초, 1분씩 소비할 필요가 없어요.
01:25:17초급자용이라기보다는 상투적인 불필요 내용이죠.
01:25:19그렇겠네요.
01:25:20어쨌든 모든 것을 다 이해시키려고 영상에서 일일이 설명할 필요는 없다는 거예요.
01:25:28모든 개념을 나열하기보다는 우리 수준과 비슷한 시청자를 타깃으로 삼는 지향점이 있어요.
01:25:39핵심 개념은 당연히 설명하지만,
01:25:42지엽적인 주제로 빠지다 보면 영상이 20분으로 늘어지니까, 가급적 짧게 가져가려고 해요.
01:25:50시청 지속 시간도 고려해야죠.
01:25:52어느 정도 신경 써야 해요.
01:25:537~10분이 적당하고, 20분이 넘어가면 끝까지 보는 비율이 확 줄어들어요.
01:26:00지극히 맞는 말씀입니다.
01:26:01화면에 코드가 뜨는 순간 시청자가 이탈하는 현상도 있어요.
01:26:05코드가 나오자마자 이탈률이 치솟는데, 이건 어떻게 해결해야 할지 모르겠어요.
01:26:11제 경우엔 코드는 최소화하고 인터랙티브 위젯을 보여주는 편이에요.
01:26:16학술 논문을 다룰 때 전체 코드보다 움직이는 차트 하나가 훨씬 이해하기 쉽거든요.
01:26:26작동의 핵심이 되는 몇 줄의 코드만 잠깐 보여주며 원리를 설명하고, 나머지는 시각적 요소로 채우는 거죠.
01:26:35Marimo 채널에서는 그 방식이 잘 통하더라고요.
01:26:39다른 테크 유튜버들도 자주 토로하는 공통된 고충이죠.
01:26:43비유하자면 건강한 식단에 채소가 필요하듯, 코드도 일정 부분은 보여줘야 한다고 생각해요.
01:26:48테크 채널이라면서 리액션 영상만 주구장창 올린다면 그걸 테크 채널이라고 부를 수 있을까요?
01:26:56그저 아침 모닝쇼에 불과해지는 건 아닐지 고민이죠.
01:27:01결국 크리에이터로서의 열정 문제로 돌아옵니다.
01:27:06내가 만드는 영상에 스스로 만족하고 싶고, 그러려면 필요할 땐 코드를 정면으로 보여줘야 하죠.
01:27:13공감되는 말씀입니다.
01:27:15벌써 한 시간이 훌쩍 지났네요.
01:27:18시간이 어떻게 되시는지 모르겠지만...
01:27:21저는 더 이야기해도 괜찮지만, 조만간 마무리는 해야겠네요.
01:27:25많은 분들이 궁금해하실 만한 AI 주제를 조금만 더 짚고 넘어가고 싶어요.
01:27:34냉정히 돌아봤을 때, 다들 개발 실력이 퇴화(Skill Atrophy)하는 듯한 순간을 경험해보셨죠?
01:27:41아까 '애착'을 언급하셨는데, 이게 기술력의 퇴화일까요, 아니면 코드를 향한 애착이 줄어든 걸까요?
01:27:51그리고 이러한 변화가 바람직하다고 보시나요?
01:27:54단순한 호기심입니다.
01:27:55여러 사람에게 던져본 질문인데, 자바스크립트 개발자분들에겐 처음 물어보네요.
01:28:00흥미로운 질문이네요.
01:28:01솔직히 둘 다 해당한다고 생각해요.
01:28:04교과서적인 답변이지만, 최근 제 실력이 퇴화하고 있다는 느낌을 직접 받고 있거든요.
01:28:10한동안 AI 사용을 끊고 기본 개념을 다시 공부하면서, 예전에 알았던 지식이라도 확실히 복습해보는 시간을 가지려 해요.
01:28:24그리고 AI가 JS/TS 코딩을 워낙 잘해주다 보니, 토이 프로젝트용으로 자동 생성된 코드엔 애착이 잘 안 가더라고요.
01:28:34그래서 두 가지 측면이 다 있는 것 같아요.
01:28:35아까 말씀드렸듯, 깃허브 커밋조차 안 할 때도 있거든요.
01:28:38파일을 잃어버려도 바이브 코딩으로 금방 다시 복구할 수 있으니까요.
01:28:45코드에 대한 애착 저하와 실력 퇴화 모두 분명히 존재합니다.
01:28:49이야기를 들어보니, 다시 예전만큼 몰입하고 싶어 하시는군요.
01:28:52“예전엔 참 열정적이었는데” 하고 그리워하는 마음이 들게 만드는 무언가가 있는 거죠.
01:28:56분명히 그렇습니다.
01:28:57문제에 부딪히고, 코드로 풀어내고, 디버깅하는 일련의 과정이 즐거워서 개발을 시작했거든요.
01:29:10그런데 AI가 대량의 작업을 대신하면서 그 소소한 재미를 앗아간 측면이 있어요.
01:29:15반대로 생각하면, 기본적인 건 AI에 맡기고 이전엔 쉽게 엄두 못 내던 고난도 분야에 도전할 기회이기도 하죠.
01:29:24새로운 영역을 제대로 배울 단계가 된 것 같아요.
01:29:28예컨대 Rust 같은 언어를 정석대로 깊이 있게 공부해보고 싶거든요.
01:29:32채용 면접을 보면 리트코드 문제를 제시하고 일단 작동하게 작성하라고 한 뒤,
01:29:48순환 복잡도를 줄여서 최적화해보라고 요구하잖아요. 면접 준비할 땐 기를 쓰고 공부하지만, 막상 입사하면 “웹사이트나 구축합시다”로 귀결되곤 하죠.
01:30:04Claude가 짜준 코드의 최적화 수준에 대해 사람들은 고민이나 할까 싶어요.
01:30:13파고들어서 개선할 여지는 언제나 존재하거든요.
01:30:19아마존 같은 기업은 로딩 속도가 고객 유치에 직결되다 보니 성능에 사활을 걸죠.
01:30:29거기서 일해본 건 아니지만, 수많은 기업이 “일단 돌아가면 됐지” 하고 넘어가는 게 현실이에요.
01:30:36하지만 개인적으로는 최적화에 신경 써서 코드 완성도를 한 단계 끌어올리고 싶습니다.
01:30:46질문에 답이 되었는지 모르겠네요.
01:30:48Casey Muratori라는 유명한 개발자 겸 팟캐스터가 있는데요.
01:30:54아, 아까 말씀하신 그분인가요?
01:30:56대단한 분이죠.
01:30:56좋습니다.
01:30:57네, 맞아요.
01:30:58그분은 AI를 전혀 안 쓰는데, 코딩이라는 장인 정신 자체를 진심으로 즐기기 때문이에요.
01:31:03저 역시 James처럼 시스템 언어를 밑바닥부터 배우고 메모리 관리 메커니즘을 이해해보고 싶거든요.
01:31:14하지만 딱히 애착이 없는 작업은 AI로 바이브 코딩해서 머릿속의 구상을 빠르게 구현해 세상에 내놓는 걸 선호해요.
01:31:24그리고 기업의 관점이든, 아니면 일하는 직장에 따라서든, 제품에 관심이 없거나 개발 직무로 일하지만 코드 자체엔 별 관심이 없다면,
01:31:34AI는 정말 최고의 도구라고 생각해요. 빠르게 구현해서 기능을 마친 뒤, 케이크 만들기든 러닝이든 자신이 진짜 관심 있는 일로 넘어갈 수 있으니까요.
01:31:46결국 성향과 목적의 차이 같아요. 코딩 자체를 즐긴다면 AI를 멀리하는 게 맞고, 생산성이 목적이라면 AI만큼 훌륭한 조력자가 없죠.
01:31:59네, 흥미로운 관점입니다.
01:32:02파이썬 진영에서도 비슷한 말이 나와요. 특히 LLM이 데이터셋 분석은 기가 막히게 못 하거든요.
01:32:11데이터 분석은 인간의 주관적 통찰이 개입될 수밖에 없어서 자동화하기 어렵고, 잘못된 의사결정을 피하려면 사람의 판단이 필수적이니까요.
01:32:26말씀하신 사례는 파이썬의 주피터 노트북 작업보다는 자바스크립트 생태계의 특성이 크게 반영된 것 같아요.
01:32:35물론 PyCharm을 주로 쓰는 파이썬 웹 개발자들도 비슷한 고민을 하긴 합니다.
01:32:40여기서 '분석'이란 데이터 전처리나 이상치 제거 같은 작업을 의미하나요?
01:32:47그것도 일부분이죠.
01:32:49가령 LLM이 감정 분석을 마쳤다고 할 때, 그 결과를 토대로 마케팅 전략을 세운다면,
01:32:56잘못된 판단을 방지하기 위해 LLM의 결과에 얼마나 동의하는지 직접 교검해보게 되죠.
01:33:02그런 맥락입니다.
01:33:05마무리하기 전에 흥미로운 사례를 하나 들려드릴게요. 혹시 '고릴라 데이터셋'에 대해 들어보셨나요?
01:33:13고릴라 실험 영상 말씀이신가요?
01:33:14아, 고릴라가 지나가는데 아무도 눈치채지 못하는 그 영상이요?
01:33:18네, 영상 시작할 때 패스되는 공의 횟수를 세라고 하잖아요.
01:33:22공에만 집중하다가 영상이 끝난 뒤,
01:33:25“지나가는 고릴라를 보셨나요?” 하고 묻죠.
01:33:29그럼 다들 공 세느라 못 봤다고 해요.
01:33:30고릴라가 있었냐면서요.
01:33:31네?
01:33:32다시 돌려보면 고릴라 옷을 입은 사람이 대놓고 지나가는데 말이죠.
01:33:38핵심은 특정 요소에 과도하게 집중하면 주위의 명확한 현상조차 놓칠 수 있다는 점입니다.
01:33:45이 원리를 데이터로 검증한 이탈리아 연구진의 데이터셋이 있어요.
01:33:50A그룹에는 특정 가설을 검증하라는 과제를 주었죠.
01:33:54BMI, 하루 걸음 수, 성별 등의 변수 간 상관관계를 가설 검정으로 확인하라고 한 거예요.
01:34:02반면 B그룹에는 아무런 지침 없이,
01:34:04“데이터셋에서 유의미한 걸 찾아보라”고만 했습니다.
01:34:07그런데 걸음 수, BMI, 성별로 그래프를 그리면 손을 흔드는 고릴라 형상이 나타나도록 설계되어 있었어요.
01:34:14과연 어느 그룹이 숨겨진 고릴라를 더 잘 찾아냈을까요?
01:34:18정답은 지침이 없던 B그룹이었습니다. 가설에 얽매이지 않고 시각화부터 해봤으니까요.
01:34:24가설 검증 그룹은 기계적으로 수치 계산만 하고 끝내버렸죠.
01:34:30그렇군요.
01:34:31이 데이터를 LLM에게 주면 어떻게 될까요?
01:34:33어떻게 될까요?
01:34:35과연 찾아낼까요?
01:34:37제가 테스트해 본 결과, 매번 실패했습니다.
01:34:41단순 상관관계 수치만 보고할 뿐이었죠.
01:34:42심지어 차트 캡처본을 보여주며 “고릴라가 보이냐”고 물어도,
01:34:48“변수 간 상관관계를 비유적으로 표현하신 것이냐”며 엉뚱한 소리를 하더라고요.
01:34:52자주 발생하는 현상입니다.
01:34:55이처럼 데이터의 맥락을 도메인 지식으로 해석하는 직무나 노트북 환경의 가치는 여전히 유효합니다.
01:35:06잘못 판단했다간 치명적인 결과로 이어지니까요.
01:35:08추천 알고리즘이 망가지거나 국세청에 부가세를 잘못 신고하는 참사가 벌어질 수 있죠.
01:35:16여전히 LLM은 데이터 속 '고릴라'를 찾는 데 쥐약입니다.
01:35:20충분히 그럴 만하네요.
01:35:23오늘 대화는 여기서 마무리를 지으면 되겠네요.
01:35:25예상치 못한 방향이었지만 재미있는 일화들과 알찬 내용이 많았습니다.
01:35:33마지막으로 홍보하고 싶으신 것이 있나요?
01:35:36키보드 리뷰나 제 관심사를 다루는 Column Code 유튜브 채널을 방문해 주세요.
01:35:43요즘은 수학 관련 콘텐츠도 하고 있습니다.
01:35:45Marimo도 꼭 체크해 보시고요.
01:35:46JS 개발자가 파이썬을 배울 때 Marimo만큼 재미있는 도구도 없을 겁니다.
01:35:51그리고 무엇보다, 다들 모니터만 보지 말고 야외 활동 좀 하세요.
01:35:55아멘.
01:35:55토큰 소비량에 연연하기보다 풍요로운 삶을 사시길 바랍니다.
01:36:01꼭 필요한 자세죠.
01:36:04BetterSat 팟캐스트를 청취해 주셔서 감사합니다.
01:36:07선호하시는 오디오 플랫폼에서 만나보실 수 있습니다.
01:36:09Apple 팟캐스트, Spotify 등 어디서나 이용 가능합니다.
01:36:12그럼 여기서 인사드릴게요.
01:36:14안녕히 계세요.
01:36:15저도 이만 인사드립니다.
01:36:16감사합니다.