AI 비서에게 배포 한번 통째로 맡겨봤습니다! (개발자가 하던 방식이랑 비교해보기)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 비서에게 배포를 통째로 맡기면 명령 실행과 오류 수정의 부담은 줄지만, 권한 분리와 기술 선택, 자격 증명, HTTPS까지 사람이 검토해야 안전한 배포가 완성된다.

📌 핵심 요점

1. Hermes Agent를 이용한 배포는 대화와 대시보드 중심으로 진행되며, 소스 내려받기부터 오류 수정과 재실행까지 상당 부분을 위임할 수 있다.
2. AI가 서버 내부 상태를 직접 볼 수 있으면 디스크·CPU·메모리 문제를 진단하고 필요한 명령을 제시할 수 있어, 외부에서 조언만 제공하는 AI보다 구체적인 대응이 가능하다.
3. sudo가 필요한 호스트 작업은 사용자가 직접 처리하고, 비권한 명령과 소스 오류 수정은 Hermes에 맡기는 방식으로 사람과 AI의 역할을 나눠야 한다.
4. 비공개 GitHub 저장소 토큰과 데이터베이스 비밀번호를 채팅으로 전달하면 노출 위험이 남으므로, 최소 권한·짧은 만료 기간·작업 후 폐기 원칙이 필요하다.
5. AWS EC2 수동 배포는 서버 사양, 런타임, MySQL·Redis, 환경변수, 빌드와 프로세스 상태를 직접 관리해야 하며, AI 배포가 줄여주는 시행착오와 사람이 계속 책임져야 할 지점을 함께 보여준다.

🧩 배경과 문제 정의

• 개발한 서비스를 불특정 다수가 이용하려면 서버 배포, 외부 접속 경로, HTTPS 연결까지 구성해야 한다.
• AI 에이전트는 명령 실행과 오류 수정을 대신할 수 있지만, 권한이 필요한 작업과 잘못된 기술 선택은 사용자가 직접 점검해야 한다.
• AI 비서 중심 배포와 AWS 터미널 중심 배포를 비교하면 자동화의 편의성뿐 아니라 보안·인프라 지식이 필요한 지점도 드러난다.

🕒 시간순 섹션별 상세정리

1. AI 비서 배포와 수동 배포의 비교

• 배포는 로컬에서 만든 서비스를 외부 사용자가 접속할 수 있게 공개하고, 최종적으로 HTTPS 보안 연결까지 적용하는 과정이다. [00:50]
• AI 에이전트에 작업을 맡기는 방식은 클릭과 대화로 진행할 수 있지만 시행착오가 많고, 백엔드 개발자의 터미널 방식은 명령을 직접 이해하고 실행해야 한다. [00:55]

2. Hermes 서버와 호스팅 상품 선택

• Hermes Agent는 배포 대상 서버에 함께 설치해야 하며, 초보자가 접근하기 쉬운 AI 비서라는 이유로 OpenClaw 대신 선택됐다. [01:00]
• KVM2 상품은 CPU 2개, 메모리 8GB, 디스크 100GB를 제공해 개인 서비스와 Hermes를 함께 운영할 수 있는 사양이다. [02:14]

3. 서버 장애를 다루는 호스팅 관리 AI

• 디스크·CPU·메모리 사용률이 100%에 도달하면 비전문가가 원인을 찾기 어렵지만, 서버 내부를 볼 수 있는 관리 AI는 문제와 실행할 명령을 구체적으로 찾아낼 수 있다. [03:14]
• 외부 ChatGPT는 서버 상태를 직접 확인하지 못하는 반면 호스팅 관리 AI는 내부 상태에 맞는 명령을 생성하므로 진단 정확도에서 차이가 난다. [04:24]

4. VPS 대시보드와 Hermes 컨테이너 접근

