Ch20 정적 분석

한 줄 정의

정적 분석(static analysis, 프로그램을 실행하지 않고 소스 코드만으로 버그·안티패턴을 찾아내는 기법)의 성패는 알고리즘이 버그를 얼마나 많이 잡느냐(거짓 음성↓)가 아니라, 개발자가 그 결과를 실제로 신뢰하고 고치느냐(유효 거짓 양성↓)에 달려 있습니다. 이 장의 핵심 주장은 정적 분석은 기술의 문제가 아니라 개발자 경험의 문제이며, 워크플로에 녹이고 누구나 검사를 기여할 수 있게 할 때 비로소 확장된다는 것입니다. 구글의 Tricorder가 그 표본입니다.

쉽게 말하면

집에 다는 화재경보기를 떠올려 봅니다.

좋은 경보기를 고르는 기준이 ‘연기 분자를 얼마나 민감하게 감지하느냐’일 것 같지만, 실제로 중요한 건 그게 아닙니다. 토스트를 살짝 태울 때마다 째질 듯 울어대는 경보기는 기술적으로는 ‘진짜 연기’를 정확히 감지한 것이지만, 며칠 못 가 천장에서 배터리를 뽑아버리게 만듭니다. 그리고 배터리가 빠진 그 순간부터는 정말로 불이 나도 아무도 모릅니다. 즉 경보기의 성패는 감도가 아니라 “사람이 계속 귀를 기울이느냐” 에 달려 있습니다.

정적 분석 도구가 정확히 이 화재경보기입니다. 이 장 전체는 결국 “버그를 한 톨도 놓치지 않는 똑똑한 경보기를 만드는 게 아니라, 개발자가 알람을 뽑아버리지 않고 매번 실제로 고치게 만드는 경보기를 만들어라” 는 이야기입니다.

그래서 구글은 ‘얼마나 많은 버그를 잡느냐(감도)‘가 아니라 ‘개발자가 알람을 듣고 정말로 행동하느냐(유효 거짓 양성)‘를 핵심 지표로 삼고, 경보기를 부엌 한가운데(코드 리뷰 워크플로)에 달며, 누구나 자기 집에 맞는 새 센서(검사 항목)를 붙일 수 있게 했습니다. 토스트 알람을 줄이는 데 모든 노력을 쏟은 이유가 여기 있습니다 — 한 번 신뢰를 잃은 경보기는 진짜 불도 막지 못하기 때문입니다.

왜 중요한가?

정적 분석을 이용하면 프로덕션에 밀어 넣기 전에 버그를 잡아낼 수 있습니다. 오버플로를 일으키는 상수 표현식, 실행되지 않는 테스트, 실행하면 비정상 종료를 부르는 잘못된 포맷 문자열 등 프로그램을 돌려보지 않고도 찾아냅니다.

하지만 가치는 버그 찾기에서 끝나지 않습니다. 정적 분석은 모범 사례를 코드 전반에 퍼뜨리고, 최신 API를 쓰도록 유도하며, 기술 부채를 막거나 줄여줍니다. 명명 규칙을 지키는지 검증하고, 폐기 대상 API를 쓰려 하면 알려주고, 같은 의미의 더 간단한 표현식을 제안해 가독성을 높여줍니다. 특히 Ch15 폐기에서 다루는 API 폐기 프로세스에서는 새 API로 마이그레이션하는 동안 역행이 일어나지 못하게 막는 가드레일 역할을 합니다. 개발자 교육에도 유용하고, 코드베이스에 안티패턴이 스며드는 것을 걸러줍니다.

거대한 코드베이스일수록 이 효과가 큽니다. 수십억 줄짜리 구글 코드베이스에는 쉽게 잡을 수 있는 버그가 많이 숨어 있어서, 분석 능력을 키우면 곧바로 혜택으로 돌아옵니다.

