# 폐기형 프로토타입 (Throwaway Prototyping)

## 1. 개요
**폐기형 프로토타입(Throwaway Prototyping)**이란 소프트웨어 개발 초기 단계에서 불확실한 요구사항을 확인하고 기술적 위험을 분석하기 위해 빠르게 구축한 후, 목적을 달성하면 최종 제품에 포함시키지 않고 완전히 폐기하는 프로토타이핑 모델이다.

이 방식의 핵심은 '학습'과 '검증'에 있다. 최종 제품의 품질을 보장하기 위해 정교한 설계와 코딩을 수행하기 전, 아이디어를 시각화하거나 핵심 기능을 가볍게 구현하여 고객 및 이해관계자와의 합의를 도출하는 것이 기본 원칙이다.

## 2. 목적 및 필요성
소프트웨어 개발 과정에서 가장 빈번하게 발생하는 문제는 사용자가 자신이 정확히 무엇을 원하는지 정의하지 못하거나, 개발자가 요구사항을 잘못 해석하는 경우이다.

*   **요구사항 구체화:** 추상적인 텍스트 기반의 요구사항 정의서보다 시각적인 프로토타입을 통해 사용자가 실제 동작을 확인하게 함으로써 숨겨진 요구사항을 발굴한다.
*   **리스크 식별 및 완화:** 구현 가능성이 불확실한 신기술이나 복잡한 알고리즘을 미리 테스트하여, 프로젝트 후반부에 발생할 수 있는 치명적인 기술적 결함을 조기에 발견한다.
*   **의사소통 비용 절감:** 고객과 개발자 간의 인식 차이(Gap)를 조기에 좁힘으로써, 개발 완료 후 대규모 수정이 필요한 '재작업(Rework)' 비용을 획기적으로 줄일 수 있다.

## 3. 작동 원리 및 프로세스
폐기형 프로토타입은 선형적인 흐름을 가지며, 검증이 완료되는 즉시 해당 결과물을 버리고 정식 개발 단계로 진입한다.

### 3.1 생명주기 (Lifecycle)
1.  **요구사항 수집:** 초기 단계의 대략적인 요구사항을 정의한다.
2.  **프로토타입 구축:** 빠른 구현을 위해 품질, 보안, 확장성을 배제하고 핵심 기능 위주로 빠르게 제작한다.
3.  **평가 및 피드백:** 사용자가 프로토타입을 사용해보고 수정 사항 및 개선점을 제안한다.
4.  **폐기:** 프로토타입의 결과물을 분석하여 요구사항 명세서에 반영하고, 구현체(코드)는 제품 개발 단계로 이관하지 않고 폐기한다.
5.  **실제 개발:** 확정된 요구사항을 바탕으로 표준 개발 프로세스(설계 $\rightarrow$ 구현 $\rightarrow$ 테스트)를 거쳐 최종 제품을 구축한다.

### 3.2 단계별 활동 및 산출물
| 단계 | 주요 활동 | 상세 산출물 |
| :--- | :--- | :--- |
| **요구사항 수집** | 인터뷰, 브레인스토밍, 시장 조사 | 초기 요구사항 정의서, 유즈케이스(Use Case) 초안 |
| **프로토타입 구축** | 와이어프레임 작성, Mock-up 구현, PoC 개발 | 저충실도(Low-fi) 스케치, 인터랙티브 프로토타입, [[PoC]] 코드 |
| **평가 및 피드백** | 사용자 테스트(UT), 이해관계자 리뷰 | 피드백 리포트, 요구사항 변경 요청서(CR) |
| **폐기 및 분석** | 요구사항 확정, 기술적 제약 사항 정리 | **[[SRS]](최종 요구사항 명세서)**, 기술 검토 보고서 |
| **실제 개발** | 정식 아키텍처 설계 및 코딩 | 설계 문서, 소스 코드, 테스트 결과서, 최종 제품 |

## 4. 장단점 분석
폐기형 프로토타입은 속도와 유연성에 최적화되어 있으나, 자원 투입의 중복이라는 기회비용이 발생한다.

### 4.1 장단점 요약
| 구분 | 장점 (Pros) | 단점 (Cons) |
| :--- | :--- | :--- |
| **개발 효율** | 빠른 피드백 수렴으로 방향성 수정이 용이함 | 동일한 기능을 두 번 개발하는 셈이 되어 시간/비용 중복 투입 |
| **품질 관리** | 요구사항 오류를 조기에 발견하여 최종 품질 향상 | 프로토타입 단계에서 품질(성능, 보안)을 무시하므로 오해 소지 있음 |
| **심리적 요인** | 개발자가 실패에 대한 부담 없이 과감한 시도 가능 | 고객이 프로토타입을 최종 제품으로 오인하여 빠른 출시를 압박함 |

## 5. [[진화형 프로토타입]]과의 비교
폐기형과 진화형의 가장 큰 차이는 **'결과물의 연속성'** 여부이다.

