GitHub 스펙 키트 💖 GitHub Copilot CLI

Den Delimarsky 구독자 6,290명

요약

이 영상은 GitHub Spec Kit을 GitHub Copilot CLI와 함께 사용하는 방법을 단계별로 데모합니다. 터미널에서 Copilot CLI 설치부터 프로젝트 초기화, Spec Kit 워크플로우(헌법→명세→명확화→계획→작업→분석→구현) 명령 실행까지 보여줍니다. 커스텀 슬래시 명령어를 prompts 폴더 파싱으로 우회 사용하고, CloudSonnet 4와 GPT-5 모델 전환 기능으로 AI 출력 방식을 선택할 수 있는 점이 핵심입니다. 마지막으로 Next.js 기반의 팟캐스트 랜딩 페이지를 자동 생성하고, /feedback 명령어로 환경별 이슈를 팀에 바로 전달할 수 있도록 안내합니다.

주요 키워드

Spec Kit GitHub Copilot CLI 커스텀 슬래시 명령어 CloudSonnet 4 GPT-5 npm 설치 멀티모달 Constitution Next.js /feedback

하이라이트

🚀 터미널에서 GitHub Copilot CLI를 npm으로 빠르게 설치해 곧바로 AI 코딩 에이전트를 사용할 수 있습니다.
🔧 Spec Kit 워크플로우 명령어(Constitution, Specify, Clarify, Plan, Tasks, Analyze, Implement)를 순차적으로 CLI에서 실행해 완전한 개발 사이클을 제공합니다.
💡 prompts 폴더에 정의된 커스텀 슬래시 명령어를 파싱해, 아직 공식 지원이 없어도 Spec Kit 명령을 우회 실행할 수 있습니다.
🌐 Copilot CLI는 CloudSonnet 4(자세한 로그)와 GPT-5(간결 실행) 간 멀티모달 모델 전환 기능을 지원합니다.
📂 명령 실행 시마다 브랜치를 자동 생성하고 변경 파일을 바로 Git 상태로 표시해 버전 관리를 깔끔하게 도와줍니다.
🎨 /implement 명령어로 Next.js 기반 정적 팟캐스트 랜딩 페이지 실제 코드를 자동 생성하고 로컬 서버에서 즉시 확인합니다.
🛠️ /tasks와 /analyze로 작업을 세분화하고 전체 스펙과 헌법 간 충돌 여부를 분석해 개발 품질을 높입니다.
🗣️ /feedback 명령어로 Windows PowerShell, macOS, Linux 등 환경별 오류를 GitHub 이슈로 손쉽게 제출할 수 있습니다.

용어 설명

GitHub Copilot CLI

GitHub에서 제공하는 터미널 기반 AI 코딩 에이전트로, 명령어 체인으로 코드 생성·분석 지원

Spec Kit

AI 워크플로우 도구로서 헌법, 명세, 계획, 구현 등의 슬래시 명령어 체인을 통해 프로젝트 사양을 자동화

멀티모달(Multi-modal)

CloudSonnet 4와 GPT-5 같은 서로 다른 언어 모델 간에 전환해 다양한 출력 스타일을 지원하는 기능

커스텀 슬래시 명령어

prompts 폴더 안에 사용자가 직접 정의하는 /specify, /clarify 등 맞춤형 작업 명령어

CloudSonnet 4

GitHub Copilot CLI의 기본 모델로, 자세한 로그와 단계별 동작을 보여주는 언어 모델

GPT-5

Copilot CLI에서 선택 가능한 차세대 모델로, 더 간결하고 독립적인 코드 생성을 제공

npm 설치

Node.js 패키지 관리 도구를 이용해 GitHub Copilot CLI를 전역 설치하는 과정

Next.js

React 기반 정적 사이트 생성 프레임워크로, Spec Kit으로 자동 생성된 팟캐스트 랜딩 페이지 구현에 사용

VS Code

명령 결과물을 확인·편집하기 위해 병행 사용되는 코드 에디터

/feedback

Copilot CLI 사용 중 발생한 오류나 제안을 GitHub 이슈로 바로 전달하는 명령어

새롭게 발표된 GitHub Copilot CLI 개념과 멀티모달 모델(GPT-5/CloudSonnet 4) 전환 기능을 간단히 소개합니다.

[00:00] GitHub Copilot CLI라는 새로운 도구 소개. 오늘 막 발표된 따끈따끈한 코딩 에이전트로, GitHub에서 제공하는 네이티브 도구입니다.

[00:18] 기존 코딩 도구들(cloud code, Gemini CLI, openAI codex)과 비교 설명. GitHub Copilot 멀티모달 기능으로 GPT-4에서 GPT-5로 전환 가능한 특징을 강조합니다.

[00:42] 설치 방법 안내. github.com/github/copilot-cli에서 npm install 명령어를 복사해서 실행하고 로그인하면 바로 사용 가능합니다.

github.com/github/copilot-cli에서 npm install 명령으로 설치 후, 터미널에서 로그인해 Copilot CLI 사용 준비를 완료합니다.

[00:55] 사용자 경험의 특별함을 강조하며 애니메이션 기능을 시연. 시각적으로 매력적인 인터페이스를 보여주며 도구의 완성도를 어필합니다.

[01:18] 실제 사용 데모 시작. spec kit과 함께 새 프로젝트 'copilot term test'를 초기화하는 과정을 보여줍니다.

copilot spec init 명령으로 새 프로젝트를 만들고, PowerShell 환경에서 디렉터리 구조와 기본 파일(README, prompts 등)을 확인합니다.

[01:36] GitHub Copilot CLI가 표준 GitHub Copilot 규칙을 따르므로 copilot 옵션을 직접 지정할 수 있음을 설명. PowerShell 사용 예시를 보여줍니다.

[01:53] UI 개선사항 소개. 향상 명령어들이 별도 섹션에 구분되어 있고, clarify와 analyze는 선택적으로 사용 가능한 유용한 명령어임을 설명합니다.

[02:08] 프로젝트 폴더 이동 및 VS Code 재시작. Copilot이 파일 변경사항을 처리하는 과정을 실시간으로 보여주기 위한 준비 과정입니다.

[02:33] 생성된 프로젝트 구조 확인. GitHub, prompts, specify 폴더 등 spec kit의 기본 구성요소들을 설명하며 실제 사용 준비를 마무리합니다.

[02:56] 화자가 copilot-banner를 사용하여 이전 명령어들을 스크롤하고, 매번 시작할 때마다 애니메이션을 보고 싶어한다고 설명합니다. 모든 도구를 허용하여 스크립트 실행 시 동의 프롬프트 없이 위험하게 살겠다고 합니다.

Copilot CLI에 아직 없는 커스텀 슬래시 명령을 prompts 폴더 파싱으로 인지시켜 /specify, /clarify 등을 우회 실행하는 방법을 시연합니다.

