모바일 네이티브 Kotlin(JAVA)&Swift 진영과 플러터 진영의 속사정

*. 아주 지극히 개인 한사람의 의견이므로 충분히 논란의 여지가 있을 수 있습니다! 진영(?)에 따라 불쾌한 내용이 있을 수 있으니 노여움을 푸셔요.

*. 긴글 헤이터를 위한, 행간 파악 귀찮니즈머를 위한 선결론 : 
1. 난 플러터나 리액트 네이티브가 죽었다 깨어나도 네이티브 언어인 kotlin과 Swift가 가지는 언어적 강력함을 깰 수 없다고 믿는 (믿고 싶은)사람이다. 
2. 네이티브 모바일 개발은 절대로 구시대적 기술이 아니다.

 

나는 우선 개발 입문을 Java 로 시작했다.

그것도 아주 고전적인 JSP 2.0 시대.

흔히들 말하는 학원 양산형 개발자라는 타이틀을 달고 말이다.

 

당장 전쟁을 위해 총쏘는 법만 가르쳐 전쟁터에 뛰어들 수 있게 해주는 속성반 졸업생이다.

정통파와 낭인(?)이라고 구분짓기는 좀 그렇지만, 높은 학습의 벽에 현실의 벽에 부딪혀 독학을 끊임없이 했고

"회사는 학교가 아니다" 라는 선배들의 엄포를 피해 퇴근후에는, 이직 중간에는 늘 학습을 하고 셀프 프로젝트를 만들었다.

웹으로 시작했던 개발 커리어가 그렇게 모바일로 거쳐갔고, 안드로이드를 지나 아이폰으로 넘어갔다.

물론 당시에는 Java 기반은 안드로이드 였으며 Objective-C 기반의 아이폰 앱이 대세였고,

스리슬쩍 Kotlin과 Swift 라이브러리와 예제가 많아지면서 현장의 분위기에 맞춰 자바를 코틀린으로, 오브젝티브씨를 스위프트로 컨버팅하는 학습과 업무를 병행하기 시작했다.

그렇게 꽤 시간이 흘렀고 웹에서도 Java가 아닌 Koltin 기반의 스프링 프로젝트로 스멀스멀 현장에서 나타나기 시작했고

모바일쪽은 UI 개발의 어려움을 아는지 원청(?)인 구글과 애플은 Jetpack Compose와 SwiftUI로 UI를 그리라고 지원해줬다.

 

그 중간 어디쯤이었을까? 아니면 아주 오래전?

플러터(Flutter)라는 언어가 등장하기 시작했고 모바일 개발자들 사이에서 조금씩 입방아에 오르내리기 시작한 때가 있었다.

 

모바일 앱 개발자가 생겨나기 시작한 초반에는 특별한 경우를 제외하고는 안드로이드 개발자는 안드로이드만, 아이폰 개발자는 아이폰만 개발할 줄 아는 사람이 많았고, 현장에도 개발자는 최소 2명으로 각기 구분되어 있었다.

그러다가 문득

개발외적인 "인프라" 측면을 생각해보니,

산술적으로 생각했을때 회사입장에서는 안드로이드 개발자 1명, 아이폰 개발자 1명 이렇게 2명을 뽑는 건 리스크가 클테니 (급여, 부사수 부재 등) 둘 다 개발할 수 있는 나같은 인원(2명분의 연봉보다는 좀 더 적게 페이 지급)을 선호하지 않을까 생각했고. 

 

나는 그래서 그 안에서 경쟁력을 키우기위해 "안드로이드 개발자", "아이폰 개발자"라는 한쪽 진영을 대변하는 명칭이 싫기도 했고

둘다 할 줄 아는 "모바일 개발자"가 되기위해 Java, Kotlin, Obejctive-C, Swift 를 모두 학습해서 자유자재로 앱을 만들고 컨버팅하고 서로 고치고 반영하고 한날 한시에 동시에 배포할 수 있을 수 있도록 커리어를 키웠다.

 

역시! 네이티브 개발이 훨씬 어려워! 라고 말하기는 좀 단편적인 결론일 수 있지만

실제로 네이티브 개발은 필수적으로 고려해야할, 학습해야할 부가적인 요소들이 너무 많다.

코틀린과 스위프트 로직과 코딩자체에만 집중하려면 최소한 UI를 그리는 방법(동적인 코딩으로 화면을 그리는 업종이라면 그건 다른 이야기)까지해서 산술적으로 총 4가지 스킬이 필요하다.

각각 순수 로직과 UI를 그리는 부분까지 말이다. (다른 방법도 존재하지만 전통적인 방식을 기준으로 했을때)

