AI가 일자리를 뺏기 전에 개발자직을 그만둔 이유 | Better Stack 팟캐스트 16화
BBetter Stack
Computing/SoftwareSmall Business/StartupsAdult Education
Transcript
00:00:00Better Start 팟캐스트에 오신 것을 환영합니다. 여기서는 AI, 소프트웨어, 개발,
00:00:04그리고 각종 새로운 기술에 대해 이야기합니다. 저는 진행자 중 한 명인 리처드이고, 함께하는 분은...
00:00:09저는 제임스입니다.
00:00:10저는 안드레스입니다.
00:00:11그리고 저는 엘리엇입니다.
00:00:13함께해 주셔서 감사합니다, 엘리엇. 오프라인에서 언급하셨듯이, 저희 중 많은 사람이
00:00:18당신의 두 유튜브 채널, 즉 Dreams of Code와 Dreams of
00:00:22Autonomy의 열렬한 팬입니다. 네, 팟캐스트에서 더 자세히 다루겠지만요. 하지만 듣고 계신 분들 중
00:00:27아직 잘 모르시는 분들을 위해 직접 소개해 주시겠어요?
00:00:30네. 좋습니다. 제 이름은 엘리엇입니다. 리처드가 언급했듯이 유튜브 채널 두 개를 운영하고 있죠.
00:00:37유튜브를 시작한 지는 3년 정도 됐네요. 하지만 원래 저는
00:00:42소프트웨어 개발자였습니다. 2012년부터 전문 소프트웨어 개발자로 일해왔고,
00:00:472007년에 처음 배우기 시작해서 대학에서 컴퓨터 과학을 전공했습니다. 처음 접했을 때부터
00:00:52완전한 제 열정이었습니다. 그래서 자연스럽게 지금은 소프트웨어 개발에 관한
00:00:57영상을 만들고 있습니다.
00:00:59좋네요. 당신의 영상은 어느 정도 프라이머젠과 비슷하다고 볼 수 있는데,
00:01:06터미널 도구에 집중하시니까요. 혹시 항상 NeoVim 같은 터미널 사용자가
00:01:10아니면 점차 그쪽으로 빠져들게 된 건가요?
00:01:13네. 대학 시절 컴파일러 작성 수업을 들었는데요. 그 모듈의 필수 조건 중 하나가
00:01:21Vim을 사용하여 Unix 환경에 SSH로 접속하는 것이었습니다. 그러니까 컴파일러를 C++로 작성해야 할 뿐만 아니라
00:01:28Vim도 사용해야 하는 상황이었죠. 저를 포함한 많은 사람들이 일종의 스톡홀름 증후군을 통해
00:01:34Vim을 사랑하게 된 것 같습니다.
00:01:40그렇게 Vim을 배웠습니다. 그때는 여전히 IDE를 사용하고 있었지만 수업 덕분에 Vim을 경험할 수 있었죠.
00:01:48그리고 제 첫 직장도 Unix 박스에 SSH로 접속하는 금융권 일이었는데,
00:01:54거기서도 C++ 환경에서 Vim을 사용했습니다. 그렇게 자연스럽게 계속 사용하게 되었고,
00:02:01이후로는 거의 Vim에서 작업했습니다. 뭐든지 다 할 수 있는 에디터였으니까요. 한때는
00:02:06애플 도구 때문에 Xcode를 사용한 적도 있지만, 그 외에는 거의 Vim이었죠.
00:02:11요즘 유튜브에서도 Vim에 대해 이야기하는 사람들이 늘면서 일종의 르네상스가 일어난 것 같아요.
00:02:17네, 맞아요. Primogen의 영향이 정말 컸죠. 많은 사람들이
00:02:21NeoVim 같은 도구에 관심을 갖게 만들었으니까요. 하지만 이전부터 이런 도구를 즐겨 사용하던
00:02:27집단이 항상 존재했습니다. 제가 유튜브를 시작하기 전, 프로그래밍 관련 영상을 보기 전에도
00:02:32온라인상에서 도구에 대해 이야기하는 사람들은 늘 있었거든요.
00:02:35그래서 NeoVim이나 Emacs에는 항상 마니아층이 있었죠.
00:02:41Emacs도 써봤는데 저는 그렇게 잘 맞지는 않더라고요.
00:02:46네, 아실지 모르겠지만 지난 에피소드에 출연했던 Bash Bunny는
00:02:51Doom Emacs의 열렬한 팬이었죠. NeoVim 사용자였다가 org mode 때문에 Doom Emacs로 넘어갔는데,
00:02:57저는 아직 안 해봤지만 정말 만족하는 것 같더라고요.
00:03:00Org mode는 정말 환상적이죠. 그만한 게 없어요.
00:03:08저도 Emacs를 다룰 때 제 Emacs init.el(설정 파일) 전체를
00:03:15org mode로 작성했었습니다. 마치 문서처럼 만들고,
00:03:20저장할 때마다 코드 블록이 실제 파일로 변환되도록 만들 수 있거든요.
00:03:26정말 놀라운 기능이죠. 그런 게 가능한 건 오직
00:03:30Elisp 덕분이겠죠. 저도 인정하자면 저는 Vim이나 NeoVim 팬은 아니었는데,
00:03:35최근 AI, 특히 Claude Code가 제 코드를 많이 작성해 주면서 관심이 생기기 시작했습니다.
00:03:40이제 Cursor나 다른 도구들은 너무 AI 기능으로 가득 차서 열기가 싫어요.
00:03:46저는 터미널에서 Claude Code와 Codex를 쓰는데,
00:03:50그저 코드를 읽고 싶을 뿐인데 AI 기능이 계속 눈앞에 나타나는 게 짜증 나거든요.
00:03:55사소한 수정 하나 하려는데 탭 자동 완성이 계속 뜨고요.
00:03:59Cursor는 마치 자기가 팔고 싶은 모든 기능을 저한테 강요하는 느낌이에요.
00:04:03저는 그냥 코드를 읽고 한 줄 수정하고 싶은 건데 말이죠.
00:04:07그래서 조금씩 갈아타고 있는데, 정말 공감합니다.
00:04:12터미널에서 작업하면 터미널 내에서 모든 걸 해결하는 게 편하죠.
00:04:17요즘 NeoVim을 정말 좋아하는 이유가 AI 자동 완성 같은 게 없어서예요.
00:04:22순수하게 코드를 읽고, 탐색하고, 필요할 때 수정하는 용도로만 쓰니까요.
00:04:25좋네요. 당신이 만드는 다른 콘텐츠들은 CLI 도구에 집중되어 있던데요.
00:04:30Zeoxide도 당신 영상을 보고 알았어요.
00:04:33croc이나 본사이 도구처럼 독특한 도구들도 많이 소개하시던데,
00:04:38어떻게 그런 도구들을 찾으시나요? 또 특정 도구에 빠지게 되는 계기가 있나요?
00:04:44어떻게 찾냐고요? 좋은 질문입니다. 주로 온라인 포럼을 자주 뒤져요.
00:04:49사람들이 뭘 쓰는지 보고 제 문제를 해결해 줄 만한 걸 찾죠. Zeoxide는
00:04:55터미널 내비게이션이 늘 고통스러웠기 때문에 정말 대단한 도구였어요.
00:05:01한번 맛보면 절대 이전으로 돌아갈 수 없죠. 독특한 도구들은 좀 더 찾기 힘들어서
00:05:06깊이 있는 리서치가 필요했어요. 대중적인 CLI 도구는 이미 다들 아니까,
00:05:12조금 더 깊게 파고들고 싶었거든요. GitHub에서 CLI 도구를 검색하면
00:05:18괜찮은 추천들을 많이 찾을 수 있습니다.
00:05:23저도 Zeoxide의 광팬입니다. 정말 동감해요. 다른 머신을 쓰는데
00:05:28Zeoxide가 안 깔려 있으면 CD 명령어가 너무 느리고 불편하게 느껴지죠.
00:05:32그래서 그런 것들을 찾는 데 많은 조사가 필요했죠. 하지만 GitHub 스타를 보면,
00:05:38GitHub에서 CLI 도구를 검색할 수 있잖아요. 보통 그 안에서 좋은 추천 도구들을
00:05:43네. 사실 최근에 Go에서 Next.js로 변경했는데,
00:05:47처음에는 Go로 시작하는 게 좋은 경험이 될 것 같았어요.
00:05:51당시 HTMX가 엄청 유행했거든요. 대규모 프로젝트에 써볼 만한지 확인하고 싶었죠.
00:05:55결과는 반반이었어요. 물론 가능은 하지만 현대적인 웹 경험을
00:06:00구현하려고 하면 꽤 까다로워지더라고요. Go는 Temple 같은 패키지 덕분에
00:06:06컴포넌트 기반 뷰 로직을 만드는 데 아주 적합해요. React와는 또 다른 맛이 있죠.
00:06:12HTMX와 하이퍼미디어 방식을 결합하면 서버에서 가져오기 아주 좋지만,
00:06:20클라이언트 사이드의 복잡한 인터랙션이 필요해지면 한계가 보입니다.
00:06:26Alpine JS도 훌륭하지만, 결국 복잡해지면 바닐라 JS를 계속
00:06:32분명 가능은 하지만, 더 현대적인 웹 환경을 구현하고 싶다면
00:06:39어려워지기 시작한다는 걸 알게 됐죠. Go는 사실 그런 작업에 매우 적합한데,
00:06:45구체적으로 document.selectElement 같은 작업을 말하시는 건가요?
00:06:51네, 그런 것도 있고 자바스크립트 코드를 적절히 구조화하는 문제도 있죠.
00:06:56프레임워크 없이 스크립트를 직접 가져와서 쓰려니 함정이 너무 많았어요.
00:07:02심지어 jQuery까지 고려할 정도로요.
00:07:06그 PHP Laravel 하는 친구가 만든 Alpine Ajax라고,
00:07:12HTMX랑 비슷한 게 있는데 들어보셨나요? 네, 고려해 봤지만 결국
00:07:18에이전트 시대가 오면서 Next.js로 완전히 갈아탔습니다.
00:07:22Claude Code를 좀 일찍 접했는데 고 사이트를 순식간에 Next.js로
00:07:28바꿔주는 걸 보고 바로 전환했죠.
00:07:35유튜버로서 수익화를 위해 코스 플랫폼을 만든 건데,
00:07:40홍보하고 고객을 모으는 게 어떠셨나요?
00:07:45솔직히 말씀드리면 저는 마케팅을 거의 안 해서 그게 큰 결점이었어요.
00:07:50제품 개발이 절반이라면 마케팅은 나머지 절반이니까요.
00:07:57있어서 Alpine Ajax 같은 건데, 들어보셨는지 모르겠네요.
00:08:03네, 네, Alpine Ajax요. 사실 Alpine 생태계 안에서
00:08:08모든 걸 해결하면 좋을 것 같아서 도입을 고려했었거든요.
00:08:13Alpine Ajax는 정말 멋져 보였죠. 결국 Next.js로 재작성했는데,
00:08:19그래서 코스 플랫폼을 만든 건데 나쁘지 않은 수익을 냈습니다.
00:08:24전업으로 삼기엔 부족했지만요. 지금은 AI 때문에
00:08:29코딩 학습 방식 자체가 많이 바뀌었고, 제가 워낙 마케팅을 못 해서 말이죠.
00:08:36요즘 유튜버들은 스폰서십으로 수익을 많이 챙기는데,
00:08:41사실 그것보다 코스 플랫폼은 이제 좀 시들해진 느낌인가요?
00:08:47판매는 여전히 되고 있지만 예전 같지는 않아요.
00:08:52특히 에이전트 도구들이 등장한 이후로 학습 수요가 팍 꺾인 게 느껴집니다.
00:08:58사람들이 스스로 배우려 하지 않게 되었죠.
00:08:59다른 코딩 튜토리얼 채널들도 마찬가지일 겁니다.
00:09:06AI가 다 해주는데 굳이 공부할 필요를 못 느끼는 것 같아요.
00:09:11저는 그래도 학습은 중요하다고 생각합니다.
00:09:17지금 Rust 책을 다시 읽고 있는 이유도 그렇고요.
00:09:23근본적인 원리를 아는 건 여전히 가치가 있습니다.
00:09:27맞습니다. AI는 기본 앱 정도는 만들 수 있지만,
00:09:33규모를 키우고 최적화하려면 결국 깊이 있는 지식이 필요하니까요.
00:09:38정말 딜레마네요. 이제 막 시작하는 사람들에게 어떻게 학습을 유도해야 할지,
00:09:44Zig 언어를 배워볼까 하는데 Claude에게 물어보면 바로 코드를 다 짜주겠지만,
00:09:51그럼 이걸 어떻게 비즈니스로 연결할까요? 유튜브에 관해서는 당신 말이 맞는 것 같아요.
00:09:54애드센스로 수익을 내기에는 유튜브 자체가 아주 형편없거든요. 제 애드센스 수익은
00:10:00잘 모르는 분야를 AI에게 배우는 건 위험해요.
00:10:07그 오류를 사실이라고 믿게 될 테니까요.
00:10:15Rust 학습은 어떻게 하고 계신가요? 자동 완성 다 끄고 하시나요?
00:10:21둘 다 섞어서 하고 있어요. 예전에 써봤는데 Go로 넘어가서 한동안 안 썼거든요.
00:10:28Rust는 코드가 예쁘게 나오지 않아서 유튜브로 설명하기가 힘들어서요.
00:10:32그래서 Go를 주로 썼죠. 다시 Rust를 배우는 중인데
00:10:38요즘 크리에이터들이 돈을 버는 가장 큰 방법은 스폰서십이잖아요? 스폰서십 세 건 정도면 코스 판매보다
00:10:45더 많은 수익을 냈을 것 같아요. 이제 코스 판매는 시들해졌다고 보시나요? 사람들이 더 이상 프로그래밍 언어를
00:10:51Rustonomicon도 읽고 싶은데 너무 어렵다는 소문이 있어서 걱정이에요.
00:10:59하지만 비교해 보면, 제가 해당 플랫폼에 대해 예전만큼 많이 언급하지 않아서 정확히는 모르겠네요.
00:11:05여전히 링크 같은 걸로 홍보를 조금씩 하긴 하지만, 확실히 하락세는 있어요. 그 시점이 언제인지도 알 수 있죠. 바로
00:11:13하지만 미디어 렌더링 같은 복잡한 부분에서 AI는 엉망이더군요.
00:11:21근본적인 해결책이 아니라 당장 돌아가게만 만드는 코드를 짜주니까요.
00:11:27Web Dev Simplified도 최근에 AI가 등장한 이후로 조회수가 줄었다는 영상을 올렸죠. 콘텐츠의 상당 부분이 튜토리얼 기반이었으니까요. 네, 사람들은 AI가 대신 코드를 짜주니까 이제 굳이 배우려 하지 않는 것 같아요.
00:11:39참 흥미로운 딜레마예요. 전 배움이 여전히 정말 중요하다고 생각하거든요. 동시에 사람들이 시간 낭비라고 느끼는 것도 이해가 가요. 생각이 참 많지만, 뭐가 정답인지는 잘 모르겠네요. 저는 요즘 Rust 책을 다시 보면서 복습하고 있어요. 여전히 학습이 꽤 중요하다고 생각하거든요. AI에 대해서는 대부분의 사람들처럼 저도 의견이 반반이지만,
00:12:09결국 배움은 여전히 중요해요. 당장은 AI가 모든 걸 다 해주는 것처럼 보여서 결과가 매우 추상적으로 느껴질지라도, 기본적인 이해와 지식을 갖추는 것은 분명 가치 있는 일이라고 생각합니다.
00:12:24네, 제 생각에 AI는 딱 거기까지만 도와줄 수 있어요. 사용자 한 명이 쓸 만한 간단한 앱은 만들 수 있겠지만, 확장을 시작하고 최적화를 해야 하는 순간이 오면 결국 근본적인 지식과 새로 익히는 지식이 필요할 거예요.
00:12:38FFI로 Objective-C 코드를 훅해서 쓰는데 아주 안전하고 좋아요.
00:12:39정말 어려운 상황이죠. AI가 코드를 대신 다 작성해주면 초보자들은 어떻게 배워야 할까요? 사람들에게 어떻게 학습을 장려해야 할지도 모르겠고요. 요즘 사람들이 어떻게 하는지 잘 모르겠어요. 저는 시스템 언어를 전혀 모르거든요. Rust는 좀 건드려봤지만 잘은 몰라요. 사람들이 좋다고 하니 Zig를 한번 시도해볼까 싶기도 하고요. 그래서 생각해본 게, Zig 유튜브 강의를 보거나 아니면 클로드(Claude)에게 Zig를 가르쳐달라고 할 수 있겠죠.
00:13:07클로드가 좀 더 빨리 가르쳐주긴 하겠지만, 결국 코드를 대신 다 짜줄 테니까 저는 아무것도 배우지 못할 거예요. 정말 난감한 상황이죠. 사람들이 앞으로 어떻게 할지 모르겠네요.
00:13:16배포 관련 라이선스 문제가 좀 복잡하죠.
00:13:19상업용 소프트웨어라면 LGPL 버전을 연결해야 하니까요.
00:13:36이런 지식은 예전 C++ 작업 경험과 유튜브 하면서 얻은 경험 덕분에 알게 됐죠.
00:13:49둘 다 조금씩 하고 있어요. 예전에는 Rust를 꽤 썼었는데, 언어 선택에 대한 결정 피로를 줄이려고 Go로 넘어갔었거든요.
00:14:02Rust를 정말 좋아하지만, 코드가 예쁘게 보이는 언어는 아니에요. 보기 좋은 코드를 짜기가 더 어렵죠. 유튜브에서는 개념을 설명할 때 코드가 읽기 쉽고 이해하기 편해야 하거든요.
00:14:18그래서 Go 쪽으로 더 옮기게 됐고, 덕분에 시청자들도 내용을 더 잘 이해할 수 있었던 것 같아요. 예전에 Rust로 코드를 작성하면 이해하기 어렵다는 댓글이 자주 달렸거든요.
00:14:31그래서 지금은 Rust를 다시 배우는 셈인데, 완전히 밑바닥부터 시작하는 건 아니에요. 예전에 익혔던 기술들을 되살려서 적용하고 있는 거죠.
00:14:47그래도 다시 초심자의 마음으로 해보려고 해요. 밤마다 '러스트 공식 책'을 읽고 있는데, 이미 아는 내용은 건너뛰면서 보고 있습니다.
00:14:56생태계가 커지면 개선될 문제니까요.
00:15:01앞으로 Rust 전문 콘텐츠를 더 많이 보게 되겠네요.
00:15:04네, 기대해 주세요.
00:15:05웹사이트에 있는 건데, 다들 아는 메인 책이에요. 노 스타치 프레스(No Starch Press)에서 나온 거죠.
00:15:13“The Rust Programming Language”가 공식 제목이에요. 하지만 다들 그냥 '러스트 북'이라고 부르죠. 그래서 그걸 다시 보고 있는데, 기초 지식이라 문법을 배우는 데 좋아요. '러스트노미콘(Rustonomicon)'도 정말 읽고 싶은데, 그게 끝판왕이죠.
00:15:25그건 읽기가 아주 어렵기로 악명 높거든요. 프로젝트는 지금 러스트로 비디오 편집 애플리케이션을 만들고 있어요. 크로스 플랫폼 네이티브 앱이고 러스트 프레임워크를 많이 쓰는데 아주 멋지죠.
00:15:40AI에 의존을 많이 하고 있어요. 주로 여기 문서가 엉망이라 '이걸로 어떻게 구현하지?' 싶을 때요. AI는 코드를 살펴보고 정보를 뽑아내는 데 정말 뛰어나거든요.
00:15:51러스트의 새로운 크로스 플랫폼 프레임워크들은 문서화가 정말 형편없어요. 그래서 AI한테 예제 코드를 받아서 직접 구현하는 게 훨씬 쉬워요.
00:16:02처음엔 AI에 좀 과하게 의존했어요. 미디어 렌더링이나 비디오 편집 같은 경우, 타임라인 컴포지터나 렌더링 같은 복잡한 과정들이 있거든요.
00:16:14근데 그런 데 AI를 쓰니까 결과가 정말 최악이었어요. 아까 제임스가 말한 거랑 같은 맥락인데, 간단한 건 잘하지만 좀 비범한 영역으로 넘어가면 코드를 이상하게 최적화해요.
00:16:26항상 느끼는 건데, AI는 근본적인 원인을 해결하기보다 증상만 고치려 해요. 그냥 작동만 하게 만들 뿐, 나중에 확장해서 쓸 수 있을 만큼 견고하게 만들지는 못해요.
00:16:38이 프로젝트를 하면서 많이 느꼈죠. 작동은 하는데 미디어 파이프라인이 아예 없는 수준이었어요. 기본 API로 비디오 파일 재생만 되는 정도였죠.
00:16:49그래서 편집 기능을 넣으려고 건너뛰기를 하거나 파일을 여러 개 추가하면 금방 망가져 버리더라고요.
00:16:55그래서 AI가 짜준 코드를 가져와서 제대로 고치는 게 공부의 대부분이었죠.
00:17:01와, 비디오 편집기는 AI 도움을 받아도 쉬운 작업이 아닐 텐데. 나라면 직접 시도도 못 했을 것 같아요.
00:17:08조만간 다시 초대하겠습니다.
00:17:10영상 편집기에서 다양한 코덱은 어떻게 처리하고 계신가요?
00:17:15음, 그건 플랫폼에 따라 다르게 처리하고 있습니다.
00:17:20애플에는 AV Foundation이라는 기본 오디오/비디오 미디어 툴킷이 있어요.
00:17:27AV Foundation은 정말 훌륭하고 다양한 코덱을 지원합니다.
00:17:31그래서 미디어 엔진에 디코더 모듈을 따로 만들어 두고 디코더를 바꿔가며 쓰고 있죠.
00:17:37macOS에서는 AV Foundation을 사용하는데, Rust 덕분에 FFI를 쓸 수 있습니다.
00:17:42Objective-C 코드와 연동하는 건데, Unsafe Rust이긴 해도 꽤 안전한 편이에요.
00:17:48윈도우와 리눅스는 좀 더 까다로운데, 윈도우의 미디어 파운데이션은 성능은 괜찮지만 AV Foundation만큼 코덱을 다양하게 지원하진 않거든요.
00:18:03...
00:18:04그래서 그 대신에, 이건 제가 AI를 다루면서 실제로 겪었던 문제 중 하나인데,
00:18:09AI가 디코더와 인코더 등을 쉽게 교체할 수 있는 방식으로 코드를 짜주지 않았거든요.
00:18:14그냥 이렇게 툭 던져줬죠.
00:18:15그냥 미디어 파운데이션으로 해결하라고 했는데, 그게 안 되는 경우가 많았어요.
00:18:19그래서 리눅스와 윈도우에서는 상황에 따라 교체할 수 있게 했죠. 윈도우는 지원 범위가 더 넓지만, 리눅스는 사실상 표준인 GStreamer를 사용합니다.
00:18:29FFmpeg과 연결되는데, 리눅스에서는 일부 코덱이 GPL 라이선스라 FFmpeg을 배포하기가 쉽죠.
00:18:36그래서 애플리케이션 안에 번들로 포함할 순 없지만, 패키지 매니저를 통해 바이너리를 설치할 때 같이 설치되도록 할 수 있습니다.
00:18:44아, 제가 너무 횡설수설하면 중간에 끊어주세요.
00:18:47...
00:18:48하지만 윈도우에서는 FFmpeg이 GPL 라이선스라 그대로 배포할 수 없어서 좀 까다롭습니다.
00:18:53링크해서 쓸 수 있는 LGPL 버전만 배포할 수 있죠.
00:18:56그래서 Media Foundation과 FFmpeg을 동시에 활용하면서 서로 다른 코덱을 지원하도록 구현해야 합니다.
00:19:03주로 H.264나 H.265 인코딩 문제라고 생각하는데, 너무 기술적인 깊은 내용으로 들어가는 것 같네요.
00:19:12아니요, 아주 좋습니다.
00:19:13말씀 감사합니다.
00:19:15Kiru를 만들기 전부터 이런 내용을 다 알고 계셨던 건가요?
00:19:18...
00:19:19...
00:19:20유튜브 같은 영상 쪽 일을 하면서 어느 정도는 알게 되었죠.
00:19:25다양한 코덱이나 그런 것들을 접하게 되니까요.
00:19:27예전에는 C++도 꽤 많이 다뤘었고요.
00:19:30그래서 렌더링이나 GPU 같은 것들에 대해 이해하고 있었죠.
00:19:32하지만 미디어 파이프라인 같은 경우에는 프로젝트를 직접 만들면서 습득한 것 같아요.
00:19:39네, 그냥 FFmpeg로 다 해결할 수 있을 줄 알았거든요.
00:19:42그런데 운영체제마다 사정이 다른가 보네요.
00:19:45네, FFmpeg로 모든 걸 할 수는 있죠.
00:19:48하지만 까다로운 부분이 있습니다.
00:19:50거기에 FFmpeg 라이선스 문제도 있고요.
00:19:53그래서, 네.
00:19:54취미 프로젝트라면 괜찮겠지만 상용 애플리케이션은 좀 힘들죠.
00:19:58...
00:19:59GPL 라이선스를 따르지 않으려 한다면 말이죠. 전 GPL을 원치 않았거든요.
00:20:02오프라인에서 잠깐 언급하긴 했지만, 영상에서 앞으로 Rust에 전념하겠다고 하셨죠. 대부분의 영상이 Go에 관한 것들이었는데 말이에요.
00:20:13Rust로 넘어가게 된 이유를 좀 설명해 주실 수 있나요?
00:20:16네, 아주 좋은 질문입니다.
00:20:18저는 2026년에 Rust의 미래를 굉장히 밝게 보고 있습니다.
00:20:23더 많은 기업이 Rust를 도입하게 될 거라 생각해요.
00:20:27과거에는 도입 속도가 다소 더뎠던 게 사실이죠.
00:20:29항상 그런 밈이 있잖아요, 맞죠?
00:20:31Rust로 일자리를 구하는 게 언어 자체를 배우는 것보다 더 어렵다는 이야기요.
00:20:35과거에는 암호화폐 기업 말고는 Rust 개발자를 채용하는 곳이 거의 없었으니까요. 대부분 개발자는 암호화폐 업계를 선호하지 않고요.
00:20:41산업계에서 Rust를 사용하는 또 다른 경우는, 보통 이미 회사에 자리를 잡은 개발자가 Rust 개발자를 새로 채용하기보다는 본인이 직접 Rust 사용을 제안하는 경우였죠.
00:20:54그래서 유튜버로서 Rust를 교육적인 관점에서 다루기가 항상 매우 어려웠습니다. 취업으로 이어질 기회가 별로 없었으니까요.
00:21:02이제는 상황이 바뀔 겁니다. AI, LLM, 에이전트 기반 엔지니어링을 받아들이는 기업들이 늘어나면서, 불안정성이라는 문제점을 깨닫고 있기 때문이죠.
00:21:12고전적인 프로젝트 관리 삼각형 있잖아요. 싸고 빠르고, 안정적이고 품질 좋은... 뭐 그런 거요.
00:21:22지금은 비용과 속도에만 치중하느라 안정성을 희생하고 있는 상황입니다.
00:21:26많은 개발자가 이제 다시 본질로 돌아가려 노력하고 있다고 봅니다.
00:21:30Rust가 그 해결책 중 하나가 될 거고요.
00:21:34올바르게 작성된 Rust 코드는 잠재적인 버그를 크게 줄여주니까요.
00:21:38그래서 더 많은 기업이 Rust로 이동하고 있습니다.
00:21:40Bun이 100만 줄의 코드를 재작성한 사례도 있었죠. 결과가 어떻게 될지 지켜봐야겠네요.
00:21:46그건 참 논란이 많을 것 같네요.
00:21:48맞아요, 흥미로운 실험인데 결과가 어떨지 궁금합니다.
00:21:52PNPM도 Rust로 이동하고 있죠.
00:21:54방금 메인 브랜치에 코드를 통합했더군요.
00:21:56아마 두 버전을 당분간 병행 유지할 생각인 것 같습니다.
00:21:58Ladybird 브라우저도 최근 C++ 코드를 Rust로 대거 포팅했고요.
00:22:04이런 흐름은 점점 더 가속화될 겁니다. 제가 Rust에 대해 긍정적인 이유이기도 하죠.
00:22:10물론 저 개인적으로도 Rust를 정말 좋아합니다.
00:22:12Rust는 한 3~4개 정도 되는, 어떤 언어라고 할까...
00:22:14제 생각엔 거의 모든 걸 만들 수 있는, 한계가 없는 언어들 중 하나라고 봅니다.
00:22:18그래서 저에겐 늘 흥미로운 주제였죠.
00:22:20이제 Rust가 사용될 프로젝트들이 많아질 테니 지금 배우는 건 정말 좋은 선택이 될 겁니다.
00:22:27저도 동의합니다.
00:22:28컴파일 속도가 느리다거나 지나치게 까다롭다는 지적도 더러 들었거든요.
00:22:36하지만 AI가 코드를 작성하는 시대라면, 그런 검사는 사람이 아니라 모델이 해주니까 오히려 말이 되는 상황 같아요.
00:22:44그나저나 Rust를 포함해 그 '한계가 없는' 언어 4가지는 나머지 3개가 무엇인지도 궁금하네요.
00:22:50네, 맞아요. 생각해보죠.
00:22:51나머지 세 가지를 꼽아보자면.
00:22:52일단 C는 당연히 들어가야죠. 못 하는 게 없으니까요.
00:22:56아마 한계가 없는 언어의 원조 격 아닐까요.
00:23:00Zig도 들어갑니다. 물론 Zig는 아직 언어로서 매우 초기 단계라는 문제가 있긴 해요.
00:23:07변화가 워낙 심하죠.
00:23:08지난 버전 문서대로 'Hello World'를 찍어보려 해도 최신인 0.16 버전에서는 작동하지 않는 경우가 많아서, 배우기가 꽤 어렵고 도전적인 언어예요.
00:23:19그 고비를 넘기면 언어의 가치를 확실히 느낄 수 있죠.
00:23:22Zig는 C와의 상호운용성이 정말 대단하다는 큰 장점이 있습니다.
00:23:27FFI를 좋아한다면 그보다 환상적인 언어는 없죠.
00:23:31세 번째는 당연히 Rust고요.
00:23:34마지막 네 번째는 C++입니다.
00:23:35C++ 역시 한계가 없는 언어죠.
00:23:37정말 뭐든지 다 할 수 있으니까요.
00:23:39제가 커리어 대부분을 C++과 함께했기 때문에 사심이 좀 들어갔을 수도 있습니다.
00:23:44그래서 저는 C++을 정말 좋아해요.
00:23:46다들 좋아하진 않지만 말이죠.
00:23:48어글리한 부분도 많지만, 동시에 모든 걸 해낼 수 있는 힘이 있죠.
00:23:52어떤 사람들은 C와 C++을 그냥 같은 선상에 두기도 하더군요.
00:23:56그냥 한 단계 발전한 정도라고 보니까요.
00:24:01Zig 얘기가 나와서 말인데, Bun 팀이 Rust로 옮겨간 이유 중 하나도 언어가 너무 새롭다는 점 때문이었던 것 같아요.
00:24:07그들이 직접 Zig 프로젝트에 PR을 많이 보냈더라고요. 버그를 고치려고요.
00:24:11사람들이 Bun이 자꾸 죽는다고 불평하면, 결국 그게 Zig의 버그였다는 걸 깨닫게 되는 식이었으니까요.
00:24:16그래서 Rust로 옮긴 거겠죠. 그렇게 크래시를 줄이려는 시도인 겁니다.
00:24:22OpenCode도 Bun 기반이다 보니 크래시가 꽤 있었는데, 파고들어 보면 Zig 문제인 경우가 많았고요.
00:24:28그래서 이번 재작성이 어떻게 끝날지 정말 궁금합니다.
00:24:31저도요.
00:24:32흥미로운 지점이죠.
00:24:34제가 하려는 재작성 방식과는 다르지만, 과학적인 실험 차원에서 가능성을 타진해 보는 건 의미가 있어 보여요.
00:24:42지켜보는 입장에선 정말 흥미롭네요.
00:24:45Bun에 의존하는 하위 프로젝트들이 많아서 논란도 많을 겁니다.
00:24:49이미 많은 기업이 Bun 기반으로 서비스를 운영 중이니까요.
00:24:51그래서 다소 무모해 보이기도 하지만, 결과가 좋다면 또 다른 이야기가 되겠죠.
00:24:58지켜봐야죠.
00:25:007일 전쯤에 실험 삼아 해보겠다는 트윗을 봤는데,
00:25:04일주일 만에 100만 줄짜리 PR을 메인에 머지했다니, 정말 미친 실험이에요.
00:25:11제대로만 된다면 Claude 입장에서도 최고의 마케팅 소재가 될 거고요.
00:25:14맞아요.
00:25:15대단한 이야깃거리죠.
00:25:16그럼요.
00:25:17작은 PR을 선호하는 사람으로서, 이건 마음이 좀 아프네요.
00:25:20살짝요.
00:25:22뭐, 결과가 어떻게 나올지 봐야죠.
00:25:25관찰자 입장에선 정말 흥미진진한 이벤트입니다.
00:25:29하지만 Bun에 의존하는 사람들 입장에서는 자기네 코드베이스가 어떻게 될지 걱정이 태산일 것 같아요.
00:25:38오늘 Dax 트윗을 보니, OpenCode는 당분간 버전 업그레이드를 안 할 거라더군요. 너무 신뢰할 수 없어서요.
00:25:46당연하죠.
00:25:47언어 선택에 대해 몇 가지 더 질문이 있습니다.
00:25:50AI 사용 방식도 궁금해요. 처음에 AI로 많은 걸 만들었다가 나중에 직접 까다로운 부분들을 수정했다고 하셨잖아요.
00:26:00수정할 때 보통 AI에게 고치라고 프롬프트를 주나요, 아니면 직접 코드를 짜나요, 아니면 둘 다 하시나요?
00:26:09둘 다입니다.
00:26:10뭘 고치느냐에 따라 다르죠.
00:26:13대부분은 아키텍처 문제더라고요.
00:26:15AI와 Rust 작업할 때 이상한 점은, 그냥 다 맡겨두면 모든 걸 main.rs 파일에 쑤셔 넣는다는 거예요.
00:26:21결국 main.rs가 2만 줄이 넘어가길래, 이건 아니다 싶어서 전부 지우고 처음부터 다시 시작했습니다.
00:26:28아키텍처 결정에는 정말 젬병이에요.
00:26:32빨리 결과물을 내거나 토큰 비용을 최소화하는 효율성에만 몰두하느라 장기적인 관점을 고려하지 않거든요.
00:26:40결정권을 AI에게 완전히 위임하는 건 최악이었습니다.
00:26:46결국 제가 직접 아키텍처를 결정하고 나서야 구현을 맡길 수 있었죠.
00:26:50어떤 부분은 제가 직접 다시 작성하거나, 최소한 뼈대라도 만들고 채워 넣으라고 시키는 방식이었습니다.
00:26:56제가 직접 어떤 파일에 어떤 코드가 들어가야 할지 정의해주면, AI는 아주 훌륭하게 리팩토링을 수행하더군요.
00:27:08그래서 요즘은 타자 치는 단순 업무를 맡기는 데 AI를 활용하고 있습니다.
00:27:10제가 직접 하기 귀찮은 타이핑 자동화 말이죠.
00:27:14요즘 제 작업 스타일이 그래요. 타이핑은 AI가, 결정은 제가 하는 거죠.
00:27:18아키텍처 결정은 여전히 제 몫입니다.
00:27:20코드는 제가 직접 검토하고요.
00:27:22완전 멍청한 코드를 짜놓으면 다시 고치라고 시키거나, 직접 손을 봅니다.
00:27:30새로운 개념을 배울 때는 무조건 직접 작성해요.
00:27:34직접 코드를 짜보지 않으면 제대로 이해할 수 없으니까요.
00:27:39Rust 프론트엔드 프레임워크들을 이것저것 시험해 보고 있는데,
00:27:44Z팀에서 만든 GPUI, 특히 GPUI 컴포넌트는 환상적인 프레임워크입니다.
00:27:50AI를 시키기 전에 제가 먼저 작은 앱을 하나 직접 만들어봤어요. AI가 하는 걸 보는 것보다 직접 써보는 게 훨씬 빠르게 이해할 수 있거든요.
00:28:03그렇게 해봐야 창 전체가 언제 새로고침 되는지, 컴포넌트가 언제 리프레시 되는지, 앱 전체를 리프레시해야 하는 타이밍은 언제인지 같은 것들을 알 수 있죠. GPUI 컴포넌트가 제공하는 3가지 컨텍스트 같은 것들이요.
00:28:20Iced나 EGUI 같은 다른 데스크톱 프레임워크도 다 건드려봤습니다. 똑같은 과정을 거쳤죠. 직접 써봐야 작동 원리를 파악하고, 제 요구사항에 맞을지 판단할 수 있으니까요.
00:28:32정말 맞는 말씀이에요. 저도 비슷합니다. 제품을 직접 만들 때 본인만의 코딩 컨벤션이나 스타일이 있잖아요.
00:28:43AI에게 기능을 추가하게 할 때도, 본인 스타일에 맞춰서 작업하게 하는 게 낫죠. 그냥 AI 맘대로 하게 두는 것보다요.
00:28:50그래서 처음엔 직접 만져보면서 구조를 익히는 게 장기적으로 AI를 올바르게 사용하는 지름길 같아요.
00:28:58스텁을 사용하는 방법도 좋네요. 그런 생각은 못 해봤는데, 함수 뼈대만 잡아두고 나머지를 AI에게 채우게 하는 거요.
00:29:05맞아요. 비어있는 함수를 던져주면 AI가 알아서 채워주죠. 아주 편합니다.
00:29:07C++ 하던 습관이 남아서 그런 것 같아요. 헤더 파일을 무조건 작성해야 했거든요.
00:29:14전 사실 헤더 파일은 정말 싫어하지만, '공개 인터페이스 정의'라는 한 가지 기능은 정말 훌륭합니다.
00:29:21클래스 파일을 만들고, 외부로 공개할 함수만 명시하는 거죠.
00:29:28그게 곧 계약서 같은 거라, 외부에서 어떤 함수를 호출할 수 있게 할지 추상화하기가 너무 좋습니다.
00:29:36LLM은 그런 사고 과정이 좀 부족하더라고요. 그래서 저도 Rust를 할 때 똑같이 합니다.
00:29:45원하는 구조체와 공개 인터페이스를 정의하고, AI에게는 '전부 다 내보내지 말고 이 계약에 맞춰 코드를 짜'라고 시키는 거죠. 기본값으로 모든 걸 공개하려는 경향이 있거든요.
00:29:55모든 걸 public으로 만들려고 하는 건 정말 바보 같은 짓이죠. 그래서 저는 늘 뼈대와 인터페이스를 정의하고 AI에게 구현 세부사항만 채우게 합니다.
00:30:09멋지네요. 다음 프로젝트 때 꼭 해봐야겠어요.
00:30:12잘 작동하나요? 가끔 AI가 추론할 때 편하게 하려고 인터페이스 계약을 맘대로 수정해 버리는 상황이 있지 않나요?
00:30:25네.
00:30:26그런 경험 있으시죠?
00:30:27수도 없이 많죠.
00:30:29AI가 완벽하게 알아서 해주는 시대는 아직 멀었다고 봐요. 인간의 개입 없이 프롬프트 한 번 던지고 내버려 두는 방식으론 절대 성공할 수 없습니다.
00:30:45원치 않는 방향으로 가고 있을 때 수시로 멈춰 세워야 하니까요. 인간의 감시 없이 AI를 완전히 신뢰하는 건 불가능해요.
00:30:57간단한 토이 프로젝트나 CLI 변환 도구 같은 건 맡겨도 되지만, 유지보수가 필요한 프로덕션 레벨의 코드라면 개발자가 적극적으로 개입해서 방향을 잡아줘야 합니다.
00:31:10질문에 답하자면, AI는 당신이 세운 제약사항마저 가이드라인 정도로만 여기고 무시하려 들 때가 많습니다. 전 출력되는 코드를 실시간으로 읽으면서 매번 감시해요.
00:31:20네, 정말 끈질기게 자기 마음대로 하려 하죠. 제가 아주 적극적으로 개입해야 합니다.
00:31:35Git 스테이징도 꽤 활용하고 있습니다. 흐름이 마음에 들 때마다 커밋이나 스테이징을 해두고, AI가 헛짓거리를 하면 바로 이전 상태로 되돌리는 식이죠.
00:31:47그거 아주 좋은 기법이네요. 까먹어서 문제지... 단계별로 체크포인트를 만들어두고 롤백할 수 있는 기능이 있으면 정말 좋을 텐데, 지금은 너무 수동이라 귀찮아요.
00:32:05VS Code에는 그런 기능이 있긴 한데, IDE마다 다르니 어떨지 모르겠네요.
00:32:22Claude Code에도 그런 기능이 있었던 것 같은데, 저도 보통 워크트리를 씁니다. 체크포인트로 돌아가는 기능이 있긴 하지만 코드를 그때로 되돌리는 것까지는 잘 모르겠네요.
00:32:42저도 해본 적 없네요. 보통은 '방금 한 거 되돌려줘'라고 시키는데, 10번 정도 주고받은 대화 내용을 한꺼번에 되돌리기는 쉽지 않죠.
00:32:54맞아요. Codex CLI를 쓰는데, 대화 한 마디마다 코드를 체크포인트로 저장해 줬으면 좋겠어요. 패치 내용만 딱 되돌릴 수 있게 말이죠.
00:33:06그건 그렇고, 왜 Claude Code가 아니라 Codex를 쓰기로 하셨나요?
00:33:10편견일 수 있지만, CLI 툴에 TypeScript가 깔리는 걸 정말 싫어하거든요. Codex는 Rust로 작성됐다는 걸 보고 바로 넘어갔습니다. 무엇보다 Rust Analyzer 메모리 문제 때문이었죠. Codex는 그런 메모리 이슈가 없더라고요.
00:33:38성능도 더 쾌적했고요. Codex 5.2부터는 그것만 쓰고 있습니다. Claude Code는 빠르긴 한데 제 손이 너무 많이 가서요. 원하는 결과를 얻으려면 끊임없이 가이드를 줘야 하니까요.
00:33:59Codex가 최근에 오류를 좀 뿜긴 하지만, 그래도 Claude Code보다는 나아서 계속 Codex를 쓰고 있습니다.
00:34:12아까 하신 말씀이랑 겹치는데, 예전에 TypeScript 좋아하신다고 하셨던 게 기억나거든요. 그런데 CLI 툴로는 싫어하시는 게 재미있네요. 확실히 런타임이 무거워서 메모리를 많이 먹긴 하죠. Tauri나 Electron 같은 건 어떻게 생각하시나요?
00:34:39웹뷰를 감싸서 네이티브 앱처럼 만드는 방식인데, 솔직히 '왜 네이티브 앱을 웹 코드로 짜지?' 하는 생각이 들 때가 있잖아요.
00:34:57의외로 성능이 잘 나오긴 하더라고요. 터미널을 웹으로 구현한 xterm.js를 Tauri로 감싸서 네이티브 터미널처럼 만든 사례도 있고요. 돌아가는 방식은 좀 우회적이지만, 잘 작동하니까요. 이런 흐름은 어떻게 보시나요?
00:35:23제 관점은 명확합니다. C++ 출신이라 가상 머신이나 브라우저 기반 도구보다는 네이티브를 훨씬 선호해요.
00:35:35Electron이나 Bun, ZeroNative 같은 건 '개발자에게는 좋지만 사용자에게는 불친절한' 도구라고 봅니다. 개발 편의성과 크로스 플랫폼 지원은 확실히 좋죠. 제품을 빨리 출시하는 게 사용자에게도 이득일 수는 있겠네요.
00:36:03하지만 전 성능 중심의 네이티브 도구를 선호합니다. 개발하기가 훨씬 어렵더라도 말이죠.
00:36:15많은 사람들은 사실 신경 쓰지 않아요. 그래서 제가 좀 까다로운 편이고, 네이티브 툴을 선호하는 개인적인 취향이 강한 거죠. 그리고 기업들이 컴퓨터 자원을 좀 더 존중해 주었으면 좋겠어요. 컴퓨터는 훨씬 강력해졌는데 소프트웨어는 그만큼 강력해지지 않았거든요. 요즘 우리가 쓰는 코드는 자원에 대해 생각할 필요가 없어서, 메모리 제한 같은 걸 고려하지 않고 좀 낭비하는 경향이 있어요.
00:36:43하지만 예전에 iOS 개발을 처음 시작했을 때는 사용할 수 있는 RAM이 아주 적었어요. 그래서 모바일 앱을 배포하거나 개발할 때 아주 제한적이고 신중해야만 했죠.
00:36:53이제 그런 절박함이 좀 다시 필요하지 않나 싶어요. 아무 이유 없이 메모리를 낭비하지 않는 태도 말이죠.
00:37:05사용자의 리소스와 하드웨어 환경을 배려하는 거요. 제가 지나치게 까다로운 걸 수도 있지만, 적어도 그런 마음가짐은 중요하다고 봅니다.
00:37:17물론 요즘 환경에서 네이티브 앱보다 웹뷰 기반 앱을 만드는 게 훨씬 쉽다는 건 부정할 수 없는 사실이죠.
00:37:27제품 출시 속도가 중요한 산업이니까요. 어쩔 수 없는 현실이겠죠.
00:37:33그러고 보면 PS1, PS2 시절 게임 개발자들이 쥐꼬리만한 메모리 쓰려고 온갖 꼼수를 부리던 게 생각나네요.
00:37:48지금은 그냥 200기가짜리 게임 만들어서 툭 던지면 PS5에서 어떻게든 돌아가니까요.
00:37:55물론 꼼수 안 부리고 쉽게 개발할 수 있는 건 좋은 일이죠.
00:38:01개발자의 진입장벽을 낮추는 건 분명 긍정적입니다. 시스템 제약을 하나하나 고민하지 않아도 되니까요.
00:38:15하지만 GPU 사이클을 낭비하지 않는 성능과, 개발의 생산성 사이의 황금 밸런스를 찾는 노력도 분명 필요할 겁니다.
00:38:30코드 작업하면서 메모리 많이 먹어서 맥이 뜨거워지고 배터리 광탈하는 걸 보면 저도 참 고민이 많아요.
00:38:38그래서 클라우드로 작업을 offload 할 방법을 찾고 있는데 아직 딱 맞는 솔루션을 못 찾았네요.
00:38:47무슨 말씀인지 알겠어요. 가까운 미래에 컴퓨팅 자원 상황에 따라 해결책이 달라지겠죠.
00:38:55저가형 노트북들도 많이 나오는데, 사실 성능은 좀 애매하니까요.
00:39:02조만간 하나 구해서 영상 편집 테스트해 보려고요. 거기서 잘 돌아가면 정말 좋겠네요.
00:39:07엔비디아가 AI 미래를 위해 엄청난 양의 전력을 요구하고 있다는 기사도 봤습니다. 앞날을 예측하는 건 보통 다 틀리더라고요.
00:39:24만약 컴퓨팅 자원이 더 부족해진다면, 개발자들은 어떻게 하면 저사양 하드웨어에서도 코드가 잘 돌아가게 할지 고민하는 시대로 다시 돌아갈지도 모릅니다.
00:39:41AI 분야도 모델 양자화(quantization)가 활발하죠. 350억 개의 파라미터를 가진 모델을 어떻게든 압축해서 로컬 맥북에서 돌리려는 노력들이 있잖아요.
00:39:57그런 시도들은 정말 멋집니다. 한 줌의 성능이라도 더 짜내려는 개발자들의 모습은 언제 봐도 흥미로워요.
00:40:10LLM 셀프 호스팅 커뮤니티는 정말 광기 어린 수준이죠. 알렉스 시스킨드라고 아시나요? 맥 스튜디오나 맥 미니를 주렁주렁 연결해서 돌리는 분인데, 정말 대단하더군요.
00:40:26그나저나 당신은 주로 맥을 쓰나요, 리눅스를 쓰나요?
00:40:30성가시게도 둘 다 씁니다. 주력은 맥북 프로예요. 하지만 리눅스도 쓰는데, 전 Nix OS를 정말 좋아하거든요. 개인적으로 역대 최고의 리눅스 배포판이라고 생각합니다. 다루긴 좀 어렵지만 AI가 설정을 잘 도와주니까요.
00:40:52선언적 설정을 사랑하거든요. 인프라는 쿠버네티스, PC는 Nix OS! 맥 OS에서는 Nix-Darwin을 쓰는데 Nix OS만큼은 아니지만 나름 견딜 만합니다. 그래도 영상 편집 같은 작업은 역시 맥 OS가 최고라 놓을 수가 없네요.
00:41:14요즘 새로 나오는 AI 툴들이 맥만 챙기는 경향도 있죠. 윈도우는 잊힌 것 같아요. 다들 '맥 앱뿐입니다, 알아서 하세요' 하는 식이라.
00:41:23맞아요. 영상 쪽으로 넘어가서, 조명이랑 카메라 세팅이 정말 깔끔하시네요. 그런데 화면 녹화를 안 하고 카메라로 화면을 직접 찍으시던데, 화면 반사(glare) 때문에 정말 어렵더라고요. 비결이 뭐죠?
00:41:42오, 그거죠. 조명 각도를 카메라랑 똑같이 맞춰야 합니다. 측면에 조명을 두면 무조건 반사가 생기니까, 카메라 뒤쪽에 조명을 두는 게 핵심이에요.
00:41:54반사 방지(Nano-texture) 처리된 맥북을 산 것도 도움이 됐고요. 그래도 어렵다면 조명을 화면 위쪽이나 뒤쪽에서 쏴보세요.
00:42:03각도 조절이 다입니다. 화면 녹화가 편하긴 한데, 영상 찍어보면 조회수 차이가 엄청나거든요.
00:42:11아이러니하게도 코딩 채널에서 화면 녹화 화면만 보여주면 사람들이 금방 이탈해요. 별로 재미가 없거든요.
00:42:20영화나 영상의 묘미는 심도(depth of field)에 있습니다. 시선을 어디에 둬야 할지 알려주니까요.
00:42:29반면 화면 녹화는 전체가 다 선명하게 나오니까 그런 몰입감이 없죠.
00:42:38반면 카메라로 화면을 직접 찍으면 심도를 이용해 강조하고 싶은 부분에만 시선을 집중시킬 수 있습니다.
00:42:45바로 지금처럼요. 훌륭한 전략입니다.
00:42:52이야기가 나와서 말인데, 지금 당신 세팅도 심도가 정말 예술이네요. 카메라 모델이랑 렌즈 정보 좀 알 수 있을까요?
00:43:03메인 촬영용으로 Sony FX30을 써요. 렌즈는 시그마 23mm를 쓰는데, 풀프레임 환산으로 하면 35mm 정도 됩니다.
00:43:22F값은 몇인가요?
00:43:231.4일 거예요.
00:43:25어쩐지 초점이 맞은 범위가 종잇장처럼 얇더라니.
00:43:32그래도 소니 오토포커스가 꽤 괜찮아서 다행입니다.
00:43:36B-roll 촬영용 카메라는 따로 쓰시나요?
00:43:38B-roll은 FX3를 쓰는데, 저조도 성능이 워낙 뛰어나거든요.
00:43:44매크로 렌즈를 쓸 때는 ISO를 낮게 하고 조리개를 열면 초점 맞추기가 불가능에 가깝거든요.
00:43:55심도가 그야말로 종잇장 수준이니까요.
00:43:58FX3는 ISO를 12,800까지 올려도 괜찮아서, 조리개를 꽤 조여도 밝게 나오니 매크로 렌즈 초점 잡기엔 최고입니다.
00:44:06화면에 띄운 코드를 매크로로 클로즈업할 때 아주 유리하죠.
00:44:14이런 지식들은 다 유튜브 하려고 배운 건가요, 아니면 원래 카메라에 관심이 많으셨던 건가요?
00:44:20말투에서 느껴지시겠지만, 전 한번 빠지면 끝장을 보는 스타일이거든요.
00:44:24영국 대학 다닐 때 사진을 전공했어요.
00:44:27사진 A-level 과정을 밟았죠.
00:44:29그때 배운 걸 정작 오랫동안 써먹진 못했습니다.
00:44:32대학 때는 나이트클럽 사진이나 찍고 다녔거든요. 그러다 영상을 시작하면서 옛 지식들이 다시 살아난 셈이죠.
00:44:37그러다 다시 비디오 쪽을 시작하게 됐죠.
00:44:39그때의 오래된 지식들이 다시 떠오르더라고요.
00:44:42스티브 잡스의 유명한 말처럼 인생에서 겪는 사소하고 무작위적인 일들이 있잖아요.
00:44:50그때는 어떻게 연결될지 전혀 모르다가 나중에,
00:44:53뒤돌아보면 '아, 이게 오늘날의 나에게 도움이 됐구나' 하고 깨닫게 되죠.
00:44:56죄송합니다.
00:44:57장비 관련해서 질문 하나만 더 할게요.
00:44:58자동 초점 기능을 쓰시는 건가요, 아니면 고정인가요?
00:45:03A-롤은 자동 초점을 사용해요.
00:45:05아, 그렇군요.
00:45:06네.
00:45:07B-롤은 수동 초점을 써요.
00:45:09네.
00:45:10정말 훌륭하네요.
00:45:11초점이 나가는 일이 전혀 없네요.
00:45:12소니의 자동 초점 기능이 정말 좋은 것 같아요.
00:45:16맞아요.
00:45:17네.
00:45:18정말 훌륭합니다.
00:45:19헤어 라이트도 사용하시는 것 같은데 화면엔 안 보이네요.
00:45:21조명을 여러 개 쓰시나요?
00:45:23네.
00:45:24여기에 '태양'이라 부르는 게 있어요.
00:45:26정말 거대한 소프트박스거든요.
00:45:29헤어 라이트도 있고,
00:45:30여기에 작은 아마란(Amaran) 조명 몇 개랑,
00:45:35뒤쪽에도 포인트 조명을 좀 뒀어요.
00:45:39좋네요.
00:45:40네.
00:45:41정말 보기 좋네요.
00:45:42사람들의 설정이 시간이 지나면서 발전하는 건 정말 놀라워요.
00:45:43조명, 삼각대 같은 것들을 계속 사게 되잖아요.
00:45:46그것도 정말 중요하죠.
00:45:47최근에 깨달은 건데 조명의 각도도 정말 중요하더라고요.
00:45:51위에서 아래로 비추면 조금 더 피곤해 보이고,
00:45:54눈 밑에 큰 그림자가 지거든요.
00:45:56그래서 지금은 거의 수평으로 맞췄어요.
00:45:58그럼 일상이 보통 어떻게 되나요?
00:46:01회사를 위해 개발을 하시는 건지, 아니면 전업 유튜버인지,
00:46:05아니면 개인 프로젝트를 하시는 건지 궁금해요.
00:46:06보통 하루 일과가 어떻게 되나요?
00:46:08네.
00:46:09일상 브이로그를 한번 찍어야겠어요.
00:46:10안 그런가요?
00:46:11그거 꼭 필요할 것 같아요.
00:46:13음, 제가 뭘 하냐고요?
00:46:15이제 풀타임 개발자로 일하진 않아요.
00:46:18누구한테 말한 적은 없는데, AI가 뜨는 걸 보고 업계를 빨리 떠났거든요.
00:46:23상황이 어떻게 돌아갈지 마음에 안 들었고, 사실 전부터 업계와 좀 안 맞았거든요.
00:46:29정말 좋은 회사들도 다녀봤지만, 지난 5년간 이 업계가 점점 관료주의적으로 변해가는 걸 느꼈어요.
00:46:40스크럼 마스터 같은 역할이 생기면서 실제 개발보다는 기획에 더 치중하게 됐달까요.
00:46:48기획이 중요하지 않다는 게 아니라, 더 빠르게 일을 처리하던 방식에서 멀어진 기분이었어요.
00:46:54일을 빠르게 하기 위해 수많은 회의를 해야 하는 상황이었죠.
00:46:57실제 소프트웨어 개발 자체로부터 멀어지는 느낌을 받았어요.
00:47:02AI까지 등장하니 그런 상황은 더 심해졌고요.
00:47:04요즘 많은 개발자들이 지금의 고용 시장과 업계의 상황에 행복해하지 않는다고 생각해요.
00:47:11저도 이해하고요.
00:47:12저라도 지금 상황에선 즐겁게 일하지 못했을 거예요.
00:47:15그래서 2014년에 전업 유튜버가 되기로 결심했죠. 창의적인 활동을 계속하면서 제가 원하는 코딩도 병행하고, 그러면서 수익도 얻을 수 있는 방법이라고 생각했거든요.
00:47:25풀타임 유튜버라고는 하지만, 사실 영상을 많이 만들지 않으니 파트타임 유튜버에 가깝죠.
00:47:33대신 제품을 만듭니다.
00:47:35제 시간에 맞춰 코딩하는 게 좋아요.
00:47:37배우는 것도 계속하고 싶고요.
00:47:38제 일상은 주로 온라인에서 사람들의 의견을 읽고 트렌드를 파악하며, 그런 트렌드에 대한 영상 아이디어를 떠올리고, 틈틈이 코딩하며 계속 배우고 소프트웨어 개발을 이해하려고 노력하는 거죠.
00:47:55죄송합니다.
00:47:56방금 제가 잘못 들었나요?
00:47:572014년이요?
00:47:58그때 전업 유튜버를 시작하셨다고요?
00:48:002024년이요.
00:48:01아, 죄송합니다.
00:48:02아, 알겠습니다.
00:48:03죄송해요.
00:48:04제 실수예요.
00:48:05벌써 베테랑이시네요.
00:48:06그래서, 지금 하시는 일들,
00:48:11유튜브, 스폰서십, 제품 판매가 생활비를 감당할 수준인가요?
00:48:16아니면 부업으로 계약직 일도 하시나요?
00:48:20수익 구조가 어떻게 되나요?
00:48:23네.
00:48:24전부 유튜브와 스폰서십, 그리고 제품 판매로 수익이 나요.
00:48:29네, 충분합니다.
00:48:30앤스로픽(Anthropic) 같은 회사에 갔다면 돈은 훨씬 많이 벌었겠죠.
00:48:34맞아요.
00:48:35정말 엄청난 돈을 벌었을 거예요.
00:48:36그래도 지금은 먹고 사는 데 전혀 지장 없고, 꽤 여유롭게 지낼 수 있어요.
00:48:43더 집중했다면 더 많이 벌 수 있었을지도 모르지만요.
00:48:46그건 제 개인적인 집중력 문제죠.
00:48:49그래도 지금 상황으로 충분해요.
00:48:51생활비는 나오니까요.
00:48:52외부에서 보기엔 정말 집중력이 대단해 보여요. 제품도 만들고 새로운 것도 계속 배우시잖아요.
00:48:58영상을 만드시는 것도 다양한 앵글로 촬영하고 편집까지 하려면 시간이 엄청 걸릴 것 같은데요.
00:49:07외부에서 보면 정말 생산적인 분 같아요.
00:49:09감사합니다.
00:49:10제 자신은 그렇게 느끼지 못하지만요.
00:49:12업계에 대해 어떤 '매운맛' 의견들을 가지고 계신가요?
00:49:16정말 많죠. 근데 전 이미 평소에 자주 공유하고 있어요.
00:49:20이미 몇 가지 들려주신 것 같네요.
00:49:22네.
00:49:23네.
00:49:24올해 러스트(Rust)가 엄청 뜰 거란 게 제 매운맛 의견 중 하나였죠.
00:49:27근데 이젠 그렇게까지 핫하진 않은 것 같아요.
00:49:29작년엔 사람들이 AI 에이전트를 써서 코딩할 거란 게 제 주장이었는데,
00:49:34그건 어느 정도 현실이 됐고요.
00:49:36이제 또 어떤 매운맛 예상을 해볼까요?
00:49:38어디 봅시다.
00:49:39제 매운맛 예상이요.
00:49:40네.
00:49:41우리가 LLM의 수확 체감 법칙에 도달했다는 게 제 생각이에요.
00:49:45이제 더 큰 발전은 없을 거라 봐요.
00:49:48물론 제 예상이 틀릴 수도 있지만요.
00:49:49현재 모델들의 수준에서 크게 더 나아지기는 힘들 것 같아요.
00:49:55툴링은 발전할지 몰라도 모델 자체는 글쎄요.
00:49:58그럼 클로드 미소스(Claude Mythos)도 완벽한 모델이라 생각 안 하시나요?
00:50:03좋은 모델이라고 생각해요.
00:50:04근데 엄청나게 비쌀 거예요.
00:50:05여전히 수확 체감의 영역에 있다고 보거든요.
00:50:09일반 소비자가 쓰기엔 가성비가 안 나올 거라 생각해요.
00:50:13기업들은 비용을 감수하고서라도 이런 비싼 모델을 쓰겠지만,
00:50:21소비자용으로는 나오지 않을 거예요. 운영 비용 대비 아웃풋이 가치 있지 않으니까요.
00:50:30그게 제 매운맛 의견입니다.
00:50:31또 2027년쯤엔 기업들의 AI 마케팅도 사라질 거라 봐요.
00:50:36그게 AI를 마케팅에 활용하는 건지, 아니면 너도나도 AI 툴을 만들어서 '우린 AI가 많아'라고 자랑하는 걸 말씀하시는 건가요?
00:50:43후자요. 제품에 어떻게든 AI를 끼워 넣고 'AI가 세상을 바꿀 엄청난 변화'라고 떠드는 거요.
00:50:53왜냐하면 소비자들은 그걸 원하지 않거든요.
00:50:55무분별하게 모든 제품에 AI를 뿌려대는 걸 소비자들은 별로 안 좋아한다는 게 여러 번 증명됐잖아요.
00:51:02언젠가는 거품이 꺼질 거라 봐요. 제가 틀릴 수도 있지만요.
00:51:05완전한 거품일 수도 있겠죠.
00:51:07정말 어찌 될지 모르는 예측이네요.
00:51:09어쨌든 전 AI 마케팅이 서서히 죽을 거라고 생각해요.
00:51:132027년엔 이런 AI 광풍이 끝날 것 같아요.
00:51:16챗 인터페이스라는 점에서는 저도 동의해요.
00:51:20모든 게 챗 인터페이스일 필요는 없잖아요, 여러분.
00:51:23챗GPT나 챗 인터페이스로 여행 예약을 한다는 식의 데모는 이제 지겨워요.
00:51:29직접 확인하고 고르는 게 좋거든요.
00:51:31챗GPT한테 '예약해 줘'라고 해서 여행을 통째로 예약하고 싶진 않아요.
00:51:34그래서 저도 동의합니다.
00:51:35윈도우도 그렇고요, 모든 기능에 코파일럿 버튼이 붙을 필요는 없잖아요.
00:51:39얼마 전에 코파일럿이 붙은 제품 리스트를 봤는데 정말 미쳤더라고요.
00:51:43코파일럿이라는 이름이 붙은 게 70개가 넘었어요.
00:51:46와.
00:51:47제정신이 아니네요.
00:51:48여러분들의 매운맛 의견은 뭔가요?
00:51:50이런 질문은 처음이라 당황스럽네요.
00:51:52준비가 안 됐거든요.
00:51:54결국 또 AI 이야기로 갈 것 같네요.
00:51:57AI로 가주셔서 기뻐요, 저도 AI에 대해 말하려고 했거든요.
00:52:02근데 딱히 매운맛 의견이랄 게 있을지 모르겠어요.
00:52:05터미널 UI는 좋은데, 저랑은 잘 안 맞는 것 같아요.
00:52:10코드덱스(Codex) 앱을 더 많이 썼는데 그게 더 편했어요.
00:52:13테오(Theo)의 T3 코드도 정말 좋은데 클로드가 구독 모델을 없애버려서 좀 짜증 나더라고요.
00:52:18그건 좀 아쉽죠.
00:52:19아까 말했듯 많은 챗 인터페이스들은 사라져야 해요.
00:52:26더 나은 인터페이스가 필요해요.
00:52:28어떤 게 좋을진 모르겠지만요.
00:52:29터미널 UI도 좋지만 멀티 에이전트 워크플로우를 다루기엔 한계가 있다고 봐요.
00:52:34제 매운맛 의견은 클로드를 비롯한 모든 AI의 예측 불가능한 가격 정책 때문에, 로컬 설정이나 로컬 모델로의 회귀가 더 가속화될 거라는 겁니다.
00:52:48GPU 가격이 오르기 전에 지금이라도 괜찮은 그래픽 카드를 하나 사두는 게 나중에 클라우드를 감당할 수 없을 때를 대비하는 좋은 방법이 될 거예요.
00:53:03클라우드 비용을 감당하기 힘들 때를 위한 로컬 환경이죠.
00:53:09전 좀 반대예요. 많은 소비자는 가격이 올라도 상관없다고 생각해서 계속 구독료를 낼 거예요.
00:53:17기업들은 비용이 들어도 계속 내겠죠. 어차피 자기들 돈도 아니니까요.
00:53:24맞아요.
00:53:25네.
00:53:26개인 사용자라면 고민할지도 모르겠지만요.
00:53:29근데 학생들은 현재 GPU 가격도 감당 못 하지 않나요?
00:53:33물론이죠.
00:53:34네.
00:53:35네.
00:53:36돈 좀 있는 분들 이야기를 들어보면, 개발자를 고용하는 것보다 200달러 내고 클로드한테 일을 시키는 게 싸고 빠르다고 하더라고요.
00:53:46200달러짜리 클로드 플랜이면 충분하니까요.
00:53:49그래서 클로드가 아무리 좋아도 진짜 개발자만큼은 아니라고 교육하는 게 필요해요.
00:53:57리처드님 매운맛 의견도 들어야죠.
00:53:59아직인가요?
00:54:00네, 아직 생각 중입니다.
00:54:02정말 모르겠네요.
00:54:03AI 관련이어야 하죠?
00:54:05아마도요.
00:54:06한 가지 정말 흥미로운 건, 클로드 코드(Claude Code)를 쓰면서 '뭘 구축하고 싶은데 추천해 줄래?'라고 물으면,
00:54:15예상치 못한 제품들을 추천해 줘요.
00:54:16예를 들어 사이트를 만들어서 배포하고 싶은데 어디가 좋을까 하면,
00:54:21어디에 호스팅 할까?
00:54:22AWS나 디지털오션 대신 다른 걸 추천하는 거죠.
00:54:25Fly.io나 Railway, 때로는 버셀(Vercel) 같은 걸요.
00:54:32이걸 위해 뭔가 작업을 하고 있는 게 분명해요.
00:54:35어떤 이들은 이걸 '에이전트 경험'이라고 부르더군요.
00:54:37이게 차세대 SEO가 될 거예요.
00:54:40이제 사람들이 H1 태그 같은 거에만 신경 안 쓸 거예요.
00:54:43모델에게 자기 제품을 추천하게끔 만드는 방법이 따로 있을 테니까요.
00:54:46이미 사람들이 그걸 해킹하고 있을지도 모르고요.
00:54:50앞으로 이게 큰 화두가 될 겁니다.
00:54:52사람들이 속임수를 찾아내면 AI의 사용자 경험이 망가지는 거 아닐까요?
00:54:56속이는 법을 알아내면요.
00:54:58글쎄요, 그것도 일리가 있죠.
00:55:00속이는 것 자체가 꽤나 교묘하긴 하죠.
00:55:02네.
00:55:03의도한 건 아니지만 진짜 교묘하네요.
00:55:04LLM용 텍스트나 MD 파일, 로봇 텍스트(robots.txt) 등에 넣어야 할 복잡한 작업들이 좀 있거든요.
00:55:09시간도 꽤 걸리고요.
00:55:11하지만 사용자 경험 측면에서 보면 '클로드, 구글 클라우드 계정 좀 설정해 줘, API 키도 다 해줘'라고 하는 게,
00:55:20그 복잡한 클라우드 대시보드를 직접 뒤지는 것보다 훨씬 쉽고 안전하다면 이야기가 달라지겠죠.
00:55:28음, 두고 보면 알겠죠.
00:55:30그게 제 소소한 매운맛 의견입니다.
00:55:33흥미로운 관점이네요.
00:55:34얼마 전 러닝머신 위에서 이런 생각을 했어요. 모두가 AI를 통해 아키텍처나 제품 결정을 내린다면,
00:55:44아이디어가 결국 비슷해질 텐데, 이때 자신의 직관을 믿는 게 더 혁신적이지 않을까 하는 생각이요.
00:55:52그게 남들과 차별화되는 점이 되겠죠.
00:55:56제가 지금 이 시점에 코딩을 배우는 게 좋다고 생각하는 이유도 똑같아요.
00:56:02AI에게만 의존하지 않고 스스로 판단할 수 있다면 그게 엄청난 경쟁력이 될 테니까요.
00:56:11모두가 AI가 주는 뻔한 답변만 따라갈 때 말이죠.
00:56:14네.
00:56:15이미 제품의 획일화가 시작됐죠.
00:56:17AI가 버셀, 수퍼베이스(Supabase), 리센드(Resend)를 추천하니까 다들 그것만 쓰잖아요.
00:56:22천천히 이미 일어나고 있는 일이에요.
00:56:25이 기술들이 어떻게 돌아가는지 알면 자신만의 최적의 툴을 고를 수 있겠죠.
00:56:29앞으로 어떻게 될지 지켜보죠.
00:56:30'러닝머신 생각'이라는 표현은 처음 들어봤는데 정말 일리가 있네요.
00:56:33샤워하면서 하는 생각이라는 건 알지만, 그 의미가 뭔지 딱 알 것 같아요.
00:56:37샤워 안 할 때도 샤워하면서 하는 생각이라고 부르는데, 이제 '러닝머신 생각'이라는 표현도 써봐야겠네요.
00:56:42대부분 생각이 러닝머신 위에서 나거든요. '더 나은 것들(The Better Stuff)' 팟캐스트를 들어주셔서 감사합니다.
00:56:46애플 팟캐스트, 스포티파이 등 팟캐스트를 듣는 곳 어디에서나 저희를 찾아주세요.
00:56:52이제 마칠 시간입니다. 안녕히 계세요, 안녕히 계세요, 안녕히 계세요, 안녕히 계세요.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video