중간, 절반, half, ½, 50%, 🕧

항해를 시작한지 딱 반이 되는 시점이다. 반대로 나머지 반이 지나면 항해도 끝이난다. 정말 하루하루 바쁘게 지내다보니 어느새 중간 지점을 통과하고 있는 중이다.

벌써부터 유쾌한 6기 분들과 코치, 운영진분들과 매주 못 만나는 것에 아쉬움이 있지만 반이 지나면 결과가 어떻든 완주를 한다는 성취감을 기대를 하고 있다.

그리고 항해는 🌊

'어떤 것에 도전하고 새로운 것을 해보는 것'

을 꽤나 내가 좋아하고 있구나 확실하게 알게 된 계기가 됐다.

또, 타로와 사주를 믿는 사람이라는 것...ㅋ. 재밌잖슴. (4팀 지혜님도 최고)
학메 운서가 사주 봐줬다. 꽤나 용한거 같다. 예전에는 그런거를 왜 신경쓸까 했는데
그냥 가볍게 받아들이니까 재밌었다.

운서의 사주에서 실행력이 내가 부족해서 실행력을 키워야 한다고 했다.
정말 나는 실행력이 진짜 부족한데 페어 1팀이 돼서 실행력 하나는 끝내주게 올라가고있다.
자의든 타의든 부족한 것을 채우니까 일단 좋다. 그리고 6기라는 새로운 인연들이 생겨서 제일 좋다.

좋다 라고만 써서 어휘의 폭이 좁다고 느껴지지만 저 단어만큼 지금 나의 상황을 제대로 표현할 단어가 없다. 그리고 좋은게 좋은거니까.

앞으로 남은 5주 느좋 항해를 줘. 🌊🌊🌊🌊🌊

---

FSD === Subway? 🥪

항해 5주차 과제를 하면서 나의 과제 폴더 구조는 도메인 기반 레이어드에 찾아보기 힘들정도의 소량의 FSD가 차용이 됐다. 나의 취향이 반영된 구조로 AI와 같이 설계를 한 결과였고, 다른 사람들의 구조도 궁금해졌다.

그러던 와중에 2팀 민기도 나와 비슷하게 다른 사람들의 폴더 구조를 궁금해했고 7팀 병준이가 구조에 대한 피드백을 남겨줬는데 되게 인상적이였다.
선명하지는 않지만 공통 사용을 한 곳으로 모아놓고 기능을 중점적으로 가보면 어떻겠냐는 거였다. 이 때는 FSD 라는 개념을 몰랐지만 되게 흥미로웠고 다음 과제에 적용해봐야지 라고 막연히 생각하고 있었다.

자 이제, 본론으로 돌아와서...
상당히 어그로를 끌만한 제목이다. FSD 가 subway 라는 결론은 어떻게 나오게 된걸까?

우리는 이번 6주차 발제의 팀별 모임에서 FSD와 단일책임 이해하기 파트의 질문들을 답하면서 가다가 점점 미궁 속으로 빠지게됐다. 그래서 FSD란?... 하고 있는데...

" 그때 빛영서가 일어나 빛을 비추시매, 어둠이 물러가고 온 페어 1팀에 광명이 임하니라.
이에 각 팀원은 손에 마우스를, 마음에 용기를 품고 코드의 바다를 항해하였더라. "

그리고 우리의 내용을 정리해서 발표했더니 아래와 같은 반응이 나왔다.

2팀 도은 도 이해하는 서브웨이론 지금 시작합니다. (사실 대단한건 없습니다...)

전체 룰 안에서 사용하기 🔖

FSD의 가장 큰 룰 중 하나인 상위 Layer 에서만 서로(Pages, Features, Entities,.. )를 조합할 수 있습니다.
예를 들어 Feature 내부에서 여러 Entity 를 결합할 수 있지만, A Feature가 B Feature를 직접 import 하는 것은 "Layer Import 규칙"에 의해 금지되고 있습니다.

쉽고 간단하게 예를 들자면 우리는 서브웨이를 주문할 때,
빵 > 치즈 > .. > 소스 이런 순으로 샌드위치를 만듭니다. 이 때 서브웨이에는 다양한 옵션을 선택할 수 있지만
1. 빵 2개를 겹친다거나,
2. 속재료로 빵을 감싼다거나 (누드김밥 얘기하지마셈),
3. 빵 위에 소스를 먼저 뿌리거나

