# Valdi – 네이티브 성능을 제공하는 크로스플랫폼 UI 프레임워크 > Clean Markdown view of GeekNews topic #24237. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24237](https://news.hada.io/topic?id=24237) - GeekNews Markdown: [https://news.hada.io/topic/24237.md](https://news.hada.io/topic/24237.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-09T09:38:54+09:00 - Updated: 2025-11-09T09:38:54+09:00 - Original source: [github.com/Snapchat](https://github.com/Snapchat/Valdi) - Points: 9 - Comments: 2 ## Summary Snap이 공개한 **Valdi**는 **TypeScript로 작성한 UI를 네이티브 뷰로 직접 컴파일**해 iOS·Android·macOS에서 **웹뷰 없이 네이티브 성능**을 구현하는 새로운 **크로스플랫폼 UI 프레임워크**입니다. **C++ 기반 레이아웃 엔진**, **자동 뷰 재활용**, **뷰포트 렌더링** 등으로 성능을 극대화하면서도, **핫 리로드**와 **VSCode 디버깅**으로 개발 경험을 세심하게 다듬었습니다. 특히 **C++·Swift·Kotlin과 타입 안전하게 연동되는 구조**는 기존 네이티브 앱과의 통합을 염두에 둔 설계로 돋보입니다. 8년간 스냅챗 프로덕션에서 검증된 기술이 이제 오픈소스로 풀렸다는 점에서, “진짜 네이티브 성능의 크로스플랫폼 UI”를 고민해온 개발자라면 주목할 만합니다. ## Topic Body - 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 라이선스**로 공개되어 자유로운 사용 및 기여 가능 ## Comments ### Comment 46091 - Author: neo - Created: 2025-11-09T09:38:54+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45852854) - 우리 회사는 **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 엔진**을 사용한다는 점도 흥미로움 [관련 문서](https://github.com/Snapchat/Valdi/blob/main/docs/docs/workflow-hermes-debugger.md)를 보면 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의 클래스 컴포넌트 스타일을 그대로 사용함 [공식 문서 예시](https://github.com/Snapchat/Valdi/blob/main/docs/docs/core-states.md#state)를 보면 `StatefulComponent`를 상속받아 `onCreate`, `onDestroy`, `onRender`를 구현하는 구조임 - 나도 **React 클래스 컴포넌트**가 그리움 지금처럼 수십 개의 `useFunction`을 쓰는 방식은 오류가 많고 복잡함 - 아쉽게도 **Linux, Windows, HTML 타깃**은 지원하지 않음 ### Comment 46131 - Author: clastneo - Created: 2025-11-10T13:13:30+09:00 - Points: 1 - Parent comment: 46091 - Depth: 1 RN에서 대부분의 앱 비즈니스 로직은 JS만으로도 충분히 빠르게 돌릴 수 있습니다. 폴리싱 하다보면 "플랫폼별 동작이 다른 경우가 많아서" 답안나오게 어려워지는게 문제라고 보네요.