맞아. 저런 추상화 레이어들이 처음부터 다 있었던 건 아니고 긴 시간 동안 좋은 추상화가 쌓이면서 점진적으로 진화한거지. 좋은 추상화가 쌓여야 결국 그게 쌓여서 라이브러리가 되고, 프레임워크가 되는 건데 우리는 추상화를 잘 못하기 때문에 아무리 오랫동안 노동을 해도 합성, 조합 가능한 블럭을 못만들고 -> 그렇기 때문에 복잡한 제품이나 기능을 만들 수 없는거야. 복잡도를 통제하지 못하기 때문에.
react 프론트엔드 서비스 개발자로서 고민되는 건. 저런 건 플랫폼 레벨에서만 가능한거 아닌가? 우리 맨날 빠르게 만드는 제품에서 저런 추상화는 좀 동떨어진 이야기가 아닌가? 라는 생각이 들 수 있다는 점이야. 도메인 독립적인 기능 관련 컴포넌트나 라이브러리. 예를 들어서 디자인 시스템 같은 것들. 그럼 디자인 시스템을 안쓰면 추상화가 필요 없나? 그런건 아니지. 프론트엔드에서 주로 다루는 복잡도를 낮추는 방법에도 이런 관점을 적용해서 점차 좋은 추상화를 쌓아야 한다는 이야기를 하고 싶은데 어떻게 하면 지금까지 대화 나누고 있는 맥락 상에서 잘 살려서 설득력을 높일 수 있을까?
서비스 개발에서의 "일상적 추상화"
"빠르게 만드는 제품"에서도 우리는 매일 추상화를 하고 있습니다. 다만 의식적으로 하지 않을 뿐이죠.
우리가 이미 하고 있는 추상화
// 나쁜 추상화: 복붙의 연속
function ProductCard({ product }) {
return (
<div>
<img src={product.image} />
<h3>{product.name}</h3>
<p>{product.price.toLocaleString()}원</p>
{product.discount && <span>{product.discount}% 할인</span>}
</div>
);
}
function CartItem({ item }) {
return (
<div>
<img src={item.product.image} />
<h3>{item.product.name}</h3>
<p>{item.product.price.toLocaleString()}원</p>
{item.product.discount && <span>{item.product.discount}% 할인</span>}
</div>
);
}
// 좋은 추상화: 재사용 가능한 블록
function PriceDisplay({ price, discount }) {
// 가격 표시라는 "복잡도"를 한 곳에 격리
return (
<>
<p>{price.toLocaleString()}원</p>
{discount && <span>{discount}% 할인</span>}
</>
);
}
JavaScript
복사
이 PriceDisplay가 바로 마이크로 추상화입니다. HTTP만큼 거창하지 않아도, 이런 작은 추상화가 쌓여야 복잡한 제품을 만들 수 있습니다.
서비스 개발의 실제 복잡도
// 검색 필터 - 매번 다시 짜는 지옥
function ProductSearch() {
const [query, setQuery] = useState('');
const [category, setCategory] = useState('');
const [priceRange, setPriceRange] = useState([0, 100000]);
const [sort, setSort] = useState('relevance');
useEffect(() => {
// 필터 변경시마다 API 호출
}, [query, category, priceRange, sort]);
// 200줄의 JSX...
}
// 이걸 3개월 후 다른 페이지에서 또 만들고 있음
function UserSearch() {
// 비슷한 200줄...
}
JavaScript
복사
왜 이렇게 될까? 첫 번째 만들 때 추상화를 안 했기 때문입니다.
점진적 추상화 쌓기
// Step 1: 검색 로직 추출 (첫 번째 프로젝트)
function useSearch(endpoint) {
const [filters, setFilters] = useState({});
const { data, refetch } = useQuery([endpoint, filters]);
return { data, setFilter: (key, value) => {
setFilters(prev => ({ ...prev, [key]: value }));
}};
}
// Step 2: 필터 UI 패턴 발견 (두 번째 프로젝트)
function FilterPanel({ filters, onChange }) {
return filters.map(filter => (
<FilterItem key={filter.key} {...filter} onChange={onChange} />
));
}
// Step 3: 조합 가능한 블록 완성 (세 번째 프로젝트)
function SearchPage({ config }) {
const search = useSearch(config.endpoint);
return (
<>
<FilterPanel filters={config.filters} onChange={search.setFilter} />
<ResultList data={search.data} />
</>
);
}
// 이제 새 검색 페이지는 설정만으로
const productSearchConfig = {
endpoint: '/api/products',
filters: [
{ key: 'category', type: 'select', options: [...] },
{ key: 'price', type: 'range', min: 0, max: 100000 }
]
};
JavaScript
복사
왜 서비스 개발자에게 추상화가 더 중요한가
1. 반복 작업이 많기 때문
// 얼마나 많은 폼을 만들었나?
// 얼마나 많은 리스트를 만들었나?
// 얼마나 많은 모달을 만들었나?
// 좋은 추상화가 있었다면
<Form schema={userSchema} onSubmit={handleSubmit} />
<DataList config={listConfig} />
<Modal trigger={<Button />} content={<Content />} />
JavaScript
복사
2. 요구사항이 빠르게 변하기 때문
// 추상화 없이: 10개 파일 수정
"모든 가격에 부가세 포함 표시 추가해주세요"
// 추상화 있으면: 1개 컴포넌트만 수정
function PriceDisplay({ price, showVAT = true }) {
const finalPrice = showVAT ? price * 1.1 : price;
// ...
}
JavaScript
복사
3. 팀이 성장하기 때문
// 신입이 와도 이해 가능한 코드
<SearchSection>
<SearchBar />
<FilterPanel />
<ResultGrid />
<Pagination />
</SearchSection>
// vs 500줄짜리 하나의 컴포넌트
JavaScript
복사
실용적 추상화 전략
Phase 1: 인식 (첫 프로젝트)
// "아 이거 또 만드네?"라는 순간 포착
// TODO 주석이라도 남기기
// TODO: 이 로직 다른 곳에서도 쓸 듯
JavaScript
복사
Phase 2: 추출 (두 번째 만날 때)
// 공통 부분만 함수로 추출
function formatPrice(price) { /* ... */ }
function validateEmail(email) { /* ... */ }
JavaScript
복사
Phase 3: 패턴화 (세 번째 만날 때)
// 이제 패턴이 보임
const FormField = { validate, format, parse };
const useFormField = (config) => { /* ... */ };
JavaScript
복사
Phase 4: 라이브러리화 (네 번째부터)
// 팀 내부 라이브러리로
// @team/form-utils
// @team/search-kit
JavaScript
복사
핵심 메시지
"플랫폼 개발자만 추상화하는 게 아니다"
HTTP를 만든 팀 버너스 리도 처음엔 그냥 문서 공유하고 싶었을 뿐입니다. jQuery도 존 레식이 DOM 조작 반복하기 싫어서 만들었고요.
우리가 매일 하는 서비스 개발에서:
•
반복되는 패턴을 발견하고
•
작은 추상화로 감싸고
•
점진적으로 개선하면
그게 쌓여서 팀의 자산이 되고, 더 복잡한 제품을 더 빠르게 만들 수 있게 됩니다.
"시간이 없어서 추상화 못 해"가 아니라 "추상화 안 해서 시간이 없는" 겁니다.