클로드 코드 에이전트: SaaS 개발자의 비밀 병기

Sean Kochel 구독자 2,190명

요약

이 영상은 Claude Code Agents를 활용해 제품 기획, 디자인, 아키텍처, 엔지니어링, QA, 배포, 보안까지 SaaS 개발 전 과정을 자동화하는 방법을 소개합니다. 단일 CLI 명령으로 디버깅, 제품 매니저, UX/UI, 시스템 설계, 프론트/백엔드, 테스트, DevOps, 보안 에이전트를 구성해 24/7 운영 가능한 AI 개발 팀을 구축하는 비법을 확인할 수 있습니다. 각 에이전트는 전용 시스템 프롬프트와 도구를 활용해 전문 인력 없이도 MVP 기획부터 프로덕션 배포까지 일관된 스펙 주도 개발(Spec-Driven Development)을 지원합니다. 이를 통해 솔로 창업자나 소규모 팀도 기술 인력 부족이라는 한계를 극복하고, 빠르고 안정적인 SaaS 애플리케이션을 구현할 수 있습니다.

주요 키워드

Claude Code Agent Spec-Driven Development Design System CI/CD 파이프라인 Event-Driven Architecture 컨텍스트 윈도우 MVP Chrome Extension Manifest

하이라이트

🔑 Claude Code 에이전트를 통해 24/7 작동하는 AI 개발 팀을 구성해, 기술 팀 전체를 대체할 수 있는 뛰어난 생산성을 얻을 수 있습니다.
📌 각 에이전트는 전용 시스템 프롬프트, 컨텍스트 창, 도구를 가지고 있어, 복잡한 기술 작업도 초보자 수준에서 수행할 수 있도록 도와줍니다.
⚡️ 간단한 디버깅 에이전트를 사용해 Python 코드의 평균 계산 버그를 자동으로 진단하고 수정하는 과정을 시연해 보였습니다.
🌟 Product Manager 에이전트는 추상적인 아이디어를 구체적인 MVP 기능, 사용자 스토리, 수용 기준 등으로 체계화해 줍니다.
🚀 UX/UI Designer 에이전트는 디자인 철학, 색상, 타이포그래피, 컴포넌트 등 통합 디자인 시스템을 생성해 사용자 경험을 고도화합니다.
📌 Architecture 에이전트는 시스템 요구사항, 기술 스택, 데이터 모델, API 설계, 보안·성능 고려사항을 종합적으로 문서화합니다.
🔧 Front-end & Back-end Engineering 에이전트를 통해 디자인 사양과 기술 문서를 코드로 구현해, 성능 최적화된 애플리케이션 구조를 구축할 수 있습니다.
🛡️ QA, DevOps, Security 에이전트가 테스트, 배포 파이프라인, 보안 스캔을 자동화해 프로덕션 환경에서 안정적으로 운영되도록 지원합니다.

용어 설명

Claude Code Agent

클로드 코드 내에서 실행되는 하위 에이전트로, 각기 다른 시스템 프롬프트와 도구를 사용해 특정 역할을 수행합니다.

MVP (Minimum Viable Product)

최소 기능 제품으로, 핵심 가설을 검증하기 위해 최소한의 기능만 포함한 초기 버전입니다.

컨텍스트 윈도우

모델이 한 번에 참조할 수 있는 입력 토큰의 범위로, 에이전트의 기억 용량을 결정합니다.

Design System (디자인 시스템)

일관된 UI 구성 요소, 색상, 타이포그래피, 레이아웃 규칙 등을 체계화한 디자인 가이드입니다.

Spec-Driven Development

사전에 정의된 기술 사양서를 바탕으로 개발을 진행해 일관성 있고 확장 가능한 코드를 구현하는 방식입니다.

CI/CD 파이프라인

지속적 통합(Continuous Integration)과 지속적 배포(Continuous Deployment)를 자동화해, 코드 변경을 신속하고 안정적으로 프로덕션에 배포하는 프로세스입니다.

Chrome Extension Manifest

크롬 확장 프로그램의 메타데이터와 권한, 스크립트 파일 등을 정의하는 구성 파일입니다.

Event-Driven Architecture

시스템 컴포넌트가 이벤트를 통해 비동기적으로 상호작용하는 아키텍처 패턴입니다.

발표자는 최근 출시된 Claude Code 에이전트가 SaaS 개발 워크플로를 자동화해 24/7 작동하는 AI 팀을 제공하는 최고의 도구임을 강조합니다.

[00:00] Claude Code 에이전트의 출시와 기존 AI 코딩 프롬프트의 한계를 지적하며, 단순한 프롬프트 대신 전문적인 에이전트 시스템의 필요성을 강조합니다.

[00:19] 8개의 맞춤형 Claude Code 에이전트를 소개하며, 전체 SaaS 개발 워크플로를 대체하고 기술팀 전체를 대신할 수 있다고 설명합니다.

Claude Code 에이전트는 전용 시스템 프롬프트, 컨텍스트 윈도우, 도구를 갖춘 하위 에이전트로, 복잡한 기술 작업을 자동화할 수 있습니다.

[00:42] 기존 바이브 코딩 프레임워크를 발전시킨 에이전트들이 24시간 작업 가능한 AI 개발팀을 구성하며, 솔로 창업자에게 강력한 이점을 제공한다고 강조합니다.

[01:14] Claude Code 에이전트의 정의와 구조를 설명하며, 각각이 독립적인 시스템 프롬프트, 컨텍스트 윈도우, 전용 도구를 갖춘 특화된 서브 에이전트임을 소개합니다.

[01:36] 기존 프롬프팅 시스템의 복잡한 체이닝 방식과 달리, 새로운 에이전트들은 자체적으로 추론하고 필요한 작업을 판단할 수 있는 게임체인저라고 설명합니다.

[01:58] 에이전트들의 실행 순서의 중요성과 이를 사용함으로써 얻을 수 있는 경쟁 우위에 대해 언급하며, 실제 설정 방법으로 넘어갑니다.

CLI에서 slash agents 명령어로 에이전트를 생성하고, 설명·프롬프트·모델·도구를 설정해 프로젝트별 디렉토리에 구성하는 과정을 설명합니다.

[02:25] Claude Code 에이전트 설정의 첫 단계로 터미널에서 '/agents' 명령어를 사용한 CLI 기반 생성 방법과 프로젝트별 구성 옵션을 안내합니다.

[02:52] Claude Code 에이전트 설정을 위한 두 가지 방법을 소개합니다. 수동 설정과 Claude Code 헬퍼 사용이 있으며, 에이전트 사용 시점에 대한 포괄적인 설명이 중요합니다.

[03:12] 에이전트 생성 과정을 설명하며, .claude/agents 디렉토리에 모든 프로젝트 에이전트가 저장됩니다. 디버거 에이전트의 구조를 보여주며 이름, 설명, 색상, 모델 설정을 포함합니다.

Python 평균 계산 코드를 예시로 디버깅 에이전트를 호출해 자동으로 문제를 분석·수정하고, 성공적으로 버그를 해결하는 과정을 시연합니다.

[03:52] 에이전트의 시스템 프롬프트 구조를 상세히 설명합니다. 핵심 철학, 접근 방식, 입력 기대치, 디버깅 대상, 전체 프로세스, 특정 MCP 서버 도구 접근 권한 등을 포함합니다.

[04:30] 실제 Python 파일을 이용한 디버깅 데모를 진행합니다. 평균 계산 스크립트에 의도적으로 버그를 삽입하여 에이전트의 작동 방식을 보여주며, 실제로 20이어야 할 평균이 30으로 나오는 문제를 해결합니다.

[05:23] 기본적인 예시를 마치고 이제 8개의 Claude Code 에이전트들을 자세히 살펴볼 예정이라고 소개합니다. 모든 에이전트는 동영상 설명란에서 확인할 수 있으며, 소개 순서가 실제 사용 순서와 다를 수 있다고 설명합니다.

제품 관리자, UX/UI 디자이너, 아키텍처 기획, 프론트/백엔드 엔지니어, QA, DevOps, 보안 분석가까지 총 8개의 에이전트를 개요합니다.

[05:42] 전체 end-to-end SaaS 애플리케이션 구축 영상은 이번 주 후반에 공개될 예정이며, 6-7단계 시스템으로 구성할 계획이라고 안내합니다.

[05:46] 첫 번째 에이전트인 프로덕트 매니저를 소개합니다. 프로젝트를 처음 시작할 때 추상적인 아이디어를 MVP의 구체적인 요소로 번역하는 역할을 담당한다고 설명합니다.

아이디어를 입력하면 MVP 기능, 사용자 스토리, 수용 기준, 기능 요구사항 등을 체계화해 프로젝트 시작 단계의 기획을 자동화합니다.

[06:06] 프로덕트 매니저 에이전트는 개발자의 편견을 극복하고 실제 문제와 해결책에 집중하도록 돕는 방어 메커니즘이라고 설명합니다. 일반적인 앱 아이디어를 입력하면 상세한 내용들을 출력한다고 소개합니다.

[06:22] 에이전트의 구성 요소들을 설명합니다. 페르소나, 문제 해결 접근법, 기능별 요약 보고서 형식(기능, 사용자 스토리, 수락 기준, 기능적/비기능적 요구사항)을 포함한다고 안내합니다.

[06:47] 실제 예시로 시즌 컬러 타입에 맞는 쇼핑을 돕는 크롬 확장 프로그램 프로젝트를 소개합니다. 시즌 컬러 분석이 패션의 하위 분야로서 피부톤, 헤어컬러, 눈 색깔 등을 기반으로 수학적으로 잘 어울리는 색상을 분석한다고 설명합니다.

[07:55] 프로덕트 매니저 에이전트가 생성되기 시작했으며 특정 도구들을 사용하기 시작했다고 보고합니다. 잠시 후 다시 돌아와서 에이전트의 작업 과정을 보여주겠다고 안내합니다.

