1. 개요

Redis는 단순히 'Key-Value 저장소'가 아닙니다. 내부적으로 다양한 데이터 구조를 지원하는 **'Data Structures Server'**입니다. 데이터 엔지니어링 관점에서 Redis를 다룬다는 것은, 특정 비즈니스 요구사항에 대해 **'메모리 점유율을 최소화하면서도 O(1)의 성능을 보장하는 자료형'**을 선택하고 설계하는 과정을 의미합니다.

본 글에서는 Redis의 5대 핵심 자료형을 Deep Dive 하여, 실무에서 마주치는 성능 병목 현상을 어떻게 구조적으로 해결할 수 있는지 분석합니다.

2. 문제 정의: "전부 String으로 저장하면 안 되나요?"

많은 입문자가 JSON.stringify()를 통해 모든 객체를 Strings 타입에 밀어 넣습니다. 하지만 이러한 접근은 대규모 시스템에서 두 가지 치명적인 병목을 만듭니다.

2.1 수정 시의 높은 I/O 비용 (Read-Modify-Write)

100개의 필드를 가진 유저 객체에서 '마지막 접속 시간' 필드 하나만 바꾸려 해도, 전체 JSON을 읽어와 파싱하고 다시 덮어써야 합니다. 이는 불필요한 네트워크 트래픽과 CPU 연산을 유발합니다.

2.2 메모리 단편화와 오버헤드

데이터의 구조를 무시한 채 String으로만 저장하면, Redis 내부의 최적화 알고리즘(예: ziplist 인코딩)을 활용할 기회를 상실하게 되어 동일한 데이터라도 수 배 이상의 메모리를 점유하게 됩니다.

3. 해결책: 5대 자료형의 내부 메커니즘과 실무 전략

Redis는 데이터 크기와 특성에 따라 내부 저장 방식을 동적으로 변경합니다.

3.1 Hashes: 객체 저장의 최적화 (Memory Saver)

Hashes는 필드-값 쌍을 저장하는 구조입니다.

• 내부 원리: 데이터 개수가 적으면 ziplist(메모리 압축 구조)를 사용하다가, 임계치를 넘으면 hashtable로 전환됩니다.
• 실무 전략: 사용자 프로필이나 설정값처럼 필드가 여러 개인 객체 저장 시 Strings보다 월등히 적은 메모리를 사용하며, 특정 필드만 원자적으로 수정(HSET)할 수 있습니다.

3.2 Lists: 메시지 큐와 타임라인 (The Sequence)

• 내부 원리: 양방향 연결 리스트인 linkedlist와 ziplist의 장점을 합친 quicklist 구조로 구현되어 있습니다.
• 실무 전략: 양 끝에서의 삽입/삭제(LPUSH/RPOP)는 **O(1)**로 매우 빠릅니다. 최근 게시물 피드나 작업 큐(Job Queue) 구현에 최적입니다.