모델·관점·아키텍처 결정

한 장의 그림으로 모든 사람의 질문에 답할 수 없다

사용자는 어떤 업무가 이어지는지 알고 싶고, 개발자는 구성요소의 책임과 인터페이스를 보고 싶다. 운영자는 어디서 장애를 감지하고 복구할지, 보안 담당자는 신뢰 경계와 데이터 이동을 묻는다. 모든 세부를 한 그림에 넣으면 누구도 읽기 어렵고, 너무 단순화하면 중요한 위험을 숨긴다. 목적별 모델과 관점을 나누고, 여러 관점에 큰 영향을 주는 선택은 아키텍처 결정으로 근거와 결과를 남겨야 한다.

먼저 되짚기: 추상화와 품질·제약

추상화는 특정 목적에 필요한 성질만 남기고 나머지 세부를 숨긴다. 기능 요구는 시스템이 할 일을, 품질 요구는 그 일을 얼마나 잘해야 하는지를, 제약은 선택할 수 있는 해법의 경계를 정한다. 모델과 아키텍처 결정은 이 목적·품질·제약을 읽을 수 있는 형태로 만든다. 뜻이 낯설면 추상화·인터페이스·계층·의존성과 기능·품질속성·제약을 먼저 읽는다. 아래의 trade-off는 한 이점을 얻는 대신 다른 이점이나 비용을 받아들이는 선택을 뜻한다.

모델·관점·뷰

모델은 현실이나 시스템의 일부를 특정 목적에 맞게 단순화한 표현이다. 관점은 어떤 이해관계자의 어떤 관심사를 어떤 표기와 규칙으로 다룰지 정한 방법이다. 뷰는 그 관점을 실제 시스템에 적용해 만든 구체적인 표현이다. 예를 들어 배포 관점은 실행 노드·네트워크·배치 규칙을 보도록 정하고, 주문 시스템 배포 뷰는 실제 서버와 서비스의 배치를 그린다. 하나의 시스템은 여러 뷰를 가질 수 있으며, 서로 다른 뷰에서 같은 요소를 말할 때 이름과 관계가 모순되지 않아야 한다. 뷰는 반드시 그림 한 장일 필요는 없고 해당 관심사에 필요한 모델·표·설명으로 구성할 수 있다.

일관성은 모든 뷰의 상자와 경계를 똑같이 그린다는 뜻이 아니다. 업무 뷰의 결제대기는 상태이고 구성 뷰의 외부 결제 API는 그 상태에 영향을 주는 구성요소다. 배포 뷰의 앱 A/B는 같은 주문 API 책임을 실행하는 두 인스턴스다. 표현 수준이 다르면 이 대응 관계를 적고, 동일한 책임이나 사실을 서로 다르게 주장하지 않는지 대조한다.

아키텍처 결정

아키텍처 결정은 시스템의 주요 구조와 품질속성에 큰 영향을 주고 나중에 바꾸는 비용이 큰 선택이다. 결정에는 해결할 맥락과 문제, 기능·품질 요구와 제약, 검토한 대안, 선택 기준, 선택한 결과, 포기한 이점, 예상 결과와 다시 검토할 조건이 포함된다. 데이터베이스 제품 A 사용이라는 결론만 적는 것은 부족하다. 왜 그 선택이 필요한 처리량·복구시간·일관성·운영역량을 만족한다고 판단했는지와 어떤 위험을 받아들였는지를 남겨야 한다.

질문을 뷰로 나누고 교차 영향은 결정으로 묶는다

여러 뷰에 큰 영향을 주는 선택은 맥락 → 품질·제약 → 대안 비교 → 결정 → 결과·재검토 조건으로 기록한다. 아래 주문 사례의 같은 요소·경계를 뷰별로 대조한다.

먼저 이해관계자와 그들이 내릴 결정을 적는다. 각 질문에 필요한 요소와 관계만 담은 관점을 선택하고 실제 뷰를 만든다. 공통 구성요소의 이름과 책임경계가 대응하도록 기록해 서로 대조할 수 있게 한다. 관점에 따라 다른 수준의 경계를 그렸다면 어느 요소·책임에 대응하는지 밝힌다. 한 선택이 여러 뷰를 바꾸거나 성능·가용성·보안·비용 사이 균형을 결정하면 아키텍처 결정 기록으로 올린다. 이후 가정이 바뀌거나 품질 목표를 달성하지 못하면 기록된 재검토 조건에 따라 대안을 다시 평가한다.

