안녕하세요. 오늘도 Claude Code에게 완전히 똑같은 이야기를 처음부터 다시 설명했습니다. 세어보지는 않았지만, 아마 이번 주에만 5번째 정도인 것 같습니다.

工具箱に並んだレンチ。左から2本だけ手入れが行き届いて光っていて、残り3本はほこりをかぶっている

Claude Code는 터미널에서 채팅하듯 지시를 내리면 코드를 작성하거나 명령어를 실행해 주는 AI 에이전트입니다. 하지만 기억하는 것은 눈앞의 대화뿐이기에, 새로 말을 걸 때마다 사용자가 처음부터 전제 조건을 다시 전달해야 합니다.

실제로 사용하다 보면 이런 상황을 자주 마주하게 됩니다.

"이 프로젝트의 구성은 이렇고, 검증은 이렇게 돌리고, PR(Pull Request)을 보낼 곳은 여기고……". 매번 똑같은 말을 하고 있는 자신을 발견하며 은근히 소모됩니다.

이 "매번 똑같은 말을 하는 것"을 줄이기 위한 수단으로, Claude Code에는 **스킬 (Skill)**이라는 메커니즘이 있습니다. 흔히 "커스텀 슬래시 명령어 (Custom Slash Command)"로 소개되기도 하지만, 정확히는 조금 다릅니다.

저는 어느 날, "좋아, 매번 설명하고 있는 정형화된 작업을 모아서 스킬로 만들자"라고 결심했고, 그날 바로 5개의 스킬을 만들었습니다. 이번에는 그 5개가 그 이후 어떻게 되었는지에 대한 솔직한 이야기입니다.

(이 기사는 2026년 7월 시점의 Claude Code를 전제로 합니다. 명칭이나 사양은 향후 변경될 가능성이 있습니다)

그날 만든 자작 스킬 5개

처음에 만든 것은 grill-me였습니다. 일문일답 형식으로 질문을 퍼부어 사용자를 압박하고, 모호한 방침을 확정해 주는 스킬입니다. 사실 이날 "무엇을 만들 것인가" 자체도 grill-me의 질문 공세에 밀려 결정했습니다. 자신을 위한 도구를 만드는 상담 상대로 이미 존재하던 도구를 사용하는, 약간 뒤틀린 순서가 된 셈입니다.

그 기세로 나머지 4개를 만들었습니다.

"글로벌"은 어떤 프로젝트를 열고 있어도 호출할 수 있는 위치이며, "프로젝트 고유"는 특정 리포지토리(Repository) 안에서만 호출할 수 있는 위치입니다. 이 차이가 나중에 큰 영향을 미칩니다.

결과적으로, 5개 중 2개만 정착했습니다

만든 직후에는 5개 모두 편리하게 사용했습니다. 하지만 그로부터 2주 정도 지난 지금, 솔직히 되돌아보니 차이가 확연히 드러납니다.

worklog는 최근 기록을 봐도 거의 매 작업마다 계속 사용되고 있습니다. grill-me도 방침을 다듬고 싶은 상황에서는 지금도 가장 먼저 손이 갑니다.

반면 verify · pr · after-merge 이 3개는 정착하지 못했습니다.

만든 후 며칠 뒤 자신의 작업 패턴을 되돌아봤을 때는, "PR 관련 일련의 흐름은 거의 자동화되어 있다"라고 평가했습니다.

그런데 그로부터 시간이 더 흐르자 상황이 변했습니다. 어느샌가 그냥 생(raw) git push로 끝내는 날이 늘어났고, 호출하지 않는 날이 더 많아졌습니다.

공정의 흐름에 배치해 보면 다음과 같습니다.

賑わう2つの入口と、誰も近寄らずほこりをかぶった3つの小部屋の扉の対比

보시는 바와 같이, 지금도 계속 사용 중인 2개는 공정의 외곽(처음과 마지막)을 차지하고 있고, 정착하지 못한 3개는 중간의 특정 프로젝트에서만 쓰이는 공정에 파묻혀 있습니다. 이것은 우연이 아닌 것 같습니다.

