33장. 요구사항에서 시스템 설계로

기능·품질·데이터·인터페이스 요구를 컴포넌트 책임과 상호작용에 할당하고 설계 근거를 보존한다.

이번 장에서 해결할 질문

학습 목표

• “요구가 아키텍처 결정을 제약하는 지점과 설계 선택인 지점을 어떻게 구분하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구사항은 시스템이 달성해야 할 결과를 말하지만 그 결과를 어떤 구조와 책임 분담으로 실현할지는 설계에서 결정한다. 기능만 따라 구성요소를 나누면 성능·가용성·보안 같은 품질 요구가 뒤늦게 구조를 흔들고, 반대로 익숙한 아키텍처를 먼저 선택하면 요구가 설계에 끌려갈 수 있다.

이 장에서는 기능·품질·데이터·인터페이스 요구를 아키텍처 동인아키텍처 동인시스템 구조 선택에 큰 영향을 주는 핵심 기능·품질·제약 요구사항이다.으로 해석하고 시스템 책임을 구성요소에 할당한다. 여러 설계 대안과 트레이드오프를 요구 근거로 비교하며, 결정과 가정·위험을 추적해 요구 변경이 시스템 구조에 미치는 영향을 설명하는 방법을 다룬다.

1. 요구사항과 아키텍처

요구사항에서 시스템 설계로 넘어갈 때 가장 먼저 버려야 할 생각은 “요구사항 하나에 화면 하나, API 하나, 테이블 하나를 붙이면 설계가 된다”는 식의 일대일 대응이다. 하나의 품질 요구는 여러 컴포넌트에 걸친 전술을 필요로 하고, 하나의 컴포넌트는 여러 기능을 함께 맡을 수 있다. 요구사항은 설계가 만족해야 할 필요와 제약을 말하고, 설계는 그 필요를 실현하는 책임·상호작용·데이터·기술 선택을 설명한다.

ISO/IEC/IEEE 42010는 시스템의 아키텍처와 아키텍처 설명을 구분한다. 도표가 곧 아키텍처인 것이 아니라 이해관계자의 관심사를 어떤 관점으로 표현했는지, 요소와 관계에 어떤 근거가 있는지를 함께 다뤄야 한다. 따라서 이 장에서 만드는 컴포넌트와 인터페이스는 실제 배포 구조를 확정한 그림이 아니라 앞 장의 요구 후보를 검증하기 위한 교육용 설계 후보다. 실제 이해관계자 승인 기준선과 운영 환경 자료가 없으므로 CMP, API, DATA, ADR 식별자에는 모두 후보 상태가 붙는다.

요구사항은 설계를 제약하지만 단 하나의 해답을 지시하지 않는다. FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.의 상태·사유 조회는 단일 애플리케이션, 모듈형 단일체, 여러 서비스 가운데 어느 구조로도 구현할 수 있다. 반대로 “마이크로서비스를 쓴다”는 선택은 사용자의 필요가 아니다. 독립 배포, 조직 경계, 장애 격리, 부하 차이 같은 근거가 확인될 때만 설계 대안으로 정당화된다.

설계 전환은 다음 네 질문으로 시작한다.

1. 어떤 기능이 어떤 상태와 결정을 공식적으로 소유하는가?
2. 품질 시나리오를 만족하려면 어디에 시간 제한, 중복 안전성, 격리와 관찰 지점을 두어야 하는가?
3. 외부 연계가 실패했을 때 어떤 결과까지 안전하게 제공할 수 있는가?
4. 이 구조에서 요구 변경의 영향을 어느 컴포넌트·계약·데이터·시험까지 역추적할 수 있는가?

