컨플루언스를 노션으로 전환할 때 고려할 점

개인적으로 수 년 전 보조 두뇌 용도로 도쿠위키를 사용해 오다가 한계를 느껴 컨플루언스 클라우드로 전환한 다음 대단히 만족스럽게 사용해 오고 있습니다. 그 전까지 또 수 년 동안 사용하던 도쿠위키는 AWS 라이트세일에 인스턴스를 만들어 사용했는데 단순하고 유연할 뿐 아니라 오직 파일시스템만을 요구하는 특징 덕분에 마치 완전관리 서비스를 사용하는 것처럼 유지보수에 매몰되지 않고 오랫동안 사용할 수 있었습니다. 하지만 슬슬 문서가 늘어나며 인덱싱이 느려지기 시작했고 또 문서에는 여러 게임의 스크린샷이나 영상을 첨부하다 보니 유지 비용이 급격히 증가했습니다. 가령 이 즈음 모바일 게임을 플레이 하며 그 기록을 남기곤 했는데 아이패드 스크린샷 한 장이 20메가에 달하면서 스토리지 사용량이 급격히 증가해 개인적인 지출로는 감당이 어렵겠다는 결론에 도달했습니다.

비슷한 시기에 지라를 개인 할일 관리에 도입했는데 당시 도쿠위키와 지라는 서로 잘 연동하기 어려웠습니다. 제가 예상한 지라 연동 기능을 수행하는 도쿠위키 플러그인이 있었지만 오픈소스 소프트웨어의 플러그인이 대체로 그렇듯 플러그인은 한동안 유지보수 되지 않아 당시 최신 도쿠위키 버전과 매끄럽게 호환되지 않았습니다. 도쿠위키 최신 버전의 플러그인 스펙 변경에 맞춰 코드를 조금만 수정해 어느 정도 완화할 수 있는 문제이기는 했지만요. 그렇다고 위키 페이지에 지라 링크를 수동으로 만드는 것은 너무 번거로웠고 또 지라 태스크의 상태를 인라인에서 바로 확인할 수도 없었습니다. 뭐가 됐든 도쿠위키를 벗어나 완전관리되는 다른 도구로 전환해야겠다고 마음 먹었는데 이 즈음에도 노션이 있었습니다. 다만 할일 관리 도구로 지라를 선택한 이상 지라를 가장 잘 지원하는 것은 같은 회사에서 만든 컨플루언스일 거라고 생각해 컨플루언스를 선택했습니다.

개인 위키로 컨플루언스 추천해요 (2024)를 비롯한 여러 컨플루언스를 언급한 글에서 이 도구가 팀이나 프로젝트, 회사 단위로 사용하기에도 훌륭하지만 개인적으로 사용하기에도 상당히 적절하다는 이야기를 여러 차례 해 왔습니다. 지금 사용하고 있는 컨플루언스 쿨라우드의 프리미엄 서브스크립션은 스토리지 사용량에 제한이 없고 여러 클래식한 위키와 비교해 편안한 위지윅 환경을 제공합니다. 처음부터 대규모 환경을 감안해 개발된 덕분에 사용량이나 문서량이 늘어나더라도 성능에 별 영향이 없습니다. 이 글을 쓰는 2025년 늦봄 현재 제 컨플루언스 사이트에는 약 1만 5천 페이지, 약 4.8테라바이트 정도의 파일이 있지만 이전 도쿠위키처럼 인덱싱에 문제가 생길 것을 걱정할 필요가 없습니다. 커다란 스크린샷이나 게임 플레이 영상을 첨부하더라도 대체로 문제 없이 소화해 냅니다. 뿐만 아니라 몇 년 전부터 추가된 아틀라시안 인텔리전스를 통해 현대의 인공지능 도입 추세로부터 멀어지지 않고 있고 또 여러 플러그인을 적용해 아틀라시안이 직접 제공하지 않는 범위의 자동화, 외부 컨텐츠 임베딩을 할 수도 있습니다. 개인적인 관점에서 거의 유일한 단점이라면 가격이 조금 높은 점 정도인데 제가 이 도구에 으존하는 수준을 생각하면 프리미엄 서브스크립션에 지불하는 월 십 몇 달러는 사실 이걸 비싸다고 말하면 양심에 찔리는 수준이 아닌가 싶습니다.

