AI 26년 차 개발자가 AI에게 블로그 글을 맡기는 방법

2026년 10월 26일 · @martin

한 줄 요약: 글은 AI가 쓰고, 재료는 내 작업 기록에서만 가져오게 한다. 기록에 없는 내용은 AI가 스스로 "이건 지어낸 부분"이라고 밝히게 만든다.

왜 블로그를 AI에게 맡기게 됐나

지난 1년 동안 Claude Code로 솔루션 11개를 혼자 만들었다. 기획부터 서버 배포, 운영까지 전부 내 손을 거친다. 그러다 보니 매일 뭔가를 고치고, 막히고, 해결한다. 문제는 그 경험이 대화창 안에서 끝나버린다는 점이었다.

26년 동안 개발하면서 "이건 글로 남겨야지" 하고 넘긴 게 수백 건은 된다. 실제로 쓴 건 손에 꼽는다. 코드 짜는 시간과 글 쓰는 시간이 같은 자리를 놓고 싸우면, 늘 코드가 이긴다.

그래서 방향을 바꿨다. 글은 AI에게 맡기고, 나는 재료와 검수만 맡는다. 지금 미단재(jblove.net)에 올라가는 개발 글 대부분이 이 방식으로 나온다. Pagus 개발기, prune-branch 스킬, 네이버 연동, 프론트 로그 수집 파이프라인 같은 글들이다.

원칙: 쓰는 건 AI, 재료는 내 기록

AI에게 "Claude Code 활용법 블로그 글 써줘"라고 하면 인터넷 어디서나 볼 법한 글이 나온다. 틀린 말은 없는데 내 글이 아니다. 독자가 내 블로그에 오는 이유는 일반론이 아니라 내가 실제로 겪은 삽질이다.

그래서 요청할 때 항상 한 문장을 붙인다. "내 기록을 바탕으로." 이 한마디로 AI가 하는 일이 바뀐다. 웹을 뒤지기 전에 먼저 두 곳을 본다.

• 메모리 — Claude가 대화에서 정리해 둔 내 프로젝트와 환경 정보. 어떤 제품을 운영하는지, 서버가 몇 대인지, 블로그 이름이 뭔지 같은 것들이다.
• 지난 대화 — 실제로 문제를 풀었던 대화 기록. 에러 메시지, 시도했다 실패한 방법, 최종 해결책이 그대로 남아 있다.

메모리는 용어 습관까지 기억한다. 예를 들어 { status, data, message } 구조를 나는 "응답 래퍼"라고 부른다. 한번 정해두면 이후 글에서 다른 이름으로 쓰지 않는다. 25년 넘게 써 온 내 말투가 글에 그대로 남는 이유다.

작업 흐름: 여섯 단계

처음과 끝은 내가, 가운데 네 단계는 AI가 맡는다. 점선이 이 방식의 핵심이다. 기록에 없는 내용은 그냥 넘어가지 않고 다시 찾거나 내가 채운다.

1. 주제 뽑기 — "최근 작업 내역 보고 블로그 주제 추천해줘"로 시작한다. AI는 이미 올린 글을 빼고, 바로 쓸 수 있는 것과 정리가 더 필요한 것으로 나눠서 준다. 최근에는 공개 저장소 봇 트래픽, 에디터가 CSS를 지워버린 문제, 집 우분투에 셀프호스티드 러너를 올린 이야기 등 11개가 나왔다.
2. 기록 검색 — 고른 주제로 메모리와 지난 대화를 검색한다. 키워드 하나로는 잘 안 걸린다. "worktree 브랜치 정리 원격", "gh pr list merged"처럼 여러 번 좁혀 들어가야 실제 해결 과정이 나온다.
3. 골격 세우기 — 본문을 쓰기 전에 섹션 제목과 각 섹션에 들어갈 내용만 먼저 잡는다. 내 글은 대체로 같은 뼈대를 쓴다. 한 줄 요약 → 단계별 본문 → 돌아보며 → 이 순서로.
4. 섹션 채우기 — 한 번에 전체를 쓰지 않고 섹션 하나씩 채운다. 쓰는 도중에 방향이 틀어지면 그 섹션에서 바로 멈출 수 있다.
5. 이미지 — 아키텍처나 흐름은 다이어그램으로 그리고 PNG로 뽑는다. 한글이 깨지지 않게 CJK 폰트로 렌더링하고, 블로그용으로 흰 배경에 2배 해상도로 만든다. 이 글의 그림도 같은 방식이다.
6. 검수 · 게시 — AI가 표시한 "기록에 없는 부분"을 읽고, 내 실제 경험으로 바꾸거나 지운다. 그다음에 올린다.

요청은 짧게, 규칙은 분명하게

요청 문장은 길 필요가 없다. 내가 실제로 쓰는 형태는 대략 이렇다.

