클로드 코드 풀코스 2시간: 설치부터 AI 직원 만들기까지 (2026)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

클로드 코드는 설치와 업무 설계에서 시작해 스킬·지식 관리·클라우드 루틴을 연결함으로써 반복 업무를 맡길 AI 직원을 만드는 도구다.

📌 핵심 요점

1. 설치보다 업무 정의가 자동화의 출발점이다. VS Code에 클로드 코드 확장을 설치하고 프로젝트 폴더를 연 뒤, 반복 업무 하나의 입력·처리·판단·출력을 정한다. 플랜 모드에서 계획을 검토하고, CLAUDE.md와 워크플로우에 판단 기준과 예외 대응을 기록한다. 주간 유튜브 분석을 PDF·Gmail·노션으로 연결하는 실습이 이를 보여 준다.
2. 스킬은 업무 지침, MCP와 API는 외부 기능 연결에 쓰인다. 정기 보고서는 파이썬의 직접 API 호출을 선택하고, 개인 말투가 필요한 답장·피드백은 스킬 크리에이터로 전용 스킬을 만든다. 마케팅·디자인·한국어 문체·영상 편집 스킬도 소개하지만, 설치 개수보다 실제 반복 작업 감소를 기준으로 선택하고 개선해야 한다.
3. 구글 업무와 지식 관리를 사업 맥락에 연결한다. GWS CLI로 메일 분류, 문서·슬라이드 생성, 일정 관리를 수행한다. 옵시디언에서는 원자료인 raw와 선별된 지식인 wiki를 분리하고, /ingest·/query·/lint로 자료를 정리·검색·점검한다. 정보 축적의 기준은 수집량보다 자신의 사업에 적용할 수 있는지다.
4. 사용량 관리와 협업 방식이 비용·품질을 좌우한다. /context로 사용량을 확인하고, 60~70%에서 상태를 저장한 뒤 새 대화를 시작하는 운영법을 제안한다. 상시 지침 축소, 문서의 Markdown 변환, 단순 작업의 저렴한 모델 위임도 활용한다. 작업자끼리 대화할 필요가 적으면 서브 에이전트, 상호 소통과 공동 검수가 필요하면 에이전트 팀을 선택한다.
5. AI 직원의 완성은 무인 실행과 실제 결과 검증에 달려 있다. 클라우드 루틴에 스케줄·커넥터·환경 변수·명확한 실행 지침을 설정하면 노트북이 꺼져 있어도 작업을 수행할 수 있다. 아침 브리핑 실습에서는 커넥터 누락과 저장소 승인 규칙으로 발송이 막혔고, 전용 저장소로 바꾼 뒤 세 번의 시도 끝에 카카오톡 발송을 확인했다. 다음 날 예약 실행의 성공 여부는 추가 확인이 남았다.

🧩 배경과 문제 정의

• 클로드 코드는 컴퓨터 폴더에서 파일을 만들고 실행하며 오류를 수정하는 AI 작업 도구다. 반복 업무를 말로 설명해 자동화하는 방식이 핵심이다.
• 자동화의 출발점은 코딩 실력보다 업무 정의다. 입력·처리·판단·출력을 명확히 정하고, 단순한 반복 업무 하나부터 시작해야 한다.
• 실습 과제는 유튜브 콘텐츠 트렌드를 수집·분석해 주간 PDF 보고서를 이메일로 보내고, 데이터를 노션에 누적하는 시스템이다.
• 자동화를 지속적으로 활용하려면 결과 검토, 보안 점검, 배포와 운영 관리가 필요하다. 개인 업무에 맞는 스킬도 실제 사례와 피드백으로 개선해야 한다.

🕒 시간순 섹션별 상세정리

1. 파일을 직접 다루는 AI 작업 도구와 이용 조건

• 채팅형 클로드가 답변을 제공하는 데 그친다면, 클로드 코드는 컴퓨터 폴더에서 파일을 생성·실행하고 오류를 수정한다. 스터디 모집, 수강생 피드백, 이메일 정리, 콘텐츠 발행이 반복 업무 자동화 사례다. [00:56]
• 이용에는 최소 클로드 프로 구독이 필요하다는 설명이다. 프로도 사용량 한도가 있어 소진하면 기다려야 하며, 사용량이 많으면 맥스의 5배·20배 옵션을 선택할 수 있다. [01:40]

2. 업무 절차에 맞춰 프로젝트 작업 공간 만들기

• 자동화 구축은 업무 정리, 작업 공간 준비, 프로젝트 설계와 승인, 코드 생성과 자기 수정, 결과 검토와 추가 개선의 순서다. 필요한 스킬은 이 과정에서 추가한다. [02:47]
• VS Code를 설치하고 확장 메뉴에서 클로드 코드 확장을 설치한 뒤 로그인한다. 새 폴더를 만들어 열면 프로젝트 작업 공간이 생긴다. [03:46]

3. 수정 권한과 계획 승인을 구분하는 작업 모드

• 수정 전에 매번 승인을 받는 모드는 초보자의 첫 사용에 권장된다. 자동 수정 모드는 사용자에게 묻지 않고 파일을 수정하며, Shift+Tab으로 모드를 전환할 수 있다. [04:51]
• 플랜 모드는 파일을 실제로 변경하기 전에 실행 계획을 제출한다. 사용자가 계획을 검토하고 승인해야 다음 단계로 넘어간다. [05:11]

4. 주간 콘텐츠 보고서의 입력과 결과를 먼저 정의하기

