본문 바로가기

Project

[UMC | DEMO DAY] 백앤드 리더의 1등상 후기

반응형

프로젝트 소개

- Github: https://github.com/spon-us

 

spon-us

spon-us has 2 repositories available. Follow their code on GitHub.

github.com

들어가면서

24년 2월 20일, UMC 데모데이를 끝으로 UMC 5기 Spring파트를 수료했습니다! 수료와 함께 첫째날 데모데이 1등상이라는 좋은 결과를 얻어 더욱 뜻깊었던 경험이 된 것 같습니다.

1등상

 

UMC는 학기간 자신의 파트 수업을 들으며 자신의 실력을 키웁니다. 그 후에 방학이 시작되면, 방학 기간 동안 여러 파트의 사람들과 팀 매칭을 통해 하나의 프로젝트를 진행합니다. 저는 이전 아이디어톤때 PM님의 성실함과 적극성에 매료되어 같은 PM님께 지원했고, 다행히 제가 원한 팀에 조인하게 되었습니다. 저희팀은 총 11명으로, PM 1 / Designer 1 / Spring 5 / IOS 4 으로 구성되어 있었습니다.

 

저는 이번 프로젝트에서 Spring 팀의 리더로 참가하게 되었습니다. 학교를 다니면서 팔로워로만 팀 프로젝트에 참가했던 점이 아쉬워, 이번 팀 프로젝트에서 리더로서의 경험을 쌓아보고 싶었습니다. 그리고 리더를 맡으면서 인턴 생활을 길게 했던 제 경험을 살려 팀이 더 잘 굴러갈 수 있도록 해보고 싶었습니다. 백엔드 리더로서의 팀 프로젝트에 대한 후기는 이후에 작성할 예정입니다. 이번 포스팅에서는 "데모데이"에 대한 후기를 중점적으로 다루고자 합니다.

백앤드 파트 리드

부스에 대해서

저희 부스에는 정말 다양한 컨텐츠가 있었습니다. 배너, 팜플릿, 스티커, 자동으로 넘어가는 PPT, 부스 참가자가 직접 넘겨볼 수 있도록 한 PPT, 판넬 2종, 포스터 8종, 실시간 시연.. 등이 있었습니다. 이렇게 많은 컨텐츠를 준비해주신 피엠님과 디자이너분이 새삼 대단하다고 느꼈습니다.

다양한 컨텐츠 중 개인적으로 느낀 가장 있어서 다행이었던 컨텐츠는 배너, 가장 있어서 돋보였던 것은 적극적인 시연(PM님이 직접ㅋㅋㅋ) 이었습니다. 배너가 없는 팀은 돌아다니면서 어떤 서비스인지 쉽게 예측이 가지 않았고, 시연 덕분에 이 팀 제대로 했구나를 보여줄 수 있었습니다.

 

시연 중 발생한 이슈

데모데이가 본격적으로 시작하기 전에, 팀원들끼리 TestFlight로 배포한 어플에 각자 로그인해서 잘 동작하는 지 확인했습니다. 저희가 시연으로 보여주고 싶었던 기능은 크게 2가지: 결제 / 알림 기능이었습니다. 두 기능 모두 잘 동작했습니다.. 시연 초반까지는요... 어느 순간부터 로그인이 되지 않더니 알림 기능까지 동작하지 않았습니다.

 

백엔드 팀원들이 DB랑 로그를 확인해서 FCM 관련하여 버그가 있다는 것을 확인했습니다. 처음에는 정확한 원인 파악과 수정을 시도했지만, 상황적으로 한계가 존재했습니다.  수정시간 동안에는 시연을 할 수가 없었고, 부스에서 가장 큰 임팩트를 주고 있던 컨텐츠였기 때문에 계속해서 개발을 할 수 있는 상황이 아니었습니다. 결국 궁여지책인 임시 FCN 토큰을 고정하는 방식으로 시연을 계속해나갈 수 있었습니다.

 

이슈를 돌아보면서..

관련 기능 이해 부족

사실 알림 기능에 대하여 완벽하게 알고 있지 못했습니다. 개발해야 할 기능들을 정리하고, 업무 분배를 하는 과정에서 개발 경험이 있는 친구가 있어 친구가 전담하여 개발했기 때문입니다. 그러다보니 이슈가 발생했을 때, 기능적으로 버그를 찾아내거나 해결책을 떠올리는 데에 한계가 있었습니다.

아무리 대학생 동아리라도, 백엔드 리더라는 직책을 담당했던 사람으로서 이슈가 터졌을 때, 기능적으로 도움을 줄 수 없었다는 점이 아쉽고 팀원들께 죄송했습니다. 당시에는 계속해서 상황을 물어보고, 현재 상황을 PM님께 공유드리는 것 밖에 할 수 있는 것이 없었다는 점이 내심 속상했습니다. 서비스가  커지면 리더가 모두 담당할 순 없지만, 아직 작은 서비스에서는 모두 파악하고 있어야 한다고 생각했습니다. 이러지 못한 점에 반성하고, 저희 프로젝트에 더욱 애정과 시간을 가져서 파악해 나아가야 할 것 같습니다.

모니터링 기능의 중요성

처음 이슈가 터졌을 때, 상황 파악하는데 시간이 걸렸습니다. 우선 로그를 보기위해 서버에 직접 접속해서 컨테이너에 직접 접근해서 로그를 확인해야 했습니다. 그리고, 로그를 본다고 어떤 문제인지 쉽게 파악하질 못했습니다. 그래서 설마 부하 문제인가? 싶기도 했지만 확인할만한 방법도 없어서 부하 문제가 아니길 빌기만 했었습니다.

현재 서비스의 상황에 대해서 모니터링할 수 있는 기능이 없다보니 더욱 당황했던 것 같습니다. 실제 서비스를 운영하게 된다면, 다양한 지표를 확인할 수 있는 모니터링 기능을 고려하고자 합니다. 버그 리포팅 기능도 고려해보면 좋을 것 같습니다.

 

앞으로의 계획

3월 말에 팀원 중 한 분의 학교에서 진행하는 부스에 참여하기로 했습니다. 그때까지 실제 배포를 목표로 개발하기로 했습니다. 백엔드 팀원분들이 모두 개발에 대한 관심이 많다 보니 시도해보고 싶은게 너무 많았습니다. 우선 해보고 싶은 것들을 나열만해보고, 3월 말 부스 행사를 마무리한 후, 실제로 적용한 것들을 작성하고자 합니다.

  • 단위 테스트
  • 성능 부하 테스트
  • 모니터링 기능
  • 멀티 모듈
  • ERD 구조 개선
  • ...

정말 어떻게 11명 모두 이렇게 착하고 좋은 팀원들이 모일 수 있었는지, 정말 운이 좋았던 것 같습니다. 정말 유능하고 책임감 많은 팀원들 덕분에 많이 배웠던 것 같습니다.

반응형