아키텍처 평가와 트레이드오프

1. 97%라는 숫자가 좋은 아키텍처를 보증할까

앞 절의 취소 서비스에는 내부 모듈을 둔 한 애플리케이션과 예약·취소를 독립 서비스로 나누는 두 후보가 있었다. 담당자가 “A는 97%, B는 94%이므로 A가 우수하다”고 결론 내렸다고 하자. 그런데 두 비율이 실제 시험이 아니라 설명용 숫자라면 어떨까? A가 빨리 응답하면서 아직 저장하지 않은 취소를 완료라고 알려 주었다면 어떨까?

아키텍처 평가는 예쁜 그림이나 높은 점수를 고르는 일이 아니다. 중요한 상황을 구조에 대입하여 어느 결정이 어떤 결과를 만드는지, 그 판단은 무엇에 근거하는지, 아직 무엇을 모르는지 드러내는 일이다. 이 절에서는 같은 공방의 취소 요청을 따라가며 평가의 질문을 위험 기록과 선택 조건으로 바꾼다.

여기의 공방, 수치, 평가 회의, 담당 역할과 결과표는 집필자가 만든 예다. 실제 운영 시스템을 평가했거나 이해관계자 회의를 개최한 기록이 아니다.

구조와 구조를 설명한 문서를 구별했던 이유

앞 절 아키텍처 드라이버·뷰·스타일·문서화에서 구조 자체와 기술서를 구별하고 드라이버에 따라 책임·관계·배포 경계를 선택했다. 모듈 뷰, 실행 뷰, 배치 뷰는 서로 다른 질문을 표현하지만 같은 요소와 계약을 설명해야 했다. 이번에는 그 결정과 표현을 중요한 시나리오에 대입하여 설명의 타당성과 남은 위험을 살핀다.

시험과 운영은 다른 증거를 더한다

분석·설계·구현·시험·운영·변경에서는 설계가 구조와 책임을 정하고, 시험은 기준 충족의 증거를 모으며, 운영은 실제 환경의 결과를 관찰한다고 배웠다. 설계상의 설명, 구현을 실행한 결과, 운영 중 관찰한 결과는 서로 연결되지만 같은 증거는 아니다. 평가 보고서에서도 어떤 단계에서 얻은 자료인지 구별한다.

확정 여부를 모른다는 말도 결과의 일부다

앞 절의 I-CANCEL-v1은 취소 확정 CONFIRMED, 업무상 거절 REJECTED, 현재 결과 미확인 UNKNOWN을 구별했다. 저장 확정 뒤 응답만 유실될 수 있으므로 시간초과를 곧바로 취소 실패로 바꾸지 않았다. 이번에는 이 계약이 정상·응답 유실·재요청에서 유지되는지 평가한다.

숫자를 비교하기 전에 측정 경계를 되짚는다

측정값·지표·목표·기준선에서 지표는 분자·분모·대상·기간·자료원과 제외 규칙이 같아야 비교할 수 있다고 배웠다. 이번에도 오류를 분모에서 빼거나 가상 수치를 실측으로 바꾸지 않고 같은 경계에서 판정한다.

쉽게 말하면, 설계 설명에 반례를 대입한다

“취소 결과가 안전하게 저장됩니다”라는 설명에 “저장한 직후 응답만 사라지면요?”라고 묻는다. “독립 배포할 수 있습니다”에는 “상대 서비스가 이전 계약을 쓰고 있으면요?”라고 묻는다. 대답이 막히면 담당자를 공격할 것이 아니라 빠진 조건과 확인할 자료를 기록한다.

이 절의 아키텍처 평가는 중요한 요구·제약에 대해 구조적 결정의 적합성과 위험을 근거로 검토하는 활동이다. 평가의 대상은 특정 버전의 구조이며 결론에는 대상·상황·전제·증거의 경계가 붙는다. “언제나 안전한 구조”라는 무제한 판정이 목표가 아니다. [S2]

설계 검토, 실행 시험, 채택 결정은 같은 행위가 아니다

취소 상태와 결과를 함께 확정하겠다는 계약은 원자성을 요구한다. 그 문장만으로 실제 DB가 그렇게 동작했다는 증거가 생기지는 않는다. 반대로 특정 입력의 시험 성공만으로 미정인 환불 정책까지 검토했다고 할 수도 없다.

아래에서는 문서에 적힌 사실, 그 사실에서 도출한 분석, 아직 확인하지 않은 가정을 따로 적는다. 평가를 수행했다는 사실과 서비스 사용을 승인했다는 사실도 따로 관리한다.

앞 절의 조건을 바꾸지 않고 가져온다

