Valdi – 네이티브 성능을 제공하는 크로스플랫폼 UI 프레임워크

• Snap(스냅챗)이 만든 Valdi는 iOS, Android, macOS에서 네이티브 성능을 제공하는 크로스플랫폼 UI 프레임워크로, 선언형 TypeScript로 작성된 UI를 각 플랫폼의 네이티브 뷰로 직접 컴파일함
• 웹뷰나 JavaScript 브리지 없이 동작하며, 자동 뷰 재활용, 최적화된 레이아웃 엔진, 뷰포트 기반 렌더링 등으로 높은 성능을 유지함
• 즉시 핫 리로드, VSCode 디버깅, TSX 문법 지원 등으로 개발 속도를 높이고, 기존 네이티브 앱과의 통합도 유연하게 지원함
• TypeScript와 네이티브 코드 간 타입 안전 바인딩, protobuf 지원, C++·Swift·Kotlin 연동 등으로 깊은 네이티브 통합 구조를 제공함
• 8년간 Snap의 프로덕션 앱에서 검증된 기술로, 대규모 애니메이션·제스처·멀티스레드 처리 등 고급 기능을 포함한 확장 가능한 UI 개발 기반임

---

Valdi 개요

• Valdi는 Snap이 8년간 프로덕션 앱에서 사용해 온 크로스플랫폼 UI 프레임워크
  • 선언형 TypeScript로 UI를 작성하면 iOS, Android, macOS의 네이티브 뷰로 직접 컴파일
  • 웹뷰나 JavaScript 브리지 없이 네이티브 성능을 제공
• 현재 베타 단계이며, 오픈소스 환경에서의 도구와 문서 안정화가 완료되면 정식 버전으로 전환 예정

주요 특징 및 예시

• 기본 컴포넌트 예시는 HelloWorld 클래스에서 와 을 사용해 간단한 UI를 구성
• TypeScript 기반의 선언형 컴포넌트 구조를 사용하며, 각 플랫폼에서 동일한 코드로 실행 가능
• 공식 문서, 설치 가이드, API 레퍼런스, Codelab 등 개발 자료 제공

성능 최적화

• 네이티브 성능 확보를 위해 다음과 같은 구조를 채택
  • 자동 뷰 재활용: 전역 뷰 풀링 시스템으로 화면 간 뷰 재사용, 인플레이션 지연 최소화
  • 독립적 컴포넌트 렌더링: 부모 렌더링에 영향 없이 개별 컴포넌트만 갱신
  • C++ 기반 레이아웃 엔진: 메인 스레드에서 최소 오버헤드로 동작
  • 뷰포트 인식 렌더링: 화면에 보이는 뷰만 인플레이트하여 무한 스크롤 성능 향상
• 관련 문서로 Performance Optimization Guide 제공

개발자 경험

• 핫 리로드 기능으로 코드 변경 후 즉시 반영
• VSCode 디버깅 지원: 브레이크포인트 설정, 변수 검사, 성능 프로파일링, 힙 덤프 캡처 가능
• TSX 문법과 타입 안정성으로 친숙한 개발 환경 제공

유연한 통합 구조

• 기존 네이티브 앱에 Valdi 삽입 가능 (Embed Valdi in native)
• Valdi 내에서 네이티브 뷰 사용 가능 (Embed native in Valdi)
• Polyglot 모듈을 통해 C++, Swift, Kotlin, Objective-C 코드와 타입 안전하게 연동
• Full-stack 아키텍처로 백그라운드 워커 스레드를 활용한 전체 기능 구현 가능

네이티브 통합

• 자동 코드 생성으로 TypeScript 인터페이스를 Kotlin, Objective-C, Swift 바인딩으로 변환
• Polyglot 모듈을 통해 플랫폼 API 및 서드파티 네이티브 라이브러리에 직접 접근
• 양방향 통신으로 복잡한 데이터 구조와 콜백을 안전하게 교환
• protobuf 지원으로 효율적인 데이터 직렬화 가능

검증된 안정성 및 기능

