Hacker News 의견들

• 작은 디테일 같지만 몇 가지 새로운 설계 결정이 업계 전반에 퍼지면 혁신적 변화를 가져올 것 같음
  Karpathy가 언급했듯, Slack·Discord 같은 통합을 직접 구현하는 대신 “통합을 작성하는 방법”에 대한 스킬(spec) 을 제공하는 접근이 핵심임
  “Claude native development”라 부를 수 있는데, 기존의 “batteries-included” 프레임워크 대신 “fork and customize” 방식으로 생태계가 이동할 것 같음
  다만 테스트·검증·보안 같은 스펙을 어떻게 배포할지 등 해결할 과제도 많음
  OS 수준에서도 이런 변화가 일어날 수 있을지 궁금함. 각 인스턴스가 강한 면역체계를 가진다면 공격에 더 강한 이질적 생태계가 될 수 있을 것 같음

  • 각 사용자가 같은 작업을 반복해야 하므로 효율성이 떨어질 것 같음. 한 번 구현해 모두가 공유하는 편이 낫다고 생각함
  • 오픈소스의 강점은 협업과 검증 과정임. LLM이 처음엔 버그를 많이 내듯, 사람도 마찬가지임. 나는 검증된 기반 위에서 커스터마이징하는 게 더 낫다고 봄
  • 코드 대신 Markdown 스펙 파일을 주고받으며 기능을 구현하는 세상이 될 수도 있겠다는 생각을 해봄

• 보안 도구나 샌드박싱을 논할 때는 반드시 위협 모델(threat model) 을 명시해야 함
  AI 에이전트가 비밀 데이터가 있는 호스트에서 임의 코드를 실행할 수 있다는 점이 위험함
  예를 들어, 메일함 삭제, 캘린더 유출, 잘못된 송금 등은 샌드박스만으로 막을 수 없음
  따라서 샌드박싱 외에도 작업별·도구별 세분화된 권한 제어가 필요함. 예: “이 요청은 Gmail 읽기만 가능하고, 쓰기·삭제는 불가해야 함”

  • 완전히 동의함. 여기에 더해 도구 간 데이터 흐름 추적(IFC) 과 권한 감쇠(ocap) 기능이 필요함. 예를 들어 “원래 메일 스레드 외부로 데이터 전송 금지” 같은 정책을 표현할 수 있어야 함
  • “Don’t Trust AI Agents” 글에서 말했듯, AI 에이전트는 불신을 전제로 설계해야 함. 오작동이나 프롬프트 인젝션을 가정하고 피해를 최소화하는 구조가 필요함
  • 나는 정책 제어 중심의 에이전트 프레임워크 smith-core와 게이트웨이 smith-gateway를 만들었음. 하지만 이런 보안 설계 논의는 커뮤니티에서 거의 주목받지 못함
  • 흥미로운 글을 봤는데, OpenClaw Sandbox에서 언급하듯 권한은 이진적이지만 LLM의 행동은 확률적이라 두 개념이 본질적으로 충돌함
  • 사실 IAM, WIF, Macaroons, Service Accounts 같은 기존 권한 시스템이 이미 존재함. 보안팀에 물어보면 회사 내에서도 활용 가능한 솔루션이 있을 것임

• NanoClaw가 마음에 듦. OpenClaw는 너무 복잡했는데 NanoClaw는 훨씬 간결함
  Claude Code를 설정 인터페이스로 쓰는 첫 프로젝트인데, 기능 추가도 재미있고 잘 작동함

  • 내 OpenClaw 인스턴스는 최근 깨졌음. 업데이트가 OpenRouter 통합을 망가뜨렸고, 코드가 지나치게 복잡함
    보안 모델도 내 루트리스 Kubernetes 환경과 맞지 않아 매번 문제가 생김
    그래서 Nullclaw로 옮겼음. Zig 언어를 배우며 디버깅할 수 있어서 학습 측면에서도 흥미로움
  • Nanoclaw에서 Claude로는 쉽게 만들 수 없는 워크플로우가 어떤 게 있는지 궁금함

