이 노트가 필요한 상황
스탠드업은 팀원이 서로의 진행 상황과 걸림돌을 짧게 맞추는 습관입니다. 모두가 같은 사무실에서 일하면 아침 15분 모임으로 끝나지만, 팀원이 서울·호치민·베를린에 흩어져 있다면 이야기가 달라집니다. 한국과 독일 사이의 시차는 서머타임 적용 여부에 따라 7~8시간이라, 한쪽의 오전 9시는 다른 쪽의 새벽 1~2시입니다. 이런 팀은 실시간 모임 대신 각자 하루를 시작할 때 세 가지를 글로 남기고, 상대는 자기 시간에 읽는 비동기 방식이 현실적입니다. 이 페이지는 그 글을 쓰고 메신저에 붙여 넣기 쉽게 만든 도구입니다.
동기 스탠드업과 비동기 스탠드업 비교
스크럼 가이드는 데일리 스크럼을 15분 이내의 이벤트로 규정하고 있고, 2020년 개정판부터는 예전에 널리 쓰이던 세 가지 질문 형식을 따로 정해 두지 않는 것으로 알려져 있습니다. 즉 "어제·오늘·블로커"는 공식 규칙이 아니라 널리 퍼진 관행이며, 팀이 편한 형식으로 바꿔도 됩니다.
| 구분 | 실시간 모임 | 글로 쓰는 방식 |
|---|---|---|
| 시간 | 모두 같은 시각에 접속 | 각자 편한 시각에 작성·열람 |
| 소요 | 보통 15분 안팎의 짧은 회의 | 작성 3~5분, 열람 5분 안팎 |
| 장점 | 즉석 질의응답, 팀 분위기 확인 | 시차·집중 시간 보호, 기록이 남음 |
| 약점 | 시차가 크면 누군가 새벽/늦은 밤 참석 | 질문에 대한 답이 늦어질 수 있음 |
세 칸을 쓰는 요령
어제 한 일에는 "열심히 했다"가 아니라 결과물이나 상태 변화를 적습니다.오늘 할 일은 하루 안에 끝낼 수 있는 크기로 쪼개 2~4개로 제한하세요. 목록이 열 개를 넘으면 읽는 사람이 아무것도 기억하지 못합니다. 블로커에는 누구에게 무엇을 요청하는지를 씁니다. "디자인이 늦다"는 불평이고 "디자이너 최 님, 결제 화면 시안을 수요일까지 확정해 주세요"는 요청입니다. 블로커가 없는 날도 "없음"이라고 명시하면 읽는 쪽이 빠뜨린 것이 아님을 알 수 있습니다.
| 모호한 표현 | 확인 가능한 표현 |
|---|---|
| 로그인 작업 진행 | 로그인 API 에러 응답 3종 처리 완료, 리뷰 요청함 |
| 버그 수정 | 주문 목록 중복 노출 버그(이슈 #412) 원인 확인, 수정은 오늘 오전 |
| 문서 작업 예정 | 온보딩 문서 2장 초안을 오후 3시 전까지 공유 |
| 막힌 거 없음 | 막힌 점 없음. 단, 스테이징 배포 권한 확인은 내일 필요 |
작성 예시: 서울-베를린 4인 프런트엔드 팀의 하루
아래는 가상의 팀을 가정한 예시입니다. 서울의 개발자 한지우가 목요일 오전에 쓰고, 베를린의 동료가 자기 아침에 읽습니다.
- 어제: 장바구니 쿠폰 입력 컴포넌트 구현 완료, 단위 테스트 6개 통과. 코드 리뷰는 베를린 팀에 요청해 둠.
- 오늘: (1) 리뷰 코멘트 반영 (2) 쿠폰 만료 문구 번역 키 추가 (3) 모바일 Safari에서 입력창 확대 현상 재현해 보기.
- 블로커: 쿠폰 검증 API 응답에 만료 시각 필드가 없음. 백엔드 담당 마르코가 한국 시간 금요일 오전까지 필드 추가 여부를 답해 주면 좋겠음.
이 글을 읽은 마르코는 자기 오후에 답을 달고, 지우는 다음 날 출근해 그 답을 보고 바로 이어서 일합니다. 실시간 회의였다면 이 한 번의 질의응답을 위해 누군가 늦은 밤이나 이른 새벽에 접속해야 했을 것입니다. 위 도구의 "직전 기록의 오늘 할 일 가져오기" 버튼은 다음 날 아침 어제 칸을 채우는 수고를 줄여 주고, 계획과 결과의 차이를 눈으로 비교하게 해 줍니다.
시차에 따라 실시간 모임이 가능한 시간
글로 쓰는 방식을 택할지 판단하려면 팀원들의 근무시간이 실제로 얼마나 겹치는지부터 보는 게 좋습니다. 아래 표는 한국 표준시(UTC+9) 오전 9시일 때 각 도시의 현지 시각과, 양쪽 모두 09~18시 근무라고 가정했을 때 겹치는 시간을 표준시 오프셋에서 빌드 시 계산한 값입니다. 서머타임은 나라마다 시작·종료일이 달라 표에는 적용 시 오프셋만 따로 두었고, 실제 날짜는 시간대 변환기로 확인하세요.
| 도시 | 표준시 | 한국 09:00일 때 | 겹치는 근무 시간 | 서머타임 적용 시 | 한국 09:00일 때 | 겹치는 근무 시간 |
|---|---|---|---|---|---|---|
| 도쿄 | UTC+9 | 09:00 | 9시간 | - | - | - |
| 호치민 | UTC+7 | 07:00 | 7시간 | - | - | - |
| 런던 | UTC+0 | 00:00 | 0시간 | UTC+1 | 01:00 | 1시간 |
| 베를린 | UTC+1 | 01:00 | 1시간 | UTC+2 | 02:00 | 2시간 |
| 뉴욕 | UTC−5 | 전날 19:00 | 0시간 | UTC−4 | 전날 20:00 | 0시간 |
| 샌프란시스코 | UTC−8 | 전날 16:00 | 2시간 | UTC−7 | 전날 17:00 | 1시간 |
겹침이 하루 2시간 이하인 도시(베를린, 런던, 뉴욕, 샌프란시스코)와 일하는 팀이라면 실시간 스탠드업은 누군가의 이른 아침이나 늦은 밤을 요구합니다. 반대로 도쿄나 호치민처럼 7시간 이상 겹치면 짧은 실시간 모임도 부담이 작습니다. 겹침이 아주 짧다면 그 1~2시간을 스탠드업이 아니라 서로의 블로커를 푸는 데 쓰는 편이 효율적입니다.
직군별 작성 예시
세 칸의 형식은 같아도 직군에 따라 쓰는 내용의 결이 다릅니다. 아래는 모두 가상의 예시입니다.
- 고객지원 담당 — 어제: 환불 문의 티켓 18건 중 16건 처리, 2건은 결제사 확인 대기. 오늘: 대기 중 2건 회신, 자주 오는 배송 문의 답변 템플릿 정리. 블로커: 결제사 담당자 회신이 없어 환불 일정 안내가 불가능, 재무팀에 연락 요청.
- 디자이너 — 어제: 결제 화면 시안 2안 제작, 개발팀 피드백 수렴. 오늘: 선택된 안의 상태별(오류·로딩) 화면 추가, 디자인 시스템 버튼 규격 업데이트. 블로커: 결제 오류 문구의 톤을 정할 사람이 없음, 기획자의 결정 요청.
- 1인 프리랜서와 스터디 그룹 — 팀이 없어도 쓸 수 있습니다. 어제: 의뢰인 A 로고 2차 수정본 전달. 오늘: B사 견적서 작성, 포트폴리오 사진 교체. 블로커: 의뢰인 A의 피드백 미수신, 내일 오전까지 없으면 재문의. 스스로 읽는 용도라도 "요청 대상과 기한"을 적는 습관이 나중에 흐름을 되짚게 해 줍니다.
쌓인 기록을 읽는 법
한 주 정도 모이면 두 가지를 확인해 보세요. 첫째, 같은 항목이 3일 넘게 "오늘 할 일"에 머물러 있다면 그 일은 크기를 잘못 잡았거나 블로커가 숨어 있다는 신호입니다. 둘째, 블로커가 며칠째 같은 내용이면 작성자가 아니라 팀이 해결해야 할 문제입니다. 이 노트의 상단 통계는 저장된 기록 수와 블로커가 적힌 기록 수를 보여 주므로, 블로커 비율이 계속 높다면 스프린트 계획부터 점검해 볼 만합니다.
팀 채널에서 운영하는 규칙 예시
글로 하는 스탠드업은 규칙이 느슨하면 금방 흐지부지됩니다. 원격팀에서 흔히 합의하는 항목은 이렇습니다. 작성 마감은 각자 근무 시작 후 1시간 이내로 하고, 한 사람의 글은 다섯 줄을 넘기지 않습니다. 블로커는 요청 대상을 @멘션으로 지정하고, 요청받은 사람은 같은 근무일 안에 "확인함" 이상의 반응을 남깁니다. 휴가나 외근으로 쓰지 못하는 날은 "부재"라고 한 줄만 남겨 읽는 사람이 기다리지 않게 합니다. 이런 규칙은 팀 상황에 맞게 바꾸되, 처음 2주 동안은 바꾸지 않고 그대로 운영해 본 뒤 조정하는 편이 낫습니다. 규칙이 자주 바뀌면 팀원이 형식 자체를 익히는 데 에너지를 씁니다.
글이 길어지거나 같은 블로커 논의가 스레드에서 두 번 오가면 그때는 15분 통화로 바꾸는 것이 빠릅니다. 비동기 방식의 목적은 모임을 없애는 것이 아니라 꼭 필요한 순간에만 실시간으로 모이는 것입니다.
입력과 버튼의 실제 동작
- 날짜 칸: 처음 열면 이 기기의 오늘 날짜(현지 시간 기준)가 들어갑니다. 지난 날짜를 골라 그날의 기록을 뒤늦게 남길 수도 있습니다.
- 저장 조건: 세 칸 중 하나라도 내용이 있어야 저장되며, 앞뒤 공백은 지워집니다. 빈 칸은 복사할 때 어제·오늘은 "-", 블로커는 "없음"으로 나옵니다.
- 가져오기 버튼: 선택한 날짜보다 앞선 기록 중 "오늘 할 일"이 적힌 가장 가까운 날의 내용을 어제 칸에 채웁니다. 이미 어제 칸에 적은 내용은 대체되므로 먼저 가져온 뒤 고쳐 쓰세요.
- 복사 형식: 날짜, "어제: …", "오늘: …", "블로커: …"의 네 줄 일반 텍스트입니다. 슬랙이나 팀즈 같은 메신저에서는 줄바꿈이 그대로 유지됩니다.
- 정렬: 기록은 날짜가 최근인 순으로 보이며 저장한 순서와는 무관합니다.
흔한 실수
- 상태 보고로 변질. 스탠드업은 상사에게 보고하는 자리가 아니라 동료가 서로 도울 수 있게 정보를 맞추는 자리입니다.
- 문제 해결을 글 안에서 하려는 것. 블로커는 한 줄로 알리고 논의는 별도 스레드나 짧은 통화로 옮기세요.
- 사실상 일기가 되는 것. 감정 상태는 팀이 합의했을 때만 짧게 덧붙이세요.
- 기록 없이 습관만 요구하는 것. 읽는 사람이 없으면 쓰는 사람도 곧 그만둡니다. 팀 채널에 붙여 넣은 글에는 반응이라도 남기는 문화가 필요합니다.
한계
이 도구에는 팀원 간 공유, 알림, 담당자 지정 기능이 없습니다. 팀이 함께 쓰려면 각자 작성한 뒤 항목별 "복사" 버튼으로 팀 메신저에 붙여 넣는 식으로 운영하세요. 일정 관리나 작업 추적은 다른 도구가 더 적합하므로 아래 관련 도구를 함께 보세요.
기록은 어디에 저장되나요? (사내 정보 주의)
이 페이지의 코드는 입력한 내용을 브라우저의 로컬 저장소(localStorage, 키daily-standup-notes-v1)에만 저장하며 서버로 전송하지 않습니다. 따라서 같은 기기·같은 브라우저 프로필에서만 보이고, 다른 기기와 동기화되지 않으며, 암호화되지 않은 상태로 보관됩니다. 사이트 데이터를 지우거나 시크릿 창을 닫으면 사라질 수 있으니 필요한 내용은 복사해서 따로 보관하세요. 삭제는 각 기록의 ✕, "전체 초기화" 버튼, 브라우저의 사이트 데이터 삭제로 할 수 있습니다. 고객사 이름, 미공개 제품명, 장애 원인 같은 사내 기밀은 회사의 보안 규정을 먼저 확인하고, 공용 PC에서는 입력하지 마세요.
자주 묻는 질문
같은 날짜에 두 번 저장하면 어떻게 되나요?
같은 날짜의 기록이 이미 있으면 덮어쓸지 확인 창이 뜹니다. 확인하면 해당 날짜의 기록이 새 내용으로 바뀌고, 취소하면 저장하지 않습니다. 하루에 한 건만 남도록 한 것입니다.
여러 명이 같은 브라우저에서 각자 기록을 남길 수 있나요?
이 도구는 브라우저(기기)에 기록을 저장하므로 같은 브라우저를 여러 명이 쓰면 기록이 섞입니다. 팀원마다 자기 기기에서 작성하고 복사해 메신저로 공유하세요.
기록이 다른 사람에게 자동으로 전송되나요?
아니요. 도구 코드는 어디로도 전송하지 않습니다. 공유하려면 "복사"를 눌러 직접 붙여 넣어야 합니다.
주말이나 휴가 날짜는 어떻게 하나요?
그날은 기록하지 않아도 됩니다. "직전 기록 가져오기"는 선택한 날짜보다 이전 중 가장 가까운 기록을 사용하므로 연휴 뒤에도 마지막 기록의 오늘 할 일을 이어받을 수 있습니다.
세 가지 외에 항목을 더 추가할 수 있나요?
현재는 세 칸으로 고정되어 있습니다. 추가로 공유할 내용(도움 요청, 학습한 것 등)은 오늘 할 일이나 블로커 칸에 한 줄로 덧붙여 쓰세요.
어제 한 일을 못 적었는데 소급해서 써도 되나요?
됩니다. 날짜 칸에서 해당 날짜를 선택해 저장하면 그 날짜의 기록으로 남습니다. 다만 며칠이 지나면 기억이 흐려지니 그날 퇴근 전에 한두 줄이라도 메모해 두는 편이 정확합니다.
블로커가 없는 날은 칸을 비워도 되나요?
비워도 저장되지만, 복사하면 "없음"으로 표시됩니다. 읽는 사람이 빠뜨렸는지 아닌지 헷갈리지 않게 필요한 날에는 "없음, 단 내일 배포 권한 확인 필요"처럼 한 줄 덧붙이는 것이 더 좋습니다.
글 스탠드업을 몇 주 해 보고 효과가 있는지 어떻게 판단하나요?
팀마다 기준이 다르지만 블로커가 해결되기까지 걸리는 시간, 같은 질문이 반복되는 빈도, 불필요한 회의가 줄었는지를 팀이 직접 비교해 보세요. 이 도구의 통계는 기록 수와 블로커 비율만 보여 줄 뿐 팀 성과를 평가하지 않습니다.
함께 쓰기 좋은 도구
- 회의 액션아이템 트래커: 스레드에서 나온 후속 조치를 끝까지 추적할 때
- 1:1 미팅 템플릿 도구: 매니저 면담에서 지난 기록을 다시 짚을 때
- RAID 로그 도구: 반복되는 블로커를 리스크·이슈로 분류해 관리할 때
- 시간대 변환기: 팀원들의 근무 시간이 겹치는 구간을 찾을 때