[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,135 +2,216 @@
|
||||
id: wiki-2026-0508-프로토타이핑-및-개념-증명-poc
|
||||
title: 프로토타이핑 및 개념 증명(PoC)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-D78391E1]
|
||||
aliases: [PoC, Proof of Concept, Prototype, Spike]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [프로토타이핑-및-개념-증명(poc), 계층형-아키텍처(layered-architecture), 서버리스-아키텍처(serverless-architecture), 계층형-아키텍처(layered-architecture), 서버리스-아키텍처(serverless-architecture), architecture-principles]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [process, prototyping, poc, architecture, methodology]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-02
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: -
|
||||
framework: -
|
||||
---
|
||||
|
||||
# [[프로토타이핑 및 개념 증명(PoC)]]
|
||||
# 프로토타이핑 및 개념 증명(PoC)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프로토타이핑 및 개념 증명(PoC)은 소프트웨어 프로젝트에서 중앙 집중적인 기술적 위험을 최소화하고 특정 기술이나 아이디어가 실제로 작동하는지 조기에 검증하기 위해 시스템을 단순화하여 구현하는 방법이다 [1]. 주로 MVP(최소 기능 제품) 개발 단계에서 활용되며, 초기 구축 비용이 낮고 배포가 빠른 계층형(Layered), 서버리스(Serverless), 마이크로커널(Microkernel) 아키텍처가 프로토타이핑에 가장 널리 권장된다 [2-5].
|
||||
## 매 한 줄
|
||||
> **"매 production 이전에 매 risk-laden hypothesis 를 매 cheapest 형태로 검증하는 throwaway 작업."**. 매 prototype = 매 UX / 형태 검증, 매 PoC = 매 기술적 feasibility 검증. 매 둘 다 매 disposable — 매 production code 로 graduating 매 매 흔한 antipattern. 2026 modern stack 에서 매 LLM (Claude Opus 4.7 코드 생성) + 매 v0 / Bolt / Cursor 가 매 prototype turnaround 를 매 hours → minutes 로 단축.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **PoC와 프로토타입의 주요 목적**
|
||||
프로토타이핑과 개념 증명(PoC)은 부하에 따른 시스템의 성능, 기존 시스템과의 통합 가능성, 운영 비용 및 특정 기술의 실현 가능성 등 핵심적인 기술 위험 요소를 초기에 확인하기 위해 사용된다 [1, 6]. 이러한 조기 검증 과정은 추후 발생할 수 있는 막대한 노력의 낭비를 막고 잘못된 의사결정을 줄여주는 역할을 한다 [1, 7].
|
||||
## 매 핵심
|
||||
|
||||
* **MVP 및 프로토타이핑에 적합한 아키텍처 패턴**
|
||||
* **[[계층형 아키텍처(Layered Architecture)]]**: 완벽함보다는 속도를 중시하는 초기 스타트업이나 소규모 팀이 MVP를 구축하고 배포할 때 가장 적합한 방식이다 [8, 9]. 초기 설정 비용이 적게 들고 3계층 설계(UI, 비즈니스 로직, 데이터베이스) 기반으로 신속하게 반복 작업을 수행할 수 있어 프로토타입 제작에 이상적이다 [3-5].
|
||||
* **[[서버리스 아키텍처(Serverless Architecture)]]**: 서버 관리 없이 작성된 코드를 바로 배포할 수 있으며, 종량제(Pay-per-use) 요금 모델을 제공하여 예측 불가능한 트래픽을 가진 MVP 및 빠른 프로토타이핑을 구축하는 데 비용 효율적이다 [2, 4, 10, 11].
|
||||
* **마이크로커널 아키텍처(Microkernel Architecture)**: 점진적인 기능 추가가 용이하여, 소규모 비즈니스를 위한 MVP 개발에 비용 효율적인 아키텍처 대안으로 꼽힌다 [4, 12].
|
||||
### 매 용어 구분
|
||||
- **Sketch / Wireframe**: 매 visual idea, 매 non-functional. Figma, paper.
|
||||
- **Prototype**: 매 interactive UX, 매 hardcoded data. Figma prototype, v0.
|
||||
- **PoC (Proof of Concept)**: 매 핵심 technical risk 한 점 만 검증. CLI script, jupyter notebook.
|
||||
- **Spike (Agile)**: 매 timeboxed exploration. 매 1–3 days.
|
||||
- **MVP (Minimum Viable Product)**: 매 production-grade. 매 PoC 의 X.
|
||||
|
||||
* **MVP 단계에서 지양해야 할 아키텍처**
|
||||
5명 미만의 소규모 개발 팀이거나 프로젝트가 단순한 프로토타입/MVP 수준일 경우, 고도의 DevOps 전문 지식과 높은 초기 비용 및 오버헤드를 요구하는 마이크로서비스 아키텍처(Microservices Architecture)의 도입은 피하는 것이 좋다 [13-15].
|
||||
### 매 PoC 의 가치
|
||||
- **De-risk**: 매 architecture 결정 전 매 unknown 제거.
|
||||
- **Cost compression**: 매 wrong path 의 매 cheap pivot.
|
||||
- **Stakeholder alignment**: 매 demo > spec.
|
||||
- **Estimation**: 매 effort estimate 의 grounding.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **기술적 부채와 향후 리팩토링의 강제성**
|
||||
초기 MVP나 프로토타입을 빠르게 시장에 출시하기 위해 계층형 아키텍처를 선택할 경우, 시스템 규모가 커짐에 따라 경계가 무너지고 코드가 복잡하게 얽히는 문제(Spaghetti code)가 발생할 수 있다 [8, 16]. 따라서 MVP 단계 이후에는 보안 부채나 기술적 빚이 쌓이는 것을 방지하기 위해 헥사고날(Hexagonal)이나 클린 아키텍처(Clean Architecture)와 같이 경계가 명확한 구조로 점진적인 리팩토링(Refactoring)을 반드시 수행해야 한다는 제약이 따른다 [5, 9, 17, 18].
|
||||
* **서버리스 아키텍처 도입 시의 부작용**
|
||||
서버리스는 프로토타이핑 속도를 높여주지만, 일정 시간 비활성화된 후 호출될 때 발생하는 콜드 스타트(Cold start)로 인한 초기 지연 시간(최대 5초) 문제가 발생할 수 있다 [19-21]. 또한, 함수 실행 시간의 엄격한 제한과 클라우드 제공업체에 대한 높은 벤더 종속성(Vendor lock-in)을 감수해야 한다 [19, 20, 22].
|
||||
### 매 흔한 실패 모드
|
||||
1. **PoC → production graduation**: 매 hardcoded auth, 매 single-tenant assumption 이 매 그대로 prod.
|
||||
2. **Scope creep**: 매 PoC 가 매 mini-MVP 로 비대.
|
||||
3. **No success criteria**: 매 언제 끝났는지 의 unclear.
|
||||
4. **Confusion of UX vs tech**: 매 prototype + PoC 를 매 동일 산출물에.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
### 매 응용
|
||||
1. New ML model 의 latency / accuracy 검증.
|
||||
2. Third-party API 의 rate limit / behavior 탐색.
|
||||
3. Architecture migration (REST → gRPC) 의 risk 측정.
|
||||
4. UX hypothesis 의 user testing.
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
- **[[계층형 아키텍처(Layered Architecture)]]**
|
||||
- 연결 이유: 소규모 팀이 MVP나 프로토타입을 신속하게 시장에 출시하기 위해 가장 흔하게 채택하는 아키텍처 패턴이다 [5, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 개발 속도와 장기적인 유지보수성 사이의 구조적 트레이드오프 원리를 이해할 수 있다.
|
||||
- **[[서버리스 아키텍처(Serverless Architecture)]]**
|
||||
- 연결 이유: 인프라 관리 부담을 없애고 초기 비용을 최소화하여 빠른 프로토타이핑을 가능하게 하는 클라우드 네이티브 기술이다 [2, 10].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이벤트 기반 트리거 방식과 상태 비저장(Stateless) 시스템 설계의 경제적 이점을 파악할 수 있다.
|
||||
- **[[마이크로서비스 아키텍처(Microservices Architecture)]]**
|
||||
- 연결 이유: MVP 단계에서는 도입이 권장되지 않으나, 프로토타입이 성공하여 대규모로 확장될 때 도달해야 할 최종 아키텍처의 형태 중 하나이다 [13, 16].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로토타입 설계 시 향후 시스템의 분산화 및 스케일 아웃(Scale-out)을 대비하는 구조적 경계 설정법을 배울 수 있다.
|
||||
## 💻 패턴
|
||||
|
||||
#### [관계 유형 B: 구현/활용 도구]
|
||||
- **[[MVP(Minimum Viable Product)]]**
|
||||
- 연결 이유: 프로토타이핑 및 PoC의 가장 대표적인 소프트웨어 제품 산출물 형태이며, 빠른 반복과 피드백을 목적으로 한다 [2, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 가치 검증과 소프트웨어 아키텍처 선택 기준이 어떻게 연결되는지 이해할 수 있다.
|
||||
- **[[리팩토링(Refactoring)]]**
|
||||
- 연결 이유: 단순한 3계층 설계의 MVP가 안정된 이후, 헥사고날(Hexagonal) 등 성숙한 아키텍처로 진화하기 위해 필수적으로 거쳐야 하는 과정이다 [5, 9, 17].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 프로토타입 코드를 점진적으로 발전시켜 기술 부채를 해결하는 공학적 접근법을 알 수 있다.
|
||||
### Pattern 1 — PoC scope contract (markdown template)
|
||||
```markdown
|
||||
# PoC: <Title>
|
||||
|
||||
### Deeper Research Questions
|
||||
- 초기 MVP 구현을 위해 계층형 아키텍처를 선택할 때, 향후 마이크로서비스 또는 헥사고날 아키텍처로의 원활한 전환(Refactoring)을 위해 초기 단계부터 지켜야 할 모듈화 원칙은 무엇인가?
|
||||
- 서버리스 아키텍처를 이용해 PoC를 구성할 때, 벤더 종속성(Vendor lock-in)과 콜드 스타트(Cold start) 문제를 최소화할 수 있는 설계 전략은 무엇인가?
|
||||
- 아키텍처 트레이드오프 분석(ATAM) 과정에서, 프로토타이핑을 통해 수집한 데이터를 어떻게 객관적 지표(성능, 부하 등)로 정량화하여 의사결정에 반영할 수 있는가?
|
||||
- 마이크로커널 아키텍처를 활용하여 플러그인 형태로 MVP 기능을 점진적으로 검증하는 방식이 SaaS 플랫폼 개발에서 가지는 경제적 효용성은 무엇인가?
|
||||
- 대규모 엔터프라이즈 환경에서 레거시 시스템을 현대화(Modernization)하기 위한 PoC를 진행할 때, 메인 시스템에 영향을 주지 않고 안전하게 검증하기 위해 사이드카(Sidecar) 패턴을 어떻게 활용할 수 있는가?
|
||||
## Hypothesis
|
||||
"매 <X> 가 매 <constraint> 안에서 매 가능하다."
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 빠른 배포와 초기 비용 절감을 위해 복잡한 인프라 설정 대신 계층형 아키텍처나 서버리스 아키텍처를 채택하여 초기 제품 버전을 신속히 코딩하고 시장 피드백을 수집한다 [3, 8, 9].
|
||||
- **System Design:** 프로젝트가 단순한 개념 증명을 위한 것인지, 향후 복잡한 외부 시스템 통합을 고려해야 하는지에 따라, 초기부터 헥사고날 아키텍처와 같은 포트/어댑터 모델을 일부 차용할지 혹은 단순 계층형으로 시작할지 결정한다 [5, 23].
|
||||
- **Operation / Maintenance:** MVP 배포 후 트래픽이 발생하기 시작하면, 초기에 빠르게 작성된 계층형 구조가 얽히거나 보안 문제를 일으키지 않도록 점진적인 코드 분리 및 리팩토링 계획을 운영 프로세스에 편입한다 [5, 18].
|
||||
- **Learning Path:** 소규모 프로젝트에서 아키텍처 패턴이 배포 속도와 구조적 복잡도에 미치는 영향을 직접 체감하며, '속도 우선(Speed Over Perfection)' 접근법의 장단점을 학습한다 [8].
|
||||
- **My Project Relevance:** 현재 진행 중인 프로젝트가 시장의 가설을 먼저 검증해야 하는 MVP 단계라면, 막대한 오버헤드가 드는 복잡한 아키텍처(예: 마이크로서비스)의 도입을 보류하고 신속한 가치 제공에 집중하도록 팀의 방향성을 조정한다 [5, 13].
|
||||
## Success criteria (매 binary, 매 measurable)
|
||||
- [ ] 매 latency p95 < 200ms
|
||||
- [ ] 매 accuracy >= 0.85
|
||||
- [ ] 매 cost per request < $0.01
|
||||
|
||||
### Adjacent Topics
|
||||
- **[[ATAM (Architecture Trade-offs Analysis Method)]]**
|
||||
- 확장 방향: 완벽한 아키텍처는 없으며 항상 타협(Trade-off)이 필요하다는 사실을 바탕으로, PoC 과정에서 드러난 시스템의 한계점 및 시나리오(예: 부하 테스트)를 체계적으로 평가하고 분석하는 방법론으로 학습을 확장한다 [24].
|
||||
- **[[ADR (Architecture Decision Records)]]**
|
||||
- 확장 방향: MVP 및 프로토타입 단계에서 속도와 비용을 위해 특정한 아키텍처(예: 계층형)를 선택하게 된 맥락, 채택한 이유, 발생 가능한 리스크를 문서화하고 이력을 추적하는 관리 기법으로 연결하여 조사한다 [25, 26].
|
||||
## Out of scope
|
||||
- 매 auth, 매 multi-tenancy, 매 retry, 매 observability.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
## Timebox
|
||||
- 매 3 days. 매 day 4 의 결정 (proceed / pivot / stop).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
## Disposal
|
||||
- 매 결과 wiki page 로 정리, 매 code 는 매 archive branch 로.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2 — Notebook PoC (LLM model eval)
|
||||
```python
|
||||
# poc_llm_eval.ipynb
|
||||
import asyncio, time
|
||||
from anthropic import AsyncAnthropic
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
client = AsyncAnthropic()
|
||||
PROMPTS = open('eval_set.txt').read().splitlines() # 매 50 prompts.
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
async def run_one(p):
|
||||
t = time.perf_counter()
|
||||
msg = await client.messages.create(
|
||||
model='claude-opus-4-7',
|
||||
max_tokens=1024,
|
||||
messages=[{'role': 'user', 'content': p}],
|
||||
)
|
||||
return time.perf_counter() - t, msg.content[0].text
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
results = await asyncio.gather(*(run_one(p) for p in PROMPTS))
|
||||
latencies = [r[0] for r in results]
|
||||
print(f'p50={sorted(latencies)[25]:.2f}s, p95={sorted(latencies)[47]:.2f}s')
|
||||
# 매 single notebook → success criteria 즉시 평가.
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 3 — v0 / Bolt prototype (UX validation)
|
||||
```typescript
|
||||
// 매 v0.dev prompt:
|
||||
// "Build a Linear-style task board with drag-and-drop columns,
|
||||
// using shadcn/ui, Next.js 15 App Router, TailwindCSS."
|
||||
//
|
||||
// 매 30초 → 매 working demo URL.
|
||||
// 매 stakeholder 에 매 link 공유 → 매 feedback 1 hour 안 수집.
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 4 — Cursor + Opus 4.7 spike
|
||||
```bash
|
||||
# 매 1 day spike — gRPC migration feasibility.
|
||||
$ cursor agent
|
||||
> Take src/api/rest/*, generate equivalent gRPC service definitions
|
||||
in proto/, and a thin BFF layer that translates REST → gRPC.
|
||||
Don't touch tests. Generate a benchmark script comparing p95 latency
|
||||
on 1000 sequential requests.
|
||||
```
|
||||
|
||||
### Pattern 5 — Disposable infra (PoC sandbox)
|
||||
```bash
|
||||
# 매 PoC env — 매 1-day TTL 의 매 ephemeral cluster.
|
||||
$ neon branches create --name poc-grpc --parent main --ttl 24h
|
||||
$ vercel deploy --prebuilt --target preview
|
||||
$ render blueprint apply poc.yaml --env ephemeral
|
||||
# 매 끝나면 매 자동 destroy — 매 cost / sprawl 방지.
|
||||
```
|
||||
|
||||
### Pattern 6 — Spike commit hygiene
|
||||
```bash
|
||||
$ git checkout -b spike/grpc-feasibility
|
||||
$ # 매 hack 자유 — 매 lint, test 의 X.
|
||||
$ git commit -am 'spike: hardcoded auth, no error handling'
|
||||
$ git push origin spike/grpc-feasibility
|
||||
# 매 PR 의 X — 매 결과만 wiki / RFC 로 추출.
|
||||
$ git branch -D spike/grpc-feasibility # 매 disposal.
|
||||
```
|
||||
|
||||
### Pattern 7 — Decision record (post-PoC)
|
||||
```markdown
|
||||
# ADR-042: gRPC migration
|
||||
|
||||
## Status
|
||||
Accepted, 2026-05-10.
|
||||
|
||||
## Context
|
||||
PoC (spike/grpc-feasibility) — 매 3 days.
|
||||
|
||||
## Result
|
||||
- 매 p95 latency: REST 180ms → gRPC 45ms.
|
||||
- 매 client SDK regen 의 매 30 min CI.
|
||||
- 매 browser 의 grpc-web bridge 필요 (Connect-Web 채택).
|
||||
|
||||
## Decision
|
||||
- 매 internal service-to-service 는 매 gRPC.
|
||||
- 매 browser-facing 은 매 Connect (gRPC-compatible).
|
||||
- 매 migration order: 매 order-svc → 매 inventory-svc → 매 user-svc.
|
||||
|
||||
## Consequences
|
||||
- 매 +1 dev week / service migration.
|
||||
- 매 OTel gRPC instrumentation 추가 필요.
|
||||
```
|
||||
|
||||
### Pattern 8 — Anti-graduation guard
|
||||
```yaml
|
||||
# .github/workflows/no-spike-to-main.yml
|
||||
name: Block spike merges
|
||||
on: pull_request
|
||||
jobs:
|
||||
guard:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: |
|
||||
if [[ "${{ github.head_ref }}" == spike/* || "${{ github.head_ref }}" == poc/* ]]; then
|
||||
echo "::error::spike/poc branches must not be merged. Extract findings to ADR/wiki."
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Tool |
|
||||
|---|---|
|
||||
| 매 UX hypothesis | Figma + v0 prototype |
|
||||
| 매 API / model behavior | Notebook PoC |
|
||||
| 매 architecture decision | Spike + ADR |
|
||||
| 매 stakeholder demo | v0 / Bolt |
|
||||
| 매 production migration | MVP, 매 not PoC |
|
||||
|
||||
**기본값**: 매 PoC 는 매 timeboxed (1–3 days), 매 success criteria binary, 매 disposable, 매 finding → ADR. 매 graduation 금지.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software Engineering Process]] · [[Risk-Driven Development]]
|
||||
- 변형: [[Spike (Agile)]] · [[MVP]] · [[Wireframe / Prototype]]
|
||||
- 응용: [[ADR (Architecture Decision Record)]] · [[Disposable Infrastructure]]
|
||||
- Adjacent: [[Cursor Agent Workflow]] · [[v0 / Bolt]] · [[Lean Startup]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 hypothesis 정의, 매 PoC 코드 작성 (Cursor / Claude Code), 매 결과 ADR 정리.
|
||||
**언제 X**: 매 PoC 코드를 매 production 으로 의 graduation. 매 success criteria 의 LLM-fabricated metric (실제 측정 X).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Graduation**: 매 PoC code 가 매 main 에 — 매 hardcoded debt.
|
||||
- **Open-ended PoC**: 매 timebox X — 매 weeks drift.
|
||||
- **No criteria**: 매 "잘 되면 좋겠다" — 매 stop condition 없음.
|
||||
- **Demo-driven**: 매 PoC 가 매 polished demo 로 — 매 effort 낭비.
|
||||
- **재활용 환상**: 매 "그래도 일부 reusable" — 매 거의 항상 매 false economy.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Lean Startup, Pragmatic Programmer, Google SRE workbook chapter "Spike").
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — PoC vs Prototype + 8 process patterns |
|
||||
|
||||
Reference in New Issue
Block a user