• 모호하게 “알아서 잘해 달라”고 지시하면 결과도 부정확해진다. 입력·처리·판단·출력의 틀을 명확히 하고, 매일 반복하는 업무 중 가장 단순한 하나를 골라 시작해야 한다. [06:58]
• 콘텐츠 제작 과정에서 관련 유튜브 영상을 찾고 아이디어를 추출하며 트렌드를 분석하는 일이 반복된다. 선호하는 영상들의 최근 주제를 PDF로 정리해 이메일로 받으면 자료 탐색 부담을 줄일 수 있다. [07:54]

5. CLAUDE.md와 워크플로우·에이전트·툴의 역할 분담

• CLAUDE.md는 프로젝트의 설계도이자 작업 판단 기준이다. 워크플로우에는 목표, 입력값, 사용할 도구, 결과물 형태, 문제 발생 시 대응을 단계별 업무 매뉴얼로 정한다. [09:56]
• 에이전트는 매뉴얼을 읽고 해결 방법과 필요한 도구를 선택한다. 툴은 데이터 수집, API 호출, 데이터 변환, 보고서 생성, 이메일 발송을 실제로 수행하는 파이썬 파일이다. [10:52]

6. 플랜 모드로 요구사항을 구체화하고 API 방식을 선택하기

• 플랜 모드에 자동화 목표와 함께 데이터 수집 방식 조사, 유용한 스킬 탐색, 추가 질문과 추천을 요청한다. 필요한 경우 웹 검색을 활용해 API와 MCP 중 적합한 연결 방법을 조사한다. [13:17]
• 추적할 유튜브 채널, PDF 디자인 수준, 수신 Gmail 주소, 노션 데이터베이스 용도를 확인해 요구사항을 구체화한다. 이번 실습은 최근 인기 영상 자동 검색, 기본형 PDF, 본인에게만 발송, 노션 기록 저장을 선택한다. [13:42]

7. 샘플 데이터로 분석과 PDF 생성을 검증하기

• 구현 계획에 따라 파이썬 도구와 단계별 워크플로우 문서가 생성된다. 샘플 데이터로 분석기와 PDF 생성기를 시험하며, 테스트에서는 영상 12개를 분석한다. [15:29]
• PDF 생성 과정에서 폰트 다운로드 URL 변경을 감지해 수정한다. 이후 편집기에서 파일을 표시할 수 없다는 메시지를 확인하고 재실행하며, PDF를 확인하기 위한 확장 프로그램을 설치한다. [16:17]

8. 컨텍스트 사용량을 확인하고 대화를 초기화하기

• AI 패널 하단의 컨텍스트 사용량은 대화 기억이 얼마나 차 있는지 보여 준다. 약 70%가 차면 /clear로 대화를 초기화하는 운영법을 권한다. [17:18]

9. 외부 서비스 연결은 MCP, 전문 지침은 스킬로 구분하기

• MCP 서버는 외부 서비스의 여러 기능을 하나의 연결로 사용할 수 있게 한다. 캘린더의 일정 생성·수정·삭제 API를 각각 연결하는 대신, MCP 서버를 연결하면 클로드가 필요한 기능을 선택해 사용한다. [17:57]
• 유튜브 정보 수집은 조사 결과 MCP가 꼭 필요하지 않다고 판단해 API를 선택했다. MCP가 외부 서비스를 이용하는 행동 능력을 제공한다면, 스킬은 특정 업무에 필요한 전문 지침을 제공한다. [18:17]

10. 클라우드에서 정해진 시간에 실행하고 발송 결과 확인하기

• 배포 대상은 워크플로우와 코드다. 업무 매뉴얼과 자동화 시스템을 클라우드 서버에 올려 정해진 절차대로 실행하고, 개선할 때는 VS Code에서 수정한 내용을 다시 배포한다. [19:23]
• 전체 파이프라인 테스트에서 발송 완료를 확인한다. 도착한 보고서에는 상위 영상 10개 분석, 트렌드 분석, 추천 콘텐츠와 아이디어, 스크립트 3개가 포함된다. [19:42]

11. API 키 보안과 운영 원칙, 사람의 최종 책임

• 전체 프로젝트에 API 키 노출과 취약점 검토를 요청한다. 점검 결과 코드에 API 키가 직접 들어간 곳은 없고, 별도 비밀 설정 파일에서 읽는 구조로 확인된다. [20:10]
• 정확한 기획, 모르는 내용 질문하기, 플랜 모드 사용, API 키의 코드 직접 입력 금지, 보안 리뷰, 컨텍스트 약 70%에서 초기화가 주요 운영 원칙이다. [20:56]

12. 브랜드와 반복 업무를 정리해야 위임할 일이 보인다

• 자동화는 자신의 브랜드와 비즈니스 시스템을 설계하고, 그 안의 반복 작업을 AI에 위임하는 문제다. 어떤 브랜드를 만들지와 어떤 업무가 반복되는지를 먼저 정리해야 자동화 대상을 찾을 수 있다. [21:58]
• 매월 스터디 모집, 하루에 60~70명 피드백, 이메일 정리, 콘텐츠 기획·촬영·편집을 직접 수행한 경험이 반복 업무를 식별하는 바탕이 됐다. 반복성을 파악한 뒤 업무를 하나씩 자동화했다. [22:19]

13. 스킬 크리에이터로 개인 업무에 맞는 스킬 만들기

• 1인 사업의 고객 답장과 채널별 글 수정은 반복적이면서도 개인화가 강해 기성 스킬이 잘 맞지 않을 수 있다. 스킬 크리에이터는 이런 반복 업무를 개인 전용 스킬로 만드는 도구다. [23:20]
• GitHub의 스킬 크리에이터 자료를 클로드에 전달하고 공식 문서에 기반한 설치를 요청한다. 스킬은 이름과 설명을 담은 YAML 메타데이터와 실행 워크플로우로 구성되며, 사용자 범위 또는 특정 프로젝트 범위로 설치할 수 있다. [24:18]

