@wooojin/forgen 0.4.8 → 0.4.9

package/assets/dev-guide/fe/sources/react/use-optimistic.md

@@ -0,0 +1,194 @@
+---
+title: useOptimistic
+source: https://react.dev/reference/react/useOptimistic
+fetched: 2026-05-18
+category: api
+react_version: 19
+---
+
+## 개요
+
+비동기 Action이 진행되는 동안 UI를 낙관적으로 즉시 업데이트할 수 있는 Hook.
+
+---
+
+## 시그니처
+
+```js
+const [optimisticState, setOptimistic] = useOptimistic(value, reducer?);
+```
+
+### Parameters
+- `value`: 진행 중인 Action이 없을 때 반환할 값
+- `reducer(currentState, action)` (optional): 낙관적 state 계산 순수 함수
+
+### Returns
+1. **`optimisticState`**: Action 없으면 `value`, Action 중이면 `reducer` 반환값
+2. **`set` 함수**: Action 내부에서 낙관적 state를 업데이트
+
+### set 함수 제약
+- **반드시 `startTransition` 또는 Action prop 내에서 호출**
+- 외부에서 호출 시 경고 + 즉시 원래 값으로 롤백
+
+---
+
+## 동작 흐름
+
+```js
+const [value, setValue] = useState('a');
+const [optimistic, setOptimistic] = useOptimistic(value);
+
+startTransition(async () => {
+  setOptimistic('b');      // 1. 즉시 'b' 표시
+  const newValue = await saveChanges('b');  // 2. 서버 요청
+  setValue(newValue);      // 3. 실제 state 업데이트 → 낙관적 state 수렴
+});
+```
+
+> Action 실패 시 자동으로 원래 `value`로 롤백됨.
+
+---
+
+## 사용 패턴
+
+### Form Action과 함께 낙관적 업데이트
+
+```js
+import { useOptimistic, startTransition } from 'react';
+import { updateName } from './actions.js';
+
+export default function EditName({ name, action }) {
+  const [optimisticName, setOptimisticName] = useOptimistic(name);
+
+  async function submitAction(formData) {
+    const newName = formData.get('name');
+    setOptimisticName(newName); // Action prop 내부이므로 startTransition 불필요
+
+    const updatedName = await updateName(newName);
+    startTransition(() => {
+      action(updatedName);
+    });
+  }
+
+  return (
+    <form action={submitAction}>
+      <p>Your name is: {optimisticName}</p>
+      <input type="text" name="name" disabled={name !== optimisticName} />
+    </form>
+  );
+}
+```
+
+### Reducer로 복잡한 낙관적 업데이트
+
+```js
+const [optimisticState, updateOptimistic] = useOptimistic(
+  { isFollowing: user.isFollowing, followerCount: user.followerCount },
+  (current, isFollowing) => ({
+    isFollowing,
+    followerCount: current.followerCount + (isFollowing ? 1 : -1),
+  })
+);
+
+function handleClick() {
+  const newFollowState = !optimisticState.isFollowing;
+  startTransition(async () => {
+    updateOptimistic(newFollowState);
+    await followAction(newFollowState);
+  });
+}
+```
+
+### 목록에 낙관적 항목 추가
+
+```js
+const [optimisticTodos, addOptimisticTodo] = useOptimistic(
+  todos,
+  (currentTodos, newTodo) => [
+    ...currentTodos,
+    { id: newTodo.id, text: newTodo.text, pending: true },
+  ]
+);
+
+function handleAddTodo(text) {
+  const newTodo = { id: crypto.randomUUID(), text };
+  startTransition(async () => {
+    addOptimisticTodo(newTodo);
+    await addTodoAction(newTodo);
+  });
+}
+```
+
+### 에러 시 롤백 패턴
+
+```js
+const [error, setError] = useState(null);
+const [optimisticItems, removeItem] = useOptimistic(
+  items,
+  (currentItems, idToRemove) =>
+    currentItems.map(item =>
+      item.id === idToRemove ? { ...item, deleting: true } : item
+    )
+);
+
+function handleDelete(id) {
+  setError(null);
+  startTransition(async () => {
+    removeItem(id);
+    try {
+      await deleteAction(id);
+    } catch (e) {
+      setError(e.message); // 실패 시 UI 자동 롤백
+    }
+  });
+}
+```
+
+### 여러 독립 낙관적 state
+
+```js
+function MyComponent({ age, name, todos }) {
+  const [optimisticAge, setOptimisticAge] = useOptimistic(age);
+  const [optimisticName, setOptimisticName] = useOptimistic(name);
+  const [optimisticTodos, setOptimisticTodos] = useOptimistic(todos, reducer);
+}
+```
+
+---
+
+## 주요 특성
+
+- **임시성**: Action 진행 중에만 낙관적 state 표시, 완료 후 `value`로 수렴
+- **자동 롤백**: Action 실패 시 원래 `value` 렌더링
+- **추가 렌더 없음**: Transition 완료 시 낙관적/실제 state가 단일 렌더에서 수렴
+- Reducer 사용 시 변경 중인 base state에도 올바르게 적용됨
+
+---
+
+## Troubleshooting
+
+```js
+// ❌ Transition 외부에서 호출
+function handleClick() {
+  setOptimistic(newValue);
+}
+
+// ✅ startTransition 내부
+function handleClick() {
+  startTransition(async () => {
+    setOptimistic(newValue);
+  });
+}
+```
+
+**pending 여부 확인 3가지 방법:**
+```js
+// 1. 값 비교
+const isPending = optimisticValue !== value;
+
+// 2. useTransition
+const [isPending, startTransition] = useTransition();
+
+// 3. reducer에 pending 플래그 포함
+(state, newItem) => [...state, { ...newItem, isPending: true }]
+```