• 구매한 VPS에는 Hermes Agent가 미리 설치돼 있으며, 웹 콘솔에서는 Linux 터미널을 열고 Open App에서는 AI 비서 대시보드로 바로 들어갈 수 있다. [04:56]
• Hermes가 Docker 컨테이너 안에서 실행되므로 docker ps로 컨테이너 이름을 확인한 뒤 docker exec -it 방식으로 내부 셸에 진입해야 한다. [05:52]

5. OpenAI 인증과 작업별 모델 선택

• OpenRouter의 무료 모델을 포함해 여러 모델을 연결할 수 있으며, 비용과 작업 난도를 기준으로 기본 모델을 선택할 수 있다. [07:27]
• OpenAI 구독 인증은 로그인 후 발급된 코드를 터미널에 붙여 넣는 방식으로 완료된다. [07:58]

6. Telegram 연결 실패와 수동 설정

• Hermes 대화 채널은 Telegram·Discord·Slack·이메일 등으로 구성할 수 있고, Telegram은 QR 코드로 봇을 만드는 빠른 설정을 지원한다. [08:53]
• 빠른 설정에서 봇 토큰이 구성되지 않자 BotFather로 이름과 bot으로 끝나는 아이디를 지정하고 토큰을 직접 발급하는 방식으로 전환했다. [09:41]

7. GitHub 소스와 배포 요청 구성

• Hermes가 코드를 내려받아 설치하려면 GitHub 같은 원격 저장소에 소스가 먼저 올라가 있어야 한다. [11:42]
• 저장소 URL과 함께 서버 배포를 요청하면서 실행한 명령과 의미도 출력하도록 지시하면, 자동화 결과를 검토하고 배포 절차를 학습할 수 있다. [12:05]

8. 비공개 저장소 토큰과 보안 범위

• 비공개 저장소는 익명 접근을 거부하므로 Hermes 전용 GitHub 토큰을 발급해야 하며, 만료 기간이 길수록 편리하지만 탈취됐을 때의 위험도 커진다. [12:48]
• 토큰은 필요한 저장소만 선택하고 Contents 권한을 부여해야 하며, 향후 코드 수정까지 맡기려면 쓰기 권한도 필요하다. [13:40]

9. 권한 한계와 잘못된 기술 선택 감시

• Hermes 컨테이너에 sudo 권한이 없으면 운영체제 수준의 데이터베이스·Redis 설치는 중단되고, 사용자가 호스트 터미널에서 필요한 명령을 대신 실행해야 한다. [14:58]
• AI가 MySQL 요구사항을 MariaDB 설치로 임의 변경할 수 있으므로, 낯선 명령이라도 제품명·버전·설치 대상을 확인하지 않으면 다른 기술 스택이 들어갈 수 있다. [15:30]

10. MySQL·Redis 설치와 정상 상태 확인

• MySQL 8.4와 Redis 7을 Docker로 설치할 때 비밀번호 자리표시자는 그대로 사용하지 않고 강력한 사용자 값으로 교체해야 한다. [16:19]
• 호스트 권한이 필요한 명령은 Hermes 컨테이너에서 빠져나온 뒤 실행하며, 설치 후 docker ps에서 Hermes 외에 MySQL과 Redis 컨테이너가 추가된 상태를 확인한다. [16:43]

11. 비권한 작업 위임과 소스 오류 수정

• sudo가 없는 명령은 사용자가 직접 실행할 필요가 없으므로 Hermes에 다시 맡기고, 권한이 필요한 작업만 사람이 처리하는 방식으로 역할을 나눈다. [17:56]
• 데이터베이스 비밀번호와 애플리케이션 비밀 키는 임의 기본값을 피하고 사용자 값으로 바꿔야 하며, 키 생성 자체는 Hermes에 위임할 수 있다. [18:24]

12. 배포 결과 검토와 비밀값 노출 위험

