아키텍처 드라이버·뷰·스타일·문서화

1. 서버 그림보다 먼저 정할 것

예약 취소 화면은 멀쩡한데 같은 버튼을 두 번 누르면 결과가 달라진다고 하자. 개발자는 코드를 어디서 고칠지, 운영자는 어느 실행 단위를 다시 올릴지, 업무 담당자는 취소와 환불 중 무엇이 끝났는지 묻는다. 서버 상자 세 개를 그리는 것만으로는 이 서로 다른 질문에 답할 수 없다.

이번 절의 질문은 “어떤 요구 때문에 이 구조를 선택했고, 다른 사람이 그 결정을 어떻게 확인할 수 있는가?”다. 요구를 구조에 연결하고, 같은 구조를 관심사별로 설명한 뒤, 문서가 서로 다른 시스템을 가리키지 않는지 확인한다. 그림의 개수나 유행하는 스타일 이름을 늘리는 것이 목표가 아니다.

앞의 말은 그대로 가져온다

모델·관점·아키텍처 결정에서 모델은 목적에 맞춘 표현이고, 뷰는 관심사별 표현이며, 관점은 그 표현을 만들고 읽는 규칙이었다. 같은 절에서 아키텍처 결정은 품질속성과 제약을 만족시키기 위한 구조적 판단이었고, 질문·대안·선택 이유·비용·재검토 조건을 남겼다. 여기서는 이 뜻을 다시 정의하지 않고 실제 설계안과 문서 묶음에 적용한다.

요구·모델·업무 경계도 이어 쓴다

요구 도출·분석·명세·검증·추적의 요구공학은 제공할 것과 판정 기준의 합의 근거를 만들었고, 기능·정적·동적 모델의 기능·정적·동적 모델은 같은 요구와 조건을 설명해야 했다. 도메인 모델과 설계 경계의 문맥 경계는 업무 언어가 일관되게 적용되는 범위였지 서버나 서비스의 자동 분할선이 아니었다. 이 절에서는 미승인 업무 규칙을 확정하지 않은 채 그 요구와 경계를 구조 선택에 연결한다.

쉽게 말하면, 큰 선택의 이유를 남기는 일이다

예약 처리 코드를 하나의 프로그램 안에 둘 수도 있고, 독립된 여러 프로그램으로 나눌 수도 있다. 전자는 함께 바꾸고 배포하기 쉽지만 변경 영향이 한 실행 단위에 모일 수 있고, 후자는 각 부분을 따로 바꿀 수 있는 대신 통신 실패와 여러 상태를 조정해야 한다. 어느 쪽이 좋은지는 필요한 독립성과 운영 능력에 달려 있다.

아키텍처 설계는 뒤에서 많은 선택을 제한하게 될 구조를 요구에 맞춰 고르는 일이다. 문서화는 그 구조와 판단을 다른 사람이 읽고 검토할 수 있게 만드는 일이다. 설계와 문서화는 연결되지만, 그림을 잘 그렸다는 사실이 선택의 타당성을 대신하지는 않는다.

이 절이 담당하는 정확한 범위

소프트웨어 아키텍처는 소프트웨어의 주요 요소와 그 관계, 설계와 진화를 이끄는 원칙으로 파악하는 구조다. 이 구조를 설계할 때에는 중요한 기능·품질 요구와 제약을 근거로 책임·관계를 선택하고 그 결과와 한계를 검토한다.

아키텍처 기술서(architecture description)는 관심사에 맞는 뷰·모델과 결정 근거 등으로 아키텍처를 표현한 산출물이다. 실제 소프트웨어의 구조 자체와 이를 적어 놓은 산출물은 구분한다. 구현이 바뀌었는데 문서가 옛 구조를 설명하면, 문서가 존재해도 현행 구조를 제대로 기술한 것이 아니다.

이 절은 드라이버 선정, 후보 구조 비교, 책임·인터페이스 결정, 뷰 선택과 문서 간 대응을 다룬다. 정식 평가 방법론의 상세 절차, 전사 아키텍처, 이행 계획과 장기 변경 관리는 뒤의 담당 절에서 다룬다. ISO/IEC/IEEE 42010:2022의 공식 소개는 기술서 요구를 다루는 범위를 확인하는 데만 사용하며, 유료 표준 전문을 읽었거나 이 원고가 표준 적합성 검사를 통과했다고 주장하지 않는다.

전체 경로: 요구에서 구조, 구조에서 검증으로

화살표는 문서를 한 번씩 만들고 끝내라는 시간표가 아니다. 실행 흐름을 그리다가 책임 누락을 발견하면 앞의 구조를 고칠 수 있고, 검증 결과가 목표에 못 미치면 대안을 다시 비교한다. 핵심은 각 선택이 어느 요구에서 왔고 무엇으로 확인되는지 왕복할 수 있어야 한다는 점이다.

모든 요구가 같은 무게로 구조를 바꾸지는 않는다

아키텍처 드라이버(architecture driver)는 주요 구조 선택에 큰 영향을 주어 후보를 구별하거나 제한하는 중요한 요구·제약·업무 목표다. 기능이냐 비기능이냐만으로 드라이버 여부를 정하지 않는다. 결제 승인처럼 핵심 처리 흐름을 정하는 기능도, 장애 격리처럼 구조를 제한하는 품질 요구도 드라이버가 될 수 있다.

