[회고] 프로젝트를 마치며..

약 5 ~ 6주간의 프로젝트가 끝이 났다. 다양한 분야의 팀원(백, 프론트, 디자인)과 프로젝트가 끝난 시점에서 어떻게 협업을 했고 어떤 부분에서 문제가 있었는지 조금이나마 생각해보는 시간을 가지려 한다.

어색한 첫 만남 & 프로젝트 주제 선정

처음 대화의 시작은 프로젝트 주제였던 것 같다. 각자 생각한 주제나 소소한 얘기를 하며 팀원끼리 말을 많이 했었고 다양한 주제에대해 얘기를 나눈 것 같다. 그 중 우리가 정했던 아이디어는 연구를 위한 지원자를 모집하는 기업/단체와 단기 알바를 원하는 유저간의 매칭을 더 간편하게 도와주는 서비스 였다.

아르바이트의 경우 이미 좋은 어플들이 많고 시스템이 존재했지만, 대학교나 대학원, 기업 등 단순한 연구에대한 테스트를 받거나 다양한 사람들의 생각을 얻을 수 있는 사이트는 없었기 때문이다.

---

서비스 해부

주제를 정하고 누가 이 서비스를 필요로 하고 사용 할지 서비스 이용자(타겟)를 조사 했다.

---

프로젝트 설계

누가 우리의 서비스를 이용하고 필요로 하는지 조사는 끝났다. 그렇다면 다음으로 사용자가 우리 서비스를 사용하기 위해 어떤 기능들이 있어야 할지 정리가 필요했고 다른 사이트를 참고하며 하나 둘 정리했다.

정리한 내용을 토대로 디자이너와 프론트의 주도하에 피그마에서 와이어 프레임을 함께 생각해 볼 수 있었고 백엔드끼리 ERD를 설계하려 했었다. 하지만 기초적인 틀은 이미 잡혔기에 프론트와 백엔드가 함께 개발을 시작할 수 있도록 API 명세서를 먼저 작성했다.

API 명세서의 경우 프론트와 백엔드가 협업하기 위해 중요한 문서이며 잘 작성해야 개발하는 단계에서 문제를 줄일 수 있다고 주변에서 많이 들었던 소리이다. 오류를 최소화하기 위해 RESTful API를 설계하고 구현하려 했었고 많이 공부할 수 있는 기회가 되었던 것 같다. RESTful API 참고 자료

아래는 프로젝트 API 명세서중 일부이다

API 명세서를 작성하고 ERD를 작성하니 생소한 작업이였지만 크게 어려운 부분은 없었던 것 같다.

---

프로젝트 진행

설계한 내용을 토대로 프로젝트를 진행했고 생각보다 수정할 부분은 많았었다. 약 5일 이상을 프로젝트 설계하는 데 시간을 할애했으나 예상과 달리 필요한 컬럼이 더 생기거나 response 값이나 request 값이 추가, 제거되는 일들도 사실 많았다.

수정을 여러번 경험하고 발생하는 오류를 최소화하기 위해 팀 내부적으로 사소한 소통을 자주 진행했고 서로의 문제를 공유하며 부족한 부분을 채워주려했다.

그 이후

프로젝트를 진행하며 설계의 중요성에대해 직접 체험할 수 있었던 것 같다. 기능 하나를 구현하려해도 그 이유와 근거는 타당해야 했고 제대로 된 설계를 한 이후 구현을 해야했다. 만약 설계를 대충 하고 프로젝트를 진행했다면 어떤 수정이 기다리고 어떤 더 큰 문제가 발생했을지 상상조차 어려울 것 같다. 또한, 기능을 구현하며 단순 코드가 작동된다면 괜찮은 코드라 생각했던 나 자신이 부끄러웠고 해당 코드의 성능을 생각해보며 개선하는 시간을 경험하며 한 단계 성장할 수 있는 시간이었다.

앞으로 이러한 경험을 토대로 프로젝트를 설계하거나 기능을 구현하며 코드를 작성할 때 많은 생각을 하게될 것 같다.