Claude Code로 오류 90% 줄이는 방법

AI Oriented Dev 구독자 2,140명

요약

이 영상에서는 Claude Code의 새로운 기능(하위 에이전트, 커스텀 명령, 출력 스타일)과 TDD(Test Driven Development)를 활용해 컬러 믹서 애플리케이션을 설계하고 구현하는 과정을 보여준다. AI 에이전트들이 설계 단계(와이어프레임, 컴포넌트 라이브러리, 테스트 플랜)를 분업 처리한 뒤 매니페스트(manifest)로 통합하며, 구현 단계에선 테스트 작성→실패 확인→코드 작성→테스트 성공의 순환을 자동화한다. Playwright 기반 테스트와 Stagehand를 비교해 설명하며, 브라우저베이스(Browserbase)를 통해 클라우드에서 세션 재생과 디버깅 도구를 사용하는 방법도 소개한다.

주요 키워드

Test Driven Development Claude Code subagent orchestrator Stagehand Playwright PRD manifest file observe extract act Browserbase MCP

하이라이트

🔑 Claude Code의 하위 에이전트와 오케스트레이터를 조합해 설계·구현 작업을 분업화함으로써 효율적인 멀티에이전트 워크플로우를 실현한다.
⚡️ PRD(Product Requirements Document) 한 장으로 와이어프레임, 컴포넌트 설계, 테스트 플랜을 생성하고 매니페스트 파일로 통합해 전 과정을 문서화한다.
🌟 TDD 사이클(레드→그린→검증)을 Claude Code의 커스텀 출력 스타일로 자동화해 테스트 작성과 코드 구현을 체계적으로 수행한다.
📌 Playwright 기반 테스트는 구현 세부사항에 의존해 취약(brittle)해질 수 있지만, Stagehand의 observe·extract·act 기능으로 자연어 기반 테스트를 작성하면 구현 변경에도 견고하게 유지된다.
🚀 Stagehand observe로 UI 요소 존재 확인, extract로 속성 추출, act로 클릭 같은 동작 수행을 자연어 명령만으로 처리해 가독성과 강인성을 높인다.
🔍 브라우저베이스 MCP 서버를 사용하면 로컬 자원에 구애받지 않고 클라우드에서 테스트 세션을 실행·재생하며 토큰 사용량과 디버깅 정보를 제공받는다.
🎯 새로운 기능(랜덤 컬러 생성 버튼)을 추가할 때도 하위 에이전트와 TDD 워크플로우를 통해 코드 작성 전 테스트를 먼저 만들고, 기능을 구현해 테스트를 통과시키는 반복 과정을 실습한다.

용어 설명

Test Driven Development(TDD)

코드 구현 이전에 테스트를 먼저 작성하고 실패를 확인한 뒤 기능을 구현해 테스트를 통과시키는 개발 방식

Claude Code

Anthropic이 제공하는 AI 코딩 환경으로, 하위 에이전트·커스텀 명령·출력 스타일을 통해 사용자 정의 워크플로우를 지원한다

하위 에이전트(subagent)

UI 디자이너, CN 전문가, 테스트 전문가 등 역할별로 나눈 AI 에이전트로, 각기 다른 작업을 분업 처리한다

오케스트레이터(orchestrator)

여러 하위 에이전트를 순차 또는 병렬로 실행·조율해 최종 결과를 종합하는 AI 관리 컴포넌트

Stagehand

Browserbase에서 만든 AI 기반 테스트 프레임워크로, 자연어 명령으로 observe·extract·act 기능을 제공한다

Playwright

브라우저 자동화 라이브러리로, 브라우저 환경에서 엔드투엔드 테스트를 수행한다

PRD(Product Requirements Document)

제품 요구사항을 정리한 문서로, 애플리케이션의 기능·설계 방향을 정의한다

매니페스트 파일(manifest file)

설계 단계 결과(와이어프레임, 컴포넌트, 테스트 플랜 등)와 요구사항을 연결해 정리한 메타데이터 파일

브라우저베이스 MCP 서버

Browserbase가 제공하는 서버 인프라로, AI 테스트 세션을 클라우드에서 실행·관리하며 세션 재생과 디버깅을 지원한다

테스트가 없으면 기능이 없다는 TDD 철학을 소개하고, AI 코딩 환경인 Claude Code와 테스트 주도 개발 워크플로우를 결합해 오류를 줄이는 방식을 개괄한다.

[00:00] Claude Code를 활용한 개발에 대한 소개와 함께, 소프트웨어 엔지니어링에서 테스트 주도 개발(TDD)의 중요성을 강조합니다. 테스트가 작성되지 않으면 기능이 존재하지 않는다는 원칙을 설명하며, AI 코딩 시대에도 체계적인 접근이 필요함을 언급합니다.

[00:26] Anthropic의 문서를 참조하여 Claude 사용 시 올바른 TDD 접근법을 설명합니다. 예상 입력과 출력을 기반으로 테스트를 먼저 작성하고, 테스트 실패를 확인한 후 통과하는 코드를 작성하는 단계별 프로세스를 제시합니다.

[00:48] 오늘의 실습 프로젝트인 색상 믹서 애플리케이션을 소개합니다. 시각적이고 인터랙티브한 요소들(슬라이더, 버튼 등)이 많아 TDD의 이점을 잘 보여줄 수 있는 예시임을 설명하고, 단일 PRD 파일로부터 전체 애플리케이션을 구축할 예정임을 안내합니다.

Browserbase가 제공하는 Stagehand 프레임워크와 클라우드 테스트 인프라를 설명하며, 자연어 기반 테스트 작성과 세션 재생, 디버깅 도구 활용법을 간략히 안내한다.

[01:16] 사용할 기술 스택을 소개합니다. Claude Code의 최신 기능들과 디자인/구현을 위한 전문화된 사용자 정의 명령어 팀, 그리고 새로운 출력 스타일 기능을 활용할 예정임을 설명합니다.

[01:29] 스폰서인 Browser Base와 Stagehand 프레임워크를 소개합니다. Stagehand가 Playwright 기반이지만 자연어 프롬프트로 테스트를 작성할 수 있게 해주며, 애플리케이션을 더 견고하고 유연하게 만들어준다고 설명합니다.

[01:53] Browser Base 클라우드 플랫폼의 고급 기능들을 소개합니다. 세션 리플레이, 액션 히스토리, 디버깅 도구 등을 통해 테스트 개발 경험을 향상시킬 수 있으며, Browser Base MCP 서버를 통해 이러한 기능들에 접근할 수 있다고 설명합니다.

[02:22] 본격적인 실습을 시작하기 전 마무리 인사와 함께, 실제로 생성한 서브에이전트들을 소개합니다. UI 디자이너, ShadCN 전문가, Stagehand 전문가로 구성된 첫 번째 서브에이전트 세트가 디자인 단계를 담당할 예정임을 설명합니다.

UI 디자이너·CN 전문가·테스트 전문가 등 세 가지 Subagent와 이들을 조율하는 오케스트레이터를 설정해 PRD 기반 설계 단계 워크플로우를 준비한다.

[02:37] 하위 에이전트들을 소개하며 UI 디자이너, ShadCN 전문가, Stagehand 전문가가 애플리케이션의 설계 단계를 담당한다고 설명합니다. 이들은 제품 요구사항 문서를 받아 오케스트레이터의 조정 하에 원하는 결과물을 생성합니다.

[02:58] 설계 단계 후 React TypeScript 전문가가 구현 단계를 담당한다고 설명하며, 테스트 주도 개발(TDD) 방식을 사용할 것이라고 소개합니다. Stagehand 전문가는 테스트 설계와 실제 테스트 코드 작성을 모두 담당하게 됩니다.

[03:31] Claude Code에서 TDD를 적용하기 위해 만든 '실용적 테스트 주도 개발자' 출력 스타일을 소개합니다. 이 방식은 Red-Green-Refactor 사이클을 따라 먼저 실패하는 테스트를 작성하고, 테스트를 통과시키는 최소한의 기능을 구현한 후, 선택적으로 사용자 검증을 거치는 과정입니다.

오케스트레이터가 프로젝트 폴더를 초기화하고, 설계 산출물과 요구사항을 연결하는 매니페스트 파일을 생성하는 과정을 설명한다.

[04:02] 하위 에이전트, 커스텀 명령어, 출력 스타일 등 Claude Code의 새로운 기능들에 대한 다른 영상들을 참고하라고 안내하며, 실제 데모를 시작합니다.

[04:14] dev design-app 명령어를 실행하여 PRD 파일을 처리하기 시작합니다. 이 커스텀 슬래시 명령어가 PRD 실행을 담당하고, 오케스트레이터가 모든 하위 에이전트들을 조정하여 필요한 결과물을 생성하도록 합니다.

[04:37] PRD 분석 후 컬러 믹서 애플리케이션을 위한 다중 에이전트 설계 워크플로우가 시작됩니다. 오케스트레이터는 하위 에이전트들이 적절한 시기에 순차적 또는 병렬로 작업하도록 조정하며, PRD를 바탕으로 출력 폴더 구조를 생성합니다.

UI 디자이너의 와이어프레임, CN 전문가의 컴포넌트 라이브러리 구성안, Stagehand 전문가의 테스트 플랜 등 설계 단계 결과물을 병렬로 생성한다.

[05:18] 심플 컬러 믹서 프로젝트의 매니페스트 파일을 통해 설계 단계와 연관된 실행을 식별하고, 요구사항과 설계가 어떻게 연결되는지 확인할 수 있습니다.

[05:42] UI 디자이너가 시작되고, 완료 후 shadcn 전문가와 테스팅 전문가가 병렬로 실행되는 다중 에이전트 아키텍처의 작동 방식을 설명합니다.

[06:22] UI 디자이너 서브에이전트가 컬러 미리보기, RGB 컨트롤, 컬러 프리셋을 포함한 반응형 와이어프레임을 생성하는 과정을 보여줍니다.

[06:52] shadcn 전문가와 playwright stagehand 전문가가 병렬로 작업하며, 각각 20만 토큰의 컨텍스트를 최대화하여 오염 없이 집중된 작업을 수행합니다.

[07:28] 두 서브에이전트가 결과물을 생산했으며, shadcn 전문가는 라이브러리 컴포넌트들의 배치, 논리적 근거, 구성 계획, 설계 고려사항들을 제공합니다.

모든 설계 산출물이 완료되면 오케스트레이터가 매니페스트와 구현 계획을 종합해 구현 단계 진입 준비를 마친다.

