AI와 함께 만드는 삶

저PBR 전략이 사실은 은행주 전략이었다 — 밸류업 정책 특수를 의심하고 검증한 과정

makewithai — Thu, 23 Jul 2026 15:31:48 +0900

살아남은 저PBR 전략을 페이퍼 트레이딩에 넣고 몇 주 지켜보다가 이상한 패턴을 발견했다. 매달 골라지는 10종목 중 4~5개가 은행이나 금융지주였다.

신한지주, 하나금융지주, 우리금융지주, 기업은행, 삼성생명. 업종이 자꾸 겹쳤다.

"분산 투자한다고 10종목을 골랐는데, 사실상 은행 한 업종에 몰아넣은 거 아닌가?"

이 의심에서 시작해 두 개의 실험을 돌렸다. 결과는 둘 다 예상과 반대였다.

왜 저PBR은 은행주가 되는가

PBR이 무엇인지 먼저

PBR(주가순자산비율)은 주가 ÷ 주당 순자산이다. 회사가 가진 자산에서 빚을 뺀 장부상 가치 대비, 시장이 그 회사에 얼마를 매기고 있는지를 나타낸다.

PBR 0.4라면 장부상 1만 원짜리 회사를 시장이 4천 원에 사고 있다는 뜻이다. "싸다"고 볼 수도 있고, "시장이 그럴 만한 이유로 낮게 본다"고 볼 수도 있다. 저PBR 전략은 앞쪽에 베팅하는 전략이다.

은행이 구조적으로 저PBR인 이유

이유를 찾아보니 우연이 아니라 구조적인 문제였다.

자본이 크게 잡힌다 — 은행업은 건전성 규제 때문에 일정 수준 이상의 자기자본을 반드시 쌓아둬야 한다. 분모(순자산)가 커진다.
성장 기대가 낮다 — 시장이 낮은 배수를 매긴다. 분자(주가)가 눌린다.
번 돈을 배당으로 돌린다 — 성장에 재투자할 데가 마땅치 않으니 주주환원으로 간다. 저성장·고배당 성격이 굳어진다.

분모는 크고 분자는 눌리니 PBR이 항상 낮게 유지된다. 결국 한국 시장에서 "저PBR 종목을 고른다"는 건 상당 부분 "은행주를 고른다"와 같은 말이었다.

문제는 이게 위험한가였다. 한 업종에 쏠려 있으면 그 업종이 흔들릴 때 계좌 전체가 같이 흔들리는 것 아닌가.

실험 1 — 업종을 강제로 분산시켜봤다

업종당 최대 보유 종목 수를 제한하는 규칙을 추가했다. 최대 2개, 3개, 4개로 각각 백테스트를 돌렸다.

조건CAGR최대낙폭샤프하락·횡보장(2021~2023)

제한 없음 (현재)	+12.0%	-56.4%	0.60	+39.9%
업종당 최대 4종목	+11.4%	-56.1%	0.57	+17.7%
업종당 최대 3종목	+10.5%	-56.9%	0.54	+10.9%
업종당 최대 2종목	+11.3%	-59.9%	0.56	+6.6%

전부 나빠졌다.

그런데 단순히 수익만 깎인 게 아니었다. 최대낙폭이 전혀 개선되지 않았다. 오히려 2종목 제한에서는 -56.4%에서 -59.9%로 더 나빠졌다. 분산의 목적은 위험을 줄이는 건데, 위험은 그대로고 수익만 줄어든 셈이었다.

가장 눈에 띈 건 마지막 열이다. 하락·횡보장 구간 수익이 +39.9% → +17.7% → +10.9% → +6.6% 로 제한을 조일수록 정확히 비례해서 무너졌다.

걱정했던 리스크가 사실은 수익의 원천이었다

원인은 명확했다. 은행주 쏠림 자체가 하락장에서 이 전략이 버틴 이유였다.

은행주는 저성장·고배당 특성 때문에 시장이 무너질 때 상대적으로 덜 흔들린다. 배당 수익률이 방어선 역할을 하고, 애초에 기대가 낮게 잡혀 있어서 실망으로 인한 급락 여지도 작다.

업종을 억지로 분산시키면 그 방어력을 걷어내는 꼴이었다. 대신 들어오는 종목들은 변동성이 더 큰 업종이라 낙폭도 줄지 않았다.

분산이 항상 옳다는 통념이 이 전략에서는 통하지 않았다. 정확히는, 이미 특정 성격(저PBR)으로 종목을 걸러낸 상태에서 업종만 억지로 흩뿌리면, 전략이 노렸던 성격 자체가 희석된다.

실험 2 — "그거 밸류업 정책 특수 아니야?"

이 결과를 정리하고 있는데 더 날카로운 질문이 들어왔다.

"이거 최근에 금융권 장이 좋아서 그런 거 아니야? 최근 데이터만 그런 거 아니야?"

정곡을 찌르는 질문이었다.

밸류업 프로그램이라는 변수

정부는 2024년 1월 17일 민생토론회에서 상장회사 주가가 기업가치보다 낮게 평가되는 현상을 극복하겠다며 '기업 밸류업 프로그램' 도입을 공표했고, 이어 1월 24일 금융위원장이 한국거래소 등과 함께 개최한 1차 세미나에서 지원방안의 주요 내용을 소개했다.

이 정책의 핵심 타깃이 바로 저PBR 종목, 그중에서도 은행·금융주였다. 발표 직후 외국인 순매수 상위 종목에 금융주를 비롯한 저PBR주가 다수 이름을 올렸다는 보도가 나올 정도였다.

즉 내 전략이 최근에 좋았던 게 실력이 아니라 일회성 정책 이벤트에 올라탄 것일 가능성이 있었다. 그렇다면 이 전략은 정책 효과가 소진되는 순간 무너진다.

바로 확인해야 했다.

정책 발표 전후로 쪼갰다

세미나 발표일인 2024년 1월 24일을 기준선으로 잡고, 전체 기간을 둘로 나눴다. 비교 대상은 그냥 40종목을 보유만 하는 경우(기준선) 와 저PBR 전략이다.

기간그냥 보유저PBR 전략저PBR의 초과수익

2018 ~ 2024.1 (정책 이전, 5.9년)	연 -1.4% 누적 -8.0%	연 +0.7% 누적 +4.4%	+12.4%p 전략 승
2024.1 ~ 현재 (정책 이후, 2.4년)	연 +55.1% 누적 +183.2%	연 +45.2% 누적 +142.5%	-40.8%p 보유 승

연 55.1%가 과해 보일 수 있는데, 2.4년 누적 183.2%를 연환산한 값이라 계산상 맞는 숫자다. 이 구간이 그만큼 이례적인 강세장이었다는 뜻이기도 하다.

결과는 걱정했던 것과 정반대였다.

최근 수익은 전략의 공이 아니었다

최근 2년의 대박 수익은 저PBR 효과가 아니었다. 시장 전체가 오른 것이었다.

그냥 40종목을 사서 아무것도 안 하고 들고만 있었어도 연 55.1%다. 저PBR 전략은 45.2%로, 오히려 40%포인트 넘게 뒤졌다. 이 기간은 반도체 랠리로 시장 전체가 밀어올려진 시기였고, 은행주 중심인 저PBR 전략은 그 랠리를 따라가지 못했다.

정책 특수를 의심했는데, 확인해보니 정책 특수조차 제대로 못 누린 셈이었다.

그럼 이 전략의 실력은 어디에 있었나. 정책 발표 이전, 시장이 죽어 있던 5.9년 구간이다.

그냥 보유: 연 -1.4% (마이너스)
저PBR 전략: 연 +0.7% (플러스 방어)

