노트북을 접어도 일하는 에이전트: Lightsail, Hermes, Discord로 만든 원격 개발 환경#

2026-06-01

문제는 노트북이 접히는 순간 시작되었습니다#

필자는 한동안 Hermes Agent를 로컬 노트북에 설치해서 사용했습니다. 로컬에서 바로 저장소를 열고, 파일을 수정하고, 테스트를 실행하는 경험은 빠르고 직관적이었습니다. 하지만 생활 패턴과 맞지 않는 문제가 있었습니다. 노트북을 접어서 가방에 넣는 순간 에이전트도 함께 멈췄습니다.

AI 에이전트를 쓰는 이유는 사람이 자리를 비운 동안에도 일을 맡기기 위해서입니다. 그런데 실행 환경이 로컬 노트북에 묶여 있으면, 이동 중에는 모바일로 확인만 할 수 있고 실제 작업은 이어가기 어렵습니다. 특히 긴 테스트, 의존성 설치, 저장소 분석처럼 시간이 걸리는 작업은 노트북이 켜져 있어야만 진행됩니다.

그래서 방향을 바꾸기로 했습니다. 에이전트는 항상 켜져 있는 원격 서버에 두고, 필자는 어디서든 메시지로 지시하는 구조입니다.

Slack보다 Discord가 편하다는 결론#

처음에는 Slack 연동을 먼저 떠올렸습니다. 회사 업무 도구가 Slack 중심이라 자연스러운 선택처럼 보였습니다. 하지만 직접 써보니 몇 가지 불편이 있었습니다.

• 봇 호출 방식과 채널 컨텍스트가 예상과 다르게 동작하는 경우가 있었습니다.
• 메시지 thread와 긴 작업 로그가 섞이면 흐름을 따라가기 어려웠습니다.
• 모바일에서 개인 작업용 에이전트와 팀 커뮤니케이션이 한 공간에 섞이는 점도 부담이었습니다.

물론 Slack이 나쁘다는 뜻은 아닙니다. 팀 공용 봇, 알림, 업무 채널 통합에는 여전히 Slack이 좋습니다. 다만 개인 원격 개발 에이전트 로는 Discord가 더 잘 맞았습니다. 다른 사용자들의 경험을 들어봐도 비슷했습니다. 개인 서버를 하나 만들고, Hermes 전용 채널이나 DM(Direct Message, 개인 메시지)으로 대화하는 방식이 가장 단순했습니다.

필자의 결론은 다음과 같습니다.

목표 아키텍처#

최종적으로 만들고 싶었던 구조는 단순합니다.

모바일 Discord
  ↓
Hermes Gateway
  ↓
AWS Lightsail 인스턴스
  ↓
Docker sandbox
  ↓
/workspace 아래의 GitHub 저장소들

핵심은 두 가지입니다.

첫째, Hermes gateway는 원격 서버에서 계속 실행됩니다. 필자가 노트북을 닫아도 Discord 메시지를 받을 수 있습니다.

둘째, 실제 명령 실행은 Docker sandbox 안에서 이루어집니다. Hermes가 실수로 민감한 host 파일을 읽거나 수정하지 않도록 작업 공간을 분리합니다.

왜 Lightsail인가#

처음에는 EC2와 Lightsail 사이에서 고민했습니다. EC2는 IAM, VPC, Security Group, SSM Session Manager 등 운영 제어가 더 정교합니다. 반면 Lightsail은 단순합니다. 인스턴스, 고정 IP, 방화벽, 스냅샷 정도만 이해하면 바로 시작할 수 있습니다.

이번 목적은 대규모 서비스 운영이 아니라 개인용 원격 에이전트 실행 환경 입니다. 그래서 Lightsail이 충분하다고 판단했습니다.

권장 기준은 다음과 같습니다.

중요한 점은 외부에서 Hermes API나 dashboard 포트를 열지 않는 것입니다. Discord gateway는 서버가 Discord 쪽으로 outbound 연결을 유지하는 구조이므로, 개인 사용만 한다면 공개 인바운드 포트는 SSH만 있어도 충분합니다.

보안 기준: 편의성과 격리 사이#

이 환경에서 가장 민감한 것은 코드보다 권한입니다. 예를 들어 다음 값들은 절대 채팅 로그나 공개 문서에 노출되면 안 됩니다.

• LLM provider API key
• Discord bot token
• GitHub fine-grained token
• Notion, Slack 등 MCP(Model Context Protocol) 서버용 token
• 서버 SSH key
• 회사 저장소명과 내부 경로

그래서 원칙을 이렇게 잡았습니다.

Docker sandbox는 모든 문제를 해결하는 완전한 금고가 아닙니다. repo 디렉터리를 sandbox 안에서 읽고 쓰게 하므로, 에이전트는 당연히 해당 repo를 수정할 수 있습니다. 다만 host의 Hermes 설정, SSH key, .env 같은 민감 파일과 일반 작업 공간을 분리하는 효과가 큽니다.

구축 과정#

