데이터는 어디에 저장될까 - CPU·메모리·하드디스크로 이해하는 Redis·MySQL·MongoDB

 

"Redis는 왜 그렇게 빠른가요?"
"메모리 DB라던데, 그럼 서버 껐다 켜면 데이터가 다 날아가는 거 아니에요?"
"MySQL이랑 MongoDB는 결국 뭐가 다른 건데요?"

"세션을 Redis에 저장한다는 말이 무슨 뜻이죠? 세션은 원래 어디 있는 건데요?"

주니어 분들이랑 얘기하다 보면 이 질문들이 묘하게 한 덩어리로 묶여서 돌아옵니다. 따로 떨어진 질문 같지만, 사실 뿌리가 하나예요. "이 데이터가 지금 물리적으로 어디에 놓여 있느냐"입니다. CPU 안인지, 메모리(RAM)인지, 하드디스크인지. 저장 위치만 잡으면 속도도, 휘발 여부도, DB들의 성격 차이도 거의 다 설명이 됩니다.

 

저는 개발을 시작하기 전부터 컴퓨터 뜯어서 고치는 걸 좋아했습니다. 램 꽂고, 하드 갈고, 발열 잡고 하던 게 취미였거든요. 그 덕에 RAM이랑 디스크가 다른 물건이라는 게 머릿속에 그냥 그림으로 박혀 있었고, 나중에 Redis나 MySQL을 다룰 때도 "아, 얘는 작업대에 올려두는 애구나" 하는 감이 자연스럽게 왔습니다. 근데 의외로 많은 개발자분들이 이 부분을 블랙박스로 두고 쓰시더라고요. 그래서 한번 바닥부터 정리해보려 합니다.

 

이 글은 신입~주니어 개발자, 그리고 DB는 쓰는데 "왜 빠른지"는 설명 못 하겠는 분들을 위한 글입니다. 하드웨어 저장 구조부터 시작해서 MySQL·MariaDB·PostgreSQL·Oracle 같은 RDB, Redis·Memcached·MongoDB·ClickHouse 같은 NoSQL 계열, 마지막엔 덤으로 쿠키와 세션까지 "어디에 저장되는가" 한 줄로 꿰어보겠습니다.

📋 목차

1. 컴퓨터는 데이터를 세 군데에 둔다
2. 메모리는 작업대, 디스크는 창고
3. 왜 위로 갈수록 빠를까 - 속도의 계층
4. 휘발성과 비휘발성, 갈리는 건 결국 전기
5. RDB 가족 - MySQL·MariaDB·PostgreSQL·Oracle
6. NoSQL이라는 큰 우산
7. Redis - 메모리에 사는데 디스크도 본다
8. Memcached - 순수하게 메모리만
9. MongoDB - 디스크 기반인데 메모리를 잘 쓴다
10. ClickHouse - 컬럼으로 눕혀서 디스크에 쌓는다
11. 덤 - 쿠키와 세션은 어디에 저장될까
12. 한눈에 비교
13. 그래서 뭘 언제 쓰나
14. 마무리

1. 컴퓨터는 데이터를 세 군데에 둔다

컴퓨터가 데이터를 보관하는 곳은 크게 세 군데입니다. CPU 안, 메모리(RAM), 그리고 디스크(하드디스크나 SSD)예요. 위로 갈수록 빠르고 비싸고 작으며, 아래로 갈수록 느리고 싸고 큽니다. 이 한 문장이 오늘 글의 거의 전부라고 해도 됩니다.

CPU 안 - 레지스터와 캐시

CPU가 실제로 계산을 하려면 데이터를 손에 쥐고 있어야 합니다. 그 "손"이 레지스터고, 손 바로 옆 작은 서랍이 캐시(L1, L2, L3)입니다. 용량은 우습게 작아요. 레지스터는 수십~수백 바이트, 캐시도 다 합쳐 수 MB 수준입니다. 대신 접근 속도는 압도적으로 빠릅니다. CPU가 연산할 때마다 매번 멀리 있는 메모리까지 다녀오면 너무 느리니까, 자주 쓸 데이터를 바로 옆에 쟁여두는 거죠.

메모리(RAM) - 펼쳐놓고 일하는 공간

