파일이 너무 무겁다
블로그의 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)”가 한눈에 들어온다. 스크롤을 내릴 필요도 변수 선언부를 헤집고 다닐 필요도 없어졌다.
숫자로 보는 성과
단순히 줄 수만 줄어든 게 아니다. “인지 부하(Cognitive Load)”가 줄어들었다. 개발자가 코드를 읽을 때 뇌를 덜 써도 된다는 뜻이다.
왜 분리해야 하는가? (The Logic)
이 작업(Refactoring)을 통해 얻은 이점은 명확하다.
1. 관심사의 분리 (Separation of Concerns):
.astro 파일은 **“보여주는 방법”**에만 집중한다.
.ts 파일은 **“보여줄 내용”**만 관리한다.
2. 재사용성 (Reusability):
만약 다른 페이지에서 똑같은 장비 목록이 필요하다면? 예전엔 코드를 복사해야 했지만 이젠 import 한 줄이면 된다.
3. 확장성 (Scalability):
나중에 장비가 100개로 늘어나도 화면 코드는 복잡해지지 않는다. 데이터 파일만 수정하면 된다.
“코드를 지우는 것만큼 짜릿한 코딩은 없다.” 오늘의 리팩토링이 증명해 준 사실이다.