⟨혹성의 아이⟩ 2.0 프로젝트 - Next.js를 선택하게 된 이유

2024년 10월 27일 오전 2시 51분 KST

올해 5월경에 친구의 졸업작품인 단편영화 ⟨혹성의 아이⟩의 홈페이지를 만들어 준 경험이 있었습니다. 그때 당시에는 웹 개발이 처음이었어서 최대한 쉬운 방법으로, 그리고 초보적인 방법으로 개발했기 때문에 지금 와서 돌이켜 보면 많이 부족한 부분이 많았습니다만, 그래도 주변 사람들과 영화에 뜻을 같이 하고자 하는 사람들의 반응들이 좋았어서 저의 웹 개발 커리어에 큰 자신감을 준 프로젝트였습니다.

당시의 기술 스택을 말씀드리자면, 프론트엔드는 HTML과 CSS, 바닐라 JavaScript로 개발했고, 백엔드는 Flask와 Gunicorn, Nginx를 사용했었습니다. 호스팅은 저희 집의 시놀로지 NAS로 했다가 배포 환경이 불안정해서 나중에는 Microsoft Azure로 옮겼습니다.

⟨혹성의 아이⟩의 촬영이 끝나고 영화의 공개와 관련 상품들의 출시를 앞두게 되면서 홈페이지의 콘텐츠를 업데이트해야 했는데요, 저는 이 홈페이지를 조금 더 현대적인 방법으로 마이그레이션하고 싶다는 생각을 하게 되었습니다.

Flask를 선택하게 된 이유

처음 Flask로 홈페이지를 개발했던 이유는 그저 단순합니다. 저에게 있어서 진입 장벽이 낮았기 때문입니다. 일례로, Flask 앱에서 "루트 경로로 접속했을 때 'Hello, world!'라는 문자열을 출력"하는 코드는 다음과 같습니다.

from flask import Flask

app = Flask(__name__)

@app.route('/')
def home():
  return 'Hello, world!'

if __name__ == '__main__':
  app.run(debug=True)

또한, HTML 파일에 Jinja2 문법을 사용하고 Flask에서 불러오면 웹 페이지의 내용을 동적으로 변경할 수도 있습니다.

<!-- 중략... -->
<body>
  <h1>{{ user }}님, 환영합니다!</h1>
  <p>{{ content }}</p>
</body>
<!-- 이하 생략... -->

이처럼 동적인 웹을 간단히 개발하기에 Flask는 매우 편리한 프레임워크입니다.

Flask의 한계점

1. 프론트엔드 개발의 한계

Flask는 웹 페이지의 렌더링을 위한 템플릿 엔진을 제공하지만, 이를 활용해서 본격적으로 프론트엔드를 개발하기에는 한계점을 많이 느꼈습니다. 일례로 웹 페이지에 메인 이미지 캐러셀을 개발할 때 Embla Carousel을 사용했었는데, Node.js 환경이라면 간단히 npm 패키지를 설치하여 사용할 수 있었지만, Flask 에서는 이를 사용하기 위해서는 직접 CDN을 불러와야 했습니다.

2. SPA 개발의 한계

SPA(Single Page Application)로 개발하기에도 적절하지 않다는 생각이 들었습니다. 페이지를 이동할 때마다 헤더와 푸터를 다시 렌더링하는 것은 트래픽 측면에서도 꽤나 비효율적이고, 사용자에게 있어서도 좋은 경험은 아니라고 생각했습니다.

3. 처음부터 설계해야 하는 프로젝트 구조

또한, 프로젝트 구조가 정해져 있지 않아 개발자가 직접 프로젝트 구조를 설계해야 하는 부분도 저에게는 피로감을 줬습니다. 제가 처음으로 Flask 기반으로 웹 개발을 시작했을 때는 단순히 app.py 파일 하나에 모든 코드를 작성했었는데, 프로젝트 규모가 점점 커지면서 코드의 가독성이나 유지보수성이 떨어지는 것을 느꼈습니다. 물론 모듈화를 통해 문제를 해결할 수 있지만, 이미 가독성이 떨어져 버린 코드를 모듈화하려고 하니 엄두가 나지 않더라고요.