그런데 정작 어려운 건 알고리즘이 아닙니다. 도구가 쓸모없는 경고를 쏟아내 신뢰를 잃으면 개발자는 결과를 무시하고, 무시당하기 시작하면 진짜 버그 경고마저 함께 묻힙니다. 분석 기법 연구는 수십 년 전부터 있었지만 확장성과 유용성 연구가 최근에야 시작된 이유가 이것입니다. 정적 분석을 ‘기술 문제’가 아니라 ‘개발자 경험 문제’로 바라봐야 비로소 도구가 실제로 굴러갑니다.

핵심 내용

효과적인 정적 분석의 두 축 — 확장성과 유용성

확장성 — 전부 분석하지 않고, 바뀐 것만 점진적으로

소프트웨어 덩치가 커지면 분석 시간도 늘어나 개발 프로세스 전체가 느려집니다. 구글의 도구는 수십억 줄을 다뤄야 하므로, 거대한 프로젝트 전체를 매번 분석하는 대신 보류 중인 변경에 영향받는 파일·라인만 점진적으로 분석 하는 길을 택했습니다. 보통은 편집된 파일이나 라인과 연관된 결과만 보여줍니다.

확장성에는 두 가지 결이 있습니다.

• 코드 규모 확장 : 코드량이 아무리 많아져도 결과를 제때 내놓을 수 있어야 합니다.
• 분석 기법 확장 : 새로운 검사를 하나 추가하면 그것이 회사 전체의 코드를 훑어줍니다. 즉 검사를 늘리는 일 자체가 쉽게 확장되어야 합니다.

또한 분석 결과를 관련 엔지니어에게 직접 보여줌으로써 개발 프로세스에 병목이 생기지 않게 합니다. 결과가 따로 모이는 대시보드로 빠지지 않고 작업 흐름 위에 바로 나타나는 것이 확장성의 일부입니다.

유용성 — 비용-편익 트레이드오프

분석의 유용성은 사용자의 비용-편익 트레이드오프(cost-benefit trade-off) 로 따져야 합니다. 여기서 ‘비용’은 개발 시간만이 아니라 코드 품질까지 포함합니다. 경고를 고치다가 새 버그가 꼬일 수 있기 때문입니다.

경고를 고치는 것이 더 위험할 때

자주 수정되지 않고 프로덕션에서 잘 도는 코드라면 굳이 고칠 이유가 약합니다. 예컨대 ‘죽은 코드’ 경고를 없애려고 그 코드를 호출하는 로직을 새로 추가한다면, 지금껏 테스트되지 않아 버그가 숨어 있을지 모르는 코드가 갑자기 실행되게 만드는 꼴입니다. 편익은 불분명하고 잠재 비용은 매우 클 수 있습니다.

이런 이유로 구글은 새로 추가·수정된 코드에서 나는 경고에 집중 하고, 잘 도는 기존 코드의 이슈는 보안이나 심각한 버그처럼 정말 중요할 때만 부각합니다. 새 코드의 경고는 곧 개발자가 지금 하고 있는 작업 과 밀접하다는 뜻이라 맥락이 살아 있습니다. 여기에 자동 수정으로 해결 비용을 더 낮추고, 오히려 품질을 떨어뜨리는 분석이면 곧장 신고할 수 있는 통로를 두어 가치 없는 일에 시간을 낭비하지 않게 합니다.

핵심 지표를 다시 정의하다 — 유효 거짓 양성

정적 분석 지표에는 두 종류의 오류가 있습니다.

• 거짓 음성(false negative) : 잡도록 설계된 문제를 놓치는 것.
• 거짓 양성(false positive) : 문제가 없는데 있다고 보고하는 것.

학계는 전통적으로 거짓 음성을 낮추는 데 집중했습니다. 하지만 도구를 쓰고 싶게 만드는 데는 오히려 거짓 양성을 낮추는 편이 훨씬 효과적입니다. 후보 수백 개짜리 리포트를 받아 분석해보니 진짜 문제는 몇 개뿐이라면, 다음부터는 그 도구를 켜지 않게 됩니다.

