[DB] 서버, 데이터베이스 개념

프론트엔드(Front End) 와 백엔드(Back End)

 

구분	프론트엔드(Front-end)	백엔드(Back-end)
작동 위치	사용자의 기기(브라우저, 앱 등)	서버(호스팅, 클라우드, 자체 서버 등)
핵심 역할	- UI/UX 구현 - 화면 렌더링 - 이벤트 처리 - 서버와 데이터 교환	- 비즈니스 로직 처리 - 데이터베이스 연동 - API 제공 - 인증/보안, 로그 관리 등
기술 스택	- HTML, CSS, JavaScript - React, Vue.js, Angular 등 프레임워크	- Node.js, Python, Java, PHP 등 - Express, Django, Spring, Laravel 등 프레임워크
대표 개념	- DOM(문서 객체 모델) - AJAX/Fetch/Axios - 상태 관리(Redux 등)	- REST API - DB 쿼리(ORM, SQL) - 서버 환경(AWS, GCP, Docker, K8s 등)
직접 눈에 보이나?	보임 (사용자에게 노출)	보이지 않음 (사용자가 직접 볼 수 없음)

 

---

서버의 필요성

• HTML, CSS 등을 이용하여 웹페이지안에서 꾸몄으나, 새로고침을 할 경우 작업한 데이터가 다 날아감
• 이걸 새로고침하더라도 데이터가 날아가지 않게 하려면, 어딘가에 계속 보관되어 있다면 날아가지 않았을 것
  
  • 데이터베이스가 있으면 데이터를 저장할 수 있음!

---

파이어베이스(Firebase)

구글(Google)이 개발한 모바일 및 웹 애플리케이션 개발 플랫폼

• 파이어베이스는 웹 서버를 대신 만들어 주는 서비스
• 서버 개발 없이 제작 가능
• 백엔드 코드 한 줄 없이도 프론트지식(HTML, CSS, JS)만 알아도 웹 서비스 출시 가능!

 

*개발 코드 1 . 서버로 데이터를 전송하는 코드 (프론트엔드에서 작성)

*개발 코드 2 . 데이터를 받으면 데이터베이스에 저장하는 코드 (파이어베이스에서 작성)

---

데이터베이스(Database)

• 많은 양의 데이터를 체계적으로 모아서 보관하고, 필요할 때 쉽게 꺼내 쓰도록 도와주는 ‘저장소
• 많은 데이터를 효율적으로 저장·관리·검색할 수 있게 만든 체계적인 시스템

쉽게 말하면, 데이터를 체계적으로 저장 및 관리하는 곳이다. (예) 도서관

 

데이터베이스는 왜 필요할까?

• 데이터가 많아지면 엑셀, 수기로 관리하기 어려움
• 빠르게 검색하고, 여러 사람이 동시에 접근해도 안정적이어야 함
• 한두 번만 찾는 것이 아니라, 지속적으로 데이터를 추가, 조회, 수정, 삭제가 가능해야 함
• 보안과 백업이 중요함 (개인 정보 데이터가 유출되면 안되기 때문)

많은 양의 데이터를 잘 관리하고, 잘 찾기 위해서 필요하다!

 

데이터베이스 종류

분류	주요 장점	주요 단점
관계형 DB (RDB)	- 구조화된 테이블 & SQL - *트랜잭션 지원 - 데이터 무결성	- 스케일 아웃 어려움 - 스키마 변경 부담 - 복잡한 JOIN 시 성능 저하
비관계형 DB 문서(Document)	- 유연한 스키마 - 수평 확장 용이 - 대규모 데이터 처리	- 데이터 중복 증가 - 복잡 쿼리 제한 - 트랜잭션/ACID 제약
비관계형 DB 키-값(Key-Value)	- 초고속 읽기/쓰기 - 메모리 기반 - 캐싱에 최적	- 복잡 쿼리 불가 - 메모리 사용량 큼 - 영구성 보장이 제한적
데이터 웨어하우스	- 대규모 데이터 분석 - OLAP 집계·통계에 최적 - 병렬 쿼리	- 실시간 처리 미흡 - 사용료가 비쌈 - ETL/ELT 과정 복잡

 

