메모리, 한 번에 이해하기
컴퓨터가 프로그램을 돌릴 때, 데이터를 어디에 올려두고 작업할까? 그 "작업 공간"이 바로 메모리(RAM) 다. 메모리를 알면 "내 컴퓨터가 왜 느려지지?"가 한 방에 이해됨. 핵심부터 한 줄로 정리하면 이렇다.
메모리 = 컴퓨터가 지금 작업 중인 데이터를 잠깐 올려두는 빠른 임시 작업 공간
쉽게 비유하면
책상이라고 생각하면 됨! 책장(저장장치 = SSD/하드디스크)에는 책이 잔뜩 꽂혀 있지만, 거기선 바로 작업을 못 한다. 필요한 책을 꺼내서 책상(메모리 = RAM) 위에 펼쳐놔야 읽고 쓸 수 있다.
- 책상이 넓으면? 여러 권 동시에 펼쳐놓고 작업 가능 (= RAM 크면 프로그램 여러 개 빵빵하게)
- 책상이 좁으면? 한 권 보려고 다른 책 치워야 함 (= RAM 부족하면 느려짐)
- 컴퓨터 끄면? 책상 위는 싹 치워짐. 안 치운 건 다 날아감 (= 휘발성)
책장은 느리지만 영구 보관, 책상은 빠르지만 임시. 이 차이가 메모리의 핵심 같음!
자세히
메모리(RAM) vs 저장장치(디스크)
| 메모리(RAM) | 저장장치(SSD/HDD) | |
|---|---|---|
| 속도 | 엄청 빠름 | 상대적으로 느림 |
| 용량 | 작음 (보통 8~32GB) | 큼 (수백 GB~TB) |
| 영속성 | 전원 끄면 날아감 | 전원 꺼도 유지 |
| 비유 | 책상 | 책장 |
메모리 계층 구조
사실 메모리는 한 종류가 아니라 속도-가격 순으로 층층이 쌓여 있다.
- 레지스터 — CPU 안. 가장 빠르고 가장 작고 비쌈
- 캐시(Cache) — CPU 근처. 자주 쓰는 거 미리 갖다 둠
- 메인 메모리(RAM) — 우리가 흔히 말하는 메모리
- 보조 저장장치(디스크) — 가장 느리지만 크고 쌈
위로 갈수록 빠르지만 비싸고 작고, 아래로 갈수록 느리지만 싸고 크다. 그래서 자주 쓰는 데이터는 위쪽에 두는 게 성능의 핵심이다.
프로그램 실행 중 메모리 구조 (스택 vs 힙)
프로그램이 돌 때 메모리는 영역이 나뉜다.
- 스택(Stack) — 함수 호출, 지역 변수 등. 자동으로 쌓였다 사라짐. 빠르지만 작음
- 힙(Heap) — 동적으로 할당하는 데이터. 크지만 직접 관리해야 함
가상 메모리 & 스왑
RAM이 부족하면 OS가 디스크 일부를 "임시 RAM"처럼 빌려 쓴다(스왑). 근데 디스크는 느리니까, 이게 발동하는 순간 컴퓨터가 버벅거리기 시작함.
메모리 누수 (Memory Leak)
다 쓴 메모리를 안 돌려주고 계속 점유하는 문제. 시간이 지날수록 쓸 수 있는 메모리가 줄어서, 앱이 점점 느려지다가 결국 뻗어버린다.
실사용 예
"컴퓨터가 왜 느려지지?"의 정답이 대부분 메모리에 있다.
- 브라우저 탭을 수십 개 열면 느려지는 이유 → 각 탭이 메모리를 먹어서 RAM이 꽉 참 → 스왑 발동 → 디스크 들락거리며 버벅임
- 앱을 오래 켜두면 점점 느려지는 이유 → 메모리 누수가 쌓이는 경우가 많음
- 서버가 갑자기 죽는 OOMKilled → 메모리 부족으로 OS가 프로세스를 강제 종료한 것 (클러스터 모니터링에서 자주 보는 그 단어!)
그리고 Redis가 왜 그렇게 빠른가? 답이 여기 있다. Redis는 데이터를 디스크가 아니라 메모리(RAM)에 올려두고 쓰기 때문이다. 책장이 아니라 책상에서 바로 꺼내 쓰니까 빠른 거다. 대신 메모리는 비싸고 작으니까, 그래서 Redis(ElastiCache) 비용이 훅 나가는 거고 메모리 용량 관리가 중요한 것 같음!
한 방 정리
| 구분 | 내용 |
|---|---|
| 한 줄 정의 | 작업 중 데이터를 올려두는 빠른 임시 공간 |
| 비유 | 책상 (책장 = 저장장치) |
| 핵심 특징 | 빠름 + 작음 + 전원 끄면 날아감 |
| 계층 구조 | 레지스터 → 캐시 → RAM → 디스크 |
| 느려지는 주범 | RAM 부족 → 스왑 / 메모리 누수 |
쉽게 외우면 "메모리는 책상, 디스크는 책장" — 이렇게 보면 감 잡힐 듯!
데이터베이스, 한 번에 이해하기
회원 정보, 게시글, 주문 내역… 서비스가 다루는 데이터는 어딘가에 저장돼야 하고, 필요할 때 빠르게 찾을 수 있어야 한다. 그걸 책임지는 게 데이터베이스(DB) 다. 핵심부터 한 줄로 정리하면 이렇다.
데이터베이스 = 데이터를 체계적으로 저장하고, 빠르게 찾아 쓸 수 있게 관리하는 시스템
쉽게 비유하면
도서관이라고 생각하면 됨! 책(데이터)을 그냥 바닥에 마구 쌓아두면 원하는 책을 절대 못 찾는다. 도서관은 책을 분류(스키마)하고, 색인 목록(인덱스)을 만들고, 사서(DBMS)가 "그 책 3층 A-7 칸에 있어요" 하고 빠르게 찾아준다.
- 그냥 메모장에 데이터 막 쌓기 = 바닥에 책 쌓기 (못 찾음)
- 데이터베이스 쓰기 = 잘 정리된 도서관 (순식간에 찾음)
데이터의 양이 많아질수록 이 "정리와 검색"의 차이가 어마어마해지는 게 핵심 같음!
자세히
DB vs DBMS
- 데이터베이스(DB) — 정리된 데이터 그 자체 (= 도서관에 꽂힌 책들)
- DBMS — 그걸 관리하는 소프트웨어 (= 사서). PostgreSQL, MySQL, MongoDB 같은 게 다 DBMS다.
크게 두 종류: 관계형 vs 비관계형
관계형 DB (RDB / SQL)
- 데이터를 표(테이블) 형태로 저장. 행(row)과 열(column)로 구성
- 테이블끼리 관계를 맺을 수 있음 (예: 유저 테이블 ↔ 주문 테이블)
- SQL이라는 질의 언어로 데이터를 다룸
- 예: PostgreSQL, MySQL
- 비유: 깔끔하게 줄 맞춘 엑셀 시트들이 서로 연결된 느낌
비관계형 DB (NoSQL)
- 표 구조에 안 묶이고 유연한 형태로 저장
- 종류가 다양함:
- 문서형(Document) — JSON 같은 형태 (예: MongoDB)
- 키-값(Key-Value) — 이름표 붙여서 저장 (예: Redis)
- 구조가 자주 바뀌거나, 엄청 빠른 속도가 필요할 때 유리
- 비유: 칸막이 없이 자유롭게 넣는 보관함
핵심 개념들
- 기본키(Primary Key) — 각 데이터를 구분하는 고유 번호 (예: 학번, 주민번호 같은 거)
- 외래키(Foreign Key) — 다른 테이블과 연결하는 키
- 인덱스(Index) — 검색을 빠르게 해주는 색인. 없으면 데이터 처음부터 다 뒤져야 함
- 트랜잭션 & ACID — 여러 작업을 "전부 성공 아니면 전부 취소"로 묶어서 데이터가 깨지지 않게 보장 (예: 송금할 때 "내 계좌 차감 + 상대 계좌 증가"가 둘 다 되거나 둘 다 안 되거나)
- 정규화 — 중복을 줄이고 구조를 깔끔하게 정리하는 설계 기법
실사용 예
서비스 만들면 무조건 쓰게 된다.
- 회원 정보, 게시글, 댓글 → 관계가 명확하니까 보통 PostgreSQL/MySQL(RDB) 에 저장
- 투표/설문 데이터 → 구조에 따라 RDB로 깔끔하게 관계 맺어서 저장
- 거래 내역 → 돈이 오가는 거라 트랜잭션(ACID) 이 특히 중요. 중간에 깨지면 큰일나니까
- 자주 조회되는 데이터(캐시) → Redis(키-값, NoSQL) 에 올려두고 빠르게 꺼냄
여기서 메모리 글이랑 연결된다. Redis는 데이터를 메모리에 올려두는 NoSQL이라 빠른 거고, PostgreSQL 같은 RDB는 디스크에 안정적으로 저장하는 거다. 그래서 보통 "RDB에 영구 저장 + Redis로 캐싱" 조합을 많이 쓴다.
성능 얘기도 빼놓을 수 없다. 데이터가 수십만 건 쌓였는데 인덱스 없이 검색하면 처음부터 끝까지 다 뒤져서 엄청 느려진다. 적절한 곳에 인덱스를 걸어주면 도서관 색인처럼 한 방에 찾아서 빨라짐. "쿼리가 왜 느리지?"의 단골 원인이 인덱스 문제인 것 같음!
한 방 정리
| 구분 | 내용 |
|---|---|
| 한 줄 정의 | 데이터를 체계적으로 저장·검색하는 시스템 |
| 비유 | 도서관 (분류 + 색인 + 사서) |
| 두 갈래 | 관계형(SQL) vs 비관계형(NoSQL) |
| 빠른 검색 비결 | 인덱스 |
| 데이터 안전장치 | 트랜잭션(ACID) |
쉽게 외우면 "잘 정리해서, 빠르게 찾고, 안 깨지게 지키는 데이터 창고" — 이렇게 보면 감 잡힐 듯!
