정적 분석이란 무엇인가?

정적 분석이란 무엇인가?

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

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

정적 분석은 다음과 같은 사항을 파악하기 위해 자주 사용됩니다:

• 보안 취약점.
• 성능 문제.
• 표준 미준수.
• 구식 프로그래밍 구조의 사용.

정적 분석 도구는 어떻게 작동하나요?

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

이는 "JUnit 5 테스트 클래스는 'public'일 필요가 없다"처럼 간단할 수도 있습니다. 또는 "SQL 실행 문에서 사용되는 신뢰할 수 없는 문자열 입력"처럼 식별하기 복잡한 것일 수도 있습니다.

정적 분석 도구는 이러한 기능을 구현하는 방식에 따라 서로 다릅니다.

• 추상 구문 트리(AST) 생성을 위한 소스 코드 파싱 기술
• 정규 표현식을 이용한 텍스트 비교
• 상기 사항들의 조합.

정규 표현식의 텍스트 일치 처리는 매우 유연하여 일치 규칙을 쉽게 작성할 수 있지만, 종종 많은 오탐 결과를 초래할 수 있으며 일치 규칙은 주변 코드 컨텍스트를 인식하지 못합니다.

AST 매칭은 소스 코드를 단순한 텍스트 파일로 취급하지 않고 프로그램 코드로 처리합니다. 이를 통해 보다 구체적이고 문맥에 기반한 일치를 가능하게 하여 코드에 대해 보고되는 오탐 결과를 줄일 수 있습니다.

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

정적 분석은 지속적 통합(CI) 프로세스 중에 수행되어 규정 준수 문제에 대한 보고서를 생성하며, 이를 검토함으로써 시간 경과에 따른 코드베이스에 대한 객관적인 개요를 얻을 수 있습니다.

일부 사용자는 정적 분석 도구를 특정 코드 부분만 측정하고 일부 규칙에 대해서만 보고하도록 구성함으로써 정적 분석을 코드 품질에 대한 객관적인 척도로 활용합니다.

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

CI에서 정적 분석을 수행하는 것은 유용하지만, 프로그래머에게 피드백을 제공하는 시기를 지연시킬 수 있습니다. 프로그래머는 코딩 중에 피드백을 받지 못하고, 코드가 정적 분석 도구를 통과한 후에야 피드백을 받게 됩니다. CI에서 정적 분석을 수행하는 또 다른 부작용은 결과가 무시되기 쉽다는 점입니다.

팀이 정적 분석 결과에 더 많은 주의를 기울이도록 유도하기 위해, 일반적으로 빌드 프로세스에서 임계값 메트릭을 구성할 수 있습니다. 이를 통해 해당 메트릭(예: 트리거된 규칙 수)이 초과될 경우 빌드가 실패하도록 설정할 수 있습니다.

IDE에서의 정적 분석

더 빠른 피드백을 얻기 위해, 코드 변경 시 필요에 따라 또는 정기적으로 IDE 내에서 정적 분석 규칙을 실행하는 다양한 IDE 플러그인이 존재합니다.

규칙 위반 사항은 프로그래머가 코드를 작성하는 동안 IDE에서 표시될 수 있습니다. 규칙을 무시하기 어렵게 하기 위해, 위반 사항은 편집기에서 밑줄이 그어진 코드로 표시되도록 구성할 수 있습니다.

개인적으로 저는 이 방법이 코딩 실력을 향상시키는 데 유용하다고 생각합니다. 특히 정적 분석 도구가 지원하는 새로운 라이브러리를 다룰 때 더욱 그렇습니다. 다만 오탐지나 관심 없는 규칙으로 인해 '시끄러울' 수 있습니다. 하지만 정적 분석 도구를 특정 규칙을 무시하도록 추가로 설정하는 단계를 거치면 이 문제는 해결됩니다.

정적 분석 규칙을 기반으로 한 코드 수정