AS-D1은 개발·운영 담당 세 명이 예약·취소를 같은 배포 주기로 관리한다는 가상 조건이다. 후보 A는 내부 모듈을 구분한 한 애플리케이션과 저장소이고 후보 B는 예약·취소를 독립 서비스로 나눈 구조다. A를 우선 검토한 이유는 현재 가정에서 독립 배포보다 운영·조정 부담이 더 중요했기 때문이다.

AS-Q1은 정상 저장 환경에서 서로 다른 시험용 예약의 유효한 취소 요청 1,000건을 같은 시험 시작 시점에 제출하고, 요청 시작부터 확정 결과 수신까지 2초 이내 성공이 최소 950건이어야 한다는 가상 목표다. 앞 절의 분모·측정 경계·성공의 뜻을 유지하며 500밀리초나 성공 응답만의 비율로 바꾸지 않는다.

환불 자동 실행과 자리 반환 정책 결정은 여전히 범위 밖이다. 이 절에서 추가하는 평가 시나리오는 EV-로 표시하여 앞의 조건을 몰래 덮어쓰지 않는다. 특히 가상 집계의 A/B라는 이름과 구조 후보 A/B를 같은 것으로 간주하지 않는다. 어느 구조에서 측정했다는 증거가 없기 때문이다.

전체 경로: 중요한 장면에서 확인할 결정까지

표의 마지막 행에서 새 질문이 생기면 앞의 판단을 다시 검토한다. 예컨대 응답 유실 후 결과 조회의 보관기간이 정해지지 않았다면 “보관기간 미정”을 새 쟁점으로 올려야 한다. 설명이 끊긴 곳을 높은 성능 점수로 메우지 않는다.

2. ATAM은 시나리오로 구조적 위험을 드러낸다

ATAM(Architecture Tradeoff Analysis Method)은 여러 품질속성 목표에 비추어 아키텍처의 위험과 상호 영향을 분석하는 시나리오 기반 평가 방법이다. [S1]

공방에 적용하면 “모놀리스인가?”보다 “지금의 저장·응답 경계로 어떤 상황을 감당할 수 있는가?”가 먼저다. 개발자는 필요한 구조 정보를 설명하고, 운영 담당자는 놓치기 쉬운 장애와 복구의 상황을 제시한다. 평가자는 그 주장에 필요한 자료를 묻는다.

이 절은 ATAM의 개념을 적용한 학습 예다. 실제 평가팀·프로젝트 의사결정자·여러 이해관계자가 참여한 정식 ATAM 수행을 대신했다고 표시하지 않는다.

누가 어떤 질문을 책임질까

공방의 가상 회의에서 업무 담당자는 본인 예약만 취소할 수 있는지와 취소 완료의 뜻을 설명한다. 설계 담당자는 M-USECASE, M-RESERVATION, M-STORAGE를 따라 어떤 계약으로 상태가 바뀌는지 보여 준다. 운영 담당자는 저장소가 응답하지 않을 때 무엇을 관찰하고 누가 결과를 확인할지 묻는다.

같은 사람이 여러 역할을 맡더라도 질문을 생략하지 않는다. 설계자가 “아마 괜찮다”고 말한 것은 운영 검증의 증거가 아니며, 평가자가 위험을 기록했다고 업무 정책을 승인할 권한이 생기는 것도 아니다. 결론마다 누가 자료를 제공하고 누가 위험 수용 여부를 결정할지 남기는 것이 이 예의 회의 규칙이다.

정책 담당자가 참석하지 못하면 미정인 보관기간을 숫자로 채우지 않는다. 그 조건을 필요한 질문으로 남기고, 결정 전에는 어떤 채택 판단을 보류하는지 적는다.

아홉 활동의 입력과 출력을 읽는다

ATAM의 아홉 활동을 이 사례의 작업으로 풀면 다음과 같다. 번호는 활동을 구분하기 위한 것이며 되돌아갈 수 없는 일회성 순서가 아니다. [S1]

예컨대 활동 7에서 결과 조회가 끊기는 상황을 새로 찾으면 활동 8에서 조회 책임과 보관 조건을 다시 분석한다. 여기서 시나리오로 설명을 시험한다는 것은 반드시 부하 발생기를 실행했다는 뜻이 아니다. 어떤 실행 검사가 필요해졌는지는 별도 확인 계획에 적는다.

유틸리티 트리는 관심사를 구체적인 장면까지 좁힌다

유틸리티 트리(utility tree)는 중요한 품질 목표를 세부 관심사와 구체적인 시나리오로 내려가며 정리하고 우선화하는 구조다. [S1]

“성능”에서 멈추면 공방 담당자는 화면 표시 속도를 떠올리고 개발자는 DB 조회 한 번의 시간을 떠올릴 수 있다. 그 아래 “취소 확정 결과 수신”을 두고 AS-Q1의 입력·시간 경계·비율을 연결하면 평가할 대상이 맞춰진다.