[03:27] 다른 터미널 CLI와 마찬가지로 슬래시 명령어를 지원한다고 설명하며, help 명령어를 통해 Copilot이 할 수 있는 작업들을 보여줍니다. Copilot이 다양한 위치의 지시사항 파일들(agents.md, claude.md, gemini.md 등)을 이해할 수 있다고 강조합니다.

[04:10] Copilot CLI가 아직 사용자 정의 슬래시 명령어를 지원하지 않는다는 한계를 언급하지만, GitHub/prompts의 슬래시 명령어들을 사용하도록 유도할 수 있다고 설명합니다. 슬래시 명령어가 본질적으로 사용자 정의 프롬프트라고 정의합니다.

[04:54] VS Code의 GitHub prompts에서 analyze, clarify, constitution, implement, plan, specify, tasks 등의 슬래시 명령어들을 보여줍니다. 더 똑똑한 방법으로는 이러한 설정을 agents.md나 copilot instructions.md에 인코딩하여 매번 설명할 필요가 없게 할 수 있다고 제안합니다.

[05:17] Copilot이 실제로 스크립트를 실행하여 폴더 내용을 이해하고 있다고 보여줍니다. 디렉토리를 나열하고 analyze, clarify, constitution, problems, implement 등의 콘텐츠를 파싱하여 프롬프트들을 바탕으로 할 수 있는 작업들을 내재화하고 있다고 설명합니다.

[05:33] GitHub Spec Kit에서 힌트의 중요성을 설명하며, 프로젝트에서 사용할 슬래시 명령어들을 시스템에 알려주는 역할을 한다고 설명합니다. 재사용을 위해서는 agents.md 같은 파일에 저장하는 것이 좋다고 조언합니다.

[05:48] 시스템이 인식한 명령어들을 나열합니다: specify, clarify, plan, task, analyze, implement, constitution. 아직 슬래시 명령어를 완전히 지원하지는 않지만 prompts 폴더 파싱을 통해 이 기능이 가능해졌다고 설명합니다.

/constitution 명령으로 프로젝트 헌법 문서를 자동 생성하고, CloudSonnet 4의 자세한 로그로 템플릿 검사 과정을 실시간으로 확인합니다.

[06:08] spec kit의 전형적인 방식으로 constitution 명령어부터 시작한다고 설명하며, /constitution을 사용하되 아직 자동완성이나 인텔리센스 기능은 없다고 언급합니다. 개발팀에서 이 기능을 검토 중이라고 전합니다.

[06:35] constitution 명령어를 실행하여 'static web app with minimal dependencies'를 입력합니다. 시스템이 constitution 프롬프트를 처리하고 파일을 생성하는 과정을 관찰하려고 합니다.

[07:04] 모델 선택의 중요성을 설명합니다. Claude Sonnet 3.5는 자세한 설명을 제공하여 진행 상황을 확인할 수 있지만, GPT-4o는 더 독립적으로 작업하여 결과만 제공한다고 비교합니다.

[07:41] Sonnet 3.5의 기본 설정을 사용하여 모든 과정을 볼 수 있도록 구축한다고 설명합니다. 시스템이 constitution 파일 수정을 시도하는 과정에서 약간의 루프가 발생했지만, constitutional update 명령의 일부로 템플릿들도 함께 업데이트한다고 설명합니다.

[08:24] 구성 요구사항과 일치하는지 확인하며 GPT-4와 달리 추측할 필요 없이 예상대로 작업을 수행하는 것을 확인합니다.

[08:40] 템플릿 구성 체크 섹션에서 명령어 관련 오류가 나타나며, Windows용 Copilot CLI 미리보기에서 새로운 오류가 발생할 수 있음을 설명합니다.

[08:56] 문제 발견 시 '/feedback' 명령을 사용해 팀에 이슈를 보고하라고 안내하며, 특히 Windows PowerShell 환경에서의 피드백 중요성을 강조합니다.

[09:23] Sonnet 4가 매우 장황할 수 있어 구성 작업 완료를 기다리며, VS Code에서 변경사항을 확인합니다.

/specify로 기능 요구사항 작성, /clarify로 미지정 항목 질문, /plan으로 Next.js 기반 기술 계획과 데이터 모델·아키텍처를 수립합니다.

[09:51] Git 저장소에서 최소한의 종속성, 정적 우선, 점진적 향상 등의 구성 변경사항을 확인하고 AI가 요청사항을 정확히 수행했음에 만족합니다.

[10:15] 커스텀 슬래시 명령어 힌트가 지원되지 않지만 '/specify'를 사용해 '세 개의 주요 에피소드가 있는 팟캐스트 랜딩 페이지'를 지정합니다.

[10:46] 스크립트 실행 중 브랜치가 동적으로 '001 팟캐스트 랜딩 페이지'로 변경되는 것을 확인하며 올바른 방향으로 진행되고 있음을 확신합니다.

[11:12] PowerShell 스크립트가 성공적으로 생성되었고, /specify 명령이 제대로 작동하는 것을 확인하며 매우 기뻐하고 있습니다. 커스텀 슬래시 명령이 나오기 전에 이런 우회 방법을 사용할 수 있다는 점에 특히 만족해하며, 이 방법이 다른 용도로도 활용 가능하다고 설명합니다.

[11:46] VS Code에서 생성된 스펙을 확인하고, 팟캐스트 랜딩 페이지와 관련 스펙이 성공적으로 만들어진 것을 확인합니다. 이제 더 본격적인 테스트를 위해 clarify 명령을 소개하며, 이 명령이 문서의 모호한 부분을 퀴즈로 질문하고 명확화를 요청하는 기능을 설명합니다.

[12:31] GitHub Copilot CLI에서 clarify 명령을 실행하여 테이블 형태로 질문이 렌더링되는 것을 확인합니다. 랜딩 페이지의 추천 에피소드 선택 방법과 팟캐스트 플랫폼 포함에 대한 두 가지 질문에 각각 A와 B 옵션으로 답변하며, 이전보다 명세 부족 부분이 줄어든 것에 만족해합니다.

[13:47] clarify 명령 실행 결과가 spec.md 파일에 자동으로 반영되는 과정을 지켜보며 매우 만족스러워합니다. 명확화된 내용들이 기록되고 파일이 업데이트되는 것을 확인하며 전체 프로세스가 성공적으로 진행되고 있다고 평가합니다.

[14:06] 화자가 GitHub Copilot이 코드 변경사항의 diff를 보여주지 않는 것에 대해 언급하지만, 대신 명확화한 내용들의 요약을 제공하는 것을 확인합니다.

[14:19] 생성된 spec 파일을 확인하며, 날짜는 정확하지 않지만 세션과 명확화 답변들이 제대로 캡처되었음을 확인합니다.

[14:41] 필요한 데이터와 기능 요구사항이 모두 캡처되어 성공적으로 요구사항을 정리했다고 평가합니다.

