AI 시대, iOS/Android 크로스플랫폼 프레임워크의 어색한 미래

크로스플랫폼의 환상: 엔지니어링, 관료주의, 그리고 AI 시대

나는 중국 본토에서 손꼽히는 대형 인터넷 기업 몇 곳에서 십 년 넘게 일했다. 이후 해외로 이주해 중국 본토를 제외한 전 세계에서 사업을 운영하는 글로벌 기술 기업에 합류했다. 그 뒤에는 해외에서 내 회사를 창업했다.

이런 경험은 중국에서 목격했던 엔지니어링 문화와 기술적 의사결정을 다른 관점에서 바라보게 해 주었다.

크로스플랫폼 프레임워크에 대한 의문은 2024년에 시작됐다.

당시 나는 여가 시간에 ASR/TTS 모바일 앱을 만들고 있었다. 클라우드 컴퓨팅에 의존하는 대신 기기 자체의 연산 능력을 활용하고 싶었다. iOS와 Android 모두 이미 점점 더 강력한 머신러닝 API를 지원하고 있었기 때문이다.

AI 보조 개발을 위해 Cursor도 사용하기 시작했다.

내 앱에 쓸 크로스플랫폼 솔루션을 조사하다가 한 가지 결론에 도달했다. AI 시대에는 iOS/Android 크로스플랫폼 프레임워크의 중요성이 점점 줄어들 것이라는 결론이었다.

어쩌면 AI 이전부터 그 가치는 과장되어 있었는지도 모른다.

최근 Shopify의 엔지니어링 글 이제 Shopify 모바일의 미래는 네이티브다를 읽었다. React Native에서 다시 네이티브 개발로 돌아가기로 한 결정을 설명하는 글이었다.

그 글은 2024년에 크로스플랫폼 프레임워크에 대해 품었던 의문을 떠올리게 했고, 마침내 내 생각을 글로 정리하게 만들었다.

Shopify는 2020년 당시 React Native가 올바른 선택이었다고 주장한다. 나는 그렇게 확신하지 못한다.

Shopify 스스로도 성능 최적화, 프레임워크 개선, 의존성 유지보수에 상당한 시간과 자원을 들였다고 인정한다. 하지만 이것들은 크로스플랫폼 개발 비용의 일부일 뿐이다. 개발자 생태계를 유지하는 데 드는 숨은 비용, 조직적 오버헤드, 그리고 놓친 사업 기회는 어떨까?

Shopify는 그 결정의 실제 경제적 비용을 온전히 계산해 본 적이 있을까? 나는 심히 의심스럽다.

내 결론에는 몇 가지 이유가 있다.

• AI 코딩 에이전트가 네이티브 애플리케이션의 개발과 유지보수 비용을 크게 낮추고 있다.
• 온디바이스 AI는 네이티브 개발을 더 매력적으로 만드는 반면, 크로스플랫폼 프레임워크는 새로운 플랫폼 기능을 뒤늦게 따라가는 경우가 많다.
• 숨겨진 비용, 즉 프레임워크 유지보수, 내부 개발자 생태계, 팀 간 조율, 조직 정치 등의 비용은 자주 과소평가된다.
• 신냉전과 AI 군비 경쟁: 우리는 지금 새로운 냉전 속에 있고, AI는 그중 가장 중요한 전략적 경쟁 무대 중 하나가 되었다. 지난 냉전의 전략방위구상, 이른바 스타워즈 계획과 비슷하다. 경쟁이 치열해질수록 개발 비용에 비해 시장 출시 속도와 사용자 경험의 중요성이 커진다.

하지만 AI를 논하기 전에, 중국 인터넷 산업에서 관찰한 이야기를 먼저 나누고 싶다.

한 번 작성하면 어디서나 실행된다?

내가 일했던 중국의 여러 대형 인터넷 기업에서 크로스플랫폼 프레임워크는 개발 비용을 줄이는 방법으로 자주 홍보되었다.

그러나 그 야심은 iOS와 Android 사이에서 코드를 공유하는 것을 훨씬 넘어섰다.

