[꿀떡볶이 프로젝트] 사이드 웹프로젝트 기술 스택 선정

실무의 갈증을 떡볶이로 풀다

 

현재 실무에서 Java 8, Spring Boot 2.x, MyBatis, Oracle 12c 기반의 웹 프로젝트를 담당하고 있다.

 

하루가 갈수록 점점 복잡한 로직(매장별 선착순 쿠폰 사용 등)을 작성하게 되면서 벽을 느끼는 일이 점점 많아졌다.

DB를 매 단계마다 조회하는 방식 대신
Redis로 연산 처리를 대신하고 Kafka로 비동기 발급을 했다면
훨씬 안정적이고 빨랐을 텐데

 

인프라의 제약 때문에 시도하지 못했던 최신 기술들에 대한 갈증이 커졌고,

이를 직접 구현해보기 위해 개인 프로젝트를 결심했다.

 

왜 하필 '꿀떡볶이'인가?

• 선착순에 최적화된 도메인

배민이나 요기요 같은 거대 플랫폼을 모방하여 다양한 기능을 시도해볼까 생각을 했었다.
하지만 아직 주니어 개발자의 1인 프로젝트에서는 배보다 배꼽이 더 커질 것 같았다.

지금은 선택과 집중이 중요하다고 생각한다.

특히 집중하고 싶은 '트래픽 병목 해결'과 '선착순 로직'을 가장 잘 보여줄 수 있는 가벼운 서비스가 필요했다.

• 사심 가득한 선정

무엇보다 프로젝트를 해야겠다고 결심했을 때, 떡볶이가 너무 먹고 싶었다.

내가 좋아하는 음식을 주제로 사이드 프로젝트를 진행하면 퇴근해서도 30분이라도 코드를 작성하고, 설계하려고 할 것 같다.
그리고 고민하는 시간 조차 즐거울 것 같다.

사람들이 내가 좋아하는 떡볶이를 어떻게 하면 더 빨리, 더 편하게, 더 간단하게 주문하게 할 수 있을까?
좋아하는 떡볶이를 빨리, 더 저렴하게 먹고 싶어서 이 서비스를 한 번 더 사용할만큼 편리하게 만들 수 있을까?
어떻게 하면 사용자가 서비스를 이용할 때 발생하는 데이터의 정확성을 높일 수 있을까?

아무리 많고 복잡한 기능이 들어있는 서비스라도 원초적으로 가장 중요한 기능은 바로 "주문"이다.
이 한 번 또는 여러 횟수의 주문을 유도하기 위해서 나는 과연 지금의 실력과 경험으로 어디까지 생각해낼 수 있을까?

이런 복잡한 고민을 수도 없이 해야 할텐데 내가 평소에 좋아하는 음식 중 하나로 주제로 사이드 프로젝트를 진행하면
너무너무 재밌을 것 같았다.

 

"꿀떡볶이" 주문 서비스 기술 스택과 선정 이유