프로그램이 실행되는 동안 데이터가 올라가 있는 곳이 메모리입니다. 우리가 흔히 "8기가, 16기가" 하는 그 램이요. CPU 캐시보다는 훨씬 크고(수 GB~수십 GB), 디스크보다는 훨씬 빠릅니다. 다만 전원이 끊기면 내용이 사라진다는 게 핵심 특징입니다. 뒤에서 다시 다룹니다.

디스크(HDD·SSD) - 꺼도 남는 창고

전원을 꺼도 데이터가 그대로 남아 있는 저장소입니다. 옛날 하드디스크(HDD)는 자기를 띤 원판을 물리적으로 돌려서 읽고, 요즘 SSD는 낸드 플래시라는 반도체에 전하를 가둬서 기록합니다. 둘 다 메모리보다 훨씬 느리지만, 용량이 크고 싸고, 무엇보다 전원이 나가도 안 날아갑니다. 우리가 파일을 "저장한다"고 할 때 데이터가 가는 곳이 바로 여기예요.

 

 

📌 한 문장 요약

CPU 캐시 → 메모리 → 디스크 순으로 내려갈수록 느려지지만 커지고 싸집니다.

그리고 메모리 위쪽은 전원 끊기면 사라지고, 디스크는 남습니다.

오늘 등장하는 모든 DB와 쿠키·세션은 결국 "이 셋 중 어디에 데이터를 두느냐"의 문제로 환원됩니다.

 

2. 메모리는 작업대, 디스크는 창고

비유가 하나 있으면 이해가 훨씬 쉬운데, 저는 목공방을 떠올립니다. 디스크는 부품과 자재를 쌓아둔 창고고, 메모리는 지금 작업 중인 물건을 올려둔 작업대입니다.

창고(디스크)는 넓어서 뭐든 잔뜩 보관할 수 있지만, 필요한 물건을 가지러 매번 걸어 들어가야 하니 느립니다. 작업대(메모리)는 좁아서 많이 못 올려두지만, 손만 뻗으면 바로 닿으니 빠르죠. 그래서 일을 할 땐 창고에서 필요한 자재를 작업대로 꺼내 와서 다루고, 다 끝나면 다시 창고에 넣습니다.

프로그램이 도는 방식이 딱 이렇습니다. 디스크에 저장된 데이터를 메모리로 끌어올려서 CPU가 작업하고, 결과를 다시 디스크에 씁니다. 그런데 작업대가 비어 있으면(전원 끄면) 올려둔 게 다 사라지지만, 창고는 문 닫고 퇴근해도 물건이 그대로 있죠. 이 차이가 곧 휘발성과 비휘발성입니다.

 

 

"그럼 작업대(메모리)를 엄청 크게 만들면 다 해결되는 거 아니에요?" 이론상 맞습니다.

다만 메모리는 디스크보다 단위 용량당 가격이 한참 비싸고,

전원이 끊기면 사라지니 영구 저장 용도로는 못 씁니다.

그래서 둘을 역할 나눠 같이 쓰는 거예요.

 

3. 왜 위로 갈수록 빠를까 - 속도의 계층

속도 차이가 어느 정도냐면, 숫자로 보면 좀 충격적입니다. 정확한 값은 하드웨어마다 다르지만, 대략적인 감을 잡아보겠습니다. 아래는 흔히 인용되는 접근 지연시간을 사람이 체감할 수 있게 뻥튀기한 비유입니다.

저장 위치	실제 접근 시간(대략)	캐시를 1초로 봤을 때
CPU 레지스터·캐시	약 1 나노초	1초
메모리(RAM)	약 100 나노초	1~2분
SSD	수십~수백 마이크로초	하루 이틀
HDD(하드디스크)	약 10 밀리초	서너 달

캐시에서 1초 걸릴 일이 하드디스크에선 몇 달짜리 작업이 되는 셈입니다. 차이가 이렇게 벌어지는 이유는 크게 둘입니다. 하나는 물리적 거리예요. 캐시는 CPU 코앞이고 메모리는 메인보드 위, 디스크는 또 그 너머에 있습니다. 신호가 오가는 거리 자체가 다릅니다. 다른 하나는 접근 방식입니다. 메모리는 원하는 주소로 바로 점프해서 읽는데(랜덤 액세스), 옛날 HDD는 원판을 돌리고 헤드를 움직여 해당 위치를 물리적으로 찾아가야 했습니다. SSD가 HDD보다 빠른 것도 이 물리적 이동이 없기 때문이고요.

 

 

