[슬축생 프로젝트] 1. 고정 사용자 80명이 확보된 프로젝트 시작

개요

나는 현재 약 80명 넘는 남녀 회원들이 활동하고 있는 대학생 연합동아리 슬기로운 축구생활에 3기 회장을 맡고 있다.

경기별로 출석, 지각처리나 회비 관리 및 활동비 납부 등등 기존엔 모든 프로세스를 엑셀로 관리를 하였는데 솔직히 너무 불편하고 하고 매번 하나하나 기록하는게 너무 귀찮고 안하게 되서 한번 어플리케이션을 제작해보면 좋겠다! 생각을 해서 이 프로젝트를 시작하게 되었다.

프로젝트 시작

사실 프로젝트 시작은 8월 7일 정도에 했지만 지금 첫 글을 쓰고 있다.

시간이 워낙 없기도 하고 지금 필수 기능들은 거의 다 만들어가는 상태여서 이제 슬슬 프로젝트가 성장해나가는 모습을 기록하려고 한다.

프로젝트 멤버 구성

그동안 프로젝트를 해올때 보통 역할 구성이 PM, 기획자, 디자이너, 백엔드, 프론트 이 정도로 생각하였다.

이번 프로젝트의 멤버 구성은 PM은 내가, 기획..도 내가, 디자인..도 내가, 백엔드도 내가 맡았고 프론트는 내 친구한테 맡겼다.

친구는 서비스 회사에서 PHP랑 Vue를 사용하는 프론트엔드 개발자로 일하고 있는데,

친구한테 맡긴 이유는 생산성은 내가 높을지언정 사용자 서비스 프로젝트이니 서비스 개발자의 무언가를 기대했었다.

프로젝트 환경 구성

백엔드 환경 구성

일단 백엔드 같은 경우는 아래와 같이 조합해서 사용하기로 결정하였다.

일단 Java + Spring Boot를 베이스 언어와 프레임워크로 결정하였다.

DB는 MySQL으로 결정했고 다른 프로젝트들과 겹치지 않게 로컬에선 Docker로 띄워 사용중이다.

JPA + Hibernate 조합을 선택하였다, 김영한 강사님의 강의를 열심히 듣는중이기 때문에 사용하고 싶었다.

IDE는 Intellij Idea Ultimate와 macOS에서 개발한다.

 

코드 관리는 평소처럼 github으로 하고 배포는 원래 사용하던 성능 짱짱한 평생 무료인 오라클 클라우드에 올리기로 하였다.

왜 AWS를 사용하지 않는가? 돈이 없다.. 한때 무료로 잘 사용했지만 EC2등 사용할줄만 알지 비용 관련한 부분은 겁나서 맘 놓고 못 쓰겠다

프론트엔드 환경 구성

프론트엔드는 PHP, Html, Css, JavaScript 조합을 사용하였다.

PHP를 선택한 이유는 친구가 php가 제일 생산성이 높았고 프로젝트가 asap였기 때문에 일단 제일 빨리 개발할 수 있는 언어를 선택했다.

 

배포는 AWS LightSail을 이용할 예정이다. 왜 오라클 클라우드에 한번에 안 올리냐면 무료 요금제여서 도메인 연결을 못한다..

그래도 일반 사용자들이 이용하는 사이트니 깃허브 교육 혜택으로 받은 SSL 인증서와 몇백원 주고 산 도메인을 써야겠다 싶어서..

AWS EC2를 항상 사용해서 익숙하긴 하지만 비용적인 문제와 php 사이트만 돌릴것이기 때문에 합리적인 LightSail을 사용하게 되었다.

 

프론트 개발 하는 친구의 역량 향상 겸 우물안의 개구리처럼 회사에서 사용하는 언어만 공부할 순 없으니 나중에 js 프레임워크로 변환하라고 할 예정이다, 요즘 트렌드인 NextJS + TS 조합을 원하지만 회사에서 vue를 사용한다고 해서 NuxtJS로 합의 보지 않을까 싶다..

협업 하는 방식

보통 나는 협업할때 노션을 사용한다, 보안 솔루션 회사에서 근무하느라 실제 서비스 도메인 회사들이 어떻게 일하는지는 잘 모르지만... 서비스 회사들의 기술 블로그랑 유튜브 영상등을 참고해서 최대한 비슷한 경험을 가져가보려고 노력하고 있는중이다

 

기획 같은 경우는 규모가 작은 프로젝트여서 화면별로 문서화하지 않고 크게 비즈니스 요구사항을 정하고 거기서 세분화하여 정리했다. 

이런식으로 비즈니스 기능을 정리하고 밑에 조그맣게 API 명세서 페이지를 생성해놓았습니다.

 

여담이지만 진짜 진심으로 진행하는 프로젝트가 있는데 (지금은 잠시 접어뒀지만) 그 프로젝트 같은 경우는 예쁘게 정리해놨습니다

근데 지금은 ASAP이기도 하고 2명이서 협업하는데 굳이 저렇게까지 해야하나..? 싶었다.

 

다시 본론으로 돌아가서 API 명세서 같은 경우는 기존에 만들어서 사용하고 있던 폼이 있어서 예쁘게 잘 정리해놨다.

API는 비즈니스 기능별로 100번대씩 잘라서 분류하였고, 들어가면 상세 API들 이름, URL, HTTP Method, 작업 진행도가 보인다.

Access 같은 경우는 JWT 토큰의 필요 여부이다.

Not Required면 필요 없음, Required는 유저토큰, Admin Required는 관리자 토큰이 필요하다는 의미다.

상세 문서를 하나 열어보면 이렇게 설명과 요청시 필요한 파라미터과 성공 / 실패 응답값이 적혀있다.

 

이 API 명세서 형식 같은 경우는 필요한 사람이 있으면 댓글에 달아주면 공유하도록 하겠다.

왜 앱이 아니라 웹을 선택했는가?

이게 제일 중요한 부분인데 이걸 까먹고 넘어갈뻔했다.

왜 앱이 아니라 웹을 선택했는가?, 나는 물론 안드로이드과 iOS 둘 다 회사에서 개발경험이 있어서 앱을 선택했다면 단독 프로젝트 진행이 가능했다, 하지만 굳이 웹을 선택한 이유는 서비스 자체가 우리 부원들만을 위한 서비스이기도 하고 사용자 경험에서 생각을 해봤을때 굳이 플레이스토어에 들어가서 앱을 다운 받고 사용할 정도로 무게감이 있는 서비스가 아니라고 생각하였다.

 

그리고 제일 중요한 부분인데 비용적인 부분이 제일 컸다, 일단 안드로이드는 몰라도 iOS 같은 경우는 개발자 계정이 필요하였고 1년에 약 10만원 정도 넘는 비용이 발생하는것으로 알고 있었다, 그리고 둘 다 배포하는데 심사를 받아야하고 그런 시간적 비용들이 이 서비스에는 좀 적합하지 않다고 판단하였고 그래서 그냥 앱이 아닌 모바일 플랫폼을 타겟팅한 웹을 개발하기로 하였다.

 

정리해보자면

보통 사용하는 경우는 경기에 도착해서 출석처리 하거나 활동비 납부 확인 신청하는 정도인데 굳이 앱까지 개발해야하나 싶었다.

그리고 경기에 도착해서 사용하는 기능이 대부분이기 때문에 PC가 아닌 모바일 플랫폼을 타겟팅하기로 하였다.

 

 

다음글은 디자인을 하는 과정에 대해서 다뤄보도록 하겠다