정적 분석이란 무엇인가요?

정적 분석이란 무엇인가요?

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

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

정적 분석은 주로 다음을 탐지하는 데 사용됩니다.

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

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

모든 정적 분석 도구의 공통적인 기본 개념은 소스 코드를 검색하여 경고나 정보가 포함된 특정 코딩 패턴을 식별하는 것입니다.

"JUnit 5 테스트 클래스는 'public'일 필요가 없음"과 같은 간단한 것부터 "SQL 실행 문에 신뢰할 수 없는 문자열 입력이 사용됨"과 같이 식별하기 복잡한 것까지 다양합니다.

정적 분석 도구는 이러한 기능을 구현하는 방식에 따라 차이가 있습니다.

• 추상 구문 트리(AST)를 생성하기 위한 소스 코드 파싱 기술,
• 텍스트 정규 표현식 매칭,
• 위 방식들의 조합.

텍스트에 대한 정규 표현식 매칭은 매우 유연하고 규칙 작성이 쉽지만, 종종 많은 오탐(false positive)을 발생시킬 수 있으며 매칭 규칙이 주변 코드 문맥을 인식하지 못한다는 단점이 있습니다.

AST 매칭은 소스 코드를 단순한 텍스트 파일이 아닌 프로그램 코드로 취급하므로, 더 구체적이고 문맥을 고려한 매칭이 가능하며 코드에 대해 보고되는 오탐의 수를 줄일 수 있습니다.

지속적 통합(CI)에서의 정적 분석

정적 분석은 종종 지속적 통합(CI) 과정에서 수행되어 규정 준수 문제에 대한 보고서를 생성하며, 이를 검토하여 시간이 지남에 따라 코드베이스에 대한 객관적인 시각을 확보할 수 있습니다.

일부 개발자는 정적 분석 도구를 특정 코드 영역만 측정하고 규칙의 하위 집합에 대해서만 보고하도록 구성하여 코드 품질을 객관적으로 측정하는 지표로 활용합니다.

객관성은 사용된 규칙에서 비롯되는데, 이는 시간이 지나도 코드 평가 방식이 변하지 않기 때문입니다. 물론 사용되는 규칙의 조합과 구성은 주관적인 결정이며, 팀마다 상황에 따라 서로 다른 규칙을 선택하여 사용합니다.

CI에서 정적 분석을 수행하는 것은 유용하지만 프로그래머에게 피드백이 전달되는 시점이 늦어질 수 있습니다. 프로그래머는 코딩하는 즉시 피드백을 받는 것이 아니라, 나중에 정적 분석 도구를 통해 코드가 실행될 때 피드백을 받게 됩니다. 또한 CI에서 정적 분석을 실행할 경우의 또 다른 부작용은 결과가 무시되기 쉽다는 점입니다.

팀이 정적 분석 결과에 더 집중하도록 유도하기 위해, 빌드 과정에서 특정 지표(예: 규칙 위반 횟수)가 임계치를 초과할 경우 빌드를 실패하도록 설정하는 것이 일반적입니다.

IDE에서의 정적 분석

더 빠른 피드백을 받기 위해, 코드가 변경될 때마다 또는 필요에 따라 IDE 내에서 정적 분석 규칙을 실행하는 다양한 IDE 플러그인을 사용할 수 있습니다.

프로그래머가 코드를 작성하는 동안 IDE에서 규칙 위반 사항을 바로 확인할 수 있으며, 규칙을 무시하기 어렵게 만들기 위해 위반 사항을 에디터 내 밑줄로 표시하도록 설정하는 경우가 많습니다.

저는 개인적으로 정적 분석 도구가 지원하는 새로운 라이브러리를 다룰 때 이 방식이 코딩 실력을 향상하는 데 매우 유용하다고 생각합니다. 물론 오탐(false positive)이 많거나 관심 없는 규칙들로 인해 '소음'이 발생할 수도 있지만, 정적 분석 도구를 설정하여 특정 규칙을 무시하도록 조정하면 해결할 수 있습니다.

정적 분석 규칙에 따른 코드 수정

대부분의 정적 분석 도구에서 규칙 위반에 대한 수정은 프로그래머의 몫입니다. 따라서 프로그래머는 규칙 위반의 원인을 이해하고 이를 어떻게 해결할지 직접 판단해야 합니다.

수정 방법이 팀의 상황, 사용 기술, 합의된 코딩 스타일 등에 따라 크게 달라지기 때문에, 위반 사항을 자동으로 수정하는 기능을 포함한 정적 분석 도구는 매우 드뭅니다.

기본 규칙

정적 분석 도구에 기본 규칙이 포함되어 있으면 도구의 품질에 대해 잘못된 확신을 갖기 쉽습니다. 이러한 기본 규칙이 프로그래머가 겪을 수 있는 모든 문제와 모든 상황을 포괄한다고 믿기 쉽기 때문입니다. 하지만 규칙이 적용되어야 할 상황은 때때로 매우 미묘하여 감지하기 어려울 수 있습니다.