예를 들어 취소 화면의 버튼 색은 이 사례의 실행 단위를 나눌 이유가 되지 않는다. 반면 취소 결과를 다시 조회해도 같은 확정 상태를 보여야 한다는 요구는 저장 책임과 응답 시점을 제한한다. 같은 “중요” 표시를 붙이는 대신 이 조건이 달라지면 어떤 구조 선택이 달라지는가를 묻는다.

드라이버는 주장과 미정 조건을 분리해서 고른다

먼저 요구의 출처와 승인 상태를 확인한다. 그다음 구조에 미치는 영향, 잘못 선택했을 때의 피해, 나중에 바꾸는 비용을 설명하고 우선 검토할 조건을 고른다. 서로 충돌하는 조건이 있으면 평균 점수로 감추지 말고 어떤 조건을 반드시 지켜야 하는지 합의한다.

공방의 기존 원고에서 미정이었던 자리 반환 시점과 환불 규칙은 이 절에서도 미정이다. 아직 합의하지 않은 “취소와 동시에 환불도 반드시 완료된다”를 드라이버에 넣으면 그 뒤의 구조와 시험은 잘못된 전제 위에 선다. 설계자는 미정을 숨기는 대신 질문, 결정 책임자, 판단에 필요한 자료, 확정 전 제한 범위를 문서에 남긴다.

품질 요구를 판정 가능한 장면으로 바꾼다

품질속성 시나리오는 어떤 주체가 어떤 자극을 주었을 때, 정해진 환경의 대상이 어떻게 반응하고 그 반응을 무엇으로 측정할지 구체화한 설명이다. 여기서는 자극원, 자극, 환경, 대상, 반응, 반응 측정의 여섯 부분을 사용한다. 여섯 용어를 외우기보다 빠진 칸 때문에 서로 다른 시험을 떠올리지 않는지 확인한다.

가령 “취소가 빠르다”에는 부하도 성공의 뜻도 없다. “정상 운영 환경에서 유효한 취소 요청이 들어오면 대상 서비스가 확정 결과를 돌려주고, 정한 전체 요청 중 일정 비율이 제한시간 안에 완료된다”까지 적으면 시험할 장면이 드러난다. 수치의 출처와 승인 여부는 시나리오의 구체성과 별개다.

가상 시나리오 AS-Q1: 분모까지 고정한다

아래는 기존 요구의 승인 결과가 아니라 이 절에서 독립적으로 만든 아키텍처 연습 조건 AS-Q1이다. 정상 저장 환경에서 서로 다른 시험용 예약의 유효한 취소 요청 1,000건을 같은 시험 시작 시점에 제출한다고 가정한다. 각 요청의 시작부터 확정 결과 수신까지를 측정하며, 전체 제출 1,000건 중 2초 이내 성공이 최소 950건이어야 한다는 가상 목표를 둔다.

자극원은 시험용 호출자, 자극은 유효한 취소 요청, 환경은 명시한 정상 상태와 부하, 대상은 취소 서비스다. 반응은 저장된 확정 결과의 반환이고, 반응 측정은 요청별 2초 이내 성공 여부와 전체 제출 건수 기준 비율이다. 오류나 시간초과를 분모에서 빼면 목표를 바꾸게 된다. 이 한 장면은 장애 중 성능이나 실제 운영의 모든 부하를 대표하지 않는다.

가상 집계 A: 제출 1000건 = 2초 이내 성공 970건 + 늦은 성공 15건 + 오류·시간초과 15건
판정 A: 970 / 1000 = 97.0%, 최소 95.0% 이상 → 이 가상 수치 조건 충족
가상 집계 B: 제출 1000건 = 2초 이내 성공 940건 + 늦은 성공 40건 + 오류·시간초과 20건
판정 B: 940 / 1000 = 94.0%, 최소 95.0% 미만 → 이 가상 수치 조건 미충족

집계 A가 통과하더라도 구조 덕분에 빨라졌다는 인과관계는 증명되지 않는다. 실제 검증에서는 같은 데이터·자원·부하로 후보를 비교하고 정확한 취소 결과도 확인해야 한다. 여기에는 부하 발생기나 운영 서비스를 실행해 얻은 실측값이 없다.

2. 스타일은 제약을 선택하는 도구다

아키텍처 스타일(architecture style)은 사용할 요소와 관계에 일정한 제약을 두어 비슷한 구조적 특성을 갖게 하는 설계 방식이다. 상자 모양이나 제품 브랜드를 뜻하지 않는다. 어떤 관계를 허용하고 금지하는지 알아야 얻는 이점과 비용을 판단할 수 있다.

스타일을 고르기 전에 반드시 필요한 기능 흐름, 품질 요구, 팀의 운영 능력을 적는다. 한 후보가 필수 조건을 어기면 다른 항목의 장점이 많아도 그대로 채택하지 않는다. 다음 비교는 전체 스타일의 목록이 아니라, 이 사례의 책임·배포·통신 선택을 설명할 후보들이다.

계층은 논리적 책임이고 티어는 물리적 배치다

