디스코드 서버에서 AI를 활용하게 되면서 배운 것

Hermes에 디스코드를 붙이면 무엇이 달라질지 궁금했다.

단순히 “채팅창 하나가 더 생긴다”는 기대는 아니었다. Claude Code 같은 코딩 에이전트라면 보통 터미널이나 IDE 안에서 부르는 것만으로도 충분하다. 코드 작업이 중심이고, 사람이 앉아 있는 개발 환경 안에서 움직이면 되니까.

그런데 Hermes는 조금 다르다. Hermes는 코딩 에이전트라기보다 개인 작업 환경에 붙는 AI 비서에 가깝다. 파일을 읽고, 명령을 실행하고, 브라우저를 열고, 기억을 남기고, 반복 작업을 예약하고, 여러 플랫폼에서 불러낼 수 있다. 그래서 디스코드 연결이 더 의미 있었다. 개발할 때만 쓰는 도구가 아니라, 내가 이미 대화하고 지시하고 알림을 받는 공간으로 Hermes를 끌어올 수 있기 때문이다.

내가 기대한 부가 효과도 그 지점에 있었다. 휴대폰에서 바로 작업을 부탁할 수 있고, 서버 안의 스레드가 자연스럽게 작업 단위가 되고, 자동화 결과가 다시 채널로 돌아오고, 여러 사람이 같은 공간에서 AI를 부를 수 있다. AI가 터미널 속 도구에서 서버 안의 구성원처럼 보이기 시작하는 것이다.

며칠 써보니 이 기대가 아주 틀리지는 않았다. 디스코드 안의 Hermes는 단순히 “답변하는 봇”에서 끝나지 않는다. 대화가 쌓이고, 작업 맥락이 이어지고, 파일을 읽고, 명령을 실행하고, 결과를 다시 디스코드로 가져온다. 그러면 채팅방이 조금씩 작업실처럼 변한다.

이 글은 그 과정에서 느낀 점을 정리한 기록이다. 거창한 성공담은 아니다. 오히려 “AI를 잘 쓰려면 일의 모양부터 바꿔야 하는구나”에 가까웠다.

채팅방이 작업 공간이 되기 시작했다

디스코드는 원래 대화가 흘러가는 공간이다. 누가 질문하면 답하고, 링크를 던지고, 생각나는 걸 적고, 지나간다. AI를 붙이기 전에는 그 흐름이 대부분 사람 사이에서만 돌았다.

AI가 들어오면 이 흐름이 조금 바뀐다. 사람이 “이거 정리해줘”라고 말하면 AI가 요약한다. “이 파일 봐줘”라고 하면 실제 파일을 읽는다. “빌드 되는지 확인해줘”라고 하면 명령을 실행하고 결과를 가져온다.

처음에는 이게 편의 기능처럼 보인다. 그런데 몇 번 반복하면 채팅방 안에서 일이 닫히기 시작한다. 예전에는 디스코드에서 얘기하고, 터미널로 가고, 브라우저로 가고, 다시 디스코드로 돌아왔다. 이제는 그 왕복의 일부를 AI가 맡는다.

이 차이가 생각보다 크다. 사람이 맥락을 계속 들고 다니지 않아도 된다. “아까 말한 그 글”, “방금 확인한 빌드 오류”, “이전에 정한 발행 방식” 같은 것들이 대화 안에서 이어진다. 디스코드가 단순한 메신저가 아니라 작업 로그와 지시서, 보고서가 섞인 공간이 된다.

Hermes를 디스코드에 붙이는 과정에서 배운 것

Hermes를 디스코드에 붙이는 과정은 생각보다 단순했지만, 아무 생각 없이 넘기면 막히는 지점이 몇 군데 있었다. 크게 보면 디스코드 쪽에서 봇을 만들고, Hermes 쪽에서 gateway를 설정하고, 마지막으로 서버 안에서 어떻게 대화하게 할지 정하는 흐름이었다.

