올해 초에 Garry Tan이 GitHub에 뭔가를 올렸습니다. Y Combinator CEO가 자기 개인 Claude Code 설정을 오픈소스로 푼 거였고, 이름은 gstack이었습니다. 같이 따라온 숫자가 있었는데 60일에 60만 줄이었습니다. 본인이 이 셋업으로 두 달 동안 혼자 쓴 프로덕션 코드 양이라고 했고, 많은 날은 하루에 1만에서 2만 줄이었다고 합니다. 팀 없이요. 숫자가 워낙 커서 그 숫자가 도구보다 먼저 퍼졌습니다.
처음 봤을 때 저게 말이 되나 싶었고, 바로 다음에는 저게 진짜면 어떡하지 싶었습니다. gstack이 실제로 뭘 하는 물건인지는 그 두 생각 사이 어딘가에 있는 것 같았습니다.
숫자 하나에 이렇게 반응하는 게 좀 우습긴 합니다. 코드 줄 수가 별 의미 없다는 건 개발자라면 다 아는 얘기인데, 막상 큰 숫자가 눈앞에 오면 그 상식이 잠깐 꺼집니다. 저만 그런 건 아닐 거라고 생각하는데, 숫자가 도구보다 먼저 퍼졌다는 게 그 증거 같기도 합니다. gstack이라는 이름은 몰라도 60만 줄은 기억하는 사람이 꽤 있을 것 같습니다. 저도 처음엔 그쪽이었습니다.
이건 Paperclip 시리즈 세 번째 글입니다. 1부에서는 AI가 목표를 너무 충실하게 따를 때 생기는 문제를 썼습니다. Claude Code한테 번들 사이즈 줄여달라고 했더니 폴리필을 통째로 빼버려서 Safari에서 터진 일이었고, 거기서 Nick Bostrom의 Paperclip Maximizer 얘기로 넘어갔습니다. 위험한 건 지능보다 목표 함수라는 얘기였죠. 2부에서는 그 사고실험 이름을 대놓고 달고 나온 오픈소스 멀티 에이전트 플랫폼 paperclip.ing을 뜯어봤습니다. 에이전트가 새 에이전트를 고용하려면 사람 승인이 있어야 한다고 못박아둔 거버넌스 레이어가 인상적이었습니다.
gstack은 같은 문제를 다른 쪽에서 건드린다고 봤습니다. paperclip.ing이 AI 거버넌스를 아키텍처로 어떻게 풀지에 대한 답이었다면, gstack은 그 아래서 혼자 실제로 어떻게 일하느냐에 대한 답에 가깝습니다.
시리즈로 묶어서 쓰고 있지만 처음부터 이렇게 이어질 줄 알고 시작한 건 아니었습니다. 1부를 쓸 때는 폴리필 하나 빠진 얘기였는데, 쓰다 보니 비슷한 고민을 하는 사람들이 각자 다른 답을 들고 나오고 있었고 gstack도 그중 하나로 보였습니다. 셋 다 AI한테 일을 맡기면서 사람이 어디서 끼어들 거냐를 묻고 있는데, 끼어드는 방식은 꽤 다릅니다. 저는 그 차이가 생각보다 큰 차이라고 보고 있습니다.
생긴 건 이렇습니다
Claude Code 위에 얹는 워크플로우 레이어입니다. 슬래시 커맨드 23개 묶음이고, 커맨드마다 팀 안의 역할 하나를 맡습니다. CEO, 디자이너, 엔지니어링 매니저, QA 리드, 릴리즈 매니저, 보안 감사관 같은 역할이 Claude Code 안에서 켜지는 식입니다.
역할 이름만 보면 회사 조직도 같습니다. 혼자 일하는 사람한테 조직도를 쥐여준다는 발상이 좀 재밌는데, 생각해보면 1인 창업자가 제일 자주 듣는 조언이 모든 역할을 다 해야 한다는 얘기니 그걸 그대로 도구로 만든 셈입니다. 다 해야 한다는 말은 늘 들어도 어떻게 다 하라는 건지는 아무도 안 알려주는데, gstack은 적어도 그 순서는 보여줍니다.
git clone https://github.com/garrytan/gstack
./setup
설치는 이게 다입니다. MIT 라이선스고 유료 플랜 같은 것도 없습니다.
설치가 이렇게 간단하다는 게 좋으면서도 조금 걸립니다. 두 줄이면 끝나니 일단 깔아보고 생각하게 되는데, 깔고 나면 커맨드 23개가 한꺼번에 생깁니다. 그걸 다 쓰는 사람은 많지 않을 것 같고, 대부분은 두세 개만 손에 붙고 나머지는 잊어버리지 않을까 싶습니다. 그게 나쁜 건 아닌데, 그렇다면 23개가 다 필요했던 건 Garry Tan 한 사람이었을 수도 있겠다는 생각이 듭니다. 남의 작업 방식을 통째로 받는다는 게 원래 그런 거겠지만요.
재밌는 건 Garry Tan 본인이 README에 이걸 코드 빨리 짜주는 도구로 보지 말라고 써놨다는 겁니다.
"If you're looking for something that writes code faster, gstack is the wrong tool. Its value is in the process around the code — the planning, reviewing, testing, and shipping."
코드 자체보다 코드 주변의 과정, 그러니까 기획하고 리뷰하고 테스트하고 배포하는 쪽에 가치가 있다는 얘기입니다.
이 문장을 읽고 나서 60만 줄이라는 숫자가 좀 다르게 보였습니다. 코드를 빨리 짜는 게 목적이 아니라면, 60만 줄은 과정을 제대로 돌렸더니 따라온 결과라는 얘기가 됩니다. 본인은 그렇게 말하고 싶었던 것 같은데 사람들은 결과 쪽만 들었습니다. 저도 처음엔 그랬고요.
흐름을 따라가보면 이렇습니다. 뭘 만들기 전에 /office-hours를 먼저 칩니다. CEO 역할이 켜져서 내가 만들려는 걸 듣고 그게 정말 그거냐고 몰아붙입니다. 일일 브리핑 앱을 만들고 싶다고 하면, 사실 당신은 개인 AI 비서를 만들고 있는 거 아니냐고 다시 정의해주는 식입니다. 기능을 만들기 전에 문제부터 맞는지 보는 단계입니다. 저는 여기가 제일 좋아 보였습니다. 사람끼리 일할 때도 이 질문을 대놓고 던져주는 동료는 생각보다 드뭅니다. 다들 일단 만들기 시작하고, 이게 맞는 문제였는지는 한참 뒤에야 묻습니다.
AI도 마찬가지인 것 같습니다. 시키면 바로 만들기 시작하고, 만들려는 게 맞는지는 묻지 않습니다. 그걸 묻는 역할을 커맨드로 따로 떼어둔 게 gstack에서 제일 사람 같은 부분이라고 봤습니다. 다만 일일 브리핑 앱이 사실은 개인 비서라는 식의 재정의가 매번 맞을지는 모르겠습니다. 그냥 일일 브리핑 앱이 필요한 사람도 있을 텐데, CEO 역할이 그걸 더 큰 얘기로 키워버리면 오히려 일이 커질 수도 있겠다 싶습니다. 스타트업 CEO 관점이라는 게 원래 문제를 크게 보는 쪽이니까요.
그다음 /plan-ceo-review랑 /plan-eng-review로 넘어갑니다. CEO 리뷰는 범위를 봅니다. 이걸 지금 다 만들어야 하나, 뭘 빼도 되나. 엔지니어링 리뷰는 구조랑 기술 선택을 정해둡니다. 이 둘을 거쳐야 코드를 만지기 시작하는데, 계획 없이 시작하면 AI는 제일 빠른 길로 달려가고 그게 맞는 길이라는 보장은 없으니 저는 이 순서가 마음에 들었습니다.
다만 리뷰를 거친 계획이라고 맞는 계획이 되는 건 아닙니다. 예전에 plan.md 얘기를 쓰면서도 비슷한 생각을 했는데, 계획을 세울 때는 모르는 게 있고 그건 코드를 짜봐야 드러납니다. 승인한 설계가 틀렸다는 걸 나중에 아는 일은 생각보다 흔합니다. 그래서 저는 /plan-eng-review가 계획을 맞게 만들어준다기보다, 적어도 계획이 뭐였는지는 남겨준다는 쪽에 더 의미가 있다고 봅니다. 나중에 틀렸다는 걸 알았을 때 어디서부터 틀렸는지 돌아볼 수 있으니까요. 계획이 머릿속에만 있으면 틀린 줄도 모르고 지나가는 경우가 많습니다.
범위를 보는 CEO 리뷰도 비슷하게 생각합니다. 뭘 빼도 되냐는 질문은 혼자 일할 때 특히 중요한데, 혼자면 빼자고 말해줄 사람이 없으니 하고 싶은 걸 다 넣게 됩니다. 사이드 프로젝트가 끝나지 않는 제일 흔한 이유가 그거라고 봅니다. 이 질문 하나만으로도 gstack을 깔아볼 이유는 충분하지 않을까 싶습니다.
코드를 짜고 나서는 /review입니다. 자기가 짠 코드를 자기가 리뷰하는 모양인데 맥락이 완전히 분리돼 있어서 실제로 놓친 게 잡힌다고 합니다. /qa에 URL을 넘기면 진짜 Chromium 브라우저가 떠서 화면을 보면서 동작을 확인합니다. 말로 됐다고 하는 거랑 화면에서 되는 걸 보는 건 꽤 다르죠. 그리고 /ship은 커밋 메시지랑 설명, 리뷰어 지정까지 넣어서 PR을 만듭니다. /land-and-deploy로 가면 프로덕션 배포까지 이어지고요. PR 설명 쓰는 게 은근히 귀찮은 일이라 이건 바로 써보고 싶어졌습니다. 마지막에 /retro로 한 주 동안 뭘 왜 결정했고 뭐가 잘 됐고 안 됐는지 돌아보고, 그게 다음 주 기획으로 들어갑니다.
/qa가 진짜 브라우저를 띄운다는 것도 오래 생각하게 됐습니다. AI가 된다고 말하는 것과 실제로 되는 것 사이의 거리는 생각보다 멉니다. 1부의 폴리필 일도 결국 그 거리에서 생긴 일이었습니다. 번들 사이즈는 줄었으니 지시대로는 된 거였는데 Safari에서는 안 됐습니다. 화면을 보는 단계가 기본으로 들어가 있었다면 그 일은 조금 일찍 잡혔을지도 모릅니다. 물론 QA가 Chromium으로 돈다면 Safari 문제는 그대로 지나갔을 수도 있겠지만요.
/retro는 혼자 일하는 사람이 제일 안 하는 일이라 눈에 띄었습니다. 혼자 하면 회고할 상대가 없으니 그냥 다음 일로 넘어가게 됩니다. 커맨드로 정해두면 적어도 한 주에 한 번은 멈추게 되는데, AI가 돌아보는 한 주가 내가 기억하는 한 주랑 같을지는 궁금합니다. 커밋 기록에 남은 것만 보고 회고하면 왜 그렇게 결정했는지는 빠질 것 같아서요. 결정의 이유는 대개 기록 밖에 있습니다.
쭉 보면 팀에 당연히 있는 과정입니다. 기획, 아키텍처 리뷰, 코딩, 코드 리뷰, QA, 배포, 회고. 그 역할을 사람 대신 AI가 하고, 그 AI들을 지휘하는 게 혼자 앉아 있는 개발자 한 명이라는 것만 다릅니다.
이걸 보다가 든 생각이 하나 있습니다. 팀에서 이 과정들이 귀찮게 느껴지는 건 단계마다 다른 사람을 기다려야 해서인 것 같습니다. 리뷰어가 바쁘고, QA는 다른 일을 하고 있고, 배포 담당은 회의 중이고요. gstack은 그 기다림을 없앱니다. 그런데 기다림이 없어지면 단계 사이에 생각할 시간도 같이 없어지는 건 아닐까 싶습니다. 리뷰를 기다리다가 내 코드를 다시 열어보고 스스로 뭔가를 찾는 경우가 있는데, 다음 커맨드를 바로 칠 수 있으면 그런 일은 줄어들 것 같습니다. 써보지 않고 하는 짐작이라 실제로는 어떨지 모르겠습니다.
60만 줄
숫자를 다시 보면, 이건 Garry Tan 본인이 한 말이고 누가 따로 확인한 수치는 아닙니다. AI가 만든 코드도 다 들어가 있습니다. 숫자를 처음 봤을 때는 솔직히 좀 위축됐습니다. 두 달에 60만 줄이면 웬만한 개발자가 몇 년 동안 쓰는 양일 테니까요. 그런데 코드 줄 수로 품질을 잴 수는 없으니까, 1만 줄짜리 보일러플레이트랑 100줄짜리 핵심 로직은 같은 1만 줄이 아닙니다. README에는 2013년에 비해 생산성이 810배쯤 올랐다는 말도 있는데, 재는 기준이 본인이 정한 정규화된 코드 변경량이라 저는 크게 의미를 두지 않았습니다.
810배라는 숫자는 특히 그렇습니다. 2013년의 본인과 지금의 본인을 비교한 건데, 그 사이에 바뀐 게 AI만은 아닐 겁니다. 경험도 쌓였고 만드는 것도 달라졌을 테니까요. 그걸 다 빼고 AI 덕분이라고 하기는 어렵다고 봅니다. 본인도 그걸 모르진 않을 것 같고요.
그래도 혼자 감당할 수 있는 개발 범위가 AI 때문에 확 넓어졌다는 건 저도 느낍니다. 1만 줄이든 2만 줄이든 810배든 저한테 남은 건 규모보다, 기획하고 리뷰하고 테스트하고 배포하는 팀의 과정을 혼자서 돌릴 수 있게 됐다는 쪽이었습니다.
만약 이 숫자가 6만 줄이었다면 어땠을까 생각해봤습니다. 두 달에 6만 줄이어도 혼자서는 꽤 많은 양인데, 아마 지금처럼 퍼지지는 않았을 겁니다. 그랬다면 사람들은 숫자보다 커맨드 구조를 먼저 봤을 거고 gstack에 대한 얘기도 조금 다르게 나왔을 것 같습니다. 숫자가 크면 관심을 끄는 데는 좋은데 그다음 얘기가 전부 숫자에 묶입니다. 진짜냐 아니냐, AI가 짠 걸 쳐줘도 되냐 같은 얘기만 남고, 정작 도구가 어떤 순서로 일을 시키는지는 뒤로 밀립니다. Garry Tan이 README에 코드 빨리 짜는 도구가 아니라고 굳이 적어둔 걸 보면 본인도 그걸 알고 있었던 것 같습니다.
HN에서 나온 얘기들
공개되자마자 Hacker News에 토론이 붙었는데, 저는 거기 나온 비판들이 더 재밌었습니다.
도구가 공개되면 칭찬보다 비판이 먼저 쓸모가 있다고 생각하는 편입니다. 칭찬은 대체로 비슷한데 비판은 쓰는 사람마다 걸리는 데가 달라서, 그걸 모아 보면 도구가 실제로 어디서 문제가 생기는지가 보입니다.
텔레메트리 얘기가 먼저 나왔습니다. 사용 패턴을 수집한다는 건데, YC가 이걸 스타트업 아이디어 찾는 데 쓰는 거 아니냐는 의심까지 나왔습니다. 끌 수는 있지만 기본값이 수집하는 쪽이라는 게 좀 찜찜합니다. 공짜로 풀린 도구를 쓸 때마다 데이터가 어디로 가는지를 묻게 되는데, 이번에도 그 질문이 제일 먼저 나왔다는 게 좀 씁쓸했습니다.
한 사용자는 에이전트가 70분 동안 프로덕션 설정 파일에 스테이징 URL을 계속 집어넣는 버그를 겪었다고 올렸습니다. 거버넌스 단계가 있어도 이런 일은 일어난다는 얘기입니다. 저는 이게 1부에서 쓴 Paperclip 문제를 작게 다시 본 것 같았습니다. URL을 업데이트하라는 지시를 받았고, 70분 동안 아주 충실하게 했습니다. 멈출 이유가 없었으니까요. 70분이면 사람이 커피 한 잔 마시고 회의 하나 들어갔다 나올 시간입니다. 그동안 아무도 화면을 안 봤다는 얘기고, 혼자 일한다는 건 그 70분을 봐줄 사람도 없다는 뜻이기도 합니다.
70분 동안 멈추지 않았다는 게 저는 제일 무섭게 읽혔습니다. 사람이었으면 세 번째쯤에서 이상하다고 느꼈을 겁니다. 같은 파일을 계속 고치고 있는데 뭔가 잘못된 거 아닌가 하고요. AI한테는 그 이상하다는 느낌이 없습니다. 그러니 그 느낌을 대신할 무언가가 바깥에 있어야 하는데, gstack의 단계들은 계획 앞뒤에는 있어도 실행 한가운데에는 없는 것 같습니다.
CEO 리뷰, 엔지니어링 리뷰, QA로 나눈 구조가 단순한 프로젝트엔 잘 맞는데, 프로젝트마다 검토 기준이 달라야 할 때 어떻게 바꿔 쓸지는 분명하지 않다는 지적도 있었습니다. 저도 이게 제일 궁금했습니다. 제 프로젝트에서 QA가 뭘 봐야 하는지는 제가 제일 잘 아는데, 그걸 남이 만든 역할 안에 어떻게 집어넣을지는 쓰는 사람이 다시 손봐야 하는 부분일 것 같습니다. 이런 얘기들을 보고 나니 gstack이 뭘 해결하고 뭘 못 하는지가 좀 더 또렷해졌습니다.
텔레메트리 얘기는 조금 더 생각하게 됩니다. YC가 아이디어를 찾는 데 쓴다는 건 의심이지 확인된 얘기는 아닌데, 그런 의심이 바로 나온다는 것 자체가 요즘 개발 도구를 대하는 분위기를 보여주는 것 같습니다. 무료로 풀린 설정 파일 하나에도 이게 왜 공짜인지를 먼저 묻게 됐습니다. 만약 기본값이 꺼져 있었다면 토론의 첫 줄이 달랐을 것 같은데, 그 정도 차이로 도구의 첫인상이 정해진다는 게 좀 아깝기도 합니다. 도구를 만든 사람 입장에서는 데이터가 있어야 고칠 수 있다고 생각했을 수도 있고요.
paperclip.ing이랑 나란히 놓으면
paperclip.ing은 다중 에이전트 플랫폼입니다. AI 회사를 만든다는 개념이고, 에이전트들이 서로 협업하고 사람은 이사회처럼 승인권을 쥡니다. 거버넌스가 아키텍처 단계에서 들어가 있습니다.
에이전트가 서로 협업한다는 그림은 멋있는데, 저는 그 그림을 볼 때마다 누가 전체를 보고 있는지가 궁금해집니다. 사람이 이사회처럼 승인권을 쥔다고 해도, 승인할 게 하루에 수십 건씩 올라오면 그건 승인이 아니라 도장을 찍는 일이 될 것 같습니다.
gstack은 그 문제를 아예 피해 갑니다. 에이전트가 하나뿐이고 사람도 하나뿐이니 승인할 게 쌓이지 않습니다. 대신 그 한 사람이 모든 단계를 다 봐야 하는데, 하루 1만 줄씩 나오는 속도에서 그게 가능한 일인지는 잘 모르겠습니다. 그 속도면 사람이 읽는 것보다 코드가 나오는 게 더 빠를 것 같습니다.
gstack에는 에이전트가 여럿 있지 않습니다. Claude 하나가 상황마다 다른 역할을 쓰는 구조고, 거버넌스는 플랜을 먼저 리뷰한다는 과정 안에서 작동합니다.
Claude 하나가 역할만 바꿔 쓴다는 건 좀 이상한 구조이기도 합니다. CEO도 Claude고 QA도 Claude면 같은 머리가 모자만 바꿔 쓰는 셈이니까요. 맥락을 분리해두면 다른 사람처럼 군다고는 하는데, 같은 모델이 놓치는 건 모자를 바꿔도 같이 놓칠 것 같습니다. 그래도 하나의 맥락 안에서 다 하는 것보다는 낫겠지요. 적어도 방금 자기가 짠 코드를 감싸고 싶은 마음은 덜할 테니까요.
1부에서 꺼낸 질문, AI한테 목표를 줄 때 어떻게 통제할 거냐에 paperclip.ing은 아키텍처로 답하고 gstack은 워크플로우로 답하는 셈입니다. 혼자 사이드 프로젝트를 돌리는 거면 gstack 쪽이 맞을 것 같고, 실제로 에이전트 팀을 굴리는 제품을 만든다면 paperclip.ing 같은 거버넌스 레이어가 필요할 것 같습니다. 둘 중 뭐가 낫냐를 묻기 전에 지금 몇 명이서 뭘 만들고 있느냐를 먼저 물어보게 됩니다.
그런데 혼자 하던 사이드 프로젝트가 어느 날 팀이 되면 어떻게 되는지는 잘 모르겠습니다. gstack으로 시작해서 사람이 한두 명 붙으면 그 사람들도 같은 커맨드를 쓰게 될 텐데, 그때 CEO 리뷰는 누구의 관점이 되는 걸까요. 혼자일 때는 Garry Tan의 관점을 빌려 쓰는 거였지만, 셋이 되면 그 관점이 팀의 기준처럼 굳어버릴 수도 있을 것 같습니다. 아무도 그렇게 정한 적이 없는데 커맨드가 그렇게 돼 있으니까 그렇게 하는 식으로요. paperclip.ing처럼 처음부터 승인 구조를 설계해두는 쪽이 그럴 때는 덜 헷갈릴 것 같기도 한데, 이건 둘 다 그 규모까지 써본 사람 얘기를 들어봐야 알 것 같습니다.
근데 이거 Anthropic이 이미 만들어둔 거 아닌가
23개 커맨드를 열어보면 구조가 꽤 단순합니다. Claude Code의 커스텀 커맨드 기능에 CLAUDE.md로 역할 정의를 써둔 겁니다. 새로운 기술은 없고 Anthropic이 Claude Code에 이미 넣어둔 기능들입니다. 이걸 알고 나서 좀 김이 샜습니다. 대단한 비밀 무기인 줄 알았는데 열어보니 제 컴퓨터에도 있는 기능이었으니까요.
그런데 김이 샌 건 잠깐이었고, 조금 지나니 오히려 그게 더 흥미로웠습니다. 제 컴퓨터에도 있는 기능인데 저는 그걸 저렇게 묶어서 쓸 생각을 안 하고 있었으니까요. 기능이 있다는 것과 그 기능으로 뭘 할지 아는 건 꽤 다른 얘기였습니다.
paperclip.ing도 크게 다르지 않습니다. 거버넌스 레이어는 인상적이지만 그 밑에는 Claude의 멀티 에이전트 오케스트레이션이 깔려 있고, 에이전트가 에이전트를 고용할 수 없다는 규칙도 Anthropic 에이전트 SDK 위에서 돕니다.
이게 나쁘다는 얘기는 아닙니다. 다들 같은 땅 위에 집을 짓고 있다는 걸 알게 됐다는 정도입니다. 다만 땅 주인이 규칙을 바꾸면 두 집이 같이 영향을 받을 텐데, 그런 생각까지 하면서 설정 파일을 받는 사람은 별로 없을 것 같습니다. 저도 평소엔 그런 생각을 잘 안 합니다. 받을 때는 받는 게 급하니까요.
그러고 보니 Paperclip 문제를 풀려는 시도 두 개가 다 같은 인프라 위에 있었고, 그 인프라를 만든 게 Anthropic이었습니다. 그 안에 같은 패턴이 이미 들어 있기도 하고요. .claude/agents/에 역할별 에이전트를 정의하고, .claude/skills/에 커스텀 슬래시 커맨드를 두고, CLAUDE.md에 프로젝트 지침을 쓰고, hooks로 이벤트마다 자동화를 거는 구조가 gstack이랑 거의 똑같습니다. 어떻게 보면 gstack은 Anthropic 도구를 잘 쓰는 법을 Garry Tan이 정리해서 공개한 겁니다.
Anthropic 입장에서는 꽤 좋은 일일 것 같습니다. 자기 도구를 어떻게 써야 하는지를 YC CEO가 직접 보여준 셈이니까요. 만약 Anthropic이 똑같은 걸 공식 예제로 냈다면 이만큼 화제가 됐을까 싶은데, 아마 아니었을 겁니다. 같은 설정 파일이라도 누가 썼느냐에 따라 사람들이 받아들이는 무게가 다릅니다.
제가 보기에 gstack이 값진 건 기술보다 골라 담은 솜씨 쪽입니다. 역할 정의 하나를 제대로 쓰는 데 얼마나 오래 걸리는지는 써본 사람은 압니다. gstack은 Garry Tan이 수백 시간 실제로 쓰면서 다듬은 걸 설정 파일로 눌러 담은 거라, 처음부터 다시 만들 필요 없이 출발할 수 있게 해줍니다. 그런데 남이 쓴 역할 정의를 그대로 받아 쓰면 그 사람의 판단 기준도 같이 받아 쓰는 거라, 그 CEO 리뷰는 Garry Tan의 눈으로 내 프로젝트를 보는 거라는 건 알고 쓰는 게 좋을 것 같습니다.
어떻게 보면 그게 gstack의 장점이기도 합니다. 내가 아닌 다른 사람의 눈으로 내 프로젝트를 한 번 보는 거니까요. 혼자 일하면 제일 부족한 게 그겁니다. 다만 그 눈이 늘 같은 사람의 눈이라는 게 걸리고, 몇 달 쓰다 보면 그 사람의 기준이 내 기준인 것처럼 느껴질 것 같습니다.
그리고 이걸 보면서 AI 개발 도구에서 정말 차이를 만드는 건 도구보다 어떻게 쓰느냐 쪽이라는 생각이 들었습니다. Garry Tan이 이걸 그냥 공개할 수 있었던 것도 도구가 원래 자기 것이 아니어서였을 것 같습니다.
이 생각을 조금 더 밀어보면 좀 불편한 데까지 갑니다. 도구가 다 같은 회사 것이고 차이가 쓰는 법에서 난다면, 쓰는 법은 이렇게 공개되는 순간 누구나 가져갈 수 있습니다. 그러면 남는 차이는 그 쓰는 법을 자기 프로젝트에 맞게 고치는 능력 정도일 텐데, 그건 설정 파일로 나눠 주기 어려운 종류의 것입니다. gstack을 받아서 그대로 쓰는 사람과 받아서 절반을 지우는 사람이 있다면 저는 뒤쪽이 더 많이 얻어갈 것 같습니다. 지운다는 건 뭐가 필요 없는지 안다는 뜻이니까요. 처음 받을 때는 다 필요해 보이는 게 문제지만요.
누구한테 맞을까
README에 꽤 솔직하게 적혀 있습니다.
"GStack is excellent for solo developers and small founding teams who need a structured AI coding workflow out of the box."
혼자 개발하는 사람, 작은 창업 팀, 짜여진 AI 워크플로우가 바로 필요한 사람들입니다.
저는 여기에 한 부류를 더 넣고 싶습니다. 회사에서는 팀으로 일하지만 사이드 프로젝트는 혼자 하는 사람이요. 낮에는 리뷰도 있고 QA도 있는 환경에 있다가 밤에 혼자 뭘 만들면 그 과정들이 한꺼번에 사라집니다. 그 빈 곳이 꽤 크게 느껴질 텐데, gstack은 딱 그 빈 곳을 채우려고 만든 물건 같습니다. 낮에 익숙했던 과정을 밤에도 비슷하게 따라 할 수 있게 해주는 거죠.
거꾸로 보면 더 잘 보입니다. 이미 잘 굴러가는 팀이 있고 CI/CD랑 코드 리뷰 과정이 이미 갖춰져 있다면 gstack은 과합니다. 원래 있던 과정 위에 AI를 얹는 게 나을 겁니다. 잘 돌아가는 팀에 남의 회사 CEO 관점을 하나 더 끼워 넣을 이유는 별로 없어 보입니다. gstack이 빛나는 건 아무것도 없을 때입니다. 팀도 없고 과정도 없고 혼자 제품을 만들어야 할 때, 커맨드 23개가 그 팀의 과정을 대신해줍니다.
반대로 팀은 있는데 과정이 없는 경우도 있을 겁니다. 사람은 여럿인데 리뷰도 대충, 배포도 각자 하는 팀이요. 그런 팀이 gstack을 쓰면 어떻게 될지 궁금합니다. 과정이 생기는 건 좋은데, 그 과정을 AI가 정해준 대로 따르게 되면 팀이 스스로 과정을 만들어볼 기회는 없어질 수도 있겠다 싶습니다. 남이 만든 과정은 왜 그렇게 생겼는지 모르고 따르게 되니까요.
이 도구를 보면서 제일 오래 붙잡고 있던 건 사실 이어받는 쪽입니다. 혼자 gstack으로 두 달을 만들고 나면, 그 코드를 다음에 받는 사람은 커맨드 23개가 내린 판단 위에서 시작하게 됩니다. 왜 이 구조냐고 물으면 /plan-eng-review가 그렇게 정했다는 답밖에 없을 수도 있습니다. 혼자 빨라지는 건 분명한데, 옆 사람이 그걸 받아서 이어갈 수 있는지는 좀 다른 문제 같습니다. 결정한 이유를 어딘가 짧게라도 적어두는 단계가 있으면 좋겠다 싶은데, /retro가 그걸 어디까지 해줄 수 있을지는 모르겠습니다.
처음 봤을 때 별로 낯설지 않았던 것도 그래서인 것 같습니다. Claude Code를 쓰는 사람이면 이미 비슷한 걸 어딘가에서 하고 있을 겁니다. 이 코드 리뷰해줘, 배포 전에 테스트 시나리오 뭐 있는지 알려줘, 이런 식으로요. gstack은 그렇게 그때그때 던지던 질문을 정해진 모양으로 묶어둔 겁니다. 매번 다르게 물으면 답도 매번 다르고, 정해진 커맨드를 치면 같은 수준의 답이 나옵니다. 팀에서 코드 리뷰가 값진 것도 리뷰어가 특별히 뛰어나서라기보다 PR마다 같은 기준으로 리뷰가 일어나서인데, /review가 하는 것도 그겁니다.
생각해보면 사람 리뷰어도 매번 같은 수준은 아닙니다. 피곤한 날에는 대충 보고 넘어가고, 급한 날에는 승인부터 누릅니다. 커맨드는 그런 게 없으니 일정한 건 맞는데, 일정하다는 게 늘 좋은 건지는 잘 모르겠습니다. 사람 리뷰어가 가끔 엉뚱한 데서 큰 문제를 짚는 건 그날 유난히 그 부분이 신경 쓰였기 때문일 때가 있으니까요. /review가 그런 엉뚱한 지적을 할 수 있을지는 써봐야 알 것 같고, 못 한다면 그건 사람이 가끔 따로 봐줘야 하는 부분으로 남을 것 같습니다.
그때그때 던지던 질문을 정해진 모양으로 묶는다는 건, 거꾸로 말하면 질문을 바꾸기가 귀찮아진다는 뜻이기도 합니다. 커맨드가 있으면 커맨드를 치게 되고, 그 커맨드가 묻지 않는 건 잘 안 묻게 됩니다. 편해지는 만큼 질문이 좁아지는 건데, 이건 gstack만의 문제는 아니고 템플릿을 쓰면 늘 따라오는 문제 같습니다.
혼자서 기획부터 배포까지 다 돌리는 게 점점 해볼 만한 일이 되고 있습니다. 그게 늘 좋은 건 아니고, 70분짜리 루프처럼 보는 눈이 없으면 AI는 여전히 엉뚱한 데로 달려갑니다. 1부에서 쓴 보상 해킹 문제는 gstack 안에서도 그대로 있습니다. gstack은 그걸 없애기보다 플랜 리뷰, 코드 리뷰, QA 같은 단계마다 한 번씩 멈춰 세워서 덜 일어나게 만드는 쪽입니다. 목표 하나를 주면 그쪽으로 끝없이 달려간다는 게 Paperclip Maximizer 얘기였는데, 그러니까 단계마다 멈추고 보자는 게 gstack이 내놓은 답이고, 저는 이게 완벽하지는 않아도 지금 혼자 일하는 사람이 쓸 수 있는 현실적인 답이라고 봅니다.
댓글
댓글 쓰기