최근 두 가지 흥미로운 사례가 같은 방향을 가리키고 있다. 하나는 Next.js App Router의 Parallel Routes 구조를 nested layout으로 바꾼 실제 리팩토링 기록이고, 다른 하나는 AI 코딩 에이전트가 긴 세션에서 효율을 유지하는 요인을 추적한 실험이다. 표면적으로는 전혀 다른 이야기처럼 보이지만, 두 사례가 공통적으로 도달한 결론은 하나다. 구조가 명확할수록 작업이 쉬워진다.
핵심 이슈: 슬롯을 없애자 모든 것이 단순해졌다
velog에 연재 중인 SlateKR 개발 로그(#046)는 @tab Parallel Routes 슬롯을 걷어내고 일반 nested layout으로 전환한 과정을 담고 있다. Before 구조에서는 [ticker]/@tab/page.tsx가 슬롯 루트로 렌더되어 URL과 실제 페이지 사이에 한 단계 간접 레이어가 존재했다. After 구조에서는 /stocks/[ticker]가 곧 종합정보 페이지가 되고, 하위 탭은 chart/, disclosures/, financials/ 경로로 직접 매핑된다. 라우트가 1:1 구조가 된 것이다.
이 변경이 단순한 폴더 정리처럼 보이지만, 연쇄 효과가 흥미롭다. React.cache의 진입점을 layout 로컬에서 lib/stocks.ts export 자체로 끌어올리자, 이후 각 탭 page에 추가된 generateMetadata 함수들이 별도 설정 없이 자동으로 같은 캐시 사이클을 공유하게 됐다. 호출 지점에서 캐시 여부를 의식할 필요가 사라진 것이다. prefetch={false}를 제거한 것도 마찬가지 논리다—Next.js가 dynamic route에서 loading.tsx 경계까지만 prefetch하는 기본 동작을 신뢰하자, 탭 전환 시 서버 응답 대기 시간이 262ms에서 48ms로 줄었다(dev 환경 측정값이므로 prod 수치는 별도 검증 필요). 설계가 단순해지자 프레임워크의 기본 동작이 제대로 작동하기 시작했다.
맥락 해석: AI 에이전트도 같은 문제를 겪는다
dev.to에 게재된 'The AI Context Efficiency Experiment'는 두 개의 실제 저장소(FPA, MIL)에서 AI 코딩 에이전트를 장기 세션으로 운용하며 47개의 관측값을 수집한 실험이다. 실험의 출발점은 단순했다—컨텍스트 창이 클수록 효율이 높을 것이라는 가설. 그런데 결과는 달랐다.
컨텍스트가 219K에서 26.7K로 압축(compaction)된 이후에도 작업이 원활하게 이어진 사례가 있는 반면, 방금 압축을 마친 신선한 세션에서도 작업이 느려지는 경우가 있었다. 차이를 만든 변수는 아키텍처 locality였다. 다음 작업이 이전 작업과 같은 아키텍처 영역 안에 있을 때—관련 파일이 가깝고, 개념이 재사용되고, 테스트 범위가 예측 가능할 때—AI 에이전트는 재탐색 없이 바로 작업에 진입했다. 반대로 컨텍스트가 충분해도 작업이 여러 도메인을 횡단해야 한다면 효율이 떨어졌다. 실험은 컨텍스트 연구로 시작해서 아키텍처 연구로 끝났다.
시사점: 구조 설계가 AI 워크플로우의 선행 조건이다
두 사례를 겹쳐보면 공통 패턴이 선명하게 드러난다. SlateKR의 nested layout 전환은 라우팅 구조에서 불필요한 간접 레이어를 제거했고, AI 실험의 locality 발견은 작업 경계가 명확한 코드베이스에서 에이전트가 더 잘 작동함을 보여줬다. 핵심은 이것이다—구조의 명확성은 사람 개발자뿐 아니라 AI 에이전트에게도 동일하게 작동한다.
Parallel Routes는 독립적인 로딩 상태와 에러 바운더리가 진짜 필요한 경우에 강력한 도구다. 그러나 단순히 탭 UI를 구현하기 위해 슬롯 레이어를 추가하는 건 코드베이스에 불필요한 인지 부하를 심는 일이다. AI 에이전트에게 이 코드를 넘기면, 에이전트는 @tab 슬롯의 의미와 default.tsx의 역할, slot prop과 children의 차이를 맥락에서 다시 파악해야 한다. 구조가 복잡할수록 AI가 소비해야 하는 컨텍스트 예산이 늘어난다.
반대로 React.cache를 lib export 자체에 두는 패턴은 AI 에이전트 입장에서 이상적인 설계다. 함수를 호출하는 곳에서 캐시 여부를 판단할 필요가 없으니, 에이전트가 생성하는 코드에서 캐시 래핑 누락 같은 실수가 구조적으로 줄어든다. 이는 단순히 '좋은 코드 관습'을 넘어, AI 워크플로우를 고려한 API 설계의 사례다.
전망: 'AI 친화적 구조'는 선택이 아닌 기준이 된다
Next.js App Router는 Parallel Routes, Intercepting Routes, Server Actions 등 강력한 기능을 계속 추가하고 있다. 문제는 이 기능들이 강력한 만큼 복잡도도 함께 올라간다는 점이다. AI 코딩 도구가 팀의 일상적인 개발 파트너가 되어가는 지금, 구조 설계의 기준에 새로운 항목이 추가되고 있다—이 구조가 AI 에이전트가 다음 작업을 시작할 때 얼마나 적은 재탐색으로 진입할 수 있는가.
빠른 프로토타이핑과 반복 검증을 중시하는 개발 흐름에서, 구조 설계는 종종 '나중에 정리할 것'으로 미뤄진다. 하지만 SlateKR의 사례처럼 라우팅 구조 결정이 #040에서 시작해 #046까지 여섯 세션에 걸쳐 정리된 비용을 생각하면, 초기 설계 투자의 가치는 명확하다. AI 도구를 실질적인 개발 동반자로 활용하려면, 그 도구가 잘 작동할 수 있는 구조를 먼저 설계하는 것이 개발자의 역할이다. 컨텍스트 창 크기를 늘리는 것보다, 그 컨텍스트 안에 들어올 코드의 형태를 다듬는 것이 더 직접적인 효율 레버다.