# 네이티브와 크로스 플랫폼 모바일 앱 중 어느 쪽이 맞습니까?

부다페스트의 소프트웨어 개발 회사인 Mesterséges Intelligencia Központ Kft.는 앱이 기기를 깊이 활용한다면 네이티브 앱이 필요하고, 두 플랫폼의 기능이 같다면 공통 코드베이스가 유지보수하기 더 간단하다고 봅니다.

> **핵심:** 결정은 유행이 아니라 기능에 달려 있습니다. 앱이 기기에 얼마나 깊이 접근해야 하는지, 성능이 얼마나 필요한지, 그리고 누가 수년간 유지보수할 것인지입니다. 앱 스토어 등록과 기기에 대한 깊은 접근이 중요하지 않다면 웹 애플리케이션(PWA)으로도 충분할 수 있습니다. 어느 길을 선택하시든 백엔드, 앱 스토어 규칙, 정기적인 운영체제 업데이트가 작업의 상당 부분을 차지합니다.

## 네이티브 앱, 크로스 플랫폼 앱, 웹 애플리케이션이란 무엇입니까?

모바일 앱은 세 가지 방식으로 만들 수 있습니다. 플랫폼별로 따로 각 플랫폼 고유의 도구로 만드는 방식, 두 플랫폼용으로 컴파일되는 하나의 공통 코드베이스로 만드는 방식, 그리고 웹 기술로 만들어 브라우저에서 실행하는 방식입니다. 세 방식 모두 작동하는 앱을 만들어 냅니다. 차이는 접근 범위, 유지보수, 그리고 앱이 누구의 규칙에 맞춰 업데이트되어야 하는지에 있습니다.

### 네이티브 앱

