반복되는 프롬프트가 보내는 신호
AI를 어느 정도 써 본 사람에게는 익숙한 장면이 있다. 매번 비슷한 요청을 한다.
"이 회의록을 요약해 줘. 결정 사항과 할 일은 따로 뽑아 줘."
"이 글을 블로그 스타일로 다듬어 줘. 제목 후보도 5개 줘."
"이 코드 변경 사항을 리뷰해 줘. 버그 가능성과 테스트 누락을 봐 줘."
처음에는 프롬프트를 잘 쓰면 충분해 보인다. 하지만 같은 일을 세 번, 다섯 번 반복하다 보면 문제가 드러난다. 매번 배경을 다시 설명해야 한다. 원하는 출력 형식을 다시 써야 한다. 어떤 기준으로 판단해야 하는지도 반복해서 알려 줘야 한다. 결과물은 그날그날 조금씩 흔들린다.
이때 필요한 단위가 스킬이다.
이 책에서 스킬은 단순한 명령문이 아니다. 스킬은 특정 상황에서 반복해서 사용할 수 있는 업무 능력의 묶음이다. 그 안에는 목적, 입력 형식, 처리 단계, 사용할 도구, 판단 기준, 완료 조건이 들어간다. 사람이 매번 프롬프트에 적던 맥락을 스킬 내부로 옮기는 것이다.
AI 생성 이미지
프롬프트, 워크플로, 에이전트, 스킬의 차이
앞으로의 논의를 위해 네 가지 단어를 구분하자. 이 단어들은 현장에서 종종 섞여 쓰인다. 그래서 무엇이 더 '정답'인지 따지기보다, 이 책에서 어떤 설계 단위로 사용할지 먼저 정리해 두는 편이 좋다.
프롬프트는 한 번의 지시다. 지금 눈앞의 요청을 처리하기 위해 쓰는 문장이다. "이 문서를 요약해 줘"가 프롬프트다. 잘 쓴 프롬프트는 당장의 결과를 개선하지만, 그 자체만으로는 재사용 구조가 약하다. 저장해 두고 다시 쓸 수는 있지만, 입력값, 판단 기준, 완료 조건이 분리되어 있지 않으면 매번 조금씩 손봐야 한다.
워크플로는 일의 전체 흐름이다. 예를 들어 콘텐츠 발행 워크플로는 아이디어 수집, 초안 작성, 편집, 이미지 준비, 예약 발행, 성과 확인까지 포함한다. 워크플로는 하나의 프롬프트보다 크고, 여러 사람과 도구가 함께 움직일 수 있다.
에이전트는 판단하고 조정하는 실행 주체다. 에이전트는 무엇을 먼저 할지, 어떤 정보를 더 물어볼지, 어떤 도구를 쓸지 결정한다. 개발 보조 에이전트, 리서치 에이전트, 고객 응대 에이전트처럼 역할과 우선순위를 가진다.
스킬은 에이전트가 특정 일을 잘 수행하기 위해 꺼내 쓰는 능력 단위다. 한 비교 글에서는 프롬프트를 일회성 지시, 워크플로를 더 큰 업무 흐름, 에이전트를 판단 계층, 스킬을 반복 가능한 실행 계층으로 구분한다1. 이 구분은 완벽한 표준이라기보다 실무에서 쓸 만한 지도에 가깝다.
간단히 말하면 이렇다.
| 구분 | 핵심 질문 | 예시 |
|---|---|---|
| 프롬프트 | 지금 무엇을 시킬까? | "이 메일을 정중하게 고쳐 줘." |
| 워크플로 | 일이 어떤 순서로 진행될까? | 문의 접수 → 분류 → 답변 초안 → 승인 → 발송 |
| 에이전트 | 누가 판단하고 실행할까? | 고객 지원 에이전트, 코드 리뷰 에이전트 |
| 스킬 | 어떤 반복 능력을 재사용할까? | 환불 문의 답변 스킬, PR 리뷰 스킬 |
이 책의 중심은 스킬이다. 에이전트를 만드는 법을 다루지만, 출발점은 거대한 자율 시스템이 아니다. 반복 가능한 작은 능력을 설계하고, 검증하고, 조합하는 방식이다.
스킬은 맥락을 내부로 옮긴다
좋은 스킬은 사용자가 매번 설명하던 내용을 내부 구조로 옮긴다. 예를 들어 "회의록 정리 스킬"을 만든다고 해 보자.
매번 이런 프롬프트를 썼다면,
아래 회의 내용을 요약해 줘. 핵심 결정 사항, 담당자별 할 일, 다음 회의 전 확인할 이슈를 표로 정리해 줘. 애매한 내용은 확정된 것처럼 쓰지 말고 '확인 필요'로 표시해 줘.
스킬로 만들 때는 다음처럼 쪼갠다.
목적: 회의 기록에서 결정 사항과 후속 작업을 분리한다.
입력값: 회의 전문, 참석자 목록, 프로젝트명, 회의 날짜.
처리 단계: 안건 파악 → 결정 사항 추출 → 할 일 추출 → 담당자 연결 → 모호한 항목 표시.
출력물: 요약문, 결정 사항 표, 액션 아이템 표, 확인 필요 목록.
트리거: 사용자가 회의록, 미팅 노트, 녹취록 요약을 요청할 때.
제약조건: 원문에 없는 결정을 만들지 않는다. 담당자가 불명확하면 임의 배정하지 않는다.
검증 기준: 모든 액션 아이템에 담당자 또는 "미정" 표시가 있어야 한다. 날짜가 없으면 "기한 미정"으로 표시한다.
이렇게 바꾸면 사용자는 매번 긴 설명을 반복하지 않아도 된다. 에이전트는 "회의록 정리"라는 상황을 만나면 이 스킬을 불러와 같은 기준으로 처리할 수 있다.
중요한 점은 자동화만이 아니다. 더 본질적인 변화는 설계의 이동이다. 사람의 머릿속에 있던 업무 기준을 스킬 안으로 옮긴다. 그 기준이 명확할수록 결과물은 안정된다.
실행 환경이 달라도 남는 구성 요소
Claude Code, Codex, Gemini CLI, Manus형 워크플로처럼 실행 환경은 계속 바뀐다. 어떤 도구는 파일 기반으로 스킬을 정의한다. 어떤 도구는 명령어, 설정 파일, 에이전트 역할, 플러그인 형태를 쓴다. 이름도 다르다. skill, command, agent, subagent, plugin, workflow라는 말이 섞여 쓰인다.
하지만 도구가 달라도 좋은 스킬에는 공통 요소가 남는다.
첫째, 언제 이 스킬을 써야 하는지가 분명해야 한다. 트리거가 모호하면 에이전트는 엉뚱한 상황에서 스킬을 사용하거나, 필요한 순간에 사용하지 못한다.
둘째, 무엇을 입력으로 받아야 하는지가 정해져야 한다. 원문, 파일 경로, 고객 유형, 목표 독자, 코드 diff, 데이터 테이블처럼 입력의 종류를 명시해야 한다.
셋째, 어떤 순서로 처리할지가 있어야 한다. 단계가 없으면 AI는 그럴듯한 답을 만들 수는 있지만, 결과를 재현하기 어렵다.
넷째, 판단 기준이 필요하다. 좋은지 나쁜지, 포함할지 제외할지, 위험한지 안전한지 판단하는 기준을 적어야 한다.
다섯째, 완료 조건이 있어야 한다. 출력물이 어떤 형태이면 끝난 것인지 정하지 않으면 작업은 늘어진다.
여섯째, 검증 방법이 있어야 한다. 표의 필수 열이 있는지, 인용 출처가 있는지, 테스트가 통과했는지, 금지 표현이 없는지 확인해야 한다.
여러 스킬 라이브러리도 스킬을 단순 프롬프트가 아니라 워크플로, 체크리스트, 도구, 참고 지식을 묶은 패키지로 설명한다2. 이 책도 같은 관점에서 스킬을 다룬다. 특정 플랫폼의 버튼 위치보다 오래 남는 것은 이 구조다.
스킬이 만드는 네 가지 변화
스킬을 도입하면 업무는 네 가지 방향으로 달라진다.
1. 반복 업무 자동화
가장 먼저 체감되는 변화다. 매주 하는 주간 보고서 작성, 매일 하는 고객 문의 분류, 매번 반복되는 코드 리뷰 체크리스트를 스킬로 만든다.
반복 업무 자동화에서 핵심은 "AI가 알아서 하게 하기"가 아니다. 반복되는 부분과 사람이 판단해야 하는 부분을 나누는 것이다. 예를 들어 주간 보고서 스킬은 데이터를 모으고 표준 형식으로 정리할 수 있다. 하지만 이번 주 가장 중요한 메시지가 무엇인지는 담당자가 확인해야 한다.
2. 전문 지식 캡슐화
스킬은 전문가의 기준을 담는 그릇이 될 수 있다. 예를 들어 "B2B 랜딩페이지 리뷰 스킬"에는 단순한 문장 교정이 아니라 고객 문제, 가치 제안, CTA, 신뢰 요소, 반론 처리 기준이 들어간다.
이렇게 만들면 초보자도 전문가의 체크리스트를 따라 결과물을 검토할 수 있다. 단, 전문 지식을 캡슐화한다는 말은 전문가를 대체한다는 뜻이 아니다. 반복 가능한 판단 기준을 꺼내 쓰기 쉽게 만든다는 뜻이다.
3. 팀 표준화
팀에서 같은 일을 서로 다르게 처리하면 품질 관리가 어려워진다. 어떤 사람은 회의록에 결정 사항을 잘 적지만 리스크를 빠뜨린다. 어떤 사람은 고객 답변은 빠르지만 근거 링크를 빼먹는다.
스킬은 팀의 작업 표준을 문서와 실행 절차 사이에 놓는다. 예를 들어 고객 지원 답변 스킬에 다음 기준을 넣을 수 있다.
첫 문장은 고객 상황을 인정한다.
해결 절차는 3단계 이하로 쓴다.
환불, 보안, 법무 이슈는 자동 확정하지 않고 담당자 확인으로 넘긴다.
답변 끝에는 추가 확인 질문을 하나만 둔다.
이 기준이 스킬에 들어가면 팀원마다 같은 기준으로 초안을 만들 수 있다.
4. 개인 비서화
마지막 변화는 개인화다. 스킬은 사용자의 취향과 업무 방식을 반영할 수 있다. "내 방식의 독서 노트 정리", "내 말투의 이메일 답장", "내 우선순위에 맞춘 하루 계획"처럼 개인의 반복 패턴을 담는다.
여기서 중요한 것은 사생활과 권한 관리다. 개인 비서형 스킬은 많은 맥락을 다루기 쉽다. 일정, 연락처, 업무 파일, 대화 기록을 사용할 수 있다면 편리하지만, 그만큼 잘못된 실행의 비용도 커진다. 따라서 개인 비서형 스킬에는 항상 접근 범위와 확인 단계가 필요하다.
좋은 스킬의 짧은 예
다음은 이 책에서 다룰 방식의 간단한 스킬 예시다.
스킬 이름: 고객 문의 1차 분류
목적: 새로 들어온 고객 문의를 빠르게 분류하고, 긴급도와 다음 조치를 제안한다.
입력값
고객 문의 원문
고객 등급
제품명
최근 장애 여부
처리 단계
문의 의도를 하나로 요약한다.
유형을 결제, 오류, 사용법, 환불, 보안, 기타 중 하나로 분류한다.
긴급도를 높음, 보통, 낮음으로 표시한다.
자동 답변 가능한지 판단한다.
사람 확인이 필요한 이유가 있으면 따로 적는다.
출력물
| 항목 | 내용 |
|---|---|
| 문의 요약 | 1문장 |
| 분류 | 결제/오류/사용법/환불/보안/기타 |
| 긴급도 | 높음/보통/낮음 |
| 추천 조치 | 자동 답변/담당자 확인/긴급 에스컬레이션 |
| 확인 필요 | 근거 또는 빈칸 |
제약조건
환불 가능 여부를 확정하지 않는다.
보안 사고 가능성이 있으면 긴급도를 낮음으로 표시하지 않는다.
고객에게 보낼 문장과 내부 메모를 섞지 않는다.
이 정도만 있어도 프롬프트보다 훨씬 안정적인 작업 단위가 된다.
변형 아이디어
하나의 스킬은 여러 방향으로 변형할 수 있다.
고객 문의 분류 스킬은 "VIP 고객 우선 대응 스킬"로 바꿀 수 있다. 이때는 고객 등급, 계약 규모, SLA 같은 기준이 추가된다.
또는 "장애 상황 문의 분류 스킬"로 바꿀 수 있다. 이때는 최근 배포 내역, 장애 공지 여부, 영향 범위 확인이 중요해진다.
또는 "답변 초안 생성 스킬"과 연결할 수 있다. 분류 스킬이 문의 유형과 긴급도를 정하면, 답변 스킬이 고객에게 보낼 문장을 만든다.
이처럼 스킬 설계의 장점은 작은 능력을 조합할 수 있다는 데 있다. 처음부터 거대한 에이전트를 만들 필요는 없다. 작고 검증 가능한 스킬을 만든 뒤, 필요한 만큼 이어 붙이면 된다.
실패 패턴
초보자가 가장 자주 하는 실수는 스킬을 긴 프롬프트 저장소로만 보는 것이다. "친절하게 답해 줘", "전문가처럼 분석해 줘", "잘 정리해 줘" 같은 말만 있으면 스킬이 아니라 말투 지시문에 가깝다.
두 번째 실수는 트리거가 없는 스킬이다. 언제 사용해야 하는지 적지 않으면 에이전트가 스킬을 선택하기 어렵다.
세 번째 실수는 완료 조건이 없는 스킬이다. 결과물이 표인지, 목록인지, 파일인지, 보고서인지 정하지 않으면 매번 출력이 달라진다.
네 번째 실수는 사람의 승인 지점을 빼는 것이다. 결제 취소, 법적 판단, 보안 조치, 고객 약속, 데이터 삭제 같은 일은 자동 실행 전에 확인이 필요하다.
다섯 번째 실수는 모든 일을 하나의 스킬에 넣는 것이다. "마케팅 전체 자동화 스킬"은 너무 크다. "광고 소재 성과 요약", "랜딩페이지 문구 리뷰", "고객 후기 재가공"처럼 작게 나눠야 한다.
이 책에서 다룰 설계 단위
이 책은 "잘 만든 스킬 30개"를 해부하고 변형하는 방식으로 진행된다. 각 스킬은 다음 질문에 답해야 한다.
어떤 문제 상황에서 쓰는가?
입력값은 무엇인가?
어떤 단계로 처리하는가?
어떤 도구나 자료를 참고하는가?
어떤 판단 기준을 적용하는가?
출력물은 어떤 형태인가?
실패를 어떻게 감지하는가?
사람이 개입해야 하는 지점은 어디인가?
프롬프트를 잘 쓰는 능력은 여전히 중요하다. 하지만 다음 단계는 프롬프트를 매번 새로 쓰는 것이 아니라, 반복되는 업무 능력으로 정리하는 것이다.
스킬은 단지 AI에게 일을 맡기기 위한 실행 단위가 아니다. 사람이 자신의 업무 기준을 명확히 하기 위한 설계 단위다. 이 관점이 이 책의 출발점이다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.