AI가 2011년에 있었다면? 현대 웹은 예정된 수순이었을까, 아니면 다른 모습이었을까?

2011년으로 잠시 돌아가 봅시다. 당시 웹은 대부분 서버에서 렌더링되는 PHP 템플릿 기반이었죠. 가끔 멋을 좀 부린다면 jQuery를 살짝 얹는 정도였고, 아예 자바스크립트가 없는 웹사이트도 흔했습니다. 사용자 인터랙션은 제한적이었고, 모든 것이 요청-응답 루프 안에서 돌아가는 단순한 구조였어요. 복잡한 클라이언트 사이드 앱이라는 개념은 아직 주류가 아니었고요. 그 시절 웹은 잘 작동했고, 예측 가능했으며, 솔직히 말해… 그 누구도 패닉에 빠지지 않았습니다 😄

그런데 바로 그 시절, 이 세상에 갑자기 현대 AI가 등장했다고 상상해 보세요. 초기 실험 모델이 아니라, 오늘날 우리가 쓰는 것과 거의 흡사한 수준의 AI 말입니다. 거대 언어 모델(LLM), 코딩 에이전트, 심지어 프롬프트만으로 전체 기능을 뚝딱 만들어내는 도구들까지요. 코덱스(Codex)나 클로드 코드(Claude Code) 같은 마법 같은 도구들이 커피 한 잔 다 마시기도 전에 앱의 절반을 뚝딱 만들어낼 수 있는 세상이 온 겁니다 ☕

(잠깐, 본론으로 들어가기 전에 이 얘기는 꼭 해야겠습니다 😄 2026년 JSNation에서 강연을 하게 되었어요. 아직도 좀 비현실적으로 느껴지네요. 정말 내로라하는 자바스크립트 대가들이 모두 모이는 컨퍼런스인데… 거기에 저도 낀다니, 묘한 기분입니다 😉)

그래도 걱정 마세요. DEV 커뮤니티에 먹칠하는 일은 없을 겁니다 😅 제가 준비한 강연은 "Rewrite or Refactor? How to Safely Move Legacy Apps to Modern Frameworks"라는 주제인데, 이미 여러 무대에서 검증을 마쳤습니다. 궁금하시다면 이곳에서 다시 보실 수 있을 거예요: https://gitnation.com/badges/jsnation-2026/sylwia_laskowska_154511. 프런트엔드 개발자가 아니더라도 제 글을 좋아하셨다면 아마 즐겁게 보실 수 있을 겁니다. 말 그대로 "말하는 블로그 글" 같은 느낌이거든요 😄

참, 강연 기념으로 무알코올 맥주를 마셨는데, 어찌 된 일인지 다음 날 엄청난 숙취에 시달린 기분으로 깨어났지 뭐예요? 네, 새로운 업적 하나 추가했습니다.

자, 다시 사고 실험으로 돌아와 봅시다. 과연 그 다음엔 무슨 일이 벌어질까요? 모두가 초능력 조수를 얻게 되었으니 현대 웹으로의 전환이 더 빨라졌을까요? 아니면 훨씬 덜 흥미로운 세상, 즉 AI가 '이미 잘 작동하는 것'만을 계속해서 강화하고, 우리는 그 너머로 나아갈 필요성을 전혀 느끼지 못하는 세상이 되었을까요?

이 질문은 좀 불편할 수도 있습니다. AI가 우리가 생각하는 것만큼 발전을 가속화하는 것이 아니라… 오히려 조용히 현 상태를 '안정화'시키는 역할을 할 수도 있다면요? 👀

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

저는 AI 전문가는 아니고, 그런 척할 생각도 없습니다. LLM을 매일 쓰고 있고, RAG가 뭔지, 추론(inference), 행렬 곱셈, 샘플링 같은 기본적인 개념은 편안하게 작업할 수 있을 정도로 이해하고 있습니다. 하지만 AI가 단순히 기술의 속도를 높이는 것을 넘어, 기술의 '방향' 자체를 형성할 수 있다는 생각은 해본 적이 없었어요.

그런데 WebAssembly와 WebGPU 작업을 더 깊이 하면서 생각이 바뀌기 시작했습니다. 그리고 아주 빠르게 명확해진 사실이 하나 있었죠.

