# 프론트엔드는 경계를 다루는 직무가 되어간다

프론트엔드는 원래도 복잡했습니다. 브라우저마다 다른 렌더링, 상태 동기화, 성능, 접근성 — 화면 하나 제대로 만드는 데 신경 쓸 게 늘 많았습니다. 다만 그 복잡함은 대체로 한 방향을 향했습니다. 이 UI를 어떻게 만들까, 상태를 어떻게 관리할까, 클릭하면 무엇이 바뀌어야 할까.

그런데 요즘 질문의 축이 하나 더 늘고 있습니다. 이 UI는 서버에서 먼저 그릴까? 이 부분은 클라이언트 인터랙션이 꼭 필요한가? 이 데이터는 서버가 가져오는 게 맞나? 이 규칙의 주인은 누구인가? 이 값은 캐시해도 되는가? 이 값이 브라우저에 내려가도 되는가?

David Poblador의 [「The Descent — What Happened to the Frontend While You Weren't Watching」](https://davidpoblador.com/deep-dives/the-descent/)을 읽고 꼬리에 꼬리를 문 질문과 답변 끝에 남은 결론은 하나였습니다. 프론트엔드는 화면을 그리는 직무에서 경계(boundary)를 다루는 직무로 바뀌어 가고 있습니다.

## 복잡함은 우연이 아니었다

이 글이 복기하는 역사는 익숙합니다. 페이지 일부만 바꾸고 싶어 jQuery가 나왔고, UI 상태 동기화가 지옥이라 React가 나왔고, JSX 때문에 Babel과 webpack이, 빌드가 느려서 Vite가, SPA의 빈 화면과 SEO 문제 때문에 SSR과 meta-framework가 나왔습니다. 저자의 표현을 빌리면 모든 도구는 "실제 상처 위에 생긴 흉터"입니다.

그리고 저자는 최신 흐름을 이렇게 진단합니다. 이제 업계는 다시 서버에서 HTML을 렌더링하고, 브라우저로 보내는 JS를 최소화하고, 웹 플랫폼 자체를 활용하는 방향으로 움직이고 있다고요. Astro, islands architecture, React Server Components, htmx가 그 증거로 등장합니다.

한 가지 짚고 넘어가야 할 게 있습니다. 요즘 프론트엔드의 변화를 흔히 AI 탓으로 돌리지만, 여기서 AI의 자리는 생각보다 좁습니다. 이제 프론트 코드의 상당 부분을 LLM이 만드는 건 맞습니다. 하지만 그 코드조차 React와 빌드 체인과 렌더링 규칙이라는 앞선 레이어를 그대로 전제합니다. AI는 이 복잡한 스택을 재편한 게 아니라 그 위에 얹혔을 뿐입니다. 그래서 이 글이 다루는 변화의 실제 동력은 AI가 아니라, 렌더링을 어디서 하느냐가 다시 움직이고 있다는 사실입니다. 이 점을 놓치면 다음 이야기가 엉뚱하게 들립니다.

## "회귀"가 아니라 보정 운동이다

여기서 잠깐 멈춰야 합니다. 이 진단을 "이제 다들 HTML만 쓴다", "클라이언트 프레임워크 시대는 끝났다"로 읽으면 과장입니다. 현업은 여전히 React와 빌드 체인과 meta-framework라는 유산 위에서 돌아갑니다. 지난 20년의 레이어가 사라진 게 아닙니다.

실제로 일어나는 일은 주류 교체가 아니라 **주류 스택 내부의 보정 운동**입니다. 같은 스택 안에서 JS 총량을 줄이고, 서버에서 더 처리하고, 인터랙션이 꼭 필요한 부분에만 JS를 붙이는 쪽으로 무게중심이 옮겨가고 있습니다.

"JS를 최소화한다면서 일부를 hydrate한다는 건 모순 아닌가"라는 의문도 같은 오해에서 나옵니다. 여기서 최소화는 JS를 0으로 만든다는 뜻이 아닙니다. 예전 전체 SPA 방식보다 훨씬 적은 JS만 보내고, 나머지는 서버가 만든 HTML로 처리한다는 뜻입니다. selective hydration은 hydration을 없애는 게 아니라 **hydration 대상을 줄이는** 전략입니다.

물론 이 전략이 어디서나 통하는 건 아닙니다. 블로그, 문서 사이트, 상품 상세 페이지처럼 읽기 중심인 곳에서는 강력하지만, 복잡한 SaaS 대시보드나 드래그 앤 드롭 편집기, 실시간 협업 툴에서는 효과가 제한적입니다. 보편 법칙이 아니라 페이지 성격에 따라 강하게 먹히는 전략입니다.

## 백엔드의 대세 전환이 아니라 프론트엔드의 관할 확장이다

그럼 서버로 무게가 옮겨간다는 건 JS/TS 프레임워크가 백엔드를 접수한다는 뜻일까요? 아닙니다. Next.js가 Go나 Java로 짠 코어 백엔드를 대체하는 일은 일어나지 않고 있습니다.

현실의 많은 서비스는 세 층으로 나뉩니다. 코어 백엔드(Go, Java, Kotlin, Rust 등), UI에 인접한 서버 레이어(Next.js, Nuxt, SvelteKit, Astro가 담당하는 BFF/SSR/렌더링), 그리고 브라우저 레이어. 프론트 서버는 백엔드 전체를 대체하는 계층이 아니라 UI에 가까운 렌더링·조합 계층입니다.

즉 이 흐름의 본질은 백엔드의 주류 전환이 아니라 **프론트엔드의 관할 확장**입니다. 프론트엔드 개발자가 브라우저 코드만 다루던 데서, 렌더링 서버와 데이터 조합 계층과 간단한 서버 오케스트레이션까지 다루게 되는 것입니다.

다만 이건 어디까지나 방향이지 현재의 보편이 아닙니다. BFF나 렌더링 서버를 직접 운영하는 프론트엔드 개발자는 아직 소수고, 대부분의 현업은 여전히 브라우저 코드가 중심입니다. 이 글에서 말하는 변화는 이미 완료된 사실이 아니라, 최전선에서 시작해 서서히 번지고 있는 흐름으로 읽어야 합니다.

예전의 관할과 지금의 관할을 나란히 놓으면 이렇습니다. 달라진 건 상자가 아니라 선입니다. 예전 프론트엔드에게 경계란 API 호출 하나뿐이었지만, 지금은 네 개의 경계선 위에서 판단을 내립니다.

![](https://cdn.hashnode.com/uploads/covers/62eb589e16f9480a9dac77d0/5237cb41-38d8-4e0a-882e-b3e0abd62b2c.svg align="center")

그리고 이 확장된 관할은 실제로 위험합니다. React 팀은 2025년 말 [React Server Components의 인증 없는 원격 코드 실행 취약점(CVE-2025-55182)](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)을 공지했고, SvelteKit도 [SSRF와 remote functions 관련 문제](https://svelte.dev/blog/cves-affecting-the-svelte-ecosystem)를 인정했습니다. 주목할 대목은 깨진 곳이 "일부만 hydrate한다"는 아이디어가 아니라 그걸 구현한 서버 프로토콜 계층이었다는 점입니다. 서버-클라이언트 경계를 자동으로 이어주는 마법 계층은 원래 공격면이 넓습니다. 그래서 partial hydration은 남되, server actions 같은 서버 RPC 계층은 보안에 민감한 조직일수록 더 보수적으로 다뤄질 가능성이 큽니다.

## 가장 현실적인 위험: 그림자 백엔드가 된 BFF

관할 확장에서 가장 먼저 터지는 사고는 보안 취약점이 아니라 이것입니다. **어설픈 BFF가 코어 백엔드 위에 얹힌 그림자 백엔드가 되는 것.**

BFF가 잘못 커지면 비즈니스 규칙이 코어 백엔드가 아니라 BFF에 복제됩니다. 할인, 권한, 가격, 주문 가능 여부 같은 규칙이 두 군데로 찢어지고, 화면과 실제 시스템 상태가 어긋나고, 캐시가 정합성과 권한을 깨뜨리고, 장애가 나면 책임 소재가 흐려집니다. 코어 백엔드가 공들여 지켜온 것들이 그 위에 얹힌 어설픈 레이어 하나로 무너질 수 있습니다.

경계선은 명확합니다. BFF는 조립기여야 하고, 판정자가 되면 안 됩니다.

| BFF가 해도 되는 일 (조립기) | BFF가 하면 위험한 일 (판정자) |
| --- | --- |
| 화면용 데이터 조합 | 결제·주문·환불 규칙 결정 |
| 포맷 변환 | 최종 권한 판정 |
| page-level prefetch | 재고·가격·한도 계산의 원본 로직 |
| SEO 메타데이터 조립 | 감사로그가 필요한 mutation |
| 세션·locale·A/B 실험 같은 UI 문맥 | 강한 정합성이 필요한 상태 전이 |

## 그래서 이제 무엇을 알아야 하나

이 경계 판단을 하려면 프론트엔드 개발자에게도 최소한의 시스템 감각이 필요해졌습니다. 깊은 백엔드 전문가가 되라는 뜻이 아닙니다. 다음 다섯 영역에 대한 판단력이면 됩니다.

*   **웹 실행 모델** — 브라우저에서만 가능한 것과 서버에서만 가능한 것, SSR/CSR/hydration의 차이
    
*   **보안과 신뢰 경계** — 브라우저는 신뢰할 수 없고, 최종 권한 판정은 서버 책임이며, secret은 절대 클라이언트에 내려가면 안 된다
    
*   **로직 소유권** — 돈·권한·상태 전이는 누가 소유하는가, 화면용 표현 규칙과 비즈니스 규칙의 차이
    
*   **성능 모델** — 읽기 중심인지 상호작용 중심인지, 캐시 가능한 데이터인지, 서버 조합이 왕복을 줄이는지
    
*   **API 기본기** — 인증과 인가의 차이, idempotency, stale data와 eventual consistency
    

UI 구현 능력이 덜 중요해졌다는 말이 아닙니다. 그 위에 이 다섯 가지 판단이 얹혔다는 말입니다.

판단 흐름을 그림으로 정리하면 이렇습니다. 새 기능을 만들 때 신경 써야 할 경계 지점들입니다.

![](https://cdn.hashnode.com/uploads/covers/62eb589e16f9480a9dac77d0/025e24d3-d0af-4855-a374-8d2d6ce8366f.svg align="center")

## 배포는 쉬워졌지만 엔지니어링은 쉬워지지 않았다

마지막 반전이 하나 남아 있습니다. 이렇게 복잡해졌지만 배포는 쉬워지지 않았느냐고 물을 수 있습니다. Git에 푸시하면 preview URL이 나오고, CDN과 HTTPS가 기본으로 따라옵니다.

맞습니다. 하지만 쉬워진 건 정확히 **배포 UX**까지입니다. 빌드 체인, client/server 분리, 캐시와 재검증 판단, 의존성 취약점 관리, 관측 가능성, 프론트 서버와 코어 백엔드 사이의 책임 분리 — 이것들은 여전히 어렵거나 오히려 더 어려워졌습니다. 복잡성은 사라진 게 아니라 다른 위치로 이동했습니다.

> FTP는 불편했지만 단순했고, 지금은 배포는 편하지만 시스템은 훨씬 덜 단순합니다.

## 흉터는 지워지지 않는다, 관할이 넓어질 뿐

「The Descent」의 핵심 통찰은 유효합니다. 프론트엔드의 복잡함은 우연한 혼돈이 아니라 실제 문제를 해결해온 결과라는 것. 다만 그 끝에 붙은 "옛 웹으로의 회귀"는 절반만 맞습니다. 일어나고 있는 건 회귀가 아니라 보정이고, 축소가 아니라 확장입니다.

그 확장의 무게는 결국 사람에게 옵니다. 프론트엔드 개발자는 이제 렌더링 위치, client/server 경계, 데이터 조합 위치, BFF의 책임 범위, 보안과 정합성의 경계까지 조금씩 판단하기 시작했습니다. 화면을 그리는 직무에서 경계를 다루는 직무로 — 이것이 우리가 보지 않는 사이 프론트엔드에 일어나고 있는 일입니다.