개발자 생활을 10년 넘게 하다 보면, 절대 변하지 않을 것 같은 '철칙'들이 하나둘씩 깨지는 순간을 목격하게 됩니다. 윈도우 안에 리눅스가 들어오고(WSL), 자바스크립트가 서버를 돌리게 된(Node.js) 사건들이 그랬죠. 그리고 최근, 제 눈을 의심하게 만드는 또 하나의 흥미로운 소식을 접했습니다. 바로 애플 생태계의 전유물로 여겨지던 Swift 언어로 안드로이드 네이티브 앱을, 그것도 UI까지 포함해서 개발할 수 있다는 이야기였습니다. 오늘은 이 신선한 충격을 여러분과 커피 한 잔 마시는 기분으로 나눠보려 합니다.
우리가 흔히 '크로스 플랫폼'이라고 하면 플러터(Flutter)나 리액트 네이티브(React Native), 혹은 코틀린 멀티플랫폼(KMP)을 떠올립니다. 이들은 각자의 렌더링 엔진을 쓰거나 브릿지를 통해 동작하죠. 그런데 이번에 화제가 된 'SwifDroid'라는 프로젝트는 접근 방식이 꽤 재미있습니다. 단순히 비즈니스 로직만 공유하는 차원을 넘어서, 안드로이드의 네이티브 뷰 시스템을 Swift 문법으로 직접 제어하겠다는 포부를 보여주고 있습니다.
제가 가장 흥미롭게 본 부분은 코드의 생김새였습니다. 얼핏 보면 영락없는 SwiftUI 코드입니다. VStack이 있고, 메서드 체이닝으로 속성을 부여하죠. 그런데 그 속성을 자세히 들여다보면 matchParent, ConstraintLayout, MaterialButton 같은 안드로이드 개발자들에게 익숙한 용어들이 등장합니다. 마치 영어를 쓰고 있는데 문법 구조는 한국어인 상황을 보는 듯한 묘한 기시감이 듭니다. SwiftUI의 선언형 문법이 주는 편리함과 안드로이드의 UI 컴포넌트가 만난 이종 교배의 현장인 셈입니다.
기술적으로 조금만 더 깊이 들어가 볼까요? 안드로이드 시스템 깊은 곳에는 JNI(Java Native Interface)라는 녀석이 있습니다. 자바나 코틀린이 아닌 다른 언어(주로 C/C++)가 안드로이드 런타임과 소통하기 위해 거쳐야 하는 관문인데, 사실 이 JNI를 다루는 게 여간 까다로운 일이 아닙니다. 메모리 관리도 복잡하고, 디버깅도 힘들어서 많은 개발자가 기피하는 영역이죠. 그런데 이 프로젝트는 그 복잡한 JNI 레이어를 추상화해서 감춰버렸습니다. 개발자는 그저 Swift로 코드를 작성하면, 프레임워크가 알아서 안드로이드 런타임과 대화를 나누는 구조입니다. 복잡한 기계어 통역사를 고용해 두고, 우리는 편하게 우리말(Swift)로 명령만 내리면 되는 격입니다.
물론, 지금 당장 실무 프로젝트에 도입하자고 제안한다면 저는 도시락 싸 들고 다니며 말릴 겁니다. 문서에도 명시되어 있듯이 이 프로젝트는 현재 활발히 개발 중인 단계이고, 곳곳에 '공사 중' 표지판이 세워져 있습니다. 수많은 오픈소스 프로젝트가 그렇듯, 실제 프로덕션 환경에서 마주칠 엣지 케이스(Edge case)들을 모두 커버하기엔 아직 시간이 필요해 보입니다. 우리가 주니어 시절, 새로운 라이브러리가 나왔다고 무턱대고 적용했다가 유지보수의 늪에 빠져 고생했던 기억, 다들 한 번쯤 있으시잖아요?
하지만 이 시도가 주는 시사점은 분명합니다. 언어의 장벽이 점점 허물어지고 있다는 사실입니다. 코틀린이 iOS 개발 영역을 넘보듯, Swift 또한 안드로이드 진영으로 발을 뻗고 있습니다. 이는 장기적으로 우리 개발자들이 특정 언어나 플랫폼에 종속된 기술자가 아니라, 문제를 해결하는 아키텍처를 설계하는 엔지니어로 성장해야 함을 의미합니다. 문법은 도구일 뿐이고, 중요한 건 그 도구로 어떤 가치를 만들어내느냐는 것이죠.
이번 주말, 가벼운 마음으로 맥북을 열고 안드로이드 스튜디오가 아닌 곳에서 안드로이드 앱을 빌드해 보는 건 어떨까요? 화면에 "Hello from Swift!"가 뜨는 순간, 어쩌면 우리가 알고 있던 모바일 개발의 경계가 조금은 다르게 보일지도 모릅니다. 기술은 늘 이렇게 엉뚱한 상상과 도전에서 발전해 왔으니까요.