표현과 선택을 구분한다

모든 코드 선택이 아키텍처 결정은 아니다. 변경이 한 모듈 안에 갇히고 품질·조직·데이터·운영에 미치는 영향이 작다면 일반 설계결정으로 관리할 수 있다. 반대로 서비스 경계, 데이터 소유, 인증 방식, 장애 격리와 배포 구조처럼 여러 팀과 품질속성에 퍼지고 되돌리는 비용이 큰 선택은 아키텍처 수준으로 다룬다.

예쁜 그림과 제품 목록은 근거가 아니다

한 뷰에 업무·코드·서버·조직을 모두 섞으면 선과 상자만 늘고 질문에 답하지 못한다. 서로 다른 뷰가 같은 이름을 다른 뜻으로 쓰거나 같은 책임경계를 모순되게 표현하면 설계·운영·보안 판단이 충돌한다. 각 뷰의 독자, 목적, 범례, 범위와 최신 기준일을 적고 공통 요소를 추적해야 한다.

결정 기록에 선택 결과만 있고 기각한 대안과 품질 근거가 없으면 환경이 바뀌었을 때 판단을 재현할 수 없다. 이미 결론을 정한 뒤 수치와 문서를 끼워 맞추거나, 모든 결정을 영구 불변으로 취급하는 것도 실패다. 결정 당시의 가정, 측정할 품질지표, 소유자와 재검토 사건을 남긴다. 아키텍처 결정 기록(Architecture Decision Record, ADR)의 상태는 제안·채택·기각·후속 결정으로 대체됨 등을 구별한다. 나중에 선택이 달라지면 옛 결정의 맥락을 지우지 말고 새 결정과 대체 관계를 연결해야 변경 이유를 추적할 수 있다.

관심사에서 뷰와 구조적 결정으로 내려간다

관심사에 맞는 관점을 선택해 업무·구성·배포·데이터·신뢰의 실제 뷰를 만든다. 공통 요소·경계가 일관되는지 대조하고, 품질·제약에 큰 영향을 주는 선택을 아키텍처 결정 기록으로 관리한다. 아래 실제 주문 뷰에서 표현과 선택을 구분한다.

사례: 주문 서비스를 한 그림으로 모두 설명하지 않는다

업무 담당자에게는 주문 접수·결제·취소 흐름, 개발자에게는 서비스 책임과 인터페이스, 운영자에게는 배포 노드·네트워크·장애전환을 보여 준다. 각 뷰는 관심사에 맞게 세부를 다르게 숨기지만 주문과 결제경계 같은 공통 요소의 이름과 관계는 모순되면 안 된다.

데이터 저장을 단일 DB에서 지역 분산 구조로 바꾸는 선택은 지연·가용성·일관성·운영역량과 복구비용에 큰 영향을 준다. 제품명만 기록하지 않고 문제, 대안, 선택기준, 포기한 이점, 예상지표와 재검토 조건을 남긴다.

네 관점으로 같은 작은 주문 서비스를 그리면 이름과 책임의 연결이 보인다.

업무 뷰: 미확인 결제는 취소와 다르다 · 상태 따라가기

고객 주문 접수 뒤 외부 결제 결과가 미확정인 결제대기다. 모든 단계에서 주문 상태·결제 근거의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

고객의 주문 접수 뒤 결제대기가 된다. 결제확정은 출고로, 명확한 거절은 취소로 이어진다. 기한초과·결과미확인은 확인대기에서 기존 결과를 조회하며 외부 효과를 실패로 단정하지 않는다.

이 예의 조건

