Props

컴포넌트를 잘게 나누더라도 각 조각이 필요한 데이터를 받지 못하면 재사용 가능한 구조가 되지 않습니다. 반대로 자식이 부모의 데이터를 직접 건드리게 두면 값이 어디서 바뀌는지 추적하기 어려워지고, 화면 업데이트 원인도 흐려집니다.

React는 데이터가 한 방향으로 흐르는 구조를 강하게 밀어 왔습니다. 여러 곳이 같은 값을 임의로 수정하는 구조는 디버깅 비용이 높기 때문입니다. 그래서 부모가 현재 값을 내려주고 자식은 그 입력을 바탕으로 렌더링만 하는 모델이 기본 규칙으로 자리 잡았습니다.

부모 컴포넌트가 렌더링될 때 JSX 속성으로 자식에게 값을 넘기면, React는 이를 props 객체로 묶어 자식 함수에 전달합니다. 자식은 그 입력을 읽어 JSX를 계산하고, 부모의 값이 바뀌면 새 props를 받아 다시 렌더링됩니다. 이 흐름 덕분에 화면 변화의 출발점을 위쪽에서 추적하기가 쉽습니다.

Props와 state는 둘 다 화면을 바꾸는 값이지만 역할이 다릅니다. Props는 외부에서 내려온 입력이고, state는 컴포넌트 내부에서 관리하는 현재 상태입니다. 또한 props drilling이 길어질 때는 props 자체가 문제라기보다, 너무 깊은 트리까지 같은 값을 손으로 전달해야 하는 구조가 부담이 되는 것이고 그때 Context를 고려합니다.

실무에서는 props를 컴포넌트의 공개 API처럼 다루는 태도가 중요합니다. 이름이 불명확한 boolean props가 여러 개 쌓이기 시작하면 컴포넌트의 책임이 흐려졌다는 신호일 수 있습니다. 값만 내릴지, 이벤트 콜백도 함께 내릴지, 아니면 아예 컴포넌트 경계를 다시 나눌지를 같이 판단해야 합니다.