React 리스트 key에 index를 쓰면 왜 상태가 꼬일까: 안전한 key 선택 기준

빠른 답

순서가 바뀌는 리스트에서 index key는 항목의 정체성을 안정적으로 보장하지 못한다.
문제의 핵심은 단순 재렌더링보다 입력값, 포커스, 체크 상태 같은 로컬 상태가 다른 행으로 옮겨 붙는 버그다.
가장 좋은 key는 서버가 준 고유 ID이고, 없으면 렌더 이전 단계에서 한 번만 만든 안정적인 ID를 써야 한다.
추가, 삭제, 정렬 변경이 전혀 없는 정적 목록만 index key의 예외로 볼 수 있다.

흐름으로 보기
시간 흐름으로 이해하기
React에서 key는 무엇을 식별하나
데이터 흐름과 상태 소유권
index key를 성능 문제로만 보면 놓치기 쉬운 점
실전 코드로 보기
서버 ID가 없을 때는 어떻게 준비할까
흔한 안티패턴과 예외 범위
점검할 때 보는 순서
시간 흐름으로 이해하기

흐름으로 보기

흐름 다이어그램

리스트가 처음 렌더링될 때 React는 각 행을 key로 구분해 기억합니다. 이 값이 안정적이면 React는 "같은 항목이 자리를 옮겼다"라고 이해하기 쉽고, 값이 위치 중심이면 "같은 자리에 다른 항목이 들어왔다"처럼 보게 됩니다.

그래서 중간 삽입, 삭제, 정렬 변경이 일어나는 순간 차이가 크게 드러납니다. index는 데이터의 정체성이 아니라 현재 위치를 가리키기 때문에, 로컬 상태의 주인이 데이터와 어긋날 수 있습니다.

시간 흐름으로 이해하기

초기 렌더

A(0) , B(1) , C(2) 처럼 각 행이 현재 위치로 식별됩니다.

→

중간 삽입

B 앞에 X 가 들어오면 뒤쪽 항목들의 index 가 모두 밀립니다.

→

index 재배치

데이터는 그대로인데 B , C 의 key 가 달라집니다.

→

기존 상태 재사용

React는 이전 위치의 상태를 새 위치의 항목에 이어 붙일 수 있습니다.

→

화면 증상

입력값, 포커스, 체크 상태, 펼침 상태가 다른 줄에 남아 보일 수 있습니다.

이 시간축이 중요한 이유는 첫 렌더에서는 문제가 잘 보이지 않기 때문입니다. 사용자가 어떤 행에서 입력을 시작하거나, 리스트가 필터링되거나, 드래그 정렬을 거친 뒤에야 증상이 나타나는 경우가 많습니다.

React에서 key는 무엇을 식별하나

현재 React 문서의 Rendering Lists와 Preserving and Resetting State를 함께 보면, key는 단순한 성능 힌트라기보다 "형제 목록 안에서 어떤 렌더 결과가 같은 항목인지"를 구분하는 식별자에 가깝습니다.

이 설명이 중요한 이유는 상태가 JSX 태그 안에 붙어 있는 것이 아니라 렌더 트리의 위치와 연결되기 때문입니다. key는 그 위치를 더 세밀하게 구분해 주는 값이라서, 같은 컴포넌트를 계속 같은 것으로 볼지, 다른 것으로 보고 상태를 새로 만들지를 결정하는 데 직접 관여합니다.

몇 가지 성질도 같이 기억해 둘 만합니다.

key는 같은 부모 아래 형제들 사이에서만 유일하면 됩니다.
key는 자식 컴포넌트의 props로 전달되지 않습니다. 자식에서도 ID가 필요하면 id를 따로 넘겨야 합니다.
React의 useId는 접근성용 ID 생성에 가깝고, 리스트 key를 만들기 위한 도구는 아닙니다.
렌더링 중 Math.random()이나 Date.now()로 만든 값은 매번 바뀌므로 상태를 계속 새로 만드는 결과로 이어집니다.

예전에는 key를 "리스트 렌더링 최적화를 위한 힌트"처럼만 설명하는 글이 많았습니다. 지금 기준으로 보면 그 설명은 절반만 맞습니다. key는 렌더링 비용뿐 아니라 상태 보존 범위를 정하는 기준이기도 합니다.

데이터 흐름과 상태 소유권

이 문제를 이해할 때는 리스트 데이터를 누가 소유하는지와, 각 행의 UI 상태를 누가 소유하는지를 분리해서 보는 편이 좋습니다.

