3줄 요약

  1. Mauro Bieg(Mastro 프레임워크 저자)가 2026년 5월 23일 자기 블로그에 올린 에세이다. 지난 10년 프론트엔드를 휩쓴 *탈숙련화(deskilling)*가 이제 AI를 통해 프로그래밍 전반으로 번지고 있다고 진단한다.
  2. 두 변화의 공통 구조는 *더 높은 추상화 + 누수(leaky abstraction)*다. 프론트엔드 프레임워크가 접근성·성능을 추상화 뒤로 숨겼듯, 에이전트 AI는 코드의 결정을 비결정적인 블랙박스 뒤로 옮긴다.
  3. 산업화에 대한 바우하우스의 응답을 모범으로 든다. 공예가와 공장 노동자를 적대시키지 말고, 재료에 손을 다시 대는 디자이너를 길러 대량 생산의 결과물을 끌어올렸듯, AI 시대에도 직접 손으로 코드를 쓸 줄 아는 사람의 자리는 좁아져도 사라지지 않는다.

자료의 정체

  • 발신자: Mauro Bieg(@mb21). 스위스의 한 주요 일간지 프론트엔드 팀 리드를 거쳤고, 현재 정적 사이트 생성기 Mastro의 저자.
  • 시점: 2026년 5월 23일, Mastro 공식 블로그.
  • 목적: AI 시대 프로그래밍의 변화를 프론트엔드 개발자가 이미 겪은 변화의 연장으로 읽어내자는 제안. 단순한 비관도 낙관도 아니고, 응답 방식의 모범을 산업사에서 끌어온다.

탈숙련화(deskilling) — 프론트엔드가 먼저 겪었다

저자는 위키피디아의 정의를 그대로 가져온다.

Deskilling is the process by which skilled labor within an industry or economy is eliminated by the introduction of technologies operated by semi- or unskilled workers. This results in cost savings […] and reduces barriers to entry, weakening the bargaining power of [workers].

이 정의를 두 변화에 차례로 적용한다.

프론트엔드의 탈숙련화

  • 한때 프론트엔드는 고도로 전문화된 직군이었다. 시맨틱 HTML, CSS, 브라우저 차이, 접근성, 점진적 향상, 네트워크 성능, 인터페이스 디자인, 사용자 테스트 등을 두루 알아야 했다.
  • JavaScript 프레임워크의 등장은 브라우저를 단순한 컴파일 타깃으로 취급하는 길을 열었다. Shadcn의 라디오 버튼 한 덩어리를 가져다 쓰면 그 아래의 HTML·브라우저 차이·페이지 로드 성능·접근성을 굳이 이해할 필요가 없다.
  • 결과는 정확히 위키피디아의 정의대로다. 기업은 어떤 일반 개발자든 프론트엔드에 투입할 수 있게 됐고, “풀스택"이라는 이름의 일반론자가 프로젝트 사이를 갈아탄다. 진입 장벽이 낮아진 대신 노동자의 협상력은 약해졌다.
  • 이런 변화에 저항하며 본래의 전문성을 지키는 사람들은 자신의 일을 “프론트엔드"가 아닌 “front of the frontend(프론트엔드의 앞단)“이라 부른다.

AI가 프로그래밍을 탈숙련화한다

  • 지금 프로그래머 전반에 벌어지는 일이 위와 매우 닮았다. 손으로 코드를 쓰는 숙련 노동이 “준숙련·미숙련 노동자가 조작하는 기술"로 대체되고 있다.
  • 에이전트 AI 운용에 어떤 스킬셋이 끝내 필요할지, 노동·로컬/원격 LLM의 가격이 어디로 수렴할지는 아직 모른다.
  • 그러나 한 가지는 이미 분명하다 — 기업은 이 기술을 비용 절감과 노동자 협상력 약화에 반드시 사용한다.

