이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 개인 프로젝트와 기업 운영에서 System Design의 기준은 어떻게 다른가?
- 같은 구조라도 어떤 증거, 관측, 복구 절차가 추가되어야 하는가?
- 설계 수준 차이는 성능, 정합성, 장애 격리, 운영 복잡도를 어떻게 바꾸는가?
개요
개인 프로젝트와 기업 설계는 목표가 다르다.
개인 프로젝트는 학습, 설명 가능성, 제한된 트래픽에서의 동작 검증이 중요하다.
기업 운영은 책임 분리, 관측, 장애 복구, 배포 호환성, 비용 통제가 중요하다.
같은 Spring App, DB, Redis 구조라도 문서에 남겨야 할 근거의 깊이가 다르다.
따라서 “기업처럼 모든 것을 구축하라”가 아니라 “현재 규모에서 무엇을 증명해야 하는가”를 구분해야 한다.
기준 차이
| 항목 | 개인 프로젝트 | 기업 운영 |
|---|---|---|
| 목표 | 선택 이유 설명, 학습 증명 | SLO 달성, 장애 대응, 책임 분리 |
| 트래픽 | 대략 추정과 간단한 부하 테스트 | peak, seasonality, capacity plan |
| 정합성 | 깨지면 안 되는 불변식 중심 | 보정, 감사, 재처리, 데이터 owner |
| 장애 대응 | 재현 가능한 실패 시나리오 | on-call, runbook, incident, rollback |
| 관측 | 로그와 핵심 metric | dashboard, alert, trace, SLI/SLO |
| 배포 | 수동 배포도 허용 | 무중단, migration, old/new 호환 |
| 비용 | 단순성 우선 | 용량, 라이선스, 인력, 운영 비용 |
개인 프로젝트가 낮은 수준이라는 뜻은 아니다.
규모와 책임에 맞지 않는 복잡도를 피하는 것이 더 좋은 판단일 수 있다.
같은 구조의 다른 문서화
예를 들어 주문 API에 Redis cache와 queue를 둔다고 하자.
개인 프로젝트 문서에는 다음 정도가 필요하다.
- 왜 cache가 필요한가?
- 어떤 데이터가 stale이어도 되는가?
- queue로 분리한 작업은 무엇인가?
- 실패하면 어떤 로그로 확인하는가?
- 트래픽이 늘면 무엇을 먼저 바꿀 것인가?
기업 운영 문서에는 여기에 더해 다음이 필요하다.
- cache hit ratio 목표와 eviction 알림
- stale response 허용 기준
- queue age SLO와 DLQ 처리 담당
- 장애 등급과 사용자 영향 범위
- rollback 조건과 데이터 보정 절차
- owner team과 on-call 연락 경로
구조는 같아도 증거 수준이 다르다.
개인 프로젝트의 좋은 기준
개인 프로젝트에서는 기술을 많이 넣는 것보다 선택을 설명하는 편이 낫다.
다음 질문에 답하면 충분히 강한 설계 문서가 된다.
- 왜 단일 DB로 시작했는가?
- 어떤 조건에서 cache를 넣을 것인가?
- 어떤 작업은 queue로 분리할 가치가 있는가?
- 중복 요청은 어떻게 막는가?
- 외부 API timeout은 얼마인가?
- 장애를 어떻게 재현하고 로그로 확인하는가?
예시는 작아도 된다.
현재 선택 = 단일 Spring App + MySQL
cache 생략 이유 = 상품 상세 QPS가 낮고 stale 정책이 아직 없음
queue 생략 이유 = 이메일 발송량이 작고 실패 시 수동 재시도 가능
전환 조건 = 상품 상세 p95 300ms 초과 또는 이메일 실패 월 3회 이상이렇게 남기면 단순한 구조도 설계 판단이 된다.
기업 운영의 추가 기준
기업 운영에서는 “동작한다”보다 “장애 때 책임 있게 운영할 수 있다”가 중요하다.
예를 들어 queue를 도입하면 다음이 필요하다.
- producer와 consumer owner
- message schema version
- retry 횟수와 backoff
- DLQ 처리 SLA
- consumer lag dashboard
- 재처리 도구와 감사 로그
- 배포 중 중복 처리 안전성
이 항목들은 기능 구현이 아니라 운영 안전장치다.
성능을 얻는 대신 운영 복잡도가 커진다는 사실을 문서에 드러낸다.
설계 수준을 올리는 순서
처음부터 기업 수준의 모든 장치를 넣을 필요는 없다.
다음 순서로 올리는 것이 현실적이다.
- 단일 구조에서 요구사항과 실패 상태를 명확히 한다.
- 핵심 API의 p95, error rate, DB query를 측정한다.
- 병목이 확인된 지점에 cache, queue, index를 추가한다.
- 추가한 컴포넌트의 실패 모드와 지표를 남긴다.
- 배포와 데이터 변경의 되돌림 경로를 만든다.
- owner, alert, runbook을 운영 문서로 연결한다.
이 순서는 복잡도를 요구사항과 증거에 맞춰 올리는 방식이다.
설계 축 비교
| 선택 | 개인 프로젝트에서의 의미 | 기업 운영에서의 의미 |
|---|---|---|
| Cache | 응답 속도 개선 실험 | hit ratio, stale 계약, 장애 fallback |
| Queue | 느린 작업 분리 | lag SLO, DLQ, replay, schema version |
| Replica | 읽기 부하 분리 학습 | failover, lag, read routing, 비용 |
| Circuit breaker | 외부 API 장애 방어 | threshold, fallback 품질, alert |
| Sharding | 개념 학습 수준 | rebalancing, hot shard, 운영 도구 |
기업 수준은 기능 수가 아니라 책임과 복구 가능성의 수준이다.
위험 신호
- 개인 프로젝트에서 복잡한 구조를 넣었지만 왜 필요한지 설명하지 못한다.
- 기업 설계에서 owner, alert, rollback 없이 컴포넌트만 추가한다.
- “나중에 운영에서 처리”라고 쓰고 데이터 보정 기준이 없다.
- 장애 재현과 로그 확인 없이 성공 흐름만 문서화한다.
- 비용과 인력 부담을 설계 판단에서 제외한다.
- 포트폴리오에서 기술 스택 나열이 trade-off 설명을 대신한다.
문서 예시
설계 문서에는 다음처럼 수준을 명시하면 좋다.
현재 수준: 개인 프로젝트
선택: 단일 DB + 주문 생성 idempotency key
생략: read replica, queue 기반 결제 후처리
근거: peak 20 TPS 가정, 결제 후처리 없음
전환 조건: 주문 생성 p95 300ms 초과, 외부 API 실패율 1% 초과
기업 전환 시 추가: SLO, alert, DLQ, rollback runbook이 형식은 과장 없이 현재 설계의 한계와 다음 단계를 보여준다.
확인 질문
확인 질문
- 확인 질문: 개인 프로젝트에서 좋은 System Design 문서는 무엇을 증명해야 하는가?
- 답변: 모든 운영 장치를 갖추는 것이 아니라 선택 이유, 생략 이유, 전환 조건, 실패 재현 가능성을 증명해야 한다.
- 확인 질문: 기업 운영에서 같은 구조에 추가로 필요한 것은 무엇인가?
- 답변: SLO, owner, alert, rollback, 재처리, 데이터 보정, 배포 호환성 같은 운영 책임이다.
- 확인 질문: 설계 수준을 올리면 어떤 축이 바뀌는가?
- 답변: 장애 격리와 복구 가능성은 좋아지지만 관측, 배포, 비용, on-call 같은 운영 복잡도가 증가한다.