신규 서비스 ‘꿀템’을 만들기 위한 여정(네? 다음 달까지요?) - 2편

외부망의 기존 BSD 프론트엔드 환경 위에 꿀템(attraction) 탭을 플러그인 형태로 얹고, 메인 데이터는 Oracle DB의 집계 애플리케이션이 조회해 전달하는 구조로 만들었다. 프론트는 TypeScript, React 18.2, TanStack Query, TanStack Virtual, Fastify, Vite를 사용했고, 꿀템용 Fastify 코드는 별도 프론트 저장소에서 개발한 뒤 npm 패키지 형태의 Fastify plugin으로 이벤트 프론트에 가져다 쓰는 방식으로 분리했다.

관리 화면과 백엔드는 Spring + Kotlin을 새로 적용했다. 오라클 환경이라 Stored Procedure 대신 JPA와 QueryDSL을 선택했고, Admin 서비스는 스프링 멀티모듈로 구성해 웹 UI와 Oracle 접근 API가 같은 도메인 모델을 공유하게 했다. Admin UI는 HTMX + Thymeleaf로 구현해 빠르게 기능을 쌓는 쪽에 초점을 맞췄다.

HTMX는 별도 JS 보일러플레이트를 크게 줄여 서버 통신을 단순하게 만들고, Thymeleaf와 결합하면 레이아웃 재사용도 쉬웠다. 다만 JSON API에 익숙한 상태에서 HTML 응답과 폼 바인딩 방식에 적응하는 데 시간이 걸렸고, @RequestBody 대신 @RequestPart, @ModelAttribute를 다루는 과정과 data class 바인딩 문제로 꽤 헤맸다. 결국 필요한 기능은 여전히 JS가 필요했고, TypeScript를 쓸 수 없다는 점과 데이터 패킷이 커질 수 있다는 점도 한계로 짚었다.

개발 과정은 2주간 매일 스크럼으로 진행했다. 1~10분 정도 짧게 진행하며 현재 작업과 진척을 맞췄고, 불필요한 논의를 줄이면서 불확실성을 조율했다. 론칭 전에는 팀 내 자체 QA를 먼저 돌려 사소한 버그, 불편한 동선, 추가 기획 아이디어까지 폭넓게 수집했고, 개발자들이 직접 개선안을 제시해 서비스 완성도를 높였다.

실무 이슈도 적지 않았다.

• Oracle RAC 환경에서는 Sequence가 캐시 단위로 할당돼 PK가 순차적으로 증가하지 않을 수 있음을 확인했다.
• 순차성이 꼭 필요하지 않다면 NO ORDER + 큰 CACHE를 권장했고, 주문·결제처럼 순서가 중요할 때만 ORDER를 고려해야 한다고 정리했다.
• QueryDSL에서는 from/join 절의 서브쿼리 제약 때문에 원하는 쿼리를 바로 만들기 어려웠고, 서브쿼리를 View처럼 Entity화하는 방식으로 해결했다.
• 인덱스가 없어 Full Scan이 발생한 사례도 있었고, 이를 통해 사내 JPA/QueryDSL 적용 가이드의 중요성을 체감했다.

이 프로젝트는 사내 도구를 적극 활용해 빠르게 밀어붙인 사례이기도 했다. Git/GitHub, Jira, Saturn Initializr, Fusion, VM 툴, Kibana, nGrinder, Datadog를 이용해 개발·배포·로그 확인·부하 테스트·장애 추적까지 이어갔다. 특히 nGrinder로 10만 건, 100만 건 단위 스트레스 테스트를 수행했고, Datadog으로 트래픽과 에러를 타임라인별로 추적하며 운영 관점까지 준비했다.

결국 꿀템은 빅스마일데이 기간 동안 장애 없이 런칭됐고, 개발 조직에서 시작한 아이디어가 실제 서비스로 빠르게 이어진 사례가 됐다. 댓글, 신고하기 등 추가 기능을 붙여 한가위 빅세일에 다시 선보일 예정이며, 유관부서의 협업이 서비스 오픈의 핵심 조건이었다는 점을 강조한다.