# Codex에서 서버의 Hermes로 프로젝트 옮기기 > Hermes에서 작업하기 위해 저장된 변경 사항, 종속성, 비밀 정보, 작업 폴더 및 개발을 재개하기 전의 확인 사항과 함께 저장소를 서버로 이전하는 방법. Source: https://ailoot.ai/blog/ko/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/ko/codex-project-to-hermes-server/ Language: ko Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-5f3680656773c797b721bffee67f5ff73de8000a386bdfcc7acc7b3d7af83224 서비스 사용에 대한 도움말은 [Ailoot 문서](https://ailoot.ai/docs/)를 참조하세요.
핵심 내용 Codex로 만든 프로젝트를 Hermes에서 계속 작업하려면 저장소 자체를 이전하고 환경을 복원하세요. 이 방법에는 별도로 “에이전트에서 프로젝트 가져오기” 단계가 필요하지 않습니다. 먼저 저장된 파일과 종속성을 확인한 다음 Hermes에서 올바른 폴더를 여세요. 이 가이드는 서버와 Hermes가 이미 설정되어 있고 저장소에 접근할 수 있다고 가정합니다.
## 이전 전에 준비할 사항 저장소는 Git 변경 이력이 포함된 프로젝트 폴더입니다. 작업 사본에는 편집하는 파일이 들어 있습니다. 여기서는 해당 사본을 서버로 옮겨 개발을 계속하면 됩니다. 아직 방문자에게 애플리케이션을 공개할 필요는 없습니다. 서버에 에이전트가 아직 설치되지 않았다면 [VPS에 Hermes Agent 설치하기](https://ailoot.ai/blog/ko/hermes-agent-vps-24-7/)부터 시작하세요. 여기서는 정상 작동하는 Hermes 설치본, 서버 터미널, Git이 필요합니다. 서버에서 접근할 수 있는 원격 저장소도 필요합니다. 아직 없다면 먼저 저장소를 만들고 비밀 정보 없이 프로젝트를 저장하세요. 비공개 저장소라면 미리 본인 계정으로 읽기 권한을 설정하세요. 저장소 URL이나 에이전트에게 보내는 메시지에 토큰을 넣지 마세요. 이전하는 동안 프로젝트에 대한 병렬 편집을 중단하세요. 원본 컴퓨터에서 프로젝트 폴더 자체를 대상으로 터미널을 열고 다음을 실행하세요. ```bash git status --short --branch git status --short --ignored ``` 첫 번째 명령은 브랜치와 파일 상태를 보여줍니다. `M`은 수정된 파일, `??`는 아직 Git이 추적하지 않는 파일을 뜻합니다. 두 번째 명령에서는 무시된 파일에 `!!` 표시가 붙습니다. 상태가 깨끗하게 표시된다고 해서 Git 외부에 필요한 파일이 없다는 뜻은 아닙니다. 필요한 변경 사항을 별도의 커밋으로 저장하고, 평소 방식대로 올바른 브랜치를 원격 저장소에 푸시하세요. 푸시하기 전에 커밋에 무엇이 포함되는지 확인하세요. 키, 비밀번호, 실제 사용자 데이터가 포함되어서는 안 됩니다. 어떤 변경 사항을 저장해야 할지 모르겠다면 먼저 Codex에게 변경 사항을 나열하고 목적을 설명해 달라고 하세요. 파일을 삭제하거나 저장소에 푸시하지는 마세요. | 프로젝트 구성 요소 | 이전 전에 확인할 사항 | |----|----| | 소스 파일 및 Git 이력 | 필요한 변경 사항이 저장되어 선택한 원격 저장소 브랜치에서 접근 가능한가 | | README 및 에이전트 지침 | 시작 방법, 확인 절차, 제한 사항이 문서화되어 있고 지침이 최신 상태인가 | | 종속성 파일 | 종속성을 정의하는 파일과 프로젝트에서 사용하는 잠금 파일(버전을 고정하는 파일)이 저장되어 있는가 | | 비밀 정보 | 서버에 안전하게 설정할 별도 방법이 있는가. 값이 Git에 들어 있거나 채팅으로 전송되지 않았는가 | | 데이터베이스 및 업로드 파일 | 허용된 테스트 데이터를 어디서 구하고 프로젝트 지침에 따라 어떻게 복원할지 알고 있는가 | 저장소를 복제한다고 해서 외부 데이터베이스, 무시된 폴더의 내용 또는 Codex와의 대화가 이전된다고 생각하지 마세요. 채팅 기록, 구독, 프로필, 에이전트 자체 설정은 이 이전 방법에 포함되지 않습니다. ## 올바른 브랜치를 서버에 복사하기 먼저 원본 컴퓨터에서 다음 명령의 출력을 저장하세요. ```bash git status --porcelain=v2 --branch ``` `# branch.oid` 행에는 현재 커밋이, `# branch.head` 행에는 브랜치가 표시됩니다. 커밋은 프로젝트의 저장된 버전입니다. 기존 커밋이 있는 일반적인 프로젝트라면 원본 사본과 새 사본을 비교할 수 있습니다. 이 비교로 커밋되지 않은 변경 사항까지 확인할 수 있는 것은 아닙니다. 서버에서 프로젝트를 보관할 디렉터리로 이동하세요. 새 폴더에 저장소를 복제합니다. 아래 템플릿에서 `REPOSITORY_URL`은 저장소 URL로, `BRANCH_NAME`은 저장하고 푸시한 브랜치 이름으로, `my-project`는 새 폴더에 사용할 이름으로 바꾸세요. ```bash git clone --branch BRANCH_NAME REPOSITORY_URL my-project cd my-project git status --porcelain=v2 --branch ``` 이것은 복사해서 바로 사용할 수 있는 URL이 아니라 템플릿입니다. `git clone`은 폴더를 만들고 선택한 브랜치의 작업 사본을 생성합니다. 대상 폴더가 이미 있다면 비어 있어야 합니다. 명령을 다시 실행하기 위해 폴더 내용을 삭제하지 말고 새 이름을 선택하세요. 두 사본의 `# branch.oid`를 비교하세요. 값이 다르면 서버에서 코드를 수정하기 시작하지 마세요. 선택한 브랜치, 푸시한 커밋, 병렬 변경이 있었는지 확인하세요. 상태 출력에 수정된 파일이 있으면 각각 따로 조사하세요. 정리 명령이나 강제 초기화로 “일치시키려” 하지 마세요. Git 서브모듈, 즉 중첩된 저장소가 있는 경우 해당 콘텐츠도 가져와야 합니다. `git clone`에는 `--recurse-submodules` 옵션이 있습니다. 프로젝트에 실제로 서브모듈이 있고 해당 URL을 확인했다면 이 옵션을 사용하세요. 다른 외부 리소스를 사용하는 프로젝트는 README에 설명된 추가 절차가 필요할 수 있습니다. ## 프로젝트 규칙에 따라 종속성 복원하기 먼저 README와 프로젝트 설정 파일을 읽으세요. 필요한 런타임 버전과 종속성 설치에 사용하는 패키지 관리자를 확인하세요. 아래 예시에 npm이 나온다고 해서 프로젝트에서 평소 사용하는 도구를 npm으로 바꾸지 마세요. **Node.js와 npm을 사용하는 가상 예시:** 저장소에 서로 일관된 `package.json`과 `package-lock.json` 파일이 있고, 서버에 프로젝트에 적합한 버전의 Node.js가 설치되어 있습니다. 이 경우 프로젝트 폴더에서 다음을 실행하세요. ```bash npm ci ``` [npm ci 문서](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md)에 따르면 이 명령은 `package.json`이나 `package-lock.json`을 다시 쓰지 않고 잠금 파일을 사용해 프로젝트 전체의 종속성을 설치합니다. 두 파일의 내용이 서로 일치하지 않으면 설치에 실패합니다. 설치 전에 기존 `node_modules` 폴더는 삭제됩니다. `--legacy-peer-deps`처럼 종속성 트리에 영향을 주는 옵션을 사용해 잠금 파일을 만들었다면 `npm ci`에도 같은 옵션이 필요합니다. 원본 프로젝트의 지침과 설정을 확인하세요. 첫 이전 오류를 감추려고 잠금 파일을 삭제하거나 모든 종속성을 업데이트하지 마세요. 설치하기 전에 프로젝트의 설치 및 시작 명령을 확인하세요. 프로덕션 데이터에 접근할 수 없는 별도의 작업 사본에서 명령을 실행하고, 필요한 환경 값은 채팅이나 Git 외부에서 설정하세요. 가능하다면 권한이 제한된 테스트 자격 증명을 사용해 프로젝트를 확인하세요. 프로젝트가 데이터베이스나 파일에 의존한다면 먼저 지침에 따라 허용된 테스트 데이터 세트를 복원하세요. 소스 파일이 같아도 해당 데이터를 대신할 수는 없습니다. 설치한 뒤 README에 있는 기존 확인 절차를 실행하세요. 제공되는 경우 테스트와 빌드를 실행합니다. 명령 이름은 프로젝트마다 다릅니다. 종속성이 성공적으로 설치되었다고 해서 애플리케이션이 작동한다는 뜻은 아닙니다. ## Hermes에서 작업 사본 열기 서버 터미널에서 새 사본의 루트로 이동해 이미 설치된 에이전트를 시작하세요. ```bash cd /absolute/path/to/my-project hermes ``` 여기서 `/absolute/path/to/my-project`는 프로젝트의 전체 경로를 나타내는 자리 표시자입니다. Hermes 시작 화면에서 작업 디렉터리와 터미널 명령이 실행되는 환경을 확인하세요. 이 시작 방법은 서버의 Hermes 로컬 터미널 환경을 위한 것입니다. SSH나 Docker가 설정되어 있다면 에이전트가 다른 환경에서 명령을 실행할 수 있으므로, 먼저 해당 환경에서 프로젝트 경로에 접근할 수 있는지 확인하세요. 에이전트의 터미널 도구를 사용해 실제 작업 폴더를 확인해 달라고 한 다음 README와 프로젝트 지침을 읽도록 하세요. 메시지에 폴더 이름이 적혀 있는 것만으로는 확인이 충분하지 않습니다. 아래에 설명된 순서는 고정된 특정 문서 버전에 따른 것이며 설치된 Hermes 버전에서는 다를 수 있습니다. 세션에서 최신 지침을 확인하세요. Hermes는 `AGENTS.md`를 지원하지만 해당 파일을 읽는지는 컨텍스트 파일의 우선순위에 따라 달라집니다. [공식 Hermes 문서](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md)에 따르면 다음 순서로 파일 유형 하나를 선택합니다. `.hermes.md`, `AGENTS.override.md`, `AGENTS.md`, `CLAUDE.md`, `.cursorrules`. 작업을 시작하기 전에 오래된 `.hermes.md`나 개인용 `AGENTS.override.md`가 있는지 확인하세요. 에이전트가 그 파일과 함께 `AGENTS.md`도 반드시 적용한다고 가정하지 마세요. 선택된 지침에는 프로젝트의 목적, 확인 명령, 변경 제한을 유지하세요. 지침을 대화 기록 보관소로 만들지 마세요. 에이전트 설정 자체도 이전해야 한다면 이는 별도의 절차이며, [Claude Code에서 Codex로 마이그레이션하는 가이드](https://ailoot.ai/blog/ko/migrate-claude-code-to-codex/)에 범위가 설명되어 있습니다. ## 에이전트에게 하나의 작업을 맡기고 결과 확인하기 변경하지 말고 프로젝트를 읽는 것부터 시작하세요. 예를 들면 다음과 같습니다. ``` 지정한 폴더에 있는 기존 프로젝트를 작업합니다. 터미널 도구를 사용해 실제 작업 디렉터리를 확인하세요. README와 현재 프로젝트 지침을 읽으세요. 비밀 정보가 들어 있는 파일을 열거나 환경 변수 값을 출력하지 마세요. 확인 명령과 실행에 필요한 전제 조건을 나열하세요. 지금은 아무것도 변경하거나 설치하지 말고 저장소에 푸시하지 마세요. ``` 그런 다음 인터페이스의 텍스트 수정처럼 작은 작업 하나를 합의하세요. 변경할 파일이나 영역을 지정하고, 부수적인 종속성 업데이트를 금지하세요. 실험을 기본 사본과 분리하고 싶다면 먼저 [별도의 Git worktree 작업 사본](https://ailoot.ai/blog/ko/codex-worktree-separate-task/)에 대해 알아보세요. 파일 변경 사항과 프로젝트 확인 절차를 반복 실행한 결과를 바탕으로 결과를 검토하세요. 실패할 수 있는 실험을 하기 전에 원본 사본과 복구 지점을 저장하세요. 모든 변경 사항을 한꺼번에 초기화하도록 에이전트에게 요청하지 마세요. 확인 절차가 실패하면 오류를 원본 사본과 비교하세요. 이를 통해 이전 과정의 문제인지 이미 있던 결함인지 구분하는 데 도움이 됩니다. 필요한 버전의 소스 파일이 준비되고, 환경이 복원되며, 필요한 데이터가 안전한 테스트 환경에서 사용 가능하고, 확인 절차가 통과하며, Hermes가 바로 이 폴더에서 작동할 때 이전이 완료된 것으로 볼 수 있습니다. 방문자에게 애플리케이션을 공개하는 것은 별도의 다음 단계이며 이 확인에는 포함되지 않습니다. [Ailoot](https://ailoot.ai/)을 알아보세요. ## Codex에서 서버의 Hermes로 프로젝트 옮기기: 자주 묻는 질문 ### 저장소를 복제하면 작업 환경 전체가 이전되나요? 아닙니다. Git 복제로는 무시된 파일, 외부 데이터베이스, 업로드된 데이터, 비밀 정보, 에이전트 대화 기록이 옮겨지지 않습니다. 프로젝트 지침에 따라 필요한 의존성과 허용된 테스트 데이터를 별도로 복원하세요. ### 서버 복사본을 수정하기 전에 무엇을 비교해야 하나요? 저장한 브랜치와 커밋 식별자를 원본과 비교하고 커밋되지 않은 변경을 확인하세요. Hermes가 실제 작업 디렉터리를 확인하게 한 뒤 그 정확한 복사본에서 프로젝트의 기존 검사를 실행하세요. ## Ailoot · 회사와 그 프로젝트 포트폴리오 Ailoot는 축적된 운영 경험, 폭넓은 고객 기반, 안정적인 서비스, 지속적인 KPI 관리를 바탕으로 합니다. 회사와 그 프로젝트 포트폴리오: 수백만 고객, 매월 수십억 규모의 매출. Ailoot는 이러한 운영 경험을 고객의 제품, 에이전트, 애플리케이션, 자동화에서 AI 기능을 이용할 수 있는 API 접근에 활용합니다.