[우아한테크캠프] 3차 프로젝트 회고

조금 늦은 글이지만

3차 프로젝트가 끝났다. 2차 프로젝트에 비해 실 난이도는 좀 낮은 편이었다.

(일단 웹소켓이 없었고...)

다른 팀의 사람들 대부분 이번 프로젝트는 조금 난이도가 낮았다고 했다. 그래서 나름 저번 프로젝트에서 넣고싶었던 것들 못해봤던 내용들을 위주로 작업을 추가할수 있었고 개인적인 욕심도 조금 내보았었다.

나름 저번 프로젝트에 비해 타입스크립트도 상대적으로 잘 사용을 했다 !

(프로젝트가 끝나구 돌아봤을 때 any타입이 손에 꼽을 정도로 줄어든 것을 확인 할 수 있었다.) 

그 외의 나만의 욕심들은 회고하면서 알아보자

 

키워드 :

셋팅 관련 : TypeScript
기술 관련 : JWT(Refresh Token), Router (History Api), SCSS(Theme), OAuth, ORM(sequelize)
서버 및 백엔드 : AWS EC2 (ubuntu), Mysql, PM2

 

1. 시작

- 이전 프로젝트와 같은 팀번호인 5팀으로 배정되고 같은 조였던 분중에 한분을 만나 빠르게 아이스 브레이킹이 되었다. 이 때문인지는 몰라도 시작은 굉장히 빠르게 진행되었다. 프로젝트 구조나 base 컴포넌트 구조를 2차 프로젝트에서 진행했던걸 그대로 가져와 사용하고 조금씩 필요에 맞게 수정하기로 했다. 그나마 다행이었던 점은 이전 내팀에서 사용한 구조를 가져와 사용했기 때문에 나는 프로젝트를 빠르게 적응 할 수 있었다. 

첫 날부터 바로 코딩을 시작했었다.

2. 프로젝트 중 겪었던 문제

1. History API

 - 이전 프로젝트에서는 해시라우터를 이용해서 페이지 이동을 진행하였는데 이번 프로젝트에서는 history API를 사용하라고 해서 api를 좀 수정했어야 했다. 대충 알고만 있었지 어떤 방식으로 적용해야하는지 이런 것에 대한 감은 하나도 잡히지는 않은 상태였고 고민을 꽤 했었다. 결국 다른 팀의 코드를 참고 하고 이해를 했는데...기본적인 라우팅은 다음과 같지만

a tag에 직접적으로 onclick을 주지않고 커스텀 이벤트를 발생시켜 모든 태그에서도 클릭시 이벤트 동작만 하면 라우팅 동작이 될수 있도록 이번 프로젝트에서 작업을 진행했다.

 히스토리 api 에서 가장 중요하게 여길 점은 popState, pushState 두가지를 이용해야한다. 
1. popstate는 웹사이트의 뒤로가기 앞으로가기의 동작에서 발생하는 이벤트이고
2. pushstate는 웹사이트 내부에서 클릭으로 href의 실제 이동을 막고 hitory에 저장하여 다른 컴포넌트를  화면에 그려주기 위한 이벤트를 등록하는 것이 바로 요점이다.
3. 경로가 바뀔때마다 컴포넌트 렌더링요청을 진행하면 완성.

2번의 경우 확 이해가 안될 수 도 있는데 다음과 같다.

const pushStateEvent = (event, path) => {
  //href 막기
  event.preventDefault();
  //히스토리에 저장할 기본데이터, 경로, url에 보여질 경로(옵션)
  window.history.pushState(data, path, window.location.origin + pathname)
  //경로 파악후 원하는 컴포넌트 렌더링 진행
}

<a href="path" onclick={(e) => pushState(e, path)}>{내용}</a>

2. 프로젝트 구조

 - 이 부분은 매번 프로젝트를 진행할때마다 하는 고민인 것 같다. 다만 이번의 경우 mvc, mvvm, 옵저버 패턴 중 하나를 사용하라고 해서 사용을 하게되면서 어느정도 구조가 잡히게 되었다. 이 덕에 프론트는 문제가 크게 없었으나 백엔드가 문제였다. 백엔드의 경우 항상 라우터에다 함수만 따로빼서 작성하는 방식으로 진행했는데 그 외의 떠오르는 방식은 크게 없었고 결국 다른팀...ㅋㅋㅋ 그리고 몇가지의 참고자료를 이용해서 더 깊게 구조분해를 하여 service, controller, repository 등으로 나누고 폴더별 기능을 명시적으로 확인 할 수있게 진행하였다. ( 백엔드 구조 짤때는 내 역할이 비중있게 다뤄져서 학습이 많이 되었었다. ) 

 

3. 옵저버 패턴

 - 나는 패턴에 대해서 아무것도 모르고 있었다. mvc, mvvm 등 말만들었지 내가 잘사용하고 있는지 이게 맞는지 아무것도 모르고 진행을 했었고 이부분에 대해서도 공부를 많이 했었다..... 다만 아직도 mvc, mvvm등의 구조는 명확히 파악하고 있지 않다는 점이다. 옵저버 패턴의 경우 따로 작성을 할 예정이다. 내가 진행한 바닐라 자바스크립트에서의 옵저버 패턴을 가볍게 말하자면

1. 옵저버는 해당 데이터를 다루고 있는 컴포넌트의 최상위 컴포넌트에만 등록한다.
 - 부모, 자식 둘다 같은 옵저버의 데이터를 쓰고 있을 경우 부모컴포넌트에만 등록해주면 된다.
   (기본적이지만 이 때문에 중복호출이 일어나는 부분을 많이 보았다....)
