개발자 스터디 서버

개발 스터디가 3주 만에 조용해지는 이유는 실력 차이가 아닙니다. 진도가 어디까지 갔는지 아무도 모르게 되는 것입니다. 이 설계도가 모집·진행·커리큘럼을 나눠둔 것은 그 흐름을 붙잡으려는 구성입니다.

모집이 포럼인 것을 살리세요

스터디 카테고리에 모집·진행·커리큘럼이 있고, 모집이 포럼입니다.

스터디는 한 건이 글 하나로 서야 합니다. 주제·기간·요일·인원을 적고, 차면 태그를 바꿔 닫습니다.

채팅으로 받으면 모집글이 밀려서, 늦게 본 사람이 이미 끝난 스터디에 연락합니다.

글에 끝나는 날짜를 반드시 적게 하세요. 기한이 없는 스터디는 예외 없이 흐지부지됩니다. 「8주」처럼 끝이 보여야 사람이 붙습니다.

진행 채널이 이 서버의 생명줄입니다

진행 채널은 지금 돌아가는 스터디의 현황을 두는 자리입니다.

여기가 비면 서버가 죽습니다. 모집만 있고 진행이 안 보이면, 새로 온 사람이 「여기 모이기만 하고 안 하는구나」로 판단합니다.

각 스터디가 주마다 한 줄씩만 남기게 하세요. 「3주차 완료, 다음은 이것」이면 충분합니다.

커리큘럼 채널은 시작 전에 짜는 자리입니다. 진행과 나눠둔 게 맞습니다.

주제 채널 세 개를 다 열지 마세요

사람이 스무 명 안쪽이면 세 채널이 다 비어 보입니다. 질문 하나에 이틀 동안 답이 없으면 아무도 안 씁니다.

처음에는 하나만 여세요. 알고리즘이 무난합니다 — 언어를 안 가리고 답할 수 있는 사람이 가장 많습니다.

사람이 늘어서 한 채널이 넘치면 그때 나누시면 됩니다. 순서를 거꾸로 하면 빈 채널만 남습니다.

과제 제출을 포럼으로 받은 판단

과제 카테고리에 제출·리뷰·해설이 있고, 제출이 포럼입니다.

코드 리뷰는 한 사람의 코드에 여러 의견이 붙습니다. 채팅이면 누구 코드에 대한 말인지 섞입니다.

제출 글 하나에 리뷰가 댓글로 달리면 흐름이 남습니다. 나중에 같은 과제를 하는 사람이 그 글을 읽습니다.

리뷰 채널을 따로 둔 이유는 리뷰하는 법을 다루기 위해서입니다. 「어디까지 지적할지」 같은 것들이요. 제출 글에 달리는 개별 리뷰와는 다릅니다.

리뷰 규칙을 먼저 정하세요

스터디가 깨지는 가장 흔한 이유가 리뷰의 온도입니다.

규칙을 하나만 두세요. 「코드를 말하고 사람을 말하지 않는다」. 「이 부분은 이렇게 하면 더 낫습니다」와 「이것도 모르나요」는 다릅니다.

그리고 리뷰를 의무로 만들지 마세요. 부담이 되면 제출부터 안 합니다.

TIL 채널이 가장 오래 갑니다

TIL은 하루에 한 줄이면 되는 자리입니다. 문턱이 가장 낮아서, 스터디가 끝난 뒤에도 이 채널만 살아남는 경우가 많습니다.

여기에 활성화봇을 붙이면 습관이 붙습니다. /출석 은 하루 한 번만 되니 그대로 기록 체크가 되고, /포인트자동지급 을 걸어두면 연속으로 남긴 사람이 눈에 보입니다. 설정은 출석체크 세팅 영상에 나옵니다.

안 쓴 날에 불이익을 주지 마세요. 기록은 습관을 만들려는 것이지 검사하려는 것이 아닙니다. 벌이 붙는 순간 아무도 안 씁니다.

회고 채널을 스터디가 끝날 때 쓰세요

회고는 끝난 뒤에 쓰는 글입니다. 무엇이 좋았고 무엇이 안 됐는지요.

이게 쌓이면 다음 스터디를 더 잘 짤 수 있습니다. 「8주는 너무 길었다」 같은 것이 그대로 다음 모집에 반영됩니다.

중간에 그만둔 스터디도 회고를 남기게 하세요. 실패한 이유가 더 값어치 있습니다.

청강 역할을 열어두세요

역할에 스터디장·멘토·참여자·청강이 있습니다.

청강은 참여는 안 하지만 보는 사람입니다. 이 자리가 있는 게 좋습니다.

스터디는 시간을 내야 해서 부담스럽지만, 보는 것부터 시작하는 사람이 있습니다. 그 사람이 다음 기수 참여자가 됩니다.

멘토는 답해주는 사람에게 주세요. 실력이 아니라 답을 다는 빈도로 보시는 편이 맞습니다. 잘하는 것과 잘 가르치는 것은 다른 재능입니다.

봇이 무엇이든, 진행 채널이 비지 않게 하는 것이 스터디 서버 운영의 전부입니다.