기술 스택 고르기

기술 스택이란

기술 스택은 프로젝트에 쓰는 언어·프레임워크·DB·인프라·도구의 묶음이다. 개발은 누군가 만든 기술 위에 내 기능을 얹는 일이라, 프로젝트는 고른 스택에 의존할 수밖에 없다. 스택은 개발 속도, 유지 보수, 팀 협업, 사람 뽑기, 장기 생존에 모두 영향을 준다.

스택은 혼자 쓰지 않는다. 누군가 문제를 느껴 새 방법을 내놓고, 비슷한 문제를 겪는 사람들이 묻고 답하며 고치는 과정에서 단단해진다. 그래서 커뮤니티가 스택을 키운다. 커뮤니티가 없는 기술은 막혔을 때 도움을 받을 곳이 없고, 그 인식이 다시 사람을 떠나게 하는 악순환에 빠진다.

유행은 어떻게 만들어지나

기술 수용 주기

캐즘과 하이프 사이클

• 캐즘(Chasm): 얼리어답터의 열광과 대중의 수용 사이에 있는 깊은 골. 새 기술을 배우고 바꾸는 데는 비용이 들기 때문에 대부분은 주류가 될 것 같을 때에야 움직인다. 이 골을 넘는 기술은 드물다.
• 하이프 사이클(Hype Cycle): 발표 → 과대 기대 → 현실 검증 → 주류 수용. 얼리어답터가 떠들 때가 가장 시끄럽다. 그들이 열정적으로 홍보하는 이유는 캐즘을 못 넘으면 좋아하는 기술이 사라진다는 걸 알기 때문이다.
• 프론트엔드는 jQuery → AngularJS → React·Vue·Angular → Svelte·Solid·Qwik으로 10년 넘게 거대한 하이프를 겪은 뒤 안정기에 들어섰다. 하이프가 지난 것은 몰락이 아니라 안정이다. 대안 프레임워크가 내놓은 아이디어(컴파일러 최적화, 시그널 반응성)는 주류 프레임워크가 흡수하는 식으로 퍼진다.

캐즘을 넘었는지 알아보는 법

혁신가는 "이런 새 문제를 풀 수 있다"고 말한다. 주류가 된 기술은 알려진 문제의 해결 과정이 공유된다. 학원 커리큘럼, 취업 블로그, TIL에 등장하면 확실히 넘은 것이다.

수치로 확인할 때는 해마다 나오는 개발자 설문의 사용률과 만족도 추이를 본다. Stack Overflow Developer Survey는 언어·프레임워크 전반을, State of JavaScript·State of CSS는 프론트엔드 도구를 써 본 사람의 재사용 의향까지 보여 주고, GitHub Octoverse는 저장소 활동량으로 생태계 규모를 보여 준다. 사용률은 높은데 만족도가 떨어지는 도구는 레거시로 넘어가는 중이다. 취업 준비라면 가고 싶은 회사 목록을 먼저 뽑아 채용 공고에 적힌 스택을 모으는 것이 가장 직접적인 기준이다.

고르는 기준

잘 모르면 커뮤니티가 큰 도구를, 팀원이 가장 많이 아는 도구를 고르는 게 대부분 안전하다.

비주류를 고르면 생기는 일

결과물에 문제가 없어도 비주류 스택(자체 제작 프레임워크 포함)에는 대가가 따른다.

• 쓰는 사람의 이력에 주류 프레임워크 경험이 비게 된다. 채용은 경험을 요구하고, 경험은 채용돼야 쌓인다.
• 인수인계가 어렵다. 문서 없는 자체 프레임워크나 작은 생태계의 기술은 담당 팀이 바뀌면 주류 스택으로 다시 짜이기 쉽다.
• 생태계가 작으면 필요한 것을 찾기 전에 직접 만들어야 하고, 베스트 프랙티스가 없다.

좋은 기술이라는 것과 회사에서 쓸 기술이라는 것은 다르다. 비주류 기술은 사이드 프로젝트로 해 보기에 좋다.

큰 팀은 유지 보수성과 안정성을 먼저 본다

팀이 빠르게 커지고 백엔드 개발자·신입까지 프론트엔드 코드를 만지면 기준의 무게가 바뀐다. 한 사람의 생산성보다 처음 온 사람이 고쳐도 깨지지 않는가가 중요해진다. 코드는 쓰는 횟수보다 읽는 횟수가 많기 때문이다.

작은 팀과 짧은 프로젝트에서는 이 비용(설정, 타입, 린트 규칙)이 이득보다 클 수 있다. 결정은 팀의 크기와 코드의 수명에 맞춘다.

선택은 계층마다 「무엇을 · 왜 · 대안은」으로 적어 둔다. 그 문서가 새 팀원의 학습 가이드가 되고, 나중에 다시 평가할 때 기준이 된다. 「지금은 Flow, TypeScript와의 격차가 벌어지면 다시 본다」처럼 재평가 조건까지 적으면 결정이 낡았는지 알아보기 쉽다. 경쟁 도구가 비슷하면 「하나라도 쓰는 것이 안 쓰는 것보다 낫다」가 기준이 된다. Flow를 고른 팀도 문법이 비슷해 TypeScript로 큰 비용 없이 옮겨 갔다.

트렌드는 범주로 읽는다

스택 숙련도와 스택 이해도는 다르다. 숙련도는 특정 도구로 문제를 풀어 본 경험(짬)이고, 이해도는 그 도구가 어떤 범주의 어떤 문제를 풀려는지 아는 것이다. React·Vue·Angular는 모두 "DOM 직접 조작보다 데이터 기반 컴포넌트 렌더링이 낫다"는 같은 범주에 있다. 하나를 잘하면 나머지도 금방 한다.

개발 언어 · 프레임워크 · 메타 프레임워크 · 상태 관리 · 서버 상태 관리
유틸리티 CSS · CSS 방법론 · 컴포넌트 라이브러리 · 디자인 시스템
패키지 관리자 · 런타임 · 번들러·빌드 도구 · 포매터 · 테스트 도구 · 문서화 도구

새 기술이 나오면 두 가지만 묻는다.

1. 기존 범주의 어떤 문제를 개선하려는가?
2. 전에 없던 새 범주와 패러다임을 만드는가? (jQuery → 프레임워크처럼) 이쪽이면 더 주의 깊게 본다.

범주마다 주류 하나를 숙련하고 나머지는 배경과 코어 컨셉만 이해해도 트렌드를 따라가기에 충분하다.

계층별 기본 선택 (2026)

캐즘을 넘어 기본값이 된 조합이다. 코드를 짜는 계층뿐 아니라 코드를 사용자에게 보내고 지켜보는 계층까지 한 줄씩 정해야 스택이 완성된다.

레거시를 대하는 자세

• 기술은 사람들이 더 이상 배우고 싶어 하지 않을 때 레거시가 된다. 오래된 것이 곧 레거시는 아니다. 아직 쓰인다면 이유가 있다.
• 표준이 바뀌는 데는 시간이 오래 걸린다. 늦은 다수여도 괜찮다. 다만 미루다 컴포트 존에 숨는 기술 꼰대가 되지는 않는다.
• 커리어에서 스택 전환은 최소 한두 번 온다. 불안해할 필요는 없지만 준비는 한다.
• 내 성향과 팀원의 성향이 수용 주기의 어디인지 알면 스택 논쟁이 편해진다. 성향은 틀린 게 아니라 다른 것이다.

정리

• 스택은 함께 쓰는 것이라 커뮤니티와 생태계가 기술의 수명을 정한다.
• 새 기술 대부분은 캐즘을 넘지 못한다. 가장 시끄러운 때는 얼리어답터 구간이니 조급해할 필요 없다.
• 범용성·학습 비용·커뮤니티·인력·지속 가능성으로 고르고, 모르면 다수가 쓰는 것을 쓴다.
• 큰 팀은 관례보다 도구가 강제하는 쪽, 경계가 분명하고 재현되는 쪽을 고른다. 계층마다 무엇을·왜·대안을 적어 두고 재평가 조건을 단다.
• 도구 하나보다 범주와 문제 인식을 이해하면 무엇이 나와도 따라갈 수 있다.

관련 노트: 프론트엔드 개발자의 업무 범위와 역량, React와 Vue 말고: 다른 프론트엔드 프레임워크, 번들러의 역사와 Vite, 프론트엔드 학습 로드맵