같은 연산인데 객체별 구조 배열과 필드별 배열의 속도가 다릅니다. AoS와 SoA는 어떤 접근 패턴에 맞나요?

AoS는 객체의 여러 필드를 가까이 두고 SoA는 같은 필드를 연속으로 둡니다. 모든 필드를 객체별로 읽는지 특정 필드만 대량 순회하는지에 따라 캐시·벡터화·메모리 대역폭 비용이 달라집니다.

동작 원리와 전제

위치만 갱신하는 루프에서 큰 객체 구조를 읽으면 쓰지 않는 필드까지 cache line에 들어올 수 있습니다. 필드별 배열은 필요한 데이터만 연속 처리하기 좋지만 객체 단위 접근과 여러 배열 동기화가 복잡해질 수 있습니다.

선택과 실패 처리

정렬·padding·SIMD·분기·접근 순서를 함께 봅니다. 포인터 배열은 큰 객체 이동을 줄여도 간접 참조와 흩어진 할당 비용을 만듭니다. 구조를 바꾸면 ID·수명·동시 갱신의 계약도 유지해야 합니다.

구체적인 사례와 검증

게임 서버가 위치 x·y만 매 틱 갱신하는데 객체마다 큰 이름·인벤토리·상태가 붙어 있으면 필요한 값보다 많은 cache line을 읽을 수 있습니다. SoA로 위치를 모으면 개선될 수 있지만 캐릭터 하나의 전체 상태를 처리하는 코드에는 여러 배열 접근이 필요해집니다. 객체 삭제·압축 때 각 필드 배열의 인덱스가 같은 논리 ID를 가리키도록 유지해야 합니다. SIMD 가능한 연속 계산과 branch-heavy 객체 로직의 요구도 다릅니다. 데이터 배치는 단순한 메모리 절약이 아니라 접근 패턴·동시성·수명과 함께 검증할 구조 선택입니다.

실제 데이터 크기·콜드·웜 캐시·필드 사용률·코어 수에서 측정합니다. 작은 microbenchmark의 결과를 전체 서비스에 일반화하지 않습니다. 가독성·유지 비용과 CPU cache miss·대역폭·전체 지연을 함께 비교하겠습니다.