위키에는 파일을 통제할 형상관리도구가 필요하다

제가 직접 프로덕션 코드를 작성하는 역할을 하지 않지만 어쨌든 커다란 소프트웨어를 개발하는 팀에 섞여 일하고 있습니다. 그래서 직접 코드를 작성하는 역할을 하지 않더라도 형상관리도구를 사용하고 또 컨플루언스나 지라 같은 복잡도 높은 업무를 통제 가능한 상태로 만들어 주는 도구를 사용하는데 익숙한 편이라고 생각합니다. 또 개인적으로 위키 모양의 기록 도구가 장기간에 걸친 기록 요구사항의 느린 변화를 같은 시스템을 통해 감당할 수 있는 확장성을 가지고 있다고 생각해 위키 모양의 기록 도구 중 하나인 컨플루언스를 오랜 기간에 걸쳐 개인 기록 도구로 사용하고 있습니다. 이 소프트웨어 각각의 역할은 명확합니다. 형상관리도구인 퍼포스는 이 프로젝트의 특징인 코드 외에도 여러 직군이 바이너리 파일을 커밋하는 상황을 처리해 내는 거의 유일한 존재입니다. 코드를 작성하는 사람들은 여기에 코드를 올리지만 직군에 따라 언리얼 데이터 에셋을 올리거나 엑셀 파일을 올리기도 합니다. 또 팀에 따라 컨플루언스 같은 보다 본격적인 웹 기반의 정보시스템을 도입하는 대신 여전히 마이크로소프트 오피스 제품군의 문서 작성 도구를 사용해 요구사항을 관리하기도 하는데 이 경우 문서 역시 형상관리도구의 관리 대상이 되기도 합니다. 프로젝트에 따라 다르지만 여러 직군에 걸친 복잡성을 줄이기 위해 프로덕션 코드, CI에 의해 빌드 된 바이너리, 데이터 에셋, 엑셀 파일, 여기에 요구사항을 기입한 워드 문서나 파워포인트 문서까지 모두 같은 퍼포스 리파지토리의 서로 다른 디렉토리를 통해 관리하곤 합니다. 누군가는 분명 이 상황을 상상하기만 해도 이미 속이 불편함을 느낄 수 있고 저 역시 문서가 위키 모양 대신 워드 모양인 것 자체로 불편함을 느끼기는 하지만 분명 지금 이 순간에도 그렇게 동작하는 프로젝트들이 있습니다.

전에 숏폼 블로그 실험을 소개했습니다. 현대는 오직 영상을 통해 정보를 전달하는 세계이고 이 사실에 완전히 동의하며 제 스스로도 영상을 통해 정보를 얻지만 정작 저 자신은 이제 더 이상 아무도 읽지 않는 텍스트 모양으로 말하고 있을 뿐 아니라 현대에 숏폼 영상에 익숙해진 사람들 관점에서는 거의 책 한권에 다다를 분량에 가까운 글 하나하나를 만들고 있는 이 상황은 분명 큰 문제라고 생각했습니다. 하지만 갑자기 이런 텍스트를 영상으로 만들 수 있을 것 같지는 않았기에 텍스트 포멧을 유지하되 어떤 질문을 가진 사람들에게 기나긴 글을 읽거나 뉴스레터를 구독하기를 요구하는 거의 화성에 깃발을 꽂고 돌아온 분들에게 정보를 전달하겠다는 태도 정도는 조금이라도 개선할 수 있지 않을까 하는 생각을 했습니다. 그래서 뉴스레터와 대부분의 글처럼 긴 글을 만들어 핵심은 기껏해야 몇 줄 되지도 않는 글을 1만자도 넘게 타이핑 해 현대에 얼마 남지 않은 글자를 읽으려고 시도하는 분들을 고통스럽게 만드는 대신 텍스트라도 짧은 모양으로 만들면 도움이 되지 않을까 하는 생각을 했습니다. 그래서 숏폼 블로그 글을 실험하기 시작했습니다. 방문자 정보를 통해 대략 어떤 검색어를 통해 이 블로그가 발견되는지 알고 있었습니다. 하지만 직접 글을 만들었기 때문에 그 내용을 대략 기억하고 있는 제 입장에서 거의 모든 검색어에 의한 유입은 결코 좋은 경험이 아니었으리라 확신합니다. 검색한 누군가는 분명 지금 당장 궁금증에 대한 짧고 정확한 답변을 얻고 싶었을 겁니다. 하지만 구글이 검색 결과에 올려 놓은 이 블로그는 일단 각각의 글이 너무 길 뿐 아니라 그 안에 검색어에 해당하는 정보가 있을지 확실하지도 않습니다. 그래서 검색어를 보고 그 의도를 예측할 수 있다면 의도에 정확히 일치하는 짧은 글을 만들어 보기 시작했습니다.

