그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Performance
Performance

참조 지역성의 원리와 코드 최적화 방법을 설명해 주세요.

실무4/5
설계3/5
인간4/5
기초4/5

면접관의 질문 의도

지역성을 정의로만 외운 사람과, 캐시 미스율·실행 시간을 측정해서 접근 패턴을 바꿔본 사람을 가르는 질문이다. 정답을 하나로 단정하는지, 측정 후 트레이드오프를 말하는지로 깊이를 본다.

큐레이션 답변

학습 자료

참조 지역성은 "방금 본 데이터를 또 본다(시간 지역성)"와 "옆에 있는 데이터를 같이 본다(공간 지역성)"는 두 경향이다. CPU 캐시·TLB·페이지 캐시는 이 경향을 전제로 동작하기 때문에, 같은 알고리즘이라도 데이터 배치와 접근 순서가 캐시 미스율을 가른다. 최적화의 핵심은 Big-O가 아니라 "한 캐시 라인이 올라오는 동안 그 라인을 얼마나 빨아먹는가"다.

좋은 답변 구조

  1. 01시간 지역성과 공간 지역성을 캐시 동작과 묶어서 정의한다
  2. 02캐시 미스율·실행 시간을 어떻게 측정해서 병목을 잡았는지 말한다
  3. 03행·열 순서, AoS·SoA처럼 데이터 배치 또는 접근 순서를 바꾼 구체적 전략을 든다
  4. 04이득이 없는 상황(작은 데이터, 스트리밍)과 false sharing 역효과까지 짚어 트레이드오프를 드러낸다

자주 실수하는 포인트

지역성 개선을 알고리즘 복잡도 개선과 같은 층위로 섞어서 말한다
측정 없이 "순서만 바꾸면 빨라진다"고 단정한다
캐시 라인·prefetcher 같은 하드웨어 단위는 빼고 추상적인 "메모리 접근"으로만 설명한다
멀티스레드에서 데이터를 뭉치다가 생기는 false sharing 같은 역효과를 모른다

실무 맥락

  • 수백 MB 이상 배열을 반복 순회하는 데이터 파이프라인이나 배치 잡
  • 프레임당 같은 버퍼를 여러 번 훑는 게임·그래픽스·시뮬레이션 루프
  • 스레드별 카운터·메트릭이 한 캐시 라인에 묶여 throughput이 안 오르는 멀티스레드 서버
  • perf·VTune·cachegrind로 LLC 미스·IPC를 보면서 핫 루프를 튜닝하는 상황

본인 경험에 녹이는 힌트

이중 루프 순서를 뒤집어 실행 시간이 몇 배 줄었던 경험이 있다면 캐시 라인 단위 접근으로 설명할 수 있다

이미지·행렬·CSV 같은 큰 배열을 다뤄봤다면 행·열 우선 차이를 자기 코드 예시로 풀 수 있다

프로파일러로 hot path를 좁혀본 경험이 있다면 "무엇을 보고 캐시 미스라고 판단했는지" 측정 기준을 답에 녹일 수 있다

멀티스레드에서 락이 없는데도 안 빨라졌던 일이 있었다면 false sharing 의심 사례로 연결할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1캐시 라인 크기가 64B라는 사실이 자료구조 설계에 어떤 제약을 주나요
Q2AoS와 SoA 중 하나로 결정해야 한다면 어떤 기준으로 고르나요
Q3멀티스레드에서 false sharing이 의심될 때 어떻게 확인하고 잡나요
Q4지역성 최적화로도 한계가 보일 때 다음에 의심하는 병목은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문