---
title: '프론트엔드는 어디서 왔고, 에이전트 이후 어디로 가는가'
tags:
  - ai
  - essay
  - frontend
  - react
  - future-of-work
published: true
date: 2026-07-22 10:00:00
description: '층은 왜 쌓였고, 왜 서버로 돌아왔고, 에이전트 이후에도 스택이 남는 이유는 무엇인가. 그리고 스택이 이기는 것과 그 스택을 아는 사람의 가치는 왜 별개인가'
thumbnail: /thumbnails/2026/07/frontend-past-present-after-agents.png
---

## 제자리로 돌아온 것처럼 보이지만

2026년의 가장 앞선 프론트엔드 관행을 한 줄로 요약하면 이렇다. 서버에서 HTML을 만들어 보내고, JavaScript는 꼭 필요한 만큼만 싣는다. Server Components, Astro, islands architecture. 이름은 새것이지만 모양은 2008년과 크게 다르지 않다. 18년을 돌아 비슷한 자리로 돌아온 셈이다.

그런데 자세히 보면 같은 자리가 아니다. 진자가 돌아온 바로 그 시점에, 더 근본적인 변수가 바뀌고 있기 때문이다. 코드를 쓰는 손이다. 클라이언트냐 서버냐를 두고 20년을 오간 논쟁이 마무리되어 가는 참에, 그 코드를 사람이 쓴다는 전제 자체가 흔들리기 시작했다. 그래서 이 글에서는 세 가지 질문을 순서대로 짚어 보려 한다. 그 많던 층은 왜 쌓였을까(과거). 지금 우리는 어디에 서 있을까(현재). 에이전트가 코드의 대부분을 쓰게 되면 이 스택은 어떻게 될까(미래).

## 먼저 결론

본문이 길어서, 핵심을 먼저 요약해 둔다.

- 지난 20년의 복잡성은 자의적이지 않았다. 대부분 실제로 겪던 문제 위에 쌓인 층이다. 다만 같은 20년은, 층이 하나 생길 때마다 그 아래를 몰라도 되는 세대를 함께 낳은 탈숙련화의 역사이기도 했다. 두 시선은 모순이 아니라고 생각한다.
- 에이전트가 스택을 갈아치울 것이라는 예측은 세 겹의 장벽을 넘어야 한다. 학습 데이터 관성, **검수 책임**, **트러블슈팅 정보량**이다. 흔히 첫 번째만 이야기되지만, 더 단단한 것은 뒤의 둘이다.
- 그런데 "어느 스택이 이기는가"는 생각보다 덜 중요한 질문일 수 있다. SQL은 사실상 완승했지만, 그것을 아는 사람의 직함까지 지켜 주지는 못했다. **스택의 생존과 그 스택을 아는 사람의 가치는 별개로 움직인다.**
- 그렇다면 사람은 어디로 가는가. 직함은 프로덕트 엔지니어로 흡수되고, 프론트엔드 전문성은 소수의 서식지로 응집될 가능성이 높다고 본다. 문제는 그 응집층을 다시 길러낼 사다리가 잘 보이지 않는다는 것이다.

각 항목의 근거는 본문에서 하나씩 설명한다.

## 과거: 층은 왜 쌓였나

프론트엔드의 복잡성은 오래된 농담거리다. HTML 한 장 보여주는 데 빌드 도구가 왜 다섯 개나 필요하냐는 이야기는 십 년째 유효하다. 그런데 그 층들을 하나씩 걷어 보면, 이유 없이 쌓인 층을 찾기가 어렵다.

시작은 문서였다. 2000년대 중반까지 웹 페이지는 서버가 HTML을 만들어 보내면 브라우저가 그리는 물건이었고, 무언가를 바꾸려면 페이지 전체를 다시 불러와야 했다. 이 전제를 대중 앞에서 흔든 것이 Gmail(2004)과 Google Maps(2005)였다. 페이지를 다시 불러오지 않고도 화면이 갱신되는 경험은 당시로서는 낯선 것이었고, 이 방식에 Ajax라는 이름이 붙으면서(2005) 웹을 문서가 아니라 앱으로 만들려는 흐름이 시작됐다.

