‘오피스 SW가 갖추어야 할 것?’ 하면 무엇이 있을까?

우선 작업으로 한번 생각해볼까?
수를 기반으로 하는 통계 데이터를 구조화하는 작업
이러한 데이터를 모아서 분석하기 위한 인사이트 추출 작업
추출된 인사이트를 풀어 해석하고 표현하고자 하는 작업
정리된 정보를 전달하고자 하는 작업
위와 같은 과업을 중요하게 생각하는 정보 리터러시가 되려는 일련의 작업들.

다시 기능적 예로 생각해보자.
무언가 통계데이터를 위한 수식과 함수, 참조데이터와 다양한 보기기준과 관점을 바탕으로한 변환 및 순환참조. 정리 정돈 가능하지만 순차적 혹은 정리정돈 된 데이터를 공통의 성격으로 나누어 배열해보는 표 작업. 공통기준이 아닌 계층적, 순차적 기준에 의해 줄과 문단 그리고 페이지를 구분하여 속성과 스타일로 계층적으로 배열해볼 수 있는 작업.
생각의 논리를 단순 도형, 순서도, 분기로 표현하는 작업. 행과 열의 매치를 통해 논리를 재구성해보는 작업. 꼬리에 꼬리를 무는 논리의 마인드매핑 작업. 이런 관계 형으로 구조화한 생각의 결과를 정해진 액션에 따라 화면의 전체 혹은 일부에 연출함으로써 전달하는 작업.
시간 혹은 작업을 기준으로 해서 작업과 작업을 나열하거나 우선 순위도에 따라 매핑을 달리해보고 검증하는 작업. 이런 작업들에 대한 미화작업. 데이터간 표현의 형식정렬법들(정렬, 회전 등등등), 이런 경험을 양식화한 템플릿, 그리고 재확인 및 공유를 위한 인쇄, 커뮤니케이션 도구로의 전송.

나열하면 한도 끝도 없을 것 같다. 시장은 지금까지도 데스크탑 기반의 오피스로부터의 결과물들에 익숙하고, 플랫폼과 대역폭은 증가하여 그 규모 역시 세포분열이라도 하는 듯 엄청난 규모의 데이터 양산을 가속화한다. 물론 데이터스모그라는 악 효과도 뒤따르고 있지만. (제발 도움 안 되는 LINK와 REPORT는 돈 내고 인터넷에서 사지 말길. 이제 링크 하나 누르는 시간도 당신의 기회비용을 야금야금 앗아가는 요인이라는걸 생각해보길.)

구글은 DOCS로 오피스환경의 변화를 꾀했다.
데이터를 저 곳에 던져 넣어 모두가 만족하는 그것을 위해 달린다는 구글의 철학과의 관계를 떠나 인터넷 기반인프라, 인프라의 원천 기술, 익숙해진 생리를 잘 아는 이들의 입맛에 맞게 그들은 멋지게 브라우저 기반의 오피스를 붙여놓았다. 페이지 리프레쉬나 뉴윈도우, 팝업 UI를 최대한 배제했고, 저장과 같은 빈번한 데이터 저장 및 접근 컨트롤을 억제라도 하듯이 펑션들은 라이트하게 배치됐다. 이런 게 웹용 오피스의 UI 가이드라인이라고 뇌까리는 것처럼.

하지만 여러 번 사용해보고 자세히 들여다보면 사용자들의 전환 비용은 꽤 크리라 생각한다. 대표적으로 언제 끊어질지 모르는 인터넷 세션이라는 낮은 신뢰도 - IE는 100% 죽지 않는 무쇠팔 무쇠다리인가 – 및 기존 데이터와의 호환성, 변환이슈 등등 여러 가지 부담 장벽이 그 비용의 원인이리라.
자세한 기능들이야 이곳에 오는 지인 분들 대부분 내로라하는 분들이니 논할 필요는 없을 듯 하고 오늘은 구글 DOCS하면 많은 리뷰어들이 이야기한 기술적 우위중 하나인 공유에 대해 이야길 좀 하려 한다.

