Ralph 루프는 잊으세요: Claude Code를 위한 새로운 GSD 프레임워크

EEric Tech
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00클로드 코드를 사용해 웹 애플리케이션을 빌드하고 계신다면, GSD를 꼭 확인해 보셔야 합니다.
00:00:04GSD는 오픈 소스 기반의 사양 중심 개발(Spec-driven development) 프레임워크로,
00:00:08다양한 하위 에이전트들을 조율하여 사양 중심 개발 프레임워크에 따라 프로젝트를 완수하는 데 특화되어 있습니다.
00:00:12기존에 저희 채널에서 다루었던 전통적인 사양 중심 개발 프레임워크와는 다릅니다.
00:00:15Beemap Method, SpecKits, Taskmaster 등 기존의 프레임워크들은
00:00:20모든 작업을 하나의 단일 컨텍스트 창에서 처리해야 한다는 엄격한 규칙을 따라야 했습니다.
00:00:24예를 들어 기획, 조사, 개발, 검증 등의 모든 과정이
00:00:29단 하나의 컨텍스트 창 안에서 이루어져야 했죠. 하지만 여기에는 아주 중요한 문제가 따릅니다.
00:00:33바로 컨텍스트 포화(Context bloat) 문제인데요, 단일 컨텍스트 창에서 토큰 소비가 많아질수록 정확도는 떨어지게 됩니다.
00:00:38이에 대한 해결책은 하위 에이전트들을 활용하는 것입니다. 기획, 조사, 개발, 검증 작업을
00:00:42각각의 하위 에이전트에게 위임하는 방식이죠.
00:00:47이렇게 하면 각 에이전트는 자신만의 깨끗한 컨텍스트를 가지고 작업을 하나씩 완수하게 됩니다.
00:00:51GSD는 이러한 하위 에이전트들을 조율하는 오케스트레이터 역할을 하며 사양 중심 개발을 수행합니다.
00:00:55거친 아이디어를 실제 프로덕션 수준의 애플리케이션으로 단계별로 이끌어주는 것이죠.
00:01:00물론 토큰은 더 많이 소비되겠지만,
00:01:04모든 것을 하나의 컨텍스트에서 처리할 때보다 얻을 수 있는 정확도는 훨씬 더 높습니다.
00:01:07그래서 이번 영상에서는 여러분의 클로드 코드에 GSD 프레임워크를 설정하는 정확한 방법을 보여드리려 합니다.
00:01:11아이디어를 가져와서 기존 애플리케이션이나 새 프로젝트 위에 빌드하는 과정,
00:01:15그리고 조사 에이전트와 기획 에이전트를 활용해
00:01:19구현하고자 하는 아이디어를 구체화하는 법을 보여드릴 것입니다. 아이디어가 구체화되면
00:01:23본격적인 구현 단계로 넘어갑니다. 여기에는 병렬로 실행되는 실행 에이전트들이
00:01:27동시에 작업을 수행하게 됩니다.
00:01:32각 에이전트는 독립된 컨텍스트 창을 가지며 완료된 작업마다 커밋을 남깁니다.
00:01:37또한 작업이 완료될 때마다 별도의 에이전트를 생성하여
00:01:41작업 결과가 목표에 부합하는지 검증합니다. 가장 중요한 점은, 한 단계의 작업이 끝나면
00:01:45논의, 기획, 실행, 검증의 각 단계를 단계별로, 루프별로 어떻게 반복하는지 보여드릴 것이라는 점입니다.
00:01:49이를 통해 사람이 개입하지 않고도 전체 마일스톤을 완전히 자율적으로 완수할 수 있습니다.
00:01:55이것이 오늘 영상에서 다룰 주요 내용입니다. 관심 있으시다면 바로 시작해 보죠.
00:02:00시작하기 전에, 처음 오신 분들을 위해 짧게 제 소개를 하겠습니다.
00:02:04제 이름은 에릭입니다. 아마존, AWS, 마이크로소프트와 같은 기업에서 시니어 소프트웨어 엔지니어로 다년간 근무했습니다.
00:02:09AI 코딩부터 자동화, Web3, 커리어 개발까지
00:02:15제가 배우고 경험한 모든 것을 공유하기 위해 이 유튜브 채널을 시작했습니다.
00:02:22모두 실무적인 튜토리얼로 구성했으니 실력을 쌓을 준비가 되셨다면
00:02:27제 채널을 확인해 보시고 구독 버튼도 눌러주세요. 이제 다시 본론으로 돌아가겠습니다.
00:02:32가장 먼저 할 일은 GSD 리포지토리로 이동하는 것입니다.
00:02:36여기 보시면 로컬 머신에 설치하는 방법이 정확히 나와 있습니다. 이 명령어를 복사한 뒤,
00:02:40현재 진행 중인 프로젝트의 터미널로 돌아가겠습니다.
00:02:44그리고 이 명령어를 입력해서 로컬 프로젝트에 설치하겠습니다.
00:02:49설치를 진행하고요, 여기 보시면
00:02:53클로드 코드를 쓸지, 오픈 코드를 쓸지, 혹은 둘 다 쓸지 선택해야 합니다. 시연을 위해 클로드 코드만 선택하겠습니다.
00:02:57다음으로 어디에 설치할지 묻는데,
00:03:02모든 프로젝트에서 사용할 수 있도록 글로벌하게 설치하도록 하겠습니다.
00:03:07선택을 마치면, GSD에는 모델명, 현재 작업,
00:03:12컨텍스트 창 사용량을 보여주는 상태 표시줄(status line)이 포함되어 있다고 나옵니다.
00:03:17기존 것을 유지할지 아니면 GSD 상태 표시줄로 교체할지 묻는군요. 아직 본 적이 없으니
00:03:222번을 선택해서 GSD 상태 표시줄이 어떻게 생겼는지 확인해 보겠습니다.
00:03:26클로드 코드 세션을 열어보겠습니다. 바로 이 부분이
00:03:31현재 GSD용 상태 표시줄입니다. 물론 이 버전이 마음에 들지 않고
00:03:37제 방식을 쓰고 싶다면, 상태 표시줄을 커스터마이징하는 방법을 설명한 다른 영상을 참고해 보세요.
00:03:41하지만 일단은 GSD 기본 상태 표시줄을 사용하셔도 무방합니다.
00:03:46GSD 설치가 완료되면 간단히 'gsd'라고 입력합니다.
00:03:49클로드 코드 터미널 안에 모든 커스텀 명령어들이 들어와 있는 것을 볼 수 있습니다.
00:03:54설치를 마쳤으니 다음 단계는 프로젝트 초기화입니다.
00:03:58새 프로젝트를 시작한다면 'gsd new project'를 하면 되지만,
00:04:02이미 기존 프로젝트가 있다면 먼저 이 명령어를 실행해야 합니다.
00:04:06그러면 여러 하위 에이전트들이 실행되어 스택, 아키텍처, 컨벤션,
00:04:10주의 사항 등을 분석합니다. 그 후에 이 명령어를 실행하면 전체 코드베이스를 파악하고
00:04:15추가하려는 기능에 대해 질문을 던지며 애플리케이션 설계를 도와줍니다.
00:04:20먼저 전체 코드베이스를 매핑하는 명령어부터 실행하겠습니다.
00:04:24보시다시피 4개의 병렬 코드베이스 매퍼 에이전트가 실행되어 전체를 매핑하기 시작합니다.
00:04:28기술 스택, 아키텍처, 컨벤션, 우려 사항 등
00:04:32애플리케이션의 모든 것을 분석합니다. 병렬로 실행 중인 에이전트들이
00:04:38분석을 완전히 마칠 때까지 잠시 기다려 보겠습니다.
00:04:42이제 매퍼가 전체 코드베이스 분석을 완료했습니다.
00:04:46현재 컨텍스트 창이 절반 정도 찼기 때문에 클로드 코드 세션을 리셋하겠습니다.
00:04:50세션을 종료하고 터미널을 정리한 뒤,
00:04:54클로드 코드 세션을 다시 실행하겠습니다. 이제 다시 0부터 시작하지만
00:04:59매핑된 정보는 이미 상태로 저장되어 있으니 걱정 마세요. '.planning' 폴더를 보시면
00:05:04그 안에 코드베이스 정보가 있는 것을 확인할 수 있습니다.
00:05:09애플리케이션의 아키텍처, 우려 사항,
00:05:13컨벤션, 통합 방식 등이 이 폴더에 요약되어 저장되므로
00:05:17매핑한 현재 상태를 잃어버리지 않습니다.
00:05:23전체 코드베이스 매핑이 끝났으니 이제 프로젝트를 초기화할 차례입니다.
00:05:28제 아이디어가 무엇인지 이해하기 위해 일련의 질문들을 던질 것입니다.
00:05:32어떤 새로운 기능을 추가할지 묻고 나면,
00:05:36여러 하위 에이전트들을 병렬로 실행해 구축하려는 도메인을 조사할 것입니다.
00:05:39또한 요구 사항을 추출하고 이를 구현하기 위해
00:05:43정확히 어떤 단계들이 필요한지에 대한 로드맵 작성을 도와줄 것입니다.
00:05:47이 명령어를 복사해서 붙여넣겠습니다. 그러면
00:05:51현재 프로젝트 초기화를 시도할 것입니다. 보시다시피 기존 코드베이스가 있고
00:05:56코드베이스 맵도 이미 마련된 브라운필드(Brownfield) 프로젝트입니다.
00:06:00Git 리포지토리는 있지만 아직 'project.md' 기획 파일은 없네요. 질문이 들어옵니다.
00:06:05코드베이스가 매핑된 기존 프로젝트임을 확인했고, 'cloud.md' 파일을 통해
00:06:10비즈니스 맥락도 파악했다며 다음에 무엇을 빌드하고 싶은지 묻습니다.
00:06:14빌드하려는 기능으로 관리자 시스템용 대시보드를 이미 생각해 두었습니다.
00:06:18AI를 활용해 초안을 잡은 짧은 MD 파일인데요,
00:06:23기존 대시보드 사이드바에 새로운 탭을 추가하여 최소 기능의 관리자 패널을 만드는 것입니다.
00:06:29사용자 관리와 서비스 런칭 시 발생하는 지원 이슈 처리에 필요한 필수 도구들을 제공하죠.
00:06:34요청한 몇 가지 기능들과 MVP 기능들,
00:06:39UX 목업 프레임워크 등이 아주 상세하게 나와 있습니다.
00:06:42저는 여러분도 클로드 같은 AI를 활용해서
00:06:47애플리케이션을 검토하고 무엇을 만들지 계획 초안을 잡아보는 것을 추천합니다.
00:06:52UX 변경 사항이나 포함하고 싶은 기능들을 최소한으로라도 정리해 두어야
00:06:56클로드가 구현할 때 명확한 계획을 가질 수 있기 때문입니다.
00:07:00물론 이 계획을 그대로 클로드에게 구현하게 할 수도 있지만,
00:07:04저는 GSD가 조사나 연구를 직접 수행하게 하고 싶습니다.
00:07:08여러 하위 에이전트를 가동해 대신 조사하고, 이 거대한 작업을
00:07:13구현하기 쉬운 더 작은 작업들로 쪼개는 것이죠. 터미널을 열고
00:07:20정확히 이것을 빌드할 것이라고 말하겠습니다. 이 파일을 참조해서
00:07:25다음에 이것을 빌드할 계획이라고 입력하겠습니다.
00:07:28입력한 뒤 GSD가 기획을 돕도록 하겠습니다.
00:07:33GSD는 이 애플리케이션에 구현하려는 백로그 항목들을 읽어볼 것입니다.
00:07:40그런 다음 정확한 사양을 확인하기 위해 저에게 중요한 질문들을 던지기 시작합니다.
00:07:44이 사양에 사용자 목록, 크레딧, 티어, 사칭 기능 등 네 가지 기능이 모두 포함되어 있는데,
00:07:48이것들을 한꺼번에 빌드할지 아니면 첫 번째 반복 작업에서 일부만 우선순위를 둘지 묻습니다.
00:07:52보시다시피 거대한 네 가지 기능을
00:07:58처음부터 작은 기능들로 쪼개기 시작했습니다. 저는
00:08:02사용자 목록이나 크레딧 같은 단순한 기능부터 시작하자고 말하겠습니다.
00:08:07그렇게 하자고 답변했고요, 관리자 패널이 제대로 작동하는지 어떻게 확인할지도 묻습니다.
00:08:11현재 프로젝트가 아주 초기 단계라 주로 수동 테스트를 하지만,
00:08:16GSD는 테스트 커버리지에 대해 묻고 있습니다. 엔드포인트에 대한 API 경로 테스트나,
00:08:21유닛 테스트, 통합 테스트, E2E 테스트를 포함한 전체 커버리지 테스트 등을 제안하네요.
00:08:25일단은 수동 테스트에만 집중하고 나중에 테스트 커버리지를 높이도록 하겠습니다.
00:08:30당장은 수동 테스트를 하겠다고 답변을 제출합니다.
00:08:34GSD가 다음에 무엇을 할지 지켜보죠.
00:08:38제 답변을 바탕으로 계속 질문을 이어갑니다. 관리자 패널이 언제까지 라이브되어야 하는지도 묻네요.
00:08:43현재 애플리케이션의 타임라인 계획을 담은 비즈니스 분석 문서를 보면
00:08:46실제 출시일이 1월 30일로 언급되어 있습니다.
00:08:50질문에서도 v2 출시일인 1월 30일 전까지 필요한 것인지 묻고 있군요.
00:08:56당연히 1월 30일 전에는 완료되기를 원한다고 말하겠습니다.
00:09:01그런 다음 'project.md' 파일을 생성하고 진행할지 묻습니다.
00:09:05저는 좀 더 탐색하며 질문을 던지고 싶습니다.
00:09:10제가 던진 질문 중 하나는 우리 사양에서 놓치고 있는 간극(Gap)이 무엇인지,
00:09:14그리고 우리가 무엇을 할 것인지 찾아내라는 것이었습니다. 보시다시피 보안, UX,
00:09:19베스트 프랙티스, 그리고 현재 사양에서 놓쳤을 수 있는 기술적 구현의 간극을 조사하기 위해
00:09:22여러 하위 에이전트를 가동했습니다. 여기 보시는 표가
00:09:28전체 간극을 정리한 결과입니다. 예를 들어 관리자 미들웨어 보호 부재,
00:09:32쿠키 누락 등이 있네요. 또한 속도 제한이 메모리 기반이라는 점과
00:09:37사용자 삭제 시의 관리자 동작 문제도 있습니다.
00:09:43다른 사용자에 대해 'isAdmin' 함수가 제대로 작동하지 않는 문제도 있군요. 구현하기 전에
00:09:49이러한 간극들을 반드시 해결해야 합니다. 그리고 여기 보시면
00:09:52GSD가 제안하는 수정 사항 목록이 나옵니다.
00:09:57이 간극들이 타당한지 검토해 볼 수 있습니다.
00:10:02타당하다면 'project.md' 파일을 생성하고 구현을 진행하면 됩니다. 다시 질문이 들어옵니다.
00:10:06조사 결과 치명적인 보안 결함이 발견되었는데 어떻게 처리할지 묻네요.
00:10:11중요한 것들부터 해결하라고 답변하겠습니다. 이것이 제 추천 방식이기도 합니다.
00:10:15입력한 뒤 클로드 코드가 'project.md' 파일로 넘어가기 전에
00:10:20우리 계획과 사양에 빠진 것이 없는지 확인하도록 하겠습니다. 모든 준비가 끝나면
00:10:24이제 'project.md' 파일을 생성할 수 있습니다. 생성하겠다고 답변하겠습니다.
00:10:29클로드 코드가 이 프로젝트 전체를 위한 'project.md' 파일을 생성하기 시작합니다.
00:10:33완료될 때까지 잠시만 기다려 보죠. 다음 섹션으로 넘어가기 전에
00:10:38오늘의 스폰서인 Testbrite를 짧게 소개해 드리고 싶습니다.
00:10:42Testbrite는 소프트웨어 테스트를 위해 특별히 제작된 AI 에이전트입니다.
00:10:46최근 출시된 Testbrite MCP를 통해 커서(Cursor), 윈드서프(Windsurf),
00:10:51클로드 코드 등 여러분이 사용하는 IDE에서 바로 사용할 수 있습니다. 설정도 매우 간단해서
00:10:57MCP 설정에 구성만 추가하면 바로 사용할 수 있습니다.
00:11:02Testbrite의 장점은 테스트를 맹목적으로 실행하지 않는다는 점입니다.
00:11:07코드베이스 전체를 읽고 문서를 이해한 뒤 AI 에이전트가 생성한 결과를 검증합니다.
00:11:11PRD에서 테스트 계획을 자동으로 생성하고 테스트 케이스를 만들며,
00:11:16수동 입력 없이도 적절한 테스트 커버리지를 보장합니다.
00:11:21그 다음 테스트를 실행하고 상세 리포트를 보내주어 무엇이 고장 났고
00:11:26무엇에 주의를 기울여야 하는지 명확히 보여줍니다. 현재 대부분의 코딩 에이전트 정확도가 42% 수준인데,
00:11:32Testbrite MCP를 사용한 팀들은 기능 전달 정확도를 최대 93%까지 높였습니다.
00:11:38관심 있으시다면 제가 만든 관련 영상을 보시거나 아래 설명란의 링크를 확인해 보세요.
00:11:42자, 다시 영상으로 돌아와서 프로젝트 범위 설정과 'project.md' 파일 생성이 완료되면
00:11:47모드를 선택하라는 메시지가 뜹니다. 자동으로 승인하고 바로 실행하는 'YOLO 모드'를 쓸 수도 있고,
00:11:52대화형 모드를 선택할 수도 있습니다. 대화형 모드에서는 단계가 끝날 때마다
00:11:56변경 사항을 확인하고 다음으로 넘어갈 수 있죠. 저는 'YOLO 모드'로 가서
00:12:01제가 직접 손대지 않고 모든 것을 완수하도록 해보겠습니다. 엔터를 눌러 YOLO 모드를 선택합니다.
00:12:04다음으로 기획의 깊이를 선택해야 합니다. 기획을 얼마나 철저하게 할지 묻는 것이죠.
00:12:09빠른 배포를 위해 3~5단계로 구성된 빠른 방식을 택할 수도 있고,
00:12:145~8단계로 구성된 좀 더 균형 잡힌 표준 방식을 택할 수도 있습니다.
00:12:18각 단계는 3~5개의 계획을 가질 수 있습니다. 이번에는
00:12:22표준 방식을 선택하겠습니다. 아주 빠르게 배포하는 것보다는
00:12:26범위가 균형 잡힌 결과물을 원하기 때문입니다. 2번을 클릭하겠습니다.
00:12:30이제 답변을 제출합니다. 그러면 결과적으로
00:12:34실행 방식을 묻는 메시지가 나옵니다. 독립적인 계획들을 동시에 실행하는 '병렬 실행'과
00:12:38하나씩 차례대로 실행하는 '순차 실행' 중 선택할 수 있습니다.
00:12:42제 추천은 시간이 아주 급한 게 아니라면
00:12:46순차 실행을 하는 것입니다. 병렬로 하는 것보다 계획을 하나씩 차근차근 처리하는 게 낫기 때문입니다.
00:12:51예를 들어 병렬로 실행하다가 크레딧이 다 떨어지면 두 작업 모두 미완성 상태로 멈출 수 있습니다.
00:12:57하지만 순차적으로 하면 최소한 몇 가지 작업은 완료할 수 있죠.
00:13:01크레딧이 떨어지더라도 기다리거나 내일 다시 와서
00:13:06남은 작업을 하나씩 이어서 진행할 수 있습니다. 적어도 모든 계획이 반쯤만 완성된 상태로 남지는 않겠죠.
00:13:10그래서 한 번에 한 단계씩 진행하도록 순차 실행을 선택하겠습니다.
00:13:14Git 추적의 경우 기획 문서를 Git에 커밋할지 묻는데,
00:13:18당연히 기획 문서들을 기록으로 남기고 싶으므로 그렇다고 답변하겠습니다.
00:13:22답변을 제출합니다. 추가 질문들이 나오네요.
00:13:27기획 전에 조사를 수행할지 묻는데 '예'라고 했고, 실행 전 계획이 목표를 달성할지
00:13:31검증할 것인지에도 '예'라고 했습니다. 다음은 검증 에이전트에 대한 설정입니다.
00:13:35각 단계가 끝날 때마다 요구 사항을 충족하는지 검증할 것인지 묻기에
00:13:40이 역시 '예'라고 답했습니다. 모델 선호도에 대해서는
00:13:46가장 품질이 좋은 모델을 선택하겠습니다. 비용은 더 들지만 더 깊은 분석을 위해
00:13:52조사와 로드맵 작성에 'Opus' 모델을 사용하도록 설정했습니다.
00:13:58이렇게 하면 모든 설정이 'config.json' 파일에 저장됩니다.
00:14:03이것이 설정 파일이며, 나중에 변경하고 싶은 내용이 있다면
00:14:07이 파일을 직접 수정하면 됩니다. 영상이 너무 길어지지 않도록 이어서 진행해 보죠.
00:14:12GSD가 이제 조사 단계로 넘어갑니다. 보시다시피
00:14:16GSD는 조사 종합 에이전트를 가동하고 먼저 여러 하위 에이전트를 실행해 조사를 시작합니다.
00:14:21모든 조사가 완료되면 그 내용들을 종합하여
00:14:26개발하려는 프로젝트를 기반으로 자체 조사 보고서를 작성합니다.
00:14:30그 내용에 동의하면 GSD는 이 프로젝트 전체를 위해
00:14:34단계별로 무엇을 할지 로드맵을 작성하는 단계로 넘어갑니다.
00:14:39이제 전체 로드맵이 생성되었습니다. 총 5단계로 구성되어 있으며
00:14:43모든 v1 요구 사항을 포괄하는 36개의 요구 사항이 매핑되었습니다.
00:14:49예를 들어 데이터베이스 스키마, 백엔드, 그리고 사용자 경험(UX) 등이 포함됩니다.
00:14:54이 로드맵 구조가 괜찮은지 묻는데,
00:14:59쭉 훑어보면서 빠진 것이 없는지 확인하면 됩니다. 문제가 없다면
00:15:03승인하고 변경을 시작하라고 하겠습니다. 프로젝트 초기화가 완료되면
00:15:08생성된 MVP 관련 결과물들을 확인할 수 있습니다. 모두 'planning' 폴더 안에 들어 있죠.
00:15:13모든 것이 planning 폴더 안에 들어있죠. 5개 단계와 36개의 요구 사항이 모두 빌드될 준비가 되었습니다.
00:15:18이제 괜찮다면 1단계부터 시작해 보겠습니다.
00:15:21단계별로 하나씩 시작할 겁니다. 1단계에 대한 계획을 생성하면,
00:15:25보시는 것처럼 여러 하위 에이전트를 동원해 2단계, 3단계에 대한 계획을
00:15:29한꺼번에 생성하게 됩니다. 하위 에이전트들을 통해
00:15:34각 단계에 맞는 새로운 계획을 생성할 수 있죠. 계획이 만들어지면,
00:15:38이제 구현 단계로 넘어갈 수 있습니다. 앞서 언급했듯이,
00:15:41새로운 컨텍스트를 사용해 순차적으로 실행하고 싶습니다. 한 단계가 끝날 때마다
00:15:46저에게 확인을 요청하는 방식이 아니라, 모든 과정을 완전히 끝내고 나서
00:15:52한 번에 검증하고 싶기 때문이죠. 매 단계마다 확인할 필요는 없습니다.
00:15:55모든 단계가 완료된 후에 검증하겠습니다. 이제 Claude에게 가서
00:15:59GSD 단계들을 새로운 컨텍스트로 순차 실행하고 싶다고 말하면 됩니다.
00:16:03그러면 각 계획에 대해 깨끗한 세션 컨텍스트를 생성하여
00:16:08단계별로 하나씩 실행하게 됩니다. 기본적으로 어떤 일이 벌어지냐면,
00:16:13GSD 실행기를 사용해 새로운 하위 에이전트들을 실행하는 겁니다. 각 에이전트는
00:16:18200K의 깨끗한 컨텍스트를 할당받아, 이전 에이전트가 완료한 계획과 섞이지 않게 됩니다.
00:16:23그리고 GSD를 통해 13개의 모든 계획을
00:16:27자율적으로 실행하게 됩니다. 데이터베이스 스키마, 백엔드, UI, 크레딧 관리,
00:16:34그리고 감사 로그 뷰어까지 포함되죠. 모든 것이 하나씩 차례로 실행됩니다.
00:16:39여기서 컨텍스트를 비우고 권한 확인을 건너뛴 뒤 순차적으로 실행해 보겠습니다.
00:16:44이제 구현을 위한 관리자 대시보드의 1단계 실행이 시작되는 것을 볼 수 있습니다.
00:16:48모든 구현이 완료될 때까지 잠시 기다려 보죠. 자, GSD를 통한
00:16:53모든 단계의 구현이 끝난 결과물입니다. 보시다시피
00:16:57관리자 탭의 사용자 관리 섹션에 와 있습니다. 여기서는 현재 플랫폼에 있는
00:17:03모든 사용자를 확인할 수 있습니다. 사용자 검색도 가능한데요,
00:17:07예를 들어 "test"라고 입력하면 첫 번째 결과가 바로 나타납니다.
00:17:12검색어를 지우면 다시 전체 목록이 표시되죠.
00:17:17티어별로 필터링할 수도 있습니다. 무료 티어 사용자가 누구인지
00:17:21확인할 수 있고, 크레딧 사용량과 가입 시점을 보거나 크레딧을 조정할 수도 있습니다.
00:17:25여기서 계정 상세 정보를 보거나, 크레딧을 직접
00:17:29조정할 수도 있습니다. 이벤트를 조정하거나,
00:17:33크레딧 설정, 커스텀 크레딧 한도 설정, 현재 사용량 확인이 가능하며
00:17:38사유도 입력할 수 있습니다. 감사 로그에서 이 모든 과정을 추적할 수 있죠.
00:17:42예를 들어, 모든 티어를 선택하고 현재 제가 관리자로 설정된
00:17:48이 사용자로 로그인한 상태라고 해봅시다. 여기서 크레딧 조정을 클릭하고,
00:17:52크레딧 금액을 늘려보겠습니다. 50크레딧을 추가한다고 가정하면,
00:17:57현재 510크레딧에서 560크레딧이 되겠네요. 아래쪽에
00:18:03사유를 추가하기만 하면 됩니다. 예를 들어 "test"라고 적고
00:18:07변경 사항을 적용해 보겠습니다. 보시는 것처럼
00:18:11510에서 560으로 증가했다는 알림이 뜨고 해당 컴포넌트의
00:18:17리렌더링이 트리거됩니다. 테이블에서도 변경된 수치인
00:18:21560으로 즉시 반영된 것을 확인할 수 있죠. 기능이 완벽하게
00:18:27작동하는 것을 검증했습니다. 관리자 분석 섹션에서는
00:18:31애플리케이션의 다양한 통계를 확인할 수 있습니다.
00:18:36마지막 업데이트 시간은 물론 총 사용자 수, 유료 사용자 수,
00:18:40티어별 분포, 크레딧 사용량, 활성 사용자 순위 등을 볼 수 있습니다.
00:18:46또한 감사 로그도 확인 가능한데, 이는 사용자 크레딧을 조정하는 등
00:18:51우리가 수행한 모든 이벤트와 작업이 기록된다는 뜻입니다. 이 기록들을
00:18:55이곳 감사 로그에서 볼 수 있죠. 크레딧 조정이나 동기화 내역, 대상 사용자,
00:19:00상세 작업 내용 등을 모두 확인할 수 있습니다. 대략 이런 방식으로
00:19:05GSD를 활용해 개발의 전 과정을 따라가며 기능을 완성할 수 있습니다.
00:19:09이 영상이 도움이 되었다면 좋아요를 눌러주세요. 그리고
00:19:13페이지 새로고침 없이 크레딧 적용 후 컴포넌트를 어떻게 리렌더링했는지
00:19:16궁금하시다면, 짧게 말씀드려 전역 상태 관리 도구인 Zustand를 사용했습니다.
00:19:21애플리케이션 전체의 상태를 중앙 집중화하여, 컴포넌트의
00:19:26한 부분이 업데이트되면 현재 상태에서 즉시 변경이 반영되도록 한 것이죠.
00:19:30여러분의 프로젝트에 이러한 상태 관리를 도입하는 방법이 궁금하시다면,
00:19:34제가 제작한 7시간 분량의 코스를 추천합니다. 확장 가능하고
00:19:38완성도 높은 NestJS 애플리케이션을 단계별로 구축하는 법을 담고 있습니다.
00:19:44이번 영상이 유익했다면 좋아요 부탁드립니다.
00:19:47구독도 잊지 마세요. 앞으로 AI를 활용해 실제 서비스 수준의
00:19:51애플리케이션을 개발하는 다양한 기법과 교훈들을 공유할 예정입니다.
00:19:55그럼 다음 영상에서 뵙겠습니다.

