101개 엔드포인트를 다시 짜며 배운 것: Django vs Rust, 그리고 AI 코딩의 진짜 비용
"서비스를 닫기는 너무 아쉽고, 서버비는 매달 나가는데, 전담 개발자를 계속 고용할 여력은 없다면 어떻게 해야 할까?"
실제 수년간 운영되어 온 101개 엔드포인트 규모의 위치 기반 소셜 백엔드를 Django에서 Rust(Axum + SQLx)로 완전히 다시 작성하면서 마주했던 현실적인 고민이다.
흔히 AI 시대에는 빠른 개발 속도가 최우선이니 파이썬 같은 동적 언어가 무조건 유리하다고 말한다. 러스트는 엄격한 규칙 때문에 AI가 토큰만 낭비할 것이라는 우려도 많다. 하지만 101개 엔드포인트를 전부 AI 에이전트로 포팅하고 실제 운영을 이어가며 측정한 데이터는 전혀 다른 가능성을 보여주었다.
이번 작업에서 얻은 실측 수치와 함께, 이 방식이 갖는 명확한 한계와 소규모 팀에게 열린 새로운 생존의 길을 기록해본다.
1. 코드량 실측: 176개 파일의 분산 vs 51개 파일의 응집
기존 Django 백엔드와 새로 작성한 Rust 백엔드는 완전히 같은 기능(PostGIS 기반 위치 쿼리, JWT 인증, 푸시 알림, 결제/포인트 등 101개 API)을 수행한다. 두 코드베이스의 물리적 수치는 이렇다.
| 항목 | Django (DRF) | Rust (Axum + SQLx) | 차이와 특징 |
|---|---|---|---|
| 소스 파일 수 | 176개 (.py) | 51개 (.rs) | Rust가 71% 적음 (도메인 응집) |
| 전체 소스 라인 (LOC) | 11,856 라인 | 12,380 라인 | 전체 라인 규모는 유사 (+4%) |
| 실제 실행 코드 (Code) | 9,618 라인 | 10,158 라인 | Rust가 약 5% 많음 |
| 순수 비즈니스 로직 | 약 6,200 라인 | 약 10,158 라인 | Rust가 1.6배 더 긺 (명시적) |
| 파일당 평균 라인 수 | 약 67 라인 (파편화) | 약 243 라인 (단일 완결) | 구조적 차이 뚜렷 |
Django는 ORM과 Serializer의 메타프로그래밍 덕분에 비즈니스 로직 자체는 6,200라인으로 짧다. 하지만 코드가 models/, views/, serializers/, services/, urls.py로 잘게 쪼개져 176개 파일에 흩어져 있었다.
반면 Rust는 요청/응답 구조체, SQL 쿼리, 에러 처리를 전부 명시적으로 써야 해서 코드가 1만 라인으로 늘어났다. 대신 라우트 파일 하나에 입출력과 쿼리를 모두 모아두어 파일 수는 51개로 줄었다.
2. 개발 비용: 토큰은 러스트가 40% 더 썼다
AI 에이전트를 통해 101개 엔드포인트를 구현할 때 소모된 예상 토큰량을 단계별로 비교해보면 이렇다.
| 개발 단계 | Django (Python) | Rust | 비고 |
|---|---|---|---|
| 1. 기본 세팅 및 인증 구조 | 약 250만 토큰 | 약 350만 토큰 | Rust의 타입 정의 및 초기 보일러플레이트 |
| 2. 101개 엔드포인트 구현 | 약 2,200만 토큰 | 약 3,300만 토큰 | 엔드포인트당 Rust가 1~2턴 더 소요 |
| 3. 테스트 및 정합성 검증 | 약 1,200만 토큰 | 약 1,500만 토큰 | 컴파일 검증 vs 런타임 디버깅 |
| 4. 배포 및 인프라 스크립트 | 약 150만 토큰 | 약 250만 토큰 | 크로스 컴파일 및 바이너리 패키징 |
| 총 토큰 소모량 | 약 3,800만 토큰 | 약 5,400만 토큰 | Rust가 약 42% 더 소모 |
| 순수 AI API 비용 (추정) | 약 16만 원 ($120) | 약 27만 원 ($200) | Sonnet/Opus 혼합 기준 |
러스트가 토큰을 약 40% 더 썼다. 명시적인 타입과 SQL 작성량 자체가 많았고, cargo check와 소유권 규칙을 통과하기 위해 AI가 수정 ➔ 에러 확인 ➔ 재수정하는 턴이 엔드포인트당 1~2회 더 발생했기 때문이다.
3. 구조의 힘: 왜 AI는 Flat 아키텍처에서 덜 헤맸을까?
토큰은 더 썼지만, 실제 개발 과정에서 AI의 작업 성공률은 Rust 쪽이 훨씬 높았다. 파이썬에서는 문법적으로 맞아도 런타임에 `NoneType` 에러가 나거나 시리얼라이저 필드가 슬그머니 누락되는 ‘침묵의 버그’가 잦았다.
반면 Rust에서는 컴파일러가 가장 저렴하고 정확한 채점관 역할을 해줬다. 특히 라우트 파일 하나에 DTO와 SQL 쿼리를 함께 담는 평탄한 수직 슬라이스(Vertical Slice) 아키텍처를 채택하면서, AI는 5개 파일을 넘나들 필요 없이 단 1개 파일 안에서 맥락을 끝낼 수 있었다.
(※ AI가 왜 복잡한 계층 구조보다 평탄한 아키텍처에서 높은 성공률을 보이는지는 학술 연구 리뷰: AI 에이전트는 왜 클린 아키텍처를 싫어할까 글에 연구 배경을 정리해두었다.)
4. 운영 비용(TCO)과 유지보수의 반전
진짜 가치는 배포 후에 나타났다. 매달 나가는 클라우드 인프라 비용과 관리 품이 극적으로 줄어들었다.
| 비용 항목 | Django (Gunicorn 8 Workers) | Rust (Axum 단일 프로세스) |
|---|---|---|
| 서버 사양 (AWS EC2) | t4g.xlarge (월 13만 원) | t4g.micro (월 2만 원) |
| 메모리 점유율 (RSS) | 1.6 GB ~ 2.0 GB | 20 MB ~ 40 MB (98% 감소) |
| P99 응답 속도 | 50ms ~ 200ms | 1ms ~ 5ms |
| Sentry 500 에러 | 월 수만 건 (키 누락, 타입 에러) | 0건에 수렴 |
| 유지보수 AI 토큰 | 사이드이펙트 추적으로 지속 소모 | 타입 에러 지점만 즉시 수정 |
[연간 총 운영 비용(TCO) 추정]
- Django : 서버비(160만 원) + 에러 대응(80만 원) + 유지보수 토큰(50만 원) = 약 290만 원
- Rust : 서버비(24만 원) + 에러 대응(0만 원) + 유지보수 토큰(20만 원) = 약 44만 원
────────────────────────────────────────────────────────────────────────
➔ 1년에 약 246만 원 절감 (초기 개발에서 더 쓴 토큰값 11만 원은 2주 만에 회수)5. 솔직한 한계: 언제 이 선택이 틀릴 수 있는가?
이 결과를 모든 프로젝트에 일반화할 수는 없다. 적대적 관점에서 보면 다음과 같은 분명한 한계가 존재한다.
- 신규 서비스(Day 0) vs 포팅의 차이
이번 프로젝트는 이미 수년간 검증된 101개 엔드포인트의 스펙(JSON 입출력, DB 스키마)이 완벽히 존재하는 상태에서의 '포팅'이었다. 기획이 하루에도 몇 번씩 바뀌는 극초기 스타트업이라면 동적 타이핑과 빠른 마이그레이션을 지원하는 Django/Python이 여전히 우위에 있다. - 인프라 비용 vs 인건비의 맹점
연간 246만 원의 서버비 절감은 자금이 넉넉한 조직에게는 시니어 개발자 며칠 치 인건비에 불과하다. 만약 문제가 생겼을 때 Rust 엔지니어를 새로 채용해야 한다면 인건비 리스크가 훨씬 커질 수 있다. - 전역 규칙 변경 시의 중복 관리
Flat 아키텍처는 개별 기능 수정에는 유리하지만, 전역 권한 정책이나 공통 비즈니스 룰이 바뀔 때는 여러 라우트 파일에 흩어진 쿼리를 빠짐없이 손봐야 하는 부담이 있다.
6. 그럼에도 남는 진짜 의미: "서비스의 생명 연장"
그럼에도 불구하고 이번 실험이 우리에게 준 가장 큰 교훈은 "소규모 팀과 성숙기 서비스를 위한 새로운 생존 방식"을 발견했다는 점이다.
수많은 스타트업과 프로젝트들이 비슷한 위기를 겪는다. 사용자가 여전히 존재하고 서비스에 애정이 남아 있어 서비스를 닫기는 너무나 아쉽지만, 매달 수십만 원씩 나가는 서버비가 부담스럽고 전담 개발팀을 유지할 여력은 없는 순간이 찾아온다. 결국 유지보수 인력 부재와 자정의 서버 장애를 감당하지 못해 서비스를 조용히 종료하곤 한다.
하지만 이번 시도를 통해 다른 길이 열렸다.
- 기존에 검증된 스펙을 바탕으로 AI 에이전트와 함께 Rust + Flat 아키텍처로 안전하게 전환해두면,
- 서버는 가장 작은 마이크로 인스턴스(월 1~2만 원)에서도 수천 접속을 거뜬히 버티고,
- 타입 시스템 덕분에 알 수 없는 500 에러와 야간 장애 알림이 사실상 사라지며,
- 가끔 생기는 유지보수나 의존성 업데이트는 전담 개발자 채용 없이 1인 창업자가 AI 에이전트와 함께 안전하게 처리할 수 있게 된다.
AI 덕분에 러스트의 진입 장벽이 낮아졌고, 러스트 덕분에 서비스의 수명은 거의 영구히 늘어났다. 개발자를 더 둘 수 없어 사라질 뻔했던 서비스들에게, AI와 견고한 언어의 결합은 든든한 '생명 연장 장치'가 되어주고 있다.