기업들은 코드를 한 번 작성해서 모든 곳에서 실행하고 싶어 했다. iOS, Android, H5, WeChat 미니 프로그램, Alipay 미니 프로그램, 때로는 그보다 더 많은 플랫폼까지.

논리는 단순하게 들렸다. 한 번 작성하면 어디서나 실행된다.

하지만 현실은 훨씬 더 복잡했다.

• 한 번만 작성한다고? 꼭 그렇지는 않다. 개발자가 결국 코드를 세 번 작성하는 경우도 있었다. iOS용으로 한 번, Android용으로 한 번, 크로스플랫폼 프레임워크용으로 한 번. 웹이나 미니 프로그램 플랫폼까지 지원하면 일이 더 늘어날 수도 있었다.
• 성능과 사용자 경험. 네이티브에 가까운 성능을 내기 위해 상당한 엔지니어링 노력이 필요한 경우가 많았고, 일부 한계는 완전히 없앨 수 없었다.
• 플랫폼 API 지원 지연. iOS와 Android의 새로운 기능을 크로스플랫폼 프레임워크에서 곧바로 사용할 수 있는 것은 아니었다.
• 조율 비용. 크로스플랫폼 개발은 비즈니스 팀, 프레임워크 팀, 네이티브 플랫폼 팀 사이에 추가적인 의존 관계를 만들었다.
• 조직 정치. 일부 엔지니어링 프로젝트는 실제 사업 가치보다 기술적 성과, 팀 확장, 승진에 더 집중하는 것처럼 보였다.
• 불필요한 반복 개발. 사업상 정말 그렇게 자주 앱을 바꿔야 했을까? 아니면 어떤 프로젝트는 그저 일을 만들기 위한 일이었을까?

복잡성의 계층이 하나 늘어날 때마다 비용이 따른다.

프레임워크가 개발 시간을 줄여 준다 해도, 그 과정에서 희생된 성능과 사용자 경험, 사업 기회는 어떻게 측정해야 할까?

숨겨진 비용: 내부 개발자 생태계

크로스플랫폼 프레임워크를 구축할 때 가장 과소평가되는 비용 중 하나는 개발자 생태계를 유지하는 비용이다.

Apple과 Google이 개발자 생태계에 막대한 투자를 하는 이유는 그 생태계가 자사의 플랫폼과 사업을 직접 강화하기 때문이다.

하지만 인터넷 기업이 자체 크로스플랫폼 프레임워크를 만들면, 사실상 회사 안에 또 하나의 개발자 플랫폼을 만드는 셈이다.

네이티브 API 브리지, UI 컴포넌트, 빌드 도구, 디버깅 도구, 테스트 인프라, 문서, SDK 통합, 하위 호환성을 유지해야 한다.

이 내부 생태계는 iOS, Android, 때로는 웹과 미니 프로그램, HarmonyOS의 변화까지 계속 따라가야 한다.

회사는 더 이상 단순히 애플리케이션을 만드는 것이 아니다. 플랫폼 안의 플랫폼을 유지하고 있는 것이다.

React Native 같은 성숙한 프레임워크를 사용하면 이 부담을 줄일 수 있다. Meta와 오픈소스 커뮤니티가 생태계의 상당 부분을 관리하기 때문이다. 하지만 대기업은 결국 그 주변에 방대한 내부 인프라를 구축하는 경우가 많다.

그렇다면 이 생태계 자체의 개발 및 유지보수 비용까지 계산했을 때, 실제로 얼마나 많은 돈을 아끼고 있을까?

그리고 이것을 만드는 이유는 사업에 필요해서일까, 아니면 엔지니어링 조직에 만들 거리가 필요해서일까?

핫 업데이트와 만들어진 수요

중국 인터넷 산업에서 크로스플랫폼 및 동적 프레임워크가 그토록 인기를 얻은 데에는 또 다른 이유가 있다. 바로 핫 업데이트다.

많은 기업은 매번 전통적인 앱 스토어 심사와 배포 절차를 거치지 않고 앱을 업데이트하고 싶어 했다.

