2026 Stolio 운영규정(수정중)
1) 활동 구조(길드/스쿼드)
1.1 길드(Guild) = 직무별 성장/리뷰 조직
Dev / PM(기획·디자인 포함) / Ops(운영·행정) 로 운영
길드는 “강의”가 아니라 코칭·리뷰·템플릿 제공만 합니다.
1.2 스쿼드(Squad) = 프로젝트 실행 조직
프로젝트 진행 시 팀당 4~5명으로 구성
기본 역할(권장): PM 1 + Dev 2~3 + QA/Docs 1(겸임 가능)
스쿼드는 결과물을 내는 조직이며, “참여”보다 산출물이 우선입니다.
2) 정기 모임(주 1회 1~2시간) 운영 방식
정기 모임은 회의가 아니라 리뷰/데모 시간입니다.
(필수) 스쿼드별: 이번 주 Done/Next + 막힌 것 1개 공유
(필수) 산출물 기반 리뷰: PR/이슈/문서/디자인/데모 중 최소 1개를 실제로 보여주기
(선택) 일부 팀 데모 발표(짧게, PPT 지양)
나머지 업무는 비동기(온라인)로 진행합니다.
3) 기여 인정 기준(무임승차 방지: “증빙 없으면 0”)
동아리는 “열심히 했다”가 아니라 증빙 링크로 기여를 인정합니다.
매주 아래 중 최소 1개 이상을 제출해야 합니다(팀 게시판/개인 깃허브/개인 노션).
인정되는 기여 예시:
코드: GitHub PR(리뷰 반영 포함), 버그 수정 PR
이슈 해결: 재현/원인/해결 과정을 남긴 이슈/노트
문서: README, API 문서, 테스트/배포 가이드, 회의록(결정사항 포함)
기획/PM: PRD(요구사항), 사용자 시나리오, 백로그/일정 업데이트
디자인(공대 내 해결 가능 범위): Figma 화면/플로우, UI 컴포넌트 정리, 레퍼런스 기반 개선안
QA/운영: 테스트 케이스, 릴리즈 체크리스트, 로그/모니터링 정리, 유저 피드백 정리
4) 프로젝트 참여 유지 규칙(프로젝트 제외 기준)
2주 연속 기여 0(증빙 없음) → 해당 학기 프로젝트에서 제외됩니다.
(동아리 자체 퇴출이 아니라, 그 학기 프로젝트 참여가 종료됩니다.)제외된 인원은 원하면 다음 기수/다음 프로젝트에 재도전할 수 있습니다.
목적: 사람을 벌주려는 게 아니라, 팀의 시간을 보호하고 “폰지형 희생”을 막기 위함입니다.
5) 역할 정의(리더 부재 해결)
5.1 PM(Project Manager) — 권한과 책임
책임: 요구사항 정리, 일정/백로그 운영, 회의록·결정사항 기록, 데모 진행
권한: 우선순위 결정, 스코프 조정, 역할 재배치 제안
5.2 Tech Lead(또는 Dev Lead) — 권한과 책임(팀에 가능하면 1명)
책임: 기술 방향/아키텍처 초안, 코드 품질 기준, 리뷰 1차 정리, 배포 체크
권한: 개발 규칙(브랜치/리뷰 방식 등) 제안 및 적용
※ “팀장”이라는 권위 직책은 두지 않고, 기능적 리더(PM/Lead)로 운영합니다.
6) 교육/성장 방식(Teaching ❌, Coaching & Review ⭕)
동아리는 정규 강의식 수업을 하지 않습니다.
문제 해결은 검색/문서/AI 활용을 기본으로 하고, 선배/리드는 리뷰와 방향성 코칭을 제공합니다.
초보자도 환영하지만, “학습 의지”는 제출물(증빙)로 증명해야 합니다.
7) 검증 문화(외부/객관 기준)
목표는 “우리끼리 만족”이 아니라 데모 가능한 결과물입니다.
정기적으로 데모/피드백을 진행하고, 가능하면 교수·졸업생·외부인 초청 평가를 추진합니다.
공모전/EXPO/창업 트랙은 팀 상황에 따라 상위팀/희망팀 중심으로 운영합니다.
8) 운영(Ops) 원칙(행정 최소화/투명성)
개발자가 영수증 처리하지 않도록 Ops가 행정을 담당합니다.
지원금/회계는 가능한 범위에서 투명하게 공유합니다(분쟁 예방).
9) 참여 가이드(가입 전 꼭 읽기)
이 동아리는 다음 사람에게 맞습니다.
결과물(포트폴리오)을 만들고 싶은 사람
팀으로 협업하며 성장하고 싶은 사람
“증빙 기반” 규칙에 동의하는 사람
맞지 않을 수 있는 사람:
참여는 하고 싶지만 산출물을 내기 어려운 사람
친목이 최우선인 모임을 원하는 사람