14. 실제 피드백 자료로 전용 스킬을 계속 개선하기

• 수강생 피드백 스킬은 지침에 따라 작성된 글을 기존 데이터와 지식으로 분석하고 개선점을 짚어 본다. 자신의 말투와 톤까지 반영해 피드백을 생성하는 개인 업무 사례다. [25:48]
• 처음 생성된 스킬은 완성품이 아니며 개인 취향과 업무 기준에 맞지 않을 수 있다. 기존에 작성한 피드백을 넣고 수개월 동안 반복 조정한 경험처럼, 실제 업무 사례를 바탕으로 계속 개선해야 한다. [26:26]

15. 슈퍼파워스로 기획·실행·검증 절차를 갖추기

• 제시 빈센트가 만든 슈퍼파워스는 여러 스킬을 묶은 플러그인이다. 제작부터 시작하면 의도와 다른 결과가 나오거나 근거 없는 수정이 반복될 수 있어, 작업에 맞는 절차를 먼저 갖추는 데 목적이 있다. [27:21]
• 브레인스토밍으로 요구를 정리하고 계획을 작성한 뒤, 서브 에이전트 실행 또는 사용자 검증 방식을 선택한다. 별도 작업 공간인 Git 워크트리를 만들어 기존 작업과 섞이지 않게 하고, 실행 중 테스트와 품질 검사를 수행한다. [28:07]

16. 대시보드의 기본 화면과 AI 생성 기능의 조건 구분하기

• 대시보드를 만들고 실행용 스킬로 서버를 띄워 브라우저에서 확인한다. 이 실습의 목표는 전체적인 큰 틀을 빠르게 완성하는 것이며, AI를 이용한 강의 생성에는 안트로픽 API 키 입력이 필요하다. [28:52]
• 생성된 강의 대시보드에는 본인만 접근하도록 보안이 설정돼 있다. 강의 초안 생성에 AI가 사용될 것으로 예상하며, 현재 구현은 API 키 설정을 요구한다. 클로드 코드와 직접 소통하는 방식으로 바꾸면 무료 생성도 가능하다는 설명이다. [29:17]

17. 마케팅 스킬로 1인 사업의 실행 아이디어 보완하기

• 코리 해인즈가 만든 마케팅 플러그인은 검증된 마케팅 아이디어 139개를 라이브러리로 제공한다. 카피, 랜딩 페이지, 이메일, 광고와 런칭을 혼자 담당하는 1인 사업자의 업무를 지원한다. [29:37]
• 마케팅을 처음 시작하면 무엇을 어떻게 적용할지 판단하기 어렵다. 책에서 아이디어를 찾아 하나씩 적용하던 경험과 비교해, 마케팅 스킬은 관련 지식을 클로드 코드 안에서 활용할 수 있게 한다. [29:57]

18. 사업 맥락을 공유하는 마케팅 스킬과 실행 순서

• 제품과 타깃 정보를 파일로 저장하면 다른 마케팅 스킬도 같은 사업 맥락을 활용한다. 다만 영어권 SaaS 기준이 한국 시장에 맞지 않을 수 있어, 실제 적용 과정에서 클로드 코드와 대화하며 스킬을 수정해야 한다 [30:48]
• 프로덕트 마케팅을 토대로 나머지 44개 스킬이 작업을 시작한다. 고객 조사로 맥락의 품질을 높이고 마케팅 플랜으로 로드맵을 만든 뒤, 필요한 카피라이팅·이메일·오퍼 작업을 선택해 진행한다 [31:25]

19. UI/UX Pro Max로 디자인 기준을 세우고 개선하기

• UI/UX Pro Max에는 스타일 50개, 색 팔레트 161개, 폰트 조합 57개, UX 가이드라인 99개가 들어 있다. 사업 유형에 맞는 스타일과 색상·폰트, 피해야 할 패턴을 선택해 흔한 AI 디자인에서 벗어나는 기준으로 활용한다 [32:58]
• 디자인 시스템으로 큰 틀을 잡은 다음 색상·폰트·UX를 세부적으로 다듬는다. 홈페이지의 단순한 흰색·빨간색 구성을 개선하고, 7일 무료 과정에 맞는 랜딩 페이지를 만든 사례가 계속된다 [33:33]

20. 한국어 초안의 의미를 유지하면서 문체 다듬기

• I’m not AI는 내용의 의미를 유지하면서 문체·리듬·표현을 자연스러운 한국어로 바꾸는 데 사용한다. 플러그인 안의 Humanize Korean 스킬을 번역문에 적용하는 방식이다 [35:09]
• 스레드나 뉴스레터처럼 AI로 초안을 만드는 콘텐츠에 활용할 수 있다. 한 번에 100% 완성되지는 않으며, 과도하게 적용하면 오히려 부자연스러워질 수 있어 약 80%를 다듬고 나머지는 직접 검토하는 접근을 권한다 [35:50]

21. Remotion으로 반복 영상 장면을 템플릿화하기

• 자막·인트로·모션 편집에는 시간이 많이 든다. Remotion 스킬은 자막 파일이나 데이터를 받아 영상 장면을 코드로 구성하고 렌더링까지 이어가, 반복되는 영상 구조를 템플릿으로 만들 수 있게 한다 [37:11]
• 장면을 React 컴포넌트로 정의하고 프레임을 렌더링해 MP4로 출력한다. 시행착오를 거쳐 만든 자막 스타일과 장면을 파일에 저장하면 다음 영상에서도 같은 구성을 재사용할 수 있다 [37:43]

22. Caveman으로 답변 길이와 토큰 사용 줄이기

