/article

이 순서대로 작업해 줘
이 정보는 내보내지 마
여기서는 반드시 확인해 줘
...

---
title: "기사 제목"
emoji: "📝"
type: "tech"
topics: ["claudecode"]
published: false
---

## 자동화해서 좋았던 점

이 스킬을 만들어서 좋았던 점은, 기사를 쓰는 허들이 상당히 낮아졌다는 것입니다.

기술 기사를 쓸 때는 의외로 첫걸음이 무겁거든요.

"무엇을 쓸까"

"어디서부터 설명할까"

"이 내용, 기사로 쓸 정도인가"

같은 생각을 하는 사이에, 결국 쓰지 않고 끝나버리는 경우가 많습니다.

하지만 Claude Code와의 상호작용에는 매번 작은 배움이 있습니다.

- 에러의 원인을 알게 되었다
- 사양 (Specification)을 읽는 법을 알게 되었다
- 라이브러리의 동작을 이해했다
- 설계상의 주의점을 깨달았다
- 이전보다 조금 더 나은 작성법을 알게 되었다

이런 것들은 그 자리에서는 작게 보입니다.

하지만 나중에 되돌아보면 충분히 기사가 됩니다.

`/article`을 만들어 두면, 그 작은 배움을 흘려보내지 않고 일단 초안으로서 남겨둘 수 있게 됩니다.

"제대로 된 기사를 쓰겠다!"가 아니라,

**오늘의 배움을 일단 초안으로 만든다**

정도의 가벼운 마음가짐으로 시작할 수 있어서 좋았습니다.

## 반대로, 자동화하지 않기로 결정한 것

편리하긴 하지만, 모든 것을 자동화하는 것은 위험하다고 생각했습니다.

특히 기술 기사는 외부로 나가는 것입니다.

Claude Code와의 대화에는 사내 코드, 사양 (Specification), URL, 에러, 조사 로그 등이 섞일 수 있습니다.

그것을 그대로 기사로 만들면 당연히 사고가 납니다.

그래서 이번에는 "자동화하는 부분"과 "사람이 확인하는 부분"을 나누었습니다.

Claude Code에게 맡기는 부분:

- 세션을 되돌아보기
- 배움을 하나 선택하기
- 기사 형태로 만들기
- 기밀로 보이는 정보를 제거하기
- 초안으로 저장하기

사람이 확인하는 부분:

- 외부로 내보내도 되는 내용인지 확인하기
- 사내 정보가 남아있지 않은지 보기
- 기술적으로 틀리지 않았는지 확인하기
- 공개해도 될지 판단하기

자동화의 목적은 확인을 없애는 것이 아니라,

**확인하기 전의 번거로운 작업을 줄이는 것**

이라고 생각합니다.

이 부분을 잘못 잡으면 편리한 메커니즘이 아니라 위험한 메커니즘이 되어버리기 때문에 상당히 주의했습니다.

## 자신을 위해 정한 안전 규칙

이번 스킬에서는 저 자신을 위해 몇 가지 규칙을 정했습니다.

### 공개 판단은 Claude Code에게 맡기지 않는다

기사 초안은 Claude Code가 작성하게 합니다.

하지만 공개해도 될지 여부는 스스로 판단합니다.

`published: false`로 push하는 단계까지는 OK.

`published: true`로 만드는 것은 별도의 명령어로 명시적으로 실행하도록 했습니다.

이 부분은 반드시 분리하는 것이 좋다고 생각합니다.

### 업무 정보는 그대로 사용하지 않는다

업무 중에 발생한 에러나 코드를 기사로 쓰고 싶은 경우라도, 그대로 사용하지 않습니다.

예를 들어, 실제 업무 코드가 아니라,

- Todo 앱
- 샘플 User 모델
- 가상의 API
- 일반적인 Rails 예시

같은 형태로 대체합니다.

독자가 알고 싶은 것은 사내의 구체적인 사양 (Specification)이 아니라,

