보안 모델 및 DM Pairing 완벽 가이드

Discord 봇의 DM 보안 정책과 페어링 시스템을 체계적으로 학습합니다. dmPolicy 설정부터 allowlist 관리, 페어링 코드 구현까지 안전한 봇 운영의 모든 것을 다룹니다.

---

목차

1. DM_보안의_중요성
2. dmPolicy_설정_옵션
3. 페어링_코드_시스템_구현
4. allowlist_관리_방법
5. src_security_코드_분석
6. 안전한_봇_운영하기

---

1. DM 보안의 중요성

어느 날 김개발 씨가 운영하는 Discord 봇에 이상한 일이 벌어졌습니다. 낯선 사용자가 봇에게 DM을 보내 민감한 정보를 요청하고 있었습니다.

"잠깐, 이 사람이 누구지? 우리 서버 멤버도 아닌데?" 김개발 씨는 식은땀을 흘리며 로그를 확인했습니다.

DM 보안은 봇이 개인 메시지를 통해 받는 요청을 어떻게 처리할지 결정하는 핵심 정책입니다. 마치 회사 건물의 출입 통제 시스템과 같습니다.

아무나 들어올 수 있다면 보안 사고가 발생하듯, 봇도 신뢰할 수 있는 사용자만 접근하도록 해야 합니다.

다음 코드를 살펴봅시다.

// DM 메시지 수신 시 보안 검증 로직
client.on('messageCreate', async (message) => {
  // DM 채널인지 확인
  if (!message.guild) {
    // 보안 정책에 따른 처리
    const isAllowed = await securityManager.checkDMAccess(message.author.id);

    if (!isAllowed) {
      // 허용되지 않은 사용자의 DM 차단
      await message.reply('인증되지 않은 사용자입니다. 먼저 페어링을 진행해주세요.');
      return;
    }

    // 정상 처리 진행
    await handleDMCommand(message);
  }
});

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 회사에서 사용하는 Discord 봇을 관리하게 되었는데, 어느 날 낯선 사용자로부터 이상한 DM이 들어오기 시작했습니다.

"관리자 권한 좀 주세요", "서버 정보 알려주세요" 같은 요청이었습니다. 선배 개발자 박시니어 씨가 상황을 보더니 심각한 표정을 지었습니다.

"이건 큰 문제가 될 수 있어요. 봇에 DM 보안 정책이 없으면 아무나 봇을 조종할 수 있거든요." 그렇다면 DM 보안이란 정확히 무엇일까요?

쉽게 비유하자면, DM 보안은 마치 아파트의 인터폰 시스템과 같습니다. 방문자가 초인종을 누르면 우리는 먼저 누구인지 확인합니다.

모르는 사람이라면 문을 열어주지 않죠. 이처럼 봇도 DM으로 명령이 들어오면 먼저 "이 사람이 신뢰할 수 있는 사용자인가?"를 확인해야 합니다.

DM 보안이 없던 시절에는 어땠을까요? 개발자들은 모든 DM 요청을 무조건 처리했습니다.

봇이 관리자 명령어를 가지고 있다면, 악의적인 사용자가 DM으로 해당 명령을 실행할 수 있었습니다. 더 큰 문제는 봇이 여러 서버에 참여하고 있을 때였습니다.

한 서버의 일반 사용자가 다른 서버의 관리 명령을 실행할 수 있는 심각한 보안 구멍이 생기는 것입니다. 바로 이런 문제를 해결하기 위해 DM 보안 정책이 등장했습니다.

DM 보안 정책을 사용하면 신뢰할 수 있는 사용자만 봇과 상호작용할 수 있습니다. 또한 악의적인 요청을 사전에 차단할 수 있습니다.

무엇보다 봇이 예기치 않은 동작을 하는 것을 방지할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 message.guild 체크를 통해 이 메시지가 서버가 아닌 DM에서 온 것인지 확인합니다. guild가 없다면 개인 메시지라는 뜻입니다.

다음으로 securityManager.checkDMAccess를 호출하여 해당 사용자가 허용 목록에 있는지 검증합니다. 허용되지 않은 사용자라면 안내 메시지를 보내고 처리를 중단합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 사내 봇을 운영한다고 가정해봅시다.

