컴퓨터시스템 기초 15. 코드 최적화는 왜 측정과 locality가 먼저일까

[컴퓨터 시스템] 15. 코드 최적화는 왜 측정과 locality가 먼저일까

14편에서 locality가 성능을 바꾼다는 감각을 잡았다면, 이제 최적화를 '코드를 영리하게 바꾸는 요령'이 아니라 '무엇을 측정하고 무엇을 바꾸는가'의 문제로 봐야 합니다.

이번 글은 최적화를 감각적 마이크로 튜닝이 아니라, 병목 파악, 데이터 접근, 실험 기반 비교라는 흐름으로 정리합니다.

먼저 짚고 갈 용어

benchmark: 코드 성능을 실제로 재보는 측정

bottleneck: 전체 성능을 가장 크게 제한하는 지점

locality-aware optimization: 데이터 접근 구조를 개선하는 최적화

이번 글에서 다루는 것

• 왜 최적화 전에 측정이 먼저여야 하는지
• 병목을 찾는 관점
• locality가 최적화에서 왜 중요한지
• 컴파일러와 프로그래머의 역할 구분
• 적용형 미니 문제

한눈에 보는 흐름

1

왜 최적화 전에 측정이 먼저여야 하는지

2

병목을 찾는 관점

3

locality가 최적화에서 왜 중요한지

4

컴파일러와 프로그래머의 역할 구분

1. 최적화는 감이 아니라 병목 찾기에서 시작한다

초반에는 코드가 느리면 '더 똑똑하게 고쳐야지'부터 떠올리기 쉽습니다. 하지만 무엇이 느린지 모르고 바꾸면 시간을 많이 써도 효과가 작을 수 있습니다.

그래서 최적화의 첫 단계는 항상 병목을 찾는 일입니다. 전체 시간을 가장 많이 잡아먹는 지점을 알아야 바꿀 가치가 생깁니다.

핵심 원칙

측정 없이 하는 최적화는 종종 방향을 잘못 잡습니다. 먼저 재고, 그 다음 바꾸는 순서가 기본입니다.

2. locality를 바꾸는 최적화는 생각보다 강하다

알고리즘 복잡도를 바꾸지 않아도, 데이터 접근 순서만 바꿔서 성능이 좋아지는 경우가 많습니다. 이는 CPU 연산 자체보다 메모리 계층에서 기다리는 시간이 더 클 수 있기 때문입니다.

그림으로 먼저 보기

같은 데이터를 다시 곧 쓰는가

왜 중요한가: 시간적 locality를 높일 수 있다

가까운 주소를 순서대로 쓰는가

왜 중요한가: 공간적 locality를 높일 수 있다

불필요한 메모리 이동이 있는가

왜 중요한가: cache miss와 대기 시간을 줄일 수 있다

그래서 최적화를 볼 때는 연산 횟수뿐 아니라 '데이터를 어떤 순서로 만지는가'를 함께 물어야 합니다.

최적화 질문	왜 중요한가
같은 데이터를 다시 곧 쓰는가	시간적 locality를 높일 수 있다
가까운 주소를 순서대로 쓰는가	공간적 locality를 높일 수 있다
불필요한 메모리 이동이 있는가	cache miss와 대기 시간을 줄일 수 있다

3. 컴파일러가 해 주는 일과 직접 고민해야 하는 일은 다르다

컴파일러는 많은 저수준 최적화를 해 줍니다. 하지만 데이터 구조 선택, 접근 패턴, 알고리즘 구조 같은 상위 설계는 여전히 프로그래머가 더 직접적으로 결정합니다.

그림으로 먼저 보기

컴파일러

주로 잘하는 것: 명령 수준 정리, 일부 자동 최적화

프로그래머

주로 잘하는 것: 데이터 구조, 접근 패턴, 알고리즘, 병목 구조 개선

즉 최적화는 전부 사람이 하거나 전부 컴파일러가 하는 일이 아니라, 서로 다른 층위의 책임이 나뉘어 있습니다.

주체	주로 잘하는 것
컴파일러	명령 수준 정리, 일부 자동 최적화
프로그래머	데이터 구조, 접근 패턴, 알고리즘, 병목 구조 개선

4. 현실적인 예제로 보면 최적화 질문이 달라진다

두 경우 모두 계산 자체는 단순할 수 있지만, 메모리 접근 구조는 전혀 다릅니다. 이때 '연산이 몇 번인가'만 보면 핵심을 놓칠 수 있고, locality와 miss 패턴을 함께 봐야 합니다.

TEXT

case A: 배열을 한 번 순차 접근하며 누적합 계산
case B: 큰 구조체 배열의 일부 필드만 띄엄띄엄 접근

읽는 법

최적화 예제를 볼 때는 먼저 연산량보다 데이터 이동과 접근 순서를 읽는 습관을 들이면 좋습니다.

5. 직접 해볼 문제: 어떤 변경이 더 가치 있을까

이 문제는 특정 언어 문법보다 최적화의 사고방식을 묻습니다.

미니 문제

실행 시간의 대부분이 큰 배열 순회에서 나온다고 할 때, 루프 안 연산 한두 개를 줄이는 것과 데이터 접근 순서를 더 연속적으로 바꾸는 것 중 어느 쪽을 먼저 의심해야 할지 설명해 보세요.

이번 글에서 기억할 것

최적화는 감으로 건드리기보다 먼저 측정해 병목을 찾는 일에서 시작한다.

locality를 높이는 구조 변화는 연산 수 변경만큼이나 강력할 수 있다.

컴파일러와 프로그래머는 서로 다른 층위의 최적화를 맡는다.

스스로 점검

왜 최적화 전에 측정이 필요한지 설명할 수 있는가

locality 기반 최적화가 왜 강한지 설명할 수 있는가

컴파일러가 잘하는 최적화와 직접 고민해야 할 최적화를 구분할 수 있는가

다음 글 예고

다음 글에서는 운영체제가 프로세스와 가상 메모리를 어떻게 관리하는지로 넘어갑니다.

한 줄 정리

좋은 최적화의 시작점은 영리한 트릭이 아니라, 병목을 측정하고 데이터 접근 구조를 읽는 데 있습니다.