1. 왜 이 스킬을 만들게 되었나

최근에 기존 업무는 정리하고, 새로운 업무를 맡게 되었습니다.

그래서 업무 인수인계도 필요하고, 업무 히스토리도 정리해야 하고, 기왕이면 몇 년동안 어떤 업무를 했는지 잘 정리해서 반쯤 버려뒀던 링크드인 업데이트도 한 번 해야 되지 않을까? 라는 생각에 도달하게 되었습니다.

그런데 막상 정리를 하려고 생각하니 너무 귀찮은 겁니다. 분명 기능 개발 할 때 나름 문서화에 신경 써서 위키에도 자료가 다 있긴한데, 일일이 하나씩 찾아가려면 힘들고, 정리도 안될 것 같고… 나 대신 누가 좀 초안 좀 작성해 줬으면 좋겠는데….라는 생각에서 출발하게 되었습니다.

마침 우리에겐 가장 확실한 기록인 Git Commit Log가 있습니다. 이 로그를 긁어다가 에이전트가 예쁘게 요약해준다면? 그 고민이 이 스킬의 시작이었습니다.

2. 어떻게 만들었나: "스킬을 만드는 스킬" (Meta-Approach)

처음 시작은 요즘 한참 뜨거운 이슈인 AI 에이전트들의 작업 방식(하네스)을 소소하게 흉내 내는 것에서 출발했습니다. 무작정 "만들어줘" 하면 이상하게 만들 때가 많잖아요? 그래서 요구 조건을 최대한 구체적으로 제시하고, "이 조건을 구현하기 위한 plan.md를 우선 만들어 줘"라고 요청했습니다.

그래서 plan.md 를 만들고, 다듬고, 다시 요청하고를 반복하면서 스킬의 뼈대를 만들었습니다. 처음에는 git log 로만 성과보고서를 만들 생각이어서 그렇게 계획했었죠. 그리고 만들어진 자료도 꽤나 잘 나왔습니다.

그런데.... 제가 그동안 개발했던 repo 는 하나가 아니었죠. 다시 다른 repo에서 plan.md 를 만들고 다듬고, 다시 요청..... 이런 반복 작업을 계속한다니! 개발자한테 반복 작업은 개선 대상이죠. 아 물론 귀찮기도 했습니다. 사실 귀찮은게 더 컸어요. 그래서 이 작업을 스킬로 만들어서 자동화 시키자, 라는 생각이 들었습니다. 스킬을 만들어주는 스킬도 있다고 들었거든요.

스킬을 찾아주는 스킬을 먼저 설치하고 - 진짜로 스킬을 찾아주는 스킬을 설치해줘 라고 요청했습니다 -, 그 다음에 스킬을 찾아주는 스킬로 스킬을 만들어주는 스킬을 설치했습니다.

적고 보니 말이 좀 이상하지만 진짜 이렇게 했습니다. :)
그래서 설치한 스킬이... microsoft-skill-creator 입니다. 이 스킬에게 시키니 진짜 만들어 주더라고요.

그 다음부터는 욕심 껏 기능을 채웠습니다.
멀티 repo도 지원하고, git log 대충 쓰는 경우도 있었으니까 기왕이면 diff 도 읽어서 분석하는 모드도 추가하고. 원천 소스 하나 만들어서 결과 보고서랑 이력서랑 링크드인 양식으로 출력도 가능하게 만들고. 매번 분석할 때마다 새로 시작하면 토큰 낭비에 비효율적이니까 점진적 업데이트 기능도 추가했습니다.

그러다 보니 이왕 만든거 스킬 등록이나 해볼까 싶어서 스킬 등록도 해보고 싶어졌죠.

3. 스킬 등록

결론부터 말하면 제가 생각하던 skills.sh에 등록은 실패했습니다. 깃허브에 repo를 만들고 업로드하는 과정은 순조로웠습니다. npx skills add로 설치도 잘 되더라고요.