prune-branch 스킬이 생긴 배경 - 내 기록을 바탕으로 블로그에 올릴 글 작성해줘.
코드는 <pre></pre> 로 감싸고, 코드 안의 < > & 는 이스케이프해줘.

중요한 건 길이가 아니라 형식 규칙이다. 내 블로그 에디터는 코드 블록을  형태로 받는다. 
코드 안의 <, >, &를 엔티티로 바꾸지 않으면 PHP 코드가 HTML로 해석돼 화면에서 사라진다. 
이 규칙을 한 번 정해두니 붙여넣고 바로 올릴 수 있게 됐다.

AI가 규칙을 무작정 따르지 않는다는 점도 좋았다. prune-branch 글은 예제가 셸 스크립트와 SKILL.md였다. AI는 language-php 대신 language-bash, language-markdown을 쓰고, 왜 바꿨는지 따로 알려줬다. 지시를 지키는 것과 맞게 쓰는 것이 부딪힐 때, 말없이 고르지 않고 물어보는 쪽이 낫다.

기록이 없을 때가 진짜 시험이다

가장 위험한 순간은 기록이 없는데 글은 써야 할 때다. AI는 빈칸을 그럴듯한 내용으로 채우는 데 능하다. 1인칭으로 "이렇게 해결했다"고 쓰면 독자는 그게 내 경험인 줄 안다.

실제로 두 번 그런 상황이 있었다. 

• 네이버 연동 글 — 소셜 로그인, 쇼핑 검색 API, 서치어드바이저 인증 세 가지를 다루려 했다. 그런데 과거 대화를 아무리 뒤져도 이 작업 기록이 거의 없었다. AI는 공식 문서와 뉴스를 찾아서 글을 쓰되, 끝에 세 가지를 나눠서 밝혔다. 출처로 확인한 내용, 내 기록에서 온 내용, 경험담처럼 쓰였지만 일반 지식인 내용. 쇼핑 API 종료 날짜는 원문을 못 열었으니 게시 전에 직접 확인하라는 말도 붙였다.
• AI 메모리 파일 글 — ".env 값에는 따옴표", "error_log를 믿지 마라" 두 교훈을 다루는 글이었다. 이 두 건도 기록에서 찾지 못했다. AI는 예시로 만든 장면 세 군데를 콕 집어서, 내 실제 경험으로 바꿔 달라고 했다.

나는 이걸 규칙으로 굳혔다. 기록에서 온 것과 AI가 구성한 것을 반드시 나눠서 알려줄 것. 이 표시가 있으니 검수가 빨라진다. 전체를 의심하며 읽을 필요 없이, 표시된 부분만 보면 된다.

돌아보며

1. 글의 가치는 재료에서 나온다. AI의 문장력은 이미 충분하다. 차이를 만드는 건 그 안에 내 에러 메시지, 내 실패, 내 결정이 들어 있느냐다.
2. 기록이 쌓일수록 글이 쉬워진다. 대화에서 문제를 풀 때마다 그게 다음 글의 재료가 된다. 따로 메모할 필요가 없다는 게 가장 큰 변화였다.
3. 구분 표시가 검수 시간을 줄인다. "이 부분은 지어냈다"는 표시 하나로, 의심하며 읽던 시간이 확인만 하는 시간으로 바뀐다.
4. 형식 규칙은 한 번만 정하면 된다. 코드 블록 형태, 용어, 글 뼈대를 정해두면 매번 설명하지 않아도 된다.
5. 쓰는 일을 넘겨도 판단은 내 몫이다. 무엇을 쓸지, 무엇을 지울지, 올릴지 말지는 여전히 내가 정한다. 26년 동안 쌓은 건 코드보다 이 판단이다.

이 순서로 해보세요 

• 평소 문제를 AI와 대화하며 푼다. 에러 메시지와 시도한 방법을 대화에 그대로 남긴다.
• AI의 메모리 기능과 지난 대화 검색 기능을 켠다.
• 블로그 형식 규칙을 정한다. 코드 블록 태그, 이스케이프, 자주 쓰는 용어, 글 뼈대.
• "최근 작업 보고 블로그 주제 추천해줘"로 후보를 받는다. 이미 쓴 글은 빼달라고 한다.
• 주제를 골라 "내 기록을 바탕으로 글 작성해줘"라고 요청한다.
• 기록에서 온 내용과 AI가 구성한 내용을 나눠서 표시해 달라고 한다.
• 흐름이나 구조는 다이어그램 PNG로 받는다.
• 표시된 부분을 내 경험으로 바꾸거나 지운 뒤 게시한다.

글 쓰는 시간이 없어서 기록을 못 남기던 26년이었다. 이제는 일하는 과정이 곧 글의 재료다.