[회고] 위키 페이지 만들기 1차 회고

학과 위키 페이지를 만들게 되었다.

 

위키 페이지는 기존에 존재 했지만, 운영자를 찾을 수 없을 뿐만 아니라 소스코드를 볼 수 없어 업데이트도 불가능 한 상황이었다.

 

교육 봉사 동아리에서 회식을 하며 "위키 페이지 다시 만들어 볼까"하는 것을 동아리 회장님이 듣고 서버 운영비를 지원해 줄 테니 해보자 라고 하여 본격적으로 시작하게 되었다.

 

현재까지 위키 페이지 CRUD, 모바일 반응형, 다크모드, 모든 페이지 조회 기능이 구현되어 있으며 추후 위키 페이지 이상으로 학과 내에서 필요한 기능들을 추가하여 학과를 위한 커뮤니티로 발전시킬 계획이다.

 

1. 기술 스택

프론트엔드: NextJS 13

백엔드: Django

 

나는 이번 프로젝트에서 프론트엔드를 담당하게 되었다.

 

원래는 백엔드 개발을 주로 했었지만 이번에 같이 하는 동기가 개발이 처음이며 Django를 처음 배웠다.

 

따라서, 친구는 백엔드 연습을 하고 나는 백엔드를 도우며 프론트엔드 개발을 하게 되었다.

 

프론트엔드 기술 스택 선정에서 중요하게 생각한 요소들은 다음과 같다.

1. 새로운 프레임워크

2. 누군가가 프로젝트를 이어서 할 때를 대비

3. 개발 생산성

 

나는 기존에 React를 다뤄봤다.

 

하지만, 이번 프로젝트에서는 React를 사용하는 대신 다른 스택을 사용하고 싶었다.

 

또한, 누군가가 프로젝트를 이어서 할 수도 있기 때문에 (내가 졸업을 하거나 바빠서 더이상 관리할 수 없을 때) 수요가 많은(사용할 줄 아는 사람이 많은) 기술을 선택하려 했다.

 

마지막으로 빠르게 개발을 끝내고 운영하는데 목표를 두고 개발 생산성이 높은 기술을 선정하려 했다.

 

최종 후보는 Svelte Kit과 NextJS였다.

 

둘 다 디렉토리 기반의 라우팅을 지원하고 SSR을 지원, JS를 사용한다는 공통점이 있었다.

 

하지만, Svelte Kit은 여러 장점에도 불구하고 사용하는 사람이 적고 학습에 대한 수요도 없을 것으로 판단되어 NextJS를 사용하게 되었다
(개인적으로 개발 속도 관련해서는 Svelte Kit에 장점이 많다고 생각한다)

 

Django에 있는 "위키 앱"을 이용하면 Django 풀스택으로 빠르게 개발할 수 있었지만, 역할의 분리를 위해 프론트엔드와 백엔드로 구분하여 개발하게 되었다.

(위키 앱의 경우 필요 없는 기능이 많다고 생각했다)

 

그 결과, 각자 담당하는 부분만 신경써서 개발하면 되었고 나는 UI(디자이너가 없음...), UX 등에 집중하고 백엔드 개발자는 로직, 데이터에 집중할 수 있었다.

 

2. NextJS 13

기술을 선택하던 중, NextJS의 13 stable 버전이 출시되었다.

 

프로덕션 환경에서 사용할 수 있다는 글과 함께 여러가지 변경점이 생겼다.

 

하지만, 나는 NextJS 12버전을 사용해본 적이 없었기 때문에 차이점을 체감할 수는 없었다.

 

특별히 어려웠던 점은 "서버 컴포넌트 VS 클라이언트 컴포넌트"였다.

 

구분하는 기준을 잡는 것이 어려웠고 함수들이 어느 컴포넌트에 들어가냐에 따라 다른 결과를 보여줬다.

 

2-1. 서버 컴포넌트 VS 클라이언트 컴포넌트

NextJS 13의 컴포넌트는 기본적으로 서버 컴포넌트이다.

 

