Redis 개요 및 설치, 환경설정

• 1. Redis 개요
  • 1.1 Redis의 등장 배경
  • 1.2 Redis의 개발 목적
  • 1.3 Redis의 핵심 특징
  • 1.4 Redis의 장단점
  • 1.5 Redis의 데이터 영속성 (Persistence) 구조
  • 1.6 주요 활용 사례 (Use Cases)
  • 1.7 현재 IT 환경에서의 적합성 및 부적합성 분석
• 2. Redis 설치
  • 2.1 Linux 환경에서 Redis 설치하기 (Ubuntu 기준)
  • 2.2 Windows 환경에서 Redis 설치하기
• 3. Redis 환경 설정

1. Redis 개요

• Redis(Remote Dictionary Server)
  • 고성능 키-값(Key-Value) 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 인메모리(In-Memory) 데이터 구조 저장소
  • 데이터베이스, 캐시(Cache), 메시지 브로커(Message Broker) 등으로 널리 사용됨
  • 현업에서 대규모 트래픽을 처리하고 시스템의 응답 속도를 극대화하기 위해 필수적으로 도입하는 기술 중 하나

1.1 Redis의 등장 배경

• Redis는 특정 개발자가 자신이 운영하던 서비스의 인프라 한계를 극복하기 위해 직접 개발한 ‘필요(Necessity)’에 의해 탄생한 기술
  • 2009년, 이탈리아의 개발자 살바토레 산필리포(Salvatore Sanfilippo, 별칭 Antirez)에 의해 처음 개발됨

    • 당시 그는 ‘LLOOGG’라는 실시간 웹 로그 분석 서비스를 운영 중

    • 기존 RDBMS(관계형 데이터베이스)의 한계
      • 실시간 데이터 처리의 병목:
        • LLOOGG 서비스는 각 웹사이트의 방문자 페이지 뷰, 실시간 카운터, 최근 방문자 목록 등을 실시간으로 보여줌
      • 디스크 I/O의 한계:
        • LLOOGG 서비스는 데이터 저장을 위해 대표적인 오픈소스 RDBMS인 MySQL을 사용함
        • 사용자가 늘어남에 따라 초당 수많은 쓰기/읽기 요청이 디스크 기반의 MySQL로 집중
        • 디스크 I/O 병목 현상으로 인해 서비스가 감당할 수 없을 정도로 느려짐
    • 기존 캐시 솔루션(Memcached)의 아쉬움
      • 당시에도 메모리 기반의 캐시 시스템인 Memcached가 존재
        • Memcached는 단순히 문자열(String) 타입만 지원
        • ‘최근 방문자 목록 10개’나 ‘실시간 순위’ 같은 복잡한 정렬 데이터를 다루려면,
          • 애플리케이션 단에서 데이터를 가져와 파싱하고
          • 다시 정렬해서 넣어야 하는 번거로움과
          • 성능 저하가 뒤따름
    • “RDBMS보다 압도적으로 빠르면서, 단순 캐시를 넘어 다양한 데이터 구조를 메모리 상에서 안전하게 처리할 수 있는 저장소가 없을까?” 고민
      • 결국 직접 새로운 솔루션을 개발하기로 결심 🡲 Redis의 시작

1.2 Redis의 개발 목적

• Redis(Remote Dictionary Server)라는 이름 자체가 “원격 딕셔너리(Key-Value) 서버”를 의미

• 디스크가 아닌 메모리 중심의 초고속 데이터 처리
  • 데이터를 메모리(RAM)에 상주시킴으로써 디스크 읽기/쓰기 속도의 한계를 완전히 극복하는 것이 최우선 목적
  • 초당 수십만 건의 요청도 마이크로초 단위로 즉각 응답할 수 있는 고성능 저장소를 지향함
• 복잡한 메모리 내 연산의 오버헤드 감소 (다양한 데이터 구조 지원)
  • 애플리케이션 개발자가 메모리 내에서 리스트, 셋, 정렬된 집합(Sorted Set) 등을 직접 구현하고 동기화(Locking)하느라 고생하지 않도록,
  • 데이터베이스 엔진 자체가 고도화된 추상 데이터 구조를 원자적(Atomic)으로 지원하는 것을 목적으로 함
