Claude Code for Infrastructure: Fluid로 안전하게 IaC 자동화하기
Claude Code for Infrastructure는 “AI가 인프라를 만지면 위험하지 않나?”라는 오래된 불안을 정면으로 다룹니다. 핵심은 Fluid라는 터미널 에이전트가 실제 VM·Kubernetes 같은 운영 환경을 그대로 복제한 샌드박스를 만들고, 그 안에서만 AI가 명령 실행과 파일 수정, 연결 테스트까지 하게 만든다는 점입니다1. 덕분에 배포 전에 인프라 변경을 충분히 실험하고, 검증이 끝난 결과를 Infra-as-Code(예: Ansible Playbook)로 뽑아 재현 가능한 형태로 남길 수 있습니다. 이 글에서는 “왜 필요한지 → 어떻게 안전한지 → 실무에서 어떻게 쓰는지” 순서로 정리해볼게요.
AI 인프라 자동화가 위험해지는 진짜 이유(실환경 불일치)
LLM이 생성한 설정이나 스크립트는 “그럴듯한 정답”을 잘 만듭니다. 문제는 인프라에서는 그 ‘그럴듯함’이 곧 장애가 된다는 점이에요. 패키지 매니저가 apt인지 yum인지, 서비스 이름이 apache2인지 httpd인지, 방화벽 정책과 네트워크 대역이 어떻게 생겼는지 같은 디테일이 실제 환경마다 다릅니다.
사람은 보통 운영 서버에 바로 손대기 전에 문서와 기억, 약간의 감으로 간격을 메우는데요. AI가 그 간격을 추측으로 메우면 “실행은 되는데 운영 표준과 다름”, “테스트에서는 되는데 배포에서 깨짐” 같은 일이 생깁니다. Claude Code for Infrastructure가 노리는 포인트는 여기입니다. 추측을 줄이려면, AI가 ‘진짜와 동일한 조건’에서 직접 해보고 배우게 해야 하거든요1.
Fluid 샌드박스: 운영 환경을 복제해 “안전한 실험실” 만들기
Fluid는 실제 인프라를 복제해 샌드박스를 구성합니다. 이 샌드박스는 단순한 로컬 컨테이너가 아니라, VM이나 Kubernetes 클러스터 등 현업에서 쓰는 구성에 맞춰 “거의 운영과 같은 조건”을 재현하는 쪽에 초점이 있습니다1. 그래서 AI가 그 안에서 명령을 실행하고, 파일을 편집하고, 서비스 기동이나 HTTP 응답 같은 연결 테스트까지 진행할 수 있습니다.
여기서 중요한 장점이 하나 더 있습니다. AI가 생성한 변경이 현실과 부딪히면(예: 패키지 이름이 다르다거나, 포트가 막혀 있다거나) 그 즉시 샌드박스에서 실패합니다. 그러면 AI는 실패 로그를 근거로 설정을 수정하고 다시 테스트하면서, 결과적으로 “이 환경에서 통하는 IaC”에 가까워집니다. 즉, IaC가 문서가 아니라 실험 결과물에서 태어나는 구조가 됩니다.
보안 설계 핵심: 운영 접근 차단, 승인 게이트, 감사 트레일
인프라 자동화에서 가장 무서운 건 “의도치 않은 파괴”와 “추적 불가능한 변경”입니다. Fluid는 애초에 생산 시스템에 직접 접근하지 않는 방식으로 설계되어 있고, 샌드박스 내부에서만 도구와 명령어를 쓰게 제한합니다1. 인프라팀이 불안해하는 ‘운영 서버에 AI 계정 만들어주기’ 같은 접근을 피할 수 있다는 뜻이죠.
또한 에이전트는 에페메럴(잠깐 쓰고 폐기되는) SSH 인증서를 통해 작업하고, 모든 실행 내역을 기록해 감사 트레일을 남깁니다1. 여기에 더해 메모리/CPU가 낮은 호스트에서의 작업이나 인터넷 접근, 패키지 설치처럼 위험도가 큰 행동은 사람 승인을 거치도록 가드레일을 둡니다1. “자동화”와 “통제”를 같이 가져가려는 설계라고 보면 됩니다.
Ansible Playbook 자동 생성: ‘명령어 메모’가 아니라 재현 가능한 결과물로
현장에서 자주 벌어지는 장면이 있어요. 급한 장애 대응이나 긴급 설정 변경 후에 “나중에 playbook으로 정리해야지” 했다가… 결국 위키에 명령어 몇 줄만 남고 끝나는 경우요. 그러면 다음에 같은 작업을 또 수동으로 하게 되고, 사람마다 방법이 달라지면서 표준이 흐트러집니다.
Fluid 흐름은 반대입니다. 샌드박스에서 AI가 실제로 설치·설정·테스트를 수행한 뒤, 그 과정을 Ansible Playbook 같은 IaC로 자동 변환해줍니다1. 예를 들어 Apache를 설치하고 서비스 활성화, index.html 커스텀 페이지 배포까지 끝낸 다음, apt 업데이트부터 필요한 패키지 설치, 파일 생성, 서비스 enable/start를 포함한 playbook을 뽑아내는 식입니다1. “잘 될 것 같은 코드”가 아니라 “이미 샌드박스에서 검증된 코드”가 남는 게 핵심이에요.
실무 적용 시나리오: 샌드박스에서 끝까지 해보고, 그다음 배포하기
업무 흐름을 한 편의 짧은 스토리로 그려보면 이해가 쉬워요.
월요일 오전, 신규 서버에 웹서버를 올려야 합니다. 평소라면 누군가는 운영 서버에 접속해 패키지 설치부터 하고, 누군가는 문서를 뒤져 표준 설정을 찾고, 마지막엔 “이거 누가 했지?”가 남습니다.
이때 Claude Code for Infrastructure 방식이라면 먼저 샌드박스를 만들고, 그 안에서 Apache 설치와 상태 점검, 커스텀 페이지 생성, 접속 테스트까지 전부 수행합니다1. 실패하면 그 자리에서 로그를 보고 수정합니다. 성공하면 그 과정을 playbook으로 생성하고, 변경 내역과 실행 기록까지 남깁니다1. 이후 다른 서버에 동일 환경이 필요할 때는 그 playbook을 재사용하면 됩니다. 인프라 작업이 ‘한 번 하고 끝’이 아니라 ‘복제 가능한 레시피’가 되는 순간이죠.
시사점: “AI가 운영을 망친다”를 “AI가 운영을 표준화한다”로 바꾸는 법
Claude Code for Infrastructure와 Fluid가 주는 함의는 단순히 “AI가 인프라를 해준다”가 아닙니다. 운영을 직접 만지는 대신, 운영을 닮은 샌드박스에서 끝까지 실험하게 만들고, 그 결과를 IaC로 남겨 재현성과 감사 가능성을 확보하는 모델입니다1.
실무 팁을 하나만 꼽자면, 처음부터 거창한 마이그레이션보다 “자주 반복되는 작업 1개”로 시작해보세요. 예를 들어 신규 VM 초기 세팅, Nginx/Apache 기본 배포, 기본 모니터링 에이전트 설치 같은 것들요. 샌드박스에서 검증된 playbook이 하나씩 쌓이면, 인프라팀의 일은 ‘수동 작업’에서 ‘표준 레시피 관리’로 자연스럽게 이동합니다. 그때부터 AI는 위험한 마법사가 아니라, 표준화를 돕는 성실한 조수에 가까워질 겁니다.