부모 컴포넌트는 보통 배열 데이터와 순서를 관리합니다. 반면 각 행 컴포넌트는 draft, isEditing, isOpen, 포커스 같은 로컬 상태를 가질 수 있습니다. key는 부모가 가진 데이터 항목과 자식이 가진 상태를 서로 연결하는 기준점입니다.

부모가 소유하는 것: 배열 데이터, 정렬 결과, 필터 결과, 선택된 항목 ID
행이 소유하는 것: 입력 중 임시값, 체크 상태, 펼침 여부, 포커스, 서드파티 입력 컴포넌트 내부 상태
key가 하는 일: 어느 상태가 어느 데이터 항목의 것인지 계속 맞춰 주기

index를 쓰면 이 연결 기준이 "이 항목이 누구인가"에서 "이 항목이 몇 번째 줄인가"로 바뀝니다. 리스트가 한 번도 움직이지 않으면 티가 덜 나지만, 순서가 조금만 바뀌어도 상태 소유권이 흔들리기 시작합니다.

index key를 성능 문제로만 보면 놓치기 쉬운 점

index를 key로 쓰지 말라는 설명은 종종 "불필요한 재렌더링이 생긴다"는 쪽에 머뭅니다. 이 설명도 일부 맞지만, 실제 버그는 성능보다 정합성 문제로 더 자주 체감됩니다.

예를 들어 사용자가 두 번째 항목의 입력창에 문장을 고치는 중이라고 가정해 보겠습니다. 그 순간 위쪽에 새 항목이 삽입되면, React는 기존 두 번째 줄이 들고 있던 상태를 새 항목에 이어 붙일 수 있습니다. 그러면 화면에는 "값이 옆 줄로 이동했다", "포커스가 이상하게 남았다", "체크 표시가 엉뚱한 항목에 붙었다" 같은 현상이 생깁니다.

부모가 모든 입력값을 완전히 제어하는 구조라면 증상이 덜 보일 수도 있습니다. 하지만 포커스 위치, 텍스트 선택 범위, 서드파티 에디터의 내부 상태, 애니메이션 진행 상태 같은 것은 여전히 영향을 받을 수 있습니다. 그래서 이 문제는 "조금 비효율적이다"보다는 "상태를 잘못 보존할 수 있다"에 더 가깝습니다.

실전 코드로 보기

아래 예시는 부모가 items 배열을 가지고 있고, 각 행이 자기 draft 상태를 로컬로 관리하는 구조입니다. 이때 key={index}를 쓰면 중간 삽입 이후 상태가 다른 행으로 이어질 수 있습니다.

import { useState } from 'react';

type Todo = { id: string; title: string };

export default function TodoList() {
  const [items, setItems] = useState<Todo[]>([
    { id: 'a', title: '회의 준비' },
    { id: 'b', title: '메일 답장' },
    { id: 'c', title: '배포 점검' },
  ]);

  const insertInMiddle = () => {
    setItems(prev => [
      prev[0],
      { id: 'x', title: '긴급 확인' },
      ...prev.slice(1),
    ]);
  };

  return (
    <div>
      <button onClick={insertInMiddle}>중간에 삽입</button>
      {items.map((item, index) => (
        <EditableRow key={index} item={item} />
      ))}
    </div>
  );
}

function EditableRow({ item }: { item: Todo }) {
  const [draft, setDraft] = useState(item.title);

  return (
    <label style={{ display: 'block', margin: '8px 0' }}>
      <div>{item.title}</div>
      <input value={draft} onChange={e => setDraft(e.target.value)} />
    </label>
  );
}

이 코드는 처음에는 멀쩡해 보입니다. 하지만 두 번째 줄의 입력값을 수정한 다음 중간에 삽입을 누르면, 아래쪽 항목들의 index가 바뀌면서 draft 상태와 실제 데이터 항목의 연결이 흔들릴 수 있습니다. 정렬 버튼이나 필터 입력이 있는 리스트에서도 같은 유형의 문제가 반복됩니다.

같은 예제를 항목 ID 기반 key로 바꾸면 React는 위치가 아니라 데이터의 정체성으로 각 행을 추적할 수 있습니다.

import { useState } from 'react';

type Todo = { id: string; title: string };

