스타 12만 개짜리 프롬프트 뭉치 — gstack 논쟁이 실제로 드러낸 것

▶ 동영상 개요 — 스타 12만 개짜리 프롬프트 뭉치 — gstack 논쟁이 실제로 드러낸 것

6분 21초 — 세 층위로 갈리는 비판과 그 뒤에 남는 것을 정리한다 — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 두 진행자가 따져보는 12만 스타의 정체

17분 24초 — 비판이 갈리는 세 층위와 그럼에도 남는 것을 대화로 풀어낸다. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

gstack 저장소를 처음 열었을 때 좀 이상했다. 스타가 12만 개를 넘겼는데(조회 시점 기준 12만 5천), 파일을 하나씩 열어 보면 대부분 마크다운 문서다. 실행되는 코드가 없는 건 아니지만, 이 도구의 값어치를 만드는 부분은 거의 다 "AI에게 이렇게 시켜라"라고 적어 놓은 자연어 문서다.

그래서 공개 직후부터 같은 지적이 반복됐다. "결국 텍스트 파일에 든 프롬프트 뭉치 아니냐." 이 말은 사실이다. 그런데 사실인 것과 그래서 가치가 없다는 것은 다른 얘기다. 이 도구를 몇 달 쓰면서 그 간극이 계속 걸렸고, 공개된 논쟁을 훑어 보니 비판들이 서로 다른 층위를 때리고 있다는 게 보였다. 정리해 둘 만하다고 판단했다.

먼저 숫자부터

2026년 3월 12일에 공개됐고 처음엔 스킬 13개였다. 지금은 그 세 배 가까이 늘었다. 저장소에는 커밋 313개와 참여자 81명이 찍혀 있고, 포크는 1만 9천 개에 가깝다. 라이선스는 제약이 거의 없는 MIT다.

만든 사람은 Y Combinator 대표 Garry Tan이다. 이 사실이 논쟁의 상당 부분을 설명한다.

비판은 세 층위로 갈린다

다이어그램 설명. 겉보기엔 하나의 논쟁처럼 보이지만 실제로는 서로 다른 세 과녁을 향한 지적이 섞여 있다는 것을 보여준다. "그냥 프롬프트"라는 지적은 만들어진 물건 자체를 겨냥하고, "유명세로 떴다"는 지적은 그 물건이 왜 이만큼 퍼졌는지를 겨냥하고, "하루 1만 줄"에 대한 반발은 물건이 아니라 그것을 홍보하며 내건 주장을 겨냥한다. 이걸 갈라 놓아야 하는 이유는 세 지적의 참·거짓이 각각 따로 놀기 때문이다. 물건이 단순한 것은 사실이면서 동시에 쓸모 있을 수 있고, 유명세로 퍼진 것이 사실이면서 동시에 퍼질 만한 물건일 수도 있다. 하나가 맞다고 나머지가 따라오지 않는다.

"그냥 프롬프트다" — 맞다. 그래서 어떤 점이 문제인가

개별 스킬을 열어 보면 정말로 구조화된 프롬프트다. 역할을 부여하고, 검토할 항목을 나열하고, 어떤 순서로 물어보라고 적어 둔 문서다. 마법은 없다.

다만 여기서 판단이 갈린다. "프롬프트일 뿐"이라는 말에는 두 가지 서로 다른 주장이 섞여 있다. 하나는 기술적 참신함이 없다는 것이고, 다른 하나는 가치가 없다는 것이다. 앞의 것은 맞고, 뒤의 것은 따라 나오지 않는다.

체크리스트를 생각해 보면 쉽다. 수술실 체크리스트에는 기술적 참신함이 조금도 없다. 항목을 순서대로 적어 놓은 종이 한 장이다. 그런데 그 종이가 합병증을 줄인다는 연구가 나왔고, 지금은 표준이 됐다. 값어치는 참신함이 아니라 매번 같은 순서를 강제한다는 데서 나왔다.

gstack이 하는 일도 그 종류다. 기획을 건너뛰고 코드부터 짜지 못하게 하고, 테스트가 통과했다고 화면 확인을 건너뛰지 못하게 한다. 사람이 규율로 지켜야 했던 순서를 도구가 대신 붙잡는다. 이걸 코드로 구현했느냐 문서로 적었느냐는 이 효과와 별 관계가 없다.

같은 토론에서 나온 반론 하나가 이 지점을 정확히 짚었다. 주목할 것은 개별 구현이 아니라 역할을 쪼갠 방식이라는 것이다. 계획, 검토, 품질 검증, 배포를 각각 다른 성격의 전문가에게 맡기는 구조 말이다. 그 패턴은 이 도구를 안 쓰더라도 가져갈 수 있다.

"유명세로 떴다" — 검증할 수 없지만 좋은 질문이다

Y Combinator 대표가 아니었어도 이만큼 퍼졌겠느냐는 지적이 있었다. 정직하게 말하면 이건 검증할 방법이 없다. 반대되는 사실을 실험할 수는 없다.

그래도 이 질문이 유용한 이유가 있다. 오픈소스 도구를 고를 때 스타 개수를 품질 신호로 쓰는 습관을 흔들기 때문이다. 스타는 얼마나 많은 사람이 알게 됐는지를 재는 값이지 얼마나 잘 만들었는지를 재는 값이 아니다. 특히 널리 알려진 사람이 공개한 물건은 그 두 값이 크게 벌어진다.