직원들만 봇을 사용할 수 있어야 합니다. DM 보안 정책을 적용하면 직원 ID 목록에 있는 사용자만 봇과 대화할 수 있고, 외부 사용자의 접근은 원천 차단됩니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 보안 검증을 클라이언트 측에서만 하는 것입니다.

이렇게 하면 우회가 가능합니다. 따라서 서버 측(봇 코드)에서 반드시 검증해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 바로 DM 보안 정책을 구현하기 시작했습니다.

"이제 더 이상 불청객 걱정은 없겠네요!"

실전 팁

💡 - DM 보안 검증은 반드시 명령 처리 전에 수행하세요

• 차단된 사용자에게는 친절한 안내 메시지를 제공하세요

---

2. dmPolicy 설정 옵션

김개발 씨가 DM 보안의 중요성을 깨달은 후, 다음 질문이 떠올랐습니다. "그런데 정책을 어떻게 설정하지?

모든 DM을 막으면 정상 사용자도 불편할 텐데..." 박시니어 씨가 웃으며 말했습니다. "좋은 질문이에요.

dmPolicy에는 여러 옵션이 있어요."

dmPolicy는 봇의 DM 처리 방식을 결정하는 설정값입니다. 마치 건물 보안 등급을 설정하는 것처럼, 상황에 맞는 적절한 정책을 선택할 수 있습니다.

none, allowlist, pairing 등 다양한 옵션으로 보안 수준을 조절합니다.

다음 코드를 살펴봅시다.

// dmPolicy 설정 객체
const securityConfig = {
  dmPolicy: 'pairing',  // 'none' | 'allowlist' | 'pairing' | 'disabled'

  policyOptions: {
    none: {
      description: '모든 DM 허용 (보안 없음)',
      riskLevel: 'high'
    },
    allowlist: {
      description: '허용 목록 사용자만 DM 가능',
      riskLevel: 'low'
    },
    pairing: {
      description: '페어링 코드로 인증된 사용자만 허용',
      riskLevel: 'very-low'
    },
    disabled: {
      description: '모든 DM 차단',
      riskLevel: 'none'
    }
  }
};

김개발 씨는 보안 정책을 설정하려고 문서를 펼쳤습니다. 그런데 옵션이 여러 개 있어서 어떤 것을 선택해야 할지 고민이 되었습니다.

개발팀 회의에서 이 문제를 꺼냈더니, 박시니어 씨가 화이트보드 앞으로 나섰습니다. "dmPolicy는 크게 네 가지 옵션이 있어요.

각각 언제 쓰면 좋은지 설명해 드릴게요." 첫 번째 옵션인 none은 보안을 적용하지 않는 것입니다. 쉽게 말해 문을 활짝 열어두는 것과 같습니다.

개발 중이거나 테스트 환경에서는 편리할 수 있지만, 실제 운영 환경에서는 절대 사용하면 안 됩니다. 아무나 봇에게 명령을 내릴 수 있기 때문입니다.

두 번째 옵션인 allowlist는 허용 목록 방식입니다. 마치 VIP 리스트를 가진 클럽과 같습니다.

미리 등록된 사용자 ID만 입장할 수 있습니다. 팀 규모가 작고 멤버가 자주 바뀌지 않는 경우에 적합합니다.

관리자가 직접 목록을 관리해야 하므로 대규모 서비스에는 다소 번거로울 수 있습니다. 세 번째 옵션인 pairing은 페어링 코드 방식입니다.

이것은 마치 블루투스 기기 연결과 같습니다. 사용자가 서버에서 페어링 코드를 발급받고, 봇에게 DM으로 해당 코드를 전송하면 인증이 완료됩니다.

자동화된 인증 시스템이 필요한 중규모 이상의 서비스에 적합합니다. 네 번째 옵션인 disabled는 모든 DM을 차단합니다.

봇이 DM 기능 자체를 필요로 하지 않는 경우에 사용합니다. 서버 채널에서만 동작하는 봇이라면 이 옵션으로 불필요한 DM 요청을 원천 차단할 수 있습니다.