G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.→UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.→FR-001–FR-005FR-001–FR-005FR-001: 학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. · FR-002: 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. · FR-003: 인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. · FR-004: 같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다. · FR-005: 신청·판정 이력., QR-001–QR-011QR-001–QR-011QR-001: 합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다. · QR-002: 핵심 업무 99.9% 가용 후보. · QR-003: 동시 신청 경쟁. · QR-004: 기준 요청량 2배 후보. · QR-005: 다른 학생 객체 접근. · QR-006: 대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다 · QR-007: 적용 접근성 기준 미정. · QR-008: 승인된 규칙 변경의 영향받는 요구·설계·시험·계약·운영 자료를 추적하고 정한 시간 안에 갱신·검증할 수 있어야 한다 · QR-009: 권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다 · QR-010: 정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다 · QR-011: 목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다, IR-001–IR-006IR-001–IR-006IR-001: 자격·운영 흐름. · IR-002: 주체 인증·세션 정보. · IR-003: 학생·강좌·이수 원천. · IR-004: 규칙 결과·사유·버전 제공. · IR-005: 최소 정보·재시도·공식 조회 연결. · IR-006: 합의 형식·전달.의 연결을 설계 입력으로 삼는다. 다만 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.과 QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 수치는 기준선·부하 환경이 확인되지 않은 목표이고, RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.와 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.의 졸업 예정자 우선권도 승인되지 않았다. 설계가 이 미결 정책을 코드 구조나 데이터 열로 먼저 확정해서는 안 된다.

2. 기능 할당

기능 할당은 화면 이름을 서버 모듈 이름으로 바꾸는 작업이 아니다. 기능이 어떤 결정을 내리고 어떤 상태를 바꾸며 어떤 근거를 남기는지에 따라 책임을 묶는다. 31장31장. 요구사항에서 기능으로상위 요구를 사용자 가치가 보존되는 기능 단위로 어떻게 분해하는가?페이지로 이동에서 도출한 기능 후보를 다음과 같이 할당한다.

여기서 신청 접수와 자격 판정을 분리하는 이유는 실패 의미가 다르기 때문이다. 접수 성공은 사용자의 의도가 내구성 있게 기록됐다는 뜻이지 승인됐다는 뜻이 아니다. 규칙 서비스가 응답하지 않으면 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.에 따라 자동 승인하지 않고 보류 상태와 원인 코드를 남겨야 한다. 두 책임을 하나의 불투명한 호출로 합치면 응답 유실 때 접수 여부를 알기 어렵고, 재시도에서 중복 처리가 생기기 쉽다.

기능 간 호출 방향만 그리지 말고 사건과 상태 전이도 기록한다. FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영.이 신청을 접수하면 FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정.이 판정을 시도하고, 결과가 있으면 FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회.에서 조회할 공식 상태에 반영한다. 알림은 그 뒤의 보조 반응이다. 알림 실패가 승인·거절 결정을 되돌리지 않으며, 알림 성공이 판정 성공을 대신하지 않는다.

할당표를 역으로 읽으면 빠진 책임이 드러난다. FR-004FR-004 · 기능 요구같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다.가 중복 안전성을 요구하는데 요청 식별자와 기존 결과를 누가 보존하는지 없다면 설계가 불완전하다. QR-009QR-009 · 품질 요구권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다가 감사 가능성을 요구하는데 운영자가 변경한 이유를 어느 데이터가 남기는지 없다면 컴포넌트 수가 많아도 요구를 만족하지 못한다.

3. 컴포넌트

컴포넌트는 우선 배포 단위가 아니라 변경 이유와 상태 책임이 비슷한 논리적 경계로 잡는다. 이후 조직·부하·가용성·배포 독립성 근거가 모이면 한 프로세스 안의 모듈로 둘지 독립 서비스로 둘지 결정한다.

CMP-STATUS-01CMP-STATUS-01 · 구성요소공식 상태·공개 사유 조회.을 별도 논리 책임으로 둔다고 해서 별도 데이터베이스나 서비스가 즉시 필요한 것은 아니다. 조회 부하가 신청 명령보다 훨씬 크고 독립 확장이 필요하다는 측정이 나오면 읽기 모델을 검토할 수 있다. 그때도 사용자가 보는 상태가 얼마나 늦을 수 있는지, 최신 판정과 충돌할 때 무엇을 기준으로 삼을지, 지연을 어떻게 표시할지 먼저 합의한다.

