[Claude Code] /write-post 스킬 설치기

📝 한줄 요약

GitHub에 공유된 Claude Code 스킬 write-post를 설치해서, 그 설치 과정 자체를 첫 사례글로 만들었습니다. 작업이 끝나자마자 사례글 초안이 나온, 일종의 메타 검증입니다.

바쁘시면 이것만 읽어도 돼요:

• GitHub에 올라온 Claude Code용 스킬(/write-post)을 프로젝트에 설치

• 설치 스크립트가 대화형(</dev/tty)이라 그냥 실행이 안 됐고, AI가 스크립트를 직접 읽고 핵심 동작만 수동으로 추출해서 우회

• 설치 위치(전역/프로젝트)를 AI가 임의로 정하지 않고, 사용자에게 선택지를 띄워 의도 확인

• 설치 끝난 뒤 /write-post를 실행해서 만든 첫 결과물이 바로 이 글

• 강의·콘텐츠용 AI 활용 사례글의 생산 사이클이 짧아짐

• 다음 단계는 다른 강의용 스킬도 같은 방식으로 도입, 그리고 직접 만든 스킬도 공개해보기

🎯 이런 분들께 도움돼요

• Claude Code 같은 AI 코딩 도구를 쓰는데 작업 기록을 안 남겨서 나중에 헤매는 분

• AI 활용 사례글이나 강의 콘텐츠를 자주 만들어야 하는 비개발자, PM, 콘텐츠 기획자

• GitHub에 공유된 Claude Code 스킬을 처음 설치해보려는 분

😫 문제 상황 (Before)

강의·콘텐츠 일을 하다 보면 "AI로 이거 이렇게 했었지" 같은 사례를 자주 풀어야 합니다. 그런데 막상 글을 쓰려고 하면 며칠 전 대화 내역을 다시 뒤지고, 어떤 순서로 작업했는지 기억을 더듬고, 캡처도 다시 찾고… 한 편 정리하는 데 보통 30분~1시간이 새어 나갑니다.

이 단계를 좀 자동화하고 싶었습니다. AI가 작업한 흔적은 어딘가에 분명히 남아 있는데, 그걸 매번 사람이 수작업으로 정리하는 게 비효율적이라고 느꼈죠.

마침 daht-mad/write-post라는 Claude Code 스킬이 GitHub에 공개돼 있는 걸 발견했습니다. 작업 세션을 자동으로 파싱해서 DEVLOG를 만들고, 그걸 바탕으로 비개발자용 사례글까지 써준다는 설명. 이거 되면 게임 체인저다 싶어서 일단 설치부터 해봤습니다.

🛠️ 사용한 도구

• 도구명: Claude Code

• 모델: Claude Opus 4.7 (1M context)

• 특이사항: 설치 대상이 Claude Code의 "스킬"이라, 결국 Claude Code 안에서 Claude Code용 도구를 까는 자기참조 상황이었습니다

🔧 작업 과정

시작은 한 줄짜리 요청 — "이 깃허브 링크 설치해줘"

뭘 어떻게 깔아야 하는지 자세히 안 적었습니다. 그냥 링크만 던졌어요.

https://github.com/daht-mad/write-post 설치해주세요

이 한 줄이 진짜 좋은 점은, AI가 알아서 저장소를 들여다보기 시작한다는 거예요. 저는 README를 미리 안 읽었습니다. AI가 대신 읽어주니까요.

AI는 먼저 GitHub CLI(gh)로 저장소 메타데이터를 조회하고, 최상위 파일 트리를 확인했습니다. macOS용 설치 스크립트, Windows용 PowerShell 스크립트, README, 그리고 실제 스킬 파일이 든 .claude/ 폴더까지 식별. 여기까지는 예상한 흐름이었습니다.

그런데 진짜 인상적이었던 건 그다음이었습니다.

첫 번째 "오!" 순간 — AI가 "이 스크립트는 그냥 못 돌립니다"라고 먼저 짚어줌

보통이라면 install_mac.sh를 그냥 실행해버렸을 거예요. 그런데 AI는 스크립트를 한 번 다운로드해서 내용을 먼저 읽었습니다. 그러더니 이렇게 알려주더라고요.

설치 스크립트가 대화형(</dev/tty)이라 직접 실행하기 어려우니, 동일한 작업을 수동으로 처리하면 됩니다.

</dev/tty는 스크립트가 사용자에게 직접 키보드 입력을 받겠다는 신호입니다. 이게 있으면 자동화 환경에서는 입력이 막혀서 스크립트가 그냥 멈춰버려요. 사람이 직접 터미널에서 돌릴 땐 문제없지만, AI 에이전트 안에서는 곤란한 구조입니다.

