Hacker News 2026.04.03 44

리눅스 커널 리포트가 급증하고 있다 — 그 이면에는 무엇이 있을까

무슨 일이 일어나고 있나요?

리눅스 커널에 보고되는 버그 리포트, 특히 회귀(regression) 리포트와 CVE(보안 취약점 번호) 할당 건수가 눈에 띄게 증가하고 있어요. LWN에서 이 현상에 대한 분석 글이 올라왔는데요, 단순히 "버그가 많아졌다"는 이야기가 아니라 리포팅 체계 자체의 변화가 숫자를 끌어올리고 있다는 점이 핵심이에요.

이게 뭐냐면, 리눅스 커널 같은 거대 오픈소스 프로젝트에서는 새 버전이 나올 때마다 이전에 잘 되던 기능이 깨지는 경우가 있거든요. 이걸 "회귀(regression)"라고 불러요. 예를 들어 커널 6.x에서 잘 되던 Wi-Fi가 6.y로 업데이트하니까 안 되는 거죠. 이런 회귀를 체계적으로 추적하는 작업이 최근 몇 년간 본격화되면서, 보고 건수 자체가 크게 늘어난 거예요.

왜 리포트가 이렇게 늘어났을까?

첫 번째 이유는 자동화 도구의 발전이에요. 구글에서 만든 syzbot이라는 퍼징(fuzzing) 도구가 대표적인데요, 퍼징이 뭐냐면 프로그램에 아무렇게나 입력을 때려넣어서 크래시가 나는 지점을 찾는 테스트 기법이에요. syzbot은 24시간 쉬지 않고 리눅스 커널을 두들기면서 문제를 찾아내거든요. 사람이 수동으로 테스트할 때는 발견하지 못했던 엣지 케이스들이 기계적으로 대량 발굴되고 있는 셈이죠.

두 번째는 CVE 할당 정책의 변화예요. 2024년부터 리눅스 커널 팀이 자체적으로 CVE Numbering Authority(CNA)가 되면서, 커널 관련 보안 수정에 CVE 번호를 적극적으로 부여하기 시작했어요. 이전에는 "이건 보안 이슈가 맞나?" 하고 고민하며 CVE를 안 붙이던 것들도, 이제는 "일단 붙이자"는 방향으로 바뀐 거예요. Greg Kroah-Hartman(커널 안정 브랜치 메인테이너)은 모든 버그를 잠재적 보안 이슈로 보는 게 맞다는 입장이에요. 결과적으로 한 해에 수백 개씩 CVE가 쏟아지면서 숫자가 급등한 것처럼 보이게 됐죠.

세 번째로는 회귀 추적 전담자의 등장이에요. Thorsten Leemhuis 같은 개발자가 커널 회귀를 전문적으로 추적하고 리포트하는 역할을 맡으면서, 이전에는 메일링 리스트에 묻혀서 무시되던 문제들이 체계적으로 가시화되고 있어요.

숫자가 늘었다고 커널이 불안정해진 걸까?

여기서 중요한 건 리포트 수 증가가 곧 품질 하락을 의미하지는 않는다는 점이에요. 오히려 반대로 해석할 수도 있거든요. 이전에는 존재하지만 발견되지 못했던 버그들이 이제야 수면 위로 올라오고 있는 거니까요. 진짜 걱정해야 할 건 리포트 숫자가 아니라 "보고된 문제가 얼마나 빨리 해결되느냐"예요.

다만 현실적인 문제도 있어요. CVE가 너무 많이 나오니까 다운스트림 배포판(Ubuntu, Fedora, RHEL 등)의 보안팀이 "이걸 다 대응해야 하나?"라는 피로감을 느끼게 된 거죠. 보안 스캐너가 수백 개의 커널 CVE를 경고로 띄우면, 정작 중요한 것과 아닌 것을 구별하기가 어려워지거든요. 일종의 "경고 피로(alert fatigue)"가 생기는 셈이에요.

다른 대형 프로젝트에서는 어떤가요?

Chromium 프로젝트도 비슷한 경험을 했어요. 퍼징 인프라를 대폭 강화한 뒤 보안 버그 리포트가 급증했지만, 이를 통해 실제로 릴리스 전에 잡아내는 버그 수가 크게 늘었죠. 안드로이드 커널도 GKI(Generic Kernel Image) 체제로 바뀌면서 업스트림 커널의 회귀 영향을 더 직접적으로 받게 됐고, 이에 따라 리포팅 파이프라인을 강화하고 있어요.

결국 "리포트가 많다 = 나쁘다"가 아니라, 성숙한 프로젝트일수록 리포트가 많아지는 건 자연스러운 현상이라는 게 업계의 공감대예요. 문제는 그걸 처리할 인력과 프로세스가 따라가느냐의 싸움이죠.

한국 개발자에게 어떤 의미가 있을까?

임베디드나 서버 환경에서 리눅스 커널을 직접 다루는 분들이라면, CVE 숫자에 과도하게 반응하기보다는 실제 영향도를 판단하는 역량이 더 중요해졌어요. 모든 CVE가 다 심각한 건 아니거든요. 또, 자사 제품에 사용하는 커널 버전의 회귀 리포트를 주기적으로 모니터링하는 습관을 들이면 업데이트 시 사고를 미리 방지할 수 있어요.

그리고 퍼징이라는 기법 자체를 실무에 도입하는 것도 생각해볼 만해요. syzbot처럼 커널 전용이 아니더라도, AFL이나 libFuzzer 같은 도구를 활용해 자기 프로젝트의 C/C++ 코드나 파서 부분에 퍼징을 돌려보면 생각지 못한 버그를 잡아낼 수 있거든요.