삭제하는 코드가 늘었다면, 그건 좋은 신호다
요즘 React 코드베이스를 열면 이상한 기분이 든다. 새로 추가하는 코드보다 지우는 코드가 더 많다. useMemo, useCallback, forwardRef, <Context.Provider>—한때 '잘 짜는 개발자'의 표식이었던 패턴들이 하나씩 불필요해지고 있다. dev.to에서 화제가 된 Things I Stopped Writing in React는 이 변화를 다섯 가지 구체적인 사례로 정리한다. 단순한 문법 변경이 아니다. React가 개발자에게 요구하는 인지 부하 자체가 달라지고 있다는 신호다.
React 19가 손에서 뺏어간 것들
변화의 핵심은 React Compiler다. 빌드 타임에 컴포넌트를 분석해 메모이제이션을 자동으로 처리한다. useMemo로 감싼 필터 로직, useCallback으로 묶은 이벤트 핸들러—이제 그냥 평범한 함수로 쓰면 된다. 의존성 배열을 틀릴 걱정도, 빠뜨린 deps 때문에 스테일 클로저를 디버깅할 일도 없다.
forwardRef도 사라졌다. React 19에서 ref는 그냥 props다. 커스텀 인풋 컴포넌트를 만들 때 forwardRef로 감싸고, 두 번째 인자로 ref를 받고, 별도로 import하던 의식이 통째로 삭제된다. React 팀은 codemod도 제공하니 기존 코드베이스 마이그레이션 비용도 낮다.
<Context.Provider value={...}> 패턴도 <ThemeContext value="dark">로 줄었다. 작은 변화처럼 보이지만, Context를 매일 쓰는 코드베이스에선 반복 소음이 꽤 컸다.
가장 실질적인 변화는 폼 상태 관리다. API 요청이 있는 폼마다 isPending, error, result—세 개의 useState와 try/catch, 수동 pending 토글이 세트로 따라왔다. useActionState 하나가 이걸 전부 대체한다. async 액션 함수를 넘기면 현재 상태, dispatch 함수, isPending 플래그를 돌려준다. 로직이 한 곳에 모이고, 상태 불일치로 UI가 엇나갈 여지가 줄어든다.
마지막으로 react-helmet. 페이지별 <title>과 meta 태그를 위해 외부 라이브러리를 설치하던 시절이 끝났다. React 19는 컴포넌트 안에서 직접 <title>, <meta>를 쓰면 자동으로 <head>로 올려주고, 중복도 알아서 처리한다.
그런데 AI 에이전트가 이 변화를 더 빠르게 만든다
React 19가 코드의 부피를 줄이는 동안, AI 에이전트는 개발 속도를 올린다. 그런데 여기서 흔히 빠지는 함정이 있다. Cursor나 Claude에게 "폼 컴포넌트 만들어줘"라고 시키면 20분 만에 돌아가는 코드가 나온다. 2주 후 그 프로젝트는 어디서 뭐가 바뀌면 다른 게 터지는 지뢰밭이 된다. Spec-Driven Development 아티클이 지적하는 게 정확히 이 지점이다.
문제는 AI가 아니다. 프로세스다. 에이전트는 실행을 잘한다. 단, 당신이 시키는 것을 실행한다. 지시가 모호하면 에이전트는 빈칸을 자기 판단으로 채운다. 그 판단이 당신이 원하던 것과 다를 때, 컨텍스트는 채팅 히스토리 어딘가에 흩어진 채 사라져 있다.
Spec-Driven Development: 에이전트에게 생각의 틀을 주는 방법
SDD(Spec-Driven Development)의 핵심 명제는 간단하다. 코드가 spec을 섬기는 게 아니라, spec이 코드를 지배한다. 구현을 시작하기 전에 무엇을 만들 것인지를 문서로 먼저 정의하고, 에이전트는 그 문서를 읽고 따르며 그 문서 기준으로 자신의 결과를 검증한다.
Matt Pocock이 정리한 7단계 플로우가 실용적이다. 아이디어 → 리서치 → 프로토타입 → PRD → 칸반 → 실행 루프 → QA. 이 중 실제로 가장 많은 것을 바꾸는 단계는 PRD다. 500단어 이내의 짧은 문서. 목표, 사용자, 예상 동작, 스코프 밖 항목, 가정(assumptions), 검증 기준. 구현 방법은 쓰지 않는다.
특히 assumptions 섹션이 핵심이다. 개발자가 당연하게 여기는 전제들—기존 API 계약, 상태 구조, 에러 처리 방식—을 명시하지 않으면 에이전트는 그 자리를 추측으로 채운다. React 19의 useActionState로 폼을 만든다고 가정하더라도, 에이전트가 그 결정을 알지 못하면 구식 패턴으로 돌아갈 수 있다.
두 흐름이 만나는 지점
React 19의 변화와 SDD를 연결하면 실용적인 워크플로우가 보인다. React Compiler가 useMemo 결정을 대신 내려주듯, PRD는 에이전트의 아키텍처 결정을 사전에 못 박는다. 둘 다 '판단의 위임'이지만 방향이 다르다. React Compiler에게는 반복적 최적화 판단을 위임하고, PRD를 통해 에이전트에게는 구현 맥락을 제공한다.
예를 들어 새 폼 컴포넌트를 만드는 PRD를 쓴다면, assumptions 섹션에 이렇게 명시할 수 있다. "폼 상태는 useActionState로 관리한다. isPending/error/result용 별도 useState는 사용하지 않는다. ref 전달이 필요할 경우 forwardRef 없이 prop으로 직접 전달한다." 에이전트는 이제 React 19 방식으로 코드를 생성하고, 개발자는 구식 패턴이 섞여 들어왔는지만 검토하면 된다.
칸반 단계에서 이슈를 쪼갤 때도 마찬가지다. 레이어별(프론트/백엔드)이 아니라 vertical slice로—하나의 이슈가 UI부터 데이터 레이어까지 end-to-end를 커버하도록. 이 방식이 React Server Components 기반 Next.js 앱에서 특히 잘 맞는다. 한 이슈 안에서 Server Component의 데이터 패칭, Client Component의 인터랙션, 그리고 useActionState 기반 폼 처리까지 한 번에 검증할 수 있기 때문이다.
전망: 보일러플레이트와의 전쟁은 이제 두 전선이다
React 19는 프레임워크 레벨에서 코드 부피를 줄이고, SDD는 에이전트 레벨에서 혼돈을 줄인다. 둘의 공통점은 개발자의 인지 부하를 줄이는 것이다. 의존성 배열을 틀릴 걱정, forwardRef 문법을 기억할 필요, 폼마다 똑같은 상태 삼총사를 복붙하는 루틴—이런 것들이 사라질 때 개발자가 집중할 수 있는 곳은 단 하나다. 사용자가 실제로 필요한 것이 무엇인가.
Thoughtworks 2025 기술 레이더가 SDD를 "생성형 AI와 함께 등장한 가장 중요한 실천 중 하나"로 꼽은 건 우연이 아니다. 에이전트가 실행자가 되는 세계에서, 지시의 품질이 코드의 품질을 결정한다. React 19가 프레임워크 수준의 판단을 자동화하는 동안, 개발자가 해야 할 일은 더 적은 코드로 더 나은 사용자 경험을 설계하는 것—그 판단만큼은 아직 인간의 몫이다.