JIRA를 하자! - 쿠키런 : 오븐브레이크의 JIRA 도입기

1. 시작하며

이슈(Issue)를 추적관리하는 업무는 QA 직군이 반드시 해야 하는 필수 업무 중 하나입니다. 탄생(생성)부터 죽음(완료)까지 이슈의 생애를 각종 정보들을 통해 지켜봄으로서 이들의 처리가 원활하도록 관리해야 합니다. 이슈는 또 일종의 일감으로, 전체 프로젝트 마일스톤(Milestone) 안에 있는 또 하나의 미시적 마일스톤으로도 볼 수 있습니다.

활발하게 개발이 이루어지는 기간에는 이러한 일감들이 끊임없이 쏟아져 나옵니다. 그럼 수많은 일감을 어떻게 전달해야 효과적일까요? 귀로 듣는 것이 확실하니까 직접 말로 설명할까요? 아니면 담당자 모니터에 포스트잇으로 붙여둘까요? 그것도 아니면 메신저로 전달할까요?

여러 가지가 있겠지만, 가장 보편적인 방법으로 대부분 **'BTS(Bug Tracking System)'**라는 도구를 사용하여 이슈와 일감들을 관리합니다. (요즘 방탄소년단 덕분에 BTS라는 단어가 국위선양의 콘텐츠로 자리매김했지만 어쨌든...) BTS를 사용하여 팀원들은 수많은 일감을 시각적으로 확인하고, 현재 상태를 직관적으로 알 수 있어서 업무 효율성이 비약적으로 상승합니다. 구두 또는 문서전달의 방식 보다 훨씬 더 효과적이죠.

그러나 당장 'BTS를 사용하자!'라고 결정해도 한 가지가 논의가 더 필요합니다.

그럼 어떤 BTS 서비스를 사용해야 할까?

BTS로 사용할 수 있는 프로그램이나 서비스들은 매우 많지만, 아무렇게나 사용하면 원하는 만큼의 효율성을 이끌어내지 못할 확률이 큽니다. 이는 개발 프로세스, 팀 성향, 무료 / 유료 툴 여부, 원하는 기능을 제공하는지 등 세부적으로 커스터마이징이 필요한 부분들이 많기 때문이죠. 어떤 툴을 어떤 방식으로 사용하느냐는 역시나 사람에게 달려 있기 때문에, 우리는 좋은 툴을 효과적으로 사용하기 위한 방법을 마련해야 합니다. 그렇지 않다면 일감 관리 업무는 Bug Tracking System이 아닌 **Burn The Stage(하얗게 불태웠어...)**가 될 테니까요.

2. JIRA 이전의 BTS

이 포스트에서는 쿠키런 오븐브레이크 팀에서 JIRA를 도입하는 과정과, 이를 효과적으로 사용하기 위해 노력했던 것들에 대해 서술합니다. 그럼 우리가 왜 JIRA를 사용했는지를 알기 위해서는 그 이전에 사용했었던 BTS에 대해서 한번 되짚어보아야 할 것 같습니다.

1) 구글 스프레드시트 (Feat. Excel)

협업을 하는 회사라면 적어도 한 번씩 사용해보았을 구글 스프레드시트입니다. 구글 계정만 있다면 기본적으로 웹페이지에서 접근이 가능하기 때문에 따로 요금을 지불하거나 복잡하게 계정을 생성해야 하는 등의 프로세스는 필요하지 않습니다. 또한 Microsoft의 Excel과 유사하여 사용성 측면에서도 비교적 간단합니다. 구글 스프레드 시트는 쿠키런 for KAKAO 서비스 초반과 쿠키런 오븐브레이크 일부 이슈관리에 사용했습니다.

구글 스프레드시트의 장단점은 다음과 같습니다.

장점:

• 접근성과 사용성이 좋습니다.
• 다양한 양식으로 템플릿을 제작할 수 있습니다.
• 메일이나 링크 전달만으로도 손쉽게 다른 사람에게 공유가 가능합니다.
• 무료입니다.

단점:

• 처음에는 가벼우나, 데이터가 쌓이면 그 데이터를 관리하는 리소스가 매우 많이 듭니다.
• 이슈 상태를 직관적으로 파악하기 어렵습니다.
• 상용 BTS 서비스 만큼의 검색, 자동 분류 기능을 기본적으로 제공하지 않습니다.
• 스크린샷, 동영상 등의 첨부파일을 업로드하는 것이 매우 제한적입니다.
• 보안이 취약합니다.
• 무엇보다도 툴이 멋지지가 않습니다. (사실 제일 중요함)

