저는 혼자서 WordPress 플러그인을 제작하며, 코드를 더 빠르게 작성하려는 명백한 이유로 Claude Code를 사용하기 시작했습니다. 6개월이 지난 지금, Claude Code가 실제로 저를 도와준 부분은 코드가 아니었습니다. 그것은 코드 주변의 모든 것이었습니다.

매 릴리스(release)마다 저는 똑같은 작은 과정을 거쳤습니다. 버전을 올리고, readme를 업데이트하고, 변경 사항(changelog)을 작성하고, 번역 파일에 누락된 부분이 있는지 확인하고, 공지 사항 초안을 작성하는 일들 말입니다. 이 중 어려운 것은 하나도 없습니다. 하지만 모두 번거로운 작업들이며, 이러한 잡무 하나하나가 실제로 무언가를 만들고 있는 제 뇌의 상태에서 저를 끌어내었습니다. 릴리스 의식을 마치고 다시 코드로 돌아올 때쯤이면, 방금 놓아버렸던 전체적인 정신적 맥락(mental context)을 다시 불러와야만 했습니다.

그 재로딩(reload)이야말로 진짜 비용이며, 이를 깨닫는 데 시간이 좀 걸렸습니다. 잡무는 단순히 그 자체의 시간만 잡아먹는 것이 아닙니다. 그것들은 당신의 머릿속에서 코드를 쫓아내 버리고, 당신은 그것을 다시 불러오기 위해 비용을 지불해야 합니다. 그래서 저는 코드가 아닌 잡무들을 Claude Code에게 넘기기 시작했고, 그것이 제대로 작동하는 방식이었습니다.

릴리스를 조용히 망가뜨리는 잡무

제가 가장 실수하고 싶지 않은 것은 버전 불일치(version mismatch)입니다. WordPress 플러그인에서 표시되는 버전은 메인 PHP 파일의 Version 헤더에서 가져오지만, readme의 Stable tag는 어떤 태그된 버전이 "안정적(stable)"인지를 가리킵니다. 이 둘은 서로 다른 역할을 하는 두 개의 별개 필드이며, 이들이 서로 일치하지 않으면 사용자에게 업데이트가 잘못 전달될 수 있습니다. 오류가 발생하지도 않습니다. 버그 리포트를 통해서야 알게 될 뿐입니다.

이것은 넘겨주기에 완벽한 잡무입니다. 왜냐하면 판단이 필요 없는 순수한 확인 작업이기 때문입니다. 저는 단계들을 파일에 기록해 두고, 매 릴리스 전에 Claude Code가 이를 실행하도록 합니다.

• 메인 파일의 Version이 의도한 릴리스와 일치하는가
• readme의 Stable tag가 올바른 것을 가리키고 있는가
• 최상단 changelog 항목이 실제로 이 버전인가
• Tested up to가 현재 안정적인 WordPress를 추적하고 있으며, 설정되어야 할 것보다 높게 설정되어 있지는 않은가

중요한 나머지 절반은 제가 여기에 첨부하는 지침입니다. 불일치 사항을 드러내되, 직접 수정하지는 말 것. 파일과 줄 번호를 보여주고, 최종 결정은 제가 내리도록 할 것. 잘못된 추측이 사용자에게 배포되는 단 한 번의 단계에서 자동 수정(auto-correction)의 편리함을 원하지 않기 때문입니다.

프롬프트를 작성하는 것을 멈추고 명령어로 만들었습니다

버전 확인 방식은 매번 동일하기 때문에, 매 릴리스마다 수동으로 프롬프트를 작성하는 것 자체가 하나의 작은 번거로움이었습니다. 그래서 이를 재사용 가능한 명령어로 옮겼습니다.

최신 버전의 Claude Code를 사용 중이라면 알아두면 유용한 정보가 있습니다. 커스텀 슬래시 명령어(custom slash commands)는 지난 4월 업데이트에서 Skills로 통합되었습니다. 기존의 .claude/commands/ 파일도 여전히 작동하지만, 현재의 표준 위치는 .claude/skills/<name>/SKILL.md입니다. 이를 통해 동일한 /name 호출 방식을 사용할 수 있을 뿐만 아니라, 문맥(context)이 적절할 때 Claude가 스스로 이를 호출할 수 있는 옵션도 얻게 됩니다.

제 명령어는 대략 다음과 같습니다:

---
name: release-check
description: "릴리스 전 WordPress 플러그인의 버전과 readme 일관성을 확인합니다. 배포 직전에 사용하세요."
...

여기에는 두 가지 중요한 요소가 포함되어 있습니다. allowed-tools 라인은 도구의 범위를 읽기(reading)와 grep으로 제한하여, 확인 작업이 몰래 수정 작업으로 변질되지 않도록 합니다. 그리고 description은 언제 이 명령어를 사용해야 하는지 평이한 용어로 설명하며, 이를 통해 Claude가 추측하는 대신 적절한 순간에 명령어를 찾아 사용할 수 있게 합니다. 이제 이 모든 과정은 /release-check 하나로 해결되며, 저는 다시는 이를 직접 타이핑하지 않습니다.

