굳이 Svelte 를 선택한 이유왜 하필 Svelte 인가요? 아직 시기상조 아닐까요?Javascript 가 Web 표준 개발 언어기 때문에, 자연스럽게 해당 언어에 기반한 Web Framework (혹은 Library) 는 짧은 시간 내 굉장히 많이 생기고, 동시에 많이 사라지고 있는 것 같습니다.Web Framework 를 선택하는 것이 더욱 어려운 이유는, Frontend 분야의 트렌드가 다른 개발 분야에 비해 비교적 빠르게 변화하고 있기 때문입니다.실제로, 지난 10년 사이에 크고 작은 지각 변동이 수차례 있었던 것 같습니다.2010년대 초반에는 jQuery, 2010년대 중반에는 Angular, 2010년대 후반 이후에는 React 와 Vue 가 Web Framework 핵심 트렌드였던 것 같습니다.개인적으로는 대부분의 기간을 Frontend 분야와 친숙하게 지내지 않았기 때문에, 위와 같이 빠르게 변하는 Frontend 업계 트렌드를 그저 '옆동네 불구경' 정도로 생각했던 것 같습니다.막상 Web 개발 공부를 시작하려다 보니 꽤나 많은 선택지 앞에서 당황했고, 실제로 공부하고자 하는 Web Framework 를 선택하는 과정에서 많은 고민을 하게 되었습니다.현재 시점에서 Javascript 기반의 Web Framework 를 선택할 때, 가장 안정적인 옵션은 의심의 여지없이 React 혹은 Vue 입니다.Frontend 분야에서 이미 전세계에서 큰 비중으로 활용되고 있기에, 개발 안정성이나 확장 가능성은 보장되었다고 해도 무방합니다.실제로, Frontend 분야의 채용 시장도 모두 React, Vue 중심으로 열려 있고, 온라인과 오프라인 구분할 것 없이 대부분의 학습 자료는 해당 Web Framework 위주로 구성되어 있습니다.또한, 현실적으로 개발자들에게 굉장히 중요한 요소로 작용하는 커뮤니티 성숙도 측면에서 압도적인 모습을 보이고 있습니다.직면한 문제가 무엇이든, 대부분 Google 혹은 Youtube 에 이미 해당 문제를 경험하고 해결한 사례가 존재하기 때문에React, Vue 에 익숙하지 않은 개발자더라도 풍부한 Reference 를 통해 어렵지 않게 궁금증을 해결할 수 있습니다.심지어, ChatGPT 도 다른 Web Framework 와 관련된 질문보다는 React, Vue 와 관련된 질문에 보다 명쾌한 해결책을 제시하는 경우가 많습니다.처음 Svelte 를 접하게 된 계기는 '노마드 코더' 라는 유튜버의 Svelte 소개 영상이었습니다.Frontend 분야에 대한 기본 지식이 부족했기에, Svelte 를 추천하는 다양한 이론적인 (Virtual DOM 을 사용하지 않는다든가, 경량화 되었다든가, 실질적인 의미의 Reactive 특성이 구현된 형태다든가 하는) 강점보다는,초심자 입장에서 가시적으로 느낄 수 있을 정도의 간결한 Code 형태가 굉장히 매력적으로 다가왔습니다.이를 계기로, Svelte 라는 Web Framework 에 관심을 가지고 다양한 자료를 찾아보기 시작했습니다.하단에 첨부된 이미지와 같이, 20

