AI에게 "이 코드를 빠르게 해줘"라고 부탁해도 빨라지지 않는 이유 — 추측을 멈추고, 계측(Profiling)으로 병목

솔직히 말씀드리겠습니다. 이런 경험, 없으신가요?

앱의 움직임이 왠지 무겁다. API의 응답이 느릿느릿하다. 그래서 AI에게 이렇게 부탁하곤 합니다.

"이 코드, 느리니까 빠르게 해줘"

그러면 AI는 그럴싸한 수정안을 돌려줍니다. 루프(Loop)를 다시 쓰거나, 본 적 없는 함수를 넣어오기도 하죠. 뭔가 똑똑해 보입니다. 하지만 실제로 돌려보면… 체감상 거의 변한 게 없습니다. 오히려 다른 부분이 망가졌거나, 코드가 지나치게 읽기 어려워졌을 뿐이죠.

이건 정말 흔히 있는 일입니다. 그리고 조금 신기하지 않나요? AI는 이렇게 똑똑한데, 왜 "빠르게 해줘"라는 요청만은 잘 안 되는 걸까 하고 말이죠.

오늘 말씀드리고 싶은 결론을 먼저 말씀드리겠습니다.

성능 개선 (Performance Tuning)은 재능이나 장인 정신이 아니라, "계측(Measurement) → 병목 지점(Bottleneck) 특정 → 딱 하나만 변경 → 재계측"이라는, 누구나 돌릴 수 있는 "형식(Pattern)"입니다. 그리고 AI는 그 형식 안에서 사용할 때 단숨에 믿음직한 파트너가 됩니다. 하지만 형식 밖에서 "통째로 떠넘기기"를 하면, 추측을 고속화할 뿐인 장치가 되어버립니다.

이 기사는 AI 개발에 아직 익숙하지 않은 분들도 읽을 수 있도록, 전문 용어는 모두 그 자리에서 풀어서 설명하며 진행하겠습니다. "프로파일러(Profiler)라는 이름은 들어봤지만, 결국 무엇을 봐야 하는 거지?"라는 상태에서, "우선 한 곳이라도 제대로 숫자로 측정하기"라는 첫걸음을 내디딜 수 있는 곳까지 함께 가보겠습니다.

왜 "빠르게 해줘"가 실패하기 쉬운 걸까요? 이유는 간단합니다. 인간도 AI도 코드의 어디가 느린지 "추측할 수 없기" 때문입니다.

이것은 오래전부터 말해져 온 것입니다. Go라는 언어를 만든 Rob Pike 씨의 유명한 "프로그래밍의 5가지 규칙". 그 첫 번째가 이것입니다.

규칙 1 (추측하지 마라): 프로그램이 어디에서 시간을 사용하는지는 예측할 수 없다. 병목 지점(Bottleneck)은 의외의 장소에서 발생한다. 그러므로 "여기가 느릴 것이다"라고 증명하기 전에는 속도 해킹(Speed Hack)을 넣지 마라.

그리고 규칙 2.

규칙 2 (계측하라): 계측하기 전까지는 튜닝하지 마라. 계측한 후라도 특정 부분이 다른 부분을 압도적으로 상회하지 않는 한, 손대지 마라.

여기서 말하는 병목 지점 (Bottleneck) 이라는 것은 교통 체증의 선두와 같습니다. 길 전체가 막히는 것처럼 보여도, 실제로 막히게 만드는 원인은 대개 한 곳의 교차로인 경우가 많습니다. 그곳을 고치지 않고 다른 도로를 넓혀봤자 정체는 1mm도 해소되지 않습니다. 코드도 마찬가지로, 체감상 "여기가 무겁겠지"라고 생각한 곳은 대개 틀립니다. 이것이 프로그래밍의 조금 무서운 점입니다.

"아니, 최신 AI라면 제대로 빠르게 만들어주겠지"라고 생각하고 싶으실 겁니다. 하지만 여기서는 사실을 제대로 확인해 둘 필요가 있습니다.

