gstack을 석 달 방치했더니 — 1.26과 1.60 사이에 늘어난 스킬 9개

▶ 동영상 개요 — gstack을 석 달 방치했더니 — 1.26과 1.60 사이에 늘어난 스킬 9개

5분 41초 — 버전 격차 34칸과 신규 스킬 9개의 분포를 훑는다 — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 두 진행자가 짚는 34칸의 버전 격차

16분 21초 — 스킬 9개가 어디에 몰렸는지, 올릴 때 무엇이 걸리는지를 대화로 풀어낸다. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

지난 5월 초에 gstack을 설치했다. gstack은 Y Combinator 대표 Garry Tan이 자기가 매일 쓰는 Claude Code 설정을 그대로 공개한 오픈소스 스킬 팩이다. 설치 디렉토리의 VERSION 파일을 열어 보니 1.26.2.0이 적혀 있었다. 그때 받아 놓고 그대로 썼으니 당연한 숫자다.

오늘 원본 저장소의 같은 파일을 열어 봤다. 1.60.1.0이었다. 석 달 사이에 마이너 버전이 34칸 올라간 것이다. 남이 만든 도구를 클론해서 쓰다 보면 "이게 지금 최신인가"를 따져 볼 계기가 좀처럼 없다. 그래서 이번엔 반대로 물어봤다. 내가 안 보는 사이에 이 도구는 무엇이 되어 있었나?

늘어난 것은 스킬 디렉토리 9개다

gstack은 스킬 하나가 디렉토리 하나에 대응한다. 그래서 버전 차이를 재는 가장 정직한 방법은 저장소 최상위의 디렉토리 목록을 양쪽에서 뽑아 비교하는 것이다. 내 설치본에 없고 원본에만 있는 디렉토리가 정확히 9개였다.

다이어그램 설명. 석 달간 추가된 스킬 9개를 성격별로 세 묶음으로 갈라 놓은 그림이다. 눈에 먼저 들어오는 것은 비율이다. 아홉 중 다섯이 iOS 하나에 몰려 있다. 나머지는 결과물을 뽑아내는 쪽 둘, 작업 흐름을 잇는 쪽 둘로 조용히 나뉜다. 이 분포가 중요한 이유는, 도구가 기능을 고르게 넓힌 게 아니라 한쪽으로 확 기울었다는 뜻이기 때문이다. 어떤 도구를 오래 쓸지 판단할 때는 기능 개수보다 이 기울기를 보는 편이 낫다. 만드는 사람이 지금 무엇을 진짜 문제로 여기는지가 거기 드러난다.

절반이 iOS인 것은 우연이 아니다

기존 gstack의 품질 검증은 브라우저에 묶여 있었다. 헤드리스 브라우저(화면 없이 백그라운드에서 도는 브라우저)를 띄워 웹 페이지를 열고, 버튼을 누르고, 스크린샷을 찍어 비교하는 방식이다. 웹이라는 한 판 위에서는 이걸로 충분했다.

새로 들어온 다섯 개는 그 판을 실제 기기로 넓힌다. USB로 연결한 진짜 아이폰을 제어해 QA를 돌리고, 발견한 문제를 고치고, 디자인을 훑고, 상태를 동기화하고, 정리한다. 웹 페이지의 DOM(문서 구조)을 읽던 자리에 실기기의 화면과 접근성 정보를 놓은 셈이다.

왜 이게 신호인가? 에이전트에게 코드를 맡기는 도구는 대개 "코드를 얼마나 잘 짜느냐"로 경쟁한다. 그런데 이 도구는 석 달 치 개발 자원의 절반 이상을 결과물을 어디서 확인하느냐에 썼다. 만드는 능력이 아니라 확인하는 범위를 넓힌 것이다. 에이전트가 코드를 빨리 뽑아낼수록 병목이 검증 쪽으로 옮겨간다는 판단이 이 선택 뒤에 있다고 읽었다.

/spec — 막연한 의도와 코드 사이에 한 칸을 더 끼운다

새 스킬 중 작업 흐름을 건드리는 것은 /spec이다. 정의문은 짧다. "막연한 의도를 다섯 단계를 거쳐 정밀하고 실행 가능한 명세로 바꾼다"고 적혀 있다.

