모바일 개발

손에 들고 다니는 기기에서 도는 앱을 만드는 구역입니다. 앱이 언제 일할 수 있는지는 기기의 운영체제가 정합니다. 만든 앱은 대개 그 플랫폼의 스토어를 거쳐 사용자에게 갑니다. 무엇을 하는 일이냐는 물음의 답이 한 문장이 아니라 목록으로 열립니다.

쉽고 빠른 이해

이 구역이 무엇을 다루나 — 손에 들고 다니는 기기에서 도는 앱을 만드는 일입니다. 화면을 여러 기기 크기에 맞추는 일, 기기 기능을 쓰려고 사용자에게 권한을 받는 일, 배터리를 아끼고 화면 밖에서 도는 제한 안에서 일하는 일, 만든 앱을 스토어를 거쳐 사람 손에 넘기는 일까지 한 자리에 있습니다. 여기 드는지 안 드는지는 무엇으로 만들었느냐로 가릅니다 — 웹 기술로 만들어 기기에 설치한 앱은 밖이고, 화면 일부가 웹이어도 플랫폼이 주는 도구로 담았으면 안입니다.

왜 한 문장 정의가 안 서나 — 무엇을 만드느냐가 아니라 어디에서 도는 것을 만드느냐로 묶인 이름이기 때문입니다. 화면을 그리는 방식도, 시스템과 주고받는 방식도, 배포되는 방식도 서로 다른데 전부 이 구역 안에 있습니다. 이런 사정을 놓치면 다른 앱을 직접 부를 수 없고 시스템에 의도를 전달해야 한다는 것과, 화면 안팎을 오갈 때마다 그에 맞춰 동작을 조정해야 한다는 것을 놓칩니다.

안에서 무엇으로 갈리나 — 시스템이 앱의 진입점을 쥐고 있어서 앱이 직접 켜지는 게 아니라 시스템이 필요할 때 프로세스를 띄우는 방식부터 다릅니다. 폰만 보느냐, 태블릿·시계·차량 화면까지 같은 구역으로 보느냐도 문서를 낸 조직마다 다릅니다.

상세

모바일 개발은 무엇을 만드느냐가 아니라 어디에서 도는 것을 만드느냐로 묶인 이름입니다. iOS와 안드로이드가 그 대표적인 예입니다.

이 구역의 성격을 만드는 것은 앱이 자기 실행을 혼자 쥐고 있지 않다는 점입니다. Android Developers 문서는 앱 컴포넌트를 안드로이드 앱의 본질적인 구성 요소로 적습니다. 각 컴포넌트는 시스템(기기 운영체제)이나 사용자가 앱으로 들어오는 진입점이라고 적습니다. 컴포넌트의 종류로 액티비티와 서비스와 브로드캐스트 리시버와 콘텐츠 프로바이더 넷을 듭니다. 종류마다 목적이 다르다고 적습니다. 컴포넌트가 만들어지는 방식과 없어지는 방식을 정하는 생명주기도 종류마다 다르다고 적습니다. 각각 무엇을 하는지는 그 이름의 항목이 받습니다.

시스템이 컴포넌트를 시작할 때 그 앱의 프로세스가 아직 돌고 있지 않으면 프로세스부터 시작한다고 적습니다. 그래서 다른 대부분의 시스템에서 도는 앱과 달리 안드로이드 앱에는 단일 진입점이 없다고 적습니다. main() 함수가 없다는 것입니다. 시스템은 각 앱을 별도의 프로세스에서 돌린다고 적습니다. 그 프로세스에는 다른 앱 접근을 제한하는 파일 권한이 걸립니다. 그래서 앱이 다른 앱의 컴포넌트를 직접 활성화할 수는 없다고 적습니다. 대신 특정 컴포넌트를 시작하겠다는 의도를 담은 메시지를 시스템에 전달한다고 적습니다. Android Developers 의 인텐트와 인텐트 필터 문서는 이 메시지를 인텐트라고 부릅니다. 요청하는 앱과 대상 컴포넌트 사이에는 이렇게 언제나 시스템이 낍니다.

