Rust Rewrite on Nabi Runtime¶

Umbra 의 장기 방향. Go 스택은 의도적 중간 단계이며, 진욱의 Rust 숙련도와 Nabi 런타임 성숙도가 충족되면 Go → Rust 재작성을 진행한다. 이 문서는 그 로드맵을 정리한다. 착수 결정은 별도 ADR 로 기록된다.

Phase¶

Phase 3+ (MVP + Phase 2 이후, 시점 미정)

Why this phase¶

Umbra 의 Go 선택(ADR-0001)은 "현재 팀 조건에서 가장 합리적인 타협" 이었다. 장기 방향은 Rust 이며, 이는 네 가지 이유에서다.

첫째, Pablo 의 기술 비전 — Rust 의 타입 시스템과 zero-cost abstraction 이 결제/복구/권한 같은 신뢰성 크리티컬 영역에 이상적이다.

둘째, Nabi 런타임의 프로덕션 검증 — Pablo 가 개발 중인 Nabi 런타임의 첫 프로덕션 사용처로 Umbra 가 적합하다.

셋째, 진욱의 Rust 성장 기회 — Go 로 실무 경험을 쌓은 후 Rust 로 자연스럽게 확장하는 성장 경로.

넷째, 장기 유지보수성 — 결제 SaaS 는 5년+ 운영을 전제로 하며, 초기 언어 선택이 평생은 아니다.

이 문서는 "Umbra 가 결국 어디로 가는가" 를 명시하여 현재 Go 개발에도 언어 무관 원칙 을 적용하게 만든다. 즉 이 로드맵의 존재 자체가 현재 설계에 영향을 준다.

Goals¶

Business goals¶

Rust 재작성 기간 동안에도 서비스 무중단
사용자 체감 품질 유지 또는 향상
Nabi 런타임 레퍼런스 프로젝트로 활용

Technical goals¶

전 도메인 Rust 재작성 (apps/web 제외)
Nabi 런타임 위에서 안정 운영
성능 벤치마크 개선 (latency, throughput)
타입 안전성 강화 (Go 의 런타임 에러 → Rust 의 컴파일 에러)

Trigger conditions¶

다음 4가지 조건이 모두 충족 될 때 착수 ADR 작성:

진욱 Rust 숙련도 — 단독으로 한 도메인 설계/구현 완료 경험 확보
Nabi 성숙도 — Discord WebSocket, HTTP, PostgreSQL, Redis, Temporal client 인터페이스 stable
Go 스택의 명확한 한계 관측 — 유지보수 부담, 성능 병목, 또는 특정 기능 구현 난이도
MVP + Phase 2 안정기 진입 — 기능 개발이 정체기 또는 수익이 재작성 기간을 감당 가능

조건 충족 전까지는 이 문서는 로드맵 참조 자료 로만 유효하며, 실제 재작성 작업은 착수하지 않는다.

In scope (재작성 시)¶

Backend rewrite¶

