APP DEVELOPMENT TERM
데이터베이스
서비스 정보를 정해진 구조로 관리하는 저장소
데이터베이스는 회원, 예약, 주문과 결제처럼 서비스가 계속 기억해야 할 정보를 정해진 구조로 저장하고 안전하게 찾고 바꾸는 시스템입니다.
30초 이해
데이터베이스는 파일을 쌓아두는 곳이 아니라 서비스의 현재 상태와 변경 기록을 관리합니다
사용자가 앱을 껐다 다시 켜도 예약 내역이 남아 있고 관리자가 같은 정보를 확인할 수 있는 이유는 서버가 데이터를 데이터베이스에 저장하기 때문입니다. 어떤 정보를 어떤 단위로 연결할지 구조를 먼저 정해야 합니다.
모든 데이터를 영원히 모으는 것이 목적은 아닙니다. 필요한 정보만 수집하고 누가 읽고 바꿀 수 있는지, 잘못된 변경을 어떻게 막을지, 보관 기간이 끝난 정보를 어떻게 삭제하고 백업에서 복구할지를 함께 설계해야 합니다.
한 장으로 이해
앱 데이터가 저장되고 다시 사용되는 과정
사용자 행동을 서버가 확인한 뒤 구조에 맞게 저장하고 고객 앱과 관리자 화면이 필요한 정보만 다시 조회합니다.
- 01
정보 입력
회원가입·예약·주문처럼 필요한 정보가 만들어집니다.
- 02
서버 확인
권한, 형식, 중복과 업무 조건을 먼저 확인합니다.
- 03
구조에 저장
회원·수업·예약을 연결하고 상태와 시간을 기록합니다.
- 04
조회·변경
허용된 화면에서 최신 결과를 찾고 안전하게 바꿉니다.
좋은 데이터 구조는 화면이 바뀌어도 서비스의 상태와 운영 기록을 일관되게 유지합니다.
언제 사용하는 개념인가요?
서비스 정보를 정의할 때
회원·상품·예약·결제처럼 저장할 대상과 서로의 관계를 정합니다.
화면과 서버를 연결할 때
각 화면에서 어떤 정보를 만들고 읽고 바꿀지 API와 권한을 정합니다.
운영과 이전을 준비할 때
백업·복구·보관·삭제와 다른 시스템으로 옮길 형식을 확인합니다.
왜 중요한가요?
여러 화면이 같은 상태를 봅니다
고객 앱과 관리자 화면이 하나의 예약·주문 상태를 기준으로 움직이게 합니다.
검색과 통계의 품질을 결정합니다
정보가 일정한 구조와 의미로 저장되어야 필요한 내용을 빠르게 찾고 정확히 집계할 수 있습니다.
개인정보와 운영 기록을 보호합니다
접근 권한, 변경 이력, 보관·삭제와 백업 기준을 통해 중요한 데이터를 안전하게 관리합니다.
실제 상황 예시
클래스 예약 데이터베이스라면
수강생, 강사, 수업과 예약을 각각 구분하고 고유 번호로 연결합니다.
저장할 주요 정보
- 수강생과 강사 계정
- 수업·장소·가능 시간
- 예약 번호·인원·현재 상태
- 결제·취소·변경 시간
함께 정할 관리 기준
- 역할별 조회·수정 권한
- 중복 예약과 잘못된 상태 변경 방지
- 개인정보 보관·삭제 기간
- 백업 주기와 실제 복구 방법
예약 상태를 화면 문구로만 보관하지 않고 정해진 값과 변경 이력으로 저장해야 고객과 관리자가 같은 결과를 확인할 수 있습니다.
자주 하는 오해
“데이터베이스는 엑셀 파일과 같은 저장 공간이다”
표처럼 보일 수 있지만 여러 사용자의 동시 요청, 정보 관계, 권한과 안전한 변경을 처리하도록 설계된 시스템입니다.
“데이터를 많이 모을수록 나중에 도움이 된다”
사용 목적이 없는 수집은 비용과 개인정보 위험을 높입니다. 필요한 정보와 보관 기간을 먼저 정해야 합니다.
“백업 파일이 있으면 복구도 된다”
파일이 손상되지 않았는지, 필요한 시점으로 실제 복구할 수 있는지와 복구 책임자를 정기적으로 확인해야 합니다.
우리 서비스에 적용할 때 확인하세요
- 1서비스가 반드시 기억해야 할 정보와 관계는 무엇인가요?
- 2각 역할이 어떤 정보를 읽고 만들고 수정할 수 있나요?
- 3중복과 잘못된 상태 변경을 데이터 수준에서 막을 수 있나요?
- 4개인정보의 수집 목적·보관 기간·삭제 방법이 정해졌나요?
- 5백업을 실제로 복구해 본 기록과 담당자가 있나요?
다음 자료
이해한 내용을 바로 적용해보세요
데이터베이스에 요청을 전달하는 API, 데이터 규칙을 관리하는 백엔드와 클라우드에서 운영하는 방식을 이어서 확인하세요.
화면보다 먼저 서비스가 기억할 정보와 상태를 정하세요
사용자 행동, 서버 판단과 관리자 업무를 하나의 데이터 흐름으로 연결하면 빠진 운영 조건을 찾을 수 있습니다.