여기서 한 단계 더 들어가는 통찰이 유효 거짓 양성(effective false positive) 입니다. 핵심은 거짓 양성이 기술적 사실이 아니라 인식(perception) 의 문제라는 점입니다. 진짜 문제를 정확히 경고했더라도 메시지가 헷갈리거나 큰 흐름에서 사소하면, 사용자는 그것을 거짓 양성처럼 취급하고 무시합니다. 그래서 구글은 지표의 기준을 도구에서 사람으로 옮겨, 개발자가 긍정적인 조치를 취하지 않은 모든 경우 를 유효 거짓 양성이라 부릅니다.

자바 해시 테이블의 contains() 경고

어떤 코드가 해시 테이블에서 containsValue()와 같은 기능인 contains()를 호출하는데, 분석 도구가 “containsKey()를 호출해야 하는 것 아니냐”고 경고했다고 해봅니다.

• 개발자가 원래 값(value)을 확인하려던 의도였다면 이 경고는 기술적으로는 틀렸습니다. 그래도 containsValue()로 바꾸는 편이 더 명확하므로 기꺼이 고친다면 → 유효 거짓 양성이 아닙니다.
• 반대로 분석 도구가 진짜 오류를 정확히 보고했더라도 무엇이 문제인지 개발자가 이해하지 못해 아무 조치도 하지 않으면 → 유효 거짓 양성입니다.

지표가 “도구가 옳았는가”에서 “개발자가 움직였는가”로 이동한다는 것이 이 절의 핵심입니다.

보안 분석은 예외

거짓 양성이 매우 많아도 리뷰어가 불평하지 않는 부류가 있습니다. 보안 문제처럼 진짜 하나를 놓치는 비용이 압도적으로 클 때는, 거짓 양성을 감수하고서라도 진짜를 한 건이라도 더 잡는 쪽이 옳습니다.

세 가지 핵심 교훈

확장성과 유용성을 높이려는 모든 선택은 결국 다음 세 교훈으로 수렴합니다.

1. 개발자 행복에 집중하자 — 유효 거짓 양성을 낮추고, 사용자와 분석기 작성자를 잇는 피드백 루프를 구축해 신뢰를 쌓습니다.
2. 정적 분석을 개발자 워크플로에 반드시 끼워 넣자 — 특히 코드 리뷰입니다.
3. 사용자가 기여할 수 있도록 하자 — 도메인 전문가의 지식을 검사 항목으로 흡수합니다.

왜 코드 리뷰가 이상적인 통합 지점인가

Ch19 Critique 구글의 코드 리뷰 도구에 정적 분석을 통합하면 여러 이점이 한꺼번에 따라옵니다. 구글에서는 커밋되는 모든 코드가 사전 리뷰를 거치므로, 리뷰에 통합한다는 것은 곧 모든 변경을 검사한다는 뜻입니다. 게다가 리뷰용으로 코드를 보냈다는 건 이미 “피드백을 주면 고칠 마음의 준비가 됐다” 는 신호라 개선 제안이 큰 저항 없이 반영됩니다. 작성자가 리뷰어의 응답을 기다리는 몇 분은 분석을 돌리기에 딱 좋은 타이밍이고, 리뷰어가 경고를 함께 보며 해결을 압박해줄 수도 있습니다. 흔한 문제를 자동으로 부각해 리뷰어의 시간까지 아껴줍니다.

왜 사용자 기여가 확장의 열쇠인가

구글에는 코드를 개선할 전문 지식을 갖춘 도메인 전문가가 많습니다. 정적 분석은 이 지식을 검사 항목으로 응결시켜 널리 퍼뜨리는 통로입니다. 그래서 생태계를 소수의 도구에 욱여넣기보다 플러그인하기 쉽게 만드는 데 집중했습니다. 간단한 API를 제공해 분석·언어 전문가뿐 아니라 엔지니어 누구든 분석기를 만들 수 있게 한 것입니다. 새로 발견한 버그가 코드베이스 다른 곳에서 재발하지 않도록 막는 검사를 직접 추가하는 식입니다.

Tricorder — 세 교훈을 구현한 플랫폼

