[Swift] 1인 앱 개발로 사용할 기술 스택 및 서비스

개요

요즘 개인 앱으로 어떤 스택이 가장 빠르며 쉽고 효율적일까를 계속 고민하고 있다.

현재 메인 앱에서 사용하는 스택으로는 Swift(UI), AWS, MongoDB, Typescript Express, Firebase authentication blablabla

이렇게 사용하는 서비스만 5~6개 정도가 되는데, 기존에는 그냥 이렇게 해왔으니까 크게 불편함을 느끼지 못했다.

 

하지만 요즘 인공지능이니, baas(Back end as a service)니 하면서 너무 많은 정보들이 머리에 입력되다보니

무엇을 메인으로 가져가야 할 지 감이 잘 안 잡히는 상황이다.

 

그래서 지금까지 앱을 만들고 출시하면서 사용했던 서비스 및 기술 스택을 좀 정리하고 나 스스로도

무엇이 내게 가장 잘 맞는지 한 번 알아보려고 글을 직접 작성하게 되었다.

 

프론트, 백, 디비, 부가적인 서비스등을 순서대로 한 번 나열해보겠다.

작성하고보니 글이 굉장히 길다.

Front-End

SwiftUI

현재 나의 주력인 SwiftUI이다. 이걸로 몇년을 개발해왔기도 하고, 구글 플레이스토어

개발자 아이디가 삭제되는 바람에(ㅠㅠ) 굳이 안드로이드 플랫폼을 고려해야하나라는 생각이 들어

따로 플러터, RN, Native Android는 고려하지 않았다.

 

스위프트의 장점이라면, 정말 직관적이다. 내가 만들고 싶은 UI는 그게 뭐가 되었든 

정말 어렵지 않게 구현해낼 수 있다. 

 

SwiftUI초기에는 미구현 된 것들이 너무 많아 UIViewController를 Representable을 상속받아 

UIView에 있는 것들을 커스텀해서 만들기도 하고 꼼수를 굉장히 많이 썼는데,

iOS버전, XCode 및 Swift 버전이 올라가며 많은 부분들이 자체 프레임워크 및 패키지로 사용할 수 있게 되었다.

 

다만 단점아닌 단점도 있는데, 생각보다 서드파티 라이브러리가 다른 프레임워크들에 비해 부족한 느낌이다.

플러터, RN, Kotlin은 서드파티 라이브러리로 원하는거 그냥 다 가져오고 생태계도 커서 종류 자체가 굉장히

많다고 느꼈는데, SwiftUI는 아직 4~5년 역사밖에 되지 않았기도 하며 그냥 뭔가 많이 없다. 

 

대표적인 서드파티 Alamofire, Kingfisher을 제외하면 사실 그렇게 가져다 쓸만한 것들이 없다.

이건 내가 못찾은건지, 아니면 다른 프레임워크들도 비슷한데 그냥 남의 떡이 더 커보이는건지 모르겠다.

 

또, 한글로 된 레퍼런스가 많이 부족하다. 본인은 영어가 충분히 되지만, 한글로 읽으면 3분 걸릴걸 영어로 5분이상 읽어야되니

은근히 스트레스가 크다.

 

본인이 아이폰 앱에만 관심이 있고 애플 사용자들을 타겟팅한 기막힌 아이디어가 있다면, SwiftUI를 강력추천한다.

Skip

요즘 내가 관심이 있는 프레임워크이다. 기존에느 크로스플랫폼을 기획하게 된다면 Flutter를 사용하려고 했는데,

SwiftUI코드를 그대로 사용해서 안드로이드 네이티브 앱을 제작할 수 있다는 말에 Flutter를 후순위로 밀어두고

예의주시하고 있는 프레임워크이다.

 

포스팅을 몇개 해두긴 했는데, 생각보다 버그도 많고 부족한 기능이 많아보여 일단은 보류해둔 상태이다.

무엇보다 서드파티 패키지가 전무하기 때문에 모든걸 직접 만들어야한다.

 

가령 내가 특정 데이터베이스를 사용하는 패키지를 사용하려고 치면, 안드로이드에서 그에 맞는 패키지 설치

Swift에서 그에 맞는 패키지 설치, 코드를 분리하여 따로 작성. 

 

위의 과정을 거쳐야하기 때문에 여간 골치아픈게 아니다.

그래서 현재는 이들의 개발행보가 어떻게 이어지는지 깃허브 즐겨찾기 이후에 모든 알림을 받으며 지켜보고 있다.