package/assets/dev-guide/fe/sources/toss-ff/INDEX.md

@@ -0,0 +1,58 @@
+---
+title: Toss Frontend Fundamentals — 챕터 인덱스
+fetched: 2026-05-18
+source: https://github.com/toss/frontend-fundamentals + https://frontend-fundamentals.com/code-quality/
+---
+
+# Toss Frontend Fundamentals — 챕터 인덱스
+
+수집 일자: 2026-05-18  
+출처: https://github.com/toss/frontend-fundamentals / https://frontend-fundamentals.com/code-quality/
+
+## 개요
+
+| 파일 | 원칙 | 한 줄 요약 |
+|------|------|-----------|
+| overview-4-principles.md | 전체 | 4대 원칙(가독성·예측성·응집도·결합도) 정의 및 트레이드오프 |
+
+## 가독성 (Readability)
+
+| 파일 | 한 줄 요약 | 핵심 안티패턴 |
+|------|-----------|--------------|
+| readability-submit-button.md | 같이 실행되지 않는 코드 분리하기 | 권한별 분기가 교차된 단일 컴포넌트 → 권한별 컴포넌트 분리 |
+| readability-login-start-page.md | 구현 상세 추상화하기 | 로그인 체크 로직 노출 → AuthGuard HOC/Wrapper로 추상화 |
+| readability-use-page-state.md | 로직 종류에 따라 합쳐진 함수 쪼개기 | 페이지 전체 쿼리파람 관리 훅 → 파라미터별 독립 훅 |
+| readability-condition-name.md | 복잡한 조건에 이름 붙이기 | 중첩 filter/some 익명 → `isSameCategory`, `isPriceInRange` 변수 추출 |
+| readability-magic-number.md | 매직 넘버에 이름 붙이기 | `delay(300)` → `const ANIMATION_DELAY_MS = 300` |
+| readability-user-policy.md | 시점 이동 줄이기 | POLICY_SET → getPolicyByRole → policy 3단계 참조 → 인라인 객체로 단순화 |
+| readability-ternary-operator.md | 삼항 연산자 단순하게 하기 | 중첩 삼항 → IIFE + early return if문 |
+| readability-comparison-order.md | 왼쪽에서 오른쪽으로 읽히게 하기 | `a >= b && a <= c` → `b <= a && a <= c` (수학 부등식 순서) |
+
+## 예측 가능성 (Predictability)
+
+| 파일 | 한 줄 요약 | 핵심 안티패턴 |
+|------|-----------|--------------|
+| predictability-http.md | 이름 겹치지 않게 관리하기 | 라이브러리와 동일한 `http` 이름 → `httpService.getWithAuth`로 구분 |
+| predictability-use-user.md | 같은 종류의 함수는 반환 타입 통일하기 | useUser는 Query 객체, useServerTime은 data만 반환 → 둘 다 Query 객체로 통일 |
+| predictability-hidden-logic.md | 숨은 로직 드러내기 | fetchBalance 안에 logging 숨김 → fetch는 fetch만, logging은 호출 측으로 분리 |
+
+## 응집도 (Cohesion)
+
+| 파일 | 한 줄 요약 | 핵심 안티패턴 |
+|------|-----------|--------------|
+| cohesion-code-directory.md | 함께 수정되는 파일을 같은 디렉토리에 두기 | 모듈 종류별 flat 구조 → 도메인별 계층 구조 |
+| cohesion-magic-number.md | 매직 넘버 없애기 (응집도 관점) | `delay(300)` 애니메이션 변경 시 둘 중 하나만 수정 위험 → 상수로 결합 |
+| cohesion-form-fields.md | 폼의 응집도 생각하기 | 필드 단위 응집(react-hook-form validate) vs 폼 전체 응집(zod schema) 선택 기준 |
+
+## 결합도 (Coupling)
+
+| 파일 | 한 줄 요약 | 핵심 안티패턴 |
+|------|-----------|--------------|
+| coupling-use-page-state.md | 책임을 하나씩 관리하기 | 모든 쿼리파람 통합 훅 → 수정 영향범위 과대 → 파라미터별 분리 |
+| coupling-use-bottom-sheet.md | 중복 코드 허용하기 | 유사해 보이는 바텀시트 로직 공통화 → 페이지별 분기 과잉 → 중복 허용 권장 |
+| coupling-item-edit-modal.md | Props Drilling 지우기 | 3단계 prop 전달 → Composition 패턴(`children`) 또는 Context API |
+
+## 총계
+
+- 총 파일 수: 15개 (INDEX.md 제외)
+- 원칙별: 가독성 8, 예측가능성 3, 응집도 3, 결합도 3

