Security

보안 담당자, 새해엔 리눅스 커널을 파라

문가용 기자

Published: 01:03, 26 Dec 2025 (Updated: 14:36, 14 Jan 2026)

💡

Editor's Pick
- 클라우드 생태계와 컨테이너 환경에 익숙해지지만
- 사실 우리가 바라보고 있는 건 추상화 통해 구현된 '거울상'
- 그 모든 것들을 떠받치고 있는 리눅스 커널 이해해야

클라우드 생태계가 점점 확산되고 있고, 심지어 일부에서는 정착을 넘어 고착화 되고 있기까지 하다. 최첨단을 달리는 회사가 아니더라도 대부분의 IT 전문가들은 YAML과 API, 오케스트레이션, 컨테이너 도구들을 사용하는 데 능숙하다. 하지만 그런 표면에 등장한 신기술들이 리눅스 커널이라는 것에 뿌리를 두고 있다는 것은 많이들 잊고 있다. 이는 보안 관점에서 심각한 문제일 수 있다는 지적이 보안 기업 에데라(Edera)로부터 나왔다.

리눅스 커널과 추상화

리눅스 커널(Linux Kernel)이란, 리눅스 운영체제의 핵심 엔진이다. 사용자나 프로그램이 컴퓨터의 자원을 직접 건드리지 못하게 하면서, 모든 요청을 대신 처리해 주는 가장 낮은 층위의 소프트웨어라고 할 수 있다. 여기서 말하는 ‘컴퓨터의 자원’이란, CPU, 메모리, 디스크 등과 같은 하드웨어를 말한다. 하드웨어가 다치면 컴퓨터는 심각하게 망가질 수 있기 때문에 모든 프로그램은 반드시 커널을 통해서만 하드웨어와 상호작용을 할 수 있게 된다. 중요한 인물의 대변인이나 변호사 정도라 할 수 있겠다.

API, 쿠버네티스, 컨테이너 등과 같은 도구들은 이런 리눅스 커널 위에 생성된 ‘추상화 계층’이다. 추상화는 복잡한 내부 구조를 숨기고, 필요한 기능만 골라서 간단한 형태로 제공하는 기술을 말한다. 즉 사용자가 구조와 원리를 샅샅이 이해하고 있지 못하더라도 필요한 기능을 사용하는 데 무리가 없게 하기 위한 것이라 볼 수 있다.

“예를 들어 자동차라는 기계를 봅시다. 운전자는 핸들과 페달을 밟는 것 정도로 충분히 차를 운행할 수 있습니다. 하지만 그 핸들과 페달들이 어떤 구조로 연결돼 있고, 어떤 원리로 가속이나 제동, 방향 전환과 같은 결과를 내는지 운전자가 다 알지는 못합니다. 알 필요도 없고요. 이렇게 ‘사용만 할 수 있게’ 간소화 해서 사용자에게 노출시키는 걸 추상화라고 합니다.” 에데라의 설명이다.

추상화는 생각보다 가까운 곳에도 있다. 우리가 한 시도 손에 떼지 못하는 스마트폰도 두터운 추상화의 산물이라고 할 수 있다. “보통의 사용자들은 그저 화면을 켜서 앱을 눌러 실행하는 것만 합니다. 하지만 그 앱이 실행되기 위해 메모리도 할당 받고, 파일 시스템에 어떤 권한으로 접근하게 되는지, 또 커널에 어떤 호출을 보내는지 등은 다 이해하지 못합니다. 핸드폰 사용자 인터페이스도 추상화의 일종이라 할 수 있습니다.”

모르라고 만든 게 추상화라면서? 그런데 이제와 모르는 게 문제라고?

리눅스 커널과 추상화가 무엇인지 이해했다면 이 글 첫 문단의 ‘리눅스 커널이라는 것에 뿌리를 두고 있다는 것을 모르는 게 보안 관점에서 심각한 문제일 수 있다’는 문장이 이상하게 읽힌다. 운전자가 핸들과 페달의 상세한 원리를 모르면 안전 운전을 하지 못하게 되는 걸까? 핸드폰 사용자가 기계 속에서 벌어지는 진짜 일들을 이해하지 못하면 위험해지는 걸까?

에데라는 여기에 대해 “일반 사용자라면 추상화를 통해 구현된, 눈에 보이는 기술만 안전하게 써도 충분히 안전할 수 있다”고 답한다. “하지만 그것이 보안 관점에서 완벽하다는 뜻이 되지는 않습니다. 따라서 일반인이 아닌 보안 담당자라면 보다 깊은 곳으로의 시선을 갖출 필요가 있습니다. 리눅스 커널에까지 생각이 가서 닿아야 한다는 것이죠.”