문제는 그 앱을 만들 도구가 마땅치 않았다는 점이다. 브라우저마다 DOM API가 조금씩 달랐고, 특히 IE6라는 거대한 예외가 있었다. 개발자들은 브라우저 호환성 표를 옆에 두고 분기문을 쌓았다. jQuery(2006)가 이 파편화를 하나의 API로 덮으면서 사실상의 표준이 됐다. 첫 번째 층이다.

jQuery로 만드는 앱이 커지자 다음 문제가 드러났다. DOM을 직접 조작하는 방식에서는 상태가 어디서 어떻게 바뀌는지 추적하기 어려웠고, 데이터와 화면이 어긋나는 버그가 코드 크기에 비례해 늘었다. Backbone과 AngularJS(2010)가 구조로 이 문제를 잡으려 시도했고, React(2013)는 다른 답을 냈다. UI를 상태의 함수로 선언하고, DOM 갱신은 라이브러리에 맡기는 방식이다. HTML을 JavaScript 안에 쓰는 JSX는 공개 당시 조롱에 가까운 반응을 받았지만, 결과적으로는 이 선언적 모델이 경쟁에서 자리를 잡았다. 두 번째 층이다.

언어 쪽에도 문제가 쌓이고 있었다. 모듈 시스템이 없는 언어로 수십만 줄짜리 앱을 짓게 된 것이다. CommonJS와 AMD가 난립하다가 ES2015가 모듈과 새 문법을 표준화했는데, 브라우저가 그것을 따라오기까지는 시차가 있었다. 그 시차를 메운 것이 Babel(트랜스파일)과 webpack(번들링)이고, 이때부터 프론트엔드에 빌드 단계가 상수로 자리 잡았다. 빌드 도구 다섯 개라는 농담의 기원, 세 번째 층이다.

층은 층을 낳았다. JavaScript로 만든 빌드 도구들은 코드베이스가 커지는 속도를 따라가지 못했고, Go와 Rust로 다시 쓴 도구들(esbuild, SWC)과 그 위의 Vite가 그 문제를 덮었다. 네 번째 층이다. 클라이언트에 모든 것을 실어 나르던 SPA는 번들이 수 MB로 불어나면서 저사양 기기와 느린 네트워크에서 한계를 드러냈고, 서버 귀환(Next.js의 SSR과 SSG, React Server Components, Astro의 islands)이 그 문제를 덮었다. 다섯 번째 층이자, 서두에서 말한 원점 회귀다.

매 층이 앞 층이 남긴 문제에 대한 반응이었다. 나는 이 흐름의 한복판에서 12년을 보냈는데, 각 층이 등장할 때마다 그 층이 해결하려던 문제가 실재했다는 것만은 분명히 기억한다.

그런데 같은 역사를 반대편에서 읽을 수도 있다. 층이 하나 쌓일 때마다, 그 아래를 몰라도 되는 세대가 함께 태어났다. jQuery 세대는 브라우저 호환성 표를 외웠지만 그다음 세대는 그럴 필요가 없었고, 프레임워크 세대는 HTML의 의미론이나 HTTP 캐시, 접근성을 깊이 알지 못해도 화면을 만들 수 있게 됐다. 진입 장벽이 내려간 만큼 산출물의 중앙값도 함께 내려갔다는 지적이 나오는 이유이고, 이 10년을 잃어버린 10년이라고 부르는 시선이 있는 이유이기도 하다.

