CRUD 매트릭스(CRUD Matrix)
1. 개요
가. 정의
정보시스템의 프로세스(기능) 와 엔터티(데이터) 사이의 생성(Create)·조회(Read)·수정(Update)·삭제(Delete) 관계를 행렬로 교차 표현하여, 데이터 모델과 프로세스 모델의 정합성을 점검하는 상관 분석(Correlation Analysis) 도구이다.
CRUD 매트릭스는 단순한 표 하나가 아니라, 서로 다른 두 설계 시각을 강제로 한 평면 위에 겹쳐 보게 만드는 검증 장치다. 데이터 관점(무엇을 저장할 것인가)과 기능 관점(무엇을 처리할 것인가)은 개발 초기에는 각각 자연스러워 보여도, 막상 맞물려 돌아갈 때 비로소 어긋남이 드러난다. CRUD 매트릭스는 이 어긋남을 코드가 작성되기 전, 분석·설계 단계에서 미리 노출시킨다는 점에서 값이 크다.
나. 등장 배경 및 필요성
정보공학(IE, Information Engineering) 방법론에서 데이터 모델(ERD)과 프로세스 모델(DFD·기능 분해도)은 서로 다른 산출물로, 종종 다른 담당자가 독립적으로 작성한다. 문제는 두 산출물이 논리적으로는 반드시 맞물려야 한다는 데 있다. 어떤 엔터티에 값을 넣어 주는 프로세스가 하나도 없다면 그 데이터는 영원히 빈 채로 남고(생성 누락), 반대로 어떤 프로세스가 존재하지 않는 데이터를 참조하도록 설계됐다면 실행 자체가 불가능하다(참조 무결성 붕괴).
이러한 데이터-기능 간 정합성의 구멍은 문서를 아무리 정독해도 사람 눈으로는 놓치기 쉽다. 엔터티가 수십 개, 프로세스가 수백 개로 늘어나면 조합의 수가 폭발하기 때문이다. CRUD 매트릭스는 이 관계를 행렬이라는 한눈에 보이는 격자 형태로 강제 정렬함으로써, 누락(빈 셀)·중복(과다 표기)·고립(전부 빈 행/열)을 시각적으로 드러낸다. 나아가 한 번 작성된 매트릭스는 검증에서 끝나지 않고 트랜잭션 경계 설정, DB 분산 설계, 접근권한(RBAC) 설계, 아카이빙·보존정책의 공통 입력 자료로 재활용된다는 점에서 분석 산출물 중에서도 재사용성이 높다.
다. 특징
CRUD 매트릭스의 특징은 세 가지로 요약된다. 첫째, 대칭적 검증이다. 데이터 쪽(엔터티가 생애주기를 온전히 갖는가)과 기능 쪽(프로세스가 실제 데이터를 다루는가)을 동시에 점검한다. 둘째, 정적 산출물이지만 동적 함의를 가진다. 표 자체는 정적이지만, 여러 프로세스가 같은 엔터티에 U를 수행한다는 사실은 곧 동시성·락 설계라는 런타임 이슈로 이어진다. 셋째, 방법론 중립적이다. 정보공학에서 출발했지만 객체지향·마이크로서비스 설계에서도 접근 패턴 분석 도구로 그대로 응용된다.
2. CRUD 매트릭스의 전체 구조와 위치
CRUD 매트릭스가 어디에서 입력을 받아 어디로 출력을 내보내는지를 먼저 이해하면, 왜 이 도구가 분석 단계의 "허브"로 불리는지가 분명해진다. 아래 구조도는 데이터 모델과 프로세스 모델이 CRUD 매트릭스로 수렴한 뒤, 다시 여러 설계 활동으로 발산하는 흐름을 나타낸다.
flowchart LR
ERD["데이터 모델(ERD·엔터티)"] --> CM["CRUD 매트릭스"]
DFD["프로세스 모델(DFD·기능)"] --> CM
CM --> V["정합성 검증(누락·고립·허수)"]
CM --> TX["트랜잭션 경계 설계"]
CM --> DIST["DB 분산·분할 설계"]
CM --> AUTH["접근권한(RBAC) 설계"]
CM --> ARC["아카이빙·보존정책"]
구조도에서 보듯 CRUD 매트릭스의 입력은 두 개의 서로 다른 모델이고, 출력은 다섯 갈래의 후속 설계 활동이다. 이때 핵심은 두 입력이 "독립적으로 만들어졌다"는 사실이다. 만약 하나의 통합 모델에서 자동 생성됐다면 정합성 검증의 의미가 없다. 서로 다른 시각에서 독립적으로 만든 두 모델을 사후에 겹쳐 보기 때문에, 비로소 사람이 미처 의식하지 못한 불일치가 표면화되는 것이다.
행렬의 좌표계도 명확한 규칙을 따른다. 관례적으로 행에는 프로세스(기능), 열에는 엔터티(데이터)를 배치한다. 이렇게 하면 한 행을 가로로 읽었을 때 "이 프로세스가 어떤 데이터들을 어떻게 다루는가"라는 트랜잭션의 데이터 접근 범위가 드러나고, 한 열을 세로로 읽었을 때 "이 데이터가 누구에 의해 어떻게 다뤄지는가"라는 데이터의 생애주기가 드러난다. 가로 읽기는 기능 설계에, 세로 읽기는 데이터 거버넌스에 각각 대응된다.
3. 표현 방법과 작성 절차
각 교차 셀에는 그 프로세스가 해당 엔터티에 수행하는 연산을 C/R/U/D로 표기하며, 하나의 프로세스가 여러 연산을 하면 함께 적는다. 예를 들어 "주문취소"는 주문을 수정하고 최종적으로 삭제하므로 UD로 표기한다. 아래 쇼핑몰 예시에서 "주문등록" 행을 가로로 읽으면, 이 기능이 회원·상품을 조회(R)하고 주문을 생성(C)하는 복합 트랜잭션임이 한 줄에 그대로 드러난다.
| 프로세스 \ 엔터티 | 회원 | 주문 | 상품 |
|---|---|---|---|
| 회원가입 | C | ||
| 상품조회 | R | ||
| 주문등록 | R | C | R |
| 주문취소 | UD |
작성은 무작정 셀을 채우는 것이 아니라 정해진 절차를 따른다. 아래 절차도는 엔터티·프로세스 도출부터 검증·재활용까지의 흐름을 나타낸다.
flowchart TD
A["엔터티 목록 도출(ERD 기반)"] --> B["프로세스 목록 도출(기능분해 기반)"]
B --> C["행렬 틀 구성(행=프로세스, 열=엔터티)"]
C --> D["각 셀에 C/R/U/D 표기"]
D --> E["행·열 정합성 검증"]
E --> F{"누락·고립·허수 존재?"}
F -->|"예"| G["모델 보완 후 재작성"]
G --> D
F -->|"아니오"| H["후속 설계에 재활용"]
첫째 단계인 엔터티·프로세스 도출은 매트릭스 품질의 8할을 좌우한다. 엔터티 목록은 정규화된 ERD에서, 프로세스 목록은 기능 분해도의 최하위(원자) 프로세스에서 가져오는 것이 원칙이다. 이때 엔터티 정의 수준(개념/논리/물리)과 프로세스 정의 수준(대기능/단위업무)의 입도(granularity)를 일치시키지 않으면, 매트릭스가 지나치게 성기거나 반대로 과밀해져 검증이 무의미해진다. 실무에서는 논리 엔터티와 단위 프로세스(하나의 화면·API에 대응) 수준으로 맞추는 경우가 많다.
둘째, 셀 표기 단계에서는 "무엇을 R로 볼 것인가"에 대한 팀 내 합의가 필요하다. 예컨대 외래키 검증을 위한 존재 확인 조회를 R로 표기할지, 화면 표시용 조회만 R로 볼지에 따라 매트릭스의 밀도가 달라진다. 이 규칙이 불명확하면 같은 시스템을 두 사람이 그려도 서로 다른 매트릭스가 나온다.
셋째, 검증과 반복이다. 검증에서 결함이 발견되면 매트릭스만 고치는 것이 아니라 원본 모델(ERD·DFD)로 되돌아가 보완하는 것이 핵심이다. 매트릭스는 결함의 징후를 보여줄 뿐, 진짜 문제는 데이터 모델이나 프로세스 모델에 있기 때문이다. 이 되먹임 고리가 CRUD 매트릭스를 단순 문서가 아닌 검증 프로세스로 만든다.
4. 정합성 검증 규칙
검증의 핵심은 "모든 엔터티가 생애주기 전체를 갖는가"와 "모든 프로세스가 실제 데이터를 다루는가"를 대칭적으로 확인하는 것이다. 각 규칙에는 위반 시 의심해야 할 구체적 결함이 대응된다.
각 엔터티 열에는 C가 최소 하나 있어야 한다. 생성 프로세스가 없는 엔터티는 데이터가 유입될 경로가 없으므로, 배치 적재·외부 연계 같은 별도 유입 경로가 명시되지 않았다면 명백한 설계 누락이다. 앞의 예시에서 상품 열에 C가 없다는 사실은 곧 "상품등록" 프로세스가 누락됐음을 알려 준다.
각 엔터티 열에는 R이 최소 하나 있어야 한다. 아무도 조회하지 않는 데이터는 저장할 이유가 없는 불필요 데이터일 가능성이 높다. 다만 로그·감사 데이터처럼 "지금은 안 읽어도 나중을 위해 쌓는" 경우가 있으므로, R이 없다고 곧바로 삭제 결정을 내리기보다 보존 목적을 재확인하는 검토 신호로 삼는다.
U/D의 유무는 관리 프로세스의 필요성을 점검한다. U가 전혀 없는 엔터티는 불변(immutable) 데이터일 수 있고, D가 없는 엔터티는 물리 삭제 없이 상태 플래그로만 관리(논리 삭제)되는 정책일 수 있다. 즉 U/D의 부재는 곧 결함이 아니라 정책적 선택인지 누락인지를 구분하게 만드는 질문이다.
모든 행·열은 최소 하나의 표기를 가져야 한다. 표기가 전혀 없는 열은 어떤 기능도 사용하지 않는 고립 엔터티, 표기가 전혀 없는 행은 데이터를 건드리지 않는 빈(허수) 프로세스로, 둘 다 오류 후보다. 고립 엔터티는 과설계이거나 프로세스 누락을, 허수 프로세스는 실제 동작하지 않는 껍데기 기능을 의심케 한다.
| 점검 규칙 | 의미 | 위반 시 의심 사항 |
|---|---|---|
| 각 엔터티에 C 존재 | 데이터 유입 경로 확보 | 생성 프로세스 누락 |
| 각 엔터티에 R 존재 | 데이터 활용 여부 확인 | 불필요 데이터 또는 보존목적 재검토 |
| U/D 존재 여부 | 상태변경·삭제 정책 확인 | 관리 프로세스 누락 vs 불변/논리삭제 정책 |
| 모든 행·열 최소 1개 | 고립·허수 방지 | 고립 엔터티·빈(허수) 프로세스 |
5. 활용 분야와 실제 사례
CRUD 매트릭스는 정합성 검증에 그치지 않고 후속 설계의 입력으로 넓게 쓰인다. 트랜잭션 분석에서는 하나의 행(프로세스)이 여러 엔터티에 걸쳐 C/U/D를 수행하면 그 범위가 하나의 논리적 작업 단위, 즉 트랜잭션 경계가 된다. 예컨대 "주문등록" 행이 주문 C와 재고 U를 함께 포함한다면, 이 둘은 원자적으로 커밋되어야 하므로 하나의 트랜잭션으로 묶어야 한다는 설계 근거가 표에서 바로 나온다.
동시성 제어 설계의 근거도 열에서 읽힌다. 특정 엔터티 열에 여러 프로세스의 U가 몰려 있으면, 그 데이터는 경합(contention)이 높은 핫스팟이므로 락 전략·낙관적 동시성 제어 여부를 결정해야 한다. 실무에서 재고·잔액처럼 U가 집중되는 엔터티가 대표적 사례로, 이 지점을 놓치면 운영 중 갱신 손실(lost update)이나 데드락이 발생한다.
DB 분산·분할 설계에서는 접근 패턴의 지역성이 핵심 단서다. 특정 엔터티군을 특정 프로세스군만 접근한다면, 그 경계를 따라 DB를 분할(샤딩·파티셔닝)했을 때 트래픽 지역성이 높아져 성능이 개선된다. 반대로 여러 프로세스가 여러 엔터티에 광범위하게 걸쳐 있으면 분할 시 분산 트랜잭션 비용이 커지므로 신중해야 한다. 접근권한 설계에서는 역할(Role)별로 어떤 엔터티에 어떤 CRUD 권한을 부여할지를 이 매트릭스에서 출발해 RBAC 권한 매트릭스로 확장한다. 예를 들어 "일반회원" 역할은 주문에 C/R만, "관리자" 역할은 U/D까지 갖도록 매핑하는 식이다.
| 분야 | 활용 방식 | 표에서 읽는 단서 |
|---|---|---|
| 업무·데이터 검증 | 요구사항-데이터 정합성 점검 | 빈 셀·고립 행·열 |
| 트랜잭션 분석 | 트랜잭션 경계·동시성 설계 | 한 행의 C/U/D 범위, 한 열의 U 집중 |
| DB 분산 설계 | 접근 패턴 기반 분할·배치 | 프로세스군-엔터티군 접근 지역성 |
| 접근권한 설계 | 역할별 CRUD 권한 매트릭스 기초 | 역할×엔터티×연산 매핑 |
6. 유사 기법과의 비교
CRUD 매트릭스는 다른 상관 분석 도구와 목적이 다르다. 이를 구분해야 시험 답안에서 혼동 없이 서술할 수 있다. 엔터티-기능 상관표(E-F Matrix)는 CRUD 구분 없이 단순 관계 유무만 표기해 도출 단계에서 쓰이는 반면, CRUD 매트릭스는 연산 종류까지 세분해 정합성·트랜잭션 설계에 쓰인다. DFD는 데이터의 흐름(어디로 이동하는가)에 초점을 두지만, CRUD 매트릭스는 데이터에 대한 연산(무엇을 하는가)에 초점을 둔다는 점에서 상호 보완적이다.
이 차이가 생기는 이유는 각 도구가 겨냥하는 설계 질문이 다르기 때문이다. E-F Matrix는 "관계가 있는가"라는 존재 여부를, DFD는 "어떻게 흐르는가"라는 이동 경로를, CRUD 매트릭스는 "생애주기가 완결되는가"라는 정합성을 묻는다. 따라서 실무에서는 세 도구를 배타적으로 고르는 것이 아니라, 분석 단계에 따라 순차적으로 함께 사용한다. 도출 초기에는 E-F Matrix로 큰 관계를 잡고, 상세화 단계에서 CRUD로 연산을 채워 검증하며, DFD로 흐름을 확인하는 식이다.
7. 심화 — MSA 시대의 CRUD 매트릭스와 예상 출제 방향
CRUD 매트릭스의 현대적 재해석은 마이크로서비스 아키텍처(MSA)에서 두드러진다. 모놀리식 시스템에서 CRUD 패턴 분석이 DB 분할의 근거였다면, MSA에서는 같은 분석이 서비스가 소유해야 할 데이터 경계, 즉 바운디드 컨텍스트(Bounded Context)를 정의하는 근거가 된다. "데이터를 소유한 서비스만 그 데이터를 변경(C/U/D)한다"는 데이터 소유권 원칙을 지키려면, 어떤 프로세스가 어떤 엔터티에 쓰기(C/U/D)를 수행하는지를 먼저 파악해야 한다. CRUD 매트릭스는 바로 그 쓰기 패턴의 지도이므로, 여러 서비스가 하나의 엔터티에 쓰기를 수행하는 셀이 발견되면 그것은 곧 서비스 경계가 잘못 그어졌다는 경고 신호다.
여기서 CQRS·이벤트 소싱과의 연계도 자연스럽게 도출된다. 읽기(R)가 여러 서비스·프로세스에 광범위하게 걸쳐 있고 쓰기(C/U/D)는 소수에 집중된다면, 읽기 모델과 쓰기 모델을 분리하는 CQRS가 유리하다. 즉 CRUD 매트릭스의 R과 C/U/D의 분포 자체가 CQRS 적용 여부의 판단 근거가 된다. 최근에는 데이터 거버넌스 관점에서 CRUD 매트릭스를 데이터 계보(Data Lineage)·개인정보 처리대장과 연결해, "어떤 개인정보 엔터티가 어떤 기능에 의해 수집(C)·이용(R)·정정(U)·파기(D)되는가"를 규명하는 컴플라이언스 근거 자료로 확장하는 흐름도 있다.
기술사 시험 관점에서 이 주제는 단독 약술뿐 아니라 데이터 모델링·트랜잭션·MSA 설계 문항의 부분 논거로 자주 활용된다. 답안 구성 시에는 (1) 정의와 표현 방법을 예시 매트릭스로 제시하고, (2) 정합성 검증 규칙 네 가지를 위반 사례와 함께 서술한 뒤, (3) 트랜잭션·분산·권한·MSA로 이어지는 활용을 단계적으로 확장하는 전개가 채점자에게 완결성을 준다. 특히 "표만 나열"하지 않고 각 규칙에 위반 시 의심 사항을 붙여 서술하면 변별력이 높다.
8. 고려사항 및 시사점
- 자동화·도구화의 필요: 엔터티·프로세스가 수백 개인 대규모 시스템에서는 수작업 관리가 불가능하다. CASE 도구·메타데이터 리포지토리 기반 자동 생성을 활용해 모델 변경과 매트릭스를 동기화하고, 모델이 바뀌면 매트릭스가 자동 갱신되도록 하는 것이 정합성 유지의 관건이다.
- 입도 일치와 표기 규칙 표준화: 엔터티와 프로세스의 정의 수준을 맞추고, "무엇을 R로 볼 것인가" 같은 표기 규칙을 팀 표준으로 명문화해야 재현성 있는 매트릭스가 나온다. 규칙 없이는 사람마다 다른 표가 만들어져 검증의 신뢰성이 무너진다.
- 데이터 거버넌스·컴플라이언스 기초 산출물: 데이터 소유권·품질·수명주기 관리의 출발점이며, 개인정보 처리대장·데이터 계보 관리와 연결해 GDPR·개인정보보호법 대응의 근거 자료로 활용할 수 있다.
- MSA·CQRS 설계로의 확장: CRUD 패턴 분석은 서비스의 바운디드 컨텍스트와 읽기·쓰기 분리(CQRS) 여부를 판단하는 근거가 된다. 다만 MSA에서는 하나의 물리 매트릭스가 아니라 서비스별로 소유 데이터를 나눠 관리해야 하므로, 전사 통합 매트릭스와 서비스별 매트릭스의 계층적 관리가 필요하다.
- 정적 검증의 한계 인식: CRUD 매트릭스는 설계 시점의 정적 정합성만 검증할 뿐, 실제 런타임의 부하·경합·성능은 보장하지 못한다. 따라서 U 집중 엔터티에 대한 부하 테스트, 트랜잭션 격리수준 검증 등 동적 검증과 반드시 병행해야 한다.
한 줄 요약: CRUD 매트릭스는 프로세스와 엔터티의 생성·조회·수정·삭제 관계를 행렬로 교차 표현 해 데이터-기능 정합성(누락·고립·허수)을 대칭적으로 검증하고, 트랜잭션·동시성·분산·접근권한 설계는 물론 MSA의 바운디드 컨텍스트와 CQRS 판단 근거까지 확장되는 상관 분석 도구다.