저자는 이 단락 끝에서 깊은 상실감을 인정한다. 100년 전 조립 라인 노동자에게 대체된 장인처럼, 지금의 개발자도 평생을 갈고 닦은 기술이 시장에서 값을 잃는 슬픔, 그리고 새로운 공정의 결과물이 더 낮은 품질이라는 사실에 슬퍼한다.

더 높은 추상화 — 그러나 모든 추상화는 누수한다

“탈숙련화"의 다른 이름은 추상화 수준의 상승이다. 자동화는 엔지니어가 사랑하는 일이기도 하다. 다만 어떤 디테일을 사소한 것으로 분류할 것인가는 결코 사소하지 않은 결정이다. 그리고 결국 디테일은 늘 새어 나온다.

“모던” 프론트엔드 — 누수가 쌓은 탑

  • 추상화는 성능 비용을 동반한다. 서버라면 가비지 컬렉션처럼 합리적인 트레이드오프이지만, 느린 네트워크 위의 저사양 모바일은 사정이 다르다.
  • React 같은 무거운 클라이언트 사이드 프레임워크와 그 생태계 패키지를 두텁게 쌓으면, 접근성과 저사양 폰·느린 네트워크의 성능을 함께 추상화해 버린다.
  • 그 추상화는 곧 그 디테일에 대해 생각하지 않기로, 신경 쓰지 않기로 선택한 것과 같다.

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

  • 에이전트 AI에 기능 구현이나 버그 수정을 맡기는 것은, 코드를 손으로 쓰는 것보다 더 적은 단어로 변경을 기술하는 것이다. AI는 학습 데이터와 주변 컨텍스트를 보고 빈자리를 채운다 — 잘 짚을 때도, 못 짚을 때도 있다.
  • 다만 이전 추상화와 다르게 에이전트 코딩은 비결정적이다. 컴파일러처럼 결정론적이지 않고, 입력이나 모델의 사소한 변동에도 결과가 크게 달라진다.
  • 그래서 사람들은 AI를 “주니어 엔지니어"에 비유한다. 다만 주니어는 학습한다 — AGENTS.md·SKILL.md 파일을 끝없이 손보지 않아도 된다.

LLM은 Stack Overflow 복붙의 연장

저자가 찾은 가장 적절한 비유는 옛 Google 검색이다.

  • 적절한 키워드를 골라 원하는 포럼/Stack Overflow 글을 첫 페이지에 띄우는 일은 그 자체로 하나의 기술이었다. 둘 다 고차원 공간의 모호한 룩업이고, 입력의 작은 변동에 결과가 크게 흔들린다.
  • 최근 몇 년 Google은 입력어를 더 적극적으로 정규화했다. Google-fu에 익숙치 않은 사람에게는 쓰기 쉬워졌지만, 그 기술을 익혔던 사람에게는 검색이 덜 강력해졌다. 특수 키워드가 동의어/연관어로 정규화되며 일반 페이지로 떨어진다.
  • 그래도 Google과 Stack Overflow의 등장은 프로그래밍을 돌이킬 수 없이 바꿔 놓았다. 매뉴얼을 읽지 않고 답을 복붙해 “어쨌든 굴러가는 무언가“를 만들어내는 흐름이 정착됐다.
  • LLM은 같은 추세의 연장이다. 아는 사람을 살짝 더 빠르게 만들고, 모르는 사람도 어쨌든 굴러가는 무언가에 도달하게 한다. 그 자체로 나쁘지 않다.
  • 다만 추상화는 결국 누수한다. 그때 누군가가 진짜로 내부를 이해하고 고쳐야 한다. 주니어에게 Stack Overflow 답변을 읽고 이해한 뒤 쓰라고 가르쳤듯, 이제는 LLM의 출력물을 읽고 이해한 뒤 기존 코드베이스에 어떻게 들어맞는지까지 보도록 가르쳐야 한다.

품질은 중요한가?

