이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
스크럼을 처음 접한 것은 팀 프로젝트에서였고, 스프린트 주기와 세 가지 역할을 중심으로 구조를 잡았습니다. 스프린트는 2주 단위로 설정했고, 스프린트 플래닝에서 백로그를 우선순위에 따라 정리해 이번 스프린트에서 처리할 항목을 팀이 함께 선택했습니다.
데일리 스크럼은 처음에 형식적으로 진행됐는데, 어제 한 것·오늘 할 것·블로커 세 가지로 구조를 잡으니 실제로 막힌 부분이 빨리 드러나고 도움 요청이 자연스러워졌습니다. 스프린트 리뷰에서 완성된 것을 시연하고, 회고에서는 잘된 것과 개선할 것을 각각 정리했습니다. 회고가 처음에는 어색했는데, 구체적인 행동 개선안으로 이어질 때 다음 스프린트에서 차이가 생긴다는 것을 경험했습니다. 한계는 팀원 모두가 스크럼 원칙에 익숙하지 않으면 도구가 오히려 오버헤드가 된다는 점으로, 팀 공감대가 먼저라는 결을 배웠습니다.
팀 프로젝트에서 Scrum Master 역할을 맡아 진행했습니다. SM으로서 주된 역할은 스프린트가 원활하게 돌아가도록 장애를 제거하는 것이었는데, 가장 자주 발생한 장애는 외부 API 연동 일정이 불확실해 스프린트 계획이 틀어지는 것이었습니다. 외부 의존 항목을 스프린트 초반에 먼저 확인하는 규칙을 만들었고, 불확실한 항목은 버퍼로 분리했습니다. 스프린트 속도(Velocity)를 3스프린트 이상 추적하면서 팀이 소화할 수 있는 포인트를 현실적으로 파악하게 됐고, 계획 수립이 훨씬 정확해졌습니다.
번다운 차트가 중반부터 평평해지는 패턴이 나타났는데, 이는 스프린트 중간에 새 항목이 추가되는 것이 원인이었습니다. 팀과 스프린트 중 신규 항목 추가를 금지하는 합의를 만들자 예측 가능성이 높아졌습니다. 스크럼의 가치는 프레임워크보다 팀이 만드는 합의에 있다는 것을 경험했습니다.
스크럼에서 가장 효과가 컸던 이벤트는 스프린트 회고였습니다. 처음에는 잘된 것과 아쉬운 것을 나열하는 수준이었는데, 아쉬운 것에서 구체적인 행동 개선안을 하나씩 뽑아 다음 스프린트 백로그에 넣는 방식으로 바꿨습니다. 코드 리뷰 지연이 반복됐는데, 회고에서 리뷰 요청 후 1일 이내 첫 댓글 원칙을 팀 규칙으로 만들었습니다. 이 원칙이 다음 스프린트에서 실제로 지켜졌고 병목이 줄었습니다. 한계도 분명했는데, 팀원 중 스크럼을 형식적으로 여기는 경우 회고가 형식만 남는 경우가 생겼습니다. 데일리 스크럼이 보고 형식으로만 돌아가면 블로커가 나오지 않고 회의 시간이 낭비됩니다. 스크럼이 도구가 되려면 팀 공감대가 먼저라는 것, 그리고 왜 이 이벤트가 필요한지를 반복해서 설명하는 역할이 중요하다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.