• 장황한 확인 문구와 부연 설명은 출력 토큰을 사용하고 대화 기억 용량·속도·비용에 부담을 준다. Caveman은 불필요한 수식어를 덜어내고 필요한 답과 결과물을 압축해 제공한다 [38:43]
• 압축 강도에 따라 Light, Full, Ultra를 선택할 수 있다. Light는 표현 차이를 작게 유지하고, Full은 중간 수준, Ultra는 최대 수준으로 압축하는 방식이다 [39:15]

23. 스킬 수보다 반복 업무의 감소를 기준으로 삼기

• 유명한 스킬을 많이 설치해도 제대로 사용하는 도구는 적을 수 있다. 먼저 자신의 반복 업무를 돌아보고 필요한 자리에만 스킬을 붙이며, 맞는 것이 없으면 스킬 크리에이터로 만드는 방향으로 전환한다 [40:57]
• 소개된 일곱 개를 처음부터 모두 설치하기보다 하나를 골라 가장 손이 많이 가는 반복 업무에 적용해야 한다. 판단 기준은 도구의 개수가 아니라 실제로 반복 작업을 줄일 수 있는지다 [41:23]

24. GWS CLI로 구글 업무를 한 인터페이스에 연결하기

• 터미널은 컴퓨터에 텍스트 명령을 보내는 창이며, GWS CLI는 구글 워크스페이스를 명령어로 조작하는 인터페이스다. 서비스별로 API나 MCP 연결·인증을 따로 구성하는 부담을 줄이는 통합 도구로 활용한다 [42:24]
• 구글 API 목록을 읽어 명령어를 자동 생성하므로 새 기능을 반영할 수 있고, 내장 MCP 서버를 통해 클로드 코드와 연결할 수 있다 [43:08]

25. GWS 설치와 OAuth 인증을 완료하는 과정

• GWS GitHub 저장소 주소와 함께 문서를 읽고 설치를 도와달라고 요청한다. 시연에서는 Node.js 설치 여부를 확인한 뒤 npm 설치를 선택하며, gcloud가 없는 환경에서는 추가 설치가 필요하다 [44:56]
• OAuth는 클로드 코드의 구글 계정 접근을 허용하는 과정이다. 프로젝트를 만들고 앱 이름·지원 이메일·외부 사용자 설정·연락처를 입력한 뒤, 데스크톱 앱 유형의 클라이언트를 생성해 JSON 파일을 내려받는다 [46:10]

26. 최근 이메일을 중요도로 분류하고 뉴스레터 저장하기

• 최근 30일 이메일에 중요도 점수를 매기고, 중요하지 않은 메일은 읽음 처리하며, 중요한 메일은 보고하도록 요청한다. 뉴스레터는 요약해 구글 독스에 저장하도록 같은 작업에 묶는다 [47:19]
• 시연 결과 이메일 249개를 분석하고, 강의 제안·협업·실패 알림 등 확인이 필요한 내용을 구분한다. 낮은 중요도의 메일 105개는 읽음 처리하고, 뉴스레터 189개는 구글 독스에 정리하며 다음 날 미팅 초대 메일 확인도 안내한다 [48:13]

27. 유튜브 내용을 서식 있는 구글 독스 가이드로 만들기

• 유튜브 링크를 입력해 영상의 가이드와 요약을 구글 독스로 만들 수 있다. 기존 뉴스레터 문서처럼 글자 크기가 같고 형식이 정돈되지 않은 결과에는 서식과 볼드체를 적용할 기능을 추가로 요청한다 [49:11]
• 완성 문서에는 영상 링크, 제목별 볼드체, 이모티콘과 구분선이 적용된다. 문서의 핵심 관점은 브랜드와 시스템을 먼저 설계하고 그 안의 반복 작업을 AI에 위임하는 것이다 [49:57]

28. 브랜드 슬라이드를 생성하고 이미지로 레이아웃 보정하기

• 브랜드 로고와 가이드라인을 폴더에 넣고 유튜브 내용을 구글 슬라이드로 변환하도록 요청한다. 브랜드 색감과 스타일을 참고해 슬라이드를 만드는 방식이다 [50:39]
• 처음 생성한 12장에는 요소 위치가 어긋나고 로고가 잘리는 문제가 있다. 썸네일·스크린샷으로 결과를 확인해 상단에 몰린 내용, 빈 하단, 작고 조밀한 텍스트와 보이지 않는 로고를 보정한다 [52:22]

29. 메일·일정·자료 제작을 실제 사업 업무에 적용하기

• GWS는 이메일 자동 분류, 영상별 가이드 생성, 시트 데이터의 문서화, 캘린더 빈 시간대의 일정 배치에 활용할 수 있다. 중요한 것은 각 기능을 자신의 사업 관리와 효율 개선에 연결하는 방식이다 [54:08]
• 중요한 메일만 받아 처리하고, 많은 뉴스레터를 구글 독스에 모아 일주일에 한 번 검토한다. 반죽 유통 업무에서는 2시 이전에 정보를 전달해야 당일 발송이 가능하므로, 누락으로 고객과 수입에 문제가 생기지 않도록 캘린더 알림을 활용한다 [54:58]

30. 수집한 지식을 사업에 적용하기 위한 옵시디언의 구조

• 책·강의·정보를 많이 모아도 어디서부터 사업에 적용할지 모르면 실행으로 이어지지 않는다. 옵시디언 사용 경험은 1~2개월 정도이며, 3년 넘게 사용한 노션에서 막혔던 부분을 클로드 코드와의 결합으로 해결한 경험이 전환의 배경이다 [56:25]
• 옵시디언은 컴퓨터 폴더에 마크다운 파일을 저장하는 노트 도구다. 볼트는 그 폴더를 뜻하며, 화면의 파일 구조도 실제 컴퓨터 폴더 구조와 연결된다 [56:58]

31. 원자료와 위키를 나누고 AI에 선별을 맡기기

