@wooojin/forgen 0.4.8 → 0.4.9

package/assets/dev-guide/fe/sources/toss-ff/coupling-use-page-state.md

@@ -0,0 +1,71 @@
+---
+title: 책임을 하나씩 관리하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/use-page-state-coupling.html
+fetched: 2026-05-18
+principle: coupling
+---
+
+# 책임을 하나씩 관리하기
+
+쿼리 파라미터, 상태, API 호출과 같은 로직의 종류에 따라서 함수나 컴포넌트, Hook을 나누지 마세요. 한 번에 다루는 맥락의 종류가 많아져서 이해하기 힘들고 수정하기 어려운 코드가 돼요.
+
+## 📝 코드 예시
+
+다음 `usePageState()` Hook은 페이지 전체의 URL 쿼리 파라미터를 한 번에 관리해요.
+
+```typescript
+export function usePageState() {
+  const [query, setQuery] = useQueryParams({
+    cardId: NumberParam,
+    statementId: NumberParam,
+    dateFrom: DateParam,
+    dateTo: DateParam,
+    statusList: ArrayParam
+  });
+
+  return useMemo(
+    () => ({
+      values: {
+        cardId: query.cardId ?? undefined,
+        statementId: query.statementId ?? undefined,
+        dateFrom: query.dateFrom == null ? defaultDateFrom : moment(query.dateFrom),
+        dateTo: query.dateTo == null ? defaultDateTo : moment(query.dateTo),
+        statusList: query.statusList as StatementStatusType[] | undefined
+      },
+      controls: {
+        setCardId: (cardId: number) => setQuery({ cardId }, "replaceIn"),
+        setStatementId: (statementId: number) => setQuery({ statementId }, "replaceIn"),
+        setDateFrom: (date?: Moment) => setQuery({ dateFrom: date?.toDate() }, "replaceIn"),
+        setDateTo: (date?: Moment) => setQuery({ dateTo: date?.toDate() }, "replaceIn"),
+        setStatusList: (statusList?: StatementStatusType[]) => setQuery({ statusList }, "replaceIn")
+      }
+    }),
+    [query, setQuery]
+  );
+}
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 결합도
+
+이 Hook은 "이 페이지에 필요한 모든 쿼리 매개변수를 관리하는 것"이라는 광범위한 책임을 가지고 있어요. 이로 인해 페이지 내의 컴포넌트나 다른 훅들이 이 훅에 의존하게 될 수 있으며, 코드 수정을 할 때 영향 범위가 급격히 확장될 수 있어요.
+
+## ✏️ 개선해보기
+
+다음 코드와 같이 각각의 쿼리 파라미터별로 별도의 Hook을 작성할 수 있어요.
+
+```typescript
+export function useCardIdQueryParam() {
+  const [cardId, _setCardId] = useQueryParam("cardId", NumberParam);
+
+  const setCardId = useCallback((cardId: number) => {
+    _setCardId({ cardId }, "replaceIn");
+  }, []);
+
+  return [cardId ?? undefined, setCardId] as const;
+}
+```
+
+Hook이 담당하는 책임을 분리했기 때문에, 수정에 따른 영향이 갈 범위를 좁힐 수 있어요.
+그래서 Hook을 수정했을 때 예상하지 못한 영향이 생기는 것을 막을 수 있어요.

package/assets/dev-guide/fe/sources/toss-ff/overview-4-principles.md

@@ -0,0 +1,77 @@
+---
+title: 좋은 코드를 위한 4가지 기준
+source: https://frontend-fundamentals.com/code-quality/code/
+fetched: 2026-05-18
+principle: readability|predictability|cohesion|coupling
+---
+
+# 좋은 코드를 위한 4가지 기준
+
+좋은 프론트엔드 코드는 **변경하기 쉬운** 코드예요.
+새로운 요구사항을 구현하고자 할 때, 기존 코드를 수정하고 배포하기 수월한 코드가 좋은 코드죠.
+코드가 변경하기 쉬운지는 4가지 기준으로 판단할 수 있어요.
+
+## 1. 가독성
+
+**가독성**(Readability)은 코드가 읽기 쉬운 정도를 말해요.
+코드가 변경하기 쉬우려면 먼저 코드가 어떤 동작을 하는지 이해할 수 있어야 해요.
+
+읽기 좋은 코드는 읽는 사람이 한 번에 머릿속에서 고려하는 맥락이 적고, 위에서 아래로 자연스럽게 이어져요.
+
+### 가독성을 높이는 전략
+
+- **맥락 줄이기**
+  - 같이 실행되지 않는 코드 분리하기
+  - 구현 상세 추상화하기
+  - 로직 종류에 따라 합쳐진 함수 쪼개기
+- **이름 붙이기**
+  - 복잡한 조건에 이름 붙이기
+  - 매직 넘버에 이름 붙이기
+- **위에서 아래로 읽히게 하기**
+  - 시점 이동 줄이기
+  - 삼항 연산자 단순하게 하기
+
+## 2. 예측 가능성
+
+**예측 가능성**(Predictability)이란, 함께 협업하는 동료들이 함수나 컴포넌트의 동작을 얼마나 예측할 수 있는지를 말해요.
+예측 가능성이 높은 코드는 일관적인 규칙을 따르고, 함수나 컴포넌트의 이름과 파라미터, 반환 값만 보고도 어떤 동작을 하는지 알 수 있어요.
+
+### 예측 가능성을 높이는 전략
+
+- 이름 겹치지 않게 관리하기
+- 같은 종류의 함수는 반환 타입 통일하기
+- 숨은 로직 드러내기
+
+## 3. 응집도
+
+**응집도**(Cohesion)란, 수정되어야 할 코드가 항상 같이 수정되는지를 말해요.
+응집도가 높은 코드는 코드의 한 부분을 수정해도 의도치 않게 다른 부분에서 오류가 발생하지 않아요.
+
+> 가독성과 응집도는 서로 상충할 수 있어요. 일반적으로 응집도를 높이기 위해서는 변수나 함수를 추상화하는 등 가독성을 떨어뜨리는 결정을 해야 해요. 함께 수정되지 않으면 오류가 발생할 수 있는 경우에는, 응집도를 우선해서 코드를 공통화, 추상화하세요. 위험성이 높지 않은 경우에는, 가독성을 우선하여 코드 중복을 허용하세요.
+
+### 응집도를 높이는 전략
+
+- 함께 수정되는 파일을 같은 디렉토리에 두기
+- 매직 넘버 없애기
+- 폼의 응집도 생각하기
+
+## 4. 결합도
+
+**결합도**(Coupling)란, 코드를 수정했을 때의 영향범위를 말해요.
+코드를 수정했을 때 영향범위가 적어서, 변경에 따른 범위를 예측할 수 있는 코드가 수정하기 쉬운 코드예요.
+
+### 결합도를 낮추는 전략
+
+- 책임을 하나씩 관리하기
+- 중복 코드 허용하기
+- Props Drilling 지우기
+
+## 코드 품질 여러 각도로 보기
+
+아쉽게도 이 4가지 기준을 모두 한꺼번에 충족하기는 어려워요.
+
+예를 들어서, 함수나 변수가 항상 같이 수정되기 위해서 공통화 및 추상화하면, 응집도가 높아지죠. 그렇지만 코드가 한 차례 추상화되기 때문에 가독성이 떨어져요.
+
+중복 코드를 허용하면, 코드의 영향범위를 줄일 수 있어서, 결합도를 낮출 수 있어요. 그렇지만 한쪽을 수정했을 때 다른 한쪽을 실수로 수정하지 못할 수 있어서, 응집도가 떨어지죠.
+
+프론트엔드 개발자는 현재 직면한 상황을 바탕으로, 깊이 있게 고민하면서, 장기적으로 코드가 수정하기 쉽게 하기 위해서 어떤 가치를 우선해야 하는지 고민해야 해요.

package/assets/dev-guide/fe/sources/toss-ff/predictability-hidden-logic.md

@@ -0,0 +1,59 @@
+---
+title: 숨은 로직 드러내기
+source: https://frontend-fundamentals.com/code-quality/code/examples/hidden-logic.html
+fetched: 2026-05-18
+principle: predictability
+---
+
+# 숨은 로직 드러내기
+
+함수나 컴포넌트의 이름, 파라미터, 반환 값에 드러나지 않는 숨은 로직이 있다면, 함께 협업하는 동료들이 동작을 예측하는 데에 어려움을 겪을 수 있어요.
+
+## 📝 코드 예시
+
+다음 코드는 사용자의 계좌 잔액을 조회할 때 사용할 수 있는 `fetchBalance` 함수예요. 함수를 호출할 때마다 암시적으로 `balance_fetched`라는 로깅이 이루어지고 있어요.
+
+```typescript
+async function fetchBalance(): Promise<number> {
+  const balance = await http.get<number>("...");
+
+  logging.log("balance_fetched");
+
+  return balance;
+}
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 예측 가능성
+
+`fetchBalance` 함수의 이름과 반환 타입만을 가지고는 `balance_fetched` 라는 로깅이 이루어지는지 알 수 없어요. 그래서 로깅을 원하지 않는 곳에서도 로깅이 이루어질 수 있어요.
+
+또, 로깅 로직에 오류가 발생했을 때 갑자기 계좌 잔액을 가져오는 로직이 망가질 수도 있죠.
+
+## ✏️ 개선해보기
+
+함수의 이름과 파라미터, 반환 타입으로 예측할 수 있는 로직만 구현 부분에 남기세요.
+
+```typescript
+async function fetchBalance(): Promise<number> {
+  const balance = await http.get<number>("...");
+
+  return balance;
+}
+```
+
+로깅을 하는 코드는 별도로 분리하세요.
+
+```tsx
+<Button
+  onClick={async () => {
+    const balance = await fetchBalance();
+    logging.log("balance_fetched");
+
+    await syncBalance(balance);
+  }}
+>
+  계좌 잔액 갱신하기
+</Button>
+```

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

