안녕하세요, Givery AI Lab 소속 AI 엔지니어 무라카미입니다.

최근에는 블로그 작성에 AI를 활용하는 것도 일반화되었습니다. 최근에는 이른바 "LLM스러운" 기술을 해소하는 Skill이 곳곳에서 만들어지는 것도 눈에 띕니다.

얼마 전, DSPy와 로컬 LLM으로 프롬프트 최적화를 시도한 기사를 작성했습니다. 사실 그 기사는 작성 자체를 Claude Code의 Agent Skill로 반자동화하고 있습니다. 본 기사에서는 그 메커니즘과 운용 방식을 공유합니다.

이 기사를 읽으면 다음 3가지를 알 수 있습니다.

• 기술 블로그 작성을 위해 어떤 Skill을 만들었는가 (사내 정보도 포함되어 있어 구체적인 내용은 비공개로 합니다)
• 어떤 흐름으로 작성했는가
• AI의 출력 중 어느 부분이 수정 대상이 되기 쉬웠는가

그리고 이 기사 자체도 앞으로 소개할 것과 동일한 흐름으로 작성되었습니다.

서론

주제는 지난번에 작성한 DSPy 기사입니다.

이 한 편을 작성하는 과정에서, 작성 워크플로우를 Claude Code의 Skill로 분리했습니다. 목표는 "빨리 쓰는 것"보다, 품질을 일정 기준에 맞추는 것과 인간이 리뷰해야 할 관점을 고정하는 것에 있습니다.

이미지로 표현하자면, 블로그 작성의 "CI/CD 모방"입니다. 골자 만들기 → 본문화 → 문장 교정 → 포괄 리뷰 → PII 체크라는 공정을 각각 독립된 Skill로 구성했습니다.

또 다른 배경이 있습니다. 사내에는 블로그 공개 전에 제3자 리뷰를 거치는 프로세스가 있습니다 (상세 내용은 생략합니다). 이번 Skill 군, 특히 포괄 리뷰와 PII 검출은 이 제3자 리뷰의 부하를 줄이기 위한 목적으로 만들었습니다. 포괄 리뷰 Skill에는 사내의 블로그 작성 지침을 반영했습니다. 제3자가 보는 관점을 작성 단계에서 미리 반영하기 위해서입니다.

시도해 본 결과

먼저 요점을 정리합니다.

• 작성을 5가지 Skill (blog-init / blog-write / blog-review / blog-lint / blog-privacy)로 분할했다.
• "기사를 써줘"라는 한 번의 생성 방식이 아니라, 공정마다 인간의 리뷰를 끼워 넣는 설계로 함으로써 재작업(rework)을 줄였다.
• AI 출력 중 수정 대상이 되기 쉬운 부분에는 뚜렷한 경향이 있었다 (부족함, 과함, 틀림의 3가지).
• 기사의 골격이나 절차는 AI에게 맡길 수 있었던 반면, 사실 확인과 "무엇을 말할 것인가"에 대한 판단은 인간에게 남겨두는 것이 효율적이었다.

이하, Skill 구성 · 흐름 · 수정 경향 순으로 작성하겠습니다.

왜 하나의 커다란 프롬프트로 만들지 않았는가

애초에 "이 검증 내용으로 블로그를 써줘"라고 한 번에 부탁하는 방법도 있습니다. 실제로 시도해 보니, 골자 단계에서 수정하고 싶은 구성상의 문제가 본문까지 그대로 파급되어 재작업의 규모가 커졌습니다.

그래서 공정을 나누기로 했습니다. 각 공정의 마지막에 인간의 리뷰를 끼워 넣어, 방향성이 확정된 후 다음으로 넘어가는 설계입니다. 즉, Skill의 경계가 곧 인간의 개입 지점이 됩니다.

Agent Skill은 Claude Code가 특정 트리거(의뢰 문구나 슬래시 명령어)에 따라 불러오는 "절차서"입니다. description에 트리거 단어와 역할을 적어두면, 의뢰 내용에 따라 역할이 맞는 Skill이 호출됩니다. 이 description을 통해 경계를 명확히 하고, 예를 들어 "본문을 쓰는 Skill은 문장 교정을 하지 않는다"와 같이 분담을 고정했습니다.

만든 5가지 Skill과 역할