[08:03] 생성된 제품 매니저 에이전트가 특정 도구들을 사용하기 시작하며 약 2분간 실행되어 결과물을 생성했습니다.

[08:19] 에이전트가 요청대로 앱의 엘리베이터 피치와 문제 정의서를 생성했으며, 이는 모든 후속 단계의 기반이 되므로 신중히 검토해야 합니다.

[08:34] 대부분의 사람들이 체형 분석에 대해 모르기 때문에 잘못된 의류 구매 결정을 내리고, 잘 맞지 않는 옷에 돈을 낭비하게 된다는 문제를 정의했습니다.

[08:50] 타겟 오디언스의 주요 페르소나, 인구통계학적 분석, 고유한 판매 포인트를 도출했으며, 이 서비스는 분석을 통해 직접 쇼핑까지 가능하게 하는 독특한 특징을 가지고 있습니다.

[09:08] 사용자 페르소나와 고통점을 분석하고, 실제 구축할 핵심 사용자 플로우를 정의했습니다. 확장프로그램 설치부터 온보딩, 실제 쇼핑 과정까지의 상호작용을 구체적으로 설계했습니다.

[09:33] 위시리스트 생성, 색상 조정 등의 보조 기능들과 기능 스토리, 승인 기준, 진행 표시기 등의 중요한 고려사항들을 포함한 상세한 설계를 완성했습니다.

[09:51] 다음으로 UX/UI 디자이너 에이전트를 소개하며, 이는 화자가 가장 좋아하는 에이전트 중 하나라고 설명했습니다.

제품 매니저 출력물을 바탕으로 디자인 철학, 색상·타이포그래피·레이아웃, 컴포넌트별 시각 사양, 화면별 상세 UX 플로우를 생성합니다.

[10:01] 훌륭한 앱이 훌륭하게 느껴지는 이유는 재능있는 디자이너가 사용자의 문제 해결을 위한 상호작용에 대해 깊이 생각했기 때문이라고 강조했습니다.

[10:14] 이 에이전트는 앱이 시각적으로 멋져 보이는 것과 설계된 상호작용 방식을 통해 실제 목표를 달성하는 두 가지를 모두 보장하는 역할을 합니다.

[10:33] 제품의 완성도를 높이기 위해 UX/UI 디자이너 에이전트를 활용하는 방법을 설명합니다. 사용자에게 조잡한 경험을 제공하지 않기 위해 시니어 프로덕트 디자이너의 전문성을 주입해야 한다고 강조합니다.

[10:59] 에이전트는 프로덕트 매니저의 결과물을 받아 타겟 고객과 앱의 목적을 분석한 후, 일관성 있는 디자인 철학을 구축합니다. 디자인 원칙과 핵심 UX 원칙부터 시작하여 포괄적인 디자인 시스템을 만들어냅니다.

[11:22] 디자인 시스템에는 색채 이론, 타이포그래피, 간격과 레이아웃, 컴포넌트의 시각적 명세와 상호작용 방식이 포함됩니다. 이는 기존 SaaS 회사에서 프로덕트 디자이너가 구축하고 프론트엔드 엔지니어가 구현하는 과정을 모방한 것입니다.

[11:54] 에이전트는 프로덕트 매니저 결과물을 기능별로 분석하여 각 기능의 외형과 작동 방식에 대한 전체 시스템을 구축합니다. 이 에이전트 기반 시스템의 장점은 작업 중에 필요에 따라 할 일 목록을 동적으로 업데이트할 수 있다는 점입니다.

[12:36] 완성된 포괄적인 UI UX 디자인 시스템은 디자인 철학, 컬러 시스템, 간격과 레이아웃을 포함합니다. 사용자 여정 매핑과 화면별 명세도 제공하며, 온보딩 화면의 시각적 레이아웃, 콘텐츠 계층구조, 애니메이션 등 세부사항까지 다룹니다. 이 모든 결과물은 최종적으로 프론트엔드 엔지니어링 에이전트에게 전달됩니다.

기획·디자인 결과물을 종합해 기술 스택 선정, 데이터·API 설계, 보안·성능 고려, 이벤트 기반 아키텍처 등 시스템 전반을 설계합니다.

[13:25] DevOps 엔지니어를 백그라운드에서 실행하여 전체 프로젝트 구성을 자동화합니다. 린트 파일, Babel 설정, Docker 파일, 크롬 익스텐션 매니페스트 등 개발에 필요한 모든 설정이 자동으로 준비됩니다.

[14:01] 아키텍처 에이전트는 프로덕트 매니저와 UX/UI 에이전트의 모든 결과물을 분석하여 상세한 시스템 아키텍처를 구축합니다. 핵심 기능 분해, 기술 스택 선정, 데이터 아키텍처, API 설계 등을 종합적으로 분석합니다.

[14:35] 시스템 요구사항 분석에는 보안 및 성능 고려사항, 위험 요소, 프론트엔드/백엔드 프레임워크 선택, 컨텍스트와 상태 관리 방법이 포함됩니다.

[15:18] 크롬 익스텐션 프로젝트의 구체적인 아키텍처 결정사항을 살펴보면, 매니페스트 파일, 고성능 처리, 구글 웹 워커를 활용한 이미지 처리, 이벤트 기반 아키텍처가 필요합니다.

[15:43] 백엔드 엔지니어링 에이전트를 위한 상세한 문서화도 제공되며, 핵심 엔드포인트와 데이터 타입 규격이 명시됩니다. 이를 통해 혼자 창업하는 개발자도 전문적인 시스템을 구축할 수 있습니다.

[16:05] 기술적이지 않은 사람도 기술적 솔루션을 만들 수 있다고 설명하며, 솔로 창업자나 취미 개발자들이 야심찬 프로젝트는 있지만 기술적 지식 부족으로 어려움을 겪는다고 지적합니다.

디자인 시스템과 기술 문서를 입력으로 받아 토큰 기반 컴포넌트, 상태 관리, 인터랙션 구현 등 고성능 프론트엔드를 생성합니다.

[16:21] 많은 도구, 패턴, 시스템들을 모르는 것이 문제라고 하며, 잘못된 데이터베이스나 백엔드 프레임워크 선택이 나중에 큰 문제가 될 수 있다고 경고합니다.

[16:42] 시스템 아키텍처 에이전트를 CTO처럼 생각하라고 하며, 제품 계획을 주면 상세한 기술 명세서를 돌려받아 기술 스택, 데이터베이스 스키마, API 계약 등을 알 수 있다고 설명합니다.

[17:03] 갑작스런 사용자 급증 상황에 대한 대응 방안도 고려해야 한다고 강조하며, 시니어 프론트엔드 엔지니어링 에이전트의 필요성을 소개합니다.

[17:24] UX/UI 프레임워크와 백엔드가 준비되면, 두 세계를 연결하여 사용자가 상호작용할 수 있는 기능적인 앱을 만드는 프론트엔드 구축이 필요하다고 설명합니다.

[17:41] 추상적인 UX/UI 이론을 빠르고 성능 좋은 프론트엔드로 번역해야 한다고 하며, 재사용 가능한 컴포넌트 시스템과 상태 관리 시스템 구축의 중요성을 설명합니다.

[18:07] 이 영상은 완전한 앱 빌드가 아니라 에이전트 구성들을 살펴보는 것이라고 하며, 프론트엔드 엔지니어가 기술 명세서와 디자인 시스템을 프로덕션 준비된 인터페이스로 변환하는 방법을 설명합니다.

스펙 주도 개발로 데이터베이스 마이그레이션, API 엔드포인트, 비즈니스 로직, 인증·인가, 성능 최적화를 고려해 백엔드를 구축합니다.

[18:44] 프론트엔드 구현을 위한 단계별 접근법을 설명하며, 사용자 스토리와 백엔드 요구사항을 체계적으로 분석하고 디자인 시스템을 구축하는 과정을 안내합니다.

[19:03] 데이터 관리 시스템 구축의 중요성을 강조하며, 백엔드에서 데이터를 가져와 프론트엔드에서 효율적으로 저장하고 활용하는 방법을 설명합니다.

[19:15] 사용자 경험 최적화를 위한 성능 요구사항을 제시하며, 빠르고 반응성 있는 애플리케이션 구축의 필요성과 완료 후 포괄적인 문서화의 중요성을 설명합니다.

[19:36] 프론트엔드와 백엔드의 상호 의존성을 강조하며, 백엔드가 앱의 핵심 경험을 구동하는 진정한 워크호스 역할을 한다는 점을 설명합니다.

[19:56] 시각적 중심의 바이브 코딩과 달리 백엔드의 비즈니스 로직이 실제 앱 구동에 미치는 영향을 설명하며, 백엔드가 모든 무거운 작업과 핵심 로직을 처리한다는 점을 강조합니다.

[20:16] 백엔드 구축 과정에서 아키텍처 계획과 기능 요구사항을 바탕으로 API 엔드포인트, 데이터베이스 스키마, 비즈니스 로직, 인증 및 권한 부여 시스템을 구축하는 스펙 기반 개발 방법론을 소개합니다.

[20:58] 기술 문서를 바탕으로 백엔드 개발을 진행하는 과정에서 데이터베이스 마이그레이션, API 개발, 외부 시스템 통합, 핵심 비즈니스 로직 구현 등의 주요 고려사항들을 제시합니다.

[21:16] 백엔드 최적화를 위한 성능과 확장성 고려사항을 설명하고, 권장하는 구현 접근법으로 스펙 분석, 데이터베이스 계획, 마이그레이션 실행, 보안과 성능이 보장된 로직 구축을 제시합니다.

유닛·통합·엔드투엔드 테스트를 계획·구현해 테스트 커버리지와 규칙을 준수하고, 안정적인 프로덕션 배포를 보장합니다.

