Self-similar: 코드용 다재다능한 폴더 패턴

Source: Dev.to

“*동형사상(isomorphism)*이라는 단어는 두 복잡한 구조가 서로 매핑될 수 있을 때 적용되며, 한 구조의 각 부분에 다른 구조에 대응되는 부분이 존재하고, 여기서 대응한다는 것은 두 부분이 각각의 구조에서 유사한 역할을 수행한다는 의미이다.”
— Douglas Hofstadter
Gödel, Escher, Bach • Meaning and Form in Mathematics • pp. 57

개요

프론트‑엔드 프로젝트는 두 가지 주요 폴더 패턴 사이를 오가며 변천해 왔습니다:

기능‑중심

• controllers/
• views/
• models/
• …

기능‑중심

• posts/
• comments/
• likes/
• …

하이브리드 시도(예: feature‑sliced design)는 두 방식을 결합해 각 기능 내부에 컨트롤러, 뷰, 모델을 중첩합니다.
self‑similar 패턴은 여기서 한 단계 더 나아가, 어떤 명명 토큰도 어느 중첩 레벨에서든 나타날 수 있게 하면서 명명을 일관되게 유지합니다.

규칙

• 모든 단어는 복수형으로 만들 수 있습니다: comment → comments.
• 단어는 대시(-)로 결합할 수 있습니다: delete + comment → delete-comment.
• 어떤 단어(또는 조합)든 폴더나 파일 이름으로 어느 깊이에서도 사용할 수 있습니다.

과정

1. 명명 토큰(복수형이 아닌)을 기존 구조에서 수집합니다.

   border
   comment
   controller
   create
   delete
   deleted
   detail
   fetch
   get
   hook
   like
   list
   local
   mixin
   model
   post
   recessed
   relieved
   storage
   use
   util
   view

2. 유사 토큰을 그룹화합니다(카드 정렬). 예시 그룹:

   • border, recessed, mixin
   • comment, list, create, delete
   • post, detail, list, create, delete
   • like, list, create, delete

3. 각 그룹에 대한 주 축을 결정합니다:

   • 단일 기능 주위에 모여 있는 토큰 → 기능 그룹화.
   • 재사용 가능한 유틸리티 역할을 하는 토큰 → 기능 그룹화.

4. 토큰을 우선순위에 따라 정렬하고 그에 맞게 중첩합니다.

결과 폴더 트리

posts/
├─ controllers/
│  ├─ list.ts
│  ├─ detail.ts
│  ├─ create.ts
│  └─ delete.ts
├─ views/
│  ├─ list.tsx
│  ├─ detail.tsx
│  ├─ create.tsx
│  └─ deleted-message.tsx
├─ models/
│  └─ post.ts
└─ hooks/
   └─ like-post.ts

comments/
├─ controllers/
│  └─ …
├─ views/
│  └─ …
└─ models/
   └─ …

likes/
└─ …

hooks/
├─ local-storage/
│  └─ hook.ts
└─ …

utils/
├─ fetch/
│  ├─ get.ts
│  ├─ delete.ts
│  └─ post.ts
└─ …

mixins/
└─ border/
   ├─ recessed.ts
   └─ relieved.ts

Self‑similarity가 드러나는 부분:

• detail은 컨트롤러(controllers/detail.ts)와 뷰(views/detail.tsx) 모두에 존재합니다.
• controllers, views, models는 어떤 기능(posts, comments, likes) 아래에도 배치될 수 있습니다.
• 훅은 전역(hooks/)에 묶이거나 기능 내부(posts/hooks/like-post.ts)에 국한될 수 있습니다.

언제 사용해야 할까

• 팀 규모 및 전문성: 작은 규모이면서 경험이 풍부하고 다언어에 능숙한 팀이 협업 조직에 투자할 의향이 있을 때 가장 효과적입니다.
• 프로젝트 복잡도: 장기적인 복잡한 코드베이스 정리 작업에 적합하며, 유연성이 구조 유지 비용보다 클 때 좋습니다.
• 리스크 고려사항:
  • 대규모이면서 위험 회피적인 팀(예: 중견 기업의 Ruby 엔지니어)에서는 더 단순한 기능‑기반 레이아웃을 선호할 수 있습니다.
  • 빠르게 움직이는 스타트업은 시간을 절약하기 위해 직관적인 기능‑기반 레이아웃을 선택할 수 있습니다.

self‑similar 패턴은 엄격하면서도 적응 가능한 프레임워크를 제공합니다—어떤 단어든 어디서든 재사용할 수 있지만, 어느 한 곳에 고정되지 않습니다. 유연성과 일관성의 이점이 협업에 필요한 노력을 정당화할 때 이 패턴을 활용하십시오.