sequenceDiagram
    participant 앱 as 요청 앱
    participant 시스템
    participant 대상 as 대상 컴포넌트
    앱->>시스템: 인텐트 전달(대상 컴포넌트를 시작하겠다는 의도)
    alt 대상 앱의 프로세스가 아직 안 돌고 있음
        시스템->>시스템: 프로세스부터 시작
    end
    시스템->>대상: 활성화

앱을 이렇게 갈라 두는 구조에는 이름이 붙어 있습니다. Android Developers 의 보안 안내 문서는 이 구조를 앱 샌드박스라고 부릅니다.

기기가 앱을 재우고 깨운다는 점도 같은 구역에서 나옵니다. Apple Developer 문서는 앱의 현재 상태가 그 앱이 그때 무엇을 할 수 있는지와 무엇을 할 수 없는지를 정한다고 적습니다. 포그라운드 앱은 사람의 주의를 받고 있어서 CPU(Central Processing Unit, 중앙처리장치)를 포함한 시스템 자원에 우선권을 갖는다고 적습니다. 반대로 백그라운드 앱은 화면 밖에 있으므로 가능한 한 적게 일해야 한다고 적습니다. 되도록 아무 일도 하지 않는 편이 낫다고 덧붙입니다. 앱이 상태에서 상태로 옮겨 갈 때마다 그에 맞춰 동작을 조정해야 한다고 적습니다.

이런 사정을 놓치면 웹이나 서버를 만들 때와 같은 방식으로 접근하게 됩니다. 그러면 다른 앱의 컴포넌트를 직접 부를 수 없고 시스템에 의도를 전달해야 한다는 것과, 포그라운드와 백그라운드를 오갈 때마다 그에 맞춰 동작을 조정해야 한다는 것을 놓칩니다. 그래서 이 구역에서 마주치는 것이 한 문장으로 닫히지 않습니다. 화면을 여러 크기의 기기에 맞추는 일이 있습니다. 기기의 기능을 쓰려면 사용자에게 권한을 받아야 하는 일이 있습니다. 배터리와 백그라운드 실행에 걸린 제한 안에서 도는 일이 있습니다. 만든 것을 사람 손에 넘기는 경로도 이 구역 안에 있습니다.

경계

설치해 쓰는 웹 앱

브라우저 기술로 만들어 기기에 설치해 쓰는 웹 앱도 이 구역인가. 아닙니다. MDN(Mozilla Developer Network)은 PWA(Progressive Web App, 프로그레시브 웹 앱)를 웹 플랫폼 기술로 만든 앱으로 정의합니다. 다만 플랫폼 전용 앱과 같은 사용자 경험을 주는 앱이라고 적습니다. 같은 문서가 플랫폼 전용 앱은 따로 정의합니다. 특정 운영체제나 기기 부류를 겨냥해 대체로 공급자가 주는 SDK(Software Development Kit, 소프트웨어 개발 키트)로 만든다는 것입니다. 보통 공급자의 앱 스토어로 배포된다는 것도 함께 적습니다. 두 정의를 가르는 자리는 무엇으로 만들었느냐입니다.

설치된다는 사실이 이 판정을 뒤집지 않습니다. MDN 은 PWA 를 기기에 설치할 수 있다고 적습니다. 플랫폼의 앱 스토어에서 설치하거나 웹에서 바로 설치할 수 있다고 적습니다. 설치된 뒤에는 플랫폼 전용 앱들과 나란히 아이콘이 생긴다고 적습니다. 브라우저 안의 웹사이트가 아니라 독립 앱으로 실행된다고도 적습니다. 놓이는 자리와 실행되는 모양이 같아져도 만든 기술이 갈립니다.

웹뷰로 그린 화면

앱 화면을 웹뷰로 그리면 그 일은 이 구역 밖인가. 아닙니다. Android Developers 문서는 웹 애플리케이션이나 웹 페이지를 클라이언트 앱의 일부로 내주는 데 웹뷰를 쓴다고 적습니다. WebView 클래스는 안드로이드 View 클래스의 확장이라고 적습니다. 액티비티 레이아웃의 일부로 웹 페이지를 보여 준다고 적습니다. 주소 표시줄이나 탐색 컨트롤 같은 완성된 웹 브라우저의 기능은 들어 있지 않다고 적습니다. 기본값으로 하는 일은 웹 페이지를 보여 주는 것뿐이라고 적습니다.

