AI 에이전트에게 서버 작업을 맡길 때 확인해야 할 것들

요약

AI 에이전트가 코드를 수정하는 시대를 지나, 이제는 서버 상태를 확인하고 배포까지 처리하는 흐름이 가능해졌습니다. 하지만 서버 작업은 단순 코드 수정보다 위험합니다. 경로를 착각하면 엉뚱한 프로젝트를 덮어쓸 수 있고, 포트를 잘못 보면 다른 서비스가 정상인 것처럼 판단할 수 있습니다.

Futory를 운영하면서 가장 중요하게 본 기준은 “내가 지금 컨테이너 안에 있는지, 호스트 서버를 보고 있는지”를 구분하는 것입니다. 특히 Docker 안에서 Hermes Agent를 실행하는 경우 /opt/wordblog와 /opt/data/wordblog_next_staging은 의미가 다릅니다.

서버 작업에서 먼저 확인할 것

AI에게 서버 작업을 맡기기 전에는 현재 환경부터 확인해야 합니다. 예를 들어 컨테이너 내부인지, Docker socket이 있는지, 호스트 경로에 접근 가능한지, PM2가 어느 네임스페이스에서 실행 중인지 확인해야 합니다.

실제로는 다음 항목을 먼저 봅니다.

• 현재 작업 경로
• 컨테이너 여부
• 호스트 마운트 경로
• Docker socket 접근 여부
• PM2 프로세스 목록
• Nginx 프록시 포트
• 공개 도메인의 응답 상태

이 과정을 생략하면 “빌드는 됐는데 실제 사이트는 옛날 화면” 같은 일이 생깁니다.

배포와 검증은 분리해야 한다

배포 명령이 성공했다고 해서 사용자가 보는 화면이 바뀐 것은 아닙니다. Next.js 앱이라면 빌드, PM2 재시작, 내부 포트 확인, Nginx vhost 확인, HTTPS 공개 URL 확인이 각각 필요합니다.

Futory에서는 내부 서비스 포트가 8042입니다. 반면 다른 블로그 서비스가 8041을 사용하고 있었습니다. 이 차이를 모르면 잘못된 포트를 확인하고도 정상이라고 착각할 수 있습니다. AI 에이전트에게 서버 작업을 맡길 때는 이런 숫자 하나가 매우 중요합니다.

위험한 작업은 작게 나눈다

AI가 서버에서 파일을 동기화할 때는 node_modules, .next, .env 같은 폴더를 어떻게 처리할지 정해야 합니다. 특히 .env는 덮어쓰면 안 되는 경우가 많습니다. 그래서 배포 스크립트는 보통 소스 코드만 동기화하고, 의존성 설치와 빌드는 서버에서 다시 실행하는 방식이 안전합니다.

작업을 작게 나누면 문제가 생겨도 원인을 찾기 쉽습니다. 파일 동기화, 의존성 설치, 콘텐츠 검증, 빌드, PM2 재시작, URL 확인을 한 번에 뭉뚱그리지 않는 것이 좋습니다.

사람이 봐야 하는 지점

서버 자동화에서 사람은 모든 명령을 직접 칠 필요는 없지만, 위험한 결정은 확인해야 합니다. 예를 들어 데이터베이스 초기화, 기존 파일 삭제, 인증서 재발급, 방화벽 수정은 자동으로 진행하기 전에 범위를 확인하는 것이 안전합니다.

반대로 단순한 문구 변경, 글 추가, 빌드 확인, PM2 재시작처럼 범위가 명확한 작업은 AI에게 맡겨도 됩니다. 중요한 것은 작업의 위험도를 구분하는 것입니다.

자주 묻는 질문

Q. AI 에이전트에게 서버 배포를 맡겨도 안전한가요?

범위가 명확하고 검증 절차가 있으면 충분히 가능합니다. 다만 데이터 삭제나 보안 설정 변경은 별도 확인이 필요합니다.

Q. 컨테이너 안에서 호스트 서버를 제어할 수 있나요?

Docker socket이나 적절한 bind mount가 있으면 가능합니다. 하지만 컨테이너 경로와 호스트 경로를 반드시 구분해야 합니다.

Q. 배포 후 가장 먼저 확인할 것은 무엇인가요?

빌드 성공보다 공개 URL 응답을 확인해야 합니다. 사용자가 보는 것은 빌드 로그가 아니라 실제 사이트이기 때문입니다.

결론

AI 에이전트는 서버 작업을 빠르게 처리할 수 있지만, 환경 확인과 검증이 빠지면 위험합니다. Futory에서는 모든 서버 작업을 “환경 확인, 실행, 검증, 보고”의 순서로 기록하면서 자동화할 계획입니다.