# Redis array: 긴 개발 과정의 짧은 이야기 > Clean Markdown view of GeekNews topic #29173. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29173](https://news.hada.io/topic?id=29173) - GeekNews Markdown: [https://news.hada.io/topic/29173.md](https://news.hada.io/topic/29173.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-05-05T08:25:50+09:00 - Updated: 2026-05-05T08:25:50+09:00 - Original source: [antirez.com](https://antirez.com/news/164) - Points: 1 - Comments: 1 ## Topic Body - Redis의 새 **Array 데이터 타입** 작업은 1월 초 시작돼 약 4개월 뒤 PR로 올라갔고, 첫 달에는 필요성, C 구조체, 희소 표현, 링 버퍼, `ARINSERT`용 배열 커서 의미를 담은 명세가 작성됨 - 초기 설계는 Opus와 함께 다듬었고 GPT 5.3 출시 뒤에는 **Codex**로 설계와 개발을 진행했으며, AI와의 피드백 과정에서 절충점과 과도하게 설계된 부분을 계속 검토함 - 구현은 `ARSET myarray 293842948324 foo` 같은 큰 인덱스 설정도 거대한 할당 없이 동작하도록 바뀌었고, 내부 자료구조는 조건에 따라 **슈퍼 디렉터리**, 슬라이스된 밀집 디렉터리, 실제 배열 슬라이스 형태로 전환됨 - 각 슬라이스는 기본적으로 **4096개 요소**를 담으며, `ARSCAN`과 `ARPOP`은 범위 전체 크기가 아니라 실제 존재하는 요소 수에 비례하는 시간으로 기존 배열을 스캔할 수 있음 - Markdown 파일을 Redis 배열에 넣는 사용 사례가 `ARGREP` 구현으로 이어졌고, 정규표현식 지원에는 TRE를 선택했으며, 사용 사례는 [Redis PR #15162](https://github.com/redis/redis/pull/15162)에 정리돼 있음 --- ### 구현과 검토 - 두 번째 달부터 자동 프로그래밍 방식으로 구현을 시작하면서 생성된 코드를 계속 검토함 - 구현이 동작한 뒤에도 `sparsearray.c`와 `t_array.c`를 포함한 코드를 한 줄씩 읽으며 검토함 - AI 덕분에 테스트가 많았지만, 표면적으로 동작하는 코드가 최적이라는 뜻은 아니어서 작은 비효율과 설계 오류를 찾아 수정함 - 여러 모듈을 수동 및 AI 보조 방식으로 다시 작성했고, 세 번째 달에는 다양한 방식으로 스트레스 테스트를 진행함 - 고품질 시스템 프로그래밍에서는 여전히 사람이 완전히 관여해야 하지만, AI가 있으면 32비트 지원 추가와 테스트처럼 피로도가 큰 작업과 복잡한 알고리듬의 명백한 버그 탐지에서 안전망이 됨 - 초기의 큰 명세 작성은 이후 작업의 핵심이었고, 코드의 모든 줄을 검토하며 맞지 않는 부분을 수정하는 데도 중요했음 ### 사용 사례와 정규표현식 - 사용 사례를 모델링하던 중 Markdown 파일을 Redis 배열에 넣기 시작했고, 파일이 배열 데이터 타입과 잘 맞는다는 결론에 이름 - 에이전트 작업에 필요한 Markdown 파일 기반 중앙 지식 베이스를 만들기 위해 **`ARGREP`** 구현으로 이어짐 - 정규표현식 지원을 위해 TRE를 선택했으며, Redis에서 정규표현식을 사용할 때 시간이나 공간 측면의 병리적 패턴이 없어야 한다는 이유가 있었음 - TRE는 `foo|bar|zap` 같은 유용한 패턴 매칭에서 매우 비효율적이어서, GPT의 도움으로 최적화하고 잠재적 보안 문제 몇 가지를 수정했으며 테스트도 확장함 - 사용 사례는 [Redis PR #15162](https://github.com/redis/redis/pull/15162)에 자세히 정리돼 있으며, 숫자 인덱스가 의미의 일부가 되는 데이터 타입이 Redis에 필요하다는 결론으로 이어짐 - Array PR이 곧 받아들여지고, 새 사용 사례의 이점을 얻을 수 있기를 기대하며 피드백을 요청함 ## Comments ### Comment 56849 - Author: neo - Created: 2026-05-05T08:25:50+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48009172) - 분명히 해두자면, 이건 **Redis의 원작자** 또는 그중 한 명이 한 일임 그는 “평균적인 개발자”가 아니고, LLM을 써도 4개월이 걸렸음 그러니 이걸 근거로 모든 개발자에게 Claude Code, Codex, 기타 AI 코딩 도구로 완전히 옮기라고 지시해도 된다는 승인 도장처럼 받아들이면 안 됨 특히 평범한 스타트업 CEO들이 봐야 할 대목임 - **경험 많은 개발자**가 코딩 에이전트를 능숙하게 쓰면 전문성이 더 증폭될 수 있다는 꽤 강한 근거로 보임 - “그는 평균적인 개발자가 아니고 LLM을 써도 4개월이 걸렸다”는 부분은 원문을 보면 조금 다름 원문에서는 “LLM 이전에도 구현 자체는 아마 4개월 안에 할 수 있었을 것이다. 달라진 건 같은 기간에 훨씬 더 많은 일을 할 수 있었다는 점”이라고 했음 즉 초기 기간은 원래 4개월이었고, LLM 덕분에 같은 기간 안에 더 많은 작업을 한 것임 - 그는 평균적이지 않지만, 그의 작업도 당연히 평균적인 작업이 아님 평균적인 개발 업무는 **배관 작업과 CRUD**에 가까움 - 현재 쓰는 방식은 이럼 먼저 AI 도움을 받아 **상위 설계 문서**를 Markdown으로 작성함. 그다음 같은 모델이되 문맥을 빼거나, 다른 모델에게 비판하게 해서 버그·누락·빈틈을 찾게 함. 나중에 보면 뻔한 것들을 항상 찾아냄 그러면 그 발견을 요약하게 해서 첫 번째 AI에 붙여넣고 의견을 묻는다. 합의된 변경을 만들고 반영한 뒤, 어떤 모델도 의미 있는 제안을 못 할 때까지 이런 적대적 라운드로빈을 계속함 이후 AI에게 계획을 만들게 하고, 그 계획도 여러 AI 사이에서 적대적으로 돌림. 결국 꽤 탄탄한 계획이 나옴 그다음 종단 간 테스트 케이스 계획 등으로 넘어감. 시스템 규모에 따라 첫날, 첫 주, 첫 달이 끝날 즈음 코딩 준비가 됨 코드가 만들어지면 그 코드와 명세, 계획을 다른 AI에 붙여넣고 버그·누락·빈틈을 찾게 함. 구현을 맡은 주 AI를 계속 다른 AI로 검증하는 방식임 물론 코드는 직접 읽어야 함. AI가 **마감 품질의 세부 polish**를 놓치는 걸 봤기 때문임 - AI 담론에서는 우리가 완전히 새로운 **비감독 개발 패러다임**을 열었다고 하지만, 사실상 Google이 10년 동안 코드를 만들어 온 방식과 거의 같음. 다만 신뢰 수준이 다른 인간 대신 AI를 쓰는 것뿐임 비꼬려는 건 아님. 내 작업 흐름도 본질적으로 같고, Google을 비웃자는 것도 아님. 오히려 새로울 건 없다는 뜻임 AI는 효과적인 작업 흐름과 비효과적인 작업 흐름을 모두 엄청나게 가속함. 덕분에 무엇이 효과적이고 무엇이 비효과적인지 훨씬 짧은 시간, 거의 실시간으로 드러남 - 그 방식이 직접 코드를 쓰는 것보다 **얼마나 빠르거나 느린지** 궁금함 - 이런 **명세 주도 개발**은 AWS Kiro의 핵심 차별점이었음: [https://kiro.dev/docs/specs/]() 다른 에이전트도 쓴다고 했는데, 덜 다듬어진 부분을 다른 에이전트가 polish하는 코드 리뷰에서 효과를 봤는지 궁금함. 내 동료들은 강하게 믿지만, 개인적으로는 인간 리뷰어 없이 가치가 있는지 아직 회의적임 “다른 AI에게 묻는다”는 방식은 응용 컴퓨터과학에서는 정립-반정립-종합이 더 잘 맞는지도 모르겠음: [https://en.wikipedia.org/wiki/Dialectic#Criticisms]() - antirez가 작성했더라도, 이 정도 기능 집합과 최소한의 PR 설명으로 **22,000줄 코드 리뷰**를 하는 건 악몽처럼 들림 Postgres 같은 주요 오픈소스가 왜 메일링 리스트에서 개발되는지 이해가 감. 중간 설계 결정을 커뮤니티와 논의하고, 관련 기능도 별도 패치로 나누며, 점진적으로 리뷰하고, 릴리스 간격도 띄워서 진행하는 방식임 - 코드는 주석 포함 총 **5,000줄**임 희소 배열이 2,000줄 `t_array` 명령과 상위 계층 구현이 2,000줄 AOF/RDB 코드가 약 500줄 나머지는 테스트, JSON 명령 설명, `deps` 아래 TRE 라이브러리임 - Postgres와 Redis는 성격, 역사, 기여 방식, 개발팀이 극적으로 다른 프로젝트임 사실상 주요 Redis 기능 대부분은 글쓴이가 혼자 만든 작업임 게다가 리뷰어들은 이 일을 잘 알고 보수도 제대로 받음 - 현재 최고 수준 AI를 써본 내 경험과 매우 비슷함. **인간 지능과 창의성의 대체재**와는 거리가 멀지만, 협업자로는 극도로 유용함 - AI는 내가 늘 원하던 **고무 오리 프로그래밍 오리**라고 말하곤 함 - 코드를 거의 보지 않고도 개발하는 프로젝트들이 있음. 개념, 알고리즘, 아이디어를 내가 쥐고 질문과 힌트를 주며, 특히 제품 방향을 소유하는 식임 하지만 Redis는 아직 아님. 언젠가 서버 소프트웨어에서 이것이 가능해지면, 오늘날의 개발 방식은 끝날 것임 기능, 수정, 경험의 축적은 여전히 가치가 있으니 프로젝트와 저장소는 남겠지만, 프로그래머의 역할은 지금까지 Linus가 커널에 해온 역할과 매우 비슷해질 것임 DeepSeek v4 추론 엔진 같은 일부 프로젝트에서는 이미 그런 식으로 작업 중임 - array/regex가 기대되고, LLM으로 능력을 확장한 경험도 매우 흥미로움. 여러 프로젝트에서 조용히 비슷한 시도를 하는 사람이 많음 **바이브 코딩**과 그에 대한 반발만으로는 이런 작업 방식을 제대로 설명하지 못함 - 나는 에이전트를 쓴 방식을 전혀 **바이브 코딩**이라고 보지 않음. 너무 깊이 관여하고, 모든 것을 검증·확인·리뷰하기 때문임 - “바이브 코딩”의 문제는 그 용어를 만든 사람이 아주 구체적인 정의를 붙였다는 데 있음. 코드를 보지 않고 그냥 “감”으로 소프트웨어를 만드는 것임 그런데 곧 사람들이 거의 모든 형태의 AI 보조 코딩에 이 말을 쓰기 시작하면서 원래 의미가 빠르게 사라졌음 - 요약하면, 이제 **Redis를 신뢰할 수 없게 됨** LLM 없는 포크는 누가 만들 건가? - 제시된 사용 사례 중 일부는 **ZSET**으로도 가능하지 않나? 성능 관점은 이해하지만, 배열이 선택적으로 희소 표현을 쓰듯 조밀한 값에 대해 ZSET 저장 방식을 선택적으로 최적화하면 새 API 표면 없이도 가능했을 것 같음 정규식 구성요소는 흥미롭지만, 여기서도 언급됐듯 배열 자료구조와는 직교적인 기능으로 보임. 즉 다른 구조에서도 쓸 수 있음. 이건 Lua 스크립팅으로 하는 편이 더 맞지 않나? Lua 성능이 문제라면, 값 범위를 반환하는 어떤 명령 위에도 조합할 수 있도록 OP를 추상화하는 방법도 있을 듯함 Antirez가 이 분야 전문가라는 점은 존중하지만, 이 새 기능 집합 일부는 LLM 주도 개발에서 자주 보이는 해법처럼 느껴짐. 기존 기능을 개선하기보다 새 기능을 만들고, 다른 기능과 조합하는 편이 더 효과적일 수 있는데 기능을 과하게 복잡하게 만드는 식임 - 아쉽게도 그렇지 않음. 정렬 집합은 스펙트럼의 거의 반대쪽에 있음. 의미론적으로는 깔끔하지만, **스킵 리스트와 배열의 결합** 때문에 매우 낭비적임 또한 내부 표현이 배열이 아니라면 범위 질의와 링 버퍼는 필요한 만큼 효율적이고 압축적으로 동작할 수 없음 이론적으로는 무엇으로든 무엇이든 할 수 있지만, 각 API가 할 수 있는 일을 분리해야 사용 사례를 활용해 최적의 내부 구현을 제공할 수 있음 - antirez에게 궁금함. 최종 코드로 사실상 **원샷 생성**을 실험해봤는지? GEPA로 거기까지 갈 수 있을지, 원하는 결과를 끌어내는 유도나 프롬프트 방식에서 배울 점이 있을지도 궁금함 아니면 결론은 모델 제공자들이 학습 데이터를 정리해야 한다는 것일 수도 있음 - Salvatore가 **Automatic Programming/Coding**이라는 용어를 대중화하고 싶어 하는 것 같음. ([https://antirez.com/news/159]()) - [https://en.wikipedia.org/wiki/Automatic_programming]()은 컴퓨터과학에서 인정된 용어로, 더 높은 추상 수준의 설명으로부터 코드를 자동 생성하는 모든 메커니즘을 가리킴 물론 LLM은 비결정적이고 범위가 놀랄 만큼 넓다는 점에서 매우 특이하지만, 그렇다고 이 용어가 적용되지 않는 것은 아님 - 같은 일을 설명하는 말을 나도 점점 줄이게 됨. 시간이 갈수록 우리가 “그” 작업을 더 자주 하게 되기 때문임 다만 용어를 **auto-code**로 줄이면 도움이 될 수도 있음 - 아주 숙련된 개발자들이 요즘 AI와 어떻게 상호작용하는지 보는 건 늘 흥미로움 @antirez: 프로젝트 후반에 겉보기에는 별개의 기능인 **정규식 기능**을 도입한 건 조금 이상하게 느껴짐. 그 판단 근거를 더 설명해줄 수 있나? - 배열이 텍스트 파일에 아주 잘 맞는다는 걸 깨닫고 나니, 떠올릴 수 있는 많은 사용 사례가 결국 파일에서 grep이 필요하다는 사실에 막혔음 그래서 파일에서 AROP에 해당하는 것이 뭘까 생각했고, 답은 ARGREP이었음 이후 사용 사례에 따라 최적 도구를 쓸 수 있도록 빠른 정확 일치와 정규식 일치를 모두 넣었음 그러다 OR로 묶인 여러 문자열에서는 정규식이 잘 최적화되면 더 빠를 수 있다는 걸 발견했고, TRE를 조금 특화했음