베이스 이미지의 AI 생성 코드 취약점

이 블로그 글의 AI 요약으로 바로 가기

LLM에게 코드를 생성해 달라고 요청한 적이 있으신가요? 그리고 ‘이 코드가 정말 안전한가?’ 하고 의문을 품어본 적은 없으신가요? 기업들이 ‘AI 유니콘’을 채용하고, Claude나 Copilot 같은 도구가 기본으로 자리 잡으면서, 무턱대고 뛰어들기 쉽습니다. 하지만 이 코드 블록들 속에는 눈에 띄지 않는 취약점들이 숨어 있습니다. 코드 검토 절차가 소홀해지기 시작하면, 이러한 취약점들은 위험한 문제로 번지게 됩니다.

저는 AI가 생성한 Dockerfile에서 이런 상황이 벌어지는 것을 목격했습니다. 기본 템플릿을 요청하면 구식 베이스 이미지가 제공되고, 이를 그대로 배포하게 됩니다. 이런 일이 십여 개의 서비스에서 반복되면, 보안 팀은 누가 만들었는지조차 기억하지 못하는 ‘AI가 생성한 기술 부채’에 허덕이게 됩니다. 뒤에서 설명하겠지만, SecureChain은 이러한 의존성 관리 문제로 인한 골칫거리를 해결하기 위해 설계되었습니다.

“AI가 위기를 구한다”는 신화

LLM은 Dockerfile 작성 같은 간단한 작업을 처리하는 데 가장 좋은 방법이라고 알려져 있습니다. 데브옵스(DevOps)를 겨우 엿본 정도인 프론트엔드 개발자에게는, AI 어시스턴트가 단 몇 초 만에 컨테이너 구성을 뚝딱 만들어 주는 구세주처럼 느껴집니다. 저도 이전에 Dockerfile을 작성해 본 적이 없었는데, Dockerfile이 필요해졌을 때 바로 그렇게 생각했습니다.

하지만 문제가 하나 있습니다. 그 ‘도움의 손길’은, 생성된 새롭고 멋진 코드가 오류를 일으키거나, 심지어 알려진 취약점을 안고 프로덕션 환경에 배포되는 등 문제가 발생하기 시작하면 종종 역효과를 낳곤 합니다.

AI가 생성한 코드는 마치 주문하지도 않은 피자와 같다고 생각해 보세요. 여전히 배는 고프지만, 먹기 전에 그 위에 안초비가 들어 있지 않은지 확인해야 합니다… 물론 안초비를 좋아한다면 얘기가 다르겠지만요. 이 비유를 빌리자면, 그 성가신 작은 물고기들을 여러분이 절대 끌어오고 싶지 않은 취약점이 있는 Node 버전으로 비유할 수 있습니다. 한 입 베어 물기 전에 무엇이 들어 있는지 먼저 확인하세요.

AI 결함의 구조

여기서는 두 가지 문제가 하나로 묶여 다루어지고 있습니다. AI는 애초부터 보안에 취약한 코드를 작성할 수도 있고, 작성 당시에는 문제가 없었지만 현재 실행 중인 것만으로도 문제가 되는 구식 의존성을 추천할 수도 있습니다. 이 글은 주로 두 번째 문제에 대해 다루고 있는데, 이는 간과하기 더 쉽기 때문입니다.

다음처럼 아주 짧게 보일 수도 있습니다: node:18-alpine. 한 줄짜리, 구문도 올바르고, 오류 없이 빌드됩니다. 하지만 그 이면에는 세 가지 체계적인 오류가 숨어 있습니다:

구식 이미지: 어시스턴트는 훈련 데이터의 특정 시점에서 합리적인 기본값이었던 기본 이미지 버전을 제안합니다. 어시스턴트가 그 오래된 이미지를 기준으로 삼고 있거나, 프로젝트가 실제로 지원하는 기능에 대한 정보가 불완전한 상태에서 작업을 진행하고 있을 수 있습니다.
내재된 취약점: EOL 런타임에서는 업스트림에서 수정 사항이 더 이상 제공되지 않기 때문에, 기존의 결함이 영구적으로 남게 됩니다. Node.js 18은 2025년 4월 30일에 지원 종료(EOL)되었습니다., 그리고 Docker Hub에는 다음과 같이 표시됩니다. 18-alpine 1년 넘게 전에 마지막으로 업데이트되었습니다. 최종 빌드에 포함된 내용이 바로 여러분이 받게 될 내용입니다.
맹목적인 신뢰: 개발자들은 “AI가 이런 건 잘할 거라고” 가정하고, 출력 결과가 익숙해 보이고 빌드가 성공하기 때문에 검증 과정을 생략합니다.

