에이전트가 실행된다는 것과, 실행 중 필요한 파일을 제대로 남길 수 있다는 것은 별개의 문제였습니다.
Jane용 Hermes를 붙이는 과정에서 이번에 다룰 부분은 실행 환경이었습니다. Hermes는 HERMES_HOME 아래에 로그와 SessionDB를 기록하는데, 샌드박스나 권한이 제한된 환경에서는 기존 홈 디렉터리를 그대로 실행 위치로 사용하기 어려울 수 있었습니다. 프로세스 자체는 시작되더라도 로그나 상태 파일을 기록하지 못할 수 있었습니다.
기존 홈 디렉터리에는 Hermes가 이미 사용하는 인증·설정 파일이 있습니다. 그렇다고 그 디렉터리 전체를 Jane의 실행 위치로 계속 사용하면, 쓰기 권한이 필요한 파일과 재사용해야 하는 설정이 한곳에 섞이게 됩니다. 필요한 것은 홈 디렉터리를 통째로 복사하는 일이 아니라, 쓸 수 있는 실행 공간과 기존 설정을 연결하는 일이었습니다.
그래서 Jane 전용 writable runtime home을 준비하는 쪽으로 바꿨습니다. _prepare_jane_hermes_runtime_home()이 전용 런타임 디렉터리를 만들고, Hermes를 실행할 때는 _hermes_subprocess_env()를 통해 해당 위치를 HERMES_HOME으로 사용하게 합니다.
다만 기존 상태를 전부 새로 만들지는 않았습니다. .env, auth.json, config.yaml, SOUL.md처럼 실행에 필요한 설정 파일만 기존 위치에서 심볼릭 링크로 연결했습니다. 로그와 상태를 기록하는 공간은 새로 분리하고, 이미 있는 로그인·설정 상태는 재사용하는 구조입니다.
이때 런타임 디렉터리 권한도 따로 지정했습니다. 전용 디렉터리는 0700으로 생성하도록 했습니다. 실행에 필요한 공간을 만들되, 그 공간의 접근 범위까지 넓힐 이유는 없었습니다. 여기서 인증 파일의 실제 내용이나 자격 증명을 복사하거나 공개하는 방식은 사용하지 않습니다.
테스트도 단순히 디렉터리가 생겼는지만 확인하지 않습니다. 런타임 홈의 권한이 0700인지, 필요한 설정 파일이 심볼릭 링크로 연결됐는지, 그리고 실행 환경을 준비하는 과정에서 logs, cache, state.db가 의도하지 않게 만들어지지 않는지를 검증합니다. 무엇을 만들어야 하는지뿐 아니라 무엇을 만들면 안 되는지도 함께 확인합니다.
이번 수정은 Hermes를 더 많은 기능으로 확장한 작업이 아니었습니다. 실행 위치를 분리하고, 쓰기가 필요한 부분과 재사용할 설정을 나누는 작업에 가까웠습니다. 제한된 환경에서 모든 권한 문제를 없앴다고 말할 수는 없지만, 적어도 Jane의 Hermes가 어디에 기록하고 어떤 설정을 가져다 쓰는지는 코드와 테스트로 구분할 수 있게 됐습니다.
다만 파일 시스템의 쓰기 위치를 정리해도 후보 생성 요청 자체가 항상 끝까지 진행되는 것은 아닙니다. 다음 편에서는 실행 환경이 아니라, 긴 history와 context 때문에 생길 수 있는 timeout을 다룹니다. 무작정 반복하지 않고 한 번만 요청을 줄여 재시도하는 방식입니다.