기술 R&D 단계별 접근법 (Claude Code)

버전: 2.0 | 최종 업데이트: 2026-01-29 Canva처럼 복잡한 기술을 단계별로 연구하고 고도화하는 워크플로우 핵심: Tech Spike → POC → Integration → Iteration

🎯 핵심 개념

일반 개발 vs 기술 R&D 개발

4단계 R&D 사이클

┌─────────────────────────────────────────────────────────────────┐
│  1. Tech Spike (기술 스파이크)                                   │
│     └─ 특정 기술을 독립적으로 연구/실험                          │
│        예: "Canvas API로 드래그앤드롭 가능한가?"                 │
├─────────────────────────────────────────────────────────────────┤
│  2. POC (Proof of Concept)                                      │
│     └─ 개념 증명, 최소한의 작동하는 프로토타입                   │
│        예: "기본 도형 3개를 드래그로 배치하는 에디터"            │
├─────────────────────────────────────────────────────────────────┤
│  3. Integration (통합)                                          │
│     └─ 검증된 기술을 메인 프로젝트에 통합                        │
│        예: "POC 코드를 실제 프로젝트 구조에 맞게 리팩토링"       │
├─────────────────────────────────────────────────────────────────┤
│  4. Iteration (고도화)                                          │
│     └─ 반복 개선, 성능 최적화, 기능 확장                         │
│        예: "Undo/Redo 추가", "레이어 시스템 추가"                │
└─────────────────────────────────────────────────────────────────┘

R&D 워크플로우 상세 흐름도

┌─────────────────────────────────────────────────────────────────────────┐
│                         복잡한 기술 과제 발생                            │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  Stage 1: Tech Spike (기술 실험)                                        │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  spikes/                                                        │   │
│  │  └── YYYYMMDD-주제/                                             │   │
│  │      ├── README.md      (가설, 실험 계획)                        │   │
│  │      ├── experiments/   (실험 코드)                              │   │
│  │      └── findings.md    (발견 사항)                              │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│  "기술 스파이크 시작해줘. 주제: [...], 질문: [...]"                      │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼ 검증 필요
┌─────────────────────────────────────────────────────────────────────────┐
│  Stage 2: POC (개념 증명)                                               │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  poc/                                                           │   │
│  │  └── 기능명/                                                     │   │
│  │      ├── README.md      (목표, 성공 기준)                        │   │
│  │      ├── src/           (POC 코드)                               │   │
│  │      └── results.md     (결과, 제한사항)                         │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│  "POC 시작해줘. 기반 스파이크: [...], 범위: [...]"                       │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼ 성공
┌─────────────────────────────────────────────────────────────────────────┐
│  Stage 3: Integration (프로덕션 통합)                                    │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  • POC 코드 → src/ 이동                                         │   │
│  │  • 에러 처리 추가                                               │   │
│  │  • 테스트 작성                                                  │   │
│  │  • 문서화                                                       │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│  "POC 통합해줘. POC: [...], 위치: [...]"                                │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│  Stage 4: Iteration (고도화)                                            │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  • 성능 최적화                                                  │   │
│  │  • 기능 확장                                                    │   │
│  │  • 리팩토링                                                     │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│  "[기능] 고도화해줘. 목표: [...]"                                        │
└─────────────────────────────────────────────────────────────────────────┘

📁 프로젝트 구조 (권장)

my-project/
├── spikes/                    # 🔬 기술 스파이크 (실험실)
│   ├── spike-001-canvas-drag/
│   │   ├── README.md          # 실험 목적, 결과, 학습
│   │   ├── index.html         # 독립 실행 가능한 실험
│   │   └── spike.ts
│   ├── spike-002-webgl-render/
│   ├── spike-003-realtime-collab/
│   └── _archive/              # 실패/완료된 스파이크 보관
│
├── poc/                       # 🧪 POC (개념 증명)
│   ├── poc-001-basic-editor/
│   │   ├── README.md          # POC 범위, 제한사항, 결론
│   │   └── src/
│   └── poc-002-layer-system/
│
├── src/                       # 🏭 프로덕션 코드
│   └── ...
│
└── docs/
    └── research/              # 📚 기술 연구 문서
        ├── canvas-api.md
        ├── webgl-vs-canvas.md
        └── decision-log.md    # 기술 결정 기록

자동화: /kdyspike 스킬 연계

아래 Stage 1 (Tech Spike)을 자동화한 스킬이 있습니다.

마이크로 스파이크 (경량 트랙)

기존 풀 스파이크(폴더 생성, README 작성 등)가 무거워서 건너뛰는 문제를 해결하기 위한 경량 트랙:

• 대상: Level 23 (SimpleModerate) 기능
• 소요: 15~30분
• 산출물: docs/research/micro-spike-{YYYYMMDD}-{주제}.md 단일 문서
• 내용: 웹검색 3회 + 접근법 비교 + 의사결정 (실험 코드 없음)