안녕하세요. 오랜만에 인사드립니다.올 상반기에 에이닷 앱의 웹 뷰 서비스를 새로 구축하는 업무를 맡게 되었습니다.Nuxt.js 프레임웍(이하 Nuxt) 기반으로 빠르게 서비스를 출시 할 수 있었는데 그 이야기를 해보려고 합니다.에이닷 앱 웹 뷰는 2018년도 기술로 구축 된 레거시 프로젝트가 존재합니다.6년이라는 시간이 흐르는 동안 Front-End 진형의 기술은 크게 발전했습니다.기술 부채가 많은 레거시 프로젝트 위에서 서비스를 확장하려면 여러 불편함이 존재했는데, 이는 최신 기술을 사용하면 대부분 해결될 문제였습니다.바꾸고 싶다는 생각은 여러 번 했지만 시간과 자원이 많이 들어가는 일이라 결정이 필요했습니다.담당님의 지원으로 프로젝트 세팅, 빌드/배포, 서버 구축까지 새로 할 수 있게 됐습니다.현재 가장 인기가 많은 라이브러리는 React.js(이하 React)입니다. 그런데 왜 Vue.js(이하 Vue)의 Nuxt를 선택했을까요?가장 큰 이유는 "러닝 커브(Learning curve)가 낮다"를 이유입니다.저는 React로 4년, Vue로 4년 개발했습니다. React를 먼저 배우고 나중에 Vue를 배웠습니다. React의 개념이 있는 상태에서 Vue를 배우는 건 어렵지 않았습니다.양방향 바인딩의 개념을 이해하고 잘 사용할수 있으면 오히려 편하다는 느낌을 받았습니다.신규 프로젝트 세팅과 신규 서비스 출시 기간이 짧지 않은 상태에서 러닝 커브가 높은 React보다 낮은 Vue를 선택하는 게 맞다고 판단했습니다.또 React는 단방향 바인딩만 가능하기 때문에 부모 컴포넌트의 상태를 바꾸려면 handler를 구현해서 자식 컴포넌트에 props로 내려 줘야 하는데 이것은 props drilling의 고통을 가중합니다.Vue의 경우 양방향 바인딩을 지원하기 때문에 이를 깔끔하게 처리 할수 있다는 장점도 크게 다가왔습니다.React 생태계만큼 Vue도 디버깅 도구, 빠른 업데이트, Nuxt를 지원하고 있어 서비스를 운영하는데 문제가 없다고 판단했습니다.기존 레거시는 jQuery 라이브러리가 코어 모듈이었습니다.jQuery의 경험이 있는 분은 알겠지만, HTML 요소의 변경을 주려면 요소를 선택하고 제공하는 속성에 접근해서 값을 하나하나 변경해야 합니다. 정말 귀찮은 일입니다.데이터 기반의 라이브러리를 사용하면 데이터 변경 시 라이브러리에서 알아서 변경해 주기 때문에 불필요한 DOM 요소 조작이 필요 없습니다.아래 예는 Vue 방식입니다.아주 단순한 코드라 별 차이가 없다고 느낄 수 있으나 DOM 요소를 찾는 일을 100번 반복한다고 상상하면 크게 다가오실 겁니다.이 장점은 Nuxt의 장점이라기보다 Vue의 장점이지만 레거시 프로젝트와 비교해서 가장 큰 장점이라 먼저 이야기합니다.프레임웍의 장점은 수많은 논의 끝에 정규화된 규칙이 존재하고 사용자는 그 규칙에 맞게 세팅하면 자동으로 해결되는 게 많다는 점입니다.프레임웍을 사용하지 않고 프로젝트를 구성하려면 프로젝트의 구조, 사용할 코어 라이브러리, 폴더 이름 하나까지도 논의가 이뤄져야 합니다.프레임웍을 도입함으로써 결정의 시간을 줄일 수 있었습니다.빌드 설정은 자주 하는 게 아니다 보니 늘 복잡하고 헷갈립니다.Nuxt는 대부분의 설정을 알아서 해줍니다. 몇 가지 필요한 부분만 문서를 통해 이해하고 추가하면 되기 때문에 간편합니다.복잡한 Webpack 문서를 읽을 필요가 없습니다.Nuxt에서 제공하는 유틸리티 함수들이 있습니다.서버의 API 호출을 하려면 대게는 라이브러리를 사용합니다. Axios가 대표적입니다.Nuxt는 Ajax 호출을 할 수 있는 내장 유틸리티 함수를 제공합니다. fetch 함수인데 사용 방법이 간단합니다.개발하다 보면 필요한 모듈들을 import 해서 상단이 지저분해지는 경험을 했을겁니다.순서도 개발자마다 스타일이 달라서 논쟁이 되죠.nuxt는 특정 폴더의 파일들을 알아서 import 해주기 때문에 신경 쓰지 않고 개발할 수 있습니다.Nuxt로 프로젝트를 기본 틀을 설정한 후, 실무에서 필요한 몇 가지를 추가했습니다.Nuxt에서 제공하는 디렉터리 외에 필요한 디렉리가 있어서 추가했습니다.• None constants : 상숫값을 등록하는 디렉터리입니다.• None dto : DTO(Data Transfer Object)가 모여 있는 디렉터리입니다.• None type : 타입스크립트의 타입이 모여 있는 디렉터리입니다.• None stores : 서버 API를 호출하고 pinia를 사용한 상태 관리를 위한 디렉터리입니다.기존 레거시 프로젝트의 문제점 중의 하나였던 부분이 코딩 컨벤션이 제각각 달랐다는 점입니다.IDE 설정을 하지 않고, 코드 리뷰도 하지 않으면 코딩 컨벤션을 지키게 할 방법이 없기 때문에 이를 강제할 수 있는 수단이 필요했습니다.husky를 사용하여 git commit을 할 때 자동으로 prettier 검사가 되고 자동으로 수정 됩니다. prettier 맞게 수정해야 commit을 할수 있도록 강제했습니다.gitlab runner를 활용해서 MR(Merge Request)을 올리면 자동으로 eslint, test가 동작하도록 구성했습니다. 모두 pass 해야 MR을 Merge 할 수 있도록 강제했습니다.nuxt.config.ts 는 Nuxt의 설정을 세팅을 변경할 수 있는 파일입니다. 서비스에 적용하면서 몇 가지 추가한 내용을 남깁니다.아래와 같이 app 하위에 head에 들어갈 정보를 수정할 수 있습니다.server side rendering이 기본으로 true가 되어 있기 때문에 ssr 옵션을 false로 변경해 줘야 정적 파일로 빌드됩니다.서버 환경 구축에 따라 옵션을 설정하면 됩니다.신규 프로젝트를 구성하는데 어떤 라이브러리와 프래임웍을 사용할지 결정하는 것은 쉽지 않습니다.많은 서비스가 운영되고 있다는 사실을 알고 있지만, 실제 내 서비스에 도입할 때는 상황에 따라 고려해야 하는 부분이 다를 것입니다.이 글이 새로운 프로젝트를 구성하는 데 의사결정을 하는데 도움이 되었으면 좋겠습니다.

