데일리 스탠드업 — 개념, 데일리 미팅 규칙 및 이점

데일리 스탠드업이란?

데일리 스탠드업 — Scrum 팀의 짧은 미팅으로, 매 근무일 같은 시간과 장소에서 진행됩니다. 시간 제한은 15분입니다. 다양한 이름으로 알려져 있습니다: Daily Scrum(Scrum Guide), 아침 동기화, 모닝 서클, 데일리. 목표는 팀 동기화, 장애 요소 식별 및 일일 계획 조정입니다. 데일리는 관리자를 위한 보고가 아니라 팀의 자기 조직화 도구입니다. 미팅 구조는 팀이 결정하며 관리자가 결정하지 않습니다.

'스탠드업'이라는 용어의 기원은 문자 그대로 서서 미팅을 진행하는 관행에서 유래했습니다: 참가자들은 보드 앞에 모여 앉지 않습니다. 이는 일시적인 느낌을 만듭니다 — 아무도 15분 이상 서 있고 싶어하지 않습니다. 대면 스탠드업은 여전히 60%의 팀이 사용합니다(Scrum.org 2025 기준), 나머지는 Zoom, Slack Huddle 또는 Teams를 통한 원격 형식으로 전환했습니다. 원격 형식에서는 규율을 유지하는 것이 중요합니다: 카메라 켜기, 멀티태스킹 금지, 답변을 미리 생각해두기.

Scrum Guide 2025는 Daily Scrum을 개발자를 위한 이벤트로 정의합니다. Product Owner와 Scrum Master는 참석할 수 있지만 의무는 아닙니다. PO나 SM이 참석하더라도 미팅을 진행하지 않습니다. 팀은 자체 구조를 선택합니다: 고전적인 세 가지 질문 또는 보드 워크. 핵심 포인트: 데일리는 Sprint Goal을 향한 진행 상황을 점검하는 것이지, 각 작업의 상태를 확인하는 것이 아닙니다. 미팅이 보드의 작업 나열로 변한다면 팀은 Sprint Goal에 대한 집중력을 잃은 것입니다.

데일리 스탠드업의 세 가지 질문

질문 1: 'Sprint Goal 달성을 위해 어제 무엇을 했나요?' — 완료된 작업의 간략한 요약. 'APP-123에 작업했습니다'가 아니라 '로그인 화면 완료, PR 리뷰에 제출'입니다. 'Sprint Goal 달성을 위해'라는 표현은 의도적입니다: 일상 작업을 스프린트의 전체 목표와 연결합니다. 개발자가 자신의 작업과 Sprint Goal의 연관성을 찾지 못한다면, 현재 스프린트에서 해당 작업이 필요하지 않을 수 있다는 신호입니다. 모바일 개발에서 어제의 결과에는 코드뿐만 아니라 테스트, 문서 및 CI/CD 구성도 포함됩니다.

질문 2: 'Sprint Goal 달성을 위해 오늘 무엇을 할 계획인가요?' — 당일 계획. 2-3개 항목 이하. 개발자는 '오늘 프로필 화면의 ViewModel을 완료하고, 단위 테스트를 작성하고, 실제 기기에서 빌드를 실행하겠습니다'라고 말할 수 있습니다. 계획이 '어제'와 일치한다면, 작업이 너무 커서 분해가 필요하다는 신호입니다. 2일 규칙: 작업이 2일 작업 내에 완료되지 않으면 하위 작업으로 분할해야 합니다. 그렇지 않으면 In Progress에 몇 주 동안 고립됩니다.

질문 3: '진행을 방해하는 장애 요소는 무엇인가요?' — 가장 중요한 질문입니다. 장애 요소는 개발자가 스스로 해결할 수 없는 것입니다: 리뷰 대기(리뷰 SLA 초과), 에뮬레이터 오류, API 미완성, 저장소 접근 권한 필요 등. 중요: 장애 요소는 언급해야 하지만 데일리 중에 해결해서는 안 됩니다. 미팅 후 개발자와 Scrum Master/관리자가 장애 요소 해결을 조율합니다. Scrum.org(2025)에 따르면, 모바일 팀 장애 요소의 70%는 리뷰 대기(30%), 테스트 기기 부족(20%), 백엔드 의존성(20%)과 관련됩니다.