이 절은 다소 냉정하다.

  • 일부 프로그래머는 Stack Overflow 답변을 진짜로 이해하는 단계까지 가지 못한 채 일했다. 돌아가면 됐으니까. 그리고 솔직히, 많은 회사가 그 방식에 공공연하게는 아니어도 만족했다.
  • 지금 달라진 점은 — 회사들이 결과물을 들여다보지도 않은 채 얼마나 AI를 쓰는지 공개적으로 자랑한다는 것이다.
  • LLM의 정당한 쓰임새도 분명히 있지만, 코드와 조직의 소통·프로세스를 망가뜨리는 새 경로도 함께 열렸다. 팀의 관점 차이가 코드 리뷰 때보다 더 크게 갈라진다.
  • 슬프지만 사실 — 사업 성공과 소프트웨어 품질은 좀처럼 상관관계가 없다. 다른 요인이 더 크다. 소프트웨어 프로젝트는 자주 블랙박스로 다뤄지고, 절반 정도는 실패한다는 전제 위에 다양한 방식으로 위험이 분산된다.
  • 프론트엔드도 같다. 느린 사이트와 쿠키 배너가 전환율을 떨어뜨리긴 하지만, 브랜드 충성도·가격 같은 요인에 비하면 작다. 경쟁사 사이트도 다 느리고, React를 골라서 해고된 사람은 없다.
  • 그렇다고 사용자와 장인 정신을 포기하라는 뜻은 아니다. 다만 그렇게 일할 수 있는 자리를 찾기가 더 어려워졌다는 뜻이다.

바우하우스 — 산업화에 대한 한 가지 응답

일상의 물건과 건물이 갑자기 산업적으로 대량 생산되기 시작했을 때, 이전 세대의 장인들은 어떻게 반응했는가?

  • 한 흐름은 옛 양식의 모방이었다 — 공장이 찍어내는 위젯과 건물에 손으로 만든 것 같은 외관을 입히는 역사주의(historicism).
  • 다른 흐름이 바우하우스다. 공장 노동자와 장인을 대립시키는 대신 함께 일하게 했고, 산업적 제조 공정을 염두에 두고 예술·공예를 재구성하려 했다.
  • 바우하우스의 핵심 처방은 — 디자이너를 다시 워크숍으로 돌려보내, 재료에 손을 대게 하라. 최종 결과는 대량 생산이라 하더라도, 최종 사용자를 깊이 생각하며 만들라는 것.
  • Dieter Rams와 Jonathan Ive로 이어지는 현대 산업 디자인의 계보는 이 바우하우스의 후예다.

소프트웨어로 옮기면

저자는 소프트웨어가 공예(우리가 쓴 그대로 사용자에게 배포된다) 와 산업 디자인(우리가 만나지 못할 수천 명에게 같은 결과물이 간다) 사이 어딘가에 있다고 본다. 그래서 두 진영의 미덕을 모두 빌려야 한다.

  • 산업 디자이너가 자기 제품의 재료를 알아야 하듯, 웹 디자이너는 HTML과 CSS에 깊이 익숙해야 한다.
  • Google·Stack Overflow·라이브러리·LLM이 초심자의 진입 장벽을 낮춰 준 것은 좋은 일이다. 다만 어쨌든 굴러가는 무언가에 도달하는 자연 장벽도 같이 낮아진다는 뜻이다.
  • 진입 장벽이 높을 때는 정말 끔찍한 결과물을 보기 어렵다. 옛 목수가 의자 만드는 법을 배웠다면, 그와 동시에 못 만들지 않는 법도 배운 셈이다.
  • 산업화로 형편없는 플라스틱 제품이 쏟아졌지만 좋은 산업 디자인은 여전히 존재한다. 워드프로세서로 형편없는 문서가 쏟아졌지만 타이포그래피와 그래픽 디자인은 여전히 존재한다. Wix·Next.js로 느리고 접근성 없는 사이트가 쏟아져도 프론트엔드의 앞단을 지키는 이들은 남아 있다. AI도 같다 — AI 슬롭이 쏟아져도, 자기가 무엇을 왜 하는지 아는 사람의 자리는 사라지지 않는다.