2. 컴포넌트가 마운트 될경우 옵저버를 등록한다.
  ( 여기서 등록한다는 것은 컴포넌트의 key값과, render 함수를 등록하는 것이다.)
3. 어떠한 동작을 통해 옵저버 데이터 변환이 일어날 경우 옵저버에 등록된 컴포넌트들의 함수를 각각 실행해준다.
 (notify라고도 한다)
4. 짜잔 옵저버에 등록된 컴포넌트 모두가 다시 렌더링 되는 것을 볼수 잇다.

3. 프로젝트 중 적용한 내용

1. JWT에 refresh token을 추가하였다.

 - 이전 프로젝트에서 아쉽게 못한 것중에 하나이다. accesstoken과 refreshtoken을 받고 만료 검증을 하고난뒤 두개 모두 만료가 되지않는 이상 로그인이 계속해서 유지가 될 수 잇도록 하였다. 이전에는 accesstoken 값으로만 하여 accesstoken의 유효기간이 지나면 무조건 재 로그인을 진행했어야 했는데 refresh를 통해 원활한 로그인 상태 유지가 가능해졌다.

 

2. 글로벌 테마를 적용하였다.

 - 다크모드, 라이트모드 색상을 지정하였다. scss를 이용해 하였으며 처음 프로젝트 시작할때부터 테마부터 적용하고 진행했다. 사실 이것만큼은 나의 개인적인 욕심이었으나 너무 만족스럽게 잘 되었다는 점이 좋았다. 기본 시스템 설정을 기준으로 색상을 바꿀수 있다는 것 과 여러가지 css 중복제거를 많이 했던점이 굉징히 만족스러웠다.

 

3. 시퀄라이저를 사용했다.

 - 이번에는 orm을 무조건 사용해야해서 그중 시퀄라이저 orm을 사용하였다. 가장 인지도가 높고 자료도 많고 범용적이어서 선택을 했으며 팀원과 내가 orm에 익숙하지 않다는 점도 한몫을 하였다. 다만 원래 쿼리문이 더 익숙해서 그런지 여럿 작업중 어려운점들이 있었다.. 그중 가장 컸던 것은 항상 orm쿼리를 날릴때 별도의 옵션들을 설정해줘야 했다는 점이 있었다. 처음 사용해서 어려웠던점이 많았었는데 다른팀의 타입 orm이나 다른 orm을 사용한 것을 보았을 때 일반 시퀄라이저를 사용하는 것보다 저 깔끔하게 코드가 작성된 것들을 볼수 있었고 나와 팀원은 시퀄라이저 쓰지 말자라는 결론에 도달하였다...;; (다만 순수 시퀄라이저를 썻기 때문이고 시퀄라이저-타입스크립트를 사용하면 생각이 또 바뀔수가 있을 것 같다.)

 

4. OAuth를 적용하였다.

 - 단순 깃허브 OAuth만 적용하였지만 이를 통해 회원가입과 로그인을 구현하였다. 이전에 페이스북, 구글 등을 적용한 적은 있었는데 깃허브는 처음이어서 여기저기 쑤시고 다녔었다. 지금생각해보면 막상 크게 어렵지는 않은데 시작까지의 접근 방식이 조금 어려웠었다.

 

4. 협력에서의 아쉬운점.

 - 사실 이번 프로젝트는 협업 보다는 분업에 가까운 프로젝트였다. 팀원은 차트부분을 작업을 하였고 나는 그 외적인 부분 전반적인 페이지 셋팅이나 백엔드 구조작업 등을 진행했었다. 작업하는 부분이 딱 나눠져 있어서 거진 개별작업이었고 중간중간 어려웠던 점들 공유하면서 진행했었다. 여기서 나타나는 문제점은 저번차 프로젝트와 동일하게 큰 기능적으로 팀원의 코드를 이해하지 못한 것들이 크다. 이번 프로젝트에서 pi차트, 선그래프 차트 등을 만들었어야 했는데 이부분은 팀원이 담당하여서 나는 사실 차트에 관한 코드에 대해 자세히 아는 바가 없다. 많이 아쉬운점이긴 하다... 개선해야할 방향을 찾아야 하긴하는데 코드 리뷰를 좀더 빡빡히 달고 자주소통하는 방법 밖에 생각나는 것이 없다..ㅠ

 두 번째로는 가끔 생각치 못하게 팀원과의 소통이 안된상태로 작업을 진행하게 될수 있다. 막상 코드를 짜고나니 구조에 변화가 있거나 중요 라이브러리를 추가하거나 등.. 결국 팀원은 다짜여진 코드를 볼수 밖에 없고 여기서부터는 시간상 수긍하고 진행해야되는 상황도 벌어질 수 있다. 이런 부분은 참 협력에서의 아쉬운게 많이 드러난다. 나도 조심하려고 조심하려고해도 최대한 소통을 많이 하려고하지만 생각치도 못한 부분에서 이런 일이 벌어지기도 하기 때문에 아직도 많은 개선이 필요하다...ㅠ

5. 최종회고

- 이번프로젝트는 협업보다는 분업에 가까웠고 이 때문인지는 몰라도 나에게 배정된 업무에 대해서는 공부를 많이 하게 되었다는 점이 가장 컸다. 특히나 옵저버패턴, sever프로젝트 베이스 구조, 히스토리 api, orm 등은 진짜 공부가 많이 되었다. 이와 비슷하게 개선점도 엄청많이 나타났다... 협력에서의 아쉬운점은 그대로 가져오고 그에 더하면 아직도 커뮤니케이션 방식에 대해 부족함을 느끼고 있다.... 다음 프로젝트에서는 좀더 소통을 잘하는 방향으로 나아갔으면 하는데....

참고내용

[1] 히스토리 API