프로젝트에 부딪혀 보았다.

팀 프로젝트 시작!

🤔 어떤 사이트를 만드나?

우리는 닥터마틴 사이트를 참고하여 신발을 판매하는 이커머스 사이트를 만들기로 했다!

팀 명은 sole mate! 

첫 회의

팀이 결성된 뒤 첫 회의에서는 닥터마틴 사이트를 분석하는 시간을 가졌다.
우리는 기술을 개발하는 개발자이지만, 결국 End-User에게 서비스를 제공하는 역할이기에 사용하는 고객의 입장을 고려하는 사고방식을 연습할 필요가 있다. 그렇기에

P : 우리 서비스가 지니는 Product 관점에서 가치를 분석합니다.
E : 우리 서비스를 이용할 가상의 End-User를 분석합니다.
T : 우리 서비스가 사용할 Tech를 분석합니다.

위와 같은 방식으로 많은 질문들에 답을 내는 방식으로 사이트를 분석했고
우리가 개발해야 할, 개발한다면 넣어야 할 기능들을 다 기록하였다.

Planning Meeting

회의 결과물을 멘토님들과 같이 확인하는 시간을 가졌다.
나름 열심히 잘 분석했다고 생각했는데, 멘토님이 닥터마틴에 대한 질문들을 했을 때 거의 대답을 하지 못했다.
그리고 다들 팀 프로젝트의 경험도 없고, 실제로 백과 프론트 간의 통신 경험도 전무하기 때문에 기능들을 기한 안에 어느정도로 구현 할 수 있을지도 파악이 어려워서, 사이트에 넣어야겠다고 생각한 기능들을 모두 작성해버렸다.
미팅을 하고난 뒤 적절히 다 가지치기를 하고 구현할 목록을 정한 뒤 나머지들은 추가구현으로 빼두었다.

1주차 구현

1주차는 반절을 ERD구현에 힘썼다.
ERD 구조를 잡는것이 중요한 작업이라고 들었기에 백엔드 팀원과 3일간 열띤 토론을 통해 테이블을 만들어냈다.

이것도 열심히 짠 만큼 각각의 필요한 테이블과 데이터를 분배했다고 생각했지만,
후에 API 코드를 짜면서 "이걸 왜 이렇게 짜놨지?" 라는 소리가 절로 나왔다.
프론트 팀원과 적절한 대화를 통해 페이지에 구현할 기능 목록들과 그에 따른 테이블, 데이터 분배를 했어야 했지만, 그런 부분에 있어서 어떤 소통을 나눠야 할지 몰랐기에 테이블을 좀 더 치밀하게 짜지 못한 부분이 아쉬웠다.

2주차 스프린트 미팅

Trello를 보며 전체적인 진행사항과 흐름을 파악하는 시간을 가졌다.
백엔드의 전체적인 진행사항이 느리고, ticket 분배가 모호하다는 지적을 받았다.
일주일간의 목표 설정이 확실히 되어있지 않아서 프로젝트 진행이 더 더뎌진 것이라는 총평이었다.

사실 나는 전반적인 서버 세팅이나 Layerd Pattern을 통한 모듈화를 하는 방법을 정확하게 숙지하지 못했다고 생각했다.
그래서 프로젝트를 진행하며 "내가 숙지하지 못한 채로 이 코드를 완성 시키는 게 맞나?"
하는 고민들을 계속 해왔었다.

결국 전반적인 코드 이해와 프로젝트 진행을 병행하려다가 프로젝트 진행이 느려졌고, 프로젝트 기간 안에 API를 완성했지만, 여유시간이 부족했기에, 상품 리뷰페이지 삭제, 변경 API 구현과 query builder를 이용한 리팩토링을 하지못한 점이 아쉬웠다.

프로젝트 마무리 

프론트엔드와 백엔드가 함께하는 프로젝트 자체가 처음인 사람들이 모여서 진행하였고, 기술적으로 완전히 숙지가 되어있지 않은 점도 있어서 그런지 이번 프로젝트에서는 아쉬운 부분이 많았다..

후기

팀적인 부분 💡

👉 기획

프로젝트를 진행하면 할수록 기획 단계의 중요성을 깨달을 수 있었다.
우리는 기획 단계에서 페이지마다 넣을 기능들과 구성들을 확실하게 짜놓지 않았다.
그래서 ERD를 만드는 것도 프로젝트 일정 기간 단위의 목표 설정도 힘들었고,
원하는 기능들을 프로젝트 기간에 제때 완성하지 못할 뻔 했다.