구글 정적 분석의 핵심에는 Tricorder 가 있습니다. 몇 차례 실패 끝에 탄생했고, 이전 실패작과 결정적으로 다른 점은 사용자에게 가치 있는 결과만 제공하는 데 모든 노력을 쏟았다 는 것입니다. Tricorder는 Critique에 통합되어 디프 뷰어에 회색 댓글 상자로 경고를 표시합니다.

마이크로서비스 아키텍처

확장하기 쉽도록 여러 대의 분석 서버를 둡니다. 변경된 코드와 메타데이터를 함께 보내 분석을 요청하면, 서버는 메타데이터로 변경 파일의 버전을 알아내 FUSE 기반 파일시스템에서 읽어 들이고, 캐시된 빌드 입력·결과물까지 가져와 분석기를 하나씩 실행합니다. 결과는 스토리지 계층에 기록되고, 분류별 최신 결과가 Critique에 표시됩니다. 분석이 끝나기까지 수 분이 걸리므로 진행 중·완료 상태를 갱신해 알려줍니다. Tricorder 분석기들은 매일 5만 개 이상의 코드 리뷰 를 검사하며, 초당 몇 개씩 도는 경우도 흔합니다.

검사 항목 추가의 네 가지 조건

누구나 분석기를 작성하거나 기존 분석기에 검사 항목을 추가해 기여할 수 있되, 다음 네 조건을 충족해야 합니다.

조건	의미
이해하기 쉬움	모든 엔지니어가 결과를 쉽게 이해할 수 있어야 함
실행 가능·수정 용이	컴파일러 검사보다 고치기 어려울 수 있으므로, 결과에 해결 방법 안내 가 포함되어야 함
유효 거짓 양성 10% 미만	개발자가 적중률을 최소 90% 이상으로 느껴야 함
큰 품질 개선 잠재력	정확성과 무관하더라도, 개발자가 진지하게 받아들이고 의식적으로 고칠 만한 문제여야 함

분석기는 30개 이상의 언어를 다양한 관점에서 분석하며, 그 수가 100개를 넘습니다. 대부분 Tricorder팀이 직접 만든 게 아니라 다른 팀 개발자들이 기여한 것이고, 그중 7개는 자체 플러그인 시스템을 갖춰 검사 항목을 수백 개씩 제공합니다. 평균 유효 거짓 양성 비율은 5%를 약간 밑돕니다.

통합된 분석기 생태계

Tricorder에는 성격이 다른 여러 분석 도구가 통합되어 있습니다.

• Error Prone(자바) · clang-tidy(C++) : 컴파일러를 확장해 AST(추상 구문 트리) 안티패턴을 검출합니다. 예를 들어 long 필드 f를 해싱하는 코드가 있습니다.

result = 31 * result + (int) (f ^ (f >>> 32));

f의 타입이 사실 int라면 컴파일은 되지만 32칸 오른쪽 시프트는 의미가 없어, 이 코드는 그저 f를 자기 자신과 XOR하는 꼴이라 출력에 아무 변화가 없습니다. 이 검사를 컴파일 에러로 분류하자 코드베이스에서 버그 31개가 발견됐습니다. AST 안티패턴은 스마트 포인터의 .get() 중복 호출을 제거하는 등 가독성 개선에도 쓰입니다.

• 파일 간 관계 분석 : Deleted Artifact는 문서·주석 등 코드가 아닌 텍스트가 참조하는 파일이 지워지면 경고합니다. IfThisThenThat은 두 파일에서 반드시 함께 바꿔야 하는 부분을 지정해 한쪽만 변경되면 경고합니다. 크롬의 Finch는 A/B 테스트 설정 파일에서 승인 없는 실험 시작이나 모집단 충돌 같은 문제를 RPC로 정보를 받아 검출합니다.

• 아티팩트 검사 : 변경 후 바이너리가 너무 커지거나 작아지면 경고하는 바이너리 크기 검사 등이 있습니다.

거의 모든 분석기는 하나의 함수(프로시저) 범위 안 에서 검사합니다. 여러 함수를 조합하거나 점증적으로 분석하는 것도 기술적으로는 가능하지만 인프라 투자(예: 메서드 요약 정보 저장)가 훨씬 많이 필요합니다.