• 휘발성 극복을 위한 영속성(Persistence) 확보
  • 인메모리 저장소의 최대 약점은 ‘서버가 꺼지면 데이터가 날아간다’는 점
  • Redis는 단순 캐시용 데이터뿐만 아니라 서비스 운영에 필요한 중요 데이터도 저장할 수 있도록,
    • 주기적으로 디스크에 백업(RDB)
    • 로그를 남기는(AOF) 기능을 내장
    • ‘안전하게 지속 가능한 인메모리 DB’를 목표로 함
• 수평적 확장성과 고가용성 제공
  • 단일 서버의 메모리 용량 한계를 극복하고 대규모 분산 환경에서도 중단 없이 서비스를 제공할 수 있도록,
    • 마스터-슬레이브 복제 구조와
    • 샤딩(Sharding) 메커니즘을
    • 쉽게 구현할 수 있는 아키텍처를 목표로 함

• Redis는 “실시간 대용량 트래픽 처리에 무기력한 RDBMS의 디스크 병목을 해결”하고, “기존 캐시 시스템의 기능적 한계를 뛰어넘어 개발자가 원하는 복잡한 데이터 구조를 메모리 상에서 초고속으로, 그리고 안전하게 처리”하기 위해 탄생한 목적 기반의 저장소

1.3 Redis의 핵심 특징

• Redis를 한 줄로 요약하면 “메모리를 사용하는, 초고속 만능 열쇠-값 저장소”

• 인메모리(In-Memory) 아키텍처
  • 모든 것은 RAM에 산다! 🡲 모든 데이터를 컴퓨터의 주기억장치(RAM)에 저장하고 처리함
  • 디스크 I/O가 발생하지 않기 때문에 마이크로초(Microseconds) 단위의 초고속 읽기/쓰기 성능을 보장함

  • 일반적인 데이터베이스(MySQL, Oracle 등)는 모든 데이터를 하드디스크(SSD/HDD)에 저장함
    • 그래서 데이터를 읽고 쓸 때 디스크가 움직이는 물리적인 시간이 걸림
  • Redis는 모든 데이터를 컴퓨터의 주기억장치(RAM)에 올려두고 처리함
    • RAM은 디스크보다 수백~수천 배 빠르기 때문에, 모든 명령이 밀리초(ms)가 아닌 마이크로초(\(\mu s\)) 단위로 즉시 처리됨

• 싱글 스레드(Single-Threaded) 기반 동작
  • Redis는 기본적으로 명령어를 처리할 때 단 하나의 스레드(일꾼)만 사용

  • 일꾼이 여러 명이면 서로 먼저 하겠다고 싸우는 문제(Race Condition, Deadlock)가 생겨 아키텍처가 복잡해짐
  • Redis는 한 명의 일꾼이 요청이 들어온 순서대로 한 줄로 서서 초고속으로 처리하기 때문에 데이터가 꼬일 일이 없고 내부 구조가 매우 단순함

  • 핵심 명령어를 처리할 때 싱글 스레드 event loop 방식을 사용
    • 장점:
      • 멀티스레드 환경에서 발생하는 Context Switching 비용이 없음
      • 교착 상태(Deadlock)나 Race Condition 같은 동기화 문제를 신경 쓰지 않아도 됨 🡲 아키텍처가 단순하고 빠름
    • 주의점:
      • 한 번에 하나의 명령어만 처리 🡲 실행 시간이 긴 명령어(\(O(N)\) 등)를 실행하면 전체 서버가 대기 상태에 빠지는 ‘Bottleneck’이 발생할 수 있음
        • 만약 10초가 걸리는 무거운 명령을 내리면 그 뒤에 서 있는 수만 개의 가벼운 명령들이 모두 대기해야 함 🡲 Redis에서는 ‘방 전체를 다 뒤져라’ 같은 명령은 금기
  • Redis 6.0부터는 네트워크 입출력 등 일부 부가 작업에 멀티스레드가 도입
    • 그러나 실제 명령어 실행은 여전히 싱글 스레드로 처리됨
