3-1. 재료는 이미 있다
첫 스킬의 재료는 두 가지다. 하나는 지금까지 붙여 넣던 프롬프트다. 다른 하나는 그 일을 하며 쌓인 판단이다. 왜 이 항목을 빼는지, 언제 톤을 바꾸는지처럼 문장으로 적지 않았던 기준까지 꺼낸다.
프롬프트가 따로 없다면 지난번 AI에게 뭐라고 부탁했는지 그대로 적으면 된다. 다듬지 않아도 된다. 이 장에서 AI와 함께 정리할 것이다.
과정에 코드는 필요 없다. 대화로 업무와 규칙을 설명하면 결과가 표준 형식의 스킬로 정리된다. 다만 첫 초안이 곧 완성본은 아니다. 만들고, 서로 다른 입력으로 시험하고, 빠진 규칙을 고치는 과정을 두세 번 거치는 것이 정상이다.
이 장의 목표는 완벽한 스킬이 아니라 실제로 한 번 써 본 첫 스킬이다.
3-2. 승격 5단계
프롬프트를 스킬로 올리는 과정은 다섯 단계다. 각 단계에서 무엇을 입력하고 무엇을 확인해야 하는지 함께 본다. 스킬 생성을 돕는 skill-creator가 설치되어 있다면 “이 프롬프트를 스킬로 만들어 줘”라고 요청하는 것만으로 시작할 수 있다. ChatGPT, Codex, Claude 등 제품마다 제공 플랜, 설치 방식, 자동 호출 방식은 다르며 바뀔 수 있다. 책을 읽는 시점의 제품 도움말에서 스킬 생성·설치 지원 여부를 먼저 확인하자.
아래 다섯 단계는 버튼의 위치를 외우는 안내가 아니다. 화면은 바뀌어도 업무 선택 → 이름과 설명 → 지침 → 자료 → 시험이라는 설계 순서는 바뀌지 않는다. 따라서 어떤 도구를 쓰든 그대로 적용할 수 있다.
첫 번째 단계는 프롬프트를 보여 주고 스킬로 만들어 달라고 요청하는 것이다. 가진 프롬프트를 그대로 붙여 넣고, 이것을 반복해서 쓰고 싶으니 스킬로 만들고 싶다고 말한다. 입력은 이런 식이다.
다음은 내가 매주 주간 보고서를 만들 때 쓰는 지시다. 이걸 스킬로 만들고 싶다.
(이어서 그동안 쓰던 프롬프트를 그대로 붙여 넣는다)
그러면 AI는 이 지시를 스킬로 정리하기 위해 몇 가지를 되묻는다. 돌아오는 응답은 대체로 이런 형태다.
이 지시를 스킬로 만들 수 있다. 정리하기 전에 몇 가지를 확인하고 싶다. 첫째, 이 스킬은 주로 어떤 상황에서 꺼내 쓰고 싶은가. 둘째, 결과물은 어떤 형태여야 하는가. 셋째, 매번 꼭 지켜야 하는 조건이 더 있는가.
되묻는 질문에 답하는 것이 곧 다음 단계로 이어진다. 처음부터 완벽하게 답할 필요는 없고, 떠오르는 대로 적으면 AI가 정리해 준다. 답이 부실하면 부실한 대로 초안이 나오고, 그 초안을 보며 고쳐 나가면 된다.
두 번째 단계는 이름과 설명을 다듬는 것이다. 이름은 이 스킬이 무엇인지 한눈에 알아볼 수 있게, 좁고 구체적으로 짓는다. 보고서 작성처럼 넓은 이름은 피하고, 주간 보고 형식 정리처럼 좁게 잡는다. 공개 표준의 name은 폴더 이름과 같아야 하며, 영문 소문자·숫자·하이픈만 쓴다. 따라서 내부 이름은 weekly-report-format처럼 짓는다. 제품에 따라 사람이 보는 한글 표시 이름을 별도로 제공할 수도 있지만, 그것은 표준의 필수 항목이 아니라 제품 기능이다.
설명은 더 중요하다. 설명은 이 스킬이 무엇을 하며 언제 꺼내야 하는지를 적는 자리다. 둘 중 발동에 더 직접 영향을 주는 것은 언제 쓰는지다. AI는 나중에 이 설명을 보고 지금 이 요청에 이 스킬이 맞는지 판단한다. 그래서 매주 팀 주간 보고 초안을 정리할 때 쓴다처럼, 어떤 상황에서 쓰이는지가 설명에 분명히 드러나야 한다. 입력은 이렇게 준다.
이름은 weekly-report-format으로 하고, 설명에는 매주 팀 주간 보고 초안을 우리 회사 형식으로 정리할 때 쓴다는 걸 넣어 줘.
돌아오는 응답은 이런 형태다.
이름: weekly-report-format
설명: 매주 월요일 팀 주간 보고 초안을 회사 표준 형식으로 정리할 때 사용한다. 개조식 보고서, 지난주 대비 변화 정리가 필요할 때 꺼낸다.
제안된 이름과 설명을 읽어 보고, 어색한 부분만 손봐서 확정한다. 이때 설명이 짧다고 아쉬워할 필요는 없다. 설명은 길이보다 언제 쓰는지가 또렷한 것이 중요하다. 오히려 이런저런 상황을 다 담으려 설명을 늘리면, 발동 판단이 흐려진다.
세 번째 단계는 지침을 정리하는 것이다. 지침은 이 일을 어떻게 하는지를 규칙 문장으로 적는 자리다. 여기가 스킬의 핵심이다. 지금까지 매번 대화창에 풀어 놓던 조건들을, 두고두고 쓸 규칙으로 옮긴다. 개조식으로 쓴다, 지난주 대비 변화를 맨 앞에 둔다, 과장된 수식어는 빼고 숫자를 강조하지 않는다 같은 조건이 여기 들어간다. 이때 한 가지 원칙이 있다. 형식에 관한 규칙과 판단에 관한 규칙을 섞지 않는 것이다. 이 원칙을 어기면 나중에 결과가 들쭉날쭉해지는데, 그 이야기는 뒤에서 실패 사례로 다시 본다. 입력은 이렇게 준다.
지침에 이 규칙들을 넣어 줘. 개조식으로 쓴다. 지난주 대비 변화를 맨 앞에 둔다. 다음 주 계획을 맨 뒤에 둔다. 과장된 수식어는 뺀다. 숫자는 굵게 표시하지 않는다.
AI는 이것을 규칙 문장으로 정리해 되돌려 준다.
지침
1. 전체를 개조식으로 작성한다.
2. 문서 첫머리에 지난주 대비 변화를 정리한다.
3. 본문에 이번 주 실적을 항목별로 적는다.
4. 문서 끝에 다음 주 계획을 둔다.
5. 과장된 수식어를 쓰지 않고, 숫자는 굵게 강조하지 않는다.
되돌아온 문장을 읽어 보고, 빠진 조건이 있으면 덧붙인다. 이 단계에서 규칙이 대여섯 줄을 크게 넘어가면, 스킬 하나에 너무 많은 일을 담고 있는 신호일 수 있다. 그럴 때는 하나의 스킬을 둘로 쪼개는 편이 낫다.
쪼개는 기준이 필요할 때 떠올릴 것은 하나의 스킬이 담는 최소 단위다. 잘 만든 스킬 하나는 업무 하나, 그 업무를 쓰는 조건 하나, 결과물의 출력 형식 하나, 결과를 확인하는 검수 기준 하나로 이루어진다. 주간 보고 형식 정리 스킬로 보면, 업무는 주간 보고 정리이고, 조건은 매주 월요일 팀 보고를 만들 때이며, 형식은 개조식에 변화를 앞세운 구성이고, 검수 기준은 지난주 대비 변화와 다음 주 계획이 빠지지 않았는지다. 이 네 가지가 하나씩 또렷하면 스킬 하나로 충분하다. 그런데 지침을 적다 보니 보고서도 담고 회의록도 담고 이메일도 담게 된다면, 업무가 여러 개로 늘어난 것이니 각각을 따로 떼어 낸다. 하나의 스킬에는 하나의 일만 담는 것이 원칙이다.
네 번째 단계는 참고 자료를 붙이는 것이다. 규칙만으로 부족한 경우, 실제 예시나 양식을 함께 넣어 두면 결과가 안정된다. 잘 쓴 지난주 보고서 한 편, 회사 표준 양식 문서 같은 것이 참고 자료가 된다. AI는 규칙을 따르면서 이 예시의 결과 모양을 참고한다. 다만 이 자리에 민감 정보를 넣지 않도록 주의한다. 앞 장에서 짚은 대로, 실적 수치나 개인정보가 든 문서보다는 형식만 담긴 예시를 고른다. 입력은 이렇게 준다.
이 양식을 참고 자료로 넣어 줘. 실제 숫자는 뺀 형식 예시야.
(이어서 숫자를 지운 지난주 보고서 뼈대를 붙여 넣는다)
AI는 이 예시를 규칙과 함께 참고하겠다고 확인해 준다. 규칙이 말로 다 담기 어려운 미묘한 형식, 예컨대 항목 사이 여백이나 소제목의 말투 같은 것은 이 예시가 대신 보여 준다. 규칙은 무엇을 지킬지 알려 주고, 예시는 그 결과가 어떻게 생겼는지 보여 주는 셈이다. 둘이 함께 있으면 결과가 한결 안정된다. 참고 자료가 필요 없는 단순한 스킬이라면 이 단계는 건너뛰어도 된다. 예시가 없다고 스킬이 작동하지 않는 것은 아니다.
다섯 번째 단계는 저장한 뒤 시험하는 것이다. 앞의 네 단계를 거치면 이름, 설명, 지침, 참고 자료가 하나의 스킬 폴더로 묶인다. 제품이 설치 또는 등록 절차를 제공한다면 그 절차를 마친다. 단, 저장됐다는 확인만으로는 완성이 아니다. 실제 요청 세 가지에서 원하는 스킬이 선택되고, 피해야 할 요청 두 가지에서는 선택되지 않아야 한다. 이 시험을 통과해야 첫 스킬이 완성된 것이다.
여기까지 오는 데 코드는 한 줄도 쓰지 않았다. 다섯 단계를 다시 짚으면, 프롬프트를 보여 주고, 이름과 설명을 정하고, 지침을 정리하고, 예시를 붙이고, 저장한 뒤 시험했다. 한 일은 평소처럼 말로 요청하고, 돌아온 초안을 읽고, 어색한 곳을 고친 것뿐이다.
프롬프트를 스킬로 바꾸는 다섯 단계
그림 3-1. 업무 선택에서 저장·시험까지의 전체 제작 과정.
완성본을 먼저 보자
대화가 끝나면 AI는 아래와 같은 설명서를 만든다. 기호를 외울 필요는 없다. 지금은 언제 쓰는지, 어떻게 일하는지, 무엇을 확인하는지가 분리되어 있다는 점만 보면 된다.
--- name: weekly-report-format description: 팀 주간 보고 초안을 회사 표준 형식으로 정리할 때 사용한다. 회의록이나 월간 실적 보고에는 사용하지 않는다. --- # 주간 보고 정리 ## 작업 순서 1. 입력에서 지난주 대비 변화를 찾는다. 2. 이번 주 실적을 항목별로 묶는다. 3. 다음 주 계획을 마지막에 배치한다. ## 출력 규칙 - 전체를 개조식으로 작성한다. - 과장된 수식어를 빼고 숫자를 굵게 표시하지 않는다. - 입력에 없는 수치나 결정은 만들지 않는다. ## 최종 점검 - 지난주 대비 변화가 첫머리에 있는가? - 다음 주 계획이 빠지지 않았는가? - 원문에 없는 내용을 추가하지 않았는가?
이 예시에는 좋은 스킬이 갖추는 실전 장치가 하나 더 있다. 단순한 작성 규칙에서 끝나지 않고, “입력에 없는 내용을 만들지 않는다”는 안전장치와 세 가지 최종 점검을 넣었다. 좋은 스킬은 일을 시키는 설명서인 동시에 실수를 막는 체크리스트다.
3-3. 첫 실행과 확인
스킬을 만들었으면 잘 작동하는지 확인해야 한다. 만들었다는 사실과 실제로 쓰인다는 사실은 다르기 때문이다. 시험은 제품이 스킬을 선택하는 방식에 맞춰 두 갈래로 한다.
자동 선택을 지원하는 환경에서는 이름을 부르지 않고 평소처럼 요청한다. “이번 주 주간 보고 초안 만들어 줘.” 매번 설명하던 형식과 톤이 반영된다면 스킬이 제대로 선택된 것이다. 명시 호출을 중심으로 하는 환경에서는 스킬 목록에서 weekly-report-format을 선택하거나 제품이 정한 호출 문법으로 지정한다. 이때의 핵심은 자동이냐 수동이냐가 아니다. 반복 규칙을 다시 붙여 넣지 않고도 같은 결과가 나오는가다.
어떤 스킬을 썼는지 표시하는 제품이라면 실행 기록이나 인터페이스에서 확인한다. 표시가 없다면 결과를 받은 뒤 어떤 스킬과 지침을 참고했는지 물어볼 수 있다.
방금 이 결과를 만들 때 어떤 스킬을 참고했어?
다만 AI의 사후 설명만 믿지는 않는다. 가장 확실한 증거는 결과다. 매번 붙이던 조건을 이번에는 주지 않았는데도 지켜졌는지 체크리스트로 확인한다. 조건이 빠졌다면 자동 선택 환경에서는 설명을 손보고, 명시 호출 환경에서는 설치 위치와 선택 여부부터 확인한다.
여기서 한 가지를 구분해 둘 필요가 있다. 스킬이 불려 나온 것과, 결과물이 마음에 드는 것은 다른 문제다. 스킬은 제대로 참조됐는데 결과의 특정 부분이 아쉬울 수 있다. 그럴 때는 발동을 의심하기보다 지침을 손보는 쪽이 맞다. 발동은 설명이 정하고, 결과의 세부는 지침이 정한다. 이 둘을 갈라 보면 어디를 고쳐야 할지 헷갈리지 않는다. 확인 단계에서 이 구분에 익숙해져 두면, 이후 스킬을 다듬는 일이 훨씬 수월해진다.
한 번 확인이 됐다고 끝은 아니다. 이번 주에는 잘 됐는데 다음 주에는 안 불려 나오는 경우가 있다. 요청 문장이 조금 달라지면 발동이 어긋날 수 있기 때문이다. 그래서 몇 번은 서로 다른 표현으로 같은 일을 시켜 보는 것이 좋다. 주간 보고 만들어 줘, 이번 주 보고서 정리해 줘, 월요일 보고 초안 잡아 줘처럼 표현을 바꿔 가며 시켜 본다. 어느 표현에도 안정적으로 불려 나오면 믿을 만한 스킬이다. 특정 표현에만 반응한다면 손볼 곳이 있다는 뜻이고, 그 손보는 방법은 다음 절에서 실패 사례로 다룬다.
3-4. 처음에 겪는 두 가지 실패
첫 스킬을 만들면 대개 두 가지 문제 중 하나를 겪는다. 미리 알아 두면 당황하지 않고 고칠 수 있다. 두 문제 모두 잘못 만든 것이 아니라, 처음엔 자연스럽게 지나는 단계에 가깝다.
첫 번째 실패는 스킬이 불려 나오지 않는 것이다. 분명히 만들었는데, 관련 요청을 던져도 스킬이 참조되지 않는다. 매번 설명하던 조건이 결과에 빠져 있다. 원인은 대개 설명에 있다. 두 번째 단계에서 적은 설명이 모호하면, AI가 지금 요청에 이 스킬이 맞는지 판단하지 못한다. 예를 들어 설명을 그냥 보고서 정리라고만 적어 두면, 이번 요청이 그 보고서인지 아닌지 가늠하기 어렵다.
고치는 방법은 설명을 더 구체적으로 다시 쓰는 것이다. 언제 쓰는 스킬인지, 어떤 요청이 오면 꺼내야 하는지를 설명에 분명히 담는다. 매주 팀 주간 보고 초안을 정리할 때처럼 상황을 또렷하게 적으면 발동이 안정된다. 고칠 때는 AI에게 직접 부탁해도 된다. 이 스킬이 잘 안 불려 나오니 설명을 더 구체적으로 다시 써 달라고 하면, 발동에 유리한 방향으로 설명을 다듬어 준다. 다듬은 설명을 확인하고 저장하면 된다. 발동 문제는 이 책에서 따로 한 장을 들여 다룰 만큼 중요한 주제라, 더 깊은 조정은 6장에서 이어 다룬다. 지금은 설명을 구체적으로 고치는 선에서 대부분 해결된다는 것만 기억하면 된다.
두 번째 실패는 결과가 매번 조금씩 달라지는 것이다. 스킬은 불려 나오는데, 어떤 날은 개조식으로 잘 나오다가 어떤 날은 줄글로 나온다. 톤도 오락가락한다. 원인은 대개 지침에 형식 규칙과 판단 규칙이 섞여 있는 데 있다. 세 번째 단계에서 지침을 적을 때, 개조식으로 쓴다 같은 형식 규칙과 중요도가 낮은 항목은 생략한다 같은 판단 규칙을 한데 뒤섞으면, AI가 둘을 헷갈려 어떤 날은 형식을 놓치고 어떤 날은 판단을 놓친다.
고치는 방법은 둘을 갈라 적는 것이다. 형식에 관한 규칙을 한 묶음으로, 판단에 관한 규칙을 다른 묶음으로 나눈다. 형식은 결과물의 모양에 관한 것이고, 판단은 무엇을 넣고 뺄지에 관한 것이다. 개조식으로 쓴다, 변화를 맨 앞에 둔다 같은 것은 형식이다. 중요도가 낮은 항목은 생략한다, 수치가 없는 항목은 다음 주 계획으로 미룬다 같은 것은 판단이다. 지침을 다시 정리해 달라고 하면서 형식 규칙과 판단 규칙을 나눠 적어 달라고 부탁하면, AI가 두 묶음으로 갈라 준다. 이렇게 나눠 두면 AI가 각각을 따로 지키기 쉬워져, 결과가 한결 고르게 나온다. 나누는 습관은 나중에 스킬을 손볼 때도 도움이 된다. 결과가 이상할 때 형식이 문제인지 판단이 문제인지 짚기 쉬워지기 때문이다.
두 실패에는 공통점이 있다. 둘 다 만들 때 대충 넘긴 자리에서 나온다. 설명을 대충 적으면 발동이 안 되고, 지침을 섞어 적으면 결과가 흐트러진다. 두 실패가 어느 자리에서 오는지 알면, 문제를 만났을 때 어디를 볼지가 정해진다. 결과가 아예 안 나오면 설명을 보고, 결과는 나오는데 들쭉날쭉하면 지침을 본다. 이 대응만 기억해도 첫 스킬을 다듬는 대부분의 상황을 넘길 수 있다.
그래서 이 두 자리, 설명과 지침은 처음 만들 때 조금 더 공들일 값어치가 있다. 그렇다고 처음부터 완벽할 필요는 없다. 만들고, 돌려 보고, 걸리는 자리를 고치는 것이 스킬을 다듬는 정상적인 흐름이다. 오히려 한 번에 완벽하게 만들려다 시작을 미루는 것이 더 큰 손해다. 대충이라도 하나 만들어 돌려 보면, 무엇이 부족한지가 머릿속 상상보다 훨씬 또렷하게 드러난다.
3-5. 방금 만든 것의 정체
여기까지 왔다면 첫 스킬이 손에 있다. 그 스킬이 대체 무엇인지 잠시 짚고 넘어간다. 방금 만든 것은 네 가지의 묶음이다. 이 스킬이 언제 쓰이는지 알려 주는 이름과 설명, 어떻게 하는지 적힌 지침, 그리고 참고할 예시 자료다. 흩어져 있던 재료가 이 네 자리에 나뉘어 담긴 것이다.
이 묶음은 사람만 읽는 메모가 아니다. AI가 읽을 수 있도록 정해진 형식으로 정리되어 있다. 겉으로는 대화로만 만들었지만, 저장된 결과물은 일정한 틀을 갖춘 작업 설명서 형식이다. 이 사실을 굳이 밝히는 이유는, 코드를 쓰지 않는다는 말이 파일 같은 것은 아예 없다는 뜻으로 오해되기 쉽기 때문이다. 파일 형식은 분명히 있다. 다만 그 형식을 직접 손으로 편집할 일은 드물다. 필요한 수정은 대부분 지금까지처럼 대화로 처리할 수 있다.
이 구분이 왜 중요한지는 앞 장의 진단과 이어진다. 메모장의 프롬프트가 대화창 안에서 증발하던 이유는, 그것이 사람이 찾아 붙여 넣어야 하는 개인 메모였기 때문이다. 방금 만든 스킬은 다르다. AI가 읽는 자리에 정해진 형식으로 설치되므로, 자동 선택되거나 짧은 이름으로 호출되어 같은 규칙을 두고두고 쓸 수 있다. 첫 스킬 하나로 이 차이를 몸으로 확인한 셈이다.
방금 만든 것의 정체를 이렇게 정리해 두면, 다음 장이 자연스럽게 이어진다. 다음 장에서는 이 묶음을 해부한다. 이름, 설명, 지침, 자료가 각각 무슨 일을 하는지, 왜 이렇게 나뉘어 있는지를 뜯어본다. 방금 만든 이 스킬을 그대로 해부 대상으로 삼으니, 새 예제를 다시 익힐 필요는 없다.
한 가지 안내를 덧붙인다. 만약 앞 절의 첫 번째 실패처럼 스킬이 잘 불려 나오지 않는 문제가 계속된다면, 4장을 건너뛰고 발동을 전담해 다루는 6장으로 먼저 가도 된다. 구조를 먼저 이해하고 싶으면 순서대로 다음 장으로 가면 되고, 당장 발동부터 잡고 싶으면 6장으로 점프해도 흐름이 끊기지 않도록 해 두었다. 어느 쪽이든, 이미 첫 스킬 하나를 손에 넣었다는 사실은 바뀌지 않는다. 여기서부터는 없던 것을 배우는 일이 아니라, 가진 것을 다듬고 늘려 가는 일이다. 가장 큰 고비였던 첫 하나를 이미 넘었다.
