00:00:00[무음]
00:00:30[무음]
00:01:00안녕하세요 여러분, 다들 잘 지내시나요?
00:01:25또 다른 Vercel 커뮤니티 세션에 오신 것을 환영합니다.
00:01:29여러분을 모시게 되어 정말 기쁩니다.
00:01:32이번 세션에 처음 참여하신 분들을 위해
00:01:35인사드릴게요. 저는 Vercel 커뮤니티 팀의 Pauline Navas입니다.
00:01:40커뮤니티 공간에서 저를 보신 적이 있을지도 모르겠네요.
00:01:44여러분과 라이브로 대화하고 소통하는 이 시간은
00:01:46저에게 항상 즐거운 시간입니다.
00:01:51이미 많은 분이 시청하고 계신 게 보여서 정말 좋네요.
00:01:56세션에 처음 참여하셔서 채팅창이 보이지 않는데
00:02:00질문을 하고 싶으신 분들이 계신다면,
00:02:02이번 세션에서는 질문을 적극적으로 권장해 드립니다.
00:02:06커뮤니티 플랫폼인 community.vercel.com에 접속해 보세요.
00:02:12그리고 이번 이벤트의 "참여하기"를 클릭하시면 됩니다.
00:02:15그러면 세션 내내 채팅을 이용해 질문을 남기실 수 있습니다.
00:02:20X나 다른 플랫폼에서 시청 중이시라면 그곳을 이용하셔도 좋습니다.
00:02:25오늘 세션이 정말 기대되는데요.
00:02:28느껴지실지 모르겠지만, 오늘은 개발자들이 AI 에이전트를 사용하는 방식을
00:02:32완전히 바꾸고 있는 주제를 다뤄보려고 합니다.
00:02:36바로 "Claude Code용 스킬"입니다.
00:02:39AI 에이전트가 알아서 척척 일을 해줬으면 좋겠다고 생각하신 적이 있나요?
00:02:44가령 Next.js를 올바른 방식으로 업그레이드하거나 팀의 코딩 컨벤션을 따르는 것처럼요.
00:02:49이런 기능들을 가능하게 해주는 것이 바로 "스킬"입니다.
00:02:51그래서 이번 워크숍을 진행해 주실
00:02:56Vercel AI DX 팀의 John 님을 모셨습니다.
00:03:02안녕하세요, John.
00:03:04안녕하세요, Pauline.
00:03:05여러분 안녕하세요.
00:03:05와주셔서 감사합니다.
00:03:07만나서 정말 반가워요.
00:03:09자, 그럼 시작해 볼까요?
00:03:12좋습니다, 시작하죠.
00:03:13네, 그럼 스킬에 대해 이야기해 보겠습니다.
00:03:15나온 지 오래된 것 같지만 사실 고작 2주 정도 됐을 거예요. 누가 알겠어요?
00:03:20이 프레젠테이션을 통해 스킬에 관해 설명해 드릴 예정입니다.
00:03:24몇 가지 시연도 보여드릴 테니 궁금한 점이 있으면 언제든 편하게 질문해 주세요.
00:03:28저는 이 주제로 이야기하는 걸 정말 좋아하거든요.
00:03:31먼저 스킬을 만들고 배포하는 방법부터
00:03:35이야기해 보겠습니다.
00:03:36사실 이 프레젠테이션도 "Remotion Geist"라는 스킬로 제작되었습니다.
00:03:42Vercel의 디자인 언어를 Remotion과 결합하여
00:03:46만든 것인데, 이건 나중에 자세히 보여드릴게요.
00:03:48우선은 몇 가지 영상을 보면서 진행하겠습니다.
00:03:51과거에는 모델 성능이 지금만큼 좋지 않았을 때,
00:03:55꽤 오랫동안 프롬프트 엔지니어링에 대해 이야기했습니다.
00:03:58모두가 프롬프트를 완벽하게 만들어야 했고,
00:04:00프롬프트 엔지니어링이 하나의 유망한 직업이 될 거라고 생각했죠.
00:04:03하지만 이제는 "컨텍스트(문맥) 엔지니어링"으로 중심이 옮겨가고 있습니다.
00:04:08마크다운 파일 형태의 스킬을 나중에 필요할 때 불러오는 방식이죠.
00:04:13즉, 처음 입력하는 프롬프트와
00:04:17나중에 로드되는 컨텍스트 조각들이 서로 분리되는 겁니다.
00:04:19우리는 이것을 "스킬"이라고 부르기로 했습니다.
00:04:22스킬은 Anthropic에서 처음 시작되었습니다.
00:04:25Claude Code에게 특정 작업들을 가르칠 필요가 있었기 때문인데요.
00:04:30모든 모델은 백지 상태에서 시작하고 기억력이 없기 때문입니다.
00:04:33마치 갓 태어난 아기에게 아무런 기술이 없는 것과 비슷하죠.
00:04:37머릿속에 주입된 고유한 지식만 가지고 있을 뿐입니다.
00:04:42그래서 처음에는 아무것도 할 줄 모르는 상태입니다.
00:04:44Anthropic은 이 문제를 어떻게 해결할까 고민했죠.
00:04:48답은 역시 마크다운이었습니다. 요즘은 모든 문제가
00:04:51마크다운으로 해결되곤 하는데, 스킬도 그렇게 탄생했습니다.
00:04:55이제 여러분은 이 스킬들을 패키지화할 수 있습니다.
00:04:58스킬은 팀원들과 공유할 수 있는 마크다운 파일이며,
00:05:04내부 워크플로우를 패키지 형태로 관리할 수 있게 해줍니다.
00:05:07GitHub 리포지토리에 올려서 공유할 수도 있습니다.
00:05:12저희가 출시한 전용 도구도 있습니다.
00:05:15커뮤니티 스킬을 관리하는 브라우저 창을 잠시 보여드릴게요.
00:05:22skills.sh라는 사이트에 접속하시면 됩니다.
00:05:27여기서 커뮤니티 스킬을 검색할 수 있고,
00:05:29가장 많이 사용되는 스킬들도 찾아볼 수 있습니다.
00:05:32늘 그렇듯, 신뢰할 수 있는 출처나 팀원이 만든 것인지
00:05:36먼저 확인하고 사용하는 것이 중요합니다.
00:05:38자신이 하려는 작업과 방향이 맞는지 알아야 하니까요.
00:05:42사용법은 나중에 더 자세히 다루겠습니다.
00:05:45어쨌든 이곳은 전체 생태계와 커뮤니티에 어떤 스킬들이
00:05:48있는지 한눈에 살펴보기에 아주 좋은 곳입니다.
00:05:50워크숍의 구체적인 진행 방식은 이 정도면 설명된 것 같으니,
00:05:56다음 영상으로 넘어가 보겠습니다.
00:06:00다시 백지 상태에 대해 이야기해 보죠.
00:06:07아기가 태어난 것처럼 에이전트가 처음 시작될 때,
00:06:11여기서 에이전트는 특정 프로그램을 실행하는 모델을 말합니다.
00:06:14화면을 좀 더 키워볼게요.
00:06:16에이전트는 React, TypeScript, CSS, SQL 같은 기초 지식은 알고 있습니다.
00:06:23하지만 모르는 것이 있는데, 바로 여러분만의 규칙, 패턴,
00:06:28시스템 구조 같은 것들입니다.
00:06:30그래서 에이전트가 원래 알고 있는 것과 여러분의
00:06:35개인화된 정보를 결합하여 그 지식의 간극을 메워주는 겁니다.
00:06:40컨텍스트를 가져오고 스킬을 로드함으로써,
00:06:42에이전트가 여러분이 원하는 방식 그대로 작업을 수행하게 됩니다.
00:06:45에이전트는 프로그래밍 언어 자체는 잘 압니다.
00:06:51하지만 여러분이 사용하는 특정 방식이나 스타일은 모릅니다.
00:06:53그렇게 이해하시면 쉬울 거예요.
00:06:54여기까지 질문 있으신가요?
00:07:01제가 놓친 질문이 있나요?
00:07:03아직 질문은 없습니다.
00:07:06채팅창 열기가 아주 뜨겁네요.
00:07:08 John, 계속 진행해 주세요.
00:07:09계속 가보죠.
00:07:11저는 지금이 스킬에 있어서 마치 NPM이 등장했을 때와 같은 순간이라고 생각합니다.
00:07:17NPM은 대부분 잘 아시는 패키지 매니저죠.
00:07:23패키지 매니저에는 커뮤니티가 만들어 놓은 리소스들이 묶여 있고,
00:07:27이를 사용해 제품을 더 쉽게 개발할 수 있습니다.
00:07:30스킬과 skills.sh를 스킬용 패키지 매니저라고 생각한다면,
00:07:35이러한 기능들을 에이전트에 설치할 수 있는 겁니다.
00:07:39라이브러리를 설치하는 것과 마찬가지로,
00:07:41npx skills add 명령어로 프로젝트에 지식을 추가할 수 있습니다.
00:07:45이전의 프롬프트 엔지니어링 방식은 claude.md나
00:07:52agents.md 파일에 "항상 이렇게 해라", "저렇게 해라"라고 적는 식이었습니다.
00:07:55"이 라이브러리를 써라", "Jira를 확인해라" 같은 것들을 일일이 나열했죠.
00:07:59하지만 이제는 그런 내용들을 스킬로 만들어서
00:08:04프로젝트로 바로 가져올 수 있습니다.
00:08:06한 번 추가하면 계속 유지되죠.
00:08:08사용자 단위나 프로젝트 단위로 공유할 수도 있고,
00:08:11개별 프로젝트와 별개로 관리할 수도 있습니다.
00:08:14더 이상 복사해서 붙여넣을 필요가 없습니다.
00:08:17많은 부분을 자동화할 수 있어서, 새로운 프로젝트를 시작할 때
00:08:21필요한 모든 스킬을 한 번에 추가할 수 있습니다.
00:08:23요점은, 이제 프롬프트를 일일이 구성하는 데
00:08:28너무 큰 공을 들일 필요가 없다는 겁니다.
00:08:30알겠습니다.
00:08:34정리하자면, 이건 팀 전체가 영구적으로 사용할 수 있는 역량입니다.
00:08:38혹시 프로젝트 내의 agents.md나
00:08:43claude.md 파일을 관리하느라 고생해 본 적이 없다면 잘 모르시겠지만,
00:08:47마크다운 파일에 매번 PR을 올리고 관리하는 건 꽤 힘든 일입니다.
00:08:50스킬은 그런 문제도 해결해 줍니다.
00:08:53개발자 한 명과 팀 전체의 차이에 대해 이야기하는 것이기도 하죠.
00:08:58자, 그럼 이제 여러분이 고려해 볼 만한
00:09:03수동(Passive) 방식과 능동(Active) 방식에 대해 말씀드리겠습니다.
00:09:05수동 방식은 스킬이 정말로
00:09:12필요해지기 전까지는 로드되지 않는 것을 말합니다.
00:09:15agents.md의 결과를 보면
00:09:22마크다운 파일은 시스템 프롬프트처럼
00:09:25가장 먼저 읽히는 요소입니다.
00:09:26항상 먼저 로드되어야 하죠.
00:09:28에이전트가 반드시 읽어야 하니까요.
00:09:31테스트 결과를 보면 알 수 있듯이,
00:09:35그곳에 너무 많은 컨텍스트를 쏟아붓고
00:09:38컨텍스트 윈도우를 가득 채우면,
00:09:41에이전트가 규칙을 훨씬 더 잘
00:09:46준수하게 됩니다. TypeScript나 Tailwind를 항상 쓰는 것 같은 규칙 말이죠.
00:09:50이때 스킬은 더 능동적으로 변합니다.
00:09:53사용자가 직접 호출할 수도 있고,
00:09:57에이전트가 지연 로딩 방식으로
00:10:00필요한 순간에만 필요한 내용을 가져올 수도 있습니다.
00:10:04Vercel 배포나 데이터베이스 생성 같은 작업이 그렇죠.
00:10:08결국 "규칙"과 "도구"의 차이인데,
00:10:13스킬을 도구라고 생각하시면 됩니다.
00:10:15그리고 작업을 위해선 항상 두 가지가 모두 필요하죠.
00:10:18John, 질문이 하나 올라왔는데요,
00:10:21지금 답변해 주시기 좋을 것 같습니다.
00:10:24특정 기능을 MCP(모델 컨텍스트 프로토콜)로 만들지,
00:10:28아니면 스킬로 만들지 어떻게 결정하나요?
00:10:30저라면 기본적으로는,
00:10:33몇 가지 계층이 있다고 생각하는데요.
00:10:37화면에 참고할 만한 걸 띄워놓고 싶네요.
00:10:38잠시만요.
00:10:39네, 좋습니다.
00:10:40가장 기본적으로, 마크다운으로 해결할 수 있다면 그렇게 하세요.
00:10:44마크다운으로 부족하다면 CLI로 해결하시고요.
00:10:47CLI로도 부족하다면 그때 MCP를 쓰면 됩니다.
00:10:51일종의 추상화 단계라고 보시면 되는데,
00:10:53단순함의 관점에서 볼 때
00:10:58마크다운으로 문제를 해결할 방법을 찾을 수 있다면
00:10:59그게 최선입니다. 모든 AI 기반 도구가 그렇듯이요.
00:11:01Anthropic이 Claude Code를 설계한 방식이나
00:11:05다른 곳에서 스킬, 커맨드, 서브 에이전트를
00:11:08다루는 방식을 보면 알 수 있습니다.
00:11:11그것들은 대부분 프런트 매터와 설정이 포함된 마크다운 파일이며,
00:11:13지금까지는 그것만으로도 충분했습니다.
00:11:15그 마크다운 파일 안에서 필요한 도구가 무엇인지,
00:11:19어떤 도구 호출이 허용되는지,
00:11:21어떤 제한 사항이 있는지 정의할 수 있습니다.
00:11:24이런 설정을 꼼꼼히 잡는 데 시간이 좀 걸릴 수도 있겠지만요.
00:11:29하지만 에이전트와 MCP 사이에서 오가는
00:11:31페이로드나 데이터 타입을
00:11:37아주 엄격하게 제어해야 하는 상황이라면,
00:11:40그때는 MCP가 좋은 해결책이 됩니다.
00:11:42하지만 전반적인 흐름이나 패러다임을 보면
00:11:43CLI와 마크다운 파일을 주로 사용하고,
00:11:46MCP는 꼭 필요한 경우에만 사용하는 쪽으로 움직이고 있습니다.
00:11:50네, 저도 온라인상에서 오가는
00:11:54이야기들을 보면 그런 것 같습니다.
00:11:59X에서 또 다른 질문이 들어왔네요.
00:12:04정말 흥미로운 질문인데, 머지않은 미래에
00:12:06스킬이 에이전트 간의 상호 탐색을 지원하게 될까요?
00:12:10한 에이전트가 다른 에이전트에게 필요한 스킬을
00:12:13직접 설치하도록 결정하는 모습은 정말 멋질 것 같습니다.
00:12:17이 질문 정말 마음에 드네요. 에이전트 간의 소통은
00:12:20아직 충분히 활용되지 않고 있지만 아주 중요한 패턴입니다.
00:12:22당연히 가능하다고 봅니다. 로드되는 에이전트의 명세서 같은 역할을 하는
00:12:27마크다운 파일을 상상해 볼 수 있겠죠.
00:12:32현재 Claude는 서브 에이전트 기능을 통해 이를 지원하고 있습니다.
00:12:39그리고 마침 오늘 발표된
00:12:42팀(Teams) 기능에 대해 이야기하기 딱 좋네요.
00:12:46여러 서브 에이전트 그룹을 생성하고
00:12:49그 결과를 메인 리더에게 보고하게 할 수 있는 기능입니다.
00:12:54그들은 이제 이것을 "팀"이라고 부릅니다.
00:12:59한 명의 팀 리더가 그 팀들을 관리하고,
00:13:02이제 그들을 팀이라고 부르죠.
00:13:04그러면 그 팀들은 기본적으로
00:13:10그 한 명의 팀장에 의해 관리될 수 있고, 여러분은 들어가서
00:13:12에이전트들이 무엇을 하고 있는지 확인할 수 있습니다.
00:13:14그리고 그 에이전트들은 자신들이 무엇을 하는지에 대한 정의를 가지고 있죠.
00:13:18그에 관한 문서를 빨리 찾을 수 있을지 모르겠네요.
00:13:23- 존이 그것을 찾는 동안,
00:13:30채팅창에 계신 분들 중 질문하고 싶은 것이 있다면
00:13:34지금이 기회입니다. 편하게 채팅창에 다 올려주시면
00:13:37세션 진행 중에 답변해 드리겠습니다.
00:13:40- 어디에 올리면 될까요, 아마 트위터 채팅에라도
00:13:42게시할 수 있을 것 같네요.
00:13:47여기 보시면,
00:13:51이 페이지에서 서브 에이전트가 정의되는 방식을 볼 수 있는데
00:13:58프론트 매터(front matter) 섹션이 있는 것을 볼 수 있습니다.
00:14:01그리고 그 프론트 매터 섹션에서,
00:14:03해당 서브 에이전트가 접근할 수 있는 스킬들을 정의할 수 있습니다.
00:14:08따라서 에이전트를 만들고 싶다면, 이 경우에는
00:14:13스킬 목록을 가진 서브 에이전트인데,
00:14:17지정된 스킬 이름을 통해 이를 수행할 수 있습니다.
00:14:20아직 설명하진 않았지만,
00:14:22다음 슬라이드는 스킬의 구조에 관한 것입니다.
00:14:26하지만 스킬은 본질적으로 그냥 이름일 뿐입니다.
00:14:28그래서 특정 스킬 세트를 가진
00:14:29서브 에이전트를 가질 수 있고,
00:14:31매우 특별한 스킬 세트를 가진 에이전트를 만들어
00:14:34그 서브 에이전트가 작업을 처리하게 할 수 있습니다.
00:14:38오늘 출시된 팀 기능에서 일어나고 있는 일은
00:14:43그들이,
00:14:45클로드 코드(Claude Code)가 본질적으로 자체 팀을 구성하고
00:14:48자체 에이전트들을 구축하여
00:14:49최대한 작업을 해결해 나가는 방식입니다.
00:14:53하지만 커스텀 스킬을 가진 커스텀 서브 에이전트를 정의하여
00:14:56직접 지정하고 싶다면,
00:14:57"이 서브 에이전트들을 사용해서 팀을 구성해 줘"라고 할 수 있습니다.
00:15:00물론 이것이 완전한 에이전트 간 통신은 아닙니다.
00:15:05그것은 에이전트 간의 통신 아키텍처를 설계하는 것에 관한
00:15:08훨씬 더 큰 논의가 필요한 부분이며,
00:15:11이번 세션의 범위를 벗어나는 내용입니다.
00:15:12하지만 저는 우리가 서브 에이전트를
00:15:14정의하는 이 방식이
00:15:17일반적인 에이전트를 정의하고
00:15:21서로 통신하는 방식에도 채택될 것이라고 봅니다.
00:15:23에이전트를 노출하는 방식처럼,
00:15:24저는 마크다운 파일이 그 역할을 할 것으로 상상합니다.
00:15:26"내가 할 수 있는 일은 이것들입니다"와 같은,
00:15:28"감독님, 저 좀 투입시켜 주세요" 식의 패턴이죠.
00:15:30"저는 이런 스킬이 있고, 3점 슛도 쏘고,
00:15:32리바운드도 할 수 있으니 투입시켜 주세요"라고요.
00:15:34그러면 에이전트들이 그런 식으로 서로를 발견할 수 있을 겁니다.
00:15:39그리고 스킬을 위한 skills.sh가 있는 것처럼,
00:15:43스킬을 위한 패키지 매니저 같은 것이죠.
00:15:47에이전트와 에이전트 마크다운 파일을 위한
00:15:49패키지 매니저도 생기게 될 것입니다.
00:15:51그것은 자연스럽게 일어날 일입니다.
00:15:54제 말은, 이미 누군가에 의해
00:15:57실행되었거나 발표되었을 수도 있지만,
00:15:58아직 주류가 되지 않았을 뿐입니다.
00:16:00- 일리가 있는 말씀이네요.
00:16:03감사합니다, 감사합니다.
00:16:04여러분, 질문이 더 있다면
00:16:06채팅창에 남겨주세요.
00:16:08그동안 계속 진행해 주시겠어요, 존?
00:16:10- 네, 물론이죠.
00:16:12스킬은 서버나 호스팅 없이 그냥 폴더일 뿐입니다.
00:16:15스킬은 디렉토리 안에 들어 있고,
00:16:20이름을 지정해 주면 되는데, 스킬 이름이나
00:16:24스킬 파일 이름은 반드시 skill.md여야 합니다.
00:16:28그래야 에이전트들이 검색 패턴을 통해
00:16:31스킬을 찾을 수 있습니다.
00:16:32이것은 툴링이 이들과 더 잘 작동하도록
00:16:35설정된 규칙일 뿐입니다.
00:16:36패키지 매니저를 구축하거나 조직화하는 등의 작업을
00:16:39정말 쉽게 만들어 주죠.
00:16:41또한 스킬은 함께 묶여 제공될 수 있습니다.
00:16:45번들 스크립트나 참조 파일을 포함할 수 있고,
00:16:49스킬이 내부에서 참조된 다른 요소들로
00:16:53확장될 수 있는 온갖 기능들이 있습니다.
00:16:56그래서 스킬에는 프론트 매터가 포함됩니다.
00:17:01기본적으로 이름과 설명이 필요하죠.
00:17:04그리고 이름은 구조를 살펴보면,
00:17:08해당 이름과 일치해야 합니다.
00:17:10가령 'my-skill'이라는 이름으로 만든다면,
00:17:12여기에 'my-skill'이라고 적어야 합니다.
00:17:17그리고 설명이 아주 중요한데,
00:17:20에이전트가 이 스킬을 언제 사용할지를
00:17:23알려주기 때문입니다.
00:17:24에이전트는
00:17:26할당받은 작업을 수행하면서 판단할 것입니다.
00:17:29작업을 하다가 어떤 지점에 도달했을 때,
00:17:31"아, 판매 표준을 강제하는 무언가가 필요해"라고 판단하면,
00:17:33이 스킬을 불러오게 되는 것이죠.
00:17:38스킬 로딩 도구를 사용해 이 스킬을 로드할 것입니다.
00:17:41그래서 이 설명들이 매우 중요해집니다.
00:17:42작성하는 방식에 따라,
00:17:43스킬을 지연 로딩(lazy loading) 방식으로 쓸 수도 있고,
00:17:46아니면 슬래시(/)를 사용해 명령어로 간주하여
00:17:50미리 호출할 수도 있습니다.
00:17:52명령어와 스킬을 비교한 슬라이드가 있을 텐데,
00:17:55본래 이 둘은 두 개의 별개 기능이었지만
00:18:00이제는 하나로 통합되었습니다.
00:18:03과거에 스킬은 지연 로딩만 가능했으나,
00:18:04이제는 사용자가 슬래시로 직접 호출하거나
00:18:08에이전트가 필요할 때 지연 로딩할 수 있습니다.
00:18:12그 말은 즉, 여기서 슬래시를 입력하면
00:18:17사용 가능한 스킬 목록을 볼 수 있고,
00:18:19원한다면 수동으로 호출할 수도 있고,
00:18:22에이전트가 필요할 때 호출할 때까지 기다릴 수도 있다는 뜻입니다.
00:18:27이제 여기서부터 더 집중해 보죠.
00:18:32- 이 내용에 대해서도 다루시겠지만,
00:18:39저는 개인적으로 구체적인 사례를 듣고 싶습니다.
00:18:43이 모델을 이해하기 위해 누구나 처음 만들어 볼 만한,
00:18:47작고 범위가 잘 정의된 스킬은 무엇이 있을까요?
00:18:52- 오, 좋은 질문이네요. 지금 가장 좋은 예시라고
00:18:55생각되는 것을 말씀드릴게요.
00:18:57본질적으로 버셀(Vercel)에서 우리가 겪는
00:19:03몇 가지 스킬 관련 문제는 우리가 제품을
00:19:07정말 빠른 속도로 출시한다는 점입니다.
00:19:12에이전트와 모델들은 지식 컷오프(Knowledge Cutoff) 날짜가 있는데,
00:19:15이것이 몇 달 전부터 길게는 1년 이상 전일 수도 있습니다.
00:19:19그래서 기본적으로,
00:19:24에이전트에게 작업을 주면 Next.js 14를 사용할 수도 있는데,
00:19:30그건 이미 몇 버전 전의 구버전이죠.
00:19:33또는 최근에 'generate object'가 폐기되고
00:19:35'generate text'의 일부로 통합된 AI SDK를
00:19:39사용할 수도 있습니다.
00:19:41API를 더 표준화하고 따르기 쉽게 만들기 위해서죠.
00:19:45그러면 이런 문제에 부딪히게 됩니다.
00:19:50에이전트는 구버전을 사용하려 하고
00:19:51사용자는 최신 작업을 하려 하는데,
00:19:53공식 문서를 읽어봐도
00:19:54정보가 서로 일치하지 않고 동기화되지 않는 것이죠.
00:19:56그러면 프로젝트는 한동안 진척 없이 맴돌게 됩니다.
00:20:00에이전트가 무엇이 필요한지
00:20:03파악하거나 맞추지 못하기 때문입니다.
00:20:05따라서 에이전트와 방향을 맞추기 위해,
00:20:08다음과 같은 스킬을 만들 수 있습니다.
00:20:11"이 버전의 React를 쓰고, 이 버전의 AI SDK를 쓰고,
00:20:16이 버전의 워크플로우를 써라"라고요.
00:20:18그리고 그 정보들을 어디서 찾을 수 있는지
00:20:19참조 링크를 넣어줄 수 있습니다.
00:20:22예를 들어 제가 버셀을 위해 만든 스킬인데,
00:20:28잠시 보여드릴게요.
00:20:33이것이 바로 버셀 워크플로우 스킬입니다.
00:20:40며칠 전에 배포한 것이죠.
00:20:43우리가 이 작업을 하는 방식은,
00:20:46버전 번호에 매우 민감하기 때문에
00:20:49기본적으로 이렇게 말합니다.
00:20:50우리는 NPM 패키지와 함께 문서를 게시하기 시작했고,
00:20:54에이전트에게 당신의 워크플로우,
00:20:58즉 워크플로우에 대한 지식은 구식이라고 알려줍니다.
00:20:59워크플로우가 정식 출시(GA)를 향해 가면서
00:21:02거의 매일 업데이트된다는 걸 우리가 알기 때문입니다.
00:21:06하지만 우리가 할 수 있는 일은 이렇게 말하는 것입니다.
00:21:10"자, 우리가 문서를 번들로 묶어놨어."
00:21:11"워크플로우를 찾아봐야 할 때마다
00:21:13우리가 묶어둔 문서를 확인하고
00:21:16최신 정보를 체크해."
00:21:18이렇게 하면 제가 워크플로우 작업을 시작할 때마다
00:21:22에이전트가 예전 정보를 찾을까 봐 걱정할 필요가 없습니다.
00:21:25항상 NPM 패키지에 번들로 제공된 정보를 찾기 때문에
00:21:27버전 자체가
00:21:32서로 완벽하게 동기화되고 일치하게 됩니다.
00:21:34이 스킬의 전체 내용은 본질적으로
00:21:38빠른 참조를 위한 몇 가지 핵심 모범 사례와 함께
00:21:42설명서를 읽으라는 지침입니다.
00:21:44이런 것들은 에이전트의 지식 컷오프 날짜와
00:21:48버전 번호 문제 등으로 인해 발생하는
00:21:53어려움을 해결해 주는 스킬들입니다.
00:21:57스스로를 위해 작성할 수 있는 스킬로는,
00:22:01제 생각엔 만약 이 스킬을 사용하신다면,
00:22:07'create skill'이라는 스킬을 예로 들어보겠습니다.
00:22:11skills.sh에서 'create skill'을 검색해 보면,
00:22:14'create skill'... 음, 잘 나올지 모르겠네요.
00:22:23여기서 'create skill' 같은 걸 하나 가져온다면,
00:22:28아마 클로드 코드 팀에서 만든 걸 가져오는 게 좋겠네요.
00:22:33클로드 거였나요, 우리가 게시했던 것 같은데.
00:22:39죄송합니다, 이건 미리 준비하지 못했네요.
00:22:42- 네, 그걸 찾으시는 동안에도,
00:22:46아, 찾으셨군요. 계속하세요.
00:22:47- 클로드 코드 대신에 앤스로픽(Anthropic)을
00:22:49생각했어야 했네요.
00:22:50네, 그들의 'create skill'이나 패턴 중 하나를 가져오면
00:22:54'create skill'이라고 입력한 다음
00:22:58이렇게 말할 수 있습니다.
00:23:02"readme.md 파일에 있는
00:23:09나의 글쓰기 스타일을 파악해서
00:23:12항상 이 스타일을 따르는 스킬을 만들어 줘."
00:23:14그러면 이 스킬은 리드미 파일에 있는 내용을 가져와서
00:23:19본질적으로 당신의
00:23:21개인화된 글쓰기 스타일과 같은 스킬을 생성합니다.
00:23:23그 이후로는 '존의 글쓰기 스타일' 같은 이름으로
00:23:26그 스킬을 호출하기만 하면 됩니다.
00:23:28엄청난 양의 문서를 제공하거나
00:23:31블로그 포스트, 개인 게시물, 또는 고객용 언어 등의 URL을
00:23:33참조하라고 알려주고
00:23:37그냥 입력을 넣어주기만 하면 됩니다.
00:23:38시작점으로 가장 좋은 건 항상
00:23:40"이미 가지고 있는 것 중에
00:23:42다시 재현하고 싶은 것이 무엇인가?"입니다.
00:23:43항상 사용하고 있고
00:23:46앞으로 더 많이 쓰게 될 것 같은 게 무엇인지 생각해보는 거죠.
00:23:50보통 그런 건 고객 메시징이나
00:23:53블로그 포스트, 콘텐츠, 자료처럼
00:23:56과거에 이미 만들어 본 것들이고
00:23:57그걸 더 많이 생성하고 싶은 경우입니다.
00:23:59네, 그게 시작하기에 아주 좋은 스타일입니다.
00:24:04- 정말 좋은 아이디어네요.
00:24:05저도 꼭 시도해봐야겠어요.
00:24:06채팅창에 올라온 의견들을
00:24:08몇 개 읽어드리고 싶네요.
00:24:10Dave 님이 말씀하시길, 저희는 스킬을 만들어서
00:24:1410년 동안 코딩을 안 했던 스타트업 창업자가
00:24:17직접 코드 기여를 할 수 있게 했습니다.
00:24:19새로운 코드베이스 내에서 아키텍처의 경계를
00:24:23무너뜨리지 않으면서 말이죠.
00:24:24비기술직이나 코딩 초보자들이
00:24:27품질 기준을 타협하지 않고도
00:24:30코딩 작업에 직접 참여할 수 있게 돕는 데
00:24:32스킬이 아주 유용하다는 걸 발견했습니다. 정말 멋지네요.
00:24:38그리고 덧붙여서, Dave 님이 아까 하신 말씀인데
00:24:42John 님이 말씀하신 것에 공감한다며,
00:24:45요즘 흔히 쓰이는 도구들에 대해 언급하셨어요.
00:24:47그가 사용하는 유일한 MCP 도구는 Chrome 개발자 도구 MCP와
00:24:52Linear나 JIRA 같은 프로젝트 관리 도구,
00:24:56그리고 데이터베이스와 상호작용하는 도구뿐이라고요.
00:24:59아까 하신 말씀들과 일맥상통하는 내용이네요.
00:25:02다음으로 넘어가기 전에, 채팅창에 질문이 하나 들어왔는데요.
00:25:07저희 에이전트 평가(evals) 블로그 포스트에서
00:25:12agents.md가 스킬보다 성능이 좋다고 나온 것에 대한 의견을 물으셨어요.
00:25:17발표 중에 이 내용을 다루실지
00:25:19잘 모르겠네요.
00:25:21이야기가 여러 군데로 샜습니다만,
00:25:25지금 이 질문에 대해 말씀해 주시겠어요?
00:25:27- 네, 좋습니다.
00:25:28모델과 에이전트를 평가한다는 건
00:25:34정말 어려운 일입니다.
00:25:38보통 평가(eval) 코드를 작성할 때,
00:25:42아무런 컨텍스트도 로드되지 않은
00:25:46새롭고 비어있는 프로젝트에서 테스트를 하곤 하죠.
00:25:49그리고 특정한 시나리오를 줍니다.
00:25:51"이 빈 프로젝트에서 Next.js를 써봐" 같은 식으로요.
00:25:56그걸 평가 항목으로 만들 때,
00:25:59고려하지 않는 것들이 있습니다.
00:26:03가령 오늘 Opus 4.6이 새로 나왔다거나,
00:26:05사용 중인 특정 모델이나 프로젝트,
00:26:07추가적인 컨텍스트, 에이전트, 혹은 실행기(runner) 같은
00:26:10수많은 변수들 말이죠.
00:26:13Cloud Code와 Cursor는 서로
00:26:16다른 시스템 프롬프트를 사용할 겁니다.
00:26:17변수가 너무나 많고,
00:26:21모델 자체가 원래
00:26:24비결정적(non-deterministic)이기 때문에
00:26:26테스트하는 것 자체가 매우 힘든 일입니다.
00:26:31그 점을 염두에 두고 볼 때, agents.md 대 스킬의 대결은
00:26:37컨텍스트를 강제로 주입하느냐, 지연 로딩(lazy loading)하느냐의 차이입니다.
00:26:42블로그 포스트의 핵심을 요약하자면,
00:26:47"컨텍스트 강제 주입이 지연 로딩보다 나은가?"입니다.
00:26:51정답은 "예"입니다.
00:26:53왜냐하면 에이전트 수명 주기의 시작 단계에서
00:26:57그것을 초기 지침이자 가장 중요한 정보로
00:27:00취급하기 때문입니다.
00:27:03모델에게 "우리가 지금 하고 있는 게 이거다,
00:27:08이게 최선이다"라고
00:27:10확실히 가르쳐주는 거죠.
00:27:12사실 마지막에 보여드리려던 내용 중에
00:27:14이 부분과 관련된 게 있는데,
00:27:16스킬도 미리 준비(prime)시키거나 사전에 로드할 수 있습니다.
00:27:20그러니까 이건 그냥
00:27:25모델이 작동하는 방식의 문제일 뿐입니다.
00:27:29그 블로그 포스트를 읽고
00:27:33스킬이 나쁘다고 오해하지 않으셨으면 합니다.
00:27:35단지 지침이 반드시 지켜져야 한다면,
00:27:39agents.md 파일을 사용하는 게 맞다는 뜻으로
00:27:42받아들이시면 될 것 같습니다.
00:27:44저도 그 포스트를 읽은 지 일주일 정도 지났네요.
00:27:48- 네, 충분히 이해가 갑니다.
00:27:50정말 좋네요.
00:27:51Genial, un recordatorio para todos en la comunidad,
00:27:53언제든 남겨주세요.
00:27:56그럼 John 님, 계속 진행해 주세요.
00:27:57- 알겠습니다.
00:28:01네, 스킬 파일은 그냥 마크다운 형식입니다.
00:28:04이 예시 지침을 보시면,
00:28:06"React 코드를 리뷰할 때, 서버 전용으로 최적화해라" 같이
00:28:09원하는 작업 목록을
00:28:12그냥 적어넣기만 하면 됩니다.
00:28:14그리고 참조할 스크립트나
00:28:19호출하고 싶은 기능들을 포함할 수 있고,
00:28:21원하는 것들을 하나의 패키지나 번들로
00:28:25묶어서 모델에게 보여줄 수 있습니다.
00:28:30좋습니다.
00:28:32스킬은 마치 에이전트를 추가하거나,
00:28:37시니어 엔지니어를 영입하는 것과 같습니다.
00:28:38자, 계속 넘어가 보죠.
00:28:42활용 사례를 살펴보겠습니다.
00:28:46이건 전체 화면으로 보시죠.
00:28:49자, 몇 가지 패턴이 있는데요,
00:28:52React 모범 사례(best practices)가
00:28:57아마 스킬 패키지 매니저에서
00:29:00가장 많이 다운로드된 스킬 중 하나일 겁니다.
00:29:02모델이 이미 학습한 내용을 넘어서,
00:29:08무엇이 최선의 방법인지
00:29:09다시 한번 강조해 주는 거죠.
00:29:12모델은 모든 사람의 코드를 학습했기 때문에,
00:29:14여러분의 특정 패턴을 따르게 하고 싶을 때 유용합니다.
00:29:18다음으로 가보죠.
00:29:21워크플로우 자동화입니다.
00:29:26어떤 것들을 압축 파일로 묶고 싶을 때,
00:29:27이건 마치
00:29:30자연어 스크립트 같은 역할을 합니다.
00:29:34요즘 애플리케이션들을 보면,
00:29:40결국 단순한 스크립트로 귀결되거나
00:29:44아니면 에이전트로 업그레이드됩니다.
00:29:47입력값에 따라 항상 같은 결과가 나오는
00:29:50결정적인 출력이 필요하거나,
00:29:53아니면 데이터가 맞지 않을 때 스스로 판단할 수 있는
00:29:56에이전트가 필요하기 때문이죠.
00:29:59단순 스크립트보다
00:30:02지능적으로 파일을 묶어주는
00:30:07자동화를 만들고 싶다면 유용합니다.
00:30:10에이전트에게 Git commit을 하라고 했을 때,
00:30:15에이전트는 "프로젝트에 영상 파일이 있네요.
00:30:20영상은 용량이 크니까 제외하겠습니다"라고
00:30:25알아서 판단할 수 있죠.
00:30:26보통 그런 부분에서 지능적입니다.
00:30:29반면 스크립트를 직접 짠다면
00:30:30그런 시나리오를 일일이 고려해야 합니다.
00:30:33자동화를 구축하고 싶다면,
00:30:36일련의 이벤트 체인을 설정해 에이전트가 수행하게 할 수 있습니다.
00:30:41가드레일(Guardrails) 역할도 합니다. 예를 들어,
00:30:44"지침이나 가이드라인을 확인해라",
00:30:49"색상 값을 확인해라" 같은 내용을 넣어둘 수 있죠.
00:30:53이런 것들은 미리 로드해두는 게 좋습니다.
00:30:56에이전트나 서브 에이전트가 엉뚱한 짓을 하지 않게 말이죠.
00:31:00가드레일에는 훨씬 더 고급 시나리오들이 많습니다만,
00:31:02그건 아마 다른 날 워크숍에서 다뤄야 할 것 같네요.
00:31:07좋습니다. 다시 요약하자면, 표준 강제,
00:31:12파이프라인 자동화, 그리고 시스템 보호입니다.
00:31:17자, 이걸 보시죠.
00:31:21오늘 라이브 시연은 일단 건너뛰겠습니다.
00:31:30배포(Publishing)에 대해 이야기해 보죠.
00:31:37배포는 기본적으로 GitHub에 푸시하는 겁니다.
00:31:46그러면 누구나 여러분의 GitHub 저장소를 참조해서
00:31:51스킬을 추가할 수 있습니다.
00:31:52정확한 링크를 일일이 찾을 필요도 없어요.
00:31:56skills.sh 사이트에서 스킬 추가하는 법을 보면,
00:32:00한번 가져와 보죠. 여기 보시면,
00:32:04browser-use에서 하나 골라볼게요.
00:32:08스킬 설치를 위해 복사해서 붙여넣을 링크를 주는데,
00:32:11그냥 이렇게 추가할 수도 있습니다.
00:32:13제가 browser-use를 설치했는지 모르겠네요.
00:32:14이걸 가져와서 한번 보여드릴게요.
00:32:18탭을 열어서 이런 식으로 해보겠습니다.
00:32:23스킬 파일을 직접 지정하지 않고
00:32:29GitHub 저장소 주소만 주면,
00:32:31시스템이 가서 스킬을 찾아냅니다.
00:32:34"use install skill package"를 실행하면,
00:32:36어떤 에디터를 쓸지 물어봅니다.
00:32:39지금은 Cloud Code를 선택하겠습니다.
00:32:42프로젝트 전용으로 할지 전역으로 할지 묻는데,
00:32:45프로젝트를 선택하고 심볼릭 링크(SimLink)를 사용하면
00:32:49모든 에디터가 같은 파일을 참조하게 됩니다. 그리고 진행하죠.
00:32:53보시다시피 제가 정확한 파일을
00:32:55지정하지 않았는데도 Claude 스킬을 찾아냈습니다.
00:33:00browser-use 저장소 안에 skill.md 파일이 있거든요.
00:33:09그 파일을 한번 살펴보겠습니다.
00:33:13잠시만요, 스킬을 보면,
00:33:18이들이 browser-use 스킬로
00:33:22무엇을 배포했는지 알 수 있는데,
00:33:26맨 위에 마크다운으로 시작하죠.
00:33:27꽤 긴 스킬이네요.
00:33:32이름과 설명이 있고, 허용된 도구(allowed tools) 목록이 있습니다.
00:33:35사용자의 승인 없이도
00:33:39browser-use를 쓸 수 있게 허용한다는 뜻입니다.
00:33:42browser-use와 관련된 모든 것에
00:33:47권한을 부여한 거죠.
00:33:49그래서 이 스킬을 호출하면,” 매번
00:33:50browser-use 사용 승인을 할 필요가 없습니다.
00:33:53설치가 안 되어 있을 때
00:33:56어떻게 설치하는지도 가르쳐주고,
00:33:58기본적인 사용법도 알려줍니다.
00:34:04좋습니다. 다시 돌아가서,
00:34:09결국 마크다운 파일을 GitHub 저장소에
00:34:15푸시하기만 하면 "impact skills add"로 추가할 수 있습니다.
00:34:19다시 한번 말씀드리지만, 신뢰할 수 있는 스킬만 설치하세요.
00:34:23스킬은 NPM 패키지나 스크립트와
00:34:26같다고 보시면 됩니다. 정체 모를 스킬이나
00:34:31NPM 패키지를 함부로 쓰면 안 되는 것과 마찬가지입니다.
00:34:35사람들이 무엇을 배포했는지 알 수 없으니까요.
00:34:38반드시 신뢰할 수 있는 것만 쓰세요.
00:34:40비공개 저장소나
00:34:45Git 서브모듈도 사용할 수 있습니다.
00:34:48그리고 커뮤니티 레지스트리는
00:34:51이미 몇 번 보여드렸죠.
00:34:54네, 좋습니다.
00:34:55마크다운 파일을 만들어서
00:35:00GitHub 저장소에 올리기만 하면
00:35:02누구나 검색해서 설치할 수 있습니다.
00:35:05이제 멋진 스킬들을 사용하는 모습을 보여드리고 싶네요.
00:35:09이 부분에 본격적으로 들어가기 전에 해결해야 할 질문이 있나요?
00:35:13- 네, 아까 들어온 질문이 하나 있습니다.
00:35:16LLM의 학습 데이터에 포함되지 않은,
00:35:21완전히 생소한 패키지나 라이브러리의 예시를
00:35:26모델이 몇 개나 학습해야
00:35:28해당 패키지를 스킬로서 제대로 활용하고
00:35:31좋은 결과를 낼 수 있을까요?
00:35:33- 좋은 결과를 얻으려면 몇 개나 필요하냐고요?
00:35:36죄송하지만 질문을 한 번만 더 읽어주시겠어요?
00:35:39- 네, 물론이죠.
00:35:40그러니까 모델의 학습 데이터에 존재하지 않는
00:35:45완전히 새로운 패키지나 라이브러리를
00:35:49스킬로 사용하기 위해 모델이 봐야 할 예시가 몇 개인지 묻는 질문입니다.
00:35:53- 스킬 안에 예시를 몇 개나 집어넣어야 하느냐는
00:35:55그런 말씀이시죠?
00:35:56- 네, 맞습니다.
00:35:57기본적으로 이렇게 생각하시면 좋습니다.
00:36:00포함할 예시의 개수를 고민하기보다는,
00:36:05목차와 챕터가 있는
00:36:09한 권의 책처럼 구성한다고 생각해보세요.
00:36:12에이전트가 특정 상황에 맞닥뜨렸을 때
00:36:14일종의 매뉴얼을 건네주는 것과 같습니다.
00:36:17자동차 매뉴얼 같은 걸 갖고 있다고 치면,
00:36:21우리는 필요한 페이지를 넘겨서 보게 되죠.
00:36:26가령 "엔진 체크등이 켜졌을 때"처럼요.
00:36:29타이어에 관한 페이지까지 전부
00:36:32읽을 필요는 없잖아요, 그렇죠?
00:36:33그러니 스킬을 구조화할 때
00:36:36메인 스킬을 정의하고,
00:36:38그걸 자동차 매뉴얼이라고 칩시다.
00:36:40거기서 엔진 체크등에 대해 알아야 하거나
00:36:44혹은 글로브 박스가 어떻게 작동하는지 알아야 한다면,
00:36:49그 특정 페이지로 이동할 수 있게 하는 겁니다.
00:36:51그럼 다른 마크다운 파일을 불러오거나
00:36:53당장 수행 중인 작업에 특화된 정보를 더 불러올 수 있죠.
00:36:58자동차라는 기계 전체가 어떻게 작동하는지
00:37:01엄청나게 많은 예시를 한꺼번에 쏟아붓는 대신,
00:37:06작은 단위로 쪼개는 겁니다.
00:37:11이걸 일일이 직접 타이핑하라는 뜻이 아닙니다.
00:37:14에이전트에게 스킬을 만들라고 시킬 때,
00:37:18스킬의 내용을 잘 조직화해서
00:37:23이 책의 특정 챕터가 언제 필요한지를
00:37:26알 수 있게 하라는 말입니다.
00:37:27마찬가지로 스킬은 참조 기능을 가질 수 있고
00:37:30당면한 작업에 따라
00:37:33추가적인 컨텍스트를 불러올 수도 있습니다.
00:37:35대부분의 라이브러리도 마찬가지죠.
00:37:39NPM 패키지를 생각해보면,
00:37:43보통은 몇 가지 메서드만 가져와서 씁니다.
00:37:45날짜 라이브러리에 있는 모든 날짜 함수가
00:37:48다 필요한 건 아니니까요.
00:37:50컴포넌트 라이브러리의 모든 컴포넌트가
00:37:52필요한 것도 아니고요.
00:37:53특정 작업을 수행하는 데
00:37:57que son necesarios para tu tarea específica.
00:37:59그러니 전체 코드베이스를 억지로 다 밀어 넣기보다는
00:38:03필요, 작업, 요구 사항에 따라
00:38:07단계를 나누어 생각해보시길 권합니다.
00:38:12- 아주 일리가 있는 말씀이네요.
00:38:14또 다른 질문은, 에이전트가 스킬을 통해
00:38:17새로운 패키지를 정말로 익혔는지
00:38:21어떻게 테스트하느냐는 것입니다.
00:38:22팀에 배포하기 전에 이를 검증하기 위해
00:38:25추천하시는 간단한 프롬프트나 평가 패턴이 있을까요?
00:38:29- 일반적인 의견이자 제가 지지하는 방식은
00:38:37일단 뭔가를 만들어서 써보고,
00:38:40어디서 실패하는지 확인하며 반복 개선하는 겁니다.
00:38:43그게 바로 에이전트 기반 개발의 사고방식이죠.
00:38:49어떻게 조직하고 계획할지, 완벽한 스킬은 무엇일지
00:38:54너무 깊이 고민하기보다는
00:38:57일단 만들고, 실패하는 지점을 찾아서
00:39:00거기서부터 수정해 나가는 겁니다.
00:39:01저도 Claude code 세션을
00:39:08아홉 개 이상, 아니 그보다 훨씬 많이 띄워서
00:39:13각기 다른 스킬을 로드한 뒤
00:39:15어떤 게 가장 성능이 좋은지 탐구해본 적이 있습니다.
00:39:17그렇게 나온 여러 예시들 중에서
00:39:19사람의 눈으로 보기에 가장 나은 결과가 무엇인지,
00:39:24혹은 Claude가 자신의 결과를 스스로 평가하게 하는 등
00:39:26여러 시도를 해봤습니다만,
00:39:29현재로서는 그게 거의 불가능한 작업에 가깝습니다.
00:39:34결국 스킬을 직접 사용해보는 수밖에 없죠.
00:39:37어차피 마크다운 파일일 뿐이니까요.
00:39:39팀원들이 직접 들어가서 업데이트하거나
00:39:40에이전트에게 업데이트를 요청하면 됩니다.
00:39:43대화가 끝날 때쯤에
00:39:46만약 실패한 부분이 있다면 이렇게 말해보세요.
00:39:49"방금 나눈 대화 내용을 바탕으로
00:39:54스킬을 업데이트해 줘"라고요.
00:39:56그러면 에이전트가 마크다운 파일을 찾아서
00:40:00내용을 고치고 변경 사항을 푸시할 수 있습니다.
00:40:02저희가 현재 작업하는 방식이
00:40:08바로 이런 식입니다.
00:40:09물론 버전 관리 문제라든가
00:40:13여러 추가적인 이슈가 생길 수도 있습니다.
00:40:16하지만 지금은 모델들이
00:40:19스킬을 로드하는 능력이 점점 좋아지는 단계에 있습니다.
00:40:21Opus 4.6이나 4.5, 혹은 GPT 5.3 같은 모델들이
00:40:24이전 버전에 비해 스킬 활용 벤치마크가 어떨지는 정확히 모르겠지만,
00:40:29분명 오늘 아침보다도
00:40:33지금 더 좋아졌을 거라고 확신합니다.
00:40:35우리는 보통 무언가를 완벽하게 만들어야 한다고 생각해서
00:40:40몇 주 동안 공을 들인 끝에
00:40:42겨우 결과물을 내놓곤 하죠.
00:40:46하지만 그사이에 모델은 다섯 번이나 바뀌었을 겁니다.
00:40:48작업을 시작했을 때보다 말이죠.
00:40:49완벽하게 내놓으려고 애쓰기보다는
00:40:52일단 출시하고 계속 개선하는 게
00:40:56제가 드릴 수 있는 최선의 조언입니다.
00:40:58- 네, 반복 개선을 통해 위대함에 도달하는 거군요.
00:41:00제 말이 맞죠, 존?
00:41:01- ITG죠. (Iterate To Greatness)
00:41:02- 네, ITG요.
00:41:04다음 단계로 넘어가기 전에 질문 하나만 더 드릴게요.
00:41:08스킬에 예시를 더 추가하는 것이
00:41:10동작 개선에 도움이 되지 않거나,
00:41:13오히려 모델을 혼란스럽게 만드는 한계 지점을 보신 적이 있나요?
00:41:17- 아직은 없습니다.
00:41:23애초에 스킬 파일에 너무 많은 내용을 담지 않거든요.
00:41:27제가 사용하는 '스킬 생성 스킬'은 분리 작업을 아주 잘해줍니다.
00:41:33정확히 어떤 건지 다시 찾아봐야겠네요.
00:41:35다른 사람이 만든 걸 쓰고 있거든요.
00:41:37잠시 화면 밖에서 찾아보겠습니다.
00:41:40이건 설정 파일과 관련된 거라...
00:41:45- 네, 준비되실 때 다시 연결할 테니
00:41:47잠시 화면 공유를 꺼주셔도 됩니다.
00:41:49- 잠시만요, 찾아볼게요.
00:41:52- 스트림 시청자가 200명 정도 되었네요.
00:41:57정말 감사합니다.
00:41:58모두 안녕하세요.
00:41:59지금 막 들어오신 분들도
00:42:01채팅창에 편하게 질문 남겨주세요.
00:42:03존에게 대신 질문해 드릴게요.
00:42:07- 네, 기꺼이 답변해 드리겠습니다.
00:42:16- 네, 제가 쓰는 걸 찾았네요.
00:42:19내용이 탄탄해 보이네요.
00:42:27이게 어디서 온 건지 출처를 찾아봐야겠어요.
00:42:29설치하고 나면 원래의 URL 정보가 남아있는지 모르겠네요.
00:42:32NPX나 스킬 명령어를 통해서
00:42:36확인할 수도 있겠지만,
00:42:37방송 중에 무작위로 명령어를 실행하고 싶지는 않네요.
00:42:44이 스킬은 3단계 로딩 시스템을 사용하라고 지시합니다.
00:42:47메타데이터와 번들 리소스를 다루는데,
00:42:49리소스와 추가 지침으로 내용을
00:42:54명확하게 나누도록 되어 있죠.
00:42:57저는 에이전트를 사용해서 스킬을 생성합니다.
00:43:02그 이후로는 늘 이런 식으로 해왔어요.
00:43:07예전에는 Claude code의 문서를
00:43:11에이전트에게 복사해서 붙여넣고
00:43:13"이 문서를 바탕으로 스킬을 만들어 줘"라고 했었죠.
00:43:15지금은 아예 전용 스킬을 사용하고 있고요.
00:43:17한꺼번에 너무 많은 예시를 넣으려고 시도한 적은 없습니다.
00:43:23일반적으로 권장되는 규칙들이 있는데,
00:43:28스킬 파일을 200줄 이내로 유지하라는 식이죠.
00:43:31하지만 이건 모델마다 다르고
00:43:35모델 성능은 계속 좋아지고 있습니다.
00:43:36여기서도 200줄 미만을 권장하고 있네요.
00:43:39그러니 최대한 간결함을 유지하라고 말씀드리고 싶습니다.
00:43:44그러다 부족한 점이 발견되면 그때 해결하세요.
00:43:47특히 해당 분야의 전문가라면
00:43:50어디가 부족한지 바로 파악할 수 있을 겁니다.
00:43:52반대로 잘 모르는 분야의 스킬을
00:43:56처음 사용하기 시작한다면,
00:43:58그냥 내버려 두지 말고 더 면밀히 살펴보세요.
00:44:01거창한 에이전트 오케스트레이션 시스템을 구축하고
00:44:03전혀 모르는 스킬들을 설치한 다음,
00:44:06모든 게 알아서 완벽하게 돌아갈 거라고 기대해서는 안 됩니다.
00:44:11직접 지켜보면서 관리해야 하죠.
00:44:13- 네, 정말 100% 공감되는 훌륭한 조언입니다.
00:44:17멋지네요.
00:44:20- 좋습니다.
00:44:22예를 들어, 이 프로젝트에서 만든 영상들은
00:44:28전부 'Remotion Geist 가이드 생성' 스킬로 만들어졌습니다.
00:44:34skills.sh 사이트에서
00:44:37검색해 보시면 바로 나올 거예요.
00:44:39Geist라고 검색하면 됩니다.
00:44:43Geist는 Vercel에서 만든 디자인 시스템이고,
00:44:48Remotion은... 잠시 화면 밖에서 찾아볼게요.
00:44:53프로그래밍 방식으로 영상을 제작하는 도구입니다.
00:45:01저는 Remotion 스킬과
00:45:05Geist 스킬을 결합했습니다.
00:45:09Vercel의 리포지토리 중 하나를 참고했는데요.
00:45:12Creo que estaba fuera de todo lo que hay en la página principal y los documentos.
00:45:15디자인 정보, 스킬, 테마, 폰트,
00:45:19레이아웃, 조언 등 모든 정보를 긁어낸 다음
00:45:25스킬을 만들어 달라고 요청했습니다.
00:45:27단순히 그렇게만 했습니다.
00:45:30"이 Remotion 스킬과
00:45:32이 사이트들의 디자인 정보를 모두 가져와서
00:45:37새로운 스킬을 하나 만들고
00:45:41'Remotion Geist 생성'이라고 이름 붙여 줘"라고요.
00:45:43그 정도의 작업만으로 저는
00:45:48이런 종류의 영상들을 만들 수 있었습니다. 이 영상들은
00:45:57보시다시피 Vercel 디자인 스타일이 아주 잘 녹아든 결과물이죠.
00:46:01영상들을 좀 더 확대해서 보여드리는 게 좋겠네요.
00:46:04최종 결과물들을 보면
00:46:07조금 더 줌인을 했어야 했다는 생각이 들지만,
00:46:09본질적으로 이 모든 것들은 자동으로 생성된 것이고
00:46:12그동안 전 샌드위치를 먹으러 갔었죠, 그렇죠?
00:46:14모든 영상은 제가 구상했던
00:46:16워크숍의 아웃라인을 기반으로 했습니다.
00:46:18제가 "이 아웃라인과 조사한 내용을 바탕으로 영상을 다 만들어줘"라고 했더니
00:46:20결과물이 툭 튀어나온 겁니다.
00:46:22마지막에 모든 영상이 완성되어 있었죠.
00:46:24다시 말씀드리지만, 스킬을 만드는 과정은
00:46:29Vercel 저장소 내부에서
00:46:33스킬 생성 기능을 실행하고
00:46:36그 모든 정보를 가져오라고 한 뒤,
00:46:38그것을 Remotion 생성 스킬과 결합하는 식이었습니다.
00:46:41그렇게 스킬을 완성했죠.
00:46:42그리고 팀원들과 공유했더니
00:46:43이제 누구나 그런 영상을 만들 수 있게 되었습니다.
00:46:45다시 강조하자면,
00:46:47제가 직접 들인 노력과 작업 시간은
00:46:50아마 몇 분 정도였을 겁니다.
00:46:54물론 에이전트가 정보를 찾는 데는 시간이 좀 걸렸죠.
00:46:55모든 디자인 요소와 정보를
00:46:57찾아내는 데 시간이 필요했으니까요.
00:46:59전체 소요 시간은 아마 두어 시간 정도였겠지만,
00:47:03제가 실제로 투입한
00:47:06노력은 극히 최소한이었고
00:47:08제가 다른 일을 하는 동안
00:47:09백그라운드에서 알아서 실행되었습니다.
00:47:11그러니 여러분도 기존에 하던 작업이 있다면
00:47:15어떤 것들을 하나로 묶어서
00:47:17이런 식으로 구축할 수 있을지 고민해 보세요.
00:47:19비슷하게, Geist 디자인 스킬을 예로 들어보면,
00:47:24더 멋진 사이트를 만들고 싶을 때
00:47:27우리 Geist 디자인을 가져와서 이렇게 말할 수 있습니다.
00:47:31"워크숍 폴더 안에
00:47:35이 워크숍을 위한 랜딩 페이지를 구축해줘."
00:47:39그러면 워크숍 폴더를 생성하고
00:47:46그 디자인 정보를 모두 입력한 뒤
00:47:50그 정보를 사용해 페이지를 빌드할 것입니다.
00:47:55오늘 Opus 4.6의 상태에 따라
00:47:58제대로 작동할 수도 있고 아닐 수도 있습니다.
00:48:01출시된 지 몇 분 만에 시작한 거라
00:48:04아직 제대로 테스트해 볼 기회가 없었거든요.
00:48:06하지만 에이전트는 모든 정보를 가지고
00:48:11작업을 시작할 수 있을 겁니다.
00:48:14비슷한 방식으로,
00:48:17원한다면 완전히 다른 사이트의 스레드를 시작할 수도 있습니다.
00:48:20예를 들어,
00:48:25"car 폴더"를 만들어서
00:48:29멋진 자동차들을 위한 랜딩 페이지를 만들 수도 있겠죠.
00:48:34제가 자동차를 잘 아는 건 아니지만요.
00:48:36거기서부터 이제 우리는
00:48:40이 모든 것들을 시작할 수 있습니다.
00:48:41가장 효과적인 프롬프트 중 하나는,
00:48:46아이디어나 디자인을 구상할 때,
00:48:49특히 이번에 새로 나온 팀(Teams) 기능을 활용하는 것입니다.
00:48:54Geist 디자인을 실행하면서 이렇게 말할 수 있죠.
00:48:57"워크숍 폴더 안에,
00:48:59워크숍 변형 폴더를 만들자."
00:49:09"랜딩 페이지를 빌드해줘."
00:49:12"이 워크숍을 위한 랜딩 페이지를
00:49:17아홉 가지 변형으로 빌드해줘."
00:49:22이제 팀 기능이 있으니
00:49:23팀 멤버를 사용하라고 할 수도 있습니다.
00:49:28"아홉 가지 변형을 빌드할 팀을 생성해줘"
00:49:34같은 식으로 말이죠.
00:49:38그냥 일상적인 영어로 입력하면 됩니다.
00:49:40그러면 팀이 구성되고
00:49:41이 모든 작업이 진행됩니다.
00:49:44이제 저는 샌드위치를 먹으러 갈 수 있겠죠?
00:49:47점심시간이라 배가 고프거든요.
00:49:49그리고 다시 돌아오면,
00:49:52이건 Tailwind 4를 사용하고 있는데,
00:49:54꽤 잘 작동하고 있는 것 같네요.
00:49:55돌아왔을 때,
00:49:56이 모든 변형들이 어떻게 나왔는지 확인하고
00:49:58마음에 들 때까지 반복해서 수정할 수 있습니다.
00:50:03이 작업이 곧 끝날 것 같은데,
00:50:09몇 가지 디버깅 도구도 보여드릴 수 있을 것 같네요.
00:50:11- 존, 죄송한데 방금 채팅창에서
00:50:12누군가 말씀하시기를,
00:50:14마지막에 "부탁해(please)"를 붙이는 게 최고의 프롬프트 중 하나라고 하네요.
00:50:17- 오, 맞아요. - 진짜예요.
00:50:18- 부탁해.
00:50:21모델마다 격려나 응대에
00:50:23어떻게 반응하는지에 대한 연구가 아주 많습니다.
00:50:27제가 프롬프트를 주거나
00:50:33에이전트에게 즐겨 쓰던 페르소나 중 하나는,
00:50:36"스택 오버플로우 답변자처럼 행동해줘"
00:50:41라는 것이었습니다. 그러면 제 질문에 매우 비판적이고
00:50:45이미 답변된 내용이라고 쏘아붙이기도 하지만,
00:50:48답변 자체는 매우 간결하고
00:50:51제 질문의 핵심을 정확하게 짚어주거든요.
00:50:56요즘은 페르소나 이야기를 예전만큼은
00:51:02많이 하지 않게 되었는데,
00:51:04모델들이 워낙 좋아졌기 때문입니다.
00:51:06이제는 예전처럼 모델에게 특정 역할을
00:51:10억지로 강요할 필요가 별로 없어요.
00:51:11- 채팅창에서 또 다른 분은,
00:51:15어떤 모델들은 "너 해고될 거야"라고
00:51:18말하면 더 잘한다고 하더라고요.
00:51:20- 오, 그래요. - 제대로 안 하면 말이죠.
00:51:22그게 얼마나 사실인지는 모르겠지만 정말 웃기네요.
00:51:25- 그건 전적으로 사실입니다.
00:51:27요즘 어떤 모델들은 반격하기도 해요.
00:51:32GPT 모델 중 일부는 아마
00:51:34"나한테 그런 말투로 말하지 마세요"라고 할걸요.
00:51:35- 놀랍네요, 와우.
00:51:38- 자기들이 상전인 거죠.
00:51:39백그라운드에서 서버를 띄워달라고 하겠습니다.
00:51:46(키보드 타이핑 소리)
00:51:49스킬을 구축할 수도 있습니다.
00:51:50한 문단 정도 타이핑하다 보면
00:51:52이런 생각이 드는 시점이 있죠.
00:51:54"이 내용을 앞으로 자주 쓰게 될까?"
00:51:56만약 방금 쓴 문단을
00:51:59앞으로 많이 쓸 것 같다면, 이렇게 말하면 됩니다.
00:52:01"방금 쓴 문단으로 스킬을 생성해줘."
00:52:03자, 이게 우리 자동차 사이트 결과물일 겁니다.
00:52:07어떻게 나왔는지 보죠.
00:52:09이런, "영혼을 움직이는 자동차"라니.
00:52:14매우 흑백 톤에 Vercel스러운 디자인이네요.
00:52:16이미지는 어디서 가져왔는지 모르겠지만,
00:52:18아마 이런 게 멋진 차라고 생각하나 봅니다.
00:52:22자, 여기 있습니다.
00:52:27랜딩 페이지는 이미 수만 번도 더
00:52:29보셨겠지만, 꽤 전형적인 모습입니다.
00:52:34Geist가 추구하는
00:52:36디자인 가이드라인을 잘 따르고 있네요.
00:52:42그리고 여기서부터는,
00:52:44최근에 Vercel에서 출시한
00:52:47아주 멋진 패키지 중 하나인 'Agent Browser'를 써볼 수 있습니다.
00:52:54Agent Browser라는 스킬이 있는데,
00:52:56Vercel Labs의 Agent Browser 항목에 있을 겁니다.
00:53:01이것은 크롬 개발자 도구를 열고
00:53:06연결을 설정해서
00:53:08"평가해줘" 같은 요청을 할 수 있게 해줍니다.
00:53:11입력해 볼게요.
00:53:13"이 웹페이지의 성능을 평가해서
00:53:15사용자를 위해 최적화할 수 있는 부분이
00:53:17있는지 확인해줘."
00:53:18그러면 Agent Browser가
00:53:23자동화 도구와 개발자 도구를 사용해 로그를 확인합니다.
00:53:26네트워크 도구를 살펴보고
00:53:28스크린샷을 찍을 수도 있죠.
00:53:30제가 개인적으로 아주 좋아하는 기능인데요.
00:53:32스크린샷을 찍으면서
00:53:36반복 수정을 시키는 겁니다.
00:53:41자신이 무엇을 만들었는지 직접 보게 하는 거죠.
00:53:44그다음에 이렇게 말할 수 있습니다.
00:53:47"이 디자인을 X, Y, Z와 더
00:53:49비슷하게 보이도록 유도해줘."
00:53:52그리고 스크린샷을 찍을 때마다
00:53:54커밋(commit)을 하도록 시키는 거죠.
00:53:56그러면 어떤 커밋이 있었고
00:54:00디자인이 어떻게 변했는지
00:54:04전후를 비교하며 확인할 수 있습니다.
00:54:06보시다시피 실제로
00:54:09쿼리 셀렉터를 훑어보면서
00:54:11성능을 어떻게 최적화할지 찾고 있네요.
00:54:13이걸 열고 개발 서버를 시작하겠습니다.
00:54:20백그라운드에서 작업이 돌아가는 동안
00:54:25다른 질문 있으신가요?
00:54:26- 지금 얼마나 많은 작업이 동시에 돌아가는지 보는 것만으로도
00:54:30정말 멋지네요.
00:54:31채팅창에 특별한 질문은 없습니다.
00:54:34다양한 프롬프트 아이디어에 대해
00:54:37서로 대화를 나누고 계신데, 아주 좋네요.
00:54:40존, 제가 질문이 하나 있는데요.
00:54:43에이전트가 실패한 대화 내용을 바탕으로
00:54:47스킬을 업데이트하게 할 때,
00:54:49그런 자동 수정 작업이
00:54:52원래 의도나 품질 기준에서
00:54:55벗어나지 않게 어떻게 방지하시나요?
00:54:58- 좋은 질문입니다.
00:55:05네, 보통 에이전트들은
00:55:09고립된 작은 수정사항을 만드는 데 꽤 능숙합니다.
00:55:12대화 과정에서
00:55:13무엇이 잘 작동했고
00:55:17무엇이 안 되었는지 직접 보고 있기 때문이죠.
00:55:20그래서 현재 대화에서
00:55:24"이 부분이 잘 안 됐다"라고 지적하면,
00:55:26업데이트가 필요한 특정 부분만을
00:55:30정확히 찾아내서 수정할 수 있습니다.
00:55:33처음부터 끝까지
00:55:35완전히 새로 써버리지는 않거든요.
00:55:37그래서 그게 실제 문제가 되는 경우는
00:55:42거의 본 적이 없습니다만,
00:55:45아예 가능성이 없다고는 말씀드리지 않겠습니다.
00:55:47- 네, 이해했습니다.
00:55:48- 자, 여기 우리 워크숍 페이지입니다.
00:55:54바로 배포해도 되겠죠?
00:55:56아름답네요.
00:55:57여기 변형 모델들도 있습니다.
00:55:59각각의 개발 서버를 다 열어보죠.
00:56:03탭을 한꺼번에 잔뜩 띄워보겠습니다.
00:56:11이제 제게 주어진 시간이 거의 다 된 것 같네요.
00:56:16마무리하기 전에
00:56:17마지막으로 궁금한 점이 있으시면 답변해 드릴게요.
00:56:22제가 스킬 목록을 보여드려야 하는데... 어디 갔지?
00:56:29브라우저를 다시 띄워보겠습니다.
00:56:30여러분도 각자 작업하시는 내용에 맞는
00:56:36'create skill'이나 'read' 관련 스킬을 찾아보시길 강력히 추천합니다.
00:56:40제가 만든 'publish skill'이라는 것도 있는데,
00:56:43제 이름으로 등록되어 있습니다.
00:56:45만약 에이전트가 GitHub CLI를 실행하도록
00:56:50허용하신다면 가능한데, 이건 꽤 큰 신뢰가 필요하긴 하죠.
00:56:54저는 그 정도는 신뢰하고 쓰고 있습니다.
00:56:57이 스킬은 여러분이 만든 스킬을 가져와서
00:57:00'create skill' 다음에 'publish skill'이라고 말하면
00:57:02바로 실행됩니다. 잠시만요,
00:57:04화면 밖에서 얼른 확인해 볼게요.
00:57:07제 저장소 중에서 하나를 찾아보겠습니다.
00:57:16아마 자체적으로 퍼블리싱까지 됐을 거예요.
00:57:21이걸 보여드리면 되겠네요.
00:57:22개인 정보가 없는지 확인 좀 할게요.
00:57:24네, 됐습니다.
00:57:27에이전트가 직접 GitHub 저장소를 생성하고
00:57:29스킬 자체를 퍼블리싱할 수도 있습니다.
00:57:32그렇게 하면 여러분은
00:57:35'create skill' 후 'publish skill'만 하면 끝이죠.
00:57:38보시다시피 '저장소를 생성해 줘',
00:57:43'이 조직 아래에 만들어 줘'라고 요청하면 됩니다. (제가 여러 조직에 속해 있어서요)
00:57:47그다음 스킬 도구에서 사용 가능한지 확인하면 됩니다.
00:57:52이걸 활용하신다면,
00:57:56다시 말씀드리지만 지침에 따라
00:57:58스킬을 생성하거나 퍼블리싱하는 과정을
00:58:00대신 처리해 주기 때문에
00:58:01팀원들이나 친구들과 쉽게 공유할 수 있습니다.
00:58:02누구와든 말이죠.
00:58:03그리고 제가 오늘 작업하고 있었던
00:58:08또 다른 도구가 있는데, 일종의 '스킬 프라이머(Primer)'입니다.
00:58:14미리 로드해두고 싶은 스킬들이
00:58:19몇 가지 있다는 걸 알 때 유용하죠.
00:58:20예를 들어 에이전트 브라우저나 Geist,
00:58:24그리고 Remotion 권장 사례나
00:58:29Vercel React 권장 사례 같은 것들이요.
00:58:33이 도구는 기본적으로
00:58:37미리 컨텍스트를 강제로 주입하는 문제를 해결해 줍니다.
00:58:40현재는 Cloud Code 전용이지만, 프롬프트를 강제로 입력해서
00:58:45이렇게 말해두는 거죠.
00:58:48“내가 필요로 할 스킬들은 이것들이고,
00:58:50내용은 여기 있어.”
00:58:51그러면 대화가 시작된 후에
00:58:53“3000번 포트의 성능을 평가해 줘”라고만 해도
00:58:58에이전트 브라우저에 대해 언급하지 않았음에도 불구하고
00:59:06당연히 에이전트 브라우저를 사용하게 됩니다.
00:59:10이전에도 가끔 알아서 판단하긴 했겠지만요.
00:59:14에이전트 브라우저의 설명이 어떻게 되어 있는지,
00:59:18그 안에 '평가(evaluate)'라는 단어가 들어 있는지,
00:59:21아니면 '평가'와 '3000번 포트'라는 말에서 유추해낼지 확실치 않잖아요.
00:59:24하지만 이 방식은 미리 강제로 로드해두기 때문에
00:59:29그런 표현을 쓰자마자 바로 작동하게 됩니다.
00:59:33그 패키지는 여기에 있습니다.
00:59:36'skills-primer'를 찾아볼게요.
00:59:41- 마지막에 이 링크들도 공유해 드릴 수 있습니다.
00:59:45- 아, 좋네요.
00:59:45- 이미 준비되어 있습니다. 완벽해요.
00:59:46- 저기에 올려둘게요.
00:59:50- 그리고 늘 그렇듯이,
00:59:53오늘날의 소프트웨어가 그렇듯
00:59:55저장소를 복제(clone)해서 여러분의 것으로 만드세요.
00:59:59지금은 CLI와 소프트웨어를 각자 입맛에 맞게
01:00:02개인화하는 시대니까요.
01:00:04이름을 완전히 바꾸고 싶거나
01:00:07전혀 다른 기능을 넣고 싶다면 그렇게 하세요.
01:00:08Codex나 Cursor 등 어디서든 쓸 수 있게
01:00:11커스터마이징하고 싶다면 그냥 복제해서 고쳐 쓰시면 됩니다.
01:00:14“이게 Cursor에서 작동하게 해 줘”라고 요청하고
01:00:18에이전트가 Cursor용으로 빌드하게 만들면 되죠.
01:00:20요즘은 한 번의 요청으로
01:00:23정말 많은 것들을 해낼 수 있습니다. 대단하죠.
01:00:26- 정말 놀랍네요. 개인화된 소프트웨어가 대세군요.
01:00:29채팅창에 올라온 질문 하나만
01:00:31더 드려보고 싶습니다.
01:00:32약속한 시간이 다 되긴 했지만,
01:00:35스킬이 GitHub 저장소이기도 하고
01:00:37로컬에도 설치되는 것 같은데,
01:00:40업데이트는 어떻게 확인하나요?
01:00:42CLI에 'slash update skill' 같은 명령어가 있나요?
01:00:48- 정확한 명령어가 뭐였는지 기억이 가물가물하네요.
01:00:52창을 좀 닫고 확인해 볼게요.
01:00:53아, 전역(global)으로 설치도 안 해놨었네요.
01:00:59- (웃음)
01:01:02- 'skills list'를 하면 최신 버전을 가져옵니다.
01:01:05네, 'skills update' 명령어가 있네요.
01:01:07- 추가 질문을 드리자면,
01:01:11스킬 업데이트가 자주 일어나는 게 좋을까요?
01:01:13- 아주 좋은 질문입니다.
01:01:18사실 이 부분에 대해서는
01:01:23아무도 정답을 모를 겁니다.
01:01:28스킬의 프론트 매터(front matter)나 버전 관리에 대한 규칙이
01:01:30아직 모두가 합의한 표준이 없거든요.
01:01:32어떤 디렉터리 구조를 쓸지에 대해서도
01:01:34아직 의견이 분분합니다.
01:01:37지금은 생태계가 아주 빠르게 성장하는 단계니까요.
01:01:41그래서 버전 관리에 대해서는
01:01:47상황을 지켜봐야 할 것 같아요.
01:01:49지금 할 수 있는 최선을 다하면서
01:01:51어떤 게 모범 사례(best practice)로 자리 잡을지 기다려보는 거죠.
01:01:54지금 당장 드릴 수 있는 조언은
01:01:57매번 업데이트하라는 것 정도입니다.
01:01:59그게 최선이라고 가정하는 수밖에 없죠.
01:02:03별다른 팁이 없어서 죄송하네요.
01:02:06- 네, 워낙 모든 게 빠르게 변하고 있으니까요.
01:02:08분명 며칠 내로 누군가가
01:02:12새로운 의견을 내놓을 겁니다. 매일이 다르니까요.
01:02:18오늘 정말 고생하셨습니다, John.
01:02:18커뮤니티에 마지막으로
01:02:20더 보여주고 싶으신 게 있나요?
01:02:21- 사실 정말 많아요.
01:02:25- 너무 많죠.
01:02:26- 이런 기회를 더 자주 만들어서
01:02:28보여드릴 것들이 한가득이지만,
01:02:30계속하면 몇 시간이고 더 떠들 수 있을 것 같네요.
01:02:32- 네, 정말 좋았습니다.
01:02:34John, 오늘 저희 커뮤니티 플랫폼에
01:02:36찾아와 주셔서 정말 감사합니다.
01:02:38커뮤니티 여러분과 소통해 주신 점도,
01:02:39끝까지 함께해주신 여러분께도 감사드려요.
01:02:42방금 말씀드린 것처럼,
01:02:44John은 조만간 꼭 다시 모실 예정입니다.
01:02:46기대해 주세요.
01:02:48- 모두 감사합니다.
01:02:49- 감사합니다.
01:02:50자, 다음 커뮤니티 세션에
01:02:53참여하고 싶으시다면,
01:02:55월요일에 '오픈 소스 스토리' 세션이 있고
01:02:58다음 주에 또 다른 파트너사들과의
01:03:00마켓플레이스 파트너 세션이 준비되어 있습니다.
01:03:03자세한 일정은
01:03:04커뮤니티 이벤트 캘린더에서 확인하실 수 있습니다.
01:03:08주소는 [community.vercel.com/events](https://www.google.com/search?q=https://community.vercel.com/events) 입니다.
01:03:12함께해주신 여러분 모두 정말 감사합니다.
01:03:15정말 즐거운 시간이었고,
01:03:17다음 주에 뵙겠습니다!