[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,154 +2,149 @@
|
||||
id: wiki-2026-0508-prototyping
|
||||
title: Prototyping
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Rapid Prototyping, MVP Prototyping]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [process, design, mvp, ux]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
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: typescript
|
||||
framework: figma-v0-claude
|
||||
---
|
||||
|
||||
# [[Prototyping (프로토타이핑)]]
|
||||
# Prototyping
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프로토타이핑(Prototyping)은 시스템 컴포넌트의 초기 단순화된 구현체를 만들어 기술적 접근 방식을 테스트하고 핵심적인 위험을 식별하는 과정입니다 [1]. 소프트웨어 아키텍처 설계에 있어 부하 성능, 기술의 실현 가능성 등을 조기에 검증(Early validation)하여 잘못된 결정을 줄이는 데 필수적입니다 [1, 2]. 주로 빠른 개발이 가능한 모놀리식(Monolithic)이나 서버리스(Serverless) 아키텍처가 초기 프로토타이핑 구축에 널리 활용됩니다 [3, 4].
|
||||
## 매 한 줄
|
||||
> **"매 cheapest test 매 maximum learning"**. 매 paper sketches → Figma → v0 / Claude Artifacts / Lovable / Bolt 매 2026 매 generative prototyping era. 매 hours 단위 product validation.
|
||||
|
||||
---
|
||||
## 매 핵심
|
||||
|
||||
> "실패를 앞당기는 지혜: 완성도를 낮추더라도 핵심 기능만 빠르게 만들어 실제 환경에서 테스트해 봄으로써, 수조 원의 예산을 쏟아붓기 전에 아이디어의 생존 가능성을 미리 검증하는 '가장 싼 실패'."
|
||||
### 매 fidelity ladder
|
||||
- **Paper / whiteboard**: minutes — 매 flow validation.
|
||||
- **Wireframe** (Figma, Excalidraw): hours — 매 layout.
|
||||
- **Mid-fi** (Figma + interactions): day — 매 user testing.
|
||||
- **High-fi clickable** (ProtoPie, Framer): days — 매 stakeholder demo.
|
||||
- **Functional MVP** (v0, Lovable, Claude Artifacts): hours-days — 매 real users.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **위험 최소화 및 초기 검증 (Risk Minimization & Early Validation):** 프로토타입이나 개념 증명(Proof of concept)은 부하 하에서의 성능, 시스템 통합 문제, 운영 비용 및 모니터링, 혹은 특정 기술의 실현 가능성과 같은 핵심적인 기술적 위험(Central risks)이 존재할 때 이를 테스트하기 위해 구축됩니다 [1, 2]. 이러한 조기 검증 과정은 향후 발생할 수 있는 막대한 노력의 낭비를 방지하고, 잘못된 아키텍처 결정을 내릴 확률을 크게 줄여줍니다 [1].
|
||||
* **지식 관리 및 의사소통 수단:** 소프트웨어 아키텍처 분석(Analysis) 과정에서 설계 지식을 탐색하고 관리하는 핵심 활동 중 하나로 활용됩니다 [5]. 프로토타이핑을 통해 설계자 및 이해관계자 간의 원활한 소통을 도모하고 아키텍처에 대한 이해도를 높일 수 있습니다 [5].
|
||||
* **빠른 프로토타이핑에 적합한 아키텍처 패턴:**
|
||||
* **서버리스 아키텍처 (Serverless Architecture):** 배포가 빠르고 초기 구축 비용이 낮아, 예측할 수 없는 트래픽을 가진 스타트업이 빠른 프로토타이핑이나 MVP(최소 기능 제품)를 구축하는 데 매우 적합합니다 [3].
|
||||
* **모놀리식 / 계층형 아키텍처 (Monolithic / Layered Architecture):** 간소화된 개발 프로세스와 단일 코드베이스를 제공하므로 애플리케이션의 초기 버전을 빠르게 구축하고 테스트(Rapid Prototyping)하기에 이상적입니다 [4, 6]. 예를 들어, 단순한 3계층(3-tier) 디자인을 통해 빠르게 프로토타입을 반복(Iterate) 개발할 수 있습니다 [7].
|
||||
### 매 prototyping types (Houde & Hill 1997)
|
||||
- **Role**: what does it do for users?
|
||||
- **Look & feel**: 매 sensory experience.
|
||||
- **Implementation**: 매 technical feasibility.
|
||||
- **Integration**: 매 all three.
|
||||
|
||||
---
|
||||
### 매 응용
|
||||
1. 매 startup MVP — Lovable + Supabase 매 day.
|
||||
2. 매 enterprise feature spike — Claude Artifact for stakeholder.
|
||||
3. 매 UX research — Figma clickable, usertesting.com.
|
||||
4. 매 hardware — 3D print + Arduino.
|
||||
|
||||
프로토타이핑(Prototyping)은 제품의 본격적인 개발에 앞서 아이디어를 구체화하고 테스트하기 위한 시제품 제작 과정입니다.
|
||||
## 💻 패턴
|
||||
|
||||
1. **유형**:
|
||||
* **Low-fidelity**: 종이 스케치, 와이어프레임 (빠른 아이디어 검증).
|
||||
* **High-fidelity**: 실제 구동되는 코드나 정교한 디자인 (사용자 경험 테스트).
|
||||
* **Functional Prototype**: 디자인보다는 핵심 로직이 작동하는지 확인. ([[Minimal-Viable-Product|Minimal-Viable-Product]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 머릿속의 완벽한 상상이 실제 시장과 만났을 때 생기는 '치명적 괴리(Gap)'를 프로젝트 초기에 발견하여 수정 비용을 최소화하기 때문임. (Iteration와 연결)
|
||||
### Claude Artifact prototype (React)
|
||||
```tsx
|
||||
// User: "prototype a Pomodoro timer"
|
||||
import { useState, useEffect } from 'react';
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **초기 개발 속도와 장기적 기술 부채의 교환:** 계층형(Layered)이나 모놀리식 구조를 활용한 빠른 프로토타이핑은 초기 시장 진입 속도를 높이는 데 유리하지만, 장기적으로는 한계를 지닙니다 [7, 8]. 시스템이 성장함에 따라 경계가 무너지면 코드가 엉키고 복잡해져 심각한 기술 부채를 유발할 수 있으며, 추후 마이크로서비스나 헥사고날 아키텍처 등으로 리팩토링해야 하는 비용이 발생합니다 [7-9].
|
||||
* **확장성 및 유지보수성의 한계:** 모놀리식 아키텍처 기반의 프로토타입은 트래픽이 증가할 때 특정 부분만 개별적으로 확장할 수 없고 시스템 전체를 확장해야 하므로 자원 효율성이 떨어집니다 [10, 11]. 또한 작은 변경 사항을 적용하더라도 전체 애플리케이션을 다시 배포해야 하므로 배포 병목 현상이 발생할 수 있습니다 [10, 12].
|
||||
|
||||
---
|
||||
|
||||
- **과거 데이터와의 충돌**: 과거에는 프로토타입 제작만 몇 달이 걸리는 정책이었으나, 현대 정책은 노코드(No-code) 툴이나 AI 생성 정책을 통해 단 몇 시간 만에 고해상도 프로토타입 정책을 만드는 '초고속 프로토타이핑 정책'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 단순히 만드는 정책을 넘어, AI 시뮬레이터 정책을 통해 가상 고객 수만 명에게 프로토타입 정책을 던지고 피드백 정책을 수집하는 'AI 가속 검증 정책' 시대가 열림.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [설계 및 검증 기법]
|
||||
- [[Proof of Concept (개념 증명)]]
|
||||
- 연결 이유: 프로토타이핑과 함께 특정 기술이나 아이디어가 원칙적으로 작동하는지 초기에 입증하기 위해 사용되는 기법입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 아키텍처 설계 시 기술적 위험을 분리하고 테스트하여 불확실성을 줄이는 구체적인 검증 방법론을 이해할 수 있습니다.
|
||||
- [[Architecture Decision Records (ADR)]]
|
||||
- 연결 이유: 프로토타이핑 등을 통해 얻은 검증 결과와 그에 따른 아키텍처 결정 사항을 문서화하여 미래에도 이해할 수 있도록 남기는 기록입니다 [13, 14].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로토타입 결과가 실제 시스템 아키텍처 결정으로 어떻게 이어지고, 어떠한 대안과 타협점(Trade-off)을 거쳐 정립되는지 파악할 수 있습니다.
|
||||
|
||||
#### [아키텍처 패턴]
|
||||
- [[Monolithic Architecture (모놀리식 아키텍처)]]
|
||||
- 연결 이유: 개발이 단순하고 배포가 용이하여 초기 프로토타입이나 소규모 애플리케이션 구축에 가장 빈번하게 채택되는 아키텍처입니다 [4, 6].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 프로토타이핑 단계에서는 복잡한 분산 시스템보다 단일 코드베이스 체계가 생산성에 유리한지 한계점과 함께 이해할 수 있습니다.
|
||||
- [[Serverless Architecture (서버리스 아키텍처)]]
|
||||
- 연결 이유: 인프라 관리 부담을 줄이고 사용량에 따른 과금 모델을 제공하여 초기 자본 없이 빠른 프로토타입 구축을 가능하게 합니다 [3, 15].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라우드 네이티브 환경에서 프로토타입을 가장 민첩하고 경제적으로 테스트할 수 있는 구조적 대안을 이해할 수 있습니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
- 프로토타이핑 과정에서 발견된 성능 한계(Bottleneck)는 모놀리식 구조에서 마이크로서비스 구조로의 전환 시점을 어떻게 결정짓는가?
|
||||
- 서버리스 아키텍처로 프로토타입을 구축할 때 겪게 되는 콜드 스타트(Cold Start)나 벤더 종속성(Vendor Lock-in) 문제는 초기 아키텍처 설계에 어떤 영향을 미치는가?
|
||||
- 단순한 계층형 아키텍처(Layered Architecture)로 구축된 프로토타입을 향후 헥사고날 아키텍처(Hexagonal Architecture)로 점진적 리팩토링하기 위한 최적의 전략은 무엇인가?
|
||||
- 부하 분산 및 시스템 통합이라는 기술적 위험을 검증하기 위한 피어투피어(P2P)나 공간 기반 아키텍처(Space-Based Architecture)의 프로토타이핑은 어떤 지표를 중점적으로 평가해야 하는가?
|
||||
- 프로토타이핑을 통해 식별된 트레이드오프(Trade-off)는 Architecture Decision Records (ADR)에 어떤 구체적인 항목과 시나리오로 문서화되어야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** 팀이 새로운 프레임워크나 외부 API를 도입하기 앞서, 핵심 기능만 갖춘 최소한의 코드로 프로토타입을 만들어 기술적 타당성을 확인합니다.
|
||||
- **System Design:** 트래픽 폭증이 예상되는 서비스의 경우, 전체 마이크로서비스를 구축하기 전 특정 부하 상황을 가정한 프로토타입을 만들어 아키텍처의 한계와 병목을 조기에 파악합니다.
|
||||
- **Operation / Maintenance:** 서버리스 환경에 프로토타입을 배포하여 초기 트래픽에 따른 클라우드 과금과 모니터링 복잡성을 시뮬레이션하고 향후 운영 예산을 산정합니다.
|
||||
- **Learning Path:** 복잡한 분산 아키텍처(예: Event-Driven, Microservices)를 학습하기 전에, 동일한 비즈니스 로직을 모놀리식 프로토타입으로 먼저 구현해봄으로써 분산 시스템이 해결하는 본질적 문제를 체감합니다.
|
||||
- **My Project Relevance:** 제한된 예산과 짧은 기간 내에 프로젝트 MVP를 출시해야 할 때, 인프라 구축 오버헤드가 적은 서버리스나 단순한 계층형 아키텍처를 선택하여 빠르게 시장 검증(Prototyping)을 수행합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Minimum Viable Product (MVP)]]
|
||||
- 확장 방향: 프로토타입이 기술적 위험 검증에 초점을 맞춘다면, MVP는 비즈니스 가치와 사용자 반응을 검증하는 시장 출시 목적의 초기 제품으로 확장이 가능합니다.
|
||||
- [[Agile Software Development (애자일 소프트웨어 개발)]]
|
||||
- 확장 방향: 요구사항이 지속적으로 변하는 환경에서 프로토타이핑을 통해 빠르고 점진적인 설계(Evolutionary Design)를 도모하는 개발 프로세스 방법론으로 이해를 넓힐 수 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
---
|
||||
|
||||
- [[Minimal-Viable-Product|Minimal-Viable-Product]], [[Iteration|Iteration]], [[Iteration|Iteration]], UX, [[Innovation|Innovation]], Design-Thinking
|
||||
- **Modern Tech/Tools**: [[Figma|Figma]], Framer, Webflow, 3D Printing (Physical), AI-generated UI.
|
||||
---
|
||||
|
||||
## 🤖 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
|
||||
export default function Pomodoro() {
|
||||
const [secs, setSecs] = useState(1500);
|
||||
const [run, setRun] = useState(false);
|
||||
useEffect(() => {
|
||||
if (!run) return;
|
||||
const id = setInterval(() => setSecs(s => Math.max(0, s - 1)), 1000);
|
||||
return () => clearInterval(id);
|
||||
}, [run]);
|
||||
return (
|
||||
<div className="text-6xl font-mono">
|
||||
{Math.floor(secs/60)}:{String(secs%60).padStart(2,'0')}
|
||||
<button onClick={() => setRun(r => !r)}>{run ? 'Pause' : 'Start'}</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### v0.dev prompt-to-UI
|
||||
```
|
||||
Prompt: "dashboard with sidebar nav, 3 KPI cards, line chart of revenue,
|
||||
recent orders table. shadcn/ui, dark mode."
|
||||
→ Generates Next.js + Tailwind + shadcn components
|
||||
→ Edit via natural language follow-ups
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Wizard-of-Oz prototype (fake AI)
|
||||
```python
|
||||
# Test demand before building real ML
|
||||
def fake_classifier(text: str) -> str:
|
||||
# human in loop via Slack
|
||||
requests.post(SLACK, json={"text": f"Classify: {text}"})
|
||||
return wait_for_human_response() # poll DB
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Throwaway prototype (Streamlit)
|
||||
```python
|
||||
import streamlit as st
|
||||
import pandas as pd
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
st.title("Sales Forecast Demo")
|
||||
df = pd.read_csv(st.file_uploader("CSV"))
|
||||
horizon = st.slider("Days", 7, 90, 30)
|
||||
if st.button("Forecast"):
|
||||
st.line_chart(simple_forecast(df, horizon))
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Figma → code (Builder.io / Anima 2026)
|
||||
```typescript
|
||||
// Auto-export from Figma plugin
|
||||
import { LandingHero } from './figma-export/LandingHero';
|
||||
// then edit in code, no re-implementation
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### A/B prototype routing
|
||||
```typescript
|
||||
const variant = userId % 2 === 0 ? 'A' : 'B';
|
||||
return variant === 'A' ? <PrototypeA /> : <PrototypeB />;
|
||||
// instrument both, compare conversion
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Fidelity |
|
||||
|---|---|
|
||||
| 매 flow / IA validation | Paper / wireframe |
|
||||
| 매 visual design review | Mid-fi Figma |
|
||||
| 매 user test | High-fi clickable |
|
||||
| 매 stakeholder buy-in | v0 / Claude Artifact |
|
||||
| 매 real user feedback | Functional MVP (Lovable, Bolt) |
|
||||
| 매 demand validation | Wizard-of-Oz |
|
||||
|
||||
**기본값**: 매 2026 매 first instinct — Claude Artifact / v0. 매 1 시간에 매 stakeholder demo.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Design Process]] · [[Lean Startup]]
|
||||
- 변형: [[Wireframing]] · [[Wizard of Oz]] · [[MVP]]
|
||||
- 응용: [[User Testing]] · [[Design Sprint]]
|
||||
- Adjacent: [[Figma]] · [[v0]] · [[Claude Artifacts]] · [[Lovable]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 prototyping itself 매 LLM-native task — Claude Artifact / v0 매 prompt → working code in seconds. 매 iteration via natural language.
|
||||
**언제 X**: 매 production architecture decision — prototype 와 production 매 different concerns. 매 throw away.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Prototype → production**: 매 throwaway code 가 매 prod 로 — 매 tech debt source #1. 매 명시적 rewrite.
|
||||
- **Over-fidelity early**: 매 high-fi 부터 매 시작 — 매 sunk cost, 매 hard to throw away.
|
||||
- **No success criteria**: 매 prototype 매 무엇 validate 인지 미정 — 매 nothing learned.
|
||||
- **Too few users**: 매 1 명 testing — 매 idiosyncratic feedback.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Houde & Hill — "What Do Prototypes Prototype?" 1997; IDEO methods).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full prototyping entry with 2026 generative tools |
|
||||
|
||||
Reference in New Issue
Block a user