Redis를 바라보며: 우리는 정말 발명하는 개발자인가요?

Key-Value 스토리지(KV 스토리지)의 탄생

2000년대 이후 웹 2.0 시대가 오면서 웹서비스 업체들은 엄청난 사용자 수를 감당해야 하는 상황에 직면했습니다. 이 엄청난 트래픽을 감당하기 위해서 더 이상 크고 아름다운 서버가 아닌, 작지만 저렴한 대규모 분산 시스템이 필요해졌습니다.

다행히 프로필 정보 가져오기(userid = 1234), 캐시, 세션 저장(key-value) 같이 대부분의 데이터 구조는 단순한 형태였습니다. 이런 데이터를 처리하기에 기존 관계형 데이터베이스(RDBMS)는 너무 무겁고, 비싸고, 복잡한 옵션이었습니다.(스키마 설계, 테이블 관리 등등)

마침 CAP 이론이 등장(일관성, 가용성, 파티션 허용성 중 2가지만 가질 수 있다) 하면서 일관성을 좀 버리더라도, 가용성과 속도를 잡으면 된다는 생각이 퍼져나갔고, 그냥 key를 주면 value를 던져주는 간단한 데이터베이스가 탄생하게 되었습니다.(Memcached-2003, Amazon Dynamo-2007)

Redis의 탄생(REmote DIctionary Server)

made in italy. 인간은 귀찮은 걸 싫어한다

2009년 파스타의 고향 이탈리아의 Salvatore Sanfilippo라는 개발자는 LLOOGG라는 스타트업을 운영 중이었습니다.(Log 철자 두 개씩 들어간 거 맞습니다)

LLOOGG는 웹사이트 방문자 실시간 추적 서비스를 제공했는데(Google Analytics 실시간 기능의 극히 단순화된 버전) 소규모지만 실제 사용자도 있었습니다.

요즘에야 너무 당연한 요구지만, 그 당시엔 실시간 분석이 꽤 힘든 작업이었고 데이터가 쌓이기 시작하면서 기존 RDBMS는 점점 느려졌고, 실시간 반응성이 나오지 않는 문제에 직면하게 되었습니다.

실시간 반응을 위해서는 메모리에 데이터를 보관하고 빠르게 조회해야 하는데 Memcached는 당시 string 형태의 단순 GET, PUT만 지원했습니다.

Salvatore는 INCR(카운터), DECR, LIST 같이 조금 더 확장된 dictionary 기능을 지원하는 DB가 없다는 것을 깨닫고 X발 없으면 그냥 내가 만든다라는 상남자개발자 정신으로 초간단 TCP 서버 위에서 작동하는 초기 버전을 만들었습니다.(클러스터, AOF, 복제 기능 따위는 없었습니다)

Redis의 진화

in-memory dictionary with strings and lists

Redis는 캐시로 출발한 게 아니라, 실시간 처리를 위한 자료구조 저장소로 태어났습니다. 하지만 사람들은 똑같이 메모리 위에서 작동하지만, Memcached보다 더 다양한 자료구조를 지원하는 Redis를 캐시로 사용하기 시작했습니다.

마침 기존의 거인들(Facebook, Twitter, GitHub, Stack Overflow 등)도 캐시를 넘어선 데이터 구조에 대한 요구 사항이 증가 중이었고, 세션 저장, 로그인 토큰 관리, 실시간 카운터, 랭킹 시스템, 좋아요 수 같은 작은 기능부터 점진적으로 도입하고 괜찮은 결과가 나오며 개발자들 사이에서 입소문을 타며 확산되었습니다.

오픈소스 커뮤니티 참여자들이 늘고, 각종 요구사항들이 더해지며 기능은 진화형으로 추가되었습니다.

• 2009:
  • GET, SET, LIST
• 2010~2012:
  • 자료구조 확장: HASH, SET, ZSET(Sorted Set)
  • 퍼시스턴스 추가: RDB(Snapshot), AOF (Append Only File)
  • Pub/Sub 도입 (2.0)
  • Bitmaps (2.2)
