(Case Study) 해외의 음악협회에서 JIRA를 선택한 이유를 확인해 보십시요.

APRA|AMCOS 정보

APRA|AMCOS는 작곡가, 작사가, 출판사의 음악 작품이 언제 어디서 재생, 연주, 복제되든지 간에 이들이 보상받을 수 있도록 합니다.

또한, 호주와 뉴질랜드 음악 소비자들이 세계의 음악 곡목에 접근할 수 있도록 지원합니다.

APRA(호주 공연 권리 협회)와 AMCOS (호주 녹음 저작권자 협회)는 별개의 비영리 조직입니다. 하지만 많은 회원이 둘 모두에 속해 있어서 AMCOS는 일상적인 운영을 관리하도록 1997년에 APRA를 관리 업체로 임명했습니다.

수신 정보 처리

APRA는 회원이 작곡한 노래와 음악 작품의 공연 데이터를 수집합니다.

저는 최근에 솔루션 및 지원 관리자인 Mark Atkins와 함께 수년 간 자체 제작한 도구를 사용하다가 JIRA로 이동한 이유에 대해 이야기를 나누었습니다.

Mark의 새로운 JIRA는 2012년 5월 18일 금요일에 오스트레일리아와 뉴질랜드 전역에서 전체 220명의 직원에게 배포되었습니다.

Mark, 현재 개발 팀에서는 어떤 작업을 진행 중입니까?

“대량의 데이터가 들어오면 우리는 그 데이터를 처리하고 돈을 주인, 즉 작곡자에게 분배해야 합니다. 우리의 최대 규모 데이터 피드 중 하나는 iTunes에서 구매가 이루어지는 노래입니다.

이 모든 데이터를 관리하기 위해 우리는 지난 15년 동안 사내에서 자체 시스템을 개발했습니다. 시스템은 타당한 수준으로 복잡하다 보니 시스템에는 자연적으로 추가된 기능, 버그 등 잡다한 것들이 많았습니다.”
그러면 작업을 어떻게 추적하십니까?

"즉, JIRA에서는 '문제'라고 표현하는 AR(지원 요청)을 추적하려고 예전에 Lotus Notes 데이터베이스를 개발했습니다.

문제는 해당 도구에서 작업이 조직되는 방식으로는 AR을 잘 찾거나 우선 순위를 정하거나 특정 AR의 상태를 쉽게 추적할 수 없었습니다. 우리와 같은 관리자는 다양한 팀의 작업 부하를 정확하게 이해하기가 매우 어려웠습니다.”

그래서 뭔가 조처를 취하기로 결정했고 그래서 JIRA로 전환한 것입니다. 저는 다른 직장에서도 일했었고 Bugzilla 같은 도구도 봤었는데 바로 이전 직장에서 사용하던 게 JIRA였습니다.

우리는 여기서도 Confluence를 사용하고 있습니다. JIRA와 Confluence가 잘 연동되는 것을 아니 결정을 내리기가 쉬웠습니다. 우리는 또 개발 팀을 위해서는 Crucible과 FishEye도 검토 중입니다. IT 작업의 3분의 2는 개발자가 대규모 시스템에서 진행하는 일일 텐데, 이러한 개발자와 비즈니스 요구 사항을 충족하기 위해 필요한 변경 작업의 양을 관리하기란 어렵습니다.

그래서 JIRA를 도입돼서 이런 부분에서 지원을 해주니 아주 만족스럽고 기쁩니다.

APRA|AMCOS가 JIRA를 택한 이유는 무엇인가요?

다른 도구나 문제 추적기도 고려해 보셨습니까?

“아니요. 안 해봤죠. 저는 제품 선택 프로세스를 담당이었습니다. 전에 JIRA를 사용해 본 적이 있어서 뭐 생각할 것도 없었죠.

JIRA 평가판을 다운로드해서 최신 버전으로 사용해보고 관리자 관점에서 알아보고 나니 확실한 선택이었습니다.

그랬던 거죠. 특히 이미 마음먹고 실행하던 Confluence도 있었기 때문에 더 그랬습니다. 둘 사이의 통합은 아주 훌륭했고 둘 사이에서 문제를 만들 수 있다는 것도 아주 좋았습니다.”