그러다보니 모바일 네이티브 기술로 안드로이드 아이폰을 둘다 개발하는 (그것도 동시에 런칭 가능할 수준으로 동시 개발이 가능한 수준) 개발자도 별로 없고, 실제로 재야에 숨어있다해도 한가지 영역만 하는 경향이 강했으며

그러다보니 좀더 안드로이드 개발자, 아이폰 개발자, 또는 둘다하는 개발자들은 더 스킬적으로도 급여부분에서도 평가가 높았다.

 

그런데 그렇게 5년여의 시간이 흘렀을까?

어느샌가 나같은 동시에 둘다 하는 개발자는 점점 줄어갔고, 회사 입장에서도 개발자 2명을 구하지 않고 그냥 1명만 구인하되 앱은 안드로이드 아이폰 둘다 할 수 있는 "네이티브 개발자"가 아니라 "플러터" 또는 "리액트 네이티브" 개발자를 구하기 시작했다.

크로스플랫폼의 Stable한 개발 버전과는 무관하게 소위 뜬다하는 언어로 개발자들이 눈을 돌리기 시작했다. (그게 네이티브 개발의 러닝커브때문이었든 미래 지향적인 마인드였든 현실 타협이었든 그 이유야 뭐든 간에) 

반응형

개발자 2명을 쓰기에 돈이 아까운걸까? 아니면 2명분을 해내는 네이티브 개발자에게 2명분의 페이를 주기 어려운걸까?

난, 이때부터 였다고 생각한다. 

네이티브로 모바일을 개발하는 개발자들의 연봉이 점점 하락해버린 시점이.

 

2명을 써야할 페이를 1명분으로 채울 수 있으니 최소한의 지출로 최대의 리소스를 창출해야하는 회사 입장에서는 당연히 올바른 선택이겠지만서도,

2명을 써야할 포지션에 1명으로 가능했던 네이티브 개발자가 아니라 1명으로 가능한 플러터, 리액트 네이티브 개발자를 뽑으려고 할때부터

분명히 네이티브 개발자의 개발 단가가 내려가기 시작했다.

 

물론, 플러터나 리액트 네이티브의 러닝커브가 낮다는건 아니다.

난 어느 언어나 개발자와 합이 잘 맞는 언어가 있고 아닌 언어가 있어서 러닝커브는 개인차가 있다고 생각하는 개발자이다.

그러나 어찌모르게 크로스 플랫폼이 가능한, 즉 하나의 언어로 여러 플랫폼의 앱을 만들어내는 언어가 상승하면서

이상하게 네이티브 개발자들의 급여와 설자리가 줄어들고 있다.

당연히, 언어라는 것이 시대에 따라 바뀌고 그 언어가 인기가 있을때 그 언어를 구사하는 업종의 개발자들이 늘어나면 기존의 언어를 구사하고만 있는 개발자들의 설자리는 줄어들겠지만, 이상하게 기존의 네이티브 개발자들이 대접받던 만큼의 페이보다 크로스 플랫폼을 구사하는 개발자들의 페이가 훨씬 낮다. (이 부분이 좀 논란이 될 수 있겠지만 네이티브 개발자들보다 더 많이 받는 경우도 분명 있다!)

 

곰곰히 생각해보니 

위에 말한대로 2명분의 네이티브 개발자나 2명분을 해내는 1명의 네이티브 개발자에게 페이를 지급하는 것이 부담되는 개발사들이 

크로스 플랫폼을 채택하는 경우가 늘어서 그렇게 느껴지는 것이 아닐까 하는 이유도 찾아보게 됐다.

중견, 그 이상의 기업들에서도 플러터를 도입하고 있다고 들었고 물론 그 소속의 개발자들은 당연히 페이를 많이 받겠지만

네이티브 개발자라는 이름이면 뭔가 당당(?)하게 요구할 수 있었던 페이를 이제는 그렇게 요구할 수 없는 (기존 네이티브 개발자가 플러터 직종을 지원하다고 해도) 업체가 많이 보인다. 

 

"당신 유튜브 채널 (센치한 개발자) 은 들어본적도 없는 듣보잡이에요. 저는 플러터가 핫해서 그거밖에 몰라요"

 

어느 개발 커뮤니티에서 알게된 개발 지망생이

"당신 유튜브 채널 (센치한 개발자) 은 들어본적도 없는 듣보잡이다. 난 플러터 개발자다." 라며

심각하게 디스를 한적이 있었다.

사실 내가 이 포스트를 쓴 이유는 이런 연유때문이었다.

나를 무시해서가 아니라 네이티브한 언어로 만들수 있는 개발 방식을 무시했다고 생각했기때문이다.

