원격 실행기

에이전트에게 실제로 작업할 컴퓨터를 제공하세요. Linux, macOS, Windows를 지원합니다.

원격 실행기란 무엇인가

Nessie의 에이전트에는 컴퓨터가 없습니다. 에이전트는 Nessie 안의 내용을 읽고, 사람들과 대화하고, 네트워크를 통해 연결된 도구를 호출할 수 있습니다. 하지만 노트북의 파일을 열거나, 명령을 실행하거나, 누군가의 로그인 뒤에만 있는 페이지를 볼 수는 없습니다. 원격 실행기는 에이전트에 작업할 수 있는 머신을 주는 방법입니다.

실행기는 여러분이 관리하는 컴퓨터에 설치하는 작은 데몬입니다. 데몬은 외부 방향으로 여러분의 Nessie 인스턴스와 페어링하고, 호스트를 떠나지 않는 키로 자신이 어떤 머신인지 증명한 뒤, 고정된 이름의 작업 목록만 제공합니다. 그 밖의 기능은 없습니다. 작업은 서명된 개별 명령으로 도착하고, 결과는 크기가 제한된 구조화된 수신 기록으로 돌아옵니다. 머신은 Nessie로부터 어떤 인바운드 연결도 받지 않습니다.

실행기가 아닌 것을 정확히 짚어 둘 필요가 있습니다. 대부분의 원격 접속 도구는 다음 중 하나에 해당하지만, 실행기는 의도적으로 그중 어느 것도 아닙니다. SSH가 없고, 제약 없는 원격 셸이 없고, 이미 열려 있는 터미널 멀티플렉서에 붙는 기능이 없고, 클라우드 쪽 표준 입력이 없고, 일반적인 로컬 네트워크 프록시도 없습니다. MCP 서버도 아니고, 컨테이너나 클라우드 실행 환경도 아닙니다. Nessie에는 이미 그런 기능이 있으며, 그것들은 실행기와 전혀 다른 것입니다. 실행기는 권한을 지닌 엔드포인트이며, 닫힌 작업 목록을 가집니다. 그 목록이 전체 노출 범위입니다.

실행기의 소유 범위

모든 실행기는 정확히 하나의 범위로 만들어지며, 만든 뒤에는 그 범위를 바꿀 수 없습니다. 범위는 누가 실행기를 호출할 수 있고 누가 관리할 수 있는지를 정합니다.

비공개 실행기에는 활성 상태의 사람 관리자가 항상 최소 한 명 있어야 합니다. 마지막 관리자를 직접 제거하면 실패합니다. 퇴사 처리 과정에서 관리자가 한 명도 남지 않게 되면, 실행기는 새 작업 수락을 멈추고, 가지고 있는 작업을 마친 뒤 스스로 접근 권한을 취소합니다. 조직 소유자에게는 관리하지 않는 실행기를 종료할 수 있는 취소 전용 비상 경로가 있습니다. 이 경로는 비공개 명단, 세션, 내용을 보여주지 않습니다. 비공개 접근 권한이 누군가에게 몰래 넘어가는 일은 없습니다.

에이전트가 실제로 할 수 있는 일

작업 어휘는 배포 환경마다 설정하는 것이 아니라 코드에 고정되어 있습니다. 작업은 두 부류로 나뉘며, 이 구분에 따라 무엇을 설치해야 하는지가 정해집니다. 일부 작업은 가상 머신 없이 데몬이 자체 임시 디렉터리에서 처리하고, 나머지는 호스트에서 세션마다 실행되는 게스트 VM이 필요합니다.

게스트가 필요 없는 작업은 워크스페이스 번들입니다. 게스트를 시작할 수 없는 호스트는 고장난 실행기가 아닙니다. 평소처럼 페어링되며, 샌드박스 백엔드를 none으로 보고하고, 워크스페이스 번들만 제공합니다. Hyper-V가 없는 Windows 에디션이나, 사용자에게 /dev/kvm 사용 권한이 없는 Linux 머신이 바로 이런 상태가 됩니다. 인터페이스는 이를 모호한 실패로 두지 않고 명확하게 알려 줍니다.

