프롬프트 팩의 시대는 끝났다. 기술의 시대가 온다

무료 나눔

"REVOPS ROCKS"라고 댓글을 달아주시면 제가 만든 350개의 커스텀 프롬프트를 DM으로 보내드리겠습니다.

여러분은 이미 수백 번도 더 지나쳤을 것입니다. 제 리스트에 가입해서 수십억 개의 프롬프트를 받으세요. 스와이프 파일(swipe file)을 원하시면 "GROWTH"라고 댓글을 다세요. 저는 RevOps를 혁신했습니다. 제 Slack 커뮤니티에 가입하여 이를 증명하는 350개의 프롬프트를 받아보세요. 프롬프트는 제품이 아닙니다. 그것은 미끼입니다. 누군가는 당신을 리스트에 올리고 싶어 하며, 엄청난 숫자의 미끼로 낚시를 하고 있는 것입니다.

그래서 당신은 댓글을 답니다. DM이 도착합니다. PDF를 열어보면 350개의 프롬프트가 다음과 같이 적혀 있습니다:

RevOps 리더로서 행동하며 파이프라인 위생(pipeline hygiene)에 관한 LinkedIn 게시물을 작성하세요.
RevOps 리더로서 행동하며 예측 정확도(forecast accuracy)에 관한 LinkedIn 게시물을 작성하세요.
RevOps 리더로서 행동하며 리드 라우팅(lead routing)에 관한 LinkedIn 게시물을 작성하세요.

같은 프롬프트입니다. 명사만 다를 뿐입니다.

작가는 동일한 세 가지 공식을 사용하여 AI로 한 번에 파일 전체를 생성했으며, 숫자가 제안의 가치를 뒷받침하도록 만들었습니다. "커스텀"이라는 말은 문장의 주제를 바꾸는 것을 의미했습니다. 파이프라인(Pipeline). 예측(Forecast). 라우팅(Routing). 이탈(Churn). 온보딩(Onboarding).

그것은 프롬프트 엔지니어링 (Prompt Engineering)이 아니었습니다. 그것은 프롬프트 인플레이션 (Prompt Inflation)이었습니다. 350개의 프롬프트 스와이프 파일은 라이브러리가 아닙니다. 그것은 리드 캡처(lead-capture) 양식이 결합된 메일 머지 (mail merge)일 뿐입니다.

역사가 아닌 구축(build)을 위해 오셨나요? 실제 기술(Skill)로 바로 건너뛰세요. 하지만 역사는 단순한 채우기용이 아닙니다. 프롬프팅이 어떻게 이렇게 취약해졌는지는 새로운 AI가 배후에서 작동하는 방식과 동일한 이야기입니다. 계속 읽어보시면 설계 선택들이 더 이상 임의적으로 보이지 않을 것입니다.

약어의 수프

좋은 프롬프트 작성은 몇 가지 간단한 포인트로 귀결되었습니다. 어쨌든 모두가 자신만의 프레임워크를 만들어냈습니다. RTF, RACE, BFD, WTF 등 말이죠.

진짜 핵심적인 것들은 대략 다음과 같습니다:

• RTF: 역할(Role), 작업(Task), 형식(Format).
• CTF: 맥락(Context), 작업(Task), 형식(Format).
• RACE: 역할(Role), 행동(Action), 맥락(Context), 기대치(Expectation).
• CO-STAR: 맥락(Context), 목적(Objective), 스타일(Style), 어조(Tone), 대상(Audience), 응답(Response).
• CREATE: 캐릭터(Character), 요청(Request), 예시(Examples), 조정(Adjustments), 유형(Type), 추가 사항(Extras).

그 후 APE, CARE, CLEAR, ICIO, 그리고 몇 주마다 새로운 것들이 등장했습니다.

이것들을 쌓아보면 요령이 드러납니다. 그것들은 냉장고 자석처럼 동일한 9가지 재료를 재배치할 뿐입니다:

• 역할 (Role). AI가 답변하는 입장입니다. 동일한 세무 질문이라도 "CFO로서" 답변하는 것과 "감사관으로서" 답변하는 것은 전혀 다릅니다. 역할은 AI가 단 하나의 사실을 읽기 전부터 모든 것을 프레임화합니다.
• 맥락 (Context). 답변이 맞춰져야 하는 상황입니다. 이를 생략하면 AI는 공백을 평균적인 사례로 채우게 되는데, 이는 귀하의 상황과 일치하는 경우가 거의 없습니다.
• 작업 (Task). 실제 동사입니다. 쓰기, 순위 매기기, 진단하기, 다시 쓰기 등입니다. "이것 좀 도와줘"라고 하면 형편없는 결과가 돌아옵니다. 날카로운 동사를 사용해야 날카로운 결과물 (deliverable)이 돌아옵니다.
• 대상 (Audience). 결과물을 읽는 사람입니다. 이사회 메모와 Slack 메시지는 동일한 사실을 담고 있더라도 문장 구조는 거의 공유되지 않습니다. 독자를 지정하면 어휘, 깊이, 그리고 생략해도 되는 부분이 결정됩니다.
• 목표 (Goal). 출력물이 달성해야 하는 것이며, 이는 작업 (task)과는 다릅니다. 작업이 "후속 이메일 쓰기"라면, 목표는 "회의 잡기"입니다. 목표를 명시하면 AI는 글자 수가 아닌 목표를 위해 최적화합니다.
• 톤 (Tone). 어조입니다. 직설적, 따뜻함, 격식 있음, 반대 의견 제시 등입니다. 이를 건너뛰면 누구나 사용하는 것과 다를 바 없는 기본 설정 (default)의 결과물을 얻게 됩니다.
• 형식 (Format). 답변의 형태입니다. 표, 불렛 포인트, 두 개의 단락, JSON 등입니다. 형식이 잘못되면 귀하가 건너뛰려 했던 바로 그 작업인 '재구성 작업'을 직접 해야 합니다.
• 제약 사항 (Constraints). 울타리입니다. 글자 수, 피해야 할 것, 절대 주장해서는 안 되는 것, 신뢰해야 할 출처 등입니다. 제약 사항을 준수하면 그 어떤 영리한 문구보다 품질을 높여줍니다. 하지만 긴 프롬프트 속에 묻혀 있으면 가장 먼저 무시됩니다.
• 예시 (Examples). 좋은 결과물이 어떤 모습인지 보여주는 샘플입니다. 잘 작동하는 예시 하나가 기준을 설명하는 한 단락보다 AI에게 더 많은 것을 가르쳐줍니다. 기준을 주장하는 대신 기준점 (bar)을 직접 보여주기 때문입니다. 다만, AI가 예시를 대본으로 착각하여 귀하의 예시를 그대로 토씨 하나 틀리지 않고 돌려주기 전까지만 유효합니다.

모두 훌륭한 재료들입니다. 이러한 프레임워크들은 진정한 교훈을 주었으며, 그 가치를 충분히 인정받았습니다.

하지만 그것들은 원샷 프롬프팅 (one-shot prompting)에만 유효했습니다. 새로 타이핑하거나, 스와이프 파일 (swipe file)에서 복사해 붙여넣거나, 커스텀 GPT (custom GPT)나 Gemini Gem에 로드하든 상관없습니다. 프롬프트가 어떤 방식으로 전달되든 그 형태는 동일합니다. 즉, 하나의 입력, 하나의 출력, 그리고 끝입니다. 그 시대는 저물고 있습니다.

지형이 변했다

백만 년 전, 즉 작년까지만 해도 잘 작동하는 프롬프트는 금값과 맞먹는 가치가 있었습니다. 좋은 프롬프트들은 스크린샷으로 찍히고 수집되며 사람에서 사람으로 전달되었습니다. 하지만 그 금값 같은 프롬프트들도 어쨌든 15~20%의 확률로 오작동했으며, 프롬프트의 복잡도가 높아질수록 그 오류율은 상승했습니다. 보관할 가치가 있는 프롬프트는 복잡한 것들이었기에, 역설적으로 가장 귀하게 여겨지는 프롬프트들이 가장 자주 실패했습니다.

사람들은 완벽한 프롬프트를 만들기 위해 몇 주를 쏟아부었습니다.

• 프롬프트를 작성하고, 지침을 잘못 해석하는 것을 지켜본 뒤, 해당 줄을 수정합니다.
• 다시 실행하고, 다른 지침을 무시하는 것을 지켜본 뒤, 그 부분을 '중요 (IMPORTANT)'로 감쌉니다.
• 다시 실행하고, 대문자를 사용해보고, 그다음엔 굵게(bold) 만들고, 그다음엔 '절대로 (DO NOT)'와 '결코 (NEVER)'를 붙입니다.

... 결국 지침은 마치 협박 편지처럼 변해버립니다. 모든 수정 사항은 프롬프트를 더 길게 만들었고, 이는 기대 사항 중 하나라도 놓칠 가능성을 높였습니다. AI는 마치 무작위인 것처럼 지침을 무시하기 시작합니다. 중요한 문장을 보호하기 위해 추가한 수정 사항들이 오히려 그 문장들을 파묻어 버립니다. 결국 프롬프트는 어느 정도 작동하게 됩니다. 그러다 다음 LLM 모델이 출시되면, 모델이 동일한 단어를 조금 다르게 해석하게 되고, 프롬프트는 이제 망가져 버립니다.

