위키에 구조화된 데이터 요구사항에 대한 컨플루언스 데이터베이스와 노션 데이터베이스

개인 위키로 컨플루언스 추천해요 (2024)에서 컨플루언스를 개인 위키로 사용하기 시작하기 전 마지막으로 사용하던 위키가 도쿠위키였다고 소개한 적 있습니다. 도쿠위키는 여러 모로 만족스러웠고 특히 직접 VPS 서비스에 설치해 사용하는 입장에서 파일시스템에만 의존하는 점이 편리하고 또 견고하게 동작하도록 만들었습니다. 애초에 위키는 주로 텍스트를 기록하는 용도로 만들어졌고 여기에 미디어 파일을 포함할 수 있는 모양으로 발전했습니다. 그렇다 보니 위키는 데이터 관점에서 비정형 데이터를 주로 다루는 도구라고 봐야 할 겁니다. 그래서 도쿠위키처럼 데이터베이스를 사용하지 않고 오로지 파일시스템만을 사용하더라도 일상적인 사용에 성능 문제가 일어나지 않았습니다. 또 데이터베이스가 특히 잘 한다고 알려진 검색을 위한 인덱싱이나 빠른 페이지 조회를 위한 캐싱도 데이터가 변경되지 않는 한 미리 만들어 둔 캐시 파일로 빨리 처리할 수 있어 데이터베이스를 사용하지 않는 점이 딱히 단점으로 다가온 적이 없었습니다. 다만 위키를 계속해서 사용하며 이 도구에 일상적으로 기록하는 텍스트와 미디어 말고 여러 페이지로부터 불러 사용할 수 있는 중앙화된 데이터, 또 구조화된 데이터가 있으면 어떨까 하는 생각이 들기 시작했습니다.

가령 게임 만드는 팀에서 요구사항을 문서 모양으로 작성한다고 해 봅시다. 개발 초기 단계라면 몰라도 어느 정도 개발이 진행 된 프로젝트라면 게임이 동작하는 근거로 삼을 여러 데이터가 있을 겁니다. 문서를 작성할 때 이 데이터들이 런타임에 어떻게 동작하는지 설명할 때 문서를 작성하는 시점의 데이터를 예로 들어 설명할 수 있습니다. 그런데 데이터를 문서로 가져오면 이 데이터는 그 시점에 일종의 스냅샷이 됩니다. 문서를 작성하고 나서 시간이 흐르면 데이터 값이 수정되거나 데이터 형태가 바뀌거나 아예 데이터가 사라질 수도 있습니다. 하지만 문서를 작성할 시점의 스냅샷으로 문서에 포함된 데이터는 그 이후 실제 데이터의 변화를 반영하지 않습니다. 여느 프로젝트마다 구조화된 데이터 뿐 아니라 특정 도메인에 포함하기 모호한 구조화 하기 좀 난처한 데이터들을 모아 두는 키밸류 데이터가 있었는데 가끔 문서를 작성할 때 이런 데이터와 연결해 문서를 작성하면 이후 데이터 변경에도 대응하고 또 데이터가 변경될 때 이 사실을 문서에 반영해야 함을 감지할 수도 있지 않을까 하는 생각을 해본 적이 있습니다. 하지만 여러 소프트웨어들이 잘 연동되어 동작하는 마이크로소프트 오피스 스위트나 상대적으로 규모가 큰 팀에서 주로 사용하는 여러 위키 제품 중 그 어느 것도 이런 요구사항을 만족하지 못했습니다.