피드백 채널 — 교훈 1의 구현체

Tricorder는 분석 결과마다 [Not useful] 버튼을 답니다. 결과가 쓸모없는 이유를 관련 정보가 자동으로 채워진 채로 분석기 작성자에게 직접 버그 리포트 로 보낼 수 있습니다. 반대로 리뷰어는 [Please fix] 로 작성자에게 조치를 요청합니다. Tricorder팀은 (특히 리뷰어가 수정을 요청했는데도) [Not useful] 비율이 높고 이를 낮추려는 움직임이 없는 분석기를 비활성화 합니다.

이 채널을 명확히 만들기 전에는 많은 개발자가 이해 못 한 결과를 그냥 무시하고 넘어갔습니다. 원인이 의외로 단순할 때도 많습니다.

Guava printf 유사 함수 — 메시지만 다듬어 해결

인수가 너무 많이 전달되면 경고하는 검사를 배포했는데, 이 함수는 여러 지정자 중 %s만 허용합니다. “지정자 수와 인수 수가 일치하는데 왜 버그냐”는 ‘Not useful’ 리포트가 매주 날아왔습니다. 사용자가 %s 외의 지정자를 써서 벌어진 일이었고, 분석 자체는 틀리지 않았으나 읽는 이가 기존 지식 탓에 오해하기 쉬웠을 뿐입니다. 진단 메시지를 “이 함수는 %s만 지원한다”로 고치자 리포트가 끊겼습니다. 메시지가 무엇이(what)·왜(why)·어떻게(how) 를 가장 적절한 지점에서 바로 설명하면 개발자는 읽자마자 상황을 이해합니다.

수정 제안 — 해결 비용을 0에 가깝게

Tricorder 검사는 가능하면 어떻게 고칠지 까지 제안합니다. 자동 수정은 메시지가 불분명할 때 또 다른 문서 역할을 하면서 해결 비용을 낮춥니다. Critique 안에서 바로 적용하거나, 명령줄 도구로 특정 변경과 관련한 수정 전체를 한 번에 반영할 수도 있습니다. 특히 코드 스타일 문제는 포맷터로 자동 수정되며, 이를 위해 구글은 언어별 스타일 가이드를 마련해 활용합니다.

규모로 보면 [Please fix] 클릭은 매일 수천 번이고 그중 약 3,000번이 자동 수정으로 해결되며, [Not useful] 클릭은 매일 250번 정도입니다.

프로젝트별 맞춤 설정과 사용자별 설정 금지

적중률 높은 결과로 신뢰를 쌓은 다음에는 기본 분석기 외에 프로젝트별 ‘선택적’ 분석기 를 추가할 수 있게 했습니다. 대표적으로 Proto Best Practices는 프로토콜 버퍼에서 잠재적 호환성 파괴 변경을 찾아줍니다(직렬화 데이터를 저장해두고 쓰는 경우에만 의미가 있으니, 그렇지 않은 프로젝트는 켤 이유가 없습니다). 선택적으로 시작했다가 사랑받아 기본으로 승격되기도 합니다.

핵심은 설정 단위가 사용자가 아니라 프로젝트 라는 점입니다.

사용자별 설정이 버그를 감춘다

초기에는 개별 사용자가 분석기의 신뢰 수준을 고르거나 비활성화할 수 있었습니다. 그러다 이를 완전히 막자 “짜증 난다”는 원성이 쏟아졌습니다. 그래도 되살리지 않았습니다. 대신 짜증의 원인 을 추적해 린터가 쏟던 버그와 거짓 양성을 모조리 잡아냈습니다(예: C++ 린터가 Objective-C 파일까지 검사하던 문제 수정, 거짓 양성투성이 HTML 린터는 아예 비활성화). 사용자별 설정을 허용하면 누구는 문제를 심고 누구는 고치는 분열이 생기고, 무엇보다 버그를 감추고 원활한 피드백을 가로막습니다. 모든 팀원이 일관된 결과를 보려면 프로젝트 단위 설정이어야 합니다.