Apple Developer 문서도 WKWebView 를 앱 UI(User Interface, 사용자 인터페이스)에 웹 콘텐츠를 넣는 플랫폼 네이티브 뷰(웹 기술이 아니라 플랫폼이 자체 도구로 만든 화면 요소)로 적습니다. 앱의 네이티브 뷰와 나란히 웹 콘텐츠를 보여 준다고 적습니다. 그 콘텐츠는 HTML(HyperText Markup Language, 하이퍼텍스트 마크업 언어)과 CSS(Cascading Style Sheets, 종속형 스타일 시트)와 자바스크립트라고 적습니다. 양쪽 문서 모두 웹뷰를 플랫폼이 주는 뷰로 둡니다. 그 뷰가 놓이는 자리는 앱 화면 안입니다. 화면을 채운 것이 웹 문서여도 그것을 담은 앱은 플랫폼 SDK 로 만들어집니다.

이견

이 구역을 어디까지로 보느냐가 문서를 낸 조직마다 갈립니다.

코드 하나로 여러 플랫폼을 겨냥하는 도구

Flutter 공식 소개는 Flutter 를 하나의 코드베이스로 여러 플랫폼을 겨냥해 네이티브로 컴파일되는 앱을 만드는 프레임워크로 적습니다. React Native 공식 소개는 다르게 적습니다. React Native 로 만든 것을 네이티브 앱(경계에서 다룬 플랫폼 전용 앱과 같은 말입니다)이라 부르고, 다른 앱들과 같은 네이티브 플랫폼 API(Application Programming Interface, 응용 프로그램 인터페이스)를 그대로 쓴다고 적습니다. 코드 하나로 여러 플랫폼을 겨냥하는 것 자체를 자기 범위로 내세우는 쪽과, 결과물이 각 플랫폼 고유의 방식으로 동작한다는 것을 내세우는 쪽으로 문서가 갈립니다. 다만 두 소개 모두 결과물이 네이티브로 컴파일되거나 네이티브 플랫폼 API 를 그대로 쓴다고는 적어서, 경계에서 본 기준(무엇으로 만들었느냐)으로는 어느 쪽 소개를 따르든 앱 자체는 이 구역 밖으로 나가지 않습니다.

포함되는 기기 범위

Android Developers 의 멀티기기 문서는 폰 앱을 최신 Jetpack Compose API 로 만드는 경우를 적습니다. Compose 가 태블릿과 폴더블과 ChromeOS 기기와 차량 인포테인먼트 시스템과 Android XR(Extended Reality, 확장 현실) 2D 에 맞게 앱을 최적화한다고 적습니다. 개발자가 추가로 들이는 개발 노력은 최소한이라고 적습니다. 같은 문서는 안드로이드가 웨어러블부터 폴더블과 TV 와 XR 까지 모든 기기 크기와 구성을 지원한다고 적습니다. 폰 앱을 만드는 자리와 다른 기기용을 만드는 자리를 한 구역으로 묶어 적는 것입니다.

Apple 은 이렇게 여러 기기를 한 문서로 묶지 않습니다. 시계 쪽은 별도 프레임워크 문서로 둡니다. Apple Developer 문서의 WatchKit 은 watchOS 앱을 만드는 자리로 적혀 있습니다. 태블릿과 시계와 차량 화면을 폰 앱과 같은 구역에 넣느냐가 문서를 따라 이렇게 달라집니다.

모바일 개발

상세

경계

설치해 쓰는 웹 앱

웹뷰로 그린 화면

이견

코드 하나로 여러 플랫폼을 겨냥하는 도구

포함되는 기기 범위

관련 항목

모바일 개발이 딛는 기반

앱 실행 모델을 이루는 구성 요소

앱을 짓는 도구

화면을 맞추는 방식

기기가 거는 실행 제약

기기 안에서 데이터를 다루는 방식

서버와 주고받는 통신 방식

앱을 사용자에게 배포하는 절차

이 구역에서 자주 나는 오류·장애

헷갈리는 이웃

모바일 개발을 정의하는 문서