두 독해는 모순처럼 보이지만, 실은 같은 사실의 앞면과 뒷면이라고 생각한다. 층은 필요해서 생겼고, 생긴 뒤에는 그 아래를 보이지 않게 만들었다. 추상화의 본성이 원래 그렇다. 문제를 덮어서 보호하는 동시에, 덮인 것을 잊게 만든다. 이 이중성은 미래를 이야기할 때 한 번 더 등장한다. (이 층들을 하나씩 따라 내려가며 변호하는 글로는 David Poblador의 [The Descent](https://davidpoblador.com/deep-dives/what-happened-to-the-frontend/)가, 같은 시기를 잃어버린 10년으로 고발하는 글로는 Mauro Bieg의 [해당 글](https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/)이 있다.)

## 현재: 회귀, 그리고 작성자 교체

서두에서 말했듯 진자는 서버로 돌아왔다. 여기까지만 보면 역사가 순환한다는 이야기로 끝난다. 그런데 돌아온 바로 그 시점에 코드를 쓰는 손이 바뀌고 있다. [이전 글에서 인용했듯](https://yceffort.kr/2026/06/learning-what-ai-cant-do) Microsoft도 Google도 새 코드의 30% 안팎을 AI가 쓴다고 말한다. 집계 방식은 회사마다 흐릿하지만 방향은 분명해 보인다.

이것이 왜 스택의 문제가 되는가 하면, 지난 20년의 층이 대부분 **사람의** 문제 위에 쌓였기 때문이다. JSX는 사람이 마크업과 로직을 한눈에 보기 위한 문법이고, 컴포넌트 경계는 사람의 인지 단위이고, hooks의 규칙(최상위에서만 호출, 조건문 금지)은 사람이 실수하지 않도록 만든 가드레일이다. 린트도, 타입도, 프레임워크의 관례도 대부분 사람의 한계를 향해 설계됐다. 작성자가 사람이 아니게 되면 자연스럽게 질문이 하나 생긴다. 이 축적은 자산일까, 비용일까.

여기서부터가 미래에 대한 이야기다.

## 미래 1: 해체 시나리오

반론은 가장 강한 형태를 상대하는 것이 공정하니, 해체 쪽 논거를 최대한 강하게 정리해 본다.

사람의 인지 한계에 맞춘 추상화는, 인지 한계가 없는 작성자에게는 비용만 남는다. 코드를 쓰는 것도 읽는 것도 에이전트라면, 벤더가 사람의 DX 대신 에이전트 친화적인 타깃(더 결정적이고, 더 검증하기 쉽고, 더 적은 토큰으로 표현되는 무언가)을 새로 설계해서 밀지 않을 이유가 없다. 실제로 모델 벤더에게는 그렇게 할 유인이 충분하다. 자기 모델이 가장 잘 다루는 타깃이 업계 표준이 되는 것만큼 단단한 해자를 찾기는 어렵다.

여기에 대한 표준 반론은 학습 데이터 관성이다. 세상의 프론트엔드 코드 대부분이 React와 그 생태계로 쓰여 있고 모델은 그 데이터로 학습됐으니, 에이전트는 계속 그 스택을 만들어낼 것이라는 논리다. 일리는 있지만 생각보다 튼튼하지 않다. 관성은 복리로 쌓이지만 외생 충격에 흔들린다. 벤더가 새 타깃을 만들어 자기 모델에 집중적으로 학습시키고, 합성 데이터로 초기 부족분을 메우고, 자기 에이전트 제품의 기본값으로 밀면, 관성은 몇 년 안에 뒤집힐 수도 있다.

여기까지는 충분히 있을 법한 이야기다. 다만 한 가지 짚고 싶은 부분이 있다. 이 시나리오는 인과의 마지막 고리를 생략하고 있다.

## 미래 2: 밀어도, 사람이 받지 않는다

인과 사슬을 끝까지 따라가 보면, 마지막 고리는 모델이 아니라 채택이다. 그리고 채택은 사람이 한다. 에이전트가 코드를 다 쓰는 단계에서도 배포 버튼을 누르는 것은 사람이고, 장애가 나면 새벽에 불려 나오는 것도 사람이다. 그 사람은 최소한의 검증이라도 해야 하는 자리에 있다. 그런데 검증은 읽을 수 있는 대상에만 가능하다. 낯선 스택으로 작성된 코드는 검수가 어려운 블랙박스가 되기 쉽고, 그런 코드를 책임지고 승인하기는 어렵다. 그래서 결국 자신이 읽을 수 있는 익숙한 스택을 선택하게 될 가능성이 높다.

이 병목이 기술의 문제가 아니라는 점이 중요하다고 생각한다. [코드 읽기를 다룬 글](https://yceffort.kr/2026/06/do-you-need-to-read-code)에서 책임은 머릿속 이해의 문제가 아니라 계약의 문제라고 썼는데, 같은 구조가 여기서도 작동한다. 검수 책임은 조직과 법에 묶여 있어서 모델 성능만으로는 풀리지 않는다. 에이전트의 자율성이 아무리 올라가도, 책임이 사람에게 남아 있는 한 사람이 읽을 수 있어야 한다는 요구는 사라지지 않는다.

다만 범위는 좁혀 두는 것이 정확하다. 이 논거는 엄밀히는 "익숙함"이 아니라 "검수 가능성"에 기대고 있고, 이 둘이 갈라지는 영역이 있다. 검수를 사실상 하지 않는 코드다. 일회용 프로토타입, 마케팅 페이지, 만들고 버리는 MVP. 이런 영역에서는 결과만 동작하면 스택이 무엇이든 크게 상관이 없어진다. 그래서 정확한 명제는 "검수 책임이 존재하는 영역에서는 익숙한 스택이 유리하다" 정도가 될 것이다. 매출과 유지보수가 걸린 코드의 비중이 크니 전체 결과는 고착 쪽으로 기울겠지만, 구멍은 구멍이다. 그 글 말미에 "이해가 필요 없는 코드는 실존하고, 그 영역은 좁지 않으며 커지고 있다"고 양보했던 바로 그 영역이기도 하다.

해체 시나리오는 이 구멍으로 파고들 수 있다. 검수 없는 영역에서 에이전트 최적화 타깃이 발판을 얻고, 거기서 성숙한 다음 검수 있는 영역으로 올라온다는 경로다. 충분히 그려 볼 수 있는 그림이다.

## 미래 3: 검수를 포기한 코드도 깨진다

그런데 그 구멍에서도 기존 스택이 유리하다고 생각한다. 트러블슈팅에 필요한 정보가 이미 쌓여 있기 때문이다.

만들고 버리는 프로토타입도 데모 직전에 동작하지 않으면 고쳐야 한다. 그 순간 필요한 것은 검수 능력이 아니라 붙잡을 수 있는 밧줄이다. 에이전트는 아직 종종 막히고, 막히면 결국 사람에게 넘어온다. Joel Spolsky가 [새는 추상화의 법칙](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)이라고 부른 것의 실전판이다. 추상화가 새는 바로 그 지점에서, 스택별로 축적된 정보의 양이 결정적으로 작용한다. React와 그 생태계에는 십수 년치 에러 메시지와 GitHub 이슈와 Stack Overflow 답변이 쌓여 있다. 낯선 스택은 사람이 검수를 포기했더라도, 깨졌을 때 붙잡을 것이 마땅치 않다.

한 가지 더 중요한 점은, 에이전트 자신도 그 밧줄로 학습됐다는 것이다. 에이전트가 자기 오류를 수정하는 능력조차, 학습 데이터에 해당 스택의 디버깅 사례가 많을수록 좋아진다. 즉 학습 데이터 관성은 생성 단계에서 한 번, 자기수정 단계에서 또 한 번, 두 번 작동한다. 흔히 말하는 "모델이 React를 잘 짠다"는 절반의 이야기이고, 나머지 절반은 "모델이 React를 잘 고친다"이다. 새로운 타깃이 전자를 합성 데이터로 흉내 낼 수는 있어도, 후자는 실전에서 깨져 본 기록의 축적이라 당장은 흉내 내기가 어렵다.

이 논거가 검수 논거보다 우회하기 어려운 이유는 단순하다. 검수는 상황에 따라 건너뛸 수 있지만, 동작하지 않는 코드는 건너뛸 수 없다.

정리하면 고착을 지지하는 힘은 세 겹이다. 학습 데이터 관성(생성), 검수 책임(사전), 트러블슈팅 정보량(사후). 첫째는 외생 충격에 흔들릴 수 있는 조건부 논거이고, 둘째는 영역에 따라 갈리는 조건부 논거인데, 셋째가 그 조건들의 예외 영역까지 덮는다. 여기까지가 고착 쪽의 논증이다.

## 이 논거들의 유통기한

여기서 끝내면 한쪽 이야기만 한 셈이 된다. 이 논거들이 어디서 약해지는지도 함께 적어 두는 편이 정직할 것이다.

첫째, 검수 책임 논거는 "코드를 읽는 것"까지 보장하지는 않는다. 컴파일러라는 전례가 있다. 사람들은 한때 컴파일러가 만든 어셈블리를 읽었지만, 신뢰가 쌓이자 검수는 사라진 것이 아니라 위층으로 이동했다. 이제는 소스를 검증하고 어셈블리는 보지 않는다. 검수 책임이 실제로 요구하는 것은 "사람이 신뢰할 수 있는 검증 인터페이스"이지 코드 리딩 그 자체가 아니다. 지금은 그 인터페이스가 코드이지만, E2E 테스트와 비주얼 회귀와 에이전트 QA가 충분히 촘촘해지면 "행동을 검증하고 코드는 읽지 않는" 균형점도 가능하다. [코드 읽기를 다룬 글](https://yceffort.kr/2026/06/do-you-need-to-read-code)에서 그린 검증 레이어가 이 이동의 설계도에 가깝다. 프론트엔드는 정답을 명세하기 어려운 영역이라(시각, UX) 전환이 늦게 오겠지만, 원리적으로 막혀 있지는 않다.

이 "늦게"가 막연한 단서가 아니라는 것을 보여주는 사례가 CSS다. 에이전트를 써 본 사람들이 공통으로 겪는 일인데, 로직은 곧잘 짜는 모델이 레이아웃과 스타일에서는 유난히 헤맨다. 이유를 뜯어 보면 우연이 아니다. 우선 CSS의 정답은 텍스트가 아니라 렌더링된 화면에 있다. 스크린샷을 찍어 피드백을 주는 워크플로우가 생기긴 했지만, 지금의 시각 판정은 해상도가 낮다. 명백히 깨진 레이아웃은 잡아도, 몇 픽셀의 어긋남이나 겹침의 미묘한 옳고 그름까지는 잘 판정하지 못한다. 다음으로 규칙 하나가 전역으로 작용한다. `position: relative` 한 줄이 스태킹 컨텍스트를 바꿔 화면 전체의 겹침이 달라지는 언어라서, [코드 조각만 보고 결과를 예측하기 어렵다는 분석](https://dev.to/asafaeirad/why-css-is-so-hard-for-generative-ais-to-understand-17fo)이 나온다. 마지막으로, 내가 가장 근본적이라고 생각하는 이유인데, CSS는 틀려도 에러를 내지 않는다. 컴파일이 실패하지도 예외가 던져지지도 않고, 그저 어딘가 어긋나 보일 뿐이다. 에이전트의 자기수정은 실패 신호를 받아야 도는데, CSS는 그 신호를 주지 않는다. 앞에서 "동작하지 않는 코드는 건너뛸 수 없다"고 썼는데, CSS는 정확히 그 명제의 사각지대다. 틀린 채로도 동작한다. 트러블슈팅 정보가 인터넷에 많이 쌓여 있다는 점도 CSS에서는 힘이 약하다. 질문과 답은 방대하지만 해법이 각자의 문맥에 묶여 있어서, 다른 화면으로 잘 옮겨지지 않는다.

흥미로운 것은 이 약점과 도구 선택의 관계다. 구조와 스타일을 한 곳에 모으는 유틸리티 클래스 방식(Tailwind)이 모델이 다루기에 유리하다는 주장이 나온다. 다만 여기에는 과장이 섞이기 쉽다. Tailwind는 에이전트 이전에 사람의 이유(스타일이 마크업 옆에 붙어 있는 지역성)로 이미 자리를 잡았고, 기계 친화성은 나중에 발견된 성질에 가깝다. 그래도 방향은 시사적이라고 생각한다. 기계가 예측하기 좋은 형태의 코드가 선택압에서 유리해진다면, 미래 1에서 말한 "에이전트 친화적 타깃으로의 재편"은 혁명적인 교체가 아니라 이런 조용한 쏠림의 형태로 올 가능성이 높다. 그래서 CSS는 양쪽 모두에게 증거가 된다. 시각 검증이 충분히 자라기 전까지 화면의 마지막 몇 픽셀은 사람 몫으로 남을 가능성이 높다는 점에서는 고착 쪽에, 도구 선택이 이미 기계 쪽으로 기울기 시작했다는 점에서는 해체 쪽에.

두 번째 약점은 트러블슈팅 쪽이다. 이 해자는 스스로를 갉아먹는 구조다. 그 해자가 십수 년치인 것은 인간이 느리게 쓰기 때문이었다. 에이전트가 새로운 스택을 쓰기 시작하면 디버깅 사례와 텔레메트리가 기계 속도로 쌓인다. 15년짜리 해자가 아니라 2~3년짜리일 수 있다. 물론 처음 발 디딜 곳이 없다는 문제는 남으므로, 당분간 유효하되 영구적이지는 않다는 것이 정직한 평가일 것이다.

마지막으로, 이 세 겹이 한꺼번에 무너지는 경로도 하나 남아 있다. 에이전트의 디버깅이 정보 검색에서 추론으로 전환되는 순간이다. 특정 스택에 쌓인 사례 없이도 오류를 원리로부터 풀어내는 수준이 되면, 세 논거 모두 근거를 잃는다. 그런 시점이 올지 나는 모르겠고, 온다는 신호도 아직은 약해 보인다. 그 전까지 지금의 스택은 남을 것이다.

## 미래 4: 이긴 채로 투명해진다

여기까지는 "어느 스택이 이기는가"라는 질문이었고, 내 답은 고착이었다. 그런데 이 질문 자체가 핵심이 아닐 수 있다.

SQL의 사례를 보면 그렇다. SQL은 사실상 완승했다. 50년째 대체되지 않았고, 방금 세운 세 겹의 논거가 전부 성립한다. 학습 데이터가 가장 많고, 사람이 검수할 수 있고, 트러블슈팅 정보도 가장 많다. 그런데 "SQL 개발자"라는 직함은 거의 사라졌다. SQL을 다루는 일 자체가 사라진 것은 아니다. 그 일은 데이터 직군 안으로 흡수됐고, 일상의 SQL은 ORM과 생성 도구가 쓰게 되면서, SQL 지식은 몸값이 아니라 상식이 됐다. 그것만으로는 직업이 되지 않는다는 뜻이다. 반대편에는 COBOL이 있다. 마찬가지로 고착됐지만 아는 사람의 공급이 끊기면서, 은퇴한 개발자를 웃돈을 주고 다시 불렀다는 이야기가 주기적으로 나오는 시장이 됐다. 고착이라는 같은 결과에서, 그것을 아는 사람의 처지는 정반대로 갈린 셈이다.

세 겹의 논거를 다시 보면, 전부 "산출물이 어느 스택으로 나오는가"를 지키는 논거다. "그 스택 지식이 사람의 가격이 되는가"에 대해서는 셋 다 답하지 않는다. 검수 책임 논거조차 그렇다. 검수가 코드 리딩에서 행동 검증으로 이동하는 순간, 스택은 이긴 채로 아무도 읽지 않는 층이 된다. 기계가 쓰고 기계가 고치는, 말하자면 투명한 기판이다. 그런 세계에서 "React를 안다"는 지금 "SQL을 안다"만큼의 변별력이 될 것이다.

갈림길은 COBOL형이냐 SQL형이냐인데, 나는 SQL형의 가능성이 더 높다고 본다. COBOL이 사람의 가치를 지킨 것은 새 코드가 쓰이지 않는 언어가 되면서 아는 사람의 공급이 끊겼기 때문이다. 지금의 프론트엔드 스택은 반대다. 에이전트가 매일 새 코드를 쏟아내는 살아 있는 기판이고, 살아 있는 기판의 지식은 희소해지지 않는다.

그리고 이 지점에서 과거 절의 이중성이 되돌아온다. 추상화는 문제를 덮는 동시에 덮인 것을 잊게 만든다고 했다. 프레임워크가 웹의 기본기를 상식 아래로 밀어냈듯, 에이전트는 프레임워크 지식 자체를 상식 아래로 밀어낸다. 하강은 멈추는 것이 아니라 한 층 더 내려간다. 층이 쌓일 때마다 그 층의 전문가들은 이번 층은 다르다고 믿었지만, 매번 다음 층이 왔다.

## 90%라는 숫자

세 겹의 논거가 무너지는 경로까지 적고 나면, 쓰고 싶어지는 문장이 하나 있다. 디버깅이 추론으로 전환되는 그때쯤이면, 프론트엔드 개발자의 90%는 사라져 있을 것이라는 문장이다. 그 문장을 그대로 쓰기 전에, 이 90%가 무엇을 세는지부터 구분할 필요가 있다.

사라지는 것은 코딩 노동이다. [직군 경계를 다룬 글](https://yceffort.kr/2026/06/when-job-titles-blur)에서 썼듯 판단, 명세, 소유는 코드 생산이 공짜가 되어도 남고, 오히려 비싸진다. 무엇을 만들지 결정하고, 에이전트에게 "무엇이 일어나면 안 되는지"를 정확히 전달하고, 장애가 나면 새벽에 대응하는 역할이다. 오늘 직무의 상당 부분이 실제로 코드 타이핑이므로 "코딩 노동의 90%"는 방어할 수 있는 숫자다. 하지만 "직무의 90%"로 읽으면, 코드를 쓰고 고치는 노동의 소멸과 프론트엔드 개발자의 소멸을 같은 사건으로 취급하는 흔한 등식을 반복하게 된다. 둘은 같은 사건이 아니다.

다만 이 낙관에는 실패 전례가 있다. 활자 디자인이다. 판단과 안목이 핵심인 직종인데도, [새로운 활자체를 디자인하는 일은 더 이상 지속 가능한 풀타임 직업이 아니게 됐다는 관찰이 나온다](https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/). "판단은 사라지지 않는다"가 "판단으로 먹고사는 자리가 줄지 않는다"를 보장하지는 않는다는 뜻이다. 판단이 남아도, 그것을 돈 받고 파는 자리는 좁아질 수 있다.

반대 방향의 변수도 있다. 90%는 수요가 고정되어 있다는 전제 위의 숫자다. 역사적으로 생산 비용이 무너지면 수요가 팽창해 왔다. 웹사이트가 앱이 되고, 앱이 모든 것의 UI가 됐다. 석탄 효율이 오르자 석탄 소비가 오히려 늘었다는 Jevons의 역설이 소프트웨어에서도 반복된다면, 단위당 노동이 90% 줄어도 총량이 10배가 되면서 사람 수는 훨씬 덜 줄어든다. 물론 팽창 자체가 일어나지 않는 세계도 있다. UI가 더 많아지는 세계가 아니라 UI 자체가 에이전트와의 대화로 대체되는 세계라면, 팽창할 그릇부터 없다.

그래서 90%에 대한 정직한 답은 이 정도가 될 것 같다. 코딩 노동을 가리키면 아마 맞고, 직무 전체를 가리키면 가능하지만 미확정이다. 비교적 분명한 것은 하나다. 남는 10%가 지금의 10%와 같은 일이 아니라는 것이다.

그 10%의 모습을 조금 더 구체적으로 그려 보면 이렇다. 직함은 프로덕트 엔지니어로 수렴할 것이다. 코드 생산이 상식이 되면 "프론트엔드"라는 수식어는 SQL이 그랬듯 직함에서 떨어져 나가고, 판단과 명세와 소유를 쥔 사람이 화면까지 함께 책임지는 형태가 될 가능성이 높다. 다만 프론트엔드 전문성 자체는 사라진다기보다 응집할 것이다. 지금도 렌더링 파이프라인이나 번들러 내부를 진짜로 이해하는 사람은 극소수이고, 그 극소수는 스택을 만드는 벤더와 초대형 서비스의 플랫폼 팀에 모여 있다. 에이전트 이후에는 이 응집이 한 층 더 진행되어, 스택을 만드는 벤더, 엣지케이스가 일상인 초대형 서비스, 그리고 호출형 전문가 시장(지금의 웹 성능 컨설턴트나 접근성 감사가 그 원형이다) 세 곳 정도가 서식지로 남을 것 같다. 그들이 하는 일도 트러블슈팅만은 아닐 것이다. 수백 개의 에이전트가 화면을 망가뜨리지 못하게 막는 플랫폼과 검증 게이트를 설계하는 일에 가까울 것이다. SRE가 장애를 잡는 직군으로 시작해 플랫폼을 설계하는 소수 정예로 정착한 것과 비슷한 경로다.

다만 이 그림에는 불안정한 구석이 하나 있다. 엣지케이스를 잡는 능력은 평범한 케이스를 대량으로 잡아 본 경험에서 나오는데, 프로덕트 엔지니어로 흡수된 트랙에는 그 경험이 쌓이지 않는다. [판단이 왜 길러지지 않는지를 다룬 글](https://yceffort.kr/2026/06/learning-what-ai-cant-do)에서 일이 더 이상 공짜로 훈련시켜 주지 않는다고 썼는데, 그 문제의 직군 버전이다. 응집된 전문가 층은 재생산 사다리가 끊긴 채로 남고, 지금 세대가 물러나면 그 자리는 COBOL형 웃돈 시장이 될 가능성이 있다. 극소수로 남는 것과 안정적으로 유지되는 것은 다른 문제다.

정리하면 남는 10%는 판단과 명세와 소유로 재구성된, 인원은 줄되 남은 사람의 단가는 오르는 직무일 것이다. 그리고 그 자리가 "직업"으로 남을지 활자 디자인처럼 소수의 니치로 남을지는, 결국 수요의 방향이 결정할 것이다.

## 정리

- **과거의 층은 필요해서 쌓였다.** 그리고 쌓인 뒤에는 그 아래 전문성을 몰라도 되게 만들었다. 진화와 탈숙련화는 같은 역사의 앞면과 뒷면이다.
- **현재는 원점 회귀에 작성자 교체가 겹친 시점이다.** 서버 렌더링과 최소한의 JavaScript로 돌아온 바로 그때, 코드를 쓰는 손이 사람에서 에이전트로 바뀌고 있다.
- **스택은 남을 가능성이 높다.** 학습 데이터 관성 때문이 아니라, 검수 책임과 트러블슈팅 정보량 때문에. 검수는 건너뛸 수 있어도 동작하지 않는 코드는 건너뛸 수 없다. 이 구조가 무너지는 경로는 디버깅이 검색에서 추론으로 전환되는 것 하나뿐인데, 그 신호는 아직 약해 보인다.
- **직함은 흡수되고 전문성은 응집될 것이다.** 프로덕트 엔지니어로의 수렴, 벤더·플랫폼 팀·호출형 시장이라는 세 서식지, 그리고 그 층을 다시 길러낼 사다리가 끊겨 있다는 문제까지가 한 묶음이다.
- **다만 스택의 승리가 사람의 자리를 보장하지는 않는다.** SQL처럼 이긴 채로 투명해지는 경로의 가능성이 더 높다고 본다. 그래서 준비해야 할 것은 스택을 더 잘 아는 쪽이 아니라, 검증 인터페이스가 코드에서 행동으로 이동할 때 [그 검증을 설계하고 소유하는 쪽](https://yceffort.kr/2026/06/do-you-need-to-read-code)이라고 생각한다. 스택의 승리와 나의 생존을 혼동하지 않는 것. 이 글에서 하고 싶었던 말은 결국 그것이다.

> 함께 읽으면 좋은 글: [코드를 읽거나 설명할 줄 몰라도, 스펙을 만족하고 버그를 고칠 수 있다면 상관없을까](https://yceffort.kr/2026/06/do-you-need-to-read-code), [AI가 기획·개발·디자인의 경계를 지운다면, 무엇이 남는가](https://yceffort.kr/2026/06/when-job-titles-blur), [마지막으로 코드를 진지하게 읽은 게 언제인가](https://yceffort.kr/2026/06/learning-what-ai-cant-do). "AI 시대의 판단" 시리즈와 문제의식을 공유한다.

## 참고

- [The Descent: What Happened to the Frontend While You Weren't Watching (David Poblador i Garcia, 2026)](https://davidpoblador.com/deep-dives/what-happened-to-the-frontend/) (하강: 당신이 안 보는 사이 프론트엔드에 일어난 일)
- [Is AI causing a repeat of Frontend's Lost Decade? (Mauro Bieg, 2026)](https://mastrojs.github.io/blog/2026-05-23-is-AI-causing-a-repeat-of-frontends-lost-decade/) (AI는 프론트엔드의 잃어버린 10년을 반복시키고 있는가)
- [The Law of Leaky Abstractions (Joel Spolsky, 2002)](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) (새는 추상화의 법칙)
- [Why CSS Is So Hard for Generative AIs to Understand? (ASafaeirad, 2025)](https://dev.to/asafaeirad/why-css-is-so-hard-for-generative-ais-to-understand-17fo) (CSS는 왜 생성형 AI가 이해하기 어려운가)