한편 이전에 참여한 어느 프로젝트 초반에 이전까지 습관적으로 사용해 온 엑셀 대신 구글스프레드시트를 데이터 정의 및 입력 도구로 사용하려고 시도한 적이 있습니다. 구글 스프레드시트는 엑셀에서 일어나는 골아픈 동시 작업 문제를 근본적으로 해결할 가능성이 있습니다. 이 부분에서 의아해 하실 분들이 있으리라는 사실을 이미 잘 알고 있습니다. 이미 엑셀은 오래 전부터 여러 가지 방법으로 온라인 동시 편집을 지원했습니다. 처음에는 네트워크 상의 공유디렉토리에 있는 엑셀 파일을 여러 클라이언트가 동시에 접근해 수정할 수 있었고 이는 셰어포인트로 발전했으며 지금은 원드라이브에 기반해 온라인 상에서 자유롭게 동시 편집 할 수 있습니다. 그런데 이를 기존 게임 데이터 파이프라인에 가져오려고 보면 좀 삐걱거리는 부분이 생깁니다. 일단 엑셀 파일을 어디에 둬야 하는지 정하기 좀 어렵습니다. 원활한 동시 작업을 할 수 있으면서도 최소한의 보안을 유지하려면 그 파일은 인트라넷에 있어야 했습니다. 그런데 인트라넷의 어느 장소에 있는 엑셀 파일은 동시 작업이 가능하기는 했지만 작업하는 각자가 원하는 시점에 형상관리도구에 엑셀 파일을 통합해 빌드에 반영하도록 만들기 어려웠습니다. 가령 제가 데이터를 수정한 다음 제 로컬 환경에서 이를 테스트 하려고 하더라도 같은 시점에 누군가의 편집이 끝나지 않았다면 저는 밸리데이션을 통과하지 못하는 엑셀 파일로 테스트를 시도하게 ㅗ딜 가능성이 큽니다.

여러 프로젝트가 이런 문제를 해결하려고 했습니다. 어느 팀은 엑셀 플러그인을 개발해 엑셀 파일을 저장할 때마다 파일의 데이터와 머지에 필요한 메타데이터를 별도로 저장했습니다. 각자가 로컬에서 데이터를 수정한 다음 형상관리도구에 통합하려 할 때 플러그인은 메타데이터와 텍스트 모양으로 읽기 쉽게 만들어 둔 데이터를 로컬과 형상관리도구 사이에 병합해 새 엑셀 파일을 생성한 다음 이를 빌드에 통합했습니다. 반대로 형상관리도구 상에서 파일이 업데이트 되면 이 플러그인이 개입해 보이지 않는 곳에서 데이터를 병합한 다음 로컬 엑셀 파일에 반영했습니다. 사실 비욘드컴페어 버전 5에 접어들면 엑셀 파일 머지가 이전에 비해 훨씬 편리해져 이런 비용이 많이 드는 아슬아슬한 곡예를 할 필요가 줄어들었습니다. 하지만 엔지니어들이 주로 모인 소프트웨어 개발 조직과 달리 게임 개발 조직은 비엔지니어 직군이 많아 이들 모두에게 매 작업마다 충돌이 일어날 때 머지하도록 교육하기는 어려웠습니다. 결국 엑셀 파일은 그냥 바이너리 덩어리로 가정하고 퍼포스 상에서 익스클루시브 체크아웃 파일 옵션을 설정해 근본적으로 머지가 필요한 상황이 발생하지 않도록 했습니다. 파이프라인 정의는 여러 사람이 동시에 데이터를 수정할 일이 많을 때, 가령 마감 전날이나 업데이트 전날 다른 사람의 작업을 기다리게 만드는 문제를 일으키지만 그런 정신 없는 상황에 익숙하지 않은 충돌이 일어나 이를 해결하도록 하는 것 보다는 나았습니다.