LLM은 Rust, 일반적인 프런트엔드 작업, 전형적인 패턴 등 기존 사례가 풍부한 모든 것에 대해서는 엄청나게 뛰어난 성능을 보여줍니다. 이미지를 다운로드하는 간단한 기능을 요청하면, 깨끗하고 관용적인 코드를 거의 즉시 받아볼 수 있어요. 솔직히 말하면 반칙하는 기분마저 들 정도입니다 😄

하지만 WebGPU나 WGSL 쉐이더 같은 새로운 영역으로 들어가면 이야기는 달라집니다. 잦은 오류가 발생하고, 잘못된 가정을 하거나, API가 뒤죽박죽 섞이기도 합니다. 결국 AI의 결과물을 신뢰하지 못하고, 마치 2010년으로 돌아간 것처럼 모든 것을 직접 코딩하고 디버깅하게 되죠.

이것은 AI가 '나쁘다'는 의미가 아닙니다. 단지 아직 충분한 데이터를 학습하지 못했을 뿐이죠. WGSL은 대략 2021년경부터 사용되기 시작했습니다. 수십 년 역사의 웹 개발 패턴과 비교하면 거의 아무것도 아닌 수준이죠.

제가 실무에서 새로운 WebGL 라이브러리를 도입하면서 느낀 건데, 초기 프로토타이핑 단계에서는 ChatGPT가 기본적인 보일러플레이트 코드를 짜주는 데 정말 유용했지만, 커스텀 쉐이더나 특정 최적화 로직으로 들어가니 결국 제가 직접 공식 문서를 파고들고 삽질해야만 했습니다. 결국 AI는 잘 닦인 길에서 가장 빛을 발하는 것 같더군요.

AI는 '기존의 것'에 최적화한다

이 지점에서 전체 논의의 방향이 조금 달라집니다. 우리는 AI가 더 나은 코드를 작성하고 더 현명한 결정을 내리도록 돕는다고 생각하기 쉽습니다. 하지만 실제로는 가장 일반적이고, 가장 많이 나타나고, 데이터에 의해 가장 많이 강화된 방향으로 우리를 안내할 뿐입니다.

AI는 시니어 엔지니어처럼 생각하지 않습니다. 트레이드오프나 장기적인 결과를 평가하지도 않아요. 그저 패턴 매칭을 할 뿐이죠.

그래서 프런트엔드 개발에서 종종 리액트(React)를 기본으로 추천하는 것입니다. 항상 최고의 선택이라서가 아니라, 리액트가 어디에나 있기 때문이죠. 어떤 경우에는 앵귤러(Angular)나 뷰(Vue)가 더 적합할 수도 있지만, AI는 특정 프레임워크를 '선호'하지 않습니다. 단지 덜 접했을 뿐인 거죠.

경험이 많은 개발자라면 이런 점을 알아차리고 조정할 수 있습니다. 하지만 피곤하거나, 압박에 시달리거나, 그저 빨리 일을 끝내고 싶을 때(즉, 대부분의 개발자가 대부분의 시간 동안 겪는 상황 😅)는 AI가 주는 대로 따르게 됩니다. 그냥 작동하고, 컴파일되니, 배포하는 거죠.

그리고 여기에 미묘한 변화가 숨어 있습니다. AI는 단순히 코딩을 돕는 것을 넘어, 우리가 코드를 짜는 방식 자체에 조용히 영향을 미치고 있습니다.

탐험에서 편의로

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

PHP 템플릿은 작동했지만, 한계에 부딪혔습니다. 우리는 더 많은 인터랙티브 기능이 필요했고, 그래서 자바스크립트로 이런저런 시도를 하기 시작했죠. 그러다 혼란을 관리하기 위해 jQuery가 나타났고, 클라이언트에서 상태 관리가 불가피해지면서 SPA(Single Page Application)가 등장했습니다. 프레임워크가 진화하고, 패턴이 진화하며, 모든 것이 끊임없이 앞으로 나아갔습니다.

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

