항공 프론트엔드 구축기 (10/10): 폴더 이름 앞의 기호 하나
Summary
FSD는 부담스럽다? 폴더 이름 앞 '기호 하나'로 복잡한 의존성 끝내기
엄격한 아키텍처 없이도 파일의 영향 범위를 명확히 규정하는 초경량 재귀적 폴더 설계법
대규모 항공 서비스 구축 과정에서 직면한 컴포넌트 관리와 의존성 문제를 심플한 '폴더 접두어 규칙' 하나로 우아하게 해결한 실무 중심의 아키텍처 노하우입니다. 무겁고 복잡한 Feature-Sliced Design(FSD) 대신, 누구나 1초 만에 이해하는 세 가지 기호만으로 사람과 AI가 모두 편안한 개발 환경을 구축한 생생한 경험을 소개합니다.
- 01FSD 도입의 현실적 장벽과 촉박한 일정 속 대안적 설계의 필요성
- 02의존성 범위를 직관화하는 3가지 폴더 접두어(shared, _, +)의 매커니즘
- 03어느 깊이에서나 일관되게 작용하여 러닝커브를 최소화하는 재귀적 구조
- 04스스로 동작하는 widget과 그리기에만 충실한 ui의 명확한 역할 분리
- 05네이밍 기반 규칙이 가지는 한계점(짝 깨짐 현상)과 자동화 도구 부재의 트레이드오프
RECOMMENDATION
복잡한 아키텍처 패턴을 팀에 학습시킬 시간이 부족하거나, 파일 삭제와 컴포넌트 재사용성 판단에 매번 병목을 겪는 모든 프론트엔드 개발 조직에게 이 직관적인 규칙을 추천합니다.
The Problem
프로젝트 규모가 커짐에 따라 특정 컴포넌트 파일의 영향 범위와 전용 여부를 직관적으로 파악하기 어려워, 파일 삭제나 재사용 판단에 매번 불필요한 분석 시간이 소요되는 비효율이 발생했습니다. 이를 해결하고자 Feature-Sliced Design(FSD) 도입을 검토했으나, 엄격한 레이어 구분 기준을 합의하는 데 따르는 인지 비용과 촉박한 개발 일정 때문에 실무 적용이 어려웠습니다.
The Solution
복잡한 아키텍처 대신 파일의 전용 및 공유 범위를 폴더 접두어 기호로 구분하는 3가지 규칙(전체 공유 'shared/', 계층 내 공유 '_이름/', 특정 파일 전용 '+이름/')을 수립하여 재귀적으로 적용했습니다. 공용 요소는 데이터 바인딩 여부에 따라 값을 화면에 그리기만 하는 'ui'와 스스로 필요한 데이터를 가져오는 'widget'으로 역할을 분담했습니다.
The Result
폴더 구조와 이름만으로 파일의 영향 범위를 명확히 알 수 있어 안전하고 신속한 코드 삭제 및 수정이 가능해졌으며, 새로 합의할 규칙이 줄어 인지 과부하가 해소되었습니다. 또한 사람이 명시적인 가이드를 주지 않아도 AI 도구가 주변 폴더 구조를 파악해 스스로 올바른 위치에 파일을 생성하는 성과를 거두었습니다.
Trade-off
폴더명과 파일명의 짝을 오직 네이밍 규칙에만 의존하기 때문에, 리팩토링 시 파일명만 바꾸고 폴더명을 수정하지 않아 일관성이 깨지는 현상이 소수 발생했습니다. FSD와 달리 규칙 준수 여부를 자동으로 검사해 주는 Linter나 컴파일러의 경고 시스템을 기본으로 탑재하지 못해, 수동 셸 스크립트 작성 등의 보완책이 필요합니다.
Key Concepts
More from 여기어때
View all posts from 여기어때항공 프론트엔드 구축기 (8/10): 토큰이 세 군데서 온다
NextJSWebViewAuthentication3시간 전AI가 내 하루를 기억하게 하는 법 (1/2): 먼저, 기억할 곳을 만들었다 — 개인 LLM 위키
LLMMarkdown WikiContext Window3시간 전[2편] Grafana 커스텀 패널로 10만 점 산점도 그리기 — 만들고 나서야 보인 함정 3가지
GrafanaCanvas APIReact3시간 전[1편] APM 스캐터 차트 직접 만들기 — OpenTelemetry 수집과 ClickHouse 저장
OpenTelemetryClickHouseAPM3시간 전전시 QA에서 예약·정산 QA로 넘어가며 달라진 관점들
QA-TestingData-ConsistencyState-Table3시간 전
