CRUD란? 생성, 조회, 수정, 삭제를 쉽게 설명

CRUD는 **생성(create), 조회(read), 수정(update), 삭제(delete)**의 약자로, 앱이 저장된 데이터에 대해 하는 네 가지 기본 작업입니다. 새 고객을 추가하는 것은 생성, 고객 목록을 보는 것은 조회, 고객의 전화번호를 바꾸는 것은 수정, 고객을 삭제하는 것은 삭제입니다. CRM, 예약 시스템, 재고 관리 도구, 관리자 패널 같은 대부분의 비즈니스 앱은 대체로 규칙과 좋은 화면 구성을 더한 CRUD입니다.

AI로 만들 때 CRUD가 중요한 이유

CRUD는 막연한 앱 아이디어를 정확한 요청으로 바꿔 주는 어휘입니다. "우리 공급업체를 관리하는 앱"이라고 하면 AI는 추측할 수밖에 없습니다. 그러나 "공급업체를 생성, 목록 보기, 수정, 삭제할 수 있게 해 주고, 다음 필드를 넣어 줘"라고 하면, 어떤 화면, 데이터베이스 작업, 서버 경로를 만들어야 하는지 정확히 알 수 있습니다.

테스트 체크리스트로도 쓸 수 있습니다. 앱의 각 종류의 레코드에 대해 네 가지를 물어보세요. 추가할 수 있는가, 볼 수 있는가, 수정할 수 있는가, 삭제할 수 있는가? 그리고 각 작업을 올바른 사람만 할 수 있는가? 의외로 많은 AI로 만든 앱이 레코드는 만들 수 있지만 수정은 못 하거나, 누구나 무엇이든 삭제할 수 있게 해 둡니다.

일상의 비유: 레시피 카드 상자

주방 선반에 놓인 레시피 카드 상자를 떠올려 보세요.

• 생성: 새 카드를 쓰고 상자에 넣습니다.
• 조회: 상자를 넘겨 보거나, 라자냐 카드 한 장을 꺼내 봅니다.
• 수정: "치즈 200g"에 줄을 긋고 "250g"이라고 씁니다.
• 삭제: 카드를 꺼내 버립니다.

여기에 규칙을 더해 봅시다. 카드를 버릴 수 있는 사람은 주방장뿐이고, 모든 카드에는 제목이 있어야 하며, 같은 이름의 카드를 두 장 넣을 수 없습니다. 이것이 검증과 권한이 있는 CRUD 앱이며, 실제 대부분의 앱이 바로 이런 모습입니다.

각 계층에서 CRUD가 나타나는 방식

각 작업은 화면, 서버, 데이터베이스에 모두 나타납니다. 이를 나란히 보면 앱이 어떻게 만들어지는지 많이 이해할 수 있습니다.

화면은 프런트엔드이고, API 요청은 프런트엔드가 백엔드와 대화하는 방식이며, SQL은 백엔드가 데이터베이스와 대화하는 방식입니다. 이 용어들이 낯설다면 API란 무엇인가와 데이터베이스란 무엇인가를 참고하세요.

실제 예시: 장비 대여 관리 앱

한 학교의 미디어 부서는 학생들에게 카메라와 마이크를 빌려 주는데, 자꾸 누가 가져갔는지 놓칩니다. 그래서 간단한 앱을 원합니다.

레코드. 두 종류가 있습니다. 장비(이름, 종류, 일련번호, 상태)와 대여(어떤 장비, 어떤 학생, 대여일, 반납 예정일, 반납일)입니다.

장비의 CRUD:

• 생성: 직원이 일련번호와 함께 새 카메라를 추가합니다. 규칙: 일련번호는 고유해야 합니다.
• 조회: 전체 장비 목록을 종류별, "지금 대여 가능" 기준으로 필터링할 수 있습니다. 상세 페이지에는 해당 장비의 대여 이력이 보입니다.
• 수정: 상태를 "수리 필요"로 바꿉니다.
• 삭제: 보통 실제 삭제는 하지 않습니다. 과거 대여가 30건인 카메라를 삭제하면 그 대여 기록들의 연결이 끊어집니다. 대신 "퇴역"으로 표시해서 대여 가능 목록에서는 사라지되, 이력은 남기는 것이 좋습니다. 이를 소프트 삭제라고 합니다.

대여의 CRUD:

• 생성: 장비를 학생에게 대여해 줍니다. 규칙: 이미 대여 중인 장비는 다시 대여할 수 없습니다.
• 조회: "연체 대여" 목록을 봅니다. 반납 예정일이 지났고 반납일이 없는 대여입니다.
• 수정: 장비가 돌아오면 반납일을 기록합니다.
• 삭제: 실수로 입력한 대여에 한해 직원만 삭제할 수 있습니다.

권한. 학생은 대여 가능한 장비를 조회만 할 수 있고, 생성, 수정, 삭제는 직원만 할 수 있습니다. 이 확인은 버튼을 숨기는 것이 아니라 서버에서 실행됩니다.

