핵심 결정 요약
주기2주 스프린트로 전환. 단 “2주 안에 끝내는 마감”이 아니라 “2주마다 멈춰 재조정하는 체크포인트”로 운영.
인력프론트 1명을 풀스택으로 전환, 백엔드 병목 지점에 투입해 프론트 대기 감소.
Capacity계획을 100% 채우지 않음. 운영 부담이 큰 사람은 개발 가능일을 낮게 고정(당번제 아님 — 특화라 못 돌림).
큰 작업5일 넘는 백엔드는 “완성”이 아니라 “이번 스프린트 목표 지점”으로 쪼개서 담음.
프론트백엔드보다 한 박자 뒤 파이프라인. 남는 역량은 품질·부채(CI/CD, 성능, 디자인시스템)에 배치.
배포정규 = 화요일 창구(준비된 것만, 없으면 스킵) / 핫픽스 = 즉시, 딱 그것만.
01왜 2주인가
“추정이 어렵다”는 짧은 주기의 반대 근거가 아니라 가장 강한 근거.
추정이 쉬우면 주기 길이는 상관없다 — 어차피 맞으니까. 추정이 어렵기 때문에 계획은 자주 틀리고, 그럴수록 짧게 끊어 빨리 교정해야 한다.
세리모니 오해 정정
2주 스프린트는 “1주 개발 + 1주 회고”가 아니다. 세리모니는 다 합쳐 2주 중 6~8시간(~10%), 나머지 ~9일은 순수 개발. 반년으로 보면 격주가 월간보다 세리모니를 약 6% 더 쓰지만, 헛짚음 손해를 절반으로 줄여 그 이상을 회수한다.
02스프린트 리듬
6인 팀 경량 버전. 세리모니는 짧게, 개발 시간을 지킨다.
1주차
월플래닝 (1~2h) — 스프린트 목표 1줄 확정
화개발 + 데일리 15분
화정규 배포 창구 (준비된 것만)
수목금개발 + 데일리 15분
2주차
월화개발 + 데일리 15분
수백로그 리파인먼트 (~1h)
화정규 배포 창구
금리뷰(데모) + 회고 (합쳐 ~1h)
- 데일리는 “어제/오늘/블로커”만. 문제 해결이 아니라 막힌 걸 드러내는 자리. 바쁘면 슬랙 스레드로 대체 가능.
- 회고는 PM이 말을 줄이고 팀이 프로세스 불만을 꺼내게 — 겸업 SM의 최대 함정이 여기.
03Capacity 규칙
운영은 “당번제”로 못 돌린다(특화). 대신 사람마다 개발 가능일을 다르게 고정.
핵심은 계획을 꽉 채우지 않는 것. 운영을 지는 특화 인력은 처음부터 계획 일감을 적게 받는다 — “7일치 주고 운영도 하세요”가 아니라 “너는 4일치만”. 그래야 “운영 때문에 못 했어요”가 사라진다.
※ 위 숫자는 예시 — 실제 운영 부담을 측정해 채워야 함(아래 미결 항목).
04큰 백엔드 작업
“완성” 대신 “이번 2주의 검증 가능한 지점”으로 정의한다.
- 5일 초과 티켓은 무조건 쪼갠다. 못 쪼개면 그건 티켓이 아니라 에픽 → 스프린트마다 조각으로 잘라 담는다.
- 티켓 정의를 “결제 완성”이 아니라 “이번 스프린트: 결제 API 스펙 + 코어 로직”처럼. 다음 스프린트: “예외처리 + 연동 + 테스트”.
- 목표는 리뷰에서 “진행 중”이 아니라 “여기까지 됐다”를 보여줄 수 있게 하는 것.
05프론트 활용
백엔드 선행 구조 → 프론트를 한 박자 뒤에서 돌리고, 빈틈은 미리 준비한 백로그로 메운다.
파이프라인: 이번 스프린트 프론트는 지난 스프린트에 백엔드가 완성한 것을 붙인다. 항상 “이미 완성된 API”를 다루므로 대기가 없다. (매끄럽게 하려면 API 계약을 코드보다 먼저 확정 → mock으로 병렬 착수)
남는 절반은 부채 상환에. 프론트 유휴는 리스크가 아니라 “부채 갚을 여유 자원”. 상시 대기 백로그를 미리 세워둔다:
- CI/CD 자동화 — 지금 수동 배포 부담을 근본적으로 없애는 1순위 후보
- 디자인시스템 미완 P0 (토큰 정리 + CI lint)
- 어드민 성능 최적화 (번들 ~3.2MB)
- E2E 테스트, 사장님 앱 UX 개선
옵틱스
“프론트가 논다”가 아니라 “여유 역량을 전략적으로 부채 상환에 배치 중, 가동률 추적 중”으로 먼저 프레이밍. 윗선이 싫어하는 건 노는 것 자체가 아니라 PM이 그걸 방치하는 것. 격주 데모로 개선 결과를 계속 보여주면 질문 자체가 안 나온다.
06배포 — 2레인
배포를 스프린트 끝에 묶지 않는다. 창구 + 긴급을 분리.
정규 배포
창구 · 화요일 오후
- “매주 강제”가 아니라 “나갈 땐 화요일에”. 준비된 게 없으면 스킵 → 규모 상관없이 항상 가능
- 새 기능·개선을 묶어서
- 수동이므로 체크리스트 따라 한 사람이 몰아서
- 금요일 배포 금지 (터지면 주말 대응 불가)
핫픽스 (긴급)
창구 무시 · 즉시
- 사용자 못 씀 / 돈 잘못 나감 / 데이터 깨짐 / 보안 → 즉시
- 딱 그 문제만 최소로. “하는 김에” 금지
- 애매하면 “화요일까지 기다리면 진짜 손해나나?”
- 핫픽스도 체크리스트 준수 + 다음 회고에서 원인 점검
※ 3주치가 한 번에 나가는 빅뱅 배포는 위험. 가능하면 기능 플래그 등으로 안전한 부분부터 중간 배포 — 단, 통째로만 나가야 하는 건 인정.
07플래닝 실행 순서
매 스프린트 시작 시 이 순서만 따르면 된다.
- 먼저 비운다. 각자 워킹데이에서 운영·회의 뺀 “진짜 개발 가능일” 계산 (보통 10일 중 6~7일).
- 운영 반영. 특화 인력의 개발 가능일을 낮게 고정.
- 큰 백엔드부터 담는다. 5일 초과는 “이번 목표 지점”으로 잘라서.
- 프론트는 지난 스프린트 결과물을 담는다 (파이프라인).
- 프론트 남는 칸은 부채 백로그에서 채운다.
- 가능일을 넘게 담지 않고 멈춘다. ← 가장 중요. 넘게 담으면 무조건 깨진다.
08중기 숙제
지금 급하진 않지만 걸어둬야 할 시한폭탄.
- CI/CD 자동화 — 수동 배포 자체가 부채. 자동화되면 고정 배포일도 불필요해지고 수시 배포 가능. 프론트 여유 역량의 1순위 투입처.
- 버스 팩터 1 해소 — “특화라서 그 사람만 운영 가능”은 시한폭탄. 문서화 + 풀스택 전환자에게 점진적 인수인계.
- 프론트 가동률 데이터 축적 — 2~3스프린트 돌려 감이 아닌 숫자로 재배치 여부 판단.
09미결 · 고도화 포인트
이 초안을 보며 함께 채울 것들.
?실제 운영 부담 측정 — 누가 스프린트당 며칠을 운영에 쓰는지. Capacity 표의 예시 숫자를 실측값으로.
?스프린트 시작 요일 — 월요일 시작이 기본이나 팀 상황에 맞게. 배포 화요일과의 간격 확인.
?풀스택 전환 대상·범위 — 누구를, 어느 백엔드 영역까지.
?배포 체크리스트 — 수동 배포 실수 방지용 실제 항목(백업/마이그레이션/배포/확인) 작성.
?부채 백로그 우선순위 — CI/CD·성능·디자인시스템·테스트 중 프론트가 먼저 칠 순서.
?핫픽스 판단 주체 — “이건 긴급” 최종 판단을 PM이 할지, 특화 인력이 할지.
한 줄 요약 — 우리 팀엔 “2주 안에 끝내는 스크럼”이 아니라 “2주마다 재조정하는 리듬”이 맞다. 추정이 어려울수록 짧게 끊고, 운영·배포는 capacity와 창구 규칙으로 흡수한다.