4. 언어의 일관성

언어의 일관성도 제가 느꼈던 문제 중 하나였습니다. Python과 JavaScript를 하나의 프로젝트에서 함께 사용하는 것은 일관된 개발 경험이 아니라는 생각이 들었습니다.

5. 코드 포매팅이 어려움

사소한 문제이지만, HTML 문서에 Jinja2 문법을 사용하면 코드 포매팅이 어려워진다는 점도 한몫했습니다. 제가 사용하는 포매터인 Prettier는 Jinja2 문법을 인식하지 않아 코드를 저장할 때마다 포매터에서 오류를 출력하는데, 저에게 있어서 좋은 개발 경험은 아니었습니다.

6. Tailwind CSS 사용의 어려움

방명록 관리자 페이지를 만들 때 Tailwind CSS를 잠깐 사용했었는데, Flask에서 Tailwind CSS를 사용하기 위해서는 Flask 환경과는 별개로 따로 Node.js 환경을 구축해야 했습니다. 어차피 Node.js를 사용하게 될 거라면, 그냥 Node.js 환경에서 프론트엔드를 개발하는 게 더 편하지 않을까 하는 생각이 들었습니다.

Next.js로의 이주를 결심

위와 같은 이유로, 저는 Flask로 작성된 홈페이지를 다른 프레임워크로 이주하기로 결심했습니다. 더 현대적인 프레임워크는 무엇이 있을까 고민한 끝에 Next.js를 선택하게 되었습니다.

1. 서버리스 아키텍처로 배포 용이

제가 Next.js를 선택하게 된 가장 큰 이유입니다. Vercel, Netlify, Cloudflare Pages 등의 서버리스 플랫폼을 이용해서 간편하게 배포할 수 있고, 서버의 유지보수에 대한 걱정을 덜 수 있다는 점이 저에게 가장 매력적으로 다가왔습니다.

2. React 기반

Next.js는 React 기반의 프레임워크이기 때문에 SPA를 쉽게 개발할 수 있고, React의 풍부한 생태계를 활용할 수 있다는 점도 큰 장점이라고 생각했습니다. 특히나, 현대적인 웹 개발에 있어서 React는 필수적인 기술이라는 생각이 들었기 때문에 React를 한번 배워보고 싶기도 했습니다.

3. 파일 시스템 기반 라우팅

Flask에서는 라우팅 경로에 따라 어떤 HTML 템플릿을 렌더링할지에 대한 코드를 직접 작성해야 했지만, Next.js에서는 파일 경로에 따라 라우팅을 자동으로 처리해주기 때문에 프로젝트가 가진 라우팅 구조를 한 눈에 파악하기 쉽다는 점도 장점이었습니다.

4. 서버 사이드 렌더링과 검색 엔진 최적화

Next.js는 서버 사이드 렌더링(SSR)을 지원하기 때문에 클라이언트 사이드 렌더링(CSR) 기반의 React 앱보다 향상된 초기 로드 성능을 제공할 수 있습니다. 또한, 완성된 HTML을 크롤러에게 제공하기 때문에 검색 엔진 최적화(SEO)에도 유리합니다.

5. 통합된 개발 환경

Next.js는 프론트엔드와 백엔드를 함께 개발할 수 있는 통합된 개발 환경을 제공하기 때문에 개발자가 프로젝트 구조를 설계하는 데 있어서 편리하다는 점도 장점이었습니다. 특히, JavaScript로 프론트엔드와 백엔드를 모두 개발할 수 있다는 점은 더 나은 개발 경험이 될 수 있을 것이라고 생각했습니다.

결론

위와 같은 고민을 거쳐, 저는 ⟨혹성의 아이⟩ 홈페이지를 Flask에서 Next.js로 마이그레이션하게 되었습니다. 기존의 프로젝트를 부수고 새로 시작한다는 것이 조금은 아쉽기도 했지만, 결론적으로는 더 현대적인 기술 스택을 공부하게 되어서 좋은 경험이 되었던 것 같습니다. 다음 포스트에서는 왜 Cloudflare Pages를 선택했는지에 대해 이야기를 해보겠습니다.