파일이 너무 무겁다

블로그의 Kitchen (설계도) 페이지와 Ingredients (도구) 페이지를 만들면서 문득 위화감을 느꼈다. 화면을 그리는 HTML 코드를 수정하려고 파일을 열었는데, 정작 내 눈앞을 가로막은 건 수십 줄에 달하는 데이터 배열(const data = [...])이었다.

// src/pages/ingredients.astro (수정 전)

const myIngredients = [
  {
    category: "Hardware",
    description: "...",
    items: [
      { name: "Galaxy Book4 Edge", ... },
      { name: "Desktop", ... },
      // ... (이런 게 100줄 가까이 이어짐)
    ]
  }
];

이건 마치 요리(View)를 하려는데, 주방 조리대 위에 식재료 박스(Data)가 산더미처럼 쌓여서 도마가 안 보이는 상황과 같았다.

---

1단계: 데이터 이사 보내기 (src/data)

나는 결단을 내렸다. “데이터는 데이터 창고로 보내자.” src/data/ingredients.ts라는 별도 파일을 만들고 .astro 파일 안을 차지하고 있던 거대한 배열을 그대로 잘라내어 옮겼다.

이 과정에서 TypeScript의 인터페이스도 함께 옮겨서, 데이터의 구조가 단단하게 고정되도록 만들었다.

2단계: 다이어트 결과 (Import의 마법)

데이터를 옮기고 난 뒤, 원래 파일인 ingredients.astro는 어떻게 변했을까? 100줄 가까이 되던 코드가 단 한 줄로 바뀌었다.

// src/pages/ingredients.astro (수정 후)

import { myIngredients } from '../data/ingredients';

이제 파일을 열면 데이터의 장벽 없이 “이 페이지가 어떻게 생겼는지(Layout)“가 한눈에 들어온다. 스크롤을 내릴 필요도 변수 선언부를 헤집고 다닐 필요도 없어졌다.

숫자로 보는 성과

Ingredients 페이지: 약 100줄 감소

Main(Index) 페이지: 약 30줄 감소

단순히 줄 수만 줄어든 게 아니다. “인지 부하(Cognitive Load)“가 줄어들었다. 개발자가 코드를 읽을 때 뇌를 덜 써도 된다는 뜻이다.

---

왜 분리해야 하는가? (The Logic)

이 작업(Refactoring)을 통해 얻은 이점은 명확하다.

1. 관심사의 분리 (Separation of Concerns):

.astro 파일은 **“보여주는 방법”**에만 집중한다.
.ts 파일은 **“보여줄 내용”**만 관리한다.

2. 재사용성 (Reusability):

만약 다른 페이지에서 똑같은 장비 목록이 필요하다면? 예전엔 코드를 복사해야 했지만 이젠 import 한 줄이면 된다.

3. 확장성 (Scalability):

나중에 장비가 100개로 늘어나도 화면 코드는 복잡해지지 않는다. 데이터 파일만 수정하면 된다.

“코드를 지우는 것만큼 짜릿한 코딩은 없다.” 오늘의 리팩토링이 증명해 준 사실이다.