[14:55] 다음 단계로 기술 계획을 위한 'plan' 명령어를 실행하며, Next.js를 사용한 정적 사이트 빌드, 데이터베이스 없이 더미 데이터만 사용하는 계획을 제안합니다.

[15:22] plan 단계의 헬퍼 스크립트가 실행되고, 시스템이 계획을 위해 필요한 작업들을 분석하기 시작합니다.

[15:44] 작업이 완료된 후 VS Code에서 결과를 확인하며, plan.md 파일과 아키텍처 개요, 퀵스타트 연구 데이터 등이 예상대로 생성되었음을 확인합니다.

[16:17] 빠른 반복을 위해 테스트 관련 부분을 제거하기로 결정하며, 팟캐스트 랜딩 페이지에는 테스트가 불필요하다고 판단합니다.

[16:55] 테스트 제거가 완료되고, 커스텀 슬래시 명령어들이 하이라이트되는 기능을 확인합니다. 마지막으로 /tasks 명령어를 실행하여 개별 작업들로 나누는 단계로 진행합니다.

[17:17] LLM이 수행할 수 있는 작업들에 대해 설명하며, 커스텀 슬래시 명령어들이 성공적으로 작동하고 있다고 확인합니다. 헬퍼 스크립트들과 인수를 받는 슬래시 명령어들이 모두 정상 작동한다고 언급합니다.

/tasks로 작업을 분할하고, /analyze로 스펙과 헌법 간 충돌 여부를 검사합니다. Windows 환경 오류 시 /feedback으로 이슈를 제보합니다.

[18:02] 작업 완료를 기다리며, 영상의 대부분이 기다리는 시간이라고 농담을 합니다. 예상보다 빨리 완료되었다고 하며 VS Code로 돌아가서 결과를 확인합니다.

[18:20] 생성된 작업들을 확인합니다. 데이터 타입 기반 핵심 컴포넌트 설정, 페이지 통합, 세련화 및 최적화 등의 작업들이 합리적으로 생성되었다고 평가합니다.

[18:35] GitHub Copilot CLI에서 테스트할 또 다른 명령어인 slash analyze를 소개합니다. 이 명령어가 까다로운 이유는 모든 맥락적 정보를 결합해야 하며, 명세되지 않은 부분이나 헌법과 충돌하는 부분을 분석해야 하기 때문입니다.

[19:00] CLI에서 작업하는 것의 장점에 대해 설명합니다. VS Code보다 더 많은 공간을 확보할 수 있어 단계들을 명확하게 볼 수 있다고 합니다. 터미널 환경에 완전히 몰입할 수 있고, diff 기능은 아쉽지만 VS Code나 Zed, Sublime Text 같은 에디터들을 diff 메커니즘으로 활용할 수 있다고 언급합니다.

[19:52] 터미널과 VS Code를 활용한 개발 워크플로우를 설명하며, 파일 변화 확인과 충돌 해결 과정을 보여줍니다.

[20:10] /implement 명령어를 통해 GitHub Copilot CLI와 Claude Sonnet 4를 사용하여 팟캐스트 랜딩 페이지 구현을 시작합니다.

/implement 명령으로 Next.js 팟캐스트 랜딩 페이지 코드를 생성하고 빌드·실행해 localhost:3000에서 최종 결과를 직접 확인합니다.

[20:40] 구현 과정에서 음악이 재생되며 대기 시간을 보냅니다.

[21:20] 구현 완료 후 터미널에서 결과를 확인하고 package.json을 살펴본 뒤 npm install과 build 과정을 진행합니다.

[22:13] npm run dev 실행 후 localhost:3000에서 생성된 팟캐스트 랜딩 페이지를 확인하며, Sarah Johnson이 호스트하는 완성된 웹사이트를 확인합니다.

[22:37] Copilot CLI의 성과에 만족을 표하며, copilot 배너 애니메이션을 즐겁게 감상합니다.

[00:00] 안녕하세요 여러분! 오늘은

[00:01] GitHub spec kit과 함께

[00:05] 오늘 막 발표된 새로운 도구에 대해 이야기해보겠습니다.

[00:07] 갓 나온 따끈따끈한 새 기능이에요.

[00:09] 지금 이 영상을 통해 라이브로 소개하는 건데요.

[00:12] 바로 GitHub Copilot CLI입니다.

[00:14] 맞습니다. 이제 우리에게 코딩 에이전트가 생겼어요.

[00:18] 만약 여러분이

[00:20] cloud code나 Gemini CLI, 또는 openAI codex를 사용해봤다면

[00:22] 이제 GitHub Copilot CLI도 사용할 수 있습니다.

[00:25] GitHub에서 제공하는 네이티브 도구죠.

[00:28] 그런데 이것도

[00:30] GitHub Copilot 멀티모달이라서

[00:32] 기본 GPT-4에서 GPT-5로도 전환할 수 있어요.

[00:35] 이게 실제로 제공되는 기능입니다.

[00:38] 그러니까, 꽤 멋진

[00:40] 기능이죠. 어쨌든

[00:42] 오늘부터 다운로드 받을 수 있고

[00:43] github.com/github/copilot-cli로 가시면

[00:46] 조금만 스크롤 내리면

[00:47] npm install이 보일 거예요.

[00:50] 그걸 복사해서 실행하시고

[00:52] 로그인하시면 바로 사용할 수 있습니다.

[00:55] 그리고 정말 말해야겠는데, 사용 경험이

[00:58] 정말 기발해요. 왜 그런지 보여드릴게요.

[01:01] 한번 보여드릴게요.

[01:04] 이걸 보세요. 보셨나요? 오케이.

[01:08] 다시 해볼게요.

[01:09] 정말 좋아서 다시 보여드릴게요.

[01:10] 오케이.

[01:12] 아, 보세요. 이 애니메이션을 보세요.

[01:14] 정말 멋져요. 너무 좋아요. 이거

[01:17] 정말 마음에 들어요. 어쨌든, 우리는

[01:18] spec kit에 대해 이야기하고 있으니까

[01:20] 앞서 사용했던 명령어 목록을

[01:21] 스크롤해서 살펴보겠습니다.

[01:24] 새로운 프로젝트를 초기화해야 하니까요.

[01:26] 그리고 이걸 copilot이라고 부를 거예요.

[01:29] term test - 터미널을 사용하니까요.

[01:32] 좋습니다.

[01:35] 왜냐하면

[01:36] GitHub Copilot CLI는

[01:39] GitHub Copilot의 표준 규칙을 따르기 때문에

[01:42] 저는 그냥 copilot 옵션을 사용해서 지정할 수 있어요.

[01:45] 그래서 여기서 엔터를 누르고

[01:47] PowerShell을 사용할 수 있죠.

[01:49] 우리가 사용하는 것이니까요.