풀 스파이크가 부담될 때 마이크로 스파이크로 최소한의 사전 연구를 수행합니다.

🔬 Stage 1: Tech Spike (기술 스파이크)

"이 기술이 우리가 원하는 걸 할 수 있는가?"를 검증

명령어

기술 스파이크 시작해줘.

주제: [Canvas API 드래그앤드롭]
질문: [Canvas 위의 요소를 마우스로 드래그해서 이동할 수 있는가?]

1. spikes/spike-XXX-[주제명]/ 폴더 생성
2. 웹검색으로 해당 기술 조사
   - 공식 문서
   - 주요 라이브러리
   - 알려진 제한사항
3. 최소한의 실험 코드 작성
   - 독립 실행 가능하게 (index.html 하나로)
   - 핵심 질문에만 집중
4. README.md에 기록
   - 목적
   - 실험 결과
   - 학습한 점
   - 다음 단계 제안

Claude Code 출력 형식

🔬 Tech Spike: Canvas 드래그앤드롭

📋 조사 결과
- Canvas API는 DOM 이벤트와 별개로 동작
- 직접 hit detection 구현 필요
- 라이브러리: Fabric.js, Konva.js가 이미 해결

📋 실험 코드
- 위치: spikes/spike-001-canvas-drag/
- 실행: index.html 브라우저에서 열기

📋 결과
✅ 가능: 마우스 좌표로 요소 이동 가능
⚠️ 주의: 요소 많아지면 성능 이슈
💡 제안: Fabric.js 사용 검토

📋 다음 단계
- POC로 진행할지?
- 다른 접근법(WebGL) 스파이크할지?

스파이크 README.md 템플릿

# Spike: [주제]

> 생성일: YYYY-MM-DD
> 상태: 진행중 / 완료 / 실패

## 질문
- 검증하고자 하는 것

## 조사 내용
- 공식 문서 링크
- 참고 자료

## 실험 방법
- 어떻게 테스트했는지

## 결과
- ✅ 성공한 것
- ❌ 실패한 것
- ⚠️ 주의사항

## 학습
- 알게 된 점

## 결론
- POC 진행 여부
- 대안 검토 필요 여부

🧪 Stage 2: POC (Proof of Concept)

"이 기술로 우리가 원하는 기능을 만들 수 있는가?"를 검증

명령어

POC 시작해줘.

기반 스파이크: spike-001-canvas-drag
POC 범위: [기본 도형 3개(사각형, 원, 삼각형)를 캔버스에 추가하고 드래그로 이동]

1. poc/poc-XXX-[기능명]/ 폴더 생성
2. 스파이크 결과를 기반으로 확장
3. 실제 사용 시나리오에 가깝게 구현
   - 하지만 완벽할 필요 없음
   - "이게 되는구나"를 확인하는 수준
4. 제한사항 명시
5. README.md에 기록
   - POC 범위
   - 구현한 것 / 안 한 것
   - 프로덕션 적용 시 고려사항

POC README.md 템플릿

# POC: [기능명]

> 생성일: YYYY-MM-DD
> 기반 스파이크: spike-XXX
> 상태: 진행중 / 완료

## 범위 (Scope)
### 포함
- 기본 도형 추가 (사각형, 원, 삼각형)
- 드래그로 이동
- 클릭으로 선택

### 제외 (의도적으로 안 함)
- 크기 조절
- 회전
- Undo/Redo
- 저장/불러오기

## 실행 방법

npm install npm run dev

## 기술 스택
- Fabric.js
- React
- TypeScript

## 발견한 이슈
- [ ] 이슈1
- [ ] 이슈2

## 프로덕션 적용 시 고려사항
- 성능: 요소 100개 이상일 때 테스트 필요
- 구조: 현재 코드는 단일 파일, 분리 필요
- 테스트: 드래그 동작 테스트 방법 연구 필요

## 결론
- ✅ 프로덕션 진행 가능
- 예상 작업량: 2주

🏭 Stage 3: Integration (통합)

POC에서 검증된 기술을 프로덕션에 통합

명령어

POC 통합해줘.

POC: poc-001-basic-editor
통합 위치: src/features/editor/

1. POC 코드 분석
2. 프로젝트 구조에 맞게 리팩토링
   - 컴포넌트 분리
   - 타입 정의
   - 테스트 추가
3. 기존 코드와 충돌 확인
4. 단계별로 통합 (한번에 다 하지 않음)
5. 통합 후 POC 폴더는 _archive로 이동

통합 계획 먼저 알려줘.

Claude Code 출력 형식

📋 POC 통합 계획

POC 분석 결과:
- 파일 3개 (Editor.tsx, Canvas.tsx, shapes.ts)
- 외부 의존성: fabric.js