Key Takeaway

GSD 프레임워크는 Claude Code의 능력을 극대화하여 복잡한 소프트웨어 개발 과정을 하위 에이전트들에게 체계적으로 위임하고 자율적으로 완수하게 돕는 혁신적인 도구입니다.

Highlights

GSD(Spec-driven development) 프레임워크는 단일 컨텍스트의 한계인 '컨텍스트 포화' 문제를 하위 에이전트 분할로 해결합니다.

Claude Code와 연동하여 기획, 조사, 실행, 검증의 전 과정을 자율적으로 수행하는 오케스트레이터 역할을 합니다.

코드베이스 매핑 기능을 통해 기존 프로젝트(Brownfield)의 아키텍처와 컨벤션을 자동으로 분석하고 저장합니다.

조사 에이전트를 통해 보안 결함이나 기술적 간극(Gap)을 사전에 파악하여 프로젝트의 안정성을 높입니다.

YOLO 모드와 순차 실행 방식을 지원하여 사용자의 개입 없이도 복잡한 마일스톤을 끝까지 완수할 수 있습니다.

실제 관리자 대시보드 구현 사례를 통해 사용자 관리, 크레딧 조정, 감사 로그 기능이 완벽히 작동함을 증명합니다.

Timeline

GSD 프레임워크 소개 및 기존 방식과의 차이점

