캐시 하면 다들 Redis만 떠올리는데
백엔드 개발을 하다 보면 '캐시(cache)'를 한 번쯤 쓰게 돼요. 캐시가 뭐냐면, 자주 쓰는 데이터를 빠른 곳에 잠깐 복사해두는 임시 보관함이에요. 매번 데이터베이스(DB)까지 가서 무겁게 조회하는 대신, 한 번 가져온 결과를 메모리에 넣어두고 다음엔 거기서 휙 꺼내 쓰는 거죠. 그런데 요즘은 캐시 하면 거의 자동으로 'Redis(레디스)'를 떠올리잖아요. 이 글은 거기에 대고 "잠깐, Memcached(멤캐시드)도 다시 봐줄 만하다"고 말하는 이야기예요.
Memcached는 사실 캐시 도구의 원조 격이에요. 페이스북이나 트위터 같은 거대 서비스가 한창 커지던 시절, 폭주하는 트래픽을 견디게 해준 일등공신이거든요. 분산 메모리 기반 키-값 저장소인데, 풀어 말하면 '여러 서버에 걸쳐서, 메모리에, 열쇠(key)와 값(value) 한 쌍으로 데이터를 담아두는 도구'예요. 'user:123'이라는 열쇠를 넣으면 그에 해당하는 사용자 정보가 튀어나오는 식이죠.
단순함 속에 숨은 강점
Memcached의 철학은 한마디로 '딱 캐시만 잘하자'예요. Redis가 리스트, 정렬된 집합, 발행/구독 같은 온갖 기능을 갖춘 다용도 칼이라면, Memcached는 캐싱 하나에만 집중하는 잘 드는 회칼 같은 거예요. 기능이 적다는 게 단점처럼 들리지만, 여기서 의외의 장점들이 나와요.
첫째, 메모리를 알뜰하게 써요. Memcached는 데이터를 저장할 때 슬랩 할당(slab allocation)이라는 방식을 써요. 이게 뭐냐면, 메모리를 정해진 크기의 칸들로 미리 나눠두고 데이터를 거기에 맞춰 넣는 방식이에요. 덕분에 메모리가 여기저기 자투리로 쪼개지는 '파편화' 문제를 줄이고, 열쇠 하나당 따라붙는 부가 비용(오버헤드)도 작아요. 작은 데이터를 어마어마하게 많이 캐싱할 땐 이 차이가 꽤 크게 벌어져요.
둘째, 여러 일을 동시에 처리하는 데 강해요. Memcached는 태생부터 멀티스레드(여러 작업 줄을 동시에 돌리는 방식)예요. 요즘 서버 CPU는 코어가 수십 개씩 되는데, Memcached는 이 코어들을 자연스럽게 나눠 쓰면서 초당 어마어마한 요청을 받아내요. 반면 Redis는 핵심 처리를 오랫동안 단일 스레드 위주로 해왔죠(최근 버전에서 일부 멀티스레드를 도입하긴 했지만요).
셋째, 예측 가능성이에요. 기능이 단순하다는 건 곧 동작이 단순하다는 뜻이고, 메모리가 가득 차면 가장 오래 안 쓴 데이터부터 버리는(LRU) 방식이 직관적이라 운영 중에 '어, 왜 이러지?' 할 일이 적어요.
그래서 언제 뭘 쓰냐면
현실적인 선택 기준은 이래요. DB 부하를 덜기 위한 순수한 캐시, 그러니까 '날아가도 다시 만들면 그만인 임시 데이터'를 빠르고 가볍게 다룰 거라면 Memcached가 깔끔해요. 반대로 캐시를 껐다 켜도 데이터가 살아있어야 하거나(영속성), 순위표·세션·실시간 알림 같은 풍부한 자료구조와 부가 기능이 필요하면 Redis가 맞고요. 즉, 둘은 경쟁자라기보다 쓰임새가 다른 도구예요. 한 시스템 안에서 역할을 나눠 같이 쓰기도 해요.
한국 개발자에게 주는 시사점
신기술과 화려한 기능에 끌리는 건 자연스러워요. 하지만 이 글이 주는 진짜 교훈은 '문제에 비해 도구가 과하지 않은가'를 되묻는 자세예요. 단순 캐싱만 필요한데 Redis의 온갖 기능을 짊어지는 건, 못 하나 박으려고 전동 드릴을 꺼내는 것일 수 있거든요. 트래픽이 정말 큰 서비스에서는 이 '단순함'이 운영 안정성과 비용 절감으로 직결돼요.
핵심은 이거예요. 유행하는 도구가 항상 정답은 아니다. 때로는 한 가지를 잘하는 단순한 도구가 가장 강하다. 여러분의 프로젝트에선 캐시로 무엇을 쓰고 계신가요? 혹시 습관적으로 Redis만 쓰고 있진 않았나요?
🔗 출처: Hacker News