• 고객의 주문 접수 뒤 결제대기가 된다. 결제확정은 출고로, 명확한 거절은 취소로 이어진다. 기한초과·결과 미확인은 확인대기에서 기존 결과를 조회하며 외부 효과를 실패로 단정하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상고객·주문 접수	원 설명주문 흐름 시작
대상결제대기	원 설명외부 결제 결과 미확정
대상결제확정	원 설명확인된 승인 결과
대상출고	원 설명확정 뒤 업무 진행
대상취소	원 설명명확한 결제 거절
대상확인대기	원 설명기존 결제 결과 조회

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결고객·주문 접수 → 결제대기	원 라벨·방향접수 / 정방향 / 실선
연결결제대기 → 결제확정	원 라벨·방향결제확인 / 정방향 / 실선
연결결제확정 → 출고	원 라벨·방향확정 뒤 / 정방향 / 실선
연결결제대기 → 취소	원 라벨·방향명확한 거절 / 정방향 / 실선
연결결제대기 → 확인대기	원 라벨·방향기한초과·미확인 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
공통 시작: 결제대기 고객 주문 접수 뒤 외부 결제 결과가 미확정인 결제대기다.	값·보충 정보 주문 상태: 결제대기 결제 근거: 결과 미확인	변화·이유 전송 성공만으로 결제확정 상태를 만들지 않는다.
대안 1: 결제확정 뒤 출고 결제대기의 공통 시작점에서 승인 확인이 나오면 결제확정 뒤 출고로 진행한다.	값·보충 정보 주문 상태: 결제확정→출고 결제 근거: 승인 결과 확인	변화·이유 확정·배송준비라는 새 상태명 대신 원문의 업무 뷰 상태를 유지한다.
대안 2: 명확한 거절 결제대기 시작점으로 재설정하고 명확한 결제 거절 결과를 본다.	값·보충 정보 주문 상태: 결제대기→취소 결제 근거: 명확한 거절	변화·이유 출고된 주문의 후속 취소가 아닌 배타적인 거절 경로다.
대안 3: 기한초과·미확인 결제대기 시작점으로 재설정하고 기한초과나 결과 미확인인 경우를 본다.	값·보충 정보 주문 상태: 결제대기→확인대기 결제 근거: 기존 결제 결과 조회	변화·이유 승인됐을 수 있으므로 실패 단정이나 새 결제 요청 대신 기존 결과부터 확인한다.

업무 뷰: 미확인 결제는 취소와 다르다 · 상태 따라가기

고객 주문 접수 뒤 외부 결제 결과가 미확정인 결제대기다. 모든 단계에서 주문 상태·결제 근거의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

고객의 주문 접수 뒤 결제대기가 된다. 결제확정은 출고로, 명확한 거절은 취소로 이어진다. 기한초과·결과미확인은 확인대기에서 기존 결과를 조회하며 외부 효과를 실패로 단정하지 않는다.

이 예의 조건

• 고객의 주문 접수 뒤 결제대기가 된다. 결제확정은 출고로, 명확한 거절은 취소로 이어진다. 기한초과·결과 미확인은 확인대기에서 기존 결과를 조회하며 외부 효과를 실패로 단정하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상고객·주문 접수	원 설명주문 흐름 시작
대상결제대기	원 설명외부 결제 결과 미확정
대상결제확정	원 설명확인된 승인 결과
대상출고	원 설명확정 뒤 업무 진행
대상취소	원 설명명확한 결제 거절
대상확인대기	원 설명기존 결제 결과 조회

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결고객·주문 접수 → 결제대기	원 라벨·방향접수 / 정방향 / 실선
연결결제대기 → 결제확정	원 라벨·방향결제확인 / 정방향 / 실선
연결결제확정 → 출고	원 라벨·방향확정 뒤 / 정방향 / 실선
연결결제대기 → 취소	원 라벨·방향명확한 거절 / 정방향 / 실선
연결결제대기 → 확인대기	원 라벨·방향기한초과·미확인 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
공통 시작: 결제대기 고객 주문 접수 뒤 외부 결제 결과가 미확정인 결제대기다.	값·보충 정보 주문 상태: 결제대기 결제 근거: 결과 미확인	변화·이유 전송 성공만으로 결제확정 상태를 만들지 않는다.
대안 1: 결제확정 뒤 출고 결제대기의 공통 시작점에서 승인 확인이 나오면 결제확정 뒤 출고로 진행한다.	값·보충 정보 주문 상태: 결제확정→출고 결제 근거: 승인 결과 확인	변화·이유 확정·배송준비라는 새 상태명 대신 원문의 업무 뷰 상태를 유지한다.
대안 2: 명확한 거절 결제대기 시작점으로 재설정하고 명확한 결제 거절 결과를 본다.	값·보충 정보 주문 상태: 결제대기→취소 결제 근거: 명확한 거절	변화·이유 출고된 주문의 후속 취소가 아닌 배타적인 거절 경로다.
대안 3: 기한초과·미확인 결제대기 시작점으로 재설정하고 기한초과나 결과 미확인인 경우를 본다.	값·보충 정보 주문 상태: 결제대기→확인대기 결제 근거: 기존 결제 결과 조회	변화·이유 승인됐을 수 있으므로 실패 단정이나 새 결제 요청 대신 기존 결과부터 확인한다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