위의 코드를 살펴보면, securityConfig 객체에서 현재 정책을 pairing으로 설정한 것을 볼 수 있습니다. 또한 각 정책에 대한 설명과 위험 수준을 명시하여 관리자가 쉽게 이해할 수 있도록 했습니다.

박시니어 씨가 덧붙였습니다. "우리 회사는 직원이 50명 정도 되고, 새 입사자도 종종 들어오니까 pairing 방식이 적합해요.

자동으로 인증을 처리할 수 있거든요." 김개발 씨가 고개를 끄덕였습니다. "그렇군요.

그럼 allowlist는 인원이 고정된 소규모 팀에 좋겠네요?" "맞아요. 예를 들어 5명짜리 스타트업 초기 팀이라면 allowlist로 충분해요.

하지만 회사가 성장하면 pairing으로 전환하는 게 좋습니다." 정책을 선택할 때 가장 중요한 것은 현재 상황에 맞는 적절한 수준을 찾는 것입니다. 너무 느슨하면 보안 사고가 발생하고, 너무 엄격하면 정상 사용자가 불편을 겪습니다.

실전 팁

💡 - 개발 환경에서도 가급적 allowlist 이상의 보안 정책을 사용하세요

• 정책 변경 시 기존 사용자에게 사전 공지를 해주세요

---

3. 페어링 코드 시스템 구현

이제 김개발 씨는 pairing 방식을 구현하기로 결정했습니다. 하지만 막상 코드를 작성하려니 막막했습니다.

"페어링 코드를 어떻게 생성하고, 어디에 저장하고, 만료는 어떻게 처리하지?" 다행히 박시니어 씨가 이미 작성해둔 코드가 있었습니다.

페어링 코드 시스템은 사용자 인증을 자동화하는 메커니즘입니다. 서버에서 임시 코드를 발급하고, 사용자가 DM으로 해당 코드를 제출하면 인증이 완료됩니다.

마치 은행의 OTP 인증과 비슷한 원리로 동작합니다.

다음 코드를 살펴봅시다.

const crypto = require('crypto');

class PairingManager {
  constructor() {
    this.pendingCodes = new Map();  // 대기 중인 페어링 코드
    this.CODE_EXPIRY = 5 * 60 * 1000;  // 5분 만료
  }

  // 6자리 페어링 코드 생성
  generateCode(userId) {
    const code = crypto.randomInt(100000, 999999).toString();
    this.pendingCodes.set(code, {
      userId,
      createdAt: Date.now(),
      expiresAt: Date.now() + this.CODE_EXPIRY
    });
    return code;
  }

  // 코드 검증 및 페어링 완료
  verifyCode(code, requesterId) {
    const pending = this.pendingCodes.get(code);
    if (!pending) return { success: false, reason: 'INVALID_CODE' };
    if (Date.now() > pending.expiresAt) return { success: false, reason: 'EXPIRED' };
    if (pending.userId !== requesterId) return { success: false, reason: 'USER_MISMATCH' };

    this.pendingCodes.delete(code);
    return { success: true, userId: pending.userId };
  }
}

김개발 씨는 박시니어 씨가 작성한 코드를 열어보았습니다. 처음에는 복잡해 보였지만, 한 줄씩 따라가니 구조가 명확하게 보이기 시작했습니다.

"이 코드의 핵심은 PairingManager 클래스예요." 박시니어 씨가 설명을 시작했습니다. 먼저 pendingCodes라는 Map 객체가 있습니다.

이것은 발급된 코드와 관련 정보를 임시로 저장하는 공간입니다. 마치 은행 창구의 대기표 발급기와 같습니다.

번호표를 받으면 시스템에 기록되고, 순서가 되면 호출되는 것처럼요. CODE_EXPIRY는 코드의 유효 시간을 5분으로 설정합니다.

페어링 코드가 영원히 유효하다면 보안상 위험합니다. 누군가 코드를 탈취해서 나중에 사용할 수 있기 때문입니다.

그래서 적절한 만료 시간을 두는 것이 중요합니다. generateCode 메서드를 살펴보겠습니다.

crypto.randomInt를 사용하여 100000부터 999999 사이의 랜덤 숫자를 생성합니다. 이렇게 하면 항상 6자리 숫자가 만들어집니다.