그 환상을 깨뜨리는 것은 아무것도 없다. docker pull node:18-alpine 2024년과 똑같이 작동합니다. 컨테이너가 시작됩니다. 업스트림에서는 아무도 이 컨테이너에 패치를 적용하지 않습니다.

연구 결과도 같은 결론을 보여줍니다. 베라코드(Veracode)의 ‘2026년 생성형 AI 코드 보안 보고서’에 따르면, 지난 4년간 100개 이상의 모델을 대상으로 한 평균 보안 통과율은 56%로 나타났으며, 구문 정확도가 95%를 넘어섰음에도 불구하고 이 수치는 변동이 없었습니다. 이는 프롬프트에 보안 관련 지침이 포함되지 않은 80개의 코딩 과제를 대상으로 한 결과이므로, 출시된 모든 코드의 결함률이 아니라 지침 없이 생성된 출력의 기준치에 해당합니다.

오해하지 마세요. AI 도구는 정말 훌륭합니다. 확실히 빠르긴 하지만 완벽하지는 않아서, 코드베이스에 문제가 발생하기 전에 이를 파악하려면 여전히 사람의 손길과 적절한 도구가 필요합니다.

왜 검토 체계가 무너지는가

코드 생성이 이제는 너무나 쉬워져서, 우리는 종종 이를 더 이상 ‘검토해야 할 코드’로 여기지 않게 되었습니다. 생성된 코드는 일회용처럼 느껴집니다. 요청하고, 붙여넣고, 실행하고, 다음 단계로 넘어가는 식이죠. 이 과정이 빨라질수록, 코드 검토는 모두가 조용히 우회하는 느린 단계가 되기 쉽습니다.

실제로 규율의 붕괴는 대개 다음과 같은 양상을 띠는 경향이 있습니다:

정형화된 업무에 대해 AI를 무조건 신뢰하기
Node 18과 같이 이미 지원 종료(EOL) 시점에 도달한 런타임 버전을 사용하는 경우
Docker Scout나 Snyk과 같은 보안 도구를 통해 AI 생성 결과를 검증하지 않는 경우
생성된 코드 내의 취약점이나 위험한 종속성을 지적하는 IDE 경고를 무시하기
인프라 파일은 “진짜” 애플리케이션 코드가 아니라는 이유로 검토 과정에서 대충 훑어넘기기
실전 적용 가능한 보안보다 “AI가 위기를 구한다”는 식의 속도를 우선시하는 것

다섯 번째 항목은 쉽게 간과하기 쉽습니다. React 컴포넌트의 모든 줄을 꼼꼼히 읽다 보면, 그 아래에 있는 9줄짜리 Dockerfile은 그냥 지나치기 쉽습니다. 그 파일은 단순한 구성이 아닙니다. 바로 기반이 되는 것입니다.

AI가 생성한 코드의 오류 유형을 파악하는 것은 매우 중요합니다:

‘환상적 위생(Hallucinated Hygiene )’이란, AI가 겉보기에는 표준처럼 보이지만 실제로는 구식이나 지원되지 않는 출처에서 가져온 구성을 제안할 때 발생하는 현상입니다. 서식은 교과서처럼 완벽하지만, 버전 핀은 오래된 것입니다.

‘중대성 맹점’은 개발자들이 AI가 생성한 코드를 여전히 취약점 검사가 필요한 구성 요소가 아니라 ‘해결된’ 문제로 취급할 때 발생합니다. 빌드 결과가 녹색이라고 해서 문제가 전혀 없는 것은 아닙니다.

배경: 오류가 발생하면, 사용자가 직접 알려주지 않는 한 AI는 어떤 버전이 EOL인지, 어떤 버전에 유효한 CVE가 있는지, 또는 사용자의 버전 정책이 무엇인지 알지 못할 수 있습니다.

LLM이 작성했다고 해서 코드가 결코 안전하다고 할 수는 없습니다. 신뢰할 수 없는 출처에서 나온 코드와 마찬가지로 취급해야 합니다. 즉, 코드를 검토하고, 악성 코드 및 알려진 취약점이 있는지 검사하며, 의존성 라이브러리가 최신 업스트림 정보와 일치하는지 확인해야 합니다.

AI가 생성한 코드의 취약점은 어떤 모습일까

