코드 구조와 URL 구조가 다를 때 써
마케팅 화면과 로그인 뒤 앱 화면에 서로 다른 레이아웃을 주고 싶지만, 주소에 /marketing이나 /app을 넣고 싶지는 않을 수 있어. 라우트 그룹은 URL을 늘리지 않고 폴더만 묶어 주는 관례야.
괄호로 감싼 이름은 주소에서 사라져
폴더를 (marketing)이나 (app)처럼 이름 지어. 그러면 app/(marketing)/about/page.tsx는 /marketing/about이 아니라 /about을 제공해. 괄호 안 이름은 개발자가 구조를 읽기 위한 표지일 뿐 방문자에게 보이는 경로가 아니야.
그룹마다 다른 루트도 만들 수 있어
- URL에 영향을 주지 않고 제품 구역마다 다른 레이아웃을 둘 수 있어.
- 각 그룹에 루트 레이아웃을 두어 서로 다른
<html>과<body>까지 사용할 수 있어. - 기능이나 팀 단위로 파일을 묶되 공개 주소는 단순하게 유지할 수 있어.
충돌은 그룹이 숨겨 주지 않아
그룹 이름이 URL에서 빠지므로 서로 다른 그룹이 같은 최종 주소를 만들면 충돌해. 폴더가 다르다는 이유로 안전하다고 생각하지 말고, 괄호를 제거한 뒤의 실제 URL을 기준으로 점검해야 해.
라우트 그룹 이름은 방문자에게 보이지 않으니 팀이 읽을 제품 구역으로 지어. (marketing)과 (app)처럼 레이아웃과 운영 책임이 갈리는 경계를 드러내면 좋아. 그룹을 추가한 뒤 괄호를 제거한 최종 URL 목록을 만들어 충돌이 없는지 빌드 전에 확인해.
폴더를 깔끔하게 묶는다는 이유만으로 그룹을 여러 겹 만들면 실제 주소와 파일 경로의 대응이 오히려 멀어져. 서로 다른 루트 레이아웃이나 명확한 조직 책임이 없으면 평범한 폴더가 더 읽기 쉬워. 보이지 않는 추상화에도 설명 비용이 있어. 괄호 그룹을 제거한 최종 URL을 자동으로 나열하고 중복을 검사해. 서로 다른 루트 레이아웃 사이를 이동할 때 문서 전체가 다시 로드되는지, 그룹 안의 상태가 다른 그룹으로 새지 않는지도 확인해. 조직 편의와 사용자 내비게이션의 경계를 함께 보는 시험이야. 라우트 그룹을 추가할 때는 서로 다른 그룹이 같은 최종 URL을 만들지 않는지 빌드 목록으로 확인해. 폴더 정리가 주소 충돌을 숨기면 조직화의 이점이 사라져.