진행 방식
운영 규칙
스터디를 굴리는 규칙과 개발자라서 쓸 수 있는 무기, 시작 전 준비를 정리했어요
| 규칙 | 왜 |
|---|---|
| 매 회차 산출물 필수 — 못 내면 그 회차 발표 순서 없음 | 요약 발표 릴레이 방지 |
| 6회차까지 코드 금지 | 개발자 스터디 최대 함정. 손이 근질거려도 참아야 기획 근육이 붙습니다 |
| 숫자 3개 + 출처 없으면 발표 불가 | 감상문 방지 |
| 매 회차 1명은 "악마의 변호인" | 그 회차 발표를 무조건 깨려고 시도. 역할이니까 서로 감정 상하지 않습니다 |
| 역기획 회차엔 1명이 "그 회사 CEO" 역할 | 개선안을 전부 방어. 방어하는 쪽이 더 많이 배웁니다 |
| 완벽하게 만들지 말 것 | A4 1~2장. 못 채운 항목은 "모르겠음"이라고 쓰고 오면 됩니다. 그것도 발견입니다 |
| 결석해도 산출물은 낼 것 | 8회차뿐이라 한 번 빠지면 흐름이 끊깁니다. 문서만 올려두면 따라올 수 있습니다 |
개발자라서 할 수 있는 것
다른 기획 스터디는 못 하는, 우리만의 무기입니다.
- 앱 릴리즈 노트 전체 히스토리 = 그 회사의 실제 로드맵 — 크롤링해서 타임라인 만들면 몇 년치 의사결정이 보입니다
- 네트워크 요청 분석 — 무엇을 수집하는가 = 무엇을 중요하게 보는가
- A/B 테스트 흔적 / 피처 플래그 탐지
- API 구조 역추적 — 도메인 모델이 드러납니다 (예: 야놀자 API를 보면 그들이 "숙소"를 어떻게 정의했는지 나옴)
- 앱 내 SDK 목록 — 어떤 분석툴·광고 인프라를 쓰는지
이런 방식으로 정리된 자료는 시중에 거의 없습니다. 블로그로 공개하면 그 자체가 포트폴리오가 됩니다.
시작 전 준비
참여 전 스스로 확인
- 8주간 주 2시간 모임 + 준비 2~3시간 낼 수 있다
- 4회차 숙제로 모르는 사람 3~5명을 인터뷰할 각오가 있다 (제일 무서운 숙제입니다)
- 6회차까지 코드를 안 짜고 버틸 수 있다
- 내 기획안이 공개적으로 반박당하는 것을 받아들일 수 있다
1회차 전에 할 일 (30분이면 됩니다)
- 디스코드 서버 입장 / GitHub 저장소 초대 수락
- 내가 매일 쓰는 앱 1개 정하고, "이 기능은 왜 있을까?" 3개 적어오기 (한 줄씩이면 충분)
준비물은 이게 전부입니다. 책도, 돈도 필요 없습니다.
1회차에 같이 정할 것
- 역기획 대상 회사 배정 (2·3회차 분)
- 역할 순번 (악마의 변호인 / CEO 역)
- 산출물 올리는 곳 (GitHub or Notion) + 마감 시각 (예: 모임 전날 자정)
- 결석·지각 시 규칙