[07:51] 스테이지핸드 전문가가 플레이라이트 테스트와 스테이지핸드 사용법을 포함한 포괄적인 테스트 계획을 생성했습니다. 이는 작업 정의에 더 유연하고 강력한 방법을 제공합니다.

[08:17] 모든 전문 에이전트들이 작업을 완료하면서 오케스트레이터가 출력들을 종합하고 검증하여 구현을 위한 최종 매니페스트 파일을 준비합니다.

[09:07] 디자인 단계가 완전히 완료되어 프로젝트 초기화, 와이어프레임, 컴포넌트, 테스트를 모두 포함한 종합적인 결과물이 생성되었습니다.

[09:31] 매니페스트 파일과 구현 계획을 통해 전문 서브에이전트들이 수행한 모든 연구와 계획을 활용할 수 있는 견고한 프레임워크가 구축되었습니다.

‘Implement MVP’ 커스텀 명령을 통해 매니페스트와 구현 계획을 읽고, 레드→그린→검증 TDD 사이클을 자동으로 적용할 출력 스타일을 설정한다.

[10:19] 설계 단계의 모든 출력을 결합하여 애플리케이션 구현을 시작하며, 'Implement MVP'라는 두 번째 사용자 정의 명령을 사용할 예정입니다.

[10:37] 구현 MVP 명령어가 설계 단계의 매니페스트와 구현 계획을 찾아 현대적인 테스트 주도 개발 워크플로우를 따른다고 설명합니다.

[10:48] TDD의 3단계 과정을 설명합니다: Red 단계에서 테스트 작성 및 실패 확인, Green 단계에서 기능 구현, 그리고 모든 필요한 기능에 대해 이 과정을 반복합니다.

[11:22] 실용적인 테스트 주도 개발자 스타일을 사용하여 이 과정을 강제하며, 검증 없음 모드로 사용자 입력 없이 끝까지 실행한다고 합니다.

Next.js 앱을 생성하고 Playwright, Stagehand 개발 의존성을 설치해 TDD 기반 구현을 시작할 개발 환경을 준비한다.

[11:48] 개발 시에는 인간 검증 단계를 포함할 것을 권장하며, 특히 기존 코드베이스에 새 기능을 추가할 때 더욱 중요하다고 강조합니다.

[12:14] MVP 구현 명령어가 설계 폴더, 출력 경로, MVP 폴더를 입력받는다고 설명하며, 매니페스트와 구현 계획이 있는 위치를 지정합니다.

[12:40] Next.js 보일러플레이트 앱을 초기화하는 과정을 보여줍니다. NPX create-next-app@latest 명령어를 사용하여 TypeScript, ESLint, Tailwind 등의 옵션을 선택합니다.

Implement MVP 명령을 실행해 자동으로 테스트 주도 개발 사이클로 컬러 믹서 기능을 구현하고, Next.js 앱에서 UI 동작을 확인한다.

[13:07] 간단한 Next.js 앱 보일러플레이트 초기화를 완료하고 npm run dev 명령어로 개발 서버를 시작하는 과정을 보여줍니다.

[13:20] 개발자가 Next.js 보일러플레이트 위에 앱을 구축할 준비를 하며, Stagehand와 Playwright 종속성을 설치하고 서버 설정을 구성한다.

[14:13] TypeScript 에이전트와 Playwright Stagehand 전문가를 활용한 서브에이전트를 사용하여 TDD 방법론으로 구현할 것이라고 설명한다.

[14:35] AI가 구현 계획을 검토하고 기존 프로젝트 구조를 분석한 후, 기본 Playwright 테스트를 작성하여 전체 애플리케이션 개발 과정을 시작한다.

[14:59] TDD 사이클이 완료되어 Stagehand 전문가와 TypeScript 전문가가 협력하며 Simple Color Mixer 앱 전체가 성공적으로 구축되었다.

Playwright로 작성된 스모크 테스트(페이지 로드, 헤딩·요소 존재 등)를 실행해 기능이 정상 동작하는지 확인하고 테스트 주도 개발의 중요성을 강조한다.

[15:25] 완성된 앱을 실행하여 RGB 슬라이더로 색상을 조정하고, 색상 프리셋을 선택하며, hex와 RGB 값을 복사하는 모든 기능이 예상대로 작동함을 확인한다.

[16:00] Color Mixer 애플리케이션이 완성되어 사양에 맞게 작동하고 있으며, 테스트 주도 개발 워크플로를 위한 테스트 작성의 중요성을 설명합니다.

[16:13] Playwright 테스트의 기본 구조를 살펴보며, 애플리케이션의 기본적인 요소들(제목, 부제목, UI 요소)이 올바르게 렌더링되는지 확인하는 스모크 테스트를 설명합니다.

[17:11] 컬러 프리뷰 요소의 존재를 확인하는 테스트를 통해 data-testid를 활용한 요소 식별 방법을 설명하고, 실제 페이지에서 해당 요소를 확인합니다.

[17:28] Playwright의 UI 모드를 사용하여 테스트를 실행하는 방법을 시연하며, 여러 브라우저에서 병렬로 실행되는 통합 테스트의 장점을 설명합니다.

Playwright 테스트의 취약점(구현 디테일 의존)과 달리, Stagehand의 observe·extract·act를 활용해 자연어 기반 테스트를 작성해 견고성을 높인다.

[18:06] Playwright UI의 스크럽 기능과 소스 코드 연동 기능을 통해 테스트 실행 과정을 시각적으로 확인하고 디버깅하는 방법을 시연합니다.

[18:34] 테스트 주도 개발 사이클을 통해 RGB 슬라이더 요소들을 검증하는 과정을 설명하며, 테스트 작성→실패 확인→최소 기능 구현→테스트 재실행 순서를 거쳤다고 설명합니다.

[19:00] 테스트 주도 개발이 에러를 줄이고 새 기능이 기존 기능을 망가뜨리는 것을 방지하는 강력한 방법이라고 강조하며, AI 덕분에 이제 대량의 테스트 작성과 실행이 빠르게 가능하다고 설명합니다.

[19:24] Playwright 사용 시의 문제점을 지적하며, RGB 슬라이더 테스트 예시를 통해 data-test-id와 label 이름에 의존하는 구조가 구현과 테스트 간의 긴밀한 결합을 만든다고 설명합니다.

[20:20] 실제 예시로 label 이름을 RGB로 변경했을 때 테스트가 실패하는 상황을 보여주며, 애플리케이션은 정상 작동하지만 구현 세부사항 변경으로 인해 테스트가 깨지는 취약성을 설명합니다.

[21:01] Browserbase에서 개발한 Stagehand를 소개하며, 이 도구가 구현 세부사항에 의존하지 않아도 되는 강력한 해결책이라고 설명합니다.

[21:16] Stagehand 테스트의 장점을 설명합니다. 구현 세부사항에 의존하지 않고 자연어와 AI를 사용해서 테스트를 작성할 수 있으며, 기존 Playwright 테스트를 Stagehand로 포팅한 예시를 보여줍니다.

[21:45] 기존 Playwright 테스트가 구현 변경으로 실패했던 문제점을 언급하고, 새로운 Stagehand 테스트를 소개합니다. observe 메서드를 사용해서 화면 요소를 자연어로 확인하는 방법을 설명합니다.

[22:19] Stagehand 테스트 실행 결과를 보여줍니다. 구현 세부사항에 의존하지 않기 때문에 이전에 실패했던 테스트와 달리 성공적으로 통과하는 것을 확인합니다.

[22:39] Playwright와 Stagehand 테스트의 차이점을 비교 설명합니다. 기능적 요구사항 대 구현 수준 요구사항을 테스트하는 방법의 차이와 각각의 적절한 사용 시나리오를 논의합니다.

[23:00] observe 기능의 강력함을 강조하며, AI가 코드를 파싱하는 대신 실제로 화면을 볼 수 있는 능력을 갖는다고 설명합니다. extract 기능을 소개하고 RGB 슬라이더 예시에서 어떻게 활용할 수 있는지 보여줍니다.

[23:23] extract 함수의 실제 사용 예시를 보여줍니다. RGB 컬러 슬라이더의 가시성, 라벨, 현재 값 등의 정보를 추출하는 방법과 스키마를 통해 출력 형식을 지정하는 방법을 설명합니다.

[23:52] AI 탐지와 추출 기능을 사용하여 슬라이더의 존재뿐만 아니라 값의 정확성까지 확인하는 테스트를 시연합니다. 초록색 기본값을 변경하여 extract 함수의 강력함을 보여줍니다.

[24:40] Stagehand의 세 번째 핵심 기능인 액션 수행 방법을 설명합니다. 인터랙티브한 애플리케이션에서 자연어를 사용하여 간단하게 액션을 수행할 수 있습니다.

[25:02] 프리셋 버튼을 클릭하는 실제 테스트를 실행하며, 빨간색, 파란색, 흰색 버튼을 순차적으로 클릭하고 각각의 색상 값을 추출하여 검증하는 과정을 보여줍니다.

[25:45] 액션 수행과 extract, observe 기능을 결합한 테스트의 강력함을 설명합니다. 구현 세부사항을 알 필요 없이 자연어로 테스트를 작성할 수 있어 가독성과 견고성을 높일 수 있습니다.

랜덤 컬러 버튼 기능을 TDD 방식으로 추가한다. 레드 단계에서 테스트 작성·실패 확인, 그린 단계에서 기능 구현·성공 검증, 검증 단계에서 수동 확인 과정을 실습한다.

[26:14] Stagehand의 세 가지 핵심 기능(observe, extract, act)을 요약하고, 테스트 작성이 기능 검증과 개발 프로세스에서 중요한 역할을 한다는 점을 강조합니다.

[26:29] 단일 PRD 파일로부터 앱을 설계하고 구현하여 완성한 과정을 설명하며, 새로운 기능 구축을 위한 반복 루프를 시연할 예정이라고 소개합니다.

[26:54] Claude와 브레인스토밍한 결과 랜덤 색상 생성기라는 간단하면서도 모든 요소를 포함하는 기능을 추가하기로 결정했다고 발표합니다.

[27:05] 실용적 테스트 주도 개발자 모드의 세 가지 사이클을 설명합니다: 레드 단계(테스트 작성), 그린 단계(기능 구현), 리팩터 단계(검증 및 확인).

[27:26] 랜덤 색상 생성기 버튼 구현을 시작하며, TypeScript 전문가와 브라우저베이스 스테이지핸드 전문가 등 서브 에이전트들을 활용한다고 안내합니다.

[28:06] 테스트 주도 개발 방법론과 전문 서브 에이전트들을 통해 원하는 기능을 구현할 것이며, 이것이 단순한 기능 작성보다 훨씬 가치 있는 접근법임을 강조합니다.