컨플루언스가 처음부터 기업용 정보시스템으로 개발되어 개인보다는 기업 위주로 개발되어 컨플루언스를 개인이 사용한다는 발상 자체를 하기 쉽지 않게 만드는 반면 비슷한 분야에 또 다른 걸출한 제품인 노션은 처음에 주로 개인 사용자 위주로 개발되었다가 최근 몇 년 사이에 급격히 기업 수준의 사용자들이 요구하는 기능을 추가하는 모양으로 발전해 온 것 같습니다. 컨플루언스에 비해 노션은 페이지를 보는 상태와 쓰는 상태를 구분하지 않고 아무때나 즉시 쓸 수 있고 또 첫 공개 즈음에는 노션만의 강점이던 데이터베이스를 제공해 다른 도구의 도움 없이 구조화된 데이터를 관리할 수 있었습니다. 특히 구조화된 데이터의 사용 사례로 노션 스스로가 프로젝트 관리를 언급했었는데 사실 이 분야의 강자인 지라를 대체할 수 있을 충분한 가능성이 있습니다. 이는 여러 프로젝트에서 사용하는 지라가 본질적으로 어떤 강점 때문에 프로젝트 관리 요구사항을 광범위하게 소화하게 되었는지를 생각해 보면 어렵지 않게 납득할 수 있습니다.

작업 관리 도구인 지라의 본질적인 두 가지 핵심 기능은 워크플로우 정의와 태스크 별 필드 설정입니다. 먼저 워크플로우는 태스크를 만들고 담당자를 할당하고 또 이 태스크가 진행되는 과정에 따라 태스크의 상태나 값이 변경되어 목표의 가시성을 올려주고 또 상황에 따라 파생되는 계획된 태스크를 자동으로 발급해 담당자에게 할당하며 외부 개발 도구와 연동되어 사람이 직접 진행 상태를 업데이트 하지 않아도 알아서 진행 상황을 업데이트 해 서로 다른 부서 사이에 여러 단계로 구성된 파이프라인을 최소한의 시행착오와 최소한의 관리를 통해 동작하도록 만들 수 있습니다. 이러한 워크플로우의 동작에 필요한 또 다른 중요한 기능이 바로 태스크 별 확장 가능한 필드 설정입니다. 지라는 기본적으로 태스크 키, 서머리, 디스크립션, 담당자, 코멘트의 최소 단위로 태스크를 정의합니다. 여기에 아틀라시안이 미리 정의해 놓은 커스텀 필드를 추가할 수도 있고 또 팁이나 프로젝트가 처한 상황, 워크플로우의 특성 따위를 고려해 커스텀 필드를 직접 만들어 자동으로 관리되거나 사람이 이를 기입하게 만들 수도 있습니다. 지라 태스크는 워크플로우에 따라 진행 상태가 정보시스템에 더 편안하게 반영되도록 해 주고 커스텀 필드는 이 과정의 가시성을 확보하는데 도움을 줍니다. 그런데 워크플로우는 몰라도 커스텀 필드는 근본적으로 거대한 엑셀 파일로 프로젝트를 관리하는 것과 상당히 비슷합니다. 이는 지라 프로젝트를 CSV 포멧으로 익스포트 해 보면 바로 이해할 수 있는데 여러 필드를 나열한 열과 각각의 태스크를 나열한 행으로 구성된 거대한 스프레드시트는 이를 그대로 노션 데이터베이스로 옮길 수 있음을 의미합니다.

다만 노션 데이터베이스는 초기에 정말 데이터베이스 그 자체만을 제공했기 때문에 지라의 두 가지 핵심 기능 중 절반을 지원했습니다. 마치 엑셀로 프로젝트를 관리하는 것과 비슷하게 데이터베이스를 통해 프로젝트를 관리할 수 있었고 각 레코드마다 페이지를 할당해 레코드에 해당하는 정보를 기술하게 만들 수는 있었지만 이는 근본적으로 엑셀이나 구글 스프레드시트를 사용하는 것과 크게 다르지는 않았습니다. 만약 노션이 데이터베이스 기능을 통해 프로젝트를 관리할 수 있다고 진심으로 주장하려 했다면 워크플로우에 해당하는 제어 방법을 함께 제공했어야 합니다. 하지만 초기 노션은 오직 데이터베이스만을 제공하면서도 프로젝트를 관리할 수 있다고 주장했습니다. 하지만 현대에는 노션 스스로가 그런 기능을 제공하지 않더라도 노션 데이터베이스 API를 사용해 지라 워크플로우와 유사하게 동작하도록 만들 수 있습니다. API까지 가지 않더라도 GUI 수준으로 제공하는 이벤트에 따른 동작을 정의해 비슷한 효과를 낼 수도 있습니다. 물론 여기에는 분명히 누군가의 인력을 필요로 하며 아틀라시안에 돈을 좀 내면 지라가 이를 이미 잘 포장된 모양으로 제공받을 수 있는 세계에서 이 일을 왜 누군가가 별도로 수행해야 하는지에 대한 의문은 남습니다.