@@ -0,0 +1,77 @@
+---
+title: 이름 겹치지 않게 관리하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/http.html
+fetched: 2026-05-18
+principle: predictability
+---
+
+# 이름 겹치지 않게 관리하기
+
+같은 이름을 가지는 함수나 변수는 동일한 동작을 해야 해요. 작은 동작 차이가 코드의 예측 가능성을 낮추고, 코드를 읽는 사람에게 혼란을 줄 수 있어요.
+
+## 📝 코드 예시
+
+어떤 프론트엔드 서비스에서 원래 사용하던 HTTP 라이브러리를 감싸서 새로운 형태로 HTTP 요청을 보내는 모듈을 만들었어요.
+공교롭게 원래 HTTP 라이브러리와 새로 만든 HTTP 모듈의 이름은 `http`로 같아요.
+
+```typescript
+// http.ts
+import { http as httpLibrary } from "@some-library/http";
+
+export const http = {
+  async get(url: string) {
+    const token = await fetchToken();
+
+    return httpLibrary.get(url, {
+      headers: { Authorization: `Bearer ${token}` }
+    });
+  }
+};
+```
+
+```typescript
+// fetchUser.ts
+import { http } from "./http";
+
+export async function fetchUser() {
+  return http.get("...");
+}
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 예측 가능성
+
+이 코드는 기능적으로 문제가 없지만, 읽는 사람에게 혼란을 줄 수 있어요. `http.get`을 호출하는 개발자는 이 함수가 원래의 HTTP 라이브러리가 하는 것처럼 단순한 GET 요청을 보내는 것으로 예상하지만, 실제로는 토큰을 가져오는 추가 작업이 수행돼요.
+
+오해로 인해서 기대 동작과 실제 동작의 차이가 생기고, 버그가 발생하거나, 디버깅 과정을 복잡하고 혼란스럽게 만들 수 있어요.
+
+## ✏️ 개선해보기
+
+서비스에서 만든 함수에는 라이브러리의 함수명과 구분되는 명확한 이름을 사용해서 함수의 동작을 예측 가능하게 만들 수 있어요.
+
+```typescript
+// httpService.ts
+import { http as httpLibrary } from "@some-library/http";
+
+export const httpService = {
+  async getWithAuth(url: string) {
+    const token = await fetchToken();
+
+    return httpLibrary.get(url, {
+      headers: { Authorization: `Bearer ${token}` }
+    });
+  }
+};
+```
+
+```typescript
+// fetchUser.ts
+import { httpService } from "./httpService";
+
+export async function fetchUser() {
+  return await httpService.getWithAuth("...");
+}
+```
+
+이렇게 해서 함수의 이름을 봤을 때 동작을 오해할 수 있는 가능성을 줄일 수 있어요.

package/assets/dev-guide/fe/sources/toss-ff/predictability-use-user.md

@@ -0,0 +1,110 @@
+---
+title: 같은 종류의 함수는 반환 타입 통일하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/use-user.html
+fetched: 2026-05-18
+principle: predictability
+---
+
+# 같은 종류의 함수는 반환 타입 통일하기
+
+API 호출과 관련된 Hook들처럼 같은 종류의 함수나 Hook이 서로 다른 반환 타입을 가지면 코드의 일관성이 떨어져서, 같이 일하는 동료들이 코드를 읽는 데에 헷갈릴 수 있어요.
+
+## 📝 코드 예시 1: useUser
+
+다음 `useUser` 와 `useServerTime` Hook은 모두 API 호출과 관련된 Hook이에요.
+
+```typescript
+function useUser() {
+  const query = useQuery({
+    queryKey: ["user"],
+    queryFn: fetchUser
+  });
+
+  return query; // Query 객체 반환
+}
+
+function useServerTime() {
+  const query = useQuery({
+    queryKey: ["serverTime"],
+    queryFn: fetchServerTime
+  });
+
+  return query.data; // 데이터만 반환
+}
+```
+
+### 👃 코드 냄새 맡아보기
+
+#### 예측 가능성
+
+서버 API를 호출하는 Hook의 반환 타입이 서로 다르다면, 동료들은 이런 Hook을 쓸 때마다 반환 타입이 무엇인지 확인해야 해요.
+
+같은 종류의 동작을 하는 코드가 일관적인 규칙에 따르고 있지 않으면 코드를 읽고 쓰는 데 헷갈려요.
+
+### ✏️ 개선해보기
+
+서버 API를 호출하는 Hook은 일관적으로 `Query` 객체를 반환하게 하면, 팀원들이 코드에 대한 예측 가능성을 높일 수 있어요.
+
+```typescript
+function useUser() {
+  const query = useQuery({ queryKey: ["user"], queryFn: fetchUser });
+  return query;
+}
+
+function useServerTime() {
+  const query = useQuery({ queryKey: ["serverTime"], queryFn: fetchServerTime });
+  return query; // 이제 Query 객체 반환으로 통일
+}
+```
+
+## 📝 코드 예시 2: checkIsValid
+
+유효성 검사 함수도 동일한 패턴의 안티패턴이 나타나요.
+
+```typescript
+/** 이름 검사: boolean 반환 */
+function checkIsNameValid(name: string) {
+  return name.length > 0 && name.length < 20;
+}
+
+/** 나이 검사: { ok, reason } 객체 반환 */
+function checkIsAgeValid(age: number) {
+  if (!Number.isInteger(age)) {
+    return { ok: false, reason: "나이는 정수여야 해요." };
+  }
+  if (age < 18) {
+    return { ok: false, reason: "나이는 18세 이상이어야 해요." };
+  }
+  if (age > 99) {
+    return { ok: false, reason: "나이는 99세 이하이어야 해요." };
+  }
+  return { ok: true };
+}
+```
+
+### 👃 코드 냄새 맡아보기
+
+#### 예측 가능성
+
+반환 값이 다르면 항상 객체인 `{ ok, ... }`는 truthy라서 `if (checkIsAgeValid(age))` 가 항상 실행되는 버그가 발생할 수 있어요.
+
+### ✏️ 개선해보기
+
+Discriminated Union 타입으로 통일:
+
+```typescript
+type ValidationCheckReturnType = { ok: true } | { ok: false; reason: string };
+
+function checkIsNameValid(name: string): ValidationCheckReturnType {
+  if (name.length === 0) return { ok: false, reason: "이름은 빈 값일 수 없어요." };
+  if (name.length >= 20) return { ok: false, reason: "이름은 20자 이상 입력할 수 없어요." };
+  return { ok: true };
+}
+
+function checkIsAgeValid(age: number): ValidationCheckReturnType {
+  if (!Number.isInteger(age)) return { ok: false, reason: "나이는 정수여야 해요." };
+  if (age < 18) return { ok: false, reason: "나이는 18세 이상이어야 해요." };
+  if (age > 99) return { ok: false, reason: "나이는 99세 이하이어야 해요." };
+  return { ok: true };
+}
+```

package/assets/dev-guide/fe/sources/toss-ff/readability-comparison-order.md

@@ -0,0 +1,52 @@
+---
+title: 왼쪽에서 오른쪽으로 읽히게 하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/comparison-order.html
+fetched: 2026-05-18
+principle: readability
+---
+
+# 왼쪽에서 오른쪽으로 읽히게 하기
+
+범위를 확인하는 조건문에서 부등호의 순서가 자연스럽지 않으면, 코드를 읽는 사람이 조건의 의도를 파악하는 데 시간이 더 걸려요.
+
+## 📝 코드 예시
+
+다음 코드들은 값이 특정 범위 안에 있는지 확인하는 조건문이에요.
+
+```typescript
+if (a >= b && a <= c) { ... }
+
+if (score >= 80 && score <= 100) {
+  console.log("우수");
+}
+
+if (price >= minPrice && price <= maxPrice) {
+  console.log("적정 가격");
+}
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 가독성
+
+이 코드들은 논리적으로는 올바르지만, 읽을 때 자연스럽지 않아요. `a >= b && a <= c`처럼 작성하면 중간값인 `a`를 두 번 확인해야 해서, 코드를 읽는 사람이 조건을 이해하기 위해 더 많은 인지적 부담을 느껴요.
+
+수학에서 범위를 표현할 때처럼 `b ≤ a ≤ c` 형태로 왼쪽에서 오른쪽으로 자연스럽게 읽히면 더 직관적이에요.
+
+## ✏️ 개선해보기
+
+다음과 같이 범위의 시작점부터 끝점까지 왼쪽에서 오른쪽으로 읽히는 순서로 조건을 작성하면, 코드를 읽는 사람이 범위를 한눈에 파악할 수 있어요.
+
+```typescript
+if (b <= a && a <= c) { ... }
+
+if (80 <= score && score <= 100) {
+  console.log("우수");
+}
+
+if (minPrice <= price && price <= maxPrice) {
+  console.log("적정 가격");
+}
+```
+
+이렇게 작성하면 `80 ≤ score ≤ 100`, `minPrice ≤ price ≤ maxPrice`처럼 수학의 부등식과 같은 형태로 읽혀서, 코드를 읽는 사람이 범위 조건을 직관적으로 이해할 수 있어요.

