반복 지시가 놓이는 네 자리와 프로젝트 지침과 스킬의 차이

5-1. 만들었는데, 어디에 두지

첫 스킬을 만들고 나면 곧바로 막히는 지점이 있다. 이걸 대체 어디에 두는 건가. 만드는 과정은 대화로 따라왔는데, 정작 이 스킬이 어느 자리에 놓여 있는지, 어디에 놓아야 제대로 불려 나오는지가 잡히지 않는다.

이 자리에서 독자가 실제로 던지는 질문들은 대개 비슷하다. 이건 클로드 안에 넣는 건가. 챗GPT에서도 되나. 프로젝트 지침이라는 것을 써 봤는데, 그거랑 스킬은 뭐가 다른가. 그냥 메모장에 저장해 두면 그것도 스킬인가. 회사 동료와 나눠 쓰려면 파일로 줘야 하나. 질문이 많다는 것은, 스킬이 놓일 수 있는 자리가 하나가 아니라는 뜻이다.

이 질문들이 많은 데는 이유가 있다. 스킬이라는 말이 자리를 가리지 않고 넓게 쓰이기 때문이다. 어떤 사람은 대화창에 붙여 넣는 프롬프트를 스킬이라 부르고, 어떤 사람은 프로젝트에 걸어 둔 지침을 스킬이라 부른다. 말이 겹치니 배치도 헷갈린다. 그래서 자리부터 갈라 두어야 한다. 자리를 나누고 나면, 무엇이 스킬이고 무엇은 스킬이 아닌지가 저절로 정해진다.

실제로 지시는 여러 자리에 놓일 수 있고, 자리마다 성격이 다르다. 어떤 자리는 한 번 쓰고 사라지고, 어떤 자리는 늘 읽히고, 어떤 자리는 필요할 때만 열린다. 같은 내용을 담아도 어느 자리에 두느냐에 따라 수명과 쓰임이 달라진다. 그래서 스킬을 잘 만드는 것만큼, 맞는 자리에 두는 것이 중요하다. 잘 만든 스킬도 엉뚱한 자리에 두면 불려 나오지 않고, 평범한 지시도 맞는 자리에 두면 제 몫을 한다.

이 장은 그 자리를 정리한다. 지시가 놓일 수 있는 네 자리를 늘어놓고, 각 자리가 어떻게 다른지 본다. 그중 어느 것이 스킬이고 어느 것은 스킬이 아닌지도 분명히 한다. 특히 가장 많이 헷갈리는 프로젝트 지침과 스킬의 차이를 따로 짚는다. 자리를 알고 나면, 자기가 만든 스킬을 어디에 두어야 할지가 정해진다.

5-2. 네 자리

반복 지시를 운용하는 방식은 네 개로 늘어놓을 수 있다. 왼쪽에서 오른쪽으로 갈수록 더 오래 남고 더 넓게 쓰인다. 다만 네 방식이 모두 스킬인 것은 아니다. 단발 프롬프트와 프로젝트 지침은 스킬과 비교해야 할 이웃이고, 표준 형식의 스킬은 개인 또는 팀 범위에 설치해 쓴다.

첫 번째 자리는 단발 프롬프트다. 대화창에 그때그때 붙여 넣는 지시다. 지금까지 메모장에서 복사해 쓰던 바로 그 방식이다. 이 자리에 놓인 지시의 수명은 대화 한 번이다. 창을 닫으면 사라지고, 다음에 또 붙여 넣어야 한다. 분명히 해 둘 것이 있다. 이것은 스킬이 아니다. 아무리 잘 쓴 프롬프트라도, 대화창에 붙여 넣는 한 그것은 단발 지시일 뿐이다. 스킬과 프롬프트를 가르는 첫 경계가 여기다. 붙여넣기는 스킬의 출발 재료일 수는 있어도, 그 자체로 스킬은 아니다. 이 구분을 흐리면 책의 전제가 무너진다. 메모장에 프롬프트를 잘 모아 둔 것을 스킬을 가졌다고 여기면, 1장에서 짚은 세 증상이 그대로 남는다. 붙여넣기를 임시 스킬 같은 이름으로 부르지 않는 이유도 여기 있다. 자리가 다르면 이름도 달라야 한다.

두 번째 방식은 프로젝트 지침이다. 특정 프로젝트나 작업 공간에 걸어 두는 지시로, 그 안에서는 계속 적용된다. 붙여 넣지 않아도 되지만 범위는 그 프로젝트 안으로 한정된다. 이것은 제품이 제공하는 상시 지침 기능이지, SKILL.md 공개 표준의 스킬은 아니다. 반복 입력을 줄인다는 효과가 비슷해 스킬과 헷갈리기 쉽지만, 특정 업무가 아니라 그 공간의 모든 작업에 공통으로 걸린다는 점이 다르다.