브라우저 작업은 에이전트가 스스로 시작하는 일이 없습니다. 일반적인 단일 작업 바인딩 경로는 browser.open과 browser.observe를 거부합니다. 브라우저 실행은 사람이 채널에서 새 실행으로 시작하며, 네 가지 작업이 묶인 하나의 번들로 동작합니다. 이후에는 다른 바인딩을 추가할 수 없습니다. 관리되는 코딩 세션도 같은 방식으로 동작합니다.

코드에는 두 가지 작업 그룹이 더 있지만, 의도적으로 사용할 수 없게 되어 있습니다. 이미 로그인된 Chrome 탭을 조작하는 작업은 로컬 구현이 완성되어 있고 네이티브 메시징 확장 프로그램도 있습니다. 그러나 서버가 원래 대화가 비공개였음을 증명하고 누가 무엇을 공개했는지 기록할 수 있을 때까지, 제어 플레인은 이를 광고하지 않습니다. 이 기반은 의도적으로 비활성 상태이며, 확장 프로그램은 두 설치 파일 어디에도 포함되어 있지 않습니다. 또한 코딩 작업 중 attach, prompt, interrupt, close는 스키마에 이름만 있고 구현이 없어서 권한을 부여할 수 없습니다.

작동 방식

연결은 항상 외부를 향합니다

데몬은 Nessie API와만 아웃바운드 HTTPS 및 WSS 연결을 만듭니다. Nessie는 노트북으로 연결을 시도하지 않으며, 노트북의 주소를 보관하지도 않고, 카탈로그의 어떤 엔드포인트도 머신 전송 수단으로 취급하지 않습니다. 그래서 실행기는 가정 네트워크, NAT 뒤, 회사 VPN에서도 포트 포워딩이나 인바운드 방화벽 규칙 없이 작동합니다. 데몬을 중지하는 것만으로도 연결이 완전히 즉시 끊어집니다.

API 출처는 반드시 HTTPS여야 합니다. 예외는 자신의 컴퓨터에서 Nessie를 실행하는 사람을 위한 루프백 주소뿐이며, 이는 별도의 환경 변수로 설정합니다. 일반적인 플래그로 프로덕션 출처를 평문 HTTP로 바꿀 수는 없습니다.

페어링은 머신을 증명하고, 사람이 확인합니다

페어링은 양쪽이 함께 증명하는 절차입니다. 권한이 있는 사람이 Nessie에서 범위를 정해 실행기를 만들면, Nessie는 등록 요청을 발급합니다. 이는 256비트 무작위 챌린지이며, Nessie는 그 SHA-256 검증값만 저장합니다. 유효 기간은 10분이고 한 번만 사용할 수 있습니다.

머신에서 데몬은 Ed25519 키 쌍을 생성하고, 소유자만 접근할 수 있는 OS 보호 저장소에 보관합니다. 또한 네트워크 호출을 하기 전에 정확한 서명 요청을 디스크에 기록하므로, 응답이 유실되어도 준비된 같은 키로 재시도할 수 있으며 조용히 두 번 페어링되는 일이 없습니다. 그다음 등록 요청 ID, 챌린지, 공개 키, 증명 서명을 제출합니다. Nessie는 공개 키와 지문을 저장하며, 개인 키는 절대 저장하지 않습니다.

Nessie는 이 지문을 사람에게 보여주고, 사람이 이를 확인합니다. 이 확인과 이후의 소유 증명이 이루어질 때까지 실행기는 오프라인 상태로 남습니다. 페어링은 채팅 텍스트나 터미널 기록으로 완료할 수 없으며, 웹 또는 데스크톱 인터페이스에서 사람이 의도적으로 수행해야 합니다.

키를 잃은 머신은 실행기 기록을 되찾을 수 없습니다. 그 실행기는 취소되고, 새 실행기로 다시 등록해야 합니다. 반면 키 교체는 이전 키와 새 키로 함께 서명한 하나의 트랜잭션으로 이루어집니다.

디스크립터는 머신이 자신에 대해 하는 서명된 주장입니다

페어링된 데몬은 디스크립터를 게시합니다. 이는 서명되고 단조 증가하는 리비전으로, 구조적 사실만 담습니다. 지원하는 작업 스키마, 리소스와 네트워크 한도, 플랫폼, 로컬 정책의 다이제스트가 여기에 포함됩니다. 호스트 경로는 포함하지 않으며, 클라우드에 어떤 권한도 만들지 않습니다.

