프로젝트 회고

 항해99의 프로젝트가 어느덧 끝이 났다. 하루에 하나씩 글을 썼다면 오늘 글의 제목이 99일 차가 됐겠지만 그렇지 못한 부분에 대해 반성을 하며 이 글을 작성하고자 한다. 

 

 오늘 글의 주제는 최종 프로젝트에서 사용한 기술들이다. CS 지식이 거의 없다시피 한 상태로 프로젝트를 시작했기 때문에 항해99를 진행하면서 배웠던 기술 또는 프레임워크, 빌드 도구들 위주로 글이 작성되겠지만, 사용했던 것들의 특징과 장, 단점에 대해서 글을 작성할 것이다.

 

빌드(Vite)

 최종 프로젝트의 빌드는 vite로 진행을 했다. 강의에서는 CRA를 활용해서 빌드를 했지만 최종 프로젝트에서는 vite를 통해 빌드를 했는데, 그 이유와 CRA, Vite의 차이점에 대해서 알아보자.

 

CRA(Create React App)

 CRA는 웹사이트에 대한 기본 파일 구조 및 내부에서 작동하는 Babel 또는 Webpack과 같은 패키지와 같은 사전 구성된 항목이 함께 제공된다. 여기서 Webpack은 모듈 번들러를 말하는데, 자바스크립트 파일들을 모듈화 시켜서 관리하게 해주는 라이브러리가 Webpack이다. CRA를 활용하면 'yarn create react-app 폴더명'을 통해 React 앱의 기본적인 구성을 한 번에 해준다. 이러한 CRA는 안정적이고 제로 설정이 필요한 경우, 특히 큰 프로젝트에서 빌드 시간이 길어질 수 있음에도 불구하고 사용하기 좋은 선택이다.

 

Vite

 vite는 CRA와 마찬가지로, 빌드 도구이지만, CRA와 다르게 모듈 번들러로 Rollup을 사용하는데 이는 ES 모듈을 중심으로 설계되었다. 따라서 ES 모듈을 직접 브라우저에 제공하여 빠른 HMR(Hot Module Replacement)과 빠른 서버 시작을 가능하게 한다.  이러한 Vite는 빠른 개발 빌드, 현대적인 도구, 구성의 유연성을 원할 때 이상적이며, 큰 프로젝트가 아닐 때 사용하는 것이 적합하다.

ES 모듈: ECMAScript(자바스크립트 표준)이며, 'import'와 'export' 문을 사용하여 모듈 간의 의존성을 관리하는 표준 방식

HMR(Hot Module Replacement): 앱이 실행 중인 상태에서 한 모듈의 코드를 변경하고, 그 변경을 즉시 반영할 수 있게 해주는 기술

 

 

Vite 사용이유

vite 사용이유는 간단하다. 우리의 프로젝트는 6주짜리 단기 프로젝트였고, 빠른 개발 빌드를 위해서 사용하였다.

 

 

React-Query

서버와의 통신을 하기 위한 라이브러리로는 React-Query를 사용하였다. 사용한 이유는 아래와 같다.

1. 직관적으로 API 사용 가능
2. 보일러 플레이트 코드를 줄임: Redux를 사용할 때 어쩔 수 없이 작성해야 하는 보일러 플레이트 코드를 사용하지 않을 수 있게 되면서 코드의 복잡도를 낮추고, 유지보수의 용이성을 높일 수 있다.
3. 캐싱된 데이터 사용: 캐싱된 데이터를 활용해서 서버에 불필요한 요청을 하지 않아 성능을 향상시킬 수 있다.

 

 

React-Router v6(BrowserRouter)

먼저 버전 6를 사용한 이유는 Outlet을 통해 중첩 라우팅을 구성할 수 있었기 때문이다. Outlet을 통해 중첩 라우팅을 구성하는 것의 장점은 아래와 같다.

1. 코드 재사용성 증가: 공통 레이아웃 컴포넌트를 한 번만 작성하고, 그 안에서 자식 라우트를 렌더링 할 수 있다.
2. 코드의 가독성, 유지보수성 향상: 부모 컴포넌트에서 자식 컴포넌트의 위치를 지정하기만 하면 되기 때문에 가독성과 유지보수성을 향상함
3. 에러 페이지 컨트롤 용이: 에러 페이지를 한 번에 관리할 수 있음

