프로젝트 회고 [명식이 - 명지대의 식사를 책임지다! ver1.0 ]

 

개발기간 2022.10 ~ ING

플랫폼 Android, IOS

참여인원 서버 1명, AOS 1명, IOS 1명, 디자이너 2명 (총 5명)

담당역할 PM, 기획, Back-end, DevOps

 

명식이는 "명지대학교의 식사를 책임지다!"를 슬로건을 가지고 출발한 앱이다. 첫 시작은 인문 캠퍼스 공사를 거치며 학생식당이 신규로 들어오며 기존의 학식메뉴를 제공해주는 에브리타임에서는 제공하지 않고 학생들은 직접 학생식당에 가서 사진을 찍고 이를 에브리타임 커뮤니티에서 공유하여 많은 학생들이 불편함을 느끼는 것을 들었다. 안드로이드 친구와 학생식당 메뉴를 알려주는 앱을 만들자는 의견에서 시작했다. 시작을 하기로 마음을 먹고 1주일 만에 개발을 마치고 배포를 진행했다.

 

배포를 진행하고 커뮤니티와 오프라인 홍보물을 부착하여 유저가 900명까지 모이기 시작하며 실제 배포를 하는 개발자의 느낌을 느끼며 내가 개발한 것에 성취감을 느끼며 고맙다는 학생들의 이야기를 들을 때면 보람을 크게 느꼈다. 해당 프로젝트를 진행하며 내가 배운 것, 개선사항을 포스핑하기로 했다. 

 

배운것

1.  실제 서비스 운영 경험

실제 서비스 운영 해본 다는 것은 단지 개발을 해서 커밋을 하고 PR을 날리는 것이 아니고 상상 이상으로 떨리는 것이었다. 당장 내 PR로 인해서 수 백명의 유저들이 즉각적인 불편함을 느낀다는 것이 부담스러웠으며 CICD 파이프라인이 잘못되는 것은 아닐지 걱정이 많았다. 걱정이 많을 수록 고민은 많이 했고 고민은 나에게 성장을 가져다줬다. 걱정은 Dev(개발), Prod(배포) 서버를 분리하게 하였고 DB 또한 분리하였으며 브랜치별 CICD 전략 구성하여 main 브랜치에 PR이 발생할 경우, prod서버에 배포가 되고 develop 브랜치의 경우, dev서버에 배포가 진행되도록 하였다.

2. 인터뷰

감사하게도 학생회에서 서면 인터뷰를 진행 요청을 받고 인터뷰를 진행하였다. 내가 개발한 것을 비개발자와 개발자들에게 글로 설명해야하는 부분을 배우게 되었다. 예를들어 Server를 Dev와 Prod로 분리한 것과 CICD 구축한 것을 설명하는 것을 개발자들을 위해 Spring yml설정 파일을 통해 매개변수로 Dev와 Prod를 입력받고 이에 해당하는 DB서버에 접속하다록 구축하였다고 설명하고 CICD를 Jenkins에서 gradle을 통해 빌드하여 jar파일을 도커로 이미지로 만들어 도커허브로 배포서버로 간다는 것을 설명하였다. 여기서 비개발자들에게는 해당 기술이 서비스에 어떤 방향으로 유저에게 전달되는지를 설명하였다. CICD를 구축하여 긴급하게 수정할 오류가 있을 경우, 기존의 반영 속도보다 더 빠르게 반영되는 방식이라고 설명하였다.

3. 소규모 팀의 힘

이전의 진행한 프로젝트를 보면 서버를 개인 프로젝트 외에는 가장 소규모로 진행된 프로젝트였다. 소규모로 진행되기에 기민성이 올라가며 팀은 개발 및 디자인에 있어서 즉각적인 결과물이 보였으며 배포 이후에도 가장 많이 수정작업이 이루어져 1.9.1버전까지 업데이트를 진행했다. 배포 이후에도 유지보수를 진행한 첫 프로젝트였다. 유지보수를 하기에 이후에 수정을 고려한 코드를 작성하며 주기적인 회의를 거치며 개발을 짧은 시간에 큰 성과를 가져왔다.

 

개선사항

1. 로드 밸런스

명식이 서버에는 로드 밸런스를 적용하지 못했다. 그 말은 Prod서버에서 문제가 발생할 경우, 서비스의 이용에 차질이 바로 이어진다는 것이다. 이것이 늘 걱정이었다. 물론 Jenkins에서 파이프라인을 구축하여 문제가 생길 경우 이전의 배포로 이루어지지만, Jenkins의 생명주기는 배포 서버에서 문제가 생기는 것은 막지 못한다. 다행스럽게 서비스를 런칭하는 동안 Prod서버에 문제가 생긴 적은 없으나 로드 밸런스를 적용했더라면 더욱 안정적인 서비스를 제공할 수 있었지 않을 가 하는 아쉬움이 있다. 

다음 버전에는 Nginx를 적용하여 로드 밸런스를 적용할 예정이다.

 

2.  모니터링의 부재

모니터링은 직접 로그를 확인하거나, AWS에서 직접 제공하는 모니터링을 활용하였다. 모니터링을 못하는 것이 이렇게 불편한 일인줄 몰랐다. 다른 프로젝트에서 모니터링에 대해서 필요성을 느끼지 못했지만 실제 유저가 있는 서비스에서 모니터링은 매우 중요한 요소였다. 모니터링의 데이터를 의사결정에 큰 지표가 되었으며 개발 팀이 언제 배포를 이루어지게 할 것인지, 특정 시간에 Scale-out할 것인지 등 다양한 의사결정에 활용할 수 있을 것 같다.

다음 버전에는 prometheus grafana를 사용하여 모니터링과 시각화를 적용할 예정이다.

 

 

3. 조회를 더욱 빠르게는 못했을 까?

대부분의 유저는 간단하게 금일 메뉴만 확인 할 것으로 예상된다. 그렇다면, 금일 메뉴만을 캐시 메모리(Redis)에 넣고 관리를 했다면 더욱 빠르게 조회가 가능하지 않았을까? 하는 아쉬움이 있다. 

Redis에 대해서 다양한 테스트를 거치고 적용을 검토해봐야겠다.

 

 

App DownLoad Link

AppStore

‎명식이 : 명지대의 식사를 책임지다!

PlayStore

명식이 : 명지대의 식사를 책임지다! - Google Play 앱

 

GitHub

GitHub - MYONGSIK/Server: 🍚🍚 명식이 : 명지대의 식사를 책임지다!

Skill Stack

Infra Structure

CICD