서버가 필요 없는데 서버를 만들었다

이 블로그의 백엔드는 원래 Spring Boot + PostgreSQL이었다.

처음 구조는 이랬다. EC2 인스턴스 하나 올리고, Spring Boot WAR 패키징해서 배포, Nginx가 리버스 프록시로 80/443 받아서 8080으로 넘기는 구조. DB는 RDS PostgreSQL. 포트폴리오 사이트(sevin.dev)와도 연계해서, 블로그 API를 포트폴리오에서도 호출하는 방식으로 설계했다.

나름 그럴싸했다.

기능이 계속 붙었다

처음엔 포스트 CRUD만 만들었는데, 만들다 보니 자꾸 기능이 생겼다.

velog나 tistory 같은 데서 쓰는 draft 기능이 있어야 할 것 같았다. 그래서 status 필드 추가, DRAFT / PUBLISHED / DELETED enum 관리, publish 엔드포인트 따로 만들고. 그러다 보니 어드민 API가 필요했다. 일반 유저랑 어드민을 구분해야 하니 JWT 인증도 붙었다. 어드민만 쓸 수 있는 포스트 관리 API, 댓글 관리 API.

그러다 문득 "블로그에 애널리틱스도 있어야 하지 않나?" 싶어서 조회수 집계 API도 만들기 시작했다. 포스트 조회할 때마다 카운트 올리고, 일별 통계 내리고, 인기 포스트 추천하고.

코드가 쌓였다. 나름 구조도 잘 잡혔다. 근데 만들면서 계속 드는 생각이 있었다 — 아무도 블로그를 이렇게 만들지 않는데, 나만 이러고 있는 건가?

Harvey의 블로그를 봤다

어느 날 동료 Harvey가 블로그 리뉴얼했다고 링크를 공유해줬다. 들어가보니 디자인도 깔끔하고, 글도 잘 써져 있고, 댓글도 달 수 있었다.

"어, 이거 어떻게 만들었어요?" 하고 물어봤더니 — Next.js에 Vercel 배포, 글은 MD 파일로 관리, 댓글은 Giscus로 붙였다고 했다.

순간 멈칫했다. 아. 정적 웹으로 만드는 거구나. 써드파티 댓글을 붙이는 거구나.

난 왜 다 서버를 통해서만 하려고 했을까? MD 파일 몇 개 렌더링하는 데 EC2, RDS, Nginx, Spring이 왜 필요한가. draft 기능은 파일에 draft: true 한 줄이면 되는 거였다. 댓글은 오픈소스 써드파티가 이미 잘 만들어져 있었다. 애널리틱스는 Vercel Analytics가 공짜로 해줬다.

나는 있지도 않은 요구사항을 혼자 만들어내고, 그걸 스스로 구현하고 있었다.

결국 다 갈아엎었다

Next.js + Vercel + Git으로 전부 다시 만들었다. EC2 없애고, RDS 없애고, Nginx 없애고, Spring 없애고. 배포는 git push 하나로 끝났다.

그때 생각했다 — "서버가 필요 없는데 서버를 만들지 말자."

그래서 Spring이 나쁜 건 아니다

이 경험이 Spring이 별로라는 얘기는 아니다. 문제는 Spring이 아니라 내가 블로그에 Spring을 쓴 것이었다.

Spring은 이런 상황에서 진가가 나온다:

• 팀이 크고, 오래 유지보수해야 하는 서비스
• 트랜잭션, 배치, 보안 같은 엔터프라이즈 기능이 필요할 때
• 코드가 많이 쌓이고, 타입 안전성이 중요할 때

DI와 AOP는 코드베이스가 커질수록 빛난다. 근데 블로그는 그런 환경이 아니었다.

반대로 Node.js가 맞는 건 이런 상황이다:

• 빠르게 뭔가 만들어서 검증해야 할 때
• WebSocket 같은 실시간 기능이 핵심일 때
• 프론트엔드와 언어를 맞추고 싶을 때

Next.js로 블로그를 만들면서 JS 하나로 프론트-백을 다 처리하는 게 이 규모에선 훨씬 자연스럽다는 걸 직접 느꼈다.

결국 이 질문이다

"Spring이 낫냐, Node가 낫냐"가 아니라 "지금 이 상황에 뭐가 맞냐"가 맞는 질문이다.

과하게 만들어봐야 뭐가 진짜 필요한지 안다. 그걸 블로그 하나 만들면서 배웠다.