사실 저는 예전에는 개발 프로젝트를 할 때 ‘이론’보다는 ‘직관’에 의존하는 편이었어요. 물론 경험이 쌓이면서 나름의 기준이 생기긴 했지만, 가끔씩 마주치는 복잡한 규칙들이나 ‘이게 맞나?’ 싶은 코드들을 볼 때마다 묘하게 불안하곤 했죠. 특히 팀 프로젝트를 할 때는 다들 자기만의 방식으로 코드를 작성하니까, 나중에 이걸 누가 유지보수해야 할지 막막할 때도 있었고요. 그래서 늘 ‘어떻게 하면 좀 더 체계적이고 일관성 있게 프로젝트를 관리할 수 있을까?’ 하는 고민을 안고 살았습니다.
그러던 어느 날, 코드팩토리 채널에서 ‘코팩의 두번째 선물. 스킬을 검증하고, 스킬을 만들고, 스킬을 실행하는 스킬 무료 배포’라는 영상을 보게 되었어요. 처음에는 ‘스킬’이라는 단어가 조금 낯설었지만, 영상을 보기 시작하면서 ‘이거다!’ 싶었죠. 제가 그동안 고민하던 문제들을 명쾌하게 해결해 줄 수 있는 열쇠가 바로 이 ‘스킬’이라는 개념에 담겨 있더라고요.
나만의 코드 규칙, AI에게 맡기다
영상에서 소개하는 ‘스킬 구조’는 정말이지 제가 딱 원하던 방식이었어요. 단순히 코드를 작성하는 걸 넘어서, 프로젝트의 전반적인 퀄리티를 관리하고 표준을 완벽하게 준수할 수 있게 해준다는 점이 정말 매력적이었는데요. 특히 ‘베리파이(Verify)’ 스킬들이 핵심인데, 이걸 하나하나 실행하는 게 아니라 하나의 스킬로 묶어서 병렬로 실행할 수 있다는 게 정말 편리하더라고요. 상상해보세요. 내가 정해놓은 모든 코드 검증 규칙들을 한 번에 쭉 돌리는 거예요. 마치 똑똑한 조수가 모든 걸 체크해주는 느낌이랄까요?
검증이 끝나면 바로 리포트가 생성돼요. 어떤 부분이 체크되었고, 어떤 이슈가 있는지, 심지어는 그 이슈를 어떻게 수정해야 하는지에 대한 설명까지 상세하게 담겨있다는 거죠. 이게 왜 좋냐면, 컨텍스트를 극강으로 아끼면서도 프로젝트의 표준을 완벽하게 지킬 수 있기 때문이에요. 새로운 기능을 추가할 때마다 이 스킬들을 통해 프로젝트 전반의 표준에 잘 부합하는지 바로바로 확인할 수 있다는 건, 정말 엄청난 장점이라고 생각했어요.
스킬, 어떻게 구성될까?
영상에서 이 ‘스킬’은 크게 세 가지 요소로 구성된다고 설명하더라고요. 첫 번째는 스킬 자체를 관리하는 ‘스킬 생성 스킬’이고, 두 번째는 프로젝트의 도메인, 기술, 아키텍처 등을 검증하고 문서화하는 스킬, 그리고 마지막으로 이 모든 스킬을 중앙에서 실행하고 리포팅하는 ‘중앙화 실행 스킬’이었어요. 그러니까, 스킬을 만들기 위한 스킬이 필요한 셈이죠. 물론 자세한 예제는 깃허브 링크로 배포될 예정이라고 하니, 그걸 보면 더 명확하게 이해할 수 있을 것 같아요.
‘스킬’이라는 이름에 담긴 힘
근데 여기서 드는 의문이 ‘왜 굳이 ‘스킬’이어야 할까?’ 하는 거였어요. 영상에서는 이 ‘스킬’이라는 개념이 특정 영역에서 정말 큰 효능을 발휘한다고 설명하더라고요. 다른 방식들, 예를 들어 커맨드나 서브에이전트 같은 것들과 비교하면 어떤 장점이 있는지에 대한 내용은 채널 내 다른 영상에서 다뤘다고 하니, 관심 있는 분들은 찾아보시면 좋을 것 같아요.
이 ‘스킬’을 제대로 이해하려면 ‘Progressive Disclosure’, 즉 ‘단계적 공개’라는 개념을 꼭 알아야 한다고 하더라고요. AI에게 정보를 한 번에 다 보여주는 게 아니라, 필요한 만큼만 순차적으로 제공하는 방식인 거죠. 이게 왜 중요하냐면, AI 모델은 컨텍스트 창의 크기에 제한이 있고, 너무 많은 정보를 한 번에 주면 오히려 효율이 떨어지기 때문이에요. 그래서 이 ‘스킬’은 공식 다큐멘테이션 기준으로 세 가지 레벨로 나뉜다고 설명했어요.
스킬의 세 가지 레벨, 컨텍스트 최적화의 비밀
-
레벨 1: 프론트 메터 (Front Matter)
이건 마크다운 파일의 가장 앞부분에 있는 메타데이터 영역이에요. 스킬 이름이나 설명을 여기에 기입하는데, AI가 스킬을 선택할 때 아주 중요한 역할을 한다고 하더라고요. 그리고 가장 중요한 건, 이 부분은 항상 컨텍스트 창에 로딩되기 때문에 아주 짧게, 100 토큰 이하로 작성하는 게 권장된다는 점이에요. 정말 컨텍스트를 아끼려는 노력이 엿보이는 부분이었죠.
-
레벨 2: 마크다운 바디 (Markdown Body)
이건 우리가 흔히 보는 마크다운 콘텐츠 영역이에요. 스킬이 트리거되기 전까지는 컨텍스트 창에 올라가지 않는다는 점이 레벨 1과 다르죠. 이 부분은 5,000 토큰 이하로 작성하는 게 좋다고 해요.
-
레벨 3 이상: 외부 파일 참조
이게 정말 신기한 부분이었는데요. 스킬.md 파일 본문에서 다른 외부 파일들을 참조할 수 있다는 거예요. AI가 스킬 사용을 결정하고 나서, 해당 파일 레퍼런스를 확인하는 시점에 비로소 파일이 로딩되는 거죠. 예를 들어, 예제 코드나 특정 조건에 맞는 코드 조각, 혹은 다른 스킬의 레퍼런스 등을 담아둘 수 있어요. 이 레벨 3 파일 안에서도 또 다른 파일을 참조할 수 있어서 레벨 4, 5, 6… 이렇게 깊어질 수 있고요. 이걸 통해 정말 필요한 순간에만 컨텍스트 창에 정보를 로딩할 수 있게 되는 거죠. 스킬의 공통 필수 내용은 스킬.md에 담고, 나머지는 이렇게 외부 파일로 분리해서 관리하는 거예요.
이 세 가지 단계적 공개 구조 덕분에 스킬의 컨텍스트 창 사용을 최적화하고 토큰을 절약할 수 있다는 점이 정말 인상 깊었습니다. 과거에는 ‘더 많은 정보를 주면 AI가 더 잘 이해하겠지’라고 막연하게 생각했었는데, 오히려 효율적인 정보 제공 방식이 중요하다는 걸 깨닫게 되었어요.
프로젝트의 든든한 기둥, ‘매니지 스킬’과 ‘베리파이 임플리멘테이션’
이번에 무료로 배포되는 스킬들의 핵심은 바로 ‘프로젝트 전반 관리’에 있다고 해요. 프레임워크 스탠더드, 캐싱, 프로젝트 포인트 시스템, 마이그레이션 스탠더드 관리 등 바이브 코딩 시 발생하는 새로운 지식과 기준들을 통합적으로 관리할 수 있게 해주는 거죠. 제가 그동안 막연하게 생각했던 ‘프로젝트 표준’이라는 게 구체적으로 어떻게 관리될 수 있는지 보여주는 것 같았어요.
모든 스킬을 한번에, ‘매니지 스킬’
이 ‘매니지 스킬’은 말 그대로 모든 스킬들을 한 번에 관리해주는 스킬이라고 해요. 스킬의 이름과 설명을 명확하게 하고, 스킬 사용 시 추가적인 설명을 제공하는 아규먼트 힌트 기능도 있고요. 주요 기능으로는 베리파이 스킬에서 참조되지 않는 변경 파일을 확인하거나, 삭제/이동된 파일을 참조하는 스킬을 찾는 일 등을 할 수 있대요. 새로운 패턴이나 규칙을 추가하거나, 더 이상 일치하지 않는 설정값이나 탐지 명령어를 수정하는 것도 가능하고요.
특히 흥미로웠던 건, 새로운 스킬을 만들 때마다 해당 스킬이 ‘등록된 검증 스킬 테이블’에 자동으로 등록되고 역할이 정의된다는 점이에요. 이걸 통해 생성된 스킬들을 일괄적으로 관리할 수 있는 거죠. 기존 스킬 도메인과 관련된 파일이 있으면 업데이트하고, 그렇지 않으면 새로운 스킬을 생성하는 결정도 AI가 내릴 수 있고요. 사용자 컨펌을 받는 과정도 있어서, AI가 멋대로 스킬을 바꾸거나 생성하지 않도록 제어할 수 있다는 점도 안심이 됐습니다.
통합 검증의 끝판왕, ‘베리파이 임플리멘테이션’
그리고 ‘베리파이 임플리멘테이션’ 스킬! 이건 정말 통합 검증 스킬의 끝판왕 같은 느낌이었어요. 위에서 말한 ‘매니지 스킬’을 통해 생성된 모든 ‘베리파이’로 시작하는 스킬들을 한 번에 실행해서 종합 리포트를 만들어주는 거죠. 마치 내가 짜놓은 모든 검증 절차를 한 번에 쭉 돌려주는 것과 같은 효과를 내는 거예요. 매니지 스킬을 통해 생성된 스킬들은 이미 표준에 따라 만들어졌기 때문에, 이렇게 통합적인 리포트를 만드는 게 훨씬 용이하다고 해요.
이제 스킬을 시작할 시간
영상을 보면서 가장 좋았던 부분 중 하나는, 이 모든 스킬을 실제로 어떻게 사용하는지에 대한 설명이었어요. 슬래시 커맨드 (/)를 통해서 간단하게 실행할 수 있고, ‘매니지 스킬’을 검색해서 원하는 기능을 직접 입력하면 되는 거죠. 기존에 하던 작업에서 중요한 요소들을 추출해서 저장해달라고 요청할 수도 있고요. 심지어는 자동으로 베리파이 스킬을 생성하고 메타데이터를 수정하라는 명령까지 할 수 있다는 게 놀라웠어요.
사용 팁으로는 깃허브에 무료로 제공되는 프로젝트를 복사해서 바로 사용해 볼 수 있다는 점이었어요. ‘매니지 스킬’로 새로운 스킬을 만들고, ‘베리파이 임플리멘테이션’으로 검증하는 과정을 직접 경험해보면 좋겠죠. 처음에는 스킬 업데이트가 조금 번거롭게 느껴질 수도 있겠지만, 프로젝트가 커질수록 그 효과는 훨씬 더 커질 거라고 하더라고요. 특히 코딩 표준이나 아키텍처가 무너졌을 때, 이 스킬셋을 활용해서 다시 구도를 바로잡을 수 있다는 점은 정말 매력적인 부분이에요. 푸시하기 전에 최소 한 번은 이 스킬들을 실행해보는 습관을 들이는 게 좋겠다는 생각이 강하게 들었습니다.
결국, 중요한 건 꾸준히 이 스킬셋을 활용해서 프로젝트 규격을 확립하고 유지하는 것이라는 생각이 들었어요. 여러분도 한번 이 ‘스킬’이라는 개념을 통해 여러분의 프로젝트 관리 방식을 한 단계 업그레이드해보는 건 어떨까요?