끝없는 마케팅 캠페인과 판촉 행사, 잦은 제품 실험을 진행하는 기업에는 특히 매력적이었다.

하지만 돌이켜보면 의문이 든다.

사용자에게 정말 그렇게 많은 변화가 필요했을까?

그 캠페인과 끊임없는 반복 개발이 비용을 정당화할 만큼 충분한 사업 가치를 실제로 만들어 냈을까?

아니면 그중 일부는 더 많은 프로젝트, 더 많은 활동, 더 많은 성과가 필요한 거대한 조직이 그저 만들어 낸 것이었을까?

불필요한 개발을 더 빠르게 해 주는 프레임워크가 반드시 회사를 더 효율적으로 만드는 것은 아니다.

그저 불필요한 일을 더 잘 만들어 내는 회사로 바꿀 뿐일 수도 있다.

엔지니어링 인프라가 아무리 정교해져도, 회사는 더 많은 기능을 출시하는 것으로 근본적인 사업 문제를 해결할 수 없다.

엔지니어링 효율이 반드시 사업 효율로 이어지는 것은 아니다.

시험 중심의 엔지니어링과 만들어진 복잡성

중국 인터넷 산업에서 관찰한 또 다른 문제가 있다. 시험 중심의 엔지니어링 문화다.

중국의 시험 위주 교육 체계는 어려운 문제를 푸는 훈련을 시키지만, 그 문제가 애초에 존재해야 하는지 의문을 품도록 권하는 경우는 드물다.

이런 사고방식은 엔지니어링 조직으로 이어질 수 있다.

어떤 엔지니어들은 복잡한 기술 문제를 해결하는 데 탁월하지만, 그 문제를 해결할 필요가 있는지는 거의 묻지 않는다.

때로는 문제가 없는 곳에 문제를 만들기도 한다.

소프트웨어 엔지니어링에는 완벽한 아키텍처도, 완벽한 프레임워크도, 보편적으로 옳은 해결책도 없다. 충분한 논거와 벤치마크, 신중하게 고른 절충안을 동원하면 거의 모든 기술적 결정을 정당화할 수 있다.

이는 조직 정치가 끼어들 충분한 공간을 만든다.

제안이 기술적으로 그럴듯하게 들리고 적절한 사람들을 만족시키기만 하면, 엔지니어링 팀은 거의 무엇이든 정당화할 수 있다.

새 프레임워크를 만든다. 기존 시스템을 다시 작성한다. 추상화 계층을 하나 더 도입한다. 새로운 기술 표준을 만든다.

그런 다음 프로젝트의 복잡성, 참여한 엔지니어 수, 이른바 기술적 성과를 활용해 승진을 얻는다.

목표는 더 이상 문제를 해결하는 것이 아니다. 승진할 만한 문제를 만들어 내는 것이다.

완벽한 아키텍처는 없으므로 해결할 다른 문제, 만들 다른 프레임워크, 조직을 계속 바쁘게 할 다른 이유가 언제나 있다.

정작 이 모든 것이 비용을 정당화할 만큼 충분한 가치를 만드는가라는 진짜 질문은 종종 편리하게 무시된다.

엔지니어링 복잡성이 승진의 경로가 되면, 단순함은 위협이 된다.

추상화가 더 많은 추상화를 만들 때

거의 황당하다고 할 만한 일이 있다.

어느 중국 인터넷 기업에는 여러 크로스플랫폼 프레임워크가 동시에 존재했다.

결국 그 기존 프레임워크들이 서로 호환되도록 만들기 위해 또 다른 프레임워크가 개발되었다.

한번 생각해 보자.

복잡성을 줄이려고 추상화를 만들고, 그 추상화가 만들어 낸 복잡성을 관리하려고 또 다른 추상화를 만든 것이다.

우스꽝스럽다.

이 일은 AI 코딩 에이전트가 소프트웨어 개발의 경제성을 바꾸기 시작하기 전에 일어났다.

크로스플랫폼 개발의 경제성

이 모든 것은 간단한 공식으로 살펴볼 수 있다.

