CRUD(생성, 읽기, 갱신, 삭제)란?

CRUD는 생성, 읽기, 갱신, 삭제의 약자로, 모든 영속 데이터 저장소가 지원해야 하는 네 가지 기본 연산입니다. James Martin의 1983년 저서 Managing the Data-base Environment에서 처음 쓰인 이 약어는 백엔드 분야에서 가장 오래 살아남은 용어입니다. 최소한의 바닥을 가리키기 때문입니다. 시스템이 그 밖에 무엇을 하든, 레코드는 생성되고, 조회되고, 변경되고, 삭제될 수 있어야 합니다.

핵심 요약

네 가지 언어로 보는 CRUD

-- SQL로 표현한 CRUD: 원래의 매핑
INSERT INTO tasks (title) VALUES ('Write the launch post');   -- C
SELECT * FROM tasks WHERE done = false;                       -- R
UPDATE tasks SET done = true WHERE id = 42;                   -- U
DELETE FROM tasks WHERE id = 42;                              -- D

같은 주기를 SDK로 표현하면 다음과 같습니다. 대부분의 애플리케이션 코드가 실제로 작성하는 형태입니다:

// JavaScript / Node.js — Back4app JS SDK
// The full CRUD cycle on one object
const task = new Parse.Object('Task');
task.set('title', 'Write the launch post');            // C — create
await task.save();

const fetched = await new Parse.Query('Task')
  .equalTo('done', false).first();                     // R — read

fetched.set('done', true);                             // U — update
await fetched.save();

await fetched.destroy();                               // D — delete

// Flutter / Dart — Back4app Flutter SDK
// The full CRUD cycle on one object
final task = ParseObject('Task')..set('title', 'Write the launch post');
await task.save();                                     // C — create

final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false);
final fetched = (await query.query()).results!.first;  // R — read

fetched.set('done', true);
await fetched.save();                                  // U — update

await fetched.delete();                                // D — delete

// iOS / Swift — Back4app Swift SDK
// The full CRUD cycle on one object
var task = Task()
task.title = "Write the launch post"
let saved = try await task.save()                      // C — create

let fetched = try await Task.query("done" == false)
  .first()                                             // R — read

var updated = fetched
updated.done = true
_ = try await updated.save()                           // U — update

try await updated.delete()                             // D — delete

// Android / Kotlin — Back4app Android SDK
// The full CRUD cycle on one object
val task = ParseObject("Task").apply {
  put("title", "Write the launch post")
}
task.save()                                            // C — create

val fetched = ParseQuery.getQuery<ParseObject>("Task")
  .whereEqualTo("done", false).first                   // R — read

fetched.put("done", true)
fetched.save()                                         // U — update

fetched.delete()                                       // D — delete

하나의 표로 보는 전체 매핑

어느 한 참고 자료에도 모여 있지 않은 여섯 열짜리 매핑입니다:

HTTP 명세에서 실제로 알아 둘 가치가 있는 각주가 두 가지 있습니다. GET은 안전하고(상태 변경 없음), PUT과 DELETE는 멱등하며(반복해도 해가 없음), POST는 둘 다 아닙니다. 재시도 로직이 이들을 다르게 취급하는 이유이자, PUT은 “전체 교체”를, PATCH는 “일부 수정”을 뜻하는 이유입니다.

CRUD가 일어나는 곳

이 다이어그램은 보안에 대한 경고이기도 합니다. 모든 동사는 API 계층을 거치며, 권한과 검증이 있어야 할 곳이 바로 그 계층입니다. 연산별 접근 제어가 없는 CRUD 표면은 몇 단계를 더 거칠 뿐인 공개 데이터베이스입니다.

CRUD vs. REST

실무적인 결론은 이렇습니다. REST API는 HTTP를 입은 CRUD API인 경우가 많습니다. 하지만 “인보이스 승인”은 API에 있어야 하면서도 CRUD 동사가 아니며, CRUD는 HTTP가 전혀 없는 곳에서도 문제없이 쓰입니다. 두 용어는 경쟁하지 않고 협력합니다.

일반적인 사용 사례

• 본래 의미의 CRUD 앱. 관리자 패널, CMS, CRM, 재고, 예약 시스템입니다. 비즈니스 소프트웨어의 대다수를 차지하며, 부끄러울 것이 없습니다.
• 프로토타이핑과 MVP. 몇 개의 클래스에 적용한 네 가지 동사가 곧 대부분 제품의 첫 버전입니다.
• 자동 생성 API. 스키마를 넣으면 CRUD 표면이 나옵니다. 네 가지 동사를 코드가 아닌 설정으로 만드는 현대의 기본값이며, 자동 생성 API 항목에서 자세히 다룹니다.
• 관리 및 지원 도구. 같은 CRUD 표면 위에 얹은 시각적 그리드로, 권한도 그대로 적용됩니다.
• 모든 것의 밑바탕. 이벤트 소싱 기반이나 워크플로 중심의 시스템도 설정, 프로필, 참조 데이터처럼 어딘가에서는 여전히 CRUD를 노출합니다.

모든 동작을 CRUD로 모델링해야 할까? 결정 매트릭스

마지막 행은 기억해 둘 만한 설계상의 경고 신호입니다. 엔드포인트 이름이 updateStatus 쪽으로 흘러가기 시작하면, 도메인이 자신만의 동사를 요구하고 있는 것입니다.

한계와 트레이드오프

• 갱신은 이력을 파괴합니다. 제자리 변경은 CRUD의 본질적인 동작이자 본질적인 손실입니다. “화요일에는 어떤 모습이었나”를 알아야 하는 모든 것에는 저널링이나 이벤트가 필요합니다.
• 삭제는 동사가 아니라 정책입니다. 소프트 삭제와 하드 삭제 사이의 선택은 감사 가능성을 개인정보 규제의 삭제 의무 및 쿼리 복잡성과 맞바꾸는 일입니다. 클래스별로, 의도적으로 결정해야 합니다.
• 동시성의 비용은 드러나지 않습니다. 두 갱신이 겹치면 마지막에 쓴 쪽이 이기고, 먼저 쓴 쪽의 변경은 조용히 사라집니다. 버전 필드와 조건부 저장이 표준 해법입니다.
• 목록 조회는 다섯 번째 동사입니다. 필터링, 정렬, 페이지네이션이 실제 읽기 트래픽의 대부분과 성능 버그의 대부분을 차지합니다. CRUDL과 BREAD가 존재하는 이유입니다.
• CRUD API는 빈약해질 수 있습니다. 행을 넣고 행을 꺼내는 것이 전부인 표면은 비즈니스 로직을 클라이언트로 밀어냅니다. 워크플로는 데이터 옆, 서버 측에 두어야 합니다.

Back4app에서의 CRUD

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Back4app은 이 글에서 다룬 작업을 덜어 줍니다. 클래스를 정의하면 위의 CRUD 매트릭스 전체가 한 번에 생깁니다. HTTP 열에 해당하는 REST 엔드포인트, GraphQL 뮤테이션, 코드 탭의 SDK 관용구가 모두 갖춰지며, 클래스 수준 권한이 각 동사를 통제하고 beforeSave 트리거가 검증을 담당합니다. 네 가지 동사는 더 이상 코드베이스의 일부가 아니라 어휘가 됩니다.