TL;DR

  • 에이전트를 샌드박스에서 YOLO 모드로 실행하려고 Orca와 VSCode Agents window를 써봤지만, 둘 다 샌드박스 밖의 IDE나 SSH 권한에 접근할 수 있어 결국 tmux로 돌아감.
  • 에이전트 격리를 위해 개발 컨테이너, Podman 컨테이너, 원격 SSH 호스트, GitHub Codespaces, 마이크로 VM 등 여러 방식을 써봤으며 각각 장단점이 있음.
  • Docker Sandboxes는 로그인 요구, 비공개 소스, 불명확한 라이선스, 기본 텔레메트리 등 단점이 있지만 트래픽 제어와 시크릿 주입을 위한 네트워크 프록시는 유용함.
  • Orca CLI는 Orca에서 열린 모든 셸에 임의 명령을 보낼 수 있고, VSCode 에이전트는 VSCode 인스턴스와 SSH 에이전트에 접근할 수 있어 샌드박스 격리를 약화함.
  • tmux와 Neovim을 SSH 또는 mosh와 함께 쓰는 구성은 안정적이고 맞춤화하기 쉬우며, AI 에이전트 시대에 IDE와 에이전트 개발 환경(ADE)이 꼭 필요한지 의문을 제기함.

Orca와 VSCode Agents window를 써본 뒤 다시 tmux로 돌아감

  • 에이전트는 YOLO 모드에서 가장 잘 작동함.
  • 에이전트에서 최대한 많은 성능을 끌어내면서 파일 손실, 시스템 설정 변경이나 새 소프트웨어 설치, 명백히 안전하지 않은 브라우저·컴퓨터 사용, 프롬프트 인젝션 공격 등의 위험을 줄이기 위해 샌드박스에서 실행함.
  • 에이전트 격리 방법으로 개발 컨테이너, 독립형 Podman 컨테이너, 임대 서버나 가상 머신(VM)을 포함한 원격 SSH 호스트, GitHub Codespaces, 로컬 또는 원격 마이크로 VM(Docker Sandboxes)을 사용해 봄. 모든 방식에는 장단점이 있으며 상황에 따라 달라짐.
  • Docker Sandboxes는 로그인 필요, 비공개 소스, 불명확한 라이선스 조건, 관련 없는 Docker 또는 Docker Engine 사용을 곳곳에서 유도하고 사전 설치하기도 하는 점, 기본 활성화된 텔레메트리, 아무 작업도 하지 않을 때도 상당한 CPU를 쓰는 터미널 사용자 인터페이스(TUI), 기본 활성화된 SSH 에이전트 전달 등의 단점이 있음.
  • 그럼에도 트래픽 제어와 시크릿 주입을 위해 함께 제공되는 네트워크 프록시는 유용함.
  • 에이전트와 함께 작업하면 작업을 병렬화할 필요가 있고, 경험의 중심이 텍스트 편집에서 벗어나므로 다음 단계로 에이전트 개발 환경(ADE)을 시도함.

Orca

  • Orca를 사용하기 시작해 에이전트 샌드박스에 SSH로 접속함. 겉보기에는 괜찮았지만 Orca CLI를 에이전트도 사용할 수 있다는 점을 곧 발견함.
  • Orca CLI를 사용하면 IDE에서 열어 둔 모든 셸을 에이전트가 나열하고 임의 명령을 보낼 수 있음.
  • 확인 요청을 보냈고, CTO는 이것이 의도된 동작이라고 곧 답변함.
  • Orca는 다음 동작을 동시에 수행함.
  • 에이전트를 YOLO 모드로 실행함.
  • 에이전트에 Orca에서 열려 있는 모든 셸, 즉 로컬 IDE와 원격 호스트를 포함해 모든 프로젝트의 셸에서 임의 명령을 실행할 수 있는 CLI를 제공함.
  • 이에 Orca를 제거함.
  • 누군가 Orca에서 사용할 Docker 샌드박스 설정을 제공하는 것으로 보이는 저장소를 공개함. 굵게 쓰인 문구는 “호스트는 안전하게 유지됨”임.
  • Orca CLI 때문에 그 접근 방식은 작동하지 않아 이를 알리는 이슈를 등록함. 관련 없거나 경쟁 관계인 제품의 AI 에이전트가 생성한 답변을 받음. GitHub 이슈를 통한 광고임. 시대의 징후인지 의문임.