생성된 코드는 사용자 ID, 생성 시간, 만료 시간과 함께 Map에 저장됩니다. verifyCode 메서드는 세 가지 검증을 수행합니다.

첫째, 코드가 존재하는지 확인합니다. 아무도 발급하지 않은 코드를 입력했다면 INVALID_CODE를 반환합니다.

둘째, 만료 시간을 확인합니다. 5분이 지났다면 EXPIRED를 반환합니다.

셋째, 사용자 ID가 일치하는지 확인합니다. A가 발급받은 코드를 B가 사용하려 하면 USER_MISMATCH를 반환합니다.

"잠깐요, 세 번째 검증이 왜 필요한 거예요?" 김개발 씨가 질문했습니다. 박시니어 씨가 답했습니다.

"좋은 질문이에요. 만약 악의적인 사용자가 다른 사람의 코드를 알아냈다고 가정해봐요.

사용자 ID 검증이 없다면 그 코드로 자신을 인증할 수 있어요. 하지만 이 검증이 있으면 코드를 발급받은 본인만 사용할 수 있죠." 검증이 성공하면 코드를 Map에서 삭제합니다.

한 번 사용된 코드는 재사용할 수 없도록 하는 것입니다. 이것을 일회용 코드 방식이라고 합니다.

실제 사용 흐름은 이렇습니다. 사용자가 서버 채널에서 "/페어링"이라고 입력합니다.

봇이 6자리 코드를 생성하여 해당 사용자에게만 보이는 메시지로 전달합니다. 사용자는 5분 내에 봇에게 DM으로 해당 코드를 전송합니다.

봇이 코드를 검증하고 성공하면 해당 사용자를 허용 목록에 추가합니다. 김개발 씨는 감탄했습니다.

"와, 정말 은행 OTP랑 똑같네요. 일정 시간 내에 사용해야 하고, 한 번 쓰면 사라지고."

실전 팁

💡 - 코드 만료 시간은 5분 이내로 설정하는 것이 안전합니다

• 코드 생성 시 crypto 모듈의 안전한 랜덤 함수를 사용하세요

---

4. allowlist 관리 방법

페어링 시스템이 완성되었지만, 김개발 씨에게 새로운 고민이 생겼습니다. "페어링에 성공한 사용자는 어디에 저장하지?

그리고 나중에 권한을 취소하려면 어떻게 해야 하지?" 이번에는 allowlist 관리 시스템을 구축할 차례입니다.

allowlist는 봇 사용이 허가된 사용자 목록입니다. 마치 호텔의 투숙객 명단과 같습니다.

체크인하면 명단에 추가되고, 체크아웃하면 명단에서 삭제됩니다. 파일 기반 또는 데이터베이스 기반으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

const fs = require('fs').promises;
const path = require('path');

class AllowlistManager {
  constructor(filePath = './data/allowlist.json') {
    this.filePath = filePath;
    this.allowlist = new Set();
  }

  async load() {
    try {
      const data = await fs.readFile(this.filePath, 'utf-8');
      const users = JSON.parse(data);
      this.allowlist = new Set(users);
    } catch (error) {
      this.allowlist = new Set();  // 파일 없으면 빈 목록
    }
  }

  async save() {
    const dir = path.dirname(this.filePath);
    await fs.mkdir(dir, { recursive: true });
    await fs.writeFile(this.filePath, JSON.stringify([...this.allowlist], null, 2));
  }

  async add(userId) {
    this.allowlist.add(userId);
    await this.save();
  }

  async remove(userId) {
    this.allowlist.delete(userId);
    await this.save();
  }

  has(userId) {
    return this.allowlist.has(userId);
  }
}

박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다. "allowlist 관리는 세 가지 핵심 기능이 필요해요.

저장, 불러오기, 그리고 실시간 조회죠." AllowlistManager 클래스는 이 세 가지 기능을 모두 담당합니다. 먼저 생성자를 보면, filePath로 저장 위치를 지정합니다.

기본값은 ./data/allowlist.json입니다. 그리고 allowlist라는 Set 객체를 생성합니다.