앞에서 배운 계층을 취소 처리에 적용하면 요청 해석, 업무 판단, 저장 접근의 책임을 나눌 수 있다. 이 절에서 티어(tier)는 실행 요소를 물리적으로 나누어 배치한 층을 가리킨다. 논리 계층 세 개를 프로그램 하나에 함께 둘 수도 있으므로 세 계층이 항상 서버 세 대라는 뜻은 아니다.

엄격하게 바로 아래 계층만 사용하는 구조는 경계를 추적하기 쉽지만 전달 단계가 늘 수 있다. 아래 여러 계층으로 접근을 허용하면 경로를 줄일 여지가 생기는 대신 의존 관계가 더 복잡해진다. “계층형”이라고만 적지 말고 허용한 의존 방향과 우회 금지 범위를 함께 남긴다.

이 절의 뒤 도식은 소스 의존 관계를 별도로 표시한다. 실행 중 호출이 어디로 가는지와 코드가 어떤 인터페이스에 의존하는지는 다른 질문이므로, 두 화살표를 같은 것으로 읽지 않는다.

모듈로 나누되 한 번에 배포할 수 있다

모듈형 모놀리스(modular monolith)는 내부 책임과 의존 경계를 모듈로 구분하면서 애플리케이션을 하나의 배포 단위로 제공하는 구조다. 여기서 모듈은 앞에서 배운 책임 분리의 적용이고, 한 배포 단위라는 조건이 핵심이다. 폴더를 여러 개 만들었어도 모든 코드가 서로의 내부 상태를 직접 바꾸면 책임 경계가 유지된 것은 아니다.

취소와 예약 규칙을 한 프로그램 안에 두면 프로그램 간 호출 없이 같은 실행 경로에서 판단할 수 있다. 다만 함께 배포하므로 변경이 무관한 기능에도 회귀검사를 요구할 수 있고, 같은 프로세스의 자원 장애가 여러 기능에 영향을 줄 수 있다. 모듈형이라는 이름만으로 독립 배포나 장애 격리를 얻었다고 쓰지 않는다.

마이크로서비스는 독립성의 운영비용까지 선택한다

마이크로서비스 아키텍처는 업무 기능별로 책임을 나눈 서비스를 독립적으로 배포·운영할 수 있도록 구성하는 접근이다. 서비스가 작다는 형용사보다 실제 변경·배포·데이터 책임의 자율성이 중요하다. 서로 다른 팀이 다른 주기로 기능을 바꾸어야 한다면 독립성이 후보의 이점이 될 수 있다.

프로그램 경계를 넘으면 요청이 늦거나 응답이 사라지는 부분실패가 생긴다. 한 작업이 여러 서비스의 상태를 바꾸면 성공을 어떻게 판단할지 별도 설계가 필요하고, 서비스별 버전·관찰·시험·운영 책임도 늘어난다. 따라서 단순히 요청이 많거나 업무 용어가 둘이라는 이유로 분리하지 않는다.

앞 절의 예약 문맥과 정산 문맥을 코드 모듈로 나눌지 독립 서비스로 나눌지는 이번 구조의 선택이다. 문맥은 의미의 경계, 배포 단위는 운영의 경계이므로 하나가 다른 하나의 개수를 자동으로 정하지 않는다.

이벤트 기반 연결은 또 다른 축이다

이벤트 기반 아키텍처(event-driven architecture)는 발생한 사실을 알리는 이벤트의 생산·전달·소비를 중심으로 요소를 연결하는 구조다. 취소 확정이라는 사실을 전달하면 알림 담당 요소가 나중에 이를 처리할 수 있다. 이때 취소 확정과 알림 발송 완료는 서로 다른 완료다.

생산자는 모든 소비자의 내부 실행을 직접 호출하지 않고 변화를 알릴 수 있지만, 처리 지연·중복·순서·실패를 다루어야 한다. 이벤트를 보냈다는 사실만으로 소비자가 원하는 업무를 끝냈다고 표시하면 안 된다. 또한 저장 확정과 이벤트 전달을 어떻게 일치시킬지 별도 검증 없이 안전하다고 가정하지 않는다.

이벤트 기반 연결은 한 프로그램 안에서도, 여러 서비스 사이에서도 사용할 수 있다. 그러므로 계층형·모놀리스·마이크로서비스·이벤트 기반을 전부 같은 차원의 배타적인 네 제품처럼 비교하지 않는다. 이번 취소 핵심 경로에는 이벤트 전달 계층을 새로 도입하지 않고, 필요한 조건이 생겼을 때 별도 검토 대상으로 남긴다.

같은 질문으로 비교하고 서로 다른 축은 분리한다

이 표는 트래픽만으로 승자를 고르지 않는다. 한 배포 단위도 여러 인스턴스로 실행할 수 있고, 서비스를 나누어도 공유 병목이 남으면 확장이 제한된다. 구체적인 확장·고가용성 수치는 배치와 시험 조건을 별도로 검토해야 한다.

계층은 논리적 책임 관계, 티어는 물리 배치, 이벤트는 요소의 상호작용 방식이다. 따라서 먼저 어느 축을 바꾸려는지 적고, 같은 축의 후보끼리 조건과 비용을 비교한다.

