[Project] 모락모락 프로젝트 1,2,3 주차 회고 (중간 회고 ^^😸)

3주차 주간 회고를 작성하기에 앞서서, 지난 2주간 진행되었던 내용과 각 주차의 소감을 간략하게 정리하고 넘어가고자 한다.

(매주 썼어야 했는데..^^)

💡WEEK 1 (2022-1101 ~ 2022-1106)

프로젝트 시작!

우리 팀은 2주 반 정도 진행됬던 클론 코딩 프로젝트(프리 프로젝트)에 앞서서, 먼저 팀을 꾸려 기획에 대한 논의를 짬짬히 진행했다. 메인 프로젝트 기간 동안은 기획부터 배포까지 가이드 없이 직접 진행하는 것이기 때문에, 기획 단계에서 드는 시간을 아끼고자 먼저 진행을 했던 것 같다. 

 

팀원 중 두 분은 이전에 같이 팀을 한 적이 있는 분들이었고, 나머지분들은 오며가며(?) 서로의 존재를 알지만(?) 같이 프로젝트를 진행해본적은 없었다. (프론트 얘기) 사실 이번 프로젝트에서 팀장을 맡고 싶었는데, 프론트 기술 스택을 Next.js, Typescript 같은 많이 다뤄보지 않았던 툴을 사용하게 되어서 이번에는 기술 스택을 공부하는데 더 집중하고 싶은 마음이 컸다. 그래서 맡지 않았는데 그냥 한다고 해볼껄 이런 마음도 살짝 ㅋㅋ

 

기획은 주로 피그마로 진행을 했고, 프로젝트를 진행하는 중이었기 때문에 시간이 될 때마다 모여서 아이디어 회의를 했다. 처음에는 백엔드에서 결제 기능을 추가하고 싶어하셔서 그 부분을 위주로 가다보니 커뮤니티 + 결제시스템 + 채팅 및 기타 여러가지 기능이 추가된 서비스를 목표로 하게 되었다.

이렇게 키워드를 잡아서 생각나는 대로 아이디어를 냈다.

사실 초반에 이런 회의 mc 역할을 내가 맡게 되었는데, 서로에 대해서 더 잘 알면 의견을 자유롭게 낼 수 있고 더 좋은 방향으로 발전할 수 있다는 생각이 들어서 급 자기소개 타임을 제안하기도 했다. ㅋㅋㅋ 팀원들의 성향에 대해서 더 잘 알 수 있어서 좋았던 시간이었음 ㅎㅎ

아이스브레이킹 ㅎㅎ

1주차에 나왔던 아이디어를 바탕으로 간략하게 요구사항도 정리하고, 필효한 페이지도 도출해볼 수 있었다.

약간 아쉬운 점은 이 단계에서 바로 개발로 들어가기 보다는, 좀 더 꼼꼼하게 문서화를 했으면 좋았을 것 같다.

ㅜㅜ 이유는 나중에 나옴🥲

페이지별 요구사항 정의...

💡WEEK 2 (2022-1108 ~ 2022-1113)

플로우차트 작성

앞서 도출된 페이지를 가지고, 업무 분장을 하고 백엔드에서는 바로 api 개발에 돌입하셨고 프론트에서는 플로우차트와 UI 를 그리는 기획 단계를 진행했다. 대략적인 요구사항이 도출되었는데 정확히 어떤 페이지가 필요하고 어떻게 연계가 되는지 알기 위해 페이지를 기준으로 플로우차트를 작성하고, 또 거기서 각 페이지별로 어떻게 동작할지 유저 플로우를 작성하는 단계를 가졌다.

첫 멘토링 후 갈등 발생🥲