💡 그래서 캐싱이 중요합니다

성능 튜닝이라는 게 결국 "느린 아래 계층 대신 빠른 위 계층에 데이터를 최대한 머물게 하는 일"입니다.

뒤에 나올 DB들의 버퍼 풀, Redis 캐시, 브라우저 캐시까지 전부 이 한 가지 아이디어의 변주입니다.

 

4. 휘발성과 비휘발성, 갈리는 건 결국 전기

이게 처음엔 좀 신기한데, 알고 보면 단순합니다. 메모리(RAM)는 데이터를 아주 작은 축전기에 전하를 채워서 표현합니다. 1이면 전하가 차 있고 0이면 비어 있는 식이죠. 문제는 이 전하가 가만히 둬도 줄줄 새서, 계속 전기를 흘려 보충(리프레시)해줘야 유지된다는 겁니다. 그러니 전원이 끊기면 보충이 멈추고, 채워둔 전하가 빠지면서 데이터가 사라집니다. 이게 휘발성(volatile)이에요. CPU 캐시도 같은 이유로 휘발성입니다.

반대로 디스크는 전기를 계속 안 줘도 상태가 유지됩니다. 옛날 하드디스크는 원판 표면을 자석처럼 N극·S극으로 자화시켜서 기록하는데, 자석은 전원 끊는다고 자성이 사라지지 않죠. SSD의 낸드 플래시는 전하를 가둬두는 구조인데, 새지 않게 절연막으로 막아둬서 전원 없이도 오래 유지됩니다. 그래서 비휘발성(non-volatile)입니다.

정리하면 이렇습니다. 빠른 저장소(캐시·메모리)는 빠른 대신 전원에 의존해서 휘발성이고, 느린 저장소(디스크)는 느린 대신 전원 없이도 버텨서 비휘발성입니다. 속도와 영속성이 일종의 트레이드오프인 셈이죠. 이걸 알고 나면 "메모리 DB는 빠른데 휘발성"이라는 말이 왜 당연한 소린지 바로 이해됩니다.

5. RDB 가족 - MySQL·MariaDB·PostgreSQL·Oracle

이제 본론입니다. 우리가 흔히 RDB(관계형 데이터베이스)라 부르는 MySQL, MariaDB, PostgreSQL, Oracle. 이들은 기본적으로 디스크 기반입니다. 데이터를 디스크에 영구 저장하는 게 본업이에요. 그래서 서버를 껐다 켜도 데이터가 남습니다. 당연한 얘기 같지만, 뒤에 나올 메모리 DB와 비교하면 이게 RDB의 정체성입니다.

그런데 "디스크 기반이면 느리지 않나?" 싶죠. 여기서 RDB들의 공통 비밀이 등장합니다. 전부 메모리에 캐시 공간을 두고, 자주 쓰는 데이터(페이지)를 거기 올려놓고 굴립니다. 이름만 제각각이지 하는 일은 똑같아요.

DB	메모리 캐시 이름	특징
MySQL / MariaDB	InnoDB 버퍼 풀	MariaDB는 MySQL에서 갈라져 나온 호환 DB로, 둘 다 기본 엔진이 InnoDB입니다
PostgreSQL	shared_buffers	OS 파일 시스템 캐시도 적극 활용하는 편입니다
Oracle	SGA의 버퍼 캐시	버퍼 캐시·공유 풀·리두 버퍼 등이 SGA라는 공유 메모리 영역에 모여 있습니다

동작은 이렇습니다. 쿼리가 들어오면 먼저 메모리 캐시(버퍼 풀)를 봅니다. 찾는 데이터가 거기 있으면(캐시 히트) 디스크 안 가고 바로 돌려줍니다. 없으면 디스크에서 읽어 와 캐시에 올려두고, 다음번엔 빠르게 내주죠. 쓰기도 비슷합니다. 일단 메모리에 바꿔놓고, 백그라운드에서 천천히 디스크로 내려보냅니다(플러시). 그래야 느린 디스크 쓰기를 매번 기다리지 않거든요.

