몇 주 동안 채팅으로 할 일 목록 앱을 만들어왔다고 해보자. 지금은 웹사이트다 — React, 데이터베이스, 특별할 것 없다. "안드로이드 버전 만들어줘"라고 입력하고 엔터를 누른다. 그 키 입력과 다운로드 폴더에 .aab 파일이 도착하는 순간 사이에 실제로 일어나는 일을 소개한다. 대부분의 플랫폼은 이 부분을 보여주지 않는데, 그들이 숨기는 그 부분이야말로 모든 고통이 있던 자리이기 때문이다.
Android .aab
Gradle이 가장 먼저 넘겨받는다. 앱의 네이티브 모듈들 — 카메라 접근, 로컬 저장소, 빌드에 딸려 온 온갖 플러그인들 — 은 각각 어떤 NDK 버전에 맞춰 컴파일되었는지 선언하는데, 그 선언들이 항상 일치하는 것은 아니다. NDK r25에 맞춰 빌드된 모듈이 r26을 전제로 한 모듈과의 링크를 거부하는 것을 본 적이 있는데, 그때 발생하는 오류는 "버전 불일치"라고 말하지 않고, .so 파일 안 세 계층 깊숙한 곳에서 심볼이 없다는 식으로 나타난다. Kotlin 버전은 좀 더 교묘하게 문제를 일으킨다. 하나의 Gradle 모듈 안에 고정된 버전이 빌드 스크립트 상단에 선언된 버전을 조용히 가려버릴 수 있고, 빌드는 성공하지만 결과물은 특정 안드로이드 버전에서 실제 사용 중 크래시를 일으키는 바이너리가 된다. 이 중 어느 것도 특별한 게 아니다. 이것은 네이티브 안드로이드를 출시하는 데 따르는 표준적인 세금이며, 팀들이 이번 주의 오류를 사라지게 하는 플래그가 무엇인지만 아는 사람을 따로 고용하는 이유다.
여기서의 빌드는 실제 툴체인을 실행하고 그 해결 작업을 스스로 처리한다.
- 런타임 크래시가 되기 전에 잡아내는 의존성 충돌
- 새로운 실패가 무언가를 가르쳐줄 때마다 매번 더 나아지는 툴체인 구성
실제 Gradle 작업을 실행하지 않고 .aab 형태만 흉내 내는 더 빠른 가짜 버전이라면 1분 안에 만들 수 있습니다. 하지만 앱에 백그라운드 서비스나 네이티브 암호화 라이브러리가 필요해지는 순간 바로 멈춰버릴 것이고, Play 스토어 심사는 하루 만에 이를 걸러낼 것입니다. 저희는 차라리 그 20분을 제대로 쓰는 쪽을 택합니다.
macOS .dmg
이 파일 하나에는 두 개의 빌드가 들어갑니다. Xcode의 커맨드라인 도구가 Apple Silicon 바이너리와 Intel 바이너리를 각각 컴파일한 뒤, lipo 하나의 유니버설 실행 파일로 결합합니다.
바이너리 하나만 배포하고 끝내고 싶은 유혹이 들 수 있습니다 — 많은 사람이 자신이 직접 고른 하드웨어가 아니라 회사에서 지급한 노트북을 쓰고 있으며, 그 노트북이 3년 된 Intel 기종일 수도 있다는 사실을 떠올리기 전까지는요. 사용자가 자신의 칩이 무엇인지 알아내게 만드는 대신(대부분은 모릅니다), 저희는 두 버전을 모두 배포하고 OS가 조용히 선택하게 합니다. 대안으로 초기에 에뮬레이션 툴체인을 사용해 Linux 머신에서 모든 것을 크로스 컴파일해본 적도 있습니다. 더 빠르긴 합니다. 하지만 그 방식은 실제 macOS 12 하드웨어에서만 나타나는 코드사이닝 엣지 케이스를 6주 뒤 배포 시점에 발견하게 되는 지름길이기도 합니다. 자기 앱이 왜 안 열리는지 전혀 모르는 당황한 사용자가 신고할 때 말이죠.
Windows 설치 프로그램
여기가 바로 첫 실행 경험이 사용자의 신뢰 여부를 결정짓는 순간입니다. Windows SmartScreen은 아직 여러분의 설치 프로그램을 알지 못합니다 — Microsoft 서버에 평판이 쌓이지 않았기 때문에 — 그래서 굵은 글씨로 "실행 안 함" 버튼이 있고 클릭해야 겨우 "실행"이 나타나는 잘 안 보이는 "추가 정보" 링크가 딸린 파란색 "Windows가 PC를 보호했습니다" 화면을 보여줍니다. macOS도 나름의 비슷한 절차를 거칩니다: 우클릭, 열기, 확인 — App Store 외부 앱은 기본적으로 신뢰되지 않기 때문입니다. 초기에는 두 경우 모두 일반적인 FAQ 페이지로 연결해뒀습니다. 하지만 지원 티켓들이 그게 통하지 않는다는 걸 보여줬습니다 — 다운로드한 파일이 악성코드일지도 모른다는 화면을 마주한 사람은 문서를 읽으러 가지 않고, 스크린샷을 찍어 해킹당한 건지 묻습니다. 그래서 설치 흐름은 OS를 감지해 정확히 필요한 세 번의 클릭을 보여주며, FAQ가 필요 없게 만듭니다. 사소해 보이지만 파일 자체도 중요합니다: 다운로드 파일명은 빌드 산출물 이름이 아니라 제품 이름을 따릅니다. "app-release-signed-v2-final.exe"를 다운로드했는데 이게 맞는 파일인지 몰라 채팅 상담에서 설명해야 하는 일은 아무도 겪지 않아야 합니다.
브라우저 확장 프로그램 매니페스트
이 파이프라인 전체에서 이질적인 존재입니다 — Gradle도, NDK도, 일반적인 의미의 컴파일 단계도 없습니다. 대신 매니페스트가 있고, 이 매니페스트는 여러분이 직접 대화할 일 없는 Chrome 웹 스토어 심사자와의 협상입니다.
| 요청된 권한 | 심사 결과 |
|---|---|
| <all_urls> (기능에 필요한 것보다 과도한 범위) | 정확히 무엇이 문제인지 밝히지 않는 상대와 2주간 이어지는 주고받기 |
| activeTab (실제 필요한 범위로 한정) | 당일 통과 |
MV3는 MV2가 쉽게 만들어줬던 부분도 복잡하게 만듭니다: 백그라운드 서비스 워커는 배터리 수명을 위한 Google의 정책적 결정에 따라 작업 도중에도 설계상 언로드될 수 있으며, 이를 견뎌야 하는 기능은 이에 맞서기보다 이를 전제로 만들어져야 합니다. 저희는 기본적으로 모든 확장 프로그램에 실제 기능이 필요로 하는 가장 좁은 권한 세트를 적용하고, 특정 기능이 요구할 때만 범위를 넓힙니다.
키스토어
Android 빌드 아래에는 절대 눈에 보이지 않지만 잃어버릴 여유가 없는 산출물이 하나 있습니다: 서명 키입니다. 이를 잃으면 앱을 업데이트할 수 없게 되는 정도가 아니라, 기존 아이덴티티로는 영구히 업데이트할 수 없게 되며, Google이 허용하는 복구 경로도 전혀 없습니다. 화려한 인프라는 아닙니다. 그냥 파일 하나일 뿐입니다. 하지만 6개월 뒤 버전을 매끄러운 업데이트로 배포하느냐, 설치 수와 리뷰가 0부터 시작하는 완전히 새로운 리스팅으로 배포하느냐를 가르는 차이입니다. 저희는 프로젝트당 하나씩 생성해 보관하여, 앞으로의 모든 빌드가 첫날과 동일한 키로 서명되도록 합니다.
이 모든 것의 바탕이 되는 채팅 스레드
위의 내용 어느 것도 별도의 "모바일 프로젝트"에 존재하지 않습니다. 웹 앱을 만든 것과 동일한 대화입니다. UI 변경을 요청하면 웹 빌드가 업데이트되고, 이어서 Android 번들을 요청하면 3주 전에 어긋나버린 포크가 아니라 바로 그 최신 상태에서 컴파일됩니다. 나중에 네이티브를 덧붙이려던 대부분의 팀은 결국 서로 벌어지는 두 개의 코드베이스를 유지하게 됩니다 — 매일 배포되는 웹 앱과, 릴리스 전마다 누군가 따라잡아야 하는 걸 기억해야 하는 네이티브 래퍼입니다. 그 간극이 바로 노후화가 생기는 지점이고, 단일한 빌드 이력이 없애는 것이 정확히 그것입니다. 다만 이는 양날의 검이기도 합니다: 최근 채팅이 대충 빠르게 진행됐다면 Android 빌드도 그것을 그대로 물려받습니다. 별도의 마무리 작업이 아니라 실제로 존재하는 것을 그대로 컴파일한 결과이기 때문에 — 실무에서는 이것이 사람들을 정직하게 만듭니다. "제출 전에 정리하자"는 식으로 건너뛸 만한 부차적 작업이 없기 때문입니다.
스토어에 올릴 준비가 되면 배포 경로가 여러분 자신의 Play 스토어 리스팅과 여러분 자신의 Apple 개발자 계정으로 인계됩니다. 저희 것이 아닙니다. 저희는 여러분과 여러분의 배포 사이에 끼어들고 싶지 않았습니다.