한편 아틀라시안은 자사의 핵심 제품군인 지라와 컨플루언스를 서버 버전과 클라우드 버전으로 라이선스를 구분해서 판매하고 있었습니다. 서버 버전은 고객이 인프라를 구성한 다음 소프트웨어 라이선스만 획득해 사용하는 것입니다. 반면 클라우드 버전은 인프라를 포함한 서비스 전체의 라이선스를 획득해 사용하는 방식입니다. 개인적으로 사용하는 컨플루언스는 유지보수를 신경 쓰고 싶지 않았기에 간단히 클라우드 버전을 결정할 수 있었지만 보안을 크게 중시하는 전통적인 기업들은 지라와 컨플루언스 서버 버전을 주로 사용해 왔습니다. 가령 이전에 참여했던 어떤 프로젝트는 회사 차원에서 컨플루언스 서버 버전을 운용했는데 컨플루언스 사이트 전체가 망 분리를 통해 폐쇄망에서만 동작했기 때문에 애초에 클라우드 버전을 사용할 수가 없었습니다. 그러다가 아틀라시안은 기존 서버, 클라우드 버전으로 구성된 제품 라인업을 변경합니다. 기존 서버 버전의 판매와 개발을 종료하고 이를 더 대규모 사용자에 맞춘 데이터센터 버전으로 변경합니다. 아틀라시안은 서버 버전의 판매 종료와 지원 종료 시점을 수 년에 걸쳐 공지한 끝에 지금은 데이터센터 버전과 클라우드 버전이 남았습니다. 데이터센터 버전은 이전 서버 버전에 기반해 더 큰 조직과 다양한 컴플라이언스 요구사항에 집중한 좀 더 클래식한 외형입니다. 바년 클라우드 버전은 현대적인 요구사항에 더 집중해 데이터센터 버전과는 상당히 다른 형태와 기능으로 구성된 사실상 이름이 같을 뿐 거의 다른 소프트웨어입니다.

컨플루언스 서버 버전을 사용하던 조직들은 이러한 아틀라시안의 라인업 변경으로 인해 선택을 강요 받게 됩니다. 컨플루언스 서버 버전에서 데이터센터 버전으로 라이선스를 변경하거나 클라우드 버전으로 이전해야 했습니다. 아무리 망 분리를 통한 폐쇄망 환경에서 동작한다 하더라도 시간이 흐름에 따라 더 이상 개발되지 않는 컨플루언스는 현대적인 도구에 요구하는 기능으로부터 빠르게 멀어져 가고 있었습니다. 컨플루언스 서버 라이선스로 추가 비용 없이 사용할 수 있는 컨플루언스 서버 마지막 버전은 8.5인데 이 버전만 해도 이미 에디터가 너무 오래된 방식으로 작동해 현대적인 브라우저에서 단축키가 충돌하거나 어디서나 통하던 마크다운 문법이 이상하게 적용되어 회사에서는 이 도구에 별도로 익숙해져야 합니다. 하지만 함부로 버전을 변경할 결정을 내리기는 쉽지 않았습니다. 회사마다 상황이 다르겠지만 제가 본 사례 안에서는 이러한 정보시스템을 관리하는 부서와 비용을 통제하는 부서가 서로 다르기 때문에 함부로 새로 라이선스 비용을 지불해야 하는 데이터센터 버전으로 변경 혹은 클라우드 버전으로 전환을 직접 결정할 수가 없었습니다. 한 관리 부서는 자신들의 컨플루언스 스페이스에 ‘현 서버 버전이 당장 동작하지 않는 것은 아니니 한 3년 정도 사용하다가 전환을 검토하자’는 기록을 작성해 놓았는데 당시 대략적인 전체 사용자 수에 공개되지 않는 엔터프라이즈 라이선스 비용을 프리미엄 라이선스의 반 정도로 추정하더라도 이미 거대한 금액이 되어 저 의견을 납득하지 않을 수 없었습니다.

