팩트 체크와 미디어 리터러시 체크를 두 개의 Claude Skill로 구현해 본 이야기

서론

Claude Code / Cowork에서 동작하는 Agent Skill로서, 정보의 신뢰성을 체계적으로 평가하는 두 가지 Skill을 공개했습니다.

shuji-bonji/factcheck-skill — 20개 항목 × 4개 카테고리로 팩트 체크 (Fact Check)
shuji-bonji/media-literacycheck-skill — 30개 항목 × 6개 카테고리로 미디어 리터러시 (Media Literacy) 평가

둘 다 필자가 이전부터 운용해 온 12개 언어 대응 PWA인 shuji-bonji/fact-checklist의 평가 방법론 (Methodology)을 LLM용으로 이식한 것입니다.

"기능이 유사한 두 가지 Skill을 왜 나누었는지", "Claude Skill로서 어떻게 구성했는지", "Anthropic Skills Registry에서 어떻게 공개하는지"를 구현 중심으로 정리합니다.

왜 Skill화 했는가

PWA 버전의 fact-checklist는 인간이 화면에서 체크리스트를 한 항목씩 평가하는 Web App입니다. 어느 정도 사용되어 왔으나, 매번 20~30개 항목을 수동으로 채우는 것은 부하가 크다는 과제가 있었습니다.

반면, Claude Code나 Cowork는 LLM이 에이전트 (Agent)로서 동작하는 환경입니다. SKILL.md를 ~/.claude/skills/에 두는 것만으로, 특정 키워드에 반응하여 자동으로 평가 로직이 기동되는 메커니즘이 있습니다.

동일한 평가 기준을 인간용 UI와 LLM용 Skill 양쪽 모두에서 제공하는 것이 기본 사상입니다.

왜 두 개로 나누었는가

기능이 겹치는 Skill을 두 개 만드는 것은 언뜻 보면 중복입니다. 하지만, 팩트 체크와 미디어 리터러시 체크는 목적·주체·관점이 다르기 때문에 의도적으로 분리했습니다.

팩트 체크와 미디어 리터러시 체크의 차이

두 가지는 혼동되기 쉽지만, 성질이 명확히 다릅니다.

팩트 체크 (Fact Check)	미디어 리터러시 체크 (Media Literacy Check)
무엇을 확인하는가	개별 주장·데이터가 사실인가
...	...

팩트 체크는 "이 주장은 사실인가?"를 1차 정보·인용·방법론·데이터의 재현성 등을 통해 검증합니다. 반면 미디어 리터러시 체크는 "이 정보는 어떻게 발신되고 있는가?"를 발신 의도·상업적 동기·시각적 연출·사회적 검증까지 포함하여 평가합니다.

두 가지는 대립하는 것이 아니라 상호 보완적인 관계에 있습니다. "사실은 맞지만, 발신 의도에 편향이 있는" 정보도 많고, "발신자는 성실하지만, 인용된 데이터가 오래된" 경우도 있습니다.

두 개의 Skill로서의 분리

이 두 가지 관점을 하나의 Skill로 병합하기보다, 호출 측에서 의도적으로 선택할 수 있는 편이 트리거링 (Triggering) 정밀도도 높아질 것이라고 판단했습니다. 독자의 상황에 따라,

투자 정보·과학적 주장·통계 데이터 → 사실 관계를 엄격하게 보고 싶다 → factcheck-skill
뉴스 기사·SNS 게시물·광고성 글 → 발신 의도까지 포함해서 보고 싶다 → media-literacycheck-skill

중 어느 것이 필요한지는 달라집니다. 두 Skill의 항목 수와 카테고리 구조는 다음과 같습니다.

factcheck-skill	media-literacycheck-skill
카테고리 수	4
...	...

두 Skill은 독립적이며 병용이 가능합니다.

아키텍처 전체상

두 Skill은 동일한 구조를 취하고 있습니다.

factcheck-skill/ media-literacycheck-skill/
├── SKILL.md ├── SKILL.md
├── agents/ ├── agents/
...

메인 SKILL.md가 트리거로 기동하는 메인 스킬이며, agents/ 하위 요소가 **독립 검증용 서브 에이전트 (Sub-agent)**입니다. 다음 절부터 각각 살펴보겠습니다.

SKILL.md의 내용

Claude Code / Cowork에서의 Skill은, SKILL.md의 서두 frontmatter에 작성된 description과 name이 트리거링 (Triggering)의 핵심이 됩니다.

factcheck-skill/SKILL.md