아래 절차는 공개 글에 맞게 일반화한 버전입니다. 실제 IP, 토큰, 계정 ID, 저장소명은 모두 placeholder로 표기합니다.

1. Lightsail 인스턴스 생성#

AWS Lightsail에서 Ubuntu LTS 인스턴스를 생성합니다. 생성 후 Networking 탭에서 방화벽을 조정합니다.

IPv4 Firewall
- SSH 22: 본인 현재 IP만 허용
- HTTP 80: 삭제
- HTTPS 443: 삭제
- 기타 포트: 없음

IPv6 Firewall
- IPv6를 쓰지 않으면 모든 rule 삭제
- IPv6를 쓴다면 SSH 22를 본인 IPv6로만 제한

Lightsail은 IPv4 방화벽과 IPv6 방화벽이 독립적으로 동작합니다. IPv4만 잠그고 IPv6를 열어두면 의도치 않은 경로가 남을 수 있습니다.

2. SSH 접속과 기본 패키지 설치#

Lightsail 기본 키를 내려받고, 로컬에서 키 권한을 제한합니다.

chmod 600 <LIGHTSAIL_KEY>.pem
ssh -i <LIGHTSAIL_KEY>.pem ubuntu@<LIGHTSAIL_PUBLIC_IP>

서버에 접속한 뒤 기본 패키지를 설치합니다.

sudo apt update
sudo apt upgrade -y
sudo apt install -y git curl ca-certificates ufw fail2ban jq unzip

3. Hermes 전용 사용자 생성#

Hermes를 root나 기본 사용자로 실행하지 않기 위해 전용 사용자를 만듭니다.

sudo adduser --disabled-password --gecos "" hermes
sudo install -d -m 700 -o hermes -g hermes ~hermes/.ssh
sudo cp ~/.ssh/authorized_keys ~hermes/.ssh/authorized_keys
sudo chown hermes:hermes ~hermes/.ssh/authorized_keys
sudo chmod 600 ~hermes/.ssh/authorized_keys

이후에는 hermes 사용자로 접속해 작업합니다.

ssh -i <LIGHTSAIL_KEY>.pem hermes@<LIGHTSAIL_PUBLIC_IP>

4. Docker 설치#

Docker 설치는 sudo 권한이 필요하므로 ubuntu 사용자에서 진행합니다.

curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
sudo usermod -aG docker hermes

그다음 hermes 사용자로 새 SSH 세션을 열고 확인합니다.

docker run --rm hello-world

5. Hermes 설치와 모델 설정#

hermes 사용자로 Hermes를 설치합니다.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash -s -- --skip-browser
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

모델 provider는 hermes model로 설정합니다.

hermes model

OpenAI API key를 직접 사용할 경우 base URL은 기본값인 https://api.openai.com/v1을 그대로 사용하면 됩니다.

6. Docker backend 설정#

Hermes가 실제 명령을 Docker sandbox 안에서 실행하도록 설정합니다.

hermes config set terminal.backend docker
hermes config set terminal.container_persistent true

설정 파일에는 대략 다음 구조가 들어갑니다.

terminal:
  backend: docker
  container_persistent: true
  docker_forward_env: []

docker_forward_env: []는 host의 환경변수를 작업 컨테이너로 자동 전달하지 않겠다는 뜻입니다.

7. 브라우저 도구 설치#

프론트엔드 E2E(End-to-End, 사용자 흐름 전체 테스트)나 실제 브라우저 확인이 필요하면 browser tool도 설치합니다.

hermes acp --setup-browser --yes

이후 Discord에서 브라우저 자동화가 되려면 hermes tools에서 Discord 플랫폼의 Browser Automation이 켜져 있어야 합니다.

8. GitHub 저장소 연결#

회사 저장소가 4~5개 정도라면 두 가지 선택지가 있습니다.

필자는 편의성을 위해 fine-grained token 방식을 선택했습니다. GitHub에서 필요한 저장소만 선택하고, Contents: Read and write, Pull requests: Read and write 정도로 권한을 제한합니다.

Docker sandbox 안에서는 다음처럼 credential store를 설정합니다.

git config --global credential.helper store
git config --global user.name "<YOUR_NAME>"
git config --global user.email "<YOUR_EMAIL>"

저장소는 /workspace 아래에 clone합니다.

mkdir -p /workspace
cd /workspace
git clone https://github.com/<ORG>/<REPO_A>.git
git clone https://github.com/<ORG>/<REPO_B>.git

중요한 점은 remote URL에 token이 남지 않아야 한다는 것입니다.

git remote -v

정상 형태는 다음과 같습니다.

https://github.com/<ORG>/<REPO>.git

9. Discord bot 생성과 연결#

Discord Developer Portal에서 새 application을 만들고 bot token을 발급합니다. Bot 설정에서는 다음 intent를 켭니다.

Server Members Intent: ON
Message Content Intent: ON

OAuth2 URL Generator에서는 다음을 선택합니다.

Integration Type: Guild Install
Scopes:
- bot
- applications.commands