어떤 회사는 컨플루언스 클라우드 버전으로 전환을 선택했습니다. 컨플루언스 위키의 단점에서 넷플릭스가 장기간에 걸쳐 사용하던 컨플루언스 서버를 클라우드로 이전하는 과정을 언급했습니다. 여러 명으로 구성된 별도 전환 팀을 만들어 전환 시점 1년 전부터 아틀라시안과 직접 의사소통하며 전환을 준비했습니다. 하지만. 앞서 잠깐 설명했듯 컨플루언스 서버 또는 컨플루언스 데이터센터 버전과 컨플루언스 클라우드 버전은 이름이 같을 뿐 사실상 다른 소프트웨어입니다. 단순히 글과 그리을 옮기는 정도는 자동화 도구를 사용해 잘 동작했겠지만 매크로와 플러그인은 컨플루언스 클라우드 쪽에 같은 매크로와 같은 플러그인이 있다 하더라도 예상한 모양으로 동작하지 않을 가능성이 높습니다. 또한 컨플루언스 서버 버전은 사용자의 요청에 따라 관리자가 여러 부분을 튜닝해 사용할 수 있었는데 이 경우 서버 버전에서 클라우드 버전으로 전환은 더더욱 어려워집니다. 넷플릭스의 경우 1년에 걸쳐 부드러운 전환을 준비했음에도 마지막 순간까지 예상하지 못한 문제가 발생했습니다. 넷플릭스 정도 되면 거대한 컨플루언스 사이트를 운용하고 이를 이전했을 거라고 생각했지만 넷플릭스의 발표를 보는 청중 중에는 이보다 더 큰 규모의 컨플루언스 사이트를 데이터센터 버전이나 클라우드 버전으로 이전해야 하는 상황에 놓인 사람들도 있었습니다. 컨플루언스 서버 버전의 지원 종료가 얼마 남지 않은 상황에서 여러 회사들이 적어도 데이터센터 버전으로 전환할 거라고 예상했지만 실상은 전환 자체를 포기하는 사례가 늘어났습니다. 일단 서버 버전이 회사 내 환경에서는 어쨌든 동작하고 있으니 인프라를 유지하는 수준에서 당장 문제가 발생하지는 않기 때문입니다. 그래서 여러 회사들이 컨플루언스 서버 라이선스로 따라갈 수 있는 마지막 버전인 컨플루언스 8.5에 머물렀습니다.

하지만 언제까지 이 상태에 머물 수는 없습니다. 정보시스템의 핵심 고객인 직원들은 회사 밖에서 현대적인 도구를 익숙하게 사용하고 있습니다. 이 말은 이들이 회사 밖에서 더 생산성 높은 도구를 사용하다가 회사 안에서는 생산성이 충분히 높지 않은 도구를 사용하게 된다는 의미입니다. 물론 이를 모른체 하고 몇 년 더 버틸 수 있겠지만 이 역시 영원할 수는 없습니다. 언젠가는 컨플루언스 데이터센터 버전이나 클라우드 버전으로 전환하거나 아예 다른 도구로 전환할 결정을 해야만 합니다. 만약 컨플루언스 데이터센터 버전과 클라우드 버전이 서로 크게 다르지 않았다면 이 의사결정은 거의 아틀라시안과 새로운 라이선스 계약을 체결하는 것으로 연결되었겠지만 컨플루언스 클라우드가 이전과는 완전히 다른 현대적인 도구로 바뀌면서 기존 컨플루언스 서버 고객들은 컨플루언스 클라우드와 별로 다르지 않은 현대적인 경쟁 도구를 살펴보지 않을 수 없었을 겁니다. 그러니까 컨플루언스 클라우드의 현대적인 측면은 노션의 그것과 아주 비슷합니다.

