찬희의 Frontend Notes

JavaScript 2026 정리: ES2025, Node.js, React, Next.js에서 알아야 할 변화

Sun, 05 Apr 2026 14:20:00 +0900

2026년에도 자바스크립트를 공부할 때
언어 문법만 보면 부족하다.

실제로는 아래 네 가지를 같이 봐야 한다.

언어 자체가 어디까지 바뀌었는가
브라우저와 런타임이 무엇을 기본 지원하는가
프레임워크가 어떤 방향으로 이동하는가
실무에서 지금 당장 체감되는 변화가 무엇인가

Frontend Masters의 글
What To Know in JavaScript (2026 Edition)를 바탕으로 다시 정리해보겠다.

2026년 자바스크립트에서 먼저 봐야 할 변화

핵심만 먼저 정리하면 이렇다.

Node.js는 TypeScript 실행 경험을 더 직접적으로 제공하고 있다
Vite, Next.js, React는 모두 빌드 속도와 서버 중심 구조를 밀고 있다
Temporal API는 매우 중요하지만, 2026년 4월 5일 기준 Stage 4이다
이제 자바스크립트 실력은 언어 + 런타임 + 툴링 이해까지 포함한다

ES2025에서 알아둘 기능

1. Iterator Helpers

Iterator Helpers는 2025년에 들어와
배열 중심 처리와 다른 흐름을 보여주는 기능이 됐다.

기존에는 배열을 여러 번 변환하면서
중간 배열이 계속 만들어지는 코드가 흔했다.

const result = items
  .map((item) => item * 2)
  .filter((item) => item > 10)
  .slice(0, 3);

이 방식은 읽기 쉽지만
중간 결과가 계속 생긴다.

반면 이터레이터 헬퍼는
지연 평가(lazy evaluation) 기반으로 동작한다.

const result = Iterator.from(items)
  .map((item) => item * 2)
  .filter((item) => item > 10)
  .take(3)
  .toArray();

이 패턴이 중요한 이유는 두 가지다.

큰 데이터에서 불필요한 중간 배열 생성을 줄일 수 있다
Array뿐 아니라 Set, Map, generator 등 iterable 전반에 같은 흐름을 적용할 수 있다

MDN 기준 Iterator 관련 helper는
2025년부터 최신 브라우저 기준으로 사용 범위가 넓어지고 있다.

2. Set Methods

Set은 예전부터 있었지만
이제는 교집합, 합집합, 차집합 같은 연산을
더 직접적으로 쓸 수 있다.

const frontend = new Set(["js", "ts", "react"]);
const required = new Set(["js", "ts", "node"]);

console.log(frontend.intersection(required)); // Set { "js", "ts" }
console.log(frontend.union(required)); // Set { "js", "ts", "react", "node" }
console.log(required.difference(frontend)); // Set { "node" }

이 변화는 작아 보이지만
실무에서는 권한 집합, 태그 집합, 기능 플래그 집합 처리에서 꽤 유용하다.

3. RegExp.escape()

이 기능은 실무 체감이 아주 큰 편이다.

사용자 입력값을 그대로 정규식에 넣으면
특수문자 때문에 의도하지 않은 동작이 생길 수 있다.

const query = userInput;
const pattern = new RegExp(RegExp.escape(query), "g");

직접 escape 유틸을 만들어 쓰던 코드보다
훨씬 안전하고 명확하다.

MDN 기준 RegExp.escape()는
2025년 5월부터 최신 브라우저에서 폭넓게 동작하는 흐름으로 소개되고 있다.

4. Promise.try()

동기 예외와 비동기 예외를 따로 처리하던 코드를
조금 더 단순하게 만들 수 있다.

Promise.try(() => loadUser(id))
  .then((user) => render(user))
  .catch((error) => showError(error));

이 패턴의 장점은
함수가 동기로 터지든, Promise rejection으로 터지든
에러 경로를 한 번에 모을 수 있다는 점이다.

5. Import Attributes

JSON이나 CSS 같은 리소스를
더 명시적으로 import하는 흐름도 중요하다.

import data from "./data.json" with { type: "json" };
import sheet from "./styles.css" with { type: "css" };

문법은 깔끔하지만
JSON import는 실패 시 모듈 그래프 전체에 영향이 갈 수 있어서
항상 fetch보다 낫다고 보긴 어렵다.

즉, 이 기능은 “새 문법”으로 보기보다
리소스를 자바스크립트 모듈 시스템에 어떻게 연결할 것인가의 문제로 보는 편이 맞다.

ES2026 후보 중에서 특히 중요한 것

1. Temporal API

원문에서도 가장 크게 다룬 기능이 Temporal이다.
이건 이유가 분명하다.
JavaScript의 Date는 오랫동안 불편했다.

timezone 처리
월 단위 계산
immutable하지 않은 API
비교와 연산의 혼란

Temporal은 이 문제를 거의 정면으로 해결하려는 API다.

const now = Temporal.Now.zonedDateTimeISO("Asia/Seoul");
console.log(now.toLocaleString());

월 계산도 더 직관적이다.

const jan31 = Temporal.PlainDate.from("2026-01-31");
const nextMonth = jan31.add({ months: 1 });

console.log(nextMonth.toString()); // 2026-02-28

다만 여기서는 날짜를 분명히 봐야 한다.
2026년 4월 5일 기준 TC39의 proposal-temporal은 Stage 4이다.
즉, 매우 중요하고 거의 표준처럼 다뤄지지만
아직 확정된 ECMAScript 본편이라고 단정하면 안 된다.

그래서 지금의 실무 기준은 이렇다.

개념은 반드시 익혀둘 것
브라우저/런타임 지원 범위를 확인하고 도입할 것
기존 날짜 라이브러리 교체는 점진적으로 판단할 것

2. Explicit Resource Management

using과 Symbol.dispose, Symbol.asyncDispose 계열은
리소스 정리를 더 명시적으로 만든다.

async function save() {
  await using file = new FileHandle("output.txt");
  await file.write("hello");
}

이 기능이 중요한 이유는
파일, DB 연결, 임시 리소스처럼
“반드시 정리해야 하는 것”을 언어 차원에서 다룰 수 있기 때문이다.

자바스크립트가 점점
스크립트 언어를 넘어서 애플리케이션 언어로 가고 있다는 신호로 볼 수 있다.

2026년 런타임에서 봐야 할 것

1. Node.js는 이제 TypeScript 실행 경험을 직접 제공한다

Node.js 22.18.0부터는
타입 스트리핑 기반 TypeScript 실행이 기본 동작으로 들어왔다.

node script.ts

이건 꽤 큰 변화다.
예전에는 tsx, ts-node, 빌드 설정이 거의 기본 전제였다.
이제는 간단한 스크립트나 도구성 코드에서
Node 자체만으로도 시작이 쉬워졌다.

다만 한계는 분명하다.

TypeScript 전체 기능을 다 지원하는 것은 아니다
tsconfig.json 기반의 완전한 타입 검사 도구는 아니다
“실행 편의성”이 커진 것이지 “타입 안정성”이 자동으로 해결된 것은 아니다

즉, node script.ts는
개발 경험 개선이지 tsc의 대체는 아니다.

2. Bun과 Deno는 계속 Node를 압박하고 있다

2026년에도 기본 축은 Node.js다.
하지만 런타임 경쟁은 더 흥미로워졌다.

Bun: 빠른 설치 속도와 빠른 실행 속도
Deno: 보안 기본값과 안정성
Node.js: 생태계 규모와 호환성

특히 Deno는 “secure by default” 철학이 분명하고,
Bun은 개발 서버 경험과 속도를 강하게 밀고 있다.

중요한 건 이제 세 런타임 모두
예전보다 훨씬 비슷해지고 있다는 점이다.
즉, 차이는 문법보다 운영 철학과 생태계 선택에 더 가깝다.

빌드 도구는 결국 Vite 중심으로 모이고 있다

1. Vite 8

2026년 3월 12일에 공개된 Vite 8은
Rolldown 기반 단일 번들러 구조를 더 강하게 밀고 있다.

이 변화가 중요한 이유는
Vite가 더 이상 “빠른 dev server” 정도가 아니라
통합 툴체인 중심축이 되고 있기 때문이다.

실무 관점에서 보면 의미는 명확하다.

개발 서버
번들링
플러그인 생태계
테스트 도구와의 연결

이 모든 것이 Vite 중심으로 더 강하게 묶인다.

2. webpack은 끝난 것이 아니라, 기본값에서 밀려난 것이다

webpack은 여전히 크고 중요하다.
다만 2026년 흐름에서 “새 프로젝트의 기본 선택지” 자리는
대체로 Vite와 Turbopack 쪽으로 이동했다.

프레임워크 흐름도 같이 봐야 한다

1. React 19.2

React는 2025년 10월 1일에 React 19.2를 공개했다.
이 버전에서 눈에 띄는 키워드는 아래와 같다.

useEffectEvent
<Activity />
Partial Pre-rendering
성능 분석용 Performance Tracks

즉, React는 여전히
렌더링 우선순위와 서버 렌더링 구조를 더 정교하게 다루는 방향으로 가고 있다.

2. Next.js 16

Next.js 16은 2025년 10월 21일 공개됐다.
이 버전에서 가장 중요한 변화는
Turbopack이 기본 번들러가 되었다는 점이다.

그리고 같이 봐야 할 변화가 있다.

React 19.2 지원
proxy.ts 전환
Cache Components
revalidateTag() 시그니처 변화
비동기 params, searchParams 사용 강화

즉, Next.js는 여전히
“React를 서버 중심 아키텍처로 실용화하는 프레임워크” 방향을 더 밀고 있다.

3. 프레임워크를 볼 때 중요한 질문

2026년에는
프레임워크를 비교할 때 기능 목록보다 이 질문이 더 중요하다.

서버를 기본 전제로 두는가
캐싱 모델이 명확한가
빌드 도구와 얼마나 잘 통합되는가
React Compiler 같은 자동 최적화와 얼마나 맞물리는가

TypeScript도 같이 봐야 한다

2026년 3월 23일 TypeScript 6.0이 공개됐다.
이 버전은 “엄청난 기능 추가”보다
TypeScript 7 전환을 준비하는 정리 단계 성격이 강하다.

중요한 이유는
다음 세대 TypeScript가 Go 기반 컴파일러로 이동하면서
속도 개선 기대치가 매우 커졌기 때문이다.

결국 2026년의 자바스크립트 생태계는
JavaScript 단독이라기보다
JavaScript + TypeScript + 빌드 체인 전체로 이해해야 한다.

그래서 지금 무엇을 공부해야 할까

2026년 기준으로 우선순위를 잡는다면
나는 아래 순서가 실용적이라고 본다.

1. ES2025 실전 기능

Iterator Helpers
Set 메서드
RegExp.escape()
Import Attributes

이건 지금 바로 코드 품질과 표현력을 바꾼다.

2. 날짜와 시간 처리의 새 기준

Temporal 개념
timezone 처리
immutable date API 감각

이건 곧 실무 기본기가 될 가능성이 크다.

3. 런타임 감각

Node.js에서 TypeScript를 어디까지 기본 지원하는가
Bun과 Deno는 무엇이 다른가
보안 모델과 실행 모델이 어떻게 다른가

4. 빌드 도구와 프레임워크 연결

Vite 8
Next.js 16
React 19.2

프론트엔드 개발자라면
이 세 축은 거의 같이 봐야 한다.

정리

2026년 자바스크립트에서 중요한 것은
“새 문법 몇 개를 외우는가”가 아니다.

더 중요한 것은 아래다.

어떤 기능이 이제 실무 기본값이 되었는가
어떤 API가 아직 후보 단계인가
어떤 런타임과 도구가 실제 개발 경험을 바꾸는가
프레임워크가 서버 중심 구조로 얼마나 이동했는가

즉, 지금 자바스크립트를 공부한다는 말은
언어만 공부하는 것이 아니라
언어, 런타임, 빌드 도구, 프레임워크의 연결 구조를 같이 이해하는 것에 가깝다.

참고 자료

Frontend Masters - What To Know in JavaScript (2026 Edition)

antd vs shadcn/ui 비교: 어떤 React UI를 선택해야 할까?

Sat, 28 Mar 2026 16:07:00 +0900

React 프로젝트를 시작할 때 UI 선택지는 많지만, 실무에서 자주 비교되는 조합은 antd와 shadcn/ui다.

둘 다 React에서 빠르게 화면을 만들 수 있다는 점은 같지만, 접근 방식은 꽤 다르다.
antd는 완성형 컴포넌트 라이브러리에 가깝고, shadcn/ui는 내 코드베이스 안으로 가져와 직접 소유하는 UI 세트에 가깝다.

현재 공식 문서 기준 antd는 6.3.4, shadcn/ui는 init/add CLI와 Radix/Base UI 선택 구조를 제공하고 있다.

요약

관리자 화면, 대시보드, 폼/테이블 중심 서비스라면: antd
마케팅 페이지, SaaS 프로덕트, 브랜드 커스터마이징이 중요한 서비스라면: shadcn/ui
팀이 “일단 빨리 많이 만들어야 한다”면: antd
팀이 “디자인 시스템을 우리 코드로 오래 가져가야 한다”면: shadcn/ui

antd와 shadcn/ui의 핵심 차이

항목	antd	shadcn/ui
기본 성격	완성형 React UI 라이브러리	코드 배포형 UI 세트
설치 방식	`npm install antd` 후 import	CLI로 필요한 컴포넌트 코드를 프로젝트에 추가
기본 스타일	일관된 Ant Design 스타일	미니멀한 기본 스타일, 직접 수정 전제
커스터마이징	토큰/테마 중심	코드 직접 수정 중심
컴포넌트 수	매우 많음	필요한 것만 선택 추가
러닝커브	낮음	낮지 않음(Tailwind/CSS 변수 구조 이해 필요)
업데이트 방식	라이브러리 버전 업	내 코드와 의존성 같이 관리
잘 맞는 제품	백오피스, 대시보드, CRUD	제품 UI, 디자인시스템 적용된 서비스

1. 설치와 시작 속도

antd: 바로 쓸 수 있는 완성형

antd는 설치 후 바로 import해서 사용할 수 있다.

import { Button, DatePicker, Table } from "antd";

공식 소개 페이지 기준으로 antd는 엔터프라이즈 웹 애플리케이션용 UI 프레임워크를 지향하고,
컴포넌트 수가 매우 많다. 실제로 Form, Table, DatePicker, Modal, Drawer, Upload처럼
실무에서 자주 쓰는 조합이 이미 잘 갖춰져 있다.

즉, 관리자 화면을 빨리 만드는 속도는 대체로 antd 쪽이 더 좋다.

shadcn/ui: 필요한 것만 가져오는 방식

shadcn/ui는 전통적인 “패키지 import” 스타일과 다르다.
CLI로 필요한 컴포넌트를 내 프로젝트에 추가하는 방식이다.

pnpm dlx shadcn@latest init
pnpm dlx shadcn@latest add button dialog form

공식 문서도 shadcn/ui를 전통적인 컴포넌트 라이브러리라기보다, 코드 배포 방식으로 설명한다.
즉, 가져다 쓰는 게 아니라 내 프로젝트 안에 컴포넌트 파일이 들어온다.

이 방식은 초반 세팅은 조금 더 필요하지만, 장기적으로는 유연하다.

2. 커스터마이징은 누가 더 쉬운가?

antd: 토큰 기반 커스터마이징

antd는 ConfigProvider와 디자인 토큰 기반 커스터마이징이 강하다.

import { ConfigProvider } from "antd";

export default function App() {
  return (
    <ConfigProvider
      theme={{
        token: {
          colorPrimary: "#0f766e",
          borderRadius: 10,
        },
      }}
    >
      {/* app */}
    </ConfigProvider>
  );
}

공식 문서 기준으로 antd 5+는 CSS-in-JS 기반 테마 시스템을 제공하고,
6.x에서는 zeroRuntime 모드도 지원한다.
즉, “브랜드 컬러/둥근 모서리/밀도” 같은 전역 규칙을 적용하는 데 강하다.

다만 컴포넌트 내부 DOM 구조까지 강하게 바꾸고 싶을 때는 shadcn/ui보다 답답할 수 있다.

shadcn/ui: 코드 직접 수정

shadcn/ui의 강점은 여기서 나온다.
버튼, 다이얼로그, 셀렉트 같은 UI가 내 코드로 들어오기 때문에 그대로 수정할 수 있다.

// components/ui/button.tsx
export function Button({ className, ...props }: ButtonProps) {
  return (
    <button
      className={cn(
        "inline-flex h-10 items-center rounded-md px-4 text-sm font-medium",
        className
      )}
      {...props}
    />
  );
}

공식 문서 기준으로 shadcn/ui는 CSS Variables 기반 테마를 권장하고,
Tailwind CSS를 전제로 스타일링한다.

즉, shadcn/ui는 디자인 시스템을 라이브러리 밖에서 억지로 덮는 구조가 아니라, 아예 코드 자체를 팀 자산으로 가져가는 방식이다.

결론적으로:

전역 테마 수정은 antd가 편하다
컴포넌트 구조 자체를 수정하려면 shadcn/ui가 더 편하다

3. 디자인 일관성과 기본 완성도

antd는 “정해진 시스템”이 강하다

antd는 처음부터 디자인 언어가 강하다.
버튼, 입력창, 테이블, 모달, 네비게이션이 한 세트처럼 움직인다.

이건 특히 아래 같은 상황에서 유리하다.

백오피스 화면이 많다
폼과 테이블이 많다
디자인보다 기능 우선이다
여러 개발자가 동시에 화면을 찍어내야 한다

즉, 디자인 판단 비용을 줄여준다.

shadcn/ui는 “좋은 출발점”에 가깝다

shadcn/ui는 기본 스타일이 깔끔하지만, antd처럼 강한 제품 언어를 밀어붙이진 않는다.
오히려 그 점이 장점이다.

제품 톤앤매너를 직접 만들기 쉽다
Tailwind/CSS 변수 기반으로 미세 조정이 쉽다
마케팅 페이지와 앱 화면을 같은 언어로 묶기 좋다

대신 팀이 디자인 원칙 없이 들어가면, 화면마다 느낌이 달라질 수 있다.

4. 컴포넌트 범위와 실무 생산성

antd는 특히 Form/Table 계열이 강하다

antd의 가장 큰 실무 장점은 풍부한 컴포넌트다.

Form
Table
DatePicker
Tree
Select
Upload
Drawer
Modal
Notification

이런 조합을 직접 설계하지 않고 빠르게 연결할 수 있다.
관리자 시스템, 내부 운영 도구, B2B SaaS 백오피스라면 이 장점이 매우 크다.

shadcn/ui는 필요한 것만 쌓는 방식

shadcn/ui도 폼, 다이얼로그, 드롭다운, 시트, 토스트 등 주요 조각은 충분히 제공한다.
게다가 최근 문서 기준으로 Radix와 Base UI 선택도 가능하다.

하지만 antd처럼 거대한 완성형 세트라기보다,
“팀이 필요한 조각을 가져와 조립하는 방식”에 더 가깝다.

그래서 제품이 아래에 가까울수록 잘 맞는다.

커스텀 UI가 많다
기본 컴포넌트를 계속 수정하게 된다
브랜드 일관성이 중요하다
디자인 시스템을 내부 자산으로 키우고 싶다

5. 번들, 런타임, 성능 관점

이 비교는 “무조건 누가 더 빠르다”로 단순화하기 어렵다.
대신 어디서 비용이 생기는가를 봐야 한다.

antd

장점: 검증된 컴포넌트가 많아 직접 구현 비용이 줄어듦
장점: ES modules 기반 tree shaking 지원
장점: 6.x에서는 zeroRuntime 모드 지원
주의점: 무거운 화면에서 많은 고수준 컴포넌트를 한 번에 쓰면 체감 비용이 생길 수 있음

shadcn/ui

장점: 필요한 컴포넌트만 추가 가능
장점: 코드 소유권이 내 쪽에 있어 불필요한 추상화 제거가 쉬움
장점: Tailwind/CSS 변수 조합으로 스타일 제어가 단순한 편
주의점: 성능이 자동으로 좋아지는 것은 아님
주의점: 결국 팀이 추가한 코드 품질에 따라 차이가 커짐

즉, 성능만 보고 고르면 안 된다.
antd는 완성도와 생산성의 비용 구조,
shadcn/ui는 유연성과 소유권의 비용 구조라고 보는 편이 맞다.

6. 어떤 팀에 무엇이 맞을까?

antd가 더 잘 맞는 팀

운영툴, 관리자, 대시보드 개발이 많다
폼/테이블/권한 관리 화면이 많다
디자이너 리소스가 제한적이다
팀원마다 UI 구현 편차를 줄이고 싶다
빠르게 MVP가 아니라 빠르게 “업무용 완성 화면”을 내야 한다

shadcn/ui가 더 잘 맞는 팀

제품 UI를 브랜드에 맞게 세밀하게 만들고 싶다
Tailwind 기반 개발 문화가 이미 있다
컴포넌트를 우리 코드 자산으로 관리하고 싶다
Next.js/Vite 기반 프론트엔드 제품팀이다
장기적으로 사내 디자인 시스템을 키우고 싶다

7. 내 기준 추천

제가 실무에서 선택한다면 기준은 꽤 단순하다.

`antd`를 고를 때

“이번 분기 안에 관리자 화면을 많이 만들어야 한다”
“Table/Form/DatePicker가 핵심이다”
“팀 전체가 같은 UI 언어를 빠르게 공유해야 한다”

이 경우는 antd가 훨씬 실용적이다.

`shadcn/ui`를 고를 때

“디자인 시스템을 우리가 소유해야 한다”
“컴포넌트를 계속 뜯어고칠 가능성이 높다”
“브랜드 경험이 제품 경쟁력이다”

이 경우는 shadcn/ui가 더 오래 버틴다.

최종 정리

antd vs shadcn/ui 비교는 단순히 “예쁜가?”의 문제가 아니다.
결국 아래 두 질문에 대한 답이다.

우리는 완성형 라이브러리가 필요한가?
아니면 우리 코드베이스 안에서 디자인 시스템을 직접 키울 것인가?

빠른 실무 생산성, 풍부한 기본 컴포넌트, 관리자 화면 중심이라면 antd.
브랜드 커스터마이징, 코드 소유권, 제품 UI 확장성을 더 중시한다면 shadcn/ui.

둘 중 무엇이 더 좋다고 단정하기보다,
“우리 팀의 제품 성격과 유지보수 방식에 더 맞는가”로 고르는 게 맞다.

참고 자료

React와 Next.js를 위한 완벽한 Codex 설정

Fri, 27 Mar 2026 16:32:00 +0900

AI 코딩 도구는 이제 많다.
하지만 생산성이 정말 오르는 팀은 모델이 좋아서가 아니라
에이전트가 참고할 규칙과 검증 루프를 먼저 세팅한 팀이다.

Builder.io의 글
The Perfect Cursor AI setup for React and Next.js도
결국 같은 얘기를 한다.
핵심은 기능 목록이 아니라, 문맥을 고정하고 결과를 자동으로 검증하는 흐름이다.

이 글에서는 그 원칙을 Cursor가 아니라
Codex를 기준으로 React/Next.js 프로젝트에 맞게 다시 정리해보겠다.

결론부터: Codex는 “설정”보다 “작업 환경 설계”가 중요하다

React와 Next.js에서 Codex를 잘 쓰려면 아래 네 가지가 먼저 잡혀야 한다.

프로젝트 규칙을 한 곳에 적어둘 것
어떤 문서를 우선 신뢰해야 하는지 정해둘 것
lint, typecheck, test를 검증 루프로 묶을 것
에이전트가 한 번에 너무 큰 변경을 하지 않게 작업 단위를 작게 나눌 것

즉, Codex를 잘 쓰는 방법은
프롬프트를 화려하게 쓰는 게 아니라
좋은 기본 규칙 + 짧은 피드백 루프 + 명확한 코드베이스 문맥을 만드는 것이다.

