스크립트
00:00:00감사합니다.
00:00:30감사합니다.
00:01:00꽤 자주 받는 질문이라 흥미로운 유튜브 영상이 될 것 같네요.
00:01:07그래서 실시간 스트리밍으로 진행하면서 의견도 듣고 질문도 받아보면 어떨까 싶었습니다.
00:01:13잠시 기다려 볼게요.
00:01:19안녕하세요, 여러분.
00:01:20함께해 주셔서 감사합니다.
00:01:23다시 스트리밍을 하게 되어 정말 기쁩니다.
00:01:25지난주는 건너뛰어야 했거든요.
00:01:28혹시 모르시는 분들을 위해 말씀드리자면, 저는 매주 목요일마다 스트리밍을 하려고 노력합니다.
00:01:32물론 매주 목요일마다 할 수 있는 건 아니지만요.
00:01:35오늘은 가능하네요.
00:01:36방금 말씀드린 것처럼, 여기저기서 이런저런 방식으로 꽤 자주 받는 질문에 대해 스트리밍을 해보려고 합니다.
00:01:492026년에 어떤 기술 스택을 선택해야 하는지, 그리고 그게 여전히 중요한지에 대한 것이죠.
00:01:55AI가 있으니 이제 중요하지 않다고 주장할 수도 있겠죠.
00:01:57더 이상 중요하지 않다면서요.
00:01:58제 관점을 공유하고, 여러분의 생각도 들어보고 싶습니다.
00:02:02그럼 시작할게요.
00:02:02안녕하세요, 여러분.
00:02:03인사해 주시고 좋은 메시지 남겨주셔서 감사합니다.
00:02:06여러분 모두 만나서 정말 반가워요.
00:02:08참여해 주셔서 정말 감사합니다.
00:02:11그럼 바로 시작해 볼까요?
00:02:17작년쯤에 Vue, React, Angular를 비교하는 비슷한 스트리밍을 했던 것 같아요.
00:02:26오늘은 그런 비교를 하려는 게 아닙니다.
00:02:28어떤 프레임워크가 더 나은지 세세하게 기술적으로 비교하는 시간이 아니에요.
00:02:35그 대신, 무언가를 만들 때 AI를 사용하든 안 하든 일반적으로 무엇을 고려해야 하는지에 대한 이야기입니다.
00:02:43AI를 사용해야 하는지도 흥미로운 질문이죠.
00:02:47저는 AI를 사용할까요?
00:02:48제 관점을 공유하고 싶습니다.
00:02:51그리고 투명하게 말씀드리고 싶어요.
00:02:53제가 세상의 모든 기술을 사용해 본 것은 당연히 아닙니다.
00:02:59제가 주로 사용하는 JavaScript와 TypeScript 생태계에만 집중해서 이야기할 예정입니다.
00:03:06Python이나 .NET 같은 세계에 대해서는 잘 알지 못하니까요.
00:03:12그래서 제가 아는 것에 집중하겠습니다.
00:03:16여러분께서 하실 만한 큰 질문 중 하나는 '과연 그게 중요할까?'일 겁니다.
00:03:21어떤 프레임워크나 데이터베이스를 사용하는지가 정말 중요할까요?
00:03:27어차피 AI를 사용해 코드를 작성할 수도 있으니까요, 그렇죠?
00:03:32그럼 무슨 차이가 있을까요?
00:03:35매우 중요하고 비판적인 질문이라고 생각합니다.
00:03:40왜냐하면, 과거와 같은 이유로 중요하지 않을 수도 있고, 혹은 과거에 중요했던 모든 이유 때문에 중요한 것은 아닐 수 있기 때문이죠.
00:03:50하지만 여전히 중요한 이유도 많다고 생각합니다.
00:03:53어떤 기술 스택을 선택하느냐는 중요합니다.
00:03:58그럼, 그것부터 시작해 볼까요?
00:04:00사용하는 기술 스택이 정말 중요할까요?
00:04:05제 대답은 당연히 '그렇다'입니다.
00:04:09하지만 왜일까요?
00:04:10중요한 이유는 무엇일까요?
00:04:13기술 스택이란 것은 당연히 많은 것들을 포함합니다.
00:04:21단순히 프론트엔드 프레임워크만 고르는 게 아니죠.
00:04:24어떤 데이터베이스를 사용할지도 중요합니다.
00:04:27인증은 어떻게 처리할 건가요?
00:04:30콘텐츠는 어떻게 관리할 건가요?
00:04:31어디에 호스팅하고 배포할 계획인가요?
00:04:36무엇을 빌드하거나 보조하기 위해 어떤 AI 에이전트를 사용하시나요?
00:04:42이 모든 것이 중요한 질문들입니다.
00:04:44설령 프론트엔드나 백엔드 프레임워크 수준에서만 본다 해도, 사실 그게 전부는 아닙니다.
00:04:51아, 물론 저는 웹 개발을 이야기하는 중입니다.
00:04:55프론트엔드, 백엔드 프레임워크만 이야기하는 게 아닙니다.
00:05:00어떤 데이터베이스를 사용할지도 중요합니다.
00:05:02보시다시피 이 모든 것은 어디에 호스팅하려는지에 따라 영향을 받게 될 겁니다.
00:05:08그건 다시 말씀드릴게요.
00:05:09어떤 선택들은 어디서나 작동하지 않을 수 있고, 비용 문제도 있어서 매우 비싼 선택을 할 수도 있으니까 중요하죠.
00:05:22물론 확장성도 중요합니다.
00:05:25하지만 여기엔 상충 관계(trade-off)가 있고, 제가 다루고 싶은 게 바로 그것입니다.
00:05:29그걸 무시하더라도, 과거에는 AI 이전이나 초기 시절에 개발자 경험 같은 것이 매우 중요했죠.
00:05:43제게도 특정 프레임워크를 작업할 때 얼마나 즐거운지가 중요했습니다.
00:05:53데이터베이스 관련해서도 다시 이야기할게요.
00:05:55하지만 프레임워크 수준에서 보자면, 문법이나 사용 편의성이 얼마나 즐거운지가 매우 중요했습니다.
00:06:07문법, 코드 스타일, 사용 편의성이 중요했죠.
00:06:17생태계도 있었죠.
00:06:20예를 들어, Vue 대신 React를 선택한 이유가 차트 라이브러리, 라우팅 같은 구축 도구들이 더 많고, 학습할 강의나 리소스가 더 많기 때문이었을 수 있습니다.
00:06:39이제 이런 점들은 덜 중요해지거나 변화했다고 봅니다.
00:06:47특히 문법이나 코드 스타일은 제게 확실히 변화했습니다.
00:06:51완전히 사라진 건 아니지만, 훨씬 덜 중요해졌죠. 아마 여러분 대부분도 채팅에 남겨주시면 좋겠지만,
00:07:00많은 개발자가 최소한의 도움을 받기 위해 AI를 사용하고 있다고 생각합니다.
00:07:09어떤 분들은 AI로 모든 코드를 생성하기도 하죠.
00:07:11일부는 바이브 코딩을 하고 있죠.
00:07:13제가 말하는 건 그런 게 아닙니다.
00:07:15만약 여러분이 바이브 코딩을 하거나 Lovable 같은 플랫폼을 사용한다면, 기술 스택은 이미 정해진 거니 중요하지 않습니다.
00:07:25저는 여러분이 직접 만드는 프로젝트를 말하는 거지만, 물론 AI를 활용할 수도 있겠죠.
00:07:31여전히 제게 문법과 코드를 얼마나 좋아하는지는 AI와 함께하면서 덜 중요해졌습니다.
00:07:39완전히 사라진 건 아니에요.
00:07:40여전히 제 눈에 코드가 쓰레기처럼 보이는 언어나 라이브러리로 작업하는 건 좋지 않거든요.
00:07:50예를 들어, Python 코드가 쓰레기라서가 아니라, 제게는 Python 코드를 쓰는 게 즐겁지 않아서 별로 좋아하지 않았어요.
00:08:01해본 적은 있어요.
00:08:02할 줄은 압니다.
00:08:03전문가는 아니지만 제 취향은 아니었죠.
00:08:07이제 AI와 함께라면, 상황에 따라 덜 신경 써도 될지 모릅니다.
00:08:11그래도 저는 Python을 많이 쓰진 않아요. 전문가도 아니고, 기술 스택을 알고, AI로 생성한 코드를 이해하는 능력을 갖추는 게 여전히 그 어느 때보다 중요하다고 생각하기 때문입니다. 자신이 만드는 제품을 아끼고 싶고, 제품으로부터 완전히 단절되고 싶지 않다면 말이죠.
00:08:37다시 말하지만, 바이브 코딩을 해도 괜찮습니다. 자신의 일회성 소프트웨어나 내부 도구를 만들 때는 괜찮겠지만, 상용 제품을 만들어 배포하고 판매한다면, 저는 코드를 이해하고 읽을 수 있는 능력이 중요하다고 믿습니다.
00:08:55그런 이유로 저는 여전히 주로 TypeScript와 JavaScript를 사용합니다. 하지만 라이브러리 선택에 있어 문법 취향이 미치는 영향은 적어졌어요.
00:09:08이제 생태계 같은 건 여전히 중요합니다.
00:09:13튜토리얼이 얼마나 많은지는 덜 중요할지 몰라도, 아예 중요하지 않은 건 아닙니다. AI로 코딩하더라도, 무언가를 읽거나 강의를 보거나, 에이전트에게 블로그 포스트를 지정해 주거나, 웹 검색을 하도록 시킬 수 있다는 점은 중요하니까요.
00:09:42그래서 AI를 활용해 좋은 코드가 생성되도록 유도하고 싶으니까 중요합니다.
00:09:51공통된 모범 사례와 패턴을 따르는 코드 말이죠. 그리고 그 패턴과 모범 사례가 잘 문서화되어 있다면 당연히 도움이 됩니다.
00:10:00공식 문서에서 그럴 수 있지만, 모든 기술이 그런 건 아닙니다.
00:10:07블로그 포스트 같은 곳에 있는 경우가 많죠.
00:10:11그래서 여전히 중요하지만, 조금 덜 중요해졌을 수도 있습니다.
00:10:16사용 가능한 라이브러리 측면에서의 생태계 중요성은 확실히 변화했습니다.
00:10:24예를 들어 2020년에는 React를 위한 라이브러리가 무엇이든 다 있어서 React를 선택했을 수도 있죠.
00:10:34차트를 만들고 싶으면 아마 10개나 100개의 다른 라이브러리 선택지가 있었을 겁니다.
00:10:40폼 제출을 처리하고 싶으면, 여기 있네요.
00:10:43수많은 라이브러리가 있었죠.
00:10:45무엇을 생각하든 그것을 위한 라이브러리가 있었어요.
00:10:48React를 위한 모든 상태 관리 라이브러리들을 생각해 보세요.
00:10:54이제는 덜 중요해졌다고 봅니다.
00:10:57또한 공급망 공격들 때문에 더 직접 구축하려고 노력했고, AI 덕분에 더 쉬워졌죠.
00:11:10두 가지 큰 이유로 AI와 함께 쉬워졌습니다.
00:11:14첫째는 당연히 속도 이점입니다.
00:11:16과거에는 제 나름의 차트 라이브러리를 구축하는 게 실현 불가능했을 겁니다.
00:11:22이제 AI가 있으니 확실히 가능해졌죠.
00:11:25특히 오픈소스나 배포가 아닌 저만을 위해 빌드한다면 더욱 그렇습니다.
00:11:30애플리케이션의 빌딩 블록일 뿐이라면 모든 기능을 할 필요는 없죠.
00:11:35필요한 기능만 하면 됩니다.
00:11:37그래서 더 쉬워졌습니다.
00:11:39AI와 함께하니 경험이 부족한 기술을 탐구하기도 쉬워졌다고 생각합니다.
00:11:48애플리케이션에 차트를 만들기 위해 SVG를 사용한다고 해보죠.
00:11:52전 SVG 전문가가 아닙니다.
00:11:54그럴 필요도 없고요.
00:11:55AI를 통해 코드를 생성하면 되니까요.
00:11:57작성하는 것과는 다르기에 이해하고 의미를 파악할 수는 확실히 있습니다.
00:12:03이 부분에서 AI가 제 관점을 바꿔놓았습니다.
00:12:07결론적으로, AI 덕분에 이 부분들에 대한 제 관점은 바뀌었습니다.
00:12:16전혀 중요하지 않다는 건 아니지만, 확실히 변했습니다.
00:12:19물론 이것들이 유일한 고려 사항은 아니죠.
00:12:21모든 기술, 특히 프레임워크와 라이브러리에 대해 또 중요한 고려 사항은 유지보수입니다.
00:12:30유지보수.
00:12:36작성된 방식을 알 수 없을 때를 아실 겁니다.
00:12:41네, 죄송합니다.
00:12:42잘 유지보수되는 기술을 선택하고 싶으시겠죠.
00:12:48재밌게도 '잘 유지보수된다'는 말은 AI 시대에 다른 의미를 가질 수 있습니다.
00:12:53물론 하나는 예전부터 그랬듯, 자주 업데이트되고 패치되고 최신 상태로 유지된다는 의미겠죠.
00:13:02보안과 관련이 있기 때문에 중요합니다.
00:13:05또한 새로운 기능을 사용할 수 있고 시간이 지나며 성능이 향상될 수도 있다는 의미죠.
00:13:10잘 유지보수되는 것을 사용하고 싶으실 겁니다.
00:13:12하지만 공급망 공격들로 인해 잦은 업데이트가 단점이 될 수도 있습니다.
00:13:18그래도 일반적으로는 더 이상 업데이트되지 않는 건 사용하고 싶지 않죠.
00:13:25참, 채팅의 질문과 의견들도 다시 다룰 예정입니다.
00:13:28이 생각만 마무리하고요.
00:13:31유지보수와 관련해서, 말씀드렸듯이 저는 라이브러리를 덜 사용하려고 노력합니다.
00:13:46의존성에는 정도가 있으니까요.
00:13:49그래도 사용하게 된다면 잘 유지보수되는 걸 원합니다.
00:13:54물론 잘 유지보수되는 게 좋죠. 보너스처럼요.
00:13:57하지만 이상적으로는 Vue, React, Angular 팀처럼 제가 신뢰하는 사람들이 관리하는 것이 좋습니다.
00:14:07그들이 무엇을 하는지 알고 있다고 믿고, 그저 엉성한 AI 코드를 무분별하게 그들의 라이브러리에 밀어 넣지 않으리라 믿기 때문입니다.
00:14:20물론 그런 위험도 있으니까요.
00:14:22요즘 어떤 유지보수자가 엉성한 AI 코드로 범벅된 라이브러리를 공격적으로 업데이트할 수도 있습니다.
00:14:28진지하게 말해서, 우리 모두 사용 중인 라이브러리의 코드를 정말 검사하고 있나요?
00:14:33아마 아닐 겁니다.
00:14:35꼭 문제인 건 아니지만, 번들 비대화, 성능 이슈, 잠재적 보안 문제를 일으킬 수 있습니다.
00:14:42그래서 고려해야 할 것들이고 제가 주의 깊게 살피는 부분입니다.
00:14:50자, 다시 돌아가 보죠.
00:14:52생각은 훨씬 더 많지만, 채팅창의 코멘트와 질문들도 얼른 살펴보도록 하겠습니다.
00:14:59Java 또는 Spring Boot와 React, 여전히 수요가 있을까요? 아니면 Golang 같은 틈새 기술을 배워야 할까요?
00:15:04Java Spring Boot는 확실히 여전히 엄청나게 인기 있고, 특히 엔터프라이즈 분야에서 그렇습니다.
00:15:09제가 직접 작업해 본 적은 없고 읽어본 내용이라 전문가라고 할 순 없지만요.
00:15:15당장 사라질 기술은 아니라고 생각합니다.
00:15:20어떤 프로그래밍 언어를 써야 할지에 대해서는 다시 이야기할 테니 일단 넘어가겠습니다.
00:15:27오, 새로운 팔로워 이정표를 달성했네요.
00:15:32대박이네요.
00:15:34C#, Blazor, MAF, .NET, Maui 등이 있네요.
00:15:40정말 놀라운 스택들이 많이 있습니다.
00:15:42언급했듯이 저는 제 세계인 TypeScript, JavaScript 세상에 집중할 겁니다.
00:15:49Max는 Udemy를 받을 자격이 없다.
00:15:51Udemy는 Max를 받을 자격이 없다.
00:15:55네, Udemy와는 좋은 시절을 보냈고 여전히 보내고 있습니다.
00:16:00미래는 조금 불투명하지만 어디로 갈지 지켜보죠.
00:16:05여전히 React와 Next.js 사이에서 혼란스럽습니다.
00:16:07네, 그것도 다시 다룰게요.
00:16:12Astro.
00:16:13Astro는 정말 놀랍죠.
00:16:18AI는 항상 존재하는 헬퍼 함수를 쓰기보다 자기만의 함수를 바닥부터 짜려고 해요.
00:16:22맞아요. AI는 모델에 따라 다르지만 제 경험상, 불필요한 헬퍼 함수를 코드에 많이 추가하고, 엄청 방어적으로 굴면서 폴백의 폴백의 폴백을 만드려는 경향이 있습니다.
00:16:36그게 바로 제가 코드를 이해할 수 있어야 한다고 말하는 이유입니다.
00:16:39저는 AI를 올바르게 유도해서 그런 쓸데없는 코드들이 코드베이스에 남지 않게 하고 싶고, 무조건 다 받아들이고 싶지 않거든요.
00:16:46네, 그렇습니다.
00:16:47그럼 어떤 프레임워크를 써야 할까요?
00:16:51그게 중요할까요?
00:16:51음, 제가 중요하게 보는 부분들이기 때문에 중요합니다.
00:16:55하지만 또 한편으로는 중요하지 않기도 하죠.
00:16:57React든, Angular든, Vue든 어떤 걸 쓰든 상관없는 상황들이 많습니다.
00:17:03물론 회사에서 일한다면 중요하겠죠.
00:17:05회사에서 Angular를 쓴다면 Angular를 써야 하니까요.
00:17:08하지만 자신만의 작은 프로젝트를 만든다고 해보죠.
00:17:12자영업을 하신다거나,
00:17:13회사를 창업한다거나요.
00:17:15그럴 땐 어떤 프레임워크를 쓰든 상관없습니다.
00:17:18AI가 확실히 가장 선호하는 건 React, 그리고 Next.js입니다.
00:17:23이들이 어떻게 관련되어 있는지는 곧 다시 이야기할게요.
00:17:26하지만 그렇다고 꼭 이걸 써야 하는 건 아닙니다. 왜냐하면 이제 우리는 초기 AI 시절이 아니니까요.
00:17:33AI에 내장된 지식에만 의존해야 했던 그런 시절이 아니죠.
00:17:38이제 Codex, Cloud Code, Pi 같은 새로운 코딩 보조 도구들과 그 모델들은,
00:17:45웹 검색을 하거나 웹 리소스를 방문하는 걸 꽤 잘합니다.
00:17:50특정 리소스를 지정해 줄 수도 있고, 물론 복사해서 넣을 수도 있죠.
00:17:54그래서 저는 AI 에이전트가 학습되지 않은 완전히 새로운 라이브러리로도 작업하게 만들 수 있었습니다.
00:18:05예를 들어 Vercel이 AI 에이전트 빌드 프레임워크를 출시했을 때 지난 며칠 동안 가지고 놀아봤습니다.
00:18:12꽤 흥미로워서 강의를 만들어 볼까 생각 중이에요.
00:18:15이건 분명히 AI 모델 가중치에는 학습되지 않은 것들이죠, 그렇죠?
00:18:21모델 자체는 그것에 대해 아무것도 모릅니다.
00:18:23하지만 문서화된 자료를 알려주고, 시작 페이지를 제공하며, 힌트를 주어 방향을 잡아주면,
00:18:29그게 바로 여러분이 할 일이죠, 그렇죠?
00:18:30그 프레임워크를 사용하는 방법을 정말 학습하거나 이해할 수 있고, 실제로 작동하게 만들 수 있습니다.
00:18:36그러니 React가 AI 모델들이 가장 선호하는 것이라고 해서 꼭 여러분이 그걸 써야 한다는 뜻은 아닙니다.
00:18:42저는 여러분이 편하게 사용할 수 있는 것을 쓰라고 말씀드리고 싶어요. 제 생각에는 최소한 코드를 직접 이해하는 것이 중요하기 때문이죠.
00:18:50이제, 사용하는 언어에 관해서는 말씀드렸듯이 저는 TypeScript를 선호합니다.
00:18:56하지만 당연히 다른 선택지들도 있죠, 안 그런가요?
00:18:59언어에 관한 게 아니라, 런타임에 관한 이야기입니다. 서버 사이드 코드를 말하는 거라면요. 클라이언트 사이드는 어차피 TypeScript니까요,
00:19:07나중에 컴파일되어 사라지죠.
00:19:09하지만 서버 사이드에서는 Node.js를 사용할 수도 있고, Bun을 사용할 수도 있고, 당연히 Deno도 사용할 수 있습니다.
00:19:15이 세 가지가 중요한 선택지라고 봅니다.
00:19:18다시 말하지만 여러분이 좋아하는 것을 고르면 되는데, 제 개인적인 선호는 Bun입니다.
00:19:22조만간 관련 강의도 나올 예정이에요.
00:19:24그건 그렇고, 소식을 계속 받고 싶으시면 뉴스레터를 구독하시거나 저희 디스코드 커뮤니티에 참여해 주세요.
00:19:31새로운 강의 소식을 공유하고 있으니까요.
00:19:33저는 Bun이 정말 좋습니다. 속도가 정말 빠르거든요. 그게 참 대단하죠.
00:19:38게다가 유용한 기능들도 많이 내장되어 있고요.
00:19:41내장된 기능이 너무 많아서 Bun을 싫어하는 분들도 꽤 많다는 걸 잘 알고 있습니다.
00:19:48순수하지 않다고들 하시더라고요.
00:19:52하지만 저는 예를 들어, SQLite 클라이언트가 내장되어 있다는 사실이 참 마음에 듭니다.
00:19:56SQLite에 대해서는 나중에 다시 얘기할게요.
00:19:57정말 훌륭한 데이터베이스거든요.
00:19:58저는 그게 내장되어 있다는 점이 좋습니다. 또 공급망 공격 같은 문제도 있으니까, 라이브러리 양을 줄이는 게 저에게는 나쁜 아이디어가 아닌 것 같거든요.
00:20:10그리고 라이브러리 없이도 기능이 구현된 런타임을 사용하는 것도 아주 좋은 것 같습니다.
00:20:18그리고 점점 더 많은 라이브러리를 사용하게 되면, 공급망 문제를 제쳐두더라도, 이 라이브러리들이 계속 잘 유지되고 서로 잘 작동하기를 바라야 하는 상황이 생기니까요.
00:20:30네, 그런 이유로 저는 Bun을 좋아합니다.
00:20:33필요한 모든 것이 다 내장된 건 아니에요.
00:20:35그리고 가능한 기능을 전부 다 사용하는 것도 아니고요.
00:20:38하지만 몇몇 기능은 정말 좋습니다.
00:20:40물론, 그렇다고 해서 Node.js가 나쁜 선택이라는 건 아닙니다.
00:20:45이미 제 Academy 유튜브 채널에 영상을 올렸듯이, Node.js에도 많은 사람들이 잘 모르는 내장 기능이 꽤 많이 들어 있거든요.
00:20:53예를 들어, SQLite 클라이언트도 내장되어 있습니다.
00:20:56다시 말하지만, 아는 사람이 많지 않죠.
00:20:58하지만 Node.js에서 SQLite를 임포트해서 사용할 수 있습니다.
00:21:03그럼 거기도 추가 라이브러리가 필요 없죠.
00:21:06그래서 Node.js도 정말 많이 발전했습니다.
00:21:09TypeScript도 기본적으로 지원하고요.
00:21:11이것도 많은 분들이 잘 모르는 사실이죠.
00:21:13결국, 선택은 여러분에게 달려 있습니다.
00:21:15Bun은 작은 성능 이점이 있고요.
00:21:19그래서 제가 선택한 겁니다.
00:21:21어쨌든, 이것들은 단지 고려해야 할 트레이드오프입니다.
00:21:24그리고 모든 것을 AI로 작동하게 만들 수는 없습니다.
00:21:27언제나 그렇듯, 올바른 방향으로 이끌어줘야 하죠.
00:21:33자, 어디 봅시다.
00:21:34채팅창.
00:21:44네, Laravel.
00:21:45채팅창에 Laravel이 나왔네요.
00:21:46그것도 아주 훌륭하죠.
00:21:48저는 10년 전만 해도 Laravel 개발자였습니다.
00:21:52그 이후로는 거의 사용하지 않았지만요.
00:21:54하지만 정말 대단한 프레임워크입니다. 사실상 모든 기능, 혹은 필요한 거의 모든 것이 다 들어 있으니까요.
00:22:01많은 상황에서 애플리케이션을 구축하는 데 필요한 모든 것이 내장되어 있습니다.
00:22:09인증 기능, 큐, 작업 관리, 스케줄링 등 모든 재밌는 기능들이 내장되어 있죠.
00:22:13참고로 자바스크립트 쪽에도 Adonis.js라는 비슷한 프레임워크가 있는데, 제가 3주 전쯤 라이브 스트리밍에서 다뤘거든요. 이것도 풀스택 프레임워크로, 자바스크립트로 풀스택 애플리케이션을 만들 때 보통 필요한 모든 기능이 내장되어 있습니다.
00:22:33네, 그쪽도 아주 흥미롭죠.
00:22:35그게 이 질문의 두 번째 파트로 넘어가게 해주네요.
00:22:42React와 Vue, 그리고 무엇이 중요한지에 대해 이야기했는데요.
00:22:45물론, 채팅창에서 이미 혼란이 있었던 것처럼, 메타 프레임워크들도 존재하니까 혼란스러울 수 있습니다, 그렇죠?
00:22:52Next.js도 있고, TanStack Start도 있고, Remix도 있는데 Remix는 이제 변화해서 앞으로는 React 프레임워크가 아니게 될 겁니다. 하지만 과거에는 React 프레임워크였죠.
00:23:05React Router가 새로운 Remix가 되면서 더 혼란스럽게 됐습니다. 왜냐하면 React Router를 두 가지 다른 모드로 쓸 수 있기 때문이죠.
00:23:11Next.js의 대안인 프레임워크 모드, 혹은 데이터 모드에서는 대안이 아니고요.
00:23:18정말 혼란스럽습니다.
00:23:21결국 요점은 React, Angular, Vue는 프론트엔드 프레임워크라는 겁니다.
00:23:27브라우저에서 실행되죠.
00:23:29브라우저에서 실행되는 애플리케이션을 만들 때 사용합니다.
00:23:33고도로 상호작용하는 웹 애플리케이션을 만들 수 있게 해주지만, 당연히 거의 모든 웹사이트는 백엔드나 서버가 필요하죠.
00:23:40거기에는 두 가지 주요 선택지가 있습니다.
00:23:42몇 가지 선택지가 있지만, 큰 선택지는 두 가지라고 하죠.
00:23:46분리된 백엔드, 즉 REST API를 구축할 수 있습니다.
00:23:51이건 BUN이나 Node.js로 할 수 있고, Express.js나 제가 아주 좋아하는 HONO 같은 프레임워크와 결합해서 사용하는 경우가 많습니다.
00:24:02이들은 백엔드 구축을 위한 훌륭한 프레임워크입니다.
00:24:05하지만 다시 말하지만, 여기가 조금 복잡해지죠.
00:24:09그게 전부는 아닙니다.
00:24:10Express나 HONO로 HTML 페이지를 렌더링할 수도 있지만, 그 페이지들은 React 애플리케이션은 아닙니다.
00:24:18대신 표준 HTML 페이지들이죠. 여기서는 클라이언트 측 자바스크립트를 사용할 수 있고 React를 작동하게 할 수도 있지만, 조금 더 어렵습니다.
00:24:26그러니 Express나 HONO 등으로 REST API를 구축하는 건 아주 쉽습니다.
00:24:32하지만 클라이언트 측을 얼마나 상호작용하게 만들지에 따라, 풀스택 앱 구축은 약간 까다로울 수 있죠.
00:24:38그때 바로 Next.js가 등장합니다.
00:24:41예를 들어, Next.js는 서버 측과 상호작용하는 클라이언트 측(React 애플리케이션)을 가진 풀스택 애플리케이션을 더 쉽게 구축하게 해줍니다.
00:24:53TanStack Start도 마찬가지고, Angular용 Analog-js나 Vue용 Next도 마찬가지입니다.
00:25:02아이디어는 언제나 같습니다.
00:25:04서버 측과 클라이언트 측을 모두 가진 풀스택 애플리케이션을 구축하는데, 여러분이 익숙할 일반적인 Vue 앱이나 React 앱처럼 상호작용이 많은 클라이언트 측을 만드는 게 훨씬 쉬워집니다.
00:25:16이게 바로 이런 프레임워크들이 해결하는 문제이며, 인기가 많은 이유입니다. 왜냐하면 보통은 둘 다 원하니까요.
00:25:22사용자 데이터를 데이터베이스에 저장해야 해서 서버 측 코드가 필요한 경우, 그 데이터베이스는 브라우저 내부에 있을 수 없고 중앙 서버에 있어야 합니다.
00:25:30하지만 동시에, 상호작용하는 클라이언트 측 애플리케이션을 만들 수 있기를 원하죠.
00:25:35이 모든 복잡함이 거기서 기인하는 겁니다.
00:25:37또한 이 분야가 2010년에서 2020년 사이, 그 정도 기간 동안 급격하게 발전했다는 사실에서도 비롯되죠.
00:25:472009년의 인터넷은 웹사이트를 구축하는 방식에 있어서 지금과는 완전히 달랐습니다.
00:25:54저는 그때부터 지금까지 다 지켜봤는데요. 2015년, 2020년, 그리고 오늘날의 모습과 비교하면 엄청난 변화죠.
00:26:02네, 그래서 그렇습니다.
00:26:04다시 한번, 무엇을 선택해야 할까요?
00:26:06여러분 마음입니다.
00:26:06AI는 분명히 Next.js를 가장 선호합니다.
00:26:09하지만 앞서 말했듯이, 그 모든 것을 다 작동하게 만들 수는 있습니다.
00:26:11예를 들어, 몇 달 전에 사이드 프로젝트로 빌드했던 제 웹사이트는 전부 TanStack Start로 만들었습니다.
00:26:18그걸 아주 좋아하거든요.
00:26:22그리고 당연히 AI와 함께 작동하도록 만들 수도 있고요.
00:26:26다시 말하지만, 직접 알아야 한다는 사실은 변하지 않습니다.
00:26:31오케이, 두서없는 이야기였네요.
00:26:33다시 채팅창으로 돌아갈게요.
00:26:38여긴 뭐가 있죠?
00:26:42FastAPI에 대한 제 의견이요.
00:26:45글쎄요, FastAPI가 아주 인기 많고 빠르다는 건 압니다. 하지만 제 관점에서 하나의 큰 단점이 있는데, 그건 파이썬 프레임워크라는 점입니다.
00:26:57저는 파이썬 개발자가 아니거든요.
00:26:59언급했듯이 파이썬은 알지만, 메인 언어는 아니거든요. 그래서 FastAPI를 실제로 사용해 본 적이 없습니다.
00:27:09조금 건드려 보긴 했지만, 확실한 의견은 없네요.
00:27:13하지만 아주 인기 있는 프레임워크인 만큼 훌륭할 거라 확신합니다. 인기가 있는 데는 분명히 좋은 이유가 있을 테니까요.
00:27:20그러니 아주 좋은 선택이 될 거라고 생각합니다.
00:27:25방금 Udemy에서 Codex 강의를 구매하셨다고요.
00:27:27멋지네요.
00:27:28강의에서 많은 걸 얻어가셨으면 좋겠어요.
00:27:30구매해 주셔서 정말 감사합니다.
00:27:33Udemy는 어떻게 되는 거냐고요?
00:27:34이제 Udemy에 강의 안 올릴 거냐고요?
00:27:36아니요, Udemy에 강의 올리는 걸 멈추지는 않을 겁니다.
00:27:40Udemy는 이미 작년에 Coursera에 인수되었고, 거래가 최종 마무리된 지 두 달 혹은 한 달 정도 된 것 같습니다.
00:27:48미래에 상황이 어떻게 바뀔지는 불확실하지만, 지금은 늘 그렇듯 똑같이 진행되고 저도 똑같이 할 겁니다.
00:27:54하지만 모든 강의가 Udemy에만 있는 건 아닙니다.
00:27:57제 자체 플랫폼인 Academy Pro에만 있는 독점 강의들도 있고, 두 플랫폼에 다 올라가는 강의의 경우, 새로운 강의들은 제 자체 플랫폼에서 조금 더 방대한 내용을 다루는 보너스가 있습니다.
00:28:08어쨌든, Udemy에 올리는 걸 아예 중단하는 건 아닙니다.
00:28:13Udemy를 떠나는 게 아니에요.
00:28:14그런 계획은 없습니다.
00:28:19ASP.net은 어떻게 생각하냐고요?
00:28:22그것도 제가 전문가는 아니라서 해드릴 수 있는 얘기가 별로 없네요. 죄송합니다.
00:28:26Udemy 강의가 컴퓨터 과학 학위보다 더 도움이 되셨다고요?
00:28:29중급에서 시니어 레벨로 가기 위한 조언이나 강의 추천 좀 해달라고요?
00:28:33정말 감사합니다.
00:28:34일단 그렇게 말씀해 주시니 정말 놀랍네요.
00:28:36제게 큰 힘이 됩니다.
00:28:37시니어 레벨로 올라가는 것에 대한, 지루하지만 정답은 어쩔 수 없이 더 복잡한 프로젝트를 많이 만들어 보는 것입니다.
00:28:46적어도 저에게는 그게 정답이었습니다.
00:28:48리소스나 튜토리얼, 강의는 그런 레벨에서는 더 드물거든요.
00:28:53결국 직접 무언가를 만들며 경험을 쌓는 게 중요합니다.
00:28:56지루하고 짜증 나는 대답일지 모르겠지만, 죄송합니다.
00:29:05그럼요.
00:29:08참, 제가 여기서 분석한 내용 중에 놓친 부분이나 꼭 필요한 내용이 있다면 채팅창에 남겨주세요.
00:29:15상호작용하는 세션으로 만들고 싶고, 제 의견뿐만 아니라 다양한 관점을 다뤄보고 싶으니까요.
00:29:26왜 구독자 10만 명이 안 되냐고요?
00:29:28사실 저는 두 번째 유튜브 채널이 있는데, 그 채널은 튜토리얼 위주로 운영해왔고 지금도 그렇습니다.
00:29:35Academy 채널은 구독자가 90만 명이에요.
00:29:40이 채널은 제가 잡담하고 의견을 공유하는 채널이죠.
00:29:43그래도 잘 성장하고 있습니다.
00:29:44언젠가 10만 명을 달성할 수 있길 바랍니다.
00:29:51지금까지가 프레임워크에 대한 제 생각과 제가 그것들을 선택하는 방법, 그리고 선택이 여전히 중요한지에 대한 제 견해였습니다.
00:30:00하지만 어떤 종류든 웹 애플리케이션을 만든다면, 설령 그것이 API일지라도 말이죠.
00:30:06아, 그것도 중요하죠.
00:30:10특히 요즘 같은 AI 에이전트 시대에는 풀스택 웹 애플리케이션이 여전히 중요하고 앞으로도 계속 중요할 것이라고 생각합니다.
00:30:235년이나 10년 뒤에는 우리가 채팅으로만 서비스와 상호작용하게 될 거라는 생각은 하지 않습니다.
00:30:33하지만 AI 에이전트가 사용하기 쉬운 서비스를 구축하는 것의 중요성이 엄청나게 커지고 있다는 것은 분명히 느낍니다.
00:30:43단순히 유행이라서일 수도 있겠지만, 저 역시 ChatGPT나 로컬에서 실행되는 에이전트를 통해 정보를 검색하고 있으니 거기에는 분명한 가치가 있다고 봅니다.
00:30:55그러니 무엇을 만들든 간에 사람을 위한 웹 프론트엔드가 있는 풀스택 애플리케이션이 될 수도 있고, 단순히 API일 수도 있겠죠.
00:31:10에이전트가 소비할 수 있는 REST API 같은 서비스를 구축하는 것도 전혀 이상하지 않죠. 어쩌면 MCP 서버나 CLI를 앞에 둘 수도 있고요.
00:31:21CLI 역시 클라이언트입니다. 비록 시각적이지 않고 예쁜 웹사이트는 아니지만, 서비스와 상호작용할 수 있는 클라이언트죠.
00:31:29그리고 그것은 서비스의 내용에 따라 100% 구축할 수 있는 것입니다.
00:31:34만약 여러분의 주 타겟이 어떤 문제를 해결하기 위해 AI 에이전트를 사용하는 사람들이라면, API만 구축하거나 거기에 CLI를 추가하는 정도로도 충분할 수 있습니다.
00:31:45그러니 참고할 가치가 있습니다.
00:31:48그리고 백엔드와 관련해서 이미 언급했지만 HONO, Express.js, Elysia.js 등 훌륭한 프레임워크는 정말 많습니다.
00:32:00오해하지 마세요.
00:32:01Fastify도 있고요.
00:32:03종류가 너무나도 많습니다.
00:32:05여전히 유지보수 되고 있냐고요?
00:32:06네, 물론입니다.
00:32:08프레임워크는 정말 많고, 어쩌면 프레임워크 자체가 필요 없을지도 모릅니다.
00:32:13특히 Bun이나 현대적인 Node.js를 사용한다면 내장된 기능이 많기 때문에 그 점도 주목할 만하다고 봅니다.
00:32:22저는 HONO를 아주 좋아하지만, 프레임워크 없이 무언가를 빌드하는 것도 가능하죠.
00:32:30좋은 프레임워크이긴 합니다.
00:32:32라우팅이나 미들웨어 같은 편리한 기능들을 제공하니까요.
00:32:38그건 가치가 있죠.
00:32:39여러분의 삶을 더 쉽게 만들어 줄 수 있으니까요, 그렇죠?
00:32:42하지만 Bun도 당연히 HTTP 요청 처리가 내장되어 있고 Node.js도 마찬가지라는 점을 기억하세요.
00:32:52이런 런타임들이 할 수 있는 핵심 기능 중 하나니까요.
00:32:57Bun에는 라우트 설정 등을 위한 기본 기능이 내장되어 있습니다.
00:33:02그러니 Bun이나 Node.js, 아니면 여러분이 사용하는 도구만으로도 API를 구축할 수 있을 겁니다.
00:33:11잘 모르겠지만요.
00:33:12익숙하다고 해서 꼭 프레임워크나 라이브러리를 써야 하는 건 아닙니다.
00:33:18AI 시대에는 이런 방식이 변하고 있다고 생각합니다. 과거에는 보일러플레이트 코드가 많아지는 걸 막으려 라이브러리를 썼다면 말이죠.
00:33:29그런데 그거 아세요?
00:33:30요즘은 보일러플레이트 코드가 사실상 무료나 다름없습니다.
00:33:32물론 완전히 무료는 아니죠.
00:33:33토큰 비용이 들긴 합니다.
00:33:35하지만 그런 코드를 직접 생성하거나 AI에게 미들웨어를 연결하는 작은 도우미 라이브러리를 만들게 하는 게 훨씬 쉬워졌습니다.
00:33:42그러니 그런 원시적인 도구들을 사용하는 것도 고려해 볼 만하다는 거죠.
00:33:50또한 CLI 부분에 대해 언급했듯이, 서버를 구축할 때만 Bun이나 Node.js, Deno를 쓸 수 있는 건 아닙니다.
00:33:59그게 주요 사용 사례이긴 하지만, 유일한 건 아니니까요.
00:34:02이런 도구들로 CLI 도구를 만들 수도 있습니다.
00:34:06Bun을 예로 들자면요.
00:34:08이건 정말 Bun 광고가 아닙니다.
00:34:10단지 제가 좋아하는 런타임일 뿐이죠.
00:34:13Bun에는 단일 파일 실행 파일 기능이 있습니다. Bun 기능들을 사용하는 TypeScript 애플리케이션을 빌드하면, 다른 사람들이 Bun을 설치하지 않아도 실행할 수 있는 도구로 만들어서 배포할 수 있죠.
00:34:31그래서 CLI를 만들 때 아주 좋습니다.
00:34:34고려해 볼 만한 가치가 있죠.
00:34:36네, 이제 이쯤에서 마무리하고 싶네요.
00:34:39지금 제가 이것에 대해 생각하는 방식은 이렇습니다.
00:34:43하지만 웹 애플리케이션을 계획할 때는 단순히 어떤 프레임워크를 사용할지 결정하는 것보다 조금 더 많은 것이 필요하죠.
00:34:51혹은 어떤 프레임워크를 알고 편하게 생각하는지보다요.
00:34:54다른 문제들도 다 고려해야 합니다.
00:34:56예를 들어, 호스팅과 배포 문제도 중요하죠. 왜냐하면 예를 들어 Vercel을 호스트로 선택한다고 했을 때,
00:35:10네.
00:35:12네.
00:35:12물론 Netlify 같은 다른 서비스들도 있죠.
00:35:28저는 제 전문 분야인 자바스크립트 생태계 위주로 말씀드리는 거고요.
00:35:34이 서비스들은 호스팅을 정말 간편하게 만들어줍니다.
00:35:38앞서 언급했듯이 다른 서비스들도 많고요.
00:35:41하지만 한 가지 단점이 있습니다.
00:35:43이런 편리함은 설정 자유도가 낮다는 대가를 치러야 하며, 제공되는 기능에 어느 정도 제한을 받게 됩니다.
00:35:52예를 들어 데이터베이스의 경우, 'Vercel database'를 검색하면 Vercel 스토리지 페이지가 나옵니다.
00:36:02현재로서는 이곳에서 딱히 훌륭한 데이터베이스 솔루션을 찾기 어렵다는 걸 알게 되죠.
00:36:11물론 별도의 데이터베이스 서비스를 연결하는 것도 100% 가능합니다.
00:36:16하지만 만약 애플리케이션을 만들면서 SQLite를 사용하고 싶다면, 다시 강조하지만 SQLite는 정말 대단한 데이터베이스거든요.
00:36:24아무튼 그걸 선택했다고 칩시다.
00:36:25SQLite를 쓰고 싶은 거죠.
00:36:27글쎄요, Vercel과 SQLite는 잘 맞지 않습니다.
00:36:32뭐, 그들도 다른 스토리지 솔루션을 제공하긴 하지만요.
00:36:44Vercel에서는 사용할 수 없죠.
00:36:46제가 찾던 게 바로 그거였습니다.
00:36:47물론 꼭 문제가 되는 건 아닙니다.
00:36:49다른 대안을 찾으면 되니까요.
00:36:51PlanetScale 같은 것을 사용할 수 있죠.
00:36:55본질적으로 호스팅된 Postgres를 제공하는 서비스입니다.
00:37:02말하자면 '서비스로서의 데이터베이스(DBaaS)'인 셈이죠.
00:37:05AWS Aurora나 RDS, 혹은 Azure나 Google Cloud의 동등한 서비스를 사용할 수도 있고요.
00:37:15요즘 꽤 인기 있는 Convex를 사용할 수도 있겠네요.
00:37:18이런 데이터베이스 서비스를 이용해 애플리케이션을 구축할 수 있습니다.
00:37:22원하는 어떤 프레임워크로든 개발할 수 있죠.
00:37:25Next.js로 만들 수도 있고, 아니면 그냥 REST API를 구축할 수도 있고요.
00:37:30Convex나 PlanetScale 같은 데이터베이스를 사용하여 자신의 서비스에 연결하면 됩니다.
00:37:37충분히 가능하죠.
00:37:38하지만 물론 비용이 추가로 발생합니다.
00:37:41이런 서비스에 돈을 내야 하니까요.
00:37:43복잡성도 조금 더 늘어나겠죠.
00:37:46외부 의존성이 하나 더 생기는 겁니다.
00:37:47최악의 경우, 해당 서비스가 종료되면 데이터를 마이그레이션해야 할 수도 있고요.
00:37:53가격이 오르면 또 문제가 될 수 있죠.
00:37:58서비스가 다운되어도 문제고요.
00:38:00하지만 물론 편리함도 얻을 수 있습니다.
00:38:02자동 백업 기능 같은 거요.
00:38:03항상 트레이드오프가 존재합니다.
00:38:05사용해도 괜찮습니다.
00:38:07하지만 개인적으로는 많은 애플리케이션에서 SQLite 같은 것을 사용하는 게 아주 훌륭한 선택이라고 생각합니다.
00:38:14아니면 러스트(Rust)로 작성된 현대적인 버전의 SQLite인 Turso를 사용할 수도 있죠.
00:38:21그래도 일반 SQLite도 꽤 훌륭합니다.
00:38:23러스트로 작성되었다고 해서 무조건 더 나은 건 아니에요.
00:38:26그저 SQLite의 또 다른 멋진 재구현판일 뿐이죠.
00:38:33네, 여기엔 정말 많은 복잡성이 얽혀 있습니다.
00:38:37그래도 저는 개인적으로 SQLite를 정말 좋아합니다.
00:38:40웹사이트가 딱히 화려하진 않지만요.
00:38:43정말 대단한 데이터베이스입니다.
00:38:45SQLite의 가장 큰 장점은 시스템에서 그냥 하나의 파일이라는 점이에요.
00:38:50개발할 때 정말 좋죠, 내 컴퓨터에 그냥 파일 하나니까요.
00:38:54따로 실행해야 할 서비스도 없고요.
00:38:56연결하거나 돈을 낼 필요도 없죠.
00:38:57그저 로컬 파일이니까요.
00:38:59배포할 때도 마찬가지입니다. VPS에 파일 하나만 있으면 되거든요.
00:39:03그것도 제가 나중에 다시 언급할 배포 옵션 중 하나죠.
00:39:05VPS에 파일을 그냥 두는 거니까요.
00:39:08백업도 그냥 복사하면 되니까 정말 간단합니다.
00:39:11물론 올바르게 복사해야겠지만요.
00:39:13그래도 백업하기는 정말 쉬워요.
00:39:16물론 백업 책임은 본인에게 있습니다.
00:39:18만약 초당, 아니 심지어 분당 수백만 명의 사용자가 접속한다면, 뭐... 한계에 부딪힐 수도 있겠죠.
00:39:27그래도 꽤 멀리 갈 수 있습니다.
00:39:29정말 꽤 오랫동안 버틸 수 있어요.
00:39:31처음 시작할 때는 그냥 간단한 솔루션으로 가세요.
00:39:36운이 좋아서 수십만 명의 사용자를 확보하고, 부하가 문제가 된다고 느껴진다면, 그건 아주 행복한 고민을 하게 된 거죠.
00:39:48그때 스케일 업을 하면 됩니다.
00:39:50더 나은 데이터베이스 솔루션으로 마이그레이션하면 돼요.
00:39:53물론 좀 노력이 필요하겠죠.
00:39:54하지만 처음부터 최종적인 솔루션을 구축하느라 너무 복잡하고 비용을 많이 쓰는 것보다는 그 편이 나을 겁니다.
00:40:03그래서 제가 권하는 건, 많은 경우 SQLite를 쓰거나, 아니면 VPS의 Docker 컨테이너에서 돌아가는 Postgres나 MySQL을 사용하는 것입니다.
00:40:12데이터베이스를 직접 운영한다는 건 백업 같은 책임이 뒤따른다는 뜻이죠.
00:40:19하지만 그만큼 엄청난 자유도와 유연성을 얻게 됩니다.
00:40:23개발 자체도 더 쉬워질 수 있고요.
00:40:26그러니까 여기에도 트레이드오프가 있는 거죠.
00:40:28네, 또 말이 너무 길어졌네요.
00:40:30죄송합니다.
00:40:31다시 채팅으로 돌아가 볼까요.
00:40:33저도 TanStack Start를 정말 많이 사용하고 있습니다.
00:40:38TanStack Start 프로젝트를 AI 개발용으로 어떻게 준비할까요?
00:40:41음, TanStack Start나 전반적으로 AI가 잘 모르는 프레임워크를 다룰 때, 저는 프로젝트 안에서 AI에게 문서를 직접 가리키게 하는 걸 좋아합니다.
00:40:54그러니까 제가 사용하는 AI 에이전트, 예를 들면 Pi나 Codex에게 '지금 TanStack Start를 사용 중이야'라고 말하는 거죠.
00:40:58'여기 문서 링크가 있어' 하고 메인 페이지나 특정 페이지를 전달합니다.
00:41:03그리고 '이 문서를 분석해줘'라고 하는 거죠.
00:41:06'정보를 수집해줬으면 해, 특히 ABC에 관해서 말이야'.
00:41:09이건 제가 중요하다고 아는 개념들에 대한 것입니다.
00:41:13예를 들어 TanStack Start의 경우, 서버 함수(Server Functions)를 제대로 사용하는 게 중요하거든요.
00:41:18여기 코드를 잘못 작성해서 문제가 발생한 적이 몇 번 있었거든요.
00:41:24그래서 AI에게 그 정보를 가리키고 관련 내용을 다 수집한 뒤에 저를 위한 스킬을 작성해 달라고 요청합니다.
00:41:30물론 공식 스킬들도 있다는 거 알아요.
00:41:32TanStack Start는 패키지와 함께 스킬과 문서를 공개한다고 생각하는데, 그건 정말 좋죠.
00:41:38AI가 설치된 패키지에서 그걸 찾을 수도 있고요.
00:41:41하지만 저는 AI가 직접 자신만의 스킬을 구축하게 만듭니다.
00:41:43그럼 그 스킬을 다른 프로젝트에 복사해두고 때때로 업데이트할 수 있거든요.
00:41:47예를 들어 AI가 실수를 하면, 스킬을 업데이트하라고 지시해서 그 지식이 반영되게끔 만들 수도 있고요.
00:41:55그래서 제가 코드를 직접 리뷰하는 겁니다. 무엇을 다루는지 이해해야 AI를 올바른 방향으로 이끌 수 있으니까요.
00:42:03그게 바로 제 접근 방식입니다.
00:42:07누구나 읽어야 할 책 top 3라...
00:42:09코딩 서적에 관해서라면, 물론 제가 쓴 책이 있죠. 만약 더 잘하고 싶다면... 아, 이것도 수정해야겠네요.
00:42:24React 실력을 키우고 싶다면 제 책 'React Key Concepts'를 강력히 추천합니다.
00:42:31농담은 제쳐두고, 'Designing Data-Intensive Applications' 그 책은 꼭 읽어보세요.
00:42:36최근에 2판이 나왔는데 저도 이미 샀습니다.
00:42:39그게 1판이었지만, 이제 2판을 구할 수 있죠.
00:42:44그 책을 추천하고 싶네요.
00:42:48자, 또 뭐가 있을까.
00:42:51'A Philosophy of Software Design'의 철학도 꽤 좋아합니다.
00:42:55정확한 제목은 기억이 안 나는데.
00:42:58이런 소프트웨어 아키텍처 책들 중 하나겠죠.
00:43:00'The Pragmatic Engineer'도 제가 아주 좋아했던 책입니다.
00:43:04어쨌든 저는 'Designing Data-Intensive Applications'와 'A Philosophy of Software Design'을 꼭 읽어보라고 하고 싶네요.
00:43:11정말 괜찮은 책들이라고 생각해요.
00:43:17AI가 제 실력이나 우리 실력에 나쁜 영향을 주고 있다고 생각하나요?
00:43:23AI가 실력에 영향을 미치는 건 분명합니다. 제 실력에도 영향을 주고 있고요.
00:43:27저는 AI가 주는 걸 무작정 수용하는 함정에 빠지지 않으려고 스스로 도전하며 실력을 유지하려 합니다. 직접 코드를 짜보고, 문서를 직접 읽으면서 제대로 이해하려고 노력하죠.
00:43:42AI한테만 다 맡기고 결과를 덥석 받기보다는요. 하지만 확실히 요구되는 역량 자체가 변하고 있습니다.
00:43:49이제는 올바른 구성 요소를 선택하고 코드를 이해하며 코드 아키텍처를 설계하는 능력이 훨씬 중요해지고 있어요.
00:43:57그게 점점 더 중요해질 것이고, 관련 강의들도 만들 예정입니다.
00:44:01네, Udemy에도 올라갈 거예요.
00:44:04분명 변화가 일어나고 있습니다.
00:44:07확실히요.
00:44:12와, 세상에.
00:44:13정말 대단한 상호작용이네요.
00:44:14놀라워요.
00:44:17정말 좋은 댓글 남겨주시는 여러분 모두에게 진심으로 감사합니다.
00:44:21저에게 정말 큰 의미가 있어요.
00:44:22너무너무 감사합니다.
00:44:23정말 놀라워요.
00:44:25Headless CMS에 대해서도,
00:44:26네, 나중에 자세히 다룰게요.
00:44:28네.
00:44:31네, 보일러플레이트 코드는 무료죠.
00:44:34하지만 보일러플레이트 코드가 고장 났을 때 수천 줄을 디버깅하는 건 공짜가 아닙니다.
00:44:37물론이죠.
00:44:37그래서 제가 이해하는 게 중요하다고 하는 겁니다.
00:44:41생성된 코드를 무작정 받아들이지 말고, 보일러플레이트 코드조차도 잘 살펴봐야 해요.
00:44:50AI가 보일러플레이트 코드를 짜준다고 해서 신경 쓰지 않아도 된다는 뜻이 아니에요.
00:44:56저는 모든 코드를 신경 씁니다.
00:44:58다만 예전에는 시도하기 귀찮거나 겁났던 특정 문제들을 해결하기가 좀 더 수월해졌을 뿐이죠.
00:45:06물론 코드를 읽고 분석하는 건 여전히 직접 해야 할 일이고, 절대 공짜가 아닙니다.
00:45:12시간이 걸리지만, 보일러플레이트 코드 정도는 꽤 빠르게 훑어볼 수 있을 테니 그런 면에서 AI가 도움을 줄 수 있죠.
00:45:26라이브러리나 프레임워크 선택은 상황에 따라 다릅니다. 어떤 경우에는 도구가 너무 무거울 때도 있거든요.
00:45:32그럴 땐 직접 만드는 걸 고려해 보는 것도 좋은 아이디어입니다.
00:45:36네, 확실히 그렇습니다.
00:45:37음, 특정 기능들의 경우에도 그렇고요.
00:45:43예를 들어 인증(Authentication) 같은 거요.
00:45:45나중에 자세히 돌아볼 겁니다.
00:45:46흔한 통념과는 달리 인증은 직접 구현하기가 그렇게 어렵지 않습니다. 다만 범위에 따라 다르죠.
00:45:57간단한 이메일/비밀번호 로그인 구현 정도는 충분히 가능합니다.
00:46:02제대로 만들려면 물론 공부를 좀 해야 하지만, 충분히 해볼 만해요.
00:46:06하지만 OpenID Connect를 추가하거나, OAuth를 파고들고, 여러 소셜 로그인 기능을 붙이고 싶다면...
00:46:15Discord, Google, Apple 로그인을 전부 지원하려면 라이브러리를 사용하는 게 좋습니다.
00:46:23AI를 활용하더라도 그걸 다 제대로 구현하려면 시간이 걸릴 테니까요.
00:46:28실수해서 보안 문제를 일으키고 싶지는 않으실 테니까요.
00:46:32물론 라이브러리라고 보안 이슈가 없다는 보장은 없지만요.
00:46:36하지만 적어도 그 문제를 당신보다 훨씬 더 많이 고민하고 시간을 쏟은 전문가들에게 해당 작업을 맡기는 거니까요.
00:46:43분명 그런 트레이드오프가 존재합니다.
00:46:51강의에서 배운 지식을 활용해 실제 프로젝트를 빌드하려면 어떻게 해야 할까요?
00:46:57지금은 완전히 막혀서 어디서부터 시작해야 할지 모르겠어요.
00:47:00저는 그냥 복제품(Clones)을 만들어보는 걸 좋아합니다. 아마존, 트위터 같은 간단한 클론을 만들면서 시작해 보세요.
00:47:11그리고 AI라는 파트너도 있잖아요.
00:47:12일부분을 만들어달라고 할 수도 있고, 생성된 코드를 이해하거나 다른 대안을 논의할 수도 있습니다.
00:47:24문제에 직면했을 때 AI와 토론해 보세요.
00:47:28AI가 제안하는 게 항상 최선의 해결책은 아니더라도, 적어도 시작점은 잡아줄 수 있을 거예요.
00:47:33그건 충분히 해볼 만한 접근입니다.
00:47:38비디오가 끊기기 시작했네요.
00:47:40영상이 렉 걸리네요.
00:47:45알겠습니다.
00:47:50이 문제가 지속되나 봅시다.
00:47:56죄송합니다.
00:47:58이제 영상이 좀 나아지길 바랍니다.
00:47:59전에도 이런 적이 있었는데.
00:48:01인코딩 설정을 바꿨어야 했나?
00:48:03CPU 자원을 좀 확보하기 위해 두 번째 모니터에서 돌아가는 몇 가지 프로세스를 끄겠습니다.
00:48:13어디 봅시다.
00:48:14음성 싱크가 안 맞네요.
00:48:17네.
00:48:24어디 보자.
00:48:32잠시만요.
00:48:33트위치에서는 잘 되는데.
00:48:45유튜브가 끊기네요.
00:48:46흠.
00:48:49유튜브 쪽 문제일 수도 있겠네요.
00:48:55사실 전 라이브 스트리밍 전문가는 아니라서요.
00:49:06어디 봅시다.
00:49:10설정을 조금 만져봐야겠네요.
00:49:13모르겠네요.
00:49:17이제 좀 어떤가요.
00:49:18지금은 좀 나은가요?
00:49:18나아지길 바라야죠.
00:49:21보죠 뭐.
00:49:22여기에 너무 시간을 뺏기고 싶진 않아요.
00:49:24네.
00:49:26네.
00:49:27계속 진행하겠습니다.
00:49:30비디오와 오디오 간의 딜레이가 심하지 않길 바랄 뿐이에요.
00:49:35아직 좀 딜레이가 있는 것 같긴 한데.
00:49:38왜 갑자기 이런 문제가 생겼는지 모르겠네요.
00:49:48네.
00:49:49어쨌든 이 문제가 곧 해결되길 바랍니다.
00:49:58네.
00:49:58좋습니다.
00:50:00네.
00:50:01자, 여러분께 질문 하나 드릴게요.
00:50:03더 나은 AI 코딩 설정이 뭘까요? Pi 코딩 에이전트, Codex 구독, 아니면 Cursor Pro 플랜?
00:50:08전 현재 Pi와 Codex를 같이 쓰고 있지만, 다른 옵션들도 시험해 보려고 자주 바꿔보고 있어요.
00:50:13하지만 Pi와 Codex 조합이 저한테는 꽤 잘 맞네요.
00:50:15네.
00:50:16뭐, 그래요.
00:50:17그냥 제 현재 스택이나 지금 사용 중인 방식이라고 말씀드리는 거예요.
00:50:29네.
00:50:29방금 말씀드렸듯이 오디오 호스팅과 배포도 중요한 고려 사항이에요.
00:50:42Vercel 같은 호스팅 서비스들이 있지만, 이미 언급했듯이 장단점이 존재합니다.
00:50:52그 장단점이 다른 선택들에도 영향을 주죠.
00:50:56예를 들어, 데이터베이스 같은 거요.
00:51:00SQLite를 언급했는데, 제 생각엔 꽤 괜찮은 선택이에요.
00:51:03하지만 그것도 단점이 있죠. 직접 관리할 책임이 더 크지만, 그만큼 유연하고 설정도 더 쉽고 저렴해요.
00:51:10항상 선택의 문제죠.
00:51:11물론 이미 자리 잡은 대형 프로젝트와는 상황이 다르겠지만요.
00:51:16하지만 새로운 것을 만든다면, 처음엔 단순하게 시작하는 게 큰 장점이 있다고 믿어요.
00:51:22그래서, 그게 한 가지 포인트예요.
00:51:27물론 Vercel 같은 서비스에 대한 대안은 아주 많죠.
00:51:33예를 들어 Cloudflare가 있어요.
00:51:35전 개인적으로 Cloudflare를 정말 좋아합니다.
00:51:38마치 매일 새로운 제품을 내놓는 것처럼 느껴질 정도니까요.
00:51:44그들의 메인 호스팅 제품은 'Workers'예요.
00:51:50이건 서버를 하나 빌려서 이것저것 설치하고 돌아가는 그런 일반적인 서버랑은 좀 다릅니다.
00:51:56들어오는 요청을 처리할 코드를 올려두는 방식이죠.
00:52:04그래서 요청이 들어오면 워커가 실행되어 처리하고, 할 일을 마치면 바로 종료됩니다.
00:52:10그러니 당연히 데이터베이스를 둘 곳은 없겠죠?
00:52:13아무것도 없으니까요.
00:52:15Vercel과 달리 그들에겐 'D1'이라는 데이터베이스 제품이 있습니다.
00:52:18하지만 그것도 결국 Cloudflare에서 제공하는 관리형 호스팅 데이터베이스죠.
00:52:23물론 다른 데이터베이스 서비스를 연결할 수도 있고요.
00:52:27전 이 Workers 모델이 시작하기에 정말 저렴해서 마음에 들어요.
00:52:33코드가 실행될 때만 비용을 지불하거든요.
00:52:36그마저도 정말 저렴하고요.
00:52:37아주 넉넉한 무료 티어도 있습니다.
00:52:39그래서 다시 말하지만, 이제 막 시작하는 단계고 사용자가 아직 없다면,
00:52:44아주 저렴하게 시작할 수 있죠. 하지만 Cloudflare 선택의 단점은 'Cloudflare 전용'으로 구축하게 된다는 거예요.
00:52:52그들의 Workers 아키텍처에 맞춰 빌드하는 거니까요.
00:52:55그 워커에서는 Bun도 사용할 수 없어요.
00:52:58자체 자바스크립트 런타임인데, Node.js 호환성은 높지만, 또 다른 트레이드오프가 존재하는 거죠.
00:53:04사용할 수 있는 기능의 폭이 제한될 수도 있고요.
00:53:07그런 선택을 하면 모든 라이브러리를 다 쓰지 못할 수도 있습니다.
00:53:11그러니 어디에 애플리케이션을 호스팅할지, 어떻게 배포할지 결정하는 게 중요해요.
00:53:17꽤 이른 시기에 결정해야 합니다. 그래야 나머지 기술 스택 결정에도 영향을 주니까요.
00:53:25물론, VPS에 호스팅할 수도 있겠죠.
00:53:28AWS EC2 같은 걸 써볼 수 있죠. 결국 클라우드에 있는 서버 하나를 빌리는 거예요.
00:53:34아니면 Hetzner를 쓸 수도 있는데, AWS보다 저렴해요.
00:53:39그렇게 할 수도 있죠.
00:53:42최근에 가격을 올리긴 했지만, 여전히 합리적인 가격으로 시작할 수 있게 해줍니다.
00:53:50그 장점에 대해서는 제가 만든 코스도 있으니 관심 있으시면 확인해 보세요.
00:53:54VPS 설정에 관한 강의가 있습니다.
00:53:59여기 있네요, 'VPS Essentials'.
00:54:01물론 VPS의 장점은 완벽한 통제권이죠.
00:54:05마치 내 컴퓨터랑 똑같아요.
00:54:07원하는 소프트웨어를 뭐든 설치할 수 있죠.
00:54:09데이터베이스도 직접 올릴 수 있고요. SQLite든 Docker 컨테이너 안의 Postgres든 상관없죠.
00:54:16하지만 그만큼 모든 걸 직접 다뤄야 한다는 뜻이기도 해요.
00:54:19VPS 설정도 직접 해야 하고, 보안도 챙겨야 하니까요.
00:54:22Cloudflare나 Vercel에서는 할 필요 없던 Docker라이징 같은 과정이 필요할 수도 있습니다.
00:54:29갑자기 새로 배워야 할 것들과 익숙해져야 할 것들이 늘어나는 거죠.
00:54:34그게 또 학습 곡선인 거고요.
00:54:36결국 다 트레이드오프 문제지만, 전 통제권이 있는 게 좋아요.
00:54:40그래서 대부분 프로젝트는 아주 저렴한 Cloudflare를 쓰거나, 아니면 VPS를 택하죠. 하지만 Cloudflare는 제한적이라는 단점이 있죠.
00:54:49그들의 런타임을 써야 하니까요. 그게 아니면 VPS로 가는 거고요.
00:54:52물론 Vercel이나 Netlify를 써야 하는 아주 좋은 이유들도 있습니다.
00:54:57하지만 이런 결정은 초반에 내리는 게 매우 중요해요. 성급하게 결정하지 말고 시간을 들여야 합니다.
00:55:02AI랑 논의해 볼 수도 있고, 문서를 뒤지거나 관련 글들을 읽으면서 어떤 트레이드오프가 있는지 스스로 의견을 만들어 보세요.
00:55:11도움이 된다면 이런 부분에 대해 더 자세한 영상을 만들 수도 있겠네요.
00:55:16아무튼, 제 생각은 그렇습니다.
00:55:24로컬에서 쓸 수 있는 오픈 소스 모델이 있나요?
00:55:27네, 전 오픈 소스 모델을 좋아합니다.
00:55:28코딩 용도는 아니지만 Llama 모델 같은 것들을 좋아해요.
00:55:31코딩의 경우, 제 머신에서 현실적으로 돌릴 수 있는 모델들은 아직 충분히 좋지 않아요.
00:55:37하지만 문서 요약 같은 작업을 할 때는 Llama 모델을 아주 좋아합니다.
00:55:42채팅창에 질문하신 Pi는 Codex나 CloudCode 같은 코딩 에이전트예요.
00:55:48하지만 그들과 달리, 특정 서비스용으로만 만들어진 게 아니죠.
00:55:52CloudCode는 당연히 Anthropic for Cloud용이고요.
00:55:55Codex도 다른 모델들과 연동되긴 하지만, 기본적으로 OpenAI에서 GPT 모델들을 위해 만든 거죠.
00:56:03Pi는 기본 기능이 몇 개 없는 아주 미니멀한 에이전트지만, 확장이 매우 쉽고 스스로 확장할 수도 있어요.
00:56:12Pi에 관한 강의도 곧 나올 예정입니다.
00:56:15관심 있으시다면 문서도 정말 잘 되어 있으니 살펴보세요.
00:56:18전 빠르고 확장성이 좋아서 Pi를 좋아합니다.
00:56:22아주 편리한 방식으로 새로운 기능을 추가할 수 있는 패키지가 정말 많거든요.
00:56:27그래서, 네, 모든 에이전트가 유용하며 '최고'라고 할 만한 건 따로 없어요.
00:56:33하지만 저는 이런 이유로 Pi와 작업하는 걸 개인적으로 좋아합니다.
00:56:38제게 더 나은 이유는 핵심이 미니멀하고, 원하는 걸 뭐든 추가할 수 있기 때문이에요.
00:56:42전 그냥 이것저것 만지작거리는 걸 좋아하기도 하고요.
00:56:45그게 아마 제가 Pi를 좋아하는 이유일 겁니다.
00:56:53Docploy에 대한 제 생각은, 솔직히 좀 살펴봐야겠지만...
00:57:02한번 확인해 볼게요.
00:57:03아, 그거...
00:57:04뭔가...
00:57:05Coolify 같은 건가요?
00:57:07아직 써보진 않았지만 아주 좋은 서비스라고 생각합니다.
00:57:12하지만 VPS를 관리형 플랫폼처럼 만들면서 비용은 안 들이는 방식은 충분히 가치가 있다고 봅니다.
00:57:21최소한 Coolify가 추구하는 건 그런 거니까요.
00:57:23Docploy도 제가 틀리지 않았다면 비슷할 거예요.
00:57:25기본적으로 VPS에 설치하는 도구인데, 이걸 설치하면 신경 쓸 게 확실히 줄어들죠.
00:57:32그 도구가, 즉 VPS에서 실행되는 서비스가 많은 설정을 처리하고 배포를 쉽게 만들어 주니까요.
00:57:40VPS의 장점은 유지하면서 Vercel처럼 만들어 주는 느낌이죠.
00:57:50다시 말하지만 저는 직접 만지작거리는 걸 좋아해서 VPS를 직접 설정하는 쪽을 선호하긴 해요.
00:57:56하지만 이런 도구들이 가진 장점은 확실히 알겠네요.
00:57:59채팅창에서 언급해 주셔서 정말 좋네요. 배포를 결정할 때 꼭 고려해 볼 만한 선택지예요.
00:58:06VPS를 직접 구축하면서 Docploy나 Coolify 같은 솔루션을 사용해 배포를 쉽게 만들 수 있으니까요.
00:58:17네, PyAgent의 장점은 커스터마이징입니다.
00:58:19어떤 커스터마이징을 했냐고요?
00:58:22기획이나 구현, 코드 리뷰를 돕는 여러 확장 기능이나 스킬을 위에 직접 얹었습니다.
00:58:29저는 Py를 코딩 이외의 용도로도 씁니다. 회사 회계 처리나 금융 데이터 분석 같은 거요. PDF 문서를 읽을 수 있는 확장 기능도 추가했죠.
00:58:44네, 그게 제가 직접 구축한, 혹은 Py를 활용하는 방식이라 할 수 있겠네요.
00:58:52저는 SSL, 라우팅, 트래픽 분석에만 Cloudflare를 사용합니다.
00:58:56사실 Cloudflare가 처음 시작할 때는 CDN이랑 DDoS 공격 방어 기능이 핵심이었지만, 지금은 훨씬 더 커졌죠.
00:59:15하지만 여전히 그 기본 기능들도 정말 훌륭합니다.
00:59:17Cloudflare는 정말 멋진 회사이자 서비스예요.
00:59:20Cloudflare는 제 생각에 정말 대단한 기업 같아요.
00:59:25예를 들어, Cloudflare R2는 S3보다 저렴해서 데이터를 클라우드에 저장할 때 제 기본 솔루션이 됐어요.
00:59:34VPS 강의를 마쳤는데, 정말 훌륭한 강의였고 많이 배웠습니다.
00:59:37정말 감사합니다.
00:59:38VPS 강의가 도움이 되었다니 너무 기쁘네요.
00:59:41정말 감사드려요.
00:59:43Go와 Vue 강의도 감사합니다.
00:59:46네, 다시 한번 감사드려요.
00:59:47그리고 여러분 모두 감사해요.
00:59:48이렇게 멋진 댓글을 많이 남겨주시고.
00:59:49정말 너무나 감사합니다.
00:59:52제 콘텐츠가 도움이 된다니 너무 기쁩니다.
00:59:54말씀드렸듯이 Py, Bun, 시스템 설계 등 흥미로운 강의들을 더 많이 계획하고 있어요.
01:00:03이 AI 시대에 Docker와 Kubernetes 지식을 쌓는 게 가장 중요하다고 생각하시나요?
01:00:13글쎄요, 가장 최고인지는 확신할 수 없지만, Docker는 모든 개발자가 알아야 할 도구라고 생각해요.
01:00:20전문가 수준일 필요는 없지만, 알고는 있어야죠.
01:00:22AI 이전에도 그랬지만, 지금도 뭔가 빌드하고 배포할 때 Docker는 매우 유용한 도구예요.
01:00:31AI 시대에는 샌드박스를 만드는 데 유용하게 쓰일 수 있고요.
01:00:36Docker와 샌드박스 활용에 대해선 한 시간도 얘기할 수 있는데, 여기엔 몇 가지 함정들도 있거든요.
01:00:43완벽하게 안전한 샌드박스는 아니지만, macOS에선 꽤 괜찮습니다.
01:00:49하지만 Docker는 모든 개발자가 꼭 알아야 할 기술이라고 생각해요.
01:00:56Kubernetes는 선택 사항이라고 봅니다.
01:00:59본인 직무에 필요한지에 따라 다르니까요.
01:01:02어느 정도 규모가 커지면 확실히 중요해지긴 하죠.
01:01:07그래도 Docker가 더 중요하다고 봅니다.
01:01:12Docploy가 정확히 Coolify랑 같군요.
01:01:13네, 맞게 이해했네요.
01:01:14네, VPS에 직접 배포하려는 분들에게는 정말 좋은 솔루션들이죠.
01:01:28어떤 AI 모델 제공업체를 쓰시나요?
01:01:31Open Router처럼 모든 모델을 하나의 API로 쓸 수 있는 걸 사용하시나요?
01:01:34저는 주로 ChatGPT 구독을 쓰고 있어요.
01:01:37200달러짜리 구독을 쓰고 있는데, 어떻게든 본전을 뽑으려고 노력 중이죠.
01:01:41Anthropic 구독도 가끔씩 바꾸면서 모델들이 어떤지 시험해 봅니다.
01:01:47그리고 Open Router나 Vercel AI Gateway, 혹은 Cloudflare AI Gateway도 사용하고요.
01:01:54그런 것들도 가끔씩 쓰는데, 예를 들어 Cloudflare의 GLM 모델 같은 걸 사용할 때가 있죠.
01:02:12Cloudflare나 Open Router에서 호스팅하는 그런 모델들이요.
01:02:16다양한 호스팅 공급자를 통해 접속할 수 있으니까요.
01:02:20훌륭한 모델이고 대형 모델들에 비하면 훨씬 저렴하기도 합니다.
01:02:27네, 저도 그런 서비스들을 사용하고 있어요.
01:02:29Pi에서도 아주 쉽게 사용할 수 있어서 좋고요.
01:02:37아, 그리고 VPS 강의에는 DNS는 다루지 않습니다.
01:02:40진짜 VPS 이해하고 기본적인 보안을 강화하는 데만 집중했어요.
01:02:45그냥 필수적인 '기초' 강의예요.
01:02:47모든 걸 다 다루는 고급 강의는 아니라는 걸 분명히 하고 싶네요.
01:02:49기대치를 딱 그 정도로 설정해 주시면 감사하겠습니다.
01:02:52리버스 프록시를 이용해 애플리케이션을 배포하는 건 보여드리지만,
01:02:57심도 있는 네트워킹 같은 강의는 아닙니다.
01:03:01자, 다시 목록으로 돌아와서.
01:03:02호스팅과 배포는 정말 중요한 고려 사항이며 일찍부터 다뤄야 하고요,
01:03:08데이터베이스 같은 것들에도 영향을 주죠.
01:03:11거기에 대해 제 생각을 공유했고요.
01:03:13관리형 서비스를 쓸 좋은 이유들은 분명히 있습니다.
01:03:15반대로 직접 호스팅할 이유들도 있고요.
01:03:18결국 비용과 책임감 같은 문제들에 대한 트레이드오프죠.
01:03:21인증에 대해서는 이미 얘기했었죠.
01:03:23이 부분은, 제가 전에도 언급했지만,
01:03:27직접 구현하는 게 사람들이 겁주는 것만큼 어렵진 않아요.
01:03:32하지만 상황이 좀 복잡해지고 고급 기능이 필요해지면,
01:03:44저는 기꺼이 책임을 넘기는 걸 선호합니다.
01:03:48하지만 그것도 선택의 문제죠.
01:03:51저는 BetterAuth 라이브러리를 정말 좋아해요.
01:03:54비교적 새로운 라이브러리인데 모든 종류의 인증 관련 기능을 제공하거든요.
01:04:10유지보수도 잘 되고 있고요.
01:04:11그게 제가 확인하고 싶었던 거였어요.
01:04:13기본적인 이메일 패스워드 인증을 지원하죠.
01:04:17모든 OAuth 제공업체도 지원하고요, 맞죠?
01:04:21그러니까 세상에 있는 거의 모든 회사의 서비스를 BetterAuth를 통해 인증에 활용할 수 있다는 거죠.
01:04:29더 고급 기능도 있습니다.
01:04:31인기 있는 프레임워크들을 위한 통합 가이드도 있고요.
01:04:342단계 인증이나 패스키, 조직/팀 관리, API 키 발급 같은 고급 기능들도 플러그인 형태로 지원해요.
01:04:47관리자 기능도 있고, OpenID Connect나 SCIM 같은 엔터프라이즈 기능도 있고요.
01:04:55정말 정말 훌륭합니다.
01:04:58그게 제가 인증에 사용하는 기본 솔루션이에요.
01:05:03물론 Clerk이나 WorkOS 같은 다른 서비스들을 쓸 수도 있겠죠.
01:05:10그런 곳들은 라이브러리를 제공해서 프로젝트에 추가하면 인증을 그쪽에 다 넘겨버리는 방식이죠.
01:05:18사용자가 실제로는 그들의 서버를 통해 가입하는 셈이에요.
01:05:22사용자 데이터는 그들 DB에 저장되고, 요금제에 따라 비용을 청구하고요.
01:05:28하지만 사용자 데이터를 직접 책임질 필요가 없다는 편의성이 있죠.
01:05:34데이터베이스가 유출되거나 서버가 해킹당해도, 사용자 데이터에 대한 책임은 그들이 집니다.
01:05:42사용자를 안전하게 인증하는 책임도 그들이 지고요.
01:05:45하지만 이 또한 트레이드오프죠.
01:05:47어쩌면 사용자 데이터를 넘겨주고 싶지 않을 수도 있고요.
01:05:49직접 구현하기 그리 어렵지 않은 걸 굳이 돈 내고 쓰고 싶지 않을 수도 있죠.
01:05:53이런 것들이 다 고민해 봐야 할 트레이드오프들입니다.
01:05:57저는 개인적으로 직접 구현하거나, 혹은 BetterAuth를 쓰는 걸 좋아합니다.
01:06:03하지만 관리형 업체를 선택할 명분도 충분히 있고요.
01:06:07참고로, 채팅에서 수파베이스(Supabase)가 언급되는 걸 봤어요.
01:06:13또 다른 훌륭한 서비스죠.
01:06:15AI 모델이나 AI 에이전트와 함께 인기가 아주 많다는 걸 알고 있습니다.
01:06:22개인적으로 수파베이스를 많이 사용해 보지는 않았어요.
01:06:25물론 어떻게 작동하는지, 어떤 기능이 있는지 이해하려고 조금 만져는 봤죠.
01:06:29데이터베이스, 인증 등 모든 걸 제공하니까요.
01:06:34그리고 충분히 직접 호스팅할 수도 있고요.
01:06:37그런데 제가...
01:06:38제가 틀렸나요?
01:06:42수파베이스 직접 호스팅?
01:06:44되는 거 맞죠?
01:06:45네, 직접 호스팅할 수 있습니다.
01:06:47하지만 클라우드 서비스를 이용할 수도 있죠.
01:06:48무료 티어도 있고요.
01:06:52데이터베이스, 저장소, 인증, 파일 스토리지까지 한 번에 해결할 수 있는 솔루션을 얻게 되는 거죠.
01:06:58정말 편리합니다.
01:07:00아주 좋죠.
01:07:01언급했듯이 직접 호스팅도 가능하고요.
01:07:06하지만 직접 호스팅하더라도, 원하는 대로 모든 것을 완벽하게 수정할 수는 없는 하나의 서비스라는 점은 감안해야 합니다.
01:07:15혹은 무언가를 바꾸거나,
01:07:17원하는 특정 부품으로 대체하는 것도 어렵죠.
01:07:20늘 그렇듯 절충안입니다.
01:07:22제 경우에는,
01:07:25SQLite와 직접 선택한 라이브러리 조합으로 기본적인 애플리케이션을 구축하는 게 그렇게 어렵지 않다고 생각해요.
01:07:33하지만 무엇이 맞고 틀리고는 없습니다.
01:07:37그게 정말 정말 중요해요.
01:07:42Forge Yo를 써봤냐고요?
01:07:47아니요.
01:07:47솔직히 뭔지도 모릅니다.
01:07:50무엇인지 모르니까,
01:07:52당연히 안 써봤죠.
01:07:53죄송합니다.
01:07:55Vercel SDK, Transformers.js 같은 AI 기반 웹 앱 강의 계획이 있냐고요?
01:08:02생각은 좀 있는데, 주로 앞에서 언급한 EVE 프레임워크나 흥미로워 보이는 FLU 프레임워크 같은 비교적 새로운 에이전트 프레임워크로 AI 에이전트를 구축하는 쪽에 관심이 있습니다.
01:08:14그런 프레임워크들이 상당히 흥미롭고 호기심이 생기더라고요.
01:08:17A, 저한테 유용한지, 그리고 B, 그와 관련된 콘텐츠나 강의를 만들고 싶은지 확인해보려고 이것저것 만져보고 있습니다.
01:08:26네.
01:08:31라라벨(Laravel)에 대해 질문하신 걸 제가 놓쳤나요?
01:08:33아까 라라벨에 관한 질문에 답변을 하나 했었는데요.
01:08:37솔직히 그게 당신 질문이었는지는 모르겠네요.
01:08:40하지만 라라벨은 정말 훌륭한 프레임워크입니다.
01:08:4210년 전에 쓸 때 정말 좋아했죠.
01:08:45그 이후로는 사용해보지 않았지만요.
01:08:47그래도 대부분의 애플리케이션에 필요한 기능이 다 내장된 놀라운 프레임워크라는 건 알고 있습니다.
01:08:53그래서 라라벨이나 PHP 쪽에 관심이 있다면 아주 좋은 선택이라고 생각합니다.
01:09:04네, Pi(파이)에 대해서는 이미 얘기했고요.
01:09:06최소한의 핵심 기능과 확장성을 좋아합니다.
01:09:09사람들이 프로젝트를 자동으로 수행하게 하려고 AI 서브 에이전트 개발 팀을 만드는 걸 보는데요.
01:09:14그게 꼭 필요한 걸까요, 아니면 여전히 사람의 모니터링이 필요할까요?
01:09:17음, 사람들이 에이전트 팀을 꾸려서 에이전트들이 협업하고 뭔가 일을 하게 한다는 소식을 읽을 때마다, 저는 그냥 마케팅 허풍이라고 생각합니다.
01:09:29그래서, 아니요.
01:09:31AI 에이전트나 AI 일반은 당연히 중요한 기술이고, 저도 매일 코딩할 때 AI를 사용합니다.
01:09:40제 코드의 대부분은 AI가 작성하죠.
01:09:43물론 코딩 에이전트들을 사용하고, 그 에이전트들이 연구를 위해 서브 에이전트를 만들기도 합니다.
01:09:49하지만 스스로 뭔가를 해내는 에이전트 팀이나 여러 에이전트 팀이 협업하는 시스템과는 아직 거리가 멀어요.
01:10:01AI를 조종하고 작업을 시작시키는 건 늘 저입니다.
01:10:06누군가에게는 이게 다르게 작동할지 모르겠지만, 여러 에이전트가 일을 처리하고 서로 소통하는 걸 보면 엄청나게 생산적으로 느껴질 수는 있다고 생각해요.
01:10:17하지만 현재는 물론이고 가까운 미래에도, 결국에는 완성도가 낮은 코드가 나올 가능성이 높다고 생각합니다.
01:10:30테일스케일(Tailscale) 강의도 하셨나요?
01:10:34그게 질문인가요?
01:10:35채팅이 올라가 버렸네요.
01:10:40어디 있지?
01:10:47참, 도커 강의 추천요.
01:10:50도커 강의가 하나 있는데, 그걸 추천합니다.
01:10:57도커 배우기에 아주 좋다고 생각해요.
01:11:00그리고 테일스케일은 강의가 없습니다.
01:11:03저도 기본적인 기능만 쓰는데, 그 정도만으로도 이미 훌륭해서 확신이 안 서네요.
01:11:09인터넷을 통해 모든 VPS와 장치를 자신만의 사설 네트워크에 넣을 수 있다는 건 정말 놀랍죠.
01:11:16그 모든 걸 무료로 이용할 수 있기도 하고요.
01:11:18꽤 후한 편이죠.
01:11:20그래서 테일스케일은 정말 대단합니다.
01:11:22웁스.
01:11:23하지만 기초적인 기능만으로는 강의를 만든다고 해서 큰 가치를 더해줄 것 같지 않아서 계획은 없습니다.
01:11:29솔직히 저도 고급 기능은 전혀 사용하지 않으니까요.
01:11:33네, 수파베이스는 파이어베이스(Firebase)의 대안이죠.
01:11:44어쩌면 더 나을 수도 있고, 무엇보다도 사용 가능하다는 게 중요하죠.
01:11:48음, 파이어베이스도 무료로 쓸 수 있긴 합니다.
01:11:51그래도 수파베이스는 직접 호스팅이 가능하지만, 최소한 제가 확인했을 때는 파이어베이스는 그게 안 됐죠.
01:11:56적어도 제가 있는 엑스(X) 커뮤니티 같은 곳에서는 수파베이스가 확실히 더 인기가 많아요.
01:12:03하지만 파이어베이스도 평판만큼 나쁘진 않다고 생각합니다.
01:12:10특히 2017년, 2018년 무렵에 파이어베이스를 정말 많이 썼거든요.
01:12:16정말 훌륭한 서비스라고 생각했어요.
01:12:18정말 괜찮은 관리형 백엔드였죠.
01:12:23하지만 지금은 클라우드플레어 관련 기술을 쓰거나 클라우드플레어 위에서 구축하는 프로젝트를 제외하고는 관리형 백엔드를 그렇게 많이 사용하지는 않습니다.
01:12:34거기서는 상황이 좀 다르니까요.
01:12:37토리(Tauri)도 조금 만져봤냐고요?
01:12:39네.
01:12:40하지만 데스크톱 애플리케이션을 건드릴 때면 늘 일렉트론(Electron)으로 돌아오곤 하네요.
01:12:45데스크톱 앱 개발에는 그다지 큰 관심이 없기도 하고요.
01:12:50애플이 가격을 인상했죠.
01:12:51네, 봤습니다.
01:12:52메모리 같은 부품 가격이 저렴해졌는데도 가격을 인상해야 했죠.
01:12:55지난 2년 동안 애플이 가격 조정을 안 해서 오히려 좋은 딜을 얻을 수 있었던 게 웃긴 상황이었죠, 그렇죠?
01:13:04요즘 직접 코딩을 하냐고요?
01:13:06네, 하고 있습니다.
01:13:07아직도 해요.
01:13:07하지만 코드의 대부분은 분명 AI가 생성한 겁니다.
01:13:14그렇지만, 다시 말하지만, 그 모든 코드를 검증하고 확인하고 있어요.
01:13:19직접 수정하거나 AI를 써서 바꾸기도 하죠.
01:13:22그냥 '이 코드 짜줘' 하고,
01:13:24오케이, 다음 코드,
01:13:24난 신경 안 써,
01:13:26이런 게 제 방식의 '바이브 코딩'이에요.
01:13:27그리고 저는 그렇게 하지 않습니다.
01:13:29당장 필요해서 대충 쓰는 유틸리티 도구 같은 일회성 소프트웨어라면 모를까,
01:13:35작동만 한다면 코드는 신경 안 써요.
01:13:38하지만 진지한 작업이라면, 절대 그렇게 안 하죠.
01:13:42AI를 활용한 '제2의 뇌'나 지식 베이스 구축 아이디어는 시도해 봤냐고요?
01:13:46네, 좀 만져봤습니다.
01:13:47솔직히 결과가 엄청 만족스럽지는 않았어요.
01:13:51아마 제가 너무 정리를 못 하고 지저분하게 써서 그럴지도 모르겠네요.
01:13:55물건을 정리해서 보관하는 능력이 좀 부족하거든요.
01:13:57그래서 AI가 저를 다루기는 좀 힘들 거예요.
01:14:03AI 도구들을 샌드박스 환경에서 실행하는 것에 대해 얘기하는 사람을 많이 못 봤는데요.
01:14:07현재 저희 고객사에서 승인된 AI 사용은 365 코파일럿(Copilot)뿐이라서요.
01:14:12네, 그 샌드박스 관련 분야는,
01:14:18지금 정말 많은 일이 일어나고 있죠.
01:14:20매일같이 새로운 샌드박스 스타트업이 생겨나고 있으니까요.
01:14:24AWS도 샌드박싱에 관한 람다(Lambda) 마이크로 VM 서비스를 발표했죠.
01:14:30그래서 아주 많은 일들이 벌어지고 있습니다.
01:14:33한 1년쯤 뒤에 상황이 좀 정리되고 나면 어떤 방식이 살아남을지 지켜보는 것도 흥미로울 것 같네요.
01:14:40예를 들어, 버셀(Vercel)이 만든 'JustBash' 같은 도구가 있는데,
01:14:47시스템에서 실행할 수 있는 아주 간단한 샌드박스를 제공하죠.
01:14:51그런 종류의 도구들이 꽤 흥미롭더라고요.
01:14:54뭐, 지금은 모든 것이 굉장히 활발하게 개발되고 있는 단계지만요.
01:15:00스펙 기반 개발을 시도해 봤냐고요?
01:15:03얼마나 엄격하게 정의하느냐에 따라 다르겠지만, 네, 해봤습니다.
01:15:06하지만 거대한 스펙 하나를 짜놓고 AI에게 모든 걸 맡기는 방식은 믿지 않습니다.
01:15:13저는 늘 반복하며 개선하는 방식을 더 좋아하거든요.
01:15:17제품을 직접 느껴보면서 감을 잡아야 하니까요.
01:15:20물론 계획은 있죠.
01:15:21스펙은 있지만, 제품을 만들어봐야 무엇이 빠졌는지, 어떤 게 원하는 대로 작동하지 않는지 알 수 있더라고요.
01:15:31저한테는 늘 그랬습니다.
01:15:32물론 모든 팀이나 모든 규모에 적합한 방식은 아니겠죠.
01:15:37하지만 혼자 혹은 작은 팀으로 작업할 때는 꽤 효과가 있습니다.
01:15:43마이크론(Micron)이 메모리 분야에서 80퍼센트의 영업이익률을 기록하는 것에 대해 어떻게 생각하냐고요?
01:15:47네, 결국엔 언젠가 변화가 생길 부분들이라고 봅니다.
01:15:50하지만 지금은, 뭐, 잘 됐네요, 그죠?
01:15:52영원한 건 없으니까요.
01:15:55자, 계속해 봅시다.
01:15:58계속하기에 딱 맞는 질문이 있네요.
01:16:00UI 디자인은 어떻게 접근하시나요?
01:16:02그냥 테일윈드(Tailwind)를 쓰나요?
01:16:03요즘 좋은 UI 프레임워크가 부족하죠.
01:16:06자, 스타일링에 대해 얘기해 봅시다.
01:16:07적어도 프론트엔드를 구축한다면 중요한 부분이니까요.
01:16:11웹 프론트엔드 말입니다.
01:16:13스타일링의 경우, 저는 주로 바닐라 CSS를 사용합니다.
01:16:22요즘 CSS는 정말 많이 발전했거든요.
01:16:28아카데미 채널에 관련 영상도 좀 올렸어요.
01:16:30불행히도 조회수는 잘 안 나왔지만요.
01:16:33하지만 현대적인 CSS와 브라우저는 정말 훌륭한 기능들을 갖추고 있어서
01:16:39CSS로 작업하는 것도, 브라우저에서 현대적인 UI를 구축하는 것도
01:16:463~4년 전보다 훨씬 쉬워졌습니다.
01:16:49많은 사람이 이걸 놓치고 있는 것 같아요. 첫째, 스타일링과 CSS를 좋아하지 않는 사람들이 많고,
01:16:55그건 예전부터 늘 그래왔죠.
01:16:58둘째, 이제 AI 시대가 되니 다들 AI 에이전트 같은 것에만 집중하고 있으니까요.
01:17:03그래서 다들 현대적인 CSS와 브라우저가 얼마나 강력해졌는지 놓치고 있는 것 같습니다.
01:17:10특히 저는 인터넷 익스플로러 8까지 지원해야 했던,
01:17:16그런 옛날 시절부터 개발자로 활동해 온 입장에서 보면,
01:17:21그땐 정말 끔찍했거든요.
01:17:23지금은 정말 훨씬 좋아졌습니다.
01:17:24그래서 제게 스타일링은 라이브러리보다는 현대적인 CSS를 사용하는 쪽이 더 가깝습니다.
01:17:29게다가 AI에게도 아주 잘 시킬 수 있고요.
01:17:32본인이 직접 초기 코드나 의사 코드를 작성해서 스타일 시스템 등을 정의해두고 AI를 활용하는 식으로 시작할 수도 있죠.
01:17:38정말 쉬워졌습니다.
01:17:41만약 안 쓴다면 테일윈드를 주로 사용합니다.
01:17:44테일윈드가 항상 가져왔던, 그리고 당연히 지금도 가진 가장 큰 장점 중 하나는,
01:17:51클래스 이름을 바꾸는 것만으로 코드에서 아주 빠르게 디자인을 반복할 수 있다는 거죠.
01:17:56정말 그렇죠?
01:17:58바닐라 CSS를 쓰면 적절한 CSS 파일을 찾아서,
01:18:04올바른 규칙이나 속성을 찾아야 바꾸는 게 단점이긴 합니다.
01:18:08반면 테일윈드는 마크업에서 바로 바꾸고 싶은 박스를 찾아서 클래스를 수정하면 되니까요.
01:18:12그런 수정이 엄청나게 빠릅니다.
01:18:15AI를 쓰든 안 쓰든 말이죠.
01:18:18그게 큰 장점이고, 테일윈드가 그렇게 유명해진 이유라고 생각해요.
01:18:23네, 저도 여전히 사용합니다.
01:18:25디자인을 구축할 때의 그 반복 속도는 정말 훌륭합니다.
01:18:29어떤 접근 방식을 쓰느냐에 따라 다르겠죠.
01:18:31피그마(Figma) 같은 툴로 디자인을 미리 한다면 중요하지 않을 수도 있겠지만,
01:18:35저는 작업하면서 바로바로 디자인하는 스타일이라서요.
01:18:38그런 환경에서는 당연히 테일윈드가 꽤 좋습니다.
01:18:41물론 AI가 있다면 바닐라 CSS로도 정말 쉽죠.
01:18:44AI에게 여기 마진을 좀 더 달라고 말만 하면 되니까요.
01:18:48물론 직접 파일을 찾아서 수정할 수도 있고요.
01:18:51설정이 어디 있는지 기억 안 나면,
01:18:53개발자 도구에서 쉽게 찾아낼 수 있죠.
01:18:56개발자 도구에서 디자인을 바로 조정해 보고,
01:18:59만족스러운 결과가 나오면 그 변경 사항을 AI에게 반영하라고 하거나 스스로 적용하면 됩니다.
01:19:07주니어가 데브옵스(DevOps)로 시작하는 게 가능할까요?
01:19:11아니면 실무 경험을 쌓은 뒤에 넘어가는 역할일까요?
01:19:16아니요, 주니어가 데브옵스로 시작하는 것도 충분히 가능하다고 생각합니다.
01:19:20물론 기본적인 개발 지식은 갖춰야겠죠.
01:19:24단순 운영(Ops)이 아니라 '데브(Dev)옵스'니까요.
01:19:27그럼요, 왜 안 되겠어요?
01:19:29본인에게 데브옵스가 정확히 어떤 의미인지가 중요하겠죠.
01:19:35배포를 관리하고,
01:19:39CI/CD를 구축하고, 에이전트 샌드박스를 관리하며,
01:19:43다양한 서비스와 상호작용하는,
01:19:46전반적인 측면은 정말 중요하고 앞으로도 계속 중요할 겁니다.
01:19:51그리고 충분히 실현 가능한 커리어이고 여러분도 할 수 있는 일이라고 생각합니다.
01:19:56그저 조합의 문제일 뿐이죠.
01:19:59물론 무엇이 배포되는지는 이해해야 합니다.
01:20:03그러니 당연히 기본적인 개발 이해도는 갖춰야 하죠.
01:20:06하지만 분명 유효한 선택지라고 봅니다.
01:20:13아, 맞다. Astro요.
01:20:15방금 Astro에 대해 읽었는데, 꽤 좋은 프레임워크더라고요.
01:20:20최근에 새 버전이 나왔는데,
01:20:22속도도 더 빨라졌고 Hano와 함께 사용할 수 있게 되었죠.
01:20:27그래서 라우팅과 미들웨어는 Hano를 쓰고
01:20:29페이지는 Astro로 정의할 수 있습니다.
01:20:32그럼 다음 주제인 콘텐츠 관리로 넘어가 보죠.
01:20:35물론 데이터베이스 쿼리와 결합할 수도 있습니다.
01:20:38데이터베이스는 데이터를 저장하는 곳이고 콘텐츠도 결국 데이터니까요.
01:20:41하지만 제가 여기서 말하는 콘텐츠 관리는
01:20:45대부분의 웹 애플리케이션이나 사이트에는 크게 두 가지 유형의 콘텐츠가 있다는 겁니다.
01:20:52사용자가 생성한 콘텐츠가 있을 수 있는데,
01:20:55그건 보통 데이터베이스에 저장하죠, 맞나요?
01:20:58소셜 네트워크를 만드는데 사용자가 게시물을 생성할 수 있다면,
01:21:01그 게시물들은 데이터베이스에 저장됩니다.
01:21:05하지만 여러분, 즉 개발자나 사이트 소유자가
01:21:07직접 제공하는 콘텐츠도 있을 수 있습니다.
01:21:10마케팅 페이지나 블로그 게시물 같은 것들이죠.
01:21:13큰 차이점은 사용자 생성 콘텐츠의 경우,
01:21:17애플리케이션이 실행되는 동안 동적으로 생성된다는 점입니다.
01:21:21그게 애플리케이션의 핵심 목적 중 하나죠.
01:21:24소셜 네트워크의 주 목적은 사람들이 게시물을 생성하고 공유하는 것이니까요.
01:21:29반면 마케팅 콘텐츠는 어느 정도 정적입니다.
01:21:33물론 시간이 지나면서 새로운 콘텐츠를 추가하긴 하겠지만요.
01:21:36소유자인 여러분은 언제 새로운 콘텐츠를 추가할지 분명히 알고 있잖아요, 그렇죠?
01:21:41따라서 그 마케팅 콘텐츠는 사용자 생성 콘텐츠와는 다른 방식으로 저장할 수 있습니다.
01:21:47사용자 생성 콘텐츠는 핵심 제품의 일부인 반면,
01:21:50마케팅 콘텐츠는 HTML로 변환되는 마크다운 파일 정도로도 충분할 수 있죠.
01:21:55흔히 사용하는 방식입니다.
01:21:57예를 들어, Astro를 사용하면 그렇게 할 수 있습니다.
01:22:00Astro는 여러모로 훌륭한 프레임워크지만,
01:22:04특히 콘텐츠가 많은 사이트,
01:22:07즉 소유자가 직접 제공하는 콘텐츠 중심 사이트에 아주 적합합니다.
01:22:11Astro를 사용하면 게시물이나 기사를 마크다운 파일로 아주 쉽게 관리할 수 있죠.
01:22:19Astro에는 이를 HTML로 아주 빠르게 변환해주는 내장 마크다운 프로세서가 있거든요.
01:22:27그래서 사이트의 콘텐츠나 마케팅 부분을 구축할 때 제가 제안하는 방식 중 하나입니다.
01:22:34그건 좀 더 고급 주제이긴 하지만, 흔하지 않은 건 아닙니다.
01:22:37여러 프레임워크와 서버를 조합할 수도 있으니까요.
01:22:43메인 애플리케이션을 위한 서버와 기술 스택을 하나 두고,
01:22:47예를 들어 소셜 네트워크는 Next.js를 사용하고,
01:22:51도커 컨테이너 안의 Postgres 데이터베이스를 쓴다고 합시다.
01:22:55그런데 마케팅 사이트는, 메인 사이트가 app.yourdomain.com이라면,
01:23:02그냥 yourdomain.com처럼 서브도메인 없이 마케팅 사이트를 만들 수 있죠.
01:23:06그건 마케팅 페이지를 담은 Astro 사이트일 수도 있고요.
01:23:10로그인 링크는 메인 사이트인 app.yourdomain.com으로 리다이렉트하면 됩니다.
01:23:16이런 구성도 전혀 드물지 않습니다.
01:23:18그런 경우에 Astro는 아주 좋은 선택이죠.
01:23:20물론 전부 하나의 앱으로 만들 수도 있고요.
01:23:22Next.js 애플리케이션 안에서 마크다운 페이지를 렌더링할 수도 있습니다.
01:23:28꼭 마크다운이어야 할 필요도 없죠.
01:23:31그냥 일반 HTML 페이지여도 됩니다.
01:23:33물론 마케팅 콘텐츠를 데이터베이스에 저장해도 되고요.
01:23:37전혀 문제 될 것 없습니다.
01:23:38그저 이런 옵션들이 있다는 걸 알면 되는 거죠.
01:23:41마크다운을 사용하면 예를 들어 새로운 배포를 할 때 빌드 타임에 미리 페이지를 생성할 수 있다는 장점이 있습니다.
01:23:48그럼 페이지를 좀 더 빠르게 제공할 수 있죠.
01:23:52데이터베이스에서 가져올 필요가 없으니까요.
01:23:54데이터베이스를 호출하지 않는 겁니다.
01:23:56데이터베이스 부하도 줄여주고요.
01:23:57네, 그런 정적 접근 방식이 인기 있는 이유입니다.
01:23:59그런 이유들을 고려해 볼 가치가 있는 거죠.
01:24:06그리고 AI의 시대에도 여전히 이런 고려 사항들은 중요합니다.
01:24:08AI에게 무작정 질문하고 그대로 믿으면 안 된다는 것도 마찬가지고요.
01:24:18여기서 왜 그런 결정이 내려지는지 이해하는 게 중요하죠.
01:24:21물론 Storyblok 같은 콘텐츠 관리 시스템도 있습니다.
01:24:28대부분의 사람들이 잘 아는 건 아닐 수도 있겠네요.
01:24:32그냥 제가 예전에 써본 서비스예요.
01:24:34핵심 아이디어는 마케팅 콘텐츠 대부분을 관리형 서비스에 저장한다는 겁니다.
01:24:43좋은 에디터와 데이터를 가져올 수 있는 API를 제공해주죠.
01:24:49따라서 마크다운 파일을 가질 필요도 없고,
01:24:51데이터베이스에 콘텐츠를 넣을 필요도 없습니다.
01:24:53대신 추가적인 서비스를 이용하는 거죠.
01:24:54이런 콘텐츠 관리 시스템은 아주 많습니다.
01:24:58그리고 Storyblok 같은 헤드리스 시스템들을 구분해야 합니다.
01:25:02적어도 예전엔 헤드리스 방식이었죠.
01:25:04API를 통해 데이터를 애플리케이션으로 불러와 보여주는 방식입니다.
01:25:09물론 워드프레스처럼 단순 데이터 관리와 API 제공을 넘어 프론트엔드까지 제공해주는 시스템들도 있고요.
01:25:22직접 코드를 작성하고 싶지 않다면 이런 방식이 아주 좋겠죠.
01:25:23직접 코드를 어디에 구현하고 싶지 않거나 그런 것들을 다루고 싶지 않을 때 아주 좋습니다.
01:25:33네, 그렇습니다.
01:25:34일반적으로 콘텐츠 관리 시스템을 사용하는 것은 흥미로울 수 있어요.
01:25:39저는 개인적으로 굳이 그럴 이유를 못 느껴서 안 쓰지만요.
01:25:42전 그냥 Astro와 마크다운 파일로 충분히 만족합니다.
01:25:44행복해요.
01:25:45하지만 규모에 따라 다를 수 있다는 점은 명심하세요.
01:25:49저는 혼자 일하거나 소규모 팀으로 일하니까요.
01:25:51만약 대기업이라면 마크다운 파일을 이용한 콘텐츠 관리는 변경사항 동기화 같은 새로운 복잡성을 야기합니다.
01:25:59승인 절차 같은 것도 직접 구축해야 할 수 있고요.
01:26:04Storyblok 같은 서비스들은 그런 기능을 제공하죠.
01:26:06그러니 결국 규모, 업무, 조직 구성 등 모든 것에 따라 달라집니다.
01:26:15네.
01:26:18Max는 대단하죠.
01:26:19그가 하는 말은 항상 경청하고 있습니다.
01:26:21정말 너무나 감사합니다.
01:26:22아래에 남겨주신 좋은 댓글들도 다 읽고 있고요.
01:26:24정말 모두 너무 감사드립니다.
01:26:26댓글 하나하나가 큰 힘이 됩니다.
01:26:28정말 의미가 커요.
01:26:29정말 진심으로 감사합니다.
01:26:30도움이 된다니 정말 기쁩니다.
01:26:33제가 이런 것들에 대해 어떻게 생각하는지, 어떤 의사결정을 하는지 뇌를 비워내듯 공유하려고 노력 중이에요.
01:26:41소프트웨어 개발 수명 주기는 변하고 있습니다. 코드 작성 비용이 급락하고 있으니까요.
01:26:46병목 현상이 코드 생성에서 변경, 검증, 검토, 거버넌스로 이동하고 있습니다.
01:26:51네.
01:26:55전체 소프트웨어 개발 수명 주기가 확실히 변하고 있습니다.
01:26:58요구되는 스킬셋도 바뀌고 있고요.
01:27:00예를 들어 AI와 함께, 혹은 AI가 대부분을 구현하게 될 때를 대비해 이런 사항들을 알고 의사결정을 내리는 게 매우 중요합니다.
01:27:11하지만 무엇보다 의사결정을 내릴 수 있어야 하죠.
01:27:14이건 아주 기초적인 의사결정들이죠.
01:27:16기술 스택 같은 것들요.
01:27:18소프트웨어 아키텍처에 대한 다른 많은 결정들도 있습니다.
01:27:21무엇을 빌드하느냐에 따라 큐가 필요한지 고민해야 하죠.
01:27:26팬아웃 패턴이 필요할까요?
01:27:28큐를 관리하려면 어떤 제공자를 써야 할까요?
01:27:31직접 관리할까요?
01:27:32어떻게 관리할 거죠?
01:27:33이런 것들이 무엇을 빌드하느냐에 따라 중요해지는 고급 질문들입니다.
01:27:38이메일을 보낸다면 어떻게 발송할지도 결정해야죠.
01:27:42훌륭한 서비스인 Resend 같은 걸 사용할 건가요?
01:27:48아니면 AWS SES 같은 걸 쓰나요?
01:27:52이 모든 게 다음 레이어의 중요한 질문들입니다.
01:27:58이건 아키텍처가 아니라 기술 스택에 관한 거대한 질문들이죠.
01:28:04우리는 더 깊이 들어갈 수 있습니다.
01:28:06그게 바로 제 시스템 디자인 코스에서 다루려는 핵심 내용 중 하나이기도 합니다.
01:28:12애플리케이션 구축에 대해 어떻게 생각하고, 트레이드오프를 평가하고, 어떤 빌딩 블록을 선택할지 말이죠.
01:28:20이게 웹 개발뿐만 아니라 미래의 소프트웨어 개발 전반에 걸친 핵심 역량이라고 믿습니다.
01:28:28여전히 코드가 중요할 것이고 코드를 이해하고 평가하고 판단하는 능력은 필수입니다.
01:28:37적어도 지금 당장 AI가 결점 없이 완벽한 것은 아니니까요.
01:28:43가까운 시일 내에 그렇게 될지도 잘 모르겠고요.
01:28:47그건 여전히 중요합니다.
01:28:48코드를 읽고 이해할 수 있어야만 합니다.
01:28:51하지만 기술 스택, 소프트웨어 아키텍처, 패턴 사용에 대한 결정도 내려야 합니다. 모든 선택에는 트레이드오프가 존재하니까요.
01:29:02만약 완벽하게 정해진 최선의 정답이 있다면, 개발은 아주 쉬웠겠죠.
01:29:07물론 AI 이전에도 그건 마찬가지였을 겁니다.
01:29:09하지만 트레이드오프는 타당한 이유가 있어서 존재합니다.
01:29:12확장성, 비용, 단순함 사이에서 항상 고민해야 하죠.
01:29:16최선이라는 건 존재하지 않습니다.
01:29:18그렇기 때문에 어떤 기술과 솔루션이 어떤 장단점을 가져오는지 알고, 어떻게 의사결정을 내릴지 이해하는 게 무척 중요합니다.
01:29:34모든 게 클라우드로 넘어가서 개인 컴퓨터는 아무 의미가 없어질까요?
01:29:39아니요.
01:29:41배포 같은 경우 당연히 로컬 컴퓨터에서 할 순 없죠.
01:29:45차고에 직접 데이터 센터를 만들 것도 아니고요.
01:29:48하지만 개발 업무 전반에 있어서는, 아니요, 전부 클라우드로 갈 것 같진 않습니다.
01:29:55이미 AI를 통해 더 많은 데이터를 클라우드로 보내고 있긴 하지만요.
01:30:00계속해서 클라우드로 데이터를 보내는 중이죠.
01:30:03그럼에도 개발은 우리 머신에서 이루어집니다.
01:30:08데이터는 결국 우리 머신이나 자체 네트워크에 존재하니까요.
01:30:12적어도 저에게는 그게 곧 변할 것 같지는 않네요.
01:30:16저는 제 컴퓨터를 만지고 설정하는 걸 너무나 좋아하거든요.
01:30:23하지만 인터넷 연결이 없으면 할 수 없는 일이 많아진 건 확실히 느껴집니다.
01:30:3010년 전과 비교하면 우리 노트북은 점점 더 클라이언트 기기가 되어가고 있어요.
01:30:42Cloudflare 코스도 나오나요?
01:30:43네, 계획 중입니다.
01:30:44역시나 계획되어 있죠.
01:30:46준비 중인 코스가 정말 많습니다.
01:30:48많은 코스들을 활발히 제작하고 있고요.
01:30:50Bun과 Pi 코스도 곧 나올 겁니다.
01:30:54네, 다 계획에 있습니다.
01:30:56아까도 말씀드렸지만,
01:30:58코스 소식을 가장 빨리 알고 싶으시다면 [academind.com/community에서](https://www.google.com/search?q=https://academind.com/community%EC%97%90%EC%84%9C) 뉴스레터를 구독하세요.
01:31:05아니면 저희 디스코드로 들어오셔도 됩니다.
01:31:06새 코스 소식은 다 거기 올라오거든요.
01:31:08물론 이미 공개된 코스들도 아주 많습니다.
01:31:11흥미로운 주제가 있을 수도 있고요.
01:31:14멤버십이나 구독을 하시면, 구독 중인 동안 모든 기존 코스와 새로 추가되는 코스들을 모두 수강하실 수 있습니다.
01:31:22참고로 말씀드렸습니다.
01:31:28아, 아, 아.
01:31:35프론트엔드 디자인 스킬은 정말 최고예요.
01:31:40댓글은 전부 읽고 있습니다. 다만 이미 언급했거나 제 생각을 더 보탤 게 없는 건 넘어가기도 해요.
01:31:46일부 의견들은 타당하지만, 지금 제가 따로 할 말이 없는 경우죠.
01:31:53네, 프론트엔드 디자인 스킬은 제 프로젝트에 매우 유용합니다.
01:31:56개인의 스킬에 의존하는 게 좋을까요?
01:31:58CSS만 해도 개발 시간이 꽤 걸리니까요.
01:32:02본인의 스킬에 의존하는 걸 말씀하시는 건가요?
01:32:09그건 항상 중요했고, 앞으로도 변하지 않을 겁니다.
01:32:14특히 AI 시대에는 말이죠. 전 이걸 굳게 믿기에 계속 강조하는 겁니다.
01:32:20결국 AI를 조종하고, 의사결정을 내리고, 인간적인 입력을 제공하는 것이 핵심입니다.
01:32:29물론 AI에게 모든 결정을 맡길 수도 있죠.
01:32:32유틸리티 도구나 일회성 소프트웨어라면 괜찮겠지만, 그 이상은 아닙니다.
01:32:39사람들에게 배포하고 수익을 낼 무언가를 빌드한다면, 그것은 제 비전이어야 하고 외관 또한 제 통제 하에 있어야 합니다.
01:32:52AI에게 서비스를 빌드하라고 시킨 뒤, 결과를 보고 '음, 이 정도면 됐어'라고 할 수는 없잖아요.
01:32:57절대 안 되죠.
01:32:57그렇게 할 수는 있겠지만, 여러분만의 영향력을 발휘하고, 본인의 스킬을 더하고, 좋은 제품을 직접 만들 때 사람들의 눈에 띌 수 있습니다.
01:33:11디자인은 좋은 제품을 위한 중요한 부분입니다.
01:33:14전 디자인에 정말 소질이 없지만요.
01:33:17그건 그냥 제가 최소한 괜찮아 보이기 위해 더 노력해야 한다는 뜻일 뿐입니다.
01:33:30AI 시대에 개발을 다시 배우고 AI도 함께 배우려면 어떻게 해야 할까요?
01:33:35어디서부터 시작해야 할지 모르겠고 배울 게 너무 많네요.
01:33:39이미 개발 경험이 있으시다면, 가장 좋은 방법은 직접 무언가를 빌드해보는 겁니다. AI를 써서 단계별로 빌드해보세요.
01:33:52AI에게 '소셜 네트워크 하나 만들어줘'라고 하지 마세요.
01:33:54그렇게 시키지 마세요.
01:33:56대신 무엇을 만들고 싶은지 스스로 생각하세요.
01:33:58아까 말한 아마존 클론 같은 거라도 좋습니다.
01:34:02핵심 빌딩 블록 단위로 쪼개보세요.
01:34:04인증 솔루션은 무엇을 쓸지 직접 결정하시고요.
01:34:08그런 모든 결정들은 직접 내리세요.
01:34:11시간을 들여서 여러 옵션을 깊이 살펴보고, 꼭 최고를 선택해야 한다는 압박은 느끼지 마세요.
01:34:15최고의 선택 같은 건 없으니까요.
01:34:17그저 몇 가지 옵션을 평가해 보고, 코드를 좀 살펴본 뒤에 본인에게 좋게 느껴지는 것을 선택하세요.
01:34:24그리고 AI를 사용하는 것도 좋지만, 스스로 평가하는 과정이 필요합니다.
01:34:27네, 느릴 겁니다.
01:34:29시간이 걸리겠지만, 그게 바로 학습이라는 과정이죠.
01:34:32AI는 분명 여러분에게 지금 시대에 아주 빨리 적응해야 하고 뒤처지면 안 된다는 느낌을 줄 수 있지만, 그건 완전히 헛소리입니다.
01:34:42여러분에게는 시간이 있습니다. 미래는 우리가 지금 생각하는 것과는 완전히 다를 가능성이 높으니까요.
01:34:50미래를 내다볼 수 있는 사람은 아무도 없어요.
01:34:52예를 들어, 2년 전에 프롬프트 엔지니어링을 마스터하는 데 시간을 쏟았더라도, 그건 지금보다 그때가 더 중요했거나 단순히 방식이 달라졌을 뿐이죠.
01:35:032년 전에 하지 않았다고 뒤처진 것이 아닙니다. 상황은 지금 또 다르니까요.
01:35:09그러니 시간을 갖고, 서두르지 마세요.
01:35:11여러분들이 쌓아가는 기술은 언제나 가치 있을 겁니다.
01:35:14가장 안 좋은 것은 그냥 아무것도 하지 않는 것입니다. 개발을 그만두고 싶은 게 아니라면 말이죠.
01:35:22하지만 기술을 날카롭게 유지하고, 연습하고, 그런 도구들을 가지고 놀면서 꾸준히 최신 상태를 유지하는 것은 좋은 생각이라고 봅니다.
01:35:32다시 개발을 시작하려면, 클론을 만들고 시간을 들여 스스로 결정을 내리는 것이 좋은 접근법이라고 생각합니다.
01:35:40레디스(Redis)는 어떤가요?
01:35:41네, 레디스도 좋은 포인트죠.
01:35:46모든 애플리케이션에 필요한 건 아닙니다.
01:35:48개발을 처음 시작할 때 대부분의 애플리케이션에는 레디스가 필요 없다고 봅니다.
01:35:53하지만 당연히 레디스는 확장성이 중요해질 때 추가하는 도구로 봅니다.
01:36:01왜냐하면 레디스로 더 잘 풀 수 있는 문제들을, 심지어 단순한 SQLite로도 해결할 수 있기 때문이죠.
01:36:10레디스보다 성능은 떨어지겠지만, 많은 상황에서 충분히 괜찮을 겁니다.
01:36:14그래도 레디스에 대해서는 조금 알아두는 게 좋습니다. 무엇인지, 어떤 경우에 쓰이는지, 어떻게 애플리케이션에 추가할 수 있는지 정도는 이해해두세요.
01:36:25추가하고 사용하는 건 어렵지 않거든요.
01:36:26처음 시작할 때 많은 애플리케이션에는 그저 과도한 기능이라고 생각합니다.
01:36:31하지만 캐시 데이터베이스를 두면, 규모가 어느 정도 커졌을 때 애플리케이션의 확장성, 효율성, 성능을 개선하는 데 100% 도움이 될 수 있습니다.
01:36:44그리고 여기서 큐(Queue)에 대해 언급하셨는데, 일반적으로 맞는 말입니다.
01:36:51모든 빌딩 블록은 매우 중요하죠.
01:36:55하지만 다시 말해, 애플리케이션에서 이메일을 보내기 위해 데이터베이스에 큐가 필요하다면, SQLite로도 지속 가능한 큐를 만들 수 있습니다.
01:37:07SQLite가 레디스만큼 좋은 건 아닐 수 있고, 분명 잠재적인 문제점도 있지만 규모에 따라 충분할 수 있습니다.
01:37:15그래도 언젠가는 레디스에 대해 확실히 공부하고, 어떻게 작동하는지 배우고, 사용을 고려해 봐야 합니다.
01:37:22LibSQL, Turso 대 SQLite에 대해 어떻게 생각하시나요?
01:37:25네, 아까 조금 얘기했었죠.
01:37:28SQLite는 어떻게 사용하든 정말 최고입니다.
01:37:31순수 SQLite를 사용하든, Turso를 사용하든, 혹은 LibSQL이라고 불리는 것도 제 생각엔 정말 훌륭합니다.
01:37:43본질적으로 재구현된 것이라서, 몇 가지 멋진 기능들이 내장되어 있죠.
01:37:49일반 SQLite에는 없는 기능들이요.
01:37:52그렇긴 하지만, 왜인지 저는 익숙해서 그런지 대부분의 애플리케이션에서 그냥 SQLite를 사용하고 있습니다.
01:38:00하지만 Turso는 데이터베이스 솔루션을 찾을 때 고려해 볼 만한, 아주 매우 흥미로운 확장 재구현 제품입니다.
01:38:27제품 책임자(PO)와 개발자 역할이 합쳐질 거라고 보시나요?
01:38:31네, 많은 것들이 바뀌고 있죠.
01:38:36모든 역할이 진화하고 있고, 새로운 역할들도 생겨날 겁니다.
01:38:42사실 직업 역할이 어떻게 진화할지에 대해 너무 많은 예측을 하고 싶지는 않아서 솔직히 말하면 미래를 내다보는 게 어렵습니다.
01:39:01첫째로 기업들, 특히 엔터프라이즈는 우리가 생각하는 것보다 더 느리게 움직이니까요.
01:39:09또 하나는 AI가 매우 유능하긴 하지만 1~2년 내에 AI 사용이 어떻게 될지, 특히 다양한 기업들과 규모에서 어떻게 변할지 예측하기 어렵습니다.
01:39:29하지만 모든 역할은 당연히 진화하고 있고, 앞서 언급했듯이 개발자가 갖춰야 할 기술들도 바뀌고 있다고 봅니다.
01:39:38React를 정말 잘 알아서 React 코드를 뱉어내기만 하면 되던 시절은 이제 끝났거나 끝나가고 있습니다.
01:39:53물론 코드를 직접 입력하지 않고 하루 종일 리뷰만 하는 개발자에 대한 수요가 있을 수는 있겠죠.
01:40:02글쎄요, 그게 재미있을까요?
01:40:02전 잘 모르겠지만, 미래에는 그게 유효한 직업일 수도 있겠네요.
01:40:08또한 일부뿐만 아니라 모든 개발자가 소프트웨어 아키텍처를 더 잘 다뤄야 하는 방향으로 바뀔 수도 있고요.
01:40:18제품 책임자와 통합될 가능성도 분명 있지만, 예측하기 너무 어렵기에 확답은 피하고 싶네요.
01:40:30그건 그렇고 당연히 변화하고 있습니다.
01:40:35선택한 것들을 적어주실 수 있나요?
01:40:37그건 시간이 좀 걸릴 텐데, 딱 정해진 '최고의 선택' 같은 건 없어요.
01:40:41그리고 스트리밍 영상은 온라인에 남아있을 겁니다.
01:40:44방송 끝나고 다시 볼 수 있으니 문제없을 거예요.
01:40:49코드를 직접 손으로 짜는 게 이제 구시대적인가요?
01:40:51네, 그렇게 생각합니다.
01:40:52안타깝지만 앞서 공유했던 내용이죠.
01:40:54저는 그런 흐름을 좋아했었어요.
01:40:55코드에 몰입할 수 있는 그 과정을 좋아했죠.
01:40:59아직도 직접 코드를 짜기도 하지만, 대부분 버그 수정이나 변경, 혹은 에이전트를 시작하기 위한 초기 코드를 작성할 때뿐입니다.
01:41:09하지만 규모가 큰 프로젝트를 손으로 직접 코딩하는 시대는 지났다고 봅니다.
01:41:15FFMPEG처럼 직접 작성한 어셈블리 코드가 필요한 틈새 분야가 있을 순 있는데, 그런 건 AI가 아직 잘 못하기 때문이겠죠.
01:41:26하지만 많은 경우에 이제 구시대적인 방식이 된 것 같습니다.
01:41:28코드 규칙, 아키텍처, 코드 표준을 설명하는 강의는 어떨까요?
01:41:36네, 아이디어가 정말 많아요.
01:41:38다 하는 건 불가능하지만, 이런 근본적인 내용들, 아키텍처나 시스템 설계 결정, 모든 개발자가 알아야 할 핵심 개념들에 대한 강의를 꼭 만들고 싶습니다.
01:41:50해싱(Hashing)이나 암호화 같은 기본적인 것들이요.
01:41:54아이디어는 정말 많아요.
01:41:55언제나 그렇듯 시간이 가장 큰 문제지만, 확실히 더 많이 만들고 싶네요.
01:42:04정말 훌륭한 세션이네요.
01:42:05나중에 처음부터 다시 볼게요.
01:42:06네, 꼭 그러세요.
01:42:07녹화본은 말씀드린 대로 계속 올라와 있을 겁니다.
01:42:09그러니 나중에라도 내일이라도 원할 때 다시 보세요.
01:42:13네, 질문 목록으로 다시 돌아가서 마저 답변해 드리고, 나중에 채팅창 내용을 더 살펴볼게요.
01:42:30대부분의 궁금증은 해결된 것 같고, 전반적인 주제는 꽤 명확한 것 같습니다.
01:42:34마지막으로, AI 에이전트 부분인데, 어떤 에이전트인지가 중요한 게 아닙니다.
01:42:39앞서 저는 개인적으로 Pi를 많이 좋아한다고 말했고, 이에 대한 강의도 준비 중입니다. 혹시 아직 언급 안 했더라면요.
01:42:46결국 그게 중요한 건 아니에요.
01:42:49분명한 건, 미래는 AI가 엄청난 양의 코드를 생성하고 AI가 코딩을 지원하는 세상이라는 겁니다. AI를 전혀 쓰지 않을 수도 있겠지만요.
01:43:06진짜 소프트웨어를 위한 '바이브 코딩(Vibe coding)'이 아니라 AI 지원 코딩이죠. 물론 모두가 그렇게 믿어야 하는 건 아닙니다.
01:43:13일부 사람들이 말하는 것과 달리, AI 에이전트와 모델이 스스로 모든 걸 할 수 있는 수준은 전혀 아니기에 AI가 어디까지 발전할지는 아무도 장담할 수 없죠.
01:43:26하지만 중요한 건 사실이고, Cloud Code든 Codex든, Pi, AMP, Google 도구 등 최근의 것들을 사용할 수 있습니다.
01:43:36그들이 내놓고 없애는 도구들을 다 추적할 수는 없지만, 그게 중요한 건 아닙니다.
01:43:43가장 중요한 건 직접 한번 시도해 보는 것입니다. 어떤 분들은 AI에 전혀 설득되지 않기도 하니까요.
01:43:541~2년 전의 좋지 않았던 경험 때문에요. 하지만 도구들은 분명히 발전했습니다.
01:43:59모든 것에 AI를 사용할 필요는 없지만, 충분히 유용한 결과를 얻을 수 있으니 꼭 한번 시도해 보시길 권장합니다.
01:44:09구독이 필요할 거고 좋은 모델을 쓰고 싶겠지만, 앞서 언급했듯이 Open Router 같은 곳을 통해 Anthropic 모델보다 훨씬 저렴하게 GLM 5.2 같은 모델들을 사용할 수 있죠.
01:44:27그게 중요한 부분이라고 생각합니다.
01:44:29저도 요즘 코딩할 때 대부분 AI 에이전트를 사용하고 있고, 직접 시도해 보는 게 정말 중요하다고 생각해요.
01:44:39그리고 어떤 에이전트를 사용하든, 미리 공부하거나 강의를 듣는 게 중요합니다.
01:44:45저도 Cloud Code 강의와 곧 나올 Pi 강의가 있지만, 꼭 강의를 안 듣더라도 에이전트가 어떤 기능을 제공하는지 이해하기 위해 몇 분 정도 시간을 투자하세요.
01:44:57예를 들어, Pi는 자체적으로 새로운 기능을 확장할 수 있는 능력이 있고 그 기능이 아주 뛰어나다는 핵심적인 특징이 있습니다.
01:45:09그게 Pi를 아주 강력하게 만들죠.
01:45:11Codex는 데스크톱 앱이 있지만, Pi는 앱이 없습니다.
01:45:15그런 게 중요하다면 Codex를 사용하고 싶을 수도 있겠죠. Pi를 위한 오픈 소스 솔루션들도 찾아볼 수는 있겠지만요.
01:45:23하지만 분명 공부할 가치가 있습니다.
01:45:26설정을 다룰 줄 알고 본인 입맛에 맞게 조정하는 것도 중요합니다. 과거의 IDE처럼 말이죠. 저도 여전히 코드 에디터나 IDE를 사용하지만, 이제는 다르게 사용합니다.
01:45:41대부분 코드 뷰어와 편집기 용도로요. 아무튼, 편안하게 일할 수 있는 환경을 구축하는 것은 중요한데, 그 환경이 너무 빨리 변하고 있어서 여기저기서 새로운 것을 시도하며 최신 상태를 유지하는 게 꽤 중요하다고 봅니다.
01:46:01다른 코딩 에이전트를 시도해 보고, 몇 달마다 변경 로그를 읽어보며 무엇이 바뀌었는지 확인하세요. 그리고 지금 당장 모든 걸 사용해야 한다는 압박감을 느끼지 않는 것도 중요합니다.
01:46:16예를 들어 Claude Code는 매일 새로운 기능을 쏟아내죠. Claude 디자인, 슬랙(Slack) 안에서 Claude를 사용하는 Claude 태그 등, Claude 코드를 원격으로 제어하는 10가지 방법들을 강의에서 다 다뤘지만, 압도당하기 쉬우니 그렇게 느끼지 않아도 됩니다.
01:46:45이런 기능들 중 다수는 사실 틈새 기능이거나 마케팅용일 뿐입니다. 핵심은 AI를 사용하는 것, 올바른 컨텍스트를 제공하는 법을 배우는 것, AI가 제대로 작동하도록 제어하는 것입니다. 모바일 폰으로 AI를 제어할 수 있느냐 아니냐는 사실 저조차도 전혀 하지 않는, fancy한 기능일 뿐입니다.
01:47:12그래서 압도당한다고 느껴질 수 있지만, 그렇게 느끼지 않는 것이 중요하다고 생각합니다.
01:47:25음, 주짓수 강의는 없냐고요? 네, 없어요. 다뤄본 적이 없어서요. ELK 스택이나 엘라스틱 서치도 마찬가지고요. 전문가가 아니라서 공유할 게 없네요. 죄송합니다.
01:47:44개인 프로젝트를 출시하고 싶은데 책임감이 두렵고, 사용자 데이터 보안 공격, 특히 결제 기능을 넣을까 봐 무섭습니다.
01:47:51네, 결제 기능은 좋은 지적이에요.
01:47:53저는 결제 서비스로 폴라(Polar)나 스트라이프(Stripe)를 추천합니다. 폴라는 매출 기록 관리(Merchant of Record)를 해줘서 판매세 같은 걸 처리해 주는데, 독일 같은 곳에 산다면 아주 중요하죠.
01:48:17게다가 요즘은 어떤 상황에서는 스트라이프보다 더 저렴하기도 합니다.
01:48:23결제를 통합하고 책임의 일부를 덜어내는 데는 정말 훌륭할 수 있죠.
01:48:29그래서 폴라는 확실히 추천합니다.
01:48:32그리고 뭘 출시하는 것에 대해서는 그냥 하세요.
01:48:36압도적일 수 있다는 건 이해하지만, AI를 보안 감사에 사용할 수 있습니다. 100% 보호는 안 되겠지만 괜찮은 추가 레이어가 되어주죠.
01:48:46데이터베이스를 백업해서 사용자 데이터를 잃지 않도록, 혹은 최소한 손실을 줄이도록 하세요.
01:48:54꼭 잘 구축된 폴라나 스트라이프 같은 결제 제공업체를 사용하세요. 데이터가 여러분의 서버가 아닌 그들의 서버에 저장되므로 안전합니다.
01:49:06그리고 일단 그냥 시작하세요.
01:49:09처음에는 사용자도 없을 테니까요.
01:49:11주된 문제는 공격을 받거나 데이터를 잃는 게 아니라, 사용자를 모으는 것이 될 겁니다.
01:49:17공격과 관련해서는 클라우드플레어(Cloudflare)를 호스팅이 아닌 서비스 앞단의 CDN으로 사용해서 DDoS 방어 기능을 쓰세요. 그리고 그냥 하세요.
01:49:30잘못될 수 있는 일은 정말 많습니다.
01:49:33하지만 실제로는 거의 일어나지 않죠.
01:49:36그러니까요.
01:49:37그게 제가 드리는 제 생각입니다.
01:49:39네, 시스템 설계 강의도 계획 중입니다.
01:49:43Convex에서 SurrealDB로 전환하셨군요.
01:49:47들어본 적은 있지만 솔직히 아예 써보질 않아서요.
01:49:51뭐라고 말씀드리기 어렵네요.
01:49:53요즘은 관리형 데이터베이스 제품이 정말 너무 많아요.
01:49:59지금 그 사이트 때문에 탭이 멈추는 것 같네요.
01:50:03잘 모르겠지만.
01:50:04그래도요.
01:50:04아직 들어보지 못했거나 사용해 보지 못했다고 해야겠네요.
01:50:09맥스, 감사하다는 말씀을 드리고 싶어요.
01:50:109년 전 당신의 강의로 웹 개발을 시작했습니다.
01:50:12어제 마이크로소프트에서 시니어 풀스택 개발자로 채용 제안을 받았습니다.
01:50:15와우.
01:50:16대단하네요.
01:50:17정말 놀라워요.
01:50:18채용 축하드리고 정말 감사합니다.
01:50:21여러분의 여정에 제가 함께할 수 있었고 제 강의가 도움이 되어 정말 기쁩니다.
01:50:25샤라웃(shout-out) 해 주셔서 감사하고, 다시 한번 취업 축하드려요.
01:50:30중국 오픈 소스 AI 모델이 AI 경쟁에서 이길까요?
01:50:34이길지는 모르겠지만, 만약 트럼프 행정부가 자국 최고 모델 사용자를 미국 시민권자로 제한한다면, 저 같은 사람들은 사용할 수 없게 되니까요.
01:50:53그런 길로 간다면 중국 오픈 모델이 확실히 이길 겁니다. 미국 최고 모델을 쓸 수 없다면 우리는 무엇을 쓰겠어요?
01:51:04저는 더 나아질 중국 최고 모델을 사용할 것이고, 전 세계 많은 사람들이 그렇게 할 겁니다.
01:51:11만약 중국마저 모델을 잠가버린다면, 저는 정말 곤란해집니다. 유럽은 이 문제에 대해서 좀 부족하거든요.
01:51:19하지만 지금으로선 미국이 하는 대로 두면 중국이 이길 수도 있다고 봅니다. 적어도 계속해서 모델 접근을 제한한다면요.
01:51:30하지만 솔직히 말해서 아직은 너무 이른 판단입니다.
01:51:34이제 코더가 아니라 소프트웨어 엔지니어의 시대네요.
01:51:37어떻게 생각하세요?
01:51:40네.
01:51:42순수 코드 생성의 시대는 확실히 끝났다고 앞서 말했죠.
01:51:46반면에 소프트웨어 엔지니어링은 여전히 중요하고 앞으로도 중요할 겁니다.
01:51:51맥스, 인사이트 고마워요.
01:51:52듣는 건 언제나 즐겁네요.
01:51:53정말 너무 감사합니다.
01:51:54멋진 피드백 주시고 함께해 주셔서 정말 감사합니다.
01:51:58저에게 큰 힘이 돼요.
01:52:00구글 검색은 줄고 AI 채팅은 늘어나서 웹사이트는 구시대적인 것이 될까요?
01:52:05웹 개발은 변할 겁니다.
01:52:06네.
01:52:07웹사이트가 구시대적인 것이 되진 않을 겁니다. 훨씬 전에 말했듯이, 모든 서비스를 오직 채팅으로만 소통하는 미래는 믿지 않아요.
01:52:17왜냐하면 채팅은 여러분이 하고 싶은 모든 것에 대한 최고의 인터페이스가 아니기 때문이죠.
01:52:24많은 상호작용에 있어서 목적에 맞게 구축된 인터페이스가 채팅보다 더 낫습니다.
01:52:29두 숫자를 더하고 싶을 때 그냥 타이핑하는 것보다, 엑셀 시트를 만드는 게 훨씬 나은 것과 같은 바보 같은 예시일 수도 있지만 말이죠.
01:52:43더하고 싶은 숫자들이 적힌 행이 있다면, 그걸 AI에게 말로 설명하는 것보다는요.
01:52:51슬라이드를 만들 때도 위치를 조정하고 싶다면 채팅으로 설명하는 것보다 직접 박스를 드래그하는 게 훨씬 나을 수 있습니다.
01:52:59그래서 웹앱을 포함한 웹사이트나 앱 전반은 계속 중요할 겁니다.
01:53:05변화는 있을 거고, 콘텐츠는 분명히 변하고 있습니다.
01:53:08구글 검색량이 줄어들고 있다는 점엔 100% 동의합니다.
01:53:12모든 검색 결과가 채팅 요약으로 들어가고 사람들이 웹사이트로 넘어오지 않는 건 저에게도 큰 문제입니다.
01:53:19앞으로 어떻게 될지 두고 봐야겠지만, 웹앱은 계속 존재할 거라고 봅니다.
01:53:26몇 살이세요?
01:53:27항상 지식으로 빛나시네요.
01:53:28정말 너무 감사합니다.
01:53:29물론 제가 모르는 것도 정말 많아요.
01:53:33매일 다루는 내용들이지만, 저는 37살입니다.
01:53:39제발 영상 올리고 라이브 스트리밍하는 노력을 멈추지 마세요.
01:53:42당신은 최고예요.
01:53:42정말 너무 감사합니다.
01:53:44네, 계속할 거예요.
01:53:45계속 강의와 영상을 만들고, 아카다민(Akadamine) 채널도 계속할 겁니다.
01:53:49멈추지 않아요.
01:53:51다만 더 많은 시간을 찾아야 할 뿐이죠.
01:53:53네, 계속 해나갈 겁니다.
01:53:54모두 정말 감사합니다. 어디 안 가요.
01:53:58라이브 스트리밍도 마찬가지고요.
01:54:01언제나 그렇듯 목요일 이 시간에 라이브 스트리밍을 계획하고 있어요.
01:54:05매주 목요일마다 다 지키진 못하지만 최선을 다하고 있습니다.
01:54:09유료 결제 장벽이 두 세계, 두 종의 코더를 만들까 봐 두렵습니다.
01:54:12네, 확실히요.
01:54:14비용 문제와 이제는 코드를 시간이 아니라 돈으로 생성한다는 사실은 어느 정도까지는,
01:54:23앞서 언급한 제한 사항들과 마찬가지로, 앞으로 어떻게 전개될지 지켜보는 게 흥미로울 겁니다.
01:54:39AI 코드가 미래에 라이선스 위반 문제가 될 거라고 느끼시나요?
01:54:45글쎄요, 전반적으로는 아닙니다.
01:54:47하지만 AI를 사용해서 맹목적으로 뭔가를 복사했는데 결국 복사물이라는 게 증명된다면, AI 사용 여부와 상관없이 분명 법적인 문제에 휘말릴 수 있습니다.
01:55:03로컬 우선이 미래입니다.
01:55:06AI와 관련해서는, 저는 로컬 모델의 열렬한 팬입니다.
01:55:09코딩 측면에서는 아직 갈 길이 멀지만, 모델이 더 작아지거나 로컬 하드웨어가 충분히 좋아지려면 기술적인 돌파구가 필요할 겁니다.
01:55:18하지만 로컬 방식을 100% 지지합니다.
01:55:21오프라인에서 뭔가를 할 수 있다는 건 정말 놀라운 일이죠.
01:55:30Polar는 정말 최고예요.
01:55:31덕분에 첫 매출을 올렸어요.
01:55:32축하합니다.
01:55:36Flutter 강의 고마워요.
01:55:38수강해 주셔서 감사합니다. 도움이 되었다니 기쁘네요.
01:55:48좋은 댓글이 정말 많네요.
01:55:49모두 정말 감사합니다.
01:55:51네, 마지막으로 확인했을 때 Polar가 Stripe보다 훨씬 저렴했어요.
01:55:54그게 중요하죠.
01:55:55Stripe는 숨겨진 수수료가 많거든요.
01:55:572.9%에 30센트 정도 추가되는 기본 수수료가 있긴 한데,
01:56:03다른 모든 것들에 대해서도 추가 비용이 발생하죠.
01:56:06그래서 갑자기 6~7%를 내게 되기도 해요.
01:56:08Polar의 경우, 최근에 가격 모델을 바꾼 거로 아는데요.
01:56:12저는 아직 예전 모델을 사용 중이에요.
01:56:14하지만 Polar는 대략 4~5% 정도의 수수료를 내는 거로 알고 있어요.
01:56:23현재 이용 중인 월간 플랜에 따라 더 낮을 수도 있고요.
01:56:26어쨌든 Stripe보다 저렴한 경우가 많습니다.
01:56:29저도 같은 경험을 했습니다.
01:56:31프랑스에서 시청 중입니다, 모든 조언 감사합니다.
01:56:35프랑스에도 인사 전합니다.
01:56:36정말 감사합니다.
01:56:38네, 앞서 언급했듯이 모두 정말 감사합니다.
01:56:45사실 이제 가봐야 할 시간이라서요.
01:56:48마지막 질문들에만 답하고 마무리하도록 하겠습니다.
01:56:53PostHoc, Datadoc 질문이네요.
01:56:54특별히 선호하는 건 없습니다.
01:56:57죄송해요.
01:56:58서비스들은 다 알고 있지만,
01:57:00실제로 사용하고 있지는 않아서요.
01:57:02공유할 만한 내용이 없네요.
01:57:07처음 웹 개발을 배우게 된 계기가 무엇인가요?
01:57:10어쩌다 보니 시작하게 됐어요.
01:57:12그 당시에는 워크래프트 3 웹사이트를 만들고 싶었거든요.
01:57:15워크래프트 3를 좋아했으니까요.
01:57:17그래서 관련 웹사이트를 직접 만들어보고 싶었고,
01:57:18그게 HTML과 인라인 스타일을 배우게 된 계기였죠.
01:57:22보기엔 형편없었지만요.
01:57:232002년, 제 첫걸음은 그렇게 시작되었습니다.
01:57:28잘 모르겠네요.
01:57:29음.
01:57:31그게 제 웹 개발의 첫 단계였습니다.
01:57:39자,
01:57:40함께해 주신 여러분, 정말 감사합니다.
01:57:44멋진 댓글도 감사드리고요.
01:57:45다양한 의견들도 고마워요.
01:57:46정말 즐거운 방송이었습니다.
01:57:47저도 많이 즐거웠어요.
01:57:48도움이 되었길 바랍니다.
01:57:49녹화본은 그대로 남겨둘게요.
01:57:51다음 주 목요일에 다시 돌아오겠습니다.
01:57:54네.
01:57:54일정 괜찮고요.
01:57:55달력에 아무것도 없네요.
01:57:56그러니 다음 주 목요일에 다시 뵙겠습니다.
01:58:00모두 감사합니다.
01:58:02즐거운 하루, 밤, 저녁, 아침 보내세요.
01:58:04지금 계신 곳의 시간에 맞춰서요.
01:58:06네.
01:58:08다음 방송에서 만나요.
01:58:10혹시 놓치고 싶지 않으시다면,
01:58:11말씀드렸던 것처럼,
01:58:12Discord 커뮤니티에 참여하시거나,
01:58:14뉴스레터를 구독해 주세요.
01:58:17Discord를 통해 방송 일정을 모두 공유합니다.
01:58:20네.
01:58:21그럼 미래에 다시 만나길 바랍니다.
01:58:24안녕히 계세요.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기