이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Constraint와 Assumption을 어떻게 구분하고 질문해야 하는가?
- 검증되지 않은 가정을 설계 위험으로 어떻게 기록하는가?
- 제약과 가정 분리는 성능, 정합성, 장애 격리, 운영 복잡도 판단을 어떻게 바꾸는가?
개요
Constraint는 설계가 반드시 지켜야 하는 조건이다.
Assumption은 아직 확정되지 않았지만 설계를 진행하기 위해 임시로 두는 전제다.
둘을 섞으면 위험하다.
예를 들어 “월 100만 사용자”는 아직 검증되지 않은 가정일 수 있다.
반면 “개인정보는 5년 보존해야 한다”는 법무나 정책에서 온 제약일 수 있다.
가정을 제약처럼 다루면 과설계가 되고, 제약을 가정처럼 다루면 나중에 설계를 크게 되돌려야 한다.
구분 기준
| 항목 | Constraint | Assumption |
|---|---|---|
| 출처 | 법규, 계약, 정책, 예산, 기술 표준 | 추정, 경험, 초기 인터뷰, 임시 수치 |
| 변경 가능성 | 낮음 | 검증 후 바뀔 수 있음 |
| 문서 표현 | 반드시, 최소, 금지, 준수 | 가정, 예상, 임시, 검증 필요 |
| 설계 영향 | 선택지를 제한 | 위험과 검증 계획을 만든다 |
| 예시 | PII 암호화, 5년 보존, AWS 사용 | peak 1,000 QPS, read 90%, MAU 100만 |
이 구분은 설계 자유도를 결정한다.
제약은 선택지를 줄이고, 가정은 검증 전까지의 임시 설계를 만든다.
질문법
요구사항 리뷰에서 다음처럼 묻는다.
- 이 조건은 누가 결정했는가?
- 바뀔 수 있는가?
- 바뀐다면 어떤 설계가 깨지는가?
- 숫자의 근거는 실제 데이터인가, 추정인가?
- 언제 어떤 지표로 검증할 것인가?
- 검증 전에는 얼마나 보수적으로 설계할 것인가?
질문은 공격이 아니라 위험을 분리하는 일이다.
질문 없이 “그럴 것 같다”를 설계에 넣으면 나중에 장애나 비용으로 돌아온다.
알림 시스템 예시
제약:
- SMS 발송 이력은 1년 보존한다.
- 수신 거부 사용자는 발송 대상에서 제외해야 한다.
- 월 클라우드 비용은 300만원을 넘기지 않는다.
- 메시지 본문에는 민감정보를 저장하지 않는다.
가정:
- 캠페인당 최대 대상자는 100만 명이다.
- 피크 발송은 초당 500건이다.
- 수신 거부 비율은 5% 이하다.
- provider timeout은 전체 요청의 1% 미만이다.위 항목은 같은 요구사항처럼 보여도 설계에서 다르게 다뤄야 한다.
보존과 민감정보는 반드시 지켜야 하므로 저장소와 audit 설계를 제한한다.
대상자 수와 timeout 비율은 검증 계획을 둬야 한다.
가정 검증 계획
가정은 반드시 검증 계획과 함께 적는다.
| 가정 | 위험 | 검증 방법 | 검증 전 완화 |
|---|---|---|---|
| 캠페인당 100만 명 | worker와 DB 용량 부족 | 과거 캠페인 데이터 확인 | batch size 제한 |
| 초당 500건 발송 | provider rate limit 초과 | provider 계약 확인 | throttling 설정 |
| 수신 거부 5% 이하 | 대상 필터링 비용 과소평가 | 최근 3개월 통계 | index와 cache 검토 |
| timeout 1% 미만 | retry 폭주 가능 | provider metric 수집 | retry budget 제한 |
이 표가 있으면 가정이 틀려도 설계를 조정할 수 있다.
없으면 가정이 사실처럼 굳어져 장애 때 원인을 찾기 어렵다.
제약이 설계를 바꾸는 방식
제약은 선택지를 줄인다.
예를 들어 “민감정보를 메시지 본문에 저장하지 않는다”는 제약이 있으면 다음 선택이 필요하다.
- 메시지 본문에는 template id와 변수 key만 저장한다.
- 실제 민감정보는 발송 직전 권한 있는 서비스에서 조회한다.
- 발송 로그에는 masking된 값만 남긴다.
- 재처리 시 원본 값을 복원할 수 있는지 별도로 판단한다.
이 제약은 보안과 정합성은 강화하지만 발송 latency와 운영 복잡도를 늘릴 수 있다.
가정이 설계를 바꾸는 방식
가정은 설계를 임시로 가능하게 한다.
예를 들어 “peak 500 msg/sec”를 가정하면 worker와 broker capacity를 그 수준에 맞춘다.
하지만 실제 peak가 5,000 msg/sec라면 queue age가 급증하고 provider rate limit에 막힐 수 있다.
따라서 가정 기반 설계에는 전환 조건이 필요하다.
가정: peak 500 msg/sec
관측: queue age p95가 60초 초과하거나 provider limit 사용률 80% 초과
전환: provider quota 증설, worker 증설, campaign throttling 적용질문을 API 계약으로 연결
Constraint와 assumption은 API에도 드러난다.
{
"campaignId": "cmp-1001",
"status": "ACCEPTED",
"acceptedRecipients": 850000,
"rejectedRecipients": 150000,
"rejectionReason": "UNSUBSCRIBED_OR_POLICY_RESTRICTED",
"dispatchPolicy": "THROTTLED_BY_PROVIDER_LIMIT"
}수신 거부 제외는 제약에서 온 기능 계약이다.
provider limit 때문에 throttling되는 것은 가정과 외부 제약이 만나는 지점이다.
위험 신호
- “대략”, “아마”, “보통” 같은 표현이 설계 결론에 들어간다.
- 법규나 보안 요구를 나중에 확인하겠다고 둔다.
- 트래픽 가정을 검증할 metric이 없다.
- 비용 제약이 있는데 scale out 전략만 쓴다.
- 외부 provider limit을 모른 채 처리량 목표를 정한다.
- 가정이 틀렸을 때의 전환 조건이 없다.
개인 프로젝트 기준
개인 프로젝트에서도 제약과 가정은 분리한다.
- 제약: 무료 tier, 단일 DB, 배포 환경, 학습 기간
- 가정: 사용자 수, QPS, 데이터 증가량, 외부 API 안정성
- 검증: 간단한 부하 테스트, 로그, 수동 장애 재현
작은 프로젝트에서 이 분리가 있으면 과장 없이 설계 한계를 설명할 수 있다.
기업 운영 기준
기업에서는 제약의 출처와 승인자가 중요하다.
- 법무, 보안, 인프라, 비용, 제품 owner 중 누가 결정했는가?
- 제약 변경 시 어떤 문서와 배포가 바뀌는가?
- 가정 검증은 어느 milestone까지 끝낼 것인가?
- 검증 실패 시 어떤 fallback 설계를 적용할 것인가?
- 위험을 누가 accept했는가?
이 기록이 없으면 설계 리뷰에서 합의한 내용이 운영 중 사라진다.
확인 질문
확인 질문
- 확인 질문: Constraint와 Assumption의 가장 중요한 차이는 무엇인가?
- 답변: Constraint는 반드시 지켜야 하는 조건이고, Assumption은 검증 후 바뀔 수 있는 임시 전제다.
- 확인 질문: 가정에는 왜 검증 계획이 필요할까?
- 답변: 가정이 틀렸을 때 성능, 비용, 정합성, 장애 격리 설계가 깨질 수 있으므로 관측과 전환 조건이 필요하다.
- 확인 질문: 제약과 가정 분리가 바꾸는 설계 축은 무엇인가?
- 답변: 불확실성을 관리해 정합성과 운영 판단은 선명해지지만, 검증 일정과 위험 추적이라는 운영 복잡도가 생긴다.