완벽함은 프롬프트 안에 존재하지 않았습니다. 그것은 특정 버전의 특이점(quirks) 속에 존재했을 뿐이며, 다음 업그레이드가 이루어지면 만료되었습니다. 프롬프트는 제조사가 계속해서 다시 깎아내는 자물쇠에 맞추기 위해 갈아낸 열쇠와 같았습니다.

세 가지 변화가 그 무게를 실어 나릅니다:

1. **추론 모델 (Reasoning models)**은 답변하기 전에 더 오래 생각합니다.
2. **에이전트 (Agents)**는 다단계 목표를 추구하며, 언제 도구 (tool)를 사용할지 스스로 결정합니다.
3. **스킬 (Skills)**은 워크플로 (workflow)를 보존하여 AI가 매번 동일한 방식으로 실행하도록 합니다.

이번 분기 마케팅에서 무엇이라 부르든 상관없습니다. 명칭은 계속 바뀌지만, 변화의 본질은 바뀌지 않습니다. 이제 AI는 스스로 훨씬 더 많은 과업을 수행합니다.

따라서 오래된 질문은 힘을 잃습니다.

과거의 질문: 어떤 프롬프트를 입력해야 하는가?

새로운 질문: AI가 어떤 프로세스 (process)를 따라야 하는가?

저장할 가치가 있는 진짜 프롬프트

한 팀은 LinkedIn 구매 여정 감사 (buyer-journey audit) 프롬프트를 보유하고 있었습니다. 이 프롬프트는 5단계 구매 인지 프레임워크 (buyer-awareness framework)를 기준으로 고객의 게시물을 평가하고, 초기 인터뷰 (intake interview)를 수행하며, 프레임워크를 고객의 비즈니스에 맞게 변환하고, 확인 단계에서 게이트 (gate)를 거친 뒤 게시물을 감사했습니다. 한 가지 규칙이 눈에 띄었는데, 분석 데이터가 담긴 CSV 파일만으로는 충분하지 않다는 점이었습니다. 감사를 위해서는 게시물 텍스트가 반드시 필요했습니다.

그 프롬프트는 이미 동급의 다른 프롬프트들을 압도했습니다. 시퀀스 (sequence), 게이트 (gates), 그리고 무언가를 분류하기 전에 멈춰서 질문하는 판단력을 갖추고 있었기 때문입니다.

하지만 그것은 여전히 프롬프트에 머물러 있었습니다. 다음 고객을 위해 문서에서 복사하여 붙여넣을 수는 있었지만, 이전 고객을 지칭하는 모든 줄을 일일이 수동으로 수정해야 했으며, 프롬프트에 내장된 규칙을 강제할 수 있는 수단도 없었습니다. 수정 과정에서 CSV 규칙을 다시 명시하는 것을 잊어버리면 그 규칙은 사라져 버렸습니다. 프롬프트는 아무것도 기억하지 못했습니다. 기억하는 것은 오직 당신뿐이었습니다.

그 프롬프트가 의존하고 있었던, 모든 것의 중추 역할을 하는 프레임워크는 다음과 같습니다:

1단계 인지 못함 (Unaware)        구매자가 문제의 존재를 모름.
2단계 문제 인지 (Problem-aware)  구매자가 고통을 느끼지만 원인을 명명하지 못함.
3단계 해결책 인지 (Solution-aware) 구매자가 접근 방식이 존재함을 알고 방법을 비교함.
...

프롬프트는 문장 하나로 이 5단계를 명시할 수 있습니다. 하지만 스킬 (Skill)은 도달 범위 (reach)가 파이프라인 (pipeline)을 전혀 만들어내지 못할 때 각 단계에서 무엇을 해야 하는지, 그리고 무엇을 거부해야 하는지를 반드시 알고 있어야 합니다. 그 격차가 바로 이 글의 핵심입니다.

프롬프트를 홍보할 가치가 있게 만드는 것

프롬프트가 다음과 같은 요소를 갖출 때 비로소 스킬 (Skill)로 졸업하게 됩니다:

• 한 번 이상 반복해서 실행하는 작업.
• AI가 시작하기 전에 반드시 수집해야 하는 필수 정보 (intake).
• 알려진 시퀀스 (sequence).
• 명시할 가치가 있는 실패 모드 (failure modes).
• 재사용 가능한 프레임워크 (framework).
• 구조화된 출력 (structured output).
• 품질 기준 (quality bar).
• 아무도 처음부터 다시 해결할 필요가 없는 예외 케이스 (edge cases).

