아키텍처 및 시스템 다이어그램 상세 가이드
목차
C4 모델 다이어그램
개념
정의
C4 모델은 소프트웨어 아키텍처를 4가지 관점(Context, Container, Component, Code)에서 표현하는 모델입니다. 각 레벨은 다른 관심사를 가진 이해관계자에게 적합한 추상화 수준을 제공합니다. Simon Brown이 개발한 현대적인 소프트웨어 아키텍처 문서화 방법론입니다.
핵심 특징
- 계층적 추상화: 4가지 레벨로 점진적 상세화
- 이해관계자 중심: 각 레벨이 특정 이해관계자에게 최적화
- 간단하고 실용적: 복잡한 UML보다 간단하고 실용적
- 도구 독립적: 특정 도구에 종속되지 않음
- 현대적: 마이크로서비스, 클라우드 아키텍처에 적합
4가지 레벨
Level 1: 시스템 컨텍스트 다이어그램 (System Context Diagram)
- 목적: 시스템과 외부 액터의 관계 표현
- 대상: 비기술적 이해관계자
- 포함 내용: 시스템, 사용자, 외부 시스템, 관계
Level 2: 컨테이너 다이어그램 (Container Diagram)
- 목적: 애플리케이션의 컨테이너 구조 표현
- 대상: 기술적 이해관계자
- 포함 내용: 웹 앱, API, 데이터베이스, 메시지 큐 등
Level 3: 컴포넌트 다이어그램 (Component Diagram)
- 목적: 컨테이너 내부의 컴포넌트 구조 표현
- 대상: 개발자
- 포함 내용: 컴포넌트, 인터페이스, 의존성
Level 4: 코드 다이어그램 (Code Diagram)
- 목적: 클래스나 함수 레벨의 상세 구조 표현
- 대상: 개발자 (상세 설계)
- 포함 내용: 클래스, 함수, 관계 (UML 클래스 다이어그램과 유사)
사용하는 곳
1. 아키텍처 문서화
- 소프트웨어 아키텍처를 계층적으로 문서화
- 시스템 구조를 다양한 관점에서 표현
- 아키텍처 의사결정 기록
2. 이해관계자 소통
- 비기술적 이해관계자와 기술적 이해관계자 모두와 소통
- 각 레벨이 적절한 추상화 수준 제공
- 프레젠테이션 자료로 활용
3. 아키텍처 설계
- 시스템 아키텍처 설계 및 검토
- 아키텍처 패턴 적용
- 기술 스택 결정
4. 온보딩
- 신규 개발자에게 시스템 구조 설명
- 레벨별로 점진적 학습 가능
- 시스템 이해도 향상
5. 아키텍처 리뷰
- 아키텍처 결정 검토
- 아키텍처 개선 기회 발견
- 기술 부채 관리
어디에 사용하면 유리한지
1. 대규모 시스템
- 상황: 복잡한 시스템의 구조를 단계적으로 이해
- 예시:
- 엔터프라이즈 애플리케이션
- 마이크로서비스 아키텍처
- 분산 시스템
- 유리한 점:
- 계층적 추상화로 복잡도 관리
- 전체 구조와 상세 구조 모두 파악 가능
- 이해관계자별 적절한 레벨 제공
2. 다양한 이해관계자
- 상황: 기술자와 비기술자 모두와 소통
- 예시:
- 경영진, 프로젝트 매니저, 개발자
- 클라이언트, 사용자
- 유리한 점:
- 각 이해관계자에게 적합한 레벨 제공
- 공통 언어 제공
- 소통 효율성 향상
3. 마이크로서비스
- 상황: 여러 서비스로 구성된 시스템
- 예시:
- 마이크로서비스 아키텍처
- 분산 시스템
- 유리한 점:
- 서비스 간 관계 명확화
- 서비스 경계 정의
- 통신 패턴 문서화
4. 레거시 시스템 문서화
- 상황: 기존 시스템의 구조 파악
- 예시:
- 레거시 시스템 분석
- 시스템 구조 문서화
- 유리한 점:
- 역공학으로 구조 파악
- 점진적 문서화 가능
- 온보딩 자료
5. 아키텍처 의사결정
- 상황: 아키텍처 결정을 문서화
- 예시:
- 아키텍처 결정 기록(ADR)
- 기술 스택 선택
- 유리한 점:
- 의사결정 배경 문서화
- 대안 비교
- 향후 참고 자료
6. 프로젝트 초기 단계
- 상황: 시스템 구조를 설계할 때
- 예시:
- 신규 프로젝트
- 시스템 재설계
- 유리한 점:
- 초기 설계 가이드
- 구조 명확화
- 팀 합의 도출
7. 리팩토링 계획
- 상황: 구조 개선 계획 수립
- 예시:
- 모놀리식을 마이크로서비스로 분해
- 아키텍처 개선
- 유리한 점:
- 현재 구조와 목표 구조 비교
- 마이그레이션 계획 수립
- 영향 분석
어떤 경우에는 과한 경우인지
1. 간단한 프로젝트
- 상황: 단일 애플리케이션으로 구성된 작은 프로젝트
- 예시:
- 개인 프로젝트
- 토이 프로젝트
- 간단한 웹 애플리케이션
- 과한 이유:
- 구조가 단순하여 문서화 불필요
- 코드로 충분히 이해 가능
- 문서화 비용 대비 효과 낮음
2. 프로토타입
- 상황: 빠르게 변경되는 초기 프로토타입
- 예시:
- MVP 개발
- 개념 검증
- 과한 이유:
- 구조가 자주 변경됨
- 문서 업데이트 비용 높음
- 개발 속도 저하 가능
3. 일회성 스크립트
- 상황: 임시 스크립트나 유틸리티
- 예시:
- 데이터 변환 스크립트
- 일회성 작업
- 과한 이유:
- 문서화 ROI 낮음
- 구조가 단순함
4. 단순한 정적 웹사이트
- 상황: 복잡한 구조가 없는 경우
- 예시:
- 정적 HTML 사이트
- 간단한 랜딩 페이지
- 과한 이유:
- 구조가 단순하여 문서화 불필요
5. 개인 프로젝트
- 상황: 개인만 사용하는 작은 프로젝트
- 예시:
- 개인 학습 프로젝트
- 포트폴리오 프로젝트
- 과한 이유:
- 문서화 필요성 낮음
- 직접 관리 가능
개발 문서에 포함될 경우
1. 시스템 아키텍처 문서 (System Architecture Document)
포함 내용
-
시스템 컨텍스트 다이어그램
- 시스템과 외부 액터의 관계
- 시스템 경계 정의
- 외부 의존성
-
컨테이너 다이어그램
- 애플리케이션 구조
- 기술 스택
- 컨테이너 간 통신
-
컴포넌트 다이어그램 (필요시)
- 주요 컴포넌트 구조
- 컴포넌트 간 의존성
포함 이유
- 전체 시스템 구조 이해
- 아키텍처 문서화
- 이해관계자 소통
- 기술 스택 문서화
작성 시점
- 아키텍처 설계 단계
- 시스템 설계 단계
- 아키텍처 리뷰 전
포함 위치
- 아키텍처 문서의 “시스템 개요” 섹션
- “아키텍처 설계” 섹션
- “시스템 구조” 섹션
2. 설계 문서 (Design Document)
포함 내용
-
컨테이너 다이어그램
- 애플리케이션 구조
- 기술 스택
- 배포 구조
-
컴포넌트 다이어그램
- 컴포넌트 구조
- 인터페이스 정의
- 의존성
포함 이유
- 시스템 설계 문서화
- 개발 가이드 제공
- 아키텍처 의사결정 기록
작성 시점
- 상세 설계 단계
- 아키텍처 설계 단계
포함 위치
- 설계 문서의 “시스템 구조” 섹션
- “아키텍처 설계” 섹션
3. 온보딩 문서 (Onboarding Document)
포함 내용
-
시스템 컨텍스트 다이어그램
- 시스템 개요
- 시스템 경계
-
컨테이너 다이어그램
- 애플리케이션 구조
- 기술 스택
-
컴포넌트 다이어그램 (상세 학습용)
- 컴포넌트 구조
- 개발 가이드
포함 이유
- 신규 개발자 교육
- 시스템 구조 이해
- 점진적 학습 지원
작성 시점
- 온보딩 자료 작성 단계
- 신규 개발자 입사 시
포함 위치
- 온보딩 문서의 “시스템 개요” 섹션
- “아키텍처 개요” 섹션
4. 아키텍처 결정 기록 (ADR - Architecture Decision Record)
포함 내용
-
컨테이너 다이어그램 (해당 결정과 관련된 부분)
- 아키텍처 결정의 영향 범위
- 기술 스택 선택 근거
-
컴포넌트 다이어그램 (필요시)
- 컴포넌트 구조 변경
포함 이유
- 아키텍처 결정 배경 문서화
- 영향 범위 시각화
- 향후 참고 자료
작성 시점
- 아키텍처 결정 시
- 기술 스택 선택 시
포함 위치
- ADR의 “아키텍처 영향” 섹션
- “기술 스택” 섹션
5. 기술 문서 (Technical Documentation)
포함 내용
-
컨테이너 다이어그램
- 기술 스택
- 애플리케이션 구조
-
컴포넌트 다이어그램
- 컴포넌트 구조
- 인터페이스
포함 이유
- 기술 스택 문서화
- 구조 설명
- 개발 가이드
작성 시점
- 기술 문서 작성 단계
- 기술 스택 결정 후
포함 위치
- 기술 문서의 “시스템 구조” 섹션
- “기술 스택” 섹션
6. 프로젝트 제안서 (Project Proposal)
포함 내용
-
시스템 컨텍스트 다이어그램
- 제안 시스템과 외부 시스템의 관계
- 시스템 범위
-
컨테이너 다이어그램 (고수준)
- 제안 아키텍처
- 기술 스택 제안
포함 이유
- 제안 시스템 구조 설명
- 이해관계자 소통
- 기술적 타당성 제시
작성 시점
- 프로젝트 제안 단계
- RFP 응답 단계
포함 위치
- 프로젝트 제안서의 “시스템 개요” 섹션
- “기술 제안” 섹션
네트워크 다이어그램
개념
정의
네트워크 다이어그램은 네트워크의 토폴로지, 장비, 연결, 그리고 데이터 흐름을 시각적으로 표현하는 다이어그램입니다. 물리적 네트워크 구조와 논리적 네트워크 구조를 모두 표현할 수 있습니다.
핵심 특징
- 토폴로지 표현: 네트워크 구조를 시각화
- 장비 표현: 라우터, 스위치, 방화벽 등 네트워크 장비 표현
- 연결 표현: 네트워크 링크와 연결 표현
- IP 주소 표현: 서브넷, IP 주소 정보 포함
- 보안 구조: 방화벽, DMZ 등 보안 구조 표현
주요 구성 요소
네트워크 장비
- 라우터: 원형, 네트워크 간 라우팅
- 스위치: 사각형, 네트워크 세그먼트 내 스위칭
- 방화벽: 방패 모양, 보안 필터링
- 로드 밸런서: 다이아몬드, 트래픽 분산
- 게이트웨이: 게이트웨이 아이콘, 네트워크 간 연결
서버 및 클라이언트
- 서버: 박스, 다양한 서버 표현
- 클라이언트: PC 아이콘, 사용자 디바이스
- 클라우드: 클라우드 모양, 클라우드 서비스
네트워크 구조
- 네트워크 링크: 연결선, 유선/무선 표현
- 네트워크 세그먼트: 클라우드 모양, 서브넷 표현
- IP 주소/서브넷: 라벨, 네트워크 정보
사용하는 곳
1. 네트워크 설계
- 새로운 네트워크 인프라 설계
- 네트워크 아키텍처 설계
- 서브넷 설계
- 라우팅 설계
2. 네트워크 문서화
- 기존 네트워크 구조 문서화
- 네트워크 구성 문서화
- IP 주소 할당 문서화
- 네트워크 토폴로지 문서화
3. 트러블슈팅
- 네트워크 문제 진단
- 연결 문제 해결
- 성능 문제 분석
- 보안 이슈 분석
4. 보안 설계
- 네트워크 보안 구조 설계
- 방화벽 규칙 설계
- DMZ 설계
- 보안 구역 설계
5. 용량 계획
- 네트워크 용량 및 대역폭 계획
- 트래픽 분석
- 대역폭 요구사항 정의
- 네트워크 확장 계획
6. 재해 복구 계획
- 네트워크 백업 및 복구 구조
- 장애 대응 계획
- 네트워크 이중화 구조
7. 네트워크 마이그레이션
- 네트워크 구조 변경 계획
- 클라우드 마이그레이션
- 네트워크 업그레이드 계획
어디에 사용하면 유리한지
1. 복잡한 네트워크
- 상황: 여러 서브넷과 장비가 있는 경우
- 예시:
- 엔터프라이즈 네트워크
- 데이터센터 네트워크
- 다중 사이트 네트워크
- 유리한 점:
- 전체 네트워크 구조 파악
- 서브넷 관계 명확화
- 장비 배치 계획
2. 분산 시스템
- 상황: 여러 데이터센터나 클라우드 리전
- 예시:
- 멀티 리전 아키텍처
- 하이브리드 클라우드
- 글로벌 네트워크
- 유리한 점:
- 분산 구조 시각화
- 통신 경로 명확화
- 지연 시간 분석
3. 하이브리드 클라우드
- 상황: 온프레미스와 클라우드 혼합
- 예시:
- 온프레미스-클라우드 연결
- 멀티 클라우드
- VPN 연결
- 유리한 점:
- 하이브리드 구조 시각화
- 연결 경로 명확화
- 보안 경계 정의
4. 보안 요구사항이 높은 경우
- 상황: DMZ, 방화벽 규칙 등 보안 구조 중요
- 예시:
- 금융 시스템
- 의료 시스템
- 정부 시스템
- 유리한 점:
- 보안 구역 시각화
- 방화벽 규칙 설계
- 보안 경계 명확화
5. 네트워크 통합
- 상황: 여러 네트워크를 통합하는 경우
- 예시:
- 기업 인수합병
- 네트워크 통합 프로젝트
- 유리한 점:
- 통합 계획 수립
- 영향 분석
- 마이그레이션 계획
6. 네트워크 최적화
- 상황: 네트워크 성능 개선 계획
- 예시:
- 대역폭 최적화
- 라우팅 최적화
- 장비 교체 계획
- 유리한 점:
- 병목 지점 식별
- 최적화 포인트 발견
- 개선 계획 수립
7. 규정 준수
- 상황: 네트워크 구조를 문서화해야 하는 경우
- 예시:
- 보안 감사
- 규제 준수
- 인증 요구사항
- 유리한 점:
- 네트워크 구조 문서화
- 감사 대응
- 규정 준수 증명
어떤 경우에는 과한 경우인지
1. 단순한 로컬 네트워크
- 상황: 홈 네트워크나 작은 오피스
- 예시:
- 홈 네트워크
- 소규모 오피스 (5-10명)
- 과한 이유:
- 구조가 단순하여 문서화 불필요
- 직접 확인 가능
2. 단일 서버
- 상황: 하나의 서버만 있는 경우
- 예시:
- 단일 서버 애플리케이션
- 개발 환경
- 과한 이유:
- 네트워크 구조가 단순함
- 문서화 불필요
3. 클라우드 관리형 서비스
- 상황: 네트워크가 완전히 추상화된 경우
- 예시:
- 완전 관리형 클라우드 서비스
- 서버리스 아키텍처
- 과한 이유:
- 네트워크 구조가 숨겨져 있음
- 관리할 네트워크가 없음
4. 개발 환경
- 상황: 개발자 로컬 환경
- 예시:
- 로컬 개발 환경
- Docker Compose 환경
- 과한 이유:
- 임시 환경
- 문서화 불필요
5. 프로토타입
- 상황: 임시 네트워크 구성
- 예시:
- 개념 검증
- 프로토타입 환경
- 과한 이유:
- 빠르게 변경됨
- 문서화 비용 대비 효과 낮음
개발 문서에 포함될 경우
1. 인프라 설계서 (Infrastructure Design Document)
포함 내용
-
네트워크 다이어그램
- 네트워크 토폴로지
- 네트워크 장비 배치
- 서브넷 구조
- IP 주소 할당
-
네트워크 상세
- 라우팅 테이블
- 방화벽 규칙
- 네트워크 보안 구조
포함 이유
- 네트워크 인프라 설계
- 네트워크 구조 문서화
- 보안 설계
- 운영 가이드
작성 시점
- 인프라 설계 단계
- 네트워크 설계 단계
포함 위치
- 인프라 설계서의 “네트워크 설계” 섹션
- “네트워크 구조” 섹션
2. 네트워크 문서 (Network Documentation)
포함 내용
-
기존 네트워크 다이어그램
- 현재 네트워크 구조
- 네트워크 장비 목록
- IP 주소 할당
- 서브넷 구조
-
네트워크 구성 정보
- 장비 설정
- 라우팅 정보
- 보안 설정
포함 이유
- 네트워크 구조 문서화
- 트러블슈팅 가이드
- 인수인계 자료
작성 시점
- 네트워크 문서화 단계
- 네트워크 인수인계 단계
포함 위치
- 네트워크 문서의 “네트워크 구조” 섹션
- “네트워크 토폴로지” 섹션
3. 보안 설계서 (Security Design Document)
포함 내용
-
네트워크 보안 다이어그램
- 방화벽 배치
- DMZ 구조
- 보안 구역
- 네트워크 세그먼트
-
보안 구조
- 방화벽 규칙
- 네트워크 보안 정책
- 접근 제어 구조
포함 이유
- 네트워크 보안 구조 설계
- 보안 경계 정의
- 보안 정책 문서화
작성 시점
- 보안 설계 단계
- 보안 감사 준비 단계
포함 위치
- 보안 설계서의 “네트워크 보안” 섹션
- “보안 구조” 섹션
4. 운영 매뉴얼 (Operations Manual)
포함 내용
-
네트워크 다이어그램
- 운영 네트워크 구조
- 네트워크 장비 위치
- 연결 정보
-
트러블슈팅 가이드
- 네트워크 문제 해결 절차
- 장비 점검 절차
포함 이유
- 운영 환경 이해
- 트러블슈팅 가이드
- 인수인계 자료
작성 시점
- 운영 매뉴얼 작성 단계
- 배포 전 단계
포함 위치
- 운영 매뉴얼의 “네트워크 구조” 섹션
- “트러블슈팅 가이드” 섹션
5. 재해 복구 계획서 (Disaster Recovery Plan)
포함 내용
-
네트워크 복구 다이어그램
- 백업 네트워크 구조
- 복구 네트워크 구성
- 네트워크 이중화 구조
-
복구 절차
- 네트워크 복구 절차
- 장비 복구 절차
포함 이유
- 재해 복구 계획
- 네트워크 복구 가이드
- 비즈니스 연속성 보장
작성 시점
- 재해 복구 계획 수립 단계
- BCP 작성 단계
포함 위치
- 재해 복구 계획서의 “네트워크 복구” 섹션
- “인프라 복구” 섹션
6. 변경 관리 문서 (Change Management Document)
포함 내용
-
현재/목표 네트워크 다이어그램
- 현재 네트워크 구조
- 목표 네트워크 구조
- 변경 사항
-
변경 계획
- 네트워크 변경 절차
- 영향 분석
- 롤백 계획
포함 이유
- 네트워크 변경 계획
- 영향 분석
- 변경 가이드
작성 시점
- 네트워크 변경 계획 단계
- 변경 요청 승인 전
포함 위치
- 변경 관리 문서의 “변경 내용” 섹션
- “영향 분석” 섹션
인프라스트럭처 다이어그램
개념
정의
인프라스트럭처 다이어그램은 IT 인프라의 물리적 및 논리적 구조를 표현하는 다이어그램입니다. 서버, 스토리지, 네트워크, 보안 장비 등 전체 인프라 구조를 시각화합니다.
핵심 특징
- 전체 인프라 표현: 서버, 스토리지, 네트워크, 보안 등 전체 인프라
- 물리적/논리적 구조: 물리적 배치와 논리적 구조 모두 표현
- 의존성 표현: 인프라 구성 요소 간 의존성 표현
- 확장성 고려: 확장 가능한 구조 표현
주요 구성 요소
서버
- 물리적 서버: 실제 하드웨어 서버
- 가상 서버: VM, 컨테이너
- 서버 역할: 웹 서버, 앱 서버, DB 서버 등
스토리지
- SAN: Storage Area Network
- NAS: Network Attached Storage
- 클라우드 스토리지: S3, Azure Blob 등
네트워크 장비
- 라우터: 네트워크 라우팅
- 스위치: 네트워크 스위칭
- 방화벽: 보안 필터링
- 로드 밸런서: 트래픽 분산
데이터베이스
- DB 서버: 데이터베이스 서버
- DB 클러스터: 고가용성 구성
- 백업 시스템: 백업 스토리지
모니터링 시스템
- 모니터링 도구: 시스템 모니터링
- 로깅 시스템: 로그 수집 및 분석
사용하는 곳
1. 인프라 설계
- 새로운 인프라 설계
- 인프라 아키텍처 설계
- 하드웨어 요구사항 정의
- 용량 계획
2. 인프라 문서화
- 기존 인프라 구조 문서화
- 인프라 구성 문서화
- 하드웨어 인벤토리
3. 용량 계획
- 리소스 용량 계획
- 하드웨어 요구사항 정의
- 확장 계획
4. 하드웨어 요구사항
- 필요한 하드웨어 스펙 정의
- 하드웨어 구매 계획
- 하드웨어 배치 계획
5. 재해 복구 계획
- 백업 및 복구 인프라
- 장애 대응 인프라
- 비즈니스 연속성 인프라
6. 보안 설계
- 보안 인프라 구조
- 보안 구역 설계
- 보안 장비 배치
7. 클라우드 마이그레이션
- 클라우드 이전 계획
- 하이브리드 클라우드 설계
- 클라우드 리소스 계획
어디에 사용하면 유리한지
1. 대규모 인프라
- 상황: 여러 서버와 장비가 있는 경우
- 예시:
- 엔터프라이즈 인프라
- 데이터센터 인프라
- 멀티 사이트 인프라
- 유리한 점:
- 전체 인프라 구조 파악
- 리소스 관리
- 용량 계획
2. 하이브리드 인프라
- 상황: 온프레미스와 클라우드 혼합
- 예시:
- 하이브리드 클라우드
- 멀티 클라우드
- 유리한 점:
- 하이브리드 구조 시각화
- 리소스 배치 계획
- 비용 최적화
3. 고가용성 시스템
- 상황: 장애 대비 인프라
- 예시:
- 고가용성 구성
- 이중화 구조
- 장애 복구 시스템
- 유리한 점:
- 고가용성 구조 설계
- 장애 대응 계획
- 비즈니스 연속성 보장
4. 규정 준수
- 상황: 인프라 구조를 문서화해야 하는 경우
- 예시:
- 보안 감사
- 규제 준수
- 인증 요구사항
- 유리한 점:
- 인프라 구조 문서화
- 감사 대응
- 규정 준수 증명
5. 인프라 최적화
- 상황: 리소스 최적화 계획
- 예시:
- 비용 최적화
- 성능 최적화
- 리소스 통합
- 유리한 점:
- 최적화 포인트 식별
- 비용 절감 계획
- 효율성 향상
6. 보안 감사
- 상황: 보안 구조 검토
- 예시:
- 보안 감사
- 보안 평가
- 유리한 점:
- 보안 구조 시각화
- 취약점 식별
- 보안 개선 계획
7. 비용 계획
- 상황: 인프라 비용 계획
- 예시:
- 예산 계획
- 비용 분석
- 유리한 점:
- 인프라 비용 시각화
- 예산 계획
- 비용 최적화
어떤 경우에는 과한 경우인지
1. 단순한 클라우드 서비스
- 상황: 완전 관리형 서비스만 사용
- 예시:
- 완전 관리형 클라우드 서비스
- 서버리스 아키텍처
- 과한 이유:
- 인프라가 완전히 추상화됨
- 관리할 인프라가 없음
2. 개발 환경
- 상황: 개발자 로컬 환경
- 예시:
- 로컬 개발 환경
- Docker Compose 환경
- 과한 이유:
- 임시 환경
- 문서화 불필요
3. 소규모 프로젝트
- 상황: 서버가 1~2개인 경우
- 예시:
- 소규모 웹 애플리케이션
- 개인 프로젝트
- 과한 이유:
- 구조가 단순하여 문서화 불필요
4. 프로토타입
- 상황: 임시 인프라
- 예시:
- 개념 검증
- 프로토타입 환경
- 과한 이유:
- 빠르게 변경됨
- 문서화 비용 대비 효과 낮음
5. 서버리스 아키텍처
- 상황: 인프라가 완전히 추상화된 경우
- 예시:
- AWS Lambda
- Azure Functions
- Google Cloud Functions
- 과한 이유:
- 관리할 인프라가 없음
- 서버 개념이 없음
개발 문서에 포함될 경우
1. 인프라 설계서 (Infrastructure Design Document)
포함 내용
-
인프라스트럭처 다이어그램
- 전체 인프라 구조
- 서버 배치
- 스토리지 구조
- 네트워크 구조
-
인프라 상세
- 하드웨어 스펙
- 리소스 할당
- 용량 계획
포함 이유
- 인프라 설계 문서화
- 하드웨어 요구사항 정의
- 용량 계획
- 운영 가이드
작성 시점
- 인프라 설계 단계
- 하드웨어 계획 단계
포함 위치
- 인프라 설계서의 “인프라 구조” 섹션
- “하드웨어 요구사항” 섹션
2. 하드웨어 요구사항 문서 (Hardware Requirements Document)
포함 내용
-
인프라스트럭처 다이어그램
- 필요한 하드웨어 구조
- 서버 배치
- 스토리지 구조
-
하드웨어 스펙
- 서버 스펙
- 스토리지 스펙
- 네트워크 장비 스펙
포함 이유
- 하드웨어 요구사항 정의
- 하드웨어 구매 계획
- 예산 계획
작성 시점
- 하드웨어 요구사항 정의 단계
- 하드웨어 구매 계획 단계
포함 위치
- 하드웨어 요구사항 문서의 “인프라 구조” 섹션
- “하드웨어 스펙” 섹션
3. 운영 매뉴얼 (Operations Manual)
포함 내용
-
인프라스트럭처 다이어그램
- 운영 인프라 구조
- 서버 배치
- 스토리지 구조
-
운영 가이드
- 서버 관리
- 스토리지 관리
- 모니터링
포함 이유
- 운영 환경 이해
- 인프라 관리 가이드
- 인수인계 자료
작성 시점
- 운영 매뉴얼 작성 단계
- 배포 전 단계
포함 위치
- 운영 매뉴얼의 “인프라 구조” 섹션
- “인프라 관리” 섹션
4. 재해 복구 계획서 (Disaster Recovery Plan)
포함 내용
-
인프라스트럭처 다이어그램
- 백업 인프라 구조
- 복구 인프라 구성
- 인프라 이중화 구조
-
복구 절차
- 인프라 복구 절차
- 서버 복구 절차
- 스토리지 복구 절차
포함 이유
- 재해 복구 계획
- 인프라 복구 가이드
- 비즈니스 연속성 보장
작성 시점
- 재해 복구 계획 수립 단계
- BCP 작성 단계
포함 위치
- 재해 복구 계획서의 “인프라 복구” 섹션
- “복구 절차” 섹션
5. 보안 설계서 (Security Design Document)
포함 내용
-
인프라스트럭처 다이어그램
- 보안 인프라 구조
- 보안 구역
- 보안 장비 배치
-
보안 구조
- 보안 정책
- 접근 제어 구조
포함 이유
- 보안 인프라 설계
- 보안 구조 문서화
- 보안 감사 대응
작성 시점
- 보안 설계 단계
- 보안 감사 준비 단계
포함 위치
- 보안 설계서의 “보안 인프라” 섹션
- “보안 구조” 섹션
6. 비용 계획서 (Cost Planning Document)
포함 내용
-
인프라스트럭처 다이어그램
- 인프라 구조
- 리소스 배치
-
비용 분석
- 하드웨어 비용
- 운영 비용
- 확장 비용
포함 이유
- 인프라 비용 시각화
- 예산 계획
- 비용 최적화
작성 시점
- 비용 계획 단계
- 예산 계획 단계
포함 위치
- 비용 계획서의 “인프라 구조” 섹션
- “비용 분석” 섹션
데이터 플로우 다이어그램
개념
정의
데이터 플로우 다이어그램은 시스템 내에서 데이터가 어떻게 흐르고 변환되는지를 표현하는 다이어그램입니다. 데이터의 소스, 처리 과정, 저장소, 목적지를 시각화합니다.
핵심 특징
- 데이터 중심: 데이터 흐름과 변환에 초점
- 프로세스 표현: 데이터 처리 프로세스 표현
- 저장소 표현: 데이터 저장소 표현
- 외부 엔티티: 시스템 외부의 데이터 소스/목적지 표현
주요 구성 요소
프로세스
- 정의: 데이터를 처리하는 기능
- 표기: 원형
- 예시: 데이터 검증, 데이터 변환, 데이터 집계
데이터 저장소
- 정의: 데이터를 저장하는 곳
- 표기: 열린 사각형
- 예시: 데이터베이스, 파일, 캐시
외부 엔티티
- 정의: 시스템 외부의 데이터 소스/목적지
- 표기: 사각형
- 예시: 사용자, 외부 시스템, 파일 시스템
데이터 흐름
- 정의: 데이터의 이동 경로
- 표기: 화살표
- 예시: 데이터 전송, 데이터 변환
사용하는 곳
1. 시스템 분석
- 데이터 흐름 분석
- 데이터 처리 프로세스 분석
- 데이터 변환 과정 분석
2. ETL 프로세스
- 데이터 추출, 변환, 로딩 프로세스
- 데이터 웨어하우스 설계
- 데이터 파이프라인 설계
3. 데이터 파이프라인
- 데이터 처리 파이프라인 설계
- 데이터 변환 단계 정의
- 데이터 흐름 최적화
4. 시스템 통합
- 여러 시스템 간 데이터 흐름
- 데이터 교환 프로세스
- 시스템 간 데이터 동기화
5. 데이터 웨어하우스
- 데이터 웨어하우스 설계
- 데이터 수집 및 저장 구조
- 데이터 변환 프로세스
6. 비즈니스 프로세스
- 데이터 중심 비즈니스 프로세스
- 데이터 처리 워크플로우
- 데이터 기반 의사결정 프로세스
어디에 사용하면 유리한지
1. 데이터 중심 시스템
- 상황: 데이터 처리와 변환이 핵심인 시스템
- 예시:
- 데이터 웨어하우스
- ETL 시스템
- 데이터 파이프라인
- 빅데이터 시스템
- 유리한 점:
- 데이터 흐름 명확화
- 데이터 변환 과정 시각화
- 데이터 처리 최적화
2. ETL 프로세스
- 상황: 복잡한 데이터 변환 프로세스
- 예시:
- 데이터 추출, 변환, 로딩
- 데이터 마이그레이션
- 데이터 통합
- 유리한 점:
- ETL 프로세스 시각화
- 데이터 변환 단계 명확화
- 오류 지점 식별
3. 데이터 파이프라인
- 상황: 여러 단계의 데이터 처리
- 예시:
- 실시간 데이터 파이프라인
- 배치 데이터 파이프라인
- 스트리밍 데이터 처리
- 유리한 점:
- 파이프라인 구조 시각화
- 처리 단계 명확화
- 병목 지점 식별
4. 시스템 통합
- 상황: 여러 시스템 간 데이터 교환
- 예시:
- 시스템 간 데이터 동기화
- 데이터 교환 프로세스
- 시스템 통합
- 유리한 점:
- 시스템 간 데이터 흐름 명확화
- 통합 프로세스 시각화
- 데이터 일관성 보장
5. 데이터 웨어하우스
- 상황: 데이터 수집 및 분석 시스템
- 예시:
- 데이터 웨어하우스
- 데이터 마트
- OLAP 시스템
- 유리한 점:
- 데이터 수집 구조 시각화
- 데이터 변환 프로세스 명확화
- 데이터 저장 구조 설계
6. 비즈니스 인텔리전스
- 상황: 데이터 분석 프로세스
- 예시:
- 리포트 생성 프로세스
- 데이터 분석 워크플로우
- 대시보드 데이터 흐름
- 유리한 점:
- 분석 프로세스 시각화
- 데이터 소스 명확화
- 리포트 생성 과정 이해
7. 데이터 마이그레이션
- 상황: 데이터 이전 프로세스
- 예시:
- 레거시 시스템 마이그레이션
- 데이터베이스 마이그레이션
- 클라우드 마이그레이션
- 유리한 점:
- 마이그레이션 프로세스 시각화
- 데이터 변환 계획 수립
- 마이그레이션 검증
어떤 경우에는 과한 경우인지
1. 단순한 CRUD
- 상황: 기본적인 생성, 읽기, 업데이트, 삭제만 있는 경우
- 예시:
- 간단한 웹 애플리케이션
- 기본적인 데이터베이스 작업
- 과한 이유:
- 데이터 흐름이 단순하여 문서화 불필요
2. 정적 데이터
- 상황: 데이터 변환이 없는 경우
- 예시:
- 정적 웹사이트
- 단순한 데이터 조회
- 과한 이유:
- 데이터 변환 프로세스가 없음
3. 단일 데이터베이스
- 상황: 하나의 데이터베이스만 사용하는 경우
- 예시:
- 단일 데이터베이스 애플리케이션
- 과한 이유:
- 데이터 흐름이 단순함
4. 간단한 API
- 상황: 단순한 데이터 전송만 있는 경우
- 예시:
- 간단한 REST API
- 기본적인 데이터 전송
- 과한 이유:
- 데이터 흐름이 명확함
개발 문서에 포함될 경우
1. 시스템 분석 문서 (System Analysis Document)
포함 내용
-
데이터 플로우 다이어그램
- 데이터 흐름 분석
- 데이터 처리 프로세스
- 데이터 저장소
- 외부 엔티티
-
데이터 분석
- 데이터 변환 과정
- 데이터 처리 로직
포함 이유
- 데이터 흐름 분석
- 시스템 이해도 향상
- 데이터 처리 프로세스 문서화
작성 시점
- 시스템 분석 단계
- 데이터 흐름 분석 단계
포함 위치
- 시스템 분석 문서의 “데이터 흐름” 섹션
- “데이터 처리 프로세스” 섹션
2. ETL 설계서 (ETL Design Document)
포함 내용
-
데이터 플로우 다이어그램
- 데이터 추출 프로세스
- 데이터 변환 프로세스
- 데이터 로딩 프로세스
- 데이터 저장소
-
ETL 상세
- 변환 규칙
- 데이터 매핑
- 오류 처리
포함 이유
- ETL 프로세스 시각화
- 데이터 변환 설계
- ETL 개발 가이드
작성 시점
- ETL 설계 단계
- 데이터 웨어하우스 설계 단계
포함 위치
- ETL 설계서의 “ETL 프로세스” 섹션
- “데이터 변환” 섹션
3. 데이터 파이프라인 문서 (Data Pipeline Documentation)
포함 내용
-
데이터 플로우 다이어그램
- 데이터 파이프라인 구조
- 데이터 처리 단계
- 데이터 저장소
- 데이터 흐름
-
파이프라인 상세
- 처리 단계 상세
- 데이터 변환 규칙
- 성능 최적화
포함 이유
- 데이터 파이프라인 구조 시각화
- 파이프라인 개발 가이드
- 파이프라인 운영 가이드
작성 시점
- 데이터 파이프라인 설계 단계
- 파이프라인 문서화 단계
포함 위치
- 데이터 파이프라인 문서의 “파이프라인 구조” 섹션
- “데이터 흐름” 섹션
4. 시스템 통합 문서 (System Integration Document)
포함 내용
-
데이터 플로우 다이어그램
- 시스템 간 데이터 흐름
- 데이터 교환 프로세스
- 데이터 동기화 프로세스
-
통합 상세
- 데이터 매핑
- 데이터 변환 규칙
- 통신 프로토콜
포함 이유
- 시스템 통합 프로세스 시각화
- 데이터 교환 가이드
- 통합 개발 가이드
작성 시점
- 시스템 통합 설계 단계
- 통합 문서화 단계
포함 위치
- 시스템 통합 문서의 “데이터 흐름” 섹션
- “통합 프로세스” 섹션
5. 데이터 웨어하우스 문서 (Data Warehouse Documentation)
포함 내용
-
데이터 플로우 다이어그램
- 데이터 수집 구조
- 데이터 변환 프로세스
- 데이터 저장 구조
- 데이터 흐름
-
데이터 웨어하우스 상세
- 데이터 모델
- ETL 프로세스
- 데이터 저장 구조
포함 이유
- 데이터 웨어하우스 구조 시각화
- 데이터 수집 프로세스 문서화
- 데이터 웨어하우스 운영 가이드
작성 시점
- 데이터 웨어하우스 설계 단계
- 데이터 웨어하우스 문서화 단계
포함 위치
- 데이터 웨어하우스 문서의 “데이터 흐름” 섹션
- “데이터 수집” 섹션
DFD (Data Flow Diagram)
개념
정의
DFD(Data Flow Diagram)는 시스템의 데이터 흐름을 여러 레벨로 세분화하여 표현하는 다이어그램입니다. 컨텍스트 다이어그램에서 시작하여 점진적으로 상세화합니다. 구조적 시스템 분석 방법론의 핵심 도구입니다.
핵심 특징
- 계층적 분해: 여러 레벨로 점진적 상세화
- 데이터 중심: 데이터 흐름에 초점
- 프로세스 중심: 데이터 처리 프로세스 표현
- 구조적 분석: 전통적인 구조적 분석 방법론
주요 레벨
Level 0 (컨텍스트 다이어그램)
- 목적: 시스템과 외부 엔티티의 관계
- 포함: 시스템, 외부 엔티티, 데이터 흐름
Level 1
- 목적: 주요 프로세스로 분해
- 포함: 주요 프로세스, 데이터 저장소, 외부 엔티티
Level 2+
- 목적: 각 프로세스를 더 상세히 분해
- 포함: 상세 프로세스, 데이터 저장소, 데이터 흐름
주요 구성 요소
프로세스
- 정의: 데이터 처리 기능
- 표기: 원형, 번호 포함 (예: 1.0, 2.0)
- 예시: 데이터 검증, 데이터 변환
데이터 저장소
- 정의: 데이터 저장
- 표기: 열린 사각형, D로 시작 (예: D1, D2)
- 예시: 데이터베이스, 파일
외부 엔티티
- 정의: 시스템 외부의 데이터 소스/목적지
- 표기: 사각형
- 예시: 사용자, 외부 시스템
데이터 흐름
- 정의: 데이터 이동
- 표기: 화살표, 라벨 포함
- 예시: 주문 데이터, 사용자 정보
사용하는 곳
1. 시스템 분석
- 구조적 시스템 분석
- 데이터 흐름 분석
- 시스템 요구사항 분석
2. 요구사항 분석
- 데이터 요구사항 분석
- 기능 요구사항 분석
- 시스템 범위 정의
3. 시스템 설계
- 데이터 중심 시스템 설계
- 데이터 처리 프로세스 설계
- 데이터 저장 구조 설계
4. 시스템 문서화
- 기존 시스템의 데이터 흐름 문서화
- 레거시 시스템 분석
- 시스템 구조 문서화
5. 시스템 리팩토링
- 데이터 흐름 개선 계획
- 시스템 구조 개선
- 데이터 처리 최적화
어디에 사용하면 유리한지
1. 구조적 분석 방법론
- 상황: 전통적인 구조적 분석 방법론 사용
- 예시:
- 구조적 시스템 분석
- 전통적인 시스템 개발 방법론
- 유리한 점:
- 구조적 분석에 최적화
- 계층적 분해 지원
- 데이터 중심 설계
2. 복잡한 데이터 처리
- 상황: 여러 단계의 데이터 처리
- 예시:
- 데이터 웨어하우스
- ETL 시스템
- 복잡한 데이터 처리 시스템
- 유리한 점:
- 데이터 처리 프로세스 시각화
- 처리 단계 명확화
- 데이터 흐름 최적화
3. 레거시 시스템 분석
- 상황: 기존 시스템의 데이터 흐름 파악
- 예시:
- 레거시 시스템 분석
- 시스템 문서화
- 유리한 점:
- 역공학으로 데이터 흐름 파악
- 시스템 구조 이해
- 문서화
4. 시스템 통합
- 상황: 여러 시스템의 데이터 흐름 통합
- 예시:
- 시스템 통합 프로젝트
- 데이터 통합
- 유리한 점:
- 시스템 간 데이터 흐름 명확화
- 통합 계획 수립
- 데이터 일관성 보장
5. 데이터 중심 설계
- 상황: 데이터 흐름이 핵심인 시스템
- 예시:
- 데이터 처리 시스템
- 데이터 웨어하우스
- ETL 시스템
- 유리한 점:
- 데이터 중심 설계 지원
- 데이터 흐름 명확화
- 데이터 처리 최적화
어떤 경우에는 과한 경우인지
1. 객체지향 설계
- 상황: OOP 중심의 설계 방법론
- 예시:
- 객체지향 개발
- UML 사용 프로젝트
- 과한 이유:
- 객체지향 개념과 맞지 않음
- UML이 더 적합
- 프로세스 중심이 아닌 객체 중심
2. 애자일 개발
- 상황: 빠른 반복 개발
- 예시:
- 애자일 방법론
- 스크럼, 칸반
- 과한 이유:
- 문서화 비용 높음
- 빠른 변경에 부적합
- 개발 속도 저하 가능
3. 간단한 시스템
- 상황: 데이터 흐름이 단순한 경우
- 예시:
- 간단한 웹 애플리케이션
- 기본적인 CRUD 시스템
- 과한 이유:
- 데이터 흐름이 명확함
- 문서화 불필요
4. 현대적인 마이크로서비스
- 상황: 서비스 간 단순 통신
- 예시:
- 마이크로서비스 아키텍처
- RESTful API 통신
- 과한 이유:
- 서비스 간 통신이 단순함
- 다른 다이어그램이 더 적합 (C4 모델 등)
개발 문서에 포함될 경우
1. 시스템 분석 문서 (System Analysis Document)
포함 내용
-
DFD (Level 0, 1, 2+)
- 컨텍스트 다이어그램
- 주요 프로세스 분해
- 상세 프로세스 분해
-
데이터 사전
- 데이터 구조 정의
- 데이터 흐름 정의
포함 이유
- 구조적 시스템 분석
- 데이터 흐름 분석
- 시스템 이해도 향상
작성 시점
- 시스템 분석 단계
- 구조적 분석 단계
포함 위치
- 시스템 분석 문서의 “데이터 흐름” 섹션
- “시스템 구조” 섹션
2. 요구사항 명세서 (Requirements Specification)
포함 내용
-
DFD (Level 0, 1)
- 시스템 컨텍스트
- 주요 기능 분해
-
데이터 요구사항
- 데이터 구조 요구사항
- 데이터 처리 요구사항
포함 이유
- 데이터 요구사항 분석
- 시스템 범위 정의
- 요구사항 검증
작성 시점
- 요구사항 분석 단계
- 요구사항 정의 단계
포함 위치
- 요구사항 명세서의 “데이터 요구사항” 섹션
- “시스템 범위” 섹션
3. 시스템 설계서 (System Design Document)
포함 내용
-
DFD (Level 1, 2+)
- 시스템 설계 구조
- 프로세스 설계
- 데이터 저장 구조
-
설계 상세
- 프로세스 상세 설계
- 데이터 구조 설계
포함 이유
- 데이터 중심 시스템 설계
- 설계 문서화
- 개발 가이드
작성 시점
- 시스템 설계 단계
- 상세 설계 단계
포함 위치
- 시스템 설계서의 “시스템 구조” 섹션
- “데이터 설계” 섹션
4. 레거시 시스템 문서 (Legacy System Documentation)
포함 내용
-
DFD (Level 0, 1, 2+)
- 기존 시스템 구조
- 데이터 흐름
- 프로세스 구조
-
시스템 분석
- 현재 구조 분석
- 개선 기회 발견
포함 이유
- 레거시 시스템 분석
- 시스템 문서화
- 개선 계획 수립
작성 시점
- 레거시 시스템 분석 단계
- 시스템 문서화 단계
포함 위치
- 레거시 시스템 문서의 “시스템 구조” 섹션
- “데이터 흐름” 섹션
도구
C4 모델 도구
- Structurizr: C4 모델 전용 도구
- C4-PlantUML: PlantUML 기반 C4 모델
- Draw.io: C4 모델 템플릿 제공
- Lucidchart: C4 모델 지원
네트워크 다이어그램 도구
- Cisco Network Assistant: Cisco 네트워크 설계
- NetBrain: 네트워크 자동화 및 문서화
- Draw.io: 네트워크 다이어그램 템플릿
- Lucidchart: 네트워크 다이어그램 지원
인프라스트럭처 다이어그램 도구
- Lucidchart: 인프라 다이어그램 지원
- Draw.io: 인프라 템플릿 제공
- Visio: 기업 표준 도구
- Cloudcraft: 클라우드 인프라 시각화
데이터 플로우 다이어그램 도구
- Draw.io: 데이터 플로우 다이어그램 지원
- Lucidchart: 데이터 플로우 다이어그램 템플릿
- yEd: 그래프 편집기
DFD 도구
- Draw.io: DFD 템플릿 제공
- Lucidchart: DFD 지원
- yEd: DFD 생성 가능
모범 사례
C4 모델
- 적절한 레벨 선택
- 이해관계자에 맞는 추상화
- 일관된 표기법
- 정기적 업데이트
네트워크 다이어그램
- 명확한 토폴로지 표현
- IP 주소 정보 포함
- 보안 구조 명시
- 장비 정보 포함
인프라스트럭처 다이어그램
- 전체 인프라 구조 표현
- 의존성 명확화
- 확장성 고려
- 하드웨어 정보 포함
데이터 플로우 다이어그램
- 데이터 흐름 명확화
- 프로세스 명확히 표현
- 데이터 저장소 명시
- 외부 엔티티 식별
DFD
- 계층적 분해
- 레벨별 일관성
- 데이터 사전 작성
- 프로세스 번호 체계 유지
결론
아키텍처 및 시스템 다이어그램은 복잡한 시스템의 구조를 시각화하는 강력한 도구입니다. C4 모델은 현대적인 소프트웨어 아키텍처 문서화에, 네트워크 다이어그램은 네트워크 인프라 설계에, 인프라스트럭처 다이어그램은 전체 인프라 구조에, 데이터 플로우 다이어그램과 DFD는 데이터 중심 시스템에 각각 유용합니다.
각 다이어그램은 고유한 목적과 사용 사례를 가지고 있으며, 프로젝트의 특성과 요구사항에 맞는 적절한 다이어그램을 선택하는 것이 중요합니다. 적절한 상황에서 사용하면 시스템 이해도와 개발 효율성을 크게 향상시킬 수 있습니다.