AI는 프론트엔드의 '잃어버린 10년'을 되풀이하게 만들고 있는가?

https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/

AI가 프로그래머 일자리를 흔드는 광경이 우리 프론트엔드 개발자 눈에는 낯설지가 않습니다. 한 번 겪어 본 일이거든요.

프론트엔드에서 벌어진 변화와 에이전트 코딩, 이 둘을 우선 탈숙련화(deskilling) 라는 렌즈로 보고, 그다음에 더 높은 추상화 수준이라는 렌즈로 한 번 더 보겠습니다. 그러고 나서 Stack Overflow 복사-붙여넣기가 등장했던 과거의 변화들, 그리고 밀려드는 산업화 앞에서 바우하우스 운동이 택한 길을 이야기하려 합니다.

탈숙련화

AI가 지금 프로그래밍에 하고 있는 일을, JavaScript 프레임워크는 지난 10년 동안 프론트엔드에 해 왔습니다. 저는 HTML/CSS에 PHP를 조금 얹는 것으로 시작해서 Ruby on Rails를 거쳐, 스위스의 한 유력 신문사에서 프론트엔드 팀 리드까지 했습니다(그때는 Next.js를 썼고요). 그러니까 이 변화를 현장에서 죽 지켜본 셈입니다. 제 말만 믿으실 필요도 없습니다! 저 말고도 같은 이야기를 한 사람들이 이미 있고, Alex Russell은 아예 이 시기를 프론트엔드의 잃어버린 10년이라고 불렀습니다.

그런데 탈숙련화가 뭘까요? 위키백과에 따르면 이렇습니다.

탈숙련화란 반숙련·비숙련 노동자가 다룰 수 있는 기술이 도입되면서 산업이나 경제 안의 숙련 노동이 사라지는 과정이다. 그 결과 비용이 절감되고 […] 진입 장벽이 낮아지며, [노동자의] 교섭력이 약화된다.

이 정의가 프론트엔드에, 그리고 에이전트 코딩에 어떻게 들어맞는지 보겠습니다.

프론트엔드의 탈숙련화

모르는 프로그래머도 많겠지만, 프론트엔드는 원래 전문성이 꽤 깊은 분야였습니다. 시맨틱 HTML, CSS, 브라우저별 차이, 접근성, 점진적 향상(progressive enhancement), 네트워크 성능, 인터페이스 디자인, 사용자 테스트까지, 알아야 할 게 한둘이 아니었죠. 이 기예를 지금도 다루는 사람들은 자기 일을 요즘 통용되는 "프론트엔드"라는 말과 구분하려고 "프론트엔드의 앞단(front of the frontend)"이라고 부르곤 합니다.

프론트엔드의 탈숙련화 는 브라우저를 JVM이나 iOS 같은 여느 앱 런타임과 다를 바 없는 컴파일 대상으로 취급하는 프레임워크와 도구들이 들어오면서 일어났습니다. 이제 괴물 같은 Shadcn 라디오 버튼을 그냥 갖다 쓰면 됩니다. 그 밑에 깔린 HTML도, 브라우저마다 다른 미묘한 동작도, 페이지 로딩 성능도, 접근성도 몰라도 되고요.

위키백과 정의 그대로입니다. 아무 프로그래머나 프론트엔드에 앉힐 수 있으니 회사 입장에서는 "비용이 절감"됩니다. 안타깝게도 "풀스택 개발자"라는 말은 프론트엔드와 백엔드를 깊이 아는 사람이 아니라, JavaScript 프레임워크를 어느 정도 다뤄서 양쪽 일을 그럭저럭 해내는 제너럴리스트를 가리키는 경우가 많습니다. 회사는 그런 사람을 프로젝트 사이에서 손쉽게 돌려쓸 수 있습니다. React Native와 Electron만 있으면 같은 사람이 네이티브 앱까지 만들어 주니까요! 위키백과 정의의 나머지 절반도 그대로 실현됐습니다. "진입 장벽이 낮아지"고(저는 이 점만큼은 늘 소중하게 여겨 왔습니다), "노동자의 교섭력이 약화"된 겁니다.

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

