Dart 백엔드: 벤치마크 및 메모리 문제

서버 Dart: 프로덕션 부하에서 무너진 이유

SaaS 개발자가 메모리 사용량을 줄이기 위해 Node.js를 Dart로 교체했다. 기대: 시작 시 10MB vs 80MB, AOT 컴파일, 정적 타이핑. 현실: 2주 개발 시간, 커스텀 프레임워크, 성능이 더 나쁜 벤치마크. 교훈: 마이그레이션 전에 프로덕션 워크로드에서 원시 벤치마크를 꼭 실행하라.

인증 서비스(OAuth2, Redis ORM)가 테스트베드였다. Node.js는 최대 500MB까지 치솟았지만 메모리를 해제했다. 시작 시 80MB로 수백 인스턴스를 돌리는 게 핵심 문제였다.

생태계: 백엔드 도구가 보이지 않는다

Dart는 Flutter를 위해 만들어졌다. NestJS 같은 건 없고, ioredis 수준의 Redis 클라이언트도 거의 없다. Shelf는 기본 라우터일 뿐, Serverpod는 풀스택 Flutter 앱을 타깃으로 한다.

프레임워크를 처음부터 만들어야 했다:

• Angular 같은 트리 기반 DI.
• Zone을 통한 요청 스코핑.
• AOT용 코드 생성 CLI.

ts-oauth2-server와 ioredis를 포팅(4,500줄 Dart vs 23,500줄 TS). AI가 처리했지만 비용이 컸다: 실험적 --enable-experiment=enhanced-parts 플래그, 모든 곳에 part 'file.g.dart', 커밋 시트나 CI 생성.

AOT로 리플렉션이 사라졌다. Type은 스텁, 정적 메서드 호출 불가. 미러 없는 DI는 JIT → 미러 → 코드 생성 CLI가 필요하다. TS/Java/C#에서는 리플렉션 3줄이면 끝.

언어: 멋진 문법, 메타프로그래밍엔 최악

논리적 문법, 컴파일 타임 에러. 하지만 객체에 for...in 없음, 리플렉션 없음. 코드 생성은 악몽: .g.dart 참조가 소스 파일을 어지럽힌다.

AI가 ioredis를 기계적으로 포팅. 결과: pub.dev 최고 클라이언트보다 RPS +5%. 백엔드 생태계는 끝장—Dart로 서버 코드를 쓰는 사람은 없다.

벤치마크: 지연과 메모리가 죽인다

시나리오: 3개 엔드포인트, Postgres, Redis. 원시 HTTP, 프레임워크 없음. 100m CPU, 500 VUS.

| 지표 | Dart AOT | Node.js | Go |

|------|----------|---------|----|

| RSS 시작 | 3 MB | 18 MB | - |

| p95 지연 | 9.5초 | 5초 | 2.9초 |

| RPS | Node보다 2배 나쁨 | - | 전체 최고 |

| 최대 RSS | 39-47 MB | 37 MB | - |

Dart:

• 메모리를 OS에 반환 안 함(피크 후 >5%).
• GC가 압박 시: 60fps(Flutter) 튜닝, K8s RSS 아님.
• 스로틀링 시 47MB로 부풀음; Node는 줄어듦.

GC 플래그(--dontneed_on_sweep, --use_compactor) 소용없음. 설계상: 모바일 VM. K8s는 pod당 40MB 상시, HPA가 노드 팩킹 못 함. 시작 절감이 과잉 프로비저닝으로 날아감.

Cloud Run에서: Dart가 Node보다 비용 더 듦—느림 + 메모리 붙잡음.

주요 교훈:

• p95 지연 9.5초 vs Node 5초 = 프로덕션 실패.
• 메모리 해제 안 됨: 스케일링 과금.
• Flutter 밖 생태계 사망.
• repo에 벤치마크: K8s 매니페스트, CPU 프로파일, Dockerfile.

결론: Dart의 영역은 Flutter뿐

프레임워크, 포팅, 테스트에 2주 날림. Dart는 단순 코드에 빛나지만 서버는 실패. 리플렉션 없음, VM 클라우드 미준비, 코드 생성 지옥. Cloud Run용 "확장 가능한 API" 공약은 허공.

err != nil과 context.Context 때문에 Go 거부. Node.js 승: 메모리 해제, 지연 우수.

— Editorial Team