00:00:002026년 4월 현재, 저와 여러분 같은 개발자들에게 기술 스택 선택이 얼마나 중요할까요? AI 분야에서 일어난 수많은 일들과
00:00:23AI 모델의 발전, 그리고 무엇보다 Claude Code나 Codex 같은 AI 에이전트 도구들의 등장을 고려했을 때 말이죠.
00:00:31저는 이런 도구들에 대한 영상도 만들고 강의도 제작했는데요, 인기가 꽤 많습니다. 하지만 오늘 자세히 살펴보고
00:00:42제 의견을 나누고 싶은 질문은 바로 이것입니다. "개발자의 기술 스택 선택이 여전히 중요한가?"
00:00:57여전히 의미가 있을까요, 아니면 AI가 결정하게 둬야 할까요? 아니면 AI를 사용할 것이라는 전제하에 결정을 내려야 할까요?
00:01:16기술 스택에 신경 쓰지 않는 가장 기본적인 형태는, 참고로 저는 웹 개발자의 관점에서 주로 말씀드리겠지만
00:01:29모든 종류의 개발자에게 적용될 것입니다. 쉬운 길은 Claude Code 같은 도구를 사용하면서
00:01:47어떤 기술 스택이 선택되든 전혀 상관하지 않는 것이죠. TypeScript와 Next.js를 쓰든, 바닐라 자바스크립트를 쓰든,
00:02:09아니면 Angular를 쓰든 무슨 상관이겠어요? AI가 결정하게 두는 거죠.
00:02:16물론 그렇게 할 수도 있지만, 이는 소위 "바이브 코딩(vibe coding)"의 영역으로 들어가는 것입니다. 개발자가 아무런 선택도 하지 않고
00:02:45결정을 내리지 않으며, AI를 조종하거나 코드에 신경 쓰지 않기 시작하는 순간, 그것이 바로 제가 정의하는 바이브 코딩입니다.
00:02:59하지만 물론 이런 선택들이 더 이상 중요하지 않다고 말하는 방식이 하나 더 있는데, 그 문제로 다시 돌아가 보겠습니다.
00:03:16더 관련성 있는 다른 측면은, 개발자인 당신이 여전히 선택을 하긴 하지만, 결국 그 선택이
00:03:44개발 과정에서 AI를 많이 활용할 것이라는 사실에 영향을 받는다는 주장입니다. 코드를 검토하고 신경 쓰지만,
00:04:06AI가 잘 다루는 스택을 사용하는 것이죠. 예를 들어 학습 데이터가 많아서 AI가 잘 처리할 수 있는
00:04:28TypeScript나 Next.js를 사용하는 경우입니다. 이 두 가지가 핵심입니다. AI에게 맡기는 바이브 코딩 방식과
00:04:43AI의 선호도에 따라 선택을 내리는 방식이죠. 저는 두 접근 방식 모두 다소 잘못되었고 근시안적이라고 생각합니다.
00:05:06오히려 개발자로서 자신이 작업할 기술 스택에 대해 주관을 가지고 현명한 결정을 내리는 것이 그 어느 때보다 중요해졌다고 봅니다.
00:05:24개발자의 작업 방식이 변하고 있기 때문입니다. 우리는 코드를 덜 쓰고 있습니다. 저도 확실히 그렇고요.
00:05:36여러분은 다를 수도 있겠지만, 업계 전체를 보면 개발자가 코드를 직접 작성하는 비중이 줄어들고
00:05:53대신 AI 에이전트와 도구들을 오케스트레이션하고 활용하는 쪽으로 큰 변화가 일어나고 있음이 분명합니다.
00:06:13이는 우리가 내리는 선택과 결정이 훨씬 더 중요해졌음을 의미합니다. 만약 바이브 코딩의 늪에 빠져서
00:06:28AI가 모든 선택과 결정을 내리게 한다면, 개발자로서 그리 밝은 미래는 아닐 것입니다. 이유는 명확하죠.
00:06:43아무런 주관이나 영향력 없이 AI에게 물어보기만 한다면, 누가 개발자를 필요로 하겠습니까? 그런 방식은 어디로도 이어지지 않습니다.
00:06:51프로토타입을 빠르게 만들거나, 예외 케이스나 보안 문제를 크게 신경 쓰지 않아도 되는 내부용 앱을 만들 때는
00:07:01괜찮은 접근법일 수 있습니다. 바이브 코딩이 유효한 사용 사례는 분명히 존재하니까요.
00:07:09또한 바이브 코딩은 코딩을 할 줄 모르지만 자신에게 필요한 소프트웨어를 쉽게 만들고 싶은 사람들에게도 매우 유용할 수 있습니다.
00:07:20여러 단점이 있겠지만 나름의 목적이 있는 셈이죠. 그런 경우에는 기술 스택이 중요하지 않을 수 있고
00:07:34바이브 코딩을 하는 사람들은 어떤 선택지들이 있는지도 모를 수 있습니다.
00:07:45하지만 AI가 선택에 영향을 주게 한다는 주장에 대해서는, 약 1년 전이라면 몰라도 지금은 더 이상 유효하지 않다고 생각합니다.
00:08:00물론 AI가 선호하는 스택은 있습니다. 이전 영상에서도 언급했듯이, 웹 개발에서 AI에게 맡기면
00:08:10대부분 TypeScript, React, Next.js, Tailwind 프로젝트 결과물이 나올 확률이 높습니다.
00:08:17그게 AI가 가장 좋아하는 스택이고 거기에는 이유가 있습니다. 학습 데이터에 해당 프로젝트들이 아주 많았기 때문이죠.
00:08:31하지만 2010년대 초반의 코드까지 포함해서 학습 데이터를 본다면, 당시에는 Tailwind도 없었고
00:08:44TypeScript나 Next.js 프로젝트도 거의 없었을 것입니다. 대신 바닐라 자바스크립트나 jQuery 프로젝트가
00:09:04학습 데이터에 엄청나게 많았겠죠. 그럼에도 불구하고 그것들이 AI의 선호 스택이 아닌 이유는
00:09:20단순히 학습 데이터의 양 때문만이 아닙니다. 우리가 사용하는 AI 모델들은 제공자에 의해 여러 단계를 거치게 되는데,
00:09:34사전 학습, 미세 조정, 강화 학습 단계 등을 거치며 모델의 행동 방식이 형성됩니다.
00:09:51그리고 시스템 프롬프트도 있죠. Claude Code 같은 도구를 사용할 때 모델이 특정 방식으로 행동하도록 지시하는
00:10:07보이지 않는 시스템 프롬프트가 존재합니다. 우리는 이미 이 모델들이 TypeScript나 React 같은
00:10:24특정 기술을 선호하도록 영향을 받았다는 사실을 알고 있습니다. 왜 그럴까요?
00:10:43특히 TypeScript의 경우, AI가 생성한 코드를 타입 에러 체크를 통해 스스로 검증할 수 있기 때문에 AI에게 매우 유리합니다.
00:10:57물론 타입 에러가 없다고 해서 반드시 좋은 코드나 의도대로 작동하는 코드인 것은 아니지만,
00:11:03하나의 지표는 됩니다. 제가 알기로는 바닐라 자바스크립트보다는 결과가 더 나은 경향이 있습니다.
00:11:14이것이 AI가 특정 스택을 선호하는 이유이며, 여러분이 그 스택을 따라가는 게 좋겠다고 결론 내릴 수 있는 이유이기도 합니다.
00:11:28예를 들어, AI가 TypeScript 같은 타입 안정성 있는 언어에서 더 성능이 좋다는 이야기를 제게 들었기 때문에
00:11:42바닐라 자바스크립트는 쓰지 않기로 결정할 수도 있죠. 어느 정도 일리가 있는 말이지만, 2026년 4월 현재
00:11:51AI와 Claude Code 같은 에이전트들은 어떤 기술 스택을 던져줘도 아주 잘 처리한다는 사실이 반복적으로 증명되었습니다.
00:12:03과거에는 학습 데이터가 적거나 아예 없는 아주 새로운 라이브러리나 프레임워크로 작업하는 것이
00:12:17다소 번거로웠던 적이 있었지만, 이제는 더 이상 그렇지 않습니다. AI를 사용하는 개발자로서
00:12:23사용하려는 어떤 라이브러리의 문서든 찾아갈 수 있습니다. 최신 Nuxt.js나 Svelte 5를 쓰고 싶다면 말이죠.
00:12:30비교적 최근에 나온 TanStack Start 같은 것도 마찬가지입니다. 공식 문서에서 관련 아티클을 골라
00:12:34현재 채팅 세션의 컨텍스트에 넣기만 하면 AI가 그 문서를 인식하게 됩니다.
00:12:44그러면 AI는 그 안의 코드 예시와 설명을 이해하고 여러분의 코드베이스에 적용할 수 있습니다. 즉, 학습 데이터에 없던
00:12:49최신 라이브러리도 프로젝트에 충분히 사용할 수 있다는 뜻입니다. 게다가 요즘은 일일이 문서를
00:12:55찾아서 넣어줄 필요조차 없습니다. 구체적인 프롬프트를 통해 특정 라이브러리를 사용하고 싶으니
00:13:02문서를 찾아보라고 지시하기만 하면 됩니다. Context.7 MCP나 Claude Code 같은 AI 에이전트들은
00:13:12웹 검색 기능이 있습니다. 검색을 통해 관련 문서를 찾을 것이라고 믿고, '스킬' 같은 기능을 활용해 이를 더 구체화할 수도 있죠.
00:13:19저는 코드 리서치 스킬을 가지고 있어서, 특정 프롬프트에 대해 AI가 어떻게 문서를 찾아봐야 하는지
00:13:28기술해 둡니다. 이런 설정이 되어 있다면 직접 문서를 제공할 필요가 없게 됩니다.
00:13:35대신 AI가 스스로 필요에 따라 관련 문서를 찾아보고 포함할 수 있습니다. 그리고 놀랍게도 개발자는 여전히 코드를 직접 쓸 수 있습니다.
00:13:45또한 AI는 프로젝트 내에 이미 존재하는 코드 스타일을 그대로 복제하려는 경향이 있습니다.
00:13:52따라서 프로젝트를 생성하고 이미 몇 개의 함수나 라우트를 만들어 두었다면, 그것이 Nuxt.js든 TanStack Start든
00:13:59AI는 그것을 파악할 것이고, TanStack Start 프로젝트에서 갑자기 Nuxt.js 문법을 사용하지는 않을 것입니다.
00:14:09기존 코드 활용, 적절한 컨텍스트 주입, 문서 검색 유도 등을 종합해 보면,
00:14:20기본 스택이 아니거나 AI에게 잘 알려지지 않은 기술들을 사용하는 것이 요즘은 정말 쉬워졌습니다.
00:14:30이것이 제 경험이고, X(트위터)에서도 다른 사람들의 비슷한 경험담을 많이 읽었습니다.
00:14:41그러니 오늘날에는 절대적으로 가능합니다. 1년 전에는 달랐을지 몰라도 지금은 충분히 실행 가능하죠.
00:14:53이 사실이 다시 원래의 질문으로 저를 이끕니다. "기술 스택 선택이 여전히 중요한가?"
00:15:08강요받지 않고 자유롭게 선택할 수 있다는 것은 멋진 일입니다. 하지만 정말 중요할까요? 저는 여전히 매우 중요하다고 주장합니다.
00:15:20앞서 말씀드렸듯이, 그것이 개발자와 비개발자를 구분 짓는 요소 중 하나이기 때문입니다. 전부는 아니지만요.
00:15:30프로젝트마다 적합한 기술 스택이 다릅니다. 이론적으로는 어떤 스택으로도 무엇이든 만들 수 있고
00:15:40대부분의 경우 상관없을 수도 있지만, 결정적일 때가 있습니다. 성능이 핵심인 프로젝트를 한다면,
00:15:44단순히 10명의 사용자를 위한 성능이 아니라, 정말 성능이 중요한 대규모 프로젝트라면 Go 같은 백엔드 언어를 선호할 수 있습니다.
00:15:56TypeScript를 쓸 때보다 더 나은 성능과 메모리 효율을 원하기 때문이죠. 다만 덧붙이자면,
00:16:04사용자가 몇 명일지도 모르는 상태에서 무턱대고 오버 엔지니어링을 할 필요는 없습니다. 만약 부하 때문에
00:16:16애플리케이션이 멈추는 시점이 온다면, 그때 다시 작성하면 됩니다. AI 덕분에 재작성도 그 어느 때보다 쉬워졌으니까요.
00:16:23하지만 그런 선택들은 분명 여전히 중요합니다. 또한 개발자가 무엇을 알고 있는지도 중요하죠.
00:16:35Angular를 정말 잘한다면 굳이 React 앱을 만들 이유가 없습니다. 개발자로서 여전히 코드를 이해하고