• 원자료와 위키를 분리하는 구조는 안드레 카파시가 2026년 4월 GitHub에 공개한 LLM 위키 패턴을 토대로 한다. 옵시디언은 작업 환경, LLM은 정보를 처리하는 역할, 위키는 정리된 지식 기반에 대응한다 [58:10]
• 도서관에 비유하면 옵시디언은 건물, 클로드 코드는 사서, 위키는 정리된 책꽂이다. 외부 자료가 들어오면 AI가 사업에 필요한지 판단하고, 통과한 자료를 위키에 배치하며 관련 자료끼리 연결한다 [58:44]

32. 사업 기준을 통과한 정보만 위키에 축적하기

• Raw는 유튜브·강의·뉴스레터·책·PDF처럼 외부에서 들어온 정보다. Wiki에는 자신의 사업에 꼭 필요한 내용만 넣고, 사업 기준에 맞지 않는 외부 정보는 들이지 않는다 [59:26]
• 선별 과정이 없으면 무엇이 좋은 정보이고 실제로 필요한 정보인지 구분하기 어렵다. 페이지를 계속 저장해도 나중에 중요한 내용이 무엇인지 찾지 못하는 문제가 생긴다 [59:53]

33. 옵시디언과 클로드 코드가 같은 자료 폴더를 공유한다

• 기존 자료 폴더를 열거나 새 폴더를 만든 뒤, 옵시디언에서도 같은 폴더를 보관함으로 연다. 예시에서는 ‘옵시디언 비즈니스’ 폴더를 사용한다. [1:00:49]
• 두 도구가 같은 폴더를 바라보므로 클로드 코드가 정리한 파일을 옵시디언에서 바로 확인하고, 새로 넣은 자료도 같은 공간에서 관리할 수 있다. [1:01:28]

34. 사업과 자료 유형에 맞춰 raw·wiki 규칙을 설계한다

• LLM 위키 원본 가이드에 사업 맞춤 프롬프트를 추가해 raw·wiki 구조를 만든다. 인터뷰의 핵심 질문은 사업 활동이 무엇인지, 어떤 정보와 자료를 자주 다루는지 두 가지다. [1:02:36]
• 예시 사업은 AI 도구로 사업 시스템화를 돕는 활동이며, 주요 자료는 고객·시장 리서치, 콘텐츠 아이디어·스크립트, 재무·매출·운영 데이터, 학습 자료·인사이트의 네 영역이다. [1:02:57]

35. 자료 정리·검색·점검을 세 가지 명령으로 운영한다

• /ingest는 raw 폴더의 새 자료를 규칙에 따라 분류하고 wiki에 정리하며, /query는 축적된 위키에서 필요한 정보를 찾는 데 사용한다. [1:04:48]
• /lint는 자료가 쌓이면서 발생하는 잘못된 정보, 미처리 자료, 구조상 점검할 부분을 진단한다. 초기보다 장기간 운영한 위키에서 필요성이 커진다는 판단이다. [1:05:42]

36. 원본 대본에서 사업에 적용할 정보만 추출한다

• 유튜브 영상의 대본을 복사해 raw 폴더에 Markdown 파일로 저장한다. 원본 전체를 보관한 뒤 /ingest로 필요한 내용을 추출해 wiki에 넣는다. [1:08:44]
• 예시 대본은 설정한 규칙상 시스템 인사이트 영역에 들어갈 가능성이 높다고 판단된다. raw에 자료를 모으고 명령을 실행하면 영역별 정리 결과를 활용할 수 있다. [1:09:21]

37. 압축된 지식을 연결하고 외부 자료 수집으로 확장한다

• 예시 처리 결과는 시스템 인사이트 영역에 배정됐으며, 약 2,000줄의 원본이 128줄로 압축됐다. 크로스 링크 다섯 개와 직접 인용 세 개가 포함됐다. [1:11:09]
• 정제된 문서에는 자동화의 AI 신입사원 모델, 라이프사이클, 구조, 운영·보안 원칙 등이 담긴다. 옵시디언에서는 태그와 문서 간 연결을 그래프로 확인해 사업에 필요한 지식의 관계를 살필 수 있다. [1:12:34]

38. 긴 대화의 반복 읽기가 사용량 한도를 소모한다

• 월 100달러 Max 구독을 사용하면서도 하루 두세 번 한도에 도달했던 개인 사례가 있다. 사용 습관을 바꾼 뒤에는 같은 구독으로 하루 한도에 도달하지 않게 됐다는 경험이다. [1:13:51]
• 메시지를 보낼 때 이전 대화를 다시 읽는 구조 때문에 대화가 길어질수록 처리량이 늘어난다. 개인적으로 한 달간 세션 80개와 턴 38,000개를 분석한 결과, 앞 대화 재읽기가 95.7%, 새 입력이 약 0.03%였다는 수치가 드러난다. [1:14:45]

39. /context로 대화와 지침의 기본 사용량을 확인한다

• /context는 현재 대화의 사용량을 확인하고, /clear는 새 대화를 시작한다. /compact는 기존 대화를 요약으로 대체하며, /rewind는 이전 지점으로 되돌린다. [1:15:24]
• 예시에서 730줄짜리 CLAUDE.md의 메모리 파일 사용량은 9.4K였고, 약 180줄짜리 프로젝트는 약 5,000토큰이었다. 작업 전부터 지침이 차지하는 공간을 /context로 확인하는 것이 사용량 관리의 출발점이다. [1:16:35]

40. 대화가 꽉 차기 전에 상태를 저장하고 새로 시작한다

