사내 개발팀 서버

사내 개발팀을 디스코드로 굴릴 때 가장 흔한 실패는 모든 이야기가 한 채널에서 벌어지는 것입니다. 장애 대응과 코드 리뷰와 점심 메뉴가 같은 곳에 있으면, 급한 것이 안 급한 것에 묻힙니다. 이 설계도는 그걸 흐름 단위로 쪼갰습니다.

스프린트·이슈·코드리뷰·배포를 순서대로 놓은 구조

스프린트(회고·플래닝·데일리) → 이슈(백로그·진행·완료) → 코드리뷰(pr·리뷰·머지) → 배포(스테이징·프로덕션·롤백) 순으로 카테고리가 서 있습니다.

이 순서가 일이 실제로 흐르는 순서입니다. 채널 목록을 위에서 아래로 읽으면 그게 곧 개발 흐름이 되니, 새로 들어온 사람이 설명을 안 들어도 어디서 무슨 이야기를 하는지 압니다.

이슈 카테고리를 백로그·진행·완료로 쪼갠 것도 같은 생각입니다. 이슈 트래커를 따로 쓰시더라도 논의는 디스코드에서 벌어지니, 상태별로 채널이 있으면 지금 붙잡고 있는 게 뭔지 보입니다.

pr과 회고, 포스트모템만 포럼인 이유

포럼 채널이 셋입니다 — 코드리뷰의 pr, 스프린트의 회고, 장애의 포스트모템.

셋의 공통점은 하나가 끝날 때까지 여러 번 오간다는 것입니다. PR 하나에 리뷰 코멘트가 열 개 붙고, 회고 하나에 팀원 전원이 의견을 답니다.

채팅 채널이면 PR 세 개의 리뷰가 뒤엉켜서 어느 코멘트가 어느 PR 이야기인지 놓칩니다. 포럼은 글마다 방이 서니 그 문제가 없습니다.

나머지가 텍스트 채널인 것도 맞습니다. 데일리나 머지 알림은 흘러가도 되는 정보입니다.

롤백 채널을 미리 만들어 두세요

배포 카테고리에 스테이징·프로덕션·롤백이 있습니다. 롤백 채널은 평소에 비어 있는 채널입니다.

그래서 지우고 싶어지는데, 사고가 났을 때 이 채널이 있는 것과 없는 것은 차이가 큽니다. 되돌리는 중에 프로덕션 채널에 글을 쓰면 배포 기록과 복구 기록이 섞여서, 나중에 시간순을 복원할 수 없습니다.

배포와 장애 공지는 형식이 정해져 있어야 합니다. 활성화봇을 초대하고 /공지 로 임베드 틀을 잡아두세요. 버전·시각·영향 범위를 같은 자리에 적게 하면 읽는 쪽이 훑기만 해도 됩니다.

배포 공지처럼 형식이 고정된 글을 짜는 법은 임베드 공지 만들기 영상을 참고하세요.

인시던트 채널은 알림이 울려야 합니다

인시던트 채널은 놓치면 안 되는 유일한 채널입니다. 나머지는 나중에 봐도 되지만 이건 아닙니다.

알림 역할을 하나 만들어 이 채널에서만 멘션하게 하시고, 다른 채널에서는 그 역할을 쓰지 마세요. 역할이 아무 데서나 울리면 사람들이 알림을 끄고, 그러면 정작 장애 때 아무도 안 봅니다.

/로그채널 로 권한 변경 로그도 잡아두시면 좋습니다. 프로덕션 접근 권한이 언제 누구에게 갔는지가 남아야 감사가 가능합니다.

백엔드·프론트·인프라·QA 역할은 멘션용입니다

역할에 팀장·백엔드·프론트·인프라·QA·개발자가 있습니다.

이 역할의 쓸모는 권한이 아니라 멘션 범위입니다. 스테이징이 죽었을 때 인프라만 부르면 되고, 전체를 부르면 여덟 명이 새벽에 깹니다.

/역할선택셋업 으로 본인이 고르게 두셔도 되지만, 개발팀은 인원이 적고 소속이 분명하니 관리자가 붙여주는 쪽이 오히려 정확합니다.

점심 채널을 지우지 마세요

유저 카테고리에 기술공유와 함께 점심 채널이 있습니다. 업무 서버에 어울리지 않아 보이는 채널입니다.

그런데 원격으로 일하는 팀에서는 이 채널이 유일한 잡담 창구입니다. 업무 채널만 있는 서버는 필요할 때만 열게 되고, 그러면 급한 일이 생겨도 반응이 늦습니다.

하루에 한 번 열리는 이유가 있는 채널을 하나쯤 두는 게 좋습니다.

공지와 로그를 이미 사내 봇이 맡고 있다면 옮기지 않으셔도 됩니다.