2026 프론트엔드 기술 스택 선택 가이드

React·Next.js·Vue·Svelte 프레임워크 선택 기준과 실무

이 장을 읽기 전에: HTML/CSS의 기본 구조(태그, 셀렉터)와 JavaScript의 기초(변수, 함수, 이벤트)를 이해하고 있으면 읽기 쉽다. 자신 없는 경우에는 제2장의 TypeScript/JavaScript 항목을 먼저 읽는 것을 권장한다.

웹 애플리케이션에서, 사용자가 직접 눈으로 보고 조작하는 부분을 프론트엔드라고 부른다. 식당으로 말하자면 "홀과 서빙"에 해당하는 부분이다. 음식이 아무리 맛있어도(백엔드가 아무리 뛰어나도), 메뉴를 읽을 수 없거나 주문 방법을 모른다면(UI가 나쁘다면), 손님은 돌아가 버린다.

이 장에서는 프론트엔드 개발의 전체 그림과, 프레임워크 선정의 판단 기준을 정리한다.

3.1 프론트엔드의 전체 그림

이 섹션이 답하는 질문: 프론트엔드 개발에는 어떤 접근 방식이 있는가?

왜 필요한가

2000년대의 웹사이트는, 서버가 HTML을 생성해서 브라우저에 반환하는 단순한 구조였다. 그러나 Gmail(2004년)과 Google Maps(2005년)의 등장으로, "페이지 전체를 다시 읽어들이지 않고 부분적으로 업데이트하는" 풍부한 웹 앱이 요구되게 되었다. 이 수요에 부응하기 위해 프론트엔드 기술은 급속히 진화하고 복잡해졌다.

2026년 시점에서는 복수의 아키텍처 패턴이 공존하고 있으며, 프로젝트의 성격에 따라 적절한 것을 선택할 필요가 있다.

� 국내 서비스 패턴: 네이버·카카오·쿠팡 등 검색 유입이 중요한 서비스는 SSR/SSG를, 사내 관리도구·B2B SaaS 대시보드는 SPA를 많이 채택한다. 이커머스(쿠팡·무신사·29CM)는 ISR을 활용해 상품 페이지 성능과 최신성을 동시에 잡는 구성이 많다.

실무에서의 주의점

⚠️ "일단 SPA"는 위험하다. SEO가 불필요한 관리 화면이라면 SPA로 문제없지만, 검색 엔진 유입이 중요한 서비스에서는 SSR이나 SSG를 검토해야 한다. 국내 주요 검색 엔진인 네이버는 Googlebot과 크롤링 방식이 다를 수 있으므로, SEO 전략 수립 시 네이버 서치어드바이저 기준도 함께 확인한다.

정리

프론트엔드 아키텍처는 하나로 결정되지 않는다. SEO의 필요성, 업데이트 빈도, 인터랙티브성의 3가지를 축으로 판단한다. 2026년 시점의 주류는 서버 측에서 먼저 렌더링하면서 필요한 부분만 클라이언트에서 동작시키는 하이브리드형이다.

3. 프레임워크 선정

이 섹션이 답하는 질문: React, Vue, Svelte… 결국 어느 것을 선택하면 좋은가?

왜 필요한가

프론트엔드 프레임워크 없이 복잡한 웹 앱을 만드는 것은 설계도 없이 건물을 짓는 것과 같다. 상태 관리, 컴포넌트 재이용, 라우팅, 데이터 취득…… 이것들을 매번 제로부터 구현하는 것은 비현실적이며, 버그의 온상이 된다.

프레임워크는 이러한 공통 과제의 모범 사례를 패키지화한 것이다.

선정 판단 기준

막힐 때의 사고 방식

채용 시장, 정보량, 기존 라이브러리 자산을 중시한다면 → React / Next.js

읽기 쉬움과 학습 속도를 중시한다면 → Vue / Nuxt

작게 시작해서 가볍게 만들고 싶다면 → Svelte / SvelteKit