“또 한 가지를 말하자면 저는 몇 년 동안 Crucible과 코드 검토를 보아 왔습니다. JIRA ID를 Crucible의 커밋 태그에 넣고 자동으로 링크를 걸게 만들고 JIRA에서 특정 코드와 연관된 소스 코드를 인식하게 만드는 것, 이런 게 환상적인 기능들이죠.

Atlassian 임직원들은 뉴욕 엠파이어 스테이트 빌딩 꼭대기에 올라가서 크게 소리 지를 자격이 있습니다.”

APRA의 개발 작업에 대해 다른 말을 하실 것이 있나요? 애자일 방법을 사용하십니까?

“우리는 폭포수보다는 애자일 방법 쪽에 더 기울어 있습니다. 소스 코드 측면에서 FishEye와 Crucible를 통합 중이고 Subversion을 사용 중입니다.

또한 Single Sign-On용으로 Crowd를 사용 중인데 이것도 아주 놀랍더군요. Crowd는 Active Directory의 지원을 받으므로 여기서는 위임된 인증을 사용합니다.

저는 Crowd를 우리가 구축할 미래의 응용프로그램에 인증 도구로 사용할까 생각 중입니다. 이것은 80년대 Single Sign On 때부터 나온 약속과 비슷한데 실제로 잘 작동하는 것 같습니다.”

“APRA 비즈니스의 특성은 아주 복잡합니다. 특히 다른 사람들의 돈을 받고 있기 때문에 정확해야만 합니다. 그래서 품질을 강조하고 여러 가지가 적절한 방식으로 수행되도록 검토를 많이 합니다.

아직은 애자일 방법이라고 할 수 없지만 점점 더 애자일 방향으로 나아가고 있습니다.”

JIRA에서 관리자의 임무를 맡은 건 어땠습니까?

“네, 거의 할 일이 없는 편입니다. 워크플로를 정해서 프로젝트를 구성하고 나니 더 할 일이 없습니다. 아 그리고 이 부분은 설명서 없이 저 혼자 힘으로 사용법을 터득했습니다.

그 정도로 간단합니다. 알아서 돌아가는 거죠. 우리는 백업과 이런저런 비즈니스를 자동화했고 알아서 잘 돌아갑니다. 관리와 관련해서 투입되는 시간은 0에 가깝습니다.

특히 Crowd를 사용한 덕분이죠. 관리 부문에서 사용자 관리가 필요 없어집니다. 정말 큰 이점입니다.”

보고 및 메트릭

저는 Mark에게 현재 처리되는 티켓 양과 팀에서 SLA와 회원들의 기대치를 얼마나 잘 충족하고 있는지 물어보았습니다.

“글쎄요, 그쪽 정보도 잘 모르겠네요. 제가 아는 건 기존 시스템에서 JIRA의 뛰어난 가져오기 도구 때문에 현재 이미 1,200개의 티켓을 내보냈고 이 티켓들은 JIRA로 가져와서 새 시스템으로 넘겨질 거라는 것뿐입니다.”

“우리가 관심을 갖는 주된 사항은 처리량입니다. 우리가 가진 작업량 때문에 그렇습니다. 우리는 지금 기존 시스템에서 평균적으로 문제가 해결되는 데 소요된 시간 등의 수치도 모르고 있습니다.

JIRA에서 제공하는 시간이나 상태 보고, 그러니까 문제가 여기에 얼마나 오래 있었는지 다른 곳에는 얼마나 있었는지 승인 대기나 동료 검토 대기 등의 자세한 정보는 특히 더 그렇습니다.

표면 아래에서 일어나는 일을 확인할 수 있다면 정말 좋겠네요. JIRA는 팀을 위해 리소스를 설정하고 비즈니스에 대한 기대치를 설정하는 데도 도움이 될 수 있습니다.

저는 최종 사용자와의 연락 담당자라서 그들이 훨씬 더 많이 참여하고 최종 사용자의 작업을 수행하는 방법에 대해 더 만족하기를 바랍니다.

