Claude Code로
AI 시작하기

🎯 이 클립에서 만드는 것

강의 첫 클립부터 뭔가 만들 줄 알았죠? 잠깐만요. 저는 여기서 먼저 지도를 펴고 출발하겠습니다. 이 강의가 23개 실습으로 어디까지 가는지, 여러분이 뭘 준비하면 되는지부터 짚고 가요. 첫 수업에 강의실 위치, 교재, 질문 채널부터 확인하잖아요? 딱 그 시간이에요.

표에서 볼 건 하나예요. 처음부터 모든 걸 이해하는 게 아니라, 어디로 가는지 알고 출발하는 겁니다.

제가 이 클립에서 가장 먼저 낮추고 싶은 건 "개발자가 아닌데 따라갈 수 있을까?"라는 걱정이에요. 이 강의는 문법 시험처럼 코드를 외우는 과정이 아닙니다. 옆자리 선배에게 묻고, 결과를 보고, 다시 부탁하는 연습에 가까워요.

그래서 첫 클립의 결과는 파일이 아니라 출발 준비입니다. 어떤 요금제를 생각할지, 강의가 어떤 순서로 흘러가는지, 실습이 왜 많은지 감만 잡으면 돼요.

💡 핵심 개념

이 강의는 도구 설명서가 아니라 운전 연습입니다

클로드코드를 처음 보면 버튼도 많고 명령도 많아 보이죠. 그런데 자동차 배울 때 엔진 구조부터 외우진 않잖아요? 시동 걸고, 브레이크 밟고, 천천히 움직이면서 손이 기억하게 만듭니다.

저는 이 강의를 설명서보다 운전 연습장에 가깝게 봅니다. 설치, 첫 실행, 데이터 분석, 카드뉴스, 영상, 포트폴리오, 자동화 스킬까지 직접 만들어봐요. 중요한 건 "내가 뭘 만들고 싶은지 말한다 → 나온 결과를 본다 → 다시 고친다" 이 흐름이에요.

전체 흐름은 23개 실습 중심입니다

강의는 Part 1에서 전체 그림을 보고, Part 2부터 설치와 첫 실행으로 들어갑니다. Part 3에서는 대화만으로 눈에 보이는 결과물을 만들고, Part 4 이후에는 플러그인과 스킬로 클로드코드의 능력을 넓혀요.

처음에 뭐부터 봐야 할지 헷갈리면 이 표만 보시면 됩니다.

처음부터 모든 Part를 외울 필요는 없습니다. 지하철 노선도도 목적지 방향만 알면 일단 탈 수 있잖아요.

구독 사용량과 API 과금은 다릅니다

이 강의는 Claude Pro/Max 구독으로 진행합니다. Anthropic API 키를 발급하거나 Console에 결제 정보를 연결하는 과정은 다루지 않아요. 여러분에게 필요한 건 클로드코드를 안정적으로 쓸 수 있는 구독 환경입니다.

헷갈리기 쉬운 지점이 딱 여기예요. Claude Pro/Max 구독은 정해진 사용량 안에서 클로드코드를 쓰는 방식입니다. 반면 API 과금은 외부 서비스처럼 부른 만큼 비용이 찍히는 방식이에요. 휴대폰으로 치면 구독은 월 이용권, API 과금은 쓴 만큼 찍히는 미터기에 가깝죠.

다만 강의 후반에는 외부 서비스 API가 나옵니다. 공공 API나 네이버 데이터를 연결해서 스킬을 만들 수 있거든요. 이건 Anthropic API 인증과 다른 얘기예요. 클로드코드 결제 이야기가 아니라, 필요한 외부 데이터를 가져오는 연결 방식으로 보시면 돼요.

Pro로 시작할 수 있지만 Max가 더 편합니다

Pro로도 됩니다. 다만 솔직히 말하면, 강의 따라가다 보면 부족하게 느껴질 수 있어요. 파일 읽고, 결과물 만들고, 다시 고치고. 이게 한 클립 안에서도 계속 일어나거든요. 한도가 금방 찰 수 있습니다.

Max는 더 넉넉해서 실습을 몰아서 진행하기 편합니다. 제가 Max를 권하는 이유도 거창하지 않아요. 운전 연습할 때 연료 걱정이 적으면 도로에 더 집중할 수 있잖아요.

🚶 진행 흐름

1. 강사의 배경과 강의 목적을 확인하세요

강사는 클로드코드를 단순한 개발 도구로 소개하지 않습니다. 업무 문제를 대화로 풀어내는 도구로 봐요. 핵심은 "코드를 잘 짜는 사람 되기"가 아니라 AI와 함께 결과물을 만드는 자신감입니다.

영상에서 제 소개가 나올 때는 경력 자체보다 "왜 이렇게 확신하게 됐는지"를 봐주세요. 반복 업무를 줄이고, 문제를 정리하고, 필요한 결과물을 만들어내는 방식이 이 강의의 중심이에요.

2. 23개 실습 구조를 큰 지도로 보세요

Part 이름을 전부 외우려 하지 마세요. 제가 압축하면 이 세 줄입니다.

• 처음에는 설치하고 첫 실행을 합니다.
• 중간에는 보고서, 콘텐츠, 웹사이트처럼 눈에 보이는 결과물을 만듭니다.
• 후반에는 플러그인과 스킬로 내 업무에 맞게 확장합니다.

이 정도만 잡아두면 이후 클립에서 "지금 내가 어느 구간에 있지?"를 덜 놓쳐요.

3. 요금제 설명은 내 수강 방식과 연결하세요

요금제 선택은 정답 맞히기가 아닙니다. 하루에 조금씩 볼 건지, 주말에 몰아서 실습할 건지에 따라 체감이 달라져요. Pro는 가볍게 시작할 때, Max는 흐름을 끊고 싶지 않을 때 편합니다.

한도가 걸리면 바로 이어서 실습하기 어렵습니다. 보통 바로 풀리는 느낌이 아니에요. 그러니까 "내가 언제, 얼마나 몰아서 들을지"를 먼저 생각해보시면 됩니다.

4. API 이야기는 둘로 나눠서 보세요

이 클립에서 구분할 건 간단합니다. 비용이라는 단어가 같이 나오니까 헷갈릴 뿐이에요.

앞으로 "API"라는 단어가 나와도 전부 같은 뜻으로 받아들이지 않으면 됩니다. 어떤 서비스와 연결하는지, 돈이 어디서 나가는지만 보면 돼요.

5. 다음 클립에서 결과물 쇼케이스를 볼 준비를 하세요

이 클립은 출발 안내입니다. 다음 클립에서는 여러분이 실제로 어떤 결과물을 만들게 되는지 먼저 봐요. 아직 따라 만들 필요는 없습니다. "저걸 내 업무 어디에 붙이면 좋을까?" 정도만 생각하며 넘어가세요.

📦 결과물

이 클립은 워크샵 세션 시청만 — 따라할 결과물은 다음 Part부터입니다.

저장할 파일이나 제출할 과제는 없습니다. 대신 아래 세 가지만 머릿속에 남기면 돼요.

• 이 강의는 대화로 결과물을 만드는 실습형 강의입니다.
• 실습은 Part 2부터 시작하고, Part 3부터 눈에 보이는 결과물이 많아집니다.
• 기본 결제 기준은 Claude Pro/Max 구독이며, Anthropic API/Console 인증은 다루지 않습니다.

개인 메모를 남기고 싶다면 "Pro로 시작할지, Max로 갈지", "가장 기대되는 결과물은 무엇인지" 정도만 적어두세요. 저는 이 정도만 적어도 첫 클립은 충분하다고 봅니다.

🆘 자주 막히는 포인트

막히는 데는 보통 정해져 있어요. 아래 표에서 내 상황과 가까운 줄부터 보시면 됩니다.

그래도 안 풀리면 지금 클립 번호와 화면 상태를 같이 적어두세요. 다음 질문이 훨씬 쉬워집니다.

🔗 다음 클립

→ Part 1 / Clip 2: 강의 활용법 - 이 강의에서 직접 보게 될 결과물 쇼케이스와 시작점을 확인합니다.

다음 클립에서는 대시보드, 카드뉴스, 리모션 영상, 포트폴리오 사이트, 모닝 브리핑 같은 결과물을 먼저 봅니다. 여러분은 "내 업무에는 어디에 붙이면 좋을까?"만 들고 오시면 돼요.

🎯 이 클립에서 만드는 것

본격적으로 시작하기 전에, 먼저 보여드릴게요. 이 클립은 설명서 첫 장을 읽는 시간이 아니라, 여러분이 앞으로 직접 만들 결과물을 먼저 보는 쇼케이스예요. 새 가전제품도 기능표보다 실제로 쓰는 장면을 먼저 보면 감이 오잖아요?

제가 여기서 보여드리는 건 장식용 샘플이 아닙니다. 뒤에서 실제로 만들 결과물들이에요.

표에서 핵심은 간단하죠. "아, 내가 저런 걸 만들러 가는구나"를 먼저 잡는 겁니다.

Part 1은 아직 실습하지 않습니다. 대신 "앞으로 무엇을 만들게 되는지"를 눈으로 확인해요. 완주 코스를 먼저 보면 중간에 낯선 내용이 나와도 덜 흔들립니다.

이 클립에서 마음속으로 정할 것은 하나예요. "나는 어떤 결과물을 가장 먼저 내 업무에 써보고 싶은가?" 대시보드일 수도 있고, 카드뉴스일 수도 있고, 매일 아침 보는 모닝 브리핑일 수도 있어요.

💡 핵심 개념

결과물을 먼저 보면 학습 방향이 선명해집니다

비개발자에게 가장 힘든 지점은 사실 이거예요. "그래서 이걸 배워서 어디에 쓰는데?" 명령어를 하나씩 배우는 동안 최종 그림이 안 보이면 금방 지칩니다. 그래서 이 클립은 완성 장면을 먼저 보여드려요.

강의에서 보여주는 결과물은 장식용 샘플이 아니라, 이후 실습에서 실제로 만들게 될 것들입니다. CSV 데이터를 대시보드로 만들고, 리서치 결과를 카드뉴스와 영상으로 바꾸고, 포트폴리오 사이트는 기획부터 배포까지 갑니다.

대표 결과물은 업무 장면과 연결됩니다

결과물 이름보다, 내 업무에서 떠오르는 장면으로 보시면 훨씬 쉬워요.

여기서 중요한 건 "내가 개발자가 되어야 한다"가 아닙니다. 내가 이미 하던 일을 더 눈에 보이게, 더 빠르게, 다시 쓸 수 있게 만드는 거예요.

공통 흐름은 5단계입니다

이 강의의 실습은 매번 완전히 다른 방식으로 움직이지 않습니다. Part 3에서 본격적으로 다루지만, 지금은 이름만 들어두면 돼요.

제가 계속 반복해서 가져갈 순서는 이겁니다.

이 흐름은 옆자리 선배에게 일을 배우는 과정과 비슷합니다. 처음에는 "이 캠페인 결과를 어떻게 보면 좋을까요?"라고 묻고, 틀이 잡히면 자료를 넣고, 나온 결과를 보며 다시 말하는 식이죠.

커뮤니티는 막혔을 때 돌아가는 우회도로입니다

강의를 듣다 보면 화면이 다르게 보이거나, 결과물이 영상과 조금 다르게 나올 수 있습니다. 이때 혼자 오래 붙잡고 있으면 에너지가 빠져요. 오픈채팅방 같은 커뮤니티는 막힌 지점을 짧게 공유하고, 다른 수강생과 강사의 힌트를 받는 공간입니다.

질문할 때는 "안 돼요"만 쓰는 것보다 현재 위치와 증상을 같이 적으면 답을 받기 쉽습니다. 예를 들어 "Part 2 설치 중이고, Mac 터미널 화면이 영상과 다릅니다. 어디를 확인하면 좋을까요?"처럼요. 여러분이 어디에 서 있는지 보여주면, 답변도 훨씬 빨라져요.

🚶 진행 흐름

1. 결과물 쇼케이스를 기능보다 장면으로 보세요

대시보드를 볼 때 차트 종류를 외우려 하지 마세요. "내가 매주 만드는 보고서가 이렇게 클릭 가능한 화면이 되면 어떤 회의가 쉬워질까?"를 떠올리면 됩니다.

카드뉴스와 리모션 영상도 마찬가지예요. 디자인 도구 이름보다, 리서치한 내용을 팀이나 고객에게 더 쉽게 전달하는 장면을 보시면 돼요.

2. 내 업무와 가장 가까운 결과물에 표시하세요

영상을 보면서 마음속으로 하나만 골라보세요. 제가 권하는 방식은 "제일 멋진 것"이 아니라 "내일 바로 써볼 만한 것"을 고르는 겁니다.

• 숫자와 표를 자주 본다면 대시보드가 가깝습니다.
• 콘텐츠나 홍보물을 만든다면 카드뉴스와 영상이 가깝습니다.
• 커리어 정리나 개인 브랜딩이 필요하다면 포트폴리오 사이트가 가깝습니다.
• 반복 확인 업무가 많다면 모닝 브리핑과 자동화 스킬이 가깝습니다.
• 시장 흐름을 계속 봐야 한다면 트렌드 분석 앱이 가깝습니다.

3. 5단계 흐름을 이름만 들어두세요

아직 프롬프트를 잘 쓰려고 애쓰지 않아도 됩니다. 이 클립에서는 "질문하고, 기획하고, 만들고, 검토하고, 개선한다"는 순서만 들어두세요. 어차피 Part 3에서 직접 반복합니다.

4. 시작점은 내 수준에 맞춰 잡으세요

처음 듣는다면 Part 2 설치부터 차근차근 따라가세요. 이미 클로드코드를 설치해서 써본 적이 있다면, Part 4의 플러그인 강화나 Part 6의 스킬 만들기에 더 관심이 갈 수 있어요.

하지만 강의를 처음 수강한다면 최소한 Part 1과 Part 2는 빠르게 훑어보는 걸 권합니다. 같은 용어와 폴더 구조를 맞춰두면 뒤에서 덜 헷갈리거든요.

5. 커뮤니티는 빠르게 묻고 빠르게 돌아오는 곳으로 쓰세요

막혔을 때는 오래 참지 마세요. 다만 질문을 올릴 때는 현재 클립, 운영체제, 보이는 증상, 이미 해본 일을 함께 적으면 좋습니다. 이렇게 적으면 다른 사람이 내 자리로 와서 화면을 같이 보는 것처럼 도와주기 쉬워요.

📦 결과물

이 클립은 워크샵 세션 시청만 — 따라할 결과물은 다음 Part부터입니다.

이 클립에서 남겨야 할 것은 완성 파일이 아니라 내 관심 결과물과 시작점이에요.

헷갈리면 아래 세 칸만 채운다고 생각하세요.

따로 제출할 것은 없습니다. 그래도 노트를 만든다면 "내가 만들고 싶은 첫 결과물"을 한 줄만 적어두세요. 솔직히 그 한 줄이면 다음 클립을 볼 이유가 훨씬 선명해집니다.

🆘 자주 막히는 포인트

막히는 지점은 보통 비슷합니다. 아래에서 내 증상과 가장 가까운 줄만 보세요.

여전히 애매하면, "나는 어떤 결과물을 먼저 만들고 싶은가"로 돌아오면 됩니다. 그 답이 시작점을 골라줘요.

🔗 다음 클립

→ Part 1 / Clip 3: cc101 & GPTaku 플러그인 - 한국어 가이드, 플러그인 생태계, 비개발자 해커톤 사례를 확인합니다.

다음 클립에서는 "막히면 어디를 보면 되는지"와 "클로드코드를 어떻게 넓혀 쓸 수 있는지"를 봅니다. 실제 설치는 나중에 해요. 지금은 여러분이 돌아올 지도와 가능성을 먼저 챙기면 됩니다.

🎯 이 클립에서 만드는 것

Part 1 마지막 클립입니다. 여기서 제가 꼭 보여드리고 싶은 건 두 가지예요. 막혔을 때 돌아올 한국어 지도, 그리고 클로드코드를 더 넓게 쓰게 해주는 확장 도구입니다. 마지막에는 해외 해커톤 사례도 봅니다. "비개발자도 진짜 가능할까?"라는 질문에 꽤 센 답이 되거든요.

먼저 전체 그림을 표로 잡고 갈게요.

이 표에서 중요한 건 "지금 바로 설치한다"가 아닙니다. 실제 플러그인 설치와 체험은 Part 4에서 해요. 지금은 스마트폰을 처음 샀을 때 앱스토어가 있다는 사실을 먼저 아는 정도면 충분합니다.

💡 핵심 개념

cc101은 막힐 때 보는 한국어 지도입니다

cc101은 axwith.com에서 볼 수 있는 Claude Code 한국어 입문 가이드입니다. 공식 문서를 처음부터 끝까지 읽기 부담스러운 분들을 위해, 꼭 알아야 하는 개념을 한국어로 정리해둔 안내서예요.

새로운 건물에 처음 가면 모든 방을 다 열어보진 않잖아요? 먼저 안내도를 보고, 화장실과 엘리베이터와 강의실 위치를 확인합니다. cc101도 그런 역할이에요. 설치, 기본 개념, 설정 파일, MCP, 스킬 같은 항목을 필요할 때 찾아보는 지도입니다.

이 강의의 보조 사이트인 bptc(bptc.axwith.com)는 cc101의 흐름을 이 강의 클립 순서에 맞게 다시 엮은 공간입니다. cc101이 일반 지도라면, bptc는 이번 강의 코스용 안내판이라고 보시면 돼요.

둘이 헷갈릴 수 있으니 여기서 한 번 나눠볼게요.

정리하면 이렇습니다. 영상으로 흐름을 보고, bptc로 다시 짚고, 더 넓은 개념은 cc101에서 찾아보면 돼요.

플러그인은 클로드코드에 붙이는 업무 도구입니다

플러그인은 클로드코드의 기본 능력에 새로운 습관과 도구를 붙이는 방법입니다. 스마트폰에 캘린더 앱, 메모 앱, 사진 편집 앱을 설치하면 같은 스마트폰으로 할 수 있는 일이 늘어나죠. 클로드코드도 비슷해요.

GPTaku 플러그인 생태계에는 여러 갈래의 도구가 있습니다. kkirikkiri는 자연어로 여러 AI 역할을 구성하는 데 도움을 주고, frontend-ui-ux는 화면과 사용자 경험을 다듬는 흐름을 보조해요. vibe-sunsang은 내 AI 활용 방식을 점검하는 데 쓰입니다.

여기서 이름을 모두 외울 필요는 없습니다. 여러분은 "필요한 기능을 나중에 붙일 수 있구나" 정도만 잡으세요. 실제 설치, 실행, 비교는 Part 4에서 하나씩 다룹니다.

스킬은 내 업무 방식으로 클로드코드를 길들이는 방법입니다

플러그인이 앱스토어에서 앱을 설치하는 느낌이라면, 스킬은 내 업무 매뉴얼을 만들어 클로드코드에게 알려주는 느낌입니다. 예를 들어 매주 보고서 형식이 정해져 있다면, 그 순서와 말투와 검토 기준을 스킬로 묶을 수 있어요.

후반부에서는 딥리서치, 공공 API 활용, 검색 API 활용, 회의록 정리, 모닝 브리핑, 콘텐츠 파이프라인 같은 스킬을 직접 만들어봅니다. 제가 계속 강조하고 싶은 건 이거예요. 비개발자라도 내 업무를 말로 설명할 수 있으면, 자동화할 재료가 생깁니다.

해커톤 사례의 핵심은 코딩 실력이 아니라 자기 문제입니다

Anthropic 해커톤 사례에서 주목할 부분은 수상자들이 모두 전통적인 전문 개발자처럼 출발하지 않았다는 점입니다. 누군가는 도시 인허가 문제를 풀고 싶었고, 누군가는 딸이 쓸 수 있는 코딩 환경을 만들고 싶었고, 누군가는 환자가 진료 내용을 더 쉽게 이해하길 바랐어요.

공통점은 거창한 기술 목표가 아니라 자기 앞의 문제였습니다. 솔직히 이게 제일 중요합니다. 이 강의도 "반복 보고서를 줄이고 싶다", "조사 결과를 보기 좋게 바꾸고 싶다", "아침 정보를 한 번에 받고 싶다" 같은 문제에서 출발해요.

🚶 진행 흐름

1. cc101을 지금 다 읽으려 하지 마세요

이 클립에서 cc101을 소개한다고 해서, 바로 전체 문서를 읽을 필요는 없습니다. 처음에는 "막히면 여기로 돌아오면 된다"는 위치만 기억하세요. 지도는 길 잃었을 때 더 빛나잖아요.

2. bptc와 워크샵 세션의 역할을 나누세요

워크샵 세션은 선생님이 앞에서 직접 보여주는 수업입니다. bptc는 수업이 끝난 뒤 펼쳐보는 필기 노트에 가깝고요. 영상에서 흐름을 보고, 사이트에서 핵심 개념과 막히는 지점을 다시 확인하세요.

특히 비개발자는 한 번에 다 이해하지 못해도 괜찮습니다. 같은 내용을 영상, 문서, 실습에서 여러 번 만나면서 익숙해지는 편이 더 자연스러워요.

3. 플러그인 이름은 기능 이미지로 기억하세요

지금은 설치하지 않으니 이름을 암기하려 하지 마세요. 대신 이렇게 연결해두면 됩니다.

이름은 낯설어도 괜찮습니다. 이미지만 붙어 있으면 Part 4에서 다시 만났을 때 훨씬 덜 낯설어요.

4. 해커톤 사례를 내 일과 연결하세요

사례를 볼 때 "저 사람은 대단해서 가능했겠지"로 끝내지 마세요. 대신 문제의 크기를 줄여서 보세요. 제가 보는 포인트도 결과의 크기보다 출발점입니다.

• 인허가 문제는 회사의 반복 승인 업무와 닮아 있습니다.
• 딸을 위한 도구는 팀원을 위한 내부 도구와 닮아 있습니다.
• 진료 요약은 고객 상담 내용 정리와 닮아 있습니다.

비개발자에게 필요한 출발점은 완벽한 기술 지식이 아니라, 불편한 장면을 구체적으로 말하는 능력입니다.

5. Part 2로 넘어갈 준비를 하세요

Part 1은 여기서 끝납니다. 다음부터는 실제 설치와 첫 실행으로 들어가요. 지금 해야 할 일은 하나입니다. "나는 앞으로 클로드코드를 내 문제 해결 파트너로 써본다"는 마음으로 Part 2를 시작하는 거예요.

📦 결과물

이 클립은 워크샵 세션 시청만 — 따라할 결과물은 다음 Part부터입니다.

남겨야 할 결과는 설치 파일이 아니라 아래 세 가지 이해입니다. 여러분이 이 세 줄을 기억하면 Part 1은 충분히 잘 지나온 거예요.

• cc101은 Claude Code 한국어 입문 가이드입니다.
• bptc는 이 강의 순서에 맞춘 학습 보조 사이트입니다.
• GPTaku 플러그인은 클로드코드를 더 넓게 쓰게 해주는 확장 생태계이며, 실제 설치는 Part 4에서 진행합니다.

개인 메모를 남긴다면 "내 업무에서 자동화하고 싶은 반복 작업 1개"를 적어두세요. 매일 복사해 붙이는 보고서, 매주 정리하는 회의록, 반복해서 보는 뉴스 키워드도 충분한 출발점입니다.

🆘 자주 막히는 포인트

막히는 데는 보통 정해진 이유가 있습니다. 아래 표에서 가까운 증상부터 보시면 돼요.

여전히 멀게 느껴지면 결과가 아니라 문제부터 보세요. "나도 매주 귀찮은 일 하나는 있지" 여기서 출발하면 됩니다.

🔗 다음 클립

→ Part 2 / Clip 1: Mac 환경 설치 - 이제 실제로 클로드코드를 사용할 준비를 시작합니다.

Mac 사용자는 다음 클립부터 설치를 따라가세요. Windows 사용자는 이어지는 Windows 설치 클립까지 함께 확인하면 됩니다. Part 1에서 본 가능성을, Part 2부터는 여러분 컴퓨터 위에 하나씩 올려봅니다.

🎯 이 클립에서 만드는 것

Mac 사용자분들은 여기서부터 진짜 시작입니다. 그런데 첫 화면부터 터미널에 긴 명령어를 줄줄 치는 강의, 아닙니다. 이 클립에서는 Mac에서 Claude Code를 처음 실행할 수 있는 기본 환경을 만들어요. 흐름은 다음 순서입니다.

1. 안티그래비티 IDE 설치
2. Homebrew와 Git 준비
3. Node.js LTS 설치
4. IDE 안의 agent를 활용한 Claude Code 설치
5. 인증과 기본 조작 확인

제가 이 클립에서 제일 강조하고 싶은 건 순서예요. 터미널에 명령어 직접 치는 게 아니에요. 안티그래비티 IDE를 먼저 깔고, 빈 폴더를 열고, 그 안의 agent한테 “Claude Code 설치하려는데 어떻게 해?”라고 묻습니다. 그러면 agent가 방법을 설명해주고, 여러분은 읽고 동의한 다음 실행하면 돼요.

끝나고 나면 brew, git, node, npm, claude가 전부 동작해야 합니다. 마지막에는 Claude 계정 인증까지 하고, 테스트 폴더에서 첫 인사까지 확인합니다. 여기까지 되면 Mac 설치는 끝이에요.

💡 핵심 개념

설치도 대화로 진행한다

여기서 중요한 건 “Mac에 Claude Code 까는 명령어”가 아닙니다. 진짜 핵심은 설치 과정을 안티그래비티 agent와 같이 풀어가는 습관이에요. 앞으로 제가 계속 반복할 패턴도 이거예요.

Mac에 Homebrew 설치하려는데 어떻게 해?

Claude Code를 네이티브 방식으로 설치하려는데, 내 환경에서 안전하게 진행할 순서와 확인 방법까지 알려줘

이렇게 먼저 물어보면 agent가 뭘 설치하는지, 어떤 명령을 실행하는지, 끝나고 뭘로 확인할지 설명해줍니다. 그다음 여러분이 이해하고 OK 하면 실행해요. 솔직히 처음엔 조금 느려 보여요. 그런데 초반에는 이게 훨씬 안전합니다.

도구들의 역할

Homebrew를 깔다 보면 Mac에서 Command Line Developer Tools와 Git이 같이 준비되는 경우가 많아요. 그래도 저는 항상 git --version으로 확인합니다. 설치된 것처럼 보여도 버전 출력이 떠야 완료예요.

🚶 진행 흐름

1. 안티그래비티 IDE 설치

첫 단추는 안티그래비티입니다. 브라우저에서 안티그래비티 다운로드 페이지에 접속해 macOS용 설치 파일을 받고, 설치 후 Google 계정으로 로그인해요.

중요한 게 하나 있어요. 폴더를 열어야 agent가 제대로 작동합니다. 처음에는 실습용 빈 폴더 하나 만들고 열어두면 됩니다.

Open Folder를 눌러 새 실습 폴더를 만들고 열어주세요. 폴더가 열린 상태에서 agent 채팅창이 보이면 다음 단계로 갑니다.

2. Homebrew와 Git 준비

이제 Homebrew입니다. 여러분이 외워야 할 명령어부터 던지는 게 아니라, 안티그래비티 채팅창에 먼저 물어봅니다.

Mac에 Homebrew 설치하려는데 어떻게 해? 설치 후 brew와 git이 제대로 잡혔는지 확인하는 방법까지 알려줘

agent가 안내하는 설명을 읽고 진행합니다. 설치 중 Command Line Developer Tools 팝업이 나오면 Install을 누르면 돼요. 끝나면 아래 명령으로 확인합니다.

brew --version
git --version

두 명령 모두 버전이 나오면 다음 단계로 갑니다. 안 나오면 아직 끝난 게 아니에요.

3. Node.js LTS 설치

Node.js는 Claude Code 자체를 실행하는 데 꼭 필요한 건 아닙니다. 다만 이후 실습에서 웹 프로젝트와 외부 도구를 다룰 때 거의 계속 나와요. 그래서 미리 깔아둡니다. 역시 명령을 외우지 말고 agent에게 묻습니다.

Mac에 Node.js LTS를 설치하려는데 Homebrew 기준으로 어떻게 진행하면 돼? 설치 후 node와 npm 확인 방법도 알려줘

확인은 아래처럼 합니다.

node -v
npm -v

4. Claude Code 설치와 인증

여기서도 인터넷에서 찾은 설치 명령을 바로 복사하지 않습니다. 안티그래비티 IDE 안의 agent에게 먼저 물어보고, 제가 이해한 뒤 실행하는 흐름으로 갑니다.

Claude Code를 설치하려는데, Mac에서 권장되는 네이티브 설치 방식과 설치 후 PATH 확인, 첫 실행 인증 절차까지 순서대로 알려줘

agent가 안내한 내용을 읽고, 실행할 명령이 뭘 바꾸는지 확인한 뒤 진행합니다. 설치가 끝나면 터미널을 새로 열거나 셸 설정을 다시 불러옵니다.

source ~/.zshrc
claude --version

버전이 출력되면 설치는 성공입니다. 이제 테스트 폴더에서 처음 실행해봅니다.

mkdir -p ~/projects/cc101-test
cd ~/projects/cc101-test
claude

브라우저가 열리면 Claude 계정으로 로그인합니다. 터미널에 프롬프트가 돌아오면 간단히 인사해보세요.

hello

📦 결과물

설치가 끝났으면 기록을 남깁니다. 저장 위치는 50-my-work/Part02-시작하기/실습01-Mac환경설치/예요.

실습01-Mac환경설치/
└── README.md          # 설치 완료 시각, 검증 출력, 인증 여부 기록

완료 기준은 단순합니다. “설치한 것 같다”가 아니라, 버전이 실제로 떠야 해요.

마지막 점검은 한 번에 실행해도 됩니다.

brew --version
git --version
node -v
npm -v
claude --version

🆘 자주 막히는 포인트

🔗 다음 클립

다음은 Part 2 / Clip 2: Windows 환경 설치 입니다. Windows 사용자분들은 여기서 WSL과 Ubuntu 설치로 이어가면 돼요.

Mac 사용자라면 Clip 2는 건너뛰고 Part 2 / Clip 3: 첫 실행으로 넘어가면 됩니다. 설치가 끝났으니 이제 진짜로 Claude Code를 만져볼 차례예요.

🎯 이 클립에서 만드는 것

Windows는 Mac보다 한 겹 더 있습니다. 바로 WSL이에요. 이 클립에서는 Windows 사용자가 Claude Code를 실행할 수 있도록 안티그래비티 IDE → WSL 설치 → Windows 재시작 → Ubuntu 초기 설정 → agent에게 Claude Code 설치 방법 요청 → 인증 → 첫 실행 확인까지 가요.

Mac 클립과 똑같이, 핵심은 설치 명령을 외우는 게 아닙니다. Windows에서는 WSL, Ubuntu, PowerShell, 브라우저 인증이 섞여서 “이 명령을 어디에 쳐야 하지?”가 자주 헷갈려요. 그래서 터미널에 wsl --install부터 치는 게 아니에요. 안티그래비티 IDE를 먼저 열고, 그 안의 agent한테 “WSL에서 Claude Code 설치하려는데 어떻게 해?”라고 물어보면서 가요.

끝나고 나면 WSL Ubuntu 안에서 curl, git, node, npm, claude가 동작해야 해요. 제가 계속 강조할 포인트는 하나예요. Claude Code는 Windows 바탕화면이 아니라 WSL의 Linux 환경 안에서 실행합니다.

💡 핵심 개념

Windows에서는 WSL이 작업 공간이다

Windows에서 Claude Code를 안정적으로 쓰려면 WSL2와 Ubuntu를 작업 공간으로 잡는 게 좋습니다. WSL은 Windows 안에서 Linux를 띄우는 환경이에요. 앞으로 프로젝트 폴더도 가능하면 ~/projects/...처럼 WSL 홈 아래에 둬요.