이제 그런 마찰의 대부분이 사라졌다고 상상해 보세요. 깊이 파고들 필요 없이 거의 즉시 작동하는 솔루션을 얻을 수 있다면요. 이런 일이 벌어지면 미묘한 변화가 일어납니다. 더 이상 **"이게 최선의 방법일까?"**라고 묻지 않고, **"이게 이미 작동하고 있는가?"**라고 묻게 되는 거죠.

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

인지적 구두쇠(Cognitive Miser)와 AI의 만남

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

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

하지만 이는 일종의 피드백 루프를 만듭니다. AI가 일반적인 해결책을 제안하고, 개발자들은 그것을 구현하고, 그 해결책은 더욱 일반적이 되고, AI는 다시 그것을 제안하는 데 더욱 확신을 갖게 됩니다.

이 루프에서 벗어나려면 노력이 필요합니다. 그런데 바로 그 '노력'이야말로 우리가 AI를 사용하는 주된 이유, 즉 피하고 싶은 대상이 아닌가요?

2011년으로 돌아가서

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

어떤 기능을 만드는 방법을 물었을 때, AI는 PHP로 깨끗하고 작동하는 솔루션을 제시합니다. 빠르고, 익숙하며, 문제도 해결해 줍니다.

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

아니면 그냥… 배포했을까요? 😄

만약 충분히 많은 사람들이 그저 배포하는 길을 선택한다면, 흥미로운 일이 벌어집니다. 극적인 붕괴가 아니라, 그저 조용한 정체가 찾아오는 거죠.

그리고 갑자기, 미래는 가능했을 만큼 빠르게 구축되지 못했을 수도 있습니다.

진짜 위험은 무엇인가

저는 AI가 개발자를 대체할 것이라고 생각하지 않습니다. 그것은 너무나도 명백하고, 솔직히 말해 덜 흥미로운 논의입니다.

더 흥미로운 가능성은 AI가 우리가 이미 가고 있는 방향으로 계속 나아가는 데에는 엄청나게 효율적으로 만들어줄 수 있다는 점입니다. 잘못된 방향이라서가 아니라, 과거에 의해 형성되고 그것을 중심으로 최적화되어 있기 때문이죠.

그리고 만약 우리가 조심하지 않는다면, 우리의 도구, 워크플로우, 심지어 우리의 결정까지 모든 것을 '아직 존재하지 않는 것'을 향해 나아가기보다 '이미 존재하는 것'을 중심으로 최적화하기 시작할 수도 있습니다.

최근 저희 팀에서도 새로운 아키텍처를 도입할 때, AI의 제안이 기존 방식과 너무 유사해서 오히려 더 나은 대안을 찾아내는 데 시간이 더 걸렸던 경험이 있습니다. 결국 '익숙한 것'에 갇히는 건 기술 발전의 큰 걸림돌이 될 수 있다는 걸 새삼 깨달았죠. 혁신은 익숙한 길을 벗어날 때 시작되니까요.

다른 시각

한편으로는, 혁신이라는 측면에서 보면 상황은 미친 듯이 가속화되고 있습니다. 새로운 아이디어는 그 어느 때보다 빠르게 움직이고 있죠. 과거에 수년이 걸리던 일이 이제는 몇 달 만에 일어납니다.

하지만 혁신은 항상 소수의 그룹, 즉 새로운 도구를 탐색하고 한계를 뛰어넘는 사람들에 의해 주도되어 왔습니다.

그 외 우리 대부분은 어떤가요?

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

그러니 맞습니다. 혁신은 속도를 내고 있습니다. 하지만 동시에 AI는 다른 모든 사람들이 '현재 있는 곳'에 머무르는 것을 그 어느 때보다 쉽게 만들고 있을지도 모릅니다.

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

이제 정말 궁금해졌습니다. 여러분은 어떻게 생각하시나요?

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

이 글을 끝까지 읽어주셨다면, LinkedIn에서 좋아요나 팔로우를 한번 고려해 주세요 🙂

솔직히 말하면, 저는 링크드인 마스터는 절대 아닙니다 😄 제 게시물의 도달률이 엄청나진 않아요 (보통 제 글 링크를 올리는데, 그것도 늦게 올릴 때가 많습니다 xD). 그래도 조만간 링크드인에서 좀 더 짧은 형식의 콘텐츠를 만들어 볼까 하는 아이디어가 생겼네요…

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