CRA가 시작된다: 임베디드 SW의 무게중심이 옮겨간다

5개월 남았다.

2026년 9월 11일, 유럽연합 사이버 회복력법(Cyber Resilience Act, CRA)의 첫 의무가 발효된다. 이날부터 EU 시장에 디지털 제품을 출하한 모든 제조사는, 적극적으로 악용되는 취약점을 알게 된 시점부터 24시간 안에 ENISA와 국가 CSIRT에 조기 경보를 제출해야 한다(72시간 내 정식 통보, 14일 내 최종 보고로 이어지는 3단계 의무). 2027년 12월 11일에는 CRA 본법이 전면 적용된다. Annex I의 필수 사이버보안 요구사항을 충족하지 못한 제품은 EU 시장에서 판매할 수 없다. 위반 시 최대 €15M 또는 전 세계 연매출의 2.5% 중 큰 금액이 부과된다.

또 하나의 규제처럼 보인다. 실제로 다들 그렇게 처리하고 있다. 그게 가장 비싼 오독이다. 임베디드 SW를 어떻게 만들어야 하는지, 지난 10년 동안 엔지니어들이 알면서도 미뤄온 답이 있다. CRA는 그 답을 법적 형태로 강제하는 사건이다.

무엇이 진짜로 바뀌었는가

CRA의 핵심을 한 문장으로 압축하면 이렇다.

보안 책임의 시점이 “제품 출시 순간”에서 “제품 수명 전체”로 옮겨갔다.

이전 모델에서 보안은 체크포인트였다. 인증을 받고, 출하하고, 가끔 패치를 내보냈다. 인증서를 받는 순간이 보안 작업의 정점이었다. CRA 이후 그 순간은 시작점이 된다. 시장에 풀린 모든 디바이스가, 살아있는 모든 날 동안, 사이버보안 의무의 대상이 된다.

구체적으로 뭐가 강제되나. CRA Annex I, Part I은 11개의 “Essential Cybersecurity Requirements”를 정의한다. 그중 하나는 짧다. “제품은 공격 표면을 줄이도록 설계·제조되어야 한다.” 이게 권고였다면 좋겠지만, 필수 요구사항이다. 시장감독청 앞에서 “왜 이 패키지가 들어 있나”에 답할 수 없으면 위반이다. “디버깅 편의”는 변명이 안 된다.

Annex I, Part II는 SBOM을 머신리더블 포맷(SPDX, CycloneDX 등)으로, 제품의 기술 문서에 포함하도록 요구한다. 패키지 하나하나가 영구적인 법적 기록 항목이 된다. BSP에 라이브러리를 하나 추가할 때마다, 그 시점부터 등기부에 올라간 자산처럼 취급된다.

Article 13은 지원 기간을 제품의 예상 사용 기간에 맞추도록 강제한다. 최소 5년이다. 그런데 카탈로그에 “15년 운영”이라고 적힌 제품은 법적으로 15년 지원 의무를 진다. PM이 마케팅 문구로 적은 숫자가 BSP 팀의 의무 기간을 결정한다. 그리고 그 기간 내내 보안 업데이트는 무상이다.

Article 14는 보고 의무를 정의한다. 24시간 조기 경보, 72시간 상세 보고, 14일 최종 보고. 알게 된 시점부터 카운트다운이 돈다.

이 네 조항이 결합하면 새로운 등식이 나온다.

우리 BSP의 패키지 한 개 = 향후 N년 동안의 추적·패치·보고 의무 한 건.

패키지 1000개면 의무 1000건. 무상으로. 24시간 안에. 매일 131개의 신규 CVE가 쏟아지는 환경에서.

숫자가 10배가 됐다

왜 지금인가. 숫자가 말해준다.

2025년 NVD에 등록된 신규 CVE는 48,174건이다. 일평균 131개. Linux 커널만 따로 보면 5,530건, 매일 8개에서 9개의 신규 커널 CVE다. 익스플로잇 공개부터 실제 악용까지의 중간값은 5일 미만으로 떨어졌다. 산업 데이터를 보면 침해의 절반 이상이 이미 패치가 나와 있던 알려진 취약점에서 터진다.

이전 모델이 굴러가던 시절의 가정이 무너졌다.

10년 전 연간 CVE는 5,000개에서 7,000개였다. 작은 보안팀이 손으로 트리아지했고, BSP에 패키지 1000개를 욱여넣어도 운영비가 눈에 안 띄었다. Yocto 기본 이미지가 데스크톱 Linux의 가정을 그대로 물려받아 부풀어도, 그게 비용으로 잡히지 않았다.

