2What — 성능 최적화란
3- Python 코드가 주어진 자원(CPU, 메모리, 시간) 안에서 더 빠르고 효율적으로 동작하도록 개선하는 과정
4- 단순히 "빠르게 만들기"가 아니라, 병목을 측정하고 근거 있는 개선을 수행하는 엔지니어링 활동
5Why — 느린 코드가 비즈니스에 미치는 영향
6- 추천 시스템 응답 지연: Amazon은 페이지 로딩이 100ms 느려질 때마다 매출이 약 1% 감소한다고 보고 (Linden, 2006)
7- 데이터 전처리 병목: ML 파이프라인에서 전처리가 전체 학습 시간의 30~50%를 차지하는 경우가 빈번 — GPU는 대기 상태로 낭비
8- 추론 지연: 실시간 서빙에서 p99 레이턴시가 SLA를 초과하면 서비스 장애로 이어짐
9- 요약: "느리다"는 단순 불편이 아니라 비용 증가 + 매출 손실 + 사용자 이탈의 연쇄 반응
10Why — 하드웨어 스케일업의 한계
11- 첫 번째 반응: "서버를 더 넣자" → 수직 확장(scale-up)은 비용이 지수적으로 증가
12- AWS 기준 예시:
13 - c5.xlarge (4 vCPU): ~$0.17/h
14 - c5.4xlarge (16 vCPU): ~$0.68/h
15 - 4배 CPU에 4배 비용, 그러나 성능은 알고리즘 병목이 있으면 4배가 안 됨 (Amdahl's Law)
16- 암달의 법칙 핵심: 병렬화 불가능한 부분이 전체 속도 향상의 상한을 결정
17S = \frac{1}{(1 - p) + \frac{p}{n}}
18- S: 전체 속도 향상 배율, p: 병렬화 가능 비율, n: 프로세서 수
19- p = 0.9이고 n = \infty여도 최대 속도 향상은 10배가 한계
20핵심 철학 — 측정 먼저, 최적화는 나중에
21- "Premature optimization is the root of all evil" (Knuth, 1974)
22- 이 문장의 진짜 의미: 최적화 자체가 나쁜 게 아니라, 측정 없이 감으로 최적화하는 것이 위험
23- 올바른 순서:
24 1. 프로파일링으로 병목 지점을 측정한다
25 2. 전체 실행 시간의 80%를 차지하는 핫스팟을 찾는다
26 3. 해당 부분만 집중 최적화한다
27- 비유: 의사가 진단 없이 수술하지 않듯, 개발자도 측정 없이 코드를 고치면 안 된다
28Why — AI/ML 파이프라인에서 특히 중요한 이유
29- ML 학습 파이프라인의 3대 병목:
30 - 데이터 로딩: 디스크 I/O, 디코딩(이미지/텍스트), 셔플링
31 - 전처리: 정규화, 증강(augmentation), 토크나이징
32 - 추론(inference): 모델 포워드 패스, 후처리
33- GPU 활용률이 30%대에 머무는 경우 대부분 CPU 측 데이터 공급이 병목 (Mohan et al., 2021)
34- PyTorch DataLoader의 num_workers, prefetch_factor 같은 설정 하나로 학습 속도가 2~3배 차이
35- 결론: AI/ML에서 최적화는 선택이 아니라 GPU 비용을 정당화하기 위한 필수 조건
36정리 — 최적화 접근 체크리스트
37- 1단계: 먼저 올바르게 동작하는 코드를 작성한다
38- 2단계: 프로파일링 도구(cProfile, line_profiler)로 병목을 측정한다
39- 3단계: 핫스팟에만 집중하여 알고리즘/자료구조를 개선한다
40- 4단계: 그래도 부족하면 C 확장, 병렬화, 하드웨어 확장을 순차적으로 고려한다
41- "Make it work, make it right, make it fast" — 이 순서를 지키는 것이 프로페셔널 최적화의 출발점 (Hunt & Thomas, 1999)