• 풍부한 데이터 구조(Data Structures)

  • Redis는 관계형 DB처럼 표(Table)나 행(Row), 열(Column)의 개념이 없음
  • 오직 ‘열쇠(Key)’와 ‘값(Value)’이라는 직관적인 쌍으로만 움직임

  • 단순히 문자열(String)만 지원하는 일반적인 Key-Value 저장소(예: Memcached)와 달리,
  • 다양한 고도화된 데이터 구조를 기본적으로 제공함
    • Strings: 가장 기본적인 키-값 쌍 (텍스트, 이진 데이터, JPEG 이미지 등 저장 가능)
    • Lists: Linked List 형태의 문자열 배열 (Queue, Stack 구현에 용이)
    • Sets: 중복되지 않는 문자열의 무순위 집합 (교집합, 합집합 등 집합 연산 지원)
    • Sorted Sets (ZSet): 가중치(Score)를 부여하여 정렬된 상태를 유지하는 집합 (실시간 랭킹 시스템에 최적)
    • Hashes: 필드와 값으로 구성된 맵 구조 (객체 표현에 적합)
    • Bitmaps / HyperLogLogs: 대규모 데이터의 비트 단위 연산 및 카디널리티(중복 없는 개수) 추정에 사용
    • Geospatial Indexes: 위도/경도 기반의 위치 데이터 저장 및 반경 검색

1.4 Redis의 장단점

• 장점
  • 압도적인 성능:
    • 초당 수십만 건 이상의 읽기 및 쓰기 작업을 처리할 수 있음 🡲 트래픽 폭주 시 데이터베이스의 부하를 줄여주는 캐싱 계층으로 최고의 효율 발휘
  • 개발 생산성 및 원자성(Atomicity):
    • 다양한 데이터 구조를 내장하고 있음 🡲 애플리케이션 단에서 복잡하게 구현해야 할 로직을 Redis 자체 명령어로 간단히 해결할 수 있음
    • Redis의 명령어는 원자적으로 실행되므로 데이터 정합성을 유지하기 쉬움
  • 영속성(Persistence) 지원:
    • 인메모리 저장소임에도 불구하고 데이터를 디스크에 저장할 수 있는 메커니즘을 제공 🡲 서버가 다운되더라도 데이터를 복구할 수 있음
  • 만료 시간(TTL) 설정 가능:
    • 키값마다 유지 시간(Time To Live)을 설정할 수 있음 🡲 세션 관리나 인증 토큰 등 임시 데이터 관리가 매우 수월함
• 단점 및 한계
  • 메모리 비용의 한계:
    • RAM은 디스크(SSD/HDD)에 비해 저장 용량당 비용이 훨씬 비쌈
    • 따라서 대용량 데이터를 무작정 Redis에 저장하기에는 비용적 부담이 큼
  • 메모리 파편화(Memory Fragmentation):
    • 데이터를 자주 쓰고 지우는 과정에서 메모리 파편화가 발생할 수 있음
    • 이로 인해 실제 저장된 데이터보다 더 많은 메모리를 차지하게 되어 시스템이 다운(OOM: Out of Memory)될 수 있음
  • 싱글 스레드의 제약:
    • 전체 데이터를 조회하는 KEYS * 같은 무거운 명령어를 상용 환경에서 실행하면 순간적으로 전체 서비스가 마비될 수 있음
    • 명령어 사용에 주의가 필요함
  • 복구 메커니즘의 한계:
    • 디스크 저장 기능을 제공하긴 하지만, 실시간으로 완벽하게 동기화하는 데는 성능 저하가 따름
    • 어느 정도의 데이터 유실 가능성을 감안해야 함
    • RDBMS 수준의 강력한 ACID 트랜잭션 보장은 어려움

1.5 Redis의 데이터 영속성 (Persistence) 구조

• Redis는 메모리 휘발성을 극복하기 위해 두 가지 방식의 디스크 저장 메커니즘을 제공 🡲 보통 두 방식을 혼합하여 사용함

