정말 오랜만이에요!

MMaximilian Schwarzmüller
컴퓨터/소프트웨어경영/리더십구직/면접

스크립트

00:00:00감사합니다.
00:00:30좋아요, 드디어 다시 온라인 상태가 되었네요. 다시 라이브 스트리밍을 시작한 것 같습니다.
00:00:58잠시만요.
00:01:06네.
00:01:07네.
00:01:08안녕하세요, 여러분.
00:01:09안녕하세요.
00:01:10새로운 방송에 오신 것을 환영합니다.
00:01:123주 만인 것 같네요.
00:01:14정말 그런가요?
00:01:15지난 방송 이후로 몇 주 정도 지났네요.
00:01:19살다 보면 의도치 않게 바쁜 일들이 생기니까요.
00:01:22보통 매주 목요일마다 방송하려고 노력하는데, 네, 항상 그렇게 할 수 있었던 건 아니었어요.
00:01:27오, 구독 정말 감사합니다.
00:01:30정말 멋진 시작이네요.
00:01:31정말 감사합니다.
00:01:32네, 여러분 모두 방송에 오신 걸 환영합니다.
00:01:35방송을 안 한 지 3주나 됐으니, 그동안 있었던 일들에 관해 이야기를 좀 나눠보려고 합니다.
00:01:42편하게 같이 이야기해요.
00:01:45질문이 있거나 제가 의견을 냈으면 하는 내용이 있다면 무엇이든 말씀해 주세요.
00:01:50물론 저도 몇 가지 이야기할 주제를 준비했습니다.
00:01:52네, 진행하면서 재미있는 걸 좀 만들어 볼 수도 있겠네요.
00:01:59여기가 너무 덥네요.
00:02:00에어컨을 최대로 틀어놨는데도 여전히 너무 덥습니다.
00:02:05그러니 제가 방송 중에 조금 날카롭지 못하더라도 너그러이 이해해 주시길 바라요. 그래도 잘 진행해 볼게요.
00:02:15방금 X에서 봤는데, 많은 사람들이 Kimi K3의 새로운 모델이 나오길 기다리는 것 같더라고요.
00:02:28지난주에만 해도 GPT 5.6 모델, GROC 4.5 같은 모델들이 많이 나왔잖아요.
00:02:36모델에 대해 긴 토론을 하고 싶은 건 아니지만, 정말 흥미진진한 몇 주였다고 말하고 싶어요.
00:02:43AI 관련 소식도 많았고 정말 흥미로웠죠.
00:02:47저는 요즘 '허더(Herder)'에 완전히 빠져 있습니다.
00:02:51혹시 모르시는 분들을 위해 설명하자면, 허더는 터미널 멀티플렉서입니다.
00:02:56오늘 제 다른 채널인 '아카데마인드(Academind)'에 허더가 무엇인지, 무엇을 할 수 있는지, 왜 제가 이것을 대단하다고 생각하는지 깊이 있게 다룬 영상을 올렸습니다.
00:03:07네, 그런 일이 있었고요.
00:03:11그리고 채팅창에서 방금 봤는데, 제 유데미 강의를 보는데 문제가 있다면 유데미 고객센터에 문의하셔야 합니다. 저는 그 플랫폼 운영에 전혀 관여하지 않거든요.
00:03:22기술적인 부분이나 운영 측면에서 제가 할 수 있는 영향력이 전혀 없습니다.
00:03:26그래서 혹시 문제가 발생한다면 정말 죄송하지만, 제가 어떻게 해드릴 방법이 없어요.
00:03:31유데미 지원팀이 도움을 드릴 수 있을 겁니다.
00:03:34네, 그동안 정말 많은 일이 있었네요.
00:03:37앞서 말씀드린 것처럼, 지난 몇 주 동안의 일들이나 전체적인 개발 환경이 어떻게 변화하고 있는지 여러분의 생각을 꼭 알려주세요.
00:03:51방금 채팅에서 Kimi K3가 출시되었다는 내용을 읽었네요.
00:03:55저도 X에서 보긴 했는데, 공식 발표를 기다리고 있습니다.
00:04:01지금 그들의 블로그에는 2.6 버전밖에 안 보이거든요.
00:04:06제가 보고 있는 곳이 맞는지 모르겠네요, 그죠?
00:04:14확실하지 않아요.
00:04:16네, 그래도 정말 많은 것들이 쏟아져 나오고 있네요.
00:04:19참 이상한 시기입니다.
00:04:22정말 기묘한 시대예요.
00:04:25개인적으로는 말씀드렸듯이 여러 에이전트와 함께 허더 설정을 활용하며 아주 활발하게 놀고 있습니다.
00:04:37채팅창에서 언급해 주신 것처럼 아카데미 대시보드가 가끔 버그가 있다는 점은 아주 좋은 지적이에요.
00:04:44그 점에 대해서도 정말 아주 많이 죄송하게 생각합니다.
00:04:47문제는 이것이 브랜드명에도 불구하고 저희 플랫폼이 아니라는 점입니다.
00:04:51그렇지만 저희만의 플랫폼을 만들고 있습니다.
00:04:54그래서 상황이 나아지길 바라고 있어요.
00:04:56아직 정확한 출시일은 말씀드리지 못하겠지만요.
00:04:59그래도 정말 불편하다는 건 잘 알고 있습니다.
00:05:02정말 안타까운 일이죠.
00:05:04저희 강의는 티처블(Teachable)이라는 화이트 라벨링 코스 호스팅 플랫폼을 사용하고 있는데, 다들 알고 계셨나요?
00:05:13사용해보신 분들도 계시겠죠.
00:05:15유데미는 여러 창작자가 모여 있는 곳이라서 티처블이 유데미를 완전히 대체할 수는 없어요.
00:05:21티처블은 자신만의 강의 플랫폼을 만들 수 있게 해주는 플랫폼입니다.
00:05:26하지만 기술적인 인프라는 그쪽에서 제공하는 거죠.
00:05:29안타깝게도 고질적인 버그들이 좀 있는데,
00:05:31계속해서 티처블 팀에 피드백을 전달하고 있습니다.
00:05:36그쪽에서는 별로 신경 쓰지 않는 것 같아 걱정이에요.
00:05:38그래서 저희는 더 나은 학습 환경을 제공하기 위해 자체 플랫폼을 구축하고 있습니다.
00:05:45언제 완료될지는 아직 잘 모르겠어요.
00:05:48저희 이름이 걸려 있는 만큼 현재 방식에 대해 전혀 만족하지 못하기 때문에, 상황이 나아지기를 정말 바라고 있습니다.
00:05:55정말 죄송합니다.
00:05:59Gabor 님, 정말 따뜻한 메시지 남겨주셔서 감사합니다.
00:06:047년 전에 앵귤러 강의를 듣고 탄탄한 기초를 다질 수 있었다니 정말 기쁘네요.
00:06:13진심으로 다시 한번 감사드립니다.
00:06:16그리고 따뜻한 메시지 보내주신 모든 분께도 감사드려요.
00:06:19또한 GitHub Actions 강의에 대해 좋은 피드백을 주신 Guzseska 님께도 감사합니다.
00:06:24도움이 되었다니 다행이에요.
00:06:28저는 제 모든 프로젝트의 CI/CD 워크플로에 GitHub Actions를 사용하고 있습니다.
00:06:33GitHub Actions와 관련해 몇 가지 문제도 있지만, GitHub 안에서 바로 편리하게 사용할 수 있다는 점이 마음에 듭니다.
00:06:40그래서 강의가 도움이 되었다니 기쁩니다.
00:06:45리액트, 앵귤러, 스프링부트, CI/CD, 도커 등을 배우고 이제 큰 개인 프로젝트를 만들면서 오픈 소스 관리와 알고리즘(DSA) 학습을 계획 중이시군요.
00:06:57현시점에서 좋은 계획일까요?
00:06:58제가 오늘 채널에 올린 영상에서도 이야기했듯이, 여러분이 반드시 해야 할 일이 있습니다.
00:07:04조금 논란이 될 수도 있겠지만, 꼭 논란을 만들려는 의도는 아니에요.
00:07:10영상 제목을 '정신 차릴 시간'으로 지었습니다.
00:07:11유튜브에서 보고 계시다면 바로 이 채널에 있습니다.
00:07:15개발자로서 AI를 활용하는 것은 정말 중요하다고 생각하기 때문이죠.
00:07:23새로운 이야기는 아닙니다.
00:07:24전에도 말씀드린 적 있죠.
00:07:25이미 수십 번은 들으셨을 거예요.
00:07:27지루하게 하려는 건 아닙니다.
00:07:28로드맵이 맞는지 물으셨으니 말씀드리자면, 네, 무언가를 직접 만들어 보세요.
00:07:32그건 AI 시대 이전에도 항상 좋은 생각이었습니다.
00:07:34지금은 당연히 AI와 함께 해야겠죠.
00:07:37그리고 어떻게 하면 AI로 생산성을 높일 수 있을지 고민해 보셨으면 좋겠어요.
00:07:40AI에게 모든 것을 맡기거나 그냥 코드를 덮어쓰는 것만으로는 생산성을 높일 수 없다고 확신하거든요.
00:07:43코드를 버려도 되는 작은 도구나 프로젝트라면 그렇게 할 수도 있죠.
00:07:51저도 그렇게 합니다.
00:07:56잠깐 필요한 도구라면요.
00:07:57예를 들어, 내부 데이터를 보여주기 위한 대시보드가 빠르게 필요할 때처럼요.
00:08:05그럴 땐 AI로 코드를 작성합니다.
00:08:06어차피 퍼블리싱할 게 아니니까요.
00:08:07판매용도 아니고요.
00:08:09전혀 문제없죠.
00:08:11하지만 AI를 효율적으로 사용하는 방법을 찾는 것이 무엇보다 중요합니다.
00:08:15우리는 아직도 그 방법을 찾아가는 중이니까요.
00:08:18누군가는 그 방법을 알려주겠다며 판매하려 할 겁니다.
00:08:22하지만 제가 AI 활용법 강의를 따로 만들지 않는 이유가 있죠.
00:08:31저는 클라우드 코드 등에 관한 강의는 하지만요.
00:08:32어떻게 활용할 수 있을지 공유하고 싶긴 해요.
00:08:35우리는 여전히 AI와 효과적으로 협업하는 방법을 알아가고 있는 단계니까요.
00:08:40새로운 모델과 에이전트 프레임워크들이 쏟아져 나오니 매일 상황이 변합니다.
00:08:45저는 현재 허더와 Pi(에이전트 프레임워크)를 조합해서 활용하고 있어요.
00:08:49Pi는 오픈 소스이면서 매우 확장성이 뛰어난 코딩 하네스(harness)입니다.
00:08:54저에게는 잘 맞더군요.
00:08:56어떤 기술을 어떻게 섞어야 할지, 어떤 기술이 필요할지 계속해서 고민하고 있습니다.
00:09:03확장 프로그램 같은 경우, Pi는 자체적으로 빌드할 수 있고 스스로 확장 프로그램을 만들게 할 수도 있는 정말 멋진 기능이 있어요.
00:09:11이런 부분들을 실험해보고 있는 중입니다.
00:09:13이게 바로 모든 개발자가 해야 할 일이라고 생각합니다.
00:09:16이런 기술들과 어떻게 협업할지 고민하는 것 말이죠.
00:09:19물론 계속 변하겠죠.
00:09:21내년쯤이면 또 달라질 겁니다.
00:09:24그럼에도 저는 이 과정이 굉장히 중요하다고 생각해요.
00:09:29모든 개발자가 해봐야 할 일입니다.
00:09:32물론 취미로 하거나 AI를 완전히 금지하는 회사에 다닌다면 신경 쓰지 않아도 괜찮겠지만요.
00:09:41AI를 완전히 무시해도 되는 환경에 있고 무시하고 싶다면 물론 그래도 됩니다.
00:09:48하지만 좋든 싫든 AI는 미래라고 생각합니다.
00:09:53그래서 모든 개발자가...
00:09:55네, 독일어를 잠깐 섞었네요.
00:09:57잠시 독일어가 튀어나왔네요.
00:10:00아무튼, 그 부분이 중요하다고 생각합니다.
00:10:03제 의견을 계속 반복하고 있네요.
00:10:06여전히 AI는 잠시 지나가는 유행일 뿐이라며 전혀 유용하지 않다고 생각하는 분들이 있는 것 같아요.
00:10:18물론 AI를 지나치게 많이 사용하거나 잘못된 곳에 쓸 수도 있지만, 쓸모없는 것은 절대 아닙니다.
00:10:25제 요점은 그거예요.
00:10:32네, 저도 이번 달에는 코드를 한 줄도 안 썼어요.
00:10:36네, 저도 줄어들긴 했습니다.
00:10:43대부분의 시간을...
00:10:45주석은 작성하죠.
00:10:48계획을 세우거나 구상하는 데 더 많은 시간을 보냅니다.
00:10:51가끔 코드를 직접 짜기도 하고요.
00:10:53네, 어쨌든 예전보다 많이 줄었습니다.
00:10:56Elm과 Elixir 조합에 대해 어떻게 생각하시나요?
00:10:58어떤 면에서 Elm은 운영 중에 오류가 안 나고 Elixir도 비슷한 성질을 가지고 있죠.
00:11:03사용해 보지 않아서 잘 모르겠네요.
00:11:06경험이 전혀 없는 분야에 대해 함부로 의견을 말하고 싶지 않아서요.
00:11:12죄송합니다.
00:11:14유데미 강의를 통해 자바스크립트를 배웠습니다.
00:11:17많이 배우셨군요.
00:11:18정말 기쁘네요.
00:11:19감사합니다.
00:11:20제가 독일어를 하냐고요?
00:11:21네, 할 줄 압니다.
00:11:23계속 취업하려면 새로운 기술이 할 수 있는 모든 것을 배우고 싶습니다.
00:11:28네.
00:11:29오늘 아침 Linus 영상처럼요.
00:11:31좋은 의견이에요.
00:11:32저에게는 여전히 즐거운 일입니다.
00:11:33네.
00:11:33중요한 건 재미있어야 한다는 거죠.
00:11:36이미 아시는 분도 있겠지만, 얼마 전에 올린 영상이 있는데 지금도 100% 맞는 말입니다.
00:11:46AI가 코딩의 즐거움을 앗아갔다는 내용인데, 지금 생각해도 그래요.
00:11:54정말 사실입니다.
00:11:56코드를 직접 작성하며 몰입했던 그 즐거운 시간을 정말 좋아했거든요.
00:12:02그건 이제 사라졌어요.
00:12:03그냥 사라진 겁니다.
00:12:04이제 저는 새로운 방식의 즐거움을 찾고 있습니다.
00:12:10요즘은 다양한 도구를 살펴보고 생산적인 환경을 구축하는 과정에서 큰 즐거움을 느껴요.
00:12:16AI로 프로젝트를 만들고 효과적으로 작업하는 방법을 알아가는 것 말이죠.
00:12:21그건 또 다른 종류의 즐거움입니다.
00:12:23솔직히 말씀드리면,
00:12:24AI가 없었더라도 슬프지는 않았을 거예요.
00:12:26하지만 이미 와버렸으니까요.
00:12:27받아들이거나 멀어지거나 선택해야겠죠.
00:12:29하지만 예전으로 돌아갈 수는 없습니다.
00:12:32하지만 재미가 사라졌다는 기분은 아주 잘 이해합니다.
00:12:42Claude와 ChatGPT 중 어떤 구독이 돈값을 할까요?
00:12:48ChatGPT 쪽이 훨씬 나아요. 지금은 제한을 거의 매일 초기화해주니까요.
00:12:52직접 쓸 수 있는 제한 초기화 기능도 주고요.
00:12:58네, 구독료 대비 얻을 수 있는 사용량을 고려하면 ChatGPT가 확실히 더 낫다고 봅니다.
00:13:06저는 200달러짜리 구독을 사용 중이에요.
00:13:08저렴한 플랜은 어떤지 모르겠네요.
00:13:11저는 Fable 같은 걸 해보고 싶어서 둘 다 구독하고 있습니다.
00:13:15Anthropic과 OpenAI의 200달러 플랜을 모두 쓰고 있죠.
00:13:19OpenAI 쪽에서 더 많은 것을 얻을 수 있는 건 확실해요.
00:13:26네, 바이브 코딩(vibe coding)을 해봤죠.
00:13:29프로젝트에 AI를 통합하는 걸 의미하시나요, 아니면 개발에 사용하는 걸 의미하시나요?
00:13:33저는 개발에 사용하는 것을 뜻합니다.
00:13:36물론 AI 기반 제품을 빌드할 수도 있죠.
00:13:38하지만 제 이야기는 개발에 사용하는 것 말이에요.
00:13:40잘 모르겠네요.
00:13:42그건 정말 중요합니다.
00:13:43계속 같은 말을 반복하게 되네요.
00:13:45바이브 코딩은 AI로 할 수 있는 작업 중 하나예요.
00:13:49어떻게 정의하느냐에 따라 달라지겠지만요.
00:13:52제 정의는, 제 생각일 뿐이지만요.
00:13:54꼭 같을 필요는 없어요.
00:13:55바이브 코딩이란 '코드에 신경 쓰지 않는다'는 뜻입니다.
00:14:01코드도 안 보고,
00:14:02어떻게 돌아가는지 전혀 신경 쓰지 않아요.
00:14:05그냥 뭔가를 만들 뿐이죠.
00:14:07결과물만 챙기는 겁니다.
00:14:10결과가 잘못되면 에러를 수정하고요.
00:14:16그리고 계획도 없고, 사양 같은 것도 없죠.
00:14:21그게 제가 정의하는 바이브 코딩입니다.
00:14:24여러분도 그렇게 할 수 있죠.
00:14:25말씀드렸듯이, 진지하지 않은 작업에는 괜찮다고 봅니다.
00:14:30아주 괜찮아요.
00:14:31하지만 그게 미래는 아닙니다.
00:14:34미래는 그런 게 아니에요.
00:14:36분명히 말씀드릴게요.
00:14:37미래는 뭐라고 불렸던 것인데,
00:14:40지금도 그렇게 부르는지는 모르겠지만,
00:14:42에이전트 기반 엔지니어링이죠, 맞나요?
00:14:43그게 바로 미래입니다.
00:14:48저는 이런 용어에 크게 신경 쓰지 않습니다.
00:14:50하지만 여기서 제가 말하는 것은 코드에 신경을 쓴다는 거죠.
00:14:54그렇다고 모든 코드를 직접 읽어야 한다는 뜻은 아닙니다.
00:14:58아마 코드 일부는 읽게 되겠죠.
00:14:59하지만 확실히 코드 자체에는 신경을 쓰게 될 겁니다.
00:15:02즉, AI와 여러분이 결합하여
00:15:05시스템을 구축하려고 노력한다는 의미입니다.
00:15:09좋은 코드를 생성하고, 코드를 검토하는 거죠.
00:15:11잘 작동하는 프로젝트를 가지고 있다고 신뢰할 수 있어야 합니다.
00:15:15계획, 사양, 테스트 전략 등을 실제로 만들어내는 것입니다.
00:15:22등등 말이죠.
00:15:22그 모든 것들이요.
00:15:24그게 바로 미래라고 생각합니다.
00:15:26개발자들이 지향해야 할 방향이라고 봅니다.
00:15:29또는 얻어야 할 것이죠.
00:15:31적어도 제 정의는 그렇고, 제 계획은 그렇습니다.
00:15:38계획에서 최종적으로 결정하려는 게 무엇인가요?
00:15:41단순히 요구 사항인가요, 아니면 기술적 구현까지 수정하려 하시나요?
00:15:44당연히 기술적 구현까지 포함됩니다.
00:15:46기술 스택에 관한 세부 사항들이죠.
00:15:48또한 세부적인 내용들도 포함되고요.
00:15:51저는 AI와 함께 매우 상세한 계획을 세우는 편입니다.
00:15:57그래서 기본적으로 제 워크플로우는, 나중에 프로젝트를 직접 볼 수도 있겠지만요.
00:16:01AI와 주고받는 방식이죠.
00:16:05논의하고, 계획을 만들게 합니다.
00:16:09그 계획이 어떤 모습이어야 하는지 AI에게 지침을 주는 기술을 가지고 있죠.
00:16:16그런 다음 계획을 검토하고 시간이 지나면서 세부적으로 조정합니다.
00:16:20아직도 가장 좋은 방법을 찾아가는 중입니다.
00:16:24오해하지 마세요.
00:16:25제 계획은 AI가 너무 방대하지도 않고,
00:16:30너무 작지도 않은, 제가 직접 조정한 계획을 만들게 하는 것입니다.
00:16:34그리고 구현하게 하죠.
00:16:36물론 작업의 복잡성에 따라
00:16:38제가 시간을 얼마나 쓸지가 달라지겠죠.
00:16:40그리고 검토 주기가 있고, AI 검토자도 있습니다.
00:16:44물론 중요한 부분은 저도 직접 검토합니다.
00:16:48결국 제가 접근하려는 방식은 그런 것입니다.
00:16:54네, 데브옵스 기술에 관한 강의 계획이 있냐고요?
00:16:59데브옵스 강의 자체는 흥미로울 것 같네요.
00:17:02하지만 다음 큰 강의는, 작은 강의들은 좀 있고요.
00:17:05곧 파이(Pi) 강의가 나올 예정입니다.
00:17:07다음 대규모 강의는 아마 시스템 디자인 강의가 될 것입니다.
00:17:19디스코드 개인 메시지는, 솔직히 말해서 제가 그걸 켜둔 줄도 몰랐네요.
00:17:25한 번도 읽지 않았거든요.
00:17:26기억이 나면 한번 확인해 보겠습니다.
00:17:28하지만 안타깝게도 약속은 못 드립니다.
00:17:33기억하도록 노력은 해볼게요.
00:17:37K3가 소네트 3.5(Sonnet 3.5)와 같은 가격이라고요, 빅 L(Big L)?
00:17:40성능에 따라 다르지 않을까 싶네요.
00:17:42아직 공식적인 건 읽어본 적이 없습니다.
00:17:44방송하는 동안 무슨 일이 있었나 보네요.
00:17:48AI로 새 프로젝트를 시작하는 데 어려움을 겪고 계시군요.
00:17:51부트스트랩 과정이 저에게도 낯섭니다.
00:17:53생성된 코드 속에서 나 자신을 찾는 데 시간이 걸리거든요.
00:17:55개인적인 문제일 수도 있겠네요.
00:17:57네, 저도 힘들긴 합니다.
00:18:00대부분의 개발자, 많은 개발자들이 힘들어하고 있다고 생각합니다.
00:18:03게다가 '바이브 코딩'의 함정에 빠지기도 아주 쉽죠.
00:18:06오해하지 마세요.
00:18:07제 말은, 모든 것을 깔끔하게 설정하고 제어하겠다는 의도로 시작하기가 너무 쉽다는 겁니다.
00:18:14그러다 보면 어느새 프롬프트만 입력하고 있고, 그 '바이브 코딩'의 함정에 깊숙이 빠져들게 되죠.
00:18:21아니면 아까 말했듯이 저는 실험을 많이 합니다.
00:18:24최신 유행이 루프(loops)인데, 루프를 설계해야 한다는 말을 들어서 시도해 보려 했죠.
00:18:32즉, 에이전트가 스스로 매우 오랫동안 작업할 수 있는 전체 시스템을 만드는 겁니다.
00:18:36그래서 루프, 즉 구현 루프를 만들기로 했습니다. 계획을 세우고 에이전트에게 주는 방식이죠.
00:18:42그럼 에이전트가 하위 에이전트를 가동해 작업을 수행하고, 검토하고, 제가 좋은 결과물을 받을 때까지 계속하는 겁니다.
00:18:51그런데 제가 쓴 스킬과 프롬프트 때문인지, 아니면 모델 때문인지, 이유는 모르겠지만,
00:19:00계속해서 문제를 찾아내는 소용돌이에 빠졌고, 그 문제들은 점점 더 난해하고 구석진 것들이 되어갔습니다.
00:19:11그래도 어디까지 가나 궁금해서 그냥 내버려 뒀죠.
00:19:16하지만 4시간 정도 지나서 멈췄습니다. 점점 더 깊이 빠져들기만 하는 걸 봤거든요.
00:19:21저는 아주 기본적인 제품을 만들고 있었거든요.
00:19:24본질적으로는 AWS SES 위에서 뉴스레터나 마케팅 이메일을 보내는 저만의 서비스를 만들고 있었죠.
00:19:35저는 저만의 서비스를 구축 중이었고요.
00:19:37그런데 AI는 계속해서 더 깊게 파고들기만 했습니다.
00:19:40결국 프로젝트는 너무 복잡해졌고, 실제로는 발생할 수도 없는 수많은 틈새 사례까지 다루게 되었습니다.
00:19:49다시 말하지만, 이건 제 자가 호스팅 이메일 발송 서비스였으니까요. 나중에 오픈 소스로 공개해서 다른 사람들의 자가 호스팅에 도움이 될 수도 있고, 고객에게 열어줄 수도 있었겠죠.
00:20:03하지만 그건 지금 당장의 의도가 아니었습니다.
00:20:07이게 빠질 수 있는 여러 덫 중 하나라고 생각합니다. 빠질 수 있는 덫이 정말 많거든요.
00:20:11갑자기 어느 정도 똑똑하고 어느 정도는 똑똑하지 않은, 최소한 최근 모델들은 일을 아주 열심히 하려는, 일종의 직원을 하나 얻게 되는 거니까요.
00:20:31하지만 항상 작업 방식을 제대로 생각하는 건 아니죠, 쉽게 말해서요.
00:20:42그리고 질문했을 때, '이 코드에 문제가 있나요?'라고 물으면 항상 '네'라고 답하는 직원이기도 하죠.
00:20:49따라서 AI와 효율적으로 일하는 것은 복잡한 문제입니다.
00:20:54그럼에도 불구하고 여전히 그런 것들을 파악하는 게 중요하다고 생각합니다. 분명 AI 에이전트가 코드를 빠르게 작성할 수 있다면 훨씬 더 빠를 수 있으니까요.
00:21:08더 나쁠 수는 없겠죠.
00:21:10물론 올바르게 제어하지 못하면 더 나빠질 수도 있습니다.
00:21:14하지만 그건 학습 과정입니다.
00:21:15이건 아주 새로운 기술이니까요.
00:21:17모든 것이 정말 빠르게 진화하고 있죠.
00:21:19아직 완전히 파악되지 않은 게 당연합니다.
00:21:22적어도 제 생각은 그렇습니다.
00:21:24앞으로 모든 것을 손으로 직접 코딩하는 구시대적인 방식이 더 나을 거라고는 전혀 생각하지 않습니다.
00:21:33다시 말하지만, AI가 모든 것을 다 하는 세상이 승자가 될 거라는 생각도 들지 않고요.
00:21:40그건 옳게 들리지 않네요.
00:21:43하지만 도구로서 효율적으로 사용하는 방법은 인지하고 있고, 대부분의 개발자들이 찾으려 노력하고 있다고 봅니다.
00:21:52네, 채팅에서 읽었는데, 저는 코드에 대한 완전한 지식을 갖는 것을 좋아합니다.
00:21:59네, 그것도 이상한 부분 중 하나죠.
00:22:02코드로부터 조금 멀어지게 되니까요.
00:22:05바이브 코딩을 하지 않더라도, 말씀드렸듯이 코드를 검토하기 때문에 조금 멀어진 느낌이 듭니다.
00:22:17일부 중요한 부분을 살펴보긴 하지만, 여전히 처음부터 끝까지 직접 작성한 것과는 다릅니다.
00:22:22특히 두 프로젝트를 동시에 작업하기 시작하면 좀 위험할 수도 있죠.
00:22:28하지만 코드베이스에서 무슨 일이 일어나고 있는지 추적을 놓칠 수도 있습니다.
00:22:33코드를 검토했고 품질이나 프로젝트 진행 방향에는 만족할지 모르지만요.
00:22:40그래도 저에게는 처음부터 직접 작성한 것과는 여전히 같지 않습니다.
00:22:47아니면 어쩌면 제 뇌가 무언가를 기억하는 데 충분히 좋지 않은 걸 수도 있죠.
00:22:53그럴 수도 있겠네요.
00:22:58에이전트 엔지니어링은 너무 복잡해서 좋은 SEO 키워드가 아니군요.
00:23:01그럴지도 모르죠, 모르겠습니다.
00:23:04현장 배치 엔지니어링(forward deployed engineering)에는 무엇이 더 필요할까요?
00:23:07네, 솔직히 말씀드릴게요.
00:23:11새로 만들어진 그 모든 이상한 용어들에 대해서는 제가 크게 언급할 수 있는 게 없습니다.
00:23:20특히 AI 시대에 그것이 정확히 무엇을 의미하는지조차 잘 모르겠습니다.
00:23:27저는 그런 모든 유행어에 별로 신경 쓰지 않습니다.
00:23:30그냥 소프트웨어 제품을 잘 만드는 소프트웨어 엔지니어가 되고 싶을 뿐이라고 생각합니다.
00:23:36즉, 코드로 된 디지털 제품들이죠.
00:23:40제 생각에는 AI가 그것과 관련이 있고요.
00:23:44그걸 잘하고 싶으신 거겠죠.
00:23:45이것도 전에도 말했었죠.
00:23:49개발자들이 좀 더 제너럴리스트가 되는 변화가 있을 거라고 생각합니다.
00:23:56깊은 전문 지식이 없는 기술로도 일하기가 더 쉬워졌으니까요.
00:24:03또한 시스템 디자인과 코드 아키텍처에 대한 질문들이 더 중요해질 거라고 믿습니다.
00:24:12죄송합니다.
00:24:13그래서 제가 믿는 미래는 조금 다를 겁니다.
00:24:18소프트웨어 엔지니어링은 항상 그런 것이었다고 주장할 수도 있겠고, 아마 사실일 겁니다.
00:24:24잘 모르겠네요.
00:24:25물론 '소프트웨어 엔지니어링'이라는 용어는 과거부터 오늘날까지 매우 광범위하게 사용되어 왔습니다.
00:24:32분명히 코딩이 포함되어 있었죠.
00:24:34그런데 코드를 작성하는 부분은 상당 부분, 아니면 완전히 사라져가고 있습니다.
00:24:42그렇다고 해서 코드와 상호작용하지 않는다는 것은 아닙니다.
00:24:46단지 완전히 다른 방식일 뿐이죠.
00:24:49Bun이 AI를 사용해 프로젝트 전체를 재작성했다는 건 정말 미친 짓이죠.
00:24:53네.
00:24:53정말 흥미로운 작업이었다고 생각합니다.
00:24:57물론 앤스로픽 모델에 자유롭게 접근할 수 있다면 조금 더 쉽겠죠.
00:25:04하지만 꽤 인상 깊었습니다.
00:25:06그리고 제 유튜브 영상 댓글을 보니 모든 사람이 그렇게 생각한 건 아니더군요.
00:25:11그래도 저는 인상적이었습니다.
00:25:13그걸 꼭 좋다고 생각할 필요는 없습니다.
00:25:16하지만 그 전체적인 구축 과정은 정말 인상적이었습니다.
00:25:23인상 깊게 봤습니다.
00:25:31취업할 때 개인 프로젝트를 가지는 것이 가치가 있을까요?
00:25:34아니면 고용주들은 그냥 AI가 만든 슬롭(slop)으로 간주할까요?
00:25:37네, 좋은 질문입니다.
00:25:39고용주들은 분명 엄청난 지원서들 속에 파묻히고 있습니다.
00:25:42개인 프로젝트는 여전히 중요할 수 있다고 생각합니다.
00:25:45하지만 예전 방송들에서도 말했듯이, 취업할 때는 눈에 띄는 방법을 찾아야 합니다.
00:25:52그게 그 어느 때보다 어려워졌죠.
00:25:53눈에 띄는 데 중요한 부분 중 하나가 소셜 미디어 활동일 수 있습니다.
00:25:59꼭 유튜버가 되어야 한다는 뜻은 아닙니다.
00:26:03X나 링크드인, 유튜브 등 본인이 선호하는 플랫폼에 흥미로운 내용을 꾸준히 공유하는 것만으로도 충분합니다.
00:26:09포트폴리오나 개인 프로젝트 외에도 이런 활동이 도움이 된다고 봅니다.
00:26:18저는 저만의 사양 중심 개발(spec-driven development) 프레임워크를 만들었습니다.
00:26:26코드는 거의 확인하지 않죠.
00:26:29네, 앞서 언급했듯이 이 모든 것은 계속 진화할 것이고, 구체적으로 어떤 모습이 될지 모두가 여전히 파악해 나가는 중이라고 생각합니다.
00:26:39코드에 신경 쓴다는 게 모든 코드를 읽는다는 뜻은 아닙니다.
00:26:42절대 아니죠.
00:26:43이전에도 코드를 검토할 때 모든 코드를 읽지는 않았던 것과 마찬가지니까요.
00:26:47데이터는 변하지 않았습니다.
00:26:49물론 접근 방식은 바뀌고 있죠.
00:26:54시스템 디자인 강의 출시일이 언젠가요?
00:26:57여전히 몇 주 더 걸릴 것 같습니다.
00:27:04미래에 말이죠.
00:27:05면접 방식도 바뀔 거라고 생각합니다.
00:27:18지금은 아주 짜증 나는 시기예요.
00:27:20지금은 정말 성가신 시기입니다.
00:27:22기술이 빠르게 변화하고 있으니까요.
00:27:27저처럼 최첨단 모델과 도구들을 항상 사용할 수 있는 혜택을 누리는 사람도 있고, 직접 파이를 써보고 커스터마이징하거나 클라우드 코드를 시도해 보는 사람들도 있죠.
00:27:34반면에 직원들에게 최신 모델을 제공하지 않거나,
00:27:40대부분 코딩 에이전트를 자유롭게 선택하도록 허용하지 않을 회사들도 있을 겁니다.
00:27:46아예 사용하지 않는 회사들도 있고요.
00:27:52나쁜 모델을 쓰면서도 저 같은 사람들의 영상을 보고 AI로 뭐든지 할 수 있다고 믿으며 기적을 바라는 관리자들도 있죠.
00:27:54회사에서 쓰는 AI가 남들이 쓰는 것과 다르다는 걸 모르는 겁니다.
00:28:00그리고 2020년 방식에 머물러 있는 구식 면접 절차들도 있겠죠.
00:28:03어떤 기술이든 변화할 때면 항상 마찰이 생기기 마련이고, 그게 현재 우리가 겪는 AI 진화의 짜증 나는 부분입니다.
00:28:07분명 면접 과정들이 따라가지 못하는 경우가 많을 겁니다.
00:28:17모든 기술 변화가 그렇듯, 이번 변화도 빠르게 진행되면서 엄청난 마찰을 빚고 있으며, 우리가 현재 겪는 AI 시대의 가장 번거로운 부분 중 하나일 것입니다.
00:28:37그래서 좌절감이 드는 건 충분히 이해합니다.
00:28:39안타깝게도, 각 회사가 이 여정의 어디에 있는지에 따라 다르기 때문에 현명한 조언을 드리기가 어렵네요.
00:28:55졸업반이시고 제 강의로 리액트를 배우셨다니, AI 시대에 커리어를 빛낼 수 있는 팁을 드릴게요.
00:29:02앞서 말씀드렸듯이, 이 방송 기록은 남을 테니 놓친 부분은 나중에 다시 확인해 보세요.
00:29:10AI를 공부하고 그것을 효과적으로 활용하는 방법을 익히셔야 합니다. 이건 오후 한나절 만에 되는 게 아니라, 도구들과 씨름하며 좋은 결과를 내는 방법을 스스로 터득해 나가는 과정입니다.
00:29:26저도 매일 같이 더 나은 결과를 얻기 위해 시간을 쏟고 있습니다. 변화가 너무 빠르니까요.
00:29:33우리 회사는 바이브 코딩을 지원하는데, 저는 에이전트 엔지니어링을 하면서 바이브 코더 동료와 같은 속도로 작업해요. 그런데 동료는 항상 자기가 짠 코드의 버그를 고치는 걸 힘들어하고, 저는 그렇지 않거든요.
00:29:44네, 제 말은, 다시 말하지만 바이브 코딩이 진지한 프로젝트에 좋은 아이디어라고 생각하지 않습니다.
00:29:51말씀드렸듯이 일회용 소프트웨어에는 분명 괜찮겠지만, 무언가를 유지보수해야 한다면 바이브 코딩은 그야말로 악몽이라고 생각합니다.
00:30:01프론트엔드 개발과 AI를 어떻게 연결할지 아직 파악하지 못하셨고, 백엔드는 수학과 비슷하다고 하셨네요.
00:30:05좋은 증명을 쓰면 코드가 잘 작동하지만, UI는 아직 그 격차를 좁히지 못해 고민이시군요.
00:30:10네, UI 관련 작업의 단점은 말씀하신 그대로입니다.
00:30:16검증하기가 조금 더 어렵죠.
00:30:18물론 AI가 브라우저를 사용할 수는 있죠.
00:30:23Playwright나 Vercel의 Agent Browser 같은 도구를 쓸 수 있으니까요.
00:30:28그런 방법들도 있지만, 제 경험상 여전히 수동 테스트가 많이 필요하긴 합니다.
00:30:38UI 작업 실력에 있어서는 모델마다 차이가 매우 큽니다.
00:30:44정말 UI 작업에 대해서만 이야기한다면, UI 뒤의 로직은 당연히 단위 테스트 등으로 테스트할 수 있고요.
00:30:53그래서 저도 그 부분은 그렇게 하고 있습니다.
00:30:56앞으로 고용주들이 AI로만 결과물을 만든 사람들을 걸러내기 위해 학위 필터를 더 많이 사용하게 될까요?
00:31:03네, 그럴 가능성도 있죠.
00:31:04잘 모르겠네요.
00:31:05저도 모르겠어요.
00:31:05쏟아지는 지원자들 사이에서 필터링하기 위해 학위나 자격증을 요구할 수도 있을 것 같아요.
00:31:13그런 위험성은 분명히 있다고 봅니다.
00:31:15저 스스로도 독학으로 공부했기 때문에 학위나 자격증만 따지는 것을 좋아하지 않아서 그게 위험하다고 생각해요.
00:31:23충분히 일어날 수 있는 상황 중 하나라고 생각합니다.
00:31:29동시에 우리는 그것이 반드시 좋은 필터는 아니라는 점도 알고 있지만, 실제로 그렇게 될 수도 있겠죠.
00:31:39이제 고객들의 불신이 예전보다 더 커진 걸까요?
00:31:42예를 들어 제가 어떤 회사에 일을 맡기려 한다면, 그들이 AI를 쓰기 때문에 믿지 않을 것 같거든요.
00:31:46어떤 경험을 하셨나요?
00:31:46네, 그건 정말 흥미로운 질문인데 저도 정확히 같은 기분을 느끼거든요.
00:31:54만약 제가 다른 계약자에게 외주를 맡긴다면 그들도 아마 AI를 사용할 거라고 가정할 거예요.
00:32:02물론 그게 반드시 문제는 아니죠, 저도 AI를 사용하니까요. 하지만 최악의 경우를 상상하게 되거나, 그들이 제대로 된 방식으로 일을 하지 않을 거라고 생각하게 될 겁니다.
00:32:16계약자 입장에서는 당연히 여러 고객의 일을 빠르게 처리하고 싶은 유인이 있으니까요.
00:32:23그래서 이런 신뢰 문제가 발생할 것이라 봅니다.
00:32:25또 지금 시점에서는 아직 AI를 활용해 직접 개발할 줄 모르거나, 그러고 싶지 않은 기업들이 존재한다는 사실을 이용해 돈을 벌 기회도 있다고 봅니다.
00:32:48치과 의사가 웹사이트가 필요하다고 가정해 보죠.
00:32:49여전히 계약자들에게 외주를 맡길 겁니다.
00:32:53계약자들은 여전히 예전 시간당 단가를 청구하겠죠.
00:32:57AI 덕분에 2시간이면 끝날 일을 10시간 치로 청구하는 식이죠.
00:33:06지금 그런 기회가 존재한다고 생각합니다.
00:33:10그게 아주 윤리적이라고 할 순 없겠죠.
00:33:13하지만 왜 그런 일이 일어나는지는 이해합니다.
00:33:16하지만 그런 기회도 결국 사라질 거예요.
00:33:18동전의 반대편을 보면, 바로 그런 이유로 인해 이미 상황을 파악한 사람들에게는 신뢰 문제가 생기는 거죠.
00:33:29AI 이후에도 DSA(자료구조와 알고리즘)와 오픈 소스 기여가 여전히 관련이 있을까요?
00:33:42아니요, 잠시만요.
00:33:43제가 뭘 건너뛴 것 같네요, 그렇죠?
00:33:49좋아요, 여기 있네요.
00:33:50다른 질문으로 돌아갈게요.
00:33:51그나저나 질문이 하나 들어왔네요.
00:33:54네, 그 질문들에 다시 답변드릴게요.
00:33:56그래서 Pi 코스는 다음 주쯤 나올 예정입니다.
00:34:02Polar를 사용한다고 언급하셨는데, 결제 플랫폼으로 Cream을 사용해본 경험이 있으신가요?
00:34:07아뇨, Cream은 사용해본 적 없고 Polar만 써봤습니다.
00:34:10죄송합니다.
00:34:13시스템 설계와 AI 시스템 설계를 배우고 있는데, AI나 ML 같은 수학적인 부분까지 깊이 들어가고 싶진 않아요.
00:34:19그래도 충분할까요?
00:34:20전 AI나 ML 배경지식이 전혀 없습니다.
00:34:22그러니 정말 AI나 ML 관련 전문적인 내용은...
00:34:27그 부분에 대해서는 조언하기가 어렵네요.
00:34:30애플리케이션 개발 관점에서 말하는 시스템 설계의 경우, 수학적인 지식은 중요하지 않습니다.
00:34:38AI나 ML 쪽은 다를 수 있겠지만요.
00:34:41어쨌든 저는 그쪽 전문가가 아니에요.
00:34:43그래서 판단하기 어렵네요.
00:34:47그 질문에도 비슷한 답변을 드려야겠네요.
00:34:49제 목표는 AI, ML 엔지니어가 되는 것입니다.
00:34:52하지만 어디서부터 시작해야 할지 모르겠어요.
00:34:53어디에 집중해야 할지 팁을 주실 수 있나요?
00:34:57그건 제 분야가 아닙니다.
00:34:59저는 전문가가 아니에요.
00:35:01그래서 제가 답해드리기엔 부적절한 사람 같습니다.
00:35:04죄송합니다.
00:35:05AI 이후에도 DSA와 오픈 소스 기여가 여전히 관련이 있을까요?
00:35:13지금 당장은 여전히 그것을 중요하게 생각하는 기업들이 있어서 관련이 있다고 봅니다.
00:35:20개인적으로는 일부 기업의 면접 방식이나 그 DSA 관련 내용의 중요성에 대해서는 딱히 좋아하지 않았습니다.
00:35:29하지만 동의하지 않는 개발자분들도 분명히 계실 거예요.
00:35:33저는 점점 덜 중요해질 것이라고 봅니다.
00:35:34여전히 중요한 것은 당신이 문제에 대해 논리적으로 생각할 수 있다는 것을 증명하거나 보여주는 능력일 거예요.
00:35:42소프트웨어 솔루션을 설계할 수 있다는 능력이죠.
00:35:47자료구조와 알고리즘이 그것에 도움을 줄 수는 있고, 고용주들이 여전히 그것을 찾을 수도 있겠죠.
00:35:56하지만 결국 고용주들도 AI를 잘 활용하는 개발자를 채용하면서 동시에 그런 모든 자료구조를 손으로 구현하기를 기대할 수는 없다는 사실을 깨달을 겁니다.
00:36:06반면에 코드 자체를 쓰지 않더라도 의사코드(pseudocode)로 구현할 수 있어야 한다는 주장을 할 수도 있겠죠.
00:36:12하지만 장기적으로 어떤 변화가 있을지는 잘 모르겠어요.
00:36:24저는 그 부분에 대해서는 전혀 걱정하지 않을 것 같아요.
00:36:28만약 제가 채용하는 입장이라면 전혀 신경 쓰지 않을 겁니다.
00:36:31저는 그 사람이 AI를 어떻게 사용하는지 보고 싶을 거예요.
00:36:34무작정 AI에게 코딩을 맡기는지, 아니면 계획이 있는지,
00:36:38전략이 있는지, 정말 우리 비즈니스에 합리적인 방식으로 문제를 해결하는지 등을 훨씬 더 중요하게 볼 것입니다.
00:36:47하지만 그건 물론 제 생각일 뿐이죠.
00:36:49제 관점입니다.
00:36:51베를린의 한 회사가 자격증 요건을 없애고 업무 경력을 더 중요시하기로 했다네요.
00:36:56네, 저는 예전부터 자격증보다는 실제로 어떤 업무를 했고 무엇을 경험했는지를 증명하는 것을 항상 선호했습니다.
00:37:04저는 그게 어떤 자격증보다 가치 있다고 생각하지만, 그럼에도 특정 기업에서는 여전히 자격증이 중요할 겁니다.
00:37:15그건 어쩔 수 없는 현실이죠.
00:37:18에이전트 코딩을 사용하면서부터 무엇을 할지, 어떻게 구현할지에 대해 깊이 고민하고 끊임없이 결정과 판단을 내려야 한다고 느껴요.
00:37:29예전에는 그게 작업의 20% 정도였고 코딩 자체는 편안하고 즐거웠거든요.
00:37:34제프 베조스가 말했듯이, 하루에 내릴 수 있는 좋은 결정의 수는 한정되어 있잖아요.
00:37:38어떤 경험을 하셨나요?
00:37:39생산적인 에이전트 작업을 하는 개발자들은 더 많은 휴식 시간이나 휴일을 가져야 하지 않을까요?
00:37:44정말 훌륭한 질문이자 관찰입니다.
00:37:48저도 정확히 같은 경험을 하고 있거든요.
00:37:51질문자님께서 정확히 짚어주셨네요.
00:37:56저도 똑같아요.
00:37:57코드를 직접 작성하는 부분은 저에게 휴식과 같았거든요.
00:38:03몰입 상태(flow state)였죠.
00:38:04이제 좋은 점은 코드를 작성하는 동안에도 의사결정을 내렸다는 거예요.
00:38:09항상 큰 결정은 아니더라도요.
00:38:10때로는 그랬지만요.
00:38:11하지만 그게 정말 말씀하신 대로 휴식 같은 부분이었어요.
00:38:14지금은 힘들 결정만 남았죠.
00:38:19특히 세 가지 프로젝트를 동시에 작업하기 시작하면, 검토할 계획이나 구현 사항들이 있다는 에이전트들의 호출을 계속 받게 되거든요.
00:38:32아니면 검토해야 할 리뷰어 에이전트의 피드백도 있고요.
00:38:36물론 무시하고 '그래, 계획대로 구현해'라고 할 수도 있겠죠.
00:38:40'그래, 에이전트가 찾은 문제들을 수정할 계획을 세워봐'라고 할 수도 있겠고요.
00:38:46하지만 그러면 결국 바이브 코딩(Vibe Coding)의 영역으로 빠져드는 겁니다.
00:38:51제 생각은 그래요.
00:38:52어쩌면 1년 뒤에는 도구와 모델이 너무 좋아져서 더 높은 수준의 복잡한 루프 작업을 하게 될지도 모르겠네요.
00:39:02잘 모르겠네요.
00:39:02하지만 지금 당장은 저에게 그렇게는 안 돼요.
00:39:05하지만 말씀하신 대로, 복잡한 결정들을 끊임없이 마주하게 되죠.
00:39:09갑자기 계획을 다시 읽기 시작해야 해요.
00:39:11'내가 지금 뭘 하고 있는 거지?'라는 생각이 들죠.
00:39:14계획이 맞는지 검증해야 합니다. 맹목적으로 받아들이기만 할 거면 계획을 볼 필요도 없으니까요, 그렇죠?
00:39:21그래서 그 부분은 전적으로 동의합니다.
00:39:23휴식을 더 취하거나 다른 일을 섞어서 하는 게 좋다고 생각해요.
00:39:30하지만 저는 그걸 잘 못해요.
00:39:33계속 에이전트들이 그런 작업을 하게 두니까 자주 지치게 되더라고요.
00:39:41끊임없이 쏟아지는 복잡한 결정의 흐름을 마주하고 있으니까요.
00:39:48제가 아마 잘못하고 있는 걸지도 모르죠.
00:39:50그래도 정말 좋은 지적이시네요.
00:39:55Udemy에서 구매한 코스를 Academind에서 액세스할 수는 없습니다.
00:39:59그 반대도 마찬가지고요.
00:40:00독립된 플랫폼들이라 Udemy의 등록이나 기타 사항에 대해 우리가 통제할 수 있는 게 없거든요.
00:40:07게다가 솔직히 말씀드리면, Udemy에서 코스를 구매하시면 우리는 상당한 수수료를 Udemy에 지급해야 합니다.
00:40:22하지만 우리 플랫폼으로 누군가를 데려오면, 우리는 그에 대한 모든 기술적 지원과 책임을 져야 하죠.
00:40:31Udemy에서는 그게 Udemy의 책임이고요.
00:40:34따라서 설령 기술적으로 가능하다고 해도, Udemy에서 구매하신 분들을 우리 사이트로 무료로 이전해 드리는 것에 대해 아주 긍정적이기는 어렵습니다.
00:40:44결국 모든 책임은 우리가 져야 하니까요.
00:40:46어쨌든 기술적으로도 안 되기 때문에 이 질문에 대한 논의는 성립하지 않습니다.
00:40:54그래서 그냥 솔직하게 말씀드리는 거예요.
00:40:59저희가 해드릴 수 있는 일이 아닙니다.
00:41:01그건 저희가 할 수 있는 부분이 아니에요.
00:41:07정말 팬입니다.
00:41:08배운 것들에 대해 감사드려요.
00:41:10덕분에 React, Next.js, Go를 배웠습니다.
00:41:12정말 감사드려요. 좋은 피드백 감사합니다.
00:41:14코스가 도움이 되었다니 정말 기쁘네요.
00:41:18Laravel, Node.js, Vue 등으로 7년 경력을 쌓은 풀스택 엔지니어입니다.
00:41:22커리어 성장을 극대화하려면 다음에 무엇에 집중해야 할까요?
00:41:26앞서 말씀드린 것과 본질적으로 같습니다. 다른 분들이 지루하지 않게 짧게 답변할게요.
00:41:29정말 AI와 효율적으로 협업하는 방법입니다.
00:41:33지금 모든 개발자가 반드시 터득해야 할 부분이라고 생각합니다.
00:41:3724시간 내내 하라는 게 아니라, 정말 어떻게 하면 AI와 효과적으로 협업할 수 있을지 진지하게 연구해 보는 것인데, 저에게도 이게 생각보다 더 어렵더군요.
00:41:47하지만 우리 모두가 노력해야 할 부분이라고 생각합니다.
00:41:56WebAssembly가 프론트엔드 개발에 적합하다고 보시나요?
00:41:59결국 애플리케이션 개발에서 자바스크립트만큼 흔해질까요, 아니면 특정 성능 중심의 시나리오에 제한적으로 남을까요?
00:42:06몇 년 전이었다면 WebAssembly는 아마 성능이 중요한 상황에 제한적으로만 사용될 것이라고 했을 겁니다.
00:42:14이제는 꼭 그렇지도 않다고 생각해요.
00:42:19자바스크립트를 완전히 대체하거나 프론트엔드 코드 실행 분야에서 자바스크립트보다 더 주류가 되지는 않을 것 같습니다.
00:42:28하지만 AI 덕분에 코드를 작성하고 WebAssembly로 컴파일하거나 버그를 디버깅하는 수많은 장벽들이 허물어지거나 더 이상 존재하지 않게 되었다고 봅니다.
00:42:45그래서 미래에는 더 중요해질 수는 있지만, 여전히 일종의 틈새 기술로 남을 것 같아요.
00:42:59목요일마다 당신의 방송을 기다립니다.
00:43:01네, 다시 돌아왔습니다.
00:43:02지난 몇 주 동안 오지 못해 죄송합니다.
00:43:04아까 처음에 말했듯이,
00:43:05살다 보면 때로는 뜻대로 안 될 때가 있죠. 그래도 방송에 다시 복귀하게 되어 정말 기쁩니다.
00:43:11LangGraph와 LangChain 코스는 계획에 없습니다. 3년 전쯤 조금 다뤄본 적은 있지만 제가 그 분야 전문가는 아니거든요.
00:43:25그래서 관련 코스는 없습니다.
00:43:27개발보다는 소프트웨어를 디버깅하고 수정하는 기술 지원이나 SRE(사이트 안정성 엔지니어) 같은 일자리가 많다고 생각하시나요?
00:43:34네, 아마 그럴 수도 있겠네요.
00:43:38그러니까 그냥 말하자면,
00:43:41소프트웨어를 수정하는 것 또한 빌드(개발)의 일환이라고 봅니다.
00:43:45단순히 디버깅이나 분석에 대해서만 말하자면, 앞으로 AI가 그런 일을 점점 더 많이 하게 되지 않을까 싶네요.
00:43:58최고의 영상들 감사합니다.
00:43:59당신의 통찰력을 높이 평가합니다.
00:44:00감사합니다.
00:44:01긍정적인 피드백 감사합니다.
00:44:03정말, 정말 감사합니다.
00:44:04정말 감사합니다.
00:44:08GitHub Copilot은 7000 토큰 프로 플러스 버전조차 돈이 끊임없이 들어요.
00:44:13네, 저는 GitHub Copilot을 더 이상 사용하지 않습니다.
00:44:17지금 시점에서 가성비가 가장 좋은 건 ChatGPT 구독입니다.
00:44:23OpenAI 거가 괜찮은 게, 제한 리셋을 자주 해주거든요.
00:44:28Anthropic도 괜찮습니다.
00:44:30적어도 제가 느끼기엔 사람들이 말하는 것만큼 나쁘진 않아요.
00:44:33하지만 ChatGPT가 확실히 더 좋은 조건이긴 합니다.
00:44:38Grok도 나쁘지 않은데, 제가 마침 X 구독을 하고 있어서 말이죠.
00:44:45실제로 사용하기에 충분히 괜찮은 결과를 얻을 수 있습니다.
00:44:53AI로 제 프로젝트를 빌드하다 보면 가끔 정말 수준 높은 코드가 나오는데, 정말 훌륭하거든요.
00:44:59하지만 그 내용을 이해하기가 어려울 때가 있습니다.
00:45:01어떻게 하는 게 좋을까요?
00:45:02네, 그 코드를 가지고 AI와 토론해 보세요.
00:45:04AI는 코드 작성만 잘하는 게 아니거든요.
00:45:07'이 코드가 무슨 일을 하는 거야?'라고 물어볼 수도 있고요.
00:45:09'이걸 다른 방식으로 빌드하려면 어떻게 해야 할까?'라고 질문해 보세요.
00:45:13'우리는, 아니 그러니까 AI인 당신은, 왜 이걸 이렇게 짰어?'라고요.
00:45:16왜 이런 식으로 빌드했는지 물어보세요.
00:45:19계속 질문하고 설명하게 만드세요. 단순히 코드뿐 아니라 왜 그렇게 짰는지, 어떤 일을 하는지, 다른 방식은 없었는지, 왜 그 방식은 안 썼는지 파고드세요.
00:45:28AI가 작성한 코드에 대해 배우고, 학습하는 과정에 있다면 전반적인 코딩 실력을 키우는 데에도 정말 좋은 방법이라고 생각합니다.
00:45:37이미 특정 기술이나 언어를 알고 있더라도 가끔씩 '왜 이렇게 짰어?'라고 AI를 자극해 보는 건 여전히 좋은 생각일 수 있어요.
00:45:48'왜 다른 방법으로는 안 했어?'라고요.
00:45:51만약 다른 방법을 알고 있다면, '왜 이 방식은 안 썼어?'라고 물어볼 수도 있겠죠.
00:45:56제 경험상 AI는 종종 '아, 맞네요. 그렇게 하는 게 더 나았겠네요'라고 말하곤 합니다.
00:46:01그럼 '그럼 왜 그렇게 안 했어?'라고 다시 물어볼 수도 있고요.
00:46:04'이 방식이 왜 안 좋아?'라고도요.
00:46:05'안 좋은데 왜 처음에 선택한 거야?'라고 물어보세요.
00:46:07AI는 여전히 사용자를 기쁘게 하려는 경향이 있지만, 그 과정을 통해 통찰력을 얻을 수 있고 확실히 코드에 대해 더 많이 배울 수 있다고 말하고 싶네요.
00:46:24에이전트 엔지니어가 되려면 개발자나 프로그래머여야만 할까요?
00:46:27그렇다고 생각하고, 또 그래야 한다고 봅니다.
00:46:30네, 에이전트 엔지니어는 개발자가 다음 단계로 진화하는 과정이라고 생각하거든요.
00:46:38이제는 더 이상 제가 예전에 배웠던 방식으로 코딩을 배우지 않을 것 같아요.
00:46:45대신 저는 AI 시대를 위해 코딩을 배울 겁니다. 즉, 직접 작성하는 코드는 줄이되, 소프트웨어와 코드 내부에서 어떤 일이 일어나는지에 대한 이해는 여전히 갖추는 거죠.
00:46:57사용하게 될 패턴이나 소프트웨어를 구성하는 빌딩 블록, 그리고 좋은 소프트웨어를 설계하는 방법에 대한 이해도 여전히 필요하고요.
00:47:07그런 모든 요소들, 어떤 문제나 잠재적인 이슈를 주의 깊게 살펴봐야 할지, 그리고 반대로 어떤 문제는 무시해도 될지에 대한 판단력도 중요합니다.
00:47:17왜냐하면 AI에게 단순히 "이 코드 리뷰해줘, 아주 비판적으로 봐줘"라고 하면,
00:47:23어떤 의견인가요?
00:47:24본인에게는 문제가 아닐 수도 있는 수많은 이슈들을 들춰낼 테니까요.
00:47:27그런 판단력을 갖추는 것이 정말 중요하다고 생각합니다.
00:47:31그렇지 않으면 시간이 지날수록 점점 더 복잡해지기만 하는 소프트웨어를 만들게 될 테니까요.
00:47:37그건 결코 올바른 선택이 아니라고 봅니다.
00:47:43에이전트 기반 코딩에서 저를 가장 짜증나게 하는 점은, 제가 수동으로 코드를 변경했다는 사실을 AI에게 알리는 걸 자주 잊는다는 거예요.
00:47:50그럼 다음 프롬프트에서 제 변경 사항을 완전히 무시하고 삭제해 버리죠.
00:47:54아, 네, 무슨 말인지 알아요.
00:47:56저도 그런 적이 있거든요.
00:47:58끊임없이 상기시켜 줘야 해요.
00:48:00아니면 저는 코드를 수정할 때마다, 말이 된다면 그냥 바로 커밋을 해버립니다.
00:48:05제 경험상, 이미 커밋된 내용은 AI가 지우거나 되돌리지 않더라고요.
00:48:11하지만 수정만 하고 커밋하지 않은 상태에서 다음 프롬프트를 입력하면, 제 변경 사항을 아주 쉽게 삭제해 버리죠.
00:48:21스킬(Skill)에 대해 제안해 줄 만한 게 있나요?
00:48:23Matt Pokok의 스킬을 써보셨나요?
00:48:25아니요, 안 써봤습니다.
00:48:26저는 직접 제 스킬을 만들고 있어요.
00:48:31그래서 이미 만들어진 스킬을 가져다 쓰는 건 별로 좋아하지 않습니다.
00:48:36제대로 된 스킬을 만드는 게 결코 쉬운 일은 아니니까요.
00:48:43별 도움이 안 되는 스킬을 만드는 건 쉽죠.
00:48:46그렇다고 엄청나게 어려운 것도 아니고요.
00:48:48좋은 스킬이란 어떤 특정한 문제를 정의하거나 해결하는 것이라고 생각합니다.
00:48:54비교적 간결하면서도 구조가 명확하고 실행 가능해야 하죠.
00:48:59AI에게 스킬을 작성하게 할 수도 있지만, 적절한 지침을 줘야 합니다.
00:49:04또한 에이전트 스킬을 가지고 있다면, 시간이 지나면서 계속 발전시켜야 한다는 점도 매우 중요합니다.
00:49:10스킬을 설치만 해두고 잊어버릴 위험이 굉장히 크거든요.
00:49:17초반에는 잘 작동하는 것처럼 보였어도, 나중에는 결과가 더 나빠질 수도 있어요.
00:49:25사용하는 모델이 바뀌거나, 다른 환경에서 실행되거나, 시스템 프롬프트가 달라질 수 있으니까요.
00:49:32갑자기 스킬이 예전만큼 잘 작동하지 않게 되는 거죠.
00:49:37직접 만들었다면 업데이트해야 한다는 사실을 기억할 확률이 더 높지 않을까요?
00:49:44그래서 저는 제가 직접 관리하는 스킬 저장소를 가지고 있고, 계속 업데이트합니다.
00:49:48작동 방식이 마음에 들지 않을 때마다 계속 개선하니까요.
00:49:54계획이 세워지는 방식도 마음에 안 들 때가 있고요.
00:49:58그래서 계속해서 스킬을 다듬으려고 노력합니다.
00:50:02제가 직접 스킬을 만들고 싶은 이유가 바로 그거죠.
00:50:04정말 세밀하게 조정하고 싶거든요.
00:50:05그것 또한 학습 과정의 일부이고, AI 에이전트에게 적절한 도구를 제공하는 법을 배우는 과정입니다.
00:50:11결국 스킬은 에이전트가 효과적으로 작동하기 위한 도구와 같으니까요.
00:50:16그게 스킬에 대한 제 생각이고, 남들이 만든 스킬을 잘 안 쓰는 이유입니다.
00:50:21영감을 얻기 위해 참고할 수는 있죠.
00:50:23스킬 내용 자체가 아니라, 스킬의 이름이나 목표 정도는 참고할 수 있습니다.
00:50:27하지만 저는 결국 직접 만드는 쪽을 선호합니다.
00:50:34이력서는 솔직하게 썼는데, 요즘처럼 힘든 취업 시장에서 거짓말을 많이 하는 지원자들과 어떻게 경쟁해야 할까요?
00:50:40이력서에서 중요한 점은, 이건 개발 분야뿐만 아니라 언제나 그랬지만, 솔직함과 동시에 대담함이 필요하다는 것입니다.
00:50:49이미 그렇게 하고 계실지도 모르지만, 그게 중요해요.
00:50:52수동적인 태도가 아니라 대담하게 어필해야 합니다.
00:50:55거짓말을 하라는 게 아니라, 대담해지라는 뜻입니다.
00:50:58그리고 앞서 언급했듯이 현재 구직 시장에서 눈에 띄려면 어딘가에 존재감을 드러내야 한다고 생각합니다.
00:51:08X, LinkedIn, YouTube, 어디든 상관없습니다.
00:51:10꼭 인플루언서나 콘텐츠 크리에이터가 될 필요는 없어요.
00:51:12하지만 활동적이고 눈에 띄는 곳에 있으면, 그곳에서 인연이 닿아 취업에 도움을 줄 수 있는 사람을 만날 수도 있으니까요.
00:51:27반드시 취업이 목적이 아니더라도, 그런 가시성 자체가 큰 가치가 있거나 다른 요소들과 결합하여 큰 힘을 발휘할 수 있고, 또 하나의 기회가 될 수 있으니까요.
00:51:40멋진 제안은 아니라는 걸 알지만, 현재 구직 시장이 워낙 가혹하기 때문에 무엇을 할 수 있을지에 대한 제 솔직한 생각을 말씀드리는 겁니다.
00:51:50과로와 번아웃은 어떻게 피하고 있나요?
00:51:53네, 의도적으로 휴식을 취하는 것이 중요합니다.
00:51:57의도적인 휴식은 정말 중요하고, 자신이 하는 일에서 즐거움을 찾는 것도요.
00:52:02앞서 말했듯이, 저는 직접 손으로 코딩하는 걸 좋아했는데 AI 때문에 그 즐거움 중 일부를 잃었어요. 그래서 이제는 AI로 구축하고 에이전트를 수정하며 좋은 결과를 얻는 과정에서 즐거움을 찾으려 합니다.
00:52:17그런 즐거움을 찾는 것이 중요한 이유는, 본인이 즐겁게 일하면 번아웃의 위험이 훨씬 낮아지기 때문입니다.
00:52:24그게 제 계획입니다.
00:52:26뻔한 소리처럼 들리겠지만, 항상 쉬운 건 아니에요. 억지로 즐거움을 강요할 순 없지만, 어떤 방식으로든 자신이 하는 일의 한 부분에서 즐거움을 찾아야 한다고 느낍니다.
00:52:38모든 조언 정말 감사합니다.
00:52:39모든 조언 정말 감사합니다. 별말씀을요, 도움이 되었다니 기쁩니다.
00:52:45토렌트로 강의를 다운로드했다가, 나중에 Udemy에서 정식으로 구매했어요.
00:52:48네, 구매해 주셔서 감사합니다.
00:52:50뭐, 불법 복제는 사실 좋은 건 아니니까요.
00:52:54제 강의를 즐겁게 보고 결제를 결정해 주셨다니 정말 기쁩니다.
00:52:58정말 고마운 일이에요.
00:52:59감사합니다.
00:53:01여러 소규모 팀이 함께하는 대형 웹 애플리케이션 구축에는 React나 Angular 중 무엇을 추천하시나요?
00:53:06아마 요즘이라면 React를 추천할 것 같아요. 더 대중적이고 사용률이 높으니까요.
00:53:13AI도 React에 아주 능숙합니다. 물론 올바른 소스와 스킬을 제공한다면 요즘 AI는 어떤 기술이든 다 잘 다루긴 하죠.
00:53:21하지만 React는 안전한 선택이죠. 나쁜 선택은 아니니까요.
00:53:27AI와 효율적으로 일하는 법이 궁금합니다. 가끔 AI를 너무 많이 사용하다 보면 제가 바보가 된 것 같은 기분이 들거든요.
00:53:33네, 그게 바로 함정이죠.
00:53:35AI를 너무 많이 사용해서 에이전트들이 모든 걸 다 하게 만들다 보면, 갑자기 전체적인 흐름을 완전히 놓쳐버리게 됩니다.
00:53:43또 제가 아직 해결책을 찾지 못한 문제 중 하나는, 제 스킬셋 자체가 바뀐다는 거예요.
00:53:52예를 들어, 몇 년 전만 해도 React 코딩 실력이 지금보다 훨씬 좋았어요.
00:54:05그건 확실히 변했습니다.
00:54:06그렇다고 React나 모범 사례, 패턴을 전혀 모른다는 뜻은 아니지만, 예전과는 달라진 거죠.
00:54:13분명히 바뀌었습니다.
00:54:14그게 바로 변화의 일부라고 생각해요.
00:54:18제 스킬셋이 변화하고 있는 것 같긴 한데, 솔직히 좀 이상하고 잘못된 것 같은 기분도 듭니다.
00:54:29정말 감사합니다, Vlad.
00:54:31Angular 1.3 때부터 당신의 강의를 들었습니다.
00:54:34덕분에 세르비아에서 좋은 개발자 직업을 얻고 돈도 잘 벌고 있어요.
00:54:38저에게 정말 큰 의미가 있네요.
00:54:39제 강의가 도움이 되었다고 말해주는 사람들의 글을 읽는 건 언제나 감격스럽습니다.
00:54:45멋진 직업을 얻고 좋은 경력을 쌓게 되어 정말 다행이에요.
00:54:48저에게 정말 뜻깊은 일입니다.
00:54:49공유해 주셔서 정말 감사합니다.
00:54:51정말 놀랍네요.
00:54:52진심으로 감사합니다.
00:55:02몇 가지 의견을 말씀드리자면,
00:55:12요즘 AI 열풍 때문에 React나 Next.js의 새로운 기능 같은 기존 기술들에 대해 소홀해지는 건 아닐까요?
00:55:20그냥 희미해지는 것 같아요.
00:55:21네, 저도 그렇게 느낍니다.
00:55:23과거에는 새로운 React, Next.js, 또는 Angular 버전이 나올 때마다 엄청난 이슈였거든요.
00:55:29그런데 요즘은 그런 걸 훨씬 덜 신경 쓰게 되죠.
00:55:32저도 확실히 그렇게 변했습니다.
00:55:35첫째, AI 에이전트에게 changelog를 알려주고 코드베이스를 업데이트하게 하거나, 중요한 내용이 있는지 파악하게 시키면 되니까요.
00:55:44둘째, 과거 프레임워크들의 새로운 버전들이 개발자들의 특정 문제들을 해결하기 위해 출시되었던 것과는 상황이 많이 달라졌기 때문입니다.
00:55:58물론 모든 변경 사항이 다 그렇다는 건 아닙니다.
00:56:00보안 개선이나 성능 최적화 같은 부분도 분명 있으니까요.
00:56:02하지만 새로운 기능이 개발자가 작업을 더 쉽게 할 수 있도록 추가되는 경우도 많았죠.
00:56:10예를 들어, Angular의 시그널은 성능 향상 효과도 있죠.
00:56:17신호 폼(Signal Forms) 같은 기능도 생각해보고요.
00:56:22잘 모르겠지만요.
00:56:23거기에도 분명 성능 개선 효과가 있을 겁니다.
00:56:26하지만 확실히 개발자들이 더 나은 방식으로, 더 효율적으로 애플리케이션을 만들 수 있게 돕기 위해 출시된 기능들이 많았어요.
00:56:37하지만 그런 점들은 더 이상 예전만큼 중요하지 않게 되었습니다.
00:56:41더 이상 그만큼 중요하지 않아요.
00:56:44이론적으로 보자면, 코드를 작성하는 과정은 정말 투박하고 불편하더라도 엄청나게 고성능의 애플리케이션을 만들어내는 프레임워크가 나온다면,
00:56:57그것이 이전의 프레임워크들보다 더 낫다고 볼 수 있습니다. 왜냐하면 코드를 작성하는 과정이 불편하고 개발자로서 즐겁지 않다는 사실이,
00:57:10그 코드를 직접 작성하는 게 아니기 때문에 더 이상 중요하지 않게 되었기 때문입니다.
00:57:14그래서 그런 흐름이 바뀌었다고 생각해요.
00:57:18그렇기 때문에 새로운 버전이 출시되어도 예전만큼 흥미롭지 않은 거죠.
00:57:22솔직히 말해서, 성능 개선 같은 건 당연히 좋은 거니까 거저 얻는 거였죠.
00:57:27그건 대단한 거였죠.
00:57:28하지만 흥미로웠던 건 새로운 문법, 새로운 API, 새로운 기능이었어요.
00:57:33그런 이유로 사람들의 관심사가 확실히 바뀐 것 같습니다.
00:57:41AI 코딩 세션 후에 저만 유독 정신적으로 지치고 짜증 나는 게 아니라는 사실을 알게 되어 위안이 됩니다.
00:57:48네, 많은 개발자들이 그렇게 느낄 거라고 생각해요. 왜냐하면 어떤 방식으로 작업하느냐에 따라 정신적으로 소모가 심하고 도전적인 일이 될 수 있으니까요.
00:57:57만약 단순히 슬롯머신 당기듯 AI에게 "이거 파랗게 바꿔줘", "이거 더 크게 해줘"라고만 한다면,
00:58:08별로 지치지 않을지도 모르죠.
00:58:10하지만 직접 의사결정을 내리고, 계획을 읽고 수정하는 등 적극적으로 개입하면 분명 정신적으로 소모가 클 수 있습니다.
00:58:17LangChain이나 LangRef 같은 에이전트 기반 앱 전문가는 어떤가요?
00:58:22제가 그런 전문가는 아닙니다.
00:58:24저는 LangChain이나 LangRef 전문가는 아니에요.
00:58:27앞으로 AI 에이전트를 구축할 수 있는 능력이 매우 중요한 영역이 될 가능성이 높다고 봅니다.
00:58:38예를 들어 Vercel의 EVE 프레임워크 같은 것들이 있죠.
00:58:42잘 모르지만 FLU 같은 프레임워크도 있고요.
00:58:46그런 프레임워크들이 AI 에이전트 구축을 돕습니다.
00:58:51이제 목표는 웹사이트를 만들어주는 AI 에이전트가 아니라, Dropbox에서 재무 문서를 가져와 요약 보고서를 작성하는 등 특정 업무를 전문으로 하는 에이전트를 만드는 것이죠.
00:59:08앞으로 그런 분야도 중요해질 거라고 생각합니다.
00:59:12그러니 앞으로는 웹/모바일 앱, 로우레벨 소프트웨어뿐만 아니라 이런 에이전트들도 구축하게 될 겁니다.
00:59:21많은 기업들이 각자 특정 도구, 지침, 스킬, 지식 베이스, 그리고 샌드박스를 갖춘 맞춤형 전문가 에이전트를 원할 테니까요.
00:59:40고객 지원이 될 수도 있고... 사실 저는 EVE로 직접 에이전트를 구축해보기도 했습니다. 관련 강의도 고려 중이라서요.
00:59:50회사 내부적으로 쓸 수 있는 재무 관리 에이전트를 만들었는데, 회계 문서나 송장 같은 걸 채팅으로 편하게 물어보고 확인할 수 있습니다.
01:00:04매달 회계 준비를 해야 하는데, 문서가 빠짐없이 있는지 확인하는 과정이 번거롭거든요.
01:00:09이제 그 에이전트에게 "이번 달 회계 마감해야 하는데, 관련 폴더에 문서를 다 확인해줘"라고 물어보면 됩니다.
01:00:15그러면 에이전트가 알아서 문서를 확인하고,
01:00:19자기 할 일을 하는 거죠.
01:00:21다시 돌아와서는 "이 송장이 누락된 것 같습니다"라고 말해주기도 하고요.
01:00:24그러면 저는 "아, 그건 일부러 뺀 거야" 혹은 "오, 좋은 지적이야, 여기 있어"라고 답할 수 있죠.
01:00:28이렇게요.
01:00:28미래에는 모든 종류의 목적을 위한 이런 에이전트들이 흔해질 것이고, 그것을 만드는 과정 역시 AI가 도울 수 있을 겁니다.
01:00:40물론 개발자의 가이드가 있어야겠죠. 결국은 일종의 소프트웨어 애플리케이션이니까요.
01:00:45앞으로 우리가 마주할 수많은 흥미로운 영역들 중 하나가 될 거라고 확신합니다.
01:00:56Pi 같은 에이전트 하네스를 직접 돌리는 게 가치가 있어 보이네요.
01:01:00저에게 있어 Pi를 사용하는 건 정말 즐겁습니다. 아주 훌륭하게 확장할 수 있거든요.
01:01:07그게 요즘 제가 즐거움을 얻는 원천이기도 합니다.
01:01:12스킬이 AI 모델에 따라 민감하게 반응하나요?
01:01:15특정 모델에 맞춰 스킬을 조정해야 하는 경우가 있나요?
01:01:19과거에는 설명을 조정해야 하는 경우가 많았습니다.
01:01:25어떤 모델은 스킬을 사용할 확률이 훨씬 높았으니까요. 하지만 지금은 다 달라졌어요.
01:01:31이제 모든 모델이 스킬을 호출하고 불러내는 데 아주 능숙해졌습니다.
01:01:35하지만 여전히 항상 세밀하게 조정합니다.
01:01:37모델뿐만 아니라 하네스(harness)에 맞춰서도 계속 다듬어야 하거든요.
01:01:43말씀드린 대로, 여러 에이전트가 동시에 실행될 수 있는 Herder를 사용 중입니다.
01:01:52Herder에서 하위 에이전트를 실행하도록instruct하는 스킬을 직접 만들었는데, Herder가 에이전트 지원 기능이 내장되어 있어서 잘 작동하도록 세팅했습니다.
01:02:06그렇게 해당 환경에서 잘 동작하도록 스킬을 만들었죠.
01:02:14반면에 Claude Code는 고유한 하위 에이전트 로직을 가지고 있습니다.
01:02:21그래서 Claude용으로는, 무의미한 하위 에이전트를 끝없이 생성하는 걸 막고 싶어서 하위 에이전트를 사용할 시점을 결정하는 스킬을 만들었습니다.
01:02:34내부 로직이 있으니까 구체적인 방법까지 알려줄 필요는 없거든요.
01:02:37이런 식으로 이제는 모델 자체보다는 하네스 환경에 맞춰 스킬을 주로 조정하게 됩니다.
01:02:52바이브(Vibe)라는 게 NFT 족들이랑 비슷하네요.
01:02:54네, 어느 정도 겹치는 부분이 있을지도 모르죠.
01:02:58최근 웹 개발에 권태를 느껴서 DevOps로 전환하려고 합니다.
01:03:02AI가 그쪽 업계에는 어떻게 영향을 주고 있는지 궁금합니다.
01:03:06제 생각에는... X에서 보는 내용이나 들리는 얘기들을 보면, 당연히 DevOps 분야도 큰 영향을 받고 있습니다.
01:03:16어떻게 DevOps를 정의하느냐에 따라 다르겠지만요.
01:03:21코딩과 마찬가지로, 무슨 일이 벌어지는지 제대로 아는 것 자체가 가치가 큽니다.
01:03:29물론 AI를 활용해 Docker 이미지를 빌드하거나 VPS를 설정하고 구성하는 데 도움을 받을 수는 있습니다. 저도 그렇게 하고 있고요.
01:03:40아주 유용하죠.
01:03:42무엇을 요청해야 할지, 무엇을 요청하지 말아야 할지, 그리고 AI가 한 작업이 무슨 의미인지 이해하는 게 중요합니다.
01:03:51Docker 구성 파일들을 검토해 보는 것도 흥미롭습니다. AI가 너무 복잡하게 만들거나 목적에 맞지 않는 구성을 만들어낼 때가 있거든요.
01:04:05컨테이너 빌드가 안 되는 오류뿐만 아니라, 인프라 자체가 너무 복잡해지거나 잠재적인 이슈를 안고 있는 경우도 생기니까요.
01:04:18저도 예전에 VPS에 Docker 설정을 AI에게 맡겼는데, 꼼꼼하게 검토하지 않은 적이 있습니다.
01:04:30한 달쯤 지나니 VPS 하드 드라이브 사용량이 100%가 되어 꽉 차버리더군요.
01:04:41알고 보니 Docker compose 파일에 설정된 로깅 방식 때문에 로그 파일이 정리되지 않고 쌓였던 겁니다.
01:04:50일정 기간이 지나거나 파일 크기가 커지면 지우는 규칙이나 로직이 전혀 없었거든요.
01:04:58바로 그런 걸 말하는 겁니다.
01:04:59최악의 상황까진 아니더라도, 하드 드라이브가 꽉 차버리면 정말 곤란하겠죠.
01:05:06결국 무슨 일이 벌어지는지 아는 게 정말 중요합니다. 물론 AI가 다른 곳들과 마찬가지로 이곳에도 영향을 미치겠지만요.
01:05:17근본적으로 파고들면, 결국 모든 건 코드니까요.
01:05:22디지털 세상의 모든 건 결국 코드로 작동합니다.
01:05:25결국 코드가 동력이죠.
01:05:28그러니 AI가 이런 모든 부분을 도울 수 있는 겁니다.
01:05:31하지만 제 의견으로는, 여전히 전문가인 인간이 협력해서 진행해야 합니다.
01:05:39스킬에 대한 당신의 견해는 정말 타당합니다.
01:05:41코드 리뷰용 스킬을 만들고 한 달 동안 세밀하게 조정해 봤거든요.
01:05:44처음엔 Sonnet, Opus를 쓰다가 지금은 5버전에 맞춰 업데이트했죠.
01:05:49네.
01:05:49스킬은 정말 계속 진화해야 하고 업데이트가 필요합니다. 하지만 너무 과하게 만들고 싶진 않네요.
01:05:54적어도 저는 그러고 싶지 않아요.
01:05:5540개씩이나 되는 에이전트 스킬을 가지고 싶진 않으니까요.
01:05:59스킬은 대략 네다섯 개, 많아야 여섯 개 정도만 가지고 있어요.
01:06:03본질적으로 좋은 프록시는 AI에게 계속 같은 내용을 반복해서 물어보게 될 때,
01:06:10혹은 매번 같은 문제로 짜증이 날 때, 바로 그때가 스킬을 추가하기 좋은 기회입니다.
01:06:16네.
01:06:17아니면 특정 행동 방식이 부족하다고 느낄 때도 스킬을 추가하기 좋은 기회죠.
01:06:24하지만 이 역시 하나의 과정입니다.
01:06:25단순히 “X, Y, Z를 수행하는 스킬 하나 만들어줘”라고 하면 끝나는 게 아니에요.
01:06:28아니죠, 좋은 스킬을 다듬으려면 노력이 필요합니다.
01:06:31가장 흥미로운 작업이 아니라는 건 잘 알지만, 시간을 들여 좋은 스킬을 구축해야 합니다.
01:06:37저에게도 아주 신나는 일은 아니지만, 이 스킬은 앞으로 몇 주나 몇 달 동안 수천 번의 에이전트 세션에서 활용될 수 있는 중요한 도구니까요.
01:06:52그러니 프로젝트, 코드 스타일, 본인의 성향, 모델, 그리고 도구들에 딱 맞는 좋은 스킬을 만드는 데 시간을 투자해야 합니다.
01:07:02그만한 가치가 충분히 있다고 생각합니다.
01:07:08특히 이번 5.6 버전 업데이트와 영구 초기화 이후로는,
01:07:14지난주에 API 추론 비용으로 2만 달러 정도를 썼더라고요.
01:07:20그래서 지금은 며칠 휴가를 냈습니다.
01:07:23아, 탈진해서 쉬시는 거군요?
01:07:25네.
01:07:26그 점은 정말 흥미로운 포인트네요.
01:07:30저도 같은 상황을 보고 있고, X에서도 관련 글을 읽었습니다.
01:07:33OpenAI가 사용량 제한을 계속 리셋해주니 참 좋긴 하죠.
01:07:39구독한 만큼 더 많이 쓸 수 있으니까요.
01:07:40하지만 당연히 그만큼 사용해야 한다는 압박감을 느끼기 쉽죠, 그렇죠?
01:07:45갑자기 사용량이 100%로 다시 채워졌으니 말입니다.
01:07:49그래서 꼭 써야 할 것 같고요.
01:07:50그 마음 충분히 이해합니다.
01:07:52하지만 그러지 마세요.
01:07:53그냥 그렇게 하지 마세요.
01:07:54어떻게 일할지, 얼마나 일할지, 무엇을 할지 OpenAI가 결정하게 내버려 두지 마세요.
01:08:00위험한 건 번아웃이 오거나, 완전한 번아웃이 아니더라도 지쳐버릴 수 있다는 점입니다.
01:08:07둘째로, 토큰을 다 써버리려고 급하게 작업하다 보면, 정작 무엇을 하는지 깊이 생각하지 않거나 에이전트의 결과물을 신중하게 검토하지 않아 저품질의 결과물을 만들 확률이 높습니다.
01:08:23결국 그 토큰을 다 써서 만든 결과물은 어차피 버리게 될 가능성이 매우 높다는 뜻이죠.
01:08:30그럼 대체 무슨 의미가 있을까요?
01:08:32물론 OpenAI의 컴퓨팅 자원을 사용하는 것이긴 합니다.
01:08:36그들의 돈을 조금 태우는 셈이죠.
01:08:38기분은 좋을지 모릅니다.
01:08:39하지만 결국, OpenAI가 시키는 대로 사용량을 채우는 데 당신의 소중한 시간을 낭비할 가치는 없습니다.
01:08:47본연의 작업에 집중하세요. 사용량 리셋 같은 것에 휘둘리지 마시고요.
01:08:54에이전트 관련 강의를 꼭 보고 싶네요.
01:08:56에이전트 강의는 곧 나옵니다.
01:08:58또한 AI를 활용해 작업하는 방식을 단순히 말로만 설명하는 게 아니라, 실제로 보여줄 계획도 가지고 있습니다.
01:09:08이제 기본기를 배울 필요가 거의 없어진 초보 개발자들에게는 어떤 영향이 있을까요?
01:09:15현재의 고급 언어들이 어셈블리어처럼 될 거라 생각합니다.
01:09:19새로 시작하는 개발자들에게는 어떤 영향을 줄까요?
01:09:23네.
01:09:25제 질문을 제대로 이해했는지 모르겠는데, 직접 코딩할 필요가 없어진 초보 개발자들에게 어떤 영향이 있을지 물으시는 거죠?
01:09:33직접 손코딩을 하지 않으면 어떻게 좋은 기본기를 다질 수 있을까, 뭐 그런 고민인가요?
01:09:39제가 제대로 이해했나요?
01:09:40아니면 말씀해주세요.
01:09:44AI와 함께 코딩을 배우는 건 꽤나, 아주 꽤나 어려운 문제입니다.
01:09:51아직 저도 완벽한 답변은 찾지 못했습니다.
01:09:54저 역시 그 해답을 찾으려고 노력 중이니까요.
01:09:58AI를 쓰면서도 정작 무슨 일이 벌어지고 있는지 배우지 못할 위험이 있다는 건 분명한 문제라고 봅니다.
01:10:06결과물이 나올 때는 좋지만, 그렇지 못할 때가 문제죠.
01:10:10그래서 해결책은 정말 어렵지만, AI가 생성한 코드가 어떤 의미인지 계속 공부하는 것입니다.
01:10:22소프트웨어를 구성하는 요소들을 끊임없이 배우는 거죠.
01:10:26소프트웨어의 구성 요소와 기술적 트레이드오프에 대해 계속 배워야 합니다.
01:10:29물론 모든 결정을 직접 내리지 않아도 될지도 모릅니다.
01:10:34작은 결정들은 AI가 대신 해줄 수도 있고, 사실 별로 중요하지 않을 수도 있습니다.
01:10:39하지만 그럼에도 무슨 일이 일어나고 있는지 이해하는 것은 중요합니다.
01:10:42이미 말했듯이 AI에게 코드를 물어볼 수 있잖아요.
01:10:44그게 중요한 방법 중 하나예요.
01:10:45그게 기본기를 다지는 방법의 일부라고 생각합니다.
01:10:49AI에게 왜 이렇게 코드를 짰는지 물어보세요.
01:10:51다른 대안은 없는지 물어보고요.
01:10:53설명을 요구하세요.
01:10:55또 다른 학습 방법은, 솔직히 제가 만들어서가 아니라, 튜토리얼이나 강의를 듣는 것입니다.
01:11:02무료 강의도 좋고요.
01:11:03유료 강의도 좋습니다.
01:11:04왜냐하면 누군가 다른 사람이 특정 기술이나 접근 방식에 대해 설명해 주는 내용을 듣는 것이 도움이 되기 때문입니다.
01:11:12질문하는 방식으로는 알 수 없는 영역들이 있는데, 사실 뭘 물어봐야 할지도 모를 수 있잖아요.
01:11:18그래서 기본기를 다지기 위해서는 전문가들이 지식을 공유하는 것이 중요하다고 생각합니다.
01:11:25그리고 여러분은 그걸 습득하면 됩니다.
01:11:26그러고 나서 에이전트에게 도전해보세요.
01:11:28에이전트에게 설명을 요구해 보는 겁니다.
01:11:31그런 식으로 여전히 좋은 기본기를 쌓을 수 있다고 봅니다.
01:11:34하지만 이건 예전처럼 직접 코드를 한 줄 한 줄 작성하던 방식과는 완전히 다른 학습 과정입니다.
01:11:38그 시절에는 자연스럽게 문제에 부딪히며 배웠죠.
01:11:40아주 좋은 학습 방법이었습니다.
01:11:43하지만 이제는 그런 식으로 일하는 시대가 아니라고 느낍니다.
01:11:48보통 적당한 규모의 프로젝트 하나당 에이전트 스킬 파일을 몇 개 정도 만드시나요?
01:11:52몇 개 안 됩니다.
01:11:52저는 대략 4~6개의 주요 전역(Global) 스킬을 가지고 있어요.
01:11:59그리고 프로젝트별로 2~3개 정도의 스킬을 추가합니다.
01:12:05만약 TanStack Start나 Fact 라이브러리를 사용해서 Cloudflare에 배포하는 프로젝트를 한다면, Cloudflare 스킬, Fact 스킬, TanStack Start 스킬을 각각 만듭니다.
01:12:18직접 만드는 거죠.
01:12:21예를 들어, 어떤 스킬이 이미 다른 프로젝트에 있다면,
01:12:24에이전트에게 “저 프로젝트에 있는 스킬을 참고해서 해줘”라고 말합니다.
01:12:28영감을 얻으라는 의미죠.
01:12:30하지만 그 스킬이 Fact를 적절하게 잘 다루는지 확인하기 위해 추가적인 조사를 시키기도 합니다.
01:12:36최신 변경 사항을 확인해서 바뀐 점을 보라고 하는 거죠.
01:12:40그리고 스킬을 개선할 방법에 대한 아이디어를 달라고 합니다.
01:12:43그러면 그 아이디어들을 검토합니다.
01:12:44제 아이디어도 보태고요.
01:12:45그러고 나서 새로운 스킬을 만들어 전역 스킬 외에 프로젝트에 추가하는 식입니다.
01:12:50어쨌든 다 합쳐도 총 10개 정도의 스킬밖에 안 돼요.
01:12:55저는 정말 최소한으로 유지하려고 합니다.
01:12:57단순히 토큰을 많이 소비해서가 아니에요.
01:13:00그건 큰 문제가 아니죠.
01:13:02그다지 큰 비중은 아니라고 생각합니다.
01:13:04단지 AI 에이전트가 무작정 도움이 될 것 같은 스킬을 마음대로 활성화하는 상황을 피하고 싶어서입니다.
01:13:11첫째, 불필요한 토큰이 소비되니까요.
01:13:14둘째, 잘못된 방향으로 모델이 흐를 위험이 있습니다.
01:13:17그러니까 제겐 일종의 트레이드오프인 셈이죠.
01:13:19스킬은 정말 유용합니다.
01:13:21하지만 너무 많이 만들고 싶지는 않아요.
01:13:24최소한 현재 제 생각은 그렇습니다.
01:13:26더 많은 실험을 거치거나 모델이 발전하면 몇 달 뒤에는 생각이 달라질지도 모르죠.
01:13:31몇 달 뒤에 어떤 상황이 올지는 아무도 모르는 거니까요.
01:13:34아, 질문 하나를 건너뛴 것 같네요.
01:13:37죄송합니다.
01:13:37개발자의 미래가 안전한가에 대한 질문을 봤습니다.
01:13:41답변을 드리자면, 일단 지금 상황은 분명히 다소 불안정한 면이 있습니다.
01:13:48훨씬 좋았던 시절도 분명 있었죠.
01:13:50그건 자명한 사실이고요.
01:13:52구인 시장 상황은 좋지 않습니다.
01:13:55그것도 너무나 명확하죠.
01:13:57그중 AI와 관련된 건 일부분이라고 생각합니다.
01:14:00하지만 AI가 분명 영향을 미칠 거라는 건 확실해요.
01:14:03그 점은 정말 의심할 여지가 없죠.
01:14:04제 생각에 AI를 잘 활용하는 개발자들은 안전할 것입니다.
01:14:09네, 그렇습니다.
01:14:09기업이 인간은 완전히 배제하고 AI만 사용하는 미래가 곧 올 거라고는 생각하지 않습니다.
01:14:21미래를 예측할 수는 없지만 말이죠.
01:14:22혹시 모델이나 도구들이 엄청나게 발전해서 제가 틀릴 수도 있겠죠.
01:14:28하지만 그런 세상이 온다면 비단 개발자뿐만의 문제가 아닐 겁니다.
01:14:31거의 모든 직업이 심각한 위기에 빠지게 되겠죠.
01:14:36하지만 저는 그렇게 생각하지 않습니다.
01:14:38거의 모든 기술이 그렇듯, 일자리는 시대에 따라 진화한다고 봅니다.
01:14:44기술과 인간의 입력이 결합할 때 최고의 성과가 나올 수 있습니다.
01:14:49앞으로의 개발자는 AI를 얼마나 효율적으로 잘 다루느냐에 달렸다고 생각합니다.
01:14:56오늘날의 개발은 4년 전과는 확연히 다를 것이고, 분명 더 달라질 것입니다.
01:15:02이미 변하고 있고요.
01:15:04하지만 여전히 개발 일자리는 존재합니다.
01:15:05다만 방식이 바뀐 것뿐이죠.
01:15:07앞서 말했듯이 말입니다.
01:15:09저 역시 예전 코딩의 즐거움 중 일부는 잃어버렸다고 느낍니다.
01:15:11하지만 새로운 세상 속에서 또 다른 재미를 찾아가고 있습니다.
01:15:17꼭 AI가 필요했냐고요?
01:15:18아니요, 하지만 이미 우리 곁에 있습니다.
01:15:27쏟아지는 기술들을 어떻게 다 따라가시나요?
01:15:29저도 어떤 기술들은 따라가기가 정말 어렵습니다.
01:15:32가르치는 입장에 계신 선생님께서는 얼마나 더 힘드실지 상상조차 안 되네요.
01:15:34혹시 특별한 알림 채널이라도 있으신가요?
01:15:36X가 정말 좋은 정보원입니다.
01:15:38X에 시간을 조금 과하게 쓰는 감도 있지만, 어쨌든 계속 확인하죠.
01:15:42소음도 많지만, 그만큼 가치 있는 정보도 정말 많거든요.
01:15:47그리고 저는 실제로 직접 만들어봅니다.
01:15:49하루 종일 오래 일하고요.
01:15:51정말 많은 것을 직접 빌드합니다.
01:15:53실험도 정말 많이 하고요.
01:15:56그게 제가 새로운 것들을 시도하는 방법입니다.
01:15:59물론 모든 걸 다 해볼 수는 없겠죠.
01:16:01그게 현실이기도 하고요.
01:16:04그래도 가능하면 최대한 많이 직접 실험해 보려고 합니다.
01:16:10진지하게 프로젝트를 빌드해보려고 노력하고요.
01:16:12X는 새로운 트렌드나 기술, 그리고 사람들의 다양한 의견을 배우는 아주 훌륭한 창구로 사용하고 있습니다.
01:16:22어떤 것들은 며칠만 지나도 금세 사그라드는 유행이라는 걸 알기에 따로 시도할 필요가 없기도 합니다.
01:16:28지금은 아무도 언급조차 안 하니까요.
01:16:31그래도 제가 직접 한번 살펴보긴 합니다.
01:16:33어쨌든 무엇이 남고 무엇이 사라지는지 계속 지켜보는 것이 중요하죠.
01:16:41지금 경력이 아예 없는 주니어 개발자를 뽑는다면, 하루하루 어떤 지식과 행동을 기대하시나요?
01:16:50제가 기대하는 부분은 이렇습니다.
01:16:52웹 개발, 앱 개발, 그리고 저희가 하는 백엔드 개발 관련 업무를 위해 채용한다고 가정해 봅시다.
01:17:03저는 그들이 핵심 기술들을 알고 있길 바랍니다.
01:17:07Node, Bun, React, PHP 같은 것들이죠.
01:17:14모두 다 알 필요는 없지만, 저희 스택인 Node, TypeScript, React는 기본이죠.
01:17:20그 기술들이 왜 존재하는지, 어떻게 함께 작동하는지, React의 핵심 개념인 컴포넌트나 상태 관리 같은 기본은 알아야 합니다.
01:17:31정말 기본적인 것들 말이에요.
01:17:32코드를 바로 짤 수 있을 정도는 아니더라도, 적어도 알고는 있어야 한다는 거죠.
01:17:37또한 인증(Auth)에 대해서도 알아야 합니다.
01:17:41인증을 추가하는 데 어떤 옵션들이 있는지 말이죠.
01:17:44거기서 오는 어려움은 무엇인지요.
01:17:46전문가 수준일 필요는 없지만, 애플리케이션을 어떻게 구성하는지, 어떤 빌딩 블록들이 필요한지, 어떤 트레이드오프와 도전 과제가 있는지를 충분히 이해하고 있다는 걸 보여주길 원합니다.
01:18:00그리고 언급했듯이 AI 부분도 중요합니다.
01:18:02AI를 어떻게 활용하는지 보고 싶습니다.
01:18:06완벽한 결과물을 기대하는 건 아니에요.
01:18:07주니어에게 시니어 수준의 경력을 기대하지 않으니까요.
01:18:11하지만 단순히 AI가 시키는 대로만 하는 건 싫습니다.
01:18:14AI의 결과물을 직접 검증하고 도전하는 모습을 보고 싶어요.
01:18:18최선의 방향이 무엇인지 확신이 서지 않을 때 AI와 논의하는 모습을 보고 싶습니다.
01:18:23그러고 나서 제게 와서 이렇게 말하는 거죠. “AI와 상의해 봤는데 여러 가지 선택지가 나왔습니다.”
01:18:30“저희가 생각한 옵션은 크게 세 가지입니다.”
01:18:33“이런 이유들 때문에 저는 이 방식이 가장 좋다고 생각하는데, 아직 고민이 좀 됩니다.”
01:18:39그건 괜찮습니다.
01:18:40충분히 좋습니다.
01:18:40그게 제가 기대하는 바입니다.
01:18:43Claude 사용량과 관련해서, 이상하게도 제 사용량 리셋이 일찍 되는 경우가 있습니다.
01:18:48Max 플랜을 쓰는데, 가끔 주간 리셋이 아니라 일일 리셋이 될 때가 있더라고요.
01:18:53좋은 기능이네요.
01:18:54아쉽게도 저는 그런 경우가 없네요.
01:18:57Kimmy K3가 웹에 출시되었다고요?
01:19:01정말요?
01:19:03나왔나요?
01:19:04공식 발표 블로그 포스팅을 보고 싶네요.
01:19:12아마 사용할 수는 있겠죠.
01:19:15전 계정이 없지만요.
01:19:16그래도 벤치마크 점수들이 다 나와 있는 공식 발표 글을 보고 싶네요.
01:19:29그럼요.
01:19:32Gemini로 문제 겪은 적은 한 번도 없습니다.
01:19:35네, 하지만 코딩용으로는 Gemini가 그렇게 만족스럽지는 않네요.
01:19:38벨기에에서 인사드립니다.
01:19:40채널과 전반적인 성격 모두 정말 마음에 들어요.
01:19:42정말 멋지십니다.
01:19:42정말 감사합니다.
01:19:43좋은 메시지 보내주신 모든 분께도 감사드려요.
01:19:45정말, 정말 감사합니다.
01:19:46저에겐 큰 의미가 있어요.
01:19:47정말 친절하시네요.
01:19:51맥스, 모든 것에 감사해요.
01:19:53감사합니다.
01:19:54방금 언급했듯이 모두에게 감사합니다.
01:19:56이런 스트리밍은 정말 즐거워요.
01:19:57이런 주제들에 대해 토론하고, 질문에 답하고, 다양한 관점에 대해 듣는 것이 정말 즐겁습니다.
01:20:02저 또한 배울 수 있는 좋은 방법이니까요.
01:20:05말했듯이 우리 모두 이걸 알아가고 있는 중이잖아요, 그렇죠?
01:20:07당연히 저도 예외는 아닙니다.
01:20:10제가 오픈 라우터를 사용하냐고요?
01:20:11네, 사용합니다.
01:20:12예를 들어 GLM 5.2 모델을 가지고 놀 때는 오픈 라우터를 사용하고 있죠.
01:20:19네.
01:20:22구글 제미나이가 LLM 시장에서 경쟁사들과 비교해 왜 고전하는지 정말 궁금해요.
01:20:26이 업계에서 쌓아온 데이터와 경험을 생각하면 말이죠.
01:20:30네, 저도 그 부분이 궁금합니다.
01:20:34구글이 거기서 뭘 하고 있는지 모르겠어요.
01:20:37그들은 엄청난 데이터를 가지고 있죠.
01:20:39분명히 재능 있는 엔지니어들과 데이터 과학자들, 그리고 ML 엔지니어들도 아주 많고요.
01:20:48모든 전문가를 다 보유하고 있죠.
01:20:50데이터도 엄청 많고요.
01:20:51왜 제미나이 모델이 제가 경험하기에, 그리고 많은 이들이 경험하는 것처럼, 다른 최상위 모델들보다 훨씬 못한지 모르겠어요.
01:21:01다른 모델들만큼 말이죠.
01:21:05벤치마크에서는 어느 정도 성과를 내지만, 네, 같은 수준은 아닙니다.
01:21:11코딩에 최적화하는 게 그들의 우선순위가 아닐 수도 있어요. 제 이해로는 코딩 전문성은 대부분 사후 훈련, 미세 조정, 강화 학습에서 나오거든요.
01:21:25거기서 AI 모델이 도구를 호출하고, 기술을 사용하고, 특정 코딩 패턴이나 관행을 인식하는 법을 배우는 것이니까요.
01:21:39네, 저라면 AI로 만드는 작업에 바로 뛰어들겠지만, AI가 생성한 코드가 무엇을 의미하는지도 병행해서 배워야 한다고 봅니다.
01:21:53아까 말했듯이, 작성되는 코드를 정말 이해해야 합니다. 모든 줄을 다 이해할 필요는 없지만, 만들어지고 있는 애플리케이션이 무엇인지에 대한 개념은 잡고 있어야 해요.
01:22:12검토해야 할 내용이 확실히 바뀌고 있어요. 그렇다고 모든 줄을 다 검토해야 한다는 건 아니에요.
01:22:21저도 그렇게 하지 않고요, 거리가 멀죠.
01:22:24하지만 AI가 당신을 위해 만든 소프트웨어가 전반적으로 무엇을 하는지, 어떤 기능과 API가 사용되는지 정도는 이해할 수 있어야 합니다. 그냥 무작정 AI가 하도록 두는 게 아니라요.
01:22:42저는 그게 중요하다고 생각합니다.
01:22:43모든 작은 결정에 의문을 제기할 필요는 없어요.
01:22:46자신의 코드 품질 기준을 강요할 필요도 없고요.
01:22:49저도 더 이상 그렇게 안 하거든요.
01:22:50하지만 본인의 소프트웨어, 애플리케이션의 일반적인 구조나 접근 방식에 대한 이해는 있어야 합니다.
01:23:03적어도 제 의견은 그렇습니다.
01:23:06프로젝트를 위해 AI가 읽을 수 있는 문서를 작성하시나요?
01:23:11아니요, 문서는 작성하지 않습니다.
01:23:13대신 사양서라고 부르거나, 뭐, 어쨌든 문서라고 부를 수도 있겠네요.
01:23:22제가 좋아하는 방식은 새로운 프로젝트를 시작할 때, 기존 프로젝트도 마찬가지지만, AI와 프로젝트에 대해 논의하고, 기존 프로젝트라면 AI가 분석하게 하는 거예요.
01:23:33다양한 아이디어와 옵션, 그리고 미처 예상하지 못했거나 고려해야 할 사항들에 대해 토론합니다. 그러고 나서 저도 반박을 하죠. 코드 리뷰 때와 마찬가지로 AI에게 “더 고려할 점이 있니?”라고 물으면 언제나 더 많은 걸 고려하라고 할 테니까요.
01:23:50무작정 받아들이지 않고 만족스러운 범위와 프로젝트 설명이 나올 때까지 AI와 토론합니다. 그 후 모든 기술적 세부 사항이 포함된 요약을 프로젝트의 마크다운 파일로 저장하라고 하죠.
01:24:05보통, 아니 대부분의 경우 그게 시작점이고, 거기서부터 하나씩 해결해 나가는 겁니다.
01:24:10그다음엔 AI에게 “이제 인증 기능을 작업하자”고 말하는 식이죠.
01:24:15그 프로젝트를 기반으로 계획을 세워달라고 합니다. 그렇게 접근하는 거죠.
01:24:19이런 식으로 접근합니다.
01:24:22충분한 폭의 주제를 시도해 보고 이제 전문화할 시간이라고 결정하는 기준이 뭔가요?
01:24:29AI와 논의할 때를 말씀하시는 건가요?
01:24:32딱히 정해진 규칙은 없습니다.
01:24:34학습에 대해 이야기할 때는, 코드의 특정 영역에서 무슨 일이 벌어지고 있는지 이해가 될 때까지 토론하는 게 좋습니다.
01:24:45계획에 대해 이야기하는 거라면, 그건 경험에서 나옵니다.
01:24:51만족스러운 답변이 아닐 거라는 건 알지만, 토론 상태와 프로젝트 범위에 만족하게 되는 건 경험이 쌓이면서 자연스럽게 느껴지는 거예요.
01:25:02혹시 제 답변이 틀렸다면 다시 말씀해 주세요.
01:25:04기회가 있을 때 감사의 말씀을 드려야겠네요.
01:25:10당신 덕분에 개발자가 될 수 있었어요.
01:25:12정말 감사합니다.
01:25:14전에도 말했지만, 계속 말해도 질리지 않네요.
01:25:17저에겐 큰 의미가 있습니다.
01:25:18제 콘텐츠와 강의가 누군가에게 취업하거나 커리어를 전환하는 데 도움이 되었다는 이야기를 들으면 정말 의미가 커요.
01:25:25제가 이걸 만든 이유기도 하니까요.
01:25:26그러니 정말 감사합니다.
01:25:27정말, 정말 감사합니다.
01:25:29저에겐 큰 의미입니다.
01:25:30너무나도 많이 감사합니다.
01:25:33네.
01:25:34X에 대한 의견에 동의해요.
01:25:36정말 소음이 너무 많죠.
01:25:37하지만 가끔 IT, 개발, 데브옵스 등에 관한 게시물들도 올라오곤 하니까요.
01:25:42인스타그램에서도 좋은 팁을 얻을 때가 있어요.
01:25:44네, 저는 인스타그램은 전혀 안 하거든요.
01:25:46그러니 제가 놓치고 있는 좋은 정보원일 수도 있겠네요.
01:25:49하지만 X는 좋은 정보원이고, 적절한 사람들을 팔로우하고 있어서 알고리즘이 저에게 꽤 잘 맞아요. 그 덕분에 좋은 통찰력과 소식을 얻고 있습니다.
01:26:05물론 모든 소셜 미디어가 그렇듯 30~40% 정도의 게시물은 무시해야 하죠.
01:26:10시간이 지나면서 어떻게 해야 할지 요령이 생기는 것 같아요.
01:26:17콜랩에 관해서는 저는 하지 않습니다.
01:26:19죄송해요.
01:26:20프리랜서 일과 사업으로 자신만의 AI 솔루션을 구축하는 데 Fast API를 배우고 사용하는 것에 대해 어떻게 생각하시나요?
01:26:27본인이 편하게 느끼는 걸 사용하라고 말씀드리고 싶네요.
01:26:29AI가 대부분의 라이브러리나 언어 등을 꽤 잘 다룰 수 있기 때문에, 과거보다 기술 스택의 중요성은 줄어들었다고 봅니다.
01:26:42그러니 본인이 즐겁게 느끼고 흥미로우며 잘하는 것을 사용하세요.
01:26:49그게 제 판단입니다.
01:26:49과거보다는 조금 더 자유가 있다고 말씀드리고 싶어요.
01:26:54이 AI 롤러코스터에서 계속 업데이트해 주셔서 감사합니다.
01:26:57함께해 주셔서 감사합니다.
01:26:57스트리밍에 참여해 주시고, 영상을 시청해 주시고, 저와 이 여정을 함께해 주셔서 감사합니다.
01:27:04GLM 5.2가 Opus 4.8만큼 좋다고 생각하시나요?
01:27:09꽤 좋았지만, GLM 5.2 구독을 하지 않아서 조금 짠돌이처럼 굴었던 것 같네요.
01:27:17Opus를 사용했던 만큼 많이 사용해 보지는 못했습니다.
01:27:27Opus는 구독 서비스에 포함되어 있어서 훨씬 더 많이 썼지만, GLM은 아니었거든요.
01:27:32그래서 Opus만큼 깊이 경험해 보지는 못했습니다.
01:27:39그래도 사용해 봤을 땐 꽤 인상적이었습니다.
01:27:43네, 판단하기 어렵네요.
01:27:45가끔 이 모델이 Opus 4.8보다 낫다는 글들을 보게 되는데,
01:27:52저는 개인적으로 그런 판단을 내리기가 어렵습니다.
01:27:56시간이 흐르면서 모델이 무엇을 잘하고 무엇을 못 하는지에 대한 느낌이 드는, 전반적인 분위기가 더 중요하죠.
01:28:10그리고 다시 한번 말하지만, 모델이 실행되는 환경의 하드웨어를 과소평가하지 마세요.
01:28:15그게 영향이 있거든요.
01:28:16모델에 부여하는 도구와 기술들, 그 모든 조합이 중요하죠.
01:28:21움직이는 요소가 워낙 많아서 저는 이게 저것보다 낫다고 말하기 어렵습니다.
01:28:28Fable이 정말 좋은 모델이라는 건 말할 수 있겠네요.
01:28:31그리고 미적 감각도 좋고요. 웁스, 죄송합니다.
01:28:35경험상 보기 좋은 프론트엔드를 만드는 데 있어서 센스가 아주 좋습니다.
01:28:40GPT 5.6은 적어도 Pi에서 사용할 때는 그 점에선 훨씬 못합니다.
01:28:45코덱에 대해서는 모르겠지만, Pi에서는 그렇게 뛰어나지 않아요.
01:28:52하지만 계획에 따라 작업을 수행하는 데는 정말 뛰어납니다.
01:28:56코드 베이스를 분석하는 것도 잘하고요.
01:29:00다시 말하지만, 올바른 기술과 도구를 주었을 때 말입니다.
01:29:03제가 접근하는 방식은 이렇습니다.
01:29:06이 모델이 저 모델과 같은 수준이라고 단정 짓기는 힘들어요.
01:29:11때로는 명확한 차이가 보이고요.
01:29:13어떨 때는 더 모호하죠.
01:29:17구글에는 유능한 엔지니어와 무능한 의사결정권자가 있죠.
01:29:21맞아요.
01:29:22어느 정도 일리 있는 말입니다.
01:29:25질문에 답해 주셔서 감사합니다.
01:29:27콘텐츠가 정말 훌륭하고 유용해요.
01:29:28정말 감사합니다.
01:29:29정말, 정말 감사합니다.
01:29:31지금 C#을 배우고 있습니다.
01:29:32특히 다룬 주제들을 구현하고 나중에 리팩터링하는 방식이 정말 마음에 듭니다.
01:29:37C# 비평가나 강사에 대해 추천해 주실 분 있을까요?
01:29:40저는 C# 강의를 들은 적이 없어서 잘 모르겠습니다.
01:29:45사실 지금 C#을 다시 배우고 있어요.
01:29:48처음 배운 언어 중 하나였거든요.
01:29:52아니, 엄밀히 말하면 첫 언어는 아니네요.
01:29:55대학 졸업 후 프로그래밍을 다시 시작하거나 더 진지하게 다가가면서 배웠죠.
01:30:04그러니까 약 16년 전쯤, 처음 시작한 건 24년 전이고요.
01:30:13대학 다닐 때 잠시 쉬었습니다.
01:30:18그때는 프로그래밍을 많이 안 했어요.
01:30:20다시 돌아와서 그때 C#을 배웠죠. 지금 재학습 중입니다.
01:30:23지금 다시 배우고 있어요.
01:30:25옛날 책으로 하고 있습니다.
01:30:27요즘은 AI 기술들이 워낙 많아서, 그냥 소파에 앉아 책 읽는 시간이 오히려 휴식이 되더라고요.
01:30:34이상한 방식의 스트레스 해소법일지도 모르죠.
01:30:38하지만 제겐 효과가 있습니다.
01:30:39그래서 아쉽게도 따로 추천해 드릴 강사는 없습니다.
01:30:43SAP 업계에서 오래 일하신 분이시네요.
01:30:46AI로 인해 많은 일이 벌어지는 지금, 웹 개발로 전향하는 게 의미가 있을까요?
01:30:51잘 모르겠습니다.
01:30:52웹 개발 시장은 현재 꽤 치열하거든요.
01:30:55개발 분야 전반의 고용 시장이 정말 안 좋으니까요.
01:30:59특히 웹 개발은 2020년과 그 이후 몇 년 동안 개발자가 엄청나게 유입됐습니다.
01:31:07그 전에도 이미 많았고요.
01:31:09그래서 고용 시장이 무척 붐비고 있죠.
01:31:12그런 면에서 웹 개발은 더 좋은 시절이 있었습니다.
01:31:17웹 개발이 항상 가진 큰 장점은 웹 애플리케이션을 구축할 때 플랫폼인 웹 자체가 거의 완전히 개방되어 있다는 점이죠.
01:31:36iOS 앱을 만들려면 애플의 검토 절차를 거쳐야 합니다.
01:31:40앱을 차단당할 수도 있고요.
01:31:41내려갈 수도 있죠.
01:31:43웹 개발에서 제가 항상 좋아했던 점은 개발 중 브라우저를 통해 화면을 즉시 확인할 수 있다는 겁니다.
01:31:50다른 프로그래밍 언어들은 그렇지 않죠.
01:31:53C++로 무언가를 만들면 터미널에서 보게 되니까요.
01:31:56그래픽 프로그래밍은 조금 더 복잡합니다.
01:32:00그런 면에서 좋습니다.
01:32:01제품을 만들면 이론상으로는 전 세계 누구나 접속할 수 있습니다.
01:32:07문제는 아무도 모른다는 거지만요.
01:32:10마케팅은 힘들어요.
01:32:11하지만 그게 웹 개발에 대해 여전히 좋아하는 점입니다.
01:32:13고용 시장은 전성기가 지났지만요.
01:32:17구글은 이미 AI 모델 개발 전쟁에서 패배했다고 생각합니다.
01:32:22이제 구글 검색이나 연구 등 대중적인 일반 사용자 쪽으로 더 집중하려고 하죠.
01:32:28맞아요.
01:32:28구글도 AI 개발 경쟁에서 더 나은 위치를 점하고 싶어 할 거예요.
01:32:37그렇지 않았다면 무엇이 남아 있고 무엇이 사라졌는지 아무도 모를 만큼 수많은 코딩 CLI와 도구를 쏟아내지는 않았겠죠.
01:32:48하지만 구글의 최종 목표는 AI 요약을 제공하고 검색창에 AI 챗봇을 넣는 것이라는 데 동의합니다.
01:33:00모든 제품을 AI로 검색할 수 있게 만드는 거죠.
01:33:04그들의 사명인 “지식을 전 세계 누구나 쉽게 접근할 수 있게 한다”는 것을 따르는 겁니다.
01:33:13물론 그 속에 광고를 포함하면서 말이죠.
01:33:17그들도 어떻게 이 서비스들을 수익화할지 여전히 고민 중일 겁니다.
01:33:21결국 구글은 코딩에 큰 관심이 없을지도 몰라요.
01:33:27하지만 한 가지 중요한 관점은 있습니다.
01:33:30더 나은 코딩 모델을 확보하면 더 좋은 AI 모델을 구축하기가 쉬워진다는 가설인데, 꽤 타당해 보입니다.
01:33:45좋은 모델을 만드는 데 필요한 과정, 즉 연구 준비와 모델 구축, 그리고 결국 그 모든 기반이 되는 실제 코드 작성 과정들이 코딩 모델이 꽤 잘 해낼 수 있는 부분이기 때문이죠.
01:34:08모든 관련 분야가 마찬가지고요.
01:34:10코딩 모델이 충분히 잘할 수 있는 영역입니다.
01:34:14좋은 모델이 미래의 더 나은 모델 구축을 돕는 선순환 구조를 볼 수 있는 거죠.
01:34:22만약 좋은 모델이 없다면 이 선순환에 진입할 수 없거나, 큰 격차로 인해 경쟁사들에게 영원히 뒤처지게 될 겁니다.
01:34:32그 가설이 완전히 터무니없게 들리지는 않습니다.
01:34:36그게 구글이 당면할 문제일 수도 있겠네요.
01:34:44BUN 강의 정말 잘 들었습니다.
01:34:45AI 시대에도 유익한 강의를 제공해 주셔서 기뻐요.
01:34:48시스템 디자인 강의는 언제 나오나요?
01:34:51올해 후반기를 계획하고 있지만, 아직 몇 주 이상은 더 걸릴 것 같습니다.
01:34:58아직 초기 단계거든요.
01:35:01즐거운 스트리밍 되세요, MIMX님.
01:35:02다음 시간에 뵙겠습니다, 참여해 주셔서 감사해요.
01:35:05다음 스트리밍 때 또 만나요.
01:35:07참여해 주셔서 감사합니다.
01:35:09Grill Me 스킬을 써보셨나요?
01:35:10사양서 작성에 완벽하거든요.
01:35:12아니요, 저는 저만의 방식이 있어서요.
01:35:15다시 한번 말하지만, 저는 제 힘으로 해결하고 싶습니다.
01:35:19그리고 저만의 접근 방식을 찾고, 저만의 기술을 쌓고 싶습니다.
01:35:23남의 기술은 전혀 사용하지 않습니다.
01:35:26직접 하고 있죠.
01:35:28물론 특정 기술이 무엇을 하는지 이해함으로써 영감을 얻기는 하지만, 당연히 그대로 베끼지는 않습니다.
01:35:34그 후에는 스스로 방법을 찾아내고 싶습니다.
01:35:39왜냐하면 결국 사양을 작성하고, 프로젝트의 범위, 기능, 기술 스택, 기술, 접근 방식, 그리고 그 안에 들어가는 모든 것을 결정하는 것은 제가...
01:35:56저는 좋은 사양이나 좋은 프로젝트 설명서, 또는 뭐라고 부르든 간에 AI에게 전달할 내용을 작성하는 데 무엇이 필요한지에 대해 꽤 명확한 비전을 가지고 있기 때문입니다.
01:36:07하지만 저는 제가 무엇을 만드느냐에 따라 직접 도달하고 싶습니다. 그게 저에게는 정말 잘 맞거든요.
01:36:16그리고 저에게는 특별한 기술이 필요하지 않습니다.
01:36:19물론 다른 사람들에게는 도움이 될 수 있다는 걸 부정하는 건 아닙니다.
01:36:22그리고 LangGraph나 LangChainPlane에 대한 강의도 없는데, 제가 그 기술들을 사용한 지 꽤 오래되었기 때문입니다.
01:36:29그래서 그 분야의 전문가는 아닙니다.
01:36:35정말 많은 이들에게 얼마나 아름다운 선물을 주셨는지요.
01:36:37라이프치히에서 인사드립니다.
01:36:38정말, 정말 감사합니다.
01:36:39읽는 것만으로도 너무 놀랍네요.
01:36:41무슨 말을 해야 할지 모르겠어요.
01:36:42정말 대단히 감사합니다, 헤수스 마리아.
01:36:46카살 토레스님.
01:36:47정말 감사합니다.
01:36:49안녕하세요, X에서 왔습니다.
01:36:50환영합니다.
01:36:52오늘 중국이 AI 여자친구를 금지했다는 소식 들으셨나요?
01:36:55아뇨, 못 들었습니다.
01:36:56그리고 말씀드리고 싶은 건...
01:36:58AI가...
01:37:00이건 전에도 말한 적이 있어요.
01:37:02만약 이런 형태의 AI가 없었더라도 저는 슬프지 않았을 겁니다.
01:37:08하지만 이미 존재하니 적응해야죠.
01:37:10괜찮습니다.
01:37:11비디오 생성, 이미지 생성 등과 관련된 AI의 측면들 중 제가 다소 곤란하다고 느끼는 부분들이 있습니다.
01:37:21단순히 저작권 문제 때문만이 아니라, AI로 이미지를 생성하는 것이 과연 좋은 사례인지 확신이 서지 않아서죠.
01:37:30비디오도 확실히 마찬가지고요.
01:37:33하지만 AI 여자친구 같은 것들이나...
01:37:37단순히 비디오 같은 것들에 대한 문제만이 아니라는 걸 알고 있습니다.
01:37:40텍스트나 챗봇일 수도 있고요.
01:37:42하지만 AI로부터 파생될 수 있는 결과들이 정말 위험하다고 생각합니다.
01:37:49어떤 사람들이 지나치게 외로워지거나, 삶의 어두운 영역으로 빠져드는 것은 정말 위험할 수 있다고 봅니다.
01:38:00우리는 이미 딥페이크 문제 등을 겪고 있고요.
01:38:04그래서 왜 그런 것들이 금지되는지 이해되는 측면들도 있습니다.
01:38:10하지만 독일이나 유럽에서 금지와 규제를 경험해 본 입장에서 볼 때, 그것이 좋은 해결책은 아닐 것이라 생각합니다.
01:38:21중국은 금지를 강제할 수 있는 도구를 조금 더 많이 가지고 있을지도 모릅니다.
01:38:31하지만 결국 사람들은 규제나 금지를 피할 방법을 찾아내기 마련입니다.
01:38:39그러니 규제가 필요한 부분이 있을 수도 있고 그것이 중요할 수도 있겠죠.
01:38:44그걸 부정하는 건 아닙니다.
01:38:47하지만 그것이 이 기술에서 발생하는 모든 문제를 해결해 줄지는 잘 모르겠습니다.
01:38:55어느 정도는 해결할 수 있겠지만, 그것이 궁극적인 해결책이라고 하기엔 회의적입니다.
01:39:01불행히도 저에게도 궁극적인 해결책은 없거든요.
01:39:05그러니 없는 것보다는 나을지도 모릅니다.
01:39:06하지만 네, 그런 부정적인 영향들에 대해서만으로도 두 시간 넘게 토론할 수 있을 겁니다.
01:39:14Mui처럼 훌륭한 UI 라이브러리가 있지만, Tailwind CSS 기반인 것들이 있나요.
01:39:23저는 그런 걸 사용하지 않을 것 같네요.
01:39:29물론 Shared CN은 어떤 관점으로 보느냐에 따라 찾으시는 것과 다를 수도 있습니다.
01:39:37하지만 저는 보통 그냥 순수 바닐라, 현대 CSS를 사용합니다.
01:39:43AI가 그런 코드를 정말 잘 작성해주기 때문이죠.
01:39:46아니면 Tailwind를 쓰거나, Tailwind에 Shared CN을 얹어서 씁니다.
01:39:50지난 몇 년간 그 외에 많이 쓴 것은 없네요.
01:39:54그래서 딱히 추천해 드릴 게 없네요.
01:39:56죄송합니다.
01:39:59애플리케이션 마케팅 방법에 대한 팁을 주실 수 있나요?
01:40:01성공적인 지원 방법을 물으시는 건가요?
01:40:03기본적으로 아까 말씀드렸듯이, 군중 속에서 눈에 띄는 방법을 찾는 것이 그 어느 때보다 중요하다고 생각합니다.
01:40:09그에 대한 한 가지 방법이나 접근법으로 X, 링크드인, 유튜브 같은 소셜 미디어 플랫폼에서 팔로워를 구축하거나 가시성을 확보하는 것을 고려해 볼 수 있습니다.
01:40:23모두 다 할 필요는 없고, 그중 하나라도 제대로 하는 게 좋습니다.
01:40:28다시 말하지만, 이게 가장 만족스러운 조언은 아니라는 걸 압니다.
01:40:32하지만 정말 치열한 시장에서 가시성을 확보하는 데 도움이 될 수 있다고 봅니다.
01:40:39인지도를 높여주는 모든 것은 아마 좋을 겁니다.
01:40:49제가 어떤 C# 책을 읽고 있냐고요?
01:40:52네, 잠깐 확인해 볼게요.
01:41:01그냥 가장 먼저 나오는 책 중 하나인 것 같네요.
01:41:08네, 그냥... 잠시만요.
01:41:13이 책입니다.
01:41:15특별할 건 없어요.
01:41:16아마존에서 C#을 검색하면 나오는 첫 번째 책들 중 하나일 겁니다.
01:41:22상당히 심도 있어요.
01:41:24정말 포괄적이죠.
01:41:28네, 그렇습니다.
01:41:29처음부터 배우는 건 아니고요.
01:41:32물론 그 책으로 그렇게 할 수도 있겠지만요.
01:41:34저는 그냥 C#을 다시 시작하는 단계거든요.
01:41:37그 목적으로는 아주 좋습니다.
01:41:38뭐, 저는 좀 독특하니까요.
01:41:40이런 식으로 공부하는 걸 좋아합니다.
01:41:42네.
01:41:45WebMCP가 미래에 어떻게 발전할 것 같냐고요?
01:41:48좋은 질문입니다.
01:41:49MCP 자체는 쉽지 않습니다.
01:41:54제가 보는 MCP의 가장 큰 장점은 인증을 추가하기가 쉽다는 점입니다. 그래서 에이전트가 인증된 방식으로 작동하게 하고 더 많은 제어권을 가질 수 있죠.
01:42:08그 외에는, 에이전트가 API 호출을 하기 위해 직접 코드를 작성할 수 있는 CLI나 직접적인 API 액세스가 더 유망하지 않을까 생각합니다.
01:42:22하지만 이건 모두 계속 발전하는 중이고 아직 초기 단계입니다.
01:42:26WebMCP도 그와 조금 관련이 있고요.
01:42:30지금은 꽤 틈새 기술이죠.
01:42:32앞으로 중요한 기술이 될지는 모르겠습니다.
01:42:39하기 싫은 말이지만, WebMCP가 대세가 되는 대신 기존 웹사이트들이 많이 사라지는 것을 보게 될지도 모릅니다.
01:42:55대신 에이전트들이 직접 통신할 수 있는 API와 CLI가 더 늘어나겠죠.
01:43:00음식을 주문하는 에이전트를 만든다면, 배달 서비스가 에이전트와 직접 대화할 수 있는 API를 제공하는 것이 가장 효율적일 테니까요.
01:43:12그게 다른 무엇보다 훨씬 효율적입니다.
01:43:16MCP일 수도 있겠지만, 왜 그냥 API를 주지 않는 걸까요?
01:43:20인증 문제는 분명한 점이지만, 이 기술들이 발전하면서 더 나은 해결책들이 나올 겁니다.
01:43:32오늘, 1Password에서 발표한 내용에 대해 읽었는데, Cloud Code 내에서 암호로 보호된 리소스에 대한 액세스를 더 쉽게 관리할 수 있게 해준다고 합니다.
01:43:45클라우드가 액세스를 요청하면 사용자가 승인하는 식인데, 에이전트나 모델은 비밀번호 등을 전혀 보지 못하게 하는 방식이죠.
01:43:54그래서 그 인증 문제는 아마 해결될 겁니다.
01:43:57확신할 수는 없지만요.
01:43:58네, API가 늘어나는 트렌드를 보게 될 겁니다.
01:44:05올해나 내년은 아니더라도, 시간이 지나면서 느리지만 꾸준하게 말이죠.
01:44:16물론 모든 웹사이트가 그렇다는 건 아닙니다.
01:44:22어쌔신 크리드 로그의 셰이 코맥처럼, 자신만의 기술을 만든다고 말할 수 있겠네요.
01:44:27안타깝게도 그 게임은 안 해봐서 어떻게 말하는지 모르겠네요.
01:44:33Angular를 해봤는데, 정말 놀랍더군요.
01:44:35네, 알고 있습니다.
01:44:36저도 Angular를 매우 좋아합니다.
01:44:3910년 전 Angular 2가 처음 나왔을 때는 조금 실수도 있었지만, 좋은 시절이었죠.
01:44:50그리고 React가 앞서 나갔죠.
01:44:52Angular 2는 너무 투박하고, 거추장스럽고, 복잡하고, 상용구(boilerplate)가 너무 많았다고 생각합니다.
01:44:58여러 이유로 React가 앞서 나갔죠.
01:45:0210년 전에 출시된 Angular 2가 지금의 모습과 더 가까웠다면 훨씬 더 대중적이었을 겁니다.
01:45:12하지만 그건 이제 와서 어쩔 수 없는 일이죠.
01:45:15그래도 현대의 Angular는 꽤 훌륭합니다.
01:45:19시스템 설계를 위한 책이나 참고 자료를 추천해 주실 수 있나요?
01:45:23아뇨, 저도 직접 찾아봤지만 책 한 권을 제외하고는 딱히 좋은 책을 찾지 못했습니다.
01:45:35제2판은 아직 읽어보지 않았어요.
01:45:39비교적 최근에 나왔거든요.
01:45:42잠시만요.
01:45:50마틴 클레프만의 '데이터 중심 애플리케이션 설계'입니다.
01:45:54제2판은 꽤 최근에 나왔죠.
01:45:56몇 달 전에 나온 것 같습니다.
01:45:59제2판은 아직 읽어보지 못했어요.
01:46:01저는 첫 번째 에디션을 읽었습니다.
01:46:03그리고 시스템 설계 주제를 다루고 있죠.
01:46:08정말 유용하게 읽었습니다.
01:46:11그래서 첫 번째 에디션이 훌륭했기 때문에 추천할 수 있는 자료입니다.
01:46:18두 번째 에디션도 그럴 것이라 생각합니다.
01:46:212026년의 Golang에 대한 생각은 어떠신가요?
01:46:28Golang은 훌륭한 언어입니다.
01:46:30그리고 AI 에이전트가 꽤 잘 다루기도 하고요.
01:46:33지난 5, 6년 정도, 아니 그보다 더 오래 Go로 일해왔습니다.
01:46:51나름 인기가 있었지만, 그렇다고 꼭 사랑받는 건 아니었죠.
01:46:59더 적절한 표현은, 꽤 많이 사용되었지만 사람들이 많이 사랑하는 언어는 아니었다는 점입니다.
01:47:09그건 지금도 사실이라고 생각합니다.
01:47:11그래도 Go는 좋은 언어입니다.
01:47:15성능이 중요한 애플리케이션을 만들기에 정말 훌륭하죠.
01:47:19구문의 대부분은 좋아하지만, 전부는 아닙니다.
01:47:24요즘에는 예전만큼 중요하지 않게 되었죠.
01:47:29어쨌든 AI가 잘 다룬다는 점이 꽤 도움이 됩니다.
01:47:32그래서 네, Go는 좋은 언어입니다.
01:47:36코딩 책을 읽을 때 독일어로 읽으시나요, 영어로 읽으시나요?
01:47:39영어로 읽습니다.
01:47:40코딩 책뿐만 아니라 거의 모든 책을 영어로 읽습니다.
01:47:41네, 코딩 관련은 당연히 영어로 읽고요.
01:47:44영어는 코딩의 주 언어이기 때문에 코딩 관련 리소스는 항상 영어로 소비해 왔습니다.
01:47:52이제는 코드를 직접 짜지 않거나, 혹은 대부분 짜지 않더라도 저를 포함해서 말이죠.
01:48:03구문의 모든 단어가 영어로 되어 있으니까요.
01:48:09그래서 항상 이상하다고 생각했어요.
01:48:12참고로, 강사로 일하면서 딱 한 번 독일어 강의를 만든 적이 있습니다.
01:48:189년 전 Udemy의 요청으로 제 Angular 강의의 독일어 버전을 만들었는데, 정말 끔찍했죠.
01:48:24단어를 독일어로 번역해야 할지, 아니면 영어 그대로 둘지 계속 고민해야 했거든요.
01:48:36예를 들어 '변수(variable)'는 독일어로 'variable'이라고 하는데...
01:48:39꽤 비슷하지만 다른 단어거든요.
01:48:42발음도 당연히 다르고요.
01:48:44그래서 번역하는 게 이상하게 느껴졌습니다.
01:48:48번역하지 않는 것도 이상하게 느껴졌고요.
01:48:51독일어로 읽는 것도 어색했죠.
01:48:54그래서 영어로 읽는 겁니다.
01:48:59Angular를 5년째 하고 있습니다.
01:49:02이제 백엔드 역할로 넘어가려는데 어떤 기술을 해야 할까요?
01:49:04또한, Angular의 미래는 어떻게 보시나요?
01:49:05음, 미래에 어떤 기술이 중요할지에 관해서라면, AI 덕분에 기술을 바꾸기가 더 쉬워지고 사람들이 기술 자체에는 그다지 신경 쓰지 않게 될 거라 생각합니다.
01:49:08역사적으로 Angular는 기업에서 인기가 많았지만, React가 훨씬 더 널리 사용되는 라이브러리인 것은 확실합니다.
01:49:20염두에 두어야 할 점이죠.
01:49:30그럼에도 Angular는 미래가 있습니다.
01:49:33네, Angular에는 미래가 있어요.
01:49:37구글은 수많은 서비스를 Angular 위에서 운영하고 있거든요.
01:49:42그러니 미래는 밝습니다.
01:49:43하지만 무엇을 위해 어떤 기술을 선택하느냐는, 특히 프론트엔드에서는 앞으로 덜 중요해질 것입니다.
01:49:53그럼에도 여전히 인기 있는 기술이나 특히 성능이 뛰어난 기술은 존재할 겁니다.
01:49:59어쨌든 Angular는 좋은 선택이라고 봅니다.
01:50:01많은 게 바뀌진 않았지만요.
01:50:04React가 더 널리 쓰이는 건 맞지만, Angular도 여전히 인기 있습니다.
01:50:15그 강의가 어떤 거였냐고요?
01:50:17Angular 강의였는데, 지금은 너무 오래되었습니다.
01:50:21Angular 2 강의거든요.
01:50:242017년에 출시했고, 업데이트도 안 했습니다.
01:50:30완전히 구식이 되었죠.
01:50:32원하신다면 구매는 가능하지만, 최신 Angular 지식을 기대하진 마세요.
01:50:37Golang은 클라우드, 인프라, 플랫폼 엔지니어링을 위한 언어 아닌가요?
01:50:41어느 정도는요.
01:50:42그렇게만 정의하고 싶지는 않네요.
01:50:44그쪽에서 인기 있는 건 확실하니까요.
01:50:46인프라 관리 업무든 다른 어떤 작업이든, CLI나 각종 유틸리티 도구, 스크립트를 빌드하는 데도 훌륭합니다.
01:50:58분명 그쪽으로도 아주 좋죠.
01:51:00어느 정도 인기 있는 것도 사실이고요.
01:51:03틀린 말은 아닙니다.
01:51:06Go로 웹 서버를 구축할 수도 있고, 성능도 대단합니다.
01:51:11정말 고성능이죠.
01:51:12다재다능한 언어라서 아주 매력적입니다.
01:51:18이제 기술 지식이 부족한 사람도 인상적인 프로젝트를 만들 수 있는 시대인데, 시니어 개발자는 어떻게 전문가임을 입증하는 프로젝트를 만들 수 있을까요?
01:51:29그건 과정에서 나오는 전문성이 중요합니다.
01:51:35과정, 그리고 이른바 '긴 승부'가 필요하죠.
01:51:40그럴듯해 보이는 프로토타입을 만드는 건 쉽습니다.
01:51:44프로그래밍 지식이 하나도 없어도 가능하니까요.
01:51:48진짜 상용화 가능한 수준의 제품을 만드는 건 훨씬 더 어렵죠.
01:51:53훨씬 더 어렵습니다.
01:51:55AI를 활용해 짧은 시간 안에 그런 상용화 수준의 애플리케이션을 만드는 건 훨씬 더 어렵고요.
01:52:06그러니까 단계가 다른 거죠.
01:52:08프로토타입 코딩?
01:52:09쉽죠.
01:52:11상용화 가능한 수준의 코딩?
01:52:12극도로 어렵습니다.
01:52:13어느 정도 지식이 있는 상태에서 상용화 수준의 앱을 구축하는 건요?
01:52:18가능은 하지만, 며칠이든 뭐든 시간이 좀 걸리겠죠.
01:52:22프로젝트마다 다르니까요.
01:52:24전문가라면 더 빠르게 할 수 있을 겁니다.
01:52:27그리고 당연히 유지보수 단계가 있죠.
01:52:29시간이 지나면서 기능을 추가하고 버그를 수정해야 하는 부분이요.
01:52:33거기서 다시 전문가의 실력이 빛을 발합니다. 지식이 있으면 애초에 문제가 적게 발생할 테니까요.
01:52:41그리고 문제를 수정하거나 기능을 추가하는 것도 훨씬 수월할 거고요.
01:52:47거기서 차이가 난다고 생각합니다.
01:52:48애플리케이션의 겉모습 같은 게 아니라, 바로 이런 과정이 중요한 겁니다.
01:52:53미래의 프레임워크 버전들이 AI에 더 최적화될 거라고 생각하시나요?
01:52:58네.
01:52:59미래 버전들이 AI에 더 최적화될 거라는 건 100% 확신합니다.
01:53:04더 많은 프로그래밍 언어와 프레임워크가 출시될 텐데, 애초부터
01:53:09에이전트와 AI를 위해 만들어진 것들이겠죠.
01:53:12그건 100% 일어날 일이라고 봅니다.
01:53:17맥스, 당신의 강의들이 얼마나 도움이 되었는지 말하고 싶었어요.
01:53:20우리 팀에 들어오는 모든 사람에게 추천하고 있습니다.
01:53:22팀 리드가 되기 전에도 저에게 큰 도움이 됐거든요.
01:53:25고마워요.
01:53:25감사합니다, 존 우드님.
01:53:27정말 감사합니다.
01:53:28큰 힘이 되네요.
01:53:29제 강의가 당신과 당신의 팀에게 긍정적인 영향을 미쳤다는 이런 메시지를 읽게 되어
01:53:33정말 너무 기쁩니다.
01:53:35멋진 피드백을 공유해 주셔서 진심으로, 진심으로 감사합니다.
01:53:40정말 큰 의미가 있어요.
01:53:42정말 감사합니다.
01:53:43그리고 방송에 함께해주신 여러분 모두 감사드려요.
01:53:45질문들을 다 해결했으니 여기서 마무리하기 딱 좋은 시점이네요.
01:53:50다음 방송에서는 제가 실제로 어떻게 AI를 활용해서 코딩하는지
01:53:55직접 보여드릴 수 있을 것 같네요.
01:53:57적어도 현재 제 상태는 그렇습니다.
01:53:59하지만 이제 가봐야 해요.
01:54:00그러니 그렇게 하죠.
01:54:01마지막 질문에 대한 짧은 답변.
01:54:03GCP와 AWS에 관한 질문이 있네요.
01:54:05저는 항상 써왔던 AWS를 선호합니다.
01:54:08Google Cloud 콘솔은 정말 끔찍하다고 생각하거든요.
01:54:11AWS 콘솔도 끔찍하긴 하지만, 구글은 더 심해요.
01:54:15그러니까 뭐, 그래요.
01:54:18그냥 전 항상 AWS로 작업해 왔을 뿐입니다.
01:54:21Google Cloud가 사실은 대단한데 제가 잘 모르는 걸 수도 있죠.
01:54:25그럼요.
01:54:26다들 감사해요.
01:54:27React 강의에 대한 정말 좋은 댓글도 남겨주셔서 감사합니다.
01:54:31유럽에서 꾸는 아메리칸 드림, 제게 큰 의미가 있습니다.
01:54:37그럼요.
01:54:38헤츠너(Hetzner)에 관해서는, 전 헤츠너가 좋아요.
01:54:40VPS 대여할 때 제공되는 가성비가 아주 좋다고 생각하거든요.
01:54:46헤츠너는 정말 훌륭합니다. 빠르게 공유하고 싶었어요.
01:54:50그럼 이만 마칠게요.
01:54:51참여해 주신 모든 분께 감사드립니다.
01:54:53녹화본은 나중에 다시 보거나 앞부분을 놓치신 분들을 위해 온라인에 남겨둘게요.
01:54:57다시 돌아올 수 있길 바랍니다.
01:55:00네.
01:55:00다음 주 목요일이 괜찮을 것 같네요.
01:55:04그럼 즐거운 저녁, 아침, 하루 보내시길 바라고, 미래에 다시 뵐 수 있기를 바랍니다.
01:55:10안녕히 가세요.