이렇게 작성하고 보니 작업이 필요한 페이지 목록이 나왔고, 페이지 갯수가 거의 20개 이상이 된다는 것을 확인했다. 사실 이때까지는 문제를 인지하지 못했는데, 첫 멘토링을 통해서 볼륨이 너무 크다는 피드백을 받게 되었다. 그 당시까지 우리의 목표 기능은 질문/답변 게시판, 정보글 게시판, 회원 랭킹 시스템, 포인트 결제 시스템, 채팅 시스템, 유저 대시보드 등이 있었는데 멘토님께서는 여기서 주요한 기능 2~3가지 정도만을 선정해서 집중하는게 좋아보인다는 말씀을 해주셨다.

 

생각해보니 우리가 감이 없었을 뿐 결제시스템에 채팅까지 추가된다는게 엄청 큰 기능이라는 것을 인지하게 되었고, 프론트 내부적으로는 회의를 거쳐 몇몇 기능에 집중하자는 결론을 내리게 되었다.

 

사실 모든 팀원들이 이에 합의하면 정말 좋겠지만, 백엔드 팀원들의 경우 이 모든 기능을 목표로 API 를 열심히 개발중이었기 때문에 말을 꺼내기가 망설여지기도 했다. 또 첫 주 아이디어 회의 단계를 지나 2주차에서 기획에 대한 산출물을 낼 때, 프론트와 백엔드간 소통이 부재했기 때문에 더 이야기를 꺼내는게 힘들다는 의견이 나왔다. 그래도 우리는 같은 팀이기 때문에 이러한 결론에 대해서 빨리 공유를 하고 지금 단계에서 방향을 정하는게 맞다는 판단이 들어서 전체적으로 회의를 거치게 되었다. 

 

백엔드 팀원분들이 사실 받아들이기 힘들어 하셨지만, 1차적으로 프론트 쪽에서는 볼륨을 줄이는 방향으로 결정을 했고 (질문/답변 게시판(좋아요, 북마크, 댓글기능 O), 대시보드, 포인트 후원 시스템 (실제 결제x), 채용 정보 캘린더 정도) 백엔드에서는 결제 기능을 제외한 다른 기능들을 모두 목표로 개발을 하는 것으로 합의를 내렸다. API 를 사용하지 않아도 개발한 내용이 사라지는 것은 아니기 때문에 그렇게 한다는 말씀을 해주셨는데, 모든 팀원들이 정확하게 동일한 목표를 가지고 달려가는 것은 아니라는 생각이 들었지만.. 그래도 취업을 위한 프로젝트라는 목적은 같기 때문에 나름 동의할만한 합의를 하게 된 것 같다. 

 

솔직히 이 경험이 개인적으로는 힘들었던 것 같다. 팀 규모가 작기 때문에 어떤 의견이든 자유롭게 주고받을 수 있어야 한다고 생각했는데 이런 팀 분위기로는 그렇게 하기는 어렵다는 생각이 들었고 프로젝트를 진행하면서 소통의 부재로 더 큰 갈등 혹은 불필요한 에너지 소모를 하게 될 것 같았다. 그래서 프로젝트를 시작한지 1~2주가 되어가는 시점이었지만 그동안 주 2회로 진행하자고 했던 회고를 매일 1회씩은 하자고 의견을 제시해서 현재까지 진행중이다. 

UI 프로토타입 완성

프로토타입 일부분~!

피그마를 이용해 UI 프로토타입을 완성했다. 처음에는 간단한 와이어프레임에서 발전시키고자 했는데, 명확한 디자인이 없으면 퍼블리싱 단계에서 애를 많이 먹을 것 같아 어느정도 고도화된 프로토타입 제작으로 노선을 변경했다.

이미 잘 만들어진 질문/답변 커뮤니티인 inflearn 을 많이 참고했고, 비슷한 서비스를 가진 네이버 지식인이나, 당근 마켓(후기 시스템) 등을 참고하여 디자인했다.

 

서비스의 컨셉이 '뉴비에게도 따듯한 개발자 커뮤니티' 이기 때문에 이를 잘 연상시킬 수 있는 네이밍과 컬러를 메인으로 잡고 디자인을 진행했다. 디자인이 나오고 나서 백엔드 분들도 생각보다 너무 좋아해주셔서 굉장히 뿌듯했다 ㅎㅎ