• 2013~2015:
  • Lua 스크립트 (2.6)
  • Sentinel 도입 (2.8): 마스터-슬레이브 구조의 고가용성 솔루션
  • HyperLogLog(2.8.9)
  • Redis Cluster 도입 (3.0)
• 2016~2020:
  • GEO 지원 (3.2)
  • Stream 도입 (5.0)

이렇게 단순 Key, Value를 넘어서 List, Hash, Sorted Set 등 다양한 자료구조와 기능이 추가되고, 활용 사례가 늘어나면서 실시간 랭킹 시스템, 메시지 브로커, 임시 데이터 저장소, 세션 관리자, 분산 큐, 인메모리 데이터 웨어하우스로 사용 가능한 유연한 데이터 처리 플랫폼으로 성장했습니다.

커뮤니티와 UX 그리고 개발자의 철학

개인 개발자의 필요에 의해 작게 시작된 Redis는 필요에 따라 진화했고, 기능은 많아도 복잡하지 않아야 한다는 철학을 바탕으로 거대한 생태계로 발전했습니다.

최소 명령어, 최대 직관성

SET, GET, LPUSH, ZADD, HGETALL 이렇게 Redis 명령어를 한번 쓱 보면 어떤 역할을 하는지 바로 감을 잡을 수 있는데요, 덕분에 SQL을 처음 배우는 시간보다 더 짧은 시간에 Redis를 사용할 수 있습니다.

이런 직관성은 단순히 편하다를 넘어 도구에 대한 심리적 장벽을 낮추고, 개발자 생산성을 높이는 역할을 합니다.

문서, 커뮤니티, 플랫폼

Redis의 공식 문서는

• 명령어 별로 정리된 예시
• CLI 기반의 바로 실행 가능한 샘플
• 명확한 동작 설명

이렇게 구성되어 있습니다.

단순한 튜토리얼뿐만 아니라 실제 사용 사례까지 포함되어 있어서 초보자도 쉽게 사용할 수 있는데요, 엄청난 사용자를 바탕으로 커뮤니티(GitHub, Hacker News, Stack Overflow)에서는 언제든지 피드백과 해결책을 얻을 수 있습니다.

범용성의 힘

Redis는 특정 스택에 묶이지 않습니다. Python, Node.js, Java, Go, PHP, Ruby 등 거의 모든 언어에서 클라이언트가 제공되고, 어떤 환경에서도 빠르게 통합할 수 있습니다.

게다가 AWS, Azure, Google Cloud 같은 거대 클라우드 회사들의 관리형 서비스 형태로 제공되면서 운영과 확장도 훨씬 간편해졌습니다.

이렇게 직관적인 설계와 다양한 도구 지원, 강력한 커뮤니티, 범용성은 사용자, 클라우드 공급자, 오픈소스 기여자 모두에게 이익을 가져다줍니다.

이렇게 서로의 이익으로 구성된 Redis 생태계는 강요되지 않은 자연스러운 선택을 통해 In-memory DB의 사실상 표준으로 자리 잡았습니다.

Redis 생태계를 바라보며

새로운 규칙을 창조

이렇게 Redis는 방문자 실시간 분석이라는, 어쩌면 흔한 아이디어를 구현하기 위한 수단으로 출발했습니다.

그 과정에서 SQL이라는 느리고, 비싼 기존 방식의 한계를 새로운 접근 방식으로 돌파했는데요

• 스토리지 업체 인맥
• 납품업체 쥐어짜기
• 하드웨어 튜닝

이런 기존 규칙에서의 최적화가 아닌, 메모리를 DB의 핵심 요소로 바꾼다는 새로운 규칙을 만들어 냈습니다.

기초 지식의 중요성

단순한 기술 스택의 선택이 아니라 도구를 직접 설계하고, 기존에 없던 흐름을 제안하고, 그걸 전 세계가 받아들이게 만들 의지가 있는 개발자라면 기초 지식이 중요하다는 것을 느끼는데요