**왜 막혔는지, 어떻게 생각하면 피할 수 있는지**

라고 생각하기 때문입니다.

### push 전에 "공개 리뷰"를 한다

push 전 확인 단계에서는 문장의 유려함보다 먼저, 우선 공개해도 되는지를 봅니다.

확인 포인트는 다음과 같습니다.

- 회사 이름이 들어있지 않은가
- 사내 리포지토리 이름이 들어있지 않은가
- 내부 URL이 들어있지 않은가
- 고객 정보가 들어있지 않은가
- 운영 환경 (Production) 정보가 들어있지 않은가
- 에러 문구에 고유 정보가 섞여있지 않은가
- 코드 예시가 너무 구체적이지 않은가

기술적인 가독성은 그 다음입니다.

가장 먼저 봐야 할 것은,

**이 기사를 외부에 내보내도 괜찮은가**

라고 생각합니다.

## Zenn 연동에 대하여

Zenn에는 GitHub 연동 기능이 있어서, 기사용 리포지토리를 연동해 두면 Markdown을 push하는 것만으로 기사가 반영됩니다.

대략적인 흐름은 다음과 같습니다.

그 후, Zenn의 배포(deploy) 설정에서 GitHub 리포지토리(repository)를 연동합니다.

이렇게 하면, `articles/`

하위의 Markdown을 push하면 Zenn에 반영됩니다.

로컬(local)에서는 `npx zenn preview`

로 확인할 수 있습니다.

다만, 저는 여기서도 반드시 `published: false`

로 설정해 둡니다.

push하면 반영되는 메커니즘은 편리하지만, 편리한 만큼 두려움도 있습니다.

그래서 처음부터 "초안(draft)으로 반영한다"는 전제로 두는 것이 안심되었습니다.

## 요약

Claude Code의 스킬(Skill)을 다뤄보며 얻은 가장 큰 배움은 이것이었습니다.

**스킬은 코드를 작성하는 것이라기보다, Claude Code에게 전달하는 Markdown 절차서였다.**

매번 Claude Code에게 부탁하고 있는 작업이 있다면, 그것을 `SKILL.md`

로 만들어 두는 것만으로 재사용할 수 있습니다.

이번에는 그 예시로서, Claude Code와의 세션(session)에서 얻은 배움을 Zenn 기사 초안으로 만드는 `/article`

스킬을 만들었습니다.

하는 일은 간단합니다.

- 세션을 되돌아보기
- 배움을 하나 선택하기
- 기사 Markdown으로 만들기
- 기밀 정보 제거하기
- 초안으로 push하기

단, 공개 여부 판단까지 자동화하지는 않습니다.

AI에게 맡기는 것은 기억하기, 정리하기, 초안으로 만들기까지입니다.

외부로 내보내도 될지는 인간이 확인합니다.

이 선을 그어 두니 Claude Code의 스킬을 상당히 편리하게 사용할 수 있다는 느낌을 받았습니다.

"스킬"이라고 하면 조금 어려워 보일 수 있지만, 실제로는 Markdown 절차서부터 시작할 수 있습니다.

우선 자신이 매번 Claude Code에게 부탁하고 있는 작은 작업 하나를 `SKILL.md`

로 만들어 보는 것.

그 정도의 가벼운 마음으로 시작해 보는 것이 딱 좋을 것 같습니다!

## 참고 기사

이번 `/article`

스킬은 Claude Code의 스킬 기능과 Zenn 기사 작성을 자동화하는 사례를 참고하여 만들었습니다.

특히 도움이 된 점은 Claude Code의 Skills는 `SKILL.md`

에 절차를 적음으로써 호출할 수 있다는 것, 그리고 Zenn 기사에서는 `published: false`

를 기본값으로 설정해 두면 안전하게 운용하기 쉽다는 점이었습니다.

### Discussion

![](https://static.zenn.studio/images/drawing/discussion.png)