구글 스프레드시트는 어쩌면 이런 문제를 근본적으로 해결할 수 있을는지도 몰랐습니다. 일단 데이터는 근본적으로 온라인에 있고 모든 사람들이 동시에 데이터를 수정할 수 있습니다. 서로 지금 이 순간 파일의 어느 부분을 수정하고 있는지 실시간으로 볼 수 있으므로 서로 다른 사람들의 편집을 방해하지 않으면서 각자의 작업을 이어 갈 수 있습니다. 동시에 편집이 일어나고 병합 역시 동시에 일어나기에 근본적으로 충돌 발생이 억제됩니다. 물론 충돌이 완전히 안 일어나지는 않았지만 동시 작업자들이 다른 사람의 커서에 유의하며 작업한다면 충돌은 사실상 발생하지 않는다고도 말할 수 있습니다. 다만 구글 스프레드시트 역시 이 데이터를 형상관리도구에 근거한 빌드에 통합하기는 좀 까다로웠습니다. 로컬에서 스프레드시트를 편집한다면 작업 완료 시점을 정확히 판단할 수 있습니다. 하지만 온라인에서 누구나, 아무때나 편집할 수 있는 구글 스프레드시트는 언제 편집이 끝나는지 정의하기 어려웠습니다. 물론 아무도 편집하고 있지 않은 때를 감지해 이 상태를 익스포트 해 빌드에 통합할 수는 있었습니다. 하지만 파일을 편집하는 사람들 각각이 자신의 수정사항을 로컬에서 테스트하기를 원했지만 여러 사람이 동시에 작업하는 상황에서는 이전 버전에 자신의 변경사항만 포함하는 스프레드시트 파일을 얻기가 어려웠습니다. 한동안 일정 시간마다 파일을 익스포트 해 형상관리도구에 추가해 빌드에 통합 시켰지만 이는 기술적으로 가능할 뿐 아무도 만족 시키지 못했습니다. 데이터를 편집한 모든 사람들은 자신의 수정사항을 자신의 로컬 머신에서 즉시 테스트 해 보기를 원했습니다. 동시 편집과 실시간 머지는 훌륭했지만 그 이외에는 모두 별로였습니다.

개인 위키에서도 비슷한 일이 일어납니다. 가령 구입한 책 목록을 정리한다든지 지금은 후잉 가계부로 옮기긴 했지만 가계부를 작성한다든지 또 장거리 자전거 이벤트 일정을 데이터 모양으로 정리해 두려면 비정형 데이터를 다루는데 집중하는 위키 말고 뭔가 다른 솔루션이 필요했습니다. 어쩌면 이런 요구사항을 위키로 달성하려고 하는 생각 자체가 잘못된 것인지도 모릅니다. 이런 일을 훨씬 더 잘 하는 독립 서비스가 있고 또 엑셀이나 데이터베이스가 같은 역할을 훨씬 더 편리하게 수행할 수 있을 겁니다. 하지만 제 모든 기록은 위키에 집중되어 있었고 또 구조화된 데이터를 어딘가 위키 밖 솔루션에 기록하더라도 위키에 반영할 수가 없습니다. 외부 데이터를 위키에 반영해 작성하려고 하면 앞서 언급한 데이터를 문서에 포함하려 할 때처럼 스냅샷이 일어납니다. 이후 데이터가 변경되더라도 이를 참조한 문서에는 반영되지 않습니다. 또 이런 데이터가 늘어날수록 현재의 데이터와 문서 사이에 정보가 일치하지 않게 되며 이런 일이 반복되면 문서에 포함된 데이터는 그들의 스냅샷 시점에 관계 없이 신뢰할 수 없는 데이터가 됩니다. 나아가 문서 자체를 신뢰할 수 없게 되기도 하고요. 애초에 이 상황에서 사람이 직접 데이터가 변경될 때마다 문서를 수정한다는 것도 말이 안 됐습니다.