주문 화면의 외부 고객은 서버의 권한검사를 거쳐 본인 주문 데이터에 접근한다. 주문 API가 저장소를 사용하며, 외부 결제 API로는 허용한 최소 필드만 보낸다. 외부 결제는 DB와 다른 효과 경계다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

입구에서 앱 A/B로 요청을 보내며 앱 A 고장 시 앱 B로 우회한다. 두 앱은 같은 단일 쓰기 DB를 쓴다. DB 장애는 대기 복구본을 이용하는 별도 복구이며 두 지역의 독립 승인 구조가 아니다.

업무 뷰의 결제대기는 구성요소 뷰의 외부 효과 미확정 상태와 같아야 한다. 배포에 앱 두 대를 그려도 저장소가 단일 쓰기라면 데이터 뷰에 양쪽 독립 승인을 그리지 않는다.

자체 조건을 국내 사용자·주문 중복승인 금지·운영인력 2명·조회 p95≤1초로 둔다. p95는 지연 표본을 작은 값부터 보았을 때 95백분위에 해당하는 값이며, ≤는 “이하”다. 여기서는 같은 조건의 완료 조회 표본에서 정한 p95가 1초를 넘지 않아야 한다는 목표다. 표본 범위·측정기간·백분위 계산 방법을 함께 기록하며, 자세한 품질지표는 뒤의 성능·가용성·신뢰성·복구성·확장성에서 배운다. 전체 조회 시도의 오류·시간초과도 별도 실패율로 기록해야 하며 빠른 완료 표본만으로 서비스 전체의 품질을 승인하지 않는다. 이 조건의 선택은 단일 쓰기 DB와 대기 복구본이다. 지역별 쓰기는 분할 중 승인 충돌·운영 복잡도 때문에 기각하고, 읽기 복제는 오래된 조회 허용범위를 정하기 전에는 도입하지 않는다. 대신 원격지역 지연과 단일 쓰기 장애의 중단 위험을 받아들이며, 대표부하에서 p95가 1초를 넘거나 지역 서비스 요구가 추가되면 이 결정을 다시 검토한다. 실제 측정 전에는 1초 달성을 완료로 쓰지 않는다.

자체 10점 문제

모델·관점·뷰를 비교하고 아키텍처 결정의 구성요소와 관리방안을 설명하시오.

요구어는 비교와 설명이다. 보는 목적과 실제 표현을 구분하고, 구조적 선택은 맥락·대안·품질근거·포기한 이점·재검토 조건까지 기록해야 한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 모델·관점·뷰 정의
2. 이해관계자 관심사별 표현
3. 뷰 사이 일관성
4. 아키텍처 결정의 구성요소
5. 품질 trade-off·재검토 관리

10점 답안 도식

관심사별 뷰 표와 실제 주문 뷰를 함께 읽는다. 관심사 → 관점 → 실제 뷰의 표현을 만든 뒤 공통 요소의 일관성을 점검하고, 품질·제약에 큰 영향을 주는 구조적 선택을 아키텍처 결정으로 올린다.

기술사 답안으로 전환하기

예상문제: “모델·관점·뷰를 비교하고 아키텍처 결정의 구성요소와 관리방안을 설명하시오.”

모델은 현실이나 시스템을 목적에 맞게 단순화한 표현이다. 관점은 특정 이해관계자의 관심사를 어떤 표기와 규칙으로 다룰지 정한 방법이고, 뷰는 그 관점을 실제 시스템에 적용한 구체적 표현이다. 업무 흐름, 구성요소 책임, 배포·장애와 데이터·신뢰 경계는 서로 다른 뷰로 나누되 공통 요소의 이름·경계·관계는 일관되어야 한다.

아키텍처 결정은 주요 구조와 품질속성에 큰 영향을 주고 되돌리기 비용이 큰 선택이다. 결정 기록에는 맥락과 문제, 기능·품질 요구와 제약, 비교 대안과 기준, 선택 결과, 포기한 이점, 예상 결과·잔여위험과 재검토 조건을 포함한다. 제품명이나 결론만 적으면 환경 변화 때 판단을 재현할 수 없다.