다이어그램 설명. "이거 좀 고쳐야 하는데" 수준의 한마디가 실제로 닫히는 이슈가 되기까지의 경로다. 핵심은 명세를 만든 뒤 끝나지 않고 이슈 등록과 종료까지 한 줄로 이어진다는 점이다. 새 작업 폴더에 에이전트를 따로 투입하는 이유는, 지금 작업 중인 디렉토리를 건드리지 않고 독립된 사본에서 작업을 돌리기 위해서다. 여러 갈래를 동시에 굴려도 서로 파일을 밟지 않는다. 다만 여기엔 대가가 있다. 사람이 짧게 말하고 넘어가던 자리에 명세 작성이라는 단계가 하나 더 생기므로, 5분이면 끝날 수정에까지 이걸 걸면 절차가 일을 앞지른다. 이 스킬은 며칠 이상 끌 일에만 쓰는 게 맞다.

내가 이전에 이 도구를 다룰 때 정리했던 흐름은 기획에서 계획, 구현, 검증으로 이어지는 순서였다. /spec은 그 순서의 계획과 구현 사이에 한 칸을 더 끼운다. 계획은 세웠는데 "그래서 이번 주에 뭘 닫나"가 흐려지는 자리를 겨냥한 셈이다.

기억이 별도 축으로 승격됐다

남은 하나는 /sync-gbrain이다. gbrain은 같은 제작자가 4월에 따로 공개한 에이전트 기억 시스템이다. 내 설치본에도 gbrain을 설치해 주는 스킬은 이미 있었지만, 동기화만 따로 떼어 낸 스킬은 없었다.

설치와 동기화가 갈라졌다는 건 사용 방식이 달라졌다는 뜻이다. 설치는 한 번 하면 끝나는 일이고, 동기화는 반복해서 도는 일이다. 반복되는 일에 이름을 붙여 스킬로 승격시켰다는 건 그만큼 자주 도는 작업이 됐다는 신호로 읽힌다. 기억이 부속품이 아니라 매일 관리해야 할 자산으로 취급되기 시작한 것이다.

업그레이드할 때 실제로 걸리는 것

그래서 바로 최신으로 올리면 되느냐 하면, 여기서 이 도구의 알려진 약점이 하나 걸린다. gstack은 저장소를 클론해서 홈 디렉토리 아래 스킬 폴더에 복사하는 방식으로 설치된다. 설치가 30초로 끝나는 대신, 내가 손댄 부분과 원본의 변경분이 같은 자리에서 만난다.

공개 토론에서도 같은 지적이 나왔다. 혼자 한 대의 기기에서 쓸 때는 이 모델이 아주 잘 돌아가지만, 저장소마다 검증 기준이 다른 환경에서는 유지보수가 무너진다는 것이다. 어떤 저장소에서는 보안 검토를 필수로 걸고 다른 저장소에서는 건너뛰고 싶은데, 스킬 본체가 한 벌뿐이라 그 차이를 담을 자리가 마땅치 않다.

실무적인 결론은 단순하다. 올리기 전에 내가 원본 파일을 직접 고친 적이 있는지부터 확인한다. 고친 적이 없으면 그냥 올리면 되고, 고쳤다면 그 변경을 스킬 본체가 아니라 프로젝트별 설정으로 빼낸 뒤에 올린다. 도구를 따라가는 비용은 도구를 얼마나 내 손으로 주물렀느냐에 정비례한다.

정리 — 남이 만든 도구를 쓴다는 것은 그 도구의 속도를 함께 받는 일이다

석 달 만에 열어 본 숫자는 34였다. 그 안에 스킬 9개가 들어왔고, 그중 다섯이 검증 범위를 웹 밖으로 넓히는 데 쓰였다. 도구가 어디로 가는지는 새 기능 목록이 아니라 새 기능이 어디에 몰렸는지에서 읽힌다.

개인 작업에 적용할 교훈은 하나다. 외부 도구를 설치한 날짜와 버전을 기록해 두고, 분기에 한 번은 원본의 같은 값을 열어 본다. 올릴지 말지는 그 다음 판단이고, 최소한 내가 몇 칸 뒤에 서 있는지는 알고 있어야 한다.

---

참고한 공개 자료:

• gstack 저장소 — https://github.com/garrytan/gstack
• gstack 버전 파일 — https://raw.githubusercontent.com/garrytan/gstack/main/VERSION
• gstack 공개 토론 (Hacker News) — https://news.ycombinator.com/item?id=47355173
• gbrain 저장소 — https://github.com/garrytan/gbrain

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.