그래서 나는 이 도구를 판단할 때 스타 개수를 아예 빼고 봤다. 대신 문서에 실패 조건이 적혀 있는지, 안 되는 경우를 솔직히 밝히는지를 봤다. 그 기준으로는 꽤 좋은 편이었다. 보안 방어 계층이 실행 방식에 따라 일부 빠진다는 사실을 문서에 그대로 적어 놓은 것 같은 대목이 그렇다.

"하루 1만 줄"이 왜 반발을 샀나

이 도구의 철학 문서에는 이런 문장이 있다. "하루 1만 줄 이상의 쓸 만한 코드. 주당 100회 이상의 커밋. 팀이 아니라 한 사람이, 그것도 파트타임으로."

이 문장에 대한 반응 중 가장 많이 인용된 것은 짧았다. 하루 1만 줄은 자랑이 아니라 위험 신호라는 것이다. 왜 그런 반응이 나오는지는 지표를 그려 보면 분명해진다.

다이어그램 설명. 생산량 증가가 왜 그 자체로는 좋은 소식이 아닌지를 보여준다. 생산이 늘면 좋은 코드와 부실한 코드가 같은 비율로 함께 늘어나고, 둘 다 결국 사람이 확인해야 할 분량으로 합쳐진다. 확인하는 속도가 그대로라면 확인되지 않은 코드가 쌓이기 시작한다. 여기서 중요한 것은 이 그림이 생산량을 늘리지 말라는 얘기가 아니라는 점이다. 늘리되 줄 수를 성과 지표로 내세우면 안 된다는 얘기다. 줄 수는 확인 부담을 함께 세지 않기 때문에, 그 숫자가 커질수록 실제 상태와 멀어진다. 이 도구가 스킬의 절반 가까이를 검토와 품질 검증에 쓰고 있다는 점을 함께 보면 앞뒤가 맞는다. 만든 사람도 이 부담을 알고 있고, 그래서 확인 쪽에 도구를 잔뜩 붙여 놓은 것이다. 홍보 문구만 떼어 놓고 보면 그 맥락이 사라진다.

수집되는 신호와 설치 모델

공개 토론에서 나온 우려 하나는 사용 기록 수집이었다. 사람들이 무엇을 만들고 있는지에 대한 신호를 얻는 통로가 되는 것 아니냐는 것이다. 투자 회사를 이끄는 사람이 만든 개발 도구라는 조합에서 자연스럽게 나올 만한 의심이다. 이 지적에 대해서는 수집을 끌 수 있다는 답이 나왔고, 실제로 끌 수 있다.

더 실무적인 지적은 설치 방식에 있었다. gstack은 저장소를 복제해 홈 디렉토리 아래에 복사하는 식으로 깔린다. 한 사람이 쓸 때는 30초면 끝나는 훌륭한 방식이다. 그런데 저장소마다 검토 기준이 달라야 하는 환경에서는 이 모델이 무너진다. 스킬 본체가 한 벌뿐인데 프로젝트 A는 보안 검토를 필수로 걸고 프로젝트 B는 건너뛰고 싶다면, 그 차이를 담을 자리가 마땅치 않다.

이건 비판이라기보다 설계가 겨냥한 사용자가 누구인지를 보여주는 대목에 가깝다. 이 도구는 처음부터 한 사람이 스타트업 규모의 결과물을 뽑아내는 상황을 향해 만들어졌다. 조직에서 여러 팀이 쓰는 상황은 겨냥한 적이 없다. 그런 용도로 가져가면 안 맞는 게 당연하다.

그리고 실제로 일어난 사고 하나

같은 토론에 사고 경험담이 하나 올라왔다. 자율적으로 돌던 에이전트가 70분 동안 같은 동작을 반복하며 운영 설정 파일에 시험용 주소를 계속 집어넣었다는 것이다. 그러면서 스스로는 작업이 성공했다고 보고했다.

이 사례가 무서운 이유는 실패가 조용했다는 데 있다. 에러로 멈췄으면 사람이 알아챘을 텐데, 성공했다고 보고하며 계속 돌았다. 이런 종류의 실패는 에이전트가 자기 상태를 스스로 판단하는 한 구조적으로 남는다. 자기 판단이 틀린 경우를 자기 판단으로 잡을 수는 없기 때문이다. 밖에서 지켜보는 눈이 필요하고, 실제로 그 경험 이후에 감시 도구를 따로 만들었다는 후일담이 붙어 있었다.

정리 — 논쟁을 거르고 나면 남는 것은 순서다

비판들을 다 떼어 놓고 보면 남는 게 있다. "그냥 프롬프트"라는 지적은 맞고, 유명세가 확산에 기여했다는 것도 아마 맞고, 줄 수를 자랑하는 화법이 부적절하다는 것도 맞다. 그런데 이 셋을 다 인정해도 역할을 쪼개 순서를 강제한다는 구조는 여전히 남는다.

그래서 나는 이 도구를 "따라 해야 할 정답"으로도, "과대평가된 유행"으로도 보지 않기로 했다. 남이 자기 작업 순서를 통째로 공개해 놓은 참고 자료로 본다. 그 순서 중 내 작업에 없던 칸이 무엇인지 찾아보는 용도라면, 프롬프트 뭉치라는 사실은 흠이 아니라 오히려 읽기 쉬운 형식이다.

---

참고한 공개 자료:

• gstack 저장소 — https://github.com/garrytan/gstack
• gstack 공개 토론 (Hacker News) — https://news.ycombinator.com/item?id=47355173
• 기술계를 갈라놓은 gstack — https://cryptorank.io/news/feed/4fcf8-garry-tan-claude-code-gstack
• Inside Garry Tan's AI Coding Setup (Y Combinator) — https://www.ycombinator.com/library/OW-inside-garry-tan-s-ai-coding-setup

---

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