장점도 있긴 한데, 단점이 매우 치명적이어서 이슈를 추적관리하는데 부적합한 툴이었습니다. 이슈를 추적관리하는 것보다 시트의 내용을 정리하고 수동으로 최적화 작업을 해야 했기 때문에 작업자의 신경이 이슈의 관리보다는 '시트 정리'에 초점이 맞추어져 있어서 일을 위한 일이 되어버리는 결과를 낳았습니다.

2) 트렐로(Trello)

그다음으로 사용했던 트렐로는 전형적인 프로젝트 관리용 서비스입니다. 애자일 프로세스에서 흔히 볼 수 있는 칸반(Kanban), 즉 열(List) 단위 연속 처리 방식에 따라 이슈가 시각화되는 것이 특징입니다. 이 서비스는 쿠키런 for KAKAO와 더불어 쿠키런 오븐브레이크 서비스 중반, 그 외 다양한 내부 프로젝트에서 범용적으로 사용하였습니다. 불과 작년 3월까지 사용했던 툴이라 아직도 기억이 생생하네요.

트렐로의 장단점은 다음과 같습니다.

장점:

• 직관적으로 이슈의 상태를 확인할 수 있습니다.
• 각 열 상태를 마음대로 지정할 수 있습니다.
• 열 이외에 레이블(Label)을 사용하여 추가적으로 이슈의 상태를 표시할 수 있습니다.
• 담당자 지정이 가능합니다.
• (제한적이지만) 첨부파일 업로드가 가능합니다.
• 상대적으로 다른 서비스에 비해 가볍습니다.
• 필터링을 통해 원하는 이슈만 볼 수 있습니다.
• 무료로 사용 가능합니다.
• 승인된 계정만 접속 가능하므로 일정 수준의 보안이 확보됩니다.

단점:

• 이슈 검색 기능이 원하는 만큼 정확하지 않았습니다.
• 생성된 이슈 카드 수가 많으면 엄청나게 느려집니다.
• 워크플로(Workflow) 기능이 없어서, 잘못된 상태에 있는 이슈를 확인하기 쉽지 않습니다.
• 무료 버전의 경우 첨부파일 용량 및 생성 가능한 보드의 수에 제한이 있습니다.
• 이슈들의 히스토리 관리가 어렵습니다.
• 통계 기능이 없습니다.

트렐로는 많은 장점을 가진 도구입니다. 팀의 규모가 작았을 때 가볍게 사용할 수 있으면서 이슈들의 상태를 관리할 수 있었기 때문에, 꽤나 오랫동안 사용했던 서비스입니다. 무엇보다도 무료였기 때문에 비용의 부담 없이 쓸 수 있어서 더 좋았었네요.

그러나 무료 버전은 첨부파일 용량 제한으로 항상 동영상이나 스크린샷을 올릴 때 용량을 확인해야 했고, 경우에 따라 용량을 줄이기 위한 인코딩까지 필요했습니다. 이러한 작업을 거치면 첨부파일의 품질이 낮아져, 막상 파일을 실행해도 화면이 나오지 않거나 저화질로 보아야 하는 경우가 비일비재했습니다. 무엇보다도 이슈 검색 기능이 생각보다 좋지 않았기에, 이전에 등록했었던 특정 이슈 카드를 찾기 힘들었습니다. 검색 결과 화면에서 일일이 카드를 눌러보며 찾아야 했던 아픔이 떠오르네요.

또한 버전 단위로 이슈를 확인하기 어려웠습니다. 저희는 이를 개선하고자 버전별로 보드를 계속 생성해서 관리하였으나, 2019년 5월을 기점으로 무료 사용자의 보드 생성 개수가 제한되면서 이 방법도 결국은 한계에 다다르고 말았습니다.

좋은 서비스였습니다만, 여러 가지 한계점으로 인해 이별을 하게 되었다는것이 참 마음이 아픕니다. 하지만 이걸 기점으로 전사 QA 직군에서는 BTS 서비스를 바꿔보는 게 어떨까 하는 의견을 낼 수 있었습니다.

3. BTS 춘추 전국 시대

트렐로 다음으로 어떤 서비스를 이용해야 하지?

트렐로와 이별하기 전, 저희 QA 엔지니어들은 BTS로 사용할 수 있는 서비스들을 주욱 나열해보았습니다. Redmine, Mantis, Asana, Wrike, Monday, JIRA 등 정말 많은 서비스들이 목록화되었고, 이들 중 몇몇은 실제로 초기 설정까지 마치고 시험적으로 사용도 해보았으나, 만족할 만큼의 효율성을 산출해내지는 못하였습니다. 이는 각 툴별로 QA 엔지니어들의 숙련도와 각자가 추구하는 BTS 최소 기능의 수준이 달랐기 때문이었습니다.