• 대화가 가득 찬 뒤 /compact에 의존하면 중요한 세부사항이 빠지거나 강조점이 어긋날 수 있다는 경험이 있다. 자동 요약을 반복한 피드백 작업에서는 결과가 뭉개지는 문제가 발생했다. [1:17:15]
• 사용량이 60~70%에 이르면 결정된 사항, 미결 사항, 다음 할 일을 정리하고, 확정된 내용은 메모리와 CLAUDE.md에 반영한다. 요약본을 복사한 뒤 /clear로 새 대화를 열어 이어가는 방식이다. [1:17:45]

41. /rewind로 잘못된 시도와 수정 대화를 줄인다

• 잘못된 결과에 계속 수정 지시를 덧붙이면 실패한 시도도 대화에 남아 이후 처리에서 다시 읽힌다. 기획안 초안을 요청했는데 기존 레이아웃까지 바뀐 사례가 여기에 해당한다. [1:19:09]
• /rewind 또는 Esc 두 번으로 원하는 이전 지점을 선택해 되돌아간다. 예시에서는 PDF 양식 변경 전으로 돌아가 잘못된 시도를 거친 구간을 제외하고 작업을 이어간다. [1:19:43]

42. 긴 컨텍스트의 품질 저하를 고려해 리셋 시점을 정한다

• 수강생 피드백을 같은 대화에서 계속 작성하면서 지시한 말투를 따르지 않는 결과가 생겼고, 결국 수동 작성이 필요해졌다. 긴 대화가 결과 품질에도 영향을 줄 수 있다는 사례다. [1:20:07]
• 인용된 Anthropic의 Opus 4.6 MRCR 결과는 256K에서 정확도 93%, 100만 토큰에서 76%다. 이 차이를 근거로 대화를 끝까지 채우기보다 60~70%에서 리셋하는 운영 기준을 권장한다. [1:20:42]

43. CLAUDE.md에는 상시 필요한 핵심 규칙만 남긴다

• 사업 정보, 명령어, 에이전트 업무, 피드백 작성법, 말투를 모두 넣으면 지침이 700줄을 넘을 수 있다. 새 대화를 열 때 로딩되는 지침이므로 작업 전부터 토큰을 차지한다. [1:21:32]
• CLAUDE.md를 200줄 이하로 줄이고, 업무별 상세 규칙은 별도 Markdown 파일로 분리한다. 예시에서는 피드백 규칙을 피드백가이드.md로 옮겨 해당 작업을 요청할 때만 읽게 한다. [1:22:01]

44. 문서를 Markdown으로 변환해 필요한 데이터 중심으로 입력한다

• 은행 거래 내역 PDF를 그대로 넣었을 때 분석 전부터 토큰을 많이 소모했다. 필요한 정보는 날짜·금액·거래 내용이었지만, 문서에는 폰트·색상·테두리·머리말·레이아웃 등 표현 요소도 포함돼 있었다. [1:23:06]
• PDF를 먼저 Markdown으로 변환한 뒤 분석에 사용한다. 변환에는 클로드나 무료 도구를 활용할 수 있으며, 텍스트 중심의 자료로 정리하는 것이 목적이다. [1:23:23]

45. 단순 작업은 저렴한 모델과 서브 에이전트에 배분한다

• 매일 받는 해외 뉴스레터 다섯~여섯 개의 번역·요약을 처음에는 Opus에 맡겼다. 단순 요약에는 더 저렴한 모델을 사용할 수 있으므로 서브 에이전트에 Sonnet이나 Haiku를 지정하는 방식으로 바꾼다. [1:24:44]
• 서브 에이전트는 메인과 분리된 대화 공간에서 작업한다. Haiku나 Sonnet은 속도 측면에서도 이점이 있어 간단한 요약 작업의 선택지가 된다. [1:24:56]

46. 지침 축소 전후의 사용량을 실제로 비교한다

• 진단 대상 프로젝트에는 730줄짜리 CLAUDE.md, 일곱 개의 하위 폴더, 과도한 내용과 변환이 필요한 문서가 있었다. 우선순위 작업으로 지침을 200줄 미만으로 줄이는 조치를 실행한다. [1:26:06]
• 실행 결과 CLAUDE.md는 102줄이 됐다. /clear 후 /context로 다시 확인한 메모리 파일 사용량은 9.4K에서 약 2K로 감소했다. [1:26:33]

47. 에이전트 팀은 상호 소통과 공동 검수가 필요한 작업에 쓴다

• 서브 에이전트는 개별 업무를 맡기고 결과를 받는 방식이며, 에이전트 팀은 프론트엔드·백엔드·QA처럼 여러 역할이 동시에 일하면서 서로 문제를 전달하고 수정하는 방식이다. [1:27:39]
• 팀원은 이전 대화나 작업 목적을 자동으로 알지 못하지만 컴퓨터의 파일을 볼 수 있다. 따라서 작업 맥락을 전달하는 프롬프트가 중요하며, 팀 운영의 핵심은 상호 메시지, 공유 작업 목록, 동료 피드백이다. [1:28:14]

48. 실험 기능을 활성화해 에이전트 팀 사용을 준비한다

• 에이전트 팀은 실험 기능이며 기본적으로 비활성화돼 있다. 문서의 활성화 설정을 설정 JSON이나 환경에 추가해야 사용할 수 있다. [1:29:09]
• 예시에서는 활성화 설정을 붙여 넣고 해당 프로젝트의 팀 기능을 켜도록 요청한다. 생성된 로컬 설정 JSON에서 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS가 1로 설정된 것을 확인한다. [1:29:45]

49. 에이전트 팀의 품질을 결정하는 구체적인 작업 지침

• 참고 문서를 읽어 에이전트 팀 구성 가이드를 프로젝트의 docs 폴더에 저장하고, 이후 팀을 만들 때 활용한다. 새로 활성화된 팀원에게 역할만 맡기면 기능·디자인·데이터 연결이 의도와 달라질 수 있다 [1:31:01]
• 프롬프트에는 최종 목표 한 문장, 팀원 수와 사용할 모델, 각 에이전트의 전문 역할·구체적인 작업·담당 파일·결과 전달 대상을 명시한다 [1:31:31]

