기술 블로그 리뷰는 팩트 체크, 구조 분석, 스타일 교정을 반복하는 작업입니다. 정확하게 하려면 시간이 오래 걸리고, 대충 하면 브랜드에 영향을 줄 수 있죠.
그동안 저는 AI와 함께 기술 블로그를 리뷰했습니다. 그러나 엄밀한 의미의 자동화는 아니었죠. 제가 글 전체를 읽고 의견과 수정 포인트를 정리한 다음, AI에게 제 리뷰의 타당성을 검토받았습니다. 그다음, AI에 수정 방향을 제시하고, 결과물을 검 토하며, 추가 수정을 거쳐 최종본에 반영했죠. 새로운 내용을 추가하면 정확성을 반드시 교차 확인했습니다. 내용의 정확성은 기술 기업의 브랜드 이미지에 영향을 미칠 수 있고요. 콘텐츠 품질은 SEO뿐만 아니라 잠재 고객의 신뢰와도 연결되기 때문입니다.
이 과정은 많은 주의와 긴 시간을 요합니다. 기술 블로그 외에 다른 작업도 수행해야 하므로 여기에 쓰는 시간을 효율화해야 했죠. 마침, 인포그랩은 DevOps 전문 기업을 넘어 AI 네이티브 기업으로 도약하고 있는데요. 전사적으로 Claude Skills 개발을 권장하고 있습니다. 저 역시 이 흐름에 발맞춰 제 업무를 일주일에 1~2개씩 Claude Skills 기반 자동화 워크플로로 만들게 됐죠. 기술 블로그 리뷰 Skill이 탄생한 이유도 이러한 배경 때문입니다.
이 글에서는 제가 기술 블로그 리뷰 Skill을 만든 과정, 시행착오, 개선 경험을 공유하려 합니다. ‘완성된 성공 사례’가 아닌, ‘진행 중인 실험’의 기록입니다.
Skills 기반 리뷰 자동화 배경
저는 기술 블로그 리뷰 Skill로 다음 문제를 해결하고 싶었습니다.
시간과 품질의 딜레마
리뷰는 반복 작업입니다. 그러나 매번 변수가 달라 단순 반복 작업은 아닌데요. 기술 블로그는 저자의 전문 지식과 고유한 관점이 담긴 콘텐츠라 글마다 내용과 분량, 스타일이 다르죠. 체크리스트가 있어도 글마다 맥락이 달라 일률적으로 적용하기 어렵고요. 리뷰어가 매번 글의 맥락을 파악하고 판단해야 해 소요 시간을 예측하기 쉽지 않습니다. 분량이 많아도 스타일만 수정하면 빠르게 끝날 수 있고요. 내용이 길고 구조적으로 수정할 사항이 많으면, 시간이 오래 걸립니다. 분량이 짧아도 보완이 필요한 내용이 있으면 이를 추가하고 정확성을 확인해야 해 공수가 들어가죠. 리뷰에 시간을 많이 쓰면 다른 업무가 밀리고, 시간을 줄이면 콘텐츠 품질을 타협해야 할 수 있는데요. 이 문제를 개선하고 싶었습니다.
AI 수동 리뷰의 비효율
기존에도 AI를 리뷰에 활용했지만, 작업 방식은 비효율적이었습니다. 맞춤화된 시스템 프롬프트를 탑재한 AI 모델에 내용을 섹션별로 나눠 리뷰했는데요. 글 전체 내용을 그대로 입력하면 컨텍스트가 많아 AI 리뷰와 제안의 품질이 낮았기 때문이죠. 섹션별로 나눠서 입력하면 AI 리뷰와 제안이 구체적이고, 실질적으로 유용했습니다. 그러나 이를 수동으로 진행하면, 분량이 길수록 시간은 오래 걸렸죠. 특히 잦은 릴리즈로 용어나 기능이 종종 바뀌는 솔루션은 최신 정보를 실시간 웹 검색으로 확인해야 했는데요. 이를 여러 AI 모델로 교차 점검해 정확성을 보장하려면 시간이 더 소요됐습니다. 이에 Claude Skills로 단계별 리뷰 프로세스를 하나의 자동화 파이프라인으로 연결해 이 과정을 효율화하고 싶었습니다.
머릿속에 머무는 경험 지식
콘텐츠 리뷰 체크리스트를 사내에 공유하지만, 자세한 업무 컨텍스트는 사람의 머릿속에 있을 때가 많습니다. 대부분 업무에는 매뉴얼을 넘어서는 경험 지식이 있죠. 이 경험 지식이 체계화되지 않고, 전체적으로 공유되지 않으면 조직의 업무가 한 사람의 개인기에 의존하게 되고요. 인력 공백이 발생하면, 업무 공백마저 생겨 조직의 업무 체계가 흔들릴 수 있습니다. 사람은 가도 시스템이 남아야 하는데, 그 시스템이 불충분한 상태가 될 수 있죠. 그러나 Claude Skills를 활용하면 Skill 생성 과정에서 업무 컨텍스트를 자동으로 문서화할 수 있는데요. 자연어로 요구사항을 입력하기만 하면 돼 문서화 부담을 덜고, 유지보수도 간편하죠. 이를 활용하면 리뷰 업무의 지식 공유 체계를 수월하게 구축할 거로 기대됐습니다.
리뷰 Skill 설계 방식
저는 아래 실행 흐름과 컨텍스트 구조에 따라 기술 블로그 리뷰 Skill을 설계했습니다.
실행 흐름
저는 리뷰 Skill의 워크플로를 다음과 같이 구성했습니다.
- 참조 파일 로드: 리뷰 체크리스트, 스타일 가이드, 출력 템플릿을 읽어 리뷰 기준을 설정합니다.
- 콘텐츠 가져오기: Notion API로 기술 블로그 내용을 가져옵니다.
- 리뷰 수행: 구조 분석, 팩트 체크, 스타일 교정을 체크리스트 기준으로 수행합니다.
- 인라인 코멘트: 리뷰 결과를 Notion 페이지에 인라인 코멘트로 남깁니다. 각 코멘트에는 태그, 판단 근거, 수정안, 출처를 포함합니다.
- 리뷰 리포트: 전체 평가 점수, 강점/약점, 팩트 체크 결과를 정리한 리포트를 생성합니다.
- 수정 반영: 리뷰어가 승인하면, 수정 제안을 Notion 페이지에 직접 반영합니다.
기존에는 이 과정을 섹션별로 수동 반복했지만, Skill로 만들면 명령어 하나로 전체 흐름을 실행할 수 있습니다.
컨텍스트 구조
Skill을 설계할 때 사내 테크니컬 라이팅 가이드, 콘텐츠 리뷰 체크리스트, 기존 리뷰에 활용하던 커스텀 AI의 시스템 프롬프트, 제가 리뷰 시 중점적으로 확인하는 항목과 원하는 결과를 모두 입력해 컨텍스트에 반영하도록 요청했습니다. 참조 파일은 다음과 같이 분리했습니다.
| 파일 | 역할 | 내용 |
|---|---|---|
| SKILL.md | 지휘 | Role(역할), Goal(목표), Constraints(제약 조건), Workflow(워크플로) 정의 |
| review-checklist.md | 검증 기준 | 구조, 콘텐츠, 기술 정확성, 가독성, 시각 자료 체크리스트 |
| style-guide.md | 교정 규칙 | 어조, 한국어 교정, 문장 구조, 표현 규칙 |
| output-templates.md | 출력 형식 | 리포트, 팩트 체크표, 코멘트 형식 템플릿 |
하나의 파일에 모든 내용을 담으면 컨텍스트가 비대해져 AI의 출력 품질이 떨어질 수 있습니다. 따라서 ‘무엇을 검증할지(체크리스트)’, ‘어떻게 교정할지(스타일 가이드)’, ‘어떤 형식으로 출력할지(출력 템플릿)’로 분리해 각 파일이 하나의 역할만 담당하게 설계했습니다.
SKILL.md는 이 파일들을 조율하는 역할을 합니다. AI에게 리뷰어의 Role(10년 이상 경력 기술 블로그 에디터), Goal(콘텐츠 품질, SEO 최적화 등), Constraints(뻔한 일반론 금지, 과도한 일반화 금지 등)를 부여하고, 어떤 순서로 참조 파일을 읽고 작업할지 워크플로를 지시하죠.
실행 결과
기술 블로그 리뷰 Skill을 만들어 테스트해 봤습니다. 기대한 대로 작동하는 부분도 있었지만, 한계도 여럿 있었습니다.
표면적 수준에 그친 리뷰
리뷰가 표면적인 수준에 그쳤습니다. 글의 구조를 분석하고, 내용 배치를 수정하거나, 누락된 필수 내용을 짚어내는 근본적 리뷰는 부족했는데요. 간단한 문구 수정 등 스타일 교정이 많았죠. 구조 검증 항목을 포함해 방대한 컨텍스트를 구축해도, 실제 리뷰 결과에 충실히 반영되지 않았습니다. 제가 글을 처음 읽을 때 든 생각과 수정 방향을 AI도 동일하게 봐주길 원했지만, 결과물은 표면적 교정에 머물렀습니다.
참조 파일을 건너뛰는 AI
참조 파일을 읽지 않을 때도 있었습니다. AI가 알아서 참조 파일을 로드하다 보니, 스스로 불필요하다고 판단하면 이를 건너뛰고 리뷰하기도 했죠. 성능 최적화를 위해 부득이한 결정이기도 했겠지만, 체크리스트와 스타일 가이드를 꼼꼼히 읽지 않으면 리뷰 완성도가 떨어질 수밖에 없었습니다. 짚어야 할 내용도 당연히 누락되고요.
컨텍스트 과다에 따른 성능 저하
초기에는 제가 생각하는 리뷰의 모든 것을 다 컨텍스트에 담으려 했는데요. 최대한 상세하게 지시할수록 결과물이 좋을 거로 예상했기 때문입니다. 그러나 컨텍스트 분량이 많아도 AI의 리뷰는 핵심을 놓치고 있었는데요. 컨텍스트 최적화를 조사하면서 실마리를 얻었습니다. 이는 별도 항목에서 자세히 소개하겠습니다.
공감되지 않는 수정 요구
AI 리뷰 내용이 공감되지 않을 때도 있었습니다. 저자의 개성 있는 문체까지 수정을 요구하는 게 그 예인데요. 지나치게 구어체거나, 기업 공식 블로그의 격에 영향을 미칠 수준이라면 수정하는 게 적절할 수 있습니다. 그러나 전혀 문제가 없는 자연스러운 표현도 딱딱한 문어체로 고치라는 피드백이 있었죠. 참조 파일에서 요구한 톤 앤 매너를 엄격하게 적용하다보니 글의 개성을 보존하는 유연함이 아쉬웠습니다.
이러한 한계를 고려했을 때, 리뷰 Skill의 만족도는 약 50% 수준이었습니다. 자동화의 틀을 갖췄지만, ‘믿고 쓸 수 있는 수준’은 아니라고 판단했습니다.
개선 과정
저는 위 문제를 해결하기 위해 두 가지 방향으로 기술 블로그 리뷰 Skill을 개선했습니다. 컨텍스트 최적화와 Skill 실행 시 프롬프트의 단계적 활용이 그 내용입니다.
컨텍스트 최적화
스킬 개발 과정에서 저는 컨텍스트 최적화 방법을 마침 조사하게 됐습니다. AI의 성능을 높이려면 컨텍스트를 무조건 많이 넣기보다, 핵심 내용을 구조화해서 넣어야 한다는 걸 알게 됐죠. 이로써 컨텍스트를 경량화할 필요성도 느꼈습니다. 이러한 방향에 따라 다음 네 가지 작업을 수행했는데요.
- 파일 간 역할 경계 재정의: 처음 Skill을 구축할 때는 SKILL.md에 상세 지시 내용이 집중돼 있었습니다. 이를 참조 파일로 분산, 재배치했는데요. 이로써 SKILL.md는 핵심 지침만 남겨 200줄에서 95줄로 절반 이상 줄였고요. 다만 실제 리뷰 노트를 참조 파일에 반영하면서 전체 컨텍스트 분량이 한때 1071줄로 늘어났습니다. 그러나 중복과 불필요한 내용을 정리해 이를 775줄로 28% 줄였죠.
- 제약 조건 구조화: 기존에는 금지 사항이 있어도 여러 파일에 흩어졌는데요. 이를 SKILL.md의 Constraints 섹션으로 모아 AI가 명확히 인식하도록 했습니다.
- 참조 파일 필수 로드 강제: 워크플로 0단계에 “리뷰 시작 전 반드시 참조 파일 3개를 모두 읽어라”는 지시를 추가했습니다. AI가 자율적으로 판단해 파일을 건너뛰는 문제를 구조적으로 방지하려 했습니다.
- 실제 리뷰 노트, 체크리스트 반영: 실제 기술 블로그를 리뷰하면서 남긴 노트 중 반복 패턴을 추출해 체크리스트에 반영했습니다. 예를 들어, ‘도입부와 본론의 연결이 끊기는 문제’, ‘기술 활동을 언급하면서 의미를 설명하지 않는 문제’와 같은 항목을 추가했습니다.
단계적 리뷰 프롬프트 구성
컨텍스트를 최적화해도 명령어 한 번에 완벽한 리뷰 결과를 얻기는 어려웠습니다. Skill이 1차 리뷰를 수행한 뒤, 결과를 보고 추가 프롬프트를 단계별로 입력해야 기대치에 가까운 결과를 얻을 수 있었는데요. 그 내용은 다음과 같습니다.
- 1차 구조적 리뷰 우선 요청: 리뷰를 시작할 때 “표면적 리뷰는 하지 말고, 글의 구조와 내용 배치, 필수 내용 누락 등 구조적인 문제부터 먼저 봐달라”고 요청합니다. 표면적 리뷰에 그쳤던 문제를 프롬프트 수준에서 해결하는 방법이죠.
- 2차 수정안 요청: 1차 리뷰를 토대로 “쉽게 수정할 수 있도록 수정안 예시를 작성해 달라”고 요청합니다. 이때 “정확도 100% 내용으로 작성해 달라”는 조건을 추가합니다.
- 3차 스타일 리뷰: 구조적 수정이 완료된 뒤, 문장과 표현 등 스타일 관련 리뷰가 부족해 보이면 이를 추가로 요청합니다.
- 4차 누락 확인: 리뷰 코멘트가 달리지 않은 부분에 “정말 문제가 없는지 확인해 달라”고 요청합니다.
- 5차 이의 제기: 리뷰 완료 시 문제 있는 리뷰에 이의를 제기합니다. “글쓴이의 개성을 너무 반영하지 않은 리뷰는 아닌가?”, “과도한 수정 요구는 아닌가?”라고 되물어 최종 조율합니다.
위 프롬프트를 단계별로 실행하니 명령어 하나로 Skill을 단독 실행할 때보다 리뷰 품질이 개선됐습니다. 글의 구조적 리뷰가 강화됐고요. 리뷰가 부족하거나, 코멘트가 아예 달리지 않은 부분에도 리뷰를 추가했죠. 이의 제기에는 수긍하며 유연한 태도를 보였습니다.
맺음말
기술 블로그 리뷰 Skill은 프로덕션에서 완전히 믿고 쓸 만한 수준은 아닙니다. 컨텍스트를 자세하게 구성하고, 프롬프트를 정교화하는 과정을 거쳤지만, 결과물이 제 기준을 충족하지 못할 때가 많습니다. 사람이 중요하다고 생각하는 것을 AI도 동일하게 ‘중요하다’고 인식하게 하는 일, AI의 제안이 저자에게 공감이 가도록 만드는 일은 풀어야 할 과제죠.
그래도 Skill을 만들며 얻은 게 있습니다. Claude Skills의 장점은 업무 컨텍스트를 쉽고 간편하게 문서화할 수 있다는 건데요. Skill을 만들면서 SKILL.md나 체크리스트, 스타일 가이드 등 참조 파일을 체계적으로 구축할 수 있었죠. 이러한 컨텍스트는 인수인계서 역할도 할 수 있고요. 나중에 다른 팀원이 이 파일을 보고 업무 맥락을 파악하고, 조직의 원칙과 지향점을 이해하며, 후속 업무를 수행하고, 업무 수행 방식을 개선하는 데 도움이 될 수 있습니다.
앞으로 제 목표는 Skill의 성능 만족도를 100%에 가깝게 끌어올리는 건데요. 이를 위해 컨텍스트를 지속적으로 최적화하고, Skill을 잘 사용하기 위한 매뉴얼도 정리할 계획입니다. 또 Claude Skills를 넘어서는 더 나은 도구가 등장하면, 유연하게 전환하도록 컨텍스트를 정리하고, 규칙적으로 업데이트하려 합니다. 도구가 바뀌어도 문서화된 컨텍스트는 남고, 이는 다른 도구나 다른 유사 Skill을 만들 때도 활용할 수 있죠.
Skill을 만들며 크게 느낀 점은 ‘자기 문제는 스스로 해결해야 한다’는 것입니다. 바이브 코딩은 비엔지니어도 자기 문제를 직접 정의하고, 해결 방안을 간편하게 구현하며, 실무에 적용하는 길을 열었습니다. 다른 전문가가 내 문제를 해결해 줄 수 있지만, 내 Pain Point를 내 처지에서 이해하고, 이에 딱 맞춘 결과물을 만들어 주기는 어려울 수 있습니다. 도메인을 이해하는 사람이 ‘결자해지’하는 자세로 직접 문제를 해결하려 할 때, 가려운 곳을 정확하게 긁어주는 결과물을 내 눈높이에 맞춰 만들 수 있습니다.
우리 회사에 딱 맞는 DevSecOps 관행과 프레임워크를 찾고 계시나요? DevOps 전문가, 인포그랩과 상담하세요!