아키텍처 설계서와 프로젝트 관리 산출물은 어떻게 구분할까?

SI 프로젝트에서는 문서가 수십 종 나오고, 그중 상당수가 같은 내용을 서로 다른 곳에 적는다. 아키텍처 설계서에 일정이 들어가고 사업수행계획서에 기술 구조가 들어가면, 한쪽만 고쳐지는 순간 두 문서가 서로 다른 말을 한다. 이 글은 두 문서 묶음을 가르는 기준, 둘 사이에 걸치는 경계 문서를 다루는 방법, 그리고 어떤 문장을 어디에 써야 하는지 판단하는 순서를 정리한 것이다.

한 문장으로 가르는 기준

아키텍처 설계서는 시스템이 어떻게 만들어지는가를 적고, 프로젝트 관리 산출물은 프로젝트가 어떻게 굴러가는가를 적는다. 앞쪽의 대상은 제품이고, 뒤쪽의 대상은 과정이다.

판단이 어려울 때는 수명을 보면 된다. 프로젝트가 끝나고 운영팀이 넘겨받은 뒤에도 필요한 내용이면 아키텍처 설계서에, 프로젝트 종료와 함께 의미가 끝나는 내용이면 관리 산출물에 쓴다.

아키텍처 설계서: 시스템이 어떻게 만들어지는가

아키텍처 설계서는 개발자가 매일 펴 보고, 운영자가 장애 때 찾아보는 문서다. 보통 다음으로 이루어진다.

• 아키텍처 정의서: 논리 구성, 물리·배포 구성, 데이터 흐름, 보안 구조, 품질 요구사항별 대응 방안
• 아키텍처 결정 기록(ADR): 결정마다 배경, 결정, 고려한 대안, 감수하는 단점
• 개발 표준 정의서: 패키지 구조, 이름 규칙, 예외·로그·트랜잭션 처리, 보안 코딩 규칙
• 인터페이스 정의서: 내부·외부 연계별 방식, 주기, 데이터 형식, 오류 처리

이 문서에 들어가면 안 되는 것은 날짜와 사람이다. "결제 연계는 3주차에 완료한다", "홍길동 책임이 담당한다" 같은 문장은 일정이 바뀔 때마다 설계서를 고치게 만든다. 설계서에는 "결제 연계는 메시지 큐를 거쳐 비동기로 호출한다"처럼 일정과 무관하게 참인 문장만 남긴다.

프로젝트 관리 산출물: 프로젝트가 어떻게 굴러가는가

관리 산출물은 발주처와 경영진이 프로젝트 상태를 판단하는 근거다.

• 사업수행계획서: 범위, 추진 전략, 조직과 역할, 일정 개요
• WBS와 상세 일정: 작업 분해, 담당, 선후 관계, 기간
• 위험·이슈 관리대장: 위험 내용, 발생 가능성과 영향, 대응 계획, 담당, 상태
• 변경 관리대장: 변경 요청, 영향 분석, 승인 결과
• 의사소통 산출물: 주간·월간 보고, 회의록
• 품질 보증 계획과 검수·완료 보고서

이 문서에 들어가면 안 되는 것은 설계의 세부다. 주간 보고에 시퀀스 다이어그램을 붙이거나 사업수행계획서에 테이블 정의를 적으면, 설계가 바뀔 때 관리 문서까지 다시 승인받아야 한다. 관리 문서에는 "인증 구조 결정 완료(ADR-004 참조)"처럼 상태와 링크만 쓴다.

경계에 걸친 문서 세 가지

두 영역에 모두 걸치는 문서가 있다. 이 문서들은 한쪽이 소유하고 다른 쪽은 참조한다는 원칙으로 다룬다.

요구사항 추적표

요구사항이 어느 설계 요소와 어느 테스트로 이어지는지를 적는 표다. 연결 관계(요구사항 → 설계 → 테스트)는 아키텍트와 품질 담당이 채우고, 이행 현황(완료율, 지연 항목)은 PM이 보고에 쓴다. 표는 하나만 두고 열의 소유자를 나눈다. 두 벌을 만들면 반드시 어긋난다.

위험 관리대장

대장 자체는 PM이 소유한다. 다만 기술 위험은 아키텍트가 찾아 내용과 대응안을 적는다. "외부 기관 API 응답이 10초까지 늦어진다"는 위험의 대응이 "비동기 큐로 분리"라면, 그 결정은 ADR에 쓰고 위험 대장에는 ADR 번호를 남긴다.