이런 생각을 할 즈음 도쿠위키에는 이미 데이터 플러그인이 있었습니다. 간단한 구조화된 데이터를 만들 수 있었는데 처음에 텍스트 형식으로 초기 데이터를 입력하고 나면 나중에 데이터를 추가할 때는 처음 입력한 데이터 구조에 맞춰 데이터를 입력할 수 있었습니다. 구조화 되어 있기는 하지만 느슨한 모양으로 데이터를 입력할 수 있고 또 이를 위키 페이지에서 불러 사용할 수 있었기에 제 요구사항을 만족하는 듯 싶었지만 문제는 금방 드러났습니다. 스프레드시트는 꽤 괜찮은 간이 데이터베이스입니다. 하지만 엑셀을 실제 데이터베이스 역할로 사용하지 않는 이유는 그 느슨함 덕분에 사용하기는 편하지만 그 느슨함 때문에 데이터의 일관성을 보장하기 어렵기 때문입니다. 숫자만 입력해야 하는 필드에 데이터베이스라면 숫자 이외의 입력을 거절하지만 엑셀은그렇지 않습니다. 일허한 일관성을 보장할 수 없는 순간 이 데이터를 적극적으로 가져와 활용하는데 어려움이 생깁니다. 이런 단점을 해결하기 위해 ‘struct’라는 다른 플러그인이 나타났습니다. 먼저 도쿠위키의 네임스페이스 하위에 데이터베이스를 생성한 다음 데이터구조를 처음부터 정의합니다. 데이터를 직접 입력할 수도 있지만 각각의 레코드를 데이터베이스 네임스페이스 하위에 각각의 페이지로 다뤄 각 페이지를 수정하면 데이터베이스 상의 레코드를 수정하는 방식으로도 동작했습니다. 이는 데이터베이스를 수정한다는 느낌 보다는 이미 만들어져 있는 규격화된 위키 페이지를 수정하는 느낌에 더 가까웠기에 위키를 사용하는 사람 입장에서 더 일관되게 느껴졌습니다.

이 플러그인을 사용하면서 위키에서도 이전의 데이터 플러그인에 비해 좀 더 단단한 모양으로 정의되고 또 데이터 구조에 따라 잘못된 입력을 거절하는 신뢰할 수 있는 데이터를 만들고 이를 참조하는 페이지를 만들 수 있게 됐습니다. 위키 문서를 작성할 때 현재 네임스페이스 범위 안에 있는 데이터베이스에 쿼리한 결과를 인용할 수 있는데 쿼리 결과로 값 하나를 가져온다면 인라인에 바로 나타나게 할 수도 있고 데이터가 여러 개이거나 여러 행으로 구성되어 있다면 그 자리에서 바로 테이블을 만들도록 할 수도 있습니다. 쿼리 결과를 위키 문서에서 참조한다는 부분에서 짐작하셨겠지만 값을 가져와 인용하는 문서로부터 값을 직접 수정할 수는 없습니다. 값을 수정하고 싶으면 데이터베이스 에디터 인터페이스를 사용하거나 앞서 소개한 레코드 별로 할당된 위키 페이지로부터 수정할 수 있습니다. 이 점은 좀 귀찮았지만 데이터베이스를 수정하고 나면 이 데이터베이스를 참조하는 값을 포함한 문서들을 업데이트 할 필요조차 없어진 점은 굉장히 마음에 들었습니다. 여러 행사 일정을 정리하면서 엑셀 대신 도우퀴키와 struct 플러그인을 사용했는데 위키만 가지고도 데이터베이스로부터 값을 가져와 각각의 일정 정보를 한 페이지에 표시하거나 ‘이번 달 행사 일정’, ‘특정 지역의 행사 일정’ 같은 페이지를 간단히 만들 수 있었습니다. 여기에는 어떤 웹 프로그래밍이나 데이터베이스 프로그래밍도 필요하지 않습니다. 그냥 위키 안에서 데이터를 입력하고 위키 확장 문법으로 데이터를 조회하는 것보다 복잡한 그 무엇도 사용할 필요가 없습니다.

