컴포넌트 코드가 대상이다. 번들러·패키지 매니저·의존성은 frontend-build,\n디자인 토큰·컴포넌트 선택은 doksam-ui 가 맡는다.
이 문서는 일반론을 적지 않는다. 판단이 갈리는 지점, 자주 틀리는 곳, React 19 에서\n바뀐 것만 담는다.
\n판단 순서:
\nuseState + useEffect\n조합으로 파생값을 동기화하지 않는다. 이 패턴이 버그의 큰 축이다.// 나쁨 — 파생값을 상태로 두고 동기화\nconst [filtered, setFiltered] = useState<Room[]>([])\nuseEffect(() => { setFiltered(rooms.filter(r => r.name.includes(q))) }, [rooms, q])\n\n// 좋음 — 렌더 중 계산\nconst filtered = useMemo(() => rooms.filter(r => r.name.includes(q)), [rooms, q])\nuseMemo 는 측정 가능한 비용이 있을 때만. 배열 몇 개 도는 것에 붙이면 코드만 늘어난다.
effect 를 쓰기 전에 답한다: 이 코드가 맞물리려는 외부 시스템이 무엇인가?\n(네트워크, DOM 이벤트, 타이머, 구독) 답이 없으면 effect 가 아니다.
\nuseEffect(() => {\n let alive = true\n api.messages(dbRef, roomId).then(m => { if (alive) setMessages(m) })\n return () => { alive = false }\n}, [dbRef, roomId])\n빠뜨리면 대상을 연달아 바꿀 때 먼저 보낸 응답이 나중에 도착해 화면을 덮는다(경합).\nAbortController 를 쓸 수 있으면 그쪽이 더 낫다 — 요청 자체를 끊는다.
린트가 요구하는 값을 빼서 \"한 번만 실행\"을 흉내내지 않는다. 대신 원인을 없앤다 —\n함수는 useCallback 으로 안정화하거나 effect 안으로 옮기고, 정말 마운트 1회면\n그 사실이 드러나게 쓴다.
key 는 데이터의 안정적 식별자. 배열 인덱스는 순서가 바뀌거나 중간 삽입이 있으면\n상태가 엉뚱한 행에 붙는다.key 를 바꾸는 것은 정식 기법이다.\n상세 뷰에서 대상이 바뀔 때 내부 상태를 리셋하는 가장 단순한 방법이다.<MessageView key={`${room.id}:${jumpTo ?? 0}`} ... />\nforwardRef 가 필요 없다 — 함수 컴포넌트가 ref 를 일반 prop 으로 받는다.\n기존 코드를 일괄 변환할 필요는 없지만 새 코드에서 쓰지 않는다.use() 로 promise·context 를 조건부로 읽을 수 있다. Suspense 경계와 함께 쓴다.useFormStatus·useActionState 는 폼 제출 상태를 다룬다. 서버 액션이 없는\nSPA 에서도 쓸 수 있다.서드파티 컴포넌트에 ref 를 넘겨 특정 자식으로 스크롤하는 식의 조작은 취약하다.\n내부가 어떤 엘리먼트를 렌더하는지에 의존하기 때문이다. 이럴 땐 data-* 속성을 붙이고\n컨테이너에서 querySelector 로 찾는 편이 타입·구조 양쪽에서 안전하다.
리뷰에서 지적하는 대신 틀리기 어렵게 만든다.
\naria-label 이 없으면 만들지 않는다. 레이블을 필수 prop 으로 받는\n래퍼 컴포넌트를 두면 구조적으로 막힌다.<button>/<a>. <div onClick> 은 키보드·스크린리더에서 사라진다.<label htmlFor> 로 연결한다. placeholder 는 레이블이 아니다.role=\"alert\".focus-visible 로 대체 스타일을 준다.confirm()/alert() 를 쓰지 않는다. 데스크톱 셸(웹뷰)에서 이벤트 루프를 막아\n앱이 굳는다. 2단계 인라인 확인이나 다이얼로그 컴포넌트로 대체한다.dangerouslySetInnerHTML 는 기본 금지. 꼭 필요하면 서버에서 새니타이즈하고, 그 사실을\n주석에 남긴다. 사용자 입력·외부 데이터를 그대로 넣지 않는다.href/src 에 넣을 때 스킴을 검사한다(javascript: 차단).기본은 \"단순하게 쓰고, 느려지면 고친다\". React 컴파일러가 도입된 프로젝트라면\n수동 메모이제이션을 먼저 걷어낸다.
\n실제로 문제가 되는 것들:
\naria-controls, aria-expanded, role=\"alert\" 등 접근성 트리(Accessibility Tree)를 기반으로 DOM 상태와 노출 여부를 판정한다.hidden 속성으로 숨겨진 폼 필드는 DOM에 남아 있어 자동완성을 보존하지만 렌더 트리에서는 비가시 상태다. 테스트 시 버튼 트리거로 가시 상태(isVisible) 전환 후 제출과 에러 안내 렌더링을 확인한다.any 0건key 가 안정적 식별자임dangerouslySetInnerHTML 을 썼다면 근거가 주석에 있음role=alert, aria-expanded 등)를 확인하는 것이 토큰 효율과 판정 정확도가 높다. 접힌(hidden) 폼 영역은 가시성 토글 이벤트 후 인터랙션을 검증한다.