프로그래머 전체에 지금 벌어지는 일도 판박이입니다. 특히 웹 개발자들이 이미 겪은 것과요. 손으로 코드를 짜는 숙련 노동이 "반숙련·비숙련 노동자가 다룰 수 있는 기술이 도입되면서" 사라지고 있는 겁니다.

이 변화가 다 지나간 뒤 에이전트 AI를 부리는 노동자에게 정확히 어떤 역량이 남을지, 노동력 가격과 로컬·원격 LLM 가격이 어디서 균형을 잡을지는 아직 모릅니다. 다만 기업들이 이 기술로 비용을 깎고 노동자의 교섭력을 눌러 놓으리라는 것 하나는 벌써 분명해 보입니다.

깊은 상실감

100년쯤 전 조립 라인에 자리를 내준 장인들이 그랬을 것처럼, 우리도 깊은 상실감을 느낍니다. 반평생 갈고닦은 기술이 시장에서 더는 값을 쳐주지 않는다는 게 슬프고, 새 방식이 내놓는 결과물의 질이 떨어지는데도 다들 별로 개의치 않아 보인다는 게 또 슬픕니다.

더 높은 추상화 수준에서 일하기

물론 "탈숙련화"를 전혀 다르게 읽는 시각도 있습니다. 이건 그냥 자동화로 효율을 높이는 일이라는 거죠. 자동화를 싫어할 엔지니어가 어디 있겠습니까. 자동화가 곧 우리 밥벌이의 큰 부분인데요!

이렇게 보면 새로 들어온 기술은 더 높은 추상화 수준에서 돌아갈 뿐이고, 쓰는 사람은 자잘한 세부에서 풀려나 큰 그림에 집중하게 됩니다. 문제는 어떤 세부를 "자잘하다"고 칠 것이냐인데, 이건 파급이 크고 때로는 꽤 주관적인 결정입니다. 게다가 세부 사항이란 언제나 새어 나오게 마련이고요.

"모던" 프론트엔드: 줄줄 새는 추상화로 쌓은 탑

추상화는 성능을 대가로 요구할 때가 많습니다. 그래도 요즘 컴퓨터는 워낙 빠르니, 우리는 런타임 성능을 조금 내주고 개발 생산성을 얻는 거래를 기꺼이 해 왔습니다. 가비지 컬렉션이 그런 예죠. 부하가 적당한 성능 좋은 서버에서라면 남는 장사입니다. 느린 네트워크에 물린 휴대폰이라면 이야기가 완전히 달라지지만요.

React 같은 무거운 클라이언트 사이드 JavaScript 프레임워크에 그 생태계의 수많은 패키지를 얹는다는 건, 접근성이나 저사양 휴대폰과 느린 네트워크에서의 성능 같은 걸 추상화 밑으로 밀어 넣는다는 뜻입니다. 사실상 그런 문제는 생각하지 않겠다고, 신경 쓰지 않겠다고 정해 버린 셈이죠.

에이전트 코딩: 비결정적 추상화

에이전트 AI로 기능을 붙이거나 버그를 잡을 때 우리는 코드를 전부 직접 칠 때보다 적은 말로, 더 높은 추상화 수준에서 원하는 변경을 서술합니다. 빠진 세부는 AI가 학습 데이터와 주변 맥락을 보고 메꾸는데, 잘 짚을 때도 있고 아닐 때도 있습니다. 이게 쓸 만하다고 느낄지 아닐지는 코딩에서 무엇을 중요하게 보느냐에 따라 크게 갈립니다.