AS-D1: 작은 운영 범위에서 후보를 선택한다

AS-D1은 기존 공방의 확정 사실이 아닌 이 절의 가상 설계 조건이다. 개발·운영 담당 세 명이 예약·취소를 같은 배포 주기로 관리하고, 당장은 독립 서비스별 운영 체계를 유지하지 않는다고 가정한다. 이번 구현 범위는 취소 요청의 판정, 저장된 확정 결과, 그 결과의 조회이며, 환불 자동 실행과 자리 반환 정책 결정은 범위 밖이다.

후보 A는 내부 모듈을 분리한 하나의 애플리케이션과 저장소이고, 후보 B는 예약·취소를 각각 독립 서비스로 나누는 구조다. 현재 조건에서는 독립 배포의 이점보다 조정·운영 책임 증가가 커서 A를 선택하는 검토용 결정을 둔다. 모든 대학·공방·소규모 조직에 적용되는 처방이 아니라 이 가정 아래의 선택이다.

A에서도 저장 장애와 중복 요청은 사라지지 않는다. 확정 응답은 저장 결과를 확인한 뒤 반환하고, 불확실한 요청은 결과 조회로 확인하게 하는 계약이 필요하다. 운영 단위가 하나라는 이유만으로 품질 요구를 충족했다고 판정하지 않는다.

언제 같은 결정을 다시 보아야 하는가

독립 서비스 후보를 지금 기각한 이유와 다시 검토할 조건을 함께 남긴다. 다른 팀이 서로 다른 배포 주기로 기능을 운영하게 되거나, 특정 책임만 독립 확장해야 하는 실측 근거가 생기면 현재 결정의 전제가 달라진다. 구조를 미리 크게 나누는 대신 현재 모듈 경계의 책임과 계약을 유지하고 그 변화가 실제로 필요한지 판단한다.

반대로 한 팀의 모든 기능이 항상 함께 바뀌는데 서비스 개수만 늘리면 배포 순서와 통신 계약의 부담만 커질 수 있다. 앞으로 나눌 수 있다는 말도 무료 변경을 보장하지 않는다. 데이터 책임, 인터페이스, 운영 책임을 다시 검토해야 하므로 재검토 조건은 자동 전환 명령이 아니라 새 판단을 시작할 근거다.

3. 같은 구조를 세 관심사로 설명한다

모듈 뷰는 소프트웨어를 구성하는 책임 단위와 그 사이의 코드 의존 관계를 중심으로 보여 주는 표현이다. 실행 뷰는 요청 처리 중 동작하는 요소의 상호작용과 상태·실패의 흐름을 중심으로 보여 주는 표현이다. 두 표현은 앞에서 배운 뷰의 구체적인 적용이다.

코드 검토자는 “저장 기술을 바꾸면 어느 코드가 영향을 받는가?”를 묻고, 장애 분석자는 “저장 응답을 받지 못한 요청은 어떤 상태로 남는가?”를 묻는다. 첫 질문에는 의존 관계가, 둘째 질문에는 실행 순서와 실패 경계가 필요하다. 같은 화살표를 설명 없이 재사용하면 컴파일 의존성과 실행 호출을 혼동하게 된다.

확정과 응답의 경계를 복습한다

트랜잭션의 네 성질(ACID)에서 트랜잭션은 함께 성공하거나 실패할 작업 경계이고 커밋은 그 작업의 완료 확정이었다. 시간초과·재시도·멱등성과 부분실패에서는 시간초과만으로 상대의 실행 실패를 확정할 수 없으며 같은 요청 식별자와 결과 확인으로 중복 효과를 통제했다. 여기서는 이 원리를 저장 계약과 응답 상태에 적용한다.

먼저 이름과 책임을 고정한다

가상 설계의 식별자는 그림이 바뀌어도 같은 책임을 가리키도록 정한다. M-ENTRY는 요청 형식과 응답 변환, M-USECASE는 취소 처리 순서, M-RESERVATION은 예약의 업무 규칙을 맡는다. M-STORE-PORT는 저장에 필요한 동작의 계약이고 M-STORAGE는 실제 저장 기술로 그 계약을 수행한다.

포트(port)는 이 예에서 업무 처리에 필요한 외부 동작을 내부 쪽에서 요구하는 인터페이스 계약이다. 어댑터(adapter)는 그 계약을 구체적인 저장소나 외부 기술에 연결하는 구현이다. 네트워크 포트 번호를 뜻하지 않는다. 예컨대 저장이 성공했는지 돌려주는 계약은 그대로 두고 저장 기술별 호출을 어댑터에 모을 수 있다.

이 분리가 검증되지 않은 동시성 보장을 만들어 주지는 않는다. 취소 상태 전이와 요청 식별자별 결과를 어떻게 함께 확정할지는 저장 계약과 실제 구현에서 확인해야 한다. 이름만 인터페이스로 바꾸고 각 모듈이 저장소를 직접 우회 호출하면 경계가 깨진다.

모듈 뷰: 화살표는 코드 의존이다

