저는 작은 디지털 마케팅 에이전시를 운영하고 있습니다. 내부적으로 보면 대부분의 주간 업무는 비슷해 보입니다. 한 고객을 위한 기술적 SEO (Search Engine Optimization) 감사, 다른 고객을 위한 스키마 마크업 (schema markup), 광고 계정 검토, 일련의 콘텐츠 브리프 (content briefs), 그리고 이 모든 것을 하나로 묶는 월간 보고서 등이 그것입니다. 이 작업들 중 신비로운 것은 하나도 없습니다. 각 작업은 제가 수년간 잘못된 방식으로 시도했다가, 그보다 조금 덜 잘못된 방식으로 수행하며 다듬어온 절차를 따릅니다. 문제는 무엇을 해야 할지 모르는 것이 아니었습니다. 문제는 이 작업 중 하나를 범용 AI (general-purpose AI)에게 맡길 때마다, 빈 프롬프트 (prompt) 상태에서 시작하여 전체 절차를 처음부터 다시 설명해야 한다는 점이었습니다.

그래서 우리는 먼저 당연해 보이는 해결책을 시도했습니다. 바로 방대한 프롬프트 라이브러리였습니다. 하지만 그것은 버티지 못했습니다. 프롬프트는 당신이 그날 우연히 입력한 단어들을 포착할 뿐, 그 밑에 깔린 절차를 포착하지 못하며, 채팅이 종료되는 순간 모든 것을 잊어버립니다. 다음 주에 똑같은 프롬프트를 붙여넣어도, 모델은 당신이 고생하며 배운 50가지의 예외 사례 (edge cases)를 전혀 기억하지 못합니다. 이것은 우리가 대신 구축한 것에 대한 이야기이며, 마침내 모든 것을 깨닫게 해준 Skills, MCP, 그리고 Agents 사이의 차이점에 대한 이야기입니다. 만약 당신이 Claude 또는 MCP 호환 모델로 무언가를 구축한다면, 이 내용 중 일부가 시행착오를 줄여줄 수 있을 것입니다.

프롬프트 팩 (prompt pack)이 잘못된 형태였던 이유

우리가 도달하는 데 너무 오래 걸렸던 통찰은 이것입니다. 에이전시의 가치는 프롬프트에 있는 것이 아니라, 축적된 판단력 (accumulated judgment)에 있다는 점입니다. 어떤 스키마 유형이 실제로 풍부한 결과 (rich result)를 얻어내는지, 아니면 단순히 유효성 검사만 통과하는지. 첫 한 시간을 낭비하지 않기 위해 광고 계정 점검을 수행하는 순서. 기술적 지식이 없는 소유자가 신뢰할 수 있도록 고객 보고서가 작성되어야 하는 구체적인 방식. 프롬프트는 그것을 얇게 찍어낸 스냅샷에 불과합니다. 우리가 원했던 것은 판단력 그 자체를 패키징하는 방법이었으며, 이를 통해 모델이 필요할 때 이를 로드하고 해당 업무를 수백 번 수행해 본 사람처럼 행동하게 만드는 것이었습니다.

그 패키징에는 세 가지 형태가 있으며, 이를 명확히 구분하는 것이 전투의 대부분을 차지합니다.

Skills, MCP, 그리고 Agents는 같은 것이 아닙니다

우리가 일상적으로 사용하는 구분은 다음과 같습니다.

**skill (기술)**은 하나의 작업을 수행하는 즉시 실행 가능한 기능입니다. 실제로 이는 모델이 작업과 일치할 때 로드하는 폴더입니다. 즉, 지침(instructions)과 해당 절차에 필요한 작은 스크립트 또는 참조 파일들로 구성됩니다. 이는 단순히 문구만을 전달하는 것이 아니라 판단력(judgment)을 수반합니다. "백링크 프로필 분석 실행" 또는 "AI 크롤러를 위한 robots 정책 작성"과 같은 것을 생각해보세요. 당신이 직접 수행하는 방식 그대로 하나의 작업을 완수합니다.

**MCP 커넥터 (MCP connector)**는 배관(plumbing) 역할을 합니다. MCP (Model Context Protocol)는 모델이 실제로 외부 서비스에 도달하는 방식이며, API에 대한 실제 운영 환경에서 검증된(production-hardened) 통합 방식입니다. skill은 모델에게 Google Search Console 데이터를 어떻게 생각해야 하는지 알려줄 수 있습니다. MCP 커넥터는 모델이 그 데이터를 읽을 수 있게 해주는 실질적인 수단입니다. skill이 지식(knowledge)이라면, MCP는 도달 범위(reach)입니다.

**에이전트 (agent)**는 전체 작업을 처음부터 끝까지 수행하는 전문 작업자입니다. 에이전트는 skill과 MCP 커넥터를 조합하고, 단계 사이에서 의사결정을 내리며, 단일 답변 대신 완성된 결과물을 전달합니다. skill이 한 가지 일을 수행한다면, 에이전트는 결과(outcome)를 책임집니다.

우리가 초기에 범했던 실수는 이 세 가지를 하나의 거대한 프롬프트(prompt)에 모두 밀어 넣으려 했던 것입니다. 일단 이를 분리하자, 각 요소는 더 단순해졌고 신뢰하기 쉬워졌습니다. skill은 읽고 감사(audit)할 수 있고, 커넥터는 독립적으로 테스트할 수 있으며, 에이전트는 의사결정을 내리는 과정을 지켜볼 수 있습니다.

