떠났던 그 자리에서
나는 내 작업에 강한 애착을 갖는 사람이 아니다. 약 1620일 전(~4.44년 전) Redis를 떠나기로 했을 때, 그 뒤로 소스 코드도, 커밋 메시지도, Redis와 관련된 어떤 것도 다시 들여다보지 않았다. 가끔 Redis가 필요할 때면 그냥 내려받아 컴파일했을 뿐이다. “make”만 입력하면 됐고, 여러 해가 지나도 Redis 빌드가 여전히 그토록 간단하다는 사실이 무척 반가웠다.
이런 거리두기가 내 과거 작업을 싫어해서 생긴 건 아니었다. 장기적으로 보면 창의적인 작업의 비중은 점점 줄어들고 프로젝트를 ‘관리하는’ 일은 점점 더 커져 갔다. 많은 프로그래머가 잘 해내는 전환이지만, 그건 내 주특기가 아니다. 그럼에도 떠날 때조차 Redis 관련 작업을 즐기고 있었다. 하지만 나는 내 나이(지금 47세)의 많은 사람들이 공유하는 생각, 즉 자신은 아직 젊다는 생각에는 동의하지 않는다. 새로운 일을 하고 싶었다. 특히 글을 쓰고 싶었다. 가족과 더 많은 시간을 보내고 친척들을 돕고 싶었다. 확실히 휴식이 필요했다.
하지만 “글쓰기의 시절” 동안(지금도 계속 글을 쓰고 있다) 강도 높은 글쓰기에서 벗어나 휴식하는 방식으로 자주 코딩으로 돌아왔다(글쓰기는 코딩보다 훨씬 더 고되다고 느낀 유일한 정신 활동이다). 임베디드 프로젝트를 몇 개 했고, 신경망을 더 가지고 놀았으며, 텔레그램 봇도 만들었다. 이것저것 조금씩 건드렸다. 마구잡이로 해킹하는 건 재미있었지만, 시간이 갈수록 진짜 목적이 없다는 느낌이 들었고, 날이 갈수록 기술 세계에 다시 참여해야 한다는 절박함이 커졌다. 동시에 외부인의 입장에서도 Redis 커뮤니티가 분열되는 모습을 보았고, 그건 조금 우려스러웠다.
그래서 결국 Redis 생태계 안에서 다시 역할을 할 수 있지 않을까 생각하기 시작했다. 어쩌면 회사와 커뮤니티의 관계에 대한 태도를 바꿀 수 있을지도 모른다. 어쩌면 새로운 개발의 중심을 다시 Redis 코어로 돌리는 데 도움을 줄 수 있을지도 모른다. 기본적으로 일종의 “에반젤리스트”(이 직함이 썩 마음에 들진 않지만, 무슨 뜻인지는 알 것이다)가 되는 셈이다. 한쪽으로는 회사와 커뮤니티를 잇는 다리가 되고, 다른 한쪽으로는 프로그래밍 데모를 만들고, 새로운 패턴을 고안하고 설명하며, 신구 기능에 대한 문서와 영상, 블로그 글을 쓰는 사람이다. 그리고 새로운 것들의 설계는 어떨까? 현장에 있는 사람들의 작업과 그들이 겪는 어려움을 통해 배우고, 그것을 정제해 디자인 아이디어로 다시 전달해 Redis가 진화하도록 할 수 있을 것이다.
뉴욕에서의 시간
어느 날 지금 12살인 내 딸이, 지성과 창의성, 사랑으로 내 매일을 밝혀 주는 내 삶에서 가장 중요한 사람이 생일 선물로 뉴욕을 방문하고 싶다고 했다. 우리도 그래, 결국 좋은 생각인 것 같다고 결정했다. 최근 몇 년이 꽤 힘들었으니, 왜 안 가겠는가. 딸은 이제 아이보다 소녀에 가깝다. 그래서 뉴욕에 있는 동안 문득 생각했다. 어쩌면 지금이 파트타임으로 일을 해볼 적기일지도 모른다고. 얼마 전 새로운 Redis CEO인 Rowan Trollope을 화상 통화로 만났다. 그와 함께라면 회사와 커뮤니티의 관계, 그리고 코드베이스의 방향이라는 미래를 조율해 나갈 수 있을 것 같다는 느낌이 들었다. 그래서 그에게 이메일을 썼다. 어떤 형태로든 복귀할 수 있을지 어떻게 생각하느냐고. Rowan은 내 제안에 관심을 보였고, 우리는 곧 합의에 이르렀다.
라이선스 변경에 대하여
사람들은 내가 *정말* 왜 이런 결정을 했는지, 위에 쓴 이야기 외에 다른 배경이 있는 건 아닌지, 어떤 합의나 거액의 돈이 오간 건 아닌지, 뭔가 석연치 않거나 불투명한 게 있는 건 아닌지 물어볼 것이다. 하지만 때로는 일이란 지루할 정도로 단순하다. 1. 회사에 먼저 연락한 건 나였다, 반대가 아니다. 2. 복귀한다고 엄청난 돈을 받는 것도 아니다. 상황을 이용하려는 것도 아니다. 평범한 연봉이다(다만 미리 밝혀두자면, 이전과 마찬가지로 Redis 스톡옵션을 보유하고 있다. 더 많지도, 더 적지도 않다). 3. Redis의 라이선스 변경에 큰 불만이 있는 것도 아니다. 특히 커뮤니티와의 균열이 *진짜로* 라이선스 때문이라고 생각하지 않는다. 하지만 사람들이 이 매우 중요한 문제에 대해 물을 것이 분명하니, 처음부터 솔직하게 모두 이야기하는 편이 낫겠다.
라이선스 딜레마
나는 거의 평생 오픈소스 소프트웨어를 만들어 왔다. 하지만 나는 무신론자이면서도 다른 사람들이 신을 믿는 모습을 보면, 그것이 삶의 고난을 견디는 데 도움이 된다면 기쁘게 생각한다. 마찬가지로 소프트웨어를 만드는 유일한 방법이 오픈소스라고 믿지도 않는다. 내가 Redis 개발을 시작했을 때, 나는 두 명의 공동 창업자 중 한 명으로 있던 회사의 맥락 안에 있었고, 그곳에서는 소프트웨어 코드를 비공개로 유지했다(Redis는 핵심 제품이 아니라고 판단되어 공개되었다). 우리는 다른 사람들이 우리 서비스를 베끼는 걸 원치 않았을 뿐이다. 그만큼 단순한 이유였다. 그래서 이 문제에 관해서는 극단주의자가 아니다. 내가 극단적인 건 소프트웨어 설계에 대해서뿐이다.
더 나아가 나는 개방성과 라이선스가 OSI가 말하는 것만이 전부라고 믿지 않는다. 라이선스를 할 수 있는 일과 할 수 없는 일의 스펙트럼으로 본다. 동시에 대형 클라우드 제공업체들이 시스템 소프트웨어 영역의 인센티브를 바꿔 놓았다는 점을 깊이 우려한다. Redis는 라이선스를 바꾼 유일한 프로젝트가 아니었고, 사실 그 커다란 흐름에서 마지막에 속했다. 그리고 최근 몇 년간은 명확한 비즈니스 모델이 없어 아예 시작되지 못한 프로젝트가 많았다는 느낌도 든다. 그러니 Redis의 라이선스 전환은 내가 결정한 일이 아니며, 내가 다른 라이선스를 선택했을지도 모른다고? 잘 모르겠다. 여러 해 동안 현장을 떠나 있었고 비즈니스 압박도 없는 지금, 그걸 다시 논하는 건 너무 쉽다. 하지만 일반적으로는 그 선택을 이해할 수 있다.
게다가 새로운 Redis 라이선스를 읽어 보면, 물론 BSD는 아니지만, Redis를 서비스로 판매하지 않는 한 이전과 매우 유사한 방식으로, 비슷한 자유를 누리며 사용할 수 있다(내 말은 여전히 Redis를 수정하고, 재배포하고, 영리 기업에서도 상업적으로 무료로 사용할 수 있다는 뜻이다). *심지어* 원한다면 여전히 Redis를 서비스로 판매할 수도 있다. 다만 모든 오케스트레이션 시스템을 동일한 라이선스 아래 공개하면 된다(아마 아무도 그렇게 하진 않겠지만, 이는 이 라이선스의 카피레프트적 접근을 보여준다). 라이선스 문구는 SaaS 관련 부분을 제외하면 AGPL과 거의 동일하다. 그러니 OSI 승인을 받지 못했냐고? 그렇다. 하지만 SSPL을 클로즈드 라이선스라고 부르는 데는 동의하기 어렵다.
당신은 이렇게 말할 것이다(벌써 들리는 것 같다). 진짜 문제는 OSS 프로젝트의 방향을 기업이 통제한다는 점 아니냐고! 결국 이해관계가 사용자보다 기업 쪽으로 더 기울게 된다고. 외부 후원 정도를 제외하면 기업의 직접적 관여가 전혀 없는 프로젝트가 많이 있다는 점은 감사하게 생각한다. 하지만 알다시피, 많은 대형 프로젝트에서 기업의 참여는 오히려 올바른 방향에서 벗어나는 과정을 늦추기도 한다. Redis의 경우에도 분명히 그랬다.
소프트웨어의 로빈 후드
과거로 잠시 돌아가 보자, Redis의 초기 시절로.
Redis가 인기를 얻기 시작했을 때, 나는 계속해서 Redis 작업을 할 방법을 찾고 싶었다. VMware가 내 작업을 후원하겠다고 제안하기 전이었다. 비즈니스 모델에 대한 아이디어를 고민하기 시작했는데, 짐작하겠지만 그건 Redis 운영을 어떤 식으로든 돕는 클로즈드 소스 제품 형태였다(놀랍게도 이 아이디어와 관련된 저장소 하나가 지금도 온라인에 남아 있고, *15*년 전의 커밋을 보여준다: https://github.com/antirez/redis-tools)
나는 일종의 오픈 코어 방식을 시도하려 했고, 유료 사용자에게 다소간의 이점을 주기 위해 새로운 코드의 BSD 라이선스 적용을 6개월 정도 늦추는 것도 생각했던 기억이 있다. 지금 생각하면 내가 사용자들을 상대로 얄팍한 술수를 부리는 속 좁은 사람이 되었을 거라고는 생각하지 않지만, VMware 덕분에, 그리고 이후 Redis Labs 덕분에 내가 될 수 있었던 모습, 즉 오픈소스 소프트웨어계의 빌어먹을 로빈 후드가 되지는 못했을 것이다. 회사로부터 충분한 보상을 받으면서도, 회사의 이익을 위해서가 아니라 오직 Redis 커뮤니티의 최선의 이익을 위해서만 일하는 사람 말이다. 내 회사를 직접 운영하는 것보다 훨씬 더 나은 구조라고 확신한다.
VMware, 그리고 뒤이은 Redis Labs는 나만을 위해 돈을 쓴 게 아니었다. 저장소의 기여 내역을 잠깐 살펴보면 역대 두 번째 기여자가 Oran Agra(Redis)이고, 그다음이 Pieter Noordhuis(VMware)임을 알 수 있다. 그 뒤로도 많은 이들이 이어진다.
그러니 기본적으로 BSD 코드로 12년을 오로지 사용자만을 바라보며 써 왔다는 건 괜찮은 거래였고, 기뻐할 만한 일이라고 생각한다. 그리고 지금 나에게 가장 중요한 건 커뮤니티와의 균열이 라이선스 때문이 아니라는 점, 적어도 주로 라이선스 때문이 아니라는 점이다. 사실 새로운 라이선스는 그 문제의 일부를 해결할 수도 있다. 이제는 코어를 유지보수 모드로만 두고 새로운 개발을 모듈에만 넣을 유인이 사라졌다. 새로운 라이선스 아래에서는 클라우드 제공업체가 Redis 코드베이스를 그대로 베껴다 아무런 수익 배분 없이 판매할 수 없다(이게 정말 과한 요구였을까? 이 조건이 있었다면 최근 당신이 본 라이선스 전환 사태 전체, Redis만이 아니라 다른 프로젝트들도 막을 수 있었을 것이다). 새로운 라이선스 아래에서는 스포트라이트가 다시 Redis 코어로 돌아와 전 세계 개발자들의 손에 새롭고 흥미로운 기능들이 쥐어질 수 있다. GitHub 저장소에 유용하고 문서화가 잘 된 변경들을 밀어 넣는, 정당한 보상을 받는 수십 명의 사람들과 함께. 이것 역시 내가 회사를 도우려는 일 중 하나이며, 최선을 다할 것이다. 라이선스 전환이 사용자 기반과 기능 측면에서 긍정적인 효과를 내도록 만들어야 한다. 그게 내 생각이다.
AI, LLM, 그리고 벡터 인덱싱에 대하여
하지만 이야기는 여기서 끝나지 않는다. Redis는 벡터 기능 개발, 그리고 더 넓게는 AI로 할 수 있는 프로그래밍을 지원하는 데 관심을 갖기 시작했다. 요즘 나는 매일 Hacker News를 읽는데, 기술에 밝은 많은 사람들이 AI와 새로운 발전들을 싫어하는 걸 본다. 최신 모델들을 깊이 있게 제대로 써 보려는 노력조차 하지 않으면서(힌트: Claude AI는 독보적이다) 쓸모없다고 일축하는 사람들도 많이 본다. 나는 다르다. 나는 항상 신경망을 사랑해 왔다. 2003년에 첫 신경망 라이브러리를 직접 만들었고, 그 개념이 얼마나 강력하고 멋진지에 완전히 충격을 받았다. 그리고 마침내 2024년 말인 지금, 그 분야에서 믿기 힘든 성과들을 보고 있다. 몇 년 전만 해도 공상과학처럼 보이던 일들이 이제 가능해졌다. Claude AI는 요즘 나의 추론·편집·코딩 파트너다. 과거보다 훨씬 더 많은 일을 해낼 수 있게 되었다. 나는 AI 덕분에 종종 *더 많은 일*을 하지만, 더 잘하게 되었다. 최근 이탈리아 출판사를 위해 SF 단편을 썼는데, Claude가 일부를 비판해 준 덕분에 결말을 다시 써 훨씬 더 나은 작품을 만들 수 있었다(Claude에게 이야기의 한 줄이나 플롯조차 쓰게 하지 않았다. AI를 잘 쓰는 법은 기계가 당신이 더 잘할 수 있는 일을 대신하게 하는 게 아니다).
어제는 내 벡터들을 8비트 양자화로 했을 때 내적이 얼마나 빨라지는지 평가해야 했다. Claude에게 특정한 방식으로 설계된 벤치마크가 필요하다고 말했더니, 2분 뒤에 바로 테스트하고, 수정하고, 그게 가치 있는 일인지 아닌지 판단할 수 있었다. 기본적으로 AI가 나를 대체한 게 아니라, AI가 나를 가속하고 내 작업에 대한 피드백으로 나를 더 나아지게 했다. 그리고 나는 (RAG의 인기와는 별개로, RAG가 꼭 주된 응용도, 가장 미래가 보장되거나 유용한 응용도 아니라고 본다. 모델의 컨텍스트가 점점 더 커지고 있고, 곧 인기 모델들의 어텐션은 선형 복잡도를 갖게 될 것이기 때문이다) 이 긴 사족은 접어두고 말하자면, 학습된 임베딩은 남을 것이고 벡터 검색은 여러 이유로 Redis에 속한다고 믿는다. 첫째, 벡터 인덱스는 자료구조이며, 특히 느린 자료구조다. 그런 자료구조는 메모리에서 아주 잘 동작한다. 또 하나는 내가 그것을 노출할 완벽한 API를 찾았다고 생각하기 때문이다.
Redis를 설계하면서 나는 늘 모순적인 경향을 보여 왔다. 프로젝트에 완벽하게 맞아 보이는 것들(지금은 둘 다 Redis에 들어와 있는 네임드 Lua 스크립트, 해시 필드 만료 같은 것들)에 대해서는 언제나 “안 된다”고 말할 준비가 되어 있었으면서도, 동시에 미친 소리처럼 들리던 Lua 스크립팅 기능—Redis 안에 인터프리터를?—이나, 맥락에 안 맞아 보이던 Pub/Sub 기능, 나아가 스트림, 심지어 컴퓨터 과학 교과서에는 존재하지 않는 합성 자료구조인 Sorted Set까지 추가했다. 나에게 새로운 기능이 Redis에 어울리는지는 두 가지에 달려 있었기 때문이다. 사용 사례와 내부 설계의 적합성. 나에게 Redis는 ‘제품’이 아니라 프로그래머를 위한 레고였다.
벡터 셋
그래서 최근에 Sorted Set에서 영감을 받아 점수 자체가 벡터인 새로운 자료형을 만들 수 있지 않을까 생각하기 시작했다. Rowan과 대화하는 동안 나는 설계 문서를 쓰기 시작했고, 이어서 새로운 자료구조의 개념 증명을 구현하기 시작했다. 사용 가능한 라이브러리 중 하나를 쓰는 대신, 모든 세부 사항을 미세하게 조정하고 싶어 HNSW를 처음부터 다시 구현했다. Redis다운 방식으로 말이다. 그리고 글쎄, 이게 어떻게 끝날지는 아직 모르겠다. 아직 코딩 초기 단계지만, 이 제안이 받아들여진다면 다시 코드 기여를 하게 될지도 모른다. 내가 구현한 모듈(나중에는 코어에 합쳐질 예정이지만, 지금은 간단함을 위해 모듈 형태다)은 임베딩을 직접 다루는 새로운 명령어들을 구현한다. 힌트로 하나만 보여주겠다.
VSIM top_1000_movies_imdb ELE "The Matrix" WITHSCORES
1) "The Matrix"
2) "0.9999999403953552"
3) "Ex Machina"
4) "0.8680362105369568"
5) "Akira"
6) "0.8635441958904266"
7) "District 9"
8) "0.8631418347358704"
9) "The Martian"
10) "0.8608670234680176"
11) "The Bourne Ultimatum"
12) "0.8599717319011688"
13) "The Bourne Supremacy"
14) "0.8591427505016327"
15) "Blade Runner"
16) "0.8585404753684998"
17) "Metropolis"
18) "0.8572960793972015"
19) "Inception"
20) "0.8521313071250916"VSIM, VADD, VCARD 등 당연한 것들이 모두 있다. Sorted Set과 정확히 같은 아이디어지만, 다차원 점수(임베딩!)와 K-최근접 이웃 매칭이 더해진 형태다. 어떻게 생각하는가? 물론 그 위에는 더 효율적으로 만들기 위한 여러 구현상의 트릭이 있다. 하지만 지금은 개념 증명 코드이니, 조금 더 작업해 보겠다. 스레딩, 차원 축소, 양자화 등 더 많은 것들을 구현 중이다. 솔직히 꽤 재미있다.
보다시피 하이브리드 검색에 대한 언급은 없다. 요즘 벡터 스토어 쪽에서 유행하는 말이다. 다시 말하지만, 이게 바로 Redis다운 방식이다. 개발자에게 역할을 주고 트레이드오프를 스스로 결정하게 하는 것. 결국 무엇을 모델링하는지 가장 잘 아는 건 그들이니까. 키마다 하나의 벡터 인덱스를 갖게 되고, 프로그래머들이 Sorted Set으로 해왔던 것처럼 흥미로운 분할 전략, 새로운 스키마, Lua 스크립트, 패턴 등 사용 사례를 모델링하는 데 필요한 모든 것을 발명해 낼 것이다.
그래도 연관된 아이템이 대개는 작은 문자열이나 문서 ID일 가능성이 높지만, 나중에 필터링할 수 있는 더 복잡한 메타데이터가 되는 것을 막을 이유는 없다(하지만 나는 참으려 한다). 많은 사용 사례에서는 사실 복잡한 서버 측 필터링이 필요하지 않고, 데이터를 미리 분할하는 방식으로 충분히 모델링할 수 있다는 느낌이 든다.
내가 큰 관심을 갖고 보는 건 결과를 사용자에게 반환하는 대신 Sorted Set에 저장하는 STORE 옵션의 추가 가능성이다. 이때 점수는 물론 유사도가 된다. 이 모든 것은 효율성, 확장성, 스크립트 활용 능력 등에 복잡하고 흥미로운 영향을 미친다. 앞으로 몇 주, 몇 달 안에 이에 대해 더 이야기할 기회가 있기를 바란다.
좋다, 좋다. 다시 이 블로그 글의 요점으로 돌아오자. 하지만 어쩌면 위의 내용이 *진짜* 요점일지도 모른다. 새로운, 흥미로운 아이디어가 있다는 것 자체가.
그래서, 돌아왔습니다 🙂
이 모든 걸 한마디로 정리하자면, 돌아왔다는 것이다. 지난 세월 동안 Redis 커뮤니티가 해 온 모든 것에 대해 큰 감사를 전할 적기라고 생각한다. 앞으로도 잘 부탁한다. 이 여정에 더 보탤 무언가가 있기를 바란다.
P.S. BlueSky에서 활동 중이다. 이 모든 과정의 진행 상황을 따라가고 싶다면 팔로우해 달라. https://bsky.app/profile/antirez.bsky.social