어떻게 굳어질까

  • 다만 제대로 하는 일의 절대량 비중은 줄어들 것이다. 동시에 전체 파이는 더 커진다.
  • 제대로 일해서 돈을 받는 사람의 절대 수가 늘어날지 줄어들지는 지금 말하기 어렵다. 저자 본인은 “세상에 못 만든 플라스틱 제품이 너무 많고, 새 활자체 디자인이 더 이상 풀타임 직업이 되기 어렵다"는 사실을 안타까워한다 — 그래도 모든 분야에 훌륭한 작업은 여전히 많이 진행 중이다.
  • 빠른 프로토타이핑·MVP가 옳은 선택일 때가 있다. PMF가 없을 때는 빠른 반복과 학습이 미래 보강보다 더 중요하다.
  • 다만 무엇을 배우려 하는지, 어떻게 검증할 것인지를 알고 있어야 한다. 그리고 때가 되면 한 발 물러나 처음부터 제대로 하는 편이 결국 낫다. 잘못 설계된 프론트엔드 위에 좋은 성능을 나중에 얹는 일은 매우 어렵다. 단순한 스택에서 시작해 기능을 더하는 편이 그 반대보다 쉽다 — Mastro가 명시적으로 권장하는 길이기도 하다.
  • 시스템의 각 부분마다 어떤 트레이드오프를 받아들이고 있는지를 알고, 그 위에서 서비스를 살지, 오픈소스를 쓸지, LLM에게 시킬지, 직접 짤지를 결정해야 한다.
  • 하이프가 가라앉으면 LLM은 “공구함의 도구 한 가지"로 자리잡을 것이다. 그때까지는 추한 풍경이 이어진다 — 추한 코드, 망가진 의사소통, 그리고 AI를 명분 삼은 끔찍한 해고.

가장 흥미로운 지점

세 가지가 마음에 남는다.

첫째, 프레임워크의 진화와 AI의 등장을 같은 결로 묶어 본 시각이다. JavaScript 프레임워크가 “브라우저를 컴파일 타깃으로 취급"하게 만들어 접근성·성능을 추상화 뒤로 밀어 넣었듯, 에이전트 AI는 “코드를 결과물로 취급"하게 만들어 왜 그렇게 짰는가를 추상화 뒤로 밀어 넣는다. 두 변화의 기하학이 같다는 진단은 단순한 비유 이상이다 — 같은 누수 패턴, 같은 협상력 이동, 같은 상실감으로 이어지기 때문이다.

둘째, **“LLM은 Google·Stack Overflow의 연장”**이라는 비유가 의외로 정확하다. 양쪽 모두 고차원 공간의 모호한 룩업이고, 입력의 작은 변동에 결과가 크게 흔들린다. 다만 한 발 더 들어가면 어긋난다 — Stack Overflow의 답변은 결정적이고 사람의 검토 흔적이 남지만, LLM의 답변은 비결정적이고 검토 흔적이 옮겨지지 않는다. 비유가 정확한 만큼, 비유가 깨지는 자리가 곧 우리가 따로 설계해야 할 자리다.

셋째, 바우하우스를 처방으로 든 점이 단정하다. 단순한 회고나 향수가 아니라, 디자이너를 워크숍으로 돌려보내라는 구체적인 처방이 있다. 소프트웨어 맥락으로 옮기면 — AI에게 모두 맡기지 말고 적어도 *재료(HTML·CSS·시스템 콜)*에 정기적으로 직접 손을 대는 흐름을 유지하라는 뜻이다. 추상화에 누수가 일어났을 때 그 자리를 짚을 사람이 팀에 남아 있도록.

출처

발신: Mauro Bieg, Mastro 블로그 발행일: 2026년 5월 23일 원문: https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/

원문에 별도 인용 이미지·도식은 없어 텍스트 다이제스트로 옮겼다. 본문의 외부 링크는 원문의 참조를 그대로 따라가도록 남겨두었다.