애플리케이션을 시작할 때 저장 어댑터를 포트의 실제 구현으로 연결한다고 가정한다. 처리 중에는 그 연결을 통해 저장 동작이 실행되지만, M-USECASE의 코드는 특정 저장 제품의 구현이 아니라 M-STORE-PORT 계약을 참조한다. 그림에 실제 DB 서버를 넣지 않은 것은 이것이 물리 배치도가 아니라 코드 의존도이기 때문이다.

M-RESERVATION에서 M-STORAGE로 직접 의존하는 경로는 이번 설계에서 허용하지 않는다. 이렇게 해야 업무 규칙을 검토할 때 저장 제품의 호출 코드까지 따라가는 결합을 줄일 수 있다. 단, 폴더 이름이나 화살표가 실제 소스의 금지 의존을 검사해 주지는 않으므로 코드 검사와 함께 확인해야 한다.

인터페이스에는 정상 결과와 모르는 결과를 함께 적는다

가상 취소 계약 I-CANCEL-v1은 신원이 확인된 호출자의 예약 식별자와 요청 식별자를 받으며, 호출 주체와 신뢰할 접수시각은 서버가 확인한 문맥으로 사용한다고 가정한다. 유효한 요청이라도 업무 조건을 만족하지 않으면 거절될 수 있으므로, 입력 형식 통과와 취소 성공은 구별한다. 응답 상태는 CONFIRMED(취소 확정), REJECTED(판정된 거절), UNKNOWN(현재 요청 결과 미확인)으로 나누며 요청 식별자로 결과 조회가 가능해야 한다고 가정한다.

가상 저장 계약 I-STORE-v1은 취소 상태 전이와 해당 요청의 결과 기록을 같은 로컬 확정 경계로 처리하도록 요구한다. 중복된 동일 식별자·동일 내용은 기존 결과를 확인하고, 같은 식별자를 다른 내용에 재사용하면 거절한다. 식별자의 유효 범위는 같은 호출 주체의 같은 작업이고, 보관·재요청 허용기간과 그 이후의 조회·오류 처리는 운영 전에 정해야 한다. 이것은 이 사례에서 선택한 계약이며 실제 DB에서 동시 실행과 장애 복구를 검증한 결과가 아니다.

CONFIRMED는 취소 저장 결과의 확정을 뜻하며 환불 완료를 뜻하지 않는다. 취소가 확정된 뒤 응답만 유실되면 다시 보내기 전에 같은 식별자로 조회하여 결과를 확인한다. 인증·인가·감사 기록의 상세 구현은 이 절에서 승인하지 않으며, 실제 서비스에서는 앞의 보안 요구에 맞게 별도 확인해야 한다.

실행 뷰: 언제 확정을 알려 주는가

앞의 업무 판단 뒤 저장할 때에는 다른 요청이 이미 상태를 바꾸지 않았는지 같은 확정 경계에서 다시 확인해야 한다. 먼저 읽은 판정을 확인 없이 저장하는 것으로 동시 요청의 안전성이 확보되지는 않는다.

이 그림의 화살표는 실행 중 전달이며 앞 그림의 코드 의존과 다르다. 실행 시 M-USECASE가 포트에 연결된 저장 어댑터를 사용하더라도 코드가 저장 구현에 직접 의존해야 하는 것은 아니다. 따라서 두 그림의 화살표 방향이 단순히 같아야 일치하는 것도 아니다.

실패 경로에서 UNKNOWN을 REJECTED로 바꾸면 실제로 확정된 취소를 실패라고 알릴 수 있다. 반대로 저장 확인 전 CONFIRMED를 반환하면 확정되지 않은 결과를 약속할 수 있다. 문서에는 정상 순서뿐 아니라 무엇을 확인한 뒤 어떤 상태를 알리는지가 있어야 한다.

배치 뷰는 실행 인스턴스를 장소와 자원에 연결한다

배치 뷰는 소프트웨어의 실행 인스턴스를 노드·실행 환경·기반시설에 대응시키고 그 통신 경계를 보여 주는 표현이다. 같은 소프트웨어 정의에서 여러 인스턴스를 실행할 수도 있으므로 소프트웨어 이름과 실행 사본의 개수를 구별한다. 어디에서 고장 나고 무엇이 함께 영향을 받는지 보려면 배치 정보가 필요하다.

이번 최소 사례는 애플리케이션 실행 인스턴스 APP-1을 N-APP에, 저장소 인스턴스 DB-1을 N-DATA에 둔다. APP-1에는 앞의 다섯 모듈이 모두 포함되며 저장 어댑터가 DB-1에 접근한다. 이것은 각 책임에 서버를 하나씩 배치했다는 그림이 아니다.

배치 예: 노드 두 개가 고가용성을 뜻하지는 않는다

이 그림에서는 애플리케이션과 저장소가 서로 다른 책임의 노드에 하나씩 놓여 있다. 둘이 서로의 대체 사본인 것은 아니므로 어느 한쪽이 중단되어도 서비스를 계속할 수 있다고 주장하지 않는다. 고가용성 목표가 필수라면 그 목표에 맞는 사본·장애영역·확정·복구 설계가 추가로 필요하다.

AS-Q1의 정상 상태 성능 조건만으로 장애 상태의 서비스 지속을 인증하지 않는다. 배치 후보에는 자원 한도, 통신 경계, 필요한 비밀정보 관리와 관측 항목을 명시하고 실제 환경에서 검증해야 한다. 이 최소 도식은 생산 환경의 완전한 보안·운영 설계서가 아니다.