얼마 공개질의를 하고 리플종용 테러(?)를 통해 그들의 시장에서의 오피스작업을 물은 적이 있다.
작업 패턴이 다른 A팀과 B팀으로 나누어 어느 팀의 패턴에 가까운 일을 더 자주하는지. A팀은 하나의 과업을 여러 개의 소 과업으로 나누고 그 소 과업을 하나씩 맡아 말 그대로 순차적 분업에 가까운 쪽으로, B팀은 하나의 과업을 똑같이 여러 명의 구성원이 진행하되 그 대상을 달리하는 형태였다.

열일곱 분 중 열세 분. 즉 과반수 이상이 모두 전자와 같은 패턴으로 일한다고 대답했었다. 물론 윈스 역시 A형태의 일을 많이 하는 듯 했다.

허나 잘 기억해보면 A형태의 일이나 B형태의 일의 규모가 비슷하게 일하지 않았나 싶다. 어쩌면 oojoo님이 언급했던 것처럼 a를 하지만 b처럼 하는 경우였을지도 모른다. 좀더 안으로 생각해보면 과업규모가 크고 유관정보가 많으면 많은 일일수록 A타입에, 유관 정보가 작고 빨리 끝낼 수 있는 과업일수록 B타입에 가깝게 일하지 않았나 싶다.

돌이켜 생각해보자.
내가 작업한 데이터의 일부를 마무리하고 넘기지 않은 형태에서 다른이와 협업한 경험이 얼마나 되는가? (윈스는 별로 없는 듯 하다.)
내가 작업한 데이터의 신뢰도를 높이기 위해 어떤 분야에 관한 데이터 전문가가 준 유관 정보를 어느 시점에 누가 넣었었는가? (윈스는 데이터 검증, 활용까지 혼자서 했던 것 같다.)
신뢰도 높은 근거를 위한 로우데이터 작업을 남에게 맡겨본 경험이 있는가? 이런 경험이 많은가? (윈스는 별로 없는 듯 하다.)

구글 DOCS의 SHARE는 말 그대로 사용자 액티비티 작업 단위의 협업이 가능한 수준이다. 같은 페이지를 두 명의 공유대상이 접근하여 실시간 협업까지 가능하다. 테스트를 하다 보면 놀라우리만큼 그 반응 또한 빠르다. 기본적 기능이지만 데이터의 변경통제 히스토리까지 제공한다.
헌데 이런 일련의 기능들이 협업 툴의 기본적인 부분이라 하지만 그 효용가치가 얼마나 될지 자꾸만 의구심이 든다. 바꾸어 말하자면 오피스라는 독립 작업 경험 성향이 높은 틀에 맞추어 협업하라 하지 말고, 우리의 생산활동에서 지금 협업을 필요로 하는 것에 맞추어 적용되어야 하지 않을까라는 의문을 스스로 던지는 중이다.

정말 단순하게 생각하면, 위키피디어에 먼저 적용하여 검증해봄으로써 수요자에게 접근해 보는 것은 어떨까? 반대로, 이벤트 단위의 협업을 마친 작업물의 결과가 오피스 포맷의 파일이지만, 협업 참가자의 일정 블로그 포스트를 이루는 UGC 타입이면 어떨까? 이거 너무 허무맹랑한 논리인가?

우린 스스로타협한 부정확한 데이터를 버리고 신뢰도 높은 협업을 하고 있는 건가.
그렇다고 자위하고 싶다.

자 간만의 애플 CEO 스티브잡스의 프리젠테이션을 또 살펴봐야지.
윈스...그 좋아하는 커피프린스 한 잔을 못마시고 이거 보고 이러고 논다.
윈스는 역시 시간관리 못하는 바.보.다. (회사 짱님이 보라는 메일을 무시하지 못해서...쩝)
남들은 완츄 완소라던데. 윈스는 냉소 리뷰 할란다.
자 시이~~~작!

1. I-PHOTO 08
- 수천, 수만개의 사진에 대한 썸네일 즉시 스크롤 지원, 관리의 이슈 (스크롤시 시계열 view 지원)
- 생일, 동창회, 여행 등의 주제의 포토 - ADVANCD 기능 -> 같은 날짜 등의 주제에 대해 ADVANCED VIEW 지원
- 수천개의 포토를 찾는것 대신 100개의 포토로 REDUCTION 해줌.(오거나이징에 있어 확장된 방법)
- 손쉽게 REDUCTION 해줌.(같은 날짜 등등 다양한 기준으로 가능-사용자맘대룽)
- 확장 뷰 기능은 physical 기반 폴더 기준이 아닌 스플리팅 기능을 통한 어노테이션 처리로 분리하는듯.

