당신의 AI 스킬에도 버전 관리가 필요합니다

블로그 · 6분 분량

패키지 매니저가 있기 전에 「남의 코드를 쓴다」는 것은 파일 하나를 내 프로젝트로 복사하는 일이었습니다. 원본에 버그 수정이 들어갔는데 내 사본에는 들어가지 않는 날이 오기 전까지, 혹은 내 사본이 딱 그만큼 갈라져서 수정을 되돌려 합치는 일이 더는 복사·붙여넣기가 아니게 되기 전까지는 잘 작동했죠. 코드에 대해서는 수십 년 전에 해결했습니다. 스킬은 지금 똑같은 문제를, 대개는 해법 없이 겪고 있습니다.

주변에 물어보면 어디서나 같은 패턴을 발견하게 됩니다. 풀 리퀘스트 리뷰용으로 좋은 프롬프트가 프로젝트 A에 붙여넣어지고, 거기서도 잘 통했다는 이유로 B에 다시 붙여넣어지고, 다른 언어를 위해 두 줄만 바꿔 세 번째로 붙여넣어집니다. 그건 더 이상 하나의 스킬이 아닙니다. 공통 조상을 가진 세 개의 프롬프트이고, 여섯 달 뒤에 어느 것이 「진짜」인지, A에 넣은 수정이 C까지 간 적이 있는지 알 방법은 없습니다.

복사·붙여넣기가 실제로 치르게 하는 비용

• 수정이 전파되지 않습니다. Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• diff가 없습니다. When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• 되돌릴 방법이 없습니다. A change that turns out to be wrong has already overwritten the version that worked.

이 중 어느 것도 다른 스킬로 스킬을 조합하기를 그만둘 이유는 아닙니다. 하나의 테스트 철학을 언어별 스킬 다섯 개가 공유하거나, 사내 스타일 가이드를 더 구체적인 스킬 열몇 개가 공유하는 것은 바로 할 만한 가치가 있는 재사용입니다. 오히려 그렇게 공유되는 조각들이 코드 의존성과 같은 규율 — 진짜 버전, 선언된 제약, 그리고 「현재」가 의미를 갖는 장소 — 을 갖춰야 하는 이유입니다.

패키지 매니저 모델을 지침에 적용하기

스킬을 텍스트 덩어리가 아니라 패키지로 다루면, 이 부류의 문제는 코드에서 그랬듯 통째로 사라집니다.

• 스킬에는 버전이 있습니다. 바꾸면 버전도 함께 바뀝니다.
• 다른 스킬은 내용을 품는 대신 제약(>=1.0.0)을 걸어 의존할 수 있습니다.
• 의존 대상의 업데이트를 공개하면 그것을 해석하는 모든 의존 스킬이 갱신됩니다 — 사본을 찾아다닐 필요가 없습니다.
• 어떤 버전을 더 이상 권장하지 않음으로 표시해도, 거기에 고정된 것들은 깨지지 않습니다.
• 의도적으로 갈라지는 것은 포크로 기록되며, 추적되지 않는 복사·붙여넣기가 아닙니다.

이는 npm, pip, cargo와 같은 형태입니다. 스킬이 코드여서가 아니라, 「시간에 따라 변하는 공유물에 여러 가지가 의존한다」는 것이 파일 안에 무엇이 들었든 같은 문제이기 때문입니다.

붙여넣은 텍스트로만 존재하는 스킬에는 계보가 없습니다. 버전이 매겨지고 조합 가능한 스킬에는 실제로 따져볼 수 있는 이력이 있습니다.

사용해 보기

튜토리얼 Compose and version skills like code은(는) 의존성을 선언하는 법, 모든 의존 스킬이 가져가는 업데이트를 공개하는 법, 그리고 출처를 잃지 않고 스킬을 포크하는 법을 다룹니다.