| ‘오피스 SW가 갖추어야 할 것?’ 하면 무엇이 있을까?
우선 작업으로 한번 생각해볼까?
수를 기반으로 하는 통계 데이터를 구조화하는 작업
이러한 데이터를 모아서 분석하기 위한 인사이트 추출 작업
추출된 인사이트를 풀어 해석하고 표현하고자 하는 작업
정리된 정보를 전달하고자 하는 작업
위와 같은 과업을 중요하게 생각하는 정보 리터러시가 되려는 일련의 작업들. 다시 기능적 예로 생각해보자.
무언가 통계데이터를 위한 수식과 함수, 참조데이터와 다양한 보기기준과 관점을 바탕으로한 변환 및 순환참조. 정리 정돈 가능하지만 순차적 혹은 정리정돈 된 데이터를 공통의 성격으로 나누어 배열해보는 표 작업. 공통기준이 아닌 계층적, 순차적 기준에 의해 줄과 문단 그리고 페이지를 구분하여 속성과 스타일로 계층적으로 배열해볼 수 있는 작업.
생각의 논리를 단순 도형, 순서도, 분기로 표현하는 작업. 행과 열의 매치를 통해 논리를 재구성해보는 작업. 꼬리에 꼬리를 무는 논리의 마인드매핑 작업. 이런 관계 형으로 구조화한 생각의 결과를 정해진 액션에 따라 화면의 전체 혹은 일부에 연출함으로써 전달하는 작업.
시간 혹은 작업을 기준으로 해서 작업과 작업을 나열하거나 우선 순위도에 따라 매핑을 달리해보고 검증하는 작업. 이런 작업들에 대한 미화작업. 데이터간 표현의 형식정렬법들(정렬, 회전 등등등), 이런 경험을 양식화한 템플릿, 그리고 재확인 및 공유를 위한 인쇄, 커뮤니케이션 도구로의 전송. 나열하면 한도 끝도 없을 것 같다. 시장은 지금까지도 데스크탑 기반의 오피스로부터의 결과물들에 익숙하고, 플랫폼과 대역폭은 증가하여 그 규모 역시 세포분열이라도 하는 듯 엄청난 규모의 데이터 양산을 가속화한다. 물론 데이터스모그라는 악 효과도 뒤따르고 있지만. (제발 도움 안 되는 LINK와 REPORT는 돈 내고 인터넷에서 사지 말길. 이제 링크 하나 누르는 시간도 당신의 기회비용을 야금야금 앗아가는 요인이라는걸 생각해보길.) 구글은 DOCS로 오피스환경의 변화를 꾀했다.
데이터를 저 곳에 던져 넣어 모두가 만족하는 그것을 위해 달린다는 구글의 철학과의 관계를 떠나 인터넷 기반인프라, 인프라의 원천 기술, 익숙해진 생리를 잘 아는 이들의 입맛에 맞게 그들은 멋지게 브라우저 기반의 오피스를 붙여놓았다. 페이지 리프레쉬나 뉴윈도우, 팝업 UI를 최대한 배제했고, 저장과 같은 빈번한 데이터 저장 및 접근 컨트롤을 억제라도 하듯이 펑션들은 라이트하게 배치됐다. 이런 게 웹용 오피스의 UI 가이드라인이라고 뇌까리는 것처럼. 하지만 여러 번 사용해보고 자세히 들여다보면 사용자들의 전환 비용은 꽤 크리라 생각한다. 대표적으로 언제 끊어질지 모르는 인터넷 세션이라는 낮은 신뢰도 - IE는 100% 죽지 않는 무쇠팔 무쇠다리인가 – 및 기존 데이터와의 호환성, 변환이슈 등등 여러 가지 부담 장벽이 그 비용의 원인이리라.
자세한 기능들이야 이곳에 오는 지인 분들 대부분 내로라하는 분들이니 논할 필요는 없을 듯 하고 오늘은 구글 DOCS하면 많은 리뷰어들이 이야기한 기술적 우위중 하나인 공유에 대해 이야길 좀 하려 한다. 얼마 공개질의를 하고 리플종용 테러(?)를 통해 그들의 시장에서의 오피스작업을 물은 적이 있다.
작업 패턴이 다른 A팀과 B팀으로 나누어 어느 팀의 패턴에 가까운 일을 더 자주하는지. A팀은 하나의 과업을 여러 개의 소 과업으로 나누고 그 소 과업을 하나씩 맡아 말 그대로 순차적 분업에 가까운 쪽으로, B팀은 하나의 과업을 똑같이 여러 명의 구성원이 진행하되 그 대상을 달리하는 형태였다. 열일곱 분 중 열세 분. 즉 과반수 이상이 모두 전자와 같은 패턴으로 일한다고 대답했었다. 물론 윈스 역시 A형태의 일을 많이 하는 듯 했다.
허나 잘 기억해보면 A형태의 일이나 B형태의 일의 규모가 비슷하게 일하지 않았나 싶다. 어쩌면 oojoo님이 언급했던 것처럼 a를 하지만 b처럼 하는 경우였을지도 모른다. 좀더 안으로 생각해보면 과업규모가 크고 유관정보가 많으면 많은 일일수록 A타입에, 유관 정보가 작고 빨리 끝낼 수 있는 과업일수록 B타입에 가깝게 일하지 않았나 싶다. 돌이켜 생각해보자.
내가 작업한 데이터의 일부를 마무리하고 넘기지 않은 형태에서 다른이와 협업한 경험이 얼마나 되는가? (윈스는 별로 없는 듯 하다.)
내가 작업한 데이터의 신뢰도를 높이기 위해 어떤 분야에 관한 데이터 전문가가 준 유관 정보를 어느 시점에 누가 넣었었는가? (윈스는 데이터 검증, 활용까지 혼자서 했던 것 같다.)
신뢰도 높은 근거를 위한 로우데이터 작업을 남에게 맡겨본 경험이 있는가? 이런 경험이 많은가? (윈스는 별로 없는 듯 하다.)
구글 DOCS의 SHARE는 말 그대로 사용자 액티비티 작업 단위의 협업이 가능한 수준이다. 같은 페이지를 두 명의 공유대상이 접근하여 실시간 협업까지 가능하다. 테스트를 하다 보면 놀라우리만큼 그 반응 또한 빠르다. 기본적 기능이지만 데이터의 변경통제 히스토리까지 제공한다.
헌데 이런 일련의 기능들이 협업 툴의 기본적인 부분이라 하지만 그 효용가치가 얼마나 될지 자꾸만 의구심이 든다. 바꾸어 말하자면 오피스라는 독립 작업 경험 성향이 높은 틀에 맞추어 협업하라 하지 말고, 우리의 생산활동에서 지금 협업을 필요로 하는 것에 맞추어 적용되어야 하지 않을까라는 의문을 스스로 던지는 중이다.
정말 단순하게 생각하면, 위키피디어에 먼저 적용하여 검증해봄으로써 수요자에게 접근해 보는 것은 어떨까? 반대로, 이벤트 단위의 협업을 마친 작업물의 결과가 오피스 포맷의 파일이지만, 협업 참가자의 일정 블로그 포스트를 이루는 UGC 타입이면 어떨까? 이거 너무 허무맹랑한 논리인가? 우린 스스로타협한 부정확한 데이터를 버리고 신뢰도 높은 협업을 하고 있는 건가.
그렇다고 자위하고 싶다.
|
