데이터 흐름 다이어그램(DFD): 레벨, 기호 및 실제 사례
올바른 표기법으로 데이터 흐름 다이어그램을 만드는 방법을 알아보세요. DFD 레벨 0~2, Yourdon-DeMarco 대 Gane-Sarson 기호, 실제 사례를 다룹니다.
시스템이 고장나거나 프로세스가 잘못된 출력을 생성할 때 첫 번째 질문은 보통 "데이터가 어디서 잘못된 걸까?"입니다. 데이터 흐름 다이어그램(DFD)은 데이터 이동을 명시적으로 보여줌으로써 이 질문에 답합니다 — 데이터가 어디서 오는지, 어디로 가는지, 어떻게 변환되는지, 어디에 저장되는지를 정확히 보여줍니다.
제어 흐름을 모델링하는 플로우차트(다음에 무슨 일이 일어나는지)와 달리, DFD는 데이터 흐름을 모델링합니다(어떤 데이터가 어디로 이동하는지). 이 차이로 인해 DFD는 시스템 분석, 소프트웨어 설계, 복잡한 데이터 통합 문서화에 적합한 도구가 됩니다.
데이터 흐름 다이어그램이란?
데이터 흐름 다이어그램은 시스템을 통해 데이터가 어떻게 이동하는지를 시각적으로 표현한 것입니다. 다음을 보여줍니다:
- 외부 엔터티 — 시스템 외부의 데이터 소스 및 목적지
- 프로세스 — 입력 데이터를 출력 데이터로 변환하는 변환
- 데이터 저장소 — 데이터가 저장되는 장소
- 데이터 흐름 — 위의 요소들 사이의 데이터 이동
DFD는 타이밍, 의사결정 로직, 또는 작업을 수행하는 사람을 보여주지 않습니다. 오직 데이터 이동만 보여줍니다. 이 집중된 범위로 인해 구현 세부 사항에 빠져들지 않고 시스템을 이해하고 설계하는 데 유용합니다.
DFD 기호
두 가지 표기법이 지배적입니다: Yourdon-DeMarco와 Gane-Sarson. 이 둘은 다른 모양으로 동일한 개념을 나타냅니다.
Yourdon-DeMarco 표기법
원래의 구조적 분석 표기법으로 소프트웨어 공학에서 널리 사용됩니다:
| 요소 | 기호 | 설명 |
|---|---|---|
| 프로세스 | 원 (버블) | 데이터를 변환; 동사구로 레이블 |
| 데이터 저장소 | 열린 직사각형 | 데이터를 저장; 명사로 레이블 |
| 외부 엔터티 | 직사각형 | 시스템 외부의 소스 또는 목적지 |
| 데이터 흐름 | 레이블이 있는 화살표 | 요소 간에 이동하는 명명된 데이터 |
┌──────────┐ ╭──────────╮ ┌═══════════════╗
│ 고객 │───────→ │ 주문 │───────→ ║ D1: 주문 ║
└──────────┘ 주문 │ 검증 │ 유효 ╠═══════════════╣
╰──────────╯ 주문 ║ ║
Gane-Sarson 표기법
정보 시스템 및 비즈니스 분석에서 일반적으로 사용됩니다:
| 요소 | 기호 | 설명 |
|---|---|---|
| 프로세스 | 분할 헤더가 있는 둥근 모서리 직사각형 | ID와 프로세스 이름으로 레이블 |
| 데이터 저장소 | 왼쪽이 열린 직사각형 | D-번호와 이름으로 레이블 |
| 외부 엔터티 | 직사각형 | 시스템 외부의 소스 또는 목적지 |
| 데이터 흐름 | 레이블이 있는 화살표 | 요소 간에 이동하는 명명된 데이터 |
┌──────────┐ ┌────────────────┐ ┌═══╦════════════╗
│ 고객 │───────→ │ 1.0 │───────→ ║D1 ║ 주문 ║
└──────────┘ 주문 │ 주문 검증 │ 유효 ╚═══╩════════════╝
└────────────────┘ 주문
어떤 표기법을 사용할까요?
두 표기법 모두 동일한 정보를 전달합니다. 맥락에 따라 선택하세요:
- Yourdon-DeMarco: 소프트웨어 공학, 학문, 구조적 분석 방법을 사용할 때 선호
- Gane-Sarson: 비즈니스 정보 시스템과 기업 맥락에서 일반적
하나를 선택하고 프로젝트의 모든 다이어그램에 일관되게 사용하세요.
DFD 레벨
DFD는 계층적으로 구성됩니다. 상위 레벨 다이어그램은 개요를 제공하고, 하위 레벨 다이어그램은 세부 사항을 제공합니다. 각 레벨은 상위 레벨의 단일 프로세스를 내부 서브프로세스로 분해합니다.
레벨 0: 컨텍스트 다이어그램
컨텍스트 다이어그램은 전체 시스템을 외부 엔터티에 둘러싸인 단일 프로세스로 보여줍니다. 시스템 경계를 정의하고 해당 경계를 넘나드는 데이터를 보여줍니다.
고객 주문
┌──────────┐ ─────────────────→ ╭──────────────────────╮
│ 고객 │ │ │
└──────────┘ ←───────────────── │ 주문 관리 │
주문 확인 │ 시스템 │
│ │
┌──────────┐ ─────────────────→ ╰──────────────────────╯
│ 공급업체│ 재고 업데이트 │
└──────────┘ ↓
┌──────────────┐
│ 결제 처리 │
└──────────────┘
컨텍스트 다이어그램은 한 페이지에 맞아야 하며 경계를 넘는 데이터 흐름만 보여줘야 합니다 — 내부 세부 사항은 없습니다. 내부 프로세스를 추가하고 있다면 잘못된 레벨에 있는 것입니다.
레벨 1: 개요 다이어그램
레벨 1 다이어그램은 단일 컨텍스트 프로세스를 주요 서브프로세스로 분해합니다. 이것들이 시스템의 주요 기능 영역입니다.
┌──────────┐ ╭──────────╮ ╭──────────╮
│ 고객 │───────→ │ 1.0 │───────→ │ 2.0 │───┐
└──────────┘ 주문 │ 주문 │검증된 │ 결제 │ │
│ 수신 │ 주문 │ 처리 │ │
╰──────────╯ ╰──────────╯ │
│ ↓
↓ ╭──────────╮
┌════════════════╗ │ 3.0 │
║ D1: 주문 ║────────────→ │ 주문 │
╚════════════════╝ 주문 데이터 │ 이행 │
╰──────────╯
│
↓
┌──────────┐
│ 배송 │
│ 파트너 │
└──────────┘
레벨 1 다이어그램은 일반적으로 3-7개의 프로세스를 가집니다. 더 많다면 더 적은 수의 상위 레벨 프로세스로 그룹화하는 것을 고려하세요.
레벨 2: 상세 다이어그램
레벨 2는 각 레벨 1 프로세스를 서브 단계로 분해합니다. 레벨 1의 각 버블은 고유한 레벨 2 다이어그램을 갖습니다.
예를 들어, 위에서 프로세스 1.0 「주문 수신」을 확장하면:
┌──────────┐ ╭──────────╮ ╭──────────╮
│ 고객 │──────────→ │ 1.1 │──────────→ │ 1.2 │
└──────────┘ 원시 주문 │ 형식 │ 유효 데이터│ 재고 │
│ 검증 │ │ 확인 │
╰──────────╯ ╰──────────╯
│ │ │
유효하지 │ 재고 있음
않은 주문 재고 없음│
↓ ↓
┌──────────┐ ╭──────────╮
│ 고객 │ │ 1.3 │
└──────────┘ │ 상품 │
│ 예약 │
╰──────────╯
│
↓
┌════════════╗
║ D1: 주문 ║
╚════════════╝
얼마나 깊이 분해해야 할까요?
다음과 같을 때 분해를 중단하세요:
- 몇 문장으로 설명할 수 있을 만큼 단순한 경우
- 단일 사람이나 원자적 시스템 기능으로 구현된 경우
- 구현에 필요한 세부 수준에 이미 도달한 경우
대부분의 시스템은 레벨 2 이상이 필요 없습니다. 레벨 3은 드물며 종종 시스템이 너무 복잡하거나 분해가 잘 구조화되지 않았음을 나타냅니다.
DFD 대 플로우차트
두 가지 모두 상자와 화살표를 사용하기 때문에 자주 혼동됩니다. 하지만 서로 다른 질문에 답합니다.
| 측면 | 데이터 흐름 다이어그램 | 플로우차트 |
|---|---|---|
| 보여주는 것 | 데이터가 시스템을 통해 어떻게 이동하는지 | 제어가 프로세스를 통해 어떻게 흐르는지 |
| 주요 질문 | 어떤 데이터가 어디로 가는가? | 다음에 무슨 일이 일어나는가? |
| 시간/순서 | 모델링되지 않음 (데이터 변환만) | 중심 — 순서가 주요 구조 |
| 의사결정 로직 | 표현되지 않음 | 명시적 (마름모 의사결정 노드) |
| 수행자 | 표시되지 않음 | 수영레인 형식으로 표시 가능 |
| 데이터 저장 | 명시적 데이터 저장 기호 | 표현되지 않음 |
| 적합한 경우 | 시스템 분석, 데이터 아키텍처 | 프로세스 문서화, 절차 가이드 |
플로우차트는 대출 승인 프로세스의 단계를 보여줍니다. DFD는 대출 신청 시스템이 받는 데이터, 저장 위치, 생산하는 출력을 보여줍니다.
시스템을 분석하거나 설계할 때는 DFD를 사용하세요. 절차를 문서화할 때는 플로우차트를 사용하세요.
단계별: DFD 만들기
1단계: 시스템 경계 정의
시스템 내부와 외부에 있는 것을 식별합니다:
- 내부: 제어하는 프로세스, 데이터 저장소, 데이터 흐름
- 외부: 외부 엔터티 — 고객, 파트너, 외부 시스템
경계 외부의 모든 것은 외부 엔터티입니다. 경계를 넘는 데이터는 컨텍스트 다이어그램에서 흐름으로 나타납니다.
2단계: 컨텍스트 다이어그램 그리기 (레벨 0)
- 전체 시스템을 중앙에 단일 레이블이 있는 원으로 배치
- 모든 외부 엔터티를 식별하고 외부에 배치
- 설명적인 레이블로 경계를 넘는 데이터 흐름 그리기
- 완성도 확인: 시스템에 들어오거나 나가는 데이터 중 레이블이 없는 것이 있나요?
3단계: 주요 프로세스 식별 (레벨 1)
시스템을 3-7개의 주요 프로세스로 분해합니다:
- 각 프로세스에 동사구로 이름 붙이기 ("주문 검증", "결제 처리")
- 번호 매기기 (1.0, 2.0, 3.0)
- 연결하는 데이터 흐름 식별
4단계: 데이터 저장소 추가
프로세스 사이에 데이터가 보관되는 위치를 식별합니다:
- 데이터베이스: 고객 기록, 주문 내역, 재고
- 파일: 로그 파일, 설정
- 외부 데이터: 외부 시스템으로/에서 전달되는 데이터 (종종 경계 흐름으로 표현, 내부 저장소 아님)
각 데이터 저장소에 명사로 이름을 붙이고 D-번호를 할당합니다 (D1, D2).
5단계: 데이터 흐름으로 연결
요소 간에 레이블이 있는 화살표를 그립니다:
- 흐름에는 설명적인 이름이 있어야 함 ("고객 주문", "검증된 기록", "청구서")
- 흐름은 프로세스와 프로세스, 프로세스와 데이터 저장소, 외부 엔터티와 프로세스를 연결
- 데이터 저장소는 외부 엔터티와 직접 연결되지 않음 (데이터는 프로세스를 통해 전달되어야 함)
6단계: 레벨 2로 분해
레벨 1의 각 주요 프로세스에 대해 내부 서브프로세스를 보여주는 별도의 레벨 2 다이어그램을 그립니다. 레벨 1 프로세스에 들어오고 나가는 데이터 흐름이 레벨 2 다이어그램의 경계 흐름이 됩니다.
7단계: 일관성 검증
다음을 확인합니다:
- 프로세스에 들어오는 모든 데이터 흐름이 해당 프로세스에서 사용되는가
- 프로세스에서 나가는 모든 데이터 흐름이 해당 프로세스에서 시작되는가
- 데이터 저장소는 프로세스를 통해서만 액세스됨 (외부 엔터티가 직접 액세스하지 않음)
- 레벨 1 경계 흐름이 컨텍스트 다이어그램 흐름과 일치하는가
실제 사례: 전자상거래 주문 시스템
레벨 0: 컨텍스트 다이어그램
┌──────────┐ 주문 요청 ╭──────────────────────╮
│ 고객 │ ────────────────→ │ │
└──────────┘ │ 전자상거래 │
↑ 주문 상태 │ 주문 시스템 │
└───────────────────────── │ │
╰──────────────────────╯
┌──────────┐ 결제 결과 │ ↑
│ 결제 │ ────────────────→ │ │
│ 게이트웨이│ ←──────────────── │ 배송
└──────────┘ 청구 요청 ↓ 데이터
┌──────────────┐
│ 배송 │
│ 파트너 │
└──────────────┘
레벨 1: 주요 프로세스
고객 ─── 주문 요청 ──→ ╭──────────╮
│ 1.0 │ ──→ D1: 주문
│ 주문 │
│ 검증 │
╰──────────╯
│
검증된 주문
↓
결제 게이트웨이 ←── 청구 ── ╭──────────╮ ── 결제 ──→ D2: 결제
요청 │ 2.0 │ 기록
결제 게이트웨이 ── 결과 ──→ │ 결제 │
│ 처리 │
╰──────────╯
│
확정된 주문
↓
╭──────────╮
D1: 주문 ── 주문 데이터 ──→ │ 3.0 │ ── 배송 요청 ──→ 배송
D3: 상품 ─ 재고 데이터 ───→ │ 주문 │ 파트너
│ 이행 │
╰──────────╯
│
배송 데이터
↓
╭──────────╮
│ 4.0 │ ── 상태 업데이트 ──→ 고객
│ 추적 & │
│ 알림 │
╰──────────╯
레벨 2: 프로세스 1.0 분해 (주문 검증)
고객 ─── 원시 주문 ──→ ╭──────────╮
│ 1.1 │ ── 유효하지 않음 ──→ 고객 (오류)
│ 형식 │
│ 확인 │
╰──────────╯
│
형식화된 주문
↓
╭──────────╮
D3: 상품 ─ 재고 정보 ─→ │ 1.2 │ ── 재고 없음 ──→ 고객
│ 재고 │
│ 확인 │
╰──────────╯
│
가능한 주문
↓
╭──────────╮
D4: 고객 ─ 인증 데이터 ─→│ 1.3 │ ── 미검증 ──→ 고객
│ 고객 │
│ 확인 │
╰──────────╯
│
검증된 주문
↓
D1: 주문 (저장됨)
일반적인 DFD 실수
외부 엔터티를 데이터 저장소에 직접 연결하는 경우. 데이터 저장소는 내부적입니다; 외부 엔터티는 직접 액세스할 수 없습니다. 시스템 경계를 넘는 모든 데이터는 프로세스를 통해 전달되어야 합니다.
레이블이 없는 데이터 흐름. 모든 화살표에는 설명적인 이름이 있어야 합니다. "데이터" 또는 "정보"는 설명적이지 않습니다. 흐름은 데이터가 나타내는 것으로 이름을 붙여야 합니다: "고객 주문", "결제 확인", "재고 수준".
입력 또는 출력이 없는 프로세스. 프로세스에는 최소한 하나의 입력 흐름과 하나의 출력 흐름이 있어야 합니다. 들어오는 데이터가 없는 원은 아무것도 없이 데이터를 "생성"합니다 — 이것은 프로세스가 아니라 외부 엔터티입니다. 나가는 데이터가 없는 원은 모든 것을 버립니다 — 데이터 저장소 쓰기로 모델링하거나 프로세스를 제거하세요.
제어 흐름과 데이터 흐름 혼합. 결정, 순서, 제어 로직은 DFD에 속하지 않습니다. 결정 마름모를 그리고 있다면 DFD가 아닌 플로우차트를 만들고 있는 것입니다. DFD는 데이터 이동만 보여줍니다.
레벨 1에 너무 많은 세부 사항. 레벨 1에는 3-7개의 주요 프로세스가 있어야 합니다. 레벨 1에 15개의 프로세스를 표시하고 있다면 계층적 분해를 건너뛴 것입니다. 관련 프로세스를 더 상위 수준의 버블로 그룹화하고 레벨 2를 사용하여 세부 사항을 보여주세요.
일관되지 않은 레벨. 레벨 1 다이어그램에서 프로세스 2.0에 들어오는 데이터 흐름은 프로세스 2.0의 레벨 2 다이어그램의 경계 흐름과 일치해야 합니다. 불일치는 다이어그램이 동일한 시스템을 나타내지 않음을 의미합니다.
설명 없이 서브시스템 간에 공유된 데이터 저장소. 여러 프로세스가 동일한 데이터 저장소에 액세스하는 경우, 의도적인지 그리고 액세스가 타당한지 확인하세요. 단일 "주 데이터베이스" 데이터 저장소를 과도하게 사용하면 중요한 데이터 아키텍처 결정이 숨겨집니다.
Flowova로 데이터 흐름 다이어그램 만들기
데이터 흐름을 수동으로 매핑하는 것은 지루합니다 — 모든 경계 흐름을 식별하고, 프로세스에 일관되게 번호를 매기고, 레벨을 동기화하는 데 상당한 노력이 필요합니다.
Flowova의 데이터 흐름 다이어그램 메이커는 일반 언어 시스템 설명에서 DFD 구조를 생성합니다. 시스템의 입력, 출력, 주요 프로세스를 설명하면 정제할 수 있는 초안 다이어그램을 얻을 수 있습니다. 이는 특히 컨텍스트 다이어그램과 레벨 1 개요를 빠르게 만든 다음, 필요한 프로세스에 대해 레벨 2 세부 사항으로 드릴다운하는 데 유용합니다.
결론
DFD는 데이터가 시스템을 통해 어떻게 이동하는지 이해하거나 소통해야 할 때 적합한 도구입니다 — 단계별로 무슨 일이 일어나는지가 아니라, 데이터가 어디서 시작되고, 무엇이 변환하고, 어디에 저장되며, 궁극적으로 어디로 가는지를 보여줍니다.
컨텍스트 다이어그램으로 시작하여 시스템 경계를 설정하세요. 주요 프로세스를 식별하기 위해 레벨 1로 분해하세요. 추가 설명이 필요한 프로세스에만 레벨 2로 이동하세요. 데이터 흐름에 구체적인 이름을 붙이고, 제어 로직을 다이어그램에 혼합하지 않으며, 레벨 간 일관성을 확인하세요.
관련 리소스
- 플로우차트 기호와 의미 — 표준 표기법 참조
- BPMN 다이어그램 가이드 — 비즈니스 프로세스 모델링 표준
- 데이터 흐름 다이어그램 메이커 — AI로 DFD 만들기
- 시스템 아키텍처 템플릿 — 바로 사용 가능한 아키텍처 다이어그램 템플릿
