
Compose LazyColumn key는 목록을 만들 때 꼭 알아야 하는 작은 옵션입니다. 처음에는 없어도 화면이 그려지기 때문에 중요하지 않아 보이지만, 항목이 추가되거나 순서가 바뀌는 순간 문제가 드러날 수 있습니다.
핵심은 key가 리스트 항목의 위치가 아니라 정체성을 Compose에 알려준다는 점입니다. 이 기준을 잡으면 recomposition과 remember 상태가 왜 엉킬 수 있는지 이해하기 쉬워집니다.
Compose LazyColumn key가 필요한 상황

LazyColumn은 필요한 item만 그린다
Jetpack Compose 공식 문서는 Lazy layouts가 화면에 필요한 항목만 구성한다는 흐름을 설명합니다. 긴 목록을 한 번에 모두 그리지 않고, 보이는 범위 중심으로 item을 구성합니다.
이 구조는 효율적이지만, Compose가 각 item을 어떻게 구분해야 하는지 알려주는 단서가 필요할 때가 있습니다. 그 단서가 key입니다.
key가 없으면 위치가 정체성처럼 쓰일 수 있다
key를 주지 않으면 Compose는 항목의 위치를 기준으로 재사용 판단을 할 수 있습니다. 정적인 목록에서는 큰 문제가 없어 보일 수 있습니다. 하지만 중간에 항목이 삽입되거나 삭제되면 위치가 밀립니다.
예를 들어 2번째 item에 있던 상태가 새로 들어온 item 쪽으로 붙는 것처럼 보일 수 있습니다. 실제 버그는 더 복잡하게 나타납니다. 체크박스 상태, 입력값, 확장 여부, 애니메이션 위치가 예상과 달라질 수 있습니다.
안정적인 key는 item id를 쓴다
가장 좋은 key는 서버나 DB에서 온 안정적인 고유 ID입니다. index를 key로 쓰면 순서가 바뀔 때 의미가 약해집니다. 항목의 정체성이 아니라 현재 위치를 key로 쓰는 셈이기 때문입니다.
LazyColumn {
items(
items = messages,
key = { message -> message.id }
) { message ->
MessageRow(message = message)
}
}이렇게 쓰면 Compose는 message의 위치가 바뀌어도 같은 id를 가진 항목을 같은 item으로 볼 수 있습니다.
remember 상태가 item 안에 있을 때 더 중요하다
각 row 안에서 remember를 쓰면 key의 중요성이 커집니다. 항목별 확장 상태, 입력 중인 텍스트, 로컬 UI 상태가 item 정체성과 함께 유지되어야 하기 때문입니다.
물론 모든 상태를 item 안에 둘 필요는 없습니다. 중요한 화면 상태는 ViewModel이나 상위 state holder로 올리는 편이 더 나을 때도 있습니다. key는 상태 설계를 대신해주는 도구가 아니라, LazyColumn이 item을 안정적으로 구분하게 해주는 도구입니다.
recomposition 성능 옵션으로만 보면 부족하다
key를 성능 최적화 옵션으로만 설명하면 절반만 이해한 것입니다. key는 재구성 시 불필요한 작업을 줄이는 데 도움이 될 수 있지만, 더 본질적인 역할은 item identity를 안정적으로 알려주는 것입니다.
- 정적인 단순 목록이라면 key 없이도 문제가 잘 드러나지 않을 수 있다.
- 삽입, 삭제, 정렬, 필터링이 있으면 key를 적극적으로 검토한다.
- index key는 순서가 바뀌는 목록에서 안정적이지 않다.
- 서버 id, DB primary key, 로컬 UUID처럼 변하지 않는 값을 우선한다.
- 상태가 섞이면 key와 state hoisting을 함께 점검한다.
목록 화면은 단독으로 끝나지 않는 경우가 많습니다. 상세 화면으로 갔다가 돌아왔을 때 스크롤 위치와 item 상태가 자연스럽게 남아야 합니다. 이때 LazyColumn key, LazyListState, ViewModel 상태, Navigation back stack이 함께 영향을 줍니다.
화면 복원과 navigation argument 흐름은 SavedStateHandle 글과도 이어집니다. LazyColumn key는 그중 목록 item 단위의 안정성을 맡는 작은 축이라고 보면 됩니다.
정리
Compose LazyColumn key는 단순한 성능 팁이 아닙니다. 리스트 항목의 정체성을 Compose에 알려주어 순서 변경, 삽입, 삭제, recomposition, remember 상태를 더 안정적으로 다루게 해주는 기준입니다. 목록이 동적으로 바뀐다면 index보다 안정적인 item id를 key로 쓰는 습관이 좋습니다.