이것이 앱의 전부입니다. 흥미로운 부분인 이중 대여 방지, 연체 목록, 장비별 이력은 기본 CRUD 위에 얹힌 규칙과 쿼리입니다.

핵심 용어

• 레코드(행): 하나의 항목입니다. 공급업체 한 곳이나 대여 건 하나가 여기에 해당합니다.
• 엔티티 / 리소스: 레코드의 종류입니다. 예를 들어 "공급업체"입니다. 보통 각 엔티티마다 자체 테이블과 CRUD 화면 세트가 있습니다.
• 검증(Validation): 입력값을 확인하는 것입니다. 필수 필드, 올바른 이메일, 양수 수량 등이 있습니다. 편의를 위해 양식에서 하고, 안전을 위해 서버에서도 해야 합니다.
• 소프트 삭제: 기록을 완전히 지우는 대신 삭제됨 또는 보관됨으로 표시해서, 이력과 연결을 유지하는 것입니다.
• 페이지네이션: 긴 목록을 한 번에 한 페이지씩 보여 주어 앱을 빠르게 유지하는 것입니다.
• 감사 로그: 누가 무엇을 언제 생성, 변경, 삭제했는지 기록하는 것입니다.
• 관리자 패널: 직원이 앱의 데이터를 관리하기 위한 CRUD 화면 모음입니다.

흔한 실수와 오해

• 네 가지 중 하나를 빠뜨리는 경우. 앱이 생성과 조회만 있고 수정이 없어서, 오타 한 번에 삭제하고 다시 입력해야 하는 경우가 많습니다. 모든 엔티티에 대해 네 가지를 모두 확인하세요.
• 삭제가 무언가를 망가뜨리는 경우. 청구서가 있는 고객을 삭제하면 연결이 끊긴 청구서가 남거나 기록이 사라질 수 있습니다. 엔티티마다 결정하세요. 삭제를 막을지, 소프트 삭제할지, 관련 레코드도 함께 삭제할지 정합니다.
• 권한을 화면에서만 처리하는 경우. 삭제 버튼을 숨겨도 누군가 DELETE 요청을 직접 보내는 것을 막지 못합니다. 서버가 요청자를 확인해야 합니다.
• ID로 수정할 때 소유권을 확인하지 않는 경우. 사용자 A가 URL의 숫자를 바꿔 /api/notes/42를 수정할 수 있다면, 사용자 B의 메모를 고칠 수도 있습니다. 모든 수정과 삭제는 레코드가 요청자의 것인지 확인해야 합니다.
• 삭제 확인 절차가 없는 경우. 실수로 한 번 누르는 것만으로 데이터가 사라지면 안 됩니다. 확인 단계나 실행 취소 기능을 두세요.
• "CRUD는 기본적인 것이라 만들 가치가 없다." 많은 유용한 제품이 범용 도구보다 업무 흐름에 더 잘 맞는 CRUD 앱입니다.

AI 빌더에게 요청할 내용

엔티티마다 한 번에 하나씩 이 패턴을 사용하세요.

공급업체 기능을 만들어 줘. 목록, 생성, 수정, 삭제가 가능해야 해. 필드는 이름(필수), 담당자 이메일(올바른 이메일 형식), 전화번호, 분류(식품, 포장재, 청소용품 중 하나), 메모야. 이름으로 검색하고 분류로 필터링하는 목록 화면이며, 페이지당 20개씩 보여 줘. 삭제 전에 확인을 받고, 공급업체에 주문이 있으면 삭제 대신 보관 처리해 줘. 로그인한 직원만 생성, 수정, 보관할 수 있도록 서버에서 강제해 줘.

그다음 네 가지 작업을 모두 테스트해 보세요. 권한이 있는 사용자로도, 접근하면 안 되는 사용자로도 해 봅니다. 엔티티 하나가 작동하면 다음 엔티티를 추가하세요. 내부 도구 만드는 방법은 CRUD 화면이 어떻게 완전한 관리자 앱이 되는지 보여 주며, Postgres란 무엇인가는 이런 앱의 대부분이 기반으로 삼는 데이터베이스를 설명합니다.

Mythex에서의 CRUD 앱

CRUD 앱은 AI 앱 빌더가 가장 잘하는 것 중 하나이며, Mythex도 예외가 아닙니다. 채팅에서 엔티티와 필드를 요청하면, Mythex가 프로젝트에 Postgres 데이터베이스를 연결하고 테이블을 만든 뒤, 라이브 미리보기에서 목록, 양식, 상세 화면을 만듭니다. 그다음 /test를 실행해 흐름을 확인할 수 있습니다. 문서에는 시작 프롬프트가 포함된 CRUD 앱 레시피가 있고, 내부 도구 빌더와 대시보드 템플릿도 시작하기 좋은 곳입니다.

자주 묻는 질문