핵심 요약

AI 시대의 개발자는 코드 작성 자체보다 AI가 생성한 코드를 검토하고 상세한 기술 사양을 결정하는 시스템 디자인 역량을 강화해야 합니다.

하이라이트

  • AI와 개발자가 효과적으로 협업하는 워크플로우를 구축하는 것이 현재 모든 개발자가 갖추어야 할 핵심 역량입니다.

  • 바이브 코딩(코드베이스를 읽지 않고 AI가 생성한 결과물만 취하는 방식)은 일회성 프로토타입에는 적합하지만, 유지보수가 필요한 상용 프로젝트에는 악몽이 될 수 있습니다.

  • OpenAI는 매일 제한을 초기화해주는 구독 정책을 제공하여 비용 효율성 면에서 Anthropic보다 우위에 있습니다.

  • AI가 생성한 코드에 대해 “왜 이렇게 짰어?

  • 더 나은 대안은 없어?”라고 끊임없이 질문하며 기술적 타당성을 검토해야 합니다.

  • 최근 개발 워크플로우는 수동 코딩 비중을 줄이고 AI와의 의사결정 및 상세 계획 수립에 더 많은 시간을 할애하는 방향으로 변화했습니다.

타임라인

AI 시대의 개발 워크플로우 변화

  • AI 에이전트와 터미널 멀티플렉서인 '허더(Herder)'를 조합하여 생산성을 높이는 것이 중요합니다.
  • 수동 코딩 비중은 줄어들고 대신 프로젝트 설계와 구조화에 할애하는 시간이 증가했습니다.
  • 기술 스택의 지엽적인 부분보다는 시스템 디자인 및 코드 아키텍처에 대한 이해가 더 중요해졌습니다.