의 frontmatter에서 해당 부분만 발췌합니다.

---
name: factcheck
description: |
...

포인트는 3가지가 있습니다.

1. description에 트리거 문구를 직접 나열하기

LLM은 description을 읽고 이 Skill을 실행할지 판단합니다. "팩트 체크해줘", "이 정보는 신뢰할 수 있어?"와 같이, 사용자가 실제로 던질 법한 자연어 문장을 구체적으로 나열함으로써 triggering의 정밀도가 크게 달라집니다. 추상적인 "정보를 검증하는 스킬"만으로는 반응하기 어렵습니다.

2. 유스케이스(Use case)를 다각도로 작성하기

"URL/기사/주장/AI의 답변"과 같이 평가 대상의 범위를 명시하고 있습니다. 이를 통해 "Claude의 답변을 검증해줘"와 같은 **메타적인 호출(Meta-call)**에도 반응합니다.

3. 리서치 결과의 리뷰에도 사용할 수 있다고 작성하기

Cowork처럼 여러 Skill을 병용하는 상황에서는, 다른 Skill의 출력을 이것으로 검증하는 식의 활용을 상정할 수 있습니다. description에 그 용도를 적어두면, Claude가 자발적으로 "방금 전의 결과를 factcheck-skill로 검증할까요?"라고 제안하게 됩니다.

평가 항목의 구조

본문 부분은 4개 카테고리 × 20개 항목의 체크리스트 구조입니다. 1개 카테고리만 발췌합니다.

### 카테고리 1: 크리티컬 평가 (6개 항목)
정보의 근본적인 신뢰성을 판단하는 가장 중요한 카테고리.
여기서 ❌가 많은 정보는 다른 카테고리의 평가와 상관없이 주의 필요.
...

각 항목에 판단 기준과 **구체적인 예시(✅/❌)**를 적은 이유는 LLM이 "모호한 지시로 인해 판정이 흔들리는 것"을 방지하기 위해서입니다. Skill 설계 시 뼈저리게 느낀 점은, "이 기준으로 평가해"라고 적는 것만으로는 불충분하며, ✅ 이런 케이스 / ❌ 이런 케이스를 병기하지 않으면 결과가 안정되지 않는다는 것이었습니다.

출력 포맷의 고정

평가 결과는 다음 테이블 형식으로 출력하도록 SKILL.md 말미에 지시하고 있습니다.

## 팩트 체크 평가 리포트
**대상**: [평가 대상 정보·URL·주장]
**평가일**: [날짜]
...

포맷을 고정하는 이유는 2차 활용을 쉽게 하기 위해서입니다. Markdown 테이블로 출력되면 Slack 게시나 Note 기사로의 복사 붙여넣기, 후속 Skill에서의 재파싱(Re-parsing)이 쉬워집니다. 판정 아이콘(🟢/🟡/🟠/🔴)은 두 Skill 모두에서 공통화했습니다. 팩트 체크와 미디어 리터러시 체크를 병용했을 때, 결과의 해석 규칙이 통일되어 있는 편이 읽는 사람의 인지 부하를 낮춰주기 때문입니다.

sub-agent 패턴 — 자기 평가 편향의 배제

두 Skill에는 agents/ 하위에 독립 검증용 sub-agent 정의를 두고 있습니다.

왜 sub-agent를 나누는가? LLM의 메인 에이전트에게 "당신의 답변이 맞습니까?"라고 물어도, 자신의 출력을 정당화하는 방향으로 편향(Bias)이 작동하기 때문입니다. 이는 "자기 봉사 편향 (Self-serving bias)"이라 불리며, LLM의 신뢰성 검증에서 빈번하게 문제가 됩니다.

media-literacycheck-skill/SKILL.md에서 sub-agent로의 위탁 플로우를 발췌합니다.

| 대상 타입 | 취득 방법 |
| ---------- | -------------------------------------------------- |
| URL | WebFetch로 콘텐츠 취득 |
...

sub-agent에게는 메인 에이전트의 대화 문맥을 전달하지 않는 것이 중요합니다. "자신이 직전에 무엇을 말했는지"를 모르기 때문에 비로소 제3자로서 평가할 수 있습니다.

LLM 출력의 메타 검증

SKILL.md의 말미에는 "LLM 답변 검증 모드"도 작성되어 있습니다.

## LLM 답변 검증 모드
LLM의 답변을 검증할 경우, 다음 사항을 특히 중시한다:
1. **할루시네이션 (Hallucination) 탐지**:
...