export default function TodoList() {
  const [items, setItems] = useState<Todo[]>([
    { id: 'a', title: '회의 준비' },
    { id: 'b', title: '메일 답장' },
    { id: 'c', title: '배포 점검' },
  ]);

  const insertInMiddle = () => {
    setItems(prev => [
      prev[0],
      { id: 'x', title: '긴급 확인' },
      ...prev.slice(1),
    ]);
  };

  return (
    <div>
      <button onClick={insertInMiddle}>중간에 삽입</button>
      {items.map(item => (
        <EditableRow key={item.id} item={item} />
      ))}
    </div>
  );
}

function EditableRow({ item }: { item: Todo }) {
  const [draft, setDraft] = useState(item.title);

  return (
    <label style={{ display: 'block', margin: '8px 0' }}>
      <div>{item.title}</div>
      <input value={draft} onChange={e => setDraft(e.target.value)} />
    </label>
  );
}

바뀐 것은 EditableRow의 내부 로직이 아니라 key뿐입니다. 그 한 줄이 상태의 소유자를 "두 번째 줄"이 아니라 "id='b'인 항목"으로 바꿔 준다는 점이 중요합니다.

서버 ID가 없을 때는 어떻게 준비할까

가장 단순한 선택은 서버가 내려준 고유 ID를 그대로 쓰는 방식입니다. 댓글, 게시글, 사용자, 주문처럼 백엔드에서 이미 고유성이 보장된 값이 있으면 그것이 가장 설명력이 좋습니다.

문제는 아직 서버에 저장되지 않은 초안 항목이나, 클라이언트에서 먼저 생성되는 로컬 데이터입니다. 이 경우에는 렌더링 시점이 아니라 데이터가 만들어지는 시점에 안정적인 ID를 붙여 두는 편이 좋습니다.

type DraftItem = {
  clientId: string;
  title: string;
};

function createDraftItem(title: string): DraftItem {
  return {
    clientId: crypto.randomUUID(),
    title,
  };
}

이런 식으로 한 번 만든 ID를 배열 데이터에 저장해 두면, 이후 렌더에서는 그 값을 그대로 key로 사용할 수 있습니다.

import { useState } from 'react';

type Item = {
  id?: number;
  clientId?: string;
  title: string;
};

export default function DraftList() {
  const [items, setItems] = useState<Item[]>([
    { id: 101, title: '서버에서 온 항목' },
    { clientId: crypto.randomUUID(), title: '아직 저장 전인 항목' },
  ]);

  const addDraft = (title: string) => {
    setItems(prev => [...prev, { clientId: crypto.randomUUID(), title }]);
  };

  return (
    <div>
      <button onClick={() => addDraft('새 초안')}>추가</button>
      {items.map(item => (
        <Row key={item.id ?? item.clientId} item={item} />
      ))}
    </div>
  );
}

function Row({ item }: { item: Item }) {
  return <div>{item.title}</div>;
}

여기서 주의할 점은 map() 안에서 crypto.randomUUID()를 호출하지 않는다는 점입니다. 렌더링 중 생성한 랜덤 키는 렌더할 때마다 달라져서, 오히려 모든 행을 매번 새 컴포넌트처럼 취급하게 만듭니다.

여러 필드를 합쳐 key를 만드는 방법도 가능은 합니다. 다만 title, name처럼 바뀔 수 있는 필드를 섞으면, 사용자가 그 값을 수정하는 순간 기존 항목이 새 항목처럼 보일 수 있습니다. 조합 키를 써야 한다면, 수정되지 않는 필드인지와 실제로 충돌이 없는지 먼저 확인해 둘 필요가 있습니다.

흔한 안티패턴과 예외 범위

index 키는 모든 경우에 즉시 문제를 일으키는 것은 아닙니다. 고정된 약관 목록처럼 순서와 내용이 바뀌지 않고, 각 행이 별도의 로컬 상태를 거의 갖지 않는 정적 목록이라면 눈에 띄는 문제가 없을 수 있습니다.

다만 조건은 생각보다 좁습니다.

항목 추가가 없습니다.
항목 삭제가 없습니다.
정렬과 필터링이 없습니다.
드래그 앤 드롭이 없습니다.
각 행의 로컬 상태가 거의 없습니다.

반대로 아래와 같은 코드는 흔히 문제가 됩니다.

key={index}
key={Math.random()}
key={Date.now()}
key={item.title}처럼 수정 가능한 값을 사용하는 방식
필터링, 정렬, 페이징, 무한 스크롤이 붙는 리스트에서 위치 기반 키를 유지하는 방식

