도플갱어 딜레마: 왜 당신의 모바일 앱은 겉은 비슷하지만 행동은 낯선 사람처럼 보이는가

Source: Dev.to

대부분의 모바일 팀은 하나의 앱만 배포하지 않는다.
그들은 서서히 서로 다른 두 앱을 배포한다.

• Android에서 검증 규칙이 변경된다.
• iOS는 두 스프린트 뒤에야 이를 반영한다.
• 몇 주 후, 사용자들은 “랜덤 오류” 를 보고하지만 실제로는 아무것도 고장 나지 않았다.

플랫폼이 단순히 다른 결정을 내렸을 뿐이다.

나는 이를 도플갱어 딜레마라고 부른다: 스토어에서는 동일하게 보이지만, 실제 운영에서는 전혀 다른 행동을 보이는 앱들.

모바일 엔지니어링에서 가장 어려운 문제는 성능이나 UI가 아니다.
독립적으로 진화하는 코드베이스 간에 동작을 일관되게 유지하는 것이다.
기능 동등성은 테스트 문제라기보다 아키텍처 문제이다.

1. 앱 서랍에서의 정체성 위기

오늘날 모바일 생태계에서 우리는 조용히 도플갱어 딜레마에 시달리고 있습니다.

• 생물학: 도플갱어는 서로 관련이 없지만 단지 닮은 사람들입니다.
• 모바일 엔지니어링: 이는 iOS와 Android 애플리케이션 간의 파편화된 관계를 의미합니다.

사용자는 기기에 관계없이 매끄럽고 일관된 경험을 기대합니다. 그러나 화면 뒤에서 이 앱들은 종종 완전히 다른 존재이며, 별개의 스택, 아키텍처 패턴, 독립적으로 진화하는 코드베이스 위에 구축됩니다.

실제로 이는 모든 모바일 팀에게 익숙한 문제로 나타납니다:

1. 각 기능마다 두 개의 풀 리퀘스트가 필요합니다.
2. 몇 주 뒤에 두 개의 서로 다른 버그 티켓이 생성됩니다.

코드베이스가 통합된 시스템이 아니라 관련 없는 쌍둥이처럼 행동하면, 우리는 단순히 앱을 만드는 것이 아니라 기술 부채를 복제하고 있는 것입니다.

2. 숨겨진 괴물: 동기화 비용

제품 계획은 보통 개발 비용이 플랫폼 수에 따라 선형적으로 증가한다고 가정합니다. 실제로는 숨겨진 배수가 존재합니다: 동기화 비용.

예시

동기화 비용은 기능 복잡도보다 빠르게 증가합니다. 새로운 기능이 추가될 때마다 다음과 같은 문제가 발생합니다:

• 중복된 검증 로직
• 일치하지 않는 엣지 케이스
• 일관되지 않은 릴리스 시점
• 테스트 조합이 늘어남

Robert C. Martin이 지적했듯이, 중복은 소프트웨어 오류를 악화시킵니다. 모바일에서는 이것이 플랫폼 전반에 걸쳐 악화됩니다.

3. 크로스‑플랫폼 타협

중복을 방지하기 위해 업계는 크로스‑플랫폼 프레임워크를 받아들였다. 이들은 도달 범위를 최적화하지만, 플랫폼 공급업체는 진화 속도를 최적화한다.

• Apple과 Google은 지속적으로 새로운 인터랙션 모델과 하드웨어 통합을 도입한다.
• 추상화 계층은 불가피하게 플랫폼 혁신에 뒤처진다.

그 결과는 앱이 깨지는 것이 아니라 미묘하게 잘못된 앱이다. 사용자는 이를 버그라기보다 마찰로 느낀다. 모든 것이 공유되어서는 안 된다.

4. 도플갱어에서 공생 사촌으로

지속 가능한 전략은 플랫폼을 공생 사촌으로 대우하는 것이며, 동일한 쌍둥이가 아니다.

현대 네이티브 언어 — Swift와 Kotlin — 은 철학적으로 수렴하고 있다:

정렬은 문법이 아니라 아키텍처적 사고이다:

• 불변성
• 명시적 상태
• 결정론적 동시성

이를 통해 공유된 의도는 유지되지만 UI 레이어는 공유되지 않는다.

5. 뇌를 공유하고, 얼굴을 공유하지 않기: Kotlin Multiplatform

Kotlin Multiplatform (KMP)은 동작을 공유하고 — 프레젠테이션은 네이티브로 유지하는 수술적 솔루션을 제공합니다.

이전 (중복된 도메인 규칙)

// shared/commonMain
class EmailValidator {
    fun isValid(email: String): Boolean {
        return email.contains("@") && email.length > 5
    }
}

이후 (네이티브 사용)

let validator = EmailValidator()
let valid = validator.isValid(email: input)

KMP는 공유 로직을 네이티브 아티팩트로 컴파일합니다:

• Android용 JVM 모듈
• iOS용 네이티브 프레임워크

런타임 브리지도 없고 UI 추상화도 없으며, 하나의 행동 진실 원본만 존재합니다. 채택은 검증, 네트워킹, 비즈니스 규칙 등으로 시작해 점진적으로 확장할 수 있습니다.

6. 선언형 UI: 아키텍처 정렬

SwiftUI와 Jetpack Compose는 모바일 아키텍처를 변화시켰습니다. UI는 더 이상 변경 가능한 객체 트리가 아니라 상태의 함수입니다. 이는 이전 MVC/MVP 계층이 만들던 임피던스 불일치를 제거합니다.

• Shared layer → 상태를 생성함 (KMP가 동작을 소유)
• Native UI → 상태를 표현함 (SwiftUI / Compose)

Result: 일관성은 있지만 균일성은 없음.

7. Observed Industry Pattern

Large mobile organizations increasingly converge on the same strategy:

shared domain logic + native UI

Not because of tooling preference, but because behavioral consistency matters more than code reuse.

The winning architecture is not “write‑once‑run‑everywhere”; it is decide‑once‑render‑natively.

8. 실용적인 관찰

다양한 모바일 프로젝트에서 기능 동일성 문제는 열악한 엔지니어링 때문이 아니라 도메인 규칙이 플랫폼마다 독립적으로 진화하기 때문에 발생한다는 것을 보았다.

검증 로직이나 비즈니스 로직이 별도의 코드베이스에 존재할 때, 작은 차이점들이 조용히 누적된다. 이러한 차이점은 통합 테스트나 릴리스 후 분석 단계에서 드러나며, 각 구현이 독립적으로는 “올바른” 상태임에도 불구하고 동작이 일관되지 않게 보인다.

공유 도메인 검증 레이어의 영향

9. 경계 너머

The Doppelgänger Dilemma는 도구 문제가 아니라 아키텍처 선택입니다. 현대 모바일 아키텍처는 더 이상 플랫폼 독립성을 최적화하지 않으며—행동 일관성을 최적화합니다.

brain (도메인 로직)를 공유하고 face (UI)를 네이티브로 유지함으로써, 팀은 숨겨진 동기화 비용을 없애고, 중복된 부채를 줄이며, iOS와 Android 전반에 걸쳐 진정으로 통합된 사용자 경험을 제공할 수 있습니다.

모바일 아키텍처에서 행동 일관성 – 파트 1

Kotlin Multiplatform은 팀이 의사결정을 통합하면서도 네이티브 경험을 유지하도록 합니다.

목표는 코드를 적게 쓰는 것이 아닙니다.
시스템에서 의견 충돌을 없애는 것입니다.

작성자 Pavan Kumar Appannagari — 소프트웨어 엔지니어 — 모바일 시스템 & 적용 AI

---

이번 시리즈에서 다룰 내용

• 왜 기능 동등성 버그는 QA 문제가 아니라 아키텍처 문제인가
• KMP를 사용해 iOS와 Android 간 검증 로직 공유하기
• Swift Concurrency vs Kotlin Coroutines: 사고 모델 매핑