▲

Fluid - 인프라를 위한 Claude Code

 (fluid.sh)
2P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • AI 에이전트가 실제 인프라를 안전하게 다룰 수 있도록 샌드박스 복제 환경을 만드는 터미널 기반 도구
  • 복제된 VM이나 Kubernetes 클러스터에서 명령 실행, 파일 수정, 연결 테스트를 수행하고 결과를 Ansible Playbook 형태로 자동 생성
  • 단순히 LLM이 코드를 생성하는 방식과 달리, 실제 환경을 복제해 테스트와 검증을 거친 IaC(Infra-as-Code) 를 생성
  • 에페메럴 SSH 인증서를 사용해 안전하게 명령을 실행하며, 리소스가 부족한 호스트나 인터넷 접근 시에는 인간 승인 절차 필요
  • 모든 명령과 변경 사항이 감사 로그로 추적되며, 개발자가 로컬 환경에서 인프라를 실험하고 재현 가능한 설정을 만들 수 있는 도구

Fluid 개요

  • Fluid는 프로덕션 인프라(예: VM, K8s 클러스터) 를 복제한 샌드박스에서 AI가 작업하도록 하는 터미널 에이전트
    • AI 에이전트가 명령 실행, 연결 테스트, 파일 편집을 수행
    • 이후 결과를 Ansible Playbook 형태로 변환해 프로덕션 환경에 적용 가능
  • 이 방식은 AI가 실제 시스템 구조를 추측하지 않고, 복제된 환경에서 직접 실험할 수 있게 함

기존 LLM 기반 IaC 생성과의 차이

  • LLM은 Terraform, OpenTofu, Ansible 등의 코드를 잘 생성하지만, 실제 프로덕션 환경의 동작을 정확히 파악하지 못함
  • Fluid는 복제된 인프라 접근을 통해 명령 실행과 테스트를 선행하고, 그 결과를 기반으로 IaC를 작성
  • 이러한 접근은 배포 전 검증과 실험을 가능하게 함

Claude Code와의 차별점 및 보안 설계

  • Fluid는 Claude Code가 로컬에서 직접 프로덕션 서버에 SSH 접속하지 않도록 설계
  • 모든 작업은 샌드박스 내에서만 실행되며, Fluid가 이를 관리
  • 에페메럴 SSH 인증서를 사용해 명령 실행 결과를 실시간으로 표시
  • 메모리나 CPU가 낮은 호스트, 인터넷 접근, 패키지 설치 등은 인간 승인 절차를 거쳐야 함

주요 기능

  • Sandbox Isolation: VM을 즉시 복제해 프로덕션에 영향을 주지 않고 변경 사항을 테스트
  • Context-Aware: 호스트의 OS, 패키지, CLI 도구를 탐색해 환경에 맞게 동작
  • Full Audit Trail: 모든 명령과 변경 사항을 기록해 감사 및 검토 가능
  • Ansible Playbook 자동 생성: 샌드박스에서 수행한 작업을 기반으로 재현 가능한 인프라 코드 생성

사용 예시

  • Fluid는 v create_sandbox 명령으로 샌드박스를 생성하고, IP와 상태를 표시
  • v run_command로 명령을 실행하며, 예시에서는 Ubuntu 22.04 환경에서 Apache HTTP Server 설치 및 실행
  • curl localhost로 웹 서버 동작을 검증
  • 이후 v create_playbook으로 httpd-setup 플레이북을 생성
    • 4개의 태스크 포함: apt 캐시 업데이트, Apache 설치, index.html 생성, Apache 서비스 시작 및 활성화
  • 생성된 플레이북은 다른 Ubuntu 서버에서도 동일한 설정을 재현 가능

설치 및 실행

  • 로컬 워크스테이션에 설치하는 터미널 에이전트 형태
  • 설치 후 로컬 환경에서 바로 샌드박스 생성 및 테스트 가능