그래서 그다음으로 나왔던 의견은, 그냥 각 프로젝트에서 사용하는 BTS는 해당 프로젝트 소속 QA가 결정하여 독자적으로 운용하자는 것이었습니다. 예를 들어 A 프로젝트는 Redmine을, B 프로젝트는 Mantis를, C 프로젝트는 Wrike를 쓰는 식입니다. 이는 각 프로젝트의 업무 프로세스와 QA 엔지니어의 툴 숙련도에 최적화하여 사용할 수 있어서 업무 효율성을 극대화하는 장점이 있습니다.

그러나 위 방식은 각 서비스마다 계정을 각각 따로 관리했어야 했기 때문에, 전사적으로 계정을 관리하는 입장에서 리소스가 너무 많이 들게 되고, 입사자나 퇴사자 처리 등 계정의 생성/제거 절차가 매우 복잡해지는 단점이 있었습니다. 또한, A 프로젝트에서 B 프로젝트의 BTS를 보려고만 해도 (View) 새로 계정을 생성해야 했기 때문에, 이게 만약 유료툴이라면 1계정 비용이 추가로 지불됩니다. 프로젝트 단위 업무 효율성은 상승할지는 몰라도 관리/비용 측면에서는 비효율적이기 때문에 이 방안은 실행하기 어려웠습니다.

그래서 우리는 다시 처음으로 되돌아왔습니다만, 여전히 어떤 툴을 사용해야 하는가에 대해서는 의견이 분분했습니다. 사실 JIRA가 다른 모든 서비스의 기능을 대체적으로 포함하고 있어서 가장 최적의 선택이었지만, 유료 서비스였기 때문에 쉽사리 결정하기 어려웠습니다. 그러나 우리의 업무 효율성을 높이는 방법이라면 유료 서비스라도 사용해야 한다는 쪽으로 의견이 모아졌고, 최종적으로 전사 모든 프로젝트가 JIRA를 사용하는 것으로 결정하였습니다.

4. 괴수 길들이기 : 초기 환경설정

우여곡절 끝에 이제 저희는 JIRA라는 아주 거대하고 복잡한 서비스를 사용하게 되었습니다. 처음에는 마치 새로운 전자기기를 산 것처럼 신나게 이것저것 뜯어보고 만져보고 했지만, 나중에는 **'이 복잡하고 어려운 서비스를 우리가 과연 효율적으로 잘 사용할 수 있을 것인가..?'**에 대해서 심각하게 고민하게 되었습니다. 저를 포함한 3명의 QA 엔지니어들은, **'2019년 4월 업데이트에 실사용'**이라는 목표를 세우고 이 무시무시한 괴수를 어떻게 길들일지 논의하였습니다.

1) 운용 방식 (Board Template)

기존처럼 칸반(Kanban) 방식을 유지할 것인가, 아니면 새로운 방식을 사용할 것인가에 대해서 논의한 사항입니다. 결과적으로 저희는 칸반 방식을 유지하기로 하였습니다. 우선 QA 팀을 포함한 프로젝트 내 모든 인원들이 트렐로에 매우 익숙해져 있고, 새로운 툴에 적응하는 데에도 스트레스가 있을 텐데 BTS의 처리 방식과 UI가 기존과 다르다면 익숙해지는데 더 많은 시간이 들 것이라 예상했습니다. 또한 칸반 자체가 직관적이고 리드미컬한 이슈 처리가 가능했기 때문에 협업에 더 유리할 것이라는 판단을 하였습니다.

2) 워크플로 (Workflow)

트렐로를 사용할 때에 저희는 '등록이슈' → '수정완료' → 'QA완료' 라는 매우 단순한 이슈 상태만 각 열에 지정해두고, '수정 중', **'QA 확인 중'**과 같은 상태는 레이블로 대체하여 운용하였습니다. 그러나 칸반은 카드를 드래그 & 드롭하여 신속하게 이슈를 처리하는 데에 목적이 있는데, 카드에 일일이 레이블을 달거나 변경하는 작업은 비효율적입니다. 따라서 저희는 기존에 레이블로 처리하던 방식까지 모두 열(List) 단위로 세분화하여 워크플로를 설계하기로 하였습니다. 이렇게 하면 굳이 카드를 팝업 하여 레이블을 입력하는 것 대신 마우스로 카드를 끌어다 놓기만 하면 되어서 신속하게 이슈의 상태를 변경할 수 있습니다.

