00:00:00AI 코딩 프레임워크가 계속 늘어나고 있으며, 저마다 에이전트를 활용해
00:00:04개발하는 가장 좋은 방법이라고 주장합니다.
00:00:05하지만 에이전트로 개발하는 최선의 방법은 전적으로 어떤 프레임워크를 고르느냐에 달려 있지 않습니다.
00:00:09사람들이 간과하는 다른 요소들이 있으며, 프레임워크가 프로젝트와 맞지 않을 때
00:00:14좌절감을 느끼곤 하죠.
00:00:15하지만 그것은 프레임워크의 문제가 아니라 선택의 문제입니다.
00:00:18각 프레임워크는 설계된 목적에 따라 잘 작동하며, 모든 상황에
00:00:22다 들어맞는 정답은 없습니다.
00:00:23저희 팀은 이전에 채널에서 AI 코딩 프레임워크를 다룬 적이 있지만, 최근에
00:00:28많은 관심을 끌고 있는 새로운 프레임워크를 발견했습니다.
00:00:31이 영상을 만드는 이유는 단순히 기존 것을 버리고 갈아타야 할
00:00:35또 다른 '최고의' 프레임워크이기 때문이 아닙니다.
00:00:37직접 테스트해 보니 확실히 차별점이 있었고, 기존 프레임워크들이
00:00:41해결하지 못한 사례들에 적합했기 때문입니다.
00:00:43이전 영상에서 BMAD나 Superpowers 같은 여러 프레임워크를 다뤘었죠.
00:00:48잘못된 선택은 오버엔지니어링이나 준비 부족으로 이어집니다.
00:00:51오늘은 GSD라는 프레임워크를 살펴볼 텐데, 왜 이름이 'Get Shit Done'의 약자인지
00:00:56이해하시게 될 겁니다.
00:00:57이 영상이 끝날 때쯤이면 어떤 프레임워크를 어디에 써야 할지 알게 되실 겁니다. 먼저
00:01:00GSD부터 시작하겠습니다.
00:01:02GSD는 무엇을 만들지 확실하지 않고, 요구 사항이 바뀔 수 있어
00:01:06모든 것을 미리 계획하고 싶지 않을 때 사용합니다.
00:01:09이는 무엇을 만들지 아예 모른다는 뜻이 아닙니다.
00:01:11만들고자 하는 제품의 각 단계에서 많은 실험이 필요하다는 의미입니다.
00:01:15실험적인 프로젝트를 위해 MVP를 최대한 빨리
00:01:19구축하고 싶을 때 매우 유용합니다.
00:01:20GSD도 대략적인 범위를 묻기는 하지만, BMAD 방식과는 달리
00:01:25사용자를 틀에 가두지 않습니다.
00:01:26초기 범위를 바탕으로 각 구현 단계를 차근차근 계획합니다.
00:01:30나중 단계들이 시스템에 의해 아주 세부적으로 미리 계획되지 않기 때문에,
00:01:34후반 작업에서도 자유로울 수 있다는 뜻이죠.
00:01:35따라서 이전에 없던 맞춤형 솔루션을 만들고 있다면,
00:01:39GSD를 사용하는 것이 더 좋습니다.
00:01:41예를 들어 Cluely 같은 화면 기반 인터뷰 어시스턴트를 만든다고 해봅시다.
00:01:45사용자 경험이 어떠해야 할지, 혹은 화면 공유 플랫폼들이
00:01:50이를 감지하지 못하게 하는 방법 등 해결해야 할 일이 많을 겁니다.
00:01:54많은 것들이 실험을 거쳐야 하며, 계획 단계 전에는 판단할 수 없는 것들입니다.
00:01:59반면 BMAD는 정반대의 접근 방식을 취합니다.
00:02:02구현에 들어가기 전, 각 단계에 대해 철저한 문서를 작성하는
00:02:06단계별 프레임워크입니다.
00:02:07시작할 때 무엇을 만들지 확신이 있어야 하며, 그렇다고
00:02:11일 처리가 엉성한 것도 아닙니다.
00:02:12이 프레임워크에는 별도의 리서치 부서 모듈이 있는데, 개발자가
00:02:17비즈니스 분석가나 디자인 씽커 같은 다양한 역할의 문맥을 넣어두어
00:02:21제품을 모든 각도에서 검토하도록 보장합니다.
00:02:25하지만 이는 모두 사전에 로드된 것이며, 이를 바탕으로 PRD와 설계 문서를 만들고
00:02:30거기서 나온 세분화된 작업들을 구현 팀이
00:02:34그대로 따라가기만 하면 됩니다.
00:02:35저희가 BMAD 시스템을 리뷰했을 때, 그 견고함을 칭찬한 바 있습니다.
00:02:39프롬프트 내에 시스템이 매우 잘 구축되어 있어 에이전트가
00:02:43작업에서 이탈하지 않도록 해줍니다.
00:02:44하지만 장기간 사용해 본 결과, 실제로 요구 사항을 변경해야 할 때
00:02:48시스템이 불안정해지는 것을 확인했습니다. 가장 뛰어난 모델조차
00:02:52요구 사항 변경 시 작은 세부 사항을 놓치기 때문입니다.
00:02:56또 다른 불만은 실제 구현이 시작되기 전까지 계획하는 데
00:03:00너무 많은 시간이 걸린다는 것인데, 사실 그런 종류의 프로젝트에
00:03:04쓰면 안 되는 도구이기 때문입니다.
00:03:05요구 사항이 확실하고 허점 없는 시스템 구축을 원할 때
00:03:09사용해야 합니다. 모든 명세가 촘촘하게 연결되어 있기 때문이죠.
00:03:14혹은 고객을 위한 맞춤형 CRM 솔루션이나 나만의 커뮤니티 플랫폼 같은
00:03:19전형적인 시스템을 구축할 때 적합합니다.
00:03:21이제 Superpowers는 TDD 기반이며, 핵심 이데올로기는
00:03:25무엇을 만들지 정확히 아는 것입니다.
00:03:26TDD는 예외 상황(edge case)의 실수가 치명적일 때 중요합니다. 여기서 비용이란
00:03:30단순한 Next.js 앱의 Stripe 연동 정도가 아니라,
00:03:34AI 에이전트가 사용자를 대신해 행동하고, 한 번의 잘못된 작업이
00:03:39취소 불가능하며 큰 손실을 초래하는 에이전틱 플랫폼 같은 경우입니다.
00:03:41사용성 측면에서는 GSD와 비슷하게 프로젝트의 개요만 가지고
00:03:46기능별로 계획을 세웁니다.
00:03:49하지만 테스트가 먼저 생성되기 때문에 다양한 실험을 할 여지가 적고,
00:03:53사전 계획이 미리 완료된 프로젝트에는 이상적이지 않습니다.
00:03:57하지만 프로젝트가 두 영역에 모두 걸쳐 있다면,
00:04:02GSD로 주요 기능을 완성한 버전을 먼저 구현한 뒤,
00:04:06나머지 부분을 Superpowers를 통해 이어 나갈 수도 있습니다.
00:04:10저희 채널에 Superpowers와 BMAD 방식에 대한 별도 영상들이 있으니,
00:04:15더 자세히 알고 싶으시면 설명란의 링크를 확인해 보세요.
00:04:19GSD는 하위 에이전트를 사용하고 격리된 작업에 대해 별도 프로세스를 생성하여
00:04:23컨텍스트 부패(context rot)를 방지하도록 설계되었습니다. 메인 에이전트의 컨텍스트를 깨끗하게 유지해
00:04:28탈선하지 않고 본질에 집중할 수 있게 합니다.
00:04:31대부분의 AI 코딩 에이전트가 이제 하위 에이전트를 지원하므로,
00:04:35여기에 Claude Code를 사용하든 아니든 상관없습니다.
00:04:37그런데 Claude도 최근에 업데이트되었죠. 100만 토큰의 컨텍스트 창을 가진
00:04:42새로운 Opus 4.6이 나왔습니다.
00:04:43그래서 저희 채널에서 가르쳤던 컨텍스트를 능동적으로 관리하는
00:04:46기법들 중 상당수가 이제는 예전만큼 중요하지 않게 되었습니다.
00:04:49설치하려면 명령어를 복사해서 작업 중인
00:04:53프로젝트 폴더에 붙여넣으면 됩니다.
00:04:54그런 다음 어떤 에이전트에 설치할지 선택하세요.
00:04:57제 경우에는 Claude였으므로 그것으로 설치했습니다.
00:04:59다음으로 설치 범위를 선택해야 합니다.
00:05:02저는 프로젝트별로 다른 프레임워크를 쓸 수 있도록
00:05:06설정을 해당 프로젝트 내로 제한하는 '프로젝트 레벨'을 선호합니다.
00:05:10저희는 Next.js로 개발 중이었으므로 새로 초기화한 프로젝트에 설치했습니다.
00:05:15설치가 완료되면 .claude 폴더 안에 에이전트, 명령어, 훅의 형태로
00:05:19GSD 프레임워크가 나타날 것입니다.
00:05:21Claude를 사용하지 않는 경우, 프로젝트 루트의 .agent 폴더에 저장됩니다.
00:05:26특정 작업별로 여러 에이전트가 있지만, 일반적인 마크다운 기반
00:05:30프롬프트와 달리 모든 것이 의도적으로 XML 형식으로 구조화되어 있습니다.
00:05:34Claude 모델은 XML 형식의 지침을 더 잘 이해하는 것으로 알려져 있어
00:05:39구조 파악이 용이하며, 이는 사용 중인 에이전트에 맞춘
00:05:43성능 최적화의 일환입니다.
00:05:44계속하기 전에, 이번 영상의 후원사인 Genspark를 소개합니다.
00:05:48대부분의 사람들은 현재 ChatGPT, Claude 및 다양한 미디어 도구에 대해
00:05:52개별 요금을 지불하며 여러 AI 구독을 관리하느라 힘들어합니다.
00:05:55Genspark는 모든 것을 하나의 구독으로 통합하여 단 11개월 만에
00:06:02연간 반복 매출(ARR) 2억 달러를 달성한 올인원 AI 작업 공간입니다.
00:06:03어떤 작업이든 최적의 모델을 선택하는 슈퍼 에이전트 시스템을 사용합니다.
00:06:07AI 슬라이드 제작, AI 시트 자동화부터 AI 미디어 생성은 물론,
00:06:12"call for me" 기능을 통해 실제 전화를 거는 것까지 전체 워크플로우를 처리합니다.
00:06:16조사한 내용을 AI 포드로 변환하여 이동 중에 들을 수도 있죠.
00:06:20또한 Speakly를 쓰면 15분 분량의 녹음을 즉시 3,000자의 완벽한 텍스트로 바꿔줍니다.
00:06:26가장 놀라운 점은 무엇일까요?
00:06:27Genspark는 2026년 내내 무제한 AI 채팅 및 이미지 기능을 제공합니다.
00:06:31Nano Banana 2, GPT-Image, Flux, Seedream, Gemini 3.1 Pro, GPT 5.2, Claude Opus 4.6 등
00:06:40최신 모델들을 모두 무제한으로 이용할 수 있습니다.
00:06:43고정 댓글의 링크를 눌러 Genspark와 함께 시작해 보세요.
00:06:46GSD를 사용하려면 먼저 이 'new project' 명령어를 사용합니다.
00:06:50명령어를 실행하면 에이전트가 초기화 프롬프트에 따라 작동하며
00:06:54코드베이스 탐색부터 시작합니다.
00:06:56이미 Next.js 앱을 초기화해 두었기 때문에 기존 코드가 있음을 감지하고
00:07:01기존 코드베이스를 먼저 훑어볼지 물어봅니다.
00:07:04저희는 시간 낭비를 피하기 위해 매핑 단계를 건너뛰라고 했습니다.
00:07:06기존 프로젝트에서 작업 중이라면 코드베이스 매핑을 먼저 시키는 게 좋지만,
00:07:11빈 템플릿만 들어있었기에 저는 생략했습니다.
00:07:14그 후 작업하고 싶은 앱 아이디어를 말해달라고 요청할 것입니다.
00:07:18그러고 나면 타겟 대상, 기능, 프로젝트 범위 등에 관해
00:07:22많은 질문을 던집니다.
00:07:24하지만 GSD의 질의응답 세션은 Superpowers와 눈에 띄게 다릅니다.
00:07:29Superpowers는 이 단계에서 사용자로부터 예외 케이스를 뽑아내려고 합니다.
00:07:32GSD는 그렇지 않고, 어떻게 망가질지 테스트하기보다는
00:07:38무엇을 만들지에 더 집중합니다.
00:07:39충분한 정보가 모이면 .planning 폴더 안에 project.md 파일을 생성하는데,
00:07:43여기에는 질문을 통해 도출된 설명, 범위 밖 항목, 컨텍스트 제약 조건,
00:07:48그리고 핵심 결정 사항들이 담겨 있습니다.
00:07:50여기서 컨텍스트 부패 방지 기능이 실제로 발휘됩니다.
00:07:54에이전트들이 방대한 문서에 파묻혀 목표를 잃지 않도록
00:07:59project.md를 의도적으로 짧고 집중도 있게 유지합니다.
00:08:01모든 작업은 git으로 추적하지만, 단순히 git commit을 사용하지는 않습니다.
00:08:05백그라운드에서 스크립트를 실행해 커밋 전 점검을 수행하며,
00:08:10모든 것이 기준에 부합하는지 확인한 후 실제로 git 커밋을 진행합니다.
00:08:12계획이 끝나면 GSD는 리서치 단계로 넘어갑니다.
00:08:16앱의 다양한 측면을 조사하는 여러 에이전트를 동시에 생성하며,”
00:08:20이들은 모두 백그라운드에서 실행됩니다.
00:08:21리서치가 끝나면 리서치 종합 에이전트가 투입됩니다.
00:08:24이 에이전트들은 작업에 적합한 모델을 사용하도록 튜닝되어 있어,
00:08:29종합 에이전트는 무거운 Opus 대신 Sonnet 모델을 사용합니다.
00:08:32GSD는 하위 에이전트의 업무 강도에 맞춰 적절한 모델을 매핑하는
00:08:36참조 체계를 갖추고 있어 불필요한 리소스 낭비를 막습니다.
00:08:39리서치 결과를 요약하고 잠재적 문제점, 즉 장기적으로 작업을 방해할 수 있는
00:08:44주의 사항들도 짚어줍니다.
00:08:46리서치 종합이 끝나면 요구 사항 단계가 시작됩니다.
00:08:49MVP에 대한 타겟 질문을 던져 버전 1에 정말 필수적인
00:08:55기능이 무엇인지 식별합니다.
00:08:56GSD는 빠른 전달에 집중하므로 V1에 꼭 필요한 것만 담기도록 합니다.
00:09:01사용자가 MVP를 확인하면 로드맵 구조를 생성하고,
00:09:05사용자가 승인하면 프로젝트 초기화가 완료됩니다.
00:09:09저희 콘텐츠가 마음에 드신다면 하이프(hype) 버튼을 눌러주세요.
00:09:14더 좋은 콘텐츠를 만들고 더 많은 분께 다가가는 데 큰 힘이 됩니다.
00:09:17이제 초기화 단계가 끝났으니 다음 단계는 계획을 구현하는 것입니다.
00:09:22이전 단계에서 요구 사항을 바탕으로 프로젝트를 4단계로 나누었습니다.
00:09:26작업 방식은 두 가지인데, 논의를 생략하거나 논의를 거쳐 진행할 수 있습니다.
00:09:31이 프레임워크에서 논의란 에이전트와의 질의응답 세션을 의미하며,
00:09:35이를 통해 에이전트가 계획을 제대로 이해했는지 확인합니다.
00:09:37저희는 요구 사항을 최대한 명확히 하기 위해 먼저 논의하는 쪽을 택했지만,
00:09:41이전 질문 세션만으로 충분하다고 생각되면
00:09:45논의를 생략할 수도 있습니다.
00:09:47논의가 끝나면 .planning 폴더 내 phases 폴더에
00:09:52context.md 파일을 생성합니다.
00:09:54이 파일에는 논의한 모든 세부 사항이 포함되어 있으며,
00:09:58에이전트와 방금 대화한 단계를 매핑합니다.
00:09:59GSD의 철학에 따라 이 파일 역시 간결하게 작성되어,
00:10:04Claude가 본질적인 부분에 집중할 수 있도록 돕습니다.
00:10:06다음으로 1단계 계획을 시작합니다.
00:10:08계획 수립은 방금 생성한 context.md 파일을 기반으로 리서치부터 시작하며,
00:10:13Sonnet 모델을 사용하는 전담 리서치 에이전트가 다양한 측면을 탐색합니다.
00:10:17저희는 이 에이전트가 Context 7을 쓰거나 문서를 제대로 찾아볼 줄 알았습니다.
00:10:21하지만 그러지 말았어야 할 검색 키워드에 2025년을 넣어
00:10:27웹 검색을 활용하고 있었습니다.
00:10:28Context 7 MCP를 연결했더라면 리서치가 더 근거 있게
00:10:32제어되었을 텐데 말이죠.
00:10:33그러니 사용하실 때는 더 나은 접지(grounding)를 위해 해당 MCP를 꼭 연결하세요.
00:10:37에이전트는 research.md 파일을 만들어 모든 조사 내용을 기록하고,
00:10:42정보원이 얼마나 신뢰할 수 있는지 보여주는 신뢰도 수준도 표시했습니다.
00:10:46리서치 후에 계획이 생성되었습니다.
00:10:48이 계획에는 각 단계의 의존성과 모든 요구 사항이
00:10:52고유 ID와 함께 상세히 나열되어 있습니다.
00:10:53그런데 GSD의 차별점은 여기서 드러납니다. 다른 도구들처럼
00:10:57계획을 한 방향으로만 쓰는 게 아니라, 여러 차원에서 교차 검증하여
00:11:02계획이 실행 가능한지, 목표에 부합하는지 확인합니다.
00:11:06전담 계획 에이전트와 계획 검증 에이전트를 사용하는데,
00:11:11계획 에이전트가 계획을 짜면 검증 에이전트가 계속 확인하며 경고를 보냅니다.
00:11:14즉, 저희가 수동으로 제어할 필요 없이 시스템이 스스로
00:11:19대립적 계획(adversarial planning)을 수행하는 것이죠.
00:11:20계획이 최종 확정되고 모든 단계가 통과되면, 이를 커밋하고
00:11:24계획을 두 개의 웨이브(wave)로 나눕니다.
00:11:25실제로는 필요한 만큼 웨이브를 나누고 독립적인 작업들은 병렬화하여,
00:11:30하위 에이전트들이 동시에 처리할 수 있게 합니다.
00:11:33전담 에이전트를 사용해 수립된 계획에 따라
00:11:37프로젝트 웨이브 구현을 시작했습니다.
00:11:38구현이 끝나면 내부적으로 Playwright 테스트를 통해 체크포인트를 검증합니다.
00:11:43스크립트를 만들고 사용 후 삭제해 폴더를 정리하는 등
00:11:47수많은 자동화 작업을 물밑에서 수행합니다.
00:11:49그런 다음 구축된 내용의 요약을 제공하고
00:11:53직접 검증할 수 있는 지침을 안내해 주었습니다.
00:11:54첫 번째 반복(iteration)에서는 앱의 실제 모습을 보여주기 위해
00:11:58초기 요소들만 보이는 플레이스홀더 상태의 앱을 만듭니다.
00:12:01이후 반복 작업을 통해 앱의 각 측면을 하나씩 구축해 나가며,
00:12:05결국 사이클 끝에 완성된 앱을 얻게 됩니다.
00:12:06전체 반복 작업에 138,000 토큰이 사용되었는데, 100만 토큰의
00:12:12컨텍스트 창을 고려하면 사실 그리 많지 않은 양입니다.
00:12:13하지만 200,000 토큰 창을 가진 에이전트라면 압축할 때가 되었다고 신호를 보낼 겁니다.
00:12:18단계별 문서화에 의존하기 때문에 컨텍스트를 비우더라도
00:12:23에이전트들은 어디서부터 시작해야 할지 알고 있습니다.
00:12:25작업을 승인하자 여러 테스트를 실행하고 웨이브 2도 완료로 표시했습니다.
00:12:29그 후 GSD 검증 에이전트를 다시 가동해 구현 내용이
00:12:34처음 목표와 일치하는지 교차 확인했습니다.
00:12:36검증이 끝나면 검증 결과와 함께 1단계를 완료로 처리하고
00:12:41다음 단계로 넘어갈지 물어봅니다.
00:12:43모든 단계를 거쳐 앱을 실행해 보니, 이전에 플레이스홀더였던
00:12:47기능들이 모두 의도한 대로 정상 작동했습니다.
00:12:49GSD는 여러 기능을 갖춘 대규모 앱 개발에는 적합하지만,
00:12:54더 간단하고 무거운 처리가 필요 없는 앱에는 과할 수 있습니다.
00:12:59단순한 앱이라면 Claude나 다른 에이전트만으로도 충분하며
00:13:03이런 철저한 계획까지는 필요 없습니다.
00:13:04하지만 계획 단계에 너무 많은 힘을 들이지 않으면서도
00:13:08잘 계획된 통제된 실행을 원한다면 반드시 GSD를 고려해 보세요.
00:13:11지금까지 한 프레임워크를 살펴봤지만, 기존 도구가 맞지 않아
00:13:16자신만의 도구를 만들어야 할 때도 종종 있습니다.
00:13:18그러기 위해서는 직접 구축하기 전에 특정 원칙들을 알아야 합니다.
00:13:22더 나은 워크플로우를 만드는 데 도움이 될 원칙들을 이전 영상에서 다뤘습니다.
00:13:26종료 화면에 해당 영상이 뜰 테니 검색할 필요 없이
00:13:30바로 클릭해서 보실 수 있습니다.
00:13:31이것으로 이번 영상을 마칩니다.
00:13:33저희 채널을 후원하고 계속해서 이런 영상을 만들 수 있도록 돕고 싶다면
00:13:37AI Labs Pro에 가입해 주시기 바랍니다.
00:13:38언제나 시청해 주셔서 감사하며, 다음 영상에서 뵙겠습니다.