[250519 TIL] FSD

작년에 FSD를 나름대로(?) 적용하여 진행했던 프로젝트가 있었습니다.

그러나 FSD에 대한 깊은 이해를 바탕으로 적용했다기 보다는
그냥 '기능 중심으로 묶는다' 정도로 생각했었기 때문에 부족함을 많이 느꼈었습니다.

 

그래서 이번에 FSD를 다시한번 공부하며 도입해 보았는데 이 과정에서
여러 의견을 종합하고 제 나름대로 커스텀(...)해보았던 기록을 남깁니다.

 

FSD의 개념에 대한 내용은 검색하면 많이 나옵니다.
# (번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처
# 프론트엔드 개발자 관점으로 바라보는 관심사의 분리와 좋은 폴더 구조 (feat. FSD)
# Feature-Sliced Design을 직접 사용하면서 느낀 장점과 단점
# FSD 아키텍처 알아보기
위 블로그 등을 참고할 수 있겠습니다(감사합니다)

 

 

(FSD 미적용) 보통의 경우 ...

Next.js 14+ app router 사용시, 아래와 같은 구조에서 시작하여..

public/
src/  
  └── app/

이런 느낌이 되는 경우가 많았습니다.

public/
src/  
  ├── app/
  ├── pages/ or templates/
  ├── components/
  │    ├── ui/ 
  │    ├── auth/
  │    └── 무언가분류/
  ├── providers/
  ├── contexts/
  ├── apis/
  ├── hooks/
  ├── utils/ or libs/
  └── types

 

역할에 따라 분류가 되어 있지만 계층 구조가 생기지 않습니다.

 

따라서 의존성이 단방향을 이루지 않아 구조가 커질수록 복잡도가 상승하고 결합(coupling)도는 높은데 응집도(cohesion)는 낮은 현상이 발생합니다.

 

-> 이런 경우 FSD 도입은 좋은 해법이 될 수 있습니다.
-> 아토믹 패턴처럼 ui 위주로 분류하는 것도 아니고
-> 로직 - view 를 너무 엄격하게 분리하여 react 프론트엔드에 도입이 힘든 것도 아니기 때문.

 

 

but FSD를 애매하게 도입할 경우...

하지만, FSD를 무작정 도입하게 되면, 큰 두가지 단점에 걸릴 확률이 높습니다.

1. 초기 학습 곡선 - 다른 디자인 패턴과 유사하면서도 어떤 면에서 더욱 높은 학습 곡선을 요구하므로, 분류가 중구난방이 되고 개발 효율이 초기에 저하되기 쉬움
2. 할계우도 - MVP 만드는데 무작정 FSD 도입하면 복잡도만 증가함

직접 적용해 본 결과 1번은 반드시 걸리고, 2번은 FSD의 좋은 점만 잘 취한다면 회피가 가능해 보였습니다.

결국, 2번의 문제를 어떻게 회피하고 긍정적으로 해결할 것인가? 가 FSD 도입의 가장 큰 난제인 것 같습니다.

 

일례로 아토믹 디자인 패턴에서 어디까지 atoms 고, 어디까지 molecules 고 하는 문제, 즉 팀원 별로 관점이 상이할 수 있다는 부분은 FSD 에서도 동일하게 발생(slice를 어떻게 정의하느냐는 결국 팀의 재량)하기 때문에 FSD가 실버불릿은 아닌게 확실합니다. (widgets, features, entities 구분 문제)

 

더구나 React 에서는 아무리 분리하더라도 로직과 뷰가 어느정도 하나의 JSX 에 섞여있게 되기도 하구요.

 

 

생각해 본 해법

1. app 계층은 /src/app 을 사용하는 대신 next.js app 디렉터리에 위임.
   • 논란의 여지가 있겠지만 Next.js app router 에서는 이 app 계층과 관련된 디렉터리가 두 개 존재할 수 있기때문에 복잡도가 더욱 증가할 수 있다고 판단됩니다.
   • 일례로 middleware.ts 를 사용하려고 해도 Next.js app router 사용시 app 디렉터리와 동일 레벨에 있어야만 합니다.
   • 때문에 /app 과 /src/app 이 동시에 존재한다면 'app' 이라는 명칭이 두 번 사용되는 것 만으로도 혼란을 가중시키고, 예약 파일인 middleware 등은 / 즉, 루트 경로에만 두어야 하는 등 본격 FSD 에 해당하는 /src/app 디렉터리에는 정작 글로벌한 파일들을 위치시킬 수 없게 됩니다.
   • FSD에 따르면, /src/app(app 계층) 에는 store, provider, globals.css 등이 들어가게 되는데 전역 store 및 provider는 features 혹은 shared에 넣는게 더 명확할 수 있고, globals 등은 그냥 프로젝트 생성시에 이미 /src/app 말고 app(Next.js app 디렉터리) 에 생기므로 놔두는 편이 나을 수 있다고 판단됩니다.
   • 즉 app 계층은 next.js app router 에서 생성되는 app 디렉터리로 사용하는 것입니다.
2. pages 는 templates 로 변경.
   • pages 라는 명칭은 app router 의 page.tsx 와 혼동되기 쉽습니다.
   • 기존의 pages 를 templates 로 변경한다면, page.tsx 에 import 되는 컴포넌트는 oooTemplate.tsx 가 될 것이고 이는 계층 인식을 명확하게 하여 혼동을 줄여줄 수 있을 것으로 생각됩니다.
   • 또한 fetching, pre-fetching 을 page.tsx에서 수행하고, oooTemplate.tsx 로 props 로 전달할 때도 유용할 것으로 생각됩니다.
3. widgets 는 보류. 추후 프로젝트 사이즈가 나눌 정도로 커지면 사용 고려.
   • 📌 도입 기준: “반복적 대형 UI 블록” 이 2개 이상 등장하는 시점에서 고려 (ex. 헤더, 카드 그룹 등)
4. features 는 기존대로 사용하지만, 2가지 가능성 고려.
   • !! 여기서 변형 1, 변형 2 로 나뉠 수 있다고 생각했습니다 !!
   1. 변형 1
      • features 하위에 기존에 익숙한 역할별 분류법을 어느정도 유지합니다.
      • providers, contexts, hooks, apis, queries, constants 등... 역할 별 분류 디렉터리를 일단 유지하고
      • 그 외 기능별로 묶을 수 있는 요소들, 예를들어 인증/인가라면 auth 등의 디렉터리를 만들고 여기에는 서브패스를 적용한 파일들이 위치합니다. ex) auth.queries.ts, auth.hooks.ts, auth.apis.ts ....
   2. 변형 2
      • 변형 1과 다르게, 역할 별 분류법을 유지하지 않습니다.
      • 좀 더 FSD 와 유사하게, 기능 중심으로 분류합니다.
      • 예를들어 auth 라면, 서브패스를 사용하지 않고 ui/, queries.ts, hooks.ts, apis.ts ... 등으로 사용합니다.
      • FSD의 개념대로 /apis, /model, /ui 등 디렉터리를 사용할 수 있습니다.
5. entities 는 유지하되, 필요시에만 사용한다.
   • 계층을 아무리 분리해도 한 JSX에 로직과 뷰가 붙어있는 경우가 많은 React의 특성을 고려한다면,
   • FSD의 entities 에 핵심 비지니스 로직을 몰아두려고 노력해도 안될 확률이 있다.
   • 따라서 entities 계층 개념은 유지하되 아래처럼 확실한 경우에 사용.
   • ✅ 선택적 사용 (공유 도메인이 2개 이상 feature에서 쓰일 경우 승격)