[21:44] 앱 설계와 프론트엔드/백엔드 구축을 완료했지만, 실제 프로덕션에서 작동하려면 적절한 QA와 테스팅 환경 설정이 필수적이라고 강조합니다. 대부분의 개발자들이 놓치는 부분이지만 해피패스에만 의존할 수 없다고 경고합니다.

[22:07] 충분한 테스트 없이 개발할 경우 이전에 작동했던 기능을 망가뜨릴 가능성이 높아지며, 이는 필연적으로 발생할 수 있는 문제라고 지적합니다. 따라서 계획적인 접근이 필요하지만 여전히 고속으로 두려움 없이 구축할 수 있어야 한다고 말합니다.

로컬 개발용 Docker 설정부터 GitHub Actions 기반 CI/CD 파이프라인, 배포 스크립트, 비밀 관리 등을 자동화해 효율적 운영을 지원합니다.

[22:28] 이 테스팅 시스템의 핵심 차이점은 컨텍스트 의존적이라는 것으로, 요청에 실제로 의미가 있는 시스템 프롬프트 부분만 실행한다고 설명합니다. 이상적으로는 백엔드, 프론트엔드, 엔드투엔드 테스팅 에이전트로 분리할 수 있지만 올인원 방식을 사용한다고 합니다.

[23:00] 세 가지 특정 컨텍스트에서 호출되는 시스템을 설명합니다: 백엔드 함수 테스팅, 프론트엔드 함수 테스팅, 그리고 절대 망가지면 안 되는 상위 10% 핵심 경로에 대한 엔드투엔드 테스팅입니다.

[23:24] 테스팅 과정을 설명하며, 기술 스펙 분석부터 시작해서 테스트 계획 수립, 백엔드/프론트엔드/엔드투엔드 구분에 따른 구현을 진행한다고 합니다. 최종적으로는 깔끔하고 읽기 쉬운 테스트를 만들어 앱의 규칙을 따르고, 중요한 버그를 사용자에게 보고하며 전체 앱의 완전한 테스트 커버리지를 확보하는 것이 목표라고 설명합니다.

[23:53] 테스팅의 중요성에 대해 설명하며, Amazon Kirao가 기능 구현 전에 테스트를 먼저 작성하는 방식을 높이 평가한다고 언급합니다. 이는 개발 과정에서 안전성을 보장하고 프로덕션 배포 전 문제를 미리 발견할 수 있게 해줍니다.

[24:32] DevOps 에이전트와 보안 분석가 에이전트 소개를 시작하며, 앱을 사용자에게 배포하기 위한 필수 요소들을 다룹니다. DevOps 에이전트는 사용자 부하 처리와 안정적인 개발을 위한 자동화를 담당합니다.

코드·의존성 취약점 스캔, API 보안 검토, 알려진 위협 조사 등 보안 모범 사례를 적용해 애플리케이션 전반의 보안성을 점검합니다.

[24:55] DevOps 에이전트의 구체적인 기능을 설명합니다. 코드를 입력으로 받아 Docker 파일 설정, GitHub Actions, CI/CD 파이프라인 등 배포에 필요한 모든 설정을 자동으로 생성해줍니다.

[25:27] DevOps 에이전트의 활용 범위를 개인 선호도에 따라 설명합니다. 개발 초기 단계에서는 로컬 개발 모드를, 프로덕션 준비가 완료되면 프로덕션 배포 시스템을 구축하는 방식으로 단계별 접근을 제안합니다.

[26:30] 프로덕션 고려사항과 로컬 개발 고려사항을 구분하여 설명합니다. 비밀 정보 관리, 배포 스크립트, 테스팅 통합 등 실제 개발에서 필요한 요소들을 다룹니다.

[26:45] 보안 분석가 에이전트를 소개합니다. 바이브 코더들이 자주 받는 보안 결함 비판을 언급하며, 단일 보안 문제가 비즈니스를 하룻밤에 망칠 수 있음을 강조합니다.

[27:20] 모든 분야의 전문가가 될 수 없다는 현실적 한계를 인정하고, 도구를 활용한 보안 관리의 필요성을 설명합니다. 온디맨드 보안 분석가로서의 에이전트 역할을 제시합니다.

[27:30] 보안 분석가 에이전트의 구체적 기능들을 설명합니다. 모범 사례 확인, 웹 취약점 조사, MCP 서버를 통한 앱 검사 등 포괄적인 보안 점검 과정을 다룹니다.

[27:58] 영상 길이를 고려하여 자세한 설명은 생략하고, 다음 영상에서 실제 앱 빌드를 예고합니다. 전체 프롬프트 접근성을 안내하며 API 엔드포인트 보호 등의 내용을 간략히 소개합니다.

에이전트 군단의 강력함을 재확인하고, 다음 영상에서는 이를 단계별로 오케스트레이션해 완전한 SaaS 애플리케이션을 구축하는 과정을 예고합니다.

[28:23] Claude 코드 에이전트에 대한 강한 애정을 표현하며, 올해 최고의 도구 중 하나라고 평가합니다. 분기별로 한 가지씩 훌륭한 도구가 나온다는 개인적 견해를 공유합니다.

[28:47] 다음 영상에서의 계획을 설명합니다. 에이전트들을 단계적 시스템으로 조율하여 원시 아이디어부터 완전한 상용 프로젝트까지 구축하는 과정을 보여줄 예정입니다.

[29:19] YouTube 알고리즘의 어려움을 토로하며, 구독자 5만 명 이하 크리에이터들의 현실적 어려움을 설명합니다. 구독과 알림 설정의 중요성을 강조합니다.

[00:00] Claude Code 에이전트가 최근 출시되었는데

[00:02] 정말 놀라울 정도로 훌륭합니다. 하지만 안타깝게도

[00:05] 지금까지 본 많은 예시들이

[00:07] 별로 좋지 않았습니다.

[00:09] 기본적이고 단순한

[00:11] 프롬프트 말이죠. 예를 들어 '당신은 시니어 백엔드

[00:13] 엔지니어입니다. 백엔드를 만들어 주세요'처럼요.

[00:17] 음, 오늘은 이런 상황을

[00:19] 반지의 제왕처럼 함께 끝내보겠습니다. 왜냐하면

[00:22] 여러분을 위해 제가 만든 8개의 맞춤형 Claude

[00:24] Code 에이전트를 소개할 예정이기 때문입니다.

[00:27] 이것들은 전체 엔드투엔드 SaaS 개발 워크플로를 대체할 수 있습니다.

[00:30] 목표는 전체 기술팀을 대체하는 것입니다.

[00:33] 그래서 우리는

[00:35] 모든 것을 다룰 예정입니다.

[00:36] 프로덕트 매니저부터 DevOps 엔지니어까지

[00:39] 보안 분석가까지 모든 것을 말이죠.

[00:42] 이 에이전트들은 기본적으로 제 기존의

[00:45] 바이브 코딩 프레임워크를 가져와서

[00:47] 추론 머신으로 바꿔줍니다. 그러니까

[00:50] 끝까지 봐주세요. 이 비디오에서

[00:52] 전체 엔드투엔드 AI 개발팀을 복제하는 방법을 보여드릴 테니까요.

[00:55] 이 팀은 24시간 내내, 일주일 내내

[00:57] 여러분을 위해 일할 것입니다.

[01:01] 휴가를 요청하지도 않고

[01:03] 보통은 불평도 하지 않습니다.

[01:06] 이것은 솔로 창업자가 가질 수 있는

[01:09] 가장 불공정한 이점일지도 모릅니다.

[01:12] 자, 이제 시작해보겠습니다.

[01:13] 먼저 간단히 정리해보죠.

[01:15] Claude Code 에이전트란 실제로 무엇일까요?

[01:18] 이것들은 기본적으로 특화된 서브 에이전트로

[01:20] Claude Code 안에서 실행되고

[01:23] 자체적인 맞춤형 시스템 프롬프트, 컨텍스트

[01:26] 윈도우, 그리고 사용할 수 있는

[01:28] 특정 도구들에 접근할 수 있습니다.

[01:30] 이것들의 영향은

[01:33] 기술 천재가 아니어도 매우 기술적인

[01:36] 것들을 코딩할 수 있다는 것입니다.

[01:37] 제 기존의 프롬프팅 시스템을 본 적이 있다면

[01:39] 매우 긴 시스템 프롬프트들을 연결해서

[01:41] 각각의 출력을 가져와서

[01:42] 다음 단계로 넘겨주는 방식이었다는 것을 아실 겁니다.

[01:45] 이 에이전트들을 발견한 것은

[01:47] 정말 게임체인저였습니다. 왜냐하면 이제

[01:50] 어떻게 추론하길 원하는지에 대한

[01:51] 시스템 프롬프트를 제공할 수 있고

[01:53] 에이전트가 필요한 것과 필요하지 않은 것을

[01:55] 알아서 모든 세부사항을 처리할 수 있기 때문입니다.

[01:58] 이 에이전트들은 특정 순서대로

[02:00] 실행되어야 하는데, 이에 대해서는

[02:02] 비디오 후반부에 다루겠습니다.

[02:05] 어쨌든, 이것들은 심각한 불공정한 이점입니다.

[02:08] 만약 이것들을 사용한다면 사용하지 않는

[02:10] 다른 사람들에 비해 우위를 갖게 될 것입니다. 간단명료하게요.

[02:12] 자, 기본부터 시작해서

[02:14] 첫 번째 에이전트를 설정하고 구성하는 방법을

[02:16] 보여드리겠습니다. 그다음에

[02:18] 8개 모두와 구체적인 예시를 통해

[02:20] 어떻게 작동하는지 살펴보겠습니다.

[02:22] 첫 번째로 해야 할 일은

[02:23] 당연히 터미널에서 Claude Code를 여는 것입니다.

[02:25] 이를 위한 두 가지 방법이 있습니다.