HIDE PHOTO
- 하일라이트, 약간 어둡게, 숨기는 형태의 세가지 형태
- 필요시에 감출 수 있어 편하다는 내용 블라블라

UNIFIDE SEARCH  지원
- 키워드 / 태그/ 어노태이션 등 다양한 기준으로 검색 지원

More Powerful Editing Tools
- ADJUST PHOTO(포토 보정 / 조정) (우클릭 후 Floating 다이얼로그 인터페이스, paste 만으로 다른 포토에 동일 적용가능)

테마 베이스 홈프린팅(포토 활용 팬시 상품으로 인쇄)
- 다양한 테마별 인쇄 기능 제공, 실사 앨범 인화  지원

NEW 북(인화), 캘린더 인화 - 가격 인하

- 동일 폴더 내에 오전 / 오후 찍은 포토에 대하여 spliting 기능을 사용하여 그룹핑.
- 그룹핑한 내용에 대하여 별도 어노테이션 가능.
- 어노테이션한 부분을 기준으로 seperating!!
- 태깅 / 어노테이션 지원 (비스타 / 피카사 등에 있었던 어노테이션으로 중요도 지정 가능)

   .MAC 서비스 (웹앨범)지원 (.MAC WEB GALLERY)
- 1천 7백만 등록 사용자,  아이포토08과 동시에 새로운 닷맥 연동 서비스.
- 단 한번의 클릭으로 공유 가능! (한번은 아니던데 -.,-)

- WEB 2.0 식의 VIEW 지원
-- 슬라이드쇼 등 다양한 기능 지원
-- 오거나이징 지원
-- 사파리 / IE / FF  등 다양한 플랫폼 지원

- 인화 기준의 고해상도 다운로드 지원 (고해상도 파일 업로드 가능 - 대용량 파일 지원)
-- 20 / 16 인치 고해상도 지원

- 어디서든 접근 가능
-- 웹 갤러리 중심.

(맥 -> 웹 퍼블리싱, -> pc와 함께 공유 가능)

(pc에서 다시 웹 갤러리로 아웃룩 클라이언트와 같은 메일프로그램을 통해 업로딩 하여 공유 가능. 웹 갤러리가 그 중추 역할.)

-- 아이폰 지원(아이폰에서 웹 갤러리로 접근 가능)

(업로딩 옵션: 웹앨범 설정: all / only me,  Edit names and password -
가족들에게 알려주어 인증 가능 - , 방문자에게 다운로드 허용
, 업로드 허용, 이메일을 통한 업로딩 허용, 이메일 주소를 방문자에게 공개)

웹 갤러리내에서 스키밍(skimming) 지원 시연 등등등..쩝쩝쩝

아이포토08에 대한 윈스생각
Advanced view 는 대표 이미지와 스키밍을 통해 빠른 접근을 지원하는
Coooooool~한 방법이긴 하지만, relevance에 있어서는 역시 rating, tag
등에 기반한 annoation 을 권장하시는 군요. 역시 사람 생각은 다 거기서
거기. (욕심쟁이 우후후!)

2. I-MOVIE 08
  새로운 편집 방식/인터페이스 고안. 새로운 Identity를 위한 아이콘부터 재디자인

- 대부분의 소스 지원
-- 스틸카메라, 캠코더, HD-VIDEO 캠코더, 새로운 ABHD 캠코더 - 슈퍼 하이 퀄리티 8기가 바이트 지원 새로운 캠코더 표준
- 스킴 투 뷰
-- 실시간 플레이백 컨트롤 지원(디바이스 연동 된 상태의 프로세싱)
- 빠른 영상 제작 지원
-- 드래그 앤 드롭을 통한 빠른 편집
- 다양한 라이브러리 / 편집
-- 음악 / 사진 / 자막 / 모션 이펙트 지원
- 가장 중요한 이슈!  - 다양한 공유 지원 (이시대 사람들이 원하는 키!)
-- 아이튠즈
  --- IMAC 머신, 아이포드 , 아이폰 등 다양한 디바이스 환경 지원
