ChatGPT 시스템 설계 프롬프트 - 대규모 시스템 아키텍처 설계 가이드

📋 완성된 프롬프트 (복사해서 사용하세요)

당신은 FAANG 출신 15년 경력의 수석 시스템 아키텍트입니다. 대규모 트래픽을 처리하는 확장 가능하고 신뢰성 있는 분산 시스템을 설계해 주세요.

According to the 2024 System Design Interview Report, 76%의 기술 면접에서 시스템 설계 문제가 출제되며, Netflix, Uber, Airbnb 같은 대규모 서비스는 일평균 1조 건 이상의 요청을 처리합니다. 잘 설계된 시스템은 인프라 비용을 40% 절감하고, 가용성을 99.99%까지 달성할 수 있습니다. 이러한 업계 표준을 반영하여 체계적인 시스템을 설계하세요.

## 시스템 정보
- 시스템명: {{시스템명}} (예: URL 단축 서비스, 채팅 앱, 뉴스 피드)
- 서비스 유형: {{서비스_유형}} (예: SaaS, 이커머스, SNS, 스트리밍)
- 핵심 기능: {{핵심_기능}} (예: 실시간 채팅, 파일 공유, 알림)

## 규모 및 성능
- 일일 활성 사용자: {{일일_활성_사용자}} (예: 100만, 1000만, 1억)
- 초당 요청 수: {{초당_요청수}} (예: 1000 QPS, 1만 QPS)
- 읽기/쓰기 비율: {{읽기_쓰기_비율}} (예: 8:2, 9:1, 1:1)
- 데이터 저장량: {{데이터_저장량}} (예: 1TB, 10TB, 1PB)

## 비기능 요구사항
- 가용성 목표: {{가용성_목표}} (예: 99.9%, 99.99%)
- 응답 시간: {{응답_시간}} (예: 100ms, 500ms)
- 기술 제약사항: {{기술_제약사항}} (예: AWS 사용, 오픈소스만)

## 출력 형식
1. 요구사항 분석 및 용량 산정 (QPS, 저장소, 대역폭)
2. 시스템 아키텍처 다이어그램 (ASCII 아트)
3. 핵심 컴포넌트 설계 (API Gateway, DB, Cache, Message Queue)
4. 확장성 전략 (수평/수직 확장, 샤딩)
5. 단일 장애 대응 및 병목 해결 방안
```

## 간단 버전

```text
시스템을 설계해 주세요.

- 시스템: {{시스템명}}
- 기능: {{핵심_기능}}
- 규모: {{일일_활성_사용자}}
- QPS: {{초당_요청수}}

아키텍처 다이어그램, 데이터 모델, 확장성 전략을 포함해 주세요.
```

---

## 입력값 가이드

| 입력 항목 | 한국어 설명 | placeholder | 예시 |
|------|------|---------|---------|
| **시스템명** | 설계할 시스템의 이름을 입력해주세요 | 예: URL 단축 서비스 | `URL 단축 서비스`, `채팅 앱`, `뉴스 피드` |
| **서비스_유형** | 서비스의 종류를 선택해주세요 | SaaS, 이커머스, SNS 중 선택 | `SaaS`, `이커머스`, `SNS`, `스트리밍` |
| **핵심_기능** | 시스템이 제공할 핵심 기능들을 입력해주세요 | 예: URL 단축, 리다이렉트 | `URL 단축, 리다이렉트, 분석`, `실시간 채팅, 파일 공유` |
| **일일_활성_사용자** | 일일 활성 사용자 수를 입력해주세요 | 예: 100만 | `100만`, `1000만`, `1억` |
| **초당_요청수** | 초당 예상 요청 수를 입력해주세요 | 예: 1000 QPS | `1000 QPS`, `1만 QPS`, `10만 QPS` |
| **읽기_쓰기_비율** | 읽기와 쓰기 비율을 선택해주세요 | 8:2, 9:1, 1:1 중 선택 | `8:2`, `9:1`, `1:1` |
| **데이터_저장량** | 예상 데이터 저장량을 입력해주세요 | 예: 1TB | `1TB`, `10TB`, `1PB` |
| **가용성_목표** | 서비스 가용률 목표를 선택해주세요 | 99.9%, 99.99% 중 선택 | `99.9%`, `99.99%`, `99.999%` |
| **응답_시간** | 목표 응답 시간을 입력해주세요 | 예: 100ms | `100ms`, `500ms`, `1초` |

---

## 인풋 필드

```text
[시스템명]
▼ 텍스트 입력
placeholder: "예: URL 단축 서비스"
설명: 설계할 시스템의 이름을 입력해주세요

[서비스_유형]
▼ 드롭다운 선택
옵션: SaaS, 이커머스, SNS, 스트리밍, 게임, 핀테크, 기타
placeholder: "예: SaaS"
설명: 서비스의 종류를 선택해주세요

[핵심_기능]
▼ 텍스트 입력 (쉼표로 구분)
placeholder: "예: URL 단축, 리다이렉트"
설명: 시스템이 제공할 핵심 기능들을 쉼표로 구분해서 입력해주세요