지금은 그 양이 10배다. 매일 100개 넘는 신규 취약점을 손으로 매칭·평가·결정할 방법은 없다. 자동화가 먹히려면 추적할 컴포넌트 수가 자동화의 한계 안에 들어와야 한다.

이게 CRA가 만든 새 풍경의 핵심이다. 24시간 보고는 BSP 크기와 직접 묶여 있다. 추적 대상이 적으면 가능하고, 많으면 불가능하다. “공격 표면을 작게”는 미적 권고로 들리지만, 실은 법적 의무를 수행 가능하게 만드는 전제조건이다.

클라우드 세계는 이미 답을 냈다

여기 임베디드 엔지니어가 잘 못 보는 흐름이 있다. 같은 문제를 클라우드/컨테이너 세계가 5년에서 7년 먼저 만났고, 답을 냈다. 임베디드만 늦었다.

그 답의 이름은 distroless다.

Chainguard라는 회사는 Wolfi라는 “비-배포판”을 만들어, 컨테이너 이미지에 애플리케이션과 그 런타임 의존성만 남기는 방식으로 패키지화한다. 셸도 없고, 패키지 매니저도 없고, 디버깅 유틸리티도 없다. 결과는 측정된다. Chainguard 이미지는 OSS 등가물 대비 CVE를 평균 97.6% 줄였다. 패치를 더 잘해서가 아니다. 애초에 들어 있는 게 적어서다.

그리고 더 중요한 원칙. 업데이트하지 말고 교체하라. Chainguard는 컨테이너 안에서 apk update를 돌리지 않는다. 새 버전이 필요하면 새 이미지를 빌드해서 통째로 갈아끼운다. 매일 밤 모든 베이스 이미지가 자동으로 다시 빌드된다. Google이 내부에서 쓰던 “build horizon” 사고방식이다. 코드가 안 바뀐 마이크로서비스도 정기적으로 새 베이스에서 재빌드된다.

이 두 원칙(최소화와 교체)이 CVE 폭증 시대에 클라우드가 살아남는 방식이다.

임베디드에 그대로 옮기진 못한다. BSP를 통째로 distroless로 만들 방법은 없다. 부트체인, 커널, HAL은 그 자리에 있어야 한다. 그래도 발상은 이전할 수 있다.

느리게 바뀌는 레이어와 빠르게 바뀌는 레이어를 물리적으로 분리하라. BSP엔 부트체인, 커널, 최소 OS만 둔다. 자주 업데이트돼야 하는 것(보안 라이브러리, 통신 스택, 애플리케이션)은 컨테이너나 정적 링크된 별도 채널로 뺀다. 그러면 BSP 자체는 5년에 한 번 큰 업그레이드를 하고, 매주 터지는 CVE는 빠른 레이어에서 처리한다. 재빌드 주기가 다른 두 영역이 같은 이미지에 묶여 있는 한, CRA의 24시간 보고는 불가능하다.

LLM이 비대칭을 더 키운다

CRA가 발효되는 지금, 동시에 벌어지는 변화가 하나 더 있다. 공격자에게 LLM이 먼저 도착했다.

2026년 4월 22일, 이 글을 쓰기 일주일 전, Deutsche Telekom의 Red Team이 PackageKit에서 12년 묵은 TOCTOU 취약점(CVE-2026-41651, “Pack2TheRoot”)을 공개했다. PackageKit은 거의 모든 메이저 Linux 배포판에 들어 있는 데몬이다. 발견 방법은 Claude Opus로 진행한 AI 보조 연구였다. AI를 특정 방향으로 유도해서 익스플로잇 가능한 취약점을 캐냈다.

신규 CVE를 캐는 비용이 떨어지고 있다. 그것도 빠르게.

방어자 입장에서 이 현상은 비대칭이다. 공격자는 “LLM × 시간”으로 취약점을 만들어낸다. 우리는 BSP 안의 모든 컴포넌트를 대상으로 그런 발견을 추적하고 응답해야 한다. 공격자 비용은 시간이 갈수록 떨어지고, 우리 비용은 BSP 크기에 비례한다. 시간이 흐를수록 격차가 벌어진다.

방어 쪽 사정은 더 나쁘다. 233개 임베디드 펌웨어 케이스로 LLM을 측정했을 때 가장 잘한 모델이 68.0%였고, 가장 크게 무너진 카테고리는 DMA, ISR, 스레딩이었다. 결함이 버그 리포트가 아니라 CVE가 되는 자리가 바로 거기다.