Flutter

아직은 사용하고 있지 않고 후보에서도 후순위로 밀려났지만, 언제든 빠르게 치고 올라올 가능성이 있는

프레임워크이다. 최근 Flutter에 대한 수요가 급증했다고 보여지고 있는데,

크로스플랫폼을 디폴트로 가져가는 스타트업 및 서비스들이 많아졌다는 이야기 같기도 하다.

 

하지만 1인 개발자로 활동하며 이 부분은 확실히 짚고 넘어가야한다고 생각한다.

나는 어느 플랫폼에 더 많은 시간을 투자할 수 있는가?

둘 다 할거라면 양쪽 앱 심사의 압박 및 업데이트 압박을 견뎌낼 수 있는가?

 

하나의 플랫폼에만 신경을 다 쓰더라도 앱 심사, 버전 관리, 스토어 관리, 결제수단 관리 등등 신경쓸 부분이 굉장히 많다.

그런데 이걸 양쪽 모두 관리하려고 한다? 내 생각에 그 스트레스는 이루 말할 수 없을 것 같다.

 

물론 양쪽 다 하고 해낸다면 좋겠지만, 본인은 오히려 하나에 집중하는 편이 더 좋다고 생각한다.

그게 내가 SwiftUI만을 사용하는 이유이기도 하다.

 

또한 플러터를 사용해본 적은 있지만, SwiftUI를 사용할 때 만큼 빠른 생산성을 보장할수도 없기 때문이다.

Swift는 이제 어지간한 보일러 플레이트 코드는 복붙 할 공간을 마련해두었고, 레퍼런스가 없어도 

웬만한 UI는 전부 구현이 가능하기 때문에 이 속도를 제칠만큼 Flutter를 사용할 이유는 없다고

생각이 된다.

결론: 나는 추후에 사람이 추가되기 전까지 SwiftUI를 사용해 아이폰 앱만을 만들어낼 것 같다.

Back-End

Back end에 관해서는 잘 모름. 말도 안되는 소리가 나와도 이해 부탁

Typescript(Javascript) Express

사실 서버 관련 프레임워크 및 패키지는 내가 잘 모른다. 그래서 타입스크립트랑 자바스크립트를 하나로 묶는게 맞는지는

모르겠지만, 내가 처음으로 서버를 구축하면서 사용했던 언어이다. express를 사용했다.

 

이 녀석을 쓰면서 가장 열받았던 건 Object타입이다. 처음에는 타입스크립트도 안쓰고 쌩 자바스크립트로 코드를 썼는데,

함수 리턴값 타입이 뭔지 모르니까 계속 에러나고 undefined 나오고 모니터 박살내고(는 구라)

 

여튼 쉽지 않은 언어라고 생각한다.

그래서 찾아보다가 타입스크립트를 발견하게 됐는데, 뭐 조금 나아지기는 했지만 기반이 자바스크립트인지라

아직 잘 모르겠다. 그래서 아직도 any로 캐스팅해서 되면 쓰고 안되면 다른거 찾아보고 하고 있다.

 

장점이라면 역시 웹 개발하던 사람들은 어렵지 않게 쓸 수 있다는 점이다. 애초에 풀스택 웹 앱을 만들면 

html, css, js만으로 전부 만들 수 있으니까 그렇게 놀라울일도 아니다.

 

단점이라면 타입 타입 타입 타입 아직도 어렵다 이놈의 타입은

Go

최근에 좀 매력을 느낀 언어이다. 멀티 쓰레딩도 하고, 포인터도 쓰고 굉장히 low-level한 언어처럼 보이지만, 

그렇게 복잡하지도 않다. 오히려 너무 단순해서 어렵다고 하면 이해가 될 정도다.

 

다만 아직 튜토리얼 단계 정도의 코드밖에 써보지 않아 데이터가 부족한 상황이긴하다.

그럼에도 자바스크립트랑 go랑 뭐쓸래 하면 닥후닥후닥후

 

지금 배포 준비중인 서비스 하나에 go 서버를 두었는데, 좀 더 업그레이드 해보면서 데이터를 쌓아보도록.

 

파이썬은 안써봤다

Database

Firestore

이걸 파이어베이스로 한 번에 묶어서 쓰는게 맞나 싶긴했는데, 일단 파이어스토어에 대해서만 얘기해보도록 하겠다.