다만 에이전트 코딩은 프로그래밍이 그동안 쌓아 온 다른 추상화들과 견주면 유난히 잘 새는 추상화입니다. 컴파일러 같은 결정성이 없어서, 입력이나 모델이 조금만 달라져도 결과가 확 달라질 수 있습니다. 사람들이 AI를 "주니어 엔지니어"에 곧잘 비유하는 이유가 이겁니다. 주니어도 결정적이진 않으니까요. 차이라면, 사람 주니어는 AGENTS.md니 SKILL.md니 하는 파일을 끝없이 고쳐 주지 않아도 알아서 배운다는 점이겠지만요.

Stack Overflow 복사-붙여넣기의 연장선에 있는 LLM

그런 점에서 제가 지금껏 찾은 LLM에 가장 잘 맞는 비유는 옛날 Google 검색입니다. 원하는 포럼 글이(나중엔 Stack Overflow 글이) 검색 결과 첫 페이지에 뜨게끔 키워드를 딱 맞게 고르는 것도 한때는 누구나 익혀야 했던 기술입니다. 퍼지한 웹 검색은 아주 고차원의 공간에서 벌어지는 조회입니다. 학습 데이터에서 딱 맞는 조합을 끌어내려고 LLM에 프롬프트를 넣는 것과 똑같이요. 그리고 LLM처럼 이 조회도 표현이 살짝만 달라져도, Google의 검색 색인이 바뀌어도 크게 흔들렸습니다.

근래 Google은 여러 개편 중에서도 입력된 검색어를 훨씬 공격적으로 정규화하는 쪽으로 검색을 바꿨습니다. 검색의 비법(Google-fu)을 익힌 적 없는 사람에게는 검색이 한결 쉬워졌죠. 대신 그 기술을 익혔던 우리에게는 검색이 무뎌졌습니다. 전문 키워드를 넣으면 곧장 답으로 이어지던 것이, 이제는 동의어나 비슷한 말로 뭉개져서 더 두루뭉술한 페이지에 떨어지고 맙니다.

어쨌든 Google과 뒤이은 Stack Overflow는 프로그래밍을 되돌릴 수 없게 바꿔 놓았습니다. 그놈의 매뉴얼을 읽는 대신 프로그래머들은 Stack Overflow 답변을 무작정 복사해 붙였고, 그러면 놀랄 만큼 자주 그럭저럭 돌아가는 걸 손에 쥐었습니다. 이 렌즈로 보면 LLM은 그 흐름의 연장일 뿐입니다. 자기가 뭘 하는지 아는 사람은 조금 더 빨라지고, 잘 모르는 사람도 그럭저럭 돌아가는 무언가까지는 가게 해 주는 도구이자 추상화 말입니다. 솔직히 그거 좋은 일 아닌가요!

다만 스스로를 속이지는 맙시다. 추상화는 언젠가 샙니다. 그 순간이 오면 누군가는 시간을 들여 무슨 일이 벌어졌는지 밑바닥까지 이해하고 고쳐야 합니다. 주니어 프로그래머에게 Stack Overflow 답변은 읽고 이해한 다음에 쓰라고 가르쳤던 것처럼, 이제는 LLM이 뱉어 낸 것을 읽고 이해하고, 그게 기존 코드베이스에 어떻게 맞물리는지 파악하라고 가르쳐야 합니다.

품질이 중요하긴 한가?

안타깝게도 Stack Overflow 답변을 정말로 이해해 보는 단계까지 끝내 못 간 프로그래머들도 있습니다. 돌아가는데 뭐 하러요? 그리고 대놓고 인정만 안 했을 뿐, 사실 그 방식에 만족한 회사도 많았습니다. 지금 달라진 건 하나입니다. 회사들이 결과물을 들여다보는 시늉조차 없이, 자기들이 AI를 이만큼 쓴다고 앞다투어 공개 선언한다는 것.