콘텐츠 중심으로 JavaScript를 너무 많이 보내고 싶지 않다면 → Astro

� 국내 채용 현황: 원티드·프로그래머스 채용 공고 기준으로 React(Next.js) 수요가 압도적으로 높다. Vue는 기존 서비스 유지보수나 중견 기업에서 여전히 요구되며, Angular는 금융·공공·엔터프라이즈 레거시 환경에서 사용된다. Svelte와 Astro는 채용보다 개인 프로젝트·사이드 프로젝트에서 인기가 높다.

실무에서의 주의점

⚠️ 프레임워크의 인기만으로 선택하지 않을 것. SEO, 인증, 관리 화면, 실시간성, 디자인 시스템, 팀 경험 쪽이 실무에서는 훨씬 중요하다.

⚠️ Next.js를 선택하는 경우는 App Router와 Server Components를 전제로 생각하면 좋다. 한편, 모든 화면을 Next.js로 통일할 필요는 없다. 단순한 관리 화면이나 임베디드 앱에서는 Vite 기반 SPA가 더 단순할 수도 있다.

정리

2026년 시점에서도, 가장 인기 있는 기술 = 모든 안건의 정답은 아니다. React / Next.js는 무난한 선택지이지만, Vue / Nuxt, Svelte / SvelteKit, Astro에는 각각 명확한 강점이 있다. 중요한 것은 "이 안건에서 무엇을 최적화하고 싶은가"를 먼저 결정하는 것이다.

① Next.js App Router와 Server Components

이 섹션이 답하는 질문: Server Components란 무엇인가? Next.js의 설계는 어떻게 바뀌었는가?

왜 필요한가

기존의 React 프론트엔드에서는 데이터 취득도 화면 표시도 클라이언트 측으로 치우치기 쉬웠다. 그 결과 초회 표시가 무거워지기 쉽고, SEO나 저속 회선에서 불리해지는 경우가 있었다.

Next.js의 App Router는, 어디까지를 서버에서 렌더링하고 어디서부터를 클라이언트에서 동작시키는가를 명시적으로 나누기 쉽게 했다. 이것이 현재의 Next.js를 이해하는 데 있어서 중요한 변화다.

React의 Server Components는 React 공식에서는 "번들 전에 별도 환경에서 먼저 렌더링되는 새로운 종류의 컴포넌트"라고 설명되어 있다. Next.js App Router에서는 이 사고방식이 기본 설계에 내장되어 있다.

---

// app/products/page.tsx — Server Component (기본값)

// 서버에서 실행: DB 직접 접근, API 호출 가능

import ProductGrid from './product-grid';

export default async function Page() {

const products = await fetchProducts(); // 서버에서 직접 데이터 취득

return <ProductGrid products={products} />;

}

// app/products/product-grid.tsx — Client Component

// 브라우저에서 실행: 상태, 이벤트 처리 가능

'use client';

import { useState } from 'react';

export default function ProductGrid({ products }) {

const [query, setQuery] = useState('');

return <>{/* 검색 입력이나 정렬 등의 대화 처리 */}</>;

}

---

선정 판단 기준

Server Components가 특히 유효한 장면

초회 표시를 가볍게 하고 싶다

데이터 취득을 서버 측으로 모으고 싶다

클라이언트에 보내는 JavaScript를 줄이고 싶다

Client Components나 기존형 클라이언트 상태 관리가 필요한 장면

폼 입력, 모달, 드래그, 키보드 조작 등 대화 중심의 UI

실시간 업데이트, 낙관적 업데이트, 오프라인 대응

브라우저 API에 강하게 의존하는 기능

⚠️ Next.js 공식 문서에서도 Layouts와 Pages는 App Router에서 Server Components가 기본이다. 먼저 서버에서 처리할 수 있는 부분을 Server Components에 두고, 필요한 곳만 Client Components로 분리하면 정리하기 쉽다.

실무에서의 주의점

