[항해99] WIL 7주차 - 실전 프로젝트 1주차 (후기)

서론

• 7/16 ~ 7/22의 클론코딩 기간이 종료되었습니다.
• 7/23 ~ 9/3의 실전 프로젝트 기간이 시작되었습니다.
• 튜터님의 미니프로젝트 코드리뷰가 진행되었습니다.

일정

• 7/16 (금) ~ 7/22 (목) : 클론코딩 진행
• 7/23 (금) ~ 9/3 (금) : 실전 프로젝트 진행
• 7/20 (화) : Node.js 미니프로젝트 코드리뷰
• 7/23 (금) : 실전 프로젝트 발제

 

6주 차 클론코딩

• 7/16 ~ 7/22 클론코딩 기간이 종료되었습니다.
• tumblr를 주제로 클론코딩을 진행하였습니다.
• 총 22개의 API를 제작하였습니다.
• Sequelize만으로 MySQL DB 통신을 진행하였습니다.
• DB를 Migrate 할 때 트리거를 생성하도록 설정하였습니다.
• AWS EC2, Synology Docker에 클론코딩 서버를 업로드 하였습니다.
• Notion : https://www.notion.so/99-1-3c5a2aec7ac94d46b8d1e95d4e873bb8
• Github : https://github.com/archepro84/tumblrClone
• API : https://docs.google.com/spreadsheets/d/16bei4mL8K_fA4-Z0Fx30NjPpM8aKTkHc4ema2CfYSG4/edit#gid=328670061 
• Youtube : https://www.youtube.com/watch?v=HLYTArLgdeY

 

6주 차 클론코딩 이야기

• 프로젝트의 구상으로 첫날을 보내고 토요일 ~ 화요일까지 API를 구현하였습니다. 단순한 CRUD를 Express 모듈을 사용해 처리하는 것은 그리 어렵지 않았고, Joi, Middleware 사용이 물 흐르듯이 자연스러워 Node.js에서 구현하는 것은 많은 어려움을 겪지 않았던 것 같습니다.
• SQL 중요성을 매번 깨닫고 있습니다. 이번 프로젝트에서 모든 API를 구현하던 시간 중 SQL을 작성하기 위해 사용한 시간이 80% 이상이었던 것 같습니다. 테이블의 개수가 이전 프로젝트보다 2배가량 증가하였고, 원하는 테이블을 조회하기 위해 SQL에서 어떤 기능을 조합해야 하는지 찾는 시간이 가장 많이 사용되었던 것 같습니다. 
• mysql 모듈을 배제하고 모든 Query를 Sequelize.query 라는 함수를 이용해 Raw Query로 변경해보았습니다. 이전 프로젝트에서는 jest, supertest를 이용해 테스트 코드를 실행할 때마다 mysql 모듈이 매번 실행돼 테스트 코드가 종료되지 않았던 상황이 발생하였고, 이를 해결하기 위해 Sequelize 모듈만으로 SQL Query를 처리하여 테스트 코드를 실행하더라도 무의미한 루프가 돌지 않도록 설정하였습니다.
• MySQL에서 Trigger를 사용해보았습니다. 팔로우, 게시글 좋아요, 리블로그 기능이 발생했을 경우 매번 Alarms 테이블에 데이터를 추가하는 행위를 반복하는 것이 비효율적이라고 생각하였습니다. Follows, Favorites 테이블에서 데이터가 생성될 때, Posts의 테이블에서 reBlog가 존재할 때 Alarms 테이블에 데이터를 삽입하도록 설정하였습니다.
• Sequelize의 Migrate를 실행해 테이블을 생성할 때 Query를 실행하도록 설정하였습니다. Trigger와 같이 한번 정의하면 추가로 정의할 필요가 없는 것을 Sequelize가 실행될 때마다 삭제와 재정의하는 것은 효율적이지 않았다고 생각하였습니다. 그래서 Sequelize 에서 db:migrate로 생성될 때 테이블과 함께 Trigger를 생성하도록 설정해 단 한 번만 트리거를 정의하였습니다.
• API 중 Search, getPosts 기능에서 테이블을 조회하는 Query가 8번 이상의 서브쿼리를 참조하고 있습니다. 논리적인 구조는 이상이 없지만, 조회문에서 서브쿼리가 많아지게 될 경우 성능 저하가 발생할 수 있기 때문에 최적화를 하기 위해 어떠한 방식을 사용할 수 있는지 더 고민을 해봐야 할 것 같습니다.

클론코딩 ERD

실전 프로젝트 1주 차

• 7/23 ~ 9/3 : 실전 프로젝트 기간이 시작되었습니다.
• Node.js 백 엔드 3명, React 프론트 엔드 3명, 디자이너 2명으로 구성되었습니다.
• React Native를 이용해 안드로이드 모바일 프로젝트를 진행 중입니다.
• 와이어 프레임 구성을 완료하였습니다.
• 기술 스택 정리를 완료하였습니다.
• 팀장을 맡았습니다.
• 개인 Synology서버를 제공해 자료를 공유하였습니다.

 

실전 프로젝트 1주 차 이야기