[02:27] 첫 번째는 안내된

[02:29] 온보딩 프로세스를 사용하는 것입니다.

[02:31] slash agents를 입력하고 엔터를 누르면

[02:33] CLI로 새 에이전트를 생성할 수 있는

[02:36] 옵션이 나타납니다.

[02:38] 예를 들어 새 에이전트 생성을 클릭하면

[02:41] 이것이 전체 컴퓨터에 있을지

[02:43] 아니면 프로젝트별로 있을지

[02:45] 선택할 수 있습니다.

[02:48] 이 예시에서는 프로젝트별로 하겠습니다.

[02:49] 그런 다음 수동으로 구성하거나

[02:52] 수동으로 설정하거나 Claude Code 헬퍼를 사용할 수 있습니다.

[02:54] 이 예제에서는 Claude Code 헬퍼를 사용해서

[02:57] 작동 방식을 보여드리겠습니다.

[02:59] 엔터를 누르면 가장 먼저 해야 할 일은

[03:01] 이 에이전트를 언제 사용할지 설명하는 것입니다.

[03:03] 여기서는 기본적인 예시를 들겠지만,

[03:05] 설명은 포괄적으로 작성하는 것이 좋습니다.

[03:07] 예를 들어 문제를 디버깅할 때마다

[03:09] 사용하는 에이전트를 만들고 싶다고 해봅시다.

[03:11] 엔터를 누르면 실제로 에이전트가 생성되고

[03:12] 어떤 도구를 사용할지 물어봅니다.

[03:14] 이제 수동 구현 방법을 보여드리겠습니다.

[03:16] 이 과정이 완료되면

[03:18] .claude/agents라는 디렉토리가 생성된 것을

[03:20] 확인할 수 있습니다.

[03:23] 이 디렉토리 안에는

[03:24] 이 프로젝트에서 접근할 수 있는

[03:26] 모든 에이전트가 들어있습니다.

[03:28] 이것이 디버거 에이전트의

[03:30] 실제 모습입니다.

[03:32] 상단에는 이름이 있고,

[03:35] 시스템이 언제 사용해야 하는지에 대한

[03:37] 설명이 있습니다.

[03:39] 코드의 버그를 분석하고 수정할 때마다 사용하죠.

[03:41] 그리고 사용할 색상을 지정하고

[03:43] 어떤 모델을 사용할지 지정합니다.

[03:45] 여기서는 Sonnet을 사용하겠습니다.

[03:47] 이 파일을 살펴보면

[03:49] 명령어를 확인할 수 있습니다.

[03:50] 이 에이전트를 실행할 때마다

[03:52] Claude Code에 제공하는 시스템 프롬프트입니다.

[03:54] 어떤 모습인지 확인할 수 있죠.

[03:56] 에이전트의 핵심 철학은 무엇인가요?

[03:59] 어떤 접근 방식을 취하나요?

[04:01] 어떤 입력을 예상해야 하나요?

[04:04] 어떤 종류의 것들을 디버깅해야 하나요?

[04:05] 어떻게 디버깅을 고려해야 하나요?

[04:07] 전체적인 프로세스는 무엇인가요?

[04:08] 기타 등등 말이죠.

[04:11] 이 에이전트가 접근할 수 있는

[04:12] 특정 도구들도 지정할 수 있습니다.

[04:14] 예를 들어, 디버깅할 때 사용하는

[04:15] 특정 MCP 서버가 있다면

[04:19] 여기서 사용할 수 있습니다.

[04:21] 정말 멋진 부분으로 넘어가기 전에

[04:23] 아주 기본적인 예시를 살펴보겠습니다.

[04:25] 평균을 계산하는

[04:27] Python 파일이 있다고 해봅시다.

[04:30] 작동 방식을 보여주기 위해

[04:31] 일부러 버그를 넣어보겠습니다.

[04:33] 여기 들어가서 실제로 이 스크립트를 실행하면

[04:35] 평균이 20이어야 하는데

[04:38] 실제로는 30이 나오는 것을 볼 수 있습니다.

[04:39] 이런 경우에는 Claude로 가서

[04:40] 다음과 같이 말할 수 있습니다:

[04:42] '디버깅 에이전트를 사용해서

[04:44] Python 파일을 디버그해줘.'

[04:46] 아주 기본적인 예시입니다.

[04:49] 하지만 이제 실제로

[04:50] 앞서 만들었던 특정 에이전트인

[04:52] 이 디버거를 인스턴스화한 것을 볼 수 있습니다.

[04:55] 그래서 이 에이전트는 진행하면서

[04:58] 이 매우 기본적인 버그를 수정하기 위해

[04:59] 우리가 가지고 있는 전체 프로세스를

[05:02] 따라갈 것입니다.

[05:05] 이 결과가 어떻게 생겼는지 살펴봅시다.

[05:06] 이제 실행이 완료된 후에

[05:08] 파일에서 수정 사항을 구현하고 있는 것을

[05:12] 볼 수 있습니다.

[05:14] 스크립트를 실행하면

[05:15] 이제 수정되었음을 볼 수 있습니다.

[05:17] 평균이 30입니다. 평균은 당연히

[05:19] 20이어야 합니다.

[05:23] 30이어야 합니다. 물론 이건 매우 기본적인 예시였습니다.

[05:25] 이제 더 자세한 예시들을 살펴보겠습니다.

[05:27] 제가 준비한 8개의 에이전트를 모두 살펴볼 예정입니다.

[05:29] 네, 이 모든 것들은 동영상 설명란에서 확인하실 수 있습니다.

[05:31] 한 가지 말씀드릴 것은

[05:33] 제가 소개하는 순서가 반드시 실제 사용 순서는 아니라는 점입니다.

[05:35] 전체 end-to-end SaaS 애플리케이션을 구축하는

[05:37] 프로덕션 준비 완료 영상은 이번 주 후반에 공개될 예정입니다.

[05:42] 이 모든 것들을 6-7단계 시스템으로 구성할 계획입니다.

[05:44] 첫 번째로 살펴볼 에이전트는 프로덕트 매니저입니다.

[05:46] 이걸 먼저 다루는 이유는

[05:48] 프로젝트를 처음부터 시작할 때

[05:50] 앱에 대한 추상적인 아이디어를

[05:53] MVP에 들어갈 구체적인 요소들로 번역해야 하기 때문입니다.

[05:54] SaaS 회사에서는 프로덕트 매니저가 이 역할을 담당합니다.

[05:57] 그들은 거의 미니 프로덕트 CEO와 같습니다.

[05:58] 아이디어와 문제, 그리고 팀 내 리소스를 가지고

[06:01] 그 문제를 해결하고 제품을 출시해야 합니다.

[06:03] 이 에이전트는 어떤 면에서는 방어 메커니즘과 같습니다.

[06:06] MVP에 무엇이 들어가야 한다고 생각하는

[06:09] 당신의 편견을 극복할 수 있게 해줄 것입니다.

[06:12] 대신 앱이 해결하려는 실제 문제와

[06:13] 특정 기능들이 그 문제들을 어떻게 해결할지에 집중할 것입니다.

[06:15] 앱에 대한 일반적인 아이디어를 입력하면

[06:18] 상세한 내용들을 얻을 수 있습니다.

[06:20] 한번 살펴보겠습니다.

[06:22] 먼저 에이전트의 설정부분입니다.

[06:24] 에이전트가 무엇인지, 페르소나가 무엇인지,

[06:26] 문제 해결 접근 방식이 무엇인지 알려주고 있습니다.

[06:28] MVP를 위해 구축할 각 기능에 대해

[06:31] 생성할 요약 보고서에 대해 설명하고 있습니다.

[06:33] 원하는 정확한 형식이 무엇인지,

[06:35] 기능, 사용자 스토리,

[06:36] 수락 기준(즉, 이 작업을 완료했다고 간주하기 위해

[06:39] 무엇이 참이어야 하는지),

[06:41] 그리고 다른 여러 기능적, 비기능적 요구사항들이 있습니다.

[06:43] 이 예시에서는

[06:44] 제게 요청된 프로젝트를 구축할 예정입니다.

[06:47] 이 경우 특별히 이 에이전트를 사용하도록 지시할 것입니다.

[06:49] 에이전트가 지능적으로 선택할 수도 있지만,

[06:52] 이번에는 어떤 에이전트를 사용할지 직접 지정하겠습니다.

[06:54] 다음 앱 아이디어를 바탕으로

[06:56] 프로덕트 매니저 에이전트를 사용한다고 말할 것입니다.

[06:59] 이 앱은 사용자가 자신의 시즌 컬러 타입에 맞는

[07:01] 제품을 쇼핑하는 데 도움을 주는 크롬 확장 프로그램입니다.

[07:04] 참고로, 시즌 컬러 분석은

[07:06] 패션 내 하위 분야로서

[07:08] 특정 의복 색상이 피부톤,

[07:10] 헤어 컬러, 눈 색깔 등을 기반으로

[07:13] 수학적으로 더 잘 어울린다고 명시합니다.

[07:14] 그리고 그 특정 사항의 수학적 원리를

[07:16] 분석하는 두 개의 자료를 제공했습니다.

[07:18] 이제 우리가 만든

[07:20] 프로덕트 매니저 에이전트가

[07:22] 작동하는 모습을 볼 수 있습니다.

[07:25] 이 에이전트는 지능적으로 에이전트를 선택할 수 있지만

[07:26] 이번 경우에는 어떤 에이전트를 사용할지 알려주겠습니다.

[07:28] 다음 앱 아이디어를 바탕으로

[07:30] 프로덕트 매니저 에이전트를 사용하라고 말할 것입니다.

[07:31] 앱은 사용자들이 자신의 시즌 컬러 타입에 맞는

[07:33] 제품을 쇼핑할 수 있도록 돕는 크롬 확장 프로그램입니다.