1. RDB (Redis Database) - 스냅샷 방식
   • 특정 시간 격차(예: 5분마다)를 두고 메모리의 데이터 전체를 바이너리 파일로 디스크에 덤프
   • 장점: 파일 사이즈가 작고 복구 속도가 빠름
   • 단점: 스냅샷을 찍은 이후 다음 스냅샷 전까지 발생한 데이터는 서버 다운 시 유실됨
2. AOF (Append Only File) - 로그 방식
   • 데이터가 변경되는 모든 쓰기 명령어를 실시간으로 로그 파일에 기록
   • 장점: 데이터 유실이 거의 없음
   • 단점: 로그 파일이 계속 커짐 🡲 서버 재시작 시 로그를 처음부터 다시 실행해야 하므로 복구 속도가 느림

1.6 주요 활용 사례 (Use Cases)

• 캐싱(Caching):
  • 데이터베이스(RDBMS)의 조회 결과를 캐싱하여 웹 애플리케이션의 응답 속도를 개선하고 DB 부하를 경감함
• 세션 스토어(Session Store):
  • 사용자의 로그인 세션 상태나 장바구니 정보 등을 저장
  • 멀티 서버 환경에서 세션 정합성을 유지하는 데 유용함
• 실시간 랭킹 보드 (Leaderboard):
  • Sorted Set(ZSet) 구조를 활용하여 게임 스코어, 포털 인기 검색어 등의 랭킹을 실시간으로 업데이트하고 조회
• 메시지 큐 / Pub-Sub:
  • List 구조를 활용한 작업 큐(Job Queue)나, 내장된 Publish/Subscribe 기능을 활용 🡲 마이크로서비스(MSA) 간의 가벼운 메시지 브로커 역할을 수행
• 속도 제한기(Rate Limiter):
  • IP나 API 키별로 일정 시간 동안의 요청 횟수를 제한(API Throttling)할 때 문자열과 TTL 기능을 활용함

1.7 현재 IT 환경에서의 적합성 및 부적합성 분석

• 현대 IT 환경: 초고가용성, 마이크로서비스 아키텍처(MSA), 실시간 데이터 스트리밍, 그리고 생성형 AI(GenAI)로 대변

• 현대 IT 환경에 ‘적합’한 부분
  • MSA 환경의 글로벌 세션 및 상태 공유 스토어
    • MSA는 서비스를 잘게 쪼개어 무상태(Stateless)로 운영하는 것이 핵심
    • 중앙집중형 인메모리 저장소
      • 개별 서버에 세션을 저장할 수 없으므로
      • 모든 마이크로서비스가 공통으로 빠르게 접근할 수 있는 중앙집중형 인메모리 저장소가 필수적
    • Redis는 초당 수십만 건의 분산 세션 및 상태 데이터를 마이크로초 단위로 처리하여 복잡한 서비스 간 정합성을 완벽히 지원함
  • 실시간 이벤트 스트리밍 및 Pub/Sub 메커니즘
    • 현대 웹/앱은 실시간 알림, 라이브 채팅, 실시간 위치 추적 등 실시간성이 기본
    • Redis의 Streams 데이터 구조와 Pub/Sub 기능
      • 무거운 메시지 브로커(Kafka 등)를 도입하기 부담스러운 경량 아키텍처나 비동기 작업 큐(Job Queue) 구현에
      • 비용 대비 최고 효율의 성능을 제공
  • API Throttling 및 속도 제한(Rate Limiter)
    • 수많은 서드파티 API와 클라우드 서비스가 연결된 현재 환경에서는 무분별한 요청을 막는 트래픽 제어가 필수적
    • Redis는 문자열 데이터의 원자적(Atomic) 연산(예: INCR)과 만료 시간(TTL) 설정을 조합
      • 디스크 DB 부하 없이 완벽한 실시간 속도 제한기 역할을 수행함