apps/bot → Rust + twilight-rs (또는 동등 라이브러리) + Nabi
apps/api → Rust + axum (또는 동등) + Nabi
apps/worker → Rust + Temporal Rust SDK + asynq 대체
engine/* → 도메인 코어 Rust 재작성
platform/* → 인프라 유틸 Rust 재작성

Runtime migration¶

Nabi 런타임 적용
Tokio 대비 이점 검증 (또는 Nabi 미성숙 시 Tokio fallback)

Tooling migration¶

sqlc → sqlx (compile-time 쿼리 검증)
swag → utoipa (OpenAPI)
Atlas → refinery 또는 Atlas Rust
golangci-lint → clippy
OpenTelemetry Rust SDK

Test migration¶

Behavior 중심 테스트 이식
기존 edge case 테스트 재확인
벤치마크 수립 (Go 대비 성능 비교)

Out of scope¶

Frontend (apps/web) — TypeScript 유지
Database schema — 그대로 (PostgreSQL 은 언어 무관)
Infrastructure — Fly.io / Vercel / Neon 그대로
API contract — OpenAPI spec 재사용 (apps/web 변경 최소화)
docs/ — 기존 문서 유지, Rust 관련 내용만 추가

Guiding principles (지금부터 적용)¶

재작성 시점이 언제든 이 원칙을 현재 Go 개발에 즉시 적용 한다. 이것이 재작성 비용을 결정적으로 낮춘다.

1. 도메인 모델 언어 무관 설계¶

Core 도메인(engine/recovery, engine/licensing, engine/billing)은 Go 특유 패턴에 종속되지 않음
chan, errgroup, context.Context 는 adapter 레이어에만 사용
도메인 entity 는 단순 struct + method

2. 이벤트 payload 는 JSON 표현 가능¶

Outbox 이벤트 payload 는 순수 데이터
Go interface, func, 복잡한 generic 금지

3. SQL 재사용 가능¶

sqlc 쿼리는 PostgreSQL 표준 SQL
ORM 마법 금지 (ADR-0005 준수)

4. OpenAPI contract 재사용¶

API 계약은 언어 무관 (ADR-0030)
Rust 재작성 후에도 같은 spec 유지

5. 테스트는 behavior 중심¶

"이 도메인이 이 입력에 이 출력을 낸다" 수준 테스트
Go 구현 세부에 의존하는 테스트 최소화

Dependencies¶

Nabi 런타임의 Discord WS, HTTP, Postgres, Redis, Temporal client 인터페이스 stable
진욱의 Rust 실무 숙련도 (ADR-0031 조건)
MVP + Phase 2 완료
Rust Discord 라이브러리 성숙 (twilight-rs 또는 대안)

Success criteria¶

재작성 완료 판단 기준:

기능 동등성 — 재작성 후 MVP + Phase 2 기능 전부 작동
성능 벤치마크 — latency, throughput 이 Go 버전 대비 동등 이상
안정성 — 재작성 후 3개월 내 critical incident 0 건
Nabi 검증 — 프로덕션 운영으로 Nabi 런타임 이슈 0 또는 조기 식별

Risks¶

Nabi 런타임 미성숙¶

Likelihood — Medium
Impact — High (재작성 차단)
Mitigation — Trigger condition 2 로 명시. Nabi 미충족 시 Tokio fallback 가능

재작성 기간 동안 기능 개발 정체¶

Likelihood — High
Impact — Medium
Mitigation — 점진 마이그레이션 (incremental), 수익 안정기에 착수

성능 회귀¶

Likelihood — Low
Impact — Medium
Mitigation — 도메인별 벤치마크 필수, 회귀 발견 시 해당 도메인 Go 재유지

진욱 학습 곡선 재발¶

Likelihood — Medium
Impact — High
Mitigation — Go 경험이 누적된 후 착수, Pablo 가 Core 선구현

팀 규모 확장 시 Rust 신규 채용 난이도¶

Likelihood — Medium
Impact — Medium
Mitigation — 재작성 시점에 팀 규모가 작으면 리스크 낮음. 성장 후 평가

Migration strategy¶

Incremental migration 을 원칙으로 한다. Big-bang 은 리스크가 크다.

Phase A: Bridgehead¶

1개 Supporting 도메인 (Identity 또는 Guild) 을 Rust 로 재작성.

Go 와 Rust 서비스가 공존
gRPC 또는 공유 DB 로 통신
Nabi 런타임의 실제 프로덕션 검증

Phase B: Core domain migration¶

Recovery 먼저, 이어서 Billing, Licensing.

도메인 단위로 재작성 + 배포
각 도메인의 벤치마크 비교
이슈 발견 시 해당 도메인 롤백 가능

Phase C: Full rewrite¶

모든 도메인 Rust 화.

Go 프로세스 retire
Fly.io 배포 전환
문서 업데이트

Big-bang fallback¶

인프라 교체 비용이 크거나 Phase A 가 명확한 이점을 보이지 못하면 big-bang 재평가. 단 이 경우 기능 동결 기간 필요.

Timeline¶

구체적 날짜 없음. Trigger condition 충족 시점부터 시작하며 각 Phase 는 대략 3~6개월.

gantt
    title Rust Rewrite Timeline (approximate)
    dateFormat YYYY-MM-DD
    section Prerequisites
    Trigger conditions 충족 :2027-01-01, 180d
    착수 ADR 작성 :2027-07-01, 30d
    section Phase A
    Identity 도메인 Rust 재작성 :2027-07-15, 90d
    Nabi 프로덕션 검증 :2027-09-01, 60d
    section Phase B
    Recovery 재작성 :2027-10-15, 120d
    Billing 재작성 :2028-01-15, 90d
    Licensing 재작성 :2028-03-15, 60d
    section Phase C
    나머지 도메인 재작성 :2028-05-01, 120d
    Go 프로세스 retire :2028-08-15, 30d

위 타임라인은 예시이며 조정 가능. Trigger 조건 충족 시점이 주 변수.

Next phase¶

Rust 재작성 완료 후:

Nabi 런타임의 공식 첫 프로덕션 사례로 documentation
다른 Luxtra 프로젝트에 Nabi + Rust 스택 확산 검토
Umbra 의 성능/안정성 벤치마크 공개 (오픈소스 기여 고려)