노션이 컨플루언스로부터 이전 기능을 처음 제공하던 시점에는 컨플루언스를 스페이스 단위로 익스포트 한 다음 이를 임포트 하는 방식으로 동작했는데 작은 스페이스나 첨부파일이 적은 텍스트 위주의 스페이스를 옮길 수 있었지만 페이지가 많고 또 대용량 파일이 많은 스페이스를 옮기는 것은 불가능했습니다. 개인적으로 이 시점까지 아직 1만 페이지도 채 되지 않던 스페이스를 노션으로 이전해 보려고 했지만 첨부파일을 제외하고서도 제대로 동작하지 않았습니다. 또한 이전된 페이지들도 앞서 언급한 플러그인, 매크로의 차이로 인해 예상대로 동작하지 않았는데 이를 해결할 방법은 사람이 하나하나 의도와 달리 나타나는 부분을 수정하는 것 뿐입니다. 하지만 시간이 흘러 현대의 Confluence에서 가져오기 기능은 기존 방법도 여전히 제공하지만 특히 컨플루언스 API를 사용해 페이지를 가져오는 방법을 제공합니다. 이전에는 파일을 직접 익스포트 해 옮겨야 했고 파일 크기나 페이지 수에 제한이 있어 편안하게 규모가 큰 스페이스를 옮길 수 없었지만 지금은 그렇지 않아 보입니다. 컨플루언스 APIf를 통해 느긋하게 모든 페이지와 첨부파일을 가져올 수 있어 보입니다 여전히 매크로와 플러그인이 호환되지는 않겠지만 대규모 스페이스를 자동화된 방법으로 가져올 수 있다는 점 자체는 상당한 가능성입니다. 또 매크로나 플러그인이 다양하기는 하지만 회사의 비용 통제 덕분에 아주 많은 종류의 플러그인을 사용하고 있지 않을 가능성이 있습니다. 컨플루언스 플러그인들은 대체로 컨플루언스 자체와 같은 가격 정책을 제시하는 경우가 대부분입니다. 컨플루언스는 사용자 한 명 당 요금이 정해져 있고 사용자 수가 늘어날 수록 한 명 당 요금이 감소하기는 하지만 사용자 수만큼 요금을 지불해야 합니다. 플러그인도 마찬가지인데 사용자 한 명 당 한 달에 1달러짜리 플러그인이라도 사용자가 1만명이면 이론적으로 1만 달러를 지출해야 합니다. 때문에 어지간히 미션 크리티컬한 기능을 수행하지 않는다면 회사가 플러그인을 구입하는 결정을 하기는 정말 어렵습니다. 그래서 오히려 제한적인 플러그인 사용으로 마이그레이션 과정을 커스터마이징 해 사람이 직접 예상과 달리 동작한 결과를 수정할 일을 줄일 수 있을지도 모릅니다.

어느 정도 규모가 있는 조직이 컨플루언스를 노션으로 전환한 사례 중 인터넷에 공개된 것들을 살펴보면 기존 파일 익스포트 방식으로는 4500 페이지, 10기가 첨부파일 정도를 이전하는 과정에 별도로 개발한 자동화 도구를 통해 페이지를 전환해 오고 또 이를 검증했습니다. 페이지 전환과 검증을 자동화 한 것은 넷플릭스의 전환 사례에서도 언급되는데 당시 아틀라시안이 컨플루언스 클라우드로 전환을 위해 제공한 도구가 충분한 기능을 제공하지 않아 아틀라시안에 계속해서 피드백 해 기능을 개선했습니다. 그런데 노션으로 전환할 경우 이런 도움을 받을 수 없으므로 전환과 검증을 자동화할 방법을 조직 내에서 직접 개발하거나 사용자들 각각의 인력을 동원해 마이그레이션을 완료하는 방법을 검토할 여지도 있습니다. 사실 이전에 사용해 본 프로젝트 컨플루언스 사이트는 아무리 규모가 작아도 고작 몇 천 페이지, 두 자릿수 기가 정도의 작은 사이트는 없었습니다. 제 개인 컨플루언스 사이트 조차 다섯 자리 페이지, 수 테라바이트에 달하는 파일로 구성됩니다. 사실상 파일을 익스포트 해 노션에 임포트 하는 방식으로 전환은 불가능해 보입니다. 하지만 컨플루언스 API를 통해 마이그레이션 하는 방식은 아마도 대규모 스페이스도 전환 시간을 감내할 수 있다면 안정적으로 가져올 수 있을 것으로 보입니다. 그래서 컨플루언스 서버를 노션으로 이전할 때 스페이스 규모가 크더라도 이는 현대에 문제가 되지 않을 겁니다.