추가로 쿠키런 오븐브레이크 개발 프로세스 내 특수한 상황들을 워크플로에 반영하기로 하였습니다. 이슈인 줄 알고 등록하였으나 기획서에 해당 내용이 명시된 경우(이슈아님), 이슈로 등록했으나 담당자들의 합의를 통해 이를 **사양(Spec)**으로 변경하는 경우(사양으로 변경), 중복으로 등록된 이슈인 경우입니다(중복이슈). QA 완료 외 3가지의 '처리 완료(Close)' 상태를 추가함으로써, 좀 더 저희 팀에 최적화된 처리 절차를 구축할 수 있었습니다.

마지막으로 '보류' 상태를 추가하여 현재 업데이트에서 수정하기에는 시간적 / 인적 리소스가 부족하거나 생각하지 못한 엣지케이스 같은, 스펙 확정의 시간이 걸리는 이슈의 경우 보류 처리하여 장기적으로 관리해야 할 이슈의 상태를 따로 만들어 두었습니다. 이들은 30일 스프린트마다 수정 가능한지 확인하면서 처리하기로 하였습니다.

최종적으로 쿠키런 오븐브레이크의 워크플로를 다이어그램으로 나타내면 다음과 같습니다.

보시다시피 **'수정 필요'**의 **'모두'**를 제외한 나머지 상태들은 이전 상태로 돌아갈 수 없도록 설정하였습니다. 이는 화살표가 일방적으로 다음 상태로만 이어진 것으로 확인할 수 있습니다.

프로젝트 보드 등록된 모든 사람들에게는 이슈 카드의 상태를 전환시킬 수 있는 권한이 부여되어 있습니다. 따라서 실수로 카드의 상태를 변경하게 되면 상태 기반으로 커뮤니케이션하는 QA 팀 특성상 해당 카드의 상태를 잘못 인지하게 되고, 이를 바로잡는데 추가적인 리소스가 들게 됩니다. 이런 인적 오류를 최소화하고 싶었기 때문에 정해진 순서대로만 카드가 이동하도록 설정하였습니다.

다만 **'수정 필요'**의 경우는 여러 가지 돌발적인 상황에 대비하기 위하여 일부러 모든 상태에서 다시 수정 필요 상태로 돌아갈 수 있도록 하였습니다. 개발 및 QA를 하다 보면 이슈가 수정된 줄 알았으나 실제로는 수정되지 않은 경우가 자주 발생했기 때문에, 손쉽게 다시 수정 필요 상태로 돌릴 수 있어야 했습니다.

모든 이슈들은 수정 필요 상태로 돌아가면 다시 다른 상태로 변경이 가능합니다. 수정 필요 상태는 이슈의 상태를 '초기화' 시키는 것이라고 생각하면 편할 것 같네요. 심지어 이미 완료 처리된 이슈들도 다시 수정 필요 상태로 전환시켜 다시 처리할 수도 있습니다. JIRA 초기 설정 시 상황에 따라 가변적이고 유연하게 대처해야 하는 게임 소프트웨어와 팀 내 문화를 보장할 수 있도록 고려한 부분 중 하나입니다.

3) 이슈 유형 (Issue Type)

**'이슈 유형'**은 이슈의 종류를 말합니다. JIRA에서는 사용자의 니즈에 따라 이슈 유형을 추가할 수 있어서, 회사 사람들이 만들어둔 이슈 유형이 엄청나게 많았습니다. 저희는 복잡하게 모든 이슈 유형을 사용하기 보다는 가장 자주 쓰는 유형인 **'버그'**와 '개선' 두 가지만 사용하여 간소화하기로 하였습니다.

**'버그'**는 말 그대로 게임 시스템(기능)과 그에 관련된 환경들(비기능)에 대한 결함 / 장애들을 뜻합니다. 버그에 대해서는 더 이상 설명할 필요가 없을 것 같네요.

**'개선'**은 버그는 아니지만, 유저 관점에서 경험이 좋지 못하거나 사소하게 수정이 필요한 부분에 대해서 등록합니다. 버그보다 우선순위는 낮지만 수정되면 더 편리하고 멋있어 보일 수 있는 부분들에 대해 담당자가 한번 생각해 볼 수 있는 문제들을 제시하게 됩니다. 단순히 테스팅이 아닌 정말로 게임의 품질을 높이기 위해서는, 제 생각엔 버그만큼이나 중요한 이슈 유형이라는 생각이 듭니다.

4) 이슈 화면 (Screen)

이슈 화면은 카드의 상세 정보가 팝업 되었을 때, 해당 화면에서 어떤 정보들이 보이게 할지 결정하는 것입니다.