그런데 에이전트에게 물어보면 검색은 되는데, skills.sh 목록에는 안 보이더라고요. 아마 skills.sh는 어느 정도 설치 수가 확보되어야 보이는 래더(Ladder) 시스템이거나 별도의 조건이 있나 보다 싶었습니다. 그래서 일단 깃허브에 공개하는 선에서 마무리 지었습니다.

4. 마무리

이번에 스킬을 만들면서 느낀 점은 '의외로 스킬을 만들기가 어렵지 않다'였습니다. 결과물도 꽤 좋게 나왔고요.

이제 이 데이터를 가지고 링크드인도 업데이트 하고, 이력서도 업데이트 하고, 보고서도 작성해야겠습니다. 바로 쓰기에는 너무 내용이 세세해서 조금 다듬기는 해야겠지만요. 다듬는 건 에이전트에게 시킬까 아니면 NotebookLM을 한 번 써볼까 고민하고 있습니다.

마지막으로 이 스킬은 https://github.com/ds-im/git-work-report 에서 확인하실 수 있고요,

npx skills add https://github.com/ds-im/git-work-report

로 설치해서 사용하실 수 있습니다.

엔지니어한테 글을 쓴다는 건 좋은 습관이라고 생각한다. 어떤 주제를 글로 남기려고 하면 보통은 글을 쓰면서 정리가 되게 마련이다. 물론 정리가 안되는 글도 있긴 하지만...

개발자 생활을 하면서 느낀 점 중 하나는 내가 직접 작성한 코드라도 어딘가 기록을 남기지 않는다면, 시간이 지난 후 다시 봤을 때 생소한 느낌을 받는다. 다시 긴 시간을 들여야지만 아 그때 그랬던가? 정도의 느낌으로 기억이 복구 될 수도 있고 안 될 수도 있는 경험을 한 번씩은 해보지 않았을까? 적어도 나는 그렇다.

그래서 얼마나 기록할 수 있을지는 모르겠지만 시작이 반이라고, 일단 시작해보려 한다.

그래서 어디에 글을 쓰지.....?

첫번째 문제는 어디에 글을 쓸까 였다. 여러 곳이 있었지만 내가 원하는 조건에서 한두개씩 빠진다. 조건을 나열해 보자면 첫번째로 마크다운은 지원되야 하고, 도메인 등록도 되야하고, 구글 검색도 되야 하고, 글이 별로더라고 내가 쓴 글은 내가 소유하는게 맞지 않을까 생각이 들었다. 마음에 안들면 마이그레이션도 해야 되니까. 그리고 결정적으로 글 발행에 시간이 적게 걸려야 한다. 업무, 육아를 제외한 짜투리 시간에 글을 써야 하므로 시간 투자를 많이 할 수 없기 때문에 이런 조건을 걸게 되었다.

• GITHUB IO : 개발자들의 블로그로 참 좋아서 몇 번 시도해 봤지만 글 발행이 어렵다. 글 발행까지의 기본 프레임워크를 만들어야 하는데, 시간이 걸려서 패스.

• 티스토리 : 마크다운 지원이 되긴하는데 좀 귀찮다.

• 네이버 : 마크다운 지원이 안된다. 구글 검색 되게 하려면 추가 설정을 해야 한다.

• velog : 좋은 플랫폼이다. 후보 1

• hashnode : 한글 지원이 안되긴 하지만 개인 도메인 연결도 되고 github에 백업도 된다. 마크다운 에디터도 괜찮은 것 같다. 후보 2

그래서 조건을 거의 대부분 만족하는 hashnode 로 결정했다.

마치면서

위 과정을 거치면서 일단 한 번 써보자 라는 생각으로 처음 쓰는 글이 바로 이 글이다. 개인 도메인도 연결해보고, 에이전트로 로컬에서 hashnode 로 바로 발행하는 자동화도 해볼 생각이긴 한데, 언제 할 수 있을지는 모르겠다.