2023년 테크 스택

회사가 아닌 나만의 테크스택 입니다.
추후 변경의 여지가 있습니다.

Svelte

사실상 리액트를 실무에서 쓰고 있음에도 이에 대해 굉장히 불만이 많은 상태였다.
리액트를 쓰기 위해 부수적인 라이브러리 설치와 이에 따른 설정과 Boilerplate 작성.
JSX를 최적화 시켜주기 위해 나오는 새로운 버젼들의 사항들, 상태관리 라이브러리들 간에 다른 패턴들.
이게 너무 불편해서 리액트 템플릿을 만들었지만 뭔가 시원하게 뻥 뚤리는 느낌은 아니었다.

아니, 에이전시 시절에 제이쿼리로 라이브러리 갖다 쓸때도 이정도는 아니었는데 이게 맞냐?
점점 그냥 백엔드 == 스프링마냥 무지성 프론트 == 리액트화 되는거 같은 느낌이었다.
내가 이상한건가 팀원과 얘기해보니 나만 그런게 아니라 리액트에 대해 다들 어느정도 불만들이 있었다.
그러던 도중 전부터 눈여겨 보았던 Svelte를 최근 1주정도 사용해봤는데 바로 이거다! 라는 느낌이 왔다.

퍼블리셔에게 익숙한 스타일의 작업방식과(Vue랑 비슷) useState, useMemo등 JSX의 괴랄한? 문법도 따로 없으며 스타일이 기본 스코프되어 CSS-IN-JS도 할 필요 없고 Recoil과 사용법이 비슷한 상태관리 라이브러리가 내장되어 있으며 양방향, 단방향 바인딩도 선택이 가능한 그냥 혁명 그 잡채...
러닝커브도 굉장히 낮아서 React든 Vue든 SPA와 바닐라 자바스크립트에 이해도가 있으면 1주면 충분히 뗀다고 생각한다.

진짜 Svelte로 작업을 하는 곳이 있다면 가서 일하고 싶을 정도로 만족스러웠는데 실무에서 쓰는곳이 적다는게 아쉽다ㅠㅠ

Tailwind

Tailwind + SCSS 조합으로 정했다.
MUI는 팀에서 사용해서 썼는데 커스텀이 진짜 너무 어렵다.
그리고 MUI를 사용하기 위해 그에 맞는 사용법? 이라고 해야하나.. 여튼 그런걸 익혀야 되서 고통스러웠다.
사실 디자인도 쫌 구..린.. 것 같다.
뭔가 디자이너 없는 사이드 프로젝트 느낌의 프로덕트랄까..

그 대안으로 Chakra가 있었는데 Tailwind + SCSS가 Tailwind를 안다면 바로 눈에 들어와 팀끼리 작업할때도 쉬울거라고 생각한다.
팀내 정한 CSS 작성 순서 대로 스타일만 잘 먹여준다면!

GraphQL

전에는 이정도까지 아니었는데 요새 굉장히 수면위로 많이 떠오르면서 주목 받는 것 같다.
뭔가 초기 스타트업에서는 Next, Nuxt, SvelteKit 등을 활용해 Full-Stack 프레임워크에 SSR을 MongoDB + GraphQL 조합으로 시작하는걸 꽤 발견할 수 있었다.

2년 전쯤인가 Apollo로 찍먹해보고 나름 신세계여서 '와 쩐다 이거 진짜 좋은데?' 라고 흥분했는데 막상 도입하는 곳은 적었지만 요즘 점점 핫해지는것 같아 테크스택에 포함했다.

Apollo를 사용할지 Urql을 사용할지는 모르겠는데 일단 둘다 해보면서 장단점을 비교해봐야겠다.

Bun

런타임 환경은 Bun 또는 Node를 가져가려고 한다.
개인적으로 Deno는 Bun의 등장으로 이점들이 다 사라진것 같다.
현 프로젝트도 Bun으로 되어있는데 2023년에는 더욱 안정화 되지 않을까 싶다.

Node에서의 패키지 매니지먼트는 yarn을 사용하려고 한다.
전에 yarn-berry 를 썼다가 쫌 크게 데인? 기억이 있어서 yarn으로 가려고 한다.
yarnberry 가 zip으로 속도 측면에서 장점을 제공해주긴 하지만 storybook등 호환시에 버그때문에도 설정이 힘들었고 일단은 보류이다.
특정 파일들은 여전히 node_modules에 설치되기도 하고 말이다.

yarn의 대안인 pnpm은 아직 제대로 써보질 않아서 써보고 정하려고한다.
번들링 툴은 Vite 고정으로 사용하려 한다.

AWS

CI/CD를 위한 나만의 쉘 스크립트 템플릿도 있고 AWS를 이용해 배포도 가능한데 더 위의 수준으로 레벨업을 하려고 한다.
관련 자격증도 따고 컨테이너를 활용한 ECS 또는 ECK 등도 배워보려 한다.
더 나아가 Terraform 을 활용한 설계까지 목표로 하고 있다.