내가 그냥 컴포넌트를 하나 만든다면 이것은 서버 컴포넌트가 된다.

 

SSR에 활용되며 데이터 fetch 등을 모두 서버에서 처리하게 된다.

 

만약, 내가 컴포넌트 파일의 최 상단에 'use client'라는 문구를 적으면 이것은 클라이언트 컴포넌트이다.

 

클라이언트 컴포넌트에서는 useState, useEffect와 같은 리액트 문법을 사용할 수 있다.

 

만약, 서버 컴포넌트에서 useState와 같은 리액트 문법을 사용하려 한다면 에러가 발생한다.

 

3. TailwindCSS

NextJS를 사용하기로 했을 때, 디자인과 관련하여 styled-component와 tailwindCSS 중에서 어떤 것을 선택할지 고민했다.

 

사용해보지 않은 tailwindCSS를 사용해보고 싶었고(최근 뜨고 있다) 다크모드, 반응형 등에서 장점이 있다고 생각하여 tailwindCSS를 사용했다.

 

사용해보니 다크모드, 반응형을 적용할 때 매우 간편했다.

 

또한, 커스터마이징이 쉬워 자주 사용하는 색상 등을 마음대로 가져다 쓸 수 있는 것이 장점이었다.

 

클래스 이름이 길어진다는 단점이 있지만 VSC의 익스텐션을 사용하면 일관된 순서로 정렬이 되어 단점을 어느정도 상쇄시킬 수 있다.

 

4. Vercel

배포는 Vercel을 이용했다.

(처음에는 AWS를 사용하려 했지만 인스턴스 비용이 부담되어...)

 

NextJS를 만든 Vercel에서 배포를 해준다 = NextJS에 특화된 배포 가능 이라는 생각으로 Vercel을 선택했다.

 

Vercel을 사용하면 CI/CD를 구축할 필요가 없다는 장점이 있다.

 

main 브랜치에 push 한다면 자동으로 빌드 및 배포가 된다.

 

또한, 도메인을 자유롭게 사용할 수 있다.

 

물론 .vercel.app으로 끝나야 하지만 중간에 들어가는 부분은 자유롭게 수정할 수 있다.

 

main 브랜치가 production 배포라면 다른 브랜치에 푸시하는 코드는 preview로 배포가 된다.

 

실제 production은 아니지만 임시로 배포가 되어 모바일 등에서 변경 사항을 테스트 하기에 좋았다.

(가격도 무료다)

 

마지막으로 분석 기능을 제공한다.

 

첫 페이지 로딩에 걸리는 시간 등을 측정해준다. 이를 이용해 코드를 수정하여 UX를 향상시킬 수 있을 것이라 생각한다.

 

5. 아쉬운점

이 프로젝트를 진행하는 과정에서 아쉬웠던 점들이 있다.

 

사전에 체계적인 기획 과정이 없어 중간에 기능들이 추가되었다.

 

이 때문에, URI가 수정되는 경우도 있고 라우팅이 수정되는 경우도 있었다.

 

불필요한 배포, hotfix 등이 발생했고 이 때문에 프로젝트 기간이 지연되었다고 생각한다.

 

또한, Svelte Kit에 대한 레퍼런스가 많이 없을 것으로 우려되어 NextJS를 선택했지만 13버전이 출시된지 얼마 되지 않아 레퍼런스가 없는 것은 마찬가지였다.

 

6. 마무리

이 프로젝트에는 앞으로 로그인 기능이 필수적으로 추가될 예정이다.

 

또 다른 변경점은 동아리 인원들에게 베타 테스트를 거쳐 의견을 받은 뒤 추가 및 변경할 예정이다.

 

이 과정에서 프로젝트에서 미흡했던 부분이나 앞으로 발전해 나갈 방향을 알 수 있을 것이라 생각한다.

 

이 프로젝트를 통해 "남들이 사용하는 서비스"를 만들게 되었다.

 

기획, 배포, 운영, 업데이트 까지 경험해 볼 예정이다.