• Docker 샌드박스는 Apple의 container 프레임워크와 유사함
  macOS에서는 Docker보다 훨씬 가벼운 네이티브 런타임으로 적합함
  하지만 Linux에서는 하이퍼바이저를 쓰고 싶지 않음. Linux namespace만으로도 충분히 격리 가능함
  왜 OpenClaw나 NanoClaw는 제대로 구성된 공식 Docker 이미지를 제공하지 않는지 궁금함

  • 나는 macOS에서는 Apple Container, 다른 OS에서는 Podman을 씀
    Container의 네트워크 버그가 좀 있지만 가치가 큼. DNS 설정만 수정하면 됨
    Claude Code나 Node.js를 호스트에 설치하지 않아도 돼서 만족스러움

• 컨테이너 여부보다 중요한 건 무엇을 하려는가임
  유용한 작업에 토큰을 쓰는 방법을 찾기 전까지 런타임은 부차적임
  보안 측면에서 LLM을 컨테이너에 넣는 것만으로는 부족함. 중요한 건 접근 가능한 정보의 범위임
  에이전트가 모든 데이터에 접근할 수 있다면 그게 진짜 위험임

  • Docker 샌드박스는 MicroVM을 추가 격리층으로 사용함. 단순한 컨테이너가 아님

• 세밀한 권한과 정책 제어가 핵심임
  단순히 어떤 도구를 쓸 수 있는지가 아니라, 무엇을 할 수 있는지까지 정의해야 함
  예: 이메일 읽기만 가능, 특정 저장소만 접근, 지출 한도 설정 등
  Docker 샌드박싱만으로는 메시징 계정 같은 민감한 자산을 LLM에게 맡기기엔 불안함

• Docker 샌드박스는 각 에이전트마다 전용 MicroVM과 Docker 데몬을 띄우고, 유연한 egress 프록시를 함께 구성함
  리버스 엔지니어링해봤는데 꽤 흥미로운 구현임

• NanoClaw는 바로 쓸 수 있는 완제품이 아님
  코딩 에이전트를 통해 iMessage 같은 기능을 직접 추가해야 함
  즉, Claude가 컴파일러 역할을 하는 셈임

  • 예전엔 컴파일러가 생성한 어셈블리를 직접 확인하던 시절이 있었음
    코딩 에이전트도 아직 그 수준임. 최근 “코딩 에이전트가 훨씬 좋아졌다”는 말은 과장임
    여전히 Claude에게 “그건 해결이 안 됐어, 다시 해줘”라고 반복 지시해야 함

• 나는 “claws”와 비슷한 아이디어를 작업 중임
  메시징 앱 통합 대신 종단간 암호화된 TUI를 제공하는 방식임
  wingthing.ai / GitHub 저장소 참고
  Docker 지원 방식을 고민 중이라 이 프로젝트도 살펴볼 예정임

• Nano/Open-Claw의 명확한 사용 사례가 궁금함. 내 디지털 생활을 대신 운영하는 건가?

  • 사실 단순함. LLM 크론잡이거나, 텔레그램·이메일 같은 채팅 커넥터임. 전자는 일반 크론으로, 후자는 수동 코드나 Gemini Gems로도 가능함
  • 이메일 요약, 일정 알림, 브리핑 문서 등 반복적 지식 작업을 자동화하는 데 유용함
  • 할 일 앱과 연결해 봇에게 메시지로 관리시키는 식임. 생산성 향상에 도움됨
  • 나는 NanoClaw를 식단·운동 코치로 씀. 목표 관리, 식단 계획, 장보기 리스트, 운동 기록까지 담당함
    Apple Container로 옮기고, LanceDB 기반 장기 기억 기능도 추가했음. 이제 같은 말을 반복할 필요가 없음