[28:34] Anthropic 팀이 실제로 사용하는 개발 방식이며, AI와 서브 에이전트의 힘으로 테스트 주도 개발의 모든 단점을 극복할 수 있다고 설명합니다.

[29:00] 스테이지핸드 테스트 작성을 완료하고 레드 단계에서 테스트가 실패하는지 확인하는 과정을 보여주며, 버튼이 아직 존재하지 않기 때문에 예상대로 실패할 것이라고 예측합니다.

[29:25] TDD의 Red 단계에서 Random 버튼 요소를 찾을 수 없는 상황을 확인하며, 테스트 실패를 통해 개발 진행 상황을 점검합니다.

[29:34] TDD 개발 시 실용적 접근법의 중요성을 설명하며, 테스트 실패 시 최소 기능 구현 vs 더 많은 기능 구현 후 테스트의 균형을 논의합니다.

[30:05] TDD의 Green 단계로 전환하여 TypeScript 전문가가 Random 버튼 기능을 구현하고, 실제 색상 변경이 작동하는지 검증합니다.

[30:43] 테스트 과정에서 extract로 초기 색상 캡처, observe로 버튼 찾기, 클릭 후 색상 변경 확인하는 자연어 기반 테스트 프로세스를 설명합니다.

브라우저베이스 MCP 서버에 테스트를 실행해 가상 브라우저에서 Observe·Act 세션을 녹화·재생하고, 토큰 사용량·디버깅 정보 등 분석 결과를 확인한다.

[31:03] TDD와 서브 에이전트를 결합한 견고한 기능 구축 방법론을 시연하고, Browserbase의 클라우드 인프라 활용 장점을 소개합니다.

[31:36] 공식 Browserbase MCP 서버를 통해 Claude Code와 Browserbase를 직접 연동하고, Vercel로 배포한 애플리케이션에서 Random Color 기능이 정상 작동함을 확인합니다.

[31:56] Browser Base를 활용한 자동화된 작업과 상호작용 실행에 대한 설명. Browser Base MCP 설정과 다양한 제공업체(Gemini, OpenAI) 지원에 대해 소개.

[32:18] Browser Base 플랫폼의 강력함과 유용성을 강조. 페이지 테스트 실행 결과를 보여주는 멋진 뷰와 각 작업의 입력/출력을 확인할 수 있는 기능 설명.

[32:36] 토큰 처리 정보 제공 기능 소개 후 실제 라이브 데모 시작. Browser Base MCP 서버 실행 확인.

[32:50] Browser Base MCP 도구를 통한 테스트 실행 시연. 애플리케이션 URL 설정 후 Browser Base에서 테스트 복제 실행.

[33:11] Claude의 자체 인프라를 사용한 MCP 도구 활용. API 지식 없이도 자연어 지시만으로 작업 수행 가능함을 설명.

[33:19] Browser Base의 Claude 브라우저 라이브 뷰 시연. 가상 브라우저에서 작업이 실행되는 모습과 버튼 존재 확인 과정을 보여줌.

[33:39] Browser Base의 장점 설명 - 로컬 머신의 리소스 제한에서 벗어나 Claude의 전체 인프라 스택을 활용한 테스트 실행 가능.

[33:51] 세션 완료 후 전체 작업 기록 확인 기능. 비디오 형태와 작업 순서 형태로 모든 액션을 볼 수 있으며, 페이지 이동부터 랜덤 버튼 클릭까지의 과정을 상세히 추적.

[34:16] 각 실행의 출력 확인과 팀 공유 기능. 화면 녹화뿐만 아니라 실제 작업과 출력까지 팀원들과 공유 가능한 Browser Base 플랫폼의 강력함 강조.

[34:34] 튜토리얼 마무리와 테스트 주도 개발의 가치 요약. Claude Code와 Stagehand를 통해 AI가 관찰, 추출, 작업 수행을 자연어로 할 수 있게 된 혁신적 변화를 강조.

Claude Code와 TDD, Stagehand, Browserbase를 결합한 워크플로우가 오류를 줄이고 효율성을 높이는 방법을 정리하며, 구독·알림 설정을 유도한다.

[34:56] 클라우드 기반 테스트의 장점과 Browser Base 후원 감사 인사. 로컬 환경의 제약에서 벗어나 클라우드의 추가 도구와 기능을 활용할 수 있음을 설명.

[00:00] 안녕하세요, 여러분.

[00:01] Claude Code를 최대한 활용하는 방법에 대한 또 다른 에피소드에 오신 것을 환영합니다.

[00:05] 소프트웨어 엔지니어링에는 이런 유명한 말이 있습니다.

[00:08] 테스트가 작성되지 않으면, 그 기능은 존재하지 않는다.

[00:11] 이건 좀 과장된 표현이긴 하지만, 사실 테스트 주도 개발이라는 방법론에서 나온 실전 방법입니다.

[00:14] 어떤 소프트웨어든 개발할 때, 코드를 구현하기 전에 항상 테스트를 먼저 작성해야 합니다.

[00:17] 그리고 이런 AI 코딩 시대에는 모든 걸 한 번에 해결하고 싶은 유혹이 정말 클 텐데요.

[00:22] 하지만 실제로 이렇게 해본 분들은 알 겁니다.

[00:25] 이건 올바른 접근법이 아니라는 것을요.

[00:26] Anthropic에서 작성한 이 문서를 보시면

[00:29] 항상 Claude에게 예상 입력과 출력을 기반으로 테스트를 작성하라고 요청하라고 되어 있습니다.

[00:33] 그다음 Claude에게 테스트를 실행해서 먼저 실패를 확인하라고 하고,

[00:36] 그 후에 테스트를 통과하는 코드를 작성하라고 합니다.

[00:38] 애플리케이션 내에서 구축하는 모든 기능에 대해 이 과정을 반복해야 합니다.

[00:45] 오늘 튜토리얼에서는 이 이론을 실제로 적용해보겠습니다.

[00:48] 여기서 보시는 색상 믹서 애플리케이션을 전체적으로 구축해볼 겁니다.

[00:52] 이는 테스트 주도 개발의 이점을 보여주는 훌륭한 예시입니다.

[00:56] 그 이유는 매우 시각적이기 때문입니다.

[01:00] 사용자가 상호작용할 수 있는 요소들이 많이 있어요.

[01:03] 여기 보이는 슬라이더들처럼 말이죠.

[01:06] 아래에 있는 이런 다양한 버튼들과 함께, 우리는 이 모든 것을

[01:10] 이 애플리케이션의 모든 요구사항을 설명하는 단일 PRD 파일로 구축할 겁니다.

[01:14] Claude Code의 최신 기능들을 여러 개 사용할 예정인데,

[01:16] 디자인과 구현 단계를 위한 전문화된 사용자 정의 명령어 팀이 포함됩니다.

[01:20] 그리고 Cloud Code의 최신 기능 중 하나인 출력 스타일도 사용할 겁니다.

[01:25] 오늘 비디오는 Browser Base의 후원으로 제작되었습니다.

[01:29] Browser Base 플랫폼과

[01:31] 오늘 테스팅에 사용할 Stagehand 프레임워크를 개발한 팀입니다.

[01:34] Stagehand는 Playwright 프레임워크 위에 구축된 프레임워크지만,

[01:37] 이런 식으로 보이는 테스트 작성에서

[01:41] 대신 자연어와 텍스트 프롬프트를 사용해서 테스트를 작성할 수 있게 해줍니다.

[01:43] 보시다시피, 이는 실제로 애플리케이션을 훨씬 더 견고하게 만들고,

[01:47] 가능한 상호작용에 대해 훨씬 더 많은 유연성을 제공합니다.

[01:50] 뿐만 아니라, Browser Base를 사용해서 클라우드에서 이런 작업들을

[01:53] 실행하는 방법도 보여드릴 겁니다. 전체 테스트 세션의 세션 리플레이,

[01:57] 수행된 모든 액션의 히스토리,

[02:00] 그리고 테스트 개발 경험을 훨씬 더 좋게 만들어주는 유용한 디버깅 도구들 같은

[02:04] 전체적인 기능을 제공합니다.

[02:08] 이런 기능에 접근하기 위해 Browser Base MCP 서버를 사용할 거고,

[02:10] Stagehand와 Browser Base 플랫폼 모두가

[02:14] Claude Code를 사용한 작업 중심 개발에서 얼마나 큰 차이를 만드는지

[02:17] 확인할 수 있을 겁니다.

[02:22] 시작할 준비 되셨나요?

[02:23] 시작해보겠습니다.

[02:25] 제가 한 일은 여러 개의 서브에이전트를 실제로 생성한 것입니다.

[02:29] 첫 번째 서브에이전트 세트는 UI 디자이너, ShadCN 전문가,

[02:33] 그리고 Stagehand 전문가인데, 이 세 개가 담당할 역할은

[02:37] 이 애플리케이션의 설계 단계를 담당합니다.

[02:39] 이 시스템이 하는 일은 단일 제품 요구사항 문서를 받아서

[02:43] 오늘 만들 앱에 대한 내용을 처리하는 것인데, 이 문서는 우리가

[02:47] 시연할 주요 기능을 설명하고 있습니다. 그리고 우리가 할 일은

[02:50] 여기 있는 오케스트레이터를 사용해서

[02:54] 세 개의 하위 에이전트 간의 조정을 통해 우리가 원하는 결과를 얻는 것입니다.

[02:58] 그 다음에 구현 단계로 넘어가서

[03:02] React TypeScript 전문가를 사용해서

[03:06] 우리가 얻은 결과물을 바탕으로 애플리케이션을 구현하게 됩니다.

[03:09] 테스트 주도 개발 방식을 사용할 예정이므로

[03:13] 여기 있는 Stagehand 전문가도 실제로 활용할 것입니다.

[03:17] 테스트 설계뿐만 아니라 구현 단계에서 사용할

[03:21] 실제 테스트 코드 작성까지 담당하게 됩니다.

[03:23] 이것이 바로 오늘 튜토리얼의 핵심입니다. 여러분에게

[03:26] 테스트 주도 개발 방식으로 애플리케이션을 구현하는 방법을 보여드리는 것이죠.

[03:31] 그리고 오늘 Claude Code로 이를 적용하는 방법은

[03:33] 제가 만든 커스텀 실용적 테스트 주도

[03:36] 개발자 출력 스타일을 사용하는 것입니다.

[03:39] 이 방식은 어떤 기능을 작성하든 먼저

[03:42] 레드 단계를 거쳐 테스트를 작성하고

[03:44] 테스트가 실패하는지 확인합니다. 기능이 아직