• 소스 오류가 해결된 뒤 네트워크 문제까지 이어서 처리되며, 사용자는 진행 상태와 직접 입력해야 하는 권한 명령만 구분하면 된다. [19:23]
• 배포 후에도 외부 접속이 되지 않으면 해당 상태를 다시 전달해 후속 작업을 요청하고, 실행 명령 목록으로 변경 내용을 확인할 수 있다. [20:14]

13. IP·포트 임시 공개와 즉시 수정

• 정식 운영 주소는 도메인과 HTTPS를 사용해야 하지만, 첫 단계에서는 서버 IP와 3000번 포트로 서비스를 임시 공개해 외부 접속부터 검증한다. [21:21]
• Hermes가 직접 처리하지 못한 호스트 명령을 실행한 뒤 확인된 IP 주소에 3000번 포트를 붙이면 배포된 서비스 화면에 접속할 수 있다. [22:12]

14. AWS EC2 서버 직접 구성

• 수동 비교 과정에서는 AWS EC2에서 Ubuntu 인스턴스를 만들고, 무료 사용 여부와 서버 사양을 사용자가 직접 선택해야 한다. [23:18]
• 애플리케이션 설치에는 메모리 2GB가 필요해 T3 Micro 대신 CPU 2개와 메모리 2GB를 제공하는 T3 Small을 선택한다. [25:00]

15. Linux 런타임 설치와 MySQL 보안 설정

• EC2 터미널에서 관리자 셸로 전환하고 Volta를 설치한 뒤 세션을 다시 연결해야 Node.js 26을 설치할 수 있다. [26:32]
• Ubuntu 패키지 명령으로 MySQL Server를 설치하면 8.4가 적용되며, 루트 인증 방식은 이전 mysql_native_password 대신 caching_sha2_password를 사용해야 한다. [27:24]

16. Redis 설치와 정상 작동 확인

• Redis 공식 설치 명령은 터미널의 우클릭 붙여넣기로 입력해야 하며, Ctrl+C나 Ctrl+V를 사용하면 특수문자가 들어가 명령이 꼬일 수 있다. [30:12]
• 설치 도중 확인 요청에 Y를 입력한 뒤 sudo systemctl status redis-server에서 active 상태가 나타나면 Redis가 정상적으로 실행 중이다. [30:43]

17. GitHub 토큰을 이용한 비공개 저장소 인증

• 비공개 저장소를 복제할 때 GitHub 계정 비밀번호는 사용할 수 없으므로, 2차 인증을 거쳐 Fine-grained Personal Access Token을 발급해야 한다. [31:14]
• 만료되지 않는 토큰은 편리하지만 탈취 시 장기간 악용될 수 있어, 30일 만료와 특정 저장소의 콘텐츠 쓰기 권한만 부여하는 방식이 보안 위험을 줄인다. [32:00]

18. 환경변수 작성과 배포용 의존성 설치

• 프로젝트 의존성을 설치한 뒤 .env 파일에 카카오 ID와 시크릿을 입력하고, Vim에서는 :wq로 저장과 종료를 함께 수행한다. [33:16]
• AI 비서가 없으면 환경변수 파일 생성과 비밀번호 입력을 오타 없이 직접 처리해야 하며, 수동 배포의 복잡성과 실수 가능성이 커진다. [34:01]

19. 데이터베이스 반영과 애플리케이션 빌드

• Drizzle 스키마를 데이터베이스에 반영하는 과정에서 ES2023 관련 오류가 발생했고, tsconfig.json의 target을 ESNext로 바꾼 뒤 다시 실행하자 정상 처리됐다. [35:35]
• 빌드는 TypeScript 소스를 실행 가능한 JavaScript로 변환하며, 그 결과 생성된 dist/main.js를 PM2가 시작 파일로 사용한다. [36:16]

20. 서버 상태 검증과 외부 공개