먼저 디스코드 개발자 포털에서 애플리케이션과 봇을 만든다. 여기서 가장 중요한 건 권한이다. 봇이 온라인으로 떠도 메시지 내용을 읽지 못하면 아무 일도 못 한다. 그래서 Message Content Intent는 꼭 켜야 했다. 서버 안에서 사용자나 역할을 기준으로 접근을 나누려면 Server Members Intent도 필요했다. 이걸 빼먹으면 “봇은 켜져 있는데 왜 대답을 안 하지?” 같은 상태가 된다.

그 다음에는 봇을 서버에 초대한다. 초대 링크를 만들 때는 단순히 메시지를 보내는 권한만 주면 부족하다. 채널을 볼 수 있어야 하고, 메시지를 보낼 수 있어야 하고, 파일이나 이미지 결과를 보내려면 첨부 권한도 있어야 한다. 스레드에서 대화하려면 스레드 메시지 권한도 필요하다. 처음부터 모든 권한을 크게 열 필요는 없지만, Hermes가 실제로 어떤 일을 할지 생각하고 권한을 줘야 했다.

Hermes 쪽에서는 hermes gateway setup으로 Discord를 선택하고 봇 토큰과 허용할 사용자 ID를 넣는 방식이 제일 편했다. 직접 설정할 수도 있지만, 처음에는 wizard를 타는 편이 덜 헷갈린다. 여기서 중요한 건 봇 토큰을 공개하지 않는 것과, 아무나 Hermes를 부를 수 없게 허용 사용자를 좁혀두는 것이다. 디스코드 서버에 붙는 순간 접근 경로가 늘어나기 때문이다.

처음 붙일 때 필요한 CLI 흐름은 대략 이렇다.

# Hermes 설치 뒤 기본 설정과 상태 확인
hermes setup
hermes doctor

# Discord를 포함한 messaging gateway 설정
hermes gateway setup

# 설정한 gateway를 foreground로 먼저 테스트
hermes gateway run

# 계속 쓸 거라면 서비스로 등록하고 실행
hermes gateway install
hermes gateway start
hermes gateway status

수동으로 설정해야 한다면 토큰과 허용 사용자는 .env에 둔다. 실제 값은 절대 글이나 저장소에 올리면 안 된다.

# ~/.hermes/.env 예시
DISCORD_BOT_TOKEN=your-bot-token
DISCORD_ALLOWED_USERS=your-discord-user-id

붙이고 나서 알게 된 것도 있다. Hermes의 Discord gateway는 단순 webhook이 아니었다. 메시지가 들어오면 권한을 확인하고, 멘션이 필요한지 판단하고, 세션을 찾고, 이전 대화 맥락을 불러온 다음, 평소 Hermes가 하던 방식대로 도구와 기억을 써서 답한다. 그래서 디스코드에서 말을 걸어도 그냥 “채팅 답변”이 아니라 실제 작업으로 이어질 수 있다.

대신 서버 채널에서는 기본적으로 봇을 멘션해야 답하는 방식이 안전했다. 모든 메시지에 반응하게 만들면 처음에는 편해 보이지만 금방 시끄러워진다. 특정 채널만 자유 응답 채널로 두고, 나머지는 멘션할 때만 답하게 하는 쪽이 더 나았다. 일반 대화 채널과 작업 지시 채널을 분리하는 것도 이때 필요해졌다.

세션 분리도 중요했다. 디스코드에서는 DM, 채널, 스레드가 모두 다른 대화 공간처럼 보이지만, AI 입장에서는 어디까지를 같은 맥락으로 볼지 정해야 한다. 기본값처럼 사용자별로 세션을 나누면 여러 사람이 같은 채널에서 말을 걸어도 서로의 맥락이 섞이지 않는다. 반대로 팀 전체가 하나의 작업 맥락을 공유해야 하는 채널이라면 일부러 공유 세션처럼 운영할 수도 있다. 어느 쪽이든 그냥 켜두는 게 아니라, 서버에서 AI를 어떻게 쓸지 먼저 정해야 했다.

