정적 코드 분석이란 무엇인가? 개발팀을 위한 완벽 가이드

실제 운영 환경에 배포되는 모든 코드는 시간적 압박, 불완전한 맥락, 미비한 문서, 그리고 대규모 시스템을 실시간으로 분석해야 하는 어려움 등 여러 제약 조건 하에서 사람이 직접 작성한 것입니다. 정적 코드 분석은 소스 코드를 실행하지 않고 체계적으로 검토하는 분야로, 자동화된 도구를 사용하여 사람이 검토할 때 놓치기 쉬운 부분, 즉 보안 취약점, 논리 오류, 코딩 표준 위반, 사용되지 않는 코드, 그리고 향후 유지보수 문제를 야기할 수 있는 구조적 패턴 등을 찾아냅니다. 이는 테스트, 설계 검토 또는 엔지니어의 판단을 대체하는 것이 아닙니다. 모든 파일, 모든 커밋, 모든 빌드에 대해 자동화된 검토를 수행하며, 어떤 수동 프로세스도 따라올 수 없는 속도와 일관성을 제공합니다.

정의는 간단해 보이지만, 실제로는 정적 분석은 광범위한 기법을 포괄하며, 깊이와 정확도 수준이 다양하고, 개발 수명주기의 여러 단계에 적용되며, 각 도구가 탐지할 수 있는 범위 또한 상당히 다릅니다. 포맷팅 규칙을 적용하는 린터도 기술적으로는 정적 분석을 수행하는 것입니다. 완전한 호출 그래프를 구성하고, 오염된 데이터를 보안 취약점까지 추적하고, 도달할 수 없는 분기를 식별하고, 다국어 엔터프라이즈 시스템에서 필드 수준의 종속성을 매핑하는 도구 또한 정적 분석을 수행하지만, 두 도구는 기술적 깊이와 실제 활용도 측면에서 완전히 다른 수준을 보입니다. 이러한 광범위한 스펙트럼을 이해하는 것이 정적 분석을 효과적으로 선택하고 사용하는 데 필수적입니다.

정적 분석이란 무엇이며 무엇이 아닌가

정적 분석은 소스 코드를 구조화된 아티팩트로 간주하여 프로그래밍 언어의 문법과 의미론을 활용해 코드의 동작을 모델링한 다음, 해당 모델에서 관심 있는 속성을 쿼리하는 방식입니다. 이 분석은 코드를 실행하지 않고 수행됩니다. 런타임 환경이나 테스트 입력이 필요하지 않으며, 실행 추적도 관찰되지 않습니다. 소스 파일이 입력으로 사용되며, 분석 결과는 전적으로 코드의 구조, 내용 및 관계에서 도출됩니다.

정적 분석은 코드를 실행하지 않기 때문에 그 가치와 한계를 모두 갖습니다. 코드를 실행하지 않으므로 정적 분석은 테스트에서 거의 접근하지 않는 경로까지 포함하여 모든 코드 경로를 분석할 수 있습니다. 예를 들어, 거의 실행되지 않는 오류 처리기, 특정 데이터 구성에 의해서만 활성화되는 조건 분기, 그리고 수년 동안 테스트되지 않은 레거시 코드 경로 등이 있습니다. 하지만 코드를 실행하지 않기 때문에 런타임 동작을 관찰할 수 없고, 런타임에만 결정되는 값에 대해 추론할 수 없으며, 코드 동작이 접근할 수 없는 실행 컨텍스트에 의존하는 경우 근사치를 사용해야 합니다.

실질적으로 정적 분석은 구조적 문제, 정책 위반, 알려진 취약점 유형과 관련된 패턴, 코드의 텍스트와 구조에 표현된 의존성 관계와 같은 특정하고 가치 있으며 명확하게 정의된 문제 유형을 찾아냅니다. 특정 런타임 조건에서만 발생하는 문제, 동시 실행이 필요한 경쟁 조건, 또는 코드의 동작에 대한 의미론적 지식에 의존하는 비즈니스 로직 오류는 찾아낼 수 없습니다. 이러한 한계는 정적 분석의 가치를 떨어뜨리는 것이 아니라, 그 범위를 정의하는 것입니다. 이러한 범위를 이해함으로써 팀은 정적 분석을 테스트, 코드 검토 및 런타임 모니터링의 대체재로 여기는 대신, 이러한 요소들과 함께 적절하게 통합할 수 있습니다.

정적 분석과 동적 분석의 차이점

동적 분석은 코드를 실행하여 평가합니다. 이 도구는 런타임 동작, 즉 메모리 할당 및 해제, 코드 경로별 실행 시간, 특정 시점의 변수 값, 동시 실행 패턴 및 시스템 호출을 관찰합니다. 동적 분석은 실행 중에만 발생하는 문제, 예를 들어 장시간 실행 시 누적되는 메모리 누수, 동시에 실행되는 스레드 간의 경쟁 조건, 특정 부하 패턴에서의 성능 저하, 예상치 못한 입력 값으로 인한 충돌 등을 찾아냅니다.

두 접근 방식은 경쟁적이라기보다는 상호 보완적입니다. 아래 비교표는 각 방식의 실제 적용 범위를 보여줍니다.

부동산	정적 분석	동적 분석
실행이 필요합니다	아니	가능
코드 경로 커버리지	운동하지 않은 경로를 포함한 모든 경로	실행된 경로만
런타임 메모리 오류를 찾습니다.	부분적으로 (패턴만 해당)	네, 바로요.
코드 구조에서 보안 취약점을 찾아냅니다.	가능	부분적으로
동시성 버그를 찾아냅니다.	부분적으로 (패턴만 해당)	네, 바로요.
불완전한 코드에 대한 작업	가능	아니
한 번에 전체 코드베이스에 맞게 확장 가능	가능	테스트 범위에 따라 다릅니다.
사용되지 않는 코드를 감지합니다.	가능	아니
구성 요소 간의 종속성을 식별합니다.	가능	부분적으로

가장 효과적인 품질 보증 프로그램은 두 가지 모두를 활용합니다. 정적 분석은 코드 실행 전에 구조적 문제와 정책 위반 사항을 조기에 포괄적으로 파악할 수 있도록 해줍니다. 동적 분석은 실행 중에 검증된 동작 확인을 제공합니다. 하지만 어느 한쪽만으로는 품질 및 보안의 모든 측면을 포괄할 수 없습니다.

개발 수명주기에서 정적 분석의 위치

정적 분석은 개발 수명주기에서 가능한 한 가장 초기 단계, 즉 개발자가 코드를 작성하는 IDE 내에서, 코드가 버전 관리 시스템에 저장되기 전에 실행되는 pre-commit 훅에서, 그리고 병합 전에 모든 변경 사항을 검증하는 CI 파이프라인에서 이루어져야 합니다. 이러한 위치 선정 덕분에 정적 분석은 탐지 메커니즘이 아닌 예방 메커니즘으로 작용합니다. IDE에서 발견된 문제는 수정하는 데 몇 분밖에 걸리지 않지만, pre-commit 단계에서 발견된 문제는 몇 시간이 걸리고, 배포 후에 발견된 문제는 시간과 위험 측면에서 훨씬 더 많은 비용을 초래합니다.

이 원칙은 때때로 "좌측 이동(shift left)"이라고 불리는데, 이는 일반적인 좌측에서 우측으로 진행되는 SDLC 타임라인에서 품질 검사를 개발 프로세스 초반, 즉 좌측으로 이동시키는 것을 의미합니다. 정적 분석은 보안 및 품질 검사를 좌측으로 이동시키는 주요 기술적 메커니즘입니다. 왜냐하면 정적 분석은 코드가 실행 가능할 정도로 완성되기 전, 테스트 스위트가 작성되기 전, 그리고 다른 사람이 검토하기 전에 실행될 수 있는 유일한 자동화된 접근 방식이기 때문입니다. 코드 품질을 위한 DevOps 통합 의 맥락에서 설명했듯이 , 자동화된 분석을 일상적인 개발 워크플로에 통합하는 것은 팀 규모에 비례하여 수동 검토 노력을 늘리지 않고도 대규모 코드 품질을 유지하려는 조직에게 필수적인 실천 방안입니다.

정적 분석의 작동 방식: 기술적 구성 요소

정적 분석 도구는 여러 가지 기술적 수준에서 작동하며, 각 수준은 서로 다른 유형의 분석을 제공하고 서로 다른 유형의 문제를 탐지합니다. 이러한 수준을 이해하는 것은 중요합니다. 왜냐하면 각 도구는 서로 다른 수준에서 작동하며, 해당 수준에 따라 도구가 무엇을 찾을 수 있고 무엇을 찾을 수 없는지가 결정되기 때문입니다.

어휘 분석: 표면적인 측면

어휘 분석은 정적 분석의 가장 기본적인 수준입니다. 소스 코드를 문자열로 간주하여 키워드, 식별자, 연산자, 리터럴, 구분 기호와 같은 토큰으로 분해합니다. 명명 규칙, 공백 규칙, 최대 줄 길이, 금지된 키워드 사용 등을 강제하는 린팅 도구는 주로 어휘 수준에서 작동합니다. 이러한 도구는 속도가 빠르고 최소한의 설정만 필요하며, 표면적인 정책 위반 사항을 일관되게 잡아냅니다.

어휘 분석은 코드의 실제 동작에 대해서는 추론할 수 없습니다. 변수 이름이 특정 방식이라는 것은 알지만, 그 변수가 무엇을 나타내는지, 또는 그 값이 프로그램에서 어떻게 흐르는지는 알 수 없습니다. 어휘 분석은 내용에 대한 이해 없이 형식만 강제하는 것입니다. 이러한 이유로 어휘 분석은 필요하지만, 독립적인 품질 관리 메커니즘으로서는 불충분합니다. 코드의 가독성과 일관성을 유지하는 데는 도움이 되지만, 논리 오류, 보안 취약점 또는 구조적 문제를 찾아낼 수는 없습니다.

구문 분석: 의미론 없는 구조 분석

구문 분석은 프로그래밍 언어의 문법에 따라 소스 코드를 파싱하여 코드의 구조적 관계를 나타내는 추상 구문 트리(AST)를 생성합니다. 이 트리는 어떤 표현식이 다른 표현식의 하위 표현식인지, 어떤 문장이 어떤 블록에 속하는지, 어떤 식별자가 선언이고 어떤 식별자가 참조인지를 보여줍니다. 많은 정적 분석 도구는 주로 구문 수준에서 작동하며, AST 패턴 매칭을 사용하여 알려진 문제와 관련된 코드 구조를 탐지합니다.

함수가 특정 복잡도 임계값을 초과하는지 여부를 표시하는 규칙은 구문적으로 작동합니다. 즉, 함수 본문의 AST(추상 구문 트리)에서 결정 지점의 수를 계산합니다. 널 역참조 패턴을 감지하는 규칙도 구문적으로 작동합니다. 즉, 널일 수 있는 값이 널 검사 없이 사용되는 AST 패턴을 찾습니다. 이러한 감지 방식은 구조를 기반으로 하기 때문에 어휘 분석보다 강력하지만, 여전히 의미론이 아닌 패턴을 기반으로 작동합니다. 널 역참조 패턴 일치는 해당 변수가 사용되는 컨텍스트에서 실제로 널일 수 있는지 여부를 알지 못합니다. 단지 패턴이 존재한다는 사실만 알 뿐입니다.

의미 분석: 의미와 유형

의미 분석은 코드의 해석된 의미를 기반으로 작동합니다. 즉, 각 표현식의 타입, 각 참조가 가리키는 선언, 호출되는 오버로드된 메서드, 그리고 타입 시스템이 프로그램 내에서 흐르는 값에 대해 증명할 수 있는 내용 등을 분석합니다. 타입 검사는 의미 분석의 가장 일반적인 형태입니다. 컴파일러의 타입 검사기는 정수가 예상되는 위치에 문자열을 전달하는 코드를 거부할 때 정적 분석을 수행합니다.

보다 정교한 의미 분석에는 명시적으로 주석이 달리지 않은 표현식의 유형을 결정하는 유형 추론과, null일 가능성이 있는 값이 사용 전에 안전하게 검사되는지 여부를 추적하는 null 안전성 분석이 포함됩니다. 이러한 분석은 완전한 심볼 해상도를 필요로 하므로 언어별로 특화되어 있으며 완전하거나 거의 완전한 코드가 필요합니다. 즉, 유형 정의가 누락되었거나 사용 불가능한 종속성에 정의된 심볼을 참조하는 코드 조각에서는 작동할 수 없습니다. 레거시 현대화 계획 에 대한 더 광범위한 논의에서 살펴본 바와 같이 , 불완전하거나 문서화되지 않은 종속성을 가질 수 있는 레거시 코드베이스에 대한 완전한 의미 분석을 수행하려면 해당 환경의 특정 구조적 패턴을 처리할 수 있는 특수 도구가 필요합니다.

데이터 흐름 분석: 실행을 통한 가치 도출

데이터 흐름 분석은 프로그램 내에서 값이 어떻게 이동하는지 추적합니다. 프로그램의 제어 흐름 그래프를 기반으로 작동하며, 실행 경로를 따라 변수 값에 대한 정보를 전파하고 값이 어디에서 생성되고, 어디에서 수정되고, 어디에서 소비되는지를 기록합니다. 데이터 흐름 분석을 통해 초기화되지 않은 변수 읽기, 메모리 관리에서의 해제 후 사용(use-after-free), 사용자 입력에서 보안에 민감한 작업으로 오염이 전파되는 등의 문제를 탐지할 수 있습니다.

오염 분석은 데이터 흐름 분석의 특정 형태로, 신뢰할 수 없는 출처(사용자 입력, 네트워크 데이터, 파일 내용)에서 발생하는 값을 추적하고 이러한 값이 검증 없이 보안에 민감한 작업(SQL 쿼리, 시스템 호출, 출력 작업)에 도달할 수 있는지 여부를 식별합니다. 오염된 값이 검증 없이 보안 지점에 도달하면 분석에서 잠재적인 인젝션 취약점으로 표시됩니다. 이는 정적 분석 도구에서 발견되는 대부분의 SQL 인젝션, 크로스 사이트 스크립팅(XSS) 및 명령 인젝션 취약점의 자동 탐지 메커니즘입니다.

코드상의 두 경로 차이는 미미하지만, 보안 결과는 완전히 다릅니다.

# Vulnerable: user input reaches SQL query without sanitization (tainted path)
def get_user(username):
    query = "SELECT * FROM users WHERE name = '" + username + "'"
    return db.execute(query)  # sink: tainted value reaches SQL execution

# Safe: sanitization breaks the taint chain before the sink
def get_user_safe(username):
    query = "SELECT * FROM users WHERE name = ?"
    return db.execute(query, (username,))  # parameterized: taint neutralized

정적 오염 분석은 코드를 실행하지 않고, 악의적인 테스트 입력 없이도 첫 번째 함수에서 취약한 패턴을 탐지합니다. 데이터 흐름 분석은 계산 비용이 많이 들고 정확도와 성능 간의 근본적인 상충 관계에 직면합니다. 모든 가능한 실행 경로를 고려하는 정확한 데이터 흐름 분석은 대규모 코드베이스에서는 비현실적인 경우가 많습니다. 대부분의 도구는 정확도를 다소 희생하면서 확장성을 확보하는 근사치를 사용하기 때문에 데이터 흐름 분석 결과에는 일반적으로 사람의 검토가 필요한 오탐률이 포함됩니다. 실행 경로와 데이터 흐름에 대한 코드 시각화는 개발자가 플래그가 지정된 경로가 실제로 애플리케이션 컨텍스트에서 악용 가능한지 여부를 확인할 수 있도록 분석 결과를 쉽게 이해할 수 있게 해줍니다.

제어 흐름 분석: 실행 경로

제어 흐름 분석은 코드의 모든 가능한 실행 경로를 그래프로 나타내어, 어떤 문장이 도달 가능한지, 어떤 문장이 실행되지 않는지, 그리고 각 분기가 실행되기 위해 어떤 조건이 충족되어야 하는지를 식별합니다. 제어 흐름 그래프는 다른 여러 분석의 기초가 됩니다. 데이터 흐름 분석은 제어 흐름 그래프를 기반으로 작동하고, 도달 가능성 분석은 이를 사용하여 실행되지 않는 코드를 식별하며, 순환 복잡도와 같은 복잡도 지표는 제어 흐름 그래프에서 도출됩니다.

제어 흐름 분석은 사용되지 않는 코드(데드 코드)를 탐지하는 핵심 요소입니다. 정의는 되어 있지만 어떤 진입점에서도 도달할 수 없는 코드는 제어 흐름 그래프에 인바운드 엣지가 없으므로 사용되지 않는 코드로 식별할 수 있습니다. 이는 기업 팀이 현대화 전에 필요한 애플리케이션 종속성 매핑 과 직접적인 관련이 있습니다 . 어떤 코드 경로가 활성 상태이고 어떤 경로가 사용되지 않는지 파악하면 마이그레이션 과정에서 안전하게 제거할 수 있는 코드와 보존해야 하는 코드를 결정할 수 있습니다.

호출 그래프 분석: 구성 요소 간 관계

호출 그래프 분석은 코드베이스 전체에서 어떤 함수가 다른 함수를 호출하는지 보여주는 모델을 구축합니다. 완전한 호출 그래프는 호출자 열거, 피호출자 열거, 전이적 종속성 분석, 그리고 어떤 진입점에서도 호출되지 않는 함수 식별을 지원합니다. 여러 파일, 모듈, 패키지에 걸쳐 있는 구성 요소 간 호출 그래프 분석은 영향 분석의 기술적 기반이 됩니다. 영향 분석이란 특정 함수나 인터페이스가 변경될 경우 어떤 부분이 영향을 받을지 판단하는 것을 의미합니다.

단일 언어, 단일 저장소 코드베이스에서는 대부분의 성숙한 정적 분석 도구가 호출 그래프 구축을 잘 지원합니다. 그러나 다중 언어 엔터프라이즈 환경에서는 완전한 호출 그래프를 구축하기 위해 시스템 내 모든 언어를 수집하고 언어 간 호출 관계를 해결하는 통합 분석 플랫폼이 필요합니다. JavaScript 및 Node.js 코드베이스 의 경우 동적 모듈 로딩, 프로토타입 기반 디스패치, 콜백 패턴으로 인해 더욱 복잡해집니다. COBOL, JCL, SQL 및 최신 서비스 계층이 혼합된 엔터프라이즈 시스템의 경우, 문제는 훨씬 더 심각해지며, 언어별 파서와 전체 시스템을 표현하는 교차 언어 그래프 모델이 필요합니다.

정적 분석이 감지하는 것: 실용적인 분류 체계

정적 분석 도구가 탐지하는 문제 유형은 매우 광범위하며, 각 도구는 이러한 범위의 하위 집합을 각각 다르게 다룹니다. 분류 체계를 이해하면 팀은 도구의 기능을 특정 탐지 요구 사항에 맞춰 선택할 수 있습니다.

패턴 및 오염 분석을 통해 발견된 보안 취약점:

• SQL 인젝션, 크로스 사이트 스크립팅, 명령 인젝션은 사용자 제어 소스에서 보안 싱크로 오염 전파를 통해 발생합니다.
• 안전하지 않은 암호화 사용: 취약한 알고리즘, 불충분한 키 길이, 더 이상 사용되지 않는 암호화 모드
• 소스 코드에 하드코딩된 자격 증명, API 키 및 비밀 값
• 안전하지 않은 역직렬화 패턴 및 안전하지 않은 XML 구문 분석 구성
• 파일 접근 작업에서의 경로 탐색 취약점

구조 분석을 통해 발견된 코드 품질 및 유지보수성 문제:

• 과도한 순환 복잡도는 코드를 안전하게 테스트하고 수정하기 어렵다는 것을 나타냅니다.
• 함수와 클래스가 너무 길어서 단일 책임 원칙을 위반하는 경우
• 중복된 코드 블록은 한쪽은 업데이트되었지만 다른 쪽은 업데이트되지 않았을 때 유지 관리 위험을 초래합니다.
• 사용되지 않는 변수, 매개변수 및 가져오기는 동작에 영향을 미치지 않고 불필요한 정보를 추가합니다.
• 일관성 없는 명명 규칙과 스타일 위반으로 인해 가독성이 저하됨

의미론적 분석 및 데이터 흐름 분석을 통해 발견된 정확성 문제:

• null 안전성 강제가 없는 언어에서의 null 역참조
• 초기화되지 않은 변수를 읽으면 정의되지 않은 동작이 발생합니다.
• 산술 연산에서 발생하는 정수 오버플로 및 언더플로
• 획득한 리소스가 모든 코드 경로에서 해제되지 않는 리소스 누수 현상
• 오류를 묵살하는 잘못된 예외 처리

호출 그래프 및 의존성 분석을 통해 발견된 구조적 문제점:

• 어떤 진입점에서도 발신자와 연결되지 않는 통화 불가 상태입니다.
• 모듈 간의 순환 종속성은 아키텍처 분리가 미흡함을 나타냅니다.
• 대체 구현으로 마이그레이션된 코드베이스에서 더 이상 사용되지 않는 함수 사용
• 무조건 반환 또는 예외 발생 후 도달할 수 없는 코드
• null을 반환할 수 있는 함수에서 반환된 값에 대해 역참조 전에 null 검사가 누락되었습니다.

Node.js 애플리케이션 및 기타 동적 런타임 환경 의 경우 , 탐지 범주는 비동기 패턴까지 확장됩니다. 여기에는 프로미스 거부 핸들러 누락, 콜백 오류 우선 패턴 위반, 이벤트 이미터 메모리 누수 등이 포함됩니다. Rust 및 시스템 프로그래밍 환경에서는 컴파일러가 완벽하게 검증할 수 없는 수명 주기 위반, 안전하지 않은 블록 사용, 동시성 안전성 속성에 대한 분석에 중점을 둡니다.

정적 분석으로는 감지할 수 없는 것

정적 분석의 한계를 이해하는 것은 그 기능을 이해하는 것만큼 중요합니다. 정적 분석이 모든 버그를 잡아낼 것이라고 기대하는 팀은 실망할 수 있으며, 깔끔한 분석 결과에 대한 신뢰를 잘못 설정할 수도 있습니다. 여러 유형의 문제는 구조적으로 정적 분석의 범위를 벗어납니다.

실행 중에만 발생하는 동작은 정적 분석으로는 탐지할 수 없습니다. 장시간 실행 후에만 나타나는 메모리 누수, 특정 부하 패턴에서의 성능 저하, 비결정적인 스레드 스케줄링에 의존하는 동시성 버그, 그리고 예상치 못한 런타임 상태 조합으로 인한 크래시 등은 모두 실행을 통해서만 탐지할 수 있습니다. 동적 분석, 프로파일링, 스트레스 테스트가 이러한 영역을 다룹니다.

도메인 지식에 의존하는 비즈니스 로직 오류는 정적 분석으로는 탐지할 수 없습니다. 예를 들어, 잘못된 공식으로 인해 이자를 잘못 계산하는 함수, 잘못된 시간 범위를 사용하여 데이터를 집계하는 보고서, 또는 잘못된 사용자 집합에 접근 권한을 부여하는 권한 확인 등은 코드의 동작 의도에 대한 의미론적 지식이 필요한 정확성 오류입니다. 정적 분석은 코드가 구조적 패턴을 준수하는지 여부는 검증할 수 있지만, 코드가 올바른 비즈니스 동작을 구현하는지는 검증할 수 없습니다. 이러한 부분은 기능 테스트와 명세 검토를 통해 확인할 수 있습니다.

소스 코드가 아닌 배포 아티팩트, 인프라 정의 및 환경 설정에 존재하는 구성 취약점은 인프라 코드 분석을 통한 최신 정적 분석으로 부분적으로 파악할 수 있지만, 많은 구성 문제는 런타임 시 또는 코드와 실행 환경 간의 상호 작용에서만 드러납니다.

여러 구성 요소에 걸쳐 있거나, 세션 상태를 포함하거나, 호출 체인 전체에 걸쳐 여러 보안 검사의 상호 작용에 의존하는 복잡한 인증 및 권한 부여 결함은 정적 분석으로 정확하게 추론하기 어렵습니다. 이러한 범주에서는 오탐과 미탐이 흔히 발생하며, 발견된 결함을 정확하게 평가하려면 전문가의 검토가 필요합니다.

정적 분석 도구 평가 및 선택

정적 분석 도구 선택은 적합성 평가 문제와 같습니다. 어떤 도구의 기능이 코드베이스, 팀, 그리고 조직의 요구 사항에 가장 잘 부합하는지를 찾아야 합니다. 도구들이 크게 차이가 나는 부분은 언어 지원, 분석 깊이, 오탐률, 통합 지원, 그리고 확장성입니다.

언어 지원은 가장 기본적인 제약 조건입니다. 코드베이스에 사용된 언어를 지원하지 않는 도구는 해당 코드베이스에 아무런 가치를 제공하지 못합니다. 다국어 환경에서는 각 언어에 특화된 여러 도구를 사용하는 것과, 여러 언어를 지원하고 언어 간 종속성 해결 기능을 통합한 통합 플랫폼을 사용하는 것 중에서 선택해야 합니다. 최신 구성 요소와 함께 상당한 양의 레거시 코드가 존재하는 엔터프라이즈 시스템의 경우, 언어 간 종속성 관계는 단일 언어 도구로는 표현할 수 없는 부분이기 때문에 통합 플랫폼 방식이 일반적으로 필수적입니다.

분석 깊이는 도구가 찾아낼 수 있는 문제 범주를 결정합니다. 어휘 및 구문 수준에서만 작동하는 도구는 데이터 흐름 취약점이나 사용되지 않는 코드를 찾지 못합니다. 전체 프로시저 간 데이터 흐름 분석을 구현하는 도구는 더 많은 취약점을 찾지만, 오탐이 더 많이 발생하고 더 많은 컴퓨팅 리소스를 필요로 합니다. 적절한 분석 깊이는 코드베이스의 위험 프로필에 따라 달라집니다. 보안이 매우 중요한 금융 또는 의료 시스템의 경우 심층적인 데이터 흐름 분석이 일반적으로 필요하지만, 내부 도구 코드베이스의 경우 가벼운 구조 분석으로도 충분할 수 있습니다.

오탐률은 실질적인 도입 제약 조건입니다. 분석하는 모든 코드베이스에서 수많은 비문제를 잘못된 것으로 표시하는 도구는 해당 문제를 무시하도록 설정될 가능성이 높습니다. 이는 팀이 분석 규칙의 이점을 잃는 동시에 이러한 결과를 무시하는 데 드는 지속적인 비용을 부담하게 된다는 것을 의미합니다. 오탐률은 도구의 분석 품질과 적용되는 규칙의 특이성 모두에 따라 달라집니다. 도구를 평가하는 팀은 공급업체가 제공하는 합성 코드베이스 기반 벤치마크에 의존하는 대신, 자사 코드의 대표 샘플을 사용하여 도구를 실행하고 조치 가능한 결과와 무시된 결과의 비율을 측정해야 합니다.

CI/CD 및 IDE 통합은 해당 도구가 실제로 활용될지 아니면 일회성 감사 활동으로만 취급될지를 결정하는 중요한 요소입니다. 별도의 수동 실행이 필요하고 결과가 별도의 인터페이스에 표시되는 도구는 개발자가 코드를 작성하는 동안 IDE에 결과를 인라인으로 표시하고 새로운 위반 사항을 포함하는 풀 리퀘스트를 실패 처리하는 도구보다 활용도가 떨어질 것입니다. 통합 품질은 일관된 적용 범위를 달성하는 데 있어 분석 품질만큼이나 중요한 실질적인 도입 요인입니다.

대규모 코드베이스에서는 확장성이 중요한 제약 조건이 됩니다. 백만 줄짜리 코드베이스를 분석하는 데 몇 시간이 걸리는 도구는 커밋이나 풀 리퀘스트 워크플로에 통합될 수 없습니다. 매번 전체 코드베이스를 분석하는 대신 변경된 파일과 그 종속성만 재분석하는 증분 분석은 커밋별 정적 분석을 대규모로 구현할 수 있게 해주는 기술적 메커니즘입니다. 따라서 도구는 전체 스캔 성능뿐만 아니라 증분 분석 기능도 함께 평가해야 합니다.

엔터프라이즈 다국어 환경에서의 정적 분석

여러 언어, 여러 플랫폼, 그리고 수십 년에 걸쳐 축적된 코드로 구성된 엔터프라이즈 환경에서는 정적 분석의 어려움이 크게 증가합니다. 단일 언어로 작성된 새로운 코드베이스에서는 효과적인 분석 접근 방식이 이러한 환경에서는 제대로 작동하지 않는 경우가 많은데, 이는 도구가 해당 언어를 지원하지 않거나, 언어 간 종속성을 모델링할 수 없거나, 레거시 코드의 구조적 패턴이 최신 코드베이스를 위해 설계된 도구의 가정과 일치하지 않기 때문입니다.

예를 들어 COBOL 프로그램은 대부분의 정적 분석 프레임워크가 가정하는 함수-클래스 모델과는 근본적으로 다른, 디비전, 섹션, 단락 기반의 구조 모델을 가지고 있습니다. 카피북 기반의 공유 정의, PERFORM-THRU 단락 범위, 그리고 camelCase나 밑줄 대신 하이픈을 사용하는 데이터 명명 규칙은 COBOL의 구조적 특징인데, 언어에 구애받지 않는 도구들은 이러한 특징들을 제대로 처리하지 못하거나 아예 처리하지 못하는 경우가 많습니다. 메인프레임 배치 프로그램의 실행을 조율하고 프로그램 간에 흐르는 데이터 세트를 정의하는 JCL은 어떤 범용 정적 분석 플랫폼에서도 전혀 분석되지 않습니다.

메인프레임 및 레거시 플랫폼과 최신 서비스를 함께 사용하는 조직에서는 코드 커버리지에 구조적인 격차가 발생합니다. 정적 분석 도구가 최신 코드는 철저하게 분석하지만 레거시 코드는 전혀 분석하지 않거나, 각 언어를 개별적으로 분석하여 언어 간의 관계를 파악하지 못하는 경우가 있습니다. 이러한 격차는 특히 해결하기 가장 어려운 부분, 즉 COBOL 프로그램의 변경 사항이 해당 출력을 읽는 Java 서비스에 영향을 미치거나 데이터베이스 스키마 변경이 레거시 배치 처리와 최신 API 계층 모두에 동시에 영향을 미치는 언어 간 인터페이스에서 가장 심각한 결과를 초래합니다. 메인프레임 현대화 계획 및 IBM i RPG 플랫폼 전환 사례에서 설명했듯이 , 레거시 구성 요소를 포함한 전체 애플리케이션 포트폴리오의 현황을 파악하는 것은 기존 위험을 해결하면서 새로운 위험을 초래하지 않는 모든 현대화 프로그램 계획의 필수 조건입니다.

방법 SMART TS XL 기업 전반에 걸쳐 정적 코드 분석 기능을 제공합니다.

SMART TS XL 이 플랫폼은 엔터프라이즈 코드베이스는 파일 수준이나 저장소 수준이 아닌 시스템 수준에서 분석해야 한다는 전제를 기반으로 구축되었습니다. 소프트웨어 인텔리전스 플랫폼은 COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, SQL 등 환경 내 모든 언어와 플랫폼의 소스 코드를 수집하고, 언어별 분석을 통해 각 코드를 통합된 상호 참조 모델로 파싱합니다. 이 모델은 전체 시스템의 구조적 관계를 나타냅니다. 여기에는 언어 경계를 넘나드는 호출 그래프, COBOL 정의에서 데이터베이스 열을 거쳐 Java 서비스로 전달되는 값을 추적하는 필드 수준 데이터 흐름 추적, 활성 코드 경로와 비활성 코드 경로를 보여주는 제어 흐름 그래프, 그리고 제안된 변경 사항의 영향을 받는 모든 구성 요소를 식별하는 종속성 맵이 포함됩니다.

The 정적 코드 분석 솔루션 그 SMART TS XL provides는 공통 대시보드를 통해 조정되는 언어별 린터 모음이 아닙니다. 시스템 전체를 모델링하는 통합 분석 플랫폼으로, 엔터프라이즈 환경에 필요한 언어 및 구성 요소 간 분석을 가능하게 합니다. 개발자가 "이 함수를 변경하면 어떤 영향을 받을까요?"라고 질문하면, 현재 보고 있는 파일만 분석하는 단일 언어 도구의 부분적인 답변이 아닌, 통합된 종속성 그래프에서 도출된 완전한 답변을 얻을 수 있습니다. 보안 분석가는 오염 분석을 수행할 때 데이터가 얼마나 많은 언어 경계를 넘나들든 상관없이 시스템 전체에서 민감한 데이터의 출처부터 최종 목적지까지 추적할 수 있습니다. 마이그레이션을 계획하는 현대화 팀은 최신 도구를 사용하는 구성 요소에만 국한된 보기가 아니라, 계층별, 언어별, 특정 관계 유형별로 구성된 구성 요소 간 종속성을 완벽하게 파악할 수 있습니다.

SMART TS XL이 플랫폼의 엔터프라이즈 검색 기능은 조사 진입점을 제공하며, 문자열 발생 빈도가 아닌 구조적 관계 유형별로 정리된 결과를 반환합니다. 정의, 호출, 읽기, 쓰기, 카피북 포함, SQL 참조 및 API 노출이 결과 집합에서 구분되므로 개발자는 텍스트 일치 목록을 필터링할 필요 없이 필요한 특정 정보를 얻을 수 있습니다. 또한 코드 시각화 기능은 심층적인 구조 분석을 탐색 가능한 순서도 및 종속성 다이어그램으로 변환하여 개발자가 모든 코드 줄을 순차적으로 읽지 않고도 복잡한 시스템을 이해할 수 있도록 합니다.

정적 분석은 기초이지, 최종 목적지가 아닙니다.

정적 분석은 도구가 아닌 인프라로 활용될 때 가장 큰 가치를 발휘합니다. 즉, 모든 코드에서 지속적으로 실행되어 체계적으로 검토되는 분석 결과를 생성하고, 그 결과를 개발 워크플로에 통합하여 필요에 따라 참조하는 방식으로 활용해야 합니다. 이러한 수준의 통합을 달성한 조직은 정적 분석을 통해 품질 및 보안 관리 방식을 점진적으로 전환할 수 있습니다. 즉, 문제가 발생한 후에 문제를 해결하는 사후 대응 방식에서, 문제와 관련된 패턴을 사전에 제거하여 문제를 예방하는 사전 예방 방식으로 전환할 수 있습니다.

목표 달성을 위한 투자는 주로 도구 투자에 그치지 않습니다. 더 어려운 과제는 문화 및 프로세스 차원의 접근 방식입니다. 즉, 정적 분석 결과를 묵살하는 대신 해결해야 한다는 기대치를 확립하고, 특정 코드베이스에 맞춰 분석 깊이와 오탐률의 균형을 유지하도록 도구를 구성하고, 분석 결과를 IDE 및 CI 워크플로에 통합하여 별도의 검토 단계가 아닌 개발 단계에서 바로 확인할 수 있도록 하고, 코드베이스가 발전함에 따라 구성을 유지 관리하는 것입니다. 도구는 이러한 작업을 가능하게 하지만, 조직의 실천은 이를 지속시키는 역할을 합니다. 여러 언어, 여러 플랫폼, 그리고 수십 년에 걸쳐 축적된 코드를 아우르는 운영 체제를 사용하는 기업의 경우, 도구 기반은 이러한 전체 범위를 포괄할 수 있어야 합니다. 코드베이스의 80%를 분석하는 정적 분석의 가치는 전체 분석 가치의 80%에 불과한 것이 아니라, 분석되지 않은 20%에 내재된 위험에 의해 제한됩니다.