Final Project Log - 1

 

 

First Project 시작한 것도 얼마 지나지 않은 듯 한데 정신을 차리고보니 파이널 프로젝트를 시작하고 있었다. 이번 주에 파이널 프로젝트를 시작해서 이미 평일동안 열심히 팀원들과 함께 프로젝트 SR 문서 (Serviece Requirements)를 작성했다.

 

이번 프로젝트의 핵심 아이디어와 kick은 빠르게 결정이 되었는데 문제는 생각보다 SR에서 소요가 많이 필요한 서비스 였던 것 같다. 아직 실질적인 코드 작성은 시작하지 않았지만 문서 작업만 하더라도 이게 쉽지 않은 프로젝트라는 것을 말해주는 듯 하다.

 

First에서는 2주 동안 진행되었던 것에 반해서 Final은 4주 동안 진행된다. 그리고 상대적으로 더 높은 완성도가 기대되는 것은 말할 것도 없는 듯하다. 그리고 이전에 부트캠프 커리큘럼에서 학습했던 스택들 외에도 학습하여 자유롭게 적용이 가능하다. 그래서 이번 기회에는 기존과 다른 프레임워크 등을 적용해볼 생각에 다소 기대가 된다.

 

아무래도 1주차 동안 코드 작성이 없어서 이번 회고는 First 대비하여 바뀌어진 점들과 그에 관한 생각들을 정리해보고자 한다.

 

---

1. 문서 작성 툴

SR 단계에서는 문서 작성에 많은 시간들이 소요된다. 근데 많은 시간이 소요되면서도 사용하는 툴이 불편하면 아주 모니터를 한대 쳐주고 싶은 욕망이 싹튼다. 지난 번 First Project 당시에 나는 gitbook으로 API문서를 작성하다가 그런 욕망을 느꼈다.

 

gitbook으로 API 문서를 작성하니 한글도 제대로 안 먹히는 문제점과 git 방식 처럼 수정한 내용을 merge 하는 과정에서 수 없이 많은 에러로 나의 심금을 많이 울려줬다. 그래서 이번에는 팀원들에게 제발 api 문서 툴을 바꾸자고 적극적으로 어필했고, swagger를 사용하게 되었다. swagger는 우선 한글 적용이 상대적으로 훨씬 잘되고 yaml파일로 내용물을 작성한다. 웹에서 작성하던 환경들이 뭔가 렉 걸린다 싶으면 바로 로컬 vs code로 작업하고 내용물을 따로 업로드 시키면 된다.

 

API 문서 말고도 사람 열받게 만들던 부분이 있었는데 와이어프레임/프로토타입 작성 툴이다. miro는 기존 First 프로젝트에서 활용할 때, 사용하기에 굉장히 캐주얼하고 일전에 잠깐 사용해본 경험이 있기에 활용했었다. 그런데 항상 이런 시각화 자료를 만드는 툴을 쓸 때마다 객체 요소들을 관리하는 것이 불편하면 그 때부터 암이 걸리는 경험으로 인식되는 듯하다.

 

miro를 사용하면서 이런 느낌을 좀 많이 받았고, Final에서는 와이어프레임이 아닌 프로토타입으로 제출하도록 이야기 해주었다. 그런 이유로 figma를 사용하게 되었는데 사용하면서 내가 예상한 것보다 정말 별의별 기능이 다 있어서 굉장히 놀랐다.

아마 와이어프레임이나 프로토타입 비주얼을 만드는 툴 중에서는 원탑이 아닐까...

 

우선 컴포넌트/인스턴스 개념이 있어서 원본(컴포넌트)에서 복사본(인스턴스)를 가져와 사용한다. 프로토타입이라고 인식하는 프레임 안쪽에는 절대 컴포넌트 원본을 넣지 않고 인스턴스를 넣어 사용된다. 여기서 컴포넌트를 수정하면 연결된 인스턴스들은 모두 컴포넌트에서 변경된 사항이 적용되어 변형된다. (이건 진짜 실제 개발에서 컴포넌트 관리하는 개념과 매우 유사했다)

 

단순한 사각형에 색깔이나 곡선 테두리 등등 여러가지 속성을 설정하고 inspect를 하면 적용했던 속성들을 CSS 코드로 표시해준다. 나중에 이거 가지고 그냥 CSS에 복붙하면 된다.

그 외에도 아이폰 목업으로 화면 진행 구성을 시각적으로 테스팅 해볼수도 있고 아주 갓 툴의 냄새를 풀풀 풍겼다.

 

2. 활용 스택

이전 First에서는 부트캠프 커리큘럼에서 학습한 스택만을 사용한 것에 반해 이번엔 스택 선택에 자율권이 주어진다. 그렇지만 관련해서 왜 이 스택을 사용하였는지 등에 대한 근거는 존재해야한다.

 

기존 프로젝트를 진행하면서 express를 바닐라 자바스크립트로 구현했었다. 그런데 이렇게 활용하게 되면 이후에 데이터 타입에 따른 에러 등이 빈번하게 발생되었는데 그래서 이번에는 프론트와 백엔드 모두 타입스크립트를 사용하기로 팀 내에서 협의했다. 백엔드의 경우에는 express를 통해서 타입스크립트 작성이 가능하다. 그렇지만 일부 셋팅 등 사전작업이 필요한데 반해서 nestJS는 기본적으로 타입스크립트를 지원하기 때문에 nestJS를 프레임워크로 활용하기로 하였다.

 

이번 프로젝트의 kick을 고려하는 과정에서 상당히 데이터 형태가 고정적이지 않고 이후 기능들을 점진적으로 개선해나가는데 데이터 스키마를 고정적으로 활용할 수 없을 깨닫게 되었다. 이런 이유로 RDBMS를 활용하지 않고 NoSQL인 mongdb를 활용하기로 하였다. 

 

db를 mongodb로 활용하기로 하면서 ORM을 nestJS와 같이 많이 활용되는 typeORM을 사용하기로 하였는데 최근에 typeORM에서 mongoDB를 쓸 때 버전에러가 뜬다고 해서 mongoose를 활용하는 방향으로 고려하고 있다.