왜 React와 Next.js에서 특히 설정이 중요할까

React와 Next.js 프로젝트는 AI가 실수하기 쉬운 지점이 꽤 분명하다.

서버 컴포넌트와 클라이언트 컴포넌트 경계를 흐릴 수 있다
useEffect를 과하게 추가할 수 있다
최신 라우팅 구조를 무시하고 예전 페이지 라우터 방식으로 코드를 만들 수 있다
Tailwind 클래스만 맞추고 접근성이나 상태 흐름은 놓칠 수 있다
타입은 맞는 것처럼 보이지만 실제 런타임 흐름은 깨질 수 있다

그래서 이 스택에서는
AI가 “대충 돌아가는 코드”를 내놓는 것보다
우리 프로젝트 규칙을 어기지 않게 만드는 장치가 더 중요하다.

1. 가장 먼저 해야 할 일: `AGENTS.md`를 제대로 적기

Codex 계열 에이전트를 쓸 때 가장 먼저 손봐야 하는 파일은 보통 AGENTS.md다.
이 파일은 “우리 프로젝트에서 어떻게 일해야 하는가”를 고정하는 역할을 한다.

여기에는 최소한 아래 내용이 들어가야 한다.

패키지 매니저는 무엇인지 (pnpm, npm, yarn)
개발 서버/테스트/린트 명령어가 무엇인지
React와 Next.js에서 반드시 지켜야 할 규칙
폴더 구조와 컴포넌트 배치 원칙
스타일링 방식 (Tailwind, CSS Modules, styled-components)
데이터 패칭 원칙
PR 전에 반드시 통과해야 하는 체크 항목

예를 들면 이런 식이다.

## 프로젝트 규칙

- Next.js는 App Router만 사용한다.
- 기본 컴포넌트는 서버 컴포넌트로 작성한다.
- 브라우저 API나 클라이언트 상태가 필요할 때만 `"use client"`를 추가한다.
- 데이터 패칭은 가능한 서버에서 먼저 처리하고, 꼭 필요하지 않다면 `useEffect`로 옮기지 않는다.
- 스타일링은 Tailwind CSS를 사용한다.
- 새 컴포넌트를 만들기 전에 `components/ui`의 기존 컴포넌트를 먼저 재사용한다.
- 의미 있는 변경 후에는 `pnpm lint`, `pnpm typecheck`, `pnpm test`를 실행한다.
- 명시적으로 요청받지 않았다면 새 의존성을 추가하지 않는다.

이 정도만 있어도 Codex의 출력 품질은 꽤 달라진다.
AI는 똑똑한 것 같아도, 기준이 없으면 매번 다른 스타일로 코드를 쓴다.

2. “무엇을 기억해야 하는가”를 규칙으로 분리하기

Builder 글이 Cursor의 Rules, Docs, Memories를 강조한 이유는 단순하다.
AI는 코드만 읽고도 어느 정도 일할 수 있지만,
팀의 취향과 예외 규칙은 코드만으로는 잘 못 배운다.

Codex에서도 같은 원칙을 적용하면 된다.

정리 기준은 이렇다.

오래 유지될 규칙: AGENTS.md
특정 폴더/기능에만 적용되는 규칙: 각 디렉터리의 문서 파일
자주 틀리는 구현 포인트: 예제 코드와 테스트

예를 들어 Next.js 프로젝트라면 아래 항목은 문서로 명시해두는 편이 좋다.

app/ 아래 라우트 구성 규칙
서버 액션 사용 기준
loading.tsx, error.tsx, not-found.tsx 처리 원칙
캐싱/재검증 정책
인증 상태를 어디서 읽는지
공통 UI 컴포넌트의 import 경로

중요한 건
설명을 길게 쓰는 게 아니라 에이전트가 반복해서 참고할 수 있게 짧고 단정하게 적는 것이다.

3. 공식 문서를 우선 참조하게 만들어라

AI가 가장 자주 헷갈리는 순간은
“예전에 맞던 답”을 지금도 맞다고 가정할 때다.

특히 React와 Next.js는 변화가 빠르기 때문에
다음 우선순위를 미리 정해두는 게 좋다.

React 공식 문서
Next.js 공식 문서
팀 내부 규칙 문서
현재 저장소의 실제 코드

실제로 Codex에 일을 시킬 때도 이렇게 요청하는 편이 낫다.

이 저장소의 현재 라우팅 구조를 기준으로 작업해줘.
기존의 서버 우선 데이터 패칭 방식을 유지해줘.
프레임워크 동작이 애매하면 React와 Next.js 공식 문서 기준에 맞춰줘.

이 한 줄이 중요한 이유는
AI가 “비슷한 예제”가 아니라 이 프로젝트와 맞는 정답을 찾도록 방향을 잡아주기 때문이다.

4. ESLint와 TypeScript는 선택이 아니라 필수다

Builder 글에서도 lint 자동 수정 루프를 강하게 밀고 있는데,
이건 Codex에서도 거의 그대로 적용된다.

AI가 만든 코드는 얼핏 그럴듯해 보여도
실제로는 아래 같은 문제가 자주 생긴다.

사용하지 않는 import
잘못된 hook 사용
타입 단언 남용
client/server 경계 위반
접근성 속성 누락

그래서 React/Next.js 프로젝트에서 Codex를 쓴다면
적어도 아래 스크립트는 정리되어 있어야 한다.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "lint": "next lint",
    "typecheck": "tsc --noEmit",
    "test": "vitest run"
  }
}

그리고 에이전트에게도 명시적으로 요구하는 편이 좋다.

변경 후에는 lint와 typecheck를 실행해줘.
수정한 영역에 테스트가 있으면 함께 실행해줘.
코드만 생성하고 끝내지 말고, 검증이 통과할 때까지 수정해줘.

핵심은 “코드 생성”에서 끝내지 않는 것이다.
생성 -> 검증 -> 수정이 한 묶음이어야 한다.

5. 테스트 기반 루프를 만들면 Codex가 훨씬 안정적이다

React와 Next.js에서 AI가 제일 잘하는 일 중 하나는
빈 화면에서 처음부터 모든 걸 맞히는 일이 아니라,
실패하는 조건을 보고 점진적으로 고치는 일이다.

그래서 새 기능을 만들 때는 아래 순서가 좋다.

먼저 테스트나 기대 동작을 적는다
Codex에게 그 조건을 만족하는 최소 구현을 시킨다
lint/typecheck/test를 돌린다
실패 원인을 보고 다시 수정한다

예를 들면 이렇게 요청할 수 있다.

`SignupForm` 컴포넌트 테스트를 먼저 작성해줘.
로딩 상태, 유효성 검사 오류 상태, 성공 상태를 포함해줘.
그 다음 테스트를 통과하는 최소 구현을 만들어줘.
컴포넌트는 작게 유지하고 기존 UI 컴포넌트를 재사용해줘.

이 방식이 좋은 이유는
AI가 멋있어 보이는 코드를 쓰는 대신
통과해야 할 기준을 중심으로 움직이게 만들기 때문이다.

6. 작업 단위는 작게 쪼개야 한다

Codex를 포함한 대부분의 에이전트는
한 번에 너무 많은 걸 시키면 품질이 급격히 흔들린다.

특히 아래 요청은 실패 확률이 높다.

“대시보드 전체를 새 디자인으로 갈아줘”
“Next.js 구조 전부 최신 방식으로 바꿔줘”
“상태 관리도 정리하고 성능도 개선하고 테스트도 추가해줘”

반대로 이런 요청은 훨씬 안정적이다.

“이 페이지를 서버 컴포넌트로 유지한 채 데이터 패칭만 정리해줘”
“이 폼에서 유효성 검사와 제출 상태만 분리해줘”
“이 파일의 useEffect를 줄이고 불필요한 상태를 제거해줘”

좋은 에이전트 사용법은
큰 일을 한 번에 맡기는 것이 아니라
작은 단위를 연속적으로 위임하는 것에 가깝다.

7. React/Next.js용 Codex 프롬프트는 이렇게 바꾸는 게 좋다

아래처럼 막연하게 시키면 결과가 흔들리기 쉽다.

이 페이지를 더 좋게 만들어줘.

반면 이렇게 조건을 걸면 훨씬 낫다.

이 페이지를 현재 Next.js 라우팅 구조에 맞게 리팩터링해줘.
클라이언트 컴포넌트로 바꾸지 말고 지금의 서버 렌더링 구조를 유지해줘.
새 의존성은 추가하지 마.
`components/ui`의 기존 컴포넌트를 우선 재사용해줘.
추상화를 늘리기보다 상태 흐름을 단순하게 유지해줘.
변경 후에는 lint와 typecheck를 실행해줘.

포인트는 두 가지다.

기술 제약을 먼저 적는다
검증 조건을 마지막에 붙인다

이 두 줄만 붙여도
AI가 “예쁜 코드”보다 프로젝트에 맞는 코드를 낼 확률이 올라간다.

8. 내가 추천하는 React/Next.js용 Codex 기본 체크리스트

새 프로젝트든 기존 프로젝트든, 시작점은 아래 정도면 충분하다.

AGENTS.md에 라우팅 구조, 스타일링, 데이터 패칭, 테스트 규칙 작성
package.json에 lint, typecheck, test 스크립트 정리
공통 컴포넌트 경로와 재사용 원칙 명시
서버 컴포넌트와 클라이언트 컴포넌트 경계 규칙 명시
의존성 추가 금지 또는 승인 기준 명시
큰 작업은 작은 단계로 나눠 요청
구현 후 반드시 검증 명령 실행

여기까지 맞추면 Codex는 단순 코드 생성기가 아니라
팀 규칙 안에서 움직이는 보조 개발자에 가까워진다.

마무리

Builder의 Cursor 설정 글을 읽고 가장 동의했던 부분은
“좋은 AI 활용은 모델 선택보다 작업 환경 설계에 가깝다”는 점이다.

Codex도 마찬가지다.
React와 Next.js에서 정말 중요한 건
에이전트를 똑똑하게 보이게 만드는 프롬프트가 아니라, 틀리기 어려운 환경을 먼저 만드는 것이다.

정리하면 React/Next.js에서 Codex 설정의 핵심은 아래다.

규칙은 AGENTS.md에 고정한다
공식 문서와 저장소 패턴을 우선 참조하게 만든다
lint/typecheck/test를 작업 루프에 포함한다
한 번에 큰 작업보다 작은 수정 단위로 맡긴다

이 네 가지만 지켜도
AI 코딩 경험은 꽤 안정적으로 바뀐다.

ChatGPT vs Gemini 비교: 프론트엔드 개발자에게 어떤 AI가 더 좋을까?

Sun, 22 Mar 2026 10:08:00 +0900

ChatGPT vs Gemini 비교를 찾는 개발자는 대체로 같은 질문을 한다.
“코딩은 누가 더 잘하나?”, “프론트엔드 개발에는 뭐가 더 잘 맞나?”, “React나 Next.js 작업에서는 어느 쪽이 덜 답답한가?”

이 글은 그런 검색 의도에 맞춰 챗GPT vs 제미나이 비교를
프론트엔드 개발자 실사용 관점으로 정리한 글이다.
특히 아래 작업을 기준으로 나눠서 본다.

React 컴포넌트 리팩터링
UI 초안 생성과 반복 수정
긴 문서, 긴 로그, 긴 스펙 요약
Next.js에 AI 기능 붙이는 프로토타이핑

결론만 먼저 말하면 이렇다.
코드를 세밀하게 고치고 UI를 여러 번 다듬는 흐름은 ChatGPT가 편하고, 긴 문서를 한 번에 읽히거나 실험용 API 흐름을 빠르게 잡는 일은 Gemini가 편한 경우가 많다.

요약

ChatGPT는 기존 코드 수정, React 리팩터링, UI 반복 편집에 강점이 있다
Gemini는 긴 문서 요약, 긴 로그 분석, 여러 자료를 한 번에 읽히는 작업에 강점이 있다
프론트엔드 개발자라면 하나만 고르기보다 편집은 ChatGPT, 탐색과 대용량 입력은 Gemini로 나눠 쓰는 전략이 실용적이다