계획을 수립함에 있어서 적극적으로 하자.
기능 구현에 소요되는 시간이 얼마나 되는지 모르겠다면, 계획 수립을 좀 더 촘촘하게 나누자.

 

👉 소통

프로젝트를 진행하며 가장 중요한 부분이라고 충고를 많이 들었다.

문자 그대로 중요하다고만 생각했지, 소통을 통해 작업을 원할하게 하는 부분에 있어서 많이 서툴렀다.

속으로 소통을 잘하자 되새겼지만, 막상 프로젝트가 시작하니 작업 진행에 부담감을 느껴, 소통보단 내 작업진행에 좀 더 집중하게 되었다.
필터를 구현할 때, 색상과 사이즈가 단일 선택인 줄 알고 구현했다가, 중복 선택인것을 늦게 알고 수정한 경우도 있었고,
백에서 보내주는 데이터의 형식이나 key값을 미리 상의해놓지 않아 명칭을 다시 고친 경우도 있었다.
물론 다행히도 코드의 전체 구조를 크게 고친 경우는 없었지만, 불필요한 시간 소요가 컸다.

프론트와 백엔드에서 서로 주고 받을 데이터들을 상의하고 미리 기록하자.

기술적인 부분 💡

👉 DB modeling

연습을 실전처럼 이라는 말에 힘 입어 ERD를 죽도록 노려봤지만, 결과물은 영 신통찮았다.
테이블이 쓸데없이 나눠져 있는 것도 있었고, 테이블 안에 있어야 할 데이터를 넣지 않은 부분도 있었다.
ERD를 만들 땐 페이지에 필요한 데이터 뿐 아니라 확장성을 고려해서 좀 더 많은 데이터를 넣는것이 좋다.
그리고 정규화는 테이블 구조를 만드는 데 있어서 적용하면 좋은 방식인 줄 알았다. 하지만 정규화가 무조건 좋은것도 아니다.

이번 프로젝트에서 짠 ERD를 살펴보면 색상과 사이즈 테이블은 다대다 관계여서 중간테이블을 만들었는데,
상품리스트의 필터 API 코드를 짜고 보니 JOIN문이 줄줄이 소세지 마냥 달려있었다.
효율적이지도 않았고, 직관적으로도 보기 좋은 코드는 아니었다.

정규화가 무조건 답은 아니다. 좋은 코드를 위해 적절한 정규화와 테이블 분배하는 방법을 고려하자

 

👉 API

처음에는 가장 막막했던 부분이었다. 코드의 흐름을 보기위해 코드를 보고 또 봤고. 따라서 써보기도 했다.

분명 설명을 들을 땐 이해가 됐다고 생각이 들었었다. 하지만 실제로 적용하려 코드를 한 부분씩 뜯어봤는데,

내 머리도 같이 뜯었던 기억이 난다.

그런데 계속 보다보니 익숙해졌고 굳센 벽 같았던 코드에 틈이 점점 보이는 것 같더니 코드 안의 흐름이 눈에 들어오기 시작했다.

그때부터 구조가 생각보다 어렵지 않네? 라는 생각이 들며 열심히 구현에 매진했다.

막막했던 코드의 구조도 천천히 하나씩 살펴보며 큰 흐름을 따라간다면, 이해하지 못할 것도 없겠다 라는 자신감이 생겼다.

이번엔 많은 API를 구현하지 못했지만, 다음 프로젝트 때에는 검색 기능이나, 상품의 좋아요 기능등을 좀 더 구현해보고 싶다.

그리고 querybuilder 코드도 적용시켜 좀 더 효율성 있는 코드를 만드는 것을 목표로 삼자.

querybuilder 코드

 

어쩌다보니 아쉬운 점만 계속 나열한 것 같은데, 프로젝트 기간동안에는 코드에 대한 이해도 부족과 완성 해야한다는 압박감이 겹쳐 많이 고심했었다. 
멘토님께서 "큰 고난은 큰 성장을 안겨다준다." 라고 자주 말하시면서 숙제를 내주셨는데, 이번만큼은 굉장히 동의한다.
많이 고심한 만큼 코드에 대한 지식이나 자신감도 얻었고, 코드 외적으로도 팀 협업에 있어서 필요한 것들을 많이 깨달았다.
지금 이 깨달음을 계속 가져가 더 나은 개발자로 성장하고싶다.