Set을 사용하는 이유가 있습니다. "왜 배열 대신 Set을 쓰나요?" 김개발 씨가 물었습니다.

"좋은 질문이에요. 배열에서 특정 사용자가 있는지 확인하려면 처음부터 끝까지 순회해야 해요.

사용자가 1000명이면 최악의 경우 1000번 비교해야 하죠. 하지만 Set은 해시 기반이라서 단번에 찾을 수 있어요.

성능 차이가 크답니다." load 메서드는 봇이 시작될 때 호출됩니다. 파일에서 사용자 ID 배열을 읽어와 Set으로 변환합니다.

파일이 없거나 읽기에 실패하면 빈 Set으로 시작합니다. 이렇게 하면 처음 실행할 때 오류가 발생하지 않습니다.

save 메서드는 목록이 변경될 때마다 호출됩니다. Set을 배열로 변환한 후 JSON 형식으로 파일에 저장합니다.

fs.mkdir에 recursive 옵션을 주어 디렉토리가 없으면 자동으로 생성합니다. add와 remove 메서드는 사용자를 추가하거나 삭제합니다.

중요한 점은 변경 후 즉시 save를 호출한다는 것입니다. 이렇게 하면 봇이 갑자기 종료되어도 변경 사항이 유실되지 않습니다.

has 메서드는 특정 사용자가 목록에 있는지 확인합니다. DM 메시지가 도착할 때마다 이 메서드로 접근 권한을 검사합니다.

Set의 has 메서드는 매우 빠르기 때문에 성능 걱정 없이 사용할 수 있습니다. 실제 운영에서는 데이터베이스를 사용하는 것이 더 좋습니다.

파일 기반은 동시 접근 시 문제가 생길 수 있고, 여러 서버에서 봇을 운영할 때 데이터 동기화가 어렵습니다. 하지만 소규모 봇이나 개인 프로젝트에서는 파일 기반으로 충분합니다.

박시니어 씨가 팁을 덧붙였습니다. "관리자가 실수로 자신을 목록에서 삭제하는 경우가 있어요.

그래서 저는 항상 슈퍼 관리자 ID를 환경 변수로 설정하고, 이 ID는 절대 삭제할 수 없도록 해둡니다." 김개발 씨는 고개를 끄덕였습니다. "안전장치가 필요하군요.

만약 모든 관리자가 잠겨버리면 정말 난감하겠어요."

실전 팁

💡 - 슈퍼 관리자는 환경 변수로 별도 관리하여 실수로 삭제되지 않도록 하세요

• 대규모 서비스는 Redis나 데이터베이스 사용을 권장합니다

---

5. src security 코드 분석

김개발 씨는 이제 개별 컴포넌트를 이해했습니다. 하지만 실제 프로젝트에서 이것들이 어떻게 조합되어 동작하는지 궁금했습니다.

"선배, 실제 프로덕션 코드는 어떻게 구성되어 있어요?" 박시니어 씨가 src/security 폴더를 열었습니다.

src/security 디렉토리는 보안 관련 모든 로직을 모아둔 곳입니다. 마치 경비실처럼, 출입 통제에 필요한 모든 장비와 명단이 한 곳에 있습니다.

SecurityManager가 전체를 관장하고, 하위 모듈들이 세부 기능을 담당합니다.

다음 코드를 살펴봅시다.

// src/security/index.js
const { PairingManager } = require('./pairing');
const { AllowlistManager } = require('./allowlist');
const { loadConfig } = require('./config');

class SecurityManager {
  constructor() {
    this.config = loadConfig();
    this.pairing = new PairingManager();
    this.allowlist = new AllowlistManager();
  }

  async initialize() {
    await this.allowlist.load();
    console.log(`보안 정책: ${this.config.dmPolicy}`);
    console.log(`허용된 사용자: ${this.allowlist.size}명`);
  }

  async checkDMAccess(userId) {
    switch (this.config.dmPolicy) {
      case 'disabled': return false;
      case 'none': return true;
      case 'allowlist':
      case 'pairing':
        return this.allowlist.has(userId);
      default: return false;
    }
  }