컴포넌트 경계에는 불변조건을 적는다.

• 동일한 신청 의도는 재전송돼도 유효한 신청으로 여러 번 반영되지 않는다.
• 승인 상태는 규칙 판정과 좌석 반영이 정한 일관성 경계를 통과한 뒤에만 만들어진다.
• 규칙 실패·무효 응답·시간 초과는 승인으로 해석되지 않는다.
• 현재 상태는 이력과 모순되지 않으며 늦은 응답이 더 새로운 전이를 덮지 않는다.
• 운영 조치는 주체·사유·대상·전후 상태와 함께 감사된다.

분산 트랜잭션을 피한다는 구호만으로 일관성을 포기하지 않는다. 좌석 차감과 승인 기록이 다른 경계에 있다면 예약, 조건부 갱신, 보상 가운데 어떤 방식으로 “좌석 초과 승인 없음”을 지킬지 증명해야 한다. ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.이 해결되지 않은 현재는 우선 배정과 좌석 경합의 최종 알고리즘을 확정할 수 없다. DEC-001DEC-001 · 의사결정정원·우선 처리의 결정 후보.도 승인된 결정이 아니라 검토 중인 기록이다.

컴포넌트 산출물은 요구-컴포넌트 매핑과 책임 카드다. 카드에는 입력, 출력, 소유 상태, 불변조건, 의존성, 실패 의미, 관찰 지점과 연결 시험을 포함한다. 상자 이름만 있는 그림보다 이 카드가 설계 검토에 더 유용하다.

4. API

API는 화면 필드를 그대로 주고받는 통로가 아니라 책임 경계 사이의 계약이다. 호출자는 성공·실패·시간 초과·중복·버전 충돌을 구분할 수 있어야 하고, 제공자는 인증·인가·검증과 오류 의미를 일관되게 지켜야 한다.

API-ENROLL-01API-ENROLL-01 · API 설계신청 의도 접수.의 성공 응답은 승인 여부가 아니라 접수 계약을 표현한다. 응답이 유실됐을 때 클라이언트는 같은 요청 ID로 결과를 조회하거나 재전송할 수 있어야 한다. 서버는 요청 ID의 유효 범위, 동일성 판단에 포함할 필드, 보존 기간과 충돌 응답을 정의한다. 같은 키에 다른 강좌를 넣은 요청을 기존 성공으로 돌려주는 식의 잘못된 중복 처리는 금지한다.

API-STATUS-01API-STATUS-01 · API 설계공식 상태·사유 조회.은 화면 문구가 아니라 안정된 상태·사유 의미를 제공한다. 사람용 설명은 지역화될 수 있지만 상태 코드와 사유 코드는 버전 관리한다. 내부 예외 문자열을 공개 사유로 보내지 않고, 지원이 필요한 경우 개인정보를 포함하지 않는 상관 ID를 제공한다. 캐시를 사용한다면 응답 시각·데이터 버전과 허용 지연을 계약에 포함한다.

시간 제한은 호출마다 임의로 두지 않는다. 사용자 응답 예산, 외부 연계 특성, 재시도 횟수, 큐 대기와 서버 처리 시간을 함께 배분한다. 규칙 호출을 세 번 재시도한 결과 p95 목표를 초과하고 동시 장애를 증폭한다면 회복 전술이 아니다. 지수형 지연, 회로 차단, 동시 요청 제한, 격리 큐를 후보로 비교하고 실제 장애·부하 시험으로 조정한다.

API 버전은 URL 숫자만의 문제가 아니다. 필드 의미, 필수성, 상태 전이와 오류 분류의 호환성을 관리한다. 소비자·제공자 계약 시험을 두고, 폐기 일정과 관찰 지표를 기록한다. 승인되지 않은 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. 때문에 우선순위 필드를 공개 계약에 미리 추가하지 않는다. 정책이 승인되면 사유 공개 범위와 데이터 최소화를 함께 검토한다.

5. 데이터