*트랜잭션: 데이터베이스 상태를 바꾸는 일종의 작업 단위

 

1) 관계형 데이터베이스

• 특징:
  • 표(테이블) 형태로 데이터를 저장
  • 스프레드시트와 유사한 구조(행과 열)
  • 중복된 데이터를 최소화하기 위해 테이블 간 관계를 설정
    • 예시: 회원 테이블, 주문 테이블, 상품 테이블 등 서로 연결
• 장점:
  • 표 형식이 직관적이고, SQL(Structured Query Language)로 원하는 정보를 쉽게 가져올 수 있음
  • 데이터가 안정적으로 관리 (무결성, 트랜잭션 등)
• 단점
  • 스케일 아웃(Scale-out) 어려움:
    • 대규모 트래픽이 몰릴 때, 수직적 확장(서버 사양 업그레이드)으로는 한계가 있을 수 있음.
    • 수평 확장(샤딩, 복제)을 구현하려면 구조가 복잡해질 수 있음
  • 스키마(schema)변경 부담:
    • 테이블 구조가 엄격해, 컬럼 추가·삭제 같은 스키마 변경 시 전체 테이블에 영향을 줄 수 있음.
    • 개발 단계에서 자주 바뀌는 구조에 대해서는 유연성이 떨어진다.
  • 복잡한 JOIN 성능 이슈:
    • 여러 테이블을 조인(Join)해서 대용량 데이터를 다룰 때, 성능 저하가 발생할 수 있음.
    • 잘못된 인덱스 설정이나 비효율적 쿼리 설계로 인해 속도가 크게 떨어지기도 함.

• 예시: MySQL, PostgreSQL, Oracle, MS SQL Server

-- 1. 새로운 데이터베이스 생성
CREATE DATABASE example_db;

-- 2. 사용할 데이터베이스 선택
USE example_db;

-- 3. users 테이블 생성 (기본적인 예시)
CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(50) NOT NULL,
  email VARCHAR(100) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 4. 예시 데이터 삽입
INSERT INTO users (username, email)
VALUES 
  ('Alice', 'alice@example.com'),
  ('Bob', 'bob@example.com');

-- 5. 테이블 조회
SELECT * FROM users;

 

2) 비관계형 데이터베이스

• 특징:
  • 테이블로만 이루어진 전통적인 구조 대신, JSON, Key-Value, 문서 형태 등 유연한 구조를 가짐
  • 스키마가 유연해서, 데이터를 자유롭게 넣고 뺄 수 있음
  • 대규모 트래픽 처리나, 초당 수많은 요청을 빠르게 처리해야 할 때 사용하기 좋음

• 장점:
  • 스키마(자료 구조)가 자유로운 편, 데이터 형식을 자주 바꿔야 하거나, 빅데이터 처리가 필요할 때 유리하다

• 단점
  • 데이터 중복 증가:
    • 문서 단위로 데이터를 저장하므로, 동일 정보가 여러 문서에 중복될 수 있음.
    • 중복을 줄이려면 도큐먼트 참조(Ref)나 임베디드(Embedded) 구조를 신중히 설계해야 함.
  • 복잡한 쿼리 시 어려움:
    • 문서 구조가 계층적이어서, 복잡한 join(관계형 DB의 조인처럼)을 구현할 때는 다소 제한적이거나 불편할 수 있음.
  • 트랜잭션/ACID 제약:
    • MongoDB도 트랜잭션을 지원하기 시작했으나, 관계형 DB만큼 전체적으로 풍부하지 않을 수 있음.
    • 여러 컬렉션에 걸친 복합 트랜잭션이 필요한 시스템에는 주의가 필요.
  • 예시: MongoDB(문서 형식 DB), Redis(Key-Value DB), Cassandra, CouchDB 등

# Mongo Shell 또는 MongoDB CLI에서 실행 예시

# 1. exampleDB라는 데이터베이스 사용(없으면 자동 생성)
use exampleDB;

# 2. users 컬렉션에 새 문서(Document) 삽입
db.users.insertOne({
  name: "Alice",
  email: "alice@example.com",
  createdAt: new Date()
});

# 3. 모든 문서 조회
db.users.find();