Docker DX(Docker Scout의 검사 결과를 인라인으로 표시해 주는 도구)나 Snyk와 같은 스캔 확장 프로그램이 설치된 Visual Studio Code에서 AI가 생성한 Dockerfile을 열면, 즉시 경고 메시지가 표시될 수 있습니다. 사용자가 직접 선택하지도 않았는데 LLM이 오래된 Node 버전을 제공한 것입니다. 도구마다 메시지 문구는 다르지만, 일반적인 Next.js 설정에서는 대략 다음과 같은 형태입니다:

# Use the official Node.js runtime as the base image
FROM node:18-alpine AS builder

# Illustrative scanner warning:
# Image references an End-of-Life Node.js runtime (18.x, EOL 2025-04-30)
# and may include known vulnerabilities.
# Move to a supported LTS line, then rebuild, rescan, and test.

번역: AI가 제공한 ‘node:18’은 단순히 오래된 버전일 뿐이 아닙니다. Node.js 프로젝트는 더 이상 해당 버전에 대한 보안 업데이트를 제공하지 않으며, 공개된 이미지는 1년 넘게 재빌드되지 않았습니다. 빌드 자체는 완벽하게 작동하지만, 그 기반이 되는 구성 요소는 더 이상 지원되지 않습니다. 이것이 바로 “빌드가 성공하면”을 최종 목표로 삼을 때 간과되기 쉬운 소프트웨어 공급망 위험입니다.

AI Dockerfile generation
  |-- Base image suggestion (node:18-alpine)
   |-- EOL runtime, no upstream security releases
       |-- Image last rebuilt over a year ago

검토 과정에 인간적인 감성을 되살리기

원한다면 AI 사용을 그만두면 되겠지만, 제가 보기에는 매일 사용량이 증가하는 추세입니다. 하지만 검토 절차를 개선하여 속도가 검증 과정을 은연중에 대체하는 일이 없도록 할 수는 있습니다.

옵션 1. 수동 확인 및 수정

최신 IDE의 “Quick Fix” 도구를 사용하면 구식 제안 사항을 지원되는 제안 사항으로 대체할 수 있는 경우가 많습니다. AI 코드를 커밋하기 전에:

레지스트리만 확인하지 말고, 업스트림 프로젝트의 릴리스 일정을 확인하세요. 레지스트리는 유지보수자가 더 이상 지원하지 않는 태그라도 아무렇지 않게 제공할 수 있기 때문입니다.
AI가 제안한 버전과 목표 버전 간의 변경 내역 또는 마이그레이션 안내를 확인하세요.
태그를 변경하는 것만으로는 이미지가 깨끗하다는 것을 증명할 수 없으므로, 변경 후 다시 빌드하고 스캔하십시오.
빌드는 먼저 새 브랜치에서 테스트하고, 절대로 메인 브랜치에서 직접 테스트하지 마십시오.
“신속하게 진행하는 것”이 검토 과정을 생략해도 된다는 뜻은 아니라는 점을 명심하십시오.

옵션 2. 프롬프트 또는 구성 업데이트

모델이 추측할 여지를 줄이세요. 팀에서 지원하는 런타임 정책이 있다면, 프롬프트나 저장소 지침에 이를 명시하여 매번 적용되도록 하세요. 그래야 같은 제안을 반복해서 수정하는 수고를 덜 수 있습니다:

# Use a supported Node.js LTS base image
FROM node:24-alpine AS base

어떤 라인으로 전환하느냐가 중요합니다. 노드 24는 활성 LTS 라인으로, 2026년 10월 20일에 유지보수 단계로 전환되며 2028년 4월 30일에 지원 종료(EOL)에 이릅니다. 노드 22는 이미 유지보수 LTS 단계에 있으며, 지원 종료(EOL) 날짜는 2027년 4월 30일로 표시되어 있습니다. 노드 20은 2026년 4월에 EOL에 도달했습니다. 상담원은 세 가지 옵션 모두를 동일한 확신 어린 어조로 추천할 수 있으므로, 일정을 직접 확인하시기 바랍니다.

무엇을 명확히 할지 node:24-alpine 하지만 문제는, 이것이 고정된 버전이 아니라 동적으로 변경되는 메이저 버전 태그라는 점입니다. Docker Hub에는 지난 한 달 이내에 업데이트된 Node 24 Alpine 이미지가 표시되는데, 이는 패치를 반영하기에는 적합하지만 재현 가능한 빌드를 구축하기에는 적합하지 않습니다. 재현성이 중요하다면, 전체 버전과 Alpine 조합을 고정하거나 불변 다이제스트를 참조하고, 해당 고정 버전을 최신 상태로 유지하는 작업을 직접 담당해야 합니다.