[07:35] 참고로, 시즌 컬러 분석은 패션 내 하위 분야입니다.

[07:37] 특정 의복 색상이

[07:38] 피부톤, 헤어 컬러,

[07:40] 눈 색깔 등을 기반으로

[07:43] 수학적으로 더 잘 어울린다고 명시합니다.

[07:45] 그리고 그 특정 내용의 수학적 원리를

[07:47] 분석하는 두 개의 자료를 제공합니다.

[07:49] 이제 우리가 만든

[07:51] 프로덕트 매니저 에이전트를 볼 수 있습니다.

[07:53] 생성되고 있으며

[07:55] 우리가 접근할 수 있는 특정 도구들을 사용하기 시작했습니다.

[07:58] 잠시 후 다시 돌아와서

[08:01] 이 프로덕트 매니저 에이전트가

[08:03] 생성된 것이 작동하기 시작하고 우리가 접근할 수 있는

[08:06] 특정 도구들을 사용하기 시작합니다.

[08:08] 작업이 완료되면 잠시 후 다시 돌아와서

[08:10] 결과를 살펴보겠습니다.

[08:12] 좋습니다, 방금 실행이 완료되었네요.

[08:13] 실제로 약 2분 정도 걸렸는데, 조금 길었지만

[08:15] 어떤 결과가 나왔는지 살펴보겠습니다.

[08:16] 요청했던 대로, 먼저 이 앱에 대한

[08:19] 엘리베이터 피치가 나왔습니다.

[08:21] 문제 정의서도 얻었습니다.

[08:24] 이제 이 결과물을 검토해서 실제로 당신의 앱이

[08:26] 무엇을 해야 하는지에 맞게 조정해야 합니다.

[08:28] 왜냐하면 다른 모든 단계가 이것을 기반으로

[08:30] 구축될 것이기 때문입니다.

[08:33] 실제 문제 정의는 무엇인가요?

[08:34] 대부분의 사람들이 이것을 식별하는 데 어려움을 겪는 이유는

[08:36] 그것에 대해 전혀 모르기 때문이고,

[08:38] 이로 인해 잘못된 구매 결정으로 이어집니다.

[08:40] 실제로 당신에게 잘 어울리지 않는 옷에

[08:42] 돈을 낭비하게 되고,

[08:43] 일반적으로 좋은 옷을 입거나

[08:45] 멋진 것을 입는 것에 대해 좋은 기분을

[08:48] 느끼지 못할 수도 있습니다.

[08:50] 그럼 이제 이 타겟 오디언스의

[08:52] 주요 페르소나들은 무엇인지 살펴보겠습니다.

[08:54] 인구통계학적 분석은 어떻게 되나요?

[08:55] 이것의 고유한 판매 포인트는 무엇인가요?

[08:58] 구체적으로 이것의 경우,

[08:59] 실제로 이런 것은 시장에 존재하지 않습니다.

[09:01] 분석을 해주는 사람들은 많지만

[09:03] 그 분석을 통해 쇼핑을 가능하게 하는

[09:05] 특별한 서비스는 없습니다.

[09:08] 시스템에 요청한 대로,

[09:09] 사용자 페르소나와 고통점들을 살펴보기 시작합니다.

[09:11] 그리고 실제 핵심 사용자 플로우까지

[09:14] 내려가게 됩니다.

[09:15] 이것이 중요한 이유는 실제로

[09:16] 구축하기 시작할 기반이 되기 때문입니다.

[09:19] 예를 들어, 첫 번째 플로우를 세분화합니다.

[09:20] 이 확장프로그램을 실제로 다운로드하고

[09:22] 설치하고 첫 온보딩 단계를 거치는 것이

[09:24] 어떻게 보이는지 살펴봅니다.

[09:26] 그다음에는 실제로 이것으로

[09:28] 쇼핑을 할 때 어떻게 보이는지,

[09:30] 브라우저에서 그 상호작용이

[09:31] 어떻게 보일지 살펴봅니다.

[09:33] 심지어 위시리스트 생성, 다양한 색상 조정과 같은

[09:36] 보조적이거나 3차적인 사용자 플로우도 있습니다.

[09:38] 기능 스토리들, 그것들의 승인 기준,

[09:40] 진행 표시기와 같이 우리가 원할 수 있는

[09:42] 중요한 고려사항들,

[09:44] 그리고 다른 많은 훌륭한 것들까지 다룹니다.

[09:46] 이것들에 대해서는 자세히 다루지 않겠습니다

[09:49] 왜냐하면 다음 주 목요일 영상에서

[09:50] 이것에 대해 살펴볼 예정이기 때문입니다.

[09:51] 이제 다음에 살펴볼 에이전트는

[09:53] UX/UI 디자이너입니다.

[09:54] 실제로 제가 만든 에이전트들 중에서

[09:57] 가장 좋아하는 것 중 하나입니다.

[09:59] 왜 그렇게 말하는 걸까요?

[10:01] 훌륭한 앱들이 훌륭하게 느껴지는 이유가 있습니다.

[10:03] 그것은 매우 재능있는 누군가가 사용자가

[10:06] 어떻게 이것과 실제로 상호작용해야 하는지에 대해

[10:08] 문제를 해결하기 위해 많은 시간을 들여 생각했기 때문입니다.

[10:12] 그래서 이 에이전트는 두 가지를 확실히 하는데 도움을 줍니다.

[10:14] 첫 번째, 앱이 멋지게 보이도록 하는 것이고,

[10:16] 두 번째는 설계 방식과

[10:18] 사용자와의 상호작용 방식을 통해

[10:20] 실제로 목표하는 바를

[10:22] 달성하도록 하는 것입니다.

[10:24] 사실, 최종 사용자의 신뢰를 잃는

[10:26] 가장 좋은 방법은

[10:28] 형편없고 어설픈 경험을 제공하는 것입니다.

[10:33] 조잡하고 불안정한 경험을 제공하는 것입니다.

[10:36] 사용자들을 기분 나쁘게 만드는 경험 말이죠.

[10:39] 그런 걸 피해야겠죠. 다시 말하지만,

[10:42] 이 에이전트는 우리가 경험과

[10:44] 시니어 프로덕트 디자이너의 전문성을 주입하고

[10:48] 앱에 최종적인 완성도를 제공할 수 있게 해줍니다.

[10:50] 이 에이전트가 하는 일은

[10:52] 결과물을 받아서 처리하는 것입니다.

[10:55] 우리가 방금 살펴본

[10:56] 프로덕트 매니저의 결과물을 받아서 처리합니다.

[10:59] 그래서 하는 일은

[11:01] 우리가 누구에게 판매하고 이 앱이

[11:03] 무엇을 달성하려고 하는지 고려합니다.

[11:05] 그런 다음 그것을 일관성 있는 디자인

[11:08] 철학으로 구축합니다. 그래서 이런

[11:10] 포괄적인 원칙들로 시작하죠. UI를 위한

[11:12] 디자인 철학, 핵심 UX 원칙들 같은 것들

[11:15] 모든 기능이 준수해야 하는 원칙들을 말이에요.

[11:17] 하지만 그다음에는 실제로 들어가서

[11:19] 포괄적인 디자인 시스템을 구축해 줍니다.

[11:22] 이런 것들이 색채 이론,

[11:24] 타이포그래피 설정,

[11:26] 시스템의 간격과 레이아웃이 어떻게 될지,

[11:28] 특정 컴포넌트들과 이런 컴포넌트들의

[11:30] 시각적 명세,

[11:32] 이 컴포넌트들과 어떻게 상호작용하는지,

[11:35] 이런 컴포넌트들을 어떻게 사용해야 하는지,

[11:37] 프로덕션에서 어떻게 사용해야 하는지를 다룹니다.

[11:39] 왜냐하면 다시 말하지만 더

[11:41] 확립된 SaaS 회사에서는

[11:43] 프로덕트 디자이너나 UX 전문가가 있어서

[11:45] 프론트엔드 엔지니어가 구현하는 시스템을

[11:48] 구축하죠. 그래서

[11:49] 이 단계에서 우리가 모방하려고 하는 것이

[11:51] 바로 이것입니다. 그래서 이 프롬프트의 마지막 부분에서는

[11:54] 당신이 이 프로덕트 매니저 결과물을 통해

[11:56] 기능별로 살펴봐야 한다고 말합니다.

[11:58] 제가 곧 주려는

[12:00] 프로덕트 매니저 결과물을 받아서 이것이 어떻게

[12:03] 보여야 하고 어떻게

[12:05] 작동해야 하는지에 대한 전체 시스템을 구축해야 합니다.

[12:07] 이 안에는 정말 멋진 것들이 많이 있습니다.

[12:10] 이것은 간단할 겁니다.

[12:11] 우리 프로젝트

[12:14] 문서 디렉터리에서 찾은

[12:15] 결과물을 기반으로 UX 디자인 에이전트를 실행합니다.

[12:18] 정말 멋진 점 중 하나는

[12:19] 이것이 에이전트 기반 시스템이라는 것입니다.

[12:22] 이 시스템은 살펴보면서

[12:24] 무언가를 만들 때, 이제

[12:26] 돌아가서 할 일 목록을

[12:28] 업데이트해야 한다는 것을 깨달으면 그렇게 할 것입니다.

[12:31] 이는 더 정적인 프롬프트 기반 시스템에 비해

[12:33] 엄청난 개선입니다.

[12:36] 좋습니다. 이제 이것이 완료되면

[12:37] 포괄적인 UI UX 디자인 시스템을 갖게 되고

[12:41] 이것이 어떤 모습인지

[12:42] 살펴볼 수 있습니다. 전반적인 디자인

[12:45] 철학, 전체 컬러 시스템,

[12:48] 간격과 레이아웃이 있습니다.

[12:50] 앞서 이야기했던 모든 것들 말이에요.

[12:52] 그리고 점점 더 깊이