두 가지 구체적인 skill

추상적인 분류 체계는 고개를 끄덕이며 이해하기 쉽지만, 우리가 최종적으로 구축한 결과물 중 실제 skill 두 가지를 소개하겠습니다.

첫 번째는 AI 크롤러 트래픽을 제어합니다. 이 skill은 허용할 크롤러(GPTBot, ClaudeBot, PerplexityBot, Google-Extended 등)를 결정하고, 그에 맞는 robots.txt 및 ai.txt를 생성하며, 해당하는 Cloudflare WAF 또는 nginx 규칙을 작성합니다. 이 기능이 단순한 코드 조각(snippet)이 아닌 skill이 되는 부분은 다음과 같습니다. 바로 역방향 DNS(reverse DNS)를 통해 봇을 검증한다는 점입니다. 따라서 단순히 User-Agent를 "GPTBot"으로 설정한 스크래퍼는 통과되지 않습니다. 이러한 역방향 DNS 확인은 일반적인 프롬프트에서는 놓치기 쉬운, 고생 끝에 얻어낸 디테일입니다.

두 번째는 답변 엔진 최적화 (Answer-engine optimization)입니다. 이는 페이지가 고전적인 블루 링크 (blue links)에서만 나타나는 것이 아니라, LLM에 의해 인용되고 AI 생성 답변에 노출되도록 하는 것입니다. 이것은 속임수가 아닙니다. 모델이 페이지를 정확하게 인용하기 쉽게 만드는 구조와 증거의 체크리스트이며, 매번 동일한 방식으로 적용됩니다. 의도적으로 지루하게 만들었는데, 그것이 핵심입니다.

저는 이 두 가지 사례에 대해 전후 수치를 의도적으로 첨부하지 않고 있습니다. 솔직한 버전은 이것들이 반복 가능한 절차를 인코딩(encode)한다는 것입니다. 이것들이 순위를 보장하지는 않으며, 그렇지 않다고 주장하는 사람이 있다면 저는 믿지 않을 것입니다.

우리가 배운 것들

스킬(Skill)은 인격이 아니라 절차입니다. 가장 잘 읽히는 프롬프트들은 재사용성이 가장 낮았습니다. 효과가 있었던 것들은 평범하고 거의 지루할 정도였으며, 분위기(vibes)보다는 단계를 설명했습니다. 처음 실행할 때가 아니라, 두 번째로 실행할 때를 위해 작성하세요.

지식과 도달 범위를 분리하세요. "데이터를 어떻게 생각할 것인가"(스킬)를 "데이터를 어떻게 가져올 것인가"(MCP 커넥터)와 분리하여 유지함으로써 둘 다 수정하기가 더 쉬워졌습니다. 무언가 고장 났을 때, 우리는 어느 쪽을 살펴봐야 할지 알 수 있었습니다.

판단력이 해자(moat)이며, 이는 오직 실제 작업에서만 나옵니다. 우리가 이것들을 작성할 수 있었던 이유는 실제 고객 사이트에서 먼저 업무를 수행했기 때문입니다. 실제 작업에서 추출된 스킬은 예외 케이스(edge cases)를 포함합니다. 상상력으로 작성된 스킬은 자신감만 가질 뿐, 그 외에는 별로 없습니다.

경계를 명시적으로 말하세요. 모든 스킬에는 "이것은 수행하지 않는 작업입니다"라는 명시적인 문구가 포함되었습니다. 그 한 줄이 그 어떤 영리한 지침보다 더 많은 잘못된 출력을 방지했는데, 모델이 자신의 역량을 벗어나 방황하는 것을 막아주었기 때문입니다.

결과

우리는 이 시스템을 forgehouse로 패키징했습니다. 왜냐하면 우리가 운영하는 것을 고용하는 대신 우리가 사용하는 것을 사고 싶어 하는 사람들이 충분히 많았기 때문입니다. 이것은 별도의 데모가 아니라, 우리가 고객 업무에 사용하는 것과 동일한 스킬, 에이전트(agents), 그리고 커넥터(connectors)입니다. 사이트가 추천사(testimonials) 대신 완료된 작업의 기록실(records room)에 의존하는 이유도 바로 그것입니다. 증거는 이미 존재했기에, 우리는 그것을 정리했을 뿐입니다.

다른 무엇보다 이 아이디어를 먼저 직접 확인해보고 싶다면, SEO 스타터 세트(SEO starter set)가 GitHub에 무료로 공개되어 있습니다: github.com/development-candavarci/seo-starter. 이를 클론(Clone)하여 스킬(skill)이 실제로 어떻게 구조화되어 있는지 읽어보고, 유용한 것이 있다면 무엇이든 가져다 쓰세요.

한 가지 핵심적인 결론을 말씀드리자면, 다음을 기억하십시오: 다음 주에 또다시 복사해서 붙여넣을 프롬프트(prompt)를 작성하는 일을 멈추고, 대신 절차(procedure)를 기록하기 시작하십시오. 모델에게 필요한 것은 당신의 가장 유려한 문장력이 아닙니다. 모델에게 필요한 것은 당신의 판단력을, 모델이 불러올 수 있는 형태(shape)로 제공하는 것입니다.