위에서 소개해 드린 Dynamo만 봐도 알 수 있습니다. 전 세계 아마존 고객들의 장바구니 저장이라는 문제를 해결하기 위해서 설계 된 Dynamo는 Consistent Hashing(노드 분산), Vector Clocks(버전 관리), Sloppy Quorum(가용성), Merkle Tree(데이터 싱크 체크) 같은 복잡한 분산 시스템 지식이 응용되어야 합니다

대한민국의 상황

냉정하게 바라본 대한민국의 커뮤니티와 오픈소스 상황은 어떨까요?

진짜 생태계는 청년 어쩌고, 중소기업 어쩌고, 국산 솔루션 사용 같은 정책과 법에 의존한 방식이 아닌, 오픈소스를 통한 개발자들의 자발적인 선택에 의해 형성됩니다.

Redis는 독점 회사의 제품이 아니라, 전 세계 개발자와 기업들이 자발적으로 선택한 결과물입니다. 그 선택이 모여 지금의 표준이 되었고, 그 안에서 생긴 부가가치는 상상 이상이었습니다.

• 네트워크, DB, 시스템 분야의 전문 인력
• 데이터센터, 전기, 메모리, UPS 같은 인프라
• 문서, 블로그, 책이라는 콘텐츠 분야
• 관리형 Redis를 제공하는 클라우드 서비스(aws, azure, gcp)
• 기업 전문 솔루션 서비스(Redis Enterprise)

대충 살펴봐도 충분히 거대한데 연관된 산업 규모까지 생각해 보면 더욱 어마어마하다는 것을 알 수 있습니다. (대한민국의 일자리 문제는 이렇게 해결해야 합니다)

이 모든 건 정부 정책이 아니라, 커뮤니티와 오픈소스가 해낸 일이라는 것을 생각하면 씁쓸해지는데요

한국이 인터넷 속도가 빠른 나라일지는 몰라도

• 기초 기술이 왜 중요한지 결과로써 증명할 수 있는지
• 문제를 해결하기 위해 도구를 만들 줄 아는 개발자 문화와 교육 시스템이 받쳐 주는지
• 지식 서비스 산업의 진정한 부가가치를 정말 이해하고 있는지

이렇게 생각해 보면 우리는 아직 겉모습만 선진국인, 어쩌면 제조업 시대의 사고방식으로 살면서 개발자는 지식서비스 산업 종사자라고 착각하고 있는 건 아닌지 고민해 보게 됩니다.

1930년대 미국 맨해튼과 대한민국 서울의 풍경. 우리는 현재 모두가 같은 인프라를 누리지만 사람들의 사고방식과 문화는 이렇게 차이 나는 상황일 수 있습니다.

나의 상황

기업이나 국가는 결국 구성원들의 집합이고, 문화는 곧 구성원들의 사고방식이 반영된 결과라고 볼 수 있는데요

• 창조에서 가장 중요한 기초 학문에 대한 존중이 있는지
• 외부 솔루션은 무조건 배척하고 자체 개발만 고집하고 있진 않은지
• 다른 사람의 아이디어가 있어 보이지 않으면 무시하고 있진 않은지
• 누군가 문제를 개선하려 할 때, 본능적으로 단점부터 찾고 있진 않은지
• 프로젝트를 이끌어가며 높은 부가가치를 창출할 의지와 능력이 있는지

뭔가를 원망하기 전에 이렇게 저 자신부터 돌아보게 됩니다.

진짜 개발자란 단순히 도구를 잘 쓰는 사람이 아니라, 허접하더라도 스스로 필요한 도구를 설계하고, 그 도구를 다른 사람도 쉽게 사용할 수 있도록 만들어서 생태계를 확장하고 부가가치를 창출할 수 있는 사람이라고 생각합니다.

Redis 생태계를 바라보며, 내가 정말 발명하는 개발자라고 당당하게 말할 수 있는지 다시 한번 생각하게 됩니다.

• 사진 출처:
  • 1930년대 엠파이어 스테이트 빌딩
  • 1930년대 남산에서 바라본 서울