스캐너는 성능 안티 패턴 (anti-patterns) — 중첩 루프, 루프 내 문자열 생성, N+1 쿼리 형태 등을 찾아냅니다. 하지만 스캐너는 실제 병목 현상 (bottleneck)을 알려줄 수는 없습니다. 왜냐하면 핫스팟 (hotspot)은 소스 코드의 형태가 아니라, 실행 중인 워크로드 (workload)의 측정된 속성이기 때문입니다. BrassCoders는 패턴을 찾아내지만, 프로그램이 실제로 어디에서 시간을 소비하는지 찾아내는 것은 프로파일러 (profiler)의 역할입니다. 이는 스캐너가 답할 수 없는 질문에 대해 스캔 결과만을 신뢰하기 전에 명확히 살펴볼 가치가 있는 또 하나의 경계선입니다.

여러분이 상상하는 느린 코드와 실제로 비용을 발생시키고 있는 느린 코드는 대개 서로 다른 줄이며, 그중 하나만이 스캐너가 볼 수 있는 형태를 가지고 있습니다.

성능 스캐너가 찾아내는 것

BrassCoders는 성능 안티 패턴 (anti-patterns) — 즉, '종종' 느려지는 구조적 형태를 찾아냅니다: 루프 안에 중첩된 루프, 루프 내에서의 += 문자열 생성, 배치 (batch) 단위가 아닌 행(row)당 한 번씩 실행되는 쿼리 등이 이에 해당합니다. 이러한 것들은 형태를 가지고 있으므로, 매 실행 시 동일한 방식으로 규칙에 매칭됩니다. AI 어시스턴트들은 이러한 코드를 정기적으로 생성하며, 이를 제거하는 것은 실질적인 가치가 있습니다.

안티 패턴은 위험 지표 (risk indicator)이지, 측정값이 아닙니다. 이중 중첩 루프는 이론적으로는 이차 시간 복잡도 (quadratic)를 가지지만, 요소가 5개 미만일 때는 실제 실행 시 비용이 거의 들지 않습니다. 스캐너가 그 형태를 찾아내는 이유는 그 형태가 느려질 수 있기 때문이지, 여러분의 데이터에서 실제로 느린지는 소스 코드만으로는 답할 수 없는 별개의 문제입니다.

병목 현상이 패턴에 있지 않은 이유

BrassCoders는 정적 소스 (static source)를 읽지만, 병목 현상 (bottleneck)은 런타임 (runtime)의 사실입니다. 이는 데이터의 크기, 코드가 실행되는 빈도, 그리고 I/O를 기다리는 시간에 따라 달라집니다. 실제 프로그램에서의 핫스팟 (hotspot)은 안티 패턴 규칙이 잡아내지 못하는 줄인 경우가 많습니다: 핫 패스 (hot path)에서의 단일 데이터베이스 라운드 트립 (round-trip), 백만 번 호출되는 JSON 파싱 (parse), 혹은 아주 조금 길게 유지되는 락 (lock) 등이 그 예입니다.

그것이 바로 프로파일링 (profiling)이 선택이 아닌 필수인 이유인 괴리 (divergence)입니다. 5개의 항목이 담긴 리스트를 순회하는 플래그가 지정된 중첩 루프 (nested loop)는 노이즈에 불과하지만, 플래그가 지정되지 않은 요청 핸들러 (request handler) 내부의 requests.get은 전체 지연 시간 예산 (latency budget) 그 자체입니다. 스캐너는 '형태 (shape)'에 따라 순위를 매기지만, 프로덕션 (production)은 '측정된 시간 (measured time)'에 따라 순위를 매깁니다. 이 두 가지 정렬 방식은 일상적으로 불일치하며, 오직 두 번째 방식만이 사용자가 실제로 느끼는 것입니다.

측정이 일어나는 곳

실제 병목 현상 (bottleneck)을 찾아내는 도구들은 실행 중인 프로그램을 측정합니다. py-spy는 오버헤드 (overhead)가 거의 없이 라이브 Python 프로세스를 샘플링 (sampling)하여 실제 경과 시간 (wall-clock time)이 어디에 소요되는지 보여줍니다. Scalene은 CPU와 메모리를 함께 프로파일링 (profiling)하며 비용을 라인 단위로 할당합니다. 표준 라이브러리의 cProfile은 호출 횟수 (call counts)와 누적 시간 (cumulative time)을 기록합니다. 각 도구는 정적 스캔 (static scan)이 할 수 없는 유일한 일인, '실제로 작업을 수행 중인' 프로그램을 관찰합니다.

BrassCoders는 이러한 도구들을 대체하려 하기보다, 자체적인 성능 안티 패턴 연구 (performance-anti-patterns research)를 통해 이들을 지목합니다. 스캐너와 프로파일러는 서로 다른 질문에 답합니다. 즉, "이 형태가 위험한가" 대 "시간이 실제로 어디로 가는가"의 차이이며, 워크플로우 (workflow)에는 두 가지 답변이 모두 필요합니다.

두 계층이 조화되는 방식

BrassCoders는 구조적 안티 패턴 (structural anti-patterns)을 정적으로 제거하여, 이들이 코드베이스 (codebase)에 남아 실제 핫스팟 (hotspot)을 가리지 않도록 하며, 프로파일러는 부하 (load) 상황에서 시간이 실제로 어디에 소요되는지 측정합니다. 스캔을 실행하면 실수로 작성된 이차 시간 복잡도 (accidentally-quadratic) 루프와 루프 내 문자열 빌드 (string builds)가 배포되기 전에 플래그가 지정됩니다. 프로파일러를 실행하면 어떤 라인이 실제로 몇 초의 시간을 잡아먹고 있는지 알 수 있습니다.

형태가 존재하는 곳은 결정론적 (deterministic)으로 파악하고, 존재하지 않는 곳은 측정 (measured)을 통해 파악합니다. 스캐너는 결코 여러분의 워크로드 (workload)를 프로파일링했다고 주장하지 않습니다. 왜냐하면 스캐너는 워크로드를 실행한 적이 없기 때문입니다. 측정하지 않은 병목 현상을 보고하는 도구는 가장 중요한 수치를 추측하고 있는 것에 불과할 것입니다.

pip install brasscoders
brasscoders --offline scan /path/to/your/project

스캔은 형태(shape)를 가진 안티 패턴(anti-pattern)을 잡아냅니다. 형태가 없는 병목 현상(bottleneck)을 찾아내는 것은 프로파일러(profiler)의 역할이며, 어떤 질문을 던지고 있는지 아는 것이 속도 향상의 절반을 차지합니다.