대부분의 정적 분석 도구는 규칙 위반 시 수정 작업을 프로그래머에게 맡기므로, 프로그래머는 규칙 위반의 원인을 이해하고 이를 해결할 방법을 알아야 합니다.

매우 소수의 정적 분석 도구만이 위반 사항을 수정할 수 있는 기능을 제공하는데, 이는 수정이 종종 팀, 사용 중인 기술 및 합의된 코딩 스타일에 따라 달라지기 때문입니다.

표준 규칙

정적 분석 도구에 표준 규칙이 탑재되어 있을 경우, 규칙의 품질에 대한 잘못된 신뢰가 생길 수 있습니다. 이러한 규칙들이 프로그래머가 마주칠 수 있는 모든 문제와 규칙이 적용되어야 하는 모든 상황을 포괄한다고 믿고 싶은 유혹이 있습니다. 때로는 규칙이 적용되어야 하는 상황이 미묘하여 쉽게 알아차리기 어려울 수 있습니다.

정적 분석 도구 사용과 규칙 및 위반 사항에 대한 보다 세밀한 검토를 통해 프로그래머들이 특정 도메인 맥락에서 문제를 인식하고 회피하는 능력을 기를 수 있을 것이라는 기대가 있다.

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

성가신 일들

이러한 "성가신 일들" 중 어느 것도 극복할 수 없는 것은 없습니다:

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

그러나 이러한 문제점들은 정적 분석 도구 사용을 아예 피하기 위한 변명으로 자주 이용되곤 하는데, 이는 매우 안타까운 일입니다. 정적 분석 도구를 활용하면 다음과 같은 측면에서 매우 유용할 수 있기 때문입니다:

• 신진 개발자를 위한 더 나은 접근법 강조
• 명확한 코딩 위반 사항에 대한 신속한 피드백을 받으세요
• 프로그래머가 한 번도 마주치지 않은 희귀한 문제를 식별하십시오
• (위반 사항이 보고되지 않는 한) 프로그래머가 적절한 코딩 방식을 선택했음을 확인합니다.

IDE 기반 정적 분석 도구

프로젝트의 단독 참여자로서 저는 IDE 내에서 실행되는 정적 분석 도구를 즐겨 사용합니다. 이를 통해 코드에 대한 신속한 피드백을 얻을 수 있기 때문입니다.

이는 프로젝트가 가질 수 있는 모든 풀 리퀘스트 검토 프로세스와 CI 통합을 보완합니다.

저는 제게 이점을 제공하고 개인적인 작업 흐름을 개선해 줄 도구를 찾으려고 노력합니다.

IDE에서 실행되는 도구들은 일반적으로 동일한 기본 GUI와 구성 방식을 사용하기 때문에, 이를 동의어로 간주하고 싶은 유혹이 있을 수 있습니다.

도구들은 기능이나 규칙 세트가 중복될 수 있지만, 최대한의 효과를 얻기 위해 여러 도구를 설치하여 각자의 장점을 활용합니다.

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

• 내장된 IntelliJ 검사 — 일반적인 코딩 패턴
• SpotBugs — 자주 발생하는 오류
• SonarLint — 일반적인 사용 패턴
• CheckStyle - 일반적인 스타일 패턴
• Secure Code Warrior Sensei Secure Code Warrior 사용자 정의 규칙 생성

저는 그들을 모두 사용합니다. 왜냐하면 그들은 서로를 보완하고 보충하기 위해 함께 잘 작동하기 때문입니다.

IntelliJ 검사

IntelliJ를 사용 중이라면 이미 해당 검사 기능을 사용하고 계십니다.

이들은 IDE에서 표시되는 정적 분석 규칙입니다. 일부 규칙에는 문제를 해결하기 위해 코드를 재작성할 수 있는 QuickFix 옵션도 포함되어 있습니다.

규칙은 켜고 끌 수 있으며, IDE에서 규칙이 강조 표시되는 오류 수준을 선택할 수 있습니다.