라우팅 방법은 BrowserRouter을 사용하였는데, BrowserRouter는 URL의 경로를 사용해서 라우팅을 관리한다. 이를 사용했을 때의 장점은 아래와 같다.

1. Clean URLs: 해시(#) 없이 깔끔한 URL을 제공한다.
2. History API 사용: 브라우저의 내장 history API를 사용하여 더 자연스러운 페이지 전환과 복잡한 내비게이션을 처리할 수 있다.

 

 

TypeScript

 타입스크립트를 사용한 가장 큰 이유는 사실 취업에 도움이 되기 때문이었다. 많은 기업들에서 타입스크립트를 사용하고, 타입스크립트는 기본적으로 깔고 들어가야 한다고 생각했기 때문이다. 하지만 타입스크립트를 사용하면서 왜 사용하는지 알 것 같았다. 이유는 타입을 지정해 주면, 해당한 타입이 들어가지 않으면 오류가 발생하고, 매개변수의 누락을 알아서 체크하기 때문에 에러 컨트롤 하기에 편리했다.

 

 

Browser Image Compression

 이는 이미지의 용량을 줄여주는 라이브러리이다. 사용하게 된 가장 큰 이유는 Spring Boot에서 저장할 수 있는 이미지의 최대 용량은 1MB였기 때문이다. 물론 서버 측에서 변경을 할 수 있지만, 불필요하게 이미지가 큰 경우 렌더링이 느려진다는 단점이 있기 때문에 이미지를 압축하는 편이 낫다고 생각하고 사용을 하였다.

 

 

SockJS / Stomp

채팅 기능 구현은 SockJs와 Stomp를 활용해서 했는데 이를 사용한 이유는 아래와 같다.

1. SockJS는 웹소켓이 지원되지 않는 환경에서도 연결을 보장
2. Stomp는 서버와 클라이언트 간의 복잡한 메시징 흐름을 단순화하여 개발자가 쉽게 실시간 통신 기능을 구현할 수 있도록 도움
3. 이 조합은 다양한 웹 환경에서의 높은 접근성과 빠르고 안정적인 메시지 교환을 가능하게 함

 

 

SSE(EventSource, Toast)

알림 기능은 SSE를 사용해서 기능을 구현했는데 EventSource 객체를 활용하여 서버에서 보내는 텍스트 스트림을 수신하였다. 또한 Toast 라이브러리를 활용하여 서버로부터 받은 알림을 웹 페이지에 보여주었다.

 

 

---

프로젝트 후기

 프로젝트를 진행하면서 큰 사건이 하나 있었는데 최초 우리가 1920px를 기반으로 디자인을 해서 프로젝트를 구성했는데, 유저 피드백을 받아보니 맥북과 같이 작은 화면에서 보면 좌우로 스크롤을 해야 돼서, 보기에 불편하다는 피드백이 많았다. 프로젝트 마무리가 2주도 안 남은 시점에서 받은 피드백이었고, 대규모의 코드 수정이 필요한 부분이어서 살짝 멘탈이 붕괴가 됐었다.. 하지만 디자이너님이 빠르게 새로운 디자인을 주셨고, 같이 작업했던 프론트 개발자분과 며칠을 밤새 작업한 덕분에 프로젝트 기한 안에 잘 수정할 수 있었다. 이번 일을 계기로 초반 기획의 중요성을 크게 느꼈다.

 

 99일이 길게 느껴지기도 했지만, 막상 끝 지점에 도착하니 빠르게 지나간 것 같기도 하다는 생각이 든다. 미니 프로젝트, 본 프로젝트, 중간중간 과제 등을 할 때 같이 진행을 했던 팀원들과 마찰 한 번 없이 잘 끝난 것에 감사하고, 모두들 취업이 잘 돼서 나중에 꼭 성공한 상태로 만나게 되면 참 좋을 것 같다.