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을 반복 실행하는 것과 어떤 차별 기능이 있는지 알고 싶음