… REDACTED …

저는 현지 분위기를 경험하고 나서 내린 결론이, 현지에서 일을 구하기보다는 제 테크트리를 완전히 digital nomad로 전직해야 해야겠다는 결론을 내렸습니다. 그래서 저는 그 쪽으로 노력하고 있구요.

지금 psgm 프로젝트를 되돌아보니 제가 RN을 사용하겠다는 결정을 한게 큰 실수라고 봅니다.

1. JS라는 언어 자체가 좋은 언어가 아님
2. 무거움: 깡통 앱 크기 200mb 초과, 플러그인 의존 패키지 문제도 큰 문제
3. 네이티브 API에 접근하기 힘듦: 특히 calendar를 RN으로 구현하는 것 너무 비효율적임
4. OS 차이점 추상화에 많은 시간을 할여해야 함
5. 가장 기본적인 OS 기능(svg 렌더링, fs 접근, asset 시스템 등)이 코어에 없는 둥, 거의 모든 기능이 플러그인으로 존재: 이게 결국 다 나중에 tech debt로 작용하게 됨
6. psgm의 요구사항은 일반적인 앱이 필요한 API보다 더 많은 것을 요구함: 특히 bottom sheet 사용이 큰 문제
7. 웹 프래임워크에 어거지로 끼워넣기 위해 만들어진 도저히 비효율적인 RN API의 추상화 개념: reducer, state, component reentrant 문제 등 (문자인증 UI 타이머 구현하는 것이 막타였음)

이런 대기업(페이스북) 잔반인 RN를 사용하기 보다, 차라리 전통적인 방법인 OS별로 앱을 따로 구현하는 것이 더 좋아 보입니다. 좋은 경험 했습니다. 제가 PSGM에 손을 다시 댈 열정이 생기면(개인적인 바램은 6개월 안에) 앱은 Android Studio로 Kotlin 사용해서 다시 개발 시작하고, 서버는 기존 방향 그대로 Spring 프레임워크 고수하는 것으로 진행하겠습니다. 제 개인적인 입장은 Kotlin과 Swift는 애플과 구글 제품에만 국한된 쓸모없는 언어이지만, 모바일 개발에 발을 담그려면 어쩔 수 없는 선택인 듯 합니다. 탈 RN이 답이라면 견뎌야 할 고통인듯.

탈 RN을 통해 바라는 점은 …

1. 네이티브 접근 (특히 WebRTC, calendar)
2. 추상화, UI 문제에 시간 낭비하지 않기. 스타일, 테마 같은거에 일단 신경쓰기 싫음
3. 플러그인 지원 걱정 안해도 됨. 차라리 우리가 모든걸 다 직접 구현하면 유지관리 편할 듯? 하지만 코드를 많이 만들면 그만큼 스코프가 커지는 문제는 여전히 존재 (“no free lunch”)
4. 기기 효율: 앱 크기 작음(빌드시간 단축, 배포 비용 단축)
5. 대부분 네이티브로 해먹을 수 있기를. 적은 외부코드 의존. 이거 없다 저거 없다, 좋은 플러그인 찾아 테스트하는데 시간 할여 안하기를

저는 Kotlin 책 하나 사서 좀 눈으로 끄적거리는 것에서 시작하겠습니다. 안드로이드라는 OS의 전반적인 지식은 좀 있어도 Kotlin을 다루는데 능숙하지 않아서 RN 네이티브 모듈 다루는데도 이미 어려움을 겪고 있었음.

… REDACTED …

COLOPHON

Signed-off-by: David Timber
Acked-by: 0