[03:48] 구현되지 않았기 때문에 실패해야 합니다.

[03:50] 그 다음 그린 단계로 넘어가서 테스트를 통과시키기 위한

[03:53] 적절한 기능을 구현합니다.

[03:55] 그리고 테스트가 통과하는지 확인하고

[03:57] 선택적으로 사용자가 제대로 작동하는지

[04:00] 확인하는 검증 단계를 거칩니다.

[04:02] 하위 에이전트나 커스텀 명령어, 또는

[04:04] 출력 스타일에 대해 더 알고 싶으시면

[04:06] Claude Code에서 새로 나온 기능들이니까

[04:09] 이 주제들에 대한 다른 영상들을 확인해보세요

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

[04:14] dev design-app을 실행하고 docs 폴더의

[04:18] PRD 파일을 지정하겠습니다.

[04:20] 좋습니다.

[04:21] 여기서 보시는 것처럼 이 커스텀 슬래시 명령어가

[04:25] PRD를 실행하는 역할을 담당합니다.

[04:30] 그리고 모든 하위 에이전트들이 오케스트레이터와 함께

[04:33] 각자가 가져야 할 필요한 결과물을 생성하도록 조정됩니다.

[04:37] 이것을 그려보겠습니다. 여기서 PRD를 분석했다고 하고, 이제

[04:41] 이 컬러 믹서 애플리케이션을 위한 다중 에이전트 설계 워크플로우를 사용할 것입니다.

[04:46] 첫 번째 단계는 오케스트레이터를 시작하는 것입니다.

[04:49] 앞서 말씀드린 것처럼, 오케스트레이터는

[04:52] 모든 하위 에이전트들이 적절한 시기에 작동하도록 보장하는 역할을 합니다.

[04:57] 순차적으로 또는 병렬로 작업하든 상관없이 모든 결과물들을

[05:01] 조정해서 올바른 위치에 배치되도록 합니다.

[05:04] 보시다시피 이 오케스트레이터가 가장 먼저 하는 일은

[05:08] PRD를 이해한 내용을 바탕으로

[05:12] 출력 폴더 구조를 만드는 것입니다.

[05:14] 설계 단계에서 단일 프로젝트를 볼 수 있습니다.

[05:18] 심플 컬러 믹서이고, 실제로 타임스탬프가 있어서 이것이 이 설계 단계와 연관된 실행임을 식별할 수 있습니다.

[05:22] 그리고 실제로 여기서 가장 중요한 파일을 볼 수 있습니다.

[05:26] 매니페스트 파일이라고 불리는데, 이 파일이 모든 것을 하나로 묶어주는 역할을 합니다.

[05:29] 이것이 실제로 모든 것을 연결해주는 파일입니다.

[05:33] 요구사항이 출력될 모든 설계와 어떻게 연결되는지 보여줄 것입니다.

[05:35] 그래서 PRD의 기능이 여기에 반영되어 있음을 볼 수 있습니다.

[05:37] 그리고 다른 한 가지는 서브 에이전트들이 실행될 것이라는 점입니다.

[05:39] UI 디자이너가 작동할 것이고 실제로 여기서 볼 수 있듯이

[05:42] 1단계가 아직 완료되지 않았기 때문에 지금 막 시작되었습니다.

[05:45] 그리고 UI 디자인이 완료된 후에는 실제로

[05:49] shadcn 전문가와 테스팅 전문가가 병렬로 실행될 것입니다.

[05:53] 그 이유는 실제로 디자인이 있으면

[05:56] 이 둘 모두 병렬로 작업할 수 있기 때문입니다.

[06:00] 작업을 완료하기 위해 서로를 기다릴 필요가 없습니다.

[06:02] 이것이 Claude Code 내 다중 에이전트 아키텍처의 힘입니다.

[06:04] 언제 병렬로 실행하는 것이 최적인지와

[06:06] 언제 순차적으로 실행할 수 있는지 이해해야 합니다.

[06:10] 마지막으로, 오케스트레이터가 최종 구현 체크리스트를 준비하기 전에

[06:13] 모든 것이 제자리에 있는지 확인할 것입니다.

[06:15] 그럼 Claude Code 화면으로 다시 돌아가봅시다.

[06:18] 여기에서 UI 디자이너 서브에이전트가 정말 열심히

[06:22] 작업 중이며 결과물을 생산하고 있는 것을 볼 수 있습니다.

[06:25] 에이전트 안에서 UI 디자이너를 볼 수 있고, 실제로

[06:29] 이 앱이 어떻게 될지 와이어프레임을 만들기 시작했습니다.

[06:30] 상단에 컬러 미리보기가 있고, 중간에 RGB 컨트롤이 있습니다.

[06:33] 그리고 아래에는 컬러 프리셋이 있을 것이고, 태블릿 레이아웃도 와이어프레임으로 만들 것입니다.

[06:37] 모바일 레이아웃도 마찬가지로, 이것들이 반응형 디자인이 되도록 합니다.

[06:41] Claude Code로 다시 돌아가봅시다.

[06:44] 여기서 shadcn 전문가가 시작되었고

[06:46] playwright stagehand 전문가도 마찬가지로 시작되었습니다.

[06:50] 그리고 둘 다 병렬로 작업할 것입니다.

[06:52] 이렇게 하면 작업 속도가 빨라질 것입니다.

[06:55] 각각은 주어진 컨텍스트를 최대화할 것입니다.

[06:59] 대략 20만 토큰 정도로요.

[07:01] 시스템과 에이전트 프롬프트를 위한 몇 가지를 고려하면요.

[07:03] 전체 아이디어는 오케스트레이터가 하는 일과 같이

[07:05] 이전에 일어난 모든 것들로 오염시키지 않고

[07:07] 그들의 작업에 집중할 수 있게 하는 것입니다.

[07:11] UI 디자이너가 하는 일뿐만 아니라요.

[07:15] UI 디자이너가 출력한 것에만 집중합니다.

[07:18] 그리고 이제 둘 다 병렬로 작업할 수 있습니다.

[07:20] 좋습니다. 작업이 진행되어서, 실제로

[07:22] 두 서브에이전트가 이제 여러 결과물을 생산했음을 볼 수 있습니다.

[07:25] 그럼 shadcn 전문가를 빠르게 살펴보겠습니다.

[07:28] 실제로 shadcn 라이브러리의 다양한 컴포넌트들을

[07:32] 사용하고자 하는 것들을 배치했습니다.

[07:35] 논리적 근거와 함께 다른 이점들도 제공합니다.

[07:39] 구성 계획과 다른

[07:42] 이러한 컴포넌트를 사용할 때 들어갈 설계 고려사항들이 있습니다.

[07:44] 구성하는 방법의 계획과

[07:47] 이러한 컴포넌트들을 사용할 때 고려해야 할 설계 사항들입니다.

[07:51] 다음으로 살펴볼 것은 실제로 스테이지핸드 전문가의 출력 결과입니다.

[07:54] 여기서 보시다시피, 실제로는 설정을 위해 필요한 모든 다양한 작업들을 다루는 테스트 계획입니다.

[07:58] 하지만 가장 중요한 것은 플레이라이트 테스트 모두를 배치했다는 점입니다.

[08:00] 그뿐만 아니라 스테이지핸드를 사용해서 작성하는 방법도 보여주었습니다.

[08:04] 오늘 이 튜토리얼을 진행하면서, 이것은 작업을 정의하는 데 훨씬 더 유연하고 강력한 방법을 제공합니다.

[08:08] 이 모든 것을 다루기 전에, 여기로 내려보겠습니다. 보시다시피 전문가가 테스트 사양을 완료했습니다.

[08:17] shadcn 전문가가 마지막 몇 개 출력을 완료하기를 기다리기만 하면 오케스트레이터가 모든 것을 종합하고 검증할 것입니다.

[08:24] 그리고 제가 말한 대로, shadcn 전문가와 플레이라이트 전문가 모두 작업을 완료한 것을 볼 수 있습니다.

[08:35] 마지막으로 오케스트레이터가 다시 들어와서 모든 출력이 올바른 순서에 있는지 확인하고, 구현을 위한 매니페스트 파일의 최종 항목들을 종합할 것입니다.

[08:50] 좋습니다. 여기서 보시듯이 오케스트레이터가 등장해서 디자인 단계에서 나온 모든 에이전트 출력들을 살펴볼 것입니다.

[08:58] 그런 다음 매니페스트 파일과 구현 계획에 대한 최종 업데이트를 생성하기 전에 모든 것을 종합하고 검증할 것입니다.

[09:07] 네, 전체 디자인 단계의 프로세스가 완료되었고, 계획된 모든 것을 완료했다는 것을 볼 수 있습니다.

[09:14] 프로젝트 초기화, 와이어프레임 생성, 차트, 컴포넌트, 플레이라이트, 그리고 가장 중요한 스테이지핸드 테스트를 완료했습니다.

[09:23] 비주얼 매니페스트로 모든 것을 종합했습니다. 실제로 여기를 보시면 디자인 단계에서 완료된 모든 것의 출력을 볼 수 있습니다.

[09:31] 기억하시다시피, 여기 있는 매니페스트 파일은 모든 다양한 파일들이 어디에 있는지 확실히 알 수 있게 해줍니다.

[09:39] 여기 있는 구현 계획을 매니페스트와 함께 사용하면, 여기서 볼 수 있는 이 전문 서브에이전트들이 수행한 모든 지식과 계획, 연구를 활용할 수 있게 됩니다.

[09:51] 각각의 항목들을 세부적으로 다루지는 않겠지만, 이해해야 할 주요 점은 이것이 이 모든 것을 기반으로 애플리케이션을 구현하는 데 매우 견고한 프레임워크를 제공했다는 것입니다.

[10:04] 이것은 항상 계획 단계를 수행하라는 권장 사항을 결합한 패턴 중 하나입니다. 또한 서브에이전트와 사용자 정의 명령을 활용하여 오케스트레이터와 연결하고 이런 방식으로 모든 것을 종합하는 방법입니다.

[10:19] 좋습니다, 이제 이것이 완료되었으므로 여기서 볼 수 있는 모든 출력을 결합하여 이 애플리케이션을 구현할 수 있게 됩니다.

[10:30] 여기에서 만든 두 번째 사용자 정의 명령인 Implement MVP를 사용할 것입니다. 이 Implement MVP에서 인식해야 할 주요 사항은

[10:37] 구현 계획과 설계 단계에서 나온 매니페스트를 찾아야 한다는 것을 이해합니다.

[10:40] 바로 설계 단계에서 나온 것들을 말이죠.