C4를 사용할 때도 표현 수준과 배치를 구별한다

C4의 컨테이너(container)는 애플리케이션이나 데이터 저장소와 같은 실행·저장 단위를 설명하는 추상화다. 반드시 Docker 컨테이너라는 뜻은 아니다. C4의 컨텍스트 그림은 사용자·외부 시스템과의 관계를, 컨테이너 그림은 시스템 내부의 주요 애플리케이션·저장소와 통신을 설명하는 데 쓸 수 있다.

이번 사례의 다섯 코드 모듈을 다섯 C4 컨테이너로 기계적으로 올리지 않는다. 한 애플리케이션 안의 책임 모듈과 별도로 실행되는 애플리케이션은 다른 수준이다. 실행 사본을 실제 노드에 대응시키려면 배치 표현을 별도로 사용한다.

C4의 모든 수준을 반드시 그리는 것이 목표도 아니다. 독자가 현재 판단해야 할 질문에 필요한 수준을 고르고 범례·책임·관계를 설명한다. C4를 사용했다는 사실과 ISO/IEC/IEEE 42010의 적합성은 별개의 주장이다.

문서끼리 같은 시스템을 설명하는지 검사한다

모듈 뷰에는 저장 포트가 있는데 실행 뷰에는 임의의 결제 서비스만 있다면 실제 저장 경로가 빠졌을 수 있다. 실행 뷰의 CONFIRMED가 인터페이스의 취소 확정을 뜻하는데 화면에서는 환불 완료라고 표시하면 의미가 어긋난다. 같은 식별자를 쓰는 것뿐 아니라 책임과 상태의 뜻까지 대조한다.

구조 검사는 등장한 모듈이 실제 정의되어 있는지, 실행 요소가 배치에 연결되는지, 인터페이스의 버전이 맞는지를 찾는 데 유용하다. 그러나 동일한 이름의 잘못된 정의는 참조 검사만으로 발견되지 않는다. 참조가 존재하는가와 그 참조가 옳은 의미로 사용되었는가는 다른 검사다.

이 사례에서 다루는 정적 검사는 다섯 모듈의 참조·배치 대응, 허용 코드 의존 관계, I-CANCEL-v1의 이름·버전 같은 정적 조건만 확인한다. 실제 동시성, 응답 유실, 외부 환불, 보안, 성능을 실행 검증한 것으로 확대하지 않는다.

4. 결정 이유와 검증 근거를 문서로 묶는다

아키텍처 결정 기록(Architecture Decision Record, ADR)은 하나의 중요한 아키텍처 결정에 대해 맥락·상태·선택·결과를 남기는 짧은 기록이다. 앞 절에서 배운 질문·대안·비용·재검토 조건을 실제 결정 한 건에 적용하는 형식이다. 문서가 짧다는 것은 근거를 생략한다는 뜻이 아니다.

채택하지 않은 대안과 불리한 결과도 남긴다. 결정이 바뀌면 이전 기록을 현행인 것처럼 숨기지 않고 대체 관계를 연결해 왜 판단이 바뀌었는지 확인할 수 있게 한다. 이것은 과거 결정의 증거를 보존하는 일이지, 낡은 구현 경로를 호환 계층으로 계속 실행하라는 뜻이 아니다.

가상 ADR-AS-001: 지금 독립 서비스로 나누지 않는 이유

상태: 제안. 맥락은 AS-D1의 세 명 팀, 공동 배포 주기, 취소 확정·조회라는 작은 구현 범위다. 질문은 예약·취소 책임을 별도 서비스로 배포할지다. 검토한 대안은 내부 모듈을 둔 한 애플리케이션과 독립 서비스 분리다.

선택: 내부 모듈을 둔 한 배포 단위. 이유는 현재 필요한 책임 분리를 유지하면서 서비스 간 버전·통신·운영 조정을 늘리지 않기 위해서다. 감수하는 결과는 공동 배포, 실행 자원 결합, 변경 영향 검토 범위이며, 별도 배포의 필요가 입증되면 다시 검토한다.

연결한 근거는 AS-Q1의 품질 시나리오와 I-CANCEL-v1·I-STORE-v1, 모듈·실행·배치 뷰다. 성능 실측, 동시성·장애 검증, 요청 식별자의 보관·재요청 기간 합의, 운영 책임자의 승인은 아직 없다. 따라서 이 기록의 상태를 채택 완료나 구현 검증 완료로 올리지 않는다.

설계 논점의 실제 연결: 요구–대안–책임–확정 경계

AS-D1의 공동 배포·작은 운영 범위는 한 배포 단위 후보를 선택할 근거가 된다. 취소 결과의 정확한 반환 요구는 M-USECASE의 처리 순서와 I-STORE-v1의 확정 계약으로 연결한다. 역할을 나누는 것만으로 정확성이 생기지 않으므로, 저장 확인 뒤 성공 응답·식별자별 결과 조회·실패 상태의 분리를 함께 요구한다.