기술적인 고려사항 외에 기존 컨플루언스 사용자들이 노션을 사용하기 시작하면서 겪게 될 수 있는 경험의 문제도 고려해야 합니다. 기본적으로 노션은 지극히 현대적인 도구로 시작했습니다. 이모지로 페이지 곳곳을 꾸미는 현상 역시 거의 노션으로부터 시작했다고 생각합니다. 또 기업용 위키 중 페이지 좌우 폭을 제한해 페이지가 가지런히 보이도록 만든 것 역시 노션이 거의 처음으로 이렇게 한 도구 중 하나일 겁니다. 결국 컨플루언스 클라우드도 이렇게 바뀌었습니다. 이 과정에서 혹실히 사용 경험 개선을 기대할 수 있습니다. 또 컨플루언스에 비해 모바일 사용성이 압도적으로 좋아 회사가 보안 위험을 감수하고 모바일 사용을 허용한다면 어디서나 정보시스템에 접근할 수 있다는 장점도 있습니다. 또 노션이 처음으로 도입한 데이터베이스 기능은 이제 컨플루언스 클라우드에도 완전히 똑같은 기능이 있기는 하지만 노션 쪽이 더 확장성 있고 다양한 사용 사례를 지원하기 때문에 노션 쪽이 더 경쟁력 있습니다. 다만 데이터베이스를 노션에서 초기에 주장하던 대로 프로젝트 관리에 사용하려 한다면 상당한 시행착오를 거쳐야 할 거라고 예상합니다. 컨플루언스 클라우드의 데이터베이스에서는 같은 문제가 발생하지 않는데 이유는 그냥 같은 회사에서 나온 제품인 지라를 사용하면 되기 때문입니다. 물론 노션에서도 지라를 연동해 사용할 수 있지만 컨플루언스에서 하던 것에 비해 상대적으로 느리고 정보가 즉시 적용되지 않는 때가 있었습니다. 만약 데이터베이스만으로 프로젝트를 관리하려 한다면 컨플루언스를 노션으로 이전하는데 드는 비용만큼이나 지라를 노션 데이터베이스로 교체하는데도 비용을 투입해야만 할 겁니다.

컨플루언스를 노션으로 전환하며 지적된 대표적 단점에는 학습 곡선이 가파르다는 점이 있습니다. 사실 노션을 이전에 사용하던 컨플루언스의 약간 제한적인 기능에 맞춰 사용한다면 큰 어려움은 없을 거라고 예상합니다. 하지만 컨플루언스에서 했던 것처럼 매크로와 플러그인 등을 사용해 대시보드를 만들거나 리포트 페이지를 만들려 한다면 같은 결과를 만들어내기 위해 노션에서 완전히 다른 방법을 습득하는데 분명 시간이 걸릴 겁니다. 하지만 이는 완전히 다른 작업을 한다기 보다는 비슷한 결과를 만들어내기 위한 다른 방법을 탐색하는 과정에 불과하므로 학습 곡선 문제는 그리 크지 않을 거라고 예상합니다. 또 현대에는 노션 역시 플러그인을 지원하지만 먼 옛날부터 이를 제공한 컨플루언스만큼의 확장성을 보이지는 않습니다. 이는 노션의 문제라기 보다는 노션의 플러그인 개발 환경이 더 늦게 도입되었기 때문에 일어나는 어쩔 수 없는 현상입니다. 이는 시간이 지나면 조금씩 해결될 겁니다. 컨플루언스라고 해서 이런 문제로부터 자유롭지는 않은데 컨플루언스 서버 버전이 오랜 세월 유지되면서 이를 지원하는 플러그인이 많지만 컨플루언스 클라우드나 데이터센터를 지원하는 플러그인은 상대적으로 적습니다. 그래서 플러그인을 통한 확장성 부족은 노션만의 문제라고 보기는 어렵습니다. 또한 앞서 잠깐 이야기한 것처럼 회사의 비용 통제에 따라 사용 중인 플러그인이 그리 다양하지 않을 가능성이 높을 거라고 예상합니다. 때문에 플러그인에 인한 단점은 그리 크지 않을 것입니다.

또 인터넷을 통해 찾아볼 수 있는 단점에는 문서의 모든 버전을 보관하지 않는다는 점이 지적되었는데 이는 엔터프라이즈 버전을 사용하지 않기 때문에 일어납니다. 노션은 이전 30일 동안의 버전을 유지해 줍니다. 사실 그보다 더 먼 과거 버전은 거의 찾아보지 않는 것이 사실이기에 이 특징이 단점이라고 말하기는 조금 어렵긴 합니다. 컨플루언스가 모든 버전을 보관하며 여기에 상당한 자원을 투입하고 있을텐데 개인적으로 컨플루언스를 사용하면서 이전 모든 버전을 보관하는 기능 덕분에 위기를 모면하는 일이 1년에 한 두번 꼴로 일어나기는 합니다. 하지만 노션도 엔터프라이즈 서브스크립션을 계약하면 이전 모든 버전을 저장합니다. 오히려 버전 관리 측면에서 걱정할 점은 읽기 모드와 쓰기 모드를 구분하지 않는 노션의 특징 때문에 구글 문서도구와 비슷하게 버전을 구분할 시점과 버전을 구분할 사용자가 명혹하지 않다는 점에 있습니다. 이런 차이는 노션으로 전환하기 전에 충분히 검토하고 교육해야 합니다.