[10:42] 알겠죠?

[10:43] 또한 인식해야 할 점은 이 도구가 현대적인 테스트 주도 개발 워크플로우를 따른다는 것입니다.

[10:46] 즉, 앞서 언급한 3단계 과정을 거쳐야 합니다.

[10:48] Red 단계에서 요구사항에 기반한 테스트를 작성해야 하고,

[10:52] 앞서 말했던 그 단계들이죠.

[10:53] 요구사항에 기반해서 테스트를 작성하는 Red 단계를 거치고,

[10:56] 그 다음에 테스트가 실패하는지 확인합니다.

[11:00] 그 후에는 Green 단계로 넘어가서

[11:02] 테스트를 통과하도록 기능을 구현합니다.

[11:05] 테스트를 다시 실행해서 통과하는지 확인하고,

[11:08] 이 과정을 필요한 모든 기능에 대해 반복합니다.

[11:11] 보시다시피 이 과정을 반복하는 거죠.

[11:13] 먼저 기본 앱이 로드되는지 확인하는 것부터 시작해서

[11:15] 그 다음에는 UI에 대해서도 같은 작업을 하고

[11:18] 앱 내의 모든 컴포넌트에 대해서도 이 과정을 반복합니다.

[11:22] 그리고 이를 강제하는 방법은 다시 한번 실용적인

[11:27] 테스트 주도 개발자 스타일을 사용하는 것입니다. 여기서 전환할 수 있어요.

[11:30] 스타일이라고 타이핑하고 이걸 누르겠습니다.

[11:35] 그리고 여기서 '검증 없음'이라는 버전을 사용할 거예요.

[11:38] 즉, 끝까지 사용자 입력 없이 실행하도록 하겠습니다.

[11:43] 이 검증 없음 방법에서는 실제로 인간 검증 단계를 제거했습니다.

[11:46] 인간 검증 단계를 말이죠.

[11:48] 하지만 개발할 때는 이 검증 단계를 포함하는 것을 강력히 권장합니다.

[11:51] 특히 기존 코드베이스에 새로운 기능을 구축할 때는 더욱 그렇죠.

[11:55] 우리는 이 다른 버전을 사용할 것인데, 여기에는

[11:59] 인간 검증 단계가 있어서 모든 것이 제대로 작동하는지

[12:02] 확인할 기회를 얻을 수 있습니다. 완성된 코드 위에 TDD 방법론을 사용해서

[12:06] 추가 기능을 구현할 때 말이죠.

[12:09] 검증 없음 모드에 있는지 확인하겠습니다.

[12:12] 그리고 MVP를 구현하겠습니다.

[12:14] 보시다시피 실제로 설계 폴더, 출력 경로, MVP 폴더를 입력받습니다.

[12:17] 여기에 배치된 출력 경로를 위한 설계입니다.

[12:22] 매니페스트와 구현 계획이 있는 곳이죠.

[12:25] 이걸 태그하겠습니다. 간단한 컬러 믹서라고 보이네요.

[12:31] 그리고 슬래시를 넣고 타임스탬프가 있는 버전을 선택하겠습니다.

[12:34] 정확한 버전이죠.

[12:35] 좋습니다.

[12:36] 이제 필요한 다른 것은 실제로 이 앱을 빌드하고 싶은 위치입니다.

[12:39] 앱을 빌드할 위치 말이죠.

[12:40] 여기서 볼 수 있듯이 이미 Next.js 보일러플레이트를 초기화해 놨습니다.

[12:42] Next.js 보일러플레이트 말이죠.

[12:45] 제가 한 방법은 NPX create-next-app@latest를 실행하고

[12:50] my-app이라고 명명했습니다.

[12:55] 그리고 예스라고 할 거예요.

[12:57] TypeScript 사용.

[12:58] 예.

[12:58] ESLint, Tailwind.

[12:59] 예.

[13:00] src 디렉토리.

[13:01] App Router, Turbopack.

[13:03] alias 커스터마이징 필요 없음.

[13:04] 이것이 완료되도록 놔두겠습니다.

[13:07] 이제 이 매우 간단한 Next.js 앱 보일러플레이트를 초기화할 거예요.

[13:11] 여기서 실행되는 것을 볼 수 있습니다.

[13:13] my-app으로 이동해서 npm run dev를 실행하겠습니다.

[13:17] 시작될 때까지 잠시 기다려 보겠습니다.

[13:20] 좋아요, 이제 로드가 완료되었고 여기서 보시다시피, 이건 그냥

[13:24] Next.js 보일러플레이트이고, 이것이 우리가

[13:27] 앱을 구축할 시작점이 될 겁니다.

[13:29] 이 부분은 전적으로 선택사항입니다.

[13:30] 만약 깨끗한 디렉토리만 지정했다면, 실제로

[13:33] 그곳에 Next.js 앱도 초기화해줄 겁니다.

[13:35] 하지만 시간을 좀 절약하고 싶었는데, 종종 종속성

[13:39] 설치가 시간이 좀 걸릴 수 있거든요.

[13:40] 제가 할 또 다른 일은

[13:43] 두 개의 개발 종속성을 추가하는 것인데, Browserbase의 Stagehand와

[13:47] Playwright 라이브러리들입니다.

[13:48] 그래서 npm install을 실행해서

[13:52] Playwright와 Stagehand 종속성도 가져올 수 있도록 하겠습니다.

[13:56] 그리고 이게 완료되면, 보시다시피 모든 것이 여기 로드되었습니다.

[14:00] 이걸 실행하고 그 다음에

[14:03] localhost 3000에서 웹 서버를 실행하고 있다고

[14:06] npm run dev로 언급하겠습니다.

[14:08] 직접 실행하지는 마세요.

[14:11] 계속

[14:12] 접근 가능할 겁니다.

[14:13] 제가 추가할 또 다른 것은 서브에이전트를 사용하는 것입니다.

[14:17] 구현을 위한 TypeScript 에이전트와 테스트 작성을 위한

[14:20] Playwright Stagehand 전문가입니다.

[14:24] 알겠죠?

[14:25] 그래서 이게 실행되고, 보시다시피 우리가 설정한

[14:28] TDD 방법론을 사용해서 이를 구현할 것이고,

[14:32] 설계를 기반으로 진행할 겁니다.

[14:34] 사양에 맞춰서요.

[14:34] 좋습니다.

[14:35] 보시다시피 가장 먼저 할 일은 실제로 구현 계획을 살펴보고,

[14:37] 그 다음에 기존 프로젝트 구조를 살펴볼 것입니다. 실제로

[14:42] Next.js 보일러플레이트를 보고 있는 것을 확인할 수 있습니다.

[14:46] 그리고 Playwright와 Stagehand가 설치되었다는 것을 보고,

[14:49] 기본 Playwright 테스트를 작성할 겁니다.

[14:52] 좋아요, 그래서 이걸 그대로 두고 계속해서 전체

[14:56] 애플리케이션을 구축한 다음 돌아와서 확인해보겠습니다.

[14:59] 좋습니다.

[14:59] 보시다시피 이제

[15:00] 완료되었습니다. 필요한 모든 기능에 대해

[15:03] 전체 테스트 주도 개발 사이클을 거쳤습니다.

[15:07] 테스트 작성 구현을 통해 Stagehand 전문가와

[15:11] TypeScript 전문가 사이를 지속적으로 전환했다는 것을 볼 수 있습니다.

[15:16] 일종의 사이클이죠.

[15:18] 그리고 마지막에 전체 Simple Color Mixer 앱을 구축하는데 성공했습니다.

[15:22] 좋아요, 이제 실제로 앱이 어떻게 보이는지 확인해볼 좋은 시간인 것 같습니다.

[15:25] 좋아요, 여기서 우선 할 일은 서버를 시작하는 것입니다.

[15:29] 앱으로 가서 npm run dev를 실행하겠습니다. 그리고 이것이

[15:34] 개발 사이클 마지막에 프로젝트의 상태입니다.

[15:37] 모든 기능이 있습니다.

[15:38] 빨간색 슬라이더, 녹색 슬라이더를 조절할 수 있습니다.

[15:42] 그리고 파란색 슬라이더도요.

[15:43] 아래에는 몇 가지 색상 프리셋이 있어서

[15:45] 검은색, 녹색, 흰색으로 바로 전환할 수 있습니다.

[15:47] 그리고 hex 값이나 RGB 값을 복사하고 싶다면

[15:52] 이 버튼들을 클릭하면 됩니다.

[15:53] 보시다시피 예상대로 작동하고 있습니다.

[15:56] 이것은 16진수 값을 주고 이것은 RGB 값을 줍니다.

[16:00] 이 애플리케이션이 사양에 맞게 작동하고 있고, 작성할 수 있는 테스트의 종류와

[16:04] 이것들이 왜 유용한지, 그리고 애플리케이션과 함께 테스트 주도 개발

[16:09] 워크플로를 가능하게 하기 위해 보여드리고 싶었습니다.

[16:13] 작성된 테스트들을 열어보면 여기에 일반적인

[16:17] Playwright 테스트들이 있는 것을 볼 수 있습니다. 이것부터 먼저

[16:21] 다뤄서 왜 이것들이 유용한지 이해해보겠습니다.

[16:23] 그 다음에 몇 가지 Stagehand 테스트들을

[16:26] 보여드릴 건데, 이것들이 이를 기반으로 구축되어 있고

[16:31] 실제로 이것들에 의존하는 것이 훨씬 더 유용한 이유를 보여드리겠습니다.

[16:33] Playwright 테스트에서 첫 번째로 하는 것을 보면

[16:36] 매우 기본적인 사양 내에서 작성되어 있고, 주요 작업은

[16:39] 업로드를 수행한 다음 제목을 표시하는 것입니다.

[16:43] 그리고 화면에 h1 태그가 있는지 확인하고

[16:47] 제목이 Color Mixer인지 확인합니다.

[16:49] 부제목 설명을 확인하고, mix and match colors with

[16:52] the RGB sliders라고 나와야 합니다.

[16:55] 이것이 바로 우리 화면에서 보는 것과 정확히 일치합니다.

[16:58] 이것이 있는 이유는 일종의 스모크 테스트와 같습니다.

[17:01] 기본 보일러플레이트를 대체하고

[17:04] 이 페이지에서 예상되는 기본적인 태그와 헤딩들을

[17:08] 구현했습니다.

[17:09] 여기에 몇 가지 더 많은 테스트들이 있습니다.

[17:11] 컬러 프리뷰 요소가 존재한다고 나와 있습니다.

[17:14] 컬러 프리뷰라고 불리는 것을 찾아서 돌아다닙니다.

