디스코드 봇 초대 링크는 결국 OAuth2 인증 URL이에요. scope 매개변수는 어떤 종류의 접근을 요청하는지(봇 계정, 슬래시 명령어, 또는 둘 다)를 정하고, permissions 숫자는 봇 계정이 서버에 들어온 뒤 무엇을 할 수 있는지를 정해요. 그리고 서버 관리자가 전체 요청을 승인해야만 어느 것이든 적용돼요. 이 두 매개변수를 이해하는 것이, 안전한 초대 링크를 만드는 것과 내용을 전부 설명할 수 없는 링크를 그냥 복사하는 것의 차이예요.
초대 링크의 구조
일반적인 봇 초대 링크는 이렇게 생겼어요:
https://discord.com/oauth2/authorize?client_id=123456789&permissions=268446800&scope=bot%20applications.commands
- client_id - 애플리케이션의 공개 ID예요. 공유해도 안전하고, 그 봇의 모든 초대 링크에 들어 있어요.
- scope - 요청하는 접근 종류예요. 공백으로 구분하며, URL 인코딩되어
%20으로 표시돼요. - permissions - 요청하는 모든 서버 권한을 더해서 나타낸 숫자 하나예요.
- guild_id와 disable_guild_select (선택 사항) - 특정 서버를 미리 선택하고 선택 목록을 그 서버로 고정해요. 서버별 "여기에 나를 추가" 버튼에 유용해요.
"bot" 스코프
이 스코프가 실제로 봇을 서버의 멤버로 추가해요. 멤버 목록에 봇 태그와 함께 나타나는 항목이 바로 이거예요. 이 스코프가 없으면 아무것도 들어가지 않아요. 승인할 봇 계정 자체가 없기 때문이에요.
"applications.commands" 스코프
이 스코프는 애플리케이션의 슬래시, 사용자, 메시지 명령어를 등록해서 그 서버에서 쓸 수 있게 해요. 기술적으로는 bot 스코프만으로도 봇을 들일 수 있어요. 하지만 서버가 명령어 등록을 승인하지 않았으므로, 누군가 /를 입력해도 봇의 /commands는 아무것도 나타나지 않아요.
거의 항상 둘 다 필요한 이유
bot만으로 초대된 봇도 메시지를 보내고, 이미 보낸 메시지의 버튼에 반응하고, 슬래시 명령어가 필요 없는 일에는 응답할 수 있어요. 하지만 요즘 디스코드 사용자는 명령어를 기대하고, 명령어를 등록할 수 없는 봇은 실제로 잘 작동하더라도 고장 난 것처럼 보여요. Noxyr가 생성하는 모든 초대 링크, 그리고 거의 모든 정상적인 봇의 초대 링크에 두 스코프가 함께 들어가는 이유가 바로 이거예요.
권한 숫자 해독하기
메시지 보내기, 역할 관리, 멤버 추방 같은 디스코드 권한은 각각 비트필드의 한 비트, 즉 2의 거듭제곱 플래그예요. 초대 링크의 숫자는 요청하는 모든 플래그를 더한 값이에요. permissions가 8인 링크는 정확히 한 가지를 요청하는 거예요. 관리자(Administrator), 즉 서버에 대한 완전하고 제한 없는 접근이에요. 잘 만들어진 초대 링크는 디스코드가 제공하는 모든 권한이 아니라, 봇 코드가 실제로 쓰는 특정 플래그만 더해요. 티켓 채널을 만들기 위한 채널 관리, 인증 역할을 위한 역할 관리, 레이드 대응을 위한 모더레이션 작업 같은 것들이에요.
관리자 권한은 요구 사항이 아니라 위험 신호예요
대부분의 정상적인 봇은 관리자 권한이 필요 없어요. 이것을 요청하는 경우는 거의 모든 권한에 한꺼번에 닿는 무언가가 정말로 드물게 필요한 경우이거나, 훨씬 흔하게는 그냥 permissions를 8로 두고 빠르게 만든 봇인 경우예요. 가장 쉽게 떠올릴 수 있는 숫자이기 때문이에요. 또한 설정 중에 디스코드가 서버 소유자에게 보여 주는 가장 무서운 화면이기도 해서, 초대가 아예 거절되거나 나중에 권한을 정리하던 누군가가 봇을 제거하는 흔한 이유가 되기도 해요. 승인을 누르기 전에 디스코드 권한 계산기로 어떤 링크든 권한 숫자를 해독해서, 정확히 무엇을 요구하는지 확인할 수 있어요.
예시: Noxyr의 초대 링크는 어떻게 만들어지나요
Noxyr는 관리자 권한을 요청하지 않아요. 초대 링크는 기능이 실제로 쓰는 특정 권한으로 만들어져요. 티켓과 인증을 위한 채널 및 역할 관리, 안티 너크 대응을 위한 메시지 및 모더레이션 권한이에요. 이 목록을 넘어서는 것은 없어요. 항상 bot과 applications.commands 스코프를 둘 다 포함하므로, 서버에 들어가는 순간 명령어가 바로 작동해요.
자주 보이는 다른 OAuth2 스코프
디스코드는 bot과 applications.commands 외에도 수십 개의 OAuth2 스코프를 정의해요. 그중 대부분, 예를 들어 identify나 guilds.join은 봇 초대가 아니라 "디스코드로 로그인" 같은 웹 인증에 속하며, 표준 초대 링크에는 아예 나타나지 않아요. 보고 있는 링크가 bot과 함께 낯선 것을 요청한다면, 승인하기 전에 그 스코프가 실제로 무엇을 허용하는지 확인할 가치가 있어요. 계정 연결도 제공하는 서비스가 아니라면, 봇 초대에 추가 웹 인증 스코프가 정당하게 필요한 경우는 드물기 때문이에요.
내 커스텀 봇의 초대 링크 만들기
디스코드 개발자 포털에서 애플리케이션을 만들었다면, OAuth2 탭의 URL 생성기가 이 링크를 체크박스로 만들어 줘요. 스코프에서 bot과 applications.commands를 체크하고, 봇에 필요한 권한을 체크한 다음 결과를 복사하면 돼요. URL과 권한 숫자를 손으로 조립할 필요가 없어요.
자주 묻는 질문
disable_guild_select는 무엇을 하나요? 서버 선택 목록을 미리 고른 서버 하나로 고정해요. 그래서 특정 커뮤니티용 초대 링크가 실수로 다른 곳에 봇을 추가하는 데 쓰이지 않아요.
봇이 버튼만 쓴다면 applications.commands가 필요한가요? 이미 보낸 메시지의 버튼만 쓴다면 엄격하게는 필요하지 않아요. 하지만 슬래시 명령어가 한 번이라도 관여하는 순간 필요해요.
나중에 권한 숫자를 바꾸면 이전 설치에도 권한이 추가되나요? 아니요. 이미 초대를 승인한 서버는 그 당시 부여된 것을 그대로 유지해요. 링크를 바꾸면 앞으로의 초대에만 영향을 줘요. 기존 설치는 더 많은 권한을 얻으려면 다시 초대되어 재승인되어야 해요.
scope=bot만으로 충분한가요? 봇이 들어오기에는 충분하지만, applications.commands가 함께 없으면 슬래시 명령어는 나타나지 않아요.
디스코드는 관리자 권한에 왜 그렇게 큰 경고를 띄우나요? 서버 전체에 대한 제한 없는 접근을 요청하기 때문이에요. 봇 초대가 요청할 수 있는 가장 위험한 단일 권한이에요.
내 봇의 초대를 설정하려고 하시나요? 먼저 디스코드 애플리케이션 만들기 가이드를 보고, 그 뒤에 있는 코드를 직접 작성하지 않으려면 커스텀 봇 문서를 읽어 보세요.