[MOBILE-002][입문] 네이티브·크로스플랫폼 선택 기준 세우기
페이지 정보
본문
[이번 수업]
모바일 앱을 네이티브로 만들지 크로스플랫폼으로 만들지 요구사항에 따라 비교합니다. 감으로 도구를 고르지 않고 기준과 가중치를 적어 후보를 만든 뒤 프로토타입으로 검증하는 흐름을 배웁니다.
[선수지식]
MOBILE-001의 모바일 앱·운영체제·스토어 기본 흐름과 Python 딕셔너리·반복문을 알면 됩니다. 실제 앱 SDK를 설치하지 않고 선택 과정만 연습합니다.
[학습목표]
1. 네이티브와 크로스플랫폼의 코드·도구 경계를 구분한다.
2. 플랫폼 API·공유 코드·UX·팀 역량을 선택 기준으로 만든다.
3. 숫자 점수를 정답이 아닌 검증할 가설로 사용한다.
[핵심개념]
네이티브 앱은 각 운영체제의 공식 언어와 UI 도구를 중심으로 구현합니다. iOS의 SwiftUI, Android의 Jetpack Compose가 예입니다. 플랫폼 기능과 새 API를 직접 사용하고 각 플랫폼의 UI 관례를 세밀하게 맞추기 좋습니다.
크로스플랫폼은 한 프레임워크에서 여러 플랫폼이 공유하는 코드를 늘리는 접근입니다. Flutter나 React Native 같은 도구는 공통 UI와 로직을 만들 수 있지만 플랫폼 차이가 사라지는 것은 아닙니다. 카메라·알림·결제 같은 기능은 플러그인이나 플랫폼별 코드가 필요할 수 있고, 스토어 빌드·권한·접근성·실기기 테스트도 각 운영체제에서 해야 합니다.
중간 선택도 가능합니다. 화면은 네이티브로 두고 도메인 규칙·네트워크·데이터 처리만 공유하거나, 공통 화면 중 일부만 공유할 수 있습니다.
먼저 절대 포기할 수 없는 조건을 적고 후보별 작은 프로토타입으로 가장 위험한 기능을 시험합니다. 숫자 표는 대화를 돕지만 실제 측정을 대신하지 않습니다.
[따라하기]
mobile_choice.py에 다음을 저장하세요. 숫자는 가상의 프로젝트 가정이며 도구의 보편적 순위가 아닙니다.
weights = {
"device_api_depth": 5,
"shared_delivery": 4,
"platform_specific_ux": 4,
"one_team_operation": 3,
}
ratings = {
"native": {
"device_api_depth": 5,
"shared_delivery": 1,
"platform_specific_ux": 5,
"one_team_operation": 2,
},
"cross_platform": {
"device_api_depth": 3,
"shared_delivery": 5,
"platform_specific_ux": 3,
"one_team_operation": 5,
},
}
def score(option):
return sum(
weights[criterion] * rating
for criterion, rating in ratings[option].items()
)
scores = {option: score(option) for option in ratings}
for option, value in scores.items():
print(option, value)
print("leading hypothesis:", max(scores, key=scores.get))
Windows는 py mobile_choice.py, macOS·Linux는 python3 mobile_choice.py로 실행합니다. 예상 결과는 native 55, cross_platform 62, leading hypothesis는 cross_platform입니다. 이는 공유 출시와 한 팀 운영을 높게 둔 가상 결과일 뿐 최종 선택이 아닙니다. device_api_depth가 실제로 어느 후보에서 충족되는지 카메라·백그라운드 작업 같은 어려운 기능을 각 플랫폼 실기기에서 먼저 시험해야 합니다.
[흔한 실수]
첫째, 한 번 작성하면 플랫폼별 작업이 전혀 없다고 생각합니다. 둘째, 첫 출시 속도만 보고 수년간의 업데이트 비용을 빼놓습니다. 셋째, 평균 화면만 만들어 카메라·알림·결제 같은 고위험 기능을 늦게 시험합니다. 넷째, 에뮬레이터만 보고 실기기 성능과 접근성을 판단합니다.
[보안 주의]
모바일 앱 바이너리와 번들은 사용자가 분석할 수 있으므로 API 비밀키와 관리자 자격증명을 넣지 마세요. 인증과 권한 판단은 서버에서도 수행하고 토큰은 플랫폼의 안전한 저장소를 사용합니다. 카메라·위치·연락처 권한은 기능에 필요한 시점에 최소 범위로 요청합니다. 크로스플랫폼 플러그인도 공급망 의존성이므로 출처·권한·업데이트·취약점을 검토하세요.
[직접 해볼 과제]
one_team_operation 가중치를 1로 바꿔 결과를 비교하세요. 이어서 오프라인 지원과 접근성 두 기준을 추가하고, 후보 두 개로 2일짜리 프로토타입을 만든다면 측정할 항목을 각각 세 개 적으세요.
[확인문제]
1. 크로스플랫폼에서도 플랫폼별 코드와 테스트가 필요한 이유는 무엇인가요?
2. 점수표의 62점이 최종 결정을 의미하지 않는 이유는 무엇인가요?
3. 네이티브 UI와 공유 로직을 결합하는 중간 선택은 언제 유용한가요?
[다음 학습]
순환 커리큘럼의 다음 글은 IOT-002 마이크로컨트롤러와 싱글보드 컴퓨터입니다. 모바일 트랙에서는 MOBILE-003 화면·컴포넌트·내비게이션으로 이어집니다.
[공식 참고 자료]
Apple SwiftUI
https://developer.apple.com/documentation/swiftui/
Android Jetpack Compose
https://developer.android.com/compose
Flutter 아키텍처
https://docs.flutter.dev/resources/architectural-overview
React Native 플랫폼별 코드
https://reactnative.dev/docs/platform-specific-code
모바일 앱을 네이티브로 만들지 크로스플랫폼으로 만들지 요구사항에 따라 비교합니다. 감으로 도구를 고르지 않고 기준과 가중치를 적어 후보를 만든 뒤 프로토타입으로 검증하는 흐름을 배웁니다.
[선수지식]
MOBILE-001의 모바일 앱·운영체제·스토어 기본 흐름과 Python 딕셔너리·반복문을 알면 됩니다. 실제 앱 SDK를 설치하지 않고 선택 과정만 연습합니다.
[학습목표]
1. 네이티브와 크로스플랫폼의 코드·도구 경계를 구분한다.
2. 플랫폼 API·공유 코드·UX·팀 역량을 선택 기준으로 만든다.
3. 숫자 점수를 정답이 아닌 검증할 가설로 사용한다.
[핵심개념]
네이티브 앱은 각 운영체제의 공식 언어와 UI 도구를 중심으로 구현합니다. iOS의 SwiftUI, Android의 Jetpack Compose가 예입니다. 플랫폼 기능과 새 API를 직접 사용하고 각 플랫폼의 UI 관례를 세밀하게 맞추기 좋습니다.
크로스플랫폼은 한 프레임워크에서 여러 플랫폼이 공유하는 코드를 늘리는 접근입니다. Flutter나 React Native 같은 도구는 공통 UI와 로직을 만들 수 있지만 플랫폼 차이가 사라지는 것은 아닙니다. 카메라·알림·결제 같은 기능은 플러그인이나 플랫폼별 코드가 필요할 수 있고, 스토어 빌드·권한·접근성·실기기 테스트도 각 운영체제에서 해야 합니다.
중간 선택도 가능합니다. 화면은 네이티브로 두고 도메인 규칙·네트워크·데이터 처리만 공유하거나, 공통 화면 중 일부만 공유할 수 있습니다.
먼저 절대 포기할 수 없는 조건을 적고 후보별 작은 프로토타입으로 가장 위험한 기능을 시험합니다. 숫자 표는 대화를 돕지만 실제 측정을 대신하지 않습니다.
[따라하기]
mobile_choice.py에 다음을 저장하세요. 숫자는 가상의 프로젝트 가정이며 도구의 보편적 순위가 아닙니다.
weights = {
"device_api_depth": 5,
"shared_delivery": 4,
"platform_specific_ux": 4,
"one_team_operation": 3,
}
ratings = {
"native": {
"device_api_depth": 5,
"shared_delivery": 1,
"platform_specific_ux": 5,
"one_team_operation": 2,
},
"cross_platform": {
"device_api_depth": 3,
"shared_delivery": 5,
"platform_specific_ux": 3,
"one_team_operation": 5,
},
}
def score(option):
return sum(
weights[criterion] * rating
for criterion, rating in ratings[option].items()
)
scores = {option: score(option) for option in ratings}
for option, value in scores.items():
print(option, value)
print("leading hypothesis:", max(scores, key=scores.get))
Windows는 py mobile_choice.py, macOS·Linux는 python3 mobile_choice.py로 실행합니다. 예상 결과는 native 55, cross_platform 62, leading hypothesis는 cross_platform입니다. 이는 공유 출시와 한 팀 운영을 높게 둔 가상 결과일 뿐 최종 선택이 아닙니다. device_api_depth가 실제로 어느 후보에서 충족되는지 카메라·백그라운드 작업 같은 어려운 기능을 각 플랫폼 실기기에서 먼저 시험해야 합니다.
[흔한 실수]
첫째, 한 번 작성하면 플랫폼별 작업이 전혀 없다고 생각합니다. 둘째, 첫 출시 속도만 보고 수년간의 업데이트 비용을 빼놓습니다. 셋째, 평균 화면만 만들어 카메라·알림·결제 같은 고위험 기능을 늦게 시험합니다. 넷째, 에뮬레이터만 보고 실기기 성능과 접근성을 판단합니다.
[보안 주의]
모바일 앱 바이너리와 번들은 사용자가 분석할 수 있으므로 API 비밀키와 관리자 자격증명을 넣지 마세요. 인증과 권한 판단은 서버에서도 수행하고 토큰은 플랫폼의 안전한 저장소를 사용합니다. 카메라·위치·연락처 권한은 기능에 필요한 시점에 최소 범위로 요청합니다. 크로스플랫폼 플러그인도 공급망 의존성이므로 출처·권한·업데이트·취약점을 검토하세요.
[직접 해볼 과제]
one_team_operation 가중치를 1로 바꿔 결과를 비교하세요. 이어서 오프라인 지원과 접근성 두 기준을 추가하고, 후보 두 개로 2일짜리 프로토타입을 만든다면 측정할 항목을 각각 세 개 적으세요.
[확인문제]
1. 크로스플랫폼에서도 플랫폼별 코드와 테스트가 필요한 이유는 무엇인가요?
2. 점수표의 62점이 최종 결정을 의미하지 않는 이유는 무엇인가요?
3. 네이티브 UI와 공유 로직을 결합하는 중간 선택은 언제 유용한가요?
[다음 학습]
순환 커리큘럼의 다음 글은 IOT-002 마이크로컨트롤러와 싱글보드 컴퓨터입니다. 모바일 트랙에서는 MOBILE-003 화면·컴포넌트·내비게이션으로 이어집니다.
[공식 참고 자료]
Apple SwiftUI
https://developer.apple.com/documentation/swiftui/
Android Jetpack Compose
https://developer.android.com/compose
Flutter 아키텍처
https://docs.flutter.dev/resources/architectural-overview
React Native 플랫폼별 코드
https://reactnative.dev/docs/platform-specific-code
- 이전글[IOT-002][입문] 마이크로컨트롤러와 싱글보드 컴퓨터 구분하기 26.08.30
- 다음글[SWE-002][입문] 읽기 쉬운 이름·함수·모듈 만들기 26.08.30
댓글목록
등록된 댓글이 없습니다.