이번에 기여를 하게된 오픈소스가 새로 생겨 소개하고자 한다.
hot-updater라는 library인데, 기존에 같은 일을 하던 유명한 서비스가 Codepush다
git - gronxb/hot-updater
docs - hot-updater
CodePush
쉽게 풀어보자면
react-native로 만든 앱을 앱스토어나 플레이스토어에 심사를 통해 배포 성공
그 이후 만약 업데이트가 생긴다면, 그 업데이트 내용을 다시 앱스토어와 플레이스토어에 심사를 받고 승인이 날 때 까지 기다린다..
만약 이 상황에서 버그를 찾았거나, 다른 수정 사항이 생길 경우 심사하던 중 다시 심사를 해야하는 경우가 생긴다면, 엄청난 시간을 소요한다.
기존에 React Native CodePush는 마이크로소프트가 만든 라이브러리로 React Native의 특징을 활용하여, 앱스토어 심사 없이 앱을 배포할 수 있게 도와준다.
앱을 켰을때 업데이트 사항이 있다면, 해당 업데이트 코드를 앱스토어가 아닌 네트워크를 통해 모바일 환경에 넣는 것이다.
Flutter vs React Native 했을 때 CodePush 덕분에 React Native가 선호되는 경우도 더러 있다고 한다.
하지만 microsoft에서 갑작스럽게 App center 종료 발표를 하였는데, CodePush를 사용하던 개발자들은 이에 대한 대안을 구해야만 한다.
그 대안들중 하나가 이 hot-updater이다. 지인이 개발 하는 오픈소스이며, 이에 기여하고자 한다.
나는 RN을 사용하지는 않아서, 콘솔부분인 웹 부분만 기여하는데 이 라이브러리에 주목하게된 이유는 다음과 같다.
- 2025년 3월 CodePush 서비스 종료
- 기존 대안인 EAS Update는 Expo에 특화되어 있고 비용이 비싸며, 다른 SaaS 솔루션들도 고정 비용 구조를 가지고 있지만, hot-updater는 사용량 기반 과금으로, 더 합리적인 비용 구조를 제공한다.
- 자체 인프라에 구축 가능하다는 점(보안 굿)
웹 콘솔 중심의 관리: 콘솔 부분이 웹 기반으로 되어있어서 내가 기여할 수 있다..ㅎㅎ 아마 기존 app center의 역할이지 않나 싶다.오픈소스라는 점, 난 오픈 소스 생태계가 코딩에 있어서 정말 중요하다고 생각한다.
실제로 가파르게 star가 오르는 중
solid.js ...???
solid.js ...???
일단 첫 번째로 내가 기여하고자 했던 console(web)부분이 react가 아닌 solidjs로 구성되어 있다.
JSX문법을 사용하는 JS 라이브러리인데, 특이한 점은 signal이라는 개념을 사용한다는 것
signal은 react에서 state가 바뀌면 컴포넌트가 통째로 다시 렌더링되는데 반해, signal은 값이 바뀐 부분만 정확하게 업데이트한다. 가상 DOM 또한 사용하지 않는다.
실제로 코드가 react랑 많이 닮아 있어서 반나절 정도 보고 docs좀 살펴보니 금방 적응할 수 있었다.
나는 react개발자가 아닌 frontend개발자를 꿈꾸기에 새로운 기술 스택도 경험해볼 겸 도전해보기로 했다.
기여한 내역
한 일주일 정도 쭉 했던 것 같다. 트러블 슈팅 내역을 좀 톺아보자.. ㅜㅜ
PR
변경 사항이 있어도 Save를 눌렀을 때, 아무런 반응이 없었다. 로딩 아이콘을 추가했다.
어려운 건 딱히 없었던 것 같다.
api를 호출할 때마다, 화면이 깜빡거리는 현상이 있었는데 이게 UX를 많이 해쳤었다.
solid-router 0.15버전부터 데이터를 캐싱하는 query를 지원하는데, 프로젝트에서 사용하던 버전이 0.14.1 버전이어서 @tanstack/solid-query를 사용해서 해결했다.
시간을 가장 많이 쓴 변경 사항이었다.
기존에는 각 열을 클릭 했을 때, 페이지를 이동하는데, 특히 sidebar가 켜진 상태에서 밖으로 나갔을 때, 사라지는 animation이 없이 바로 사라졌었다.
이는 사용자에게 하여금 급격한 화면 전환으로 UX를 저하시키는 요소로 판단하고, 이에 대해 많이 고민했었다.
열을 클릭할 때, URL의 param을 가져와서 데이터 get, push에 사용하는데 이를 유지한 채로 해당 문제를 고쳐야만 했다.
오픈 소스나 라이브러리 개발에 있어서, 나는 새로운 기능 개발이 혁신적인 변화를 이끌어내는 정도가 아니라면 시존 시스템의 변화를 야기해서는 안된다고 생각한다.
내가 바꾼 소스 코드 하나가 사용중인 모든 사람들의 소스 코드 변경을 유발할 수도 있기 때문이다.
결국 나는 sidebar가 열려 있는 상태인지를 판단하는 signal을 도입하고, 밖으로 나와질때는 0.5초의 delay만을 필요하게끔 수정하였다.
페이지가 바뀌며 컴포넌트 자체가 unmount되는 상황이기에, 어쩔수없이 0.5초 delay vs animation 미출력이 사용자 경험에 있어 어떤 것이 더 안좋을까에 대한 가치 판단을 하다가 결국 0.5초 Latency를 주기로 결정했다.
별 문제가 없었는지 merge 되었따.
기존에는 HMR(Hot Module Replacement, 코드 수정하면 새로고침 없이 바로 반영되는 그것 ㅎㅎ)가 적용이 안돼있어서, 코드 변경하고 build하고, 변경하고 build하고 했었는데 HMR이 업데이트 되면서 console 개발시 Mock data를 사용하게끔 변경되었다.
개발하는데 네트워크 지연 시간이 없는 것은 영 맛이 안나서 Latency를 추가했다. (진짜 API 쓰는 것처럼 느낌나게 하려고..!) 0.5~0.7초 랜덤 시간의 지연을 주니 좀 더 네트워크를 사용하는 듯한 느낌이 났다. (DX 향상!)
필요 없는 await가 있었는데 그냥 merge 시켜줬었다. 빠르게 파악하고 await를 지워서 다시 PR을 날렸다.
결론
다들 본업 하시면서 틈틈이 개발하시는 분들이 많아서 오픈소스계는 늘 인력이 부족한 상태이다
그래서 여러분도 이렇게 작은 거부터 시작해서 PR 한번 날려보시는거 정말로 추천한다.
내가 한 것처럼 UX/DX 개선이나 버그 수정 같은 것도 Maintainer들이 하나하나 잘 봐준다.
(진짜 맛만 봐보라니까요)
