2011년, AI가 존재했다면? 모던 웹은 '지연'되었을지도 모른다.

상상해 보세요. 2011년입니다. 당시 웹은 대부분 서버에서 렌더링되는 PHP 템플릿 기반이었고, 좀 멋을 부린다 싶으면 jQuery를 약간 섞는 정도였죠. 심지어 JavaScript가 전혀 없는 경우도 흔했습니다. 상호작용은 매우 제한적이었고, 모든 것이 요청-응답 루프 안에서 돌아갔어요. 지금처럼 복잡한 클라이언트 사이드 앱이라는 개념은 아직 주류와 거리가 멀었죠. 모든 게 잘 작동했고, 예측 가능했으며, 솔직히… 아무도 패닉하지 않았습니다. 😄

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

잠깐, 본론으로 들어가기 전에 너무 신나서 이 이야기를 빼먹을 수가 없네요. 😄 제가 JSNation 2026에서 발표를 하게 됐습니다! 아직도 좀 비현실적으로 느껴져요. 정말 유명한 자바스크립트 거장들이 총출동하는 컨퍼런스인데, 거기에 저도 끼게 됐네요 😉

하지만 걱정 마세요. 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)이나 행렬 곱셈(matrix multiplication), 샘플링(sampling)에 대해서도 편안하게 다룰 만큼은 이해하고 있습니다. 하지만 AI가 기술의 속도뿐 아니라 그 방향 자체를 형성한다는 관점에서 깊이 생각해 본 적은 없었습니다.

이런 생각이 바뀌기 시작한 건 WebAssembly와 WebGPU 작업을 더 많이 하면서부터입니다. 그리고 한 가지 사실이 꽤 빠르게 분명해졌죠.

LLM은 Rust나 일반적인 프런트엔드 작업, 전형적인 패턴 등 기존 예시가 많은 분야에서는 엄청나게 뛰어난 성능을 보여줍니다. 예를 들어 이미지 다운로드 같은 간단한 기능을 요청하면, 깔끔하고 관용적인 코드를 거의 즉시 받아볼 수 있죠. 솔직히 반칙하는 기분까지 듭니다. 😄

하지만 WebGPU나 WGSL 셰이더처럼 새로운 영역으로 발을 들이는 순간, 상황은 완전히 달라집니다. 잦은 오류가 발생하고, 잘못된 가정을 하며, API를 엉뚱하게 조합하는 일도 비일비재하죠. 결국 출력 결과에 대한 신뢰를 잃고, 마치 2010년으로 돌아간 듯 모든 것을 직접 코딩하고 디버깅하게 됩니다. 제가 실무에서 WebGPU 프로젝트를 진행하며 LLM의 도움을 받으려 했을 때, 익숙한 웹 컴포넌트 생성은 거침없이 해냈지만, WGSL 셰이더 코드에서는 기본적인 문법 오류부터 로직 오류까지 쉴 새 없이 발생해서 결국은 제가 직접 다시 짜는 게 훨씬 빠르다는 걸 깨달았습니다.

그렇다고 AI가 '나쁘다'는 건 아닙니다. 단순히 충분한 데이터를 보지 못했을 뿐이죠. WGSL은 대략 2021년부터 존재하기 시작했습니다. 수십 년 역사의 웹 개발 패턴과 비교하면 거의 아무것도 없는 수준이죠.

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

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

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

이것이 AI가 프런트엔드에서 종종 React를 기본으로 추천하는 이유입니다. 항상 최선의 선택이기 때문이 아니라, React가 도처에 깔려 있기 때문이죠. 어떤 경우에는 Angular나 Vue가 더 적합할 수 있지만, AI는 이들을 '선호'하지 않습니다. 그저 그만큼 많이 보지 못했을 뿐이죠.

경험이 많은 개발자라면 이런 함정을 알아채고 조정하겠지만, 피곤하거나, 압박을 받거나, 그저 빨리 일을 끝내고 싶을 때(즉, 우리 대부분이 대부분의 시간을 보내는 방식이죠 😅), AI가 주는 대로 따르게 됩니다. 작동하고, 컴파일되고, 배포하면 끝이죠.

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

