안녕하세요. Web Frontend팀 이민하입니다. 지난 편에서 꿀템 서비스를 기획하고 필요한 개념들의 이름을 지어주며 이를 바탕으로 데이터베이스를 설계해 보았습니다. 이번 편에서는 어떤 기술 스택을 선택했는지 소개하도록 하겠습니다. 기술 스택 선택과 개발 External 망에는 기존에 BSD 프론트엔드 영역 어플리케이션들이 있습니다. node.js와 경량 웹프레임워크인 fastify로 되어있습니다. 프론트에서 api를 호출하면 attraction 집계 어플리케이션이 메인 데이터 저장소인 Oracle DB에서 데이터를 조회해 옵니다. 구매내역, 링크루 등 외부 api를 호출한 결과도 전달해 줍니다. 저장된 데이터는 Admin화면을 통해 관리할 수 있습니다. 누가 어떤 피드를 작성했고 누가 좋아요 버튼을 눌렀는지, 구매는 얼마나 일어났는지 등을 확인할 수 있습니다. 프론트엔드는 별도의 서버를 구축하지 않고 플러그인 형태로 개발되었습니다.event  관련 어플리케이션은 프론트엔드 이름이 붙어있지만 여러 프로모션 영역의 비즈니스 로직이 많이 들어있는 어플리케이션입니다. 이번 BSD는 랭킹 탭 옆에 신규 탭으로 꿀템 탭이 신설될 것이므로 event 어플리케이션 안에 신규 생성한 attraction 어플리케이션을 번들 형태로 import 했습니다. Typescript, React 18.2Tanstack query (aka. react-query) api fetching 기능을, 꿀템의 등록/편집/좋아요 처리에 개별적으로 상태를 관리하지 않아도 되서 개발에 유리하였고요Tanstack virtual을 이용해 무한스크롤 기능을 구현하였습니다.event-fe와 마찬가지로 Fastify 프레임워크를 사용하였습니다.Vite로 번들링 하여 사내 배포시스템을 통해 배포하였습니다.또 아래의 특징을 갖고 있습니다.attraction 집계 api 호출 및 사용자 입력값 검증 (xss 방어)이벤트 프론트 저장소가 분리되어 있고 꿀템 저장소(attraction 프론트엔드)도 별도라서 꿀템 쪽 fastify용 코드는 attraction 프론트에서 개발하고 결과물을 fastify plugin 형태의 npm 패키지로 생성해서 이벤트 프론트 쪽에서 가져다 쓰는 방식으로 구현개발 중에는 attraction 프론트엔드에서 이벤트 프론트의 구성과 유사하게 dev server를 띄워서 개발하였습니다. 백엔드의 기술스택은 다음과 같습니다. 이벤트 영역에서는 C# 닷넷과 Node.js로 이루어진 어플리케이션이 많은데 팀 내에서 처음으로 Spring과 Kotlin을 적용하여 어플리케이션을 개발했습니다. 오라클을 사용하니 Stored Procedure 대신 jpa와 QueryDSL을 적용하였습니다.Admin 서비스는 스프링 멀티모듈로 만들어 웹 UI와 oracle에 접속할 api가 같은 도메인 모델을 공유하도록 하였습니다.기존 사내에서 사용되는 공통 Admin 시스템은 사용하는 모든 도메인이 관련 프론트엔드 저장소 한 곳에 있다 보니 개발, 배포가 번거로울 때가 있습니다. 프로젝트가 무거워 빌드에도 시간이 꽤 걸리고 어플리케이션 별로 자체 스케일링하기 어렵습니다. 관련 어드민에서는 외부 시스템과의 연동을 위해 SSO(Single Sign On)을 지원합니다. 이를 이용해 사내 쿠버네티스 시스템인 fusion에 올릴 수 있는 java/kotlin, node.js 등으로 변경하면 관리포인트가 줄어 유지보수에 매우 도움이 됩니다. 또한 닷넷 프레임웍을 쓰지 않기 때문에 맥북으로 개발이 가능해집니다. 하지만 사내 어드민 공통 기능은 자체적으로 구현해야 하고 별도의 admin qa를 거쳐야 하므로 개발기간이 길어질 수 있어 개발과 유지보수의 trade off 관계라고 생각합니다. 팀 내에서는 같은 기술스택이지만 다른 어드민을 작업하고 있었기 때문에 수월하게 적용할 수 있었습니다.HTMX + Thymeleaf  마찬가지로 cshtml이 아닌 htmx를 이용하여 admin ui를 구성했습니다. 완성도보다는 빠르게 기능을 구현하는데 목적을 둔 어플리케이션이지만 htmx 적용을 테크니컬 챌린지라고 말씀드릴 수 있습니다. (물론 일정이 촉박해질수록 후회를 안 할 수가 없었지만..)HTMX에 대해 한마디 하자면...html만 봐도 이해하기 쉽습니다. htmx는 별도의 스크립트를 이용하지 않고 서버와 ajax 통신을 도와주는 프론트엔드 웹 프레임워크입니다. 기존에 통신하기 위해 수많은 js 코드를 만들어야 했는데 보일러 플레이트를 꽤 많이 없애 코드량 자체가 줄어드는 효과가 있습니다. hx-  프리픽스가 붙은 속성을 선언해 간편하게 원하는 데이터를 만들어 낼 수 있습니다. 필요한 기능은 Extension으로 만들 수 있어 사용성이 무궁무진합니다. 또 빌드 단계도 별도로 없어 즉시 개발할 수 있게 도와줍니다.장단점이 아주 명확한데요, 장점은 서버 통신할 때 js는 정말 사용하지 않고 html 본연의 목적에 충실할 수 있다. 특히 thymeleaf와 결합하면 레이아웃 재사용으로 리액트의 컴포넌트 재사용과 같은 효과를 가질 수 있습니다. 백엔드 개발자 혼자서 프론트를 만들 수 있다는 것도 장점입니다. 단점은 json 데이터로 api 통신을 주고받았다 보니까 받았다 보니까 html 시맨틱 태그를 응답받는 것에 적응할 시간이 필요하다는 것과  간단한 통신을 해도 쉽지 않다는 것입니다. 특히 컨트롤러에서 @RequestBody만 주로 사용해 오다가 @RequestPart, @ModelAttribute로 바꾸고 data class가 바인딩되지 않는 이슈는 한참을 헤매게 만들었습니다.데이터를 주고받는 데이터 패킷량도 많아져 트래픽이 많이 몰리는 프론트 서비스에서는 사용이 부담스러울 수 있습니다. 무엇보다 필요한 기능은 결국 js를 써야 합니다 써야 합니다. Csv 엑셀 다운로드, form reset이나 date-picker를 사용하기  위한 공통 함수 작성.. 그리고 typescript를 쓸 수 없다..는 것이 또 큰 단점이죠. Htmx 레퍼런스가 많이 없어 거대한 js 덩어리를 디버깅해 가며 입맛에 맞게 수정했던 경험도 있네요. htmx에 대해 아주 신랄