정적 분석이란

정적 분석이란

정적 분석은 애플리케이션을 실행하지 않고 소스 코드를 자동으로 분석하는 것입니다.

프로그램 실행 중에 분석이 수행되는 경우, 동적 분석이라고 합니다.

정적 분석은 다음을 검출하기 위해 자주 사용됩니다.

• 보안 취약점.
• 성능 문제.
• 표준 위반.
• 구식 프로그래밍 구성체의 사용.

정적 분석 도구는 어떻게 작동합니까?

모든 정적 분석 도구에 공통적으로 적용되는 기본 개념은 소스 코드를 검색하여 특정 코딩 패턴을 식별하고, 이에 경고나 정보를 연관시키는 것입니다.

이는 "JUnit 5의 테스트 클래스는 '공개'일 필요가 없다"와 같은 단순한 것일 수도 있습니다. 또는 "신뢰할 수 없는 문자열 입력이 SQL 실행문에 사용되고 있다"처럼 식별하기 어려운 것들도 있습니다.

정적 분석 도구는 이 기능의 구현 방식이 다릅니다.

• 추상 구문 나무(AST)를 생성하기 위한 소스 코드 분석 기술
• 텍스트 정규 표현식 매칭,
• 위의 조합.

텍스트에서의 정규 표현식 매칭은 매우 유연하여 일치시킬 규칙을 쉽게 기술할 수 있지만, 대부분의 경우 오탐이 다수 발생할 가능성이 있으며, 매칭 규칙은 주변 코드 컨텍스트를 인식하지 못합니다.

AST 기반 코드 비교에서는 소스 코드를 단순한 텍스트로 채워진 파일이 아닌 프로그램 코드로 처리합니다. 이를 통해 보다 구체적이고 상황에 맞는 비교가 가능해지며, 코드에 대해 보고되는 오탐지 수를 줄일 수 있습니다.

지속적 통합에서의 정적 분석

대부분의 경우 정적 분석은 지속적 통합(CI) 프로세스 중에 실행되어 컴플라이언스 문제 보고서를 생성합니다. 이 보고서를 검토하면 시간이 지남에 따라 코드베이스를 객관적으로 파악할 수 있습니다.

일부 코드 부분만 측정하고 규칙의 하위 집합만 보고하도록 정적 분석 도구를 구성함으로써, 정적 분석을 코드 품질의 객관적인 척도로 사용하는 사람들도 있습니다.

객관성은 사용되는 규칙에 의해 결정됩니다. 이러한 규칙들은 시간이 지나도 코드 평가에서 변하지 않기 때문입니다. 분명히, 사용되는 규칙의 조합과 그 구성은 주관적인 결정이며, 서로 다른 팀들은 서로 다른 시점에 서로 다른 규칙을 사용하기로 선택합니다.

CI에서 정적 분석을 실행하는 것은 편리하지만, 프로그래머에게 피드백이 늦게 전달될 수 있습니다. 프로그래머는 코딩 중에 피드백을 받지 못하고, 나중에 정적 분석 도구를 사용하여 코드를 실행할 때 피드백을 받게 됩니다. CI에서 정적 분석을 실행함으로써 발생하는 또 다른 부작용은 결과를 무시하기 쉬워진다는 점입니다.

팀이 정적 분석 결과를 쉽게 확인할 수 있도록, 일반적으로 빌드 프로세스에서 임계값 메트릭을 설정하여 해당 메트릭을 초과할 경우 빌드가 실패하도록 구성할 수 있습니다. 예를 들어, 다수의 규칙이 트리거된 경우 등이 해당됩니다.

IDE에서의 정적 분석

피드백을 더 빨리 받기 위해, IDE의 정적 분석 규칙을 필요할 때마다 또는 코드가 변경될 때마다 정기적으로 실행하는 IDE 플러그인이 많이 제공됩니다.

프로그래머가 코드를 작성할 때 IDE에서 규칙 위반을 확인할 수 있도록 하고, 규칙을 무시하기 어렵게 하기 위해, 에디터에서 위반 사항을 밑줄이 그어진 코드로 렌더링하도록 설정할 수 있는 경우가 많습니다.

