Redis를 바라보며: 우리는 정말 발명하는 개발자인가요?
Key-Value 스토리지의 탄생
2000년대 이후 웹 2.0 시대가 오면서 웹서비스 업체들은 엄청난 사용자 수를 감당해야 하는 상황에 직면
이 엄청난 트래픽을 감당하기 위해 크고 아름다운 서버가 아닌, 작지만 저렴한 대규모 분산 시스템이 필요해짐
다행히 대부분의 데이터 구조는 단순함(ex. userid = 1234 정보 가져오기)
관계형 데이터베이스(RDBMS)를 이용하기에는 너무 무겁고, 비싸고, 복잡함
CAP Theorem 등장
그럼 일관성 버리더라도, 가용성과 속도를 잡으면 됨
key를 주면 value를 던져주는 간단한 데이터베이스 탄생(Memcached-2003, Amazon Dynamo-2007)
Redis의 탄생
파스타의 고향 이탈리아에서 Salvatore Sanfilippo라는 개발자가 LLOOGG라는 스타트업을 운영 중(Log 철자 두개 맞음)
LLOOGG는 웹사이트 방문자 실시간 추적 서비스를 제공
소규모지만 실제 사용자도 있었음
당시 실시간 분석은 꽤 힘든 작업임
데이터 쌓이기 시작 → 기존 RDBMS는 점점 느려짐 → 실시간 반응성이 나오지 않음
실시간 반응을 위해서는 메모리를 이용해야 함 → Memcached는 당시 string 형태의 단순 GET, PUT만 지원함
INCR, DECR, LIST 같이 조금 더 확장된 dictionary 기능이 필요한데 그런 DB가 없다? → X발 그냥 내가 만든다
초간단 TCP 서버 위에서 작동하는 초기 버전 탄생(클러스터, AOF, 복제 같은 고오급 기능 따위는 없음)
Redis의 진화
Redis는 캐시가 아닌 실시간 처리를 위한 자료구조 저장소를 목적으로 태어남
그런데 사람들이 캐시로 사용하기 시작
기존의 거인들(Facebook, Twitter, GitHub, Stack Overflow 등)의 캐시를 넘어선 데이터 구조 요구 사항이 증가
세션 저장, 로그인 토큰 관리, 실시간 카운터, 랭킹 시스템, 좋아요 수 같은 작은 기능부터 점진적 도입 시작
각종 필요 기능과 자료구조는 진화형으로 추가됨 (Sorted Set, HASH, Cluster, 퍼시스턴스...)
유연한 데이터 처리 플랫폼이 되어버림
커뮤니티와 UX 그리고 개발자의 철학
Redis는 기능은 많아도 복잡하지 않아야 한다는 철학이 바탕임
공식 문서는 CLI 기반의 바로 실행 가능한 샘플, 명확한 동작 설명을 제공함
직관적인 명령어들은(SET, GET, LPUSH, ZADD, HGETALL 등) 공식 문서 한번 쓱 보면 어떤 역할을 하는지 바로 감을 잡을 수 있음
이런 직관성은 단순히 편하다를 넘어 도구에 대한 심리적 장벽을 낮추고, 개발자 생산성을 높이는 역할을 함
이런 구조에서 나오는 범용성은 사용자, 클라우드 공급자, 오픈소스 기여자 모두에게 이익을 가져다 줌
서로의 이익으로 구성된 생태계에서 Redis는 강요되지 않은 선택을 통해 In-memory DB의 사실상 표준으로 자리 잡음
Redis 생태계를 바라보며
Redis는 방문자 실시간 분석이라는, 어쩌면 흔한 아이디어를 구현하기 위한 수단으로 출발함
SQL이라는 기존 방식의 한계(느리고 비쌈)를 새로운 접근 방식으로 돌파
업체 인맥 활용, 납품업체 쥐어짜기, 하드웨어 튜닝, 사용량 제한 같은 기존 규칙의 최적화가 아님
메모리를 DB의 핵심 요소로 바꾼다는 새로운 규칙을 만들어냄
도구를 직접 설계하고, 기존에 없던 흐름을 제안하고, 그걸 전 세계가 받아들이게 만들려면 응용을 위한 기초 지식이 중요함
장바구니 저장이라는 문제를 해결하기 위해서 설계된 Amazon Dynamo만 봐도 복잡한 분산 시스템 지식이 응용되어야 함
모두의 자발적 선택에 의한 업계 표준이 되면 거대한 부가가치와 일자리가 창출됨
Redis 전문 인력, 하드웨어 인프라, 학습 콘텐츠, 관리형 서비스(AWS, Azure), 전문 솔루션(Redis Enterprise)을 보면 공감할 수 있음
이 모든 건 xx 산업 살리기, 청년 어쩌고, 중소기업 어쩌고 같은 정부 정책이나 법이 만들어낸 것이 아님
우리는 아직 겉모습만 선진국인, 어쩌면 제조업 시대의 사고방식으로 살면서 개발자는 지식서비스 산업 종사자라고 착각하고 있는 건 아닌지 고민해 보아야 합니다.
기초 기술(ex. 알고리즘)이 왜 중요한지 결과로써 증명할 수 있는지
문제를 해결하기 위해 도구를 만들 줄 아는 개발자 문화와 교육 시스템이 있는지
모두가 실패를 용납하는 문화를 키워야 한다고 하지만 나부터 다른 사람의 실수에 분노하거나 욕하지는 않는지
지식 서비스 산업의 진정한 부가가치를 정말 이해하고 끈질기게 밀고 나갈 수 있는지
진짜 개발자란 단순히 도구를 잘 쓰는 사람이 아니라, 허접하더라도 스스로 필요한 도구를 설계하고, 그 도구를 다른 사람도 쉽게 사용할 수 있도록 만들어서 생태계를 확장하고 부가가치를 창출할 수 있는 사람이라는 마음을 되새겨 봅니다.
