소프트웨어 아키텍처 문서 SAD 작성과 활용
소프트웨어 아키텍처 문서(SAD)의 역할, 아키텍처 요구사항과 뷰, 설계전략, 작성·갱신 체계를 실무 관점에서 정리한다.
2026-08-14 · 최초 발행 2025-05-23
SAD는 설계 결정이 남아 있는 시스템 청사진이다
소프트웨어 아키텍처 문서(SAD)는 시스템 구조와 아키텍처 설계 결정사항을 기록하는 산출물이다. 개발팀에는 구현 방향을 제시하고, 이해관계자에게는 각자의 관점에서 시스템을 설명하는 소통 수단이 된다.
문서에 남겨야 할 대상은 구조 자체만이 아니다. 설계 과정에서 어떤 결정을 내렸는지와 그 이유를 기록해야 이후 변경과 확장에도 참조할 수 있다. SAD는 품질 요구사항 충족 여부를 검증하는 기준이 되며, 시스템 유지보수와 진화를 뒷받침한다.
문서의 출발점은 범위와 제약을 명확히 하는 일이다
개요에는 SAD의 작성 목적과 필요성, 문서가 다루는 범위, 적용 대상 시스템의 경계를 적는다. 발주자·사용자·개발자·운영자·테스터처럼 시스템과 관계된 이해관계자를 식별하고 각 역할도 정의한다.
아키텍처 배경에서는 기술 환경과 비즈니스 환경을 함께 다룬다. 기술 환경에는 운영체제, 미들웨어, 서버 환경이 포함되고, 비즈니스 환경에는 조직 구조·업무 프로세스·기존 시스템과의 관계가 포함된다.
제약사항도 설계의 전제다. 특정 기술이나 플랫폼을 사용해야 하는 기술적 제약, 예산·일정·법적 또는 규제적 요구사항 같은 비기술적 제약을 분리해 기록한다.
품질 요구사항이 아키텍처 선택을 이끈다
SAD에서는 ISO/IEC 25010 같은 품질 모델 가운데 어떤 속성을 중점적으로 다룰지 정한다. 성능, 보안, 가용성, 확장성, 사용성, 유지보수성 등의 품질 속성에는 구체적 목표치와 측정 방법을 연결한다.
이 요구사항이 설계 선택에 미치는 영향도 분석 대상이다. 아키텍처는 기능을 배치하는 방식만으로 결정되지 않으며, 품질 속성을 만족시키기 위한 판단과 함께 설명되어야 한다.
참조 관점과 설계전략을 연결한다
참조 아키텍처에는 시스템을 바라보는 관점과 선택한 아키텍처 스타일을 담는다. 관점으로는 논리·프로세스·개발·물리·유스케이스 뷰를 포함하는 4+1 뷰, Kruchten의 모델, Zachman 프레임워크 등을 사용할 수 있다.
아키텍처 스타일은 레이어드 아키텍처, 마이크로서비스, 이벤트 기반 등의 후보 가운데 선택하며, 선택 이유도 남긴다. 설계전략에서는 주요 비즈니스 기능을 어떤 컴포넌트로 나눌지, 도메인 모델과 컴포넌트를 어떻게 매핑할지 다룬다.
공통 기능의 재사용 전략과 구현 방식도 이 영역에 속한다. 로깅, 인증·인가, 오류 처리, 트랜잭션 관리처럼 여러 영역을 가로지르는 관심사는 시스템 공통기능으로서 처리 방식을 분명히 한다.
시스템 뷰로 서로 다른 관심사를 설명한다
전체 아키텍처의 Overview와 뷰 사이의 관계 및 매핑을 제시한 뒤, 이해관계자별로 필요한 뷰를 제공한다.
- 사용자 뷰(User View)는 사용자 관점의 시스템 기능을 보여 준다.
- 논리 뷰(Logical View)는 주요 추상화 요소와 관계를 다룬다.
- 프로세스 뷰(Process View)는 시스템의 동적 측면과 프로세스 간 통신을 설명한다.
- 구현 뷰(Implementation View)는 소프트웨어 모듈, 라이브러리, 컴포넌트를 다룬다.
- 배포 뷰(Deployment View)는 물리적 인프라에 소프트웨어를 배치하는 방식을 담는다.
용어사전에는 문서에서 사용한 주요 용어와 정의를 수록하고, 참고문서에는 관련 문서·표준·참조 자료를 연결한다.
초안에서 운영 문서로 이어지는 갱신 흐름
작성은 요구사항 분석과 아키텍처 드라이버 식별에서 시작한다. 이후 주요 설계 결정을 수립하고, 핵심 뷰와 결정사항을 담은 SAD 초안을 만든다. 이해관계자의 검토와 피드백을 반영해 문서를 정제한 뒤에도, 시스템 변화에 맞춰 갱신을 계속한다.
이 흐름이 유지되려면 아키텍처 변경 통제 절차, 문서 버전 관리와 이력 추적 체계가 필요하다. 자동화된 문서 생성 도구의 활용도 고려할 수 있다.
협업 규모가 커질수록 문서의 역할이 선명해진다
레거시 시스템을 마이크로서비스 아키텍처로 전환하는 금융권 핵심 업무시스템에서는 SAD가 마이크로서비스 경계, 서비스 간 통신 전략, 데이터 일관성 유지 방안을 정의하는 기준이 된다. 명확한 SAD를 바탕으로 10개 팀이 병렬 개발을 수행하면서도 통합 이슈를 최소화할 수 있다.
여러 기관의 시스템을 연계하는 대규모 공공 시스템에서는 인터페이스 정의, 보안 아키텍처, 확장성 있는 인프라 설계가 핵심이다. 이때 SAD는 복잡한 이해관계자 사이의 소통 도구가 되고 변경 관리에도 활용된다.
독자에 맞추되 구현 세부사항과 혼동하지 않는다
경영진에게는 비즈니스 가치·비용·일정 중심의 정보가 필요하고, 개발자에게는 기술적 상세 정보와 구현 가이드라인이 필요하다. 운영자는 배포, 모니터링, 장애 대응 방안을 우선적으로 확인한다.
문서의 추상화 수준은 이 요구를 함께 고려해야 한다. 지나치게 상세하면 유지보수가 어려워지고, 너무 추상적이면 구현에 도움이 되지 않는다. 핵심 결정사항은 SAD에 집중하고 세부 구현은 별도 문서로 관리한다.
표현 방식으로는 클래스·시퀀스·컴포넌트·배포 UML 다이어그램, C4 모델이나 ArchiMate 같은 아키텍처 뷰, 복잡한 개념을 직관적으로 드러내는 인포그래픽을 활용할 수 있다.
SAD는 요구사항과 운영 사이의 설계 기준이다
요구사항 명세서(SRS)는 기능 및 비기능 요구사항을 제공하는 SAD의 입력 문서다. SAD보다 낮은 수준의 설계 상세는 상세 설계 문서(DDD)에 기록한다.
테스트 계획서는 SAD를 활용해 아키텍처 검증 전략을 수립하며, 운영 매뉴얼은 SAD의 배포 뷰를 기반으로 운영 절차를 마련한다. 따라서 SAD는 개별 산출물로 끝나는 문서가 아니라 개발과 운영 문서를 연결하는 기준점이다.
잘 관리된 SAD는 개발 과정의 일관성과 품질 보증의 근거를 제공한다. 시스템 개발 초기부터 이를 관리하면 유지보수 비용 절감과 비즈니스 민첩성 향상으로 이어질 수 있다.