PM 의 세 가지 일
① 인프라를 깐다
서버·DB·배포·시크릿·도메인. 나머지 4인이 git push 외에는
아무것도 신경 쓰지 않게 만든다.
인프라 런북 →
② 지킬을 관리한다
이 사이트가 팀의 단일 기준점이다. 기획·일정·칸반·기록이 여기서만 갱신된다. 사이트 사용법 →
③ 확인하고 숙지시킨다
각자가 한 일을 PM 이 직접 확인하고, 그 결과를 팀 전체가 알게 만든다. 리뷰 & 숙지 사이클 →
PM 이 하지 않는 일
역할을 좁게 정의하는 게 더 중요합니다.
- 기능 코드를 짜지 않는다. PM 이 개발에 들어가면 리뷰·인프라·판단이 전부 밀린다.
- 개인의 구현 방식에 개입하지 않는다. 완료 기준을 확인하되, 어떻게 짤지는 담당자 몫이다.
- 지연을 대신 메우지 않는다. 늦으면 범위를 줄인다. 야근으로 메우면 어디가 늦는지 안 보이게 된다.
하루 리듬
| 시각 | 무엇 | 소요 |
|---|---|---|
| 09:30 | 아침 정렬 — 오늘 관문 확인, 각자 오늘 카드 확인 | 10분 |
| 낮 | PM 은 인프라·문서 작업. 막힌 사람 있으면 즉시 붙는다 | — |
| 18:00 | 저녁 리뷰 — review 카드 확인 → done 처리, 사이트 갱신 |
30분 |
| 밤 | 내일 관문에 필요한 선행조건이 준비됐는지 PM 혼자 점검 | — |
회의는 하루 두 번, 합쳐서 40분
14일 프로젝트에서 회의 시간은 곧 개발 시간입니다. 긴 논의가 필요하면 회의를 늘리는 대신 결정 권한을 한 사람에게 주는 쪽을 택합니다.
의사결정 권한
| 무엇 | 누가 정하나 |
|---|---|
| 범위 조정 (무엇을 자를지) | 류준 — 단독 결정 |
| 백엔드 구조·ERD·API 계약 | 장민석 — PM 은 일정만 관여 |
| AI 프롬프트·모델·툴 설계 | 신채연 |
| 앱 구조·상태관리 | 이은상 |
| 웹 구조·디자인 토큰 | 김충식 |
| 배포 시점·롤백 판단 | 류준 — 단독 결정 |
| 오픈 여부 | 류준 — 릴리스 체크리스트 기준 |
기술 판단은 각 담당자가, 일정과 범위 판단은 PM 이 합니다. 이 선이 흐려지면 둘 다 느려집니다.
PM 의 14일 (칸반 44건)
류준 개인 보드에 전부 있습니다. 요약하면:
| 기간 | PM 이 하는 일 |
|---|---|
| D-13 ~ D-12 (9/03–04) | 레포·브랜치·DNS·스테이징 서버·DB·시크릿 — 기반을 깐다 |
| D-11 ~ D-10 (9/05–06) | CI/CD 파이프라인, HTTPS — 자동화를 완성한다 |
| D-9 ~ D-8 (9/07–08) | 스모크 스크립트, 모니터링, 앱 배포 채널, AI 비용 대시보드 |
| D-7 (9/09) | 알파 시연 주재 + 범위 컷 결정 — 이날이 PM 의 가장 중요한 날 |
| D-6 ~ D-5 (9/10–11) | 프로덕션 인프라, Feature Freeze 선언, 릴리스 체크리스트 |
| D-4 ~ D-3 (9/12–13) | 버그 트리아지, 보안 점검, 스토어 제출 지원 |
| D-2 ~ D-1 (9/14–15) | RC 태깅, 배포·롤백 리허설, Code Freeze |
| D-0 (9/16) | 배포 실행, 30분 관측, 온콜, 회고 |
문서 관리 원칙
- 결정은 기획 문서에, 과정은 데브로그에. 섞이면 둘 다 안 읽힌다.
- 바꿀 때는 「결정 로그」에 한 줄. 날짜·바뀐 것·이유. 이게 없으면 두 달 뒤에 아무도 이유를 모른다.
- 빈칸 대신 「미정」. 빈칸은 합의된 걸로 오해되고, 「미정」은 누군가 물어보게 만든다.