Skill	역할	자동 편집	주요 인간 개입 지점
blog-init	골자(헤드라인 구성) 생성. Front Matter 및 마지막 CTA를 미리 준비	함	헤드라인·키워드의 방향성
blog-write	검증 리포지토리 등을 참조하여 골자를 본문으로 살 붙이기 (동일 파일을 in-place 업데이트)	함	사실·수치·코드의 정확성
blog-review	Zenn 가이드라인과 사내 지침에 따른 6가지 관점의 포괄적 리뷰	하지 않음 (지적만 수행)	지적 사항의 채택 여부
blog-lint	textlint를 실행하여 에러 보고 및 수정안 제시	승인 시에만	수정 사항의 채택 여부
blog-privacy	openai/privacy-filter로 PII(개인 식별 정보)를 검출 (보조적인 탐지)	하지 않음 (보고만 수행)	검출 위치에 대한 최종 판단

설계에서 의식한 점은, 쓰는 Skill과 판정하는 Skill을 분리하는 것입니다. blog-init과 blog-write는 파일을 새로 쓰지만, blog-review와 blog-privacy는 「지적·검출할 뿐 자동 수정은 하지 않는다」는 운영 방식을 택했습니다. 수정 여부에 대한 최종 판단을 인간에게 남겨두기 위해서입니다. blog-lint의 자동 수정(textlint:fix)도 승인을 받은 후에 실행합니다.

집필 플로우와 인간의 개입 지점

전체 흐름은 다음과 같습니다.

포인트는 각 Skill 사이에 반드시 인간의 리뷰가 들어간다는 점입니다.

리뷰 ① (골자 작성 후)

• 헤드라인의 순서와 기사에서 목표로 하는 키워드의 방향성을 확인한다
• 여기서 방향을 바로잡으면 본문 작업의 재작업(rework)을 방지할 수 있다

리뷰 ② (본문 작성 후)

• 할루시네이션 (Hallucination)을 체크하는 공정 중 가장 비중이 크다
• 사실·수치·코드가 검증 원천과 일치하는지 육안으로 확인한다

리뷰 ③ (교정·리뷰 후)

• textlint나 blog-review의 지적 사항을 모두 수용하는 것이 아니라 채택 여부를 판단한다

리뷰 ④ (PII 체크 후)

• 집필자 이외의 제삼자에 의한 리뷰
• 앞선 Skill 그룹, 특히 포괄적 리뷰와 PII 검출은 이 ④의 부하를 줄이기 위해 마련되었다

①~③은 집필자 자신의 셀프 리뷰이며, ④가 다른 담당자에 의한 제삼자 리뷰에 해당합니다. 역할 분담을 한마디로 요약하자면, AI는 초안 작성과 관점 제시, 최종 결정은 인간입니다.

각 Skill은 구체적으로 무엇을 하는가

지금까지 역할을 빠르게 훑어보았으므로, 각 Skill이 실제로 체크하거나 생성하는 항목을 조금 더 구체적으로 소개하겠습니다 (Skill의 내부 로직 자체는 공개하지 않습니다).

blog-init (골자 만들기)

• 기사의 유형(트라이얼계/소개계/리포트계)에 따라 헤드라인 템플릿을 전개한다
• Front Matter의 필수 항목(title·emoji·type·topics·published)을 Zenn의 사양에 맞춰 미리 준비한다
• 마지막에 정형화된 CTA를 삽입한다
• 제목이나 토픽에는 검색 키워드를 포함시킨다

blog-write (본문 작성)

• 검증 리포지토리나 로그로부터 골자의 헤드라인 메모를 본문으로 전개한다
• 대상은 단 1개의 Markdown 파일이며, 동일한 파일을 직접 수정한다
• 수치나 커맨드는 추측으로 채우지 않고 참조 원천에 맞춘다
• 가정을 하는 경우에는 문면에 명시한다

blog-review (포괄적 리뷰)

• 사내 블로그 집필 지침을 반영한 6가지 관점으로 기사를 점검한다
• 기본 구조 / 가이드라인 준수 / Markdown 표기법 / 기술적 정확성 / 문장 품질 / SEO·발견성
• 제삼자 리뷰(④)에서 확인될 포인트를 집필 단계에서 미리 선점하는 위치에 있다
• 지적 사항만 반환하며, 파일은 수정하지 않는다

blog-lint (문장 교정)

• textlint를 통해 문장의 길이, 조사의 연속, 표기 불일치 등을 기계적으로 잡아낸다
• 규칙에는 「AI스러운 문장」을 검출하는 프리셋도 포함되어 있다
• 일례로, 「강조 + 콜론」 형태의 불렛 포인트를 AI 스타일로 판정하는 등
• 자동 수정은 실행 전에 반드시 확인 과정을 거친다

