AI 시대에도 정적 분석은 필요할까? 목적과 토큰 효율성 관점에서 고찰

AI 시대에도, 정적 분석(Static Analysis)은 필요합니다.

그 이유는 코드를 작성하는 속도가 빨라지더라도, 정확성을 확인하는 작업은 남아있기 때문입니다. 기계적으로 확인할 수 있는 부분을 정적 분석에 맡긴다면, AI와 사람은 사양이나 설계 판단에 집중할 수 있습니다.

이 글에서는 정적 분석의 전체적인 개요와 AI 개발에서의 역할을 정리합니다. 특정 AI 제품을 전제로 하지는 않습니다. 후반부 코드 예시에는 TypeScript를 사용하겠습니다.

정적 분석은 대상 프로그램을 실행하지 않고, 코드의 구조나 타입(type), 데이터 흐름(data flow)으로부터 문제를 조사하는 기술입니다.

목적은 실행 전에 발견할 수 있는 문제를 빠르게 찾고, 동일한 기준으로 반복적으로 확인하는 것입니다.

대표적인 범위는 다음 세 가지입니다. 분류가 중첩되며, 제품별로 대응 범위도 다릅니다.

예를 들어 CodeQL은 데이터 흐름을 모델링하여 분석합니다. 다만, 실행 시점에 결정되는 호출 대상 등 정확하게 다루기 어려운 경우도 있습니다. [CodeQL의 데이터 플로우 분석 설명]

또한, 포맷팅(formatting)을 수행하는 포매터나, 의존 라이브러리의 알려진 취약점을 조사하는 검사도 개발에 도움이 되지만, 여기서는 역할을 나누어 생각하겠습니다.

AI에게도 코드 문제를 찾아달라고 할 수 있습니다. 그럼에도 불구하고 정적 분석을 남겨두는 이유가 있습니다.

규칙으로 명문화할 수 있는 확인 작업을 매번 AI에게 추론하도록 시킬 필요가 없기 때문입니다.

AI가 작성한 코드든, 사람이 작성한 코드든 동일한 검사를 적용하는 것만으로도, 코드 작성자에 의존하지 않는 확인 절차를 만들 수 있습니다.

여기서 말하는 토큰(token)은 AI가 입출력하는 문서나 코드를 처리하는 단위입니다.

정적 분석을 먼저 실행하면,

error TS18048: 'name' is possibly 'undefined'.

여기까지는, 타입 검사(型検査)가 판단할 수 있습니다.

반면, 미입력된 이름을 어떻게 처리해야 하는지는 사양(仕様)의 문제입니다. 에러로 만들지, 입력을 요구할지, 대체 표시를 사용할지 등입니다. 타입 검사만으로는 결정되지 않습니다.

'미정의, 빈 문자열, 공백만 있는 이름은 '이름 없음'으로 표시한다'는 사양이 있다면, 다음과 같이 수정할 수 있습니다.

function displayName(name: string | undefined): string {
return name?.trim() || "名無し";
}

이 코드를 after.ts에 저장하고, 같은 조건으로 검사하면 통과합니다.

npx --yes --package [email protected] tsc --strict --noEmit after.ts

2026년 10월 4일, macOS, Node.js v26.0.0, TypeScript 5.9.3으로 확인했습니다. 수정 전에는 TS18048로 종료 코드 2였고, 수정 후에는 진단 없이 종료 코드 0이었습니다. 이는 타입 검사의 확인일 뿐이며, 제품 사양의 타당성을 검증한 것은 아닙니다.

AI에게 수정을 맡길 때도 이 사양을 전달해야 합니다. 타입 에러가 사라진 것과 기대했던 동작이 된 것은 별개로 확인합니다.

처음부터 모든 규칙을 활성화할 필요는 없습니다. 먼저, 언어의 타입 검사와 실질적인 피해(実害)가 명확한 Lint 규칙부터 시작합니다. 필요한 범위에 보안 검사를 추가합니다.

AI와 결합하는 절차도 간단합니다.

• 코드를 변경했다면, 정적 분석을 실행한다.
• 진단과 필요한 문맥, 사양을 AI에게 전달하여 수정한다.
• 같은 정적 분석을 재실행하고, 관련 테스트도 수행한다.
• 사람이 사양이나 설계상의 판단을 확인한다.

분석을 통과시키기 위해 규칙을 비활성화하거나, 타입 검사를 회피하지 않았는지도 확인합니다.

기존 경고가 많은 경우라면, 알려진 경고를 기록하고 새로운 문제부터 대응하는 운영 방식도 고려할 수 있습니다. 다만, 중대한 알려진 문제를 방치할 이유는 되지 않습니다.

AI에게 전달할 진단을 좁히는 것과, 분석 대상을 좁히는 것은 별개입니다. 변경된 줄만 분석해서는, 호출하는 곳이나 의존하는 곳에 미치는 영향을 놓칠 수 있습니다.

정적 분석에는 오탐지(誤検知)도 있고 누락(見逃し)도 있습니다. 통과했다고 해서 버그가 없거나 안전하다는 보장은 되지 않습니다.

업무 요구사항, 사용 용이성, 실제 환경에서의 성능 등은 테스트나 측정, 사람의 확인도 필요합니다. AI는 사양 정리나 수정안 검토를 도울 수 있지만, 그 제안 역시 검증해야 합니다.

AI 시대에 정적 분석은 필요한가. 답은, 필요합니다.

기계적으로 확인할 수 있는 것은 정적 분석으로. 실행해서 확인하는 것은 테스트로. 무엇을 옳다고 할지는 사람이 AI도 활용하여 결정합니다.

이 역할 분담을 만드는 것이, 토큰뿐만 아니라 개발 전체의 재작업(手戻り)을 줄이는 출발점이 됩니다.