기술 스택(Backend)	선정 이유
Java 21, SpringBoot 4.0.3	실무에서 사용하고 있는 오래된 버전에서 벗어나 최신 버전을 도입하고 싶었다. Java 8에서 JSON을 자바 코드 내 넣어야 할 경우, \n과 + 연산자로 도배를 해야 했지만, 21을 이용하면 """로 줄바꿈이 그대로 유지된다. Java 8에서 DTO 하나 만들려면 Getter, Setter, toString 등의 여러 코드를 작성해야 하고 Lombok을 써도 클래스가 무거워 보인다. 하지만 21 버전은 record 클래스를 이용하면 간단하게 작성할 수 있다. 기존 Java 8, 17 방식처럼 무거운 플랫폼 스레드를 수천 개씩 만드는 대신, 가상 스레드를 통해 아주 적은 리소스로도 수만 개의 동시 요청을 처리할 수 있는 성능적 우위를 확보할 수도 있다. SpringBoot 4버전은 2버전에 비해 최신 보안 표준과 향상된 성능의 라이브러리를 제공한다고 한다. 3버전까지는 주소창에 /v1/, /v2/를 직접 관리해야 했지만, 4버전에서는 어노테이션 기반의 더 깔끔한 API 버전 관리 기능을 제공하여 유지보수성이 높아졌다. 정확한 차이점은 개인 프로젝트를 진행하면서 알아봐야 할 것 같다.
Gradle	gradle은 바뀐 부분만 계산해서 빌드하기 때문에 maven보다 속도가 빠르다고 한다. 로컬 환경에서 빠르게 코드를 수정하고 결과를 확인하기 위해 gradle을 선택했다.
JPA, Querydsl	XML 기반의 MyBatis 대신 객체 중심 JPA를 사용하여 비즈니스 로직에만 집중하려고 선택했다.  JPA만으로 구현하기 까다로운 복잡한 쿼리나 동적 검색은 Querydsl을 도입하여 해결하고자 한다.

기술 스택(View)	선정 이유
Thymeleaf	JSP처럼 서버가 있어야하면 화면을 확인할 수 있는 방식보다는, 디자인 결과물을 브라우저에서 즉시 확인할 수 있어 선택했다. 퍼블리셔의 작업물(물론 꿀떡볶이는 개인 프로젝트라 퍼블리셔가 없지만)을 최소한의 수정으로만 적용할 수 있다는 장점이 있으며, UI 작업의 독립성을 확보하고자 선택하였다.
Next.js	JSP는 매번 서버에서 화면을 다 그려 통째로 보내지만, Next.js는 미리 그려두거나(정적 사이트 생성 SSG) 바뀐 부분만 가져와서 렌더링 속도(서버 사이드 렌더링 SSR)가 훨씬 빠르다.  주문 서비스는 반응 속도가 생명이라고 생각한다. 느려터지면 어플 사용하는 사람들은 답답해서 잘 사용 안할듯 .. 그리고 검색 엔진 최적화(SEO) 기능도 있다고 한다.
Bootstrap 5	백엔드 비즈니스 로직에 집중하면서도 완성도 높은 UI를 구축하기 위해 선택했다. 별도의 CSS 작업 없이도 모든 디바이스에서 최적화 된 반응형 웹을 보여주기 위해 사용할 예정이다.

기술 스택(DB)	선정 이유
MySQL 8.0	무거운 Oracle 대신 로컬 컨테이너로 가볍게 띄울 수 있는 MySQL을 선택했다. 이는 도커를 이용해서 띄울 생각이다.
Redis	선착순 이벤트 시 발생하는 DB 병목을 Redis로 차단하고자 한다. RDBMS의 부하를 줄이기 위한 캐싱 전략을 이용해보고자 한다.

인프라	선정 이유
Kafka	주문 처리의 안정성을 위해 Kafka로 비동기 이벤트를 관리하고자 선택했다.
docker	docker가 없다면 오라클이나 MySQL 등 각종 툴을 내 컴퓨터에 직접 설치해야 한다. 그러다보면 설정이 꼬여서 포트가 충돌하거나, 지워도 찌꺼기가 남아 결국 컴퓨터를 포맷해야 하는 상황이 오기도 한다. 실제로 입사 초 2주간 MySQL 설치하다가 설정이 꼬여서 포맷을 한 기억이 있다. 이를 위해 docker를 강력하게 사용해야 한다고 생각했고, 이를 실천에 옮기려고 한다.

형상관리	선정 이유
Git	SVN은 커밋한 프로젝트를 가져와 다같이 작업하고, 커밋한다. 그러다보면 내 코드가 완성되지 않았는데 다른 사람 코드가 깨질까 봐 눈치 게임을 하게 되는 상황이 발생한다. 또한 서버가 죽으면 아무것도 못한다는 것도 단점이다. 그러나 Git은 로컬 저장소가 있어 오프라인에서도 작업이 가능하다. 무엇보다 브랜치 생성이 매우 가벼운 것도 장점이다. Feature 브랜치를 따서 내 기능을 구현하고, 완성이 검증되었을 때만 합치는 Git-flow 전략을 통해 안전한 개발이 가능하다. 커밋을 잘게 나누어 기록할 수 있고, 문제가 생겼을 때 이전 상태로 되돌리는 롤백 과정이 훨씬 빠르고 정교하다.

 

그 외에 것들은 실제 프로젝트를 진행하면서 추가되거나 변경될 수 있을 것 같다.

 

꿀떡볶이, 시작하다

 

2026년 3월 16일 월요일 20:00.