Jira와 Confluence 로 협업하기 -1. 이슈트래커 정착기

Jira가 지랄한다 라는 표현을 들어보셨나요?

개발자가 Jira와 Confluence 를 사용하는건 당연하다는 생각도 많이 하실것 같지만 그게 생각보다 당연하지 않습니다.

제가 지금 재직중인 회사만 해도 1여년 전부터 국내산 이슈트래커를 감사 등의 이유로 도입하였으나, 여전히 대부분의 팀에서는 소스코드 관리 정도의 역할이 중심이며 긴밀한 히스토리 관리가 되고 있는지에 대해서는 의문일때가 많습니다.

 

반면에 저희팀은 제가 입사한 2년반 정도 전부터 각종 개발/유지보수 요청들을 Jira + Confluence + Bitbucket 을 이용해서 해결하고 있습니다.  처음에는 엑셀과 생체컴퓨터로만 이슈를 관리하던 분들이 낯선 툴에 생소해 하며 이용을 잘 안하시는 경우도 많았지만 지금은 다들 필요성을 인지하며 없으면 안되는 도구로 자리 잡았습니다.

 

그리고 이번에 새로운 팀을 꾸리는 동료분을 위해 Jira와 Confluence 의 기본셋팅을 도와드렸는데, 이번 기회에 Jira와 Confluence  도입에 따른 그간의 정착기와 최소한의 셋팅방법을 글로 남겨보려고 합니다.

 

1. 오류는 무수히 터지는데 전혀 이슈 관리가 되어 있지 않는 상황에 닥치다

당시 저희팀의 상황은 아래 3항목으로 요약됩니다.

 

1. 자잘한 요청사항이 너무 많아서 정리가 안된다
(구두요청/전화/메일/카톡.. 아주 중구난방).

 

2. 개발중인 프로그램은 에러가 너무 많아서 수습이 안된다.
(멀쩡한 소스는 과연 존재하는 것인가?)

 

3. 엑셀에 정리를 하려고 해도 뭐가 해결되었고 뭐가 아직 문제인지 모르겠다.
(에러발견 -> 오류수정 -> 테스트 의 단계를 거치지 않고 수정하면 바로 완료처리하고 잊어버리는 패기로 버티고 있었음).

 

2. Jira와 Confluence 도입을 검토하다

솔직히 이슈트래커로 업무효율성을 경험했던 입장으로는 1의 상황은 정말 견디기 어려웠습니다.

그래서 어떻게 쉽게 도입하여 사용할 수 있는 방법이 없을까 고민하다가 Jira를 선택했습니다.

 

Jira 를 선택한 이유는 아래와 같습니다.

 

1. 제가 이전 회사에서 Jira + Confluence + Bitbucket 조합으로 빡세게 규칙을 만들어서 사용한 적이 있다.

2. 10명 이하는 무료로 이용가능(Bitbucket은 5명 이하)인데 팀원은 당시 5명 이하였다.

 

그리고 다행히 팀장님이 관심을 가지고 OK하여 제가 총대를 메고 도입하게 되었습니다.

제가 생각하기에 저희팀이 도입이 가능했던 이유는 아래 이유라고 생각합니다.

 

1. 소규모 그룹으로 팀원들 설득이 비교적 쉬웠다.

2. 경험자(저)가 알아서 업무외 시간(야간/주말 등..)에 셋팅을 하였고 질문에 대답이 가능해서 첫 이용에 부담이 덜했다.

3. 당시 업무부담이 너무 심각했었기 때문에 이 이상 더 나빠질 것도 없었다... 

 

3. Jira + Confluence + Bitbucket 를 도입하다

네.. 여기서 갑자기 Bitbucket 이 추가되었습니다.

왜냐... 여기선 아직도 SVN과 옛날 옛적의 TFS 를 사용하고 있었고, 이슈와 관련 리소스 간의 링크는 긴밀할 수록 좋다 라는 신념으로 Bitbucket 으로 이관 가능한 프로젝트는 Jira도입과 함께 모두 이관했습니다.

 

그럼 순차적으로 도입시에 특히 신경썼던 부분과 팀에 정착시키기 까지 시행착오를 순서대로 정리해 보겠습니다. 

3-1. 가급적 관리자 계정은 팀장 계정 외의 공적 계정을 사용해서 만들자

개인적으로 팀 명의가 아닌 팀장이라는 한 개인의 계정을 이용하여 이러한 클라우드 서비스를 개설한 경우, 그 당사자가 퇴사를 하거나 위급한 상황이 되었을 경우 다른 사람이 팀장이 되었을 경우에도 권한등의 문제로 곤란을 겪는 것을 실제 경험하였습니다.

어떤 회사에서는 팀장이 모든 리소스와 히스토리를 본인계정 소유의 GitHub 저장소에서 관리하다가, 회사와 사이가 나빠지자 비공개 처리하고 당일퇴사를 지르고 날라버려서 이후 입사한 개발자들을 엿먹였던 사건이 있었...

 

그래서 제가 도입할때는 팀에서 메일을 확인할 수 있는 공적인 메일 계정으로 Jira 포함 3개의 서비스를 개설하였습니다.

팀장 또한 한명의 사용자로서 권한만 관리권한을 가지는 형태가 되었습니다.(사실상 팀장은 계정이 2개)

나는 이 팀에 뼈를 묻겠다! 아님 급한데 좀 써봐야지 라면 상관없을 것 같습....