⚠️ Server Components는 "무엇이든 안전하다"는 의미가 아니다. Next.js는 server-only에 의한 보호와 빌드 시 체크를 제공하고 있지만, 2025년 12월에는 App Router / RSC에 관련된 중대한 보안 어드바이저리 CVE-2025-66478도 공개되었다. App Router를 사용한다면 패치 적용을 지속할 것.

⚠️ Next.js 16에서는 Turbopack이 신규 프로젝트의 기본 번들러가 되었으며, Cache Components가 도입되었다. 이것들은 편리하지만, 먼저 이해해야 할 기본은 Server Components와 Client Components의 경계다.

정리

Next.js의 현재 위치는 "React를 브라우저에서 전부 동작시키는" 것이 아니라 서버와 클라이언트의 책무를 나누는 설계에 있다. Server Components는 강력하지만, 대화적 UI는 여전히 Client Components가 담당한다. 이 경계를 올바르게 설계할 수 있는가가 Next.js를 제대로 활용할 수 있는지를 결정한다.

3. 상태 관리의 사고 방식

이 섹션이 답하는 질문: "상태"란 무엇인가? 왜 관리가 필요한가?

왜 필요한가

웹 애플리케이션에는 "상태(state)"가 있다. 로그인 중인 사용자 이름, 장바구니의 내용물, 폼의 입력값, 다크 모드의 ON/OFF — 이것들은 모두 상태다.

작은 앱에서는 상태 관리에 어려움을 겪지 않지만, 앱이 성장하면 "이 화면에서 변경한 값이 다른 화면에 반영되지 않는다", "같은 데이터를 여러 곳에서 가지고 있어 불일치가 발생한다"는 문제가 발생한다.

상태는 다음 3가지로 나누면 정리하기 쉽다.

선정 판단 기준

⚠️ 먼저 로컬 상태로 닫을 수 없는지를 생각한다. 다음으로 서버 상태로 취급할 수 없는지를 생각한다. 글로벌 상태 라이브러리는 마지막에 검토한다.

React 계열에서 자주 쓰이는 선택지는 다음과 같다.

---

// 상태 관리 선택 판단 흐름 — 실무 예시

// 1단계: 로컬 상태로 닫을 수 있는가?

function SearchBar() {

const [query, setQuery] = useState(''); // ✅ 로컬 상태로 충분

return <input value={query} onChange={e => setQuery(e.target.value)} />;

}

// 2단계: 서버 데이터는 TanStack Query로

function ProductList() {

const { data, isLoading } = useQuery({

queryKey: ['products'],

queryFn: fetchProducts,

staleTime: 60_000, // 1분간 캐시 유지

});

// ...

}

// 3단계: 공유 UI 상태만 Zustand

import { create } from 'zustand';

const useUIStore = create(set => ({

sidebarOpen: true,

theme: 'light' as const,

toggleSidebar: () => set(s => ({ sidebarOpen: !s.sidebarOpen })),

}));

---

⚠️ Next.js App Router에서는 읽기 중심의 데이터 취득을 Server Components로 모으기 쉽다. 단, 실시간 업데이트, 클라이언트 캐시, 낙관적 업데이트가 필요하다면 TanStack Query 같은 도구는 지금도 유효하다.

정리

상태 관리는 "로컬 → 서버 → 공유 UI"의 순서로 작게 생각한다. 처음부터 큰 상태 관리 라이브러리를 넣는 것보다, 어떤 종류의 상태인지를 분별하는 것이 더 중요하다.

4. 스타일링 방법

이 섹션이 답하는 질문: CSS 작성 방법에는 어떤 선택지가 있으며, 무엇을 선택해야 하는가?

왜 필요한가

웹 앱의 외관을 정돈하는 것이 CSS(Cascading Style Sheets)다. 소규모라면 순수 CSS로 문제없지만, 앱이 커지면 "클래스명 충돌", "사용되지 않는 스타일의 누적", "디자인 일관성 붕괴"가 발생한다. 이러한 문제를 해결하기 위해 다양한 스타일링 방법이 생겨났다.

선정 판단 기준

