지금 React와 Next.js 생태계에서 동시다발적으로 일어나고 있는 변화들을 각각 따로 보면 '새로운 API 하나 더 배워야 하나' 정도로 느껴질 수 있다. 그런데 Server Action, useEffectEvent, 그리고 모노레포 전략을 하나의 흐름으로 연결해서 보면 이야기가 달라진다. 이 세 가지는 각기 다른 레이어에서 같은 문제를 해결하고 있다. 불필요한 복잡도를 걷어내고, 코드가 의도를 직접 드러내게 만들며, AI 에이전트가 전체 맥락을 한 번에 파악할 수 있는 구조를 만드는 것이다.
Server Action: API Route라는 간접층을 제거하다
velog에 올라온 Server Action 정리 글을 보면, 핵심은 단순하다. 'use server' 디렉티브로 선언한 함수가 곧 서버 엔드포인트가 된다. form의 action prop에 직접 넘기면 FormData를 자동으로 받고, onClick 같은 이벤트 핸들러에서 await로 호출하는 것도 가능하다. 기존에 API Route 파일을 별도로 만들고, fetch로 호출하고, 에러를 핸들링하던 그 모든 보일러플레이트가 함수 하나로 수렴된다.
주목할 디테일이 두 가지 있다. 첫째, revalidatePath와 redirect()의 호출 순서다. redirect()는 내부적으로 즉시 throw되기 때문에 반드시 revalidate를 먼저 호출해야 한다. 순서를 바꾸면 캐시 무효화가 일어나지 않은 채 리다이렉트된다. 이런 암묵적 규칙은 문서를 꼼꼼히 읽지 않으면 놓치기 쉽다. 둘째, useActionState의 세 번째 반환값인 pending이다. 로딩 상태를 위해 별도 useState를 두고 try/finally로 관리하던 패턴이 단 한 줄로 대체된다. DX 개선이라는 말이 이렇게 구체적으로 느껴지는 경우가 많지 않다.
프론트엔드 개발자 입장에서 Server Action이 가져오는 가장 큰 변화는 서버 로직을 '어디에 쓰느냐'의 문제가 사라진다는 점이다. API Route는 파일 시스템 기반 라우팅이라는 Next.js의 규칙과 서버 로직을 분리해서 관리하게 만들었다. Server Action은 컴포넌트 파일과 같은 맥락 안에서—혹은 명시적으로 분리한 actions.ts 파일에서—서버 로직을 직접 다룰 수 있게 한다. 코드를 읽는 흐름이 UI에서 데이터로 끊기지 않고 이어진다.
useEffectEvent: 의존성 배열이라는 미로를 빠져나오다
useEffect의 의존성 배열은 React를 처음 배우는 사람들이 가장 먼저 막히는 지점이고, 오래 써온 사람들도 여전히 실수하는 부분이다. velog의 useEffectEvent 번역 글이 다루는 문제는 전형적인 케이스다. 타이머를 유지하면서 최신 userName을 참조하려면, 의존성 배열에 userName을 넣으면 타이머가 리셋되고, 빼면 stale closure가 생긴다. 기존 해결책은 useRef였는데, 이건 동작은 하지만 읽는 사람이 의도를 파악하기 위해 한 번 더 머릿속에서 번역해야 하는 코드다.
useEffectEvent는 이 문제를 개념적으로 다르게 접근한다. "이 값은 effect의 타이밍에 영향을 주는 게 아니라, 실행 시점에 최신 값을 읽으면 되는 것"이라는 구분이다. useEffectEvent로 감싼 함수는 항상 최신 클로저를 참조하면서도 의존성 배열에 포함되지 않는다. 타이머 설정이라는 effect의 본질적인 로직과, 그 안에서 사용하는 상태값을 읽는 로직이 명시적으로 분리된다.
아직 실험적 API라는 점은 감안해야 하지만, 이 훅이 stable로 전환되는 순간 useRef 우회 패턴은 상당 부분 교체 대상이 될 것이다. 더 중요한 건 이 변화가 가리키는 방향이다. React 팀은 개발자가 '규칙을 지키면서 원하는 동작을 구현하기 위해 우회로를 찾는' 경험을 줄이려 하고 있다. useActionState, useOptimistic, 그리고 useEffectEvent—이 흐름은 일관되다.
모노레포: AI 에이전트를 위한 컨텍스트 통합
dev.to에 올라온 'Rethinking Architecture in the AI Era' 시리즈 첫 번째 글은 모노레포를 AI 시대의 기본 아키텍처 선택으로 제안한다. 저자의 논거는 흥미롭다. 기존에 모노레포를 선택하는 이유가 '공유 패키지 관리'나 '빌드 효율화'였다면, 이제는 여기에 AI 에이전트의 컨텍스트 관리라는 이유가 추가된다는 것이다.
AI 코딩 에이전트는 컨텍스트 범위 안에 있는 것만 '알 수 있다'. 프론트엔드 레포와 백엔드 레포가 분리되어 있으면, 에이전트는 두 레포를 넘나드는 피처를 구현할 때 반쪽짜리 맥락으로 작업한다. Turborepo 기반 모노레포에서는 apps/web(Next.js), apps/api(백엔드), packages/ui(공유 컴포넌트), 그리고 .claude/CLAUDE.md와 specs/ 같은 에이전트 지시 파일까지 하나의 레포에 존재한다. 클론 한 번으로 에이전트가 필요한 전체 지식 베이스가 갖춰진다.
저자가 언급하는 또 다른 실질적 포인트는 PR 워크플로우다. 모노레포에서 AI가 코드를 짜면 프론트엔드와 백엔드 변경이 하나의 PR에 묶인다. 기존의 레이어별 리뷰 관행을 그대로 유지하면 사람이 병목이 된다. 구조를 바꿨으면 프로세스도 함께 바꿔야 한다는 것—이건 기술 선택의 문제가 아니라 팀 운영 설계의 문제다.
세 변화가 가리키는 하나의 방향
Server Action은 데이터 변경의 간접층을 제거하고, useEffectEvent는 상태 관리의 우회로를 제거하며, 모노레포는 컨텍스트 분산을 제거한다. 공통점은 제거다. 더 많은 기능을 추가하는 게 아니라, 복잡도를 발생시키는 구조적 원인을 걷어내는 방향이다.
AI 도구를 쓴다는 건 프롬프트를 잘 치는 것만이 아니다. 에이전트가 실수 없이 빠르게 움직일 수 있는 코드베이스를 설계하는 것—그게 지금 프론트엔드 개발자에게 주어진 진짜 질문이다. Server Action으로 API Route를 줄이고, useEffectEvent로 effect 로직을 명확하게 하고, 모노레포로 컨텍스트를 통합하는 것은 사람이 읽기 좋은 코드와 AI가 다루기 좋은 코드베이스가 결국 같은 방향이라는 걸 보여준다. 좋은 설계는 도구가 바뀌어도 좋은 설계다.