AI가 프론트엔드의 잃어버린 10년을 반복하게 만들고 있는가?

Mauro Bieg, 2026년 5월 23일

AI가 프로그래머의 일자리에 미치고 있는 영향은 많은 프론트엔드 (Frontend) 개발자들에게 매우 익숙하게 느껴집니다. 왜냐하면 우리에게 이미 전에 일어났던 일이기 때문입니다.

먼저 기술 저하 (deskilling) 의 관점에서 프론트엔드와 에이전트 기반 코딩 (agentic coding)의 변화를 살펴보고, 그다음 더 높은 수준의 추상화 (a higher level of abstraction) 의 관점에서 두 변화를 살펴보겠습니다. 마지막으로, Stack Overflow로부터의 복사-붙여넣기 (copy-pasta)의 등장과 같은 이전의 변화들, 그리고 바우하우스 (Bauhaus) 운동이 고조되는 산업화에 어떻게 대응했는지 살펴보겠습니다.

기술 저하 (Deskilling)

현재 AI가 프로그래밍의 기술을 저하시키고 있는 것처럼, JavaScript 프레임워크들은 지난 10년 동안 프론트엔드 개발의 기술을 저하시켜 왔습니다. HTML/CSS와 약간의 PHP로 시작하여, 이후 Ruby on Rails를 거쳐 스위스의 주요 신문사의 프론트엔드 팀 리드(당시 Next.js 사용)를 맡았던 사람으로서, 저는 이러한 변화를 직접 목격해 왔습니다. 제 말만 믿으실 필요는 없습니다! 제가 처음으로 이렇게 말하는 것도 아니니까요. Alex Russell은 이를 '프론트엔드의 잃어버린 10년 (Frontend's Lost Decade)'이라고 불렀습니다.

기술 저하 (Deskilling)란 무엇일까요? 위키피디아(Wikipedia)에 따르면 다음과 같습니다:

기술 저하란 산업이나 경제 내의 숙련된 노동이 반숙련 또는 미숙련 노동자에 의해 운영되는 기술의 도입으로 인해 제거되는 과정을 말합니다. 이는 비용 절감 [...]을 초래하고 진입 장벽을 낮추어, [노동자]의 협상력을 약화시킵니다.

이것이 프론트엔드에 어떻게 적용되는지, 그리고 에이전트 기반 코딩 (agentic coding)에는 어떻게 적용되는지 살펴보겠습니다.

프론트엔드의 기술 저하

많은 프로그래머가 모르고 있을 수도 있지만, 프론트엔드는 과거에 매우 전문화된 기술이었습니다. 시맨틱 HTML (semantic HTML), CSS, 다양한 브라우저 간의 차이점, 접근성 (accessibility), 점진적 향상 (progressive enhancement), 네트워크 성능 (network performance)

*프론트엔드의 탈숙련화 (deskilling of the frontend)*는 브라우저를 다른 앱 런타임(예: JVM 또는 iOS)과 마찬가지로 단순한 컴파일 대상 (compilation target)으로 취급하는 프레임워크 및 기타 도구들의 도입이었습니다. 그렇게 되면 Shadcn 라디오 버튼과 같은 괴물 같은 결과물을 그냥 불러오기만 하면 되며, 그 밑바탕에 깔린 HTML, 다양한 브라우저와 관련된 미묘한 차이점, 페이지 로드 성능 (page load performance), 그리고 접근성 (accessibility)을 이해할 필요가 없게 됩니다.

위의 Wikipedia 인용구에서 지적하듯이, 이는 기업 입장에서 "비용 절감 (cost savings)"을 가져옵니다. 왜냐하면 이제 어떤 일반적인 프로그래머라도 프론트엔드 업무에 쉽게 투입할 수 있기 때문입니다. 불행하게도 종종 "풀스택 개발자 (full-stack developer)"는 프론트엔드와 백엔드를 모두 깊이 이해하는 사람이 아니라, 단지 JavaScript 프레임워크를 다루어 두 가지를 모두 수행할 수 있을 만큼만 아는 제너럴리스트 (generalist)를 의미하곤 합니다. 이를 통해 기업은 서로 다른 프로젝트 간에 프로그래머를 쉽게 교체할 수 있습니다. 동일한 제너럴리스트가 React Native와 Electron을 사용하여 네이티브 앱까지 만들 수도 있습니다! Wikipedia 인용구를 마무리하자면, 이는 "진입 장벽을 낮추지만 (reduces barriers to entry)"(이는 제가 항상 소중히 여겨온 부분입니다), 동시에 "노동자의 협상력을 약화시킵니다 (weakens the bargaining power of workers)".

AI는 프로그래밍을 탈숙련화하고 있다

