이번 주 비대면에서는 불변성, 프로토타입, 타입 체크를 배웠습니다. 세 개 모두 처음에는 "JS가 왜 이렇게 이상하게 생겼지?" 싶은 개념입니다. 그런데 이 개념들은 프로젝트가 커질수록 실제 버그와 구조 문제로 이어집니다.
그래서 오늘 대면에서는 문법을 다시 설명하기보다, 프론트엔드 프로젝트가 왜 복잡해지는지 이야기해보겠습니다. 처음에는 HTML, CSS, JS 파일 몇 개면 될 것 같은데, 왜 React가 나오고, 컴포넌트가 나오고, 상태 관리가 나오고, 폴더 구조와 API 계층이 생기는지 큰 그림을 잡는 시간입니다.
작은 화면 하나를 만들 때는 간단합니다. 버튼을 누르면 텍스트가 바뀌고, CSS로 예쁘게 꾸미면 됩니다. 문제는 화면이 많아지고, 데이터가 많아지고, 여러 사람이 동시에 작업하기 시작할 때 생깁니다.
복잡도는 보통 코드 양보다 책임이 섞일 때 터집니다.
코드는 많아도 책임이 잘 나뉘어 있으면 고칠 수 있습니다. 반대로 코드가 적어도 책임이 섞여 있으면, 한 줄을 바꾸는 순간 어디가 깨질지 알 수 없습니다.
UI는 사용자에게 보이는 모양입니다. 버튼, 카드, 모달, 입력창, 리스트 같은 것들이 여기에 들어갑니다. 좋은 UI 컴포넌트는 가능하면 "어떻게 보여줄지"에 집중하고, 데이터를 어디서 가져오는지는 덜 알아야 합니다.
<UserCard name="진규" role="프론트엔드" isOnline={true} />
이 컴포넌트는 이름, 역할, 온라인 여부를 받아 보여주는 일만 하면 됩니다. 이 값이 API에서 왔는지, 임시 데이터인지, 로그인한 사용자 정보인지는 몰라도 됩니다.
상태는 화면이 기억해야 하는 값입니다. 모달이 열려 있는지, 어떤 탭이 선택됐는지, 입력창에 무슨 값이 들어있는지 같은 것들입니다.
상태가 무서운 이유는 시간이 지나며 바뀌기 때문입니다. 값이 바뀌면 화면도 바뀌고, 다른 컴포넌트에도 영향을 줄 수 있습니다. 그래서 상태는 "어디에 둘지"가 중요합니다.
3-3. 서버 데이터 — 내가 만든 값이 아니라 받아온 값
서버 데이터는 프론트엔드가 소유한 값이 아닙니다. 사용자 목록, 게시글, 알림, 주문 내역처럼 서버가 진짜 원본을 가지고 있는 데이터입니다. 그래서 로딩, 실패, 재요청, 캐싱, 권한 같은 문제가 따라옵니다.
이걸 일반 상태와 똑같이 다루면 점점 힘들어집니다. 화면 상태는 "내가 지금 어떤 탭을 보고 있나"에 가깝고, 서버 데이터는 "서버의 최신 값이 무엇인가"에 가깝습니다. 둘은 성격이 다릅니다.
비즈니스 규칙은 제품이 정한 판단입니다. 예를 들어 "관리자만 승인 버튼을 볼 수 있다", "마감 시간이 지나면 신청할 수 없다", "무료 사용자는 3개까지만 만들 수 있다" 같은 규칙입니다.
이런 규칙이 화면 코드 곳곳에 흩어지면 나중에 정책이 바뀔 때 지옥이 열립니다. 그래서 규칙은 이름을 붙이고, 가능하면 한 곳에서 관리해야 합니다.
function canApprove(user, item) {
return user.role === "ADMIN" && item.status === "PENDING";
}
중요한 건 함수 하나를 만들었다는 사실이 아니라, "승인 가능 여부"라는 판단에 이름을 붙였다는 점입니다. 좋은 구조는 이런 식으로 팀이 말하는 개념을 코드에 남깁니다.
프로젝트 구조 이야기를 하면 폴더 이름부터 떠올리기 쉽습니다. components,
hooks, utils, api 같은 폴더를 어떻게 나눌지 고민합니다. 물론 중요합니다.
하지만 폴더 이름보다 더 중요한 질문은 이겁니다.
"요구사항이 바뀌었을 때, 어디를 고치면 되는지 바로 알 수 있는가?"
좋은 구조는 변경이 들어왔을 때 흔들리는 범위가 작습니다. 디자인만 바뀌면 UI 컴포넌트만 바꾸고, API 응답만 바뀌면 데이터 변환 계층만 바꾸고, 정책만 바뀌면 비즈니스 규칙만 바꿀 수 있어야 합니다.
처음부터 완벽한 구조를 만들 필요는 없습니다. 다만 코드가 조금만 커져도 "이 코드는 UI인가, 상태인가, 서버 데이터인가, 정책인가"를 묻는 습관이 중요합니다.
AI는 파일 하나 안에서 그럴듯한 코드를 빠르게 만들어줍니다. 하지만 프로젝트의 책임 경계를 자동으로 잘 지켜주지는 않습니다. "이 로직은 컴포넌트 안에 있으면 안 되고 hook으로 빼야 한다", "이건 서버 데이터라 캐싱 전략이 필요하다", "이건 정책 함수로 이름 붙여야 한다" 같은 판단은 사람이 해야 합니다.
그래서 앞으로는 코드를 많이 치는 사람보다,
AI가 만든 코드를 프로젝트 구조 안에 제대로 배치할 수 있는 사람
이 더 중요해질 수 있습니다.
다음 대면에서는 프론트엔드와 백엔드가 만나는 지점인 API와 통신을 다룹니다. API는 그냥 데이터를 받는 수단이 아니라, 팀 사이의 계약입니다.