[12:53] 들어가면서 실제 사용자

[12:56] 여정 매핑을 보기 시작합니다. 그리고 화면별

[12:59] 명세를 얻습니다. 예를 들어

[13:00] 온보딩 화면에서 시각적 레이아웃이 무엇인지,

[13:03] 사용자가 볼 실제

[13:05] 콘텐츠 계층 구조가 무엇인지,

[13:08] 어떤 타입의 애니메이션이 있을지,

[13:10] 있다면 어떤 애니메이션이 적용될지를 다룹니다.

[13:12] 컬러 시즌 평가에서도 마찬가지입니다.

[13:15] 레이아웃이 무엇인지, 모든 것이

[13:17] 어떻게 흘러갈지를 다룹니다. 이 모든 것이

[13:20] 결국 우리의

[13:22] 프론트엔드 엔지니어링 에이전트에게 전달될 것입니다. 지금

[13:25] 이게 실행되는 동안 저는 DevOps 엔지니어도 백그라운드에서 돌렸습니다.

[13:29] 그래서 이게 하는 일은 이 첫 번째 범위에서

[13:31] 로컬 개발의 초기 단계에 있을 때

[13:35] 기본적으로 전체 프로젝트를

[13:37] 구성해주고 설정해줍니다.

[13:39] 모든 린트 파일들이 설정되고

[13:42] Babel 설정, Docker 파일들

[13:44] 이걸 실제로 실행하기 위해

[13:47] 필요한 모든 것들이 기본적으로

[13:48] 준비되죠, 맞죠?

[13:51] 심지어 매니페스트 파일까지

[13:52] 만들어줬는데, 이건

[13:54] 크롬 익스텐션에 특별히 필요한 거예요.

[13:56] 그리고 이게 어떻게 보이는지

[13:58] 여기서 볼 수 있어요. 정말 탄탄합니다.

[14:01] 이제 DevOps 에이전트를 실행하기 전에

[14:04] 마지막 계획 에이전트인

[14:07] 아키텍처 에이전트를 실행했습니다.

[14:10] 이 에이전트가 하는 일은

[14:12] 지금까지 만든 모든 것들을 살펴보는 거예요.

[14:15] 프로덕트 매니저의 모든 결과물

[14:17] UX UI 에이전트의 모든 결과물을 가져와서

[14:20] 그 모든 것들과 앱에 대한 이해

[14:22] 그리고 앱이 해야 할 일을 바탕으로

[14:24] 상세한 시스템 아키텍처를

[14:26] 구축해줍니다. 이게 무슨 뜻이냐면?

[14:28] 기본적으로 모든 시스템

[14:31] 요구사항에 대한

[14:32] 종합적인 분석을 얻게 됩니다.

[14:35] 예를 들어, 핵심 기능을

[14:37] 어떻게 세분화할 수 있을까요?

[14:39] 이를 구동하기 위해 어떤 기술 스택이

[14:41] 필요할까요? 데이터 아키텍처는

[14:43] 어떻게 생겨야 할까요?

[14:45] 이것과 상호작용하기 위해

[14:47] API는 어떻게 설계되어야 할까요?

[14:48] 주요 보안 및 성능 고려사항은

[14:50] 무엇일까요? 어떤 위험이 있을까요?

[14:54] 기술 스택의 세부사항은

[14:56] 실제로 어떻게 생겨야 할까요?

[14:58] 우리의 프론트엔드 프레임워크, 백엔드

[15:00] 프레임워크는 무엇일까요? 컨텍스트와

[15:02] 상태는 어떻게 관리할까요?

[15:04] 이런 모든 종류의 것들이죠.

[15:05] 시스템 내에서 컴포넌트들이

[15:08] 어떻게 작동할 것인가? 데이터베이스와

[15:10] 데이터 모델들이 실제로

[15:12] 어떻게 생겨야 하는가?

[15:14] 이 모든 걸 살펴보고 그 결과물이

[15:16] 어떻게 보이는지 여기서 볼 수 있어요.

[15:18] 예시로 이 일부를

[15:20] 확대해보면, 이 크롬 익스텐션을 위해

[15:21] 필요한 주요 아키텍처 결정사항들은

[15:22] 무엇일까요? 음, 우리는

[15:24] 크롬 익스텐션 매니페스트가 필요하고

[15:27] 조금 전에 봤던 거죠.

[15:28] 고성능을 보장해야 하는데

[15:30] 이 모든 게 실제로

[15:32] 사용자의 브라우저에서 실행되기 때문이에요.

[15:34] 이미지 처리를 위해

[15:37] 구글의 웹 워커를 사용할 거고

[15:39] 이벤트 기반 아키텍처를 사용하며

[15:40] 심지어 몇 가지 문서화도 있어요.

[15:43] 백엔드 엔지니어링 에이전트를 위한

[15:45] 문서들을 명시하고 있어요.

[15:48] 이들이 알아야 할 핵심 엔드포인트들과

[15:51] 데이터 타입들이

[15:52] 어떻게 생겨야 하는지 말이죠.

[15:54] 그래서 매우 상세한

[15:57] 전체적인 시스템 문서입니다.

[15:59] 그래서 우리가 이 시스템

[16:01] 아키텍처 에이전트를 실행하는 이유는

[16:03] 단순히 당신이 혼자 창업하는

[16:05] 기술적 솔루션을 만들어낼 수 있습니다. 세상에서 가장 기술적인 사람이 아니어도 말이죠.

[16:10] 왜냐하면 솔로 창업자나

[16:12] 단순히 자신만의 멋진 것을 만들려는

[16:14] 취미 개발자, 즉 팅커러에게

[16:16] 가장 큰 병목 중 하나는

[16:17] 정말 야심찬 프로젝트는 있지만

[16:19] 기술적 지식이 부족하다는 것입니다.

[16:21] 제가 말하는 것은

[16:22] 여러분이 모를 수도 있는 많은 도구들과 패턴, 시스템들이 있는데

[16:26] 이것들이 여러분이 달성하려는 목표를

[16:28] 훨씬 더 쉽고 지속가능하게

[16:30] 달성하는 데 도움이 될 것입니다.

[16:33] 잘못된 데이터베이스나

[16:34] 백엔드 프레임워크를 선택하거나

[16:37] 그런 것들은 나중에 영혼을 갉아먹을 수 있거든요.

[16:39] 나중에 다시 해야 한다는 걸 깨달았을 때 말이죠.

[16:42] 그래서 이 에이전트를 CTO 같은 존재로 생각해보세요.

[16:44] 중요한 기초적인 결정들을 내립니다.

[16:47] 우리가 에이전트에게 제품 계획을 주면

[16:49] 완전히 상세한 기술 명세서를

[16:51] 돌려받습니다. 그래서 시스템이

[16:54] 그것을 구현하기 위해 어떤 모습이어야 하는지

[16:56] 알 수 있죠.

[16:58] 기술 스택은 뭔지, 데이터베이스

[16:59] 스키마는 뭔지, API 계약은

[17:01] 어떻게 되는지, 모든 것 말이죠.

[17:03] 만약 우연히 하룻밤 사이에 10만 명의 사용자로

[17:05] 확장되면 어떻게 할까요?

[17:07] Product Hunt에서 대박이 나서 말이죠.

[17:09] 그런 상황에서 우리는 어떻게 해야 할까요?

[17:11] 그 부하를 어떻게 처리할까요?

[17:13] 우리는 이것이 그런 모든 고려사항들을

[17:15] 생각해보기를 원합니다.

[17:18] 다음 목록에는 시니어 프론트엔드

[17:20] 엔지니어링 에이전트가 있습니다. 이것이 있는 이유는

[17:24] UX와 UI 프레임워크가 준비되고

[17:27] 백엔드가 실제로 설정되어

[17:28] 데이터베이스가 어떻게 될지

[17:30] 알고 모든 비즈니스 로직이 구축되면

[17:32] 이 두 세계를 합쳐서

[17:34] 사용자가 상호작용할 수 있는

[17:36] 기능적인 앱을 만드는

[17:38] 프론트엔드를 구축해야 하기 때문입니다.

[17:41] 추상적인 UX와 UI 이론은 훌륭하지만

[17:44] 결국 우리는 그것을 빠르고 성능이 좋은

[17:46] 프론트엔드로 번역해야 합니다.

[17:48] 그래서 우리가 할 일은

[17:50] UX/UI 문서와 백엔드

[17:52] 문서, 지금까지 가지고 있는

[17:54] 거의 모든 것을 제공해서

[17:57] 재사용 가능한 컴포넌트 시스템을 구축하고

[17:59] 앱의 상태 관리 시스템이

[18:01] 어떻게 생겼는지, 이제 UX 부분에서

[18:03] 이야기한 실제 상호작용성을 구축하는 것입니다.

[18:05] 그 모든 것들이 이제 살아나야 합니다.

[18:07] 그리고 앞서 말했듯이

[18:09] 이 영상은 완전한 앱 빌드가 아닙니다.

[18:11] 그건 나중에 올 예정입니다.

[18:12] 그래서 지금은 이 문서 안에서

[18:14] 제가 여러분을 위해 구축한

[18:17] 에이전트 구성들 중 일부를

[18:19] 살펴볼 것입니다.

[18:22] 말했듯이 우리 프론트엔드 엔지니어는

[18:24] 기술 명세서, API, 디자인 시스템,

[18:27] 그 모든 것을 프로덕션 준비가 된

[18:30] 사용자 인터페이스로 변환할 것입니다.

[18:32] 그러면 어떻게 그걸 해낼까요?

[18:34] 먼저 예상해야 하는 입력값들을

[18:36] 알려줄 것인데, 이것들은 이제

[18:38] 이전 단계들에서 구축한 것들입니다.

[18:40] 다만 백엔드 엔지니어는 예외인데

