2026년 10월 28일 수요일
미단재

AI개발 블로그 글을 스무 번 부탁하고 나서, 스킬로 만들었다

작성자 웅파 작성일 2026-10-28 10:27:30 조회수 5

2026년 10월 28일 · @martin

한 줄 요약 — 같은 부탁을 스무 번 했다면 그건 대화가 아니라 스킬이다. 블로그 글도 예외가 아니었다.

10월 20일부터 열흘 남짓, AI에게 블로그 글을 맡긴 횟수가 스무 편 가까이 된다. dev-issue, prune-branch, 로그 파이프라인, MSA 에러 규약, CI3→CI4 마이그레이션, CNC 문패, 어르신 AI 강의, 26년차 복귀기까지. 주제는 개발과 목공과 일상을 오갔지만 요청 문장은 거의 같았다.

내 기록을 바탕으로 블로그 글 써줘. 이미지 최소 1개(png) 넣어서.

예전에 prune-branch 글에서 이렇게 썼다. 같은 부탁을 세 번 했다면 스킬 후보라고. 그런데 정작 블로그 글은 스무 번 가까이 그냥 넘겼다. 이유는 단순했다. 글감이 이렇게 많을 줄 몰랐다. 블로그 글은 가끔 한 편씩 쓰는 일이라고 생각했고, 가끔 하는 일을 스킬로 만들 이유는 없어 보였다. 그런데 기록을 뒤질 때마다 개발, 목공, 집 이야기까지 쓸 거리가 계속 나왔다. 그사이 나는 매번 같은 설명과 같은 수정을 반복하고 있었다. 이 글은 그 반복을 스킬 하나로 잡은 이야기다.

매번 덧붙인 부탁 다섯 가지

스무 편의 요청을 다시 훑어보니, 본문 주제 말고 매번 따라붙는 조건이 다섯 개였다.

부탁

왜 필요했나

내 기록을 바탕으로

일반론은 AI가 이미 잘 안다. 글의 가치는 내 에러 메시지, 내 실패, 내 결정에서 나온다

코드는 <pre><code class="language-php">로, < > &는 이스케이프

블로그 에디터가 이스케이프 안 된 PHP 코드를 HTML로 해석해 화면에서 지운다

이미지 최소 1개(png)

글 목록 썸네일과 본문 가독성. 다이어그램 하나가 문단 세 개를 대신한다

기록에서 온 것과 AI가 지어낸 것을 나눠서 알려줄 것

1인칭 기술 블로그에서 지어낸 경험담은 독자를 속이는 일이다

이미 쓴 주제는 빼고

주제 추천을 받을 때마다 "그거 벌써 올렸다"를 반복했다

이 중 셋째와 넷째는 거의 모든 글에 들어갔다. 둘째는 코드가 있는 글마다 붙였다. 다섯째는 주제 추천을 받을 때 두 번이나 "제안한 열 개 다 이미 올렸다"고 답해야 했다.

문제는 이 조건을 하나라도 빠뜨리면 결과물이 그만큼 어긋난다는 점이었다. 이미지를 빼먹으면 이미지 없는 글이 오고, 구분 표시를 말하지 않으면 지어낸 일화가 사실처럼 섞여 온다.

내 부탁보다 더 반복된 것: AI 쪽의 수고

내가 반복한 말보다 더 많이 반복된 게 있었다. 매 세션 AI가 처음부터 다시 하는 준비 작업이다.

  • 한글 폰트 확인. PNG에 한글을 넣으려면 서버에 CJK 폰트가 있어야 한다. 세션마다 fc-list :lang=ko로 폰트를 찾고, cairosvg가 없으면 설치했다. 한 세션 안에서 이 확인을 두 번 한 적도 있다.
  • 폰트 인덱스 찾기. Noto Sans CJK는 여러 언어 글꼴이 한 .ttc 파일에 묶여 있다. Pillow로 쓰면 한국어 글꼴이 몇 번째인지 매번 index=0..9를 돌며 찾았다.
  • 겹친 이미지 다시 그리기. CNC 글은 헤더 간격이, 패스키 글은 화살표가, CI3→CI4 글은 카드 크기가, CVE 글은 카드 넘침이 문제였다. 네 번 모두 한 번 그리고, 눈으로 보고, 고쳐서 다시 그렸다.
  • 원본 PNG 따로 보내기. 문서에 넣은 이미지와 별개로, 블로그에 바로 올릴 원본 파일을 매번 따로 받았다.
  • 용어 바로잡기. AICella 글에서 "봉투 형식"이라는 말이 나왔다. response envelope를 직역한 것이다. 앞으로는 "응답 래퍼"로 쓰라고 했지만, 그건 메모리에만 남았고 블로그 작성 절차에는 없었다.

하나하나는 몇십 초짜리다. 하지만 스무 번이면 이야기가 다르다. 그리고 더 큰 문제는 시간이 아니라 일관성이었다. 어떤 글은 Playwright로, 어떤 글은 Pillow로, 어떤 글은 cairosvg로 이미지를 만들었다. 결과물의 톤이 글마다 달랐다.

스킬로 옮기기

말로 하던 다섯 가지는 규칙 파일로, AI가 매번 하던 수고는 스크립트와 순서로 옮겼다. 한 장으로 보면 이렇다.

매번 프롬프트로 하던 말이 blog-post 스킬의 파일과 6단계 순서로 옮겨 간 구조

SKILL.md 본문은 짧게 두었다. 긴 규약은 references로 빼고, 본문에는 순서와 꼭 지킬 규칙만 적는다. api-error-contract 스킬을 만들 때 배운 방식 그대로다.