이 구간은 밸류업 정책과 아무 상관이 없다. 정책 이전이니까. 화려한 숫자는 아니지만, 시장이 돈을 잃는 동안 잃지 않았다는 게 이 전략이 실제로 한 일이었다.

두 실험을 합쳐서 보면

따로 돌린 두 실험의 결론이 같은 곳을 가리켰다.

실험발견

업종 분산 실험	은행주 쏠림이 하락장 방어력의 원천이다
정책 특수 검증	전략의 실력은 하락·정체 구간에서 나왔다

저PBR 전략의 정체는 "많이 버는 전략"이 아니라 "시장이 안 좋을 때 덜 잃는 전략"이었다. 은행주 쏠림이 그 방어력의 원천이고, 그 방어력이 진짜로 발휘된 건 정책과 무관한 하락·정체 구간이었다.

목표 수치를 다시 봐야 했다

이건 처음 세웠던 "연 12% 목표"를 재검토해야 한다는 뜻이기도 했다. 그 숫자에는 최근 강세장의 몫이 크게 섞여 있다.

앞으로 성장주 중심의 랠리가 이어진다면 이 전략은 시장 평균보다 덜 벌 가능성이 높다. 중요한 건 그게 전략이 고장 난 게 아니라 원래 그런 성격이라는 점이다.

이걸 미리 알아두는 것과 모르는 것의 차이는 크다. 모르면 6개월쯤 시장에 뒤처졌을 때 "이 전략 망가졌나" 하고 파라미터를 만지기 시작한다. 그게 대부분 시스템이 망가지는 경로다.

그래서 기준을 이렇게 바꿨다.

절대 수익률로 전략을 평가하지 않는다
같은 기간 그냥 보유했을 때와 비교해서 평가한다
상승장에서 뒤처지는 건 실패가 아니라 예상된 동작으로 간주한다
하락·횡보 구간에서 방어력이 사라지면, 그때가 진짜 이상 신호다

이번 편에서 배운 것

두 실험 모두 직관이 틀렸다는 걸 데이터가 알려준 사례였다.

"쏠림은 위험하다" → 그 쏠림이 방어력의 원천이었다
"최근 수익은 정책 특수일 것이다" → 정책 특수는커녕 시장에 뒤처지고 있었다

공통점은 둘 다 의심을 실험으로 바꿨다는 것이다. 걱정만 하고 넘어갔다면 업종 제한을 넣어서 전략을 망쳤을 것이고, 최근 수익률을 그대로 믿었다면 지킬 수 없는 기대치를 갖고 있었을 것이다.

지난 편의 호가 바운스도 그랬다. 시스템을 만드는 일의 상당 부분은 좋아 보이는 숫자를 의심할 방법을 마련하는 것이라는 생각이 든다.

다음 편 예고

전략 얘기는 여기까지가 큰 줄기다. 이제부터는 이 전략을 실제로 돌리기 위해 붙잡고 씨름했던 개발 이야기다.

공식 문서에도 안 나와 있는 API 응답 구조를 직접 호출해서 알아낸 과정, 그리고 실행 도중 콘솔 인코딩 때문에 프로그램이 끝난 뒤 입력하는 다음 명령어까지 깨지던 버그를 쫓아다닌 이야기를 다룬다.

이 글은 투자 권유가 아니며, 개인적인 AI·자동매매 시스템 개발 과정의 기록입니다. 백테스트 결과는 과거 데이터에 대한 시뮬레이션이며 미래 수익을 보장하지 않습니다. 언급된 종목은 백테스트 과정에서 선정된 예시일 뿐 추천이 아닙니다.

문의하기

makewithai — Thu, 23 Jul 2026 14:06:10 +0900

블로그 내용에 대한 질문이나 의견을 환영합니다.

연락처

이메일: moraenymph@naver.com

가능한 한 빠르게 답변드리려 하지만, 본업과 병행하고 있어 며칠 걸릴 수 있는 점 양해 부탁드립니다.

이런 문의를 받고 있습니다

글 내용에 대한 질문 설명이 부족했던 부분, 따라 하다 막힌 지점, 환경이 달라 재현되지 않는 경우 등 무엇이든 좋습니다. 질문 주신 내용은 해당 글을 보완하는 데 반영합니다.

오류 지적 사실관계가 틀렸거나, 도구 버전이 바뀌어 글의 내용이 더 이상 맞지 않는 경우 알려주시면 감사하겠습니다. 확인 후 본문을 수정하고 수정 시점을 함께 표기합니다.

글 주제 제안 다뤄줬으면 하는 도구나 주제가 있다면 알려주세요. 직접 써보고 판단할 만한 것이면 후기로 정리합니다.

협업 및 기타 제안 기술 관련 협업, 기고, 강의 등의 제안도 받고 있습니다.

문의 시 참고

기술적인 문제를 문의하실 때는 아래 정보를 함께 주시면 훨씬 정확한 답변이 가능합니다.

어떤 글의 어느 부분인지 (링크 또는 소제목)
사용 중인 환경 (운영체제, 언어·도구 버전)
실행한 명령과 실제로 나온 오류 메시지

답변드리기 어려운 문의

개별 투자 자문 및 종목 추천 — 본 블로그의 자동매매 관련 글은 개발 과정의 기록이며 투자 권유가 아닙니다. 투자 판단에 대한 상담은 드리지 않습니다.
광고성 제휴 및 홍보 요청 — 블로그 성격과 맞지 않는 제안은 답변드리지 못할 수 있습니다.

운영자: makewithai · https://makewithai.kr

개인정보처리방침

makewithai — Thu, 23 Jul 2026 14:05:00 +0900