이 트리의 선은 호출이나 네트워크 연결이 아니다. 소프트웨어 책임을 나누는 모듈 뷰와도 다르다. 무엇을 중요하게 검토할지 정리한 지도이며, 그 잎에서 실제 구조의 어느 결정을 살필지 다시 찾아가야 한다.

예제 트리에는 새 조건의 출처도 표시한다

EV-M1은 화면에 날짜를 표시하는 형식만 바꾸고 입력·업무 정책·공개 계약의 뜻은 바꾸지 않는다는 추가 학습 조건이다. 날짜 계산 규칙 자체를 바꾸는 작업까지 같은 변경이라고 부르지 않는다. 확인 자료는 변경 전후 코드와 영향 범위이며 아직 실제 변경을 수행한 결과가 없다.

EV-R1은 저장 확정 직후 응답을 잃는 장면이다. 재요청으로 새 취소 효과가 생기지 않고 기존 결과를 확인해야 한다는 앞 절의 계약을 대입한다. 이것도 실제 장애를 주입해 성공한 결과가 아니라 시험할 장면이다.

보안 전체를 이 작은 트리에 다 넣었다고 주장하지 않는다. 소유권 등 이미 지켜야 할 기능·보안 조건은 별도의 필수 조건 표에서 함께 확인한다.

중요도와 달성의 어려움을 구별한다

유틸리티 트리의 우선화에서는 시스템 성공에 대한 중요도와 해당 목표를 달성하기 어렵다고 보는 정도를 구별한다. H, M, L은 이 예에서 높음·중간·낮음이며 측정한 실패 확률이 아니다. [S1]

공방의 설명용 표에서는 AS-Q1을 (H,M), EV-M1을 (M,L), EV-R1을 (H,H)로 둔다. EV-R1은 중요한데 확정 시점·응답·조회·중복 통제를 함께 따져야 하므로 먼저 질문한다. 실제 팀의 평가나 설문으로 얻은 순위는 아니다.

중요도가 높지만 쉬워 보이는 소유권 검사를 생략해도 된다는 뜻은 아니다. 필수 조건은 여전히 필수다. 어려움이 낮다는 예상이 틀릴 수 있으므로 확인 근거를 남긴다. 두 글자를 곱하여 객관적인 위험 점수나 장애 확률처럼 쓰지 않는다.

후보 이름이 아니라 작동하는 결정을 찾는다

“후보 A는 모듈형 구조다”만으로는 EV-R1에 답할 수 없다. M-USECASE가 언제 저장을 요청하고 M-STORAGE가 어떤 결과를 확인한 뒤 확정을 알리는지 보아야 한다. 이 예에서 분석할 결정은 “취소 상태와 요청 결과를 같은 로컬 확정 경계로 저장한다”와 “결과가 불명이면 UNKNOWN으로 남긴다”다.

EV-M1에서는 표시 형식의 변경이 M-ENTRY에 머물고 업무 판단 책임으로 퍼지지 않는지 살핀다. 실제 저장 제품 이름을 바꾼다는 설명과 필요한 계약이 유지된다는 설명을 구분한다. 스타일은 출발점이 될 수 있지만 필수 조건·팀의 능력·실제 책임을 함께 비교해야 한다. [S5]

평가 질문을 쓰면 필요한 뷰도 정해진다. EV-R1은 실행과 저장 경계, EV-M1은 코드 의존과 변경 범위, 노드 장애는 배치와 대체 경로를 본다. 같은 상자 그림 한 장으로 모든 질문을 닫지 않는다.

3. 위험·비위험·민감점·트레이드오프점을 구별한다

아키텍처 위험(risk)은 중요한 품질 목표를 달성하지 못할 가능성을 드러내는 구조적 결정이나 미결정의 문제다. 비위험(non-risk)은 분석한 상황과 전제 아래 적절하다고 판단한 구조적 결정이다. [S1]

둘은 한 번 붙이면 영원히 유지되는 제품 등급이 아니다. 공방에서 “저장 확정 전 성공을 응답한다”는 결정은 확정 결과를 약속한 계약과 충돌한다. 반면 “확정 여부를 모르면 UNKNOWN이라고 표현한다”는 계약은 그 한 가지 오표시를 막는 방향으로 적절하다. 그러나 실제 구현과 보관기간이 미검증이면 전체 경로를 비위험으로 닫을 수 없다.

특히 아무도 문제를 지적하지 않았다는 사실은 비위험의 근거가 아니다. 무엇을 분석했고 어떤 전제가 유지되어야 하는지 설명할 수 있어야 한다.

위험 기록 하나를 끝까지 쓴다