새 리비전은 도착하는 즉시 활성화되지 않습니다. 검토 대기 상태로 저장되며, 권한이 있는 사람이 이를 확인하고 승인해야 사용 가능한 작업에 영향을 줄 수 있습니다. 이것이 기능 새로 고침으로 새 권한이 조용히 부여되는 일을 막습니다. 새로 광고된 작업은 거부 상태로 시작합니다.

서명이 무엇을 증명하는지 분명히 해야 합니다. 페어링된 실행기 키로 서명된 디스크립터는 그 키가 이 주장을 했다는 사실만 증명합니다. 호스트가 손상되지 않았다는 것은 증명하지 않으며, 인터페이스도 이를 명시해야 합니다.

디스패치: 후보, 바인딩, 명령, 수신 기록

에이전트는 실행기를 직접 지정하지 않습니다. 실행이 실행기를 사용하기 전에 Nessie는 논리 작업을 불투명하고 수명이 짧은 가용성 후보로 변환합니다. 응답에는 실행기 ID가 없으며, 데이터베이스에는 핸들의 다이제스트와, 누구를 위해 무엇으로 해석되었는지만 보관합니다. 모델과 클라이언트는 선택할 수 있는 머신이 아니라 핸들을 받습니다.

가용성은 API, 워커, UI, 어시스턴트가 모두 똑같이 사용하는 하나의 해석기로 처리됩니다.

available(operation, human, agent, immutableRunContext) =
  human may discover executor
  ∩ exact executor-agent-operation grant allows operation
  ∩ stable logical tool grant allows operation
  ∩ scope matches immutable run context
  ∩ executor is online and descriptor is approved
  ∩ local policy permits operation

후보를 사용하면 데이터베이스 잠금 아래에서 바인딩이 만들어집니다. 이 과정에서 위의 모든 게이트를 한 번 더 확인하고, 단조 증가하는 펜스를 올립니다. 디스패치 때 다시 확인합니다. 따라서 두 단계 사이에 권한이 철회되거나, 정책이 좁혀지거나, 실행기가 취소되면 작업이 나중에 발견되는 것이 아니라 즉시 멈춥니다. 재시도가 실행을 바인딩된 머신과 다른 머신으로 보내는 일은 결코 없습니다.

명령 자체는 별도의 큐가 아니라 Nessie의 기존 큐 작업과 도구 호출 수명 주기 위에서 전달됩니다. 데몬은 인증된 제어 채널로 작업을 폴링하며, 먼저 푸시를 받지 않습니다. 명령은 다음 네 가지 수신 기록을 거치며, 다른 기록은 없습니다.

leased → accepted → started → result-acknowledged

모든 프레임은 명령 ID, 실행 출처, 바인딩 펜스, 기능 리비전, 만료 시각, 멱등성 키, 인자와 페이로드의 다이제스트를 함께 묶습니다. 데몬은 불일치, 오래된 정책, 재전송, 이미 완료한 명령에 대한 두 번째 결과를 거부합니다. 인자와 최종 결과는 저장 시 AES-256-GCM으로 암호화되며, 데이터베이스에는 제한된 암호문과 정규화된 다이제스트만 보관하고 내용은 보관하지 않습니다.

확인 응답이 유실되면 Nessie는 성공했다고 가정하지 않습니다. 명령은 결과 불명으로 기록되고, 실행은 일반 복구 경로를 따릅니다. 데몬은 작업을 시작하기 전에 전달받은 각 명령을 로컬에 기록하므로, 부작용을 반복하지 않습니다. 나중에 도착하는 수신 기록으로 이 불확실성을 정직하게 해소할 수 있습니다.

신뢰 경계

실행기 설치와 페어링

Mac CLI는 Homebrew로, Mac 앱은 Homebrew 캐스크로, Linux CLI는 APT 또는 DNF로, Windows 실행기는 WinGet으로 설치합니다. 페어링된 팀마다 별도의 권한이 컴퓨터에 저장됩니다. Nessie는 팀 안에서 접근을 관리하지만, 로컬 리소스는 변경할 수 없습니다.

설치 및 페어링 안내서에는 정확한 명령, 양쪽에서 입력하는 8자리 코드 절차, 로컬 설정, 시작, 업데이트, 제거 방법이 나와 있습니다.

각 플랫폼이 실제로 검증된 정도