현재 프로그래머들에게 전반적으로 일어나고 있는 일은 특히 웹 개발자들이 이미 겪어온 일과 매우 유사해 보입니다. 코드를 수동으로 작성하는 숙련된 작업은 "반숙련 또는 미숙련 노동자에 의해 운영되는 기술의 도입으로 인해 제거"되고 있습니다.

우리는 이러한 변화의 끝에서 에이전틱 AI (agentic AI)를 다루는 노동자들이 정확히 어떤 기술 스택 (skillset)을 갖추어야 할지, 그리고 노동력과 로컬 및 원격 LLM 모두에 대해 어느 정도의 가격대에 도달하게 될지 아직 정확히 알지 못합니다. 하지만 기업들이 비용 절감과 노동자의 협상력 약화를 위해 반드시 이 기술을 사용할 것이라는 점은 이제 분명합니다.

깊은 상실감

한 세기 전 조립 라인 노동자들에 의해 대체되었던 장인과 숙련공들처럼, 우리도 깊은 상실감을 느낍니다. 우리는 인생의 절반을 바쳐 연마해 온 기술이 더 이상 시장에서 가치를 인정받지 못한다는 사실에 슬퍼합니다. 또한 새로운 프로세스가 더 낮은 품질의 결과물을 만들어내고, 많은 이들이 이를 전혀 개의치 않는 것 같아 마음이 아픕니다.

더 높은 추상화 수준에서의 작동

"탈숙련화 (deskilling)"를 바라보는 또 다른 관점은, 이것이 단지 자동화를 통해 효율성을 높이는 과정이라고 주장하는 것입니다. 자동화를 좋아하지 않는 엔지니어가 어디 있겠습니까? 결국 그것은 우리 업무의 큰 부분을 차지하니까요!

이러한 프레임워크 안에서, 새로 도입된 기술은 단순히 더 높은 추상화 (abstraction) 수준에서 작동하며, 이를 사용하는 사람이 중요하지 않은 세부 사항에 신경 쓰지 않고 더 큰 그림에 집중할 수 있게 해줍니다. 하지만 어떤 세부 사항이 "중요하지 않은 것"으로 간주될 것인가는 매우 중대한, 때로는 주관적인 결정입니다. 그리고 결국, 그 세부 사항들은 언제나 새어 나오기 마련입니다.

"현대적" 프론트엔드: 누수되는 추상화의 탑

추상화가 성능(performance)의 희생을 대가로 이루어지는 것은 흔한 일입니다. 하지만 오늘날의 컴퓨터는 매우 빠르기 때문에, 우리는 개발자 생산성을 높이기 위해 어느 정도의 런타임 성능을 기꺼이 포기하곤 했습니다 (가비지 컬렉션 (garbage collection)이 그 한 예입니다). 적절한 부하를 받는 고성능 서버의 경우, 이는 매우 합리적인 트레이드오프 (tradeoff)입니다. 하지만 느린 네트워크 환경의 모바일 기기는 이야기가 다릅니다.

React와 같은 무거운 클라이언트 사이드 JavaScript 프레임워크와 그 생태계의 수많은 패키지들을 사용함으로써, 당신은 접근성 (accessibility), 저사양 폰에서의 성능, 또는 느린 네트워크에서의 성능과 같은 요소들을 추상화하고 있습니다. 사실상, 당신은 그러한 것들에 대해 생각하지 않기로 선택한 것이며, 그것들을 신경 쓰지 않기로 선택한 것입니다.

에이전틱 코딩 (Agentic coding): 비결정론적 추상화

에이전틱 AI (Agentic AI)를 사용하여 기능을 코딩하거나 버그를 수정할 때, 여러분은 더 높은 수준의 추상화 (Abstraction) 단계에서 변경 사항을 설명하게 되며, 모든 코드를 직접 손으로 작성할 때보다 더 적은 단어를 쓰게 됩니다. AI는 학습 데이터와 주변 문맥 (Context)을 살펴봄으로써 여러분이 생략한 세부 사항을 채워 넣을 것입니다. 때로는 잘 추측하기도 하지만, 때로는 그렇지 못하기도 합니다. 이것이 유용하다고 느낄지 여부는 코딩할 때 무엇이 중요한지에 대한 여러분의 관점에 크게 좌우됩니다.

하지만 프로그래밍의 이전 추상화 방식들과 비교했을 때, 에이전틱 코딩 (Agentic coding)은 매우 누수되는 추상화 (Leaky abstraction)입니다. 컴파일러 (Compiler)처럼 결정론적 (Deterministic)이지 않으며, 입력값이나 모델의 미세한 변화가 매우 다른 결과를 초래할 수 있습니다. 이 때문에 사람들은 AI를 "주니어 엔지니어"에 비유하곤 하는데, 주니어 엔지니어들 또한 결정론적이지 않기 때문입니다. 하지만 한 가지 차이점은, 당연하게도 사람은 여러분이 그들의 AGENTS.md나 SKILL.md 파일을 끝없이 수정할 필요 없이 스스로 학습할 수 있는 능력이 있다는 점입니다.