[01:51] 그리고 참고로 작은 삶의 질

[01:53] 개선사항도 있어요. 이제

[01:54] 향상 명령어들이

[01:56] 별도의 섹션에 구분되어 있습니다.

[01:58] 혹시 생각하시기를

[02:00] 잠깐, 성공하려면

[02:02] 이 모든 걸 실행해야 하나? 아니에요.

[02:04] clarify와 analyze는 실제로

[02:05] 여러분이 직접 활용할 수 있는 유용한 명령어들입니다.

[02:08] 이제 여기 폴더로 들어갈 수 있어요.

[02:11] 프로젝트가 생겼으니까

[02:13] cd copilot로 들어가보겠습니다.

[02:16] term test. 좋습니다. 그리고 제가

[02:20] 거짓말하는 게 아니라는 걸 확실히 하기 위해

[02:21] 기존의 VS Code 인스턴스를

[02:23] 닫고 새로운 걸 열어서

[02:26] Copilot이 우리 repo의

[02:28] 파일들을 반복작업할 때

[02:31] 실제로 변경사항을 볼 수 있도록 보여드리겠습니다.

[02:33] 그리고 여기 우리가 익숙한 것들이 있어요.

[02:35] GitHub과 prompts가 있고

[02:36] specify 폴더도 있습니다.

[02:38] 다시 말씀드리면, speckit을 사용해보셨다면

[02:41] 이게 뭔지 아실 거고, 모르신다면

[02:43] 이전 영상들을 보세요.

[02:44] 설명란에 있습니다. 오케이. 이제 이 폴더에서

[02:47] 작업하기 위해 copilot을 사용할 거고

[02:50] copilot을 몇 가지 매개변수나

[02:52] 인수들과 함께 사용할 건데

[02:55] 제가 전달할 매개변수들 말이에요.

[02:56] 이전 명령어들을 스크롤해보겠습니다.

[02:57] 그리고 이건

[02:58] copilot-banner가 될 거예요

[03:00] 저는 애니메이션을 너무 좋아하거든요. 매번

[03:01] 시작할 때마다 그 애니메이션을 보고 싶어서

[03:03] 모든 도구를 허용하도록 했습니다. 이렇게 하면

[03:06] 위험하게 살 수 있어요. 말 그대로

[03:08] 한계에서 살아갈 수 있죠. 왜냐하면

[03:09] 기본적으로 스크립트가 실행될 때

[03:11] 동의를 구하는 프롬프트가 뜨지 않거든요.

[03:13] VS Code에서도 본 적 있는 기능인데,

[03:15] 참고로 이것도 비활성화할 수 있어요. 하지만 저는

[03:16] 그냥 켜두고 있습니다. 그럼

[03:18] 이대로 실행해보겠습니다. 와, 정말 보세요.

[03:21] 매번 이 애니메이션을 볼 때마다

[03:23] 정말 멋져요. 이제

[03:24] 폴더를 신뢰하겠습니다. 자, 다른

[03:27] 터미널 CLI와 마찬가지로, 슬래시

[03:30] 명령어도 지원합니다. 슬래시를 입력하면

[03:32] 여러 명령어들을

[03:34] 스크롤해서 볼 수 있어요, 맞죠? 그리고 이 경우에는

[03:36] help라고 입력하면 Copilot이

[03:38] 무엇을 할 수 있는지 보여줍니다.

[03:40] 여기서 매우 흥미로운 점은

[03:43] Copilot이 정말 뛰어나게 하는 것이

[03:44] 실제로 다양한 위치의

[03:47] 지시사항을 이해한다는 거예요. 단 하나의

[03:49] instructions.md 파일에만 제한되지 않고

[03:51] agents.md, claude.md,

[03:54] gemini.md, 또는 물론

[03:56] instructions.md가 있는 모든 파일에서 읽을 수 있어요.

[03:58] 정말 깔끔하다고 생각해요. 이런 컨벤션 덕분에

[04:00] 기본적으로

[04:02] 서로 다른 터미널 에이전트로 만든

[04:03] 다양한 프로젝트에서 작업할 수 있고

[04:06] Copilot CLI와 그냥 플러그 앤 플레이로

[04:08] 연동됩니다. 하지만 어쨌든, Copilot CLI가

[04:10] 아직 없는 한 가지가 있는데

[04:12] 사용자 정의 슬래시 명령어입니다. 그리고 이건

[04:14] 표면적으로는 제한적인 요소처럼

[04:16] 보일 수 있어요. 왜냐하면 여러분은

[04:18] 'spec kit의 핵심이

[04:19] 사용자 정의 슬래시 명령어를 사용하는 거 아니야?'라고

[04:22] 생각할 테니까요. 맞습니다. 하지만 여기엔 함정이 있어요.

[04:26] GitHub Copilot CLI가 실제로

[04:29] 이 슬래시 명령어들을 사용하는 방법을

[04:31] 이해하도록 유도할 수 있어요. 그리고 이건 매우 쉽게

[04:32] 할 수 있습니다. 제가 여기서 하는 걸 보세요.

[04:34] 우리는 그냥 Copilot에게

[04:36] GitHub/prompts에서

[04:42] 슬래시 명령어들을 사용할 거라고

[04:45] 알려줄 거예요. 왜냐하면 기억하세요, 슬래시 명령어는

[04:47] 사용자 정의 프롬프트

[04:50] 외에는 아무것도 아니거든요. 사용자 정의

[04:52] 프롬프트죠, 맞죠? VS Code로 가서

[04:53] GitHub prompts를 보면,

[04:54] 맞죠? analyze, clarify, constitution,

[04:56] implement, plan, specify, tasks가 있어요.

[04:58] 이 모든 게 슬래시 명령어들입니다.

[05:02] 그래서 Copilot CLI가 아직 슬래시 명령어를

[05:04] 지원하지 않는다면, 우리가

[05:05] 이게 뭔지 알려줄 거예요. 그리고 물론, 여러분이

[05:08] 저보다 똑똑하다면, 아마

[05:09] agents.md나 copilot instructions.md에

[05:12] 이걸 인코딩해서 새 세션을 실행할 때마다

[05:14] Copilot에게

[05:16] 매번 설명할 필요가 없게 만들 수 있을 거예요.

[05:17] 하지만 이것 좀 보세요. 실제로

[05:18] 제가 그 폴더들에 뭐가 있는지 이해하기 위해

[05:21] 스크립트를 실행하고 있어요. 실제로

[05:23] 디렉토리를 나열하고 있습니다. 그리고

[05:24] 보세요, analyze, clarify,

[05:26] constitution, problems, implement라고 나오네요.

[05:28] 콘텐츠를 파싱하고 있어요, 맞죠?

[05:30] 그 프롬프트들을 바탕으로 실제로

[05:31] 할 수 있는 작업들을 내재화하고 있습니다

