2011년에도 AI가 있었다면, 우리는 지금의 웹을 만날 수 있었을까요?

자, 잠시 타임머신을 타고 2011년으로 돌아가 봅시다. 당시 웹은 대부분 서버에서 렌더링되는 PHP 템플릿으로 이루어져 있었죠. 좀 멋 좀 부린다 싶으면 jQuery를 살짝 얹거나, 아예 자바스크립트가 없는 사이트도 흔했습니다. 사용자 인터랙션은 제한적이었고, 모든 것이 요청-응답 루프 안에서 돌아갔습니다. 복잡한 클라이언트 사이드 앱이라는 개념은 아직 주류와는 거리가 멀었죠. 그래도 뭐, 다들 잘 쓰고 있었고 예측 가능했으며, 솔직히 아무도 크게 걱정하지 않았어요 😄

그런데 이 시점에, 갑자기 우리가 지금 사용하는 수준의 현대 AI가 뚝 떨어진다고 상상해 보세요. 초기 실험 모델이 아니라, 오늘날의 거대 언어 모델(LLM), 코딩 에이전트, 프롬프트만으로 전체 기능을 뚝딱 만들어내는 도구들 말이죠. 코드 생성 AI '코덱스(Codex)'나 '클로드 코드(Claude Code)' 같은 마법 같은 기술들이요. 커피 한 잔 다 마시기도 전에 앱의 절반을 뚝딱 만들어낼 수 있는 그런 도구들입니다 ☕

아, 잠깐, 본론으로 들어가기 전에 이 얘기는 꼭 해야겠습니다. 너무 신나서 말이죠 😄 제가 JSNation 2026에서 강연을 하게 되었어요. 아직도 좀 비현실적으로 느껴집니다. 그야말로 쟁쟁한 자바스크립트 대가들이 모이는 콘퍼런스인데… 거기에 저도 끼게 되었네요 😉

DEV 커뮤니티에 누가 되지는 않을 겁니다 😅 제 발표 주제는 “Rewite or Refactor? How to Safely Move Legacy Apps to Modern Frameworks”인데, 이미 여러 무대에서 검증받은 내용이에요. 궁금하신 분들은 여기서 시청하실 수 있을 겁니다: https://gitnation.com/badges/jsnation-2026/sylwia_laskowska_154511. 프런트엔드 개발자가 아니더라도 제 글을 좋아하셨다면 분명 재미있게 보실 수 있을 거예요. 말 그대로 "말하는 글" 같거든요 😄

아, 그리고 기념으로 무알코올 맥주를 마셨는데, 어찌 된 일인지 다음 날 아침에 엄청난 숙취에 시달린 기분으로 깨어났습니다. 네, 새로운 업적 하나 달성했습니다.

다시 사고 실험으로 돌아가 봅시다. 그럼 그 다음엔 무슨 일이 벌어질까요? 모두가 초능력 비서(AI)를 갖게 되었으니 현대 웹으로 더 빠르게 진입했을까요? 아니면 예상보다 훨씬 덜 흥미로운 세상이 펼쳐졌을까요? AI가 이미 작동하는 방식을 계속 강화해서, 우리가 굳이 더 나아가야 할 필요성을 느끼지 못하게 되는 그런 세상 말이죠.

왜냐하면, 여기서 불편한 질문 하나가 나옵니다. AI가 우리가 생각하는 만큼 혁신을 가속하지 않고… 오히려 조용히 현상을 안정시키는 역할을 한다면 어떨까요? 👀

AI는 '익숙한 영역'에서만 빛난다

제가 AI 전문가는 아니니 척하는 일은 없을 겁니다. LLM을 매일 쓰고, RAG가 뭔지 알고, 추론(inference)이나 행렬 곱셈(matrix multiplication), 샘플링(sampling) 같은 개념도 편안하게 다룰 줄 아는 정도는 됩니다. 하지만 AI가 기술의 속도를 높이는 것을 넘어, 그 방향 자체를 결정할 수도 있다는 생각은 해본 적이 없었어요.

WebAssembly나 WebGPU 작업을 더 많이 시작하면서 이런 생각이 바뀌기 시작했습니다. 그리고 한 가지 사실이 빠르게 명확해졌죠.

LLM은 Rust나 일반적인 프런트엔드 작업, 전형적인 패턴들처럼 기존 예시가 많은 분야에서는 엄청나게 뛰어납니다. 이미지를 다운로드하는 간단한 기능을 요청하면, 거의 즉시 깔끔하고 관용적인 코드를 뚝딱 내어줍니다. 솔직히 반칙하는 기분마저 들어요 😄