데이터 설계는 화면 표를 저장할 열로 옮기는 일이 아니라 업무 사실, 현재 상태, 판정 근거와 보존 책임을 정의하는 일이다. 같은 “상태”라도 신청 생명주기, 규칙 판정, 알림 전달 상태는 서로 다른 사실이다.

DATA-APPLICATION-01DATA-APPLICATION-01 · 데이터 설계신청 ID, 주체, 대상, 요청 ID, 현재 상태·버전.의 현재 상태만 저장하면 과거 판정의 근거와 늦은 응답 경합을 설명하기 어렵다. 모든 것을 무기한 사건으로 저장하는 것도 정답은 아니다. 필요한 이력, 스냅숏, 파생 현재 상태를 구분하고 DR-004DR-004 · 데이터 요구현재 상태와 변경 이력이 모순되지 않게 유지한다, QR-009QR-009 · 품질 요구권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다, QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다에 맞춰 보존·파기·접근 정책을 결정한다.

규칙 판정에는 “지금 조회한 학생 정보”가 아니라 판정에 실제 사용한 입력의 기준선이 필요하다. 학적·이수·신청·강좌 상태가 서로 다른 시점이면 재현성이 무너진다. DR-003DR-003 · 데이터 요구학생·강좌·규칙 입력의 원천과 기준 시점을 판정에 연결한다은 데이터 항목, 원천 버전, 조회 시각과 일관성 경계를 정하도록 요구한다. 전체 개인정보 복사본을 남기기보다 필요한 사실의 버전 참조나 최소 스냅숏을 선택하고, 원천 정정이 과거 판정과 재평가에 미치는 영향도 기록한다.

좌석 수는 특히 기준이 중요하다. 검색용 캐시의 잔여 좌석은 안내에는 쓸 수 있어도 최종 승인 기준으로 그대로 사용할 수 없다. 동시 신청에서 음수 좌석이나 초과 승인이 생기지 않도록 조건부 갱신·직렬화·예약 같은 대안을 비교한다. 좌석을 보류 신청이 점유하는지는 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?이 아직 확인되지 않았으므로 데이터 모델에 확정하지 않는다.

개인정보 최소화는 열을 줄이는 것에 그치지 않는다. 로그, 추적 ID, 메시지 큐, 분석 사본, 백업과 시험 데이터까지 흐름을 따라간다. 민감 사유를 알림 본문이나 URL에 넣지 않고, 운영자가 볼 수 있는 내부 사유와 학생에게 공개할 사유를 분리한다. 삭제 요청과 법정 보존이 충돌할 때의 책임자는 실제 정책 확인이 필요하다.

6. 외부 연계

외부 연계는 “호출 성공”뿐 아니라 데이터 기준, 응답 지연, 부분 실패, 버전과 운영 책임을 계약해야 한다. 수강신청 후보는 인증, 학사정보, 규칙, 알림과 파일 이관 연계에 의존한다.

연계 계약에는 소유자, 지원 시간, 용량, 시간 제한, 재시도 가능 오류, 중복 의미, 순서, 스키마 버전, 개인정보 등급, 관찰 지표와 비상 연락 절차를 둔다. “REST로 연계한다”는 기술 표현만으로는 이런 책임을 설명하지 못한다.

규칙 서비스가 느릴 때 내부 신청 처리를 같은 시간 동안 붙잡아 둘지, 접수를 먼저 내구성 있게 남기고 비동기 판정할지 비교한다. 피크 시간, 허용 판정 지연과 사용자 기대가 없으면 확정할 수 없다. 현재 후보에서는 접수 여부를 분명히 하고 판정이 끝나지 않으면 보류로 조회 가능하게 하는 방향이 FR-002FR-002 · 기능 요구인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다., FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름.을 함께 만족시키기 쉽다. 다만 좌석의 점유 시점과 공정성 정책이 결정돼야 세부 순서를 정할 수 있다.