가령 제가 마스토돈 이야기를 종종 했더니 구글은 ‘마스토돈 아이디 변경’ 같은 검색어를 이 블로그에 유입 시켰는데 분명 그 누구도 이 블로그로부터 원하는 답변을 얻지 못했을 겁니다. 저는 분명 마스토돈의 계정 이동성에 대한 걱정, 마스토돈에서 중요한 것은 오직 소셜그래프 뿐이다에서 마스토돈에 계정 이동성이 거의 없는 것이나 다름 없다는 불만을 토로했지만 이 기나긴 글로부터 마스토돈에 계정 이동이 거의 불가능하다는 결론에 도달하는 정보를 습득하기는 아주 어렵습니다. 하지만 저는 이 검색어의 의도를 예상할 수 있고 또 그 정확한 답도 알고 있습니다. 그래서 마스토돈 아이디 변경이라는 정확히 제목에 해당하는 내용만 있는 짧은 글을 만들었습니다. 이번에는 검색을 통해 이 페이지를 본다면 사실상 불가능하다는 답변에 바로 도달할 수 있습니다. 또 어떤 사람들은 자신이 원하는 정보를 그 정보의 원천을 직접 확인하면 가장 정확한 정보를 습득할 수 있을 것이 분명한데도 굳이 구글 검색 상위에 올라온 엉뚱한 사이트를 전전하기도 하는 것 같습니다. 가령 해피해킹 키보드의 배열을 알고 싶으면 PFU 웹사이트에 가면 첫 화면에 떡하니 키보드 그림이 그려져 있어 즉시 키보드 제조사가 직접 제공하는 가장 정확한 정보를 얻을 수 있습니다. 하지만 이들은 굳이 구글이나 네이버에 검색한 다음 불확실한 정보를 제공하는 엉뚱한 정보제공자들의 웹사이트에서 시간을 보내는 것 같습니다. 이번에도 저는 해피해킹 키보드를 오랜 시간에 걸쳐 사용해 오며 이런 이야기를 블로그 글로 만든 적이 있으므로 검색에 나타난 모양이지만 굳이 키보드 배열을 제공할 이유는 없었습니다. 이건 그냥 이미지 검색을 하거나 PFU 웹사이트에 가면 알 수 있는 정보니까요. 하지만 이런 검색이 너무 많이 나타나자 이번에도 해피해킹 배열이라는 숏폼 글을 만들었습니다. 엉뚱하게 해피해킹 키보드를 사용하는 글로 그저 키보드 배열을 알고 싶은 사람들을 당황스럽게 만드는 대신 키 배열 이미지를 바로 보여주는 페이지를 제시하면 누군가의 검색 경험을 개선할 수 있을 거라고 생각합니다.

예상대로 이 숏폼 글들은 글 각각이 예상한 검색어에 의해 의미 있는 유입을 발생 시키기 시작했습니다. 물론 이를 통해 저는 아무 것도 얻을 수 없습니다. 이렇게 단순한 정보를 원하는 분들은 이 정보를 어떤 웹사이트에서 제공하든 일단 정보를 획득하고 나면 더 이상 웹사이트에 머물지 않기 때문입니다. 하지만 정확히 검색어에 해당하는 정보만을 제공하는 글을 만드는 실험 자체는 재미있었습니다. 한때 구글은 같은 검색어에 대해 더 긴 글로 설명하는 페이지를 검색 결과의 더 위쪽에 올려 준다고 알려져 있었지만 이를 어뷰징 하는 사례가 너무 많고 또 제 스스로도 그 주제에 대해 길게 설명하는 웹사이트보다 정확히 검색어에 해당하는 답변 자체만 제공하는 편이 검색어의 의도에 더 잘 부합한다고 생각합니다. 때문에 구글이 상위에 올려주든 말든 짧은 페이지를 만들었는데 구글이 검색 결과 표시 방법을 바꿨는지 몰라도 이 짧은 페이지들로부터 유입이 일어났고 이 경험은 꽤 재미있었습니다. 다만 이 글들을 블로그 도구인 고스트 규칙에 따라 마음에 드는 모양으로 배치하는 것은 어려운 일이었습니다. 글 각각을 만든 시각을 그대로 사용했더니 숏폼 글들이 메인 화면에 다른 글과 함께 나타나 그렇잖아도 별로 좋지 않은 첫 화면 내비게이션을 심각하게 망가뜨렸습니다 .그렇다고 이 글들을 목록 모양으로 나타나는 포스트가 아닌 페이지로 만들면 목록에 나타나지 않게 할 수는 있었지만 정작 이 글들의 목록을 자동으로 만들 수 없었습니다. 고민 끝에 썩 좋은 방법은 아닐 것 같지만 글을 작성한 날짜 중 연도를 2000년으로 바꿔 첫 페이지 목록 맨 아래 나열되도록 했습니다. 대부분 그럴 일이 없겠지만 첫 페이지 스크롤을 끝까지 내리면 숏폼 글들이 모여 있는데 이들이 여기 있다고 해서 맨 위에 있는 글의 내비게이션을 방해하지는 않을 겁니다.