-- 닷맥 웹 갤러리(영상 업로드 가능)
  --- 다양한 레졸루션으로 인코딩 가능. TINY, MEDIUM , LARGE 모드로 인코딩 가능 (HIGHER RESOLUTION)
  --- 10기가 금방 찰텐데. 우리나라 divx 공유 문화를 하루만 체엄해보시길........T.T 슬픈 현실.
- 보고 공유하고!
-- 유튜브로 바로 업로드 가능!

- 시연
-- 메인 UI변화. 모니터 / 라이브러리 영역 위치가 바뀌고, 클립 라이브러리 영역이 썸네일 / 타임라인 편집 기준으로 변화.

-- 하나의 클립을 여러개의 캐스트 리소스로 나누어 처리 (나누는 기준은 오토 씬 디텍션 기준: 피사체가 크게 변화하는 기준)
-- 각 캐스트별 다이렉트 스키밍(Skimming) 지원 (이거 아주 예술임)
-- 더블클릭 / 스페이스로 실시간 재생 가능(온다이렉트 플레이백 컨트롤 기능)

윈스생각1: 썸네일 기반 VIEW 임에도 불구 타임라인 베이스에 가까운 편집 기준으로 사용자 접근을 유도하고, 시계열을 떠난 스토리와 플롯 구성 및 다이렉트편집이 용이한 구조로의 변경(아이맥, 아이라이프라는 하드웨어 플랫폼과 유기적으로 동작하는 환경에서나 가능하리라 판단됨)

윈스생각2: 헌데 왜 유튜브에 올리는 영상은 시연을 안해주는걸까? 열심히 유료 닷맥 서비스의 웹갤러리에서의 공유만 보여준다.

종합: 윈스가 애플에 하고픈 이야기.
윈스가 당신들의 이런 영상을 이런 이야길 담아 설명하는 동영상을 만들려면 과연 맥을 얼마나 배워야 할까요?

제가 가진 PC를 팔고 스티브잡스 당신이 보여준 시연과 동일한 퍼포먼스로 영상 편집을 하려면 얼마나 더 비용을 내야 할까요?

과연 그 비용은 지금 투자해서 사용법을 익혀야 하고, 다양하게 실현할 수 있는 디지털 라이프의 가치를 충분히 커버할 수 있는 걸까요?

결론: 별로 자신이 없습니다. 윈스도 7600까지 맥으로 살다가 이젠 돈이 없어 아범 씁니다만.여러 가지 이유가 창궐하더라도(ㅋㅋ), 디지털 디바이드가 일어난다 할지라도 그비용 만큼은 아닌것 같아요. 다소 냉소적인 리뷰였다면 미안합니다. 쩝!

상세기획서 어떻게 써야 할까?
예를 들어 소프트웨어 기획서의 상세기획에 있어 어떻게 작성하는 것이 좋을까?
예를 들어 하이라키 구조에 있어 컨텍스트를 제어하는 액티비티를 설명해야 하는 상세 기획에 있어 내용은 어떤 내용으로 갖추어져 있어야 할까? 우선적으로 사용자 컨트롤에 따라 액티비티 기준을 나눌 것이다. 그리고 그 기준은 다시 상세하게 나뉘어진다.

가령 윈도우 탐색기와 같은 인터페이스를 설명하는 상세기획서를 작성한다고 해보자. 우선적으로 발생할 수 있는 선택, 복사, 이동, 삭제와 같은 요소들에 대하여 개요를 설명하는 부분이 있을 것이고, 이 개요에 따라 각 세부적 항목에 대하여 다시 상세한 그림과 함께 description 을 추가해야 하고, 예외 처리에 대한 고민과 함께 각종 하드웨어/소프트웨어적인 특성 (키보드 인터랙션 등)을 설명함과 동시에 Modal 혹은 Modalless 성격을 같는 dialog / message box 에 있어서의 default, activity value range와 같은 속성 옵션을 기술해야 한다.

