왜 Redis는 PostgreSQL 이후에 배워야 할까?

주 저장소와 보조 저장소의 차이

데이터베이스를 집에 비유해 봅시다. PostgreSQL은 튼튼한 금고와 같습니다. 속도는 조금 느릴 수 있지만 정전이 되거나 사고가 나도 안의 내용물이 안전하게 보존됩니다. 반면 Redis는 책상 위에 놓인 작업용 화이트보드입니다. 바로 쓰고 지우기에는 엄청나게 빠르지만, 누군가 보드를 닦아버리거나 정전이 발생하면 적혀있던 내용이 날아갈 위험이 있습니다.

이러한 차이 때문에 우리는 데이터를 성격에 따라 분리해서 저장해야 합니다. 주 저장소(Primary Store)는 데이터의 영구적인 보존과 무결성을 책임집니다. 반면 보조 저장소(Secondary Store)는 빠른 접근과 임시 저장을 담당하죠.

메모리 기반 데이터베이스의 한계

Redis는 데이터를 하드디스크가 아닌 RAM(Random Access Memory)에 저장합니다. RAM은 CPU와 매우 가깝게 동작하기 때문에 디스크보다 압도적으로 빠르죠. 하지만 RAM은 디스크에 비해 가격이 매우 비싸고 용량이 적습니다.

따라서 모든 데이터를 Redis에 넣으려고 하면 막대한 인프라 비용이 발생합니다. 이것이 바로 Redis를 메인 데이터베이스로 사용하지 않는 또 다른 현실적인 이유입니다.

왜 PostgreSQL 이후에 배워야 할까?

Redis는 훌륭한 도구이지만, 그 자체만으로는 온전한 서비스를 구성하기 어렵습니다. 만약 데이터가 날아갔을 때 언제든 복구할 수 있는 "원본"이 없다면, Redis가 재시작되는 순간 서비스 전체의 데이터가 증발하는 대형 사고가 발생하게 됩니다.

그래서 안전한 원본 저장소를 다루는 법을 먼저 깨우친 후에야, 그 원본을 보호하면서 속도를 끌어올리기 위한 보조 도구로서 Redis를 올바르게 활용할 수 있습니다.

async function getUserProfile(userId) {
  // 1. 먼저 빠른 Redis(보조 저장소)에서 데이터를 찾아본다
  const cachedProfile = await redis.get(`user:${userId}`);
  
  if (cachedProfile) {
    return JSON.parse(cachedProfile); // 빠르게 바로 응답!
  }
  
  // 2. 만약 Redis에 없다면, 느리지만 확실한 PostgreSQL(주 저장소)에서 원본을 조회한다
  const dbProfile = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
  
  // 3. 다음 조회를 위해 원본 데이터를 Redis에 복사해둔다
  await redis.set(`user:${userId}`, JSON.stringify(dbProfile));
  
  return dbProfile;
}

위 코드처럼 Redis는 항상 뒤에 든든한 주 저장소를 두고, 이를 보조하는 형태로 사용될 때 가장 빛을 발합니다. 이러한 협력 패턴을 "캐시 어사이드(Cache Aside)" 방식이라고 부르며, 실무에서 가장 흔하게 접하는 구조입니다.

Redis는 무적의 만능 도구가 아니다

초보 개발자들은 Redis의 엄청난 속도에 매료된 나머지 모든 데이터를 Redis에 넣고 싶어하는 유혹에 빠지기 쉽습니다. 하지만 아키텍처 설계에서 만능 도구란 없습니다. 어떤 데이터를 디스크에 넣고 어떤 데이터를 메모리에 넣을지 선별하는 안목을 기르는 것이 이 강의의 핵심 목표입니다.