Claude Code에 '의미 감사(Meaning Audit)' 기능을 설치할 수 있는 Skill을 만들었습니다
요약
Claude Code의 Skill 기능을 활용하여 'Meaning Audit' 워크플로우 v1.0을 구현했습니다. 이 기능은 제시된 자료나 결과물만으로 주장의 근거가 어디까지 지지되는지, 의미가 어떻게 추론되었는지를 추적하는 데 중점을 둡니다. 이는 단순히 오류를 판정하기보다 논리적 비약이나 부족한 전제를 찾아내는 감사 과정입니다.
핵심 포인트
- Meaning Audit는 '맞다/틀리다' 대신 근거의 과정을 추적합니다.
- Mode A(Source-Grounded)와 Mode B(Artifact-Only) 두 가지 모드를 제공합니다.
- Mode B는 원자료 없이 완성된 결과물만으로 논점과 부족한 전제를 찾아냅니다.
- Finding은 오류가 아닌, 사람이 확인/판단해야 할 의미상의 논점을 의미합니다.
영업 자료에는 이런 숫자가 나오는 경우가 있습니다.
성사 15/20개 사
평범하게 읽으면 '성사율이 높은가?'라고 생각합니다. 물론 전적으로 믿는 것은 아니며, 영업 자료이므로 어느 정도 과장되어 보였을 것이라고도 생각합니다. 그럼에도 불구하고 '뭐 그럴 만하지 않나'라고 받아들이고 다음 페이지로 넘어갑니다.
Meaning Audit라는 방법으로 이 숫자를 보면 지적은 다음과 같습니다.
- 20개 사란 무엇인가
- 모집단은 어떻게 정의되었는가
- 대상 기간은 언제인가
- 선정 조건은 무엇인가
이러한 내용들이 자료 내에서 확인되지 않는다는 지적입니다.
여기서 말하는 것은 '15/20개 사가 거짓이다'라는 것이 아닙니다. 숫자는 제시되어 있지만, 그 숫자를 어디까지 일반화할 수 있는지는 해당 자료만으로는 판단할 수 없다는 것입니다.
이 글에서는 이러한 Meaning Audit Workflow v1.0을 Claude Code의 Skill로 사용할 수 있도록 했기 때문에, 무엇을 볼 수 있는지, 어떻게 사용하는지 소개합니다.
Meaning Audit란 무엇인가
Meaning Audit는 '맞다/틀리다'를 판정하는 것이 아닙니다. 근거에서 최종적으로 제시된 의미까지의 과정에서 어디서 의미가 추가되고 변형되며 추론되어 판단으로 채택되었는지를 추적하는 방법입니다.
Evidence / Source
→ Interpretation
→ Inference / Warrant
...
점수 매기지도 않고, 다시 쓰지도 않습니다. AI가 하는 것은 trace / expose / question / classify까지이며, accept / revise / investigate / hold / reject는 사람이 결정합니다.
두 가지 모드
Workflow v1.0에는 감사 모드가 2가지 있습니다.
Mode A: Source-Grounded Audit는 원자료나 Evidence가 손에 있을 경우입니다. 결과물의 주장이 원자료에 어디까지 지지받고 있는지를 봅니다.
Mode B: Artifact-Only Audit는 완성된 결과물만 있는 경우입니다. 원자료에 대한 충실성은 판정할 수 없으므로, '맞다/틀리다'가 아니라 이 결과물 안에서 근거까지 추적할 수 있는지를 봅니다. 외부 Evidence 없이 '오류'라고 단정하지 않습니다.
받아본 자료를 읽을 때는 대부분 Mode B에 해당합니다. 후술할 필드 테스트도 Artifact-Only였습니다.
Artifact-Only로도 무엇이 보였는지
첫 번째 필드 테스트(Test 01-1)는 36페이지 분량의 서비스 소개 자료에 대한 Artifact-Only Audit였습니다. 공개 기록에서의 위치는 Presentation Artifact — Generation Provenance Unknown입니다. 작성 수단이 AI인지 아닌지는 자료에서 확인할 수 없었기 때문에, 'AI 생성 프레젠테이션을 감사했다'고 말할 수는 없습니다. 원자료도 없습니다.
그럼에도 불구하고, 자료 안만으로 다음과 같은 것들이 보였습니다.
- 그래프의 수치와 그 옆에 크게 표시된 배율이 일치하지 않음
- 제목의 단어가 그래프가 보여주는 내용과 다름
- 외부 통계에서 '이 사업은 확실히 성장할 것이다'로 이어지는 과정의 근거가 자료 내에 제시되어 있지 않음
- 숫자의 모집단・기간・조건이 제시되어 있지 않음
- 사진이나 그림의 배치가 본문 이상의 의미를 만들고 있음
- 관찰과 해석이 하나의 문장 안에서 섞여 있음
최초 실행에서는 26건의 Finding이 나왔습니다. 이것은 오류 건수가 아닙니다. Finding은 확인/판단해야 할 의미상의 논점입니다. 실제로 이 26건도 사람의 검토를 거쳐 4건이 수정되었고, 1건에 주석이 추가되었습니다(예: '결과물 내에서 모순된다'는 판정을 '제시되지 않았을 뿐이다'로 변경하거나, 관찰과 해석을 분리하여 수정하는 등).
'거짓인지 아닌지'가 아니라 '무엇이 부족한지'
사용해 보니 가장 흥미로웠던 부분은 바로 여기였습니다.
영업 자료나 제안 자료를 읽는 사람은 모든 숫자에 대해 근거를 요구하지 않습니다. '뭐 그럴 만하지 않나'라는 작은 수용을 쌓아가면서 읽어 나갑니다. 그것 자체는 당연한 일입니다.
Meaning Audit는 그 설득력을 무너뜨리는 것이 아닙니다. 그 설득력이 무엇에 의해 지지받고 있는지를 노출시킵니다. 보고 있는 것은 '거짓인지 아닌지'가 아니라, '이 주장을 믿기 위해 무엇이 부족한지'입니다.
冒頭の「15/20社」も、嘘だと言っているわけではありません。その数字の意味を読み手が判断するための情報が、資料の中にない、という話です。
사용 방법 1: 자신의 자료를 감사하기
직접 만든 프레젠테이션, 제안서, 또는 AI가 작성하게 한 자료를 제출 전에 검토하는 용도입니다.
확인할 포인트의 예시입니다.
- Evidence보다 제목이 더 강해지지는 않았는지
- 숫자의 조건이 빠지지 않았는지
- 인과관계가 비약하지 않았는지
- 그림이나 그래프가 본문 이상의 의미를 만들고 있지 않은지
- 작성자에게는 사실이지만, 독자에게는 근거가 보이지 않는 형태가 되고 있지는 않은지
여기서 중요한 것은 '올바른 것을 쓰는' 것뿐만 아니라, 올바른 것이 추적 가능한 형태로 전달되는 것인지입니다.
도입부의 숫자의 경우, 이렇게 작성하면 독자가 판단할 수 있습니다.
성사 15/20개 사
대상: (어떤 집단인가)
계약: (무엇을 근거로 성사로 보았는가)
...
숫자 자체는 변하지 않았습니다. 바뀐 것은 독자가 그 숫자를 어디까지 일반화하여 판단할 수 있는지 여부입니다.
사용 방법 2: 받은 자료를 감사하기
영업 제안, 컨설팅 제안, 기획서, 프레젠테이션 등 타인으로부터 받은 자료에 적용하는 용도도 있습니다.
목적은 상대방의 자료를 공격하는 것이 아닙니다. 확인하는 부분은 대략 이렇습니다.
- 어떤 숫자를 추가로 확인할 필요가 있는지
- 어떤 결론에 추론이 들어갔는지
- 그래프와 제목이 같은 의미를 나타내는지
- 판단하기 전에 확인하고 싶은 Unknown(미지)은 무엇인지
의사결정 전 체크리스트 정도로 사용할 수 있다는 정도입니다.
Finding은 전부 고칠 필요는 없다
이 부분은 오해하기 쉬운 것 같습니다. Finding을 모두 수정할 필요는 없습니다.
영업 자료라면, 의도적인 Framing(틀 짓기)이나 간소화를 남겨두는 판단도 있습니다. Meaning Audit는 '모두 고치라'는 시스템이 아닙니다. 고칠지 / 남길지 / 조사할지 / 보류할지는 사람이 결정하는 것입니다.
AI에게 수정을 돌려줄 때
자료를 AI로 만들고 있는 경우, Meaning Audit Report를 그 AI에 다시 넣어 수정하게 할 수 있습니다.
이때, Report 전체를 넘겨주면서 '모두 고쳐라'라고 하는 것보다는 채택한 Finding만 되돌리는 것이 좋습니다.
F-03, F-08, F-12만 수정해 주세요
채택할 Finding을 고르는 시점에 사람의 판단이 개입하는 부분입니다.
너무 많이 깎아내리지 않기
Meaning Audit는 연필깎이에 약간 비유됩니다. 한 번 깎으면 심은 곧게 됩니다. 다만, 'Finding이 0이 될 때까지' 계속 깎고 있으면, 연필 자체가 짧아집니다.
자료도 마찬가지로, 수정 그 자체가 새로운 Meaning Shift(의미 변화)를 만들어낼 수 있습니다. 목표는 Finding 0이 아니라, 중요한 Finding을 사람이 놓치지 않는 것입니다.
Skill로서 공개했습니다
Meaning Audit Workflow v1.0을 Claude Code의 Agent Skill로 공개했습니다.
위치는 installable implementation of Meaning Audit Workflow v1.0입니다. Workflow 자체의 방법/Status/Finding Type/STEP은 동일하며, Skill로서 구동하기 위한 운영상의 지침만 추가되었습니다.
설치
git clone https://github.com/meaning-audit/meaning-audit-workflow.git
개인용 Skill로 넣을 경우에는 skills/meaning-audit를 ~/.claude/skills/에 복사합니다.
mkdir -p ~/.claude/skills
cp -R meaning-audit-workflow/skills/meaning-audit ~/.claude/skills/
Windows(PowerShell)나 프로젝트 단위에서의 설치는 README에 적혀 있습니다. 복사한 후 Claude Code를 다시 시작해 주세요.
사용 방법
/meaning-audit slides.pdf를 감사해 줘. 원본 자료는 source-report.pdf
이 제안서를 Meaning Audit 해 줘. 원본 자료는 없어
원본 자료(元資料)가 있으면 Mode A로, 없으면 Mode B로 감사합니다. 출력은 13개 섹션의 Meaning Audit Report이며, Human Decision 항목은 공란으로 반환됩니다.
실행마다 결과가 달라집니다
솔직히 말씀드리겠습니다. 같은 자료를 넣어도 실행할 때마다 다음 내용들이 바뀐다는 것을 확인했습니다.
- Finding 개수
- Finding Type
- Status
- Finding의 정리 방식 및 분류
- 주 Document Class
같은 자료에 대해 6회 실행했을 경우, Finding 수는 2131 범위였습니다(프롬프트 사용 3회 시 2126, Skill 사용 3회 시 28~31). 주 Document Class 역시 A와 C로 나뉘었습니다.
반면, 독립적인 4회 실행 모두에서 의미적으로 동종의 지적이 재검출된 부분이 23개 있었습니다(전체 34개 중). Report 구조, 모드 판정, 금지 사항 준수는 어떤 실행에서도 일치했습니다.
즉, '매번 같은 결과가 나오는 감사 시스템'이 아닙니다. 같은 Workflow에 따라 Meaning Shift를 관찰하고 Human Review로 반환하는 Skill입니다. 재현성은 검증하지 않았으며, 그렇게 주장하지도 않습니다.
최종 판단은 사람이 합니다
설계상 AI는 최종 판단을 내리지 않습니다.
| AI | Human |
|---|---|
| trace(추적) | accept(수용) |
| ... | |
| 앞서 진행된 필드 테스트에서도, AI가 도출한 Finding을 그대로 채택하지 않았습니다. 사람의 검토를 통해 판정 근거가 결과물 내에서 확인 가능한 범위를 넘어선 부분을 수정했습니다. Meaning Audit의 결과 자체도 'Meaning Audit되었다'는 형태로 처리됩니다. |
향후 계획
v1.0은 스코어링, 자동 Rewrite, 자동 의사결정을 포함하지 않습니다. 엔진화나 SaaS화 역시 범위 외입니다. 새로운 개념이 필요해 보이는 경우라면, 사양에는 넣지 않고 후보로 기록하는 운영 방식을 취하고 있습니다.
현재까지 파악된 것은 '평소라면 흘려보냈을 숫자들에 대해 멈춰서 볼 수 있었다' 정도입니다. 그럼에도 불구하고, 자신의 자료를 제출하기 전에 한 번 거치기에는 충분했습니다.
직접 자료로 시험해보고 싶은 분들은 리포지토리에서 이용해주세요.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기