2025년에 나온 SWE-Perf라는 연구가 있습니다. 제목 자체가 질문인데, "Can Language Models Optimize Code Performance on Real-World Repositories? (언어 모델은 실재 리포지토리의 코드 성능을 최적화할 수 있는가?)"입니다. 실제 GitHub 리포지토리의 "성능 개선 풀 리퀘스트 (Pull Request)"를 통해 만든 140건의 과제로 AI를 평가했습니다.

결론을 말씀드리자면, **"기존 LLM과 전문가 수준의 최적화 사이에는 큰 능력 차이 (Substantial Capability Gap)가 존재한다"**는 것입니다. AI는 코드 생성이나 버그 수정은 능숙해졌지만, 현실의 코드를 빠르게 만드는 작업에서는 아직 인간 전문가에게 상당히 미치지 못한다는 것이죠.

또 하나, 2025년 소프트웨어 공학 국제 컨퍼런스에서 발표된 **「When Faster Isn't Greener (빠르다고 해서 반드시 친환경적인 것은 아니다)」**라는 연구가 있습니다. 여러 AI 모델로 118건의 최적화 태스크를 조사한 결과, **"최적화 과정에서 종종 '잘못된 코드'나 '오히려 더 느린 코드'가 생성되었다"**고 보고되었습니다. 나아가 성능 향상과 실제 에너지 절약 사이에는 약한 음의 상관관계조차 있었다고 합니다.

즉, AI가 내놓는 "빠르게 만들었습니다"를 계측 없이 믿는 것은 위험하다는 뜻입니다. 이것은 딱히 AI를 비난하는 것이 아닙니다. 업계의 컨센서스(Consensus)도 이와 같습니다.

AI의 가장 현실적인 역할은 "성능 어시스턴트(Performance Assistant)"입니다. 최적화 안을 제안해 줍니다. 하지만 인간이 그것을 비판적으로 평가하고, 벤치마크(Benchmark)로 측정하며, 검증한 뒤에 도입해야 합니다.

요컨대, 판단은 인간, 제안과 작업은 AI. 이 역할 분담을 벗어나면 사고가 난다는 뜻입니다.

두 가지만 더, 오래된 격언을 덧붙이겠습니다. 오래되었지만 AI 시대에야말로 효과적입니다.

하나는 Donald Knuth의 매우 유명한 말입니다.

"조기 최적화는 모든 악의 근원이다 (Premature optimization is the root of all evil)"

사소한 효율성에 대한 이야기는 97%의 경우 무시해도 좋습니다. 하지만 나머지 "critical 3%"의 기회는 놓치지 말라는 이야기입니다. 즉, 무턱대고 전부 빠르게 만들려고 하지 마세요. 정말 효과가 있는 곳을 계측(Profiling)을 통해 찾아낸 뒤에 실행하라는 뜻입니다.