컴포넌트별 플로우 차트 작성

UI 프로토타입을 토대로 퍼블리싱을 진행하려는데, 화면을 각 컴포넌트 단위로 분리하고 작업에 들어가려고 하니 로직을 어떻게 짜야 클린 하면서 제대로 동작하도록 짤 수 있을까 고민을 많이 하게 되었다. 처음에 페이지별로 플로우차트를 작성해서 페이지에 어떤 기능이 필요한지 명확하게 도출할 수 있었던 것처럼, 컴포넌트 안에서도 어떻게 동작할지 알면 좋을 것 같아 플로우차트를 작성했다.

플로우 차트를 그리는데 많은 시간이 소요되었지만 어떤 데이터를 보내줘야 하고, 어떻게 요청을 보내야하는지도 알 수 있었고 사용자의 동작에 대해서 어떻게 피드백을 줘야 하는지도 명확하게 나와서 좋았던 것 같다. 지금도 중간에 변경된 부분이 있어서 수정이 필요하지만... 여러 시행착오를 거치고 있다. 이미 정해진 서비스를 분석해서 요구사항을 도출하는 것과, 직접 기획을 하면서 도출하는 것은 많이 다르다는 것을 느꼈다. 

💡WEEK 3 (2022-1114 ~ 2022-1120)

본격적인 컴포넌트 퍼블리싱에 돌입하면서, 백엔드와 API DTO 에 대해서 협의를 하는 과정을 거쳤다. 

내가 담당하게 된 부분은 질문 리스트에서 클릭했을 때 보여지는 질문 상세 페이지와, 답변을 채택하게 되면 보여질 태그 선택 및 메시지, 포인트 후원 페이지이다. 작업 우선순위는 먼저 API 작업이 진행될 질문/ 답변 / 댓글 CRUD 부분이고 그 뒤에 답변 채택에 대한 UI 퍼블리싱을 진행했다.

 

이번 주에 가장 힘들었던 부분은 컴포넌트를 어떻게 분리해야 할지... 

현재 우리의 컴포넌트 디렉토리의 구조는 componetns > 개발자 이름 > 각 컴포넌트 이런 식인데, 멘토님께서 이런 식의 구조는 나중에 확장을 생각했을 때 담당자가 바뀌는 경우가 정말 많기 때문에 좋지 않다고 말씀해주셨다. 처음에는 약간 atomic design 느낌으로 모든 컴포넌트를 다 잘게 쪼개서 진행할까 생각해봤는데, 그렇게 진행하니 시간도 너무 오래걸리고 무엇보다 파일이 너무 많아져서 정리가 되지 않는 것 같았다. 그래서 일단 중복이 되더라도 목표한 한 페이지에 대해서 코드를 대부분 작성하고, 많이 중복이 되어서 분리가 필요한 코드에 대해서만 컴포넌트 분리 작업을 진행했다. 

 

질문 상세페이지 작업을 완료한 뒤에 통신 로직을 간단하게나마 작성해보고 싶어서 msw 를 사용해보았다. 어느정도 주고 받는 데이터가 정해져있기 때문에 그걸 토대로 가짜 서버를 만들었다. msw 가 좋은데, 이상하게 제대로 통신이 되지 않는 때도 많다. 다음주 쯤이면 ngrok 등을 사용해 서버 통신이 가능할 것 같아서 msw 는 많이 사용을 안할 것 같다. 개발자가 직접 서버 코드 비슷하게 작성하는 것은 좋은데 이렇게 간단한 내용을 테스트 할 때는 json-server 가 훨씬 간단하고 편리한 것 같다. 

 

이제 다음주부터 본격적인 기능에 돌입하면서 데이터 캐싱 기능을 추가하려고 하는데, 기능에 대해서는 이해가 되지만 이떤 부분에 어떻게 적용해야할지 조금 고민이 된다.