• 현대 IT 환경에 ‘부적합’한 부분
  • 클라우드 환경에서의 폭발적인 비용 부담 (Scale-Up의 한계)
    • 클라우드 인프라(AWS, Azure, GCP)에서 RAM은 SSD나 HDD 디스크에 비해 기하급수적으로 비싸짐
    • 테라바이트(TB) 단위 이상의 대규모 빅데이터를 모두 Redis에 올리는 것은 비용적으로 불가능에 가까움
    • 대용량 처리를 위해 Redis 클러스터를 확장(Scale-Out)하더라도, 메모리 집약적인 특성 때문에 인프라 유지 비용이 급격히 상승함
  • 싱글 스레드 아키텍처로 인한 ‘CPU 집약적 작업’의 병목
    • Redis의 핵심 엔진은 싱글 스레드로 명령을 처리 🡲 현대의 멀티코어 CPU 환경을 온전히 활용하지 못한다는 구조적 한계
    • 데이터셋 전체를 스캔하는 무거운 쿼리나 복잡한 데이터 연산이 단 하나라도 유입되면,
      • 후속 모든 요청이 대기 상태(Blocking)에 빠져 서비스 전체가 일시 마비되는 취약점을 가짐
  • 엄격한 ACID 트랜잭션이 필요한 마스터 데이터 저장
    • 금융 거래나 결제 시스템처럼 철저한 데이터 유실 방지와 롤백(Rollback), 완벽한 일관성이 보장되어야 하는 영역에는 부적합
    • Redis도 영속성(RDB, AOF)과 트랜잭션(MULTI/EXEC)을 지원하긴 하지만,
      • 인메모리의 고속 처리를 위해 완벽한 디스크 동기화를 희생하는 구조
      • 시스템 장애 시 미세한 데이터 유실 가능성을 배제할 수 없음
• 초기 개발 목적 vs 현재의 활용 방향 변화

비교 항목	초기 개발 목적 (2009년 탄생 당시)	현재의 활용 방향 및 분야 (2026년 현재)
기본 역할	RDBMS(MySQL)의 디스크 병목을 돕는 보조용 '캐시 스토어'	캐시, 메시지 브로커, 검색 엔진, AI 메모리를 아우르는 '멀티 모델 데이터 플랫폼'
핵심 데이터	단순 문자열 카운터, 최근 방문자 리스트, 웹 로그 데이터	세션 관리, JSON 문서, 시계열(Time-Series) 데이터, AI 벡터 임베딩(Vector Embedding)
포지셔닝	단일 서버 기반의 가볍고 빠른 오픈소스 유틸리티	대규모 엔터프라이즈 클러스터, 하이브리드 클라우드 핵심 데이터 인프라

2. Redis 설치

• Redis는 공식적으로 Linux 환경을 기반으로 개발 및 최적화되어 있음
• Windows 환경에서는 Docker를 사용하거나 Linux용 Windows 하위 시스템(WSL2)을 활용하는 것이 글로벌 표준 권장 사항

2.1 Linux 환경에서 Redis 설치하기 (Ubuntu 기준)

• Linux 환경에서는 APT 패키지 관리자를 사용하여 공식 Redis 저장소로부터 안전하게 최신 버전을 설치하는 것이 가장 좋음

• 1단계: 시스템 패키지 업데이트 및 필수 의존성 설치

  • 터미널을 열고 패키지 목록을 최신 상태로 업데이트한 뒤, 보안 통신을 위한 필수 패키지를 설치

      sudo apt update
      sudo apt install lsb-release curl gpg -y
    

• 2단계: 공식 Redis APT 저장소 키 및 URL 등록

  • 우분투 기본 저장소에 있는 Redis는 버전이 낮을 수 있으므로, 공식 Redis 래포지토리를 서명 키와 함께 추가

      # 공식 GPG 키 다운로드 및 변환
      curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
    
      # APT 소스 리스트에 Redis 저장소 추가
      echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb noble main" | sudo tee /etc/apt/sources.list.d/redis.list
    
      # 저장소 반영을 위한 업데이트
      sudo apt update
    

• 3단계: Redis 설치 실행

    sudo apt install redis -y
  

• 4단계: 서비스 활성화 및 동작 확인

  • 설치가 완료되면 백그라운드 서비스(systemd)로 등록하고 정상 작동하는지 확인

      # Redis 서비스 시작 및 부팅 시 자동 시작 설정
      sudo systemctl start redis-server
      sudo systemctl enable redis-server
    
      # 서비스 상태 확인 (Active: active (running) 확인)
      sudo systemctl status redis-server
    