IntelliJ 검사 기능은 매우 유용합니다. 제가 이 글을 작성하면서 직접 살펴본 결과입니다. 저는 IntelliJ 검사 기능을 기본값으로 사용하며 별도로 구성하지 않았지만, 검사 기능을 최대한 활용하려면 각 기능을 꼼꼼히 살펴보고 자신의 코딩 스타일에 적합한 항목을 식별한 후, 코드에서 해당 경고가 눈에 띄도록 경고 수준을 설정해야 합니다.

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

• 소스 코드 작성 중 경고 및 오류 감지
• 마우스 포인터를 표시된 코드 위로 이동하면 규칙 위반 사항을 확인할 수 있습니다.
• Alt+Enter를 눌러 문제에 대한 빠른 수정(QuickFix)을 적용하세요.

버그를 식별하다

버그 탐지 IntelliJ 플러그인은 정적 분석을 사용하여 코드 내 오류를 알려줍니다.

스팟버그는 IntelliJ 설정에서 코드 스캔을 구성할 수 있습니다. 실제 사용되는 규칙은 '검출기' 탭에서 확인할 수 있습니다.

코드를 작성하고 검토한 후에는 SpotBugs를 사용하는 편입니다. 그런 다음 "테스트 소스를 포함한 프로젝트 파일 분석" 옵션을 실행합니다.

이는 오류, 사양된 코드 및 명백한 최적화 부분을 식별하는 데 도움이 됩니다. 또한 보고된 위반 사항 중 일부를 조사하도록 강제하여 어떤 조치를 취할지 결정하는 데 도움을 줍니다.

SpotBugs는 문제를 발견하지만, 해당 문제를 해결하기 위한 빠른 수정 작업을 제공하지는 않습니다.

SpotBugs는 설정하기 쉽고, 제 IDE에서 얻을 수 있는 유용한 객관적인 두 번째 의견이라고 생각합니다.

소나 린트

Das Sonar Lint 플러그인.

SonarLint는 IntelliJ 설정에서 코드 유효성 검사에 사용할 규칙을 선택하도록 구성할 수 있습니다.

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

SonarLint은 빠른 해결책을 제공하지는 않지만, 위반 사항 보고서에 첨부된 문서화는 일반적으로 명확하고 잘 정리되어 있습니다.

저는 과거에 SonarLint가 최신 Java 버전에서 제공되는 새로운 기능들을 알려주는 데 유용하다고 느꼈습니다.

여전히 확인 중

스타일 검사 플러그인은 서식 규칙과 코드 품질 규칙을 혼합하여 제공합니다.

CheckStyle 플러그인은 "Sun Checks" 및 "Google Checks"와 함께 패키지로 제공됩니다.

이러한 정의들은 온라인에서 쉽게 찾을 수 있습니다.

CheckStyle은 프로젝트가 자체 규칙 세트를 구축하는 데 시간을 투자했을 때 가장 큰 가치를 제공합니다. 그런 다음 IDE 플러그인을 해당 규칙 세트를 사용하도록 구성할 수 있으며, 프로그래머는 코드를 CI로 넘기기 전에 스캔을 실행할 수 있습니다.

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

Sensei

Sensei 선생님은 추상 구문 트리(AST)를 기반으로 한 정적 분석을 사용하여 코드를 비교하고 빠른 수정(QuickFixes)을 생성합니다. 이를 통해 문제가 있는 코드를 매우 구체적으로 식별할 수 있습니다.

AST는 레시피에 할당된 QuickFixes가 주변 코드를 이해할 수 있게 합니다. 예를 들어, 코드에 새 클래스가 추가될 때 해당 클래스에 대한 각 임포트는 소스 파일에 한 번만 추가되고 각 대체에 대해 추가되지 않습니다.

Sensei 다른 도구에서는 존재하지 않거나 구성하기 어려울 수 있는 사용자 정의 매칭 규칙을 쉽게 생성할 수 있도록 Sensei .

