리액트 폼 입력은 누가 관리해야 할까: Controlled와 Uncontrolled 선택 기준
빠른 답
- 입력값이 화면 상태와 함께 즉시 바뀌어야 하면 Controlled가 기본 선택입니다.
- 제출할 때만 값을 읽으면 되는 단순 폼은 Uncontrolled가 더 간단합니다.
- 핵심 기준은 성능보다 데이터 흐름과 상태 소유권을 어디에 둘지입니다.
- value와 defaultValue를 섞거나 ref와 state를 함께 밀어붙이면 버그가 나기 쉽습니다.
목차
왜 두 방식이 자주 헷갈릴까
겉으로 보면 둘 다 똑같이 입력창이 동작합니다. 사용자는 타이핑하고, 화면에는 글자가 보입니다. 그래서 처음에는 "useState로 관리하든 ref로 읽든 결과가 같은 것 아닌가?"라고 느끼기 쉽습니다.
하지만 실무에서 중요한 것은 누가 현재 값을 소유하느냐입니다. Controlled Component는 입력값의 원본이 리액트 state입니다. 반대로 Uncontrolled Component는 브라우저 DOM이 값을 들고 있고, 리액트는 제출 시점이나 특정 이벤트에서만 그 값을 읽습니다.
즉 차이는 문법이 아니라 데이터 흐름입니다. 입력값이 다른 UI를 바꾸는지, 부모 컴포넌트가 현재 값을 알아야 하는지, 입력 중간에 검증이나 자동 저장이 필요한지에 따라 선택이 갈립니다.
한눈에 비교
- 값의 출처:
Controlled는state,Uncontrolled는 DOM의 현재 값입니다. - 데이터 흐름:
Controlled는onChange -> setState -> render -> value순서로 흐르고,Uncontrolled는사용자 입력 -> DOM 갱신 -> submit/ref/FormData 조회흐름으로 동작합니다. - 상태 소유권:
Controlled는 컴포넌트 또는 부모가 값을 소유하고,Uncontrolled는 브라우저가 값을 소유합니다. - 리렌더링:
Controlled는 입력마다 상태를 쓰는 컴포넌트가 다시 렌더링됩니다.Uncontrolled는 입력 자체만으로는 리액트 리렌더링이 발생하지 않습니다. - 초기값 처리:
Controlled는value,checked로 현재 값을 밀어 넣고,Uncontrolled는defaultValue,defaultChecked로 초기값만 설정합니다. - 잘 맞는 상황: 실시간 검증, 조건부 UI, 부모 상태 연동, 미리보기는
Controlled가 유리합니다. 제출 시점 조회, 단순 입력, 기존 DOM 중심 코드 연동은Uncontrolled가 잘 맞습니다. - 예외 케이스:
input type="file"은 브라우저 제약 때문에 사실상Uncontrolled로 다룹니다. - 실무 기준: 현재 입력이 다른 화면 요소를 바꾸면
Controlled, 제출 데이터로만 쓰이면Uncontrolled라고 보면 대부분 맞습니다.
먼저 결정할 질문: 이 값은 화면 상태인가, 제출 데이터인가
폼을 만들기 전에 필드별 소유권을 먼저 정하면 판단이 쉬워집니다. "이 값이 렌더링 흐름에 들어오는가?"를 먼저 묻고, 그다음에 구현 방식을 정하는 것이 좋습니다.
아래처럼 요구사항을 설정처럼 적어 보면 어떤 필드를 state로 가져와야 하는지 빠르게 보입니다.
const formPolicy = {
email: {
owner: "react-state",
validateOn: "change",
usedBy: ["errorMessage", "submitButton", "preview"],
},
memo: {
owner: "dom",
validateOn: "submit",
usedBy: ["submitPayload"],
},
};
이 예시에서 email은 입력 중간의 값이 에러 메시지와 버튼 상태를 바꾸므로 Controlled에 가깝습니다. 반면 memo는 제출 시점 payload에만 필요하므로 Uncontrolled로 두기 쉽습니다.
판단 질문은 보통 세 가지면 충분합니다.
- 현재 입력값이 다른 UI를 즉시 바꾸는가
- 부모 컴포넌트나 상위 화면이 지금 값을 알아야 하는가
- 입력 도중 검증, 마스킹, 자동 저장, API 호출이 필요한가
이 질문 중 하나라도 강하게 "예"라면 Controlled가 자연스럽습니다.
Controlled Component가 맞는 상황
Controlled는 입력값이 곧 화면 상태일 때 가장 강합니다. 대표적으로 아래와 같은 경우입니다.
- 이메일 형식이 틀리면 즉시 에러를 보여줘야 할 때
- 글자 수에 따라 버튼 활성화 여부가 바뀔 때
- 부모 컴포넌트가 현재 값을 다른 자식에게 내려줘야 할 때
- 입력값이 필터, 미리보기, 단계 이동 조건으로 쓰일 때
중요한 점은 단순히 state를 쓴다가 아니라, 부모가 값을 소유하고 자식은 입력 이벤트만 올리는 단방향 흐름을 만드는 것입니다. 이렇게 두면 어디서 값이 바뀌는지 추적하기 쉽고, 검증이나 초기화 로직이 늘어나도 구조가 덜 흔들립니다.
import { useState } from "react";
export default function FeedbackPage() {
const [form, setForm] = useState({
name: "",
message: "",
});
const messageLength = form.message.trim().length;
const messageTooShort = messageLength > 0 && messageLength < 10;
function handleSubmit(e) {
e.preventDefault();
if (!form.name.trim() || messageLength < 10) return;
console.log("submit payload", form);
}
return (
<form onSubmit={handleSubmit}>
<FeedbackFields form={form} onChange={setForm} />
<p>{form.message.length}/200</p>
{messageTooShort && <p>메시지는 10자 이상 입력해 주세요.</p>}
<button disabled={!form.name.trim() || messageLength < 10}>
보내기
</button>
</form>
);
}
function FeedbackFields({ form, onChange }) {
return (
<>
<input
name="name"
value={form.name}
onChange={(e) =>
onChange((prev) => ({ ...prev, name: e.target.value }))
}
placeholder="이름"
/>
<textarea
name="message"
value={form.message}
onChange={(e) =>
onChange((prev) => ({ ...prev, message: e.target.value }))
}
placeholder="의견을 남겨 주세요"
/>
</>
);
}
이 예시에서 name과 message는 단순한 제출 데이터가 아니라 버튼 상태와 에러 메시지를 결정합니다. 그래서 DOM에 값을 맡겨 두기보다 리액트가 현재 값을 명확히 알고 있는 편이 낫습니다.
입력마다 리렌더링이 일어난다는 이유만으로 Controlled를 피할 필요는 없습니다. 문제는 입력 자체보다 상태를 너무 높은 곳에 올려서 불필요하게 큰 트리를 같이 다시 그리는 구조인 경우가 많습니다. 성능 이슈가 보이면 먼저 상태 범위를 줄이고, 무거운 계산이나 네트워크 호출을 분리하는 쪽이 보통 더 정확한 대응입니다.
Uncontrolled Component가 맞는 상황
Uncontrolled는 입력 중간의 값이 화면 로직에 거의 관여하지 않을 때 깔끔합니다. 사용자가 입력하는 동안 리액트가 매번 값을 알 필요가 없다면, 브라우저가 기본으로 제공하는 입력 관리에 맡기고 제출 시점에만 값을 읽으면 됩니다.
잘 맞는 예는 이런 경우입니다.
- 제출 버튼을 누를 때만 값이 필요할 때
- 관리자 도구, 내부 운영 화면처럼 단순 입력이 많을 때
- 기존 DOM 중심 코드나 외부 위젯과 연결해야 할 때
- 파일 업로드처럼 브라우저가 값을 직접 관리하는 입력을 다룰 때
Uncontrolled라고 해서 반드시 ref만 써야 하는 것은 아닙니다. 필드가 여러 개라면 FormData가 더 간단한 경우도 많습니다.
export default function FeedbackPage() {
function handleSubmit(e) {
e.preventDefault();
const formData = new FormData(e.currentTarget);
const payload = {
name: String(formData.get("name") || "").trim(),
message: String(formData.get("message") || "").trim(),
attachment: formData.get("attachment"),
};
console.log("submit payload", payload);
e.currentTarget.reset();
}
return (
<form onSubmit={handleSubmit}>
<input name="name" defaultValue="익명" />
<textarea name="message" placeholder="의견을 남겨 주세요" />
<input name="attachment" type="file" />
<button type="submit">보내기</button>
</form>
);
}
이 방식에서는 defaultValue가 초기값만 설정합니다. 한 번 마운트된 뒤 사용자가 수정한 값은 DOM이 소유하고, 리액트는 자동으로 추적하지 않습니다. 그래서 실시간 글자 수, 즉시 검증, 입력값에 따른 다른 UI 변경이 필요해지는 순간 Uncontrolled의 장점은 빠르게 줄어듭니다.
예외 케이스와 하이브리드 구성
실무에서는 폼 전체를 무조건 한 방식으로 통일하지 않아도 됩니다. 필드마다 요구사항이 다르면 필드별로 소유권을 다르게 가져가는 하이브리드 구성도 충분히 합리적입니다.
예를 들어 검색어는 현재 목록 필터링에 바로 쓰이므로 Controlled가 낫고, 첨부 파일은 브라우저가 관리하므로 Uncontrolled가 자연스럽습니다. 중요한 것은 한 필드 안에 진실의 원천을 둘 이상 두지 않는 것입니다.
폼 라이브러리도 이런 현실을 반영합니다. 많은 라이브러리가 기본적으로 DOM 값을 활용해 리렌더링을 줄이면서, 현재 값이 UI에 직접 필요할 때만 Controller 같은 연결 계층으로 Controlled 입력을 지원합니다. 결국 라이브러리를 쓰더라도 판단 기준은 같습니다. 현재 값이 렌더링 로직에 들어오느냐가 핵심입니다.
흔한 안티패턴과 디버깅 포인트
가장 흔한 문제는 한 입력 필드에 소유권을 두 군데 선언하는 것입니다. value와 defaultValue를 같이 주거나, 부모가 준 값을 자식 state로 다시 복사해 별도로 관리하면 어느 값이 최신인지 모호해집니다.
아래 예시는 실무에서 자주 보는 안티패턴입니다.
import { useRef, useState } from "react";
// 안티패턴 1: value와 defaultValue를 함께 사용
function BadNameField() {
const [name, setName] = useState("");
return (
<input
value={name}
defaultValue="guest"
onChange={(e) => setName(e.target.value)}
/>
);
}
// 안티패턴 2: props를 다시 state로 복사해 이중 소유권 만들기
function BadNicknameField({ value }) {
const [localValue, setLocalValue] = useState(value);
return (
<input
value={localValue}
onChange={(e) => setLocalValue(e.target.value)}
/>
);
}
// 안티패턴 3: ref와 state를 동시에 원본처럼 사용
function BadSearchBox() {
const inputRef = useRef(null);
const [keyword, setKeyword] = useState("");
return (
<input
ref={inputRef}
value={keyword}
onChange={(e) => {
setKeyword(e.target.value);
console.log(inputRef.current.value);
}}
/>
);
}
디버깅할 때는 증상보다 소유권부터 확인하는 편이 빠릅니다.
- 입력이 안 써지면
value만 있고onChange가 없거나,onChange에서 상태 갱신이 누락된 경우가 많습니다. - 부모 초기값이 바뀌어도 자식 입력이 예전 값을 유지하면
props -> local state복사가 원인인 경우가 많습니다. defaultValue를 바꿨는데 화면이 안 바뀌면 정상 동작일 수 있습니다.Uncontrolled는 마운트 이후 DOM 값을 리액트가 다시 밀어 넣지 않습니다.- 입력할 때 페이지 전체가 무거워지면 입력 방식을 바꾸기 전에 상태를 누가 소유하고 있는지, 너무 큰 컴포넌트가 함께 다시 그려지는지부터 봐야 합니다.
실무 선택 기준 정리
정리하면 선택 기준은 복잡하지 않습니다.
- 입력값이 현재 화면의 일부라면
Controlled - 입력값이 제출 payload의 일부라면
Uncontrolled
이 기준을 조금 더 실무적으로 풀면 다음과 같습니다.
- 실시간 검증, 조건부 노출, 버튼 활성화, 미리보기, 부모 상태 연동이 있으면
Controlled - 제출 시점 조회, 단순 설문, 내부 운영 폼, 파일 업로드, 외부 DOM 라이브러리 연동은
Uncontrolled - 한 폼 안에서도 필드별로 선택은 달라질 수 있지만, 한 필드의 원본은 하나만 유지해야 합니다
- 성능 문제는
Controlled자체보다 상태 범위와 렌더링 경계 설계에서 생기는 경우가 많습니다
한 줄로 정리하면 이렇습니다. 현재 입력값이 다른 UI를 바꾸면 Controlled, 아니면 Uncontrolled를 먼저 떠올리면 됩니다. 이 원칙만 잡아도 value, defaultValue, ref, state를 어디에 써야 하는지 훨씬 분명해집니다.
원문 참고
https://www.maeil-mail.kr/question/17
댓글
댓글 쓰기