또 기술 스택을 바꾸고 있는 개발자에게
by 그릿 | GROWTH_ESSAY | 2026-07-12
#성장 #커리어 #기술스택멘토링을 하면서 한 가지 패턴을 자주 봤습니다. 처음에는 Spring을 배우다가 Go로 바꾸고, Go를 하다가 Node.js가 낫다고 들어서 다시 바꾸는 분들이 있습니다. 프론트도 마찬가지입니다. React에서 Vue, Vue에서 Svelte, Svelte에서 Next.js로.
1~2년이 지나도 스택이 하나로 정해지지 않습니다.
새로운 스택은 공부처럼 느껴집니다
새 기술을 배울 때는 뭔가를 하고 있다는 느낌이 납니다. 유튜브 강의를 틀면 진도가 나가고, 공식 문서를 읽으면 이해가 됩니다. 손가락이 움직이고, 코드가 실행됩니다.
그런데 이건 공부가 아닙니다. 새로운 문법에 적응하는 것입니다.
React를 3개월 했는데 Vue로 옮기면, 처음 2주는 빠릅니다. React를 하면서 이미 컴포넌트가 무엇인지, 상태 관리가 왜 필요한지를 몸으로 익혔기 때문입니다. 새로운 걸 배우는 게 아니라 이미 아는 것을 다른 언어로 번역하는 중입니다.
그래서 빠릅니다. 빠르니까 잘하고 있다는 착각이 생깁니다.
스택이 아니라 만들 것이 없습니다
200명 넘게 멘토링을 하면서 "어떤 스택이 좋아요?"라고 묻는 분들의 공통점을 발견했습니다. 스택 선택에 에너지를 쓰는 분들은 대부분 만들고 싶은 것이 없습니다.
만들고 싶은 게 있으면 그 스택을 씁니다. 회사에서 쓰는 걸 씁니다. 커뮤니티에서 많이 쓰는 걸 씁니다. 선택이 쉬워집니다.
반대로 만들고 싶은 게 없는 상태에서 스택을 고르면 선택이 어렵습니다. 어떤 걸 골라도 "저게 더 좋을 것 같은데"라는 생각이 따라옵니다. 3개월이 지나도 4개월이 지나도 확신이 없습니다.
스택이 문제가 아닙니다. 스택으로 해결할 문제가 없는 것이 문제입니다.
면접관이 보는 것
채용 담당자에게 직접 물어본 적이 있습니다. 이력서에서 뭘 먼저 보냐고. 거의 예외 없이 같은 대답이 나왔습니다.
"이 사람이 뭘 만들었는지요."
Spring도 좋고 Django도 좋습니다. 중요한 건 그 스택으로 무엇을 완성했느냐입니다. 반쪽짜리 React 프로젝트 3개보다, 완성된 Spring 프로젝트 1개가 낫습니다.
스택 목록이 길면 오히려 의심합니다. 이것저것 해봤지만 깊이가 없는 사람이라는 신호로 읽힙니다.
지금 스택으로 끝까지 가보세요
지금 하고 있는 스택이 무엇이든, 3개월 더 하세요. 기초 강의가 아니라 실제 서비스 하나를 처음부터 끝까지 만들어보세요. 배포까지.
배포를 해봐야 환경 변수가 뭔지 알게 됩니다. 실제 유저가 쓸 때 어떤 에러가 나는지 알게 됩니다. 성능이 왜 중요한지 몸으로 이해하게 됩니다.
스택을 바꾸려면 지금 스택의 한계를 직접 만나야 합니다. 강의에서 배워서 아는 한계가 아니라, 직접 부딪혀서 아는 한계여야 합니다. 그때 다른 스택을 보면 진짜 비교가 됩니다.