세 가지 게스트 샌드박스의 상태는 서로 다르며, 그 차이는 중요합니다. macOS는 실제로 작동하고 검증된 게스트 경로를 갖춘 백엔드입니다. Linux의 Firecracker 백엔드와 Windows의 Hyper-V 백엔드는 구현되어 있으며, 실행 순서, 디스크 이미지, 제어 및 출구 전송, 초안 프로토콜 등을 호스트 측 테스트로 다룹니다. 그러나 이를 증명하려면 KVM 또는 Hyper-V를 갖춘 머신이 필요하고, 이 프로젝트의 지속적 통합 작업에는 그런 머신이 한 번도 없었습니다. 그래서 아직 어떤 게스트도 실제 하드웨어에서 부팅된 적이 없습니다. 게스트가 필요 없는 워크스페이스 번들은 Windows에서 실제 제어 루프를 대상으로 처음부터 끝까지 검증되었습니다. 직접 하드웨어에서 증명하기 전까지는 Linux와 Windows의 게스트 기반 작업을 검증되지 않은 것으로 취급하세요. Nessie의 페어링 화면도 같은 내용을 자체 문구로 알려 줍니다.

보안과 격리

작업 루트는 하나이며, 그 경로는 머신에 남습니다

페어링하면 정확히 하나의 정식 작업 루트가 선택됩니다. 여러 폴더의 집합이 아니라 디렉터리 하나이며, 가장 가까운 공통 상위 디렉터리도 아닙니다. Nessie는 루트의 기본 이름만 전달받으므로, 사용자는 인터페이스에서 그 경계를 알아볼 수 있습니다. 전체 경로는 소유자만 접근할 수 있는 머신 상태에만 남으며, 업로드되지 않습니다. 루트를 바꿀 수는 있지만, 로컬 초안과 샌드박스를 모두 삭제한 뒤에만 가능하며, 다른 정책 변경과 마찬가지로 사람의 검토를 거치는 새 디스크립터 리비전을 만듭니다. 상위 디렉터리로 조용히 넓어지는 일은 결코 없습니다.

파일 작업은 상대 경로만 허용합니다. 상위 경로 이동과 모든 심볼릭 링크 구성 요소를 거부하고, 설정된 루트가 여전히 일반 디렉터리인지 다시 확인하며, 호스트 경로가 없는 제한된 구조화 결과만 반환합니다.

쓰기는 사본으로 가고, 적용은 사람만 합니다

에이전트는 사용자의 파일에 절대 쓰지 않습니다. file.write는 데몬 자체 상태 디렉터리 아래에 실행 단위로 묶인 제한된 쓰기 시 복사 트리를 만듭니다. 이후 해당 실행의 읽기와 목록 조회는 그 초안을 봅니다. 코딩 세션을 포함한 게스트 작업도 같은 쓰기 시 복사 임시 공간을 사용합니다.

초안을 실제 작업 공간에 적용하는 작업은 workspace.promote 하나이며, 시스템에서 유일한 호스트 쓰기입니다. 모델에 노출되는 스키마는 전혀 없습니다. 에이전트, 어시스턴트, 호출자가 제공한 경로 중 어떤 것도 초안을 호스트 쓰기로 바꿀 수 없습니다. 대신 사람이 검토된 초안을 열고, 적용 검토를 누른 뒤 현재 비밀번호로 확인합니다. 그러면 서버는 확인된 검토 다이제스트, 매니페스트 다이제스트, 원래 실행, 사용자, 에이전트, 권한 리비전, 작업 권한, 활성 로컬 정책을 다시 확인한 뒤에 명령을 만듭니다. 머신에서는 데몬이 매니페스트를 직접 다시 만들고, 다이제스트가 바뀌었으면 거부합니다. 따라서 검토 후에 가한 편집이 검토 승인에 묻어 들어갈 수 없습니다.

적용 자체는 디스크립터 기반이며 저널에 기록됩니다. 네이티브 도우미는 작업 루트와 초안을 경로가 아니라 이미 열린 디렉터리 디스크립터로 받습니다. 모든 구성 요소를 심볼릭 링크를 따라가지 않는(no-follow) 작업으로 검증하고, 심볼릭 링크, 하드 링크, 특수 파일, 마운트 경계 넘기를 거부합니다. 또한 전부 적용하거나 전부 복구하는 저널을 유지하므로, 적용 중 충돌이 나더라도 검증된 매니페스트를 끝내거나, 그 밖의 어떤 것이 실행되기 전에 원래 상태로 되돌립니다.