가상 위험 R-AE-01은 “같은 요청의 결과를 언제까지 보관하는지 정하지 않았다”는 문제다. 앞 절은 식별자별 결과 조회를 요구했지만 보관·재요청 허용기간은 미정으로 남겼다. 다음은 그 미정을 실제 판단 자료로 바꾸는 예다.

“저장 실패 위험 있음”보다 구체적이다. 이 기록은 실제 장애가 발생했다는 주장도, 기간이 지나면 반드시 중복 취소된다는 주장도 아니다. 현재 근거로 무엇을 보장할 수 없는지 드러낸 것이다. 늦게 도착한 요청과 같은 식별자의 다른 의도는 재시도 계약에서 따로 다루어야 한다. [S4]

민감점은 결과에 중요한 영향을 미치는 구조의 속성이다

민감점(sensitivity point)은 특정 품질 응답을 달성하는 데 중요한 영향을 주는 구성요소나 관계의 속성이다. [S1]

공방에 비유하면 저장 처리의 동시 실행 한도 k를 바꿨을 때 대기와 결과 수신시간이 크게 달라지는지 묻는 것이다. 단지 설정값이 있다는 이유만으로 민감점이라고 부르지 않는다. 현재 부하에서 저장소가 아닌 다른 단계가 병목이면 k만 늘려도 목표가 달라지지 않을 수 있다.

먼저 자원이 어디에서 제한되는지 확인하고, 다른 조건을 고정한 채 k 변경 전후의 응답·대기·오류를 비교할 계획을 세운다. 아직 실행하지 않았으면 “민감점 후보”다. 이미 생긴 결과와 앞으로 확인할 가설의 이름을 구별한다.

같은 속성이 여러 품질에 중요하면 함께 판단한다

트레이드오프점(tradeoff point)은 둘 이상의 품질속성에 대한 민감점인 구조의 속성이다. [S1]

공방의 결과 보관기간 r을 생각해 보자. 허용된 기간의 재조회 가능성을 위해 충분히 길어야 하지만, 길수록 보관량과 관리 부담도 검토해야 한다. 이를 분석할 때에는 실제로 허용할 재요청 기간과 저장 규모를 함께 정한다. 이 예에서는 결과 조회 신뢰성과 자원 부담에 대한 트레이드오프점 후보이며 두 영향이 어느 정도인지 아직 검증하지 않았다.

한 값을 바꾸면 한쪽이 반드시 같은 비율만큼 나빠진다는 법칙은 없다. 영향의 방향과 크기, 임계값을 조사해야 한다. 또한 이미 합의한 조회 기간을 어기면서 비용만 낮추는 것은 허용 대안 사이의 절충이 아니라 필수 조건 위반이다.

네 용어는 같은 층위의 배타적인 네 등급이 아니다

보관기간이 민감한 속성이라는 판단과 그 값을 아직 정하지 않았다는 위험은 함께 기록할 수 있다. 반대로 실제 분석 없이 “비위험”을 채워 네 칸을 완성할 필요는 없다.

완료된 평가처럼 꾸미기보다 후보, 미결정, 근거 확보, 추가 시험 필요를 구별한다. 이 학습 예는 미검증 속성을 정식 ATAM의 확정된 분석 결과라고 주장하지 않는다.

작은 계산으로 의존 관계를 확인하되 효과를 과장하지 않는다

보관기간과 자료량의 관계만 보기 위해 별도의 가정 EV-C1을 둔다. 하루에 새 결과 1,000개가 생기고 각 결과가 정확히 2,000바이트이며 매일 같은 양이 들어온다고 하자. 중복 요청은 새 결과를 추가하지 않으며 기간이 지난 기록을 정확히 삭제하고, 색인·복제·여유 공간을 제외한 정상상태의 결과 본문만 계산한다.

결과 본문량 = 하루 신규 결과 수 × 결과당 바이트 × 보관 일수
7일: 1000 × 2000 × 7 = 14,000,000바이트
30일: 1000 × 2000 × 30 = 60,000,000바이트
차이: 46,000,000바이트

이 계산은 선형 보관량이라는 가정의 결과다. 실제 DB의 디스크 크기, 가격, 조회 속도, 장애 복구시간을 계산한 것이 아니다. 7일이 싸 보인다고 합의하지 않은 재요청 기간을 7일로 결정해서도 안 된다.

그 대신 “허용 조회 기간이 정해지면 필요한 보관량을 계산하고, 실제 자료 구조와 조회량으로 성능을 확인한다”는 다음 질문을 만든다. 작은 계산의 역할은 대안을 성급히 승인하는 것이 아니라 어떤 입력이 필요한지 드러내는 데 있다.

