코드플래시 분석: 클로드 코드로 작성된 두 개의 PR에서 118개의 성능 버그 발견

AI 생성 코드의 성능 분석

Codeflash는 Claude Code로 작성된 두 개의 풀 리퀘스트를 분석하기 위해 자체 최적화 도구를 사용했습니다. 분석된 기능은 Java 언어 지원(파서, 컨텍스트 추출기, 계측, 테스트 러너, 어설션 변환기 등 52,000줄)과 React 프레임워크 지원(컴포넌트 탐지, 프로파일링, 벤치마킹, 코드 교체를 포함한 24,000줄)이었습니다.

주요 발견 사항

이 두 PR만 살펴봐도 Codeflash는 필요 이상으로 상당히 느리게 수행되는 118개의 함수를 식별했습니다. 이들은 변두리 사례가 아닙니다 — 모든 사용자의 모든 최적화 작업에서 실행되는 핫 패스에 있는 함수들이었습니다.

비효율성 패턴

• 치명적으로 비효율적인 알고리즘: Java 컨텍스트 모듈의 타입 추출 함수는 트리-시터 기반 추출 대신 순진한 문자열 스캐닝으로 구현되어 필요보다 446배 느렸습니다. 도우미 함수 파인더도 비슷한 이유로 74배 느렸습니다.
• 중복 계산: 함수들은 이미 파싱된 데이터를 다시 파싱하고, 이미 탐색한 트리를 다시 순회하며, 문자열을 문자별로 다시 구축했습니다. 어설션 타겟 호출 빌더는 캐싱하지 않고 모든 호출에서 소스 바이트 변환을 재계산하여 19배 느렸습니다. React PR의 임포트 삽입 유틸리티는 중복 트리 순회로 인해 36배 느렸습니다.
• 캐싱 누락: 동일한 입력으로 반복 호출되는 함수들은 매번 처음부터 결과를 계산했습니다. React PR의 타입 정의 추출기는 중간 결과를 메모이제이션하지 않아 16배 느렸고, 익스포트 체커도 같은 이유로 9배 느렸습니다.
• 최적화되지 않은 데이터 구조: 집합이어야 할 곳에 리스트를 사용하고, 해시 조회가 가능한 곳에 선형 검색을 수행하며, 루프에서 문자열 연결 대신 조인을 사용하지 않았습니다. 중괄호 균형 파서는 비효율적인 데이터 구조 선택으로 인해 3배 느렸습니다.

구체적인 예시: 19배 성능 향상

Claude Code는 바이트 오프셋을 문자 위치로 변환하기 위해 이 함수를 작성했습니다:

# 파일에서 발견된 모든 AST 노드에 대해 호출됨
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

Codeflash는 이를 다음과 같이 교체했습니다:

# 룩업 테이블을 한 번 구축한 후, 모든 노드에 대해 이진 검색 수행
from bisect import bisect_right
cum_bytes = [0]
for ch in source.decode("utf8"):
    cum_bytes.append(cum_bytes[-1] + len(ch.encode("utf8")))
start_char = bisect_right(cum_bytes, start_byte) - 1
end_char = bisect_right(cum_bytes, end_byte) - 1

원본 코드는 모든 호출에서 파일 시작부터 전체 바이트 접두사를 디코딩합니다 — O(n) per lookup. 수백 개의 AST 노드가 있는 파일의 경우, 이는 동일한 바이트를 수백 번 다시 디코딩한다는 의미입니다. 최적화된 버전은 룩업 테이블을 한 번 구축하고 이진 검색을 사용합니다 — O(n) once, then O(log n) per lookup.

이 기사는 AI 코딩 에이전트 사용 여부에 관한 것이 아니라(사용을 권장합니다), 사용한 후 코드에 어떤 일이 발생하는지에 관한 것임을 강조합니다. 이러한 성능 문제는 정확성과 가독성에 집중하고 성능 최적화를 소홀히 함으로써 AI 에이전트가 체계적으로 도입하는 새로운 범주의 기술 부채를 나타냅니다.