게스트에는 네트워크가 없고, 외부 연결은 강제로 거칩니다

작업에 게스트가 필요하면, 그것은 세션마다 만들어지는 Linux 마이크로 VM입니다. 호스트 홈 디렉터리, Docker 소켓, SSH 에이전트, 상속된 환경 변수가 없고, 워크스페이스 공유를 제외한 호스트 마운트도 없습니다. 실행 가능한 런타임 마운트는 읽기 전용이며, 쓰기 가능한 워크스페이스 마운트는 실행을 금지합니다. 따라서 실행되는 것은 에이전트가 작성한 파일이 아니라 검증된 런타임 페이로드에서 옵니다. 게스트는 소켓을 열기 전에 권한이 없는 신원으로 내려가며, 루트 소유 공유가 있으면 권한 있는 작업을 그대로 실행시키는 대신 부팅을 실패시킵니다.

가장 중요한 점은 게스트에 네트워크 인터페이스가 없다는 것입니다. Linux에서 실행 순서는 네트워크를 의도적으로 구성하지 않으며 TAP 장치도 만들지 않습니다. Windows에서는 Hyper-V가 기본으로 추가하는 가상 네트워크 어댑터를 설정 중에 제거합니다. 게스트가 머신 밖으로 나갈 수 있는 경로는 내부의 루프백 프록시뿐이며, 이는 가상 소켓을 통해 호스트의 브리지로 터널링됩니다. 브리지는 바이트를 데몬 자체의 게이트웨이로 넘깁니다. 이 게이트웨이는 소유자만 접근할 수 있는 로컬 소켓 리스너이며, TCP 리스너나 일반 전달 모드가 없습니다. HTTP, CONNECT, WebSocket, 리디렉션, 출처, 다운로드, 업로드 정책이 모두 이곳에서 시행되며, 같은 규칙을 두 번 구현하지 않고 Nessie에 이미 있는 고정 가져오기(pinned fetch) 기능을 사용합니다. NAT 브리지나 직접 DNS 리졸버는 없습니다. 대체 DNS, 원시 TCP, QUIC, 프록시 우회는 모두 거부됩니다.

이 게이트웨이가 시행하는 출처 목록은 머신 소유자가 머신에 설정하며, 의도적으로 업로드되지 않습니다. 인터페이스는 Nessie가 출처 정책 편집기인 척하지 않고 이 사실을 그대로 알려 줍니다. 브라우저 실행기가 어디에 접근할 수 있는지 알고 싶다면, 머신을 소유한 사람에게 물어보세요.

자격 증명

호스트의 자격 증명 저장소는 어떤 게스트에도 마운트되지 않습니다. 키체인, ~/.codex나 ~/.claude, 전역 CLI 토큰, API 키를 담은 환경 변수도 포함됩니다. 관리되는 코딩 세션에서 지원되는 로그인 방식은 소유자 전용 인증 파일 하나뿐입니다. 이 파일의 내용은 소유자가 관리하는 initrd 빌더만 읽으며, Nessie, 디스크립터, 로그, 명령 인자는 읽지 않습니다. 파일은 한 번 게스트 안의 비공개 홈 디렉터리로 옮겨지며, 이 홈은 VM과 함께 삭제됩니다. 그 게스트는 정확히 한 개의 출처에만 접근할 수 있습니다.

브라우저 실행기는 더 엄격합니다. 각 세션은 새로운 비공개 브라우저 프로필을 받으며, 작업 공간이 준비한 프로필은 거부합니다. 따라서 쿠키, 확장 프로그램, 주변의 로그인 상태 없이 시작합니다.

원시 로컬 데이터는 명시적이고 제한된 실행 안에서만 모델 제공자에게 전달될 수 있습니다. Nessie가 저장하는 것은 민감 정보를 가린 매니페스트, 인자와 정책 다이제스트, 결과 다이제스트, 구조화된 상태뿐입니다. 파일 내용, 터미널 출력, 브라우저 DOM, 자격 증명, 인증 요소는 데이터베이스 기록, 감사 항목, 로그, 실시간 이벤트, 오류 보고에 저장할 수 없습니다.

운영자가 무엇을 허용하고, 어떻게 취소하는가