LLM이 확실히 쓸모 있는 경우야 분명 있습니다. 그런데 코드를 망치는 새로운 방법, 조직의 커뮤니케이션과 프로세스를 망치는 새로운 방법도 같이 잔뜩 생겼습니다. 특히 팀 단위에서 갈피를 잡기가 어려워 보입니다. 코드 리뷰가 그렇듯, LLM을 워크플로에 어떻게 쓰고 통합할지(혹은 아예 쓰지 말지)에 대한 견해도 사람마다 크게 다릅니다. 뭐가 중요한지 팀의 눈높이가 안 맞으면 일이 제대로 굴러갈 리 없고요.

형편없는 소프트웨어를 찍어 내면서 잘만 나가는 회사가 많다는 것도 씁쓸하지만 엄연한 현실입니다. 우리 프로그래머들은 믿고 싶어 하지 않지만, 사업의 성공과 소프트웨어 품질이 상관관계를 보이는 경우는 드뭅니다. 대개는 다른 요인이 그냥 압도해 버리거든요. 소프트웨어 프로젝트는 성공하는 만큼 실패하는 걸로 유명한 블랙박스 취급을 받고, 그 위험은 이런저런 방식으로 분산됩니다. 최악의 경우엔 다른 팀이 한 번 더 도전하는 식으로요.

프론트엔드 개발도 다르지 않았습니다. 끔찍한 웹사이트가 순익에 주는 타격은 안타깝게도 크지 않습니다. 느려 터진 사이트와 덕지덕지 붙은 쿠키 배너가 전환율을 깎느냐고요? 깎습니다. 그래도 브랜드 충성도나 가격 같은 요인 앞에서는 미미한 수준입니다. 게다가 경쟁사 웹사이트도 다 느리잖아요! 무엇보다, React를 골랐다는 이유로 잘린 사람은 여태 아무도 없습니다.

그럼 사용자도, 우리 기예도 그만 아끼자는 얘기냐 하면 그건 아닙니다. 그렇게 일할 수 있는 직장을 찾기가 한층 어려워졌다는 뜻일 뿐이죠. 과열이 가라앉고 LLM이 실제로 어떤 작업에 맞고 어떤 작업에 안 맞는지 감이 잡히고 나면, 시계추가 조금은 되돌아오기를 바랍니다. 그래도 우리 직업이 예전 같지는 않을 겁니다.

바우하우스 운동

일상용품과 건물을 어느 날 갑자기 산업 공정으로 대량 생산할 수 있게 됐을 때, 그 전 세대 장인들은 뭘 했을까요? 하나의 반응은 옛 양식을 베끼는 것이었습니다. 겉모습만은 수공예처럼 보이는 물건과 건물을 공장에서 찍어 내는 거죠.

20세기 초의 바우하우스 운동은 이런 역사주의에 맞서 다른 길을 냈습니다. 공장 노동자와 장인을 맞세우는 대신 두 집단이 함께 일하게 하고, 산업 제조 공정을 전제로 공예를 새로 일으켜 세우자는 것이었습니다. 바우하우스는 디자이너들에게 공방으로 돌아가 재료를 손으로 만지며 작업하라고 요구했습니다. 종착점은 어디까지나 대량 생산에 올릴 디자인이었지만, 언제나 최종 사용자를 마음에 두고 깊이 아끼면서요. Dieter Rams와 Jonathan Ive로 대표되는 현대 산업 디자인의 뿌리를 따라가면 곧장 바우하우스가 나옵니다.

품질과 사용자를 아끼는 마음

이 사고방식을 소프트웨어로 가져오면 어떻게 될까요?

소프트웨어는 공예와 산업 디자인 사이 어디쯤에 있습니다. 우리가 짠 프로그램은 별도의 제조 단계 없이 "그대로" 사용자에게 갑니다. 이건 공예 쪽입니다. 동시에 똑같은 걸 수천 명에게 배포할 수 있으면서도 그들이 우리 제품을 쓰는 모습은 결코 직접 볼 수 없습니다. 이건 산업 디자인 쪽이고요.