한편 도쿠위키에 한계를 느껴 컨플루언스로 옮긴 다음 컨플루언스의 구조화된 데이터 관리 방법이 굉장히 낡았다는데 놀랐습니다. 오픈소스로 개발되는 도쿠위키에 한참 못미쳤습니다. 당시 컨플루언스에는 ‘Page Property’ 익스텐션이 비슷한 기능을 제공했습니다. 미리 약속한 경로 하위에 미리 약속한 방식으로 테이블을 만들고 데이터를 입력해 놓으면 다른 컨플루언스 페이지로부터 데이터를 가져와 표시할 수 있었습니다. 도쿠위키와 비슷해 보이지만 미리 스키마를 지정할 수도 없고 값을 검사할 수도 없었습니다. 지금 와서 생각해 보면 마치 NoSQL 데이터베이스처럼 행동했는데 페이지 단위로 레코드를 작성할 때 다른 페이지에 정의된 값을 빼먹거나 다른 페이지에 없는 값을 새로 추가하더라도 아무런 오류를 일으키지 않았습니다. 다만 외부에서 이 값들을 한 번에 조회하면 서로 일치하지 않는 모든 스키마가 병합된 페이지 모양으로 나타났습니다. 또 특정 조건에 맞는 값만을 조회하려고 할 때ㅑ 서로 일치하지 않는 스키마를 무시한 값을 가져와 표시했는데 엄밀한 데이터베이스가 아닌 환경에서 이 정도 동작은 그냥 원래 그런 것으로 넘어가 줄 만한 수준이라고 생각했지만 스키마를 정의할 수 없는 점은 위키 수준에서 데이터베이스의 일관성, 신뢰성을 유지하기 어렵다는 결론에 다다랐습니다.

한편 이 즈음 노션을 알게 됐습니다. 노션은 제가 노션을 알게 되기 훨씬 전부터 존재했지만 애초에 그 존재 자체를 모르고 있다가 지난 2018년 노션 2.0이 출시되면서 캘린더, 데이터베이스 기능이 추가된 다음에야 알게 되었습니다. 아직 도쿠위키를 사용하던 시점이어서 시험 삼아 살펴본 노션의 데이터베이스 기능은 환상적이었습니다. 데이터베이스를 만들고 스키마를 정의하고 전용 에디터 상에서 값을 입력할 수도 있었습니다. 레코드 각각을 별도의 페이지 모양으로 접근할 수도 있고 다른 노션 페이지로부터 데이터베이스에 쿼리한 결과를 단일 값이나 레코드 집합 등 다양한 모양으로 가져와 표시할 수도 있었습니다. 결정적으로 여전히 조금 느슨하기는 하지만 스키마를 선언할 수 있는 덕분에 데이터의 정합성을 일정 수준 유지할 수도 있어 보였습니다. 특히 이 즈음 포켓몬 데이터베이스를 노션 데이터베이스 기능으로 만들어 노션 페이지를 통해 제공하는 사이트를 봤는데 당시 도쿠위키의 struct 플러그인에 염증을 느끼던 입장에서 제 요구사항에 부합할 뿐 아니라 데이터베이스 관련 기능이 거의 예상한 모양과 일치했습니다. 다만 노션이 혁신적인 개념으로 내세운 읽기 모드와 쓰기 모드를 구분하지 않는 위키 편집 방식은 제 입맛에 맛지는 않았고 결국 노션과 노션 데이터베이스의 존재를 알고 있으면서도 개인 위키를 컨플루언스로 전환했습니다. 그리고 앞서 설명한 대로 컨플루언스의 페이지 프로퍼티 익스텐션의 기능 부족에 후회했습니다.