코드 리뷰를 넘어선 통합 지점

코드 리뷰는 이상적인 시점이지만 유일한 시점은 아닙니다. 구글은 워크플로의 여러 단계에 정적 분석을 끼워 넣었고, 앞단으로 갈수록 강제력이 세지는 대신 통과 기준도 가팔라집니다.

프리서브밋 — 커밋을 막는 게이트

리뷰에 표시된 경고는 무시될 수 있습니다. 그래서 변경이 커밋되지 못하게 막는 프리서브밋 검사(presubmit check) 를 둡니다. 변경 내용이나 메타데이터를 보고 “커밋 메시지에 DO NOT SUBMIT이 없어야 한다”, “테스트 파일이 반드시 있어야 한다”, “특정 분류의 Tricorder 문제가 0이어야 한다” 같은 규칙을 강제합니다. 팀이 자기만의 프리서브밋을 만들어 프로젝트 특화 분석을 더할 수도 있습니다(예: 새 프로젝트는 레거시가 많은 프로젝트보다 모범 사례를 더 엄격하게 적용). 다만 팀 특화 프리서브밋이 대규모 변경을 가로막을 수 있어, 변경 설명에 CLEANUP=을 넣어 건너뛸 수 있게 합니다.

컴파일러 통합 — 가장 강한 경고는 빌드 실패

문제를 더 앞단에서 알리려면 컴파일러에 통합하는 게 최선입니다. 빌드 실패는 절대 무시할 수 없는 경고이기 때문입니다. Error Prone의 ‘ERROR’ 검사 항목들이 그 예로, 자바 컴파일러에서 모두 활성화되어 에러를 걸러냅니다. 단 컴파일러 검사는 다음을 모두 만족해야 합니다.

• 빠르게 수행될 것(빌드 속도를 해치지 않도록)
• 쉽게 수정할 수 있을 것(가능하면 기계적 수정 제안)
• 유효 거짓 양성이 발생하지 않을 것(올바른 코드의 빌드를 절대 막지 않도록)
• 스타일·모범 사례가 아닌 정확성 문제만 보고할 것

새 검사를 켜려면 먼저 코드베이스 전체에서 해당 문제를 모두 없애야 합니다(안 그러면 기존 빌드가 깨집니다). 절차는 ① 검사를 지정해 컴파일러를 MapReduce로 돌려 자동 수정 제안 생성 → ② 전체 적용 변경을 준비해 테스트 → ③ 커밋해 문제 제거 → ④ 검사 활성화입니다. 역으로 말하면, 컴파일러 검사를 새로 배포한다는 건 기존 코드를 전부 청소할 만큼 가치가 큰 검사 라는 뜻입니다. 구글은 컴파일러 경고 0개를 목표로 하며(경고는 무시되기 마련이라 빌드를 멈추지 않을 검사라면 아예 끕니다), Go 컴파일러는 더 극단적으로 미사용 변수·임포트도 에러로 취급합니다.

IDE·코드 브라우징 — 적합한 분석기에 한해서만

IDE 통합도 가능하지만 까다롭습니다. IDE에서는 분석을 매우 빠르게(대체로 1초, 이상적으로 100ms 미만) 끝내야 하고, 팀마다 IDE가 달라 같은 분석을 동일하게 적용하기 어렵습니다. 또한 코드 리뷰가 분석 결과를 보여주기에 더 적합한데, 변경과 관련한 맥락을 코드베이스 전체에서 살펴볼 수 있기 때문입니다(예: 죽은 코드 분석기는 호출 코드가 들어오기 전까지 계속 문제를 보고하므로 부분 코드만으로는 완전하지 않습니다). 리뷰에서 보여주면 작성자가 무시하려 해도 리뷰어의 동의가 필요하다는 이점도 있습니다.

한편 새 코드가 아니라 코드를 둘러볼 때 보여줘야 유익한 분석도 있습니다. 보안 분석은 보안팀이 문제 사례 전부를 봐야 할 수 있고, 리팩터링하려는 개발자도 코드베이스 전체 분석 결과를 원합니다. 즉 브라우징 시점도 통합 후보입니다.