대부분의 정보는 이슈 보고자가 입력하게 됩니다. 이슈 유형과 마찬가지로 이슈 화면도 JIRA에서 제공하는 필드가 매우 다양합니다. 모두 쓰고는 싶지만, 이 수많은 필드들을 사용하게 될 경우 직관적으로 이슈의 정보를 파악하기 힘들어질 것입니다. 정말 정말 필요한 정보만 한눈에 딱 보여주고, 굳이 몰라도 되는 (사실 알아도 의미 없는) 정보들은 가리기로 하였습니다.

이는 총 11개로, 필드는 다음과 같습니다.

1. 요약 (이슈 제목): 이슈 전체 내용을 요약하여 하나의 간단한 문장으로 제목을 지정합니다.

2. 보고자: 이슈를 보고하는 사람입니다. 생성하는 사용자가 자동으로 등록되도록 설정하였습니다.

3. 담당자: 이슈를 수정할 사람입니다. 해당 프로젝트에 등록된 사용자를 기반으로 등록할 수 있습니다.

4. 그룹: 해당 이슈를 직군 전체에서 봐야 하는 경우, 미리 지정된 그룹을 등록할 수 있습니다.

5. 설명: 이슈의 상세 설명을 기재합니다. 저희는 테스트 환경/이슈 설명/기대 결과를 작성합니다.

6. 우선순위: 이슈의 수정 우선순위를 등록합니다. Lowest/Low/Medium/High/Highest의 5단계를 사용합니다.

7. 레이블: 이슈의 추가 정보를 나타내는 레이블을 등록합니다.

8. 첨부파일: 이슈의 상태를 설명할 수 있는 스크린샷이나 동영상을 첨부합니다.

9. 영향을 받는 버전: 해당 이슈가 발생하는 버전을 기재합니다.

10. 수정 버전: 이슈가 수정된 경우, 해당 이슈가 수정된 버전을 기재합니다.

11. 연결 이슈 (관련된 이슈): 어떤 이슈에서 파생되었거나, 영향을 주는 경우 연결된 이슈 번호를 기재합니다.

이 이외의 컴포넌트, 에픽, 작업 로그, 시간 추적과 같은 봐도 잘 모르겠는 정보들은 과감하게 포함하지 않았습니다. BTS의 최초 사용 목적인 직관적으로 일감을 식별하는 효율성을 확보하기 위해 복잡함보다 심플함을 선택한 것은 좋은 결정이었다는 생각이 듭니다.

5) 레이블

기존 트렐로에서는 레이블을 통해 이슈의 상태를 추가적으로 보여주었으나, 이는 JIRA에서 워크플로로 대체되었기 때문에 저희는 레이블을 다른 방향으로 사용할 수 있었습니다. 따라서 저희는 이 레이블을 이슈와 관련 있는 콘텐츠 정보 표시로 사용하였습니다.

초반 설계에서는 직군, 콘텐츠 카테고리를 매우 세분화하였습니다. 예를 들면 클라이언트, 쿠키 등으로 레이블을 지정한 것을 들 수 있습니다. 특히나 콘텐츠 카테고리는 게임 시스템 내에서도 경기, 떼탈출, 기억의 섬, 우정런, 인게임, 쿠키, 펫, 보물, IAP, 플랫폼, 계정 연동 등등 세분화할 수 있는 요소가 많았기 때문에 새로운 콘텐츠마다 이를 나누어 레이블을 부여했습니다.

6) 기타

이 이외에도 저희는 논의를 통해 세부적인 사항들까지 의사결정하여 반영했습니다. 너무 많아서 다 기억은 안 나지만 몇 가지 기억나는 것들을 한번 적어보려 합니다.

1. 이슈의 제목 (요약):
   제목은 한눈에 어떤 이슈인지 파악할 수 있도록 하는 매우 중요한 부분입니다. 따라서 저희는 대 괄호 안에 해당 이슈의 콘텐츠를 적고, 그 뒤에 이슈의 설명을 적는 방식으로 결정하였습니다. 예를 들자면 다음과 같습니다:
   [용감한쿠키] 용감한 쿠키 점프버튼 터치 시, 크래시 나는 문제

2. 완료된 이슈의 처리:
   완료된 이슈는 히스토리 관리를 위해 '처리 완료' 열 안에 계속 쌓아두기로 하였습니다. 일일이 이슈를 찾는 것보다 리스트 안에 두는 것이 관리 측면에서 더 효율적일 것이라 생각했기 때문입니다. 따라서 버전이 올라가면 올라갈수록 '처리 완료' 열에는 이슈가 계속 누적되어 나타나게 됩니다.