우선 이 녀석은 굳이 서버를 두지 않고 클라이언트단에서 데이터베이스를 조작할 때 쓰면 좋다.

 

한마디로 정말 단순한 CRUD기능이 필요할 때 사용하면 좋다는 이야기다.

근데 Table Join이 필요한 순간 파이어스토어는 옵션에서 제외해야할 수도 있다.

 

기본적인 쿼리는 지원하지만, 데이터의 결과를 변형해서 만들어내고 싶을때는 적합하지 않다.

현재 메인 앱 초반에는 파이어스토어로 데이터베이스를 가져가려고 했는데,

컨텐츠 데이터와 글쓴이 데이터를 하나로 묶으려면 리스트 아이템 하나마다 컬렉션을 전부 조회해야했던 기억이 있다.

 

쿼리가 조금 효율이 안좋을수도 있었겠지만, 테스트로 쿼리 몇번 돌렸는데 10원 정도 과금된걸 보고 빠르게 

MongoDB로 옮기게 되었다. 기술적인 부분은 잘 모르겠고, read, write만 할거라면 파이어스토어 나쁘지 않다고

생각한다. 다만 생각보다 많이 비싸다.

MongoDB

몽고디비를 사용한 이유는 따로 없다. serverless instance를 제공해서 사용량만큼 과금이 된다는 점이 마음에 들어

선택했다.

몽고디비 역시 클라이언트에서 사용할 수 있지만, 현재 테스트앱, 관리자앱, 크리에이터용 웹페이지까지 있다보니

백엔드 파트에서 작성한 타입스크립트로 만든 애플리케이션으로 데이터베이스를 관리하고 있다.

 

뭐 나쁘지 않고 무난무난하다. 관계형 데이터베이스에 비해 편한건 사실이지만, 컬렉션을 하나 새로만들거나 컬럼이 추가되면

관리가 조금 어려운 것도 사실이다. 또 쿼리가 우리가 아는 SQL쿼리가 아니기 때문에 처음에 익숙해지는데 시간이 좀 걸릴 수 

있다. modifier, builder함수로 쿼리를 작성하거나, aggregate로 데이터를 생성하는 방식이다.

 

기존에 다른 noSQL사용해본 사람들은 나쁘지 않게 사용할 수도 있을 것 같다.

무엇보다 처음에 작성한 정액제가 아닌 종량제에 초기 설치비용이 없다는 점이 가장 큰 메리트 같다.

Pocketbase

자 이제 좀 내가 원래 포스팅 하려고 했던 녀석이 나왔다. (Supabase도 있다.)

baas라고 back end as a service라고 하는 녀석중에 한 놈이다.

 

이게 어쩌다 알게 됐냐, 니꼴라스 형 유튜브 보다가 알게 됐다. 그리고 엄청나게 충격을 먹었다.

내가 지금까지 6개월이상의 시간을 걸쳐 만든 서버가 이걸로 다 퉁칠 수 있다고?

 

포켓베이스는 프레임워크라던지 언어라던지 패키지 같은 개념이 아니다. 이건 프로그램이다.

그래서 이 녀석을 실행하면 프로그램이 8090포트에서 실행되며 8090포트에 api request를 날릴 수 있다.

이 api request는 데이터베이스의 내용을 기반으로 한다.

 

또 관리자 페이지가 있어서 현재 데이터베이스 내용을 웹 상에서 확인하고 조작할 수 있다.

authentication도 지원한다. 

포켓베이스 자체 기능이 부족하면 go, js등으로 커스텀해서 서버를 열수도 있다.

그리고 무료이다

 

허허......

파이어스토어나 수파베이스와는 다르게 도메인을 구매하고 서버를 호스팅할 인스턴스를 구해야하긴 하지만, 

그걸 감안하더라도 미친 효율을 보여주는 서비스이긴하다.

 

심지어 여태까지 내가 만든 express+mongodb보다 더 정교한 트랜잭션을 보여주는 것 같아서 너무 속상하다.

오픈소스 프로젝트로 누구나 무료로 사용할 수 있지만, 이쪽 팀에서는 제품단계에 웬만하면 쓰지 말라는

경고가 있긴 하다.

 

나는 서버 인스턴스가 있고 도메인이 존재한다면 저 경고 무시하고 무조건 포켓베이스 쓰라고 하고 싶다.

Supabase

포켓베이스와 비슷한 형태지만, 프로그램은 아니고 파이어베이스와 같은 서비스다.