  async handlePairing(code, userId) {
    const result = this.pairing.verifyCode(code, userId);
    if (result.success) {
      await this.allowlist.add(userId);
    }
    return result;
  }
}

module.exports = { SecurityManager };

박시니어 씨가 폴더 구조를 보여주었습니다. src/security 아래에는 index.js, pairing.js, allowlist.js, config.js 파일이 있었습니다.

각 파일이 하나의 책임을 담당하는 구조입니다. "이렇게 분리하는 이유가 있어요.

단일 책임 원칙이라고 하는데, 각 파일이 하나의 일만 하면 코드가 깔끔해지고 유지보수가 쉬워져요." SecurityManager는 이 모든 것을 하나로 묶는 파사드(Facade) 역할을 합니다. 외부에서는 SecurityManager만 알면 되고, 내부 구현은 몰라도 됩니다.

마치 리모컨의 전원 버튼만 누르면 TV가 켜지는 것처럼요. 우리는 TV 내부 회로를 알 필요가 없습니다.

생성자에서 loadConfig를 호출하여 설정을 불러옵니다. 설정 파일에는 dmPolicy 값과 기타 보안 관련 옵션이 들어있습니다.

그 다음 PairingManager와 AllowlistManager 인스턴스를 생성합니다. initialize 메서드는 봇이 시작될 때 한 번 호출됩니다.

허용 목록을 파일에서 불러오고, 현재 설정 상태를 콘솔에 출력합니다. 이렇게 하면 봇이 시작될 때 보안 상태를 한눈에 확인할 수 있습니다.

checkDMAccess 메서드가 핵심입니다. switch 문으로 현재 정책에 따라 다르게 동작합니다.

disabled면 무조건 false를 반환하여 모든 DM을 차단합니다. none이면 무조건 true를 반환하여 모든 DM을 허용합니다.

allowlist나 pairing이면 허용 목록을 확인합니다. "여기서 재미있는 점이 있어요." 박시니어 씨가 말했습니다.

"allowlist와 pairing이 같은 로직을 사용하죠. 차이점은 사용자가 목록에 어떻게 추가되느냐예요.

allowlist는 관리자가 수동으로 추가하고, pairing은 코드 인증을 통해 자동으로 추가됩니다." handlePairing 메서드는 페어링 코드 검증과 목록 추가를 한 번에 처리합니다. 검증이 성공하면 자동으로 allowlist에 사용자를 추가합니다.

이렇게 하면 호출하는 쪽에서 별도로 목록 추가 로직을 작성할 필요가 없습니다. 김개발 씨가 코드를 보며 감탄했습니다.

"이 구조라면 나중에 새로운 인증 방식을 추가해도 SecurityManager만 수정하면 되겠네요." "맞아요. 예를 들어 OAuth 연동을 추가하고 싶다면, oauth.js 파일을 만들고 SecurityManager에서 불러오기만 하면 됩니다.

기존 코드는 건드릴 필요가 없어요."

실전 팁

💡 - 보안 관련 코드는 별도 디렉토리로 분리하여 관리하세요

• 파사드 패턴으로 복잡한 내부 로직을 감추면 사용이 편리해집니다

---

6. 안전한 봇 운영하기

드디어 모든 구현이 끝났습니다. 김개발 씨가 자신 있게 배포하려는 순간, 박시니어 씨가 말했습니다.

"잠깐, 코드만 잘 짜면 끝이 아니에요. 운영할 때 지켜야 할 보안 수칙이 있어요." 김개발 씨는 메모장을 꺼내 들었습니다.

안전한 봇 운영은 코드 구현 이후의 모든 보안 활동을 포함합니다. 마치 건물을 지은 후 경비 시스템을 운영하는 것처럼, 지속적인 모니터링과 관리가 필요합니다.

로깅, 감사, 정기 점검이 핵심 요소입니다.

다음 코드를 살펴봅시다.

// 보안 이벤트 로깅 시스템
class SecurityLogger {
  constructor() {
    this.events = [];
  }