ChatGPT vs Gemini 한눈에 비교

작업	추천	이유
React 컴포넌트 리팩터링	`ChatGPT`	기존 코드를 붙여 넣고 단계적으로 수정하기 편하다
UI 초안 만들기	`ChatGPT`	시안을 만든 뒤 여러 번 수정 지시를 주는 흐름이 자연스럽다
긴 문서/긴 로그 읽히기	`Gemini`	긴 입력을 한 번에 다루는 쪽이 더 편하다
Next.js에 AI 기능 붙이기	`Gemini`	프로토타입을 빠르게 만들고 비교 실험하기 좋다
모델 응답 비교/PoC 만들기	`Gemini`	여러 조건을 바꿔가며 실험할 때 효율적이다

ChatGPT와 Gemini 차이: 프론트엔드 개발자 기준 비교 포인트

ChatGPT와 Gemini는 둘 다 “코드도 만들고 문서도 읽는 AI”처럼 보이지만,
실제로 붙잡고 일해보면 결이 다르다.

프론트엔드 개발자 기준으로는 아래 차이가 체감된다.

이미 있는 코드를 조금씩 고쳐야 하는가
화면 초안을 만든 뒤 여러 번 수정해야 하는가
긴 문서나 큰 로그를 한 번에 읽혀야 하는가
Next.js에서 빠르게 AI 기능 PoC를 붙여야 하는가

즉, ChatGPT vs Gemini는 모델 성능 한 줄 비교보다
어떤 작업 흐름에 더 잘 맞는가로 보는 편이 정확하다.

ChatGPT vs Gemini 코딩 비교: React 리팩터링은 누가 더 편할까?

프론트엔드에서 AI를 가장 자주 쓰는 순간은
새 프로젝트를 처음부터 만드는 때보다 이미 있는 코드를 손볼 때다.

예를 들면 이런 작업이다.

상태가 꼬인 컴포넌트 정리
과하게 늘어난 useEffect 제거
반복되는 폼 로직 분리
길어진 Tailwind 클래스 정리
접근성(a11y) 보강

이 구간에서는 대체로 ChatGPT가 더 손에 잘 붙는다.
이유는 결과물 자체보다 수정 대화의 템포에 있다.

“문제부터 짚어줘”
“가장 작은 수정안부터 보여줘”
“before / after로 비교해줘”
“이건 유지하고 이 부분만 바꿔줘”

이런 식으로 한 단계씩 밀고 가는 흐름이 자연스럽다.

React 코드 정리가 잦다면
useEffect 정리 글과
React/Next.js용 Codex 설정 글도 같이 보면
프롬프트 품질을 더 끌어올리기 쉽다.

반대로 Gemini는 코드 생성 자체는 충분히 되지만,
한두 줄씩 집요하게 다듬는 편집감보다는
넓은 맥락을 한 번에 보고 정리하는 느낌이 더 강하다.

UI 초안 생성은 ChatGPT가 더 빠른 편이다

ChatGPT vs Gemini를 UI 기준으로 비교하면
초안 하나를 만든 뒤 계속 수정해 나가는 작업은 ChatGPT가 대체로 편하다.

예를 들면 이런 요청이다.

“간격을 더 줄여줘”
“모바일에서는 카드 순서를 바꿔줘”
“빈 상태와 로딩 상태를 추가해줘”
“너무 평범하지 않게 다시 구성해줘”

이런 식의 반복 수정은
초안을 계속 이어서 고치는 방식이 중요하기 때문에 ChatGPT 쪽이 유리하다.

특히 아래 조건이 많을수록 체감 차이가 난다.

React 또는 Next.js 기반 UI
Tailwind나 CSS 변수 사용
시안보다 구현 가능한 코드가 중요
디자이너 전달용이 아니라 개발 초안이 목적

Gemini도 UI 코드를 만들 수는 있다.
다만 UI 하나를 세밀하게 다듬는 것보다
요구사항이 긴 화면이나 데모 성격의 기능 화면을 한 번에 잡는 쪽이 더 잘 맞는다.

긴 문서 요약과 긴 로그 분석은 Gemini가 더 잘 맞는다

문서가 길어지고 입력량이 커질수록 Gemini가 편하다고 느끼는 경우가 많다.

대표적으로 아래 작업이다.

Next.js 마이그레이션 문서 통째로 읽히기
OpenAPI 문서를 바탕으로 타입 초안 만들기
긴 에러 로그에서 반복 패턴 찾기
여러 파일을 한 번에 넣고 구조 정리 받기

프론트엔드 실무에서는 이런 일이 생각보다 자주 생긴다.
특히 프레임워크 변경점을 따라가야 할 때 체감이 크다.

예를 들어 Next.js를 쓰고 있다면
Next.js App Router 정리나
Next.js 16 vs 15 변경점 같은 긴 문서를 볼 때,
핵심만 먼저 추려 달라고 하기 좋다.

반대로 ChatGPT는 긴 입력을 한 번에 몰아 넣기보다
문맥을 대화로 이어가며 점점 좁혀가는 방식에 더 강점이 있다.

Next.js에서 AI 기능 붙일 때는 Gemini가 실험 속도가 빠르다

Gemini vs ChatGPT 개발자 추천 질문이 나올 때
의외로 갈리는 지점이 바로 프로토타이핑 속도다.

Next.js에서 AI 응답을 붙이는 최소 예제를 만들고
응답 형식을 바꿔 보고
에러 처리 구조를 바꿔 보고
스트리밍 확장 여지를 남기는 식의 PoC를 할 때는 Gemini가 편한 경우가 많다.

이유는 복잡한 제품 설계보다
빠르게 붙여 보고 확인하는 흐름에 잘 맞기 때문이다.

특히 아래 조건이면 더 그렇다.

Route Handler 기준 최소 예제가 필요하다
환경변수 분리와 에러 처리까지 같이 보고 싶다
여러 모델 응답 형태를 빠르게 비교하고 싶다
아직 제품 코드보다 실험 코드 비중이 높다

다만 PoC가 끝나고 실제 화면 안에서 다듬기 시작하면
그다음부터는 다시 ChatGPT가 더 편하게 느껴질 수 있다.

그래서 프론트엔드 개발자는 무엇을 먼저 써야 할까?

ChatGPT와 Gemini 중 어떤 AI가 더 좋나요?라는 질문에
프론트엔드 개발자 기준으로 답하면 아래에 가깝다.

ChatGPT가 더 잘 맞는 사람

기존 React 코드를 자주 고친다
UI 초안을 만든 뒤 수정 반복이 많다
한 번에 완성 답변보다 대화형 수정이 편하다
코드 리뷰처럼 문제를 짚고 고쳐 나가는 흐름을 선호한다

Gemini가 더 잘 맞는 사람

긴 문서와 긴 입력을 자주 다룬다
API 실험과 PoC를 빠르게 돌려본다
여러 자료를 한 번에 넣고 구조를 잡고 싶다
Next.js에 AI 기능을 붙이는 초기 탐색을 자주 한다

둘을 같이 쓰는 것이 맞는 사람

구현과 실험을 모두 많이 한다
코드는 세밀하게 고치고 문서는 크게 읽어야 한다
한 도구로 모든 상황을 해결하려다 자주 막힌다

실무에서는 이 세 번째가 가장 많다.

비교할 때 바로 써먹기 좋은 프롬프트

아래 프롬프트는 ChatGPT와 Gemini를 같은 조건으로 비교할 때 유용하다.
같은 입력을 넣으면 두 도구의 답변 스타일 차이가 꽤 선명하게 드러난다.

1) React 컴포넌트 리팩터링

아래 React 컴포넌트를 리팩터링해줘.

조건:
- 관심사 분리
- derived state 제거
- 불필요한 useEffect 제거
- 접근성(a11y) 개선
- TypeScript 타입 보강

코드:
[여기에 컴포넌트 코드 붙여넣기]

2) Next.js 페이지 구조 개선

이 Next.js App Router 코드를 보고 서버 컴포넌트와 클라이언트 컴포넌트 경계를 다시 설계해줘.

조건:
- use client 최소화
- 서버 패칭 우선
- hydration mismatch 가능성 체크
- provider 전염 여부 체크
- before / after 코드로 보여줘

코드:
[여기에 페이지 코드 붙여넣기]

3) TypeScript 에러 분석

아래 TypeScript 에러 원인을 설명하고, 가장 단순한 수정안과 구조적으로 더 나은 수정안을 각각 제안해줘.

에러:
[에러 메시지]

코드:
[관련 코드]

4) UI 초안 생성

Next.js + Tailwind 기준으로 반응형 대시보드 페이지 초안을 만들어줘.

조건:
- 모바일/태블릿/데스크톱 대응
- 카드 4개
- 최근 활동 리스트
- 빈 상태와 로딩 상태 포함
- CSS 변수 사용
- 너무 평범하지 않게 구성

5) 긴 문서 요약

아래 공식 문서를 읽고 프론트엔드 개발자가 알아야 할 핵심만 정리해줘.

조건:
- 바뀐 점
- 기존 코드가 깨질 수 있는 지점
- 바로 적용할 수 있는 예시
- 10줄 요약 + 상세 설명

문서:
[공식 문서 본문 또는 링크 내용 요약]

6) Gemini API / OpenAI API 프로토타입

Next.js Route Handler에서 사용자 질문을 받아 AI 응답을 반환하는 최소 예제를 만들어줘.

조건:
- TypeScript
- 에러 처리 포함
- 환경변수 분리
- fetch 또는 공식 SDK 사용
- 추후 스트리밍으로 확장하기 쉽게 구조화

자주 묻는 질문

ChatGPT와 Gemini 중 코딩은 뭐가 더 좋나요?

기존 코드를 고치고, 문제를 짚고, 작은 수정안을 반복해서 받는 흐름은 ChatGPT가 더 편한 경우가 많다.
반면 긴 문서와 큰 입력을 함께 읽혀가며 구조를 잡는 흐름은 Gemini가 더 편할 수 있다.

프론트엔드 개발자는 어떤 AI부터 써보면 좋나요?

React 컴포넌트 수정, UI 초안 생성, 코드 품질 개선이 많다면 ChatGPT부터 시작하는 편이 무난하다.
긴 문서 요약, 로그 분석, AI 기능 PoC가 많다면 Gemini부터 써보는 것도 괜찮다.

Next.js 프로젝트에는 ChatGPT와 Gemini 중 무엇이 더 잘 맞나요?

구현 단계에서는 ChatGPT, 탐색 단계와 긴 문서 요약 단계에서는 Gemini가 편한 경우가 많다.
즉, Next.js에서는 둘 중 하나를 고르기보다 작업 단계에 따라 분리해서 쓰는 전략이 실용적이다.

ChatGPT vs Gemini 비교에서 가장 중요한 기준은 무엇인가요?

모델 이름보다 내가 자주 하는 작업의 형태가 더 중요하다.
세밀한 편집이 많은지, 긴 입력을 자주 다루는지, 프로토타입 비중이 높은지를 먼저 보면 선택이 쉬워진다.

결론

ChatGPT vs Gemini 비교를 한 줄로 끝내면 이렇다.

코드를 세밀하게 고치고 UI를 반복 수정해야 하면 ChatGPT
긴 문서와 큰 입력을 빠르게 정리하고 실험해야 하면 Gemini
프론트엔드 실무에서는 둘을 분리해서 쓰는 쪽이 가장 덜 답답하다

즉, 챗GPT vs 제미나이의 답은 “누가 무조건 더 좋다”가 아니다.
프론트엔드 개발에서 내가 자주 하는 일이 무엇인지가 답을 정한다.

Next.js 16 vs 15 변경점: 무엇이 달라졌나?

Wed, 18 Mar 2026 18:10:00 +0900

2025년 10월 21일에 Next.js 16이 공개되었다.
이미 15를 쓰고 있는 팀이라면 “무엇이 좋아졌는가?”보다 먼저
“어떤 부분이 바뀌었고 왜 바뀌었는가?”를 확인하는 게 중요하다.

