지라와 컨플루언스의 차이
문서에 내용을 기입한다는 관점에서 지라와 컨플루언스의 차이는 점점 줄어들고 있습니다. 하지만 지라에는 문서의 상태를 규칙에 따라 변경하는 자동화된 규칙을 포함한다는 점이 다릅니다.

지난 새로운 시대의 SEO에 대한 고민에서 지금처럼 글을 작성하되 등록해 주신 분들께 전문을 공개하는 정책을 유지할지 고민하는 이야기를 했습니다. 처음에는 당연히 등록해 주신 분들께 전문을 공개했고 이상하지 않다고 생각했습니다. 그런데 시간이 지나며 검색엔진이 특정 검색어에 대해 이 블로그 웹사이트를 상위에 노출 시키기 시작했지만 등록을 요구했기 때문에 결과를 클릭해 본 사람들은 등록을 해야 한다는 사실을 눈치 챈 순간 페이지를 닫아 버린다는 사실을 잘 알고 있습니다. 1년 전과 비교해 검색엔진에 의한 접근이 늘어남에 따라 검색어에 의해 노출된 페이지를 공개하는 편이 낫지 않은가 하는 고민을 해봤습니다.
물론 검색 결과를 클릭한 분들이 뉴스레터에 등록해 전문을 읽어 보신다면 가장 좋은 시나리오이겠지만 그런 일은 영원히 절대 네버 일어나지 않는다는 사실을 잘 알고 있을 뿐 아니라 검색을 하는 사람들은 질문에 대한 즉각적인 답변을 원하곤 하기 때문에 배경부터 설명하고 시작하는 기나긴 텍스트 무더기에 별 관심을 가지지 않는다는 사실 역시 잘 알고 있습니다. 잠깐 동안 전문 공개를 할까 고민했지만 전통적인 검색엔진은 정보 제공에 대해 방문자 모양으로 크레딧을 주지만 현대적인 대규모 언어 모델에 기반한 검색엔진은 더 이상 이런 크레딧을 주지 않으므로 글을 쓰는 입장에서 크레딧을 얻을 수 없을 바에는 검색엔진 역시 글을 읽지 못하는 상태를 유지하는 편이 더 낫다고 판단했습니다.
반면 검색어를 살펴보다가 사용자들이 시도한 검색과 그 결과로 나타난 이 블로그가 검색 목적에 잘 부합하지 않는 사례를 여러 차례에 걸쳐 파악하고 있었는데 처음에는 어쩔 수 없다고 생각했지만 계속해서 같은 검색어에 의해 이 블로그의 글이 맨 위에 나타나는 모습을 보니 계속해서 사용자들이 검색어에 대해 잘못된 결과를 보도록 만드는 것은 좋은 아이디어가 아니라는 생각이 들었습니다. 물론 이런 상황은 검색엔진을 개발하는 사람들이 검색엔진을 더 똑똑하게 만들어 해결해야 하지만 그들은 이미 다른 온갖 문제를 해결하고 있을 테고 구글 같은 전통적인 검색엔진은 조만간 수명을 다할 가능성이 있어 회사 안에서 개발력이 집중되지 않아 좀처럼 개선되지 않을 수 있는 가능성을 고려하지 않을 수 없었습니다.
그래서 검색어를 살펴보고 검색어에 잘 맞는 글을 만들기 시작했는데 컨플루언스에 엑셀을 붙여넣는 현실적인 방법, 컨플루언스 위키의 단점 같은 글이 이에 해당합니다. 컨플루언스에 엑셀을 붙여 넣고 그대로 사용하는 방법을 여러 사람들이 찾고 있었고 또 컨플루언스 위키 사용을 고민하는 분들이 컨플루언스 위키의 단점을 검색하고 있었는데 저는 이런 검색어에 대한 정확한 답변을 작성한 적이 없었고 제 블로그를 봐도 검색을 시도한 목적에 맞는 텍스트를 찾을 수는 없었을 겁니다. 그래서 아예 정확히 검색어에 답하는 글을 만들기 시작했습니다. 오늘 설명할 것은 ‘컨플루언스와 지라의 차이’에 대한 것입니다.

