Redis array: 긴 개발 과정의 짧은 이야기

• 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에 정리돼 있음

구현과 검토

• 두 번째 달부터 자동 프로그래밍 방식으로 구현을 시작하면서 생성된 코드를 계속 검토함
• 구현이 동작한 뒤에도 sparsearray.c와 t_array.c를 포함한 코드를 한 줄씩 읽으며 검토함
• AI 덕분에 테스트가 많았지만, 표면적으로 동작하는 코드가 최적이라는 뜻은 아니어서 작은 비효율과 설계 오류를 찾아 수정함
• 여러 모듈을 수동 및 AI 보조 방식으로 다시 작성했고, 세 번째 달에는 다양한 방식으로 스트레스 테스트를 진행함
• 고품질 시스템 프로그래밍에서는 여전히 사람이 완전히 관여해야 하지만, AI가 있으면 32비트 지원 추가와 테스트처럼 피로도가 큰 작업과 복잡한 알고리듬의 명백한 버그 탐지에서 안전망이 됨
• 초기의 큰 명세 작성은 이후 작업의 핵심이었고, 코드의 모든 줄을 검토하며 맞지 않는 부분을 수정하는 데도 중요했음

사용 사례와 정규표현식

• 사용 사례를 모델링하던 중 Markdown 파일을 Redis 배열에 넣기 시작했고, 파일이 배열 데이터 타입과 잘 맞는다는 결론에 이름
• 에이전트 작업에 필요한 Markdown 파일 기반 중앙 지식 베이스를 만들기 위해 ARGREP 구현으로 이어짐
• 정규표현식 지원을 위해 TRE를 선택했으며, Redis에서 정규표현식을 사용할 때 시간이나 공간 측면의 병리적 패턴이 없어야 한다는 이유가 있었음
• TRE는 foo|bar|zap 같은 유용한 패턴 매칭에서 매우 비효율적이어서, GPT의 도움으로 최적화하고 잠재적 보안 문제 몇 가지를 수정했으며 테스트도 확장함
• 사용 사례는 Redis PR #15162에 자세히 정리돼 있으며, 숫자 인덱스가 의미의 일부가 되는 데이터 타입이 Redis에 필요하다는 결론으로 이어짐
• Array PR이 곧 받아들여지고, 새 사용 사례의 이점을 얻을 수 있기를 기대하며 피드백을 요청함