한눈에 보는 Next.js 16 vs 15

영역	Next.js 15	Next.js 16
요청 관련 API (`params`, `searchParams`, `cookies`, `headers`)	비동기 전환 시작, 동기 접근 임시 허용(경고)	동기 접근 제거, `await` 기반 사용이 사실상 필수
번들러	Turbopack 개발 안정화(`next dev --turbo`)	Turbopack이 `dev/build` 기본값
Cache Components	`experimental.ppr` 기반 흐름 + 암묵적 캐싱 이해 필요	`cacheComponents: true` + `"use cache"` 중심의 명시적 opt-in 캐싱
라우팅/프리패치	기존 prefetch 동작	레이아웃 중복 제거 + incremental prefetching
미들웨어	`middleware.ts` 중심	`proxy.ts` 권장(네트워크 경계 명확화), `middleware.ts`는 deprecated
캐시 API	`revalidateTag(tag)` 단일 인자 사용 가능	`revalidateTag(tag, profile)` 권장/갱신, `updateTag()`/`refresh()` 추가
Next.js Devtools MCP	별도 MCP 연동 없음	`next-devtools-mcp`로 AI 에이전트 디버깅 연동
Logging Improvements	개발/빌드 로그 정보가 상대적으로 제한적	`Compile`/`Render` 구분 + 빌드 단계별 소요 시간 표시
버전 요구사항	Node 18 호환 구간 존재	Node.js 20.9+ / TypeScript 5.1+

16에서 먼저 확인할 변경점

1) Async Request APIs 최종 정리

15에서 경고로 넘어가던 동기 접근은 16에서 더 엄격해졌다.
다음 패턴을 우선 점검한다.

// before
export default function Page({ params }) {
  const slug = params.slug;
  return <div>{slug}</div>;
}

// after
export default async function Page({ params }) {
  const { slug } = await params;
  return <div>{slug}</div>;
}

같은 맥락으로 cookies(), headers(), draftMode()도 await 패턴을 기준으로 마이그레이션한다.

2) `middleware.ts` -> `proxy.ts`

16에서는 proxy.ts가 표준 경로다.
기존 로직은 대부분 유지하고, 파일명/함수명만 전환하면 된다.

// proxy.ts
import { NextRequest, NextResponse } from 'next/server';

export default function proxy(request: NextRequest) {
  return NextResponse.next();
}

3) `revalidateTag()` 시그니처 변경

단일 인자 호출은 deprecated 흐름이다.

import { revalidateTag, updateTag } from 'next/cache';

// SWR 성격의 재검증
revalidateTag('posts', 'max');

// Server Action에서 read-your-writes 보장
updateTag('user-profile');

4) Parallel Routes의 `default.js` 요구

병렬 슬롯은 default.js가 없으면 빌드 실패 가능성이 있다.
기존에 암묵 동작하던 슬롯 구조를 명시적으로 보강해야 한다.

5) 이미지/보안 기본값 변화

next/image 관련 기본 정책(캐시 TTL, quality, redirect 제한, local src 보안 제한 등)이 조정됐다.
이미지 최적화 커스텀을 많이 한 프로젝트는 회귀 테스트가 필요하다.

16에서 체감되는 “좋아진 점”

Cache Components (`"use cache"`)

15까지는 App Router에서 캐싱 동작을 규칙/예외로 이해해야 하는 구간이 많았고,
16은 캐시할 대상을 코드에서 직접 선언하는 방식으로 정리했다.

기본 동작: 페이지/레이아웃/라우트의 동적 코드는 요청 시점에 실행
선택 동작: "use cache"를 선언한 페이지/컴포넌트/함수만 캐시
캐시 키: 컴파일러가 사용 위치 기준으로 키 생성을 보조

또한 Cache Components는 PPR(Partial Prerendering) 흐름을 공식 모델로 통합한다.
즉, URL 전체를 정적/동적으로 이분법 처리하는 대신,
정적 껍질 + 필요한 부분만 동적으로 렌더링하는 구성이 자연스러워진다.

설정은 next.config.ts에서 활성화한다.

const nextConfig = {
  cacheComponents: true,
};

export default nextConfig;

기존에 쓰던 experimental.ppr 계열 설정은 제거되었고,
Cache Components 설정으로 일원화되었다.

Turbopack 기본화

next dev, next build에서 Turbopack이 기본이 되며
프로젝트에 따라 빌드/리프레시 체감 개선이 크다.
단, 커스텀 webpack 의존이 강하면 --webpack 경로를 함께 유지해 단계적으로 전환하는 것이 안전하다.

라우팅/프리패치 개선

레이아웃 중복 다운로드를 줄이고 incremental prefetch를 적용해
요청 수는 늘어도 총 전송량을 낮추는 방향으로 최적화가 들어갔다.

Next.js Devtools MCP

Next.js 16은 Next.js Devtools MCP를 소개했다.
MCP(Model Context Protocol)를 통해 AI 코딩 에이전트가 실행 중인 앱 상태와 로그에 더 직접적으로 접근할 수 있다.

공식 가이드 기준 최소 설정 예시는 다음과 같다.

{
  "mcpServers": {
    "next-devtools": {
      "command": "npx",
      "args": ["-y", "next-devtools-mcp@latest"]
    }
  }
}

이후 pnpm dev / npm run dev처럼 개발 서버를 실행하면 MCP 서버가 앱을 감지해 연결된다.

Logging Improvements

Next.js 16에서는 로그가 “시간이 어디에 쓰였는지”를 더 잘 보여준다.

개발 요청 로그: Compile(라우팅/컴파일)과 Render(코드 실행/React 렌더링) 구분
빌드 로그: TypeScript, 페이지 데이터 수집, 정적 페이지 생성, 최적화 단계별 소요 시간 표시

이 변경으로 dev/build 단계에서 병목 위치를 빠르게 파악하기 쉬워졌다.

참고 자료

https://nextjs.org/blog/next-16

Angular DI(Dependency Injection)에 모든 것: 기초, 계층형 Injector

Sun, 01 Mar 2026 14:40:00 +0900

Angular DI, 이제는 “서비스 가져다 쓰기”에서 끝내지 말자

Angular를 쓰다 보면 DI를 이렇게 이해하기 쉽습니다.

constructor에 서비스 넣기

처음엔 이 정도면 충분합니다. 하지만 프로젝트가 커지면 금방 한계가 옵니다.

이 글에서는 DI를 문법이 아니라 설계 도구로 설명합니다.

Angular 의존성 주입(DI)은 단순한 문법이 아니라, 테스트 용이성과 유지보수성을 동시에 높이는 아키텍처 핵심입니다.

1. 도입: DI란 무엇인가?

DI(Dependency Injection)는 객체가 필요한 의존성을 직접 만들지 않고, 외부에서 주입받는 방식입니다.

핵심은 두 가지입니다.

IoC(제어의 역전): 객체 생성/생명주기 제어를 프레임워크에 위임
Loose Coupling(느슨한 결합): 구체 구현과의 결합을 낮춰 교체를 쉽게 만듦

Bad (DI 미사용)

class PaymentComponent {
  // 컴포넌트가 직접 생성
  private paymentService = new PaymentService();

  checkout() {
    this.paymentService.pay();
  }
}

문제:

테스트에서 Mock으로 바꾸기 어렵습니다.
구현 교체 시 컴포넌트까지 수정됩니다.
컴포넌트가 UI + 생성 책임까지 떠안습니다.

Good (DI 사용)

@Injectable({ providedIn: 'root' })
export class PaymentService {
  pay() {
    // 결제 로직
  }
}

@Component({
  selector: 'app-payment',
  template: `<button (click)="checkout()">결제</button>`,
})
export class PaymentComponent {
  constructor(private paymentService: PaymentService) {}

  checkout() {
    this.paymentService.pay();
  }
}

실무에서 DI가 필수인 이유는 단순합니다.

테스트가 쉬워짐: Mock 주입이 자연스럽다.
유지보수가 쉬워짐: 구현을 갈아껴도 소비자 코드는 안정적이다.
협업이 쉬워짐: 역할이 분리되어 충돌이 줄어든다.

2. Angular DI의 3가지 핵심 요소

Angular DI는 아래 흐름으로 보면 쉽습니다.

Consumer: 의존성을 필요로 하는 쪽 (컴포넌트/서비스)
Dependency: 주입되는 대상 (서비스/설정 객체)
Injector + Provider: 무엇을 어떻게 만들지 결정하고 전달하는 주체

@Injectable({ providedIn: 'root' })
export class UserService {
  getUsers() {
    return [];
  }
}

@Component({
  selector: 'app-user-list',
  template: `<p>Users</p>`,
})
export class UserListComponent {
  // Consumer가 Dependency를 요청
  constructor(private userService: UserService) {}
}

동작 순서:

Consumer가 토큰(UserService)을 요청
Injector가 Provider 설정을 확인
인스턴스를 생성 또는 재사용해 전달

3. [핵심] 계층적 주입(Hierarchical Injectors)

여기서 Angular DI의 실전 감각이 갈립니다. 어디에 Provider를 두느냐가 핵심입니다.

`providedIn: 'root'` vs `@Component({ providers: [...] })`

항목	`providedIn: 'root'`	`@Component({ providers: [...] })`
범위	애플리케이션 전역	해당 컴포넌트 인스턴스 트리
인스턴스	보통 1개(싱글톤)	컴포넌트마다 독립 인스턴스
적합한 대상	인증, 공통 API, 로깅	탭 상태, 위저드 상태, 샌드박스 세션
주의점	전역 상태 오염 가능	과도하게 쪼개면 구조가 복잡해짐

4. 예시

4-1. 탭(Tab) 위젯 상태 분리

Bad (전역 싱글톤 사용)

@Injectable({ providedIn: 'root' })
export class TabStateService {
  activeTab = 'overview';
}

페이지에 탭 위젯이 여러 개 있으면 activeTab이 서로 영향을 줄 수 있습니다.

Good (컴포넌트 레벨 주입)

@Injectable()
export class TabStateService {
  activeTab = 'overview';
}

@Component({
  selector: 'app-tab-group',
  providers: [TabStateService],
  template: `
    <button (click)="state.activeTab = 'overview'">Overview</button>
    <button (click)="state.activeTab = 'settings'">Settings</button>
    <p>현재 탭: </p>
  `,
})
export class TabGroupComponent {
  constructor(public state: TabStateService) {}
}

이제 탭 그룹 인스턴스마다 상태가 분리됩니다.

4.2. 샌드박스 패턴

샌드박스 패턴은 쉽게 말해 “같은 화면의 기능을 서로 독립된 작업실처럼 분리하는 방식”입니다.

코드 실행기, 폼 빌더, 탭형 편집기에서 특히 중요합니다. 한 화면에 인스턴스가 여러 개 떠도 상태가 섞이지 않아야 하기 때문입니다.

Bad (전역 싱글톤 공유)

@Injectable({ providedIn: 'root' })
export class SandboxStateService {
  code = '';
  logs: string[] = [];
}

이 상태에서 샌드박스가 2개 있으면 왼쪽에서 reset했을 때 오른쪽 로그도 같이 지워질 수 있습니다.

Good (컴포넌트 단위 분리)

@Injectable()
export class SandboxStateService {
  code = '';
  logs: string[] = [];

  run() {
    this.logs.push(`run: ${this.code}`);
  }

  reset() {
    this.code = '';
    this.logs = [];
  }
}

@Component({
  selector: 'app-sandbox',
  providers: [SandboxStateService],
  template: `
    <app-sandbox-editor></app-sandbox-editor>
    <app-sandbox-console></app-sandbox-console>
  `,
})
export class SandboxComponent {}

정리하면:

같은 app-sandbox 내부 자식은 같은 상태를 공유
다른 app-sandbox 인스턴스와는 완전히 분리
인스턴스별 reset/run이 가능해 디버깅이 쉬워짐

5. 고급 DI 설정 방법

기본 생성자 주입만으로는 실무 요구를 다 못 맞춥니다. 여기서 Provider 옵션을 꺼내 쓰게 됩니다.

5-1. `useClass`: 구현 교체가 필요할 때