변경 요청

변경 절차(접수, 영향 분석, 승인)는 PM이 운영한다. 영향 분석 중 구조에 관한 부분은 아키텍트가 쓴다. 승인되면 PM은 일정과 범위를, 아키텍트는 설계서와 ADR을 각자 고친다.

이 문장은 어디에 쓸까: 판단 순서

새 내용을 적을 때 아래 순서로 물으면 대부분 한 곳으로 정해진다.

실제 문장으로 연습하면 이렇다.

같은 내용을 두 곳에 쓰면 생기는 일

가장 흔한 사고는 숫자가 갈라지는 것이다. 사업수행계획서에 "동시 사용자 1,000명"이 적혀 있고, 아키텍처 정의서는 그 뒤 합의된 "2,000명"으로 고쳐졌는데 계획서는 그대로인 경우다. 검수 때 발주처가 어느 쪽을 기준으로 삼을지 다투게 된다.

해법은 내용마다 정본을 한 곳에 두고, 다른 문서는 식별자로 가리키는 것이다.

• 품질 요구사항의 숫자는 품질 요구사항 정의서에만 둔다. 다른 문서는 "NFR-PERF-01 참조"로 쓴다.
• 설계 결정은 ADR에만 둔다. 보고서는 "ADR-007 승인"처럼 상태만 적는다.
• 일정은 WBS에만 둔다. 설계서에 날짜가 필요하면 "WBS 3.2 완료 후"처럼 쓴다.

아키텍처 정의서 목차 예시

경계를 목차에 미리 박아 두면 작성자마다 판단이 달라지는 일이 줄어든다.

# 아키텍처 정의서

1. 개요 — 목적, 범위, 용어 (일정·조직은 사업수행계획서 참조)
2. 아키텍처 핵심 요구사항 — ASR 목록 (수치는 품질 요구사항 정의서 ID로 참조)
3. 논리 아키텍처 — 레이어, 업무 모듈 경계, 호출 규칙
4. 물리·배포 아키텍처 — 서버·네트워크 구성, 환경별 차이
5. 데이터 아키텍처 — 주요 데이터 흐름, 저장소 역할
6. 보안 아키텍처 — 인증·권한, 암호화, 접근 통제
7. 품질 요구사항 대응 — 요구사항 ID별 대응 방안과 검증 방법
8. 주요 결정 — ADR 목록과 링크
9. 미결 사항 — 결정이 남은 항목 (진행 상태는 이슈 관리대장 참조)

넣지 않는 것: 일정, 담당자 이름, 공수, 진척률

자주 하는 실수

• 설계서에 일정을 적는다. 일정이 바뀔 때마다 설계서 개정과 재승인이 따라온다.
• 보고서에 설계 그림을 복사한다. 설계가 바뀌면 지난 보고서 그림이 틀린 정보로 남는다. 링크로 대신한다.
• 경계 문서를 두 벌 만든다. 아키텍트용 추적표와 PM용 추적표가 따로 있으면 한 달 안에 어긋난다.
• 기술 위험을 위험 대장에만 적고 설계에 반영하지 않는다. 대응이 구조 변경이면 ADR이 있어야 개발자가 안다.
• 프로젝트가 끝날 때 설계서도 같이 보관함에 넣는다. 설계서는 운영 이관 문서다. 마지막 판을 운영팀에 넘기고 갱신 책임자를 정한다.

점검표

• 아키텍처 설계서에 날짜, 담당자 이름, 진척률이 없다
• 관리 산출물에 설계 세부 대신 상태와 문서 링크가 있다
• 품질 요구사항 숫자의 정본이 한 문서에만 있다
• 요구사항 추적표는 한 벌이고 열마다 소유자가 정해져 있다
• 기술 위험의 대응이 구조 변경이면 ADR 번호가 위험 대장에 있다
• 변경 요청의 영향 분석에 구조 영향 항목이 있고 아키텍트가 썼다
• 승인된 변경이 설계서와 일정에 각각 반영됐다
• 설계서 목차에 "넣지 않는 것"이 적혀 있다
• 프로젝트 종료 때 설계서의 갱신 책임자가 운영 쪽에 정해졌다

두 문서 묶음을 가르는 기준은 결국 하나다. 시스템과 함께 살아남는 내용은 아키텍처 설계서에, 프로젝트와 함께 끝나는 내용은 관리 산출물에 쓰고, 둘 다에 걸치는 내용은 한쪽이 소유하고 다른 쪽은 가리키기만 한다.