CRUD-Matrix로 데이터와 업무 기능의 관계 검증하기
CRUD-Matrix의 구성 방식과 검증 항목을 정리하고, 데이터 모델과 업무 프로세스의 관계를 설계에 활용하는 방법을 다룬다.
2026-08-14 · 최초 발행 2025-08-10
데이터 모델과 프로세스를 같은 화면에서 검증하는 방법
CRUD-Matrix는 시스템 개발에서 업무 프로세스와 데이터베이스 사이의 의존 관계를 드러내는 분석 도구다. 데이터베이스 설계와 애플리케이션 기능이 어떻게 맞물리는지 한눈에 볼 수 있어, 시스템 설계의 완전성과 일관성을 확인하는 데 쓴다.
세로축에는 논리 데이터 모델링으로 도출한 Entity Type을 두고, 가로축에는 시스템이 제공하는 업무를 최하위 수준까지 분해한 기능을 둔다. 각 교차 지점에는 데이터 생성(Create), 조회(Read), 수정(Update), 삭제(Delete) 관계를 C, R, U, D로 기록한다.
매트릭스에 들어갈 재료와 기호
작성에 필요한 입력은 Entity Type과 업무기능분해도다. Entity Type은 논리적 데이터 모델링의 결과이고, 업무기능분해도는 시스템이 제공하는 업무를 최하위 수준까지 나눈 기능 목록이다.
셀의 표기는 다음 의미를 가진다.
- C(Create): 업무 기능이 엔티티 데이터를 생성한다.
- R(Read): 업무 목적을 수행하기 위해 엔티티 데이터를 참조한다.
- U(Update): 업무 기능이 엔티티 데이터를 수정한다.
- D(Delete): 업무 기능이 엔티티 데이터를 삭제한다.
고객 관리 시스템에 적용한 형태
고객 관리 시스템에서는 고객, 주문, 상품, 결제 같은 엔티티와 고객 등록·조회·수정·삭제, 주문 생성·조회·취소 같은 기능의 관계를 다음처럼 표시할 수 있다.
| Entity Type\업무기능 | 고객 등록 | 고객 조회 | 고객 정보 수정 | 고객 삭제 | 주문 생성 | 주문 조회 | 주문 취소 |
|---|---|---|---|---|---|---|---|
| 고객 | C | R | U | D | R | R | |
| 주문 | C | R | UD | ||||
| 상품 | R | ||||||
| 결제 | C | R | D |
이 표는 모델링 결과를 확인하는 용도에 그치지 않는다. 데이터와 프로세스 사이에서 빠진 관계를 찾고, 업무 전체의 인터페이스와 데이터 흐름, 처리 과정을 파악하는 기준이 된다. 또한 업무 기능별 데이터 접근 권한을 설계할 때도 기초 자료로 쓸 수 있다.
업무 시스템에서 관계를 읽는 방식
은행 계정 관리 시스템에서는 계좌 생성, 조회, 이체, 해지 기능을 고객·계좌·거래내역 엔티티와 연결한다. 예를 들어 이체 기능은 계좌 엔티티를 R(조회)하고 거래내역 엔티티를 C(생성)한다.
전자상거래 플랫폼도 상품등록, 주문처리, 결제, 배송관리 기능을 상품·주문·고객·결제·배송 엔티티에 매핑할 수 있다. 주문처리 기능은 상품 엔티티를 R(조회)하고 주문 엔티티를 C(생성)한다.
| Entity Type\업무기능 | 상품등록 | 상품조회 | 장바구니추가 | 주문생성 | 결제처리 | 배송관리 | 주문취소 |
|---|---|---|---|---|---|---|---|
| 상품 | CU | R | R | R | R | ||
| 고객 | R | R | R | R | R | R | |
| 장바구니 | CUD | R | D | ||||
| 주문 | C | R | R | UD | |||
| 결제 | CU | D | |||||
| 배송 | CUD |
인사관리 시스템에서는 직원등록, 평가관리, 급여처리, 휴가관리와 직원·부서·평가·급여·휴가 엔티티의 관계를 정의한다. 이 과정에서 여러 기능이 같은 엔티티를 생성하는지 확인하면 데이터 무결성에 영향을 줄 수 있는 중복 Create 작업을 식별할 수 있다.
매트릭스에서 확인할 불일치
완전성은 모든 Entity Type에 CRUD가 한 번 이상 기록됐는지부터 확인한다. 데이터 생성(C) 없이 사용되는 엔티티가 없는지, 모든 Entity에 Read 작업이 한 번 이상 있는지도 함께 본다.
일관성 점검에서는 모든 프로세스에 하나 이상의 Entity가 표시됐는지 확인한다. 데이터를 전혀 사용하지 않는 프로세스가 있다면 업무기능분해도나 데이터 모델 어느 한쪽의 누락을 의심할 수 있다.
중복성은 둘 이상의 프로세스가 하나의 Entity에 2개 이상의 Create 작업을 수행하는 경우를 살핀다. 중복 생성이 발견되면 업무 로직상 타당한 관계인지 검토해야 한다.
정합성 측면에서는 Delete 이전에 해당 데이터를 Read하는지, Update와 관련된 참조 무결성 제약조건을 고려했는지를 확인한다.
작성 범위와 변경 관리
프로세스를 지나치게 세분화하면 매트릭스가 복잡해지고, 반대로 너무 추상화하면 분석 가치가 낮아진다. 업무 도메인과 시스템 규모에 맞는 분해 수준을 정해야 한다.
관계는 C, R, U, D 외에도 필요하면 CR, UR처럼 조건부로 표현할 수 있다. 복잡한 관계는 주석이나 별도 문서에 상세 설명을 남긴다. 요구사항이 바뀌면 매트릭스 역시 변경 관리 프로세스와 연계해 계속 갱신해야 한다.
CRUD를 넓혀 표현하는 방식
기본 CRUD만으로 업무 특성을 충분히 나타내기 어려운 경우에는 확장 표기를 사용한다.
- CRUD+는 E(Execute)를 프로세스 실행, L(Link)를 데이터 연결, P(Print)를 출력 기능으로 표현한다.
- CRUDS는 S(Search)를 검색 기능에 특화해 표시한다.
- BREAD는 B(Browse)를 목록 조회, R(Read)를 상세 조회, E(Edit)를 편집, A(Add)를 추가, D(Delete)를 삭제로 구분한다.
핵심 뱅킹 개발에서의 활용
대형 금융기관의 핵심 뱅킹 시스템 개발에서는 분석 단계에서 200개 이상의 엔티티와 300개 이상의 업무 기능 사이의 관계를 매핑했다. 이 과정에서 누락된 업무 기능 15개와 불필요한 엔티티 7개를 발견해 수정했다.
설계 단계에서는 데이터 접근 권한 설계의 기초 자료로 활용하고, 트랜잭션 경계 설정과 서비스 계층 구조화에도 참조한다. 구현 단계에서는 모듈별 개발 우선순위를 정하고 테스트 케이스를 도출하는 기준이 된다. 운영 단계에서는 변경 영향도 분석과 성능 최적화 대상 선정 시 참고 자료로 사용할 수 있다.
CRUD-Matrix는 데이터 중심 시스템에서 프로세스와 데이터의 관계를 명확하게 만들고 검증하는 분석 기법이다. 대규모 엔터프라이즈 시스템에서는 특히 데이터 모델과 업무 기능의 누락·중복을 통제하고, 프로젝트 전 단계에서 일관된 설계 기준을 유지하는 데 쓰인다.