완전히 새로 빌드하면 대체 빌드가 생성되고 경고가 사라진다는 사실만 알 수 있을 뿐입니다. 이는 이미지에 취약점이 전혀 없거나 앱이 여전히 정상적으로 작동한다는 것을 보장하지는 않습니다. 여전히 스캔과 테스트가 뒤따릅니다. AI는 속도 면에서 훌륭하지만, 이런 ‘교묘한’ 문제들을 찾아내기 위해서는 여전히 사람의 손길이 필요합니다.

어디에 노력을 쏟을지는 판단의 문제입니다. 내부 도구용 표준 코드 템플릿은 태그 확인과 스캔만 거치면 됩니다. 운영 트래픽, 인증, 비밀 정보 또는 의존성 트리와 관련된 모든 코드는 격리된 브랜치에서 전면적인 검토를 거칩니다.

항상 결과물을 확인하십시오. AI가 제안한 내용은 최종 계획이 아닌 초안으로 간주하십시오. 보안 도구의 경고 메시지를 비활성화한다고 해서 근본적인 기술 부채가 사라지는 것은 아닙니다.

SecureChain을 통한 보안 확장

수십 개에 달하는 서비스 전반에 걸친 종속성 위험을 관리하는 일은 어떤 보안 팀에게도 큰 부담이 될 수 있으며, 특히 AI가 사람이 수동으로 검토할 수 있는 속도보다 훨씬 빠르게 선택지를 생성할 때는 더욱 그렇습니다. 바로 이때 SecureChain이 귀사의 종속성 트리를 감싸는 ‘갑옷 같은 보호막’ 역할을 합니다.

기본 이미지는 단지 하나의 표면에 불과합니다. 선택했던 바로 그 조수가 node:18-alpine 또한 귀하의 package.json, 똑같은 낡은 그림에서 비롯된 문제입니다. SecureChain은 그 두 번째 영역을 보호하며, 빌드가 참조하는 대상으로서 공개 레지스트리를 대체합니다. 이러한 보호 기능은 다음 두 가지 측면에서 작용합니다:

제품 수명 종료(EOL) 전 보호 조치: 모든 패키지는 보안이 강화되고 격리된 환경에서 소스 코드부터 재컴파일되며, 알려진 악성코드, 의심스러운 코드 패턴 및 공급망 위험에 대한 검사를 거친 후, CVE가 발견될 때마다 SLA에 따라 패치가 적용됩니다. 여기에는 전이적 의존성도 포함됩니다.
제품 수명 주기 종료(EOL) 후 보호: 상위 버전의 유지보수가 종료되더라도, Endless Lifecycle Support(ELS) 를 통해 사용자가 현재 실행 중인 정확한 버전에 맞춰 역포트된 수정 사항을 지속적으로 제공합니다. 강제 업그레이드나 코드 재작성이 필요하지 않습니다.

리포지토리 관리자나 패키지 관리자를 SecureChain에 직접 연결한 후 작업을 계속하세요. 패키지, API, 워크플로우는 모두 동일합니다. 각 패키지에는 SLSA 레벨 3 출처 정보, SBOM 및 VEX 데이터가 포함되어 있어, AI가 제안한 종속성의 출처가 어디인지 묻는 경우 유용한 증거 자료가 됩니다.

이 모든 것이 코드 리뷰를 대체할 수는 없습니다. 즉, 종속성 보안이 보조 도구가 모든 버전 선택을 정확히 해내는 것에만 의존하는 것은 아니라는 뜻입니다.

핵심 요점

LLM이 여러분이 코드를 검토하는 속도보다 더 빨리 코드를 작성한다고 해서 당황하지 마세요. 그저 프로세스를 조정하면 됩니다. 제안은 그저 ‘제안’일 뿐이라는 점을 명심하세요. 코드 편집기나 IDE, 스캐너, 그리고 이용 가능한 기타 도구를 활용하여 취약점이 실제 운영 환경에 노출되기 전에 미리 발견하세요.

모델이 이를 눈치채든 못 채든 출시 일정은 계속 진행되며, 바로 그 간극에 AI가 생성한 코드의 취약점이 도사리고 있습니다. 안전하고 순조로운 출시를 위해 반드시 사람이 개입하도록 하십시오.

요약