Tailwind CSS v4: 속도와 일관성을 우선하는 신규 개발용. 2025년부터 CSS-first 설정 방식으로 전환

CSS Modules: 순수 CSS에 가까운 사고 방식으로 진행하고 싶은 팀용

vanilla-extract: 디자인 토큰을 타입 안전하게 관리하고 싶을 때

CSS-in-JS(Emotion·styled-components): 기존 자산이 있는 경우. RSC와의 궁합에 주의

� 한국어 폰트 최적화: 국내 서비스에서는 Pretendard(무료 오픈소스)나 Noto Sans KR이 표준 한국어 폰트로 자주 사용된다. 한글 폰트는 용량이 크므로 서브셋 폰트 적용이 필수다.

---

/* Tailwind CSS v4 + 한국어 환경 최적화 */

@import "tailwindcss";

@theme {

--font-sans: "Pretendard Variable", "Pretendard", ui-sans-serif, system-ui;

}

@layer base {

html {

/* 한국어 줄바꿈 최적화 — 단어 단위가 아닌 음절 단위 */

word-break: keep-all;

overflow-wrap: break-word;

}

}

---

⚠️ Tailwind CSS는 편리하지만, CSS의 기초 지식을 대체하는 것이 아니다. display, flex, grid, 여백, 레이아웃, 셀렉터의 이해는 여전히 필요하다.

⚠️ AI 생성 UI는 Tailwind로 나오는 경우가 많지만, 그것만을 이유로 Tailwind를 선택할 필요는 없다. 팀 표준으로 변환하는 것을 전제로 사용해도 좋다.

정리

신규 안건에서는 Tailwind CSS가 유력한 후보이지만, 유일한 정답은 아니다. 장기 유지보수까지 생각한다면, 팀이 계속 읽을 수 있는 작성 방법인가를 우선하여 선택해야 한다.

5. 빌드 툴체인

이 섹션이 답하는 질문: 왜 작성한 코드를 그대로 브라우저에서 동작시키지 않는가?

왜 필요한가

현대의 프론트엔드 개발에서는 TypeScript, JSX, 최신 JavaScript 구문, CSS 프리프로세서 등 브라우저가 직접 이해할 수 없는 형식으로 코드를 작성한다. 이것들을 "브라우저가 실행할 수 있는 형태"로 변환하는 공정이 빌드다.

공장에 비유하자면, 원재료(TypeScript, JSX)를 가공하여 제품(최적화된 JS/CSS/HTML)을 출하하는 생산 라인이 빌드 툴체인이다.

선정 판단 기준

Next.js를 사용하는 경우
Next.js 16에서는 Turbopack이 신규 프로젝트의 기본 번들러가 되었다. 먼저 프레임워크 표준을 그대로 사용하고, 문제가 발생한 후 개별 설정을 생각하는 편이 좋다.

Next.js 이외의 SPA / SSG
Vite를 기준으로 생각하는 것이 알기 쉽다. React, Vue, Svelte 모두 도입하기 쉽고 공식 가이드도 충실하다.

린트 / 포맷
ESLint 플러그인 자산에 강하게 의존한다면 ESLint + Prettier. 도구를 줄이고 싶다면 Biome를 검토한다.

� 국내 스타트업 표준 구성: 토스·당근마켓·카카오 기술 블로그에서 공개된 스택 기준으로, Next.js(App Router) + TypeScript + Tailwind CSS + ESLint + Prettier 조합이 신규 프로젝트의 사실상 표준이다.

실무에서의 주의점

⚠️ 빌드 속도 비교는 프로젝트 구성으로 크게 달라진다. 벤치마크 기사만으로 판단하지 말고 실제 리포지토리에서 계측할 것.

⚠️ 도구를 교체하기 전에, 의존 관계 삭감, 코드 분할, 불필요한 플러그인 제거 쪽이 더 효과적인 경우도 많다.

정리

2026년 실무에서는 Next.js라면 Turbopack, 그 외는 Vite라는 정리가 알기 쉽다. 단, 중요한 것은 "가장 빠른 도구를 선택하는 것"보다 팀이 이해할 수 있는 구성을 유지하는 것이다.