• Snap의 주요 프로덕션 기능을 구동하는 핵심 기술
• 고급 애니메이션, 실시간 렌더링, 복잡한 제스처 시스템 지원
• Flexbox 레이아웃, 멀티스레드 워커, 네이티브 애니메이션, 고급 제스처 인식, 내장 테스트 프레임워크, Bazel 통합 빌드 등 다양한 기능 포함

지원 및 라이선스

• Discord 커뮤니티를 통한 지원 제공
• MIT 라이선스로 공개되어 자유로운 사용 및 기여 가능

[GN⁺]

Hacker News 의견

• 우리 회사는 React Native를 쓰고 있는데, 앱 스토어와 플랫폼별 언어 차이의 종말을 간절히 바람
  내년엔 그냥 웹사이트 기반으로, 모바일 앱은 WebView로 감싸고, 알림·GPS·HealthKit 같은 기능만 네이티브 코드로 처리하는 걸 고려 중임
  요즘은 AI 덕분에 각 플랫폼별로 UI를 따로 만드는 게 오히려 나을지도 모른다는 생각이 듦

  • 나도 그렇게 했고, 후회하지 않았음. 이건 흔히 말하는 “WebView 앱”인데, 플랫폼별로 꽤 괜찮은 경험을 줄 수 있음
    핵심은 UI 컴포넌트를 너무 독특하게 만들지 말고, 버튼 스타일이나 백스택 같은 부분만 플랫폼별로 약간 다르게 조정하는 것임
    또 Service Worker로 오프라인 기능을 추가하고, 네트워크 진단 도구를 앱 시작 시 실행해 문제를 빠르게 파악할 수 있게 했음
    다만 내 앱은 B2B용이라 이런 구성이 가능했음
  • 그래도 여전히 WebView를 네이티브 컨테이너로 감싸야 한다면, 그 시점에서 이미 iOS 코드 서명 지옥에 발을 들인 셈임
    웹은 원래 앱스토어와 코드서명을 우회하기 위한 길이라고 생각함
    대부분의 기능은 웹으로도 가능하고, HealthKit만 별도 동반 앱으로 처리하면 됨
    마케팅 예산으로 QR 코드나 링크를 홍보하는 게 앱스토어 경쟁보다 훨씬 효율적일 수도 있음
  • 나도 10년마다 이런 시도를 함. 처음엔 빠른 개발 속도에 반하지만, 나중엔 새 OS 기능 통합이나 제스처 대응에서 결국 대가를 치르게 됨
    특히 iOS에서 ‘뒤로 가기 스와이프’가 안 되는 순간, 그게 WebView라는 걸 바로 알게 됨
  • AI가 Apple의 가이드라인을 바꾸진 않음
    나는 비즈니스 UI를 한 번 작성하고 LLM으로 React Native와 React 간 변환을 함
    하지만 Apple은 여전히 “단순히 웹사이트를 포장한 앱은 거절”한다는 4.2 최소 기능성 규정을 유지하고 있음
  • 복잡하고 장기적인 앱을 플랫폼별로 세 번 작성하는 건 악몽에 가까움
    기능과 테스트를 세 플랫폼에서 동기화해야 하고, 개발자도 여러 스택에 능숙해야 함
    대부분의 사용자는 좋은 WebView 구현과 네이티브 앱의 차이를 거의 못 느끼는데, 그 대가가 너무 큼

• Valdi가 개념적으로 React Native와 비슷해 보임
  이제 React 기반의 크로스플랫폼 프레임워크가 React Native, Lynx.js(ByteDance/TikTok), Valdi 세 가지나 됨
  경쟁은 좋지만, RN만큼 큰 생태계를 빠르게 만들 수 있을지는 의문임
  RN은 올해 Hermes 엔진 개선, 네이티브 바인딩 생성기, 멀티스레드 애니메이션, Tailwind 지원 등 많은 발전이 있었음
  Lynx.js는 React 외 프레임워크도 지원하려는 점에서 더 유리할 수도 있음

  • 조금 찾아보니 Valdi는 VSCode 디버깅을 완전히 지원함
    RN의 Radon IDE는 유료인데, Valdi는 오픈소스임
    Valdi가 RN의 Hermes 엔진을 사용한다는 점도 흥미로움
    관련 문서를 보면 AOT/JIT 구현 방식이 궁금해짐