일반 운전자라면 핸들과 페달만 능숙하게 조작해도 안전하게 운전하기 충분하지만, 차량 안전 책임자라면 에어백이 있고, 차선 보조 시스템이 설치돼 있다는 것 정도로 ‘누가 몰아도 안전한 차’라고 믿어서는 안 된다는 게 에데라의 설명이다. “예를 들어 차대에 결함이 없는지, 계절이나 도로 상태를 고려해 타이어 상태가 괜찮은지까지도 생각할 수 있어야 합니다.” 일반 핸드폰 사용자라면 안전하게 앱만 설치해 사용하면 그만이지만, 그런 핸드폰을 임직원 1만 명에게 지급해 관리해야 하는 보안 책임자의 시선은 달라야 한다. 그런 사람은 적어도 ‘OS 모르면 어때’ 같은 생각을 하지 말아야 한다는 게 에데라가 말하고자 하는 바다.

“보안의 실제 경계는 커널”

다시 이야기를 처음으로 돌려, YAML과 API, 오케스트레이션, 컨테이너 도구들을 능숙하게 사용하는 오늘날의 IT 및 보안 전문가들을 살펴보자. 그리고 ‘API, 쿠버네티스, 컨테이너 등과 같은 도구들은 이런 리눅스 커널 위에 생성된 ‘추상화 계층’이다.’라는 문장을 다시 보자. 무슨 의미가 되는가? 바뀌어버린 현대 네트워크 구조와, 그런 구조들에서 사용되는 신기술들은 사실, 자동차 구조 모르는 운전자가 쥔 핸들, 스마트폰 내부 원리를 모르는 사용자가 보는 앱 화면과 같다는 뜻이 된다.

“우리가 능숙하게 다루는 이 멋진 신기술들은 결국 ‘추상화’를 통해 구현된 ‘일부 기능’일 뿐입니다. 좀 극단적으로 표현하면 신기루나, 거울에 반사된 형상이기도 하죠. 신기루나 거울상이 무사해 보인다고 해서 본체가 무사하다고 할 수 없습니다. API니, 쿠버네티스니, 컨테이너의 본체인 리눅스 커널이 안전하지 않으면, 이런 것들을 아무리 안전하게 사용해도 안전해질 수 없습니다.” 에데라가 강조한다.

이 모든 것을 건물로 예를 들어 보자. 에데라의 설명에 따르면 리눅스 커널은 건물의 구조 그 자체다. 컨테이너는 그 건물에 입점된 사무실이나 매점의 칸막이다. 칸막이를 아무리 잘 닦고 관리하고 각종 소음이나 침투에 대비해 보강하더라도, 건물 구조가 무너지면 말짱 도루묵이 된다. “리눅스 커널이 뚫리면 클라우드 테넌트들도 뚫리고, 컨테이너 경계선도 사실상 무의미해집니다. 리눅스 커널이 흔들리면 우리가 하는 클라우드 보안이나 OS 보안, 소프트웨어 보안이 다 무용지물이 된다고 할 수 있습니다.”

그러면서 에데라는 “보안의 실제 경계는 커널이다”라고 강조한다. “해커가 절대로 들어오면 안 되는 구역이 있습니다. 다른 모든 공격을 허용하더라도 여기 만큼은 절대로 지켜야 하는 구역이 있는데, 그게 바로 리눅스 커널이라는 의미입니다. 그런데 대부분의 우리는 추상화 계층에 정신이 팔려 리눅스 커널을 보지 못하고 잊어버린 채 삽니다. 그 중요한 리눅스 커널이 난공불락인 것도 아닌데 말입니다.”

리눅스 커널, 생각보다 문제 많다

에데라가 진짜 하고 싶은 말은 “리눅스가 현대 클라우드 생태계나 인프라 구조를 염두에 두고 만들어진 게 아니”라는 것이다. “그런데 우리는 그 리눅스 커널 위에 모든 신뢰와 보안 장치들을 얹고 있습니다. 불안한 지대 위에 콘크리트도 깔지 않은 채 철근 기둥을 계속 올려 고층 건물을 만들고 있는 겁니다. ‘지금은 괜찮은데?’라고 되묻는다면 반박하기 힘듭니다만, 한 번 무너지면 커다란 재앙으로 이어질 수 있습니다. 커널이 무너지면 그 위의 모든 것이 무너집니다.”

그러면 리눅스 커널이 안 무너지면 되는 것 아닐까? “커널은 수천만 행의 C 코드로 만들어졌습니다. C 언어가 예전에는 대세였고, 지금도 강력하게 사용되는 게 사실입니다만, 메모리를 안전하게 지켜주는 데에는 한계가 있다는 게 널리 알려져 있죠. 그래서 많은 기업들이 러스트(Rust)와 같은 현대적인 언어로 옮기는 추세입니다. 커널을 만든 언어 자체가 취약하다는 건, 커널 자체를 허술하게 만들 수밖에 없습니다. 태생적 한계를 가지고 있는 겁니다.”

실제 2025년 초, 불과 수주 사이에 커널에서만 100개가 넘는 취약점이 나오기도 했었다. 하루 평균 8개의 취약점이 발견된 것이었다. 그런데 이것이 특정 이미지나 컨테이너에서만 나오는 문제였다면 그리 심각한 일이 아니었을 것이다. 커널에서 발견된 문제는 무조건 “해당 노드에서 실행되는 모든 컨테이너에 적용”되기 때문에 취약점 하나하나의 파급력이 어마어마했다. 그런 게 단기간에 100개 넘게 나오는 것이 작금의 현실이다.

