그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Cache
Cache

Redis가 싱글 스레드로 만들어진 이유를 설명해주세요.

실무4/5
설계4/5
인간3/5
기초3/5

면접관의 질문 의도

단일 스레드 = 느림이라는 직관을 그대로 들고 오는지, 메모리 작업·이벤트 루프·락 비용까지 한 줄로 연결해 보는지를 가른다.

큐레이션 답변

학습 자료

Redis는 메모리 기반 작업과 이벤트 루프 중심 처리 모델 위에서 명령 실행을 싱글 스레드로 직렬화해 락 경쟁과 동기화 비용을 끊었다. 레이스 컨디션과 데드락이 구조적으로 사라지고 데이터 일관성은 단순해진다. 컨텍스트 스위칭 오버헤드도 줄어 메모리 작업 자체의 빠른 응답이 그대로 처리량으로 이어진다. Redis 6.0부터는 네트워크 I/O 일부만 멀티스레드로 풀고, 명령 실행 코어는 여전히 단일 스레드다.

좋은 답변 구조

  1. 01Redis가 처리하는 작업이 메모리 기반이라는 전제를 먼저 짚는다
  2. 02싱글 스레드가 락·동기화 비용을 어떻게 끊어내는지 설명한다
  3. 03이벤트 루프와 컨텍스트 스위칭이 처리량으로 이어지는 경로를 연결한다
  4. 04Redis 6.0의 I/O 스레드 도입과 명령 코어의 단일 스레드 유지가 왜 분리됐는지 짚는다

자주 실수하는 포인트

싱글 스레드라서 처리량이 낮다고 단정하고 메모리 작업 전제를 빠뜨린다
Redis 6.0 이후 I/O 스레드 도입을 명령 실행까지 멀티스레드가 됐다고 오해한다
락 회피와 일관성 단순화라는 설계 의도를 빼고 결과만 외운다

실무 맥락

  • 초당 수만 요청이 몰리는 캐시 계층에서 단일 인스턴스 한계를 보는 환경
  • 세션·실시간 카운터처럼 일관성과 빠른 응답을 동시에 요구하는 환경
  • 핫키 한두 개에 트래픽이 쏠려 인스턴스가 통째로 끌려가는 운영 상황

본인 경험에 녹이는 힌트

Redis 인스턴스를 워크로드 별로 분리해 본 적이 있다면 단일 코어 병목과 연결할 수 있다

핫키나 큰 키 하나가 응답 지연을 끌어올린 경험이 있다면 명령 실행 직렬화 구조와 엮어 설명할 수 있다

slowlog나 CPU 사용률을 보고 인스턴스를 늘릴지 샤딩으로 갈지 판단했던 경험이 있다면 멀티코어 확장 전략으로 이어진다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1어떤 워크로드에서 단일 스레드 병목이 가장 먼저 드러나나요
Q2Redis 6.0의 I/O 스레드가 실제로 어디서 이득을 주나요
Q3멀티코어를 활용해 Redis를 확장할 때 어떤 선택지를 고려하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문