양산형 개발자라 양송합니다를 말하게 되는 여러 이유만큼이나 무서운 발언이었다고 생각한다.

"대충 인기있는 거나 배워서 돈이나 벌려구요"로 밖에 난 들리지 않았다.

그게 잘못된건가요? 라고 한다면 .. 내 철학에 의해서는 잘못됐다고 하고 싶다.

예전에 내 방송에서도 말했었지만 다같이 열심히 하고 다같이 기초를 탄탄히 해야

우리 후배들이 한국 어느 도시에 실리콘 밸리를 만들 수 있지 않을까?

 

 

개발에 뛰어드는, 그 중에서는 모바일 개발자가 되기를 희망하는 개발 지망생들도 네이티브 앱을 학습하기 보다는 플러터나 리액트 네이티브를 공부해서 취업을 하려하는 것이 여러 블로그를 봐도 알 수 있다.

난, SDK를 만든다면서 유니티 자바스크립트로 크로스플랫폼 타겟은 개발할 줄 알지만

최종 엔드라인의 자바(코틀린)와 스위프트 프로젝트를 다룰줄 몰라서 배포는 정작 못하고

프로젝트 설정도 못고치는 개발자를 더러 봤다. 

기본기 없이 새로운 것만, 뜨는 것만 따라가다가는 언젠가 막힌다.. 

 

그래서 네이티브 언어도 학습 하기를 더 강력히 추천한다.

 

나는 이렇게 조언해주고 싶다. (앗 상꼰대다 튀엇)

개발자는 프론트든 백엔드든 10여년차를 지나기 시작하면 이것저것 다 어느정도는 할 줄 알아야 대화가 가능하고 로직을 가늠해서 설계할 수 있다.. (주 업무 스킬은 계속하되) 

언어나 영역에 제한을 두어서는 안된다는 것을.

 

[ 개발자의 여러모습 ]

백엔드 개발자 A : API 컨트롤러 클래스를 좀 고쳐야하는데.. 별 문제 없겠지 함수 내용만 바꾼거니까.

백엔드 개발자 A-1 : API 컨트롤러 클래스를 좀 고쳐야하는데.. 별 문제 없겠지 함수 내용만 바꾼거니까.
브라우저에서 테스트해보니 데이터 잘 나오네~ 오케이 끝. 

백엔드 개발자 B: API 컨트롤러 클래스를 좀 고쳐야하는데.. 별 문제 없겠지 함수 내용만 바꾼거니까.
브라우저에서 테스트해보니 데이터 잘 나오네~ 오케이 끝.... 이 아니지. 
브라우저만 접속하는게 아니라 앱도 API를 이용하니까..
음.. 어떻게 테스트하지?
모바일 개발자가 지금 자리에 없는데. 알아서 앱도 테스트 해보겠지~ 내가 모바일 개발자도 아닌데.

백엔드 개발자 C: 
API 컨트롤러 클래스를 좀 고쳐야하는데.. 별 문제 없겠지 함수 내용만 바꾼거니까.
브라우저에서 테스트해보니 데이터 잘 나오네~ 오케이 끝.... 이 아니지. 
브라우저만 접속하는게 아니라 앱도 API를 이용하니까..
음.. 어떻게 테스트하지?
아! 모바일 개발자 A님, 앱 좀 테스트해주세요~
..(다음날)
(에러나요~ 고칠게요~ 또 에러나요~ 고칠게요~ x100 반복)

백엔드 개발자 D:
API 컨트롤러 클래스를 좀 고쳐야하는데.. 별 문제 없겠지 함수 내용만 바꾼거니까.
브라우저에서 테스트해보니 데이터 잘 나오네~ 오케이 끝.... 이 아니지. 
브라우저만 접속하는게 아니라 앱도 API를 이용하니까..
음.. 어떻게 테스트하지?
아! 모바일 개발자가 최종 배포했던 마켓의 앱이나 디버그용 앱을 깔아서 먼저 좀 테스트해봐야겠다.
앗! 이전 버전의 앱이 크래시로 뻗어버리네!?
(아! 앱은 업데이트를 안하면 기존 사용자들은 계속 오류가 생길 수도 있겠구나! > 앱 강제 업데이트를 하자고 논의 해야할까? 반려되면 어떻게 해야할까? 소스 롤백을 하고 다른 방법으로 다시 구현해볼까 )
일단 서버쪽 소스를 고쳐보기전에 앱 쪽 소스도 잠깐 살펴볼까?
아! 기존에는 이렇게 변수를 사용했군. 이걸 앱은 업데이트를 안하면 절대 안되겠는데..
이걸 해결하기위해서는.... 흐음~ 



