이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 세션 관리를 DB에 저장하다가 조회 빈도가 높아지자 Redis를 캐시 레이어로 도입한 경험이 있습니다. 가장 먼저 고민한 건 어떤 데이터를 캐싱하고 어떤 TTL을 줄 것인가였는데, 변경이 자주 일어나는 데이터를 캐싱하면 오히려 정합성 문제가 생긴다는 걸 초반에 배웠습니다.
TTL과 캐시 무효화 전략을 설계하면서 캐시를 쓰는 것보다 올바르게 무효화하는 것이 훨씬 어렵다는 점을 체감했습니다. Redis를 선택한 이유는 읽기 속도보다 데이터 구조의 다양성 때문이었는데, 순위 목록 구현에 sorted set을 쓰니 별도 정렬 로직이 필요 없었습니다. 지금도 캐싱 도입 전에 캐시 미스와 무효화 시나리오를 먼저 그려보는 순서를 지킵니다.
Redis를 쓰면서 인프라 구성이 복잡해지는 시점이 올 때 대안을 생각해보는 습관이 생겼습니다. 작은 프로젝트에서 캐싱을 위해 Redis를 붙이면 운영해야 할 컴포넌트가 하나 더 늘어나고, Redis 장애 시 애플리케이션도 영향을 받는 구조가 됩니다.
세션 캐싱 용도로 Redis를 쓰다가 팀 내에서 인프라 단순화 방향으로 논의가 생겼을 때, DB 레벨에서 만료 기간 컬럼을 붙이는 방식으로 대체할 수 있는지를 실험해봤습니다. 트래픽이 적은 환경에서는 DB 기반 세션 관리도 충분히 가능했고, Redis 없이도 동일한 요건을 충족할 수 있었습니다.
이 경험에서 배운 것은 도구보다 그 도구가 해결하는 문제 자체를 이해하는 것이 더 중요하다는 점입니다. Redis가 필요한 이유가 인메모리 속도인지, 데이터 구조의 유연함인지에 따라 대체 가능한 방식이 달라집니다. 도구 선택이 도구에 종속되지 않으려면 그 도구가 무엇을 하는지를 정확히 알아야 한다는 생각이 남아 있습니다.
Redis를 프로덕션처럼 운영하는 실습 환경에서 실수로 KEYS * 명령을 실행한 경험이 있습니다. 저장된 키를 전체 확인하려는 의도였는데, 키가 수만 개 쌓인 상태에서 이 명령을 실행하자 다른 명령들이 모두 멈추는 상황이 됐습니다.
Redis가 단일 스레드 구조라 명령 하나씩 처리한다는 것을 알고 있었지만, KEYS처럼 전체를 스캔하는 명령이 실행되는 동안 다른 명령이 블로킹된다는 것을 그때 처음 체감했습니다. 이후 키 목록 조회가 필요할 때는 SCAN으로 나눠서 가져오는 방식을 쓰고 있습니다.
maxmemory 설정을 명시하지 않은 상태로 두면 메모리를 계속 쓰다가 결국 프로세스가 종료될 수 있다는 것도 이 실습에서 배웠습니다. Redis를 처음 쓸 때는 성능이 빠른 부분만 보이는데, 실제로 운영 관점에서 설정해야 할 항목이 생각보다 많다는 것이 체감됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.