기술 아키텍처 발표에서는 세 가지를 순서대로 보여 주세요. 시스템이 전체 구조에서 어디에 있는지, 중요한 요청 하나가 어떤 경로로 처리되는지, 제안한 방식이 다른 대안보다 적합한 이유입니다. 마지막에는 필요한 결정을 제시합니다. 구성 요소를 그린 그림만으로는 동작 방식이나 설계에서 무엇을 얻고 포기하는지 설명할 수 없습니다.
아래에서는 가상의 소매업체 주문 서비스를 예로 듭니다. 이 팀은 주문 접수와 출고 처리 사이에 큐를 도입하려고 합니다. 발표 자료는 개발팀과 운영팀이 이 변경을 시범 적용할지 판단하도록 돕기 위한 것이며, 실제 운영 시스템의 설계안은 아닙니다.
다이어그램과 비교 내용이 준비되면 Presenti로 아키텍처 개요를 편집 가능한 슬라이드로 만들어 보세요. AI에 시스템 설계 자체를 맡기는 대신 설계의 근거도 입력해야 합니다. 그래야 초안에서도 의미 있는 설명 순서를 잡을 수 있습니다.
청중이 승인해야 할 변경부터 명확히 정하기
슬라이드를 만들기 전에 필요한 결정을 적습니다. “결제 승인은 현재 처리 경로에 유지하고, 접수된 주문의 출고 처리를 비동기화하는 시범 적용을 승인한다.” 논의 범위도 덧붙이세요. 결제 업체 연동, 데이터베이스 교체, 결제 절차 전체의 재설계는 이번 논의에서 제외합니다.
이 문장이 발표에 넣을 세부 사항의 기준이 됩니다. 운영 책임자는 출고 작업이 지연됐을 때 어떤 상태로 나타나는지 알아야 합니다. 개발 책임자는 재시도와 중복 이벤트를 어떻게 처리하는지 알아야 합니다. 어느 쪽도 회사의 모든 서비스를 차례로 소개받을 필요는 없습니다. 예상 사용자 동작에 아직 이견이 있다면 제품 요구사항 발표 자료에서 먼저 합의한 뒤 이번 검토에서 아키텍처를 선택하도록 하세요.
시스템과 주변 시스템의 관계부터 설명하기
고객, 결제 절차를 진행하는 애플리케이션, 주문 서비스, 결제 업체, 출고 서비스를 포함한 맥락도를 사용하세요. 관계를 화살표만으로 표시하지 말고 목적을 적습니다. “API”보다 “결제 승인”이 더 많은 정보를 전달합니다. 논의 대상인 주문 서비스를 명시하고 외부 시스템은 그 경계 밖에 표시합니다.
C4 시스템 맥락도 가이드는 세부 구조를 소개하기 전에 시스템, 사용자, 연결된 시스템을 넓은 관점에서 보여 줄 것을 권합니다. 관점을 이렇게 나누기 위해 C4의 모든 다이어그램을 사용할 필요는 없습니다.
주문 한 건을 접수부터 출고 처리까지 따라가기
제안한 큐가 무엇을 바꾸는지 번호를 붙인 흐름으로 설명합니다. 다음은 가상의 소매업체를 위한 예시입니다. 표와 그림의 번호를 맞추면 발표자가 해당 상자를 찾느라 헤매지 않고 각 단계를 가리킬 수 있습니다.
| 단계 | 상호 작용 | 청중이 이해해야 할 점 |
|---|---|---|
| 1 | 결제 애플리케이션이 주문 서비스로 주문 요청을 전송 | 전체 흐름에서 추적할 수 있는 주문 ID를 요청에 포함 |
| 2 | 주문 서비스가 결제 승인을 확인 | 결제가 거절되면 출고 작업을 생성하지 않음 |
| 3 | 주문 서비스가 접수된 주문과 전송 대기 이벤트를 기록 | 주문을 기록한 뒤 이벤트를 발행하기 전에 발생하는 장애도 설계에서 고려 |
| 4 | 발행 프로세스가 대기 중인 이벤트를 큐로 전송 | 발행을 재시도할 수 있으므로 이벤트 식별자는 변하지 않아야 함 |
| 5 | 출고 서비스가 이벤트를 받아 처리 상태를 기록 | 같은 이벤트를 다시 받아도 두 번째 출고가 생성되지 않아야 함 |
| 6 | 운영팀이 작업 상태나 실패 알림을 확인 | 큐는 요청 경로뿐 아니라 모니터링과 복구 업무도 바꿈 |
C4 동적 다이어그램으로 특정 사용 사례에서 실행 중에 일어나는 상호 작용을 순서대로 보여 줄 수 있습니다. 필요한 부분에만 사용하세요. 이 사례에서 중요한 것은 정상 호출을 모두 나열하는 것이 아니라 장애와 재시도의 경로입니다.
이 예시에 “정확히 한 번 처리”나 “주문 유실 없음”이라고 적지 마세요. 그런 주장을 하려면 발표 자료에 없는 구현 세부 사항과 테스트가 필요합니다. 대신 대기 이벤트의 복구 방법, 실패 작업의 보관 기간, 재처리 담당자 등 설계에서 답해야 할 질문을 보여 주세요.
같은 질문으로 대안 비교하기
한쪽에는 장점 문단을, 다른 쪽에는 단점 문단을 놓는 방식으로는 비교하기 어렵습니다. 동일한 기준을 적용하고 각 방식에서 감수해야 할 부담을 드러내세요.
| 기준 | 출고 서비스를 직접 호출 | 큐를 통한 출고 처리 |
|---|---|---|
| 고객에게 보내는 응답 | 주문 접수가 출고 서비스 호출의 동작에 영향을 받음 | 접수와 이후 처리를 분리할 수 있음 |
| 장애 복구 | 호출 경로 안에서 재시도를 처리 | 작업 상태, 재처리, 중복 대응이 필요 |
| 운영 업무 | 이 흐름에서 관리할 구성 요소가 적음 | 큐 상태, 실패 작업, 처리 지연을 관리할 담당자가 필요 |
| 이전 작업 | 새로운 메시지 경로가 필요하지 않음 | 시범 적용과 원상 복구 경로가 필요 |
표는 설계 시 고려할 사항을 설명하며, 측정된 성능을 뜻하지 않습니다. 실제 지연 시간이나 오류 데이터를 추가하려면 환경, 기간, 표본, 출처를 제시할 수 있어야 합니다. 그런 데이터가 없다면 개선 효과를 단정하기보다 범위를 제한한 시범 적용을 권하는 편이 정확합니다.
6장 슬라이드로 논의 구성하기
- 결정과 범위: 제안하는 시범 적용과 제외 항목.
- 전체 맥락: 주문 서비스와 직접 연결된 시스템.
- 현재 문제: 제안의 계기가 된 실제 장애, 지연 또는 운영 제약.
- 제안한 흐름: 6개 상호 작용과 장애가 발생할 수 있는 지점.
- 대안: 두 방식에 동일한 4개 비교 기준 적용.
- 시범 적용 결정: 담당자, 원상 복구 경로, 테스트, 진행 또는 중단을 판단할 검토 날짜.
이 예시라면 마지막 슬라이드에서 플랫폼팀에 검토 전까지 발행 프로세스 장애, 중복 전달, 출고 서비스 중단을 테스트하도록 요청할 수 있습니다. 각 테스트에는 예상 결과와 결과를 해석할 담당자가 필요합니다. 발표 자료 자체로 아키텍처가 확정되는 것처럼 보이지 않으면서도 회의에서 구체적인 다음 행동을 정할 수 있습니다. 테스트를 마친 뒤에는 릴리스 준비 상태 발표 자료에서 결과를 정확한 릴리스 후보 버전, 남은 차단 요인, 출시 여부를 결정할 권한이 있는 사람과 연결하세요.
실제 요청 흐름, 대안 표, 시범 적용 조건을 사용해 Presenti에서 6장짜리 초안을 만들어 보세요. 설정, 로그, 전체 테스트 결과는 부록이나 연결된 설계 기록에 두면 핵심 설명을 복잡하게 만들지 않으면서 검토자가 자세히 살펴볼 수 있습니다.