세 번째 방식이 설치된 스킬이다. 이 책이 주로 다루는 표준형이다. 이름과 설명, 지침을 담은 SKILL.md를 제품이나 작업 환경이 읽을 수 있는 위치에 설치한다. 이후 제품에 따라 관련 요청에서 자동으로 선택되거나, 사용자가 목록과 호출 문법으로 직접 선택한다. 공개 표준은 스킬의 파일 구조를 정하지만, 설치 위치와 선택 방식까지 하나로 통일하지는 않는다. 따라서 “어느 대화에서든 자동 발동한다”는 식으로 제품 차이를 지우면 안 된다.

네 번째 방식은 팀 라이브러리다. 같은 표준 스킬을 파일로 배포하거나 제품의 조직 기능으로 설치해 여러 사람이 함께 쓴다. 별개의 스킬 형식이 아니라 세 번째 방식의 공유 범위를 넓힌 것이다. 개인의 요령이 팀의 표준으로 넘어가는 대신, 버전·승인·민감 정보·변경 공지를 함께 관리해야 한다.

네 자리를 한눈에 비교하면 다음과 같다.

단발 프롬프트·프로젝트 지침·설치된 스킬·팀 라이브러리 비교

그림 5-1. 반복 지시는 목적과 범위에 맞는 자리에 놓아야 한다.

표에서 첫째와 둘째는 반복 지시를 다루는 이웃 방식이고, 셋째와 넷째가 공개 표준의 스킬이다. 앞으로 이 책에서 스킬이라 부르는 것은 SKILL.md를 갖춘 세 번째 형식을 가리킨다. 네 번째는 그 스킬을 여럿이 나눠 쓰는 운영 방식이다.

5-3. 프로젝트 지침과 스킬은 뭐가 다른가

가장 많이 나오는 질문이 이것이다. 프로젝트 지침도 매번 다시 쓰지 않아도 되고 스킬도 그렇다. 차이는 한 문장으로 정리된다. 프로젝트 지침은 그 공간의 모든 작업에 공통으로 적용하고, 스킬은 특정 업무를 할 때만 선택해 쓴다.

프로젝트 지침은 그 프로젝트 안의 모든 대화에 늘 깔린다. 무슨 요청을 하든 배경에 함께 적용된다. 그래서 프로젝트 안에서 하는 모든 일에 공통으로 걸리는 지시를 담기에 좋다. 이 프로젝트에서는 항상 존댓말을 쓴다, 이 작업 공간의 결과물은 늘 우리 회사 용어를 따른다 같은 것이다. 어떤 일을 하든 공통으로 적용되어야 하는 규칙이면 지침이 맞다.

스킬은 다르다. 특정 업무에만 걸린다. 주간 보고를 만들 때만 주간 보고 스킬이 열리고, 회의록을 정리할 때는 열리지 않는다. 그래서 특정 상황에만 필요한 지시를 담기에 좋다. 어떤 노하우가 모든 대화에 두루 적용되면 지침에, 특정 업무에만 적용되면 스킬에 담는다. 이 구분이 둘을 가르는 기준이다.

판단이 애매할 때는 이렇게 물어보면 된다. 이 지시가 이 공간에서 하는 모든 일에 적용되어야 하는가, 아니면 특정 업무를 할 때만 적용되면 되는가. 앞이면 지침이고 뒤면 스킬이다. 회사 용어를 통일하는 규칙은 무슨 일을 하든 걸려야 하니 지침이 맞고, 주간 보고를 개조식으로 정리하는 규칙은 그 업무를 할 때만 필요하니 스킬이 맞다. 둘을 굳이 하나로 합치려 하면 어느 쪽도 제대로 작동하지 않는다. 항상 걸려야 할 것이 특정 업무에만 묶이거나, 특정 업무용 규칙이 늘 배경에 끌려 나오기 때문이다.

세 가지 방식을 나란히 두면 차이가 분명해진다.

프롬프트 메모 vs 지침 vs 스킬

프롬프트 메모는 사람이 필요할 때 찾아 붙여 넣는다.

프로젝트 지침은 그 공간 안에서 늘 읽힌다.

스킬은 특정 업무에서만 자동 선택하거나 이름으로 호출한다.