• 예전에 Snap에서 이 프로젝트의 초기 버전(Screenshop! )을 함께 디버깅했었음
  Simon은 훌륭한 엔지니어였고, 이 프로젝트가 공개된 게 정말 반가움
  Snap 팀에게 축하를 보냄

  • Snap처럼 단순한 앱이 크로스플랫폼 UI 프레임워크에 투자했다는 게 의외였음
    카메라, AR, 알림, 스크린샷 감지 등 네이티브 통합이 중요한 앱이니까 더 놀라움
  • 그때도 정말 멋진 프로젝트였고, 오픈소스화가 목표였던 걸 기억함
    이렇게 현실이 된 게 기쁨임
  • 나도 Simon과 함께 일하며 웹 포팅을 시도했지만 실패했음
    정말 똑똑한 사람이고, 팀 전체에 축하를 보냄
  • 지금이라면 이 프레임워크를 실제 프로젝트에 쓸지 궁금함
  • “Composer”라는 이름이 떠오름

• Snapchat이 만든 UI 프레임워크에 Discord 커뮤니티라니, 개인적으로 전혀 끌리지 않음

  • 요즘 많은 프로젝트가 Discord로 커뮤니티를 옮기고 있음
    완벽하진 않지만, 미래의 흐름에서 스스로 빠지는 셈일 수도 있음
  • 나도 Discord를 자주 쓰지만, 업무용 커뮤니티로는 여전히 불편하다고 느낌

• 문서에 “C++, Objective-C, Kotlin 객체를 TypeScript로 노출하면 Native Reference, 반대는 JS Value Reference”라고 되어 있는데
  Swift나 SwiftUI 언급이 없는 점이 조금 우려스러움

• 솔직히 Snap이 만든 프레임워크를 신뢰하기 어려움
  예전 Android 앱 품질이 너무 안 좋았기 때문임

  • 예전엔 사진을 찍는 게 아니라, 카메라 뷰의 스크린샷을 찍는 방식이었다는 걸 알고 충격이었음

• Valdi는 “TypeScript로 한 번 작성하면 iOS, Android, macOS에서 네이티브 성능으로 동작하는 UI 프레임워크”라고 소개됨
  웹뷰나 JS 브리지가 없다는 점을 강조함

  • “우린 두 가지 다 있어요. Country and western!”이라며 농담을 던짐

• 그냥 각 플랫폼의 네이티브 언어로 UI를 두 번 작성하고, 공통 로직은 C 계열 FFI로 공유하면 된다고 생각함
  얼마나 어렵겠음?

  • 우리도 그 방향으로 가고 있음. 현재는 iOS만 지원하지만, 사용자 피드백을 얻은 뒤 Android로 확장할 계획임
    팀 대부분은 Android 유저지만, 고객은 iOS 중심이라 우선순위를 그렇게 둠
    RN 앱을 만들어본 경험이 있지만, 여전히 진짜 마법 같은 크로스플랫폼 솔루션을 기대하고 있음
  • 나도 동의함. 핵심은 비즈니스 로직을 UI와 분리하는 아키텍처 설계임
    그러면 웹, 모바일, 데스크톱, CLI 등 다양한 인터페이스가 단순히 코어를 호출하는 얇은 레이어가 됨
    완벽히 일관된 UX는 어렵겠지만, 장기적으로 3rd-party 프레임워크 의존성을 줄일 수 있음

• Valdi의 상태 관리 방식이 궁금하다면, React의 클래스 컴포넌트 스타일을 그대로 사용함
  공식 문서 예시를 보면 StatefulComponent를 상속받아 onCreate, onDestroy, onRender를 구현하는 구조임

  • 나도 React 클래스 컴포넌트가 그리움
    지금처럼 수십 개의 useFunction을 쓰는 방식은 오류가 많고 복잡함

• 아쉽게도 Linux, Windows, HTML 타깃은 지원하지 않음

[clastneo]

RN에서 대부분의 앱 비즈니스 로직은 JS만으로도 충분히 빠르게 돌릴 수 있습니다.
폴리싱 하다보면 "플랫폼별 동작이 다른 경우가 많아서" 답안나오게 어려워지는게 문제라고 보네요.