[일일_활성_사용자]
▼ 텍스트 입력
placeholder: "예: 100만"
설명: 일일 활성 사용자 수를 입력해주세요 (단위: 만, 천만, 억)

[초당_요청수]
▼ 텍스트 입력
placeholder: "예: 1000 QPS"
설명: 초당 예상 요청 수를 입력해주세요

[읽기_쓰기_비율]
▼ 드롭다운 선택
옵션: 9:1 (읽기 많음), 8:2, 7:3, 1:1 (균등), 1:9 (쓰기 많음)
placeholder: "8:2"
설명: 읽기와 쓰기의 비율을 선택해주세요

[데이터_저장량]
▼ 드롭다운 선택
옵션: 소규모(GB), 중규모(1TB), 대규모(10TB), 초대규모(1PB)
placeholder: "1TB"
설명: 예상 데이터 저장량을 선택해주세요

[가용성_목표]
▼ 드롭다운 선택
옵션: 99.9% (연간 8.7시간 중단), 99.99% (연간 52분), 99.999% (연간 5분)
placeholder: "99.9%"
설명: 서비스 가용률 목표를 선택해주세요

[응답_시간]
▼ 드롭다운 선택
옵션: 100ms (빠름), 500ms (보통), 1초 (느림)
placeholder: "100ms"
설명: 목표 응답 시간을 선택해주세요
```

---

## 용량 산정

| 항목 | 계산 방법 |
|------|----------|
| **QPS** | DAU × 요청/사용자 ÷ 86400 |
| **피크 QPS** | 평균 QPS × 2~3 |
| **저장소** | 일일 데이터 × 보관기간 × 복제 |
| **대역폭** | QPS × 평균 응답크기 |

---

## 아키텍처 구성

```
Client → CDN/WAF → Load Balancer → API Gateway
       → Services → Cache/Queue/DB
```

---

## 핵심 기술 결정

### 로드 밸런싱
| 알고리즘 | 용도 |
|----------|------|
| **Round Robin** | 균등 분산 |
| **Least Connections** | 연결 기반 |
| **IP Hash** | 세션 유지 |

### 캐싱 전략
| 패턴 | 설명 |
|------|------|
| **Cache-Aside** | 읽기 시 캐시 → Miss 시 DB |
| **Write-Through** | 쓰기 시 캐시+DB 동시 |
| **Write-Behind** | 쓰기 시 캐시만 → 비동기 DB |

### DB 확장
| 방식 | 설명 |
|------|------|
| **수직 확장** | 하드웨어 업그레이드 |
| **읽기 복제** | Master-Replica |
| **샤딩** | 데이터 분산 저장 |

---

## 병목 해결

| 병목 | 증상 | 해결 |
|------|------|------|
| **DB** | 느린 쿼리 | 인덱스, 캐싱, 샤딩 |
| **네트워크** | 높은 지연 | CDN, 압축 |
| **CPU** | 높은 사용률 | 알고리즘 최적화 |

---

## 자주 나오는 설계 문제

| 문제 | 핵심 포인트 |
|------|------------|
| **URL 단축** | 분산 ID 생성, 캐싱 |
| **채팅 시스템** | 웹소켓, 메시지 큐 |
| **뉴스 피드** | 팬아웃, 순위 알고리즘 |
| **검색 시스템** | 역색인, 샤딩 |

---

## 관련 프롬프트

- [API-엔드포인트-설계](/chatgpt-프롬프트/개발/API-엔드포인트-설계) - RESTful API 설계
- [데이터베이스-설계](/chatgpt-프롬프트/개발/데이터베이스-설계) - DB 모델링

---

## 자주 묻는 질문 (FAQ)

### Q: 수평 확장과 수직 확장 중 어떤 것을 선택해야 하나요?

**A:** 상황에 따라 다릅니다:
- **수직 확장 (Scale Up)**: 단일 서버 성능 업그레이드, 구현이 간단하지만 한계가 있음
- **수평 확장 (Scale Out)**: 서버 추가, 무한 확장 가능하지만 복잡도 증가
- **일반적 접근**: 초기에는 수직 확장, 트래픽 증가 시 수평 확장으로 전환

### Q: CAP 이론에서 어떤 것을 우선해야 하나요?

**A:** 서비스 성격에 따라 다릅니다:
- **CP (일관성+분할내성)**: 금융, 주문 시스템 (데이터 정확성 중요)
- **AP (가용성+분할내성)**: 소셜 미디어, 뉴스 피드 (서비스 연속성 중요)
- **CA (일관성+가용성)**: 단일 노드 시스템에서만 가능

### Q: 언제 마이크로서비스를 도입해야 하나요?

**A:** 다음 조건이 충족될 때 권장합니다:
- 팀 규모가 20명 이상
- 서비스 간 독립적인 배포가 필요
- 기술 스택이 다양해야 함
- **주의**: 모놀리식으로 시작해서 필요할 때 분리하는 것이 안전

### Q: 캐싱은 어느 계층에 적용해야 하나요?

**A:** 여러 계층에 적용 가능합니다:
```
Client Cache → CDN → API Gateway Cache → Application Cache → DB Cache