AI로 하루 만에 JSONata를 Go로 재작성해서 연간 $500K 절약한 이야기

Who Should Read

데이터 파이프라인에서 언어 간 RPC 호출로 비용이 낭비되고 있는 백엔드 개발자, 또는 AI 코드 생성 도구로 레거시 컴포넌트를 교체하는 작업을 고려 중인 엔지니어.

Core Mechanics

• Reco는 보안 정책 엔진에서 JSONata 표현식을 수십억 개의 이벤트에 대해 평가하는데, JSONata의 레퍼런스 구현이 JavaScript라서 Go 서비스에서 직접 쓸 수가 없었다. 결국 Kubernetes에 Node.js jsonata-js 파드를 별도로 띄우고 Go 서비스가 RPC로 호출하는 구조를 수년간 유지했다.
• 이 아키텍처는 매 이벤트마다 직렬화 → 네트워크 전송 → 평가 → 결과 직렬화 → 반환이라는 왕복 과정이 필요해서, 컴퓨팅 비용만 연간 약 $300K가 들었고 고객과 탐지 규칙이 늘수록 비용도 계속 증가하는 구조였다.
• 해결책으로 JSONata를 Go로 직접 포팅하기로 했다. 접근 방식은 Cloudflare의 빠른 재작성 방식과 동일하게, 공식 jsonata-js 테스트 스위트를 Go로 옮긴 뒤 모든 테스트가 통과할 때까지 evaluator를 구현하는 방식이었다.
• AI 도구(Claude)를 활용해 하루 만에 재작성을 완료했고, 사용한 Claude 토큰 비용은 약 $400 수준이었다. Go 인라인 실행으로 전환하자 RPC 오버헤드가 사라지면서 월 $25K였던 jsonata-js 파드 비용이 0이 됐다.
• 총 절감액은 연간 $500K로 발표됐는데, 여기에는 컴퓨팅 비용($300K)뿐 아니라 두 언어 스택을 동시에 운영하면서 발생하는 배포 복잡도, 운영 오버헤드 등도 포함된 것으로 보인다.
• JSONata의 레퍼런스 JavaScript 구현은 약 5,500줄이고, AI가 생성한 Go 구현은 약 13,000줄이다. JavaScript의 동적 특성과 JSONata 문법의 JS 기반 뉘앙스를 Go로 표현하면서 코드량이 늘어난 것으로 보인다.
• 재작성된 Go 구현은 공식 JSONata 테스트 스위트를 통과하는 것을 검증 기준으로 삼았고, 프로덕션에 배포 후 실제 비용이 급감하면서 내부적으로 ROI를 바로 증명할 수 있었다고 한다.

Evidence

• 핵심 비판은 'AI 재작성'이 아니라 '왜 이걸 이렇게 오래 방치했냐'는 것이었다. $400짜리 Claude 토큰으로 재작성이 됐다는 건 코드베이스 자체가 그리 크지 않았다는 뜻이고, 그러면 엔지니어가 직접 이식해도 충분히 가능한 규모였다는 지적이 많았다. 연간 $300K, 즉 FTE(직원 한 명 풀타임 비용) 수준을 수년간 낭비한 것에 대한 황당함을 표현하는 댓글이 많았다.
• 이미 Go로 된 JSONata 구현이 두 개나 존재했음에도 새로 만든 이유를 설명하지 않았다는 비판이 있었다. JSONata 공식 문서에도 Go 구현들이 링크돼 있고, 그 중 하나인 `github.com/jsonata-go/jsonata`는 실제로 Claude Code와 Codex를 써서 2025년 초에 만들어진 것으로, 공식 테스트 스위트를 통과하며 프로덕션에서도 잘 돌아가고 있다는 해당 프로젝트 기여자의 댓글이 달렸다. Reco가 기존 라이브러리를 검토하고 왜 부적합했는지 설명하지 않은 점이 엔지니어링 블로그로서 아쉽다는 평가가 많았다.
• 벤치마크 방식도 도마에 올랐다. 성능 측정을 앱 레벨에서 했는데, 이건 RPC 오버헤드 제거 효과를 측정한 것이지 Go로 구현한 JSONata 자체의 성능을 측정한 게 아니라는 지적이었다. JS 구현과 Go 구현을 격리된 환경에서 동일 조건으로 비교했어야 실제 성능 차이를 알 수 있는데, 그 데이터가 없어서 'AI 구현이 느릴 수도 있다'는 우려가 나왔다.
• AI 생성 코드의 장기 유지보수에 대한 우려도 제기됐다. JSONata 오픈소스 프로젝트에는 현재 15개의 PR과 150개의 오픈 이슈가 있는데, 이제 자체 포크를 13,000줄의 Go 코드로 유지해야 한다. 업스트림 변경사항을 어떻게 따라갈 것인지, 이 유지보수 비용이 절감액 계산에 포함됐는지 불분명하다는 댓글이 있었다.
• '이런 식의 포스트가 앞으로 더 많아질 것'이라는 냉소적인 예측도 나왔다. 나쁜 아키텍처를 고쳐서 이득을 봤는데 AI가 한 것처럼 포장한다는 패턴, 그리고 AI로 빠르게 만든 코드를 제대로 이해하지 않고 운영하다가 새로운 버그가 쌓이는 악순환이 반복될 것이라는 예측이었다. 한 댓글러는 '코드는 100배 더 많이 나오고 토큰 비용은 개발자 월급의 2배가 되는데 실제 임팩트는 별로 없는 미래'를 경고했다.

How to Apply

• Go 서비스에서 Node.js/Python 등 다른 언어 런타임을 RPC나 사이드카로 호출하는 구조가 있다면, 해당 컴포넌트의 월간 컴퓨팅 비용을 먼저 계산해봐라. 비용이 연간 수만 달러 이상이라면 Claude Code나 Cursor 같은 AI 코딩 도구로 인라인 포팅을 검토할 가치가 있다. 단, 포팅 전에 공식 테스트 스위트를 먼저 확보해서 동작 동등성 검증 기준을 마련하는 게 핵심이다.
• JSONata를 Go 파이프라인에서 써야 한다면, Reco처럼 직접 재작성하기 전에 `github.com/jsonata-go/jsonata` (2025년 초 AI로 포팅, 공식 테스트 스위트 통과, 프로덕션 검증 완료)를 먼저 평가해봐라. 기존 라이브러리로 요구사항이 충족된다면 유지보수 부담 없이 쓸 수 있다.
• AI로 레거시 컴포넌트를 재작성할 때는 '공식 테스트 스위트를 타겟 언어로 이식 → AI가 테스트 통과할 때까지 구현 → 프로덕션 배포 전 격리된 벤치마크로 성능 검증'의 순서를 지켜라. 이 블로그 사례에서 벤치마크가 비판받은 이유가 격리 검증 없이 시스템 레벨 지표만 봤기 때문이다.
• AI 생성 코드로 오픈소스 라이브러리를 포크할 때는 유지보수 전략을 미리 정해야 한다. 업스트림 업데이트를 주기적으로 반영할 담당자를 지정하거나, 아니면 포크 시점의 버전으로 기능을 동결하고 보안 패치만 수동 적용하는 정책을 명시적으로 결정해둬야 나중에 기술부채가 된다.

Terminology

Related Resources

• https://www.reco.ai/blog/we-rewrote-jsonata-with-ai
• https://github.com/jsonata-go/jsonata
• https://github.com/blues/jsonata-go
• https://docs.jsonata.org/overview.html