모범 사례 — 10가지 팁 | Easy Understand Hermes Agent

Hermes Agent를 바쁜 주방의 셰프라고 생각해 보세요. 모든 요리사가 같은 도마에서 채소를 썰면서 동시에 디저트 플레이팅을 하게 두지는 않을 겁니다. 각자에게 자기만의 작업 공간을 주죠. 코드베이스에도 똑같은 논리가 적용됩니다.

1. 실험 하나당 워크트리 하나

집에 페인트를 칠한다고 상상해 보세요. 거실과 욕실을 같은 붓으로 동시에 칠하지는 않을 겁니다. 둘 다 망치게 되니까요. Git 워크트리를 사용하면 각 Hermes 작업에 전용 “방”을 따로 줄 수 있습니다.

Hermes가 메인 프로젝트 폴더의 파일을 직접 수정하게 두는 대신, 각 실험마다 별도의 작업 공간을 만드세요. 이렇게 하면 메인 코드는 안전하게 보호되고 변경 사항도 깔끔하게 유지됩니다.

브랜치에는 명확하고 설명적인 이름을 붙이세요. 그래야 지금의 당신(그리고 미래의 당신)이 각 브랜치가 무엇을 위한 것인지 알 수 있습니다:

git checkout -b feature/hermes-checkpoints-docs

branch-1이나 test-fix 같은 이름은 쓰지 마세요. 구체적으로! 나중에 분명히 고마워하게 될 겁니다.

커밋은 게임에서 세이브 포인트를 찍는 것과 같습니다. 3시간을 플레이하고 세이브를 안 해서 모든 걸 잃고 싶지는 않잖아요.

큰 단위의 마일스톤에서 커밋하세요:

git add .
git commit -m "Add checkpoint documentation"

그 사이에 있는 작은 도구 기반 변경 사항은 Hermes의 체크포인트와 /rollback을 안전망으로 활용하세요.

워크트리를 사용할 때는 원본 리포 폴더에서 Hermes를 실행하지 마세요. 대신 워크트리 디렉토리로 cd 한 후 실행하세요. 이렇게 하면 각 에이전트의 작업 범위가 명확해지고 의도치 않은 상호 오염을 방지할 수 있습니다.

워크트리를 매번 수동으로 설정하고 싶지 않나요? Hermes에는 내장된 단축키가 있습니다:

cd /path/to/your/repo
hermes -w

이 명령은 자체 브랜치를 가진 일회용 워크트리를 자동으로 생성합니다. 단일 쿼리와 결합할 수도 있습니다:

hermes -w -z "Fix issue #123"

여러 Hermes 에이전트를 동시에 실행하고 싶나요? 그냥 터미널을 여러 개 열고 각각에서 hermes -w를 실행하세요. 각 세션은 자동으로 격리된 워크트리와 브랜치를 갖게 됩니다. 더 이상 에이전트들이 서로 발을 밟지 않습니다.

실수는 누구에게나 있습니다. 괜찮아요. Hermes는 세션 중에 체크포인트를 만들고 문제가 생기면 그 지점으로 롤백할 수 있게 해줍니다. 에이전트의 작업에 대한 “실행 취소” 버튼이 있는 것과 같습니다.

승리 공식은 다음과 같습니다:

이것들을 함께 사용하면 빠른 반복, 쉬운 복구, 깔끔한 풀 리퀘스트를 얻을 수 있습니다.

여러 워크트리에서 TUI나 데스크톱 앱을 작업한다면 각각에 node_modules가 필요합니다. 파일이 많이 중복되죠. 심볼릭 링크로 하나의 설치를 공유하는 htui / hgui 헬퍼를 확인해 보세요. 디스크 공간과 설정 시간을 절약할 수 있습니다.

이 모든 관행의 핵심은 메인 브랜치를 안정적이고 프로덕션 배포 가능한 상태로 유지하는 것입니다. 워크트리 브랜치는 테스트가 끝나고 완성되었을 때만 병합하세요.

워크트리를 사무실의 개별 책상이라고 생각해 보세요. 각 Hermes 에이전트는 자신만의 도구를 가진 자신만의 책상을 갖게 되어, 아무도 다른 사람의 작업을 망치지 않습니다. 브랜치는 파일 정리 시스템이고, 체크포인트는 “내가 여기 있었다”는 메모지입니다.

실용적인 팁: 다음 작업부터 hermes -w만 사용해 보세요. 수동 설정 없이 격리 환경을 얻을 수 있는 가장 쉬운 방법입니다. 익숙해지면 체크포인트와 롤백을 워크플로우에 추가해 보세요. 이게 없이 어떻게 일했는지 의아해질 겁니다.