저는 이 차이를 몰랐고, 그냥 시키면 됐겠지 싶었거든요. AI가 한 단계 먼저 가서 "이대로는 안 되니까 우회하자"고 제안한 게 신선했습니다. 막연히 시도하다 막히는 게 아니라, 막히기 전에 막힐 걸 알아채는 단계가 있다는 걸 본 순간이었어요.

두 번째 "오!" 순간 — "이미 깔려 있어요" 점검부터

다음 단계로 넘어가기 전에, AI는 한 가지를 더 확인했습니다. 제 컴퓨터의 ~/.claude/skills/ 폴더를 들여다보더니, 이미 4월 1일에 설치된 write-post가 있다고 알려줬어요.

이건 솔직히 저도 잊고 있었습니다. 예전에 한 번 깔아두고는 안 쓰고 묻혀 있었던 거죠. AI가 무작정 덮어쓰지 않고 "이미 있는데 어떻게 할까요?"를 먼저 물어준 게 다행이었습니다. 만약 그냥 덮어버렸다면, 혹시 모를 기존 설정이 날아갈 수도 있었을 거예요.

이건 "안전하게 행동한다"는 게 어떤 건지를 보여주는 작은 예시였습니다. 시키지 않은 일을 막 하는 것도 문제지만, 시킨 일이라도 영향 범위가 큰 일은 한 번 확인하고 가는 태도가 보였습니다.

세 번째 "오!" 순간 — 결정을 떠넘기지 않고 명확하게 물어봄

확인을 마친 AI는 곧바로 설치 위치를 묻는 선택지 카드를 띄웠습니다.

어디에 설치할까요?

• 전역 (재설치/업데이트)

• 프로젝트만

• 전역 + 프로젝트 둘 다

이게 왜 좋았냐면, AI가 임의로 "그럼 그냥 전역에 깔겠습니다"라고 결정해버릴 수도 있었거든요. 보통 그렇게 동작하는 도구가 더 많죠. 그런데 여기서는 결정 권한이 큰 갈림길에서 멈추고, 선택지를 명시적으로 보여줬습니다.

저는 "프로젝트만"을 골랐습니다. 검증되지 않은 GitHub 스킬을 일단 격리된 환경에 깔아보고 싶었거든요. 잘 동작하면 그때 전역으로 옮기면 되니까.

프로젝트만

선택을 받자마자 AI는 곧장 실행으로 넘어갔습니다. 대화형 스크립트의 핵심 동작은 결국 curl로 SKILL.md 한 파일을 받아 정해진 경로에 두는 것뿐이라는 걸 이미 파악해뒀던 거죠. 그 한 줄을 직접 실행해서 프로젝트 폴더의 .claude/skills/write-post/ 아래에 28KB짜리 SKILL.md를 깔끔하게 배치했습니다.

설치 끝.

그리고 진짜 메타 한 컷 — 그 다음 명령이 바로 /write-post

스킬이 깔리고 나서 제가 다음으로 한 일은, 방금 깐 그 스킬을 바로 실행하는 거였습니다.

/write-post

이 명령이 한 일은 지금 이 글의 모든 재료를 모은 거예요. 방금 끝난 설치 작업의 대화 세션을 자동으로 스캔해서 DEVLOG.md를 만들고, 그 로그를 바탕으로 저에게 여덟 가지 맥락 질문을 차례로 던졌습니다. "왜 시작했나요?", "막혔던 부분은?", "결과 임팩트는?" 같은 것들이요.

각 질문마다 DEVLOG에서 뽑아낸 추천 답변을 3~4개씩 같이 보여줘서, 저는 거의 다 "4번으로 해줘"라고만 답하면 됐습니다. 글을 쓰고 있는 게 아니라, 선택하고 있었어요.

그래서 지금 여러분이 읽고 있는 이 글은, 글을 쓴 결과물이 아니라 선택의 결과물입니다.

✅ 결과 (After)

Before vs After

결과물

• DEVLOG.md — 설치 과정의 전 단계가 시간순으로 정리된 작업 로그

• AI_CASE_STUDY.md — 지금 보고 계신 이 문서. 비개발자도 읽을 수 있도록 풀어쓴 사례글

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 대화형 스크립트가 막히면, 스크립트를 열어서 핵심 동작만 추출해 수동 실행하기

   • 자동화 환경에서 </dev/tty나 read 같은 사용자 입력 명령이 보이면, 그냥 실행하지 말고 스크립트의 실제 동작이 뭔지 먼저 확인하세요. 대부분은 "어디서 뭘 받아서 어디에 두는 것" 한두 줄이 본질입니다.

2. AI에게 결정을 떠넘기지 말고, 선택지를 묻게 시키기

   • 영향 범위가 큰 결정(설치 위치, 덮어쓸지 말지, 어떤 라이브러리 쓸지)은 AI가 알아서 결정하기 전에 선택지를 띄우게 하는 게 안전합니다. Claude Code의 AskUserQuestion 도구가 그런 용도예요.