같은 지시라도 어디에 담느냐에 따라 꺼내는 주체와 시점이 달라진다. 메모는 사람이 꺼내고, 지침은 늘 켜져 있고, 스킬은 AI가 상황을 보고 꺼낸다. 항상 켜 두는 것이 유리한 지시가 있고, 필요할 때만 켜지는 것이 유리한 지시가 있다. 모든 것을 지침에 몰아넣으면 배경이 무거워지고, 상황에 안 맞는 규칙까지 늘 끌려 나온다. 반대로 두루 쓰는 규칙을 스킬로 만들면 정작 필요한 순간에 안 열릴 수 있다. 자리를 맞게 고르는 것이 그래서 중요하다.

5-4. 표준형이 되는 순간

세 번째 방식, 설치된 스킬로 만드는 순간 지시는 표준형이 된다. 표준형이라는 말이 거창하게 들릴 수 있지만, 정해진 자리에 정해진 것을 담은 상태를 가리킬 뿐이다. 앞에서 만든 주간 보고 스킬을 형식만 남겨 늘어놓으면 이런 모습이다.

이름: weekly-report-format

설명: 매주 월요일 팀 주간 보고 초안을 회사 표준 형식으로 정리할 때 사용한다.

지침 (다섯 항목)

1. 전체를 개조식으로 작성한다.

2. 지난주 대비 변화를 맨 앞에 둔다.

3. 이번 주 실적을 항목별로 적는다.

4. 다음 주 계획을 맨 뒤에 둔다.

5. 과장된 수식어를 빼고, 숫자는 굵게 강조하지 않는다.

검수 기준: 지난주 대비 변화와 다음 주 계획이 빠지지 않았는지 확인한다.

이 형식을 보고 오해하지 말아야 할 것이 있다. 이것은 실행할 코드가 아니다. 지시를 이 형태로 정리해 두면 AI가 더 안정적으로 읽는다는 뜻이다. 이름, 설명, 지침, 검수 기준이 자리를 잡은 구조는 뭉친 메모보다 선택과 실행과 확인의 경계가 또렷하다.

이 예시는 앞서 말한 최소 단위를 그대로 따른다. 업무 하나는 주간 보고 정리, 사용 조건 하나는 매주 팀 보고, 출력 형식 하나는 개조식 구성, 검수 기준 하나는 변화와 계획의 누락 확인이다. 이 네 가지가 또렷하게 담겨 있다. 표준형이란 결국 이 최소 단위가 이름·설명·지침이라는 자리에 정리된 상태다. 회의록 정리와 이메일 작성까지 욱여넣으면 설명이 여러 상황을 가리켜 선택이 흐려지고 지침도 뒤섞인다.

메모장에 적어 둔 프롬프트와 이 형식의 차이도 여기서 드러난다. 메모장의 프롬프트는 문단 하나로 뭉쳐 있어, 어디까지가 언제 쓰는지이고 어디부터가 어떻게 하는지인지 구분되지 않는다. 표준형은 그 문단을 이름, 설명, 지침, 검수 기준이라는 자리로 갈라 놓는다. 설명을 보고 선택 여부를 판단하고, 지침을 보고 작업하고, 검수 기준을 보고 결과를 점검한다.

이 형식은 공개 표준이라 지원 도구 사이에서 옮겨 쓸 여지가 있다. 그러나 “표준”이 “어디서나 똑같이 작동한다”는 뜻은 아니다. 제품마다 설치 위치, 허용하는 부가 항목, 자동 선택, 도구 권한이 다르다. 옮길 때는 name과 description, 본문 지침 같은 공통부를 유지하고, 제품별 설정과 권한을 다시 확인해야 한다. 이식 가능성과 완전 호환을 구분해 두면 과장된 기대를 피할 수 있다.

자리마다 쓰임이 다르다는 것을 알고 나면 배치가 막막하지 않다. 특정 업무에만 걸리는 노하우라면 설치된 스킬로 둔다. 동료와 나눠 쓸 때는 팀 라이브러리로 배포한다. 모든 일에 두루 걸려야 할 규칙이라면 스킬이 아니라 프로젝트 지침에 둔다.

자리를 정했으면 스킬을 그 자리에 두면 된다. 그런데 자리에 잘 놓았는데도 막상 관련 요청에 스킬이 안 불려 나오는 일이 있다. 그럴 때는 자리가 아니라 설명이 문제인 경우가 많다. 발동을 좌우하는 설명을 어떻게 써야 하는지, 다음 장에서 본격적으로 다룬다. 자리를 맞게 골랐다면, 남은 절반은 설명에 달려 있다.