스크립트
00:00:00이 영상은 Cloud Code를 사용하며 겪는 1,000시간 이상의 시행착오를 단축해 드리고,
00:00:04초보자이건, 중급자이건, 전문가이건 상관없이 어디에 집중해야 할지 짚어드릴 것입니다.
00:00:08데스크톱 앱부터 프롬프트 작성법, MCP, CLI,
00:00:12그리고 그래프 엔지니어링이나 나만의 에이전틱 OS 구축 같은 고급 주제까지 모든 것을 다룰 예정입니다.
00:00:18영상이 끝날 때쯤이면 오늘날 가장 강력한 AI 도구를 마스터하기 위한 완벽한 로드맵을 갖추게 될 것입니다.
00:00:22다룰 내용이 정말 많으니 바로 시작해 보겠습니다. 자, 초보자 섹션에서 가장 먼저 이야기해야 할 것은
00:00:27Cloud Code를 어디서 실행해야 하는가입니다. 이것은 실제로 헷갈릴 수 있는 질문이거든요.
00:00:32기술적으로는 클라우드의 웹 앱에서도 Cloud Code를 실행할 수 있습니다.
00:00:37또한 Cloud Code 데스크톱 버전도 있죠. 그리고 물론 터미널도 있습니다.
00:00:43특히 이제막 시작하는 분들이라면 이 세 가지 중 어떤 것을 사용해야 할까요?
00:00:48몇 달 전만 해도 이 질문을 받았다면 터미널이나
00:00:51Cloud Code 확장이 포함된 VS Code 같은 것을 추천했을 것입니다. 하지만 요즘은 데스크톱 앱이
00:00:56훨씬 좋아졌습니다. 기술적 배경이 없고
00:01:01이 모든 것이 완전히 처음이신 분들이라면, Cloud Code 데스크톱 앱을 사용하시라고 제안하고 싶습니다. 물론 터미널은
00:01:07기술에 더 친숙한 분들에게는 언제나 강력한 옵션일 것입니다. 하지만 그게 본인 이야기가 아니라면,
00:01:11편하지도 않은데 억지로 써야 한다는 압박감을 느낄 필요는 없습니다. 요즘은 정말로 손해 보는 것이 없거든요.
00:01:16데스크톱 앱에는 터미널 안에서는 아예 사용할 수 없는 기능들도 탑재되고 있습니다.
00:01:21음성 모드나 브라우저 자동화 같은 기능들이죠. 그리고 데스크톱 앱 안에서 작업할 때
00:01:25인라인 아티팩트처럼 유용한 편의 기능들이 많고, 터미널을 한 번도 써본 적 없는 분들에게
00:01:31전반적으로 더 나은 사용자 경험을 제공합니다. 게다가 데스크톱 앱 내부에서도
00:01:36터미널을 사용할 수 있으므로 양자택일의 문제는 아닙니다. 자, 이제
00:01:40Cloud Code 데스크톱 앱을 다운로드하고 설치하는 것은 매우 쉽습니다. 'Cloud desktop app'을 검색해서
00:01:44첫 번째 링크로 들어가 설치 프로그램을 다운로드하여 실행하면 됩니다. 자, 이제 데스크톱 앱이 설치되었습니다.
00:01:48이 프로그램이 무엇이고 어떤 점에 주목해야 하는지 빠르게 훑어보겠습니다. 설정의 경우,
00:01:53왼쪽으로 와서 'customize'를 누르세요. 그런 다음 일반 탭으로 이동합니다.
00:01:57그리고 Cloud용 지침(instructions for Cloud)을 살펴보세요. 제 화면을 보세요.
00:02:01비어 있습니다. 여러분의 것 역시 비어 있는 편이 좋을 것입니다. 이것은 전역 지침입니다.
00:02:06전역이라는 것은 모든 것, 즉 모든 프로젝트와 모든 프롬프트에 적용된다는 뜻입니다.
00:02:11만약 여기에 '모든 답변이 운율을 맞추게 해줘' 같은 걸 적어두면 어떤 일이 벌어질까요?
00:02:16모든 답변이 운율을 맞추게 될 겁니다. 바보 같은 예시죠. 하지만 핵심은, 여러분이
00:02:21Cloud와 나누는 모든 대화에 항상 적용될 정도로 관련성이 높은 내용을 여기에 명시해야 할까요?
00:02:26그럴 수도 있지만, 기준이 매우 높습니다. 그리고 여기에 추가하려는 내용이 그 기준에 미치지 못한다면
00:02:31비워두는 것을 추천합니다. 다음으로 기능(capabilities)으로 이동하세요. 도구 접근 모드(tool access mode)를
00:02:36'필요할 때 도구 로드(load tools when needed)'로 설정하고 이 페이지의 나머지 항목은 모두 켜두세요.
00:02:41Cloud Code 탭에서는 일반(general) 항목들을 모두 켜두는 편이 좋습니다. 개인 취향에 따른 설정들도 일부 포함되어 있죠.
00:02:47그리고 로컬 세션의 경우에도 이 항목들을 전부 켜두는 것을 추천합니다. 다만 풀 리퀘스트(pull request) 항목은 예외입니다.
00:02:52풀 리퀘스트가 무엇인지 모른다면 그냥 꺼두세요. 약간 더 고급 기능입니다. 그리고 Cloud in Chrome의 경우,
00:02:58Cloud가 브라우저 내의 작업을 제어할 수 있게 해주는 구글 크롬 확장 프로그램인데, 저 역시 이것도 켜둡니다.
00:03:03다만 이를 이용하려면 구글 확장을 다운로드해야 한다는 점을 알아두세요. 기술, 커넥터, 플러그인, 메모리에
00:03:08관해서는 나중에 더 자세히 다룰 테니 지금은 걱정하지 마세요. 자, 여기에는 아티팩트가 있습니다.
00:03:14솔직히 Cloud Code 안에서 아티팩트는 크게 신경 쓰지 않아도 됩니다. 루틴은 실행하는
00:03:18자동화와 관련이 있으며, 자동화에 대해서는 나중에 더 깊게 다룰 것입니다.
00:03:23그리고 이쪽은 이전에 Cloud Code와 나누었던 대화 기록들입니다. 자, 새로 만들기(new)를 누르면
00:03:29이와 같은 페이지가 나타날 것입니다. 우리가 보고 있는 화면을 분석해 보겠습니다. 당연히
00:03:33여기에는 작은 채팅창이 있고, 상단에는 네 가지 항목이 있습니다.
00:03:37Local, 1000이라고 적힌 무언가, main, work tree, 그리고 작은 더보기 버튼이 있죠.
00:03:42Local은 Cloud가 실제로 어디서 실행될지 지정하는 것입니다. 이러한 항목들,
00:03:47즉 Cloud, 원격 제어(remote control), WSL, SSH가 무엇인지 모른다면 99.99%의 경우 Local로 설정해야 합니다.
00:03:53WSL을 제외한 나머지 항목들은 전부 컴퓨터와 멀리 떨어져 있을 때 Cloud를 사용하는 것과 관련이 있습니다.
00:03:58따라서 초보 단계라면 해당 사항이 없을 것입니다. 다음으로, '1000'이라고 적힌 이곳은
00:04:03단순히 제가 작업 중인 폴더입니다. 여기를 클릭하면 새 폴더를 열 수 있으며,
00:04:08작업하고 싶은 컴퓨터 내의 폴더를 아무거나 선택할 수 있습니다. 예를 들어 바탕 화면에
00:04:13'Cloud Code projects'라는 폴더를 만들 수 있겠죠. 그리고 그곳에서 작업하는 것입니다.
00:04:18Cloud Code 안에서 하는 모든 일은 그 폴더 안에 저장됩니다. 그러니 폴더 하나만 선택하시면 됩니다.
00:04:23다음으로 main과 work tree가 있습니다. 이것은 Git과 관련된 것으로, 다소 고급
00:04:26주제입니다. 따라서 Git 초보자로서 아주 단순화해서 설명하자면, Git은 단순히 작업을 저장하는 것과 관련이 있습니다.
00:04:32그러므로 Git이 뭔지 모른다면, 이걸 Git 강좌로 만들 생각은 없습니다.
00:04:36그냥 main으로 유지하고 work tree는 체크하지 마세요. 그리고 플러스 버튼이 있습니다. 이를 통해
00:04:40추가 폴더를 더할 수 있습니다. 즉, 작업 내용이 본질적으로 두 곳에 복제되는 셈이죠.
00:04:44다음은 권한(permissions)입니다. auto를 누르면 다섯 가지 모드가 나타납니다. 이 모드들이란 무엇일까요?
00:04:48우리의 동의를 받거나 받지 않고 Cloud Code가 무엇을 할 수 있는지 권한을 부여하는 것과 관련이 있습니다. 그래서
00:04:55스펙트럼의 한쪽 끝에는 수동(manual) 모드가 있습니다. 이것은 끊임없이 물어보겠다는 뜻입니다. 이거 해도 될까?
00:04:58저거 해도 될까? 수정해도 될까? 스펙트럼의 반대쪽 끝에는 권한 우회(bypass permissions)가 있습니다.
00:05:03다운로드든, 설치든, 삭제든, 수정이든 원하시는 대로 다 할 수 있죠. 다소 무섭기도 합니다.
00:05:07그 중간에는 auto가 있는데, 기본적으로는 권한 우회와 같지만 예외가 있습니다.
00:05:12Cloud Code가 실행하는 명령어를 살펴보고 그것이 위험한지 여부를 판단하는 분류기(classifier)가 존재하거든요.
00:05:17그래서 위험하다고 판단되면 중단시킵니다. 이것이 기본값인 데는 다 이유가 있습니다. 평소에는
00:05:22이 상태로 두어야 합니다. 우리가 다뤄볼 다른 모드는 plan뿐이며, 이에 대해서는 나중에 더 자세히 다루겠습니다.
00:05:26이 플러스 버튼을 누르면 스크린샷 같은 항목들을 추가할 수 있습니다.
00:05:30그리고 마이크가 있죠. 우측 편에는 모델, 작업 강도(effort level), 그리고 컨텍스트 창이 있습니다.
00:05:34어떤 모델을 사용해야 할까요? 글쎄요, 이용 중인 플랜에 따라 다릅니다. 월 20달러짜리 플랜을 쓰고 있다면
00:05:39Fable을 제대로 쓰기는 어려울 것입니다. 사용량이 너무 빨리 소모되거든요.
00:05:42따라서 Opus를 사용해야 할 겁니다. 만약 맥스 플랜(5X, 20X, 즉 월 100~200달러)을
00:05:46이용 중이라면 대부분의 경우 Fable로 작업하는 것을 추천합니다. 단언컨대 가장 뛰어난 모델입니다.
00:05:51다만 문제는 사용량입니다. 여기 있는 이 작은 아이콘을 클릭해보면 아시겠지만
00:05:58컨텍스트 창이 보일 겁니다. 이에 대해서는 나중에 더 이야기하겠습니다. 여러 가지 제한이 존재하죠.
00:06:035시간 제한, 주간 제한, 그리고 Fable 제한이 있습니다. 즉, 매주 사용량의 절반만
00:06:07Fable에 할당할 수 있습니다. 따라서 너무 일찍 Fable 사용량을 다 소모해 버리면 안 됩니다.
00:06:14그러므로 우리가 정말로 고민해야 할 것은 작업 강도(effort level)입니다. 이는
00:06:21low부터 울트라 코드(ultra code)까지 다양합니다. 많이 생각할수록 성능은 좋아지지만,
00:06:27그 관계가 선형적이진 않습니다. extra high에서 ultra code로 올린다고 해서 성능이 10배 증가할까요?
00:06:35아니요. 성능은 1% 정도 늘어나는데 비용은 5배 이상 더 내야 할 수도 있습니다. 사실
00:06:39여러분이 해결하려는 문제들 중 대부분은, 특히 초보 단계에 가까울수록
00:06:43medium을 넘어가는 수준을 요구하지 않습니다. 사실 low로 두고도 충분히 해낼 수 있을 겁니다.
00:06:48저 같은 경우는 꽤 복잡한 걸 다루거나 사용량 초기화가 임박해서 마음껏 써도 될 때가 아니면
00:06:52대부분 Fable medium으로 둡니다. 그러니 오늘 우리는 Fable 5 medium으로
00:06:57설정하겠습니다. 훌륭하고 만족스러운 절충안이니까요. 즉, 낮은 작업 강도는 사용량을 적게 쓰고,
00:07:03성능이 아주 뛰어나진 않지만 대개 충분하고도 남을 만큼의 결과를 보여줍니다.
00:07:07이제 프롬프트 작성에 대해 이야기해 봅시다. 새로운 프로젝트를 시작하기 위해 프롬프트를 입력할 때는 언제나,
00:07:12정말 간곡히 플랜 모드(plan mode)로 들어갈 것을 권장합니다. 자, 왜 그럴까요? 글쎄요, 플랜 모드를 이용하면
00:07:18Claude가 무언가를 실행에 옮기기 전에 서로 의견이 일치하는지 확인하기 위한 대화를 나눌 수 있기 때문입니다.
00:07:22그리고 더 중요한 것은, 그저 대화를 나누는 것에 그치지 않고 Claude가 여러분에게
00:07:27질문을 던질 것이라는 점입니다. 왜냐하면 많은 경우, 특히 A, 비기술적 배경을 가지고 있거나
00:07:33B, 본인의 전문 분야가 아닌 프로젝트를 시도하려고 할 때 AI를 사용하면서 겪게 되는 문제는
00:07:38모르는 것이 너무나도 많다는 점입니다. 그리고 자신이 무엇을 모르는지조차 모르는 것들이 너무 많습니다.
00:07:43이러한 '알지 못한다는 사실조차 모르는 것들(unknown unknowns)'은 진짜 문제입니다.
00:07:49그리고 이를 해결할 수 있는 유일한 방법은 Claude Code가 그러한 점들을 직접 끌어내어
00:07:54존재조차 몰랐던 어두운 영역에 빛을 비춰주도록 하는 것입니다.
00:07:58그리고 플랜 모드는 그 문제를 해결하는 가장 간단한 방법입니다. 우리에게 질문을 하도록 강제하기 때문이죠.
00:08:02따라서 A 단계에 있고 Z 단계로 가고 싶긴 한데 무엇을 해야 할지 막연한 아이디어만 있는 상태라면 플랜 모드로 들어가야 합니다.
00:08:07자, Claude Code에 프롬프트를 입력할 때 과거 지난 1~2년 전쯤에는 이게 아주 큰 이슈였고
00:08:12지금은 이런 경향이 조금 줄어들긴 했습니다. 하지만 여전히 사람들은 뭔가 마법 같은 프롬프트가 존재하며
00:08:15조금 사라지긴 했지만 여전히 마법 같은 프롬프트가 따로 있어서
00:08:19특정 형식에 맞춰 입력해야 한다고 생각하는 사람들이 있습니다. 예를 들어 목표는 이거고,
00:08:22맥락은 이렇고, 이런 방식으로 행동해 달라고 하는 식이죠. 하지만 그럴 필요는 없습니다.
00:08:25필요한 건 마이크를 하나 사고, 마이크를 켠 다음에
00:08:29Claude Code에 의식의 흐름대로 말해주는 것입니다. 우리가 만들 이 웹사이트의 계획을 위해
00:08:33가짜 AI 분석 기업을 위한 웹사이트라고 하고, 이름을 Lighthouse라고 지어보겠습니다.
00:08:41제가 할 일은 그게 전부입니다. 그냥 아무 말이나 늘어놓는 거죠.
00:08:46여기에는 계획이랄 게 없습니다. 대략 이렇게 말하겠죠. 가짜 AI 분석 기업인
00:08:54Lighthouse라는 가상의 AI 분석 회사 웹사이트를 만들고 싶어. 웹사이트에 뭐가 들어가야 할지 잘 모르겠고,
00:09:02마지막에는 우리와 통화를 예약해 달라는 유도 문구가 들어갔으면 좋겠어. 그게 주요 유도 문구가 될 거야.
00:09:07타겟 오디언스의 경우 소규모 스타트업을 대상으로 한다고 해보자. 그 외에는
00:09:12무엇이 빠졌는지 잘 모르겠어. 내가 생각하지 못한 것 중에 관련이 있다고 생각되는 질문들을 편하게 해줘.
00:09:18이제 여러분이 주목했으면 하는 점은 제가 마지막에 질문을 던지라고 했던 바로 그 부분입니다.
00:09:22지금은 플랜 모드 상태이기 때문에 어차피 그렇게 작동할 것입니다. 하지만 Claude에게 프롬프트를 입력할 때는
00:09:27항상 이런 내용을 끝에 추가할 수 있습니다. 내가 생각하지 못한 게 뭘까?
00:09:31나한테 할 질문이 어떤 게 있지? 이런 식이죠. 이렇게 하면 다시 한 번
00:09:37Claude Code와 주고받는 상호작용을 유도할 수 있습니다.
00:09:41어떤 시점에서든 이런 식으로 질문을 던져올 수 있기 때문입니다.
00:09:44자, 이 가짜 사이트의 목적은 무엇인가? 디자인 및 개발 연습용이라고 해두죠.
00:09:49Lighthouse는 실제로 무엇을 하는가? 제품 분석 및 AI 인사이트를 제공한다고 하겠습니다.
00:09:56규모는 어느 정도로 할 것인가? 랜딩 페이지 수준으로 합시다. 그리고 디자인의 분위기는 어떻게 할 것인가? 깔끔하고 밝은 SaaS 느낌으로 가겠습니다.
00:10:06다음으로 사이트 구축에 사용할 기술 스택을 묻습니다. 일반 HTML, CSS/JS, Next.js + Tailwind, 아니면 Astro + Tailwind 중 무엇을 원하나요?
00:10:12여러분은 저것들 중 아는 것이 있나요? 진심으로, 저게 뭔지 조금이라도 아시나요?
00:10:18기술 스택이 뭔지나 아시나요? 대답이 아니오라면, 우리는 어떻게 해야 할까요? 그냥 추천하는 것으로 갈까요?
00:10:23네, 하지만 아니오입니다. 여기에 많은 사람들이 빠지는 문제가 있습니다.
00:10:28기술 스택이 뭔지도 관심 없고, 그냥 일반 HTML로 추천해 달라고 하지 뭐 하고
00:10:33그냥 이걸 클릭해 버리는 것입니다.
00:10:38문제는 이 모델들이 너무 뛰어나서 여전히 꽤 괜찮은 결과물이 나온다는 점입니다.
00:10:41문제가 되는 것은 질문을 이해하려 하지 않고 그냥 추천 옵션을 계속해서 반복해서 누르는 행동을
00:10:45반복할 때 발생합니다. 핵심적인 문제는 거리의 지나가는 아무 사람이나 컴퓨터 앞에 앉혀서
00:10:50똑같이 시켰을 때와 여러분 사이에 아무런 차별점이 없어진다는 것입니다.
00:10:54여러분이 하는 일에 무슨 독보적인 경쟁력이 있겠습니까? 완전히 대체 가능한 사람이 되는 거죠.
00:10:59하지만 더 중요한 건, 아무것도 배우지 못하고 있다는 사실입니다. 이 모델들이 아무리 뛰어나도
00:11:04결국에는 Claude가 최적의 접근법을 모를 수도 있는 아주 독창적인 개인 프로젝트를 진행하게 될 것입니다.
00:11:08만약 아무것도 배우지 않은 채 매번 추천, 추천, 추천만 누르면서 Claude Code 사용법을 익혀왔다면
00:11:13실제로 무슨 일이 일어나고 있는지 전혀 알 수 없을 것입니다.
00:11:17이제 다시는 코드를 직접 배울 필요는 없지만, AI 소프트웨어 엔지니어링의 기본기만큼은 익히기 시작해야 합니다.
00:11:23큰 그림을 보는 법이나 이러한 구성 요소들이 어떻게 결합되는지 이해하는 것 말입니다.
00:11:30그리고 그럴 수 있는 유일한 방법은 이런 질문을 마주쳤을 때 무조건 추천을 누르는 대신
00:11:34이런 식으로 말하는 것입니다. 기술 스택이 정확히 무엇인지 설명해 줄 수 있나요?
00:11:40잘 모르겠어요. 이 옵션들도 잘 이해가 안 갑니다. 그러니 내가 무엇을 보고 있는지
00:11:44간단하게 요약해서 설명해 줄래요? 그게 전부입니다. 질문에 대해 조금 더 자세히 설명해 달라고 요청하는 거죠.
00:11:49이 작업을 몇 주, 몇 달, 몇 년 동안 계속 반복하면 결국 실제 기반을 다지게 될 것이며
00:11:53이런 식의 겉멋만 번지르르한 바이브 코더의 캐리커처 같은 모습이 되지 않을 것입니다.
00:11:58이것은 극도로 중요합니다. 무엇인가를 진정으로 배우고 싶다면
00:12:02Claude Code와 대화하고 프롬프트를 작성할 때 가져야 할 사고방식 바로 이것입니다.
00:12:07그럼 가격 책정과 제품 기능으로 하겠습니다. 좋습니다.
00:12:12예약 콜 CTA는 어떻게 작동하게 할까요? 가짜 예약 양식을 만들겠습니다.
00:12:21이제 본격적으로 시작됩니다. 여기서 볼 수 있듯이 기술 스택이 무엇인지에 대한 질문을 분해한 다음
00:12:27각 항목이 무엇인지 좀 더 자세히 설명해 줍니다. 다시 말하지만, 이 모든 것의 전문가가 될 필요는 없습니다.
00:12:31하지만 이 과정을 반복하고 자신에게 의미가 있을 때 깊이 파고들다 보면
00:12:35일반적으로 조각들을 맞춰나갈 수 있게 됩니다.
00:12:39이건 그렇게 복잡하지 않습니다. 코딩이 어렵긴 하죠. 진정한 의미의 소프트웨어 엔지니어가 되라고 요구하는 사람은 아무도 없습니다.
00:12:47하지만 기술 스택이 무엇인지 배울 수 있고, 이러한 다양한 언어가 무엇이며
00:12:52각각의 유스케이스에서 무엇을 해야 하는지 배울 수 있습니다. 이제 계획을 제안하면
00:12:56오른쪽 창에 채워지는 것을 볼 수 있습니다. 데스크톱 앱 내의 플랜 모드에서 멋진 점은
00:13:01이 창이 뜰 때 언제든지 특정 항목을 선택할 수 있다는 것입니다.
00:13:07타겟 오디언스의 경우 소규모 스타트업만 원한 게 아니라고 해보죠. 중소기업도
00:13:13추가하고 싶었다고 가정해 봅시다. 그렇게 하고 댓글을 누르면 이제
00:13:22여기에 코멘트 같은 것들이 추가되기 시작합니다. 따라서 계속해서 코멘트를 추가하여
00:13:27작성된 계획에 대한 작은 메모처럼 활용할 수 있습니다. 또한 원하는 프롬프트를 추가할 수도 있습니다.
00:13:31그런 다음 언제든지 자, 이걸 수정합시다라고 말할 수 있습니다. 그러면 오디언스에
00:13:37중소기업도 추가됩니다. 계획이 마음에 들면 수락 또는 자동 모드로 수락을 누르면 됩니다.
00:13:43자동 모드로 수락을 눌러야 합니다. 그렇지 않으면 수동 모드로 실행되기 시작하는데 우리는 그걸 원하지 않으니까요.
00:13:48그러니 자동 모드로 수락을 누릅니다. 이제 우리를 위해 웹페이지가 구축되었습니다.
00:13:52이 시점에서 우리는 Claude Code와 관련된 중급 수준의
00:13:57기술, 팁, 노하우 단계로 넘어가게 됩니다. 하지만 그 전에,
00:14:01오늘의 스폰서인 저의 한마디가 있겠습니다. 바로 어제, 저는 완전히 업데이트된 버전의
00:14:06Claude Code 마스터클래스를 출시했습니다. 오늘 영상에서 표면적으로 다루었던 모든 주제를 훨씬 더 깊이 다룹니다.
00:14:12비전공자이면서 이 놀라운 도구를 마스터하는 법을 정말 배우고 싶어 하는 분들에게 완벽한 장소입니다.
00:14:17이 강좌를 이용하고 싶다면, Chase AI 플러스에서 찾아볼 수 있으며
00:14:22고정 댓글에 링크가 있습니다.
00:14:27그럼 웹사이트를 만들어 봅시다. 하지만 제가 실제로 집중하고 싶은 것은 저 아래에 있는 이 녀석,
00:14:31이 작은 동그라미입니다. 우리의 사용량을 보여주던 이거 기억하시나요? 이것은 이제 우리의 컨텍스트 윈도우도 보여줍니다.
00:14:37그리고 컨텍스트 윈도우를 클릭하면 실제로 무엇이 그것을 채우고 있는지에 대한 아주 구체적인 내역을 보여줍니다.
00:14:41자, 컨텍스트 윈도우는 몇 가지 이유로 항상 주시해야 하는 매우 중요한 지표입니다.
00:14:47첫 번째 이유는 성능과 관련이 있습니다. 하지만 이걸 이해하려면
00:14:51토큰과 컨텍스트를 이해해야 합니다. 아주 단순화해서 말하자면, Claude Code에 보내는 모든 단어와
00:14:57받는 모든 단어는 토큰으로 간주됩니다. 토큰은 대형 언어 모델의 화폐입니다.
00:15:03그리고 컨텍스트 윈도우는 예산입니다. 따라서 각 세션에서 기본적으로 사용할 수 있는 100만 토큰의 예산이 있습니다.
00:15:09그리고 지금까지 15만 6천 토큰을 사용했습니다. 아주 좋아 보입니다. 15%밖에 쓰지 않았으니
00:15:1684만 4천 토큰을 더 쓸 수 있습니다. 음, 그렇기도 하죠. 문제는 이 컨텍스트 윈도우가 채워질수록
00:15:25실제로 Claude Code의 성능이 떨어진다는 점입니다. 뇌에 너무 많은 정보가 들어 있는 것과 같다고 생각하면 됩니다.
00:15:31100만 토큰 중 80만 토큰을 채운 상태에서 앞서 80만 토큰 동안 일어났던 일에 대해 질문하면
00:15:38모델이 어려움을 겪게 됩니다. 특히 중간쯤에 일어났던 일에 대해 질문할 때는 더욱 그렇습니다.
00:15:43그렇기 때문에 성능 저하를 막기 위해 항상 컨텍스트 윈도우를 예의 주시해야 합니다.
00:15:49이 성능 저하는 어느 정도 선형적으로 일어나며, 거기에 정확한 과학적 공식이 있는 것은 아닙니다.
00:15:53경험 법칙상 대략 30%, 40%, 확실히 50%인 50만 토큰에 도달하면
00:16:00이 세션을 계속 진행해야 할지 반드시 멈춰 서서 자문해 보아야 합니다. 저의 경우는 실제로 30% 정도일 때 그렇습니다.
00:16:06여기서 볼 수 있듯이 컨텍스트 윈도우는 우리의 메시지 외에도 시스템 도구 및 스킬 같은 것들로 채워지지만
00:16:11가장 큰 비중을 차지하는 것은 메시지입니다.
00:16:15컨텍스트 윈도우가 30%, 혹은 50%에 도달했다고 해봅시다. 어떤 선택지가 있을까요?
00:16:22사실 우리에게는 단 하나의 선택지만 있습니다. 바로 새 채팅을 시작하는 것입니다. 자, 새 채팅을 시작할 겁니다.
00:16:31이를 수행하는 방법에는 몇 가지가 있습니다. 슬래시 명령어를 사용할 수 있죠.
00:16:39clear를 입력하면 모든 것이 지워지고 완전히 새로 시작하게 됩니다.
00:16:43아주 새로운 컨텍스트 윈도우로 최고 성능을 발휘할 수 있죠. 다른 선택지로는
00:16:48슬래시 콤팩트(compact)를 사용하는 것입니다. 슬래시 콤팩트를 입력하면 클라우드 코드가
00:16:53우리가 나눈 전체 대화 기록을 살펴본 후 새로운 요약본을 만들고
00:16:57그 요약본을 바탕으로 새 채팅을 시작합니다. 또 다른 방법은 저쪽으로 가서
00:17:02플러스 버튼을 누르는 것입니다. 그러면 동일한 폴더 내에서 새 채팅이 시작됩니다. 언제든지 이전 채팅을 참조할 수 있죠.
00:17:06두려운 점은, 특히 주로 웹 앱을 사용해 온 경우 대화 내용이 전부인 경우가 많기 때문에
00:17:11대화를 없애면 모든 것을 잊어버린다고 생각한다는 것입니다.
00:17:16잊지 마세요. 우리는 지금 특정 폴더 안에서 작업하고 있습니다.
00:17:201000번 폴더 안에서 웹사이트를 만들고 있죠. 따라서 이 전체 대화를 지운다고 해도,
00:17:26여전히 파일과 우리가 작성한 모든 코드를 살펴보고 무슨 일이 일어나는지 파악할 수 있습니다.
00:17:31그러므로 새로운 채팅을 시작하는 것은 말 그대로 제로에서 시작하는 것이 아닙니다. 그럴 경우 정말 두려워할 필요가 전혀 없죠.
00:17:36컨텍스트 윈도우가 채워지고 처음부터 다시 시작하는 게 두렵다면 괜찮습니다.
00:17:40그냥 다시 시작하세요. 최악의 경우 slash compact로 요약하게 만들면 됩니다. 하지만 시점상으로,
00:17:45우린 아직 16%밖에 쓰지 않았습니다. 그러니 괜찮습니다. 이제 이 웹사이트에 대해 조금 이야기해 봅시다. 이 웹사이트는,
00:17:53못생겼습니다. 이 웹사이트는 사실 꽤 구리고 진부합니다. 그리고 참고로 저는 이걸
00:18:00Claude Code 데스크톱 앱 내부의 브라우저 창에서 보고 있습니다. 그래서 여기서 정말 많은 작업을 할 수 있죠. 예를 들어 이걸 열면,
00:18:05특정 항목을 선택하고 플랜 모드에서처럼 여기에 코멘트를 남길 수 있습니다.
00:18:11그러면 프롬프트에 반영되죠. 실제로 주석을 달며 '야, 이거 쓰레기야' 같은 식으로 말할 수도 있습니다. 그러면
00:18:17코멘트에도 추가됩니다. 원한다면 여기서 마이크로 편집 같은 걸 아주 쉽게 할 수 있죠. 하지만 우리가 해결해야 할 큰 문제는,
00:18:24이 웹사이트처럼 대체 왜 이렇게 끔찍해 보이는가 하는 점입니다? 이거 꽤 끔찍해 보이네요.
00:18:28왜냐하면 첫째, 어떻게 보이길 원하는지에 대한 충분한 컨텍스트를 주지 않았고, 어떠한 영감도 주지 않았으며,
00:18:35스크린샷도 제공하지 않았기 때문입니다. 우리가 한 말이라고는 깔끔한 SaaS 제품을 원한다는 것뿐이었습니다. 그리고
00:18:39중급 섹션의 주제 중 하나는 컨텍스트 엔지니어링입니다. 즉 여러분의 생각과 비전뿐만 아니라,
00:18:44외부 도구와 스킬에도 Claude Code가 접근할 수 있도록 만들어 더 나은 작업을 수행할 수 있게 하는 능력 말입니다.
00:18:50더 나은 결과물을 낼 수 있도록 말이죠. 이 문제를 해결하기 위한 두 가지 단계라고 볼 수 있습니다.
00:18:55스킬은 아마 여러분이 Claude Code 성능을 한 단계 끌어올리기 위해
00:19:00반드시 이해하고 마스터해야 할 가장 중요한 것일 겁니다.
00:19:06가장 단순화된 상태의 스킬은 (조금 더 복잡해지기도 하지만) 단순히 프롬프트입니다.
00:19:11Claude Code에게 특정 방식으로 특정 작업을 수행하도록 지시하는 프롬프트죠. 예를 들어, 더 나은 웹사이트를 만드는 것과 관련된 수많은 프런트엔드
00:19:17디자인 스킬들이 있습니다. 본질적으로 그것들은 Claude Code에게
00:19:22야, 이 웹사이트를 만들 때는 특정 그라데이션을 피하고, AI 찌꺼기처럼 보이는 것들을 피해라,
00:19:27이것을 해라 저것을 해라 하고 지시하는 프롬프트일 뿐입니다? 그냥 구체적인 지시사항을 주는 것뿐이죠. 스킬이라는 건 그게 다입니다.
00:19:32그렇다면 스킬은 실제로 어떻게 얻을까요? 클로드 앱 안에서 찾을 수 있습니다. 사용자 지정(Customize)으로 가면,
00:19:37이걸 이쪽으로 옮기고, 스킬(Skills)로 내려가면 됩니다. 여기에 제가 가지고 있는 몇 가지 스킬들이 보이시죠.
00:19:44플러그인도 있는데, 이 역시 스킬의 일종일 수 있어서 약간 회색 지대입니다. 특히 앱에서
00:19:49스킬 대 플러그인에 대해 이야기할 때, 대략 같은 것으로 생각해도 무방합니다. 플러그인에는
00:19:54여러 스킬이 포함될 수 있지만 좀 임의적인 면이 있습니다. 예를 들어 플러그인에 가서
00:19:59찾아보기(Browse)를 누르면, 무엇을 보게 될까요? 앤스로픽 공식 플러그인들이 보입니다. 여기에는
00:20:04프런트엔드 디자인 플러그인이 포함되어 있는데, 이는 단순히 프런트엔드 디자인 스킬입니다. 이걸 설치하면,
00:20:10(제 건 이미 설치되어 있네요) Claude Code에 프런트엔드 디자인 스킬이 추가됩니다. 그리고 이것이
00:20:15실제 프런트엔드 디자인 스킬의 프롬프트입니다. 이건 공식 스킬이라서 직접 가서 볼 수 있습니다.
00:20:19공식 Claude Code GitHub에 올라와 있죠. 이 전체 내용을 복사해서 여기로 돌아와,
00:20:24프롬프트에 붙여넣는다면, 마치 스킬을 사용하는 것과 같습니다. 하지만 당연히 프런트엔드 디자인과 관련된
00:20:30작업을 할 때마다 매번 그렇게 하지는 않겠죠. 대신에 우리는 단순히
00:20:34UI에서 보여드렸듯이 스킬을 추가하고 프런트엔드 디자인을 실행합니다. 슬래시를 입력하면
00:20:40이제 이게 호출됩니다. 그 전체 내용을 복사해서 붙여넣은 것과 똑같습니다.
00:20:44꼭 슬래시를 쓰지 않아도 자연어를 사용해서 프런트엔드 디자인 스킬을 사용해줘
00:20:49라고 말할 수 있습니다. 그러면 그걸 호출해야 한다는 걸 알 정도로 똑똑하죠. 혼란이 생길 수 있는 경우는
00:20:53프런트엔드 디자인과 관련된 스킬이 여러 개 있을 때입니다. 만약 그렇다면
00:20:58그냥 야 나 웹사이트 만들고 있어라고만 말하면 어떤 걸 골라야 할지 모를 수 있습니다. 따라서 비슷비슷한 일을 하는 스킬이 여러 개 있다면
00:21:02클로드에게 올바른 방향으로 넌지시 힌트를 주어야 합니다. 자, 지금 당장 추가할 수 있는
00:21:05가장 중요한 스킬은 웹 디자인을 넘어서는 것으로, 플러그인으로 돌아가서
00:21:10찾아보기(Browse)를 누르고 스킬 크리에이터(Skill Creator)로 가는 것입니다. 이건 여러분이 추가할 수 있는 가장
00:21:16중요한 스킬입니다. 다른 스킬을 만들 수 있게 해주는 스킬이기 때문이죠. 여기에는
00:21:21스킬 성능 측정, 테스트 실행, 평가(evals), 벤치마크 같은 기능들이 포함되어 있으며, 이에 대해서는 잠시 후에 더 이야기하겠습니다.
00:21:27하지만 여기서 살펴보면 알 수 있듯 선택할 수 있는 스킬이 그리 많지는 않습니다. 그리고 우리 모두 알다시피
00:21:31세상에는 10억 개가 넘는 스킬들이 떠돌고 있습니다. 따라서 보통 스킬을 찾게 되는 곳은
00:21:35여기서 보시는 것과 같은 GitHub입니다. 예를 들어 다른 프런트엔드 디자인 관련 스킬을 사용하고 싶다고 해보죠.
00:21:40그리고 완벽한(impeccable) 스킬을 찾고 있었는데 GitHub에서 그것을 발견했다고 가정해 봅시다. 자, 이걸 어떻게 설치할까요?
00:21:45설명에 단계별로 방법이 나와 있긴 합니다. 하지만 종종 좀 귀찮을 때가 있죠.
00:21:49마음에 드는 스킬을 찾았을 때 해야 할 일은, GitHub에서 URL을 복사하여 Claude Code 안으로 들어가
00:21:53그 스킬을 붙여넣고 '이 스킬을 추가해줘' 같은 말을 하는 것입니다.
00:22:01그러면 문자 그대로 여러분의 레퍼토리에 그 스킬이 추가됩니다. 그리고 나서 보여드린 것처럼 그냥 호출하면 되죠.
00:22:07이제 스킬과 관련해서는 꽤 고급 단계로 나아갈 수 있습니다, 특히 스킬 크리에이터 스킬을 가지고 있을 때 말이죠.
00:22:12예를 들어 이 영상을 다 마치고 나서, 이 웹페이지에 새로운 것들을 잔뜩 추가했다고 해봅시다.
00:22:16프롬프트를 입력하고, 웹사이트를 만들고, 추가 작업을 하고, 원하는 걸 더 넣는 등 이 모든 과정을 끝낸 시점에
00:22:21이런 작업을 할 수 있습니다.
00:22:26스킬 크리에이터 스킬을 사용하자고 한 뒤,
00:22:30세션의 전체 메시지 기록을 살펴보고, 오늘 우리가 한 모든 것을 살펴본 뒤 그걸 스킬로 만들어줘라고 말하는 식이죠.
00:22:35따라서 여러분이 반복해서 계속하는 작업이 있다면, 그것들을 스킬로 만들 수 있습니다. 나중에는
00:22:39그러한 스킬을 자동화로 전환하는 방법까지 보여드리겠습니다. 스킬이 매우 강력한 이유는
00:22:44AI가 하는 일을 체계화할 수 있게 해주기 때문입니다. AI의 문제점 중 하나는
00:22:48다소 비결정론적이라는 점입니다, 맞죠? 어떤 일을 10번 요청하면
00:22:5310가지 다른 방식으로 수행할지도 모릅니다. 결정론적이지 않은 거죠.
00:22:58하지만 스킬을 사용하면 어느 정도 결정론적으로 만들 수 있고 클로드가 작업을 수행하는 방식에 더 많은 통제력을 가질 수 있습니다.
00:23:04그것이 바로 스킬이 그토록 중요한 이유입니다. 앞서 언급했듯이
00:23:08스킬을 넘어 여기에 더 많은 컨텍스트를 추가해야 합니다. 그래서 제가 하려는 것은
00:23:12웹사이트를 좀 더 멋지게 만들기 위해 추가할 수 있는 몇 가지 스크린샷을 검색하는 것입니다. 그래서 핀터레스트에 가서
00:23:16SaaS 랜딩 페이지를 검색했을 때 이 이미지를 찾았는데 꽤 멋져 보였습니다.
00:23:20따라서 우리가 할 일은 이 스크린샷을 여기에 떨어뜨리는 것입니다. 그러고 나서 이렇게 말할 거죠.
00:23:25프런트엔드 디자인 스킬을 사용하여 이 웹페이지를 재설계해줘. 사실
00:23:303가지 버전을 만들어서 제가 선택할 수 있도록 브라우저 창 안에 세 버전 모두 보여줬으면 좋겠어.
00:23:37모두 어느 정도 이 스타일을 따르되, 약간의 차이점을 볼 수 있을 만큼
00:23:40충분히 독창적이었으면 좋겠어. 그러자 우리가 요청한 그대로 정확히 수행했습니다. 이걸 보면,
00:23:45이제 웹사이트의 세 가지 다른 버전을 볼 수 있습니다. 우리가 방금 보던 것과 얼마나 크게 달라졌는지
00:23:50확인할 수 있죠. 그리고 그것은 앤스로픽의 일반적인 프런트엔드 디자인 스킬과
00:23:55스크린샷과 함께 제공된 꽤 기본적인 프롬프트 하나로 된 결과입니다. 그럼 이걸 한번 살펴보겠습니다.
00:24:03V1 풀 사이즈입니다. 이거 꽤 멋져 보이네요. V2도 있는데, 색상은 그다지 마음에 안 들지만
00:24:11레이더는 좀 멋져 보이네요. 그리고 마지막으로 V3가 있습니다, 솔직히 말해서 전형적인 AI 찌꺼기처럼 보입니다.
00:24:17저는 V1이 정말 마음에 듭니다. 이거 꽤 멋져 보이는 것 같아요. 그래서 우리가 할 일은
00:24:24야, 그냥 V1으로 가자고 말하는 것입니다.
00:24:26이것이 보여주려는 것은 문자 그대로 컨텍스트를 주입하는 힘입니다, 단 하나의 스크린샷과 스킬 하나로
00:24:31끝 결과물이 무한히 달라질 수 있다는 것이죠. 자, 이제 이야기해 봅시다.
00:24:36외부 도구를 가져오고, 외부 응용 프로그램을 Claude Code 자체에 연결하여
00:24:42클로드가 그것들을 제어할 수 있도록 함으로써 Claude Code를 슈퍼차지하는 방법에 대해 말이죠. 그리고 우리는 앱을
00:24:47정말로 떠날 필요조차 전혀 없습니다. 이를 수행하는 방법에는 실제로 세 가지가 있습니다. 첫 번째는 사용자 지정(Customize)으로 들어가
00:24:53커넥터(Connectors)로 향하는 것입니다. 이 중 일부는 연결하기가 매우 쉬워서 이미 해보셨을지도 모릅니다.
00:24:57예를 들어 Gmail, Google 캘린더, Google 드라이브 같은 것들이죠. 이를 통해 클로드는
00:25:02이러한 애플리케이션과 대화하고 제어할 수 있게 됩니다, 대개 몇 가지 가드레일이 적용된 상태로 말이죠.
00:25:06그리고 이건 프롬프트를 통해 이루어집니다. 따라서 제가 Claude Code에게 야 내 Gmail 좀 읽어줘라고 말하면, 연결되어 있기 때문에 그렇게 합니다.
00:25:11자, 세상의 대다수 대형 앱들은 어떤 형태든 커넥터를 가지고 있습니다. 따라서
00:25:16추가(Add)를 누르고 커넥터를 찾아보면, 찾고 있는 것을 발견할 가능성이 높습니다. 두 번째 방법은
00:25:22플러그인을 통한 것입니다. 그리고 말씀드렸듯이 이 모든 것들 사이에는 아주 모호한 경계가 존재합니다. 커넥터와 마찬가지로
00:25:28규모가 크고 유명하다면 그것을 위한 플러그인이 아마 존재할 것입니다. 따라서 찾아보기(Browse)로 가면,
00:25:34먼저 앤스로픽 플러그인들이 여러 개 보일 텐데, 그것들은 사실 그냥 스킬입니다. 하지만
00:25:39파트너(Partners)로 가면 GitHub이나 Supabase 같은 것을 찾을 수 있습니다. 그것을 클릭하면
00:25:44후드 아래에서 어떤 일이 일어나고 있는지 볼 수 있습니다. 이 경우 이것은 GitHub MCP입니다. 커넥터와 마찬가지로
00:25:50어떤 플러그인을 추가하면, Claude Code를 통해 외부 애플리케이션과 대화하고 제어할 수 있게 됩니다.
00:25:55하지만 MCP나 플러그인, 커넥터가 아닌 세 번째 방법이 존재합니다, 그것들은 바로
00:26:01이런 CLI 같은 것들이 있습니다. 여기 GitHub CLI가 있죠. 즉, GitHub CLI와 GitHub MCP가 모두 있는 셈입니다.
00:26:08둘의 차이점은 무엇일까요? 실무적인 적용 관점이나 여러분이 신경 써야 할 부분을 보면 약간의 기술적인 차이가 있습니다.
00:26:13대개의 경우 엄청나게 큰 차이는 없습니다. 일반적으로
00:26:19CLI는 MCP보다 더 많은 기능을 제공하는 경향이 있습니다. 그리고 대개 CLI에는 스킬도 함께 포함되어 있죠.
00:26:26따라서 외부 애플리케이션을 다룰 때, 즉 클라우드 코드(Cloud Code) 안에서 작업하면서
00:26:31다른 무언가와 통신해야 할 때, 커넥터, 플러그인, CLI 이 세 가지 방법 중 어디에 추가할 수 있는지 파악해야 합니다.
00:26:36보신 것처럼 커넥터와 플러그인은 물론이고, 여기서는 CLI를 통해서도 이를 수행할 수 있습니다.
00:26:42클라우드 코드에 CLI를 추가하라고 간단히 지시하기만 하면 됩니다. 마치 GitHub
00:26:49CLI의 경우 터미널 안에서 실행하는 실제 명령어가 있는 것처럼 말이죠. 하지만 저는 그냥 URL을 복사할 수도 있습니다.
00:26:54“야, 여기 GitHub용 CLI가 있어. 가서
00:27:01이 CLI를 추가해 줘”라고 클라우드 코드 안에서 말할 수 있습니다. 그러면 정확히 그 작업을 수행합니다. 그로부터 여러분은 사실상 클라우드 코드에 부여하게 되는 셈이죠.
00:27:08그 CLI를 호출하고 해당 CLI가 할 수 있는 기능을 수행하도록 만드는 일종의 스킬로 생각하시면 됩니다.
00:27:14GitHub의 경우, 리포지토리를 생성할 수 있다는 뜻입니다. 방금 만든 이 모든 코드를
00:27:19해당 리포지토리에 업로드할 수 있죠. 리포지토리를 수정할 수도 있습니다. 여기서 한 걸음 더 나아가
00:27:25Vercel 같은 것을 예로 들어보죠. 잘 모르실 수도 있겠지만 Vercel은 웹 애플리케이션을 호스팅할 수 있는
00:27:31서비스입니다. 방금 웹사이트를 만들었는데 이를 웹에 올려 실제 URL을 갖고 싶다면
00:27:35Vercel을 사용하면 그렇게 할 수 있습니다. 음, Vercel 내부의 이런 대시보드에 들어가서 직접 모든 걸 처리하는 대신,
00:27:40그냥 Vercel CLI를 검색해 보면 어떨까요? 오, 저기 보세요. Vercel에도 CLI가 있습니다.
00:27:46따라서 이 두 가지 애플리케이션만 가지고 우리가 할 수 있는 일은, GitHub 커넥터가 있는지 확인해 보는 것입니다.
00:27:52있죠. GitHub 플러그인이 있는지 확인할 수도 있습니다. 있죠. GitHub CLI가 있는지
00:27:57확인할 수도 있습니다. 있습니다. 그중 아무거나 추가하세요. Vercel과 함께 추가하면,
00:28:04제가 만든 웹사이트를 가져와서 GitHub 내에 리포지토리를 생성한 다음, 이를 Vercel에 자동으로 연결할 수 있는 파이프라인이 완성됩니다.
00:28:09클라우드 코드에서 말 한마디만 건네면 되는 전체 배포 파이프라인을 기본적으로 구축한 셈입니다.
00:28:14Cloud Code에서 간단한 일상 언어로 말만 하면 되는 배포 파이프라인을 만들 수 있습니다. 나머지는 알아서 다 해줍니다.
00:28:19여기서 가장 중요한 핵심은 Cloud 외의 다른 외부 도구를 다룰 때마다 자문해 봐야 한다는 점입니다.
00:28:24“과연 내가 Cloud로 이것을 직접 제어할 수 있을까?”라고 말이죠. 왜냐하면 Cloud가 여러분보다
00:28:28해당 애플리케이션의 작동 방식을 잘 모르더라도, 더 훌륭하게 제어할 가능성이 높기 때문입니다. 특히 그 애플리케이션에
00:28:33대해 잘 모를 때 더욱 그렇습니다. CLI든, MCP든, 커넥터든 상관없습니다. 그냥 하나만 선택하면 됩니다.
00:28:38게다가 직접 찾아 나설 필요도 전혀 없습니다. 예를 들어 Cloud Code에 다음과 같이 질문하는 것입니다.
00:28:44“야, 이 웹사이트를 배포하려고 생각 중인데. GitHub나 Vercel 같은 것들에 대해 들어봤어.
00:28:51난 그런 것들에 대해 잘 몰라. 우리가 사용할 수 있는 CLI나 MCP 같은 것도 있다는 걸 들었지. 그럼 우리 웹사이트
00:28:58호스팅에 그게 말이 되는지 한번 찾아봐 줄 수 있어? 만약 그렇다면,
00:29:03필요한 경우 해당 CLI들을 추가해 줄 수 있어? 그리고 추가된 후에 곧바로
00:29:08배포 파이프라인을 설정하고 전부 올바르게 연결해 줄 수 있어?” 이처럼 프롬프트를 작성하면 됩니다.
00:29:12“이런저런 도구들이 있다고 들었다, 아마 CLI가 있을 거다, 있으면 추가하고 실행해라”라고
00:29:16그냥 말하기만 하면 되는 겁니다? 여러분이 전문가일 필요는 전혀 없습니다!
00:29:21의문이 들 때는 그냥 Cloud Code에 모범 사례가 무엇인지, CLI가 있는지 물어보세요. 알아서 검색해 줄 겁니다.
00:29:26자, 이걸 실행해 보면—참고로 저는 이미 이것들이 설치되어 있어서 아마 이렇게 답변이 올 겁니다.
00:29:29“야, 이미 설치했어”라고 말이죠. 만약 한 번도 사용해 본 적이 없다면 여러분이 해야 할 일은 단지
00:29:33계정을 생성하는 것뿐이며, 나머지는 저희가 설치 과정을 안내해 드립니다. 그리고 이와 같은 에이전트 기반 코딩
00:29:37하네스(Cloud Code 같은)가 점점 더 보편화됨에 따라, 여러분은 거의 모든 앱에서
00:29:42어떤 버전으로든 CLI, 커넥터, MCP가 구현되어 있는 것을 보게 될 것입니다. 즉 다시 말해,
00:29:47Cloud가 판을 주도한다는 뜻입니다. 따라서 저 프롬프트를 쓰면 당연히 로그인하는 법을 안내해 줄 것입니다.
00:29:51이후 GitHub 레포지토리가 생성됩니다. 따라서 우리 웹사이트의 모든 코드는 기본적으로
00:29:55클라우드 안에 살게 됩니다. 또한 Vercel 연결도 설정해 줍니다. 이제 접속할 수 있는 라이브 URL이 생겼고,
00:30:02여기서 바로 확인할 수도 있습니다. 실제 URL이 있는 Lighthouse 사이트가 Vercel 앱에 연결되었으며,
00:30:07이걸 누구와든 공유할 수 있습니다. 자, 제가 직접 GitHub에 들어갔나요? 아닙니다.
00:30:11Vercel에 직접 들어갔나요? 아닙니다. 모든 것이 Cloud Code에서 제어되었습니다. GitHub와 Vercel이
00:30:17연동되어 있으므로, 여기 Cloud Code 안에서 웹사이트에 어떤 변경 사항을 만들든,
00:30:22그것을 라이브 웹사이트에 반영하고 싶다면 그냥 말만 하면 알아서 해줍니다. 이 배포 파이프라인은 외부 도구를
00:30:28Cloud Code 진영으로 끌어오는 단 하나의 예시일 뿐입니다. 이제 좀 더 고급 주제로 넘어갈 시간입니다. 우리는
00:30:34자동화 같은 주제들을 다룰 것입니다. 장기적인(Long-horizon) 작업에 가장 잘 접근하는 방법에
00:30:39 대해서도 이야기해 보겠습니다. slash goal, 루프 엔지니어링(Loop engineering), 그래프 엔지니어링 같은 개념들을 논하며 다루게 될 겁니다.
00:30:44또한 모델 라우팅에 대해서도 조금 이야기해 볼 텐데요, 어떻게 codecs나 GPT 모델 같은
00:30:48다른 모델들을 우리의 워크플로에 끌어올 수 있는지 다룰 것입니다. 그런 다음,
00:30:52Cloud Code 위에 얹을 수 있는 좀 더 맞춤형 하네스나 UI 유형들에 대해 이야기하며 마무리하겠습니다. 이런 형태의 도구가 될 수도 있고,
00:30:57옵시디언(Obsidian) 커맨드 센터 같은 방식을 채택할 수도 있습니다. 자, 장기적인 작업과
00:31:02루프 엔지니어링 이야기부터 시작해 봅시다. 이건 일종의 자동화 영역으로 이어집니다. 우리가
00:31:07장기적인 작업을 이야기할 때, 그것은 바로 루프 엔지니어링과 그래프 엔지니어링을 뜻합니다.
00:31:11이게 정말 무슨 뜻일까요? 우리가 말하려는 바는, 우리에게 어떤 종류의 작업이나
00:31:16완수해야 할 목표가 있지만, 이것은 어쩌면 Cloud Code가 무한한 횟수만큼 반복해서 수행해야 할지도 모르는 일이라는 점입니다.
00:31:21매일같이 실행되는 작업일 수도 있습니다. 그리고 이상적으로는,
00:31:25매일 실행될 뿐만 아니라 스스로 발전하는(Self-improving) 성격을 가진 작업이기를 바랍니다.
00:31:29따라서 이러한 장기 작업에는 실질적으로 세 가지 부분이 존재합니다. 바로 트리거, 작업,
00:31:37그리고 일종의 성공 기준(Success criteria)입니다. 자, 모든 장기 작업이 전부 루프인 것은 아닙니다. 이것은
00:31:43단순히 Cloud Code가 완료하는 데 2시간, 4시간, 12시간, 혹은 며칠이 걸릴 거라고 생각되는 어떤 작업일 수도 있습니다.
00:31:48그리고 여러분은 녀석이 컨텍스트 창이 꽉 찼다고 해서 매번 그냥 멈춰버리기를 원치 않습니다. 작업을 완수할 때까지
00:31:53계속해서 계속해서 계속 달리기를 원하죠. 바깥에 그런 기능을 하는
00:31:57Cloud Code 내부 명령어 빌트인이 존재합니다. 바로 slash goal입니다. 자,
00:32:03slash goal은 Cloud Code가 완료해 주기를 바라는 복잡한 프로젝트가 있으면서, 전 과정에 걸쳐
00:32:07지켜보며 시중을 들고 싶지 않을 때 완벽합니다. 하지만 꼭 필요한 한 가지 특별한 것이 있는데,
00:32:12그것은 바로 '성공'을 정의하는 능력과 관련이 있습니다. 성공을 정의할 수 있어야 합니다. 왜냐하면 slash goal이 전달하는 유일한 것이
00:32:20그것만이 아니기 때문입니다. 여러분은 프롬프트도 함께 전달해야 합니다. 그리고 그 프롬프트는 성공 기준이 무엇인지 명시해야 합니다.
00:32:28알겠죠? Cloud Code가 수행해야 할 목표가 있습니다. 녀석에게 무엇을 시키고 싶으신가요? 단순히
00:32:32“야, X랑 Y랑 Z를 해줬으면 좋겠어”라고 설명하는 것만으로는 충분하지 않습니다. 아니, 최종 상태(End state)가 과연 무엇인가요?
00:32:38왜냐하면 우리가 슬래시 골(forward slash goal)을 실행할 때 벌어질 일은, 코딩이든 무엇이든 간에 그 목표를 완수하기 위해
00:32:44시도할 것이기 때문입니다. 첫 번째 반복(Iteration)을 실행할 것입니다. 그리고 그 반복의 결과를
00:32:49여러분이 정의한 성공 기준과 비교할 것입니다. 성공 기준을 충족했다면, 멋지죠, 다 끝난 겁니다. 그렇지 않다면,
00:32:55두 번째 세션을 띄우고 다시 실행할 것입니다. 그런 다음 성공 기준을 확인할 것입니다.
00:33:00효과가 있었나요? 아니요. 그러면 다시 실행할 것입니다. 자, 실행할 때마다 녀석은
00:33:05“무엇이 효과가 있었고 무엇이 효과가 없었지?” 확인하기 위해 이전 반복 결과들을 살펴볼 것입니다, 하지만
00:33:10목표에 도달할 때까지 이 내부 루프를 계속해서 이어나갈 것입니다. 이것은 엄청나게 강력합니다. 대략
00:33:16랄프 루프(Ralph loops)와 비슷하다고 볼 수 있습니다, 뭔지 아신다면 말이죠. 따라서 우리의 성공 기준이
00:33:22최대한 객관적인 것이 중요합니다. 만약 제가 단순히 “야, 목표는 멋진 웹사이트를
00:33:28멋져 보이게, 깔끔해 보이게 만드는 거야”라고만 말한다면? 멋진 게 도대체 뭔지 녀석이 어떻게 알겠습니까? 깔끔한 게 뭔지 어떻게 알겠어요?
00:33:34매 실행이 끝날 때마다 녀석이 직접 살펴보고 “내가 이걸 완료했나 아니면 못 했나”를 어떻게 판단할 수 있겠습니까?
00:33:39따라서 기준이 주관적일수록 결과는 점점 안 좋아질 것입니다. 꼭 상황이 나빠진다기보다는,
00:33:44여러분의 요구를 충족할 가능성이 그만큼 낮아진다는 뜻입니다. 하지만 이 모든 것을 고려해 보더라도,
00:33:49goal은 분명 루프 엔지니어링의 한 형태이지만, 꽤나 명확한 끝이 존재하는 방식입니다.
00:33:57우리가 forward slash goal을 실행하고 이게 영원히 실행될 거라고 기대하지는 않으니까요. 하지만 우리가 원하는 일들 중에는
00:34:03정말로 영원히 실행되기를 바라는 것들도 존재합니다. 그리고 여전히 goal과 똑같은 방식으로
00:34:07동작하기를 원하죠. 온디맨드로 혹은 스케줄에 맞춰 트리거되기를 원합니다. 완료해야 할 작업이 있고,
00:34:12성공 기준이 있으며, 또한 스스로 발전하기를 원합니다. 왜냐하면 이것 역시
00:34:17항상 자신의 출력물을 살펴보고 일종의 성공 기준과 비교하기 때문에 어떤 면에서는 스스로 발전하는 구조이기 때문입니다.
00:34:23그렇다면 영원히 루프를 도는 무언가를 만들고 싶다면 어떻게 해야 할까요? 가령 매일 실행되면서
00:34:28스스로를 지속적으로 개선하기를 바라는 자동화 기능 말입니다. 자, 우리는 이 세 가지 단계를 계속 유지하겠지만,
00:34:33다음에는 일종의 로깅(Logging) 단계를 추가해야 할 것입니다. 자, 이제 예시를 통해 커스텀 루프를 한번 살펴봅시다.
00:34:37여기에 Cloud Code가 있습니다. 우리가 Cloud Code가 매일 하기를 원하는 것은
00:34:45일종의 아침 보고서, 아침 브리프 같은 것을 생성해 주는 것입니다.
00:34:50웹상에 나가서 AI 뉴스를 찾아오게 하고 싶습니다. 제 Gmail도 확인하게 하고 싶고, 마지막에는
00:34:54어떤 문서 형태로 결과물을 주기를 원합니다. 그래서 Cloud Code는 YouTube를 살펴볼 것입니다. Twitter, Reddit, 제 Gmail을 살펴볼 것입니다. 녀석은
00:35:00그 모든 정보를 긁어모으고 스크래핑한 뒤, 통합하고 종합해서
00:35:05모든 정보를 수집하고, 스크래핑하고, 통합하고, 종합해서,
00:35:09보고서 형태로 만들어 줍니다. 이걸 매일 하고 싶단 말이죠. 그렇다면 여기에 루프
00:35:16엔지니어링의 기본 개념을 어떻게 적용할 수 있을까요? 자, 기억하세요. 이 네 가지만 설정하면 됩니다. 그렇다면
00:35:23트거는 무엇이 될까요? 음, 매일 아침 7시에 실행되는 것이 트리거라고 해봅시다.
00:35:29작업은 무엇인가요? 음, 작업은 방금 제가 설명한 그대로입니다. 웹사이트를 스크래핑하고, 통합하고,
00:35:34보고서를 만드는 것이죠. 자, 이건 설정되었습니다. 그렇다면 성공 기준은 무엇일까요? 음, 바로 여기서
00:35:39어려워집니다, 맞죠? 이건 약간 주관적인 부분이니까요. 좋은 보고서란
00:35:45과연 무엇일까요? 여기에 약간의 주관적인 조건을 추가할 수도 있습니다. 예를 들어,
00:35:49모든 보고서에는 유튜브 영상 5개, 트위터 게시물 5개, 레딧 게시물 5개가
00:35:54게시물 5개가 포함되어야 한다. 그리고 지메일에서 X, Y, Z를 언급해야 한다. 이런 식이죠. 여기서 할 수 있는 것들이 몇 가지 있지만,
00:35:59하지만 파이썬 애플리케이션으로 루프를 돌면서 특정 속도에 도달하는 것을
00:36:03목표로 삼는 것만큼 간단하지는 않습니다. 마지막으로 로깅이 있습니다. 모든
00:36:09보고서를 어떤 데이터베이스에 저장할 수 있겠죠? 그렇게 하면
00:36:14Claude Code가 항상 과거의 작업을 살펴보고 앞으로 할 작업을 우리가
00:36:19이미 완료한 내용과 비교할 수 있습니다. 이론적 관점에서 볼 때 이것이 바로 루프 엔지니어링입니다. 자,
00:36:24Claude Code 내부에서 실질적으로는 어떤 모습일까요?
00:36:28음, 첫 번째 단계는 어떤 종류의 스킬을 만드는 것입니다. 방금 제가 설명한 게 무엇이었죠?
00:36:34네, 바로 스킬을 설명한 겁니다. Claude Code가 명령이나
00:36:39트리거에 따라 실행하는 스킬을 만들어 정보를 수집하고 보고서로 변환하는 이 모든 작업을 수행하게 할 수 있습니다.
00:36:44그리고 해당 스킬에 그 모든 정보를 특정 데이터베이스로 전송하는 기능을 포함할 수 있습니다.
00:36:48따라서 진정한 의미의 루프 엔지니어링을 위한 첫 단계는 스킬 생성기 스킬을 호출하는 것입니다. 기억하시죠?
00:36:54앞서 제가 그 방법을 보여드렸습니다. 그런 다음 방금 했던 것처럼 스킬을 설명하기만 하면 됩니다.
00:36:59거기서부터 원하는 결과가 나올 때까지 해당 스킬을 수동으로 계속해서 실행하게 됩니다.
00:37:03그 스킬이 마음에 들면, 다음과 같은 내용을 추가해야 합니다.
00:37:09이 작업이 데이터베이스에 기록되기를 원한다. 그리고 이 스킬을 실행할 때마다 이전 실행 결과를 살펴보고
00:37:15더 나아질 수 있는지 확인해 주었으면 좋겠다. 바로 여기서 자체 개선
00:37:20측면이 들어오게 됩니다. 이상적으로는 이전 보고서 각각에 대해 점수를 매길 수 있어야 합니다. 그래야 출력을 기반으로 삼을 수 있는
00:37:26어떤 객관적인 지표가 생기니까요. 하지만 간단히 말해서 먼저 이것을
00:37:31스킬로 전환하게 됩니다. 일단 스킬로 만들고 나면, 이제 해야 할 일은 항상 실행되는
00:37:36자동화로 전환하는 것뿐입니다. 그리고 이것은 클로드 코드 안에서는 아주 간단합니다.
00:37:41그냥 루틴으로 만들면 되거든요. 따라서 왼쪽에 와서 루틴을 누르고 새 루틴으로 가서
00:37:46로컬을 선택하면, 제가 무엇을 하게 될까요? 매일 특정 시간에 그 스킬을 실행하도록
00:37:53지시하는 것입니다. 이건 루프 스킬 같은 형태가 되겠죠. 루프 스킬을 실행하는 겁니다.
00:38:02그리고 명령어는 말 그대로 슬래시 루프 스킬 실행이 될 것입니다. 좋습니다. 이 작업을 수행하고
00:38:11스킬 생성기를 사용하여 클로드 코드 내에서 이를 만들 때, 다음과 같이 말할 수도 있습니다.
00:38:14이것을 자체 개선형으로 만들려고 한다, 데이터베이스 루프 엔지니어링의 기본 원칙들을 적용하고 싶다 등등으로요.
00:38:18클로드 코드 내 스킬 생성기의 대단한 점은 모든 힘든 작업을 알아서 처리해 준다는 것입니다. 여기서의 목표가 무엇인지
00:38:22어느 정도 이해하거든요. 그리고 나서 일정을 예약하기만 하면 됩니다, 맞죠?
00:38:27이상적으로는 아마 매일 실행되는 형태가 되겠지만, 시간별로, 평일마다, 또는 맞춤형으로 원하는 대로 설정할 수 있습니다.
00:38:31이것이 바로 루프 엔지니어링의 실용적인 적용 방식입니다. 그리고 그게 알아야 할 전부입니다. 루프 엔지니어링을 넘어서면,
00:38:37우리는 그래프 엔지니어링에 대해 이야기하기 시작하니까요. 그래프 엔지니어링은 조금 더 복잡해질 수 있습니다.
00:38:48하지만 실제로 무슨 일이 일어나고 있는가 하면, 이전에 이것을 살펴봤을 때 진행되던 모든 루프
00:38:53엔지니어링 작업들을 기억해 보세요. 실제로 이걸 전부 취소해 보죠. 이 모든 루프
00:38:59엔지니어링 작업들이 진행되고 있었죠, 맞죠? 예를 들어, 한 에이전트가 모든 걸 스크래핑하고 살펴보고, PDF를 만들고,
00:39:04평가받는 것처럼 말입니다. 글쎄요, 만약 트리거, 작업, 성공 기준의 그 모든 루프를 수행하고,
00:39:12그걸 평가한 뒤에(정보를 로깅하는 등의 작업 말입니다), 그 전체 과정을 여정의 매 단계마다
00:39:16여정의 모든 단계마다 수행하는 거죠? 유튜브 스크래핑을 전담하는 에이전트가 있어서 트리거가 발동되고,
00:39:20유튜브를 가져와 데이터를 스크래핑한 다음, 자체적인 과거 반복 학습 결과를 바탕으로 스크래핑 품질을 스스로 평가하고 개선합니다.
00:39:25판단하는 거죠. 그리고 트위터 폴링, 레딧 폴링,
00:39:30그리고 지메일 폴링, 이 폴링에서도 똑같이 하는 겁니다. 따라서 전체 작업에 대해 거대한 루프 하나만 사용하는 대신,
00:39:36한 번의 실행 내부에 여러 개의 마이크로 루프들이 중첩되어 있도록 만드는 것입니다.
00:39:41그게 바로 그래프 엔지니어링입니다. 그래서 저는 거기에 관해 전체 영상을 하나 만들었어요. 조금 복잡할 수 있죠. 하지만
00:39:46핵심적으로 볼 때 그래프 엔지니어링의 본질은 그게 전부입니다. 서로 소통하기도 하는 루프 에이전트들의 모음일 뿐이죠.
00:39:52그게 전부입니다. 그리고 대부분의 사람들에게 이것은 완전한 과잉 기술입니다. 보통은 이게 필요 없어요.
00:39:57하지만 개념적으로는 그렇게 작동합니다. 이제 논의를 동적 워크플로와
00:40:02울트라 코드로 전환해 보겠습니다. 자, 울트라 코드란 정확히 무엇일까요? 최대 노력 모드와는 어떻게 다를까요? 음,
00:40:08울트라 코드가 하는 일은 본질적으로 여러분이 해결하고자 하는 어떤 문제든 그에 맞는 맞춤형 하네스를
00:40:14생성해 주는 것입니다. 실무적인 관점에서 이것이 의미하는 바는 여러분이 가진 어떤 문제든 처리하기 위해
00:40:19하위 에이전트들을 무더기로 실행할 가능성이 높다는 것입니다. 이것은 극도로 효과적일 수 있지만,
00:40:25동시에 극도로 비용이 많이 들 수도 있습니다. 동적 워크플로의 한 예로는 슬래시 심층 연구(deep research)가 있습니다. 이것은 기본적으로
00:40:34미리 구축된 동적 워크플로와 같습니다. 그리고 웹 앱에서 심층 연구를 실행할 때 작동하는 방식과 매우 유사합니다.
00:40:39따라서 제가 심층 연구를 실행하면, 수많은 하위 에이전트들이 생성되고
00:40:44수많은 하위 에이전트를 생성하고, 이 하위 에이전트들이 다양한 작업을 수행하게 됩니다. 그래서 제가
00:40:49클로드 코드 내부에서 동적 워크플로를 사용할 때의 모범 사례에 대해 심층 연구를 수행해 줘.
00:40:59이제 구글 검색을 수행하기 위해 하위 에이전트를 대략 5개 정도 생성하는 표준 웹 검색을 하는 대신,
00:41:03그보다 훨씬 더 많은 에이전트를 생성할 것입니다. 저는 100개가 넘는 하위 에이전트가
00:41:08생성되는 것도 보았습니다. 이들은 여러 가지 작업을 수행하게 되며, 실제로 웹에 나가서
00:41:12데이터를 스크래핑하고, 우리가 찾은 데이터를 검토한 뒤 비교 대조하여 실제로 엄밀한 검증을 견뎌내는지
00:41:18확인하는 적대적 에이전트들을 생성하고, 그런 다음 종합 과정을 거쳐
00:41:22최종 보고서를 제공합니다. 따라서 여기를 보시면, 이번 범위를 위해 질문을 5개의 검색 각도로
00:41:28분해하기로 결정했음을 알 수 있습니다. 병렬 웹 검색 에이전트는 5개만 필요하다고 하네요.
00:41:33우리가 페이블(fable)을 사용하고 있으니 다행이죠. 그리고 상위 15개의 소스를 가져와서,
00:41:38각 주장에 대해 3표의 적대적 검증을 거쳐 모든 것을 검증한 후, 최종적으로
00:41:45종합하게 됩니다. 오른쪽에 작동 중인 모습이 보이실 겁니다. 6개의 에이전트를 생성했고 모든
00:41:50에이전트가 시작부터 꽤 많은 토큰 비용을 소모하기 때문에, 벌써 314,000개의 토큰을 태웠습니다.
00:41:57그러니 제가 농담한 게 아니죠. 자, 울트라 코드를 실행할 때 구체적으로 지정하지 않는다면,
00:42:02예를 들어 제가 페이블 5에서 울트라 코드를 실행 중이라면, 이 하위 에이전트들에 대해 페이블을 사용하게 되는데, 이는
00:42:07문제가 될 수 있습니다. 100개의 웹 검색 에이전트를 생성하겠다고 선언하면 어떻게 되겠습니까? 이제 제가
00:42:13거기에 대응하는 프롬프트를 줄 때, 하위 에이전트 수를 20개로 제한하라거나,
00:42:1750개로 제한하라고 구체적으로 말할 수 있습니다. 혹은 하위 에이전트용으로 소넷(Sonnet)
00:42:22이나 오푸스(Opus)를 사용하라고 지정할 수도 있죠. 따라서 현재 사용 중인 모델에
00:42:26무조건 얽매일 필요는 없습니다. 앤트로픽에서 동적 워크플로를 설명하는 아주 좋은 블로그 글을 올렸는데요,
00:42:31그 내부에서 벌어지는 일은 단일 세션에서 10개에서 수백 개의 병렬 하위 에이전트를 실행하는
00:42:36오케스트레이션 스크립트를 작성하여, 어떤 결과든 사용자에게 도달하기 전에 작업을 검증한다는 것입니다.
00:42:40여기 다양한 종류의 동적 워크플로 예시가 있습니다. 기억하세요, 울트라 코드에서 동적
00:42:45워크플로를 실행하면 클로드 코드가 여러분의 문제에 가장 잘 맞는 것을 찾아냅니다. 이 중 하나일 수도 있고,
00:42:50완전히 다른 것일 수도 있습니다. 분류 및 실행(classify and act)의 경우, 어떤 작업을 주면
00:42:54그에 맞는 최적의 하위 에이전트를 선택해 주는 분류기 에이전트가 존재합니다. 팬 아웃 및 종합,
00:42:59그리고 적대적 검토가 있죠. 이 둘을 조합하는 것이 바로 우리가 심층 연구에서 하고 있는 일입니다,
00:43:02맞죠? 어떤 작업(예: 이 정보 찾기)이 주어지면 웹상으로 확장(fan out)하여 모든
00:43:07정보를 얻고, 우리를 위해 종합하기 전에 실제로 말이 되는지 확인하기 위한 적대적 검토도 수행합니다.
00:43:12그다음에는 생성 및 필터링 같은 기능도 있죠. 토너먼트 형식으로
00:43:16어떤 문제를 해결하기 위해 다양한 시도를 해보고 판사(평가자)를 포함시키는 방식입니다. 그리고 다시
00:43:21완료될 때까지 반복(loop until done)하는 기능이 있는데, 이는 루프 엔지니어링과 매우 유사합니다. 다시 안쪽으로 돌아와 보면,
00:43:25앞서 시작했던 이 심층 연구 실행에 103개의 에이전트가 포함되었고 6백만 개의 토큰을 소모했음을 알 수 있습니다.
00:43:32그리고 이 모든 것이 페이블 위에서 이루어졌죠. 비용이 얼마나 많이 드는지 상상이 가실 겁니다. 실제 보고서의
00:43:38모습을 보시죠. 보시다시피 매우 심층적이며 21개의 서로 다른 소스도 포함되어 있습니다. 모든
00:43:43예시 중에서 심층 연구가 여러분이 가장 많이 사용하게 될 기능이라고 생각합니다. 만약 여러분이
00:43:47꽤 복잡한 프로젝트에 착수하려고 하며 계획 모드에 들어가기도 전에 철저하게 준비를 마치고 싶다면,
00:43:52심층 연구를 사용하는 것을 강력히 추천합니다. 그래야 클로드 코드가 개발을 시작하기 전에
00:43:57나가서 상황을 파악할 수 있으니까요. 이제 모델 라우팅에 대해 조금 이야기해 봅시다. 실질적으로
00:44:01외부 모델을 Claude Code 체계 안으로 어떻게 끌어들일 수 있을까 하는 점입니다. 주요 대기업 중 일부인
00:44:07ChatGPT 같은 모델들은 훌륭하고요. Sol 5.6도 멋지며, 루나와 테라는 토큰 효율성이 매우 뛰어납니다.
00:44:13그리고 여러분이 명심해야 할 한 가지는 일반적인 AI 시스템, 이러한 모델들이 전반적으로
00:44:20자신의 작업을 평가하는 일을 그리 잘 해내지 못한다는 사실입니다. 따라서 제가 Claude Code에게 자체 작업을 평가해 달라고 요청하거나,
00:44:25Opus에게 자체 작업을 평가하도록 요청하면, 스스로 평가할 수 있게 할 때 이 모델은 거의 항상
00:44:30내가 일을 아주 잘 해냈다고 말할 것입니다. 그렇다면 이 문제를 어떻게 해결해야 할까요? 특히 우리가 직접 평가할 수 없는
00:44:34훌륭한 결과물을 다룰 때 말이죠. 마치 우리의 전문 분야를 벗어난 것처럼요. 저 코드가 정말 훌륭한지 사실 잘 알지 못합니다.
00:44:38그렇다면 또 다른 최첨단 에이전트를 데려와 우리의 작업을 검토하게 하는 건 어떨까요? 우리가 이를 수행할 방법은
00:44:43다양한 스킬과 플러그인을 통해서입니다. 실제로 Claude Code를 위한 공식 Codex 플러그인이 존재합니다.
00:44:47이것은 OpenAI 본사에서 만든 것입니다. 이를 통해 Claude Code 안에서 Codex를 호출할 수 있습니다.
00:44:53이 URL을 복사하여 Claude Code에 붙여넣고 설치하고 싶다고 말하기만 하면 됩니다. 그렇게 하실 수 있죠.
00:44:58여기서부터는 Codex로 하여금 여러분이 이미 작성한 코드를 적대적으로 검토하도록 할 수 있습니다. 혹은 이를 사용하여
00:45:04Codex가 제품의 특정 기능을 구현하도록 작업하게 만들 수도 있습니다. 특히 기획 단계와 관련해서는,
00:45:09저는 맷 포콕(Matt Pocock)의 Grill Me 스킬과 Codex의 적대적 검토를 결합한 Grill Me Codex라는 스킬을 만들었습니다.
00:45:13어떤 일이 벌어지냐면, 여러분과 Fable이 서로 대화를 나누며 계획을 세운 다음, 그 계획이 Codex로 전달됩니다.
00:45:20그러면 Codex와 Fable이 일종의 의견 교환을 거치게 되는데, Codex가 Fable이 생성한 결과물을 살펴보고
00:45:25최대 5라운드까지 이 과정을 진행합니다. Codex는 이것이 틀렸고 그 이유는 이렇다고 말합니다.
00:45:29Claude는 이에 반응하여 알겠다고 수정하겠다거나 동의하지 않는다고 말합니다. 그리고
00:45:35합의에 이를 때까지 계속해서 의견을 주고받습니다. 따라서 이는 모델들이 자신의 작업을 평가하는 데 겪는 어려움을
00:45:39어느 정도 해결해 주고 두 번째 검토자의 눈을 확보하게 해 줍니다. 덕분에 우리는 복잡한 사례에서도
00:45:46자신감을 가지고 앞으로 나아갈 수 있습니다. 이러한 모델 활용 방식은 만약 여러분이 Codex 같은 것을 사용하고 싶지 않고
00:45:51대신 훨씬 더 저렴한 모델이나 심지어 로컬 모델에 의존하고자 한다면 한 단계 더 발전시킬 수도 있습니다.
00:45:55핵심은 여러분이 Opus, Haiku, Sonnet, Fable만 쓰도록 갇혀 있지 않다는 점입니다. 무엇이든 우리가 원하는 것을 데려올 수 있습니다.
00:46:02특히 이를 스킬로 활용한다면 말이죠. 역시나 여러분은 스킬 생성자 스킬을 사용해 그 작업을 수행하면 됩니다.
00:46:07마지막으로 중요하게는, 보시는 바와 같이 커스텀 에이전틱 OS 구조들이 있습니다.
00:46:11이것들은 모두 Claude 위에 커스텀 래퍼를 구축하고 다른 곳에서는 얻을 수 없는 시각적 인터페이스를 제공하는 것에 관한 것입니다.
00:46:17결국 커스텀 형태인 셈이죠. 자, 이러한 것들의 진정한 가치는 시각적인 래퍼 그 자체에 있는 것이 아닙니다.
00:46:24비록 이것이 제게 유용하기는 하지만요. 이것은 저에게 소셜 미디어 지표를 보여줍니다.
00:46:27쉽게 클릭하여 그에 대한 더 깊은 분석 내용을 얻을 수 있습니다. GitHub나 Hacker News 등에서
00:46:33무슨 일이 일어나고 있는지 보여주며 매일 한곳에서 연구를 끝마칠 수 있게 해 줍니다.
00:46:37이 모든 버튼들은 제가 필요할 때 실행할 수 있는 특정 스킬 및 자동화와 연관되어 있습니다.
00:46:41그리고 이쪽에는 거의 똑같은 시스템이 있지만, 음성 모드도 함께 지원됩니다.
00:46:45하지만 말씀드렸듯이 진정한 가치는 이러한 멋진 시각적 레이어에 있는 것이 아닙니다.
00:46:51진짜 가치는 그 이면에 있는 스킬 아키텍처에 있습니다. 이 모든 것의 핵심 아이디어는 Claude를 본질적으로
00:46:58여러분의 개인 비서나 혹은 여러분이 하는 모든 일을 수행할 수 있는 조직 내의 실제 근로자로 탈바꿈시키는 것입니다.
00:47:03따라서 저에게 있어 여러분이 지금 보고 계신 것은 기본적으로 제가 일상에서 사용하는 모든 스킬들이
00:47:09저에게 중요한 다양한 영역에 걸쳐 매핑된 형태입니다. 즉,
00:47:13메모리와 관련된 것들, Gmail이나 캘린더 같은 생산성과 관련된 것들을 갖추고 있습니다.
00:47:18연구, 콘텐츠, 커뮤니티, AI 에이전시, 영업 등과 관련된 것들도 있죠.
00:47:22이 모든 것 하나하나는 제가 예전에 직접 수동으로 하던 작업들입니다.
00:47:27이제는 그것들을 혼자 수동으로 처리하는 대신 특정 스킬에 매핑해 두었습니다.
00:47:31그리고 말이 된다면 그 스킬들을 자동화로 전환합니다. 큰 그림에서 이것을 바라보면
00:47:36그것이 바로 에이전틱 OS의 실체입니다. 일상적인 업무에 매핑해 둔 일련의 스킬과 자동화인 셈이죠.
00:47:41매핑한 것입니다. 자, 이런 걸 어떻게 만들까요? 글쎄요, 우리 이미 어느 정도
00:47:44그저 스킬을 구축하는 것입니다. 스킬 생성자 스킬을 사용하고 마이크를 켠 다음
00:47:49매일, 매주 자신이 하는 일에 대한 의식의 흐름을 들려주고 나서
00:47:53Claude Code에게 타당하다면 그것들을 스킬로 전환할 수 있는지 물어보는 것입니다.
00:47:58만약 가능하다면 그렇게 하면 됩니다. 이 과정을 반복하고 또 반복하면 결국 삶의 방대한 영역을
00:48:02자동화할 수 있게 해 주는 스킬 집합체를 만들게 됩니다. 그리고 그 모든 것의 이면에는 Obsidian이 있습니다.
00:48:08Obsidian을 통해 우리는 마크다운 파일 시스템의 형태로 우리가 하는 모든 일을 쉽게 추적할 수 있습니다. 자, Obsidian
00:48:15자체만으로는 Claude Code가 할 수 있는 일에 엄청난 업그레이드를 제공해 주지는 않지만, 우리가 실제로
00:48:20모든 것을 추적하고 약간의 메모리를 부여할 수 있도록 해 줍니다. 이것이 바로 여러분이 일찍이 들어보셨을
00:48:24카파시(Karpathy) Obsidian RAG 시스템의 기초 같은 것입니다. 자, 제가 Obsidian 메모리 시스템에 대해
00:48:28말씀드릴 때 뜻하는 바를 아주 간략하게 복습하자면, 이는 단지 파일 구조일 뿐입니다. 이것은 단지
00:48:33Claude Code가 거주하는 일관된 파일 구조입니다. 따라서 무엇이 어디로 가는지 이해할 수 있죠. 이것 역시
00:48:38흔히 카파시 Obsidian 방식이라고 불립니다. 아주 간단합니다. 에이전틱 OS가 거주하는 폴더가 있고
00:48:42제 경우에는 볼트(vault)라고 부릅니다. 볼트 안에는 다음과 같은 파일 구조가 존재합니다.
00:48:48정확히 똑같을 필요는 없지만, 핵심은 그 폴더들 중 하나에
00:48:52원시(raw) 섹션이 있다는 것입니다. 이곳은 원시 데이터가 가는 곳이자 연구 결과가 저장되는 곳입니다.
00:48:56그런 다음 위키 섹션과 출력 섹션이 있습니다. 위키 섹션은 이 모든 원시 데이터를 가져와서
00:49:01본질적으로 다양한 보고서나 위키 스타일의 기사로 변환하는 곳입니다. 가령
00:49:06Claude Code에게 AI 에이전트에 대한 수많은 조사를 수행하라고 시켰다고 해봅시다. 원시 정보를 여기에 덤프한 다음
00:49:11AI 에이전트 하위 폴더 아래에 AI 에이전트에 관한 기사를 생성하게 됩니다. 자, 만약 제가 그 AI 에이전트 유형의 위키로부터
00:49:17무언가를 생성하고 싶다고 해보죠. 예를 들어 슬라이드 덱으로 만들고 싶다면, 그 슬라이드 덱은
00:49:23출력 섹션으로 이동하게 됩니다. 이 간단한 모델을 통해 얻을 수 있는 아이디어는
00:49:29잠재적으로 수십만 개에 달하는 엄청난 양의 파일을 다룰 수 있다는 점입니다. 그리고 인간인 저도
00:49:35쉽게 탐색할 수 있고 Claude도 쉽게 탐색할 수 있는 명확한 방식으로 설정되어 있습니다. 이 파일 구조를 쉽게 탐색할 수 있다면
00:49:41정확도가 높아지고 결과적으로 토큰 비용도 적게 들 것입니다. 이 모든 것의 핵심은
00:49:45여정의 모든 단계마다 존재하는 이러한 인덱스 파일들입니다. 파일 구조 속으로 더 깊이 들어갈 때마다
00:49:50그 내부에서 무슨 일이 일어나고 있는지 알려주는 index.markdown 파일이 기본적으로 존재합니다.
00:49:55따라서 이는 기본적으로 목차와 같습니다. 자, 이게 혼란스러우셨더라도 이에 대해 훨씬 더 깊이 다루는 콘텐츠가 많이 있습니다.
00:49:58하지만 이러한 에이전틱 OS 시스템의 아이디어는 이 시각적 래퍼가 방금 말씀드린 커스텀 스킬 아키텍처 위에 얹혀서
00:50:05그 Obsidian 메모리 레이어의 뒷받침을 받는다는 것입니다. 이 레이어는 여러분이 해온 모든 것을 탐색하도록 돕고
00:50:10Claude Code가 그것을 조금 더 수월하게 탐색할 수 있도록 보조해 줍니다.
00:50:15그리고 이러한 시스템이 작동하는 방식은, 왜냐하면 여기서 사실 Claude Code를 직접 사용하는 게 아니기 때문입니다.
00:50:19우리는 dash P를 사용하는 Atlas Claude를 사용합니다. 따라서 터미널로 명령이 전송될 때
00:50:28그냥 claude를 실행하는 대신 claude dash P를 사용합니다. 이는 Claude가
00:50:34기본적으로 백그라운드에서 보이지 않게 실행된다는 뜻입니다. 한동안 이와 관련해서 Anthropic이
00:50:38그것에 대해 다른 요금을 부과할 것이며 사용량이 아닐 것이라는 논란이 좀 있었지만, 이제는
00:50:41더 이상 그렇지 않습니다. 따라서 이러한 종류의 시스템은 실제로 다른 어떤 것만큼이나 비용 효율적입니다.
00:50:47자, 이처럼 에이전틱 혹은 Claude OS를 만드는 것이 100% 필수적인 것은 아닙니다. 하지만 정말로
00:50:53모든 것의 뼈대가 되는 이러한 스킬 아키텍처를 구축하는 데는 필수적이라고 생각합니다. 물론
00:50:59저의 정확한 설정을 그대로 가져오고 싶으시다면, 그 역시 Chase AI plus 안에 마련되어 있습니다. 그러니
00:51:03오늘 여러분을 여기서 마무리하려 합니다. 우리는 정말 많은 다양한 주제를 다루었습니다. 그리고 이것들은
00:51:07처음부터 아주 고급 수준에 이르기까지 어디에 집중해야 할지 관점에서 여러분께 가장 큰 가성비를 줄 수 있다고
00:51:12느낀 주제들입니다. 평소와 같이 여러분의 생각을 알려주세요.
00:51:17저의 Claude Code 마스터클래스를 직접 만나보고 싶으시다면 Chase AI plus를 꼭 확인해 보세요.
00:51:20여기서 다룬 내용과 대략 비슷한 많은 부분을 훨씬 더 자세하게 다루고 있습니다.
00:51:26그럼 이만, 다음에 뵙겠습니다.