변수를 정의해 보자.

• $V_{cross}$

  — 크로스플랫폼 프레임워크 도입의 순경제적 가치.

• $C_{saved}$

  — 플랫폼 간 코드 재사용으로 실제 절약한 개발 및 유지보수 비용.

• $C_{complexity}$

  — 추상화, 호환성 문제, 디버깅, 성능 최적화로 발생하는 추가 비용.

• $C_{ecosystem}$

  — 개발 도구, SDK, 테스트 인프라, 플랫폼 API 호환성 유지 비용.

• $C_{organization}$

  — 조율, 관료주의, 조직 정치, 승진 목적의 프로젝트로 발생하는 추가 비용.

• $C_{opportunity}$

  — 출시 지연, 플랫폼 API 지원 지연, 열등한 사용자 경험, 플랫폼 차별화 상실로 인한 기회비용.

공식은 다음과 같다.

크로스플랫폼 프레임워크는 실제로 절약하는 비용이 추가로 발생시키는 비용보다 클 때만 양의 경제적 가치를 만든다.

이는 AI 이전부터 이미 물어볼 가치가 있는 질문이었다.

AI 시대 크로스플랫폼 개발의 경제성

이제 AI가 이 식을 어떻게 바꾸는지 살펴보자.

첫째, AI 코딩 에이전트는 네이티브 개발 비용을 크게 낮추고 있다.

그 결과 크로스플랫폼 프레임워크가 애초에 절감하려던 개발 비용 자체가 줄어들고 있다.

둘째, 신냉전과 AI 군비 경쟁은 네이티브 플랫폼 기능의 가치를 점점 더 높이고 있다.

온디바이스 AI, 즉 엣지 AI는 필연적으로 iOS, Android, 그리고 다른 컴퓨팅 플랫폼의 핵심 구성 요소가 될 것이다.

네이티브 개발은 새로운 API에 더 빨리 접근하고, 더 나은 성능과 더 쉬운 통합을 제공하며, 플랫폼 고유의 하드웨어와 소프트웨어를 더 직접적으로 활용하게 해 준다.

하지만 물어볼 만한 질문이 하나 더 있다.

애초에 iOS와 Android 애플리케이션은 왜 똑같아야 할까?

Windows와 Linux 애플리케이션은 반드시 같은 모습이나 동작을 갖지 않는다. 모바일 애플리케이션은 왜 그래야 할까?

플랫폼마다 하드웨어, 운영체제, AI 기능, 사용자 기대가 다르다.

앞으로 몇 년 동안 Apple과 Google은 각자의 온디바이스 AI 기능, 모델, 하드웨어 가속, 개인정보 보호 메커니즘, 시스템 수준 통합을 계속 발전시킬 것이다.

왜 제품은 이런 기능들의 공통 부분집합 안에 스스로를 가둬야 할까?

기술 경쟁이 치열한 시대에는 플랫폼 고유의 차이가 없애야 할 문제가 아니라 경쟁 우위가 될 수 있다.

기업이 성능과 사용자 경험, 혁신 속도를 놓고 경쟁할 때 개발 비용의 상대적 비중은 작아진다.

이는 크로스플랫폼 프레임워크에 의존하는 기회비용을 높인다.

셋째, AI는 크로스플랫폼 프레임워크가 도입하는 복잡성을 없애지 못한다.

AI 코딩 에이전트는 개발자가 네이티브 모듈을 만들고 새로운 API에 대응하며 크로스플랫폼 프레임워크를 유지보수하는 속도를 높여 줄 수 있다.

하지만 코드를 쓰는 것은 문제의 일부일 뿐이다.

크로스플랫폼 프레임워크는 여전히 추가적인 런타임 계층, 통합 경계, 호환성 요구사항, 디버깅 복잡성을 도입한다.

문제가 생기면 개발자는 원인이 운영체제에 있는지, 네이티브 구현에 있는지, 프레임워크에 있는지, 아니면 이들 사이의 통합에 있는지 판단해야 할 수 있다.

