고객 지원 대기열 디스코드 봇 만들기

문의가 적을 때는 누가 먼저 왔는지 채널만 훑어도 보입니다.

문제가 시작되는 시점은 문의 수보다 담당자 수가 늘어날 때입니다.

이 글에서는 문의자를 큐에 넣고, 담당자가 다음 문의를 하나씩 꺼내는 가장 작은 대기열 구조를 만들어서 순서가 왜 자주 꼬이는지부터 정리합니다.

1. 문의 수보다 담당자 수가 늘 때 필요해진다

아래 상황이 보이면 대기열이 도움이 됩니다.

• 문의가 동시에 여러 개 들어온다
• 담당 운영진이 둘 이상이다
• 처리 순서를 자주 놓친다
• 먼저 온 문의보다 나중 문의가 먼저 답변되는 일이 반복된다

문의 입구 구조가 아직 흐릿하다면 디스코드 문의 동선 설계법부터 먼저 맞춰야 합니다.

2. 대기열 채널과 역할 값 정리

DISCORD_TOKEN=여기에_봇_토큰
GUILD_ID=테스트_서버_ID
QUEUE_CHANNEL_ID=문의대기열_채널_ID
SUPPORT_ROLE_ID=문의담당_역할_ID

대기열 상태를 임베드로 보여 줄 채널 하나를 따로 두면 관리가 쉽습니다.

3. 문의 순서를 줄 세우는 코드

import os
from collections import deque

import discord
from discord import app_commands
from dotenv import load_dotenv

load_dotenv()

TOKEN = os.getenv("DISCORD_TOKEN")
GUILD_ID = int(os.getenv("GUILD_ID"))
QUEUE_CHANNEL_ID = int(os.getenv("QUEUE_CHANNEL_ID"))
SUPPORT_ROLE_ID = int(os.getenv("SUPPORT_ROLE_ID"))

intents = discord.Intents.default()
client = discord.Client(intents=intents)
tree = app_commands.CommandTree(client)
guild = discord.Object(id=GUILD_ID)
support_queue: deque[int] = deque()


async def send_queue_status(guild_obj: discord.Guild):
    channel = guild_obj.get_channel(QUEUE_CHANNEL_ID)
    if not isinstance(channel, discord.TextChannel):
        return

    if support_queue:
        lines = [f"{index + 1}. <@{user_id}>" for index, user_id in enumerate(support_queue)]
        description = "\n".join(lines)
    else:
        description = "현재 대기 중인 문의가 없습니다."

    embed = discord.Embed(title="고객 지원 대기열", description=description, color=discord.Color.orange())
    await channel.send(embed=embed)


@client.event
async def on_ready():
    await tree.sync(guild=guild)
    print(f"로그인 성공: {client.user}")


@tree.command(name="대기열추가", description="본인을 문의 대기열에 추가합니다.", guild=guild)
async def enqueue(interaction: discord.Interaction):
    if interaction.user.id in support_queue:
        await interaction.response.send_message("이미 대기열에 등록되어 있습니다.", ephemeral=True)
        return

    support_queue.append(interaction.user.id)
    await interaction.response.send_message("대기열에 등록되었습니다.", ephemeral=True)
    if interaction.guild:
        await send_queue_status(interaction.guild)


@tree.command(name="다음문의", description="대기열에서 다음 문의자를 호출합니다.", guild=guild)
async def dequeue(interaction: discord.Interaction):
    if interaction.guild is None:
        await interaction.response.send_message("서버 안에서만 사용할 수 있습니다.", ephemeral=True)
        return

    member = interaction.guild.get_member(interaction.user.id)
    support_role = interaction.guild.get_role(SUPPORT_ROLE_ID)
    if member is None or support_role is None or support_role not in member.roles:
        await interaction.response.send_message("문의 담당 역할이 있는 사용자만 실행할 수 있습니다.", ephemeral=True)
        return

    if not support_queue:
        await interaction.response.send_message("대기 중인 문의가 없습니다.", ephemeral=True)
        return

    next_user_id = support_queue.popleft()
    await interaction.response.send_message(f"다음 문의자: <@{next_user_id}>")
    await send_queue_status(interaction.guild)


