서비스를 Docker 이미지로 묶어 동료에게 테스트나 배포를 맡기려 한다. 보안 스캐너를 돌리자 화면에는 갑자기 수십 개, 때로는 백 개가 넘는 경고가 뜬다. 패키지 버전이 오래되었고, 기반 이미지에 취약점이 있으며, Dockerfile(이 이미지를 어떻게 만들지 적어 둔 설정 파일) 작성 방식이 안전하지 않고, 어떤 설정은 컨테이너 권한을 너무 크게 열어 둘 수 있다는 내용이다.

보안을 매일 다루는 사람이 아니라면 두 극단에 빠지기 쉽다. 경고를 전부 무시하거나, AI에게 “전부 고쳐 줘”라고 맡기는 것이다. 앞의 선택은 실제로 위험한 구멍을 남길 수 있다. 뒤의 선택도 안전하지 않다. AI가 버전, 설치 방식, 실행 권한을 바꾸면서 서비스가 더 안전해 보이게 만들 수 있지만, 실제로는 다른 곳을 망가뜨릴 수 있기 때문이다.

OWASP Incubator Project인 DockSec은 최근 여러 보안 및 오픈소스 매체에서 소개되었다. 이 도구는 Trivy, Hadolint, Docker Scout 같은 기존 Docker 스캔 도구를 묶고, 대규모 언어 모델, 즉 글을 읽고 설명을 만들어 내는 AI를 사용해 경고를 정리하고 위험을 설명하며 Dockerfile 수정 제안을 제공한다. AI를 호출하지 않고 스캔만 수행하는 오프라인 모드(scan-only)도 제공하며, 설명이 필요할 때만 OpenAI, Anthropic, Google Gemini, 로컬 Ollama 같은 모델에 연결한다.

이런 도구의 가치는 AI가 대신 수정 버튼을 눌러 주는 데 있지 않다. 진짜 배울 점은 이것이다. 스캔 결과가 많아질수록 팀에는 “먼저 분류하고, 그다음 고치고, 마지막에는 사람이 확인하는” 흐름이 필요하다.

팀이 많은 Docker 보안 경고를 마주한 뒤 분류하고 테스트하며, 책임자가 어떤 수정 항목을 승인할 수 있는지 결정한다.

문제는 경고가 적은 것이 아니라, 너무 많아서 무엇부터 볼지 모르는 것이다

Docker는 프로그램, 실행 환경, 의존 패키지를 함께 포장하는 방식이다. 많은 웹사이트, API, 내부 도구, 작은 AI 서비스는 배포를 더 안정적으로 만들기 위해 Docker를 사용한다. 문제는 이 묶음 안에 운영체제 패키지, 언어 패키지, 설정 파일, 시작 명령이 동시에 들어갈 수 있다는 점이다. 어느 한 층이라도 오래되었거나 권한이 너무 크면 위험이 될 수 있다.

전통적인 스캔 도구는 문제를 찾는 데 능하지만, 무엇을 먼저 고쳐야 하는지까지 항상 잘 도와주지는 않는다. 일반 개발자에게 스캔 보고서는 흔히 이렇게 보인다.

  • 정말 급해서 오늘 고쳐야 하는 경고가 있다.
  • 패키지 안에는 존재하지만, 현재 서비스는 그 취약한 기능을 사용하지 않는 경고가 있다.
  • 단순한 버전 업그레이드처럼 보이는 수정이 실제로는 호환성에 영향을 줄 수 있다.
  • Dockerfile 제안은 합리적이지만 기존 배포 흐름을 망가뜨릴 수 있다.

DockSec 같은 도구가 메우려는 것은 “한 무더기의 경고”와 “이해 가능한 수정 계획” 사이의 빈틈이다. Open Source For You는 프로젝트 작성자의 말을 인용해, 개발자가 200개가 넘는 CVE, 즉 공개 번호가 붙은 보안 취약점을 받더라도 “도대체 어느 줄부터 고쳐야 하는지” 알기 어려운 상황을 소개했다.

하지만 여기에는 새로운 위험도 있다. AI가 수정 제안을 매끄럽게 설명하면, 팀은 판단까지 이미 끝났다고 느끼기 쉽다. 실제로는 그렇지 않다. AI는 단서를 정리할 수 있지만, 이 서비스의 버전을 바꿔도 되는지, 기반 이미지를 교체해도 되는지, 어떤 패키지를 삭제해도 되는지는 대신 결정할 수 없다.