• 드디어 최종 프로젝트인 실전 프로젝트가 시작되었습니다. 첫날부터 팀 배정으로 인해 수많은 우여곡절이 있었지만, 저희 팀은 아무런 이상 없이 조용하게 진행되었습니다. 
• 실전 프로젝트의 주제는 팀장을 지원할 때 제시했던 TRPG, 방 탈출 실시간 즉석 모임에서 모든 주제를 포괄하는 실시간 즉석 모임으로 수정되었습니다.
• 주제를 지정하고, 주제별 기술 스택을 정의하며, 와이어 프레임을 작성하는데 엄청나게 많은 시간이 소모되었습니다. 팀장의 관점에서 오전 9시 ~ 오후 11시까지 끊임없이 의견을 조율하고 선택하는 것이 힘들었습니다. 하지만 제출한 주제가 구체화하면서 프로젝트의 모양이 갖추어진다는 것에서는 엄청난 만족감을 느꼈습니다.
• 프론트 엔드와 협업을 하는 것은 미니프로젝트 > 클론코딩 > 실전 프로젝트 순으로 3번의 경험이 있지만, 디자이너분들하고 협업하는 것은 처음이라 많은 어려움이 있었습니다. 가장 먼저 디자이너분들이 어떠한 업무를 수행하는지, 어느 정도의 범위까지 도와주실 수 있는지, 그렇다면 백 엔드, 프론트 엔드 개발자들이 어느 부분을 도와 드려야 하는지 아무것도 알지 못하였기 때문에 서로 이야기를 하면서 많은 정보를 얻었습니다.
• 실전 프로젝트를 진행한 지 3일 정도의 시간이 지났습니다. 미니프로젝트, 클론코딩을 진행하면서 모두 팀장을 맡았고, 주제선정, 와이어 프레임 작성, API 문서 작성, DB ERD 구성이 1일이면 전부 끝났었습니다. 그렇기 때문에 이번 실전 프로젝트는 기간이 길어도 모든 정의는 2일이면 끝날 것으로 생각하였지만, 진행속도는 생각했던 것 이상으로 오래 걸렸습니다. 주제선정, 기술 스택 작성, Notion 회의록 작성만으로 하루를 소모하였고, 와이어 프레임 작성은 개발자들과 작성하는데 하루, 디자이너분들과 재구성하는데 하루를 소모하였습니다.
• 개발 계획도 정의, API 문서 작성, DB ERD 구성, 업무 배분 4가지의 업무가 남았습니다. 월요일 하루 만에 끝을 내는 것을 목표로 일요일인 오늘도 열심히 진행하고 있지만, 가능할지 아직 의문입니다. 
• 팀장의 입장에서는 백 엔드, 프론트 엔드, 디자이너 모든 분의 업무를 이해하고, 도움을 드릴 수 있어야 한다 생각합니다. 하지만 어떠한 방식으로 도움을 드릴 수 있을지 확실하게 생각하진 못했지만, 프로젝트를 진행하면서 차근차근 배워나가야 하는 것 같습니다.

배운 점

• 프로젝트 일정, 의견 조율법
• 협업의 마음가짐
• supertest, jest 테스트코드 작성법
• cookie 모듈
• MySQL procedure, function, trigger
• MySQL 스칼라함수, JOIN, UNION
• 마크다운 작성법

 

나의 생각과 이야기

• 클론 코딩 기간은 하루하루가 조용하게 흘러갔습니다.  코드리뷰 세션을 제외하고 특별한 세션이 많이 진행되지 않았고, 정기적인 팀 회의를 제외하면 미니프로젝트 기간과 비슷하게 흘러갔던 것 같습니다.
• 클론코딩 기간은 Node.js나 SQL과 같은 기술을 배우는 것이 아닌 배웠던 것을 더 익숙하게 사용하기 위해 땅을 다지는 작업을 하는 기간인 것 같습니다. 지금껏 배웠던 것을 바탕으로 실전 프로젝트를 진행하면서 어떤 부분을 배워야 할지, 그리고 어떠한 기술을 프로젝트에 접목해야 할지를 확실히 정의해 기술적인 성장을 해야 할 것 같습니다.
• 이전 프로젝트에서는 4~5명 정도로 팀원이 구성되었지만, 이번에는 디자이너분들을 포함해 총 8명의 팀이 구성되었습니다. 회의를 진행하면서 느꼈던 것이지만, 팀원의 숫자가 많아졌기 때문에 의견도 많이 나오게 되었고, 그러한 의견을 어떻게 중재해야 할지 많은 걱정이 생겼습니다. 해결방법은 바로 머릿속에 떠오르는 것이 아니기 때문에 시간이 지나면서 새로운 방법을 시도를 해봐야 할 것 같습니다.
• 기술 스택에 대해서 고민이 많아졌습니다. 우선은 프론트 엔드분들과 디자이너분들의 업무 능력을 확실하게 알지 못하고, 프론트 엔드에서는 새로운 리액트 네이티브라는 기술을 도입하면서 시간이 지체될 것 같다는 생각하였습니다. 그렇다면 차라리 이전에 어플리케이션을 개발했었던 제가 리액트 네이티브를 도와주면서 진행해야 하지 않을까 생각하였지만, 그렇다면 백 엔드의 추가적인 기술을 공부하지 못한다는 막다른 길에 몰리고 말았습니다. 해결방법이 존재하지도 않고 시간이 흐르고 있지만, 확실한 결단을 내릴 준비를 해야 할 것 같습니다.
• 팀원의 구성이 많아질수록 팀장은 고민이 많아지는 것 같습니다. 모든 팀장분들 힘내시길 바랍니다.