[05:33] 힌트를 제공했기 때문입니다. 이 힌트가

[05:36] 중요합니다. 이 힌트가 시스템에게

[05:39] 이 프로젝트에서 사용할

[05:40] 슬래시 명령어들을 알려주는 역할을 합니다.

[05:41] 다시 말하지만, 이것을 재사용할 계획이라면

[05:43] agents.md와 같은 재사용 가능한 파일에

[05:46] 구워넣는 것이 도움이 됩니다.

[05:48] 명령어들은 순서대로 작동하도록 설계되었습니다.

[05:51] specify, clarify,

[05:52] plan, task, analyze, implement, 그리고

[05:55] constitution이 있습니다. 시스템이 명령어들을

[05:58] 식별했군요. 실제로 사용 가능한

[05:59] 슬래시 명령어들을 제공해 줍니다.

[06:01] 아직 슬래시 명령어를 지원하지는 않지만,

[06:02] prompts 폴더를 파싱했기 때문에

[06:04] 이제 이렇게 할 수 있게 되었습니다. 훌륭하네요.

[06:08] 전형적인 spec kit 방식으로

[06:11] constitution부터 시작하겠습니다.

[06:13] /constitution을 사용할 겁니다.

[06:15] 여기서는 힌트가 없습니다.

[06:17] /constitution을 사용하는 이유는

[06:19] 그렇게 해야 하기 때문이죠. 하지만 드롭다운이나

[06:22] 인텔리센스가 없어서

[06:24] 'constitution이 존재한다'고

[06:26] 알려주지 않습니다. 그들이 이 부분을

[06:28] 검토하고 있습니다. 확실한 정보통으로부터

[06:30] 들었는데 이 부분을

[06:31] 검토하고 있다고 합니다. constitution을

[06:35] 사용해서 'static web app with

[06:37] minimal dependencies'라고 입력하겠습니다.

[06:45] 모든 것이 잘 되면 실제로

[06:48] constitution 프롬프트를 처리하고

[06:51] constitution을 생성하는지 확인해볼 겁니다.

[06:53] 올바른 폴더를 보고 있는지...

[06:54] 경로가 존재하지 않네요. readme...

[06:55] 네, 맞습니다. 지정된 템플릿들을

[06:58] 보고 있군요.

[07:00] constitution 문서가

[07:04] 불러와지면서 실제로

[07:07] 콘텐츠를 파싱합니다. 이것은 모델 선택에서

[07:10] 중요한 부분 중 하나입니다.

[07:12] copilot CLI가

[07:14] 멀티모델이라는 사실을 언급했는데,

[07:15] GPT-4o나

[07:17] Claude Sonnet 3.5를 사용할 수 있습니다.

[07:19] Claude Sonnet 3.5는 매우 자세합니다.

[07:22] 무엇을 하고 있는지 알려줍니다. 여기를 보면

[07:25] 실제로 plan 템플릿이나

[07:27] task 템플릿을 보고 있다고

[07:28] 말해주므로

[07:30] 상태를 파악할 수 있습니다.

[07:32] GPT-4o는 훨씬 독립적입니다.

[07:35] 기본적으로 '내가 해결하고

[07:37] 필요한 것을 정확히 제공했다고

[07:40] 믿어달라'는 식으로 생각합니다.

[07:41] 여기서 우리가 할 일은

[07:44] 기본적으로 기본 설정을

[07:48] 사용하도록 보장하는 것입니다.

[07:51] Sonnet 3.5와 함께

[07:52] 기본 설정을 사용하고, 일어나는 모든 것을

[07:57] 볼 수 있도록 구축할 겁니다.

[07:59] 여기서 자세한 과정을 보고 싶습니다.

[08:02] constitution ID 생성

[08:03] 경로가 이미 존재한다고 하네요.

[08:05] 일치하는 항목이 없다고 하니

[08:08] constitution 파일을 수정하려고

[08:09] 합니다. 약간의 루프를 거쳤네요.

[08:11] 괜찮습니다. 그럴 수 있습니다.

[08:13] 또한 템플릿들도 업데이트할 겁니다.

[08:15] 그것이 사양의 일부이거나

[08:16] constitutional update 명령의 일부이기 때문에

[08:18] 실제로 템플릿들도

[08:20] 업데이트해서

[08:21] 확실히 하려고 합니다.

[08:24] 구성 요구사항과 일치하는지 확인하고 있어요.

[08:25] 다시 말하지만, 이미 내장되어 있고

[08:28] 예상한 대로 작업을 수행하는 것을 확인할 수 있습니다.

[08:32] GPT-4와 달리 추측할 필요가 없어요.

[08:34] 그럼 실제로 무슨 일이 일어날지 살펴볼까요.

[08:36] 여기서 실제로

[08:38] 템플릿 구성 체크 섹션을 살펴보고 있는 것을 볼 수 있습니다.

[08:40] 좋아요. 명령어에 이름이나 명령어 이름 하위 요소가 없다고 나오네요.

[08:43] 음, 이런 오류는 처음 보는데요.

[08:44] 그런데 Windows에서 Copilot CLI를 사용하면

[08:46] 이전에 보지 못한 오류가 발생할 수 있습니다.

[08:48] 이건 미리보기 소프트웨어이기 때문에

[08:50] 그런 일이 일어날 수 있어요.

[08:52] 프리뷰 소프트웨어니까요.

[08:54] 팀에 알려주세요.

[08:56] '/feedback'을 사용해서

[08:58] 발견한 문제에 대한 이슈를 열 수 있어요.

[09:01] Windows에서 실행 중이시라면

[09:03] 또는 어디서든 실행 중이시라면

[09:04] '/feedback'을 사용하세요.

[09:06] 특히 Windows에서

[09:07] PowerShell 위에서 WSL2가 아닌 환경에서 실행 중이시라면

[09:09] '/feedback'이 정말 유용할 거예요.

[09:12] 뭔가 문제가 있다면

[09:15] 팀에 알려주세요.

[09:16] 꽤 자주 이런 문제들을 분류하고 있거든요.

[09:19] 좋습니다. 지금 우리는

[09:22] 구성 작업이 완료되기를 기다리고 있어요.

[09:23] 그리고 Sonnet 4는

[09:25] 매우 장황할 수 있고 저처럼

[09:28] 영원히 계속 떠들 수 있어요.

[09:31] 작업이 끝날 때까지 기다려서

[09:34] 결과가 어떻게 나오는지 보겠습니다.

[09:37] 자, 이제

[09:38] 구성이 준비되었고

[09:40] 향후 모든 개발을 안내할 것 같지만

[09:42] 확인해볼게요. 아직은 믿지 못하겠어요.

[09:43] VS Code로 가보죠.

[09:45] 여기서 specify를 보고

[09:47] 메모리 구성을 확인할 수 있어요. 좋아요.

[09:51] 네, 변경된 내용들을 볼 수 있어요.