@tree.command(name="대기열보기", description="현재 문의 대기열을 봅니다.", guild=guild)
async def show_queue(interaction: discord.Interaction):
    if support_queue:
        lines = [f"{index + 1}. <@{user_id}>" for index, user_id in enumerate(support_queue)]
        message = "\n".join(lines)
    else:
        message = "현재 대기 중인 문의가 없습니다."

    await interaction.response.send_message(message, ephemeral=True)


if not TOKEN:
    raise ValueError("DISCORD_TOKEN 값이 없습니다.")

client.run(TOKEN)

이 구조는 메모리 기반 큐라 재시작하면 대기열이 비워집니다.
대신 작동 원리를 잡고 운영 흐름을 확인하기에는 충분합니다.

4. 접수부터 호출까지 한 번 돌려 보기

python main.py

그다음 아래처럼 확인합니다.

1. 일반 유저가 /대기열추가 실행
2. 문의 담당자가 /대기열보기로 순서 확인
3. 담당자가 /다음문의 실행
4. 큐에서 첫 번째 유저가 빠지는지 확인

5. 순번 관리에서 흔히 어긋나는 부분

• 같은 유저가 중복으로 계속 들어가는 경우 큐 등록 전 중복 체크가 빠졌을 수 있습니다.
• 담당자가 다음문의를 못 쓰는 경우 역할 ID가 틀렸거나 테스트 계정에 역할이 안 붙어 있을 수 있습니다.
• 대기열 메시지가 너무 많이 쌓이는 경우 상태 임베드를 수정하지 않고 새 메시지로만 쌓는 구조이기 때문입니다.
  
  운영 단계에서는 마지막 상태 메시지를 수정하는 식으로 바꿔야 합니다.

6. 티켓과 붙여야 진짜 운영 도구가 된다

대기열만 따로 두면 실제 문의 내용과 분리돼 어색할 수 있습니다.

보통은 티켓 생성 직후 자동 등록하거나, 접수 메시지와 대기열 메시지를 같이 갱신하는 구조로 가야 운영진이 덜 헤맵니다.

티켓 구조가 먼저 필요하다면 티켓 디스코드 봇 만들기과 디스코드 티켓 카테고리 설계법을 같이 보면 됩니다.

7. 운영 단계에서는 상태 메시지와 담당자 배정도 같이 본다

대기열이 실제로 중요해지면 메모리 저장만으로는 부족합니다.

재시작 뒤에도 순서가 유지되게 파일 저장이나 DB를 붙여야 합니다.

또 하나 자주 놓치는 부분은 상태 메시지를 계속 새로 보내서 채널이 지저분해지는 문제입니다.

운영 단계에서는 마지막 대기열 메시지를 수정하거나, 문의를 잡아 간 운영진 이름까지 같이 남기는 쪽이 훨씬 실용적입니다.

8. 문의량보다 운영팀 규모를 먼저 본다

문의가 많아도 담당자가 한 명이면 복잡한 큐 기능보다 기본 응답 템플릿과 처리 시간 공지가 더 중요할 때가 많습니다.

반대로 담당자가 여러 명이면 큐 번호 하나만 있어도 체감 정리가 크게 좋아집니다.

9. 상시 운영이라면 결국 서버에 올려야 한다

대기열은 문의가 들어오는 순간부터 의미가 있습니다.

개발 PC를 끄면 순서 관리도 같이 끊깁니다.

실제 운영용으로 옮길 때는 24시간 디스코드 봇 무료 호스팅, 디스호스트처럼 계속 켜져 있는 환경을 같이 준비해야 합니다.

10. 대기열 뒤에는 접수 양식과 분류가 붙어야 한다

문의 순서를 잡았다면 다음에는 접수 양식과 처리 분류를 붙여서 운영 부담을 더 줄일 수 있습니다.

입구 설계와 티켓 흐름을 함께 다듬을 때는 디스코드 문의 동선 설계법과 티켓 디스코드 봇 만들기을 이어서 보면 흐름이 잡힙니다.