1억 가치 앱 바이브 코딩으로 만들기 라이브 LIVE (Step by Step)

https://www.youtube.com/watch?v=7DwDddzwoVY

0:00 No, you over sensitive, emotional, silly Sally, take your Xanax pills. 아니, 당신은 너무 예민하고 감정적이며, 바보 같은 샐리야, 진정하고 약을 챙겨 먹어. 0:03 Calm down. 진정하세요. 0:04 The title of this video, not ClickBait. 이 영상의 제목은 클릭베이트가 아닙니다. 0:05 I have SaaS companies that are generating me well over $100,000 per day. 저는 하루에 100,000달러 이상을 벌어들이는 SaaS 회사를 운영하고 있습니다. 0:09 And in this video I'm going to show you how as a CEO and a non technical founder, how I vibe code the shit out of these. 그리고 이 영상에서는 CEO이자 비기술 창립자로서, 제가 어떻게 코딩을 통해 이 모든 것을 해냈는지 보여드리겠습니다. 0:15 And look, I know you as my viewer, you might have been wondering the past 45, 60 days, why have I been making videos? 그리고 여러분, 제가 여러분의 시청자로서, 지난 45일, 60일 동안 왜 영상을 만들고 있었는지 궁금해하셨을 것 같아요. 0:21 Where have I been? 저는 어디에 있었나요? 0:22 And the God's honest truth is, once Opus 4.5 dropped, it unlocked an ability to code and add things to my SaaS companies that I never had before. 정직하게 말씀드리자면, Opus 4.5가 출시된 이후로, 저는 이전에는 할 수 없었던 SaaS 회사에 코딩하고 기능을 추가할 수 있는 능력을 얻었습니다. 0:29 This is equivalent to giving a college kid who's just been getting drun on beer the last couple of years a juice energy drink. 이건 몇 년 동안 맥주에 취해 있던 대학생에게 에너지 음료를 주는 것과 같습니다. 0:35 If you guys remember those things. 여러분이 그걸 기억하신다면요. 0:36 It was, it was caffeine mixed with excessive amounts of alcohol. 그건 카페인과 과도한 양의 알코올이 섞인 음료였습니다. 0:39 You would get wasted off one. 하나만 마셔도 취했죠. 0:41 It was, it was wonderful. 정말 멋졌습니다. 0:43 And just like discovering Opus 4.5, it was the point where code from LLMs has hit the point where as a non technical person, you can build substantial, significant improvements to your SaaS company or just Vibe code a company from scratch if you know what you're doing. Opus 4.5를 발견한 것처럼, LLM의 코드가 비기술자도 SaaS 회사에 실질적이고 중요한 개선을 할 수 있는 지점에 도달한 것입니다. 또는 제대로 알고 있다면 회사를 처음부터 Vibe 코드로 만들 수 있습니다. 1:00 And in this video I'm going to be breaking down my entire process, process for doing that at my companies and where we've made huge giant leaps with my companies to achieve this. 이번 영상에서는 저의 전체 프로세스, 즉 저희 회사에서 이를 수행하는 방법과 저희 회사가 이룬 큰 도약에 대해 설명드리겠습니다. 1:10 On top of this, I'm going to be breaking down how you should be doing this if you're a new founder and you actually want the code from scratch and how to work with your developers, or if you're a developer, how you should be working in your systems right now. 이와 더불어, 새로운 창립자라면 어떻게 처음부터 코딩을 해야 하는지, 개발자와 어떻게 협력해야 하는지, 또는 개발자라면 현재 시스템에서 어떻게 작업해야 하는지에 대해 설명드리겠습니다. 1:21 And yes, what I'm going to do is the typical Vibe coding CEO is going to be telling you as a person and an engineer how you should be running your code if this video wasn't obnoxious enough. 그리고 네, 제가 할 것은 전형적인 Vibe 코딩 CEO로서 여러분에게 어떻게 코드를 운영해야 하는지 이야기하는 것입니다. 이 영상이 충분히 시끄럽지 않았다면요. 1:31 And so that's it. 그게 전부입니다. 1:32 We're going to go through the entire process, start to finish. 우리는 전체 프로세스를 처음부터 끝까지 살펴볼 것입니다. 1:34 Here it is. 여기 있습니다. 1:34 And everything we're going to go through begin. 그리고 우리가 겪게 될 모든 것이 시작됩니다. 1:36 So first off, what is Vibe coding and agentic coding and does it, can you actually code? 먼저, Vibe 코딩과 에이전틱 코딩이 무엇인지, 그리고 실제로 코딩이 가능한지에 대해 이야기해보겠습니다. 1:40 Can you actually do this on production software? 이걸 실제 소프트웨어에서 할 수 있을까요? 1:43 Can you actually do this to make money? 이걸 통해 돈을 벌 수 있을까요? 1:44 Not these little stupid shitty apps you see everybody doing. 모두가 하는 그런 작은 쓸모없는 앱이 아닙니다. 1:46 Not to organize your email. 이메일을 정리하는 것도 아닙니다. 1:48 Can this be done at large scale or to build your first company and start making money through it? 이걸 대규모로 할 수 있을까요, 아니면 첫 회사를 세우고 이를 통해 돈을 벌 수 있을까요? 1:52 The answer is yes, with caveats. 답은 예, 단 조건이 있습니다. 1:55 Right now, what people think Vibe coding is is they're either in two camps. 현재 사람들이 Vibe 코딩에 대해 생각하는 것은 두 가지 진영으로 나뉩니다. 1:59 One, they either think it's some useless, stupid silver spoon, preachy developer thing, they won't touch it kind of Vibe or your person who's screaming developers are engineers are over. 하나는 쓸모없고, 바보 같은 은수저 개발자 같은 것이라며 손도 대지 않겠다고 생각하는 사람들입니다. 2:10 No one needs developers ever again on Twitter. 트위터에서는 더 이상 개발자가 필요 없다고 외치는 사람들도 있습니다. 2:12 And both of these people are. 이 두 종류의 사람들은 모두 잘못된 것입니다. 2:14 They're both wrong. 둘 다 틀렸습니다. 2:14 I'm explaining to you why. 제가 왜 그런지 설명해드리겠습니다. 2:16 See, engineering is not dead. 보세요, 엔지니어링은 죽지 않았습니다. 2:18 And developing and needing engineers is definitely not dead either. 개발과 엔지니어가 필요한 것은 분명히 죽지 않았습니다. 2:22 You're not going to be replacing any engineers anytime soon because developing software still takes engineering, which is knowing how the architecture of the software goes together. 소프트웨어 개발은 여전히 엔지니어링을 필요로 하므로, 가까운 시일 내에 엔지니어를 대체할 수는 없습니다. 소프트웨어의 구조가 어떻게 구성되는지를 아는 것이 필요합니다. 2:30 I don't care if you have people building your house, which is the AI. AI가 당신의 집을 짓고 있다고 해도 상관없습니다. 2:33 You still need to know if you're the architect, how everything goes together and fits together. 당신이 건축가라면 모든 것이 어떻게 조화롭게 어우러지는지 알아야 합니다. 2:37 You need to be able to plan, you need to be able to structure your ideas. 계획을 세울 수 있어야 하고, 아이디어를 구조화할 수 있어야 합니다. 2:39 You need to be able to plan how things are going to work and fit together in the system that you're building. 당신이 만들고 있는 시스템에서 사물이 어떻게 작동하고 서로 맞물릴지를 계획할 수 있어야 합니다. 2:44 So what does this mean? 그렇다면 이게 무슨 의미인가요? 2:45 I don't think vibe coding is capable of building or adding anything to your companies. 저는 vibe coding이 당신의 회사에 무엇이든 구축하거나 추가할 수 있다고 생각하지 않습니다. 2:49 I don't like the term vibe coding because you really don't know what the you're doing and you're just going off vibes. 저는 vibe coding이라는 용어가 마음에 들지 않는데, 왜냐하면 당신이 하고 있는 일을 정말로 알지 못하고 단지 느낌에 따라 진행하고 있기 때문입니다. 2:54 I do like the term agentic engineering, which is just basically a fancier way to say vibe coding. 저는 agentic engineering이라는 용어는 좋아하는데, 이는 기본적으로 vibe coding을 더 멋지게 표현한 것입니다. 2:59 It makes me feel better about myself. 그렇게 하면 제 자신이 더 나아지는 느낌이 듭니다. 3:00 But in truth, what we're doing is we're going to be doing the same engineering that you see done in software, the same processes to come to planning, building and putting it all together. 하지만 사실 우리가 하는 것은 소프트웨어에서 이루어지는 것과 같은 공학을 하는 것이며, 계획하고 구축하고 모든 것을 조합하는 동일한 프로세스입니다. 3:09 But we're going to be using agents to code a lot of it and agents to review the code. 하지만 우리는 많은 부분을 코드화하기 위해 에이전트를 사용하고, 코드를 검토하기 위해 에이전트를 사용할 것입니다. 3:13 And you can do massive amounts of improvements to live apps, large apps. 그리고 실시간 앱, 대규모 앱에 대해 대규모 개선을 할 수 있습니다. 3:17 And if you understand how to put this together in your softwares and the strategy behind it, you can do it on large production apps, you can use it to start apps from scratch and start billing and running a completely legitimate software company. 이것을 당신의 소프트웨어에 어떻게 조합하는지, 그리고 그 뒤에 있는 전략을 이해한다면, 대규모 생산 앱에서 사용할 수 있고, 처음부터 앱을 시작하고 완전히 합법적인 소프트웨어 회사를 운영할 수 있습니다. 3:29 And you can use it to make massive improvements to how your company works as well. 그리고 이것을 사용하여 당신의 회사가 작동하는 방식에 대해 대규모 개선을 할 수 있습니다. 3:32 I'm going to be showing you examples of all these right now. 지금 이 모든 예제를 보여드리겠습니다. 3:35 So look, this isn't going to be a how to to use Claude and Opus and everything that comes with it. 그러니까, 이건 Claude와 Opus 및 그와 관련된 모든 것을 사용하는 방법에 대한 것이 아닙니다. 3:41 I will make one of those if you guys really want. 여러분이 정말 원하신다면 그런 영상을 하나 만들겠습니다. 3:43 I just feel there are better videos on it on YouTube. 저는 유튜브에 더 좋은 영상이 있다고 느낍니다. 3:47 And the more important thing to using Opus or any of the LLMs, it doesn't matter which ones you're using, is understanding the process that you go through with the LLMs to plan, structure and then develop your apps. Opus나 어떤 LLM을 사용하는 것보다 더 중요한 것은, 어떤 LLM을 사용하든 간에, LLM과 함께 계획하고 구조화한 다음 앱을 개발하는 과정에 대한 이해입니다. 4:00 The, the process is what matters. 그 과정이 중요합니다. 4:01 It's the conversation you're having with lms it isn't the specific techniques you're using from my point of view, which is not someone who's doing massive. 당신이 LLM과 나누는 대화가 중요하며, 제가 보는 관점에서는 특정 기술이 중요하지 않습니다. 4:09 There's the super genius engineers out there, okay, and there's the people that are building all sorts of crazy technical stuff. 세상에는 슈퍼 천재 엔지니어들이 있고, 다양한 기술적인 것들을 구축하는 사람들이 있습니다. 4:15 If you're building some new functional form of technology that's able to send people back in time, please disregard what I'm saying here. 만약 당신이 사람들을 과거로 보내는 새로운 기능의 기술을 구축하고 있다면, 제가 하는 말을 무시해 주세요. 4:21 But for the most part, if you're trying to get results with vibe coding or what I'm going to refer to as agentic coding to sound scientific and smart for the rest of the video, you don't need to be doing all these technical crazy things. 하지만 대체로, 바이브 코딩이나 제가 과학적이고 똑똑하게 들리게 하려고 부르는 에이전틱 코딩으로 결과를 얻으려 한다면, 이런 기술적인 복잡한 것들을 할 필요는 없습니다. 4:32 If you're going and browsing around, you're seeing people running eight different windows at once. 주변을 둘러보면, 여러 사람이 동시에 여덟 개의 창을 열고 있는 모습을 보게 될 것입니다. 4:36 You're going to see people talk about RALPH Loops and you're going to be seeing talk about their other agents and their skill set up and their building steps. RALPH 루프에 대해 이야기하는 사람들을 보게 될 것이고, 그들의 다른 에이전트와 기술 세트, 그리고 구축 단계에 대한 이야기를 보게 될 것입니다. 4:42 And the truth is, if you just understand how the process works and how context windows work and how overall the thing's going to be thinking and putting things together, you don't need to be doing complicated anything. 사실, 과정이 어떻게 작동하는지와 컨텍스트 윈도우가 어떻게 작동하는지를 이해하고, 전반적으로 이 시스템이 어떻게 생각하고 사물을 조합하는지를 이해하면, 복잡한 것을 할 필요는 없습니다. 4:52 And in fact I think the complicated anything's make it even worse because as you're building something, it's like if you're building out a house, you need to go one step at a time and you don't need to be doing 5,000 different things all at once. 사실, 복잡한 것들은 오히려 더 나쁘게 만들 수 있다고 생각합니다. 무언가를 구축할 때, 마치 집을 짓는 것처럼 한 번에 한 단계씩 진행해야 하며, 동시에 5,000가지 일을 할 필요는 없습니다. 5:02 And yes, there's all sorts of automations and clever shit, but you don't need the clever shit. 물론 다양한 자동화와 똑똑한 방법들이 있지만, 그런 똑똑한 방법이 꼭 필요하지는 않습니다. 5:06 You need to be able to carefully think about what you're doing. 당신이 하고 있는 일을 신중하게 생각할 수 있어야 합니다. 5:08 Because when you're building these things, it often doesn't require this thing to sit there for 12 hours in code. 이런 것들을 만들 때, 코드에서 12시간 동안 기다릴 필요는 없습니다. 5:12 You're going to work with it, it's going to do it for 20 minutes and you're going to come back. 당신은 그것과 함께 작업할 것이고, 20분 동안 작동한 후 다시 돌아올 것입니다. 5:16 So first let's back up to that right there. 그러니 먼저 그 점으로 돌아가 보겠습니다. 5:18 We don't want to get into the super technicalities of this. 우리는 이 문제의 기술적인 부분에 깊이 들어가고 싶지 않습니다. 5:21 I want to show you the overview and the thought process I use and then you can of course go figure out how to learn how to use cloud code or something on your own. 저는 여러분에게 제가 사용하는 개요와 사고 과정을 보여주고 싶습니다. 그리고 여러분은 물론 클라우드 코드를 사용하는 방법을 스스로 배울 수 있습니다. 5:26 If you're not using it. 사용하지 않는다면요. 5:27 I don't. 저는 사용하지 않습니다. 5:28 If you're a founder right now and you're not the ability, you don't have the ability to use cloud code or Opus or anything like that. 현재 창업자이신데 클라우드 코드나 Opus 같은 것을 사용할 수 없다면, 정말 뒤처져 있는 것입니다. 5:33 You really are just behind. 그러니 준비를 잘 하셔야 합니다. 5:34 So you should get your shit together. 하지만 그 점을 감안하더라도, 우리가 이 내용을 다루면서 어떻게 적용할 것인지 이해해야 합니다. 대규모 생산 소프트웨어를 열어보는 것은 아닙니다. 5:36 But that being said, you need to understand as we get into this how you're going to be applying this, you're not going to be cracking open your large production software. 저는 Hiros를 열고, VS 코드와 Claude에 넣고 막 작업하는 것은 아닙니다. 5:46 I'm not going to be cracking open Hiros just booting it up, throwing it in VS code and Claude and just going to town on the thing. 알겠습니까? 5:53 Okay? 5:53 That's not how I want to do it. 그렇게 하고 싶지는 않습니다. 5:54 And I also don't want to go to certain parts of the software and start coding on it. 그리고 특정 소프트웨어 부분에 가서 코딩을 시작하고 싶지도 않습니다. 5:57 I also don't want to be messing with the general software overall. 전반적인 소프트웨어와 관련해서도 간섭하고 싶지 않습니다. 6:00 Because what you're going to see when you're working with really large apps is the problem with really large apps isn't the fact that you can't write code fast enough. 정말 큰 앱을 다룰 때 보게 될 문제는 코드 속도를 빨리 쓸 수 없다는 것이 아닙니다. 6:08 It's the fact that the code needs to be reviewed and every code affects every other part of the code of the app. 문제는 코드가 검토되어야 하고, 모든 코드가 앱의 다른 부분에 영향을 미친다는 것입니다. 6:12 And it has to be understood how it goes in there. 그것이 어떻게 연결되는지를 이해해야 합니다. 6:14 And even if the code you pass doesn't have bugs in it, so you don't pass bugs for two, three months, the problem is slowly people stop understanding the code and they slowly start stop understanding how everything fits together. 그리고 당신이 전달하는 코드에 버그가 없더라도, 두세 달 동안 버그가 없더라도, 문제는 사람들이 점점 코드를 이해하지 못하게 되고 모든 것이 어떻게 맞물리는지를 이해하지 못하게 된다는 것입니다. 6:24 So again, even if you're coding with LLMs or you're coding by hand, the main issue you're going to run into with large apps, that doesn't matter whether which route you're taking is making sure that architecture and everything you're building fits on top of each other. 그러므로 다시 말하지만, LLM으로 코딩하든 손으로 코딩하든, 큰 앱에서 마주하게 될 주요 문제는 어떤 경로를 선택하든지 간에 아키텍처와 당신이 만드는 모든 것이 서로 맞물리도록 하는 것입니다. 6:38 And you're going to run into the same issue with LMS if you're using it to write code, because it's like you're trying to build a Lego castle and you're not thinking about what's going on this part of the Lego castle, or maybe someone's building in the Lego castle over here and they're not considering what's happening over here. LMS를 사용하여 코드를 작성할 때도 같은 문제에 직면하게 될 것입니다. 마치 레고 성을 만들고 있는데, 레고 성의 이 부분에서 무슨 일이 일어나고 있는지 생각하지 않고, 혹은 누군가가 여기에서 레고 성을 만들고 있는데 그 부분에서 무슨 일이 일어나고 있는지를 고려하지 않는 것과 같습니다. 6:51 And if you have two people building, even if they're working with the best AIs on earth, if they interject with it, they're not going to fit together. 두 사람이 함께 작업하더라도, 지구상에서 가장 좋은 AI를 사용하고 있다 하더라도, 서로 간섭하게 되면 잘 맞지 않을 것입니다. 6:56 And you do have a giant, big old problem, just like a normal code. 그리고 일반 코드와 마찬가지로 큰 문제가 발생하게 됩니다. 7:00 So again, you're still going to run into a lot of the large problems that you have at scale when it comes to coding by hand. 따라서 다시 말하지만, 손으로 코딩할 때 대규모에서 겪는 많은 큰 문제에 여전히 직면하게 될 것입니다. 7:05 And you really don't save that much time coding with AI unless you understand how to use it to give like huge, massive impact very quickly and segregate what you're doing from the rest of your product. AI로 코딩할 때 그렇게 많은 시간을 절약할 수 있는 것은 아닙니다. 빠르게 큰 영향을 주고 당신이 하는 일을 제품의 나머지 부분과 분리하는 방법을 이해해야 합니다. 7:17 So I need you to understand that rough little analysis I just gave you before you actually start talking about how we're going to be coding our apps. 그래서 우리가 앱을 코딩할 방법에 대해 이야기하기 전에 제가 방금 드린 간단한 분석을 이해해 주셨으면 합니다. 7:23 So in this example, I'm going to use one of my companies, Hros and we're doing about $40 million a year right there, cruising past that. 이 예시에서는 제 회사 중 하나인 Hros를 사용할 것이며, 우리는 연간 약 400억 원 정도를 벌고 있습니다. 7:29 We're growing about 30, 40% a year right now. 현재 연간 30%에서 40% 정도 성장하고 있습니다. 7:31 So it's going well. 그래서 잘 진행되고 있습니다. 7:32 Companies, it's a serious company. 이 회사는 진지한 회사입니다. 7:34 We're not, we're not selling ice cubes on the side of the road. 우리는 길가에서 얼음 조각을 팔고 있는 것이 아닙니다. 7:36 And at Highros, it's gotten to the point where I'm spending about half my day developing and engineering solutions for the product. Highros에서는 하루의 절반을 제품을 위한 솔루션 개발과 엔지니어링에 사용하고 있습니다. 7:43 It's actually just crazy. 정말 미친 것 같아요. 7:44 So that's one of the reasons I've been making videos, because we're getting so much shit done because of the huge breakthroughs in LLM and AI coding that just way more profitable and better for my time. 그래서 제가 영상을 만드는 이유 중 하나는 LLM과 AI 코딩의 큰 혁신 덕분에 많은 일을 해내고 있어서, 제 시간에 비해 훨씬 더 수익성이 높고 좋기 때문입니다. 7:53 Just be doing this all day. 이걸 하루 종일 하고 싶어요. 7:55 So I want to show you how I think about this at the company and how it's being used on a live, giant working service. 그래서 제가 회사에서 이 문제를 어떻게 생각하고 있는지, 그리고 이게 실제로 거대한 작업 서비스에서 어떻게 사용되고 있는지를 보여드리고 싶습니다. 8:01 You can take any of these and apply them to your existing businesses. 이 중 어떤 것이든 기존 비즈니스에 적용할 수 있습니다. 8:05 You can also use them to start another business from scratch. 또한 이를 바탕으로 새로운 비즈니스를 시작할 수도 있습니다. 8:07 There have been things I have coded up or agenda coded. 제가 코딩한 것들이나 의제 코딩한 것들이 있었습니다. 8:10 I'm just going to use the word coded and parentheses because I don't think I'm here writing JavaScript and building out my apps. 저는 그냥 '코딩'이라는 단어와 괄호를 사용할 건데, 제가 여기서 자바스크립트를 작성하고 앱을 만드는 건 아니라고 생각하기 때문입니다. 8:16 I think I'm Vibe coding. 저는 Vibe 코딩을 하고 있다고 생각합니다. 8:17 We're just going to say coding. 그냥 코딩이라고 하겠습니다. 8:18 Okay, I'm not going to say it anymore or explain the difference between them, but I've coded up things at hires that could be their own softwares by them themselves and I could easily start selling. 알겠습니다, 더 이상 말하지 않거나 둘의 차이를 설명하지는 않겠지만, 제가 만든 것들은 그들 스스로 소프트웨어가 될 수 있는 것들이고, 쉽게 판매를 시작할 수 있습니다. 8:27 My goal is to build a company that's making $100 million per year. 제 목표는 연간 1억 달러를 벌어들이는 회사를 만드는 것입니다. 8:30 So I'm not going to do that right now, but feel free to take these all away. 지금 당장은 그렇게 하지는 않겠지만, 이 모든 것을 마음껏 활용하세요. 8:33 So as we look at this right here, I want to talk about the three types of apps you can build. 그래서 여기서 이걸 보면서, 제가 만들 수 있는 세 가지 종류의 앱에 대해 이야기하고 싶습니다. 8:37 So the first thing you need to understand that Vibe coding gives you the ability to do at your companies is MVP things very fast and find the technical solutions that can be implemented in your software very fast. 그래서 Vibe 코딩이 여러분의 회사에서 할 수 있는 첫 번째 이해해야 할 점은 MVP를 매우 빠르게 만들고, 소프트웨어에 구현할 수 있는 기술적 솔루션을 매우 빠르게 찾는 것입니다. 8:48 So for example, if you're a product person, which I am at, my main job at High Risk is to think of the product, the designs and everything that's going to go there. 예를 들어, 만약 여러분이 제품 관련 사람이라면, 제가 High Risk에서 하는 주요 업무는 제품, 디자인 및 그곳에 들어갈 모든 것을 생각하는 것입니다. 8:55 You can think of a lot of things and how you want your product to work, but technically the things you think up, you're not always going to to know exactly if that's the way they're going to be put together and work. 여러 가지를 생각할 수 있고 제품이 어떻게 작동하길 원하는지에 대해 생각할 수 있지만, 기술적으로 여러분이 생각한 것들이 실제로 어떻게 조합되고 작동할지는 항상 정확히 알 수는 없습니다. 9:04 So for example, when you're building an AI agent bot or something that sends emails or manages some part of the company or captures code in some certain way, the code and everything puts together Your team's going to have to figure it out and encode it into your solution. 예를 들어, AI 에이전트 봇을 만들거나 이메일을 보내거나 회사의 일부를 관리하거나 특정 방식으로 코드를 캡처하는 것을 만들 때, 코드와 모든 것이 조합되어 여러분의 팀이 그것을 파악하고 솔루션에 인코딩해야 합니다. 9:17 And that can just take a lot of time just for them to research and figure out, much less find the best way to actually optimize it. 그것을 연구하고 파악하는 데 많은 시간이 걸릴 수 있으며, 최적화하는 가장 좋은 방법을 찾는 것은 말할 것도 없습니다. 9:22 So for example, one of the things you can do is build parts of your app that you want to have, build the features out and find the optimal ways for them. 예를 들어, 여러분이 원하는 앱의 일부를 만들고, 기능을 개발하고, 그 기능에 대한 최적의 방법을 찾는 것이 가능합니다. 9:31 So for example, at our software Hieros Air, we're able to pinpoint people coming to websites and recognize them regardless of whether they enter anything in the website and follow up with them via e commerce emails and reps and all sorts of cool stuff. 예를 들어, 저희 소프트웨어 Hieros Air를 사용하면 웹사이트에 방문하는 사람들을 정확히 파악하고, 그들이 웹사이트에 어떤 정보를 입력하든 상관없이 인식할 수 있습니다. 그리고 전자상거래 이메일과 상담원 등을 통해 후속 조치를 취할 수 있습니다. 9:44 But one of our bigger problems, we had a really hard time making good looking emails. 하지만 저희가 겪었던 큰 문제 중 하나는 보기 좋은 이메일을 만드는 데 정말 어려움을 겪었다는 것입니다. 9:49 And so I had to go and figure out like, how can we make these emails look really good when they're generated by AI? 그래서 저는 AI가 생성한 이메일을 정말 멋지게 만드는 방법을 고민해야 했습니다. 9:54 And it takes a lot of combinations and you have to know exactly what things are going together and how all the system prompts and user prompts are all put together. 여기에는 많은 조합이 필요하고, 모든 시스템 프롬프트와 사용자 프롬프트가 어떻게 결합되는지를 정확히 알아야 합니다. 10:00 And I didn't want my team spending all their time that they would be spending developing features actually figuring this out. 그래서 제 팀이 기능 개발에 할애할 시간을 이렇게 알아내는 데 쓰지 않기를 원했습니다. 10:05 So I was able to work with Claude and actually come and develop an app that allows me to test basically any type of generation method with AI. 그래서 Claude와 함께 작업하여 AI로 다양한 생성 방법을 테스트할 수 있는 앱을 개발할 수 있었습니다. 10:12 The second comes out and I'm able to vibe code it and it allows me to then make really beautiful emails and then find the costs and make things optimal for the software and then pass the optimal code to my team. 두 번째 결과가 나오면 코드를 조정할 수 있고, 이를 통해 정말 아름다운 이메일을 만들고 비용을 찾아 소프트웨어를 최적화한 후, 최적의 코드를 팀에 전달할 수 있습니다. 10:22 And so I'm able to go and test all sorts of different product features and strategies for the product very, very quickly and then find the best version of it and then take the code from that. 그래서 저는 다양한 제품 기능과 전략을 매우 빠르게 테스트하고, 가장 좋은 버전을 찾아 그 코드로 작업할 수 있습니다. 10:31 Have Claude go generate the code that would be optimal based on the high risk code and then give that to the team and say, hey, put this into the product and find a way to put it in there. Claude에게 고위험 코드를 기반으로 최적의 코드를 생성하게 하고, 그 코드를 팀에 전달하여 제품에 적용할 방법을 찾도록 합니다. 10:39 And so then the engineer's time is only spent doing things. 그래서 엔지니어의 시간은 실제로 일을 하는 데만 사용됩니다. 10:42 You're making money and making the features better. 이렇게 하면 수익을 창출하고 기능을 개선할 수 있습니다. 10:44 This is one of the best ways that I found at first to use it. 이것이 제가 처음에 발견한 가장 좋은 사용 방법 중 하나입니다. 10:47 Now the next thing you can do is also code up things that allow your team to work faster. 다음으로 할 수 있는 것은 팀이 더 빠르게 작업할 수 있도록 하는 코드 작업입니다. 10:52 So, so, for example, one of the most difficult things at Hires is we have a lot of complex setups that our customers have to use to install the app. 예를 들어, Hires에서 가장 어려운 것 중 하나는 고객이 앱을 설치하기 위해 사용해야 하는 복잡한 설정이 많다는 것입니다. 11:00 Once they do it, their ads absolutely shit money. 일단 설치하면, 그들의 광고는 정말 많은 수익을 창출합니다. 11:02 By the way, if you're watching this, you have a SaaS company, anything you should be using Hires. 참고로, 이 영상을 보고 계신다면 SaaS 회사를 운영하고 계신 것인데, Hires를 꼭 사용해야 합니다. 11:05 There's a reason why everybody uses it because you plug into your Ads, you're going to make 10 to 15%, 20%, sometimes more from your ads, particularly SaaS and B2B ads. 모두가 사용하는 이유가 있습니다. 광고에 연결하면 10%에서 15%, 20% 또는 그 이상을 광고에서 얻을 수 있습니다. 특히 SaaS 및 B2B 광고에서요. 11:14 This is why every big brand in the world uses it. 이것이 세계의 모든 대기업이 Hires를 사용하는 이유입니다. 11:16 You can come check it out right now. 지금 바로 확인해 보실 수 있습니다. 11:18 You can use it. 사용해 보실 수 있습니다. 11:18 It has a 90 day refund guarantee. 90일 환불 보장입니다. 11:20 If you don't see results from it, you don't see the results I just talked about. 결과가 나타나지 않으면, 제가 방금 말씀드린 결과를 보지 못하는 것입니다. 11:23 You don't pay for it. 이것에 대해서는 비용을 지불하지 않습니다. 11:24 But we've been around for a very long time at this point. 하지만 우리는 지금까지 아주 오랫동안 존재해왔습니다. 11:26 We have thousands and thousands of customers. 수천 명의 고객이 있습니다. 11:28 It's a pretty big company. 상당히 큰 회사입니다. 11:29 So if it didn't work consistently, we wouldn't be there. 그래서 만약 지속적으로 효과가 없었다면, 우리는 여기 있지 않았을 것입니다. 11:31 You should come use it if you're watching this video and you want to make more money from your ads, particularly if you're a SaaS business. 이 영상을 보고 계시고 광고에서 더 많은 수익을 올리고 싶다면, 특히 SaaS 비즈니스라면 사용해 보셔야 합니다. 11:36 Anyways, at our SaaS company, one of the hardest things is managing people's installs and then keeping all the install documentation up to site, up to date on our sites. 어쨌든, 저희 SaaS 회사에서 가장 어려운 것 중 하나는 사람들의 설치를 관리하고 모든 설치 문서를 최신 상태로 유지하는 것입니다. 11:47 And so one of the things you can do and I'm going to show you the really cool apps here in a second. 그래서 여러분이 할 수 있는 것 중 하나가 있으며, 정말 멋진 앱을 곧 보여드리겠습니다. 11:50 But I some people might roll their eyes because the sexiest thing you build is infrastructure apps for your business. 하지만 어떤 사람들은 눈을 굴릴 수도 있습니다. 왜냐하면 여러분이 만드는 가장 매력적인 것은 비즈니스를 위한 인프라 앱이기 때문입니다. 11:56 But this is one of the best applications for it. 하지만 이것은 그 중 가장 좋은 애플리케이션 중 하나입니다. 11:59 So you can see what this app right here, what it does is it allows my team to go and manage all the documentation for the business. 이 앱이 하는 일은 제 팀이 비즈니스의 모든 문서를 관리할 수 있도록 해줍니다. 12:06 And you can see if we scroll this over right here, it has when the documentation is uploaded, when it's marked good, it has the person's sign name next to it. 그리고 여기에서 스크롤하면 문서가 업로드된 날짜, 승인된 날짜, 그리고 그 옆에 서명한 사람의 이름이 표시됩니다. 12:13 And what happens when people are using this with one of our install apps, when the installs go wrong, the customer reports bad, the status turns to bad, it alerts the team and then they go and ch what happened with the bad status and an update doc. 사람들이 저희 설치 앱 중 하나를 사용할 때 발생하는 일은, 설치가 잘못되면 고객이 문제를 보고하고, 상태가 나쁨으로 바뀌며, 팀에 경고가 가고, 그들은 나쁜 상태에 대해 무슨 일이 있었는지 확인하고 문서를 업데이트합니다. 12:26 And so what this allows us to do is simultaneously manage hundreds of docs that talk about the installs and keep them up to date with what's going on with the companies. 이것을 통해 우리는 설치에 대한 수백 개의 문서를 동시에 관리하고, 회사에서 일어나는 일과 함께 최신 상태로 유지할 수 있습니다. 12:34 And so you can see we used to have a really ugly documentation website, but I went in and made an entirely new documentation website that manages all this and it plugs into these. 예전에는 정말 보기 흉한 문서 웹사이트가 있었지만, 저는 완전히 새로운 문서 웹사이트를 만들어서 이 모든 것을 관리하고 연결했습니다. 12:42 Txt files which then also can then be plugged into Claude. 텍스트 파일은 Claude에도 연결될 수 있습니다. 12:45 So Claude can set up our app for our customers as well. 그래서 Claude는 고객을 위해 저희 앱을 설정할 수 있습니다. 12:49 But regardless, I was able to go and get all these. 어쨌든, 저는 이 모든 것을 가져올 수 있었습니다. 12:51 Txt files and it up updates. 텍스트 파일과 그 업데이트입니다. 12:52 These cloud's going to look at the. 이 클라우드는 그걸 살펴볼 것입니다. 12:54 Txt files and then rewrite our documentation based on. 텍스트 파일을 작성한 후, 이를 바탕으로 문서를 다시 작성합니다. 12:57 Txt files. 텍스트 파일입니다. 12:58 So it literally allows us to do one of the biggest challenges that we had at our company effortlessly and stay on top of it without our, our customer support team having to manage and write hundreds of docs and stay on top of it manually. 이 시스템 덕분에 저희 회사에서 겪었던 가장 큰 도전 과제를 수월하게 해결하고, 고객 지원 팀이 수백 개의 문서를 관리하고 수동으로 처리하지 않고도 이를 잘 유지할 수 있습니다. 13:08 It's all done for us directly from this system. 모든 것이 이 시스템에서 직접 처리됩니다. 13:11 So the next thing you can use this for at your companies is infrastructure in your companies. 따라서 여러분의 회사에서 이를 사용할 수 있는 다음 사항은 인프라입니다. 13:16 All right, so we have all sorts of new apps and all things to make our team's lives easier. 좋습니다, 저희는 팀의 삶을 더 쉽게 만들어줄 다양한 새로운 앱과 모든 것을 가지고 있습니다. 13:20 Massive, massive, massive unlock. 엄청난, 엄청난, 엄청난 잠금 해제입니다. 13:22 Just these two, right, Allow us to get so much more done at high risk that is focused around getting results for the customer and the product itself. 바로 이 두 가지가 저희가 고객과 제품 자체를 위한 결과를 얻는 데 집중할 수 있도록 많은 일을 더 할 수 있게 해줍니다. 13:29 So the two thing I want you to notice right here is we found a lot of ways to segregate what we're building from the actual software itself. 여기서 제가 주목하고 싶은 두 가지는 우리가 실제 소프트웨어와 구축하고 있는 것을 분리할 수 있는 많은 방법을 찾았다는 것입니다. 13:37 This is important because you need to realize when you go in and mess with actual software, the deep internal guts of the software, you're not going to blow everything up. 이는 실제 소프트웨어의 깊은 내부를 건드릴 때 모든 것이 망가지는 것이 아니라는 것을 인식해야 하기 때문에 중요합니다. 13:44 You can 100% use agentic coding inside your software using the steps I'm going to show you in this process. 이 과정에서 제가 보여드릴 단계들을 사용하여 소프트웨어 내에서 100% 에이전틱 코딩을 사용할 수 있습니다. 13:51 You want your engineers knowing this stuff. 여러분의 엔지니어들이 이러한 내용을 알고 있기를 원합니다. 13:52 You want your engineers working like this. 여러분의 엔지니어들이 이렇게 작업하기를 원합니다. 13:54 You want your engineers using LLMs a lot when they're coding. 여러분의 엔지니어들이 코딩할 때 LLM을 많이 사용하기를 원합니다. 13:57 There's ways to use it in a controlled format that definitely work. 확실히 효과가 있는 통제된 형식으로 사용하는 방법이 있습니다. 14:00 What I'm saying right here is especially if you're a non technical founder and you're looking to get not be engineering your main software kind of like I do, or working with the teams and the things they're doing, you need to be understanding that one of the best ways to use agentic coding is when it's segregated from your software because then you can make little mini apps to get massive, massive progress for your company done that are completely risk free to build. 특히 비기술적 창립자이시고, 저처럼 주요 소프트웨어를 엔지니어링하지 않으려 하거나 팀과 그들이 하는 일과 함께 작업하려는 경우, 에이전틱 코딩을 사용하는 가장 좋은 방법 중 하나는 소프트웨어와 분리되어 있을 때라는 것을 이해해야 합니다. 그러면 완전히 위험 없이 구축할 수 있는 작은 미니 앱을 만들어 회사의 큰 진전을 이룰 수 있습니다. 14:23 And if, if you understand the basics, where I'm going to show you in this video, maintaining these and keeping these going is effortless. 그리고 제가 이 비디오에서 보여드릴 기본 사항을 이해한다면, 이를 유지하고 계속하는 것은 수월합니다. 14:28 Okay, so the final thing I'm actually going to show you is actually user used applications. 좋습니다, 제가 실제로 보여드릴 마지막 것은 사용자 사용 애플리케이션입니다. 14:34 All right, so I'm going to show you one thing that we've created right here. 좋습니다, 제가 여기서 만든 한 가지를 보여드리겠습니다. 14:38 All right, so this is actually a setup extension. 사실 이것은 설정 확장 기능입니다. 14:40 And I built and what it does is. 제가 만든 것이고, 그 기능은 이렇습니다. 14:43 Well, I'll just show you what it does. 그럼 제가 그 기능을 보여드리겠습니다. 14:44 I can type in WordPress right here. 여기서 워드프레스를 입력할 수 있습니다. 14:46 And what we had the biggest problem with at Hyros was people getting set up and installing Hiros. 하이로스에서 가장 큰 문제는 사람들이 하이로스를 설치하고 설정하는 것이었습니다. 14:51 So what I did is we created that, that system I showed you and then I created an app that is going to allow LLMs to essentially watch your screen while you're doing setup and then it walks you through step by step, how to do the entire setup. 그래서 제가 한 것은, 제가 보여드린 시스템을 만들고, 설정하는 동안 LLM이 화면을 지켜보면서 단계별로 전체 설정을 안내해주는 앱을 만든 것입니다. 15:05 So if I use this app right now, it will walk me through screen by screen, tell me exactly what to do to set up Hiros for WordPress or whatever I type in, it will go scrape my site, look at my stack and it will go and then tell me what to do. 그래서 지금 이 앱을 사용하면, 화면별로 안내해주고 하이로스를 워드프레스에 설정하는 방법을 정확히 알려줍니다. 제가 입력하는 내용에 따라 제 사이트를 스크랩하고, 스택을 확인한 후에 무엇을 해야 하는지 알려줍니다. 15:17 It's basically like having a customer support agent that will sit by with our customers and help them install HiOS which was our single biggest blocker. 기본적으로 고객 지원 담당자가 고객과 함께 앉아 하이오스를 설치하는 데 도움을 주는 것과 같습니다. 이것이 우리의 가장 큰 장애물이었습니다. 15:23 Like that's the biggest big problem at hos. 그것이 하이로스에서 가장 큰 문제입니다. 15:25 It's not that it doesn't get results or works every time. 결과가 나오지 않거나 매번 작동하지 않는 것은 아닙니다. 15:27 When people come in and set this up, they see huge results in their ads. 사람들이 이 설정을 하면 광고에서 엄청난 결과를 보게 됩니다. 15:30 It basically prints money for people when they come in. 사람들이 들어오면 기본적으로 돈을 인쇄하는 것과 같습니다. 15:32 It's getting them to take the effort to sit down and actually install it which in the in the past required people to have to sit down, go through our documentation, figure out their stack set up, work with our customer support people, get on customer support calls. 문제는 사람들이 앉아서 실제로 설치하는 노력을 기울이는 것입니다. 과거에는 사람들이 앉아서 우리의 문서를 읽고, 스택 설정을 파악하고, 고객 지원 직원과 협력하며, 고객 지원 전화를 해야 했습니다. 15:43 And as good as our customer support is, people don't like dealing with customers. 우리의 고객 지원이 아무리 좋더라도 사람들은 고객과의 대화를 좋아하지 않습니다. 15:47 So that was one of our biggest reasons for churn is because it takes a little bit of time. 그래서 이것이 이탈의 가장 큰 이유 중 하나였습니다. 시간이 조금 걸리기 때문입니다. 15:50 The set of pyros not anymore. 이제는 그런 문제가 없습니다. 15:52 And so we're able to use Vibe coding to go and solve massive huge chunks of our business. 그래서 우리는 Vibe 코딩을 사용하여 비즈니스의 큰 부분을 해결할 수 있게 되었습니다. 15:58 Now with Vibe coding is what we've made. 이제 Vibe 코딩으로 우리가 만든 것입니다. 16:00 I've been working on huge leaps at high risk to allow us to get the raw data, use the APIs to build stuff there's just nutty we can put into the software. 저는 하이리스크에서 큰 발전을 위해 작업해왔고, 원시 데이터를 얻고, API를 사용하여 소프트웨어에 넣을 수 있는 것들을 구축할 수 있게 되었습니다. 16:09 And if you're thinking about when you're building these type of of mini apps inside of your business, if you think when you're using it for your users or you're giving it to your users, how you can either build stuff that sits outside the software. 그리고 이러한 미니 앱을 비즈니스 내에서 구축할 때, 사용자에게 제공할 때 소프트웨어 외부에 있는 것들을 어떻게 구축할 수 있을지 생각해 보세요. 16:21 Okay, kind of like this Chrome extension right right here. 자, 바로 이 Chrome 확장 프로그램처럼요. 16:23 All right. 좋습니다. 16:24 Sits outside of software. 소프트웨어 외부에 위치합니다. 16:25 I can work on this all day without really risking the app and I can create extra systems that there that benefit the customer without really risking that. 저는 앱에 위험을 주지 않고 하루 종일 이 작업을 할 수 있으며, 고객에게 이익이 되는 추가 시스템을 생성할 수 있습니다. 16:32 Next you can actually create apps that sit outside the software that can be API called. 다음으로, 소프트웨어 외부에 위치하고 API 호출이 가능한 앱을 실제로 만들 수 있습니다. 16:37 So for example, I've made a scraping software that our system, when people are going through onboarding can use to figure out what sites they need, what their set process is going to look like. 예를 들어, 사람들이 온보딩을 진행할 때 사용할 수 있는 스크래핑 소프트웨어를 만들었습니다. 이를 통해 어떤 사이트가 필요한지, 그들의 설정 프로세스가 어떻게 될지를 파악할 수 있습니다. 16:45 And then Hiros will ping that API so it sits at outside the software. 그리고 Hiros는 그 API를 호출하므로 소프트웨어 외부에 위치하게 됩니다. 16:49 Again we can work on this, do all sorts of stuff on this all day, low risk. 다시 말해, 우리는 이 작업을 하루 종일 할 수 있으며, 위험이 적습니다. 16:53 And then finally when you're actually building inside your software, finding ways to structure your architecture so that Vibe code Specific areas like your front end or your onboarding areas or places that don't really need access to your complicated backend of the software. 그리고 마지막으로 소프트웨어 내에서 구축할 때, Vibe 코드의 특정 영역, 즉 프론트 엔드나 온보딩 영역, 복잡한 백엔드에 접근할 필요가 없는 곳을 구조화하는 방법을 찾아야 합니다. 17:07 Usually the user interface where your team can lose so much time coding it. 보통 사용자 인터페이스는 팀이 코딩하는 데 많은 시간을 낭비할 수 있는 곳입니다. 17:12 For example, going and changing the UI or changing the setup area inside the software, the menu areas or the onboarding systems. 예를 들어, UI를 변경하거나 소프트웨어 내의 설정 영역, 메뉴 영역 또는 온보딩 시스템을 변경하는 것입니다. 17:19 Those used to take teams very long amounts of time to do and so they were working on these instead of building the features that get people to buy your software. 이러한 작업은 팀이 매우 오랜 시간을 소모하게 했고, 그들은 소프트웨어를 구매하게 만드는 기능을 구축하는 대신 이 작업을 하고 있었습니다. 17:26 These are the most important parts of your software though. 하지만 이러한 부분이 소프트웨어에서 가장 중요한 부분입니다. 17:28 Onboarding is the most important part. 온보딩이 가장 중요한 부분입니다. 17:29 If you see me talk about on the channel all the time. 제가 채널에서 항상 이야기하는 부분이죠. 17:31 If you can find ways to segregate the code so you can work on those parts of the app risk free, then holy moly. 코드를 분리할 수 있는 방법을 찾으면 앱의 이러한 부분을 위험 없이 작업할 수 있습니다. 그러면 정말 대단합니다. 17:39 You can just cut literally half the development time off your software and put your teams purely on money making development. 소프트웨어 개발 시간을 절반으로 줄이고 팀을 순수하게 수익 창출 개발에 집중시킬 수 있습니다. 17:45 These three views all together just money and make make. 이 세 가지 관점이 모두 모이면 돈을 벌고 만들게 됩니다. 17:50 If you're a non technical founder or product person, you can just get so much done, it's ridiculous. 비기술적 창립자나 제품 담당자라면 정말 많은 일을 할 수 있어요, 정말 말도 안 됩니다. 17:56 I've fat for the past 60 days I've just been coding and making apps and coding and making apps and coding and making apps that have just removed so much like freaking red tape at high risk, it's insane. 지난 60일 동안 저는 계속 코딩하고 앱을 만들면서 많은 불필요한 절차를 없앴습니다. 정말 미친 듯이 고위험의 상황에서도 말이죠. 18:06 Now using the process I'm going to give you for these, you can even start developing inside your app. 이 과정을 사용하면 앱 내에서 개발을 시작할 수 있습니다. 18:12 You just have to move a little bit slower and be a little bit more careful, especially because you're working with lots of other developers. 조금 더 천천히 움직이고, 특히 다른 개발자들과 함께 작업하고 있으니 좀 더 조심해야 합니다. 18:17 It's not something I suggest you doing. 이건 제가 추천하는 방법이 아닙니다. 18:19 I really suggest you giving these smart processes I'm talking about to your developers and having them use it. 제가 말씀드리는 스마트한 프로세스를 개발자들에게 제공하고, 그들이 이를 활용하도록 하는 것을 정말 추천합니다. 18:24 Because at the end of the day, what doing high level development is, is it's not writing code, a lot of people can write code. 결국 고급 개발이란 코드를 작성하는 것이 아니라, 많은 사람들이 코드를 쓸 수 있지만, 모든 코드가 어떻게 맞물리는지를 이해하는 것입니다. 18:30 It's understanding how all the code fits together, which the AI can do. AI가 그 일을 할 수 있습니다. 18:34 But it's understanding how to make the AI understand what it's looking at and giving the AI enough context. 하지만 AI가 무엇을 보고 있는지 이해하게 하고, AI에게 충분한 맥락을 제공하는 것이 중요합니다. 18:39 And when the AI is working on understanding what the AI is doing to the code, which can be done, even if you cannot write code, you can still look at what the AI is doing and look at the work it's done and figure out what it's doing. AI가 코드에 대해 이해하려고 할 때, 코드를 쓸 수 없더라도 AI가 하는 일을 보고, 그 작업을 살펴보며 무엇을 하고 있는지 파악할 수 있습니다. 18:51 You can even ask it what it's doing. AI에게 무엇을 하고 있는지 물어볼 수도 있습니다. 18:52 You can ask and explain what it just did. AI가 방금 한 일을 설명해 달라고 요청할 수 있습니다. 18:54 And you can, if you understand how your app works as a whole, then you understand what it just did to the rest of the app. 앱 전체가 어떻게 작동하는지 이해한다면, AI가 나머지 앱에 대해 무엇을 했는지 알 수 있습니다. 19:00 And so even when you cannot code, you should be able to read some base code. 그래서 코드를 쓸 수 없더라도 기본적인 코드를 읽을 수 있어야 합니다. 19:04 If you work in SAS and you're. SAS에서 작업하고 있다면. 19:05 If you can't read code like, you should understand the gist of where all the files are. 코드를 읽을 수 없다면, 모든 파일이 어디에 있는지 대략적인 개념은 이해해야 합니다. 19:10 You should be able to look at VS code in your app and like know where the things are are. 앱의 VS 코드에서 항목들이 어디에 있는지 알 수 있어야 합니다. 19:13 But if you're not even a top level engineer, most of the work is actually still keeping in track of where everything in your software is. 하지만 최상위 엔지니어가 아니라면, 대부분의 작업은 소프트웨어의 모든 것이 어디에 있는지를 추적하는 것입니다. 19:18 So when Cloud does something, it tells you what it does and you know exactly what it did to the rest of the software, regardless if you can understand the Python or the JavaScript, the next JS or whatever the it's written in. 클라우드가 무언가를 할 때, 그것이 무엇을 했는지 알려주고, 파이썬이나 자바스크립트, 넥스트 JS 등 어떤 언어로 작성되었든지 상관없이 소프트웨어의 나머지 부분에 대해 정확히 무엇을 했는지 알 수 있습니다. 19:27 Okay, so this being said, let's talk about how we would go and actually do this entire process. 자, 이제 이 모든 것을 바탕으로 실제로 이 과정을 어떻게 진행할지 이야기해보겠습니다. 19:32 I want you to think first though, like I just said, how you're going to be using this. 먼저, 제가 방금 말한 것처럼, 이걸 어떻게 사용할 것인지 생각해보시기 바랍니다. 19:36 Okay. 알겠습니다. 19:36 It's not just rip open your software and start coding on it. 소프트웨어를 열고 바로 코딩하는 것만으로는 안 됩니다. 19:39 Okay, so I'm going to show you my entire process from start to finish. 자, 이제 시작부터 끝까지 제 전체 과정을 보여드리겠습니다. 19:42 Now look, do I think this is the most technically super duper impressive way to be using Cloud? 자, 이게 클라우드를 사용하는 가장 기술적으로 인상적인 방법이라고 생각하나요? 19:49 Yes, baby. 네, 맞습니다. 19:50 Actually, I'm a genius. 사실, 저는 천재입니다. 19:51 This stuff is. 이런 것들이죠. 19:52 This stuff is awesome. 정말 멋진 것들입니다. 19:53 I think I'm pretty damn efficient at this. 저는 이 부분에서 꽤 효율적이라고 생각합니다. 19:55 That being said, you're going to see all sorts of setup strategies and loops and technical things and ways to manage the context window that I think if you're trying to get stuff done, I don't think are needed. 그렇긴 해도, 여러분은 다양한 설정 전략과 루프, 기술적인 것들, 그리고 제가 생각하기에 작업을 완료하려고 할 때 필요하지 않은 방법들을 보게 될 것입니다. 20:07 I think it's much more important you understand how Claude works. 클로드가 어떻게 작동하는지를 이해하는 것이 훨씬 더 중요하다고 생각합니다. 20:10 Even if your developers are working on your large software, you don't get the results from more complication. 개발자들이 대규모 소프트웨어를 작업하고 있더라도, 복잡함이 더 많은 결과를 가져오지는 않습니다. 20:14 You understand that you get the results by understanding how Claude works and making sure Claude always has context of what it's doing and full awareness of what it's doing. 클로드가 어떻게 작동하는지를 이해하고, 클로드가 항상 자신이 하고 있는 일의 맥락을 알고 있도록 하는 것이 결과를 얻는 방법입니다. 20:22 You're watching what it's doing and you understand what it's doing to your software, which doesn't take a complicated setup. 여러분은 클로드가 무엇을 하고 있는지를 지켜보고, 그것이 여러분의 소프트웨어에 어떤 영향을 미치는지를 이해하게 됩니다. 이는 복잡한 설정을 필요로 하지 않습니다. 20:28 It takes understanding the process and the train and the assembly line of what you're building. 여러분이 만들고 있는 것의 과정과 기차, 조립 라인을 이해하는 것이 필요합니다. 20:33 Okay. 알겠습니다. 20:34 Everything else, all the loops, the agents and stuff like that that people create. 그 외의 모든 것, 루프와 에이전트 같은 것들은 사람들이 만들어내는 것입니다. 20:38 Oh, I got six agents doing six different things at a time. 아, 저는 동시에 여섯 개의 에이전트가 여섯 가지 다른 일을 하고 있습니다. 20:40 I don't understand the purpose of that because it's just excessive stuff. 그 목적을 이해하지 못하겠습니다. 왜냐하면 그건 단순히 과도한 것들이기 때문입니다. 20:44 And that's not how you want to build something. 그리고 그렇게 무언가를 만드는 것은 원하지 않습니다. 20:46 It's like if you're writing a novel, you don't want to have something go and you have eight different writers all writing your novel at once. 소설을 쓴다고 생각해보세요. 여러 명의 작가가 동시에 당신의 소설을 쓰고 있다면 원치 않는 일이 생길 것입니다. 20:52 You want to write chapter one, you want to review chapter one, you want to carefully go through each part of chapter one and make sure it's aligned correctly before going to chapter two. 첫 번째 장을 쓰고, 첫 번째 장을 검토하고, 첫 번째 장의 각 부분을 세심하게 살펴보며 두 번째 장으로 넘어가기 전에 제대로 정렬되어 있는지 확인하고 싶습니다. 21:00 Okay. 알겠습니다. 21:01 And as you start making the book, there's gonna be things you discover as you're building. 책을 만들기 시작하면, 작업을 진행하면서 발견하게 될 것들이 있을 것입니다. 21:04 Okay. 알겠습니다. 21:04 You're gonna maybe get to chapter two and say, oh, okay. 두 번째 장에 도달했을 때, 아, 알겠구나 할 수도 있습니다. 21:06 The character should work this way. 그 캐릭터는 이렇게 작동해야 합니다. 21:07 If you have all these eight different things and everything, you're not carefully crafting what you're doing. 여러 가지가 동시에 진행되고 있다면, 당신이 하고 있는 일을 세심하게 다듬고 있지 않은 것입니다. 21:11 And frankly, you don't need to write that much code to make an app. 솔직히 말해서, 앱을 만들기 위해 그렇게 많은 코드를 작성할 필요는 없습니다. 21:16 Okay, look, I know there's. 알겠어요, 그런 게 있다는 걸 압니다. 21:17 If you're making your own Internet browser, your own coding language or something. 자신만의 인터넷 브라우저나 코딩 언어를 만들고 있다면 말이죠. 21:20 Yeah, maybe you do. 네, 그럴 수도 있습니다. 21:21 But if you're adding a feature to your app, if you're adding a tool for your users, Claude is probably going to need to only swing at it for about an hour. 하지만 앱에 기능을 추가하거나 사용자들을 위한 도구를 추가한다면, Claude는 아마도 한 시간 정도만 작업하면 될 것입니다. 21:28 And the most important thing is you're thinking about your users and the process and what you're building and how Claude understands it while it's doing it. 가장 중요한 것은 사용자의 입장과 프로세스, 당신이 만들고 있는 것, 그리고 Claude가 이를 이해하는 방식에 대해 생각하는 것입니다. 21:34 So when you give it a command, it understand how it fits into the process. 그래서 명령을 내릴 때, 그것이 프로세스에 어떻게 맞는지를 이해합니다. 21:37 And this is where this process starts at. 그리고 여기서 이 프로세스가 시작됩니다. 21:39 Okay, so while this might not be the most technical, you can get really good results with this. 알겠습니다, 이게 가장 기술적이지는 않지만, 정말 좋은 결과를 얻을 수 있습니다. 21:44 Okay, so I'm going to walk you through the planning process all the way to the actual Vibe coding process itself. 그럼 계획 과정부터 실제 Vibe 코딩 과정까지 안내해 드리겠습니다. 21:48 So the first thing you want to do is I use Claude code exclusively. 먼저 하고 싶은 것은 Claude 코드를 전적으로 사용하는 것입니다. 21:53 And if we pop open, I'm just going to show you my setup. 설정을 보여드리기 위해 잠시 열어보겠습니다. 21:55 And I usually have three terminals going the same time. 저는 보통 세 개의 터미널을 동시에 사용합니다. 21:58 I just kind of crush these all together. 이걸 그냥 한꺼번에 처리합니다. 21:59 Usually I'm just looking at one terminal and I'm moving from one at a time. 보통은 한 개의 터미널만 보고 한 번에 하나씩 이동합니다. 22:03 I don't have them all three open at the same time. 세 개를 동시에 열어두지는 않습니다. 22:05 That's ridiculous. 그건 말도 안 돼요. 22:06 I know you see people screenshotting that on X. X에서 사람들이 스크린샷을 찍는 걸 보셨죠. 22:08 That's stupid. 그건 멍청한 짓이에요. 22:09 You don't need this much text all at once. 한 번에 이렇게 많은 텍스트를 볼 필요는 없습니다. 22:11 What I'm usually doing is throughout the day, when I'm in, like, coding mode, I'm just going to have three going at once, which sounds impressive, but it's not because all it does is it goes and works for five, ten minutes, and then at five to ten minutes, you talk to this one, and then that five to ten minutes you talk to this one one. 제가 보통 하는 것은 하루 동안 코딩 모드에 있을 때, 세 개를 동시에 켜두는 건데, 이게 인상적으로 들릴 수 있지만, 사실 그렇지 않습니다. 왜냐하면 이건 5분에서 10분 동안 작업하고, 그 다음 5분에서 10분 동안 이걸 보고, 또 그 5분에서 10분 동안 저걸 보는 식이거든요. 22:26 It's that damn simple. 정말 간단해요. 22:27 Okay, but what my setup is going to be is I'm just going to use free VS code, Open the terminal. 좋아요, 제 설정은 무료 VS 코드를 사용할 거고, 터미널을 열 것입니다. 22:32 I'm going to have the eyed over here. 여기서 아이디를 사용할 거예요. 22:33 All right. 좋아요. 22:34 I'm going to have all my files and everything over here that I'm going to be looking at if I need to look at them. 필요할 때 볼 파일과 모든 것을 여기 두고 볼 것입니다. 22:38 You don't really need to be looking at the Code. 코드를 볼 필요는 사실 별로 없습니다. 22:40 You can look at the code if you want, especially these smaller apps. 원하시면 코드를 볼 수 있지만, 특히 이런 작은 앱들은 그렇습니다. 22:43 There's no point. 의미가 없어요. 22:44 You don't need me looking at the code. 제가 코드를 볼 필요는 없습니다. 22:45 Like, there's no point. 그건 의미가 없어요. 22:46 If you're doing it with your main software base. 주 소프트웨어 기반으로 작업하고 있다면요. 22:48 Yes, you need to be able to read the code with these smaller apps and everything builds, building. 네, 이러한 작은 앱들을 통해 코드를 읽을 수 있어야 하고 모든 것이 구축됩니다. 22:51 No, you don't need to do it. 아니요, 그렇게 할 필요는 없습니다. 22:52 The code reviews. 코드 리뷰입니다. 22:52 And if you have enough context and you build it's right with Claude and you understand how to give it context, you don't need to look at the code. 그리고 충분한 맥락이 있고 Claude와 함께 올바르게 구축하면, 맥락을 제공하는 방법을 이해하게 되므로 코드를 볼 필요가 없습니다. 22:57 I'm sorry, you don't. 죄송하지만, 필요하지 않습니다. 22:58 I have had no issue for 60 days straight. 60일 동안 아무 문제 없이 지냈습니다. 23:00 And I built a lot of. 그리고 많은 것을 구축했습니다. 23:01 And I built. 그리고 구축했습니다. 23:02 That actually does important stuff in our business and there's no problems. 실제로 우리 비즈니스에서 중요한 일을 하는 것이고, 문제는 없습니다. 23:05 Okay. 알겠습니다. 23:06 So it's. 그래서 그것은. 23:07 It's more about how you understand how it fits together. 어떻게 서로 맞물리는지를 이해하는 것이 더 중요합니다. 23:09 And the reason why there's no problem is because I understand how it fits together, which I'm going to communicate to you right now. 문제가 없는 이유는 제가 어떻게 맞물리는지를 이해하고 있기 때문이며, 지금 바로 여러분에게 전달하겠습니다. 23:12 So you're going to see people using Cursor and all sorts of crazy stuff. 그래서 여러분은 사람들이 Cursor와 다양한 신기한 것들을 사용하는 모습을 보게 될 것입니다. 23:15 I love Cursor as a company. 저는 Cursor라는 회사를 좋아합니다. 23:17 I think it's cool. 멋지다고 생각합니다. 23:18 I don't understand the point of it. 그 목적이 무엇인지 이해하지 못하겠습니다. 23:19 All, right? 모두 알겠죠? 23:19 I don't. 저는 이해하지 못합니다. 23:20 You really just need a terminal or you need a chat box and you can just get all the stuff done. 정말로 터미널이나 채팅 박스만 있으면 모든 작업을 끝낼 수 있습니다. 23:24 You're going to see all the complicated steps, but that's it. 복잡한 단계들을 모두 보게 될 거지만, 그게 전부입니다. 23:26 So what I'm going to be doing and I'm just going to work over and make this the main thing we're going to be working on, because it's what we're building and I'm going to be talking about how I built this today, literally. 제가 할 일은 이 작업을 주로 진행하는 것이고, 오늘 이걸 어떻게 만들었는지에 대해 이야기할 것입니다. 23:37 So what I'm going to have most of the time going is I'm just going to have my setup like this and I'm going to work directly like this most of the time. 대부분의 시간 동안 이렇게 세팅해 놓고 직접 작업할 것입니다. 23:44 If I need to read files or look at specific things, this is where I'm going to be looking at. 파일을 읽거나 특정한 것들을 살펴봐야 할 경우, 여기에서 확인할 것입니다. 23:47 But this is where I'm going to be working at most of the time. 하지만 대부분의 시간 동안 여기에서 작업할 것입니다. 23:49 And I'm just going to be just chatting this little box right here. 그리고 저는 여기 작은 박스에서 대화할 것입니다. 23:51 Here. 여기입니다. 23:51 Now, before we come over here, what a lot of people try to do is they plan inside the terminal, which is fine. 이곳에 오기 전에 많은 사람들이 터미널 안에서 계획을 세우려 하는데, 그건 괜찮습니다. 23:57 I think that that's great. 그건 정말 좋은 방법이라고 생각합니다. 23:59 You can just come over here plus shift tab shift to plan mode and, you know, talk to Claude and say, okay, I want to add a new browse feature. 여기로 와서 Shift + Tab을 눌러 계획 모드로 전환하고, Claude와 대화하면서 새로운 탐색 기능을 추가하고 싶다고 말할 수 있습니다. 24:11 Let's discuss. 논의해 봅시다. 24:13 Give me a list of feature ideas that we could add in list format. 추가할 수 있는 기능 아이디어 목록을 리스트 형식으로 주세요. 24:19 Okay. 좋습니다. 24:20 And so what it's going to do is it's going to go in and help me plan and start working through the software. 이것은 제가 계획을 세우고 소프트웨어 작업을 시작하는 데 도움을 줄 것입니다. 24:23 This is a great way to plan out your software. 소프트웨어를 계획하는 좋은 방법입니다. 24:25 This isn't how I like to do it though. 하지만 저는 이렇게 하는 것을 좋아하지 않습니다. 24:27 And I think my method is a little bit better for stupid people like me, which I assume you are. 제 방법이 저 같은 멍청이에게는 조금 더 나은 것 같고, 당신도 그렇게 생각한다고 가정합니다. 24:31 Okay. 좋습니다. 24:31 I don't like doing plan mode in this because you're going to spend a lot of context doing this and you're going to add in the test things and to build things out, you're going to have to create a lot of test code. 이렇게 계획 모드로 하는 것을 좋아하지 않는데, 많은 맥락을 소모하게 되고 테스트 코드를 추가해야 하며, 많은 테스트 코드를 만들어야 하기 때문입니다. 24:43 And I like to make test code before I go and actually start developing the right product. 저는 실제로 올바른 제품을 개발하기 전에 테스트 코드를 만드는 것을 좋아합니다. 24:48 And I don't like to make my MD files and everything inside of this. 저는 여기서 MD 파일과 그 안의 모든 것을 만들고 싶지 않습니다. 24:50 Okay. 알겠습니다. 24:51 So you can see it's actually giving me a bunch of ideas and things I can work with. 그래서 실제로 저에게 많은 아이디어와 작업할 것들을 제공하고 있다는 것을 볼 수 있습니다. 24:54 And I'm in planning stuff. 저는 지금 계획을 세우고 있습니다. 24:55 I don't want this in here. 여기에는 이걸 원하지 않습니다. 24:56 So I'm gonna hit Escape. 그래서 Escape 키를 누르겠습니다. 24:57 Escape and go back and revert. Escape를 눌러서 돌아가고 되돌리겠습니다. 25:00 All right? 괜찮으신가요? 25:01 So that, that's the setup that I have right here. 그래서 이게 제가 여기서 설정한 것입니다. 25:03 So what I want to do is explain why I start off inside of Claude. 그래서 제가 하고 싶은 것은 왜 Claude 안에서 시작하는지를 설명하는 것입니다. 25:06 All right? 괜찮으신가요? 25:07 And so one of the reasons I also want to break down why I'm doing this is I see a lot of videos on YouTube and X, then they're made by developers for developers. 제가 이렇게 하는 이유 중 하나는 YouTube와 X에서 많은 동영상을 보았는데, 그들은 개발자를 위한 개발자에 의해 만들어진 것들이라는 것입니다. 25:15 And I don't really see a lot of product people making coding or agentic coding instructions. 하지만 저는 제품 관련 사람들이 코딩이나 에이전틱 코딩 지침을 만드는 것을 많이 보지 못했습니다. 25:20 And here's why I think this is really, really important. 그리고 제가 생각하기에 이것이 정말로 중요한 이유입니다. 25:22 If you look at softwares, developers and engineers are very, very important. 소프트웨어를 보면, 개발자와 엔지니어는 매우, 매우 중요합니다. 25:26 But what they're usually not doing is doing the proc. 하지만 그들이 보통 하지 않는 것은 프로세스를 진행하는 것입니다. 25:29 Designs and the design process, how the feature is going to look and feel and do. 디자인과 디자인 프로세스, 기능이 어떻게 보이고 느껴지며 작동할 것인지입니다. 25:32 And that's the most important thing. 그리고 그것이 가장 중요한 것입니다. 25:34 Look, I'm not in this video putting and saying developers or engineers are not needed. 보세요, 저는 이 영상에서 개발자나 엔지니어가 필요 없다고 말하고 있는 것이 아닙니다. 25:38 They're super duper and critically important. 그들은 매우 중요하고 필수적입니다. 25:40 And if you can do what I'm doing right here as an engineer, you're like, like Moses right now partying the Red Sea. 그리고 만약 당신이 여기서 제가 하는 것처럼 엔지니어로서 할 수 있다면, 당신은 지금 홍해를 가르는 모세와 같은 존재입니다. 25:45 Like you are just the most valuable person on planet Earth. 당신은 지구상에서 가장 소중한 사람입니다. 25:47 The reason why I think what I'm talking about right here is very important is because I'm coming at this from a product and a product designer angle. 제가 여기서 이야기하는 것이 매우 중요하다고 생각하는 이유는 제가 제품과 제품 디자이너의 관점에서 접근하고 있기 때문입니다. 25:53 And in order to think out your product and how to get it right, you've got to do a lot of testing and then you've got to understand how to develop it with Claude. 제품을 구상하고 제대로 만들기 위해서는 많은 테스트를 해야 하고, 그 다음에는 Claude와 함께 개발하는 방법을 이해해야 합니다. 25:59 And if you're doing it inside the terminal and you start in the terminal right away, you're going to make lots of dumpable code. 그리고 만약 터미널 안에서 시작하고 바로 터미널에서 작업을 시작한다면, 많은 쓸모없는 코드를 만들게 될 것입니다. 26:04 And it's just going to be a big old mess. 그건 그냥 큰 엉망이 될 것입니다. 26:05 And it's just easier to do everything inside of Claude and brainstorm with Claude from the actual. 모든 것을 Claude 안에서 하고 실제로 Claude와 브레인스토밍하는 것이 훨씬 더 쉽습니다. 26:10 Just the basic simple system right here. 여기 아주 기본적인 간단한 시스템입니다. 26:12 And I think, look, you are going to be using this as not probably the senior engineer of your company. 그리고 제가 생각하기에, 보세요, 당신은 아마도 당신 회사의 수석 엔지니어로서 이걸 사용할 것입니다. 26:17 And so you want to do things and keep them in simple formats. 그래서 당신은 일을 하고 그것들을 간단한 형식으로 유지하고 싶어할 것입니다. 26:20 And so what I'm going to show you in this video is kind of dirty, simple, all right? 그래서 제가 이 영상에서 보여드릴 것은 약간 지저분하고 간단한 것입니다, 알겠죠? 26:24 And a lot of people aren't going to be starting. 그리고 많은 사람들이 시작하지 않을 것입니다. 26:26 They're like, he doesn't work in the terminal. 그들은 '그는 터미널에서 작업하지 않는다'고 생각할 것입니다. 26:28 He's not using 16 alphabetical agent skill systems. 그는 16개의 알파벳 에이전트 기술 시스템을 사용하지 않습니다. 26:31 No, this works. 아니요, 이건 작동합니다. 26:32 And it's easy for everyone to grasp, and it's easy for me to grasp. 그리고 모든 사람이 이해하기 쉽고, 저도 이해하기 쉽습니다. 26:35 So let's talk about this. 자, 이 주제에 대해 이야기해봅시다. 26:37 What we want to do before we even think about coding or starting anything is we want to think about starting a conversation with Claude about what we want to build. 코딩이나 어떤 것을 시작하기 전에 우리가 해야 할 것은, 우리가 만들고자 하는 것에 대해 Claude와 대화를 시작하는 것입니다. 26:46 Okay? 알겠죠? 26:47 And so what you're going to want to do first off is you want to describe to Claude what you're looking to build and you want to describe the intent of what you want to build and where it's going to fit into your company and what your company's trying to do with it. 그래서 당신이 가장 먼저 하고 싶은 것은 Claude에게 당신이 만들고자 하는 것과 그것의 의도, 그리고 그것이 당신 회사에서 어떤 역할을 할 것인지, 그리고 당신 회사가 그것으로 무엇을 하려 하는지를 설명하는 것입니다. 27:00 You want to explain the problem to Claude, you want to explain the problem that users have. 당신은 클로드에게 문제를 설명하고 싶어하며, 사용자가 겪고 있는 문제를 설명하고 싶어합니다. 27:03 You want to give a right rough breakdown of how you think it would look and you want to not tell Claude, okay, just build this. 당신은 이 문제가 어떻게 보일지에 대한 대략적인 구성을 제시하고 싶으며, 클로드에게 '그냥 이걸 만들어라'라고 말하지 않기를 원합니다. 27:11 You want to say, how would this look? 이것이 어떻게 보일까요? 27:13 What would be the best systems to do this with? 이걸 수행하기 위한 최상의 시스템은 무엇일까요? 27:14 What would be the best structure? 최상의 구조는 무엇일까요? 27:16 Assume that I'm a non technical founder and you need to explain this to me and don't tell me what I want to hear, push back on my ideas. 제가 비기술적인 창립자라고 가정하고, 당신이 저에게 이것을 설명해야 하며, 제가 듣고 싶어하는 것을 말하지 말고 제 아이디어에 반박해 주세요. 27:22 And so what you're going to see is me discussing with Claude in this, this instance we did. 그래서 당신이 보게 될 것은 제가 클로드와 논의하는 모습입니다. 이번 경우에 대해 이야기하고 있습니다. 27:28 I just made a scanning app today that scans our customer sites and inside sets up all the websites that they have in their tech stack. 오늘 저는 고객 사이트를 스캔하고 그들의 기술 스택에 있는 모든 웹사이트를 설정하는 스캔 앱을 만들었습니다. 27:35 Okay? 알겠습니까? 27:36 And then what it does is it passes this tech stack to the extension, so the extension knows the tech stack to go through. 그리고 그것이 하는 일은 이 기술 스택을 확장 프로그램에 전달하는 것입니다. 그래서 확장 프로그램은 어떤 기술 스택을 사용할지 알게 됩니다. 27:40 Okay? 알겠습니까? 27:41 So I pointed out and explained this all the cloud in this and I say, all right, we, this is what we need to do this. 그래서 저는 클로드에게 이 모든 것을 지적하고 설명하며, '좋습니다, 우리가 이걸 하기 위해 필요한 것입니다.'라고 말했습니다. 27:46 So how could we go and set this up? 그럼 우리는 어떻게 이걸 설정할 수 있을까요? 27:48 And so what it does is goes and gives a bunch of ideas on how this is going to work. 그것이 하는 일은 이게 어떻게 작동할지에 대한 여러 가지 아이디어를 제공하는 것입니다. 27:54 And it describes the MVP to me and I go back and forth with it like, here's what we need to do. 그리고 그것이 저에게 MVP를 설명하고, 저는 '우리가 해야 할 일은 이겁니다.'라고 왔다 갔다 합니다. 27:58 And then one of the most Important things you can do when you're planning a cloud is at tell it to constantly ask you clarifying questions on your idea. 클라우드를 계획할 때 가장 중요한 것 중 하나는 당신의 아이디어에 대해 지속적으로 명확한 질문을 하도록 지시하는 것입니다. 28:04 So you can see right here, want me to start building this or the working prototype, I can create a singer, blah, blah, blah. 여기서 보시다시피, '이걸 만들기 시작할까요? 아니면 작업 프로토타입을 만들까요? 저는 싱어를 만들 수 있습니다, blah, blah, blah.'라고 합니다. 28:09 But I say, yes, but we need to make these adjustments right here. 하지만 저는 '네, 하지만 여기서 몇 가지 조정을 해야 합니다.'라고 말합니다. 28:11 All right, all right. 좋습니다, 좋습니다. 28:13 So what you can see me doing right here is going back and planning with it. 그래서 제가 지금 하고 있는 것은 다시 계획을 세우는 것입니다. 28:17 And this is a very important example right here, because you're going to see I was not specific enough with what I was telling Claude to do. 여기 아주 중요한 예가 하나 있습니다. 왜냐하면 제가 클로드에게 시키고자 하는 일을 구체적으로 설명하지 않았기 때문입니다. 28:22 And so this was kind of a throwaway app. 그래서 이건 일종의 간단한 앱이었습니다. 28:25 This isn't someone that I was thinking super duper deeply about. 이 사람에 대해 깊이 고민하고 있었던 것은 아닙니다. 28:27 I was building this while, like doing eight different other things. 여러 가지 다른 일을 하면서 이걸 만들고 있었거든요. 28:30 Okay. 알겠습니다. 28:31 So you can see how easy this process is once you get it going. 이 과정을 시작하면 얼마나 쉬운지 보실 수 있습니다. 28:34 And so what I forgot to tell it is make it an artifact. 제가 잊고 말한 것은 이걸 아티팩트로 만들어야 한다는 것입니다. 28:36 And the reason why I'm doing all this in the, in the actual Claude, just in the browser, like a normal civilian normie, is because of one thing. 제가 실제 클로드에서, 일반 사용자처럼 브라우저에서 이렇게 하는 이유는 딱 하나입니다. 28:44 It has this artifact feature right here, which allows me to then go and build the feature out and test it inside of Claude. 여기 아티팩트 기능이 있어서, 이를 통해 기능을 구축하고 클로드 안에서 테스트할 수 있습니다. 28:52 Because I don't want to put this on my computer, I don't want to run this locally, I don't want to deal with the architecture of it yet. 저는 이걸 제 컴퓨터에 설치하고 싶지 않고, 로컬에서 실행하고 싶지도 않으며, 아키텍처에 대해 신경 쓰고 싶지 않습니다. 28:58 I don't want to build a plan how it's going to be on Versal or how I'm going to get it on manage GitHub and all that. 저는 이걸 버설에서 어떻게 운영할지, 깃허브에서 어떻게 관리할지 계획하고 싶지 않습니다. 29:04 I just don't want to do any of that right now. 지금은 그런 것들을 하고 싶지 않습니다. 29:05 Or manage the super base. 슈퍼베이스를 관리하는 것도 마찬가지입니다. 29:06 I don't want to do any of that. 저는 그런 것들을 하고 싶지 않습니다. 29:07 All right. 좋습니다. 29:08 I just want to plan out how the thing is going to work and how the system will work overall. 저는 이 시스템이 어떻게 작동할지를 계획하고 싶습니다. 29:13 Because Claude sometimes doesn't know how the system is going to work either. 왜냐하면 클로드도 때때로 시스템이 어떻게 작동할지를 모를 때가 있기 때문입니다. 29:15 A lot of the ways that we're building things, you don't really know how the final architecture is going to work. 우리가 물건을 만드는 방식 중 많은 경우, 최종 아키텍처가 어떻게 작동할지를 잘 모릅니다. 29:20 And you say, oh, maybe we want to use this different agent right here. 그리고 '아, 아마도 여기서 다른 에이전트를 사용하고 싶다'고 말하게 됩니다. 29:23 Maybe for this response we want to use Grok. 아마도 이 응답에는 그록을 사용하고 싶습니다. 29:25 Maybe for this response we want to use opus. 아마 이 응답을 위해서는 opus를 사용하고 싶을 것입니다. 29:27 And maybe the way we fetch the HTML, it's too expensive if we use OPUS to do it. 그리고 아마 HTML을 가져오는 방식이 OPUS를 사용하면 너무 비쌀 것입니다. 29:31 Let's instead use the Smart Fetch feature and let's see how that works. 대신 Smart Fetch 기능을 사용해보고, 그것이 어떻게 작동하는지 봅시다. 29:35 Oh, this HTML feature doesn't work. 오, 이 HTML 기능이 작동하지 않네요. 29:37 Let's. 합시다. 29:37 Let's fetch it like this instead. 이렇게 가져오는 것이 좋겠습니다. 29:38 And so you're going to go back and forth with it in the planning phase and figure out how the tech is actually going to work. 그래서 계획 단계에서 이것을 반복하며 기술이 실제로 어떻게 작동할지를 고민하게 될 것입니다. 29:45 Unless you're freaking Raptor. 당신이 정말 Raptor가 아니라면요. 29:47 Jesus. 제발. 29:48 Developer, you're not going to sit down and know the perfect architecture for every single app right away. 개발자님, 모든 앱에 대한 완벽한 아키텍처를 바로 알 수는 없습니다. 29:52 And what you're doing as an engineer, an agentic engineer, which I've signed myself, the certification of, of is you're, you're going to go and think of how the damn thing works and how it's going to come together and find the optimal way for it to go together. 그리고 당신이 엔지니어로서 하는 일은, 제가 인증한 대로, 이 기계가 어떻게 작동하는지, 어떻게 결합될지를 생각하고, 최적의 방법을 찾는 것입니다. 30:07 If I tell Claude, make me a tool that scrapes people's websites and tells me their tech stack, it will just make it, but it will miss so much and it won't consider if it's going to work for Hiros or how it's going to work or any of the specifics. 내가 Claude에게 사람들의 웹사이트를 스크랩해서 그들의 기술 스택을 알려주는 도구를 만들어 달라고 하면, 그것은 만들어지겠지만, 많은 것을 놓치고 Hiros에 어떻게 작동할지, 구체적인 사항을 고려하지 않을 것입니다. 30:18 And it will make non optimal solutions that could cost tons of credits or tokens or they could just not work at all. 그리고 비용이 많이 드는 비최적의 솔루션을 만들거나 아예 작동하지 않을 수 있습니다. 30:24 And it will just give me the app and I'll put it in cloud code and it won't work. 그리고 그냥 앱을 주고, 클라우드 코드에 넣으면 작동하지 않을 것입니다. 30:26 And then I, I upload this thing to GitHub, it's just a mess. 그런 다음 이걸 GitHub에 업로드하면, 그냥 엉망이 됩니다. 30:29 So this artifact step right here when you're planning allows you to go and say, all right, this is how it's going to work, this is how the rough UI is going to work for this. 그래서 이 계획 단계의 아티팩트 단계에서는 이렇게 작동할 것이라고 말할 수 있습니다. 이것이 대략적인 UI가 작동하는 방식입니다. 30:36 And then you work out all the kinks with it and you just go back and forth with Claude explaining what it's getting wrong or what's not working. 그리고 그와 관련된 모든 문제를 해결하고, Claude와 반복적으로 설명하며 무엇이 잘못되었는지, 무엇이 작동하지 않는지를 이야기합니다. 30:43 And you just work on it for a little bit in here until you get the final version of it. 그리고 최종 버전을 얻을 때까지 여기서 조금 작업합니다. 30:46 Okay. 알겠습니다. 30:47 Then when you have the final version of it, what I'm going to do is once you have a final version for the go, perfect. 그런 다음 최종 버전이 준비되면, 제가 할 일은 최종 버전이 준비되면 완벽하다고 하는 것입니다. 30:53 This is what we're trying to build. 이것이 우리가 만들고자 하는 것입니다. 30:55 So Claude, what I want you to do is I want you to create a PRD or an explanation of what this product is and you, I want you to focus on why we're making the product and the intent and the context of this, this thing we're building. 클로드, 당신에게 부탁하고 싶은 것은 이 제품이 무엇인지에 대한 PRD나 설명을 만들어 주는 것입니다. 그리고 이 제품을 만드는 이유와 의도, 그리고 우리가 만들고 있는 것의 맥락에 집중해 주셨으면 합니다. 31:08 We're not just going to go in the cloud and say, hey, make a scanner app. 우리는 단순히 클라우드에 들어가서 '스캐너 앱을 만들어라'라고 하지 않을 것입니다. 31:11 Now we know how it looks. 이제 어떻게 생겼는지 알게 되었습니다. 31:12 Great, give me the technical readout, let's go. 좋습니다, 기술적인 내용을 알려주세요, 시작합시다. 31:14 We want to make a PRD that explains everything we're doing on this product and everything about the product and how it's going to work and how the features are going to fit together and everything. 우리는 이 제품에 대해 우리가 하고 있는 모든 것과 제품에 대한 모든 정보, 어떻게 작동할 것인지, 기능들이 어떻게 결합될 것인지 등을 설명하는 PRD를 만들고자 합니다. 31:23 Okay. 알겠습니다. 31:23 This is incredibly important, not just having a description of product, but why the product is doing something. 이것은 매우 중요합니다. 제품에 대한 설명뿐만 아니라, 왜 이 제품이 어떤 일을 하는지도 중요합니다. 31:29 So when Claude starts coding later on and wherever we make changes, it knows why and what its goal is and what the it's trying to do, every single time Claude boots up, it forgets everything. 그래서 클로드가 나중에 코딩을 시작할 때, 우리가 변경하는 모든 것에 대해 그 이유와 목표를 알고 있어야 합니다. 클로드가 매번 부팅할 때마다 모든 것을 잊어버리기 때문입니다. 31:37 So if you show it an app and the app is like scanning stuff, it doesn't know why it's scanning stuff or what the point it is or why it's trying to scan things. 그래서 만약 당신이 어떤 앱을 보여주고 그 앱이 무언가를 스캔하고 있다면, 그것은 왜 스캔하는지, 그 목적이 무엇인지, 왜 무언가를 스캔하려고 하는지를 알지 못합니다. 31:44 And so it's going to forget things that you were working on before. 그래서 이전에 작업하던 것들을 잊어버리게 될 것입니다. 31:46 Okay, this is called the context window. 이것을 맥락 창이라고 부릅니다. 31:48 If you're, if you're new to this on context windows very quickly, if you're looking at this Claude for right now, if you're working in Claude, goat has 150,000 ish contact units. 만약 당신이 이 맥락 창에 대해 처음이라면, 클로드를 지금 보고 있다면, 클로드는 약 150,000개의 연락 단위를 가지고 있습니다. 31:58 What this means is that Claude's going to compact the conversation. 이것은 클로드가 대화를 압축할 것이라는 의미입니다. 32:02 And you just look at it. 그냥 그것을 바라보세요. 32:03 Think of it like this, okay, you have a book, all right, let's say after 30 pages, it's able to do is it's only able to keep so many pages at times. 이렇게 생각해 보세요. 책이 있다고 가정해 봅시다. 30페이지가 지나면, 그것은 동시에 유지할 수 있는 페이지 수가 제한되어 있습니다. 32:11 So if you start on page number one and you get to page 30 and you go past 30, that what happens is it starts forgetting everything that's on page one and knows everything all the way to page five. 그래서 1페이지에서 시작해서 30페이지에 도달하고 30페이지를 넘어가면, 1페이지의 모든 것을 잊기 시작하고 5페이지까지의 모든 것만 기억하게 됩니다. 32:19 And so it's a window. 그래서 이것은 창입니다. 32:20 It's like, it's like a view. 마치, 뷰와 같습니다. 32:21 And so if you, if you have a bunch of information that's on page one, but the context window is on page five or here, and you tell it to do something that requires the page one information, it's not going to do it well because it doesn't know that's there anymore. 그래서 만약 1페이지에 많은 정보가 있지만 맥락 창이 5페이지에 있다면, 1페이지의 정보가 필요한 작업을 시키면 잘 수행하지 못할 것입니다. 왜냐하면 더 이상 그 정보가 거기에 있다는 것을 알지 못하기 때문입니다. 32:32 Okay. 네. 32:33 So it doesn't think, it doesn't remember things. 그러니까 생각하지도 않고, 기억하지도 않아요. 32:35 It's just a screenshot of where it is in the book. 그냥 책에서 현재 위치의 스크린샷일 뿐이에요. 32:38 Okay. 네. 32:39 And so what's going to happen in cloud code is when it gets to that point, it compacts itself and summarizes everything and shrinks it down. 그리고 클라우드 코드에서 일어나는 일은 그 지점에 도달하면 스스로 압축하고 모든 것을 요약해서 줄어든다는 거예요. 32:45 Now, in the past, this used to be extremely critical. 과거에는 이게 정말 중요했어요. 32:48 This was like the core thing. 이게 핵심이었죠. 32:49 When you were coding with Claude code, you had to worry about it a lot because it got really stupid the deeper it got into the book. 클라우드 코드로 코딩할 때는 이 부분에 대해 많이 걱정해야 했어요. 책 속으로 깊이 들어갈수록 정말 멍청해졌거든요. 32:56 And so just be forgetting literally everything all the time. 그래서 literally 모든 것을 계속 잊어버리곤 했어요. 32:58 So you try to actually do things in about 150,000 chunk windows. 그래서 약 150,000개의 청크 창에서 실제로 작업을 하려고 했어요. 33:02 And so you'd work on one feature. 그래서 하나의 기능에 대해 작업했어요. 33:03 You describe everything it needs to know at the start. 시작할 때 알아야 할 모든 것을 설명했어요. 33:05 You'd open the session, get everything done in that window, then document everything, reset the loop, give it everything you just did, reset it over again. 세션을 열고 그 창에서 모든 작업을 마친 후, 모든 것을 문서화하고 루프를 초기화한 다음, 방금 한 모든 것을 다시 주고 다시 초기화했어요. 33:13 I don't do this so much anymore. 이제는 그렇게 많이 하지 않아요. 33:14 It is important. 중요한 부분이에요. 33:15 If you're building like some major feature on your software and you need cloud, be precise. 소프트웨어에서 큰 기능을 만들고 클라우드가 필요하다면, 정확하게 하세요. 33:21 Laser. 레이저처럼요. 33:22 Yes. 네. 33:22 You you need to maybe be worrying about this right now. 지금 이 부분에 대해 걱정해야 할 수도 있어요. 33:24 If you're doing a RALPH loop, which maybe some of you psychopaths are, that's essentially why the RALPH loop exists. 만약 여러분 중 일부가 RALPH 루프를 하고 있다면, 그게 바로 RALPH 루프가 존재하는 이유예요. 33:30 That said, the compacting and Claude is so good now that I haven't really had to deal with this. 그렇긴 하지만, 지금은 컴팩팅과 클로드가 정말 잘 되어 있어서 이 문제를 다룰 필요가 없었습니다. 33:36 And if you're using Codex, for example, I don't see people having to deal with this either over the there. 예를 들어 코덱스를 사용하고 있다면, 저쪽에서도 사람들이 이 문제를 다루는 것을 보지 못했습니다. 33:40 So I don't worry about this too much. 그래서 저는 이 문제에 대해 너무 걱정하지 않습니다. 33:41 You just need to be aware that that's how it looks, that's how the thing is thinking. 그냥 이렇게 보이는구나, 이렇게 생각하고 있구나 하는 것을 인지해야 합니다. 33:47 So you want to make sure in that context window, it knows what it's doing and why the it's doing it. 그래서 그 컨텍스트 창에서, 무엇을 하고 있는지, 왜 그렇게 하고 있는지를 알고 있어야 합니다. 33:52 So the reason why we're building on these documents is so when Claude is coding or getting the work, it knows why it's doing the damn thing. 우리가 이 문서들을 기반으로 구축하는 이유는 클로드가 코딩을 하거나 작업을 할 때, 왜 그렇게 하고 있는지를 알기 위해서입니다. 33:59 We don't just boot it up, give it the code for the scanning app, say, all right, we're going to need to add a feature right here that helps the the customer know whether their payment processor is connected or not. 우리는 그냥 부팅하고 스캐닝 앱의 코드를 주고, '좋아, 여기서 고객이 결제 프로세서가 연결되어 있는지 여부를 알 수 있도록 기능을 추가해야 해'라고 말하지 않습니다. 34:08 Claude won't notice. 클로드는 이를 인식하지 못할 것입니다. 34:09 It's supposed to be related to the ad account feature because it doesn't know what the app is. 이것은 광고 계정 기능과 관련이 있어야 하는데, 앱이 무엇인지 모르기 때문입니다. 34:13 This is why we give it this right here and this full breakdown of why we're doing it, how the product works and how the features work together, then what we're going to have it build is an architecture layout so that whenever Claude knows when it's building, it knows exactly how the app all fits together and where everything is and where it's all located at. 그래서 우리는 여기서 이렇게 하고, 왜 이렇게 하는지, 제품이 어떻게 작동하는지, 기능들이 어떻게 함께 작용하는지에 대한 전체적인 설명을 제공합니다. 그러면 클로드가 구축할 것은 아키텍처 레이아웃이어서, 클로드가 구축할 때마다 앱이 어떻게 모두 맞물려 있는지, 모든 것이 어디에 위치해 있는지를 정확히 알 수 있습니다. 34:27 This is the same exact reason we're doing the prd. 이것이 우리가 prd를 하는 정확한 이유입니다. 34:29 And then we're going to have it create a build plan. 그리고 나서 우리는 그것이 빌드 계획을 만들도록 할 것입니다. 34:31 It's going to step by step, systematically go and tell it everything that needs to be done to build this app out. 단계별로 체계적으로 이 앱을 구축하기 위해 필요한 모든 것을 알려줄 것입니다. 34:37 This is when we're going to start coding. 이때부터 우리는 코딩을 시작할 것입니다. 34:39 So then we're going to take this on over to Claude Code and I want to show you how we built this. 그래서 우리는 이것을 클라우드 코드로 가져가고, 어떻게 이것을 구축했는지 보여드리고 싶습니다. 34:44 This is a more simpler app. 이것은 더 간단한 앱입니다. 34:45 I've had ones where massive, big old file bases working with. 저는 대규모 파일 기반으로 작업한 경험이 있습니다. 34:48 And I just want to show you the basics right here. 그래서 여기서 기본적인 것들을 보여드리고 싶습니다. 34:50 We're going to take this over in the cloud code and this is when we're going to get to work and there's processes we want to do before that. 우리는 이것을 클라우드 코드로 가져가고, 이때부터 작업을 시작할 것이며, 그 전에 해야 할 과정들이 있습니다. 34:55 Okay. 좋습니다. 34:56 So I don't think I'm going to be able to access my conversation history right here, which is going to be okay, that's fine. 그래서 여기서 제 대화 기록에 접근할 수 없을 것 같아요. 괜찮습니다, 괜찮아요. 35:04 I'm just going to go through the process that I'd Be doing it from the start. 저는 그냥 처음부터 진행하는 과정을 거칠 거예요. 35:06 All right, so the first thing I'm going to do right here is, you can see I have all these files right here. 좋아요, 그래서 제가 여기서 가장 먼저 할 일은, 여기 모든 파일이 보인다는 거예요. 35:12 Okay. 알겠어요. 35:13 We have everything and how it's going to be built out. 우리는 모든 것을 가지고 있고, 어떻게 구성될 것인지에 대한 내용입니다. 35:16 We also have a Cloud MD file. 우리는 또한 Cloud MD 파일도 가지고 있어요. 35:18 All right, so here's the process we're going to be using. 좋아요, 그래서 우리가 사용할 과정은 이렇습니다. 35:22 The first thing we're going to do is we're going to boot up Claude code and I'm not going to do it because I want this session right here. 가장 먼저 할 일은 Claude 코드를 부팅하는 건데, 저는 이 세션을 유지하고 싶어서 하지 않을 거예요. 35:27 You can always just resume the conversation later on. 언제든지 나중에 대화를 재개할 수 있습니다. 35:30 That's a lot what I do. 그게 제가 하는 일이에요. 35:31 But so the first thing you're going to do is you're actually going to go and I'm going to paste in this Cloud MD file right here. 그래서 가장 먼저 할 일은 실제로 가서 이 Cloud MD 파일을 여기 붙여넣는 거예요. 35:37 That gives it our working relationship rules and everything it should know about the software that we're building right here. 이 파일은 우리가 여기서 만들고 있는 소프트웨어에 대해 알아야 할 작업 관계 규칙을 제공합니다. 35:42 Okay, and the most important thing you have in here is these rules that I have first. 좋아요, 그리고 여기서 가장 중요한 것은 제가 처음에 가진 이 규칙들입니다. 35:47 And so what these rules basically do is give it very good guardrails of what, how to behave when looking at code and interacting. 이 규칙들은 기본적으로 코드와 상호작용할 때 어떻게 행동해야 하는지에 대한 매우 좋은 가이드라인을 제공합니다. 35:55 This is actually copied from another YouTuber who I'm going to link below. 이 내용은 제가 아래에 링크할 다른 유튜버에게서 복사한 것입니다. 35:58 I forgot his name because there's so many making clogged code. 그의 이름을 잊어버렸어요. 클라우드 코드를 만드는 사람이 많아서요. 36:01 But it will be a link below. 하지만 아래에 링크가 있을 거예요. 36:02 So you get the credit. 그래서 당신이 공로를 인정받을 수 있습니다. 36:03 Whoever you are just gonna steal everything you said in your video. 당신이 누구든지, 당신의 영상에서 말한 모든 것을 훔칠 거예요. 36:07 Okay? 알겠죠? 36:07 All right, so look, what's going on is I have my core rules right here. 좋아요, 지금 무슨 일이 일어나고 있는지 보세요. 여기 제 핵심 규칙이 있습니다. 36:12 Understand before acting. 행동하기 전에 이해하세요. 36:13 So like, if you see coding about to work on something, read the code base and relevant files related to it. 예를 들어, 무언가 작업을 하려고 하는 코드를 보게 되면, 코드베이스와 관련 파일을 읽어보세요. 36:18 Don't just work on it. 그냥 작업하지 마세요. 36:19 Check in before you go and do something huge to the software before major change, check with me. 소프트웨어에 큰 변경을 하기 전에 저와 확인하세요. 36:23 Communicate clearly, all right? 명확하게 소통하세요, 알겠죠? 36:25 Every step of the way, provide a high level explanation of what you're doing. 매 단계마다 당신이 하고 있는 일에 대한 높은 수준의 설명을 제공하세요. 36:28 So when it's coding out stuff, it's telling me what it's doing. 그래서 코딩을 할 때, 무엇을 하고 있는지 저에게 알려주는 겁니다. 36:30 I'm like, okay, that's what you're up to. 저는 '아, 그게 당신이 하고 있는 일이구나'라고 생각합니다. 36:31 Little. 조금. 36:32 And if I see it doing stuff that doesn't make any sense, which shouldn't be happening because I, I get the plan from Claude before it codes. 그리고 만약 제가 이해가 안 되는 일을 하고 있다면, 그건 일어나서는 안 되는 일입니다. 왜냐하면 저는 코드가 작성되기 전에 Claude에게 계획을 받기 때문입니다. 36:39 If I see it doing something or it clearly misunderstood something. 제가 무언가를 하고 있거나 분명히 무언가를 잘못 이해하고 있는 것을 보면요. 36:42 For example, we want a TXT readout and it says starting to make the PDF readout. 예를 들어, 우리는 TXT 출력이 필요하고, 그것이 PDF 출력을 만들기 시작한다고 말합니다. 36:45 I'm whoa, whoa, whoa, we want to do txt exports, not PDFs. 저는 '잠깐, 잠깐, 우리는 PDF가 아니라 TXT 내보내기를 원해요.'라고 생각합니다. 36:48 You stop it. 그걸 멈추세요. 36:49 It continues it again. 그것이 다시 계속됩니다. 36:50 All right, Simplicity. 좋아요, 단순함입니다. 36:51 We want to have it make simple solutions that don't change. 우리는 변하지 않는 간단한 솔루션을 만들기를 원합니다. 36:54 Large parts of the code. 코드의 큰 부분들입니다. 36:55 Cloud will make some very creative. Cloud는 매우 창의적인 것을 만들 것입니다. 36:57 We don't want creative all right? 우리는 창의적인 건 원하지 않아요, 알겠죠? 36:58 We don't want, like, endless ways to backdrop the other code. 우리는 다른 코드를 배경으로 하는 끝없는 방법을 원하지 않아요. 37:01 We want stone caveman code that is simple, all right? 우리는 간단한 석기 시대의 코드를 원해요, 알겠죠? 37:04 And then we want it to always maintain the documentation of the work it's doing. 그리고 우리는 그것이 수행하는 작업의 문서를 항상 유지하기를 원해요. 37:08 So you can see these. 그래서 이걸 볼 수 있어요. 37:09 These files right here are going to constantly be updated. 여기 있는 파일들은 계속해서 업데이트될 거예요. 37:11 So when I boot up a new version of Claude, or Claude is way outside of its context window of where it is, it's going to look at these files and it's going to know exactly what the last claw did and what's going on. 그래서 제가 새로운 버전의 클로드를 실행할 때, 또는 클로드가 자신의 맥락 창을 벗어났을 때, 이 파일들을 보고 마지막 클로드가 무엇을 했는지, 지금 어떤 상황인지 정확히 알게 될 거예요. 37:19 So all these things that it's doing are constantly upd on top of the memory that's compacting over here from Claude, which is still actually very functional and good. 그래서 지금 하고 있는 모든 것들은 클로드에서 압축되고 있는 메모리 위에 계속 업데이트되고 있어요. 여전히 매우 기능적이고 좋습니다. 37:27 The one I have right here is, I say, you are the cto. 제가 여기서 말하는 것은, 당신이 CTO라는 거예요. 37:30 You're also responsible for the entire product. 당신은 전체 제품에 대해서도 책임이 있어요. 37:32 I copied this from a guy on Lenny's podcast. 이건 제가 레니의 팟캐스트에서 한 사람에게서 복사한 거예요. 37:34 Very good podcast. 아주 좋은 팟캐스트예요. 37:35 If you're building stuff or doing stuff for SaaS companies or for your SaaS company, and what I have it basically said here is, I'm a fucking idiot, you're a cto. 만약 당신이 SaaS 회사나 당신의 SaaS 회사를 위해 무언가를 만들거나 하고 있다면, 제가 여기서 기본적으로 말하는 것은, 저는 정말 바보고, 당신은 CTO라는 거예요. 37:44 I'm going to give you lots of ideas, but assume I don't know shit and don't just agree with me. 저는 많은 아이디어를 드릴 건데, 제가 아무것도 모른다고 가정하고 저와 그냥 동의하지 마세요. 37:47 Push back on my ideas and find the most optimal code solutions solution. 제 아이디어에 반론을 제기하고 가장 최적의 코드 솔루션을 찾아주세요. 37:50 If you don't do this, you're going to give Claude a terrible idea and it's going to be like, seems like a good idea, Alex. 이걸 하지 않으면, 당신은 클로드에게 끔찍한 아이디어를 줄 것이고, 클로드는 '좋은 아이디어인 것 같아, 알렉스'라고 할 거예요. 37:56 I guess I'll get to work. 그럼 저는 일을 시작해야겠네요. 37:58 And then it codes a backdoor to pornhub in the back of your software because you were an idiot and described and mistyped something in. 그리고 그러면 당신의 소프트웨어 뒤에 포르노허브의 백도어를 코딩할 거예요, 왜냐하면 당신이 바보였고 뭔가를 잘못 설명하고 잘못 입력했기 때문이죠. 38:05 Or I don't. 아니면 제가 하지 않을 수도 있어요. 38:06 I don't know. 저는 잘 모르겠어요. 38:07 Okay, it's gonna. 좋아요, 진행될 거예요. 38:07 It's not gonna do that, but you can come up with really stupid ideas and it'll be like, it should be like, hey, that's a stupid idea. 그렇게 되지는 않겠지만, 정말 바보 같은 아이디어를 생각해낼 수 있고, 그럼 '이건 바보 같은 아이디어야'라고 말할 거예요. 38:14 We should go about it this way. 이런 식으로 접근해야 합니다. 38:16 You know, like, yeah, okay, maybe we do that. 음, 맞아요, 그걸 해볼까요. 38:18 And it will explain to you why it's a stupid idea. 그리고 왜 그게 바보 같은 아이디어인지 설명해 줄 거예요. 38:19 So you learn. 그래서 배우게 되는 거죠. 38:20 So we put this cloud MD file in first. 먼저 이 클라우드 MD 파일을 넣습니다. 38:22 Then we say it will. 그 다음에 그렇게 될 거라고 말합니다. 38:24 It will look at the Cloud MD file. 클라우드 MD 파일을 살펴볼 거예요. 38:26 By default, the cloud MD file is going to look at it before it starts doing everything. 기본적으로 클라우드 MD 파일은 모든 작업을 시작하기 전에 그것을 살펴볼 것입니다. 38:30 Every single time you say, look, look at all these files that I just gave you. 당신이 '봐, 내가 방금 준 모든 파일을 봐'라고 말할 때마다요. 38:35 Study them to the level that you're able to deeply discuss them. 그것들을 깊이 논의할 수 있을 정도로 공부하세요. 38:38 Don't just look at them. 그냥 보는 것만으로는 안 됩니다. 38:39 Don't just tell it. 그냥 말하는 것만으로는 안 됩니다. 38:40 They will then go skim it. 그들은 그러고 나서 대충 훑어볼 거예요. 38:41 Look at them to the point you deeply understand them and are able to discuss. 그것들을 깊이 이해하고 논의할 수 있을 때까지 살펴보세요. 38:46 Notify me when you've done this. 이 작업을 완료하면 저에게 알려주세요. 38:47 It's going to spend a lot of tokens. 많은 토큰을 소모할 거예요. 38:48 We have a little token scanner down here. 여기 아래에 작은 토큰 스캐너가 있습니다. 38:50 It tells us the context window. 그것이 우리의 컨텍스트 윈도우를 알려줍니다. 38:51 You can see right here, we're at 126,000 tokens. 여기 보시면, 우리는 126,000개의 토큰에 있습니다. 38:53 At 150, it's going to reset. 150에 도달하면, 리셋될 것입니다. 38:55 And I'm going to know that, hey, some of the things we talked about are going to be forgotten. 그럼 제가 알게 될 것은, 우리가 이야기했던 것 중 일부는 잊혀질 것이라는 점입니다. 39:00 I don't pay attention to this that much anymore because it's. 이제는 이걸 그다지 신경 쓰지 않아요, 왜냐하면. 39:03 It's context window and compacting works great. 맥락 창과 압축 작업이 잘 작동하거든요. 39:06 And I assume here in a few months when this upgrades again, I don't think context windows are even going to be much of an issue here in the future. 몇 달 후에 이게 다시 업그레이드되면, 저는 미래에 맥락 창이 큰 문제가 되지 않을 것이라고 생각합니다. 39:12 So. 그래서. 39:12 So this is kind of an ancient skill set. 이건 일종의 고대 기술 세트입니다. 39:14 Even now, it's still relevant. 지금도 여전히 관련이 있습니다. 39:16 But just vibe with me on that. 그냥 저와 함께 느껴보세요. 39:17 All right, so look, I'm going to say read these all to the point of deeply understanding, then tag me. 좋아요, 그러니까, 저는 여러분이 이 모든 것을 깊이 이해할 때까지 읽어보라고 할 것입니다. 그 후에 저를 태그해 주세요. 39:21 It's going to tag me and say, hey, now I understand this. 그럼 저를 태그하고, 이제 이해했다고 말할 것입니다. 39:23 I say, okay, we're going to build this from scratch, but ask me any clarifying questions before you get going. 저는, 알겠어요, 이걸 처음부터 만들 건데, 시작하기 전에 저에게 명확한 질문을 해보세요. 39:28 Now, if you're new to this, what I really suggest doing is sitting down and going with it phase by phase and having it build something out one phase at a time. 이게 처음이시라면, 제가 정말 추천하는 것은 앉아서 단계별로 진행하고, 한 번에 한 단계씩 뭔가를 만들어 나가는 것입니다. 39:35 Because depending on the complication and how complicated what you're building is, you don't want it to go and build everything all at once. 왜냐하면 복잡성에 따라, 여러분이 만들고 있는 것이 얼마나 복잡한지에 따라, 한 번에 모든 것을 만들도록 하고 싶지 않기 때문입니다. 39:40 Once this app right here, I'm like, look, just go build the entire thing and I'm going to go get. 이 앱이 여기서, 저는, 그냥 전체를 만들어 보라고 할 것이고, 저는 가서. 39:44 I'm going to go make some noodles or something. 면을 좀 만들러 갈 것입니다. 39:46 All right? 알겠죠? 39:47 And so it just goes to this entire checklist that we built for it and builds the entire thing. 그래서 이건 우리가 만든 전체 체크리스트를 따라가서 전체를 만듭니다. 39:50 I come back 30 minutes later and I have the working app. 30분 후에 돌아오니, 작동하는 앱이 있습니다. 39:54 Cool. 멋지네요. 39:54 You don't want to do that for everything. 모든 것에 대해 그렇게 할 필요는 없습니다. 39:55 There are some things where you actually want to sit with it phase by phase and really pay attention to the parts that matter. 실제로 단계별로 앉아서 중요한 부분에 집중해야 하는 것들이 있습니다. 40:00 All right, so anyways, what we're going to then do is I'm going to say, ask me any clarified questions for this, because sometimes the things that work over in Claude on the AI chat are not going to be the same over here. 자, 어쨌든 우리가 할 일은, 이와 관련해 명확한 질문을 해달라고 말씀드리는 것입니다. 왜냐하면 AI 채팅에서 Claude에서 작동하는 것들이 여기서는 동일하지 않을 수 있기 때문입니다. 40:12 And it's going to need some questions and answers, and it's going to think about some things before it develops it. 그리고 몇 가지 질문과 답변이 필요할 것이고, 그것이 개발되기 전에 몇 가지를 생각해야 할 것입니다. 40:16 So you tell to ask me clarifying questions. 그러니 저에게 명확한 질문을 해달라고 말씀해 주세요. 40:18 It's going to ask you questions in a list right here. 여기서 질문 목록을 요청할 것입니다. 40:20 And you just answer the questions and say, okay, but should this feature be here or should be here? 그리고 질문에 답하고, '좋아요, 그런데 이 기능은 여기 있어야 하나요, 아니면 여기 있어야 하나요?'라고 말씀해 주세요. 40:25 Should this. 이것이 있어야 하나요. 40:27 Should the way it exports files. 파일을 내보내는 방식은 어떻게 해야 하나요. 40:29 Should it be saved like this or saved like this? 이렇게 저장해야 하나요, 아니면 이렇게 저장해야 하나요? 40:31 This feature makes no sense. 이 기능은 의미가 없습니다. 40:32 Can you clarify how this works? 이게 어떻게 작동하는지 설명해 주실 수 있나요? 40:33 It's going to ask you to things. 그것이 당신에게 몇 가지를 요청할 것입니다. 40:34 You clarified it, it's going to get to work. 당신이 그것을 명확히 하면, 작업을 시작할 것입니다. 40:36 Now. 이제. 40:37 One little tip I'm going to give you before you get started with this, is when you're working with it, and this is something I always forgot to do, is when you have Claude building out these things, be very specific about where you're going to store it at or where you're going to upload it to. 시작하기 전에 드릴 작은 팁은, 작업할 때, 제가 항상 잊어버리는 것인데, Claude가 이러한 것들을 만들 때, 어디에 저장할 것인지 또는 어디에 업로드할 것인지에 대해 매우 구체적으로 말씀하셔야 한다는 것입니다. 40:50 If you're new to this, you're not going to understand that. 이것이 처음이라면 이해하지 못할 것입니다. 40:52 So you need to ask it what's the. 그래서 그것에게 어떻게 사용되기를 원하는지 물어봐야 합니다. 40:54 You need to tell it how you want it to be used. 어떻게 사용되기를 원하는지 알려줘야 합니다. 40:55 So if you're putting an app online that everybody's going to use or your. 모두가 사용할 앱을 온라인에 올린다면, 당신의 팀도 사용할 것이고, 다양한 플러그인을 여러 곳에 추가할 것입니다. 40:58 Your team is going to be using it, you're going to be putting in different plugins, places. 저는 Veral에 물건을 올리는 것을 정말 좋아하고, Supabase에 저장하는 것도 좋아합니다. 41:01 I really like just putting things on Veral and I like storing things on Supabase. 하지만 미리 물어봐야 합니다. 41:06 But you need to ask it beforehand. 좋습니다, 제가 이렇게 인터넷에 저장할 것이라고 상상해봅시다. 41:08 All right, let's imagine I'm going to be storing this on the Internet in this way. 이것이 바로 제 팀이 접근할 방식입니다. 41:11 This is exactly how my team's going to be accessing it. 이것을 위한 최상의 인프라는 무엇일까요? 41:13 What's the best infrastructure for this? 간단하고 이렇게 작동하며 유지 관리가 쉬워야 합니다. 41:15 So that it's simple and works in this way and is easy to maintain. 그리고 대부분의 경우, 아, 이 사람은 자신의 컴퓨터에서 로컬로 실행하지 않을 것이라고 생각할 것입니다. 41:21 And so it's going to think most of the time, oh, okay, so this guy is not going to be running it locally on his computer. 그는 웹사이트의 어딘가에서 Python으로 실행하지 않거나 이상한 것을 실행하지 않을 것입니다. 41:26 He's not going to be running it off of Python on the website somewhere or some weird thing. 이상한 방식으로 실행되지 않을 것입니다. 41:29 It's not going to be running in this weird winging thing. 왜냐하면 그것이 구축할 때 가장 최적의 방법에 대해 생각할 것이기 때문입니다. 41:31 Because what it will do when it's building things out is it will just think about the most optimal way to build it. 어디에 배포할 것인지와 어떤 용도로 사용할 것인지에 대한 맥락을 주지 않으면. 41:36 If you don't give it context of where you're going to deploy it at and what it's going to be used for. 그것은 그것을 고려하지 않을 것입니다. 41:40 It's not going to consider that. 좋습니다, 당신이 맞출 수도 있고, 아닐 수도 있습니다. 41:41 Okay, so you might get it right, you might not. 이것이 당신이 코딩할 때 생각해야 할 사항입니다. 41:43 This is the stuff you have to think about when you're coding with this. 그리고 이것이 당신이 엔지니어링해야 할 방법입니다. 41:45 And this is how you have to engineer. 당신은 생각해야 하거나 알아야 합니다. 41:46 You have to think about or know. 이것이 가장 중요한 부분입니다. 41:49 This is the most important part. Claude에게 미리 무엇을 물어봐야 올바른 엔지니어링 구조와 정보를 얻을 수 있는지 알아야 합니다. 41:50 Know what to ask Claude beforehand to bring the right engineering structure and information out of Claude to tell you. 41:57 You have to be aware of what you don't know know. 자신이 모르는 것을 인식해야 합니다. 41:59 So telling and giving Claude context and asking it to ask you questions about that context is the best way to find out. 그래서 Claude에게 맥락을 설명하고 그에 대해 질문을 하도록 요청하는 것이 가장 좋은 방법입니다. 42:04 For example, if you're starting off and you don't know the Best, the best stack to build this on, you need to say this is how I intend to use this cloud. 예를 들어, 시작하는 단계에서 가장 적합한 스택을 모르신다면, 이 클라우드를 어떻게 사용할 것인지에 대해 말씀하셔야 합니다. 42:11 This is the context for this. 이것이 바로 그 맥락입니다. 42:12 What's the best stack? 가장 좋은 스택은 무엇인가요? 42:13 This is this. 이것이 바로 그것입니다. 42:14 Okay, when you build the system that we're building right here, detectable build outs, what you need to do is build it around that stack. 좋습니다, 우리가 여기서 구축하고 있는 시스템, 즉 감지 가능한 빌드 아웃을 만들 때, 그 스택을 중심으로 구축해야 합니다. 42:20 Now there you go. 자, 이제 시작해 보세요. 42:21 A lot of people don't do that step and so they end up with all these weird ass stacks. 많은 사람들이 이 단계를 건너뛰어서 이상한 스택을 갖게 됩니다. 42:24 Like Claude gave me an output in Python. Claude가 저에게 파이썬으로 출력을 줬습니다. 42:25 I'm not going to be running this locally. 저는 이걸 로컬에서 실행할 생각이 없습니다. 42:27 What a idiot. 정말 바보 같네요. 42:28 You're the idiot. 당신이 바보입니다. 42:29 Not, not the LLM. LLM은 아닙니다. 42:30 All right, so that said, what you're going to do is I'm. 좋습니다, 그렇게 말했으니, 당신이 할 일은 제가. 42:33 This is the overall process to get something built. 이것이 무언가를 구축하기 위한 전체 과정입니다. 42:35 Okay, this, this right here in this understanding I just gave you is like 9, 10 of the law. 좋습니다, 제가 방금 드린 이 이해는 법칙의 9, 10에 해당합니다. 42:39 If you understand this, you can kind of move on to anything else. 이해하신다면, 다른 어떤 것으로도 나아갈 수 있습니다. 42:41 But I'm going to give you the next steps after this anyways, because why not? 하지만 어쨌든 다음 단계도 알려드릴게요, 왜냐하면 그럴 필요가 있으니까요. 42:44 So what's going to happen is you're going to have this built out and then you're going to, in my opinion, what, what you want to structure it as is say look, we're going to run this locally first, but then we're going to upload it to GitHub and then we're going to load it up somewhere else. 그래서 일어날 일은 이걸 구축한 후, 제 생각에는 이렇게 구조화하고 싶으신 거죠, 먼저 로컬에서 실행할 것이고, 그 다음에 GitHub에 업로드하고, 다른 곳에 올릴 것입니다. 42:54 So consider it working locally and on the way Internet, okay? 그러니 로컬에서 작동하는 것과 인터넷에서 작동하는 것을 고려해 보세요, 알겠죠? 42:58 On, on a different website, versa, whatever you guys want to call putting online. 다른 웹사이트에서, 또는 여러분이 온라인에 올리는 것을 뭐라고 부르든지 간에요. 43:03 And so that's going to make sure that when it goes and builds these things out, it's going to build your environment, your folder where basically all your API keys and everything is set correctly. 그래서 이 작업을 수행할 때, 여러분의 환경과 API 키가 모두 올바르게 설정된 폴더를 구축할 것이라는 점을 확실히 해줄 것입니다. 43:10 And it's going to make it so that it works locally on your computer, but when you upload it, it's going to work there too. 그리고 여러분의 컴퓨터에서 로컬로 작동하도록 만들 것이지만, 업로드하면 거기에서도 작동할 것입니다. 43:15 Because using things that work on your computer are not going to work the same way they work on the Internet. 왜냐하면 여러분의 컴퓨터에서 작동하는 것들이 인터넷에서는 같은 방식으로 작동하지 않기 때문입니다. 43:18 Okay. 알겠죠. 43:19 So anyways it's going to go and then launch it locally and then you're going to do all your testing there, there. 어쨌든 로컬에서 실행되고, 그곳에서 모든 테스트를 진행할 것입니다. 43:24 Okay. 알겠죠. 43:25 And so pow. 그래서 팡. 43:25 I chuck something in. 뭔가를 넣어보겠습니다. 43:26 Boom. 붐. 43:27 I got a full hyros report and everything. 전체 하이로스 보고서와 모든 것이 나왔습니다. 43:29 We're get in there now. 이제 들어가고 있습니다. 43:30 We got the integration checklist and I can build all sorts of features and an API call into this and all sorts of neat gizmos and stuff like that. 통합 체크리스트가 있고, 다양한 기능과 API 호출을 구축할 수 있으며, 여러 가지 멋진 기기와 그런 것들을 만들 수 있습니다. 43:36 So now what I want to do is give you some, some basic rules of thumb when you're building stuff because you're just going to kind of get the gist of this. 그래서 이제 제가 여러분에게 몇 가지 기본적인 규칙을 알려드리고 싶습니다. 왜냐하면 여러분은 이 내용을 대충 이해하게 될 것이기 때문입니다. 43:41 And if you're if you need any more steps after this, you're just being a big baby. 그리고 만약 이 이후에 더 많은 단계가 필요하다면, 여러분은 그냥 큰 아기일 뿐입니다. 43:46 All right, you got enough, you got enough information. 좋아요, 여러분은 충분한 정보를 가지고 있습니다. 43:48 Go get in the water. 물속으로 들어가세요. 43:48 Go figure it out. 스스로 해결해 보세요. 43:49 Out. 나가세요. 43:49 All right, you're going to flap around, you make some mistakes. 좋아요, 당신은 여기저기서 실수를 하게 될 거예요. 43:51 It's fine. 괜찮습니다. 43:52 All right, you're going to go build some apps. 좋아요, 이제 앱을 만들어 볼 거예요. 43:54 Wrong. 틀렸습니다. 43:54 You're going to do some things, you're not going to learn and get it right the first time. 당신은 여러 가지를 시도할 것이고, 처음부터 제대로 배우고 맞추지는 못할 거예요. 43:58 That's fine. 괜찮습니다. 43:58 All right, it's fine. 좋아요, 괜찮습니다. 43:59 So I want to give you some basic things right now that you need to be thinking about, though, when, when you're building these apps. 그래서 지금 앱을 만들 때 생각해야 할 몇 가지 기본적인 것들을 알려드리고 싶습니다. 44:05 So you're going to run in the bugs and Claude's going to build things wrong, and it's going to build things wronger and wronger based on how badly you are at figuring out what's wrong with Claude. 당신은 버그를 만나게 될 것이고, 클로드는 잘못된 것을 만들 것이며, 당신이 클로드의 문제를 파악하는 데 얼마나 서투르냐에 따라 점점 더 잘못된 것들이 만들어질 것입니다. 44:14 If you're able to. 당신이 할 수 있다면. 44:15 To set Claude up to win, it's going to figure out what's wrong with things very quickly. 클로드가 성공할 수 있도록 설정하면, 문제를 매우 빠르게 파악할 것입니다. 44:19 If you don't set it up to win, it's going to make all sorts of weird things for this. 성공할 수 있도록 설정하지 않으면, 이상한 것들이 많이 만들어질 것입니다. 44:24 So what you're going to do when you test an app, let's say I go and put this up and it gives me a bunch of weird stuff right here. 앱을 테스트할 때, 예를 들어 이걸 올려놓고 이상한 것들이 나왔다고 가정해봅시다. 44:29 What I want to do with Claude, if it's an obvious bug, like something just missing, I'm just going to say, this is missing. 클로드와 함께 하고 싶은 것은, 만약 명백한 버그가 있다면, 예를 들어 뭔가가 빠졌다면, 저는 그냥 '이게 빠졌습니다'라고 말할 것입니다. 44:34 Fix it, please. 수정해 주세요. 44:34 But if it's more of a intangible bug, like the. 하지만 만약 더 무형의 버그라면, 예를 들어. 44:38 The information is coming back wrong or things are displaying wrong, you need to not just tell it to fix something, you need to think about how it. 정보가 잘못 돌아오거나, 것들이 잘못 표시된다면, 단순히 뭔가를 고치라고 말하는 것만으로는 부족합니다. 그것이 어떻게. 44:43 It affects other parts of the software. 소프트웨어의 다른 부분에 영향을 미치는지 생각해야 합니다. 44:46 Okay, so you need to say, call it. 좋아요, 그래서 당신은 이렇게 말해야 합니다. 44:48 All right, this is happening right here. 좋아요, 여기서 이런 일이 일어나고 있습니다. 44:50 And if it's something that consistently keeps happening, you say, all right, let's think deeply about why this is happening. 그리고 만약 이런 일이 계속 발생한다면, 그 이유에 대해 깊이 생각해보자고 하세요. 44:55 Find out why it's happening, and then give me multiple fixes. 왜 이런 일이 발생하는지 알아보고, 그 다음에 여러 가지 해결책을 제시해 주세요. 44:57 And while thinking about other problems that could occur after this fix. 그리고 이 수정 후에 발생할 수 있는 다른 문제들에 대해서도 생각해보세요. 45:01 Okay? 알겠죠? 45:02 And then what you need to do is when it gives the fixes that are listing out, you need to be thinking about and looking at the app and how it's coming back. 그리고 수정 사항이 나열될 때, 앱을 살펴보며 어떻게 돌아오는지 생각해야 합니다. 45:07 So, for example, with that, that, with that integration app, I showed you where the. 예를 들어, 제가 보여드린 그 통합 앱과 관련해서. 45:12 The system was working, what kept happening is Claude got out of sync with the rule system. 시스템이 작동하고 있었지만, 클로드가 규칙 시스템과 동기화가 맞지 않게 되었어요. 45:18 So how the, how it reads the. 그래서 TXT 문서를 어떻게 읽는지. 45:19 TXT documents, how it. TXT 문서가 어떻게 작성되는지, 그래서 재작성 가이드가 있습니다. 45:21 How the TXT documents are written, so it has a rewriting guide. 그래서 우리는 이를 바탕으로 문서를 재작성합니다. 45:25 So we rewrite the documents based on this. 읽기 위해 사용하는 시스템이 있고, 이를 표시하는 또 다른 시스템이 있습니다. 45:26 There's a system it uses to read it and then there's another system that displays it. 그리고 이 모든 것은 항상 동기화되어 있어야 합니다. 45:30 And these all have to be in sync at all times. 하지만 이들은 동기화되어 있지 않았고, 그래서 저는 하나를 계속 업데이트했습니다. 45:32 And these weren't in sync, so I kept updating one. 다른 하나는 바로 그 자리에서 제대로 작동하고 있었어요. 45:34 Another one was working right there. 그래서 저는, 알겠어요, 전체 앱을 살펴보고 코드 베이스를 확인해서 여기서 무엇이 동기화되지 않는지 보자고 했습니다. 45:35 So I said, all right, let's look at the overall app and let's look at the code base and see what's out of sync here. 그리고 제가 그렇게 하지 않았다면, 저는 하나의 문제를 해결하고 있었지만 다른 문제가 발생하는 끝없는 루프에 빠졌을 것입니다. 45:40 And if I hadn't done that, it would just kept going in that endless loop where I was fixing one thing, but it was breaking another thing. 그래서 여러분은 앉아서 코드 베이스를 살펴보라고 요청해야 하고, 코드 베이스에서 어떤 일이 일어나고 있는지, 어디서 잘못되고 있는지, 동기화가 맞지 않는 부분과 가능한 해결책이 어디서 나타날 수 있는지를 생각해야 합니다. 45:45 And so you have to sit down and ask it to look at the code base and you have to sit through and think about what's happening in your code base and where it's going wrong at and where things are out of sync and where the possible solution could be popping up at. 왜냐하면 클로드는 단지 이 한 가지 문제를 해결하라고 하면 그 문제를 해결하겠지만, 다른 문제가 그 문제와 관련이 있다는 것을 알지 못하기 때문입니다. 명확하게 설명하지 않으면요. 45:56 Because Claude doesn't know if you say just fix this one thing, it's going to go fix that one thing, but doesn't know this other thing is relevant to the other thing, unless you make it clear. 그래서 그 후에 제가 한 일은 클로드 MD를 업데이트해서 이 것들이 항상 동기화되어야 한다고 말하는 것이었습니다. 그 이후에는 코드가 없어야 합니다. 46:04 And so then what I did after that is I made an updated the Claude MD to say these things must always be in sync, no codes after that. 46:11 You have to think about where the bug occurred, why it's happening, and then create rules so it doesn't happen again, especially context or not rules, context. 버그가 발생한 위치와 그 이유를 생각한 다음, 다시는 발생하지 않도록 규칙을 만들어야 합니다. 특히 맥락이나 규칙에 대한 것입니다. 46:21 So CLAUDE is aware of it. 그래서 CLAUDE는 그것을 인지하고 있습니다. 46:23 For example, with the extension as well. 예를 들어, 확장 프로그램과 관련해서도 그렇습니다. 46:24 There was a, there was a, a catching issue with Chrome and Chrome kept not updating the Catch. Chrome에서 캐치 문제가 있었고, Chrome이 캐치를 업데이트하지 않고 있었습니다. 46:30 And so we'd upload something and it would show the wrong thing and it would shoot back Claude the wrong code. 그래서 우리가 뭔가를 업로드하면 잘못된 것이 표시되고, 잘못된 코드가 Claude에게 전송되었습니다. 46:33 But Claude didn't know Chrome was, was not catching, so we needed to go and test it. 하지만 Claude는 Chrome이 캐치를 하지 않고 있다는 것을 몰랐기 때문에, 우리는 테스트를 해야 했습니다. 46:38 And so I say, what could the issue possibly be? 그래서 저는, 문제가 무엇일 수 있을까?라고 말했습니다. 46:40 It gave me three different issues. 그것은 세 가지 다른 문제를 제시했습니다. 46:41 One of them was the catching issue. 그 중 하나가 캐치 문제였습니다. 46:42 I went through and tested it myself and said, okay, we got this catching issue. 제가 직접 테스트해보고, 알겠습니다. 이 캐치 문제가 있군요. 46:45 We need to develop something in the software that gets around that catching issue when we upload it on. 업로드할 때 이 캐치 문제를 우회할 수 있는 소프트웨어를 개발해야 합니다. 46:49 And then when we see stuff coming in or a bug, always check for the catching issue first. 그리고 들어오는 내용이나 버그를 확인할 때는 항상 먼저 캐치 문제를 확인하세요. 46:53 We never have the catching issue anymore. 이제는 캐치 문제가 전혀 발생하지 않습니다. 46:55 This is how bug fixing works in Claude. 이것이 Claude에서 버그 수정이 작동하는 방식입니다. 46:57 The other thing you need to do when you're thinking about running in the bugs, is you're going to run the bugs and just sending it. 버그를 실행할 때 생각해야 할 다른 점은, 버그를 실행하고 그냥 보내는 것입니다. 47:01 You can, you can send Claude a screenshot, you can send it an error report, you can describe what went wrong. Claude에게 스크린샷을 보낼 수 있고, 오류 보고서를 보낼 수 있으며, 무엇이 잘못되었는지 설명할 수 있습니다. 47:07 These are all great. 이 모든 것이 훌륭합니다. 47:08 But what's better, when you see something going wrong in your software, particularly with an output, you need to have Claude Go and for example, I'll show you with my system. 하지만 소프트웨어에서 문제가 발생했을 때, 특히 출력과 관련하여, Claude에게 가서 제 시스템으로 예를 보여줘야 합니다. 47:17 So if you look at my extension right here and you see this pop out and we go and bring this down, you can see I have this log system right here, okay? 그래서 제 확장 프로그램을 보면, 이 팝업이 나타나고, 이걸 내리면, 여기 로그 시스템이 있음을 알 수 있습니다, 알겠죠? 47:25 And so the point of this is we. 그리고 이 점은 우리가. 47:27 When I would run in the errors with the extension and I'd see bad outputs coming back, back, I don't want you to explain to Claude. 확장 프로그램에서 오류가 발생했을 때 잘못된 결과가 돌아오는 것을 보았을 때, 클로드에게 설명하지 않기를 바랍니다. 47:33 I want a deep, detailed log. 저는 깊고 상세한 로그를 원합니다. 47:34 And one of the things Claude is exceptional at is you say, all right, where are all the things that can go wrong with this app or this. 클로드가 뛰어난 점 중 하나는, 이 앱이나 이와 관련된 문제들이 어디에 있는지 말할 수 있다는 것입니다. 47:40 This error is popping up right here. 이 오류가 바로 여기에서 발생하고 있습니다. 47:41 How can we create something that's going to give you a very detailed code technical explanation of why it's happening? 왜 이런 일이 발생하는지에 대한 매우 상세한 기술적 설명을 제공할 수 있는 무언가를 어떻게 만들 수 있을까요? 47:46 And it will think up test it can create for itself and then put these tests in there. 그리고 그것은 스스로 생성할 수 있는 테스트를 생각해내고, 그런 다음 이 테스트들을 여기에 넣을 것입니다. 47:50 So when you see things pop up, you can have documents you can feed back to it and say, all right, here's what went wrong. 그래서 문제가 발생했을 때, 당신은 그것에 피드백을 줄 수 있는 문서를 가질 수 있고, '좋아요, 여기서 잘못된 점이 있습니다.'라고 말할 수 있습니다. 47:55 Read this. 이것을 읽어보세요. 47:55 Why did it go wrong? 왜 잘못되었나요? 47:56 Wrong? 잘못된 건가요? 47:56 Look at the code base. 코드베이스를 살펴보세요. 47:57 Think about why it's going. 왜 이런 일이 발생하는지 생각해보세요. 47:58 Give me pos, give me why it's happening. 문제를 제시하고, 왜 이런 일이 발생하는지 설명해 주세요. 48:00 Give us possible solutions and in ways to prevent it from happening in the future. 가능한 해결책을 제시하고, 앞으로 이런 일이 발생하지 않도록 하는 방법을 알려주세요. 48:05 Bam. 짠. 48:05 You're not dealing with guesswork when you're dealing with with this shit anymore. 이제는 이런 문제를 다룰 때 추측에 의존하지 않아도 됩니다. 48:10 Finally, when you do a code review, it can be as simple as saying, claude, do a code review. 마지막으로, 코드 리뷰를 할 때는 '클로드, 코드 리뷰를 해줘.'라고 간단히 말할 수 있습니다. 48:16 One thing that is very helpful is you can have Codex and Claude and another cloud agent has no codecs. 매우 유용한 점은, Codex와 Claude, 그리고 다른 클라우드 에이전트가 코덱스 없이도 함께 코드를 검토할 수 있다는 것입니다. 48:22 All review the code and then send all the reports back to the main CLAUDE agent and then say, hey, this is something I stole from the Lenny podcast, YouTube as well. 모두 코드를 검토한 후, 모든 보고서를 주요 CLAUDE 에이전트에게 보내고, '이건 제가 Lenny 팟캐스트에서 가져온 것입니다. 유튜브에서도요.'라고 말할 수 있습니다. 48:29 And you can say, hey, here's what's wrong in the software. 그리고 '여기 소프트웨어에서 잘못된 점이 있습니다.'라고 말할 수 있습니다. 48:32 Either explain why this is incorrect or fix it. 이것이 왜 잘못되었는지 설명하거나 수정해 주세요. 48:35 That's another way to fix it. 그것을 수정하는 또 다른 방법입니다. 48:36 But then finally, when you have it, do the code review, all those MD files and everything you just put into the software is what the code review is going to use to review everything. 하지만 결국, 그것을 갖게 되면 코드 리뷰를 진행해야 합니다. 모든 MD 파일과 소프트웨어에 넣은 모든 것이 코드 리뷰에서 검토하는 데 사용됩니다. 48:44 And the context of it is whether it's wrong or not. 그리고 그 맥락은 그것이 잘못되었는지 여부입니다. 48:46 If you give a person a huge code base and you say, tell me where the bugs are, something could fit together architecturally just fine, but it's not the intended output of the software or it misses the point of the software. 누군가에게 방대한 코드 베이스를 주고 버그가 어디에 있는지 말해 달라고 하면, 구조적으로 잘 맞아떨어질 수 있지만, 소프트웨어의 의도된 출력이 아니거나 소프트웨어의 핵심을 놓칠 수 있습니다. 48:56 Software. 소프트웨어입니다. 48:57 If it doesn't have this, it's going to put stuff in there. 이것이 없으면 거기에 무언가가 들어갈 것입니다. 48:59 It doesn't make any sense. 전혀 말이 되지 않습니다. 49:00 So you need to have all this context. 그래서 이 모든 맥락이 필요합니다. 49:01 The final thing I'm going to tell you is whenever you're done coding or whenever you're done Working with Claude, what you're going to want to do is you need to have this little update everything. 마지막으로 말씀드릴 것은, 코딩을 마치거나 Claude와 작업을 마치면, 모든 것을 업데이트해야 한다는 것입니다. 49:10 And the more complicated your system is, the more technical docs. 시스템이 복잡할수록 기술 문서가 더 많아집니다. 49:14 You can see this doc area right here that I have in VS code right here. 여기 VS 코드에서 제가 가지고 있는 문서 영역을 볼 수 있습니다. 49:19 The more advanced your Claude and your architecture and your documents are going to be. 당신의 Claude와 아키텍처, 문서가 더 발전할수록 더욱 그렇습니다. 49:23 So keep these really clean. 그래서 이들을 정말 깔끔하게 유지하세요. 49:25 But, but every time I build something new, the architecture updates. 하지만, 제가 새로운 것을 만들 때마다 아키텍처가 업데이트됩니다. 49:28 Every time I add something new about how the feature works, the PRD updates. 기능이 작동하는 방식에 대해 새로운 것을 추가할 때마다 PRD가 업데이트됩니다. 49:31 Every time we learn something or we need rules or ways that it works with or things for it to consider the Cloud MD updates. 무언가를 배우거나 규칙이나 작동 방식이 필요할 때마다 Cloud MD가 업데이트됩니다. 49:36 Okay, on top of this, when you're building really advanced stuff inside each folder or inside each thing you're building, you can still have other rule systems in there that Claude looks at before it gets into the folder. 좋습니다, 이와 더불어, 각 폴더나 구축 중인 각 항목 내부에서 정말 고급 기능을 구축할 때, Claude가 폴더에 들어가기 전에 살펴보는 다른 규칙 시스템을 여전히 가질 수 있습니다. 49:46 So if it's going into this part of the app right here, and this is just a one page app, so it doesn't have lots of folders or whatnot. 그래서 이 앱의 이 부분으로 들어간다면, 이것은 단일 페이지 앱이므로 많은 폴더가 없거나 그런 것이 없습니다. 49:51 Whatnot. 그런 것들입니다. 49:51 But let's say we're just getting to something in the API. 하지만 API에서 무언가를 다루고 있다고 가정해 보겠습니다. 49:53 All right, I could have a note or a Cloud MD in the API that says, hey, wait, before you do this, make sure it aligns with this other part of the software. 좋습니다, API에 메모나 클라우드 MD가 있어서, 이걸 하기 전에 이 소프트웨어의 다른 부분과 일치하는지 확인하라고 말할 수 있습니다. 50:00 And these are always in sync. 그리고 이들은 항상 동기화되어 있습니다. 50:01 Now the reason why you do this is because you don't want Claude always opening up files, okay. 이렇게 하는 이유는 클로드가 항상 파일을 열지 않도록 하기 위해서입니다. 50:06 And reading it because it takes up your, your context window. 그리고 읽는 것은 당신의 컨텍스트 창을 차지하기 때문입니다. 50:09 That said, you want it when it digs into something relevant to know where to look and specific things to check that are very, very important. 그렇다고 해서, 관련된 내용을 파고들 때 어디를 봐야 할지와 매우 중요한 특정 사항들을 확인할 수 있도록 하고 싶습니다. 50:18 Okay? 알겠죠? 50:18 So these are just other little general tips that really are going to save your life when you're doing this. 그래서 이것들은 당신이 이 작업을 할 때 정말로 도움이 될 일반적인 팁들입니다. 50:22 Finally, my last tip for you when you're building these things is make sure Claude explicitly builds in ways that parts of the software are segmented from each other. 마지막으로, 이러한 것들을 만들 때 클로드가 소프트웨어의 부분들이 서로 분리되도록 명확하게 구축하도록 해야 합니다. 50:30 Because remember that context window. 컨텍스트 창을 기억하세요. 50:32 Let's imagine you have chapter one of your book, chapter two and chapter three. 당신의 책의 1장, 2장, 3장을 상상해 보세요. 50:36 Let's imagine you keep these all super duper cleanly and there's little context at the beginning of chapter one and the end of chapter one on the rest of the book book. 이 모든 것을 아주 깔끔하게 유지하고 1장의 시작과 끝에 나머지 책에 대한 약간의 컨텍스트가 있다고 가정해 보겠습니다. 50:44 So it's a summary of the book on each side. 그래서 양쪽에 책의 요약이 있는 것입니다. 50:45 But the, the AI can cleanly work on one chapter at a time and they don't mess with each other too much. 하지만 AI는 한 번에 한 장씩 깔끔하게 작업할 수 있고 서로 너무 많이 엉키지 않습니다. 50:51 If you have a code system, it's all a bunch of interlending things. 코드 시스템이 있다면, 모든 것이 서로 얽혀 있습니다. 50:54 Think about a plumbing system. 배관 시스템을 생각해 보세요. 50:55 Okay, Much better analogy. 좋습니다, 훨씬 더 나은 비유입니다. 50:57 It's a bunch of plumbing all intersected. 모든 것이 서로 교차하는 배관입니다. 50:59 If something over here changes and it messes up with that? 여기서 무언가가 변경되면 그것이 엉켜버리면 어떻게 될까요? 51:01 Well, Claud has to keep the entire plumbing system all in its mind. 클로드는 전체 배관 시스템을 모두 기억해야 합니다. 51:04 If you have a skyscraper where each floor has its own plumbing system and it doesn't need to understand how the plumbing system up here works, works, then what you're going to be able to do, and I know you're checking out the buys, it's good, don't worry about it. 각 층마다 독립적인 배관 시스템이 있는 마천루가 있다면, 위층의 배관 시스템이 어떻게 작동하는지 이해할 필요가 없습니다. 그러면 여러분이 할 수 있는 일은 많아지며, 여러분이 구매를 확인하고 있다는 것을 알고 있습니다. 괜찮습니다, 걱정하지 마세요. 51:15 What you're going to need to do is a lot less work because you can just put Claude on one floor and say here's the context of the overall project. 여러분이 해야 할 일은 훨씬 적은 작업입니다. 왜냐하면 클로드를 한 층에 두고 전체 프로젝트의 맥락을 설명할 수 있기 때문입니다. 51:21 But you only need to understand what's on this floor right here. 하지만 여러분은 이 층에 있는 것만 이해하면 됩니다. 51:24 And it can work much better because it doesn't have to remember everything and blow its context window very fast. 이렇게 하면 모든 것을 기억할 필요가 없고, 맥락 창이 너무 빨리 소진되지 않기 때문에 훨씬 더 잘 작동할 수 있습니다. 51:29 So these are a bunch of things I do when I'm building in my company and how I think about the code and how I look at it. 이것들은 제가 회사에서 작업할 때 하는 여러 가지 일들이며, 코드에 대한 제 생각과 바라보는 방식입니다. 51:34 I think a lot of these things right here. 저는 여기 있는 많은 것들을 생각합니다. 51:35 You should, your developers should know all these things. 여러분의 개발자들은 이러한 모든 것을 알아야 합니다. 51:38 Okay? 알겠죠? 51:39 If your team, if you ing doing this, your team's and they suck. 여러분의 팀이 이렇게 하고 있다면, 그 팀은 형편없습니다. 51:43 Sorry, but it's true. 죄송하지만, 사실입니다. 51:44 And your team should know these things. 여러분의 팀은 이러한 것들을 알아야 합니다. 51:46 And if they don't know these things, they should be thinking these ways. 그리고 만약 그들이 이러한 것들을 모른다면, 그들은 이런 방식으로 생각해야 합니다. 51:48 You should have deep MD files for your software. 여러분의 소프트웨어에 대한 깊이 있는 MD 파일이 있어야 합니다. 51:50 You should have deep MD files for your ui. 여러분의 UI에 대한 깊이 있는 MD 파일이 있어야 합니다. 51:52 You should have parts of your software signal. 여러분의 소프트웨어 신호의 일부가 있어야 합니다. 51:54 All the things I talked about should be there times 10 on your real like deep product. 제가 이야기한 모든 것들은 여러분의 실제 깊이 있는 제품에서 10배는 있어야 합니다. 51:58 Okay? 알겠죠? 51:59 That being said, as a non technical founder, this allows you to do so much work on other parts of the software that are not directly connected to your deep back end of the complicated parts. 그렇다고 하더라도, 비기술적인 창립자로서, 이는 여러분이 복잡한 백엔드와 직접 연결되지 않은 소프트웨어의 다른 부분에서 많은 작업을 할 수 있게 해줍니다. 52:07 It allows you to make stuff for your customers right away way that gets them results very, very quickly. 이는 고객을 위해 즉시 결과를 얻을 수 있는 제품을 만들 수 있게 해줍니다. 52:11 And those are the three ways to look at and these are the ways to build them from scratch. 이것들이 바라보는 세 가지 방법이며, 이를 처음부터 만드는 방법입니다. 52:14 If you have a SaaS company, you should be using high risk because it's gonna make you a lot more money from your ads. SaaS 회사를 운영하고 계신다면, 높은 리스크를 감수해야 합니다. 그렇게 해야 광고에서 훨씬 더 많은 수익을 올릴 수 있습니다. 52:19 So that's that. 그게 전부입니다. 52:20 That's the real point of why I'm making this video. 제가 이 영상을 만드는 진짜 이유입니다. 52:22 I want you to use my, my, my ad products will make you a lot more money, but not before I give you good content, which is this video. 제 광고 제품을 사용하시면 훨씬 더 많은 수익을 올릴 수 있지만, 좋은 콘텐츠를 제공하기 전에는 그렇지 않습니다. 이 영상이 그 콘텐츠입니다. 52:28 So this is the video. 그래서 이 영상입니다. 52:29 I've talked enough. 제가 충분히 이야기했습니다. 52:30 This is everything I do when it comes to vibe coding or agenda coding. 이것이 제가 분위기 코딩이나 아젠다 코딩에 대해 하는 모든 것입니다. 52:33 Have a nice day. 좋은 하루 되세요. 52:34 If you guys like these videos, let me know. 이런 영상이 마음에 드신다면 알려주세요. 52:36 I can go into the actual how to use Claude MD and more deeper stuff. Claude MD를 실제로 사용하는 방법이나 더 깊은 내용에 대해 이야기할 수 있습니다. 52:41 But I think this is the only vibe code I'm going to make because this is everything I think you need to know. 하지만 제가 만들고 싶은 분위기 코드는 이게 전부라고 생각합니다. 여러분이 알아야 할 모든 것이니까요. 52:45 Okay, bye. 그럼, 안녕히 계세요.