[18:42] 이것은 이 다음에 살펴볼 것입니다.

[18:44] 실제 구현에 대한 가이드라인을 제공합니다.

[18:45] 먼저 이 구현 방법에 접근하는 방식을 살펴보겠습니다.

[18:48] 모든 것을 단계별로 분석해야 합니다.

[18:50] 사용자 스토리와 백엔드를 살펴보고

[18:52] 모든 요구사항을 단계적으로 분해해야 합니다.

[18:55] 단계별로 나누어 처리해야 합니다.

[18:57] 실제로 디자인 시스템을 구현해야 합니다.

[18:59] 예를 들어 Tailwind를 사용한다면

[19:01] 토큰 기반 디자인 시스템을 만들고

[19:03] 실제로 시스템을 구축해야 합니다

[19:05] 백엔드에서 필요한 데이터를 가져와서

[19:07] 프론트엔드에서 필요한 곳에

[19:09] 그 데이터를 지능적으로 저장해야 합니다.

[19:12] 실제로 핵심 사용자 경험을 구축해야 합니다.

[19:15] 성능이 잘 나오도록 만들어야 하고

[19:17] 빠르고 반응성이 좋아야 하며

[19:19] 이상한 현상이 발생하지 않아야 합니다.

[19:21] 그리고 실제로 어떻게 구성해야 하는지에 대한

[19:23] 다른 가이드라인들을 제공합니다.

[19:25] 어떻게 코딩해야 하는지, 그리고 완료되면

[19:28] 포괄적인 문서를 반환합니다.

[19:30] 그래야 실제로 무엇이 구축되었는지 알 수 있습니다.

[19:32] 우리가 확인할 수 있고

[19:34] 어떻게 작동하는지 이해할 수 있습니다.

[19:36] 이제 잠깐 다시 돌아가서

[19:38] 프론트엔드는 백엔드에서 구축하는 것에

[19:41] 매우 의존적이라는 점을 말씀드리겠습니다.

[19:43] 이것의 실제 비즈니스 로직이 무엇인가요?

[19:45] 백엔드가 앱의 핵심 경험을

[19:47] 실제로 구동하는 것이기 때문입니다.

[19:49] 그래서 매우 잘 만들어져야 합니다.

[19:51] 실제로 바이브 코딩이 사람들에게

[19:54] 보통 보여지는 방식과는 반대로

[19:56] 매우 시각적인 것입니다.

[19:58] 그래서 우리는 비즈니스 로직이

[20:00] 내부에서 실제로 이것을 구동할지에 대해 생각하지 않는 경향이 있습니다.

[20:04] 왜냐하면 다시 말하지만 백엔드는

[20:07] 앱의 진짜 워크호스입니다. 모든 무거운 작업을 수행합니다.

[20:11] 핵심 로직을 구축해서 실제로

[20:14] 이것이 켜지고 작동하도록 합니다.

[20:16] 그래서 우리가 이 부분에서 구축하려는 것은

[20:18] 아키텍처 계획과 기능 요구사항을

[20:20] 전달하는 것입니다.

[20:22] 그리고 반대편에서는

[20:24] 모든 API 엔드포인트, 데이터베이스 스키마

[20:28] 비즈니스 로직, 인증 및

[20:30] 요청에 대한 권한 부여를

[20:32] 원합니다. 이 모든 것들을

[20:34] 실제로 프론트엔드를 구축하기 전에

[20:36] 원합니다. 그리고 여기서 그 프롬프트를 볼 수 있습니다.

[20:39] 다시 말하지만, 우리는 스펙 기반 개발을 실행하고 있습니다.

[20:42] 이는 기술 문서와

[20:43] 우리가 가진 스토리를 가져와서

[20:45] 그것으로부터 백엔드를 구축할 것이라는 의미입니다.

[20:48] 그래서 다시 말하지만, 입력으로

[20:50] 무엇을 기대해야 하는지 말하고 있습니다.

[20:53] 지금까지 완료한 모든

[20:55] 기술 문서를 가지게 될 것입니다.

[20:58] 그리고 거기서부터 우리는 단지

[21:00] 어떻게 작업을 제대로 해야 하는지 말하고 있습니다.

[21:02] 예를 들어, 데이터베이스 마이그레이션을 어떻게 처리해야

[21:04] 문제가 생기지 않고

[21:05] 키보드에 머리를 박고 싶어하지 않을까요?

[21:07] API를 어떻게 개발할 것인가?

[21:09] 외부 시스템과 어떻게 통합할 것인가?

[21:11] 이 앱의 핵심 비즈니스 로직이

[21:13] 실제로 어떻게 보여야 하는가?

[21:16] 어떻게 생겼을까요? 백엔드를 성능과 확장성 측면에서

[21:18] 어떻게 최적화할 수 있을까요? 이 모든 것들이

[21:21] 바로 우리가 고려해야 할 요소들입니다.

[21:23] 그리고 다시 한번, 권장하는 구현 접근법을 제공합니다.

[21:25] 스펙을 분석하고, 데이터베이스를 계획하고,

[21:28] 마이그레이션을 실행하고, 로직을 구축하고,

[21:29] 보안 측면에서 견고하게 만들고,

[21:31] 성능을 보장하고, 당연히 모든 엣지 케이스들을

[21:37] 처리하도록 하는 것입니다.

[21:39] 그리고 다른 모든 것들과 마찬가지로,

[21:40] 우리가 원하는 출력 형태를 알려줍니다.

[21:43] 지금까지는 모든 것이 훌륭했습니다.

[21:44] 앱을 설계했고, 프론트엔드 컴포넌트를 구축했고,

[21:46] 백엔드 컴포넌트도 구축했습니다.

[21:47] 하지만 실제 프로덕션에서 작동하는 것을

[21:50] 구축할 수 있게 해주는 한 가지는

[21:51] 적절한 QA와 테스팅 환경 설정이

[21:53] 필요하다는 것입니다.

[21:54] 대부분의 바이브 코더들은 이것에 대해

[21:56] 생각조차 하지 않습니다. 왜냐하면

[21:59] 우리가 바라는 해피패스에만 의존할 수는 없기 때문입니다.

[22:02] 특히 충분한 테스트 없이 바이브 코딩을 한다면,

[22:05] 이전에 작동했던 것들을 망가뜨릴 수도 있습니다.

[22:07] 그리고 편집하는 모든 파일을

[22:10] 완벽하게 파악하지 못한다면,

[22:12] 그것은 가능성이 아니라

[22:14] 필연성입니다.

[22:16] 그래서 그냥 계획해두는 것이 필요합니다.

[22:18] 하지만 여전히 고속으로

[22:20] 두려움 없이 구축하고 싶습니다.

[22:23] 그리고 그것이 바로 이것이 도와주려는 것입니다.

[22:28] 이것과 우리가 본 다른 것들의

[22:30] 큰 차이점 중 하나는

[22:32] 훨씬 더 컨텍스트 의존적이라는 것입니다.

[22:34] 즉, 요청되는 내용에 대해 실제로 의미가 있는

[22:37] 시스템 프롬프트의 부분들만

[22:39] 실행하고 싶었습니다.

[22:42] 이상적인 세계에서는 아마도 이것을

[22:44] 백엔드 테스팅 에이전트 대 프론트엔드 테스팅 에이전트

[22:47] 또는 엔드투엔드 테스팅 에이전트로

[22:49] 나눌 수 있을 것입니다.

[22:51] 하지만 저는 이 올인원을 사용하고 있습니다.

[22:53] 토큰 효율적이지는 않을지 모르지만, 제 역할은 합니다.

[22:58] 세 가지 특정 컨텍스트 중 하나에서

[23:00] 호출될 것이라고 알려주고 있습니다.

[23:02] 고유한 고려사항이 있는

[23:03] 백엔드 함수를 테스트하거나,

[23:05] 고유한 고려사항이 있는

[23:06] 프론트엔드 함수를 테스트하거나,

[23:09] 엔드투엔드 테스팅을 실행할 것입니다.

[23:11] 즉, 절대 망가지면 안 되는

[23:12] 상위 10% 핵심 경로를 식별하고,

[23:14] 그 기능들에 대해서는

[23:16] 견고한 엔드투엔드 테스팅을

[23:18] 수행할 것입니다.

[23:21] 그렇다면 어떻게 이것을 할까요?

[23:24] 음, 기술 스펙을 분석하고,

[23:26] 테스트를 계획하고,

[23:28] 백엔드인지, 프론트엔드인지,

[23:29] 엔드투엔드인지에 따라

[23:31] 테스트를 구현해야 합니다.

[23:34] 그리고 우리의 테스트들이

[23:36] 깔끔하고, 읽기 쉽고,

[23:38] 앱에서 이미 설정한 규칙을 따르고

[23:40] 모든 중요한 버그들이

[23:42] 사용자인 우리에게 실제로 보고되고

[23:44] 전체 앱에 대한 완전한 테스트 커버리지를

[23:46] 갖도록 하는 것입니다.

[23:53] 앱 전체에 대한 이야기입니다. 그런데 여기서 테스팅에 대해 잠깐 이야기하자면,

[23:56] 제가 처음 Amazon의 Kirao를 사용하기 시작했을 때

[23:57] 정말 감사했던 부분 중 하나는

[24:00] 무엇보다도 기능을 구현하기 전에

[24:02] 테스트를 먼저 작성한다는 점이었습니다.

[24:05] 그리고 이건 명백히 매우 안전하고

[24:07] 견고한 개발 방식입니다. 왜냐하면

[24:09] 개발 과정의 모든 단계에서

[24:11] 이 기능이 테스트되고

[24:13] 제대로 동작한다는 것을 보장하기 때문입니다.

[24:15] 그리고 앱을 빌드해서 프로덕션에 배포할 때도

[24:17] 배포하기 전에 모든 테스트를 실행해서

[24:18] 자신이 실수를 하지 않았는지