50. 우선순위 관리 웹앱에서 드러난 데이터 저장 요구사항

• 프런트엔드·백엔드·QA로 구성한 3인 팀에 하루의 업무 우선순위를 정하고, 실행 가이드와 멘토링을 제공하는 웹앱을 맡긴다. 유튜브 편집, 피드백, 독서, 투자 웹 개발 등 다섯 가지 업무가 관리 대상이다 [1:33:22]
• 할 일을 저장해도 새로고침하면 사라지는 문제가 발생한다. 응답 구조와 저장 처리의 오류뿐 아니라, Supabase나 Firebase처럼 데이터를 보관할 공간을 지정하는 요구사항도 프롬프트에 부족했다 [1:34:13]

51. 상호 대화의 필요성으로 구분하는 팀과 서브 에이전트

• 웹 개발이나 리서처·라이터·에디터가 함께 만드는 콘텐츠 파이프라인처럼 여러 전문가가 동시에 소통해야 하는 작업에는 에이전트 팀이 적합하다 [1:35:42]
• 수강생 피드백, 영상 분석, 이메일 정리, 시트 정리처럼 작업자끼리 대화할 필요가 적은 업무는 서브 에이전트로 처리한다. 선택 기준은 작업 중 서로 대화가 필요한지다 [1:36:04]

52. QA의 토큰 낭비를 줄이는 모델 선택과 테스트 준비 분리

• 3인 팀 사용 중 토큰이 세 배 빠르게 소진되는 경험이 있었고, 실제 측정에서는 QA가 전체 토큰의 62%를 사용했다. 테스트 실행보다 프레임워크 설치·설정과 반복 오류 수정에 많은 토큰이 들었다 [1:36:54]
• 개발자는 소넷을 유지하고, 체크리스트 확인과 반복 검증을 맡는 QA·에디터에는 저렴한 모델을 사용한다. 프런트엔드·백엔드는 소넷, QA는 하이쿠로 나누는 절감안의 기대 효과는 토큰 사용량 20~30% 감소다 [1:37:38]

53. 작은 작업의 단독 처리와 담당자·데이터 이름의 명확화

• 파일이 20개 미만인 프로젝트는 혼자 처리한다는 기준을 둔다. 작은 작업에도 팀을 구성하면 협업 비용이 작업 자체보다 커질 수 있다 [1:38:33]
• 요청을 팀 전체에 보내면 여러 에이전트가 파일을 읽으며 토큰을 소비하므로, 해당 작업을 맡은 에이전트에게만 직접 지시한다 [1:39:00]

54. 배포 환경에 맞는 저장소 지정과 전체 변경의 일관성

• 데이터베이스를 알아서 연결하라는 요청에 백엔드는 SQLite 로컬 파일 저장을 선택했다. 배포 후 서버리스 환경에서 데이터가 사라지는 문제가 생겨, Supabase와 테이블·URL·API 키를 구체적으로 지정하는 방식으로 바꿨다 [100:50] [1:40:40]
• SQLite를 Supabase로 바꾸면서 백엔드·프런트엔드·테스트 코드를 모두 수정해야 했다. 이렇게 여러 영역을 함께 바꾸는 작업은 팀으로 나누기보다 한 에이전트가 전체를 일관되게 수정하는 편이 낫다 [101:29] [1:41:27]

55. 노트북을 꺼도 실행되는 클라우드 루틴

• 자동화를 만들어도 매일 직접 켜야 하고 노트북을 끄면 업무가 멈추는 문제는 실행 장소와 연결된다. 루틴은 저장한 작업을 Anthropic 서버에서 실행해 노트북이나 터미널이 꺼져 있어도 돌아가게 한다 [103:37] [1:42:34]
• 루틴의 핵심은 “매일 아침 이런 작업을 해 달라”는 프롬프트다. 사람이 정해진 시간에 직접 입력하던 요청을 클라우드 환경에서 실행한다 [103:57] [1:43:51]

56. 스케줄·이벤트·API 트리거와 외부 도구 연결

• 루틴에는 이름, 지침, 저장소, 모델, 실행 환경을 설정한다. 실행 계기는 정해진 시간의 스케줄, 저장소 변경에 반응하는 GitHub 이벤트, 다른 자동화가 호출하는 API로 나뉜다 [104:42] [1:43:59]
• 스케줄은 가장 짧게 한 시간 간격으로 설정할 수 있고, 특정 분에 실행하거나 매일·평일·매주 반복하도록 지정할 수 있다 [104:58] [1:44:20]

57. 무인 실행을 위한 작은 저장소·환경 변수·명확한 지침

• 저장소를 사용하는 루틴은 GitHub 저장소를 복제해 CLAUDE.md와 스킬 등을 읽고 작업한 뒤 복제본을 없앤다. 큰 프로젝트 전체보다 자동화에 필요한 작은 저장소를 따로 연결하면 불필요한 무게와 토큰 사용을 줄일 수 있다 [106:03] [1:45:53]
• API 키 같은 비밀 정보는 GitHub에 올리지 않고 실행 환경의 환경 변수에 넣는다. 필요한 키가 없으면 외부 도구를 사용하지 못해 자동화가 중간에 멈출 수 있다 [106:56] [1:46:54]

58. 1인 기업 소식 열 가지를 전달하는 아침 루틴