3-2. 요청이 발생하면 Jira 이슈를 만들자! 이슈를 만들었으면 Bitbucket 브랜치를 만들자! 복잡한 내용은 Confluence에 정리하자!

스크럼이다 뭐다... 많긴 한데.. 최종적으로 정착한 것은 대략 이렇습니다.

Jira 프로젝트 세부사항은 [템플릿] 칸반 또는 스크럼, [유형] 회사에서 관리 유형 입니다.

 

1. 로드맵에서 업무구분용 에픽 작성
    (예) A시스템 개발)

2. 연관된 이슈 작성
    (예) 특정기능 오류, 뫄뫄기능 추가 개발 등)

3. 이슈 번호로 Bitbucket 브랜치 작성
    (보통 이슈의 개발 항목에서 [새 브랜치 만들기] 메뉴 이용)

4. 소스 커밋때는 이슈번호를 필수로 입력

 

스프린트도 도입하려고 노력을 많이 했습니다만... 업무단위가 지나치게 세분화 되어 있고(유지보수 해야 할 시스템이 엄청 많을 경우 등..) 자잘한 업무가 많은 경우에는 스프린트 구분에 대한 기준이나 설정기간(기본값이 4주)이 지나치게 짧아서 관리에 도리어 부담이 되었습니다.

잘 사용하면 분명 좋은 개념임에 분명하지만 작은 팀이라면 별도 관리인원이 있지 않다면 활용은 어렵다는 판단입니다.
현재 저희팀은 모두 개발에 투입되어야 하니 본인 일 쳐내기도 바빠서... 그 많은 스프린트를 매번 열고 닫기가 생각보다 어렵더군요.

 

브랜치는 GitFlow를 적당히 도입하여 1~2주내에 완료될만한 안건은 feature 브랜치로, 2주이상 소요될 것 같은 어느정도 규모가 있는 안건은 sprint브랜치를 작성하여 그 하위에 feature 브랜치를 여러개 작성하여 개발하는 방식으로 돌아가고 있습니다. 

빡빡하게 GitFlow를 도입하는것은... 저희에겐 무리였습니다.

3-3. 정착할 때 까지 총대가 많이많이 작성하고 보충하자

이슈트래커라는 것을 처음 접하시는 분들은 아무리 이슈를 관리하는 도구를 도입해도 지금까지 습관이 되어 있지 않기 때문에, 문제가 생겨서 이슈를 작성하려고 해도 제목에 달랑 [뫄뫄 오류] 만 쓰고 이슈를 생성하는 경우가 많았습니다.

내용까지는 쓰기가 귀찮기도 하고 "바쁜데 이것까지 해야해?" 라는 생각이 다들 깔려 있기 때문인 것 같습니다.

아마도 이슈트래커 툴을 도입했어도 제대로 정착이 되지 않은 조직도 세상에는 많지 않을까요?

 

그래서 전 가급적 제가 관여한 이슈들을 중심으로 Jira와 Confluence에 상세히 내용을 남기려고 노력했고 사소한 잔소리도 다소.. 엄청 많이 하면서 팀의 히스토리를 쌓아보려고 노력했습니다.

업무가 세분화 되면서 레이블도 자잘하게 추가하고 상태값도 그때그때 수정해서 완료/진행중 구분하고... 지라는 생활입니다.

그래도 가끔 과거에 남겼던 내용이 부실해서 제 자신에게 실망할 때가 있으니 히스토리 관리는 정말 힘듭니다..

 

도구를 도입만 하고 다들 사용하지 않으면 도입에 대한 시간 허비만 되는 격이니 도입시에는 총대를 메시는 분은 [내가 이구역의 정리왕이다]라고 정신승리 하며 정리를 해야 하지 않을까 생각됩니다. 계속 하다보니... 다른 분들도 필요성을 느끼며 하시더라구요.

단 여기까지 오는데에 약 2년이 걸린 듯 합니다.

3-4. 안건이 발생하면 담당자에게 [이슈 작성했어요?][브랜치 만들었어요?] 확인하기

팀원들에게 매우 미안하지만 정말정말 잔소리를 많이했습니다.

팀장님이 허용해 주셨기 때문이기도 합니다만(캄샤합니다..) 팀장님 포함 다른 분들에게 매번 "ㅁㅁ안건 이슈 만드셨습니까~", "브랜치 만드셨습니까~" 하고 잔소리를 해대며 아직 하지 않았을 경우에는 만들어 드리기도 하고 참 많은 오지랖을 떨었던 것 같습니다.

 

그래도 당시에는 낯설어 하셨던 동료분께서 본인이 새로 팀을 꾸리게 되는 상황이 되자, 엑셀로 돌아간 상황을 불편해 하면서 Jira + Confluence 도입방법을 물어봐 주셔서 정말 기뻤습니다.

 

4. 마무리로

솔직히 저희 팀은 Git도입과 함께 진행했던지라 이래저래 좀더 적응기간이 필요했지만 그게 아니라면 좀더 빨리 정착할 수 있었지 않았을까 하는 생각이 듭니다.
(잔소리의 50%는 브랜치 작성과 커밋 이력 남기기 였던거 같아서..)

 

앞으로도 이대로만 갔으면 좋겠다는 바램을 가슴에 품고 정착기는 이걸로 마무리 하고...

다음에 시간이 나면 Jira와 Confluence 이용시에 설정해 두면 편리한 항목들을 간단히 정리해 보겠습니다.

 

 

2023.03.10 - [개발/잡담] - Jira와 Confluence 로 협업하기 -2. 기본 설정