또 하나는 **암달의 법칙 (Amdahl's Law)**입니다. 이것은 매우 중요한데, 한 마디로 요약하자면 "전체에서 차지하는 비중이 작은 부분을 아무리 빠르게 만들어도, 전체 속도는 크게 변하지 않는다"는 것입니다.

구체적으로 들어가 봅시다. 어떤 처리 과정이 전체 실행 시간의 **5%**만을 차지한다고 가정해 보겠습니다. 그 부분을 만약 "순식간에(무한히 빠르게)" 처리할 수 있게 만든다 해도, 전체 시간은 최대 약 5%밖에 줄어들지 않습니다. 100초 걸리던 처리가 95초가 될 뿐입니다. 나머지 95%는 건드리지 않았으니 당연한 결과겠죠.

그런데도 우리는 자꾸 "내가 고치기 쉬운 곳"이나 "코드가 지저분해서 신경 쓰이는 곳"을 최적화하고 싶어 합니다. 하지만 그 부분이 전체의 5%라면, 아무리 노력해도 5%일 뿐입니다. "고치기 쉬운 곳"과 "고칠 가치가 있는 곳"은 전혀 다릅니다. 이 둘을 혼동하는 것이 소모적인 작업의 가장 큰 원인이라고 생각합니다.

여기서 용어를 한 번 정리하겠습니다. 이미 알고 계신 분들은 넘어가셔도 좋습니다. 하지만 "어렴풋이만 알고 있는" 상태라면 AI에게 지시를 내릴 때도 모호해질 수 있으므로, 빠르게 맞춰두도록 하겠습니다.

프로파일링 (Profiling): 프로그램을 실행하여 "어떤 함수에 얼마나 시간이 걸렸는지"를 실측하는 것. 말하자면 코드의 건강검진입니다. 몸 상태가 좋지 않을 때, 자기 진단(추측)이 아니라 제대로 된 검사 수치를 확인하는 것과 같습니다. -
프로파일러 (Profiler): 그 건강검진을 수행해 주는 도구. Python이라면 cProfile이나 py-spy, Node.js라면 --prof나 Chrome DevTools, 브라우저라면 Performance 탭과 같이 언어마다 준비되어 있습니다. -
병목 지점 (Bottleneck): 앞서 말한 정체의 선두. 전체를 느리게 만드는 가장 큰 원인이 되는 지점. -
핫 패스 (Hot path): 자주 지나가는 길. 반복적으로 실행되는 처리의 중심 경로. 이곳이 느리면 전체 성능에 영향을 줍니다. -
레이턴시 (Latency) 와 스루풋 (Throughput): 레이턴시는 "건당 대기 시간"(주문 후 음식이 나올 때까지의 시간)입니다. 스루풋은 "단위 시간당 얼마나 처리할 수 있는가"(1시간에 몇 명을 응대할 수 있는가)입니다. 무엇을 빠르게 만들고 싶은지에 따라 대응 방법이 달라집니다. -
Big-O (계산 복잡도): 데이터 양이 늘어날 때 처리 시간이 어떤 식으로 증가하는지를 나타내는 대략적인 표현입니다. O(n)은 "데이터가 10배면 시간도 약 10배", O(n²)은 "데이터가 10배면 시간은 약 100배"를 의미합니다. 소규모 데이터에서는 차이가 보이지 않다가, 실서비스에서 데이터가 늘어나는 순간 폭발하는 것이 이 녀석의 무서운 점입니다. -
p50 / p99: 측정값을 작은 순서대로 나열했을 때의 중간값(p50)과, 나쁜 쪽에서 상위 1%에 해당하는 라인(p99)입니다. 평균값만 보고 있으면 가끔 엄청나게 느린 "불운한 고객"을 놓치게 되므로, p99와 같은 "나쁜 쪽"의 수치도 확인하는 것이 중요합니다. -
벤치마크 (Benchmark): "동일한 조건에서 공정하게 시간을 측정하는 것"입니다. 이것이 없으면 "빨라진 것 같다"는 느낌에서 끝나버리고 맙니다.

이 중에서 딱 하나만 가져가신다면, **"빠르다/느리다는 '감각'이 아니라 '숫자'로 말한다"**는 것입니다. 이것만 지켜도 이미 절반은 이긴 것이나 다름없습니다.

기다리셨습니다. 이제 본론입니다. 성능 개선은 다음의 흐름을 반복하는 것뿐입니다. 저는 이것을 **계측 주도 루프 (Measurement-driven loop)**라고 부릅니다.

베이스라인(Baseline) 측정하기 — "지금 얼마나 느린가"를 숫자로 파악합니다. 이것이 기준점이 됩니다. 기준이 없으면 "빨라졌다"고 말할 수 없습니다. -
프로파일링으로 병목 지점(Bottleneck) 특정하기 — 건강검진을 통해 가장 시간을 많이 잡아먹는 함수(핫 패스)를 찾습니다. 체감으로 결정하지 마세요. -
왜 느린지 가설 세우기 — Big-O 관점에서 무거운가? 불필요한 재계산이 있는가? 같은 데이터를 여러 번 읽고 있는가? 이때 AI에게 후보를 뽑아달라고 하면 빠릅니다. -
딱 하나만 바꾸기 — 이 부분이 매우 중요합니다. 동시에 두 가지를 바꾸면 무엇 때문에 효과가 나타났는지 알 수 없게 됩니다. 하나를 바꾸고 그 효과를 확인합니다. 이 과정을 반복합니다. -
재측정하기 — 정말 빨라졌는가? 동시에 정확성은 유지되고 있는가? 다른 곳이 느려지지는 않았는가(퇴행, Regression)? 여기까지 마쳐야 비로소 "개선했다"라고 말할 수 있습니다. -
기록하기 — 무엇을 어떻게 측정했고 얼마나 빨라졌는지를 남깁니다. 이것이 나중에 큰 도움이 됩니다(나중에 다시 다루겠습니다).

그리고 루프에 들어가기 전, 한 가지. 암달의 법칙(Amdahl's Law)을 떠올리며 「이 부분이 전체의 몇 %인가」를 먼저 추정하십시오. 전체의 3%밖에 안 되는 부분을 필사적으로 다듬는다면, 20%를 차지하는 부분을 조금 개선하는 것이 훨씬 효과적입니다. 어디를 공략할지에 대한 "지도"를 가진 상태에서 달리는 것. 이것이 소모되지 않는 비결입니다.

"뭐야, 당연한 거 아냐?"라고 생각할지도 모릅니다. 하지만 막상 코드를 마주하면, 사람들은 이 순서를 건너뛰고 곧바로 단계 4(재작성)부터 시작해 버립니다. AI에게 통째로 맡기면 더욱더 단계 4만 고속으로 회전하게 됩니다. 느린 코드가 빠른 속도로 양산되는 것입니다. 이것은 정말 아까운 일이죠.

"계측이 중요하다는 건 알겠어. 그럼 AI는 필요 없잖아"라고 되지 않습니다. 오히려 반대로, 이 루프의 각 단계를 가속하는 파트너로서 AI는 매우 우수합니다. 중요한 것은, 인간이 쥐어야 할 부분(What / Why)과 AI에게 맡길 부분(How)을 나누는 것입니다.

공정	인간이 결정함 (What / Why)	AI에게 맡김 (How)
베이스라인 계측	무엇을 "빠르다"고 할 것인가 (목표치·p99)	계측 스크립트 작성
...

포인트는 AI에게 "판단"을 시키지 않는 것입니다. "어디를 최적화해야 할까?"라고 묻는 것은 좋지만, 그 답을 맹신하여 바로 실전에 적용하지 마십시오. 앞서 언급한 연구처럼, AI의 "빨라질 것입니다"라는 말은 꽤 빗나갑니다. AI는 "후보를 대량으로 제시하기", "읽기 힘든 프로파일(Profile)을 요약하기", "공정한 벤치마크(Benchmark) 코드 작성하기"에 능숙합니다. 인간은 나온 후보를 계측을 통해 선별합니다. 이 분담이 가장 사고가 적은 방식입니다.

여기서부터는 내일 업무에서 바로 복사해서 사용할 수 있는 프롬프트를 남겨두겠습니다. 공통적인 요령은 **"수정 코드를 갑자기 쓰게 하지 않는 것"**입니다. 먼저 독해와 분석만 시키고, 인간이 방침을 결정한 뒤에 구현으로 넘어갑니다. 이것만으로도 짐작에 의존한 수정이 눈에 띄게 줄어듭니다.

당신은 성능 분석 어시스턴트입니다. 다음은 cProfile의 출력 결과입니다.
다음 형식으로 답해 주세요. 수정 코드는 아직 작성하지 마세요.
1. 누적 시간(Cumulative time)이 긴 상위 3개 함수 (함수명 / 전체에서 차지하는 대략적인 비율 / 호출 횟수)
...

"추측은 추측이라고 명시해"라고 제약을 거는 것이 핵심입니다. AI는 질문을 받으면 자신만만하게 단정 짓는 경향이 있으므로, 근거와 추측을 분리하게 만듭니다. 이는 모르는 코드를 읽을 때의 "그라운딩(Grounding, 근거 제시)"과 같은 발상입니다.

다음 두 함수 before / after의 실행 시간을 공정하게 비교하는 벤치마크를 작성해 주세요.
조건:
- 계측 전에 워밍업(Warm-up)을 몇 차례 수행할 것 (처음 몇 번은 느리므로 제외)
...

**"평균이 아니라 중앙값(Median)과 p95"**를 지정하는 것이 중요합니다. 평균은 우연히 느렸던 한 번의 결과에 휘둘릴 수 있습니다. 중앙값과 p99/p95를 보면 실제 사용자 경험에 가까운 수치를 얻을 수 있습니다. 또한, 합성 데이터(Synthetic data)를 사용하게 하는 것은 안전을 위해서입니다(나중에 다루겠습니다).

다음은 "고속화를 위해" 제안된 패치입니다. 반영하기 전에 비판적으로 리뷰해 주세요.
관점:
- 정확성: 원래 코드와 동작이 달라지는 입력값이 있는가? (구체적인 에지 케이스(Edge case)를 제시할 것)
...

자신이 작성한 코드라도 다른 AI에게 "비판적으로 리뷰해 줘"라고 부탁하면 꽤 많은 허점이 발견됩니다. "빨라지는 대신 무엇을 잃게 되는가"를 반드시 물으십시오. 속도만 보고 가독성을 죽여버리면, 내일의 자신이 눈물을 흘릴 테니까요.

(덤) "이것이 알고리즘의 문제인가, 상수 배(Constant factor)의 문제인가"를 구분하고 싶을 때는 이렇게 물으면 빠릅니다.

이 코드가 느린 주된 원인이 "알고리즘적(데이터 규모가 커지면 급격히 악화)"인가요, 아니면 "상수 배(매번 조금씩 느릴 뿐)\

나온 표의 `cumtime`

(해당 함수와 그 안에서 호출된 처리의 합계 시간)이 긴 순서대로 상위에 있는 것이 당신의 “정체의 선두” 후보입니다. **이 출력을 아까의 프롬프트 1에 그대로 붙여넣으면**, AI가 독해를 도와줍니다.

「빨라진 것 같다」를 숫자로 바꿉니다. 포인트는 웜업 (Warm-up)과, 평균이 아닌 중앙값(Median)·p95.

import time
import statistics
def benchmark(fn, *, warmup=3, repeat=30):
...

이렇게 하면 「중앙값이 42ms → 11ms (−74%)」와 같이 당당하게 숫자로 말할 수 있게 됩니다. 반대로 「생각보다 변하지 않았다」는 것을 알게 되는 경우도 많은데, 그것 또한 훌륭한 수확입니다. **“효과가 없었다”는 것을 아는 것도 계측 (Profiling)의 가치**입니다.

Rob Pike의 규칙 5, 「데이터가 지배한다」. 많은 “느린 것”은 복잡한 최적화가 아니라, 데이터 구조를 하나 바꾸는 것만으로 해결됩니다. 고전적인 방법을 말이죠.

```python
# Before: 리스트 (List)에 대한 「in」은 매번 처음부터 순서대로 탐색한다 (요소 수 n에 비례 = O(n)).
# 그것을 루프 (Loop) 안에서 돌리면 전체는 O(n * m)이 된다. 데이터가 늘어나는 순간 급격히 무거워진다.
def find_new_users(all_users, known_ids): # known_ids가 list라면…
...

all_users가 10만 건, known_ids가 5만 건 있다면, Before와 After의 체감이 완전히 달라집니다. 게다가 After 쪽이 더 짧고 읽기 쉽습니다. 속도와 가독성이 양립하는 것이 이런 “올바른 최적화”의 즐거운 점입니다. (주의: known_ids가 이미 set이라면 이 최적화는 효과가 없습니다. 그래서 「측정부터」 해야 하는 것입니다.)

마지막으로, 가장 수수하지만 가장 효과적인 것. 어렵게 빠르게 만들어 놓아도, 반년 뒤에 누군가(미래의 자신일지도 모릅니다)가 실수로 느린 코드로 되돌려 놓을 수 있습니다. 그것을 방지하는 것이 성능 퇴행 (Regression)을 CI에서 감시하는 메커니즘입니다.

# tests/perf/test_hot_path.py
def test_find_new_users_perf(benchmark): # pytest-benchmark의 fixture
users = [{"id": i} for i in range(100_000)]
...

# .github/workflows/perf-guard.yml
name: perf-guard
on: [pull_request]
...

이렇게 하면 누군가 성능을 악화시키면 PR (Pull Request) 단계에서 알아챌 수 있습니다. 주의할 점은 CI 머신은 실행할 때마다 속도가 흔들리기(Fluctuation) 때문에, 절대 시간이 아니라 「베이스라인 (Baseline)과의 비율」로 보고, 임계값(여기서는 25%)에 여유를 두는 것이 요령입니다. 신경질적으로 1% 차이에 반응하면, 변동성 때문에 오탐지(False Positive)가 발생하여 모두가 이를 '양치기 소년' 취급하며 무시하게 됩니다.

이론은 알아도 무심코 저지르는 실수들을 여기에 정리해 둡니다.

#	함정	대처법
1	계측 없이 최적화를 시작함	우선 베이스라인을 잡는다. 기준이 없으면 「빨라졌다」고 말할 수 없다
2	병목 지점(Bottleneck)이 아닌 곳을 다듬음 (암달의 법칙(Amdahl's Law) 무시)	「고치기 쉬운 곳」이 아니라 「전체에 영향을 주는 곳」부터. 비율을 먼저 추정한다
3	AI의 「빨라집니다」를 계측 없이 믿음	연구에서도 “틀림·오히려 느려짐”이 빈번함. 반드시 재계측으로 확인한다
4	동시에 여러 변경 사항을 넣음	무엇이 효과가 있었는지 알 수 없게 됨. 하나를 바꾸고, 측정하는 과정을 반복한다
5	마이크로 벤치마크 (Micro-benchmark)만으로 만족함	실제 운영 환경의 데이터 규모·분포·p99를 간과함. 실제 운용에 가까운 조건에서 측정한다
6	가독성이나 정확성을 희생하며 빠르게 만듦	빨라져도 망가지면 의미 없음. 리뷰에서 「무엇을 잃게 되는지」를 반드시 확인한다

그리고, 되돌아갈 라인 (철수 기준) 도 미리 정해 둡시다. 이것은 「그만두는 판단」을 감정이 아니라 규칙으로 하기 위한 선입니다.

• 계측해도 효과가 한계에 다다랐다 → 거기서 멈춘다. 완벽을 노리지 않는다.
• 개선의 이득보다 망가뜨릴 리스크(복잡화·버그)가 더 크다 → 원래대로 되돌린다.
• 되돌리기 어려운 변경(후술)을 시도하려 한다 → 인간의 승인을 얻을 때까지 진행하지 않는다.

「빠르게 만드는 것」 자체가 목적이 되면 늪에 빠집니다. 목적은 “사용자 경험이나 비용을 개선하는 것”이며, 최적화는 그 수단입니다. 이 점을 놓치지 않도록 해야겠습니다.

성능 개선은 일반적인 코드 수정보다 "실제 운영 환경(Production)에 가까운 부분"을 건드리는 경향이 있으므로, 마지막으로 안전 가이드라인을 정하겠습니다. 이 부분은 절대 생략해서는 안 됩니다.

운영 환경에서의 프로파일링(Profiling)은 원칙적으로 승인 절차를 거쳐야 합니다. 프로파일러는 오버헤드(Overhead, 측정 자체의 부하)를 발생시킬 수 있으며, 운영 환경에 부하를 주거나 서비스를 불안정하게 만들 수 있습니다. 실행한다면 영향이 적은 기법을 선택하고, 반드시 사람의 승인 하에 진행하십시오. -
에러 로그나 프로파일 출력 결과를 그대로 AI에게 붙여넣지 마세요. 여기에 실제 사용자의 데이터, 개인정보(PII), 토큰이나 API 키와 같은 비밀 정보(Secret)가 섞여 있는 경우가 매우 빈번합니다. 외부 서비스에 붙여넣은 정보는 삭제하더라도 남는다고 생각하는 것이 좋습니다. 벤치마크에 사용할 데이터는 합성 데이터(Synthetic Data, 더미 데이터)로 교체하십시오. 프롬프트 2에서 "실제 데이터나 PII를 사용하지 말 것"이라고 제한한 이유도 바로 이것 때문입니다. -
되돌리기 어려운 최적화는 반드시 사람이 승인해야 합니다. 예를 들어 캐시 계층(Cache Layer) 추가, DB 인덱스(Index) 변경, 데이터 구조의 스키마(Schema) 변경, 인프라 구성 변경 등이 있습니다. 이러한 작업들은 "속도는 빨라졌지만 다른 문제가 발생하여 즉시 되돌릴 수 없는" 상황을 초래하기 쉽습니다. 되돌리기 어려운 작업(운영 DB, 결제, 삭제, 공개, 배포 등)은 AI에게 자동 실행하게 하지 말고, 반드시 사람의 게이트(Gate)를 통과하게 하십시오. -
AI에게 전달하는 외부 유래 텍스트는 "데이터"로 취급하십시오. 프로파일 출력이나 로그에 섞여 있는 문자열을 지시 사항(Instruction)으로 실행하지 않도록 주의해야 합니다.

이 규칙들만 지켜도 "속도를 높이려다 더 큰 사고를 내는" 가장 슬픈 패턴을 피할 수 있습니다.

여기까지 읽어주셔서 감사합니다. 마지막으로, 조금 거시적인 이야기를 해볼까 합니다.

성능 개선이라고 하면 왠지 "할 줄 아는 사람만의 장인 기술" 같은 이미지가 있잖아요? 하지만 지금까지 살펴본 것처럼, 그 정체는 **"추측을 멈추고, 증거(숫자)로 움직이는 것"**이라는 매우 단순한 태도입니다. 측정하고, 병목 지점(Bottleneck)을 특정하고, 하나를 바꾸고, 다시 측정하는 것. AI는 그 각 단계를 엄청나게 가속해 줍니다. 하지만 "어디를 공략할지", "무엇을 포기해도 될지"를 결정하는 것은 마지막까지 사람의 몫입니다.

그리고 오늘 기록한 측정 데이터와 벤치마크는, 미래의 나에게 보내는 편지와 같습니다.

저는 요즘 무언가를 판단할 때 "내일의 내가 오늘의 나에게 '고마워(아자스)'라고 말해줄까?"라고 생각하곤 합니다. 성능 개선의 관점에서 말하자면——

"제대로 측정하고 나서 고쳐준 데다, 퇴행 방지(Regression Guard)까지 마련해 둬서 반년 뒤에 성능 저하(Degradation) 없이 지나갈 수 있었어. 고마워."

아마 이렇게 말해줄 것입니다. 반대로, 측정도 없이 짐작만으로 코드를 고쳐서 무엇이 효과가 있었는지 알 수 없는 코드를 남겨둔다면, 내일의 나는 "이게 뭐야..."라며 머리를 싸매게 될 것입니다. 비난의 축이 아니라, 배려의 축으로 접근하세요. 미래의 나에게 선물을 준다는 마음으로, 오늘 조금만 더 측정해 두는 것입니다.

게다가, "측정하여 판단하는 능력"은 AI에게 빼앗기지 않고 쌓여가는 자산이라고 생각합니다. AI가 코드를 아무리 빠르게 작성할 수 있게 되더라도, "어디를, 왜, 어디까지 빠르게 만들어야 하는가"를 측정하고 결정하는 능력은 자신 안에 계속 남을 것입니다. What과 Why는 인간이, How는 AI가 담당합니다. 이 분업을 통해 쌓아 올린 것은 온전히 자신의 재산이 됩니다.

마지막으로, 내일부터 시작할 첫걸음을 아주 작게 만들어 두겠습니다.

지금 "왠지 좀 느린데"라고 생각되는 처리 중 딱 한 곳만, time이나 cProfile로 측정해 보세요. 그것뿐입니다. 코드를 고칠 필요도, 수정할 필요도 없습니다. 우선 숫자 하나를 갖는 것부터 시작하세요.

그것만으로도 내일의 나는 "고마워"라고 말해줄 것 같습니다. 그럼, 다음에 또 뵙겠습니다.