개요

단일 진실 공급원(SSOT)은 정보 시스템 설계 및 이론중 하나로 정보와 스키마를 오직 하나의 출처에서만 생성 또는 편집하도록 하는 방법론입니다.

단일 출처를 통해 데이터를 생성하고 편집하고 접근하므로 데이터의 정합성을 지키고 잘못된 데이터 유통을 방지하고 모두가 동일한 데이터를 참고하도록 하고 있습니다.

SW 개발과 관련된 직군은 SSOT 라는 용어를 몰랐어도 업무 수행에 필요하므로 알게 모르게 SSOT 를 지켜왔습니다.

예로 DBA 는 다루는 데이터를 저장하는 테이블과 스키마를 정규화하고 참조 무결성을 통해서 데이터의 정합성과 일관성을 지키고 SW 개발자는 소스 코드의 중복으로 인한 여러 문제를 방지하기 위해 소스 코드를 library 로 만들고 이를 repository 를 통해 배포하여 단일 출처에서 데이터와 정보를 유통할 수 있었습니다.

전사적 SSOT

조직에는 다양한 직군의 직원들이 존재하며 업무 특성에 맞게 각자 다른 저작 도구를 사용해서 문서나 콘텐츠를 만들고 별도의 workflow를 따르므로 전사적으로 SSOT 를 지키는 것은 매우 어려운 일입니다.

특히 전통적인 협업 방식인 전용 저작도구(MS Office, HWP, etc..) + Email 방식은 SSOT 에 반하는 최악의 협업 방법으로 의사 소통에 드는 비용을 극대화시키지만 효율은 떨어뜨립니다.

이런 방식의 협업을 할 경우 의도적이거나 또는 실수로 최신 정보가 누락되거나 공유되지 않을 소지가 높아지며 이로 인해 부서간 높은 사일로가 생길 수 있습니다.

업무가 나날이 복잡해지고 리스크가 커지고 있는 최근의 기업 환경에서는 효과적으로 협업하고 의사 소통 과정의 시간과 비용을 줄이고 조직의 사일로 현상을 막기 위해 SSOT 기반의 업무 프로세스 설계가 점점 중요해지고 있습니다.

이때문에 SSOT를 업무 현장에 적용하려는 경우 단일 도구를 사용해서 구현하려는 경우가 많으며 이런 요구 사항에 맞게 All in One Product를 표방하는 여러 제품들이 있습니다.

개인적으로 이런 All in One 제품들을 그리 선호하지 않는데 그 이유는 복잡한 현대의 업무를 하나의 도구로 관리하는 건 불가능에 가깝다고 생각해서입니다.

조직에서 가장 많이 일어나고 중요한 일중에 하나는 문서를 작성하고 이를 공유하고 의견을 수렴하고 반영해서 다시 문서를 갱신하고 배포하는 일입니다.

이런 문서 작성/배포/피드백/갱신은 WIKI 방식을 도입하여 쉽게 구축할 수 있습니다.

여기서 쉽게라는 건 위키 기반의 문서 협업이 어느 정도 체계화되어 있고 좋은 도구가 많기때문에 도입이 기술적으로 쉽다는 의미이며 이를 잘 쓰기 위해서는 직원 재교육, 업무 프로세스 개선, 조직 문화 변경등이 필요하므로 결코 쉬운 일은 아닙니다.

특정 포맷의 콘텐츠 관리

위키 방식으로 문서를 작성하고 배포할 떄 가장 큰 문제는 모든 문서가 위키를 통해서 만들고 관리할 수는 없다는 점입니다.

예로 외부 프로젝트에 제안서를 제출할 경우 일반적으로는 MS의 Power Point 로 작성하게 되며 공공 기관의 경우 HWP 를 사용해야 하므로 위키 시스템에서 작성 및 관리할 수가 없습니다.

이때문에 MS Office 등을 저작 도구로 사용하고 생산한 콘텐츠는 dropbox 나 one drive 같은 공동 저장소에 넣어서 SSOT 를 구현하려는 경우도 많이 있지만 모든 문서를 이런 무거운 도구를 이용할 필요는 없습니다.

더구나 이런 전문 저작 도구를 사용할 경우 Confluence 같은 위키 방식의 장점인 쉽고 간단한 콘텐츠 작성과 공유가 어려워지며 이로 인해 변화에 대응하기 힘들어집니다.

Ref

Browser not supported