에릭 강연자는 오픈 소스 기반의 사양 중심 개발 프레임워크인 GSD를 소개하며 영상의 포문을 엽니다. 기존의 Beemap이나 SpecKits 방식은 모든 작업을 단일 컨텍스트 창에서 처리해야 했기에 토큰 소비가 늘어날수록 정확도가 떨어지는 '컨텍스트 포화' 문제가 발생했습니다. GSD는 이를 해결하기 위해 기획, 조사, 개발, 검증 작업을 각각의 독립된 하위 에이전트에게 위임하는 오케스트레이션 방식을 채택합니다. 이 방식은 토큰 소비는 더 많을 수 있지만 각 에이전트가 깨끗한 컨텍스트를 유지하므로 결과물의 정확도가 비약적으로 향상됩니다. 강연자는 시니어 엔지니어로서의 경험을 바탕으로 실무적인 튜토리얼을 제공할 것임을 약속하며 구독을 권장합니다.

GSD 설치 및 프로젝트 초기 분석 단계

GSD를 로컬 환경에 설치하고 기존 프로젝트에 적용하는 구체적인 프로세스를 설명합니다. 사용자는 터미널에서 간단한 명령어로 GSD를 설치할 수 있으며, Claude Code 전용 상태 표시줄을 선택하여 실시간 컨텍스트 사용량을 확인할 수 있습니다. 설치 후 가장 먼저 수행하는 작업은 '코드베이스 매핑'으로, 4개의 병렬 에이전트가 기술 스택, 아키텍처, 컨벤션을 분석합니다. 분석된 정보는 '.planning' 폴더에 저장되어 세션이 리셋되더라도 프로젝트의 맥락을 잃지 않도록 설계되었습니다. 이 단계는 AI가 프로젝트의 전체 지도를 그리게 함으로써 이후 발생할 오류를 최소화하는 중요한 기초 작업입니다.