컨플루언스와 지라는 아틀라시안에서 개발해 판매하고 있는 가장 대표적인 두 가지 소프트웨어인데 이전에 참여한 여러 프로젝트에서 이 두 가지 소프트웨어 조합을 활용해 게임을 개발해 왔습니다. 이들 각각은 같은 회사에서 개발한 덕분에 서로 잘 연동되기 때문에 굳이 어느 한 쪽 역할을 하는 다른 소프트웨어를 사용할 필요가 별로 없어 회사 전체에 걸친 문서 관리 소프트웨어를 도입할 때 컨플루언스를 도입한다면 서로 다른 시점에 이슈 관리 도구를 검토할 때 지라를 선택하지 않을 이유가 별로 없습니다. 먼 과거에는 다른 위키, 다른 이슈트래커를 사용하던 시대가 없지는 않았습니다. 개발비 문제로 공개 이슈트래커인 멘티스나 trac을 사용하기도 했고 trac을 사용하던 팀에서는 여기 딸린 위키를 함께 사용하기도 했는데 결과는 썩 좋지 않았습니다. 이들은 작은 규모에서는 잘 동작했지만 팀 규모가 커지고 하루 동안 수 백 페이지가 동시에 수정되는 환경에서는 하드웨어가 뒷받침 되더라도 빠른 검색, 수정, 연결 따위를 제대로 해 내지 못했습니다. 또 많은 미디어 파일을 첨부하려고 하면 이들을 잘 처리하지 못했는데 애초에 이들을 선택한 이유가 개발비가 부족해서였던 만큼 결국 이 프로젝트들은 개발비가 부족해 완수 되지 못하곤 했습니다.
이후 어지간한 프로젝트는 지라, 컨플루언스 조합을 너무나 당연하게 사용했는데 앞에서 이 조합을 사용하는 가장 큰 이유는 이들을 같은 회사에서 만든 덕분에 서로 아주 잘 호환되기 때문이라고 소개했습니다. 이전에 경험한 어떤 프로젝트에서는 노션을 사용합니다. 처음에는 프로젝트 전체에 걸친 문서 관리 도구로 노션을 사용하고 이슈 트래킹은 노션의 데이터베이스 기능을 사용했는데 프로젝트 초반 팀 규모가 작을 때는 그럭저럭 동작했지만 인원이 늘어나고 동시에 일어나는 일이 늘어나자 겉잡을 수가 없게 됩니다. 노션 데이터베이스는 이론적으로 이를 관리하는 사람이 있다면 이 사람의 수동 조작을 근거로 노션 데이터베이스를 이슈트래킹에 사용할 수 있지만 이 역할을 할 독립적으로 고용하거나 이 규칙을 모든 사람들이 숙지하고 수행하도록 만들지 않는다면 절대 제대로 동작하지 않습니다. 예상하셨다시피 노션 데이터베이스를 사용한 이슈트래킹은 본격적으로 개발을 시작한 다음 두어 달이 지나자 도저히 수습할 수 없는 상태가 되어 버렸고 다른 이슈트래커를 도입할 수밖에 없었습니다. 그리고 이 때 고려한 단 한 가지 이슈트래커는 지라였습니다. 그래서 지라와 노션을 함께 사용하는 이상한 세계에서 개발읋 시작합니다.
노션 스스로도 자신들이 노션 데이터베이스가 이슈트래킹에 사용될 수 있다고 광고하기는 했지만 실제 세계에서 그럴 수는 없다는 사실을 이미 잘 알고 있었을 것 같습니다. 이들은 처음 노션을 사용하기 시작할 때에 비해 지라를 점점 더 잘 지원해 어느 시점에는 컨플루언스에서 제공하는 것과 비슷한 수준으로 지라를 지원했는데 가령 노션 페이지에 지라 링크를 붙여 넣으면 예쁜 링크 모양으로 바꿔 이슈키, 제목, 현재 상태, 담당자를 바로 알 수 있는 모양으로 바꿔주기도 하고 지라에 JQL을 보내 돌려 받은 결과를 노션 데이터베이스 모양으로 정리해 표시하고 이를 때때로 업데이트 해 최신 정보를 보여주도록 합니다. 하지만 여전히 컨플루언스에서 지원하는 현재 페이지에 언급된 지라 목록, 지라에 표시되는 이 이슈를 언급한 컨플루언스 페이지 목록과 서로가 서로를 언급할 때마다 알아서 쌓이는 히스토리 같은 기능을 네이티브로 제공하지는 못했습니다. 물론 이를 원하면 지라 오토메이션을 통해 비슷하게 만들 수는 있었지만 이를 만드는 것 역시 사람이어서 이를 유지보수할 자원을 요구했고 노션 데이터베이스를 이슈트래킹에 사용할 때와 마찬가지로 이 역할을 할 한 사람을 고용하거나 이 역할을 여러 사람에게 숙지 시킬 수 없었기 때문에 이는 기술적으로는 가능하지만 현실적으로는 불가능하다고 볼 수밖에 없습니다.
컨플루언스는 위키 방식으로 문서를 작성하고 관리하는 도구입니다. 여기서 위키 방식은 별로 중요하지 않고 문서를 작성하고 관리하는 도구라는 점이 중요합니다. 회사 단위에서 일하다 보면 여러 가지 문서를 만들어야 합니다. 제가 일하는 게임 업계에서는 여러 가지 계획, 기획서, 보고서, 회의록, 현황 파악, 메모 등 온갖 종류의 문서를 생산하며 일하는데 이 문서 모두를 컨플루언스 하나로 해결할 수 있습니다. 컨플루언스는 자유롭게 문서를 생성하고 내용을 작성한 다음 저장할 수 있는데 이들의 연결 관계를 편집하고 이들의 계층 구조를 조정하다 보면 아무렇게나 생성한 문서들이 집합이 어느새 그럭저럭 잘 정리된 회사의 지식 자원으로 활용할 수 있는 상태가 됩니다. 컨플루언스는 단순히 문서를 작성하는 도구일 뿐 아니라 온갖 미디어 파일을 포함할 수 있고 인라인 답글을 통한 의견 교환, 페이지 답글을 통한 논의와 히스토리 보존, 문서의 모든 버전을 저장해 주기 때문에 히스토리를 파악하는데도 유용하고 이 모든 내용에 강력한 검색을 통해 접근할 수 있어 회사 수준으로 문서를 생산하고 관리하고 재활용하는데 강력한 장점이 있습니다. 특히 규모가 커지더라도 이전과 똑같이 동작하기 때문에 급격한 확장에도 아무 문제를 일으키지 않습니다.
지라는 어쩌면 컨플루언스와 비슷하다고 생각할 수도 있습니다. 지라 역시 새 이슈를 생성하면 제목과 내용을 쓴 다음 저장할 수 있고 컨플루언스와 똑같이 다른 문서를 향한 링크를 만들 수 있으며 답글을 달 수 있고 미디어를 포함할 수 있으며 검색을 통해 문서를 찾아내 재활용하는데 사용할 수 있습니다. 이론적으로 지라는 컨플루언스의 기능을 거의 완전히 대체할 수 있으나 그 반대는 잘 성립하지 않는데 컨플루언스에도 노션과 거의 같은 데이터베이스 기능이 있어 지라의 역할을 하도록 만들 수 있지만 노션 때와 마찬가지로 데이터베이스를 구동하는 로직을 별도의 사람, 혹은 팀 전체에 수동으로 맡겨야 하기에 이론적으로는 가능하지만 실제로는 동작하지 않습니다. 반면 지라는 제목과 내용을 쓸 수 있고 답글을 달고 검색하고 서로를 연결할 수 있다는 점에서 컨플루언스가 가진 기능을 거의 다 가지고 있을 뿐 아니라 그 스스로가 컨플루언스 데이터베이스처럼 동작하면서도 글 각각의 상태가 미리 만들어진 규칙에 따라 알아서 동작하기 때문에 이슈트래커로도 아무런 문제 없이 활용할 수 있습니다. 만약 어떤 이유로든 컨플루언스와 지라 중 단 하나만을 고를 수밖에 없는 상황에 놓인다면 저 혼자 사용할 경우 컨플루언스를 선택하겠지만 여러 사람들과 프로젝트를 수행해야만 한다면 지라를 선택할 겁니다.
지라와 컨플루언스의 가장 큰 차이는 컨플루언스는 문서를 만들면 그 문서가 상시 같은 상태로 유지되지만 지라는 문서를 생성하면 그 문서의 상태가 바뀌며 그 상태에 따라 일의 진행 상황을 파악할 수 있도록 해준다는 점입니다. 지라는 컨플루언스로 새 페이지를 생성하는 것과 똑같이 새 지라 이슈를 만들 때 제목과 내용을 작성하지만 이 뿐 아니라 담당자는 누구인지, 마감은 언제인지, 다른 어떤 이슈와 어떤 연결 관계를 가지고 있는지, 그리고 현재 상태는 무엇인지를 제각기 입력할 수 있습니다. 프로젝트 정책에 따라 어떤 값은 비워 놓을 수 있지만 어떤 값은 반드시 작성해야만 하는데 프로젝트에 따라 마감 일자를 기록하거나 기록하지 않도록 하기 위해 팀 사이에 첨예하게 대립한 적도 있습니다. 한 번 생성된 지라 이슈는 이 이슈의 담당자, 마감 일자, 현재 상태를 함께 기록하기 때문에 이슈를 열어보면 이 이슈의 현재 상태를 알 수 있습니다.
가령 컨플루언스에 작성한 기획서는 그저 문서일 뿐이지만 지라에 기획서를 작성했다면 이 이슈는 현재 담당자가 설정되어 있고 또 현재 상태가 있습니다. 가령 상태는 준비, 진행중, 테스트 가능, 완료 같은 형식으로 구분될 수 있기 때문에 고정된 문서가 아니라 이 문서가 현재 어떤 상태인지를 함께 파악할 수 있습니다. 즉 컨플루언스와 지라는 서로 제목과 내용을 기입하는 관점에서는 문서를 작성하는 도구라는 점에서 별로 다르지 않지만 지라는 컨플루언스에 비해 담당자, 기한, 현재 상태 등 다양한 추가 정보를 기입하도록 요구할 수 있고 작업 진행에 따라 이 정보가 바뀌며 문서의 현재 진행 상태를 함께 표현하고 이 정보 중 일부는 상황에 따라 자동으로 바뀐다는 점에서 차이가 있습니다.
그렇다면 컨플루언스를 지라처럼 사용할 수는 없을까요? 가령 컨플루언스 페이지 위에 표를 만들고 그 표에 담당자, 마감 기한, 현재 상태 따위를 기입하고 상황에 따라 이를 업데이트 하도록 만든다면 굳이 컨플루언스에 비해 라이선스 요금이 일인당 두 배 정도 비싼 지라를 동시에 사용할 필요가 없을 수 있지 않을까요? 앞에서 여러 번 이야기했는데 이론적으로, 그리고 기술적으로는 가능하고 그 반대 역시 마찬가지입니다. 우리들 모두가 문서에 표시된 상태에 따른 처리 방침을 정확히 이해하고 이를 규칙에 맞게 수행한다고 보장할 수 있다면 지라는 필요하지 않습니다. 지라와 컨플루언스를 함께 사용할 때 드는 비용의 33%만 들이면 컨플루언스 만으로도 일할 수 있습니다. 하지만 모든 사람들이 정확히 규칙에 따라 컨플루언스 문서의 여러 값들을 바꿀 거라고 보장할 수 있을까요?
가령 컨플루언스에 작성된 어떤 기획서의 현재 상태가 ‘진행중’이었는데 그 다음 상태는 반드시 ‘테스트 가능’으로 바뀌어야 함에도 누군가 실수로, 혹은 고의로 ‘완료’로 바꿨고 다른 누군가가 이 사실을 눈치 채지 못하고 그냥 지나간다면 이 문서는 완료 상태가 되고 나중에 테스트 되지 않아 문제를 일으킬 수 있습니다. 또 ‘테스트 가능’으로 바꿀 때 자동으로 담당자가 테스트 해야 하는 사람으로 바뀌어야 하는데 이를 빠뜨려 상태만 바뀌고 담당자가 바뀌지 않았다면 또 다른 문제를 일으킬 겁니다. 그래서 지라가 필요합니다.
지라는 문서를 작성하는 관점에서 컨플루언스와 별로 다르지 않지만 컨플루언스와 달리 글 하나에 여러 가지 다른 값들을 포함할 수 있고 이 값들은 규칙에 따라 움직이도록 미리 설정할 수 있습니다. 만약 컨플루언스 데이터베이스를 사용한다면 각각의 값을 움직이는 규칙에 따라 값을 업데이트 하는 사람이 따로 있거나 이를 자동화 하기 위한 별도의 개발이 필요하겠지만 지라는 비개발자도 값이 변경되는 방법, 값이 변경될 때 함께 바뀌어야 하는 값 목록을 설정하고 또 어떤 값이 바뀌어야 하는 순서에 따라 바뀌도록 만들 수 있고 이렇게 한 번 설정해 두면 실수 없이 계속해서 이 규칙에 따라 동작할 거라는 사실을 보장할 수 있습니다.
즉 컨플루언스는 문서를 작성해 놓으면 그 상태 그대로 유지되며 인라인, 또는 페이지에 답글을 달며 이를 해결하는 과정을 통해 문서를 작성하는 일 자체에 집중하는 도구라면 지라는 비슷하게 문서를 작성하는데 사용할 수 있지만 이렇게 생성한 이슈의 현재 상태, 담당자, 마감 기한 같은 값들을 입력하고 이들이 규칙에 따라 변경되는데 따른 현재 상태를 파악하는데 사용할 수 있다는 점에서 비슷하지만 서로 다릅니다. 하지만 문서를 작성한다는 관점에서 이들 둘은 충분히 비슷해 보일 수 있습니다.
이전 한 프로젝트에서는 개발비용을 절약하는데 극도로 집중해야 했는데 여러 가지 자잘한 비용을 낮추는데 동의했지만 당시 사용하던 노션의 데이터베이스 기능에 대한 광고를 근거로 지라를 사용하는 대신 노션 데이터베이스를 사용하면 어떻겠느냐는 스폰서의 진지한 제안을 듣고 혈압이 오르지 않기는 어려웠습니다. 진지하게 노션과 지라의 차이점, 개발 철학, 실제 개발 환경에서 어떻게 서로 다르게 사용되는지 따위를 설명해야만 했고 이 과정에서 제 스스로도 지라와 컨플루언스, 지라와 노션 사이의 차이를 더 잘 설명할 수 있게 됐지만 그런 행동을 하고 있는 저 자신의 행동에 깊은 수치심을 느꼈습니다. 결국 계속해서 노션과 지라의 불편한 동거를 유지했지만 이미 소개했다시피 비용을 절약해야 했던 프로젝트는 결국 비용이 부족해 완수할 수 없는 운명을 맞이합니다.
지라와 컨플루언스는 비슷합니다. 제목과 내용을 쓸 수 있고 서로를 연결하고 검색하고 답글을 달 수 있다는 점에서요. 컨플루언스는 문서 자체를 작성하고 유지하는데 집중하며 관련 기능이 없지는 않지만 현재 상태를 파악하고 다음 상태로 전환하는데 집중하기 보다는 문서 자체의 완성과 보관, 검색을 통한 재발견에 초점을 맞춘 도구입니다. 지라 역시 제목과 내용을 입력해 문서를 작성할 수 있지만 여러 다른 값들을 함께 입력해 두면 미리 수립해 둔 정책에 따라 값들이 변경되며 이 이슈가 대표하는 실제 업무의 진행과 현재 상태를 파악하고 업무 간의 연관관계를 만들고 유지하는데 초점을 맞춘 도구입니다. 결국 아틀라시안에서 개발한 도구만으로 프로젝트를 이끌어 간다면 서로 비슷한 점이 있음에도 불구하고 문서는 컨플루언스로, 이슈 관리는 지라를 사용하는 다른 여러 팀에서 하는 것과 같은 구성을 갖추는 편이 장기적으로 오히려 비용을 줄이며 프로젝트를 완수하는 방법입니다.