textlint란

textlint는 Markdown이나 플레인 텍스트 (Plain Text)를 대상으로 하는 문장 교정 도구입니다. ESLint의 문장 버전이라고 생각하면 이해하기 쉬우며, 규칙을 플러그인 (Plugin) 형태로 조합하여 .textlintrc.json에 설정을 작성하여 운용합니다. 한 문장의 길이 나 표기 불일치와 같이 "기계적으로 판정할 수 있는" 관점을 자동으로 체크할 수 있으며, --fix를 붙이면 수정 가능한 것은 자동으로 고칠 수 있습니다.

textlint에서 채택하고 있는 규칙의 예

이 운용에서는 기술 문서용 및 일본어용 프리셋 (Preset)에 더해, 표기 불일치 검출과 "AI스러움" 검출 규칙을 조합하고 있습니다. .textlintrc.json에서 활성화하고 있는 것을 발췌하면 다음과 같습니다.

규칙 / 프리셋	주로 포착하는 관점
preset-ja-technical-writing	기술 문서용의 정석적인 프리셋. 한 문장의 길이 (본 운용에서는 최대 120자로 조정), 문장 끝 구두점 통일, 이중 부정, 「が(가)」, 「の(노)」의 연속 등
preset-ja-spacing	일본어 주변의 공백. 반각 영숫자와 전각 문자 사이의 공백 등을 통일
@textlint-ja/no-synonyms	동의어에 의한 표기 불일치 (같은 단어의 카나 표기가 장음 부호 유무 등으로 흔들리는 케이스)를 검출
@textlint-ja/preset-ai-writing	AI가 쓰기 쉬운 기술 패턴을 검출 (후술)
prh	프로젝트 고유의 표기 사전. 본 운용에서는 zenn을 Zenn으로 맞추는 등

이 중 @textlint-ja/preset-ai-writing이 서두에서 언급한 "LLM스러움"을 기계적으로 포착하기 위한 프리셋입니다. 다음과 같은 규칙을 포함합니다.

• no-ai-list-formatting: 불렛 포인트에서 강조와 콜론을 조합하는 형식이나, 이모지를 머리에 붙인 항목 등 기계적인 리스트 표현을 검출
• no-ai-hype-expressions: 과도하게 "대단함"을 부추기는 과장·호들갑스러운 표현을 검출
• no-ai-emphasis-patterns: 불필요한 굵게 처리나, 굵게 처리 + 이모지와 같은 과도한 강조 패턴을 검출
• no-ai-colon-continuation: 술어 뒤에 콜론을 두어 코드나 리스트를 이어가는 영어식 접속을 검출
• ai-tech-writing-guideline: 중언부언하는 표현이나 수동태, 추상적인 말투 등 기술 문서로서의 품질 관점을 제시

실제로 이 글을 쓰는 과정에서도 초안에는 「강조 + 콜론」 형태의 불렛 포인트나 과도한 강조가 산견되었으며, 이러한 규칙들이 이를 잡아내 주었습니다.

blog-privacy (PII 검출)

• 블로그 공개 전에 개인정보로 보이는 기술이 남아 있지 않은지 기계적으로 분류
• openai/privacy-filter라는 고유 명사 추출 모델을 @huggingface/transformers에서 이용
• 입력된 Markdown은 행 단위로 추론하며, 검출된 부분을 라벨 (인명, 메일, URL, 전화번호 등)과 점수(Score)와 함께 목록화
• 결과는 어디까지나 보조이며, 최종 판단은 사람이 수행
• 영어 중심의 모델이므로 오검출이 많으며, 이 글의 검출에서도 나타난 항목은 모두 오검출이었음

AI 출력에서 수정 대상이 되기 쉬웠던 부분

여기가 본 기사의 핵심입니다. 소재가 된 DSPy 기사는 초판이 AI 생성물이었습니다. 그 초안에 필자가 리뷰를 넣고 수정을 거듭하여 공개 원고로 만들었습니다. 작성했던 리뷰 메모를 되돌아보면, AI의 출력에서 수정이 필요한 부분은 크게 다음 3가지였습니다. "부족함", "과함", "틀림"입니다.

A. 부족함 — AI가 쓰지 않으므로 사람이 추가함

AI가 채우는 것은 "무엇을·어떻게 했는가"까지입니다. 그 전 단계인 "왜"나, 독자가 판단하는 데 사용하는 구체적인 재료는 빠지기 쉬웠습니다.