---
name: blog-post
description: 미단재(jblove.net) 블로그 글을 내 기록으로 쓴다. "블로그 글", "블로그에 올릴",
  "내 기록을 바탕으로" 요청, 또는 주제 추천을 받을 때 사용한다.
---

# 순서
1. 기록 검색 — 메모리 파일과 과거 대화를 먼저 찾는다. 검색어는 제품명·에러 문구 같은 내용어로.
2. 골격 — 한 줄 요약, 본문 섹션, 돌아보며, 이 순서로(체크리스트).
3. 섹션 채우기 — 한 섹션씩. 내 기록에 없는 경험을 1인칭으로 지어내지 않는다.
4. 이미지 — 최소 1장. scripts/render_png.py로 그리고, 반드시 직접 열어 겹침·넘침을 확인한다.
5. 전달 — 문서와 별개로 원본 PNG 파일을 따로 보낸다.
6. 보고 — 답변 끝에 "기록에서 온 것 / 구성한 것"을 나눠 적는다.

# 반드시
- 코드: <pre><code class="language-php">, 코드 안의 < > &는 엔티티로.
  예제가 셸이면 language-bash로 바꾸고 바꿨다고 알린다.
- 용어: references/style.md의 용어집을 따른다. (예: response envelope → 응답 래퍼)
- 주제 추천 전 references/published.md를 읽고 겹치는 주제는 뺀다.

이제 요청은 이렇게 줄었다.

블로그 글 쓰는 스킬을 만든 것 — 내 기록을 바탕으로 써줘.

이미지 조건도, 코드 형식도, 구분 표시도 더 이상 말하지 않아도 된다.

넣은 것, 넣지 않은 것

스킬에 무엇을 넣을지보다 무엇을 빼야 할지가 더 어려웠다.

넣은 것은 매번 같은 판단이다. 코드 형식, 이미지 기준, 구분 표시, 용어집은 글이 바뀌어도 답이 같다. 이런 건 스킬에 적어 두면 세션이 바뀌어도 같은 결과가 나온다.

이미지 검수를 순서에 박은 이유. 기록을 보면 이미지를 한 번에 맞게 그린 적이 드물다. 그래서 "그린 뒤 직접 열어 본다"를 선택이 아닌 단계로 만들었다. 다이어그램을 SVG로 그리고 2배로 렌더링하는 방식도 하나로 정했다. Pillow로 글자를 한 자씩 배치하던 방식보다 겹침을 고치기 쉽다.

뺀 것은 글마다 달라지는 판단이다.

  • 문체와 분량. 기술 글과 에세이, 목공 글은 톤이 다르다. 26년차 복귀기는 손으로 코드를 치던 감각을 아쉬워하는 문장이 필요했다. 이런 건 규칙으로 고정하면 글이 납작해진다.
  • 무엇을 쓸지. 주제 선택은 스킬이 아니라 내가 한다. 스킬은 이미 쓴 주제를 걸러 줄 뿐이다.
  • 블로그 에디터에 올리는 일. 게시는 여전히 내 손으로 한다. 올리기 전에 구분 표시된 부분을 내 경험으로 바꾸는 시간이 꼭 필요하기 때문이다.

규칙 하나는 일부러 두 번 적었다. "내 기록에 없는 경험을 1인칭으로 지어내지 않는다." 이 규칙이 빠지면 스킬은 그럴듯한 글을 더 빨리 찍어 내는 도구가 된다. 그건 내가 원하는 게 아니다.

돌아보며

  1. 세 번 규칙은 글쓰기에도 통한다. 코드 작업에서는 세 번이면 알아챘는데, 글은 스무 번이 걸렸다. 가끔 하는 일이라고 믿었기 때문이다. 앞으로 몇 번 할지 예상하지 말고, 지금까지 몇 번 했는지 세어야 한다.
  2. 내 말보다 AI의 수고를 세어 봐야 한다. 내가 반복한 말은 다섯 가지였지만, 실제로 스킬의 절반을 채운 건 AI가 매번 하던 폰트 확인과 재렌더였다. 대화 기록을 다시 읽어야 보인다.
  3. 메모리와 스킬은 다르다. "응답 래퍼" 교정은 메모리에 남았지만 블로그 절차와는 따로 놀았다. 상황에 묶인 규칙은 그 상황의 스킬에 적어야 확실하다.
  4. 스킬은 품질 하한선이다. 좋은 글을 써 주지는 않는다. 다만 이미지 없는 글, 이스케이프 안 된 코드, 지어낸 일화가 섞인 글은 더 이상 나오지 않는다.
  5. 판단은 넘기지 않는다. 주제를 고르고, 구분 표시된 문장을 내 경험으로 바꾸고, 올릴지 말지 정하는 일은 여전히 내 몫이다.

이 순서로

블로그 글을 AI에게 맡기고 있다면, 이 순서로 스킬을 만들어 보자.

  1. 지난 블로그 요청 대화를 열 개쯤 다시 읽는다.
  2. 주제 말고 매번 덧붙인 조건을 적는다. (형식, 이미지, 톤, 금지 사항)
  3. AI가 매번 처음부터 하던 준비 작업을 적는다. (폰트 확인, 설치, 재시도)
  4. 글마다 답이 같은 것만 골라 SKILL.md와 references로 옮긴다.
  5. 반복되던 준비 작업은 스크립트 하나로 묶는다.
  6. "지어내지 않는다"와 "구분해서 알린다"를 규칙으로 넣는다.
  7. description에 실제로 쓰는 요청 문장을 넣어 스킬이 제대로 불리게 한다.
  8. 다음 글을 짧은 요청으로 시켜 보고, 빠진 규칙을 채운다.

댓글 0개