회사 부서용 서버 리뉴얼

회사 서버에서 디스코드가 사내 메신저와 갈리는 지점은 결재와 근태입니다. 이 설계도에 그 둘이 각각 카테고리로 있는 만큼, 시작 전에 정해야 할 것이 있습니다.

먼저 — 근태를 디스코드로 관리해도 되는지 확인하세요

근태 기록은 법적 효력이 있는 자료입니다. 근로시간 산정과 급여, 분쟁이 났을 때 근거가 되는 기록이에요.

그런데 디스코드는 회사가 통제하는 시스템이 아닙니다. 계정이 정지되거나 서버가 사라지면 기록도 같이 사라지고, 되살릴 방법이 없습니다.

그래서 이렇게 쓰시길 권합니다.

• 공식 기록은 회사 근태 시스템에 남기세요
• 디스코드 근태 채널은 「지금 자리에 있는지」 공유용으로만 쓰세요
• 휴가 채널도 신청이 아니라 공유입니다. 정식 신청은 회사 절차로요

이 구분을 채널 설명에 적어두시면 나중에 문제가 안 생깁니다.

결재 카테고리도 같은 기준입니다

결재는 증빙이 남아야 합니다. 디스코드 메시지는 수정하거나 지울 수 있어서 증빙으로 쓰기 어렵습니다.

결재현황 채널은 어디까지 갔는지 보는 용도로 두시고, 실제 결재는 회사 시스템에서 진행하세요.

이렇게 쓰면 오히려 값어치가 큽니다. 결재가 며칠째 막혀 있는지 한눈에 보이거든요. 그게 사내 시스템에서는 잘 안 보입니다.

양식 채널에는 링크만 두세요. 파일을 올리면 버전이 갈립니다.

요청이 포럼인 것을 살리세요

업무 카테고리에 요청·업무공유·현안이 있고, 요청이 포럼입니다.

부서 간 요청은 한 건이 글 하나여야 합니다. 요청하고, 되묻고, 처리되고, 확인되는 흐름이 남아야 해요.

채팅으로 받으면 「그거 어떻게 됐죠」가 반복됩니다.

태그를 접수 / 진행중 / 완료 / 보류로 만드세요. 목록만 훑어도 어느 건이 멈춰 있는지 드러납니다. 부서 간 요청에서 이만큼 바로 쓰이는 장치가 없습니다.

현안 채널을 업무공유와 나눈 것

업무공유는 평소 진행 상황이고 현안은 지금 터진 것입니다.

섞이면 급한 일이 일상 보고에 묻힙니다.

현안 채널에만 알림을 켜두게 안내하세요. 나머지는 꺼둬도 됩니다. 그래야 알림이 실제로 작동합니다.

회의록이 포럼인 것

회의 카테고리에 회의록·일정·안건이 있고, 회의록이 포럼입니다.

회의 한 건에 안건·결정·후속 조치가 붙습니다. 글 하나로 서야 나중에 찾습니다.

결정된 것을 반드시 적게 하세요. 회의록이 「무슨 말이 오갔나」만 적혀 있으면 아무도 안 봅니다. 「누가 언제까지 무엇을」이 있어야 합니다.

안건 채널은 회의 전에 모으는 자리입니다. 미리 올라와 있으면 회의 시간이 절반으로 줍니다.

근태와 결재는 기록으로 남아야 합니다

근태와 결재는 기억이 아니라 기록으로 남아야 합니다. 활성화봇이 그 기록을 만듭니다.

/로그채널 로 입장·퇴장과 역할 변경을 남길 채널을 지정해두시면, 누가 언제 서버에 들어왔고 언제 부서가 바뀌었는지가 저절로 쌓입니다. 어느 종류를 어디에 꽂는지는 로그 채널 세팅 영상에 나옵니다.

다만 채팅 로그는 켜지 마세요. 직원 대화가 전부 기록되는 것은 부담이 크고, 회사에 따라 근로자 감시 문제가 될 수 있습니다. 입장·퇴장과 역할 변경까지가 적당합니다.

초대 링크와 퇴사자 처리를 정해두세요

회사 서버에서 가장 흔한 사고입니다.

초대 링크 하나가 새면 바깥 사람이 사내 대화를 봅니다. 그리고 퇴사한 사람이 계속 남아 있는 경우가 놀랄 만큼 많습니다.

• 초대 링크는 기한제로 만드세요 (기본 7일 만료를 「무제한」으로 바꾸지 마세요)
• 퇴사 절차에 「디스코드 서버 내보내기」를 넣으세요
• 로그 채널이 있으면 누가 아직 남아 있는지 확인됩니다

역할 셋의 권한을 갈라 두세요

역할에 부서장·팀장·사원이 있습니다.

결재와 근태 채널은 부서장·팀장에게만 보이게 두는 것이 맞습니다. 사원끼리 서로의 휴가 신청을 다 보면 불편해집니다.

그리고 서버 설정과 채널 삭제는 한 사람만 갖고 계세요. 부서 서버는 실수 한 번으로 기록이 통째로 사라집니다.

공식 기록을 디스코드에 의존하지 않는 것이 첫 원칙입니다.