실행기를 사용할 권한은 단일 스위치가 아닙니다. 에이전트는 정확히 그 실행기와 정확히 그 작업에 대한 권한이 있고, 그리고 일반 논리 도구 정책이 허용하고, 그리고 실행 범위가 맞고, 그리고 머신 자체의 로컬 정책이 허용할 때만 작업을 호출할 수 있습니다. 따라서 한 실행기에 작업을 허용해도 다른 실행기에는 아무 권한도 생기지 않으며, 기능 새로 고침도 권한을 넓힐 수 없습니다. 새 작업은 거부 상태로 도착하기 때문입니다.

에이전트 접근과 공유는 모두 페이지에서 즉시 적용되며, 승인 절차, 비밀번호 입력, 재인증 단계가 없습니다. 실행기의 에이전트 탭에서 관리자는 에이전트의 머신 접근을 직접 켜거나 끌 수 있습니다. 공유 탭에서는 같은 방식으로 사람에게 사용 가능 또는 관리자 권한을 주거나, 프로젝트나 현재 팀의 모든 구성원에게 사용 권한을 확장할 수 있습니다. 여러분의 개인 비서 대화에서만, 즉 공유 채널, 예약 작업, 다른 에이전트의 실행에서는 제외하고, 어시스턴트가 에이전트 접근이나 할당 변경을 대신 준비할 수 있습니다. 이때 그 대화에 확인 카드가 게시됩니다. 여러분이 그 카드에서 접근 허용을 누르기 전까지는 아무것도 바뀌지 않으며, 채팅 텍스트는 확인으로 간주되지 않습니다.

다음 세 가지 변경은 확인 시점에 현재 비밀번호를 다시 입력해야 합니다. 디스크립터 리비전 활성화, 어시스턴트가 준비한 할당 중 에이전트가 아니라 사람에게 머신을 주는 할당, 그리고 동료가 소유자 자격으로 명령을 시작할 수 있게 하는 상시 정책인 무인 티켓 작업 정책입니다. 머신 연결 해제나 삭제는 의도적으로 둘 다 요구하지 않습니다. 긴급 차단 스위치가 자신이 막는 대상보다 더 어려워서는 안 되기 때문입니다. 검토된 초안의 적용은 항상 비밀번호를 요구합니다. 감사 기록은 실제로 행동한 사람과 어시스턴트의 관여를 구분해 기록합니다.

실행기는 다음과 같은 작고 명시적인 상태들을 거칩니다:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

헤더의 컴퓨터 메뉴에서 관리자는 수명 주기 변경을 준비합니다. 일시 중지, 일시 중지된 상태에서 재개, 연결 해제, 삭제가 가능합니다. 일시 중지하면 실행기는 온라인 상태로 남지만 명령 수락을 멈춥니다. 연결을 해제하면 클라이언트 인증서와 대기 중인 모든 후보 핸들이 무효화되며, 되돌릴 수 없습니다. 연결이 해제된 실행기는 새 실행기로 다시 페어링해야 합니다. 삭제도 같은 효과가 있으며, 추가로 목록에서도 제거합니다. 연결 해제와 달리 삭제는 실행기 상태와 관계없이, 페어링 대기 중이거나 이미 연결이 해제된 경우에도 제공됩니다. 목록에서 제거할 수 있는 유일한 방법이기 때문입니다. 드레이닝(draining), 즉 이미 가진 작업을 마친 뒤 새 작업을 받지 않는 상태는 프로토콜에서 실제로 존재하는 세 번째 상태이며, 인터페이스에도 표시할 수 있습니다. 그러나 여기서는 아무것도 드레이닝을 시작하지 않으며, API를 직접 호출할 때만 시작됩니다. 확인된 접근 변경, 디스크립터 검토, 수명 주기 전환은 드레이닝을 포함해 모두 데몬의 연결 에포크(epoch)를 올립니다. 그러면 데몬의 다음 제어 폴링(최대 1초 이내)이 실패하고, 다시 연결하기 전에 실행 중인 모든 게스트를 중지합니다. 취소는 머신이 무시해도 되는 요청이 아닙니다.

실행기 운영하기

정상 작동 확인하기

