Spike
사용자가 실제 빌드를 시작하기 전에 아이디어를 미리 느껴보고, 타당성을 검증하거나, 접근 방식을 비교하거나, 아무리 조사해도 알 수 없는 미지의 영역을 표면화하려 할 때 이 스킬을 사용하세요. 스파이크는 설계상 폐기 가능합니다. 임무를 다하면 버리세요.
사용자가 "한번 해볼게", "X가 되는지 볼까", "스파이크 돌려봐", "Y를 시작하기 전에", "Z를 빠르게 프로토타입", "이게 가능한가?", "A vs B 비교해줘" 같은 말을 할 때 로드하세요.
사용하지 말아야 할 경우
- 문서나 코드를 읽으면 답을 알 수 있는 경우 — 그냥 조사하고 빌드하지 마세요
- 작업이 프로덕션 경로인 경우 —
plan스킬을 사용하세요 - 아이디어가 이미 검증된 경우 — 바로 구현 단계로 넘어가세요
전체 GSD 시스템이 설치된 경우
gsd-spike가 ( npx get-shit-done-cc --hermes 를 통해 설치된) 형제 스킬로 나타나면, 사용자가 전체 GSD 워크플로우(영구적인 .planning/spikes/ 상태, 세션 간 MANIFEST 추적, Given/When/Then 판정 형식, GSD의 나머지 부분과 통합되는 커밋 패턴)를 원할 때 gsd-spike 를 선호하세요. 이 스킬은 전체 시스템이 없거나 원하지 않는 사용자를 위한 경량 독립형 버전입니다.
핵심 방법
규모에 관계없이 모든 스파이크는 다음 루프를 따릅니다:
분해 → 연구 → 구축 → 판정
↑__________________________________________↓
발견 사항 반복
1. 분해
사용자의 아이디어를 2-5개의 독립적인 타당성 질문으로 나누세요. 각 질문이 하나의 스파이크입니다. Given/When/Then 프레임워크로 표로 제시하세요:
| # | 스파이크 | 검증 내용 (Given/When/Then) | 위험도 |
|---|---|---|---|
| 001 | websocket-streaming | 웹소켓 연결이 주어졌을 때, LLM이 토큰을 스트리밍하면 클라이언트가 100ms 미만의 청크를 수신하는가 | 높음 |
| 002a | pdf-parse-pdfjs | 여러 페이지 PDF가 주어졌을 때, pdfjs로 파싱하면 구조화된 텍스트를 추출할 수 있는가 | 중간 |
| 002b | pdf-parse-camelot | 여러 페이지 PDF가 주어졌을 때, camelot으로 파싱하면 구조화된 텍스트를 추출할 수 있는가 | 중간 |
스파이크 유형:
- 표준 — 하나의 질문에 하나의 접근 방식
- 비교 — 같은 질문, 다른 접근 방식 (동일한 번호, 문자 접미사
a/b/c)
좋은 스파이크 질문: 관찰 가능한 출력을 동반한 구체적인 타당성. 나쁜 스파이크 질문: 너무 광범위하거나, 관찰 가능한 출력이 없거나, 단순히 "X에 대한 문서 읽기"인 경우.
위험도 순으로 정렬하세요. 아이디어를 무산시킬 가능성이 가장 높은 스파이크를 먼저 실행하세요. 어려운 부분이 작동하지 않는다면 쉬운 부분을 프로토타입하는 것은 의미가 없습니다.
분해를 건너뛸 때는 사용자가 이미 무엇을 스파이크할지 정확히 알고 있고 그렇게 말하는 경우뿐입니다. 그러면 사용자의 아이디어를 하나의 스파이크로 받아들이세요.
2. 조정 (여러 스파이크 아이디어의 경우)
스파이크 표를 제시하세요. "이 순서대로 모두 구축할까요, 아니면 조정할까요?"라고 물으세요. 코드를 작성하기 전에 사용자가 스파이크를 삭제하거나, 순서를 바꾸거나, 다시 구성할 수 있게 하세요.
3. 연구 (스파이크별, 구축 전)
스파이크는 연구가 필요 없음을 의미하지 않습니다 — 올바른 접근 방식을 선택할 수 있을 만큼 연구한 다음 구축하세요. 스파이크별로:
-
요약. 2-3문장: 이 스파이크는 무엇인지, 왜 중요한지, 주요 위험.
-
경쟁 접근 방식 표면화 실제 선택지가 있는 경우:
접근 방식 도구/라이브러리 장점 단점 상태 ... ... ... ... 유지 관리 중 / 중단됨 / 베타 -
하나를 선택하세요. 이유를 명시하세요. 2개 이상이 신뢰할 수 있다면 스파이크 내에서 빠른 변형을 구축하세요.
-
외부 종속성이 없는 순수 로직의 경우 연구를 건너뛰세요.
연구 단계에 Hermes 도구를 사용하세요:
web_search("python websocket streaming libraries 2025")— 후보 찾기web_extract(urls=["https://websockets.readthedocs.io/..."])— 실제 문서 읽기 (마크다운 반환)terminal("pip show websockets | grep Version")— 프로젝트 가상 환경에 설치된 버전 확인
문서 페이지가 없는 라이브러리의 경우 read_file을 통해 README.md / examples/ 를 클론하고 읽으세요. Context7 MCP (사용자가 구성한 경우)도 좋은 소스입니다 — mcp_*_resolve-library-id 그런 다음 mcp_*_query-docs.
4. 구축
스파이크당 하나의 디렉터리로 유지하세요. 독립적으로 유지하세요.
spikes/
├── 001-websocket-streaming/
│ ├── README.md
│ └── main.py
├── 002a-pdf-parse-pdfjs/
│ ├── README.md
│ └── parse.js
└── 002b-pdf-parse-camelot/
├── README.md
└── parse.py
사용자가 상호작용할 수 있는 것을 만드는 데 치우치세요. 유일한 출력이 "작동합니다"라고 말하는 로그 한 줄인 스파이크는 실패입니다. 사용자는 스파이크가 작동하는 것을 느끼고 싶어합니다. 선호도 순서대로 기본 선택:
- 입력을 받고 관찰 가능한 출력을 표시하는 실행 가능한 CLI
- 동작을 시연하는 최소 HTML 페이지
- 하나의 엔드포인트가 있는 작은 웹 서버
- 인식 가능한 어설션으로 질문을 실행하는 단위 테스트
속도보다 깊이. 한 번의 해피 패스 실행 후 "작동합니다"라고 선언하지 마세요. 엣지 케이스를 테스트하세요. 놀라운 발견을 추적하세요. 조사가 정직했을 때만 판정을 신뢰할 수 있습니다.
스파이크가 특별히 요구하지 않는 한 피하세요: 복잡한 패키지 관리, 빌드 도구/번들러, Docker, env 파일, 구성 시스템. 모든 것을 하드코딩하세요 — 스파이크니까요.
하나의 스파이크 구축 — 일반적인 도구 시퀀스:
terminal("mkdir -p spikes/001-websocket-streaming")
write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
write_file("spikes/001-websocket-streaming/main.py", "...")
terminal("cd spikes/001-websocket-streaming && python3 main.py")
# 출력 관찰, 반복.
병렬 비교 스파이크 (002a / 002b) — 위임. 두 접근 방식을 병렬로 실행할 수 있고 둘 다 실제 엔지니어링이 필요한 경우 (10줄짜리 프로토타입이 아닌 경우) delegate_task로 분기하세요:
delegate_task(tasks=[
{"goal": "Build 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
{"goal": "Build 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])
각 하위 에이전트는 자체 판정을 반환합니다. 당신이 맞대결을 작성합니다.
5. 판정
각 스파이크의 README.md 는 다음으로 마무리됩니다:
## 판정: VALIDATED | PARTIAL | INVALIDATED
### 작동한 것
- ...
### 작동하지 않은 것
- ...
### 놀라운 점
- ...
### 실제 빌드를 위한 권장 사항
- ...
VALIDATED = 핵심 질문에 '예'라고 답했으며 증거가 있음. PARTIAL = X, Y, Z 제약 조건 하에서 작동함 — 이를 문서화하세요. INVALIDATED = 작동하지 않음, 이유는 다음과 같음. 이것은 성공적인 스파이크입니다.
비교 스파이크
두 접근 방식이 동일한 질문에 답하는 경우 (002a / 002b), 연속해서 구축한 다음 마지막에 맞대결 비교를 수행하세요:
## 맞대결: pdfjs vs camelot
| 차원 | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| 추출 품질 | 9/10 구조화됨 | 7/10 테이블 전용 |
| 설정 복잡성 | npm install, 1 줄 | pip + ghostscript |
| 100페이지 PDF 성능 | 3초 | 18초 |
| 회전된 텍스트 처리 | 아니오 | 예 |
**승자:** 우리 사용 사례에서는 pdfjs. 나중에 테이블 우선 추출이 필요하면 camelot.
프론티어 모드 (다음 스파이크 선택)
스파이크가 이미 존재하고 사용자가 "다음에 무엇을 스파이크해야 할까요?"라고 묻는다면, 기존 디렉터리를 살펴보고 다음을 찾으세요:
- 통합 위험 — 동일한 리소스를 건드리지만 독립적으로 테스트된 두 개의 검증된 스파이크
- 데이터 핸드오프 — 스파이크 A의 출력이 스파이크 B의 입력과 호환된다고 가정했지만 입증되지 않음
- 비전의 격차 — 가정되었지만 입증되지 않은 기능
- 대안적 접근 방식 — PARTIAL 또는 INVALIDATED 스파이크에 대한 다른 각도
Given/When/Then으로 2-4개의 후보를 제안하세요. 사용자가 선택하게 하세요.
출력
spikes/(또는 사용자가 GSD 규칙을 사용하는 경우.planning/spikes/)를 리포지토리 루트에 생성- 스파이크당 하나의 디렉터리:
NNN-descriptive-name/ - 스파이크당
README.md는 질문, 접근 방식, 결과, 판정을 캡처 - 코드는 폐기 가능하게 유지하세요 — "프로덕션용으로 정리"하는 데 2일이 걸리는 스파이크는 나쁜 스파이크였습니다.
기여
GSD (Get Shit Done) 프로젝트의 /gsd-spike 워크플로우에서 각색 — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). 전체 GSD 시스템은 영구적인 스파이크 상태, MANIFEST 추적, 그리고 더 광범위한 스펙 기반 개발 파이프라인과의 통합을 제공합니다. 설치: npx get-shit-done-cc --hermes --global.