API 속도 제한 및 보안 필터링

봇을 안정적으로 운영하기 위해서는 외부 사용자들의 악의적인 도배 공격이나 부적절한 특수 문자 유입을 안전하게 차단할 수 있는 API 레이트 리밋(Rate Limit) 제어와 입력 필터링 코드 작성이 필수입니다.

1. 디스코드 API 속도 제한 (Rate Limit) 우회

디스코드 API 게이트웨이는 단일 IP 및 봇 토큰 단위로 초당 요청 처리 한계치가 엄격히 정해져 있습니다. 이 규칙을 어기고 메시지 발송 루프를 고속 가동하면 429 Too Many Requests 상태 코드가 보고되며 봇 IP가 일시적으로 블랙리스트 격리됩니다.

• 메시지 전송 일괄 결합(Batching): 수십 명의 전적을 동시에 뿌려야 한다면, 한 통씩 개별 메시지로 보내지 말고 하나의 임베드 필드 목록에 병합하여 1회에 발송하십시오.
• 슬립 타임아웃 주입: 반복 루프를 구동할 땐 최소 0.5초에서 1초 이상의 인위적인 스레드 대기(Sleep/Await) 구문을 주입해 지연을 걸어주어야 안전합니다.

2. 사용자 입력 문자열 검증 및 SQL 인젝션 예방

사용자가 입력 창이나 명령어 파라미터로 넘겨주는 데이터는 항상 오염되어 있다고 가정하고 철저히 검증 필터를 적용해야 합니다.

• SQL prepared statement 의무화: SQLite 등 DB에 사용자 닉네임이나 메모 내용을 저장할 때 문자열 더하기(+) 방식을 사용하면 악의적 쿼리가 삽입되어 데이터가 파괴될 수 있습니다. 반드시 바인딩 변수 파라미터(? 또는 플레이스홀더)를 적용하십시오.
• 특수 코드 이스케이프: 사용자 문자열을 터미널 명령어 인자로 직접 주입하여 child_process.exec()로 실행시키는 구성은 백도어 노출을 의미하므로 절대 금지해야 합니다.

3. 이벤트 리스너 중첩 등록 금지 (메모리 누수 원인)

디스코드 개발 입문자들의 흔한 오류 중 하나는 이벤트 리스너 내부에 또 다른 리스너 함수를 네스팅 정의하는 구조입니다.

잘못된 설계 예시 (안 좋은 예)

client.on('messageCreate', (message) => {
  if (message.content === '!인증') {
    // 메시지 수신 함수 안에서 또 다른 리스너를 계속해서 대여 등록합니다.
    // 사용자가 !인증을 입력할 때마다 리스너가 메모리에 중복 등록되어 심각한 메모리 누수와 중복 응답 현상이 촉발됩니다.
    client.on('messageCreate', (reply) => {
      if (reply.content === '동의') {
        message.reply('인증이 끝났습니다.');
      }
    });
  }
});

올바른 설계 예시 (좋은 예)

이러한 후속 대기 상태는 임시 이벤트 리스너 누적 방지를 지원하는 Collector 모듈을 이용해 설계해야 합니다.

client.on('messageCreate', async (message) => {
  if (message.content === '!인증') {
    message.reply('동의 여부를 입력해 주세요. (제한시간 10초)');
    
    // 특정 멤버의 후속 답변 1개만 수집하는 콜렉터를 정의합니다.
    const filter = m => m.author.id === message.author.id;
    const collector = message.channel.createMessageCollector({ filter, time: 10000, max: 1 });
    
    collector.on('collect', m => {
      if (m.content === '동의') {
        m.reply('인증이 정상 완료되었습니다.');
      }
    });
  }
});