프로덕션 레디 포트폴리오 구축: Phase-2 — 레이아웃, 네비게이션 및 라우팅 기초

발행: 6시간 전 (2026년 1월 20일 오후 02:41 GMT+9)

15 min read

원문: Dev.to

Source: Dev.to

지금까지 프론트엔드는 주로 구조와 의도 수준에 머물렀다

폴더가 계획되었다
책임이 정의되었다
라우팅이 구상되었다

Day‑4는 이러한 계획이 실제 사용자 경험으로 전환되기 시작한 시점이다.

제품 소유자이자 수석 개발자로서 나는 이 날을 다음과 같이 정의했다:
“사용자가 제품을 어떻게 이동하는지, 그리고 시스템이 그 이동을 깔끔하게 지원하도록 하자.”

레이아웃과 내비게이션이 자체 단계가 필요한 이유

많은 프로젝트에서 내비게이션은:

서두름
하드코딩됨
UI와 긴밀히 결합됨

이러한 접근 방식은 확장성이 없습니다.

제품 관점에서 보면:

내비게이션은 정보 구조를 정의합니다
레이아웃은 일관성을 정의합니다
라우팅은 사용자에 대한 정신 모델을 정의합니다

그래서 헤더와 푸터를 여기저기 흩뿌리는 대신, 전용 레이아웃 시스템을 도입했습니다.

레이아웃 레이어 소개 (단순히 컴포넌트가 아니라)

첫 번째 신중한 결정은 레이아웃 추상화를 만드는 것이었습니다.
이는 시각적인 요소에 관한 것이 아니라 소유권과 책임에 관한 것이었습니다.

레이아웃 레이어는 다음을 담당합니다:

전역 UI 요소
지속적인 내비게이션
라우트 전반에 걸친 공유 구조

그 결과 세 가지 명확한 빌딩 블록이 생겼습니다:

NavBar
Footer
Layouts (래퍼)

Layout diagram

네비게이션이 변경되면 어떻게 될까요?

중앙 집중식 네비게이션 데이터 (제품처럼 생각하기)

NavBar JSX 코드를 한 줄도 작성하기 전에 간단한 질문을 던졌습니다:

네비게이션이 변경되면 어떻게 될까요?

새 페이지, 이름이 바뀐 섹션, 순서가 바뀐 링크 — 이는 UI 문제가 아니라 제품 결정입니다.

그래서 컴포넌트 안에 링크를 하드코딩하는 대신 단일 진실의 원천을 만들었습니다.

`data/navLinks.js`

// data/navLinks.js
export const navLinks = [
  { label: "Home",   path: "/" },
  { label: "About",  path: "/about" },
  { label: "Docs",   path: "/docs" },
  // …add more as the product evolves
];

이 파일은 다음을 나타냅니다:

제품의 네비게이션 구조
제품이 제공하는 페이지들
라우팅과 UI 사이의 계약

이를 중앙 집중화함으로써:

NavBar와 Footer가 항상 동기화됨
미래의 변경이 간단해짐
중복이 사라짐

실제 제품이 다음을 관리하는 방식과 동일합니다:

메뉴
사이드바
사이트맵

NavBar는 가장 눈에 띄는 컴포넌트이면서 가장 남용되기 쉬운 요소이기도 합니다.
여기서는 NavBar를 다음과 같이 다루었습니다:

브랜드 앵커
네비게이션 허브
반응형 시스템 컴포넌트

핵심 디자인 결정

1. 브랜드 아이덴티티가 최우선

로고 + 이름
클릭 가능
언제나 홈으로 돌아감

이를 통해 다음을 구축합니다:

신뢰
인지도
연속성

2. 데스크톱과 모바일은 동등한 존재

“데스크톱‑우선, 모바일은 사후 생각”이 아니라, NavBar는 다음을 고려해 구축되었습니다:

반응형 로직
모바일 인터랙션 패턴
부드러운 전환

이는 실제 사용 환경을 반영한 것이며, 단순히 데스크톱 데모에 국한되지 않습니다.

모바일 네비게이션: 의도에 맞춘 설계

햄버거 메뉴는 단순히 추가된 것이 아니라 설계되었습니다.

주요 고려 사항:

명확한 열림/닫힘 상태
부드러운 애니메이션
네비게이션 시 자동 닫힘
실수로 인한 오버레이 방지

“Coming Soon”도 제품 신호다

테마 토글 버튼이 아직 테마를 전환하지 않는 것을 보게 될 것입니다.
이는 의도된 설계입니다.

제품 관점에서:

로드맵을 신호함
기대치를 설정함
조용한 실패를 방지함

미완성 기능을 숨기기보다, 저는 다음을 선택했습니다:

의도를 드러냄
명확히 소통함
UX를 정직하게 유지함

이는 미묘하지만 강력한 제품‑리더십 결정입니다.

푸터: 구조와 신뢰 강화

푸터는 종종 무시되지만, 중요한 역할을 합니다.
여기서 푸터는 세 가지 목적을 수행합니다:

보조 네비게이션
브랜드 강화
외부 신뢰도 (소셜 링크)

같은 navLinks 데이터를 사용함으로써:

일관성을 유지하고
변형을 방지하며
제품의 정보 구조를 강화합니다

이러한 재사용은 의도된 것이며 확장 가능합니다.

Layouts Component: The Glue That Holds Everything Together

Instead of wrapping every page manually, I introduced a single Layouts component.

Responsibility

지속적인 UI 렌더링
라우팅을 통해 페이지 콘텐츠 위임

Using React Router’s Outlet:

라우트를 깔끔하게 유지
중복을 방지
중첩 라우팅을 자연스럽게 지원