LinkedIn 감사 프롬프트는 모든 항목을 충족했습니다. 이 작업의 목적은 아이디어를 생성하는 것이 아니라, 진단 (diagnostic)을 수행하는 것이었습니다.

그래서 저는 이를 linkedin-buyer-journey-auditor라는 이름의 스킬 (Skill)로 패키징하여, 어떤 컨설턴트라도 어떤 고객에게든 실행할 수 있도록 만들었습니다. 구조는 다음과 같습니다:

linkedin-buyer-journey-auditor/
├── SKILL.md
├── references/
...

이 중 어느 것도 이국적이거나 특별한 것이 아닙니다. 이 모든 것들은 단 한 번 작동하는 프롬프트와 매번 작동하는 워크플로우 (workflow)를 구분 짓는 요소들입니다.

Layer 1: 운영자가 주체라고 가정하는 것을 멈춰라

원래의 프롬프트는 "내 LinkedIn 콘텐츠를 감사해줘"라고 말했습니다. 하지만 이 스킬 (Skill)은 누구든 감사할 수 있습니다. my라는 그 한 단어가 재사용을 목적으로 설계된 프롬프트에 가정을 심어버린 것입니다.

SKILL.md는 이를 제거하며 시작합니다.

## 사용 시점 (When to use)
컨설턴트, 에이전시 또는 창업자가 특정 개인이나 기업의 LinkedIn 콘텐츠를 구매자 관점에서 감사해야 할 때 실행하십시오.
...

이 두 번째 블록은 보이는 것보다 훨씬 중요합니다. 일회성 프롬프트는 "지금 바로 1단계, 질문 1부터 시작해"라고 말했습니다. 이는 단 하나의 대화에만 속하는 내용입니다. 반면 스킬 (Skill)은 대신 진입 조건 (entry condition)을 명시하므로, 운영자가 이미 진행 중인 어느 지점에서든 바로 이어갈 수 있습니다.

Layer 2: AI가 건너뛸 수 없는 인테이크 (intake)

프롬프트는 문맥 (context)을 요청하고 희망 사항을 말합니다. 스킬 (Skill)은 입력값 (inputs)을 스키마 (schema)로 정의하며, 입력값이 없으면 진행을 거부합니다.

# assets/intake-schema.yaml
required:
  client_name:        string   # 감사 대상자
...

6개의 필드와 2개의 거부 규칙이 있습니다. sales_cycle_days 필드는 단순한 장식이 아닙니다. 14일짜리 판매 사이클은 중간 과정이 다소 빈약해도 견딜 수 있습니다. 하지만 9개월짜리 엔터프라이즈 (enterprise) 판매는 중간 단계에서 무너지기 때문에, 스킬 (Skill)은 판매 사이클이 길어질 경우 3단계와 4단계의 가중치를 더 높게 설정합니다. 스킬 (Skill)은 필드를 읽고 스스로 조정합니다. 프롬프트였다면 그냥 무시했을 것입니다.

Layer 3: 프레임워크를 번역한 후, 멈춰서 확인하라

5단계의 과정은 일반적입니다. 하지만 구매자는 일반적이지 않습니다. 스킬 (Skill)이 단 하나의 포스트에도 손을 대기 전에, 추상적인 단계들을 클라이언트의 실제 구매 움직임 (buying motion)에 매핑 (mapping)하고 운영자에게 확인을 요청합니다.

PE (사모펀드) 지원을 받는 SaaS 창업자들에게 판매하는 분할 CRO (fractional CRO)의 경우, 매핑 결과는 다음과 같이 나옵니다.

Stage 1  "매출은 괜찮습니다, 영업 사원만 더 필요해요."
Stage 2  "영업 사원을 더 뽑아도 해결되지 않았습니다. 상류 단계(upstream)에 문제가 있습니다."
Stage 3  "아마도 GTM (Go-To-Market) 움직임 자체에 인력 충원이 아닌 운영자가 필요할지도 모릅니다."
...

그다음 게이트 (gate)가 나타납니다:

확인 게이트 (Confirmation gate)

번역된 맵(map)을 제시합니다. 그리고 질문하십시오: "이것이 귀하의 구매자가 실제로 움직이는 방식과 일치합니까?" 다음 단계 전까지는 어떤 게시물도 분류하지 마십시오.

...

이 게이트는 작성 비용은 저렴하지만, 건너뛰는 비용은 매우 비쌉니다. 잘못 매핑된 퍼널 (funnel)을 대상으로 감사를 수행하면, 모든 게시물을 잘못 읽어내는 세련된 보고서만을 얻게 될 뿐입니다. 운영자는 10초 만에 이를 확인합니다. 기술 (Skill)은 그 10초를 투자하여 나머지 자체 신뢰성을 확보합니다.

레이어 4: 형식이 아닌 의도에 따른 분류 (classify on intent, not format)

대부분의 감사는 여기서 실패합니다. 사람들은 게시물이 어떻게 보이는지에 따라 분류합니다. 논쟁적인 의견 (hot take)은 반드시 퍼널 상단 (top-of-funnel)이어야 하고, 프레임워크 (framework)는 퍼널 중간 (mid-funnel)이어야 하며, 사례 연구 (case study)는 반드시 퍼널 하단 (bottom)이어야 한다고 생각합니다. 표면은 거짓말을 합니다.

평가 기준 (rubric)은 게시물이 어떤 형태를 띠느냐가 아니라, 어떤 신념 (belief)을 이동시키느냐에 따라 분류합니다.

## 분류 기준 (Classification rubric) (references/classification-rubric.md)
모든 게시물에 대해 질문하십시오: 이 게시물은 어느 단계의 구매자에게 어떤 신념을 변화시키는가? 형식 (Format)은 힌트일 뿐이며, 결코 판결이 될 수 없다.

실제 실행 과정에서 추출한 세 가지 작동 예시입니다.

게시물 A. "대부분의 'AI 전략' 덱 (deck)은 단어 찾기 및 바꾸기만 거친 작년의 디지털 전환 (digital-transformation) 덱입니다."

표면적으로는 1단계 (Stage 1)로 읽힙니다. 반대 의견을 제시하며, 강렬하고, 도달 범위 (reach)를 위해 만들어졌기 때문입니다. 하지만 의도 (intent)를 보면 2단계 (Stage 2)입니다. 이 게시물은 해결책을 제시하지 않으면서 구매자가 이미 느끼고 있는 고통, 즉 낭비되는 전략 비용을 지목합니다. 이는 누군가를 '인지하지 못하는 상태'에서 '인지하는 상태'로 이동시키지 않습니다. 대신 그들을 "막연한 짜증"에서 "나에게 명명된 문제가 있다"는 상태로 이동시킵니다. 문제 인지 (Problem-aware).

게시물 B. "우리가 단 하나의 GTM 전술을 건드리기 전에 실행하는 4단계 프레임워크 (framework)."

표면적으로는 3단계 (Stage 3)로 읽히며, 의도 또한 이에 동의합니다. 이는 방법론을 가르치며, 구매자를 "나에게 문제가 있다"에서 "나와 같은 문제는 이런 방식으로 해결된다"로 이끕니다. 해결책 인지 (Solution-aware). 진정한 퍼널 중간 (middle-funnel) 단계입니다.

게시물 C. "우리는 한 고객사의 영업 주기 (sales cycle)를 한 분기 만에 40% 단축했습니다. 전과 후를 비교해 보십시오."

표면적으로는 최종 단계인 5단계(Stage 5), 즉 클로징 증거(closing proof)로 읽힙니다. 하지만 의도는 4단계(Stage 4)를 나타냅니다. 이는 시작할 준비가 된 구매자를 위한 마지막 촉진제(nudge)가 아니라, 이 제공자가 실제로 성과를 내는지 묻는 구매자에게 비교를 위한 연료를 제공하는 것입니다. 5단계 버전이라면 마지막 반론(objection)인 '어떻게 협업이 시작되는지', '리스크 완화(risk reversal) 방안은 무엇인지', '왜 지금이어야 하는지'를 해결해 주었을 것입니다. 이 게시물은 그렇지 않습니다. 제공자 인지(Provider-aware).

세 개의 게시물, 세 개의 형식, 그리고 그 형식은 세 번 중 단 한 번도 단계를 정확히 예측하지 못했습니다. 이것이 바로 이 루브릭(rubric)이 하나의 문장이 아니라 참조 파일(reference file)로서 제공되는 이유입니다.

레이어 5: 노이즈로부터 구매 가치를 분리하여 점수화하기

인기 있는 게시물과 가치 있는 게시물은 하나의 지표를 공유할 뿐, 그 외에는 거의 아무것도 공유하지 않습니다. Skill은 의도적으로 분리되는 축(axes)을 따라 모든 게시물의 점수를 매깁니다.

post_id | stage | impressions | engagement_rate | buyer_relevance | commercial_value
--------+-------+-------------+-----------------+-----------------+-----------------
  A     |   2   |   18,400    |     4.1%        |      high       |     medium
...