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

Source: Hacker News

antirez – 40 minutes ago · 3545 views

나는 1월 초에 Redis용 새로운 Array 데이터 타입 작업을 시작했다. PR은 이제서야 저장소에 머지됐으며, 이 코드는 4개월 동안 준비된 것이다. 구현 작업은 파트‑타임으로 진행했지만(몇 주는 실제로 풀‑타임이었다; 키보드에서 손을 떼는 것이 복잡할 수 있다), LLM이 등장하기 전에도 이 구현은 4개월 안에 할 수 있는 수준이었다. 바뀐 점은 같은 기간 동안 내가 훨씬 더 많은 일을 할 수 있었다는 것이다. 이것이 일어난 일에 대한 짧은 이야기다.

Specification (Month 1)

• 다음을 포함한 상세 사양 문서를 작성함:
  • 새로운 데이터 타입에 대한 근거
  • 사용된 C 구조체와 희소 표현 방식
  • 링 버퍼와 ARINSERT에 대한 배열 커서의 정확한 의미
• 처음에는 사양을 손으로 초안 작성한 뒤 Opus와 페어링했으며, 이후 GPT‑5.3(그리고 이후 GPT‑5.x)으로 설계와 개발을 전환함.
• 사양은 피드백과 설계에 대한 지적 도전, 타협, 과도한 엔지니어링 방지를 거치며 발전함.

Implementation (Month 2)

• AI 지원을 받아 자동 프로그래밍을 시작하고, 생성된 코드를 지속적으로 검토함.
• 초기 간접 레이어(디렉터리 + 슬라이스)가 ARSET myarray 293842948324 foo 같은 명령에 대해 거대한 할당 없이는 충분하지 않다는 것을 발견함.
• 설계를 슬라이스된 밀집 디렉터리들의 슈퍼 디렉터리로 수정했으며, 각 디렉터리는 배열 슬라이스(기본 4096 요소 per 슬라이스)를 가리킴.
  • 이는 “실제로 배열”이라는 표현을 유지하고, 메모리 특성 목표를 만족시키며, ARSCAN과 ARPOP이 범위가 아니라 기존 요소 수에 비례하는 시간에 실행되도록 함.

Review & Optimization (Month 3)

• 라인‑바이‑라인 코드 리뷰를 수행함; AI‑생성 테스트가 대부분의 경우를 커버했지만 겉보기 정확성이 최적화를 보장하지는 않음.
• 작은 비효율과 설계 오류를 식별하고, AI 도움을 받아 많은 모듈을 수동으로 재작성함.
• 다양한 시나리오에 대한 광범위한 스트레스 테스트를 수행해 구현의 견고함과 유용성에 대한 신뢰를 얻음.

Extending the Idea: ARGREP and Regular Expressions

• 사용 사례를 모델링하면서 Redis 배열에 마크다운 파일을 저장했으며, 이것이 중앙화된 지식 베이스에 아주 적합하다는 것을 깨달음.
• 이는 정규식 지원이 필요한 ARGREP을 만들게 함.
• 패턴이 시간·공간적으로 병리적일 경우 안전성을 제공하는 TRE 라이브러리를 선택함(감사: Ville Laurikari).
• TRE는 foo|bar|zap 같은 패턴에서 성능이 저조했으며, GPT 도움을 받아 라이브러리를 최적화하고 잠재적 보안 문제를 수정했으며 테스트 스위트를 확장함.

Reflections

• 고품질 시스템 프로그래밍은 여전히 전면적인 참여가 필요하지만, AI는 다음과 같은 안전망을 제공함:
  1. 대규모, 지루한 작업(예: 나중에 32‑bit 지원 추가 및 테스트)
  2. 복잡한 알고리즘에서 명백한 버그를 잡아주는 가상 인력
• 방대한 초기 사양 작성을 통해 sparsearray.c와 t_array.c에 대한 철저한 라인‑바이‑라인 리뷰가 가능했음.

Conclusion

자세한 사용 사례는 여기서 반복하지 않는다—PR 메시지에 문서화되어 있다:
Redis PR #15162

나는 이제 Redis가 숫자 인덱스를 의미론의 일부로 갖는 데이터 타입을 가져야 할 시점이라고 생각한다. Array PR이 곧 받아들여지고 커뮤니티가 새로운 사용 사례의 혜택을 누릴 수 있기를 바란다. 피드백을 환영한다. 감사합니다.