어떠한 개발자가 될지는 각자의 판단이다..
연수가 늘어날수록 개발자는 코딩만 하는 사람이 되어서는 안되고 Co-Worker로서 함께가는 일원이 되어야 한다..

 

자바를 해야하나요 코틀린을 해야하나요? -> 둘다

오브젝티브씨를 해야하... -> 스위프트! ㅎ

 

기본 네이티브가 자리잡아 오래도록 사랑받고 있는 Java, Kotlin, Swift 는 학습했으면 좋겠다.

그렇게 그 방식으로도 앱을 만들어 낼 수 있었으면 좋겠다. (모바일 개발자가 주 업무라면)

 

아이 그냥 공만 뻥뻥 때려서 골만 넣으면 되지 뭘 패스연습을 하고 트래핑 연습을 해? 

라고 할 수 있지만 

이건 인스턴트 라면을 사먹지 말고 라면면발을 직접 뽑아서 라면먹어 수준의 말도안되는 근원으로의 회기 같은게 아니다..

언급했던 네이티브 진영의 언어들은 아주 기본적으로 개발자라면 언젠가는 쓰이고 알아야하는 초석의 언어라고 생각한다.

 

현장 업무에서 편하디 편한 어떠한 크로스 플랫폼을 사용하더라도

수십만, 수백만(까지 되려나)의 개발자들이 선택해오고 익혀온 네이티브 언어(언급한 언어들은 다방면으로 쓰인다..)를 꼭 익혔으면 한다.

 

 

 

말을 줄이려했는데.. 한가지 더 쓰는김에 써보자면..

 

신기술을 회사에 도입안하면 시름시름 앓는 사람아

 

새로운 언어, 뜨는 언어를 현업에서 사용안하면 죽을 병에 걸려 시름시름 앓으며 쉬는시간, 점심시간때마다 회사와 동료 개발자들에게 내 팔자야~ 우리 팔자야~하면서 신세 한탄하는 개발자가 많다..

더러는 파이썬을 기똥차게 장착하고서 "자바"를 욕하는 후배들도 보았다.

(시간복잡도 공간복잡도 코딩의 간결화, 지원하는 함수 범위가 어떤게 더 좋으니까~ 같은 코딩테스트 층위의 논의는 논외로..)

 

허나 아직도 현장에서는 클래식ASP와 닷넷, C#도 많이 사용하고 있다.

그보다 더 많이 Java도 쓰이고 있다.

회사는 급변할 여유도 이유도 없다.

안전한 것이 제일이고, 그것이 이윤 추구를 할 수 있는 가장 쉬운 첫번째 방도이기때문이다.

다른 회사들의 도입 성공사례들을 빗대어 우리는 왜 못하나! 안하나? 로 공격적인 사람이 되기이전에

뜻이 맞는 동료들과 업무 외적으로 1시간이라도 따로 모여서 투 트랙으로 신기술을 도입할 수 있게 준비하고서 회사에 이바지하는게

본인의 자체의 스킬업을 위해서라도 이력서 한줄을 위해서라도 더 큰 메리트가 되지 않을까 싶다. 

ex) 업무 외 시간에 짬짬히 투자하여 회사의 신기술 도입을 성공적으로 이끌어 냈다 내지는 그런 도입에 힘쎴다. (실패했지만 ~~한 교훈을 얻었다 같은)

 

근무시간 내에 그런 신기술 도입을 시도한다는건 현실적으로 불가능하다. 

인원을 더 뽑아서 신기술 도입팀(?)이 전담하면 되지 않느냐?

4시간은 회사 업무, 나머지 4시간은 신기술 도입 이렇게 업무양을 조절하면 되지 않느냐?

하는것도 회사 입장에서는 굉장한 모험이다.

근무시간이 길다고 효율이, 매출이 늘지 않더라~ 하는 사례가 아무리 많아져도

대부분의 회사를 이윤 추구에 보수적으로 임할수밖에 없다.

내 월급만 주는 곳이 아니라 다른 모든 직원(+그 직원들의 가족들의 생계)들의 월급도 걸려있는 문제이기때문이다.. 

 

사실 정말 신기술 병(?)의 원인은

바로 "내가" 그런 기술 도입을 위해 "꾸준하게", "길게보고" 발벗고 나서서 팀을 꾸리고 전략을 짜고 리드해보려는 시도를 하지 않아서가 아닐까?

 

2024. 05. 추가

하지만 이랬던 나도 기술의 목마름으로 플러터를 학습하고 있다.

이미 알고 있는 Restful API 와 MVVM 패턴을 접목하여 BLOC 이라는 기술을 사용해서 Hello World 를 만들어보고 있다.. ㅎㅎ

 

 

긴글 쓰고보니 나도 이젠 늙었나 보다 싶다