마지막으로 gateway는 계속 떠 있어야 의미가 있다. 터미널에서 한 번 실행하고 끝내는 도구가 아니라, 디스코드와 Hermes 사이를 이어주는 백그라운드 프로세스에 가깝다. 그래서 처음 테스트는 foreground로 해도 되지만, 실제로 쓰려면 서비스로 등록하고 상태를 확인하는 흐름이 필요했다. 여기까지 해두고 나서야 “디스코드에서 부르면 내 작업 환경에서 실제로 움직이는 AI”가 된다.

AI에게 일을 맡기려면 요청을 바꿔야 했다

처음에는 나도 평소처럼 말했다.

“이거 해줘.”

사람에게는 이 말이 통할 때가 많다. 서로 이미 알고 있는 맥락이 있고, 모르면 되묻고, 대충 감으로 맞춘다. AI도 어느 정도는 그렇게 한다. 문제는 실제 작업을 맡길수록 “대충”의 비용이 커진다는 점이다.

예를 들어 블로그 글을 올린다고 하면 그냥 “게시물 작성해줘”로는 부족하다. 제목은 무엇인지, 공개해도 되는 내용은 어디까지인지, 초안 상태로 둘지 바로 발행할지, 미리보기는 어떻게 할지, 빌드 검증까지 할지 정해야 한다.

AI를 잘 쓰려면 일을 더 작게 나눠야 했다.

“이 주제로 초안을 써줘.”

“아직 공개하지 말고 draft로 둬.”

“내부 경로나 주소는 빼고 써줘.”

“기존 글과 같은 frontmatter 형식으로 맞춰줘.”

이렇게 말하면 AI가 훨씬 안정적으로 움직인다. 반대로 요청이 흐릿하면 결과도 흐릿하다. AI가 멍청해서라기보다, 사람이 머릿속에만 들고 있던 조건을 밖으로 꺼내지 않았기 때문이다.

이걸 몇 번 겪고 나니, AI를 쓴다는 건 명령을 잘하는 문제가 아니라 일을 설명 가능한 형태로 바꾸는 일에 가깝다는 생각이 들었다.

역할을 나누면 훨씬 편해졌다

처음에는 하나의 AI에게 모든 걸 시키면 된다고 생각했다. 글도 쓰고, 코드도 보고, 서버도 확인하고, 리뷰도 하면 되지 않나 싶었다.

실제로 가능은 하다. 하지만 오래 쓰다 보면 역할을 나누는 편이 낫다.

글을 쓰는 AI, 코드를 고치는 AI, 검토하는 AI, 반복 작업을 확인하는 AI는 필요한 관점이 조금씩 다르다. 한 대화 안에서 전부 처리할 수도 있지만, 작업이 커질수록 섞인다. 글을 쓰던 맥락에 배포 이야기가 들어오고, 배포를 보던 중에 디자인 이야기가 끼어든다. 그러면 사람도 헷갈리고 AI도 헷갈린다.

그래서 디스코드 서버 안에서 AI를 쓸 때는 채널이나 스레드, 역할을 어느 정도 나누는 게 좋았다. 글쓰기 스레드는 글쓰기 흐름대로 두고, 운영 알림은 운영 알림대로 두고, 개발 작업은 개발 작업대로 둔다. 이렇게 하면 AI도 지금 자신이 무엇을 해야 하는지 덜 헷갈린다.

특히 여러 AI 도구를 같이 쓸 때는 역할 분리가 더 중요하다. 어떤 도구는 프론트엔드 작업에 강하고, 어떤 도구는 코드 리뷰나 백엔드 수정에 더 편하다. 전부 같은 “AI”로 묶어버리면 장단점이 흐려진다. 사람을 팀에 배치하듯 AI도 자리를 나눠야 한다.