개인적으로는 코딩을 개선하는 데 유용한 방법이라고 생각합니다. 특히 정적 분석 도구가 커버하는 새로운 라이브러리를 사용할 때 더욱 그렇습니다. 다만 오탐이나 관심 없는 규칙이 있을 경우 '잡음이 많다'고 느낄 수 있습니다. 하지만 정적 분석 도구를 설정하여 특정 규칙을 무시하도록 하는 추가 단계를 거치면 이 문제를 해결할 수 있습니다.

정적 분석 규칙에 기반한 코드 수정

대부분의 정적 분석 도구에서는 규칙 수정이 프로그래머에게 맡겨져 있으므로, 프로그래머는 규칙 위반의 원인과 수정 방법을 이해해야 합니다.

위반 사항을 수정하는 기능을 갖춘 정적 분석 도구는 거의 없습니다. 수정은 대부분 팀, 사용하는 기술, 그리고 합의된 코딩 스타일에 맞춰 수행되기 때문입니다.

기본 규칙

정적 분석 도구에 기본 규칙이 제공되면 규칙의 품질에 대한 잘못된 신뢰가 생길 수 있습니다. 프로그래머가 마주칠 수 있는 모든 문제와 해당 규칙이 적용되어야 할 모든 상황을 포괄한다고 믿고 싶어집니다. 규칙을 적용해야 할 상황은 미묘하여 쉽게 구분하기 어려울 수 있습니다.

정적 분석 도구를 사용하여 규칙과 위반 사항을 보다 상세히 조사함으로써, 프로그래머가 특정 도메인의 컨텍스트에서 문제를 발견하고 회피하는 기술을 습득할 수 있을 것으로 기대됩니다.

도메인에 컨텍스트 규칙이 필요한 경우, 정적 분석 도구에는 도메인 또는 라이브러리에 맞는 규칙이 없을 수 있으며, 또한 도구 구성이나 확장이 어려울 수 있습니다.

번거로움

이러한 '번거로움'은 어느 것도 극복할 수 없는 것이 아닙니다.

• 위양성
• 수정 부족
• 규칙을 무시하는 설정
• 컨텍스트별 규칙 추가

그러나 애초에 정적 분석 도구 사용을 피하기 위한 변명으로 자주 사용됩니다. 정적 분석은 다음과 같은 방법으로 매우 유용할 수 있기 때문에 안타깝습니다.

• 젊은 개발자에게 더 나은 접근 방식을 강조하다
• 명확한 코딩 위반에 대한 피드백을 신속하게 획득
• 프로그래머가 지금까지 경험해 본 적 없는 불명확한 문제를 식별한다
• (위반 사항이 보고되지 않은 경우) 프로그래머가 우수한 코딩 기법을 채택하고 있음을 강조한다

IDE 기반 정적 분석 도구

프로젝트에 개인 기여자로서, 코드에 대한 피드백을 신속하게 받을 수 있도록 IDE 내에서 실행되는 정적 분석 도구를 사용하는 것을 선호합니다.

이를 통해 풀 리퀘스트 검토 프로세스 및 프로젝트가 보유할 수 있는 CI 통합이 보완됩니다.

저는 자신에게 우위를 부여하고 개별적인 워크플로를 개선해 주는 도구를 찾도록 노력합니다.

IDE에서 도구를 실행할 때 기본적인 GUI와 구성 접근 방식은 동일한 경향이 있으므로, 동일한 방식으로 표시하고 싶을 수 있습니다.

도구에는 중복되는 기능이나 규칙 세트가 있을 수 있지만, 그 장점을 최대한 활용하기 위해 여러 도구를 설치하고 있습니다.

코딩 시 제가 적극적으로 사용하는 정적 분석 IDE 도구는 다음과 같습니다.

• 내장된 IntelliJ 검사기 - 일반적인 코딩 패턴
• 스팟 버그 - 자주 발생하는 오류
• SonarLint-일반적인 사용 패턴
• 체크 스타일 - 일반적인 스타일 패턴
• 시큐어 코드 워리어 강사 - 커스텀 규칙 생성

저는 그것들을 모두 사용하고 있습니다. 왜냐하면 그것들은 서로를 보완하며 잘 협력하기 때문입니다.

IntelliJ 검사

IntelliJ를 사용 중이라면 이미 해당 인스펙션을 사용하고 있는 것입니다.

이들은 IDE에서 플래그가 설정된 정적 분석 규칙입니다. 그 중에는 문제를 해결하기 위해 코드를 수정하는 QuickFix 옵션이 있는 것도 있습니다.