6. 테스트 전략

이 섹션이 답하는 질문: 프론트엔드에서는 무엇을 어떻게 테스트하면 좋은가?

왜 필요한가

"화면을 클릭해서 눈으로 확인한다"는 것은 가장 원시적인 테스트다. 코드가 변경될 때마다 모든 화면을 수동으로 확인하는 것은 현실적이지 않다. 자동 테스트를 작성함으로써 변경할 때마다 "망가지지 않았는지"를 기계적으로 검증할 수 있다.

선정 판단 기준

⚠️ 모든 것을 완벽하게 테스트하려고 하지 않을 것. 먼저 망가지면 곤란한 로직과 주요 플로에 집중한다.

실무에서는 다음 조합이 현실적이다.

Vitest로 로직을 지킨다

Testing Library로 주요 컴포넌트를 지킨다

Playwright로 로그인, 결제, 전송 등의 중요 플로를 지킨다

---

// Vitest — 비즈니스 로직 단위 테스트 예시

import { describe, it, expect } from 'vitest';

import { formatKoreanPrice } from './utils';

describe('한국 원화 포맷', () => {

it('1000 → "1,000원"', () => {

expect(formatKoreanPrice(1000)).toBe('1,000원');

});

it('10000 → "1만원"', () => {

expect(formatKoreanPrice(10000)).toBe('1만원');

});

it('0 → "0원"', () => {

expect(formatKoreanPrice(0)).toBe('0원');

});

});

// Playwright — 로그인 E2E 테스트 (국내 소셜 로그인 포함)

import { test, expect } from '@playwright/test';

test('카카오 로그인 버튼이 표시되는가', async ({ page }) => {

await page.goto('/login');

await expect(page.locator('[data-testid="kakao-login-btn"]')).toBeVisible();

await expect(page.locator('[data-testid="naver-login-btn"]')).toBeVisible();

});

test('이메일 로그인 후 대시보드 이동', async ({ page }) => {

await page.goto('/login');

await page.fill('[name="email"]', 'test@example.com');

await page.fill('[name="password"]', 'Test1234!');

await page.click('[type="submit"]');

await expect(page).toHaveURL('/dashboard');

});

---

실무에서의 주의점

⚠️ AI가 생성한 코드도 통상 코드와 같은 품질 게이트를 통과시킨다. "AI가 작성했으니 별도로 취급한다"는 것이 아니라, 테스트, 정적 분석, 접근성 확인, 리뷰로 통상대로 흘리는 편이 안전하다.

� 국내 서비스 접근성 요건: 장애인차별금지법(장차법) 및 웹 접근성 인증(WA 인증)이 공공기관·대형 포털에 의무화되어 있다. WCAG 2.1 AA 수준을 기준으로, 스크린 리더(센스리더, 낭독 프로그램) 호환성과 키보드 완전 탐색 가능 여부를 확인한다.

정리

프론트엔드의 테스트는 Vitest + Playwright를 축으로 생각하면 정리하기 쉽다. 거기에 컴포넌트 테스트와 접근성 확인을 필요에 따라 추가해 나가는 것이 실천적이다.

① AI를 활용한 UI 시작

이 섹션이 답하는 질문: 프로토타이핑에서 본 구현까지의 시간을 어떻게 단축하는가?

왜 필요한가

디자인 안에서 컴포넌트 구현까지를 매번 제로부터 손으로 작성할 필요가 없어지고 있다. 최근에는 자연어나 이미지에서 UI의 초안을 만드는 도구가 증가하고 있으며, 시작의 속도를 높이기 쉽다.

선정 판단 기준

⚠️ 이러한 도구들은 시작을 빠르게 하는 도구로 생각하면 좋다. 본번 품질을 그대로 보증하는 도구가 아니다.

실무에서의 주의점