export abstract class Logger {
  abstract log(message: string): void;
}

@Injectable()
export class ConsoleLogger implements Logger {
  log(message: string) {
    console.log('[console]', message);
  }
}

@Injectable()
export class RemoteLogger implements Logger {
  log(message: string) {
    // 서버 전송
  }
}

export const appProviders = [
  { provide: Logger, useClass: ConsoleLogger },
];

언제 쓰나:

개발/운영 구현 교체
레거시 구현에서 새 구현으로 점진 이전

5-2. `useValue`: 설정값(Config), 상수 주입

export interface AppConfig {
  apiBaseUrl: string;
  enableNewCheckout: boolean;
}

export const APP_CONFIG = new InjectionToken<AppConfig>('APP_CONFIG');

const config: AppConfig = {
  apiBaseUrl: 'https://api.example.com',
  enableNewCheckout: true,
};

bootstrapApplication(AppComponent, {
  providers: [{ provide: APP_CONFIG, useValue: config }],
});

언제 쓰나:

환경별 API URL
피처 플래그
빌드 타임/런타임 상수

5-3. `useFactory`: 실행 시점에 값 골라서 주입

쉽게 말하면, 앱이 실행될 때 현재 상황을 보고 값을 결정한 뒤 주입하는 방식입니다.

예를 들어:

로컬 개발이면 로컬 API 주소
스테이징이면 스테이징 API 주소
운영이면 운영 API 주소

이처럼 “미리 고정하기 어려운 값”은 useValue보다 useFactory가 더 맞습니다.

export const API_BASE_URL = new InjectionToken<string>('API_BASE_URL');

export function apiBaseUrlFactory(): string {
  return location.hostname.includes('staging')
    ? 'https://staging-api.example.com'
    : 'https://api.example.com';
}

bootstrapApplication(AppComponent, {
  providers: [{ provide: API_BASE_URL, useFactory: apiBaseUrlFactory }],
});

동작은 이렇게 이해하면 됩니다.

Angular가 API_BASE_URL이 필요하다고 판단
useFactory에 등록된 apiBaseUrlFactory()를 실행
함수가 현재 환경을 보고 URL을 계산해 반환
반환된 값을 의존성으로 주입

언제 쓰나:

호스트/플랫폼에 따라 값 분기
여러 의존성 조합으로 객체 생성

5-4. `InjectionToken`: 인터페이스/값 주입의 핵심

interface는 런타임에 사라집니다. 그래서 Injector 토큰으로 사용할 수 없습니다.

Bad (문자열 토큰)

providers: [{ provide: 'CONFIG', useValue: config }];

Good (`InjectionToken`)

export const APP_CONFIG = new InjectionToken<AppConfig>('APP_CONFIG');
providers: [{ provide: APP_CONFIG, useValue: config }];

장점:

타입 안정성
토큰 충돌 방지
리팩터링 안정성

6. 정리

전역 공유가 필요한가? providedIn: 'root'
컴포넌트 인스턴스마다 분리돼야 하는가? @Component.providers
구현을 바꿔 끼워야 하는가? useClass
상수/설정 주입인가? useValue + InjectionToken
런타임 계산이 필요한가? useFactory
테스트에서 Mock 주입이 쉬운 구조인가? 같은 토큰에 Mock Provider를 주입

Capacitor vs React Native 작동 원리 비교

Sun, 22 Feb 2026 10:30:00 +0900

저는 실무에서 Capacitor를 주로 사용해 왔고, React Native도 한 번 실제 프로젝트에 적용해봤습니다.

이 글은 제가 다시 공식 문서와 기술 블로그를 확인하면서, 두 기술의 작동 원리와 JS-Native 비동기 통신 메커니즘을 한 번에 비교해 정리한 내용입니다.

Capacitor와 React Native는 둘 다 iOS/Android 앱을 만들 수 있지만, 내부 동작 방식은 꽤 다릅니다.

한눈에 보는 결론

웹 코드를 최대한 재사용하고 싶다면: Capacitor
네이티브 UI 성능/일관성을 더 중요하게 본다면: React Native
이미 React 웹팀이 있고 빠르게 앱을 내야 한다면: Capacitor
장기적으로 모바일 UX를 네이티브 수준으로 밀고 싶다면: React Native

1. Capacitor의 작동 원리

Ionic 팀 설명에 따르면 Capacitor는 “웹 앱을 네이티브 앱으로 감싸서 실행”하는 런타임 접근입니다.
즉, 코드를 네이티브로 변환하는 크로스 컴파일러가 아니라, WebView + 네이티브 브리지 구조에 가깝습니다.

구조

웹 앱(HTML/CSS/JS)
  -> iOS WKWebView / Android WebView
      -> Capacitor Bridge
          -> Native Plugin (Swift / Kotlin / Java)

빌드 흐름

제가 Capacitor 프로젝트를 세팅할 때는 보통 아래 순서로 진행합니다.

npx cap add ios / npx cap add android로 네이티브 프로젝트를 한 번 생성
웹 앱 빌드 후 npx cap sync
sync는 내부적으로 copy(웹 자산 복사) + update(플러그인/네이티브 의존성 반영) 수행

Capacitor의 요약

UI 렌더링 주체: 브라우저 엔진(WebView)
네이티브 기능 접근: 플러그인 브리지 호출(Promise 기반)
강점: 기존 웹 코드 재사용성, 빠른 개발 속도
한계: 복잡한 애니메이션/리스트에서 WebView 특성의 한계를 만날 수 있음

2. React Native의 작동 원리

React Native는 WebView 위에서 DOM을 그리는 방식이 아니라, 네이티브 UI 컴포넌트 트리를 직접 다루는 방식입니다.

공식 문서 기준으로 React Native 0.82(2025-10-08)부터는 Legacy Architecture와 기존 Bridge가 제거되고, New Architecture가 기본이 되었습니다.

New Architecture 핵심 구성

React 컴포넌트
  -> JS Runtime(Hermes 등)
      -> JSI
          -> TurboModules (Native API)
          -> Fabric (Native Rendering)

JSI: JS와 네이티브 사이 통신을 기존 직렬화 브리지보다 직접적으로 처리
TurboModules: 필요 시점 로딩(lazy loading) 가능한 네이티브 모듈 시스템
Fabric: React의 최신 렌더링 모델과 맞춰 네이티브 UI 렌더링을 수행

React Native의 요약

UI 렌더링 주체: 네이티브 컴포넌트
네이티브 기능 접근: JSI + TurboModules
강점: 네이티브에 가까운 UI/성능, 대규모 모바일 앱 확장성
한계: 네이티브 빌드/모듈 이해도 요구, 러닝커브 존재

3. JS와 Native가 비동기로 통신하는 메커니즘

핵심은 두 프레임워크 모두 요청 ID를 기준으로, JS의 Promise와 Native 작업 결과를 다시 연결한다는 점입니다.

3-1. Capacitor의 비동기 통신 흐름

JS(Plugin.call)
  -> Bridge에 plugin/method/options 전달
  -> Native Plugin 실행(백그라운드 작업 가능)
  -> 결과와 callbackId로 resolve/reject 반환
  -> WebView JS 런타임에서 Promise 완료

실제 흐름을 풀어서 보면 다음 순서입니다.

JS에서 Camera.getPhoto() 같은 플러그인 메서드를 호출하면 Promise가 생성됩니다.
Bridge는 pluginId, methodName, options, callbackId를 Native 쪽으로 전달합니다.
Native 플러그인이 실제 OS API를 비동기로 수행합니다.
완료 시 callbackId를 포함해 성공/실패 결과를 Bridge로 돌려보냅니다.
JS 런타임이 해당 Promise를 resolve/reject합니다.

즉, WebView 메인 스레드를 오래 점유하지 않도록 Native 작업을 비동기로 처리하고, 완료 시점에만 JS 이벤트 루프로 결과를 되돌립니다.

3-2. React Native(New Architecture)의 비동기 통신 흐름

JS(TurboModule method)
  -> JSI 경유 C++/Native 영역 진입
  -> Native에서 작업 큐로 비동기 처리
  -> CallInvoker 등을 통해 JS 런타임으로 완료 콜백 전달
  -> Promise resolve/reject + 필요 시 Fabric으로 UI 반영

New Architecture에서는 Legacy Bridge의 JSON 직렬화 왕복 대신 JSI 기반 통신을 사용합니다.

JS가 TurboModule 메서드를 호출합니다.
JSI를 통해 Native 코드에 진입합니다.
시간이 걸리는 작업은 Native 스레드/큐에서 비동기로 수행합니다.
완료 콜백을 JS 런타임 큐로 다시 보내 Promise를 완료합니다.
결과로 UI 상태가 바뀌면 Fabric 렌더링 파이프라인에서 네이티브 UI 업데이트가 적용됩니다.

참고로 React Native는 일부 가벼운 API는 동기 호출도 가능하지만, 네트워크/파일 I/O/디스크 접근처럼 시간이 걸리는 작업은 비동기로 처리하는 것이 기본입니다. JS 스레드를 막지 않기 위해서입니다.

3-3. 공통 원리

요청-응답 상관관계: callbackId 또는 내부 요청 핸들로 매칭
스레드 분리: 오래 걸리는 Native 작업은 JS 메인 흐름 밖에서 처리
Promise 기반 복귀: JS 쪽에서는 await 패턴으로 동일하게 소비
이벤트 통신: 단발 응답 외에 센서/위치처럼 스트리밍은 listener 패턴 사용

4. Capacitor vs React Native 비교

비교 항목	Capacitor	React Native
UI 렌더링	WebView 내부 DOM/CSS	네이티브 UI 컴포넌트
네이티브 API 호출	Capacitor Bridge + Plugin	JSI + TurboModules
JS-Native 비동기 통신	callbackId 기반 Promise 완료	JSI+TurboModule+CallInvoker 기반 Promise 완료
웹 코드 재사용	매우 높음(기존 웹 앱 활용 용이)	로직 재사용은 좋지만 UI는 별도 구성
UI 성능 특성	일반 앱은 충분, 고난도 UI에서 제약 가능	고난도 인터랙션/리스트에서 유리
개발 진입장벽	웹 개발자에게 낮음	모바일/네이티브 개념 학습 필요
팀 구성 적합성	웹팀 중심 조직	모바일 제품 조직(장기 운영)에 유리

5. 어떤 경우에 무엇을 선택할까?

Capacitor가 맞는 경우

기존 React/Vue/Angular 웹 서비스를 앱으로 빠르게 확장해야 함
한 팀이 웹과 앱을 동시에 운영해야 함
앱의 핵심 가치가 복잡한 네이티브 인터랙션보다 서비스 확장 속도에 있음

React Native가 맞는 경우

모바일 UX 품질과 퍼포먼스가 제품 경쟁력 핵심임
장기적으로 모바일 전용 기능과 고성능 화면이 계속 늘어날 예정임
네이티브 모듈 연동/최적화를 감당할 팀 역량이 있음

제 경험으로는, 초기 출시 속도와 웹 자산 재사용이 중요할 때는 Capacitor가 정말 빠르게 성과를 냈고, 화면 복잡도와 인터랙션 품질을 더 밀어야 하는 상황에서는 React Native 접근이 더 설득력 있었습니다.

참고 자료

Ionic Blog: How Capacitor Works
Capacitor Docs: JavaScript to Native
React Native Docs: React Native Architecture, What is React Native?
React Native Blog: The New Architecture is here

[Next.js] App Router에서 서버/클라 경계 설계 실수 TOP 7 (실무 패턴 + 샘플)

Sun, 15 Feb 2026 11:03:00 +0900

왜 “서버/클라 경계”가 App Router의 핵심인가?

App Router(Next.js 13+)는 기본이 Server Component입니다.
즉, 컴포넌트가 어디서 실행되는지(서버/브라우저)에 따라 가능한 API, 번들 크기, 렌더링 방식이 크게 달라집니다.

실무에서 문제는 보통 이 셋으로 귀결됩니다.

클라에서 해야 할 일을 서버에서 하려다 깨짐
서버에서 할 수 있는 일을 클라로 끌고 와서 성능/보안 손해
Provider/상태/이벤트 때문에 경계가 무너짐