구성 파일을 수정하는 대신, 전체 구성을 GUI에서 수행할 수 있습니다. 새로운 레시피를 생성할 때 GUI를 통해 해당 레시피가 어떤 코드에 적합한지 쉽게 파악할 수 있습니다. 또한 퀵픽스(QuickFixes)를 정의할 때 코드의 수정 전후 상태를 즉시 비교할 수 있습니다. 이를 통해 매우 컨텍스트 중심적인 레시피를 더 쉽게 생성할 수 있습니다. 즉, 팀, 기술, 심지어 개별 프로그래머에 특화된 레시피를 만들 수 있습니다.

저는 Sensei 다른 정적 분석 도구와 Sensei 사용합니다. 예를 들어, 대부분의 정적 분석 도구는 문제를 발견하지만 해결하지는 못합니다. Sensei 일반적인 사용 사례는 다른 도구의 검색을 Sensei 빠른 수정(Quick Fix)으로 확장하는 Sensei . 이렇게 하면 적용된 사용자 정의 수정이 이미 프로젝트의 코딩 표준을 준수한다는 장점이 있습니다.

정기적으로 Sensei 레시피를 생성합니다. 이는 IntelliJ 의도(Intention) 세트에 이미 포함되어 있지만, 생성한 컨텍스트와 의도 보고서가 완전히 일치하지 않거나 IntelliJ에서 제공하는 빠른 수정(QuickFix)이 사용하려는 코드 패턴과 일치하지 않기 때문입니다.

기존 도구를 완전히 대체하려 하기보다는 보완합니다.

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

Sensei 언급된 정적 분석 도구들처럼 많은 일반적인 레시피를 Sensei . 그 강점은 특정 코딩 스타일과 사용 사례에 맞게 구성된 퀵픽스(QuickFixes)를 포함하여 새로운 레시피 생성을 단순화하는 데 있습니다.

참고: 우리는 일반적인 사용 사례를 다루기 위한 공개 레시피 아카이브를 구축 중이며 여기에서 확인할 수 있습니다에서 확인할 수 있습니다.

요약

저는 특정 상황에 맞게 함께 작동하고, 구성 가능하며, 쉽게 확장할 수 있는 도구를 선택하는 경향이 있습니다. 수년간 IDE 내 정적 분석 도구를 사용하여 문제를 식별하고 제가 사용하는 프로그래밍 언어와 라이브러리에 대해 더 깊이 이해해 왔습니다.

저는 언급된 모든 도구를 조합하여 사용합니다:

• IntelliJ Intentions는 자주 발생하는 코드 문제를 즉시 식별하는 데 도움을 주며, 종종 관련 퀵픽스와 함께 제공됩니다.
• SpotBugs는 제가 간과했을 수 있는 간단한 오류를 찾아내고 성능 문제를 경고해 줍니다.
• SonarLint는 제가 알지 못했던 Java 기능을 식별하고, 제 코드를 추가로 모델링하도록 요구합니다.
• CheckStyle은 CI 과정에서도 적용되는 합의된 코딩 스타일을 준수하도록 도와줍니다.
• Sensei 정적 분석 도구로 발견된 일반적인 시나리오를 확장하기 위한 퀵픽스(QuickFixes)를 작성하는 데 Sensei , 다른 도구에서는 구성하기 어려운 특정 프로젝트나 기술 레시피를 만드는 데도 도움을 Sensei .

---

Sensei 설치하려면 Mac의 경우 "Preferences\ Plugins", Windows의 경우 "Settings\ Plugins"로 이동한 후 "Sensei Code"를 검색하세요.

일반적인 사용 사례에 대한 예제 코드와 레시피가 포함된 저장소는 Secure Code Warrior GitHub 계정 내 `sensei` Secure Code Warrior 확인할 수 있습니다.

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

Sensei에 대해 더 알아보기