비교 / 트레이드오프

거짓 음성↓ vs 유효 거짓 양성↓

관점	거짓 음성 최소화(학계 전통)	유효 거짓 양성 최소화(구글)
목표	잡을 수 있는 버그를 최대한 다 잡기	개발자가 실제로 고치게 만들기
성공 척도	알고리즘의 검출력	도구가 켜진 채 유지되는가(채택·신뢰)
위험	노이즈가 쌓여 도구가 무시됨	진짜 버그를 일부 놓칠 수 있음

검출력을 높이는 것과 채택을 얻는 것은 종종 반대 방향입니다. 한 번 신뢰를 잃은 도구는 진짜 경고까지 묻히므로, 채택을 먼저 확보하는 쪽이 장기적으로 더 많은 버그를 잡습니다.

통합 지점별 트레이드오프

통합 지점	시점	강제력	통과 기준
코드 리뷰(Tricorder)	리뷰 중	무시 가능(리뷰어가 압박)	가장 느슨, 대신 가장 풍부한 맥락
프리서브밋	리뷰 요청·커밋 시	커밋 차단	팀별 사용자화 가능
컴파일러	빌드 시	빌드 실패(가장 강함)	유효 거짓 양성 0·정확성만·빠를 것
IDE	편집 중	무시 가능	100ms 미만, IDE 파편화
코드 브라우징	탐색 중	정보 제공	전체 코드베이스 분석 필요

핵심 패턴은 강제력이 셀수록 유효 거짓 양성 허용치가 0에 수렴 한다는 것입니다. 빌드를 멈출 권한을 줄수록 거짓 양성은 단 한 건도 허용되지 않습니다.

내 생각

• 유효 거짓 양성 = 지표를 도구에서 사람으로 옮긴 것. SonarQube·ESLint를 도입해놓고 경고 수천 개가 쌓여 아무도 안 보는 상황이 정확히 이 함정입니다. ‘기술적 정확도’가 아니라 ‘개발자가 실제로 고치는 비율’을 KPI로 봐야 합니다.

• 신규·변경 코드에만 경고 = 점진 도입의 정석. 레거시 전체에 룰을 소급하면 경고 폭탄으로 도구가 죽습니다. baseline을 박아두고 새 코드부터 거는 ratchet 패턴(ESLint --max-warnings, 커버리지 게이트)과 동형입니다.

• 컴파일러 경고 0 목표. 경고는 무시되는 게 디폴트이니 에러로 승격하거나 끄거나 둘 중 하나입니다. -Werror, CI에서 lint 실패를 빌드 실패로 처리하는 것과 같은 철학입니다.

• 사용자별 설정 금지. 린트 룰을 개인이 끌 수 있으면 “누구는 심고 누구는 고치는” 분열이 생깁니다. 룰은 프로젝트 단위로 박제해 레포에 커밋해야 일관성이 유지됩니다.

• 메시지 한 줄이 채택을 가른다. Guava %s 사례처럼, what/why/how를 적시에 알려주는 진단 메시지가 자동 수정만큼 중요합니다. 좋은 에러 메시지 설계는 분석 정확도와 동급의 투자 가치가 있습니다.

관련 개념

• Ch19 Critique 구글의 코드 리뷰 도구 — Tricorder가 회색 댓글로 통합되는 코드 리뷰 도구. 정적 분석을 워크플로에 녹이는 1차 통합 지점입니다
• Ch09 코드 리뷰 — [Please fix]로 리뷰어가 경고 해결을 압박하는 프로세스·문화의 토대입니다
• Ch08 스타일 가이드와 규칙 — 스타일 문제를 포맷터로 자동 수정하기 위한 언어별 스타일 가이드의 근거입니다
• Ch15 폐기 — API 폐기 과정에서 정적 분석이 마이그레이션 역행을 막는 가드레일로 쓰입니다
• Ch18 빌드 시스템과 빌드 철학 — 컴파일러 통합·CI 게이트로 정적 분석을 빌드에 끼워 넣는 지점이 맞물립니다