Hong Cheung 
자본주의에서 벗어나기 위해 모든 것을 셀프 호스팅하는 방법을 고민해 왔는데, 정말 쉽지 않았습니다.
규모의 경제와 자본주의는 떼려야 뗄 수 없는 관계입니다. 회사가 클수록 더 저렴하고 더 나은 서비스를 제공할 수 있죠. 이런 독점 기업들에게 아니라고 말하기 위해서는 어느 정도 희생을 감수해야 합니다.
저는 시간을 들여 배우고 이것저것 만져 보았습니다. 정말 그만한 가치가 있기를 바랍니다.
지난 몇 주 동안 크로스 플랫폼, 로컬 우선 동기화를 구현하기 위해 수많은 스택을 시도해 보았습니다. 네이티브 플랫폼, RN Expo, LegendState, Flutter, RxDB, Powersync, Appwrite, MongoDB, Realm, Supabase 등이 포함됩니다. Brick, WatermelonDB, IndexDB 같은 것들도 살펴보았습니다. 또한 이 모든 솔루션의 차이점과 이들을 어떻게 조합할 수 있는지도 이해하려고 했습니다. 예를 들어 Expo에 LegendState와 Supabase/Appwrite를 조합하기, Flutter에 Supabase + Powersync/ElectricSQL을 조합하기 등입니다.
결국 깨달은 것은, 어떤 플랫폼을 쓰든, 예를 들어 Flutter(Google), RN(Facebook), SwiftUI, Kotlin 등 무엇이든 간에 여전히 플랫폼에 크게 의존하게 된다는 점입니다. 그들이 유지보수를 중단하거나, 요금을 부과하거나, 정책을 바꾸기 시작하면 저는 인질이 됩니다. 특히 제 시간을 들여 Apple을 위해 개발하고, 그들의 SwiftUI로 훌륭한 앱을 출시해 App Store를 키워 준다면, 저는 그저 그들을 위해 일하는 기분이 듭니다.
어떤 개발자들은 그냥 이를 받아들일 거라는 것도 압니다. 그들은 빠르게 MVP를 출시하기 위해 자신에게 편리한 것을 사용합니다. 하지만 저는 여전히 그러고 싶지 않습니다. 편리하고 확장 가능하며 상대적으로 비용 효율적이라는 이유만으로 Flutter와 Firebase를 쓰고 싶지 않습니다. Google이라는 회사가 우리를 바보 취급하듯 프로파일링하고 추적해서 우리에게서 이익을 챙기는 방식을 외면하면서 말이죠.
따라서 제가 내린 결론은, 유일한 해답은 웹이라는 것입니다. 늘 그래 왔던 것처럼요. 웹 기술은 안정적이고, 그들의 독점 규칙을 따르지 않는다는 이유로 제 프로젝트가 갑자기 중단될지도 모른다는 걸 알기 위해 이용약관 수십 페이지를 읽을 필요도 없습니다.
결국 크로스 플랫폼 프레임워크가 어차피 컴파일을 필요로 한다면, 웹 앱을 먼저 만들고 Capacitor로 감싸서 App Store와 Google Play Store에 출시하는 것이 완벽하게 합리적입니다. 어차피 그쪽은 2순위로 취급되어야 하니까요.
기기 성능도, 기기 API도, 멀티스레드도 애초에 문제가 아니었습니다. 그것은 자존심의 문제이자, 큰 것을 이루겠다는 목표의 문제입니다.
abcd.com은 google.com과 같으며, 저는 바로 거기서부터 시작해야 합니다.