3. 가이드북 제작:
   JIRA는 저희에게도 매우 복잡한 서비스였기 때문에, 다른 직군에서 사용하는데 어려움이 있을 것이라 생각하고 가이드북을 제작하고 배포하기로 하였습니다.

4. 이슈의 알림:
   이슈는 메일링으로 받고 싶지 않다는 개발자들의 의견을 수용하여 (메일함이 지저분해지므로) 회사에서 사용하는 Slack 메신저를 통하여 알림을 받도록 설정하였습니다. 다만, 개개인이 일일이 설정해야 하기 때문에 위 가이드북에 설명을 기재하여 배포하였습니다.

5. 대망의 릴리즈 : 그러나 끝나지 않은 작업

드디어 모든 초기 설정이 끝이 났습니다. 처음 사용해보는 툴이라 복잡한 설정과 JQL 등 어려운 난관이 많았지만, 많은 분들의 도움과 구글링으로 처음 치고는 그럴듯하게 BTS 환경이 구축되었습니다.

사용자 등록과 가이드북 배포, 기존 트렐로에서 History를 옮겨오는 후속작업까지 완료하고 2019년 4월 정식으로 쿠키런 오븐브레이크 팀에서 JIRA를 사용하게 되었습니다! (짝짝짝~)

생각보다 순조로운 출발에 저희 QA 팀은 안도의 한숨을 내쉬었습니다. 이슈를 올리고, 수정하고, 처리하는 과정이 트렐로보다는 무거웠지만 그래도 큰 어려움 없이 진행되는 것을 보며, 직관적으로 환경을 설정하는 것이 정말로 중요하다는 것을 다시 한번 깨닫게 되었습니다. 그 외 어려운 부분들은 저희 팀에서 직접 튜토리얼과 커뮤니케이션을 통해 해결했고, 반대로 사용자 입장에서 받을 수 있는 사용성 피드백들을 받았습니다.

사실 초기 시스템 구축은 **'이렇게 사용할 것으로 예상된다'**와 같은 추측에 가까웠다고 해도 과언이 아닙니다. 저희도 릴리즈 직전까지 결정할 사항들이 산더미 같았지만, 결국에는 **'써보고 수정합시다!'**로 결정한 이유는, 사용해보고 개선하는 것이 사용 전 추측으로 구축하는 것보다 더 효율적일 것이라 판단하였기 때문입니다. 게다가 사내에서 사용하는 서비스이므로, 차분히 개선할 수 있는 시간적 여유도 있었습니다. (우리끼리 사용하는 것이니 조금 불편해도 참아주시겠지..?)

결과적으로 충분한 사용 후 받은 피드백들이 영양가 있어서 좋았습니다. 처음엔 편리할 것이라 생각하여 추가한 기능이 실제로는 비효율적인 부분도 있었고, 릴리즈 하고 보니 조금만 더 개선하면 좋을 것 같은 미숙한 부분들도 계속해서 튀어나왔습니다. 특히나 QA 팀에서 생각하지 못한 부분들을 다른 직군의 팀원들께서 짚어 주시는 부분들이 굉장히 많은 도움이 되었습니다.

그리하여 저희에게는 '불편한 점들을 개선하라!'는 미션이 다시 주어졌습니다. 흐규...

2019년 4월부터 지금까지 JIRA를 약 1년간 사용하면서 저희는 총 25건의 크고 작은 개선사항이 있었습니다. 이를 체크리스트에 등록하고 시간이 될 때마다 조금씩 개선해 나갔습니다.

이 중 중요하다고 생각되는 몇 가지를 골라 한번 이야기해보겠습니다.

1) 프로필 이름 한글로 바꾸기

JIRA는 기본적으로 영어 이름으로 등록되기 때문에 (Gunwoo Park 같은 식으로) 담당자를 검색하기가 조금 불편했습니다. 영어보다 그냥 '박건우'를 치는 게 더 빠르기 때문에 아틀라시안 계정의 이름을 전부 한글로 바꾸도록 팀원 분들께 요청하였습니다. 놀라운 건 보고자 및 담당자 검색을 한글로 할 수 있게 되면서 생각보다 업무가 훨씬 더 편리해졌다는 겁니다. 별거 아닌 것 같은 부분에서 생각지도 못한 효율성 상승을 이끌어 냈다는 점이 재미있었습니다.

2) 수정 버전 미입력 시, 처리 완료(Close)가 되지 않도록 수정