스탠드업 올바르게 진행하는 방법

시간과 장소. 데일리는 매일 같은 시간에 진행됩니다 — 보통 근무일 시작 시간(9:00-10:00). 분산 팀의 경우 모든 시간대에 편리한 시간을 선택합니다. 시간 — 엄격히 15분. 타이머는 필수입니다. 팀이 시간 내에 끝내지 못한다면, 문제는 데일리가 아니라 프로세스에 있습니다: 참가자가 너무 많거나 작업을 나열하는 대신 논의하고 있습니다. 핑퐁 규칙: 각 참가자는 60초 이내로 발언합니다. 답변 후 다음 사람에게 발언권을 넘깁니다.

보드 워크 형식. 세 가지 질문의 대안: 팀원들이 차례로 Scrum 보드에서 작업을 이동하며 변경 사항을 설명합니다. 개발자가 To Do에서 작업을 가져와 In Progress로 이동하며 'APP-123을 진행합니다 — 주문 화면, 프로모 코드 필드 추가'라고 말합니다. 보드 워크는 진행 상황을 시각적으로 이해하게 하고 '잊혀진' 작업(3일 이상 움직이지 않은 작업)을 드러냅니다. 보드 워크가 선호됨 Jira/Linear를 사용하는 분산 팀에 적합 — 모두가 독백을 듣는 대신 보드를 봅니다.

원격 팀의 경우: 카메라는 켜야 합니다 — Microsoft Research(2025)에 따르면 카메라를 켜면 참여도가 40% 증가합니다. 작업 보드(Jira, Linear, Miro)를 화면 공유합니다. 장애 요소는 채팅에 작성합니다 — 기록이 남습니다. 반응 이모지를 장려합니다(사용자 지시가 있는 경우 제외 — 이모지는 사용하지 않음) — 동료 메시지에 좋아요. 데일리 후 2-3분의 파킹 로트: 별도 논의가 필요한 주제는 후속 미팅 목록에 기록합니다. Scrum Master의 핵심 기술: 데일리 중 논의를 중단하고 파킹 로트로 이동시키는 것.

미팅의 일반적인 실수

실수 1: 관리자를 위한 상태 보고. 개발자가 차례로 Jira에 적힌 내용을 읽고, 관리자가 질문하며, 미팅이 45분 동안 지속됩니다. 해결책: 데일리는 팀을 위한 것임을 상기시키고 관리자를 위한 것이 아님을 알립니다. 관리자는 보드에서 상태를 확인할 수 있습니다. 관리자가 질문하면 1:1 미팅으로 이동합니다. 데일리를 상태 보고로 전환한 팀은 모든 참가자가 주당 2-3시간을 잃습니다. 8명의 개발자의 경우 월 16-24인시 — 연간 전체 스프린트 하나의 손실입니다.

실수 2: 현장에서 문제 해결. 개발자가 'gRPC에 버그가 있습니다 — 프로젝트가 빌드되지 않습니다'라고 말하면 전체 팀이 20분 동안 해결책을 논의합니다. 해결책: 장애 요소를 파킹 로트에 기록하고 데일리를 계속합니다. 미팅 후 관련자(개발자 + 도움을 줄 수 있는 사람)를 모아 10분 논의를 진행합니다. Basecamp(Shape Up)에 따르면, 데일리에서 발견된 문제의 20%만 전체 팀 논의가 필요합니다. 나머지는 개발자 2명이 10분 안에 해결할 수 있습니다.

실수 3: 지각과 결석. 누군가 시작 5분 후에 도착하여 반복 설명이 필요합니다. 해결책: '데일리는 정시에 시작하며 지각자는 참여할 수 없음' 또는 '지각자는 벌금(팀 커피)' 규칙을 설정합니다. 더 엄격하게: 데일리는 고정 시간에 진행되며, 체계적으로 지각하는 경우 1:1에서 해결하는 규율 문제입니다. 데일리는 하루의 동기화입니다. 개발자가 결석하면 동기화되지 않으며 팀에 잘못된 작업을 할 위험이 있습니다.

