Azure의 Replication 기반인 RSL을 Rust로 '현대판'으로 다시 만든 이야기

• Azure의 Replication 기반인 RSL을 Rust로 “현대판”으로 다시 만든 이야기
• 100K행 이상의 Rust 코드를 AI coding agents를 사용하여 단기간에 구현
• 정확성 보장에는 「code contracts」가 상당히 효과적이었다
• Spec-Driven Development는 너무 무거운 운영보다 “경량판”이 적당하다
• 성능 개선에서는 23K ops/sec → 300K ops/sec까지 끌어올렸다
• 향후 AI 개발에는 테스트, 계약, 성능 개선의 자동화가 더 진전되기를 바란다는 본심이 담겨 있다

이 기사는 Cheng Huang 씨가 「AI coding agents를 사용하여 실제 프로덕션급 분산 시스템을 어디까지 만들 수 있는가」를 상당히 진지하게 시험해 본 기록입니다.

만든 것은 Rust 기반의 multi-Paxos consensus engine입니다.

Paxos는 여러 서버가 **“이 데이터의 순서나 내용으로 결정하자”**라고 합의하기 위한 메커니즘으로, 분산 시스템의 심장부와 같은 것입니다.

요컨대, 데이터를 여러 대에서 안전하게 일치시키기 위한 초중요 기술입니다.

게다가 이 프로젝트는 단순한 연구용 테스트가 아닙니다.

Azure의 RSL (Replicated State Library), 즉 수많은 Azure 서비스를 지탱하는 기반을 Rust로 현대의 하드웨어에 맞춰 다시 만드는, 상당히 야심 찬 내용입니다. 이 점은 솔직히 대단하다고 생각합니다. AI로 약간의 코드 보조를 받는 수준이 아니라, 프로덕션급 분산 시스템을 통째로 구축하고 있다는 점이 포인트입니다.

기사에 따르면 전체 기간은 약 3개월입니다.

그중,

약 4주 만에 100K행의 Rust 코드 구현
약 3주 만에 성능을 23K ops/sec에서 300K ops/sec로 개선

이라는, 상당히 이상치로 보일 법한 속도감을 보여줍니다.

물론 단순 비교는 할 수 없습니다. AI가 전부 알아서 작성한 것이 아니라, 저자 자신이 설계하고 리뷰하며 방향을 제시했기 때문입니다. 그럼에도 불구하고, 이것은 AI 시대 개발의 “성장 잠재력”을 상당히 강력하게 보여주고 있다고 생각합니다.

나아가 최종적으로는 130K행 초과, 1300건 이상의 테스트, 게다가 테스트가 코드베이스의 65% 이상을 차지하는 상태까지 진행되었습니다.

테스트 비중이 높은 것은 분산 시스템에서는 오히려 건전한 상태입니다. Paxos와 같은 것은 사소한 결함이 대형 사고로 이어지기 때문에 이 부분을 소홀히 할 수 없기 때문입니다.

Azure의 RSL은 강력하지만, 10년도 더 된 설계로 현재의 하드웨어나 워크로드에 완전히 맞지 않는다고 저자는 보고 있습니다. 구체적으로는 다음 세 가지가 과제였습니다.

No pipelining

하나의 투표 처리가 진행되는 동안에는 새로운 요청이 대기해야 합니다.
즉, 병렬로 처리할 수 없어 지연(latency)이 증가합니다.

No NVM support

NVM은 non-volatile memory, 즉 전원을 꺼도 내용이 유지되는 고속 기억 영역입니다.
현재 데이터 센터에서는 드물지 않으며, 잘 활용하면 커밋 시간을 크게 단축할 수 있습니다.

Limited hardware awareness

RDMA와 같은 현대의 고속 통신을 제대로 활용하지 못합니다.
RDMA는 서버 간에 CPU 부하를 억제하면서 고속으로 메모리에 액세스하는 기술입니다. 분산 시스템에서는 매우 중요합니다.

이 세 가지는 바꿔 말하면 **“예전에는 충분했지만, 지금 환경에서는 아쉽다”**는 이야기입니다.

저자는 그 부분을 Rust와 AI로 단번에 다시 만들고자 한 것입니다.

저자는 상당히 많은 AI 도구를 사용하고 있습니다.

• GitHub Copilot
• Claude Code
• Codex
• Augment Code
• Kiro
• Trae

현재 주력은 Claude Code와 Codex CLI이며, VS Code는 차이점 확인이나 세밀한 편집에 사용하고 있다고 합니다.

개인적으로는 이 “CLI 중심의 비동기 워크플로우”라는 이야기가 상당히 흥미롭습니다. 에디터 안에서 계속 기다리는 것이 아니라, 태스크를 던져두고 다른 일을 하면서 진행하는 것. AI 시대의 개발은 점점 「스스로 전부 타이핑하는 일」에서 「잘 지휘하는 일」로 변해가는구나, 라고 느낍니다.

나아가 저자는 Anthropic의 max plan에 월 100달러를 지불하고 있으며, 그것이 「자기 전에 Claude로 무언가 시작하지 않으면 손해 보는 기분이 들게」 만드는 구조라고 솔직하게 적고 있습니다.

이 부분은 상당히 인간적인 이야기라 마음에 듭니다. 비싼 구독료를 '본전을 뽑기 위한 행동 촉진 장치'로 만드는 발상은 꽤 효과가 있거든요.