이는 QA 팀 내부에서 자주 하던 실수를 개선하기 위해 직접 수정하였습니다. 카드를 빠르게 처리하다 보면, 카드 내부의 '수정 버전'을 누락하고 처리하는 경우가 많았습니다. 당장 크게 문제가 되지는 않지만, 나중에 이슈들을 목록화하거나 테스트 리포트를 작성할 때 수정 버전이 누락된 이슈들을 빼먹는 경우가 종종 생겼습니다. 따라서 처음에는 일일이 찾아 누락된 수정 버전을 입력했지만, 이것 자체가 비효율적이었기 때문에 워크플로 자체에 수정 버전을 입력하지 않으면 처리 완료되지 않도록 설정하였습니다. JIRA 개선사항 중 가장 효율성이 높아진 사례로 꼽을 수 있을 것 같습니다.

3) 필수 입력 정보 누락 시, 카드가 생성되지 않도록 수정

2번과 비슷한 문제인데, 카드를 생성할 때 필수 정보를 입력하지 않아 나중에 이슈가 완료 처리되고 나서 필수 정보를 부랴부랴 넣는 상황이 종종 발생했습니다. 따라서 이것도 카드를 생성하는 시점에서 필수 입력 필드를 지정하고, 해당 필드가 빈 값인 경우에는 카드가 생성되지 않도록 조치하였습니다. 2번 개선사항을 포함하여, 이제는 카드에 누락된 정보가 있는 경우는 발생하지 않습니다. 카드 정보가 정확한지 판별하는 시간과 리소스를 온전히 이슈 처리에 집중할 수 있게 되어 업무가 훨씬 수월해진 것 같습니다.

4) 릴리즈된 버전의 카드는 보드에서 보이지 않도록 수정

이는 한 개발자분의 JIRA 사용 중 불편한 점을 듣고 개선한 사례입니다. 위에서 설명했듯이 저희는 처음에 모든 카드를 한 보드에서 모두 관리할 수 있도록 처리 완료 열에 현재까지 생성된 카드들을 누적해왔습니다. 그러나 카드가 쌓이면 쌓일수록 안 그래도 무거운 툴이 점점 느려지더니, 나중에는 웹페이지 새로 고침이 안될 정도로 느려지기 시작했습니다. 트렐로에서처럼 칸반에 카드가 많으면 생기는 이슈일 것이라 생각하고 수정 버전에 입력된 버전이 릴리즈 된 경우, 해당 카드들을 보드에서 보이지 않도록 하였습니다. (실제로 사라지는 것은 아니고 보이지 않게만) 다행히도 카드가 열에서 사라지자 다시 JIRA 서비스가 쾌적해졌고 모두가 행복하게 잘 사용할 수 있었다는 해피엔딩으로 끝났습니다.

위 개선사항을 적용하기 위해서 보드 설정의 '보조 필터' 기능을 사용하였는데, 이는 JQL을 이용해야 합니다. 코드의 코자도 모르는 제가 어떻게 JQL을 이용했을까요? 이는 JIRA 고급 검색의 'JQL 변환' 기능이 그 답을 주었습니다.

보조 필터는 입력된 JQL에 해당하는 이슈만 보드에 보여주는 기능입니다. 릴리즈된 이슈들은 보드에서 안 보이도록 해야 하므로, 보조 필터에는 '처리 완료된 이슈 중, 릴리즈되지 않은 이슈만 보여준다.'라는 값을 입력해야 합니다. 따라서 고급 검색에서 unreleased version을 체크한 다음, 이를 JQL로 변환 후 보조 필터에 그대로 복사 + 붙여넣기 하여 간단하게 필터를 구성할 수 있었습니다. 보조 필터는 따로 작업 없이 자동으로 동작하기 때문에 해당 버전을 릴리즈 처리하면, 릴리즈 대상 버전의 이슈가 한 번에 사라지게 되어 매우 편리했습니다.

5) 레이블 정리

레이블은 아직도 진행 중인 개선사항 중 하나입니다. 아까 이야기했듯이, 처음에는 모든 콘텐츠를 레이블화 하려고 시도했습니다만, 띄어쓰기 하나로 같은 내용의 레이블이 중복으로 생성되기도 하고, 한번 쓰고 버려지는 레이블들이 너무 많아서, 결국 이도 저도 아닌 상태가 되어버린 것 같습니다. 따라서 이를 초 단순화시켜 간단하게 사용할 수 있게 정리하는 작업이 필요했습니다.

그리하여 기존 콘텐츠들을 우선 크게 '아웃게임'과 '인게임'으로 구분하고, 그 외에는 '직군' 단위의 레이블만 활성화시켜 이슈에 적용하였습니다. '아웃게임'의 '클라이언트' 이슈, '인게임'의 '게임디자인' 이슈 등 직관적으로 어디의 어떤 직군의 담당 이슈인가를 파악하는 쪽으로 개선하니, 더 깔끔한 구성으로 이슈를 생성할 수 있었습니다.

