00:00:00여러분, 안녕하세요. 이번 주 Vercel 커뮤니티 라이브 스트림에 오신 것을 환영합니다. 저는 에이미고요, 여기는
00:00:26제이콥입니다. 저희는 Vercel의 커뮤니티 팀 소속입니다. 다시 한번 알려드리자면, 현재
00:00:31X와 YouTube에서 스트리밍 중입니다만, 여러분의 질문과 의견을 저희가 채팅창에서
00:00:36확실히 확인할 수 있게 하려면 커뮤니티 페이지에 로그인해 주세요. 주소는 [community.vercel.com/live](https://community.vercel.com/live) 이며
00:00:43첫 번째 이벤트로 떠 있는 것을 보실 수 있습니다.
00:00:44네, 세션 마지막에는 질문을 받는 시간도 가질 예정입니다. 세션을 시청하시면서
00:00:49채팅에 참여하실 분들은 저희의 행동 강령을 준수해 주시기 바라며
00:00:55진행 도중 궁금한 점이 생기면 언제든 질문을 남겨 주세요. 저희가 꼭 질문하겠습니다.
00:00:59이제 게스트를 소개해 드리고 싶네요. Cloud Code용 새로운 Vercel 플러그인을 보여주실
00:01:05존 린드퀴스트 씨를 모셨습니다. 안녕하세요, 존.
00:01:09안녕하세요, 제이콥. 안녕하세요, 에이미. 초대해 주셔서 감사합니다. 좋습니다. 바로
00:01:16제 화면을 공유해서 지금 무슨 일이 일어나고 있는지 보여드리도록 하죠. 한동안
00:01:23스킬(skills)이 큰 화두였고, 모두가 프로젝트의 수준을 높이기 위해 어떤 스킬을 사용해야 할지,
00:01:29그리고 에이전트가 평소에 하지 못하던 일을 할 수 있게 하려면 무엇이 필요한지 이야기해 왔습니다.
00:01:37이제 스킬에서 한 단계 더 나아간, 다음 진화 형태가 바로 저희가 '플러그인'이라고 부르는 것입니다.
00:01:43이것은 여전히 확산 중인 단계입니다. 시중에 플러그인이 아주 많지는 않고, 사람들은 여전히
00:01:48이것을 정확히 어떻게 구축해야 할지 탐색하고 있죠. 제가 Vercel 플러그인의 초안을 만들었는데요,
00:01:56오늘 이야기하고 싶은 것은 왜 플러그인을 만들어야 하는지, 언제 만들어야 하는지, 그리고 왜
00:02:03스킬 대신 플러그인인지, 그리고 이 둘이 서로를 어떻게 보완하는지 같은 질문들입니다.
00:02:09플러그인이 무엇인지에 대해서도 이야기하겠지만, 플러그인이 여러분에게 어떤 것을 가능하게 하는지,
00:02:16혹은 내부용이나 개인용으로 구축해야 할지에 대해 질문이 있으시다면 오늘 세션에서
00:02:22함께 논의해 보고 싶습니다. 우선, 플러그인은 처음에
00:02:32Claude Code와 Gemini에 의해 시작되었지만, 접근 방식은 매우 달랐습니다.
00:02:39플러그인의 표준화는 현재 진행 중인 과제입니다. 곧 더 자세히 말씀드릴 수 있기를 바랍니다만,
00:02:44단일 플러그인이 모든 에디터에서 작동하게 하는 것이 목표입니다. 현재는
00:02:49Claude Code와 Cursor 지원에 대해 이야기하고 있습니다. CodeX도 오늘 혹은
00:02:54아주 곧 지원될 예정이며 다른 에디터들도 마찬가지입니다. 현재 플러그인 표준이
00:03:01개발되고 있습니다. 따라서 여러분이 어떤 도구를 사용하든 플러그인을 패키징해서
00:03:08공유할 수 있게 될 것으로 기대하셔도 좋습니다. 그건 그렇고, 여러분은 스킬에 대해
00:03:15잘 아실 텐데요. 스킬은 에이전트가 추가 지침을 얻기 위해 로드할 수 있는 마크다운 파일입니다.
00:03:23사용자가 직접 슬래시(/)를 입력해 스킬을 호출하거나, 에이전트가
00:03:29설명을 바탕으로 스킬을 로드해야 한다고 감지하는 방식이죠. 즉, 사용자 호출이나
00:03:36설명의 조건에 따른 에이전트의 결정에 크게 의존합니다. 하지만 플러그인으로 한 단계 올라서면
00:03:44이른바 '훅(hooks)'이라는 것이 있습니다. 플러그인을 생각할 때, 혹은
00:03:53Claude Code나 다른 에이전트 하네스(harness)와 나누는 세션을 생각할 때, '라이프사이클'이 있다고 보시면 됩니다.
00:03:59지금 저는 Vercel 플러그인 디렉토리에 있는데요, 여기서 Claude Code를 실행해서
00:04:07이 플러그인이 사용하는 훅이 무엇인지 물어보겠습니다. 그러면 시스템이
00:04:18라이프사이클을 정의하는 훅들을 나열해 줄 것입니다. 라이프사이클이란 세션이 시작될 때,
00:04:27도구가 호출되기 전후, 사용자가 텍스트를 입력할 때,
00:04:33그리고 세션이 종료될 때 등의 시점을 의미합니다. 그 안에는 더 많은 훅이 있습니다만,
00:04:39Vercel 플러그인의 경우 현재 저희의 초기 목표에 따라 이 기능들을 사용하고 있습니다.
00:04:44정확히 말씀드리자면, Vercel 플러그인의 초기 목표는 사람들이
00:04:51Vercel에서 에이전트를 원활하게 배포하도록 돕는 것이었습니다. 즉, 에이전트에게 Vercel 생태계를
00:05:02어떻게 인식시킬 것인가의 문제입니다. AI SDK, 게이트웨이 같은 플랫폼의 모든 것들 말이죠.
00:05:11그리고 저희 워크플로우(Workflows)도 마찬가지입니다. 워크플로우와 관련된 모든 것들, 그리고 기본적으로
00:05:19Vercel CLI도 많이 업데이트되었습니다. 에이전트 SDK, 아니 죄송합니다,
00:05:26Vercel에서 에이전트를 배포하는 것과 관련된 이 모든 것들은 지난 며칠, 몇 주,
00:05:33혹은 몇 달 사이에 출시된 것들입니다. 그런데 Claude Code 같은 에이전트 하네스들은
00:05:39지식 컷오프(knowledge cut-off) 시점이 아마 6개월에서 1년 전일 것입니다. 모델이나
00:05:46여러 변수에 따라 다르긴 하겠지만요. 하지만 공통적으로 에이전트들은
00:05:52저희가 출시한 최신의 놀라운 기능들을 모릅니다. 그래서 Vercel 플러그인의
00:05:57목표는 에이전트가 시대에 뒤떨어진 코드나 방식을 사용하지 않게 막고,
00:06:06Vercel 플랫폼의 최신 정보를 반영하도록 끌어올리는 것입니다. 이것이 엄청난 이점입니다.
00:06:11모델은 똑똑하지만 단지 이런 최신 정보를 모를 뿐이니까요.
00:06:19매번 조사를 시키거나, 모든 항목에 대해 거대한 스킬 묶음을
00:06:25가지고 있게 하는 대신, 에이전트가 Vercel 플랫폼에 대한 최선의 정보를
00:06:32강제로 로드하게 할 수 있다면 그것은 저희에게 큰 승리입니다. 에이전트 라이프사이클의
00:06:38이 훅들을 살펴보면, 다시 말씀드리지만 앞으로 활용할 수 있는 훨씬 더 많은 훅이
00:06:45있겠지만 현재 핵심적인 것들은 'session start'입니다. 이는 몇 가지 방식으로 쓰입니다.
00:06:49'pre-tool-use', 'user-prompt-submit', 'post-tool-use', 그리고 'session end'가 있습니다.
00:06:56'session start'와 'session end'는 에이전트와의 대화가 시작되고 끝나는 시점입니다.
00:07:03일반적으로 세션이 시작될 때 'agent.md'나 'claud.md' 파일을 사용하게 되는데요,
00:07:12Vercel 플랫폼을 위해 세션 시작 시점에 무엇을 할 수 있을까요?
00:07:19바로 Vercel 플랫폼 파일을 로드하는 것입니다. 즉,
00:07:27'vercel.md'를 묘사해 보라고 하면, 이 파일은 'claud.md'와 함께
00:07:40세션 시작 시점에 포함될 수 있습니다. 기본적으로 여러분이 원하는 것이 'claud.md' 파일을
00:07:48공유하고 누군가 그것을 쉽게 설치하게 하는 것이라면, 그냥 '이것은 Vercel의 지식
00:07:52그래프입니다'라고 주입하기만 하는 플러그인을 만들 수도 있습니다. 이것은 저희가
00:07:59지속적으로 다듬고 있는 부분입니다. 최대한 압축해서 크기를 줄이면서도
00:08:04좋은 성능을 내고, 무엇을 넣고 뺄지 균형을 맞추는 방법을 찾고 있죠.
00:08:08모든 모델과 하네스를 대상으로 평가(evals)를 실행하는 것은 매우 어렵습니다만,
00:08:15천천히 해결해 나가고 있습니다. 그 파일에 담긴 내용은 기본적으로 Vercel 생태계 내의
00:08:21AI 관련 관계들, 즉 어떤 제품을 언제 사용해야 하는지, 어떤 것을 언제 호출해야 하는지 등
00:08:28Vercel 생태계 전체에 대한 구조화된 이해입니다. 저는 이것을
00:08:35'목차'라고 부르는 방식이 마음에 듭니다. 대화를 시작할 때 책의 맨 앞부분을 펴는 것과 같죠.
00:08:44저희가 이 구조를 생각한 방식은 이렇습니다. 제가 에이전트와 대화할 때
00:08:50저는 저만의 어휘가 있고 에이전트도 에이전트만의 어휘가 있습니다.
00:08:56만약 에이전트에게 용어집을 주고, 그것을 문서나 스킬, 그리고 로드해야 할 정보들과
00:09:02연결해 줄 수 있다면 어떨까요? 일단 그런 연결이 설정되면, 제가 할 말과
00:09:07에이전트가 로드하고 호출해야 할 것들을 미리 파악해서 마인드맵을 구성할 수 있습니다.
00:09:12그러면 저는 AI SDK를 언급할 걱정조차 할 필요 없이 아주 자연스럽게 대화할 수 있죠.
00:09:19어떤 특정 기능을 일일이 말할 필요도 없습니다. 제가 그냥
00:09:24"이런 앱을 만들어서 배포해 줘"라고만 말하면, 나머지 모든 것은 플러그인에서
00:09:30알아서 처리해 주는 방식입니다. 플러그인이 모든 것을 처리해서 멋진 앱이
00:09:38Vercel에 배포되고, 사용자는 거기서부터 계속 작업을 이어갈 수 있게 됩니다.
00:09:45v0나 저희의 다른 프로젝트들이 작동하는 방식과 비슷하죠. 사용자가 생태계에 대해
00:09:52고민할 필요 없이 훌륭한 경험을 할 수 있게 만든다면 그것은 큰 성과입니다.
00:09:57이해가 되시나요? 제이콥, 에이미, 혹시 질문이나 채팅창에 올라온 내용이 있나요?
00:10:02제이콥, 회의 때문에 질문이 하나 있다고 하셨던 것 같은데요. 아, 정말 죄송합니다.
00:10:09존에게 궁금한 게 있었어요. 이 플러그인이 목차 역할을 한다고 하셨는데,
00:10:16그렇기 때문에 새로운 문서가 나올 때마다 플러그인을 계속 업데이트할 필요가
00:10:24없는 건가요? 에이전트가 최신 문서를 찾아갈 수 있도록 연결해 주는
00:10:30URL 모음 같은 건가요? 아니면 플러그인 자체에 즉시 업데이트 시스템이 있나요?
00:10:38어떤 방식으로 작동하는 건가요? 네, 기본적으로 처음에 제공하는 지식 그래프는
00:10:43상당 부분 최신 문서를 가리키는 역할을 합니다. 이는 스킬이나
00:10:49라이브러리별 스킬 관리와 관련해서도 자주 나오는 질문인데요.
00:10:58어떤 사람은 특정 SDK의 버전 5를 쓰고, 어떤 사람은 버전 6을 쓰는데
00:11:07서로 충돌하는 다른 버전의 스킬로 영향을 주려 한다면 어떻게 해야 할까요?
00:11:14많은 경우 사용자가 무엇을 설치했는지, package.json 파일이나 버전을 확인하면 됩니다.
00:11:18그걸 바탕으로 어떤 문서 URL을 참조해야 할지, 어떤 스킬을 로드해야 할지 등을
00:11:22똑똑하게 찾아내는 것이죠. 이것이 세션 시작 시점의 '프리로드(preload)' 단계에서
00:11:31사용자의 프로젝트를 검사하는 또 다른 이유입니다. 다시 말씀드리지만 이건 전부 로컬에서 이루어집니다.
00:11:36어떤 라이브러리를 쓰는지, 설정은 어떤지 확인해서 올바른 방향을 제시하는 거죠.
00:11:44가장 흔한 오류 중 하나가, API가 바뀐 것을 모르고 최신 SDK 버전에서
00:11:51이전 방식의 'generate object'를 쓰려고 하는 경우입니다. 그래서 플러그인이
00:11:58그런 부분을 알아서 처리해 줍니다. 여러분이 레거시 프로젝트를 쓰든,
00:12:02완전 처음 시작하는 최신 프로젝트를 쓰든 신경 쓸 필요가 없게 말이죠.
00:12:07버전 번호나 패키지 이름 같은 건 고민하지 마세요. 그냥
00:12:12Vercel이 알아서 하도록 두시면 됩니다. 맞습니다. 저희는 더 나은 방법을 위해
00:12:21계속 아이디어를 내고 있습니다. 플러그인은 계속 업데이트되면서 이를 발전시켜 나갈 것입니다.
00:12:27다른 질문 있으신가요? 네, 플러그인의 전체적인 범위는 어느 정도인가요?
00:12:32단순히 Vercel 서비스들만 다루나요? 대시보드에서 볼 수 있는 것들만요?
00:12:34아니면 저희가 지원하는 Next.js, AI SDK, 워크플로우 같은 오픈 소스 라이브러리도 포함되나요?
00:12:41네, 초기 범위에 대해서는 가능한 한 많이 포함하기로 결정했습니다.
00:12:49모든 라이브러리와 플랫폼의 모든 것을 일단 다 넣어보고,
00:12:54내부적으로 어떤 게 가장 많이 쓰이는지 보려고 합니다. 텔레메트리(telemetry) 공유를 선택하면
00:12:58어떤 스킬이 실제로 사용되고 어떤 게 안 쓰이는지 알 수 있거든요. 그러면
00:13:04정보가 많이 필요 없는 부분은 제거하고, 많이 쓰이는 부분은 더 보강할 수 있겠죠.
00:13:11당연히 Next.js나 AI SDK처럼 인기 있는 항목들이 가장 많은 정보를 갖게 될 것입니다.
00:13:16그래서 초기 출시 때는 의도적으로 범위를 꽤 넓게 잡았고,
00:13:25앞으로는 좀 더 날씬하게, 뭐라고 할까요, 'Svelte'하게 다듬어 나갈 예정입니다.
00:13:32그렇군요. 충분히 이해가 됩니다. 감사합니다. 네, 좋습니다. 그래서
00:13:36만약 여러분이 플러그인을 만든다면... 제가 이 이야기를 일반적이고 포괄적인 용어로 하는 이유는
00:13:40제가 '에이전트 중심 개발(agentic driven development)'에 매우 관심이 많기 때문입니다.
00:13:48모든 작동 방식을 정확히 보여드리는 것보다 용어와 개념을 익히는 게 더 중요하다고 생각해요.
00:13:53그래야 AI 어시스턴트에게 비슷한 일을 시킬 수 있으니까요. 만약 여러분이
00:13:59Claude Code에게 'Claude Code용 플러그인을 만들어 줘'라고 말하고 관련 문서를 주면
00:14:08에이전트가 해낼 수 있습니다. 그래서 코드를 깊이 파는 것보다 개념과 아이디어를
00:14:15논의하는 게 훨씬 중요합니다. 그런 의미에서 'session start'는 플랫폼의
00:14:16목차를 주입하기에 아주 좋은 지점입니다. 모델이 가진 지식 중에
00:14:24오래된 정보가 무엇인지 에이전트에게 알려주는 것이죠. 이를 통해
00:14:29Vercel의 현재 모습이 어떠한지 최신 상태로 끌어올릴 수 있습니다.
00:14:36플러그인에서 일어나는 일이 이것뿐이라 해도, 에이전트는 앞으로 어떤 점을
00:14:40확인해야 할지 알게 됩니다. 그리고 저희가 할 수 있는 또 다른 일은, 이건 여담입니다만
00:14:45Claude Code의 각 세션은 고유 ID를 가지고 있습니다. 덕분에 세션이 진행되는 동안
00:14:52스킬 예산이 얼마나 남았는지, 어떤 스킬이 이미 로드되었는지 등을
00:14:58확인할 수 있습니다. 그래서 세션 환경이나 세션 저장소에
00:15:05데이터를 기록할 수 있습니다. 이미 로드된 것을 중복해서 로드하지 않도록
00:15:11진행 상황을 계속 추적할 수 있는 거죠. 그게 아주 좋습니다.
00:15:19세션 ID를 확보하면 세션 내에서 실행되는 어떤 미래의 훅이나
00:15:24작업에서도 그 ID를 붙잡고 개별 플러그인에 대한 세션 정보를 저장할 수 있습니다.
00:15:31Claude Code도 '.claud' 디렉토리의 프로젝트를 보면 세션 정보 등이 들어 있습니다.
00:15:37여러분도 직접 만드는 플러그인이나 도구에 같은 개념을 적용할 수 있습니다. 자, 이제
00:15:44'pre-tool-use'에 대해 이야기해 보죠. 'post-tool-use'와 묶어서 설명해 드리겠습니다.
00:15:52이 기능들은 파일의 변경 사항을 확인할 기회를 제공합니다. 'pre-tool-use'에서는
00:16:01변경되기 직전의 파일 내용을 가져올 수 있습니다. 즉,
00:16:07파일 읽기, 쓰기, 수정, 생성과 관련된 시점이죠. 그리고 'pre-tool-use'는
00:16:15Bash에서 명령어를 실행하는 것과 같은 다른 도구 사용도 폭넓게 다룹니다.
00:16:20어떤 일이 일어나기 직전에 '내가 하고 싶은 다른 작업이 있는가?'를 묻는 겁니다.
00:16:26예를 들어, 누군가 특정 Vercel CLI 명령어를 실행하려 하는데
00:16:30지금은 더 나은 방식이 있다는 것을 저희가 안다면 어떨까요? 이제 Vercel CLI에는
00:16:35더 고급 쿼리가 가능한 API 옵션이 생겼거든요. 최근에 업데이트를 안 하셨다면
00:16:40CLI에 아주 좋은 새 기능들이 많습니다. 저희가 그런 힌트를 줄 수 있습니다.
00:16:47어떤 작업을 하려 하거나 Vercel CLI 버전이 낮을 때 업데이트를 권할 수도 있죠.
00:16:50여기서 선택지가 훨씬 많아집니다. 도구 호출, 즉 CLI 호출이 일어나려 할 때
00:16:56이를 확인할 기회를 줍니다. 이는 샌드박스 CLI나 워크플로우 CLI처럼
00:17:05완전히 새로운 CLI들에서 매우 중요합니다. 모델의 지식 컷오프 이후에
00:17:11출시되어 모델이 아직 모르는 도구들이 올바르게 작동하도록 보장해야 하니까요.
00:17:20도구 호출, 특히 Bash 호출과 파일 수정 시점에 이 점이 빛을 발합니다.
00:17:29저희가 더 탐색하고 있는 부분은 파일의 차이(diff)를 확인하는 것입니다. '파일이 원래 이랬는데
00:17:34에이전트가 이렇게 바꾸려 하네? 우리 라이브러리 기준으로 이 변경이
00:17:40맞는 건가? 아니면 뭔가 이상한 냄새가 나나?' 이런 걸 확인하는 거죠.
00:17:47아까의 예로 돌아가서, v6 SDK가 설치되어 있는데 에이전트가 API로
00:17:55'generate object'를 쓰려 한다고 칩시다. 흔한 실수죠. 그 순간을 포착해서
00:18:00"잠깐, 지금 'generate object'를 쓰려는데, AI SDK의 실제 사용법은 이래"라고 알려주는 겁니다.
00:18:05테스트나 배포 단계까지 가기도 전에, 에이전트가 파일을 바꾸려는
00:18:11바로 그 시점에 오류를 잡아내는 것이죠. 이것은 스킬과는 다른 점입니다.
00:18:17스킬은 단순히 텍스트 힌트에 불과하거든요. 만약 여러분이
00:18:21'claud.md'나 스킬 파일에 "어떤 파일은 절대 커밋하지 마"라거나
00:18:27"브랜치에 있지 않으면 절대 푸시하지 마" 같은 내용을 적어본 적이 있다면
00:18:34경험해 보셨을 겁니다. 그런 지침이 항상 여러분을 완벽히 지켜주지는 못한다는 걸요.
00:18:39'pre-tool-use'는 프로그래밍적이고 공학적인 방식으로 그런 일이 일어나는 것을
00:18:47실제로 막을 수 있는 기회를 줍니다. 그리고 다른 지침이나 다른 방식의
00:18:52예시를 에이전트에게 줄 수도 있죠. 이것이 스킬이나 'claud.md', 'agent.md'와
00:18:59플러그인의 가장 큰 차이점입니다. 실제로 무엇이 바뀌는지, 어떤 일이
00:19:06벌어지는지 통제할 수 있습니다. 그게 가능해지는 시점을 제공한다는 게 정말 좋습니다.
00:19:11거기서부터 'post-tool-use'에서도 비슷한 기능을 사용할 수 있습니다.
00:19:18Bash 명령어가 실행된 후 무엇이 정확히 바뀌었는지 확인할 수 있는 기회죠.
00:19:25도구가 호출된 후 어떤 점이 달라졌는가? 이건 어떤 일이 일어나는 걸
00:19:32미리 막지는 못하지만, 벌어진 일의 결과를 볼 수 있게 해줍니다. 그리고
00:19:36만약 예상치 못한 결과가 나왔거나 무언가 바뀌었다면, 다시 한번
00:19:46차이점을 확인하고 에이전트에게 "이거 좀 이상한데?"라고 말할 수 있는 거죠.
00:19:54이 두 가지가 플러그인을 만들 때 알아야 할 거대한 라이프사이클 훅입니다.
00:20:03저희에겐 지식 컷오프가 가장 큰 문제입니다. Vercel은 아주 빨리,
00:20:13아주 자주 새로운 기술을 출시하고 사람들에게 선보이고 싶어 하니까요.
00:20:21그런 상황에서 플러그인이 정말 큰 도움이 됩니다.
00:20:28이 부분에 대해 질문 있으신가요? 네, 만약 파일 경로를 사용해 어떤 스킬을 주입할지 결정한다면,
00:20:32프로젝트의 파일들을 좀 더 단일 목적에 맞게 쪼개는 게 이득이 될까요?
00:20:41그래야 에이전트가 어떤 스킬이 필요한지 더 정확하게 판단할 수 있을 테니까요.
00:20:47예를 들어 큰 파일 하나에 저희 라이브러리 5~6개가 쓰이고 있는데,
00:20:51스킬은 한 번에 3개까지만 추가할 수 있다거나 파일 경로만 봐서는
00:21:01정확히 모를 수도 있잖아요. 이런 점이 이제 이런 도구들로 소프트웨어를
00:21:07만들 때 고려해야 할 사항이 될까요?
00:21:13질문의 내용을 파악해보니 매우 날카로운 지적이네요.
00:21:19파일이 너무 크고 복잡하면 에이전트가 문맥을 파악하기 힘들어할 수 있습니다.
00:21:25따라서 관심사를 분리하고 파일을 작게 유지하는 것이 에이전트 친화적인 개발 방식이 될 수 있습니다.
00:21:31이것은 단순히 에이전트뿐만 아니라 일반적인 코드 품질 측면에서도 좋은 습관이죠.
00:21:38플러그인이 더 똑똑하게 작동하려면 파일의 성격이 명확한 것이 훨씬 유리합니다.
00:21:43그래야 우리가 주입하려는 최신 지식과 기술이 정확한 위치에 전달될 수 있으니까요.
00:21:49이런 설계 방식은 앞으로의 개발 환경에서 점점 더 중요해질 것입니다.
00:21:55우리는 이 모든 새로운 기술을 아주 빠르게 선보이고 있습니다. 그리고 이 놀라운 것들을
00:22:00사람들에게 보여주고 싶어 하죠. 바로 그 지점에서 플러그인이 정말 유용하게 쓰일 수 있습니다.
00:22:09이에 대해 질문 있으신가요?
00:22:11네. 만약 파일 경로를 사용해서 어떤 기술(skills)을 주입할지 결정한다면, 그것은 우리가
00:22:21프로젝트의 파일 범위를 조금 더 단일 목적으로 좁게 설정함으로써 얻는 이점이 많다는 뜻일까요?
00:22:27그렇게 하면 어떤 기술이 필요한지 더 정확하게 판단할 수 있을 테니까요. 예를 들어,
00:22:34큰 파일이 하나 있고 그것이 대여섯 개의 라이브러리를 사용하고 있다면, 이제는
00:22:39한 번에 최대 3개의 기술만 추가할 수 있거나, 파일 경로만 보고는
00:22:47무엇이 필요한지 모를 수도 있지 않나요? 그래서 이제는 이런 도구들로 소프트웨어를 구축할 때
00:22:51그 점을 고려해야 한다고 생각하시나요?
00:22:54제 생각에 에이전트가 작성하는 코드에 대해서는 신경 쓰지 않으셔도 될 것 같습니다.
00:23:02그런 것들이 잘 작동하게 만드는 것은 플러그인 제작자나 하네스(harness) 제작자의 몫입니다.
00:23:12실제로 평가(evals)를 실행하고 그런 변화가 차이를 만드는지 확인하는 사람들 말이죠.
00:23:17반면에 개발자 모드로 돌아가서 "사람이라면 이렇게 해결할 거야"라고 생각하기가
00:23:27매우 쉽습니다. 그리고 그것이 에이전트가 원하는 방식이라고 단정 짓기도 쉽죠.
00:23:33그것이 현재 개발자들이 겪는 가장 큰 유혹 중 하나인 문제 해결, 즉
00:23:39문제가 아닌 문제를 찾아내는 것입니다. 왜냐하면,
00:23:50무언가를 고치려고 하는데 어떻게 테스트해야 할지 모를 때, 만약 여러분이
00:23:53에이전트를 상대로 테스트하는 법을 안다면 해보셔도 좋습니다. 하지만 그럴 의사가 없다면
00:24:00그냥 플러그인과 하네스를 만드는 사람들이 처리하도록 맡겨두세요.
00:24:05테스트와 평가에는 비용이 많이 들기 때문입니다. 이러한 변경 사항에 대해 모든 모델을
00:24:12실행하는 데는 많은 돈이 듭니다. 시간도 오래 걸리고 아주 번거로운 일이죠.
00:24:17그래서 저는 아무도 그런 것을 신경 쓰지 않아도 되기를 바랍니다.
00:24:23지금은 다른 일에 노력을 쏟는 것이 낫다고 생각합니다.
00:24:33그렇군요, 알겠습니다. 모델의 다음 버전이 그런 변경 사항들을
00:24:40결과적으로 불필요하게 만들 방식으로 구축될 예정이라면,
00:24:47제가 구축하는 방식을 바꿀 필요가 없겠네요.
00:24:48네. 그리고 모든 하네스와 Vercel의 최종 목표는 여러분이
00:24:56코드에 대해 너무 많이 생각하거나 들여다볼 필요가 없게 만드는 것입니다. 지금 당장
00:25:01그렇다는 뜻은 아닙니다. 그것이 우리가 추진하고 있는
00:25:07최종 목표라는 말입니다. 여러분은 아름다운 소프트웨어를 출시하고 싶어 할 것이고,
00:25:11자유롭게 아이디어를 흐르게 하며 다양한 변형을 얻고, 어떤 것이 자신에게 정말 와닿는지
00:25:19확인한 다음, 자신이나 가족, 고객에게 아름다운 결과물로 깎아내고 싶어 할 것입니다.
00:25:25우리는 여러분이 파일 크기가 얼마나 큰지 고민하지 않아도 되는
00:25:33아름다운 경험을 원합니다. 여러분이 글을 쓸 때
00:25:39올바른 디자인 패턴을 쓰는지, 어떤 라이브러리를 선택하는지 고민하지 않게 말이죠. 전적으로 동의합니다.
00:25:48"에이전트가 이 패턴을 더 잘 다루니까 이 모든 패턴을 사용하자"라고 말하고 싶은 유혹이나
00:25:53"이 모든 것들을 하자"라는 유혹 말입니다. 확실히 저희가 플러그인과 테스트를 통해
00:25:58실험하고 있는 부분이기도 합니다. 하지만 다시 말씀드리지만, 테스트할 수 없다면
00:26:07"내가 이 변경을 했으니 이제 분명히 더 잘 작동할 거야"라고 말하고 싶은 유혹이 너무 큽니다.
00:26:18그것이 바로 일종의 자폭 행위(foot guns)가 될 수 있는데, 왜냐하면 그런 변경을 함으로써
00:26:23이전에는 어떻게 작동했는지, 그리고 그것이 다른 곳에 어떤 영향을 주는지 보지 않게 되기 때문입니다.
00:26:28그 한 번의 세션에서는 잘 작동했을지 몰라도... 그래서 공학이 이제 달라졌습니다. 죄송합니다,
00:26:35제가 너무 철학적으로 흘렀네요. 네, 이해한 것 같습니다.
00:26:44자, 또 다른 훅(hook)은 'user prompt submit'입니다. 이것은 매우 중요한데,
00:26:50사용자가 입력한 텍스트를 가져올 수 있게 해주기 때문입니다. 만약 사용자가 특정 라이브러리나
00:26:55개념을 언급한다면, 예를 들어 "스케줄(schedule)"이라는 단어를 언급하면
00:27:00크론(cron) 기술을 가져오는 식이죠. 이것은 '기술(skills)'이 작동하는 방식과 매우 유사합니다.
00:27:07사용자가 말하거나 대화 중에 설명과 일치하는 내용이 감지되면 작동하지만, 이것은 실제로
00:27:12사용자 프롬프트에 대해 정규표현식(regex)을 실행할 기회를 줍니다. 특정 키워드나
00:27:20패턴 등이 감지되면 해당 기술을 로드하거나 에이전트에게 힌트를 줍니다.
00:27:26"추가 질문을 해보는 게 어때?" 같은 식으로요. 이것은 상호작용적인 부분이며,
00:27:33"사용자가 이렇게 말했으니 더 명확한 설명이 필요할 것 같아"라거나
00:27:38"그냥 이 모든 것들을 로드해서 진행하자"라고 말할 수 있는 기회입니다. 또한
00:27:44'user prompt submit'으로 할 수 있는 정말 재미있는 일들이 있습니다. 만약 여러분이
00:27:48자신만의 커스텀 용어집이나 명령어를 갖고 싶어서,
00:27:56명령어 앞에 달러($) 기호를 붙이고 싶다고 합시다. 무언가 달러 기호로 시작하면 이걸 실행해라, 같은 식이죠.
00:28:00아니면 무언가가... 이건 마치 'user prompt submit' 안에
00:28:07작은 배시(bash) 스크립트를 작성하는 것과 비슷해서, 특정 조건이 감지되면 즉시 도구를 실행할 수 있습니다.
00:28:13세션의 컨텍스트 밖에서 어떤 배시 스크립트나 노드(node) 스크립트라도
00:28:20해당 훅 내부에서 실행할 수 있습니다. 그래서 그 안에서
00:28:28온갖 기발하고 빠른 작업들을 할 수 있습니다. 예를 들어 "커밋(commit)"이라는 단어를 감지해서
00:28:37에이전트가 무언가를 커밋하기 위해 몇 단계를 거치는 것을 방지하고 싶다면,
00:28:47대신 무엇이든 할 수 있는 커밋 스크립트를 실행하면 됩니다. 프롬프트가 입력된 직후에
00:28:53에이전트에게 "내가 커밋 작업을 실행했으니 걱정하지 마"라고 말할 수 있는 거죠.
00:28:59그러면 에이전트의 턴(turn)을 몇 번 아낄 수 있습니다. 그 안에서 속도를 정말 높이기 위해
00:29:03사용할 수 있는 아주 흥미롭고 작은 기교들이 많이 있습니다. 매번 에이전트에게
00:29:09부탁하기보다 반복적으로 수행하는 일들이 있다면 말이죠. 자신을 위한
00:29:15'user prompt submit'을 만들고 에이전트와 대화하는 자신만의 언어를 고안해 보는 것도
00:29:19재미있는 프로젝트가 될 것입니다. 하지만 저희에게 그것은 좀 더 이런 의미입니다.
00:29:25"사용자가 이 개념을 말했다면 Vercel 용어로는 무엇을 의미하는가?" 즉, 단어들을 매칭하는 것이죠.
00:29:30구체적으로 스케줄링은 크론(crons)과 워크플로우(workflows)에 해당합니다. 그리고
00:29:37"병렬(parallel)"이나 "성능(performance)" 같은 단어들이 나오면,
00:29:45여러분이 알고 있는 Vercel의 특정 기능으로 에이전트를 안내할 수 있습니다. 주말에
00:29:53'user prompt submit'을 가지고 놀아보는 것은 아주 즐거운 일이 될 거예요.
00:29:58다시 한번 반복하자면, 여기 와서 이렇게 말하는 것이 전적으로 가능합니다. "내가
00:30:03달러 기호를 감지하는 'user prompt submit' 기능이 있는 Claude code 플러그인을 만들게 도와줘."
00:30:09"그리고 달러 기호가 보이면 'user prompt submit' 내부에서 커밋을 실행하게 해줘."
00:30:14이런 프롬프트만으로도 구축할 수 있었을 테니, 코드에 대해 너무 걱정하지 말고
00:30:19그냥 바로 시작해 보세요. 자, 이제 이 모든 것을 마무리했다면,
00:30:26'session end'는 세션 동안 작성한 파일이나 다른 것들을 정리할 수 있는 기회입니다.
00:30:32어떤 기술들이 실행되었는지 수집하기 시작했거나, 호출된 도구들의
00:30:39결과에 대한 정보를 수집했거나, 세션 내내 추적하던
00:30:48예산이나 다른 것들이 있다면 그것들을 정리할 기회입니다. 'session end'에서 할 수 있는
00:30:51매우 흥미로운 일들이 있습니다. 왜냐하면 이것은 본질적으로
00:30:57Ctrl+C와 같은 세션 종료 시점에 실행되기 때문입니다. 다른 에이전트들을 띄워서
00:31:05"자, 이번 세션에서 변경된 모든 파일을 봐봐. 우리가 원하던 것과 일치해?"라고 말할 수도 있겠죠.
00:31:09저희가 그렇게 하지는 않지만, 'session end'로 할 수 있는 정말 흥미로운 일들이 많습니다.
00:31:13"내 세션이 끝났어. 이 세션이 프로젝트의 진행을 나타내는가? 아니면 찌꺼기를 남겼는가?"
00:31:20"변경된 모든 파일을 훑어봐. 프로젝트에 이미 있는 것들이 중복되지는 않았어?"
00:31:26만약 그렇다면 정리 작업을 하고 사용자에게 알림을 줄 수도 있습니다. 세션이
00:31:30이미 종료되었으므로 시스템 알림이나 다른 수단을 통해 사용자에게 알려야 하겠지만요.
00:31:37정말 흥미로운 것들이 많습니다. 자, 각설하고,
00:31:43이제 여기서 간단한 데모를 하나 보여드리겠습니다. 저는 지금
00:31:50Vercel 플러그인을 실행 중인 Claude code 버전과 실행하지 않는 버전을 실행해 볼 것입니다.
00:31:56'Claude dangerously skip permissions'를 사용하고, 디버그 모드는 켜두겠습니다. 잠시 후에 보여드리죠.
00:32:04그리고 이 모델은 Haiku로 설정하겠습니다. Claude code에서 가장 빠르고
00:32:08가장 가벼운 모델이죠. 그리고 저는 "AI SDK에 대한 튜토리얼을 작성해 줘"라고
00:32:13말할 것입니다. 그리고 무슨 일이 일어나는지 보죠. 이것들을 나란히
00:32:26비교해 볼 텐데, 보시다시피 이미 기술을 로드하기 시작합니다. 여기에는 플러그인이 로드되어 있습니다.
00:32:30만약 플러그인이 로드되지 않은 상태로 세션을 시작하고 싶다면, 'setting sources'
00:32:37플래그가 있는데, 이를 통해 사용자 수준의 소스나 사용자 수준의 설정,
00:32:46또는 프로젝트 수준의 설정을 비활성화할 수 있습니다. 즉, 모든 설정을 무시하는 것이죠.
00:32:53이런 방식으로 플러그인 없이 로드할 수 있습니다. 'no flicker' 옵션은 어제
00:32:59새로 추가되었는데, Claude code 내부에서 부드러운 스크롤을 가능하게 해주는 좋은 방법입니다.
00:33:05이 기능도 활성화하겠습니다. 그런 다음 모델을 가장 똑똑한 모델인 Opus로
00:33:12설정하겠습니다. 그리고 동일하게 "SDK에 대한 튜토리얼을 작성해 줘"라는 프롬프트를
00:33:20입력하겠습니다. 이것이 이쪽의 순정(vanilla) 버전입니다. 그리고
00:33:28결과를 비교해 보겠습니다. 오, 이런, 이전 것을 삭제하지 않았네요. 다시
00:33:36시작하죠. 이걸 다시 실행해 보겠습니다. 이건 오늘 아침에
00:33:50실행하던 것이라 시작 전에 정리해야 했습니다. 다시 시작할게요.
00:33:56비교를 해보는 중입니다.
00:34:01좋습니다. 그래서
00:34:04여기서의 큰 차이점은 이것이 Haiku 4.5 대 Opus 4.6이라는 점입니다. 맞죠? 이쪽이
00:34:15백만 배는 더 저렴하고 훨씬 더 빠릅니다. 게다가 훨씬 더 많은 Vercel 관련 정보가
00:34:22담겨 있습니다. 그래서 우리가 포함하고 있는 추가 토큰의 비용을 비교해 보더라도,
00:34:32Haiku 대 Opus를 보면 말이죠. 이게 마크다운 파일을 생성하라고 했어야 했는데,
00:34:38실제로 코드를 작성하고 있네요. 하지만 그것도 충분히 흥미로울 것 같습니다.
00:34:45한번 보죠. 저희가 많은 기술에 대해 취하고 있는
00:34:59접근 방식 중 하나에 대해 참고할 점이 있습니다. 앞서 언급했듯이,
00:35:05버전 번호나 다른 기술들이 바뀔 수 있기 때문에, 저희는 기술의 버전 번호를 고정(pinning)하고 있습니다.
00:35:13다시 말씀드리면, 저희 라이브러리의 버전마다 서로 다른 기술이 필요할 수 있습니다.
00:35:21그래서 많은 기술들이 "node_modules를 확인해 주세요"라고 말합니다. 그곳에
00:35:28많은 문서를 묶어두었기 때문에 문서들도 버전이 고정되어 있는 셈입니다. 여기를 보시면,
00:35:34실제로 로컬 문서를 읽고 있었습니다. 그리고 여기를 거쳐 가며
00:35:40이 튜토리얼을 작성하고 있습니다. 자, 이제 보겠습니다. 이건
00:35:53조사(research)를 전혀 하지 않았네요. 흥미로운데요. 지난번에는 조사를 훨씬 많이 했거든요.
00:36:01그리고 벌써 보이는데, 4.6 대신 Sonnet 4 같은 구버전 모델을 사용하고 있습니다.
00:36:07구버전이죠. 또한 우리가 사용하고 싶지 않은 'generate object'를 언급했습니다.
00:36:15우리는 V6를 사용합니다. 이미 구식이 되어버린 것들이 많이 보이네요. 그것들이
00:36:23틀렸다고는 할 수 없지만, SDK의 최신 성능과 최적의 관행(best practices)을 원한다면
00:36:28아주 오래된 방식들입니다. 자, 여기서 무언가 감지된 게 있나요?
00:36:37네, 그런 것 같네요. SDK 기술이 감지한 것 같습니다. 처음에는 여기에서
00:36:51튜토리얼을 쓴 것 같은데, 제가 아무 말도 하지 않았음에도 기술이 이것이 V6로 업데이트되지 않았음을
00:36:58감지했습니다. 그리고 이제 업데이트를 진행하고 있습니다. 'generate object'에서 'generate text'로 바꿨죠.
00:37:03그리고 모든 것이 최신 버전인지 확인하며 업데이트를 진행 중입니다. 좋습니다,
00:37:10이 둘을 비교해 볼 수 있겠네요. 새 세션을 시작해서, 여기 들어가서
00:37:23플러그인이 없는 튜토리얼과 Vercel 플러그인이 있는 튜토리얼의 정확도를 비교해 봅시다.
00:37:44이전에는 Opus가 항상 마크다운 파일을 작성했는데,
00:37:48이번에는 코드 스니펫을 작성했네요. 차이를 보는 게 재밌을 것 같습니다.
00:37:54이런 작업을 할 때, 특히 이 플러그인과 함께 작동하는 다른 기술들이 있다면,
00:38:03그들 사이에 충돌이 발생해서 오래된 정보가 선호될 위험은 없나요? 아니면
00:38:10플러그인이 더 높은 우선순위를 갖게 되나요?
00:38:16플러그인은 본질적으로 그 패턴에 기반하여 기술을 강제로 주입할 것입니다. 그래서
00:38:27항상 그런 위험은 존재합니다. 모든 것이 결국 컨텍스트니까요.
00:38:34그 모든 기술은 세션에 밀어 넣어지는 텍스트 파일일 뿐입니다. 그래서 저는 항상
00:38:41현재 진행 중인 프로젝트에 필요한 것들만 사용하라고 말씀드립니다. 실례합니다만,
00:38:49모든 프로젝트에서 사용하고 싶은 게 아니라면 사용자 수준에서 기술을 설치하는 일은 아주 드뭅니다.
00:38:58심지어 Vercel 플러그인의 경우에도, 저희는 현재 진행 중인
00:39:06프로젝트에 필요한 것만 로드할 수 있는 최선의 방법을 찾기 위해 노력하고 있습니다.
00:39:11그와 관련해서 많은 아이디어를 가지고 있습니다. 하지만 가장 논란이 될 만한 아이디어 중 하나는,
00:39:23사용자가 Vercel 플러그인을 설치했다고 했을 때, 그에 대해 어떤 가정을 할 수 있을까 하는 점입니다.
00:39:30사용자가 Vercel 플러그인을 설치했는데 경쟁사의 플랫폼을 사용 중이고, 그 플랫폼에서
00:39:35프로젝트를 열었다면 어떨까요? 그들에게 우리 제품에 대해 이야기해야 할까요? 이건
00:39:42매우 논란의 여지가 있는 부분이죠, 그렇죠? 어떤 사람은 그것을 보고
00:39:47실제로 Vercel로 마이그레이션할 생각이 전혀 없었다면 매우 불쾌해할 것입니다.
00:39:53반면에 다른 사람은 매우 기뻐할 수도 있죠. 그래서
00:39:59정말 흥미로운 점들이 많습니다. 만약 모든 사람이 에이전트와
00:40:05상호작용하게 될 것이라는 이론을 받아들인다면, 플러그인이나
00:40:15에이전트에게 정보를 제공할 때의 에티켓은 무엇일까요? 다른 플랫폼의 영역을
00:40:24침범하지 않으면서 우리 플랫폼의 훌륭한 신기능을 알리는 법 말이죠. 그래서 많은 것들이...
00:40:31이건 제가 지금 하고 있는 일과도 매우 관련이 깊은데, 저희는 곧 워크플로우를 정식 출시(GA)합니다.
00:40:37그래서 마이그레이션 가이드를 작성하고 있죠. 만약 누군가 워크플로우의 경쟁사 제품에서
00:40:43마이그레이션하고 싶어 한다면, 기술을 사용하여 워크플로우로 마이그레이션하라고 직접 말할 수 있을 것입니다.
00:40:49방법은 이렇습니다, 라고 말이죠. 그렇게 하고 싶다면, 에이전트의 어느 시점에서
00:40:55사용자에게 그 사실을 알려야 할까요? 그런 것들이 저에게는 정말 정말 흥미롭습니다.
00:41:00특히 제가 지금 바로 작업하고 있는 일이라 더 머릿속에 가득 차 있네요. 하지만 네,
00:41:07컨텍스트 충돌 같은 문제는 앞으로 계속 발생할 것입니다. 사용자가 무엇을 원하는지
00:41:14프로젝트의 맥락이나 지금까지의 질문을 바탕으로 추론하려는 시도는 계속될 것입니다.
00:41:19그게 가능하다면 훌륭하겠죠. 기술적으로는 과거의 대화 내용을 살펴보고
00:41:27무엇을 했는지 확인할 수도 있습니다. 커밋 기록을 볼 수도 있겠죠. GitHub CLI에게
00:41:35프로젝트의 무엇이든 살펴보라고 시킬 수도 있습니다. 맥락을 파악하기 위해 할 수 있는 일은
00:41:40많지만, 그것은 사용자가 요청하지 않은 도구를 호출하는 등 경계를 넘는 일이 될 수도 있습니다.
00:41:46정말 흥미로운 것들이 많지만, 모든 것을 Vercel에서 처리하고 한 명의 에이전트에게
00:41:53특정 규칙 세트와 모든 것을 아름답게 배포해 주는 플러그인을 제공하여
00:42:00그런 충돌에 대해 걱정하지 않게 만드는 것이 훨씬 쉬울 것입니다. 어쨌든요.
00:42:05이걸 언급하고 싶었네요.
00:42:14플러그인 컨텍스트에서, 우리 기술들은 보통 이 과정 중 어느 단계에 있나요?
00:42:19예를 들어 저에게 'Create React App에서 Next.js로 마이그레이션'하는 기술이 있고,
00:42:26그것이 제 기술 폴더에 들어있다면, 제가 Create React App 프로젝트에 있을 때마다
00:42:32자동으로 호출될 가능성이 높나요? 반면에 여기 Vercel 플러그인이 있다면,
00:42:39언제 호출될지 제가 결정할 수 있고, 만약 동일한 마이그레이션을 플러그인으로 만들었다면
00:42:47사용자가 명시적으로 요청할 때만 발생하게 할 수 있는 건가요? 이게 맞는 생각인가요?
00:42:52그렇게 생각합니다. 저희는 '원샷(one-shot) 기술'이나
00:42:59'단일 사용 기술' 같은 개념에 대해 논의해 왔습니다. 마이그레이션과 같은 것은
00:43:06수행해야 할 하나의 '작업'이죠. 그것은 작업과 관련된 기술이지
00:43:12그 작업 이외의 시간에는 로드하고 싶지 않은 것입니다. 즉, 기술이 프로젝트가 아니라
00:43:17작업의 범위에 맞게 조정되기를 원하는 것이죠. 사용자나 프로젝트 수준이 아니라
00:43:22작업 수준으로 말이죠. 그것이 저희가 나누고 있는 대화입니다. 그리고 명확한
00:43:27답을 드리기는 어려운데, 지금 당장은 그런 기술이 로드되어 있다면
00:43:33사용 중인 모델과 다른 기술들에 따라 하네스와 모델에
00:43:41영향을 줄 것이기 때문입니다. 프로젝트에 다른 무엇이 있는지 모르는 상태에서
00:43:47말하기는 정말 어렵습니다. 하지만 네, 말씀하신 '작업 범위 기술' 또한
00:43:55저희가 깊이 고민하고 있는 주제입니다. 궁금한 게 하나 더 있는데,
00:44:04이 플러그인 아키텍처 중 얼마만큼이 Claude code 전용인가요? 만약 제가 Cursor나
00:44:12Codex 등 다른 도구에서도 비슷한 동작을 원한다면, 그들도 각자의 플러그인 형식이 있나요?
00:44:18각각의 플러그인이 따로 필요한가요? 어떻게 작동하죠? 네, 곧 플러그인 명세(spec)와
00:44:25관련된 발표가 있을 예정입니다. 모두가 마침내 플러그인이 범용적으로 작동하고
00:44:33교차 호환성을 갖게 하는 데 동의하는 분위기입니다. 거의 모든 곳이 동의하고 있죠.
00:44:39오늘 당장은 아니지만, 만약 오늘 Claude code 형식으로 플러그인을 만든다면
00:44:45조만간 다른 도구들과도 호환될 것이라고 기대하셔도 좋습니다.
00:44:54정말 환상적이네요. 이미 스킬 폴더가 너무 많거든요. 드디어 무언가 표준화되기 시작해서 정말 기쁩니다.
00:45:00네, 그 아이디어가... 제가 앤스로픽과 플러그인에 대해 이야기했을 때 좋았던 점은
00:45:07그들이 '확장 프로그램(extension)'이라는 단어 대신 '플러그인(plugin)'이라는 단어를 선택한 이유가
00:45:13플러그인은 꽂았다가(plug in) 다시 뽑을 수 있는(plug out) 것이라는 의미를 내포하기 때문입니다.
00:45:18따라서 특정 스킬 세트로 플러그인을 만들고, 단일 작업을 위해서만
00:45:24다시 사용하고 싶을 때 매우 쉽게 할 수 있어야 한다는 것이죠.
00:45:33제가 프로젝트를 진행 중인 디자이너라면, 제 모든 디자인 스킬들이
00:45:40개발자 스킬이나 다른 것들과 간섭하는 것을 원치 않을 것입니다. 딱 필요한 부분만
00:45:46연결해서 쓰고 싶은 거죠. 저는 이러한 개념에 강력히 동의합니다.
00:45:52개개인마다 고유한 작업, 역할, 프로젝트가 있을 것이고,
00:45:59단순한 스킬보다는 플러그인을 더 선호하게 될 것입니다. 또한 자신만의 플러그인을 직접
00:46:05관리하고 싶어 할 거예요. 자신의 작업 방식에 완전히 맞춤화된 스킬과
00:46:10훅(hooks) 세트를 직접 구축하는 것처럼 말이죠.
00:46:16그렇다면 Vercel 프로젝트가 아닌 작업을 할 때는 Vercel 플러그인의
00:46:21연결을 해제하는 것을 고려해야 한다는 뜻인가요?
00:46:25오늘 기준으로는 그렇다고 말씀드리고 싶네요. 왜냐하면 지금은
00:46:34매우 공격적으로 작동하기 때문입니다. 이런 말을 해서 누군가에게 혼나지 않았으면 좋겠는데,
00:46:39Vercel 플러그인의 전체적인 의도는 에이전트를 실행해서
00:46:46“이것 좀 만들어줘”라고 말하면, 그 결과물이 Vercel 상에
00:46:53마치 마법처럼 나타나게 하는 것이 초기 목표입니다. 현재 그 과정을 지켜보고 있고,
00:46:59받고 있는 피드백에 기반하여 기능을 조금 조정하고 있습니다. 프로젝트에 무엇이 있는지
00:47:04더 잘 감지해서 기능을 비활성화하는 등의 처리가 필요하다는 점을 인지하고 있습니다.
00:47:09그 기능은 아주 곧 추가될 예정입니다. 그러니 일단은
00:47:15설치해서 활성화된 상태로 두셔도 좋습니다. 오늘 아침에도
00:47:18바로 그 부분에 대해 논의하며 활발히 작업 중이거든요.
00:47:23그렇군요. 미래에는 언제 스스로 호출되어야 할지 더 잘 이해하게 되겠지만,
00:47:29지금 당장은 사용자가 세션마다 플러그인을 꽂거나 뽑는 방식으로
00:47:36이 플러그인의 호출 여부를 제어해야 한다는 말씀이시네요.
00:47:42네. 지금은 'slash plugin'을 입력하고 설치된 플러그인 탭으로 이동해서
00:47:48비활성화하고 싶은 플러그인을 선택하면 됩니다. 거기서 업데이트,
00:47:54삭제 등 무엇이든 할 수 있죠. 그런 식으로 비활성화가 가능합니다. 그리고
00:48:03특정 설정 세트를 로드하는 커스텀 ZSH 함수를 설정하는 것과 같은
00:48:10더 고급 기술들도 있습니다. 컴퓨터 앞에 앉은 사람의 프로필이라는 개념과,
00:48:17그들이 무엇을 보고 있는지에 따라 원하는 플러그인이 무엇인지 파악하는 것은
00:48:23매우 복잡한 일입니다. 아직 완벽한 해결책은 없지만,
00:48:29조만간 찾아낼 수 있기를 바랍니다.
00:48:34마치 Waymo 무인 택시가 도착했을 때, 탑승하자마자
00:48:39좌석이 내 몸에 맞춰 조절되어 있는 것과 같겠네요.
00:48:40맞습니다. 그리고 언젠가는 에이전트가 사용자에게
00:48:49더 많은 것을 물어보게 될 것이라고 생각합니다. 프로필, 정체성, 역할이라는 개념은
00:48:57매우 중요한 부분이지만 지금은 빠져 있는 조각처럼 느껴집니다. 모든 사람이
00:49:05전체 프로젝트를 관리하는 매니저라고 가정하고 싶지는 않거든요. 당분간은요.
00:49:12어떤 사람들은 특정 분야에 대해 다른 사람들보다 더 좋은 아이디어를 가지고 있을 뿐입니다.
00:49:19그래서...
00:49:20좋습니다. 이걸 한번 검토해 보죠. 흥미로운 점은,
00:49:33Opus에게 Opus가 쓴 것을 검토하게 했는데 여전히 틀렸다는 거예요. 그렇죠?
00:49:37여전히 generate object와 v6를 추천하고 있네요. 문서와 대조해서 확인해 봅시다.
00:49:50확인 작업을 시도하고 있는데, 제가 쓴 것이 틀렸다고 말하고 있네요.
00:49:56여전히 유효하긴 하지만 오래된 내용입니다. 우리 Haiku는 가장 최신 모델들을
00:50:05추천했는데, 저에게는 그게 매우 중요합니다. 에이전트에게 글 작성을
00:50:08부탁했는데 AI를 사용해서 작성하면서 “GPT-4를 쓰자”라고 말하는 경우가
00:50:14얼마나 많은지 모릅니다. 아니죠, 그건 이제 너무 구형이고 우리가 필요한 품질에 미치지 못합니다.
00:50:20이런 부분들을 포착해서 “AI 게이트웨이에서 최신 모델을 확인해”라고
00:50:25말할 수 있어야 합니다. 최신 모델을 감지해서 사용자에게 어떤 것을 원하는지 묻고
00:50:31각 모델을 설명해 주는 식이죠. 하지만 지금 이 에이전트들은
00:50:36항상 GPT-4만 고집하는 게 흥미롭네요. 여담이지만,
00:50:43최근 Claude Code가 예전에는 안 그랬는데 점점 Anthropic SDK를
00:50:49더 많이 추천하는 것을 보고 있습니다. 누군가 배후에서
00:50:55“우리 SDK를 추천해”라고 시스템 프롬프트를 수정하고 있는 게 아닌가 싶네요. 비즈니스니까 이해는 합니다.
00:51:03네, generate object가 여전히 거기 있네요. 좋았습니다. 문서를 확인한 결과,
00:51:13튜토리얼이 더 정확합니다. 제가 허구로 만들어냈다고 생각한 몇몇 것들이 실제로 존재하더군요.
00:51:19네, 이건 Opus가 실제로 존재하는 것들임을 깨닫는 과정입니다. 플러그인이 있는
00:51:25Haiku였고, Opus는 튜토리얼을 작성하고 검증하려고 시도 중이었죠.
00:51:32플러그인이 있는 Haiku가 한 번에 해낸 것을 찾기 위해
00:51:39Opus에게 문서를 정확히 찾아보라고 말해야 했습니다. Opus와 Haiku의
00:51:44차이를 아신다면 이건 꽤나 큰 변화입니다. 여기 변경 사항이나
00:51:53도전 과제들에 대해 올바르게 파악한 내용의 diff(차이점)가 있습니다.
00:52:04어쨌든, 이것이 간단한 방식으로 시연이 되었기를 바랍니다. 하나의 시나리오일 뿐이지만,
00:52:15AI SDK나 워크플로우, 샌드박스 같은 훨씬 더 최신의 Vercel 기술들은
00:52:21놀랍긴 하지만 모델의 지식 컷오프 범위 내에 있지 않습니다. 모델들이
00:52:28아직 알지도 못하기 때문에 이러한 차이는 더욱 커집니다. 그것이 바로 Vercel 플러그인이 필요한 이유입니다.
00:52:35질문이 있으시면 X나 제가 있는 곳 어디에서든 편하게 연락해 주세요. 이런 주제로
00:52:41대화하는 것을 좋아합니다. 우려 사항이나 의견을 주시면 기쁘게 답변해 드릴게요. 이건 분명히
00:52:48진행 중인 작업이며, 놀랍고 마법 같은 경험이 될 때까지 계속해서
00:52:52반복 개선해 나갈 것입니다. 오늘 그 시작을 확인하셨기를 바랍니다.
00:52:59질문이 있으시면 답변해 드리겠습니다. 브레인스토밍하고 싶은 플러그인
00:53:04아이디어가 있다면 그것에 대해서도 기꺼이 이야기 나누고 싶습니다. 다른 부분을
00:53:14더 파고들길 원하시는 게 아니라면, 오늘 제가 준비한 내용은 여기까지입니다.
00:53:20시간 내주셔서 정말 감사합니다. 받아들일 내용이 많네요. 큰 변화입니다.
00:53:25이 모든 AI 도구들과 함께 정말 빠르게 움직여 왔네요.
00:53:28네, 안타깝게도 속도는 줄어들지 않을 것 같습니다.
00:53:33질문이 하나 더 있는데요, 사람들이 어떤 방식으로든 기여하고 싶거나
00:53:38버그를 발견해서 제보하고 싶다면 가장 좋은 방법이 무엇인가요?
00:53:41아, 네. 해당 레포지토리입니다. Vercel 슬래시, Vercel 슬래시 플러그인인가요,
00:53:49아니면 Vercel 슬래시 Vercel-플러그인인가요?
00:53:51네, vercel/vercel-plugin입니다.
00:53:58알겠습니다. 사람들이 확인할 수 있도록 채팅창에도 링크를 남겨둘게요.
00:54:03감사합니다. 이슈 제보는 언제든 환영입니다. 빠르게 변화할 거예요.
00:54:10이 통화 바로 직전에도 큰 PR을 하나 승인했거든요.
00:54:14멋지네요. 제이콥, 다른 질문 더 있나요?
00:54:20아니요, 스트림에서 모든 내용을 다룬 것 같습니다. 심도 있고 훌륭한 데모
00:54:24진행해 주셔서 감사합니다. 이제 저만의 Claude 플러그인을 만들 준비가 된 기분이에요.
00:54:30에이전트가 멋대로 main 브랜치에 강제 푸시(force push)를 할 때 화만 내는 대신,
00:54:37이제는 어떤 훅을 사용하라고 말해줘야 그런 일이 다시 발생하지 않을지
00:54:42알게 되었습니다. 정말 도움이 되네요.
00:54:45pre-tools(도구 실행 전 단계)는 원치 않는 일을 방지하는 가장 좋은 방어책입니다.
00:54:51좋네요. 정말 감사합니다, 존. 별말씀을요. 모두 감사합니다.
00:54:56함께해주신 여러분 감사합니다. 예정된 세션은 [community.vercel.com/events에서](https://www.google.com/search?q=https://community.vercel.com/events%EC%97%90%EC%84%9C)
00:55:01확인하실 수 있습니다. 그럼 다음에 뵙겠습니다.
00:55:05네, 커뮤니티에서 뵐게요. 모두 좋은 하루 보내세요.