축덕 퀴즈 개발기 - V1 확장을 결심한 이유

기존에 만들었던 “축덕 퀴즈”는 단순히 축구 선수 이름을 맞히는 작은 프로젝트로 시작했다.
처음에는 가볍게 만들어본 프로젝트였지만, 주변 반응이 생각보다 정말 좋았다.

“생각보다 재밌다.”
“은근 중독성 있다.”
“다음 문제 또 하고 싶어진다.”

“심심할 때 하기 좋다.”

이런 반응들을 들으면서 단순한 미니 프로젝트로 끝내기보다, 제대로 확장해서 서비스 형태로 만들어보고 싶다는 생각이 들었다.

특히 단순 퀴즈를 넘어서:

• 글로벌 랭킹
• 무한 퀴즈 모드
• 기록 저장
• 다국어 대응
• 보안 및 인증
• 실시간 경쟁 요소

같은 기능들을 붙이면 훨씬 재미있는 서비스가 될 수 있다고 느꼈다.

그래서 이번에는 단순 HTML/JS 수준이 아니라, 실제 서비스 구조처럼 프론트엔드와 백엔드를 분리해서 제대로 개발하기로 했다.

 

기술 스택 선정 이유

이번 확장 버전에서 사용한 기술 스택은 다음과 같다.

• React.js
• NestJS
• Prisma
• PostgreSQL
• Redis
• TailwindCSS
• TypeScript

단순히 “많이 써서” 선택한 것이 아니라, 각각 명확한 이유가 있었다.

React.js를 선택한 이유

프론트엔드는 React.js를 사용했다.

가장 큰 이유는 이후 React Native까지 확장하기 위해서다.

웹 개발 경험을 React 기반으로 쌓아두면 이후 모바일 앱 개발로 넘어갈 때도 흐름이 이어진다.
컴포넌트 방식이나 상태 관리 개념도 비슷하기 때문에 장기적으로 도움이 된다고 생각했다.

그리고 React는:

• 컴포넌트 재사용이 쉽고
• 상태 관리 구조가 명확하며
• 유지보수가 편하고
• 생태계가 크다

는 장점이 있어서 프로젝트 규모가 커질수록 훨씬 유리하다.

특히 퀴즈 UI처럼 반복되는 화면이 많은 프로젝트에서는 컴포넌트 구조가 정말 강력하다고 느꼈다.

 

NestJS를 선택한 이유

백엔드는 NestJS를 사용했다.

원래 JavaScript/TypeScript 기반 백엔드에 관심이 많았고,
백엔드 개발자로 성장하려면 NestJS는 꼭 경험해봐야 한다고 생각했다.

무엇보다 NestJS는:

• 의존성 주입(DI)
• MVC 패턴
• 모듈 구조
• 계층 분리

같은 구조를 굉장히 체계적으로 잡을 수 있다.

Express만 사용할 때보다 프로젝트 구조를 훨씬 명확하게 관리할 수 있었고,
서비스 규모가 커질수록 왜 NestJS를 많이 사용하는지 이해가 되었다.

특히:

• Controller
• Service
• Module

구조로 나누다 보니 유지보수가 훨씬 편했다.

 

Prisma + PostgreSQL을 사용한 이유

데이터베이스는 PostgreSQL을 사용했고, ORM으로 Prisma를 선택했다.

PostgreSQL은 안정성과 성능이 좋고, 실제 서비스에서도 많이 사용되는 데이터베이스라서 선택했다.

그리고 Prisma를 사용한 이유는 ORM의 장점 때문이었다.

특히 Prisma는:

• 타입 지원이 강력하고
• 쿼리 작성이 직관적이며
• 생산성이 높고
• TypeScript와 궁합이 좋다

는 점이 마음에 들었다.

무엇보다 직접 문자열로 SQL을 조합하는 방식보다 훨씬 안전하게 개발할 수 있었다.

예를 들어 SQL Injection 같은 문제를 줄이는 데도 도움이 되기 때문에 백엔드 개발에서 굉장히 유용하다고 느꼈다.

 

TypeScript를 사용한 이유

JavaScript는 자유롭고 유연하다는 장점이 있다.

하지만 프로젝트 규모가 커질수록:

• 타입 실수
• 예상치 못한 undefined
• 잘못된 데이터 구조

같은 문제가 자주 발생한다.

그래서 이번 프로젝트는 TypeScript 기반으로 개발했다.

TypeScript를 사용하면:

• 타입 오류를 미리 발견할 수 있고
• IDE 자동완성이 강력해지고
• 유지보수가 쉬워지고
• 협업에도 유리하다

는 장점이 있다.

처음에는 타입 때문에 조금 답답하게 느껴질 때도 있었지만,
프로젝트가 커질수록 “왜 다들 TS를 쓰는지” 체감하게 되었다.

 

TailwindCSS를 사용한 이유

UI 스타일링은 TailwindCSS를 사용했다.

기존 CSS 방식은 프로젝트가 커질수록 클래스 관리가 복잡해지는 경우가 많았다.

반면 TailwindCSS는:

• 빠른 스타일링
• 반응형 대응
• 일관된 디자인
• 생산성 향상

측면에서 굉장히 편했다.

특히 직접 CSS 파일을 계속 왔다 갔다 하지 않아도 되다 보니 개발 속도가 정말 빨라졌다.

퀴즈 UI처럼 반복적인 화면 구성에서는 Tailwind의 효율이 상당히 좋다고 느꼈다.

 

Redis를 사용한 이유

Redis는 랭킹 시스템 때문에 사용했다.

축덕 퀴즈는 단순 점수 저장만 있는 게 아니라:

• 실시간 랭킹
• 최고 점수
• 빠른 조회
• 사용자 기록 관리

같은 기능이 중요했다.

이런 부분에서 Redis의 빠른 읽기/쓰기 성능이 굉장히 강력했다.

특히 메모리 기반이라 속도가 빠르고, 랭킹 시스템 같은 기능에 잘 어울린다고 느꼈다.

나중에는:

• 캐싱
• 세션 관리
• 실시간 기능

등으로도 확장 가능성이 있다고 생각하고 있다.

 

마무리

이번 축덕 퀴즈 확장은 단순히 기능 추가가 목적이 아니었다.

“실제 서비스처럼 구조를 설계해보는 경험”

그 자체가 가장 큰 목표였다.

프론트엔드와 백엔드를 분리하고,
데이터베이스와 캐시를 연결하고,
보안과 구조를 고민하면서 개발하다 보니 이전보다 훨씬 많은 것을 배우게 되었다.

아직 완벽한 프로젝트는 아니지만,
직접 부딪히면서 하나씩 개선해나가는 과정 자체가 굉장히 재미있었다.