“그런 커널에 너무 많은 일을 맡기고 있죠. 모든 프로세스가 커널을 통해 실행됩니다. 모든 메모리가 커널 단에서 관리됩니다. 모든 파일 접근이 커널을 통해 구현됩니다. 모든 네트워크 통신 역시 커널을 통해 이뤄집니다. 컨테이너의 최신 보안 기능 역시 커널 위에서 실행됩니다. 무슨 말입니까? 모든 계란을 단 한 바구니에 담았다는 의미죠. 중요한 걸 나눠서 보관하고 관리하는 게 리스크 관리의 기본 아닙니까? 그런데 현대 클라우드 구조는 그 기본을 전혀 지키지 않고 있는 겁니다.”

커널이 너무 많은 일을 하고 있다는 것에는 또 다른 의미가 있다. 패치가 어렵다는 것이다. 너무 많은 일을 담당하고 있어, 멈추는 즉시 큰 손해나 손실이 발생할 확률이 높아지기 때문이다. 패치를 위해 커널을 잠시 재부팅 하거나 꺼두면, 그 수많은 기능들이 한꺼번에 마비나 지연을 일으키는 현 구조 속에서 패치는 그 자체로 또 다른 리스크가 될 수 있다. 취약점이 적게 나오는 것도 아니고, 그 취약점의 파급력이 낮은 것도 아닌데, 해결조차 마음대로 할 수 없다는 의미다.

커널 공격, 난이도 높을까? 어떻게 막을까?

이렇게나 중요한 요소라서 그런지 ‘커널을 공격하려면 대단한 실력을 가지고 있어야 한다’는 잘못된 믿음도 쉽게 발견할 수 있다고 에데라는 전한다. 하지만 취약점이 충분하고 패치가 느린 생태계의 한계 때문에 공격 난이도는 오히려 낮은 편에 속한다고 한다. “예를 들어 넷필터(netfilter)라는 요소에서 발견된 취약점 하나는 2024년 패치가 나왔음에도 지금까지 랜섬웨어 공격에 이용되고 있습니다. 공격자들은 커널에 대한 깊은 지식 없이도, 공개된 취약점 정보만으로 쉽게 공격을 성공시켰습니다.”

커널 하나가 뚫리면 컨테이너나 클라우드 테넷 수백~수천 개가 뚫린 것과 같은 지금 상황에서, 보안 담당자들은 어느 정도로까지 리눅스 커널을 이해하고 있어야 할까? “커널 코드를 직접 작성할 때까지? 아닙니다. 해커들처럼 커널을 공략할 수 있을 때까지? 아닙니다. 커널이 현재 우리 회사에서 사용되는 어떤 기술/앱/기능이 커널과 연결돼 있는지, 그런 기술/앱/기능이 커널과 어떻게 작용하는지, 지금 우리 회사의 보안 정책은 커널에 영향을 주는지, 아니면 커널 침해에 무용지물이 되는 수준인지, 커널 취약점이 익스플로잇 되었을 때 어떤 도구나 사업, 서비스에 영향을 주는지 등을 파악하면 됩니다.”

그러면서 에데라는 다음 몇 가지를 추천한다.
1) 커널 구조를 이해한다. 커널 공간과 사용자 공간의 차이를 이해한다.
2) 이해된 것을 바탕으로 커널을 겨냥한 실제 공격의 전형적인 흐름을 이해한다. 커널 환경의 CVE들을 학습하는 것도 좋다.
3) 지금의 보안 도구, 설정, 정책을 커널의 관점에서 재검토 한다.
4) 커널 패치 소식을 매일 점검하여 재빠르게 대처한다.🆃🆃🅔

by 문가용 기자(anotherphase@thetechedge.ai)

CONTAINER RUNTIME VULNERABILITY MITIGATION - California State University, San Bernardino 석사학위논문, 2023년 (컨테이너 탈출의 핵심 축이 런타임·구성 문제가 아니라 공유 Linux 커널 취약점이라는 점을 도식으로 설명)
Container Privilege Escalation Vulnerabilities Explained - Aikido Security, 2024년 (CVE‑2023‑2640, CVE‑2023‑32629 등 OverlayFS·cgroup 취약점을 통해 “루트리스 컨테이너라도 결국 호스트 Linux 커널이 뚫리면 끝”이라는 점을 사례로 정리)
CISA Alerts: Critical Linux Kernel Bugs CVE‑2024‑1086 & CVE‑2023‑3390 - LinuxSecurity.com, 2024년 (netfilter: nftables의 커널 취약점이 완전한 시스템 장악과 데이터 유출로 직결됨을 강조하며 커널 패칭과 하드닝의 중요성을 설명)
Essential Guide for Securing the Linux Kernel Environment Effectively - LinuxSecurity.com, 2024년 (Lockdown 모드, 모듈 서명, SELinux/AppArmor 등 커널 자체를 보호하는 메커니즘이 상위 추상화 계층보다 우선 방어 대상임을 주장)