AI와 함께 만드는 삶(이하 "본 블로그", https://makewithai.kr)은 방문자의 개인정보를 중요하게 생각하며, 개인정보보호법 등 관련 법령을 준수합니다. 본 방침은 본 블로그가 어떤 정보를 수집하고 어떻게 이용하는지 안내합니다.

1. 수집하는 정보

본 블로그는 회원가입 절차가 없으며, 방문자에게 이름·연락처 등의 개인정보를 직접 요구하지 않습니다. 다만 서비스 이용 과정에서 아래 정보가 자동으로 생성·수집될 수 있습니다.

자동 수집 항목

IP 주소, 브라우저 종류 및 버전, 운영체제 정보
방문 일시, 접속 경로(유입 검색어 및 참조 URL), 페이지 이용 기록
쿠키(Cookie)를 통한 방문 기록

이용자가 직접 입력하는 경우

댓글 작성 시: 닉네임, 비밀번호, 댓글 내용, IP 주소
문의 시: 이용자가 이메일에 기재한 내용

2. 정보의 이용 목적

수집된 정보는 아래 목적으로만 이용합니다.

블로그 방문 통계 분석 및 콘텐츠 개선
댓글 등 이용자 참여 기능의 운영
스팸·부정 이용 방지
문의 사항에 대한 답변

이용자의 사전 동의 없이 위 목적 외의 용도로 이용하거나 제3자에게 제공하지 않습니다.

3. 쿠키(Cookie) 사용에 대하여

본 블로그는 방문자에게 더 나은 서비스를 제공하기 위해 쿠키를 사용합니다. 쿠키는 웹사이트가 이용자의 브라우저에 저장하는 작은 텍스트 파일로, 방문 기록과 이용 형태를 파악하는 데 사용됩니다.

3-1. 광고 및 분석 서비스의 쿠키

본 블로그는 광고 게재 및 방문 분석을 위해 아래와 같은 제3자 서비스를 이용하거나 향후 이용할 수 있습니다.

Google AdSense — 구글 및 협력사는 광고 게재를 위해 쿠키를 사용하며, 이를 통해 이용자의 본 블로그 및 다른 웹사이트 방문 기록에 기반한 맞춤 광고를 표시할 수 있습니다.
Kakao AdFit — 국내 광고 게재를 위해 쿠키를 사용할 수 있습니다.
Google Analytics / 티스토리 통계 — 방문자 수, 유입 경로 등 통계 분석 목적으로 이용됩니다.

3-2. 맞춤 광고 거부 방법

이용자는 아래 방법으로 맞춤 광고를 거부할 수 있습니다.

Google 광고 설정 — https://www.google.com/settings/ads 에서 맞춤 광고 사용을 해제할 수 있습니다.
브라우저 설정 — 사용 중인 브라우저의 설정 메뉴에서 쿠키 저장을 거부하거나 삭제할 수 있습니다.
- Chrome: 설정 → 개인정보 및 보안 → 서드파티 쿠키
- Safari: 환경설정 → 개인정보 보호
- Edge: 설정 → 쿠키 및 사이트 권한

쿠키 저장을 거부할 경우 일부 기능의 이용에 불편이 있을 수 있습니다.

4. 정보의 보유 및 파기

자동 수집된 접속 로그는 통계 분석 목적으로 이용된 후 티스토리 서비스 정책에 따라 보관·파기됩니다.
댓글은 작성자 본인 또는 운영자가 삭제할 때까지 보관됩니다.
이메일 문의 내용은 답변 완료 후 보관 필요가 없어진 시점에 삭제합니다.

5. 제3자 제공 및 처리 위탁

본 블로그는 이용자의 개인정보를 제3자에게 제공하지 않습니다. 다만 법령에 근거하여 수사기관이 적법한 절차에 따라 요청하는 경우는 예외로 합니다.

본 블로그는 티스토리(주식회사 카카오)가 제공하는 블로그 플랫폼을 이용하고 있으며, 서비스 운영에 필요한 범위 내에서 해당 플랫폼의 개인정보 처리 정책이 함께 적용됩니다.

6. 이용자의 권리

이용자는 언제든지 본인의 정보에 대한 열람, 정정, 삭제를 요청할 수 있습니다. 댓글은 직접 삭제할 수 있으며, 그 외의 요청은 아래 연락처로 문의해 주시면 지체 없이 조치하겠습니다.

7. 외부 링크에 대한 책임

본 블로그에는 외부 사이트로 연결되는 링크가 포함될 수 있습니다. 링크된 외부 사이트의 개인정보 처리에 대해서는 본 블로그가 책임지지 않으므로, 해당 사이트의 정책을 별도로 확인하시기 바랍니다.

8. 콘텐츠 이용 안내

본 블로그의 글과 이미지에 대한 저작권은 운영자에게 있습니다. 인용 시 출처와 링크를 함께 표기해 주시면 감사하겠습니다.

본 블로그의 자동매매·투자 관련 글은 개인적인 개발 과정의 기록이며, 투자 권유나 투자 자문이 아닙니다. 게시된 내용을 근거로 한 투자 판단의 결과에 대해 운영자는 책임지지 않습니다.

9. 문의처

개인정보 처리에 관한 문의는 아래로 연락 주시기 바랍니다.

운영자: makewithai
이메일: moraenymph@naver.com

10. 방침의 변경

본 방침은 법령 또는 서비스 정책의 변경에 따라 수정될 수 있으며, 변경 시 본 페이지를 통해 공지합니다.

공고일자: 2026년 7월 23일
시행일자: 2026년 7월 23일

블로그 소개

makewithai — Thu, 23 Jul 2026 13:15:09 +0900

이 블로그는 무엇을 기록하나

AI를 실제로 써서 무언가를 만들고, 그 과정에서 겪은 시행착오를 기록하는 곳입니다.

잘 된 결과만 정리하는 곳이 아닙니다. 백테스트 수익이 착시였다는 걸 뒤늦게 발견한 과정, 세 번 연속 실패한 전략을 버린 이유, 새 도구를 써보고 기대에 못 미쳤던 경험 — 이런 것들이 오히려 더 자세히 남아 있습니다. 실패의 원인을 설명할 수 있게 되는 것이 다음 시도의 출발점이라고 생각하기 때문입니다.

누가 쓰나

본업은 IT 프로젝트의 PM(Project Manager)이자 PL(Project Leader)입니다. 상황에 따라 직접 개발도 합니다.

요구사항을 정의하고, 일정과 리스크를 관리하고, 만들어진 결과물이 원래 의도와 맞는지 검증하는 일을 오래 해왔습니다. 그래서 AI를 다룰 때도 비슷한 습관이 나옵니다. "일단 돌아가니까 됐다"보다 "이게 왜 이렇게 나왔는지 설명할 수 있나"를 먼저 묻는 편입니다.

AI 전문가로 자리 잡는 것이 중장기 목표이고, 그 과정을 공개적으로 기록하는 것이 이 블로그의 목적입니다.

다루는 주제

카테고리내용

AI시스템 설계기	AI를 활용한 시스템을 설계하고 만들어가는 과정의 기록. 판단은 코드가, 설명은 AI가 맡는 구조를 어떻게 만들었는지
바이브코딩 실전기	AI와 대화하며 실제로 동작하는 서비스를 만든 과정. 설치부터 배포까지의 단계별 기록
AI 활용 원칙 & 인사이트	여러 번 시행착오를 겪고 나서 정리된 원칙들. 어디까지 AI에 맡기고 어디부터는 직접 확인해야 하는가
PM 관점의 AI 프로젝트 운영	요구사항 정의, 일정 관리, 검증 같은 실무에 AI를 어떻게 붙일 수 있는지
AI 자동화 & 수익화 실험	반복 작업을 자동화하고, 그것이 실제로 얼마나 시간과 비용을 줄였는지 데이터로 확인한 기록
AI 용어 사전	헷갈리기 쉬운 AI 용어를 정의와 예시로 정리
AI 오픈소스 리뷰	새로 나온 오픈소스 도구를 직접 써보고, PM 관점에서 실무에 쓸 만한지 판단한 후기

진행 중인 연재

주식 자동매매 시스템 개발기 — AI와 함께 자동매매 시스템을 설계하고 검증해나가는 7편 시리즈입니다. 전략을 세우고, 백테스트를 돌리고, 그 결과가 착시였다는 걸 발견하고, 다시 검증 기준을 세우는 과정을 순서대로 기록하고 있습니다.

현재 페이퍼 트레이딩(가상매매) 단계이며, 실제 주문 기능은 구현하지 않았습니다. 이 시리즈는 개발 과정의 기록이며 투자 권유가 아닙니다.

글을 쓸 때 지키는 것

직접 해보지 않은 것은 쓰지 않습니다
숫자는 실제로 측정한 값만 적고, 추정치는 추정치라고 밝힙니다
잘 안 된 시도도 그대로 남깁니다
버전이 자주 바뀌는 도구를 다룰 때는 확인 시점을 함께 적습니다

연락

블로그 내용에 대한 질문, 오류 지적, 협업 제안 모두 환영합니다. 문의 페이지를 통해 연락 주세요.

운영자: makewithai

백테스트 수익이 가짜였다 — 호가 바운스 착시를 일봉으로 걸러낸 과정

makewithai — Thu, 23 Jul 2026 10:39:50 +0900

세 번 연속 실패한 뒤 겨우 찾은 두 개의 후보가 있었다. 하나는 대형주 중에서 장부가 대비 싼 종목만 골라 사는 전략(저PBR), 다른 하나는 소형주 중에서 최근 많이 떨어진 종목을 사는 전략(리버설)이었다.

월 단위로 계산한 첫 결과는 둘 다 인상적이었다. 저PBR은 샤프비율 0.63으로 지금까지 나온 모든 전략 중 최고였다. 그런데 리버설은 그보다 더 눈에 띄는 기록을 세웠다 — 상승장·하락장·최근 구간 세 개를 전부 플러스로 통과한 유일한 전략이었다. +59%, +23%, +37%. 지금까지 어떤 전략도 이렇게 전 구간에서 이긴 적이 없었다.

너무 좋아서 오히려 불안했다. 그리고 그 불안은 맞았다.

월말 종가라는 한 지점이 마음에 걸렸다

리버설 전략의 계산 방식은 이랬다.

매달 말일 종가를 기준으로 최근 한 달 수익률을 계산한다
가장 많이 떨어진 소형주 10개를 고른다
다음 달 한 달간 들고 있는다고 가정한다

문제는 1번의 "월말 종가"였다.

호가 바운스란 무엇인가

거래가 뜸한 소형주는 호가 사이의 간격(스프레드)이 넓다. 매수 호가 9,000원, 매도 호가 9,500원처럼 벌어져 있는 식이다. 이때 장 마감 직전에 누군가 급하게 팔면 9,000원(매수 호가)에 체결되고, 그 가격이 그날의 종가로 기록된다.

그런데 다음 거래일이 되면 다시 9,300원 근처의 정상 가격대로 돌아온다. 아무 일도 일어나지 않았는데 +3.3% 상승한 것처럼 보인다. 이걸 호가 바운스(bid-ask bounce)라고 부른다.

리버설 전략은 구조적으로 이 함정에 정확히 걸리게 되어 있었다. "가장 많이 떨어진 종목"을 고르는 기준 시점이 하필 일시적으로 눌린 매수 호가였다면, 그 다음 달의 반등처럼 보이는 수익은 전략의 힘이 아니라 그냥 가격이 제자리로 돌아온 것뿐이다.

월 단위 데이터로는 이 둘을 구분할 방법이 없었다. 확인하려면 하루 단위로 다시 계산해야 했다.

9년치 전 종목 일봉을 다시 모았다

데이터 수집

거래일 하루하루의 실제 가격이 필요했다. 코스피·코스닥 전 종목의 2018년부터 2026년까지 일봉 데이터, 총 2,334거래일을 KRX에서 하루씩 받았다.

문제는 안정성이었다. 2,300번이 넘는 요청을 한 번에 돌리면 중간에 세션이 끊긴다. 실제로 여러 번 끊겼다. 그래서 수집기를 이렇게 만들었다.

하루치를 받을 때마다 즉시 파일로 저장
시작할 때 이미 받은 날짜를 스캔해서 건너뜀
실패한 날짜는 별도 목록에 쌓아두고 마지막에 재시도

덕분에 중단돼도 다시 실행하면 끊긴 지점부터 이어졌다. 전체 수집에 며칠이 걸렸지만, 이 구조가 아니었으면 훨씬 더 걸렸을 것이다.

체결 조건을 현실적으로 바꿨다

이번 재검증에서 핵심적으로 바꾼 건 이 한 줄이다.

신호 계산은 월말 종가로, 체결은 반드시 다음 거래일 시가로.

실제로 거래한다면 월말 종가를 보고 그 자리에서 살 수는 없다. 종가가 확정되는 순간은 이미 장이 끝난 뒤다. 그러니 아무리 빨라도 다음 거래일 시가에나 살 수 있다. 이게 가장 현실적인 조건이었다.

그리고 이 한 줄의 차이가 두 전략의 운명을 갈랐다.

결과가 완전히 갈렸다

전략월간 근사치일봉 재검증

저PBR (대형주)	CAGR +13.2%, 샤프 0.63	CAGR +12.0%, 샤프 0.60
리버설 (소형주)	CAGR +12.4%, 샤프 0.48	CAGR -15.2%, 최대낙폭 -80.2%

저PBR은 살아남았다. 숫자가 살짝 줄었을 뿐 성격은 그대로였다. CAGR 1.2%p, 샤프 0.03 하락은 체결 시점을 하루 미룬 것에 대한 정상적인 비용으로 볼 수 있는 수준이다. 이 전략은 지금 실제로 페이퍼 트레이딩에 넣고 돌리고 있다.

리버설은 완전히 무너졌다. 세 구간 전부 플러스였던 성적이 통째로 사라졌고, 수익률은 플러스에서 마이너스로 부호가 뒤집혔다. 최대낙폭은 -44%에서 -80%로 뛰었다. 실제 돈이었다면 원금의 5분의 1만 남았다는 뜻이다.

의심했던 그대로였다. 수익의 정체는 호가 바운스 착시였다.

검증 자체가 틀린 건 아니었을까

여기서 한 번 더 의심해야 했다. 재검증 로직에 버그가 있어서 리버설만 억울하게 죽은 건 아닐까?

두 가지 근거로 아니라고 판단했다.

1. 같은 방법론에서 결과가 갈렸다

저PBR과 리버설에 완전히 동일한 코드를 적용했다. 데이터도 같고, 체결 규칙도 같고, 수수료·세금 가정도 같았다. 검증 방식 자체에 문제가 있었다면 둘 다 무너지거나 둘 다 버텼어야 한다. 한쪽만 통과하고 한쪽만 무너졌다는 건, 검증이 전략의 차이를 제대로 잡아냈다는 뜻이다.

2. 원인이 논리적으로 설명된다

대형주(저PBR): 거래가 활발하니 호가 간격이 좁다 → 월말 종가가 왜곡될 여지가 적다 → 영향 적음
소형주(리버설): 거래가 뜸하니 호가 간격이 넓다 → 월말 종가가 쉽게 눌린다 → 착시를 그대로 흡수

결과와 메커니즘이 서로 맞아떨어졌다. 우연히 나온 숫자가 아니라는 확인이었다.

최근에 다시 한번 들여다봤다

얼마 전에 이 리버설 전략을 다른 방식으로 다시 검토해볼 일이 있었다. AI 개발 도구 하나를 시험 삼아 써보면서 "이 죽은 전략을 되살릴 방법이 있을까"를 다시 물어본 거였다.

결론은 크게 다르지 않았다. 이미 근거를 갖고 내린 판단은 도구를 바꾼다고 쉽게 뒤집히지 않았다. 오히려 그게 안심이 됐다 — 판단의 근거가 도구가 아니라 데이터에 있었다는 뜻이니까. (이 과정 자체는 도구 사용기라 별도 글로 정리했다.)

이 실패에서 남은 규칙

월 단위 근사치는 계산이 빠르고 편하다. 전 종목 9년치를 월봉으로 돌리면 몇 초면 끝난다. 일봉으로 돌리면 데이터 수집에만 며칠, 백테스트에도 수십 배의 시간이 든다.

그래서 유혹이 생긴다. "월간으로도 충분히 좋아 보이는데 그냥 넘어갈까?"

그 유혹에 넘어갔다면 리버설을 실전에 넣었을 것이다. 그리고 -80% 낙폭을 실제로 겪었을 것이다.

이후로 세운 규칙은 이렇다.

신규 전략은 월간 근사치로 1차 스크리닝만 한다
후보로 인정하려면 일봉 + 익일 시가 체결 검증을 반드시 통과해야 한다
소형주·저유동성 종목을 다루는 전략은 이 검증을 더 엄격하게 본다
월간과 일봉의 결과 격차가 크면, 그 격차의 원인을 설명할 수 있어야 한다
설명이 안 되면 전략을 버린다

마지막 항목이 제일 중요했다. 숫자가 좋으면 이유를 못 찾아도 그냥 쓰고 싶어진다. 그 지점에서 멈추는 게 이 시스템의 안전장치다.

다음 편 예고

저PBR 전략은 최근 2년 동안 유독 성적이 좋았다. 그런데 우연히 이런 질문을 받았다.

"그거 혹시 정부 정책 특수 아니야?"

밸류업 정책이 저PBR 종목을 밀어올린 구간에 백테스트가 겹친 거 아니냐는 지적이었다. 타당한 의심이었고, 확인이 필요했다. 그런데 확인해보니 걱정한 것과는 완전히 다른 답이 나왔다.

이 글은 투자 권유가 아니며, 개인적인 AI·자동매매 시스템 개발 과정의 기록입니다. 백테스트 결과는 과거 데이터에 대한 시뮬레이션이며 미래 수익을 보장하지 않습니다.

office-hours가 죽은 전략도 살려낼까 — gstack 실전 사용기

makewithai — Thu, 23 Jul 2026 10:18:03 +0900

지난 편에서 예고한 대로, 이번엔 진짜로 설치해서 써봤다. 대상은 자동매매 프로젝트에서 이미 한 번 "탈락"으로 결론 낸 전략 하나 — 리버설 전략(최근 하락한 종목을 사는 전략)이다. 호가 바운스라는 데이터 착시 때문에 죽은 전략인데, 이걸 다시 살릴 방법이 있는지 gstack의 /office-hours로 검증해보기로 했다.

이 리버설 전략의 호가 바운스 착시 이야기는 자동매매 개발기 시리즈에서 별도로 자세히 다룬다.

설치부터 순탄치 않았다

bash

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack
./setup

PowerShell에서 그대로 실행했더니 cd 단계에서 바로 막혔다. 이유는 PowerShell이 ~를 git 같은 외부 프로그램에 넘길 때 자동으로 확장해주지 않는다는 것 — bash와 다른 점이다. 결과적으로 홈 디렉터리가 아니라 지금 작업하던 프로젝트 폴더 안에 ~라는 이름의 폴더가 생겨버렸다. Git Bash로 다시 하니 정상적으로 풀렸다.

./setup이 도는 규모도 예상보다 컸다. 브라우저 자동화용 실행파일, PDF 생성기, 디자인 도구까지 여러 개를 컴파일하고 Node 서버까지 번들링했다. 참고로 gstack 전체 스킬 문서를 다 합치면 66,534줄, 약 89만 토큰이다. office-hours 스킬 파일 하나만 1,698줄인데, 실제 "질문 로직"은 872번째 줄부터 시작한다. 그 앞은 텔레메트리 설정, 세션 동기화, 프로젝트별 학습 데이터 관리 같은 인프라다.

여기서 하나 짚고 넘어갈 게 있다. 이 인프라 중 일부는 사용자 확인 없이 CLAUDE.md에 라우팅 규칙을 자동으로 추가하고 git commit까지 하려고 든다. 이건 그냥 넘기지 않고, 이번 실험에서는 의도적으로 건너뛰었다.

첫 질문부터 삐걱거렸다

/office-hours를 직접 명령어로 칠 수는 없었다. gstack은 "라우터" 구조라서, gstack 스킬이 요청을 분석해서 적절한 서브 스킬로 연결해주는 방식이었다.

라우팅되고 나서 처음 받은 질문은 이거였다.

Before we dig in — what's your goal with this? Building a startup / Open source·research / Learning / Having fun

선택지 중에 "이 트레이딩 전략이 통계적으로 타당한지 검증하고 싶다"에 맞는 항목이 없었다. 제일 가까운 "Learning"을 골랐더니 Builder Mode로 연결됐다. 이어지는 질문들은 이랬다.

가장 쿨한 버전은 뭔가요?
누구에게 보여줄 건가요?
가장 빨리 쓰거나 공유할 방법은 뭔가요?

세 번째 질문에서 막혔다. "공유할 것"이 아니라 "검증 결과"가 목적이었으니까. 이 질문에는 정직하게 "잘 모르겠음"으로 답했다.

그런데 여기서 반전이 나왔다

office-hours의 첫 단계 지시사항에는 이렇게 적혀 있었다. "작업을 시작하기 전에 프로젝트의 CLAUDE.md를 먼저 읽어라."

자동매매 프로젝트의 CLAUDE.md에는 정확히 이런 문장이 있다.

STRATEGY.md — 자동매매 전략 연구의 단일 원본(SSOT). 새 전략 논의 전 반드시 읽을 것.

리버설 전략이 왜 탈락했는지, 그 판단 근거가 전부 STRATEGY.md에 기록돼 있다. 즉 office-hours의 워크플로우 설계 자체는 이 과거 판단을 찾아내도록 이미 짜여 있었다.

그런데 실제로 그 역할을 수행하던 나(Claude)조차, 첫 단계의 "먼저 읽어라"를 건너뛰고 곧바로 흥미로운 질문 단계로 직행해버렸다. 지시사항이 명확히 있었는데도, 재밌는 대화형 파트가 지루한 사전 조사를 밀어낸 셈이다.

결론: 이미 답이 정해진 프로젝트엔 안 맞는다

정리하면 이렇다.

office-hours는 "이 아이디어로 뭔가 만들 가치가 있는가"를 검증하는 도구다. 질문 설계 전체가 아직 아무것도 결정되지 않은 상태를 전제로 한다. 그런데 내 상황은 반대였다 — 이미 엄격한 백테스트로 결론을 낸, 성숙한 프로젝트 안에서 "이 결론을 뒤집을 수 있나"를 묻고 있었다. 질문의 결이 처음부터 안 맞을 수밖에 없었다.

다만 이게 도구의 실패라고만 보긴 어렵다. 설계는 맞았는데(CLAUDE.md를 먼저 읽으라는 지시), 실행에서 그걸 건너뛴 건 나였다. 좋은 프로세스도 누가·무엇이 강제하지 않으면 쉽게 생략된다는 게, 어쩌면 이 실험에서 가장 값진 발견일 수도 있다.

다음 편 예고 — 진짜 새 프로젝트에 써보면 어떨까

이번 실험으로 확실해진 게 하나 있다. office-hours를 제대로 시험하려면 이미 답이 있는 프로젝트가 아니라, 정말 아무것도 정해지지 않은 새 프로젝트가 필요하다. 그래야 이 도구가 원래 설계된 자리에서 어떻게 작동하는지 볼 수 있다.

그래서 이번 실험은 여기서 일단락한다. 다음은 진짜 그린필드 프로젝트를 하나 잡아서, 처음부터 office-hours로 시작해보려고 한다. 그때 다시 이어서 쓴다.

이 글은 개발 도구에 대한 개인적인 사용 후기이며, 언급된 트레이딩 전략은 예시일 뿐 투자 권유가 아닙니다.

직감이 세 번 연속 틀린 이야기 — 자동매매 필터·손절 백테스트 실패기

makewithai — Wed, 22 Jul 2026 17:13:27 +0900

이제 안전장치를 붙여볼 차례였다

40종목 기준 백테스트로 다시 보니, 순수 전략은 그냥 사서 보유하기를 못 이겼다. 그럼 여기에 "안전장치"를 몇 개 붙이면 나아지지 않을까 싶었다. 상식적으로 생각하면 다 맞는 소리였다. 하락장이 예상되면 매수를 막고, 손실이 커지면 손절하고, 기관 자금이 잘 안 들어가는 중소형주를 노리면 더 유리할 거라고.

세 개 다 시도했다. 세 개 다 틀렸다.

첫 번째: "하락 예상되면 매수 금지"

주가가 200일 이동평균선 아래에 있으면 신규 매수를 하지 않는 필터를 넣었다. 하락 추세에서는 사지 않겠다는, 지극히 상식적인 규칙이었다.

평균 수익률평균 최대낙폭수익 종목 비율

기본 전략	+83.4%	-50.7%	57%
+ 하락장 필터	+54.1%	-43.2%	60%

최대낙폭은 확실히 줄었다(-50.7% → -43.2%). 그런데 수익률이 그보다 더 크게 깎였다(+83.4% → +54.1%). 위험은 조금 줄었는데 수익은 훨씬 많이 잃은 셈이다. 밑지는 장사였다.

두 번째: "손실이 커지면 판다"

고점 대비 일정 비율 이상 떨어지면 자동으로 손절하는 규칙을 추가했다. 리스크 관리의 기본 중의 기본이라고 생각했다.

결과는 더 나빴다. 하락장 필터에 손절까지 더하자 수익률이 절반 넘게 깎였다. 왜 이런 일이 벌어지는지 찾아보니, 원인은 한국 시장의 특징에 있었다. 코로나 폭락 때를 생각해보면, 3주 만에 -35%가 났다가 그 뒤로 V자 반등이 나왔다. 손절 규칙은 정확히 바닥 근처에서 팔고 나가게 만들었고, 그 직후에 오는 반등은 고스란히 놓쳤다. "빠지면 판다"가 이 시장에서는 "제일 안 좋은 타이밍에 팔고, 회복은 못 먹는다"로 작동했다.

세 번째: "중소형주가 더 유리할 것"

여기서는 가설이 좀 더 그럴듯했다. 대형주는 이미 기관과 외국인 자금이 다 들어가 있어서 남은 기회가 적을 거고, 중소형주는 상대적으로 덜 알려져서 추세를 따라가는 전략(모멘텀)이 더 잘 먹힐 거라고 생각했다. 실제로 이런 논리를 펴는 투자서도 많이 봤다.

시가총액 구간별로 나눠서 최근 6개월 많이 오른 종목을 사는 전략을 테스트했다.

시가총액 구간모멘텀 전략 CAGR최대낙폭

대형주 (1~50위)	+10.6%	-46.5%
중형주 (51~200위)	-3.5%	-57.3%
소형주 (201~500위)	-17.2%	-88.5%

소형주로 갈수록 나아지긴커녕 재앙에 가까워졌다. 최대낙폭 -88.5%는 1억을 넣었으면 1,200만 원만 남는다는 뜻이다. 이유를 뜯어보니, 소형주의 "최근 6개월 급등 종목"은 대부분 테마성 단기 급등이었다. 그런 종목을 계속 사들이는 전략은 매번 상투를 잡는 꼴이 됐다. 게다가 소형주라고 딱히 저평가돼 있지도 않았다 — 그냥 사서 보유하는 것조차 대형주보다 성적이 나빴다.

세 번 다 실패한 이유를 다시 보니

세 시도의 공통점을 짚어보면 전부 "안전장치를 추가했다"는 점이었다. 그런데 안전장치가 작동하려면 그게 필요한 순간을 정확히 짚어내야 하는데, 한국 시장은 급락과 급반등이 짧은 시간에 같이 오는 경우가 많았다. 안전장치는 위험을 피하게 해주는 대신, 회복까지 같이 피하게 만들었다.

직감으로는 셋 다 "당연히 도움될 것"처럼 보였다. 그런데 상식이 통하는 시장과 이 시장의 실제 움직임이 달랐다. 백테스트로 확인하지 않았다면, 지금도 이 세 가지를 다 넣은 채로 운영하고 있었을 거다.

다음 편 예고

그래도 하나는 제대로 먹히는 걸 찾았다. 하락장에서 오히려 수익을 낸 전략이었다. 그런데 이것도 다시 의심해봐야 했다. 자세히 들여다보니 진짜 수익이 아니라 데이터 착시일 수도 있다는 신호가 보였다 — 다음 편에서 그 착시를 어떻게 잡아냈는지 이어간다.

이 글은 투자 권유가 아니며, 개인적인 AI·자동매매 시스템 개발 과정의 기록입니다.

5종목으로는 속았다 — 백테스트 생존편향에 속은 이야기

makewithai — Wed, 22 Jul 2026 14:51:15 +0900

첫 백테스트, 숫자가 꽤 그럴듯했다

원칙을 세웠으니 이제 백테스트로 확인할 차례였다. 판단을 전부 코드로 짰으면, 그 코드가 진짜 돈을 버는지 봐야 한다. 익숙한 대형주 5개 — 삼성전자, SK하이닉스, NAVER, 현대차, 카카오 — 로 8년치 데이터를 돌렸다.

결과는 나쁘지 않아 보였다. 5종목 평균 수익률 +336.8%. 특히 카카오는 전략이 +376.4%를 냈는데, 그냥 사서 들고 있었으면 +74.4%에 그쳤을 거였다. 다섯 배 차이. "이 전략, 폭락장에서 방어력이 있구나" 싶었다.

그런데 자세히 보니 이상한 게 있었다

같은 표 안에 불편한 숫자도 있었다. SK하이닉스를 그냥 사서 들고 있었다면 +2,919%였다. 전략은 +589.6%. 무려 2,300%포인트 차이로 전략이 졌다. NAVER는 더 심했다 — 보유는 +64.9%인데 전략은 -39.0%, 마이너스였다.

5종목 평균을 내면 +336.8%로 그럴듯해 보이지만, 그 안을 뜯어보면 "크게 이긴 종목 하나(카카오)"와 "크게 진 종목 둘(SK하이닉스, NAVER)"이 섞여 있었을 뿐이었다. 평균이라는 숫자 하나에 가려져 있었다.

5개로 결론 내리는 게 맞나 — 생존편향 문제

멈춰서 생각해봤다. 삼성전자, SK하이닉스, NAVER, 현대차, 카카오 — 이 다섯은 전부 "지금 봐도 여전히 잘나가는" 종목이다. 2018년에 이 다섯 개를 미리 알고 골랐다면, 사실 어떤 전략을 썼어도 크게 손해 보기 어려웠을 거다. 이게 바로 생존 편향이다. 지금 살아남아서 유명한 종목들로만 테스트하면, 무슨 전략이든 그럴듯해 보인다.

그래서 기준을 다시 잡았다. 2018년 1월 시점의 시가총액 상위 40개 종목으로 유니버스를 고정했다. 지금 좋은 종목이 아니라, "그때 시점에 컸던" 종목들이다. 이 안에는 이후 반토막 난 종목도, 상장폐지 위기를 겪은 종목도 그대로 들어간다. 미래를 모르는 채로 그 시점에 실제로 골랐을 법한 40개였다.

40개로 늘리자 완전히 다른 그림이 나왔다

같은 전략, 같은 기간, 종목 수만 5개에서 40개로 늘려서 다시 돌렸다.

구간전략그냥 보유

전체 (2018~2026)	+83.4%	+167.9%
상승장 (2018~2020)	+6.9%	+16.1%
하락횡보장 (2021~2023)	-10.8%	-8.0%
최근 (2024~2026)	+70.3%	+125.4%

네 구간 전부 그냥 사서 보유하는 쪽이 이겼다. 심지어 방어력이 있다고 믿었던 하락장에서도, 전략이 오히려 보유보다 더 많이 잃었다(-10.8% vs -8.0%). 40개 종목 중 전략이 보유를 이긴 건 40%뿐이었다.

카카오에서 봤던 "다섯 배 방어" 이야기는 어디로 갔나. 그건 그냥 카카오라는 종목 하나가 만든 착시였다. 40개로 늘리자 그 효과는 평균 속으로 사라졌다.

운이 좋았던 거였다

5종목 백테스트 결과를 처음 봤을 때 들었던 "방어력이 있다"는 생각은, 데이터가 아니라 표본이 작아서 생긴 착각이었다. 다섯 개 중 하나가 우연히 잘 맞았을 뿐인데, 그걸 전략의 실력이라고 착각했던 거다.

이 실패가 알려준 건 명확했다. 검증은 익숙하고 편한 종목 몇 개로 하면 안 된다는 것. 그리고 "그때 그 시점에 몰랐을 것"을 아는 척하면서 유니버스를 고르면 안 된다는 것. 이후 모든 백테스트는 이 원칙 위에서 다시 짰다.

다음 편 예고

40종목 기준을 잡고 나니 이제 제대로 실험할 준비가 됐다. 그런데 문제는 여기서부터였다. "이건 당연히 도움될 것"이라고 생각했던 안전장치들을 하나씩 넣어봤는데, 세 번 연속으로 직감이 틀렸다. 하락 예상되면 매수를 막는 필터도, 손절 규칙도 — 다음 편에서 이어간다.

이 글은 투자 권유가 아니며, 개인적인 AI·자동매매 시스템 개발 과정의 기록입니다.

PM 혼자 바이브코딩할 때 gstack에서 먼저 써볼 8개

makewithai — Wed, 22 Jul 2026 14:30:29 +0900

지난 편에서 게리 탄(Garry Tan)이 공개한 Claude Code 툴킷 gstack의 전체 구조를 살펴봤다. 23개 전문 스킬과 8개 파워툴, 총 30개가 넘는 구성이다. 이걸 한 번에 다 익히려 들면 오히려 시작도 못 하고 지친다.

PM 출신으로 혼자 바이브코딩하는 입장에서, 실제로 먼저 손대볼 만한 8개만 추렸다.

우선순위 8개

순위스킬하는 일왜 먼저인가

1	office-hours	아이디어를 코드 짜기 전에 검증	요구사항 명확화는 PM에게 익숙한 작업과 겹친다
2	spec	막연한 의도를 5단계 실행 스펙으로 변환	"이거 만들어줘"의 모호함을 줄여준다
3	plan-eng-review	엔지니어링 매니저 관점 계획 리뷰	개발 지식이 부족한 부분을 AI가 대신 검토해준다
4	review	PR 랜딩 전 최종 코드 리뷰	혼자 개발할 때 놓치는 버그를 잡아준다
5	qa	웹앱 QA + 버그 직접 수정까지	배포 전 필수, 헤드리스 브라우저로 실사용을 흉내 낸다
6	ship	배포 원스톱 워크플로우	자동화 수익화 방향과 직결된다
7	context-save / context-restore	작업 컨텍스트 저장/복원	세션이 끊겨도 이어서 작업할 수 있다
8	retro	주간 엔지니어링 회고	PM 습관(회고)과 자연스럽게 연결된다

이 8개만 익혀도 기획 → 검증 → 개발 → QA → 배포의 최소 사이클이 완성된다.

왜 이 순서인가

office-hours와 spec을 가장 앞에 둔 이유는 단순하다. 바이브코딩에서 가장 많은 시간을 잡아먹는 건 코드 자체가 아니라 "내가 지금 뭘 만들려는 건지"가 흐릿한 상태에서 일단 프롬프트부터 던지는 습관이다. PM으로 일하면서 요구사항을 명확히 하는 훈련은 이미 되어 있으니, 이 두 스킬은 낯선 도구가 아니라 익숙한 작업을 AI에게 위임하는 느낌에 가깝다.

plan-eng-review와 review는 반대로 PM에게 약한 지점을 메워주는 용도다. 아키텍처 판단이나 코드 품질은 혼자 개발할 때 가장 놓치기 쉬운 부분인데, 이걸 엔지니어링 매니저 페르소나가 대신 검토해주는 구조다.

qa와 ship은 배포까지 가는 마지막 관문이다. 특히 ship은 브랜치 머지부터 버전업, CHANGELOG, PR까지 한 번에 처리해주기 때문에, 자동화 수익화를 목표로 한다면 이 스킬 하나로 배포 사이클 자체를 자동화하는 셈이 된다.

context-save/context-restore와 retro는 우선순위상 뒤에 있지만 실제 체감 효용은 크다. 세션이 끊겨서 맥락을 처음부터 다시 설명해야 하는 상황, 바이브코딩 해본 사람이라면 한 번쯤 겪었을 것이다. 그리고 주간 회고는 PM 업무에서 익숙한 루틴이라, 이 스킬은 그냥 그 습관을 개발 프로젝트에 옮겨오는 것뿐이다.

실제로 어떻게 쓰고, 뭐가 나오나

이론만으로는 감이 안 잡히니, 공식 문서 기준으로 대표적인 4개 스킬이 실제로 어떻게 동작하는지 정리했다.

/office-hours — 아이디어 검증

Claude Code에서 /office-hours라고 치거나, "이 아이디어 괜찮을까?" 같은 말을 하면 자동으로 실행된다. 두 가지 모드가 있다.

스타트업 모드: "수요가 진짜 있나, 지금은 어떻게 해결하고 있나, 구체적으로 누가 필요로 하나, 가장 좁게 시작할 수 있는 지점이 어디인가" 같은 6개의 압박 질문을 던진다. "헬스케어 기업들이 필요로 함" 같은 막연한 답은 계속 되돌려 받는다. 이름, 직무, 회사, 이유가 구체적으로 나올 때까지.
빌더 모드: 사이드 프로젝트나 해커톤용으로, 브레인스토밍 파트너에 가깝게 진행된다.

대화가 끝나면 ~/.gstack/projects/ 경로에 디자인 문서가 자동 저장되고, 이 문서가 다음 단계인 /plan-eng-review로 그대로 이어진다.

/spec — 막연한 아이디어를 실행 스펙으로

"이거 스펙으로 정리해줘", "GitHub 이슈로 만들어줘" 같은 말을 하면 자동 실행된다. 5단계(왜 하는지 → 범위 → 기술적 검토(코드 직접 읽기 필수) → 초안 → 파일링)를 거치는데, 특이한 건 품질 게이트가 있다는 점이다. 자체 점수가 7/10 미만이면 파일링을 막는다. 비밀키(API key 등)가 실수로 포함되지 않도록 자동 검열도 들어간다.

결과물로 GitHub 이슈가 생성되고, 기존 이슈와 중복되는지도 자동으로 체크해준다.

/review → /ship — 리뷰부터 배포까지

PR 머지 직전에 "리뷰해줘" 하면 /review가 코드 diff를 분석해서 문제점을 짚어주는 리뷰 코멘트를 생성한다. 여기서 문제없으면 바로 "배포해줘" 또는 /ship으로 넘어가는데, 이 한 번의 명령으로 브랜치 머지 → 테스트 실행 → 버전 업 → CHANGELOG 작성 → PR 생성까지 전부 처리된다. 사람이 클릭할 일이 거의 없다.

대표적인 전체 흐름

공식 문서에서 제시하는 대표적인 첫 루프는 이렇다.

/office-hours (또는 /spec) → 아이디어를 디자인 문서로 정리
     ↓
/plan-eng-review → 아키텍처 확정
     ↓
/ship → 배포까지 완료

이 세 개만 이어 붙여도 아이디어에서 배포까지 한 세션 안에서 끝나는 구조다. 공식 문서에서도 gstack은 이 루프 하나를 완주할 때 진가를 발휘한다고 강조한다.

한 가지 재밌는 점은, /로 직접 명령어를 치지 않아도 말하는 내용에 따라 gstack이 알아서 적절한 스킬을 골라 실행해준다는 것이다. "이거 좀 브레인스토밍 해볼까"라고 하면 자동으로 /office-hours가, "버그 있는 거 같은데"라고 하면 자동으로 /investigate가 실행되는 식이다.

자동화 수익화 관점에서 눈여겨볼 것

바이브코딩으로 자동화 수익화를 노리는 방향이라면 이렇게 조합해볼 수 있다.

spec → plan-eng-review → qa → ship, 이 4개만으로도 최소 사이클이 완성된다. 아이디어를 스펙으로 만들고, 검토받고, 테스트하고, 배포까지 — 사람이 개입하는 지점을 최소화하는 흐름이다.
scrape + skillify 조합은 반복 작업 흐름을 아예 재사용 스킬로 저장해두는 구조다. n8n 같은 자동화 툴과 결이 비슷해서, 자동화 파이프라인을 만들 때 참고할 만하다.
iOS 전용 스킬 5개는 네이티브 앱을 안 만들면 통째로 무시해도 된다. 전체 스킬 수가 많아 보여도 이쪽에 몰려있는 비중이 커서, 체감 개수는 실제로 더 적다.

시작하는 법

1편에서 다룬 설치 명령어로 gstack을 먼저 설치한다.

bash

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

그다음 위 8개 순서대로 하나씩 실제 프로젝트에 적용해보는 걸 추천한다. autoplan이나 design-shotgun 같은 무거운 스킬은 러닝커브가 있으니, 이 8개를 1~2주 정도 써보고 익숙해진 다음 확장하는 편이 낫다.

이전 편: [gstack이 뭐길래 난리인가 — 게리 탄이 공개한 Claude Code 툴킷 뜯어보기]

gstack이 뭐길래 난리인가 — 게리 탄이 공개한 Claude Code 툴킷 뜯어보기

makewithai — Wed, 22 Jul 2026 09:53:20 +0900

이게 뭔데 화제였나

Y Combinator CEO인 게리 탄(Garry Tan)이 자신이 실제로 쓰던 Claude Code 설정을 통째로 공개했다. 이름은 gstack. 공식 저장소 설명을 보면, CEO·디자이너·엔지니어링 매니저·릴리스 매니저·문서 엔지니어·QA — 이렇게 여섯 개 역할을 대신해주는 23개의 "opinionated"(자기 주장이 뚜렷한) 도구 모음이라고 되어 있다.

공개 직후 짧은 기간에 GitHub 스타 수만 개를 넘기며 화제가 됐고, 지금도 활발히 업데이트되고 있다. 최신 버전은 v1.57.6.0이고, 최근 릴리스에서는 세션이 끊겨도 이전 결정을 기억하는 크로스 세션 메모리 기능과, 보안 가드 중 뚫려 있던(failing open) 4개를 막는 수정이 들어갔다.

구성은 23개 전문 스킬 + 8개 파워툴이다. 참고로 "51개"라는 숫자로 소개된 자료도 종종 보이는데, 이건 세부 하위 명령어까지 다 센 숫자로 추정된다. 실제 공식 저장소 기준으로는 23+8 구성이 맞다.

왜 필요한가 — Claude Code 기본 모드와 뭐가 다른가

Claude Code를 그냥 쓰면 대부분 빈 CLAUDE.md에서 시작해서, 리뷰 방식도 QA 방식도 배포 체크리스트도 전부 각자 만들어 써야 한다. gstack은 이 앞뒤 과정(기획 → 리뷰 → QA → 배포)에 이미 만들어진 역할극 페르소나를 끼워 넣는 방식이다.

즉 코드를 직접 짜는 도구가 아니라, "무엇을 왜 할까"를 강제하는 거버넌스 레이어에 가깝다. Build 단계 자체는 Claude Code 기본 기능에 맡기고, gstack은 그 전후 과정을 채운다.

안전장치도 있다. "be careful"이라고 말하면 /careful이 rm -rf, DROP TABLE, force-push, git reset --hard 같은 파괴적 명령 앞에서 경고를 띄우고, /freeze는 디버깅 중 편집 범위를 한 디렉토리로 묶어 Claude가 엉뚱한 코드를 건드리지 못하게 막는다.

전체 스킬 맵 (단계별)

1. 기획 · 검증

office-hours — 아이디어 사전 검증. YC 파트너 세션처럼 코드 짜기 전에 질문을 던져 검증해준다.
spec — 막연한 의도를 5단계로 정밀한 실행 스펙으로 변환.
plan-tune — 질문 민감도·개발자 성향을 관찰해서 자가 튜닝.

2. 계획 리뷰 (역할별 검토)

plan-ceo-review — 창업자 관점 리뷰
plan-design-review — 디자이너 관점 리뷰
plan-devex-review — 개발자 경험(DX) 관점 리뷰
plan-eng-review — 엔지니어링 매니저 관점 리뷰
autoplan — 위 4개를 자동으로 순차 실행

3. 디자인

design-consultation — 톤·타이포·컬러·레이아웃 제안
design-html — 프로덕션 품질 HTML/CSS 생성
design-review — 시각적 불일치·간격·위계 문제 발견 및 수정
design-shotgun — 여러 시안 생성 → 비교 보드 → 피드백 수집

4. 개발 · 디버깅

investigate — 근본 원인 추적 디버깅
health — 코드 품질 대시보드
devex-review — 실시간 개발자 경험 감사
careful, guard, freeze/unfreeze — 안전장치

5. QA · 테스트

qa — 웹앱 QA + 버그 수정까지
qa-only — 리포트만 생성
browse — QA용 헤드리스 브라우저
benchmark, benchmark-models — 성능 회귀 감지, 모델 간 벤치마크
canary — 배포 후 모니터링
iOS 전용 5종 (ios-qa, ios-fix, ios-clean, ios-sync, ios-design-review)

6. 배포 · 운영

ship — 브랜치 머지 → 테스트 → 버전업 → CHANGELOG → PR까지 원스톱
land-and-deploy, setup-deploy, landing-report, document-release

7. 문서 · 산출물

document-generate — 기능/모듈/프로젝트 문서 자동 생성
make-pdf — 마크다운 → 출판 품질 PDF
diagram — 텍스트/mermaid → 다이어그램

8. 세션 · 컨텍스트 관리

context-save / context-restore — 작업 컨텍스트 저장/복원
learn — 프로젝트 학습 내용 관리
retro — 주간 회고

9. 브라우저 자동화

scrape, skillify, pair-agent, setup-browser-cookies, open-gstack-browser

10. 시스템 · 보안 · 유틸리티

cso — 보안 담당자 모드
setup-gbrain, sync-gbrain — 장기 기억(gbrain) 설정/동기화, 최근 업데이트로 dream-stage 캐싱 추가
gstack-upgrade, codex

설치 방법

bash

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

MIT 라이선스, 무료로 공개되어 있다. 시스템 PATH를 건드리지 않고 .claude/ 디렉토리 안에서만 동작한다.

참고 및 주의

오픈소스 프로젝트 특성상 버전이 빠르게 바뀐다. 이 글은 v1.57.6.0 기준으로 작성했으며, 최신 스펙은 공식 저장소에서 다시 확인하는 걸 권한다.

전체 30개가 넘는 스킬을 한 번에 다 익히는 건 비효율적이다. 다음 편에서는 PM이 혼자 바이브코딩할 때 어떤 것부터 써야 하는지, 우선순위를 추려서 정리한다.

다음 편: PM 혼자 바이브코딩할 때 gstack에서 먼저 써볼 8개