식의 단위도 확인하자. 1,000개/일 × 2,000바이트/개는 하루에 쌓이는 2,000,000바이트/일이고, 여기에 보관 일수를 곱하면 일 단위가 없어져 바이트가 남는다. 보관기간 r은 이 사례에서는 일 단위의 기간이며 앞의 k는 동시에 처리할 수 있는 작업 수다. 서로 다른 단위의 두 속성을 같은 점수처럼 더하지 않는다. 보관일수만 14일로 바꾸어 계산하면 2,000,000 × 14 = 28,000,000바이트다. 7일의 두 배이니 조회 속도도 두 배라고 해석하면 자료량 가정을 성능 법칙으로 바꾼 오류다. 민감점은 결과에 중요한 영향을 미치는 구조의 속성이다·같은 속성이 여러 품질에 중요하면 함께 판단한다의 속성별 영향과 작은 계산으로 의존 관계를 확인하되 효과를 과장하지 않는다의 제외 범위로 돌아가, 계산으로 알 수 있는 본문량과 실제 시험이 필요한 조회 성능을 나눠 적는다.

4. 숫자를 비교하기 전에 무엇을 센 것인지 확인한다

AS-Q1의 분자는 제출한 요청 중 기대한 확정 결과를 2초 이내 받은 건수다. 빨리 반환된 오류나 내용이 틀린 응답은 성공이 아니다. 지연시간을 볼 때 성공과 실패를 구별하고 오류도 별도로 관찰해야 한다. [S3]

분모는 전체 제출 1,000건이다. 늦은 성공, 오류, 시간초과를 제외하여 분모를 작게 만들지 않는다. 시간초과는 이 시간 목표의 미충족이지 실제 취소가 영원히 실행되지 않았다는 뜻은 아니다. 확정 여부는 별도의 결과 조회로 확인한다.

이 예의 경계는 2000밀리초 이하다. 2000은 시간 조건 안에 들고 2001은 넘는다. 기록이 누락되어 시간을 모르면 임의로 0을 넣지 않는다. 제출 목록과 결과 기록의 대응이 완전한지 먼저 확인해야 한다.

가상 집계 A와 B를 같은 분모로 다시 계산한다

같은 1,000건을 분모로 하면 집계 A는 97.0%로 수치 조건을 충족하고, 집계 B는 94.0%로 미충족이다.

판정식은 2초 이내 성공 수 × 100 ≥ 전체 제출 수 × 95다. 집계 B에서 실패한 20건을 분모에서 빼면 940/980 ≈ 95.92%가 되어 결과가 뒤집힌다. 하지만 그것은 오류를 고친 것이 아니라 측정 약속을 바꾼 것이다.

집계 A/B는 앞 절에서 가져온 설명용 자료 묶음이다. 이름이 같아도 구조 후보 A/B를 실제로 실행한 결과가 아니다. 합성 요청 기록을 같은 분모·판정식으로 재집계해 97%와 94%를 확인해도 실제 성능 시험을 수행한 것은 아니다.

평균·성공률·내용의 정확성은 서로 대신하지 못한다

응답 1,000개가 모두 1밀리초에 도착하더라도 전부 UNKNOWN이면 AS-Q1에서 기대한 확정 결과의 성공은 0건이다. 응답 문자가 CONFIRMED여도 실제 예약번호가 다르거나 저장 확정 사실이 없으면 올바른 성공으로 세지 않는다.

평균 지연만 낮다고 해서 정한 비율이 시간 안에 끝났는지도 알 수 없다. 큰 지연이 일부에 몰릴 수 있으므로 제출별 성공·시간 경계를 확인한다. 성공률이 좋다는 사실과 잘못된 내용을 반환하지 않는다는 조건도 따로 확인한다. [S3]

이 예의 합성 기록에는 응답 종류, 지연시간, 기대 결과와의 일치 여부를 둔다. 정확함이라는 필드를 작성자가 임의로 채운 합성 데이터는 검산 입력이지 서비스의 정확성을 입증한 자료가 아니다. 실제 시험에서는 저장 상태와 독립적으로 정한 기대값에 대조해야 한다.

비교 조건이 다르면 원인도 분리할 수 없다

구조 후보 A를 작은 자료로, B를 큰 자료로 실행해 속도를 비교하면 구조 때문인지 자료 때문인지 구별하기 어렵다. 비교표에는 코드 버전, 자원 한도, 입력 분포, 제출 방식, 저장 상태, 관찰 경계를 적는다. 이미 데이터가 들어 있는 캐시를 사용한 실행과 최초 실행을 같은 조건이라고 숨기지 않는다.

AS-Q1은 1,000건 동시 제출이라는 특정 장면이다. 초당 일정량이 계속 들어오는 상황이나 장애 중의 응답을 대신 측정하지 않는다. 후속 시험에서는 필요한 다른 장면을 별도 식별자로 정의하고 변동도 살핀다.