실무에서는 이해관계자가 내려야 할 판단에서 필요한 뷰를 정하고, 한 선택이 여러 뷰·팀·품질에 퍼지면 아키텍처 결정으로 관리한다. 결정에 대응하는 성능·복구·보안 지표와 소유자를 두고 가정이 깨지면 재검토한다. 한 그림에 모든 세부를 섞거나 뷰끼리 모순되고, 이미 정한 결론에 근거를 끼워 맞추는 실패를 뷰 일관성 점검과 결정 이력으로 통제한다.

자체 25점 문제

주문 시스템의 업무·구성·배포·데이터 관점을 분리해 모델링하고, 지역 분산 저장 도입 여부를 아키텍처 결정으로 평가·관리하는 절차를 설계하시오.

요구어는 모델링·평가·설계다. 여러 뷰의 공통 요소를 일관되게 유지하고 품질·제약과 대안의 trade-off를 측정 가능한 결정으로 남긴다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 이해관계자·관심사 식별
2. 관점과 필요한 뷰 선정
3. 공통 요소·경계·관계 일관성
4. 구조적 문제와 품질·제약
5. 대안 비교
6. 지연·가용성·일관성·운영비
7. 결정·포기효과·잔여위험 기록
8. 지표·조건 기반 재검토

25점 답안 도식

대조할 연결	결정 기록으로 남길 것
업무·구성·배포·데이터 뷰	공통 요소·경계의 일치
품질·제약 → 대안 비교	같은 부하·장애조건과 판단 근거
비교 → 결정 기록	선택·기각·포기효과·잔여위험
결정 → 지표·재검토 조건	1초 초과나 지역 요구 등 재검토할 사건

실제 주문 뷰와 아래의 단일 쓰기 선택을 연결한다.

25점 모범답안

먼저 이해관계자의 질문을 정하고 업무흐름, 구성요소 책임, 배포·장애, 데이터·신뢰경계를 서로 다른 관점과 뷰로 표현한다. 뷰마다 필요한 세부만 남기되 주문·결제·고객 같은 공통 요소의 이름, 책임경계와 관계가 서로 모순되지 않도록 추적한다.

지역 분산 저장은 지연·가용성·일관성·복구·운영역량에 큰 영향을 주고 되돌리기 비용이 큰 선택이므로 아키텍처 결정으로 관리한다. 현 구조의 문제와 품질목표·제약을 적고 단일 저장, 읽기 복제, 지역 분산 등 대안을 같은 부하·장애조건에서 비교한다.

결정에는 선택 결과뿐 아니라 포기한 이점, 예상지표, 잔여위험과 재검토 조건을 남긴다. 운영지표나 업무조건이 임계값을 벗어나면 결정과 관련 뷰를 함께 재검토한다.

위 네 뷰를 채택해 주문 API·주문 저장소·외부 결제의 이름을 공통으로 맞춘다. 국내 사용자와 운영인력 2명이라는 조건에서는 단일 쓰기 DB+대기 복구본을 선택하고 지역별 독립 쓰기는 충돌 통제비용 때문에 기각한다. p95≤1초는 검증할 목표이며 실측 보장이 아니다. 담당자는 같은 부하 성능시험과 앱/DB 각각의 장애시험을 기록하고, 원격지역 요구나 1초 초과가 확인되면 데이터·배포 뷰와 결정기록을 함께 개정한다.

출처와 적용 경계

모델·관점·뷰와 아키텍처 결정은 안정된 시스템·소프트웨어 아키텍처 기초개념이다. 관점의 규칙과 실제 뷰의 구분은 ISO/IEC/IEEE 42020:2019의 공개 용어 §3.24–3.25로 대조했다. 이는 42020의 공개 설명을 근거로 삼은 것이며 ISO 42010 본문을 직접 읽거나 복제했다는 뜻은 아니다. 결정의 맥락·선택·긍정과 부정 결과, 상태·후속 대체 기록은 GDS의 Architecture Decision Records 안내로 대조했다(2026-10-09 확인). 안내의 제안 양식을 모든 조직의 고정 절차로 취급하지 않는다.

주문·지역분산 저장 사례와 계산 연습은 trade-off와 결정기록을 연습하기 위한 자체 예이며 특정 제품 채택을 뜻하지 않는다. 운영인력 2명만으로 단일 DB의 성능·복구 목표가 자동 보장되는 것은 아니므로 실제 부하·장애 시험에서 선택 근거를 확인해야 한다.

자기교정과 조건 변경