대신 "메모리에만 바꿔놓고 아직 디스크에 안 쓴 상태"에서 사고가 나면 곤란하죠. 그래서 RDB들은 변경 사항을 먼저 로그에 적어둡니다. PostgreSQL의 WAL, Oracle의 리두 로그가 그 역할이에요. 사고가 나도 이 로그를 보고 복구할 수 있게요. 디스크에 안전하게 남기는 일과 메모리로 빠르게 처리하는 일, 이 둘을 동시에 잡으려는 장치입니다.

제가 3~5년 차쯤에 투자 분석용으로 재방문 고객이나 코호트를 뽑는 SQL을 매일 새벽에 돌린 적이 있는데, 같은 쿼리라도 처음 돌릴 때랑 두 번째 돌릴 때 체감 속도가 달랐습니다. 그땐 "캐싱 때문이구나" 정도로만 알았는데, 지금 보면 정확히 이 버퍼 풀 위에서 일어난 일이었죠. 처음엔 디스크에서 끌어올리느라 느리고, 두 번째는 메모리에 올라와 있어 빨랐던 겁니다.

6. NoSQL이라는 큰 우산

NoSQL은 하나의 기술이 아니라 "전통적인 RDB 방식이 아닌 것들"을 뭉뚱그린 우산 같은 말입니다. 그래서 NoSQL끼리도 성격이 천차만별이에요. 크게 보면 이런 갈래가 있습니다.

- 키-값(Key-Value) 저장소: 열쇠 하나에 값 하나. 단순하고 빠릅니다. Redis, Memcached가 대표적입니다.
- 도큐먼트(Document) 저장소: JSON 비슷한 문서 단위로 저장합니다. 스키마가 유연합니다. MongoDB가 대표적이죠.
- 컬럼 지향(Column) 저장소: 데이터를 행이 아니라 열 단위로 눕혀 저장합니다. 대량 집계·분석에 강합니다. ClickHouse, Cassandra 계열이 여기 들어갑니다.
- 그래프(Graph) 저장소: 점과 선, 즉 관계 자체를 저장합니다. 소셜 관계나 추천에 쓰입니다. Neo4j 같은 게 있고요.

NoSQL이 나온 배경은 대충 이렇습니다. 트래픽이 폭발하면서 한 대로 안 되니 여러 대로 나눠 담아야 했고(분산·확장), 정형화된 표 구조에 안 맞는 데이터도 늘었고, 어떤 용도엔 RDB의 엄격한 일관성보다 속도가 더 급했거든요. 그렇다고 NoSQL이 RDB의 상위호환이라는 건 아닙니다. 트랜잭션이 빡센 결제 같은 영역은 여전히 RDB가 강하죠. 도구마다 잘하는 자리가 다를 뿐입니다.

그리고 여기서도 결국 같은 질문으로 돌아갑니다. "얘는 데이터를 메모리에 두느냐, 디스크에 두느냐." 이걸로 NoSQL들의 속도와 휘발성이 갈립니다. 하나씩 보겠습니다.

7. Redis - 메모리에 사는데 디스크도 본다

Redis는 키-값 저장소이면서, 데이터를 기본적으로 메모리(RAM)에 올려두고 다룹니다. 그래서 빠릅니다. 앞에서 본 대로 메모리는 디스크보다 수백~수만 배 빠르니, 디스크를 거치는 RDB와는 체감 속도가 다를 수밖에 없죠. 캐시나 세션 저장, 실시간 순위표 같은 데 Redis를 쓰는 이유가 이겁니다.

그럼 "메모리에 있으니 껐다 켜면 다 날아가는 거 아니냐"는 의문이 자연스럽게 따라옵니다. 여기서 흔한 오해를 하나 짚고 가겠습니다.

저는 하드웨어를 좋아해서 Redis를 처음 만졌을 때부터 "얘는 램에 사는 애"라는 그림이 있었는데, 주변을 보면 이 부분을 모른 채 쓰다가 데이터를 날리고 당황하는 경우가 꽤 많았습니다. 그런데 정확히 알아보면, "옛날엔 Redis가 디스크 저장을 안 했다"는 건 사실이 아닙니다. Redis는 아주 오래전부터 RDB 스냅샷(dump.rdb)을 기본값으로 켜놓고 일정 조건마다 디스크에 떨궈 왔어요. 기본 설정이 대략 이렇습니다.