하는 행위를 하지 않는 전체 룰 을 지켜서 샌드위치를 제조합니다.
이것이 제일 중요한 사용법 중 하나입니다.

출처: https://dev.to/m_midas/feature-sliced-design-the-best-frontend-architecture-4noj

필요한 계층만 사용하기 📝

주제 그대로 전체 룰 안에서는 자유롭게 조합해서 사용하면 됩니다.
위 주제에서 예시를 들었듯이, Feature 내부에서 여러 Entity 를 결합,
Widget 내부에서 여러 Feature를 props / children 형태로 결합 또는 사용하지 않는 계층은 과감히 생략해도 좋습니다.

그럼 언제 생략을 해도 좋은지를 알아보자면

• 해당 레벨의 책임이 비어있거나 중복일 때,
• 크로스 슬라이스 조립이 거의 없는(widgets, processes 미사용) 경우,
• 한두 파일만 있는 형식적 디렉터리일 때

1. 안먹는 야채는 아예 빼고, 같은 소스를 두 번 뿌리지 않듯이,
2. 세트 또는 콤보로 바꾸지 않고 샌드위치 단품으로만 주문을 할 수 있고,
3. 운영적인 측면에선 소스병 하나 쓰려고 소스바를 만들지 않는

경우들을 예로 들 수 있겠습니다.
이렇게 개발자가 커스텀을 해볼 수 있는 구조로 DX 지향 성격이 강합니다.
즉, 나만의 썹픽을 만들어 먹자!

📍 사실상 이번 과제는 하나의 큰 규칙만 잘 지키면 흥미로운 설계를 경험할 수 있습니다.
이를 통해 각자의 개발 취향과 성향을 알아보고, 다양한 구조를 탐색하며 파악하는 좋은 기회가 될 것입니다.

---

📬 참고 링크

FSD 를 더 잘 정리된 버전으로 알고싶다면 영서의 PR을 참고하셔도 좋습니다.
다들 아시죠? 빛영서 ✨✨✨✨✨ 모두들 많이 봐주세요!

링크 모음
🔗 Feature-Sliced Design: The Best Frontend Architecture
🔗 feature-sliced.design_FAQ 🔗 Layer Import 규칙
🔗 A quick introduction to clean architecture
🔗 영서_PR

---

💬 gpt-5 와 대화: FUN FUN GPT

gpt-5 가 2025.08.08 정식 공개됐다. 그래서 '그 AI' 의 견해를 듣고싶었다. 참을 수 없었다. 왜냐 나는 커서 과금 유저고 지금 공짜여서 ㅎㅎ... (글을 작성하는 시점 25.08.10 지피티5 살짝 논란이 있어보임..)
gpt-5 와 샌드위치(subway)에 대한 견해를 나눴다. 재미(?)로 봐주세요. 🤪🤪🤪
시간이 아까우신 분 또는 뻘글 싫다는 분 제일 밑 부분만 확인! 2줄 요약 해둠.

Q. FSD 아키텍쳐 구조가 샌드위치 랑 비슷하다면 믿을래?

한 줄 답

• 네, 비유로는 충분히 그럴듯합니다. 다만 FSD는 “수평 계층 + 수직 슬라이스” 구조라, 단순 샌드위치 비유만으로는 전부를 담기 어렵습니다.

간단 매핑(샌드위치 비유)

• 윗빵: app — 전역 설정/부트스트랩(라우팅, 스타일, DI)
• 속재료(위→아래 순)
  • processes — 전역 흐름(옵션)
  • pages — 경로 단위 조립
  • widgets — 페이지 큰 블록
  • features — 사용자 시나리오 단위
  • entities — 도메인 모델/핵심 규칙
• 아랫빵: shared — 공용 UI/라이브러리/유틸/설정

비유가 좋은 점

• 의존성은 위→아래로 흐른다(윗재료가 아래 재료를 참고).
• 빵(app, shared)이 틀을 잡고, 속재료가 의미를 만든다.

비유의 한계