규칙은 켜기/끄기 설정이 가능하며, IDE에서 강조 표시할 오류 수준도 선택할 수 있습니다.

IntelliJ에는 훌륭한 검사 기능이 많이 있습니다. 이 글을 쓰는 동안 그들을 살펴보았기 때문에 잘 알고 있습니다. 저는 IntelliJ 검사 기능을 기본으로 사용하고 있지만 아직 설정하지는 않았습니다. 검사 기능을 최대한 활용하려면 검사 항목을 살펴보고 자신의 코딩 스타일과 관련된 검사 항목을 식별한 후, 코드 내에서 이를 인지할 수 있도록 경고 수준을 설정해야 합니다.

IntelliJ 검사 기능의 훌륭한 점은 IDE에 무료로 포함되어 있다는 점과 다음과 같은 근육 기억을 구축하는 데 도움이 된다는 점입니다.

• 코드를 작성할 때 소스 내의 경고나 오류를 발견한다
• 플래그가 설정된 코드에 커서를 올리면 규칙 위반 사항을 확인할 수 있습니다
• Alt+Enter 키를 사용하여 문제에 대한 빠른 수정 사항을 적용합니다.

스팟 버그

SpotBug IntelliJ 플러그인은 정적 분석을 사용하여 코드의 버그를 경고합니다.

SpotBugs는 IntelliJ 환경 설정에서 코드를 스캔하도록 설정할 수 있습니다. 실제로 사용되는 규칙은 Detector 탭에 있습니다.

저는 코드를 작성하고 리뷰한 후 SpotBugs를 사용하는 경향이 있으며, 그 후 '테스트 소스를 포함한 프로젝트 파일 분석'을 실행합니다.

이는 버그, 데드 코드, 명백한 최적화 기회를 식별하는 데 도움이 됩니다. 또한 플래그가 설정된 위반 사항 중 일부를 조사하여 어떤 조치를 취해야 할지 판단해야 합니다.

SpotBugs는 문제를 감지하지만, 문제를 해결하기 위한 빠른 수정 조치를 제공하지 않습니다.

SpotBugs는 설정이 간편하며, IDE에서 참고할 수 있는 객관적인 제2의 의견으로서 유용할 것 같습니다.

소나린트

ザ의 소나린트 플러그인.

SonarLint는 IntelliJ 환경 설정에서 설정하여 코드 검증 대상이 될 규칙을 선택할 수 있습니다.

기본적으로 SonarLint는 실시간으로 실행되어 편집 중인 현재 코드의 문제를 표시합니다.

SonarLint는 신속한 해결책을 제공하지는 않지만, 위반 보고와 관련된 문서는 일반적으로 명확하고 충분히 문서화되어 있습니다.

SonarLint는 지금까지 Java의 새 버전에서 인식했던 새로운 Java 기능에 대해 경고해 주기 때문에 편리했습니다.

체크 스타일

Z의 체크 스타일 플러그인은 포맷팅과 코드 품질 규칙을 결합하여 제공합니다.

CheckStyle 플러그인에는 'SunCheck'와 'GoogleCheck'가 번들로 포함되어 있습니다.

이러한 정의는 간단히 찾을 수 있습니다. 온라인에서 발견되었습니다.

CheckStyle은 프로젝트가 시간을 들여 자체 규칙 세트를 생성했을 때 가장 큰 가치를 제공합니다. 그렇게 하면 IDE 플러그인을 해당 규칙 세트를 사용하도록 설정할 수 있으며, 프로그래머는 코드를 CI에 커밋하기 전에 스캔을 실행할 수 있습니다.

CheckStyle은 CheckStyle 위반 건수가 임계값을 초과할 경우 CI 프로세스의 빌드 실패 플러그인으로 자주 사용됩니다.

선생님

선생님, 코드 검증과 빠른 수정(Quick Fix) 생성에 추상 구문 나무(AST) 기반 정적 분석을 사용합니다. 이를 통해 문제 있는 코드를 매우 구체적으로 식별할 수 있습니다.

AST를 사용하면 레시피와 관련된 QuickFix가 주변 코드를 이해할 수 있습니다. 예를 들어, 코드에 새로운 클래스를 추가할 경우 해당 클래스의 임포트는 소스 파일에 한 번만 추가되며, 교체할 때마다 추가되지 않습니다.