WSL2에 Ubuntu를 설치하고 Claude Code를 쓰려는데, 처음부터 끝까지 어떤 순서로 하면 돼?

이 질문을 안티그래비티 agent에게 던지면 PowerShell에서 할 일, 재시작 후 Ubuntu에서 할 일, 인증할 때 Windows 브라우저를 써야 하는 지점까지 나눠서 설명해줍니다. 이게 이 강의의 패턴이에요. 복잡할수록 명령어보다 대화로 확인하는 순서가 중요해요.

Windows 설치 흐름 한눈에 보기

비밀번호를 입력할 때 화면에 아무 글자도 안 보이는 건 정상입니다. 보안 때문에 숨기는 거예요. 안 보여도 입력되고 있으니까 그대로 치고 Enter 누르면 돼요.

🚶 진행 흐름

1. 안티그래비티 IDE 설치

먼저 Windows용 안티그래비티 IDE를 설치하고 Google 계정으로 로그인합니다. 저는 여기서부터 agent를 켜두는 걸 추천해요. 뒤에 나오는 설치 흐름을 계속 물어보면서 갈 수 있거든요.

Windows에서 Claude Code 설치 실습을 시작하려는데, WSL2부터 인증까지 단계별로 알려줘

여기서 agent가 안내하는 내용을 따라가되, Windows PowerShell에서 실행할 명령과 Ubuntu 터미널에서 실행할 명령을 꼭 구분해둡니다. 이 둘이 섞이면 설치가 꼬이기 쉬워요.

2. WSL2와 Ubuntu 설치

PowerShell을 관리자 권한으로 열어 WSL 설치를 진행합니다. 구체적인 명령은 agent가 현재 Windows 상태에 맞게 안내하도록 둡니다. 여러분이 외울 필요 없어요.

WSL2와 Ubuntu를 설치하려는데, PowerShell에서 할 일과 재부팅 후 할 일을 나눠서 알려줘

설치 후에는 Windows를 재시작합니다. 이건 건너뛰면 안 돼요. 재시작하지 않으면 WSL 기능이 제대로 적용되지 않을 수 있습니다. 재시작 뒤 Ubuntu 창이 열리면 사용자명과 비밀번호를 만들어요.

Ubuntu가 준비되었는지 확인해요.

uname -r
pwd

3. Ubuntu 기본 도구 준비

이제 Ubuntu 안에서 기본 도구를 깝니다. Claude Code 설치와 이후 실습에 curl과 git이 필요해요.

WSL Ubuntu에 curl과 git을 설치하려는데, 업데이트부터 설치 확인까지 안전한 순서로 알려줘

설치 후 확인해요.

curl --version
git --version

4. Claude Code와 Node.js 설치

이 단계에서도 핵심은 agent 패턴입니다. 인터넷에서 본 명령을 바로 실행하지 말고, 안티그래비티 agent에게 WSL Ubuntu 기준 설치 절차를 먼저 설명받아요.

WSL Ubuntu 안에 Claude Code를 설치하려는데, 권장 설치 방식과 PATH 확인, 인증 방법까지 알려줘

설치가 끝나면 셸 설정을 다시 불러오고 버전을 확인해요.

source ~/.bashrc
claude --version

Node.js도 Ubuntu 안에 설치합니다. Windows에 이미 Node.js가 있어도 WSL 안에서는 별개예요. 이걸 헷갈리면 npm 경로가 섞여요.

WSL Ubuntu에 최신 LTS Node.js를 설치하려는데, Windows 쪽 npm이 섞이지 않게 확인하는 방법까지 알려줘

확인 명령은 이렇게 갑니다.

node -v
npm -v
which npm

which npm이 /mnt/c/...로 시작하면 Windows 쪽 경로가 섞인 겁니다. 이 경우 agent에게 WSL PATH 정리 방법을 다시 물어보면 돼요.

5. 첫 실행과 인증

이제 WSL 홈 아래에 테스트 폴더를 만들고 Claude Code를 실행합니다. /mnt/c 아래가 아니라 ~/projects 아래라는 점, 꼭 보세요.

mkdir -p ~/projects/cc101-test
cd ~/projects/cc101-test
claude

WSL에서는 브라우저가 자동으로 안 열릴 수 있습니다. 에러가 아니라 정상이에요. 터미널에 표시된 인증 URL을 복사해서 Windows 브라우저 주소창에 붙여넣고 로그인하면 돼요.

📦 결과물

설치가 끝났으면 기록을 남깁니다. 저장 위치는 50-my-work/Part02-시작하기/실습02-Windows환경설치/예요.

실습02-Windows환경설치/
└── README.md          # WSL 버전, Ubuntu 사용자, 설치 검증, 인증 여부 기록

최종 확인 항목은 다음과 같습니다. 여기서는 “Windows에서 된다”가 아니라 “WSL Ubuntu 안에서 된다”가 기준이에요.

한 번에 확인하려면 아래 순서로 실행해요.

uname -r
curl --version
git --version
node -v
npm -v
which npm
claude --version

🆘 자주 막히는 포인트

🔗 다음 클립

다음은 Part 2 / Clip 3: 첫 실행 입니다. 설치가 끝났다면 이제 Claude Code 화면을 직접 보고, 슬래시 명령과 모델 전환, 첫 폴더 정리 실습까지 가봐요.

🎯 이 클립에서 만드는 것

설치가 끝났다고 바로 감이 오진 않죠? 이 클립은 처음으로 Claude Code를 제대로 만져보는 시간입니다. 단순히 claude를 실행해보는 데서 끝나지 않고, 화면 구성, 슬래시 커맨드, 모델 전환, 자기 학습 기능, 실제 파일 정리까지 한 번에 봐요.

마지막 실습은 다운로드 폴더 정리예요. 여기서 제가 꼭 보여주고 싶은 장면이 나옵니다. Claude Code는 일반 챗봇이 아니라 자율 에이전트입니다. 여러분이 한 줄로 요청하면 폴더를 분석하고, 정리 방안을 판단하고, 실행 전에 확인을 요청하고, 허락받은 뒤 파일을 옮겨요.

가장 중요한 메시지는 이겁니다. Claude Code는 혼자 막 실행하는 도구가 아니라, STEP 3 확인에서 사용자의 승인을 받는 도구예요. 이 안전장치를 이해하고 나면 “AI에게 작업을 맡긴다”는 말이 훨씬 덜 막연해져요.

💡 핵심 개념

Claude Code 화면의 기본 요소

처음 실행하면 화면이 좀 낯설 수 있습니다. 괜찮아요. 이름만 알아도 이후 강의가 훨씬 편해집니다.

Status Line은 여러분 입맛대로 바꿀 수 있습니다. /statusline 뒤에 원하는 표시 방식을 자연어로 적으면 돼요. 저는 첫날에는 모델, 현재 폴더, 컨텍스트 정도만 보여도 충분하다고 봅니다.

/statusline 모델, 현재 폴더, 컨텍스트 퍼센트, 누적 비용을 한 줄로 보여줘

슬래시 커맨드와 모델 전환

Claude Code 안에서 /로 시작하는 명령은 특별한 기능을 호출합니다. 처음부터 전부 외우려고 하지 마세요. 네 개만 익숙해져도 충분합니다.

모델은 /model로 전환합니다. Sonnet은 대부분의 작업에 좋은 기본값, Opus는 복잡한 분석과 디버깅, Haiku는 간단한 확인과 요약에 좋다고 보시면 돼요.

/model

기본 모델을 고정하고 싶다면 설정 파일을 수정할 수도 있습니다. 다만 첫날에는 피커로 한 번 바꿔보는 정도면 충분해요.

자율 에이전트 4단계

다운로드 폴더 정리에서 확인할 핵심 구조입니다. 어렵게 볼 필요 없어요. “보고, 판단하고, 물어보고, 실행한다”입니다.

STEP 1 분석 -> STEP 2 판단 -> STEP 3 확인 -> STEP 4 실행

여기서 STEP 3이 안전장치예요. “이렇게 정리할까요?”라고 물었을 때 여러분이 동의해야 실행됩니다. 처음부터 바로 실행을 요청하기보다 아래처럼 시작합니다.

다운로드 폴더를 정리하려는데 어떻게 하면 좋을지 먼저 분석해서 알려줘

이 문장은 Part 3에서 본격적으로 배울 대화 5단계 패턴의 첫 맛보기입니다. 던지기, 범위 좁히기, 만들기, 검증, 개선의 흐름을 여기서 미리 경험하는 거예요.

🚶 진행 흐름

1. 화면 둘러보기

먼저 테스트 폴더에서 Claude Code를 실행합니다. 설치 확인은 했으니, 이제 화면을 보는 시간이에요.

mkdir -p ~/projects/cc101-test
cd ~/projects/cc101-test
claude

입력창, Status Line, 응답 영역, Permission Prompt가 어디에 나타나는지 확인합니다. 이어서 여러분이 보고 싶은 Status Line을 직접 설정해봅니다.

/statusline 모델 이름, 현재 폴더, 컨텍스트 사용량, 오늘 사용 비용을 보기 좋게 표시

2. 슬래시 커맨드 확인

아래 명령을 한 번씩 입력해봅니다. 결과를 외울 필요는 없습니다. 어디서 확인할 수 있는지만 익숙해지면 돼요.

/help
/status
/usage
/clear

/clear는 대화를 새로 시작하고 싶을 때 유용합니다. 다만 진행 중인 작업 맥락도 같이 정리돼요. 중요한 작업 중이라면 먼저 필요한 내용을 남겨두는 습관이 좋습니다.

3. /model로 모델 전환

모델 선택 화면을 열어 다른 모델을 한 번 선택해봅니다. 이건 겁낼 필요 없어요. 지금 세션에서 한 번 바꿔보는 정도입니다.

/model

선택 후 Status Line에서 모델명이 바뀌었는지 확인합니다. 복잡한 분석은 Opus, 일반 작업은 Sonnet, 간단한 요약은 Haiku 정도로 기억하면 됩니다.

4. /powerup 체험

Claude Code에는 스스로 기능을 알려주는 대화형 학습 기능이 있습니다. 이름이 /powerup이에요.

/powerup

토픽 목록이 나오면 흥미로운 주제 하나를 선택해 따라갑니다. 이 강의에서 모든 기능을 한 번에 외우지 않아도 돼요. 막히면 /powerup으로 다시 배우면 됩니다.

5. 다운로드 폴더 정리

이제 진짜 작업을 시켜봅니다. 본인 다운로드 폴더에 파일이 충분하면 그대로 가도 되고, 강사가 준비한 실습 자료(mock 파일 모음)를 받아 써도 됩니다.

📁 실습 자료 폴더 — Google Drive에서 받기

받은 폴더를 본인 컴퓨터의 ~/Downloads/cc-demo에 풀어두면 정리 대상이 바로 준비됩니다. 개인 파일이 섞인 다운로드 폴더로 실습하기 부담스러우면 이 자료로 진행하세요.

실제 다운로드 폴더에 파일이 충분하면 본인 폴더로 진행하세요. 파일이 적거나 개인정보가 걱정되면 위 자료를 사용하면 됩니다.

~/Downloads 폴더를 정리하려는데 어떻게 하면 좋을지 먼저 분석해서 알려줘. 파일을 옮기기 전에 정리 기준과 예상 결과를 설명해 줄 수 있어?

또는 실습용 폴더를 쓰는 경우:

~/Downloads/cc-demo 폴더를 정리하려는데 어떻게 하면 좋을지 먼저 분석해서 알려줘. 파일을 옮기기 전에 정리 기준과 예상 결과를 설명해 줄 수 있어?

Claude Code가 분석과 판단을 보여준 뒤 실행 여부를 물으면, 내용을 확인하고 승인합니다. 제가 이 장면을 중요하게 보는 이유가 있어요. 바로 여기서 “AI가 막 하는 게 아니라 물어보고 한다”는 감이 생깁니다. 정리 후에는 검증과 개선까지 이어갑니다.

정리 결과를 검토하려는데, 빠진 파일이나 애매한 분류가 있는지 확인하고 요약해 줄 수 있어?

PDF 파일 폴더 안에서 날짜순으로 다시 정리하려는데 어떻게 개선하면 좋을지 제안해 줄 수 있어?

📦 결과물

결과물은 첫 실행 기록입니다. 저장 위치는 50-my-work/Part02-시작하기/실습03-첫실행-폴더정리/예요.

실습03-첫실행-폴더정리/
└── README.md          # 모델, 모드, 정리 대상, Before/After, 검증·개선 기록

README에는 다음 내용을 남깁니다. 거창한 보고서가 아니라, 나중에 “내가 뭘 했더라?” 볼 수 있는 기록이면 충분해요.

이 클립을 마치면 progress.json에는 실습 3 완료 상태가 반영됩니다. 핵심은 “첫 실행 성공”보다 “분석 → 판단 → 확인 → 실행” 흐름을 직접 봤다는 점이에요.

🆘 자주 막히는 포인트

🔗 다음 클립

다음은 Part 2 / Clip 4: 모드 + Alias 입니다. 방금 본 Permission Prompt를 바탕으로 Default, Accept-edits, Plan, Auto, Bypass의 차이를 잡고, cc alias까지 설정합니다.

🎯 이 클립에서 만드는 것

매번 “이거 해도 돼요?”라고 묻는 게 안전하긴 한데, 계속 쓰다 보면 조금 답답하죠. 이 클립에서는 Claude Code를 더 빠르고 편하게 쓰기 위한 두 가지를 잡습니다. 첫째, 작업 성격에 따라 권한 모드를 바꾸는 법. 둘째, 매번 claude를 입력하지 않고 짧은 별명으로 실행하는 alias입니다.

Clip 3에서 다운로드 폴더를 정리하면서 Claude Code가 실행 전에 “이 작업을 해도 될까요?”라고 확인하는 장면을 봤습니다. 그 확인 방식은 모드에 따라 달라져요. 처음에는 묻는 게 좋습니다. 그런데 계속 쓰다 보면 작은 편집마다 멈추는 흐름이 꽤 답답해집니다.

끝나고 나면 여러분에게 맞는 권한 모드를 고르고, 터미널에서 cc만 입력해 Claude Code를 실행할 수 있어야 합니다. 익숙한 분들은 ccd, ccr처럼 Bypass와 resume을 섞은 alias도 같이 등록할 수 있어요. 저는 첫날에는 cc부터 추천합니다.

💡 핵심 개념

권한 모드는 자동차 기어다

권한 모드는 Claude Code가 파일을 읽고, 수정하고, 명령을 실행할 때 얼마나 자주 사용자에게 확인할지 정하는 장치입니다. 자동차 기어처럼 생각하면 쉬워요. 처음에는 수동으로 천천히 가고, 익숙해지면 자동으로 바꾸고, 복잡한 길에서는 네비게이션을 먼저 봅니다.

강의 기본 권장은 단순합니다. Pro 사용자는 Accept-edits로 시작하면 흐름이 부드럽고, Max 사용자는 Auto를 써도 좋아요. Bypass는 강력합니다. 솔직히 편해요. 다만 첫날 기본값으로 두지는 않습니다. 이런 모드가 있다는 걸 알고, 나중에 본인이 책임질 수 있는 환경에서 선택하면 됩니다.

Shift+Tab으로 모드를 바꾼다

Claude Code가 실행 중인 상태에서 Shift+Tab을 누르면 모드가 순환합니다. 입력창 안에서 눌러야 해요.

Default -> Accept-edits -> Plan -> Default

Status Line을 보면 현재 모드가 바뀌는 걸 확인할 수 있습니다. Bypass는 일반 사이클에 들어있지 않아요. 실행할 때 별도 플래그를 붙이거나 alias로 따로 만들어둡니다.

Alias는 실행 단축키다

alias는 긴 명령에 붙이는 짧은 별명입니다. 터미널에 매번 claude를 입력하는 대신 cc만 입력해 실행할 수 있어요. 작은 차이인데, 매일 쓰면 꽤 큽니다.

처음에는 cc 하나만 등록해도 충분합니다. ccd와 ccr은 반복 작업이 많고, 현재 폴더가 안전하다는 확신이 있을 때 쓰면 돼요.

🚶 진행 흐름

1. Shift+Tab으로 모드 사이클 확인

Claude Code 실행 상태에서 Shift+Tab을 눌러봅니다. 한 번 누를 때마다 Status Line의 모드 표시가 바뀌어요.

Shift+Tab

Default, Accept-edits, Plan을 한 바퀴 돌려봅니다. 바뀐 모드가 실제로 Status Line에 표시되는지 확인하세요.

2. /powerup으로 권한 모드 학습

이번엔 Claude Code 안에서 /powerup을 실행합니다. 문서로만 읽는 것보다 직접 보여주는 설명이 더 빠르게 들어와요.

/powerup

토픽 목록에서 권한 모드와 관련된 항목을 선택합니다. Claude Code가 자기 자신을 예시와 함께 설명해주기 때문에 감이 빨리 옵니다.

3. 본인 기본 모드 선택

처음에 뭐 고를지 헷갈리면, 저는 이렇게 추천합니다.

모드를 바꾼 뒤 간단한 요청을 하나 넣어 확인합니다. 실제로 어떻게 묻고 멈추는지 보는 게 중요해요.

현재 폴더를 살펴보고 어떤 파일이 있는지 요약하려는데, 먼저 어떤 방식으로 확인할지 알려줘

4. Claude Code 종료 후 alias 설정

alias는 Claude Code 밖, 일반 터미널에서 설정합니다. 먼저 Claude Code를 종료합니다.

/exit

Mac은 ~/.zshrc, Windows WSL은 ~/.bashrc에 alias를 추가합니다. 여기서 운영체제별 파일이 다르다는 점만 조심하면 돼요.

Mac 기본형:

echo 'alias cc="claude"' >> ~/.zshrc
source ~/.zshrc

Windows WSL 기본형:

echo 'alias cc="claude"' >> ~/.bashrc
source ~/.bashrc

풀 패키지를 등록하려면 아래처럼 추가합니다. Bypass를 아직 안 쓸 생각이면 cc만 등록해도 됩니다.

Mac 풀 패키지:

cat >> ~/.zshrc << 'EOF'
alias cc='claude'
alias ccd='claude --dangerously-skip-permissions'
alias ccr='claude --resume --dangerously-skip-permissions'
EOF
source ~/.zshrc

Windows WSL 풀 패키지:

cat >> ~/.bashrc << 'EOF'
alias cc='claude'
alias ccd='claude --dangerously-skip-permissions'
alias ccr='claude --resume --dangerously-skip-permissions'
EOF
source ~/.bashrc

5. 작동 확인

새 터미널을 열거나 설정 파일을 다시 불러온 뒤 cc를 입력합니다.

cc

Claude Code가 실행되면 성공입니다. 이미 다른 프로그램이 cc라는 이름을 쓰고 있다면 clc, claudie처럼 다른 별명을 선택하면 돼요. 이때도 무작정 고치지 말고 Claude Code나 안티그래비티 agent에게 현재 alias 목록을 확인하는 방법을 물어보면 됩니다.

📦 결과물

마지막 결과물은 선택한 모드와 alias 기록입니다. 저장 위치는 50-my-work/Part02-시작하기/실습04-모드소개-Alias/예요.

실습04-모드소개-Alias/
└── README.md          # 선택한 모드, alias 설정 여부, OS별 설정 파일 기록

README에는 다음 내용을 기록합니다. 나중에 새 터미널에서 cc가 안 먹힐 때, 이 기록이 꽤 도움이 됩니다.

progress.json에는 Part 02 완료, 실습 4 완료, 선호 모드, alias 설정 여부가 반영됩니다. 이 클립까지 끝나면 설치와 첫 조작 준비가 마무리돼요.

🆘 자주 막히는 포인트

🔗 다음 클립

다음은 Part 3 / Clip 1: 대화 패턴 5단계 입니다. Part 02에서 설치, 첫 실행, 권한 모드, alias까지 끝냈으니 이제 대화만으로 실제 결과물을 만드는 흐름으로 들어갑니다. 여기부터가 진짜 재미있는 구간이에요.

🎯 이 클립에서 만드는 것

첫 클립부터 파일을 만들지는 않습니다. 대신 앞으로 9개 실습에서 계속 반복할 대화 방식을 먼저 잡고 가요. 데이터 분석, 보고서, 대시보드, 카드뉴스, 영상, 포트폴리오, 배포까지 결과물은 매번 달라지지만 흐름은 같습니다.

핵심은 질문하기 → 기획하기 → 만들기 → 검토하기 → 개선하기입니다. 저는 이걸 그냥 "AI에게 말 잘 거는 법" 정도로 보지 않습니다. 뭘 만들든 이 순서가 잡히면 결과물이 훨씬 덜 흔들려요.

여러분이 이 클립 끝에 가져갈 건 파일이 아니라 패턴입니다. 이 패턴 하나로 Part 3 전체를 밀고 갑니다.

💡 핵심 개념

BUILD 기법 = 5단계입니다

여기서 제일 중요합니다. BUILD 기법은 5단계예요. 새로 외울 게 두 벌 있는 게 아닙니다. Part 01에서 본 BUILD를 한국어로 풀면 바로 이 흐름입니다.

B(질문) + U(기획) + I(만들기) + L(검토) + D(개선). 뭘 만들든 이 한 가지 패턴이에요.

AI를 처음 쓰면 바로 "보고서 작성", "대시보드 생성"처럼 결과부터 말하고 싶잖아요? 그런데 그렇게 던지면 AI는 우리 머릿속 맥락을 모른 채 달리기 시작합니다. 좋은 시작은 명령이 아니라 질문입니다. "이런 일을 하려는데 어떻게 접근하면 좋을까요?" 이 한 줄에서 일이 풀려요.

1단계: 질문하기

질문하기는 "이런 거 하려는데 어떻게 시작하면 좋을까요?"라고 묻는 단계입니다. 아직 만들지 않아요. 가능한 방법, 필요한 자료, 먼저 정해야 할 항목을 넓게 보는 시간입니다.

경쟁사 분석 임원 보고를 준비하려는데, 먼저 정해야 할 항목과 슬라이드 구성 옵션을 2~3개로 정리해 주세요.

2단계: 기획하기

기획하기는 선택한 방향을 조건으로 묶는 단계입니다. 무엇을 만들지, 어떤 자료를 쓸지, 어떤 형식이 필요한지 정리합니다. 마지막에는 꼭 "내 요청을 어떻게 이해했는지 다시 설명해 주세요"라고 확인시켜 보세요.

의사결정용 8장 슬라이드로 가려고 합니다. 비교 대상은 A·B·C 경쟁사, 기준은 가격·기능·점유율·R&D입니다. 임원이 Q3 투자 우선순위를 정하는 데 쓰는 보고서로 이해했는지 다시 설명해 주세요.

3단계: 만들기

만들기는 충분히 좁힌 뒤 실행하는 단계입니다. 한 번에 완성본을 요구하기보다 뼈대 먼저, 살은 나중에가 안전해요. 목차, 섹션, 핵심 메시지처럼 큰 구조가 맞아야 세부 내용도 덜 흔들립니다.

위 조건으로 8장 슬라이드의 목차와 각 장 핵심 메시지 1줄을 먼저 만들려고 합니다. 구조를 먼저 제안한 뒤, 확인 후 본문 작성으로 이어가세요.

4단계: 검토하기

검토하기는 AI가 만든 결과물을 사람이 기준으로 보는 단계입니다. 특히 보고서와 리서치에서는 근거, 일관성, 의도 부합을 봐야 합니다. AI가 말은 매끄럽게 만들 수 있어요. 하지만 최종 판단은 여러분이 합니다.

완성된 슬라이드를 검증하려고 합니다. 각 주장에 출처가 있는지, 경쟁사 비교 기준이 일관적인지, 임원 의사결정에 필요한 결론이 보이는지 점검해 주세요.

5단계: 개선하기

개선하기는 전체를 다시 시작하는 단계가 아닙니다. 좋은 부분은 남기고, 문제 있는 위치만 고쳐요. 위치, 바꿀 기준, 유지할 범위를 같이 말하면 결과가 훨씬 안정적입니다.

6번 슬라이드의 B사 신규 기능 출시 문장 옆에 출처를 푸터로 추가하려고 합니다. 다른 슬라이드의 내용과 디자인은 그대로 유지하세요.

여기까지가 BUILD 기법입니다. 질문하기가 B, 기획하기가 U, 만들기가 I, 검토하기가 L, 개선하기가 D예요. 약자를 따로 외우기보다 일의 순서로 기억하시면 됩니다.

🚶 진행 흐름

한 시나리오로 5단계 풀어보기

5단계만 따로 들으면 조금 추상적이죠. 그래서 이제 한 시나리오로 풀어보겠습니다. 상황은 경쟁사 분석 임원 보고입니다. 다음 주 임원 회의에서 Q3 투자 우선순위를 정해야 하고, 발표 시간은 10분. 결과물은 8장 내외 슬라이드라고 가정할게요.

실제 대화 흐름

1. 질문하기에서는 선택지를 넓힙니다.

경쟁사 분석 임원 보고를 만들려는데, 먼저 정해야 할 항목 체크리스트와 슬라이드 구성 옵션을 2~3개로 정리해 주세요.

2. 기획하기에서는 선택한 방향을 조건으로 묶습니다.

의사결정용 8장 구성으로 가려고 합니다. 1장은 표지, 2장은 시장 포지셔닝, 3~5장은 A·B·C 비교, 6장은 위협과 기회, 7장은 Q3 투자 권고, 8장은 Q&A입니다. 이 요청을 어떻게 이해했는지 다시 설명해 주세요.

3. 만들기에서는 뼈대를 먼저 확인합니다.

위 조건으로 각 장의 핵심 메시지 1줄과 필요한 근거 자료를 먼저 정리하려고 합니다. 목차 초안을 만든 뒤 확인을 기다리세요.

4. 검토하기에서는 기준을 가지고 봅니다.

초안을 검토하려고 합니다. 모든 수치에 출처가 있는지, A·B·C 비교 축이 같은지, 7장의 권고가 임원 결정에 충분한지 확인해 주세요.

5. 개선하기에서는 한 부분만 고칩니다.

6번 슬라이드의 B사 신규 기능 출시 항목에 출처를 추가하려고 합니다. 푸터에 "B사 IR 2026 Q1 p.18"을 넣고, 다른 슬라이드는 그대로 유지하세요.

이 흐름을 거치면 반나절 걸리던 일이 10~30분 단위로 줄어듭니다. 시간이 줄어드는 이유는 단계를 대충 넘겨서가 아닙니다. 각 단계에서 사람이 손으로 하던 일을 클로드코드에게 명확히 맡기기 때문이에요.

📦 결과물

이번엔 이론 클립이라 별도 실습 파일은 만들지 않습니다. 대신 Part 3의 모든 실습에서 아래 흐름을 반복해서 씁니다.

Part03-체험하기/
├── 실습05-데이터분석/
├── 실습06-보고서작성/
├── 실습07-대시보드/
├── 실습08-자료리서치/
├── 실습09-카드뉴스/
├── 실습10-리모션영상/
├── 실습11-포트폴리오기획/
├── 실습12-포트폴리오수정/
└── 실습13-Vercel배포/

이번 클립에서 남길 것은 파일이 아니라 대화 습관입니다. 제가 계속 강조하는 이유가 있어요. 앞으로 프롬프트를 쓸 때 바로 결과부터 말하고 싶어지면, 먼저 "하려는데 어떻게?"로 묻고 있는지 확인하면 됩니다.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 2: 데이터 분석 — 이제 같은 5단계를 CSV 데이터에 적용합니다.

다음 클립부터는 실제 파일을 만듭니다. 첫 결과물은 쫀득팩토리 1분기 운영 데이터를 분석한 인사이트와 차트예요. BUILD가 진짜로 어떻게 굴러가는지 바로 보실 겁니다.

🎯 이 클립에서 만드는 것

CSV 8개를 받으면 보통 엑셀 열고, 피벗 만들고, 차트 하나씩 그리잖아요. 그러다 보면 1~2시간은 금방 갑니다. 이번 클립에서는 그 일을 클로드코드와 같이 줄여봅니다.

쫀득팩토리라는 가상 디저트 제조사의 1분기 운영 데이터 8개 CSV를 분석합니다. 목표는 숫자 파일을 그냥 열어보는 게 아니라, 볼 만한 관점 5개를 뽑고 그중 일부를 차트 PNG 5~10장으로 만드는 거예요.

여러분이 자동 셋업 코드를 직접 만질 필요는 없습니다. 작업 폴더와 자료가 준비되어 있다는 전제에서, 아래 결과를 만드는 흐름만 따라가면 됩니다.

50-my-work/Part03-체험하기/실습05-데이터분석/
├── sample_csv/
│   ├── 쫀득팩토리 1분기 운영 데이터 CSV 8개
│   └── ...
├── charts/
│   ├── chart-01.png
│   ├── chart-02.png
│   └── ...
└── README.md

핵심 결과는 분석 관점 목록과 차트 이미지입니다. 제가 여기서 꼭 보라고 하는 건 "차트를 몇 장 만들었냐"가 아니에요. 어떤 질문으로 차트까지 갔는지입니다. 다음 Clip 3에서는 이 결과를 그대로 가져가 임원 보고서로 확장합니다.

💡 핵심 개념

데이터 분석은 "파일 읽기"가 아니라 "무엇을 볼지 고르는 일"입니다

CSV가 8개 있다고 바로 차트를 그리면, 그림은 나옵니다. 그런데 메시지가 약할 수 있어요. 냉장고에 재료가 많다고 무작정 볶기보다, 오늘 김치볶음밥을 할지 파스타를 할지 먼저 정하는 게 더 중요하잖아요?

그래서 이 클립의 핵심은 가능한 분석 관점을 펼친 뒤, 그중 몇 개를 고르는 것입니다. 예를 들어 위기 진단, 원가 추이, 라인별 매출, 운영 효율, 재고 균형처럼 나뉘면 차트 종류도 자연스럽게 정해져요.

차트 생성에는 pandas, matplotlib 같은 도구가 쓰일 수 있습니다. 솔직히 도구 이름을 외우는 게 핵심은 아닙니다. AI에게 데이터 위치, 보고 싶은 관점, 저장 위치, 수정 범위를 분명히 말하는 게 핵심이에요.

🚶 진행 흐름

1. 던지기: 가능한 방법 묻기

처음부터 차트 달라고 하지 마세요. 먼저 "이 데이터로 뭘 볼 수 있냐"를 물어봅니다. 이게 BUILD의 B, 질문하기입니다.

sample_csv 폴더에 CSV 8개가 있는데, 이걸로 데이터 분석과 차트 생성을 하려는데 어떻게 접근하면 좋을까요? 필요한 도구와 진행 순서를 먼저 알려주세요.

2. 기획하기: 관점과 차트 후보 받기

AI가 가능한 흐름을 설명하면, 이제 볼 만한 관점을 넓게 펼치게 합니다. 여기서 여러분이 고르는 일이 시작돼요.

이 데이터를 실제로 분석하려고 합니다. 확인할 만한 관점 5개와 각 관점에 어울리는 차트 후보를 같이 정리해 주세요. 관점은 운영자가 의사결정에 쓸 수 있는 수준이면 좋겠습니다.

여기서 나온 후보 중 1~2개를 고르면 됩니다. 예를 들어 원가 추이와 라인별 매출을 고르면, 차트도 선그래프·막대그래프처럼 자연스럽게 좁혀져요.

3. 만들기: 차트 PNG 생성

고른 관점으로 차트를 만듭니다. 저는 여기서 저장 위치와 형식을 꼭 같이 말합니다. 안 그러면 텍스트 답변만 받고 끝날 때가 있어요.

원가 추이와 라인별 매출 관점으로 차트를 만들려고 합니다. matplotlib 기반 PNG 5~10장을 charts 폴더에 저장하고, 한글은 AppleGothic 또는 NanumGothic으로 표시되게 진행하세요.

4. 검증하기: 결과 확인