한편 아틀라시안 제품의 익스텐션을 개발하던 k15t에서 Orderly라는 익스텐션을 개발했습니다. 이 플러그인은 정확히 노션이 제공하는 바로 그 데이터베이스 기능을 컨플루언스에서도 아주 비슷한 모양으로 사용할 수 있게 해 주었습니다. 데이터베이스를 만들고 스키마를 선언하고 전용 에디터로 값을 입력하거나 레코드 단위로 생성된 페이지에서 값을 수정하고 데이터베이스에 쿼리한 결과를 페이지에 인라인 또는 테이블 모양으로 인용할 수 있었습니다. 이 정도면 노션이 딱히 부럽지 않았지만 초반에는 데이터 타입이 제한적이고 또 아무래도 서드파티 도구의 한계 때문인지 컨플루언스에 아주 잘 연동되지는 않는 것 같아 보였습니다. 하지만 지난 2024년 아틀라시안은 이 제품을 인수해 컨플루언스 데이터베이스로 리브랜딩해 런칭했습니다. 고맙게도 그 이전에 작성한 데이터베이스를 모두 마이그레이션 해 새로운 컨플루언스 데이터베이스에 포함해 주기도 했습니다. 이후 컨플루언스 오토메이션 기능이 추가되면서 개인적으로 이제 데이터를 쌓는 과정을 자동화 할 수 있으리라 기대했지만 실망스럽게도 컨플루언스 오토메이션은 런칭 후 상당한 시간이 흐르도록 데이터베이스 관련 아무런 기능을 제공하지 않았습니다. 이 글을 작성하는 2025년 초여름 현재 컨플루언스 오토메이션은 데이터베이스 관련 단 두 가지 기능만 제공합니다. ‘새 데이터베이스가 생성될 때’ 발동되는 트리거와 ‘새 데이터베이스 생성’ 액션 뿐입니다. 사실 노션도 이와 비슷한 수준의 오토메이션을 제공하지만 노션은 데이터베이스 단위가 아니라 레코드 단위로 동작하므로 훨씬 활용 범위가 넓습니다. 솔직히 컨플루언스 오토메이션이 제공하는 데이터베이스 관련 오토메이션은 아무리 생각해도 이 기능을 도대체 어떻게 유용하게 활용할 수 있는지 아직 모르겠습니다.

기능 상 컨플루언스 데이터베이스와 노션 데이터베이스는 2025년 현재 서로 상당히 비슷하게 동작합니다. 각 서비스의 시각 테마를 무시하고 보면 서로를 구분하기 어려울지도 모릅니다. 하지만 컨플루언스는 오토메이션 연동 기능이 존재하기는 하지만 부실하고 또 데이터베이스를 페이지 모양으로 표현할 때 선택할 수 있는 형식이 크게 제한적입니다. 데이터를 쌓을 수는 있지만 이 데이터를 원하는 모양으로 페이지에 포함하기까지는 앞으로도 많은 개발이 필요할 것으로 보입니다. 반면 노션은 데이터베이스에 기반한 레코드 목록이나 갤러리, 캘린더 모양 등 페이지에 표현할 수 있는 방식이 훨씬 다양합니다. 페이지를 생성할 때마다 페이지의 존재를 특정 데이터베이스에 쌓고 이 이벤트를 기준으로 슬랙에 연동하거나 개발 환경에서 특정 액티비티가 발생하면 이를 데이터베이스에 기입하고 데이터베이스에 기반한 페이지를 만들어 개발환경에서 새로 완료된 빌드의 릴리즈노트를 작성하게 만들 수도 있습니다. 게다가 최근에는 형상관리도구 로그를 그냥 보여주는 대신 이를 요약하거나 카테고리 별로 분류해 텍스트를 생성하도록 할 수도 있어 꽤 그럴싸한 릴리즈노트가 데이터베이스에 쌓이고 이를 웹 페이지 형식으로 볼 수 있도록 할 수도 있습니다. 반면 컨플루언스는 기능 상으로 비슷한 수준의 기능을 제공하면서도 이런 사용성이나 확장성 측면에서는 크게 뒤지고 있습니다.

