CLOUD-6999 처리로 보는 잘못된 지라 사용 사례
CLOUD-6999를 추모하며 아틀라시안이 지라를 사용하는 방식을 살펴봅시다. 부디 그곳에서는 2레벨 서브도메인처럼 추한 모습을 벗어나기를 바랍니다.
서기 2024년 8월 15일 늦은 오후 아틀라시안이 개발해 그들 스스로 사용하고 있는 클라우드 프로젝트 지라에 발급되었던 CLOUD-6999의 상태가 ‘Resolved’로 변경되었습니다. 이 태스크는 처음 만들어진 다음 가장 오랫동안 해결되지 않는 태스크는 아니었지만 처음 만들어진 다음 오랜 세월에 걸쳐 완료되지 않아 온 것으로 명성이 높았습니다. 특히 이 태스크는 7천명이 넘는 투표를 받아 아틀라시안이 외부에 공개해 사용자들로부터 직접 기능 요청을 받는 태스크로는 가장 높은 투표를 받았음에도 오랜 세월에 걸쳐 해결되지 않은 것으로 또 다른 명성을 얻고 있었습니다. 이 태스크를 소개하는 말의 시제가 모두 과거형인 이유는 이제 이 태스크는 완료 처리 되었기 때문입니다.
이 태스크가 처음 만들어진 때는 지금으로부터 10년 이상 전인 2011년의 초여름이었는데 태스크가 처음 생성된 다음 13년 1개월 7일 4시간여만에 초기 요구사항과는 아무런 관계가 없는 이상한 모양으로 구현이 진행된 다음 요구사항을 만족하지 못했음에도 태스크가 완료 상태로 변경되었습니다. 이 태스크가 얼마나, 그리고 어떻게 최초 요구사항과는 완전히 무관한 이상한 기능 개발을 통해 마무리되었는지는 이전에 작성한 고마워요.아틀라시안!! 저주 받으세요!!를 통해 확인할 수 있으니 여기서 또 다시 자세히 언급하지는 않으려 합니다. 다만 13년이 넘는 오랜 세월에 걸쳐 개발되었음에도 고객들의 요구사항과 완전히 빗나간 이상한 모양으로 기능을 만들어낸 다음 태스크를 닫은 그들의 모습을 보며 이 태스크가 드디어 그 저주받은 생을 마무리한 채 어둡고 습한 묘지의 구석진 자리에 들어갔음을 슬퍼하며 추모 페이지를 만들었습니다.
태스크가 아틀라시안에 의해 구현되고 또 이 구현에 따라 완료 처리 되었음에도 태스크가 완료 처리 되었다는 무력한 현실 앞에 컨플루언스 사용자로써 아쉬움과 안타까움을 느끼며 그를 추모하게 된 이유는 물론 아틀라시안이 태스크에 분명히 기입된 고객의 요구사항을 10년이 넘는 세월에 걸쳐 완전히 무시했을 뿐 아니라 고객의 요구사항과는 아무 관계 없는 이상한 모양으로 구현했다는데 있지는 않습니다. 이 태스크의 완료 처리를 추모하는 가장 큰 이유는 아틀라시안이 개발한 지라는 전 세계적으로 널리 사용되는 태스크 관리 솔루션이 되었으며 이에 따라 전 세계에 걸친 온갖 프로젝트에서 지라를 사용해 그들의 지라 없이는 관리 불가능했을 태스크를 그저 그런 두뇌를 지닌 인간들의 모임만으로도 아슬아슬하게 지탱하고 있는 상황에서 그들 스스로도 지라를 사용하면서 지라를 개발한 그들, 아틀라시안 스스로가 지라를 그리 잘 활용하지 않는 사용 사례를 만들어냈기 때문입니다. 개인 영역, 그리고 업무 영역 양쪽 모두에서 지라를 사용해 지라 없이는 제대로 해내지 못했을 더 규모가 큰 일들을 처리해 가면서 이 자유도 높은 도구를 올바르게 활용해 기왕 이용 요금을 지불하는 김에 최상의 결과를 만들어낼 방법을 오랜 시간에 걸쳐 고민해 왔습니다. 단순하게는 지라 이슈키의 쓸모를 설명하기도 하고 좋지 않은 태스크 이름을 만들지 않는 요령을 고민해 보기도 했습니다. 오늘은 이런 구질구질한 이야기를 뒤로 하고 이미 고객의 요구사항과는 아무 관계 없는 모양으로 구현된 기능을 뒤로 하고 완료 처리 된 아틀라시안이 직접 관리하는 클라우드 제품군에 대한 고객의 요구사항을 받는 용도로 사용하는 CLOUD 프로젝트에 가장 오랫동안 처리되지 않고 있던 태스크 중 하나인 CLOUD-6999의 최후를 살펴보며 아틀라시안이 지라를 사용하는 방식을 살펴보고 우리들이 배울 점, 배우지 말아야 할 점을 생각해 볼 작정입니다.
이미 아틀라시안은 클라우드 기반의 컨플루언스와 지라 각각에 대한 요구사항을 접수하는 다른 지라 프로젝트를 운영하고 있습니다. 아마도 초창기에 아틀라시안은 그들의 클라우드 제품군을 런칭하면서 기존 서버 제품군과는 분리된 지라 프로젝트에 고객들의 요구사항을 접수하기를 원했던 것 같습니다. 그래서 그들의 지라 프로젝트에 CLOUD 프로젝트를 새로 만들었고 여기에는 컨플루언스 뿐 아니라 클라우드 기반의 지라에 대한 요구사항도 함께 받았습니다. 세월이 흐르며 클라우드 제품군의 종류가 늘어나자 아틀라시안은 기존 CLOUD 프로젝트를 통해 요구사항을 받는 대신 클라우드 기반의 다양한 제품군 별로 서로 다른 지라 프로젝트를 만들어 고객들로부터 요구사항을 따로 받기 시작합니다. 하지만 오래 전 만들어진 프로젝트 하위에 아직 열려 있는 태스크가 있는 이상 프로젝트 전체를 완전히 닫고 각 클라우드 제품군마다 별도로 만들어진 지라 프로젝트를 사용하도록 강제할 수는 없었을 겁니다. 또한 고객들 역시 비록 오랜 세월에 걸쳐 요구사항이 반영되지 않더라도 요구사항에 대한 개발이 진행되고 있다는 사실을 알고는 있기에 이미 클라우드 제품군 별로 구분된 지라 프로젝트가 운영되고 있다는 사실을 알면서도 그들의 클라우드 제품군 초기에 만들어진 이 지라 프로젝트를 떠나지 않고 그에 포함된 태스크 각각을 주의 깊게 살펴보고 있었습니다.
클라우드 제품군 별로 구분된 새로운 지라 프로젝트 역시 거의 동일하게 운영되는데 이 오래된 CLOUD 프로젝트는 먼저 유료 상품을 구독하는 고객이 직접 태스크를 생성할 수 있습니다. 하지만 태스크는 생성한다고 해서 바로 아틀라시안의 구현 목록에 올라가지는 않습니다. 일단 지라 프로젝트에 올라온 태스크는 다른 사용자들로부터 투표를 받는 단계를 거치는데 수많은 태스크가 이 단계에서 다른 사용자들의 관심을 받지 못해 그대로 열려 있다가 오랜 시간이 지나면 규칙에 의해 닫히게 됩니다. 만약 이 단계에서 다른 사용자들로부터 충분한 투표를 받으면 그 시점에 아틀라시안의 검토 대상이 되며 아틀라시안은 태스크를 그대로 받아들일지 아니면 이 태스크의 내용에 기초해 다른 태스크를 정의할지, 아니면 어떤 이유로든 태스크를 받아들이지 않기로 결정할 수 있습니다. CLOUD-6999는 13년 전 어느 날 컨플루언스 사용자에 의해 처음 만들어져 그 후 오랜 기간에 걸쳐 지속적으로 다른 사용자들의 투표를 받았고 투표 수가 임계치를 넘기고 나서 아틀라시안의 검토 대상이 됩니다. 물론 태스크를 받아들이기로 결정했다 하더라도 당장 구현을 시작할 수 있지는 않을 겁니다. 그들의 업무 목록은 그렇잖아도 바삐 일해도 쉽게 완료하기 어려울 만큼 많은 우리가 알 수 없는 온갖 작업들로 이미 가득 차 있을 것이고 우리들이 클라우드 제품군에 아틀라시안 도메인 대신 커스텀 도메인을 사용할 수 있게 해 달라는 요구사항을 바로 추가하기는 어려움이 있을 겁니다. 하지만 일단 아틀라시안이 기능을 개발하기로 결정하면 담당자가 설정되고 잊어버릴 만 하면 한 번 씩 진행 상황을 알 수 있습니다.
재미있는 점은 이 태스크에 담당자가 할당된 다음 오랜 세월에 걸쳐 대략 1년에 한 번, 또는 반 년에 한 번 정도 개발 진행상황을 설명하는 글이 올라왔는데 최근 몇 년을 제외한 그보다 더 오래된 진행상황 안내는 제가 글을 제대로 읽었는지 여러 차례 의심할 정도로 이상한 내용일 때가 많았습니다. 가령 개발 진척을 보고할 때 제 입장에서 글을 거칠게 요약하한 결과는 두 가지 밖에 없습니다. 그래서 개발이 완료되었는가, 그렇지 않은가의 두 가지입니다. 그런데 그들이 올리는 글은 항상 둘 중 어느 하나로 요약할 수가 없었는데 그들은 개발을 시작하기 전에 이 기능이 가져올 온갖 사이드이펙트를 검토하고 온갖 보안 문제를 확인하는데 아주 긴 시간을 소요하고 있다는 내용이었기 때문입니다. 물론 이를 ‘개발이 완료되지 않았다’라고 거칠게 요약할 여지가 없지 않지만 이는 적어도 개발이 시작 된 다음에 할 수 있는 요약 방법이라고 생각합니다. 그들의 진행 안내는 아무리 곱씹으며 다시 읽어봐도 아직 개발을 전혀 시작하지 않았다고밖에 해석할 수밖에 없었습니다. 개발을 시작하지 않았다고 가정할 때 그들이 진척을 안내하는 글에 아무런 내용도 포함할 수 없으며 그 결과 그런 이상한 긇 여러 개가 만들어졌다는 사실이 그리 이상하지 않습니다. 이들은 오랜 세월에 걸쳐 몇 차례 아무런 내용도 없는 이상한 글, 그러니까 사이드이펙트를 점검하거나 보안 문제를 미리 검토하는데 엄청난 시간을 사용했다고 주장했지만 결국 개발은 전혀 이루어지지 않았음을 의미하는 그런 글을 올려 댔고 그러는 사이에도 시간은 계속해서 흐릅니다.
그리고 지금으로부터 다시 몇 년 전 그 사이에 몇 번이나 변경된 또 다른 담당자는 처음으로 그림 한 장을 공유하며 사람들의 이목을 집중시켰는데 바로 커스텀 도메인이 구현될 때 고객들이 사용하게 될 인터페이스 목업이었습니다. 이 목업은 하도 어이가 없어 도대체 이들이 무슨 개소리를 하는가 싶어 한참을 생각한 다음 CLOUD-6999의 괴상한 2레벨 서브도메인 접근에 제가 이해한 내용을 적어 봤는데 지금에 와서 돌아보면 제가 이해한 것과 실제로 구현된 기능 사이에 거의 차이가 없었고 이 때 제가 잘못 이해했을 거라고 생각한 그 괴상한 기능은 제가 올바르게 이해했을 뿐 아니라 그 괴상한 기능이 정말로 그대로 개발되었다는 현실 역시 변하지 않았습니다. ‘Allow custom domains for Cloud apps’의 초기 요구사항은 'Today, you can sign up for certain Atlassian cloud products (Jira Software, Jira Service Management, and Confluence) under the subdomain of your choice. For example, if your company is Acme, you can host these products under acme.atlassian.net. The scope of "custom domains" on this ticket is to allow customers to use Atlassian cloud products on their own second-level domain, i.e. jira.acme.com or acme.com/confluence'로 아틀라시안이 제공하는 도메인 대신 고객이 제공한 도메인 혹은 서브도메인을 사용하게 해 달라는 것이었습니다. 이는 우리들이 인터넷을 사용하며 보는 여러 서비스들로부터 흔히 볼 수 있는 형태인데 이 블로그 주소가 ‘blog.woojinkim.org ’인 것과 비슷합니다. 하지만 아틀라시안은 이 요구사항을 멋대로 해석해 ‘confluence.acme.com’ 대신 ‘confluence.FIXED-WORD.acme.com’ 모양의 두 단계 서브도메인을 사용한 주소만을 사용할 수 있도록 개발 중이라는 공지를 남깁니다.
수많은 사용자들이 몰려와 태스크에 언급된 초기 요구사항을 언급하며 우리들 중 누구도, 단 한번도 두 단계의 서브도메인이 필요하다고 말한 적이 없으며 두 단계의 서브도메인이 일으킬 수 있는 온갖 문제를 언급하며 결코 그렇게 구현되어서는 안된다는 의견을 피력합니다. 두 단계의 서브도메인, 그러니까 ‘confluence.support.acme.com' 같은 사용자가 설정한 이름, 그리고 아틀라시안이 제시한 몇 가지 단어 중 하나인 'support’를 합친 최소 네 단어로 구성된 커스텀 도메인은 일단 보기에 나쁘고 기억하기 어렵습니다. 또 ‘co.kr’과 같이 애초에 도메인을 포함한 주소가 최소 세 단어 이상으로 구성되는 경우 주소는 더 복잡하고 이상한 모양이 될 수밖에 없습니다. 뿐만 아니라 서브도메인 레벨 수에 따라 인증서를 발급하는데 별도의 절차가 필요한 경우도 있는데 가령 클라우드플레어로부터 인증서를 발급해 사용한다면 ‘confluence.acme.com’처럼 첫 번째 단계의 서브도메인을 사용할 경우 이들이 무료로 제공하는 유니버설 인증서를 그대로 사용할 수 있습니다. 하지만 ‘confluence.support.acme.com’과 같이 두 번째 단계의 서브도메인이 추가되면 이때부터는 유니버설 인증서를 사용할 수 없어 최소 월 10달러 정도의 비용을 지불해야만 합니다. 또한 사용자에 따라 애초에 한 단계 이상의 서브도메인을 발급 받아 사용해야만 하는 경우도 있는데 주로 교육 기관이나 정부 기관에서 이런 시나리오가 나타납니다. 가령 이미 하위 기관에 발급된 서브도메인이 ‘lab.department.acme.com'과 같은 형식일 수 있는데 처음부터 이런 모양의 도메인을 보유하고 있을 경우 아틀라시안이 제안한 추가로 두 단계 서브도메인이 추가되면 'confluence.fixed.lab.department.acme.com’의 완전히 이상한 주소를 사용해야만 할 수도 있습니다.
이런 사용 방법이 워낙 이상한 나머지 ‘CLOUD-6999’의 미래에 대한 암울한 생각을 통해 이들이 애초부터 이 요구사항을 제대로 해결할 생각이 아예 없을 지도 모른다는 생각을 해봤습니다. 사실 컨플루언스 서버 버전이 선셋팅 되면서 커스텀 도메인을 사용할 수 없게 되었지만 이들이 컨플루언스 클라우드 제품군에 커스텀 도메인을 제공하지 않는다 하더라도 커스텀 도메인을 아예 사용할 수 없는 상황은 아닙니다. 컨플루언스 데이터센터 버전 고객들은 여전히 직접 컨플루언스 웹사이트를 호스팅하고 직접 커스텀 도메인을 제어할 수 있습니다. 다만 데이터센터 버전은 직접 사이트를 호스팅 해야 한다는 점 말고도 최소한 월 사용자 500명부터 계약할 수 있다는 점 때문에 넓은 범위의 컨플루언스 고객들이 사용할 만한 기능은 아닙니다. 그렇다 보니 어차피 아무 것도 안 해도 커스텀 도메인이 필요한 충분히 규모가 큰 고객들은 알아서 데이터센터 버전을 구입할텐데 굳이 그보다 훨씬 규모가 작을 가능성이 있는 클라우드 고객들에게 커스텀 도메인 기능을 제공해 봐야 별 의미가 없다고 판단했을 수 있다고 생각합니다. 그래서 고객들이 도저히 받아들이기 어려운 이상한 제안을 한 다음 고객들이 제안해 대해 격렬하게 거부 의사를 보이면 이를 검토하겠다는 핑계로 또 다시 이후 한 10년 정도는 우습게 보낼 수 있는 이유가 된다고 생각했습니다. 워낙 두 단계 서브도메인 아이디어가 이상하게 받아들여졌기에 이들이 그저 고객들의 이목을 엉뚱한 곳에 집중 시키고 개발하지 않을 방법을 찾고 있어 보였습니다.
하지만 그로부터 또 다시 몇 년이 지난 다음 이들은 정말로 이들이 그림으로만 제안했던 두 단계 서브도메인을 반드시 요구하는 커스텀 도메인 기능을 정말로 출시해버렸습니다. 이 사건이 어찌나 충격적이었는지 처음 이 기능을 테스트 해 보고 고마워요.아틀라시안!! 저주 받으세요!!라는 생각을 할 수밖에 없었습니다. 일단 이들은 기능을 만들었습니다. 하지만 그 지라 태스크를 처음 만든 사람, 그리고 10년이 넘는 세월에 걸쳐 태스크에 답글을 단 모든 사람들 중 어느 누구도 요구한 적 없는 두 단계 서브도메인을 요구했고 이를 적용한 주소는 정말로 이상해 보입니다. 저는 이 기능을 테스트 해 보며 도저히 중간에 무슨 단어를 넣어야 할 지 결정할 수가 없었고 고민 끝에 중간에 점을 하나 찍어 ‘confl.uence.woojinkim.org’라는 주소를 만들었는데 이 주소를 입력하고 다음으로 넘어갈 때 느낀 당혹스러움, 실망감, 무기력함, 분노, 좌절 같은 기분이 끝없이 올라왔고 마치 지구 저 편의 아틀라시안 오피스에서 이 기능을 만든 사람들이 저런 웃긴 모양으로 만들어지는 커스텀 도메인에 기반한 컨플루언스 웹사이트를 보며 낄낄대고 있을 것만 같은 생각마저 들었습니다. 컨플루언스 클라우드 사용자들은 그들의 규모가 얼마나 크든 말든 이 괴상한 상황에 대항할 방법이 없었습니다.
10년이 넘는 세월에 걸쳐 기다려 온 커스텀 도메인 기능이 누구도 원하지 않은 이상한 모양으로 만들어졌다 하더라도 그나마 제대로 동작이라도 했다면 이 절망적인 기분을 좀 가라앉힌 다음 그 추한 모양으로라도 사용해볼 생각을 했을른지도 모릅니다. 하지만 커스텀 도메인을 적용하자 과거에 컨플루언스 앞에 붙여 커스텀 도메인을 씌운 것처럼 동작하게 만들어 주던 cloak.ist를 사용할 때, 그리고 기술적으로 이와 거의 똑같은 방법인 클라우드플레어 터널을 사용해 컨플루언스 클라우드에 커스텀 도메인 설정을 사용할 때와 완전히 똑같이 오동작 하는 모양을 보고 아틀라시안은 정말 이 기능을 똑바로 개발해낼 생각이 전혀 없음을 느끼지 않을 수가 없었습니다. 만약 그들이 이 기능을 위해 그렇게 오랜 세월에 걸쳐 온갖 사이드이펙트를 고려하고 보안 문제를 점검했다면 그 과정에서 커스텀 도메인이 적용될 때 서드파티 애플리케이션 뿐 아니라 그들 스스로가 만든 기능인 답글, 관련글 표시, 통계, 빠른 이미지 로딩 같은 기초적인 기능이 동작하지 않는다는 사실을 모를 수가 없다고 생각합니다. 또한 커스텀 도메인을 적용하자마자 전혀 상관 없어 보이는 지라 API가 응답하지 않게 됐는데 이 역시 만약 이들이 이 기능을 충분히 숙고해서 개발했다면, 또 이 기능을 충분히 잘 테스트했다면 빠뜨릴 수가 없습니다. 하지만 아틀라시안이 직접 개발한 커스텀 도메인을 적용하자마자 이미 제가 다른 방법을 통해 경험했던 문제들이 몽땅 일어나는 모습을 보고 아틀라시안이 결코 커스텀 도메인 기능을 고객들이 원하는 모양으로 개발할 생각이 없으며 이들은 하루라도 빨리 이 저주 받은 태스크를 닫고 영원히 신경 쓰지 않을 궁리만 하고 있다는 것 이외의 원인을 상상할 수가 없었습니다.
한편 아틀라시안이 이 지라 태스크를 다루는 방법을 통해 우리들이 어떤 기능 개발을 요구하는 지라 태스크를 다루는 방식을 비교해 보고 우리들이 과연 지라를 올바르게 사용하고 있는지 점검해볼 수 있습니다. 이 태스크는 13년 전 처음 만들어질 때 분명 사용자가 제시한 탑 레벨 도메인 그대로, 혹은 한 단계 서브도메인을 붙인 모양의 주소를 사용할 수 있어야 한다고 명시하고 있습니다. 그런데 세월이 흐른 다음 이 태스크를 담당한 누군가는 갑자기 최소 두 단계의 서브도메인을 강제로 사용해야만 하는 모양으로 멋대로 요구사항을 변경했습니다. 제가 지라를 사용해 프로젝트를 수행할 때 어떤 지라 태스크에 근거해 기능을 개발하다가 중간에 어떤 이유로든 구현이 크게 변경될 경우 이 구현의 근거가 된 지라가 실제 구현된 기능과 큰 차이를 보이기 때문에 기존 태스크는 답글에 상황을 설명한 다음 닫고 다른 태스크를 만들어 이 태스크가 왜 만들어졌는지, 이 태스크에 의해 예상할 수 있는 기능은 어떻게 동작하는 것인지 설명해 실제 구현된 기능을 뒷받침할 수 있는 태스크를 만들며 개발합니다. 물론 실제 개발된 모양이 최초 요구사항으로부터 벗어났다 하더라도 여전히 같은 지라 태스크에 근거해 개발을 계속할 수도 있지만 이 상태를 그냥 두면 태스크에 따라 빌드를 검토할 때 명백히 태스크와 전혀 맞지 않는 빌드를 보고 이를 버그로 정의해야 할 지 검토하는데 누군가의 시간을 소모하게 될 수 있습니다. 때문에 개인적으로는 중간에 구현이 변경될 경우 이에 맞춘 태스크를 재정의하고 기존 태스크는 재정의된 태스크의 히스토리로써 역할을 하도록 하는 편이 옳다고 생각합니다.
또 태스크에 기반해 기능을 개발한 다음 이 기능의 결함 때문에 태스크를 닫을지 말지를 결정하는 경우에도 아틀라시안이 이 태스크를 처리한 방식을 참고할 수 있습니다. 아틀라시안은 그 누구도 원하지 않는 모양으로 커스텀 도메인을 개발했지만 그나마 주의 깊게 개발하지 않아 이전에 여러 가지 다른 방식으로 커스텀 도메인을 통해 컨플루언스를 서비스 할 때 겪던 것과 거의 똑같은 문제를 그대로 겪게 만들었습니다. 아틀라시안은 이런 각각의 문제에 대한 버그 태스크를 등록했는데 이 자체는 당연한 행동이지만 개인적으로 주목한 지점은 그 버그를 일으킨 태스크를 처리하는 방법입니다. 게임 소프트웨어 개발 프로젝트를 수행하며 비슷한 경우를 만날 때가 있습니다. 가령 마일스톤 목표로 거래소 기능을 투입한다고 할 때 마일스톤이 끝날 무렵 거래소 기능을 완성해 정신 없이 테스트하며 온갖 문제를 발견해 보고하고 있는 상황입니다. 이 때 일단 거래소가 동작하기는 하지만 여러 가지 결함이 있어 거래소 개발이 완료되었다고 평가할지 아니면 아직 개발이 완료되지 않았다고 평가할지 판단하기 어려울 수 있습니다. 사실 아직 알려진 결함이 남아 있는 이상 기능 개발이 완료되었다고 평가해서는 안된다고 생각하지만 만약 프로젝트가 마일스톤 단위로 진행되며 마일스톤이 기능의 구현 상태가 아니라 날짜에 의해 구분된다면 날짜 경계를 지날 때 개발 완료 여부를 다르게 판정할 수 있습니다.
조직에 따라 마일스톤 목표 완수 여부에 민감하게 반응할 경우 마일스톤 경계를 지날 때 핵심 기능이 동작한다면 알려진 결함은 다음 마일스톤으로 이관하되 이전 마일스톤에서 아직 개발이 끝나지 않았다고 판단해 닫지 않고 있던 거래소 개발 태스크는 완료 처리해 마일스톤 목표를 달성했다고 판단하게 만들고 알려진 결함만 다음 마일스톤으로 넘기도록 처리하곤 합니다. 만약 기능 개발이 완료된 시점과 결함이 발견된 시점이 서로 떨어져 있다면 어쩔 수 없지만 이들이 서로 거의 붙어 있다면 결함이 남아 있는 채로 태스크를 완료 시킬 수 없다고 생각합니다. 하지만 이런 원칙을 곧이곧대로 적용하면 분명 우리의 실제 진행 상태와 무관하게 날짜에 바인딩 된 마일스톤 종료 조건은 결함을 찾아 제거하기에 바쁜 우리들을 순식간에 마일스톤 기간 안에 태스크를 완수하지 못한 무능력자들로 만들어버리고 또 마일스톤 목표 달성률을 100% 미만으로 끌어내린 주범으로 몰려 관리자와 우리 자신들 양쪽 모두로부터 나쁜 평가를 받게 만들기 십상입니다. 그래서 마일스톤이 끝날 무렵 개발되기는 했지만 아직 알려진 결함이 남아 있는 태스크는 마일스톤 경계를 지나기 전에 완료했다고 평가한 다음 알려진 결함은 다음 마일스톤으로 넘겨 시스템 상 마일스톤 목표 달성률을 100%로 유지한 채 다음 마일스톤에 처리할 수 있는 업무 분량을 이번 마일스톤으로부터 이관된 결함의 양만큼 조절하는 수준에서 타협해 누구도 다치지 않은 채 이번 마일스톤을 마무리 할 수 있습니다.
하지만 이런 평가 방법은 마일스톤 단위로 개발을 진행하며 각 마일스톤의 완수 여부에 민감하게 반응하는 조직에서 어쩔 수 없이 행하는 손바닥으로 하늘을 가리려고 시도하는 방법에 지나지 않는다고 생각합니다. 근본적으로 마일스톤은 그 목표를 완수함에 따라 완수 여부를 판정할 수 있으며 여러 가지 이유에 의해 날짜에 바인딩 된 마일스톤 종료 조건에 의해 마일스톤 목표 달성률은 100%가 될 수 없습니다. 이번 마일스톤에 개발된 기능에 아직 알려진 결함이 남아 있다면 이 기능은 명백히 이번 마일스톤에 아직 개발이 완료되었다고 평가할 수 없으며 평가해서도 안됩니다. 개인적으로 생각하는 이 상황의 올바른 처리 방법은 태스크를 이번 마일스톤에 남겨 두되 알려진 결함이 모두 수정되기 전에는 태스크를 닫지 않고 유지하는 것입니다. 이러면 먼저 다음 마일스톤 계획에 영향을 주지 않을 수 있고 또 이번 마일스톤의 현 시점의 달성률을 정확히 평가할 수 있습니다. 그러면 기능의 규모나 예상되는 난이도에 따라 결함 발생 가능성을 마일스톤 계획 단계부터 평가할 수 있기 때문에 결함 가능성을 예측하지 않고 과도한 목표를 설정할 때에 비해 현실적인 목표를 설정할 수 있는 장점이 있습니다. 물론 고위 의사결정자나 경영진 입장에서 마일스톤 목표가 깔끔하게 달성되지 않는 모양을 보고 받을 때 기분이 좀 나쁠 수 있지만 그렇다고 그 기분을 위해 개발팀이 명백한 거짓말을 하게 만들어서는 안된다고 생각합니다.
이 관점에서 아틀라시안이 CLOUD-6999를 처리한 방식을 보면 마치 이들이 우리들처럼 마일스톤 목표 달성 실패 보고를 들을 때 기분 나빠 하는 경영진을 대하는 것과 비슷한 방식으로 태스크를 처리하고 있음을 알 수 있습니다. 지금까지 설명한 개인적인 평가 기준에 의하면 이 태스크는 우선 태스크의 요구사항과 실제 구현된 기능이 전혀 일치하지 않습니다. 앞서 설명한 대로 제가 생각하는 올바른 태스크 처리 방법은 중간에 요구사항이 명백히 변경 되었으므로 현재 태스크는 목표를 완료하지 않은 상태로 닫고 정확한 목표를 서술한 다른 태스크를 만들어 실제 기능과 태스크에 기입된 요구사항 사이에 차이를 줄이거나 없애야 합니다. 여전히 빡치기는 하지만 명백히 이상한 기능을 만들어 놓고 CLOUD-6999가 완료되었다고 평가하기 보다는 명백히 이상한 기능을 만든 김에 이 기능을 뒷받침하는 다른 태스크를 만들어 그 태스크에 의해 기능을 개발했다고 하고 그 근거로 CLOUD-6999를 인용하는 정도로 처리했어야 한다고 생각합니다. 또한 아직 이 기능에 알려진 결함이 남아 있는 상태에서 태스크를 서둘러 닫고 각각의 결함을 처리하는 단계로 넘어간 것 역시 올바른 접근이 아닙니다. 각각의 결함이 기존 태스크가 완료된 다음에 일어났다면 지금과 같이 처리할 수밖에 없습니다. 하지만 이미 알려진 결함이 다수 남아 있는 상태에서 이 결함들이 처리되기도 전에 기능 태스크를 닫아 버리는 것은 명백히 기능 개발이 완료되어 정상 동작하기 전임에도 태스크를 닫아 버린 것과 다르지 않습니다. 오동작 역시 마저 개발 되어야 할 기능의 일부라고 생각합니다.
어차피 이들이 만든 괴상한 두 단계 서브도메인에 기반한 커스텀 도메인 기능을 사용할 생각이 없습니다. 이전에 알려진 결함이 수정되었는지 알 수 없고 또 제 스스로가 그 사실을 확인하기 위해 제 위키와 제 지라를 걸고 실험할 생각이 없습니다. 또한 두 단계 서브도메인에 기반한 커스텀 도메인은 그냥 생긴 것 부터 너무 추해 도저히 사용할 생각이 들지 않습니다. 그럼에도 이렇게 한바탕 생각해본 이유는 아틀라시안 그 스스로가 전 세계적으로 널리 사용되는 태스크 관리 도구인 지라를 개발하고 그들 스스로 지라를 사용하는 입장에서 지라를 올바르게 사용하는 사례를 보여주지 못했다고 생각하기 때문입니다. 요구사항이 구현 도중 크게 변경되어 태스크와 실제 구현 사이에 명백한 차이가 발생해 태스크에 근거해 평가한다면 현재 구현된 기능은 명백히 결함으로 볼 수밖에 없습니다. 이를 방지하기 위해 요구사항이 명백히 변경되었다면 이를 뒷받침할 다른 태스크를 만들었어야만 합니다. 또한 요구사항에 따른 구현이 끝나 태스크를 닫기 전에 아직 알려진 결함이 해결되지 않았다면 태스크를 닫아서는 안됩니다. 이는 아직 구현이 끝나지 않은 상태이기 때문입니다.
지라를 만든 바로 그들이 지라를 이렇게 이상하게 사용하는 모습을 보였지만 어쨌든 지난 13년 넘는 세월에 걸쳐 수많은 사람들에게 고통을 줘 온 CLOUD-6999는 이제 완료 처리 되었고 앞으로 이 태스크를 열어볼 일은 없을 겁니다. 제 개인적으로는 컨플루언스에 커스텀 도메인이 앞으로 영원히 존재하지 않으리라는 사실에 안타까움을 느끼지만 다른 한 편으로는 앞으로 영원히 이 기능 개선에 희망을 걸 필요가 없어져 오히려 잘 되었다고 생각합니다. 하지만 지라를 만들어 전 세계가 이 도구를 사용하게 만들었고 또 그들 스스로가 지라를 사용해 프로젝트를 관리하는 입장에서 그들이 직접 지라의 올바르지 않은 사용 방법을 보여줬다는 점은 몹시 실망스럽습니다.
그럼 이만 그들이 개발한 추하기 짝이 없는 2레벨 서브도메인과 달리 1레벨 서브도메인을 통해 CLOUD-6999를 추모하며 그곳에서는 행복하기를 바랍니다.
