[90일차] Jira 슬기롭게 사용하기

 

이번 주부터 종합프로젝트를 시작했다.

가장 처음으로 세팅한 것은 프로젝트를 슬기롭게 관리하기 위한 서비스인 Jira를 세팅했다.

Jira를 세팅하면서 겪었던 문제와 배운 점, 회고를 작성해보고자 한다.

 

 

💡 배운 점 (What I Learned)

이번 작업을 통해 Jira를 단순히 이슈를 관리하는 도구로 사용하는 것과, 팀의 작업 흐름을 설계하는 도구로 사용하는 것의 차이를 분명히 느낄 수 있었다.

특히 자동화를 적용하면서 Jira는 ‘기록용 툴’이 아니라, 현재 팀이 무엇을 하고 있는지 한눈에 보여주는 상태 기반 도구가 되어야 한다는 점을 배웠다.

스프린트를 시작하지 않은 상태에서 이슈를 관리하면, 백로그와 실제 진행 중인 작업이 뒤섞여 보드의 의미가 사라진다. 반대로 스프린트를 명확히 시작하고, 이번 스프린트에서 다룰 이슈만 보드에 올려두면 굳이 설명하지 않아도 현재 진행 상황이 자연스럽게 드러난다. 또한 커밋, 이슈, 에픽이 서로 연결되도록 자동화를 구성하면, 사람이 직접 상태를 관리하지 않아도 작업 흐름이 끊기지 않는다는 것을 체감했다.

이 과정에서 자동화는 단순한 편의 기능이 아니라, 협업의 신뢰도를 높여주는 핵심 요소라는 것을 체감했다.

 

 

 

🚀 문제 해결 / 고민 (Problem & Solution)

문제 상황

가장 크게 막혔던 부분은 자동화를 어디까지 적용해야 하는지에 대한 명확한 기준이 없었다는 점이다. Jira는 자동화 기능을 굉장히 많이 제공하지만, 막상 팀 단위로 사용하려고 하니 “이걸 자동화하는 게 맞나?”, “여기까지 하면 오히려 관리가 더 어려워지지 않을까?”라는 고민이 계속 생겼다.

다른 팀의 Jira 세팅을 담당하고 있는 친구들과도 대화를 나눠보니 이 부분이 가장 큰 고민이었다고 한다. 

특히 프론트엔드와 백엔드를 어떻게 분기할지, 스프린트를 어떤 기준으로 운영할지, 에픽과 이슈의 역할을 어디까지 가져갈지 등 설계 단계에서 결정해야 할 요소들이 많았다. 하지만 팀 단위 Jira 자동화 사례는 구글링으로 찾기 어려웠고, 대부분은 회사 내부 정책이거나 단편적인 기능 설명에 그쳐 실제로 참고하기가 힘들었다.

 

해결 과정

고민 끝에 우리 팀은 모든 것을 자동화하지 않고, 작업 흐름의 핵심만 자동화하는 방식을 선택했다.
기본적인 방향은 다음과 같다.

 

1️⃣ FE / BE 분리는 별도 보드가 아닌 에픽 라벨로 해결

프론트엔드, 백엔드를 Jira에서 완전히 분리하지 않고, 에픽에 FE / BE 라벨을 붙이는 방식으로 구분했다.
이를 통해 보드는 하나로 유지하면서도, 작업 성격은 라벨로 명확히 드러나게 했다.
이 선택 덕분에 관리 포인트를 늘리지 않으면서도 작업 구분이 가능했다.

라벨 추가

 

2️⃣ 에픽은 수동 생성, 이슈부터 자동화

에픽은 담당자, 기한, 작업 범위가 명확해야 하기 때문에 수동으로 생성했다.
대신, GitHub에서 이슈를 생성하면 Jira 이슈가 자동으로 생성되고, 에픽 번호를 상위 작업으로 연결하는 방식으로 자동화를 적용했다.

이 과정에서 브랜치도 함께 자동 생성되도록 설정해, 개발자는 브랜치명만 신경 쓰면 되도록 흐름을 단순화했다.

에픽 수동 생성	깃허브 이슈 생성 시: Jira 이슈 자동 생성 + 브랜치 자동 생성

 

3️⃣ 스프린트 운영은 명확하게, 하지만 일부는 수동 유지

스프린트는 기본적으로 생성된 상태를 전제로 하고, 백로그에 있는 작업을 현재 스프린트로 드래그하는 과정은 수동으로 유지했다.
이는 “이번 스프린트에 무엇을 할지”를 팀이 한 번 더 인지하는 장치로 작용했다.

백로그 내 작업을 스프린트로 옮기기

 

4️⃣ 커밋과 이슈 상태는 자동화의 핵심 포인트

커밋 메시지는 [Feat] 로그인 UI 구현처럼 작성하면, Husky가 자동으로 Jira 티켓 번호를 붙여주도록 구성했다.
첫 커밋이 발생하면 Jira 이슈 상태가 자동으로 ‘진행 중’으로 변경되어, 누가 작업을 시작했는지가 별도 공유 없이도 드러났다.

커밋 시 Jira 티켓 번호 자동 부여	Jira 이슈 상태 '진행 중' 자동 변경

 

5️⃣ 종료 시점은 GitHub 이슈 기준으로 통일

PR 리뷰 후 머지가 완료되면, GitHub 이슈를 Closed 하는 것을 작업 종료의 기준으로 삼았다.
이슈가 Closed되면 Jira 이슈 상태가 자동으로 ‘완료’로 변경되고, 스프린트에서도 자동으로 제거되도록 설정했다.

다만 에픽 종료와 브랜치 삭제는 여전히 수동으로 남겨두었다.

깃허브 이슈 closed 하기	Jira 이슈 상태 '완료' 자동 변경

 

 

 

💬 회고 (Reflect)

이번 Jira 세팅을 도맡아 하면서 IT 업계에서 DevOps 개발자의 중요성이 계속 강조되는지 명확히 이해하게 되었다. 자동화를 설계하는 일은 단순히 기술을 붙이는 작업이 아니라, 팀의 일하는 방식을 정의하는 작업에 가깝다는 생각이 들었다.

또한 빠르게 변화하는 IT 환경에서 DevOps는 끊임없이 새로운 기술을 학습하고 이를 팀과 시스템에 적용해야 하며, 그 결과가 곧 기업의 생산성과 직결되기 때문이다.

아쉬운 점이 있다면, JIra를 아예 처음 접해봐서 자동화를 구조적으로 설계하지 못하고 시행착오를 겪었다는 점이다.

다음 프로젝트에서는 Jira 자동화 설계 패턴과 자동화 전략을 더 정리해 보고 작업에만 집중할 수 있는 자동화에 대해 더 깊이 고민해 보고 적용해 봐야겠다.