여러분은 라이브러리를 만들어봤거나, 만들어야겠다고 생각해본 적이 있나요? 아마 개발자라면 한 번 쯤은 생각해보셨을 것 같습니다. 라이브러리를 만들 때는 해결하려는 문제와 설계 목적, 그리고 개발자의 요구에 따라 고려해야 하는 요소들이 다양합니다. 그중에서도 라이브러리가 다양한 환경에서 사용하려는 목표가 있다면, 범용성을 고려하죠.이번에는 프론트엔드 개발 환경에서 높은 범용성을 나타내는 용어 중 하나인 “Framework Agnostic”에 대해 이야기 해보려고 합니다.소프트웨어 엔지니어링에서 "Agnostic"이라는 용어는 소프트웨어가 특정 환경(예: 운영 체제, 하드웨어 플랫폼, 프로그래밍 언어, 프로토콜 또는 기타 기술 영역)에 독립적으로 설계되었다는 속성을 나타냅니다. 따라서 Framework Agnostic은 프레임워크라는 환경에 독립적으로 설계되었다는 속성을 나타내죠.JavaScript 라이브러리 개발에서 Framework Agnostic 접근 방식은 특정 프레임워크에 종속되지 않는 라이브러리를 작성하는 것을 의미합니다. 이를 통해 라이브러리는 다양한 프레임워크와 호환 가능해지고, 개발자는 보다 넓은 범위의 프로젝트에서 라이브러리를 재사용할 수 있습니다.조금 더 범위를 축소해 프론트엔드 개발 관점에서 바라본다면, Framework Agnostic하다는 것은 React, Vue와 같은 웹 프레임워크 혹은 라이브러리에 상관 없이 의도된 동작이 잘 실행되도록 설계되었다는 것을 의미합니다.React를 사용한다면 Tanstack Query라는 라이브러리를 한 번 쯤은 들어보셨을텐데요. JavaScript 애플리케이션에서 데이터를 가져오고 서버와의 데이터 통신, 캐싱, 동기화, 데이터 무효화 등을 간소화해주는 역할을 해요.Tanstack Query도 Framework Agnostic한 라이브러리 중 하나예요. React Query라는 이름을 가졌던 라이브러리였지만 v4 버전부터 이름을 Tanstack Query로 바꾸고 Framework Agnostic한 라이브러리로 거듭났어요. Vue, Svelte, Solid 등 다양한 프론트엔드 라이브러리 및 프레임워크에서도 사용할 수 있게 되었죠.Tanstack Query는 어떻게 Framework Agnostic한 라이브러리를 만들 수 있었을까요? 소스 코드를 간단하게 분석해봤어요.Tanstack Query 소스 코드를 보면 모노레포로 구성된 것을 볼 수 있어요. 모노레포에서 운영되는 패키지들이 모여있는 디렉터리를 볼까요?이 디렉터리에 , 등 Framework에 의존성이 있어보이는 패키지들이 여러 개 존재하네요. 또, 라는 이름에서 알 수 있듯 핵심(core) 로직이 담겨있는 것처럼 보이는 패키지가 하나 있습니다.react-query와 query-core의 관계성 알아보기우리의 추측대로라면 는 프레임워크에 의존성이 없는 핵심 로직들만 들어있고, 는 리액트에 의존성이 있는 로직들이 들어있을 것 같아요. 우리의 추측이 맞는지 이 두 패키지의 package.json를 들여다볼게요.package.json