차트가 생기면 파일 개수만 보지 말고, 실제로 열어봅니다. 한글이 네모로 깨지거나 축 라벨이 안 보이면 업무에서는 바로 못 씁니다.

charts 폴더의 PNG를 검증하려고 합니다. 숫자 계산이 CSV와 맞는지, 제목과 축 라벨이 읽히는지, 한글이 깨지지 않는지 체크해 주세요.

5. 개선하기: 한 장만 부분 수정

수정할 때는 전체를 다시 만들지 말고, 특정 차트만 집어 말합니다. "다른 건 그대로" 한 줄, 이거 정말 중요해요.

3번 차트의 색상이 흐려서 더 선명하게 조정하려고 합니다. 3번 차트만 다시 그리고, 나머지 차트와 파일명은 그대로 유지하세요.

이렇게 하면 차트 8장을 다시 만들다가 잘 된 부분까지 바뀌는 일을 줄일 수 있습니다.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습05-데이터분석/입니다. 여기만 찾으면 여러분 결과물이 한 번에 보여야 합니다.

실습05-데이터분석/
├── sample_csv/        # 강의용 CSV 8개
├── charts/            # 분석 결과 차트 PNG 5~10장
└── README.md          # 진행 요약과 한 줄 회고

README.md에는 사용한 데이터, 선택한 분석 관점, 생성한 차트 개수, 가장 인상적인 발견을 적습니다. 분석 답변을 별도 .md 파일로 저장했다면 같이 남겨도 좋아요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 3: 보고서 작성 — 방금 만든 분석 관점과 차트를 30페이지 내외의 임원 보고서로 확장합니다.

데이터 분석의 끝은 차트가 아니라 읽히는 설명입니다. 다음 클립에서 차트와 숫자를 보고서 문장으로 연결해볼게요.

🎯 이 클립에서 만드는 것

차트만 던져주면 임원이 바로 결정하기 어렵습니다. 이번 클립에서는 Clip 2에서 만든 분석 관점과 차트 PNG를 가져와 30페이지 내외의 임원 보고서로 바꿉니다.

차트는 그림으로 끝나면 아깝습니다. 숫자 근거가 붙은 문장과 연결되어야 해요. 보고서의 목표는 "분석을 많이 했다"를 보여주는 게 아니라, 읽는 사람이 5분 안에 핵심을 잡게 하는 것입니다. 저는 그래서 목차, 차트 배치, 주장과 근거의 순서를 먼저 잡습니다.

50-my-work/Part03-체험하기/실습06-보고서작성/
├── sample_csv/
├── charts/
├── 쫀득팩토리_2026Q1_경영분석보고서.md
└── README.md

Clip 2를 건너뛰었다면 차트가 없을 수 있습니다. 괜찮아요. 그 경우에는 CSV만으로 보고서를 만들거나, 보고서 작성 중 필요한 차트를 새로 만들어도 됩니다.

💡 핵심 개념

보고서는 차트 모음이 아니라 판단의 순서입니다

차트를 8장 만들었다고 보고서가 되는 건 아닙니다. 보고서는 독자가 어떤 순서로 숫자를 이해해야 하는지 안내하는 길이에요. 지도에 점이 많아도 길이 없으면 목적지에 못 가잖아요?

임원 보고서는 특히 요약 → 근거 → 해석 → 권고의 흐름이 중요합니다. 숫자를 먼저 보여주고, 그 숫자가 왜 중요한지 설명하고, 마지막에 어떤 결정을 돕는지 연결해야 해요.

이 클립에서는 charts/ 폴더의 PNG를 Markdown 문서 안에 인라인으로 넣습니다. 파일명과 경로가 맞아야 이미지가 안 깨집니다. 여러분이 먼저 챙길 건 예쁜 문장이 아니라 근거가 빠지지 않는 구조예요.

🚶 진행 흐름

1. 던지기: 보고서로 바꾸는 방법 묻기

분석 결과와 차트가 있다는 상황을 설명하고, 보고서 작성 흐름을 먼저 물어봅니다. 바로 "보고서 써줘"로 가지 않는 게 핵심이에요.

방금 만든 분석 결과와 charts 폴더의 PNG 8장을 임원 보고서로 바꾸려는데, 어떤 순서로 진행하면 좋을까요? 목차, 차트 인용, 숫자 근거 정리 방식을 먼저 알려주세요.

2. 기획하기: 목차와 차트 배치 정하기

보고서의 목차 후보를 받고, 각 장에 어떤 차트가 들어가면 좋을지 연결합니다. 이 단계에서 보고서 품질이 거의 결정돼요.

쫀득팩토리 2026년 1분기 경영분석 보고서를 만들려고 합니다. 30페이지 내외 분량으로 목차 옵션을 제안하고, 각 장에 들어갈 차트와 표를 매핑해 주세요.

AI가 제안한 목차 중 하나를 고르면 됩니다. 보통은 요약, 핵심 지표, 운영 이슈, 재무 관점, 권고안처럼 읽는 순서가 보이는 구조가 좋아요.

3. 만들기: Markdown 보고서 생성

고른 목차를 기준으로 실제 보고서 파일을 만듭니다. 제가 여기서 꼭 넣는 건 파일명과 이미지 인용 방식입니다. 안 넣으면 파일명이 제멋대로 나오거나 이미지가 빠질 수 있어요.

선택한 목차대로 보고서를 작성하려고 합니다. 결과 파일은 쫀득팩토리_2026Q1_경영분석보고서.md로 두고, charts 폴더의 PNG를 Markdown 이미지 문법으로 인라인 인용하세요. 각 주장에는 숫자 근거를 함께 적어 주세요.

4. 검증하기: 근거와 흐름 확인

보고서가 만들어지면 문장만 읽지 말고, 차트와 주장이 맞물리는지 봅니다. 말이 매끄러워도 숫자가 빠지면 보고서가 약해집니다.

작성된 보고서를 검증하려고 합니다. 주장마다 숫자 근거가 있는지, 차트 경로가 깨지지 않는지, 장별 결론이 서로 충돌하지 않는지 점검해 주세요.

5. 개선하기: 특정 장만 보강

부족한 장 하나를 골라 부분 수정합니다. 전체 다시 쓰기는 위험해요. 좋았던 문장까지 같이 바뀔 수 있습니다.

3장 운영 효율 부분만 보강하려고 합니다. 관련 차트 1개를 더 인용하고 결론 문장 1줄을 추가하세요. 다른 장의 구성과 문장은 그대로 유지하세요.

수정 범위를 장 단위로 말하면, 보고서 전체가 다시 쓰이면서 어조가 바뀌는 일을 줄일 수 있어요.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습06-보고서작성/입니다. 여기에 보고서와 차트가 같이 있어야 프리뷰에서 덜 깨집니다.

실습06-보고서작성/
├── sample_csv/                                # 필요 시 원본 데이터 확인
├── charts/                                    # Clip 2에서 만든 차트
├── 쫀득팩토리_2026Q1_경영분석보고서.md       # 최종 보고서
└── README.md                                  # 진행 방식과 회고

README.md에는 사용한 자료, 보고서 파일명, 차트 개수, 가장 중요한 결론을 한 줄로 남깁니다. 보고서 파일은 다음 클립에서 직접 쓰이지는 않지만, 같은 데이터를 대시보드로 바꿀 때 비교 기준이 돼요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 4: 대시보드 만들기 — 같은 CSV 데이터를 인터랙티브 HTML 대시보드로 바꿉니다.

보고서는 읽는 결과물이고, 대시보드는 만져보는 결과물입니다. 같은 숫자가 형식에 따라 어떻게 달라지는지 비교해 보시면 됩니다.

🎯 이 클립에서 만드는 것

보고서를 만들고 나면 이런 질문이 나옵니다. "이거 매주 업데이트되는 화면으로 볼 수 없나요?" 그게 대시보드예요. 이번 클립에서는 Ch 02에서 계속 사용한 sample_csv 데이터를 탭이 있는 HTML 대시보드로 만듭니다.

결과물은 index.html 한 파일입니다. 브라우저에서 열면 탭을 눌러 전환하고 차트를 확인할 수 있어요. 보고서가 읽는 문서라면, 대시보드는 눌러보며 이해하는 화면입니다. 저는 이 차이를 꼭 보여주고 싶습니다.

50-my-work/Part03-체험하기/실습07-대시보드/
├── sample_csv/
├── index.html
└── README.md

이 클립은 Ch 02의 마지막입니다. 같은 CSV에서 분석, 보고서, 대시보드라는 세 가지 결과물이 나옵니다. 여러분이 직접 코드를 한 줄씩 치는 게 아니라, 대화로 결과물을 바꾸는 흐름을 보는 거예요.

💡 핵심 개념

대시보드는 주제별 칸으로 나눕니다

대시보드를 처음 만들 때 흔한 실수는 모든 차트를 한 화면에 밀어 넣는 겁니다. 그러면 보는 사람은 어디부터 봐야 할지 몰라요. 옷장도 상의, 하의, 외투를 칸으로 나누잖아요? 데이터도 주제별 칸이 필요합니다.

이번 클립에서는 탭을 3개 정도로 나누고, 각 탭마다 핵심 차트를 먼저 넣습니다. 처음부터 완벽한 화면을 만들지 않습니다. 1차 뼈대 → 2차 확장으로 가요.

핵심은 기술 이름이 아니라 확인 순서입니다. 첫 번째 버전에서는 탭 전환과 핵심 차트 1개씩만 확인하세요. 그다음 필요한 탭에 차트를 1~2개씩 추가하면 수정 비용이 작습니다.

🚶 진행 흐름

1. 던지기: 대시보드 제작 방식 묻기

CSV를 브라우저 대시보드로 바꾸는 가능한 방법을 먼저 묻습니다. 바로 index.html 만들어 달라고 하면 구조가 흔들릴 수 있어요.

sample_csv 폴더의 CSV 8개로 인터랙티브 대시보드를 만들려는데, 어떤 방식으로 접근하면 좋을까요? 한 파일 HTML로 가능한지, 필요한 라이브러리와 흐름을 알려주세요.

2. 기획하기: 탭과 차트 설계

어떤 탭이 필요하고, 각 탭에 어떤 차트가 들어갈지 정합니다. 이때 "임원이 한눈에"처럼 보는 사람을 같이 말해주면 훨씬 좋아집니다.

임원이 한눈에 볼 수 있는 대시보드를 만들려고 합니다. 탭 구성 옵션 3개를 제안하고, 각 탭에 들어갈 차트 후보와 보여줄 메시지를 함께 정리해 주세요.

탭은 많을수록 좋은 게 아닙니다. 처음에는 운영, 재무, 라인별 성과 정도로 나누고, 각 탭에 핵심 차트부터 넣어보세요.

3. 만들기: 1차 HTML 생성

첫 버전은 작게 만듭니다. 한 파일 안에서 CSV를 읽고 차트를 그리는 구조로 가요. 제가 계속 "뼈대 먼저"라고 말하는 이유가 여기 있습니다.

선택한 탭 구조로 index.html 1차 버전을 만들려고 합니다. 한 파일 안에 Chart.js와 PapaParse CDN을 사용하고, 탭 3개와 핵심 차트 1개씩부터 구현하세요.

이후 필요한 탭만 확장합니다. 잘 되는 뼈대를 확인한 뒤 살을 붙이는 거죠.

운영 탭에 차트 2개를 더 추가하려고 합니다. 색상 톤도 조금 정돈하되, 재무 탭과 라인별 탭은 그대로 유지하세요.

4. 검증하기: 브라우저에서 확인

HTML 파일은 브라우저에서 직접 열어봐야 합니다. 터미널에서 "완료"라고 떠도, 화면이 빈 페이지면 아직 끝난 게 아니에요.

index.html을 검증하려고 합니다. 탭 전환이 되는지, CSV 데이터가 정상 로드되는지, 차트 수치가 원본과 맞는지, 모바일 폭에서 깨지는지 점검해 주세요.

5. 개선하기: 특정 탭만 수정

대시보드는 작은 수정이 잦습니다. 위치를 정확히 말하세요. "재무 탭만"처럼 범위를 잘라야 다른 탭이 덜 흔들립니다.

재무 탭의 색상 대비만 개선하려고 합니다. 배경과 차트 색상을 더 구분되게 조정하고, 다른 탭의 레이아웃과 데이터 처리는 그대로 유지하세요.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습07-대시보드/입니다. 여기서 index.html만 열리면 일단 절반은 성공입니다.

실습07-대시보드/
├── sample_csv/       # 대시보드가 읽는 CSV
├── index.html        # Chart.js + PapaParse 기반 대시보드
└── README.md         # 탭 구성과 확인 결과

완성 후에는 index.html을 브라우저로 열어 확인합니다. README.md에는 탭 이름, 사용한 차트, 가장 유용했던 대시보드 관점을 적으면 됩니다.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 5: 자료 리서치 — Ch 03으로 넘어가 주제 한 줄에서 콘텐츠 재료를 수집합니다.

Ch 02에서는 데이터가 이미 있었습니다. 다음부터는 재료가 없는 상태에서 시작합니다. 주제 한 줄로 검색해서 자료를 모으는 흐름이에요.

🎯 이 클립에서 만드는 것

Ch 02에서는 CSV 파일을 던져주고 시작했죠? 이번엔 손에 든 게 주제 한 줄뿐입니다. 거기서 출처 붙은 리서치 문서까지 끌어내야 해요. 어떻게 시작할까요?

그 한 줄을 검색 가능한 질문으로 바꾸는 것부터 시작합니다. 결과물은 02-주제리서치.md입니다. 예시는 2026년 AI 주요 이슈 5개를 조사하는 흐름이지만, 여러분 관심 주제로 바꿔도 됩니다.

50-my-work/Part03-체험하기/실습08-자료리서치/
├── 02-주제리서치.md
└── README.md

이 문서는 다음 Clip 6에서 카드뉴스의 원고 재료가 됩니다. 그래서 짧은 감상문이면 안 됩니다. 항목별 핵심 요약과 출처 URL이 꼭 필요해요.

💡 핵심 개념

리서치는 검색어를 잘 던지는 일입니다

좋은 리서치는 많은 페이지를 긁어오는 일이 아닙니다. 어떤 질문으로 검색할지, 어떤 기준으로 정리할지, 출처를 어떻게 남길지 정하는 일이에요. 도서관에서 책장을 무작정 훑는 것보다 사서에게 "이 주제 최신 자료 찾으려면 어떤 키워드가 좋을까요?"라고 묻는 것에 가깝습니다.

클로드코드에는 검색 흐름을 도와주는 방식이 있습니다. 넓게 찾을 때는 WebSearch, 특정 페이지를 읽을 때는 WebFetch. 저는 이 둘을 "검색이냐, 가져오기냐"로 구분해서 봅니다.

이번 클립의 목표는 5개 항목, 각 항목 핵심 2~3줄, 출처 URL 1~2개입니다. 다음 콘텐츠 제작 단계에서 바로 쓸 수 있게 정리해두는 게 중요합니다.

🚶 진행 흐름

1. 던지기: 검색 방법 묻기

바로 검색을 시키기보다, 어떤 방식으로 검색할 수 있는지 먼저 물어봅니다. 결과부터 달라고 하면 출처가 약해질 때가 많아요.

클로드코드로 인터넷 자료 리서치를 하려는데, 어떤 방식으로 접근하면 좋을까요? 키워드 검색과 특정 URL 읽기의 차이, 출처를 남기는 방법을 알려주세요.

2. 기획하기: 주제와 정리 형식 정하기

주제와 결과 형식을 함께 말합니다. "무엇을 찾을지"와 "어떻게 남길지"가 같이 들어가야 합니다.

2026년 AI 주요 이슈 5개를 조사하려고 합니다. 검색 키워드 후보와 정리 형식 옵션을 제안해 주세요. 각 항목은 핵심 요약, 왜 중요한지, 출처 URL로 정리하고 싶습니다.

AI가 키워드를 제안하면, 너무 넓거나 오래된 키워드는 줄이고 현재성 있는 키워드를 고르면 됩니다. 주제가 한국 시장과 관련 있다면 "국내 기준"도 같이 넣으세요.

3. 만들기: 리서치 문서 작성

검색을 실행하고 파일로 저장합니다. 제가 꼭 넣는 문장은 "추측 말고 실제 검색 결과 기반으로"입니다. 이 한 줄이 결과 신뢰도를 꽤 바꿔요.

선택한 방식으로 2026년 AI 주요 이슈 5개를 조사하려고 합니다. 각 항목은 핵심 2~3줄, 이슈의 영향 1줄, 출처 URL 1~2개로 정리하고 결과는 02-주제리서치.md에 저장하세요.

4. 검증하기: 출처와 항목 확인

리서치 문서는 링크가 생명입니다. 링크가 없거나 안 열리면 다음 단계에서 신뢰도가 떨어집니다. 여러분도 실제로 몇 개는 눌러보셔야 합니다.

02-주제리서치.md를 검증하려고 합니다. 5개 항목이 모두 주제와 맞는지, 출처 URL이 실제로 열리는지, 추측처럼 보이는 문장이 없는지 점검해 주세요.

5. 개선하기: 항목 하나만 보강

문제가 있는 항목만 다시 다룹니다. 전체를 다시 검색하면 잘 찾은 자료까지 바뀔 수 있어요.

3번 항목의 근거가 약해서 보강하려고 합니다. 공식 발표나 신뢰도 높은 출처를 1개 더 찾아 추가하고, 다른 항목의 내용은 그대로 유지하세요.

리서치에서는 항목 번호와 바꿀 기준을 꼭 같이 말하세요. "3번만, 다른 건 그대로"가 안전한 공식입니다.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습08-자료리서치/입니다. 파일 하나지만, 다음 클립의 출발점이 됩니다.

실습08-자료리서치/
├── 02-주제리서치.md    # 5개 항목 + 출처 URL
└── README.md           # 선택한 주제와 한 줄 회고

02-주제리서치.md에는 항목마다 제목, 핵심 요약, 영향, 출처 URL이 들어갑니다. 다음 클립에서 이 문서를 읽어 10장 카드뉴스 기획서로 바꿔요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 6: 카드뉴스 만들기 — 리서치 문서를 10장짜리 HTML 카드뉴스로 바꿉니다.

리서치는 콘텐츠의 재료 창고입니다. 다음 클립에서는 이 재료를 한 장씩 넘겨보는 카드 구조로 재배치해볼게요.

🎯 이 클립에서 만드는 것

리서치 문서가 생겼다고 바로 카드뉴스가 되지는 않습니다. 이번 클립에서는 Clip 5에서 만든 02-주제리서치.md를 바탕으로 10장짜리 HTML 카드뉴스를 만듭니다.

바로 HTML로 가지 않습니다. 먼저 기획서를 만들고, 그 기획서를 기준으로 실제 HTML을 생성해요. 결과물은 두 개입니다. 01-카드뉴스-기획서.md는 카드별 내용 설계서이고, 02-카드뉴스.html은 브라우저에서 볼 수 있는 정사각 카드뉴스입니다.

50-my-work/Part03-체험하기/실습09-카드뉴스/
├── 02-주제리서치.md
├── 01-카드뉴스-기획서.md
├── 02-카드뉴스.html
└── README.md

카드뉴스는 다음 Clip 7에서 영상으로 바뀝니다. 그래서 카드 수, 카드 크기, 흐름이 일정해야 해요. 여러분이 여기서 대충 만들면 다음 영상 단계에서 바로 티가 납니다.

💡 핵심 개념

카드뉴스는 디자인보다 "장면 나누기"가 먼저입니다

리서치 문서를 바로 HTML로 만들면 카드가 7장으로 줄거나 15장으로 늘어나는 일이 생깁니다. 그래서 먼저 기획서가 필요해요. 영화 촬영 전에 콘티를 그리는 것과 같습니다.

10장 카드뉴스는 보통 도입, 문제 제기, 핵심 항목, 정리, 마무리로 흐릅니다. 각 카드는 하나의 메시지만 담는 게 좋아요. 한 카드에 문장을 많이 넣으면 모바일에서 읽기 어렵습니다.

HTML은 1080×1080 정사각을 기준으로 만들고, 모바일에서는 화면 폭에 맞게 줄어들게 합니다. 저는 한글 가독성 때문에 Pretendard를 기준으로 잡는 편입니다. 안정적이에요.

🚶 진행 흐름

1. 던지기: 카드뉴스 형태 묻기

카드뉴스가 어떤 구조로 만들어지는지 먼저 확인합니다. "카드뉴스 만들어줘"로 바로 가면 장수부터 흔들릴 수 있어요.

리서치 결과를 카드뉴스로 만들려는데, 보통 어떤 형태와 구조로 진행하면 좋을까요? 인스타 정사각 카드 기준으로 카드 수, 흐름, 제작 순서를 알려주세요.

2. 기획하기: 10장 기획서 설계

리서치 문서를 읽고 카드별 역할을 나누게 합니다. 이 단계에서 10장의 흐름이 정해집니다.

02-주제리서치.md의 5개 이슈로 인스타 10장 카드뉴스를 만들려고 합니다. 카드별 제목, 본문 핵심, 시각 요소, 색상 방향을 포함한 구성 옵션을 제안해 주세요.

여기서 바로 HTML로 가지 마세요. 먼저 10장 구성이 적절한지 확인합니다. 제가 제일 많이 멈춰 세우는 지점이 여기예요.

3. 만들기: 기획서 작성 후 HTML 생성

두 단계로 나눕니다. 먼저 기획서입니다. 기획서가 있으면 HTML 결과도 훨씬 예측 가능해집니다.

선택한 구조로 01-카드뉴스-기획서.md를 먼저 만들려고 합니다. 카드 1~10번의 제목, 핵심 문장, 이미지 방향, 색상 톤을 표로 정리하세요.

그다음 HTML입니다. 이제야 실제 화면을 만듭니다.

01-카드뉴스-기획서.md를 기준으로 02-카드뉴스.html을 만들려고 합니다. 한 파일 안에 10장, 1080×1080 정사각 카드, 세로 스크롤, Pretendard 폰트, 이미지 자리까지 포함해 구현하세요.

4. 검증하기: 카드 수와 가독성 확인

브라우저에서 열어 10장이 모두 보이는지 확인합니다. 파일이 만들어졌다고 끝난 게 아니에요. 빈 카드가 하나라도 있으면 다시 봐야 합니다.

02-카드뉴스.html을 검증하려고 합니다. 카드가 정확히 10장인지, 빈 카드가 없는지, 모바일 폭에서 글자가 잘리는지, 한글 폰트가 적용됐는지 점검해 주세요.

5. 개선하기: 카드 하나만 수정

카드뉴스 수정은 카드 번호를 꼭 말해야 합니다. "3번 카드만"이라고 잘라 말해야 나머지 9장이 덜 흔들립니다.

3번 카드의 배경색만 더 부드럽게 바꾸려고 합니다. 배경색을 #FFE5EC 계열로 조정하고, 다른 카드의 내용과 레이아웃은 그대로 유지하세요.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습09-카드뉴스/입니다. 리서치, 기획서, HTML이 한 폴더에 같이 있어야 흐름이 보입니다.

실습09-카드뉴스/
├── 02-주제리서치.md
├── 01-카드뉴스-기획서.md
├── 02-카드뉴스.html
└── README.md

README.md에는 카드뉴스 주제, 카드 수, 확인한 문제, 가장 마음에 드는 카드 한 장을 적습니다. 다음 클립에서는 02-카드뉴스.html을 자동 스크롤 영상으로 변환해요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 7: 리모션 영상 — 카드뉴스 HTML을 30초 내외의 MP4 영상으로 바꿉니다.

지금 만든 카드는 영상의 장면이 됩니다. 카드별 메시지가 선명할수록 다음 단계의 영상 품질도 좋아져요.

🎯 이 클립에서 만드는 것

카드뉴스 10장을 영상으로 만들려면 보통 캡처하고, 편집기에 올리고, 타임라인 맞춥니다. 생각보다 손이 많이 가죠. 이번 클립에서는 Clip 6에서 만든 02-카드뉴스.html을 영상으로 바꿉니다.

브라우저에서 카드뉴스를 열고, 카드 한 장씩 일정 시간 머무르며 스크롤하는 과정을 녹화해 output.mp4를 만들어요. 텍스트로 새 영상을 생성하는 실습이 아니라, 이미 만든 HTML 콘텐츠를 자동화 도구로 촬영하는 흐름입니다.

50-my-work/Part03-체험하기/실습10-리모션영상/
├── 02-카드뉴스.html
├── output.mp4
└── README.md

그래서 카드뉴스의 카드 수와 레이아웃이 안정적일수록 영상도 안정적으로 나옵니다. 이 클립을 마치면 Ch 03은 주제 한 줄에서 시작해 리서치, 카드뉴스, 영상까지 이어져요. 여러분이 방금 만든 파일이 그대로 다음 결과물이 되는 겁니다.

💡 핵심 개념

영상 만들기는 두 갈래로 생각합니다

AI 영상이라고 하면 텍스트를 넣어 새 장면을 생성하는 도구를 떠올리기 쉽습니다. 그런데 업무 실습에서는 이미 만든 자료를 영상으로 바꾸는 경우도 많아요. 예를 들어 카드뉴스를 쇼츠처럼 보여주거나, 웹페이지 스크롤을 녹화해 소개 영상으로 만드는 방식입니다.

이번 클립은 두 번째입니다. 저는 이걸 "기존 자료 영상화"라고 부릅니다. Playwright로 브라우저를 자동 제어하고, 카드마다 3초 정도 머무르며 스크롤한 뒤, MP4로 저장합니다.

중요한 것은 영상 도구 이름보다 입력 자료가 무엇인지입니다. 이번 입력은 카드뉴스 HTML이고, 출력은 output.mp4예요.

🚶 진행 흐름

1. 던지기: 영상 제작 방법 묻기

먼저 어떤 방식으로 영상화할 수 있는지 물어봅니다. 그냥 "영상 만들어줘"라고 하면 범위가 너무 넓어져요.

클로드코드로 영상을 만들려는데, 어떤 방법들이 있을까요? 텍스트로 새 영상을 만드는 방식과 기존 HTML을 영상화하는 방식의 차이를 알려주세요.

2. 기획하기: 자동화 방식으로 좁히기

이번 실습은 기존 카드뉴스를 MP4로 바꾸는 쪽입니다. 새 영상을 상상해서 만드는 게 아니라, 있는 화면을 촬영하는 흐름으로 좁힙니다.

이번에는 02-카드뉴스.html을 30초 내외 SNS 영상으로 만들려고 합니다. 자동화 스크립트 방식으로 진행한다면 어떤 도구가 좋고, 설치부터 실행까지 어떤 흐름이 필요한지 단계별로 정리해 주세요.

AI가 Playwright, Remotion, FFmpeg, MoviePy 같은 선택지를 말할 수 있습니다. 가장 빠른 길은 브라우저 자동화와 녹화 흐름입니다. 제가 여기서는 Playwright 쪽으로 좁혀갑니다.

3. 만들기: 스크립트 작성과 실행

실제 파일 생성을 요청합니다. 대기 시간과 출력 파일명을 분명히 말하세요. "카드 1장마다 3초"처럼 숫자로 박아두면 결과가 덜 흔들립니다.

Playwright로 브라우저를 자동 제어해서 02-카드뉴스.html을 영상으로 만들려고 합니다. 카드 1장마다 3초씩 머무르며 스크롤하고, 결과 파일은 output.mp4로 저장하도록 스크립트를 작성하고 실행하세요.

설치 허락 요청이 뜨면 확인하고 진행합니다. Node.js 버전이 낮으면 먼저 버전을 맞춰야 할 수 있어요.

4. 검증하기: 영상 열어 보기

MP4 파일은 만들어졌다는 사실보다 실제 재생이 중요합니다. 검은 화면이면 파일이 있어도 실패입니다.

output.mp4를 검증하려고 합니다. 길이가 20~40초 범위인지, 카드가 순서대로 보이는지, 검은 화면이나 끊김이 없는지, 마지막 카드까지 녹화됐는지 확인해 주세요.

5. 개선하기: 시간만 조정

영상이 너무 빠르면 카드별 머무는 시간만 바꿉니다. 전체 스크립트를 다시 쓰게 하지 마세요.

각 카드가 너무 빨리 지나가서 3초를 5초로 늘리려고 합니다. 대기 시간만 수정하고, 카드 순서와 화면 크기, 출력 파일명은 그대로 유지하세요.

영상 작업은 전체 재생성을 하더라도 조건을 고정하는 게 중요합니다. 바꿀 값 하나만 정확히 말하면 됩니다.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습10-리모션영상/입니다. 여기서 output.mp4를 실제로 열어보는 것까지가 한 사이클이에요.

실습10-리모션영상/
├── 02-카드뉴스.html
├── output.mp4        # 20~40초 내외 영상
└── README.md

README.md에는 사용한 입력 파일, 영상 길이, 카드당 머무는 시간, 확인한 문제를 적습니다. 영상 길이가 너무 길거나 짧으면 다음 수정에서 카드당 초 단위만 조정하세요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 8: 포트폴리오 기획 — Ch 04로 넘어가 가상 인물 자료를 웹사이트 기획과 프로토타입으로 바꿉니다.

Ch 03에서는 콘텐츠 하나가 여러 형식으로 바뀌었습니다. 다음부터는 웹사이트를 기획하고, 수정하고, 배포까지 이어갑니다.

🎯 이 클립에서 만드는 것

Ch 04부터는 웹사이트입니다. 이번 클립에서는 가상 인물 김지수 UX/UI Designer의 리서치 자료와 이미지 15장을 바탕으로 포트폴리오 웹사이트를 기획하고 1차 프로토타입을 만듭니다.

처음부터 예쁜 웹사이트를 완성하려고 하지 않습니다. 먼저 자료를 읽고, 사이트 구성 기획서를 만든 뒤, 그 기획서를 기준으로 portfolio.html을 생성해요. 저는 이 순서를 꼭 지킵니다.

50-my-work/Part03-체험하기/실습11-포트폴리오기획/
├── 00-포트폴리오-리서치.md
├── images/
├── 01-포트폴리오-구성기획.md
├── portfolio.html
└── README.md

이번 결과물은 완성품이 아니라 1차본입니다. 색상, 여백, 타이포, 애니메이션 같은 세부 다듬기는 다음 Clip 9에서 진행합니다. 오늘은 "실물이 눈앞에 생기는 것"이 목표예요.

💡 핵심 개념

웹사이트는 기획서부터 시작합니다

포트폴리오 사이트를 만들 때 바로 HTML부터 시작하면, 이름은 들어갔는데 어떤 사람인지 보이지 않는 페이지가 되기 쉽습니다. 자기소개서를 쓰기 전에 이력과 강점을 정리하잖아요? 웹사이트도 구조를 먼저 잡아야 합니다.

이번 클립의 자료에는 가상 인물 프로필, 레퍼런스 15개 분석, 디자인 트렌드, 이미지가 들어 있습니다. 여러분이 할 일은 이 자료를 AI에게 읽히고 어떤 섹션으로 보여줄지 결정하는 거예요.

구성은 보통 Hero, Work, About, Contact처럼 시작합니다. 중요한 것은 김지수라는 인물의 강점과 프로젝트가 페이지 안에서 자연스럽게 연결되는지입니다.

📁 시작 전 — 자료 셋업

이 클립은 가상 인물 김지수의 포트폴리오 자료를 사용합니다. 워크스페이스 안 30-templates/portfolio-template/에 미리 들어 있어요. 작업 폴더로 옮겨두면 바로 시작할 수 있어요.

한 줄 시작 — 셋업 + 스킬 실행 (클로드코드에 입력)

~/Desktop/bptc-cc/30-templates/portfolio-template/ 안의 자료(00-포트폴리오-리서치.md + images/)를 ~/Desktop/bptc-cc/50-my-work/Part03-체험하기/실습11-포트폴리오기획/ 폴더로 복사하고, 그 작업 폴더로 진입해 주세요. 그 다음 ~/Desktop/bptc-cc/progress.json의 current_clip을 "Part03-Clip8-포트폴리오기획"으로 갱신하고, part03-experience 스킬을 실행해서 Clip 8 (포트폴리오 기획) 강의 가이드를 시작해 주세요. 이전 Clip 5~7 진행 상태는 무시하고 Clip 8부터 진행합니다.