Stack Overflow의 복사-붙여넣기 (Copy-pasta)의 확장으로서의 LLM

따라서 제가 지금까지 찾아낸 LLM 사용에 대한 가장 적절한 비유는 과거의 Google 검색이 작동하던 방식입니다. 우리 모두는 언젠가 적절한 포럼 게시물(그리고 나중에는 Stack Overflow 게시물)이 Google 검색 결과 첫 페이지에 나타날 수 있도록 정확한 키워드를 선택하는 기술을 배워야 했습니다. LLM에 프롬프트 (Prompt)를 입력하는 것과 마찬가지로, 학습 데이터의 올바른 조합을 반환하기 위해 퍼지 웹 검색 (Fuzzy web search)을 수행하는 것은 매우 고차원적인 공간에서의 조회 (Lookup) 작업입니다. 그리고 LLM과 마찬가지로, 이 조회 작업은 단어 표현의 미세한 변화나 Google 검색 인덱스 (Search index)의 변경에 매우 민감했습니다.

최근 몇 년 동안 Google은 다른 무엇보다도 입력된 용어를 훨씬 더 공격적으로 정규화 (Normalize)하도록 검색 방식을 변경했습니다. Google-fu라는 암흑의 기술에 익숙하지 않았던 사람들에게는 이 방식이 검색을 훨씬 사용하기 쉽게 만들었습니다. 하지만 그 기술을 습득했던 우리들에게는 Google 검색을 훨씬 덜 강력하게 만들었습니다. 특화된 키워드들은 과거에 우리를 정답으로 직접 안내하곤 했습니다. 하지만 이제는 그 키워드들이 유의어나 밀접하게 연관된 단어로 정규화되어, 우리는 더 일반적인 페이지에 도달하게 됩니다.

하지만 Google의 등장, 그리고 이후 Stack Overflow의 등장은 프로그래밍을 돌이킬 수 없을 정도로 변화시켰습니다. 프로그래머들은 더 이상 빌어먹을 매뉴얼을 읽는 대신, Stack Overflow에서 답을 무작정 복사하여 붙여넣을 수 있게 되었고, 놀랍게도 그 결과물이 어느 정도 작동하는 경우가 상당히 많았습니다. 이러한 관점에서 볼 때, LLM (Large Language Models)은 동일한 트렌드의 연장선에 있습니다. 즉, 무엇을 하고 있는지 아는 사람들을 조금 더 빠르게 만들어주고, 무엇을 하고 있는지 잘 모르는 사람들이 종종 어느 정도 작동하는 결과물에 도달할 수 있게 해주는 도구이자 추상화 (Abstraction)인 것입니다. 그리고 그거 아세요? 그건 아주 좋은 일입니다!

하지만 우리 자신을 속여서는 안 됩니다. 어느 시점에는 반드시 추상화 누수 (Abstraction leak)가 발생할 것입니다. 그때가 되면 누군가는 실제로 무슨 일이 일어나고 있는지 깊이 이해하고 이를 수정하기 위해 시간을 투자해야만 합니다. 우리가 주니어 프로그래머들에게 Stack Overflow의 답변을 사용하기 전에 먼저 읽고 이해하도록 가르쳤던 것처럼, 이제는 사람들에게 LLM이 내뱉는 결과물을 읽고 이해하며, 그것이 기존 코드베이스 (Codebase)에 어떻게 맞물리는지를 이해하도록 가르쳐야 합니다.

품질이 중요한가?

불행히도, 어떤 프로그래머들은 Stack Overflow의 답변을 진정으로 이해하려고 시도하는 단계로 결코 나아가지 못했습니다. 작동한다면 굳이 왜 귀찮게 하겠습니까? 그리고 공개적으로 인정되지는 않았지만, 실제로 많은 기업이 이러한 방식에 만족해 왔습니다. 지금 달라진 점은 기업들이 결과물을 살펴보는 척조차 하지 않으면서, 자신들이 얼마나 많은 AI를 사용하고 있는지를 공개적으로 선언하기 위해 애를 쓰고 있다는 것입니다.

