앱을 만드는 법은 예전보다 다양해졌고, 요즘은 예전보다 여건이 많이 다양해지고 옵션이 많아졌습니다.

오브젝티브 C나 자바로 어렵게 앱을 만들었다는 말을 들으면 호랑이 담배 피우던 시절 이야기라며 웃고 넘어갈 수 있는 시대가 되었습니다.

안드로이드 앱 공식 개발은 코틀린으로 진행하고 iOS 앱 공식 개발은 스위프트로 진행합니다.

이뿐만 아니라 코드 하나로 안드로이드와 아이폰 앱을 동시에 만드는 크로스 플랫폼 기술도 존재합니다.

자바스크립트로 작성하는 리액트 네이티브와 다트로 작성하는 플루터가 대표적입니다.

오늘은 앱을 만드는 네 가지 방식을 살펴보고 앱을 짜 보며 코드를 비교해 보도록 하겠습니다.

만들 앱은 버튼을 누른 만큼 숫자가 올라가는 카운터 앱입니다.

안드로이드와 iOS 네이티브는 화면을 짜는 방식이 두 가지가 있습니다.

아이폰은 UI 킷과 스위프트 UI, 안드로이드는 XML 레이아웃과 Compose가 그것입니다.

이들은 이렇게 나누어서 알아보도록 하겠습니다.

첫 번째로 안드로이드 XML 레이아웃으로 앱을 만들어 보겠습니다.

안드로이드는 XML이라고 하는 식의 파일로 레이아웃을 정리합니다.

이 파일에는 화면이 어떻게 그려지는지 정의됩니다.

다른 어떤 프로그래밍 정보도 들어가지 않습니다. XML 레이아웃에서 버튼이 텍스트 뷰를 삽입함으로써 화면을 미리 구성해 볼 수 있습니다.

안드로이드 공식 언어는 코틀린과 자바입니다. 자바는 끝도 없이 요구되는 타자로 악명이 높습니다.

그렇게 안드로이드 앱 개발은 코틀린을 주로 사용합니다.

그러나 자바로 개발해도 딱히 문제는 없습니다.

안드로이드의 화면을 구성하는 단위는 액티비티입니다. XML 레이아웃에서는 뷰의 아이디를 붙일 수 있습니다.

이 아이디를 이용해 액티비티의 뷰를 연결할 수 있습니다.

코틀린으로 작성된 액티비티 내부에는 변수를 선언할 수 있습니다.

버튼을 클릭하면 변수의 카운터 값을 증가시키게 지시합니다. 그 값을 텍스트 뷰에 반영하도록 주시합니다.

이렇게 카운터 앱을 구현할 수 있습니다.

두 번째로 컴포즈 방식으로 앱을 만들어 보겠습니다. 제팩 컴포즈는 단연 전에 나온 뷰 구성 방식입니다.

XML 방식으로 앱을 구성했을 때는 값이 어떻게 보일지 명령하듯이 프로그래밍을 했습니다.

이런 방식은 연결한 컴포넌트들이 많아지면 변수와 화면을 연결하는 코드를 짜 줘야 했죠.

이런 방식의 코드 구현이 조금 성가시다는 지적이 있었습니다. 이에 대한으로 요즘은 값과 UI 연결을 선언만 해주면 연결이 되는 방식을 사용하고 있습니다.

컴포즈도 이런 선언적인 방식을 사용합니다. 컴포즈는 뷰를 XML 레이아웃에 저장하지 않습니다.

그 대신 컴포저블을 붙인 코틀린 함수의 내부에 붙입니다.

이 함수는 표현할 뷰를 리턴합니다.

카운터를 위한 변수를 하나 만들어 봅시다. 변수 뒤에 리멤버를 붙이면 변수가 화면에 미친다는 상태를 나타낼 수 있습니다.

텍스트 뷰는 상태를 연결하여 값을 표현합니다.

버튼을 클릭하는 것도 마찬가지로 상태를 변경합니다.

컴포즈 UI는 전통적인 개발 방식과는 전혀 다른 방식을 취합니다.

배우고 구현할 때 많은 공부와 고민이 필요합니다. 다만 코드의 줄 수가 확연히 줄어든다는 장점이 있습니다.