This is the point where architecture pays off.

라우팅: 구조를 내비게이션으로 전환하기

마침내 모든 것이 라우팅에서 하나로 합쳐집니다.

라우팅 설정은 다음을 반영합니다:

깨끗한 URL
예측 가능한 구조
실제 애플리케이션 패턴

각 라우트는:

페이지에 매핑됩니다
레이아웃을 상속합니다
콘텐츠에 집중합니다

이러한 분리는 다음을 가능하게 합니다:

페이지를 건드리지 않고 레이아웃 변경
UI를 깨뜨리지 않고 라우팅 변경
테스트 및 디버깅 용이

중첩 라우팅이 전략적 결정인 이유

공유 레이아웃에 중첩 라우트를 사용하는 것은 React 트릭이 아니라 아키텍처적 약속입니다.

다음과 같이 정의함으로써:

단일 레이아웃 래퍼
자식으로서의 페이지

그리고 Outlet을 통해 콘텐츠를 렌더링하면:

전역 UI가 안정적으로 유지
페이지 간 내비게이션이 지속
페이지 수준 컴포넌트가 집중될 수 있음

제품 관점에서 이는 다음을 의미합니다:

일관된 사용자 경험
예측 가능한 동작
기여자 온보딩 용이

Nested routing diagram

관심사의 분리: 조용한 승리

이 설정의 가장 간과되는 장점 중 하나는 페이지가 알 필요가 없는 것입니다.

페이지는:

네비게이션에 신경 쓰지 않는다
레이아웃을 관리하지 않는다
오직 자신의 콘텐츠에만 집중한다

이러한 깔끔한 분리는 코드베이스를 유지보수, 확장, 그리고 새로운 팀원에게 인계하기 쉽게 만듭니다.

레이아웃 컴포넌트를 가져오지 마세요

전역 UI를 관리하지 않는다

그들은 단순히 다음과 같이 답합니다:

“이 라우트가 보여줄 콘텐츠는 무엇인가요?”

이것은 코드베이스를 다음과 같이 만듭니다:

이해하기 쉬워진다
리팩터링이 안전해진다
확장이 빨라진다

이는 우연이 아니라 의도적인 엔지니어링입니다.

네비게이션을 UI가 아닌 데이터로

navLinks.js를 데이터로 다룸으로써 여러 장점을 얻었습니다:

UI 컴포넌트는 단순하게 유지된다
제품 구조가 명확하게 유지된다
변경 시 수정이 적게 필요한다

프로덕트 오너 관점에서 이것은 강력합니다, 왜냐하면:

새로운 섹션 추가가 위험이 낮다
페이지 순서 변경에 UI 재작성 필요 없음
일관성이 설계에 의해 강제된다

실제 시스템이 엔트로피를 방지하는 방식입니다.

흔한 프론트엔드 안티패턴 피하기

이 단계에서는 실제 시스템에서 반복적으로 보던 여러 실수를 의도적으로 피합니다:

❌ 어디에나 하드코딩된 네비게이션
❌ 페이지마다 중복된 레이아웃
❌ 파일에 흩어져 있는 라우팅 로직
❌ 모바일을 사후 생각으로 처리

대신, 이 설정은 다음을 제공합니다:

단일 레이아웃 소유자
단일 네비게이션 소스
예측 가능한 라우팅 규칙
모바일 우선 동작

이러한 결정은 4일 차에 중요하게 느껴지지 않을 수 있지만, 나중에 몇 주를 절약합니다.

작은 디테일에서의 프로덕트 사고

작은 선택조차도 프로덕트 사고를 반영합니다:

깨진 버튼 대신 “곧 제공” 툴팁
무음 상태 변화 대신 애니메이션 피드백
헤더와 푸터 모두에 브랜드 존재
신뢰와 신용을 위한 소셜 링크

이 중 어느 것도 기능을 위해 필수는 아닙니다.
하지만 모두 경험을 위해 필수입니다.

그 차이가 중요합니다.

시스템을 확장에 대비시키는 방법

이 기반은 향후 작업을 직접적으로 가능하게 합니다:

다크 모드 → 토글이 이미 존재
백엔드 통합 → 페이지가 격리됨
역할 기반 네비게이션 → 데이터 기반 링크
SEO 및 분석 → 일관된 레이아웃
테스트 → 예측 가능한 컴포넌트 경계

3단계는 기능에 관한 것이 아닙니다.
이는 기능을 위한 공간을 만드는 것입니다.

Day‑4 회고

되돌아보면, Day‑4는 미묘하지만 중요한 무언가를 달성했습니다:

프런트엔드를 *“파일과 폴더”*에서 탐색 가능한 사용자‑대면 제품으로 변환했습니다.

여기서:

사용자들이 의견을 형성하기 시작합니다
구조가 효과를 발휘하기 시작합니다
기술적 결정이 가시화됩니다

그리고 이제부터 모든 새로운 기능은 안정적이고 예측 가능한 시스템에 연결됩니다.

다음 단계

레이아웃과 네비게이션이 마련된 상태에서 다음 논리적인 단계는:

실제 섹션 구축
데이터 연결
실제 콘텐츠 구성

Phase‑3가 계속되지만, 가장 어려운 부분인 — 기초를 올바르게 다지는 것 — 은 이제 완료되었습니다.

마무리 생각

좋은 프론트엔드 엔지니어링은 JSX를 더 빠르게 작성하는 것이 아닙니다.
미래의 당신과 미래의 기여자들이 감사하게 될 결정을 내리는 것입니다.

If you’re following along, the complete source lives here:

👉 GitHub Repository: