차등 분석이란 무엇인가?

블로그 2020년 5월 11일

차등 분석이란 무엇인가?

차등 분석(differential analysis)은 정적 분석의 신흥 솔루션이다. 이 글에서는 차등 분석이 무엇이며 정적 분석에서 어떻게 작동하는지 자세히 살펴본다. 끝까지 읽어도 좋고, 가장 관심 있는 섹션으로 바로 이동해도 된다.

차등 분석은 '빠른 피드백(fast feedback)' 정적 코드 분석의 한 형태다. 이전 분석 빌드의 시스템 컨텍스트 데이터를 활용하여 새 파일과 변경된 파일만 분석한다. 동시에 전체 시스템을 분석한 것과 동일한 결과를 제공한다. 이러한 차등 분석 접근 방식은 분석 데이터의 정확성과 세부 사항을 유지하면서 새 코드와 변경된 코드에 대해 가장 짧은 분석 시간을 제공한다.

점진적 분석 vs 차등 분석

점진적 분석

점진적 분석(incremental analysis)은 컴파일러 도구 체인이 '전체 빌드'가 아닌 '업데이트 빌드'를 수행하는 것과 유사하게 '업데이트 분석'을 수행한다는 개념을 포괄한다. 이전 분석 빌드에서 '분석 객체'(모듈에 대한 분석 데이터와 해당 모듈이 의존하는 파일의 타임스탬프 또는 체크섬 포함)를 유지함으로써, 점진적 분석은 '의존성 확인'을 시작하여 소스 파일 중 변경된 것이 있는지, 그리고 재분석이 필요한지 판별한다.

점진적 분석에서는 전체 애플리케이션이 기본적으로 최소한의 노력으로 재분석된다. 올바르게 수행하면 점진적 분석은 전체 분석보다 훨씬 빠르며 결과의 정확성에 영향을 주지 않는다.

하지만 최악의 시나리오, 즉 설계가 잘못된 시스템에서 코드 변경이 중앙 모듈이나 인터페이스 업데이트를 포함하고, 이것이 궁극적으로 시스템의 다른 모든 모듈에서 사용(또는 포함)되는 경우를 상상해 보라. 이때 점진적 분석 시간은 전체 분석 시간과 동일해진다. 안타깝게도 불필요한 의존성과 결합을 가진 모듈화가 잘 안 된 소프트웨어 시스템은 흔하며, 리팩터링이 항상 가능한 것도 아니다.

매우 크고 복잡한 코드베이스, 매우 긴 빌드 및 분석 시간과 결합되면, 이는 CI/CD 파이프라인의 런타임 문제를 악화시킨다.

차등 분석

간단히 말해, 차등 분석은 CI/CD 파이프라인에서 사용하도록 설계된 향상된 형태의 점진적 정적 코드 분석이다. 코드베이스가 크고 복잡하며, 빌드 및 분석 시간이 길어 개발 팀에 '빠른 피드백'을 제공하기 어려운 상황에서 유용하다.

원격 빌드 서버의 이전 전체 분석 빌드에서 시스템 컨텍스트 데이터를 사용하면, 로컬 정적 분석기는 버전 관리 시스템(예: Git 또는 P4)에서 보고된 새 파일이나 변경된 파일만 검사한다. 서버에서 공유된 이 시스템 컨텍스트 데이터를 사용하면, 로컬 정적 코드 분석기는 시스템의 작은 부분만 로컬에서 분석했더라도 전체 시스템을 분석한 것처럼 분석 결과를 제공할 수 있다.

따라서 차등 분석은 변경된 코드에서 새로운 문제를 보고하면서 가능한 가장 짧은 분석 시간을 제공한다. 이를 통해 코드베이스의 전체 규모나 설계의 모듈화 부족 여부와 관계없이 개발 팀에 '빠른 피드백'을 제공할 수 있다.

Klocwork 같은 도구에서 차등 분석은 마지막 빌드 이후 또는 현재 메인 브랜치를 기준으로 감지된 새로운 문제만 보고한다. 이를 통해 코드베이스 품질을 저하시키고 규정 준수 문제를 야기할 수 있는 '새로운 문제'에 초점을 맞춘다.

차등 분석이 중요한 이유는?

차등 분석은 분석 시간을 단축하고 더 빠른 피드백을 보장하기 위해 중요하다.

차등 분석은 코드 분석을 가속화한다

코드를 작성할 때 품질, 보안 또는 표준을 준수해야 할 것이다. 일반적으로 이는 코드의 로컬 분석 또는 커밋 전 분석을 실행하는 것을 포함한다. 하지만 분석이 수행될 때 이미 코드가 커밋된 경우는 어떨까? 이미 다른 작업으로 넘어갔을 수 있다. 그 문제들을 수정하는 것은 뒤로 밀려날 수 있다. 열린 문제 백로그가 개발 팀에 제출되는 최종 릴리스 주기까지 밀려날 수도 있다.

로컬 또는 커밋 전 분석은 일반적으로 변경 사항을 포함한 전체 코드베이스 분석을 실행한다. 새로운 문제를 보고한다. 이는 소규모 프로젝트에서는 완벽하게 작동하지만, 더 큰 코드베이스와 더 긴 분석 시간을 다룰 때는 문제가 발생한다.

정적 분석은 이를 해결하기 위해 점진적 분석 기능을 제공한다. 즉, 코드 변경이 전체 시스템의 새로운 분석 빌드를 필요로 하지 않는다. 대신 변경된 파일과 그에 의존하는 파일을 분석한다.

하지만 이것은 여전히 비효율적일 수 있다. 최악의 시나리오에서 의존성을 분석하는 것은 전체 코드베이스를 분석하는 것과 유사하다. 프로젝트에 따라 몇 분에서 몇 시간이 걸릴 수 있다.

점진적 분석과 차등 분석의 예시

개발자가 점진적 또는 차등 정적 코드 분석에서 가장 큰 가치를 얻을 수 있는 곳을 이해하려면, 개발자가 생산성을 유지하기 위해 필요한 피드백 시간을 고려하는 것이 중요하다. 그리고 그것을 코드베이스 크기와 복잡성, 이전 빌드 이후의 변경 및 커밋 수에 의해 생성된 제약과 균형을 맞춰야 한다.

기능 브랜치 CI 파이프라인

위에서 설명한 것처럼 기능 브랜치 내에서 개발자는 일반적으로 브랜치의 여러 버전을 커밋하고 각 커밋마다 CI 작업을 실행한다. 이 경우 차등 분석은 상당한 시간을 절약하고 변경 사항을 기반으로 빠른 피드백과 집중된 결과를 제공한다.

즉, 차등 분석 예시로서 이 유형의 분석은 특정 파일 변경 세트(애플리케이션의 하위 집합)의 새로운 문제나 취약점을 보고한다. 빌드 및 분석 시간이 큰 문제가 되지 않는 소규모 애플리케이션의 경우 각 커밋마다 전체 애플리케이션을 분석할 수 있다. 어느 쪽이든 이 접근 방식은 메인 브랜치에 병합되는 문제 수를 줄여 개발 팀에 이득이 된다.

통합 브랜치

여러 개발자가 각자 자신의 브랜치에서 작업하는 개발 팀에서 기능 브랜치의 커밋이 성공한 후, 모든 변경 사항을 릴리스 브랜치에 병합하기 전에 Dev 브랜치에 대한 추가 CI 파이프라인 실행이 시작될 수 있다.

점진적 분석은 다양한 기능 브랜치에서 만든 모든 변경 사항을 수행하고 이전 릴리스 브랜치 개정판과 비교하여 '점진적으로' 분석하므로 여기서 매우 유용하다. 코드베이스가 크고 복잡한 많은 경우, 이는 엄청난 시간을 절약하면서도 전체 클린 빌드와 일치하는 분석 결과를 제공한다.

또한 개발자가 결국 Dev 브랜치에 병합되는 기능 브랜치에 매일 변경 사항을 적용함에 따라, 사용 가능한 가장 최신 시스템 컨텍스트 데이터를 재설정하는 주기를 갖는 것이 중요하다. 그래야 새로운 기능 브랜치에서 수행되는 다음 차등 분석 실행이 가능한 한 관련성 있고 정확할 수 있다.

릴리스 브랜치 CD 파이프라인

마지막으로 릴리스 스트림에 각 릴리스 후보가 생성될 때, 전체 클린 분석을 실행하여 전체 애플리케이션에 대해 가장 정확한 분석 데이터를 제공하고 이전 실행의 간섭이 없도록 하는 것이 일반적으로 권장된다. 이러한 독립성은 최종 정책 스캔 결과와 규정 준수 보고서를 생성할 때 안전 및 보안 표준의 요구 사항인 경우가 많다.

Klocwork에서 차등 분석이 작동하는 방식

Klocwork에서 차등 분석이 작동하는 방식은 다음과 같다.

1. 서버 프로젝트에 연결

로컬 데스크톱 프로젝트 워크스페이스가 서버 프로젝트에 연결되면 Klocwork의 분석이 자동으로 작동한다.

2. 통합 분석 실행

Klocwork 통합 분석을 실행하고 그 결과를 Klocwork 서버에 푸시할 때마다 결과가 저장된다. 그리고 기존 코드베이스의 인터페이스 동작에 대한 세부 정보가 클라이언트 도구에 제공된다. 그런 다음 Klocwork 데스크톱이나 CI 도구에서 분석을 실행할 때마다 이 인터페이스 동작 정보가 나머지 시스템 컨텍스트의 기준선이 된다.

3. 변경된 코드의 차등 분석 실행

변경된 코드 분석을 수행할 때 Klocwork가 변경되지 않은 다른 함수나 메서드에 대한 호출을 감지하면(따라서 로컬에서도 분석되지 않음), 중앙 서버 데이터의 인터페이스 동작이 대신 코드 분석에 정보를 제공하는 데 사용된다.

차등 분석 예시

Klocwork를 사용한 차등 분석의 몇 가지 예시를 살펴보자.

데스크톱 분석

11행에서 초기화된 널 포인터는 14행과 21행의 호출을 통해 sendMessage(..)로 전달된다. 거기서 빠르게 역참조되어 프로그램이 충돌을 일으킨다. Klocwork의 데스크톱 도구 중 하나인 명령줄 kwcheck 도구나 Klocwork 데스크톱 GUI를 사용하여 main.c만 분석한다면 결함이 보이지 않을 것이다.

서버 분석

하지만 Klocwork 서버의 프로젝트에 통합 빌드 분석이 체크인되어 있다고 가정해 보자. 로컬 프로젝트를 해당 프로젝트에 연결한 다음 main.c를 재분석하면 결함을 볼 수 있다.

하지만 sendMessage(..)가 로컬에서 분석되지 않았기 때문에 역추적(traceback)은 sendMessage(..)의 세부 정보를 보여주지 않는다. 그러나 서버의 지식 베이스는 sendMessage(..)가 전달된 세 번째 인수를 역참조한다는 것을 보여준다. 이 정보를 사용하면 전체 코드베이스를 분석하지 않고도 코드를 커밋하기 전에 결함을 수정할 수 있다.

전체 프로젝트 분석

하지만 전체 프로젝트를 한 번에 분석한다면 어떨까? sendMessage(..)에 대한 역추적의 세부 정보를 볼 수 있다.

서버에 있는 지식 베이스는 거기에 체크인된 가장 최근 분석을 기반으로 한다. 이는 프로젝트의 메인 코드베이스에 대한 마지막 분석일 가능성이 높다. 하지만 특정 함수에 대한 지식 베이스 레코드는 자신의 워크스페이스 내에서 코드를 분석하여 얻을 수 있는 레코드와 다를 수 있다. 이는 커밋하는 코드가 곧 메인라인에 병합될 것이기 때문에 유익하다. 지금 보는 결함은 병합 후에 나타날 가능성이 크다. 이러한 유형의 분석을 통해 다음을 얻을 수 있다.

• 병합 후 발생할 결함의 미리보기
• 미리 수정할 수 있는 기회

차등 분석 사용 시작

Perforce Klocwork의 무료 7일 평가판에 등록하고 오늘부터 차등 분석을 사용해 보라.