React 19.2 Activity와 useEffectEvent를 실제 화면에 적용할 때의 기준

React의 새 기능을 보면 기존 컴포넌트를 모두 바꾸고 싶어집니다. 그러나 화면이 빨라질지, 효과의 생명주기가 더 이해하기 쉬워질지는 코드의 사용 맥락에 따라 다릅니다.

React 19.2에서 소개된 Activity와 useEffectEvent는 숨겨진 화면과 효과 이벤트를 다루는 선택지를 넓혀 줍니다. 이 글은 API 사용법을 나열하기보다 어떤 화면에 적용하고 어떤 화면에는 적용하지 않을지에 초점을 둡니다.

Activity는 숨겨진 화면의 생명주기를 명시합니다

조건부 렌더링은 보이지 않는 화면을 언마운트하는 단순한 방법입니다. Activity의 hidden 모드는 화면을 유지하면서 효과를 중단하고 업데이트를 늦출 수 있어, 다시 돌아올 가능성이 높은 화면의 상태를 보존하는 데 유용할 수 있습니다.

하지만 모든 화면을 숨겨 둔다고 좋은 것은 아닙니다. 상태를 오래 보존하면 데이터가 낡거나 메모리를 계속 사용할 수 있습니다. 사용자가 곧 돌아올 화면과 다시 계산해도 되는 화면을 구분해야 합니다.

• 적용 후보: 탭 전환에서 입력 상태를 보존해야 하는 화면입니다.
• 보류 후보: 데이터가 자주 바뀌거나 메모리 비용이 큰 화면입니다.
• 확인할 것: hidden 상태에서 효과·요청·캐시가 어떻게 동작하는지입니다.

useEffectEvent는 반응성과 이벤트를 분리합니다

효과 안에서 최신 값을 읽어야 하지만 그 값이 효과를 다시 실행하는 원인이 되어서는 안 되는 경우가 있습니다. useEffectEvent는 이런 이벤트 로직을 분리하는 도구로 소개됩니다. 그렇다고 의존성 배열을 무시하는 지름길로 쓰면 안 됩니다.

저는 먼저 효과가 정말 다시 실행되어야 하는지 확인합니다. 연결을 다시 맺어야 하는 값과, 연결된 상태에서 최신 값을 읽기만 하면 되는 값을 나누는 것이 순서입니다.

코드 역할다시 실행 필요분리 후보

구독 주소	주소가 바뀌면 필요	아님
알림 문구	최신 값을 읽되 구독은 유지	예
인증 토큰	보안 정책에 따라 재연결	무조건 분리하지 않음

Performance Tracks로 체감을 확인합니다

React 19.2는 Chrome DevTools 성능 프로파일에서 React 작업을 더 잘 구분할 수 있도록 Performance Tracks를 제공합니다. 기능을 적용한 뒤 ‘새 API라서 빠르다’고 결론 내리지 않고, 실제 화면의 렌더·효과·사용자 입력 구간을 비교해야 합니다.

측정할 때는 같은 데이터와 같은 상호작용을 사용합니다. 초기 로드, 탭 전환, 뒤로 가기, 입력 중 업데이트처럼 사용자가 체감하는 시나리오를 나눠 기록합니다.

• 기준선: 기존 코드의 렌더·입력·네트워크 시간을 보관합니다.
• 변경 후: 같은 시나리오를 다시 실행해 차이를 비교합니다.
• 부작용: 상태 보존으로 오래 남는 메모리와 데이터 신선도를 확인합니다.

새 API를 쓰지 않는 판단도 기록합니다

React의 최신 기능을 적용하지 않는 것도 합리적인 결정입니다. 화면 구조가 단순하고 현재 성능 문제가 없다면 API를 늘리는 비용이 이득보다 클 수 있습니다. 팀이 이해하지 못하는 생명주기를 추가하면 유지보수 위험이 커집니다.

저는 적용한 컴포넌트마다 왜 필요한지와 다시 제거할 조건을 주석이 아니라 기술 기록에 남깁니다. 다음 사람이 기능 이름만 보고 전체 구조를 바꾸지 않게 하기 위해서입니다.

실험 결과를 운영 판단으로 바꾸는 순서

개발 문서에서 가장 재사용하기 어려운 문장은 ‘잘 됩니다’입니다. 어떤 버전과 데이터, 부하에서 잘 되었는지 모르면 독자는 자신의 환경에서 다시 확인할 수 없습니다. 저는 새로운 기능을 검토할 때 SDK·런타임·패키지·데이터베이스 버전을 먼저 고정하고, 기존 구현을 기준선으로 보관합니다. 변경 전후의 코드와 측정 명령도 함께 기록합니다.

측정값이 좋아도 운영에 바로 도입하지 않습니다. 오류 추적, 로그의 의미, 배포와 롤백, 팀이 이해할 수 있는지까지 확인합니다. 프리뷰나 변경 중인 문서는 정식 기능과 구분하고, 문서에 확인 날짜와 테스트 범위를 적습니다. 독자가 복사해 사용해도 위험하지 않도록 적용하지 말아야 하는 조건도 함께 적는 것이 기술 글의 중요한 부분입니다.

• 버전 잠금: 실험한 SDK·런타임·패키지·브라우저 버전을 기록합니다.
• 기준선: 변경 전 기능·성능·오류 결과를 같은 입력으로 보관합니다.
• 경계 사례: 빈 값·중복·실패·큰 입력에서 결과를 확인합니다.
• 배포 판단: 적용·보류·롤백 중 하나를 고르고 근거를 남깁니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

React 19.2의 Activity와 useEffectEvent는 더 많은 기능을 넣기 위한 장식이 아니라 화면 상태와 효과의 경계를 분명히 하는 도구입니다. 적용 후보 화면 하나를 골라 기준선 프로파일을 먼저 남긴 뒤 작은 변경으로 비교해 보시기 바랍니다.

참고한 문서: React 19.2 공식 글 · React 공식 블로그