정적 분석 도구를 사용하고 규칙과 위반 사항을 자세히 연구함으로써, 프로그래머가 자신의 특정 도메인 맥락에서 문제를 감지하고 예방하는 능력을 기를 수 있기를 기대합니다.

도메인에 특화된 규칙이 필요할 때, 정적 분석 도구에는 해당 도메인이나 라이브러리에 맞는 규칙이 없을 수 있으며, 도구 자체를 설정하고 확장하는 작업이 어려울 때가 많습니다.

불편 사항

이러한 '불편 사항'들은 극복할 수 없는 문제가 아닙니다:

• 오탐(false positive)
• 수정 기능 부재
• 규칙 무시를 위한 설정
• 컨텍스트별 규칙 추가

하지만 이러한 점들은 종종 정적 분석 도구 도입을 피하기 위한 핑계로 사용되곤 합니다. 정적 분석은 다음과 같은 측면에서 매우 유용하게 활용될 수 있기에 이는 안타까운 일입니다:

• 주니어 개발자에게 더 나은 접근 방식 제시
• 명확한 코딩 위반 사항에 대한 빠른 피드백 확보
• 프로그래머가 이전에 경험하지 못한 모호한 문제 식별
• 프로그래머가 올바른 코딩 방식을 따르고 있음을 확인(위반 사항이 없을 경우)

IDE 기반 정적 분석 도구

프로젝트의 개별 기여자로서, 저는 코드에 대한 빠른 피드백을 받기 위해 IDE 내에서 실행되는 정적 분석 도구를 사용하는 것을 선호합니다.

이는 프로젝트에서 수행하는 풀 리퀘스트 리뷰 과정이나 CI 통합을 보완해 줍니다.

저는 업무 효율을 높이고 개인적인 작업 흐름을 개선해 줄 도구를 찾으려 노력합니다.

IDE 내에서 실행되는 도구들은 기본적인 GUI와 설정 방식이 비슷한 경우가 많아, 서로 대체 가능한 것으로 생각하기 쉽습니다.

도구들 간에 기능이나 규칙이 중복될 수 있지만, 각 도구의 강점을 최대한 활용하기 위해 저는 여러 도구를 함께 설치해 사용합니다.

제가 코딩할 때 실제로 사용하는 정적 분석 IDE 도구들은 다음과 같습니다.

• IntelliJ 내장 검사(Inspections) - 일반적인 코딩 패턴
• SpotBugs - 일반적인 오류
• SonarLint - 일반적인 사용 패턴
• CheckStyle - 일반적인 스타일 패턴
• Secure Code Warrior의 Sensei - 사용자 지정 규칙 생성

이 도구들은 서로의 기능을 보완하며 시너지를 내기 때문에 모두 함께 사용합니다.

IntelliJ 검사

IntelliJ를 사용 중이라면 이미 내장 검사 기능을 활용하고 계신 셈입니다.

이는 IDE에서 표시되는 정적 분석 규칙입니다. 일부 규칙은 문제를 해결하기 위해 코드를 자동으로 수정해 주는 QuickFix 옵션을 제공하기도 합니다.

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

IntelliJ에는 유용한 검사 기능이 매우 많습니다. 이 글을 쓰면서 직접 확인해 보니 정말 그렇더군요. 저는 기본 설정 그대로 사용하고 있지만, 검사 기능을 최대한 활용하려면 직접 목록을 읽어보고 본인의 코딩 스타일에 맞는 규칙을 찾아 경고 수준을 조정하는 것이 좋습니다.

IntelliJ 검사 기능의 가장 큰 장점은 IDE에 무료로 포함되어 있으며, 다음과 같은 습관을 기르는 데 도움을 준다는 점입니다.

• 코드를 작성하면서 소스 코드의 경고 및 오류를 즉시 확인하기
• 표시된 코드에 마우스를 올려 규칙 위반 사항 파악하기
• alt+enter를 사용하여 문제에 대한 QuickFix 적용하기

SpotBugs

SpotBugs IntelliJ 플러그인은 정적 분석을 통해 코드 내의 버그를 알려줍니다.

SpotBugs는 IntelliJ 환경 설정에서 코드를 스캔하도록 구성할 수 있으며, 실제 적용되는 규칙은 Detector 탭에서 확인할 수 있습니다.

저는 보통 코드를 작성하고 검토를 마친 뒤에 'Analyze Project Files Including Test Sources'를 실행하여 SpotBugs를 사용합니다.

이 과정은 버그, 죽은 코드(dead code), 그리고 명백한 최적화 지점을 찾는 데 큰 도움이 됩니다. 또한, 표시된 위반 사항을 조사하면서 어떻게 해결할지 고민하게 만들어 줍니다.

SpotBugs는 문제를 찾아내지만, 이를 해결하기 위한 QuickFix 기능은 제공하지 않습니다.

SpotBugs는 설정이 간편하며, IDE에서 객관적인 제2의 의견을 구할 수 있는 유용한 도구라고 생각합니다.

SonarLint

SonarLint 플러그인.

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

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

SonarLint는 빠른 수정(Quick Fix) 기능을 제공하지 않지만, 위반 보고서와 관련된 문서는 일반적으로 명확하고 상세하게 작성되어 있습니다.

저는 과거에 SonarLint를 사용하면서 새로운 Java 버전에서 제가 미처 알지 못했던 새로운 Java 기능을 알게 되어 유용했던 경험이 있습니다.

CheckStyle

The CheckStyle plugin offers a mix of formatting and code-quality rules.

CheckStyle 플러그인은 'Sun Checks' 및 'Google Checks'와 함께 번들로 제공됩니다.

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

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

CheckStyle은 CheckStyle 위반 횟수가 임계값을 초과할 경우 CI 프로세스에서 빌드를 실패하게 만드는 플러그인으로 매우 자주 사용됩니다.

Sensei

Sensei는 추상 구문 트리(AST) 기반의 정적 분석을 사용하여 코드를 매칭하고 빠른 수정(QuickFix)을 생성하므로, 문제가 있는 코드를 매우 구체적으로 식별할 수 있습니다.

AST를 사용하면 레시피와 관련된 빠른 수정 기능이 주변 코드를 이해할 수 있습니다. 예를 들어 코드에 새 클래스를 추가할 때 해당 클래스에 대한 import 문은 각 교체 시마다 추가되는 것이 아니라 소스 파일에 한 번만 추가됩니다.

Sensei는 다른 도구에는 존재하지 않거나 구성하기 어려운 사용자 지정 매칭 규칙을 쉽게 만들 수 있도록 제작되었습니다.

구성 파일을 수정하는 대신 모든 구성을 GUI에서 수행할 수 있습니다. 새로운 레시피를 만들 때 GUI를 통해 레시피가 어떤 코드와 일치하는지 쉽게 확인할 수 있습니다. 또한 빠른 수정 기능을 정의할 때 코드의 변경 전후 상태를 즉시 비교할 수 있습니다. 이를 통해 팀, 기술, 심지어 개별 프로그래머에게 고유한 매우 맥락적인 레시피를 더 쉽게 만들 수 있습니다.

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

저는 가끔 IntelliJ Intensions 세트에 이미 존재하는 Sensei 레시피를 만들곤 합니다. 이는 Intension 보고서가 제가 만든 맥락과 완전히 일치하지 않거나, IntelliJ에서 제공하는 빠른 수정 기능이 제가 사용하려는 코드 패턴과 맞지 않기 때문입니다.

저는 기존 도구를 완전히 대체하려 하기보다는 보완하는 방식으로 사용합니다.

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

Sensei는 언급된 정적 분석 도구들처럼 일반적인 레시피를 많이 포함하고 있지는 않지만, 사용자의 코딩 스타일과 유스케이스에 맞춰 QuickFix를 구성하고 새로운 레시피를 쉽게 만들 수 있다는 점이 강점입니다.

참고: 현재 일반적인 유스케이스를 다루는 공개 레시피 저장소를 준비 중이며, 여기에서 확인하실 수 있습니다.

요약

저는 서로 연동이 잘 되고, 설정이 가능하며, 제 특정 상황에 맞춰 쉽게 확장할 수 있는 도구를 선호합니다. 수년간 IDE에서 정적 분석 도구를 사용하여 문제를 식별하고, 제가 사용하는 프로그래밍 언어와 라이브러리에 대해 더 깊이 학습해 왔습니다.

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

• IntelliJ Intentions는 일반적인 코드 문제를 즉시 식별하고 종종 QuickFix를 제공합니다.
• SpotBugs는 제가 놓칠 수 있는 간단한 버그를 찾아내고 성능 문제를 알려줍니다.
• SonarLint는 제가 몰랐던 Java 기능을 식별하고 코드를 모델링하는 추가적인 방법을 제안합니다.
• CheckStyle은 CI 과정에서 강제되는 합의된 코딩 스타일을 준수하도록 돕습니다.
• Sensei는 정적 분석 도구가 발견한 일반적인 시나리오를 보완하는 QuickFix를 만들고, 다른 도구에서는 설정하기 어려운 특정 프로젝트나 기술 관련 레시피를 생성하도록 돕습니다.

---

IntelliJ 내의 "Preferences \ Plugins"(Mac) 또는 "Settings \ Plugins"(Windows)에서 "sensei secure code"를 검색하여 Sensei를 설치하세요.

일반적인 유스케이스에 대한 예제 코드와 레시피 저장소는 Secure Code Warrior GitHub 계정의 `sensei-blog-examples` 프로젝트에서 찾을 수 있습니다.

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

Sensei에 대해 더 알아보기