15년 지원 기간 동안 이 격차가 계속 벌어진다고 가정하라. 그 가정 위에서 살아남는 길은 표면을 줄이는 것뿐이다. 더 빨리 패치하기는 한계가 있다. 24시간이 이미 한계점이다. 그다음은 패치할 게 적은 쪽이다.

세 가지 마인드셋 전환

CRA를 컴플라이언스 작업으로 다루는 팀과, 게임 자체의 변화로 다루는 팀이 앞으로 5년 안에 갈린다. 후자가 되려면 세 가지 전환이 필요하다.

첫째, 패키지를 “자산”이 아닌 “계약서”로 본다.

IMAGE_INSTALL에 한 줄 추가하는 것은, 그 패키지의 향후 N년 CVE 추적·백포트·검증·보고를 서명하는 행위다. 이 관점이 박히면 의사결정이 자동으로 달라진다. 기본 질문이 “왜 빼지?”에서 “왜 넣지?”로 바뀐다. 디버깅 편의 도구가 production에 남는 사고도 준다. 한번 들어간 건 빼기가 어렵기 때문이다.

운영으로 옮기면, 모든 패키지 추가에 책임자 이름이 붙어야 한다. 누가 왜 이걸 넣었나. 다음 LTS 마이그레이션에서 누가 이걸 정당화할 건가. 이름 없는 패키지는 안 들어간다.

둘째, BSP 크기를 “컴플라이언스 운영비”로 환산한다.

지금 BSP 패키지가 N개라 하자. 향후 15년 SBOM 항목은 N개. 매일 N에 비례하는 신규 CVE 매칭이 생긴다. 그중 일부는 24시간 보고 대상이 된다. 각각을 패치하거나 백포트하거나 mitigation을 무상으로 만들어야 한다. 적합성 평가에서 Notified Body가 N개 항목을 감사한다.

N이 크면 전부 크다. 다른 어떤 단일 결정도 향후 15년 운영비에 BSP 크기만큼 영향을 주지 않는다. 그래서 BSP 슬림화는 보안 R&D 예산이 아닌 컴플라이언스 운영비 절감 예산이다. 임원에게 올라가는 메시지가 달라져야 한다.

셋째, “재빌드 속도”를 보안 KPI로 도입한다.

CRA 시대에 보안 능력을 대표하는 단일 지표는 전체 펌웨어를 처음부터 다시 빌드하는 데 걸리는 시간이다. 핵심 의존성 하나에 CVE가 떴을 때, 처음부터 새 이미지를 빌드해 OTA로 배포하기까지의 lead time. 이게 짧으면 24시간 보고가 가능하고, 15년 지원이 가능하고, Yocto LTS 갈아끼우기가 가능하다. 길면 다 불가능하다.

이 시간은 BSP 크기에 거의 정비례한다. 빌드 시간, 회귀 테스트 시간, QA 시간, OTA 검증 시간. 전부 패키지 수와 같이 늘어난다. 작은 BSP가 빠른 재빌드를 만들고, 빠른 재빌드가 컴플라이언스를 가능하게 만든다.

마치며

CRA는 컴플라이언스 작업이 아니다. 지난 10년 동안 옳았던 엔지니어링이 마침내 처벌 메커니즘을 얻은 사건이다.

작게 만들고, 빠르게 갈아끼우고, 영원히 책임진다. CVE 폭증 시대에 임베디드 SW가 살아남는 유일한 방식이라는 걸, 클라우드 세계가 5년 먼저 깨닫고 입증했다. CRA는 그 답을 모든 EU향 디바이스 제조사에게 법적으로 확장한 것뿐이다.

후자의 관점에서 보면, 5개월 남은 카운트다운은 부담보다 방향 신호에 가깝다. CRA가 강제하는 것(공격 표면 최소화, SBOM, 24시간 보고, 무상 패치)은 다 어차피 좋은 임베디드 SW가 갖췄어야 할 것들이다. 비용이 안 보여서 미뤄왔을 뿐이다. 이제 비용이 보인다. 처벌이 매겨졌고, 운영비가 계산 가능해졌다.

5개월 안에 전부 바꾸진 못한다. 그래도 어디로 가야 하는지는 분명하다. 작게, 모듈화, 빠른 재빌드. 9월 11일부터 시작되는 게임에서 이 세 가지가 곧 살아남는 능력이다.