[24:20] 확인할 수 있습니다.

[24:22] 만약 이 과정을 생략한다면,

[24:25] 앞으로 겪게 될 모든 고통은

[24:26] 본인의 몫입니다.

[24:29] 이제 마지막 두 에이전트도 이 과정에서 매우 중요합니다.

[24:32] DevOps 에이전트와

[24:33] 보안 분석가 에이전트가 있습니다.

[24:35] DevOps 에이전트는 이미 결과를 보여드렸으니

[24:38] 간단히 설명하겠습니다.

[24:39] 결국 우리는 사람들이 우리 앱을

[24:41] 사용할 수 있도록 해야 합니다.

[24:44] 그래서 사람들이 우리 시스템과 상호작용할 때

[24:46] 발생하는 부하를 처리할 수 있어야 하고,

[24:48] 동시에 기존 시스템을 망가뜨리지 않으면서도

[24:51] 빠르게 개발할 수 있어야 합니다.

[24:53] 이 에이전트는 이 모든 것을 최대한 자동화하기 위한 것입니다.

[24:55] 기본적으로 우리가 할 일은

[24:58] 우리가 작성한 코드와

[24:58] 구축한 모든 것을 에이전트에게 제공하면

[25:00] 이것을 배포하기 위해 필요한

[25:03] 모든 설정을 되돌려 줍니다.

[25:04] 여기에는 Docker 파일 설정,

[25:07] GitHub Actions, 그리고 실제

[25:09] 통합 및 배포 파이프라인이 포함됩니다.

[25:13] 배포를 시도하기 전에

[25:15] 자동으로 테스트를 실행하고

[25:17] 실패했을 때 알려주며

[25:20] 실패 시 배포하지 않는 파이프라인입니다.

[25:21] 이 모든 것들이 매우 중요하고

[25:23] 이것이 바로 이 에이전트가 하는 일입니다.

[25:25] QA 에이전트와 마찬가지로

[25:27] 이 에이전트를 호출할 다양한 범위가 있습니다.

[25:30] 그리고 이건 개인적인 선호입니다.

[25:32] 개발 초기 단계에서

[25:34] 혼자 개발하거나 아주 작은 프로젝트일 때는

[25:36] 많은 것들을 로컬에서 하는 것을 선호합니다.

[25:38] 그래서 백엔드와 프론트엔드를

[25:39] 구축하기 시작하기 전에

[25:42] 실제로 Docker에서 실행되고

[25:44] 내 로컬 머신에서 실행되는지

[25:46] 확인하고 싶습니다.

[25:49] 만약 그런 단계라면

[25:50] 로컬 개발 모드를 호출할 것입니다.

[25:52] 하지만 5단계를 넘어서서

[25:54] 실제로 이것을 실행하고

[25:55] 프로덕션으로 보낼 준비가 되면

[25:57] 프로덕션 배포 시스템을

[25:59] 구축할 것입니다.

[26:01] 다시 말하지만, 우리는 어떤 입력을 받을지,

[26:04] 어떤 다양한 기술 스택이 있고

[26:06] 준수해야 할지,

[26:08] 로컬 개발 환경이

[26:10] 실제로 어떤 모습이어야 하는지,

[26:11] 로컬 개발을 위한 우리의 원칙이 무엇인지

[26:14] (이는 다를 수 있습니다)를 알려주고 있습니다.

[26:17] 예를 들어 우리는 프로덕션에 최적화하는 것보다

[26:20] 속도를 위해 최적화하기를

[26:22] 원할 수 있습니다.

[26:24] 그래서

[26:26] 프로덕션에 매우 최적화되는 것 대신에

[26:30] 우리는 계속해서 이런 프로덕션 고려사항들과

[26:32] 로컬 개발 고려사항들을 계속 설명해 나갑니다.

[26:34] 비밀 정보는 어떻게 관리해야 할까요?

[26:37] 배포 스크립트는 어떤 모습이 될까요?

[26:39] 어떻게 다시 테스팅을 통합할 것인가?

[26:40] 그리고 모든 좋은 것들 말이죠.

[26:42] 자, 마지막이지만 절대 가볍지 않은 것은

[26:45] 우리의 보안 분석가입니다.

[26:48] 솔직히 바이브 코더들에게 던져지는

[26:51] 가장 큰 비판 중 하나는

[26:54] 앱들이 보안 결함을 가지는 경향이 있다는 것입니다.

[26:56] 우리가 마지막으로 하고 싶지 않은 일은

[26:59] 실제로 사람들을 돕기 위한

[27:01] 무언가를 만들려고 하다가

[27:02] 정말 바보같은 실수를 해서

[27:05] 망쳐버리는 것입니다.

[27:07] 왜냐하면 단 하나의 보안 문제가

[27:10] 하룻밤 사이에 당신의 비즈니스를 망칠 수 있기 때문입니다.

[27:12] 최근에 정말 많은

[27:13] 유명한 바이브코딩 앱 사례들이 있었습니다.

[27:16] 그리고 솔직히 말하면, 우리가 하려는

[27:20] 다른 모든 일 위에 보안 전문가가 될 수는 없습니다.

[27:23] 그래서 우리는 이런 도구들을

[27:25] 최대한 잘 활용해야 합니다.

[27:26] 이 에이전트는 우리의 온디맨드

[27:30] 보안 분석가가 되어

[27:32] 우리가 구축한 모든 것을 살펴보고

[27:34] 알려진 모범 사례와 대조해서 확인하고

[27:35] 웹에서 알려진 취약점을 조사하고

[27:38] 그런 것들이 우리 앱에 없는지 확인하고

[27:40] 알려진 MCP 서버를 사용해서

[27:43] 실제로 우리 앱을 정밀 검사해서

[27:46] 정말 바보같은 일을 하지 않고 있는지

[27:48] 확인하는 것입니다.

[27:50] 이 단계에서 우리가 하고 싶은 일이 바로 그것입니다.

[27:52] 우리 자신의 발등을 찍지 않도록 하고

[27:53] 우리를 신뢰할 수 있는 사람들의

[27:55] 발등을 찍지 않도록 하는 것입니다.

[27:58] 이제 이 영상이 너무 길어질 위험과

[27:59] 다음 영상에서 전체 앱을 빌드하기 위해

[28:01] 문자 그대로 이 일을 할 것이라는 것을 알기에

[28:03] 자세히 들어가지는 않겠습니다.

[28:05] 하지만 다시 말씀드리지만, 여러분 모두

[28:07] 원하신다면 이 전체 프롬프트에 액세스할 수 있습니다.

[28:10] 그리고 다시, 이것은 다음과 같은 것들을 다룹니다.

[28:12] API 엔드포인트를 보호하는 방법

[28:14] 우리 프로젝트에 있는

[28:16] 일부 의존성에 명확한 문제가

[28:18] 없는지 확인하는 방법 등입니다.

[28:20] 그런 것들 말이죠. 자, 끝!

[28:23] 여러분은 방금 여러분의 꿈을 실현시킬

[28:27] 멋진 에이전트 군대를 설정하는 방법을 봤습니다.

[28:31] 저는 Claude 코드 에이전트를 사랑합니다.

[28:33] 이것이 올해 만들어진 최고의 것 중 하나라고 생각합니다.

[28:35] 그리고 아마 이런 주장을 두 번 정도 했던 것 같습니다.

[28:37] 지금은 8월이니까 세 번째 주장을

[28:39] 할 수 있을 것 같습니다.

[28:41] 분기당 하나씩 멋진 걸 얻는 거죠.

[28:43] 이제 다시, 우리가 사용할 수 있는

[28:45] 이 멋진 추론 에이전트들을 가지고 있다는 것을 알지만

[28:47] 그것은 전투의 절반에 불과합니다.

[28:50] 다음 영상에서는 이것들을 가져와서

[28:51] 단계적 시스템으로 조율해서

[28:54] 일부와 함께 반복하며

[28:56] 실제로 새로운 기능들을 구축할 것입니다.

[28:59] 원시 아이디어에서부터

[29:01] 완전히 완성된 프로젝트까지 갈 것입니다.

[29:04] 사람들이 실제로

[29:06] 가입하고 돈을 지불할 수 있는 것까지요.

[29:08] 코드, 데이터베이스,

[29:11] 배포, 모든 것을 말입니다.

[29:15] 그리고 전체를 하루 안에

[29:16] 아니면 주말 안에 완성하려고 합니다.

[29:19] 하지만 함정이 있습니다.

[29:21] 항상 함정이 있거든요.

[29:23] 이것이 제가 만든 최고의 영상일 수도 있고

[29:26] 아니면 이 영상을 생각하며

[29:28] 오늘 아침에 정말 행복했던 것일 수도 있지만

[29:30] YouTube 알고리즘은 구독자 5만 명

[29:32] 이하의 크리에이터들에게는 잔인합니다.

[29:34] 영상에서 견인력을 얻기가

[29:35] 정말 어렵습니다.

[29:37] 때로는 공허한 곳으로 소리치는 것 같을 수 있습니다.

[29:41] 그래서 구독하고

[29:42] 알림벨을 누르지 않으시면

[29:44] 우리가 다시는 서로를 볼 수 없을 가능성이 높습니다.

[29:47] 솔직히 말씀드리면, 여러분은 정말로

[29:50] 다음 영상을 놓치고 싶지 않을 겁니다.

[29:52] 정말 멋질 거거든요.

[29:56] 그러니 헐크처럼 구독 버튼을 누르고

[29:59] 댓글에서 제가 만들기를 원하는

[30:01] 앱 아이디어가 있으시면 알려주세요.

[30:03] 어쩌면 그것이 제가 선택할 것일지도 모릅니다.

[30:06] 자, 그게 전부입니다.

[30:08] 아래 영상 설명란에서 에이전트들을 받으세요.

[30:10] 다음 시간까지, 평화!