# redis.conf 기본 스냅샷 설정 (예시)
save 900 1      # 900초(15분) 동안 1건 이상 변경되면 저장
save 300 10     # 300초(5분) 동안 10건 이상 변경되면 저장
save 60 10000   # 60초 동안 1만 건 이상 변경되면 저장

그러니까 데이터가 날아간 진짜 이유는 "저장을 아예 안 해서"가 아니라, 저장 방식의 특성을 몰라서인 경우가 대부분이었습니다. Redis 데이터는 평소 메모리에 있다가 위 조건이 맞을 때 주기적으로만 디스크에 떨어집니다. 그래서 스냅샷과 스냅샷 사이에 정전이 나거나, 정상 종료 절차(SHUTDOWN) 없이 프로세스를 강제로 죽이면, 마지막 저장 이후의 데이터가 사라집니다. "데이터가 RAM에 살고 디스크엔 가끔 사본을 남긴다"는 구조를 몰랐던 거죠. 여기에 영속성을 아예 꺼두고 순수 캐시로 쓰던 경우, 그리고 뒤에 나올 Memcached와 헷갈린 경우까지 겹치면서 "Redis는 껐다 켜면 날아간다"는 인상이 퍼진 겁니다.

좀 더 촘촘하게 남기고 싶으면 AOF(Append Only File)라는 방식을 켭니다. 변경 명령을 차곡차곡 파일에 기록하는 방식이라 데이터 손실 창이 훨씬 좁아요. 요즘은 RDB와 AOF를 같이 쓰는 하이브리드 구성도 권장됩니다. 빠른 복구는 RDB가, 촘촘한 보존은 AOF가 맡는 식이죠.

 

📌 헷갈리지 않게

Redis는 "메모리에서 일하고 디스크에 백업하는" 구조입니다.

휘발이냐 아니냐는 설정 나름이에요.

영속성을 잘 켜두면 재시작해도 살아남고,

다 꺼두면 캐시처럼 휘발됩니다.

 

8. Memcached - 순수하게 메모리만

Memcached도 키-값 저장소고 메모리에 데이터를 둡니다. 여기까진 Redis랑 비슷한데, 결정적 차이가 하나 있습니다. Memcached는 디스크 영속성 기능이 아예 없습니다. 설계 자체가 "휘발되는 캐시"예요. 그래서 서버를 재시작하면 담겨 있던 데이터는 깔끔하게 사라집니다.

이건 단점이라기보다 용도가 다른 겁니다. Memcached는 "원본은 어차피 DB에 있고, 나는 그 사본을 잠깐 빠르게 내주는 역할만 한다"는 콘셉트예요. 날아가도 DB에서 다시 채우면 그만이니, 군더더기 없이 캐싱만 단순하게 잘합니다. 데이터 구조도 단순 문자열 위주라 Redis보다 가볍고요. 앞에서 "Redis가 휘발된다"는 오해가 퍼진 데에는, 이 Memcached의 동작과 뒤섞인 영향도 있었을 거라고 봅니다.

 

 

💡 Redis vs Memcached 한 줄

둘 다 메모리 캐시지만,

Redis는 영속성·다양한 자료구조까지 갖춘 다재다능형이고,

Memcached는 순수 휘발 캐시에 집중한 단순형입니다.

 

9. MongoDB - 디스크 기반인데 메모리를 잘 쓴다

MongoDB는 도큐먼트 저장소입니다. 성격으로 보면 의외로 RDB 쪽에 가까워요. 기본 저장 엔진인 WiredTiger가 데이터를 디스크에 영구 저장하기 때문입니다. "NoSQL이니까 메모리에 있겠지?"라고 생각하기 쉬운데, 기본값은 디스크 기반이 맞습니다.

대신 WiredTiger도 RDB의 버퍼 풀처럼 메모리에 캐시를 둬서, 자주 쓰는 데이터를 메모리에 올려놓고 빠르게 처리합니다. 디스크에 안전하게 두면서 메모리로 속도를 챙기는, 우리가 5번에서 본 그 패턴 그대로입니다. 변경 사항도 주기적으로 체크포인트를 찍어 디스크에 반영하고, 압축까지 해서 공간도 아끼죠.

참고로 MongoDB에도 인메모리 전용 엔진(In-Memory) 옵션이 따로 있습니다. 이걸 쓰면 데이터를 전부 메모리에만 두고 디스크엔 안 씁니다. 당연히 재시작하면 날아가고요. 극단적으로 낮은 지연시간이 필요한 특수 상황용이지, 기본은 어디까지나 디스크 기반인 WiredTiger입니다.