하지만 WebGPU나 WGSL 셰이더 같은 새로운 영역으로 발을 들이는 순간, AI의 성능은 급격히 떨어지기 시작합니다. 잦은 오류가 발생하고, 잘못된 가정을 하거나, API들을 마구 섞어버리죠. 결국 AI 결과물을 믿지 못하게 되고, 2010년처럼 직접 모든 것을 코딩하고 디버깅하는 옛날 방식으로 돌아가게 됩니다.

이것은 AI가 "나빠서"가 아닙니다. 단순히 충분한 데이터를 학습하지 못했기 때문이에요. WGSL은 대략 2021년부터 존재했으니, 수십 년에 걸친 웹 개발 패턴에 비하면 그저 아무것도 아닌 수준이죠. 제가 실무에서 WebGPU 프로젝트를 진행하면서 LLM에 코드를 물어봤을 때, 일반적인 React 컴포넌트나 TypeScript 유틸리티는 척척 내어주던 AI가 WebGPU 셰이더나 WASM 바인딩 쪽에서는 엉뚱한 답을 내놓거나 구시대적인 패턴을 제안하는 걸 보면서 이 글의 핵심 아이디어에 깊이 공감할 수밖에 없었습니다.

AI는 '현존하는 것'에 최적화한다

여기서 관점이 조금 뒤집힙니다. 우리는 AI가 더 나은 코드를 작성하고 더 현명한 결정을 내리도록 돕는다고 생각하기 쉽죠. 하지만 실제로는 가장 흔하고, 가장 많이 표현되고, 데이터로 가장 많이 강화된 방향으로 우리를 이끕니다.

AI는 시니어 개발자처럼 생각하지 않습니다. 트레이드오프나 장기적인 영향을 평가하지도 않아요. 그저 패턴을 매칭할 뿐입니다.

그래서 AI가 프런트엔드에서 흔히 React를 기본으로 제안하는 이유도 여기에 있습니다. React가 항상 최선의 선택이라서는 아니죠. 그냥 어디에나 존재하기 때문입니다. 어떤 경우에는 Angular나 Vue가 더 적합할 수도 있지만, AI는 그런 "선호"를 가지고 있지 않습니다. 단순히 그만큼 많이 보지 못했을 뿐이죠.

경험 많은 개발자라면 이런 함정을 알아채고 조정하겠지만, 피곤하거나, 압박에 시달리거나, 그냥 빨리 일을 끝내고 싶을 때(즉, 대부분의 우리가 대부분의 시간에 겪는 상황이죠 😅)는 AI가 내놓은 대로 따르게 됩니다. 작동하고, 컴파일되니, 그냥 출시해 버리는 겁니다.

바로 이것이 미묘한 변화입니다. AI는 단순히 코딩을 돕는 것을 넘어, 우리가 코딩하는 방식 자체에 조용히 영향을 미치고 있습니다.

탐험에서 편리함으로

AI가 등장하기 전에는 웹 개발이 편안함과는 거리가 멀었습니다. 거의 고통에 가까웠죠 😄

PHP 템플릿은 잘 작동했지만, 뭔가 부족했습니다. 우리는 인터랙티브한 웹을 원했고, 그래서 자바스크립트를 가지고 씨름하기 시작했죠. 그 혼란을 관리하기 위해 jQuery가 등장했습니다. 그러다 클라이언트 측에서 상태를 관리하는 것이 필수 불가결해지면서 SPA(Single Page Application)가 대세가 되었습니다. 프레임워크가 진화하고, 패턴이 진화하고, 모든 것이 계속 앞으로 나아갔어요.

항상 마찰이 있었습니다. 그리고 그 마찰은 사람들이 생각하고, 실험하며, 때로는 아직 주류가 아닌 것들을 시도하게 만들었죠.

이제 그 마찰 대부분을 제거했다고 상상해 보세요. 깊이 파고들 필요 없이 거의 즉시 작동하는 솔루션을 얻을 수 있습니다. 그렇게 되면 미묘한 변화가 발생합니다. 더 이상 **"이것이 최선의 방법인가?"**라고 묻지 않고, **"이것이 이미 작동하는가?"**라고 묻기 시작하죠.

그리고 한 번 이런 사고방식이 자리 잡으면, 탐험은 서서히 사라지기 시작합니다.

인지적 구두쇠와 AI의 만남

여기에는 매우 인간적인 요소도 있습니다. 우리는 심리학자들이 "인지적 구두쇠(cognitive misers)"라고 부르는 존재입니다. 기본적으로 불필요한 생각을 가능한 한 피하려 하죠. 더 쉬운 길이 있다면, 우리는 그 길을 택합니다.