3. GitHub에서 받은 스킬은 일단 프로젝트 스코프로 깔아 격리하고, 검증되면 전역으로 옮기기

   • 잘 모르는 스킬을 처음부터 전역에 깔면, 다른 프로젝트에서도 자동으로 작동해 의도치 않은 결과가 날 수 있습니다. 프로젝트 단위로 먼저 격리해서 검증한 다음, 안전하다 싶으면 그때 전역으로 승격시키는 흐름이 좋습니다.

이렇게 하면 안 돼요

1. "그냥 깔아줘"라고만 하고 결과를 안 확인하기 — 어디에 깔렸는지, 기존 버전을 덮었는지 한 번은 봐야 합니다.

2. README를 안 읽고 일단 install 스크립트부터 돌리기 — 스크립트가 뭘 만지는지 모르고 실행하는 건 위험합니다. AI에게 "스크립트 먼저 읽고 요약해줘"부터 시키세요.

3. 첫 시도에서 막히면 그냥 포기 — 막히는 지점에 보통 가장 좋은 학습 포인트가 있습니다. AI에게 "왜 안 되는지 진단해줘"라고 한 번 더 물어보세요.

🌍 다른 업무에 적용한다면?

이번 경험에서 진짜 재사용 가능한 건 "설치"가 아니라 "AI에게 시키기 전에 한 단계 확인부터 시키는 흐름" 입니다.

• 외부 라이브러리/도구 도입할 때: README → 설치 스크립트 → 영향 범위 → 사용자 확인 → 실행 순서로 한 번 거쳐 가게 시키기

• 데이터 처리 자동화: 데이터 샘플 1건을 먼저 보여달라고 하고, 처리 로직이 맞는지 확인한 다음에야 전체 실행

• 문서·콘텐츠 작업: 한 번에 다 써달라고 하지 말고, 맥락 질문을 받게 하고 선택지로 답하는 흐름으로 가기 (이 글이 그 예시)

🚀 앞으로의 계획

1. 루틴화 — 앞으로 모든 AI 작업이 일단락되면 바로 /write-post를 돌려서 DEVLOG와 사례글 초안을 확보합니다. 강의·콘텐츠 자산이 자동으로 쌓이는 구조를 만드는 게 1차 목표.

2. 다른 강의용 스킬도 같은 방식으로 도입 — 시스템에 이미 깔려 있는 quiz-3jong(퀴즈 자동 생성), lecture-outline(강의 개요), feedback-digest(후기 요약) 같은 스킬들도 이번처럼 프로젝트 스코프 → 검증 → 전역 승격 순으로 차례로 적용해서 콘텐츠 제작 파이프라인을 완성할 계획입니다.

3. 직접 만든 스킬 공개 — 받기만 하는 쪽에서 주는 쪽으로 한 발 더 가보고 싶어요. 이번에 익힌 SKILL.md 구조를 바탕으로 강의·콘텐츠 작업자에게 유용한 스킬을 직접 만들어 GitHub에 공개하는 게 마지막 단계입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: GitHub 도구를 안전하게 설치하기

[GitHub 저장소 URL]을 설치해줘. 단, install 스크립트를 바로 실행하지 말고:

1. 먼저 저장소 구조와 README를 요약해서 알려줘

2. 설치 스크립트의 내용을 읽고, 실제로 뭘 만지는지(어떤 파일을 어디에 두는지) 설명해줘

3. 이미 같은 도구가 깔려 있는지 점검해줘

4. 설치 위치 같은 결정은 나에게 선택지로 물어봐줘

5. 내 확인 후에 실행해줘

프롬프트 2: 작업 직후 사례글로 정리하기

방금 진행한 작업을 정리해서 비개발자가 읽기 좋은 AI 활용 사례글로 만들어줘. 조건:

• 사용자 요청 원문은 코드블록으로 보존

• 기술 용어는 풀어서 설명 (예: "API 라우트" → "서버와 통신하는 경로")

• "Before/After" 표로 임팩트를 구체적인 숫자로 보여주기

• 막혔던 부분과 해결 과정도 포함

• 다른 사람이 복사해서 쓸 수 있는 프롬프트 템플릿 1~2개 마지막에 추가

프롬프트 3: 대화형 셸 스크립트 우회하기

[스크립트 URL 또는 파일 경로]를 실행해야 하는데, 대화형 입력(</dev/tty, read)이 들어가서 자동화 환경에서 막혀. 스크립트를 열어보고, 사용자 입력을 받아서 결국 뭘 하려는 건지 핵심 동작을 추출해줘. 그다음 그 핵심 동작만 비대화형 명령으로 실행할 수 있게 명령어 한 줄로 만들어줘. 단, 실행 전에 내가 한 번 확인할 수 있게 명령어부터 보여줘.