앱은 코드 한 줄 변경하지 않고도 죽을 수 있습니다. 내부에서 무언가 고장 나는 것이 아닙니다. 주변 세상이 움직이는 것입니다. 데모 — 또는 AI가 생성한 프로토타입 (prototype) — 는 첫날의 앱 모습을 보여줍니다. 하지만 실제로 중요한 질문은 거의 던져지지 않습니다. 아무도 건드리지 않은 채 1,095일째 되는 3년 뒤에도 앱이 여전히 작동할 것인가 하는 질문 말입니다.

이것은 수사적인 질문이 아닙니다. 그 3년 동안 정확히 어떤 일이 일어나는지 설명하겠습니다.

인벤토리: 아무것도 움직이지 않을 때 망가지는 것들

스토어(Stores)가 규칙을 바꿉니다. Apple과 Google은 개인정보 보호 선언 (privacy declarations), 최소 SDK 버전, 권한 정책 (permission policies) 등 요구 사항을 계속 추가합니다. 잠자고 있는 앱은 보호받지 못합니다. 오히려 그 반대입니다. 마침내 업데이트가 배포되는 날, 앱은 태어날 당시의 규칙이 아니라 오늘날의 규칙에 따라 심판받습니다. 그리고 두 스토어 모두 너무 오래 잠들어 있는 앱을 정리하는 법을 배웠습니다. 앱 심사 (App review)는 형식적인 절차가 아닙니다. 그것은 반대편에 심사관이 있는 움직이는 요구 사항 세트이며, 앱을 제출해 본 사람이라면 누구나 그 심사관이 생각보다 더 자주 거절한다는 사실을 알고 있습니다.

운영 체제 (Operating systems)가 지원 중단 (deprecate)을 선언합니다. 모든 주요 iOS 또는 Android 릴리스는 API를 차단하거나, 점차 의무화되는 새로운 API를 도입합니다. 잘 작동하던 기능이 그냥 멈춰버립니다. 종종 충돌 (crash)도 경고도 없이, 그저 화면이 조용히 이전처럼 작동하지 않을 뿐입니다. 아무도 당신에게 말해주지 않습니다. '완성된' 앱의 제작자가 읽을 이유가 없는 릴리스 노트 (release notes)에 적혀 있을 뿐입니다.

의존성 (Dependencies)과 키 (keys)가 노후화됩니다. 제3자 라이브러리 (third-party library)가 API를 변경하거나 유지보수를 중단합니다. 인증서 (certificate)가 만료되면 푸시 알림 (push notifications)이 전송되지 않거나 업데이트 서명 (signed)이 중단됩니다. 다시 말하지만, 당신의 코드 한 줄도 바뀌지 않았습니다.

데이터가 늘어납니다. 아이템 100개일 때 즉각적이었던 것이 100,000개일 때는 느려집니다. 단순한 사용량 — 쌓여가는 콘텐츠, 가입하는 사용자 —만으로도 괜찮은 앱을 고통스러운 앱으로 바꾸기에 충분합니다. 시간 그 자체가 부하 (load)를 만들어냅니다.

이 네 가지의 공통점은 무엇일까요? 바로 첫날에는 그 무엇도 보이지 않는다는 점입니다. 데모에서도, 프로토타입에서도, 코드 자체에서도 보이지 않습니다. 당신은 완성된 객체를 출시했다고 생각하겠지만, 실제로 유통되는 것은 움직이는 환경 속에서 살아가는 무언가이며, 이는 기본적으로 쇠퇴합니다.

"흡수(absorbing)"가 기계적으로 의미하는 것

이 모든 상황에 맞서, 플랫폼이 "당신의 앱을 유지 관리한다"라고 말하는 것은 너무 모호합니다. 흥미로운 메커니즘은 단 한 문장으로 설명됩니다. 문제는 플랫폼 수준에서 단 한 번 해결되며, 모든 앱은 다음 컴파일 (compilation) 시점에 그 해결책을 상속받습니다.

새로운 개인정보 보호 요구 사항이 내려왔을 때, 수천 명의 제작자가 Apple의 문서를 읽는 것이 아닙니다. 단 하나의 팀이 단 한 번, 컴파일 엔진 (compilation engine)을 최신 상태로 업데이트합니다. OS가 API를 지원 중단 (deprecate)하면, 해당 API를 사용하던 컴포넌트 (component)는 동일한 엔진 내에서 단 한 번 다시 작성됩니다. 엔진은 영구적으로 최신 상태를 유지하므로, 시간 T에 컴파일된 앱은 해당 날짜까지 확인된 모든 수정 사항을 포함하게 됩니다. 무엇이 트리거하든 다음 빌드 (build)는 앱이 태어난 세상이 아니라, 오늘날의 세상 수준에 맞춰 나옵니다. 제작자는 이 과정 중 그 어떤 것도 보지 못했습니다. 규칙도, 마이그레이션 (migration)도 말이죠.