요약

  • Fluid는 AI 기반 인프라 자동화와 보안 격리를 결합한 도구
  • 실시간 명령 실행, 감사 추적, Ansible 코드 생성 기능을 통해 안전하고 재현 가능한 인프라 관리를 지원
  • Claude Code의 인프라 버전으로, 개발자와 운영자가 프로덕션 환경을 모방해 실험할 수 있는 새로운 접근 제공
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 요즘은 뭔가를 만들기 위한 도구는 넘쳐나는데, 정작 만들 대상이 없다는 느낌임
    마치 모든 제품이 또 다른 빌드 툴을 위한 피라미드 구조의 일부처럼 느껴짐
    fluid.sh에 대한 불만은 아니고, 단지 나도 뭘 만들어야 할지 고민 중임

    • 2007년 Facebook 앱 붐 때 스타트업에서 일했는데, 모든 앱 회사가 다른 앱 광고를 파는 구조였음
      앱 생태계가 완전히 순환 경제처럼 돌아갔고, 실제 사용자 가치나 수익원은 없었음. 결국 오래가지 못했음
    • 문제는 많은 개발자가 도메인 지식 없이 소프트웨어 기술만 깊게 파는 데 있음
    • 나도 비(非)테크 업계에서 1년째 일하고 있는데, 코딩 능력 덕분에 동료들에게 마법사 취급을 받음
      실제 문제를 해결하면서 코드베이스가 점점 재사용 가능한 기능으로 발전하고 있음
      이제는 이 경험을 기반으로 컨설팅을 시도 중이며, 언젠가 ‘제품’이라 부를 수 있는 걸 찾을 것 같음
    • 거시경제학적으로 보면, 기술이 너무 빠르게 발전하면 오히려 산출량이 감소하는 구간이 있음
      지금의 AI 툴 붐도 비슷한 현상 같음. 너무 빠른 변화 속에서 모두가 다시 배우는 중임
      결국 우리는 움직이는 모래 위에 기반을 쌓는 셈임
    • 나도 같은 고민을 했지만, 최근엔 이런 툴들을 리버스 엔지니어링에 활용하기 시작했음
      예를 들어 중국산 라벨 프린터의 리눅스 인쇄 품질이 마음에 안 들어서, BLE로 직접 출력하는 Go 스크립트를 만들었음
      안드로이드 앱을 디컴파일하는 대신 Agentic AI에게 맡겼고, 지금은 브라우저 버전과 ESP32 버전까지 있음
      관련 글은 Making a label printer work under Linux using Agentic AI에 정리했음

  • 내가 curl -fsSL https://fluid.sh/install.sh | bash 명령을 보고 웃었던 이유는,
    원래 보안상 SSH 접근을 막으려던 의도였는데, 결과적으로 더 위험한 설치 스크립트를 실행하게 된 아이러니 때문임
    관련 트윗은 여기에서 볼 수 있음

    • 요즘은 인터넷에 악성 URL을 LLM이 추천하도록 독을 뿌리는 세상임. 참 놀라운 시대임

  • 나는 Collin이고, fluid.sh를 만들고 있음
    Claude Code의 인프라 버전이라 보면 됨.
    Fluid는 프로덕션 인프라(VM, K8s 등)의 샌드박스 복제본을 만들어, AI 에이전트가 명령 실행·파일 수정·테스트를 한 뒤
    Ansible Playbook 같은 IaC를 생성하도록 함
    LLM이 단순히 Terraform을 생성하는 것보다, 실제 환경을 탐색하며 문맥을 이해할 수 있게 하는 게 핵심임
    보안상 이유로 Claude Code가 직접 프로덕션에 SSH 접속하지 않도록 설계했고,
    ephemeral SSH 인증서로 명령 실행을 추적 가능하게 함
    리소스가 적은 호스트나 외부 네트워크 접근 시에는 사람의 승인을 요구함
    피드백 환영함!

    • 이런 설명을 왜 홈페이지에 안 넣었는지 궁금함.
      지금 사이트에는 “Claude Code for infrastructure” 정도만 써 있어서,
      인프라 엔지니어가 bash 한 줄로 설치하기엔 너무 불친절함
    • 인프라 복제본을 여러 개 띄워서 에이전트가 돌아다니게 하는 건 비용 낭비처럼 보임
      DevOps를 하는 입장에서 이건 비효율적임
    • 원격 샌드박스에서 수동 설정을 하는 건 Infrastructure as Code 철학과 맞지 않음
      나는 Pulumi, Tilt, Kubernetes 조합으로 충분히 자동화하고 있음
      Claude도 이 환경에서 잘 작동함. 굳이 SSH로 직접 만질 필요는 없음
    • 그렇다면 기존 VM에 Claude Code를 배포해 돌리는 것과 뭐가 다른지 모르겠음
      이미 여러 샌드박싱 방법이 있음. 차별점이 궁금함
    • Terraformer로 기존 인프라를 복제할 수도 있는데,
      이런 기본적인 IaC 자동화가 안 되어 있다면 DevOps 팀이 문제임
    • “Claude Code에게 kubectl 명령을 시켜 Helm 차트를 고치게 한다”는 식으로 이미 하고 있음
      일반 CLI로도 충분히 잘 작동함
      • 요즘 LLM 기반 툴 중 상당수가 이런 프롬프트 래퍼 수준임. 본질적 차별점이 없음
      • 나도 비슷하게 느끼지만, 이 프로젝트는 대규모 환경의 안전성 확보를 위한 목적이 있음
        수백 대 VM 단위로 운영할 때는 단순 감시만으로는 부족함
      • 나도 읽기 전용 계정으로 Claude를 돌리는데, Terraform이나 AWS CLI와도 잘 연동됨
        굳이 새로운 툴이 필요하진 않음
      • 나도 읽기 전용 kubeconfig로 제한을 두고, SKILL.md만 잘 작성하면 충분히 안전하게 작동함
      • 읽기 전용으로 풀어둬도 큰 문제는 없었음.
        다만 이 프로젝트는 재현성과 안전성을 더 강조하는 접근 같음
    • 프로덕션 복제는 간단하지 않음. DB 연결이나 전체 스택 복제는 현실적으로 어려움
      차라리 AI가 프로덕션 구조를 이해하고 직접 변경하는 게 낫다고 봄
      이미 모델들은 IaC 작성에 충분히 능숙함
    • 아이디어는 흥미로움. 요즘 운영·관측(Observability) 분야가 뜨고 있음
      나도 Kubernetes 운영 중 Claude에게 Grafana 접근 권한을 줘서 디버깅을 돕게 하는데,
      덕분에 수십 시간을 절약했음.
      Ansible Playbook을 자동 생성하는 접근은 감사 추적성 측면에서도 훌륭함
      • 하지만 이런 자동화가 확산되면, 운영 인력의 불안정성이 커질 수 있음
        실제로 숙련된 엔지니어들이 일자리를 잃는 사례도 생기고 있음
      • Kubernetes 지원 계획이 있다니 기대됨. 아이디어가 마음에 듦
    • 솔직히 이건 이미 해결된 문제라고 생각함
      대부분은 처음부터 IaC로 인프라를 구성하고, 필요하면 역으로 재구성할 수 있음
      Claude를 샌드박스 계정에서 IAM 역할로 돌리면 충분함
    • “LLM이 프로덕션 시스템을 잘 추측하지 못한다”는 주장엔 동의하지 않음
      IaC는 API를 통해 인프라를 질의할 수 있고, 재사용성과 버전 관리가 장점임
      • DevOps 환경은 회사마다 다르고, 일반화가 어렵다는 점엔 동의함
        대부분의 스타트업은 여전히 HCL이나 YAML 수준에서 고전 중임
    • “안전하게 하려면 curl 스크립트를 실행하라”는 문구가 아이러니하게 느껴짐
    • 혹시 이게 KVM을 libvirt로 제어하고 SSH 키를 발급해 LLM이 VM에 접근하는 구조인가?
      Ansible Playbook은 VM 내부 변경을 기반으로 생성되는 건지, 아니면 Ansible로만 조작하는 건지 궁금함
      단순히 Ansible을 반복 실행하는 것과 어떤 차별 기능이 있는지 알고 싶음
답변달기