이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Agile 방법론을 적용한 프로젝트 경험은 학부 캡스톤 팀 프로젝트에서 있었습니다. 2주 스프린트로 운영하면서 매 스프린트 초반에 백로그를 정리하고 스프린트 목표를 설정했습니다. 초반에는 백로그가 계속 바뀌면서 스프린트 중반에 방향이 흔들리는 문제가 있었고, 이후 스프린트 시작 후엔 추가 요구사항은 다음 스프린트로 미루는 원칙을 세웠습니다. 가장 도움이 됐던 것은 스프린트 회고(retrospective)였습니다. 잘된 것과 개선할 것을 팀이 함께 정리하면서 다음 스프린트에서 반복 실수가 줄었습니다. Agile은 이론보다 루틴을 지키는 규율이 효과를 결정한다는 것을 배웠습니다. 앞으로도 Agile 프로세스를 운영할 때 회고와 스프린트 목표 고정을 최우선으로 지키는 방식을 유지하겠습니다.
방법론의 힘은 규칙을 지킬 때 나옵니다.
Agile 방식으로 운영했던 사이드 프로젝트에서 가장 오래 붙잡았던 문제가 스프린트 항목의 완료 기준 부재였습니다. 백로그를 만들어 두기는 했는데 각 항목에 완료 조건이 적혀 있지 않아서 스프린트가 끝날 때마다 '이게 끝난 건지'를 팀이 각자 다르게 판단하는 일이 반복됐습니다. 이후 완료 기준(Definition of Done)을 항목별로 한 줄씩 적는 방식을 도입했더니 리뷰 때 논쟁이 눈에 띄게 줄었습니다. 스프린트가 2주였는데 1주차와 2주차의 작업량이 매번 크게 차이나는 패턴이 있어서 태스크를 반일 단위로 쪼개 배분하는 방식으로 바꿨습니다. Agile은 프레임워크보다 팀이 합의한 작은 규칙들이 실제 운영을 결정한다는 것을 배웠고, 새 팀에 들어갈 때 완료 기준부터 먼저 맞추는 것이 습관이 됐습니다.
Agile 프로젝트에서 가장 기억에 남는 변화는 회고에서 나온 말이 다음 스프린트에 실제로 반영됐을 때였습니다. 이전 팀에서는 회고가 불만을 털어놓는 시간으로 끝났는데, '잘된 것 1개, 바꿀 것 1개'만 다음 스프린트 백로그에 넣는 원칙을 세운 뒤부터 분위기가 달라졌습니다. 팀원 한 명이 코드 리뷰가 너무 늦어 다음 작업에 걸린다고 말했고, 그 주부터 PR 오픈 후 24시간 내 리뷰를 팀 규칙으로 정했습니다. 단순한 규칙이었는데 스프린트 후반에 급하게 합치는 일이 확연히 줄었습니다. 소통 면에서는 일 얘기를 가능한 한 공개 채널에 남기는 방식이 나중에 결정 근거를 찾는 데 큰 도움이 됐습니다. 회고에서 나온 말이 다음 스프린트를 바꾼다는 경험이 쌓이면서 팀원들이 회고에 더 솔직하게 임하는 변화가 느껴졌습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.