먼저 세 층으로 나누기: 절차대로 수정, 테스트 후 수정, 사람이 결정할 수정

AI가 정리한 스캔 보고서를 볼 때, 먼저 “똑똑한가”를 묻지 말자. 먼저 물어야 할 것은 이 수정이 잘못되면 누구에게 영향을 주는가이다.

수정 층흔한 예다음 단계
절차대로 수정Dockerfile 형식, 명백히 불필요한 임시 파일, 문서화된 낮은 위험 설정제안대로 수정하되 차이 기록을 남긴다
테스트 후 수정패키지 버전 업그레이드, 기반 이미지 조정, 빌드 단계 변경격리된 테스트 환경에서 확인하고 실패 시 롤백／복구할 수 있게 한다
사람이 결정할 수정권한 모델 변경, 핵심 패키지 제거, 네트워크나 인증 정보 설정 변경, 고객 데이터 처리 영향책임자가 위험, 일정, 배포 창을 확인한다

이 표의 목적은 “AI 제안”을 “추적 가능한 수정 결정”으로 바꾸는 것이다. AI는 어떤 취약점이 왜 중요한지 설명하고 Dockerfile의 가능한 수정 위치를 가리킬 수 있다. 하지만 수정이 배포, 권한, 데이터 처리, 고객 이용 가능성에 영향을 준다면 AI 조언이 그대로 운영 환경까지 이어져서는 안 된다.

특히 권한 관련 수정은 더 조심해야 한다. 권한을 줄이는 것은 대체로 좋은 일이지만, 서비스가 특정 파일, 연결, 시스템 기능에 의존한다면 바로 잘라 냈을 때 테스트에서는 정상처럼 보이고 운영 환경에서만 깨질 수 있다. 보안은 모든 권한을 없애는 일이 아니다. 각 권한이 왜 존재하는지, 어떤 것은 제거할 수 있는지, 어떤 것은 더 좁은 대안으로 바꿔야 하는지 아는 일이다.

AI 수정 제안은 네 가지 확인을 거쳐야 한다

팀이 AI 보조 스캔을 일상 흐름에 넣고 싶다면, 각 수정 제안을 네 가지 확인점에 통과시키면 된다.

확인점물어볼 질문중요한 이유
영향 범위이 취약점이 현재 이미지, 실행 방식, 공개된 진입점에 실제로 영향을 주는가?작동하지 않는 경고에 시간을 쓰지 않기 위해
수정 내용AI가 제안하는 것은 버전, 설정, 권한, 또는 전체 빌드 흐름 중 무엇을 바꾸는가?수정 종류마다 필요한 테스트 강도가 다르기 때문에
테스트 증거수정 후 단위, 통합, 시작, 배포 테스트 중 무엇을 돌렸는가?“스캔 점수는 올랐지만 서비스는 망가진” 상황을 피하기 위해
복구 방식문제가 생기면 이전 버전으로 빠르게 돌아갈 수 있는가?보안 수정에도 롤백과 복구 계획이 필요하기 때문에

롤백／복구란 변경을 이전의 안정된 상태로 되돌리는 것이다. 이것은 비관적인 태도가 아니라 보안 작업의 일부다. 기반 이미지, 시스템 패키지, 배포 권한을 건드리는 수정일수록 변경 전에 되돌리는 방법을 알아야 한다.

0에서 100까지의 보안 점수도 유일한 목표로 삼지 말아야 한다. 점수는 개선을 추적하는 데 도움이 되지만, 제품이 안전한지에 대한 완전한 답은 아니다. 실제로 봐야 할 것은 높은 위험의 경고가 처리되었는지, 수정에 테스트가 있는지, 예외가 승인되었는지, 다음 스캔 때 왜 어떤 경고를 남겼는지 설명할 수 있는지다.

AI가 자동으로 고치게 하면 안 되는 상황

AI가 도와주기 좋은 작업도 있다. 보고서를 쉬운 말로 바꾸고, 중복 경고를 합치고, 가능한 Dockerfile 수정 방식을 나열하는 일이다. 이런 작업은 읽는 시간을 줄여 준다.