숏폼 글들은 나머지 글에 비해 훨씬 많은 검색어로부터 접근을 만들어냈지만 숏폼 모양으로 만들지 않은 글 하나의 기록을 넘길 수는 없었습니다. 바로 컨플루언스에 엑셀을 붙여넣는 현실적인 방법입니다. 사실 이 글 역시 숏폼 모양으로 만들지 고민했습니다. 사실 컨플루언스 위키에 엑셀 파일을 첨부하고 이를 예쁜 모양으로 표시하고 동시에 여러 사람이 이를 동시에 편집하는 상황에서도 잘 동작하는 솔루션은 없습니다. 방금 제가 나열한 여러 가지 요구사항의 일부를 달성하는 방법은 여러 가지가 있습니다. 컨플루언스 마켓플레이스에서 비슷한 역할을 하는 플러그인을 구입할 수도 있는데 컨플루언스 페이지 자체는 여러 사람이 동시에 사용하는 상황에 잘 견디지만 그 페이지에 플러그인을 통해 표시된 엑셀 파일은 그렇지 못한 경우가 많습니다. 또 어떤 플러그인은 대체로 잘 동작하지만 한글을 잘 처리하지 못해 문제를 일으키기도 합니다. 저 글에도 결론은 저 방식이 그리 좋지 않은 접근이라는 것이지만 굳이 컨플루언스 페이지 안에 엑셀 스프레드시트를 넣고 동시에 수정하며 파일의 변경사항 역시 기록되기를 원한다면 가장 현실적인 방법은 마이크로소프트 오피스 스위트를 구독하고 온라인 엑셀 상에서 데이터를 편집하도록 만든 다음 이를 임베딩 하는 것입니다. 이 시나리오가 거의 유일하게 엑셀 워크시트 인터페이스를 거의 그대로 사용하면서 동시에 컨플루언스 페이지에 이 워크시트가 거의 그대로 나타나도록 하는 방법입니다. 하지만 이 경우에는 컨플루언스 뿐 아니라 마이크로소프트 오피스 스위트 역시 사용자 수만큼 구매해야 하고 버전이 위키와 원드라이브 상에 분산되므로 관리에 용이하지 않을 수 있습니다. 가령 컨플루언스 페이지를 이전으로 돌려도 엑셀 워크시트는 영향을 받지 않고 또 엑셀 파일의 어떤 버전이 컨플루언스의 어떤 페이지에 해당하는 것인지 알 수 없어 버전 관리가 모호해지는 문제가 있습니다.

