Node.js 24와 Fastify v6 — 왜 fast-json-stringify를 버렸을까

Fastify v6가 오랜 정체성이었던 자체 직렬화 엔진 fast-json-stringify를 과감히 제거했습니다. Node.js 25에 탑재된 V8 엔진의 네이티브 JSON.stringify 성능이 획기적으로 개선되면서, 굳이 복잡한 스키마 컴파일을 거치지 않아도 압도적인 속도를 낼 수 있게 되었기 때문입니다. 덕분에 Fastify는 3,000줄이 넘는 코드를 덜어내며 프레임워크를 극적으로 경량화하는 동시에, 최신 런타임의 최적화 이점을 고스란히 확보하는 아키텍처 전환을 이루어냈습니다.

Node.js 24와 25에서 일어난 V8 JSON.stringify 최적화

웹 서버나 API 서버를 개발할 때, 결국 가장 많은 CPU 연산 시간을 잡아먹는 주범은 언제나 JSON 직렬화였습니다. 우리가 즐겨 쓰던 Fastify 역시 이 직렬화 병목을 해결하기 위해 개발자가 정의한 스키마를 미리 컴파일해 문자열로 조립하는 'fast-json-stringify'라는 무시무시한 서드파티 엔진을 자체적으로 탑재해 활용해 왔죠.

하지만 Node.js 25에 탑재된 V8 13.8 엔진을 비롯한 최신 런타임의 최적화로 인해 이 패러다임이 완전히 뒤흔들렸습니다. 굳이 복잡한 컴파일 라이브러리를 동원하지 않더라도, 네이티브 JSON.stringify만으로 기존 커스텀 컴파일 엔진과 대등하거나 오히려 앞서는 성능을 낼 수 있게 되었기 때문입니다. 이 놀라운 아키텍처 개선은 다음과 같은 몇 가지 영리한 최적화 메커니즘을 유기적으로 결합한 결과입니다.

이제 개발자는 복잡한 최적화 라이브러리를 전전하며 유지보수 리소스를 낭비할 필요가 없어졌습니다. 단지 Node.js 버전을 올리는 단순한 인프라 작업만으로도, 백엔드의 가장 고질적인 연산 부하를 런타임 자체 엔진을 통해 말끔히 해소할 수 있게 되었습니다.

Fastify v6의 대담한 결정: 3,000줄의 커스텀 엔진 삭제

Fastify v6가 3,000줄이 넘는 커스텀 직렬화 엔진을 과감히 제거한 이유는, 최신 Node.js 환경에서 더 이상 복잡한 런타임 컴파일 방식을 유지할 실리가 사라졌기 때문입니다. Fastify 개발팀은 깃허브 풀 리퀘스트 6507을 통해 기존의 fast-json-stringify 라이브러리 의존성을 완전히 들어냈습니다. 이로써 성능 극대화를 위해 감수해야 했던 애플리케이션 초기 구동 시의 컴파일 오버헤드와 거대한 커스텀 엔진의 유지보수 부담이 단번에 해결되었습니다.

이러한 구조적 변화가 단순한 코드 정리를 넘어 충분한 고성능을 보장하는 비결은 Node.js 25 환경의 벤치마크 결과에서 고스란히 드러납니다. 다음은 네이티브 직렬화와 기존 커스텀 컴파일러의 처리량을 직접 비교한 수치입니다.

실제 프로덕션 API 환경에서 가장 빈번하게 오가는 대용량 배열이나 표준 객체 포맷에서는 오히려 네이티브 API의 성능이 기존 엔진을 추월했습니다. 스키마 프리포맷팅 덕분에 날짜 데이터나 아주 짧은 문자열 구조에서 기존 엔진이 앞서는 영역도 존재하지만, 프레임워크가 안고 가야 할 복잡한 코드 유지보수 비용에 비하면 그 실익이 크게 낮아졌습니다. 결국 런타임 자체의 고도화가 서드파티 라이브러리의 인위적인 튜닝을 압도하기 시작한 것입니다.

직렬화 분리와 Ajv 기반의 응답 스키마 검증 패턴

Fastify v6에서 응답 스키마는 더 이상 직렬화를 가속하거나 출력 데이터를 걸러내는 역할을 하지 않습니다. 직렬화는 V8 엔진의 초고속 네이티브 JSON.stringify가 전담하고, 개발자가 선언한 응답 스키마는 오직 Ajv 엔진을 통한 선택적 데이터 유효성 검증 목적으로만 작동합니다. 두 역할이 완전히 분리되면서 아키텍처는 한층 명확해졌지만, 기존 사용 방식을 바꿀 때 반드시 주의해야 할 점이 있습니다.

과거 버전에서는 응답 스키마에 정의하지 않은 속성이 직렬화 과정에서 자동으로 제외되었습니다. 하지만 v6부터는 네이티브 직렬화를 사용하므로, 스키마에 없는 필드도 필터링 없이 그대로 클라이언트에 노출됩니다. 민감한 데이터가 누출되는 사고를 막으려면 응답 객체를 비즈니스 로직 단에서 직접 정제하거나, 명시적으로 응답 검증 단계를 활성화해야 합니다.

다음은 Fastify v6에서 응답 스키마를 사용하는 간단한 예시입니다.

fastify.get('/user', {
  schema: {
    response: {
      200: {
        type: 'object',
        required: ['id', 'name'],
        properties: {
          id: { type: 'integer' },
          name: { type: 'string' }
        }
      }
    }
  }
}, async (request, reply) => {
  // v6 주의: 스키마에 없는 'role' 필드가 필터링되지 않고 그대로 출력됩니다.
  return { id: 1, name: '마루', role: 'admin' };
});

이처럼 응답 검증과 직렬화의 결합을 끊어냄으로써 개발자는 필요한 곳에만 선택적으로 검증 비용을 지불할 수 있게 되었습니다. 성능 최적화가 필요하지 않은 내부 API라면 검증을 아예 생략해 응답 속도를 최대로 끌어올릴 수 있습니다.

지금 준비해야 할 마이그레이션 전략

Node.js 버전을 최신 LTS 이상으로 올리는 것만으로도, 복잡한 아키텍처 변경 없이 직렬화 과정의 CPU 리소스를 크게 줄일 수 있습니다. 이제는 커스텀 최적화 라이브러리에 의존하기보다, 런타임 표준 스펙의 엔진 레벨 최적화를 적극적으로 활용할 때입니다. Fastify v6 도입을 앞두고 있다면 기존의 스키마 필터링 동작에 의존하던 코드를 찾아내고, 네이티브 직렬화 스펙에 맞게 객체 구조를 명확히 정리해 두는 선제적인 리팩터링을 권장합니다.

참고 링크