React와 Vue를 함께 쓰다 보면 두 프레임워크 모두 지정된 포맷팅이 너무 다르기도 하고, 추상화 방식도 생각보다 달라서 Vue 를 쓰다가 React 를 사용하게 되면 혼동되는 경우가 많이 생긴다. 예전에 풀던 과제들도 다시 풀면 롤백되어 탈락하기도 하고.. React 를 Vue 의 template 문법처럼 사용하는 경우도 많아서, 천천히 돌아볼겸 두 프레임워크를 동시에 사용하는 사람들을 위해 다시 한번 정리를 하고자한다.
사실 두 프레임워크의 차이를 명확하게 알고있으면 되긴 하지만, React 에서는 한 파일에서 여러 모듈들을 임포트할 수 있고, Vue 의 경우에는 SFC (Single File Component) 이기 때문에 단 하나의 모듈만 임포트할 수 있다. 사실 자바스크립트라는 교집합이 존재하지만 이 과정에서 두 프레임워크의 차이를 명확하게 알고 있고, 어떤 방식에서 차이점을 가지고 있는지 알아야 프레임워크에서 추구하는 추상화가 가능하다는 생각이 들었다.
인터넷에서 여러 문서들을 참고하고, 또 여러 과제들을 진행하면서 느꼈던 부분들을 적은 내용들이라 아마 개발자들마다 코드에 대해 생각하는 부분들이 다를 수 있겠지만 여러 문서들을 읽으며 동의했던 부분들과 내가 생각한 좋은 코드에 대한 기준을 적은 문서이니 지나가시는 분들은 가볍게 보시면 좋을 것 같다 ^,^ ..
React — 좋은 코드를 작성하는 방법
코드는 예측 가능해야 한다
좋은 코드의 기준은 하나라고 생각한다. 다음 줄이 어떻게 생겼을지 읽기 전에 예측할 수 있어야 한다. 이름, 구조, 인터페이스가 일관된 패턴을 따를수록 읽는 사람의 인지 부하가 줄어든다. 예측이 맞으면 빠르게 읽히고, 빗나가면 흐름이 끊긴다.
예측 가능한 코드
const [isOpen, setIsOpen] = useState(false)
// → 어딘가에서 setIsOpen(true/false)가 나올 것이다
const { data: product, isLoading } = useProduct(id)
// → product가 null일 수 있고, isLoading 중엔 스켈레톤을 보여줄 것이다
예측 불가한 코드
const [d, setD] = useState(null)
// → d가 뭔지, 어떤 타입인지, 언제 바뀌는지 알 수 없다
컴포넌트는 하나의 관심사만 가지는 것이 좋다
컴포넌트가 커지는 가장 흔한 이유는 "여기에 추가하면 빠르니까"다. 하지만 한 컴포넌트가 데이터 페칭, 레이아웃, 인터랙션을 모두 담당하면 어느 하나를 바꿀 때 다른 것이 영향을 받는다.
// ✅ 관심사를 분리
function ProductPage({ id }: { id: number }) {
const { product, isLoading } = useProduct(id) ← 데이터 페칭 분리
if (isLoading) return <Spinner />
if (!product) return <NotFound />
return <ProductDetail product={product} /> ← UI 렌더링 분리
}
function ProductDetail({ product }: { product: Product }) {
return (
<div>
<ProductImage src={product.imageUrl} alt={product.name} />
<ProductInfo product={product} />
<ProductActions productId={product.id} price={product.price} />
</div>
)
}
function ProductActions({ productId, price }: { productId: number; price: number }) {
const [quantity, setQuantity] = useState(1) ← 이 컴포넌트에서만 필요한 상태
const [isWished, setIsWished] = useState(false)
return (
<div>
<QuantitySelector value={quantity} onChange={setQuantity} />
<WishButton isWished={isWished} onToggle={() => setIsWished(w => !w)} />
<CartButton productId={productId} quantity={quantity} price={price} />
</div>
)
}
ProductPage는 데이터를 가져오는 것에만 집중하고, ProductDetail은 레이아웃에만 집중하고, ProductActions는 인터랙션에만 집중한다. 각 컴포넌트를 독립적으로 테스트하고 교체할 수 있다.
컴포넌트 상태 설계 — 어디에 위치 시켜야할까?
상태를 어디에 두느냐는 코드 복잡도에 직접 영향을 준다.
상태는 그것을 필요로 하는 컴포넌트에 가장 가까운 곳에 둬야한다.
상태 위치 결정 기준
이 컴포넌트에서만 쓰인다 → 컴포넌트 로컬 useState
형제/부모가 함께 쓴다 → 공통 부모로 상태 끌어올리기 (lifting state up)
멀리 떨어진 컴포넌트가 쓴다 → Context 또는 전역 상태
URL로 관리할 수 있다 → URL searchParams
// ❌ 모든 상태를 최상단에 몰아두는 패턴
function App() {
const [isModalOpen, setIsModalOpen] = useState(false)
const [selectedProduct, setSelectedProduct] = useState<Product | null>(null)
const [cartCount, setCartCount] = useState(0)
const [searchKeyword, setSearchKeyword] = useState('')
// ... 스크롤하지 않으면 어떤 상태가 어디서 쓰이는지 알 수 없다
}
// ✅ 상태는 쓰이는 곳 가장 가까이에
function ProductList() {
const [searchKeyword, setSearchKeyword] = useState('') ← 이 컴포넌트 트리에서만 필요
return (
<>
<SearchInput value={searchKeyword} onChange={setSearchKeyword} />
<ProductGrid keyword={searchKeyword} />
</>
)
}
function ProductCard({ product }: { product: Product }) {
const [isModalOpen, setIsModalOpen] = useState(false) ← 이 카드에서만 필요
return (
<>
<img onClick={() => setIsModalOpen(true)} src={product.imageUrl} />
{isModalOpen && <ProductModal product={product} onClose={() => setIsModalOpen(false)} />}
</>
)
}
상태 설계 — 어떤 형태로 설계해야할까?
상태의 개수가 많아질수록 동기화 문제가 생긴다. 서로 연관된 상태는 하나의 객체로 묶거나, useReducer로 전환하는 것이 좋다.
// ❌ 연관된 상태가 분산되어 있음
const [isLoading, setIsLoading] = useState(false)
const [data, setData] = useState<User | null>(null)
const [error, setError] = useState<Error | null>(null)
// isLoading=true이면서 error가 있는 상태가 생길 수 있다 — 불가능한 상태
// ✅ 상태를 discriminated union으로 설계
type AsyncState<T> =
| { status: 'idle' }
| { status: 'loading' }
| { status: 'success'; data: T }
| { status: 'error'; error: Error }
const [state, setState] = useState<AsyncState<User>>({ status: 'idle' })
// 불가능한 상태 조합 자체가 타입 수준에서 막힌다
if (state.status === 'success') {
console.log(state.data) ← 타입스크립트가 data를 보장함
}
// ❌ 복잡한 폼 상태를 useState로 하나씩 관리
const [name, setName] = useState('')
const [email, setEmail] = useState('')
const [phone, setPhone] = useState('')
const [agree, setAgree] = useState(false)
// ✅ useReducer로 폼 상태를 하나로 관리
type FormState = {
name: string
email: string
phone: string
agree: boolean
}
type FormAction =
| { type: 'SET_FIELD'; field: keyof FormState; value: string | boolean }
| { type: 'RESET' }
const initialState: FormState = {
name: '',
email: '',
phone: '',
agree: false,
}
function formReducer(state: FormState, action: FormAction): FormState {
switch (action.type) {
case 'SET_FIELD':
return { ...state, [action.field]: action.value }
case 'RESET':
return initialState
}
}
const [form, dispatch] = useReducer(formReducer, initialState)
// 사용할 때
dispatch({ type: 'SET_FIELD', field: 'name', value: '김현우' })
dispatch({ type: 'RESET' })
Custom Hook 설계 — 어떤 지점에서 어떤 것들을 캡슐화해야할까?
Custom Hook은 상태와 그 상태를 다루는 로직을 함께 묶는 도구다. 단순히 코드를 줄이기 위해 쪼개는 것은 오히려 코드를 따라가기 어렵게 만든다.
// ❌ 너무 잘게 쪼갠 훅 — 오히려 추적이 어려움
function useIsOpen() {
const [isOpen, setIsOpen] = useState(false)
return { isOpen, open: () => setIsOpen(true), close: () => setIsOpen(false) }
}
// ❌ React와 무관한 계산 로직을 훅으로 만든 경우
function useFormattedPrice(price: number) {
return useMemo(() => price.toLocaleString() + '원', [price])
// useMemo가 필요 없는 단순 계산 — 그냥 함수면 충분하다
}
// ✅ 상태와 관련 로직이 함께 있어야 의미 있는 훅
function useImageUpload() {
const [preview, setPreview] = useState<string | null>(null)
const [isUploading, setIsUploading] = useState(false)
const [error, setError] = useState<string | null>(null)
function handleFileSelect(file: File) {
const reader = new FileReader()
reader.onload = (e) => setPreview(e.target?.result as string)
reader.readAsDataURL(file)
}
async function upload(file: File): Promise<string> {
setIsUploading(true)
setError(null)
try {
const url = await uploadFile(file)
return url
} catch (e) {
setError('업로드에 실패했습니다')
throw e
} finally {
setIsUploading(false)
}
}
return { preview, isUploading, error, handleFileSelect, upload }
}
순수한 계산 로직은 훅이 아닌 함수로 분리하는 것이 좋다.
함수로 만들면 renderHook 없이 바로 단위 테스트를 작성할 수 있다.
// 순수 함수 — React와 완전히 분리된 로직
function formatPrice(price: number): string {
return price.toLocaleString() + '원'
}
function filterByCategory(products: Product[], category: string): Product[] {
return category === 'all' ? products : products.filter(p => p.category === category)
}
function sortByPrice(products: Product[], order: 'asc' | 'desc'): Product[] {
return [...products].sort((a, b) =>
order === 'asc' ? a.price - b.price : b.price - a.price
)
}
// 컴포넌트에서는 조합해서 사용
const displayed = useMemo(
() => sortByPrice(filterByCategory(products, category), sortOrder),
[products, category, sortOrder]
)
처음에 reactive 는 그냥 사용하지 말자~ 라고 생각했었는데 폼과 같은 복잡한 데이터 구조에서는 유용하기도 하다.
// ref — 원시값, 또는 교체가 일어나는 참조에 적합
const count = ref(0)
const user = ref<User | null>(null)
// 나중에 객체 자체를 교체할 수 있다
user.value = await fetchUser(id) ← ref는 교체 가능
// reactive — 내부 속성만 바뀌는 객체에 적합
const filter = reactive({
keyword: '',
category: 'all',
sortOrder: 'asc' as 'asc' | 'desc',
})
filter.keyword = '나이키' ← 교체 없이 내부 속성만 변경
// ❌ reactive는 객체 자체를 교체하면 반응성이 끊긴다
// filter = { keyword: '나이키', category: 'all', sortOrder: 'asc' } ← 절대 이렇게 쓰면 안 됨
실무에서는 ref를 기본으로 쓰고, 폼 상태처럼 여러 속성을 한 덩어리로 다루는 경우에만 reactive를 선택하는 방식이 안전하다.
Composable 설계 — 무엇을 묶어야 할까
Composable은 반응형 상태와 관련 로직을 함께 묶는 도구다. Vue 반응형 API(ref, computed, watch, onMounted)가 실제로 필요한 경우에만 Composable로 만드는 것이 좋다.
// ❌ Vue 반응형과 무관한 계산 로직을 Composable로 만든 경우
export function useFilteredProducts(products: Ref<Product[]>, filter: Ref<Filter>) {
return computed(() =>
products.value
.filter(p => p.category === filter.value.category)
.sort((a, b) => a.price - b.price)
)
// computed만 쓴다고 Composable이 될 필요는 없다
}
// ✅ 순수 함수로 분리 — 테스트가 쉽고 Vue 없이도 동작
function filterProducts(products: Product[], filter: Filter): Product[] {
return products
.filter(p => p.category === filter.category)
.sort((a, b) =>
filter.sortOrder === 'asc' ? a.price - b.price : b.price - a.price
)
}
// 컴포넌트에서는 computed로 감싸서 사용
const filtered = computed(() => filterProducts(products.value, filter))
반응형 + 라이프사이클이 조합될 때 Composable이 실제로 가치를 발휘한다.
// ✅ 진짜 Composable이 필요한 경우 — 반응형과 라이프사이클이 함께 필요함
export function useIntersectionObserver(target: Ref<HTMLElement | null>) {
const isVisible = ref(false)
onMounted(() => {
if (!target.value) return
const observer = new IntersectionObserver(([entry]) => {
isVisible.value = entry.isIntersecting
})
observer.observe(target.value)
onUnmounted(() => observer.disconnect())
})
return { isVisible }
}
// 컴포넌트에서
const cardRef = ref<HTMLElement | null>(null)
const { isVisible } = useIntersectionObserver(cardRef)
Props 설계 — 인터페이스를 어떻게 만들 것인가
Vue의 defineProps는 TypeScript 제네릭 문법을 그대로 지원한다.
Props 이름이 부모의 상태 구조를 드러내면 재사용성이 떨어진다.
<!-- ❌ 부모의 상태 구조가 Props로 새어나옴 -->
<script setup lang="ts">
defineProps<{
date: string
setDate: (v: string) => void ← 부모 구현이 노출됨
}>()
</script>
추상화는 코드를 단순히 숨기는 플로우가 아니라 반복이 실제로 발생했을 때, 변경 가능성이 있는 경계가 생겼을 때 의미가 생긴다고 생각한다. 추상화 전에 확인해야할 부분들은 아래와 같다.
•
이 로직이 두 곳 이상에서 실제로 사용되고 있는지?
•
내부 구현이 바뀌어도 인터페이스는 유지될 수 있는지?
•
추상화 후에 코드가 이전보다 더 예측 가능해지는지?
세 질문 중 하나도 해당하지 않으면 추상화는 유지보수 비용만 늘어날 수 있다. React의 Custom Hook이나 Vue의 Composable을 너무 잘게 쪼개면 코드를 따라가기 위해 파일을 여러 개 열어야 하는 상황이 생긴다.
응집도는 파일 수가 아니라 관련 있는 코드가 얼마나 가까이 있는가로 판단하는 것이 좋다. 항상 개발을 진행하면서 확장성을 생각하며 개발을 진행하지만 이 확장성이 오히려 현재 구현되지 않는 기능까지 고려하며 개발을 진행하다보니 나만 알 수 있는 코드가 되어버리는 경우가 정말 많다.
코드는 영구적인 것이 아니라, 항상 다듬고 다듬어주는 글과 같은 존재라고 생각이 든다. 현재에서 최선의 코드를 작성하고, 이 코드가 추후에는 어떤 기능이 추가되었을 때 또 어떻게 변화할지는 개발자가 계속해서 신경을 써줘야하는 몫이라고 생각이 든다.
