플로우차트 및 ER 다이어그램 상세 가이드
목차
플로우차트
개념
정의
플로우차트(Flowchart)는 프로세스, 알고리즘, 워크플로우를 단계별로 표현하는 다이어그램입니다. 각 단계를 기하학적 도형으로 표현하고, 화살표로 흐름을 나타내어 프로세스의 논리적 순서를 시각화합니다.
핵심 특징
- 순차적 표현: 시간 순서대로 단계를 표현
- 명확한 시작과 종료: 프로세스의 시작점과 종료점 명시
- 의사결정 지점: 조건 분기를 명확히 표현
- 표준 심볼: 일관된 기호 사용으로 이해도 향상
- 직관적 이해: 비개발자도 쉽게 이해 가능
역사
- 1921년: Frank Gilbreth이 “Process Chart” 개념 제시
- 1940년대: Herman Goldstine과 John von Neumann이 컴퓨터 프로그래밍에 적용
- 1947년: ASME(American Society of Mechanical Engineers)가 표준 심볼 제정
- 현재: ISO 5807, ANSI X3.5 등 국제 표준 존재
기본 원칙
- 순차적 표현: 시간 순서대로 단계 표현
- 명확한 시작과 종료: 프로세스의 시작점과 종료점 명시
- 의사결정 지점: 조건 분기 명확히 표현
- 표준 심볼: 일관된 기호 사용
플로우차트 심볼
기본 심볼
1. 시작/종료 (Terminator)
- 모양: 둥근 사각형 또는 타원형
- 용도: 프로세스의 시작점과 종료점
- 표기: “시작”, “종료”, “Start”, “End”
2. 프로세스 (Process)
- 모양: 직사각형
- 용도: 처리 작업, 계산, 연산
- 표기: 동작을 명확히 기술 (예: “데이터 검증”, “계산 수행”)
3. 의사결정 (Decision)
- 모양: 다이아몬드
- 용도: 조건 판단, 분기점
- 표기: Yes/No 질문 또는 조건식
- 출력: 최소 2개의 화살표 (True/False)
4. 입력/출력 (Input/Output)
- 모양: 평행사변형
- 용도: 데이터 입력 또는 출력
- 표기: “사용자 입력”, “결과 출력”, “파일 읽기”
5. 준비 (Preparation)
- 모양: 육각형
- 용도: 변수 초기화, 설정
- 표기: “변수 초기화”, “설정 로드”
6. 미리 정의된 프로세스 (Predefined Process)
- 모양: 직사각형 (양쪽에 수직선)
- 용도: 서브루틴, 함수 호출
- 표기: 함수명 또는 프로세스명
7. 연결자 (Connector)
- 모양: 원형
- 용도: 같은 페이지 내 연결 또는 다른 페이지 연결
- 표기: 문자 또는 숫자로 식별
8. 주석 (Annotation)
- 모양: 점선으로 연결된 사각형
- 용도: 추가 설명, 노트
- 표기: 설명 텍스트
9. 화살표 (Arrow/Flowline)
- 모양: 화살표
- 용도: 프로세스 흐름 방향 표시
- 표기: 단방향 또는 양방향
고급 심볼
1. 문서 (Document)
- 모양: 물결 모양이 있는 사각형
- 용도: 문서 출력 또는 입력
2. 데이터베이스 (Database)
- 모양: 원통형
- 용도: 데이터베이스 접근
3. 수동 입력 (Manual Input)
- 모양: 사다리꼴
- 용도: 키보드 입력
4. 수동 작업 (Manual Operation)
- 모양: 사각형 (위쪽이 물결 모양)
- 용도: 사람이 수행하는 작업
5. 병합 (Merge)
- 모양: 역삼각형
- 용도: 여러 흐름을 하나로 합침
6. 저장 (Storage)
- 모양: 역삼각형 (위쪽이 열림)
- 용도: 데이터 저장
사용하는 곳
1. 프로그래밍 및 소프트웨어 개발
알고리즘 설계
- 용도: 알고리즘의 논리적 흐름 표현
- 예시:
- 정렬 알고리즘 (버블 정렬, 퀵 정렬)
- 검색 알고리즘 (이진 검색)
- 재귀 알고리즘
- 그래프 알고리즘
- 장점: 복잡한 로직을 단계별로 이해 가능
프로그램 로직 문서화
- 용도: 코드의 실행 흐름 설명
- 예시:
- 복잡한 비즈니스 로직
- 조건문이 많은 함수
- 예외 처리 흐름
- 상태 머신 로직
- 장점: 코드 리뷰 시 이해도 향상
디버깅
- 용도: 버그 발생 지점 추적
- 예시:
- 예상 흐름과 실제 흐름 비교
- 조건 분기 오류 발견
- 논리적 오류 식별
- 장점: 논리적 오류 시각화
2. 비즈니스 프로세스
업무 프로세스 문서화
- 용도: 조직의 업무 프로세스 시각화
- 예시:
- 주문 처리 프로세스
- 고객 지원 프로세스
- 승인 워크플로우
- 재고 관리 프로세스
- 장점: 업무 표준화, 신입 교육
프로세스 개선
- 용도: 현재 프로세스 분석 및 개선점 도출
- 예시:
- 불필요한 단계 제거
- 병목 지점 식별
- 자동화 가능 영역 발견
- 효율성 개선
- 장점: 효율성 향상, 비용 절감
규정 준수
- 용도: 규정 및 절차 준수 확인
- 예시:
- 품질 관리 프로세스
- 보안 절차
- 감사 프로세스
- 컴플라이언스 프로세스
- 장점: 규정 준수 증명, 감사 대응
3. 교육 및 학습
프로그래밍 교육
- 용도: 프로그래밍 개념 설명
- 예시:
- 제어 구조 (if, for, while)
- 함수 호출 흐름
- 객체지향 개념
- 알고리즘 학습
- 장점: 추상적 개념 구체화
문제 해결 교육
- 용도: 문제 해결 과정 시각화
- 예시:
- 수학 문제 풀이 과정
- 과학 실험 절차
- 논리적 사고 과정
- 의사결정 과정
- 장점: 체계적 사고 습관 형성
4. 시스템 분석
시스템 프로세스 분석
- 용도: 시스템의 동작 과정 분석
- 예시:
- 사용자 인증 프로세스
- 데이터 처리 파이프라인
- 트랜잭션 처리
- 배치 작업 프로세스
- 장점: 시스템 이해도 향상
의사결정 프로세스
- 용도: 의사결정 로직 표현
- 예시:
- 승인 프로세스
- 라우팅 로직
- 비즈니스 규칙
- 자동화 규칙
- 장점: 의사결정 기준 명확화
5. 품질 관리
테스트 프로세스
- 용도: 테스트 절차 정의
- 예시:
- 단위 테스트 프로세스
- 통합 테스트 절차
- 사용자 수용 테스트
- 회귀 테스트 프로세스
- 장점: 테스트 일관성 유지
품질 검사 프로세스
- 용도: 품질 검사 절차 문서화
- 예시:
- 제품 검사 프로세스
- 코드 리뷰 프로세스
- 릴리스 프로세스
- 배포 프로세스
- 장점: 품질 표준 유지
6. 운영 및 유지보수
운영 절차
- 용도: 운영 프로세스 문서화
- 예시:
- 배포 프로세스
- 백업 프로세스
- 모니터링 절차
- 인시던트 대응 프로세스
- 장점: 운영 표준화, 인수인계
트러블슈팅 가이드
- 용도: 문제 해결 절차 정의
- 예시:
- 장애 대응 프로세스
- 성능 문제 해결
- 보안 이슈 대응
- 데이터 복구 프로세스
- 장점: 빠른 문제 해결
어디에 사용하면 유리한지
1. 복잡한 조건 분기가 많은 경우
다중 조건문
- 상황: if-else, switch-case가 중첩된 복잡한 로직
- 예시:
- 사용자 권한 체크 (역할, 부서, 프로젝트 등)
- 가격 계산 로직 (할인, 쿠폰, 포인트 등)
- 라우팅 로직 (다양한 조건에 따른 분기)
- 승인 프로세스 (다단계 승인)
- 유리한 점:
- 모든 분기 경로를 한눈에 파악
- 누락된 케이스 발견 용이
- 테스트 케이스 작성 가이드
- 코드 리뷰 시 논리 오류 발견
상태 머신
- 상황: 여러 상태와 전이 조건이 있는 경우
- 예시:
- 주문 상태 (대기, 결제, 배송, 완료 등)
- 승인 워크플로우
- 게임 상태 관리
- 문서 라이프사이클
- 유리한 점:
- 상태 전이 명확화
- 불가능한 상태 전이 발견
- 상태 다이어그램과 함께 사용 가능
2. 비개발자와 소통이 필요한 경우
비즈니스 분석가
- 상황: 비즈니스 요구사항을 개발자에게 전달
- 예시:
- 비즈니스 규칙 설명
- 프로세스 개선 제안
- 요구사항 검증
- 유리한 점:
- 기술 용어 없이 이해 가능
- 시각적으로 명확
- 피드백 수집 용이
이해관계자
- 상황: 프로젝트 이해관계자에게 프로세스 설명
- 예시:
- 고객에게 시스템 프로세스 설명
- 경영진에게 비즈니스 프로세스 제시
- 사용자에게 워크플로우 교육
- 유리한 점:
- 직관적 이해
- 프레젠테이션 자료로 활용
- 합의 도출 용이
3. 교육 및 온보딩
신입 개발자 교육
- 상황: 복잡한 레거시 코드 이해
- 예시:
- 기존 시스템 로직 설명
- 비즈니스 규칙 전달
- 코드 구조 이해
- 유리한 점:
- 빠른 이해
- 질문 감소
- 학습 곡선 완화
사용자 교육
- 상황: 시스템 사용법 교육
- 예시:
- 주문 프로세스 안내
- 보고서 생성 절차
- 설정 변경 방법
- 유리한 점:
- 단계별 가이드
- 오류 방지
- 일관된 사용
4. 프로세스 개선이 필요한 경우
비효율적 프로세스
- 상황: 현재 프로세스의 문제점 분석
- 예시:
- 불필요한 단계 식별
- 병목 지점 발견
- 중복 작업 제거
- 유리한 점:
- 전체 프로세스 한눈에 파악
- 개선점 시각화
- Before/After 비교
자동화 계획
- 상황: 수동 프로세스의 자동화 계획
- 예시:
- 반복 작업 자동화
- 의사결정 로직 시스템화
- 워크플로우 자동화
- 유리한 점:
- 자동화 가능 영역 식별
- 자동화 범위 결정
- ROI 계산
5. 문서화가 중요한 경우
표준 절차 문서화
- 상황: 조직의 표준 프로세스 정의
- 예시:
- 개발 프로세스
- 배포 프로세스
- 인시던트 대응 절차
- 유리한 점:
- 일관성 유지
- 감사 대응
- 지식 공유
규정 준수
- 상황: 규정 및 표준 준수 요구
- 예시:
- ISO 인증
- 보안 규정 준수
- 산업 표준 준수
- 유리한 점:
- 규정 준수 증명
- 검증 용이
- 문서화 요구사항 충족
6. 디버깅 및 문제 해결
복잡한 버그 분석
- 상황: 논리적 오류 추적
- 예시:
- 조건 분기 오류
- 상태 전이 오류
- 데이터 흐름 오류
- 유리한 점:
- 예상 흐름과 실제 흐름 비교
- 오류 지점 식별
- 수정 방안 도출
성능 문제 분석
- 상황: 병목 지점 찾기
- 예시:
- 반복 작업 최적화
- 불필요한 분기 제거
- 캐싱 가능 지점 발견
- 유리한 점:
- 전체 흐름 파악
- 최적화 포인트 식별
어떤 경우에는 과한 경우인지
1. 매우 간단한 프로세스
단순한 순차 작업
- 상황: 단계가 3-4개 이하이고 분기가 없는 경우
- 예시:
- 변수 할당 후 출력
- 간단한 계산
- 단순한 함수 호출
- 과한 이유:
- 코드 자체가 이미 명확함
- 문서화 시간 낭비
- 유지보수 부담만 증가
일회성 스크립트
- 상황: 한 번만 실행하고 버리는 스크립트
- 예시:
- 데이터 변환 스크립트
- 일회성 마이그레이션
- 임시 작업
- 과한 이유:
- 문서화 ROI 낮음
- 빠른 개발이 우선
- 재사용 불가
2. 이미 다른 도구를 사용하는 경우
UML 액티비티 다이어그램
- 상황: UML을 이미 사용하고 있는 프로젝트
- 예시:
- 객체지향 설계 프로젝트
- 엔터프라이즈 애플리케이션
- 과한 이유:
- 중복 문서화
- UML이 더 풍부한 표현력 제공
- 일관성 저하
BPMN
- 상황: 비즈니스 프로세스 모델링에 BPMN 사용
- 예시:
- 워크플로우 엔진 사용
- 비즈니스 프로세스 자동화
- 과한 이유:
- BPMN이 더 표준적이고 풍부함
- 도구 지원 우수
- 실행 가능한 모델 생성
상태 다이어그램
- 상황: 상태 머신이 복잡한 경우
- 예시:
- 복잡한 상태 전이
- 병렬 상태
- 과한 이유:
- 상태 다이어그램이 더 적합
- 상태 중심 표현에 유리
- 도구 지원 우수
3. 실시간 또는 이벤트 기반 시스템
이벤트 드리븐 아키텍처
- 상황: 비동기 이벤트 처리 시스템
- 예시:
- 메시지 큐 기반 시스템
- 마이크로서비스 통신
- 이벤트 소싱
- 과한 이유:
- 순차적 흐름 표현에 한계
- 시퀀스 다이어그램이 더 적합
- 이벤트 흐름 표현 어려움
실시간 시스템
- 상황: 시간 제약이 중요한 시스템
- 예시:
- 임베디드 시스템
- 실시간 제어 시스템
- 과한 이유:
- 시간 제약 표현 어려움
- 타이밍 다이어그램이 더 적합
- 병렬 처리 표현 제한
4. 함수형 프로그래밍
순수 함수
- 상황: 부작용 없는 순수 함수
- 예시:
- 함수형 언어 (Haskell, Clojure)
- 데이터 변환 파이프라인
- 과한 이유:
- 함수 조합이 이미 명확
- 데이터 플로우 다이어그램이 더 적합
- 순차적 흐름보다 데이터 변환 중심
고차 함수
- 상황: 함수를 인자로 받는 함수
- 예시:
- map, filter, reduce
- 함수형 파이프라인
- 과한 이유:
- 함수 조합이 더 명확
- 플로우차트로 표현하기 어려움
5. 빠른 프로토타이핑
MVP 개발
- 상황: 빠른 검증이 필요한 경우
- 예시:
- 스타트업 초기 제품
- 개념 검증
- 과한 이유:
- 문서화 시간이 개발 시간보다 많을 수 있음
- 빠른 변경으로 문서 유지 어려움
- 개발 속도 저하
실험적 기능
- 상황: 불확실한 기능 개발
- 예시:
- A/B 테스트 기능
- 연구 프로젝트
- 과한 이유:
- 최종 구조 미정
- 문서화 투자 대비 효과 낮음
6. 이미 잘 문서화된 코드
자가 문서화 코드
- 상황: 코드 자체가 매우 명확한 경우
- 예시:
- 명확한 함수명과 변수명
- 충분한 주석
- 단순한 로직
- 과한 이유:
- 중복 문서화
- 유지보수 부담
- 코드와 문서 불일치 위험
테스트 코드
- 상황: 테스트 코드가 이미 로직을 설명하는 경우
- 예시:
- BDD 스타일 테스트
- 통합 테스트
- 과한 이유:
- 테스트가 이미 문서 역할
- 실행 가능한 문서
- 중복 문서화
7. 팀이 플로우차트에 익숙하지 않은 경우
학습 곡선
- 상황: 팀이 플로우차트를 처음 사용
- 예시:
- 신입 개발자 팀
- 다른 문화의 팀
- 과한 이유:
- 초기 생산성 저하
- 잘못된 사용 가능성
- 도구 학습 필요
소규모 팀
- 상황: 2-3명의 작은 팀
- 예시:
- 스타트업 초기 팀
- 같은 공간에서 작업
- 과한 이유:
- 직접 소통으로 충분
- 문서화 오버헤드
- 빠른 피드백 가능
개발 문서에 포함될 경우
1. 알고리즘 설계 문서 (Algorithm Design Document)
포함 내용
-
알고리즘 플로우차트
- 알고리즘의 전체 흐름
- 주요 단계와 조건 분기
- 입력/출력 명시
- 예외 처리 흐름
-
복잡도 분석
- 시간 복잡도
- 공간 복잡도
- 최적화 포인트
포함 이유
- 알고리즘 로직을 시각적으로 이해
- 구현 가이드 제공
- 성능 분석 기반
- 코드 리뷰 기준
작성 시점
- 알고리즘 설계 단계
- 성능 최적화 계획 단계
- 코드 리뷰 전
- 문서화 단계
포함 위치
- 알고리즘 설계서의 “알고리즘 개요” 섹션
- “상세 설계” 섹션
- “복잡도 분석” 섹션
2. 비즈니스 로직 명세서 (Business Logic Specification)
포함 내용
-
비즈니스 규칙 플로우차트
- 비즈니스 규칙의 논리적 흐름
- 조건 분기와 예외 처리
- 승인 프로세스
- 의사결정 로직
-
의사결정 트리
- 복잡한 의사결정 로직
- 다중 조건 처리
포함 이유
- 비즈니스 요구사항 명확화
- 개발자와 비즈니스 분석가 간 소통
- 테스트 케이스 작성 기반
- 요구사항 검증
작성 시점
- 요구사항 분석 단계
- 비즈니스 규칙 정의 단계
- 개발 전 검증 단계
- 요구사항 검토 단계
포함 위치
- 비즈니스 로직 명세서의 “비즈니스 규칙” 섹션
- “프로세스 흐름” 섹션
- “의사결정 로직” 섹션
3. API 설계 문서 (API Design Document)
포함 내용
-
API 호출 플로우차트
- API 호출 시퀀스
- 에러 처리 흐름
- 인증/인가 프로세스
- 재시도 로직
-
비즈니스 로직 플로우
- API 내부 처리 로직
- 데이터 검증 과정
- 비즈니스 규칙 적용
포함 이유
- API 사용법 시각화
- 에러 처리 가이드
- 통합 가이드 제공
- 클라이언트 개발 지원
작성 시점
- API 설계 단계
- API 문서화 단계
- 클라이언트 개발 가이드 작성
- 통합 테스트 계획 단계
포함 위치
- API 문서의 “API 개요” 섹션
- “사용 예제” 섹션
- “에러 처리” 섹션
- “통합 가이드” 섹션
4. 테스트 계획서 (Test Plan)
포함 내용
-
테스트 프로세스 플로우차트
- 테스트 실행 절차
- 테스트 환경 설정
- 결과 보고 프로세스
- 에스컬레이션 프로세스
-
테스트 케이스 플로우
- 각 테스트 케이스의 실행 흐름
- 조건 분기별 테스트
- 예외 상황 테스트
포함 이유
- 테스트 절차 표준화
- 테스트 케이스 시각화
- 테스트 커버리지 확인
- 테스트 자동화 설계
작성 시점
- 테스트 계획 수립 단계
- 테스트 케이스 작성 단계
- 테스트 자동화 설계 단계
- 테스트 프로세스 정의 단계
포함 위치
- 테스트 계획서의 “테스트 프로세스” 섹션
- “테스트 케이스” 섹션
- “테스트 자동화” 섹션
5. 운영 매뉴얼 (Operations Manual)
포함 내용
-
운영 프로세스 플로우차트
- 배포 프로세스
- 모니터링 절차
- 백업 프로세스
- 인시던트 대응 프로세스
-
트러블슈팅 플로우
- 장애 대응 절차
- 문제 해결 프로세스
- 에스컬레이션 프로세스
- 복구 프로세스
포함 이유
- 운영 절차 표준화
- 신규 운영자 교육
- 일관된 운영 보장
- 인수인계 자료
작성 시점
- 배포 전 단계
- 운영 매뉴얼 작성 단계
- 인수인계 단계
- 운영 프로세스 정의 단계
포함 위치
- 운영 매뉴얼의 “운영 프로세스” 섹션
- “배포 가이드” 섹션
- “트러블슈팅 가이드” 섹션
- “인시던트 대응” 섹션
6. 사용자 매뉴얼 (User Manual)
포함 내용
-
사용자 워크플로우 플로우차트
- 기능 사용 절차
- 단계별 가이드
- 오류 처리 방법
- 예외 상황 대응
-
비즈니스 프로세스 플로우
- 업무 프로세스 안내
- 승인 프로세스
- 보고서 생성 절차
- 데이터 입력 절차
포함 이유
- 사용자 교육 자료
- 오류 방지
- 일관된 사용법 안내
- 온라인 도움말
작성 시점
- 사용자 매뉴얼 작성 단계
- 사용자 교육 준비 단계
- 제품 출시 전
- 기능 업데이트 시
포함 위치
- 사용자 매뉴얼의 “시작하기” 섹션
- “기능 가이드” 섹션
- “문제 해결” 섹션
- “FAQ” 섹션
7. 시스템 분석 문서 (System Analysis Document)
포함 내용
-
시스템 프로세스 플로우차트
- 주요 시스템 프로세스
- 데이터 처리 파이프라인
- 통합 프로세스
- 배치 작업 프로세스
-
의사결정 프로세스
- 시스템 의사결정 로직
- 라우팅 로직
- 비즈니스 규칙 적용
- 자동화 규칙
포함 이유
- 시스템 이해도 향상
- 프로세스 개선 기회 발견
- 문서화 및 지식 공유
- 레거시 시스템 분석
작성 시점
- 시스템 분석 단계
- 레거시 시스템 분석
- 시스템 개선 계획 수립
- 문서화 단계
포함 위치
- 시스템 분석 문서의 “시스템 프로세스” 섹션
- “데이터 흐름” 섹션
- “의사결정 로직” 섹션
8. 품질 관리 문서 (Quality Assurance Document)
포함 내용
-
품질 검사 프로세스 플로우차트
- 코드 리뷰 프로세스
- 테스트 프로세스
- 릴리스 프로세스
- 배포 프로세스
-
품질 기준 적용 플로우
- 품질 기준 검증 절차
- 승인 프로세스
- 에스컬레이션 프로세스
포함 이유
- 품질 표준 유지
- 일관된 품질 관리
- 감사 대응
- 프로세스 표준화
작성 시점
- 품질 관리 체계 구축 단계
- 프로세스 표준화 단계
- 인증 준비 단계
- 품질 프로세스 개선 단계
포함 위치
- 품질 관리 문서의 “품질 프로세스” 섹션
- “코드 리뷰 프로세스” 섹션
- “릴리스 프로세스” 섹션
ER 다이어그램
개념
정의
ER 다이어그램(Entity-Relationship Diagram, 개체-관계 다이어그램)은 데이터베이스의 엔티티(개체), 속성, 그리고 엔티티 간의 관계를 시각적으로 표현하는 다이어그램입니다. 관계형 데이터베이스 설계의 핵심 도구로, 데이터 모델을 시각화하여 데이터베이스 스키마를 설계하는 데 사용됩니다.
핵심 특징
- 엔티티 중심: 데이터베이스의 주요 개체(엔티티)를 중심으로 표현
- 관계 명시: 엔티티 간의 관계를 명확히 표현
- 속성 표현: 각 엔티티의 속성(컬럼)을 표현
- 카디널리티: 관계의 다중성을 표현 (1:1, 1:N, N:M)
- 정규화 지원: 데이터 정규화 설계에 유용
역사
- 1976년: Peter Chen이 ER 모델 제안
- 1980년대: 관계형 데이터베이스와 함께 널리 사용
- 현재: 데이터베이스 설계의 표준 도구
기본 원칙
- 엔티티 식별: 시스템에서 관리해야 할 주요 개체 식별
- 관계 정의: 엔티티 간의 관계 명확히 정의
- 속성 정의: 각 엔티티의 속성 정의
- 정규화: 데이터 중복 최소화
ER 다이어그램 구성 요소
1. 엔티티 (Entity)
- 정의: 데이터베이스에서 관리하는 실세계의 객체나 개념
- 표기: 사각형
- 종류:
- 강한 엔티티(Strong Entity): 독립적으로 존재 가능
- 약한 엔티티(Weak Entity): 다른 엔티티에 의존적 (이중 사각형)
- 예시: 사용자, 주문, 상품, 게시글
2. 속성 (Attribute)
- 정의: 엔티티의 특성이나 특징
- 표기: 타원형
- 종류:
- 기본키(Primary Key): 밑줄, 고유 식별자
- 외래키(Foreign Key): 점선 밑줄, 다른 엔티티 참조
- 복합 속성: 여러 속성의 조합
- 다중값 속성: 이중 타원
- 유도 속성: 점선 타원
- 예시: 사용자ID(기본키), 이름, 이메일, 주문ID(외래키)
3. 관계 (Relationship)
- 정의: 엔티티 간의 연관성
- 표기: 마름모
- 카디널리티:
- 1:1 (일대일): 한 엔티티의 인스턴스가 다른 엔티티의 인스턴스 하나와만 관계
- 1:N (일대다): 한 엔티티의 인스턴스가 여러 인스턴스와 관계
- N:M (다대다): 양쪽 모두 여러 인스턴스와 관계
- 예시: 사용자-주문 (1:N), 학생-과목 (N:M)
4. 관계 속성 (Relationship Attribute)
- 정의: 관계 자체에 속하는 속성
- 표기: 관계 마름모에 연결된 타원
- 예시: 주문-상품 관계의 수량, 가격
사용하는 곳
1. 데이터베이스 설계
관계형 데이터베이스 설계
- 용도: RDBMS 스키마 설계
- 예시:
- MySQL, PostgreSQL, Oracle 등
- 테이블 구조 설계
- 외래키 관계 정의
- 장점: 데이터 구조를 시각적으로 설계
데이터 모델링
- 용도: 비즈니스 도메인의 데이터 구조 모델링
- 예시:
- 도메인 모델 설계
- 개념적 데이터 모델
- 논리적 데이터 모델
- 장점: 비즈니스 요구사항을 데이터 구조로 변환
2. 데이터베이스 리팩토링
스키마 개선
- 용도: 기존 데이터베이스 구조 개선
- 예시:
- 정규화 개선
- 성능 최적화
- 중복 제거
- 장점: 개선 계획 시각화
마이그레이션 계획
- 용도: 데이터베이스 이전 계획
- 예시:
- 레거시 시스템 마이그레이션
- 데이터베이스 버전 업그레이드
- 클라우드 마이그레이션
- 장점: 마이그레이션 영향 분석
3. 데이터베이스 문서화
기존 데이터베이스 문서화
- 용도: 기존 데이터베이스 구조 문서화
- 예시:
- 레거시 시스템 문서화
- 데이터베이스 구조 정리
- 온보딩 자료
- 장점: 데이터베이스 구조 이해도 향상
API 문서화
- 용도: 데이터 구조 설명 (특히 GraphQL)
- 예시:
- GraphQL 스키마 문서화
- REST API 데이터 모델
- 데이터 구조 설명
- 장점: API 사용자에게 데이터 구조 명확히 전달
4. 요구사항 분석
데이터 요구사항 분석
- 용도: 시스템이 관리해야 할 데이터 식별
- 예시:
- 비즈니스 요구사항에서 데이터 추출
- 데이터 범위 정의
- 데이터 관계 정의
- 장점: 데이터 요구사항 명확화
어디에 사용하면 유리한지
1. 관계형 데이터베이스 프로젝트
RDBMS 사용
- 상황: 관계형 데이터베이스를 사용하는 모든 프로젝트
- 예시:
- MySQL, PostgreSQL, Oracle, SQL Server
- 관계형 데이터베이스 기반 애플리케이션
- 유리한 점:
- 데이터베이스 설계 가이드
- 외래키 관계 명확화
- 정규화 설계 지원
복잡한 데이터 구조
- 상황: 많은 테이블과 복잡한 관계
- 예시:
- 엔터프라이즈 애플리케이션
- ERP 시스템
- 복잡한 비즈니스 로직
- 유리한 점:
- 전체 데이터 구조 파악
- 관계 명확화
- 복잡도 관리
2. 정규화가 중요한 경우
데이터 무결성
- 상황: 데이터 정규화와 무결성이 중요한 경우
- 예시:
- 금융 시스템
- 의료 시스템
- 정부 시스템
- 유리한 점:
- 정규화 설계 지원
- 데이터 중복 최소화
- 무결성 제약 조건 설계
3. 팀 협업
데이터베이스 설계 공유
- 상황: 데이터베이스 설계를 팀과 공유
- 예시:
- 개발팀 간 협업
- 백엔드-프론트엔드 협업
- 데이터 분석가와 협업
- 유리한 점:
- 시각적 소통
- 일관된 이해
- 피드백 수집
4. 데이터베이스 리팩토링
기존 구조 개선
- 상황: 기존 데이터베이스 구조 개선
- 예시:
- 레거시 시스템 개선
- 성능 최적화
- 정규화 개선
- 유리한 점:
- 현재 구조 파악
- 개선 계획 수립
- 영향 분석
어떤 경우에는 과한 경우인지
1. NoSQL 데이터베이스
문서형 데이터베이스
- 상황: MongoDB, CouchDB 등 문서형 데이터베이스
- 예시:
- 문서 기반 저장소
- 스키마 없는 데이터베이스
- 과한 이유:
- 관계 개념이 약함
- ER 다이어그램의 장점 활용 어려움
- 다른 다이어그램이 더 적합
키-값 저장소
- 상황: Redis, DynamoDB 등 키-값 저장소
- 예시:
- 캐시 시스템
- 세션 저장소
- 과한 이유:
- 단순한 구조
- 관계 개념 없음
- ER 다이어그램 불필요
2. 단순한 데이터 구조
테이블이 적은 경우
- 상황: 테이블이 1~2개인 경우
- 예시:
- 간단한 웹 애플리케이션
- 프로토타입
- 과한 이유:
- 구조가 단순하여 문서화 불필요
- 코드로 충분히 이해 가능
3. 프로토타입 단계
빠른 변경
- 상황: 빠르게 변경되는 초기 단계
- 예시:
- MVP 개발
- 개념 검증
- 과한 이유:
- 구조가 자주 변경됨
- 문서 업데이트 비용 높음
4. 단순한 파일 저장
파일 기반 저장소
- 상황: 파일로 데이터 저장
- 예시:
- CSV 파일
- JSON 파일
- 로그 파일
- 과한 이유:
- 데이터베이스 개념 없음
- ER 다이어그램 불필요
개발 문서에 포함될 경우
1. 데이터베이스 설계서 (Database Design Document)
포함 내용
-
ER 다이어그램
- 전체 데이터베이스 구조
- 엔티티와 관계
- 속성 정의
- 카디널리티
-
스키마 상세
- 테이블 정의
- 컬럼 정의
- 제약 조건
- 인덱스 설계
포함 이유
- 데이터베이스 구조 시각화
- 설계 가이드 제공
- 개발자와 협업
- 문서화
작성 시점
- 데이터베이스 설계 단계
- 스키마 설계 단계
- 데이터 모델링 단계
포함 위치
- 데이터베이스 설계서의 “데이터 모델” 섹션
- “ER 다이어그램” 섹션
- “스키마 설계” 섹션
2. 시스템 설계서 (System Design Document)
포함 내용
-
데이터 모델 ER 다이어그램
- 도메인 모델
- 데이터 구조
- 엔티티 관계
-
데이터 흐름
- 데이터 생성/수정/삭제 흐름
- 데이터 조회 패턴
포함 이유
- 시스템의 데이터 구조 이해
- 데이터 설계 문서화
- 개발 가이드
작성 시점
- 시스템 설계 단계
- 데이터 모델링 단계
포함 위치
- 시스템 설계서의 “데이터 모델” 섹션
- “데이터 구조” 섹션
3. API 문서 (API Documentation)
포함 내용
-
데이터 모델 ER 다이어그램
- API에서 사용하는 데이터 구조
- 엔티티 관계
- 데이터 타입
-
특히 GraphQL API
- GraphQL 스키마와 ER 다이어그램 매핑
- 타입 관계 설명
포함 이유
- API 사용자에게 데이터 구조 명확히 전달
- 데이터 모델 이해
- 클라이언트 개발 지원
작성 시점
- API 설계 단계
- API 문서화 단계
포함 위치
- API 문서의 “데이터 모델” 섹션
- “스키마” 섹션 (GraphQL)
4. 데이터베이스 문서 (Database Documentation)
포함 내용
-
기존 데이터베이스 ER 다이어그램
- 현재 데이터베이스 구조
- 테이블 관계
- 외래키 관계
-
데이터베이스 구조 설명
- 각 테이블의 용도
- 관계 설명
- 제약 조건
포함 이유
- 기존 데이터베이스 구조 문서화
- 신규 개발자 온보딩
- 데이터베이스 이해도 향상
작성 시점
- 데이터베이스 문서화 단계
- 레거시 시스템 분석 단계
포함 위치
- 데이터베이스 문서의 “데이터베이스 구조” 섹션
- “ER 다이어그램” 섹션
5. 마이그레이션 계획서 (Migration Plan)
포함 내용
-
현재/목표 ER 다이어그램
- 현재 데이터베이스 구조
- 목표 데이터베이스 구조
- 변경 사항
-
마이그레이션 전략
- 데이터 변환 계획
- 관계 유지 계획
포함 이유
- 마이그레이션 계획 수립
- 영향 분석
- 데이터 변환 가이드
작성 시점
- 마이그레이션 계획 수립 단계
- 데이터베이스 이전 계획 단계
포함 위치
- 마이그레이션 계획서의 “데이터베이스 구조” 섹션
- “마이그레이션 전략” 섹션
플로우차트 및 ER 다이어그램 도구
플로우차트 도구
- 온라인: Draw.io, Lucidchart, Creately
- 데스크톱: Visio, OmniGraffle, yEd
- 텍스트 기반: Mermaid, PlantUML, Graphviz
ER 다이어그램 도구
- 온라인: dbdiagram.io, ERD Cloud, Draw.io
- 데스크톱: MySQL Workbench, DBeaver, ER/Studio
- 텍스트 기반: dbml, PlantUML
모범 사례
플로우차트
- 명확한 시작과 종료
- 일관된 방향 (위→아래 또는 왼쪽→오른쪽)
- 적절한 상세도
- 표준 심볼 사용
- 명확한 라벨
ER 다이어그램
- 명확한 엔티티 식별
- 관계 명확화
- 카디널리티 정확히 표현
- 정규화 고려
- 일관된 네이밍
결론
플로우차트와 ER 다이어그램은 각각 프로세스와 데이터 구조를 시각화하는 강력한 도구입니다. 플로우차트는 복잡한 로직과 프로세스를, ER 다이어그램은 데이터베이스 구조를 명확히 표현하여 개발 효율성과 품질을 향상시킵니다. 적절한 상황에서 사용하면 큰 도움이 되지만, 간단한 프로젝트나 다른 도구를 사용하는 경우에는 오히려 부담이 될 수 있습니다.