이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 Jira를 처음 도입했습니다. 이전엔 할 일을 노션 체크리스트로 관리했는데 태스크 상태가 맥락 없이 뒤섞였습니다. Jira로 전환하면서 스프린트 보드에 In Progress·Review·Done 컬럼을 만들고 이슈마다 담당자와 완료 기준을 적는 규칙을 정했습니다.
Confluence는 회의록과 설계 문서를 Jira 이슈와 연결해서 왜 그 결정을 했는지 나중에 찾을 수 있게 했습니다. 두 도구를 연동하면서 이슈에서 관련 문서로 바로 이동할 수 있는 게 의사결정 추적에 실질적으로 도움됐습니다. 처음엔 설정이 번거롭다는 반응이 있었지만, 프로젝트 후반에 링크 하나로 답이 되는 순간 팀이 납득했습니다. 두 도구를 함께 쓰면 이슈·문서·결정이 하나의 흐름으로 연결되는 구조가 생긴다는 걸 경험했습니다.
Jira와 Confluence를 쓰면서 스프린트 회고가 말로 끝나는 패턴이 반복됐습니다. 좋은 이야기를 했는데 다음 스프린트에서 같은 문제가 생기는 결이 있었습니다. 회고에서 나온 개선 아이디어를 Confluence 회의록에만 남기는 것이 문제였습니다. 회고 액션 아이템을 Jira 이슈로 직접 연결하고 담당자와 스프린트를 배정하는 방식으로 바꿨습니다. 문서에만 있으면 잊히지만, Jira 보드에 올라가면 눈에 띄어서 처리될 가능성이 높아졌습니다. 이 방식이 정착되니 회고가 실제 개선으로 이어지는 비율이 높아졌습니다.
문서는 기록이 아니라 실행을 가능하게 하는 도구라는 것을 Jira와 Confluence를 함께 쓰면서 배웠습니다. 두 도구가 연결될 때 비로소 논의가 행동으로 이어지는 결이 생겼습니다.
Confluence를 쓰면서 문서가 많아질수록 찾기 어려워지는 문제가 생겼습니다. 각자 자유롭게 만들다 보니 비슷한 내용의 문서가 여러 곳에 흩어지고, 어디서 찾아야 하는지 모르는 상황이 반복됐습니다. 팀과 합의해서 공간 구조를 정했습니다. 설계 문서·회의록·온보딩 자료·운영 가이드를 각각 다른 섹션에 분리하고, 문서 제목 규칙도 통일했습니다. 이 구조가 정착되니 새 팀원이 문서를 찾는 방식이 달라졌습니다. 섹션 구조만 알면 원하는 문서를 예측해서 찾을 수 있게 됐습니다.
정보는 쌓이는 것보다 찾을 수 있는 것이 더 중요한 결이라는 것을 이 경험에서 배웠습니다. 도구보다 구조가 먼저라는 것을 Confluence를 쓰면서 처음으로 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 HL그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.