그래서 컨플루언스에 엑셀을 붙여넣는 현실적인 방법의 결론으로 엑셀 워크시트를 컨플루언스 페이지에 첨부하는 것은 결코 좋은 방법이 아니니 다른 방법을 모색할 것을 추천했습니다. 만약 컨플루언스 클라우드를 사용한다면 개인적으로 가장 추천하는 방법은 엑셀 워크시트가 아니라 컨플루언스 데이터베이스를 사용하는 것입니다. 컨플루언스 데이터베이스는 엑셀 워크시트와 똑같은 모양은 아니지만 설정에 따라 거의 같은 모양으로 동작합니다. 뿐만 아니라 컨플루언스 페이지와 마찬가지로 여러 사람의 동시 사용 상황에도 문제 없이 동작하고 컨플루언스 페이지 버전과 통합해 동작하지는 않지만 데이터베이스 자체가 통합되어 있어 버전 관리에 유리합니다. 하지만 이런 결론에도 불구하고 익숙한 방법을 벗어나 생소한 기능과 생소한 인터페이스를 만져보는 결정을 내리기는 어려운 법입니다. 지금까지 제가 확인할 수 있는 검색어 기록으로 미루어 여전히 많은 사람들이 컨플루언스 페이지에 엑셀 파일을 임베딩 하고 실시간으로 수정할 방법을 찾고 있을 뿐 컨플루언스 클라우드의 데이터베이스를 사용할 방법을 찾고 있는 것 같아 보이지 않습니다. 이해할 수 있고 또 당연하기도 합니다. 저 자신을 포함해 거의 모든 사람들은 익숙한 사용 방법과 습관을 잘 바꾸려 하지 않습니다. 또 한 번 익숙해진 방법을 이 방법이 최적이든 아니든 관계 없이 여러 가지 서로 다른 경우에 함부로 대입하려 하는 것 역시 마찬가지입니다. 저 글에서 컨플루언스 데이터베이스를 추천한 결론은 이 페이지를 검색하는 사람들의 기대에 부응하지 못했습니다. 그렇다면 어떻게 하면 좋을까요. 만약 현실적인 방법이 아니더라도 컨플루언스 위키가 이런 요구사항을 받아들일 계획이라고 가정하면 어떤 기능을 만드는 것이 사용자들에게 가장 적당한 방법일까요.

개인적으로 가능성이 있다고 생각하는 방법은 컨플루언스에서 그림 그리는 도구로 널리 사용되는 draw.io가 사용하는 방식이라고 생각합니다. 저 역시 컨플루언스 클라우드에서 이 도구를 사용해 그림을 그리곤 하는데 이 도구는 온라인에서 독립적으로 동작하기도 하지만 컨플루언스 클라우드의 플러그인 모양으로도 동작합니다. 컨플루언스 클라우드에서 동작할 때는 웹사이트 상에서 그림을 그린 다음 이를 저장하면 컨플루언스 페이지에 파일을 첨부합니다. 이후 이 드로잉을 수정할 때마다 컨플루언스 페이지의 첨부파일 버전이 변경되고 컨플루언스 페이지에는 첨부파일의 새 버전이 임베딩 됩니다. 덕분에 컨플루언스 페이지를 수정하며 드로잉을 수정할 때, 그리고 페이지 수정 없이 드로잉만 수정할 때 양쪽 모두 페이지와 드로잉 각각의 버전이 관리될 뿐 아니라 이들이 합쳐진 상태의 페이지 버전 역시 관리됩니다. 특히 페이지의 이전 버전을 보려 할 때 앞서 설명한 온라인 엑셀을 임베딩했다면 페이지는 이전 버전으로 돌아가더라도 엑셀 파일은 최신 버전으로 표시되어 정합성이 깨진 이상한 페이지를 보게 되지만 draw.io는 파일을 컨플루언스 페이지에 첨부해 버리기 때문에 페이지와 파일의 정합성을 유지한 상태로 이전 버전을 볼 수 있습니다. 모든 작업이 컨플루언스 위키 내에서 일어나므로 외부 계정을 만들 필요도 없고 파일은 컨플루언스 페이지의 첨부파일 모양으로 기록되니 권한 관리, 보안 측면에서도 이점이 있습니다.