그래서 최근 많은 안드로이드 앱들이 XML 레이아웃 방식에서 컴포즈 UI 방식으로 앱을 전환하고 있습니다.

세 번째로는 iOS UI 기술로 앱을 만들어 볼 iOS 스위프트라는 언어를 사용합니다.

스위프트는 맥, 아이폰, 아이패드 앱을 작성하기 위해 사용하는 표준 프로그래밍 언어입니다.

그전에 애플 진영의 표준 프로그래밍 언어는 오브젝티브 C라는 언어였습니다.

자바스크립트가 널 비슷한 게 두 개가 있다면 오브젝티브 C는 한 서더 떠서 네 개가 존재합니다.

이것만 봐도 알 수 있듯 오브젝티브 C는 배우기 어려운 언어로 악명이 높았습니다.

현재 iOS 메인 언어는 스위프트로 굳건히 자리 잡았습니다.

오브젝티브 C보다 훨씬 어렵기에 오브젝티브 C로 아이폰 앱을 프로그래밍하는 건 권장하지 않습니다.

스위프트는 독특한 메모리 관리 기법이 있습니다. 그래서 깊게 파고들면 난이도가 있습니다.

그러나 취미 레벨에서 간편하게 써보자 한다면 그렇게 배우기 어려운 언어는 아닙니다.

원래 iOS 개발은 스토리보드에서 직접 화면을 디자인하고 코드에 드래그해서 연결하는 방식을 사용했습니다.

앱 개발에 직관적인 디자인을 도입한 겁니다. 애플 특유의 강박적인 발상이 인상에 있습니다.

그러나 연결하고 끊고 하다 보면 꽤나 시간이 오래 걸립니다.

복잡하고 살기 바쁜 삶을 산다면 스토리보드 기반 방식을 잘 쓰지 않습니다.

안드로이드 화면 액티비티가 구성한다면 iOS 화면은 UI 킷의 UI 뷰 컨트롤러가 구성합니다.

iOS 앱은 대부분 뷰를 코드에서 생성하고 코딩으로 배치하는 방식이 있습니다.

이 뷰들의 구성은 오토 레이아웃이라는 방식으로 배치합니다.

오토 레이아웃은 뷰들의 상호 재우를 수학적으로 제약 조건을 지정해 주는 배치 방식입니다.

이 카운터 앱에서는 라벨과 버튼의 중앙부가 전체 화면의 중앙부와 같다는 오토 레이아웃 제약을 걸었습니다.

오토 레이어는 까다롭고 미리 보기를 지원하지 않습니다. 실제로 돌려보기 전까지는 어떻게 구성될지 파악이 어렵습니다.

그래서 iOS UI 개발은 단연 난이도가 높습니다.

화면 갱신 방식은 안드로이드의 xml 레이아웃과 유사합니다.

버튼이 클릭되면 물리 함수를 지정합니다. 이 함수 안에서는 변수의 값을 변경하고 변경된 값에 맞게 텍스트 라벨의 표시 값을 변경해 줍니다.

네 번째로는 iOS 스위프트 UI 앱을 만들어 보겠습니다.

스위프트 UI 아이패드, 맥, 아이폰 앱을 동시에 개발할 수 있는 화면 개발 방식입니다.

세 기기에서 공통으로 쓸 수 있을 법한 레이아웃만 우선 순위로 주요합니다.

카메라 이미지 선택 등 아이폰에만 있을 법한 화면은 UI 키을 가져다 써야 합니다.

스위프트 UI, 안드로이드 컴포즈럼 선언하는 방식으로 화면을 구성합니다.

오토 레이어시는 난해한 개발 방식을 안 수로 됩니다.

마찬가지로 카운터를 위한 변수를 하나 만들어 봅시다. 변수 앞에 스테이트를 붙이면 변수가 화면에 영향을 미친다는 상태를 나타낼 수 있습니다.

이 변수를 텍스트에서 직접 출력하고 버튼을 클릭하면 값을 변경시키면서 화면 값도 변합니다.

스위프트 UI 쓴다고 UI 키 사용을 아예 없앨 수 없습니다.

그러나 코드가 UI 키보다 짜기 쉽습니다. 최근 주된 화면을 스위프트 UI 변환하는 식으로 앱 개발이 진행되고 있습니다.