무엇이 "정착"을 갈랐는가

되돌아보며 생각한 결과, 차이를 만든 것은 주로 두 가지 축이었습니다.

1. 상황은 보편적이어도, 위치가 프로젝트 고유라면 호출할 수 없다

"작업을 시작한다", "방침을 다듬는다"라는 상황은 어떤 프로젝트를 다루고 있어도 발생합니다. worklog와 grill-me는 글로벌한 위치에 놓여 있기 때문에, 이 보편적인 상황에 그대로 올라타 어떤 리포지토리를 열고 있어도 /worklog, /grill-me로 호출할 수 있습니다.

반면 "검증한다", "PR을 낸다", "머지(Merge)된다"도 본래는 어떤 프로젝트에서든 일어날 법한 상황입니다. 하지만 verify · pr · after-merge는 특정 리포지토리 안에만 두었습니다. 그래서 상황 자체는 발생하더라도 다른 리포지토리에서는 애초에 호출할 수 없고, 해당 리포지토리를 만지지 않는 날이 계속되면 존재 자체를 잊어버리게 됩니다. 즉, 똑같은 "상황의 보편성"을 가지고 있더라도, 위치 하나만으로 사용 횟수가 완전히 달라진다는 것입니다.

2. 대신해 주는 것이 "번거롭지만 빠른 작업"인가, "은근히 기력을 소모하는 작업"인가

git push

gh pr create와 같은 명령어는 사실 몇 초면 입력할 수 있습니다. 스킬(Skill)로 만들어도 타이핑 양이 그렇게 줄어들지는 않습니다. 전환할 메리트가 적기 때문에, 바쁠 때는 그냥 직접 입력하게 됩니다.

반면, 질문을 다듬고 사양을 확정하는 작업이나, 작업 내용을 제대로 언어화하여 로그로 남기는 작업은 손으로 직접 하면 은근히 기력을 소모합니다. "무엇을 물어봐야 하는가", "어떻게 써야 나중에 다시 읽을 수 있는가"를 고민하는 부담 그 자체를 대신해 주기 때문에, 체감되는 부담 감소가 큽니다.

커맨드화(Command化)를 고민할 때 스스로에게 던지는 질문

天秤ばかりで道具を作るかどうか吟味している人物

이 경험을 통해, 무언가를 스킬화하기 전에 스스로에게 던지는 두 가지 질문이 있습니다.

• 이것은 "어떤 프로젝트에서도" 발생하는 장면인가? 그렇다면 글로벌(Global)한 위치에 둘 수 있는가, 아니면 특정 리포지토리(Repository) 안에서만 호출할 수 있도록 만들어 버렸는가?
• 손으로 하는 것이 "빠르지만 귀찮은" 것뿐인가, 아니면 "시간이나 기력을 잡아먹는" 작업인가?

"장면이 보편적이고 글로벌하게 둘 수 있다"와 "기력을 잡아먹는 작업을 대신해 준다"라는 두 가지 조건이 모두 충족될수록, 정착할 가능성이 높다는 것이 현재의 실감입니다. 반대로 둘 다 해당하지 않는다면, 만들어 놓아도 손이 가지 않을 가능성을 의심해 보는 것이 좋습니다.

요약

5개를 만들었지만, 지금도 망설임 없이 사용하고 있는 것은 2개뿐이었습니다. 숫자만 보면 "3개는 실패"한 것처럼 보일지도 모릅니다. 하지만 직접 만들어 보았기에 비로소 "어디에 효과가 있는지"를 알게 되었다는 의미에서는, 헛되지 않았다고 생각합니다.

만약 "매번 Claude Code에게 똑같은 말을 하고 있다"고 느껴진다면, 우선 자신의 하루 일과를 떠올려 보며 "어떤 프로젝트에서도 발생하는 장면"을 하나 찾아보세요. 그것이 커맨드화가 가장 효과를 발휘하는 지점입니다.

Discussion