누군가에게 알려주기 보다는 나 스스로 정리 하며 언젠가 다시 사용할 때를 대비하는 글을 작성할것이다.

참고자료 : 내 경험 + AI

갑자기 웬 솔루션?

사실 별 이유는 없다.
그저 한 번씩 오는 개발자들의 사이드 프로젝트 증후군 같은게 왔을 뿐이고 어떤 주제로 개발을 할까 고민을 했을뿐이다.

예전에 매번 혼자서 사이드 프로젝트를 할 때 로그인 만들고, 푸시 좀 붙여서 푸시 좀 받다가, 화면 좀 만들어보고 접는 프로젝트가 많았다.

이렇게 하나 만들다 접고 하는 과정을 할거면 모듈식으로 이런 기능들을 하나하나 미리 개발을 해두고 후에 다른 프로젝트에 그대로 붙이거나 해서 하면 되지 않을까?

라는 생각에서 시작하게 되었다.

근데 왜 푸시?

나는 iOS 개발자이다 보니 원래는 iOS에서 SwiftUI로 그리는 그래프 그림을 프레임워크로 개발해보고 싶었다.
그외의 토스트 메시지나 이디케이터 같은 UI적인 뭐 그런것들을 프레임워크로 묶어서 나만의 Package로 만들어볼 생각이었다.

근데 그러던 중에 프로젝트를 해보고 싶어졌고 서버도 사용하고 BO도 만들고 하는 뭐 그런걸 해보고 싶었을 뿐이었다.

그러다보니 어? 매번 골머리 썩던 푸시를 그냥 솔루션으로 만들어서 내 프로젝트 할 때 마다 구현하는게 아니라 그냥 솔루션으로 모든 내 사이드 프로젝트의 푸시를 하게 하면 되는거잖아? 싶어서 시작했다.

(뭐 그러다 사이드 프로젝트 수준에서 푸시 솔루션 쓰고 싶은 지인이 있다면 공유해도 상관 없는거니까~)

작명

• 예전에 어디서 본건데 프로젝트의 이름이 너무 멋드러지고 신경을 많이 쓰면 끝까지 잡고 있는게 힘들다고 했던 분이 계셨다.
  뭐 나도 대충은 비슷한 생각이다. 이런 이름 신경쓰고 고민하고 이럴바에 일단 만들어 봐야 하니까.. 그래서 이름은 이렇게 짓기로 했다.

SPMS : Stein Push Message Service

• Stein이 뭐냐고 묻는다면 그냥 내가 꾸린 개발 프로젝트 팀의 팀명 정도라고 생각하면 된다. (팀장: 나, 팀원: 1명(나))

기술 분석

당연하게도 프로젝트를 시작하기 전에 무슨 기술을 써서 어느 수준까지 만들어야 하는것에 대한 고민을 하는 부분부터 시작했다.

1. Server 개발

• 환경 : NAS Docker
  - 푸시 서버가 돌아갈 환경부터 정했다. AWS를 사용해서 본격적으로 해볼까 했는데 그거보다는 집에 남아있던 NAS를 활용해서 일단 해보고 그 이후에 변경하기로 했다.

• 언어 : C# .NET 9.0
  - .NET, Node, Spring 등 이 있었는데 결론은 종종 취미로 건들던 .NET으로 하기로 했다. 이왕 하는거 최신 버전으로 사용하기로 했고 10.0 이 나왔던데 25.11월에 나온 버전이라서 그건 아직 너무 이른거로 생각해서 9.0으로 정했다.
  

2. Office 개발

• 기술: React + Vite
  - FO / BO 둘다 그렇게 크게 고난도의 기술이 필요한건 아니어서 잘 사용은 못하더라도 레퍼런스 많고 도와줄 지인이 많던 React로 하기로 했다. Vite는 요즘 좋다고(잼미니가 추천해줌) 해서 같이 추가 했다.
• 언어: TypeScript
  - JS, TS 딱히 좋아하지 않고 전문 분야도 아니지만 RN 개발을 하면서 TS 를 해본 경험이 있어서 이거로 하기로 결정했다.
  

3. Framework 개발

• 기술: iOS(Swift, XCFramework), Android(예정)
  - 뭐 본업이다 보니 이거로 정했고 안드로이드 쪽은 아직은 어떻게 할지 생각은 안했는데 저거 또한 내가 할 생각이기는 한데 당장에 할 생각은 없다.
  

4. Middleware 개발

• 메세지 큐: RabbitMQ
  - 사실 이거 잘 모른다.
  근데 이전에도 푸시 작업했었는데 대량 발송을 할 경우 트래픽이 몰리거나 해서 서버가 뻗는 경우가 있고 이럴때 직접 개발을 하면 어려웠던걸로 기억을 한다.
  그런데 이걸 사용하면 큐를 사용해서 안정적으로 처리하기가 쉽다고 해서 사용했다. (kafka 도 있었는데 이건 NAS Docker에서 하기에는 너무 무거움..)

• DB: MariaDB
  - 이거도 고른 이유는 이전에 한 번 다뤄본 경험이 있고 실무에서도 이걸 사용해서 하는걸 많이 보기도 했고 MS SQL 서버 같은 것은 .NET 과 잘 어울릴수 있지만 리소스를 많이 먹어서 제외했으며 마리아는 다른걸 다 떠나서 일단 가볍다
  

5. DevOps 개발

데브옵스라고 해도 될지는 모르겠지만 일단 체계는 갖춰야지.. 라는 생각에 해본것이다.

• SCM: Gitea
  - GitHub 이 있는데 왜 Gitea를 했냐고 물어본다면 내 자료의 모든걸 다 내가 관리하고 소유하는 그런 생각을 가지고 있었을 뿐이다.
  그럼 깃랩은 왜 안했냐 라고 한다면 걔는 무거워서 램을 많이 잡아 먹기에 제한적인 상황에서는 깃티가 좋아보여서 깃티로 진행했다.

• CI/CD: Jenkins
  - 로컬에서 소스를 수정하고 깃에 올려서 소스 관리를 하면서 NAS에는 따로 수동으로 올리고 하는건 너무 비효율적이라 생각했다.
  그렇기에 깃에 브랜치에 맞게 푸시하면 알아서 젠킨스를 통해 NAS에 코드 복사하고 빌드하고 배포까지 하게 자동화 라인을 구축했다.

일단 구축은 완료

• 뭐 뒤 Part에서 구축하면서 겪게 된 시행착오들을 보여주겠지만 아래 화면처럼 아주 잘 빌드가 된 모습을 볼 수 있다.
  

참고자료

• 구글의 어느 멋진 개발자분들의 블로그
• 구글의 잼미니
• 이전에 해왔던 내 머리속 어딘가 있는 지식

기타

당연 틀린 부분 지적은 감사하나 비난은 정중하게 사양하겠다.