Sensei는 다른 도구에는 존재하지 않거나 설정이 어려운 맞춤형 매칭 규칙을 쉽게 구축할 수 있도록 만들어졌습니다.

설정 파일을 수정하는 대신 모든 설정을 GUI에서 수행할 수 있습니다. 새로운 레시피를 생성할 때 GUI에서는 레시피가 어떤 코드와 일치하는지 쉽게 확인할 수 있습니다. 또한 QuickFix를 정의하면 코드 수정 전후 상태를 즉시 비교할 수 있습니다. 이를 통해 팀이나 기술, 심지어 개별 프로그래머에게 특화된 레시피 등 매우 상황에 맞는 레시피를 손쉽게 만들 수 있습니다.

저는 Sensei를 다른 정적 분석 도구와 함께 사용하고 있습니다. 예를 들어, 대부분의 정적 분석 도구는 문제를 탐지하지만 수정하지는 않습니다. Sensei의 일반적인 사용 사례는 다른 도구의 일치 검색을 Sensei에서 복제하고 빠른 수정 기능으로 확장하는 것입니다. 이는 적용된 사용자 지정 수정이 이미 프로젝트의 코딩 표준을 충족한다는 장점이 있습니다.

Intension 보고서가 생성한 컨텍스트와 완전히 일치하지 않거나, IntelliJ가 제공하는 QuickFix가 사용하고자 하는 코드 패턴과 일치하지 않아, IntelliJ의 Intensions 세트에 이미 존재하는 Sensei 레시피를 정기적으로 생성하고 있습니다.

기존 도구를 완전히 대체하려는 것이 아니라, 기존 도구를 보완합니다.

Sensei는 공통 규칙의 컨텍스트 변형을 식별하는 데에도 매우 유용합니다. 예를 들어, 정적 분석 도구에서 지원되지 않는 SQL 라이브러리를 사용 중이지만 정적 분석 엔진의 공통 SQL 규칙이 계속 적용되는 경우, Sensei를 사용하여 해당 규칙의 라이브러리별 변형을 생성할 수 있습니다.

Sensei는 앞서 언급한 정적 분석 도구처럼 일반적인 레시피를 즉시 제공하는 것은 아닙니다. 그 강점은 특정 코딩 스타일이나 사용 사례에 맞춰 구성된 QuickFix를 사용하여 새로운 레시피를 쉽게 생성할 수 있다는 점입니다.

참고: 현재 일반적인 사용 사례를 지원하기 위해 레시피 공개 저장소를 생성 중입니다. 여기에서 찾을 수 있습니다.

요약

저는 연동하여 작동하고, 설정 가능하며, 특정 컨텍스트에 맞게 쉽게 확장할 수 있는 도구를 선택하는 경향이 있습니다. 문제를 파악하거나 사용 중인 프로그래밍 언어나 라이브러리에 대한 이해를 깊게 하기 위해, 오랫동안 IDE의 정적 분석 도구를 사용해 왔습니다.

위의 모든 도구를 조합하여 사용합니다.

• IntelliJ Intentions는 자주 발생하는 코드 문제를 즉시 보고하는 데 도움이 됩니다. 대부분의 경우 관련 빠른 수정 기능을 사용합니다.
• SpotBugs는 간과했을 수도 있는 단순한 버그를 찾아내고, 성능 문제를 알려줍니다.
• SonarLint는 제가 인지하지 못했던 Java 기능을 식별하고, 코드를 모델링하는 다른 방법을 알려줍니다.
• CheckStyle은 CI 중에도 적용되는 합의된 코딩 스타일에 부합하도록 돕습니다.
• 선생님은 정적 분석 도구에서 발견되는 일반적인 시나리오를 보완하거나, 다른 도구로는 구성이 어려운 특정 프로젝트나 기술 레시피를 만들기 위한 퀵픽스 생성을 도와줍니다.

---

「환경 설정\ 플러그인」(Mac) 또는 「설정\ 플러그인」(Windows)을 사용하여 IntelliJ 내에서 Sensei를 설치하고, 「sensei 보안 코드」를 검색하십시오.

일반적인 사용 사례의 샘플 코드와 레시피 저장소는Secure Code Warrior 계정의sensei 프로젝트에 있습니다.

https://github.com/securecodewarrior/sensei-blog-examples

선생님에 대해 더 알아보기