23년 9월에 시작해 24년 2월까지 약 5개월 동안 앱 프로젝트를 진행했다.
부족한 점이 많은 프로젝트지만 그래도 진행하면서 경험했던 내용들이 잊혀지기에는 아쉬운 내용이 많아 간단하게라도 정리하고자 한다.
프로젝트 결과물은 아래에서 확인 할 수 있다.
기술스택 정하기
앱을 개발에는 다음과 같은 5가지의 방식이 있다. 각각의 방식은 장/단점이 존재하며, 자기가 개발하려는 앱의 성격에 따라 선택해서 개발하는 것을 추천한다.
- 네이티브 앱(Native App)
- 모바일 웹 앱(Mobile Web App)
- 프로그레시브 웹 앱(Progressive Web App)
- 하이브리드 앱(Hybrid App)
- 크로스 플랫폼 앱(Cross-Platform App)
가장 기본이 되는 네이티브 앱
네이티브 앱은 단어 그대로 각 기기에 맞는 기본 언어로 개발된 앱을 뜻한다. 안드로이드 운영체제에서는 코틀린(Kotlin) 또는 자바(Java)를 사용하고, iOS는 스위프트(Swift) 또는 오브젝티브 C(Objective C)를 사용한다.
기본 언어로 개발되었기에 당연하게도 각 운영체제에 맞추어 최적화되어 있고 기기 자체의 기능에 손쉽게 접근해 사용할 수 있다. 다만, 안드로이드와 iOS 두가지 언어를 모두 익히고 따로 개발해야 되기에 상대적으로 비용과 시간이 높아진다.
웹 화면을 앱에 맞춰서 표기하는 모바일 웹 앱
가장 간단하게 설명하면 휴대폰으로 웹 브라우저(크롬, 사파리)에서 화면을 생각하면 된다. 기존의 웹 기술로 제작해 앱 화면에서 보이도록 설계한 서비스다.
기본적으로는 웹을 기반하여 작동하기에 별도의 설치가 필요하지 않다는 장점이 있다. 다만, 기기의 기능에 접근하는데 한계가 있고 앱에 비해서 접근성이 떨어진다.
웹과 앱의 장점을 합친 프로그레시브 웹 앱
주로 PWA라고 부르는 해당 방식은 점진적으로(Progressive) 네이티브 앱 수준으로 근접해가는 웹이라는 뜻으로 앱의 장점을 가지고 있는 웹 기술이다. 웹이기에 검색이나 링크를 통해 접근 할 수 있으면서 간편하게 설치를 통해 손쉽게 사용할 수도 있다. 또한, 웹 기술(HTML, CSS, JavaScript)로 개발해 안드로이드와 iOS 운영체제에서 사용할 수 있으며 네이티브 앱처럼 푸시알림과 같은 기기의 기능을 사용할 수도 있다.
다만, 2016년도에 처음 소개된 짧은 역사를 가진 기술이기에 상대적으로 낮은 인지도로 인해 사용자 입장에서 진입장벽이 높고 네이티브에 비하면 상대적으로 부족한 성능을 보여준다.
특정 주소의 화면을 보여주는 하이브리드 앱
앞선 PWA와 비슷하게 네이티브와 웹을 합친 방식이다. 다만, 하이브리드 앱에서는 네이티브 앱을 기반으로 앱에서 웹 화면을 가져와 사용자에게 보여주는 방식이다. 따라서 대부분의 기능들을 웹 기술을 통해 개발이 가능하며, 웹 기술로 구현이 어려운 기능들은 네이티브 앱을 기반하여 처리할 수 있게 개발한다.
그렇지만, 웹 화면을 보여주는 특성상 네이티브 앱과 웹 화면과의 UI 특성의 차이가 있어 사용자 입장에서 괴리감을 느낄 수 있다.
하나의 프레임워크로 모든 운영체제를, 크로스 플랫폼 앱
기존 네이티브 앱을 개발하려면 안드로이드 iOS 두개의 언어를 알아야 하는 것과 다르게 크로스 플랫폼에서는 하나의 언어만을 이용해 두개의 앱을 개발할 수 있다. 대표적으로는 React-Native와 Flutter가 존재한다.
당연하게도 네이티브 보다는 성능이 조금 떨어지지만 뛰어난 성능을 가지고 있고 기기의 거의 대부분의 기능을 활용할 수 있으며, 훨씬 간편하게 안드로이드와 iOS 앱을 개발 할 수 있다.
왜 크로스 플랫폼 앱, React-Native인가?
이번에 개발한 앱은 챌린지 형식으로 다음과 같은 기능들이 필요했다.
- 높은 접근성
- 사진 촬영과 같은 네이티브 기능
- 자신의 ID와 함께 친구 초대
따라서 기존의 네이티브 앱이나 그와 유사한 크로스 플랫폼 앱으로 개발하고자 하였고, 비용과 시간적인 측면에서 좀 더 간편하게 개발할 수 있는 크로스 플랫폼 앱 방식으로 선택하게 되었다.
그렇다면, Flutter와 React-Native 중 어떤 방식을 골라야 할까?
리엑트 네이티브(React-Native)
React-Native는 페이스북에서 개발한 프레임워크로, 프론트엔드 개발을 한다면 친숙한 언어인 JavaScrpit 기반으로 구현 되어있다. 실제로 리엑트로 개발을 해본 프론트엔드 개발자 입장에서는 정말 간편하게 사용할 수 있다. 아래는 React-Native 공식 문서에 소개된 예제 코드다.
import React from 'react';
import {Text, View} from 'react-native';
const YourApp = () => {
return (
<View
style={{
flex: 1,
justifyContent: 'center',
alignItems: 'center',
}}>
<Text>Try editing me! 🎉</Text>
</View>
);
};
export default YourApp;또한, 오픈 소스 커뮤니티가 잘 되어 있어 개발 관련 정보를 손쉽게 찾을 수 있고 Styled-Component와 같은 CSS 라이브러리를 포함한 다양한 라이브러리를 가져와 사용할 수 있다. 그리고 코드 푸시(Code Push) 기능을 통해 앱 스토어 배포없이 원격 서버를 통해 JS 코드를 업데이트를 해 앱을 설치한 사용자에게 즉각적으로 코드를 수정해 화면을 보여줄 수 있다.
플러터(Flutter)
플러터는 구글에서 개발한 프레임워크로 Dart 언어를 사용한다. Flutter에서는 자체적으로 제공하는 위젯(Widget) 기반으로 UI를 구성하며 Bridge를 통해 자바스크립트와 네이티브간의 통신을 하는 React-Native와 다르게 자체 엔진을 통해 Bridge 없이 보다 빠르게 작동할 수 있다.
출처: https://hackernoon.com/whats-revolutionary-about-flutter-946915b09514
또한, Dart 언어를 개발한 곳도 구글이기에 Flutter에서 필요한 경우 Dart 언어의 기능을 추가해 Flutter에서 사용할 수 있다는 점과 React-Native와 다르게 매년 Flutter에서는 꾸준한 업데이트 통해 개선되고 있다는 점도 장점으로 작용한다.
24년 4월기준으로 React-Native의 버젼은 0.74, Flutter은 3.19.0이다.
React-Native vs Flutter
두 프레임워크 모두 뛰어난 성능을 가지고 있으며 각각 장/단점이 존재한다. 해당 프로젝트에서는 React-Native를 도입하기로 결정했으며 이유는 다음과 같다.
- 러닝커브가 낮다.
비록 Dart언어가 쉽다고 해도 익숙한 JavaScrpit 기반인 React-Native 보다 Flutter를 선택할 경우 필수적으로 개발에 필요한 시간과 비용이 올라가게 된다고 보았다. - 코드 푸쉬가 가능하다.
처음 앱을 개발하는 입장에서 분명히 완벽하게 QA를 진행할 수 없을 것이고, 자잘한 수정사항과 버그들이 발생 할 것이라 생각했다. 이때마다 매번 앱스토어에 배포-심사 프로세스를 거치기에는 너무 비효율적이라고 생각했다. - Material UI를 사용한다.
구글이 개발해 안드로이드 스마트폰에 적용한 디자인 시스템인 Material Design을 사용하고자 했다. 따라서 기본 네이티브 모듈을 크게 수정하지 않고 React-Native를 통해 필요한 화면을 구성할 수 있으리라 생각했다.
React-Native로 개발을 마치고.
React-Native로 앱 개발을 진행하면서 불편한점도 많았지만 생각하고 있던 기능을 대부분 성공적으로 구현했다. 짧은 기간 중 기획, 디자인, 서버개발 등도 병행해서 진행한 만큼 초기에 목표로한 적은 시간과 비용으로 앱을 개발하고자 한 목표는 분명 성공적으로 달성했다.
하지만 React-Native로 개발을 마친 뒤 초기에 생각한 React-Native의 장점에는 몇가지 오해가 있었다.
- 실제로 러닝커브가 낮지 않다.
단순한 쇼핑몰 사이트 같은 경우 JavaScript 정도의 기술을 통해 정말 간단하게 뛰어난 결과물을 얻을 수 있는 것은 틀리지 않았다. 다만, React-Native에서 지원하지 않는 기능(Kakao API 연동 등)을 사용하게 되는 경우 반드시 안드로이드와 iOS의 네이티브 언어에 대한 지식이 필요하다.
안드로이드, iOS, JavaScrpit 개발자가 모두 있는 기업 입장에서는 상관이 없지만 JavaScrpit만으로 앱을 개발할 수 있다고 오해를 해 React-Native를 선택하는 경우 기술 스택을 고르기 전 앱의 기능이 React-Natvie에서 지원하는지 꼭 확인해야한다. - 코드 푸쉬는 쉽지 않다.
앱 배포 후 QA 과정에서 코드 푸쉬 기능을 넣고자 했으나 실패해 매번 배포-심사 프로세스를 통해 앱을 업데이트 했다. 단순히 코드 푸시를 구현하기 위해 필요한 기술적 지식에 대한 진입 장벽도 높지만, 생각보다 신경 써야할 부분도 많았다.
코드 푸시가 생긴 경우, 사용자가 선택적으로 받을 수 있는지 아니면 필수적으로 받아야 하는지를 정해야하고 앱 실행 중에 코드 푸쉬가 들어오는지 매번 체크해야하는지, 아니면 초기 실행에만 검사하는지도 정해야한다. 또한, 설치가 되고 있는 경우 진행도를 표기할Progress Bar와 화면 또한 필요하다. - 안드로이드와 iOS에게 동일한 환경을 제공하는게 어렵다.
생각보다 한쪽의 환경에서만 작동하는 기능이 많고 이러한 점이 굉장히 신경이 쓰인다. 가장 치명적이었던건 커스텀 폰트인 TossFace에서 발생했다. 안드로이드에서는 멋대로 Padding 값이 붙어있거나, Vertical Align이 안되는 등 다양한 문제가 발생했다. - 디버깅이 어렵다.실제로 React-Native로 개발하면서 대부분의 시간은 오류를 해결하는데 사용했다고 생각한다. JavaScrpit를 Bridge를 통해 네이티브로 변환해서 동작하는 프레임워크 특성상 외부 라이브러리를 통해 사용하지 못하는 네이티브 기능을 사용 및 수정했고, 이러한 구조상 높은 확률로 충돌과 버그가 발생한다.
이 과정에서 JavaScript 코드 뿐만 아니라, 네이티브 기능까지 확인해야하므로 개발에 난항을 겪은적이 종종 있었다.
어떻게 보면 단점을 많이 적었는데, React-Native는 좋은 프레임워크라고 생각한다. JavaScrpit로 손쉽게 앱을 개발할 수 있다는 점에서는 높은 점수를 주고 싶다. 다만, 누가 앱개발을 하게 된다면 개인적으로는 Flutter을 추천할 것 같다. 아직 Flutter으로 규모있는 프로젝트를 진행해보진 않았지만, Flutter으로 학습 중 가장 많이 느낀 점은 "쉽고 편하고 재밌다." 였다. 크로스플랫폼의 특성상 두 프레임워크 모두 한계가 있겠지만, 둘 중 하나를 정 고른다면, 좀 더 재밌게 개발했던 Flutter을 고르지 않을까 싶다.