하지만 아래 상황에서는 AI가 자동으로 고친 결과를 그대로 운영 환경에 올리면 안 된다.

  • 서비스가 고객 데이터, 결제, 로그인, 내부 인증 정보, 회사 기밀을 다룬다.
  • 수정이 기반 이미지, 데이터베이스 드라이버, 암호화 패키지, 네트워크 설정을 바꾼다.
  • 자동 테스트가 없고, 명확한 배포 롤백／복구 방식도 없다.
  • 팀 안에 이 컨테이너에 어떤 권한이 필요한지 설명할 수 있는 사람이 없다.
  • 스캔 도구와 AI 모델이 보고서 데이터를 외부 서비스로 보내야 하는데, 그 안에 민감 정보가 있는지 아직 확인하지 않았다.

DockSec 문서는 오프라인 스캔만 수행할 수도 있고 필요할 때 여러 AI 모델을 사용할 수도 있다고 설명한다. 이것은 중요한 알림이다. 어떤 AI 보조 보안 도구를 도입하기 전에, 데이터가 로컬 밖으로 나가는지, 전체 이미지가 전송되는지 아니면 스캔 요약만 보내지는지, 누가 보고서를 볼 수 있는지, 보고서가 어디에 저장되는지 먼저 확인해야 한다.

아직 이 질문에 답할 수 없다면 운영 빌드 흐름에 넣지 말자. 먼저 격리된 테스트 환경에서 민감하지 않은 프로젝트로 분류와 수정 흐름을 연습하는 편이 낫다.

최소 흐름: AI는 설명하게 하고, 사람은 승인하게 하기

작은 팀이 처음부터 복잡한 보안 플랫폼을 만들 필요는 없다. 더 현실적인 방법은 스캔 결과를 간단한 표에 넣는 것이다. 이 표는 세 번째 새 기준이 아니다. 앞의 세 층 분류와 네 가지 확인점을 PR, 티켓, 수정 기록에 붙일 수 있는 작업표로 압축한 것이다.

항목적을 내용
경고 요약AI 또는 스캔 도구가 정리한 문제
영향 판단이 문제가 현재 서비스에 영향을 주는지. 주지 않는다면 이유
수정 유형절차대로 수정, 테스트 후 수정, 사람이 결정할 수정
테스트 증거수정 후 어떤 테스트를 돌렸고 결과가 어땠는지
승인자이 수정이 병합되거나 배포되어도 된다고 실제로 확인한 사람

이 흐름은 “한 번에 모두 고치기”보다 느려 보인다. 하지만 가장 위험한 오해를 막아 준다. AI가 취약점을 설명했다고 해서, 수정 이후의 결과까지 AI가 책임지는 것은 아니다.

생활 4컷 만화

4컷 만화: 팀이 많은 보안 경고를 받은 뒤 분류하고, AI가 단서 정리를 돕고, 마지막에는 사람이 승인할 수 있는 수정 항목을 결정한다.

  1. 팀은 보안 경고가 가득 담긴 상자를 받고, 처음에는 모든 카드가 급해 보인다.
  2. 먼저 경고를 절차대로 수정, 테스트 후 수정, 사람이 결정할 항목으로 나눈다.
  3. AI는 단서와 체크리스트 정리를 돕지만, 테스트와 복구 계획은 사람이 확인한다.
  4. 낮은 위험의 수정만 먼저 진행하고, 위험한 항목은 책임자의 결정을 기다린다.

DockSec 같은 도구는 보안 스캔을 더 읽기 쉽게 만든다. 그것은 좋은 일이다. 다만 읽기 쉬운 보고서일수록 명확한 사람의 관문이 필요하다. 다음에 Docker 스캐너가 취약점을 한꺼번에 쏟아낼 때, AI에게 전부 고치라고 서두르지 말자. 먼저 나누자. 무엇은 정리 작업인지, 무엇은 엔지니어링 수정인지, 무엇은 실제 제품 책임에 영향을 주는지.

AI 정리 카드

이 글의 상황에 맞춰 AI에게 정리하게 하기

자신의 AI 채팅 도구에 붙여 넣으면 이 미니 클래스를 개인용 체크리스트로 바꿀 수 있습니다. BMC는 사용자가 AI에 붙여 넣은 내용을 볼 수 없습니다.

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료