마이크로소프트에서 엑셀 PM을 하셨다는 조엘 아저씨의 [조엘 온 소프트웨어]에서도 설계 단계에서 개발자가 구현하기에 필요한 아주 세부적인 사항까지 기술해주어야 문제가 없음을 설명해준바 있다.

규모 있는 소프트웨어 개발 회사라면 한 사람이 아닌 여러 사람의 팀 작업에 의해 개발이 이루어질 것이고 각 개발원이 맡은 모듈에 맞게 상세기획서 역시 섹션별로 나누어 설명해주면 작업하기에 더욱 편할 것이다. 다만, 개발원간 코웍을 통해 연동 개발해야 할 부분에 대해서는 양쪽으로 나뉘어진 섹션 모두에서 설명해주어야만(물론 이때 기획서를 작성하는 기획자의 Copy & Paste 능력과 버전 관리 능력이 뒷바침 되어 주어야만 한다.) 뒷담화 없는 자연스러운 코웍 개발이 가능할 것이다.

때문에 윈스의 기획서는 사실 다른 사람보다 좀 긴 편이고, 쓸데없다라고 할 정도로 그림도 많고 코멘트도 많은 편이다.

윈스의 기획서 중 아주! 극히! 일부를 본 UX 전문가라 하셨다는 그 분께 코멘트하고 싶다.

1. 상세 기획서는 말 그대로 상세기획서 입니다. 기획서 작업은 예쁘게 보이기 위한 디자인 작업도 중요하지만, 무엇보다 무에서 유를 창조하는 유능한 개발자에게 사용자가 취할 수 있는 가능한 모든 액티비티를 기술하여 발생할 수 있는 오류를 최대한 미연에 방지토록 도와주기 위한 것이랍니다. 즉, 상세기획서는 1page proposal 이 아니랍니다. ^^

2. 상세기획서의 모든 부분을 보아주세요. 전략서가 아닌 소프트웨어에 있어 상세기획서는 섹션별로 나뉘어져 있기 쉽습니다. 신문의 사설을 볼 때에도 앞 줄 한 줄과 마지막 줄 한 줄을 읽고 아는 것이 아니라 논조와 근거를 바탕으로 한 모든 내용을 읽어보았을 때 글쓴이가 전달하고자 하는 뜻을 충분히 이해하기 좋답니다.

3. 소프트웨어와 웹에 있어서의 기술문서의 설명 방식에 약간의 차이가 있을 순 있습니다. 주요 과업을 토대로 하여 그 흐름을 잃지 말아야 하는 것 역시 웹이나 소프트웨어에 있어서 크게 다르지 않다고 생각합니다. 다만 한 가지 거론하고자 하는 차이는 기획서마다 기획자의 정성의 차이가 있다는 부분입니다.

윈스 PC의 케이스엔 물리적인 하드랙과
물리적인 파워버튼이 4개로 분기되어 있다.

OS로 보자면 위로부터 VISTA, XP, 2000, 아범 업은 맥

1. 시간에 비례하여 메모리 점유 어플리케이션이
늘어나는 양에따라 18일에 두배씩 속도가 느려지는 것 같다.

2. 하드웨어 판매량에 따라 시장확보하는 좋은 출발처럼 보이지만,
메밀꽃 필부럽 장똘뱅이 인생이 떠오른다.

3. Aero는 초기 일주일간 환상이라는 티켓을단 심각한 배낭여행족에게
유익하다.

4. 보안을 강화함으로써 호환성을 위한 Rich Application 들에게 모두
새로운 todo gift 셋을 선물하다.

5. 정말 비스타로 업그레이드 할 계획이라면 강원도 두메산골로 다운사이징
라이프 스타일을 시도한다음 듀얼코어 지하실에, 메모리 2기가라는 구획의
지반을 다진 다음, 싸타 인터페이스 기둥을 세우고 그 위에 전력선이 1개월
안에 들어오길 바라는 마음으로 준비하시길 두손 모아 권한다.

PS: 대략 1개월 전부터 가장 위쪽에 있는 파워버튼을 안누른것 같다.
너무 심하게 갈궜나? 근데 워째. 사실인걸.