| 비교 항목 | 폐기형 프로토타입 (Throwaway) | 진화형 프로토타입 (Evolutionary) |
| :--- | :--- | :--- |
| **기본 목적** | 요구사항 확인 및 리스크 제거 | 점진적인 시스템 구축 및 발전 |
| **유지보수성** | 고려하지 않음 (빠른 구현 우선) | 매우 중요 (최종 제품이 되므로) |
| **개발 속도** | 초기 구축 속도가 매우 빠름 | 초기 설계 단계에서 시간이 더 소요됨 |
| **결과물 처리** | 검증 후 폐기 $\rightarrow$ 새로 개발 | 지속적 개선 $\rightarrow$ 최종 제품으로 진화 |
| **적용 시점** | 요구사항이 매우 불분명할 때 | 핵심 요구사항은 명확하나 세부 구현이 필요할 때 |
| **비용 관점** | 초기 비용 낮음 / 전체 공정(재개발) 비용 발생 | 초기 설계 비용 높음 / 중복 개발 비용 낮음 |

## 6. 적합한 도구 및 툴 예시
프로토타입의 충실도(Fidelity)에 따라 사용하는 도구가 달라진다.

*   **저충실도 (Low-Fidelity):** 아이디어 스케치 및 흐름 검증
    *   *도구:* 화이트보드, 포스트잇, Balsamiq, Figma(Wireframe/Lo-fi)
*   **중/고충실도 (Mid/High-Fidelity):** UI/UX 인터랙션 및 사용자 경험 검증
    *   *도구:* Figma(Interactive Prototype/Hi-fi), Adobe XD, ProtoPie, Framer
*   **기술 검증 ([[PoC]] - Proof of Concept):** 특정 기술의 구현 가능성 확인
    *   *도구:* Python(빠른 스크립팅), Jupyter Notebook, Mock 서버(Prism, Stoplight), 클라우드 샌드박스 환경

## 7. 적용 사례 및 주의사항

### 7.1 사례 연구
*   **[사례 1: UI/UX 검증 중심]**
    A사는 복잡한 금융 데이터 시각화 대시보드를 개발하며, 실제 개발 전 Figma를 이용해 폐기형 프로토타입을 제작했다. 사용자 테스트 결과, 초기 기획했던 복잡한 그래프보다 단순한 요약 표를 선호한다는 점을 발견했다. 이를 통해 잘못된 방향의 개발을 막고 개발 기간을 2개월 단축하며 최적의 사용자 경험을 설계할 수 있었다.
*   **[사례 2: 기술 검증(PoC) 중심]**
    B사는 기술 검증을 위해 Python으로 빠르게 만든 PoC 코드를 폐기하지 않고, 그대로 상용 서비스의 백엔드에 통합했다. 결과적으로 확장성과 보안이 고려되지 않은 코드가 누적되어, 사용자 증가 시 시스템이 잦은 다운타임을 겪는 심각한 **[[기술 부채]](Technical Debt)** 문제를 야기했다. 이는 프로토타입의 '폐기' 원칙을 무시했을 때 발생하는 전형적인 실패 사례이다.

### 7.2 주의사항 및 위험성
1.  **[[기술 부채]]의 위험:** 프로토타입은 '빠르게' 만드는 것이 목적이므로 코드 품질이 낮다. 이를 폐기하지 않고 제품에 반영하면 유지보수가 불가능한 스파게티 코드가 되어 장기적인 품질 저하를 초래한다.
2.  **고객의 오해:** 시각적으로 완성도 높은 프로토타입을 본 고객은 "거의 다 만들어졌으니 바로 출시하자"라고 압박할 수 있다. 개발자는 이것이 '껍데기'일 뿐이며, 실제 내부 로직 구현에는 별도의 시간이 필요함을 명확히 고지해야 한다.
3.  **과도한 투자:** 프로토타입 단계에서 너무 많은 시간을 소비하면, 본 개발 단계의 일정이 부족해지는 주객전도 현상이 발생할 수 있다. '적당한 수준'에서 멈추고 폐기하는 결단력이 필요하다.

### 7.3 프로토타입 폐기 시 갈등 해결법
프로토타입을 폐기하는 과정에서 고객이나 경영진과의 의견 충돌이 발생할 수 있으며, 다음과 같은 전략으로 해결한다.
*   **사전 합의(Contract):** 프로젝트 헌장이나 계약 단계에서 "본 프로토타입은 검증용이며 최종 제품에 포함되지 않고 폐기된다"는 점을 명문화한다.
*   **가시적 차별화:** 프로토타입 단계에서는 의도적으로 거친 디자인(Lo-fi)을 사용하여, 이것이 완성품이 아님을 시각적으로 인지시킨다.
*   **가치 중심 설득:** "지금 이 코드를 재사용하면 추후 유지보수 비용이 5배 이상 증가한다"는 점을 [[기술 부채]] 개념을 통해 논리적으로 설명하고, '재개발'이 아닌 '정식 구현'임을 강조한다.

### 7.4 실제 적용 체크리스트
프로토타입 단계에서 다음 항목을 점검하여 효율적인 폐기형 모델을 운영한다.
- [ ] **목적 명확화:** 이번 프로토타입으로 검증하려는 핵심 가설(요구사항/기술)이 무엇인지 정의되었는가?
- [ ] **범위 제한:** 전체 기능이 아닌, 불확실성이 높은 '핵심 기능'에만 집중하여 구축했는가?
- [ ] **품질 타협:** 보안, 성능, 확장성 등 비기능적 요구사항을 의도적으로 배제하여 속도를 높였는가?
- [ ] **피드백 경로:** 사용자의 피드백을 수집하고 이를 [[SRS]]에 반영할 프로세스가 마련되었는가?
- [ ] **폐기 계획:** 검증 완료 후 코드를 어떻게 처리하고, 정식 개발로 어떻게 전환할지 계획이 있는가?