[09:52] Git 저장소에서 이런 표시들을 보실 수 있죠.

[09:54] 최소한의 종속성, 정적 우선,

[09:56] 점진적 향상, 성능 우선,

[09:58] 접근성과 표준.

[10:00] 네, 맞아요. 템플릿에 맞게 작업했네요.

[10:03] 제대로 했어요. 훌륭합니다.

[10:05] 이걸 정말 좋아해요. 제가 요청한 대로

[10:08] 정확히 해준 것이 정말 마음에 들어요.

[10:11] 좋아요, 명령어 하나 완료했습니다.

[10:13] '/constitution'이 있고, 이제 '/specify'로 가볼게요.

[10:15] 다시 말하지만, 힌트를 받지 못하고 있는데

[10:17] 아직 커스텀 슬래시 명령어를

[10:18] 지원하지 않기 때문이에요.

[10:19] 하지만 어쨌든 강제로 사용해볼게요.

[10:21] specify. 그리고 '세 개의 주요 에피소드가 있는

[10:25] 팟캐스트 랜딩 페이지'라고 하겠습니다.

[10:30] 또 무엇을 지정할까요.

[10:32] 실제로는 데모용으로는

[10:33] 이 정도면 충분할 것 같아요. 괜찮을 거예요.

[10:37] 좋습니다. 모든 것이 잘 되면

[10:39] 스크립트가 실행될 것입니다.

[10:41] 경로를 설정하고 있네요. 괜찮습니다.

[10:43] 네, 경로를 사용할 수 있어요.

[10:46] 음, 이거 보이시나요?

[10:48] 브랜치가 바뀌었어요. 실제로

[10:51] 이거 좋네요. 실제로 여기서

[10:53] '001 팟캐스트 랜딩 페이지'를 보여주고 있어요.

[10:56] 실제로 동적으로 변경했어요.

[10:58] 메인 브랜치에 있었는데

[11:00] 이제 팟캐스트 랜딩 페이지 1을 사용하고 있어요.

[11:03] 좋아요. 멋져요, 정말 멋져요.

[11:05] 이는 우리가 올바른 방향으로

[11:07] 가고 있다는 뜻인 것 같아요.

[11:09] 그리고 우리가 실행한 것을 보면서 이를 확인할 수 있습니다

[11:12] 헬퍼가 새로운 기능 PS1 PowerShell 스크립트를 생성했네요.

[11:15] 맞죠? 정말 좋은 신호입니다.

[11:17] 실제로 /specify 명령을 따르고 있어요.

[11:19] 저는 정말 기뻐요. 설명할 수 없을 만큼

[11:22] 이런 해킹이나 우회 방법이

[11:25] 존재한다는 사실에

[11:26] 얼마나 기뻐하는지요.

[11:29] 커스텀 슬래시 명령이

[11:31] 온라인에 나오기 전에

[11:34] 실제로 이걸 사용할 수 있거든요.

[11:36] 그리고 우리가 specit에 대해 이야기했는데

[11:39] 이건 다른 것들에도 적용될 수 있어요.

[11:40] 맞죠? specit에 대해

[11:41] 걱정할 필요가 없습니다.

[11:44] 커스텀 슬래시 명령이 있다면 말이에요.

[11:46] 어쨌든, 완료된 것 같네요.

[11:47] VS Code를 한번 살펴보죠.

[11:49] 다시 한번 확인하기 위해서요.

[11:53] 스펙, 팟캐스트 랜딩 페이지가 있고

[11:56] 우리의 스펙도 있네요. 좋아요.

[11:58] 이걸 생성했어요. 훌륭합니다.

[12:00] 우리의 스펙이 있네요. 이제

[12:03] 정말로 테스트해보겠습니다.

[12:05] VS Code에서 이전 영상에서

[12:07] 보여드린 것을 기억하시나요?

[12:09] clarify 명령을 소개했었죠.

[12:11] clarify 명령은 LLM이 여러분을 퀴즈로

[12:14] 테스트하고 옵션을 제공해줍니다.

[12:15] 어떤 옵션을 원하는지 말이에요.

[12:18] 만약 문서에 명세가 부족하거나

[12:20] 추가 컨텍스트가 없는 부분이 있으면

[12:22] 퀴즈를 내고 명확화를

[12:24] 요청할 거예요.

[12:26] VS Code에서는 테이블을

[12:28] 렌더링해서 A, B, C, D 옵션을 주거나

[12:31] 답을 직접 명시할 수 있게 해줍니다.

[12:33] GitHub Copilot CLI가 이 도전을

[12:35] 해결할 수 있는지 봅시다.

[12:38] clarify를 해보겠습니다.

[12:40] 그냥 clarify만.

[12:42] 이제 이게 어떻게

[12:43] 렌더링될지 정말 궁금하네요.

[12:45] 처음 보는 거라서 실패할 수도 있지만

[12:49] 저는 믿어요. 경험이

[12:51] 좋을 거라고 생각합니다.

[12:53] 스크립트를 실행한 것 같네요. 좋아요.

[12:55] 스펙에서 모호성을 찾고 있고

[12:57] 실제로 스펙 파일을 보고 있어요. 훌륭합니다.

[12:59] 와, 저것 보세요. 테이블을 렌더링하네요.

[13:02] 실제로 테이블을 제공합니다.

[13:05] 랜딩 페이지에서 세 개의 추천 에피소드를

[13:07] 어떻게 선택해야 하나요?

[13:10] 옵션 A... A를 선택하겠습니다.

[13:12] 이 경우 2개 중 1번 질문인 것 같네요.

[13:14] 명세가 부족한 게

[13:15] 별로 없는 것 같습니다. 이전 영상에서는

[13:16] 5개 질문이 있었는데

[13:18] 이제는 2개만 있어요.

[13:20] 제가 프롬프팅을

[13:22] 더 잘하게 된 것 같아요.

[13:24] 이게 완전히 간단한

[13:26] 더미 프로젝트라는 사실과는

[13:28] 전혀 관계없죠. 하지만, 뭐 어쨌든요.

[13:31] 두 번째 테이블입니다.

[13:33] 랜딩 페이지의 구독 링크에

[13:34] 어떤 팟캐스트 플랫폼을

[13:36] 포함해야 할까요?

[13:39] 네, B가 옵션인 것 같네요.

[13:42] B를 사용할 예정이고

[13:45] 이게 스펙에

[13:47] 포함되기를 바라겠습니다.

[13:50] spec.md를 편집합니다. 완벽해요.

[13:53] 명확화된 내용을 기록했습니다.

[13:55] 진행되고 있어요. 일어나고 있습니다.

[13:56] 일이 벌어지고 있어요, 여러분.

[14:00] 저것 보세요. 일이 일어나고 있어요.

[14:02] 뭔가 추가하고, 또 추가하고, 변경하고 있네요.