디스코드에서는 기억보다 경계가 먼저였다

Hermes를 디스코드에서 계속 부르다 보면 “이 채널은 어떤 용도인지”, “어떤 사용자가 어디까지 시켜도 되는지”, “어떤 알림은 어디로 보내야 하는지” 같은 운영 규칙이 생긴다. 이런 건 매번 설명하기보다 Hermes가 알고 있는 편이 편하다.

그런데 디스코드에서는 기억을 늘리는 것보다 경계를 정하는 일이 먼저였다. DM, 공개 채널, 비공개 스레드가 섞여 있기 때문이다. 어떤 정보는 개인 대화 안에만 있어야 하고, 어떤 정보는 팀 채널에서 공유돼도 된다. 반대로 임시 링크나 작업 중인 브랜치, 특정 채널에서만 의미 있는 말까지 기억해버리면 다음 대화에서 이상하게 튀어나올 수 있다.

그래서 디스코드에 붙인 Hermes에게는 “무엇을 기억할지”보다 “어느 공간의 맥락을 어디까지 가져갈지”가 더 중요했다. 개인 설정과 장기적인 선호는 남길 만하지만, 채널 안에서 잠깐 오간 운영 잡담은 그 채널의 대화 기록에만 남겨두는 편이 안전하다.

결국 기억은 편의 기능이면서 동시에 운영 정책이었다. 서버 안에서 여러 사람이 AI를 부를수록 이 차이가 더 크게 느껴졌다.

자동화는 생각보다 쉽게 시작되고, 생각보다 쉽게 이상해진다

디스코드에 AI를 붙이면 자연스럽게 자동화를 생각하게 된다. 매일 같은 시간에 보고서를 보내고, 특정 조건이 맞으면 알림을 주고, 새 글이나 공고가 올라오면 확인해주는 식이다.

처음에는 굉장히 좋아 보인다. 사람이 매번 확인하던 일을 AI가 대신 봐주니까. 하지만 자동화는 한 번 설정해두면 사람이 보고 있지 않을 때도 혼자 돈다. 그래서 대충 만든 자동화는 대충 이상한 결과를 계속 보낸다.

예를 들어 “매일 요약해줘”라고만 해두면 매일 비슷한 요약이 올 수 있다. 무엇을 새 정보로 볼지, 이전 결과와 어떻게 비교할지, 추천을 해야 하는지 단순 보고만 해야 하는지, 결과가 없으면 조용히 있어야 하는지 정해줘야 한다.

AI 자동화에서 중요한 건 똑똑한 문장보다 명확한 조건이었다.

무엇을 볼 것인가.

언제 알릴 것인가.

무엇이 바뀌면 새 소식인가.

결과가 없을 때도 메시지를 보낼 것인가.

이런 기준이 없으면 자동화는 금방 소음이 된다. 디스코드 서버에서는 특히 그렇다. 알림이 많아지면 사람은 채널을 안 보게 된다. AI가 일을 덜어주려면, 아무 때나 말하는 봇이 아니라 필요한 때에만 말하는 동료에 가까워야 했다.

권한은 편의성과 같이 커진다

AI가 파일을 읽고, 명령을 실행하고, 브라우저를 조작할 수 있으면 편하다. 디스코드에서 한 줄로 부탁했는데 실제 서버 상태를 확인하고 결과를 알려주는 경험은 꽤 강하다.

하지만 그만큼 조심해야 한다. 권한이 큰 AI는 실수했을 때 영향도 크다. 글 초안에 내부 정보가 들어갈 수 있고, 명령 하나가 예상보다 넓은 범위를 건드릴 수도 있다. 브라우저 자동화에서는 로그인, 결제, 예약 확정 같은 민감한 단계도 만날 수 있다.

그래서 디스코드 안에서는 작업을 두 단계로 나눠서 생각하게 됐다. 확인하고 정리하는 단계는 AI에게 맡겨도 된다. 하지만 채널에 공개 메시지를 보내거나, 실제 시스템을 바꾸거나, 비용과 권한이 걸린 버튼을 누르는 단계는 사람이 다시 확인해야 한다.