• pm2 list에서 재시작 횟수가 계속 증가하거나 상태가 online이 아니면 서버 오류이며, pm2 monit이나 pm2 logs로 실시간 로그를 확인해야 한다. [37:30]
• 프로세스가 online이고 업타임만 계속 증가하면 서버가 정상 실행 중이며, 인스턴스의 퍼블릭 IP를 공유해 외부 사용자가 서비스에 접속할 수 있다. [38:15]

21. 과금 차단과 후속 운영 과제

• 무료 티어도 1년이 지나면 비용이 발생할 수 있으므로 사용하지 않는 인스턴스를 종료해 추가 과금을 막아야 한다. [39:00]
• 퍼블릭 IP와 보안 경고가 그대로 노출된 상태는 신뢰하기 어려우며, 도메인 연결과 HTTPS 발급이 실제 서비스 운영을 위한 후속 과제로 남는다. [39:18]

🧾 결론

• AI 비서는 배포 명령 실행기뿐 아니라 오류를 추적하고 소스를 수정하는 운영 보조 도구로 활용할 수 있다.
• 자동화가 기술적 판단까지 보장하지는 않으므로 MySQL과 MariaDB처럼 유사하지만 다른 제품을 선택하는 오류를 사람이 차단해야 한다.
• 성공 여부는 화면이 한 번 열리는 데서 끝나지 않고 MySQL Alive, Redis Pong, PM2 online 상태와 외부 접속을 함께 확인해야 판단할 수 있다.
• IP와 포트로 접속한 HTTP 상태는 임시 검증이며, 실제 운영에는 도메인 연결과 HTTPS 적용이 추가로 필요하다.

📈 투자·시사 포인트

• 서버 상태를 직접 관찰하고 명령 실행과 오류 수정을 연결하는 관리형 AI는 단순한 명령 생성보다 높은 운영 편의성을 제공한다.
• AI가 사전 설치된 VPS와 웹 대시보드는 비개발자의 초기 진입 장벽을 낮추지만, 보안과 인프라 지식에 대한 수요까지 제거하지는 못한다.
• 일상 작업과 복잡한 작업에 서로 다른 모델을 배정하는 방식은 성능뿐 아니라 구독 한도와 비용을 고려한 모델 라우팅의 필요성을 보여준다.
• 향후 경쟁력은 자동화 범위뿐 아니라 최소 권한 관리, 비밀값 전달, 실행 명령 설명, 배포 후 상태 검증을 얼마나 안전하게 제품화하는지에 달려 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• KVM2 사양과 일부 도메인의 1년 무료 제공 조건은 소개됐지만, 장기 요금과 갱신 조건은 제시되지 않았다.
• Hermes가 배포 중 수정한 소스 오류와 네트워크 문제의 구체적인 원인 및 변경 내용은 상세히 제시되지 않았다.
• AI 배포와 AWS 수동 배포의 총소요 시간, 오류 횟수, 운영 비용을 같은 기준으로 측정한 정량 비교는 제공되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• AI가 제안한 명령마다 제품명, 버전, 설치 위치와 권한 범위를 확인한다.
• GitHub 토큰은 필요한 저장소와 Contents 권한만 부여하고 짧은 만료 기간을 설정한 뒤 배포 후 폐기하거나 재발급한다.
• sudo가 필요한 호스트 작업과 Hermes가 수행할 비권한 작업을 사전에 분리한다.
• MySQL Alive, Redis Pong, docker ps, pm2 list와 외부 접속 결과를 배포 완료 체크리스트로 검증한다.

❓ 열린 질문

• 자격 증명을 채팅에 직접 노출하지 않으면서 Hermes에 비공개 저장소와 애플리케이션 비밀값을 전달할 방법은 무엇인가?
• AI가 제안한 기술 스택 변경과 호스트 권한 명령을 어떤 승인 절차로 통제해야 하는가?
• 동일한 서비스와 운영 조건에서 AI 배포와 수동 배포의 시간, 오류, 비용 차이는 얼마나 되는가?