LLM의 확실히 유효한 사용 사례 (Use-cases)들이 존재하지만, 동시에 코드를 망치고 조직의 커뮤니케이션과 프로세스를 망치는 새로운 방법들도 아주 많습니다. 이는 팀으로서 해결해야 할 특히 도전적인 과제로 보입니다. 코드 리뷰 (Code review)와 마찬가지로, LLM을 우리의 워크플로 (Workflow)에 어떻게 사용하고 통합할 것인지(혹은 아예 사용하지 않을 것인지)에 대해서는 매우 다양한 견해가 존재합니다. 만약 팀이 무엇을 가치 있게 여기는지에 대해 의견이 일치하지 않는다면, 이는 정말로 업무 진행을 방해하는 요소가 될 수 있습니다.

또한 많은 기업이 형편없는 소프트웨어를 쏟아내고 있음에도 불구하고 매우 잘 운영되고 있다는 사실은 삶의 슬픈 단면이기도 합니다. 우리 프로그래머들이 믿고 싶어 하는 것과는 달리, 비즈니스의 성공과 소프트웨어 품질은 상관관계가 있는 경우가 매우 드뭅니다. 보통은 다른 요인들이 압도적으로 작용하기 때문입니다. 종종 소프트웨어 프로젝트는 블랙박스 (black boxes)로 취급되며, 성공하는 만큼이나 자주 실패하는 것으로 알려져 있으며, 다양한 방식으로 리스크를 제거 (derisked)합니다 (최악의 경우, 다른 팀이 다시 한번 시도하게 됩니다).

프론트엔드 개발 (frontend development) 또한 마찬가지였습니다. 불행하게도, 끔찍한 웹사이트가 수익 (bottom line)에 미치는 영향은 상대적으로 작습니다. 느린 웹사이트와 수많은 쿠키 배너가 전환율 (conversion)을 떨어뜨릴까요? 물론 그렇지만, 그 효과는 브랜드 충성도나 가격 책정과 같은 다른 요인들에 비하면 상대적으로 작습니다. 게다가 모든 경쟁사도 웹사이트가 느립니다! 게다가 React를 선택했다고 해서 해고된 사람은 아무도 없었습니다.

그렇다면 우리가 사용자나 우리의 기술 (craft)에 대해 관심을 끊어야 한다는 뜻일까요? 아닙니다. 하지만 그렇게 할 수 있도록 허용되는 직업을 찾는 것이 훨씬 더 어려워졌음을 의미합니다. 바라건대, 거품이 빠지고 LLM (Large Language Models)이 실제로 어떤 작업에 적합하고 어떤 작업에 적합하지 않은지에 대해 더 잘 이해하게 되면, 추의 흐름이 다시 조금씩 돌아오기를 바랍니다. 하지만 우리의 직업이 이전과 같지는 않을 것이라고 말하는 것이 안전할 것입니다.

바우하우스 (The Bauhaus) 운동

이전 세대의 장인들은 일상 용품과 건물이 갑자기 산업 공정에 의해 대량 생산될 수 있게 되었을 때 무엇을 했나요? 한 가지 반응은 과거의 스타일을 모방하여, 산업계가 적어도 수공예로 만든 것처럼 보이는 도구와 건물을 찍어내도록 만드는 것이었습니다.

이러한 역사주의 (historicism) 경향에 대응하여, 20세기 초 바우하우스 (Bauhaus) 운동에 의해 대안적인 접근 방식이 개발되었습니다. 그들의 명시적인 목표는 공장 노동자와 장인을 대립시키는 대신, 그들이 함께 협력하여 산업 제조 공정을 염두에 두고 예술과 공예를 재개발하는 것이었습니다. 바우하우스는 디자이너들에게 다시 작업장으로 돌아가 재료 그 자체와 함께 작업할 것을 촉구했습니다. 여전히 대량 생산될 수 있는 디자인에 도달하는 것을 목표로 하되, 항상 최종 사용자 (end user)를 염두에 두고 그들을 깊이 배려하는 것이었습니다. Dieter Rams와 Jonathan Ive가 예시로 보여주는 현대 산업 디자인 (industrial design)은 그 뿌리를 바우하우스까지 직접 거슬러 올라갈 수 있습니다.

품질과 사용자에 대한 배려

이러한 사고방식을 소프트웨어로 어떻게 번역할 수 있을까요?

소프트웨어는 한편으로는 공예 (craft) (우리가 작성한 프로그램은 제조 단계를 거치지 않고 "있는 그대로" 사용자에게 전달됩니다)와, 다른 한편으로는 산업 디자인 (industrial design) (우리는 제품과 상호작용하는 모습을 결코 볼 수 없는 잠재적인 수천 명의 사용자에게 동일한 것을 전달합니다)의 중간 어디쯤에 위치합니다.

코드를 직접 손으로 작성할 수 있어야 할 필요성은 명확합니다. 산업 디자이너가 자신의 제품이 만들어질 재료를 알아야 하는 것처럼, 웹 디자이너는 HTML과 CSS에 친숙해야 합니다.