이번 포스팅은 Vue3, Composition API와 Pinia를 이용한 상태관리 (1) 글의 후편입니다. 이전 포스팅에서 Composition API, Pinia에 대한 이론적인 설명을 다루었다면 이번 포스팅에서는 실제로 Pinia를 어떤 방식으로 적용했고 어떤 작업 결과를 냈는지 다루려합니다.글의 목차는 아래와 같습니다. 03. 적용 결과: 인재풀에서의 Pinia 04. 느낀점: 이론적 장단점과 내가 느낀 실제Vue3가 적용된 서비스 런칭으로 약 1년 정도의 시간이 지나면서 당시 프로젝트 작업자 외에 많은 팀원들이 Vue3를 직접 경험할 수 있었습니다. 프로젝트 작업시의 관점 뿐만 아니라 서비스 운영, 유지보수 관점에서 느낀 , , 의 장단점에 대해 이야기하고자 합니다.컴포넌트 구성 방식을 좌우하는 주요 기능인 와 에 대해 설명하고 본격적으로 가 무엇인지 마지막으로 실제 사람인 인재풀에서는 어떤 부분에 어떻게 적용되었고 그 과정을 통해 느낀점을 이야기해보겠습니다.3. 적용 결과: 인재풀에서의 Pinia설명에 앞서 사람인 인재풀 서비스에 대한 이해가 필요합니다. 인재풀은 기업 회원에게 제공되고 있는 서비스로 아래 화면과 같이 좌측 검색 필터를 활용해 원하는 인재를 검색할 수 있는 서비스입니다. 사용자가 원하는 이력서 항목 조건을 설정하면 그에 맞는 인재 결과를 제공해주고 있습니다.인재풀 검색 필터 기능은 경력, 지역, 직무, 학력, 연봉, … 등 총 17가지 항목의 조건 변경이 가능합니다. 다양한 세부 항목이 존재하는 만큼 필요로하는 데이터가 복잡하며 데이터 변경이 잦은 영역입니다. 이러한 기능적 특징 때문에 검색 필터 영역을 단일 컴포넌트로 관리할 경우 코드 복잡도가 올라갈 수 있는 상황이었습니다. 따라서 검색 필터 영역은 라는 상위 컴포넌트 아래 항목 단위로 분리된 자식 컴포넌트를 갖도록 구성했습니다.인재 검색 기능은 아래와 같이 동작하게 됩니다.모든 검색 필터 조건 정보를 담은 JSON 형태의 데이터가 인재 검색 API 요청 파라미터 정보로 활용됩니다. 검색 필터의 세부 항목에서 변경이 발생하게 되면 해당 항목 컴포넌트 내부에서 검색 필터 데이터 변경, 검색 리스트 API 재호출이 순차적으로 수행되게 됩니다. 이때 필터 데이터 변경, API 재호출 동작은 각기 다른 컴포넌트 내부 동작에 의해 발생하지만 최종적으로 활용되는 데이터는 검색 필터 조건 정보를 담은 공통의 데이터 입니다.활용되는 필터 데이터는 공통의 데이터이기 때문에 어떤 컴포넌트에서 해당 데이터를 참조하던 동일한 상태여야합니다. 활용되는 공통 데이터의 구조가 복잡하다는 점과 각기 다른 컴포넌트에서 공통의 데이터 상태가 공유되는 프로젝트 특성상 상태관리 라이브러리 활용의 장점을 경험하기에 적합했고 라이브러리 적용을 결정하게 되었습니다. (물론 검색 필터 기능 외에 다른 기능을 위해서도 스토어를 정의하며 상태 관리 라이브러리를 활용했습니다.)이번 프로젝트에서는 모든 작업자들이 를 처음 접하는 상황이었기에 공식 문서를 적극 활용해 공식 문서에서 제공해주는 기본 구조를 기