다른 구조가 같은 자원으로 불가능하다면 비교 목적부터 명확히 한다. 같은 자원에서의 효과를 볼지, 같은 비용에서의 효과를 볼지, 같은 목표를 만족하는 데 드는 비용을 볼지는 서로 다른 비교다. 모두 측정 경계를 명시해야 한다.

가상 계산·분석·실측·미확인을 구분한다

이 표의 분류는 이 학습 예의 보고 규칙이며 모든 산업의 공식 증거 등급표가 아니다. 보고서에 수치가 있다는 이유만으로 실측이라고 바꾸지 않는다. 반대로 실측이 없다는 이유로 계약의 논리적 모순까지 발견할 수 없는 것은 아니다.

5. 좋은 점수보다 먼저 필수 조건을 통과시킨다

먼저 반드시 지켜야 하는 조건과 개선 정도를 비교할 항목을 나눈다. 공방에서는 본인 예약의 허용된 취소만 확정하고, 취소 확정을 환불 완료로 표시하지 않으며, 같은 요청의 중복 효과를 막아야 한다. 여기서 새 보안 정책을 정의하는 것이 아니라 앞선 계약을 평가 대상으로 다시 확인한다.

필수 조건을 위반한 대안은 다른 장점의 점수로 상쇄하지 않는다. 확인되지 않은 필수 조건은 통과가 아니라 보류다. AS-Q1의 97%라는 가상 수치도 소유권 위반이나 저장 전 완료 응답을 덮을 수 없다.

그다음에 비교 가능한 대안들의 변경 부담, 운영 책임, 비용을 살핀다. 비용은 이 예에서 장비뿐 아니라 공동 배포 점검, 계약 변경 조정, 장애 시 확인 작업까지 같은 기간과 범위로 비교한다. 실제 금액 자료가 없으므로 임의의 원 단위 총액을 넣지 않는다.

선택표에는 모르는 것도 한 칸으로 남긴다

표의 “미측정”을 설명용 집계 A/B로 채우지 않는다. 현 단계에서 가능한 결론은 A의 구조적 방향을 우선 검토한다는 것과 실제 사용 승인에 필요한 근거가 남았다는 것이다. A가 실제로 더 빠르다거나 B가 열등하다는 결론은 아니다.

여러 서비스의 독립성이 실제로 필요한 환경이면 B의 부담과 이점을 다른 조건에서 다시 비교한다. 특정 스타일에 붙은 일반적 장점과 이 프로젝트에서 확보한 효과를 구별한다. [S5]

점수 합계가 높아도 채택할 수 없는 반례

학습용 선택표에서 X의 편의 점수가 95, Y가 80이라고 가정하자. X는 소유권 검사에서 실패했고 Y는 통과했지만 실제 성능 검증이 없다. X는 채택 불가이고 Y는 확인이 더 필요한 상태다. 둘 중 하나를 반드시 승인해야 한다는 규칙은 없다.

필수 조건의 상태를 충족, 위반, 미확인으로 관리하면 이 차이가 드러난다. 모두 충족된 대안들 사이에서만 같은 정의의 선호 점수를 보조적으로 쓴다. 점수 범위와 가중치를 누가 정했는지도 남긴다.

이 반례는 후보의 필수 조건을 먼저 대조하면 확인할 수 있다. “충족”이라는 입력을 이용한 선택 계산은 실제 소유권 검사를 수행한 것과 다르다. 실제 구현이 그 입력 상태에 해당하는지는 별도 시험과 검토의 책임이다.

보고서에는 결론뿐 아니라 다음 확인의 끝도 적는다

공방 평가 기록에는 대상 버전, AS-D1·AS-Q1과 추가 EV 시나리오, 분석한 책임·계약, 근거 종류, 위험, 미정 조건을 남긴다. R-AE-01에는 담당 역할뿐 아니라 어떤 자료가 갖추어지면 닫을지도 적는다.

“추후 검증”만 쓰지 말고 “합의된 보관·재요청 기간의 직전·직후, 응답 유실 뒤 같은 식별자, 같은 식별자의 다른 내용 재사용을 대조한다”고 쓴다. 실제 원격 환경에서 실행하지 않은 항목은 미실행으로 유지한다. 재요청 안전성은 정상 경로뿐 아니라 늦은 요청과 의도 변경을 구분하는 계약에 달린다. [S4]

제안의 종료 조건과 릴리스의 승인 조건은 다를 수 있다. 한 위험을 닫았어도 다른 필수 조건이 미확인이면 전체 사용을 승인하지 않는다. 보고서의 판단 범위를 마지막 문장까지 유지한다.

반복해서 나타난 문제를 공통 원인으로 묶는다

결과 조회 기간이 미정이고 만료 후 오류 처리도 미정이며 누가 기간을 결정할지도 없다면, 서로 다른 세 줄의 문제가 같은 원인을 가질 수 있다. 이 예에서는 이를 “계약 수명과 운영 책임이 정해지지 않음”이라는 공통 문제로 묶는다.

