게시판 원본 데이터를 Redis에 넣으면 안 되는 이유

메모리는 영원하지 않다 (휘발성의 공포)

가장 치명적인 문제는 Redis가 메모리(RAM) 기반 저장소라는 사실입니다. 컴퓨터를 사용하다가 저장하지 않은 문서가 정전으로 날아간 경험이 있으신가요? Redis도 기본적으로 이와 똑같은 약점을 가지고 있습니다.

게시판의 '게시글 원본'이나 '댓글'은 서비스의 자산입니다. 만약 Redis 서버가 예기치 않게 재시작되어 이틀 동안 작성된 모든 게시글이 날아갔다고 상상해 보세요. 사용자의 신뢰는 바닥으로 떨어질 것입니다.

인메모리 백업 옵션의 한계

물론 Redis도 만약의 사태를 대비해 디스크에 데이터를 백업하는 RDB(스냅샷)와 AOF(로그) 기능을 제공합니다. 하지만 이는 어디까지나 재난 복구를 위한 최소한의 안전장치일 뿐, 처음부터 디스크 영속성을 고려하여 치밀하게 설계된 RDBMS(PostgreSQL 등)의 트랜잭션 안정성을 따라갈 수는 없습니다. 백업 주기에 따라 1~5분 사이의 최근 데이터는 여전히 날아갈 위험이 존재합니다.

용량과 비용의 현실적인 벽

데이터를 보관할 때 성능만큼이나 중요한 것이 경제성입니다. RAM은 SSD나 하드디스크에 비해 압도적으로 비쌉니다.

게시글은 시간이 지날수록 끝없이 누적되는 성질을 가집니다. 이를 모두 값비싼 RAM에 올려둔다면, 서비스가 성장할수록 눈덩이처럼 불어나는 서버 비용을 감당할 수 없게 됩니다.

안전하게 게시판 데이터를 다루는 법

그렇다면 빠른 게시판을 만들기 위해서는 어떻게 해야 할까요? 정답은 원본의 영구 보존과 복사본의 빠른 제공을 분리하는 것입니다.

// 나쁜 예: Redis에만 게시글 저장 (위험!)
async function createPostBad(title, content) {
  const postId = generateId();
  // 데이터가 Redis에만 존재. 서버 재시작 시 영구 삭제됨
  await redis.set(`post:${postId}`, JSON.stringify({ title, content })); 
}

// 좋은 예: PostgreSQL에 저장 후 Redis로 캐싱 (안전!)
async function createPostGood(title, content) {
  // 1. 디스크 기반의 안전한 DB에 원본을 확실히 저장
  const newPost = await db.query(
    'INSERT INTO posts (title, content) VALUES ($1, $2) RETURNING *',
    [title, content]
  );
  
  // 2. 빠른 조회를 위해 Redis에 복사본(캐시) 업데이트
  await redis.set(`post:${newPost.id}`, JSON.stringify(newPost));
  
  return newPost;
}

이처럼 항상 "데이터베이스에 먼저 기록하고, Redis를 덮어씌우는" 순서를 지켜야 합니다. 만약 Redis 캐싱 과정에서 에러가 발생해도, 사용자는 데이터베이스에 저장된 원본을 통해 여전히 서비스를 이용할 수 있습니다.