Codex CLI가 나온 후에는 ChatGPT Plus를 하나 더 추가해서 요일별로 나누어 사용했다고 합니다. 무식한 방법 같지만, 현장감이 느껴집니다.

이 기사의 핵심 중 하나는 **코드 계약 (code contracts)**입니다.

이것은 간단히 말해, 함수에 대해 다음과 같은 사항을 명시하는 메커니즘입니다.

전제 조건 (precondition): 실행 전에 충족해야 하는 조건
사후 조건 (postcondition): 실행 후에 충족되어야 하는 조건
불변 조건 (invariant): 항상 지켜져야 하는 불변의 조건

테스트 중에는 **단언 (assert)**으로서 동작하게 하고, 운영 환경에서는 비활성화할 수 있으므로 성능을 너무 떨어뜨리지 않으면서도 안전성을 높일 수 있습니다.

저자는 이전부터 .NET에서 이 사고방식을 사용해 왔다고 하는데, AI와 결합하면 단번에 강력해진다고 말합니다. 이 부분은 상당히 설득력이 있습니다.

인간이 '대충 이 함수는 이렇게 동작할 것이다'라고 생각하는 부분을 AI에게 **언어화 (verbalization)**하게 함으로써 모호함을 줄일 수 있기 때문입니다.

저자는 계약 (contracts)을 다음 3단계로 사용하고 있습니다.

AI에게 계약 (contracts)을 작성하게 한다
GPT-5 High의 계약 (contracts)이 특히 좋았다고 합니다.
단, 저자는 리뷰와 수정을 담당합니다. -
계약 (contracts)으로부터 테스트를 생성한다
사후 조건 (postcondition)마다 테스트 케이스를 만듭니다.
이것은 AI가 잘하는 분야이며, 에지 케이스 (edge case)를 잘 잡아냅니다. -
속성 기반 테스트 (property-based tests)로 변환한다
이것은 상당히 강력합니다.
다양한 랜덤 입력을 대량으로 시도하여 계약 (contract) 위반을 찾아냅니다.
즉, '어쩌다 통과하는 테스트'가 아니라, '넓은 입력 공간에서 망가지지 않는지'를 탐색할 수 있는 것입니다.

실제로 AI가 작성한 계약 (contract)을 통해 Paxos의 안전성 (safety)과 관련된 미묘한 버그를 발견했다고 합니다.

이것은 중요합니다. Paxos는 '안전성 (safety)'이 생명이며, 이 부분이 무너지면 데이터 정합성 (data integrity)이 깨질 가능성이 있습니다.

즉, 이 계약 (contract)은 운영 사고의 싹을 상당히 이른 단계에서 잘라낸 것이 됩니다. 이 부분은 정말 가치가 크다고 생각합니다.

다음 주제는 **사양 주도 개발 (Spec-Driven Development, SDD)**입니다.

이것은 대략 말하자면, 갑자기 코드를 쓰는 것이 아니라 먼저 사양 (specification)을 쓰고, 설계를 쓰고, 태스크를 작성하며 진행하는 방식입니다.

저자는 처음에 상당히 엄격한 SDD 방식으로 작업했다고 합니다.

하지만 진행하다 보니 '문서의 정합성을 유지하는 것이 너무 힘들다'고 느꼈다고 합니다. 이 부분은 정말 공감이 갑니다. 사양서, 설계서, 태스크 목록, 구현이 모두 어긋나지 않도록 만드는 것은 현실적으로 상당히 무거운 작업이죠.

그래서 저자는 경량화된 SDD로 전환했습니다.

/specify로 사양 마크다운 (specification markdown)을 생성한다 -
거기에 사용자 스토리 (user story) (사용자 관점에서 하고 싶은 것)와 수락 기준 (acceptance criteria) (충족해야 할 조건)을 작성한다 -
/clarify로 AI에게 자기 비판을 시켜 개선안이나 누락된 부분을 도출한다 - 납득이 되면 계획 모드 (plan mode)로 진행한다 -
하나의 사용자 스토리 (user story) 단위로 구현한다

이 '1 사용자 스토리 (user story)가 AI에게 딱 적당한 작업 단위'라는 감각은 상당히 실천적이라고 생각합니다.

너무 큰 태스크는 AI가 길을 잃기 쉽고

• AI에게 모든 코드 경로(code path)에 latency metrics (지연 시간 지표)를 삽입하게 함
• performance test (성능 테스트)를 실행하여 trace logs (추적 로그)를 수집함
• AI에게 지연 시간의 내역을 분석하게 함
• 병목 현상(bottleneck)의 후보를 도출하게 함
• 하나씩 구현하고 다시 측정함

이 흐름은 화려하지는 않지만 매우 강력합니다.

특히 AI가 Python 스크립트를 작성하여 quantile (분위수)을 산출하거나, 병목 현상을 찾아내는 것은 상당히 "요즘 스타일"의 활용법이라고 생각합니다.

결과적으로 발견된 문제들은 예를 들어 다음과 같습니다.

• async path (비동기 경로)에서의 lock contention (잠금 경합)
• 불필요한 memory copy (메모리 복사)
• 불필요한 task spawn (태스크 생성)

최종적인 개선 포인트는... 자세한 내용은 아래의 전체 기사를 확인해 주세요.