노션을 사용한다고 알려진 기업들 상당수는 스타트업들인데 가장 큰 이유는 일정 수준 이상의 규모를 안정적으로 지원하는 비슷한 도구 중 비용이 가장 낮은 편에 속하기 때문일 거라고 예상합니다. 또 다른 이유에는 현대적인 사용 경험을 제공하기 때문에 스타트업에서 일할 것으로 예상되는 사람들의 취향에 맞기 때문인 것도 있을 겁니다. Y Combinator가 지원하는 회사 중 절반에 가까운 곳들이 노션을 사용하는 것을 보면 이런 경향을 예상할 수 있습니다. 한동안 노션은 사용자 증가에 따라 속도가 급격히 느려지는 문제를 겪었습니다. 읽기 모드와 쓰기 모드를 구분하지 않기 때문에 블록 단위로 문서를 편집하는 기능은 반 강제적으로 도입할 수밖에 없었을 것입니다. 그런데 이러한 블록 단위의 편집 기능을 사용할 때 노션이 느리게 동작하면 수정한 블록이 이전 상태로 돌아가거나 문서를 스크롤 할 때 때맞춰 블록들이 로딩되지 않아 스크롤 하다 말고 한참을 기다려야 하며 특히 미디어 파일의 로딩이 느려 텍스트 사이에 빈 공간이 나타나기도 하는 문제가 있었습니다. 이는 노션이 선택한 기술 스택의 한계를 넘는 문제로 이어졌는데 현재는 기술 스택을 변경해 문제를 완화했다고 하니 이전에 사용할 때만큼 끔찍하게 느리지는 않을 거라고 기대합니다.

인공지능 기능이 노션의 장점일지는 잘 모르겠습니다. 컨플루언스에서 아틀라시안 인텔리전스를 사용하며 느낀 점은 아틀라시안이나 노션처럼 인공지능 기능을 스스로 수직계열호 하지 않은 회사들의 제품에는 한계가 있을 수밖에 없다는 것입니다. 가령 컨플루언스 클라우드는 아틀라시안 인텔리전스를 통해 단일 페이지 요약, 다시 쓰기, 번역, 다시 정리하기, 문서 내용에 기초한 질문과 대답을 잘 수행해 냅니다. 하지만 아틀라시안이 주장했던 여러 페이지나 심지어 스페이스 전체에 걸친 문서에 기반한 ‘버추얼 팀메이트’ 기능은 아직까지 예상한 대로 동작하지 않습니다. 어떤 질문에는 스페이스 전체에 걸친 학습이 동작하는 것처럼 보이지만 또 다른 질문에는 아예 답변을 생성하는데 실패하기도 합니다. 이런 일관적이지 않은 사용 경험은 근본적으로 인공지능 개발과 인프라 유지 기능을 회사에 수직계열화 하기 어려운 회사들의 한계로부터 기인한다고 생각합니다. 비슷한 사례에는 오랜 세월에 걸쳐 멍청한 시리를 개선하는데 실패해 온 애플도 있는데 그나마 이들은 최근 인공지능 개발을 수직계열화 해 제품에 적용하려고 하는 대신 외부 인공지능 회사와 계약하는 방식으로 문제를 해결하고 있습니다. 이전 시대의 노션은 방금 서령한 아틀라시안 인텔리전스 수준의 빈약한 인공지능 기능을 제공했지만 현대에는 개선되었을는지도 모릅니다. 하지만 노션 역시 인공지능 개발을 수직 계열화 하기 어려운 입장일 거라는 점을 감안하면 인공지능 기능으로붜 큰 도움을 받을 수 있을 거라고는 예상하지 않는 편이 좋다고 생각합니다.

