---
title: "41장. 요구사항과 아키텍처"
description: "서비스 블루프린트로 사용자 접점과 전면·후면 업무, 지원 시스템과 실패 복구 책임을 한 흐름에서 본다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
품질 속성과 기술 제약을 아키텍처 판단 근거로 어떻게 연결하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “품질 속성과 기술 제약을 아키텍처 판단 근거로 어떻게 연결하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
아키텍처는 요구사항이 완성된 뒤 기술팀이 별도로 만드는 구조가 아니다. 성능·가용성·보안·변경 용이성처럼 시스템 전체에 걸친 품질 기대는 초기 구조 선택을 이끌고, 선택한 구조는 다시 비용과 제약을 드러내 요구의 실현 가능성에 영향을 준다.
이 장에서는 요구사항을 아키텍처 동인과 품질 시나리오로 해석하고 주요 설계 결정을 연결한다. 충돌하는 품질 속성의 트레이드오프와 기술 제약을 명시하며, 결정 근거와 영향받는 요구를 추적해 아키텍처와 요구사항을 반복적으로 함께 검토하는 방법을 살펴본다.
### 1. 요구사항이 아키텍처에 미치는 영향
아키텍처는 기술 목록이나 상자 그림이 아니다. 시스템의 주요 책임을 어디에 배치하고, 요소가 어떤 인터페이스와 규칙으로 협력하며, 변화와 실패를 어떻게 다룰지 결정하는 구조적 선택의 집합이다. 요구사항은 그 선택을 평가하는 기준을 제공하고, 아키텍처는 요구가 실현 가능한지와 어떤 추가 제약·파생 요구가 필요한지를 되돌려 준다.
[ISO/IEC/IEEE 42010:2022](https://www.iso.org/standard/74393.html)는 관심 대상의 아키텍처와 이를 표현한 아키텍처 기술(architecture description)을 구분하고, 이해관계자의 관심사를 관점·모델과 연결하는 구조를 제시한다. 이 표준은 특정 개발 방법, 표기법이나 기술을 강제하지 않는다. 요구-아키텍처 협업에서 중요한 것은 “누구의 어떤 관심사를 이 모델이 설명하며, 어떤 결정과 근거가 남았는가”이다.
기능 요구도 구조에 영향을 준다. `FR-002`의 접수, `FR-004`의 중복 안전성, `FR-005`의 취소는 신청 상태의 책임과 일관성 경계를 묻게 한다. `FR-003`의 상태·사유 조회는 판정 이력과 공개 표현을 분리할지 결정하게 한다. `IR-001`은 규칙 서비스 실패를 자동 승인으로 우회하지 않고 보류·재평가할 수 있는 구조를 요구한다. 기능과 아키텍처를 분리해 뒤늦게 “비기능 요구를 반영”하면 핵심 상태 모델부터 다시 고칠 수 있다.
반대로 요구 문장이 특정 구조를 자동 결정하지는 않는다. `QR-001`의 p95 2초 후보가 있다고 해서 캐시, 비동기 처리, 특정 데이터베이스가 곧 정답이 되는 것은 아니다. 조회와 신청 판정의 측정 경계, 데이터 신선도, 피크 요청 분포, 실패 허용과 비용을 알아야 대안을 비교할 수 있다. 기술 이름이 요구에 들어가 있다면 법·계약·조직 역량·기존 연계 때문에 반드시 지켜야 하는 제약인지, 선호나 아직 검증되지 않은 해법인지 구분한다.
수강신청 사례의 요구-결정 사슬 후보는 다음과 같다.
화살표는 양방향이다. 예를 들어 규칙 연계가 요청 시간 안에 결과를 보장하지 못한다는 아키텍처 분석은 `IR-001`의 보류 상태, `FR-003`의 조회, 보류 적체 경보와 재평가 요구를 더 정밀하게 만든다. 그러나 설계자가 정책 권한 없이 “보류 신청이 좌석을 차지하지 않는다”고 정하면 `ASM-003`을 사실로 바꾸는 오류다. 구조가 드러낸 업무 질문은 책임자에게 되돌려야 한다.
### 2. 품질 속성
품질 속성은 시스템이 얼마나 잘 기능하는지를 여러 관점에서 설명한다. 성능, 가용성, 신뢰성, 보안, 사용성, 접근성, 유지보수성, 감사 가능성, 회복성, 개인정보 보호는 이름만 붙여서는 시험할 수 없다. 누가 어떤 상황에서 무엇을 자극했을 때, 시스템의 어느 부분이 어떤 반응을 보이고 어떻게 측정되는지를 시나리오로 만든다.
[ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html)은 ICT·소프트웨어 제품에 적용할 수 있는 제품 품질 모델을 제공한다. 품질 특성은 누락을 찾는 공통 어휘로 유용하지만 체크한 항목 수가 품질을 보장하지 않는다. 프로젝트 맥락에 맞는 관찰 가능한 요구와 측정으로 정제해야 한다. 사용자 맥락에서의 결과는 별도 품질-사용 모델과 40장의 사용성 증거도 함께 본다.
품질 속성 시나리오 `QAS-PERF-01` 후보를 작성해 보자.
| 구성 | 후보 내용 |
|---|---|
| 출처 | 피크 시간의 인증된 학생 요청 |
| 자극 | 합의된 분포로 자신의 신청 상태를 조회 |
| 환경 | 수강신청 피크, 기준 데이터량·캐시 상태·외부 연계 조건 |
| 대상 | 상태 조회 경로와 판정 기록 |
| 반응 | 권한을 확인하고 현재 상태·공개 사유·갱신 시각을 반환 |
| 측정 | 후보 p95 2초, 오류율·오래된 응답률·권한 오류 0; 실제 기준선 미확정 |
| 추적 | `QR-001`, `FR-003`, `QR-006`, `QR-011`, `DATA-DECISION-01` |
`p95 2초`만 적으면 무엇을 희생했는지 알 수 없다. 다른 학생 정보를 캐시해 노출하거나 오래된 승인 상태를 빠르게 보여 주는 것은 실패다. 성능 지표와 함께 데이터 신선도, 정확성, 인가와 오류율을 보호 지표로 둔다. 피크 트래픽 수, 요청 혼합, 워밍업, 네트워크 경계와 측정 구간이 정해지기 전에는 `QR-001` 수치를 계약·인수 기준으로 확정하지 않는다.
실패 상황의 시나리오 `QAS-REC-01` 후보도 필요하다.
| 구성 | 후보 내용 |
|---|---|
| 출처·자극 | 규칙 서비스가 실패·무효 응답·시간 초과를 반환 |
| 환경 | 신청 기간 중 판정 요청 처리 |
| 반응 | 자동 승인하지 않고 원인 코드가 있는 처리 보류로 기록, 재조회·재평가 가능 |
| 측정 | 잘못된 승인 0, 요청·결정 추적 보존, 경보·재처리 목표는 기준선 확인 필요 |
| 추적 | `IR-001`, `FR-003–FR-004`, `DR-001`, `QR-003`, `QR-009–QR-010` |
품질 속성은 서로 독립적이지 않다. 상세 로그는 감사·진단에 도움이 되지만 개인정보 최소화와 비용에 부담을 줄 수 있다. 엄격한 동기식 판정은 즉시성 이해를 단순하게 만들 수 있지만 외부 장애가 전체 접수를 막을 수 있다. 캐시는 성능과 가용성을 높일 수 있으나 규칙·좌석의 신선도를 해칠 수 있다. 상호작용이 구조적 결정을 좌우할 때 시나리오를 함께 평가한다.
모든 품질 요구를 같은 강도로 다루지 않는다. 학생의 좌석·권리·개인정보를 훼손하는 실패와 관리 화면의 사소한 지연은 위험이 다르다. 영향 규모, 복구 가능성, 노출 시간, 규제·계약, 발생 가능성과 탐지 가능성을 이용해 분석·시험 깊이를 정한다. 빈도가 낮아도 다른 학생의 신청 정보를 보는 인가 실패는 높은 우선순위일 수 있다.
### 3. 아키텍처적으로 중요한 요구사항
아키텍처적으로 중요한 요구사항(ASR)은 구조 전반에 크거나 되돌리기 어려운 영향을 주는 요구다. 주로 엄격한 품질 목표, 핵심 업무 불변조건, 외부 연계, 기술·규제 제약에서 나오지만 “비기능 요구 전체”와 같지는 않다. 평범해 보이는 기능도 상태·경합·보안 경계를 좌우하면 ASR이 된다.
ASR 후보를 찾을 때 다음을 묻는다.
- 여러 구성요소와 팀의 책임 경계를 바꾸는가?
- 데이터 일관성·보안·장애 격리 같은 전역 속성을 좌우하는가?
- 늦게 바꾸면 이관·계약·비용·운영 위험이 크게 늘어나는가?
- 기술적으로 어렵거나 경험이 부족하고, 가정이 틀릴 가능성이 큰가?
- 다른 중요한 품질과 충돌해 대안 비교가 필요한가?
- 법·정책·외부 공급자처럼 조직 밖 제약과 연결되는가?
수강신청의 ASR 목록 후보는 다음과 같다.
| ASR 후보 | 근거 요구 | 구조적 영향 | 미확인·검증 |
|---|---|---|---|
| `ASR-ENR-01` 신청 효과와 좌석의 일관성 | `FR-002`, `FR-004`, `RULE-004`, `RULE-005`, `QR-003` | 동시성 경계, 멱등 처리, 상태 전이·대사 | 우선 정책·정원 원천, 경합 시험 |
| `ASR-ENR-02` 규칙 장애에서 안전한 보류 | `IR-001`, `DR-001`, `QR-010` | 비동기 상태, 내구 기록, 재평가·관찰 | `ASM-003`, 적체·복구 목표 |
| `ASR-ENR-03` 피크 조회·신청 성능 | `QR-001`, `QR-004` | 용량, 읽기·쓰기 경로, 부하 제어 | 실제 요청 분포·환경·비용 |
| `ASR-ENR-04` 본인 상태만 공개 | `QR-006`, `QR-011`, `FR-003` | 신원·대상 인가, 데이터 최소화, 감사 | 인증 계약, 사유 공개 정책 |
| `ASR-ENR-05` 판정 재현과 감사 | `DR-001–DR-005`, `QR-009` | 규칙·입력 버전, 이력·보존, 운영 변경 | 보존 기간·열람·변조 통제 |
| `ASR-ENR-06` 접근 가능한 상태 변화 | `QR-007`, `UI-001`, `UXR-003` | 클라이언트 상태 모델·알림·시험 환경 | 대상 기술·사용자 검증 |
이 목록 역시 승인본이 아니다. `ASR-ENR-03`의 피크 규모가 작고 확장 비용이 낮다면 선택의 중요도가 달라질 수 있다. 반대로 졸업예정자 우선권 `CR-003`이 실제 정책으로 승인되면 마지막 좌석 경합과 설명 가능성이 새로운 ASR이 될 수 있다. 요구·위험·기술 발견이 바뀔 때 목록과 우선순위를 갱신한다.
ASR마다 영향을 받는 결정과 검증을 연결한다. `ASR-ENR-02`가 “메시지 큐 사용”으로 끝나면 부족하다. 처리 보류의 공식 상태가 어디에 기록되는지, 중복·순서 역전·늦은 결과를 어떻게 다루는지, 재평가 실패를 어떻게 관찰하고 누가 복구하는지 설명해야 한다. 기술 제품은 교체될 수 있지만 지켜야 할 결과와 실패 의미는 남아야 한다.
간단한 위험 실험으로 결정을 앞당길 수 있다. 예상 피크 부하에서 상태 저장 경합을 재현하고, 규칙 서비스 지연·중복 응답을 주입하며, 대량 보류를 재평가해 본다. 실험은 후보 구조의 불확실성을 줄이는 증거이지 운영 품질의 최종 보증이 아니다. 데이터·환경·버전·결과와 남은 차이를 기록한다.
### 4. 기술 제약
기술 제약은 해법 공간을 의도적으로 제한하는 조건이다. 기존 학사 시스템의 계약, 배포 환경, 조직이 지원할 수 있는 기술, 보안·접근성 표준, 데이터 거주·암호화, 공급자 API와 라이선스가 제약이 될 수 있다. “우리 팀이 익숙하다”나 “요즘 많이 쓴다”는 선호는 별도로 기록한다.
제약에는 출처, 이유, 적용 범위, 강제 수준, 유효 기간, 예외 권한과 검증을 붙인다.
| 제약 후보 | 분류 | 필요한 근거·질문 |
|---|---|---|
| `CON-001` 기존 인증 공급자의 표준 프로토콜 사용 | 외부 연계 후보 | `IR-002`의 실제 계약·버전·장애 책임은? |
| `CON-002` 결정 기록에 불필요한 개인정보 저장 금지 | 개인정보 원칙 후보 | 목적·보존·접근·파기 기준과 법무 검토는? |
| `CON-003` 기관 운영 환경에서 배포 | 조직·운영 후보 | 용량·지역·관찰·복구 능력과 지원 종료는? |
| `CON-004` 특정 DB·클라우드 제품 사용 | 기술 선택 후보 | 계약상 의무인가, 선호인가, 대안 비용은? |
모호한 제약은 아키텍처 선택을 왜곡한다. “클라우드 금지”가 실제로는 특정 학적 데이터의 외부 반출 금지인지, 모든 관리형 서비스 금지인지에 따라 대안이 다르다. “실시간 연계”도 허용 지연, 일관성, 장애 시 행동이 없으면 설계할 수 없다. 제약 원문과 권한 있는 해석을 분리해 보존한다.
요구와 제약이 충돌하면 조용히 한쪽을 무시하지 않는다. 기존 인프라가 `QR-001` 후보 부하를 감당하지 못하거나 인증 공급자의 SLA가 `QR-002` 목표보다 낮을 수 있다. 요구 완화, 용량 확장, 단계 분리, 대체 통제, 공급 계약 변경과 일정 조정을 비교해 결정권자에게 올린다. 기술팀이 비용을 이유로 사용자·정책 요구를 임의로 낮추거나, 업무팀이 물리적 한계를 무시한 수치를 확정해서는 안 된다.
제약도 생명주기를 가진다. 공급 제품 버전, 인증서, 브라우저·보조기술, 보안 기준과 가격은 바뀐다. 결정 기록에는 확인 날짜와 재검토 사건을 둔다. 39장의 시스템 변경이 발생하면 어떤 `CON`, `ASR`, `ADR`, 회귀 요구가 영향을 받는지 추적한다.
### 5. 트레이드오프
트레이드오프는 한 품질을 얻기 위해 다른 품질을 무조건 포기하는 일이 아니다. 여러 관심사가 같은 결정에 어떻게 영향을 받는지 드러내고, 위험과 비용을 포함해 허용 가능한 균형을 선택하는 과정이다. “성능 대 보안” 같은 표어보다 구체적 시나리오와 측정으로 비교한다.
[SEI의 Architecture Tradeoff Analysis Method](https://www.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method-2/)는 아키텍처가 서로 경쟁하는 품질 속성 목표에 얼마나 적합한지 이해하고 위험·민감점·트레이드오프를 찾는 구조화된 접근을 제공한다. 이 책에서는 ATAM 전체 절차를 복제하기보다 이해관계자 시나리오, 대안, 결정 근거와 위험을 연결하는 원리를 사용한다.
규칙 판정과 접수의 대안 비교 후보를 보자.
| 대안 | 기대 이점 | 위험·비용 | 지켜야 할 조건 | 확인 방법 |
|---|---|---|---|---|
| A. 판정 완료까지 동기식 응답 | 상태가 단순하고 즉시 결과 가능 | 외부 지연이 접수 실패·재시도 폭증으로 전파 | 시간 초과 시 자동 승인 없음, 요청 효과 일관성 | 지연·장애 주입, 피크 부하 |
| B. 내구 접수 후 비동기 판정 | 외부 장애 격리, 상태 조회·재평가 가능 | 보류 상태·적체·순서·운영 복잡성 | 접수≠승인 표현, `IR-001`, 늦은 결과 통제 | 상태 전이·중복·복구·UX 시험 |
| C. 규칙·좌석 캐시로 즉시 판정 | 지연·외부 호출 감소 가능 | 오래된 규칙·정원으로 잘못된 승인 가능 | 신선도·공식성·무효화와 초과 좌석 금지 | 경합·캐시 만료·대사 시험 |
표만으로 B를 채택하지 않는다. 실제 외부 지연, 허용 보류 시간, `ASM-003`, 좌석 예약 정책, 운영 역량과 비용을 확인해야 한다. 일부 조합도 가능하다. 정적에 가까운 설명 정보는 캐시하되 승인 판정은 공식 상태를 기준으로 처리하거나, 안전하게 판정할 수 없는 상황만 보류할 수 있다.
결정 기록 후보 `ADR-ENR-01`에는 다음을 둔다.
| 항목 | 기록 내용 |
|---|---|
| 상태 | 제안 / 검토 / 승인 / 대체 / 폐기 |
| 결정 질문 | 규칙 서비스 지연 중 신청 의도와 판정을 어떻게 다룰 것인가? |
| 근거 | `FR-002–FR-004`, `IR-001`, `QR-001–QR-004`, `DR-001`, UX 흐름·사용성 후보 |
| 환경·가정 | 피크 분포, 규칙 SLA, `ASM-003`, 운영 재평가 능력 |
| 대안 | 동기식 / 내구 접수·비동기 / 제한 캐시 / 조합 |
| 결과 | 선택안과 적용 범위 — 현재 미승인 |
| 절충·위험 | 성능, 일관성, 가용성, 사용성, 운영 복잡성, 비용 |
| 파생 요구 | 보류 상태, 적체 경보, 재평가, 데이터·API·화면·시험 |
| 검증·재검토 | 실험, 부하·장애·회귀시험, 가정·공급 계약 변경 시점 |
| 승인 역할과 날짜 | 미정 |
트레이드오프 기록은 기술팀 내부 메모로 끝나지 않는다. 보류 상태가 사용자의 신청 기회와 운영 업무를 바꾸면 제품·학사·지원 책임자가 참여한다. 개인정보 공개와 감사 보존은 보안·개인정보·법무 책임이 필요하다. 비용을 감당할 권한과 잔여 위험을 수용할 권한도 구분한다.
결정 뒤에는 파생 요구와 시험을 갱신한다. 비동기 판정을 택했다면 보류 상태의 데이터 생명주기, 재평가 순서, 중복·늦은 응답, 적체 경보, 사용자 안내와 운영 대사가 요구에 들어가야 한다. 기술 선택만 기록하고 이 결과를 남기지 않으면 아키텍처 지식이 구현자 머릿속에만 머문다.
완료 검토는 다음 질문으로 한다.
- 중요한 사용자·업무 관심사가 품질 시나리오로 표현됐는가?
- ASR마다 관련 요구, 구조적 영향, 대안·위험과 검증이 있는가?
- 기술 제약과 선호, 가정과 확정 사실이 구분됐는가?
- 성능·가용성 개선이 정합성·인가·개인정보·접근성을 몰래 낮추지 않는가?
- 결정에서 요구와 시험으로, 시험에서 결정 근거로 되짚을 수 있는가?
- 운영 환경과 공급자 변화가 생길 때 재검토 조건이 있는가?
이 장에서 정리한 결과는 **ASR 후보 목록**, **품질 속성 시나리오**, **요구-결정 매핑**, **기술 제약 목록**, **트레이드오프·결정 기록**이다. 어떤 구조도 아직 승인되지 않았으며 `ADR-ENR-01`은 교육용 후보이다. 42장은 이 구조가 다루는 강좌·분반·신청·수강·보류·좌석의 의미와 규칙을 도메인 지식으로 정리한다. 용어가 흔들리면 정교한 아키텍처도 서로 다른 업무를 정확하게 구현할 수 없다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 41장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
서비스 블루프린트로 사용자 접점과 전면·후면 업무, 지원 시스템과 실패 복구 책임을 한 흐름에서 본다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
학습 순서에 따라 다음 판단 주제로 이어갑니다.