“JIRA는 매우 유연하기 때문에 분명히 워크플로를 사용자 지정했습니다. 동료 검토, 테스트, 최종 검토 등으로 복잡한 워크플로를 적합하게 만들었습니다.

어디에서 문제가 오래 걸리고 병목 현상이 어디에 있는지 보여주는 JIRA의 상태 내 보고서를 비롯한 이 정도의 관리 및 제어 수준은 이전에는 한 번도 사용해 보지 못하던 정보였습니다. 이제는 동료 검토에서 병목 현상이 있는지 살펴보고 거기에 리소스를 좀 추가하거나 어떤 교육을 하고 우리가 가진 이 대규모 워크로드의 측면에서 회사 내 팀으로부터 최대한의 성과를 끌어낼 수 있다고 생각합니다.”

“최근 몇 년 간 일반 비즈니스 담당자들이 불만을 토로하던 것 중 하나는 티켓을 만들어 놓으면 그냥 사라져 버린다는 것입니다.

다른 얘기도 듣지 못하고 티켓을 찾지도 못하고 어떻게 진행되고 있는지 쉽게 알 수도 없었던 것이죠. 이 부분에서 JIRA가 발휘하는 능력은 정말 놀랍습니다. 앞으로도 기대하고 있습니다.”

출시

Mark의 팀은 몇 년 동안 직접 제작한 추적기를 사용했지만 JIRA로의 데이터 마이그레이션은 간단했습니다.

“우리는 CSV 내보내기를 사용했습니다.

JIRA의 가져오기 도구에서 우선 순위와 법규 매핑 등은 정말 환상적이어서 모든 것을 정확하게 제가 원하는 방식대로 설정할 수 있었습니다.

기한일인 18일이 되면 최종적으로 가져오기를 하고 하루 동안 작업 우선 순위를 다시 매긴 다음 새롭게 시작하기 위해 필요한 사항을 점검할 겁니다. 가져오기 도구는 탁월합니다. 우리는 이전 시스템을 병렬로 실행하지 않고 그냥 꺼버릴 생각입니다. 그래서 데이터를 가져오는 겁니다. 바로 원하는 대로 작업할 수 있도록 말입니다.”

채택 현황은 어떻습니까?

“우리는 구현 팀을 합쳐서 작업 중에 시간을 할애해서 우리를 위해 많은 문제를 생성해 달라고 요청했습니다. 우리는 JIRA용으로 기록자 역할, 서명자 역할 등과 같은 어떤 포괄적인 역할을 생성했고 이 역할이 모두 시스템에 액세스하도록 했습니다.

이 역할을 맡은 사람들은 계속 문제 추가 작업을 실험하고 있습니다. 그래서 '아, 이건 또 새로운 거네. 귀찮은데.'하는 느낌을 극복한 다음부터는 모두가 거의 전반적으로 마음에 들어 했고 앞으로 사용하기를 기대하고 있습니다."

업데이트: 최종 마이그레이션을 완수한 다음에 Mark가 보낸 이메일이 이번 주에 도착했습니다.

“최종 데이터 가져오기는 원활하게 잘 되었으며 거기 나온 것들을 보고 깜짝 놀랐습니다. 이미 JIRA 대시보드에는 다양한 정보가 나와 있었죠.

다양한 개발자의 워크로드부터 시작해서 티켓을 가장 많이 생성하는 부서, 문제 유형, 문제가 얼마나 오래 되었는지(붉게 표시) 같은 정보가 보였습니다.

할당 작업을 수행하고 우선 순위를 설정함에 따라 이메일이 이리저리 날아옵니다. 사용자 불만 사항 중 하나는 커뮤니케이션 부족이었는데 지금은 확실하게 해결되었습니다!”

왜 JIRA를 택하셨습니까?

기존 버그 추적기에서 JIRA로 전환한 경우 이유를 말해주시면 도움이 됩니다. JIRA를 선택한 가장 큰 이유를 트위터로 알려주세요.

[이것이] 내가 [내 이전 버그 추적기]를 버리고 JIRA를 선택한 이유 - http://atlss.in/GoJIRA