Nessie 자체의 판단 기준은 활성 상태 확인입니다. 데몬은 하트비트에 서명하며, 마지막 인증된 활동이 60초보다 오래된 실행기는 목록에 나타나거나, 선택되거나, 디스패치되기 전에 오프라인으로 확실히 표시됩니다. 온라인으로 보이는 실행기는 최근 1분 안에 자신이 살아 있음을 증명한 것입니다.

머신에는 상태 확인 엔드포인트가 없습니다. 데몬은 설계상 운영자용 포트를 전혀 열지 않습니다. macOS와 Linux에서는 CLI에 직접 확인하세요:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

macOS에서 상태 명령은 팀마다 launchd 에이전트를 보고합니다. systemctl 명령은 Linux 전용입니다. Windows에서는 트레이 아이콘이 한눈에 보는 답이며, 메뉴에 이유가 표시되고, 서비스 로그에 자세한 내용이 있습니다. 두 플랫폼 모두 Nessie에서 실행기의 개요 탭은 승인된 프로필, 데이터 경계, 마지막으로 확인된 시각, 검토를 기다리는 로컬 정책 제안을 보여줍니다.

로그

사람이 조치할 수 있는 모든 거부는 여기에 기록됩니다. 서명되지 않았거나 변조된 런타임, 안전하게 설정할 수 없는 상태 디렉터리, 부팅 시 시작하지 못한 실행기가 포함됩니다. 페어링 챌린지, 키, 자식 프로세스의 출력은 여기에 기록되지 않습니다. 높일 수 있는 로그 수준 설정은 없습니다. 더 자세히 기록할 내용이 없기 때문입니다.

Mac CLI는 팀마다 서비스 로그를 ~/Library/Logs/NessieExecutor/<executorId>.log에 기록합니다.

업그레이드

Homebrew, APT 또는 DNF로 CLI를 업그레이드한 다음, 팀별 서비스를 disable을 실행한 뒤 enable로 다시 시작하세요. WinGet은 Windows 실행기를 업그레이드합니다. 직접 설치하는 Nessie Desktop 설치 파일은 서명된 앱 내 업데이트를 제공하며, MSI와 Debian 설치는 패키지 관리자를 사용합니다. 페어링과 로컬 권한은 업그레이드 후에도 유지됩니다.

중지 및 제거

중지는 데몬이 직접 관리하는 정상 종료 경로이며, 강제 종료가 아닙니다. 데몬은 종료 신호를 받고, 모든 게스트 세션을 중지하고, 임대를 해제한 뒤 종료합니다. Linux에서 유닛은 10초의 정리 예산에 맞춰 15초를 기다리며, 중단할 수 없는 강제 종료(kill)로는 결코 넘어가지 않습니다. 정리 도중에 강제 종료된 데몬은 마이크로 VM과 워크스페이스 오버레이를 남겨 두는데, 이를 정리할 프로세스가 더 이상 없기 때문입니다. 그래서 멈춘 중지는 조용히 넘어가지 않고 systemctl --user status에 드러나며, 강제 종료는 사람이 명시적으로 결정해야 합니다.

Linux 패키지를 제거하려면:

nessie-executor disable <executorId>   # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger                # only if your user manager should stop running at boot too

Windows에서 msiexec /x는 서비스, 레지스트리 항목, 트레이의 시작프로그램 항목을 중지하고 제거합니다. 두 플랫폼 모두 페어링된 상태는 의도적으로 남겨 둡니다. Linux에서는 ~/.local/state/nessie-executor/, Windows에서는 %ProgramData%\Nessie Executor에 남습니다. 페어링은 머신 키와 서명된 정책 리비전이며, 프로그램을 제거한다고 이를 파기하라는 뜻은 아닙니다. 다시 설치하면 이전 위치에서 페어링을 찾습니다. 페어링을 완전히 잊으려면 해당 디렉터리를 직접 삭제하고, 반대편에서 끝내려면 Nessie에서 실행기를 취소하세요.

Windows 트레이와 데스크톱 컴패니언은 모두 이 컴퓨터의 페어링 잊기를 기본 기능으로 제공합니다. 이 기능은 로컬 데몬을 중지하고, 머신 키와 폴더 선택을 제거하며, 네이티브 확인을 한 번 거친 뒤 로컬 초안 사본을 영구 삭제합니다. 서버 쪽 실행기와 감사 기록은 소유자가 보관하거나 취소할 수 있도록 그대로 남겨 둡니다.

자주 발생하는 실패