"초는 거짓말해. 네 노트북, 배터리, Spotify 켜져 있는지에 따라 달라져. 단계는 진실을 말하고."
스톱워치의 문제
본능은 비용을 초로 재는 거야: 돌리고, 시간 재고, 끝. 근데 초는 끔찍한 자야. 같은 코드가 더 새 칩에선 빠르고, 배터리 절약 모드에선 느리고, 브라우저 탭 마흔 개가 메모리 두고 싸우면 또 느려. 월요일이랑 금요일에 재면 동일한 코드인데 다른 숫자가 나와. 알고리즘은 아무것도 안 바뀌었는데 측정값이 바뀌면, 그건 알고리즘이 아니라 기계를 재는 거야.
그래서 시계를 버리고 하드웨어가 속일 수 없는 걸 세: 알고리즘이 입력 크기의 함수로 몇 단계를 밟는지. 입력 크기를 n 이라 하자. 리스트 한 번 훑기는 대략 n 단계. 중첩 훑기는 대략 n × n. 그 수는 네 칩이나 배터리에 신경 안 써 — 레시피 자체의 속성이야.
모양이 속도를 이긴다
처음엔 틀린 것처럼 느껴지는 부분: 좋은 알고리즘 돌리는 느린 컴퓨터가 나쁜 알고리즘 돌리는 빠른 컴퓨터를 이겨, 입력이 충분히 크기만 하면. n² 단계를 밟는 번개 같은 기계가 n 단계 밟는 굼뜬 기계한테 져 — 작은 n 에선 아니지만, 교차점은 늘 오고, 그 뒤로 격차는 벌어지기만 해. 성장의 모양 (입력을 두 배 하면 일이 두 배냐, 네 배냐?) 이 데이터가 진짜로 커지면 나머지 전부를 지배해.
그래서 "그냥 더 빠른 서버 사" 가 함정이야. 빠른 하드웨어는 선을 조금 위로 올려; 더 나은 알고리즘은 선의 기울기를 바꿔. 나쁜 기울기를 하드웨어로 영원히 이길 순 없어.
상수의 함정
입문자는 상수 깎는 걸 좋아해 — "반복문 둘을 합쳐서 2배 빠르게 했어!" 가끔은 그게 중요해. 근데 밑바탕 모양이 n² 이면, 상수를 깎는 건 벽에 부딪히는 걸 미룰 뿐 벽을 옮기진 않아. 모양을 먼저 고치고 (이걸 n² 대신 n 으로 할 수 있나?), 그다음에야 상수에 땀 흘려. Complexity 트랙에서 이걸 엄밀하게 만들 거야 — 이 lesson 은 그 반사신경만 심어.