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

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

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

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

추상화는 특정 목적에 필요한 성질만 남기고 나머지 세부를 숨긴다. 기능 요구는 시스템이 할 일을 정하고, 품질 요구는 그 일을 얼마나 잘해야 하는지를 정한다. 제약은 고를 수 있는 해법의 범위를 정한다. 모델과 아키텍처 결정은 이 목적과 품질, 제약을 읽을 수 있는 형태로 만든다. 뜻이 낯설면 추상화·인터페이스·계층·의존성과 기능·품질속성·제약을 먼저 읽는다. 아래의 트레이드오프(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 장애는 대기 복구본을 이용하는 별도 복구이며 두 지역의 독립 승인 구조가 아니다.

세 그림은 같은 주문 서비스를 업무 뷰, 구성·데이터·신뢰 뷰, 배포 뷰로 나누어 그린 것이다. 업무 뷰의 결제대기는 구성 뷰에서 외부 결제의 효과가 아직 확정되지 않은 상태와 같은 것을 가리켜야 한다. 또 배포 뷰에 앱을 두 대 그렸더라도 저장소가 단일 쓰기 DB라면, 데이터 뷰에 두 앱이 각자 독립적으로 승인하는 구조를 그리지 않는다.

이 사례의 자체 조건은 국내 사용자, 주문 중복승인 금지, 운영인력 2명, 조회 p95≤1초다. p95는 지연 표본을 작은 값부터 늘어놓았을 때 95백분위에 해당하는 값이며, ≤는 “이하”라는 뜻이다. 즉 같은 조건에서 모은 완료 조회 표본의 p95가 1초를 넘지 않아야 한다는 목표다. 그래서 표본 범위와 측정기간, 백분위 계산 방법을 함께 기록한다. 자세한 품질지표는 뒤의 성능·가용성·신뢰성·복구성·확장성에서 배운다.

완료 표본만 보면 안 되는 이유도 있다. 전체 조회 시도 중 오류와 시간초과는 별도 실패율로 기록해야 하며, 빠르게 끝난 표본만으로 서비스 전체의 품질을 승인하지 않는다.

이 조건에서 고른 구조는 단일 쓰기 DB와 대기 복구본이다. 지역별 쓰기는 네트워크가 분할되는 동안 승인이 충돌할 수 있고 운영이 복잡해지므로 기각한다. 읽기 복제는 오래된 조회를 어디까지 허용할지 정하기 전에는 도입하지 않는다. 대신 원격지역의 지연과 단일 쓰기 DB 장애로 인한 중단 위험을 받아들이고, 대표부하에서 p95가 1초를 넘거나 지역 서비스 요구가 추가되면 이 결정을 다시 검토한다. 실제로 측정하기 전에는 1초 달성을 완료로 적지 않는다.

자체 10점 문제

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

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

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

10점 답안 목차

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

10점 답안 도식

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

기술사 답안으로 전환하기

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

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

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

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

자체 25점 문제

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

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

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 확인). 안내의 제안 양식을 모든 조직의 고정 절차로 취급하지 않는다.

주문·지역분산 저장 사례와 계산 연습은 트레이드오프와 결정기록을 연습하기 위한 자체 예이며 특정 제품 채택을 뜻하지 않는다. 운영인력이 2명이라는 조건만으로 단일 DB의 성능·복구 목표가 저절로 달성되는 것은 아니다. 그래서 실제 부하·장애 시험에서 이 선택이 맞는지 확인해야 한다.

자기교정과 조건 변경

조건을 바꿔 보자. 운영팀이 지역 분산을 감당할 역량이 없다면 운영·복구의 복잡성과 교육·자동화 비용을 대안평가에 넣는다. 반대로 단일 DB의 지연이 개선돼 목표를 만족한다면 분산을 도입할 필요가 있는지와 그 트레이드오프를 다시 평가한다.

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

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

연습 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. 좋은 결정은 결론뿐 아니라 품질·제약, 포기한 이점, 측정지표와 재검토 조건을 남긴다.