[14:06] 흥미롭네요. 저는 diff를 볼 수 있을 거라고 예상했는데,

[14:09] 아직은 diff를 보여주지 않네요.

[14:09] 추가된 줄, 삭제된 줄 같은 것들 말이에요.

[14:12] 하지만 괜찮습니다. 실제로 여기서

[14:15] 명확히 한 내용들의 요약을 보여주네요.

[14:16] 명확히 한 내용들의 요약을 보여주네요.

[14:19] 좋습니다. 좋아요. 한번 봅시다.

[14:21] 우리의 스펙이 있네요.

[14:24] 아하! 그리고 보세요.

[14:25] 예상했던 대로 세션을 캡처했습니다.

[14:28] 날짜가 조금 틀렸네요.

[14:30] 오늘이 올해 1월 27일은 아니거든요.

[14:34] 하지만 뭐 어때요.

[14:37] 명확화를 위한

[14:38] 답변들을 캡처했습니다.

[14:41] 확인해 볼까요? 네, 네, 네, 네.

[14:43] 여기 데이터가 있네요.

[14:45] 필요했던 콘텐츠가 있고요.

[14:46] 기능 요구사항을 위한

[14:49] 내용들을 캡처했습니다.

[14:52] 좋습니다. 요구사항이 있네요.

[14:55] 이제 다음 명령어는 plan입니다.

[14:57] 기술 계획이 필요하거든요.

[14:58] plan을 실행하겠습니다.

[15:02] 여기서 우리의 계획은 무엇이어야 할까요?

[15:04] Next.js JavaScript로

[15:07] 정적 사이트 빌드를 하는 것 같네요.

[15:11] 그리고

[15:13] 데이터베이스는 없고,

[15:15] O도 없고, 그냥 더미 데이터만요.

[15:20] 합리적인 것 같습니다.

[15:22] 이제 plan 단계에도 헬퍼 스크립트가 있어요.

[15:25] 실행되는지 볼게요.

[15:27] 실행됐네요. setup plan이 있고,

[15:30] 실행했고, 작동합니다.

[15:32] 이제 계획을 위해

[15:34] 무엇을 해야 하는지 생각하고 있네요.

[15:36] 계획은 좀 더 오래 걸리는

[15:38] 작업이니까요.

[15:41] 돌아와서 좀 더 생각해보겠습니다.

[15:42] >> 이런 일하기엔 나이가 너무 많아.

[15:44] >> 작업을 완료했네요. 한번 봅시다.

[15:46] VS Code로 가보죠.

[15:49] VS는 아니고 VS Code라고 해야겠네요.

[15:52] 여러 가지가 보이네요.

[15:55] plan.md가 있고

[15:57] 많은 게이트들과

[15:59] 아키텍처를 개요로 제시하고 있어요. 깔끔하네요.

[16:02] 모든 맥락이 있고,

[16:04] 퀵스타트 연구 데이터 모델

[16:06] 계약들까지. 실제로 예상했던 것들이네요.

[16:09] 이제, 이걸 확실히

[16:11] 더 빠르게 완료하고 싶어서

[16:13] 테스트는 하고 싶지 않아요.

[16:17] 이전 비디오처럼

[16:18] 테스트를 건너뛸 거예요.

[16:19] 제거한다고 하겠습니다.

[16:20] 계획과 관련 콘텐츠에서

[16:23] 테스트에 대한 모든 참조를 제거해 주세요.

[16:26] 테스트는 하고 싶지 않습니다.

[16:33] 다시 말하지만, 빠르게 반복할 거예요.

[16:34] 이건 팟캐스트 랜딩 페이지고,

[16:36] 팟캐스트 랜딩 페이지에는

[16:37] 테스트가 필요하지 않아요.

[16:39] 이제 테스트 관련

[16:42] 참조들을 제거하도록 하겠습니다.

[16:45] 참조들을 제거하도록 하겠습니다.

[16:47] >> 안돼, 제발

[16:50] 안돼. 제발 안돼. 안돼, 안돼,

[16:55] 안돼. 이제 좋은 상태인 것 같네요.

[16:57] 테스트가 없고 작업할 준비가 됐어요.

[16:59] 실제로 슬래시 커스텀

[17:02] 슬래시 명령어들을 하이라이트해 주네요.

[17:05] 아직 커스텀 슬래시 명령어를

[17:07] 지원하지는 않지만,

[17:09] 하이라이트는 해주니까 무엇을 해야 하는지 알 수 있어요.

[17:11] /tasks를 해봅시다.

[17:13] 이건 정말 멋진 경험이에요. 정말 좋아해요.

[17:15] tasks를 실행해서 개별 작업들로 나누겠습니다.

[17:17] 여러분이 이제 매우 익숙해져 있듯이

[17:20] LLM이 하나씩 수행할 수 있는 작업들일 뿐입니다.

[17:22] 하지만 실제로 스크립트도 성공적으로 실행되었네요.

[17:25] 그렇죠?

[17:26] 모든 헬퍼 스크립트들,

[17:27] 커스텀 슬래시 명령어의 모든 것들이

[17:29] 작동하고 있습니다. 정말 좋네요.

[17:31] 그뿐만 아니라

[17:34] 이러한 슬래시 명령어들은 이미

[17:36] 인수를 받아들이고 있습니다.

[17:38] 헌법에 대해 작업하고 나서

[17:40] 인수를 전달했던 것을 기억하시나요?

[17:41] 헌법 이후에 무엇이 일어날까요?

[17:42] slsp specify에 대해 논의했고

[17:45] 실제로 무엇을 명세하고 있는지 개요를 작성했던 것을 기억하시나요?

[17:47] 그것이 오늘 지원됩니다.

[17:49] 이렇게 할 수 있습니다.

[17:51] 전체 컨텍스트를 해석하지만

[17:52] 다른 CLI에서 볼 수 있는 깔끔한 UI는 보여주지 않습니다.

[17:54] 하지만 작동합니다.

[17:57] 그리고 이 영상이

[17:58] 프롬프트 폴더에서 직접 정의한

[18:00] 커스텀 명령어들에 대해 실제로 작동한다는 증거입니다.

[18:02] 그래서 우리는

[18:04] 작업들이 완료될 때까지 기다릴 것입니다.

[18:07] 다시 기다리는 것으로 돌아왔네요.

[18:09] 솔직히 이 영상의 대부분이 그냥 기다리는 시간입니다.

[18:11] 조금 더 기다려보겠습니다.

[18:12] >> 기다려보세요.

[18:13] >> 좋습니다. 예상보다 오래 걸리지 않았네요.

[18:14] 좋습니다.

[18:15] 우리는 좋은 상태입니다. 작업들을 받았고

[18:17] 다시 VS Code로 돌아가겠습니다.

[18:19] 살펴보겠습니다.

[18:20] 작업들을 받았습니다. 데이터 타입 기반