개인적으로 컨플루언스 클라우드 버전을 대단히 만족스럽게 보조 두뇌로 사용하고 있을 뿐 아니라 이전에 경험한 여러 프로젝트에서 조금 부족한 컨플루언스 서버 버전을 사용해 온 입장에서 아틀라시안의 제품 라인업 변경으로 인해 다른 도구로 전환이 종종 일어나는 모습을 보면 조금 아쉽습니다. 하지만 이런 일이 일어나게 만든 근본적인 원인은 아틀라시안 스스로가 제공했기에 부란을 가질 여지는 없스니다. 한편 아틀라시안 입장에서도 커스터마이징 여지가 많아 안정적인 유지보수가 너무나 어려워진 서버 버전을 아예 선셋팅하고 데이터센터 버전으로 넘어가고 또 현대적인 요구사항을 급격히 받아들여 기존 사용자들을 당황시키거나 화나게 만드는 대신 별도의 클라우드 버전을 개발해야만 했을 이유 역시 이해하지 못하는 것은 아닙니다. 어쨌든 컨플루언스를 노션으로 이전한다면 마이그레이션 과정의 자동화, 각 페이지에 사용된 매크로와 플러그인의 안전한 전환, 대규모 페이지와 첨부파일 이전에 따른 다운타임 고려가 선행되어야 합니다. 또 개인적으로는 그러지 않기를 바라지만 기존 지라를 노션 데이터베이스로 대체할 결정을 한다면 지라의 핵심 기능인 워크플로우와 커스텀 필드라는 점을 충분히 고려해 이를 대체할 인프라를 수직계열화 할 수 있는지, 혹은 이를 수행할 솔루션을 준비했는지 확인할 필요가 있습니다. 또 컨플루언스 서버에 비해 상대적으로 자유로운 페이지 작성 기능 덕분에 한동안은 정보가 체계적으로 기록되지 않을 가능성이 있습니다. 이를 예상한 교육이 선행되어야 할 수 있음을 감안해야 합니다.

현대적인 도구들이 보안 위협에 꽤 잘 대응하고 있음을 알고 있지만 컨플루언스에 비해 상대적으로 약한 감시 기능은 조금 걱정입니다. 또 비공개 스페이스 중 일부 페이지를 선택적으로 공개할 수 있는 기능은 페이지를 공개하려는 유저 입장에서는 편리하겠지만 스페이스 단위로 권한을 조정하고 관리해야 하는 입장에서는 상당히 골아픈 문제가 될 수 있습니다. 공개 여부를 스페이스 단위로만 설정할 수 있는 컨플루언스에서도 의도하지 않은 공개 사고가 종종 일어나는 것으로 미루어 페이지 단위로 공개 여부를 설정하는 기능은 의도하지 않은 보안 사고를 일으킬 가능성이 있습니다. 또 컨플루언스는 한동안 컴플라이언스에 대응하는데 굉장한 자원을 투입했습니다. 거의 2년에 걸쳐 기능 추가와 개선은 줄어들고 컴플라이언스 대응으로 릴리즈노트를 가득 채우곤 했습니다. 반면 노션은 그런 단계가 있었는지 잘 모르겠습니다. 최소한의 데이터 암호화나 데이터 레지던시, 감사 기능이 상대적으로 빈약할 거라는 점은 기존 대규모 컨플루언스 사이트를 이전할 때 신경 쓰이는 점입니다.

이런 변화와 관계 없이 지난 5년 이상 사용해 온 컨플루언스 클라우드를 제 보조 두뇌로 계속해서 사용할 겁니다. 반면 개인 영역 바깥에서 노션을 적극적으로 사용할 기회가 생긴다면 두 도구를 사용하며 서로의 장단점, 특징을 살펴볼 기회가 될 겁니다. 어느 순간 노션이 명백히 컨플루언스에 비해 더 뛰어나 보인다면 그 즈음에는 오랜 세월에 걸쳐 보조 두뇌로 활용하는 도구를 변경할 가능성도 있습니다. 또 대규모 조직이 노션을 활용하는 사례를 지속적으로 관찰할 겁니다. 가령 국내에는 GS그룹이 노션을 대규모로 도입해 폭넓게 사용하고 있다고 알려져 있습니다. 또 최근 아틀라시안은 윌리엄스 레이싱 팀과 파트너십을 체결했는데 이 윌리엄스 팀은 암흑기 내내 엑셀 파일을 사용해 레이스카 개발과 제작을 관리해 왔고 이로 인해 온갖 문제를 겪어 왔다고 알려졌습니다. 아틀라시안이 타이틀 파트너십을 체결하며 아틀라시안 제품을 통해 이런 상태를 개선하는데 도움을 주고 있다고 알려져 있으며 타이틀 스폰서 계약을 체결한 김에 제품 뿐 아니라 컨설팅을 함께 제공하고 있을 가능성이 있습니다. 때문에 컨플루언스를 큰 규모로 사용하는 조직의 사례로 윌리엄스 레이싱을 지켜봐야 합니다.

어떤 도구도 결코 영원하지 않습니다. 컨플루언스에서 노션으로 전환하는 사례들을 살펴보며 개인적인 수준에서 도구의 변화를 지켜보는 과정 속에서 이번에는 주로 노션으로 전환하는 기업들의 시행착오들을 살펴봈습니다. 분명 간단한 문제는 아니지만 또 기대할 점 역시 없지 않습니다. 이런 과정을 앞으로 지켜보는 일은 분명 재미있을 겁니다.