이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 Jira를 이슈 트래킹 도구로 사용하며 스프린트를 관리한 경험이 있습니다. 초반에는 이슈를 생성만 하고 상태를 업데이트하지 않아 실제 진행 상황과 보드가 달라지는 문제가 생겼고, 이후 작업 시작 시 In Progress로 변경하는 것을 팀 규칙으로 정했습니다. 에픽과 스토리, 태스크로 계층을 나누는 방식을 익혔는데, 너무 세밀하게 쪼개면 관리 비용이 높아져 실용적인 단위를 찾는 것이 중요했습니다.
스프린트 번다운 차트를 매주 확인하면서 남은 일정과 진행 속도가 맞지 않는 시점을 조기에 발견해 일정을 조정할 수 있었습니다. Confluence와 연동해 스프린트 회고 문서를 이슈와 연결해두니, 나중에 비슷한 문제가 생겼을 때 이전 맥락을 빠르게 찾을 수 있었습니다. 협업 도구는 팀이 같은 기준으로 사용할 때만 효과가 생긴다는 결을 얻었습니다.
인턴 때 Jira를 버그 트래킹 도구로 집중 사용한 경험이 있습니다. QA 팀이 버그를 이슈로 등록하면 개발팀이 우선순위를 정해 처리하는 워크플로였는데, 이슈 상태가 Resolved인데 실제로 배포가 안 된 경우가 생겨 혼선이 있었습니다. 배포 완료와 Closed를 구분하는 커스텀 상태를 추가하고, 배포 태그를 이슈에 연결하는 방식으로 해결했습니다.
JQL 필터를 배우면서 특정 버전에 포함된 버그 목록을 한 번에 뽑는 쿼리를 만들었고, 릴리즈 전 필수 점검 목록을 자동으로 생성하는 용도로 썼습니다. 대시보드에 버그 유입률과 처리율을 주간 단위로 집계해 팀과 공유했는데, 숫자가 보이자 이슈 처리 속도가 자연스럽게 빨라지는 효과가 있었습니다.
도구는 사용 방식을 팀이 합의해야 효과가 나온다는 것을 이 경험에서 배웠습니다.
팀 프로젝트에서 에픽-스토리-서브태스크 계층 구조를 처음 설계해보면서 시행착오를 겪었습니다. 처음에는 모든 작업을 서브태스크로 쪼갰는데, 이슈 수가 너무 많아지니 진행 상황 파악이 오히려 어려워졌습니다. 스토리는 사용자 가치 기준, 서브태스크는 개발 단위로 구분하는 원칙을 세우고 나서 구조가 자리를 잡았습니다. 스토리마다 완료 기준(Definition of Done)을 미리 적어두면 PR 리뷰에서 이 기능이 완성됐는가를 빠르게 판단할 수 있었습니다. 계층 구조의 가장 큰 효과는 팀장이 에픽 단위 진행률을 보고 전체 흐름을 파악하는 시간이 줄었다는 것이었습니다. 한계는 계층이 복잡해질수록 이슈 업데이트를 잊는 팀원이 생긴다는 점인데, PR 머지 시 서브태스크를 Done으로 자동 전환하는 방식으로 일부 보완했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부동산플래닛 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.