통합 단계:
1단계: 의존성 설치 (fabric.js)
2단계: 타입 정의 (src/types/editor.ts)
3단계: 기본 컴포넌트 이동 (src/features/editor/)
4단계: 기존 레이아웃에 연결 (src/app/editor/page.tsx)
5단계: 테스트 작성

예상 파일 구조:
src/features/editor/
├── components/
│   ├── Canvas.tsx
│   ├── Toolbar.tsx
│   └── ShapeButton.tsx
├── hooks/
│   └── useCanvas.ts
├── types/
│   └── shapes.ts
└── index.ts

이대로 진행할까요?

🔄 Stage 4: Iteration (고도화)

통합된 기능을 반복적으로 개선

명령어

[기능명] 고도화해줘.

현재 상태: 기본 드래그앤드롭 동작
목표: Undo/Redo 기능 추가

1. 현재 구현 분석
2. 고도화 방법 연구 (웹검색)
   - 일반적인 패턴
   - 라이브러리 옵션
   - 성능 고려사항
3. 구현 계획 제안
4. 단계별 구현

분석 결과와 계획 먼저 알려줘.

반복 고도화 체크리스트

## [기능명] 고도화 로그

### v0.1 (기본)
- [x] 기본 동작 구현
- [x] POC 완료

### v0.2 (안정화)
- [ ] 에러 핸들링
- [ ] 엣지 케이스 처리
- [ ] 기본 테스트

### v0.3 (기능 확장)
- [ ] Undo/Redo
- [ ] 키보드 단축키
- [ ] 다중 선택

### v0.4 (성능)
- [ ] 렌더링 최적화
- [ ] 메모리 관리
- [ ] 대용량 데이터 테스트

### v1.0 (프로덕션)
- [ ] 문서화
- [ ] 접근성
- [ ] 크로스 브라우저 테스트

📚 기술 결정 기록 (Decision Log)

왜 이 기술을 선택했는지 기록

명령어

기술 결정 기록해줘.

주제: 캔버스 라이브러리 선택
선택: Fabric.js
대안: Konva.js, 직접 구현

docs/research/decision-log.md에 추가해줘.

Decision Log 템플릿

# 기술 결정 기록

## 2025-01-16: 캔버스 라이브러리 선택

### 컨텍스트
- 그래픽 에디터 개발 필요
- 드래그, 선택, 변형 기능 필요

### 검토한 옵션
1. **Fabric.js**
   - 장점: 풍부한 기능, 큰 커뮤니티
   - 단점: 번들 크기 큼 (300KB)
   
2. **Konva.js**
   - 장점: React 통합 좋음
   - 단점: 저수준 API

3. **직접 구현**
   - 장점: 완전한 제어
   - 단점: 개발 시간 많이 필요

### 결정
**Fabric.js 선택**

### 이유
- POC에서 충분한 성능 확인
- 우리 요구사항에 맞는 기능 내장
- 커뮤니티 지원 활발

### 결과
- spike-001, poc-001에서 검증 완료
- 프로덕션 통합 진행

🎮 실전 예시: Canva 같은 에디터 개발

Phase 1: 핵심 기술 스파이크

기술 스파이크 시작해줘.

주제: Canvas vs SVG vs WebGL 비교
질문: 그래픽 에디터에 어떤 렌더링 방식이 적합한가?

비교 기준:
- 성능 (요소 1000개 이상)
- 개발 편의성
- 브라우저 지원
- 인터랙션 처리

Phase 2: 단계별 POC

POC 로드맵 만들어줘.

최종 목표: Canva 같은 그래픽 에디터

POC 순서:
1. poc-001: 기본 캔버스 + 도형 배치
2. poc-002: 레이어 시스템
3. poc-003: 텍스트 편집
4. poc-004: 이미지 처리
5. poc-005: 실시간 협업

각 POC 범위와 예상 기간 정리해줘.

Phase 3: 점진적 통합

에디터 기능 점진적 통합 계획 세워줘.

원칙:
- 한 번에 하나의 POC만 통합
- 통합 후 안정화 기간 1주
- 다음 POC 통합 전 리뷰

현재: poc-001 완료
다음: poc-002 통합 준비

통합 계획 알려줘.

🔑 핵심 원칙

1. 작게 시작 - 스파이크는 하루 이내로 끝낼 수 있는 크기
2. 빠르게 실패 - 안 되면 빨리 다른 방법 시도
3. 기록 남기기 - 왜 이 결정을 했는지 기록
4. 독립적으로 실험 - 스파이크는 메인 코드와 분리
5. 점진적 통합 - 검증된 것만 프로덕션에

📋 빠른 참조: 주요 명령어

📂 Python R&D 세션 전략

Python 데이터 분석 R&D를 위한 확장 문서:

← 체계 목차