package/assets/dev-guide/fe/sources/toss-ff/cohesion-code-directory.md

@@ -0,0 +1,79 @@
+---
+title: 함께 수정되는 파일을 같은 디렉토리에 두기
+source: https://frontend-fundamentals.com/code-quality/code/examples/code-directory.html
+fetched: 2026-05-18
+principle: cohesion
+---
+
+# 함께 수정되는 파일을 같은 디렉토리에 두기
+
+프로젝트에서 코드를 작성하다 보면 Hook, 컴포넌트, 유틸리티 함수 등을 여러 파일로 나누어서 관리하게 돼요. 이런 파일들을 쉽게 만들고, 찾고, 삭제할 수 있도록 올바른 디렉토리 구조를 갖추는 것이 중요해요.
+
+함께 수정되는 소스 파일을 하나의 디렉토리에 배치하면 코드의 의존 관계를 명확하게 드러낼 수 있어요.
+
+## 📝 코드 예시
+
+다음 코드는 프로젝트의 모든 파일을 모듈의 종류에 따라 분류한 디렉토리 구조예요.
+
+```text
+└─ src
+   ├─ components
+   ├─ constants
+   ├─ containers
+   ├─ contexts
+   ├─ remotes
+   ├─ hooks
+   ├─ utils
+   └─ ...
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 응집도
+
+파일을 이렇게 종류별로 나누면 어떤 코드가 어떤 코드를 참조하는지 쉽게 확인할 수 없어요. 코드 파일 사이의 의존 관계는 개발자가 스스로 코드를 분석하면서 챙겨야 해요.
+
+또한 더 이상 특정 컴포넌트나 Hook, 유틸리티 함수가 사용되지 않아서 삭제된다고 했을 때, 연관된 코드가 함께 삭제되지 못해서 사용되지 않는 코드가 남아있게 될 수도 있어요.
+
+## ✏️ 개선해보기
+
+다음은 함께 수정되는 코드 파일끼리 하나의 디렉토리를 이루도록 구조를 개선한 예시예요.
+
+```text
+└─ src
+   │  // 전체 프로젝트에서 사용되는 코드
+   ├─ components
+   ├─ containers
+   ├─ hooks
+   ├─ utils
+   ├─ ...
+   │
+   └─ domains
+      │  // Domain1에서만 사용되는 코드
+      ├─ Domain1
+      │     ├─ components
+      │     ├─ containers
+      │     ├─ hooks
+      │     ├─ utils
+      │     └─ ...
+      │
+      │  // Domain2에서만 사용되는 코드
+      └─ Domain2
+            ├─ components
+            ├─ containers
+            ├─ hooks
+            ├─ utils
+            └─ ...
+```
+
+함께 수정되는 코드 파일을 하나의 디렉토리 아래에 둔다면, 코드 사이의 의존 관계를 파악하기 쉬워요.
+
+예를 들어, 다음과 같이 한 도메인(`Domain1`)의 하위 코드에서 다른 도메인(`Domain2`)의 소스 코드를 참조한다고 생각해 볼게요.
+
+```typescript
+import { useFoo } from "../../../Domain2/hooks/useFoo";
+```
+
+이런 import 문을 만난다면 잘못된 파일을 참조하고 있다는 것을 쉽게 인지할 수 있게 돼요.
+
+또한, 특정 기능과 관련된 코드를 삭제할 때 한 디렉토리 전체를 삭제하면 깔끔하게 모든 코드가 삭제되므로, 프로젝트 내부에 더 이상 사용되지 않는 코드가 없도록 할 수 있어요.

package/assets/dev-guide/fe/sources/toss-ff/cohesion-form-fields.md

@@ -0,0 +1,110 @@
+---
+title: 폼의 응집도 생각하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/form-fields.html
+fetched: 2026-05-18
+principle: cohesion
+---
+
+# 폼의 응집도 생각하기
+
+프론트엔드 개발을 하다 보면 Form으로 사용자에게 값을 입력받아야 하는 경우가 많아요.
+Form을 관리할 때는 2가지의 방법으로 응집도를 관리해서, 함께 수정되어야 할 코드가 함께 수정되도록 할 수 있어요.
+
+## 필드 단위 응집도
+
+필드 단위 응집은 개별 입력 요소를 독립적으로 관리하는 방식이에요.
+각 필드가 고유의 검증 로직을 가지므로 변경이 필요한 범위가 줄어들어 특정 필드의 유지보수가 쉬워져요.
+
+```tsx
+import { useForm } from "react-hook-form";
+
+export function Form() {
+  const { register, formState: { errors }, handleSubmit } = useForm({
+    defaultValues: { name: "", email: "" }
+  });
+
+  return (
+    <form onSubmit={handleSubmit(console.log)}>
+      <div>
+        <input
+          {...register("name", {
+            validate: (value) =>
+              isEmptyStringOrNil(value) ? "이름을 입력해주세요." : ""
+          })}
+          placeholder="이름"
+        />
+        {errors.name && <p>{errors.name.message}</p>}
+      </div>
+
+      <div>
+        <input
+          {...register("email", {
+            validate: (value) => {
+              if (isEmptyStringOrNil(value)) return "이메일을 입력해주세요.";
+              if (!/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$/i.test(value))
+                return "유효한 이메일 주소를 입력해주세요.";
+              return "";
+            }
+          })}
+          placeholder="이메일"
+        />
+        {errors.email && <p>{errors.email.message}</p>}
+      </div>
+
+      <button type="submit">제출</button>
+    </form>
+  );
+}
+```
+
+## 폼 전체 단위 응집도
+
+폼 전체 응집은 모든 필드의 검증 로직이 폼에 종속되는 방식이에요.
+
+```tsx
+import * as z from "zod";
+import { useForm } from "react-hook-form";
+import { zodResolver } from "@hookform/resolvers/zod";
+
+const schema = z.object({
+  name: z.string().min(1, "이름을 입력해주세요."),
+  email: z
+    .string()
+    .min(1, "이메일을 입력해주세요.")
+    .email("유효한 이메일 주소를 입력해주세요.")
+});
+
+export function Form() {
+  const { register, formState: { errors }, handleSubmit } = useForm({
+    defaultValues: { name: "", email: "" },
+    resolver: zodResolver(schema)
+  });
+
+  return (
+    <form onSubmit={handleSubmit(console.log)}>
+      <div>
+        <input {...register("name")} placeholder="이름" />
+        {errors.name && <p>{errors.name.message}</p>}
+      </div>
+      <div>
+        <input {...register("email")} placeholder="이메일" />
+        {errors.email && <p>{errors.email.message}</p>}
+      </div>
+      <button type="submit">제출</button>
+    </form>
+  );
+}
+```
+
+## 필드 단위 vs. 폼 전체 단위 응집도
+
+### 필드 단위 응집도를 선택하면 좋을 때
+
+- **독립적인 검증이 필요할 때**: 이메일 형식 검사, 아이디 중복 확인, 추천 코드 유효성 확인처럼 각 필드가 독립적이고 고유한 검증이 필요할 때
+- **재사용이 필요할 때**: 필드와 검증 로직이 다른 폼에서도 동일하게 사용될 수 있는 경우
+
+### 폼 전체 단위 응집도를 선택하면 좋을 때
+
+- **단일 기능을 나타낼 때**: 결제 정보나 배송 정보처럼 모든 필드가 하나의 비즈니스 로직을 이룰 때
+- **단계별 입력이 필요할 때**: Wizard Form과 같이 스텝별로 동작하는 복잡한 폼
+- **필드 간 의존성이 있을 때**: 비밀번호 확인이나 총액 계산처럼 필드 간 상호작용이 필요할 때

package/assets/dev-guide/fe/sources/toss-ff/cohesion-magic-number.md

@@ -0,0 +1,47 @@
+---
+title: 매직 넘버 없애기
+source: https://frontend-fundamentals.com/code-quality/code/examples/magic-number-cohesion.html
+fetched: 2026-05-18
+principle: cohesion
+---
+
+# 매직 넘버 없애기
+
+**매직 넘버**(Magic Number)란 정확한 뜻을 밝히지 않고 소스 코드 안에 직접 숫자 값을 넣는 것을 말해요.
+
+## 📝 코드 예시
+
+다음 코드는 좋아요 버튼을 눌렀을 때 좋아요 개수를 새로 내려받는 함수예요.
+
+```typescript
+async function onLikeClick() {
+  await postLike(url);
+  await delay(300);
+  await refetchPostLike();
+}
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 응집도
+
+`300`이라고 하는 숫자를 애니메이션 완료를 기다리려고 사용했다면, 재생하는 애니메이션을 바꿨을 때 조용히 서비스가 깨질 수 있는 위험성이 있어요.
+충분한 시간동안 애니메이션을 기다리지 않고 바로 다음 로직이 시작될 수도 있죠.
+
+같이 수정되어야 할 코드 중 한쪽만 수정된다는 점에서, 응집도가 낮은 코드라고도 할 수 있어요.
+
+## ✏️ 개선해보기
+
+숫자 `300`의 맥락을 정확하게 표시하기 위해서 상수 `ANIMATION_DELAY_MS`로 선언할 수 있어요.
+
+```typescript
+const ANIMATION_DELAY_MS = 300;
+
+async function onLikeClick() {
+  await postLike(url);
+  await delay(ANIMATION_DELAY_MS);
+  await refetchPostLike();
+}
+```
+
+이렇게 하면 애니메이션 지속 시간이 변경될 때, 상수 하나만 수정하면 관련된 모든 곳이 함께 수정돼요.