⚠️ AI 생성 UI는 "드래프트"이지 "완성품"이 아니다. 접근성, 상태 관리, 데이터 취득, 인증, 에러 핸들링, 디자인 정합성은 인간이 최종 책임을 가지고 확인할 필요가 있다.

⚠️ 가장 효과가 높은 사용법은, 최초의 초안을 AI로 만들고, 거기서부터 팀의 디자인 시스템과 구현 규약으로 맞춰가는 방법이다. AI가 생성한 Tailwind 클래스나 컴포넌트 구조를 자사 디자인 토큰 기준으로 정제하는 것이 핵심이다.

정리

AI 도구는 UI 시작을 크게 빠르게 한다. 단, 실무에서 가치가 나오는 것은 생성 속도 그 자체가 아니라, 생성물을 설계·품질 기준으로 맞춰서 마무리할 수 있는 것이다.

7. 성능 최적화의 기본

이 섹션이 답하는 질문: 웹 앱의 "빠름"을 어떻게 측정하고, 어떻게 개선하는가?

왜 필요한가

성능은 UX에 직결되며, 검색 유입이나 전환율에도 영향을 미친다. 또한 최근에는 "읽어들이는 빠름"뿐만 아니라 조작에 얼마나 빠르게 응답하는가도 중요해지고 있다.

Google이 공개하고 있는 Core Web Vitals가 대표적인 기준이다.

� 국내 네트워크 환경: 한국은 세계 최고 수준의 인터넷 속도를 가지고 있어, 데스크탑 환경에서는 LCP 문제가 두드러지지 않을 수 있다. 그러나 지하철·엘리베이터 등 네트워크 품질이 낮은 모바일 환경을 고려하면 최적화는 여전히 중요하다. 또한 Google 검색 순위에 Core Web Vitals가 반영되므로 SEO 관점에서도 무시할 수 없다.

⚠️ web.dev에서도 Core Web Vitals는 실제 사용자 계측을 중시하고 있다. Lighthouse는 출발점으로서 유효하지만, 최종 판단은 필드 데이터(CrUX 보고서, Google Search Console)로 해야 한다.

정리

성능은 "측정하고 나서 개선한다"가 철칙. Chrome DevTools의 Lighthouse나 PageSpeed Insights로 현상을 측정하고, Core Web Vitals의 목표값을 기준으로 우선순위를 매겨 개선한다. 먼저 이미지 최적화와 코드 분할부터 시작하는 것이 효과적이다.

8. AI 시대의 프론트엔드 개발 철학 (2026년)

이 섹션이 답하는 질문: AI 도구 시대에, 프론트엔드 엔지니어에게 요구되는 스킬은 무엇인가?

AI의 보급으로 프론트엔드 개발의 작업 배분이 바뀌었다.

선정 판단 기준

AI를 활용할 때는 다음 순서로 생각하면 무너지기 어렵다.

무엇을 자동화해도 좋은지 결정한다 — 예를 들어 UI 초안, Storybook Story 작성, 테스트의 초안 등.

무엇은 인간이 반드시 확인하는지 결정한다 — 접근성(장차법 대응), 상태 관리, 설계 경계, 보안 등.

품질 게이트를 통상대로 통과시킨다 — 린트, 타입 체크, 테스트, 리뷰를 생략하지 않는다.

실무에서의 주의점

⚠️ AI에 의해 구현 속도가 높아질수록, 정리되지 않은 UI나 그때그때의 상태 관리도 증가하기 쉽다. 속도의 향상은 그대로 품질의 향상을 의미하지 않는다.

⚠️ 프론트엔드에서 정말 가치가 있는 것은, 코드를 빨리 작성하는 것보다 복잡성을 제어하는 것이다. AI를 사용해도 책무 분리, 설계 일관성, 접근성의 중요성은 내려가지 않는다.

정리

AI 시대의 프론트엔드에서는 구현 그 자체보다도 생성물의 품질을 간파하고 설계로 되돌릴 수 있는 힘이 중요해진다. AI는 구현 속도를 높이지만, 무엇을 만들지를 결정하는 책임까지는 떠맡아 주지 않는다.

