Apache Fory 1.7.0: Kotlin·Scala JSON과 스트리밍 디코딩이 들어왔다

Apache Fory 1.7.0이 Kotlin·Scala 모델의 JSON 처리와 NDJSON·배열 스트리밍 디코딩을 추가했다. 지원 환경, 호환성, 도입 전 점검 사항을 정리한다.

Apache Fory 1.7.0: Kotlin·Scala JSON과 스트리밍 디코딩이 들어왔다

Apache Fory 1.7.0이 2026년 8월 28일 공개됐다. 이번 버전의 중심은 Kotlin과 Scala 애플리케이션이 표준 JSON을 다루는 새 모듈, 그리고 큰 JSON 배열과 NDJSON을 전부 메모리에 올리지 않고 처리하는 증분 디코더다.

공식 v1.7.0 릴리스 노트Apache Fory 공식 문서를 기준으로 지원 범위와 주의점을 확인했다. Fory는 Java, Python, Go, Rust, C++, JavaScript 등 여러 런타임에서 객체 직렬화와 교환을 지원하는 Apache 프로젝트다.

무엇이 바뀌었나

fory-json-kotlin 모듈은 Kotlin의 생성자 기본값, null 가능성, 부호 없는 정수, 값 클래스와 제네릭 인자를 보존한다. JVM, Android API 26 이상, GraalVM Native Image를 지원하며 kotlin-reflect를 요구하지 않는다. Android에서는 런타임 코드 생성이 꺼지므로 R8·ProGuard를 쓴다면 KSP 프로세서와 타입 등록을 함께 확인해야 한다.

dependencies {
    implementation("org.apache.fory:fory-json-kotlin:1.7.0")
}

Scala용 fory-json-scala는 Scala 2.13과 Scala 3의 case class, 기본 생성자 값, Option, Either, 튜플, 컬렉션과 값 클래스를 지원한다. 릴리스에는 Scala 3 열거형과 봉인 계층을 다루는 코덱 지원도 포함됐다. Scala 모듈은 Java 8 바이트코드를 대상으로 수정됐다.

libraryDependencies += "org.apache.fory" %% "fory-json-scala" % "1.7.0"

Java 쪽에는 최상위 JSON 배열과 줄 단위 JSON(NDJSON)을 UTF-8 청크로 읽는 증분 디코더가 추가됐다. 각 값이 완성될 때마다 애플리케이션에 넘기므로 파일 전체를 버퍼링할 필요가 없다. 값 하나의 최대 바이트 수를 제한할 수 있어 비정상적으로 큰 레코드가 메모리를 잠식하는 위험도 줄일 수 있다.

개발자에게 왜 중요한가

Kotlin과 Scala 서비스는 Jackson이나 kotlinx.serialization 같은 성숙한 선택지가 이미 있다. Fory 1.7.0의 가치는 무조건 교체하는 데 있지 않고, Fory의 객체 직렬화·다중 언어 경계를 이미 사용하는 팀이 JSON 입출력까지 같은 타입 모델과 코드 생성 체계에서 다룰 수 있다는 데 있다. GraalVM Native Image에서는 빌드 시점 코드 생성과 더 세분화된 코덱 캐시가 기본값으로 들어가 시작 시간과 반영 설정을 함께 관리하기 쉬워졌다.

스트리밍 디코더는 이벤트 내보내기, 로그 수집, 대용량 API 응답처럼 레코드가 순차적으로 도착하는 경로에 실질적이다. 다만 디코더는 한 스트림에만 속하고 스레드 안전하지 않으며 완료나 실패 뒤 재사용할 수 없다. 각 입력 청크를 모두 소진한 뒤 다음 청크를 공급해야 한다.

기존 프로젝트 영향

1.7.0은 새 기능을 추가한 마이너 릴리스다. 기존 애플리케이션이 자동으로 새 JSON 모듈로 전환되지는 않는다. Kotlin의 누락 필드는 생성자 기본값을 쓰지만 명시적인 JSON null은 기본값 요청으로 취급하지 않고 선언된 null 가능성을 검사한다. 이 차이는 기존 역직렬화 동작과 결과가 달라질 수 있어 계약 테스트가 필요하다.

Native Image와 Android는 런타임 리플렉션·코드 생성 조건이 일반 JVM과 다르다. 모델과 정확한 제네릭 바인딩을 빌드 시점에 도달 가능하게 만들고, 축소 도구가 생성 코드를 제거하지 않는지 확인해야 한다. Swift 지원은 visionOS·watchOS·tvOS·Linux로 넓어졌고 Swift gRPC 코드 생성이 추가됐지만, 각 플랫폼의 실제 배포 도구 사슬은 별도로 시험해야 한다.

적용 전 확인 사항

  • 실제 데이터에서 기본값과 명시적 null, 알려지지 않은 필드의 처리 결과를 회귀 테스트한다.
  • 스트림의 maxValueBytes를 업무상 가능한 최대 레코드보다 조금 크게 설정하고 전체 스트림 크기 제한은 별도로 둔다.
  • Android API 26 이상 조건, KSP 생성물과 R8·ProGuard 규칙을 릴리스 빌드에서 확인한다.
  • GraalVM Native Image는 개발 JVM 테스트만으로 판단하지 말고 네이티브 바이너리를 실제 생성해 모델 도달성과 초기화 시점을 검증한다.
  • 직렬화 라이브러리 변경은 신뢰하지 않는 입력을 다루는 경계이므로 입력 크기 제한과 예외 처리, 의존성 업데이트 정책을 함께 점검한다.

출처