이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
여러 팀 프로젝트를 거치면서 애자일(스크럼) 방식을 가장 선호하게 됐습니다. 초기에 폭포수 방식으로 진행했을 때, 요구사항이 중간에 바뀌자 완성된 기능을 다시 갈아엎는 상황을 겪었습니다. 스크럼으로 전환하고 2주 단위 스프린트를 도입하니, 변경이 생겨도 다음 스프린트에서 반영할 수 있어 팀 전체 방향이 자주 조율됐습니다.
스프린트 회고를 통해 무엇이 느렸는지를 주기적으로 점검하는 구조가 팀 작업 방식을 꾸준히 개선해줬고, 이것이 가장 큰 장점이었습니다. 방법론 자체보다 팀이 짧은 주기로 피드백을 교환하는 습관이 핵심이라고 느꼈고, 지금도 작업 단위를 작게 쪼개 빨리 검증하는 방향을 선호합니다.
스크럼을 경험하면서 단점도 분명히 느꼈습니다. 스프린트 도중 요구사항이 바뀌면 현재 진행 중인 작업을 어떻게 처리할지가 팀마다 다른데, 원칙적으로는 다음 스프린트로 미루지만 실제로는 중간에 끼워 넣는 경우가 생겼습니다. 스프린트 목표가 자주 흔들리면 스크럼의 핵심 구조가 깨진다는 것을 이때 경험했습니다. 스크럼 의식(데일리 스크럼, 회고, 플래닝)이 팀 규모가 작으면 오버헤드로 느껴지는 경우도 있었습니다. 2명이 진행하는 프로젝트에서 공식 스크럼을 따랐더니 의식 자체에 시간이 너무 많이 들어서, 핵심만 남기고 가볍게 조정했습니다.
어떤 방법론도 팀 상황에 맞게 조정해야 한다는 것을 이 경험에서 배웠습니다. 요구사항 변경이 잦고 긴급 작업이 많은 상황에서는 스프린트 단위보다 칸반의 흐름 기반 관리가 더 현실적이었습니다. 방법론 선택은 팀 규모, 요구사항 안정성, 배포 빈도를 먼저 보고 결정하는 것이 맞다는 것을 여러 경험에서 배웠습니다.
스크럼의 회고를 처음에는 형식적으로 진행했는데, 무엇이 잘됐고 무엇이 안됐는지 나열만 하고 끝나는 경우가 많았습니다. 그냥 이야기하고 넘어가면 다음 스프린트에서 같은 문제가 반복됐습니다. 회고에서 나온 개선 항목을 다음 스프린트 플래닝에서 실제 태스크로 만드는 방식으로 바꾸니 회고 내용이 실제 작업 방식 변화로 이어졌습니다. 예를 들어 PR 리뷰가 쌓인다는 문제가 나왔을 때, "앞으로 빨리 리뷰하자"로 끝내지 않고 "PR 리뷰 응답을 24시간 이내로 정하고 플래닝에 리뷰 시간을 미리 넣는다"는 구체 액션으로 바꿨습니다.
회고가 불평 나열이 아니라 절차 개선으로 끝나는 구조를 만드니 팀 작업 방식이 실제로 바뀌는 것을 경험했습니다. 방법론의 가치는 의식 자체보다 의식이 만들어내는 개선 루프에 있다는 것을 배웠습니다. 회고 결과가 절차로 남지 않으면 다음 회고에서 같은 이야기가 반복된다는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.