AS-Q1은 이 구조가 실제 부하에서 목표를 만족하는지 확인할 시험 조건이다. 후보를 골랐다는 이유로 95% 목표를 통과 처리하지 않고, 결과가 나쁘면 병목·자원·요구·구조를 대조한다. 이처럼 요구마다 선택한 요소·관계와 확인 방법을 이어야 설계의 근거가 된다.

문서화 논점의 실제 연결: 독자–관점–뷰–대응–판본

문서 묶음에는 범위와 미정 사항, 관심사별 뷰, 요소·관계·인터페이스의 뜻, 선택 근거, 검증 상태를 함께 둔다. 코드 검토자는 모듈 뷰와 금지 의존, 운영자는 실행·배치 뷰와 실패 상태, 업무 담당자는 취소와 환불의 서로 다른 완료를 확인하도록 연결한다. 같은 시스템을 다른 관심사로 설명하되 식별자와 계약의 의미는 유지한다.

뷰별로 무엇을 점·선·화살표로 표현하는지 설명하고 대응 대상을 적는다. 문서 판본, 대상 구현 판본, 결정 상태, 미해결 이슈와 검토자를 기록하며 구현이 바뀌면 관련 뷰·계약·시험 근거도 다시 확인한다. 뷰를 여러 개 보유하는 것이 아니라 같은 판본의 구조와 결정을 일관되게 설명하는 것이 문서화의 핵심이다.

저장 기술 변경을 문서로 추적해 본다

가상 변경 CH-AS-1은 저장 어댑터의 구현 기술 교체이며, 취소 가능 조건과 I-CANCEL-v1의 의미는 그대로라고 가정한다. 모듈 뷰에서는 M-STORAGE의 구현과 계약 수행 여부를, 실행 뷰에서는 저장 성공·거절·결과 불명의 처리를, 배치 뷰에서는 새 저장 환경과 연결을 확인한다. 포트가 있으니 다른 확인이 필요 없다는 결론은 틀리다.

업무 규칙 파일을 수정하지 않았다는 사실은 변경 영향의 단서일 뿐, 결과가 같다는 증명이 아니다. 기존 예약 상태, 동일 요청 반복, 같은 식별자에 다른 내용, 저장 응답 유실의 결과 조회를 같은 의미로 다루는지 확인해야 한다. 미확인 항목이 있으면 변경 기록과 ADR에 남기고 시험 완료로 표시하지 않는다.

저장 응답 한 번만 유실되도록 조건을 바꿔 다음 응답을 예상해 보자. 요청 식별자 K1로 취소 상태와 결과가 함께 확정됐지만 APP-1이 그 응답을 받지 못했다면, APP-1이 당장 아는 상태는 UNKNOWN이다. 식별자 K1로 조회하여 기존 확정 결과를 확인한 뒤에는 CONFIRMED를 알릴 수 있다. 처음부터 REJECTED라고 쓰면 실행 여부를 모른다는 사실을 업무 거절로 바꾼 것이고, 새 식별자로 다시 취소하면 같은 요청인지 확인할 근거를 잃는다. 인터페이스에는 정상 결과와 모르는 결과를 함께 적는다의 세 응답 뜻과 실행 뷰: 언제 확정을 알려 주는가의 저장 확인 순서로 돌아가 저장소의 실제 상태와 호출자가 현재 확인한 사실을 따로 적는다. 이 둘을 구별하는 설명이 앞의 모듈·실행·배치 뷰를 실제 변경 검토에 적용하는 중간 단계다.

설계·문서화가 실패하는 다섯 가지 방식

유행어 선행은 독립 배포가 필요한지 확인하기 전에 서비스부터 나누는 경우다. 징후는 모든 변경을 동시에 배포하는데 서비스 간 조정만 늘어나는 것이며, 실제 변경·운영 단위로 대안을 다시 비교해야 한다. 그림 선행은 요소와 화살표는 있지만 대응하는 요구·책임·계약이 없는 경우다.

정상 경로만 기술하면 저장 응답 유실을 실패 확정으로 오인하거나 취소 확정을 환불 완료로 과장할 수 있다. 관점 혼합은 코드 의존·실행 호출·물리 배치를 한 화살표로 그려 변경 영향과 장애 경계를 잘못 읽게 한다. 판본 단절은 구현을 고친 뒤 옛 뷰와 계약을 현행 문서로 배포하는 경우다.

대책은 그림을 더 붙이는 데서 끝나지 않는다. 중요한 요구와 선택 이유를 연결하고, 정상·거절·불확실 상태를 계약에 적으며, 뷰별 범례와 대응을 확인하고, 실제 변경 범위의 문서·시험 근거를 같은 판본으로 묶는다. 인쇄된 문서와 코드의 날짜가 같다는 사실만으로 내용까지 일치했다고 보지는 않는다.

검토할 때 무엇을 보고 무엇을 남기는가

먼저 설계 검토에서는 필수 요구를 누락하지 않았는지, 대안 비교축이 같은지, 채택 이유가 실제 제약에서 나오는지 확인한다. 다음 문서 검토에서는 관심사에 필요한 뷰가 있는지, 책임과 상태의 의미가 일치하는지, 그림 사이에 누락·중복·잘못된 대응이 있는지 살핀다. 마지막으로 검증 근거와 미실행 항목을 분리한다.

