[Project] INFRA(인프라) 회고

인프라 로고

[진행 기간]

2022.01 ~ 2022.03

 

[인원]

안드로이드 개발자 : 2명

백엔드 개발자 : 5명

디자이너 : 1명

 

[역할]

백엔드 개발

 

[회고]

UMC(University MakeUs Challenge)라는 앱 런칭 연합동아리 들어가 Server파트에서 2개월동안 교육을 받고, 팀원을 구성하여 앱런칭 프로젝트에 참가하였다. UMC에서 AWS, EC2, DB, SQL, Spring 등 백엔드에 필요한 기초적인 지식을 얻을 수 있었고, 이 과정을 수료하고 INFRA(아이디어 구현 팀원 매칭 서비스)라는 앱런칭 프로젝트에 합류하였다.

 

아무래도 리눅스 환경에서 서버 구축하는 것이 처음인터라 많은 어려움을 겪었지만, 스터디를 만들어 다음과 같이 실습체크리스트, 트러블 슈팅, 논의해보면 좋은 것들에 대해 스터디 구성원들과 의논하여 모두 해결할 수 있었다.

이렇게 백엔드 개발자 4명이 모두 같이 공부하여 AWS EC2, RDS 등 환경 구축을 완료하였다. 팀원 모두가 노션 공유 페이지를 만들어 공부한 내용을 발표 및 공유하다보니 자연스레 백엔드 개발 지식에 대한 스택을 쌓을 수 있었고, 백엔드 개발자에 비해 안드로이드 개발자가 부족하여 앱 런칭이 목표보다 좀 늦었지만 결국 앱 런칭에는 성공하였다. 

 

뒤늦게 백엔드 개발자에서 안드로이드 개발자로 전향하였지만, 절대 이 시간이 아깝지 않았고 백엔드에 대한 기본 지식때문에 백엔드 개발자와 소통 및 협업할 때 현재 많은 도움이 되고 있다.

 

[협업]

슬랙

슬랙을 깃허브와 연동하여 각각의 진행상황을 파악하였다.

노션 : Api Sheet

노션 : 회의록

또한, 노션에서 Api Sheet를 위의 사진처럼 보다 구체적으로 작성하여 협업에 도움을 주었다.

 

[개발]

ERD

기획의도 및 우려사항을 다음과 같이 ERD에 반영하였다. 가장 고민이였던 것은 사용자와 프로젝트와의 관계였다. 아무래도 인프라의 메인 기능은 사용자가 프로젝트를 올리고, 조회하고, 참여하는 기능이라 많은 관계가 나올 것을 예상하였지만, 막상 ERD를 설계하고 나니 너무 복잡한 형태를 이루었다. 하지만 관계를 줄이고 정규화를 지키지 않는다면 추 후에 문제가 생길 것을 예상하여 나중에 바뀌더라도 애자일하게 변경하기로 결정하였다.

사람과 사람간의 매칭이기 때문에 어떠한 문제가 발생했을 때 항상 추적이 가능해야 했다. 따라서 위의 ERD와 DB설계한 내용을 보면 모두 상태를 나타내는 status가 있는데, 실제로 삭제가 되었더라도 DB에서 Delete가 되는 것이 아니라 상태만 변경되게끔 설계하였다.

Dao

기본적으로 Controller, Provider, Service, Dao 구성하여 프로젝트를 진행했으며 jdbc를 사용했기 때문에 위의 코드처럼 쿼리문을 하나씩 모두 작성해주어야했다. 나름 쿼리에 자신 있었던 나는 팀원들의 쿼리까지 작성해주곤 했다. 하지만 쿼리의 복잡도가 올라갈수록 코드가 좀 더러워지는 기분이 들었고, 다음 프로젝트에서 백엔드로 참여하게 된다면 꼭 JPA를 사용해보고 싶은 느낌을 받았다. 

 

백엔드 개발자가 5명이니 만큼, 개발 속도가 안드로이드 개발자에 비해 많이 빨랐다. 안드로이드 개발자에 비해 시간이 많이 여유가 있었던 백엔드 개발자들이 단위테스트를 작성하지 못해 아쉬움이 컸던 프로젝트였다. 당시 첫 앱 런칭 프로젝트라 칸반보드를 통해 백로그를 작성하는 등 협업에 필요한 자세에 대해 많이 배울 수 있었다. 만일 시간이 남았던 당시 단위테스트에 공부하여 테스트코드를 작성하였다면 더욱 질 높은 프로젝트가 됐었을텐데 라는 아쉬움이 있다. 

 

이 프로젝트로 인해 일은 누가 줘서 하는 것이 아니라, 내가 일을 찾아서 할 때 비록 성장할 수 있다는 것을 깨달았다.

 

인프라 서버 깃허브 ->

GitHub - INFRAcp/INFRA-Server: 👥아이디어 구현 팀원 매칭 서비스