AI 에이전트가 서버에서 작업할 수 있도록 하는 모든 설정 방식은 두 가지 중 하나를 요구했습니다. 에이전트가 읽을 수 있는 어딘가에 개인 키(private key)를 붙여넣거나, 서버에 데몬(daemon)을 설치하여 계속 실행해 두는 방식이었습니다. 저는 첫 번째 방식은 하고 싶지 않았고, 두 번째 방식은 유지 관리하고 싶지 않았기에 약 1년 동안 운영(ops) 작업에 에이전트를 사용하지 않았습니다. 대신 창 하나를 열어두고 에이전트에게 문제를 설명한 뒤, 명령어는 제가 직접 입력했습니다.

결국 저를 괴롭혔던 점은 이것이었습니다: 저는 이미 인증된 SSH 세션을 열어두고 있습니다. 제가 매일 사용하는 파일 관리자에서 연결되어 있고, 호스트 키(host key)가 검증된 상태로 준비되어 있습니다. 에이전트에게는 자격 증명(credentials)이 필요한 것이 아닙니다. 에이전트에게 필요한 것은 바로 '그 세션'이며, 세션에 접근하기 전에 저에게 요청해야 합니다.

그것이 바로 제가 유지 관리하는 SFTP/SSH 클라이언트인 Faro의 Agent Bridge입니다. 저는 주로 로그를 추적(tailing)하거나 스테이징(staging)과 운영(prod) 환경 간의 설정을 비교(diffing)하는 읽기 전용 작업에 이를 사용해 왔습니다. 지난주에 저는 더 큰 결과가 따르는 작업에 이를 적용해 보았습니다: 두 개의 완전히 새로운 DigitalOcean 드롭릿(droplets), 하나의 프롬프트, 그리고 두 서버 모두에 전체 서버 제어 패널(server control panel)을 설치하는 작업이었습니다.

설명 없이 2분 만에 완료되었습니다. 직접 따라 해보고 싶다면 Faro와 ServerKit은 모두 MIT 라이선스입니다.

에이전트가 실제로 볼 수 있었던 것

Bridge는 MCP(Model Context Protocol)를 사용하는 HTTP 엔드포인트입니다. 이는 임의의 포트에서 127.0.0.1에 바인딩되며, 실행할 때마다 새로 생성되는 베어러 토큰(bearer token)을 요구하고, 머신에 이미 존재하는 것이 아니면 그 어떤 것에도 아무것도 제공하지 않습니다. 에이전트를 연결하는 것은 한 줄의 명령어로 가능합니다:

claude mcp add --transport http faro http://127.0.0.1:<port>/mcp \
  --header "Authorization: Bearer <token>"

그곳에서 에이전트는 25개의 도구(tools)를 얻게 됩니다. 사람들이 반응하는 것은 faro_exec이지만, 가장 유용한 작업은 대부분 faro_list_dir, faro_read_file, faro_search, faro_tail, faro_diff와 같은 것들입니다. 즉, 변형(mutation)이 아닌 조사(inspection) 작업입니다. "두 서버의 nginx 설정을 읽고 무엇이 다른지 말해줘"라고 말할 수 있는 능력은 원격 실행(remote execution)보다 일상 업무에서 훨씬 더 가치 있는 것으로 드러났습니다.

도구 호출(tool call)과 제 서버 사이에는 세 가지 요소가 존재합니다. 세션은 한 번에 하나씩 선택적으로 참여(opt-in)하므로, 제가 접근 권한을 부여하지 않은 저장된 연결은 에이전트가 받는 목록에 포함되지 않습니다. 즉, 에이전트는 볼 수 없는 박스(box)에 대해서는 작업을 수행할 수 없습니다. 부수 효과(side effects)를 동반하는 모든 작업은 Faro 창에 정확한 명령어를 보여주는 프롬프트를 띄우며, 호출은 제가 응답하거나 2분 후 타임아웃이 발생할 때까지 차단(block)됩니다. 그리고 승인되거나 거부된 모든 호출은 실행 중인 활동 로그(activity log)에 기록됩니다.

이 중 그 어떤 것도 에이전트가 비밀(secret)을 보유하는 것과는 관련이 없습니다. 에이전트는 localhost와 통신합니다. Faro가 SSH 세션을 유지하며, 원격 측에는 아무것도 설치되지 않습니다. 이는 제가 대규모 플릿(fleet) 관리에서 가장 중요하게 생각하는 부분입니다.

프롬프트

제가 입력한 전체 내용은 다음과 같습니다:

faro-cli를 사용하여 serverkit-test-server-1과 serverkit-test-server-2에 
ServerKit을 병렬로 설치하세요: curl -fsSL https://serverkit.ai/install.sh | bash
2개의 관리자 URL을 반환하세요.

IP, 사용자 이름, 키 경로(key paths)는 전혀 포함되지 않았습니다. 오직 두 개의 이름뿐이며, 이는 제가 몇 달 전 Faro에 저장해 두었던 것과 동일한 이름입니다.

이것이 작동하는 이유는 GUI가 실행 중인 것과 동일한 브릿지(Bridge)와 통신하는 독립형 바이너리인 faro-cli 덕분입니다. 이 도구는 Faro의 로컬 디스커버리 파일(local discovery file)에서 URL과 토큰을 읽어오므로, 스크립트가 이 둘을 직접 다루는 일은 결코 발생하지 않습니다:

faro-cli agent sessions
# → serverkit-test-server-1  sftp  159.223.187.83
# → serverkit-test-server-2  sftp  157.230.230.92
...

이런 방식으로 전달되는 명령어도 여전히 승인 게이트(approval gate)를 거쳐야 하며 콘솔에 나타납니다. CLI는 잠금 장치를 우회하는 방법이 아니라, 동일한 방으로 들어가는 또 다른 문일 뿐입니다.

왜 서버가 두 대인가

서버 한 대였다면 데모는 더 쉬웠겠지만, 덜 정직했을 것입니다. 플릿(fleet) 작업에서 흥미로운 모든 일은 두 대부터 시작됩니다. 두 번째 박스는 드리프트(drift)가 시작되는 곳이며, 잘못된 IP를 붙여넣거나, 여섯 단계는 정확히 수행하고 일곱 번째 단계를 잊어버리는 곳이기 때문입니다.

그래서 저는 의도적으로 다르게 설정했습니다. serverkit-test-server-1은 SSH 키를 사용합니다. serverkit-test-server-2는 DigitalOcean에서 이메일로 보내주는 루트(root) 비밀번호를 사용합니다. 두 서버 모두 결국 동일한 연결 목록의 일반적인 항목으로 남게 되며, 에이전트(agent)가 이를 확인하는 시점에는 그 차이가 더 이상 중요하지 않게 됩니다. 에이전트는 두 개의 이름을 부여받았고, 그것들을 동일하게 취급했습니다.

에이전트는 플릿(fleet)을 나열하고 두 프로필 모두에 명령을 실행했으며, 두 개의 설치 스트림(install streams)이 나란히 실행되었습니다. 각각 약 1분 정도 걸렸습니다. 그 후 에이전트는 두 개의 URL을 반환했고, 제가 두 개를 모두 열었을 때 녹화를 시작할 당시에는 비어 있었던 하드웨어 위에 두 개의 작동하는 패널이 떠 있었습니다.

마음에 들지 않는 점

승인 피로(Approval fatigue)가 진짜 문제입니다. 그리고 저는 이 문제를 해결하지 못했다고 생각합니다. 설치 프로그램을 지켜본다는 것은 계속해서 승인을 클릭해야 함을 의미하며, 계속해서 승인을 클릭하는 행위는 읽는 것을 멈추도록 스스로를 훈련시키는 것과 같습니다. 프로필별로 저장되어 재시작 후에도 유지되는 완화된 정책들 — 모두 허용(allow-all), 읽기 전용 작업 자동 승인, 안전 및 읽기 전용으로 매칭된 명령 자동 승인 — 이 있습니다. 각각은 보안 결정이며, 저는 사람들이 마흔 번째 프롬프트쯤에서 표류하듯 승인하기보다는 시작 단계에서 의도적으로 결정하기를 바랍니다.

더 불편한 제한 사항은 다음과 같습니다: 승인은 명령 자체를 대상으로 하며, 그 명령이 무엇을 수행하는지는 대상으로 하지 않습니다. 저는 curl … | bash를 승인했습니다. 그 스크립트가 이후에 무엇을 했는지는 저와 해당 URL에 대한 저의 신뢰 사이의 문제입니다. Bridge는 자격 증명 노출(credential exposure)과 원격 데몬(remote daemon)을 제거합니다. 하지만 판단력(judgment)을 제거하지는 않습니다. 이 범주의 도구에 대해 그렇지 않다고 주장하는 사람이 있다면 저는 의심스러울 것입니다.

그 외에도: 설계상 로컬호스트(localhost) 전용이며, 이는 책상에 앉아 있는 운영자에게는 적합하지만 CI(지속적 통합)에는 아무런 도움이 되지 않습니다. 데스크톱 빌드는 아직 Apple이나 Windows 인증서가 없기 때문에 서명되지 않았으며, 따라서 모든 OS는 처음 실행할 때 경고를 띄웁니다. 그리고 영상에 나온 두 개의 드롭릿(droplets)은 모두 일회용이었으며, 이후 파괴되었습니다.

시도해보기

Faro는 Tauri 2 기반의 Rust로 작성된 SFTP, FTP, SSH, S3 호환 스토리지, WebDAV 및 몇몇 클라우드를 위한 데스크톱 클라이언트입니다: github.com/jhd3197/faro. ServerKit은 그것이 설치한 패널로, 단 하나의 명령어로 셀프 호스팅(self-hosted)이 가능합니다:

curl -fsSL https://serverkit.ai/install.sh | bash

둘 다 MIT 라이선스이며 무료이고, 외부로 데이터를 전송(phones home)하지 않습니다.

제가 계속해서 생각을 바꾸고 있는 미결정 사항(open question)은 자동 승인(auto-approval)이 어디에서 멈춰야 하는가 하는 점입니다. 읽기 전용 검사(Read-only inspection)는 분명히 괜찮습니다. apt install은 문제가 생기기 전날까지는 괜찮게 느껴집니다. 만약 여러분이 에이전트(agent)에게 이런 종류의 권한을 부여했다면, 여러분은 어디에서 선을 그었는지 알고 싶습니다. 저는 곧 기본값(defaults)을 배포할 예정인데, 저 혼자서 그것들을 만들어내고 싶지는 않기 때문입니다.