• FSD는 “클럽 샌드위치”처럼 여러 층과 “세로로 자른 조각(슬라이스: feature 단위)”이 동시에 존재.

• 공개 API(index.ts)와 의존 규칙(상위→하위만 의존) 같은 규범은 샌드위치만으로 설명이 부족.

• 요약

  • 비유: 이해에 도움 됨(빵=틀, 재료=계층).
  • 한계: 수직 슬라이스/공개 API/의존 규칙은 별도 설명 필요.

Q. 근데 너는 샌드위치를 정말 시각적인 레이어로 생각해서 했는데. 샌드위치를 만드는 방식에서 FSD 와 비교를 해줄래?

한 줄 결론

• 샌드위치 “만드는 법”을 표준화·경계·자동화까지 갖추면, 운영 원리는 FSD와 거의 같습니다. 차이는 FSD가 수직 슬라이스/공개 API/경계 강제를 체계로 포함한다는 점.

조건
표준화: 모두 같은 레시피·순서·수치로 만든다.
경계: 섞이지 않게 구역·의존을 제한한다.
자동화: 도구/시스템이 규칙 위반을 자동으로 잡는다.
한 줄: 같게 만들고, 섞이지 않게 나누고, 기계로 계속 검사한다

핵심 차이

• 샌드위치(비유/결과): 물리적 레이어와 순서 중심.
• FSD(체계): 레이어 + 수직 슬라이스 + 공개 API + 자동화된 경계 강제.

실무 체크리스트(샌드위치를 FSD처럼)

• 단방향 의존: UI/pages/widgets → features → entities
• 공개 API 통제: 각 슬라이스 index.ts만 노출, 내부 경로 import 금지
• 경계 자동화: import 규칙, 테스트/타입체크, CI 필수화
• 코드 스플리팅: 라우트/피처 단위 청크
• 문서화: 폴더/네이밍/의존 규약, ADR 유지
• 역할 분리: 디자인 토큰·공용 UI는 shared, 도메인 규칙은 entities

최종 정리

• 조건을 “지속적으로” 강제하면 체감상 구분이 어렵고, 사실상 FSD와 동일하게 작동합니다.

Q. 너가 제시한 방향이면 한계를 극복한 샌드위치가 되는거네? 한계를 극복한 샌드위치는 FSD 와 구분할 수 없는거지?

... 중략 ...

한 줄 답
개념적으로는 다르지만, 제시한 규칙을 문서화·자동화로 “지속 강제”하면 실무적으로는 거의 구분하기 어렵습니다.

gpt-5 대화 2 줄 요약

• 규칙을 제도화한 샌드위치 🥪 ≈ FSD.
• 핵심: 단방향 의존, 슬라이스 API, 경계 강제, shared 격리, 스플리팅, 문서화.

---

이번주 6기와의 추억 🌇

6기와의 추억이 많지만 캡쳐를 못한 관계로.....

사랑, 버릇 없는 친구들, 그리고 사주

과제하면서 한 곡 반복으로 벌써 일년 들었는데..... 시간과 정신의방 갔다옴.

상큼한 병준이.. 그리고 나..

풍.년.집 꼭 다 같이 갑시다.

---

✅ Keep: 이번주 내가 잘한 것들

• 과제 제출이 50%를 달성한 것. 나머지 반도 무탈하게 지나갔으면싶다.
  

❗ Problem: 탈탈 털린 순간

• 처음 상태 관리 라이브러리를 사용해서 감이 안잡혔지만.. 그래도 AI 한테 물어보면서 맞는지 계속 체크하면서 진행했다.
• 개발과는 별개인 문제인데 11월 JTBC 마라톤을 위한 연습이 잘 안되고 있다. 항해,러닝 두 마리 토끼 잡는게 쉽지 않다... 컨디션, 체력 모두 다 신경써야지

💡 Try: 노력, 다짐, 실행

• FSD 아키텍처에 대해 관심이 생겼다. 마침 6주차 과제가 FSD 구조를 학습하는 것이기에 '이 구조가 왜 그렇게 사람들 입에 오르내리는지' 알고싶다.

🧠 이번 주 한 줄 회고:

내 썹픽 궁금하지?

▶ 허정석님의 추천 코드 : Vo6fpd