AI는 궁극적인 쉬운 길입니다. 바로 그래서 AI가 강력한 이유이기도 하죠 😄

하지만 동시에 피드백 루프를 만듭니다. AI가 흔한 솔루션을 제안하고, 개발자는 그것을 구현하며, 그 솔루션은 더욱 흔해지고, AI는 다시 그것을 제안하는 데 더욱 확신을 갖게 되는 거죠.

그 루프를 깨고 나오려면 노력이 필요합니다. 그리고 노력은 애초에 AI를 사용하는 이유가 아닐까요? 우리는 노력을 줄이고 싶어 합니다.

2011년으로 돌아가서

자, 다시 원래 시나리오로 돌아가 봅시다. 당신은 2011년의 개발자이고, 웹 앱을 만들고 있습니다. 그 시점에 존재했던 모든 것, 즉 PHP 템플릿, 초창기 자바스크립트, 서버 사이드 렌더링 패턴에 대해 학습된 강력한 AI 비서에 접근할 수 있습니다.

당신이 AI에게 어떤 기능을 만드는 방법을 물어보면, AI는 깔끔하고 작동하는 PHP 코드를 제공합니다. 빠르고, 익숙하며, 당신의 문제를 해결해 주죠.

과연 당신은 클라이언트 사이드 앱 같은 완전히 새로운 패러다임을 추진했을까요? 현재 방식이 이미 작동하고 도구들이 완벽하게 지원하는 상황에서, 아직 존재하지 않는 무언가를 실험했을까요?

아니면 그냥… 출시했을까요? 😄

만약 충분한 사람들이 그저 "출시"하는 길을 택한다면, 흥미로운 일이 일어납니다. 극적인 붕괴는 아닐 겁니다. 그저 조용한 정체 상태가 되겠죠.

그리고 갑자기, 미래는 우리가 만들 수 있었던 것만큼 빠르게 구축되지 못했을 겁니다.

진짜 위험

저는 AI가 개발자를 대체할 것이라고 생각하지 않습니다. 그건 너무 뻔한 논의이고, 솔직히 덜 흥미로운 부분이죠.

더 흥미로운 가능성은 AI가 우리가 이미 가고 있는 방향으로 계속 나아가는 것을 엄청나게 효율적으로 만든다는 것입니다. 그 방향이 틀렸기 때문이 아니라, 과거에 의해 형성되고 과거에 최적화되어 있기 때문입니다.

만약 우리가 조심하지 않는다면, 우리의 도구, 워크플로우, 심지어 의사 결정까지 아직 존재하지 않는 것을 향해 나아가기보다는, 이미 존재하는 것에 맞춰 모든 것을 최적화하기 시작할지도 모릅니다.

또 다른 관점

한편으로는… 혁신의 속도는 미친 듯이 빨라지고 있습니다. 새로운 아이디어는 그 어느 때보다 빠르게 움직이죠. 예전에는 수년이 걸리던 일이 이제는 몇 달 만에 일어납니다.

하지만 혁신은 언제나 비교적 소수의 그룹, 즉 새로운 도구를 탐색하고 한계를 밀어붙이는 사람들에 의해 주도되어 왔습니다.

나머지 우리는요?

우리는 매일 앉아서 이미 존재하는 것을 가지고 작업합니다. 안정적이고, 지원되며, 문서화가 잘 되어 있는 것들이죠. AI가 아주 잘 이해하는 종류의 스택 말입니다.

그러니 네, 혁신은 빨라지고 있습니다. 하지만 동시에 AI는 다른 모든 사람이 지금 있는 곳에 머무르기가 그 어느 때보다 쉬워지도록 만들고 있을지도 모릅니다.

그래서 제가 틀렸기를 바랍니다.

정말 궁금하네요. 여러분은 어떻게 생각하세요?

만약 2011년에 AI가 있었다면, 우리는 지금의 현대 웹을 더 빨리 만들었을까요… 아니면 여전히 index.php에서 편안하게 앉아 있었을까요? 😄

여기까지 읽어주셨다면, LinkedIn에서 좋아요나 팔로우를 한 번 고려해 보세요 🙂

솔직히 저는 LinkedIn을 잘 다루는 편은 아닙니다 😄 거기서 제 글의 도달률이 엄청나진 않거든요 (보통 그냥 제 글 링크를 올리는데, 늦을 때도 많고요 xD). 하지만 거기서 좀 더 짧은 형식의 콘텐츠를 만들어 볼 아이디어가 떠오른 것 같습니다…

원문: https://dev.to/sylwia-lask/if-ai-existed-in-2011-would-we-still-have-the-modern-web-408g 수집일: 2026-04-26 01:23:27