하지만 모든 컨플루언스 플러그인이 이런 모양으로 동작하지는 않습니다. 가령 개인적으로 굉장히 좋아하는 Balsamiq Wireframe 역시 컨플루언스 플러그인을 제공하는데 이들 역시 온라인 상에서 와이어프레임을 편집하는 환경을 제공하고 파일을 컨플루언스 페이지에 첨부파일 모양으로 기록하기는 하지만 모든 기능을 컨플루언스 안에서 실행하지는 않습니다. 가령 페이지를 볼 때 페이지에 임베딩 된 와이어프레임의 섬네일 등은 플러그인 제작사의 웹서버를 통해 가져오게 되는데 이렇게 개발한 이유를 모르지는 않지만 항상 외부 자원에 의존해야만 하기에 권한 관리와 보안 상 결함이 있습니다. 또한 이 서비스가 아틀라시안과 같거나 더 긴 기간에 걸쳐 서비스를 계속한다면 모르겠지만 어느 날 아틀라시안보다 먼저 서비스를 종료한다면 페이지에 섬네일이 모두 깨져 보일 위험성도 있습니다. 이는 마치 온라인 엑셀을 컨플루언스 페이지에 임베딩 한 상태와 비슷합니다. 물론 마이크로소프트 역시 아틀라시안 만큼 오랜 세월에 걸쳐 서비스 할 것은 분명하지만 지금과 서비스 형태가 변경된다면 컨플루언스 페이지에 의도하지 않은 영향을 줄 수 있습니다. 또한 이런 영향이 컨플루언스 사용자와 관리자가 이 사실을 모르는 상태로 일어난다는 점은 별로 유쾌한 동작이 아닙니다. 그래서 엑셀, 드로잉 등 컨플루언스 페이지에 포함되는 요소에 대한 접근은 외부 자원을 임베딩 하는 모양 보다는 앱만 온라인에서 구동하고 그 결과물은 계속해서 컨플루언스 페이지의 첨부파일 모양으로 기록하는 것이 현실적으로 가장 적절한 방법이라고 생각합니다.

그럼에도 불구하고 아직 근본적인 문제가 해결되지 않았습니다. 개인적으로는 컨플루언스 페이지에 스프레드시트 모양의 데이터를 포함하고 싶다면 엑셀 보다는 컨플루언스 데이터베이스를 사용할 것을 강력히 추천하지만 이 주장이 받아들여지지 않으리라는 사실을 잘 알고 있습니다. 사람들은 그저 엑셀 파일을 컨플루언스 페이지에 첨부한 다음 이 파일에 근거해 컨플루언스 페이지에 스프레드시트를 직접 표시하고 여기서 수정하면 다시 컨플루언스 페이지의 첨부파일이 수정되기를 원합니다. 이해합니다. 하지만 여전히 이 요구사항을 완벽히 모두 지원할 적당한 방법은 없어 보입니다. 그렇다면 이 상황에 접근할 그나마 가장 현실적이고 또 사용자들의 본질적인 요구사항을 해결하는 접근 방법은 무엇일까요. 저는 조직이 소프트웨어를 개발하는 조직이 아니어서 형상관리도구를 사용할 필요가 없다 하더라도 컨플루언스 위키와 함께 여러 파일을 관리할 별도의 형상관리도구가 필요하다고 생각합니다. 깃이나 퍼포스는 소프트웨어를 개발하는 조직, 그것도 어느 정도 규모가 큰 조직에서 사용한다고 알려져 있습니다. 또 대체로 그렇게 행동합니다. 소프트웨어를 개발하는 일을 하지 않는 조직들은 여전히 공유디렉토리에 엑셀 파일을 올려 놓고 여러 사람이 수정하게 만들기도 하고 그나마 좀 더 나은 경우에는 마이크로소프트 오피스 스위트를 구입해 온라인에서 파일을 편집하도록 하기도 합니다. 엑셀 스스로도 파일이 공유디렉토리 상에 있을 때 여러 사람에 의한 동시 편집을 지원하고 또 워드는 자기 스스로 버전 관리와 버전 사이에 비교, 병합 기능을 제공합니다. 하지만 이것 만으로는 부족합니다. 더 범용적이고 더 안전한 방법으로 버전을 관리해야 합니다.

이런 이유로 개인적으로는 소프트웨어를 개발하는 조직이 아니더라도, 또 정보시스템으로 컨플루언스 위키만을 사용하더라도 조직에서 생산되는 여러 파일을 관리하기 위한 별도의 형상관리도구가 필요하다고 생각합니다. 컨플루언스 위키는 첨부파일 기능이 있고 파일 이름 기반으로 버전을 관리하는 기능이 있기는 합니다. 같은 파일을 수정한 다음 또 올리면 이전 파일을 덮어 쓰는 대신 새 버전을 생성하고 이전 버전에도 여전히 접근할 수 있습니다. 하지만 사람들이 컨플루언스 페이지에 엑셀 파일을 임베딩 할 방법을 계속해서 찾는 이유는 엑셀 파일을 수정한 다음 이를 다시 컨플루언스 페이지에 첨부하는 과정이 굉장히 귀찮고 복잡하며 사고를 일으킬 가능성이 높기 때문입니다. 작업을 시작하기 전에 항상 컨플루언스 페이지로부터 최신 버전의 파일을 직접 다운로드 해야 하고 파일을 수정한 다음에도 다시 같은 위치에 업로드 해야 합니다. 이 사이에 다른 사람이 파일을 수정했더라도 충돌 여부를 알 수 없으며 내 스스로가 최신 버전이 아닌 파일을 편집한 다음 올리더라도 이를 막거나 이 사실을 인지할 방법이 없습니다. 때문에 컨플루언스 페이지에 엑셀 파일을 ‘첨부’하는 방법이 아니라 ‘임베딩’하는 방법을 찾는 사람들에게 컨플루언스 페이지의 파일 첨부 기능은 요구사항을 만족하지 못하는 방법입니다.

