# Fluid - 인프라를 위한 Claude Code

> Clean Markdown view of GeekNews topic #26430. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26430](https://news.hada.io/topic?id=26430)
- GeekNews Markdown: [https://news.hada.io/topic/26430.md](https://news.hada.io/topic/26430.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-06T04:34:29+09:00
- Updated: 2026-02-06T04:34:29+09:00
- Original source: [fluid.sh](https://www.fluid.sh/)
- Points: 5
- Comments: 1

## Summary

**Fluid**는 AI가 실제 인프라를 다루기 전에 **복제된 샌드박스 환경**에서 명령을 실행하고 결과를 검증하도록 설계된 터미널 기반 도구입니다. 복제된 VM이나 Kubernetes 클러스터에서 수행한 작업은 자동으로 **Ansible Playbook**으로 변환되어, 실험을 거친 재현 가능한 IaC로 이어집니다. 모든 명령은 감사 로그로 추적되며, **에페메럴 SSH 인증서**와 인간 승인 절차를 통해 보안성을 유지한 채 안전한 인프라 실험을 가능하게 합니다.

## Topic Body

- 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 서버에서도 동일한 설정을 재현 가능**  
  
### 설치 및 실행  
- 로컬 워크스테이션에 설치하는 **터미널 에이전트 형태**  
  - 설치 명령:  
    ```  
    curl -fsSL https://fluid.sh/install.sh | bash  
    fluid  
    ```  
- 설치 후 로컬 환경에서 바로 샌드박스 생성 및 테스트 가능  
  
### 요약  
- Fluid는 **AI 기반 인프라 자동화와 보안 격리**를 결합한 도구  
- 실시간 명령 실행, 감사 추적, Ansible 코드 생성 기능을 통해 **안전하고 재현 가능한 인프라 관리**를 지원  
- **Claude Code의 인프라 버전**으로, 개발자와 운영자가 프로덕션 환경을 모방해 실험할 수 있는 새로운 접근 제공

## Comments



### Comment 50685

- Author: neo
- Created: 2026-02-06T04:34:29+09:00
- Points: 1

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

- 내가 `curl -fsSL https://fluid.sh/install.sh | bash` 명령을 보고 웃었던 이유는,  
  원래 **보안상 SSH 접근을 막으려던** 의도였는데, 결과적으로 더 위험한 설치 스크립트를 실행하게 된 아이러니 때문임  
  관련 트윗은 [여기](https://x.com/sheeki03/status/2018382483465867444)에서 볼 수 있음
  - 요즘은 인터넷에 **악성 URL을 LLM이 추천하도록** 독을 뿌리는 세상임. 참 놀라운 시대임

- 나는 Collin이고, [fluid.sh](https://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을 반복 실행하는 것과 어떤 **차별 기능**이 있는지 알고 싶음
