<aside>

스터디 운영에 전반적인 방식을 기록하여 후대 전수하기 위한 목적으로 작성된 문서

스터디 운영 경험이 한 기수 안에서만 머무르지 않고 다음 기수로 이어지도록 하기 위해서예요. 새로운 리드는 이전 기수의 고민과 시행착오 위에서 출발할 수 있고, 자신만의 운영 방식을 설계할 때도 구체적인 레퍼런스를 가질 수 있어요.

📌 리드 운영 가이드

기존 스터디 리드들이 자유롭게 남긴 운영 기록을 주제별로 묶어 정리한 문서예요. 처음 스터디를 여는 리드가 "무엇을 어떻게 준비하면 되는지" 흐름대로 따라갈 수 있도록 구성했어요. 각 항목 끝의 출처는 실제 운영 사례를 남긴 스터디예요.

⚠️ 아래 내용(미션 일정, PR 정책, 회고 횟수 등)은 정해진 표준이나 규칙이 아니라 일부 리드의 운영 사례일 뿐이에요. 참고용으로만 보시고, 스터디 성격과 참여자에 맞게 각자의 방식으로 자유롭게 운영하시면 돼요.

1. 시작 전 준비

스터디 시작 전, 참여자의 개발 경험을 미리 파악해두면 리뷰의 눈높이를 맞추기 좋아요. 간단한 사전 설문(구글폼)으로 참여자의 경험 수준을 받아두고, 그에 맞춰 리뷰 강도를 조절했어요. (우아한명지코스 사례)
- 사진

미션 1개당 약 10일을 기본 주기로 잡았어요.
- 초기에는 구현 3일 + 리뷰 반영 7일로 운영했고, 이후 기수에서 구현 4일 + 리뷰 반영 6일로 구현 기간을 늘렸어요. 참여자들이 구현에 더 시간을 쓸 수 있게 한 조정이에요. (우아한명지코스 사례)
주 1회 오프라인 모임 기반이면 일주일 단위 사이클이 자연스러워요. 월요일 저녁 스터디 → 목요일 저녁까지 PR 제출 → 다음 월요일 전까지 리뷰·머지 흐름으로 운영했어요. (SCG 사례)

처음에는 우테코 방식대로 1차 구현 PR + 2차 리팩토링 PR로 나눠 받았어요. 그런데 구현 PR에서 이미 리팩토링 리뷰가 오가다 보니 두 PR의 경계가 모호해졌어요.
- 그래서 이후 기수에서는 하나의 PR로 통합해, 한 PR 안에서 구현 → 리뷰 → 반영이 이어지도록 바꿨어요. (우아한명지코스 사례)
리뷰 요청은 디스코드 채널에 리드를 언급(@)하고 PR 링크를 공유하는 방식으로 받았어요. 미션 진행·코드리뷰 요청 단계는 별도 문서로 안내해두면 참여자가 따라오기 쉬워요. (GoGcd 사례)
리뷰 기간이 짧으면(예: 4일) 핑퐁이 2번 정도라 아쉬울 수 있어요. 미션 분량이 적은 초반에는 PR을 미리 제출하는 스터디원이 리뷰를 더 풍부하게 받기도 했어요. (SCG 사례)

중간 회고 + 최종 회고, 총 2회를 진행했어요.
- 회고 형식은 자유로 두되, 별도 repo를 만들어 참여자 전원이 회고록을 남기도록 했어요. (우아한명지코스 사례)
- 회고 링크: https://github.com/woowa-myongji-course/java-basic-1th
매 강의·미션마다 짧은 피드백(좋았던 점 / 아쉬웠던 점, 난이도, 소요시간)을 갠톡이나 폼으로 받아두면 다음 회차 개선에 바로 반영할 수 있어요. (GoGcd 사례)

스터디만을 위해 모인 경우 친밀도를 쌓기 어려울 수 있어요. 여건이 되면 오프라인 만남을 가지면 친밀도도 올리고, 코드의 의도를 직접 물어볼 수 있어 좋아요. (의도를 묻는 건 AI 의존 여부와 본인 의도가 담긴 코드인지 가늠하는 데도 도움이 돼요.) (우아한명지코스 사례)
오프라인 모임 시간은 지난 미션에 대한 이야기·의견 나눔과 다양한 활동(노션 발표 자료로 특정 주제 다루기, 페어프로그래밍, 퀴즈, 라이브코딩, 실습 등)으로 채울 수 있어요. 페어프로그래밍은 호불호가 있을 수 있으니 분위기를 봐서 시도해보세요. 첫 환경설정·첫 미션·첫 웹 애플리케이션처럼 진입장벽이 높은 부분은 다같이 해보는 것이 좋아요. (SCG 사례)
참여자가 질문을 망설이지 않도록 "본인을 검열하지 않는다, 질문이 강의자를 돕는 것" 같은 규칙을 미리 공유하면 강의 분위기가 한결 열려요. (GoGcd 사례)