Development Terms

개발 과정에서 자주 사용하는 용어들을 정리했습니다.

프로토타입과 단계별 개발

POC (Proof of Concept)

개념 검증 단계입니다.

정의: 아이디어가 기술적으로 실현 가능한지 검증하는 단계입니다.

특징:

• 목적: 기술 가능성 검증
• 완성도: 10-20%
• 사용자 테스트: ❌ 없음
• 운영 준비: ❌ 미준비
• 기간: 1-2주
• 코드 품질: 매우 낮음
• 성능/확장성: 고려하지 않음

결과: 개념이 기술적으로 작동하는지만 확인합니다.

Prototype

프로토타입은 실제 제품의 초기 버전입니다.

정의: 사용자에게 제품의 외형과 기본 기능을 보여주고 피드백을 수집하는 단계입니다.

특징:

• 목적: 사용성 검증
• 완성도: 40-60%
• 사용자 테스트: ⚠️ 선정된 사용자 대상
• 운영 준비: ❌ 미준비
• 기간: 2-4주
• 코드 품질: 중간 (일부만)
• 성능/확장성: 아직 미고려
• 실제 데이터: 사용 가능

포함 요소:

• ✓ UI/UX 디자인
• ✓ 일부 기능 구현
• ✓ 기본 사용자 경험
• ✗ 모든 기능
• ✗ 성능 최적화
• ✗ 에러 처리 (완전하지 않음)

MVP (Minimum Viable Product)

최소 기능 제품입니다.

정의: 실제 사용자에게 배포 가능한 최소 기능을 갖춘 제품입니다.

특징:

• 목적: 시장 검증
• 완성도: 70-80%
• 사용자 테스트: ✓ 실제 사용자
• 운영 준비: ✓ 준비됨
• 기간: 4-8주
• 코드 품질: 높음
• 성능/확장성: 기본 고려
• 실제 데이터: 실제 사용자 데이터 처리

포함 요소:

• ✓ 핵심 기능만
• ✓ 안정적인 성능
• ✓ 기본 에러 처리
• ✓ 모니터링
• ✓ 배포 파이프라인
• ✗ 부가 기능 (추천, 고급 통계 등)
• ✗ 성능 최적화 (완전한)
• ✗ 모든 엣지 케이스 처리

유명한 MVP 사례:

• Slack: 팀 메시징 → 엔터프라이즈 협업 플랫폼
• Dropbox: 파일 동기화 → 클라우드 스토리지
• Instagram: 사진 + 필터 → 소셜 네트워크

단계별 비교

버전 관리

Version Numbers: Semantic Versioning

표준 형식: Major.Minor.Patch

예: 1.3.5

예시:

1.0.0 → 1.0.1: 버그 수정
1.0.1 → 1.1.0: 새 기능 추가 (기존 호환)
1.1.0 → 2.0.0: API 변경 (기존 코드 깨짐)

릴리스 버전 단계

Alpha (α)

초기 개발 단계입니다.

• 상태: 개발 진행 중, 기능이 불완전
• 테스터: 개발팀 + 선정된 내부 사용자
• 버그: 매우 많을 수 있음
• 버전 표기: 1.0.0-alpha 또는 1.0.0-a 또는 1.0.0-alpha.1
• 데이터 변경: 주의 (DB 스키마 변경 빈번)
• 사용 권장: ❌ 절대 금지

Beta (β)

기능은 완성되었지만 버그를 수정하는 단계입니다.

• 상태: 기능은 대부분 완성, 버그 수정 중
• 테스터: 선정된 외부 사용자들 (Beta Tester)
• 버그: 알파보다 훨씬 적음
• 버전 표기: 1.0.0-beta 또는 1.0.0-b 또는 1.0.0-beta.2
• 데이터 변경: 가능하지만 최소화
• 사용 권장: ⚠️ 신중하게 (피드백 목적이면 가능)

RC (Release Candidate)

최종 검증 단계입니다.

• 상태: 거의 완성, 최종 검증 중
• 테스터: 광범위한 외부 사용자
• 버그: 극히 드문 경우만 (Critical Bug)
• 버전 표기: 1.0.0-rc1, 1.0.0-rc.1, 1.0.0-rc2
• 데이터 변경: 거의 없음
• 사용 권장: ✓ 큰 문제 없으면 사용 가능

Stable / Release

정식 출시 버전입니다.

• 상태: 완전히 검증되고 안정적
• 버전 표기: 1.0.0 (숫자만, 추가 표기 없음)
• 지원: 공식 지원 대상
• 사용 권장: ✓✓ 권장

버전 라이프사이클

개발 중     │ 테스팅 중          │ 최종 검증  │ 출시
────────────┼────────────────────┼──────────┼─────
1.0.0-alpha → 1.0.0-beta → 1.0.0-rc1 → 1.0.0 (Stable)
   a1   a2      b1   b2     rc1  rc2

개발 주기 및 배포

Iteration

반복 개발 사이클입니다.

정의: 한 번의 완전한 개발 → 테스트 → 배포 → 피드백 사이클입니다.

특징:

• 기간: 1-4주
• 내용: 기능 단위로 개발
• 결과: 새로운 버전 배포
• 구조: 명확한 시작과 끝

Sprint

Agile 개발 방법론에서의 고정 기간입니다.

정의: 정해진 기간(보통 1-2주) 동안 정해진 작업을 완료하는 사이클입니다.

특징:

• 기간: 고정 (1주 또는 2주, 팀이 결정)
• 계획: Sprint Planning에서 일의 량 결정
• 추적: 일일 Standup으로 진행 상황 공유
• 검토: Sprint Review에서 완료된 작업 검토
• 회고: Retrospective에서 개선점 논의

Story Point: 작업의 복잡도를 나타냅니다.

1 point: 간단한 API 호출
3 point: 회원가입 검증 + DB 저장
5 point: 결제 통합
8 point: 복잡한 로직
13 point: 매우 복잡한 작업

Sprint Velocity: 팀이 한 Sprint에서 완료할 수 있는 work의 양입니다.

Release Cycle

하나의 버전이 완성되기까지의 기간입니다.

월간 릴리스: 매달 새 버전 분기별 릴리스: 3개월마다 새 버전 지속적 배포 (CD): 하루에 수십 번 배포

배포 전략

Blue-Green Deployment

두 개의 동일한 프로덕션 환경(Blue, Green)을 번갈아가며 사용합니다.

Blue (현재 운영중: v1.0.0)
Green (새 버전 준비: v1.1.0)

트래픽 전환 ← → (즉시 복귀 가능)

장점:

• ✓ 즉시 롤백 가능
• ✓ 다운타임 없음 (Zero Downtime Deployment)
• ✓ 구현이 간단

단점:

• ✗ 2배의 리소스 필요
• ✗ 데이터베이스 스키마 변경 복잡
• ✗ 두 버전이 같은 DB 공유할 경우 주의

Canary Deployment

새 버전을 일부 사용자(5-10%)에게만 먼저 배포합니다.

v1.0.0 (90% 사용자)
v1.1.0 (10% 사용자) ← 모니터링

문제 없으면 → 모두 v1.1.0로 전환

특징:

• 위험 최소화
• 실제 사용자 환경에서 테스트
• 점진적 전환

Rolling Deployment

서버를 순차적으로 업데이트합니다.

Server 1: v1.0.0 → v1.1.0
Server 2: v1.0.0 → v1.1.0
Server 3: v1.0.0 → v1.1.0

(중간에도 서비스 가능)

장점:

• ✓ 리소스 효율적
• ✓ 점진적 배포로 위험 분산
• ✓ 구현이 간단

단점:

• ✗ 배포 중 혼합 버전 실행
• ✗ 데이터베이스 스키마 변경 조심
• ✗ 롤백이 느림

Hotfix

긴급 버그 수정입니다.

v1.5.2 (Production 운영 중)
   ↓
심각한 버그 발견
   ↓
Hotfix Branch → 수정 → 테스트 → 배포
   ↓
v1.5.3 배포

일반 릴리스 사이클을 무시하고 즉시 배포합니다.

Rollback

이전 버전으로 되돌리기입니다.

현재: v1.2.0 (문제 발생)
      ↓ Rollback
복구: v1.1.5 (안정 버전)

롤백 시간:

• Blue-Green: 몇 초
• Canary: 1-2분
• Rolling: 30분-1시간

배포 전략 비교

테스트 관련 용어

Unit Test

개별 함수나 메서드를 테스트합니다.

특징:

• 범위: 한 개의 함수/메서드
• 속도: 매우 빠름 (밀리초)
• 의존성: Mock/Stub으로 제거
• 작성자: 개발자 본인

Integration Test

여러 컴포넌트가 함께 정상 작동하는지 테스트합니다.

특징:

• 범위: 여러 컴포넌트 + 실제 의존성
• 속도: 느림 (초 단위)
• 의존성: 실제 사용 또는 테스트용 인스턴스
• 작성자: 개발자 또는 QA

E2E Test (End-to-End)

사용자 관점에서 전체 흐름을 테스트합니다.

특징:

• 범위: 전체 애플리케이션 (Frontend + Backend + DB)
• 속도: 매우 느림 (분 단위)
• 의존성: 모든 실제 시스템
• 작성자: QA 또는 테스트 전문가

Smoke Test

기본 기능이 작동하는지 빠르게 확인합니다.

정의: "애플리케이션이 아예 작동하지 않나?" 수준의 빠른 검증입니다.

특징:

• 범위: 기본 기능만 (시작, 로그인, 홈페이지)
• 속도: 5-10분
• 목적: 심각한 문제 조기 발견
• 시기: 배포 직후

Regression Test

기존 기능이 여전히 정상인지 확인합니다.

정의: 새 기능 추가 후, 기존 기능에 영향이 없는지 검증하는 것입니다.

특징:

• 목적: 새 변경이 기존 기능을 깨뜨리지 않았는가
• 범위: 변경과 관련된 기존 기능들
• 자동화: 대부분 자동화됨

테스트 피라미드

테스트의 비율을 나타냅니다.

         △ E2E (5%)
        / \
       /   \     Integration (15%)
      /-----\
     /       \   Unit Tests (80%)
    /─────────\

기타 개발 용어

Feature Flag / Toggle

기능을 활성화/비활성화할 수 있는 스위치입니다.

사용 예:

• 베타 기능을 일부 사용자에게만 공개
• 버그 발견 시 긴급 비활성화
• A/B 테스트

용어 정리 한눈에 보기

개발 순서:
POC (개념) → Prototype (사용성) → MVP (시장 검증)
              ↓
         Alpha (미완성) → Beta (거의 완성) → RC (검증) → Stable (출시)
                                                        ↓
                                                  Iteration/Sprint 반복