package/assets/dev-guide/fe/sources/toss-ff/readability-condition-name.md

@@ -0,0 +1,64 @@
+---
+title: 복잡한 조건에 이름 붙이기
+source: https://frontend-fundamentals.com/code-quality/code/examples/condition-name.html
+fetched: 2026-05-18
+principle: readability
+---
+
+# 복잡한 조건에 이름 붙이기
+
+복잡한 조건식이 특별한 이름 없이 사용되면, 조건이 뜻하는 바를 한눈에 파악하기 어려워요.
+
+## 📝 코드 예시
+
+다음 코드는 상품 중에서 카테고리와 가격 범위가 일치하는 상품만 필터링하는 로직이에요.
+
+```typescript
+const result = products.filter((product) =>
+  product.categories.some(
+    (category) =>
+      category.id === targetCategory.id &&
+      product.prices.some((price) => price >= minPrice && price <= maxPrice)
+  )
+);
+```
+
+## 👃 코드 냄새 맡아보기
+
+### 가독성
+
+이 코드에서는 익명 함수와 조건이 복잡하게 얽혀 있어요. `filter`와 `some`, `&&` 같은 로직이 여러 단계로 중첩되어 있어서 정확한 조건을 파악하기 어려워졌어요.
+
+코드를 읽는 사람이 한 번에 고려해야 하는 맥락이 많아서, 가독성이 떨어져요.
+
+## ✏️ 개선해보기
+
+다음 코드와 같이 조건에 명시적인 이름을 붙이면, 코드를 읽는 사람이 한 번에 고려해야 할 맥락을 줄일 수 있어요.
+
+```typescript
+const matchedProducts = products.filter((product) => {
+  return product.categories.some((category) => {
+    const isSameCategory = category.id === targetCategory.id;
+    const isPriceInRange = product.prices.some(
+      (price) => price >= minPrice && price <= maxPrice
+    );
+
+    return isSameCategory && isPriceInRange;
+  });
+});
+```
+
+명시적으로 같은 카테고리 안에 속해 있고, 가격 범위가 맞는 제품들로 필터링한다고 작성함으로써, 복잡한 조건식을 따라가지 않고도 코드의 의도를 명확히 드러낼 수 있어요.
+
+## 🔍 더 알아보기: 조건식에 이름을 붙이는 기준
+
+### 조건에 이름을 붙이는 것이 좋을 때
+
+- **복잡한 로직을 다룰 때**: 조건문이나 함수에서 복잡한 로직이 여러 줄에 걸쳐 처리되면, 이름을 붙여 함수의 역할을 명확히 드러내는 것이 좋아요.
+- **재사용성이 필요할 때**: 동일한 로직을 여러 곳에서 반복적으로 사용할 가능성이 있으면, 변수나 함수를 선언해 재사용할 수 있어요.
+- **단위 테스트가 필요할 때**: 함수를 분리하면 독립적으로 단위 테스트를 작성할 수 있어요.
+
+### 조건에 이름을 붙이지 않아도 괜찮을 때
+
+- **로직이 간단할 때**: 로직이 매우 간단하면, 굳이 이름을 붙이지 않아도 돼요. 예를 들어, `arr.map(x => x * 2)`와 같은 코드는 이름을 붙이지 않아도 직관적이에요.
+- **한 번만 사용될 때**: 특정 로직이 코드 내에서 한 번만 사용되며, 그 로직이 복잡하지 않으면 익명 함수에서 직접 로직을 처리하는 것이 더 직관적일 수 있어요.

package/assets/dev-guide/fe/sources/toss-ff/readability-login-start-page.md

@@ -0,0 +1,183 @@
+---
+title: 구현 상세 추상화하기
+source: https://frontend-fundamentals.com/code-quality/code/examples/login-start-page.html
+fetched: 2026-05-18
+principle: readability
+---
+
+# 구현 상세 추상화하기
+
+한 사람이 코드를 읽을 때 동시에 고려할 수 있는 총 맥락의 숫자는 제한되어 있다고 해요.
+내 코드를 읽는 사람들이 코드를 쉽게 읽을 수 있도록 하기 위해서 불필요한 맥락을 추상화할 수 있어요.
+
+## 📝 코드 예시 1: LoginStartPage
+
+다음 `<LoginStartPage />` 컴포넌트는 사용자가 로그인되었는지 확인하고, 로그인이 된 경우 홈으로 이동시키는 로직을 가지고 있어요.
+
+```tsx
+function LoginStartPage() {
+  useCheckLogin({
+    onChecked: (status) => {
+      if (status === "LOGGED_IN") {
+        location.href = "/home";
+      }
+    }
+  });
+
+  /* ... 로그인 관련 로직 ... */
+
+  return <>{/* ... 로그인 관련 컴포넌트 ... */}</>;
+}
+```
+
+### 👃 코드 냄새 맡아보기
+
+#### 가독성
+
+예시 코드에서는 로그인이 되었는지 확인하고, 사용자를 홈으로 이동시키는 로직이 추상화 없이 노출되어 있어요. 그래서 `useCheckLogin`, `onChecked`, `status`, `"LOGGED_IN"`과 같은 변수나 값을 모두 읽어야 무슨 역할을 하는 코드인지 알 수 있어요.
+
+### ✏️ 개선해보기
+
+사용자가 로그인되었는지 확인하고 이동하는 로직을 **HOC(Higher-Order Component)** 나 Wrapper 컴포넌트로 분리하여, 코드를 읽는 사람이 한 번에 알아야 하는 맥락을 줄여요.
+
+#### 옵션 A: Wrapper 컴포넌트 사용하기
+
+```tsx
+function App() {
+  return (
+    <AuthGuard>
+      <LoginStartPage />
+    </AuthGuard>
+  );
+}
+
+function AuthGuard({ children }) {
+  const status = useCheckLoginStatus();
+
+  useEffect(() => {
+    if (status === "LOGGED_IN") {
+      location.href = "/home";
+    }
+  }, [status]);
+
+  return status !== "LOGGED_IN" ? children : null;
+}
+
+function LoginStartPage() {
+  /* ... 로그인 관련 로직 ... */
+
+  return <>{/* ... 로그인 관련 컴포넌트 ... */}</>;
+}
+```
+
+#### 옵션 B: HOC(Higher-Order Component) 사용하기
+
+```tsx
+function LoginStartPage() {
+  /* ... 로그인 관련 로직 ... */
+
+  return <>{/* ... 로그인 관련 컴포넌트 ... */}</>;
+}
+
+export default withAuthGuard(LoginStartPage);
+
+function withAuthGuard(WrappedComponent) {
+  return function AuthGuard(props) {
+    const status = useCheckLoginStatus();
+
+    useEffect(() => {
+      if (status === "LOGGED_IN") {
+        location.href = "/home";
+      }
+    }, [status]);
+
+    return status !== "LOGGED_IN" ? <WrappedComponent {...props} /> : null;
+  };
+}
+```
+
+## 📝 코드 예시 2: FriendInvitation
+
+다음 `<FriendInvitation />` 컴포넌트는 클릭하면 사용자에게 동의를 받고 사용자에게 초대를 보내는 페이지 컴포넌트예요.
+
+```tsx
+function FriendInvitation() {
+  const { data } = useQuery(/* 생략.. */);
+
+  const handleClick = async () => {
+    const canInvite = await overlay.openAsync(({ isOpen, close }) => (
+      <ConfirmDialog
+        title={`${data.name}님에게 공유해요`}
+        cancelButton={
+          <ConfirmDialog.CancelButton onClick={() => close(false)}>
+            닫기
+          </ConfirmDialog.CancelButton>
+        }
+        confirmButton={
+          <ConfirmDialog.ConfirmButton onClick={() => close(true)}>
+            확인
+          </ConfirmDialog.ConfirmButton>
+        }
+      />
+    ));
+
+    if (canInvite) {
+      await sendPush();
+    }
+  };
+
+  return (
+    <>
+      <Button onClick={handleClick}>초대하기</Button>
+      {/* UI를 위한 JSX 마크업... */}
+    </>
+  );
+}
+```
+
+### ✏️ 개선해보기
+
+사용자에게 동의를 받는 로직과 버튼을 `<InviteButton />` 컴포넌트로 추상화했어요.
+
+```tsx
+export function FriendInvitation() {
+  const { data } = useQuery(/* 생략.. */);
+
+  return (
+    <>
+      <InviteButton name={data.name} />
+      {/* UI를 위한 JSX 마크업 */}
+    </>
+  );
+}
+
+function InviteButton({ name }) {
+  return (
+    <Button
+      onClick={async () => {
+        const canInvite = await overlay.openAsync(({ isOpen, close }) => (
+          <ConfirmDialog
+            title={`${name}님에게 공유해요`}
+            cancelButton={
+              <ConfirmDialog.CancelButton onClick={() => close(false)}>
+                닫기
+              </ConfirmDialog.CancelButton>
+            }
+            confirmButton={
+              <ConfirmDialog.ConfirmButton onClick={() => close(true)}>
+                확인
+              </ConfirmDialog.ConfirmButton>
+            }
+          />
+        ));
+
+        if (canInvite) {
+          await sendPush();
+        }
+      }}
+    >
+      초대하기
+    </Button>
+  );
+}
+```