반면 형상관리도구는 이를 당연하게 사용하는 조직에서 지금까지 설명한 온갖 문제를 일으키지 않는 그 동작 그대로 이 모든 문제 시나리오를 해결합니다. 컨플루언스 페이지에는 컨플루언스 상에서 편집할 수 있는 데이터에 한해 동시 작업과 버전 관리 기능을 수행합니다. 컨플루언스가 직접 지원하지 않는 엑셀 파일 같은 외부 파일은 형상관리도구를 사용해 편집합니다. 소프트웨어를 개발하지 않는 조직에서 시작하기 적당한 형상관리도구는 SVN이라고 보는데 윈도우 탐색기 인터페이스에 쉽게 통합할 수 있고 서버 구축 역시 단순하며 여전히 깃에 비해 바이너리 파일이나 크기가 큰 파일을 잘 다룰 뿐 아니라 무료로 사용할 수 있기 때문입니다. 컨플루언스 페이지에는 엑셀 파일이 존재하는 형상관리도구 상의 위치만 표시하고 나머지는 각자의 로컬에 있는 엑셀 파일을 보고 편집하는 방식으로 작업합니다. 일단 형상관리도구가 파일을 관리하는 이상 내가 최신 파일을 가지고 있는지, 내가 커밋하기 전에 다른 사람이 먼저 커밋하지 않았는지 같은 동시 작업 상황에서 일어나는 여러 가지 기초적인 문제를 해결할 수 있습니다.

이렇게 주장하면서도 과연 소프트웨어를 개발하지 않는 조직에서 파일 모양의 산출물을 관리하기 위해 형상관리도구를 도입해야 한다는 주장이 받아들여질 가능성이 있는지 고민해보게 됩니다. 사실 이보다 더 좋은 방법도 있기 때문입니다. 가령 드랍박스는 형상관리도구 역할을 대신할 수 있지만 겉으로는 완벽히 아무 외부 유틸리티도 사용하지 않는 모양으로 동작하며 최신 파일을 가지고 있는지 알 수 있기 이전에 그냥 최신 버전의 파일을 이미 다운로드 해 놓은 상태일 겁니다. 또 내가 파일을 수정하면 나보다 먼저 파일을 올린 사람이 있는지 확인하거나 파일을 커밋하는 귀찮은 절차 대신 뒤에서 조용히 파일을 서버에 올리고 이를 다른 사람들의 로컬에 동기화 할 겁니다. 그런데 만약 소프트웨어를 개발하지 않는 규모가 아주 크지 않고 비용에 제약이 있는 조직에서 이 중 어느 한 가지 방법을 선택해야만 하는 상황이라면 드랍박스 비즈니스 섭스크립션을 도입해 매월 비용을 지불하는 모양 보다는 형상관리도구를 사용하는 쪽이 더 명시적이고 비용 효율적인 방법이 아닐까 생각해봤습니다.

사실 여기까지 주장하면서 조금 자신이 없어졌습니다. 여전히 가장 이상적인 방법은 마치 draw.io가 컨플루언스 위키 상에서 동작하는 것처럼 컨플루언스 페이지 상에서 파일을 직접 편집하고 그 결과를 즉시 컨플루언스 페이지 첨부파일의 새 버전 모양으로 업데이트 하는 것이기 때문입니다. 하지만 이 시나리오를 온전히 달성하는 제품이 없거나 거의 없다면 외부에서 파일을 관리할 방법을 찾아야 하고 비용 효율적이고 안전한 방법은 형상관리도구를 사용하는 것이 아닐까 하는 결론에 도달했습니다.