기본적으로 내부 프로젝트이기 때문에 사실 레이블을 보지 않고도 어떤 이슈인지는 모두가 이미 알고 있습니다. 따라서 복잡하게 레이블을 구성하는 것보다는, 실질적으로 어디에서 어떤 문제가 발생하였는가만 대략적으로만 알아도 업무 진행에 큰 방해가 되지는 않았습니다. 다만, 현재도 레이블을 입력하는 방식이 QA 팀 내부에서도 각각 조금씩 달라서 상위 방향성을 개선하는 작업은 더 필요해 보입니다.

6) 적용하지 못한 개선사항들

물론 아쉽게도 개선하지 못한 사항들도 있습니다. QA 직군 12명 모두가 원했던 설명 필드의 '기본 템플릿 적용' 은 구글링과 아틀라시안 커뮤니티, 관련 서적을 읽어도 뚜렷한 답을 찾을 수 없어 결국 적용하지 못하였습니다. 유료 애드온 프로그램 중에 관련 기능을 제공하는 프로그램도 있었으나, 이미 유료 서비스를 사용하는 입장에서 또 하나의 유료 서비스를 이용하는 것이 과연 옳은가라는 의구심이 있어 그냥 저희가 이슈를 생성할 때마다 입력하는 것으로 마무리하였습니다.

또한 이슈의 상태에 따라 카드 썸네일에 색상을 표시하는 기능을 넣고 싶었으나 이것도 마찬가지로 JIRA에서 지원하지 않는 기능이고, 애드온 프로그램 중에서도 이런 기능을 제공하는 프로그램이 없어 그냥 넘어가기로 하였습니다. 색깔을 부여하면 좀 더 직관적으로 이슈의 상태를 알 수 있지 않을까 하여 생각한 아이디어였는데, 지원하지 않는 기능이라니... JIRA에 가지고 있는 불만사항 중 하나입니다.

6. 마치며 : 회고

지금 JIRA를 사용하는 것은 너무나 당연한 일이 되었지만, 사실 처음에는 신기하기도 하고 어렵기도 했던 툴이었습니다. 특히나 저는 처음으로 JIRA를 사용해보았기 때문에 더더욱 부담스러웠던 것 같습니다. 이미 JIRA를 잘 알고 있는 분들에게 그냥 맡길까 하는 생각도 있었지만, 결국엔 제가 실질적으로 사용해야 하는 툴이라는 것을 깨닫고 노력으로 어느 정도 환경 구축에 성공한 것 같습니다.

그렇다면 과연 JIRA는 쓸만한 BTS 서비스일까요? 이 질문에는 이렇게 답변할 수 있을 것 같습니다.

BTS의 정석.

그러나 초기 설정 여부에 따라 양날의 검이 될 수 있다.

JIRA는 트렐로처럼 가볍게 슉슉 던지듯이 일처리가 가능한 툴은 아닙니다. 그럼에도 JIRA가 더 효율적이라고 생각하는 이유는 사용자의 작업환경을 편하게 만들어주는 기능들이 트렐로보다 훨씬 더 많기 때문입니다. 트렐로를 쓰면서 가장 불만이었던 "편리하고 정확한 검색(추적)"과 "버전별 이슈 관리(관리)"의 니즈가 충족된 것만으로도 JIRA는 트렐로보다 더 효율적인 툴이라고 말할 수 있을 것 같습니다.

다만, JIRA는 사용자의 숙련도에 따라서 효율성이 천차만별이기 때문에 어떤 경우엔 트렐로보다 더 비효율적일 수도 있을 것 같습니다. 따라서 환경설정이나 수많은 레퍼런스 등 '공부'가 필요한 서비스이기도 하고, 개인적/팀적으로 많은 노력을 기울여야 어느 정도 쓸만한 환경 구축이 가능합니다. JIRA 설정이 어렵다면 간단하게 사용할 수 있는 다른 서비스를 이용하는 것이 오히려 더 효과적일지도 모릅니다.

'어떤 툴을 어떤 방식으로 사용하느냐는 역시나 사람에게 달려 있다.'라는 첫 부분의 문장을 기억하시나요? 그래도 성공적으로 JIRA가 쿠키런 오븐브레이크에 안착한 것은 QA를 비롯한 많은 팀원분들께 공이 있다고 생각합니다. 이 글을 읽는 모든 분들이 각 팀에서 사용하는 서비스들에 대해 사용 피드백을 적극적으로 주는 것이, 그 내용이 사소할지라도 사용성 개선에 큰 힘을 줄 수 있다는 것을 꼭 아셨으면 좋겠습니다. 그럼 이만!