[17:17] 우리 페이지로 가보면 data-testid가 color-preview로

[17:22] 라벨링된 카드 요소가 있는 것을 볼 수 있습니다.

[17:24] 따라서 이 모든 테스트들이 통과할 것으로 예상되고

[17:27] 어떻게 실행하는지 보여드리겠습니다.

[17:28] --ui 옵션을 사용해서 좋은 사용자 인터페이스를 볼 수 있습니다.

[17:31] 그리고 test 하위 디렉토리를 전달하겠습니다.

[17:34] 이렇게 하면 모든 테스트를 실행할 수 있는 좋은 사용자 인터페이스가 나타납니다.

[17:38] 모든 기본 테스트들을 살펴보겠습니다.

[17:40] 앱 로딩과 같은 매우 기본적인 것들이 몇 가지 있습니다.

[17:44] 실제로 다루었습니다.

[17:45] 모든 테스트를 실행할 수 있습니다.

[17:47] 방금 보신 정말 멋지고 놀라운 점은

[17:49] 여러 브라우저를 생성했고, 각각 독립적으로 테스트를 실행하여

[17:54] 모든 것이 올바르게 작동하는지 확인할 수 있다는 것입니다.

[17:57] 이것이 Playwright의 힘이고 브라우저 기반 테스팅을 사용하는 힘입니다.

[18:00] 단위 테스트만 작성하는 게 아니라, 실제 브라우저와 함께

[18:03] 일종의 통합 테스트를 하고 있습니다.

[18:04] 여기서 무슨 일이 일어났는지 살펴보겠습니다.

[18:06] 이 UI의 좋은 점은 실제로 스크럽할 수 있다는 것입니다.

[18:09] 애플리케이션을 통해서 말이죠.

[18:10] 여기서 로드된 것을 볼 수 있습니다.

[18:12] 여기서 보여드리겠습니다. 모든 것이 서로 연결되어 있습니다.

[18:14] 여기를 클릭하고 소스를 클릭하면, 실행되고 있는 테스트를 기반으로

[18:18] 실제 코드 라인들을 볼 수 있습니다.

[18:21] 첫 번째 라인으로 가면, h1이 보이기를 기대한다고 나와 있고

[18:24] 오른쪽에서 실제로 찾은 정확한 요소를 보여주고 있습니다.

[18:28] 그리고 실제로 텍스트를 포함해야 한다고 나와 있습니다.

[18:30] Color Mixer이고 실제로 Color Mixer를 포함하고 있습니다.

[18:34] 통과하고 나서 아래로 내려가서 'RGB 슬라이더로 색상을 믹스하고 매치하세요'라고 적힌 단락을 검색합니다.

[18:38] 바로 여기서 볼 수 있는 내용과 정확히 일치합니다.

[18:40] 잊지 마세요. 실제로 우리는 이 단계에 도달하기 위해

[18:41] 테스트 주도 개발 사이클을 거쳤습니다.

[18:45] 먼저 테스트를 작성하고 실패하는지 확인했죠.

[18:46] 처음 애플리케이션에는 이런 요소들이 전혀 없었기 때문에

[18:49] 당연히 실패했습니다.

[18:52] 그다음 테스트를 통과시키기 위한 최소한의 기능만 구현했는데,

[18:54] 바로 이런 요소들을 추가하는 것이었고,

[18:57] 마지막으로 테스트를 다시 실행했습니다.

[19:00] 이런 테스트 주도 개발 방법론은 에러를 줄이는 강력한 방법입니다.

[19:05] 새로운 기능이 기존 기능들을 망가뜨릴 가능성을 줄여줍니다.

[19:08] AI의 힘 덕분에 이제 정말 빠르게 실행할 수 있습니다.

[19:13] AI 에이전트가 이런 테스트들을 대량으로 작성하고, 모두 실행하고,

[19:16] 항상 최신 상태로 유지할 수 있기 때문입니다.

[19:18] 그래서 이제는 개발 사이클의 일부로 테스트를 작성하지 않을

[19:22] 이유가 정말 없습니다.

[19:24] 자, 이제 이것의 힘을 보셨지만, Playwright를 그대로 사용할 때의

[19:26] 문제점을 강조하고 싶습니다.

[19:29] 여기 있는 테스트를 실제로 보시면, 세 개의 RGB 슬라이더가

[19:33] 모두 존재하는지 확인하는 기본적인 테스트입니다.

[19:37] 보시다시피 실제로 꽤 간단하죠?

[19:39] 그냥 여기로 가서

[19:41] 이 섹션을 찾아보고, 그다음 이런 다른 슬라이더들을

[19:44] 순서대로 확인합니다.

[19:47] 여기서 문제는 이 슬라이더들이 data-test-id로 slider-R, slider-G,

[19:51] slider-B라고 명명되어 있다는 사실에 의존한다는 것입니다.

[19:55] 또한 레이블들이 label-red, label-green, label-blue라고 불린다는

[20:00] 것도 가정하고 있습니다.

[20:02] 이것의 문제는 긴밀한 의존성을 만든다는 것입니다.

[20:06] 작성된 테스트와 구현 사이에 긴밀한 결합을

[20:09] 만듭니다.

[20:11] 이것이 꽤 잘 작동하긴 하지만, 실제로는 구현 세부사항을

[20:14] 알고 있기 때문에 약간 치팅하는 것입니다.

[20:16] 이를 설명하는 단어는 매우 '취약하다'입니다.

[20:19] 왜 그런지 보여드리겠습니다.

[20:20] 여기로 가서 만약 누군가가 위에서 사용된 규칙에 맞추려고

[20:24] 이것을 RGB로 바꾼다면 어떨까요?

[20:29] 이제 이 테스트를 다시 실행하면 실패할 것으로 예상됩니다.

[20:33] 실행되는 것을 볼 수 있습니다.

[20:34] 요소들을 확인하고 있고, 곧 실패하는 것을 보게 될 것입니다.

[20:38] label-R을 찾을 수 없기 때문입니다. 이것이 바로

[20:41] 문제입니다. 애플리케이션을 보면 다른 모든 것들이

[20:44] 실제로는 올바르게 작동하고 있습니다.

[20:46] 단지 구현을 바꿨기 때문에

[20:49] 테스트가 실패하고 있을 뿐입니다.

[20:50] 균일성과 구현을 보장하기 위해 이런 종류의 문제를 잡는 것은

[20:54] 매우 유용하지만, 기본적인 구현 세부사항을 알아야 하기 때문에

[20:59] 좋은 테스트는 아닙니다.

[21:01] 바로 여기서 Stagehand가 등장합니다. Stagehand는 오늘 비디오를

[21:05] 친절하게 후원해주신 Browserbase에서 만든 제품입니다.

[21:09] Stagehand가 극도로 강력한 이유는

[21:11] 더 이상 구현 세부사항을 이해하는 것에 의존하지 않아도 되기 때문입니다.

[21:16] 대신에 여러분은 자연어와 AI를 사용해서

[21:19] 이런 테스트들을 설명할 수 있습니다.

[21:21] 여기서 어떻게 작동하는지 보여드릴게요.

[21:23] 제가 한 일은 실제로 이런 Playwright 테스트들을

[21:26] Stagehand 테스트로 포팅한 것입니다.

[21:27] 먼저 Stagehand로 작성하는 것이 얼마나 견고한지 보여드리고,

[21:32] Stagehand가 훨씬 더 복잡하면서도

[21:36] 이해하고 검증하기 쉬운 테스트들을 수행할 수 있는 부분을 보여드리겠습니다.

[21:39] 이것은 이전에 RGB 슬라이더가 존재하는지

[21:43] 확인했던 테스트입니다.

[21:45] 하지만 구현체의 이름을 바꿔서 실패했던 것을 기억하실 겁니다.

[21:49] 이제 여기에 새로운 테스트를 만들었고,

[21:52] 기본적으로 이것은

[21:54] 페이지에서 슬라이더가 존재하는지 확인합니다.

[21:57] 화면의 요소들을 보는 Stagehand observe 메서드를 사용하고 있어요.

[22:01] 제가 해야 할 일은 '세 개의 RGB 컬러 슬라이더를 모두 찾아서 열거하고

[22:05] 슬라이더들을 통해 빨강, 초록, 파랑이

[22:07] 보이는지 확인하라'고 말하는 것뿐입니다.

[22:09] 같은 UI가 실행되고 있지만, 이것들은 모두

[22:11] Stagehand 관련 테스트들입니다.

[22:13] 방금 완료한 observe를 사용해서

[22:16] 모든 RGB 슬라이더를 발견하는 테스트로 내려가서

[22:18] 이 테스트를 실행해보겠습니다.

[22:19] 이전에 Clear로 작성한 테스트는 구현이 바뀌어서

[22:22] 실패했던 것을 기억하세요.

[22:24] 하지만 여기서는 어떻게 될지 봅시다.

[22:26] 아하!

[22:26] 전혀 문제없습니다.

[22:27] 이번에는 구현 세부사항에 전혀 의존하지 않기 때문입니다.

[22:30] 대신에 페이지를 로드하고 자연어를 사용해서 무엇이

[22:34] 페이지에 있는지 보고, 마지막에 모든 것이 올바르게 보이는지 판단합니다.

[22:39] 이것은 정말 견고합니다. Playwright 테스크가

[22:42] 구현 변경 때문에 계속 실패하는 반면, 다른 테스크는

[22:46] 실제로 통과할 것입니다. 구현이 중요하지 않기 때문이죠. 하나가

[22:49] 다른 것보다 확실히 더 좋다고 말하는 것이 아닙니다.

[22:52] 기능적 요구사항에 대해서 생각하고

[22:54] 그것들을 어떻게 테스트할지와 구현 수준의

[22:58] 요구사항을 어디서 고려해야 하는지 보여드리고 있습니다.

[23:00] 이제 observe의 강력함에 대해 생각해보세요.

[23:02] 화면의 코드를 파싱하는 대신에 AI에게 실제로 사물을 볼 수 있는 능력을 주는 것과 같습니다.

[23:07] 하지만 때로는 여전히 애플리케이션에서

[23:09] 일어나고 있는 것들을 추출할 수 있는 것이 매우 유용합니다.

[23:13] 그리고 이것은 매우 적절하게 extract라고 명명되었습니다.

[23:15] 방금 본 RGB 슬라이더를 어떻게 활용할 수 있는지

[23:18] extract를 사용해서 보여드리겠습니다.

[23:20] extract 함수를 어떻게 사용할 수 있는지에 대한 예시입니다.

[23:23] 이제 RGB 컬러 슬라이더에 대해 설명하겠습니다.

