CRUD

CRUD란 무엇인가

CRUD는 데이터에 가해지는 네 가지 기본 조작인 생성(Create)·조회(Read)·수정(Update)·삭제(Delete)의 머리글자를 묶은 용어다. 어떤 정보 시스템이든 데이터를 다루는 한, 그 행위는 결국 이 네 동작의 조합으로 환원된다.

화면이 아무리 복잡하고 비즈니스 규칙이 정교하더라도, 데이터 관점에서 보면 무언가를 만들고, 읽고, 바꾸고, 지우는 일의 반복이다. 그래서 CRUD는 기능을 정의하고 권한을 설계할 때 가장 기본이 되는 사고의 축으로 쓰인다.

기능 정의의 기준선

분석·설계 단계에서 요구사항을 정리할 때 CRUD는 누락을 잡아내는 체크리스트 역할을 한다. 하나의 데이터 객체에 대해 생성 화면만 있고 수정·삭제 경로가 빠지거나, 조회는 되는데 등록 흐름이 정의되지 않은 사례는 흔하다.

핵심 엔터티마다 네 동작이 각각 어떤 기능과 화면으로 구현되는지를 표로 정리하면, 설계 단계에서 비어 있는 부분이 곧바로 드러난다. 데이터 모델링으로 도출한 엔터티 목록과 이 표를 교차로 점검하면 기능 명세의 완결성을 높일 수 있다.

권한 설계의 출발점

CRUD는 접근 통제를 설계할 때도 기본 단위가 된다. 같은 데이터라도 사용자 역할에 따라 어떤 동작까지 허용할지가 달라지기 때문이다.

일반 사용자는 조회만 가능하고, 담당자는 생성·수정까지, 관리자만 삭제 권한을 갖는 식의 분리는 모든 시스템 설계에서 반복된다. 역할과 데이터 객체를 두 축으로 두고 각 교차점에 어떤 동작을 허용할지 명시하는 권한 행렬은 CRUD를 토대로 만들어진다.

이 행렬이 없으면 권한 누수나 과도한 권한 부여가 운영 단계에서야 드러난다.

단순한 듯 무거운 동작들

네 동작이 형식적으로 대등해 보이지만 실제 무게는 같지 않다. 조회는 성능과 검색 조건 설계의 부담이 크고, 수정과 삭제는 데이터 무결성과 이력 관리라는 까다로운 문제를 동반한다.

특히 삭제는 물리적으로 행을 지울지, 삭제 표시만 남기는 논리적 삭제로 처리할지에 따라 후속 영향이 크게 갈린다. 회계·거래 데이터처럼 추적 가능성이 중요한 영역에서는 실제 삭제 대신 상태 변경으로 다루는 편이 안전하다.

이런 판단을 설계 단계에서 명확히 해 두지 않으면 운영 중 데이터 복구나 감사 요건에서 곤란을 겪는다.

UseCase·화면 설계와의 연결

CRUD는 UseCase 모델 및 화면 설계와 자연스럽게 맞물린다. 하나의 유스케이스는 대개 특정 데이터에 대한 한두 가지 CRUD 동작을 중심으로 구성되며, 그 흐름이 곧 화면 전환 시나리오가 된다.

목록 화면은 조회, 등록 화면은 생성, 상세 화면은 조회와 수정, 그리고 삭제 버튼이 한 묶음으로 묶이는 전형적 패턴이 여기서 나온다. 설계자가 엔터티별 CRUD 매핑을 먼저 정리해 두면 화면 산출물과 기능 명세가 서로 어긋나지 않게 정렬된다.

결과적으로 데이터 구조·기능·화면이 하나의 일관된 골격 위에서 설계된다.

설계 검증의 작은 척도

CRUD는 거창한 방법론이 아니라 설계의 완결성을 점검하는 실무 척도에 가깝다. 모든 핵심 데이터에 대해 네 동작의 처리 방식과 권한, 예외 상황이 정의되어 있는지를 확인하는 것만으로도 설계 품질이 눈에 띄게 올라간다.

반대로 이 점검을 건너뛰면 조회만 화려하고 데이터 정합성은 취약한 시스템이 되기 쉽다. 분석가는 요구사항을 받을 때 항상 이 데이터가 어떻게 생기고 사라지는지를 끝까지 따라가야 한다.

그 추적의 습관이 설계의 빈틈을 메운다.