디스코드에서 AI를 쓰면 접근성이 너무 좋아진다. 휴대폰에서 바로 시킬 수 있다는 건 장점이지만, 실수도 쉽게 할 수 있다는 뜻이다. 편해질수록 경계선을 더 분명히 해야 했다.

좋은 AI 협업은 “알아서 해줘”가 아니었다

AI를 많이 쓰면 언젠가 “그냥 알아서 해주면 좋겠다”는 기대가 생긴다. 나도 그랬다. 특히 디스코드에 붙여두면 정말 개인 비서처럼 느껴지는 순간이 있다.

하지만 지금까지의 결론은 조금 다르다. 좋은 AI 협업은 AI가 모든 걸 알아서 하는 게 아니었다. 사람이 방향과 기준을 정하고, AI가 확인과 실행을 맡는 구조가 가장 안정적이었다.

사람은 무엇을 할지 정한다. 공개해도 되는지 판단한다. 결과가 마음에 드는지 읽는다. 애매한 결정을 내린다.

AI는 파일을 찾고, 명령을 실행하고, 초안을 만들고, 반복되는 확인을 대신한다. 사람이 놓치기 쉬운 체크리스트를 따라가고, 결과를 다시 대화로 가져온다.

이렇게 나누면 둘 다 편해진다. 사람은 계속 창을 오가며 확인하지 않아도 되고, AI는 모호한 최종 판단까지 떠안지 않아도 된다.

디스코드는 AI와 일하기에 꽤 괜찮은 장소였다

디스코드는 원래 개발 도구가 아니다. 하지만 AI를 붙여보니 장점이 분명했다.

스레드로 맥락을 나눌 수 있다. 채널로 목적을 나눌 수 있다. 알림이 바로 온다. 모바일에서도 이어서 볼 수 있다. 무엇보다 대화가 자연스럽다. 터미널 앞에 앉아 있지 않아도 “이거 확인해줘”라고 말할 수 있다.

물론 단점도 있다. 대화가 흘러가다 보면 중요한 결정이 묻힌다. 여러 사람이 같이 쓰면 권한과 범위를 더 신경 써야 한다. AI가 보낸 긴 메시지가 쌓이면 채널 자체가 피곤해질 수도 있다.

그래도 지금은 장점이 더 크게 느껴진다. 디스코드는 이미 사람들이 모여 있는 공간이고, AI는 그 안에서 일을 이어받을 수 있다. 새 도구를 하나 더 여는 게 아니라, 이미 쓰는 대화 공간에 작업 능력이 붙는 셈이다.

지금 배운 것

디스코드 서버에서 AI를 활용하면서 가장 크게 배운 건 이거다.

AI를 붙인다고 바로 자동화된 팀이 생기지는 않는다. 그냥 똑똑한 봇 하나가 들어올 뿐이다. 하지만 대화의 위치를 정하고, 역할을 나누고, 기억할 것과 버릴 것을 가르고, 자동화 조건을 분명히 하면 이야기가 달라진다.

채팅방이 작업실이 된다.

사람은 방향을 정하고, AI는 반복되는 확인과 실행을 맡는다. 그 사이에서 디스코드는 단순한 메신저가 아니라 작업이 흘러가는 공간이 된다.

아직 완성된 방식은 아니다. 아마 앞으로도 계속 바뀔 것이다. 그래도 이제는 확실히 알겠다. AI를 잘 쓰는 문제는 어떤 모델이 제일 똑똑한가에서 끝나지 않는다. 어디에 붙이고, 어떤 권한을 주고, 어떤 방식으로 말하게 할지가 더 중요하다.

디스코드 서버에 AI를 붙이면서 배운 건 결국 도구 이야기가 아니었다. 같이 일하는 방식에 대한 이야기였다.