운영팀이 지역 분산을 감당할 역량이 없으면? 운영·복구 복잡성과 교육·자동화 비용을 대안평가에 넣는다.

단일 DB의 지연이 개선돼 목표를 만족하면? 분산 도입의 필요성과 trade-off를 다시 평가한다.

새 규제로 데이터 지역분리가 의무화되면? 제약 변화로 기록하고 기존 결정·데이터뷰·배포뷰와 마이그레이션 위험을 함께 재검토한다.

표현과 결정 근거를 바꾸어 보는 세 연습

연습 1. “실행 노드와 서비스 배치를 어떤 기호·규칙으로 그릴지 정한 안내”와 “주문 API가 앱 A/B에서 실행되고 같은 단일 쓰기 DB를 쓰는 실제 표현”을 각각 관점과 뷰 중 무엇인지 구별하자. 업무 뷰에 앱 A/B 대신 결제대기가 나타나면 곧바로 모순일까?

연습 2. 같은 부하의 조회 시도 22건 중 20건이 완료됐고 2건은 시간초과였다. 완료 지연은 0.6초 18건, 1.2초 1건, 1.6초 1건이다. 이 연습의 p95는 완료값을 오름차순으로 놓고 ceil(0.95×완료건수)번째 값을 고르는 최근접 순위 방식으로 계산한다. ceil은 소수 부분이 있으면 다음 정수로 올리는 연산이다. p95≤1초 목표를 만족할까? 전체 시간초과 비율도 계산하고 결정 기록에 남길 판단을 적자.

연습 3. 앱 A를 멈췄을 때 앱 B로 우회하는 시험은 통과했다. DB 장애·복구는 시험하지 않았지만 결정 기록에 “모든 단일 장애에서 계속 승인 가능”이라고 썼다. 이 기록과 배포 뷰를 어떻게 고칠까? 나중에 데이터 지역분리 제약이 새로 생겼을 때 기존 채택 기록도 어떻게 관리할지 적자.

세 연습의 대조·계산·결정 해설 보기

1. 표기와 규칙을 정한 안내는 배포 관점이며 실제 주문 배치를 표현한 결과는 배포 뷰다. 결제대기는 업무 상태이고 앱 A/B는 그 업무를 실행하는 배포 인스턴스이므로 상자가 다르다는 이유만으로 모순은 아니다. 구성 뷰의 주문 API 책임과 배포 인스턴스, 업무 상태 사이 대응을 적고 한 뷰는 단일 승인인데 다른 뷰는 독립 이중 승인을 주장하는 식의 사실 충돌을 찾는다.

2. ceil(0.95×20)=19이므로 정렬된 19번째 값 1.2초가 이 연습의 p95다. 1초 목표를 만족하지 않는다. 시간초과 비율은 2/22×100≈9.09%다. p95 계산에 성공 표본만 썼다는 경계와 시간초과를 따로 남기고, 완료 지연·실패율 모두로 대안을 재검토한다. 완료 20건만 골라 “서비스 전체가 성공”이라고 쓰지 않는다. 백분위 보간 방법이 다르면 값도 달라질 수 있으므로 이 연습에 지정한 계산 방법을 다른 기록에 말없이 적용하지 않는다.

3. 확인한 것은 앱 A 장애 시 우회뿐이다. 단일 쓰기 DB가 두 앱의 공통 의존이므로 DB 장애는 별도 중단·복구 위험으로 남기고 대기 복구본의 전환·데이터 손실·복구시간을 검증한다. 관찰하지 않은 승인 지속을 완료로 적지 않는다. 데이터 지역분리 제약이 생기면 대안과 관련 데이터·배포 뷰를 다시 평가하고 새 결정 기록을 만든다. 옛 채택 기록은 당시 맥락과 함께 보존하고 새 기록으로 대체됐음을 연결한다.

30초 정리

1. 모델은 목적에 맞춘 단순화, 관점은 보는 규칙, 뷰는 실제 시스템에 그 규칙을 적용한 표현이다.
2. 여러 뷰는 이해관계자 질문을 나누되 공통 이름·경계·사실이 일치해야 한다.
3. 아키텍처 결정은 영향이 크고 되돌리는 비용이 큰 구조 선택과 그 대안·근거·결과를 기록한다.
4. 좋은 결정은 결론뿐 아니라 품질·제약, 포기한 이점, 측정지표와 재검토 조건을 남긴다.