개발자가 4년간 4번의 리팩토링을 통해 과도한 기술 스택 선택이 프로젝트에 부담이 된다는 교훈을 얻다

Context

2022년 Classicum Association을 위해 랜딩 페이지와 이벤트 등록 웹 앱을 구축하기 시작했다. 단순한 스택으로 시작했으나通知, 동시 이벤트, 계정, 댓글 기능 등을 추가하겠다는 목표를 세웠다. 이는 실제로 필요하지 않은 과도한 목표였다.

Technical Solution

• NextJS → SSR 성능과 SEO 최적화를 위해 도입
• Go → 향후 모바일 앱과 대량 사용자 확장 고려해 API 확장성 확보 목적
• PostgreSQL → 실제 유료 서비스를月开始 사용
• Directus → 백오피스 기능 처리를 위해 도입했으나 5~10초의 냉장 시작 시간 문제 발생
• Prisma → ORM으로 데이터베이스 관리 간소화
• NextAuth → 단순 로그인 시스템 구축

Impact

월 비용이 $21에서 $0으로 감소했다. 초기 버전의 전체 페이지 로드 시간이 7~13초에서 최종 버전의 정적 생성 방식으로 크게 개선되었다.

Key Takeaway

복잡한 솔루션은 기술적 우월감을 주지만 실제 프로젝트에서는 부담이 된다. 비용과 인프라를 UML 다이어그램 작성 전부터 고려해야 하며, 확장성은 절대적 개념이 아니라 실제 필요에 따라 달라지는 상대적 개념이다.