[18:23] 핵심 컴포넌트 설정이 있습니다.

[18:26] 좋습니다.

[18:28] 페이지 통합, 세련화 및 최적화가 있네요.

[18:32] 합리적인 것 같습니다.

[18:33] 하지만 여기에 또 다른 선택적 명령어가 있다는 것을 기억하세요.

[18:35] GitHub Copilot CLI에서 테스트하고자 하는 명령어가 있습니다.

[18:37] 그 명령어는 slash analyze입니다.

[18:40] 그것이 바로 까다로운 부분입니다.

[18:43] slash analyze는

[18:46] 모든 맥락적 정보를

[18:48] 우리가 함께 구성한 것들을 결합해야 합니다.

[18:52] 우리가 명세하지 못한 부분이나

[18:55] 헌법과 충돌할 수 있는 부분에 대한

[18:57] 실제 분석에 도달하기 위해서 말이죠.

[18:58] 출력이 무엇인지 살펴보겠습니다.

[19:00] 또한 제가 정말 좋아하는 것 중 하나는

[19:02] 제가

[19:03] VS Code 자체에서 작업하는 대신

[19:04] CLI 내에서 작업한다는 사실입니다.

[19:07] 더 많은 공간을 확보할 수 있기 때문입니다.

[19:09] VS Code에서는 무엇이 일어나고 있는지 볼 수 있는 더 많은 공간이 있습니다.

[19:13] VS Code는 오른쪽에 있어서 불편하기 때문입니다.

[19:15] 창을 확장하고 코드를 숨기기 시작하지 않는 한

[19:17] 제약을 받아야 합니다.

[19:19] 하지만 터미널에서는

[19:21] 이 경험에 완전히 몰입할 수 있습니다.

[19:23] 이것을 보세요.

[19:24] 단계들이 명확하게 보입니다.

[19:27] 큰 화면이 있고 이 영상에서 보시는 해상도로 에뮬레이션된

[19:30] 작은 화면이 아니라면

[19:32] 무엇이 일어나고 있는지에 대해

[19:34] 많은 것들을 볼 수 있습니다.

[19:35] 여전히 diff 같은 것이 그립지만

[19:36] 괜찮습니다. 하지만 터미널에서 작업하는 것을 정말 좋아합니다.

[19:40] 그리고 VS Code나 여러분이 사용할 수 있는 다른 에디터들을 사용하는 것을요.

[19:43] Zed를 사용할 수도 있고

[19:45] Sublime Text를 diff 메커니즘으로 사용해서

[19:47] 실제로 변경사항 간의 델타를 확인할 수도 있습니다.

[19:50] 그 사이의 차이를 말이죠.

[19:52] 파일에서 발생할 수 있는 변화들을

[19:54] 확인하는 거죠. 여기서 보시는 것처럼

[19:56] 터미널에서 작업하지만 VS Code로 가서

[19:57] 실제로 생성된 결과를 확인합니다.

[20:00] 충돌이 많지 않은 것 같네요.

[20:03] 모든 게 괜찮아 보입니다.

[20:04] 작업이 준비되었고 적절한 범위도 갖추었으며

[20:07] 구성적 호환성도 괜찮아 보입니다.

[20:10] 이제 구현할 준비가 되었습니다.

[20:12] 그리고 이제부터가

[20:14] 재미있는 부분입니다. 어떤 결과가 나올지

[20:18] 어떻게 작동할지 지켜보겠습니다.

[20:19] /implement를 실행하고

[20:21] GitHub Copilot CLI와 Claude Sonnet 4가

[20:23] 우리가 그토록 기다렸던

[20:26] 팟캐스트 랜딩 페이지를 만들어 주도록 하겠습니다.

[20:28] 자, implement를 입력해 봅시다.

[20:31] 결과를 얻는 마지막 슬래시 명령어입니다.

[20:35] 해봅시다. 이제

[20:38] 구현을 기다려 봅시다.

[20:40] [음악]

[20:55] [음악]

[21:03] [음악]

[21:09] [음악]

[21:15] [음악]

[21:17] 좋아요.

[21:20] 작업이 완료되었네요. 터미널로 가서

[21:22] 확인해 봅시다.

[21:26] 여기서 실제로 무슨 일이 일어나고 있는지

[21:28] 정말 궁금하거든요. 여기 폴더를 살펴봅시다.

[21:31] package.json이 있네요.

[21:33] npm install을 실행해서

[21:36] 패키지들이 제대로 작동하는지 확인하겠습니다.

[21:38] 그다음 cat package를 해보겠습니다.

[21:40] JSON을 확인해서

[21:42] 제대로 체크하는지 봅시다.

[21:45] 명령어를 확인해 보겠습니다.

[21:47] npm run build를 실행할 수 있네요.

[21:49] 좋아요, npm run build입니다.

[21:55] 이게 잘 작동하기를 바랍니다.

[22:03] 좋아요. 좋아요. 좋아요.

[22:04] 좋아요. 거의 다 되어 갑니다.

[22:07] 거의 다 되어 갑니다.

[22:09] 좋습니다. 그리고 npm run dev를 실행합니다.

[22:13] 그리고 여기를 봅시다. 웹사이트가 있습니다.

[22:15] localhost 3000입니다.

[22:19] 봅시다. 이게 작동하는지 확인해 봅시다.

[22:22] 우와! 보세요. 팟캐스트 랜딩 페이지가 있습니다.

[22:25] 여기 있어요. Sarah Johnson이라는 사람이

[22:28] 호스트하고 있네요.

[22:30] 누군지는 모르겠지만 잘됐네요.

[22:32] 링크들도 있고 모든 게 생성되었습니다.

[22:34] 맞죠. Copilot CLI가

[22:37] 정말 훌륭한 일을 해냈다고 생각합니다.

[22:39] 커스텀 슬래시 명령어를 지원하지 않음에도 불구하고

[22:41] 작동하게 만들었어요. 정말 좋습니다. 마음에 듭니다.

[22:43] 너무 마음에 들어서

[22:45] copilot을 실행해 보겠습니다.

[22:47] 대시 배너. 보세요.

[22:51] 이 애니메이션 보는 게 정말 좋아요.

[22:52] 정말 환상적입니다. 좋아요.

[22:55] GitHub Copilot CLI와 함께 Spec Kit을 사용하는 방법을

[22:57] 보여드리는 건 여기서 마무리하겠습니다.

[22:59] 오늘 바로 시도해 보실 수 있어요.

[23:00] 다시 말씀드리지만 github.com/github/copilot-

[23:03] CLI로 가서 다운로드하세요.

[23:06] Windows, macOS, Linux에서 CLI를 시도해 보시고

[23:09] /feedback 명령어로

[23:11] 피드백을 주시기 바랍니다.

[23:12] 여러분이 만들 것들이 기대됩니다. 다음에 또 만나요.