요구 사항 추출 및 기술적 간극 조사

사용자가 구현하고자 하는 아이디어를 GSD에게 전달하고 이를 구체화하는 과정을 담고 있습니다. 강연자는 관리자 대시보드 기능을 예시로 들어, AI가 사용자 목록 및 크레딧 관리와 같은 핵심 기능을 어떻게 작은 작업 단위로 쪼개는지 보여줍니다. 특히 GSD는 단순 구현에 그치지 않고 여러 조사 에이전트를 가동하여 보안 취약점이나 미들웨어 부재와 같은 '기술적 간극'을 사전에 찾아냅니다. 이 과정에서 발견된 치명적인 보안 결함은 기획 단계에서 우선순위로 조정되어 반영됩니다. 사용자는 AI와 대화하며 프로젝트의 범위를 확정하고 최종적으로 'project.md' 기획 파일을 생성하게 됩니다.

실행 모드 설정 및 자율 구현 프로세스

기획이 완료된 후 실제 코드를 작성하기 위한 실행 옵션을 설정하는 단계입니다. 사용자는 대화형 모드 대신 모든 것을 자율적으로 처리하는 'YOLO 모드'를 선택하고, 작업의 안정성을 위해 '순차 실행' 방식을 택합니다. GSD는 각 단계마다 200K의 깨끗한 컨텍스트를 가진 새로운 하위 에이전트를 생성하여 데이터베이스 스키마부터 UI 컴포넌트까지 하나씩 빌드합니다. 이 방식은 이전 작업의 데이터가 현재 작업의 정확도를 방해하지 않도록 보장하며, 병렬 실행 시 발생할 수 있는 자원 부족 문제를 예방합니다. 강연자는 'Opus' 모델을 활용해 비용보다는 분석의 깊이에 집중하여 고품질의 코드를 생성하는 과정을 시연합니다.

구현 결과 검증 및 상태 관리 최적화

마지막으로 GSD가 자율적으로 완성한 관리자 대시보드의 실제 작동 모습을 상세히 검증합니다. 사용자 검색, 티어별 필터링, 그리고 실시간 크레딧 조정 기능이 오류 없이 작동하며 감사 로그에 모든 이력이 기록되는 것을 확인할 수 있습니다. 특히 페이지 새로고침 없이 데이터가 즉시 반영되는 부분은 전역 상태 관리 도구인 'Zustand'를 활용했음을 설명합니다. 강연자는 단순한 코드 생성을 넘어 실제 프로덕션 수준의 애플리케이션을 구축하기 위한 상태 관리의 중요성을 강조합니다. 끝으로 더 깊이 있는 학습을 원하는 시청자들에게 자신의 NestJS 코스를 추천하며 영상을 마무리합니다.

Community Posts

View all posts