00:00:00코딩 에이전트를 활용하려면 프레임워크가 필요하다는 사실은 누구나 알지만
00:00:04단순하면서도 온전히 자신만의 것이며, 시간이 흐르며 발전시킬 수 있는 체계를 가진 사람은 많지 않습니다.
00:00:09GitHub에는 지나치게 복잡하게 설계된 프레임워크가 넘쳐납니다. 사람들이 만드는 그 수많은 멀티 에이전트 시스템들,
00:00:15그 노고는 존중하지만, 사실 우리에게 필요한 건 그저 일을 깔끔하게 처리해 줄 아주 단순한 도구일 때가 많습니다.
00:00:19여러분에게는 빌드하고 싶은 좋은 아이디어가 있고, 에이전트 코딩 워크플로를 만드는 데
00:00:24실제 코딩보다 더 많은 시간을 허비하고 싶지 않으실 테니까요. 그래서 제가 준비했습니다.
00:00:29제가 코딩 에이전트로 새 프로젝트를 시작할 때마다 사용하는 정말 간단한 프레임워크입니다.
00:00:35기존 코드 베이스에서 작업하는 브라운필드(Brownfield) 개발은 방식이 조금 다른데,
00:00:40그건 다른 영상에서 다루기로 하고, 이번에는 그린필드(Greenfield) 개발에 집중해 보겠습니다.
00:00:45새로운 무언가를 만들 때 최대한 빠르게 궤도에 오를 수 있는 단순한 체계가 목표이며,
00:00:50여기서 다루는 모든 내용은 보편적입니다. 어떤 코딩 에이전트를 사용하든 이 원칙들은 동일하게 적용됩니다.
00:00:56이 영상은 크게 두 부분으로 나뉘며, 내용을 구체적으로 전달하기 위해
00:01:00설명과 동시에 여러분과 함께 직접 라이브 빌드를 진행해 보려 합니다.
00:01:05현재 제 코드 베이스에는 AI 레이어 외에는 아무것도 없는 상태입니다.
00:01:11모든 프로젝트의 시작점으로 삼는 몇 가지 명령어와 스킬들만 가져다 두었죠.
00:01:16완전 바닥부터 시작할 것이기에, 우선 초기 기획인 PRD 작성부터 시작해야 합니다.
00:01:21PRD는 애플리케이션의 최소 기능 제품(MVP)을 만들기 위해 작성하는 초기 작업 범위 문서입니다.
00:01:27본격적인 코딩에 들어가기 전, 초기 AI 레이어를 설정하는 단계에 많은 내용이 포함됩니다.
00:01:32그다음 PRD를 작업 단계별로 나누고, PIV 루프를 통해 하나씩 해결해 나갈 것입니다.
00:01:37PIV 루프가 무엇인지 예시와 함께 설명해 드리고, 전체 구현 과정을 진행하면서
00:01:43우리가 항상 지켜야 할 네 가지 황금률에 대해서도 다룰 예정입니다.
00:01:47이 황금률들은 PRD 작성, AI 레이어 설정, PIV 루프 수행 과정에 자연스럽게 녹아들 것입니다.
00:01:52예를 들어 컨텍스트 관리 같은 부분 말이죠. 컨텍스트는 AI 코딩 어시스턴트와 작업할 때
00:01:57가장 소중한 자원이며, 이는 영상 전체를 관통하는 핵심 주제가 될 것입니다.
00:02:03또한 모든 것을 명령어와 스킬로 만들고, 시스템을 진화시키는 사고방식도 다룰 것입니다.
00:02:08우리가 지향하는 것은 신뢰할 수 있고 반복 가능한 시스템을 구축하는 것이기 때문입니다.
00:02:14진행하면서 이런 핵심 테마들을 계속 언급하도록 하겠습니다. 매우 가치 있는 내용들이 될 거예요.
00:02:18그럼 제가 "AI 레이어"라고 부르는 초기 기획 단계부터 시작해 보죠.
00:02:23AI 레이어가 무엇인지 설명하고 지금 바로 함께 구축해 보겠습니다.
00:02:28AI 레이어란 코딩 에이전트의 컨텍스트로 활용하기 위해 코드 베이스에 생성한 모든 자산을 말합니다.
00:02:34무엇을 만들지 정의한 PRD, 어떻게 만들지 정의한 글로벌 규칙(Global Rules),
00:02:39코딩 에이전트를 위한 재사용 가능한 워크플로인 명령어가 여기에 포함됩니다.
00:02:45우선은 가장 핵심적인 명령어에 집중할 것이고, 조사를 위임할 서브 에이전트도 다룰 겁니다.
00:02:50제가 AI 레이어를 다루는 일반적인 방식이자 여러분께 공유할 리소스는,
00:02:55어떤 새 프로젝트에도 바로 적용할 수 있는 범용적인 명령어 세트를 갖추는 것입니다.
00:03:01핵심은 코드 베이스가 커지고 구체화됨에 따라 명령어 역시 특정 유스케이스에 맞춰
00:03:07더 강력하고 정교하게 진화시켜 나가는 것이며, 이것이 제가 추천하는 방식입니다.
00:03:13필요하시다면 제가 제공하는 리소스를 시작점으로 삼으셔도 좋습니다. 설명란에 GitHub 레포 링크를 남겨둘게요.
00:03:18체계를 이토록 단순하게 유지하는 이유는, 여러분이 각자의 상황과 작업 방식에 맞춰
00:03:23쉽게 변형하고 발전시킬 수 있도록 하기 위함입니다.
00:03:27Beemad나 GitHub spec kit 같은 복잡한 프레임워크보다 이런 방식을 추천하는 이유도 그것입니다.
00:03:33그런 도구들은 강력하지만 온전히 내 것으로 만들기가 어렵죠. 저는 여러분이 직접 주도권을 갖길 원합니다.
00:03:38이제 전체 PRD를 작성하는 모습을 보여드리겠습니다. 코드 베이스의 초기 규칙을 정의하고,
00:03:42첫 번째 명령어를 커스터마이징하는 과정도 살펴볼 겁니다. 서브 에이전트 이야기도 계속 곁들일 거고요.
00:03:48PIV 루프를 통한 실제 코딩 전에 기획 단계가 좀 길게 느껴질 수도 있겠지만, 매우 중요한 과정입니다.
00:03:52미리 계획을 세우는 게 더디게 보일 수 있어도, 좋은 규칙과 PRD라는 탄탄한 설계도가 있다면
00:03:57그 이후의 개발 과정은 훨씬 빠르고 안정적으로 진행될 수 있습니다.
00:04:03그럼 PRD부터 시작해 보죠. 많은 분이 "스펙(Spec)"이라고도 부르는데,
00:04:07애플리케이션의 초기 버전을 구축하기 위한 전체 작업 범위를 뜻합니다.
00:04:13이 단계에서 좋은 기반을 닦고 나면, 그다음부터는 브라운필드 개발 단계로 넘어가게 되죠.
00:04:18그 내용은 다음 영상에서 다룰 예정이니 기대해 주세요.
00:04:24현재 Claude Code 상에서는 AI 레이어 외에는 텅 빈 프로젝트 상태인데,
00:04:28우선 가벼운 대화부터 시작할 겁니다. 제 아이디어나 생각 중인 기술 스택,
00:04:34아키텍처 등을 그냥 이야기하는 거죠. 비정형적인 상태로 시작하는 게 진입장벽을 낮춰줍니다.
00:04:40그러다 어느 정도 내용이 쌓이면 이 대화 내용을 컨텍스트로 삼아 구조화된 PRD를 만듭니다.
00:04:45이 작업을 도와줄 명령어가 있는데, 잠시 후에 설명해 드리고 우선 아이디어부터 꺼내보죠.
00:04:50이번 영상의 예시로 만들어볼 것은 'Linktree'와 비슷한 서비스입니다.
00:04:55여러 링크를 정리해 올릴 수 있는 자신만의 랜딩 페이지를 직접 호스팅하는 버전이죠.
00:05:01각 링크의 클릭률 같은 분석 기능도 포함하고 싶습니다. 이걸 예시로 고른 이유는,
00:05:06단순히 'Vibe Coding'으로 뚝딱 만들 만큼 아주 쉽지도 않으면서,
00:05:12영상 끝날 때까지 결과물도 못 볼 만큼 지나치게 복잡하지도 않기 때문입니다.
00:05:16여기서는 음성 인식(STT) 도구를 활용해 내용을 전달할 텐데, 'Aqua Voice' 같은 도구를 강력 추천합니다.
00:05:20제가 사용하는 도구인데, Whisper Flow나 Epicenter Whispering 같은 좋은 무료 오픈소스 대안도 많습니다.
00:05:24제가 STT를 즐겨 쓰는 이유는, 솔직히 제가 분당 226단어를 타이핑할 자신은 없기 때문입니다.
00:05:29이런 도구를 사용해 빌드하고 싶은 내용을 먼저 머릿속에서 막 쏟아낼 겁니다.
00:05:33다듬어지지 않은 내용이겠지만, 지금 라이브로 브레인 덤프를 진행할 테니 제가 Claude Code에
00:05:39무엇을 요청하는지 잘 주목해 보세요. 제 아이디어만큼이나 그 요청 방식이 중요하거든요.
00:05:43나중에 부연 설명을 좀 더 드리겠습니다. 참고로 이 모든 과정은 어떤 AI 코딩 어시스턴트로도 가능합니다.
00:05:48자, 시작해 보죠. "Link-in-bio 페이지 빌더를 만들고 싶어."
00:05:54링크트리 같은 서비스인데, 사용자가 계정을 만들고 직접 링크를 지정한
00:05:59랜딩 페이지를 생성할 수 있어야 해. 링크 순서도 바꿀 수 있어야 하고.
00:06:03분석 기능도 있어서 링크의 클릭률을 확인할 수 있어야 하고 테마 커스터마이징도 가능하게 할 거야.
00:06:09기술 스택은 Next.js를 생각 중이고, DB와 인증은 Neon을 쓰고 싶어.
00:06:13그 부분에 대해서는 서브 에이전트를 띄워서 조사를 좀 해줘.
00:06:20아키텍처는 딱히 정해둔 건 없는데, 너의 추천을 듣고 싶어.
00:06:24테마 설정이나 링크 빌딩을 어떻게 처리할지에 대해서도 말이야.
00:06:29그러니까 에이전트를 하나 더 띄워서 이런 링크트리류 앱을 만들 때의
00:06:33베스트 프랙티스에 대해 웹 조사를 시켜줘. 그러고 나서 나한테 돌아와서
00:06:37우리가 만들 것의 세부 사항까지 서로 완벽히 이해할 수 있도록 질문을 한 보따리 던져줘."
00:06:43좋습니다, 이제 전송해 보죠. 몇 초 안에 텍스트로 변환될 겁니다.
00:06:48네, 됐네요. 자, 이제 본격적인 시작입니다. 방금 제가 한 일 중 가장 중요한 건
00:06:55마지막에 조사를 마친 뒤 나에게 질문을 많이 해달라고 시킨 부분입니다.
00:07:00이 점을 꼭 명심하셔야 합니다. 코딩 에이전트와 기획을 할 때 여러분의 지상 과제는
00:07:04에이전트가 멋대로 추측하는 일을 최소화하는 것입니다.
00:07:10코드 베이스에서 에이전트가 실수할 때, 그건 코딩 실력이 부족해서가 아니라
00:07:14정확히 무엇을 만들어야 하는지 서로 합이 맞지 않았기 때문인 경우가 태반입니다.
00:07:20나쁜 코드 한 줄은 그냥 한 줄의 나쁜 코드일 뿐이지만, 나쁜 계획 한 줄은
00:07:25수백 줄의 나쁜 코드를 낳을 수 있습니다. 하물며 PRD의 잘못된 한 줄은
00:07:32서로의 방향이 어긋난 탓에 수천 줄의 쓰레기 코드를 만들어낼 수도 있죠.
00:07:37그래서 저는 어떻게 하면 이런 추측을 줄일 수 있을지 오랫동안 실험해 왔고,
00:07:42코딩 에이전트가 저에게 질문 세례를 퍼붓게 하는 방식이 정말 효과적이라는 걸 발견했습니다.
00:07:48특히 Claude Code는 객관식이나 주관식 답변을 받을 수 있는 'Ask User Question' 도구가 있어서
00:07:54그 위력이 대단합니다. 곧 보게 되시겠지만, 우리가 미처 생각지 못한 예외 케이스나
00:08:02세부 사항까지 아주 꼼꼼하게 짚어줍니다. 에이전트가 어떤 지점에서 오해를 할지
00:08:08우리 스스로 추론해내기는 어렵거든요. 그래서 아주 강력한 방법입니다.
00:08:13그리고 보시는 것처럼 조사를 수행하기 위해
00:08:17여러 개의 서브 에이전트가 돌아가고 있습니다. 저는 기획이나 PRD 작성,
00:08:23혹은 나중에 다룰 PIV 루프의 계획 단계에서 서브 에이전트 활용을 매우 선호합니다.
00:08:28Claude Code에서는 탐색 및 조사용 서브 에이전트가 도구에 내장되어 있어 편리하지만,
00:08:33다른 에이전트를 쓴다면 직접 구축해야 할 수도 있기에 여기서 짚고 넘어가는 겁니다.
00:08:38하지만 요즘 잘나가는 코딩 에이전트들은 대부분 서브 에이전트 개념을 지원하죠.
00:08:42제가 서브 에이전트를 좋아하는 이유는 '컨텍스트 격리' 때문입니다. 다시 강조하지만 핵심은
00:08:48메인 코딩 에이전트의 컨텍스트를 최대한 보호하는 것입니다. 조사는 특히 서브 에이전트에게 딱인데,
00:08:53조사 과정에서는 온갖 자료를 다 들여다봐야 하기 때문입니다. 코드 베이스를 샅샅이 뒤지거나
00:08:59웹을 검색하며 수만, 수십만 토큰을 읽어 들이게 되죠. 하지만 정작 우리에게 필요한 건
00:09:04그들이 작업 끝에 메인 컨텍스트로 전달해 주는 핵심 요약뿐입니다.
00:09:08이렇게 하면 메인 컨텍스트를 깨끗하게 유지할 수 있죠. 반면 실제 구현 단계에서는
00:09:14서브 에이전트 사용을 권장하지 않습니다. 구현할 때는 수정하거나 생성한 파일들의
00:09:20전체 컨텍스트가 중요하기 때문입니다. 격리된 상태로 구현하면 제 경험상 환각 증상이 잦더군요.
00:09:26Claude Code에도 구현용 내장 에이전트가 없고 조사용만 있는 이유가 바로 그겁니다.
00:09:32지금 화면에 보이는 게 바로 그 조사 과정이고요. 모든 과정이 끝나고
00:09:36질문 리스트가 준비되면 다시 돌아오겠습니다. 자, 조사가 모두 끝났고 질문들이 도착했습니다.
00:09:41이 과정을 지켜보시면 저처럼 매력을 느끼실 겁니다. 수많은 불확실성이 해소되고 있거든요.
00:09:46우리가 여기서 답하는 질문 하나하나가 코딩 에이전트의 막연한 추측을 하나씩 제거하는 셈입니다.
00:09:51보통 에이전트가 제시하는 선택지 중에 정답이 있으므로 객관식 답변을 통해 아주 빠르게 진행할 수 있습니다.
00:09:57이렇게 세부 사항을 다 확정 짓고 나면 실제 구현 단계에서 훨씬 자신감을 가질 수 있죠.
00:10:01예를 들어, '공개 페이지의 URL 구조는 어떻게 할까요?'라는 질문에
00:10:06저는 1번 옵션이 맘에 드네요. 클릭하고 다음으로 넘어갑니다. '사용자당 몇 개의 페이지를 만들 수 있게 할까요?'
00:10:12일단 사용자당 한 페이지로 하죠. 그냥 기본 설정대로 쭉쭉 넘어가도 되는 것들도 있지만,
00:10:17에이전트가 근본적으로 오해하고 있는 지점에서는 직접 답변을 타이핑해 명확히 해줘야 합니다.
00:10:22지금 바로 그런 예시가 나올진 모르겠지만, 제가 질문들에 전부 답하고 다시 올게요.
00:10:26질문이 20개, 25개까지도 이어질 수 있어서 여러분이 이걸 다 보실 필요는 없습니다.
00:10:31시간이 좀 걸리고 인내심이 필요하지만, 여기서의 답변 하나가 수백 줄의 나쁜 코드를 막아줍니다.
00:10:36아, 마침 제가 제시된 것과는 완전히 다른 방향으로 명확히 하고 싶은 질문이 나왔네요.
00:10:41이건 Claude가 던진 두 번째 질문 묶음인데, '링크 에디터에 실시간 폰 프레임 미리보기가 있어야 할까요?'라고 묻네요.
00:10:46Lovable이나 Bolt.new처럼 만드는 화면 옆에 미리보기가 보일지, 아니면 인라인 방식일지 묻는 건데
00:10:50저는 사실 두 옵션을 다 원합니다. 이럴 땐 채팅으로 대화할 수 있죠.
00:10:54에이전트가 다른 질문들을 이어서 하겠지만, 지금은 이 특정 항목에 대해 좀 더 이야기해 보겠습니다.
00:10:59이렇게 말할게요. "인라인 에디터를 원하지만 미리보기도 볼 수 있는 옵션이 있으면 좋겠어."
00:11:03"기본적으로 버튼이 세 개 있어서, 하나는 에디터만, 하나는 둘 다, 하나는 미리보기만 보게 해줘."
00:11:07이렇게 보내면 에이전트가 확인하고 다음 질문을 이어갈 겁니다. 자, 드디어 끝났습니다.
00:11:14Claude가 질문을 쏟아냈는데, 필요 이상으로 많았을 수도 있지만 취향껏 조절하시면 됩니다.
00:11:19이제 최종 스펙 요약을 보니 우리가 무엇을 빌드할지, 심지어 나중에 어디에
00:11:24배포할지(저는 Vercel에 할 겁니다)까지 에이전트가 완벽하게 파악하고 있네요.
00:11:30정말 환상적입니다. 이제 막연한 추측은 거의 없어진 것 같아요. 그럼 이제
00:11:35PRD 생성 명령어를 실행하겠습니다. 파일은 '.claud/prd.md'에 저장할게요.
00:11:39위치나 이름은 원하시는 대로 정하시면 됩니다. 제가 아까 언급한 명령어를 사용할 건데,
00:11:44네 가지 황금률 중 하나인 '모든 것을 명령어화하라'를 지키기 위해서입니다.
00:11:49두 번 이상 반복하는 작업이라면(저는 프로젝트를 꽤 자주 시작하거든요), 명령어로 만들어야 합니다.
00:11:53Claude Code에서는 최근 명령어와 스킬이 통합되었지만, 저는 여전히 구분을 선호합니다.
00:11:58명령어는 'slash commit'처럼 사용자가 직접 실행하는 것이고,
00:12:03스킬은 에이전트가 새로운 기능을 수행하는 법을 알기 위해 컨텍스트를 읽는 등 스스로 판단해 쓰는 겁니다.
00:12:08지금은 대화 흐름상 제가 직접 이 타이밍에 구조화된 PRD를 뽑아내고 싶으니
00:12:13명령어를 사용하는 것이죠. 이 명령어에는 제가 PRD에 들어가길 원하는
00:12:18정확한 구조와 모든 섹션이 정의되어 있습니다. 덕분에 전체 프로세스를 반복 가능하게 만들 수 있죠.
00:12:23이 시스템의 장점은 자신에게 맞는 방식을 한 번 정립해두면, 새로운 기능이나
00:12:28다른 프로젝트에서도 몇 번이고 똑같이 활용할 수 있다는 점입니다.
00:12:31자, 'slash create PRD'를 실행하겠습니다. 결과가 나오면 다시 돌아올게요.
00:12:36PRD가 생성되었습니다. 아주 포괄적인 내용이 담겨 있네요.
00:12:43코딩 에이전트에게 이걸 통째로 던져서 한 번에 구현하라고 시킬 건 아니니 괜찮습니다.
00:12:47대신 PRD에 기술된 단계별로 빌드를 진행할 겁니다. 내용 검증 과정을 일일이
00:12:53보여드리는 건 시간 낭비겠지만, 여러분은 꼭 한 번 읽어보며 에이전트와 합이 맞는지 확인하셔야 합니다.
00:12:59그렇지 않으면 나중에 엉뚱한 코드가 나올 수 있거든요. 몇 가지만 짚어보자면,
00:13:03우선 MVP 범위 섹션을 보면 우리가 나눈 질문과 답변들이 PRD에 그대로 녹아들어 있습니다.
00:13:10중요한 포인트는, 방금 나눈 대화는 PRD를 만들기 위한 비정형 컨텍스트였을 뿐이고
00:13:15결국 남는 건 PRD뿐이라는 점입니다. 그러니 대화의 정수가 여기에 다 담겨 있어야 하죠.
00:13:20지금 당장 빌드하지 않을 '제외 범위(Out of scope)'도 명시되어 있고, 전체 디렉터리 구조도 잡혀 있네요.
00:13:27이미 기술 스택과 아키텍처를 확정했기에 코드 베이스에 무엇이 들어갈지도 이미 파악된 상태입니다.
00:13:32가장 중요한 건 바로 이 '작업 단계(Phases)'입니다. 나중에 'Prime' 명령어를 사용할 때
00:13:38코드 베이스에 무엇이 이미 구현되었고, PRD에 따라 다음에 무엇을 구현해야 할지
00:13:42판단하는 근거가 됩니다. MVP를 구축해 나가는 모든 대화의 시작점에서 아주 중요한 컨텍스트가 될 겁니다.
00:13:48여기 작업 단계를 나열한 섹션이 있네요. 각 단계는 PIV 루프를 통해
00:13:53하나의 구체적인 구현 작업이 될 겁니다. 기반을 다지고, 링크 관리 기능을 만들고,
00:14:00테마 기능을 만드는 식으로요. 각 단계를 개별적으로 계획함으로써
00:14:04코딩 에이전트가 한꺼번에 너무 많은 일을 하려다 망치는 것을 방지합니다. 자, PRD를 만들었습니다.
00:14:09가장 큰 산을 넘었네요. 첫 구현을 시작하기 직전입니다. 다음으로 설정할 건 '규칙(Rules)'입니다.
00:14:14처음엔 꽤 기본적일 겁니다. 규칙은 코드 베이스가 진화함에 따라 함께 계속 발전할 것이기 때문입니다.
00:14:18저는 Claude Code를 쓰고 있어서 '.agents'와 'agents.md' 파일을 참조할 텐데,
00:14:22이것이 글로벌 규칙 명명의 보편적인 표준이기 때문입니다.
00:14:29중요한 건 코딩 에이전트가 항상 따라야 할 제약 사항과 컨벤션을 이 글로벌 규칙 파일에 넣는다는 겁니다.
00:14:34앱 실행 명령어, 테스트 전략, 로깅 전략 같은 것들이 포함되죠.
00:14:40무엇을 만들든 에이전트가 늘 숙지해야 할 내용입니다. 일단 시작을 위한 초기 버전을 만들어보죠.
00:14:44또 하나는 'reference' 폴더입니다. Claude Code의 스킬을 써도 되지만,
00:14:49이 방식이 좀 더 범용적입니다. 특정 부분 작업 시에만 필요한 컨텍스트가 있을 수 있으니까요.
00:14:53예를 들어 프런트엔드 작업 시에만 참고할 컴포넌트 제작 가이드 같은 거죠.
00:14:58이런 내용을 'agents.md'에 다 때려 넣지 않는 이유는, 그 파일은 매 대화마다
00:15:04전체 컨텍스트로 로드되기 때문입니다. 컨텍스트는 아껴야 하니까요. 'agents.md'는 간결하게 유지하면서
00:15:09각 파일로 링크만 걸어주는 게 좋습니다. 에이전트에게 "프런트엔드 작업 중이라면 이 파일을 읽어라"
00:15:13혹은 "새 API 엔드포인트를 만든다면 이 파일을 읽어라"라고 지시하는 식이죠.
00:15:19이것이 바로 '점진적 공개(Progressive Disclosure)'입니다. 여러 층의 컨텍스트를 두고
00:15:24에이전트가 현재 작업에 꼭 필요한 내용만 골라 로드하도록 유도하는 것이죠.
00:15:29이를 위해 저는 또 다른 명령어를 준비했습니다. 다시 말하지만 '모든 것을 명령어화'하세요.
00:15:33PRD 템플릿이 있듯 글로벌 규칙 생성에도 저만의 템플릿이 있습니다.
00:15:38우선 에이전트가 현재 코드 베이스에 무엇이 있는지 파악하게 할 겁니다.
00:15:43기존 프로젝트와 새 프로젝트 모두에서 작동하도록 만들었거든요. 지금 상태에서는
00:15:48PRD만 훑어보게 될 겁니다. 기술 스택과 아키텍처를 파악하고, 테스트 및 로깅 전략에 대한
00:15:53웹 조사를 수행한 뒤, 저의 가이드와 합쳐서 글로벌 규칙을 생성할 겁니다.
00:15:58제가 정해둔 구조가 있고 그 템플릿을 기반으로 만들어질 겁니다. 이 내용도 빠르게 보여드릴게요.
00:16:04이 명령어는 에이전트가 PRD와 기본 정보를 바탕으로 규칙 파일을 초기화하도록 돕습니다.
00:16:10자, 규칙 생성을 요청하겠습니다. 에이전트가 파일을 만들고 있네요.
00:16:16규칙 파일이 완성되면 그 내용을 함께 살펴보면서 왜 이런 구조가 효율적인지 설명하겠습니다.
00:16:20이 파일은 앞으로 프로젝트의 나침반 역할을 하게 될 아주 중요한 자산입니다.
00:16:25에이전트가 멋대로 코딩 스타일을 바꾸거나 엉뚱한 라이브러리를 쓰는 걸 방지해 주죠.
00:16:30이제 드디어 실제 코드를 작성할 준비가 거의 다 되었습니다.
00:16:35기획과 규칙 설정에 공을 들인 만큼, 실제 코딩 속도는 엄청나게 빨라질 겁니다.
00:16:40많은 분이 이 단계를 건너뛰고 바로 코딩을 시키려 하지만, 그게 더 시간을 잡아먹는 지름길입니다.
00:16:44파일이 생성되었습니다. 내용을 보니 아주 깔끔하게 정리되었네요.
00:16:49우리의 기술 스택인 Next.js, Neon DB, Vercel 배포에 최적화된 규칙들입니다.
00:16:55자, 이제 기초 공사는 끝났습니다. 본격적으로 기능을 하나씩 구현해 볼까요?
00:17:00첫 번째 단계인 프로젝트 기반 설정 및 환경 구축부터 진행해 보겠습니다.
00:17:04이것은 본질적으로 점진적 공개 방식입니다. 우리는 다양한 계층의 컨텍스트를 구성하여
00:17:09에이전트가 현재 직면한 작업에 따라 실제로 필요한 정보만 로드할 수 있도록,
00:17:14시간이 지남에 따라 이를 발견하게 합니다. 그래서 이 부분에도 별도의 명령어를 만들었습니다. PRD 템플릿처럼
00:17:20모든 것을 명령어화하는 거죠. 저는 글로벌 규칙(Global Rules)을 생성할 때 사용하는 전용 템플릿이 있습니다.
00:17:25먼저 코드베이스에 이미 무엇이 있는지 탐색할 것입니다.
00:17:30기존 코드베이스와 새로운 코드베이스 모두에서 작동하도록 만들었기 때문입니다. 여기서 에이전트가
00:17:35탐색할 대상은 주로 PRD입니다. 기술 스택과 아키텍처를 파악하고,
00:17:38테스트 및 로깅 전략에 대한 웹 리서치를 수행한 뒤, 이 모든 것을
00:17:43저의 가이드와 결합하여 글로벌 규칙을 생성합니다. 여기에 정확한 구조가 나와 있습니다.
00:17:50제가 사용하는 이 템플릿을 기반으로 생성될 것입니다. 아주 빠르게 보여드리자면,
00:17:55이것이 제가 모든 글로벌 규칙에 즐겨 사용하는 템플릿입니다. 보시다시피
00:17:59이 항목들은 우리가 어떤 작업을 하든 에이전트가 반드시 알아야 할 내용들입니다. 기술 스택,
00:18:04실행 및 테스트 명령어, 프로젝트 구조 등이 포함되죠. 기본적으로 코드베이스의 인덱스,
00:18:08아키텍처, 네이밍 컨벤션 같은 코드 패턴, 테스트 및 검증 전략 등이 들어있습니다.
00:18:13전체적으로는 꽤 기본적인 내용이지만, 우선 이것을 먼저 생성하겠습니다.
00:18:17그다음 보조적인 온디맨드 컨텍스트인 참조 문서의 몇 가지 예를 보여드릴게요.
00:18:22이제 Claude로 돌아가서, PRD를 만들었던 것과 동일한 대화창에서
00:18:27“create rules” 명령어를 실행하겠습니다. 이전 대화의 모든 내용을 컨텍스트로 활용할 수 있으니까요.
00:18:33에이전트는 즉시 PRD와 기술 스택 등을 파악합니다. 좋습니다.
00:18:38규칙 생성 명령어가 완료되었고, 이제 글로벌 규칙이 준비되었습니다. 이미 파일을 열어두었는데요,
00:18:43꽤 표준적인 구성입니다. 기술 스택과 명령어가 있고,
00:18:47예를 들어 데이터베이스에 Drizzle ORM을 사용한다는 점, 프로젝트 구조, 아키텍처,
00:18:52코드 패턴 등이 포함되어 있습니다. 시간 관계상 여기서는 내용을 세세하게 커스터마이징하거나
00:18:57제 생각을 많이 반영하지는 않았지만, 여러분의 기술적 수준에 따라
00:19:03제약 사항, 컨벤션, 코드 패턴이 본인이 원하는 방식과 일치하는지
00:19:07반드시 확인해야 하는 단계입니다. 원하신다면 이 부분에 많은 시간을 투자하셔도 좋습니다.
00:19:12지금은 핵심 개념을 설명하는 데 집중하기 위해 생략하겠습니다. 또한 에이전트에게
00:19:16프론트엔드 컴포넌트나 API 엔드포인트 생성에 관한 모범 사례를 웹 리서치하게 했습니다.
00:19:21그 결과에 따라 몇 가지 온디맨드 컨텍스트도 생성했습니다. 다시 말씀드리지만,
00:19:24이것들은 원하신다면 Claude의 code skills로 구성할 수도 있습니다. 글로벌 규칙 파일의
00:19:29온디맨드 컨텍스트 섹션으로 내려가 보겠습니다. 여기 있네요. 프론트엔드 작업 시에는
00:19:34이 파일을 읽고, API 라우트 작업 시에는 저 파일을 읽으라고 되어 있습니다. 즉, claude.md만
00:19:40처음에 로드되고, 나머지는 필요할 때 가져오는 식입니다. 제 경험상 글로벌 규칙이
00:19:45간결할수록 에이전트가 이런 참조를 아주 잘 수행합니다. 보시다시피
00:19:50글로벌 규칙은 240행도 안 되는 233행뿐입니다. 반면 api.md나
00:19:58components.md는 훨씬 더 큽니다. 매우 구체적인 작업에 들어갔을 때는
00:20:03코딩 에이전트에게 더 많은 가이드 정보를 제공해도 괜찮기 때문입니다. 다시 다이어그램으로
00:20:08돌아가 보겠습니다. 규칙(Rules)은 어떻게 만들 것인가에 대한 것이고,
00:20:14PRD는 정확히 무엇을 만들 것인가에 대한 것입니다. 이 두 가지를 염두에 두고
00:20:19마지막으로 이야기할 것은 명령어, 특히 “prime” 명령어입니다.
00:20:23그다음 첫 번째 단계의 계획을 세우고 코드를 작성해 보겠습니다. 현재 우리는
00:20:29초기 AI 레이어를 갖췄습니다. PRD, 규칙, 그리고 제가 가져온 범용 명령어들이 있죠.
00:20:34이제 구현 단계로 넘어가겠지만, 중요한 점이 있습니다.
00:20:39AI 코딩 어시스턴트와 새로운 대화를 시작할 때마다,
00:20:44에이전트가 코드베이스의 현재 상황을 파악해야 합니다. 우리가 무엇을 만들고 있고, 다음 단계가 무엇인지 말이죠.
00:20:50이때 사용하는 것이 바로 prime 명령어입니다. 매 세션 시작 시
00:20:56/prime을 실행할 것입니다. 이것은 에이전트가 코드베이스를 탐색하고 다음 기능 구현을 위한
00:21:02멘탈 모델을 갖추도록 안내하는 프로세스입니다. 에이전트가
00:21:06문서를 읽고 구조를 탐색하게 하며, 이 과정에서 서브 에이전트를 활용할 수도 있습니다.
00:21:11또한 git log를 확인하는 작업도 포함되는데, 이에 대해서는 잠시 후 자세히 설명하겠지만
00:21:15git log를 장기 기억 장치로 사용하는 것입니다. 코드베이스가 어떻게 진화해 왔는지 파악하면
00:21:21다음에 무엇을 구축할지 결정하는 데 도움이 되기 때문입니다. 이 명령어가 끝나면
00:21:26에이전트는 코드베이스에 대한 이해도를 출력합니다. 이를 통해 우리는 에이전트가
00:21:31상황을 정확히 파악했는지 검증하고 다음 단계로 넘어갈 수 있습니다. prime 명령어를
00:21:36너무 자세히 설명하지는 않겠지만, git의 히스토리를 활용하기 위해 몇 가지 작업을 수행합니다.
00:21:40그다음 핵심 파일들을 읽고 어플리케이션의 주요 엔트리 포인트처럼
00:21:45특별히 주의 깊게 살펴봐야 할 부분을 식별합니다.
00:21:49그리고 출력된 보고서를 통해 에이전트의 이해도를 검증합니다. 이 과정은 프로젝트에 맞춰
00:21:55시간이 지남에 따라 발전시킬 수 있습니다. 한 가지 작은 예를 들면,
00:22:01핵심 문서 읽기 단계에서 “Drizzle 마이그레이션 파일을 읽고 데이터베이스 스키마를 파악해라”
00:22:08라고 지시할 수 있습니다. 자동 완성이 될 정도로 제가 의도한 바를 정확히 알고 있네요.
00:22:12여러분이 이 코드베이스에서 코딩 에이전트가 집중해야 할 핵심 사항이 무엇인지,
00:22:16가령 reference 폴더에 있는 다른 문서라든지, 그런 것들을 이해하게 되면 여기에 추가하면 됩니다.
00:22:20이제 Claude로 가서 완전히 새로운 대화를 시작하겠습니다.
00:22:25이제 첫 번째 PIV 루프를 시작할 것이기 때문입니다. PIV 루프에 대해서는 잠시 후 자세히 설명하겠지만,
00:22:30한번 보세요. 그냥 Prime을 실행하겠습니다. 이것이 탐색을 시작하기 전
00:22:34대화의 시작점이 될 것입니다. 그러면 에이전트는 이것이 완전히 새로운 프로젝트임을 깨닫고
00:22:39PRD를 확인한 뒤, “1단계부터 시작합시다. 프로젝트의 기초를 만들어보죠”
00:22:44라고 제안할 것입니다. Prime이 완료되었습니다. 프로젝트 개요인 “Link in bio 페이지 빌더”가 보이네요.
00:22:49현재 상태는 문서만 있는 빈 저장소입니다. 사실 제가 아까 테스트 빌드를 해봐서
00:22:54기록이 남아있지만, 지금은 모두 지운 상태입니다. 그리고 에이전트가 PRD에서
00:22:59첫 번째 단계인 기초 공사(Foundation)를 가져왔습니다. 이것이 에이전트가
00:23:04제안하는 개발 내용입니다. 제가 원하던 바죠. 에이전트가 PRD에서 단계를 하나씩 선택해서
00:23:10세밀하게 구현해 나가는 PIV 루프를 진행하기를 원합니다. 자, 그럼 이제
00:23:14PIV 루프에 대해 알아보겠습니다. PIV는 계획(Plan), 구현(Implement), 검증(Validate)의 약자입니다.
00:23:20보통 PRD의 한 단계를 대상으로 이 전체 프로세스를 실행합니다. 먼저 무엇을 처리할지에 대해
00:23:29구조화된 계획을 수립합니다. 이 부분이 바로 여기죠.
00:23:34이 과정은 사실 PRD를 만드는 과정과 꽤 비슷합니다. 그다음 구현 단계로 넘어갑니다.
00:23:38우리의 목표는 모든 코딩 작업을 코딩 에이전트에게 위임하는 것입니다. 그리고 마지막에 검증을 하죠.
00:23:44이 프로세스가 어떻게 진행되는지 빠르게 훑어본 다음, 실제 작동 모습을 보여드릴게요.
00:23:50먼저 계획 단계에는 두 가지 레이어가 있습니다. 첫 번째는 이미 우리가 수행한
00:23:55PRD 및 규칙 생성과 같은 최상위 프로젝트 계획입니다. 그리고 이제
00:24:00작업별 구체적인 계획(Task specific planning)을 세웁니다. 앞서 언급했듯이,
00:24:07구조화된 계획을 만드는 것은 PRD를 만드는 것과 비슷합니다. 주요 차이점은
00:24:13구조화된 계획은 개별 기능과 그에 따른 모든 세부 작업에만 아주 집중한다는 점입니다.
00:24:19이제 코드로 들어가는 단계입니다. 더 이상 고수준의 이야기만 하는 것이 아니죠. 하지만 여전히
00:24:24비구조화된 대화로 시작할 것입니다. 저는 이를 “바이브 플래닝(vibe planning)”이라 부르는데,
00:24:30일반적인 아이디어를 탐색하는 단계입니다. 구축하려는 기능의 구체적인 아키텍처는 무엇인지,
00:24:35코드베이스 분석 및 문서를 위해 서브 에이전트를 구동하고, 이 기능을 위해
00:24:40해결해야 할 구체적인 작업이 무엇인지 파악하는 단계입니다. 이런 대화를 나누고 나서,
00:24:44나중에 예시를 보여드리겠지만, 이를 PRD처럼 구조화된 문서로 변환합니다.
00:24:50목표는 대화 내용을 바탕으로 AI 코딩 어시스턴트를 위한 상세한 공격 계획을 만드는 것입니다.
00:24:56대화 자체도 컨텍스트의 일부이지만, 구조화된 계획에는 제가 만들고자 하는
00:25:02매우 구체적인 섹션들이 포함되어야 합니다. 기능의 목표와 성공 기준,
00:25:09서브 에이전트가 찾은 참고 문서, 그리고 생성하거나 업데이트해야 할
00:25:13개별 파일 단위까지 아주 상세하게 기술된 작업 목록(Task list)입니다. 그리고 아마도
00:25:18이 전체 계획에서 가장 중요한 부분은 검증 전략(Validation strategy)일 것입니다.
00:25:23이것은 테스트 주도 개발(TDD)과 유사합니다. 단 한 줄의 코드를 작성하기 전부터
00:25:27이 기능을 어떻게 검증할지 매우 구체적으로 정하는 것이죠. 이는 우리와 코딩 에이전트 모두에게
00:25:33성공 기준을 명확히 하도록 강제합니다. 이렇게 우리는 구조화된 계획을 세우는 데
00:25:38적극적으로 참여하지만, 실제 코딩은 모두 에이전트에게 위임합니다. 그렇다고 이것이
00:25:45“바이브 코딩”은 아닙니다. 제가 에이전트를 믿고 맡기되 나중에 검증하는 이유는,
00:25:51제가 직접 참여한 계획 단계와 검증 단계 사이에 구현 과정을
00:25:56끼워 넣었기 때문입니다. 따라서 코딩 에이전트가 유닛 테스트, 통합 테스트,
00:26:01E2E(End-to-End) 테스트를 통해 스스로의 결과물을 확인하게 할 것입니다. 그것도 곧 보시게 될 거예요.
00:26:06하지만 그 후에 저 또한 직접 코드 리뷰를 하고 어플리케이션을 수동으로 테스트할 것입니다.
00:26:11커밋을 하고 프로덕션이나 스테이징 서버로 보내기 전에, 직접 사용자가 되어
00:26:16어플리케이션의 모든 기능이 제대로 작동하는지 꼼꼼히 확인할 것입니다.
00:26:20여기서 중요한 점은 계획 단계와 구현 단계 사이에 컨텍스트를 초기화한다는 것입니다.
00:26:26이것은 황금률 중 하나인데, 컨텍스트는 매우 소중하기 때문입니다. 구현할 기능에 대해
00:26:32길고 상세한 대화를 나누고 나서 만든 이 구조화된 계획이,
00:26:38코딩 에이전트가 작업을 완수하는 데 필요한 유일한 컨텍스트가 되기를 원합니다. 그래서
00:26:44계획 문서만 전달하는 새로운 대화를 시작하는 것이죠. 거기에는 필요한 모든 참조 문서와
00:26:50전체 작업 목록이 들어있습니다. 무엇을 해야 할지, 어떻게 검증할지도 알고 있죠.
00:26:55이렇게 하면 군더더기를 쳐내고 실행에만 온전히 집중할 수 있습니다. 실제 코드를 작성할 때
00:27:00대화창에 불필요한 컨텍스트가 가득 차는 것을 원치 않기 때문입니다. 좋습니다.
00:27:06그럼 이제 첫 번째 PIV 루프를 시작해 보죠. 생각보다 훨씬 간단할 것입니다.
00:27:12미리 정성 들여 계획을 세워둔 덕분에 그 보상을 받는 셈이니까요. 우리는 코딩 에이전트와
00:27:16같은 방향을 바라보고 있고, 에이전트가 우리의 의도를 완벽히 이해했다는 확신이 있습니다.
00:27:22따라서 초기 단계에서는 각 단계별 계획에 그렇게 많은 노력을 들일 필요가 없습니다.
00:27:27다시 돌아와서, prime 단계가 끝났습니다. 코딩 에이전트와 의견을 맞췄고,
00:27:31저는 아주 간단한 프롬프트를 줬습니다. “1단계가 좋아 보이네요. 우리가 무엇을 만들지
00:27:36정확히 확인해 주세요.”라고요. 보통 첫 번째 루프 이후의 PIV 루프는 더 상세하게 진행됩니다.
00:27:40코드베이스를 보면서 어떻게 구축할지 구체적으로 고민하죠. 하지만 지금은 매우 단순합니다. 좋습니다.
00:27:44자, 다시 모든 것을 명령어화합시다. 이 대화 내용과 1단계의 아이디어를
00:27:49작업 목록과 검증 절차가 포함된 구조화된 계획으로 바꾸고 싶습니다. 이를 위한 명령어가 있습니다.
00:27:53바로 /plan-feature 입니다. 이 명령어를 실행하면,
00:27:59PRD 생성 때처럼 구조화된 계획 개념이 내장된 프로세스가 작동합니다. 이 명령어도
00:28:04한번 보여드릴게요. plan-feature를 열어보겠습니다. 무엇을 만들지 지정하는
00:28:10선택적 인자를 받을 수 있는데, 여기서는 대화 히스토리를 사용하겠습니다. 에이전트는 이미 알고 있으니까요.
00:28:17여기서 단계별 프로세스를 거칩니다. 기능 이해를 위해 코드베이스를 파고드는데, 이는
00:28:23나중의 PIV 루프에서 더 유용합니다. 많은 리서치를 수행하고 관련 문서를 가져와서,
00:28:28구현 단계에 들어가기 전 풍부한 컨텍스트를 확보합니다. 그리고 지금 보시는 것이
00:28:33바로 템플릿입니다. 문제 정의, 참고 자료 및 컨텍스트를 기술하고,
00:28:38여기 작업 목록이 포함된 구현 계획이 있습니다. 그리고 당연히
00:28:44테스트 전략도 있죠. 미리 검증 방법을 정의하는 것입니다. 이 계획을 만든 뒤에는
00:28:49당연히 검증을 거칩니다. “어플리케이션을 검증하는 정확한 단계”를 아주 구체적으로 확인하는 것이죠.
00:28:55저는 실제로 Vercel 에이전트 브라우저 CLI 스킬을 사용하고 있는데, 이에 대해 이전에 만든 영상 링크를
00:29:00걸어둘게요. 이를 통해 완전한 브라우저 자동화를 구축할 것입니다. 에이전트가 백엔드와 프론트엔드를
00:29:05실행하고, 데이터베이스 마이그레이션을 수행하며, 직접 링크 트리를 만들어보는 등
00:29:11사용자가 실제 어플리케이션을 사용하는 것과 똑같이 모든 기능이 작동하는지 확인할 것입니다.
00:29:17매우 흥미로운 부분이죠. 검증 과정이 매우 상세하기 때문에, 다시 우리에게 제어권이 넘어왔을 때
00:29:21구현 결과에 대해 매우 확신할 수 있습니다. 직접 검증을 하긴 하겠지만
00:29:26훨씬 수월해지겠죠. 자, 이제 계획이 완성되었습니다. 한번 살펴보죠.
00:29:31카메라 밖에서 검증을 좀 해봤는데, 잠시 후에 보여드릴게요. 보통은 이 과정에서
00:29:361단계에 대한 에이전트의 이해가 PRD 및 여러분의 의도와 일치하는지 확인하기 위해
00:29:42꽤 여러 번 반복 수정하게 될 것입니다. 모든 섹션을 꼼꼼히 확인하시길 권장합니다.
00:29:47여기 작업 목록이 포함된 구현 계획이 있습니다. 아주 상세한데, 좋은 현상입니다.
00:29:52하나의 기능에 집중할 때는 구체적일수록 좋으니까요. 제가 “검증 피라미드”라고 부르는
00:29:56검증 절차도 있습니다. 타입 체크, 린팅, 유닛 테스트 등이 포함되죠. 그리고
00:30:01E2E 테스트를 위해 에이전트가 수행해야 할 모든 사용자 여정(User journeys)을 아주 구체적으로 정했습니다.
00:30:05덕분에 결과물을 받았을 때 구현 상태를 신뢰할 수 있습니다. 사실 처음에는
00:30:10에이전트가 이 작업을 잘 못했습니다. 그래서 제가 후속 프롬프트를 통해
00:30:15구현 단계로 넘기기 전에 계획을 다듬고 정교화하는 과정을 보여드렸던 예시가 있었습니다.
00:30:20자, 또 다른 꿀팁 하나 알려드릴게요. 곧 구현 단계로 가겠지만 이건 정말 중요합니다.
00:30:24일반적으로 코딩 에이전트는 환경 변수 처리에 서툽니다. 실수를 많이 하죠.
00:30:29구현 전에 환경 변수를 설정해두지 않으면, 에이전트는 목(mock) 테스트만 수행하고
00:30:34실제로는 검증되지 않았는데도 다 됐다고 말할 것입니다. 정말 짜증 나는 상황이죠.
00:30:38그래서 저는 보통 계획 수립과 병행하여 .env.example 파일을 만들고
00:30:43에이전트에게 이를 확인하게 합니다. 그러면 에이전트는 제가 설정한 환경 변수들을 파악하게 되고,
00:30:48저 또한 환경 변수 설정을 마칩니다. 물론 데이터베이스 URL 같은 비밀 정보가 들어있는
00:30:53이 파일의 실제 내용을 보여드릴 수는 없지만요. 하지만 이미 설정을 마쳤기 때문에,
00:30:57이제 중단 없이 전체 구현을 밀어붙일 수 있습니다. 코드 작성뿐만 아니라
00:31:03데이터베이스 마이그레이션 실행, 백엔드 및 프론트엔드 구동, Vercel 에이전트 브라우저 CLI를 이용한
00:31:09테스트까지 한 번에 가능하죠. 제가 환경 변수를 설정하느라 흐름이 끊길 필요가 없습니다.
00:31:13이제 모든 준비가 완벽하게 끝났고 구현 계획도 만족스럽습니다. 자, 기억하세요.
00:31:19컨텍스트는 소중하니까 초기화해야 합니다. 완전히 새로운 대화창에서 execute 명령어를 사용하고,
00:31:23인자로 해당 계획 파일의 경로를 지정합니다. 이제 에이전트에게 필요한 컨텍스트는 이것뿐입니다.
00:31:29잠시 멈췄다가 전체 과정이 완료되면 돌아오겠습니다. 이제 코딩은
00:31:34전적으로 에이전트에게 맡깁니다. 우리가 계획에 들인 노력의 결실을 보는 것이죠.
00:31:40이 작업 덕분에 앞으로의 모든 PIV 루프는 놀라울 정도로 빠르게 진행될 것입니다. 좋습니다.
00:31:45구현이 완료되었습니다. 스크린샷을 보니 전체 E2E 테스트까지 수행했네요.
00:31:51에이전트가 이미 모든 처리를 끝냈기 때문에 결과물을 꽤 신뢰할 수 있지만, 여전히
00:31:56인간의 검증 과정은 중요합니다. “믿되 확인하라(Trust but verify)”는 원칙을 지키는 것이죠.
00:32:01코드 리뷰는 너무 세부적인 내용이라 지금 하지는 않겠지만,
00:32:06여러분이 기술적인 배경이 있다면 반드시 직접 수행하시길 권장합니다. 대신 저는 여러분과 함께
00:32:11어플리케이션을 직접 테스트해 보겠습니다. 카메라 밖에서 제가 미리 해둔 것은
00:32:16기본적인 인증이 작동하는지 확인하기 위해 계정을 생성한 것뿐입니다. 다른 건 아직 건드리지 않았어요.
00:32:21한번 보세요. 정말 멋지네요. 벌써 디자인이 꽤 괜찮습니다. 표시 이름을 설정할 수 있고,
00:32:26“멋진 AI 빌더” 같은 자기소개도 쓸 수 있습니다. 아바타 URL도 설정 가능하네요. Imgur에 이미지를 하나 올렸는데,
00:32:30네, 아주 보기 좋습니다. 링크도 추가해 볼게요. YouTube를 넣고,
00:32:35주소는 [youtube.com/atcolemedine](https://www.google.com/search?q=https://youtube.com/atcolemedine). 좋습니다. 링크를 하나 더 추가해서 LinkedIn도 넣어보죠.
00:32:39지금 제 LinkedIn URL이 기억나지 않으니 그냥 linkedin.com이라고 할게요. 상관없습니다.
00:32:43좋아요. 하나만 더 추가하죠. X입니다. x.com으로 하겠습니다. 멋지네요.
00:32:49순서를 드래그해서 바꿀 수도 있고, 그 결과가 옆에 즉시 반영됩니다. 에디터만 보거나
00:32:55미리보기를 조절할 수도 있습니다. 테마는 지금 그냥 하얀색이라 아주 예쁘지는 않지만,
00:32:59그건 아마 다음 단계에서 다룰 내용일 겁니다. 지금은 기초를 만드는 단계니까요.
00:33:08아직 완벽하지는 않지만 시작 단계치고는 정말 훌륭합니다. 그리고
00:33:11저장을 누르면... 네, API 엔드포인트를 로드하네요. 로컬 호스트에서 실행 중입니다.
00:33:18성공적으로 저장되었습니다. 새로고침을 해도 데이터가 그대로 남아있네요.
00:33:24정말 놀랍습니다. 아주 잘 작동하네요. 이제 프로젝트의 기본 토대가 마련되었으니
00:33:28커밋 메시지에 대해 아주 잠깐 이야기해 보겠습니다.
00:33:32/commit 이라는 명령어가 있는데, 아주 기본적인 기능입니다. 원하신다면 더 상세하게 만들 수 있지만,
00:33:37핵심은 에이전트에게 git 메시지 생성 지침을 주는 것입니다. 이 기록을 장기 기억으로 활용할 것이기 때문입니다.
00:33:42다이어그램으로 돌아가 보면, 이것 또한 황금률 중 하나입니다. “커밋 히스토리는 당신의 장기 기억이다.”
00:33:46메시지 형식을 표준화하고 재사용 가능한 /commit 명령어를 사용하면, 에이전트가
00:33:51prime 단계를 수행할 때 git log를 보고 최근에 무엇을 만들었는지 파악할 수 있습니다.
00:33:57이는 다음에 무엇을 할지, 그리고 따라야 할 패턴은 무엇인지 가이드를 제공합니다.
00:34:01이것이 커밋 메시지의 힘입니다. /commit 을 실행하겠습니다. 물론 직접 git commit을 할 수도 있고
00:34:06그게 아주 쉽지만, 명령어를 쓰면 일관된 메시지 형식을 유지할 수 있습니다.
00:34:11다시 다이어그램으로 돌아가서, 이것이 바로 황금률 중 하나입니다. 커밋 내역이 곧 여러분의 장기 기억입니다.
00:34:17메시지를 표준화하고 재사용을 위해 '/commit' 명령어를 사용하는 이유가 바로 여기에 있습니다. 그러면 우리 에이전트가
00:34:22프롬프트를 처리할 때 git 로그를 확인하여 최근에 무엇을 구축했는지 이력을 볼 수 있고,
00:34:28그 이력은 다음에 무엇을 할지, 그리고 어떤 패턴을 따라야 할지에 대한 가이드가 됩니다.
00:34:32이것이 바로 커밋 메시지의 힘입니다. 이제 '/commit'을 실행해 보겠습니다.
00:34:38직접 'git commit'을 실행해도 되지만, 이건 정말 간단하죠. 하지만 이 방식은
00:34:43항상 일관된 형식의 메시지를 보장해 줍니다. 지금은 제가 카메라 밖에서 이미 실행했기 때문에
00:34:48커밋할 내용이 없지만, 매번 구현을 마칠 때마다 이 작업을 해주는 것이 중요합니다.
00:34:53프로젝트의 기초가 마련된 후 다뤄야 할 또 다른 매우 중요한 사항은
00:34:58회귀 테스트(Regression Testing)를 위한 프레임워크를 구축하는 것입니다. 우리가
00:35:04앞으로 PIV 루프를 거치며 원하는 기능들을 계속해서 만들어 나갈 때,
00:35:09기존에 만들었던 것들이 망가지지 않도록 확인해야 합니다. 이 부분은
00:35:14직접 테스트 하네스를 구현하는 모든 전략과 함께 다른 영상에서 더 자세히 다룰 예정입니다.
00:35:19기본적으로 에이전트에게 가서 "지금까지 만든 건 좋아, 하지만"
00:35:25"네가 수행한 모든 E2E(End-to-End) 테스트 목록을 뽑아줘"라고 말한 뒤,
00:35:31"나중에 다른 기능을 만든 후에도 실행할 수 있게 명령어로 만들어줘"라고 요청하는 식입니다.
00:35:36그렇게 하면 이전에 구축한 모든 기능이 여전히 잘 작동하는지 확인할 수 있겠죠?
00:35:41지금 당장 너무 깊이 들어가지는 않겠습니다. 테스트 하네스를 설정하고 만드는 데는 시간이 꽤 걸리지만,
00:35:46이것이 애플리케이션을 계속 확장하면서도 안정성을 유지하는 방법입니다.
00:35:50다만 이를 생성하고 유지 관리하는 데는 지속적인 업데이트가 필요해 많은 노력이 듭니다.
00:35:55그래서 이런 과정을 대신 처리해 주는 아주 강력한 솔루션들이 시중에 나와 있습니다.
00:36:00그중 하나가 바로 'QA tech'입니다. 여기에는 코드베이스와 함께 진화하고 적응하는 AI 테스트 에이전트가 있습니다.
00:36:05새로운 기능이 추가될 때마다 에이전트가 테스트 케이스를 늘려가며,
00:36:11애플리케이션이 빌드 과정 내내 제대로 작동하는지 확인해 줍니다.
00:36:16얼마나 쉬운지 예를 보여드리겠습니다. 우선 QA tech에 접속하세요.
00:36:22시작해 볼 수 있는 무료 티어가 있습니다. 프로젝트를 생성하고,
00:36:26테스트하려는 URL을 붙여넣기만 하면 됩니다. 저는 이미 커밋을 하고
00:36:30GitHub에 푸시했기 때문에, 단 1분 만에 Vercel에 배포했습니다.
00:36:35Next.js로 빌드할 때 사이트를 무료로 호스팅하기 가장 쉬운 곳이죠. 제 프로젝트로 가서
00:36:40이 URL을 복사해 붙여넣겠습니다. 프로젝트를 생성하고 코드베이스를 분석하는 데
00:36:45시간이 조금 걸릴 겁니다. 그런 다음 "내 사이트에 적합한 테스트를 설정해 줘."
00:36:50"첫 3~5개의 테스트 케이스 생성을 도와줘"라고 말하면 됩니다. 이건 'bolt.new'나 'lovable'과 비슷하거나,
00:36:55프로젝트의 테스트 스위트 설정을 위해 원하는 무엇이든 프롬프트로 입력할 수 있습니다.
00:36:59이것이 그들이 권장하는 시작 방법입니다. 일단 전송해 보죠.
00:37:04정말 멋진 점은 AI가 인프라 관리 없이도 웹사이트를 실제로 크롤링하며 샅샅이 뒤진다는 것입니다.
00:37:08사이트를 분석해서 테스트 케이스를 도출해 냅니다. 분석이 끝나면 다시 돌아오겠습니다.
00:37:12실행 중간에 잠깐 보여드리면, 단 몇 분 만에 제 웹사이트 크롤링을 마쳤습니다.
00:37:16그다음 중요한 단계는 자동화 도구가 웹사이트에 로그인할 수 있는 방법이 필요하다는 것입니다.
00:37:21사용자 이름과 비밀번호를 입력하는 기능이 있고, 이를 안전하게 저장해 줍니다.
00:37:25여기에 테스트 계정을 하나 만들어 두었습니다. 저장해 보죠. 그러면
00:37:29그 계정으로 웹사이트에 접속해 우리가 테스트하려는 모든 사용자 여정을 깊이 있게 파악할 것입니다.
00:37:34자, 보시는 것처럼 여러 테스트 케이스가 생성되었습니다. 각 케이스를 클릭해서
00:37:38정확히 어떤 흐름으로 진행되었는지 확인할 수도 있습니다. 이제 모든 테스트 설정이 완료되었습니다.
00:37:43QA tech의 AI 테스트 에이전트는 코드베이스의 모든 부분을 계속 커버할 수 있도록
00:37:48시간이 지남에 따라 이 테스트 케이스들을 진화시킬 것입니다. 기능을 더 추가할수록
00:37:53정말 놀라운 도구가 됩니다. 물론 우리가 직접 이런 명령 시스템을 구축할 수도 있지만,
00:37:59이 모든 것을 알아서 처리해 주는 플랫폼을 사용하는 것이 훨씬 효율적입니다.
00:38:04내부적으로 에이전트와 대화하며 테스트 작업을 조율할 수도 있고,
00:38:09모든 것에 대해 회귀 테스트가 제대로 이루어지는지 확인할 수 있습니다.
00:38:14나중에 무언가 망가졌을 때, 여기에 와서 "지금 앱에 버그가 있으니
00:38:19실패해야 하는 테스트를 만들어줘. 내가 문제를 해결하면 테스트가
00:38:24통과하게 될 거야"라고 말할 수 있죠. 이것이 제가 가진 마지막 황금률인
00:38:28"시스템 진화 마인드셋(System Evolution Mindset)"으로 이어집니다.
00:38:33코드베이스에서 버그를 발견했을 때 단순히 버그만 고치는 것이 아니라,
00:38:40같은 일이 반복되지 않도록 AI 레이어에서 무엇을 수정할 수 있을지 고민하는 것이 중요합니다.
00:38:46가령 스타일 가이드나 규칙을 더 구체화하거나, 새로운 '온디맨드 컨텍스트'를 만들 수도 있겠죠.
00:38:51혹은 명령어와 워크플로우에 더 많은 E2E 테스트를 배치할 수도 있습니다.
00:38:57해당 이슈를 다시 겪지 않기 위해 필요한 모든 조치를 취하는 것이죠. 그다음 QA tech나
00:39:02자체 명령어 시스템을 통해 테스트를 추가하여 코드베이스에서 같은 문제가 생기지 않도록 확신을 갖습니다.
00:39:06비록 시간이 걸리더라도 이 방식이 강력한 이유는, 코딩 에이전트를 더 신뢰할 수 있고 재현 가능하게 만들며
00:39:12코드베이스와 함께 에이전트를 진화시킬 수 있기 때문입니다. 즉, 우리는 세 가지를 병행하고 있는 셈입니다.
00:39:16코드베이스를 구축하면서 동시에 테스트 베이스와 AI 레이어를 함께 진화시키는 것이죠.
00:39:21그리고 이 과정은 시간이 지남에 따라 엄청난 복리 효과를 냅니다. 'Cloud Code'로 돌아가서
00:39:26간단한 예를 보여드리겠습니다. 제가 카메라 밖에서 한 번 더 반복 작업하며 진행한 것 중 하나가
00:39:32사이트의 스타일을 다듬는 일이었습니다. 영상 시작 부분을 보시면 아시겠지만
00:39:37사이트가 정확히 어떻게 보였으면 좋겠는지 스타일 이야기를 깜빡했거든요. 그래서 Cloud Code가
00:39:43나름대로 가정을 하고 만들었는데, 그렇게 좋아 보이지 않았습니다. 그래서 수정이 필요했죠.
00:39:47여기서 제가 할 수 있는 건, "처음에 구현한 프론트엔드 스타일이 맘에 들지 않았어."
00:39:51"현재 AI 레이어의 규칙과 온디맨드 컨텍스트에는 스타일 가이드라인이 부족해."
00:39:56"그러니 '메타 추론'을 좀 해줘. 당장 아무것도 바꾸지는 말고,
00:40:01우리의 규칙이나 컨텍스트에 무엇을 추가하거나 업데이트해야 나중에 분석 페이지 등을 만들 때
00:40:06더 일관된 스타일을 유지할 수 있을지 같이 생각해보자"라고 요청하는 것입니다.
00:40:10여기서 중요한 점은 "아직 아무것도 바꾸지 말라"고 말한 것입니다.
00:40:15코드베이스 수정은 에이전트에게 최대한 위임하고 싶지만, AI 레이어를 수정할 때는
00:40:20제가 훨씬 더 세밀하게 통제하고 싶기 때문입니다. 그래서 에이전트와 함께 추론을 하되,
00:40:25작고 집중적인 변경 사항은 직접 수정하는 편을 선호합니다. 에이전트는 지금
00:40:29reference 폴더에 'style.md' 파일을 만들라고 제안하네요. 세 번째 온디맨드 컨텍스트가 생기는 셈입니다.
00:40:34이것은 'components.md'와 짝을 이룰 것입니다. 컴포넌트 파일이 배치를 다룬다면,
00:40:39'styles.md'는 어떻게 작동하는지, Tailwind CSS나 ShadCN을 어떻게 써야 하는지 다루겠죠.
00:40:44전체 구현 과정과 모든 수정을 다 보여드리지는 않겠지만, 제가 드리고 싶은 핵심은
00:40:50코드에 버그가 있거나 우리 의도와 어긋나는 상황이 발생했을 때가 바로
00:40:54AI 레이어를 진화시킬 기회라는 것입니다. 그렇게 함으로써 프로젝트를 진행할수록
00:40:58우리의 코딩 에이전트와 더 완벽한 호흡을 맞출 수 있게 됩니다.
00:41:03그리고 이 과정이야말로 전체 프로세스에서 가장 레버리지가 높은 부분입니다. 최고의 팁을 마지막에 아껴두었죠.
00:41:06이제 다 끝났습니다. 새로운 프로젝트를 시작할 때 코딩 에이전트로부터
00:41:11신뢰할 수 있고 재현 가능한 결과를 얻는 정말 간단한 프로세스입니다.
00:41:16시스템을 진화시킨 후에는 다시 처음으로 돌아가서 더 많은 PIV 루프를 돌며
00:41:20PRD의 모든 단계를 구축하고 기능을 추가하며 MVP(최소 기능 제품)를 완성해 나가는 것이죠.
00:41:26그다음은 제가 올릴 다음 영상 중 하나인 '브라운필드(Brownfield) 개발' 단계로 이어집니다.
00:41:32이 내용이 마음에 드셨고, 제가 가진 명령어와 규칙 리소스 라이브러리를 더 깊이 파고들고 싶다면,
00:41:35또 시스템 진화가 실제로 어떻게 이루어지는지 자세히 보고 싶다면
00:41:40Dynamics 커뮤니티의 '에이전틱 코딩 코스'를 꼭 확인해 보세요. 설명란과 고정 댓글에
00:41:45링크를 남겨두겠습니다. 제가 준비한 내용은 여기까지입니다.
00:41:49영상이 도움이 되셨고 앞으로 나올 에이전틱 코딩과 브라운필드 개발 영상이 기대된다면,
00:41:54좋아요와 구독 부탁드립니다. 그럼 저는
00:41:59다음 영상에서 뵙겠습니다.
00:42:04Dynamics 커뮤니티에 있는 제 에이전트 코딩 강의를 꼭 확인해 보시기 바랍니다.
00:42:08영상 설명란과 고정 댓글에 링크를 남겨 두겠습니다.
00:42:13제가 준비한 내용은 여기까지입니다. 이번 영상이 도움이 되셨고,
00:42:17앞으로 올라올 에이전트 코딩이나 기존 프로젝트 개발 영상이 기대되신다면 좋아요와 구독 부탁드립니다.
00:42:22그럼 다음 영상에서 뵙겠습니다.