10. ClickHouse - 컬럼으로 눕혀서 디스크에 쌓는다

ClickHouse는 분석(OLAP)에 특화된 컬럼 지향 데이터베이스입니다. 데이터는 디스크에 저장합니다. 그런데도 대량 집계 쿼리에서 굉장히 빠른데, 비결은 "어떻게 저장하느냐"에 있습니다.

보통의 RDB는 데이터를 행(row) 단위로 저장합니다. 한 사람의 이름·나이·주소를 한 줄에 붙여 쓰는 식이죠. 주문 하나를 통째로 읽고 쓰는 일엔 이게 유리합니다. 반면 ClickHouse는 열(column) 단위로 눕혀서 저장합니다. 모든 사람의 나이만 한곳에, 주소만 또 한곳에 모아두는 식이에요.

"전체 사용자 평균 나이" 같은 걸 구한다고 해보죠. 행 기반이면 모든 사람의 모든 정보를 다 훑으면서 나이만 골라내야 합니다. 컬럼 기반이면 나이 열만 쭉 읽으면 끝이에요. 안 읽어도 될 데이터를 디스크에서 안 건드리니 그만큼 빠릅니다. 게다가 같은 종류 데이터가 모여 있어 압축도 잘 되고요. 대신 행 하나를 통째로 다루거나 건건이 수정하는 일엔 약합니다. 그래서 ClickHouse는 실시간 거래 처리(OLTP)가 아니라 로그 분석·통계 같은 대량 집계에 씁니다.

11. 덤 - 쿠키와 세션은 어디에 저장될까

여기까지 왔으면 쿠키와 세션도 같은 질문으로 풀립니다. "데이터가 어느 쪽에, 어디에 저장되느냐." 둘이 자주 헷갈리는데, 저장 위치를 보면 단번에 갈립니다.

쿠키 - 브라우저(클라이언트)에 저장

쿠키는 사용자의 브라우저, 즉 클라이언트 쪽에 저장됩니다. 서버가 "이거 갖고 있어" 하고 작은 데이터를 내려보내면 브라우저가 보관하다가, 같은 사이트에 요청할 때마다 그 쿠키를 같이 딸려 보냅니다. 그래서 서버는 "아, 아까 그 사용자구나" 하고 알아봅니다.

- 크기가 작습니다. 쿠키 하나에 보통 4KB 정도가 한계예요.
- 만료 시점을 지정한 쿠키는 디스크에 파일로 저장돼 브라우저를 꺼도 남습니다(로그인 유지 같은 것).
- 만료를 안 정한 세션 쿠키는 메모리에만 있다가 브라우저를 닫으면 사라집니다.
- 클라이언트에 있으니 사용자가 열어볼 수도, 조작할 수도 있습니다. 그래서 민감한 정보를 그냥 담으면 안 됩니다.

세션 - 서버에 저장

세션은 반대로 데이터 본체가 서버에 저장됩니다. 서버가 사용자별로 정보를 쥐고 있고, 클라이언트에는 "너를 알아볼 열쇠"인 세션 ID만 쿠키에 담아 내려보냅니다. 그러니까 흔히 보는 흐름은 이렇습니다. 실제 데이터는 서버에, 그 데이터를 가리키는 ID는 쿠키에 담겨 클라이언트와 서버를 오갑니다.

그럼 서버는 세션 데이터를 정확히 어디에 둘까요? 여기서 오늘 글이 한 바퀴 돌아 제자리로 옵니다. 서버 메모리에 두면 빠르지만, 서버를 재시작하면 날아가고 서버가 여러 대면 공유가 안 됩니다. 그래서 실무에선 세션을 외부 저장소에 빼두는 일이 흔한데, 그 단골 후보가 바로 Redis예요. 빠르면서도(메모리 기반) 영속성과 공유가 되니까요. "세션을 Redis에 저장한다"는 말이 바로 이 얘기입니다.

 

 

📌 쿠키와 세션, 한 줄 정리

쿠키는 클라이언트(브라우저)에, 세션은 서버에 저장됩니다.

쿠키에는 보통 "세션 ID"만 담겨 둘을 이어주는 열쇠 역할을 하고,