package/assets/dev-guide/fe/sources/toss-ff/coupling-item-edit-modal.md

@@ -0,0 +1,124 @@
+---
+title: Props Drilling 지우기
+source: https://frontend-fundamentals.com/code-quality/code/examples/item-edit-modal.html
+fetched: 2026-05-18
+principle: coupling
+---
+
+# Props Drilling 지우기
+
+Props Drilling은 부모 컴포넌트와 자식 컴포넌트 사이에 결합도가 생겼다는 것을 나타내는 명확한 표시예요.
+만약에 Drilling되는 `name` prop의 이름이 `firstName`으로 변경되면, 해당 prop을 참조하는 모든 컴포넌트를 수정해야 해요.
+
+## 📝 코드 예시
+
+다음 코드는 사용자가 `item`을 선택할 때 사용하는 `<ItemEditModal />` 컴포넌트예요.
+
+```tsx
+function ItemEditModal({ open, items, recommendedItems, onConfirm, onClose }) {
+  const [keyword, setKeyword] = useState("");
+
+  return (
+    <Modal open={open} onClose={onClose}>
+      <ItemEditBody
+        items={items}
+        keyword={keyword}
+        onKeywordChange={setKeyword}
+        recommendedItems={recommendedItems}
+        onConfirm={onConfirm}
+        onClose={onClose}
+      />
+    </Modal>
+  );
+}
+
+function ItemEditBody({
+  keyword, onKeywordChange, items, recommendedItems, onConfirm, onClose
+}) {
+  return (
+    <>
+      <div style={{ display: "flex", justifyContent: "space-between" }}>
+        <Input value={keyword} onChange={(e) => onKeywordChange(e.target.value)} />
+        <Button onClick={onClose}>닫기</Button>
+      </div>
+      <ItemEditList
+        keyword={keyword}
+        items={items}
+        recommendedItems={recommendedItems}
+        onConfirm={onConfirm}
+      />
+    </>
+  );
+}
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 결합도
+
+이 컴포넌트는 부모인 `ItemEditModal`과 자식인 `ItemEditBody`, `ItemEditList` 등이 동일한 값인 `recommendedItems`, `onConfirm`, `keyword` 등을 prop으로 공유하고 있어요.
+
+Props Drilling이 발생하면, prop을 불필요하게 참조하는 컴포넌트의 숫자가 많아져요.
+그런데 prop이 변경되면 prop을 참조하는 모든 컴포넌트가 수정되어야 해요.
+
+## ✏️ 개선해보기
+
+### A. 조합(Composition) 패턴 활용
+
+```tsx
+function ItemEditModal({ open, items, recommendedItems, onConfirm, onClose }) {
+  const [keyword, setKeyword] = useState("");
+
+  return (
+    <Modal open={open} onClose={onClose}>
+      <ItemEditBody
+        keyword={keyword}
+        onKeywordChange={setKeyword}
+        onClose={onClose}
+      >
+        <ItemEditList
+          keyword={keyword}
+          items={items}
+          recommendedItems={recommendedItems}
+          onConfirm={onConfirm}
+        />
+      </ItemEditBody>
+    </Modal>
+  );
+}
+
+function ItemEditBody({ children, keyword, onKeywordChange, onClose }) {
+  return (
+    <>
+      <div style={{ display: "flex", justifyContent: "space-between" }}>
+        <Input value={keyword} onChange={(e) => onKeywordChange(e.target.value)} />
+        <Button onClick={onClose}>닫기</Button>
+      </div>
+      {children}
+    </>
+  );
+}
+```
+
+### B. ContextAPI 활용
+
+```tsx
+function ItemEditModal({ open, onConfirm, onClose }) {
+  const [keyword, setKeyword] = useState("");
+
+  return (
+    <Modal open={open} onClose={onClose}>
+      <ItemEditBody keyword={keyword} onKeywordChange={setKeyword} onClose={onClose}>
+        <ItemEditList keyword={keyword} onConfirm={onConfirm} />
+      </ItemEditBody>
+    </Modal>
+  );
+}
+
+function ItemEditList({ keyword, onConfirm }) {
+  const { items, recommendedItems } = useItemEditModalContext();
+  // ...
+}
+```
+
+ContextAPI를 사용하면 매우 쉽게 Props Drilling을 해결할 수 있지만, Props Drilling이 되는 모든 값을 ContextAPI로 관리해야 하는 것은 아니에요. `children` prop을 이용해서 컴포넌트를 전달해 depth를 줄이는 것을 먼저 고려하세요.

package/assets/dev-guide/fe/sources/toss-ff/coupling-use-bottom-sheet.md

@@ -0,0 +1,57 @@
+---
+title: 중복 코드 허용하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/use-bottom-sheet.html
+fetched: 2026-05-18
+principle: coupling
+---
+
+# 중복 코드 허용하기
+
+개발자로서 여러 페이지나 컴포넌트에 걸친 중복 코드를 하나의 Hook이나 컴포넌트로 공통화하는 경우가 많아요.
+중복 코드를 하나의 컴포넌트나 Hook으로 공통화하면, 좋은 코드의 특징 중 하나인 응집도를 챙겨서, 함께 수정되어야 할 코드들을 한꺼번에 수정할 수 있어요.
+
+그렇지만, 불필요한 결합도가 생겨서, 공통 컴포넌트나 Hook을 수정함에 따라 영향을 받는 코드의 범위가 넓어져서, 오히려 수정이 어려워질 수도 있어요.
+
+## 📝 코드 예시
+
+아래와 같이 점검 정보를 인자로 받아서, 점검 중이라면 점검 바텀시트를 열고, 사용자가 알림 받기에 동의하면 이를 로깅하고, 현재 화면을 닫는 Hook을 살펴볼게요.
+
+```typescript
+export const useOpenMaintenanceBottomSheet = () => {
+  const maintenanceBottomSheet = useMaintenanceBottomSheet();
+  const logger = useLogger();
+
+  return async (maintainingInfo: TelecomMaintenanceInfo) => {
+    logger.log("점검 바텀시트 열림");
+    const result = await maintenanceBottomSheet.open(maintainingInfo);
+    if (result) {
+      logger.log("점검 바텀시트 알림받기 클릭");
+    }
+    closeView();
+  };
+};
+```
+
+이 코드는 여러 페이지에서 반복적으로 사용되었기에 공통 Hook으로 분리되었어요.
+
+## 👃 코드 냄새 맡아보기
+
+### 결합도
+
+이 Hook은 여러 페이지에서 반복적으로 보이는 로직이기에 공통화되었어요. 그렇지만 앞으로 생길 수 있는 다양한 코드 변경의 가능성을 생각해볼 수 있어요.
+
+- 만약에 페이지마다 로깅하는 값이 달라진다면?
+- 만약에 어떤 페이지에서는 점검 바텀시트를 닫더라도 화면을 닫을 필요가 없다면?
+- 바텀시트에서 보여지는 텍스트나 이미지를 다르게 해야 한다면?
+
+위 Hook은 이런 코드 변경사항에 유연하게 대응하기 위해서 복잡하게 인자를 받아야 할 거예요.
+이 Hook의 구현을 수정할 때마다, 이 Hook을 쓰는 모든 페이지들이 잘 작동하는지 테스트도 해야 할 것이고요.
+
+## ✏️ 개선해보기
+
+다소 반복되어 보이는 코드일지 몰라도, 중복 코드를 허용하는 것이 좋은 방향일 수 있어요.
+
+함께 일하는 동료들과 적극적으로 소통하며 점검 바텀시트의 동작을 정확하게 이해해야 해요.
+페이지에서 로깅하는 값이 같고, 점검 바텀시트의 동작이 동일하고, 바텀시트의 모양이 동일하다면, 그리고 앞으로도 그럴 예정이라면, 공통화를 통해 코드의 응집도를 높일 수 있어요.
+
+그렇지만 페이지마다 동작이 달라질 여지가 있다면, 공통화 없이 중복 코드를 허용하는 것이 더 좋은 선택이에요.