Bot Permissions:
- View Channels
- Send Messages
- Read Message History
- Embed Links
- Attach Files
- Use Application Commands

생성된 URL로 개인 Discord 서버에 bot을 초대합니다.

10. Discord allowlist 설정#

Discord 사용자 설정에서 개발자 모드를 켠 뒤 본인 User ID를 복사합니다. 한국어 UI에서는 대략 다음 경로입니다.

사용자 설정
→ 개발자
→ 개발자 모드 ON
→ 본인 프로필 우클릭
→ 사용자 ID 복사

Lightsail의 ~/.hermes/.env에는 다음처럼 저장합니다.

DISCORD_BOT_TOKEN=<DISCORD_BOT_TOKEN>
DISCORD_ALLOWED_USERS=<YOUR_DISCORD_USER_ID>
MESSAGING_CWD=/workspace

절대 아래 설정을 공개 환경에서 켜지 않습니다.

GATEWAY_ALLOW_ALL_USERS=true
DISCORD_ALLOW_ALL_USERS=true

11. gateway를 systemd로 실행#

테스트가 끝나면 gateway를 systemd 서비스로 등록합니다.

[Unit]
Description=Hermes Gateway
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
User=hermes
WorkingDirectory=<HERMES_HOME>
Environment=PATH=<HERMES_HOME>/.hermes/node/bin:<HERMES_HOME>/.local/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=<HERMES_HOME>/.local/bin/hermes gateway
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

적용합니다.

sudo systemctl daemon-reload
sudo systemctl enable --now hermes-gateway
sudo systemctl status hermes-gateway

MCP 서버와 skill은 운영 권한으로 본다#

구축하면서 흥미로웠던 지점은 MCP 서버 설정입니다. Docker sandbox 안의 에이전트는 host의 ~/.hermes/config.yaml을 보지 못합니다. 이것은 불편하지만, 보안 관점에서는 정상입니다. MCP 서버를 추가한다는 것은 에이전트가 외부 시스템과 연결되는 도구 권한을 확장한다는 뜻이기 때문입니다.

편의성을 높이려면 config.yaml만 sandbox 안에 제한적으로 mount할 수 있습니다.

terminal:
  backend: docker
  docker_volumes:
    - <HERMES_HOME>/.hermes/config.yaml:/host-hermes/config.yaml

다만 이 선택은 신중해야 합니다. 에이전트가 MCP 서버를 직접 추가할 수 있다는 것은 외부 endpoint와 도구 권한을 스스로 늘릴 수 있다는 뜻입니다. 따라서 실제 secret은 여전히 .env에 두고, config.yaml에는 ${ENV_NAME} 형태로만 참조하게 하는 편이 낫습니다.

Skill도 비슷합니다. Skill은 ~/.hermes/skills/ 아래에 추가되며 Hermes의 행동 지침이 됩니다. 편리하지만, 공개 URL에서 가져온 skill을 무심코 설치하는 것은 위험할 수 있습니다. 회사 업무용 환경에서는 에이전트가 만든 skill도 사람이 한 번 읽고 승인하는 절차가 좋습니다.

최종 확인#

구축 후에는 Discord DM에서 다음을 차례로 확인했습니다.

현재 작업 디렉토리와 실행 환경을 알려줘.

/workspace 아래 저장소 목록과 각 저장소의 git status를 확인해줘.

브라우저 자동화 도구로 https://example.com 에 접속해 페이지 제목을 알려줘.

Notion 또는 Slack MCP 서버가 연결되어 있다면 사용할 수 있는 도구 목록을 확인해줘.

이 네 가지가 되면 모바일에서 개발 업무를 맡길 수 있는 기본 조건은 갖춘 셈입니다.

남은 생각#

이번 구성의 핵심은 에이전트를 노트북에서 떼어내는 것 이었습니다. 로컬 노트북은 여전히 가장 편한 개발 환경이지만, 항상 켜져 있는 실행 환경은 아닙니다. 반면 Lightsail 같은 작은 원격 서버는 IDE는 아니지만, 에이전트가 오래 생각하고, 테스트하고, 결과를 남기기에는 충분합니다.

Discord는 그 위에 얹은 얇은 조작 인터페이스입니다. 모바일에서 긴 설명을 쓰고, 에이전트가 원격 서버에서 저장소를 살펴보고, 필요하면 테스트를 돌립니다. 필자는 노트북을 다시 열었을 때 결과를 이어받으면 됩니다.

이 구조가 모든 팀에 맞지는 않습니다. 조직 공용 봇이라면 Slack, 권한 관리, 감사 로그, 네트워크 정책을 더 엄격하게 봐야 합니다. 하지만 개인 개발자가 자신의 작업 흐름을 확장하는 용도라면, Lightsail + Hermes + Discord + Docker sandbox 조합은 꽤 현실적인 해법입니다.

노트북을 접어도 일이 멈추지 않는다는 것. 그것만으로도 에이전트 사용 경험은 꽤 달라집니다.