강한 타입은 코딩 에이전트를 더 빠르게 만들지 않았다

세 가지 코딩 에이전트가 두 프로젝트에서 수행한 766회 실행을 분석한 사례 연구에서, 타입 표기는 에이전트의 정확도나 속도, 토큰 사용량을 눈에 띄게 개선하지 않았다. 다만 에이전트에게 타입 검사기 mypy를 사용하게 하면 타입 오류가 포함된 변경을 막을 수 있었다.

실험은 billing 구독 결제 엔진과 오픈소스 취약점 데이터 도구 vunnel을 대상으로 했다. 실험용 코드에는 타입이 없는 버전, 일부 타입만 적은 버전, 설명적인 이름과 문서 문자열을 쓴 버전, 엄격한 타입을 적용한 버전 등이 포함됐다. 타입 적용 버전에는 mypy를 안내한 조건과 타입을 검사하지 않는 린터 ruff를 안내한 조건도 뒀다. 모델은 Claude Sonnet과 Claude Haiku를 Claude Code 2.1.306으로, gpt-6-sol을 Codex CLI 0.162.1로 실행했다.

티켓 형태의 작업 16개, 자동으로 심은 버그 20개, vunnel의 변경 작업 5개를 테스트했다. 각 작업은 코드 버전별로 2~3회 실행했고, 측정값을 평균 냈다. 대부분의 실행은 타입 유무와 관계없이 정답을 내거나 회귀 없이 숨은 테스트를 통과했다. 타입을 넣어도 토큰 사용량과 작업 시간은 대체로 비슷했고, 일부 경우에는 오히려 나빠졌다. 설명적인 이름이나 일부 타입만 적용한 조건도 비슷한 결과를 보였다.

차이를 만든 것은 타입 자체가 아니라 검사기를 사용하게 한 조건이었다. 에이전트는 mypy가 있다고 안내받으면 거의 모든 변경에 실행했다. ruff도 비슷한 빈도로 실행했지만 타입 오류는 잡지 못했다. 검사기가 없을 때는 타입을 적용한 코드에 Sonnet 변경의 약 10분의 1, Codex 변경의 약 20분의 1에서 타입 오류가 새로 생겼다. Sonnet은 None일 수 있는 값을 None을 허용하지 않는 함수에 전달하는 실수를 반복했고, 테스트와 ruff는 이를 놓쳤지만 mypy를 켠 뒤에는 해당 오류가 통과하지 않았다.

이 결과는 벤치마크가 아니라 사례 연구다. billing과 티켓 작업은 Claude를 사용해 실험용으로 작성했으므로 Claude가 익숙한 코드 스타일일 수 있다. 무작위 버그와 vunnel, Codex를 포함해 이 영향을 줄이려 했지만, 각 비교에는 작업이 5~20개뿐이어서 큰 효과만 드러날 수 있다. 실험을 진행한 사람은 세 에이전트와 두 프로젝트, 766회 실행에서 타입이 에이전트를 더 빠르고 저렴하게 만들거나 정답률을 높이지는 않았다고 결론 내렸다. 다만 타입 검사기를 제공하면 피드백 과정이 개선된다는 점은 확인했다.

실험에 사용한 도구와 비교 자료는 Claude Code, Codex, ruff, SWE-bench, 그리고 Gao·Bird·Barr의 2017년 연구에서 확인할 수 있다. 글은 강한 타입을 쓰는 Rust가 AI 작업에 최선이라는 주장에도 의문을 제기하지만, Rust에 관한 비교 실험 결과는 제시하지 않는다. 관련 연구 링크로 논문 21쪽을 덧붙였다.

부록: 원문 예시

def report_usage(ctx, subscription_id, price_id, quantity, timestamp=None, idempotency_key=None):     ...     record = {         "id": ctx.ids.usage_record(),         "quantity": quantity,         "timestamp": timestamp if timestamp is not None else to_millis(ctx.clock.now()),     }def report_usage(     ctx: Context,     subscription_id: SubscriptionId,     price_id: PriceId,     quantity: int,     timestamp: EpochMillis | None = None,     idempotency_key: str | None = None, ) -> UsageRecord:     ...