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

지난 편에서 예고한 대로, 이번엔 진짜로 설치해서 써봤다. 대상은 자동매매 프로젝트에서 이미 한 번 "탈락"으로 결론 낸 전략 하나 — 리버설 전략(최근 하락한 종목을 사는 전략)이다. 호가 바운스라는 데이터 착시 때문에 죽은 전략인데, 이걸 다시 살릴 방법이 있는지 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로 시작해보려고 한다. 그때 다시 이어서 쓴다.

---

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