이 메커니즘의 정직한 비용은 영광 없는 지속적인 작업입니다. 모든 OS 릴리스 (release)에 맞춰 Swift와 Kotlin 빌드 체인 (build chain)을 최신으로 유지하고, 모든 스토어 규칙 변경 사항이 적용되기 전에 읽고, 지원 중단이 서비스 중단 (outage)으로 이어지기 전에 컴포넌트를 마이그레이션하는 것입니다. "확인된 모든 수정 사항" — 여기서 핵심적인 단어는 "확인된 (identified)"입니다. 이 감시는 마법 같은 보장이 아니라 하나의 업무입니다. 누군가가 다가올 것을 미리 본 것만을 잡아낼 수 있을 뿐입니다. 이는 데모로 보여주기 적합하지 않습니다. 작동할 때조차 눈에 띄지 않습니다. 그 결과물은 고장 나지 않는 기능과 거절당하지 않는 제출물일 뿐입니다. 누군가가 규칙이 적용되기 전에 미리 읽었기 때문입니다.

그것이 바로 내구성이 있는 플랫폼(durable platform)의 정의입니다. 타격을 전혀 받지 않는 플랫폼이 아니라, 그 위에서 구축하는 모든 이들을 대신하여, 그들에게 대응을 요구하지 않고 지속적으로 타격을 흡수하는 플랫폼 말입니다. 배경 소음(background noise)에 적용되는 원리는 거대한 충격에도 동일하게 적용됩니다. 지각 변동이 실제로 일어날 때 — 당시에는 모바일의 등장이 불가피해졌던 것처럼, 지금은 AI 에이전트(AI agents)가 그러하듯 — 질문은 동일하며 규모만 더 커질 뿐입니다. 이미 실행 중인 것들을 망가뜨리지 않으면서 어떻게 이를 흡수할 것인가 하는 점입니다.

AI는 첫날을 무료로 만들었지만 — 그 이후의 1,094일은 그렇지 않습니다

이러한 메커니즘이 오늘날 더 줄어들기는커녕 오히려 더 눈에 띄게 된 이유가 바로 이것입니다. 이제 앱 프로토타입(prototype)을 생성하는 데는 프롬프트(prompt) 하나면 충분합니다. 이는 진정으로 좋은 소식입니다. 더 많은 아이디어가 탄생하고, 더 많은 사람이 구축을 시작하기 때문입니다. 하지만 무엇이 압축되었고 무엇이 압축되지 않았는지 보십시오. 생성(Generation) 단계는 3개월에서 3분으로 줄어들었습니다. 하지만 그 뒤에 이어지는 1,094일은 단 한 시간도 줄어들지 않았습니다. 스토어 규칙은 여전히 변할 것이고, API는 동일한 속도로 지원이 중단(deprecated)될 것이며, 데이터는 똑같은 방식으로 쌓일 것입니다.

첫날은 무료가 되었습니다. 따라서 이제 앱을 구분 짓는 것은 1,095일째의 모습입니다. 프롬프트로부터 탄생한 앱도 다른 모든 앱과 마찬가지로, 변화하는 세상의 3년을 대신 흡수해 줄 누군가 — 혹은 무언가 — 가 필요합니다. 그리고 이는 우리가 현재의 AI 충격을 다루는 방식과도 같은 논리입니다. 처음부터 다시 시작하며 기존에 작동하던 것을 망가뜨리는 대신, 프레임(frame) 안으로 이를 흡수하는 것입니다. 즉, 에이전트에 의해 앱이 작동 가능하게 만들거나, 플랫폼 내부에서 AI가 구축하도록 하는 것과 같은 방식 말입니다.

내구성은 스스로를 알리지 않습니다 — 검증될 뿐입니다

플랫폼의 견고함이 가진 고마움을 모르는 특성은, 그것이 제대로 작동할 때는 보이지 않는다는 점입니다. 즉, 아무 일도 일어나지 않습니다. 1,095일째의 앱은 첫날의 앱과 똑같아 보입니다. 동일한 화면, 동일한 기능, 여전히 스토어에 존재합니다. 그 사이에 변한 모든 것들 — 규칙, API, 인증서(certificates), 부하(load) — 은 다른 어딘가에서, 그것이 직업인 사람들에 의해 흡수되었습니다.

데모(demo)는 첫날의 모습을 보여줍니다. 프로토타입(prototype)도 마찬가지입니다. 장수(Longevity)란 당신의 앱을 제외한 모든 것이 변했을 때 남겨지는 것입니다.