과거처럼 코드를 처음부터 끝까지 직접 짜는 방식은 사라졌으며, AI를 활용해 생산적인 개발 환경을 구축하는 과정 자체가 새로운 즐거움이 되었습니다. 기술 변화가 워낙 빨라 매일 새로운 에이전트 프레임워크와 도구를 실험하며 자신만의 개발 방식을 찾는 과정이 필수적입니다.

바이브 코딩과 에이전트 기반 엔지니어링의 차이

  • 바이브 코딩은 코드의 내부 동작을 신경 쓰지 않고 결과물만 취하는 방식이며 유지보수성이 낮습니다.
  • 에이전트 기반 엔지니어링은 AI와 협업하여 계획과 사양을 검토하고 신뢰할 수 있는 시스템을 구축하는 방식입니다.
  • AI를 잘못 사용하면 코드 품질이나 프로젝트 방향을 추적하지 못하는 위험이 발생합니다.

코드 한 줄 쓰지 않는 바이브 코딩은 일회성 도구에는 유용하지만, 진지한 상용 소프트웨어를 개발할 때는 지양해야 합니다. 미래의 개발자는 AI가 생성한 코드를 읽고 비판적으로 분석하며 테스트 전략까지 수립하는 능력을 갖춰야 합니다.

AI 도구 선택과 개발자 전문성

  • 구독형 AI 모델 중에서는 사용량 제한 초기화 기능이 강력한 ChatGPT가 가성비가 가장 높습니다.
  • AI 기반 프로젝트를 진행할 때 수동 테스트와 직접적인 코드 리뷰는 여전히 필수적입니다.
  • AI가 코드 작성을 대신하더라도 개발자는 기술적 구현 세부 사항과 트레이드오프를 결정해야 합니다.