  log(event) {
    const entry = {
      timestamp: new Date().toISOString(),
      type: event.type,
      userId: event.userId,
      action: event.action,
      result: event.result,
      details: event.details || null
    };

    this.events.push(entry);
    console.log(`[SECURITY] ${entry.type}: ${entry.action} by ${entry.userId} - ${entry.result}`);

    // 실패한 시도가 연속 5회 이상이면 경고
    if (event.result === 'FAILED') {
      this.checkSuspiciousActivity(event.userId);
    }
  }

  checkSuspiciousActivity(userId) {
    const recentFails = this.events
      .filter(e => e.userId === userId && e.result === 'FAILED')
      .slice(-5);

    if (recentFails.length >= 5) {
      console.warn(`[ALERT] 의심스러운 활동 감지: ${userId}`);
      // 관리자에게 알림 전송
      this.notifyAdmin(userId, recentFails);
    }
  }

  notifyAdmin(userId, events) {
    // 디스코드 웹훅이나 이메일로 알림
  }
}

박시니어 씨가 진지한 표정으로 말했습니다. "코드가 완벽해도 운영에서 실수하면 소용없어요.

제가 겪었던 실제 사례를 하나 들려줄게요." 몇 년 전, 한 회사에서 Discord 봇을 운영했습니다. 보안 코드는 잘 작성되어 있었지만, 로깅이 없었습니다.

어느 날 누군가 수백 번에 걸쳐 페어링 코드를 무작위로 입력하는 브루트포스 공격을 시도했습니다. 로그가 없었기 때문에 아무도 이 사실을 몰랐습니다.

운 좋게 코드가 맞지 않아 침입에는 실패했지만, 나중에 알게 되었을 때 모두 놀랐습니다. 그래서 SecurityLogger가 중요합니다.

모든 보안 이벤트를 기록합니다. 언제, 누가, 무슨 행동을 했고, 결과가 어땠는지 상세히 남깁니다.

이 로그는 문제가 발생했을 때 원인을 추적하는 데 필수적입니다. checkSuspiciousActivity 메서드는 자동 감지 시스템입니다.

같은 사용자가 5번 연속 실패하면 의심스러운 활동으로 간주합니다. 정상적인 사용자라면 한두 번 실수할 수 있지만, 5번 연속 실패는 공격일 가능성이 높습니다.

"그런데 만약 정말 사용자가 5번 실수한 거라면요?" 김개발 씨가 물었습니다. "좋은 질문이에요.

그래서 자동 차단 대신 알림만 보내는 겁니다. 관리자가 상황을 확인하고 판단할 수 있도록요.

무조건 차단하면 정상 사용자가 피해를 볼 수 있거든요." 운영 시 지켜야 할 핵심 수칙을 정리해보겠습니다. 첫째, 정기적인 허용 목록 점검입니다.

퇴사자나 권한이 변경된 사용자를 주기적으로 정리해야 합니다. 한 달에 한 번은 전체 목록을 검토하세요.

둘째, 토큰 관리입니다. 봇 토큰은 절대 코드에 하드코딩하면 안 됩니다.

환경 변수나 비밀 관리 서비스를 사용하세요. 토큰이 유출되면 즉시 재발급해야 합니다.

셋째, 권한 최소화입니다. 봇에게 필요한 권한만 부여하세요.

관리자 권한이 필요 없다면 주지 마세요. 만약 봇이 침해당해도 피해를 최소화할 수 있습니다.

넷째, 정기 업데이트입니다. Discord.js나 기타 라이브러리에 보안 패치가 나오면 빠르게 적용하세요.

알려진 취약점을 방치하면 공격에 노출됩니다. 김개발 씨는 메모를 끝마치며 말했습니다.

"생각보다 신경 쓸 게 많네요. 코드 작성만큼 운영도 중요하다는 걸 깨달았어요." 박시니어 씨가 미소 지었습니다.

"맞아요. 보안은 한 번 하고 끝나는 게 아니에요.

지속적인 관심과 노력이 필요하죠. 하지만 이렇게 체계를 잡아두면 훨씬 수월해집니다."

실전 팁

💡 - 모든 보안 이벤트는 최소 90일간 보관하세요

• 의심 활동 알림은 슬랙이나 디스코드 웹훅으로 실시간 전송하면 좋습니다
• 분기별로 보안 정책 전체를 리뷰하는 시간을 가지세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!