엔지니어링 팀을 위한 최고의 스탠드업 질문 (힌트: 그 세 가지가 아닙니다)
엔지니어링 팀의 고전적인 스탠드업 질문은 시그널이 아닌 상태 보고 쇼만 만듭니다. 실제로 중요한 것을 드러내는 더 나은 질문을 소개합니다.
By Ellis Keane · 2026-03-26
1790년, 영국 해군은 당직 보고 프로토콜을 공식화했습니다. 4시간마다 당직 장교는 교대자에게 간략한 보고를 전달했습니다: 해황, 풍향 변화, 목격한 선박, 그리고 교대 장교가 즉각 주의를 기울여야 할 사항. 이 형식은 철저하게 효율적이었습니다 – 선원들의 집중력이 짧아서가 아니라, 분쟁 해역의 프리깃함은 의례적인 낭비를 허용할 수 없었기 때문입니다. 변화한 것, 위험한 것, 다음 사람의 판단이 필요한 것을 보고했습니다. 나머지는 모두 노이즈였습니다.
약 230년 후, 엔지니어링 팀의 스탠드업 질문은 이를 완전히 역전시켰습니다. 의식은 유지하면서(같은 시간, 같은 사람들, 같은 방 또는 Zoom 통화) 시그널을 제거했습니다. "어제 무엇을 했나요?"는 당직 보고가 아닙니다. 코드를 작성하고 싶은 사람들에게 매일 공개적으로 시행되는 성과 평가입니다.
(그리고 네, 저도 다른 누군가가 이야기하는 동안 머릿속으로 제 업데이트를 리허설했던 스탠드업에 많이 서 있었습니다. 당신도 그렇겠죠. 그렇지 않은 척하지 맙시다!)
저도 몇 년 동안 스탠드업을 제대로 진행하지 못했습니다. 솔직히 고백합니다. 의무적으로 순서를 돌며, 한 시간 안에 잊어버릴 업데이트를 수집하고, 왜 회고에서 같은 문제가 계속 나오는지 의아해했습니다. 질문 자체가 병목이었음을 깨닫는 데 당혹스러울 만큼 오랜 시간이 걸렸습니다 – 답변하는 사람들이 아니라.
세 가지 기본 질문과 그 문제점
다들 알고 계시죠. "어제 무엇을 했나요? 오늘은 무엇을 할 건가요? 차단 요소가 있나요?"
엔지니어링 팀의 스탠드업 질문으로서 이것들은 원칙적으로는 나쁘지 않지만, 실제로는 매우 특정한 역기능을 만들어냅니다. "어제 무엇을 했나요"는 관련성이 아닌 기억을 최적화합니다 – 실제로 중요한 두 가지가 아닌 누군가의 화요일 시간순 이야기가 나옵니다. "오늘은 무엇을 할 건가요"는 점심까지 아무도 기억하지 못할 소규모 프로젝트 계획을 만들어냅니다. 그리고 "차단 요소가 있나요"는 기본적으로 "없어요"로 답변됩니다 – 한번은 주니어 엔지니어가 6일 연속으로 "차단 요소 없음"이라고 말하면서 팀 전체 앞에서 드러내고 싶지 않았던 인증 문제로 조용히 막혀 있던 것을 봤습니다. 막혀 있다는 것을 공개적으로 인정하려면 대부분의 팀이 아직 쌓지 못한 심리적 안전감이 필요합니다.
결과는 제가 '상태 보고 쇼'라고 부르는 것입니다 – 15분 동안 사람들이 서로에게 작업 요약을 낭독하고, 그 후 모두가 회의 시작 전과 정확히 같은 정보를 가지고 해산합니다. 생산적으로 느껴집니다. 하지만 생산적이지 않습니다.
전통적인 세 가지 스탠드업 질문은 정보 흐름이 아닌 책임에 최적화되어 있습니다. 작업이 일어났다는 사실은 알려주지만, 지금 당장 주의가 필요한 것은 알려주지 않습니다.
더 나은 엔지니어링 팀 스탠드업 질문 (드러내는 것 기준 분류)
다음 질문들은 보편적인 템플릿이 아닙니다 – 팀의 현재 어려움에 맞는 2~3개를 선택하고, 매달 교체하며, 리허설된 답변이 나오기 시작하면 은퇴시키세요.
위험을 드러내는 질문
- "지금 가장 위험한 것이 무엇인가요?" – 제가 가장 좋아하는 스탠드업 질문입니다! 어제의 성과를 건너뛰고 오늘 잘못될 수 있는 것에 직접 착지합니다. 사람들은 위험한 것이 무엇인지 알고 있지만, 직접 물어보지 않으면 자발적으로 말하지 않습니다.
- "예상보다 오래 걸리는 것이 있나요?" – "차단 요소가 있나요"보다 조용하지만 훨씬 더 많은 것을 드러냅니다. 예상보다 오래 걸리는 작업은 종종 아직 이름이 붙지 않은 문제의 첫 번째 증상입니다.
- "이번 주 가장 자신 없는 것이 무엇인가요?" – 일일 스탠드업보다 주간 동기화에 더 적합하지만, 뒤를 돌아보는 활동 로그 대신 조기 경고 목록을 제공합니다.
의존성을 드러내는 질문
- "누군가를 기다리고 있는 곳이 있나요?" – 이것이 의존성 감지기입니다. 제가 함께 일해온 대부분의 팀에서 엔지니어링 작업은 기술적 복잡성보다 인식되지 않은 의존성으로 인해 더 많이 막힙니다. 3일 동안 열려 있는 PR, 이루어지지 않은 디자인 검토, 조용히 미뤄진 결정 – 이것들이 실제 차단 요소입니다, 아무도 그렇게 부르지 않더라도.
- "오늘 누구와 이야기해야 하나요?" – 더 짧고, 더 실행 가능합니다. 두 사람이 모두 "서로"라고 답하면, 하루치 비동기 왔다갔다를 방을 같이 씀으로써 절약했습니다. (이것이 실제로 전체 스프린트를 구한 적이 있습니다 – 사람들은 5미터를 걸어가서 이야기하는 것보다 며칠 동안 병렬로 혼란스러워한다는 것이 밝혀졌습니다.)
학습을 드러내는 질문
- "마지막 스탠드업 이후 무엇이 놀라웠나요?" – 아키텍처 오해를 조기에 파악하는 데 탁월합니다. (그리고 믿어주세요, 아키텍처 오해는 항상 있습니다.) 엔지니어가 API가 문서와 다르게 작동한다는 것을 발견하거나, 마이그레이션이 티켓이 암시한 것보다 더 많은 테이블에 영향을 미친다는 것을 발견하면, 그 놀라움은 어떤 상태 업데이트보다 팀에게 더 가치 있습니다.
- "월요일에 알았더라면 좋았을 것을 지금 알고 있나요?" – 주간 미팅에 더 유용합니다. 하지만 다음 스프린트까지 잊혀질 조직 지식을 포착합니다.
사기를 드러내는 질문（드물게 사용）
- "오늘 에너지가 1~5 척도에서 어떤가요?" – 리드가 수년에 걸쳐 진심으로 신뢰를 쌓은 팀에서 딱 한 번 잘 작동하는 것을 봤습니다. 대부분의 맥락에서는 침입적으로 느껴집니다. 사용하기 전에 팀을 파악하세요.
- "이 작업이 흥미롭나요?" – 편안하게 들리지만, 지속적으로 지루한 작업은 리텐션 시그널입니다. 누군가가 3스프린트 연속으로 마이그레이션 작업을 하고 있다면, 이 질문이 그렇게 말할 허가를 줍니다.
그룹 스탠드업 vs 1:1: 다른 형식에는 다른 질문이 필요합니다
이 엔지니어링 팀 스탠드업 질문들이 모두 같은 미팅에 속하는 것은 아닙니다. 그룹 설정에서는 빠르게 답할 수 있고 참석자 모두에게 유용한 정보를 생산하는 질문이 필요합니다. 1:1에서는 더 길고 더 성찰적인 질문을 위한 공간이 있습니다.
그룹 스탠드업 (2개 선택, 주 단위로 교체):
| 질문 | 드러내는 것 | 1인당 시간 | |------|-----------|-----------| | 지금 가장 위험한 것이 무엇인가요? | 미래 지향적 위험 | ~30초 | | 누군가를 기다리고 있는 곳은? | 의존성 | ~20초 | | 무엇이 놀라웠나요? | 숨겨진 복잡성 | ~30초 |
1:1 체크인 (2~3개 선택):
| 질문 | 드러내는 것 | 시간 | |------|-----------|------| | 월요일에 알았더라면 좋았을 것은? | 학습 격차 | 2~3분 | | 예상보다 오래 걸리는 것은? | 새로운 위험 | 1~2분 | | 이 작업이 흥미롭나요? | 참여도와 사기 | 1~2분 | | 제가 차단 해제해줄 수 있는 한 가지는? | 매니저 액션 아이템 | 1분 |
그룹 스탠드업은 짧고 유용해야 합니다. 1:1은 탐색의 여유가 있습니다 – 청중은 들은 것에 실제로 행동할 수 있는 맥락을 가진 한 사람이기 때문입니다.
안티패턴: 더 많은 작업을 만드는 질문
일부 인기 있는 스탠드업 "개선"은 실제로 상황을 악화시킵니다. 형식이 엔지니어에게 미팅 전에 서면 업데이트를 준비하게 한다면, 스탠드업 전 스탠드업 – 의식을 준비하는 의식 – 을 만든 것입니다. 작업 완료율에 대한 수치 추정을 요구한다면（"API 마이그레이션이 몇 퍼센트 완료됐나요?"）, 낙관적 반올림을 장려하는 마이크로 추적 연습을 구축한 것입니다. 그리고 통화 중에 Linear 보드를 업데이트하게 한다면, 동기적 대화를 15분 동안 사람들이 타이핑하는 것을 보는 시간으로 바꾼 것입니다.
（물론 아이러니는, 이 모든 것이 "스탠드업을 더 효율적으로 만들기 위해" 도입됐다는 것입니다. 의식은 사용 가능한 시간을 채울 때까지 성장하고, 그 후 정중하게 더 요청합니다.）
스탠드업 개선에 준비 시간이 필요하다면, 오버헤드를 줄인 것이 아니라 추가한 것입니다. 최선의 스탠드업 질문은 30초 이내에 유용한 답변을 만들어내고, 미팅 전에 아무도 숙제를 할 필요가 없는 것입니다.
내일부터 시작할 수 있는 실용적인 세트
2주 동안 시도할 구체적인 것을 원한다면, 다음을 추천합니다:
일일 스탠드업 (3가지 질문, 엄격한 15분 타임박스):
- "지금 가장 위험한 것이 무엇인가요?" – 차단 요소로 변하기 전에 문제를 포착합니다.
- "누군가를 기다리고 있는 곳이 있나요?" – 보이지 않는 의존성을 가시화합니다.
- "팀이 알아야 할 것이 있나요?" – 개방형 전체 포괄, 하지만 "중요한 것만"으로 프레이밍됩니다.
그게 전부입니다. "어제 무엇을 했나요" 없음 – 도구들이 이미 그 정보를 Linear 보드, GitHub 활동 피드, Slack 스레드에 가지고 있습니다. "오늘은 무엇을 할 건가요" 없음 – 스프린트 계획이 최신이라면 이 질문은 아무것도 추가하지 않습니다. 그냥: 무엇이 위험한지, 무엇이 막혀 있는지, 무엇이 놀라운지.
2주 후에도 스탠드업이 여전히 의식처럼 느껴진다면, 문제는 아마 질문이 아닐 것입니다. 일일 동기 체크인이 팀에 맞는 형식이 아닐 수 있습니다 – 그것은 도달하기에 완전히 합리적인 결론입니다. 영국 해군은 18세기에 당직 보고 형식을 파악하고, 결정적으로, 분기마다 재설계하는 것을 멈췄습니다. 때로는 최선의 프로세스 개선은 프로세스가 필요하지 않다는 것을 인정하는 것입니다.
"영국 해군은 18세기에 당직 보고 형식을 파악하고, 결정적으로, 분기마다 재설계하는 것을 멈췄습니다. 때로는 최선의 프로세스 개선은 프로세스가 필요하지 않다는 것을 인정하는 것입니다." – Chris Calo
Sugarbug이 팀의 활동을 자동으로 표시합니다 – 스탠드업이 상태 보고를 건너뛰고 중요한 것에 집중할 수 있도록.
Q: 엔지니어링 팀을 위한 최고의 스탠드업 질문은 무엇인가요? A: 솔직히, "지금 가장 위험한 것이 무엇인가요?"와 "누군가를 기다리고 있는 곳이 있나요?"는 전통적인 세 가지보다 훨씬 더 멀리 갈 수 있습니다. 엔지니어링 팀의 고전적인 스탠드업 질문은 상태 낭독을 최적화합니다 – 어제 누가 무엇을 했는지 – 실제로 하루를 어떻게 보내는지 바꾸는 위험과 의존성을 드러내는 것이 아니라.
Q: Sugarbug이 엔지니어링 스탠드업 자동화에 도움이 되나요? A: Sugarbug은 Linear, GitHub, Slack, Figma 등의 엔지니어링 도구를 지식 그래프로 연결하여 마지막 스탠드업 이후 변경된 사항을 자동으로 표시합니다. 어제 한 일을 낭독하게 하는 대신 Sugarbug이 보여주므로, 스탠드업은 상태 보고 대신 인간의 판단이 필요한 대화에 집중할 수 있습니다.
Q: 엔지니어링 스탠드업은 얼마나 걸려야 하나요? A: 5~8명 팀의 경우 15분이 상한선입니다. 더 오래 걸린다면, 너무 많은 저가치 출력을 만드는 질문을 하고 있거나（안녕, "어제 무엇을 했나요?"）, 팀이 별도 미팅이 필요한 문제를 해결하고 있는 것입니다. 1인당 2분이 목표로 삼을 합리적인 기준입니다.
Q: Sugarbug이 일일 스탠드업 미팅을 대체할 수 있나요? A: Sugarbug은 스탠드업을 대체하지 않습니다 – 스탠드업의 상태 보고 부분을 대체합니다. GitHub, Linear, Slack의 최근 활동을 단일 뷰로 가져옴으로써 "어제 무엇을 했나요" 질문에 자동으로 답이 됩니다. 남는 것은 동기적인 것에서 실제로 이익을 얻는 스탠드업 부분입니다: 위험, 의존성, 그리고 방의 주의가 필요한 결정들.
Q: 스탠드업 질문을 효과적으로 만드는 것은 무엇인가요? A: 30초 이내에 새로운 정보를 만들어내고, 준비가 전혀 필요 없고, 팀이 이미 알지 못했던 것을 드러내는 것입니다. 사람들이 매일 같은 리허설된 답변을 주기 시작하면（알 수 있습니다 – 들릴 것입니다）, 그 질문을 은퇴시키고 다른 것을 시도하세요. 최선의 스탠드업 질문에는 유효 기간이 있습니다, 그리고 그것은 괜찮습니다.
스탠드업이 실제 결정보다 상태 낭독에 더 많은 시간을 보낸다면, Sugarbug이 보고 부분을 자동으로 처리할 수 있습니다 – 15분이 실제로 방에 사람이 필요한 것들에 쓰이도록.