AI 툴을 사용할 때 가장 큰 함정은 에이전트에게 모든 것을 맡기다가 전체적인 코드베이스의 추적을 놓치는 것입니다. 특히 업무량이 급증할 때 무작정 AI에게 의존하면 품질 낮은 결과물이 나올 수 있으므로, 개발자의 주도적인 판단과 조정이 병행되어야 합니다.

학습 전략 및 커리어 관리

  • 소셜 미디어를 통해 개발 활동의 존재감을 드러내는 것이 현재의 가혹한 취업 시장에서 생존하는 방법입니다.
  • AI 관련 도구와 모델에 대한 깊은 학습보다는 도구와의 협업 방식을 터득하는 것이 우선입니다.
  • AI와 협업하는 방법을 배우려면 AI가 짠 코드에 대해 계속해서 대안을 묻는 토론 과정을 거쳐야 합니다.

기업들은 단순히 코딩만 하는 지원자보다 AI를 효과적으로 사용하여 비즈니스 문제를 합리적으로 해결하는 개발자를 원합니다. 전문적인 에이전트 구축 역량을 갖추기 위해 특정 업무를 전문으로 하는 에이전트를 직접 만들어보고 기술적 세부 사항을 끊임없이 파고드는 노력이 필요합니다.

향후 기술 전망 및 마침말

  • 미래의 개발 환경은 AI와 에이전트 구축에 최적화된 새로운 프레임워크 위주로 재편될 것입니다.
  • 시스템 디자인의 고전인 '데이터 중심 애플리케이션 설계'와 같은 서적은 AI 시대에도 여전히 유효한 기초를 제공합니다.
  • 모든 작은 결정에 의문을 제기할 필요는 없지만, 애플리케이션의 전반적인 구조와 접근 방식은 개발자가 이해하고 있어야 합니다.

기술은 빠르게 진화하지만, 좋은 소프트웨어를 구축하기 위한 논리적 사고와 문제 해결 능력은 변하지 않는 가치입니다. AI는 도구일 뿐이며, 최종적으로 결과물에 책임을 지는 것은 개발자의 몫이므로 코드가 무엇을 의미하는지에 대한 기본 소양을 게을리해서는 안 됩니다.

커뮤니티 글

모든 글 보기