이 작은 사례의 관측 후보는 제출 대비 제한시간 이내 확정 비율, 오류·결과 미확인 요청 수, 식별자별 조회로 확정된 결과, 계약 위반·문서 불일치다. 수치 목표는 승인된 요구에서 가져와야 하고, 도구가 기록을 남겼다는 사실만으로 해석까지 정확하다고 판단하지 않는다. 다음 아키텍처 평가와 트레이드오프에서는 구조를 평가하고 상충하는 품질 요구를 판단하는 방법을 이어 다룬다.

독립 연습 — 저장 기술을 바꿀 때 어느 뷰부터 달라지는가

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

APP-1의 저장 구현 M-STORAGE를 교체하되 M-STORE-PORT와 I-STORE-v1의 의미, 한 배포 단위 및 공동 운영 조건은 유지한다고 가정한다. 검토자가 “저장 구현을 바꿨으니 예약 규칙 M-RESERVATION도 새 DB 라이브러리에 직접 의존하게 하자”고 제안한다.

• 본문의 코드 의존 방향을 근거로 제안을 판단하라.
• 모듈 뷰의 확인과 저장 응답 유실·재요청 실행 확인이 서로 대신하지 못하는 이유를 쓰라.

5. 이해를 시험 답안으로 바꾼다

10점: 아키텍처 드라이버와 아키텍처 기술서의 역할을 설명하고, 구조 선택의 근거와 관심사별 뷰를 연결하는 방법을 제시하시오.

이 문제는 기출 전재가 아닌 자체 제작 문항이다. 역할 설명은 구조를 바꾸는 조건과 구조를 표현하는 산출물을 구별하라는 요구다. 연결 방법은 드라이버 이름과 그림 종류만 나열하지 말고, 대안 선택의 이유가 뷰·계약·검증에 어떻게 남는지 설명하라는 요구다.

25점은 선택을 실제 구조와 통제로 내려야 한다

25점: AS-D1의 공동 운영·공동 배포 조건에서 예약 취소 기능의 아키텍처 후보를 비교·선정하고, AS-Q1·정상 및 실패 흐름·관심사별 뷰·결정 기록·검증 방안을 설명하시오.

이 문항도 자체 제작이다. AS-D1과 AS-Q1은 본문에서 제시한 가상 조건이고 실제 공방의 승인 요구가 아니다. 자리 반환 정책과 환불 자동 실행을 이번 범위에 몰래 추가하지 않는다.

목차는 요구·조건, 대안·선택, 계약·실패, 뷰·대응, 문서·판본, 검증의 여섯 요구를 받는다. 아래 답안은 논점과 연결을 확인하는 작성 예이며 제한시간 필기 재현성을 사람에게 검증받은 답안은 아니다.

직접 연습: 빠른 오답, 같은 이름의 다른 뜻, 같은 노드의 두 사본을 구별한다.

아래 집계와 배치 변경은 별도의 설명용 조건이다. 계산을 만족한 것, 문서의 뜻이 맞는 것, 실제 환경에서 요구를 지킨 것을 각각 구분하여 답한다.

1. AR-Q. 별도 시험 조건은 전체 제출 400건 중 정확한 확정 결과를 2초 이내 받은 요청이 최소 95%여야 한다는 것이다. 집계는 2초 이내 정확한 성공 378건, 2초 이내 오답 7건, 늦은 정확한 성공 9건, 오류·시간초과 6건이다. 조건을 만족하는가? 오답까지 빠른 성공으로 세면 어떤 잘못된 비율이 나오는가? 다른 건수는 유지하고 빠른 오답 중 일부가 제한시간 이내 정확한 성공으로 바뀐다는 가정에서 최소 몇 건이 바뀌어야 하는가? 이 계산이 그런 수정 방법의 실측 성능까지 증명하는가?
2. AR-V. 문서의 모듈 이름과 I-CANCEL-v1 참조가 모두 존재하는 것은 확인했다. 그러나 화면은 CONFIRMED를 ‘환불 완료’로 표시하고, 실패 흐름 설명은 UNKNOWN을 ‘업무 거절 확정’으로 설명한다. 한편 모듈 뷰에는 M-STORAGE→M-STORE-PORT 의존이, 실행 뷰에는 포트에 연결된 M-USECASE→M-STORAGE 호출이 있다. 세 관측을 각각 판단하라. 이름 존재 검사에 통과했으니 모두 옳다고 해도 되는가?
3. AR-D. 본문 APP-1과 같은 다섯 모듈을 가진 애플리케이션을 두 실행 사본 APP-A·APP-B로 늘리되, 둘 다 같은 물리 노드 N-APP에 둔다. DB-1은 N-DATA의 한 저장소 인스턴스이며 대체 사본은 없다. 애플리케이션은 같은 판본으로 함께 배포한다. 내부 모듈 정의 수, 애플리케이션 실행 사본 수, 저장소를 포함한 실행 인스턴스 수, 물리 노드 수는 각각 얼마인가? N-APP 전체가 중단되면 남는 애플리케이션 사본은 몇 개인가? 사본이 둘이라는 이유로 마이크로서비스나 고가용성 검증 완료라고 판단해도 되는가?