요즘 대다수 애플리케이션은 크로스 플랫폼일 것이다. 사용자에게는 좋지만 많은 경우 개발자에게는 어려운 일이다. 둘 이상의 플랫폼을 대상으로 할 경우 경로를 어떻게 관리할지, 데스크톱 애플리케이션 UI를 어떻게 작성할지, 다른 플랫폼을 위해 바이너리를 어떻게 컴파일할지를 비롯해 온갖 판도라의 상자가 열리게 된다. 이 기사에서는 성공적인 크로스 플랫폼 애플리케이션을 위한 길을 안내하는 4가지 핵심 개념을 소개한다.

마이크로소프트 윈도우는 항상 예외

마이크로소프트 윈도우는 모든 운영체제를 통틀어 예외가 가장 많이 필요한 운영체제다. 리눅스와 맥OS는 많은 부분에서 비슷해서 대부분의 동작이 호환된다. 그러나 윈도우에는 이 둘과 전혀 다른 동작이 많고 이로 인해 크로스 플랫폼 개발이 복잡해진다.

줄바꿈

리눅스와 맥OS의 경우 텍스트 파일의 표준 줄바꿈 문자는 새 줄 문자(n)다. 윈도우에서는 리턴과 새 줄 문자(rn다. 필자가 윈도우에서 사용하는 편집기는 기본적으로 리눅스나 맥 스타일을 사용하도록 구성할 수 있는데, 일관성을 위해서는 그렇게 하는 것이 좋다.

윈도우 시스템에서 서버(어느 OS를 실행하든)로의 웹 양식 텍스트 입력은 줄바꿈 예외에 특히 취약하다. 윈도우의 브라우저에서 제출된 텍스트 항목에는 줄이 끝날 때 rn이 있다. 따라서 일관성을 위해서는 웹 프레임워크가 이 문자를 자동으로 n으로 변환하도록 해야 한다.

파일 경로 구분자

윈도우는 백슬래시()를 경로 구분자로 사용할 수 있다. 리눅스와 맥OS에서 백슬래시는 거의 모든 경우 이스케이프 문자다. 이 두 플랫폼의 경로는 슬래시(/)로 연결된다. 다행히도 최근 대부분의 윈도우 버전에서는 경로 구분자에 슬래시도 사용할 수 있다.

소프트웨어 개발자는 가능한 모든 경우 문자열에서 수동으로 경로를 구성하는 방식을 피하고 일종의 객체 지향 경로 처리 방법을 사용해야 한다. 예를 들어 파이썬의 표준 라이브러리에 있는 pathlib모듈은 경로를 문자열이 아닌 객체로 변환한다. 그러면 OS에 관계없이 프로그래밍을 통해 적절한 경로 구분자를 적용할 수 있다.

파일 시스템의 대소문자 구분

윈도우는 전통적으로 파일 시스템에서 대소문자를 구분하지 않는 문화를 갖고 있다. 운영체제 자체는 대소문자를 구분하지만 윈도우의 FAT, FAT32, NTFS 파일 시스템은 기본적으로 대소문자를 구분하지 않는다.

애플리케이션에 사용되는 모든 파일 이름이 대소문자 구분과 무관하게 고유하다면(예를 들어 myfile과 MyFile이 동일한 디렉터리에 있지 않다면) 문제가 되지 않는다. 이 문제가 아니더라도 고유한 이름을 사용하는 것이 좋은 전략이다.

가능한 경우 플랫폼 네이티브 UI보다 웹을 사용

일렉트론(Electron)이 미움을 많이 받긴 해도 일관성 있는 진정한 크로스 플랫폼 앱 만들기라는 한 가제 과제는 해결한다. 일렉트론이 이 문제를 해결하는 방법은 앱의 프론트엔드 렌더링에 웹 기술을 사용해서 앱을 로컬에 호스팅되는 웹 애플리케이션으로 만드는 것이다.

일렉트론에 대한 비판은 대부분 최종 결과물의 크기(몇 백 메가바이트에 이를 수도 있음), 특정 작업에 대한 웹 프론트엔드의 견고성 부족, 또는 HTML, CSS, 자바스크립트로 프론트엔드를 만들 수밖에 없다는 점에 집중된다.

첫 번째 비판은 전적으로 타당하다. 일렉트론 빌드는 대체로 용량이 크다. 일렉트론의 설계상 완전한 독립 실행형 웹 브라우저 인스턴스를 번들로 함께 넣어야 하기 때문이다. 이로 인해 타우리(Tauri)와 같은 대안이 부상했다. 타우리는 러스트 언어를 사용하며 결과물 패키지 크기가 훨씬 더 작다. 브라우저가 포함된 모놀리식 결과물에서 벗어나 가능한 한 운영체제의 기존 웹 뷰 구성요소를 활용하는 방향을 향하는 추세다.

두 번째 불만, 즉 앱에 따라서 웹 브라우저가 제공할 수 있는 수준을 넘어서는 강력한 동작이 필요할 수 있다는 불만은 시간이 지나면서 근거가 빈약해지고 있다. 많은 경우 관건은 브라우저의 기능보다는 원하는 기능을 잘 사용할 수 있게 해주는 프론트엔드 프레임워크를 찾는 것이기 때문이다. 예를 들어 인터랙티브 3D 그래픽의 경우 three.js 라이브러리는 대부분의 완전한 데스크톱 앱 못지않은 인상적인 결과를 제공한다.

세 번째 비판인 HTML, CSS, 자바스크립트에 대한 과도한 의존성 역시 정당한 비판이다. 웹 애플리케이션 개발은 다른 종류의 애플리케이션 개발과 구분되는 고유한 기술이자 과학이다. 프론트엔드의 상호작용을 위한 방대한 선택 범위는 웹 애플리케이션 개발을 시작하는 개발자에게 당황스러울 수 있다. 좋은 소식은 웹 UI가 있는 애플리케이션을 개발하기 위한 자습서, 툴, 재사용 가능한 구성요소, 문서화된 방법, 기능적 예제를 다루는 문화가 풍성하다는 점이다. HTMX와 같은 툴은 일반적인 동작 패턴을 사용하는 앱을 간단히 만들 수 있게 해주며, 일부 언어는 프론트엔드 코드를 프로그래밍으로 생성하는 라이브러리를 제공한다(예를 들어 파이썬용 앤빌(Anvil)).

크로스 컴파일에서 다른 플랫폼 사용하기

크로스 컴파일은 다른 플랫폼에서도 실행되도록 프로그램을 컴파일하는 방법(또는 기술)이다. 여러 플랫폼에 걸쳐 애플리케이션을 제공할 때 거쳐야 하는 복잡한 작업 중 하나다.

어느 언어를 사용하든 크로스 컴파일에서 가장 중요한 한 가지 규칙은 대상 플랫폼에서 직접 컴파일하는 것이 항상 더 쉽다는 것이다. 또 다른 중요한 규칙은 비용을 지불하고 다른 사람에게 이 일을 맡길 수 있다면 그렇게 하는 편이 더 낫다는 것이다.

일부 언어는 크로스 컴파일의 어려움을 줄여주는 툴과 기능을 제공한다. 예를 들어 러스트는 크로스 컴파일을 자체 툴체인에서 반 네이티브 기능으로 제공한다. 그러나 예를 들어 적절한 링커를 확보하는 등 개발자가 직접 해야 하는 부분도 여전히 존재한다.

크로스 플랫폼 컴파일에서 한 가지 큰 문제는 비대칭성이다. 맥OS 사용자라면 맥에서 손쉽게 윈도우 또는 리눅스 가상 머신을 설정하고 유지할 수 있다. 리눅스나 윈도우를 사용한다면 이러한 플랫폼에서 맥OS를 에뮬레이션하기는 상대적으로 더 어렵다. 불가능하지는 않지만 더 어려운데, 가장 주된 이유는 법적인 문제다. 맥OS의 EULA는 애플 이외의 하드웨어에서 맥OS 사용을 허용하지 않기 때문이다. 가장 쉬운 방법은(가장 저렴하지는 않지만) 맥 시스템을 따로 구매해서 사용하는 것이다. 다른 방법은 osxcross와 같은 툴을 사용해서 리눅스, 프리BSD 또는 오픈BSD 시스템에서 크로스 컴파일하는 것이다.

또 다른 일반적인 방법은 현대 소프트웨어 제공 방법과도 가장 잘 맞는 옵션으로, 깃허브 액션(깃허브에 호스팅되는 러너를 통해) 또는 애저 파이프라인 같은 시스템을 사용해서 지원되는 대상 플랫폼에서 소프트웨어를 빌드하는 것이다(깃허브와 애저 모두 맥OS를 지원함). 단점은 서비스 사용에 대한 비용을 지불하는 것이지만, 이미 둘 중 어느 한 플랫폼에 투자했다면 가장 경제적이고 덜 복잡한 방법이다. 또한 시스템 유지보수 부담도 덜 수 있다.

애플리케이션 개발 플랫폼을 주시하라

앱을 개발하고 배포하는 방법은 항상 변화한다. 예를 들어 누가 컨테이너 혁명을 예상할 수 있었을까? 파이썬이 머신러닝과 AI(그 외에도 많은 분야에서)를 위한 지배적인 언어가 될 것이라고 어느 누가 예상했을까? 크로스 플랫폼 배포가 빠르게 필수 기능으로 부상하고 있는 만큼 항상 미래를 주시하는 것이 좋다.

웹어셈블리를 생각해 보자. 웹어셈블리는 주요 크로스 플랫폼 런타임이자 지나친 성능 희생 없이 이식성을 달성하는 방법으로 자리를 잡아가고 있다. 나아가 적절한 사용 사례에서는 컨테이너 기술을 대체할 가능성도 있는 것으로 주목받고 있다. 와즘 런타임 환경은 모든 측면에서 아직 초기 단계에 있지만 “최대한 많은 플랫폼”을 목표로 한다면 와즘이 제공하는 기능을 살펴볼 만하다.
dl-itworldkorea@foundryco.com