[23:26] 무엇이 일어나고 있는지에 대한

[23:29] 명확한 정보를 제공해줄 수 있기를 원합니다.

[23:32] 슬라이더들이 보이는지, 라벨이 무엇인지,

[23:35] 그리고 현재 값도 알고 싶습니다.

[23:36] 스키마를 전달하는 것이 매우 유용한 부분입니다.

[23:39] 사용자인 저에게 정보를 어떻게 출력해서 돌려주기를 원하는지 말할 수 있습니다.

[23:43] 여기서 실제로 다음 형식으로

[23:46] 슬라이더의 설명을 지정했습니다.

[23:48] 그리고 이 테스트를 실행해서 이 작업을 보여드리겠습니다. 좋습니다, 이제

[23:52] AI 탐지와 추출 기능을 사용하여 이것을 실행해보겠습니다.

[23:58] 보시다시피 매우 유사하지만, 이제 페이지를 살펴보고

[24:01] 슬라이더의 존재를 관찰할 뿐만 아니라 실제로

[24:05] 값이 정확한지 확인하게 됩니다.

[24:08] 여기서 초록색의 기본값을 변경하면 어떻게 되는지 보여드리겠습니다.

[24:11] 이것이 2, 5, 5로 기본 설정되어 있다고 가정하고 재생 버튼을 누르겠습니다.

[24:15] 실제로 테스트가 실행되면서 extract가 왜 그렇게 유용한지 보게 될 것입니다.

[24:19] 보시다시피 서브스트림에서 값 2, 5, 5를 기대했지만

[24:23] 대신 라벨 녹색, 표시 true, 그리고 값 87을 반환했습니다.

[24:28] 이것이 extract 함수의 강력함을 보여줍니다. AI가 결과를

[24:32] 어떻게 출력할지 결정할 수 있어서 실제로 검증하고 조작하는 것이 훨씬 쉬워집니다.

[24:37] 좋습니다. 이제 관찰하는 방법을 살펴봤고

[24:40] 추출하는 방법도 살펴봤습니다.

[24:43] 세 번째로 살펴볼 것은

[24:44] 실제로 페이지에서 액션을 수행하는 방법입니다.

[24:46] 결국 우리가 다루는 애플리케이션은

[24:49] 인터랙티브 애플리케이션입니다.

[24:51] 매우 시각적이고 상호작용적입니다.

[24:52] 이것이 바로 액션을 수행할 수 있는 것이

[24:54] Stagehand를 사용하는 데 있어 유용한 이유입니다.

[24:57] 매우 간단합니다.

[24:59] 자연어를 사용하기만 하면 됩니다.

[25:00] 여기 있는 이 테스트를 보시면

[25:02] 실제로 프리셋 버튼 중 일부를 누르는

[25:04] 액션을 수행하겠습니다.

[25:08] 빨간 버튼을 클릭한 다음 extract를 사용하여

[25:12] 해당 버튼들의 값을 가져올 것입니다. 그 다음

[25:15] 색상 결과를 확인하고

[25:16] 해당 값들이 일치하는지 확인할 것입니다.

[25:18] 프리셋 버튼이 올바르게 작동하는지 확인하는 것입니다.

[25:20] 지금 이것을 실행해보겠습니다.

[25:21] 이것을 클릭하겠습니다.

[25:22] 프리셋 버튼이 올바른 색상을 적용하는지 보시면

[25:25] 먼저 빨간색을 클릭할 것입니다.

[25:29] 좋습니다.

[25:30] 빨간색이 작동하고 있습니다. 그 다음에는

[25:33] 이제 파란색을 클릭하도록 전환된 것을 보실 수 있습니다.

[25:36] 값들을 추출하고 올바르게 작동하는지 검증해야 합니다.

[25:40] 이제 흰색을 클릭합니다.

[25:43] 그리고 마침내 테스트가 통과했다고 표시됩니다.

[25:45] 이것은 스테이션 테스트의 일부로 액션을 수행할 수 있는 방법을 보여줍니다.

[25:47] 이는 매우 강력한 방법입니다.

[25:49] 스테이션을 활용하는 것이 강력한 이유는 이제 액션을 수행하고 상호작용할 수 있으면서

[25:52] extract와 observe를 사용하여 제대로 작동하는지 평가할 수 있기 때문입니다.

[25:57] 이제 추출할 수 있을 뿐만 아니라 액션도 수행할 수 있습니다.

[26:00] 이것이 Stagehand가 그토록 강력한 이유를 보여주는 예시입니다.

[26:04] 구현 세부사항을 많이 알 필요 없이 자연어를 사용해서 이 모든 것을 수행할 수 있습니다.

[26:07] 테스트를 더 읽기 쉽게 만들고

[26:10] 이해하기 쉽게 만들며

[26:11] 훨씬 더 견고하게 만들 수 있게 해줍니다.

[26:14] 좋습니다. 이제 세 가지 핵심 Stagehand 기능을 다뤘습니다.

[26:17] observe, extract, act를 활용할 수 있습니다.

[26:21] 또한 테스트 작성이 실제로 기능을 검증하는 데

[26:25] 매우 유용한 이유와 개발 프로세스의 일부가 되어야 하는 이유도

[26:28] 말씀드렸습니다.

[26:29] 실제로 저는 단일 PRD 파일로부터 이 앱을 만들었어요.

[26:34] 디자인한 다음 구현해서 지금 보시는 결과물까지

[26:36] 몇 가지 미세한 조정을 거쳐 완성했습니다.

[26:38] 이제 모든 것을 종합해서 이 앱에 새로운 기능을 구축하기 위해

[26:42] 단일 반복 루프를 어떻게 진행하는지 보여드리겠습니다.

[26:46] Claude와 함께 몇 가지 아이디어에 대해

[26:48] 브레인스토밍을 해봤어요.

[26:50] 그리고 지금까지 본 모든 것을 포함하면서도

[26:53] 간단한 것을 만들어보겠습니다.

[26:54] 새로운 랜덤 색상 생성기를 추가해보겠습니다.

[26:58] 먼저 출력 스타일이 제대로 설정되어 있는지

[27:01] 확인하기 위해 전환하겠습니다.

[27:03] 실용적 테스트 주도 개발자 모드로요.

[27:05] 간단히 복기하자면, 이 출력 스타일은

[27:09] 효과적으로 세 가지 사이클로 작동합니다.

[27:10] 먼저 테스트를 작성하는 레드 단계를 거치고

[27:13] 그 후 테스트가 실패하는지 확인하고, 필요한

[27:16] 기능을 구현합니다.

[27:18] 그다음 테스트가 통과하는지 확인하고

[27:19] 마지막으로 모든 것이 올바른지 저와 함께 다시 확인합니다.

[27:23] 실용적 테스트 주도 개발자임을 확인했습니다.

[27:26] 랜덤 색상 생성기 버튼 구현을 시작해보겠습니다.

[27:34] 서브 에이전트를 사용하여 구현을 수행합니다.

[27:39] TypeScript 전문가와 테스트를 사용하세요.

[27:43] 브라우저베이스 스테이지핸드 전문가인 Writing을 사용합니다.

[27:48] 이 서브 에이전트 정의들을 얻고 싶으시다면

[27:52] 아래 설명란의 링크에서 접근할 수 있습니다.

[27:55] 마지막으로, npm run dev는 실행하지 마세요. 지속적으로 실행 중이고

[28:03] localhost:3000에서 실행되고 있습니다.

[28:06] 제가 기대하는 것은 실제로 테스트 주도

[28:11] 개발 방법론을 사용하고, 우리가 보유한 전문 서브 에이전트들을 활용해서

[28:15] 마침내 우리가 원하는 기능에 도달하는 것입니다.

[28:17] 이런 방식으로 기능을 구축하는 가치를

[28:20] 여러분께 보여드릴 수 있길 바랍니다.

[28:22] 단순히 기능을 작성하고 살펴본 다음

[28:27] 예상대로 작동하지 않을 때 실망하는 것과는 대조적으로요.

[28:30] 처음 이런 방식으로 해보면 과도해 보일 수 있지만, 기억하세요.

[28:34] 이것이 바로 Anthropic 팀이 사용하는 방식입니다.

[28:36] 새로운 기능을 개발하고 모범 사례의 일부이기도 합니다.

[28:39] 그리고 이제 AI와 서브 에이전트의 힘으로, 여러분은 모든

[28:44] 단점들을 극복할 수 있어야 합니다. AI가 이 모든 것들을

[28:48] 화면에서 보시는 것처럼 빠르게 작성해주기 때문입니다.

[28:51] 따라서 이런 방법론들과 테스트 프레임워크를

[28:55] 개발 사이클의 일부로 사용하지 않을 이유가 거의 없습니다.

[29:00] 좋습니다.

[29:00] 보시는 것처럼 스테이지핸드 테스트 작성을 완료했습니다.

[29:03] 이 레드 단계의 일환으로 테스트를 실행해서

[29:07] 실패하는지 확인할 것입니다, 알겠죠?

[29:12] 그리고 여기서 보시는 것처럼, 매우 실패할 가능성이 높습니다.

[29:16] 음, 존재하지 않는 버튼이니까요.

[29:20] 그리고 여기서 보시는 것처럼, 실제로 스스로도

[29:22] 말하고 있습니다. 여기 구현을 살펴보고 있는데

[29:23] 버튼이 아직 존재하지 않기 때문에 실패할 것입니다.

[29:25] 이것이 TDD의 Red 단계를 수행하고 있고 여기에서 이를 확인하고 있기 때문입니다.

[29:30] Random 버튼이라는 요소를 전혀 찾을 수 없기 때문이죠, 맞나요?

[29:34] 여기서 핵심은 실용적으로 접근하는 것입니다.

[29:35] 테스트가 실패할 때마다 해당 테스트를 통과시키기 위한

[29:38] 최소한의 기능을 구축하는 수준에서 작업할 수 있습니다.

[29:42] 또는 적어도 테스트가 실패한다는 것을 알고

[29:44] 그 주변에 더 많은 기능을 구축한 다음 다시 테스트를 실행할 수도 있습니다.

[29:48] 실제로 너무 많은 작업을 작성하게 되면

[29:52] 매우 천천히 진행될 수 있으므로 적절한 균형이 중요합니다.

[29:53] 또는 너무 빠르게 진행해서 테스트에 대한 생각 없이

[29:56] 많은 구현을 진행했기 때문에 실제로 어떤 테스트가

[29:59] 실패했는지 모르는 상황이 될 수도 있습니다.

[30:02] 따라서 이런 방식으로 작업할 때는 좋은 균형을 찾는 것이 중요합니다.