네이티브 앱에서는 iOS 버전과 Android 버전을 각 플랫폼 고유의 언어와 UI 도구로 따로 만듭니다. 오늘날 iOS에서는 일반적으로 Swift 언어와 SwiftUI를 씁니다. Apple에 따르면 SwiftUI는 선언형 구문을 사용하며, Swift를 기반으로 모든 Apple 플랫폼에서 사용자 인터페이스를 구축할 수 있게 합니다([Apple: SwiftUI](https://developer.apple.com/swiftui/)). Android에서는 Kotlin과 Jetpack Compose를 씁니다. Google은 Jetpack Compose를 네이티브 UI 구축을 위한 Android의 권장 최신 툴킷이라고 부르며([Android Developers: Jetpack Compose](https://developer.android.com/compose)), 새 Android 앱은 Kotlin으로 시작할 것을 권장합니다([Android Developers: Kotlin-first](https://developer.android.com/kotlin/first)). 네이티브 방식의 장점은 플랫폼의 모든 새 기능을 첫날부터 바로 쓸 수 있다는 점이고, 단점은 두 개의 코드베이스를 개발하고 유지보수해야 한다는 점입니다.

### 크로스 플랫폼 프레임워크

크로스 플랫폼 프레임워크를 쓰면 하나의 공통 코드베이스로 iOS 앱과 Android 앱을 만듭니다. 자주 쓰이는 네 가지 접근 방식은 다음과 같습니다.

- **Flutter:** Dart 언어를 쓰는 프레임워크입니다. 문서에 따르면 Flutter는 시스템의 UI 요소를 쓰는 대신 모든 UI 요소를 자체적으로 구현하며, 렌더링에는 Impeller라는 엔진을 사용합니다. 플랫폼 고유의 코드는 이른바 플랫폼 채널을 통해 호출할 수 있습니다([Flutter: Architectural overview](https://docs.flutter.dev/resources/architectural-overview)).
- **React Native:** React와 JavaScript를 기반으로 합니다. 프로젝트 자체의 설명에 따르면 JavaScript로 작성하지만 네이티브 코드로 렌더링되는데, 기본 구성 요소가 플랫폼의 네이티브 UI 구성 요소에 대응하기 때문입니다([React Native](https://reactnative.dev/)). 0.76 버전부터는 이른바 새 아키텍처가 기본값이며, 이 아키텍처는 비동기 브리지를 JavaScript Interface(JSI)로 대체합니다([React Native: New Architecture](https://reactnative.dev/architecture/landing-page)).
- **Kotlin Multiplatform:** JetBrains의 오픈 소스 기술로, Android, iOS, 데스크톱, 웹, 서버 환경 사이에서 코드를 공유할 수 있습니다. 네이티브 UI를 유지하면서 비즈니스 로직만 공유할 수도 있고, Compose Multiplatform으로 UI까지 공유할 수도 있습니다([Kotlin: Kotlin Multiplatform](https://kotlinlang.org/docs/multiplatform/kmp-overview.html)). Kotlin 문서에 따르면 Compose Multiplatform은 iOS에서도 안정 수준입니다([Kotlin: stability of supported platforms](https://kotlinlang.org/docs/multiplatform/supported-platforms.html), 2026년 10월 17일 확인).
- **.NET MAUI:** C#과 XAML을 사용하는 Microsoft의 프레임워크로, 하나의 공통 코드베이스로 Android, iOS, macOS, Windows용 앱을 개발할 수 있으며, Xamarin.Forms를 발전시킨 것입니다. iOS 및 macOS 앱을 빌드하려면 Mac이 필요합니다([Microsoft Learn: What is .NET MAUI?](https://learn.microsoft.com/en-us/dotnet/maui/what-is-maui)).

### 프로그레시브 웹 앱(PWA)

PWA는 브라우저에서 실행되는 웹 애플리케이션으로, 홈 화면에 설치할 수 있고 점진적 기능 향상(progressive enhancement)으로 더 안정적인 경험을 제공합니다. web.dev의 요약에 따르면 플랫폼 앱은 기능 면에서, 웹 앱은 도달 범위 면에서 가장 강합니다. 하나의 코드베이스로 누구에게나, 어떤 기기에서나 닿을 수 있습니다([web.dev: Progressive Web Apps](https://web.dev/learn/pwa/progressive-web-apps)). iOS와 iPadOS에서는 16.4 버전부터 홈 화면에 추가한 웹 앱도 푸시 알림 권한을 요청할 수 있습니다([WebKit: Web Push for Web Apps](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)). 중요한 제약이 하나 있습니다. App Store 가이드라인 4.2항에 따르면 앱은 다시 포장한 웹사이트 이상의 것을 제공해야 하므로, 웹사이트를 단순히 앱으로 감싸 앱 스토어에 올리는 것은 권하지 않습니다([Apple: App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)).

## 표로 보는 비교

| 기준 | 네이티브(Swift, Kotlin) | 크로스 플랫폼(Flutter, React Native, KMP, .NET MAUI) | PWA |
|---|---|---|---|
| 성능 | 플랫폼 도구로 직접 최적화 가능 | 계산량이 많은 부분은 네이티브 코드로 분리 가능 | 브라우저와 웹 기술이 결정 |
| 기기 접근 | 모든 플랫폼 기능, 첫날부터 | 프레임워크나 플러그인을 통해 가능, 새 기능은 나중에 지원되거나 추가 네이티브 코드가 필요 | 브라우저가 지원하는 웹 인터페이스로 제한 |
| 외관과 사용감 | 플랫폼 고유의 요소 그대로 | Flutter는 자체적으로 그린 요소, React Native는 네이티브 요소 | 웹사이트와 비슷하며 브라우저에 따라 다름 |
| 코드 공유 | 없음, 두 개의 별도 코드베이스 | 로직과 대개 UI까지 공유 | 모든 기기에 하나의 코드베이스 |
| 팀 | iOS와 Android 전문성이 각각 필요 | 한 팀이지만 네이티브 계층에 대한 지식도 필요 | 웹 개발 팀 |
| 유지보수 | 두 코드베이스가 정기적인 플랫폼 변경을 따라감 | 하나의 코드베이스, 여기에 프레임워크 자체 업데이트 | 앱 스토어 출시 없음, 브라우저 변화를 따라가야 함 |
| 앱 크기 | 시스템 고유의 라이브러리를 활용 | 프레임워크 엔진도 앱에 포함됨 | 설치 패키지 없음, 브라우저가 캐시 |
| 앱 스토어 등록 | 예 | 예 | 필요 없음, 앱 스토어용으로 감싸면 4.2항의 제약이 적용 |

Flutter 문서도 Flutter 앱 패키지는 독립적이어서 앱 실행에 필요한 모든 코드와 리소스를 담고 있으므로 크기가 고려 사항이 될 수 있다고 분명히 밝힙니다([Flutter: Measuring your app's size](https://docs.flutter.dev/perf/app-size)). 실무에서 이 차이가 결정적인 경우는 드물지만, 대상 사용자가 오래된 기기나 약한 연결로 앱을 사용한다면 알아 두는 것이 좋습니다.

## 언제 어느 쪽이 맞습니까?

### 네이티브가 맞는 경우

- 앱이 기기를 깊이 활용할 때: 카메라, 센서, Bluetooth, 백그라운드 작업
- 높은 성능이 필요할 때: 예를 들어 실시간 이미지 또는 오디오 처리, 복잡한 애니메이션
- 플랫폼의 최신 기능을 즉시 활용해야 할 때
- 한 플랫폼용 앱만 필요하거나, 두 버전이 크게 다를 때

### 크로스 플랫폼이 맞는 경우

- 두 플랫폼의 기능이 같고, 변경 사항이 동시에 반영되는 것이 중요할 때
- 앱이 주로 양식, 목록, 데이터 표시, 알림으로 이루어질 때(대부분의 업무용 앱이 그렇습니다)
- 한 팀이 앱을 장기간 유지보수할 때
- 회사가 이미 프레임워크의 언어를 쓰고 있을 때: 예를 들어 웹의 React 경험은 React Native로, .NET 경험은 .NET MAUI로 이어집니다

### PWA 또는 웹 애플리케이션이 맞는 경우

- 사용자가 앱 스토어에서 앱을 찾지 않고, 링크나 웹사이트를 통해 들어올 때
- 기기에 깊이 접근할 필요가 없을 때
- 앱이 데스크톱과 휴대전화에서 똑같이 작동해야 할 때
- 앱 스토어 심사 없는 빠른 업데이트가 플랫폼 기능보다 중요할 때

여기서도 경계가 뚜렷하지는 않습니다. 예를 들어 Kotlin Multiplatform으로는 비즈니스 로직을 공유하면서 UI는 네이티브로 유지할 수 있고, Flutter와 React Native에서도 중요한 부분을 네이티브 코드로 작성할 수 있습니다. 저희 홈페이지의 게임은 웹 애플리케이션으로 작동합니다. 설치 없이 브라우저에서 실행되고, 데스크톱과 휴대전화에서 똑같이 작동합니다. 웹 방식에 관해서는 [웹사이트 제작 및 웹 애플리케이션 개발](https://www.mestersegesintelligenciakozpont.hu/ko/services/website-development) 페이지에서 다룹니다.

## 백엔드와 관리자 화면

모바일 앱이 단독으로 존재하는 경우는 드뭅니다. 사용자 계정, 공유 데이터, 알림 중 하나라도 생기면 그 뒤에 서버가 필요합니다. 계정, 데이터, 권한이 서버에 있고, 알림도 서버에서 보냅니다. 푸시 알림은 일반적으로 백엔드가 전용 서비스를 통해 보냅니다. 예를 들어 Firebase Cloud Messaging은 크로스 플랫폼 메시징 솔루션으로, 신뢰할 수 있는 서버 환경이 메시지를 만들어 Apple, Android, 웹 앱에 보냅니다([Firebase: Cloud Messaging](https://firebase.google.com/docs/cloud-messaging)).

관리자 화면은 백엔드의 제어판입니다. 브라우저에서 콘텐츠를 편집하고 사용자와 설정을 관리할 수 있어, 일상적인 변경에 개발자가 필요하지 않습니다. 기존 회사 시스템, 예를 들어 고객 관리 시스템, 재고 관리 시스템, 청구서 발행 프로그램도 여기에 연결하여, 앱이 회사의 다른 부분과 같은 데이터로 작동하도록 합니다. 아직 그런 시스템이 없다면 [맞춤 소프트웨어](https://www.mestersegesintelligenciakozpont.hu/ko/services/custom-software-development)로 그것도 구축합니다. 네이티브냐 크로스 플랫폼이냐의 결정은 백엔드에 영향을 주지 않습니다. 같은 서버가 네이티브 앱과 Flutter로 만든 앱을 모두 지원할 수 있습니다.

## 앱 스토어 출시: 2026년 10월에는 무엇에 주의해야 합니까?

앱 스토어 규칙은 자주 바뀌므로, 아래 내용에는 날짜를 밝혀 둡니다(2026년 10월 17일 확인).

### App Store(Apple)

- **심사 가이드라인:** App Store Review Guidelines는 2026년 10월 16일에 마지막으로 업데이트되었습니다. 2.1항에 따르면 심사 준비가 끝난 완전한 버전을 제출해야 하며, 앱에 로그인이 있다면 데모 계정을 제공해야 하고, 심사 중에도 백엔드가 작동해야 합니다. 5.1.1항에 따르면 모든 앱은 개인정보 처리방침에 링크해야 하며, 앱에서 계정을 만들 수 있다면 계정 삭제도 앱 안에서 제공해야 합니다([Apple: App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)).
- **개인정보 보호 세부사항:** App Store Connect에서 앱의 데이터 처리 관행을 신고해야 하며, 여기에는 내장된 외부 구성 요소(예: 분석 SDK)의 관행도 포함됩니다. 이는 새 앱과 업데이트를 제출할 때 모두 필요합니다([Apple: App privacy details](https://developer.apple.com/app-store/app-privacy-details/)).
- **개발 도구 요구사항:** 2026년 4월 28일부터 App Store Connect에 업로드하는 앱은 Xcode 26 이상 버전과 iOS 26 SDK로 빌드해야 하며, 2026년 9월 9일부터 iOS 및 iPadOS 앱은 iOS 13 이상을 대상으로 해야 합니다([Apple: Upcoming requirements](https://developer.apple.com/news/upcoming-requirements/)).
- **회사 계정:** 조직으로 등록하려면 회사가 법인이어야 하고 D-U-N-S 번호를 보유해야 하며, 등록하는 사람은 회사를 대신해 법적 의무를 질 권한이 있어야 합니다([Apple: Enrollment](https://developer.apple.com/programs/enroll/)).
- **EU 내 거래자 지위:** Apple은 개발자에게 EU 법률상 거래자에 해당하는지 신고하도록 요청하며, EU에서는 거래자의 연락처 정보가 앱의 앱 스토어 페이지에 표시됩니다([Apple: Digital Services Act trader requirements](https://developer.apple.com/help/app-store-connect/manage-compliance-information/manage-european-union-digital-services-act-trader-requirements/)).

### Google Play

- **대상 API 수준:** 2026년 8월 31일부터 휴대전화용 새 앱과 업데이트는 Android 16(API 수준 36) 이상을 대상으로 해야 합니다. 기존 앱은 더 새로운 Android 버전을 실행하는 기기의 신규 사용자에게 계속 제공되려면 Android 15(API 수준 35) 이상을 대상으로 해야 합니다. Play Console에서 연장을 요청한 경우 기한은 2026년 11월 1일입니다([Android Developers: Target API level](https://developer.android.com/google/play/requirements/target-sdk)).
- **개인 계정의 테스트:** 2023년 11월 13일 이후에 만든 개인 개발자 계정은 정식 출시 전에, 최소 14일 동안 계속 참여한 테스터 최소 12명과 함께 비공개 테스트를 진행해야 합니다([Play Console Help: testing requirements](https://support.google.com/googleplay/android-developer/answer/14151465)).
- **조직 계정:** D-U-N-S 번호 없이는 조직 개발자 계정을 만들 수 없습니다([Play Console Help: creating an account](https://support.google.com/googleplay/android-developer/answer/13628312)).
- **데이터 보안 양식:** Google Play에 게시되는 모든 앱에 대해 작성해야 하며, 앱이 사용자 데이터를 수집하지 않더라도 마찬가지입니다([Play Console Help: Data safety](https://support.google.com/googleplay/android-developer/answer/10787469)).
- **계정 삭제:** 앱에서 계정을 만들 수 있다면, 계정과 관련 데이터의 삭제를 앱 안에서도, 웹 링크를 통해서도 요청할 수 있게 해야 합니다([Play Console Help: account deletion requirements](https://support.google.com/googleplay/android-developer/answer/13327111)).

이 규칙은 기술과 무관하게 적용됩니다. Flutter나 React Native로 만든 앱도 네이티브 앱과 같은 대상 API 및 SDK 요구사항을 충족해야 하며, 프레임워크 업데이트가 이를 따라가야 합니다. 개발자 계정은 의뢰한 회사의 소유로 하실 것을 권장합니다. 그러면 앱이 귀사의 이름으로 표시되고, 앱 스토어 등록 정보도 귀사의 것으로 남습니다.

## 접근성

두 플랫폼 모두 스크린 리더가 내장되어 있으며(iOS의 VoiceOver, Android의 TalkBack), 앱이 이러한 보조 기술과 함께 작동할 수 있도록 인터페이스를 제공합니다([React Native: Accessibility](https://reactnative.dev/docs/accessibility)). 예를 들어 Flutter 문서는 스크린 리더가 모든 컨트롤을 이해할 수 있게 설명하고, 텍스트와 배경의 명암 대비가 최소 4.5:1이며, 탭할 수 있는 모든 요소가 최소 48×48픽셀이 되도록 권장합니다([Flutter: Accessibility](https://docs.flutter.dev/ui/accessibility)). Android 문서는 문제를 찾기 위해 Material Design 가이드라인, Accessibility Scanner 도구, 자동 검사를 권장합니다([Android Developers: Accessibility](https://developer.android.com/guide/topics/ui/accessibility)).

이는 단지 좋은 관행에 그치지 않습니다. 지침 (EU) 2019/882에 따라 회원국은 2025년 6월 28일부터 소비자에게 제공되는 전자상거래 서비스(모바일 앱을 통해 제공되는 서비스 포함)에 접근성 요구사항을 적용해야 하며(헝가리 규정은 이 지침의 국내 이행에 기반합니다), 서비스를 제공하는 마이크로 기업은 적용을 면제해야 합니다([EUR-Lex: 지침 (EU) 2019/882](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882)). 온라인 쇼핑몰에 관한 자세한 내용은 [온라인 쇼핑몰: 임대형 솔루션과 맞춤형 개발 중 어느 쪽이 맞습니까?](https://www.mestersegesintelligenciakozpont.hu/ko/knowledge-base/hosted-webshop-vs-custom-development) 글에서 다룹니다.

## 인공지능: 기기와 클라우드 중 어디에서 실행합니까?

모바일 앱에서 AI 기능은 두 곳에서 실행될 수 있습니다. 휴대전화 자체에서, 또는 백엔드를 거쳐 클라우드에서 실행되는 대규모 언어 모델에서입니다.

- **기기에서(Apple):** Apple의 Foundation Models 프레임워크는 iOS 26부터 Apple Intelligence를 위해 설계된, 기기와 Private Cloud Compute에서 실행되는 모델에 접근할 수 있게 합니다. 텍스트 생성, 구조화된 출력, 자체 도구 호출에도 쓸 수 있지만, Apple Intelligence를 지원하는 기기에서만 가능합니다([Apple: Foundation Models](https://developer.apple.com/documentation/foundationmodels)).
- **기기에서(Android):** Gemini Nano는 Android의 AICore 시스템 서비스에서 실행되며, ML Kit GenAI 인터페이스를 통해 요약, 교정, 다시 쓰기, 이미지 설명 등에 이용할 수 있습니다. Google에 따르면 네트워크 연결 없이도 작동하고 민감한 데이터가 기기에 남지만, 모델은 토큰 한도와 기기 하드웨어의 제약을 받습니다([Android Developers: Gemini Nano](https://developer.android.com/ai/gemini-nano)).
- **클라우드에서:** OpenAI(ChatGPT), Anthropic(Claude), Google(Gemini)의 대규모 언어 모델은 회사 자체 자료를 바탕으로 답변하는 어시스턴트, 문서 및 이미지 처리, 요약 같은 더 복잡한 작업에 쓰입니다. AI 서비스의 접근 키는 휴대전화가 아니라 백엔드에 보관합니다. 그래서 앱에서 키를 빼낼 수 없고, 사용량은 서버에서 통제할 수 있습니다.

기기에서 실행되는 모델은 데이터 보호와 오프라인 작동 면에서 매력적이지만, 모든 사용자의 기기에서 이용할 수 있는 것은 아니므로 보통 클라우드 대체 수단과 함께 설계하는 것이 좋습니다. 모델 연결에 관해서는 [AI 통합](https://www.mestersegesintelligenciakozpont.hu/ko/services/ai-integration) 페이지에서 다룹니다.

## 유지보수는 무엇에 따라 달라집니까?

모바일 앱은 인도 후에도 완성된 것이 아닙니다. 앱을 둘러싼 환경이 계속 바뀌기 때문입니다. 유지보수 작업은 주로 다음 요소로 정해집니다.

- **운영체제와 앱 스토어의 요구사항:** Apple은 업로드에 더 새로운 Xcode와 SDK 버전을, Google Play는 더 높은 대상 API 수준을 요구합니다. 위의 날짜들이 보여 주듯 이 기준은 정기적으로 높아집니다.
- **앱 스토어 가이드라인의 변경:** 새로운 개인정보 보호 신고, 계정 삭제 또는 테스트 규칙.
- **프레임워크 업데이트:** 크로스 플랫폼 앱에서는 Flutter, React Native 또는 .NET MAUI의 주요 버전 변경이 자체 코드와 사용하는 플러그인에서도 작업을 뜻할 수 있습니다.
- **외부 구성 요소:** 결제, 지도, 분석 SDK도 각자의 업데이트 요구사항이 있습니다.
- **백엔드와 연동:** 연결된 회사 시스템과 AI 서비스의 인터페이스 변경.
- **코드베이스의 수:** 네이티브 앱 두 개는 두 곳에서 수정해야 합니다.

## 흔한 실수

- 기술을 앱의 기능이 아니라 팀의 습관으로 결정합니다.
- 화면만 고려하고 백엔드와 관리자 화면은 계산에 넣지 않습니다.
- 웹사이트를 단순히 앱으로 감쌌다가 앱 스토어에서 거절당합니다.
- 개발자 계정이 개발 회사 명의로 되어 있어, 나중에 앱 스토어 등록 정보를 옮길 수 없습니다.
- 계정 삭제, 개인정보 보호 세부사항 또는 데모 계정을 제출 당일에야 준비합니다.
- 인도 후 업데이트를 책임지는 사람이 없어, 규칙이 바뀐 뒤 앱이 신규 사용자에게 보이지 않게 됩니다.

## 자주 묻는 질문

### 네이티브와 Flutter/React Native 중 어느 쪽이 맞습니까?

앱이 기기를 깊이 활용하거나(카메라, 센서, 백그라운드 프로세스) 높은 성능이 필요하다면 네이티브 개발이 더 확실한 길입니다. 두 플랫폼의 기능이 같다면 Flutter나 React Native로 만든, 공통 코드베이스를 쓰는 앱이 유지보수가 더 간단합니다. Kotlin Multiplatform으로는 중간 방식도 가능합니다. 비즈니스 로직은 공유하고 UI는 네이티브로 만드는 방식입니다. 첫 상담에서 구체적인 기능을 바탕으로 제안해 드립니다.

### 웹 애플리케이션(PWA)으로 충분한 경우는 언제입니까?

사용자가 링크나 웹사이트를 통해 들어오고, 기기에 깊이 접근할 필요가 없으며, 데스크톱과 휴대전화에서 똑같이 작동하는 것이 중요할 때입니다. 홈 화면에 설치할 수 있고 iOS에서도 푸시 알림을 보낼 수 있지만, 앱 스토어에는 등록되지 않으며, 쓸 수 있는 기기 기능의 범위는 브라우저에 달려 있습니다.

### 백엔드가 필요합니까?

거의 항상 필요합니다. 앱에 사용자 계정, 공유 데이터, 알림 중 하나라도 있으면 그 뒤에 서버가 있어야 합니다. 예외는 기기에만 데이터를 저장하는 앱입니다. 백엔드와 관리자 화면도 구축하고, 기존 회사 시스템에 연결합니다.

### 앱 스토어에는 누가 앱을 등록합니까?

출시는 저희가 처리합니다. 앱 스토어 등록 정보 자료와 개인정보 보호 신고 내용을 준비하고, 앱을 제출하며, 심사 과정을 끝까지 지원합니다. 개발자 계정은 귀사 소유로 하실 것을 권장합니다. 두 앱 스토어 모두 조직 계정에 D-U-N-S 번호를 요구하므로, 미리 발급받아 두는 것이 좋습니다.

### 유지보수 비용은 무엇에 따라 달라집니까?

유지보수해야 할 코드베이스의 수, 운영체제와 앱 스토어 요구사항이 얼마나 자주 바뀌는지, 앱이 얼마나 많은 외부 구성 요소와 연동을 사용하는지, 그리고 추가 개발이 얼마나 예상되는지에 따라 달라집니다. 개발 비용은 기능 규모를 바탕으로 산정하며, 그 방법은 [비용 산정](https://www.mestersegesintelligenciakozpont.hu/ko/pricing) 페이지에서 설명합니다.

## 저희는 어떻게 도와드립니까?

저희는 iOS 및 Android 앱을 개발합니다. 앱 뒤의 백엔드와 관리자 화면을 구축하고, 인공지능을 연결하며, 앱 스토어 출시까지 맡아 진행합니다. 네이티브냐 크로스 플랫폼이냐의 결정은 기능을 바탕으로 함께 내립니다. 서비스에 관한 자세한 내용은 [모바일 앱 개발](https://www.mestersegesintelligenciakozpont.hu/ko/services/mobile-app-development) 페이지에서 보실 수 있습니다.

개발의 기능 규모를 COSMIC 기능점수(ISO/IEC 19761)로 측정하고, 이를 바탕으로 견적과 일정을 작성합니다. 첫 상담은 무료이며, 요청하시면 비밀유지계약(NDA)을 체결하고, 인도 후에는 운영과 유지보수도 맡습니다. 소스 코드와 이용 권리는 계약으로 정합니다. 아이디어를 몇 문장으로 적어 [저희에게 연락해 주시기 바랍니다](https://www.mestersegesintelligenciakozpont.hu/ko/contact).

## 출처

- [Apple: SwiftUI](https://developer.apple.com/swiftui/)
- [Android Developers: Jetpack Compose](https://developer.android.com/compose)
- [Android Developers: Android's Kotlin-first approach](https://developer.android.com/kotlin/first)
- [Flutter: Architectural overview](https://docs.flutter.dev/resources/architectural-overview)
- [Flutter: Measuring your app's size](https://docs.flutter.dev/perf/app-size)
- [Flutter: Accessibility](https://docs.flutter.dev/ui/accessibility)
- [React Native](https://reactnative.dev/)
- [React Native: About the New Architecture](https://reactnative.dev/architecture/landing-page)
- [React Native: Accessibility](https://reactnative.dev/docs/accessibility)
- [Kotlin: Kotlin Multiplatform overview](https://kotlinlang.org/docs/multiplatform/kmp-overview.html)
- [Kotlin: Stability of supported platforms](https://kotlinlang.org/docs/multiplatform/supported-platforms.html)
- [Microsoft Learn: What is .NET MAUI?](https://learn.microsoft.com/en-us/dotnet/maui/what-is-maui)
- [web.dev: Progressive Web Apps](https://web.dev/learn/pwa/progressive-web-apps)
- [WebKit: Web Push for Web Apps on iOS and iPadOS](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/)
- [Apple: App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)
- [Apple: App privacy details](https://developer.apple.com/app-store/app-privacy-details/)
- [Apple: Upcoming requirements](https://developer.apple.com/news/upcoming-requirements/)
- [Apple: Enrollment](https://developer.apple.com/programs/enroll/)
- [Apple: Digital Services Act trader requirements](https://developer.apple.com/help/app-store-connect/manage-compliance-information/manage-european-union-digital-services-act-trader-requirements/)
- [Android Developers: Target API level requirements for Google Play](https://developer.android.com/google/play/requirements/target-sdk)
- [Play Console Help: App testing requirements for new personal developer accounts](https://support.google.com/googleplay/android-developer/answer/14151465)
- [Play Console Help: Required information to create a developer account](https://support.google.com/googleplay/android-developer/answer/13628312)
- [Play Console Help: Data safety section](https://support.google.com/googleplay/android-developer/answer/10787469)
- [Play Console Help: Account deletion requirements](https://support.google.com/googleplay/android-developer/answer/13327111)
- [Android Developers: Accessibility](https://developer.android.com/guide/topics/ui/accessibility)
- [EUR-Lex: 지침 (EU) 2019/882](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882)
- [Apple: Foundation Models](https://developer.apple.com/documentation/foundationmodels)
- [Android Developers: Gemini Nano](https://developer.android.com/ai/gemini-nano)
- [Firebase: Cloud Messaging](https://firebase.google.com/docs/cloud-messaging)