9. 한국 서비스 프론트엔드 특이사항

이 섹션은 원문에 없는 내용으로, 한국 개발 현장에 맞게 보완한 내용이다.

국내 소셜 로그인 연동

한국 서비스에서는 글로벌 OAuth(Google, GitHub)뿐만 아니라 카카오·네이버·애플 로그인이 거의 필수다.

---

// 카카오 로그인 연동 예시 (next-auth 활용)

// providers/kakao.ts

import KakaoProvider from 'next-auth/providers/kakao';

export const kakaoProvider = KakaoProvider({

clientId: process.env.KAKAO_CLIENT_ID!,

clientSecret: process.env.KAKAO_CLIENT_SECRET!,

});

// 네이버 로그인은 커뮤니티 provider 또는 직접 OAuth 구현 필요

// 공식 next-auth provider 없음 (2026년 시점)

---

한국 결제 UI 패턴

---

// 토스페이먼츠 결제창 연동 (프론트엔드 측)

import { loadTossPayments } from '@tosspayments/payment-sdk';

async function handlePayment(orderId: string, amount: number) {

const tossPayments = await loadTossPayments(

process.env.NEXT_PUBLIC_TOSS_CLIENT_KEY!

);

await tossPayments.requestPayment('카드', {

amount,

orderId,

orderName: '주문 상품',

successUrl: `${window.location.origin}/payment/success`,

failUrl: `${window.location.origin}/payment/fail`,

});

}

---

다국어(i18n) - 한국어 특수 처리

---

// 한국어 복수형·경어 처리 — 영어와 다른 국어 규칙

// next-intl 활용 예시

// messages/ko.json

{

"cart": {

"itemCount": "{count}개",

"empty": "장바구니가 비어 있습니다",

"total": "합계 {amount}원"

},

"greeting": {

"formal": "{name}님, 안녕하세요", // 경어 (기본)

"informal": "{name}야, 안녕" // 반말 (특수 케이스)

}

}

---

✅ 이 장의 체크리스트

SSR, SPA, SSG, Islands의 차이를 설명하고, 사용 구분의 기준을 말할 수 있는가?

React, Vue, Svelte의 특징과 선정 이유를 말할 수 있는가?

Server Components와 Client Components의 차이를 설명할 수 있는가?

"상태 관리"의 3가지 레이어를 설명할 수 있는가?

Core Web Vitals의 3가지 지표(LCP·INP·CLS)와 목표값을 말할 수 있는가?

Tailwind CSS를 선택하는 이유와 주의점을 설명할 수 있는가?

AI UI 빌더(v0, Bolt, Lovable)의 차이와 사용 구분을 말할 수 있는가?

Next.js와 Vite의 사용 구분을 설명할 수 있는가?

"AI 생성 UI를 그대로 운영 환경에 투입해서는 안 되는 이유"를 설명할 수 있는가?

국내 서비스에서 한국어 줄바꿈(word-break: keep-all)이 필요한 이유를 설명할 수 있는가?

장애인차별금지법(장차법)과 웹 접근성 인증(WA 인증)이 프론트엔드 개발에 미치는 영향을 설명할 수 있는가?

⚠️ 편집 노트: 본 문서는 지속적으로 보완 중입니다. 국내 서비스 특이사항(소셜 로그인, 결제 연동, 접근성 인증) 및 프레임워크 최신 동향은 계속 업데이트될 예정입니다.

---

©2024-2026 MDRules dev., Hand-crafted & made with Jaewoo Kim.

이메일문의: jaewoo@mdrules.dev

AI강의/개발/기술자문, AI 업무 자동화 컨설팅 문의: https://talk.naver.com/ct/w5umt5

MDRules Dev - 네이버톡톡

AI 업무 자동화/에이전트/워크플로우설계 컨설팅/AI교육: https://mdrules.dev

MDRules Dev — AI 에이전트 경영과 AI 교육으로 차세대 경영 모델을 구축합니다