정작 무거운 데이터는 서버(흔히 Redis 같은 곳)에 있습니다.

 

12. 한눈에 비교

대상	주 저장 위치	영속성	주 용도
MySQL·MariaDB	디스크(+버퍼 풀 캐시)	있음	범용 관계형 데이터
PostgreSQL·Oracle	디스크(+공유 메모리 캐시)	있음	복잡한 트랜잭션·기업용
Redis	메모리(+디스크 백업)	설정에 따라	캐시·세션·실시간 처리
Memcached	메모리만	없음(휘발)	단순 캐시
MongoDB	디스크(+캐시, 인메모리 옵션)	있음(기본)	유연한 문서형 데이터
ClickHouse	디스크(컬럼 단위)	있음	대량 집계·분석(OLAP)
쿠키	클라이언트(브라우저)	종류에 따라	사용자 식별·상태 유지
세션	서버(메모리/외부 저장소)	저장소에 따라	로그인 상태 등 보관

13. 그래서 뭘 언제 쓰나

저장 위치를 알았으니 선택 기준도 자연스럽게 따라옵니다. 정답은 없지만, 대략적인 감은 이렇습니다.

- 정합성이 중요한 핵심 데이터(주문, 결제, 회원)는 RDB로 갑니다. 트랜잭션과 관계 표현이 강하니까요. 가벼운 서비스면 MySQL·MariaDB, 복잡한 쿼리나 기능이 필요하면 PostgreSQL, 기업용 대형 시스템이면 Oracle을 고려하는 식입니다.
- 빠른 캐시나 세션, 실시간 순위표가 필요하면 Redis가 무난합니다. 날아가도 그만인 정말 단순한 캐시면 Memcached도 선택지고요.
- 스키마가 자주 바뀌거나 문서 형태 데이터가 많으면 MongoDB가 편합니다.
- 로그가 산더미처럼 쌓이고 그걸 집계·분석해야 하면 ClickHouse 같은 컬럼 지향 DB가 빛을 봅니다.

다만 한 가지 단서는 달아두고 싶습니다. 이건 어디까지나 2026년 현재, 그리고 일반적인 경우의 기준입니다. 실제로는 서비스 규모, 팀이 익숙한 기술, 운영 비용까지 얽혀서 결정되거든요. 그리고 요즘은 클라우드 매니지드 서비스가 워낙 잘 돼 있어서, 직접 설치하고 튜닝하던 시절과 또 다릅니다. 도구의 성격을 이해한 다음엔, 결국 우리 상황에 맞춰 고르는 게 맞다고 봅니다.

14. 마무리

길게 돌아왔지만 처음 그 한 문장으로 다시 모입니다.

 

"이 데이터가 지금 어디에 놓여 있는가."

 

CPU 캐시·메모리·디스크라는 세 층, 그리고 속도와 영속성의 트레이드오프.

 

이 그림 하나만 머릿속에 있으면

Redis가 왜 빠른지,

MySQL이 왜 디스크 기반인데 안 느린지,

세션이 왜 Redis로 빠지는지가 따로 외울 거 없이 줄줄이 이어집니다.

 

저는 컴퓨터를 손으로 뜯어본 경험 덕에 이 그림이 일찍 잡혔는데,

꼭 하드웨어를 만져봐야 아는 건 아니라고 생각합니다.

 

"얘는 작업대에 사는 애, 얘는 창고에 사는 애"

정도로만 구분해도 시작으로는 충분해요.

 

그다음은 직접 설치해보고,

껐다 켜보고,

데이터가 남나 날아가나 확인해보면 몸으로 익습니다.

저장소를 고를 일이 생겼을 때,

 

이 글이 "그래서 얘는 어디에 저장하더라?"를 떠올리는 출발점이 되면 좋겠습니다.

📚 함께 보면 좋은 글

질문이 엉성하면 답도 없다 - 스택오버플로우가 바꾼 개발자의 사고방식

웹개발자 MBTI 직무 추천 — 프론트엔드·백엔드·DBA 성향 궁합

리눅스 계보도 정복하기: 유닉스에서 시작된 오픈소스 언어의 거대한 역사

우분투(Ubuntu)는 왜 운영체제의 표준이 되었나? 이름 속에 숨겨진 인문학적 성공 비결