개발자용 노이즈를 사용자용 노트로 전환하기

또 다른 반복적인 시간 소모 요인은 readme와 변경 로그(changelog)입니다. WordPress readme는 고정된 형태의 자체 마크다운(markdown) 서브셋을 사용하므로, 커밋(commit) 더미를 적절한 섹션으로 변환하는 작업은 정직함만 유지한다면 모델에게 매우 적합한 작업입니다.

저는 커밋 범위(commit range)를 전달하고 초안을 요청합니다:

git log --oneline v1.9.2..HEAD

그다음: 이것들을 사용자용 변경 사항(changelog)으로 다시 작성하되, 형식을 유지하고, 숫자나 세부 사항이 확실하지 않은 경우 추측하는 대신 (to confirm)이라고 작성하세요. 마지막 규칙은 보기보다 훨씬 중요합니다. 그대로 두면 모델은 모든 빈틈을 매끄럽게 채워버리는데, 그 '매끄러움'이야말로 당신이 확인해야 할 지점을 숨기는 바로 그 요소입니다. 불확실한 부분을 눈에 보이게 비워두도록 강제함으로써, 저는 그 부분을 잡아낼 수 있습니다.

번역 단계도 같은 방식으로 작동합니다. .pot 파일을 각 .po 파일과 비교(diff)하여 번역되지 않은 문자열만 나열하도록 시킵니다. 아직 번역은 하지 않습니다. 먼저 차이를 확인하고, 그다음 결정을 내리는 것입니다. 버전 확인 단계와 같은 형태입니다. 상태를 보여주되, 그것에 대해 조치를 취하지는 마세요.

한 번 겪었던 작은 지뢰가 있었습니다. WordPress의 readme 파일은 표(table)를 렌더링하지 않으며, 파일 크기가 약 10KB를 넘어가면 파서(parser)가 오작동하기 시작합니다. 그래서 변경 사항(changelog)이 길어지면, Claude에게 기존 항목들을 별도의 changelog.txt로 옮기도록 시킵니다. 이때 다시 작성하지 않고 순수하게 이동만 합니다. 여기서 규칙은 명확합니다. 요약하지 말고 위치만 옮기세요. 그렇지 않으면 기록을 잃게 됩니다.

제가 선을 긋는 지점

저는 의도적으로 이 모든 과정을 절반의 자동화 상태로 유지합니다. 세 가지는 수동으로 남겨둡니다: 릴리스 버튼 누르기, 사용자가 실제로 보게 될 문구 작성, 그리고 코드 병합(merging)입니다. Claude가 생성하는 모든 것은 초안이나 확인 결과로 전달될 뿐, 결코 완성된 결과물로 전달되지 않습니다.

이는 단순히 조심하기 위해서가 아닙니다. 모든 것을 통째로 넘겨버리면, 아무도 먼저 읽어보지 않은 텍스트를 사용자에게 배포하게 됩니다. 플러그인에게 이것은 시간의 문제가 아니라 신뢰의 문제입니다. allowed-tools 범위 지정과 강제된 (to confirm) 표시는 모두 그 선을 지키기 위한 메커니즘입니다. 기계는 가져오기(fetching)와 차이점 비교(diffing)를 수행하게 하고, 판단은 제가 유지하는 것입니다.

예상치 못했던 부분

저는 Claude Code가 코딩 속도를 높여주기를 바라며 시작했습니다. 하지만 실제로 Claude Code가 해준 일은, 코딩 주변의 잔해들을 치워줌으로써 저에게 코딩 그 자체를 되돌려준 것이었습니다.

이러한 잡무들 자체가 그 자체로 비용이 많이 드는 부분은 아니었습니다. 진짜 비용이 발생하는 지점은 그 작업들이 집중력에 미치는 영향이었습니다. 각각의 작은 작업들은 제 머릿속에서 코드를 밀어냈고, 다시 불러오는 과정은 일종의 세금과 같았습니다. 잡무들을 제 업무에서 치워버린 것은 단순히 몇 분의 시간을 아껴준 것이 아니었습니다. 그것은 릴리스(release) 한 번당 다섯 번씩 다시 작업에 몰입하기 위해 올라가는 대신, 빌드(build) 상태를 계속 유지할 수 있게 해주었습니다. 만약 더 많은 코드를 작성하기 위해 AI 에이전트(AI agent)를 찾고 있다면, 실제로 당신의 속도를 늦추는 것이 코드 그 자체인지, 아니면 주의력을 계속 분산시키는 주변의 작은 작업들인지 확인해 볼 가치가 있습니다. 저에게는 그 주변 작업들이 문제였고, 바로 그 부분이 가장 먼저 넘겨줄 가치가 있는 부분입니다.

저는 WordPress 플러그인을 제작하며 https://raplsworks.com/에서 AI 도구 및 보안에 관한 글을 씁니다.