• 5단계: Redis CLI 접속 테스트

    redis-cli
  

  • 접속 후 터미널이 127.0.0.1:6379> 형태로 바뀌면 ping 입력 🡲 서버에서 PONG이라고 응답하면 정상적으로 설치 및 구동된 것

2.2 Windows 환경에서 Redis 설치하기

• Docker 활용
  • 현업 개발 환경에서 가장 확장성이 높고 간편한 Docker 기반 설치를 우선 권장

  • Windows에 Docker Desktop이 설치되어 있다면 명령 한 줄로 가장 깔끔하게 독립된 Redis 환경을 구성할 수 있음

  • 1단계: PowerShell 또는 CMD를 관리자 권한으로 실행

  • 2단계: 다음 명령어를 입력하여 최신 Redis 컨테이너를 다운로드하고 실행

      docker run --name my-redis -p 6379:6379 -d redis:latest
    

    • --name my-redis: 컨테이너 이름을 my-redis로 지정
    • -p 6379:6379: Windows 호스트의 6379 포트와 컨테이너 내부의 6379 포트를 연결
    • -d: 백그라운드 모드(Detached)로 실행

  • 3단계: 실행 중인 Redis CLI 접속하기

      docker exec -it my-redis redis-cli
    

    • ping을 입력해 PONG 반응을 확인
• WSL2 (Windows Subsystem for Linux) 활용
  • 1단계: WSL2 및 Ubuntu 설치 (이미 설치되어 있다면 패스)

    • PowerShell에서 아래 명령어를 실행하고 컴퓨터를 재부팅

        wsl --install
      

      -재부팅 후 Ubuntu 초기 계정(ID/Password) 설정 완료

  • 2단계: WSL 터미널에서 Linux 설치 프로세스 진행
    • 설치된 Ubuntu 터미널을 실행한 뒤,
    • [1. Linux 환경에서 Redis 설치하기]의 1단계부터 3단계까지의 과정을 그대로 수행
  • 3단계: WSL 환경에서의 서비스 실행 규칙

    • WSL2는 systemd 구조가 기본적으로 비활성화되어 있는 경우가 많음 🡲 서비스 시작 시 다음 명령어를 사용

        sudo service redis-server start
      

      • 이후 redis-cli를 입력해 연동을 확인
      • WSL2 내부에서 뜬 Redis는 Windows 호스트(localhost:6379)와도 포트가 공유됨 🡲 Windows 애플리케이션 개발 시 그대로 연결 가능

3. Redis 환경 설정

• 필수 보안 및 외부 접속 설정 (공통)
  • 기본적으로 Redis는 보안을 위해 127.0.0.1(로컬호스트) 내부 접속만 허용하며 패스워드가 걸려있지 않음
  • 다른 서버나 대역에서 Redis에 접속해야 하거나 최소한의 보안을 갖추려면 설정 파일을 수정해야 함

• 설정 파일 위치: /etc/redis/redis.conf (Linux/WSL 기준)

    sudo nano /etc/redis/redis.conf
  

  1. 외부 접속 허용 (원격 접속이 필요한 경우만 변경):
     • bind 127.0.0.1 -::1 부분을 찾아서 bind 0.0.0.0으로 변경하거나,
     • 접속을 허용할 특정 서버의 사설 IP를 추가
  2. 비밀번호 설정 (원격 허용 시 필수):

     • # requirepass foobared 부분을 찾아서 주석(#)을 제거하고 사용할 비밀번호를 입력

         requirepass 내_안전한_비밀번호_입력
       

     • 수정 후 컨트롤+O, 엔터, 컨트롤+X로 저장하고 나온 뒤 Redis 서비스를 반드시 재시작

         sudo systemctl restart redis-server  # 일반 Linux
         sudo service redis-server restart    # WSL 환경
       

     • 비밀번호를 설정한 후에는

       • redis-cli 접속 후
       • auth 내_비밀번호를 입력해야 정상적으로 명령어를 수행할 수 있음