동기·배경

• 초안에는 "왜 시도했는가"가 없었기 때문에, 로컬 LLM의 성능 확인이나 DSPy의 최적화라는 동기를 보충함
• 아울러 배경 섹션을 신설함

선정 이유

• 평가 지표도 마찬가지로 "왜 Levenshtein 거리인가"가 빠져 있었기에, 완전 일치로는 gemma 계열의 표기 불일치에 대응할 수 없어 완화했다는 경위를 보충함

구체적 예시·실제 입출력

• 방법론에 대한 설명은 있지만, 추출 결과의 샘플이 없었음
• 직무 경력서에서 自動車産業 (자동차 산업)이 반환된다는 실례를 1개 추가함

한계 및 전제 조건의 주의사항

• 실험을 위해 샘플 데이터로 10건의 AI 생성물만을 준비했으나, 초안에는 건수에 대한 주의 사항이 없었음
• 10건 정도는 본래 불충분하며, 수백 건 이상이 바람직하다는 보충 설명을 추가함

B. 과잉 정보 — AI가 불필요하게 작성하여 사람이 깎아내거나 수정함

반대로, 형식을 채우려다 보니 본질적이지 않은 정보까지 채워 넣는 경향도 있었습니다. 서두에서 언급한 "LLM스러움"이 여기서 나타납니다.

본질적이지 않은 망라 섹션

• 개발 환경의 디렉터리 구성도나 비공개 리포지토리(Repository)의 설정 절차 등이 나열되어 있었음
• 데이터 분석 위주의 "해봤다" 식의 기사에서, 아키텍처(Architecture)가 주제가 아니었기에 통째로 삭제함
• 전형적인 AI 생성물다운 과도한 친절함이었음

환경 의존적인 절차

• "--data를 붙이지 않고 실행하면 데모만 돌아간다"와 같이, 수중의 디렉터리를 전제로 한 설명도 삭제함 - 독자의 환경에서는 재현되지 않기 때문

도식의 표현

• 처리 흐름이 코드 블록 내의 아스키 아트(ASCII art)로 그려져 있었기에, Mermaid로 교체함.

수치 표기 불일치 · 구성 중복 · 장황한 표현

• 42.64%와 42.6%와 같은 자릿수 불일치, 동일한 목적 설명이나 동일한 수치의 반복, 완곡하고 번거로운 말투 - 이것들도 "과잉 정보"의 일종이며, 깎아낼수록 가독성이 좋아졌음

C. 오류 — AI가 사실 확인을 하지 않으므로 사람이 확인함

마지막으로, 그럴듯해 보이지만 사실과 다른 기술입니다. 이 부분이 가장 주의해야 할 영역이었습니다.

사실 관계

• 추출된 모델명이 gemma4:e4b라고 적혀 있었으나, 실제로 사용한 것은 gemma4:e2b였음 - 다만, 소스 코드로서 일부 gemma4:e4b를 이용한 코드가 남아 있었기 때문에 오인한 것으로 생각됨
• 외부 문서로의 링크도 플레이스홀더(Placeholder) 상태였기에, 실제 URL로 교체함

학습된 지식으로의 유도 (Hallucination)

• LLM은 학습 시의 지식을 신뢰하기 쉬운 경향이 있음
• 생소한 고유명사를 "알고 있는" 표기로 멋대로 바꿔버리는 경우가 있음
• 예를 들어 지정한 gpt-5-nano가 어느샌가 gpt-4o로 변해 있었음 - 새로운 모델명이나 버전일수록 이러한 교체가 일어나기 쉬움

전문 용어 설명

• MIPROv2와 같은 용어를 설명 없이 사용하기 시작하거나, 혹은 한 단락 전체를 설명에 할애하는 등 양극단으로 치우침 - 처음 등장할 때 한 문장의 보조 설명을 추가하고, 긴 설명은 3단계의 불렛 포인트(Bullet point)로 분해함

AI는 사실 확인(Fact-check)을 하지 않습니다. 검증 원천인 코드나 로그와 대조하는 확인 작업은 사람의 몫으로 남습니다. 플로우 차트 리뷰 ②를 "가장 무겁다"라고 쓴 이유도 이 때문입니다.

textlint가 잡아낼 수 있는 범위와의 경계

정리하자면, 기계(textlint)와 사람이 담당하는 수비 범위가 나누어져 있었습니다.

