스크립트
00:00:00루프 엔지니어링은 이제 우리가 AI 에이전트를 사용하는 방식의 필수 요소가 되었습니다.
00:00:04에이전트가 훨씬 더 오랜 시간 동안 스스로 실행을 지속할 수 있기 때문입니다.
00:00:09그래서 이번 영상에서는 세 가지 서로 다른 루프를 단계별로 정리해 보여드리려고 합니다.
00:00:131단계에서는 기본 단위와 이를 효율적으로 사용하는 방법을 알아보고, 2단계에서는 그 단위를 확장해
00:00:18팩토리 형태로 구축하는 법을 다룹니다. 마지막 3단계에서는 대부분의 시간을 확보하여
00:00:23진정한 에이전틱 상태를 구현하게 됩니다. 영상에 방대한 정보가 담겨 있는 만큼,
00:00:28필요할 때 언제든 다시 찾아볼 수 있도록 아래에 타임스탬프를 남겨두었습니다.
00:00:33또한 이번 영상에서는 Claude Code를 사용하지만, 여기서 보여드릴 시스템은
00:00:38Codex에서도 작동합니다. 도구의 경우 Warp와 VS Code를 사용하며,
00:00:43두 프로그램에서 동일한 폴더 하나만 열고 저희를 따라오시면 됩니다. 바이브 코딩 내에서
00:00:48루프 엔지니어링을 구현하는 방법을 살펴보기 전에 먼저 루프가 무엇인지 설명해 드리겠습니다.
00:00:53이전에 무언가를 만들 때 여러분은 이미 루프 속에 있었습니다. 에이전트에게 프롬프트를 주면
00:00:57구축을 시작했고, 완료되면 검증을 요청했습니다. 결과가 잘못되면 에이전트에게
00:01:02다른 프롬프트를 주어 다시 빌드하게 만들었죠. 여러분은 이미 루프를 사용하고 있었습니다.
00:01:07이제 에이전트 루프란 이 과정에서 사람이 빠지고 검증 단계마저 에이전트가 담당하는 것을 말합니다.
00:01:12이것은 자연스러운 흐름입니다. 생각해보면 에이전트와 함께 무언가를 구축하는 것은
00:01:17시간을 가장 많이 잡아먹는 요인이 아닙니다. 에이전트가 백그라운드에서 자율적으로 처리하니까요.
00:01:21실제로 우리의 주의가 필요한 것은 에이전트가 성공했는지 확인하는 일입니다.
00:01:26하지만 에이전트가 올바른 결과물이 무엇인지 알아야만 검증을 수행할 수 있습니다. 그것이 루프의 핵심입니다.
00:01:30물론 다른 부분들도 존재합니다. 먼저 루프를 시작하는 트리거가 필요하고, 그다음 루프 자체가 있습니다.
00:01:35그리고 각 루프의 끝에는 에이전트의 작업 완료 여부를 결정하는 검증 단계가 필수적으로 존재해야 합니다.
00:01:41이 검증 단계는 사용자가 결정해야 합니다. 따라서 에이전트 루프에서
00:01:46여러분이 계속 가져가는 부분은 처음부터 여러분의 몫이었던 바로 그 부분입니다. 즉, 에이전트를
00:01:50끌지 더 시킬지를 결정하는 역할이며, 이는 온전히 넘길 수 없는 영역입니다.
00:01:55여러분은 왜 갑자기 루프 엔지니어링으로 전환하는지, 왜 1년 전에는 이것이 안 되었는지 의문이 들 수 있습니다.
00:01:59그 이유는 예전 모델들은 이 정도로 오래 실행될 수 없었기 때문입니다. 하지만 새로 나오는
00:02:04모델들을 통해 이제는 사용자의 개입 없이도 몇 시간 동안 작업이 가능해졌습니다.
00:02:08우리가 이 모든 것을 구동하고 있는 대상은 미용실 예약 앱입니다. 누군가 사이트에 방문하여
00:02:13디자이너를 선택한 후, 날짜별로 해당 디자이너의 예약 가능한 시간을 확인하고 예약할 수 있습니다.
00:02:17또한 이 서비스를 사용하는 모든 미용실에는 접수 담당자가 있으므로 직원 로그인 기능도 있습니다.
00:02:22담당자가 들어오는 요청을 승인 또는 거절하고, 미용실 내 디자이너들의 캘린더를 관리하죠.
00:02:27현재 이 앱에는 빠진 기능이 많습니다. 랜딩 페이지도 없고 추가해야 할 중요한 기능들이 남았습니다.
00:02:31이 앱을 빌드한 Claude Code 세션이 바로 이것입니다. loop engineering 폴더를 만들고
00:02:36그 안에서 Claude Code에게 프로젝트 설정을 요청했습니다. 앱 자체는 loop salon 폴더에
00:02:41위치하며 단순한 Next.js 앱입니다. 이 용어가 처음이셔도 걱정하실 필요 없습니다.
00:02:46모델에게 Next.js 앱을 만들고 싶다고 말한 뒤 거기서부터 빌드를 시작하면 알아서 처리해 줍니다.
00:02:51여기서 다루는 것처럼 실제 웹사이트를 구축할 때 가장 인기 있는 방법 중 하나입니다.
00:02:55이제 폴더 안에 반드시 포함해야 하는 파일들이 있습니다. 첫 번째로는 Claude.md가 있는데,
00:03:00내용은 단순히 Agents.md를 확인하라는 것뿐입니다. 이 저장소에서는 Claude Code뿐만 아니라
00:03:04둘 이상의 에이전트를 실행해야 할 수 있기 때문입니다. 거의 모든 다른 에이전트들이
00:03:09새 세션이 열릴 때 수행할 규칙으로 Agent.md의 지침을 사용하기 때문에 이 파일을 활용합니다.
00:03:14Claude.md는 오직 Claude Code만 사용합니다. Agents.md 내부의 내용은 직접 작성할 필요는 없었습니다.
00:03:21그리고 사용자가 실제로 상호작용하는 앱의 모든 클릭 가능한 요소를 다루는
00:03:27design.functional.md라는 파일이 있습니다. 해당 요소들의 디자인은 이 파일에서 가져옵니다.
00:03:33눈치채셨겠지만 이 앱은 듀오링고처럼 보입니다. 듀오링고의 디자인을 그대로 차용했기 때문입니다.
00:03:36다음으로 알아두어야 할 스킬들이 있습니다. 첫 번째는 'Grill Me'로,
00:03:41첫 번째 버전을 빌드하는 동안 사용했던 기능입니다. 에이전트가 여러분이 원하는 바를
00:03:45확실히 파악할 때까지 계속해서 질문을 던집니다. 이외에도 다른 스킬들이 있으며
00:03:50이는 나중에 다루겠습니다. 보시다시피 이 프로젝트는 이미 구축되어 있습니다.
00:03:55의도적으로 그렇게 한 것인데요, 새로운 것을 시작할 때 가장 먼저 만드는 것은 MVP입니다.
00:03:59이는 핵심 기능만 구현하고 다른 것은 없는 가장 거칠지만 작동하는 제품 버전을 의미합니다.
00:04:04핵심 기능만 담고 다른 건 없는 가장 기본적인 제품인 MVP로 시작하는 이유입니다.
00:04:08MVP는 원래 빠르게 만들 수 있지만, 여기에 반복 작업을 도입하려면 에이전트가 시작하기도 전에
00:04:13완료 상태가 어떤 것인지 미리 정해야 합니다. 하지만 그때는 제품이 어디로 갈지
00:04:18아직 확실히 알 수 없죠. 결국 그 방식을 정리하는 데 첫 버전을 직접 만드는 것보다 더 오래 걸리게 됩니다.
00:04:23하지만 레벨 1을 시작하기 전에, 채널을 구독하고
00:04:27좋아요 버튼을 눌러주시면 큰 힘이 됩니다. 자, 그럼 루프 엔지니어링의 레벨 1로 넘어가겠습니다.
00:04:33여기서는 하나의 목표를 가진 단일 루프를 다루며, 검증 과정은 사람이 아니라
00:04:37에이전트가 담당하게 됩니다. 이 작업을 진행할 곳은 랜딩 페이지인데,
00:04:42랜딩 페이지는 화면이 하나뿐이라 왠지 어울리지 않는 장소처럼 들릴 수도 있습니다.
00:04:47에이전트는 기본적으로 한 번에 구축할 수 있고, 문제가 있다면 여러 번이 아니라
00:04:51단 한 번의 프롬프트로 수정할 수 있으니까요. 랜딩 페이지에 루프를 적용하는 건 페이지 자체보다 일이 더 많아집니다.
00:04:57하지만 이번에는 GSAP 기술을 활용해 움직임이 많은 랜딩 페이지를 만들려고 합니다. 모든 요소가 애니메이션으로 나타나는데,
00:05:02생각해보면 이런 부분은 한 번 훑어보는 것만으로는 제대로 확인하기 어렵습니다. 애니메이션이 들어가면
00:05:07에이전트가 실수를 할 수 있는 부분이 너무 많아서 수많은 피드백이 오가야 하죠.
00:05:12어떤 작업에 루프가 필요한지 확인하는 아주 좋은 방법은 에이전트와 빈번한 상호작용이 필요한지 보는 것입니다.
00:05:16자, 루프를 설정하기 전에 사람들을 헷갈리게 만드는 명칭 문제가 하나 있습니다.
00:05:21Claude Code에서 슬래시 메뉴를 여는 순간 바로 마주치게 될 텐데요. 명령어가
00:05:25loop와 goal 두 가지가 있는데, 루프 엔지니어링은 기본적으로 goal 명령어를 사용합니다. loop 명령어는
00:05:30타이머에 맞춰 프롬프트를 실행하므로, 변경 사항이 있든 없든 5분마다 혹은 1시간마다 다시 작동합니다.
00:05:35반면 goal 명령어는 요청한 작업이 실제로 완료될 때까지 계속 작동하는 명령어입니다.
00:05:40따라서 루프 엔지니어링이라고 할 때 우리는 goal 명령어를 사용하는 것입니다. loop 명령어 역시
00:05:45일부 형태나 루프 엔지니어링 워크플로에서 쓰이기도 하지만, 여기서는 사용하지 않습니다. goal 명령어 자체는 꽤 단순합니다.
00:05:51slash goal을 입력한 다음 달성하려는 목표를 적고, 모델에게
00:05:56목표 달성 여부를 확인하는 방법도 함께 알려줍니다. 그런 다음 매 단계가 끝날 때마다 더 작은 모델이 대화 내용을 읽고
00:06:00에이전트가 이 작업을 계속해야 할지, 아니면 조건이 충족되었는지 판단합니다.
00:06:05랜딩 페이지 작업을 시작하기 위해 우리는 다시 grill me 기술을 사용했고, 이 기능에 필요한 사양 파일이 필요하다고 말했습니다.
00:06:11자, 요청한 내용에 대해 이야기하기 전에 프로젝트 내부에 있는 features 폴더를 먼저 살펴봐야 합니다.
00:06:16그 안의 각 폴더는 에이전트가 완료해야 하는 하나의 기능을 의미하며,
00:06:21각 폴더에는 두 가지가 들어 있습니다. 해당 기능에 대한 모든 내용이 기록되는 사양 파일과,
00:06:25처음에는 비어 있다가 에이전트가 해당 기능의 루프를 실행하는 동안 채워지는 검증 폴더가 그것입니다.
00:06:31그런 다음 사용할 기술을 지정해 주었습니다. 첫 번째는 GSAP 기술인데,
00:06:35아름다운 애니메이션이 적용된 랜딩 페이지를 만들어주는 기능입니다. 하지만 이렇게 무거운 애니메이션은
00:06:41페이지 속도를 크게 떨어뜨립니다. 그래서 최적화 기술도 함께 사용하도록 지시하여
00:06:45애니메이션을 제거하지 않으면서도 페이지 속도를 다시 끌어올리도록 했습니다. 또한 참고할 수 있도록
00:06:50일러스트가 포함된 랜딩 페이지 이미지 레퍼런스도 제공했습니다. 그리고 마지막으로 전달한 지시는 검증에 관한 것이었습니다.
00:06:55보통 이 단계에서는 여러분과 에이전트가 서로 오가며 페이지를 보고, 무엇이 잘못되었는지 말해주면 에이전트가 수정하러 갑니다.
00:06:59그래서 디자인을 실제로 검증하기 위해, 특정 프로젝트만이 아니라 기기의 모든 프로젝트에 적용되는
00:07:04전역 Claude.MD 파일에 명시된 특정 도구를 사용하도록 지시했습니다.
00:07:11결과적으로 작성된 내용은 두 가지가 동시에 담긴 형태였습니다. 페이지를 구축하기 위한 사양과,
00:07:15해당 페이지를 대상으로 실행되는 검증 체크리스트가 그것입니다.
00:07:20전역 파일에 있던 스크린샷 도구가 그곳에 포함된 이유도 그 도구가 매번 전체 브라우저를 여는 것보다
00:07:25훨씬 더 빠르게 스크린샷을 촬영할 수 있기 때문입니다. 원하신다면 여기서 멈추고 전체 프롬프트를 읽어보셔도 좋습니다.
00:07:30그러면 이 모든 과정이 훨씬 더 명확하게 이해될 것입니다. 그 후 Grill.me가 질문 단계로 넘어가서
00:07:34랜딩 페이지에 관한 다양한 질문들을 던졌습니다.
00:07:39그런 다음 우리는 한 가지를 더 지시했고, 이것이 바로 사양을 목표로 전환시킨 핵심이었습니다.
00:07:45목표 명령어로 실행할 수 있도록 사양 파일을 goal 형식으로 작성해달라고 요청했고, 그 결과 몇 가지 다른 변경 사항도 함께 적용되었습니다.
00:07:50즉, 그 이후부터는 goal 명령어를 실행하고 랜딩 페이지 사양 파일만 전달하면 끝나는 상태가 되었습니다.
00:07:55기능마다 이 모든 과정을 반복하는 것은 정말 피하고 싶은 번거로운 작업입니다.
00:08:00그래서 우리는 goal writer 기술을 만들었습니다. 방금 살펴본 모든 내용과 그 한 줄의 명령어가 그 안에 포함되어 있죠.
00:08:06이 기술이 하는 일은 사양 파일이 goal 형식으로 이미 작성된 상태로 features 폴더 내부에 폴더들을 생성하는 것입니다.
00:08:11그런 다음 작업이 시작되어 첫 번째 패스를 거쳤고, 다시 체크리스트를 기반으로 스스로 점수를 매기는
00:08:16체크리스트를 다시 확인하며 계속해서 스스로 점검했습니다. 그후에 멈췄고 그때쯤이면
00:08:2138분 동안 실행된 상태였고 오류가 하나 발생했는데, 마스코트 중 하나의 깜빡임 문제였습니다.
00:08:26이것이 바로 그 결과물입니다. 교정 프롬프트를 한 번 더 입력한 후, 마스코트들이 우리가 원하는
00:08:31방식대로 깜빡이게 되었고, 그 단 하나의 실수는 검증 과정에서 절대 잡아낼 수 없는 부분이었습니다. 왜냐하면
00:08:36스크린샷은 단 한 순간만을 포착하며 한 번의 깜빡임과 다음 깜빡임 사이의 간격은 너무 짧아서
00:08:42두 장의 스크린샷으로는 잡아낼 수 없기 때문입니다. 그 외에는 일러스트레이션들이 아주 잘 나왔고
00:08:46우리가 목표로 했던 듀오링고 스타일의 브랜드 아이덴티티와 잘 일치하며, 이는 이미 메인 앱에
00:08:50있는 스타일과 동일합니다. 레퍼런스도 충실히 따랐고 '지금 예약하기'를 누르면 바로
00:08:55앱으로 진입하여 바로 사용할 수 있습니다. 이제부터 실행되는 모든 작업에는 몇 가지 설정이 필요합니다.
00:09:00이 앱에 필요한 세 가지 요소는 여러분의 개인 컴퓨터 혼자서는 처리할 수 없는 것들이며, 여러분이 직접
00:09:05그중 어느 것도 조작할 일이 없으니 그 부분은 걱정하지 않으셔도 됩니다. 자, 지금 여러분이 빌드한 모든 것은
00:09:10컴퓨터의 한 폴더 안에 들어 있으며 그것이 어디에도 없는 유일한 복사본입니다. 만약 컴퓨터가 고장 나거나
00:09:15잘못된 것을 삭제하면 프로젝트 전체가 사라지게 됩니다. 이것이 가장 먼저
00:09:20달라져야 하는 부분이며, 이를 해결해 주는 것이 바로 깃허브(GitHub)입니다. 클로드가 여러분의 폴더에 프로젝트 코드를 작성하면 깃허브는 그 코드를 온라인으로 가져와
00:09:25저장소(repo)에 보관합니다. 저장소란 기본적으로 오직 여러분의 기기에만 있던 그 폴더가 깃허브 사이트에 그대로 존재하는 것입니다.
00:09:31두 번째는 앱이 아직 아무것도 기억하지 못한다는 점입니다. 실제 사람들이 이 서비스를 사용하게 될 텐데
00:09:36예약 내용이 어딘가에 저장되어야 합니다. 그렇지 않으면 누군가 예약을 하고
00:09:41페이지를 새로고침하는 순간 모든 기록이 그냥 사라져 버리기 때문입니다. 따라서 데이터베이스가 필요하며 우리가
00:09:45사용할 것은 수파베이스(Supabase)입니다. 그리고 마지막으로, 앱이 오직 여러분의 컴퓨터에서만 실행되기 때문에
00:09:50다른 사람들은 실제로 접근할 수 없습니다. 따라서 배포가 이루어져야 하며, 이는 다른 사람들이 열어볼 수 있도록 인터넷상의
00:09:55어딘가에 올려진다는 뜻이고, 이를 수행하는 것이 바로 버셀(Vercel)입니다. 이제 이 세 플랫폼에서 여러분이 실제로 해야 할 일은
00:09:59이 세 플랫폼에서 실제로 해야 할 일은 계정을 만들고 각 웹사이트에 접속해 Google로 로그인을 클릭하는 것뿐입니다.
00:10:04구성하거나 설정할 필요가 전혀 없습니다. 그 이후의 모든 과정은 에이전트를 통해 진행되며,
00:10:08그렇게 작동할 수 있는 이유는 세 플랫폼 모두 CLI를 제공하기 때문입니다. 에이전트는 여러분처럼
00:10:14웹사이트를 직접 클릭할 수 없습니다. 따라서 CLI는 에이전트가 해당 플랫폼을 사용하기 위한 도구입니다. 보통은
00:10:20GitHub에 저장소를 만들고 Supabase와 Vercel에 프로젝트를 생성해야 하지만, Claude가 CLI를 사용해 직접 처리할 수 있습니다.
00:10:26따라서 세 곳 모두에 계정을 만든 후 에이전트로 돌아와서 CLI를 통해
00:10:31이 세 가지를 모두 사용하도록 요청하면 됩니다. 에이전트가 각각에 대한 명령어를 제공할 것이며, 여러분은
00:10:37다른 터미널에서 그 명령어들을 실행해야 합니다. 에이전트가 이미 첫 번째 터미널에 실행 중이므로 두 번째 터미널을 열고
00:10:41그 명령어를 붙여넣으면 됩니다. 그러면 알아서 CLI를 설치해 준 다음 계정에
00:10:46로그인하기 위해 브라우저 창을 엽니다. 거기서 승인만 하면
00:10:51인증이 완료됩니다. 이후부터는 에이전트가 해당 플랫폼에서 모든 작업을 수행할 수 있으므로 다시는 그 사이트들에 접속할 필요가 없습니다.
00:10:56그리고 이 모든 내용을 기억할 필요는 없습니다. 설명란에
00:11:00무료 설정 파일을 준비해 두었기 때문입니다. 그 파일을 에이전트에게 전달하기만 하면 Next.js 앱을 기본적으로 설정해 주고,
00:11:05이 세 가지 플랫폼을 모두 연결하는 데 필요한 나머지 과정도 단계별로 안내해 줍니다.
00:11:10또한 이러한 플랫폼들의 규칙은 계속해서 바뀌기 때문에, 각 플랫폼사에서는 에이전트를 위한 스킬을 출시했습니다.
00:11:16GitHub는 특별한 스킬이 필요하지 않습니다. 크게 바뀐 부분이 없고 지금도
00:11:21변화가 없기 때문입니다. 하지만 Vercel 배포 스킬이 있어서, 기본적으로 에이전트에게
00:11:26Vercel CLI를 사용하여 프로젝트를 자동으로 배포하는 방법을 알려줍니다. 그리고
00:11:31Supabase 스킬과 Supabase 모범 사례 스킬도 있습니다. 이 역시 자동으로 실행되므로 에이전트가
00:11:37이 두 플랫폼 중 하나를 사용해야 할 때가 오면 알아서 사용하므로 여러분이 직접 무언가를 할 필요가 없습니다.
00:11:42이렇게 하면 Supabase 데이터베이스에 데이터가 채워지고 프로젝트가
00:11:47Vercel에 라이브로 배포됩니다. 이 스킬들의 링크는 아래 설명란에 남겨두겠습니다. 하지만
00:11:52다음 단계로 넘어가기 전에 스폰서인 Hedra의 이야기를 잠시 전해드리겠습니다. 이 서비스를 Manus처럼
00:11:57조사하고 프로젝트를 기획하는 에이전트들과 동일시하기 쉽습니다. Hedra 역시 그 기능을 수행합니다. 차이점은
00:12:02문서나 슬라이드 덱이 아니라, 완성된 비디오를 건네준 이후에 나타납니다. Claude가 Canva를 만난 것과 같습니다.
00:12:08대화를 나누면 옆에서 함께 빌드해 나갑니다. 스페이스 안에서 직접 써보고 앱을 위한 짧은 홍보
00:12:13영상을 만들어 달라고 요청해 보았습니다. 흥미로웠던 점은 영상 자체보다도 에이전트가 거기에 도달하는 과정이었습니다.
00:12:18먼저 몇 가지 명확화 질문이 오간 뒤 제안된 계획이 나왔습니다. 짐작하는 대신, Hedra가 직접
00:12:23해당 주제를 조사하고 실제 조사 결과를 가져왔습니다. 그로부터 캔버스에 전체 스크립트가 작성되고,
00:12:28에이전트가 그 과정을 안내해 준 끝에 완성된 프로모션 영상이 탄생했습니다. 이 서비스는 특히 편집자나
00:12:33작가 없이 혼자 마케팅을 진행하는 분들에게 정말 유용합니다. Hedra 덕분에 예전에는 팀 전체가
00:12:38필요했던 일을 한 사람이 처리할 수 있게 됩니다. Hedra.com에서 무료로 체험해 보실 수 있으며, 저희 코드를 사용하시면 첫 달
00:12:4350% 할인 혜택을 받으실 수 있습니다. 링크와 코드는 아래 설명란에 있습니다. 자, 그럼 다음
00:12:48단계로 넘어가겠습니다. 레벨 2는 '소프트웨어 팩토리 루프(Software Factory Loop)'라고 합니다. 이 단계에서는 여러 기능을
00:12:53함께 기획하고 루프에 등록하여, 에이전트가 하나의 기능이 끝난 후 멈추지 않고 밤새도록 목록에 있는 기능들을 작업할 수 있게 합니다.
00:12:59이러한 루프는 매우 길어질 수 있으므로, 부여된 기능 목록이 완료되었는지 여부를 알려줄 트래커가 필요합니다.
00:13:04목록의 모든 기능이 체크아웃되면 목표 루프가 완료됩니다. 이제 새로운 기능을 기획할 때
00:13:09만들 내용만 적어두는 것이 아니라 실제로 UI를 만들어야 합니다. 이것을
00:13:13프로토타입이라고 부르며, 실제 작동하지는 않지만 완전히 클릭해 볼 수 있는 앱 버전입니다. 이렇게 개발을 시작하기 전에
00:13:18UI 프로토타입을 만들어야 하는 데에는 두 가지 엄청난 이유가 있습니다. 첫 번째 이유는
00:13:23프로토타입을 통해 내가 만들고자 상상했던 것이 실제로 내가 만들고 싶었던 바로 그 대상인지
00:13:28확인할 수 있기 때문입니다. 그리고 두 번째 이유는 이 프로토타입이 루프 안에서 작동하는 에이전트가
00:13:33자신이 만든 결과물이 올바른지 검증하는 수단이 되기 때문입니다. 이제 팩토리 안에서
00:13:37목록이 있고 에이전트는 루프를 돌며 각 항목을 하나씩 처리합니다. 하지만 개별 항목을
00:13:42어떻게 처리할까요? 메인 에이전트가 항목을 선택하면 직접 빌드 작업을 수행하지 않습니다.
00:13:48해당 작업을 하위 에이전트에게 넘기고, 하위 에이전트가 기능을 완성합니다. 하지만 만약
00:13:53하위 에이전트가 빌드를 망쳐서 앱이 망가진다면 어떻게 해야 할까요? 이것이 바로 메인 에이전트가
00:13:58브랜치라는 폴더 복사본을 만들고 에이전트가 그곳에서 작업하도록 하는 이유입니다. 작업이 끝나면 에이전트는 직접
00:14:03검증하지 않습니다. 여기서 루프 엔지니어링의 또 다른 매우 중요한 규칙이 등장합니다. 작업을 수행한 에이전트는
00:14:07절대 스스로 검증해서는 안 된다는 것입니다. 검증은 항상 새로운 컨텍스트 윈도우를 가진 다른 에이전트에게 맡겨야 합니다.
00:14:13이것이 바로 하위 에이전트가 작동하는 방식이므로, 메인 에이전트는 해당 브랜치를 적대적 검토(adversarial review)
00:14:18에이전트에게 전달합니다. 이는 에이전트가 항상 완료된 작업에 어떤 오류가 있다고 가정하고 의심해야 함을 의미합니다.
00:14:24이것이 버그를 잡아내는 데 유용한 방식입니다. 따라서 적대적 검토 에이전트를 통해
00:14:29어떤 문제가 발견되면, 메인 에이전트는 다시 빌드 에이전트를 실행해야 하며 목록의 기능이
00:14:34완료 체크될 때까지 이 과정이 루프로 반복됩니다. 해당 기능이 완료되면, 사용자가
00:14:39새로운 기능을 사용할 수 있도록 해당 브랜치의 작업 내용을 배포된 앱에 반영해야 합니다. 모르시는 분들을 위해
00:14:44설명하자면, GitHub의 메인 코드 버전이 Vercel의 배포된 앱에 실제로 표시되는 내용입니다.
00:14:48따라서 브랜치가 메인 버전과 병합되면, 해당 브랜치의 기능이 배포된 앱에 반영됩니다.
00:14:53여기서 여러분의 최종 승인이 필요합니다. 기능이 완료되면 풀 리퀘스트(pull request)가 생성됩니다.
00:14:58풀 리퀘스트란 기능 브랜치를 메인 브랜치와 병합해 달라는 요청입니다. 해당 풀 리퀘스트에는
00:15:03에이전트가 스크린샷도 함께 첨부합니다. 하지만 확실히 하고 싶다면, Claude에게 해당 브랜치로 전환해 달라고
00:15:08요청한 뒤 컴퓨터 폴더 내에서 기능이 실제로 잘 작동하는지 직접 테스트해 볼 수 있습니다. 이상이 없다면
00:15:13풀 리퀘스트를 병합하면 됩니다. 다시 스킬들을 살펴보면,
00:15:18이제 새로운 기능 스킬이 추가된 것을 확인할 수 있습니다. 이 스킬을 호출하면 기본적으로
00:15:22에이전트에게 내부에 폴더를 만들어야 하며, 검증을 위해 각 폴더에 spec.md
00:15:27및 기타 파일들이 필요하다고 알려주게 됩니다. 보시다시피 여기서 두 가지 기능을 정의했습니다.
00:15:33첫 번째는 미용실의 각 직원 정보가 포함된 서비스 페이지가 생성되어야 한다는 기능이고,
00:15:38두 번째는 고객이 미용실 스타일리스트와 세션을 마친 후, 관리자인 리셉셔니스트를 통해
00:15:43리뷰를 남길 수 있어야 한다는 기능입니다. 이제 여기서 새 기능 스킬을 사용하는 대신
00:15:48리셉셔니스트, 즉 관리자를 통해 리뷰를 남길 수 있습니다. 이제 여기서 새 기능 스킬을 사용하는 대신,
00:15:53목표 작성자 스킬을 직접 사용합니다. 이제 이 모든 스킬들은 상호 연결되어 있습니다. 따라서 만약
00:15:58목표 작성자를 사용하지 않으면 됩니다. 하지만 목표 작성자를 사용하면 이 새 기능 스킬이 트리거되어
00:16:03사양(spec) 파일을 실행 가능한 목표로 만드는 규칙도 함께 추가됩니다. 앞서
00:16:08논의했듯이, 구현을 시작하기 전에 기능의 UI를 먼저 만들어야 합니다. 이것이 바로
00:16:13새 기능 스킬이 기능성 UI(functional UI) 스킬을 호출하는 이유입니다. 이 스킬은 앱 내부에
00:16:18mocks라는 폴더가 있어야 하며, 해당 mocks 폴더 내의 HTML 파일이
00:16:23전체 앱의 완전한 기능적 프로토타입 역할을 할 것이라고 지시합니다. 또한
00:16:29리셉셔니스트와 고객 모두를 위한 뷰를 포함하게 됩니다. 이 파일은 각 폴더마다
00:16:33오직 하나만 존재해야 하며, 기능성 UI 스킬은 아직 생성되지 않은 경우에만 이를 생성합니다.
00:16:37당연히 새로운 기능이 생성될 때마다 트리거되므로 각 기능 폴더 내부에
00:16:42HTML 파일도 함께 추가될 것입니다. 이제 이미 복제된 앱을 가져와서 해당 기능에 의해 변경되는
00:16:47HTML 파일도 함께 추가됩니다. 이제 이미 복제된 앱을 가져와서 변경되는 부분만 가져와서
00:16:53그것만 보여줍니다. 예를 들어, 여기 서비스 기능이 있는데,
00:16:58이 목업을 열어보면 앱에 전체 서비스 페이지를 추가하고
00:17:04이 버튼을 통해 접근할 수 있게 되는 것을 볼 수 있습니다. 그리고 지금 예약하기를 클릭하고 스타일리스트를 선택하면
00:17:08먼저 해당 스타일리스트에게 어떤 서비스를 받을지 묻게 됩니다. 사실 이것은 아직
00:17:13앱에 구현된 적이 없고 복제본 내에도 구현되지 않았지만, 이 기능
00:17:19프로토타입에 구현되어 있습니다. 따라서 만들고 있는 것이 실제로 원하는 것인지 시각화하는 데 도움이 됩니다. 그리고 이것은 또한
00:17:24루프가 빌드 중인 내용이 올바른지 실제로 검증할 수 있는 방법이 됩니다. 따라서 그 후에,
00:17:29두 가지 기능을 작성하도록 지시했고, 세션 리뷰와
00:17:33서비스 폴더를 작성했습니다. 이것이 세션 리뷰의 UI입니다. 그리고 이번에도 마찬가지로
00:17:38고객과 안내원 양쪽의 시선으로 볼 수 있습니다. 안내원이 고객을 대신해 리뷰를 추가하게 되는데,
00:17:43현재 사이트가 이런 식으로 작동한다고 상상하고 있기 때문입니다. 실제 사이트에서는 이런 일이 일어나지 않겠지만,
00:17:47데모 사이트이므로 그냥 기능을 구상해 보는 것입니다. 이제 작업할 기능이 여러 개 있으므로,
00:17:52기본적으로 이를 추적할 목록이 필요합니다. 그래서 이 기능
00:17:57배치 스킬이 있는 것이며, 이는 단지 기능들이 나열된 하나의 테이블인
00:18:02Q 마크다운 파일을 사용할 뿐입니다. 예를 들어, 지금도 루프가 계속 진행 중이며 첫 번째 기능을
00:18:06빌드하고 있고 두 번째 기능은 여전히 할 일 목록에 있으며, 하나씩 표시해 나갈 것입니다. 따라서 여러분은
00:18:11스킬을 호출하고 원하는 기능을 추가하라고 지시하기만 하면 됩니다. 그런 다음 보시다시피,
00:18:16두 파일을 모두 작성 중이라고 말하며 해당 기능들을 추가했습니다. 그런 다음 기능들을 추가하고 나면,
00:18:21실제로 실행할 수 있는 목표 명령어를 제공합니다. 우리는 이를 약간 수정하여 큐
00:18:26파일 안에서 실행했으며, 할 일이나 빌딩 상태에 있는 행이 없을 때만 멈추도록 했습니다. 즉,
00:18:31모두 완료되어 완료 상태로 이동했음을 의미합니다. 그리고 실제로 작동하기 시작했습니다. 여전히 첫 번째 기능에 대해
00:18:36진행 중이며, 앞서 말씀드린 것처럼 먼저 서브 에이전트를 사용하여 실제로 항목을 빌드하고
00:18:41작업을 확인 및 검증하기 위해 적대적 에이전트를 실행할 것입니다. 아직 진행 중이며,
00:18:46대략 3시간 정도 지났고 완료되면 최종 결과를 보여드리겠습니다. 보시다시피
00:18:51GitHub를 열어두었고 여기에 우리 루프 살롱 프로젝트가 있습니다. 찾을 수 없다면,
00:18:55에이전트에게 이 링크를 달라고 요청하면 바로 열 수 있습니다. 자, 바로 이곳에서
00:19:00이 풀 리퀘스트 탭을 볼 수 있으며, 이를 열면 에이전트가 검토를 위해 작성한
00:19:04풀 리퀘스트를 볼 수 있습니다. 이것을 보면, 전체 요약을 제공하고 나서
00:19:09수행해야 할 작업이 실제로 완료되었다는 증거로 페이지의 스크린샷을
00:19:13실제로 제공해 주었습니다. 이 모든 것을 검토한 후, 풀 리퀘스트를 병합하기만 하면 됩니다. 그리고 보시다시피,
00:19:18여기에 라이브 호스팅 버전이 있습니다. 도메인이 없기 때문에
00:19:23Vercel로 끝납니다. 하지만 보시다시피 이 서비스 기능이 추가되기를 원했고, 이제
00:19:27서비스 기능으로 들어가면 살롱에서 제공하는 모든 서비스를 볼 수 있습니다. 그리고 지금 예약하기 옵션으로 들어가면
00:19:33각 스타일리스트마다 자신만의 서비스가 지정되어 있는 것을 실제로 볼 수 있습니다. 그리고 예약을 하기 전에,
00:19:37기본적으로 서비스를 선택해야 합니다. 그리고 이 두 번째 풀 리퀘스트를 병합할 때도
00:19:42똑같은 일이 일어날 것입니다. 그리고 우리가 여기서 다룬 모든 것들을 기본적으로
00:19:47여러분이 직접 가서 구축할 수 있는 방식으로 설명했습니다. 스킬은 실제로 파일에 들어 있는
00:19:51작성된 지침에 불과합니다. 따라서 여기에는 여러분이 직접 만들 수 없는 것은 아무것도 없습니다. 하지만 그 모든 과정을 거치고 싶지 않다면,
00:19:56전체 저장소가 우리의 커뮤니티인 AI Labs Pro에 있습니다.
00:20:01방금 보신 그대로 모든 스킬이 이미 들어 있는 전체 시스템이 바로 그것입니다.
00:20:05그러므로 저희가 하는 일에서 가치를 발견하셨고 채널을 지원하고 싶으시다면, 그것이 바로
00:20:10올바른 방법입니다. 링크는 설명란에 남겨두겠습니다. 자, 이제 이 전체 과정에서 여러분이 해야 할 일은
00:20:14단 두 가지밖에 남지 않았습니다. 이제 여러분은 기능을 기획하고, 기능이나 변경 사항이 사용자에게 전달되기 전에
00:20:19최종 승인을 내려주기만 하면 됩니다. 그 두 가지 일 모두 실제로 여러분이 노트북 앞에 있을 필요가 없으며,
00:20:24특히 기획 단계가 그렇습니다. 원하는 것을 설명하면, 이해할 때까지 질문을 던지고
00:20:28프로토타입을 빌드해 주며, 이 모든 과정이 스마트폰에서 이루어질 수 있습니다.
00:20:33사소한 변경 사항이라면, 휴대전화로 직접 최종 승인을 내려줄 수도 있습니다.
00:20:37여기서 레벨 3가 등장하며, 그 주된 목표는 노트북에 대한 의존성을 없애는 것입니다.
00:20:43이 목적을 위해, Paseo라는 정말 좋은 앱을 찾았습니다. 이 앱은 여러분의 노트북에서 에이전트를 실행하고
00:20:48휴대전화로 그 안을 들여다볼 수 있는 창을 제공합니다. 따라서 에이전트는 여전히 모든 파일,
00:20:52모든 스킬, 이미 로그인된 모든 CLI가 있는 여러분의 머신에 남아 있습니다. 그리고 이 영상에서 빌드한 모든 것들이
00:20:57계속해서 작동합니다. Claude Code 역시 내장된 원격 제어 기능을 통해 이를 수행할 수 있지만,
00:21:03그 기능 중 많은 부분이 고장 나 있습니다. 스킬의 경우, Claude의 원격 제어 기능 안에서는 스킬을 실행할 메뉴를 제대로 얻을 수 없습니다.
00:21:07따라서 이것이 무료 앱이며, 아래에 링크를 남겨두겠습니다.
00:21:12그것이 하는 모든 일에 대해 깊이 파고들지는 않고, 여러분이 시작할 수 있도록 필수적인 부분만 다루겠습니다.
00:21:17이 앱에는 각 워크스페이스가 기본적으로 폴더인 워크스페이스 시스템이 있으며, 그 안에서
00:21:22여러 채팅을 열 수 있고 앱 자체가 Claude Code를 실행하므로 별도의
00:21:26다른 구독이 필요하지 않습니다. 그다음으로 정말 흥미로운 또 다른 부분은, 이것이 노트북에서만
00:21:31실행되는 것이 아니라 연결한 맥미니에서도 실행될 수 있다는 점입니다. 따라서 노트북에서
00:21:35맥미니를 제어할 수 있고 휴대전화에서도 그 맥미니를 제어할 수 있습니다. 그리고 전체 터미널 인터페이스 대신
00:21:40훨씬 더 세련되어 있습니다. Cursor처럼 보이지만 모든 기능은 여전히
00:21:45여기에 남아 있습니다. goal 명령어도 작동하고 우리가 만든 다른 모든 슬래시 명령어들도 작동합니다. 자, 그래서 우리는
00:21:49여기서 루프 엔지니어링 폴더를 열고 그 안에 세션을 만든 후 새로운 기능을 정의하고 있습니다.
00:21:54여기에는 모바일 미리보기 스킬이라는 새로운 스킬도 하나 더 있는데, 곧 설명해 드리겠습니다.
00:21:59자, 이것이 모바일에서 어떻게 보이는지 보여드리기 위해 휴대전화를 여기에 미러링해 두었으며, 이것은
00:22:03컴퓨터에서 볼 수 있는 것과 정확히 같은 인터페이스입니다. 모든 Claude Code 기능과 슬래시
00:22:09명령어들을 바로 사용할 수 있으므로, 새로운 기능을 시작하려면 모바일에서 바로
00:22:14new feature 슬래시 명령어를 실행하기만 하면 됩니다. 이전에 구현되지 않았던 고객 측 로그인 흐름을 구현했습니다.
00:22:18그런 다음 정말 흥미로운 부분이 있습니다. 당연히 기능 파일 전체를 작성하겠지만,
00:22:22목업이 어떻게 생겼는지 보여주기 위해 인터페이스 내에서 바로 이미지를 제공할 수 있으며,
00:22:27그 이미지들이 휴대전화에도 표시되므로 휴대폰에서 바로 UI를 확인할 수 있습니다.
00:22:32하지만 모바일 미리보기 스킬을 실행한 이유는 HTML 목업을 링크로 배포하기 때문입니다.
00:22:37그것들은 Vercel에서의 무료 배포이며, 링크를 클릭하면
00:22:42실제 목업으로 이동하게 되어, 단순히 이미지만 보는 것이 아니라 직접 클릭하며 앱을 제대로 사용할 수 있게 됩니다.
00:22:47그리고 그것이 바로 휴대폰으로 이 팩토리를 운영할 때 진정으로 원하는 바입니다.
00:22:51이것으로 이번 영상의 마치겠습니다. 채널을 지원하고 저희가 이런 영상을 계속 만들 수 있도록 돕고 싶으시다면
00:22:56아래의 슈퍼 랭스 버튼을 사용하여 그렇게 하실 수 있습니다. 언제나 시청해 주셔서 감사드리며,
00:23:01다음 영상에서 뵙겠습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기