실수 4: 참가자 과다. 15명 이상의 팀, 각 1분 발언 — 총 20분 이상. 해결책: 팀을 기능/모듈별 하위 그룹으로 나눕니다. 각 하위 그룹이 자체 데일리를 진행합니다(5-7명). 각 하위 그룹의 대표 한 명이 팀 간 스탠드업에 참여할 수 있습니다(팀 간 동기화가 필요한 경우). 대안: Slack/GeekBot을 통한 비동기 스탠드업으로 각자 작업/계획/장애 요소를 작성합니다.

비동기 스탠드업: 대안

비동기 스탠드업 — 참가자가 구두 미팅 대신 채팅(Slack, Telegram, Teams)이나 전용 봇(GeekBot, Standuply, Status Hero)에 답변을 작성하는 형식입니다. 3시간 이상의 시차가 있는 분산 팀에 적합합니다. 각 참가자는 정해진 시간(예: 11시까지)까지 동일한 세 가지 질문에 답변합니다. 봇이 답변을 수집하여 공통 채널에 요약을 게시합니다. 장점: 유연성, 기록 유지, 지각 문제 없음.

비동기 형식의 단점: 실시간 소통 없음 — 비언어적 신호 손실, 장애 요소 식별이 어려움(개발자가 문제를 작성하지 않을 수 있음). 채팅에 작성된 장애 요소는 하루 종일 발견되지 않을 수 있습니다. GitLab(2025)에 따르면, 비동기 스탠드업으로 전환한 팀의 40%가 3개월 이내에 구두로 복귀했습니다. 권장 사항: 하이브리드 사용 — 주 3일 구두(월, 수, 금), 2일 비동기(화, 목). 또는 주 1-2회 구두, 나머지 날은 비동기.

비동기 스탠드업 도구: GeekBot(Slack) — 세 가지 질문을 하고 요약을 게시; Standuply — Jira 통합 및 자동 추적 제공; Status Hero — 상태를 수집하여 관리 주간 보고서 생성. 도구 선택은 팀 문화에 따라 다릅니다: 스타트업에서는 Slack 봇으로 충분; 엔터프라이즈 환경에서는 기업 프로세스 통합이 가능한 Standuply가 필요할 수 있습니다. 중요 규칙: 형식에 관계없이 답변은 관리자뿐만 아니라 전체 팀이 볼 수 있어야 합니다. 투명성은 Agile의 핵심 가치입니다.

모바일 팀 데일리의 특징

모바일 팀은 데일리에서 특정 장애 요소에 직면합니다. 주요 사항: CI의 프로젝트 빌드(Gradle 빌드는 20분 이상 소요 가능 — 중단 시 개발자가 디버깅에 1시간 손실), TestFlight/Firebase App Distribution 대기(테스터에게 빌드 게시에 30-60분 소요), 에뮬레이터 및 시뮬레이터 문제(Android Emulator는 KVM/HAXM 필요, iOS Simulator는 Mac 전용). 모바일 팀 데일리에는 빌드 상태 빠른 확인이 포함되어야 함: '빌드 통과하나요? 모든 테스트가 통과했나요?'

크로스 플랫폼 프로젝트(Flutter, React Native)의 경우 데일리에 공유 코드 상태에 대한 질문이 포함될 수 있습니다. 두 개발자가 동시에 동일한 Dart 파일을 편집하고 한 명이 변경 사항을 병합하면 다른 개발자가 충돌을 경험합니다. 조언: 플랫폼(Android / iOS / Shared)별로 분할된 보드로 보드 워크를 사용합니다. 누가 어디에서 작업하고 변경 사항이 중복되는지 시각화하는 데 도움이 됩니다. Flutter 프로젝트의 경우 Platform Channel, BLoC/Cubit, UI 및 Tests 열이 있는 보드를 사용합니다.

릴리스 준비 — 데일리에서 모바일 개발의 또 다른 특정 사항입니다. 릴리스 3-5일 전에 질문을 추가합니다: '빌드가 릴리스 준비가 되었나요? 모든 메타데이터(아이콘, 스크린샷, 설명)가 업데이트되었나요?' 이는 개발자가 릴리스 당일 코딩을 마치고 빌드 및 게시에 3-4시간이 더 걸리는 상황을 방지합니다. 릴리스 트래커 — 체크리스트가 있는 별도 보드: versionCode/versionName 업데이트, ProGuard 확인, AAB 서명, 개발자 콘솔 업로드, 릴리스 노트 작성.