프로젝트를 4번 빌드했어요, 그게 제가 배운 점

Source: Dev.to

요구 사항

• 협회가 무엇을 하는지 간단히 설명할 수 있는 랜딩 페이지
• 사람들을 등록하고 행사에 참석한 것을 기록할 수 있는 웹 앱

초기 스택 (2022)

• React 18
• PHP 8.1
• MySQL

잘 동작했고 반응도 빠른 편이었다. 코드베이스는 단순하고 순진했다.

더 강력한 스택으로 전환

Next.js

원시 SSR 파워와 프론트엔드 레이어에서의 서버‑사이드 로직, 그리고 SEO 최적화가 필요했다.

Go

향후 모바일 앱과 수천 명의 사용자를 위한 API 확장성이 필요했다.

PostgreSQL

MySQL보다 필요하다고 판단해 관리형 PostgreSQL 서비스를 비용을 내고 사용하기 시작했다.

첫 번째 버전은 한 달 만에 출시되었다.

비용

첫 번째 문제는 비용이었다. render.com을 사용하면 각 서비스당 $7 / 월이 든다. 프론트엔드, 백엔드, 데이터베이스를 합치면 총 $21 / 월 정도가 되는데, 이는 작은 협회에겐 부담스러운 금액이었다.

확장성

큰 실수는 확장성을 복잡성과 혼동한 것이었다.
시스템은 추상화와 레이어가 많아 조직화는 되었지만 변경이 느렸다. 이런 구조는 많은 개발자가 있는 대기업에 적합하지만, 작은 프로젝트에서는 기능을 조금만 수정해도 큰 부담이 된다.

버전 3

더 저렴한 방안을 찾아야 한다는 것을 깨닫고, SEO 이점을 유지하면서 스택을 바꾸었다.

• Next.js – SEO용
• Directus – 백오피스
• PostgreSQL

Next.js가 Directus API와 직접 연결돼 로컬에서 매우 쾌적했다. 배포는 비용이 저렴하고 자동 머신 스케일링을 제공하는 fly.io를 사용했다.

단점: Directus가 시작하는 데 5–10 초, 프론트엔드가 또 2–3 초가 걸려 랜딩 페이지 로드에 총 7–13 초가 소요된다.
장점: 월 사용료가 없다.

버전 4

많은 Directus‑편집 가능한 섹션이 실제로는 불필요하다는 것을 나중에 알게 되었다. 리팩터링을 통해 편집 가능한 부분을 세 섹션으로 줄였다.

• Next.js (완전 정적 사이트)
• PostgreSQL + Prisma (ORM)
• NextAuth (빠른 로그인 시스템)
• 세 섹션을 위한 간단한 대시보드

결과: 거의 4년간의 작업 끝에 일주일 만에 완성된 웹사이트.

배운 점

• 복잡한 솔루션은 대화 소재는 좋지만, 반드시 프로덕션 코드에 적합한 것은 아니다.
• 비용과 인프라 결정은 UML 다이어그램을 그리기 전에 해야 한다.
• 이 프로젝트를 통해 제품을 전체 시스템의 일부분으로 바라보게 되었고, 이는 협회의 요구와 맞물렸다.
• 확장성은 상대적이며 실제 요구 사항에 따라 달라진다.
• “제품의 미래를 생각하는 시간을 적게 할수록 좋다.” 간단하게 만들고 성장 여지를 남겨두라—적을수록 좋다.