VSCode Agents window

  • Agents window는 Microsoft의 새 UI로, 기본적으로 VSCode 안의 ADE임.
  • Agents window를 포함한 VSCode도 Orca와 같은 문제를 겪음. 에이전트 샌드박스에 SSH로 접속하면 에이전트가 VSCode 인스턴스로 되돌아가 확장 프로그램을 설치하거나 임의의 링크를 열 수 있음. 이 동작을 비활성화하려고 시도한 내용은 별도 글에 정리함.
  • 백그라운드에서는 여러 동작이 일어남. 여기에는 샌드박스로의 대용량 전송(“VSCode remote”로 인해 디스크 사용량이 기가바이트 단위로 늘어남)과 기본적으로 자동 전달되는 SSH 에이전트가 포함됨.
  • SSH 에이전트가 전달되면 샌드박스의 AI 에이전트가 사용자를 대신해 접근 권한이 있는 다른 모든 머신에 SSH로 접속할 수 있으며, 사용자와 동일한 접근 권한을 갖게 됨.
  • 작성 시점에는 모델 선택기가 오작동해 샌드박스의 에이전트에 제공되는 모델을 사용자가 선택할 수 없음. 공개 이슈가 있으며, 이미 길고 AI가 생성한 답변이 달리고 있음.
  • VSCode를 제거하지는 않았으며, 가끔 저장소를 둘러보는 용도로 사용함.

Herdr는 어떨까?

  • 아직 Herdr는 사용해 보지 않음.
  • GPT-6에 “에이전트 하네스의 터미널 벨 알림을 이미 지원하는 내 tmux 설정을 고려할 때, Herdr와 tmux의 근본적인 차이는 무엇인가?”라고 질문함.
  • GPT-6은 tmux를 계속 사용하라고 답했으며, 근본적인 차이는 없고 Herdr의 일부 기능은 불안정하다고 설명함. Herdr가 가능한 한 터미널 출력의 문자 그대로의 내용을 토대로 에이전트 상태를 감지하는데, 이 방식은 불안정하기 때문임.
  • 그래도 언젠가는 시도해 봐야 함. 놓치고 있는 무언가가 있을 수 있음.

다시 tmux로

  • SSH 또는 mosh를 통한 tmux와 Neovim 조합은 매우 좋음. 오래된 도구지만 매우 잘 작동하고 다용도이며 안정적임.
  • 포트, 호스트 이름, DNS 등을 관리하는 Tailscale을 더하면 충분함.
  • 이 도구들은 맞춤화할 수 있으며, AI 에이전트의 도움으로 맞춤화가 점점 쉬워지고 있음. 몇 시간, 어쩌면 몇 분 만에 마음에 드는 가벼운 Herdr 버전을, 적어도 필요한 부분만큼은 다시 만들 수 있음.
  • 그러면 사용하는 도구를 직접 이해하게 된다는 이점도 따라옴.
  • 현재 설정이 무려 11년 전 설정인데도 가장 좋은 설정이라는 점이 놀라움. 이 설정을 근육 기억에 이를 정도로 완전히 능숙하게 다룰 수 있어 기쁘고, 운이 좋다고도 느낌.
  • 물론 이런 생각 때문에 스스로를 의심하게 됨. 2026년에는 더 나은 방법이 분명 있지 않을까? 확신이 없어 계속 찾아볼 예정임.

무슨 의미일까?

  • 흥미로운 교훈이 없을 수도 있음. AI는 텍스트 생성에 강하고 효율적이어서, 우연히 코딩과 CLI 도구 사용에 특히 잘 맞을 뿐일 수 있음.
  • 그 결과 두 가지 변화가 동시에 일어남.
  • 에이전트가 코드를 작성하므로, 처음 VSCode를 사용하게 한 강력한 코드 편집 경험의 필요성이 사라짐.
  • tmux, Neovim, SSH 계열 도구는 이 시대에 훨씬 강력하고 적합해짐.
  • 이에 따라 IDE가 끝나고 ADE도 필요하지 않은지 질문하게 됨.
  • 하지만 이 글은 다른 이야기도 보여주는 듯함. 사람들이 토큰을 소모해 빠르게 만든 소프트웨어가 그다지 훌륭하지 않거나, 아예 필요하지 않거나, 충분히 고민되지 않았다는 이야기임. 적어도 아직 완성되지 않은 상태임.
  • 몇 달 안에 모든 것이 괜찮아질 수도 있음.