도입, 개발하고자 한 계기
2024년 초, 단체를 통해 월 1회 유기견/유기묘 보호소에 봉사를 다니기 시작했고, 05 월 즈음부터 보호소의 관리 서비스를 만들고 싶다는 생각이 들었다.
우선 내가 할 수 있는 일 중 보호소에 뭐라도 더 실질적인 도움이 되고 싶었고, 보호소의 관리자들도 모두 현생을 살아가는 일반 직장인이었기에 이분들이 조금 더 편하게 보호소의 작은 부분들을 관리할 수 있는 서비스를 목표로 했다.
기획
보호소 내 견사/묘사 관리, 스케쥴 관리, 기부금 관련 엑셀 파일 관리를 우선적으로 고려했다.
기부금 관리의 경우 은행 API에 연동하는게 가장 좋은 방안이었으나, 그러기 위해서는 기업명의의 계좌와 API 접근 권한이 필요했다.
이러한 이유로 기능을 제외할까 생각도 했지만, 그러기에는 수작업의 번거로움과, 시스템으로 구현했을 때의 이점이 충분할 것으로 판단하여 관리자 측에서 엑셀로 다운받은 파일을 업로드하면 적절하게 formatting 해서 제공하는 형식으로 구성하려 한다.
보호소 내 강아지/고양이의 경우에도 결연후원 목록을 별도로 제공하는데, 그 과정에 있어 변경사항이 있는 경우 일일히 후원자 목록과 아이들 사진을 갱신해야 한다는 점, 그걸 모두 캡쳐해서 카페에 공유하는 점 등을 공유했을 때, 조금 더 편하게 구성하고자 했다.
기획이나 디자인 등은 Figma로 관리하고 싶었지만, 개인 프로젝트임을 감안했을 때, 기획자도 디자이너도 아니고 Figma의 기본적인 기능도 숙지하지 못한 나로서 그런 절차는 "절차를 위한 절차" 가 될 수 있다는 생각에 우선은 수기로 정리 후 필요에 따라 Figma 사용을 고려하려 한다.
서버구성 및 기술스택
초기에는 호스팅 서버에 도메인만 구매해서 서비스를 올리겠다고 막연히 생각했는데, 생각해보니 그렇게 간단한 일이 아니었다.
우선은 금전적인 부분도 무시할 수 없었고 (보호소의 재정 상 관리자 편하자고 큰 돈을 투자할 수 없는 상황) 서비스를 올리기만 할 게 아니라 back이랑 db도 필요했기에, 여러 방법을 고민했다.
1. 안쓰는 컴퓨터나 노트북을 사용해서 서버를 돌리자
> 365일 24시간 내내 켜놓아야 한다는 점에서 변수가 너무 많았다. 혹시 나중에 일반 봉사자를 위한 페이지도 생길 수 있다는 점을 고려하면 적절하지 않다고 생각했고, 마땅한 기기가 없었다.
2. 라즈베리파이를 사용해서 서버를 돌리자
> 내가 모두 부담하기에 초기 기기값이 적지 않았고, 1번과 마찬가지로 개인이 계속 서버를 돌려야 한다는 부분이 안정성 부분에 있어서 걱정됐다. 보안 측면에서도 모든걸 내가 감당하기에는 현실적으로 무리가 있다고 판단했다.
3. EC2 서버 구축 후 내부에 front, back, db를 모두 구성하는 방안
> 이후로 AWS의 기능을 사용하는 걸 고려했다. 가장 간단한 건 사실 EC2로 인스턴스 서버를 구성한 후 Front-end / Back-end / DB 를 모두 EC2 서버에서 돌리는 방법이었다. 얼추 계산해보니 트래픽이 많지 않은 서비스일 예정이라 금전적인 부분도 고려해볼 만 했다.
4. AWS에서 제공하는 다양한 서비스를 활용하여 serverless 로 구성하는 방안
> EC2 금액을 알아보다가, AWS Free Tier를 적극적으로 활용해볼까? 라는 생각이 들었다. 다양한 걸 시도해보고 싶다는 생각도 있었는데 금액을 고려했을 때에도 소규모 개인 프로젝트였기에 오히려 합리적으로 사용할 수 있을 것 같았다.
이러한 고민 끝에 결국 최종 기술 스택은 아래와 같이 구성했다.
| Front-end | Vue3 + Nuxt |
| Front-end Hosting | AWS Amplify Host |
| Back-end | Go + Chi || Gin |
| Back-end Hosting | AWS Lambda + API Gateway |
| DB | AWS DynamoDB |
| Storage | AWS S3 |
| Source | Github |
Front 같은 경우에는 Vue를 좋아했었는데 Vue3는 아직 사용해보지 못했다. 사실, Vue3가 기존 Vue의 성격을 잃었다는 생각에 실망을 하기도 했지만, 현실적인 이유로 최근에는 React 위주로 작업을 했는데 이 기회에 Vue3도 직접 경험해보고 싶었다. 문제는 Client hosting을 별도 서버 없이 어떻게 하지? 였는데, AWS에서 Front-end 배포&호스팅 기능도 서비스 중이었다. 레포지토리를 연결해서 자동 배포도 되는 듯 하다.
Back-end 언어로는 Go를 선택했는데, 내게 Golang은 임베디드 특화 언어라는 이미지가 강했기 때문에 웹 개발에 Go가 적절할까, 하는 고민은 있었다. 알아보니 구글에서 만든 언어인 만큼(?) 네트워킹이나 서버 개발을 염두에 두고 만들어져서 성능도 괜찮고, 트랜드성도 나쁘지 않을 것 같다는 판단이었다. 프레임워크는 Gin이랑 Chi중 고민중인데, 조금 더 다양한 기능을 선택하느냐(Gin) 가벼운 프로젝트인 만큼 아예 심플하고 가벼운 걸 선택하느냐(Chi) 에서 고민중이다. 이 부분은 좀 더 알아본 후 결정하게 될 것 같다.
특히 DB를 어떻게 할 지가 좀 고민이었는데, 내가 개발하고자 하는 기능들은 통상적으로 RDB가 조금 더 적합한 구조라고 생각했다. DynamoDB를 사용해보고는 싶지만 어느정도 적합성도 고려하려 했기 때문에 AWS RDS를 사용해야겠다, 고 생각했는데 온디멘드로 돌렸을 때의 요금이 만만치 않았다. (스팟 인스턴스라고 해도 별 다를 건 없었다.) 그런 이유로 이럴거면 차라리 EC2를 사용해서 DB를 돌려야 하나, 그러면 굳이 다른 서비스를 사용할 필요 없이 EC2에 서비스를 구성하면 안되나? 라는 굴레에 빠졌다.
결론적으로는, DynamoDB를 사용하기로 했는데, 요금적인 측면도 있지만 구조를 신경써서 잡으면 충분히 구현할 수 있는 부분이고, 실제로 MSA의 경우에도 NoSQL을 사용한다고 알고 있으니(물론 여기에 비빌 건 아니지만) 해보자! 는 생각이었다. 애초에 RDB를 사용하는 이유도 문법적 이유나 호출 횟수 등으로 인한 성능 저하를 고려하는건데, 누누히 말하지만 소규모 개인 프로젝트이고 사용자가 많아진다고 해도 일반 서비스 만큼의 트래픽이 나올 수 없는 구조이기 때문에 우려할 만큼의 성능차이는 발생하지 않을 거라는 판단이었다.
이번 프로젝트를 실천하기로 마음을 먹은 후, 평소처럼 아무런 기록 없이 만들게 되는 대로 만들까 했으나, 기획부터 어떤 기술 스택을 사용할 지 등 처음부터 끝까지 내가 결정하게 되는 경험이 많지 않을 것 같았고 사실 하나씩 머리로만 생각을 하다 보니 점점 구체화 시키고 싶었다. 막연히 생각하는 것 보다 문서 등으로 정리해두는 것이 이후 나의 작업 능률이나 기능 개선에도 도움이 될 거라고 생각했다.
아무튼, 잘 마무리 되면 좋겠다.