▲

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

 (github.com/Snapchat)
5P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 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⁺ 2일전  [-]
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 13시간전  [-]

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

답변달기