메모이제이션도 이 문제를 대신 해결해 주지는 않습니다. React.memo, useMemo, useCallback은 렌더 비용을 줄이는 도구일 뿐, 어떤 상태가 누구의 것인지를 다시 맞춰 주는 장치는 아닙니다.

반대로 key를 의도적으로 바꿔 상태를 초기화하고 싶을 때도 있습니다. 예를 들어 채팅 대상을 바꿀 때 입력창을 새로 시작하고 싶다면 key={to.id}처럼 다른 key를 주는 방법을 쓸 수 있습니다. 같은 메커니즘이 버그의 원인이 되기도 하고, 상태 초기화 수단이 되기도 한다는 점에서 key의 의미를 더 분명하게 볼 수 있습니다.

점검할 때 보는 순서

리스트에서 값이 뒤섞이거나 포커스가 이상하게 움직일 때는 렌더링 최적화보다 먼저 식별자 기준을 점검해 보는 편이 좋습니다.

리스트가 중간 삽입, 삭제, 정렬, 필터링을 하는지 확인합니다.
각 행 안에 useState, useRef, 체크 상태, 포커스, 서드파티 입력 상태가 있는지 봅니다.
key가 서버 ID, 로컬 생성 ID처럼 항목 자체를 식별하는 값인지 확인합니다.
map() 안에서 랜덤 값을 만들거나, 수정 가능한 필드를 key로 쓰고 있지 않은지 봅니다.
증상이 특정 시점 뒤에만 나타난다면, 그 시점에 배열 순서가 어떻게 바뀌는지 추적합니다.

이 순서로 보면 "왜 값이 꼬였는가"를 성능 문제가 아니라 데이터 항목과 로컬 상태의 연결 문제로 해석하기 쉬워집니다. React 리스트에서 key는 사소한 문법 장치가 아니라, 어떤 상태가 어떤 항목의 것인지를 정하는 기준점에 가깝습니다.

원문 참고

https://www.maeil-mail.kr/question/42

시간 흐름으로 이해하기

초기 렌더

→

중간 삽입

→

index 재배치

→

기존 상태 재사용

→

입력값 뒤섞임

Chart js와 amchart 비교

Chart js 특징은 위의 그림으로 대체 할 수 있을 듯 하다. 오픈 소스이고, 기본으로 제공하는 차트 종류가 8가지 Canv a s를 이용해서 차트를 그리고, 반응형을 지원한다. amchart amchart는 기본적으로 유료이며, 기본으로 제공하는 차트 종류가 기본적인 차트 + 주식 처럼 보이는 차트 + 지도에 관련된 차트(?) 까지 하면, 기본 제공 하는 종류가 20개 내외 이려나, 일일이 세기에는 양이 좀 많아 보인다. 렌더링은 svg를 통하여 그려지고, 당연 반응형도 지원이 된다. 그러면, 이 둘중에 어떤것이 내 프로젝트에 적합 하냐는 것이 문제이다. 일단, 주식 처럼 보이는 차트나 지도에 관련된 차트(?)가 필요하면, amchart를 선택해야 되는 것은 맞다. 그건 당연한 것이니 빼고 얘기 해보자! 여러 종류의 차트가 필요하다면, 일단은 amchart를 염두해 두는 것이 좋다. 돈 낸 만큼은 하는 듯 하다. 하지만, 기본적인 막대 그래프, 도넛 차트 등, 아주 기본적인 차트들인데, Chart js도 amchart도 그러한 차트가 없을 때가 문제가 된다. 그렇다면, 조금이라도 커스텀이 용이한 것을 찾는 것이 좋을 것이다. 일단 amchart에서 custom이라고 검색 하였을 때, 검색 결과가 61가지가 나온다. 차트의 종류도 많고, 각 차트마다 들어가는 속성이 매우 많기 때문에, 웬만한 내용들은 속성 값을 어떻게 주느냐에 따라서 변경이 가능 하게 된다. 커스텀의 예를 들면, 기본적으로 도넛 파이의 형태를 띄면서, 화살표로 목표를 표시해주는 차트가 필요하다고 생각 해보자. 이것은 amchart로 만든 그래프이고 이것은 chart js로 만든 그래프이다. 모양이 살짝 다르긴 하지만, 완벽하게 똑같이 구현 할 수도 있다. amchart로 만든 그래프의 경우, 저것은 도넛그래프가 아닌 guage 그래프이다. 원래 게이지 그래프는 이와 같...

코드 땜장이

이 블로그 검색