이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Jira와 Confluence를 처음 실제로 써본 것은 수업 팀 프로젝트에서였습니다. Jira에서는 스프린트를 2주 단위로 나눠 이슈를 등록하고 상태를 관리했는데, 어떤 작업이 어디서 막혀 있는지를 한눈에 볼 수 있었습니다. Confluence에는 회의록과 설계 문서를 Jira 이슈와 연결해 작업 배경을 같은 공간에서 확인할 수 있게 정리했습니다. 처음에는 이슈 작성 기준이 팀원마다 달라서 같은 작업이 중복 등록되거나 너무 큰 단위로 묶이는 문제가 있었습니다. 이를 해결하기 위해 이슈 작성 가이드를 문서화했는데, 이 경험에서 도구 자체보다 팀의 사용 기준을 맞추는 것이 더 중요하다는 것을 배웠습니다. 이후 다른 프로젝트에서도 이슈 작성 기준을 처음부터 합의한 덕분에 훨씬 수월하게 운영할 수 있었습니다.
Jira를 쓸 때 제가 중요하게 본 건, 큰 작업을 추적 가능한 단위로 쪼개는 일입니다. 수업 팀 프로젝트에서 한 기능을 통째로 이슈 하나에 담았더니, 어디까지 됐는지가 안 보여 진척을 알 수 없었습니다. 그래서 저는 큰 목표를 에픽으로 두고 그 아래 스토리와 서브태스크로 나눠, 무엇이 어디서 막혔는지를 한눈에 보이게 했습니다. Confluence에는 회의록과 설계 문서를 Jira 이슈와 연결해 작업 배경을 같은 공간에서 보게 정리했습니다. 다만 제 한계도 인정합니다. 처음엔 어디까지 쪼갤지 기준이 없어, 너무 잘게 나누면 관리가 번거롭고 크게 묶으면 추적이 안 됐습니다. 그 적정 단위를 잡는 감각이 부족했습니다. 또 저는 수업 규모라, 스프린트 속도로 일정을 예측하거나 JQL로 복잡한 필터를 짜 본 경험은 없습니다. 그래서 이슈를 계층으로 쪼개는 토대 위에, 그 단위를 일정 예측까지 잇는 역량을 더 키우려 합니다.
Jira와 Confluence를 수업 팀 프로젝트에서 처음 실제로 썼습니다. Jira에선 스프린트를 2주 단위로 나눠 이슈를 등록하고 상태를 관리해, 어떤 작업이 어디서 막혔는지를 봤습니다. Confluence엔 회의록과 설계 문서를 이슈와 연결했습니다. 그런데 제가 직접 부딪힌 건, 이슈 작성 기준이 팀원마다 달라 같은 작업이 중복 등록되거나 너무 큰 단위로 묶이는 문제였습니다. 그래서 저는 이슈 작성 가이드를 문서화해 기준을 맞췄습니다. 이 경험에서 도구 자체보다 팀의 사용 기준을 맞추는 게 더 중요하다는 걸 배웠고, 이후 프로젝트에선 작성 기준을 처음부터 합의해 훨씬 수월했습니다. 다만 제 한계도 인정합니다. 저는 수업 규모라, 핵심 문서 유형별로 템플릿을 미리 정해 팀 전체에 일관성을 주거나 검색성을 관리해 본 경험은 없습니다. 그래서 사용 기준을 합의하는 토대 위에, 템플릿 표준화까지 챙기는 역량을 더 키우려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.