다섯 번째로는 리액트 네이티브로 앱을 만들어 보았습니다.

리액트 네이티브는 페이스북에 적극 밀어주는 개발 방식입니다.

앱 개발에서 부동의 1위를 지키는 리액트를 쪽에 가져온 거라고 볼 수 있겠습니다.

리액트의 학습 난이도는 꽤 높은 편이지만 인기가 나 학습자료와 사용 자료는 많습니다.

리액트 네이티브는 사용자 수가 적지만 리액트 고수들의 도움을 어느 정도 받을 수 있습니다.

그래서 리액트 전문가들이 앱을 만들거나 앱 개발 소들이 두 개의 앱을 한 번에 만들려고 할 때 애용되고 있습니다.

리액트 네이티브는 네이티브 방식에 비하여 점유율이 당연히 적습니다.

페이스북이나 인스타그램 앱을 필두로 많은 앱들이 리액트 네이티브를 사용하고 있습니다.

한국에서도 꽤나 많은 앱들이 리액트 네이티브를 사용하고 있습니다.

리액트 네이티브는 웹 개발 언어인 자바스크립트 혹은 타입스크립트로 개발합니다.

스크립트는 타입이 동적이고 덕 타이핑이라는 컨셉을 알아야 합니다.

기존 앱 개발 언어와는 다른 점이 매우 많아 어색할 수 있겠습니다.

리액트는 뷰를 겹겹이 쌓는 방식으로 앱을 그립니다. 안드로이드의 Compose나 iOS 스위프트 UI 형식이 매우 유사합니다.

사실 이런 방식은 Compose나 스위프트 UI 다 이쪽이 먼저 나왔습니다.

2013년에 리액트가 발표되었을 때는 새로운 시도로 받아들여졌습니다.

리액트에서 상태가 담긴 변수를 만들려면 유즈 스테이트라는 특정한 함수를 써야 됩니다.

유즈 스테이트는 현재 상태와 상태를 바꾸기 위해서 불러야 하는 함수를 리턴합니다.

변수 자체를 바꾼다고 화면에 영향을 주지 않고 변경 함수를 불러야 화면에 표시된 값도 변경됩니다.

리액트 네이티브는 배우기는 어렵고 네이티브에 비하며 사용자도 얇은 편입니다.

그렇지만 이미 많은 복잡한 앱들이 리액트 네이티브를 사용하고 어느 정도 검증되어 있습니다.

아이폰과 안드로이드 두 플랫폼 앱을 동시에 만들기 위해서 용이되고 있습니다.

마지막으로 플러터를 이용해 앱을 만들어 보았습니다. 플러터는 구글이 만든 크로스 플랫폼 개발 방식입니다.

플러터는 급속도로 인기를 끌어 사용자들을 끌어모으고 있습니다.

플러터가 네이티브, 리액트 네이티브보다 배우기가 쉬운 게 한 요인이 아닌가 싶습니다.

플러터는 2017년에 출시되어 역사가 짧습니다.

그렇게 운영하는 회사도 적으며 플러터의 경험 많은 개발자 수도 적습니다.

앱 개발의 전문성이 없는 신생 회사들이 플러터로 앱을 만드는 경우가 왕왕 있습니다.

그러다가 초기 개발자가 퇴사하여 신규 개발자를 구하기 힘들어 하는 우여곡절도 있는 편입니다.

플러터는 다트라고 하는 프로그래밍 언어를 사용합니다.

플러터 이외에는 쓰이지 않는 언어이지만 언어 자체가 그렇게 배우기 어렵진 않습니다.

플러터는 리액트의 영향을 받은 뷰 방식을 사용합니다.

트리 구조를 이루는 위젯들을 조합하여 화면을 표시합니다. 이런 뷰들을 빌드라는 함수에 넣으면 화면에 표시가 됩니다.

변화가 없는 화면은 코드가 단순합니다.

어떤 모바일 앱 개발 방식이 최고인가?

전직 수능 전과목 만점자. 서울대 컴퓨터공학부 졸업. 현직 개발자.

토스 후원하기 : https://toss.me/worlddev
투네이션 후원하기 : https://toon.at/donate/worlddev
기타 문의 : over.horizon.dev@gmail.com

후원은 영상 제작에 큰 도움이 됩니다!