비정형 데이터를 다루는 기능이 제품의 핵심인 위키를 선택하면서 갑자기 구조화된 데이터를 다루는 데이터베이스를 심각하게 고려하는 이유는 위키가 근본적으로 비정형 데이터를 다루는 도구라 하더라도 여기에 정보 자산을 쌓다 보면 반드시 구조화된 모양의 데이터를 기록할 요구가 나타날 수밖에 없으며 이를 비정형 데이터를 다루는 도구와 편리하게 통합 관리할 수 없으면 정보 자산을 관리하는 도구인 위키가 정보 자산을 관리하는데 한계를 드러내며 다른 도구와 잘 통합되지 않는 아슬아슬하고 불편한 상태로 접어들 수밖에 없기 때문입니다. 만약 문서 도구와 개발 환경의 데이터가 좀 더 잘 통합된다면 문서에 인용한 데이터가 변경될 때 문서를 수정할 필요 조차 없을 것입니다. 또 문서에 인용한 새로운 데이터구조가 이미 데이터베이스 상에 만들어져 샘플 데이터에 기반해 바로 개발을 이어가고 또 이후 추가한 데이터가 문서에 바로 표시될 수도 있을 겁니다. 아직 이런 단계에 도달하지 못했고 또 규모가 커질수록 도전적인 개발 파이프라인 변경에 보수적인 업계 속성 상 이런 단계에 도달하기까지는 오랜 세월이 걸릴 겁니다. 이럴 때 핵심 정보시스템으로부터 비정형 데이터 뿐 아니라 구조화된 데이터를 함께 다루고 이들을 원활하게 통합해 사용할 수 있는 환경을 갖추고 있다면 다른 파이프라인을 좀 더 편안하게 시도할 수 있을는지도 모르겠습니다.

노션은 처음부터 훨씬 나은 데이터베이스 기능으로 시작했고 스스로 지라를 개발하지는 않았지만 컨플루언스와 비슷한 수준의 지라 연동 기능을 제공하며 지라 쿼리 결과를 데이터베이스에 기록하고 다시 이를 쿼리하며 오토메이션을 통해 이 기능에 접근하게 해 어떤 면에서는 오히려 같은 아틀라시안이 개발하는 컨플루언스보다 더 나은 활용성을 보이기도 합니다. 반면 컨플루언스는 서드파티 데이터베이스 제품을 인수한 다음 기대보다는 느리게 개발을 이어 가고 있고 컨플루언스 오토메이션이나 아틀라시안 인텔리전스 같은 현대 정보자산 관리 도구에 요구되는 기본적인 기능들과 원활하게 통합되는 모습을 보이고 있지는 못합니다. 이런 이유로 현 시점에 비정형 데이터를 주로 다루는 정보자산 관리 도구와 데이터베이스가 원활하게 통합되는 도구를 선택한다면 노션이 더 나은 선택이라고 생각합니다. 개인적으로는 컨플루언스를 사용하고 또 컨플루언스를 무척 좋아하지만 컨플루언스는 데이터베이스, 오토메이션, 인공지능 기능 라인업을 노션과 비슷한 수준으로 갖추고 있으면서도 이들의 통합 수준은 노션에 비해 훨씬 부족해 보여 데이터베이스를 사용하려고 하는 프로젝트에 권하기는 조금 무리가 있습니다. 물론 아틀라시안이 이 사실을 모르지 않을 테고 장기적으로는 두 제품 모두 비슷한 수준의 기능에 도달하겠지만 지금 당장은 그렇지 않습니다.

위키는 근본적으로 비정형 데이터를 다루는데 집중하는 도구이고 우리들이 작성하는 어지간한 문서는 대부분 이 비정형 데이터에 속합니다. 위키는 이런 데이터를 기록하고 검색을 통해 재발견하고 서로를 연결하고 연결에 의미를 부여하는 방식으로 발전해 왔습니다. 여기에 미디어 처리 기능이 추가되고 동시에 여러 사용자가 접근하는 환경을 받아들여 현재의 모습에 이르렀습니다. 여기에 위키 사용자들은 구조화된 데이터 핸들링, 두 가지 데이터 모두를 아우르는 오토메이션, 그리고 통합된 인공지능 기능을 요구하고 있습니다. 이들 중에서 구조화된 데이터에 집중한다면 지금은 노션이 더 나은 선택입니다.