외부 응답은 신뢰 경계 밖의 입력이다. 성공 코드라도 필수 필드, 규칙 버전, 사유 값과 서명을 검증하고, 예상하지 못한 값은 승인으로 변환하지 않는다. 장애 중 운영자가 CSV로 결과를 덮어쓰는 우회 절차도 별도 요구·권한·감사·대사 없이 허용하지 않는다.

연계 시험은 모의 성공 응답만으로 끝내지 않는다. 지연, 중복, 순서 뒤바뀜, 부분 필드, 이전 버전, 연결 단절과 회복 뒤 폭주를 포함한다. 연계 소유자와 함께 계약 예제를 검토하고 운영 대시보드에서 어떤 신호로 문제를 구별할지도 정의한다.

7. 기술 제약

기술 제약은 조직이 반드시 따라야 하는 플랫폼·법규·운영 환경과, 설계자가 선호하는 선택을 구분한다. 지원 브라우저, 배포 창, 기존 인증 체계, 데이터 위치, 암호화 기준, 접근성 준수 범위가 실제 제약일 수 있다. 특정 프레임워크나 메시지 브로커는 근거가 확인되지 않으면 대안일 뿐이다.

ISO/IEC 25010의 제품 품질 모델은 요구 도출, 설계 목표, 시험 목표와 수용 기준을 연결하는 데 사용할 수 있다. 품질 특성을 이름으로만 적지 않고 관찰 가능한 시나리오로 내린다. SEI가 제시한 품질 속성 시나리오의 여섯 요소인 원천, 자극, 환경, 대상, 반응, 측정값을 사용하면 다음과 같이 설계 전술을 비교할 수 있다.

수치가 없는 시나리오는 아직 수용 기준이 아니다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 p95 2초도 동시 사용자, 데이터량, 네트워크 위치, 캐시 상태와 측정 구간을 정해야 의미가 있다. 가용성·복구 목표 역시 업무 시간과 허용 데이터 손실을 확인한 뒤 정량화한다.

신청 처리 구조는 세 대안으로 비교할 수 있다.

현재 증거로는 세 번째 혼합 대안을 우선 검토할 수 있다. 접수 상태를 내구성 있게 만들고, 규칙 판정은 시간 제한 안에 완료되면 즉시 반영하되 미완료면 보류와 재평가로 넘긴다. 알림은 상태 변경 뒤 비동기로 분리한다. 이것은 권고 후보이지 승인된 구조가 아니다. 좌석 점유 시점, 허용 대기 시간, 피크 부하와 운영 지원 능력이 확인되면 다시 비교한다.

설계 결정 기록 후보 ADR-ENR-001ADR-ENR-001 · 아키텍처 결정 기록내구 접수·보류 구조 선택이 바뀌는가?은 다음처럼 남긴다.

ADR-ENR-002ADR-ENR-002 · 아키텍처 결정 기록상태 조회 캐시는 후보로 별도 관리한다.는 상태 조회 캐시의 사용 범위를 기록한다. 검색·설명용 읽기 성능은 캐시로 개선할 수 있지만 승인·좌석·최종 상태의 기준을 캐시가 대신하지 않도록 한다. 허용 지연, 무효화, 버전 비교와 장애 시 표시 방법이 정해지지 않으면 적용하지 않는다.

설계 추적 사슬은 다음처럼 양방향으로 관리한다.

화살표를 역으로 읽어 DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현.의 필드가 어떤 요구와 화면, 시험에 쓰이는지 설명할 수 있어야 한다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.이 승인된다면 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.의 정책만 고치는 것이 아니라 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 수용량 불변조건을 재검증하고 판정 컴포넌트, 결정 데이터, 공개 사유, 동시 좌석 처리, 운영 감사와 회귀 시험까지 영향을 평가한다.

이 장에서 정리한 결과는 요구사항-컴포넌트 매핑, 컴포넌트 책임 카드, API·데이터·연계 계약 후보, 품질 시나리오-전술표, 설계 결정 기록 후보다. 다음 장에서는 이 연결을 수용 기준과 시험 조건·시나리오·케이스로 내리고, 설계가 의도한 결과를 관찰 가능한 증거로 확인한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로