Hermes 에이전트가 프롬프트 가이드를 읽고 직접 웹 검색+요약까지 하던 고객사 뉴스 리포트 워크플로우를, 결정론적인 파이썬 파이프라인으로 옮기는 작업을 했다. 검색·크롤링·요약·표 조립까지 다 만들고 실제로 한 번 돌려봤다.
권한 오류로 멈췄다
리포트를 저장하려는 순간 PermissionError: [Errno 13] Permission denied: '/opt/data'가 떴다. 저장 경로는 원래 Hermes 프롬프트 가이드에 적혀
있던 /opt/data/workspace/news/를 YAML 설정에 그대로 옮겨온 것이었다.
확인해보니 /opt 자체가 root 소유였고, /opt/data는 아예 존재하지도
않았다. 지금 계정으로는 애초에 그 경로 밑에 폴더를 만들 권한이 없었다.
왜 처음부터 이 경로가 적혀 있었을까
원래 프롬프트 가이드는 Hermes가 실제로 잘 쓰고 있던 저장 경로였다. 그러니 최소한 Hermes 입장에서는 이 경로가 유효했을 텐데, 지금 이 파이썬 파이프라인은 같은 계정으로 호스트에서 직접 도는데도 안 됐다.
일단 홈 디렉토리 밑으로 옮기면 되겠다 싶어서, Hermes 가이드 md
파일들이 모여 있는 ~/hermes-workspace/로 바꿔봤다. 근데 이것도
아니었다 — docker inspect로 Hermes 컨테이너를 직접 열어보고 나서야
진짜 마운트 경로를 확인할 수 있었다. 컨테이너 설정엔 호스트의
/home/decipher/hermes-data가 컨테이너 안의 /opt/data로 연결되어
있다고 적혀 있었다. ~/hermes-workspace/는 가이드 문서들이 있는
완전히 다른 디렉토리였고, 컨테이너 안의 /opt/data와는 아무 관계도
없었다.
즉 Hermes 입장에서 /opt/data가 멀쩡했던 이유는 Docker가
~/hermes-data라는 전혀 다른 이름의 호스트 디렉토리를 그 안으로
연결해줬기 때문이고, 이 새 파이썬 파이프라인은 그 컨테이너 밖에서
직접 도니까 /opt/data라는 경로 자체가 아무 의미도 없었던 것이다.
프롬프트 가이드를 그대로 옮기면서 생긴 일
이 저장 경로는 원래 프롬프트 텍스트에 적힌 값을 그대로 YAML 설정으로 옮긴 거였다. 그 값이 “왜” 유효했는지(컨테이너 안에서 실행되고, 그 안에서만 보이는 마운트 경로라서)는 확인하지 않고, “지금 잘 동작하고 있다”는 사실만 보고 그대로 가져온 셈이다. 같은 값이라도 실행되는 환경이 바뀌면 그 값의 근거 자체가 사라질 수 있는데, 그 근거를 확인하지 않은 채 값만 복사한 것이다.
비슷한 시기에 만든 다른 파이프라인(news_automation)은 애초에 이런
문제가 없었다 — 처음부터 /opt가 아니라 홈 디렉토리 밑에 저장하도록
되어 있었기 때문이다. 이번 프로젝트만 Hermes 프롬프트 가이드에 적힌
경로를 그대로 가져오면서 이 문제를 새로 만든 셈이다.
고치는 방법은 간단했다 — 호스트에서 실제로 쓰기 가능한 경로
(~/hermes-data/workspace/customer-news/)로 바꾸면, 컨테이너 안에서는
여전히 /opt/data/workspace/customer-news/로 보이니 Hermes가 그 경로를
계속 참조해야 할 일이 생겨도 문제없다.
배운 점
다른 시스템(다른 에이전트, 다른 프롬프트, 다른 설정)에서 잘 동작하던 값을 그대로 가져올 때는, 그 값 자체가 아니라 “이 값이 왜 유효한가”까지 같이 옮겨야 한다. 이번 경우엔 그 근거가 “Docker 컨테이너 안에서 실행된다”는, 값 자체엔 안 적혀 있는 실행 환경 조건이었다. 값만 보고 베끼면 그 조건이 깨지는 순간까지는 아무 문제가 없어 보이다가, 실행 환경이 바뀌는 순간 조용히 깨진다.