[30:05] 여기서 보시면 이제 Green 단계로 넘어간 것을 볼 수 있습니다.

[30:09] TypeScript 전문가를 사용해서 Random 버튼의

[30:12] 기능을 작성할 예정입니다.

[30:13] 하단에 Random Color 버튼이 있는 것을 볼 수 있습니다.

[30:17] 이제 Green 단계를 실행해서 검증을 시도할 것입니다.

[30:21] 이제 Green 단계를 실행하는데, Random 버튼을 클릭하는 데 성공했고

[30:24] 여기서 새로운 색상으로 무작위로 변경된 것을 볼 수 있습니다.

[30:29] 그리고 다시 Random 버튼을 클릭했습니다.

[30:31] 좋습니다. 한 번 더요.

[30:35] 이번에는 통과했습니다.

[30:36] 매번 검증할 때마다 여기에서 테스트를 볼 수 있습니다.

[30:39] 모두 자연어로 되어 있습니다.

[30:40] 이해하기 매우 쉽게 만들어져 있습니다.

[30:43] 좋습니다.

[30:43] 여기 아래를 보시면, 실제로 extract를 사용해서 초기 색상을 캡처했습니다.

[30:47] Observe를 사용해서 Random Color 버튼을 찾고,

[30:49] 버튼을 여러 번 클릭한 다음 다시 extract를 사용해서

[30:52] 색상이 변경되었는지 확인했습니다.

[30:53] 이제 기능이 완성되었고 직접 테스트해보라고 요청하고 있습니다.

[30:56] 그럼 직접 해보겠습니다.

[30:57] 페이지를 새로고침하겠습니다. 여기에 Random

[30:59] Color가 있는 것을 볼 수 있습니다.

[31:00] 클릭해보겠습니다. 계속 클릭해보겠습니다.

[31:02] 확실히 작동하고 있습니다.

[31:03] 이것으로 TDD 방법론을 서브 에이전트와 함께 사용해서

[31:07] 견고한 방식으로 기능을 구축하는 방법을 시연해 보였습니다.

[31:11] 이제 이것을 개발 워크플로우의 일부로

[31:13] 수행하는 방법에 대해 다뤘습니다.

[31:14] Browserbase의 강력함에 대해 정말 강조하고 싶은 점은

[31:18] 이런 테스트를 수행하기 위해 로컬 머신에 의존할 필요가 없다는 것입니다.

[31:22] Browserbase의 가장 좋은 점 중 하나는 이 모든 것을

[31:25] Claude의 인프라에서 실행할 수 있고, 훨씬 빠르게

[31:29] 그리고 여러 인스턴스로도 실행할 수 있다는 것입니다.

[31:30] 실제로 정말 좋은

[31:33] Analytics 도구를 제공해서 세션이 어떻게 실행되고 있는지

[31:36] 실제로 볼 수 있습니다. 공식 Browserbase MCP 서버를 사용할 예정인데,

[31:40] 이를 통해 Claude Code를 사용하고 코드 프로젝트에서 Browserbase와

[31:45] 직접 상호작용할 수 있습니다. 실제로 지금까지 만든 모든 것을 바탕으로

[31:47] Vercel을 사용해서 이 애플리케이션을 배포했습니다.

[31:49] 보시는 것처럼 기능이 여기 있고, 가장 최신 기능은

[31:51] 우리가 추가한 Random Color 기능이지만, 다른 모든 기능도 예상대로 작동합니다.

[31:56] 이제 Browser Base를 사용해서 이런 작업들을 수행해보겠습니다.

[31:59] 이 플랫폼이 자동화된 작업과 상호작용을 실행하는 데 얼마나 유용한지 보여드리겠습니다.

[32:03] 이것이 왜 그렇게 강력한지 지금 보여드리겠습니다.

[32:07] 그래서 Browser Base MCP를 사용하겠습니다.

[32:09] 제 설정 파일에는 API 키와 프로젝트 ID가 들어있습니다.

[32:13] Gemini나 OpenAI를 사용할 수 있고, 다양한 제공업체를 지원합니다.

[32:16] 여러 다른 제공업체도 지원하죠.

[32:18] 솔직히 Browser Base 플랫폼이 얼마나 유용하고 강력한지 정말 인상깊었습니다.

[32:21] 여기서 보시는 것처럼, 이것은 제가 페이지에서 테스트했던 실행 중 하나입니다.

[32:24] 그리고 실제로 매우 유용합니다.

[32:26] 수행된 모든 작업을 보여주는 정말 멋진 뷰가 있기 때문입니다.

[32:29] 각각을 클릭해서 입력이 무엇이었는지 확인할 수 있습니다.

[32:32] 그리고 왜 실패했는지도 알 수 있습니다.

[32:34] 실패한 이유를 말이죠.

[32:36] 이 요청을 처리하는 데 사용된 토큰에 관한 많은 정보도 보여줍니다.

[32:39] 토큰 정보를 말이죠.

[32:41] 그럼 지금 실제 라이브 데모를 해보겠습니다.

[32:43] 좋습니다.

[32:44] 제 Browser Base MCP 서버가 실행 중인지 한 번 확인해보겠습니다.

[32:46] 서버가 실행 중인지 확인하겠습니다.

[32:48] 여기 있는 테스트를 불러와보겠습니다.

[32:50] Browser Base MCP 도구를 통해 여기 있는 테스트를 실행합니다.

[32:57] 애플리케이션의 URL은 이것입니다.

[33:04] 이제 이 테스트를 실행하고 Browser Base에서 복제해달라고 요청하겠습니다.

[33:07] 자체적인 Claude 인프라를 사용해서 이 테스트를 실행합니다.

[33:11] MCP 도구를 사용하므로, API에 대해 너무 많이 알 필요가 없습니다.

[33:13] API를 자세히 몰라도 됩니다.

[33:15] 자연어로 지시하는 것만으로도 충분합니다.

[33:19] 좋습니다.

[33:19] 이것이 Browser Base에서 실행 중인 Claude 브라우저의 라이브 뷰입니다.

[33:24] 여기 있는 이 브라우저를 보실 수 있습니다.

[33:27] 실제로는 가상 브라우저입니다.

[33:28] 이 브라우저는 여러분의 작업 목적으로 생성된 것입니다.

[33:31] 이제 버튼이 존재한다고 표시됩니다.

[33:34] 방금 전에 했던 작업을 복제하는 것을 볼 수 있지만,

[33:37] 이번에는 실제로 자체 브라우저, 자체 인프라에서 실행되고 있습니다.

[33:39] 이것은 매우 유용합니다. 왜냐하면 여러분 컴퓨터에서 여러 개의 브라우저를 실행해야 한다면

[33:43] 자체 리소스에 의해 제한받게 됩니다.

[33:44] 하지만 이것은 Claude에서 실행되고 있고, 전체 인프라 스택을 활용할 수 있습니다.

[33:47] 모든 테스트를 실행하기 위한 전체 인프라 스택을 말이죠.

[33:49] 모든 테스트를 실행할 수 있습니다.

[33:51] 세션이 완료되면, 수행된 모든 작업의 전체 기록을 볼 수 있습니다.

[33:54] 비디오 형태뿐만 아니라 여기서 작업 순서로도 볼 수 있습니다.

[33:58] 여기서 작업 순서를 확인할 수 있습니다.

[34:00] 페이지로 이동한 것을 볼 수 있습니다.

[34:03] 그다음 랜덤 생성기를 사용하기 전에 현재 값들을 가져왔고,

[34:07] observe를 사용해서 찾은 다음 랜덤 버튼을 한 번 클릭했습니다.

[34:12] 그리고 랜덤 버튼을 두 번째로 클릭했습니다. 실제 출력도 볼 수 있습니다.

[34:16] 각 실행의 출력을 볼 수 있고, 가장 좋은 점은

[34:19] 팀 멤버들과 이것을 공유할 수 있다는 것입니다.

[34:22] 화면 녹화뿐만 아니라 실제 작업과 출력에도 접근할 수 있게 하려면 말이죠.

[34:25] 이것이 Browser Base 플랫폼의 힘입니다. 이 모든 것들을 결합하면

[34:28] 정말 강력한 도구 모음이 되어 테스팅 인프라를 훨씬 향상시킵니다.

[34:31] 테스팅 인프라를 훨씬 좋게 만들어줍니다.

[34:34] 좋습니다 여러분, 오늘 튜토리얼의 끝에 다다랐습니다.

[34:37] 무언가를 만들 때 테스트 주도 개발을 사용하는 가치를 보셨기를 바랍니다.

[34:40] Stagehand의 힘과 함께 Claude Code를 사용하면, 이제 AI에게 눈을 주어

[34:44] 여러분이 만들고 있는 것을 볼 수 있게 하고, 관찰하고 추출하고 작업을 수행할 수 있습니다.

[34:49] 그리고 이를 테스트의 일부로 사용할 수 있습니다.

[34:53] 이 모든 것을 자연어의 힘으로 할 수 있습니다.

[34:56] 더 나아가, 더 이상 자신의 컴퓨터에만 제한되지 않고

[35:00] 클라우드의 힘을 활용해서 이런 테스트들을 실행하고

[35:04] 모든 추가 도구와 기능을 사용할 수 있습니다.

[35:06] 다시 한 번, 오늘 비디오를 후원해주신

[35:08] Browser Base에게 감사드립니다.

[35:10] 아래 설명란의 링크를 통해

[35:12] Stagehand, MCP 서버, 그리고 Browser Base의 모든 것을 받으실 수 있습니다.

[35:16] 오늘 비디오가 마음에 드셨다면 좋아요를 눌러주시고, 구독 버튼을 눌러주세요.

[35:20] 알림 벨도 켜는 것을 잊지 마세요.

[35:22] 이런 콘텐츠가 올라올 때 항상 가장 먼저 알 수 있도록 말이죠.

[35:25] 아, 그리고 Claude Code에서 제가

[35:28] 이 커스텀 상태 줄을 가지고 있는 것을 보셨을 겁니다.

[35:31] Claude Code 세션에 관한 많은 정보를 보여줍니다.

[35:33] 사용 중인 모델, 남은 컨텍스트, 그리고

[35:36] 달러와 토큰으로 표시되는 소모율을 보여줍니다.

[35:38] 이것을 어떻게 구할 수 있는지 또는 직접 만드는 방법을 알고 싶으시다면,

[35:42] 여기 제가 만든 단계별 비디오 튜토리얼을 꼭 확인해보세요.

[35:45] 좋습니다.

[35:46] 다음번까지, 안녕히계세요.