6. shared 는 동일하게 유지.
7. components 디렉토리를 사용하되, shadcn 전용으로 사용(계층과 관계 무)
   • shadcn 을 거의 필수적으로 사용하기 때문에, shadcn 설치시 기본적으로 설치되는 경로는 그냥 유지합니다(옮기기 귀찮으므로)
   • 다만 components 라는 명칭의 디렉터리가 있어도 여기에는 shadcn 외에는 보관하지 않습니다.

해법 - 변형1 - 디렉터리구조 예시

├── app/                  # Next.js의 App Router 폴더 (라우트 구성 전담)
│   ├── layout.tsx
│   ├── page.tsx          // 예: 루트 페이지 -> 내부에서 src/templates/home 불러옴
│   ├── globals.css       
│   └── (기타 Next 전용 폴더/파일들)
├── src/                  # 실제 애플리케이션 구현 (FSD 구조)
│   ├── templates/        # FSD Templates 계층 (각 페이지-템플릿 컴포넌트)
│   ├── features/         # FSD Features 계층
│   │   ├── providers
│   │   ├── contexts
│   │   ├── hooks
│   │   ├── apis
│   │   ├── queries
│   │   └── 기타필요한디렉터리(auth등)
│   ├── entities/(필요시    # FSD Entities 계층(필요시 추가)
│   ├── shared/           # FSD Shared 계층
│   └── components/       # FSD Templates 계층 (각 페이지-템플릿 컴포넌트)
│       └── ui/           # shadcn ui 를 사용하기 편리하게 하기 위함.
└── middleware.ts         # Next.js 의 app 과 동일한 레벨에 있어야 함.

 

해법 - 변형2 - 디렉터리구조 예시

├── app/                  # Next.js의 App Router 폴더 (라우트 구성 전담)
│   ├── layout.tsx
│   ├── page.tsx          // 예: 루트 페이지 -> 내부에서 src/templates/home 불러옴
│   ├── globals.css       
│   └── (기타 Next 전용 폴더/파일들)
├── src/                  # 실제 애플리케이션 구현 (FSD 구조)
│   ├── templates/        # FSD Templates 계층 (각 페이지-템플릿 컴포넌트)
│   ├── features/         # FSD Features 계층
│   │   ├── auth          # 기능별
│   │   │   ├── queries.ts
│   │   │   ├── consts.ts
│   │   │   ├── hooks.ts
│   │   │   └── actions.ts
│   │   ├── like          # 위와 동일
│   │   ├── post
│   │   └── task
│   ├── entities/(필요시    # FSD Entities 계층(필요시 추가)
│   ├── shared/           # FSD Shared 계층
│   └── components/       # FSD Templates 계층 (각 페이지-템플릿 컴포넌트)
│       └── ui/           # shadcn ui 를 사용하기 편리하게 하기 위함.
└── middleware.ts         # Next.js 의 app 과 동일한 레벨에 있어야 함.

 

 

---

 

추가로 질의응답을 첨부합니다.

Q1

저는 FSD 에서 등장하는 model 과 entities 에 관한 궁금증이 있어요.

1. FSD 는 프론트엔드를 위한 것으로 아는데 model 이라는 개념은 백엔드와 더 관련이 있지 않나요? react 프로젝트에서 model 은 어떤 부분에 주로 해당할까요?
2. entities 역시 nest.js 의 typeORM의 entity 가 떠오르는데요. 이 계층은 왜 이름이 entities 이며, 역시 react 프로젝트에서 entities는 주로 어떤 부분에 해당하나요?

---

A1

좋은 질문입니다! FSD에서 model과 entities는 백엔드와 겹치는 용어이긴 하지만, 프론트엔드(특히 React)에서도 충분히 유의미한 역할을 합니다. 각각의 개념을 React 관점에서 분해해 설명드릴게요.

1. model – 프론트엔드에서 무엇을 의미하나요?

📌 일반적 오해

• model이라는 단어는 백엔드의 데이터베이스 모델(예: ORM의 모델 클래스)로 익숙합니다.
• 그래서 프론트에서 model이라는 폴더가 있으면 “DB랑 연관 있는 것 아냐?”라는 생각이 들기 쉽습니다.

✅ FSD에서의 의미 (React 기준)

• model은 해당 슬라이스(기능)의 상태, 비즈니스 로직, 도메인 타입, 파생 상태 등을 다루는 계층입니다.
• 즉, "어떻게 동작하는가"를 정의하는 계층입니다.

🧩 주로 포함되는 것들:

• 상태 관리 로직 (예: Zustand, Redux slice, useState + useReducer 조합)
• 도메인 관련 타입 (TypeScript type/interface)
• 파생 로직 (예: computed values, formatters)
• 비즈니스 규칙 (예: 특정 조건 하에서 버튼을 disable 처리하는 로직)

📁 예시

features/auth/
├── model/
│   ├── types.ts        // AuthUser, AuthToken 등 타입
│   ├── store.ts        // Zustand 상태
│   └── validators.ts   // 로그인 검증 로직, zod schema 등

2. entities – 왜 이름이 '엔티티'고, 무엇을 다루나요?

📌 어감상의 혼동

• 백엔드에서 Entity는 DB 테이블-객체 매핑을 의미 (예: TypeORM, Prisma 등)
• 그래서 React에서 이 단어를 보면 “DB랑 연결된 건가?” 싶지만,
• FSD에서는 전혀 다른 관점에서 사용합니다.

✅ FSD에서의 의미 (React 기준)

• entities는 비즈니스 중심 객체(도메인 개체)를 나타냅니다.
• 여러 feature에서 반복 사용되는 도메인 단위의 UI·로직 묶음입니다.
• 쉽게 말해 "앱의 핵심 구성 요소를 담당하는 계층"입니다.

🧩 언제 쓰는가?

• 복수의 feature가 동일한 도메인을 다룰 때 (user, product, task, notification 등)
• 이 도메인을 중앙 집중화해서 중복/오염을 막고 싶을 때

🧩 포함되는 것들:

• 도메인 타입, API DTO 변환기
• 해당 도메인의 공통 UI 컴포넌트
• 비즈니스 로직 중 일부

📁 예시

entities/user/
├── model/
│   ├── types.ts          // User 타입 정의
│   ├── formatters.ts     // 이름 포매팅, 날짜 포매팅
├── ui/
│   └── UserCard.tsx      // 재사용 가능한 유저 컴포넌트

📌 예시 상황: features/like, features/post, features/profile에서 모두 UserCard를 쓴다면, 이걸 entities/user로 승격

---

✍️ 요약

구분	model	entities
위치	각 feature 내부	src/entities/도메인명/
주요 목적	상태, 도메인 로직, 타입 정의	여러 feature가 공유하는 도메인 중심 UI/로직 캡슐화
포함 예시	Zustand store, 타입, validator, 컴포지션 로직	공통 타입, 포매터, UI 컴포넌트
유사한 개념	useStore/useReducer, domain.ts	공통 컴포넌트 라이브러리

---

궁극적으로,

• model: 기능 내부의 "작동 원리"
• entities: 여러 기능 간 공유되는 "중심 객체"

이렇게 구분하시면 React 환경에서도 혼동 없이 적용 가능합니다.

 

 

---

Q2

1. 관심사 분리에 따라 역할 중심으로 html, css, js 가 나왔다고도 볼 수 있다. 그런데 점차 컴포넌트 단위 개발이 보편화되면서 기능 중심으로 계층화 되었다. 이는 새로운 복잡성을 초래하였고 이를 해결하기 위한 시도들이 현대 프론트엔드 레포 구성의 기본적인 골자를 구성하게 되었다. (ui 계층구조 만들기, html-css 간 의존성, 비즈니스로직-뷰로직 분리, 서버 상태 관리 등)
2. 이 과정에서 대두된 문제는, 계층적 구조로 분리하다보면 독립적 기능 구조가 필요하게 되고, 반대로 독립적 기능 구조로 분리하다보면 계층적 분리의 필요성이 강해진다는 것이다. 이는 module 과 layer 라는 두 가지 관심사의 '기준' 이 대두되는 이유이다.
3. 이러한 관심사의 기준에는 하나가 더 있다. 바로 '데이터의 흐름' 이라는 기준이다. (클린 아키텍처)
4. 이처럼 관심사는 관점에 따라 늘어날 수 있다. 하지만 폴더구조는 하나로 정해야한다.
5. 때문에 이런 고민 속에서 등장한 것이 FSD 등의 방법론이다. (여기까지가 현대 프론트엔드와 FSD 의 이해)
6. 결국, 여러 방법을 시도하는 과정에서 고려해야 할 가장 중요한 점은 solid 등 소프트웨어 공학의 원칙들이 아닐까?(SRP, OCP, ISP, 단방향데이터흐름, 응집도는높게결합도는낮게 등)
7. (여기서부터 ai 시대의 질문들) 그런데, 이러한 중요 원칙들은 사람에게 맞추어져 있을때 의미가 있는게 아닐까? ai first 개발 방법론이 정착되어도, 관심사의 분리나 단일책임원칙 같은 원칙들이 꼭 중요할까? 코드의 90% 이상을 ai 가 작성하고 사람보다 100배는 빠른 속도로 코드베이스를 읽는데, 약간의 코딩에서의 비효율 같은게 의미가 있을까?(예를 들어 jsx 가 비대해지면 사람이 읽는데 문제가 생기지만, ai 한테는 별 문제 아니지 않을까?)

 

---

A2

✅ 1–5: 현대 프론트엔드의 구조 진화와 FSD의 등장

✔️ 매우 타당한 해석입니다.

• HTML, CSS, JS의 역할 분리 → 컴포넌트화 → 계층화 → 기능 중심 구조(FSD 등)
  이 흐름은 프론트엔드 역사에서의 중심 축이며, 그 과정에서의 “관심사의 기준” 을 layer, module, data flow로 분류한 것도 인상 깊습니다.
• 특히 2번에서 제기한 “독립 기능 구조 ↔ 계층 구조” 의 상호 필요성은 FSD가 왜 slice 개념을 기반으로 모듈과 계층을 조화시켰는지 잘 설명해줍니다.

---

✅ 6: FSD와 소프트웨어 공학 원칙의 관계

✔️ 핵심 통찰: FSD는 소프트웨어 공학의 원칙(SOLID) 을 프론트엔드에 맞게 현실화한 사례입니다.

• 예를 들어,
  • SRP(단일 책임 원칙): 각 feature의 model/ui/api 분리
  • OCP(개방 폐쇄 원칙): 외부 UI는 shared/widgets, 내부 UI는 feature/ui로 분리
  • DIP(의존 역전 원칙): 고수준 → 저수준 흐름 강제 (ESLint boundaries)
  • 단방향 데이터 흐름: React의 기본 철학
  • 고응집/저결합: FSD의 계층·슬라이스 기준 자체가 이를 목적으로 함

✅ 즉, FSD는 현대 프론트엔드 문맥에 맞게 공학적 원칙을 “현실적”으로 재해석한 패턴이라고 볼 수 있습니다.

---

🤖 7: AI 시대에도 이러한 원칙이 여전히 유효한가?

핵심 질문: “원칙은 사람이 이해하기 위해 필요한 것인가, 시스템 자체의 구조적 안정성을 위한 것인가?”

🧠 사람 중심 시대

• 코드는 “사람이 이해해야 유지보수 가능”해야 하므로 가독성, 역할 분리, 문맥 일관성이 필수였습니다.
• 이때 SRP, 관심사 분리, FSD 같은 구조는 “사람의 인지부하 최소화”를 목적으로 등장.

🤖 AI-first 시대

• GPT나 Agent 기반 코드 작성 도우미는 수천 줄짜리 비정형 JSX도 전혀 문제 없이 이해·요약·변환할 수 있습니다.
• 따라서 구조적 복잡성에 대한 비용은 사람보다 AI에겐 훨씬 작습니다.
• ⇒ 결과적으로 “비대하거나 혼합된 구조”도 AI에겐 문제가 되지 않을 수 있습니다.

🔁 BUT: 중요한 전환점

코드 작성자가 AI라고 해서 구조적 설계의 원칙이 무의미해지지는 않습니다.

이유 3가지:

1. AI는 팀 단위로 일하지 않는다. (아직은)
   • 팀 협업, 리뷰, 테스트, 지속적 확장에는 여전히 인간 기준의 일관성과 구조적 예측 가능성이 필요.
   • 예: 특정 기능이 어디 위치하는지 예측 가능해야 유지보수/추론이 가능함.
2. AI는 논리적 일관성에는 강하지만, 도메인 전략에는 약하다.
   • AI는 문맥은 잘 추론하지만 어떤 구조로 어떤 책임을 가져야 하는가? 같은 도메인 중심 설계에는 여전히 사람이 주도.
3. 궁극적으로 코드는 제품의 일부가 아니라, “팀 지식의 표현체”이다.
   • 따라서 AI가 작성하더라도, 팀 내 공유 가능한 표현으로 구조화하는 것은 여전히 중요.

---

🧭 결론: AI-first 시대에 아키텍처가 의미 없지는 않다

항목	사람 중심 시대	AI-first 시대
코드 작성 속도	느림	빠름
구조의 필요	가독성 위해 필요	문맥 예측 위해 여전히 필요
책임 분리	인지 부하 감소	도메인 설계와 변경 안정성 확보
비대 JSX 문제	심각한 가독성 문제	AI에겐 문제 아님, 그러나 리뷰·협업엔 여전히 장애

---

✨ 앞으로의 방향성

• 아키텍처는 “사람이 짜기 위해 필요한 것” 에서 → “AI가 짜더라도 팀이 이해하고 유지보수할 수 있게 하기 위한 것” 으로 진화할 것
• 구조의 명확성과 의존성 제약은 사람보다는 시스템을 위한 사전 방역선 역할로 재해석될 수 있음
• 따라서, FSD나 SOLID는 AI 시대에도 여전히 유효하며, 오히려 AI가 이를 자동으로 유지시켜줄 수 있는 환경(예: LLM-aware linters, AI-driven code reviewers)이 핵심이 될 가능성이 높습니다

 

---

Q3

클린 아키텍처를 프론트엔드에서 실용적으로 적용하는 부분은 FSD 가 좋은 예인 것 같네요. 그렇다면 제가 궁금한 것은 'AI는 문맥은 잘 추론하지만 어떤 구조로 어떤 책임을 가져야 하는가? 같은 도메인 중심 설계에는 약할 수 있다'고 하셨는데 이 부분이에요. 솔직히 요즘 발표되는 AI 관련 신기술들을 보면 AI가 곧 도메인 중심 설계도 잘하게 될 것 같거든요. 결국 이부분도 케이스들을 sequential thinking 계속하면 AI가 잘 하게 되지 않을까요? 저는 그럴 것 같긴한데, 그렇게 된다 해도 추가 궁금증이 들긴 해요. '도메인' 이라는 용어는 개발에 있어서의 도메인 말고도 비즈니스 도메인 등 세상 모든 만물의 질서를 '도메인'으로 분류할 수도 있는 개념으로 이해하고 있는데요. 인간은 비이성적인 부분이 많으니까 이런 비이성, 비합리적 결정들이 쌓여서 나타나는 현상, 도메인들에 대한 대처는 AI가 약할 수 있을 것 같아요. 만약 AGI 가 되어서 동일한 수준의 비합리적 계산을 할 수 있다면 또 다르겠지만요. 음.. 그러니까 돈버는 일 = 비즈니스 로 생각해본다면, 인간세상의 비즈니스 모델은 계속 비합리적인 부분에서 driven 되는 것이 많을 테고, 비즈니스 모델이 생기면 개발 수요가 생길거고, 이런 비즈니스 모델을 ai-first로 개발하려면 이 '도메인'을 AI가 잘 이해하고 '도메인 중심 설계' 도 잘해야 되는 것일 텐데, 이 때 문제가 될 수는 있겠네요

---

A3

🧠 1. "AI도 결국 도메인 중심 설계 잘하게 될 것 같다" — 맞는가?

✅ Yes, 곧 잘하게 될 것이다

• LLM들은 이미 추상화, 계층화, SRP/OCP 등 아키텍처적 사고를 문맥 속에서 수행합니다.
• 그리고 점점 더 나아가 사례 기반 추론(sequential case-based reasoning) 능력도 발전 중입니다.
• 예: "장바구니-쿠폰 로직을 분리해줘" → cart/model/discount.ts를 만들고 cart/applyDiscount()에 연결함.

➡️ 기술적으로 도메인 중심 설계 자체는 얼마든지 학습하고 적용 가능하다고 봐도 무방합니다.

---

🧩 2. 그러나 진짜 어려운 건 “도메인 자체”다

도메인 중심 설계(Domain-Driven Design, DDD)의 핵심은 기술이 아니라 "업무에 대한 깊은 이해와 판단"입니다.

🧠 인간은 도메인을 이렇게 정의합니다:

• "사용자가 ‘찜’을 여러 번 누르면 불편하니까 중복 방지하자."
• "이 화면은 비주얼적으로 나쁘지만 CEO가 좋아하니까 유지한다."
• "성장 중인 시장이라서 초기엔 정제 안 돼도 빠르게 뽑아야 한다."

🤖 AI는 도메인을 이렇게 추론합니다:

• "찜은 boolean 상태로 표현되며, toggle 처리를 통해 UX를 단순화할 수 있음."
• "디자인은 Figma 리서치 결과 B안이 더 우세함 → A안 선택은 비합리적."
• "요구사항이 모호하니 fail-safe 상태 설계를 추천함."

📍 즉, AI는 합리적 판단은 매우 강하지만,
비합리, 감정, 정치, 타이밍, 관계, 이해관계 같은 인간 특유의 ‘맥락’을 도메인으로 해석하고 반영하는 데는 아직 미숙합니다.

---

🌍 3. 비즈니스 모델이 비합리로부터 생성되는 이유

• 인간의 비즈니스는 “말이 안 되지만 팔리는 것”에서 종종 시작합니다.
• 예시:
  • 3초마다 광고를 보여주는 앱 → 말이 안 되지만 수익남.
  • 아이디 없이 로그인? → 전환율 올라감.
  • 사람 얼굴이 되는 감성적 로딩 애니메이션 → 성능 저하되지만 고객이 좋아함.

이 모든 비합리의 흐름이 도메인의 경계(boundary)를 만들고, 그에 따라 설계도 바뀌게 됩니다.

---

🧭 4. 그래서 미래에는 어떻게 될까?

🤖 AI가 도메인 중심 설계를 잘하게 될 조건:

• 🌐 도메인에 대한 지속적 대화 및 보정 피드백이 가능한 환경 (≒ 팀처럼 대화할 수 있어야 함)
• 🧠 정해진 도메인이 아니라 새롭게 정의되는 도메인을 스스로 개념화할 수 있어야 함
• 🧍 비합리성, 우선순위, 정치적 판단까지도 설명 가능한 AGI 수준에 가까워야 함

즉, 단순히 "코드를 잘 짜는 AI"가 아닌

"도메인을 설계하고, 설계 기준을 문맥에 따라 유연하게 바꾸는 AI"가 필요합니다.

---

🔚 결론:

“도메인 중심 설계란, 기술이 아니라 해석이다.”
현 시점에서 AI는 이 해석을 ‘기계적 패턴’ 수준까지만 잘할 수 있고,
‘비합리의 정당화’까지 끌어안는 설계는 아직 인간의 몫입니다.