손으로 코드를 쓸 줄 알아야 한다는 건 분명합니다. 산업 디자이너가 제품에 들어갈 재료를 알아야 하듯, 웹 디자이너는 HTML과 CSS를 속속들이 알아야 합니다.

Google이, Stack Overflow가, 바로 가져다 쓸 수 있는 라이브러리가, 이제는 LLM이 초보자의 일을 쉽게 만들어 주는 건 반가운 일입니다. 뒤집어 말하면 뭐든 일단 돌아가게 만드는 데 필요한 자연스러운 문턱이 계속 낮아지고 있다는 뜻이기도 하지만요.

문턱이 높은 분야에서는 정말 형편없는 물건을 보기가 어렵습니다. 나무 의자 만드는 법을 배운 장인은 예외 없이, 형편없이 만들지 않는 법도 같이 배웠으니까요.

산업화는 쓸 사람을 한 번도 생각해 보지 않은 이들이 디자인한 싸구려 플라스틱 제품을 쏟아 냈습니다. 그래도 좋은 산업 디자인은 살아남았습니다. 워드 프로세서는 끔찍하게 편집된 문서를 양산했지만 타이포그래피와 그래픽 디자인은 여전히 있습니다. Wix며 Next.js 같은 소프트웨어가 지독하게 느리고 접근성 없는 웹사이트를 찍어 내는 동안에도, 프론트엔드의 앞단을 다루는 사람들은 사라지지 않았습니다. 마찬가지로 AI가 조악한 AI 양산물(AI slop)을 쏟아 낸다고 해서, 자기가 뭘 하는지 알고 자기 일을 아끼는 사람이 더는 필요 없어지는 것도 아닙니다.

앞으로 어떻게 될까?

다만 다른 산업들이 걸어간 길을 보면, 제대로 만드는 일이 차지하는 몫은 갈수록 줄어들 겁니다. 대신 만드는 일 자체가 싸고 쉬워졌으니 파이 전체는 계속 커지겠죠. 그래서 일을 제대로 하는 값을 받는 사람의 절대 수가 늘지 줄지는, 지금 시점에서는 정말 말하기 어렵습니다. 제 생각을 묻는다면, 세상엔 엉터리로 디자인된 플라스틱 제품이 너무 많습니다. 새 서체를 디자인하는 걸로는 더 이상 먹고살기 어렵다는 것도 슬픈 일이고요. 그런데도 이 모든 분야에서 훌륭한 작업이 지금도 수없이 나옵니다.

솔직히 말하면, 프로토타입이나 MVP를 후딱 만들어 내는 게 맞는 순간도 있습니다. 제품-시장 적합성(product-market fit)을 아직 못 찾았다면, 모든 걸 미래에 대비해 다져 두는 것보다 빨리 돌려 보고 배우는 게 우선입니다. 물론 뭘 배우려는 건지, 배운 걸 어떻게 검증할지는 알고 있어야죠. 그리고 때가 오면 대개는 한발 물러나 처음부터 제대로 짓는 편이 낫습니다. 이를테면 좋은 성능은 아키텍처가 엉망인 프론트엔드에 나중에 끼워 넣기가 몹시 어렵습니다. 단순한 스택으로 시작해 나중에 기능을 얹는 게 그 반대보다 쉽기도 하고요. Mastro는 이 두 가지를 명시적으로 권장합니다.

시스템 어느 구석에서든 지금 무슨 트레이드오프를 하고 있는지 알아야 하고, 그다음에 정해야 합니다. 서비스를 사다 쓸지, 오픈 소스 라이브러리를 쓸지, LLM에게 뽑아내게 할지, 직접 짤지. 과열이 식고 나면 업계도 이게 도구 상자에 도구가 하나 더 생긴 것뿐임을 알게 될 겁니다. 그때까지는 흉한 걸 실컷 보겠지만요. 흉한 코드, 망가진 커뮤니케이션, 그리고 AI를 핑계 삼은 참혹한 해고까지.