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

오브젝티브 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

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


저세상개발자

과거에는 Objective-C나 Java를 사용한 앱 개발이 일반적이었지만, 현재는 Kotlin(Android)과 Swift(iOS)가 주류를 이루고 있습니다. **하나의 코드로 Android와 iOS 앱을 동시에 개발할 수 있는 크로스 플랫폼 기술**인 React Native와 Flutter도 주목받고 있습니다.

🤖 Android 네이티브 개발 (XML 레이아웃 & Compose UI)

Android 앱 개발 시, XML 레이아웃을 사용하여 UI를 구성할 수 있습니다. XML 파일은 화면의 디자인을 정의하며, Kotlin 코드를 통해 화면의 요소들을 제어합니다. **Kotlin은 Java에 비해 코딩이 더 간결하며 효율적입니다**.

Jetpack Compose는 XML 레이아웃의 단점을 보완하기 위해 등장한 최신 UI 개발 방식입니다. Compose는 선언형 프로그래밍 방식을 채택하여, **변수와 UI 간의 연결을 단순화하고 코드 양을 줄여줍니다**.

🍎 iOS 네이티브 개발 (UIKit & SwiftUI)

Swift는 Mac, iPhone, iPad 앱 개발에 사용되는 표준 프로그래밍 언어입니다. Objective-C에 비해 배우기 쉬우며, iOS 개발의 주류 언어로 자리 잡았습니다. UIKit을 사용하여 UI를 구성할 때, Auto Layout을 통해 화면 요소들의 제약 조건을 수학적으로 정의합니다. **Auto Layout은 미리보기가 어렵다는 단점이 있습니다**.

SwiftUI는 iPad, Mac, iPhone 앱을 동시에 개발할 수 있는 UI 개발 방식입니다. SwiftUI는 Android의 Compose와 유사한 방식으로 화면을 구성하며, **UI 코드를 더 쉽게 작성할 수 있도록 지원합니다**.

⚛️ React Native: JavaScript 기반 크로스 플랫폼

React Native는 Facebook에서 적극적으로 지원하는 크로스 플랫폼 개발 방식입니다. React에 대한 이해가 필요하지만, **React 전문가의 도움을 받을 수 있다는 장점**이 있습니다. 많은 복잡한 앱들이 React Native를 사용하여 개발되었으며, iPhone과 Android 앱을 동시에 만들 수 있습니다.

💙 Flutter: Google의 크로스 플랫폼 프레임워크

Flutter는 Google에서 만든 크로스 플랫폼 개발 방식입니다. Dart라는 프로그래밍 언어를 사용하며, **배우기 쉽고 앱 개발이 간단하다는 장점**이 있습니다. 주로 가벼운 앱을 빠르게 개발하는 데 사용됩니다.

Flutter는 React의 영향을 받은 뷰 구조를 사용하며, 위젯들을 트리 형태로 결합하여 화면을 구성합니다. **setState 함수를 사용하여 화면에 표시되는 값을 변경할 수 있습니다**.

다양한 앱 개발 방식이 존재하지만, **하나의 방법을 깊이 있게 학습하는 것이 중요합니다**. 개발 방식을 변경하는 것은 처음부터 다시 시작하는 것과 같은 노력이 필요하므로 신중하게 결정해야 합니다.

앱 시장에서는 Android native와 iPhone native가 여전히 강세를 보이고 있습니다. 개발자 취업을 고려한다면, Android 또는 native iPhone 개발을 선택하는 것이 좋습니다.

다양한 앱 개발 방식 소개 및 비교

Objective-C나 Java를 사용한 앱 개발은 과거의 이야기처럼 느껴지는 시대가 옴.

Kotlin(Android), Swift(iOS)를 비롯하여 React Native, Flutter와 같은 크로스 플랫폼 기술 존재.

본 영상에서는 4가지 앱 개발 방식을 통해 카운터 앱을 만들고 코드를 비교할 예정.

Android XML 레이아웃을 이용한 앱 개발

Android는 XML 파일에 레이아웃을 구성하며, Kotlin 또는 Java를 사용하여 개발.

XML 레이아웃에서 뷰 ID를 할당하고, Kotlin Activity에서 해당 뷰를 연결하여 변수를 선언.

버튼 클릭 시 변수 값을 증가시키고, 텍스트 뷰에 반영하는 방식으로 카운터 앱 구현.

Compose는 XML 방식에 비해 최신 UI 구축 방식으로, 선언적 접근 방식을 사용.

Compose에서는 뷰가 XML 레이아웃에 저장되지 않고, composable 블록을 사용하는 Kotlin 함수 내에 배치.

상태(state)를 연결하여 값을 표현하고, 버튼 클릭 시 상태를 변경하는 방식으로 UI를 구현.

Swift 언어를 이용한 iOS UI 기술 앱 개발

Swift는 Mac, iPhone, iPad 앱 개발에 사용되는 표준 프로그래밍 언어이며, Objective-C보다 배우기 쉬움.

iOS 개발은 스토리보드 방식을 통해 직관적인 디자인을 도입했지만, 연결 및 해제에 시간이 소요될 수 있음.

iOS 화면은 UIKit의 UI View Controller로 구성되며, Auto Layout을 사용하여 뷰의 레이아웃을 설정.

Swift UI는 iPad, Mac, iPhone 앱을 동시에 개발할 수 있는 화면 개발 방법.

SwiftUI와 Android Compose와 유사한 방식으로 화면을 구성하며, state 변수를 사용하여 화면에 영향을 줌.

UI 키를 완전히 제거할 수는 없지만, UI 키를 사용하는 것보다 코드 작성이 더 쉬움.

React Native는 Facebook에서 적극적으로 추진하는 개발 방법으로, React의 장점을 활용.

JavaScript 또는 TypeScript를 사용하여 개발하며, 웹 개발 언어에 익숙한 개발자에게 유리.

Android XML 레이아웃 또는 iOS Swift UI 형식과 유사하게 뷰를 계층화하여 앱을 구축.

Flutter는 Google에서 만든 크로스 플랫폼 개발 방식으로, 빠른 속도로 사용자들을 끌어모으고 있음.

Dart라는 프로그래밍 언어를 사용하며, React의 영향을 받은 뷰 방식을 채택.

비교적 배우기 쉽고 앱 개발이 간단하여 가벼운 앱을 빠르게 만드는 데 주로 사용됨.

하나의 개발 방법만 잘 배워도 훌륭한 앱을 만들 수 있으며, 개발 방법을 바꾸는 것은 처음부터 다시 시작하는 것과 같은 노력이 필요.

앱 시장에서는 Android native와 iPhone native가 압도적으로 우세하며, 개발자로 취업을 고려한다면 이 두 가지를 선택하는 것이 좋음.