시간이 된다면 GCP랑 비교해서 비용측면에서 유리한 부분들만 서비스에 맞게 가져오는 방식도 해볼까 생각중이다.

NestJS

SpringBoot는 당분간 쳐다보지 않을 생각이다.
현재 잠깐 서드파티 측이랑 API 연동하는 것 때문에 Spring Boot를 사용하고 있기는 한데 개발자 경험에서 너무 떨어진다.
처음 개발 배울때 시작한 언어가 Java이고 학교에서도 백엔드는 Spring Boot로 과제와 시험을 봤지만 애증의 SpringBoot는 안녕이다.
뭐랄까, 자바 버젼으로 인한 충돌도 그렇고 프레임워크가 너무 무겁고 반복되게 작성해야 되는게 너무 많고 설정도 복잡하다.
코프링도 음 뭔가... 손이 안가..

이에 비해 NestJS는 굉장히 만족스럽다.
MVC 패턴의 SpringBoot랑 코드 작성 방식이 비슷해 이해도 쉽고,
Express의 자유분방함을 잡아주면서 정해진 규칙내에서의 작성이 마음을 편안하게 해준다.
또한 프론트와의 통일된 언어로 개발이 가능한것도 크다.
string 썼다가 String 썼다가 멈춰!!!

Prisma2

사실 이건 확정? 은 아닌데 팀원이 예전에 Prisma vs TypeORM 관련 발표한 것을 보고 관심이 생겼다.
NestJS 밋업 참여했을 때도 Prisma에 대해서도 웅성웅성 다들 많은 이야기를 나누는게 들렸다.

관심이 많이 가는 녀석이라 일단 넣어뒀다.
얘도 TypeORM이랑 비교해보고 선택하는걸로!

MongoDB & MySQL

DB는 몽고db와 MySQL 을 가져가려고 한다.
그리고 제 3정규화의 설계 및 쿼리 뿐만 아니라 DB 내부를 쫌 많이 깊게 파보려고 한다.
PostgresQL 을 선택하지 않은 이유는
네이버 지클라우드 등 PostgresQL을 지원하지 않는 곳들이 아직 있어서이다.

Flutter

우선순위에서는 밀리지만 앱 개발을 배워 볼 생각이다.
사이드 프로젝트 다 만들고 나서 내가 껍데기 씌워서 크로스 플랫폼으로 배포도 해보고 싶고 뭐 그렇다.

React Native랑 고민했지만 Flutter를 고른 이유는 단순히 재밌어보여서 이다.
Flutter 해보고 별로면 RN으로 가면 되지~

TDD

사실 테스트 코드에 대해서 2022 상반기 까지 회의적이었다.
"콘솔 찍거나 Swagger, Postman으로 요청 때리는거랑 뭐가 다름? 아니, 내가 특정 상황을 생각하지 못해 테스트 코드를 작성 못하면 어차피 런타임환경에서 그 상황에 버그 뜨는건 마찬가지 아님? 특정 상황을 생각했다면 걍 직접 QA 하면 되잖아..?"
러닝커브가 낮은것도 아니고 배워서 적용해도 테스트코드를 작성하기 위한 시간 그리고 그 테스트 코드를 작성하기 위해 필요한 설정 코드들.. 목업.. 이거 또 대세라고 하니까 그냥 너도 나도 다 불나방마냥 하는거 같은데...

라는 매우 잘못된 생각을 갖고 있었지만 바뀌게 되었다.
바뀌게 된건 다름 아닌 CTO님과 커리어 관련 얘기를 나누던 도중이었는데 CTO님 왈
"테스트 커버리지는 그렇게 중요하지 않다고 생각해요. 예외 상황을 생각해서 그에 맞는 테스트 코드를 작성해야 해요. 테스트 코드의 진가는 리팩토링 및 코드를 수정해야 될때 발휘되거든요."

그래. 바로 이거다! 그래서 였구나.
해야될 이유를 명백히 알았는데 안할 이유가 없잖아?

커버리지에 대한 집착보다 올바른 테스트 코드의 작성을 도입하려고 한다.

다양한 아키텍쳐

MSA 와 같은 다양한 아키텍쳐 설계에 대해 공부하고 적용하려고한다.
Turborepo 라든가 해외 포럼등을 주기적으로 체크해 사이드에 적용해보고 이점등을 정리하려 한다.

마무리

2023년도는 남들이 하니까 하는 Spring, React가 아닌
내가 원하는 내가 좋아하는 스택들을 해보려고 한다.
해봤는데 생각과 다르고 아니라면?
해온 근본이 있는데 1~2달 하면 다시 잘하겠지 뭐. 아예 새로운 걸 배워서 해야된다 해도 마찬가지고.
그리고 회사의 비젼과 나의 비젼이 맞는 빠른 피봇을 할 수 있는 서비스를 만들어보고 싶다.

혹시...
Svelte 또는 Nest를 쓰는곳이 있다면 굳이 연락은 사양하지 않겠습니다^^.