탐색에서 편의로

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

PHP 템플릿은 작동했지만, 어느 순간 한계에 부딪혔습니다. 우리는 상호작용이 필요했고, 그래서 JavaScript로 뭔가 해킹하기 시작했죠. 그러자 혼란을 관리하기 위해 jQuery가 나타났습니다. 그리고 클라이언트에서 상태를 관리하는 것이 불가피해지면서 SPA(Single Page Application)의 시대가 열렸죠. 프레임워크가 진화하고, 패턴이 진화하며, 모든 것이 끊임없이 앞으로 나아갔습니다.

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

이제 그 마찰의 대부분이 사라진다고 상상해 보세요. 깊이 파고들 필요 없이, 거의 즉시 작동하는 해결책을 얻을 수 있습니다. 이런 일이 벌어지면 미묘한 변화가 찾아옵니다. 더 이상 **"이것이 최선의 방법인가?"**라고 묻지 않고, **"이것이 이미 작동하는가?"**라고 묻기 시작하죠.

그리고 이런 사고방식이 자리 잡으면, 탐색이라는 행위는 서서히 사라지게 됩니다.

인지적 구두쇠와 AI의 만남

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

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

하지만 이것은 또한 피드백 루프를 만듭니다. AI는 일반적인 솔루션을 제안하고, 개발자는 그것을 구현하며, 그 솔루션은 더욱 일반적이 되고, AI는 다시 그것을 제안하는 데 더욱 확신을 가집니다.

이런 루프에서 벗어나려면 노력이 필요합니다. 그런데 AI를 사용하는 가장 큰 이유가 바로 '노력을 피하기' 위함이 아니던가요?

2011년으로 돌아가다

자, 다시 원래 시나리오로 돌아가 봅시다. 2011년의 개발자입니다. 웹 앱을 만들고 있죠. 당시 존재했던 모든 것에 대해 학습된 강력한 AI 비서가 당신에게 있습니다. PHP 템플릿, 초기 JavaScript, 서버 사이드 렌더링 패턴 등 말이죠.

어떤 기능을 만들지 물으면, AI는 깔끔하고 작동하는 PHP 솔루션을 제공합니다. 빠르고, 익숙하며, 문제를 해결해 줍니다.

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

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

만약 충분한 사람들이 그저 '배포'를 선택한다면, 흥미로운 일이 벌어집니다. 극적인 붕괴는 아닙니다. 그저 조용한 정체죠.

그리고 갑자기, 미래는 만들어질 수 있었던 만큼 빠르게 만들어지지 않게 됩니다.

진짜 위험

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

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

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

다른 관점

한편으로는… 혁신에 있어서는 미친 듯이 속도가 붙고 있습니다. 새로운 아이디어는 그 어느 때보다 빠르게 움직이고 있죠. 과거에는 몇 년이 걸리던 일이 이제는 몇 달 만에 일어납니다.

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

나머지 우리들은요?

우리는 매일 앉아서 이미 존재하는 것들, 즉 안정적이고, 지원되며, 잘 문서화된 것들과 함께 일합니다. AI가 아주 잘 이해하는 종류의 스택 말이죠.

그러니 네, 혁신은 가속화되고 있습니다. 하지만 동시에 AI는 다른 모든 사람들이 그 자리에 머무는 것을 그 어느 때보다 쉽게 만들고 있을지도 모릅니다.

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

이제 정말 궁금하네요. 여러분은 어떻게 생각하시나요?

만약 AI가 2011년에 존재했다면, 우리는 모던 웹을 더 빨리 만들었을까요… 아니면 여전히 index.php에서 편안하게 지내고 있었을까요? 😄

여기까지 읽어주셨다면, 링크드인에서 좋아요나 팔로우를 눌러주시는 건 어떠세요? 🙂

고백하자면, 제가 링크드인 마스터는 절대 아닙니다. 😄 거기서 제 게시물의 도달 범위가 아주 좋지는 않아요(보통 제 글 링크를 올리는데, 그것도 늦게 올릴 때가 많죠 xD). 하지만 거기서 좀 더 짧은 형식의 콘텐츠에 대한 아이디어가 떠오른 것 같기도 합니다…

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