아래 TOP 7은 가장 자주 터지는 패턴 + 바로 적용 가능한 해결책입니다.

TOP 1. `use client`를 습관처럼 붙여서 “페이지 전체를 클라”로 만들어버림

증상

페이지 전체 번들이 커짐(초기 로딩/INP 악화)
서버 패칭/캐시/SEO 이점이 사라짐

안 좋은 예(샘플)

// app/dashboard/page.tsx
'use client';

import {useEffect, useState} from 'react';

export default function DashboardPage() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/stats').then(r => r.json()).then(setData);
  }, []);

  return <pre>{JSON.stringify(data, null, 2)}</pre>;
}

권장 패턴: 서버는 데이터/조합, 클라는 인터랙션만(샘플)

// app/dashboard/page.tsx (Server Component)
import DashboardClient from './DashboardClient';

async function getStats() {
  const res = await fetch('https://internal-api.example.com/stats', {
    cache: 'no-store',
  });
  return res.json();
}

export default async function DashboardPage() {
  const stats = await getStats();
  return <DashboardClient initialStats={stats}/>;
}

// app/dashboard/DashboardClient.tsx (Client Component)
'use client';

import {useState} from 'react';

export default function DashboardClient({initialStats}: { initialStats: any }) {
  const [stats, setStats] = useState(initialStats);

  return (
    <>
      <h1>Dashboard</h1>
      <button onClick={() => setStats({...stats, refreshedAt: Date.now()})}>
        새로고침(샘플)
      </button>
      <pre>{JSON.stringify(stats, null, 2)}</pre>
    </>
  );
}

핵심: use client는 “페이지 전체”가 아니라 딱 필요한 컴포넌트에만. 하지만 꼭 최적화를 할 필요는 없다 작은 페이지/컴포넌트는 use client로 빠르게 개발해도 무방

TOP 2. Server Component에 이벤트/상태/브라우저 API를 섞어버림

증상

onClick 넣자마자 에러
window, document, localStorage 접근 시 런타임 에러

올바른 분리(샘플)

// app/products/page.tsx (Server)
import FilterBar from './FilterBar';

export default async function ProductsPage() {
  const initialFilters = {q: '', onlySale: false};
  return (
    <>
      <h1>Products</h1>
      <FilterBar initialFilters={initialFilters}/>
    </>
  );
}

// app/products/FilterBar.tsx (Client)
'use client';

import {useState} from 'react';

export default function FilterBar({initialFilters}: { initialFilters: any }) {
  const [filters, setFilters] = useState(initialFilters);

  return (
    <div>
      <input
        value={filters.q}
        onChange={(e) => setFilters({...filters, q: e.target.value})}
        placeholder="검색"
      />
      <label>
        <input
          type="checkbox"
          checked={filters.onlySale}
          onChange={(e) => setFilters({...filters, onlySale: e.target.checked})}
        />
        세일만
      </label>
    </div>
  );
}

TOP 3. 데이터 패칭을 전부 클라로 내려서 SSR/캐시 이점을 다 날림

증상

초기 화면은 스피너만 보임(UX 저하)
중복 호출/레이스 컨디션이 늘어남
SEO/공유 메타에서 빈 화면처럼 보일 수 있음

서버에서 패칭(샘플)

// app/posts/page.tsx
export default async function PostsPage() {
  const posts = await fetch('https://api.example.com/posts', {
// 상황에 따라 선택:
// cache: 'force-cache',
// next: { revalidate: 60 },
    cache: 'no-store',
  }).then(r => r.json());

  return (
    <ul>
      {posts.map((p: any) => <li key={p.id}>{p.title}</li>)}
    </ul>
  );
}

TOP 4. Provider를 Root에 박아서 전부 Client로 “전염”시킴

증상

layout까지 use client 필요 → 앱 전체가 클라화
번들/JS 실행 비용 증가

권장 패턴: Providers를 전용 파일로 분리(샘플)

// app/providers.tsx
'use client';

import {ReactNode, useState} from 'react';
import {QueryClient, QueryClientProvider} from '@tanstack/react-query';

export default function Providers({children}: { children: ReactNode }) {
  const [client] = useState(() => new QueryClient());
  return <QueryClientProvider client={client}>{children}</QueryClientProvider>;
}

// app/layout.tsx (Server)
import Providers from './providers';

export default function RootLayout({children}: { children: React.ReactNode }) {
  return (
    <html lang="ko">
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  );
}

TOP 5. Server Action을 “만능 API”처럼 쓰다가 UX/경계가 꼬임

현실적인 정리

Server Actions는 특히 폼 기반 뮤테이션(저장/수정)에 적합
조회(Read)는 서버 패칭/캐시 설계와 조합하는 편이 안정적
TanStack Query 같은 클라이언트 데이터 라이브러리로도 충분히 커버 가능

폼 업데이트(샘플)

// app/settings/actions.ts
'use server';

export async function updateProfile(formData: FormData) {
  const nickname = String(formData.get('nickname') ?? '');
// await db.user.update(...)
  return {ok: true};
}

// app/settings/page.tsx
import {updateProfile} from './actions';

export default function SettingsPage() {
  return (
    <form action={updateProfile}>
      <label>
        닉네임
        <input name="nickname"/>
      </label>
      <button type="submit">저장</button>
    </form>
  );
}

TOP 6. `process.env`를 클라에서 써서 비밀값 노출/빌드 문제 발생

규칙

클라에 노출해도 되는 값만 NEXT_PUBLIC_ 접두사
그 외는 서버에서만 사용(Server Component/Route Handler/Server Action)

좋은 예(샘플)

// 공개 가능
const publicKey = process.env.NEXT_PUBLIC_MAP_KEY;

// 서버에서만
export async function GET() {
  const secret = process.env.API_SECRET;
  return Response.json({ok: true});
}

TOP 7. Hydration mismatch를 운빨로 치부하고 땜질만 함

대표 원인

서버 렌더와 클라 렌더 결과가 달라지는 값
- new Date(), Math.random(), locale 포맷 등
localStorage 기반 테마 같은 “클라 전용 상태”를 즉시 렌더

해결 패턴 1: 마운트 후에만 값 반영(샘플)

'use client';
import {useEffect, useState} from 'react';

export default function Now() {
  const [now, setNow] = useState<string | null>(null);

  useEffect(() => {
    setNow(new Date().toISOString());
  }, []);

  return <span>{now ?? '...'}</span>;
}

해결 패턴 2: 서버에서 값 고정해서 내려주기(샘플)

// Server Component
export default function Page() {
  const serverNow = new Date().toISOString();
  return <ClientNow serverNow={serverNow}/>;
}

'use client';
export default function ClientNow({serverNow}: { serverNow: string }) {
  return <span>{serverNow}</span>;
}

실무 팁: 코드리뷰에서 바로 쓰는 체크 질문

이 컴포넌트는 정말 Client여야 하나? (이벤트/상태/브라우저 API가 있나?)
데이터 패칭을 클라로 내린 이유가 있는가? (SEO/TTFB/중복 호출 고려했나?)
Provider 범위는 최소인가? (Root까지 전염시키지 않았나?)
env는 NEXT_PUBLIC_만 클라로 나갔나?
Hydration mismatch 가능성이 있는 값(Date/Random/Locale)은 어디서 계산했나?
“수정”은 Server Action, “조회”는 서버 패칭으로 분리했나?

React useEffect 실수 TOP3 정리 + useEffectEvent로 의존성/스테일 클로저 해결하기

Sun, 08 Feb 2026 16:33:00 +0900

useEffect 한 줄 정의: “외부 시스템과 동기화”

React 공식 문서의 핵심 관점은 단순합니다.

useEffect는 React 바깥(외부 시스템) 과 컴포넌트를 동기화할 때 쓰는 “탈출구(escape hatch)”다.
외부 시스템이 없다면, Effect가 필요 없을 가능성이 높다.

(공식 문서: You Might Not Need an Effect)

실무에서 자주 하는 useEffect 실수 TOP3

1) 불필요한 useEffect 사용 (derived state / 렌더 계산을 effect로 처리)

가장 흔한 패턴이 “상태를 또 다른 상태로 동기화”하는 코드입니다.

❌ 안 좋은 예: state를 effect로 ‘복제’

const [first, setFirst] = useState("");
const [last, setLast] = useState("");
const [fullName, setFullName] = useState("");

useEffect(() => {
  setFullName(`${first} ${last}`);
}, [first, last]);

이 경우 외부 시스템이 없고, 단순 계산이라서 렌더링 중 계산이 더 적합합니다.
불필요한 Effect는 코드 흐름을 복잡하게 만들고 버그(렌더 타이밍/의존성)를 늘립니다. 간단한 state는 가독성이 괜찮지만 프로젝트가 복잡할 시 가독성은 급격히 떨어지고 사이드이펙트가 늘어나 디버깅하기가 어렵습니다.

“렌더링을 위한 데이터 변환”은 Effect가 아니라 렌더 계산으로 해결하는 게 우선입니다.

(공식 문서: Updating state based on props or state)

2) 의존성 배열(deps) 실수 (과도한 재실행 / 누락 / 객체·함수 deps)

의존성 배열 관련 실수는 크게 2가지로 나뉩니다.

(A) 객체/함수 deps로 인해 effect가 “쓸데없이 자주” 재실행

컴포넌트 내부에서 만든 객체/함수는 렌더마다 새로 만들어질 수 있어, deps에 넣으면 effect가 불필요하게 반복됩니다.

useEffect(() => {
  // ...
}, [options]); // options가 렌더마다 새 객체면 매번 실행될 수 있음

✅ 개선 방향(공식 문서 권장 요지)

불필요한 객체/함수 의존성 제거
외부로 빼거나, 필요한 “원시 값”만 deps에 넣기
“반응형(reactive) 로직”과 “비반응형(non-reactive) 로직” 분리 고려

(공식 문서: useEffect Caching expensive calculations)

(B) deps 누락으로 인한 stale closure(스테일 클로저) / 의도치 않은 동작

deps를 “비워서([])” 고정하거나, 필요한 값을 빠뜨리면 Effect 내부에서 오래된 state/props 를 참조하는 문제가 생길 수 있습니다.

이 지점에서 useEffectEvent가 매우 유용합니다. (아래에서 자세히)

3) cleanup 누락 (특히 Strict Mode에서 더 잘 드러남)

구독/이벤트/타이머처럼 “설치(setup)”를 했다면, 반드시 해제(cleanup) 해야 합니다.

대표 케이스

setInterval / clearInterval
addEventListener / removeEventListener
소켓 연결 / 해제
서드파티 위젯 초기화 / 제거

useEffect(() => {
  const id = setInterval(() => {
    // ...
  }, 1000);

  return () => clearInterval(id);
}, []);

또한 React Strict Mode(개발 모드)에서는 setup + cleanup을 한 번 더 실행해서 cleanup이 제대로 “대칭”인지 점검합니다.
cleanup이 빠져 있으면 개발 환경에서 문제(중복 구독/중복 타이머)가 더 빨리 튀어나옵니다.

(공식 문서: useEffect Sharing logic between event handlers)

useEffectEvent 추가: “최신 state/props는 읽고 싶지만, effect를 재실행하진 않게”

문서: https://react.dev/reference/react/useEffectEvent

useEffectEvent란?

useEffectEvent는 Effect 내부에서 사용하는 로직 중, 반응형(reactive)으로 다루고 싶지 않은 부분을 분리해 “Effect Event”라는 함수로 만들 수 있게 해주는 Hook입니다.

공식 문서가 강조하는 대표 목적은:

Effect 안에서 최신 props/state 읽기
하지만 그 값 때문에 Effect 자체가 다시 실행되게 만들지 않기

(공식 문서: useEffectEvent)

언제 유용한가? (실전 시나리오)

“roomId가 바뀔 때만” 서버 연결을 다시 하고 싶다
그런데 연결 과정에서 “최신 알림 설정/유저 정보” 같은 값도 쓰고 싶다
그 값들을 deps에 넣으면 effect가 너무 자주 재실행됨 → 원치 않는 재연결/재구독

