리엑트 네이티브 개발 경험기
웹 개발자로서 앱을 만들어야 한다고 말했다.
"React Native" VS "Flutter" 뭐가 더 쉽나요?
요새 흔하게 시작하는 멘트입니다.
"그거 하면,
Android, IOS 동시에 개발 가능하다면서요?"
물론 동시에 개발이 가능하긴 합니다.
하지만, 꼭 장점만 있는 것도 아니고, 단점만 있는 것도 아닌데요.
앱을 론칭하고 운영하면서 겪은 경험담을 소개해드려 보겠습니다.
원래는 작년 말쯤 론칭이 끝난 직후
이 경험담을 쓰려고 했지만,
차일피일 미루다 보니 벌써 1년이나 지났네요.
원래 시스템이란 도입도 어렵고, 운영 및 유지보수도 어렵지만,
만약 또 이런 서비스를 도입하려고 하시는 분들에게는 조금이라도 더 빨리
이런 경험들이 알려지는 것이 도움이 되겠다고 생각이 되어서 다시 글쓰기를 도전해 봅니다.
앱 개발 착수 일 : 2020년 3월, 앱 론칭일 : 2020년 9월
현재 앱 론칭 이후 약 1년 3개월이라는 시간이 흘렀는데요.
앱의 개발 시작 이야기부터 현재의 앱이 되기까지의 다양한 이야기를 해보도록 하겠습니다.
리엑트 네이티브를 선택한 이유
우선 전 리엑트 개발자가 아니었습니다.
회사에 이직 후에 리엑트를 1~2달 정도 했고, 2019년 10월 이직한 이후로
처음 아이들랩 회사에서 있던 시스템을 익히고 점검 후에 앱 개발에 착수한 건 약 4~5개월 지난 후입니다.
한창 Flutter 가 뜨기 시작한 시점이었고,
현재 웹 서비스만으로 돌아가던 회사의 서비스를 고도화할 필요성을 느끼고 있었습니다.
물론 웹만으로도 서비스의 정체성을 계속 유지하면서 성장을 할 수는 있지만,
모바일에 대한 사람들의 충성도. 그리고 그 편리함을 고려했을 때, 장기적으로 회사가 큰 도약을 하기 위해서 결단이 필요하다는 생각을 했습니다.
과거 앱을 론칭한 경험에 전 스타트업에서 앱을 유지 보수하면서 앱을 관리해본 경험 등을 토대로,
앱을 만들어야겠다고 생각을 했고,
이를 착수하기 위해 자료 조사 및 선택을 하기로 했습니다.
Flutter의 장점은 Dart라는 새로운 언어, 그리고 구글이 서포트해준다는 점, 그리고 나온 지 얼마 나오지 않아서 핫하다는 점 등등이 장점이었고,
리엑트 네이티브의 경우는 시장에 나온지는 그래도 2~3년 정도 되었다는 점, 페이스북이 관리를 좀 잘 안 한다는 점이 단점이라는 대략적인 상황 판단을 하였고, 그리고 리엑트의 언어와 언어적 기반이 매우 흡사하다는 지점이 눈에 들어왔습니다.
자원이라는 건은 늘 한정적 자원 안에서의 최대의 효율을 고려해야 합니다. 제가 이 스타트업의 입사 당시 개발팀의 인원이 몇 명 되지 않았다는 지점에서 앱을 만들기로 결심하는 것은 매우 어려운 일이었습니다.
하지만, 새로운 언어에 대한 도전, 그리고 그 결과가 기대가 되었기 때문에 웹이 어느 정도 안정화된 이후에 개발을 시작하기로 합니다.
리엑트 네이티브를 선택한 가장 큰 이유 중 하나는
https://reactnavigation.org/docs/getting-started/
였습니다.
앱의 구조가 탭의 형태를 띠고 있는데, 탭의 구조를 라우트의 느낌으로 자유자재로 앱 내에서 이동을 가능하게 하는 구조를 찾고 있었는데, 마침 이 리엑트 내비게이션이 업그레이드 소식이 있었고,
5 버전을 적용해보면 딱 좋겠다는 생각이 들어서, 레퍼런스가 부족하기는 했지만,
이 라이브러리의 선택의 지금의 앱을 선택하게 된 결과 인듯하네요.
그리고 Flutter에 비해 라이브러리가 많아서 디자인을 커스텀하기에 좋다는 생각도 들긴 했는데,
사실 충분히 Flutter도 현재는 다 가능해지게 되지 않았을까 생각해 보긴 합니다.
expo와 리엑트 네이티브
첫 리엑트 네이티브의 프로젝트는 expo로 테스트를 하고 진행을 했는데요.
expo로 한 달 정도 진행해보니, 리엑트 네이티브 클리로 한다고 해도 큰 차이가 없을 것 같다는 확신이 들었습니다. expo는 처음 리엑트 네이티브를 시작하는 사람에게 조금 더 접근하기 쉬운 툴입니다. 심지어 안드로이드나, 아이폰 빌드가 없더라도, 실행해볼 수 있고, 웹으로 화면을 볼 수 있다는 것이 가장 큰 장점인데요. 리엑트 네이티브 클리의 경우는 이런 expo에 비해서는 조금 더 기기를 세팅해야 한다던지, 안드로이드 스튜디오나 XCode 같이 안드로이드, 아이폰 빌드 툴이 있어야 해서 약간은 난이도가 더 있다고 볼 수도 있습니다. expo가 쉽다고는 하는데, 보니까, 여러 가지 라이브러리를 적용하는데도 문제가 있고, 웹으로 볼 수 있는 점이 장점이라고는 하는데, 특별한 점이 없어 보였어요.
그래서, 앱을 개발하는 상황이 더 커지고 어려워지기 전에 eject을 해야 한다는 이야기가 많이 있어서 실행하기로 합니다.
과정은 간단한데요.
명령어 : expo eject
이라고 실행하면 됩니다. 다만 안드로이드 폴더와 아이폰 폴더를 확인하고, 안드로이드 스튜디오에서 잘 빌드가 되는지, 아이폰에서 잘 빌드가 되는지를 확인해야 하는 이슈가 있었죠.
이렇게 eject 명령어를 사용하면, 기존에 개발해 놓은 expo로 짜여진 소스를 리엑트 네이티브 클리를 이용해서 빌드할 수 있도록 소스들을 변경해줍니다. 애초에 처음부터 리엑트 네이티브 클리를 이용해서 작성했다면, 이런 고민을 할 필요가 없지만, 조금 더 쉽게 리엑트 네이티브를 사용하기 위해서 expo를 사용한 사람들의 경우는 이 결단을 해야 할 필요가 있습니다. 조금 더 주요한 차이라고 한다면, expo에서도 라이브러리를 사용하고 리엑트 네이티브에서도 라이브러리를 사용하는데요. 이게 expo에서만 사용 가능하고 지원 가능한 라이브러리도 있고, 또 리엑트 네이티브에서만 사용 가능한 경우도 있고, 경우에 따라서는 라이브러리가 되고 안되고의 차이가 있어서, 한 방향으로 하게 되면, 계속 그것을 이용해야 한다는 점이 있습니다. 이 점을 참고하고 개발을 시작하면 됩니다.
socekt js 적용하기 (채팅 서비스 구축)
지금 생각해보면,
그때는 어떻게 서비스가 유지될 수 있었는지 궁금할 정도로,
채팅 서비스를 통해서 현재의 고객들이 대화하고 결제하는 시스템이 잘 동작하고 있는데요!
첫 웹 서비스에서는 고객은 채팅 없이도 결제했었습니다! 그게 더 대단!!
리엑트 네이티브에서 웹소켓을 사용할지, 다른 라이브러리를 사용할지를 고민했었는데요.
https://socket.io/ 를 적용해서 채팅 서비스를 구축했는데요.
해당 서비스는 이미 잘 알려진 라이브러리이기도 하죠!
다만 구축을 하는 입장에서는 해당 예제만으로는 한계가 있었는데요.
문제를 해결하는 게 또 역할이다 보니, 여러 가지로 애로사항이 많았습니다.
또한 함께했던 동료가 있어서 해결해 나갈 수 있었죠!
채팅에 대한 설계 부분을 따로 말할 수는 없지만!
쉽지는 않았어요! 두 가지 기종의 안드로이드와 아이폰, 그리고 웹에도 채팅을 가능하게 해야 하는 것과
기존에 있는 서비스 부하를 주지 않기 위해서 따로 구성하는 부분 등등
채팅 서비스가 시작되고 나서
현재 지금의 서비스가 구성이 될 수 있었고,
지금은 이 채팅이 없다면 어떻게 서비스가 돌아갈 수 있을지 상상할 수 없네요!
6개월간의 론칭 여정(시간의 촉박함)
앱을 개발한 시간은
물론, 지금까지도 계속 개발 중이긴 합니다만,
2020년 3월 ~ 2020년 9월 총 6개월 정도 앱에 본격적으로 개발을 시작해서, 론칭까지 걸린 시간입니다.
9월에 오픈을 하긴 했지만,
그 당시에는 약간 허름한 면모도 갖추고 있었습니다.
기능도 많이 빠져있어서, 가게는 오픈했는데, 재료가 좀 부족한 상황이었고,
약간 분주한 느낌이 많았습니다.
하지만, 그 6개월은 어떻게 시간이 흘러갔는지 모르겠네요.
로그인도 해야 하고, 로그인 유저의 계정 정보를 어떻게 해야 할지,
기존에 시스템과 앱과의 연동 상황을 고려해야 하고,
결제도 해야 되고, 채팅도 해야 되고, 저희의 클래스 정보도 예쁘게 보여주어야 하고...
할 일은 정말 끊임이 없습니다.
앱을 개발하거나 서비스를 운영하거나, 뭔가를 시작하려고 계획 중이신 분이라면,
정말이지 모든 것들을 다 하고 싶으실 거예요. 하지만, 그러려면, 끝이 없다는 사실...
따라서, 뼈대를 세우고, 정말 필요한 것만을 우선적으로 설정해서 시동을 건다는 것이 중요하죠.
저의 경우는 백엔드 세팅 및 서버 API도 직접 만들었기 때문에,
프런트에만 에너지를 쏟을 수는 없었는데요. 분산된 상황과 제한된 시간,
나중에 API개수만 100여 개가 넘는 것을 보고.....
결국에는 론칭을 하긴 합니다! 결제도 일어났고요!
6개월이라는 시간은 꽤나 오랜 시간 동안 기억할 것 같은 날이네요.
함께 고생한 영혼을 갈아 넣어준 친구에게 다시 한번 박수와 찬사를 보냅니다.
놀랍게도 이 앱을 2명이 초기에 만들었고, 그 친구는 안드로이드/아이폰 개발을 했던 친구였는데,
현재는 리엑트 네이티브로 안드로이드와 아이폰 둘 다 자유자재로 개발이 가능해진 상황입니다.
그리고 지금은 조금 더 팀원이 늘어나서,
개발 및 유지보수가 가능해진 상황인데요!
지금의 앱은 실력 있는 디자이너의 합류로 훨씬 더 보기 좋아지고 예뻐진 상황입니다. (물론 기존에도 잘해주셨지만! 충분히 앱이 론칭된 이후에 생각과 고민이 디자인으로 녹아지다 보니 또 새로운 앱이 된 느낌이에요!)
초기 화면에 비해서 앱이 너무나 예뻐지고 기능도 많이 개선된 모습입니다.
웹 서비스와 앱 서비스의 특징(빌드의 어려움)
제가 웹 개발을 하다,
앱 개발 서비스를 리드하고, 함께 개발하다 보니,
겪게 된 고민과 이슈들이 있었는데요.
웹의 경우는 npm install이나, 의존성의 문제 때문에 업그레이드하는 경우에 여러 가지 문제들에 직면했었는데요.
앱의 경우는 해당 부분의 모듈과 의존성에 대해서, 빌드 툴에서 설치 시에 정상적인지를 체크하는 첫 번째, 그리고 안드로이드에서 빌드되고, 정상적으로 화면에 나오는지에 대한 두 번째, 마지막으로 아이폰에서 개발된 결과물이 동일한지, 그렇지 않은지에 대한 3번째 단계를 체크해야 하다 보니, 어려움이 많이 있었습니다.
특히나 카카오나 네이버 로그인의 경우, 로컬에서 빌드하고, 체크해보는 것을 테스트하는 환경이 부족하기 때문에 실제로 론칭 한 뒤에야 문제를 발견하게 될 수도 있고,
해당 부분을 테스트하는 과정이 무척 어려웠기 때문에 해당 공수에 대한 시간이 많이 들어갔었는데요.
그 과정 이후에 해당 문제가 해결될 수 있었습니다.
안드로이드의 경우
안드로이드의 경우는 gradle 파일에서 모듈을 추가해주거나 빠지는 부분을 체킹 하는 부분에 시간이 들었습니다. 따라서 빌드 이후에도 여러 가지 문제가 생길 수 있는데, 꼭 테스트를 다 거쳐야지 문제가 있는지 없는지를 확인할 수 없었기 때문에 빌드 이후가 중요했습니다.
아이폰의 경우
대부분의 경우는 큰 문제가 없었는데요. 리엑트, 리엑트 네이티브 버전에 따라서 pod 파일의 문법들이 조금씩 달라지는 부분이 있었는데, 의외로 이 부분에서 막혀서 시간을 잡아먹은 케이스가 좀 있던 것 같습니다.
그래서, 특정 버전과 모듈을 업그레이드하기 위해서는 또 다른 부분을 살펴보아야 하고, 또 너무 업그레이드를 하는 경우, 또 다른 모듈과의 충돌 문제가 발생하는데요.
그 과정에서 node_modules 폴더를 얼마나 많이 지웠는지 모르겠네요.
그리고, 의존성의 문제라던지 아이폰에서는 서로의 라이브러리의 이름이나 h파일을 못 찾아서 꼬이는 경우들이 종종 있는데, 이런 문제로 pod install 이후에도 라이브러리를 세팅하는 과정이 쉽지가 않습니다.
이런 과정을 겪다 보면, 아... 그냥 네이티브가 낫다. 그냥 이렇게 고구마를 먹느니, 그냥 네이티브로 개발하고 만다라는 소리가 절로 나오는데요.
만약 리 엑트 네이티브 개발자가 한숨을 쉬면서, 뭔가 욕하고 있다면 이런 상황이라고 생각해 주시면 되지 않을까 싶네요...
결과적으로는 이런 과정이 옆에서 보기에는 비효율적으로 보여도, 이런 과정이 끝나고 나면 화면을 그리거나 안드로이드나 아이폰을 동시에 변경할 수 있다는 장점이 기다리고 있습니다!
리엑트 네이티브 개발 시 어려운 점(유의사항)
웹을 개발하다가 리엑트 네이티브 개발 시에 참고할 부분, 혹은 안드로이드나 아이폰 네이티브를 하다가 리엑트 네이티브를 해보려고 할 때 참고할 점들을 말씀드려볼게요.
리엑트 문법이 필요
제가 리엑트 네이티브를 선택한 이유 중 하나가 리엑트를 조금 경험했다는 이유였는데요.
실제로 리엑트 네이티브를 개발하기 위해서는 리엑트 문법에 대한 지식이 필요합니다.
따라서 처음에 리엑트에 대한 구조적인 지식이나 앱 설계 경험이 동시에 있어야 한데요. 안드로이드 개발이랑 아이폰 개발도 개발 스타일이 많이 다른데, 리엑트까지 또 공부해야 한다는 생각이 들 수 있습니다. 그러니 리엑트를 경험하지 않은 개발자 입장에서는 당연스레 거부감이 들 수 있습니다.
타입 스크립트 지식
기본적으로 파일명이 jsx도 아니고 tsx 파일입니다. 타입 스크립트에 대한 이해도 전반적으로 깔려있어야 합니다. 사실 타입에 대한 정의를 미리 해주어야 한다는 부분을 제외하고는 문법적으로는 크게 다르진 않은데요. 만약 웹의 소스를 활용해서 앱을 만들어보겠다. 이건 좀 다릅니다. 새로 만들어야 하는 부분이 많아요.
웹과 앱을 동시에 할 수 있나요?
처음에 리엑트 네이티브를 만들 때 은근 이 질문도 많고 오해도 많은데요. 그 이유 중에 하나가 expo를 사용하는 경우 웹으로도 표기할 수 있기 때문인데요. 그 부분이 조금 더 편리하게 화면상에서 웹상에서 모바일 느낌으로 개발할 수 있도록 도와주는 역할을 하긴 하지만, 실제로 이것을 웹 서비스의 형태로 적용하게 하기에는 여전히 문제가 많이 있습니다. 첫 번째는 UI/UX 부분인데요. 전통적인 웹 모바일의 형태와 앱 서비스의 형태가 다르기 때문인데요. 기존에 웹의 경우는 상단 뒤로 가기가 가능하고 조금 더 가벼운 느낌입니다. 그리고 메뉴 바를 통해서 원하는 메뉴로 쉽게 접속하는 게 조금 더 편리한 반면, 앱에서는 탭 바를 통해서 접근성을 한정하더라도 앱이 안정감을 느끼는데요. 모바일 웹으로는 그렇게 진행하기에는 약간 어울리지 않는 측면이 있습니다. 이런 디자인이나 설정 부분도 문제가 있습니다. 마지막으로 리엑트 네이티즈 자체의 소스의 실행이 기본적으로는 react-native run-android, react-native run-ios 이 두 명령어만 보아도 웹을 지원하지는 않고, 안드로이드와 아이폰만 지원하는 것을 알 수 있는데요. 따라서 리엑트 네이티브로 개발한다는 것은 그냥 앱을 만들기 용이한 수준이라고 생각하시면 좋을듯하네요.
다만, 웹으로 이런 문법적인 부분이 비슷하기 때문에 활용할 충분한 가치는 있습니다. 따라서, 웹을 개발하기 위해서 리엑트 네이티브 개발자를 뽑는다고 하면, 조금은 어폐가 있는 것이겠죠! 따라서 웹 개발자와 리엑트 네이티브 개발자를 따로 뽑는 것을 추천합니다.
엠플리튜드 붙이기 (마케터와의 협업)
이런 서비스를 개발하고 나서는 후속 절차도 중요합니다.
A/B 테스트라고 하죠! 고객이 원하는 것이 무엇인가?
고객에게 설문이나 전화 등 등으로 많은 것들을 얻어내려고 하지만, 사실 고객도 모르고, 우리도 모르고, 서로가 형태 없는 무형의 서비스를 하다 보니, 진짜로 원하는 것에 접근하는 것이 쉽지는 않습니다.
거기에서 가장 중요한 것 중에 하나가 고객의 여정을 파악하는 일입니다.
그 일중에 하나가 엠플리튜드를 붙이는 것인데요. 웹으로 따지는 GA 구글 애널리틱스를 많이 붙입니다.
마찬가지로, 엠플리튜드를 붙이기 위해서는, 고객이 어떤 경로로 유입되었고,
어디를 선택하고, 어디를 누르고, 어디에서 결제가 일어나는지 파악하는 게 중요하겠죠!
그 여러 가지 항목들을 세팅하고, 앱 안에 붙여야 합니다. 이런 엠플리튜드를 적시 적소에 잘 붙이는 것도,
이번 프로젝트를 통해서 배운 점이라고 할 수 있겠네요!
이렇게 프로젝트를 진행하고, 인자 값을 넘기다 보면, 간혹, 이런 엠플리튜드에 넣는 인자 값들을 잘못 세팅하는 경우도 있는데, 그럼 버그로 이어지기도 합니다. 따라서, 그냥 가볍게 세팅한다고 생각하지만, 조금 더 꼼꼼하게 볼 필요가 있겠죠!
서비스 고도화를 위한 알람톡 연동 작업 (스케줄과 넛지)
프로젝트가 끝나고 진행되었던 것 중에 하나는 알람톡 연동 작업입니다.
고객과 만나는 지점은 엄청나게 많습니다!
저희 서비스의 핵심이라고도 할 수 있기 때문에 모두 나열할 수는 없지만,
서비스를 더 안정화하고, 고객과 만나는 지점들을 잘 설정하기 위해서는 이런 알람 톡이라던지, 넛지를 주는 장치가 필요합니다.
따라서, 이런 데이터 바인딩과 연동 작업이 쉽지는 않았는데요!
기존에 알림톡 업체에서도 자바나 다른 언어로는 되어있었지만, 리엑트로 연동하는 사람이 없었기 때문에
레퍼런스가 없었어요.
그래도, 한번 해보자는 마음으로, 연동을 시도해보았는데!
연동이 되더군요! 팁 중 하나라면, 제공해주는 코드가 제한된 언어라고 할지라도!
우리 언어가 없더라도 시도해보면 될 수 있다는 점입니다.
그리서 초기에 소통에 약간의 어려움은 있었지만,
한번 뚫리면 그 뒤는 쉽죠! 알림톡을 공통 함수로 만들어 두고는 다양한 서비스에 연결하는 과정 성공!
알림톡도 그 간에 서비스 안에 중요한 성과 중 하나입니다.
특출 난 에디터 분들이 멘트를 가다듬어 주셔서, 지금의 아이고고 멘트들이 만들어졌네요!
디자인 변경 및 검색 고도화 (클래스 검색이 더 쉽도록)
앞에도 살짝 언급했지만,
뛰어난 디자이너의 합류로 아이고고의 디자인은 조금 더 예뻐졌는데요!
동시에, 수업 유형과 교육 분야, 연령 및 지역 등등을 함께 검색할 수 있도록 검색이 고도화되었습니다.
아이고고는 일전에 이미 당근 마켓과 함께 작업을 진행한 일이 있는데요!
기사 한번 보고 가겠습니다.
https://www.news1.kr/articles/?4336188
https://www.newstomato.com/ReadNews.aspx?no=1051145
http://it.chosun.com/site/data/html_dir/2021/06/11/2021061101436.html
이렇게 다양한 기사가 나왔는데요!
당근 마켓이 이런 로컬라이제이션에 기반한 중고 거래 앱이라면,
저희는 이런 지역에 기반한 키즈 클래스 매칭 앱입니다.
이 서비스를 론칭하기 위해서도 꽤 많은 시간을 들여서 론칭을 했었는데요!
아이 고고에서도 키즈 클래스를 찾을 수 있고,
당근 마켓에서도 키즈 클래스를 찾을 수 있다! 이색적인 조합이었던 건이었죠.
저희는 지역 안에서 부모님들의 입소문으로 조금씩 더 성장하고 있습니다.
리엑트 네이티브 개발자를 찾는 팁이나 노하우
아마도 이 글을 보고 계신 분들 중에는
개발자나 학생으로서,
리엑트 네이티브로 앱이 어디까지 성장할 수 있는지를 궁금해하셔서 이 글을 보고 계신 분들도 많겠지만,
스타트업의 대표로서, 혹은 앱을 개발하려고 하는 분들 중에서,
리엑트 네이티브로의 개발과 함께, 어떻게 그런 개발자를 찾을지 고민하시는 분들이 있을 것이라고 생각합니다. 몇 가지 팁을 말씀드려보겠습니다.
먼저, 리엑트 네이티브를 처음부터 시작해서, 전향하고, 그렇게 개발자를 하고 계신 분들이 그리 많지는 않다고 생각합니다. 즉 리엑트 네이티브를 뽑으실 때, 리엑트 네이티브 연차를 7년 차 10년 차 이렇게 높게 설정하시면 안 됩니다. 즉, 저도 리엑트 네이티브만 따진다면, 2~3년밖에 안 되겠네요. 즉, 리엑트 네이티브로 앱을 론칭하거나, 만들어본 경험이 있는가? 이 정도면 조건은 충분하다고 생각합니다. 그럼 그다음으로 필요한 것은, 비슷한 앱, 비슷한 다른 프로젝트, 혹은 전체적인 개발에 관련된 연차수나 경험으로 비추어서 찾아야 가능하다고 생각합니다. 즉, 업계에 나온 지 얼마 안 된 기술을 연차라는 것으로 실력을 측정하거나 연봉을 측정할 수 없다는 것이죠. 이제는 프론트로 넘어가면 프런트 경력부터 다시 1년 차, 서버로 넘어가면 다시 서버에서 1년 차, 앱으로 넘어가면 앱에서 1년 차 이렇게 하면서, 경력을 깎아내릴 수는 없습니다. 이제 대 통합의 시대.. 이것도 하고 저것도 하고, 이것저것 한 개발자들이 늘어나고 있죠. 그런 다양한 경험과 경력을 갖춘 인재를 섭외하기 위해서는 개발 전체 경력을 경력으로 보아야 합니다. 이게 첫 번째입니다.
두 번째는 리엑트 네이티브 경험이 없는 사람이 없을 때는 누굴 뽑아야 하는가입니다. 안드로이드만 했던 사람을 뽑아보기도 했고, 리엑트 경험만 있는 사람을 뽑아보기도 했는데요.
일단, 리엑트 네이티브 경험이 있는 사람이 회사 내에 일단 1명은 있어야 합니다. 그 사람이 전파한다면 충분히 가능합니다. 다만, 그런 경험 있는 사람이 한 명도 없다면, 초기 세팅에 많은 시간을 투자해야 할 수 도 있습니다. 따라서, 가르칠 수 있다면, 안드로이드, 리엑트 무엇을 했든 가르치면 된다. 만약 그런 부분이 없다면, 애초에 리엑트 네이티브에 조금이라도 경험이 있는 사람이 낫다입니다.
세 번째는 리엑트, 리엑티브, 노드, 웹 등등 보다 중요한 것은 서비스에 대한 이해가 있는 개발자를 뽑는 것입니다. 즉 주니어나 신입을 뽑을 때는 이런 조건이 포함되지는 않습니다. 처음 서비스를 만들려고 할 때, 결제 서비스를 해본 적은 있는지, 개발 세팅은 어떻게 할 것인지, API를 설계해본 적은 있는지 물론 각각의 개발 역할이 있기 때문에 모든 것을 할 수 있는 사람을 뽑을 필요는 없는데요. 단순히 언어적인 부분으로 이해를 하고 있는 사람을 여러 명을 뽑는다고 하더라도, 개발에 속도가 나지 않을 수 있습니다. 보통 '정의'가 중요하다고 말을 많이 합니다. 서비스에 대하여 어떤 서비스를 어떻게 만들 것인지 정의가 잘 내려져야 하는데, 여기에서, 기획자나 PO 등등의 역할도 중요하지만, 그것을 개발해야 할 사람과의 의사소통이 무척 중요합니다. 이 단계에서 합의를 거치고 나서 개발에 들어가야 진짜 개발 일정이 나올 수 있고, 정상적이고, 괜찮은 서비스가 만들어질 수 있겠죠. 이런 부분을 고려할 수 있는 사람을 뽑아야 한다는 점입니다.
마지막으로 안드로이드, 아이폰 앱을 한 번이라도 론칭해 본 사람을 뽑으시는 것을 추천합니다. 물론 리 엑트만 한 사람도 리엑트 네이티브를 충분히 배워서 익힐 수 있고, 테스트로 한번 앱을 만들어본 사람도 뽑을 수 있지만, 론칭해본 사람은 론칭한 이후에 겪는 에러와 문제, 사이드 이팩트들을 충분히 체감한 사람일 수 있습니다. 즉, 문제를 겪고 그 부분을 처리해본 사람을 채용하는 것이, 문제를 겪어 보지 않은 사람을 채용하는 것보다 훨씬 더 효율적이라는 것입니다.
홈 개편 작업과 올해 도약을 준비하며
홈 개편 작업이 거의 끝이 나고 있습니다.
벌써 올해도 2월이 다 되었네요!
아이고고는 작년에도 꽤 많은 성장을 이루었는데요!
올해에도 성장을 이루기 위해서, 다양한 개발과 지점들을 만들어가고 있습니다.
좋은 분들도 꽤 많이 합류했는데요!
아이고고에 관심 가져주시고! 각 서비스들 링크드리오니 한 번씩 감상해주시면 감사하겠습니다.
아이고고 웹 서비스 :
아이고고 안드로이드 서비스 :
https://play.google.com/store/apps/details?id=com.igogo
아이고고 아이폰 서비스 :
https://apps.apple.com/us/app/id1524244020
이상 리엑트 네이티브 개발 경험기 마치겠습니다.
