요구사항과 ADR로 설계를 고정하기

---

이 글의 결론

시스템 설계의 성패는 ‘무엇을 만들지’가 아니라, ‘무엇을 반드시 결정해야 하는지’를 얼마나 빨리 고정하느냐에 달려 있다.

---

왜 요구사항과 ADR이 출발점인가

아키텍처는 기술 선택의 문제가 아니라, 요구사항이 강제한 선택의 결과다.

왜

대규모 시스템 설계에서 실패하는 가장 흔한 이유는 “기술을 먼저 고르고 요구사항을 끼워 맞추는 것”이다. 이 방식은 설계자가 판단을 유예한 채, 익숙한 기술 스택 뒤로 숨게 만든다.
요구사항은 설명이 아니라 결정을 요구한다. 결정이 없으면 아키텍처도 없다.

무엇

• 요구사항: 시스템이 반드시 만족해야 하는 조건의 집합
• 아키텍처 다이렉트 드라이버(ADR): 설계 선택을 강제로 유도하는 요구사항 일부

어떻게

1. 요구사항을 기능/품질/제약으로 분리한다.
2. 그중 선택지를 제거하는 항목만 추린다.
3. 그 항목을 ADR로 선언하고, 이후 모든 설계를 이에 종속시킨다.

---

요구사항의 3종 분류와 흔한 혼동

요구사항을 섞어 말하는 순간, 설계는 감으로 변한다.

요구사항 3종

• 기능 요구사항: 시스템이 무엇을 하는가
• 품질 요구사항: 어떤 특성으로 동작해야 하는가
• 제약 사항: 선택할 수 없는 것

흔한 혼동 사례 5가지

1. “응답이 빨라야 한다” → 품질 요구사항 (성능)
2. “Redis를 써야 한다” → 제약 (기술 선택 강제)
3. “확장 가능해야 한다” → 품질 요구사항 (확장성)
4. “주문을 처리한다” → 기능 요구사항
5. “트래픽이 많다” → 요구사항 아님 (조건 설명일 뿐, 수치 없음)

---

아키텍처 다이렉트 드라이버(ADR)

ADR은 ‘설계 논쟁을 끝내는 문장’이다.

정의

ADR이란, 해당 요구사항을 만족하지 않으면 설계가 실패했다고 말할 수 있는 항목이다.

드라이버가 되기 위한 조건

• 결정이 강제되는가?
• 선택지를 실제로 제거하는가?
• 다른 요구사항과 충돌 가능한가?
• “그래도 된다”라는 말이 불가능한가?

---

예시 1: URL 단축기 (Toy)

요구사항 분류

구분	내용
기능	URL을 단축하고 리다이렉트
품질	초당 10K 리다이렉트 처리
제약	단일 리전 배포

ADR 추출 과정

• “초당 10K” → 캐시 필수 → DB 직접 조회 불가
• “단일 리전” → 글로벌 CDN 고려 불필요

최종 ADR

1. 읽기 요청은 캐시 우선 처리
2. 쓰기보다 읽기 최적화
3. 단일 리전 기준 장애 허용 범위 정의

---

예시 2: 커머스 주문/결제 시스템 (실무형)

요구사항 분류

구분	내용
기능	주문 생성, 결제 요청, 결제 확정
품질	중복 결제 불가, 99.99% 결제 신뢰성
제약	외부 PG 연동 필수, 금융 로그 5년 보관

ADR 추출 과정

• “중복 결제 불가” → 멱등성 키 필수
• “99.99% 신뢰성” → 동기 실패 시 재시도 설계
• “금융 로그 5년” → 이벤트 소싱 또는 감사 로그 필수

최종 ADR

1. 모든 결제 요청은 멱등성 키 기반
2. 결제 상태는 단일 소스 오브 트루스 유지
3. 외부 PG 장애를 내부 상태로 흡수

---

요구사항 질문 리스트 (면접용)

좋은 질문은 기술을 쓰지 않고도 설계를 흔든다.

기능 (6)

• 사용자는 정확히 어떤 행동을 할 수 있는가?
• 실패 시 사용자에게 무엇을 보장해야 하는가?

품질 (6)

• 허용 가능한 지연 시간은?
• 데이터 정합성은 강/약 중 무엇인가?

제약 (6)

• 반드시 써야 하거나 쓸 수 없는 기술은?
• 법/보안/조직 제약은 무엇인가?

---

면접에서 자주 깨지는 포인트 5개

1. 요구사항 확정 전에 기술 스택부터 말함
2. 수치 없는 품질 요구사항
3. 제약을 “취향”으로 처리
4. ADR 없이 컴포넌트 다이어그램 그림
5. 트레이드오프를 말하지 않음

---

결과물 템플릿

(a) 요구사항 표

| 구분 | 요구사항 | 수치/조건 |
| ---- | -------- | --------- |
|      |          |           |

(b) ADR 리스트

| ADR | 강제 이유 | 영향 영역 |
| --- | --------- | --------- |
|     |           |           |

(c) 선택 문장 템플릿

• 우리는 일관성을 위해 동기 처리를 선택한다.
• 우리는 확장성을 위해 비동기 이벤트를 선택한다. (총 10개 작성 가능)

---

재학습 체크리스트 (10)

• ADR 없이 설계를 시작하지 않았는가?
• 모든 품질 요구사항에 수치가 있는가?
• 제약을 명시적으로 적었는가?

---

10분 훈련 루틴 (7일)

• Day 1–2: 요구사항 분류 연습
• Day 3–4: ADR 추출만 연습
• Day 5–6: 선택 문장 작성
• Day 7: 전체 타이머 10분 실전

---

한 줄 요약

설계는 기술 설명이 아니라, 요구사항이 강제한 결정의 기록이다.

---

• 참고: 소프트웨어 아키텍처 및 대규모 시스템 설계