그러면 스키마 필드 하나를 추가하는 대신 업무·운영·개발이 함께 결정해야 할 작업이 보인다. 그렇다고 관련된 위험 번호를 지우지는 않는다. 각 상황의 영향과 종료 조건을 따라갈 수 있어야 공통 결정이 무엇을 해결했는지 확인할 수 있다.

이 묶음은 원인을 이해하기 위한 저자의 사례 분석이다. 실제 사고 조사 결과나 모든 미정 항목의 보편적 원인을 선언하는 것이 아니다.

전제가 바뀌면 같은 판정을 재사용하지 않는다

세 명의 공동 배포라는 AS-D1이 달라져 별도 팀이 다른 주기로 기능을 배포하게 되면, 앞 절에서 A를 우선 검토한 이유가 달라진다. 결과 조회 허용기간이 늘면 보관기간과 자료량 계산도 다시 확인한다. 요청 부하가 달라지면 기존의 성능 결과를 그대로 가져오지 않는다.

재평가에서는 바뀐 전제와 영향을 받는 시나리오를 찾아 관련 계약·뷰·증거를 갱신한다. 이전 결정을 무조건 폐기하는 것도, 이미 평가했다는 이유로 새 검토를 막는 것도 맞지 않는다.

다음 절 아키텍처 이행·적합성·기술부채에서는 의도한 결정을 구현과 운영에서 어떻게 지키는지 이어 다룬다. 이번 절의 산출물은 그 확인을 시작할 질문·조건·근거다.

완성된 평가 기록의 모양을 짧게 읽는다

평가 대상은 앞 절의 가상 취소 설계이며 실제 서비스는 아직 실행하지 않았다. AS-D1 아래에서는 후보 A를 우선 분석한다. AS-Q1의 집계 A/B는 97%·94%로 검산되지만 후보 구조의 실측 결과가 아니다. I-CANCEL-v1은 미확인 결과를 거절과 구별하나, 결과 보관·재요청 기간이 미정이어서 EV-R1의 보장 범위를 닫을 수 없다. R-AE-01을 남기고 기간·만료 처리를 합의한 뒤 경계·중복·응답 유실 시험을 수행한다. 필수 조건의 미확인이 남아 실제 사용 승인은 보류한다.

좋은 보고서는 부정적인 말만 늘어놓지 않는다. 무엇이 이미 설명되었고 무엇이 미확인인지 구별하여 다음 작업이 정확해진다. 이 예에서 보고서의 마지막은 “모두 안전함”이 아니라 “어떤 근거를 갖추면 다시 판단할 수 있는가”다.

독립 연습 — 97%가 있어도 남겨야 하는 미확인

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

AS-Q1의 설명용 집계 A는 원문 그대로 970/1000이다. 그런데 같은 요청의 결과 조회 허용기간과 보관기간은 아직 합의되지 않았다. 평가자는 “97%이고 7 일 보관량이 작으니 이 구조를 실제 운영에 채택한다”고 썼다. EV-C1의 하루 1000 개·개당 2000 바이트·색인과 복제 제외 조건도 유지한다.

• 수치 조건 충족, 실제 성능 검증, 보관기간 합의, 운영 채택을 각각 판정하라.
• 14 일의 본문량을 계산하고 그 값으로 알 수 없는 것 두 가지를 적어라.

6. 10점 문제: 용어를 하나의 판단으로 연결한다

자체 작성 문제 · 실제 기출이 아님 · 10점

ATAM의 목적을 설명하고, 유틸리티 트리·민감점·트레이드오프점·위험의 관계를 예를 들어 설명하시오.

“설명”은 이름의 나열이 아니라 역할과 관계를 요구한다. 목적을 한 문장으로 밝힌 뒤 중요 장면을 고르고, 관련 속성의 영향을 분석해 위험 판단으로 연결한다. 모든 품질을 자동 인증한다는 결론은 피한다.

7. 25점 문제: 수치와 판단의 경계를 끝까지 유지한다

자체 작성 문제 · 실제 기출이 아님 · 25점

세 명이 공동 배포하는 예약 취소 서비스를 대상으로 내부 모듈을 둔 한 애플리케이션과 독립 서비스 분리안을 검토하고 있다. 제출 1,000건 중 2초 이내 올바른 확정 결과가 950건 이상이어야 한다. 제공된 설명용 집계 A는 빠른 성공 970·늦은 성공 15·오류 및 시간초과 15, 집계 B는 각각 940·40·20이다. 결과 보관기간은 미정이다. 시나리오 기반 아키텍처 평가 절차, 수치 판정, 위험·트레이드오프 분석, 선택 및 후속 확인 방안을 제시하시오.