→ 클로드코드가 자동으로:

1. mkdir -p 50-my-work/Part03-체험하기/실습11-포트폴리오기획/ — 폴더 생성
2. cp -r 30-templates/portfolio-template/* 실습11-포트폴리오기획/ — 김지수 자료 복사
3. 작업 폴더 진입 (cd)
4. progress.json 갱신 — current_clip = "Part03-Clip8-포트폴리오기획"
5. part03-experience 스킬 자동 실행 → Clip 8 가이드 시작

스킬이 Clip 8 reference(clip08-portfolio-plan.md)를 읽고 던지기·기획·만들기·검증·개선 5단계를 순서대로 안내합니다. 학생은 영상을 보면서 스킬 안내에 따라 진행하면 돼요.

이전 Clip 5~7 진행 여부와 무관하게 작동해요. Clip 8은 김지수 자료만 필요하고, 이전 클립 결과물(리서치·카드뉴스·영상)과 분리된 실습입니다.

셋업 완료 체크

작업 폴더 안에 다음이 있으면 준비 완료:

• 00-포트폴리오-리서치.md (김지수 프로필 + 레퍼런스 15개 + 디자인 트렌드)
• images/ (이미지 15장)

자료가 안 보이면 강사에게 "30-templates 폴더에 portfolio-template 있나요?" 확인 요청.

🚶 진행 흐름

1. 던지기: 사이트 제작 흐름 묻기

작업 폴더에 자료가 셋업된 상황에서, 웹사이트 제작 흐름을 먼저 묻습니다. 바로 HTML 만들자고 하면 AI가 즉흥적으로 꾸밀 수 있어요.

방금 셋업한 실습11-포트폴리오기획/ 폴더에 김지수 리서치(00-포트폴리오-리서치.md)와 이미지 15장(images/)이 있습니다. 이 자료로 포트폴리오 사이트를 만들려면 어떤 순서로 진행하면 좋을까요? 기획서 작성부터 HTML 생성까지 흐름을 알려주세요.

2. 기획하기: 구조와 무드 고르기

리서치 자료를 기준으로 사이트 구조 옵션을 받습니다. 여기서 무드까지 같이 고르면 다음 단계가 훨씬 편해집니다.

00-포트폴리오-리서치.md를 읽고 김지수 UX/UI Designer에게 맞는 포트폴리오 구조를 기획하려고 합니다. 섹션 구성, 레퍼런스 무드, 디자인 방향을 2~3개 옵션으로 제안해 주세요.

여기서 선택하는 것은 단순 취향이 아닙니다. 어떤 무드가 인물의 작업과 가장 잘 맞는지 고르는 일이에요.

3. 만들기: 기획서와 HTML 생성

먼저 기획서를 만들고, 그다음 HTML을 만듭니다. 제가 보기엔 이 순서가 포트폴리오 품질을 가장 크게 가릅니다.

선택한 구조와 디자인 방향으로 01-포트폴리오-구성기획.md를 먼저 작성하려고 합니다. 각 섹션의 목적, 들어갈 문구 샘플, 사용할 이미지 방향을 포함하세요.

01-포트폴리오-구성기획.md를 기준으로 portfolio.html 1차 프로토타입을 만들려고 합니다. 단일 HTML, 인라인 CSS, 바닐라 JS, 반응형 구조로 구현하고 images 폴더의 이미지를 적절히 배치하세요.

4. 검증하기: 1차본 확인

브라우저에서 열어 섹션과 내용이 맞는지 봅니다. 파일이 만들어졌다고 끝이 아니죠. 김지수 정보가 제대로 들어갔는지 봐야 합니다.

portfolio.html을 검증하려고 합니다. Hero, Work, About, Contact 섹션이 있는지, 김지수 정보가 반영됐는지, 이미지가 깨지지 않는지, 모바일 폭에서 읽히는지 점검해 주세요.

5. 개선하기: 가벼운 문구만 수정

본격 디자인 수정은 다음 클립에서 하므로, 여기서는 작은 수정만 합니다. 1차본에서 너무 욕심내면 다음 클립의 역할이 흐려져요.

Hero 타이틀의 한 줄 메시지만 더 선명하게 바꾸려고 합니다. 김지수의 UX/UI 강점이 드러나게 문장만 수정하고, 레이아웃과 다른 섹션은 그대로 유지하세요.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습11-포트폴리오기획/입니다. 리서치, 기획서, HTML이 한 폴더에서 이어져야 합니다.

실습11-포트폴리오기획/
├── 00-포트폴리오-리서치.md
├── images/
├── 01-포트폴리오-구성기획.md
├── portfolio.html
└── README.md

README.md에는 선택한 구조, 참고한 무드, 1차 프로토타입에서 마음에 드는 점과 아쉬운 점을 적습니다. 다음 클립에서는 이 아쉬운 점을 디자인 수정 목록으로 바꿔요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 9: 포트폴리오 수정 — 1차 portfolio.html을 디자인 참고 자료와 대화로 다듬어 최종본으로 만듭니다.

이번 클립은 뼈대를 세우는 단계였습니다. 다음 클립에서 색상, 여백, 타이포, 애니메이션, 반응형을 차례로 다듬어봅니다.

🎯 이 클립에서 만드는 것

Clip 8에서 만든 1차 portfolio.html은 뼈대만 잡힌 상태예요. 이번에는 getdesign.md에서 좋아하는 사이트의 디자인을 .md로 받아 — 그걸 참고하면서 내 portfolio의 디자인뿐 아니라 구조까지 새롭게 다듬습니다.

핵심: 참고할 사이트 1~2개를 명확히 골라서, 그 디자인 .md를 클로드코드에 던지면서 변경 요청. "예쁘게 해줘"가 아니라 "이 사이트 톤으로 이 부분을 바꿔줘"가 됩니다.

50-my-work/Part03-체험하기/실습12-포트폴리오수정/
├── portfolio.html              # 개선 대상 (Clip 8에서 가져옴)
├── 00-포트폴리오-리서치.md     # 그대로
├── 01-포트폴리오-구성기획.md   # 그대로
├── 02-design-references.md     # ★ getdesign.md에서 받은 디자인 참고
├── images/                     # 그대로
└── README.md

💡 핵심 개념

디자인 수정 = 참고 + 구체화

"예쁘게 만들어줘"만 던지면 AI가 즉흥적으로 색·여백을 바꿉니다. 결과는 일관성 없는 사이트가 되기 쉬워요. 좋은 수정은 명확한 참고 자료 + 구체적 변경 범위 두 가지로 만들어집니다.

getdesign.md — 사이트 디자인을 .md로

getdesign.md는 좋아하는 사이트 URL을 입력하면 그 사이트의 디자인 시스템(색·타이포·여백·구조·인터랙션)을 마크다운으로 추출해 주는 서비스예요. 받은 .md를 클로드코드에 던지면 AI가 참고 디자인의 패턴을 정확히 이해한 상태로 내 portfolio를 수정합니다. "Stripe처럼" 같은 추상적 요청보다 훨씬 정확해요.

디자인뿐 아니라 구조도

Clip 8 1차본의 섹션 구성을 그대로 두지 마세요. 참고 사이트에서 좋은 구조 패턴이 있으면 — 섹션 순서·블록 종류·내비게이션 같은 구조 자체를 바꾸는 것도 OK. 이번 클립은 "디자인만 바꾸기"가 아니라 "사이트 전체를 다시 다듬기"입니다.

🛠️ 시작 전 — 자료 셋업

1단계. Clip 8 결과물 가져오기 (클로드코드에 입력)

~/Desktop/bptc-cc/50-my-work/Part03-체험하기/실습11-포트폴리오기획/ 안의 portfolio.html, 00-포트폴리오-리서치.md, 01-포트폴리오-구성기획.md, images/ 를 ~/Desktop/bptc-cc/50-my-work/Part03-체험하기/실습12-포트폴리오수정/ 폴더로 복사하고, 그 작업 폴더로 진입해 주세요. 셋업이 끝나면 작업 폴더 파일 목록을 한 줄로 보고만 해 주세요. 실습은 아직 시작하지 마세요.

2단계. getdesign.md에서 디자인 참고 .md 받기 (브라우저)

1. https://getdesign.md/ 접속
2. 참고할 사이트 URL 1~2개 입력 (예: Stripe / Linear / Vercel / Notion / Apple / 본인이 좋아하는 사이트)
3. 결과 .md를 복사하거나 다운로드
4. 작업 폴더(실습12-포트폴리오수정/)에 **02-design-references.md**로 저장

참고 사이트는 정적 사이트 위주로 고르세요. 너무 동적이거나 보호된 사이트는 추출이 잘 안 될 수 있어요.

셋업 완료 체크

작업 폴더 안에:

• portfolio.html, 00-포트폴리오-리서치.md, 01-포트폴리오-구성기획.md, images/ (Clip 8에서 복사)
• 02-design-references.md (getdesign.md 결과)

다 있으면 진행 흐름으로.

🚶 진행 흐름

1. 던지기 — 참고 디자인으로 가능한 변경 묻기

02-design-references.md에 [참고 사이트명]의 디자인 시스템이 정리돼 있어요. 이 디자인을 portfolio.html에 어떻게 반영할 수 있을지 — 색·타이포·여백 같은 디자인뿐 아니라 섹션 구성·내비게이션·블록 구조까지 어떤 변경이 가능한지 옵션을 펼쳐 주세요.

2. 구체화 — 적용할 변경 범위 정하기

제안받은 변경 중 다음 3가지를 적용하려고 합니다:
- (예시) 색 팔레트를 다크 미니멀로 전환
- (예시) Hero를 풀스크린 + 큰 타이포로 재구성
- (예시) Work 섹션을 그리드 → 케이스 카드 슬라이더로 변경

먼저 02-design-references.md를 다시 읽고, 위 변경이 일관되게 적용되도록 디자인 토큰(색·폰트·여백·라운드·섀도우 등)을 정리해 주세요. 그 다음 portfolio.html에 어떻게 적용할지 작업 계획을 한 번 보여주세요.

3. 만들기 — 디자인·구조 적용

정리된 디자인 토큰과 작업 계획대로 portfolio.html을 수정해 주세요. 김지수의 정보(이름·프로젝트·자기소개)는 그대로 유지하고, 섹션 구성·디자인만 변경합니다. 인라인 CSS, 바닐라 JS, 반응형 구조는 유지하세요.

4. 검증 — 일관성·정보·반응형

수정된 portfolio.html을 검증해 주세요:
1) 02-design-references.md의 참고 디자인이 일관되게 반영됐나
2) 김지수 정보(이름·프로젝트 4개·자기소개·이미지)가 빠지지 않았나
3) 데스크톱·태블릿·모바일(375px)에서 깨지지 않나
4) 인라인 CSS · 바닐라 JS 구조가 유지됐나

5. 개선 — 한 부분만 부분 수정

Hero 섹션의 한 줄 메시지가 너무 작아 보여요. 폰트 사이즈만 더 키우고 자간을 좁혀 주세요. 다른 섹션의 색·여백은 그대로 유지합니다.

📦 결과물

저장 위치: 50-my-work/Part03-체험하기/실습12-포트폴리오수정/

실습12-포트폴리오수정/
├── portfolio.html             # 디자인·구조 개선된 최종본
├── 00-포트폴리오-리서치.md
├── 01-포트폴리오-구성기획.md
├── 02-design-references.md    # getdesign.md 결과
├── images/
└── README.md

README.md에 다음을 적습니다:

• 참고 사이트 1~2개 (URL)
• 적용한 디자인 변경 3가지
• 적용한 구조 변경 (있다면)
• Before/After 한 줄 (어디가 어떻게 달라졌나)

🆘 자주 막히는 포인트

🔗 다음 클립

→ Part 3 / Clip 10: Vercel 배포 — 완성된 portfolio.html을 Vercel에 올려 공개 URL을 받습니다.

이번 클립에서 만든 portfolio.html은 이제 어느 사이트에 올려도 부끄럽지 않은 수준이에요. 다음은 진짜 인터넷에 올려보는 시간.

🎯 이 클립에서 만드는 것

file:///Users/.../portfolio-final.html 주소를 친구에게 보내면 열릴까요? 안 열립니다. 내 컴퓨터 안에 있는 파일이니까요. 이번 클립에서는 Clip 9에서 만든 portfolio-final.html을 Vercel에 배포해 공개 URL을 만듭니다.

로컬에서만 열리던 주소를 다른 사람도 접속할 수 있는 https://프로젝트명.vercel.app 형태로 바꾸는 단계입니다. 배포는 웹사이트를 세상에 올리는 마지막 문턱이에요. 파일을 만드는 것과 달리 로그인, 인증, 프로젝트 이름, 재배포 같은 절차가 들어갑니다.

50-my-work/Part03-체험하기/실습13-Vercel배포/
├── portfolio-final.html
├── index.html
└── README.md

Vercel은 index.html을 기본 진입 파일로 찾습니다. 그래서 필요하면 portfolio-final.html을 index.html로 복사하거나 이름을 바꿔 배포합니다. 여러분이 여기서 받는 최종 결과는 파일이 아니라 진짜 주소입니다.

💡 핵심 개념

배포는 "내 컴퓨터 파일"을 "인터넷 주소"로 바꾸는 일입니다

브라우저에서 로컬 HTML을 열면 내 컴퓨터에서는 잘 보입니다. 하지만 그 주소를 친구에게 보내면 열리지 않아요. 파일이 내 컴퓨터 안에만 있기 때문입니다.

배포는 이 파일을 호스팅 서비스에 올리고, 접속 가능한 주소를 받는 과정입니다. 집에서 만든 포스터를 동네 게시판에 붙여 다른 사람이 보게 만드는 것과 비슷해요.

이번 클립에서는 Vercel을 기준으로 진행합니다. 중요한 것은 CLI 명령을 외우는 게 아닙니다. 저는 AI에게 맡길 부분과 사람이 직접 해야 할 부분을 나누는 걸 더 중요하게 봅니다. 이메일 인증처럼 사람 확인이 필요한 단계에서는 직접 확인해야 해요.

🚶 진행 흐름

1. 던지기: 배포 가능 여부 묻기

먼저 현재 HTML을 인터넷에 올릴 수 있는지 묻습니다. 바로 배포 명령부터 치지 않습니다. 가능한 선택지를 먼저 펼쳐요.

이 HTML 파일 portfolio-final.html을 인터넷에 공개하려는데, 어떤 방식으로 배포할 수 있을까요? Vercel, Netlify, GitHub Pages 같은 선택지를 비교하고 가장 빠른 흐름을 알려주세요.

2. 기획하기: Vercel 흐름 정하기

가장 빠른 방법으로 좁히고, 사람이 해야 할 일과 AI가 할 일을 나눕니다. 이걸 해두면 Magic Link 같은 단계에서 덜 당황합니다.

이번에는 Vercel로 배포하려고 합니다. CLI 설치, index.html 준비, 인증, 배포, URL 확인까지 단계별 흐름을 정리하고, 제가 직접 해야 하는 부분과 자동으로 처리할 부분을 구분해 주세요.

가입이나 인증 단계에서는 브라우저와 이메일 확인이 필요할 수 있습니다. 이 부분은 여러분이 직접 처리합니다.

3. 만들기: 배포 실행

실제 배포를 진행합니다. 인증이 필요한 지점에서는 멈추게 합니다. 제가 요청문에 "인증 단계에서는 멈추고 알려줘"를 넣는 이유가 이거예요.

정리한 흐름대로 Vercel 배포를 진행하려고 합니다. 필요한 CLI 설치와 파일 준비를 진행하고, Magic Link나 브라우저 인증이 필요한 단계에서는 멈춘 뒤 제가 할 일을 알려주세요.

배포가 완료되면 URL을 받습니다. URL은 README.md에 남겨야 합니다. 나중에 찾으려고 하면 은근히 헷갈려요.

4. 검증하기: 공개 URL 열어 보기

배포 후에는 URL이 열리는지 반드시 확인합니다. 데스크톱에서만 보지 말고 스마트폰에서도 열어보면 좋습니다.

발급된 Vercel URL을 검증하려고 합니다. 데스크톱 브라우저에서 열리는지, 스마트폰에서도 표시되는지, 이미지와 CSS가 깨지지 않는지 확인할 체크리스트를 만들어 주세요.

5. 개선하기: 이름이나 진입 파일만 수정

문제가 있으면 작은 범위부터 수정합니다. 배포 문제는 대부분 파일명, 경로, 프로젝트 이름처럼 작은 데서 납니다.

배포 후 404가 떠서 진입 파일을 조정하려고 합니다. portfolio-final.html을 index.html로 맞추고 재배포하되, HTML 내용과 디자인은 그대로 유지하세요.

프로젝트 이름을 바꾸고 싶을 때도 이름만 지정합니다. 사이트 내용은 그대로 둔다는 말을 같이 넣어야 안전해요.

프로젝트 이름을 jisu-portfolio-2026으로 바꿔 재배포하려고 합니다. 이름 설정만 조정하고 사이트 내용은 그대로 유지하세요.

📦 결과물

저장 위치는 50-my-work/Part03-체험하기/실습13-Vercel배포/입니다. 배포용 index.html과 원본 portfolio-final.html을 구분해두면 나중에 덜 헷갈립니다.

실습13-Vercel배포/
├── portfolio-final.html
├── index.html
└── README.md

README.md에는 공개 URL, 배포한 파일, 확인한 기기, 막혔던 지점을 적습니다. 최종 결과는 파일 하나가 아니라 다른 사람이 접속할 수 있는 주소예요.

🆘 자주 막히는 포인트

🔗 다음 클립

→ 보조 레퍼런스: 대화 패턴 5단계 — Part 3에서 반복한 대화 흐름을 다시 정리합니다.

Part 3은 여기서 마무리됩니다. 데이터, 콘텐츠, 웹사이트, 배포까지 모두 같은 5단계 대화로 이어졌다는 점을 확인하면 됩니다.

🎯 이 클립에서 만드는 것

Part 3까지는 클로드코드에게 일을 잘 맡기는 법을 연습했죠? Part 4부터는 한 단계 더 갑니다. 이번에는 클로드코드에 새 기능을 붙여요. 스마트폰에 앱을 설치하면 갑자기 할 수 있는 일이 늘어나잖아요? 클로드코드에서도 비슷한 일이 벌어집니다.

이번 클립에서 여러분은 GPTaku 플러그인 묶음에 들어가고, 앞으로 쓸 docs-guide, kkirikkiri, vibe-sunsang 같은 도구를 설치합니다. 저는 이 클립을 "장비 창 여는 시간"이라고 봐요. 아직 멋진 결과물을 만드는 건 아니지만, 다음 세 클립에서 쓸 도구함을 여기서 열어두는 거예요.

이 클립의 결과물은 README.md 하나입니다. 설치한 플러그인 목록, 설치한 날의 모델·모드, 그리고 내가 왜 이 플러그인을 깔았는지를 적어둡니다. 여러분이 나중에 "내가 뭘 설치했더라?" 하고 돌아볼 때 꽤 도움이 돼요.

💡 핵심 개념

플러그인은 어렵게 말하면 확장 패키지인데, 저는 그냥 "클로드코드용 앱"이라고 설명합니다. 앱스토어에서 앱을 내려받으면 카메라, 메모, 지도처럼 기능이 늘어나죠. 플러그인도 명령, 스킬, 에이전트, 설정을 한 묶음으로 받아와서 클로드코드가 더 많은 일을 하게 해줍니다.

여기서 중요한 건 "많이 설치하기"가 아닙니다. 여러분에게 필요한 도구를 믿을 만한 출처에서 설치하고, 설치 뒤에 실제로 호출되는지 확인하는 거예요. 솔직히 플러그인은 강력한 만큼 조심해야 합니다. 내 컴퓨터에서 실행되는 기능이니까요. 그래서 저는 수업에서 검증된 GPTaku 묶음부터 시작합니다.

오늘 설치 흐름은 단순합니다. 플러그인 묶음을 추가하고, 설치됐는지 확인하고, README에 남깁니다. 이 세 가지만 해도 다음 클립부터 훨씬 편해져요.

🛠️ 시작 전 — 자료 셋업

먼저 실습 폴더를 만들고 그 안에서 시작합니다. 클로드코드에 아래 한 줄을 그대로 넣어 주세요.

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습14-플러그인설치/ 폴더를 만들고, 그 작업 폴더로 진입해 주세요. 셋업이 끝나면 위치를 한 줄로 보고만 해 주세요. 실습은 아직 시작하지 마세요.

위치 확인이 끝나면 플러그인 설치를 진행합니다. 이번 클립의 핵심 명령은 이거예요.

/plugin install gptaku-plugins

화면에서 권한 확인이나 설치 확인을 물으면 강의 화면을 보면서 진행하면 됩니다. 만약 TUI가 열리면 Marketplaces, Discover, Installed 탭을 차례대로 보세요. 저는 설치 직후에 바로 한 번씩 호출해보는 편입니다. "깔렸다"와 "실제로 동작한다"는 다른 얘기잖아요?

/docs-guide
/kkirikkiri
/vibe-sunsang

응답이 뜨면 준비 완료입니다.

🚶 진행 흐름

1. 플러그인이 뭔지 먼저 물어보기

설치 전에 개념을 짧게 확인합니다. 그냥 따라 치면 금방 잊히는데, 한 번 물어보면 기억이 남아요.

클로드코드 플러그인이 뭔지 초보자 기준으로 설명해 주세요. 슬래시 명령, 스킬, 에이전트가 각각 어떻게 다른지도 짧게 비교해 주세요.

2. GPTaku 플러그인 설치하기

이제 설치합니다. 여러분은 아래 명령을 실행하고, 클로드코드가 보여주는 안내를 따라가면 돼요.

/plugin install gptaku-plugins

설치 중간에 출처나 권한을 확인하는 화면이 나오면 그냥 넘기지 마세요. 어떤 묶음을 설치하는지 한 번 읽어봅니다. 저는 이 습관을 꽤 중요하게 봐요.

3. 설치된 항목 확인하기

설치가 끝나면 목록을 확인합니다. docs-guide, kkirikkiri, vibe-sunsang이 보이면 이번 Part 4의 기본 도구가 들어온 상태예요.

방금 설치한 GPTaku 플러그인 중 Part 4에서 사용할 플러그인 목록을 확인해 주세요. docs-guide, kkirikkiri, vibe-sunsang이 설치되어 있는지 봐 주세요.

4. 호출 테스트하기

설치 목록에 있는 것만으로는 부족합니다. 실제로 짧게 호출해봅니다.

/docs-guide vercel 한 줄로 뭐 하는 도구인지 알려줘

/kkirikkiri 리서치 팀 만들어줘

여기서 완벽한 답을 받을 필요는 없습니다. 명령이 인식되는지 확인하는 게 목적이에요.

5. README 작성하기

마지막으로 설치 기록을 남깁니다. 여러분이 나중에 다른 컴퓨터에서 다시 세팅할 때 이 파일이 작은 체크리스트가 돼요.

README.md를 작성해 주세요. 설치한 플러그인 목록, 각 플러그인을 한 줄로 설명한 내용, 현재 사용한 모델·모드, 설치 중 막힌 지점이 있었는지 포함해 주세요.

📦 결과물

저장 위치는 50-my-work/Part04-강화하기/실습14-플러그인설치/입니다. 이번 결과물은 작지만, 다음 클립 세 개의 출발점이에요.

실습14-플러그인설치/
└── README.md

README.md에는 다음 항목이 들어가면 좋습니다.

• 설치한 플러그인 목록: docs-guide, kkirikkiri, vibe-sunsang
• 설치한 명령: /plugin install gptaku-plugins
• 현재 모델·모드
• 각 플러그인을 어디에 쓸지 한 줄 메모
• 설치 중 막힌 점과 해결한 방법

여러분이 이 파일을 남겨두면 Part 4 끝에서 "내 도구함이 어떻게 늘어났는지"가 눈에 보입니다. 저는 이런 작은 기록이 나중에 꽤 큰 차이를 만든다고 봅니다.

🆘 자주 막히는 포인트

막히는 데는 보통 정해져 있어요. 아래 표에서 증상부터 찾아보세요.

여전히 이상하면 설치 명령, 에러 문장, 현재 화면을 그대로 붙여서 도움을 요청하면 됩니다.

🔗 다음 클립

→ Part 4 / Clip 2: docs-guide로 Vercel 공식 문서 확인 — 방금 설치한 docs-guide로 Vercel을 다시 파헤칩니다.

여러분은 Part 3에서 이미 Vercel 배포를 했죠. 다음 클립에서는 "내가 그때 누른 버튼들이 사실 무슨 뜻이었는지"를 공식 문서로 다시 열어봅니다.

🎯 이 클립에서 만드는 것

어제 Part 3 Clip 10에서 여러분은 포트폴리오를 Vercel에 올렸습니다. 그런데 솔직히 이런 생각 들 수 있어요. "배포는 됐는데, 내가 정확히 뭘 한 거지?" 버튼 몇 개 누르고 URL을 받았는데, 그 뒤에 자동 배포, 도메인, 환경변수 같은 말이 슬쩍 지나갔잖아요?

이번 클립에서는 docs-guide로 Vercel 공식 문서를 열어보고, 내가 어제 한 일을 다섯 영역으로 다시 정리합니다. 저는 이 과정을 좋아합니다. 손으로 먼저 해보고, 다음날 문서로 구조를 이해하면 머릿속에 훨씬 오래 남거든요.

결과물은 세 개입니다. vercel-학습노트.md, vercel-시너지-아이디어.md, README.md. 여러분이 앞으로 새로운 도구를 만날 때도 이 방식 그대로 쓰면 돼요. 먼저 공식 문서로 묻고, 내 작업과 연결하고, 다음에 써먹을 아이디어를 적어둡니다.

💡 핵심 개념

docs-guide는 "아는 척하는 답"을 줄이기 위한 도구입니다. 일반 대화에서는 모델이 기억하는 정보로 설명할 수 있지만, 문서가 바뀌는 서비스에서는 오래된 답이 섞일 수 있어요. Vercel처럼 기능이 빠르게 변하는 서비스는 특히 그렇습니다.

저는 docs-guide를 "도서관 사서가 옆에서 공식 책장을 바로 찾아주는 느낌"으로 봅니다. 여러분이 Vercel 환경변수 어떻게 써?라고 물으면, 그냥 감으로 설명하는 게 아니라 공식 문서를 확인한 뒤 답을 줍니다.

이번에는 Vercel을 다섯 영역으로 나눠 봅니다.

핵심은 명령어 암기가 아닙니다. 여러분이 이미 해본 행동에 이름을 붙이는 거예요. "아, 내가 한 건 Deployment였구나", "도메인은 URL의 문패 같은 거구나" 하고 연결되면 다음부터 덜 낯설어집니다.

🛠️ 시작 전 — 자료 셋업

먼저 실습 폴더를 준비합니다. 클로드코드에 아래 한 줄을 그대로 넣어 주세요.

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습15-공식문서확인/ 폴더를 만들고, 그 작업 폴더로 진입해 주세요. 셋업이 끝나면 위치를 한 줄로 보고만 해 주세요. 실습은 아직 시작하지 마세요.

추가로 브라우저에서 https://vercel.com에 로그인되어 있는지 확인해 주세요. Part 3 Clip 10에서 만든 프로젝트가 보이면 더 좋습니다. 안 보여도 괜찮아요. 오늘은 배포를 새로 하는 시간이 아니라, 공식 문서로 이해하는 시간이니까요.

셋업이 끝나면 저는 보통 이렇게 시작합니다.

/docs-guide vercel Vercel을 처음 배포해본 학생 기준으로 배포, 도메인, 환경변수, Edge, Analytics 5개 영역으로 설명해 주세요. 공식 문서 출처도 함께 알려주세요.

답변을 받은 뒤에는 바로 복사하지 말고, 여러분 말로 다시 줄여 적어야 합니다. 문서 답변은 재료고, 오늘 결과물은 여러분의 학습 노트예요.

🚶 진행 흐름

1. 어제 한 배포를 다시 설명받기

Part 3 Clip 10을 떠올리면서 시작합니다. "내가 한 게 뭐였지?"라는 질문을 그대로 던져도 됩니다.

/docs-guide vercel 어제 portfolio HTML을 Vercel에 배포한 학생 입장에서, 제가 실제로 한 일이 Vercel의 어떤 개념과 연결되는지 설명해 주세요.

여기서 받은 답을 vercel-학습노트.md의 첫 부분에 정리합니다.

2. 다섯 영역으로 노트 만들기

이제 배포, 도메인, 환경변수, Edge, Analytics를 나눠 정리합니다. 한꺼번에 깊게 파기보다, 각 영역을 "내 말 한 줄 + 문서에서 확인한 내용"으로 적어보세요.

/docs-guide vercel 배포, 도메인, 환경변수, Edge, Analytics를 각각 초보자 눈높이로 설명하고, 각 영역에서 클로드코드로 물어보면 좋은 질문 예시를 2개씩 주세요.

3. 클로드코드와 Vercel이 만나는 지점 찾기

이 단계가 재미있습니다. Vercel은 배포 서비스지만, 클로드코드와 같이 쓰면 작업 방식이 달라져요.

/docs-guide vercel Claude Code와 Vercel을 함께 쓸 때 학생이 발견할 수 있는 시너지 5가지를 자동 배포, Preview, 환경변수 관리, Analytics, 자연어 워크플로우 중심으로 정리해 주세요.

받은 내용은 vercel-시너지-아이디어.md에 적습니다. 저는 여기서 "내가 다음 프로젝트에서 바로 써볼 것"을 꼭 하나 고릅니다.

4. 일반 답변과 공식 문서 답변 비교하기

일반 질문도 한 번 해보면 차이가 보입니다.

Vercel을 초보자에게 설명해 주세요. 공식 문서 확인 없이, 기억나는 범위에서만 답해 주세요.

그 다음 docs-guide 답변과 비교합니다. 출처가 있는지, 최신 기능 이름이 정확한지, 너무 뭉뚱그려 말하지 않는지 보면 돼요.

5. README로 정리하기

마지막은 기록입니다. 여러분이 실제로 배운 영역, 가장 놀란 시너지, 다음 프로젝트에서 해볼 일을 남깁니다.

README.md를 작성해 주세요. 이번 실습에서 만든 vercel-학습노트.md, vercel-시너지-아이디어.md를 요약하고, 내가 이해한 Vercel 5개 영역과 다음에 써볼 아이디어를 포함해 주세요.

📦 결과물

저장 위치는 50-my-work/Part04-강화하기/실습15-공식문서확인/입니다.

실습15-공식문서확인/
├── vercel-학습노트.md
├── vercel-시너지-아이디어.md
└── README.md

vercel-학습노트.md에는 Vercel 5개 영역을 정리합니다.

• 배포: 어제 포트폴리오를 공개 URL로 만든 일
• 도메인: 주소를 붙이고 관리하는 일
• 환경변수: API 키처럼 감춰야 하는 값을 관리하는 일
• Edge: 사용자 가까운 곳에서 코드를 실행하는 일
• Analytics: 접속과 성능을 확인하는 일

vercel-시너지-아이디어.md에는 학생이 발견한 5가지를 넣습니다.

• 자동 배포: 변경하면 다시 올리는 흐름
• Preview: 수정본을 먼저 확인하는 주소
• 환경변수 관리: 비밀값을 코드 밖에 두는 방식
• Analytics: 공개 후 반응 확인
• 자연어 워크플로우: 클로드코드에게 배포 점검과 수정 요청

README.md에는 오늘 만든 파일 목록, docs-guide로 확인한 출처, 다음 프로젝트에서 써볼 한 가지를 적으면 됩니다.

🆘 자주 막히는 포인트

막히는 데는 보통 정해져 있어요. Vercel은 익숙해질 때까지 용어가 살짝 많습니다.

여전히 헷갈리면 "어제 내가 한 배포 절차에 맞춰 다시 설명해줘"라고 되돌리면 됩니다.

🔗 다음 클립

→ Part 4 / Clip 3: kkirikkiri로 AI 팀 구성 — 이제 혼자 묻는 단계를 넘어, 자연어 한 문장으로 AI 팀을 꾸려봅니다.

오늘은 Vercel 공식 문서로 하나의 도구를 깊게 봤습니다. 다음은 여러분 주제를 놓고 여러 역할의 AI가 동시에 의견을 내는 장면으로 넘어가요.

🎯 이 클립에서 만드는 것

지금까지는 여러분이 AI 한 명에게 질문했습니다. 그런데 실제 회사 일은 혼자 보는 것보다 여러 사람이 나눠 보는 게 낫잖아요? 리서처는 시장을 보고, 기획자는 실행안을 보고, 리뷰어는 빠진 부분을 봅니다. 이번 클립에서는 kkirikkiri로 Agent Teams를 구성하고, 바로 역할별 작업까지 맡깁니다.

kkirikkiri는 "Agent Teams 만들어줘"라는 요청을 받아서 필요한 역할을 묻고, 팀을 구성하고, 그 팀이 실제 작업을 수행하도록 이어주는 플러그인입니다. 저는 이걸 처음 쓸 때 제일 좋았던 점이 "역할을 매번 직접 짜지 않아도 된다"는 거였어요. 다만 오늘은 팀을 만드는 데서 멈추지 않습니다. Agent Teams를 만들고, 각 팀원에게 일을 나눠 맡기고, 결과를 파일로 남기는 것까지가 실습입니다.

주제는 자유입니다. "BPTC 항만 트렌드 리서치 Agent Teams"도 좋고, "내 부서 자동화 Agent Teams"도 좋아요. 여러분 업무, 관심사, 과제 중 하나를 가져오면 됩니다. 중요한 건 너무 멋진 주제를 고르는 게 아니라, 실제로 내가 쓸 만한 질문을 던지는 거예요.

💡 핵심 개념

Agent Teams는 역할 분담입니다. 한 명에게 "다 해줘"라고 하면 답이 넓고 흐릿해질 때가 많아요. 반대로 리서처, 전략가, 실행 담당, 검토 담당처럼 역할을 나누면 서로 다른 시선이 나옵니다. 회의실에 네 명 앉혀두고 같은 안건을 보는 느낌이죠.

다만 Agent Teams가 생긴다고 무조건 답이 좋아지는 건 아닙니다. 여러분이 던지는 주제가 너무 흐리면 팀도 흐릿하게 움직여요. "마케팅 알려줘"보다 "부산 항만 물류 스타트업의 2026년 B2B 콘텐츠 주제 10개를 찾고 싶어"가 훨씬 낫습니다.

저는 여기서 학생들에게 꼭 말합니다. Agent Teams를 부르는 건 거창한 일이 아니에요. 내 일을 다른 각도에서 보게 만드는 장치입니다. 오늘은 그 장치를 한 번 열어보는 시간이에요.

🛠️ 시작 전 — 자료 셋업

먼저 실습 폴더를 준비합니다. 클로드코드에 아래 한 줄을 그대로 넣어 주세요.

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습16-AgentTeams활용/ 폴더를 만들고, 그 작업 폴더로 진입해 주세요. 셋업이 끝나면 위치를 한 줄로 보고만 해 주세요. 실습은 아직 시작하지 마세요.

그다음 오늘 사용할 주제를 하나 고릅니다. 너무 오래 고민하지 마세요. 여러분에게 익숙한 일이 가장 좋습니다.

/kkirikkiri 리서치 Agent Teams 만들어줘

또는 이렇게 바로 주제와 작업 범위를 넣어도 됩니다.

/kkirikkiri BPTC 항만 트렌드 리서치 Agent Teams를 만들고, 각 역할이 실제로 조사와 아이디어 정리까지 수행하게 해줘

/kkirikkiri 내 부서 반복 업무를 줄이는 자동화 Agent Teams를 만들고, 자동화 후보 5개와 실행 우선순위까지 뽑아줘

질문이 나오면 목적, 작업 종류, 원하는 깊이를 짧게 답하면 됩니다. 저는 첫 실습에서는 "리서치", "아이디어", "실행안" 중 하나로 좁히는 걸 추천합니다. 그래야 결과가 손에 잡혀요.

🚶 진행 흐름

1. 주제 고르기

여러분이 실제로 궁금한 주제를 고릅니다. 강사 예시를 그대로 따라 해도 되지만, 본인 업무와 연결하면 훨씬 재미있어져요.

오늘 kkirikkiri로 Agent Teams를 활용할 주제를 고르려고 합니다. BPTC 항만 트렌드 리서치, 내 부서 자동화, 개인 포트폴리오 개선 중에서 초보자가 실습하기 좋은 주제를 비교해 주세요.

2. 자연어 한 문장으로 호출하기

이제 길게 쓰지 말고 한 문장으로 부릅니다.

/kkirikkiri BPTC 항만 트렌드 리서치 Agent Teams를 만들고, 2026년에 볼 만한 트렌드와 콘텐츠 아이디어까지 정리해줘

또는 여러분 주제로 바꿉니다.

/kkirikkiri 우리 팀 주간 보고서 자동화 아이디어를 찾는 Agent Teams를 만들고, 바로 실행할 후보 5개를 뽑아줘

3. 인터뷰에 답하기

kkirikkiri가 몇 가지를 묻습니다. 여기서 솔직하게 답하면 돼요. 대상, 원하는 결과, 깊이 정도가 핵심입니다.

대상: 부산 항만 물류에 관심 있는 BPTC 수강생
원하는 결과: 2026년에 볼 만한 트렌드와 콘텐츠 아이디어
깊이: 처음 보는 사람도 이해할 수 있게, 실행 아이디어까지

4. Agent Teams 구성 확인하고 작업 시작시키기

팀원이 어떻게 나뉘었는지 확인합니다. 리서처만 많은지, 실행 담당이 있는지, 리뷰 역할이 있는지 보세요. 구성이 괜찮다면 바로 작업을 시작시킵니다.

방금 구성된 Agent Teams의 역할을 초보자도 이해할 수 있게 정리해 주세요. 각 팀원이 무엇을 맡는지, 결과물에서 어디를 보면 되는지도 알려주세요.

구성만 보여주고 멈추면 아래처럼 이어서 말합니다.

좋습니다. 이제 이 팀으로 작업을 시작해 주세요. 각 팀원은 자기 역할에 맞게 결과를 만들고, 마지막에는 전체 결과를 종합해서 team-result.md 초안 형태로 정리해 주세요. 20분 실습 안에 끝나도록 범위를 작게 잡아 주세요.

여기서 중요한 건 "Agent Teams를 만들었네요"가 아니라 "그 팀이 실제로 일을 했네요"입니다. 화면을 볼 때도 팀 이름보다 각 역할이 낸 결과를 더 유심히 봅니다.

5. 역할별 작업 결과 받기

작업이 끝나면 역할별 결과를 한 번 더 정돈합니다. 팀원마다 좋은 말이 많이 나와도, 실습에서는 쓸 만한 내용만 남기는 게 좋습니다.

방금 팀 작업 결과에서 역할별 핵심 산출물을 정리해 주세요. 각 역할마다 쓸 만한 내용 2개씩만 뽑고, 마지막에 내가 바로 실행할 1순위와 2순위를 추천해 주세요.

가능하면 결과를 team-result.md로 저장하게 합니다.

지금 정리한 내용을 team-result.md로 저장해 주세요. 역할별 결과, 종합 판단, 실행 1순위와 2순위를 포함해 주세요.

6. 결과를 README로 정리하기

마지막은 저장입니다. 팀 구성만 보고 끝내면 금방 사라져요. 결과를 한 폴더에 남겨야 Part 6에서 스킬 아이디어로 다시 가져올 수 있습니다.

README.md를 작성해 주세요. 오늘 만든 Agent Teams 이름, 팀원 역할, 역할별 작업 결과 요약, 내가 다음에 실제로 해볼 1순위와 2순위를 포함해 주세요.

📦 결과물

저장 위치는 50-my-work/Part04-강화하기/실습16-AgentTeams활용/입니다.

실습16-AgentTeams활용/
├── team-setup.md
├── team-result.md
└── README.md

team-setup.md에는 팀 이름, 요청한 자연어 문장, 팀원 역할을 적습니다. team-result.md에는 각 역할이 실제로 수행한 작업 결과와 종합 판단을 옮겨두면 됩니다. 자동으로 다른 폴더에 리포트가 생겼다면, 필요한 부분만 이 실습 폴더로 복사해도 괜찮아요.

README.md에는 다음 항목이 들어가면 좋습니다.

• 내가 입력한 주제
• 사용한 명령: /kkirikkiri ...
• 자동 구성된 팀원 역할
• 역할별 작업 결과 중 가장 쓸 만한 내용 3개
• 내가 실제로 해볼 1순위와 2순위
• Part 6에서 스킬로 만들 수 있을 것 같은 아이디어

여러분이 오늘 얻은 결과는 단순 리포트가 아닙니다. 나중에 "내 업무용 스킬"을 만들 때 재료가 됩니다. 저는 여기서 나온 1순위, 2순위를 꼭 남겨두라고 말합니다.

🆘 자주 막히는 포인트

막히는 데는 보통 정해져 있어요. 팀이 자동으로 움직이는 만큼, 시작 문장이 중요합니다.

여전히 애매하면 "내 주제가 너무 넓은지 봐줘"라고 물어보면 됩니다.

🔗 다음 클립

→ Part 4 / Clip 4: vibe-sunsang으로 내 사용 패턴 점검 — Agent Teams까지 써본 뒤, 이번에는 내가 AI를 어떻게 쓰고 있는지 돌아봅니다.

여러분은 이제 플러그인을 설치했고, 공식 문서를 확인했고, Agent Teams에 실제 작업까지 맡겨봤습니다. 다음 클립에서는 이 모든 사용 습관을 한 번 점검해볼 거예요.

🎯 이 클립에서 만드는 것

여러분, 지금까지 꽤 많이 AI와 대화했죠? 저는 여기서 한 번 멈추고 물어봐야 한다고 봐요. "내가 AI를 잘 쓰고 있나?" 이 질문은 혼자서는 답하기 어렵습니다.

이번 클립에서는 vibe-sunsang, 줄여서 바선생에게 내 AI 활용 패턴을 점검받습니다. Part 2부터 지금까지 쌓인 대화 로그를 바탕으로, 내가 요청을 어떻게 쓰는지, 어디서 자주 막히는지, 다음에는 무엇을 고치면 좋은지 코칭받는 시간이에요.

50-my-work/Part04-강화하기/실습17-AI활용점검/
├── 01-coaching-notes.md
└── README.md

이 클립에서 중요한 건 점수가 아닙니다. "나는 AI에게 일을 너무 크게 던지는구나", "검증 요청을 빠뜨리는구나"처럼 다음 대화에서 바로 고칠 수 있는 한두 가지를 잡는 거예요.

💡 핵심 개념

바선생은 AI 사용 습관을 봐주는 코치입니다

저는 AI를 쓰다 보면 사람들이 결과물만 보게 되는 걸 자주 봐요. 그런데 진짜 차이는 요청하는 방식에서 나요. 같은 Claude Code를 써도 어떤 사람은 일을 잘게 나눠 맡기고, 어떤 사람은 한 번에 너무 크게 던져서 중간에 길을 잃습니다.

바선생은 대화 로그를 읽고 이런 패턴을 6가지 축으로 봅니다.

이번에는 특히 네 가지 말 걸기 방식을 써봅니다. 자연어로 부르면 돼요.

솔직히 이건 조금 민망할 수 있어요. 내 대화 습관을 들여다보는 거니까요. 그런데 딱 한 번만 해보면, 다음 프롬프트가 바로 달라집니다.

📁 시작 전 — 자료 셋업

이번 클립은 새 자료를 복사해오는 실습이 아닙니다. 작업 폴더만 만들고, 바선생이 읽을 수 있는 대화 기록을 준비하면 됩니다.

한 줄 시작 — 폴더 준비 + 스킬 실행 (클로드코드에 입력)

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습17-AI활용점검/ 폴더를 만들고, 그 작업 폴더로 진입해 주세요. 그 다음 vibe-sunsang을 처음 쓰는 상태라면 시작 설정을 진행하고, 이미 설정되어 있다면 최근 대화 로그를 변환한 뒤 AI 활용 멘토링을 받을 준비까지 해 주세요.

→ 클로드코드가 자동으로:

1. mkdir -p 50-my-work/Part04-강화하기/실습17-AI활용점검/ — 작업 폴더 생성
2. 작업 폴더 진입 (cd)
3. 바선생 설정 여부 확인
4. 필요하면 /vibe-sunsang 시작 흐름 진행
5. 최근 대화 로그 변환 준비

셋업 완료 체크

작업 폴더가 있고, 바선생이 "최근 대화 로그를 볼 수 있다"는 취지로 답하면 준비 완료입니다. 처음 쓰는 분은 워크스페이스 유형을 고르라고 나올 수 있어요. Builder, Explorer, Designer, Operator 중 지금 본인에게 가까운 것을 고르면 됩니다.

🚶 진행 흐름

1. 시작하기 — 바선생 설정 확인

처음 쓰는 분은 먼저 바선생을 켭니다. 이 단계는 "분석"이 아니라 준비예요.

/vibe-sunsang 시작

워크스페이스 유형을 묻는다면 지금 이 강의에서는 보통 Builder나 Operator가 잘 맞습니다. 코딩과 결과물 제작 중심이면 Builder, 업무 자동화와 반복 처리 중심이면 Operator로 보면 돼요.

2. 변환하기 — 최근 대화 로그 읽을 수 있게 만들기

바선생은 대화 기록을 바로 읽는 게 아니라, 읽기 쉬운 형태로 변환한 뒤 분석합니다.

/vibe-sunsang 이번 주 대화 로그 변환해줘

변환 결과가 적게 나와도 괜찮습니다. 대화 기록이 적으면 진단도 짧아지는 게 정상이에요.

3. 멘토링 받기 — 전체 습관 보기

이제 본격적으로 코칭을 받습니다. 너무 어렵게 말할 필요 없습니다.

/vibe-sunsang 멘토링해줘

여기서 받은 내용 중 "맞는 말인데 좀 아프다" 싶은 문장을 01-coaching-notes.md에 남겨두세요. 그게 제일 쓸모 있는 문장입니다.

4. 요청 코칭 받기 — 프롬프트만 따로 고치기

전체 습관을 본 뒤에는 요청문 자체를 봅니다. AI 결과가 흔들리는 학생 대부분은 여기서 많이 좋아져요.

/vibe-sunsang 요청 코칭해줘. 내가 Claude Code에 일을 맡길 때 요청문에서 빠뜨리는 게 뭔지 봐줘.

좋은 답을 받으면 "다음 요청 예시"까지 뽑아달라고 하세요. 바로 써먹을 수 있어야 합니다.

5. 개선 포인트 정리하기

마지막에는 많이 적지 말고 두세 개만 남깁니다. 너무 많이 고치려고 하면 아무것도 안 바뀌어요.

오늘 받은 코칭을 바탕으로 실습17-AI활용점검/README.md를 작성해 주세요. 포함할 내용은 1) 내가 자주 보인 패턴, 2) 바선생이 짚은 개선 포인트 2개, 3) 다음 실습에서 바로 써볼 요청문 1개입니다.

📦 결과물

저장 위치는 50-my-work/Part04-강화하기/실습17-AI활용점검/입니다. 코칭 원문을 전부 예쁘게 옮기려 하지 말고, 내가 다음에 볼 내용만 남기면 됩니다.

실습17-AI활용점검/
├── 01-coaching-notes.md   # 바선생 코칭에서 건진 핵심 문장
└── README.md              # 개선 포인트와 다음 요청 예시

README.md에는 "다음부터 이렇게 요청하겠다"는 문장을 꼭 하나 넣으세요. 이 클립은 회고가 아니라 다음 대화를 바꾸는 준비입니다.

🆘 자주 막히는 포인트

막히는 데는 보통 정해져 있어요. 아래부터 확인하면 됩니다.

여전히 애매하면 "내가 지금 바로 고칠 것 1개만 골라줘"라고 다시 물어보세요. 그게 가장 빠릅니다.

🔗 다음 클립

→ Part 4 / Clip 5: show-me-the-prd — PRD 자동 생성 — 이제 내 AI 사용 습관을 점검했으니, 다음에는 한 문장짜리 아이디어를 4종 설계 문서로 바꿔봅니다.

다음 클립에서 만든 PRD는 그냥 문서로 끝나지 않습니다. 그 안의 핵심 기능 하나를 마지막 Clip 6에서 실제 스킬로 바꿀 거예요.

🎯 이 클립에서 만드는 것

"반복 업무 자동화 도구 하나 만들고 싶어요." 이 한 문장, 너무 막연하죠? 그런데 실무에서 시작은 원래 이 정도입니다. 처음부터 데이터 구조와 개발 단계가 머릿속에 다 있으면 오히려 이상해요.

이번 클립에서는 show-me-the-prd 스킬로 한 문장짜리 아이디어를 4종 디자인 문서로 바꿉니다. 스킬이 5~6개 정도 질문을 던지고, 여러분은 부서와 직무에 맞게 답합니다. 그 답을 모아 PRD, 데이터 모델, Phase 계획, 프로젝트 스펙을 자동으로 만들어줘요.

50-my-work/Part04-강화하기/실습18-PRD작성/
├── PRD/
│   ├── 01_PRD.md
│   ├── 02_DATA_MODEL.md
│   ├── 03_PHASES.md
│   └── 04_PROJECT_SPEC.md
└── README.md

오늘 만든 PRD는 다음 Clip 6의 재료입니다. 문서 하나 쓰고 끝나는 게 아니라, 여기서 핵심 기능 하나를 골라 실제 스킬 설계로 이어갑니다.

💡 핵심 개념

PRD는 "만들기 전에 합의하는 문서"입니다

AI에게 바로 "앱 만들어줘"라고 하면 처음엔 빨라 보입니다. 그런데 중간에 꼭 흔들립니다. 누가 쓰는지, 어떤 데이터를 저장하는지, 1차 버전에서 뭘 빼야 하는지 정하지 않았기 때문이에요.

show-me-the-prd는 그 빈칸을 인터뷰로 채웁니다. 여러분이 아는 것은 업무의 불편함입니다. AI가 도와주는 것은 제품 문서의 구조예요.

학생 주제는 자유입니다. 중요한 건 멋진 스타트업 아이디어가 아니라, 내가 실제로 귀찮게 반복하는 일을 고르는 거예요.

솔직히 "내 업무가 너무 작나?" 걱정할 필요 없습니다. 작고 자주 하는 일이 PRD 실습에는 제일 좋습니다.

📁 시작 전 — 자료 셋업

이번 클립은 빈 폴더에서 시작합니다. 대신 주제는 여러분이 직접 고릅니다. 부서명이 달라도 괜찮아요. 본인이 하는 반복 업무를 한 줄로 쓰면 됩니다.

한 줄 시작 — 폴더 준비 + 스킬 실행 (클로드코드에 입력)

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습18-PRD작성/ 폴더를 만들고, 그 작업 폴더로 진입해 주세요. 그 다음 show-me-the-prd 스킬로 "내가 자주 하는 반복 업무 자동화 도구"를 PRD로 만들 준비를 해 주세요. 아직 문서는 생성하지 말고, 먼저 주제 선택 질문부터 시작해 주세요.

→ 클로드코드가 자동으로:

1. mkdir -p 50-my-work/Part04-강화하기/실습18-PRD작성/ — 작업 폴더 생성
2. 작업 폴더 진입 (cd)
3. 주제 선택 질문 시작
4. show-me-the-prd 인터뷰 준비

셋업 완료 체크

작업 폴더가 비어 있어도 괜찮습니다. 오늘의 출발점은 파일이 아니라 한 문장입니다.

🚶 진행 흐름

1. 주제 고르기 — 내 업무에서 하나 잡기

먼저 너무 거창하게 잡지 마세요. "부서 전체 시스템"보다 "매주 반복하는 보고서"가 좋습니다.

이번 PRD 주제는 "매주 영업 보고서 양식 자동 작성"으로 하겠습니다. 내가 넣는 원자료를 바탕으로 요약, 표준 문구, 다음 액션을 만들어주는 도구를 상상하고 있어요.

자기 주제가 바로 안 떠오르면 아래처럼 시작해도 됩니다.

내 부서는 HR이고, 반복 업무 자동화 주제를 고르려고 합니다. 신입사원 온보딩, 교육 신청 관리, 면담 기록 정리 중 PRD 실습에 가장 좋은 주제를 골라 주세요.

2. 스킬 호출 — 한 문장으로 시작하기

이제 show-me-the-prd를 부릅니다. 명령은 짧아도 됩니다.

/show-me-the-prd 내가 자주 하는 반복 업무 자동화 도구

또는 주제가 정해졌다면 바로 이렇게 부르세요.

/show-me-the-prd 월말 자재 재고 정산 자동화 도구

3. 인터뷰 답하기 — 5~6개만 성실하게

스킬은 보통 목적, 사용자, 입력 자료, 원하는 결과, 꼭 빼야 할 범위를 묻습니다. 여기서 긴 보고서처럼 답할 필요는 없어요.

사용자는 자재팀 담당자입니다. 월말마다 창고별 재고 수량, 입출고 기록, 누락 항목을 모아서 차이를 확인해야 합니다. 첫 버전에서는 엑셀 업로드와 차이 목록 생성만 되면 됩니다. ERP 연동은 나중에 하고 싶습니다.

제가 여기서 꼭 넣는 말은 "첫 버전에서는"입니다. 이 말을 넣으면 AI가 욕심을 덜 부려요.

4. 4종 문서 생성하기

인터뷰가 끝나면 문서를 생성합니다. 파일명은 강의 폴더 구조와 맞춥니다.

지금까지 답변한 내용을 바탕으로 PRD/ 폴더 안에 01_PRD.md, 02_DATA_MODEL.md, 03_PHASES.md, 04_PROJECT_SPEC.md 4개 문서를 생성해 주세요. README.md는 작업 폴더 루트에 따로 만들고, 선택한 주제와 인터뷰 답변 요약, 다음 액션을 적어 주세요.

5. 검증하기 — 다음 클립에서 쓸 기능 하나 고르기

문서가 만들어지면 01_PRD.md와 03_PHASES.md를 먼저 봅니다. 다음 클립에서 스킬로 만들 기능을 하나 골라야 하거든요.

생성된 PRD 문서를 읽고, 다음 클립에서 스킬로 만들기 좋은 핵심 기능 1개를 골라 주세요. 너무 큰 기능은 피하고, 입력과 출력이 분명한 기능을 추천해 주세요.

📦 결과물

저장 위치는 50-my-work/Part04-강화하기/실습18-PRD작성/입니다. PRD 4종 문서는 PRD/ 안에, 회고와 다음 액션은 루트 README.md에 둡니다.

실습18-PRD작성/
├── PRD/
│   ├── 01_PRD.md
│   ├── 02_DATA_MODEL.md
│   ├── 03_PHASES.md
│   └── 04_PROJECT_SPEC.md
└── README.md

README.md에는 선택한 주제, 인터뷰 답변 요약, 다음 클립에서 스킬로 만들 후보 기능을 적습니다. 다음 클립에서 이 PRD의 핵심 기능 1개를 정교한 스킬로 만듭니다.

🆘 자주 막히는 포인트

막히는 지점은 대부분 주제가 너무 크거나 너무 흐릴 때 나옵니다.

문서가 길어도 겁먹지 마세요. 다음 클립에서 보는 건 전부가 아니라 핵심 기능 하나입니다.

🔗 다음 클립

→ Part 4 / Clip 6: skillers-suda — 4명 전문가와 스킬 설계 — 방금 만든 PRD에서 기능 하나를 골라, 실제로 불러 쓸 수 있는 스킬로 바꿉니다.

PRD는 설계도입니다. 다음 클립에서는 그 설계도에서 방 하나를 골라 실제 도구로 만들어볼 거예요.

🎯 이 클립에서 만드는 것

PRD까지 만들었으면 이제 "그래서 이걸 어떻게 매번 다시 쓰지?"가 남습니다. 앱 전체를 만들기 전에, 반복해서 써먹을 작은 기능 하나를 스킬로 빼내는 거예요.

이번 클립에서는 Clip 5에서 만든 PRD의 핵심 기능 1개를 고르고, skillers-suda에게 맡깁니다. PM, 작가, 기획자, 테스터 관점으로 아이디어를 뜯어본 뒤, 실제 .claude/skills/{내스킬명}/SKILL.md 형태의 스킬을 만듭니다.

50-my-work/Part04-강화하기/실습19-스킬설계/
├── PRD/
├── 01-skill-design-notes.md
└── README.md

~/Desktop/bptc-cc/.claude/skills/{내스킬명}/
└── SKILL.md

여기서 중요한 건 "앱을 다 만든다"가 아닙니다. PRD 안에서 가장 작고 반복 가능한 기능 하나를 떼어내, 다음부터 /내스킬명처럼 부를 수 있게 만드는 겁니다.

💡 핵심 개념

좋은 스킬은 작고 자주 쓰는 일에서 나옵니다

스킬은 거대한 제품 설명서가 아닙니다. Claude Code가 특정 상황에서 "아, 이때는 이 방식으로 진행해야겠다"라고 알아차리게 해주는 작업 설명서예요.

그래서 Clip 5의 PRD를 그대로 전부 스킬로 만들면 너무 큽니다. 하나만 고릅니다.

skillers-suda는 이 기능을 4명 전문가가 나눠 봅니다.

혼자 만들면 대충 "이렇게 쓰면 되겠지"로 끝나기 쉽습니다. 네 관점이 들어오면 스킬의 입구, 흐름, 실패 대응이 훨씬 또렷해져요.

📁 시작 전 — 자료 셋업

이번 클립은 Clip 5 결과물에서 출발합니다. 먼저 PRD/ 폴더를 그대로 복사하세요. 이 연결이 끊기면 skillers-suda가 무엇을 보고 스킬을 설계해야 하는지 모릅니다.

1단계. Clip 5의 PRD 폴더 가져오기 (터미널 또는 클로드코드에 입력)

mkdir -p ~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습19-스킬설계/
cp -R ~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습18-PRD작성/PRD ~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습19-스킬설계/

2단계. 작업 폴더로 진입

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습19-스킬설계/ 폴더로 진입하고, PRD/01_PRD.md, PRD/03_PHASES.md를 읽은 뒤 스킬로 만들기 좋은 핵심 기능 후보를 2~3개만 골라 주세요. 아직 스킬 파일은 만들지 마세요.

셋업 완료 체크

작업 폴더 안에 PRD/01_PRD.md, PRD/02_DATA_MODEL.md, PRD/03_PHASES.md, PRD/04_PROJECT_SPEC.md가 있으면 준비 완료입니다.

🚶 진행 흐름

1. 핵심 기능 하나 고르기

처음부터 스킬 만들자고 하지 말고, 기능을 먼저 고릅니다. 입력과 출력이 선명한 기능이 좋아요.

PRD 문서를 읽고 스킬로 만들기 좋은 기능을 하나 골라 주세요. 기준은 1) 자주 반복되는가, 2) 입력이 분명한가, 3) 결과물이 파일이나 체크리스트로 남는가입니다.

예를 들어 "월말 자재 재고 정산 자동화" PRD라면 앱 전체가 아니라 "입출고 엑셀을 읽고 차이 목록 초안을 만드는 스킬"이 좋습니다.

2. skillers-suda 호출하기

이제 PRD를 붙여서 스킬 설계를 맡깁니다. 핵심은 "이 PRD의 어떤 기능"인지 콕 집어 말하는 겁니다.

/skillers-suda
@PRD/01_PRD.md
@PRD/02_DATA_MODEL.md
@PRD/03_PHASES.md
@PRD/04_PROJECT_SPEC.md

이 PRD의 [기능명]을 스킬로 만들고 싶어. 결과는 ~/Desktop/bptc-cc/.claude/skills/{내스킬명}/SKILL.md 형태로 만들고, 초보자가 자연어로 부를 수 있게 트리거 문장도 같이 설계해줘.

[기능명]에는 실제로 고른 기능을 넣으세요. 예: 재고 차이 목록 초안 생성, 영업 보고서 초안 작성, 온보딩 체크리스트 생성.

3. 4명 전문가 토론 확인하기

skillers-suda가 PM, 작가, 기획자, 테스터 관점으로 질문하거나 의견을 줄 겁니다. 여기서 "네"만 누르지 말고 충돌 지점을 보세요.

4명 의견 중 서로 다르게 본 부분을 먼저 정리해 주세요. 그 다음 제가 결정해야 하는 항목만 2~3개로 줄여 주세요.

결정은 짧게 하면 됩니다. 예를 들면 "첫 버전은 엑셀 파일 1개만 받는다", "결과는 README 초안으로 만든다" 정도면 충분해요.

4. SKILL.md 생성하기

결정이 끝나면 실제 스킬 파일을 만듭니다. 이때 경로를 분명히 말해야 합니다.

확정한 설계대로 ~/Desktop/bptc-cc/.claude/skills/{내스킬명}/SKILL.md를 생성해 주세요. description에는 언제 이 스킬을 써야 하는지와 자연스러운 호출 문장을 넣고, 본문에는 입력 자료, 진행 단계, 결과물, 실패했을 때 처리 방법을 포함해 주세요.

5. 바로 불러서 테스트하기

스킬은 파일이 생겼다고 끝이 아닙니다. 실제 호출 문장으로 한 번 테스트해야 해요.

방금 만든 스킬을 실제로 불러 테스트하려고 합니다. 샘플 입력을 하나 만들고, 스킬이 어떤 순서로 작동하는지 점검한 뒤 부족한 부분을 SKILL.md에 반영해 주세요.

테스트 결과는 01-skill-design-notes.md와 README.md에 남깁니다. 나중에 내가 왜 이렇게 만들었는지 기억해야 하니까요.

📦 결과물

이번 클립의 기록은 50-my-work/Part04-강화하기/실습19-스킬설계/에 남기고, 실제 스킬은 사용자 워크스페이스의 .claude/skills/ 아래에 만듭니다.

실습19-스킬설계/
├── PRD/
│   ├── 01_PRD.md
│   ├── 02_DATA_MODEL.md
│   ├── 03_PHASES.md
│   └── 04_PROJECT_SPEC.md
├── 01-skill-design-notes.md
└── README.md

.claude/skills/{내스킬명}/
└── SKILL.md

README.md에는 선택한 기능, 4명 전문가가 짚은 포인트, 최종 스킬 호출 문장, 테스트 결과를 적습니다. 이 파일이 있으면 나중에 스킬을 고칠 때 훨씬 편합니다.

🆘 자주 막히는 포인트

마지막 클립이라 욕심이 나기 쉽습니다. 작게 잡는 게 이깁니다.

계속 헷갈리면 "이 스킬을 오늘 딱 한 번만 쓴다면 어떤 입력을 넣을까?"라고 물어보세요. 그 답이 스킬 범위입니다.

🔗 다음 클립

→ Part 4 / Clip 7: 바르다 깃선생 — git/GitHub 첫 발 — Part 4 마지막은 git/GitHub 첫 발을 떼는 자리예요. Part 5에서 워크스페이스를 받기 시작하는데, 그 받는 방법이 보통 git clone이거든요. 한 번 익혀두고 가면 매끄러워요.

오늘 만든 .claude/skills/{내스킬명}/SKILL.md도 깃선생 클립에서 첫 push 대상으로 써볼 수 있습니다. 강의용 예제가 아니라 내 도구로 바뀌는 순간이 여기서 시작돼요.

🎯 이 클립에서 만드는 것

여러분, Part 5부터 본격적으로 워크스페이스를 받아 내 비서를 만들어요. 그 받는 가장 깔끔한 방법이 git clone이거든요. git이 뭔지 모른 채로 받으면 "왜 이걸 써?" "어디로 받아지는 거야?" 같은 질문이 자꾸 발목을 잡아요.

저는 Part 4 마지막에 이 한 클립을 끼워 넣는 게 훨씬 효율적이라고 봐요. 바르다 깃선생 플러그인을 써서 git/GitHub 기본 감각만 잡고 Part 5로 넘어갑니다. Part 5에서 워크스페이스 받기·내 결과물 백업·발표 자료 공유까지 다 매끄러워져요.

50-my-work/Part04-강화하기/실습20-깃기초/
├── hello-bptc/                 # 바르다 깃선생이 만든 첫 프로젝트 폴더
│   ├── README.md               # "이 프로젝트는 무엇인가" 한 줄
│   └── (.git, GitHub remote 연결 완료)
└── README.md                   # 이번 실습 회고

목표는 단순합니다. 첫 commit + 첫 push까지 가서 GitHub 페이지에서 내 파일이 보이는 순간을 만나는 것. 거기까지면 충분해요.

💡 핵심 개념

git/GitHub은 "구글 드라이브 + 변경 이력"

바르다 깃선생은 비개발자를 위한 플러그인이라 비유부터 친절합니다.

저는 학생들이 "git은 개발자만 쓰는 어려운 것"이라고 미리 겁먹는 걸 자주 봤어요. 사실 우리가 하려는 건 드라이브 동기화에 가깝습니다.

바르다 깃선생 — 5 스킬

플러그인이 5개 자연어 스킬을 제공해요.

명령어를 외울 필요가 없어요. "지금 뭐 했냐?", "이거 저장해줘" 같은 자연어로 말 걸어도 알아들어요.

🛠️ 시작 전 — 자료 셋업

한 줄 시작 — 폴더만 만들기 (클로드코드에 입력)

~/Desktop/bptc-cc/50-my-work/Part04-강화하기/실습20-깃기초/ 폴더를 만들고, 그 작업 폴더로 진입해 주세요. 셋업이 끝나면 작업 폴더 위치를 한 줄로 보고만 해 주세요. 실습은 아직 시작하지 마세요.

이번 클립은 셋업이 가벼워요. 진짜 셋업은 다음 단계에서 바르다 깃선생이 알아서 해줍니다.

🚶 진행 흐름

1. 시작하기 — 환경 점검 + 첫 프로젝트 만들기

작업 폴더에서 클로드코드에 그대로 입력하세요.

/git-teacher 시작하기

여기서 깃선생이 자동으로 점검합니다.

• git 설치 여부 (안 깔렸으면 설치 안내)
• gh 명령(GitHub CLI) 설치 여부
• git 사용자 이름·이메일 설정 여부
• GitHub 로그인 여부 (gh auth status)

이미 끝난 항목은 체크 표시로 넘어가고 안 된 항목만 진행해요. 처음 쓰는 분이라면 GitHub 로그인은 브라우저 인증으로 한 번만 하면 됩니다.

이어서 첫 프로젝트 폴더 이름을 묻습니다. 저는 hello-bptc 정도를 추천해요. 이름을 정하면 폴더가 생기고 git 초기화 + 첫 README가 자동으로 들어갑니다.

2. 처음 변경하기 — README에 한 줄 적기

만들어진 hello-bptc/README.md를 열어 한 줄을 직접 적어보세요. 클로드코드에 입력해도 됩니다.

hello-bptc/README.md를 열어서 첫 줄에 "이 프로젝트는 BPTC 클로드코드 워크샵에서 git을 처음 써본 흔적이다." 라고 적어 주세요.

이렇게 한 번 직접 변경하면 "내가 뭘 바꿨는지"가 분명해져서 다음 단계가 와닿아요.

3. 저장하기 — 첫 commit

/git-teacher 저장하기

깃선생이 변경된 파일을 자동으로 묶고 commit 메시지를 한국어로 추천해요. "그대로 좋다"고 하면 commit이 찍힙니다. commit이 뭔지 잘 모르겠다면 여기서 잠깐 /git-teacher 리뷰를 호출해서 "지금 뭐 한 거예요?"라고 물어보세요.

4. 올리기 — 첫 push

/git-teacher 올리기

처음 올리는 거면 깃선생이 GitHub 원격 저장소(repo)를 자동으로 만들 거예요. public/private 선택을 묻습니다. 학습용은 private로 충분해요.

push가 끝나면 깃선생이 GitHub 페이지 URL을 알려줍니다. 브라우저로 열어서 내가 적은 README가 떠 있으면 성공이에요.

5. 상태 보기 — 감각 잡기

마지막으로 한 번만.

/git-teacher 상태

지금 git이 뭘 추적하고 있고 다음에 commit할 게 있는지 한눈에 보여줍니다. 이 명령은 다음 클립부터 워크스페이스에서도 자주 쓰게 돼요. "내가 변경한 게 뭐였지?"가 헷갈릴 때 가장 빠른 답입니다.

📦 결과물

저장 위치는 50-my-work/Part04-강화하기/실습20-깃기초/입니다.

실습20-깃기초/
├── hello-bptc/                 # 첫 프로젝트 폴더
│   ├── README.md               # 직접 한 줄 적은 파일
│   └── (.git + GitHub 연결)
└── README.md                   # 이번 실습 회고

회고 README에는 다음을 적으세요.

• GitHub 프로젝트 URL (push로 만들어진 repo 링크)
• 5 스킬 중에서 가장 쓸모 있다고 느낀 1개
• 다음에 git을 또 쓰고 싶은 상황 1개

저는 "두 줄이면 끝"을 강조해요. 길게 적으면 다음 클립으로 못 넘어갑니다.

🆘 자주 막히는 포인트

여기서 중요한 건 "전부 이해하고 가지 말자"예요. push까지 한 번 가본 경험만 남으면 다음 클립이 자연스럽게 풀려요.

🔗 다음 클립

→ Part 5 / Clip 1: 워크스페이스 — 비서의 영혼 — 이제 git을 한 번 써봤으니, Part 5에서는 워크스페이스 개념을 잡고 받아쓰는 비서(workmate)를 본인 손으로 개인화해 봅니다.

Part 5 / Clip 2에서 workmate를 받을 때 git clone 한 줄만 쳐도 익숙하게 느껴질 거예요.

🎯 이 클립에서 만드는 것

여러분, 지금까지는 AI에게 일을 시켰죠? 보고서도 만들고, 포트폴리오도 만들고, 문서도 찾아봤습니다. 그런데 Part 5부터는 살짝 위치가 바뀝니다. 이제 여러분은 "AI 사용자"에서 "AI 비서의 작업 환경을 설계하는 사람"이 돼요.

이번 클립에서는 아직 workmate를 설치하지 않습니다. 먼저 구조를 봅니다. 저는 이 순서를 중요하게 봐요. 집 안 구조도 모르고 집사에게 일을 맡기면, 그 집사가 어디서 자료를 꺼내고 어디에 기록을 남기는지 감이 안 오잖아요?

오늘 만드는 결과물은 workspace-개념.md입니다. 여기에 workmate의 5가지 핵심 구성 요소를 여러분 말로 정리합니다.

한마디로 말하면 이겁니다. 워크스페이스는 비서의 영혼입니다. 성격, 기억, 책상, 도구함, 업무 파일이 한 번에 놓인 자리예요.

💡 핵심 개념

비서에게 "영혼"이 있다는 말, 조금 과하게 들리죠? 그런데 실제로 써보면 이 표현이 딱 맞습니다. 같은 Claude라도 어떤 폴더에서 실행하느냐에 따라 전혀 다르게 행동해요. 왜냐하면 그 폴더 안에 정체성, 규칙, 기억, 참고자료, 작업 대상이 들어 있기 때문입니다.

workmate는 다섯 덩어리로 보면 됩니다.

저는 여기서 CLAUDE.md를 제일 먼저 봅니다. 여기에 "이 비서는 누구인가"가 적혀 있거든요. 다음 클립에서 /onboarding을 하면 담당자 빈칸이 채워지고, 범용 비서가 여러분 비서로 바뀌어요.

.claude/는 겉으로 잘 안 보이지만 중요합니다. /onboarding, /inbox-sorter 같은 커맨드와 반복 업무를 스킬로 키우는 장치가 여기 있어요.

memory/는 세션이 끝나도 남는 기억입니다. "이 사람은 짧은 보고를 좋아한다", "지난번에 이 형식으로 정리했다" 같은 내용이 여기 쌓입니다.

references/는 판단할 때 보는 책이고, data/는 오늘 처리할 재료입니다. 불량률 기준표는 references/, 이번 달 불량 데이터 CSV는 data/에 가까워요.

결국 Part 5의 목표는 "프롬프트 잘 쓰기"가 아닙니다. 여러분 업무가 들어와도 흔들리지 않는 작업장을 만드는 거예요.

🛠️ 시작 전 — 자료 셋업

이번 클립은 이론 클립이라 폴더만 만듭니다. workmate는 다음 클립에서 받아요. 지금은 여러분이 나중에 다시 볼 학습 노트를 준비합니다.

터미널이나 클로드코드에 아래 명령을 넣어 주세요.

mkdir -p ~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습20-워크스페이스이론/
cd ~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습20-워크스페이스이론/
touch workspace-개념.md

셋업이 끝나면 workspace-개념.md를 열고 제목만 먼저 적어둡니다.

# workspace-개념

## 워크스페이스가 왜 비서의 영혼인가

## workmate 5가지 구성 요소

## Part 5에서 내가 만들 것

저는 빈 파일을 그냥 두지 않는 편입니다. 제목 세 줄만 있어도 "여기에 뭘 채워야 하는지"가 보이거든요. 여러분도 오늘은 완벽한 정리보다, 나중에 내 말로 다시 읽을 수 있는 뼈대를 만드는 데 집중하면 됩니다.

🚶 진행 흐름

1. 사용자에서 시스템 설계자로 넘어가기

먼저 오늘의 전환점을 한 줄로 적습니다. 여러분이 지금까지 한 일과 Part 5에서 할 일을 나눠 보는 거예요.

workspace-개념.md에 "지금까지 나는 AI 사용자였고, Part 5부터는 AI 비서의 작업 환경을 설계한다"는 내용을 강의 노트 톤으로 정리해 주세요. 너무 딱딱하지 않게, 예시 3개를 넣어 주세요.

이 단계에서 중요한 건 기분 전환입니다. "AI가 잘 일할 자리를 만들어주는 사람"으로 보면 폴더 하나도 다르게 보입니다.

2. 5가지 구성 요소 정리하기

이제 workmate의 다섯 조각을 표로 정리합니다. 저는 이 표가 Part 5 전체의 지도라고 봅니다.

workmate 워크스페이스를 CLAUDE.md, .claude/, memory/, references/, data/ 다섯 요소로 나눠 설명해 주세요. 각 요소마다 "무엇을 넣는 곳인지", "비서가 어떻게 쓰는지", "학생이 실습에서 확인할 것"을 표로 정리해 주세요.

표를 만든 뒤에는 한 줄을 꼭 추가하세요. CLAUDE.md는 정체성, .claude/는 도구, memory/는 기억, references/는 기준, data/는 재료입니다.

3. 패캠에서 본 것과 Part 5에서 만들 것 비교하기

Part 3와 Part 4는 주로 "요청하면 결과가 나오는 경험"이었습니다. Part 5는 그 요청이 반복 가능해지는 장면입니다.

Part 3, Part 4에서 했던 작업과 Part 5에서 만들 workmate 라인을 비교하는 Before/After 표를 작성해 주세요. 핵심은 "사용자 → 시스템 설계자" 전환입니다.

겁낼 필요는 없어요. 코드로 거대한 앱을 만드는 게 아니라, 비서가 일할 책상을 차려주는 겁니다.

4. 내 업무로 바꿔 생각하기

마지막으로 여러분 업무를 하나 떠올립니다. 영업 보고, 채용 서류, 재무 마감, 콘텐츠 기획, 제조 품질 자료, 뭐든 괜찮아요.

내 업무 하나를 예로 들어 workmate 5요소에 무엇이 들어갈지 상상해 보겠습니다. 예시는 [내 업무명]입니다. CLAUDE.md, .claude/, memory/, references/, data/에 들어갈 내용을 각각 2개씩 제안해 주세요.

여기서 나온 내용은 아직 실행하지 않습니다. 다음 클립부터 실제 workmate를 받고, /onboarding으로 이 상상을 현실로 바꿔요.

📦 결과물

저장 위치는 50-my-work/Part05-에이전트구축/실습20-워크스페이스이론/입니다.

실습20-워크스페이스이론/
└── workspace-개념.md

workspace-개념.md에는 세 가지가 들어가면 됩니다.

• 워크스페이스 정의 — 비서의 정체성, 도구, 기억, 기준, 재료가 함께 있는 작업장
• 5가지 구성 요소 — CLAUDE.md, .claude/, memory/, references/, data/
• 내 업무 적용 상상 — 다음 클립에서 개인화할 때 넣고 싶은 정보

저는 이 결과물을 "설치 전 지도"라고 부릅니다. 지도 없이 바로 여행을 떠나도 되긴 합니다. 그런데 여러분이 지금 구조를 보고 가면, 다음 클립에서 workmate 폴더가 열리는 순간 덜 낯설어요.

🆘 자주 막히는 포인트

처음엔 폴더 이름이 영어라 좀 차갑게 느껴질 수 있습니다. 막히는 데는 보통 정해져 있어요.

여전히 헷갈리면 CLAUDE.md = 누구인가, .claude/ = 무엇을 할 수 있나, memory/ = 무엇을 기억하나 이 세 개만 먼저 잡으면 됩니다.

🔗 다음 클립

→ Part 5 / Clip 2: workmate 받기와 온보딩 — 이제 진짜 workmate 워크스페이스를 ~/Desktop/workmate/에 놓고 /onboarding으로 여러분 비서로 바꿉니다.

오늘은 비서의 설계도를 봤습니다. 다음 클립에서는 빈 담당자 칸이 여러분 이름과 업무로 채워지는 순간을 보게 됩니다. 여기서부터 조금 재미있어져요.

🎯 이 클립에서 만드는 것

여러분, 지난 클립에서 워크스페이스가 비서의 영혼이라고 했죠? 오늘은 그 영혼에 이름표를 붙입니다. 공용으로 받은 workmate를 여러분 비서로 바꾸는 시간이에요.

workmate는 처음엔 빈 사무실 같습니다. 책상도 있고 규칙도 있는데 아직 "누구를 위해 일하는지"는 모릅니다. 그래서 /onboarding으로 이름, 소속, 직무, 보고 대상, 반복 업무, 선호 스타일을 묻고 CLAUDE.md를 채워요.

오늘 결과물은 두 가지입니다. 개인화된 CLAUDE.md 담당자 섹션 캡처, 그리고 첫 대화 기록입니다. 저는 이 첫 대화를 중요하게 봅니다. 비서가 여러분을 어떻게 이해했는지 처음 확인하는 장면이거든요.

솔직히 말하면, 여기서 대충 넘기면 뒤 클립이 계속 애매해집니다. 여러분 비서가 여러분을 모르면, 그냥 친절한 일반 AI일 뿐이에요.

💡 핵심 개념

/onboarding은 가입 양식이 아닙니다. 비서에게 "내가 누구고, 어떤 일을 반복하고, 어떤 말투와 결과물을 좋아하는지" 알려주는 인터뷰예요.

처음 CLAUDE.md의 담당자 섹션은 비어 있습니다.

- 이름: _(미설정)_
- 소속: _(미설정)_
- 직무: _(미설정)_
- 보고 대상: _(미설정)_
- 커뮤니케이션 선호: _(미설정)_
- 주요 반복 업무: _(미설정)_

이 빈칸이 채워지는 순간부터 비서는 다르게 움직입니다. "보고서 초안 써줘"라고 말했을 때, 누구에게 보고하는지와 어떤 표현을 피해야 하는지 먼저 떠올릴 수 있어요.

저는 온보딩 답변을 멋지게 쓰려고 하지 말라고 말하고 싶습니다. "마케팅 전략 수립"보다 "매주 월요일 캠페인 성과를 팀장에게 1페이지로 보고"가 훨씬 좋아요.

인터뷰에서 주로 묻는 항목은 이렇습니다.

회사 이름이나 민감한 수치를 넣기 부담스럽다면 익명화해도 됩니다. 저는 실습에서는 실제 이름보다 실제 업무 흐름이 더 중요하다고 봅니다.

🛠️ 시작 전 — 자료 셋업

이번 클립에서는 workmate 워크스페이스를 ~/Desktop/workmate/에 둡니다. 폴더 이름이 중요해요. 뒤 클립들이 이 위치를 기준으로 설명됩니다.

먼저 결과 기록용 폴더를 만듭니다.

mkdir -p ~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습21-개인화/

workmate를 받는 방법은 둘 중 하나입니다.

cd ~/Desktop

# Drive zip으로 받은 경우
# 압축을 풀고 폴더 이름을 workmate로 바꿔 주세요.

# git으로 받은 경우
git clone <강의에서 제공한 workmate 저장소 주소> workmate

그 다음 workmate 폴더에서 Claude Code를 실행합니다.

cd ~/Desktop/workmate
claude

Claude Code가 열리면 첫 명령은 이것입니다.

/onboarding

여기까지 오면 준비 끝입니다. 여러분은 이제 공용 starter kit을 받은 게 아니라, 내 업무를 묻기 시작하는 비서를 앞에 둔 거예요.

🚶 진행 흐름

1. workmate 위치 확인하기

먼저 폴더가 맞는지 봅니다. 위치가 꼬이면 뒤에서 파일이 다른 곳에 생겨요.

현재 폴더가 ~/Desktop/workmate인지 확인해 주세요. 그리고 이 워크스페이스의 README.md와 CLAUDE.md가 있는지도 확인해 주세요. 아직 파일은 수정하지 마세요.

README.md와 CLAUDE.md가 보이면 정상입니다. 저는 여기서 CLAUDE.md 담당자 섹션을 한 번 열어보게 합니다. 빈칸을 보고 시작해야, 온보딩 뒤에 무엇이 바뀌었는지 보이거든요.

2. /onboarding 인터뷰 시작하기

이제 인터뷰를 시작합니다. 답변은 짧아도 됩니다. 대신 실제 업무처럼 써야 해요.

/onboarding

예를 들어 이렇게 답할 수 있습니다.

이름은 김민지입니다.
소속은 브랜드마케팅팀입니다.
직무는 캠페인 성과 정리와 주간 보고입니다.
보고 대상은 팀장님이고, 보고서는 짧은 요약을 먼저 좋아합니다.
반복 업무는 광고 성과 CSV 확인, 이슈 목록 정리, 다음 액션 제안입니다.

여러분이 학생이라면 회사 대신 "개인 프로젝트 운영", "강의 실습 정리", "취업 포트폴리오 관리"처럼 적어도 됩니다. 비서에게 필요한 건 직함의 무게가 아니라 반복되는 일의 모양이에요.

3. 담당자 섹션 확인하기

인터뷰가 끝나면 CLAUDE.md가 바뀌었는지 확인합니다.

CLAUDE.md의 담당자 섹션을 보여 주세요. 방금 온보딩에서 입력한 이름, 소속, 직무, 보고 대상, 반복 업무, 선호 스타일이 반영됐는지 확인하고 누락된 항목을 알려주세요.

여기서 누락이 있으면 바로 고치면 됩니다. 저는 "주의사항 / 금기"도 한 줄 넣는 걸 좋아합니다. 예를 들어 "확인 안 된 숫자를 단정하지 않기", "임원 보고에는 농담 넣지 않기" 같은 식이죠.

4. 첫 대화 기록 남기기

이제 비서에게 첫 업무성 질문을 해봅니다. 너무 큰 작업 말고, 내 업무를 이해했는지 확인하는 질문이 좋습니다.

방금 온보딩한 제 정보를 바탕으로, 앞으로 당신이 저를 도울 수 있는 반복 업무 5가지를 제안해 주세요. 각 항목은 입력 자료, 결과물, 제가 확인할 포인트로 나눠 주세요.

받은 답변은 결과 폴더의 첫-대화-기록.md에 옮깁니다.

~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습21-개인화/첫-대화-기록.md 파일을 만들고, 방금 첫 대화 요약과 앞으로 맡길 반복 업무 후보 5개를 정리해 주세요.

5. 캡처 남기기

마지막으로 CLAUDE.md 담당자 섹션이 보이는 화면을 캡처합니다. 여러분이 나중에 "내 비서가 어디서 나를 기억하지?"라고 물을 때 바로 보여줄 증거예요.

파일 이름은 CLAUDE-담당자섹션-캡처.png처럼 저장하면 됩니다. 담당자 정보가 보이면 충분합니다.

📦 결과물

저장 위치는 50-my-work/Part05-에이전트구축/실습21-개인화/입니다.

실습21-개인화/
├── CLAUDE-담당자섹션-캡처.png
├── 첫-대화-기록.md
└── README.md

실제 개인화는 ~/Desktop/workmate/CLAUDE.md에 반영됩니다. 결과 폴더에는 그 증거와 기록을 남겨요.

README.md에는 세 줄이면 됩니다.

• 온보딩에서 입력한 내 역할 요약
• 비서가 제안한 반복 업무 후보
• 다음 클립에서 00-inbox/에 넣어볼 업무 파일

저는 여기까지 되면 workmate가 "받아서 쓰는 비서"에서 "내 책상에 앉은 비서"로 바뀌었다고 봅니다. 첫 대화가 너무 일반적이면 "내 직무를 더 반영해서 다시"라고 하면 됩니다.

🆘 자주 막히는 포인트

막히는 지점은 대부분 위치와 답변 구체성에서 나옵니다.

여전히 어색하면 저는 이렇게 묻습니다. "내가 매주 월요일 아침에 귀찮아하는 일이 뭐지?" 그 답이 온보딩의 좋은 재료예요.

🔗 다음 클립

→ Part 5 / Clip 2: PARA와 /inbox-sorter — 이제 개인화된 비서에게 받은 업무 파일을 던지고, 00-inbox/에서 자동 분류를 시켜봅니다.

오늘은 비서에게 여러분을 소개했습니다. 다음은 그 비서에게 책상 위 파일을 정리시키는 장면입니다. 사람 비서에게 처음 맡기는 일도 보통 파일 정리부터잖아요?

🎯 이 클립에서 만드는 것

여러분 책상 위에 파일이 쌓이는 건 게을러서가 아닙니다. 입구가 없어서 그래요. 어디에 넣어야 할지 애매하니까 다운로드 폴더, 카톡, 바탕화면, 메일 첨부파일에 흩어지는 거죠.

오늘은 workmate의 00-inbox/에 여러분 업무 파일 1~2개를 넣고 /inbox-sorter로 정리합니다. 비서가 파일 이름과 내용을 보고 어디로 옮길지 제안하고, 승인하면 PARA 구조 안으로 옮겨요.

저는 이 클립을 "비서에게 책상 정리 맡기는 첫날"이라고 봅니다. 분석이나 보고서보다 먼저 정리가 되는 이유가 있어요. 비서가 파일 위치를 알아야 다음 일을 이어서 할 수 있거든요.

결과물은 정리된 폴더 구조 스크린샷과 분류 결과 README.md입니다. 여러분이 파일을 몇 개만 넣어도, 이 구조가 왜 필요한지 바로 감이 올 거예요.

💡 핵심 개념

PARA는 파일을 "종류"가 아니라 "쓰임"으로 나누는 방식입니다. 파일 확장자가 PDF냐 엑셀이냐보다, 이 파일을 왜 가지고 있는지가 더 중요하다는 뜻이에요.

workmate는 PARA를 7개 폴더로 씁니다.

여기서 핵심은 00-inbox/입니다. 모든 파일의 첫 입구예요. 여러분이 파일을 받을 때마다 "이걸 어디 넣지?" 고민하지 말고 일단 inbox에 넣습니다. 그리고 /inbox-sorter에게 맡겨요.

/inbox-sorter는 파일을 무작정 옮기지 않습니다. 먼저 내용을 읽고 분류표를 제안합니다. 예를 들어 엑셀 파일이라도 원시 데이터면 data/, 보고용 결과물이면 reports/, 운영 양식이면 20-operations/에 가까울 수 있어요. 그래서 파일명만 보는 정리와 다릅니다.

저는 학생들에게 파일 1~2개만 넣으라고 말합니다. 처음부터 50개 넣으면 정리 실습이 아니라 대청소가 돼버려요. 여러분도 오늘은 작은 성공 하나만 만들면 됩니다.

🛠️ 시작 전 — 자료 셋업

먼저 결과 기록용 폴더를 만듭니다.

mkdir -p ~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습22-PARA정리/

그 다음 workmate의 inbox를 준비합니다.

cd ~/Desktop/workmate
mkdir -p 00-inbox

이제 여러분 본인 업무 파일 1~2개를 ~/Desktop/workmate/00-inbox/에 넣습니다. 너무 민감한 파일은 쓰지 마세요. 실습에서는 이름과 숫자를 익명화한 사본이 좋습니다.

좋은 예시는 이런 파일입니다.

• 지난주 회의록 .docx 또는 .md
• 캠페인 성과 .csv
• 프로젝트 기획서 .pdf
• 업무 메모 .txt
• 강의 정리 파일 .md

파일을 넣은 뒤 Claude Code를 ~/Desktop/workmate에서 실행합니다.

cd ~/Desktop/workmate
claude

여기까지 되면 책상 위에 정리할 물건을 올려둔 상태입니다.

🚶 진행 흐름

1. inbox 안 파일 확인하기

먼저 비서에게 inbox를 보라고 합니다. 파일이 정말 들어갔는지 확인하는 단계예요.

00-inbox/ 안에 들어 있는 파일 목록을 확인해 주세요. 숨김파일이나 임시파일은 무시하고, 정리 대상만 보여 주세요. 아직 이동하지 마세요.

여기서 파일이 안 보이면 Finder에서 다른 폴더에 넣은 겁니다. ~/Desktop/workmate/00-inbox/ 위치를 다시 확인하면 돼요.

2. /inbox-sorter 실행하기

이제 자동 분류를 시작합니다.

/inbox-sorter

비서는 파일을 읽고 목적지를 제안합니다. 저는 여기서 바로 승인하지 말고 한 번 읽어보라고 합니다. "왜 이 폴더로 가는지"가 보여야 다음부터 여러분도 감을 잡습니다.

분류표에서 각 파일의 목적지와 이유를 한 줄씩 다시 설명해 주세요. 제가 승인하기 전까지 실제 이동은 하지 마세요.

3. 분류 승인하기

분류가 맞으면 승인합니다. 애매한 항목이 있으면 목적지를 바꿔도 됩니다.

분류표를 승인합니다. 제안한 목적지로 파일을 이동하고, 이동 결과를 요약해 주세요.

여기서 중요한 건 비서에게 완전히 맡기되, 최종 결정은 여러분이 한다는 점입니다. workmate 원칙도 같습니다. 판단은 도와주지만 결정은 사람이 해요.

4. 폴더 구조 캡처하기

이동이 끝나면 ~/Desktop/workmate 폴더를 Finder에서 열고, 00-inbox/, 10-projects/, 20-operations/, 30-knowledge/, 40-personal/, 50-resources/, 90-archive/가 보이게 캡처합니다.

파일이 이동된 폴더도 함께 보이면 더 좋습니다. 캡처 파일은 결과 폴더에 PARA-정리후-폴더구조.png로 저장하세요.

5. 분류 결과 README 만들기

마지막은 기록입니다. 파일이 어디로 갔는지 남겨야 나중에 찾을 수 있어요.

방금 /inbox-sorter로 정리한 결과를 ~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습22-PARA정리/README.md에 정리해 주세요. 원래 파일명, 이동한 폴더, 분류 이유, 다음에 할 일을 포함해 주세요.

저는 이 README를 "정리 영수증"이라고 부릅니다. 파일이 사라진 게 아니라 제자리를 찾았다는 증거니까요.

📦 결과물

저장 위치는 50-my-work/Part05-에이전트구축/실습22-PARA정리/입니다.

실습22-PARA정리/
├── PARA-정리후-폴더구조.png
└── README.md

실제 파일은 ~/Desktop/workmate/ 안의 PARA 폴더로 이동됩니다.

workmate/
├── 00-inbox/
├── 10-projects/
├── 20-operations/
├── 30-knowledge/
├── 40-personal/
├── 50-resources/
└── 90-archive/

README.md에는 분류 결과가 들어갑니다. 예를 들어 캠페인성과.csv → data/, 회의록.md → 20-operations/, 포트폴리오참고.pdf → 50-resources/처럼요. 여러분이 다음 클립에서 반복 업무를 만들 때도 이 정리된 파일들이 재료가 됩니다.

🆘 자주 막히는 포인트

처음 자동 정리를 시키면 약간 불안합니다. 괜찮아요. 승인 전에는 확인할 수 있습니다.

여전히 애매하면 "이 파일을 다음에 왜 다시 열까?"라고 물어보세요. 그 답이 폴더를 정합니다.

🔗 다음 클립

→ Part 5 / Clip 3: 메모리와 스킬 자가성장 — 이제 정리된 파일로 반복 업무를 세 번 해보고, workmate가 스킬 후보를 잡아내는 장면을 봅니다.

오늘은 비서에게 책상 정리를 맡겼습니다. 다음은 더 재미있어요. 같은 일을 반복했더니 비서가 "이거 매번 하시네요. 스킬로 만들까요?"라고 물어보는 순간입니다.

🎯 이 클립에서 만드는 것

여러분, 좋은 비서는 시킨 일만 하는 사람이 아닙니다. "이 일 매주 하시네요?" 하고 먼저 알아차리는 사람이죠. workmate도 반복 업무를 그냥 흘려보내지 않고 스킬 후보로 모읍니다.

이번 클립에서는 같은 유형의 작업을 3회 반복합니다. 그리고 SessionEnd 훅 또는 수동 /wrap으로 마무리하면서 .claude/skills/_candidates/pending.json에 후보가 생기는 흐름을 확인해요. 승인하면 skillers-suda로 정식 스킬까지 승격합니다.

저는 이걸 workmate의 자가성장이라고 부릅니다. 매번 길게 시키던 일을, 비서가 이름 붙은 능력으로 바꿔가는 과정이에요.

결과물은 자가성장으로 만든 스킬 1개입니다. 스킬 이름과 SKILL.md 위치를 결과 폴더 README에 남깁니다.

💡 핵심 개념

workmate의 기억은 한 군데가 아닙니다. 세 갈래로 나뉘어 있어요. 저는 "장기 기억, 오늘 일지, 임시 주머니"라고 설명합니다.

여기에 스킬 후보 저장소가 붙습니다.

.claude/skills/_candidates/pending.json

같은 작업이 1~2회 보이면 workmate는 조용히 관찰합니다. 바로 "스킬 만들까요?"라고 튀어나오지 않아요. 3회 이상 반복되거나 여러분이 "이거 매번 반복해", "자동화해줘"라고 말하면 후보로 올라옵니다. 한 번 해본 일을 모두 스킬로 만들면 도구함이 금방 어질러지거든요.

승격 흐름은 이렇게 봅니다.

같은 작업 3회 반복
        ↓
SessionEnd 훅 또는 /wrap
        ↓
_candidates/pending.json에 후보 저장
        ↓
다음 세션 시작 시 제안
        ↓
사용자 승인
        ↓
skillers-suda로 정식 스킬 생성
        ↓
.claude/skills/{스킬명}/SKILL.md

Part 4 / Clip 6에서 여러분은 skillers-suda로 직접 스킬을 설계했습니다. 오늘은 실제로 반복한 업무에서 후보가 올라옵니다. 비서가 여러분 습관을 보고 도구를 제안하는 거예요.

🛠️ 시작 전 — 자료 셋업

먼저 결과 기록용 폴더를 만듭니다.

mkdir -p ~/Desktop/bptc-cc/50-my-work/Part05-에이전트구축/실습23-자가성장/

그 다음 workmate에서 Claude Code를 엽니다.

cd ~/Desktop/workmate
claude

오늘은 같은 작업을 3회 반복해야 합니다. 너무 큰 업무 말고, 여러분이 실제로 자주 하는 작은 일을 고르세요.

좋은 후보는 이런 일입니다.

• 회의록에서 액션 아이템 뽑기
• CSV 요약 후 보고 문장 만들기
• 메일 초안을 짧고 공손하게 다듬기
• 주간 업무 메모를 팀장 보고용으로 바꾸기
• 강의 노트를 README로 정리하기

중요한 건 "파일은 달라도 절차가 같다"는 점입니다. 저는 실습에서는 주간 업무 메모 → 보고용 요약처럼 작고 반복적인 일을 추천합니다.

🚶 진행 흐름

1. 반복 업무 하나 고르기

먼저 오늘 관찰할 작업을 선언합니다.

오늘은 "주간 업무 메모를 팀장 보고용 요약으로 바꾸는 작업"을 반복해 보겠습니다. 이 작업은 제가 매번 반복하는 업무입니다. 입력, 처리 단계, 결과물 형식을 관찰해 주세요. 아직 스킬은 만들지 마세요.

여러분 업무에 맞게 따옴표 안만 바꾸면 됩니다. "회의록에서 액션 아이템 뽑기"도 좋고, "광고 성과 CSV를 5줄로 요약하기"도 좋아요.

2. 같은 작업을 1회 실행하기

첫 번째 입력을 줍니다. 결과가 마음에 들면, 어떤 형식이 좋았는지도 말해줍니다.

첫 번째 입력입니다. @00-inbox/week1-note.md를 읽고 팀장에게 보낼 보고용 요약으로 바꿔 주세요. 형식은 1) 이번 주 한 줄 요약, 2) 완료한 일, 3) 이슈, 4) 다음 액션으로 해 주세요.

이 단계에서는 "좋았다"로 끝내지 말고, 좋은 형식을 확인해 주세요.

방금 결과 형식이 좋습니다. 다음에도 같은 형식으로 반복할 수 있게 기억해 주세요.

3. 2회, 3회 반복하기

파일이나 내용만 바꿔 같은 작업을 반복합니다.

두 번째 입력입니다. @00-inbox/week2-note.md도 같은 방식으로 팀장 보고용 요약을 만들어 주세요. 이전과 같은 형식을 유지해 주세요.

세 번째 입력입니다. @00-inbox/week3-note.md도 같은 방식으로 처리해 주세요. 이 작업이 반복 업무 후보인지 확인해 주세요.

여러분이 실제 파일을 준비하지 않았다면 짧은 샘플 텍스트를 붙여도 됩니다. 다만 세 번 모두 "같은 절차"라는 점은 분명해야 해요.

4. /wrap으로 후보 저장 확인하기

세 번 반복했다면 세션을 마무리합니다. 자동 SessionEnd 훅을 기다려도 되지만, 강의에서는 눈으로 보기 위해 /wrap을 쓰는 편이 좋습니다.

/wrap

그 다음 후보 파일을 확인합니다.

.claude/skills/_candidates/pending.json을 확인해 주세요. 방금 반복한 업무가 스킬 후보로 잡혔는지, 이름과 trigger, count, status를 요약해 주세요.

후보가 바로 안 보이면 당황하지 마세요. workmate는 1~2회 관찰 단계에서는 조용히 둘 수 있습니다. 세 번 반복했다는 문장을 명시했는지 확인하면 돼요.

5. 다음 세션에서 정식 스킬로 승격하기

Claude Code를 종료했다가 다시 ~/Desktop/workmate에서 엽니다.

cd ~/Desktop/workmate
claude

후보가 뜨면 승인합니다.

네, 이 반복 업무를 정식 스킬로 만들어 주세요. skillers-suda를 사용해서 스킬 이름, 트리거 문장, 입력 자료, 진행 단계, 결과물, 실패했을 때 처리 방법이 들어간 SKILL.md로 승격해 주세요.

완료 후 위치를 확인합니다.

생성된 스킬 이름과 SKILL.md 위치를 알려 주세요. 그리고 SKILLS_INDEX.md에 새 스킬이 등록됐는지도 확인해 주세요.

생성 위치는 보통 이런 형태입니다.

~/Desktop/workmate/.claude/skills/{스킬명}/SKILL.md

📦 결과물

저장 위치는 50-my-work/Part05-에이전트구축/실습23-자가성장/입니다.

실습23-자가성장/
├── 01-repeat-log.md
├── 02-skill-candidate.md
└── README.md

실제 스킬은 workmate 안에 생깁니다.

~/Desktop/workmate/.claude/skills/{스킬명}/
└── SKILL.md

01-repeat-log.md에는 3회 반복 기록을 남깁니다. 02-skill-candidate.md에는 후보 이름, trigger, count, status를 적습니다. README.md에는 최종 스킬 이름과 SKILL.md 위치를 적으면 됩니다.

저는 결과물에서 "어떤 반복이 왜 스킬이 됐는지"를 더 봅니다. 여러분도 다음부터 어떤 한 문장으로 부를 수 있는지 꼭 적어두세요.

🆘 자주 막히는 포인트

자가성장은 멋있게 들리지만, 실제로는 반복의 모양을 잘 보여주는 게 전부입니다.

저는 후보가 안 잡힐 때 이렇게 말합니다. "내가 방금 한 세 번의 작업에서 공통 절차를 찾아서 스킬 후보로 정리해줘." 비서에게 반복을 보이게 해주는 문장이죠.

🔗 다음 클립

여기까지가 Part 5입니다. 워크스페이스 개념을 잡고, 받아쓰는 비서(workmate)를 개인화하고, PARA로 자료를 정리하고, 메모리와 자가성장까지 — 내 업무 비서를 직접 만들어 봤어요.

→ Part 6 / Clip 1: 컨텍스트 관리 — 다음 Part부터는 클로드코드를 더 깊이 다룹니다. 먼저 길어진 대화를 /clear·/compact·/rewind로 갈무리하는 법부터 시작해요.

🎯 이 클립에서 만드는 것

이번 클립은 파일을 만들지 않습니다. 대신 대화창 자체를 다루는 3가지 슬래시 커맨드를 손에 익혀요. "정보가 많을수록 좋다"는 흔한 오해를 푸는 부분이기도 합니다.

비유 하나. 잘 모르는 동료한테 회사 매뉴얼 1000장을 통째로 던집니다. 어떤 게 중요한지 모르죠. AI도 똑같아요. 100개를 한꺼번에 던지면 다 보긴 하지만 중요한 게 뭔지가 흐려져요. 저는 이걸 "정보 과적재"라고 불러요. 대화창에는 지금 일에 필요한 것만 남겨두는 게 좋아요.

이 3개만 손에 익으면 한 세션을 길게, 그리고 깔끔하게 끌고 갈 수 있습니다.

💡 핵심 개념

"컨텍스트" = AI에게 한 번에 주는 정보 묶음

화면에 쌓인 메시지 · 첨부 파일 · 도구 호출 결과까지 전부 컨텍스트예요. AI는 답할 때 이 묶음 전체를 한 번에 봅니다.

여기서 자주 헷갈려요. 묶음이 길어질수록 토큰이 늘어나고, 중요한 단서가 묻힙니다. 100을 한꺼번에 던지면 100을 다 보긴 하지만, 중요한 게 뭔지가 흐려져요. 우리 일도 똑같죠? 회의 자료가 너무 두꺼우면 결정이 안 납니다.

/clear — 새 주제로 갈 때

/clear

대화창의 컨텍스트를 완전히 비웁니다. 이전 작업이 끝나고 다른 주제로 갈 때 가장 먼저 누르는 키예요.

예시:

• 보고서 작업 끝 → /clear → 새 카드뉴스 작업 시작
• 디버깅 끝 → /clear → 새 기능 기획

쓰지 않으면 어떻게 되나요? 이전 작업의 맥락이 다음 작업에 묻어옵니다. "아까 그 보고서 톤으로" 같은 식으로요. 의도한 게 아니면 결과가 묘하게 흐려집니다.

/compact — 같은 작업이 길어질 때

/compact

지금까지의 대화를 AI가 요약하고, 그 요약본을 들고 이어갑니다. 같은 작업이 1시간 넘게 길어질 때 써요.

예시:

• 워크스페이스 빌딩 중 30번 넘게 주고받음 → /compact → 핵심만 남기고 계속
• 코드 리뷰 한 PR을 깊게 파고듦 → /compact → 주요 결정만 들고 이어서

/clear와 차이는 명확합니다. /clear는 비우고, /compact는 압축해서 들고 갑니다.

/rewind 또는 ESC 두 번 — 잘못된 방향으로 갔을 때

/rewind

이전 단계로 돌아갑니다. /clear처럼 전부 지우는 게 아니라, AI의 응답 한두 개만 무르는 거예요. 키보드 ESC를 두 번 눌러도 똑같이 작동합니다.

예시:

• AI가 엉뚱한 방향으로 코드 짜기 시작함 → ESC ESC → 다시 지시
• 잘못된 파일을 수정함 → /rewind → 다른 파일에서 다시

이 세 가지를 손에 익히면 대화창이 깔끔하게 유지돼요. 오래 쓸수록 차이가 나요.

🚶 진행 흐름

1. 대화창에 직접 한 줄씩 입력해 보세요

설치할 것은 없습니다. 클로드코드 안에서 그냥 슬래시(/)를 누르면 커맨드 자동완성이 뜹니다. 위 3개를 차례로 눌러보세요.

/clear

/compact

/rewind

세 번 다 해 보시면 화면이 어떻게 바뀌는지 감이 옵니다.

2. "내 평소 사용 패턴"을 한 줄로 적어보세요

평소에 한 번 세션을 얼마나 길게 쓰시나요? 한 주제로만 이어가시나요, 아니면 중간에 다른 일이 끼시나요?

my-context-pattern.md라는 메모를 하나 만들어 적어보세요.

# 내 컨텍스트 사용 패턴

- 평소 세션 길이: __분 / __개 메시지
- 자주 끼는 다른 일: __
- /clear를 누를 만한 시점: __
- /compact를 누를 만한 시점: __
- /rewind를 쓸 만한 실수 유형: __

길게 안 적어도 됩니다. 3분이면 끝나요.

3. 이번 주 안에 한 번씩만 써 보세요

처음 일주일은 3개 다 손에 안 익습니다. 그래서 목표를 작게 잡아요. "한 번씩만 써 본다." 그 정도면 충분합니다.

4. 막혔을 때 ESC를 떠올리세요

키보드 ESC 두 번 — 이게 의외로 빠릅니다. 다음 클립부터는 이걸 실제 작업 흐름에 끼워 넣는 방법까지 다룹니다.

📦 결과물

• my-context-pattern.md 메모 1장 (3분이면 충분)
• 3개 커맨드를 직접 입력해 본 경험

파일이 거창하지 않아도 됩니다. 실제로 한 번 눌러봤다 — 이 한 줄이 이번 클립의 전부예요.

🆘 자주 막히는 포인트

/compact를 누르면 이전 정보가 사라지나요?

아니요. AI가 요약본으로 변환해서 들고 갑니다. 핵심 결정·중간 산출물은 남고, 잡담·반복 확인 같은 부수적인 메시지가 압축됩니다.

/clear를 잘못 눌렀어요. 복구되나요?

새 세션이 시작된 후에는 이전 내용으로 돌아가기 어렵습니다. 중요한 결과물은 항상 파일로 저장하고 클리어하세요. 메시지에만 떠 있는 내용은 잃기 쉽습니다.

/rewind는 몇 단계까지 돌아갈 수 있나요?

여러 단계 돌아갈 수 있지만 깊게 갈수록 컨텍스트가 흔들립니다. 보통은 한두 단계만 돌리는 게 안전합니다. 그 이상 가야 할 만큼 어그러졌다면 /clear 후 다시 시작하는 게 더 빠릅니다.

3개 다 안 외워져요

/clear 하나만 익혀도 됩니다. 새 주제 시작할 때마다 한 번씩. 나머지 둘은 자연스럽게 필요해질 때 손이 가게 돼요.

🔗 다음 클립

다음은 하네스 엔지니어링입니다. 컨텍스트가 "대화 한 번에 주는 정보"라면, 하네스는 "매 세션 자동으로 따라오는 환경"이에요. CLAUDE.md · rules · skills · MCP를 한 번 잘 적어두면 그다음부터는 알아서 쓰입니다.

→ Part 6 / Clip 2: 하네스 엔지니어링

🎯 이 클립에서 만드는 것

이번 클립에서는 개념 한 장만 잡고 갑니다. AI 일이 잘 풀리려면 모델만 좋다고 되는 게 아니에요. AI를 둘러싸는 환경 — 이게 영어로 "harness(하네스)" 입니다.

비유는 단순합니다. 잘 정리된 회사 인수인계 문서가 있는 회사를 떠올려보세요. 신입이 와도 같은 결과가 나옵니다. 매번 새로 설명할 필요가 없죠. 하네스가 그 역할이에요. 한 번 잘 적어두면 매 세션 자동으로 쓰입니다.

이번 클립이 끝나면 여러분은 "내 워크스페이스에 무엇을 넣어야 하는지" 한 표로 들고 갑니다. 실제 만드는 것은 다음 클립(Part 6 / Clip 3)에서 시작해요.

💡 핵심 개념

하네스 = AI 작업을 둘러싸는 모든 환경

용어가 낯설 수 있어요. 정의는 생각보다 단순해요.

하네스 = 매 세션 자동으로 따라가는 환경 한 묶음
       = 지침 + 규칙 + 도구 + 환경 + 레퍼런스

신입에게 회사 매뉴얼을 매번 슬랙으로 다시 보내지는 않잖아요. Notion에 한 번 잘 정리해 두면 끝이죠. 하네스도 같은 결입니다.

워크스페이스에 들어갈 것 — 6가지

클로드코드는 워크스페이스(폴더) 안에 둔 파일을 자동으로 읽고 작업에 써요. 우리가 채워야 할 건 다음 6가지예요.

처음 보면 많아 보이지만, CLAUDE.md 한 장부터 시작하면 됩니다. 나머지는 일하다 필요해질 때 늘려가요.

CLAUDE.md 5블록 — 시작은 이거 하나만

CLAUDE.md는 워크스페이스의 "뇌"입니다. 다섯 블록이면 충분해요.

# 정체성
이 워크스페이스는 무엇을 위한 곳인지 한 문장.

# 일하는 원칙
3~5줄. 톤·기준·금지사항.

# 도구
어떤 MCP·CLI·외부 도구를 쓰는지.

# 산출물
이 워크스페이스에서 나오는 결과물의 정의·기준.

# 답변 원칙
출력 형식·길이·언어.

이 5블록만 잘 적어둬도 AI가 매 세션 일관성 있게 따라옵니다.

rules vs skills 차이

자주 헷갈리는 부분이라 여기서 한 번만 잡고 갑니다.

규칙은 항상, 스킬은 필요할 때. 그래서 자주 쓰는 작업 절차는 skill로 빼두면 평소 토큰을 아낄 수 있어요.

settings · MCP — 도구 vs 환경

도구    = MCP · CLI · Skills (직접 호출해서 쓰는 것)
환경    = settings.json · CLAUDE.local.md (자동으로 적용되는 것)

설정 파일들은 자동으로 먹힙니다. 권한 모드, 어떤 모델을 쓸지, hook 등이 settings.json에 들어가요. MCP는 외부 서비스(수파베이스·플레이라이트·노션 등) 연결입니다.

🚶 진행 흐름

1. "하네스 = 인수인계 문서" 비유를 한 번 자기 말로 풀어보세요

옆사람한테 (또는 노트에) 한 줄로 설명해 보세요.

하네스가 뭐냐고 누가 물으면 나는 ___________ 라고 답한다.

용어를 외우는 게 아니라 자기 비유로 잡는 게 중요합니다.

2. 6가지 항목을 표로 옮겨 적으세요

위 표를 그대로 베끼지 말고, 내 업무 기준으로 한 줄씩 적어보세요.

# 내 워크스페이스에 들어갈 것 (초안)

| 파일 · 폴더 | 내 업무에서 뭘 넣을까 |
|---|---|
| CLAUDE.md | __ 비서 정체성 한 문장 |
| .claude/rules/ | __ 규칙 (예: 답변은 항상 한국어, 출처 표기) |
| .claude/skills/ | __ 반복 절차 (예: 주간 보고서 작성) |
| CLAUDE.local.md | __ 메모 |
| .claude/settings.json | (기본 그대로) |
| .mcp.json | __ MCP (예: 수파베이스 연결 예정) |

다 채울 필요 없어요. 빈 줄이 있어도 됩니다. 오히려 빈 칸이 "내가 뭘 모르는지" 알려줍니다.

3. CLAUDE.md 5블록을 머릿속으로 한 번 채워보세요

종이에 적든 머릿속에서 하든, 5블록을 내 업무로 채워보세요.

# 정체성
나의 ___________ 비서

# 일하는 원칙
1. ___________
2. ___________
3. ___________

# 도구
___________

# 산출물
___________

# 답변 원칙
___________

이게 다음 클립의 출발점입니다.

4. 다음 클립으로 — 실제 폴더를 만들 준비

이번 클립은 개념 한 장이 목적이었어요. 다음 클립(Part 6 / Clip 3)에서 실제 폴더 구조를 만들고, 그다음 클립(6-04)에서 PRD + 골잡이로 자동 빌딩까지 갑니다.

📦 결과물

• "하네스 = ___" 본인 비유 한 줄
• "내 워크스페이스에 들어갈 것" 초안 표 1장 (빈 칸 있어도 OK)
• CLAUDE.md 5블록 머릿속 초안

파일 1~2장이면 충분합니다. 개념을 손에 쥐고 다음 클립으로 가는 것이 이번 목표예요.

🆘 자주 막히는 포인트

6가지 다 만들어야 하나요?

아니요. CLAUDE.md 한 장부터 시작합니다. 나머지는 일하다 필요해질 때 늘리세요. 처음부터 6개 다 채우려고 하면 일주일 걸려요.

CLAUDE.md를 어디에 둬야 하나요?

워크스페이스 폴더의 루트에 둡니다. 예: ~/my-workspace/CLAUDE.md. 클로드코드를 그 폴더에서 실행하면 자동으로 읽어요.

CLAUDE.md와 CLAUDE.local.md 차이는?

CLAUDE.md는 팀에 공유되는 본체, CLAUDE.local.md는 나만 보는 메모입니다. local은 gitignore에 들어가서 팀에 안 보여요. 개인 키 메모, 임시 노트는 local에.

rules와 CLAUDE.md "일하는 원칙" 차이는?

• CLAUDE.md "일하는 원칙": 워크스페이스 전체에 적용되는 큰 원칙 (3~5개)
• rules/*.md: 주제별 세부 규칙 (예: code-style.md, tone-and-manner.md)

규칙이 5개 이상으로 늘어나면 rules로 빼세요.

MCP는 꼭 설정해야 하나요?

아니요. 외부 도구가 필요할 때만 추가합니다. 처음에는 비워두고 시작하세요. 수파베이스·노션 같은 게 필요해질 때 그때 추가하면 됩니다.

🔗 다음 클립

다음은 워크스페이스 빌딩 — 폴더 구조입니다. 이번 클립에서 표로 정리한 6가지를 실제 폴더와 파일로 만듭니다. CLAUDE.md를 5블록으로 채우고, rules·skills 폴더를 만들어요.

→ Part 6 / Clip 3: 워크스페이스 빌딩 — 폴더 구조

🎯 이 클립에서 만드는 것

지난 클립에서 표로 잡았던 6가지 항목 기억나시죠. 이번에는 그걸 실제 폴더와 파일로 만들어봅니다. 15분 동안 내 책상 위에 작은 사무실 하나 차리는 거예요.

순서는 이걸 추천해요. 폴더 → CLAUDE.md 5블록 → 필요한 rules · skills 채우기 → 마지막 확인. 처음부터 6가지 다 만들지 않습니다. 일이 굴러가다 보면 어디가 비어 있는지 자연스럽게 보이거든요.

5블록 초안만 잡혀도 이번 시간은 성공입니다.

💡 핵심 개념

폴더 구조 — 빌딩 블록처럼 쌓는다

폴더는 단순합니다. 루트 + 숨김 폴더 두 개 + 일하는 폴더 몇 개.

my-workspace/
├── CLAUDE.md                ← 워크스페이스의 뇌
├── .claude/                 ← 클로드코드 전용
│   ├── rules/               ← 주제별 규칙 (옵션)
│   ├── skills/              ← 반복 절차 (옵션)
│   └── settings.json        ← 권한·모델·hook (옵션)
├── .mcp.json                ← 외부 도구 연결 (옵션)
├── CLAUDE.local.md          ← 나만 보는 메모 (옵션, gitignore)
├── 00-system/               ← 공용 자산
├── 10-자료/                 ← 들어온 자료
├── 20-산출물/               ← 완성된 결과물
└── 30-진행중/               ← 진행 중인 작업

번호 접두사(00-, 10-, 20-)는 정렬 때문이에요. 알파벳 순으로 자연스럽게 줄을 섭니다. 더 늘릴 때는 15-자료-아카이브 식으로 사이에 끼우면 되고요.

CLAUDE.md 5블록 — 한 페이지 안에 다 들어간다

CLAUDE.md 한 장이 워크스페이스의 뇌입니다. 다섯 블록이면 충분해요. 처음 쓸 때는 한 줄씩만 채우세요. 일하다 보면 늘어납니다.

# 정체성
__를 위한 워크스페이스. __ 비서 역할.

# 일하는 원칙
1. 한국어로 답한다.
2. 출처 표기 — 수치·사례는 출처 또는 등급(A~D).
3. 추측성 표현 금지 — 모르면 "확인 필요" 명시.

# 도구
- Playwright MCP — 웹 자동화
- 수파베이스 MCP — DB 연결
- (필요할 때 추가)

# 산출물
- 보고서: `20-산출물/보고서/{YYYY-MM-DD}_제목.md`
- 슬라이드: `20-산출물/슬라이드/`
- 답변 톤: 비즈니스 한국어, 존댓말

# 답변 원칙
- 짧고 명확하게.
- 옵션이 둘 이상일 때는 표로.
- 명령형보다 권장형 ("~하시면 됩니다").

이걸 워크스페이스 루트에 저장하고 클로드코드를 그 폴더에서 열면 자동으로 읽어요.

rules vs skills — 항상 vs 필요할 때

항상 따라야 하는 짧은 규칙은 rules에. 자주 쓰는 작업 절차는 skill에. 처음에는 rules 1~2개로 시작하고, 같은 작업을 세 번 이상 반복하면 그때 skill로 빼면 됩니다.

settings.json · MCP — 자동 환경

이 두 파일은 따로 부르지 않아도 알아서 먹혀요.

• .claude/settings.json — 권한 모드, 기본 모델, hook
• .mcp.json — 외부 도구 연결 (Playwright, 수파베이스, 노션 등)

처음 워크스페이스를 만들 때는 둘 다 비워둬도 괜찮습니다. 권한 모드가 필요해지면 그때 settings, 외부 서비스 연결이 필요해지면 그때 MCP를 추가하세요.

🚶 진행 흐름

1. 폴더 만들기 — 1분

터미널 한 줄로 끝납니다. 내 워크스페이스 이름으로 바꿔서 돌리세요.

mkdir -p my-workspace/{.claude/{rules,skills},00-system,10-자료,20-산출물,30-진행중}
cd my-workspace

윈도우는 PowerShell이나 탐색기에서 같은 구조로 만드시면 됩니다.

2. CLAUDE.md 5블록 초안 — 7분

위 템플릿을 복사해서 내 업무로 채워보세요. 한 줄씩만요. 막힌 블록은 비워둬도 됩니다. 비어 있는 게 보이는 자체가 다음 작업거리예요.

저는 처음 만들 때 "정체성"이 가장 어려웠어요. "뭘 위한 곳인가" 한 문장으로 정하기가 의외로 시간이 듭니다. 일단 거칠게 한 줄 쓰고 시작하세요. 나중에 다듬으면 됩니다.

3. rules 한두 장 — 3분

처음에는 두 개면 충분합니다.

.claude/rules/
├── tone.md           ← 톤앤매너 (존댓말, 어휘, 금지표현)
└── output-format.md  ← 답변 형식 (길이, 표 사용 기준)

각 파일은 5~10줄짜리 짧은 markdown입니다. 길게 안 적어도 돼요. 평소에 "AI가 자꾸 이렇게 하던데 안 했으면" 싶었던 것을 한 줄씩 적으면 됩니다.

4. 마지막 확인 — 4분

다른 PC에서 같은 폴더를 클론하고 클로드코드를 열어보세요. 비슷하게 읽히는지만 보면 됩니다. 못 가져갈 부분(개인 API 키, 로컬 경로 등)은 CLAUDE.local.md로 분리하시고요.

마지막 체크리스트:

• 다른 사람이 봐도 "여기가 뭐 하는 곳인지" 한 줄로 보이는가
• .gitignore에 CLAUDE.local.md, .env, node_modules 등이 들어 있는가
• 외부 서비스 키가 코드에 노출되어 있지 않은가
• 산출물 폴더 경로가 일관적인가

📦 결과물

• my-workspace/ 폴더 1개
• CLAUDE.md 5블록 초안 (1장)
• .claude/rules/*.md 1~2장
• (선택) CLAUDE.local.md 메모

15분 안에 위 4가지가 손에 잡히면 이번 클립 통과입니다. 완벽하지 않아도 됩니다. 굴러가는 초안 한 벌이 다음 클립의 출발점이에요.

🆘 자주 막히는 포인트

.claude 폴더가 왜 숨김인가요?

. 으로 시작하는 폴더·파일은 macOS·Linux에서 숨김 처리됩니다. 클로드코드가 자동으로 읽지만 평소 파일 탐색기에서는 안 보여요. 보려면 Finder에서 Cmd + Shift + . (윈도우 탐색기는 "숨김 항목" 체크).

CLAUDE.md를 어디까지 자세히 적어야 하나요?

한 화면에 다 보이는 분량(약 50~100줄)이 적정해요. 그 이상으로 늘어나면 rules로 빼는 신호입니다. CLAUDE.md는 "뇌의 큰 그림", rules는 "주제별 세부 규칙" — 이렇게 분리하면 깔끔합니다.

폴더 번호 (00-, 10-, 20-)는 꼭 써야 하나요?

아니요. 내 정리 습관에 맞으면 그대로 두세요. 번호를 붙이면 정렬·확장이 편하다는 장점이 있는데, 한글 폴더명만으로도 충분합니다.

5블록 중 일부가 안 채워져요

비워두세요. 7분 안에 다 채우려고 하면 부정확한 내용이 들어갑니다. 빈 블록은 다음 작업에서 자연스럽게 채워져요. 지금은 골격만 잡히면 돼요.

워크스페이스를 여러 개 만들어도 되나요?

나누는 편이 좋아요. "업무 비서용", "개인 학습용", "사이드 프로젝트용" 식으로 목적별로 분리하세요. CLAUDE.md가 각 워크스페이스의 정체성을 잡아주기 때문에 섞이지 않습니다.

🔗 다음 클립

폴더와 CLAUDE.md를 직접 짰는데, 사실 이 과정을 AI가 도와줄 수 있어요. 다음 클립에서는 PRD + 골잡이로 워크스페이스 빌딩 자체를 자동화합니다. 정의 한 줄만 적으면 PRD부터 폴더·CLAUDE.md 초안까지 AI가 만들어줘요.

→ Part 6 / Clip 4: PRD + 골잡이로 자동 빌딩

🎯 이 클립에서 만드는 것

지난 클립에서는 손으로 폴더와 CLAUDE.md를 짰습니다. 이번에는 같은 일을 AI에게 맡겨봅니다. 사람이 정하는 건 딱 두 가지 — 정의 한 줄과 PRD. 그다음부터는 골잡이가 받아서 굴립니다.

이 흐름의 핵심은 한 문장이에요. "사람은 정의만 하고, 나머지는 AI가 빌딩한다." 손으로 짜든 AI가 짜든 결과는 비슷합니다. 차이는 시간이에요. 손으로 30분 걸리던 게 5분으로 줄어듭니다.

이 흐름에서는 사람이 많이 쓰지 않아도 돼요. 방향만 또렷하면 나머지는 AI가 채웁니다.

💡 핵심 개념

PRD = Product Requirements Document

이름이 어렵게 들리는데, 정의는 단순합니다. 이 워크스페이스가 무엇을 위해 존재하는지 한 페이지로 정리한 문서예요. 목적·타겟·핵심 메시지·산출물·도구를 묶어 둡니다.

PRD가 잘 잡혀 있으면 다음 단계가 빨라져요. AI는 PRD를 보고 폴더 구조·CLAUDE.md 5블록·rules·skills 후보까지 거꾸로 풀어냅니다.

/show-me-the-prd — PRD 자동 생성

GPTaku 플러그인의 슬래시 커맨드입니다. 인터뷰 방식으로 PRD를 만들어요.

/show-me-the-prd

질문이 5~7개 정도 쏟아져요. 답은 짧게 하세요. 한 답에 한 줄이면 충분합니다. 인터뷰가 끝나면 다음 4가지가 만들어져요.

• PRD.md — 핵심 명세 한 페이지
• data-model.md — 데이터 모델 (필요한 경우)
• phase.md — 단계별 진행 계획
• project-spec.md — 프로젝트 명세

이 4종 세트가 다음 단계의 입력이 됩니다.

/goaljaby — 골 세팅 (목표 + 검증 + 복구)

GPTaku 플러그인의 두 번째 커맨드예요. PRD를 받아 5가지 문서를 자동으로 만듭니다.

/goaljaby

이 5종이 있으면 AI가 혼자 일을 굴리기 시작해요. 사람은 PROGRESS만 가끔 보면 돼요.

/goal — 자율 실행

마지막 커맨드입니다.

/goal

AI가 PLAN을 따라 워크스페이스를 짜기 시작해요. 폴더를 만들고, CLAUDE.md를 채우고, rules를 작성하고, 필요하면 첫 결과물 초안까지 만듭니다. 사람은 콘솔만 보고 있으면 돼요.

중간에 결정이 필요한 지점에서 AI가 멈춥니다. 그때만 한 줄로 답해주시면 됩니다. 보통은 3~4번 멈춰요.

사람은 정의만 — 5단계 흐름

정의 한 줄 (사람)
   ↓
PRD 4종 (AI 자동, 사람은 답만)
   ↓
goaljaby 5종 (AI 자동)
   ↓
goal 실행 (AI 자율)
   ↓
초안 완성 → 사람 검토 → 본격 작업

처음 한 번만 이 흐름을 타보면 다음부터는 5분 안에 감이 와요.

🚶 진행 흐름

1. 정의 한 줄 — 30초

비어 있는 폴더에서 시작합니다. 한 줄을 머릿속에 정하세요.

"___을 위한 워크스페이스. ___ 만드는 곳."

예시:

• "주간 보고서 자동화 워크스페이스. 영업팀 KPI 자료 만드는 곳."
• "포트폴리오 사이트 워크스페이스. 개인 브랜드 페이지 만드는 곳."

2. /show-me-the-prd 실행 — 5분

클로드코드 안에서 슬래시 커맨드를 입력하세요.

/show-me-the-prd 주간 보고서 자동화 워크스페이스

질문이 뜹니다. 짧게 답하세요. 답에 자신 없으면 "잘 모르겠어요"라고 해도 됩니다. AI가 옵션을 제안해줘요.

인터뷰가 끝나면 PRD 4종이 폴더에 생깁니다. 한번 열어보세요. 내 답이 어떻게 문서가 됐는지 보면 다음 단계가 덜 불안해요.

3. /goaljaby 실행 — 1분

/goaljaby

PRD를 자동으로 읽고 5종 문서를 만들어요. 사람은 기다리기만 하면 됩니다.

4. /goal 실행 — 5분

/goal

AI가 일을 시작해요. 폴더가 늘어나고 파일이 채워져요. 중간에 결정이 필요하면 멈춥니다. 그때만 답하세요.

5. 한 번 훑기 — 3분

초안이 완성되면 한 번 훑어보세요.

• CLAUDE.md 5블록이 내 의도와 맞는지
• rules가 너무 많거나 적지 않은지
• 산출물 폴더가 깔끔한지

수정할 부분이 보이면 그 자리에서 한 줄로 지시하시면 됩니다. "톤을 더 부드럽게", "rules에 출처 표기 원칙 추가" 같은 식으로요.

📦 결과물

• PRD.md + 보조 명세 3종
• VALIDATION.md, RECOVERY.md, PLAN.md, PROGRESS.md, goal-command.md
• 자동 빌딩된 워크스페이스 폴더 1벌

15분 안에 위 모든 게 손에 잡힙니다. 손으로 짜는 것보다 두 배는 빨라요.

🆘 자주 막히는 포인트

골잡이가 뭔지 잘 모르겠어요

GPTaku 플러그인에 들어 있는 슬래시 커맨드 묶음입니다. "골(goal) 잡이"라는 이름처럼 목표 잡고 굴리는 도구예요. 설치는 한 줄로 되고, 자세한 사용법은 플러그인 README에 있어요.

PRD 인터뷰 답을 모르겠어요

비워두거나 "옵션 추천해주세요"로 답하세요. AI가 합리적인 기본값을 제안합니다. 이건 처음 만드는 PRD니까 완벽할 필요가 없어요. 다음 작업에서 다듬으면 됩니다.

/goal 도중에 AI가 엉뚱한 방향으로 갑니다

ESC 두 번으로 멈추세요. 그리고 "방금 만든 X 파일은 빼주세요" 식으로 한 줄로 지시하세요. PLAN.md를 한 번 같이 보면서 "이 부분만 다시 가자"로 재시작해도 됩니다.

자동 빌딩과 손 빌딩, 어느 게 더 좋나요?

처음 한 번은 손으로 짜보시는 걸 추천해요 (Clip 3). 폴더 구조와 CLAUDE.md가 어떻게 동작하는지 감을 잡아야 자동 빌딩 결과도 평가할 수 있어요. 두 번째부터는 자동이 훨씬 빠릅니다.

골잡이가 만든 결과물이 마음에 안 들어요

PRD부터 다시 짜는 게 빠릅니다. 골잡이 결과는 PRD에 좌우돼요. PRD가 흐릿하면 결과도 흐릿합니다. 정의 한 줄을 더 또렷이 적고 인터뷰 답을 구체적으로 다시 해보세요.

🔗 다음 클립

여기까지는 클로드코드 본체 + GPTaku 플러그인이었어요. 다음 클립부터는 oh-my-claudecode(OMC), 줄여서 OMC를 깝니다. 19개 전문 에이전트와 33개 슬래시 커맨드가 한 번에 따라와요. 설치는 한 줄, 첫 사용도 한 줄입니다.

→ Part 6 / Clip 5: oh-my-claudecode 설치 · 첫 사용

🎯 이 클립에서 만드는 것

오픈소스 플러그인 하나를 깝니다. 이름은 oh-my-claudecode, 줄여서 OMC라 부릅니다. 클로드코드 위에 얹는 도구예요. 한 번 깔면 19개 전문 에이전트와 33개 슬래시 커맨드가 따라옵니다.

설치는 한 줄짜리 명령으로 끝나요. 그다음 /autopilot "할 일" 하나로 첫 작업을 돌려봅니다. 본인 작업 한 건만 실험으로 돌려보면 그날 안에 감을 잡아요.

💡 핵심 개념

OMC = 클로드코드 위에 얹는 오픈소스 플러그인

GitHub 주소: github.com/yeachan-heo/oh-my-claudecode

이름은 oh-my-zsh에서 따왔어요. 셸을 한 번에 강화하는 그 도구처럼, OMC는 클로드코드를 한 번에 강화합니다. 직접 만든 에이전트나 커맨드를 따로 세팅하지 않아도 19+33개 세트가 깔리는 거예요.

핵심 가치는 네 가지입니다.

Smart Model Routing — 토큰 절감의 비밀

OMC가 토큰을 줄이는 방법은 단순해요. 작업의 복잡도에 따라 모델을 자동으로 골라줍니다.

간단한 작업 (lookup, 단순 fix)  → Haiku  (저렴, 빠름)
표준 작업 (구현, 디버깅)        → Sonnet (균형)
복잡 작업 (아키텍처, 큰 리팩토링) → Opus   (정확, 느림)

평소 모든 작업을 Opus로 굴리시면 비용이 큽니다. OMC가 적절한 모델로 자동 분배해줘서 똑같은 결과를 30~50% 적은 토큰으로 받아요.

/autopilot — 한 줄로 시작

이 커맨드 하나가 OMC의 얼굴이에요.

/autopilot "주간 보고서 템플릿 만들고 샘플 데이터 채워줘"

OMC가 안에서 자동으로 일어나는 일:

1. 작업 분석 → 어떤 에이전트가 필요한지 결정
2. 모델 라우팅 → 단계별로 적절한 모델 배치
3. plan → exec → verify 파이프라인 실행
4. 결과 검토 → 사람에게 보고

사람은 한 줄만 적으면 됩니다. 나머지는 OMC가 굴려요.

🚶 진행 흐름

1. 설치 — 1분

클로드코드 안에서 슬래시 커맨드 한 줄을 입력하세요.

/oh-my-claudecode:omc-setup

설치 마법사가 시작됩니다. 보통은 기본 옵션 그대로 엔터만 누르면 돼요. 끝나면 19개 에이전트와 33개 커맨드를 바로 쓸 수 있어요.

2. 설치 확인 — 30초

새 세션을 한 번 열고 /만 입력해보세요. 자동완성에 /autopilot, /plan, /ralph 같은 새 커맨드가 떠 있으면 설치 성공입니다.

또는 내 워크스페이스 .claude/ 폴더를 보시면 됩니다. OMC가 깔리면서 새 폴더와 파일이 추가됐을 거예요.

3. 첫 실행 — 5분

내 업무 한 건을 골라보세요. 너무 큰 작업은 피하시고요. "3분 안에 끝낼 만한 거" 정도가 첫 실험에는 적당합니다.

/autopilot "이 폴더에 있는 CSV 한 줄로 요약해줘"

/autopilot "README.md 한 페이지 초안 만들어줘"

/autopilot "이 함수에 주석 달아줘"

이 중 하나로 시작해보세요. OMC가 일을 받아 굴리는 모습을 한 번 보는 게 이번 클립의 본 목적이에요.

4. 결과 평가 — 3분

/autopilot 결과가 나오면 두 가지만 보세요.

• 결과 품질 — 내가 손으로 했으면 어땠을지와 비교
• 걸린 시간 + 토큰 — 콘솔에 표시되는 사용량

이 두 가지를 메모해두면 다음 작업에 OMC를 쓸지 말지 판단 기준이 생깁니다.

5. 막힘 풀기 — 1분

처음 쓰시면 한두 번은 /autopilot이 의도와 다르게 흐를 수 있어요. 그럴 때 ESC 두 번으로 멈추고, /cancel로 모드를 종료하세요. 그리고 작업 한 줄을 더 구체적으로 다시 적어보시면 됩니다.

/cancel

이게 OMC의 안전 장치예요. 어떤 모드(autopilot, ralph, ultrawork 등)가 돌고 있든 /cancel로 중단할 수 있습니다.

📦 결과물

• OMC 설치 완료 + 19개 에이전트 / 33개 커맨드 사용 가능
• /autopilot 첫 실행 결과 1건
• 내 메모: "OMC를 어떤 작업에 쓸 만한가" 한 줄

설치 + 한 번 돌려본 경험만 있으면 이번 클립은 성공입니다. 다음 클립부터 19개 에이전트와 33개 커맨드를 본격적으로 알아갑니다.

🆘 자주 막히는 포인트

설치가 실패해요

/oh-my-claudecode:omc-doctor를 실행해보세요. 설치 문제를 자동으로 진단·수정해주는 커맨드입니다. 그래도 안 풀리면 GitHub Issues에 올라온 사례를 한 번 검색해보시고요.

/autopilot이 너무 느려요

작업이 큰 거예요. 한 번에 한 가지만 시키세요. "보고서 만들고 PDF로 출력하고 이메일 보내기"보다 "보고서 만들기" → 결과 확인 → "PDF로 출력하기" 식으로 쪼개세요.

모델이 자동으로 바뀐다는데 어떻게 확인하나요?

OMC 콘솔에 어떤 모델이 어떤 단계에 쓰였는지 표시됩니다. /autopilot 실행이 끝나면 요약에서 "plan: Sonnet / exec: Haiku / verify: Sonnet" 같은 표시가 보일 거예요.

다른 플러그인과 충돌 안 하나요?

GPTaku 플러그인(/show-me-the-prd, /goaljaby, /goal)과는 잘 어울립니다. GPTaku로 PRD/골을 잡고, OMC로 자율 실행을 돌리는 흐름이 자연스러워요.

19개 에이전트 다 외워야 하나요?

아니요. 다음 클립에서 이름을 한 번 훑기만 하시면 됩니다. 실제로는 /autopilot이 알아서 호출해줘서 우리가 이름을 외울 필요가 없어요. 카탈로그는 참고용이에요.

🔗 다음 클립

설치가 끝났으니 OMC 안에 어떤 도구들이 들어 있는지 한 번 펼쳐봅니다. 다음 클립에서는 19개 전문 에이전트를 5개 그룹으로 나눠서 정리해요. 어떤 작업에 어떤 에이전트가 자동으로 붙는지 감을 잡는 시간입니다.

→ Part 6 / Clip 6: OMC 19개 에이전트 카탈로그

🎯 이 클립에서 만드는 것

지난 클립에서 깐 OMC 안에는 19명의 전문가가 들어 있어요. 비유하면 19명짜리 외주 팀을 통째로 영입한 셈입니다. 이번 클립에서는 누가 무슨 일을 하는지 한 번 훑고, 내 업무에서 자주 부를 후보 3~4명을 메모로 남깁니다.

19명 다 외울 필요는 없어요. 평소 일에서는 5~6명이 반복적으로 등장합니다. 내 일에 자주 붙을 후보만 손에 잡으면 충분해요.

💡 핵심 개념

그룹 1 — 기획·전략 (5명)

작업을 시작하기 전 "뭘 만들지" 정하는 사람들이에요.

PRD 짤 때 analyst, 작업 계획 짤 때 planner, 아키텍처 결정에 architect — 이런 식으로 단계별로 호출됩니다.

그룹 2 — 실행·구현 (3명)

기획이 끝나고 실제로 손을 움직이는 사람들이에요.

/autopilot을 돌리면 가장 자주 마주치는 멤버들입니다. executor가 80% 정도 일을 합니다.

그룹 3 — 탐색·디버깅 (3명)

문제가 생겼을 때 부르는 사람들이에요.

"이 버그가 어디서 시작됐는지 모르겠다"면 tracer, "왜 빌드가 깨졌는지 모르겠다"면 debugger, "이 함수 어디서 쓰이는지 모르겠다"면 explore.

그룹 4 — 품질·테스트 (3명)

코드를 만든 뒤 점검하는 사람들이에요.

PR 올리기 전 code-reviewer, 테스트 추가할 때 test-engineer, 실제 사용 흐름을 눌러볼 때 qa-tester.

그룹 5 — 보안·과학·디자인·문서 (5명)

특수 영역 전문가들이에요.

비개발자 분들도 자주 쓰실 멤버가 둘 있어요. writer는 보고서·README 초안, scientist는 데이터 분석. 이 두 명만 알아두면 OMC 절반은 써먹는 거예요.

🚶 진행 흐름

1. 19명 이름 한 번 훑기 — 3분

위 5개 그룹 표를 한 번 위에서 아래로 읽으세요. 외우려 하지 마시고요. "아, 이런 역할이 있구나" 정도면 충분합니다.

2. 내 업무에 자주 붙을 3~4명 표시 — 5분

내 작업 한 건을 떠올리세요. 그걸 OMC로 굴린다고 가정하고 어떤 에이전트들이 붙을지 생각해보세요.

# 내 업무 → 호출될 에이전트 (예시)

업무: 월간 영업 보고서 작성

호출 후보:
1. planner — 보고서 구조 잡기
2. scientist — KPI 데이터 분석
3. writer — 보고서 초안 작성
4. critic — 초안 검토

(verifier 또는 code-reviewer는 이 업무에선 안 쓰임)

표시 안 된 에이전트는 신경 안 쓰셔도 됩니다.

3. 직접 호출해보기 — 5분

/autopilot 안 쓰고 특정 에이전트를 직접 호출하고 싶을 때는 자연어로 적으면 됩니다.

"이 코드 critic으로 비판적으로 검토해줘"

"이 보고서 초안 writer가 다듬어줘"

"이 함수 어디서 쓰이는지 explore가 찾아줘"

OMC가 자연어 안의 에이전트 이름을 보고 알아서 불러요. subagent_type 같은 기술 용어를 안 써도 돼요.

4. 메모 저장 — 2분

위 후보 목록을 my-omc-agents.md로 저장하세요. 워크스페이스 안 .claude/나 메모 폴더에 두시면 됩니다. 다음 클립에서 33개 커맨드와 짝지을 때 이 메모를 다시 펼칠 거예요.

📦 결과물

• my-omc-agents.md — 내 업무 + 호출 후보 3~4명 매핑
• 자연어로 에이전트 직접 호출 1번 실험

15분 안에 이 두 가지면 됩니다. 19명을 다 알 필요는 없어요. 누가 있는지 한 번 본 것이 본 목적입니다.

🆘 자주 막히는 포인트

19명 중 누구를 부를지 모르겠어요

/autopilot을 쓰세요. OMC가 자동으로 적절한 에이전트를 골라줍니다. 직접 호출은 결과가 마음에 안 들 때 "이번에는 critic으로 다시" 같은 식으로 보조적으로 쓰시면 돼요.

"기획·전략 5명"은 다 비슷해 보여요

겹치는 영역이 있긴 한데, 결정적 차이는 이렇게 잡으시면 돼요.

• analyst → 시작 전 분석 (요구사항)
• planner → 시작 후 계획 (단계별)
• architect → 구조 설계 (시스템 차원)
• critic → 완료 전 비판 (결함 찾기)
• verifier → 완료 후 검증 (증거 확인)

시점이 다르다고 보시면 가장 쉽습니다.

writer와 document-specialist 차이는?

• writer — 만드는 사람 (README, API 문서, 코드 주석)
• document-specialist — 찾는 사람 (외부 문서·레퍼런스 조회)

문서를 새로 쓸 때는 writer, 외부 자료를 찾아야 할 때는 document-specialist.

code-reviewer와 critic 차이는?

• code-reviewer → 코드 전용 리뷰 (SOLID, 성능, 보안)
• critic → 계획·아키텍처 비판 (코드 외 산출물 포함)

코드 리뷰는 code-reviewer, PRD나 워크스페이스 설계 비판은 critic.

19명이 너무 많아요

5~6명만 알아두시면 됩니다. 비개발자 분들이 자주 쓰는 멤버:

1. planner — 작업 계획
2. writer — 문서 초안
3. scientist — 데이터 분석
4. critic — 비판적 검토
5. explore — 자료 찾기

이 다섯이면 사실상 일상 업무 대부분이 커버됩니다.

🔗 다음 클립

에이전트는 "누가 일하나"의 답이었어요. 다음 클립은 "어떻게 부르나"의 답인 33개 슬래시 커맨드입니다. /autopilot은 이 중 하나일 뿐이에요. 나머지 32개가 어떤 상황에 쓰이는지 6개 카테고리로 나눠서 봅니다.

→ Part 6 / Clip 7: OMC 33개 슬래시 커맨드

🎯 이 클립에서 만드는 것

19명짜리 외주 팀에게 일을 시키는 방법이 33가지 있다고 보시면 돼요. 33개를 다 외울 필요는 당연히 없습니다. 핵심 5~7개만 손에 익히면 일상 업무는 끝납니다.

처음엔 /autopilot 하나만 알아도 충분해요. 그 정도로 시작하고, 나머지 32개는 필요할 때마다 천천히 늘려가시면 됩니다.

(릴리스 카테고리에 /release 1개 추가, 총 33개)

💡 핵심 개념

카테고리 1 — 실행 모드 (5)

작업을 어떤 방식으로 굴릴지 정하는 커맨드들이에요.

처음 한 달은 /autopilot 하나만 익히세요. 익숙해지면 큰 작업에 /ralph, 병렬이 필요해지면 /ultrawork.

카테고리 2 — 기획·분석 (6)

작업 시작 전 머리 굴리는 커맨드들이에요.

PRD 짤 때 /plan, 막힌 버그 추적할 때 /trace, 자료 조사할 때 /external-context.

카테고리 3 — AI 협업 (3)

다른 AI 모델과 같이 일하는 커맨드들이에요.

같은 코드도 모델마다 다른 문제를 잡습니다. 중요한 결정에는 /ccg로 두 번째 의견을 받으세요.

카테고리 4 — 코드 품질 (3)

만든 결과물을 점검하는 커맨드들이에요.

AI가 만든 코드에 군더더기가 많이 보이면 /ai-slop-cleaner. UI 변경 검증할 때 /visual-verdict.

카테고리 5 — 워크스페이스·세팅 (8)

설치·환경·진단 커맨드들이에요.

설치할 때 /omc-setup 한 번, 문제 생기면 /omc-doctor 한 번. 나머지는 필요해질 때만.

카테고리 6 — 스킬·메모리 (5)

학습·관리 커맨드들이에요.

/cancel은 안전 장치예요. 어떤 모드든 중단할 수 있어요. /learner는 잘 쓰셨던 대화 패턴을 스킬로 박제할 때 씁니다.

🚶 진행 흐름

1. 33개 이름 한 번 훑기 — 3분

위 6개 카테고리를 한 번 위에서 아래로 읽으세요. 이름만 익숙해지면 됩니다.

2. 내가 자주 쓸 5개 표시 — 5분

업무 패턴에 따라 자주 쓸 커맨드 5개를 골라보세요. 비개발자 분들 추천 조합:

# 내가 자주 쓸 OMC 커맨드 5개

1. /autopilot — 일상 작업 한 줄 시작
2. /plan — 큰 작업 기획
3. /ai-slop-cleaner — AI 결과물 정리
4. /external-context — 외부 자료 리서치
5. /cancel — 막혔을 때 탈출

개발자 분들 추천 조합:

1. /autopilot
2. /ralph — 완료까지 굴리기
3. /ai-slop-cleaner
4. /ccg — 두 번째 의견
5. /cancel

내 상황에 맞게 바꾸면 돼요.

3. 핵심 5개 한 번 눌러보기 — 5분

표시한 5개를 차례로 한 번씩 입력해보세요. 인수 없이 입력하면 도움말이 떠요. 화면에서 어떤 옵션이 있는지 보면 감이 잡힙니다.

/autopilot

/plan

/cancel

/cancel은 활성 모드가 없으면 그냥 "활성 모드 없음" 메시지만 떠요. 안전합니다.

4. 메모 저장 — 2분

5개 목록을 my-omc-commands.md로 저장하세요. 지난 클립의 my-omc-agents.md와 같은 폴더에 두시면 한 번에 펼쳐볼 수 있어요.

📦 결과물

• my-omc-commands.md — 내가 자주 쓸 5개 커맨드
• 5개 커맨드 한 번씩 눌러본 기록

이번 클립은 카탈로그 한 번 펼쳐보는 게 본 목적이에요. 33개 다 외우려 하지 마시고요.

🆘 자주 막히는 포인트

33개 중 누구를 부를지 모르겠어요

/autopilot으로 시작하세요. OMC가 안에서 알맞은 커맨드와 에이전트를 알아서 불러요. 우리가 33개를 의식적으로 하나씩 부르는 경우는 많지 않아요.

/plan과 /autopilot 차이가 모호해요

• /plan → 기획만 (작업 안 함, 결과는 계획 문서)
• /autopilot → 기획 + 실행 (자동 작업까지)

큰 작업을 시작하기 전 검토용으로 /plan을 먼저 돌리고, OK면 /autopilot으로 넘어가는 흐름도 자주 씁니다.

/ralph와 /autopilot 차이는?

• /autopilot → 한 번 실행 → 결과 보고
• /ralph → 검증 통과까지 반복 (자기참조 루프)

작업이 한 번에 안 끝날 게 분명하면 /ralph. 짧은 작업은 /autopilot.

/ccg는 비용이 안 드나요?

Claude는 본 구독, Codex와 Gemini는 별도 API 키 또는 구독이 필요해요. 처음 쓰실 때는 /ask로 한 모델만 호출해보시고, 쓸 만하다 싶으면 다른 모델 키를 추가하는 흐름이 안전합니다.

/cancel을 눌렀는데 모드가 안 꺼져요

/cancel --force 옵션이 있어요. 강제로 모든 상태 파일을 비웁니다. 그래도 안 꺼지면 클로드코드 세션을 한 번 재시작하세요.

🔗 다음 클립

에이전트와 커맨드를 한 번 훑었으니, 이제 그걸 실제 작업에 써봅니다. 다음 클립은 코드 리뷰 가이드예요. 자연어 한 줄부터 명시적 에이전트 호출까지, 상황별로 code-reviewer · security-reviewer를 어떻게 부르는지 정리합니다.

→ Part 6 / Clip 8: 코드 리뷰 가이드

🎯 이 클립에서 만드는 것

코드 리뷰는 OMC에서 가장 자주 쓰이는 작업 중 하나예요. 그런데 리뷰 방법이 한 가지가 아닙니다. 자연어 한 줄부터 MCP로 외부 AI 호출까지 5~6가지 옵션이 있어요. 여기서는 상황별로 뭐부터 쓰면 되는지만 잡고 갑니다.

저는 평소에 빠른 체크는 자연어, 본격 리뷰는 명시적 에이전트 호출, 보안 점검은 따로 분리해서 씁니다. 내 일하는 방식에 맞는 말투 두세 개만 손에 익히면 충분해요.

💡 핵심 개념

가장 빠른 방법 — 자연어 한 줄

대화창에 그냥 적으면 클로드코드가 알아서 적절한 에이전트를 호출해요.

이번에 작업한 파일 리뷰해줘

src/auth/ 변경분 리뷰해줘 — 보안 위주로

방금 커밋한 거 리뷰해줘

OMC가 깔려 있으면 자동으로 code-reviewer (Opus) 또는 code-reviewer-low (Haiku)가 매칭됩니다. 빠른 체크면 후자, 본격 리뷰면 전자가 자동으로 붙어요.

명시적 호출 — 3가지 방식

자연어가 모호하면 직접 적시할 수 있어요.

A. OMC 에이전트 (가장 권장)

이 PR의 비즈니스 로직 깊게 봐줘 — code-reviewer로

빠르게 스타일·오타만 체크 — code-reviewer-low로

B. Codex MCP (외부 AI 의견)

코덱스한테 이 함수 리뷰 받아줘

같은 코드도 모델마다 다른 문제를 잡아요. 두 번째 의견이 필요하면 이 패턴이 빠릅니다.

C. 보안만 분리

이 코드 OWASP 기준으로 보안 리뷰해줘

OMC security-reviewer가 호출돼요. SQL 인젝션, 시크릿 노출, 권한 우회 같은 보안 패턴만 집중해서 짚어줍니다.

본격 리뷰 흐름 — 4단계

PR 단위로 본격 리뷰할 때 저는 이렇게 갑니다.

1. git diff main..HEAD 확인 (또는 PR 번호)
   ↓
2. "이 변경 리뷰해줘. 심각한 거만"
   → code-reviewer 자동 호출
   → severity별 리포트 (Critical / Major / Minor)
   ↓
3. "Critical만 executor로 고쳐줘"
   → OMC executor가 해당 항목만 자동 수정
   ↓
4. 다시 리뷰 → 통과 시 PR ready

처음부터 PR 전체를 물고 들어가지 않아도 됩니다. 코드 한 건만 리뷰로 돌려봐도 그날 안에 감을 잡아요. PR은 그다음에 붙이면 됩니다.

상황별 빠른 선택

이 표 한 장만 내 워크스페이스 references/ 같은 폴더에 두시면 돼요. 막힐 때 한 번 펼쳐보시면 됩니다.

🚶 진행 흐름

1. 내 워크스페이스에서 코드 한 건 고르기 — 1분

너무 큰 작업은 피하시고요. 100~300줄짜리 파일 한 개나, 작은 PR 하나가 첫 실험에 적당해요.

2. 자연어 리뷰 — 3분

이 파일 리뷰해줘 — [파일 경로]

OMC가 어떤 에이전트를 불렀는지 콘솔에서 이름만 봐두세요. code-reviewer-low가 떴다면 빠른 모드, code-reviewer가 떴다면 본격 모드예요.

리포트가 나오면 한 번 훑어보세요. severity 분류가 어떻게 됐는지, 어떤 카테고리(로직·성능·스타일·보안)로 묶였는지 보시면 다음 리뷰가 빨라져요.

3. 보안 분리 리뷰 — 3분

같은 파일에 보안 리뷰만 한 번 더 돌려보세요.

이 파일 보안 위주로 리뷰해줘

OMC security-reviewer가 호출돼요. 첫 번째 리뷰와 같은 문제를 짚을 수도, 새 문제를 짚을 수도 있어요. 두 리포트를 합치면 커버리지가 늘어납니다.

4. 결과 메모 — 3분

my-review-pattern.md로 내 리뷰 말투를 정리하세요.

# 내 코드 리뷰 말투

## 평소 작업
- 자연어 "리뷰해줘" → code-reviewer-low

## PR 단위
- "심각도별로 리뷰" → code-reviewer

## 보안 자료 다룰 때
- "보안 리뷰" → security-reviewer

## 결정적인 PR
- /ccg (두 번째 의견)

## 메모
- code-reviewer는 톤이 ___
- security-reviewer는 ___ 위주로 짚음
- /ccg는 시간이 ___ 걸림

직접 돌려본 느낌으로 빈칸을 채우시면 됩니다.

📦 결과물

• 코드 한 건 자연어 리뷰 1회
• 같은 코드 보안 리뷰 1회
• my-review-pattern.md 메모 1장

10분 안에 이 세 가지면 충분합니다. PR 리뷰는 다음번 실제 작업에 붙여보면 돼요.

🆘 자주 막히는 포인트

자연어로 적었는데 엉뚱한 에이전트가 호출돼요

말이 모호한 경우예요. "리뷰해줘"만 적으면 OMC가 빠른 모드로 갈 수 있어요. "심각도별로 본격 리뷰" 한 줄만 더 붙이면 code-reviewer(Opus)가 호출돼요.

code-reviewer가 너무 깐깐해요

코멘트 수가 많으면 severity 필터를 거시면 됩니다.

방금 리뷰에서 Critical만 다시 정리해줘

또는 처음부터 "Critical만 보여줘"로 시작하셔도 돼요.

code-reviewer와 security-reviewer를 같이 쓰면 시간이 두 배인가요?

병렬로 돌릴 수 있어요.

/autopilot "이 파일을 code-reviewer와 security-reviewer로 동시에 리뷰해서 통합 리포트 줘"

OMC가 두 에이전트를 병렬로 호출하고 결과를 합쳐서 보여줍니다.

보안 리뷰는 매번 해야 하나요?

외부 입력·인증·데이터베이스를 만지는 코드라면 돌리는 편이 좋아요. 단순 UI 변경이나 내부 유틸리티는 생략해도 큰 문제 없어요. 내 워크스페이스 rules에 "보안 리뷰가 필요한 변경 유형"을 한 줄로 적어두면 자동으로 판단해줍니다.

Codex/Gemini 의견이 Claude와 다를 때는?

세 모델이 다 동의하는 항목만 우선 처리하시는 게 안전해요. 의견이 갈리는 항목은 사람이 마지막에 판단해요. /ccg가 마지막에 종합 의견을 내는데, 그 종합도 참고용으로만 보세요. 결정은 사람이.

🔗 다음 클립

여기까지가 Part 6입니다. OMC 심화 — 컨텍스트 관리부터 코드 리뷰까지 한 바퀴 돌았어요. 다음 Part부터는 데이터로 넘어갑니다. 데이터베이스를 기초부터 잡고, 공공·검색 API로 데이터를 받아와 직접 DB를 채워봅니다.

→ Part 7 / Clip 1: 데이터베이스 기초 — 엑셀 너머로

🎯 이 클립에서 만드는 것

Part 7의 주제는 데이터입니다. 공공 API에서 데이터를 받아와 직접 데이터베이스를 만들어보는 게 이번 Part의 목표예요.

그 출발점이 이번 클립입니다. 다짜고짜 API부터 붙이지 않고, 데이터베이스가 뭔지 기초부터 잡고 갑니다. 엑셀은 다들 써봤으니, 엑셀과 비교하면서 시작하면 빠르게 감이 와요.

이번 클립에서는 익숙한 도서관 예시(책·회원·대출 3시트)로 엑셀 한 묶음을 진짜 데이터베이스로 옮겨봅니다.

이번엔 SQL 문법을 외우지 않습니다. 구조를 이해하고, 나머지는 클로드코드한테 시키는 흐름을 손에 익히는 게 목적이에요.

💡 핵심 개념

엑셀 vs 데이터베이스 — 차이는 어디서 오나

엑셀로도 시트 분리는 돼요. 그런데 데이터가 커지고, 여러 명이 만지고, 앱이 끼어들기 시작하면 엑셀이 버거워집니다. 차이는 네 군데서 나와요.

핵심 키워드 네 개만 기억하세요. 연결·무결성·동시성·규모. "엑셀로 충분한데 왜 DB?"라는 질문의 답이 다 여기 들어 있어요.

테이블 · 행 · 열 — 엑셀 시트와 1:1로 대응

용어가 낯설어 보여도 엑셀과 거의 같아요.

엑셀 시트 3장 = 테이블 3개. 이렇게 보면 됩니다. 다만 DB는 각 열에 "여기는 숫자만", "여기는 날짜만" 하는 타입이 붙어요. 그래서 "출판년도" 칸에 작가이름을 넣으면 DB가 알아서 거절합니다.

PK · FK — 테이블을 잇는 두 개의 열쇠

DB가 시트를 자동으로 연결하는 비결이 이 두 가지예요.

도서관 예시로 보면, 책 테이블의 책ID가 PK, 회원 테이블의 회원ID가 PK예요. 그리고 대출 테이블에는 책ID와 회원ID가 들어가는데, 이게 FK입니다. "누가(회원ID) 어떤 책(책ID)을 빌렸다"가 한 줄로 연결되는 거예요.

DB는 FK가 가리키는 PK가 실제로 존재하는지 자동으로 확인합니다. 등록 안 된 회원ID로 대출 기록을 넣으려고 하면 막혀요. 이게 아까 말한 무결성입니다.

ERD — 테이블 관계 그림

ERD는 Entity Relationship Diagram의 약자예요. 풀어 쓰면 "테이블 관계 그림"입니다.

ERD를 사람이 직접 그릴 필요는 없어요. 엑셀을 보여주고 "이대로 ERD 그려줘"라고 하면 클로드코드가 mermaid 코드로 그려줍니다. 그림은 mermaid.live에 붙여넣으면 떠요.

스키마 — DB가 직접 읽는 정의

ERD가 사람용 그림이라면, 스키마는 컴퓨터용 정형 텍스트예요. 같은 정보의 두 가지 표현입니다.

CREATE TABLE 책 (
  책ID    INTEGER PRIMARY KEY,
  제목    TEXT NOT NULL,
  저자    TEXT,
  출판년도 INTEGER
);