디스코드 봇 개발 서버

봇을 만드는 서버는 쓰는 사람과 만드는 사람이 같은 곳에 있습니다. 그래서 오류 제보와 코드 이야기가 섞이기 쉬워요. 이 설계도가 개발과 문의를 다른 카테고리로 뗀 이유입니다.

코드 채널에 토큰이 박힌 코드가 올라옵니다

개발 카테고리에 코드·라이브러리·배포가 있고, 코드가 포럼입니다.

이 서버에서 일어나는 가장 큰 사고입니다. 「이 코드가 왜 안 되나요」 하고 붙여넣은 코드 안에 봇 토큰이 그대로 들어 있는 경우요.

토큰이 새면 그 봇이 들어가 있는 서버 전부가 남의 손에 넘어갑니다.

규칙에 앞줄로 적어두세요.

• 토큰·API 키를 지우고 올리기
• 실수로 올렸으면 글을 지우는 것보다 먼저 토큰을 재발급하기
• 설정값은 .env 로 빼고 그 파일은 올리지 않기

글을 지워도 이미 본 사람이 있습니다. 순서가 중요합니다 — 재발급이 먼저입니다.

활성화봇의 /검열 에 토큰 형태 문구를 걸어두시면 올라오기 전에 막힙니다. 완벽하진 않지만 실수 대부분이 걸립니다.

오류 제보에 무엇을 적을지 정해두세요

문의 카테고리에 오류제보·기능요청·faq가 있고, 오류제보가 포럼입니다.

「안 돼요」만 적힌 제보는 아무것도 할 수 없습니다.

제보 글에 이 넷이 없으면 되돌려 보내는 편이 낫습니다.

• 무슨 명령어를 썼는지
• 무엇을 기대했고 무엇이 일어났는지
• 언제인지
• 서버 id (알아내야 로그를 찾습니다)

그런데 개인 메시지 내용이나 남의 계정 정보는 적지 말라고 같이 적어두세요. 제보하려다 남의 정보를 공개 채널에 올리는 일이 생깁니다.

로그가 있어야 제보를 확인할 수 있습니다

제보를 받아도 그 시각에 무슨 일이 있었는지 볼 수 없으면 추측만 하게 됩니다.

/로그채널 을 관리 카테고리의 로그 채널에 걸어두시면 서버에서 오간 기록이 한곳에 쌓입니다. 설정은 로그 채널 세팅 영상에 나옵니다.

다만 이건 디스코드 서버 쪽 기록입니다. 봇 내부 오류 로그는 봇을 돌리는 쪽에서 따로 남기셔야 합니다. 둘을 같은 것으로 생각하면 제보를 놓칩니다.

기능요청은 받는 것보다 닫는 것이 어렵습니다

기능요청 채널은 금방 쌓이고, 대부분 답이 안 달립니다. 그러면 사람들이 요청을 그만둡니다.

상태를 표시하는 규칙을 하나 두세요. 검토 중 / 만들기로 함 / 안 하기로 함 정도면 충분합니다.

「안 함」을 말하는 게 제일 중요합니다. 이유를 한 줄 붙여 닫으면 같은 요청이 다시 안 옵니다. 답이 없으면 계속 옵니다.

faq 채널을 먼저 채우세요

오류 제보의 절반은 오류가 아니라 설정을 안 한 것입니다. 권한이 부족하거나 역할 순서가 잘못된 경우요.

그걸 faq에 미리 적어두시면 제보가 눈에 띄게 줄어듭니다.

그리고 제보를 닫을 때마다 그 답을 faq로 옮기는 습관을 들이세요. 같은 질문이 세 번 오면 그건 faq에 없는 항목입니다.

배포 채널과 업데이트 채널은 독자가 다릅니다

배포 채널은 만드는 사람이 보는 곳입니다. 어디에 올렸고 무엇이 바뀌었는지요.

봇 카테고리의 업데이트 채널은 쓰는 사람이 보는 곳입니다. 같은 변경이라도 쓰는 말이 달라야 합니다.

둘을 합치면 쓰는 사람이 못 읽습니다. 「의존성 올림」은 쓰는 사람에게 아무 뜻이 없습니다.

기여자에게 무엇을 열어줄지 미리 정하세요

역할에 메인개발·기여자·유저·신입이 있습니다.

기여자 역할을 만들어두신 건 좋습니다. 다만 무엇을 할 수 있는 역할인지를 적어두셔야 합니다.

코드 포럼에 답하는 것까지인지, 배포 채널을 보는 것까지인지요. 이게 흐리면 기여자가 어디까지 손대도 되는지 몰라서 아무것도 안 합니다.

후원 채널을 여실 거면 후원이 기능 요청 우선권이 아니라는 것을 적어두세요. 이걸 안 적으면 후원한 사람이 당연히 그럴 거라 생각합니다.

코드 채널에 토큰 규칙을 붙이는 것이 이 서버에서 제일 먼저 할 일입니다.