AI는 이런 문제를 다루는 비용을 줄일 수 있지만, 아키텍처의 복잡성을 사라지게 하지는 못한다.

한편 AI는 그런 추가 추상화 계층을 요구하지 않으면서 네이티브 개발을 더 저렴하게 만들고 있다.

AI는 추상화를 구현하는 비용을 줄이지만, 그 추상화가 도입하는 복잡성은 없애지 못한다.

따라서:

크로스플랫폼 프레임워크의 경제적 가치는 양쪽에서 압박받고 있다.

네이티브 구현은 더 저렴해지고, 플랫폼 고유의 기능은 더 가치 있어지고 있다.

핵심을 재사용하되, 앱 전체일 필요는 없다

2024년에 ASR/TTS 앱을 만들면서 나는 결국 크로스플랫폼 애플리케이션 프레임워크를 쓰지 않기로 했다.

Core ML과 Whisper를 중심으로 한 C/C++ 추론 생태계를 포함해, 네이티브 기능을 직접 활용하고 싶었다.

흥미롭게도 whisper.cpp 자체는 크로스플랫폼 프로젝트다.

하지만 이것은 근본적으로 다른 종류의 코드 재사용이다.

운영체제 사이에서 C/C++ 추론 엔진을 공유하는 것은 앱 전체를 공통 UI 프레임워크, 런타임, 개발자 생태계에 억지로 끼워 넣는 것과 다르다.

네이티브 iOS 앱은 SwiftUI와 Core ML을 사용할 수 있다. 네이티브 Android 앱은 Kotlin과 Android 고유의 가속 기능을 사용할 수 있다. 그러면서도 둘 다 같은 추론 코어의 적절한 부분을 재사용할 수 있다.

크로스플랫폼 코드 재사용은 크로스플랫폼 애플리케이션 프레임워크와 같은 것이 아니다.

내 주장은 코드 공유에 반대하는 것이 아니다. 애플리케이션 전체의 구현을 공유하는 것이 언제나 경제적으로 이롭다는 가정에 반대하는 것이다.

AI는 이 구분을 점점 더 중요하게 만든다.

어색한 중간 지대

단순한 앱, 콘텐츠 중심 제품, 자주 업데이트되는 페이지라면 그냥 웹 기술을 쓰면 안 될까?

웹은 이미 거대한 개발자 생태계를 갖춘 성숙하고 폭넓게 지원되는 플랫폼을 제공한다.

풍부한 기능을 가진 앱, 특히 온디바이스 AI, 하드웨어 가속, 운영체제 기능과 깊이 통합되는 앱이라면 네이티브를 쓰면 안 될까?

크로스플랫폼 애플리케이션 프레임워크는 점점 더 그 중간에 끼어 있다.

물론 특정 상황에서는 여전히 가치가 있다. 플랫폼 고유 기능에 대한 요구가 제한된, 적당한 복잡도의 앱을 만드는 소규모 팀은 React Native나 Flutter에서 큰 이점을 얻을 수 있다.

하지만 그 가치는 가정할 것이 아니라 입증해야 한다.

그리고 코드 재사용을 의심할 수 없는 엔지니어링 미덕으로 취급하는 일을 멈춰야 한다.

수십 년 전 Java는 한 번 작성하면 어디서나 실행된다는 생각을 널리 퍼뜨렸다. 현대 소프트웨어 엔지니어링의 상당 부분은 같은 방향을 따라왔다. 추상화를 도입해 서로 다른 플랫폼을 지원하는 비용을 줄이는 방향이다.

AI는 그 결정의 바탕에 있는 경제성을 바꾸고 있다.

우리는 서로 다른 플랫폼을 위해 별도의 구현을 다시 만들게 될지도 모른다. 과거의 교훈을 잊어서가 아니라 구현 자체의 비용이 달라졌기 때문이다.

미래는 플랫폼 간 차이를 없애는 데 있지 않을 수도 있다.

그 차이를 받아들이면서 구현 비용을 극적으로 낮추는 데 있을지도 모른다.

핵심을 재사용하라. 구현을 자동화하라. 플랫폼을 살려라.