또한 정액제 유료이다. 무료플랜이 있긴 하다. mau 5만 미만, storage용량 몇 미만 뭐 미만 이렇게

조건이 달려있지만, 출시 초기의 애플리케이션이 장착하면 어지간해서는 무료 플랜으로 다 커버가 될 것 같다.

 

또한 가격이 그렇게 비싸지도 않기 때문에 나중에 사용자가 많아지더라도 충분히 사용을 고려해볼만하다.

 

일단 포켓베이스의 경우에는 api기반으로 request, response를 통해 데이터를 조작하는 방식이었다면

이건 supabase가 제공하는 sdk로 (driver 같은..?) supabase에 연결해 데이터를 조작하는 방식이다.

 

물론 pocketbase도 데이터에 연결하는 방법이 있긴 하지만, api call로 처리하는게 훨씬 깔끔하다

생각이 든다.

 

자 그래서 supabase같은 경우에는 authentication, storage, database 등을 제공하며 데이터베이스는 

PostGres, 저장소는 AWS S3, authentication은 거의 모든 플랫폼을 준비해두었다.

Pocketbase vs Supabase

그래서 현재 새로운 프로젝트는 포켓베이스와 수파베이스 둘 중 하나를 선택해서 계속 사용하려고 하는데,

본인은 수파베이스를 선택하기로 했다.

 

포켓베이스는 정말 좋지만, 아직 레퍼런스가 많이 부족한 느낌이다. user authentication도 swift에서 하는 방법을 찾아보다가 결국 놔버렸고, storage도 s3를 차용하거나 하는게 아니라 로컬 스토리지에 저장해버리는거라 ec2같은 클라우드 인스턴스 사용하는

개발자에게는 조금 버거울 수도 있다는 생각이 든다.

 

반면 수파베이스는 유료이기는 하지만 초기 프로젝트에서는 무료 플랜으로 충분히 커버가 될 정도의

사용량을 제공하며, 꽤 생태계가 크고 애용하는 사람들이 많은 서비스다보니 레퍼런스가 굉장히 많다.

 

nextjs로 웹에만 많이 사용하는 줄 알았는데, 생각보다 Swift에서 Supabase를 사용하는 사람도 많아

본인이 쓰기에도 어려움이 없을 것 같다는 생각이 든다.

 

혹시나 본인이 웹 개발을 하고 있다면 nextjs + supabase를 강력하게 추천한다.

기타 서비스들

EC2

뭐 별건 없고 서버를 돌리기 위해 AWS에서 사용중이다. 서버 환경 구축하는 부분이 너무 어려웠는데,

한 번 설정해두니 크게 손댈일도 없고 생각보다 간단해서 다행이다.

nginx로 서비스별 도메인 라우팅 중이고, pm2로 애플리케이션 실행중이다.

S3

이미지를 좀 많이 다루는 서비스라서 S3 버켓 만들어 사용중이다.

Firebase DynamicLink

다이나믹 링크........ 내년 8월이면 사라질 기능이다. 굉장히 잘 쓰고 있는데, 또 내가 직접 만들어야한다니 너무 

막막하다. 혹시나 다른 대체 서비스를 알고 계신분은 알려주세요 ㅠㅠ

Firebase Authentication

수파베이스를 진작 알았다면 사용하지 않았을 파이어베이스 인증. 사실 수파베이스를 알았으면 지금 

서버에 있는 스택 대부분 날아갔을지도 모른다.

Firebase Crashlytics

굉장히 좋은 서비스다. 앞전에 포스팅을 했었는데, 앱 심사에서 알수없는 Crash가 계속 발생해 2주 넘게 리젝을 먹었던 경험이 있다.

나는 도저히 크래쉬가 발생하지 않고, 동생, 지인 기기에서 전부 테스트해봐도 재현이 안돼서 

막막해하던 와중에 발견해서 잘 써먹고 있다.

Firebase Analytics

아직 데이터가 많지는 않지만 사용자들의 앱 사용 흐름을 대략적으로나마 확인할 수 있게 해주는 녀석 고마운 녀석

이렇게 써놓고 보니 파이어베이스에 있는 것들은 꽤 많이 쓰네..?

 

여기까지 새벽에 작업하다가 지금까지 내가 사용해온 스택 및 서비스들을 한 번 정리해보았다.

마무리는 어떻게 해야하는걸까.

 

여기까지