문제는 집계와 구조 후보의 대응을 주지 않았다. 따라서 집계 A를 구조 A의 벤치마크라고 해석하면 안 된다. 수치 목표와 업무상 필수 조건을 구별하고, 보관기간 미정의 영향을 결과 조회·재요청 상황에 연결한다.

참고자료와 적용 범위

[S1] Rick Kazman, Mark H. Klein, Paul C. Clements. ATAM: Method for Architecture Evaluation. Carnegie Mellon University, Software Engineering Institute. CMU/SEI-2000-TR-004 2000-08-01. 확인 2026-09-06. 위치: §3; §5.3; §7.1–7.3; §8. Printed pp. 7–8, 16–18, 21–24, 25–39. Figure 3 (PDF page 29) and Figure 7 (PDF page 43) visually inspected. 원문: https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf

[S2] Software Engineering Institute. Architecture Tradeoff Analysis Method® Collection. Carnegie Mellon University, Software Engineering Institute. 2018-02-14. 확인 2026-09-06. 위치: Opening collection description 원문: https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/

[S3] Rob Ewaschuk. Monitoring Distributed Systems. Google SRE Book / O’Reilly. 발행일 별도 확정 안 함. 확인 2026-09-06. 위치: The Four Golden Signals: Latency and Errors; Worrying About Your Tail 원문: https://sre.google/sre-book/monitoring-distributed-systems/

[S4] Malcolm Featonby. Making retries safe with idempotent APIs. Amazon Builders’ Library. 발행일 별도 확정 안 함. 확인 2026-09-06. 위치: Late arriving requests; Same client request ID, different intent 원문: https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

[S5] Microsoft. Architecture Styles. Microsoft Learn, Azure Architecture Center. 발행일 별도 확정 안 함. 확인 2026-09-06. 위치: Architecture styles as constraints; Microservices 원문: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/

ATAM 용어·활동은 [S1]·[S2]에 근거한다. [S3]·[S4]·[S5]는 각각 측정, 재요청, 구조 비교의 제한된 원리를 뒷받침한다. 공방의 이름·가정·수치·평가표·문제·답안·자체 도식은 집필자가 작성했다. 원문 도식을 복제한 것이 아니며 실제 서비스 실험이나 정식 ATAM 보고서가 아니다.

편입 검토에서는 2026-09-06 SEI 원문 §1.1·§3·§5.3·§7.1–7.2와 Google SRE의 지연·오류 설명을 다시 대조했다. 관찰·보존과 사람 독립 승인은 서로 다른 상태다.

직접 연습: 허용 범위, 기록 수명, 도입 조건을 차례로 확인한다.

평가에서 대안을 고르려면 먼저 각 대안이 필수 조건을 만족하는지 확인한다. 다음 수치는 계산과 판단을 위한 가정이며, 실제 저장소나 아키텍처를 측정한 결과는 아니다.

1. AE-C. EV-C1의 본문 용량 식 1,000건/일 × 2,000바이트/건 × r일을 그대로 사용한다. 별도로 합의한 조건은 ‘최소 14일 보관’과 ‘이 식으로 계산한 본문 용량이 36,000,000바이트 이하’이다. 제시된 보관 기간은 7일, 14일, 18일, 30일이다. 각 용량과 허용 여부를 구하라. 정수 일수 중 선택할 수 있다면 가능한 범위는 어디인가? 대안이 7일과 30일뿐일 때 비용 점수로 하나를 승인해도 되는가?
2. AE-R. 한 결과 기록의 나이를 t시간이라고 하자. 이 연습에서 합의한 조회 허용 범위는 0 ≤ t < 10시간이고, 기록은 나이가 r시간에 도달하면 정확히 삭제된다. 원래 보관 기간 r=7시간일 때 t=6, 8, 10시간의 ‘조회 허용 여부’와 ‘기록 존재 여부’를 각각 구하라. r=10시간으로 바꾸면 어떻게 되는가? t=10시간에 기록이 없다는 이유만으로 취소 실패나 환불 완료를 응답해도 되는가? 허용 기간 이후 응답 계약은 아직 정하지 않았다.
3. AE-G. 다른 필수 조건들은 모두 만족했다고 가정하고, 여기서는 ‘소유자 검증’과 ‘성능 시나리오’ 두 조건만 판단한다. 대안 X는 각각 위반·만족, 선호 점수 95점이다. Y는 만족·미검증, 80점이고, Z는 만족·만족, 70점이다. 이 두 조건을 통과한 대안은 무엇인가? X와 Y만 있다면 반드시 하나를 골라야 하는가? Y의 미검증 항목을 닫으려면 어떤 근거가 더 필요한가? 이 표의 판단만으로 실제 운영 도입까지 승인했다고 할 수 있는가?