• textlint가 잡아낼 수 있었던 것은 문말 표현, 한 문장의 길이, 「が(가)」의 연속, 구두점 주변, 표기 불일치의 일부. - 사람만이 알아챌 수 있었던 것은 A의 "부족함"과 C의 "오류"의 거의 전부, 그리고 B의 구성 판단.

교정의 기계화는 가능하더라도, 기사의 설계와 사실 확인은 사람에게 남는다는 것이 실감입니다.

해본 소감

좋았던 점은 리뷰의 관점이 고정되었다는 것입니다. blog-review가 매번 Front Matter부터 SEO까지 동일한 6가지 관점으로 체크해주기 때문에 놓치는 부분이 줄었습니다. 골자 단계에서 방향성을 바로잡을 수 있는 것도 재작업을 줄이는 데 효과적이었습니다. 사내 지침을 반영한 관점을 집필 단계에서 적용할 수 있어, 제3자 리뷰(④)로 넘어가기 전에 수정할 수 있는 지적 사항이 늘어난 것도 수확이었습니다.

반면 한계도 명확합니다. AI는 문장을 다듬는 데는 능숙하지만, 사실 확인과 "무엇을 말할 것인가"에 대한 판단은 인간이 필수적입니다. 실제로 DSPy 기사에서 독자에게 가치 있는 "고찰"이나 비교표는 AI의 초안을 베이스로 하되, 사람이 크게 손을 대어 완성했습니다.

공정과의 궁합을 정리하면 다음과 같습니다.

• AI에게 맡기기 쉬운 것: 골자 만들기, 정형화된 내용 채우기, 문장 교정, 체크 관점의 망라.
• 사람이 담당해야 하는 것: 사실 확인, 구성의 최종 판단, 고찰 및 스토리의 살 붙이기.

보충

• Skill화에는 유지보수 비용도 든다. 특히 description

（트리거어와 역할）의 조정은 호출 구분(calling)의 정밀도와 직결되므로, 운용하면서 키워나가는 전제가 필요하다. - Skill은 모두 초안 작성과 탐지의 보조에 머문다. 사실 확인과 제3자 리뷰(④)는 생략할 수 없다.

• 참고 링크:

마치며

Claude Code의 Agent Skill로 Zenn 블로그 집필 플로우를 구성하여, 골자(outline)부터 PII(개인정보) 체크까지를 5개의 Skill로 나누어 운용해 보았습니다.

배움을 한마디로 요약하자면, AI 집필의 품질은 「공정 분할 × 인간의 개입점 설계」로 안정된다는 것입니다. 한 번에 쓰게 하는 것이 아니라, 골자·본문·교정으로 공정을 나누고 각각의 경계에서 인간이 리뷰한다. 그리고 AI의 출력물에서 수정이 일어나기 쉬운 부분(부족함·과함·틀림)을 알고 있으면 리뷰의 방향을 잡기가 쉬워집니다.

홍보 (꼭 확인해 주세요!)

마지막으로, Givery AI Lab에서는 독자적으로 보유한 프리랜서·부업의 고단가 AI 프로젝트 소개, 세미나 및 파티 등의 이벤트를 수시로 개최하고 있습니다.

관심이 있으시다면 꼭 Track Works 계정을 등록하여 최신 정보를 받아보세요!

「Track Works」란?

Givery AI Lab의 운영 회사인 주식회사 Givery가 제공하는 프리랜서 엔지니어 프로젝트 매칭 서비스입니다.

AI 시대의 프리랜서 엔지니어로서 「기술(Skill)」과 「실적」을 강화할 수 있는 실천적인 AI 프로젝트를 경력과 기술에 맞춰 소개해 드립니다.

그 외에도 독자적으로 보유한 프리랜서·부업 프로젝트를 소개하거나, AI 관련 기술 및 엔지니어의 커리어에 관한 이벤트를 수시로 개최하고 있습니다.

또한, Givery AI Lab 멤버로서 취업·이직을 검토하시는 경우에는 아래를 통해 지원해 주시기 바랍니다!

(운영 회사인 주식회사 Givery의 엔지니어 대상 채용 공고 목록 페이지입니다)

【기업 담당자님께】

Givery AI Lab에서는 PoC(개념 증명)로 끝나지 않는 「AI의 사회 구현」을 실현하기 위해, AI 개발 프로젝트의 PoC부터 본격적인 구현·운용까지 폭넓게 동반 지원하고 있습니다. 언제든 편하게 문의해 주세요.

AI 개발 프로젝트 동반 지원 서비스:

생성형 AI 기술 관련 고민 해결 서비스 「Givery AI 고문」:

Discussion