이를 통해 "Claude가 내놓은 제안 리포트를 다시 한번 Claude에게 체크하게 하는" 메타적인 활용이 가능합니다. Cowork에서 긴 리서치를 실행한 후의 **품질 게이트 (Quality Gate)**로서 기능합니다.

Anthropic Skills Registry를 통한 공개

Skill을 만들었다면, 공개하여 다른 사람들도 사용할 수 있게 하고 싶을 것입니다. Anthropic 공식 프레임워크는 "Plugin Marketplace" 형식을 취하고 있으며, .claude-plugin/marketplace.json이라는 manifest (매니페스트)를 Git 호스팅을 통해 공개하면 누구나 자신만의 마켓플레이스를 운영할 수 있습니다.

공개 옵션

자체 마켓플레이스의 최소 구성

이것이 가장 간단한 방법입니다. 디렉토리 구조는 다음과 같습니다.

my-marketplace/
├── .claude-plugin/
│ └── marketplace.json
...

marketplace.json의 최소 예시:

{
"name": "shuji-bonji-skills",
"owner": {
...

두 가지 포인트가 있습니다.

사용자 측 설치 절차

공개된 마켓플레이스는 사용자 측에서 다음과 같이 추가합니다.

# GitHub의 owner/repo 형식으로 추가
/plugin marketplace add shuji-bonji/skills-marketplace
# 개별 plugin을 설치
...

특정 브랜치나 태그에 pin (고정) 하려는 경우 owner/repo@ref 형식을 사용할 수 있습니다.

로컬 검증

공개하기 전에 로컬에서 동작을 확인할 수 있습니다.

# 로컬 디렉토리를 마켓플레이스(Marketplace)로 추가
/plugin marketplace add ./my-marketplace
# 검증
...

claude plugin validate는 marketplace.json의 스키마, 중복된 plugin 이름, 소스 경로 트래버설 (source path traversal), plugin.json의 버전 (version) 정합성을 체크합니다. SKILL.md의 프론트매터 (frontmatter) 또한 plugin 디렉토리를 지정하여 검증해 줍니다.

공식 마켓플레이스 신청

Anthropic이 운영하는 공식 마켓플레이스인 anthropics/claude-plugins-official에 게재하려면 PR (Pull Request) 기반의 신청이 필요합니다. 품질 및 보안 기준을 충족해야 하며, 당연히 리뷰 과정을 거치게 됩니다.

필자의 경우에는 우선 자체 마켓플레이스로 공개한 뒤, 이용 실적이나 피드백이 쌓이면 공식 신청을 검토하는 흐름을 취하고 있습니다. Skill 자체를 한 번 만들고 끝내고 싶지는 않기 때문입니다.

제3자 카탈로그 사이트

Anthropic 공식 프레임워크와는 별개로, 커뮤니티에서 운영하는 카탈로그 사이트들도 있습니다.

agentskills.so — Agent Skill 카탈로그
claudemarketplaces.com — Plugin / Marketplace 목록
tessl.io / explainx.ai — Skill 레지스트리 (Registry)

여기에 등록하면 검색 유입이 늘어납니다. 경우에 따라 GitHub README에 배지를 달 수 있기도 합니다.

요약

2개의 Skill을 만들어 공개하는 과정에서 얻은 지식을 정리합니다.

관점을 나누는 것이 트리거링 (triggering) 정밀도를 높인다. 1개의 Skill에 모두 담기보다, 목적별로 분리하여 호출 측에서 선택할 수 있는 구조로 만든다.
description에 발화 문구를 직접 나열하는 것이 트리거링 설계의 핵심이다. 추상적인 표현이 아니라, 사용자가 실제로 던질 법한 자연어를 작성한다.
sub-agent를 분리하여 자기 평가 편향 (self-evaluation bias)을 제거한다. agents/ 디렉토리에 독립된 검증 에이전트를 두는 패턴은 품질 게이트 (quality gate)로서 기능한다.
자체 공개는 marketplace.json을 통해 GitHub repo 하나로 완결된다. 공식 신청에 앞서 자체적으로 배포하여 테스트해 볼 수 있다.
PWA → Skill 파생은 동일한 방법론을 human-facing과 LLM-facing 양쪽 모두에 대응시키는 좋은 패턴이다.

실제 상황에서 2개의 Skill을 어떻게 구분하여 사용할지, 입장별 권장 유스케이스 (개인 사용자, 저널리스트, 교육 기관, AI 출력의 메타 검증 등)는 관련 기사에 정리해 두었습니다.