이런 상황에서 useEffectEvent로 “최신 값 읽기”를 분리하면, deps는 깔끔하게 유지하면서 stale closure를 줄일 수 있습니다.

예시 패턴: reactive deps는 최소화 + 최신 값은 Effect Event로 읽기

(아래 예시는 “형태”를 보여주는 샘플입니다)

import { useEffect, useState } from "react";
import { useEffectEvent } from "react";

function ChatRoom({ roomId, soundEnabled }) {
  // ✅ 최신 값을 읽되, 이것 때문에 effect가 재실행되진 않도록 분리
  const onMessage = useEffectEvent((message) => {
    if (soundEnabled) {
      // 최신 soundEnabled를 사용
      playSound();
    }
    showToast(message);
  });

  useEffect(() => {
    const connection = createConnection(roomId);

    connection.on("message", (msg) => {
      onMessage(msg); // 최신 값을 안전하게 사용
    });

    connection.connect();
    return () => connection.disconnect();
  }, [roomId]); // ✅ roomId만 바뀔 때 재연결
}

핵심 포인트:

Effect는 “외부 시스템과의 동기화(연결/해제)”만 담당
“최신 옵션/상태 읽기”는 useEffectEvent로 분리
deps가 과도하게 커지지 않아서 의도한 타이밍만 재실행됨

체크리스트: useEffect 쓰기 전에 한번 생각 해보기

외부 시스템 동기화인가? (DOM API/구독/네트워크/타이머/서드파티 위젯)
단순 계산/파생 값이면 렌더에서 계산할 수 없는가?
유저 클릭/입력 등 “이벤트”라면 이벤트 핸들러에서 처리하는 게 맞지 않은가?
setup을 했다면 cleanup이 대칭으로 존재하는가?
deps에 객체/함수가 들어가서 불필요한 재실행을 만들고 있지 않은가?
deps 누락으로 stale closure 위험이 있지 않은가?
“최신 값은 필요하지만 재실행은 싫다”면 useEffectEvent로 분리할 수 있는가?

요약

useEffect는 “외부 시스템 동기화”를 위한 도구다.
실수 TOP3는 보통 불필요한 Effect, deps 실수, cleanup 누락에서 터진다.
deps가 커지거나 stale closure가 고민이라면, useEffectEvent로 비반응형 로직을 분리해서 “재실행 타이밍”과 “최신 값 읽기”를 동시에 만족시킬 수 있다.

공식 문서

useEffectEvent: https://react.dev/reference/react/useEffectEvent
useEffect: https://react.dev/reference/react/useEffect
You Might Not Need an Effect: https://react.dev/learn/you-might-not-need-an-effect

[React] react-error-boundary 완벽 정리: ErrorBoundary는 만능이 아니다 (언제 써야 할까?)

Sat, 07 Feb 2026 14:20:00 +0900

React ErrorBoundary(Error Boundary)란?

React에서 컴포넌트가 렌더링 중 에러를 던지면, 화면 전체가 깨지거나(화이트 스크린) 앱이 멈춰 보일 수 있습니다.
ErrorBoundary는 이런 상황에서 하위 컴포넌트 트리에서 발생한 렌더링 에러를 포착하고, 앱 전체가 죽지 않도록 대체 UI(fallback UI) 를 보여주는 “UI 안전장치”입니다.

핵심: ErrorBoundary는 에러 처리 로직이 아니라, 렌더링 붕괴를 막는 UI 보호막에 가깝습니다.

ErrorBoundary가 잡아주는 에러 범위 (✅ 되는 것)

ErrorBoundary가 포착할 수 있는 대표 케이스는 아래와 같습니다.

컴포넌트 렌더링(render) 과정에서 발생한 에러
클래스 컴포넌트 기준 생명주기(lifecycle) 에서 발생한 에러
자식 컴포넌트 트리 내부에서 발생한 에러

예시:

<ErrorBoundary>
  <MyComponent />
</ErrorBoundary>

MyComponent가 렌더링 중 예외를 던지면, ErrorBoundary가 fallback UI로 대체 렌더링합니다.

ErrorBoundary는 만능이 아니다 (❌ 안 되는 것)

많이 하는 오해는 “ErrorBoundary로 감싸면 앱 에러가 다 잡힌다”인데, 그렇지 않습니다.
ErrorBoundary는 React 렌더링 사이클 안에서 발생한 에러만 안전하게 다룰 수 있습니다.

ErrorBoundary가 잡지 못하는 대표 케이스

1) 이벤트 핸들러 내부 에러

onClick, onChange 등 사용자 액션 핸들러에서 발생한 예외

2) 비동기 코드의 에러

setTimeout, Promise, async/await 내부에서 발생한 예외

3) SSR(서버 사이드 렌더링) 중 에러

4) ErrorBoundary 자신에서 발생한 에러

왜 이벤트/비동기 에러는 ErrorBoundary로 안 잡힐까?

ErrorBoundary는 렌더링 중 발생한 예외를 기준으로 “fallback UI로 교체”하는 방식입니다.

렌더링 중 에러: React가 UI 트리를 다시 그리면서 대체 가능 ✅
이벤트/비동기 에러: 렌더링이 끝난 뒤 발생 → React가 자동으로 UI를 교체할 컨텍스트가 없음 ❌

즉, ErrorBoundary는 “렌더링 단계의 안전장치” 이고,
이벤트/비동기 단계의 에러는 별도 전략이 필요합니다.

React 에러 처리 실전 전략 (ErrorBoundary + 직접 처리)

1) 이벤트 핸들러 에러 처리: try/catch로 직접 잡기

function handleClick() {
  try {
    // 위험한 로직
  } catch (error) {
    console.error(error);
    // 필요하면 사용자에게 토스트/알림 표시
  }
}

2) 비동기 에러 처리: Promise 체인/async 처리로 잡기

async function fetchData() {
  try {
    const res = await fetch("/api/data");
    if (!res.ok) throw new Error("Network error");
    return await res.json();
  } catch (error) {
    console.error(error);
    // 상태로 에러를 관리하거나, 재시도 UI를 제공
  }
}

네트워크 에러/비동기 에러는 대개 ErrorBoundary보다
TanStack Query이나 로딩/에러 상태(state) 기반 UI 패턴으로 처리하는 쪽이 가독성이 좋습니다.

언제 ErrorBoundary를 써야 할까? (판단표)

상황	ErrorBoundary 사용
렌더링 에러(컴포넌트 JSX 평가 중)	✅
생명주기 에러(클래스 컴포넌트 기준)	✅
이벤트 핸들러(onClick 등) 에러	❌
비동기(Promise/async/timeout) 에러	❌
API 요청 실패/서버 응답 오류	❌ (직접 처리 권장)
특정 섹션만 깨져도 되는 UI 보호	✅ (강력 추천)

ErrorBoundary 적용 위치: “전체 감싸기”보다 “구역 감싸기”

실무에서는 App 전체를 1개 ErrorBoundary로 감싸기보다, 깨졌을 때 영향 범위를 줄이고 싶은 구역에 배치하는 게 효율적입니다.

요약

ErrorBoundary는 렌더링 에러 전용 안전장치다.
이벤트/비동기/SSR 에러는 별도 처리가 필요하다.
실무에서는 페이지/섹션 단위로 적용해 장애 범위를 줄이는 게 핵심이다.
ErrorBoundary는 “에러 처리 만능키”가 아니라 “UI 붕괴 방지용 보호막”이다.

찬희의 Frontend Notes

JavaScript 2026 정리: ES2025, Node.js, React, Next.js에서 알아야 할 변화

2026년 자바스크립트에서 먼저 봐야 할 변화

ES2025에서 알아둘 기능

1. Iterator Helpers

2. Set Methods

3. RegExp.escape()

4. Promise.try()

5. Import Attributes

ES2026 후보 중에서 특히 중요한 것

1. Temporal API

2. Explicit Resource Management

2026년 런타임에서 봐야 할 것

1. Node.js는 이제 TypeScript 실행 경험을 직접 제공한다

2. Bun과 Deno는 계속 Node를 압박하고 있다

빌드 도구는 결국 Vite 중심으로 모이고 있다

1. Vite 8

2. webpack은 끝난 것이 아니라, 기본값에서 밀려난 것이다

프레임워크 흐름도 같이 봐야 한다

1. React 19.2

2. Next.js 16

3. 프레임워크를 볼 때 중요한 질문

TypeScript도 같이 봐야 한다

그래서 지금 무엇을 공부해야 할까

1. ES2025 실전 기능

2. 날짜와 시간 처리의 새 기준

3. 런타임 감각

4. 빌드 도구와 프레임워크 연결

정리

참고 자료

antd vs shadcn/ui 비교: 어떤 React UI를 선택해야 할까?

요약

antd와 shadcn/ui의 핵심 차이

1. 설치와 시작 속도

antd: 바로 쓸 수 있는 완성형

shadcn/ui: 필요한 것만 가져오는 방식

2. 커스터마이징은 누가 더 쉬운가?

antd: 토큰 기반 커스터마이징

shadcn/ui: 코드 직접 수정

3. 디자인 일관성과 기본 완성도

antd는 “정해진 시스템”이 강하다

shadcn/ui는 “좋은 출발점”에 가깝다

4. 컴포넌트 범위와 실무 생산성

antd는 특히 Form/Table 계열이 강하다

shadcn/ui는 필요한 것만 쌓는 방식

5. 번들, 런타임, 성능 관점

antd

shadcn/ui

6. 어떤 팀에 무엇이 맞을까?

antd가 더 잘 맞는 팀

shadcn/ui가 더 잘 맞는 팀

7. 내 기준 추천

antd를 고를 때

shadcn/ui를 고를 때

최종 정리

참고 자료

React와 Next.js를 위한 완벽한 Codex 설정

결론부터: Codex는 “설정”보다 “작업 환경 설계”가 중요하다

왜 React와 Next.js에서 특히 설정이 중요할까

1. 가장 먼저 해야 할 일: AGENTS.md를 제대로 적기

2. “무엇을 기억해야 하는가”를 규칙으로 분리하기

3. 공식 문서를 우선 참조하게 만들어라

4. ESLint와 TypeScript는 선택이 아니라 필수다

5. 테스트 기반 루프를 만들면 Codex가 훨씬 안정적이다

6. 작업 단위는 작게 쪼개야 한다

7. React/Next.js용 Codex 프롬프트는 이렇게 바꾸는 게 좋다

8. 내가 추천하는 React/Next.js용 Codex 기본 체크리스트

마무리

ChatGPT vs Gemini 비교: 프론트엔드 개발자에게 어떤 AI가 더 좋을까?

요약

ChatGPT vs Gemini 한눈에 비교

ChatGPT와 Gemini 차이: 프론트엔드 개발자 기준 비교 포인트

ChatGPT vs Gemini 코딩 비교: React 리팩터링은 누가 더 편할까?

UI 초안 생성은 ChatGPT가 더 빠른 편이다

긴 문서 요약과 긴 로그 분석은 Gemini가 더 잘 맞는다

Next.js에서 AI 기능 붙일 때는 Gemini가 실험 속도가 빠르다

그래서 프론트엔드 개발자는 무엇을 먼저 써야 할까?

ChatGPT가 더 잘 맞는 사람

Gemini가 더 잘 맞는 사람

둘을 같이 쓰는 것이 맞는 사람

`antd`를 고를 때

`shadcn/ui`를 고를 때

1. 가장 먼저 해야 할 일: `AGENTS.md`를 제대로 적기

2) `middleware.ts` -> `proxy.ts`

3) `revalidateTag()` 시그니처 변경

4) Parallel Routes의 `default.js` 요구

Cache Components (`"use cache"`)

`providedIn: 'root'` vs `@Component({ providers: [...] })`

5-1. `useClass`: 구현 교체가 필요할 때

5-2. `useValue`: 설정값(Config), 상수 주입

5-3. `useFactory`: 실행 시점에 값 골라서 주입

5-4. `InjectionToken`: 인터페이스/값 주입의 핵심

Good (`InjectionToken`)