• 매일 오전 8시에 1인 기업 관련 내용 열 가지를 검색해 전달하는 루틴을 구성한다. 검색 초점에는 1인 기업 트렌드와 인사이트, 자동화 도구, 콘텐츠 마케팅 사례를 포함한다 [108:26] [1:47:40]
• 연결된 Gmail 도구가 발송을 지원하지 않아 이메일 자동 수신 대신 초안 생성이나 카카오톡 ‘나와의 채팅’ 발송을 선택해야 했다. 카카오톡을 선택한 초기 시험에서는 검색과 발송 파이프라인이 작동했다 [108:58] [1:48:30]

59. 클라우드 실행을 막은 커넥터 누락과 저장소 승인 규칙

• 클라우드에서 실행하자 카카오 MCP 도구를 사용할 환경이 없어 Gmail 초안으로 대체됐다. 루틴에 커넥터가 연결되지 않은 상태였으므로 플레이 MCP와 Gmail을 연결하고, 데이터 저장을 위해 Supabase도 추가했다 [110:46] [1:50:15]
• 개인 사업 맥락을 반영하려고 기존 비즈니스 저장소를 연결했지만, 두 번째 실행에서는 CLAUDE.md의 외부 메시지 발송 승인 규칙이 카카오 발송을 막았다. 결과는 다시 Gmail 초안으로 저장됐다 [111:45] [1:51:24]

60. 전용 저장소로 수정한 뒤 확인한 실제 발송

• 루틴 지침을 바탕으로 solo-daily-briefing 전용 저장소를 만들고 연결을 교체한다. prompt.md에 실행 지침을 두고, CLAUDE.md에는 피하고 싶은 말투와 자연스러운 한국어 작성 기준을 담는다 [112:33] [1:52:50]
• 새 저장소로 실행한 루틴은 웹 검색 결과에서 열 개 항목을 선정했고, 카카오톡 ‘나와의 채팅’에 메시지가 도착했다 [113:11] [1:52:58]

61. 반복 검증으로 확보하는 자동화와 되찾은 시간

• 원하는 결과가 나오지 않으면 지침을 더 세부적으로 수정하고, API 키는 환경 변수에 넣는다. 시간·GitHub 이벤트·API POST 요청으로 실행을 시작할 수 있으며, 커넥터를 추가해 Notion 등에 결과를 기록하는 방식도 가능하다 [114:03] [1:53:37]
• 손으로 반복하던 업무를 루틴으로 하나씩 옮기면 그만큼 시간을 확보할 수 있다. 확보한 시간을 좋아하는 일에 도전하거나 자신만이 할 수 있는 일에 쓰는 것이 자동화의 최종 목적이다 [115:01] [1:54:42]

🧾 결론

• 자동화는 자신의 브랜드와 사업 시스템을 먼저 정리하고, 그 안의 반복 업무를 하나씩 AI에 위임하는 과정이다.
• AI가 코드를 만들더라도 요구사항 설계, 결과 검토, 보안 점검과 최종 책임은 사람이 맡아야 한다.
• 처음 만든 스킬이나 자동화는 실제 업무 사례와 실패 원인을 반영하며 계속 개선해야 한다.
• 자동화로 확보한 시간을 자신만이 할 수 있는 일이나 새롭게 도전하고 싶은 일에 쓰는 것이 최종 목적이다.

📈 투자·시사 포인트

• 도구 도입의 가치는 설치한 스킬 수보다 반복 작업이 얼마나 줄었는지로 판단한다. 가장 손이 많이 가는 업무 하나에 먼저 적용하는 접근이 제시된다.
• 같은 구독에서도 지침 길이, 대화 누적, 모델 선택과 팀 구성에 따라 사용량이 달라진다. 사업 운영에서는 구독 선택과 함께 작업 방식도 점검필요가 있다.
• 클라우드 자동화의 실용성은 생성 결과뿐 아니라 커넥터 기능, 인증, 데이터 저장소와 예약 실행까지 함께 검증해야 판단할 수 있다.
• 영어권 SaaS 중심의 마케팅 지침은 한국 시장과 자신의 사업에 맞게 수정해야 한다. 지식 관리 역시 사업 기준으로 선별한 자료를 실행에 연결하는 데 의미가 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 구독 조건, 루틴 실행 한도, 에이전트 팀의 실험 기능 상태와 커넥터 지원 범위는 영상에서 설명한 조건이다. 실제 적용 환경에서도 같은 조건인지 확인이 필요하다.
• 카카오톡 브리핑은 수동 시험에서 도착을 확인했지만, 다음 날 오전 8시 예약 발송까지 정상 작동하는지는 확인되지 않았다.
• 컨텍스트 60~70% 리셋, 업무의 80%는 서브 에이전트로 충분하다는 기준, 처리량 두 배 개선은 발표자의 운영 판단과 개인 경험이다. 모든 업무에 동일한 효과를 보장하는 수치는 아니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 업무 하나를 골라 입력·처리·판단·출력, 실행 주기와 실패 시 대응을 작성한다.
• 프로젝트 폴더를 만들고 플랜 모드에서 요구사항과 계획을 검토한 뒤, 샘플 데이터로 결과물을 확인한다.
• 필요한 외부 기능에 맞춰 API·MCP·GWS CLI를 선택하고 인증, 접근 범위와 발송 지원 여부를 시험한다.
• API 키를 별도 비밀 설정 파일이나 실행 환경의 환경 변수에 두고, 배포 전 키 노출과 취약점을 점검한다.

❓ 열린 질문

• 내 업무에서 가장 먼저 위임할 반복 작업은 무엇이며, 어떤 결과가 나와야 성공으로 판단할 수 있는가?
• 외부 자료를 wiki에 넣거나 제외할 사업 기준을 얼마나 구체적으로 정의할 수 있는가?
• 작업 중 전문가끼리 소통이 필요한가, 아니면 개별 서브 에이전트의 결과를 받아 검토하는 것으로 충분한가?