Next.js 16이 2025년 10월에 출시됐다. 이후 16.1부터 16.3까지 마이너 릴리스가 연달아 나오면서 프레임워크의 무게 중심이 조용히 바뀌었다. Webpack이 Turbopack으로 교체되고, 캐싱 철학이 암묵적에서 명시적으로 뒤집혔으며, 라우팅은 SPA 수준의 즉각성을 품었다. 수치는 자체적으로 말한다. 프로덕션 빌드는 24.5초에서 5.7초로, Server Component 페이로드 역직렬화는 최대 60% 빨라졌다. 그런데 이 숫자들을 훑다 보면 묘한 질문이 남는다. 프레임워크가 이만큼 결정을 대신 내려줄 때, 개발자는 정확히 무엇을 결정해야 하는가?
프레임워크가 '기본값'을 바꿀 때 무슨 일이 일어나는가
Next.js 16의 가장 의미 있는 변화는 속도가 아니라 철학이다. 이전 버전의 암묵적 캐싱—fetch가 기본으로 캐싱되던 방식—은 실무에서 끊임없이 디버깅 지옥을 만들었다. 의도하지 않게 캐싱된 데이터, 프로덕션에서만 나타나는 스테일 응답, 설정 파일 깊숙이 숨어 있던 원인. dev.to의 릴리스 분석이 지적하듯, 16.x의 핵심 아키텍처 변화는 '모든 것이 동적, 캐싱은 명시적 opt-in'이다.
'use cache' 디렉티브는 캐싱 경계를 코드에서 눈에 보이게 만든다. updateTag()는 폼 제출 직후 사용자가 자신의 변경사항을 즉시 볼 수 있게 하는 read-your-writes 의미론을 제공하고, refresh()는 캐시를 건드리지 않고 동적 데이터만 갱신한다. 이 세 API가 함께 작동하면 캐싱 전략이 프레임워크 내부의 암묵적 규칙이 아니라 코드베이스의 명시적 설계 결정이 된다. 좋은 변화다. 하지만 동시에, '어디에 use cache를 붙이고 어디에 붙이지 않을 것인가'라는 판단은 고스란히 개발자에게 돌아온다.
급여 계산기 한 달이 프레임워크 이야기인 이유
이 지점에서 전혀 다른 맥락의 이야기가 겹쳐진다. SalaryHow 개발기는 이렇게 시작한다. "산술은 한 시간이었다. 나머지 한 달은 다른 질문이었다—숫자 하나를 화면에 보여줄 때, 사람이 그것을 실제 결정에 쓸 만큼 신뢰하게 만들려면 무엇이 필요한가."
hourlyRate * hoursPerWeek * weeksPerYear. 한 줄이다. 그런데 이 공식을 세 개의 컴포넌트에 흩어놓으면 하루 만에 숫자가 서로 다른 값을 표시하기 시작한다. 이자율 차이, 반올림 위치, 중간 계산의 뉘앙스 차이. 해결책은 "지루하고 절대적인" 단일 계산 모듈이었다. 모든 입력은 하나의 annualGross로 정규화되고, 모든 표시 값은 그 단일 값에서 파생된다. 컴포넌트는 값을 렌더링할 뿐, 계산하지 않는다.
이것은 Next.js 16의 캐싱 철학과 정확히 같은 구조다. 암묵적으로 여러 곳에 분산된 진실의 원천은 결국 불일치를 만들고, 그 불일치는 사용자의 신뢰를 조각낸다. 프레임워크 수준이든 단일 컴포넌트 수준이든, 명시적이고 단일한 진실의 원천을 설계하는 판단은 도구가 대신해줄 수 없다.
AI가 루프에 들어왔을 때 희소해지는 것
Pydantic 팀이 공유한 글은 이 맥락을 더 넓게 밀어붙인다. "진짜 병목은 코드가 아니었다. 인간의 주의력, 공학적 판단, 시스템에 대한 일관된 비전을 유지하는 능력이었다. 코드 작성이 어려워 보였기 때문에 이 병목이 잘 드러나지 않았을 뿐이다."
Next.js 16이 빌드 속도를 5배 높이고, Turbopack이 Fast Refresh를 10배 빠르게 하고, AI 코딩 도구가 코드를 쏟아낼 때—시작할 수 있는 작업의 수는 폭발적으로 늘어난다. 하지만 신중하게 마칠 수 있는 작업의 수는 여전히 인간의 두뇌에 묶여 있다. Pydantic의 유지보수자 Douwe는 아침마다 AI가 밤새 만든 PR 30개를 검토했다. 검토 자체를 AI에 맡기면 인간이 루프에 있는 이유가 사라진다. 그렇다고 검토를 계속하면 새로운 형태의 감독 피로가 쌓인다.
이 딜레마는 프레임워크 선택이나 AI 도구 도입만으로 해결되지 않는다. SalaryHow의 개발자가 "어떤 가정을 쓰는지 사용자에게 보여줄 것인가"를 명시적으로 설계했듯, AI와 함께 작업하는 개발자에게도 "어디에 인간의 판단을 배치할 것인가"를 의도적으로 설계하는 구조가 필요하다.
프레임워크가 줄여주는 것과 늘려주는 것
Next.js 16의 Instant Navigation(16.3)은 클라이언트에 라우트 셸을 캐싱해 링크 클릭 즉시 렌더링하고 나머지를 스트리밍한다. SSR의 이점을 유지하면서 SPA 수준의 네비게이션 경험을 만든다. 레이아웃 중복 다운로드는 50개에서 1개로 줄고, 증분 프리페칭은 총 전송량을 극적으로 낮춘다. 이 모든 것이 설정 없이 자동으로 작동한다.
프레임워크는 반복적이고 예측 가능한 결정을 흡수한다. Webpack 설정, 캐싱 디버깅, 프리페칭 최적화. 이것들이 사라진 자리에 남는 것은 무엇인가. SalaryHow 개발기가 말하는 것처럼, 남은 것은 가정을 명시적으로 설계하는 판단, 단일 진실의 원천을 만드는 구조적 결정, 그리고 "숫자가 맞더라도 사용자가 신뢰할 수 있는가"라는 질문이다.
개발자 판단의 무게가 오히려 무거워지는 역설
Pydantic 글의 핵심 통찰을 다시 빌리면, 누구나 그럴듯한 UI와 컴파일되는 코드를 만들 수 있는 환경에서는 취향, 아키텍처 판단, 실제 전문성에 기반한 결정이 차별점이 된다. 프레임워크가 더 많은 것을 자동화할수록, AI가 더 많은 코드를 생성할수록, 남은 판단의 질이 결과물의 질을 결정한다.
Next.js 16에서 use cache를 어디에 붙일 것인가. updateTag()와 refresh()를 언제 구분할 것인가. Instant Navigation이 활성화됐을 때 스트리밍 경계를 어디에 설정할 것인가. 이 질문들은 릴리스 노트가 답해주지 않는다. 수년간의 실패에서 축적된 판단이 답한다. Pydantic의 한 엔지니어가 과거 코드 리뷰 댓글 수천 개에서 규칙을 추출해 AGENTS.md의 초기 지침으로 만든 것처럼—암묵적으로 쌓인 공학적 판단을 명시적인 구조로 증류하는 작업이, AI와 고도화된 프레임워크가 공존하는 시대의 개발자에게 실질적으로 남겨진 핵심 과제다.
프레임워크는 계속 진화한다. 빌드는 더 빨라지고, 캐싱은 더 예측 가능해지고, 네비게이션은 더 즉각적이 된다. 그리고 그 진화가 흡수하는 결정들이 늘어날수록, 흡수되지 않고 남는 결정들의 무게는 오히려 커진다. 좋은 소식은, 그 무게를 감당하는 능력이 도구로 대체되지 않는다는 것이다. 나쁜 소식도 같다.