OmniFocus 4 for iOS 베타 테스트

OmniFocus 4의 베타 베스트가 시작되었다. 우선 iOS 및 WatchOS 기반 베타를 시작하게 되었는데, Apple Watch는 사용하지 않으니 그냥 지나고 iPhone에 설치하여 변화의 수준을 확인할 기회가 왔다.

이번에는 애플 앱스토어의 테스트플라이트 기능을 사용할 수 있도록 전환되었는데, 여러모로 편리하지 않나 싶고 OmniGroup에서의 관리 용이성도 높을 듯 하다.

OmniGroup이 이-메일 링크로 다운로드가 시작되고 설치되어 그런지 따로 베타 코드를 입력하지 않아도 구동이 가능했다.

실제적 사용은 좀더 시간이 걸리겠지만 첫 느낌은 이전 버전에 비해 인터페이스 조금 복잡하다 내지는 어렵게 배치되었지 않나 싶다. 새로운 기능의 추가로 인해 당연히 그렇게 될 수 밖에 없을 수도 있겠지만, 스마트폰과 같은 모바일 환경에 너무 많은 기능을 담다보니 기능과 별개로 인터페이스의 이러한 복잡성 문제가 OmniFocus의 어려움이지 않나 싶기도 하다. 하지만 과연 얼마나 새로울 지는 모르겠다.

솔직히 OmniFocus의 기능적 창의성은 이제 한계를 맞이한 지 오래되었다고 보는 입장에서, OmniFocus를 Mac, iPhone, iPad 그리고 Apple Watch 등 각 기기에 맞도록 설계하고 또한 독자적으로 운용하도록 하는 방법이 적절한 지는 모르겠다.

Things나 The Hit Lists처럼 구성이나 내용이 상대적으로 단순한 프로그램도 점차 기능이 확장되면서 모바일 버전에서는 사용 효용성이 낮아지고 있다. 더욱이 애초부터 복잡하고 다양한 기능으로 승부했던 OmniFocus가 모바일 버전에서도 최대한 그 기능을 모두 수용하려고 하니-그 인기에도 불구하고-사용자 입장에서 제대로 대응하기 어렵다. 오히려 Mac 버전을 중심으로 iPhone 등은 입력 및 확인 등에 특화된 보조 수단으로 활용하는 방법도 좋지 않을까 싶다. 물론 iPad의 경우는 인터페이스 측면에서 유연성이 높다보니 다소 경우를 다를 수도 있다고 본다.

• 베타 테스트라서 그럴 것이라고 생각되지만, 현재 버전에서는 위치 정보 기능이 빠져 있다. iOS 버전의 OmniFocus의 유일한 핵심 기능이라고 할 수 있는데, 설마 향후 제거할 계획인가 ?

블로그 포스팅 오류로 인한 이전 포스팅 정비 중.. T T

한창 더운 여름날의 주말, 예기치 않은 포스팅 오류로 이전 포스팅까지 삭제되는 사태가 발생했습니다. 포스팅 원본 내용은 MacJournal에 그대로 있기 때문에 사라질 위험은 없지만, 이전 내용을 다시 일괄로 업로드 할 수 없어 개별 포스팅을 하나 씩 복구해서 다시 올리고 있습니다.

휴가철의 외로운 플래닝 맨 ?

어느 날 혹은 언제나처럼 오늘도 머리 속 가득한 부담으로부터 벗어나기 위해 모니터를 바라보며 계획을 세우거나 심지어 어떤 프로그램이 계획 수립에 적합한 지 웹 서핑에 빠진 자신을 본 적이 있지 않나 싶다.

하지만 무섭게도 이런 일이 어제도, 오늘도 그리고 내일도 계속 될 것이다. 아마도 많은 혹은 적지 않은 주변의 사람들이 그러리라 본다. 다만 그럼에도 계획의 의지나 기대와 무관하게 밀려오는 일을 닥치는 대로 무엇보다도 열심히 하다보니 하루는 나름 의미있게 보낸 듯 위로하며 눈을 감는다. 그리고 곧 머리 속에는 다시금 뭔가를 해야할 부담에 잠을 뒤척이게 된다. 물론 곧 지친 몸 덕에 잠을 빠져 든다.

언제가 강조하지만 계획은 언제나 계획이다. 계획을 아무리 잘 짠다고 하더라도 실행이 보장되지는 않는다. 반대로 무언가 실행을 시작했다면 어떤 계획은 이미 시작된 것이다. 물론 성공과 실패는 별개의 결과이다. 하지만 시작했으니 어떤 식으로든 결과는 드러날 것이다.

현실적으로 그리고 사실 상 좋은 계획은 없다. 더욱이 완벽한 계획이란 존재할 수 없다. 계획이란 언제나 수정되고 바뀌고 그리고 사라지기도 한다. 계획이 지속된다는 자체만으로 가치가 있을 수도 있다. 어쨌든 실행된 계획만이 가능한 것이다. 결국 계획은 실행의 시작이면서 실행의 결과이다. 결과에 의해 좋은 계획, 완벽한 계획이 평가된다.

뜨거운 여름, 한 주 혹은 두 주 또는 몇 일 정도의 휴가 기간 동안에 많은 이들이 가족들 몰래 크고 작은 계획을 준비하는 시간을 가지려고 할 것이다. 그러나 그 모든 시도는 물거품이 될 것이다. 그러니 사랑하는 가족들과 휴가를 즐기거나 가족들 몰래 도망가기를 기원한다. 후회하고 구박받더라도 계획에 빠져 고민하는 시간 보다는 훨씬 가치가 있지 않나 싶다.

그럼에도 계획의 시간을 가지려고 한다면, 해야 할 일이나 하고 싶은 일이 아닌, 할 수 있는 일의 기록하기 바란다. 목록으로 나열하든 다양한 형식으로 맵핑을 하든 현재 머리 속에서 할 수 있는 일을 적는다면, 그 일 가운데 하고 싶은 일과 해야 할 일이 있다. 그리고 그 일들을 분류하거나 정리하지 말고, 당장 할 수 있는 일이라고 생각되는 일부터 실행하도록 하자.

할 수 없는 일이라면 곧 벽에 부딪힐 것이고 할 수 있는 일이라면 실행될 것이다. 그리고 크든 작든 새로운-미뤄두었던-계획이 시작되었다고 할 수 있다. 우리는 이미 벌어진 일에 대해서는 놀라운 대응력을 가지고 있음을 안다.

어렵게 비싼 비용을 들여, 좋은 그리고 강력한 프로젝트 및 플래닝 프로그램을 찾더라도 자신의 계획은 실행은 커녕 제대로 수립해주지도 않는다. 휴가비만 날릴 지 않을까 싶다.

GTD의 업무 계층화, 프로젝트 관리에 대한 오해

GTD 시스템 운용이 쉽지 않거나 나름 제대로 된 운용을 하고 있다고 싶지만 뭔가 불안정한 상황이 이어지고 있다면 한번 쯤 뒤돌아 보아야 할 것이, GTD 시스템의 프로젝트 관리에 관한 사항이 아닐까 싶다.

OmniFocus(이하 OF)와 Things(혹은 Microsoft To Do, 이전 Wunderlist)의 GTD 구현 과정의 가장 큰 기능적 차이는-이른바 프로젝트로 불리는-업무 간의 계층적 구조에 대한 처리에 있다. 일단 기능적인 측면에서 OF는 Things에 비해 높은 혹은 복잡한 수준의 계층 구조를 지원한다. Things 역시 계층화 구조 구현에 대한 사용자들의 의견을 수용하여 상당 부분 계층적 구조에 대한 지원이 가능하도록 개선되었다. 그럼에도 반드시 기능적 구조에서 Things의 OF의 계층화 구조 프로젝트 관리에 대응할 수 없다.

물론 이러한 기능적 차이가 GTD 시스템의 기술적 우위를 가르는 일방적 기준이 될 수는 없다. 이전 여러 포스팅에서 이런 내용을 적었다. 하지만 어쩔 수 없은 기능의 존재과 구조에 따른 비교이다 보다 OF가 Things에 비해 우위에 있다는 사실을 부정할 수도 없다.

문제는 OF를 사용하든 혹은 Things를 사용하든 프로젝트 혹은 복잡한 계층화 구조의 기능을 제대로 이해하고 사용하지 못한다면 GTD 시스템 운용의 큰 낭패를 볼 수 있다는 점이다. 일반적으로 업무를 계층화된 구조로 구성하게 되면 어쩔 수 없이 상위에 있는 항목이 하위에 대해 주요한 위치를 차지하거나 혹은 관리 우선 순위에서 높은 곳에 있다고 생각하게 된다.

그러나 GTD의 가장 근본적 개념이 이러한 구조로 부터 벗어나 현실적으로 현재 실행 가능한 일을 수행하는 방식을 제공한다는 사실에서, 프로젝트에 대한 상세한 구성 및 관리에 지나친 집중을 하게 되면 GTD의 기능적 운용 범위를 초과하게 될 수 있다. 즉 GTD 시스템을 넘어 프로젝트 관리 시스템으로 진입하게 된다는 것이다.

우선 GTD의 개념적 측면 이전 계층화 구조의 업무 체계 즉 프로젝트 관리의 가장 큰 문제점을 한번 생각해 볼 필요가 있는데, 그것은 일의 시급성이나 중요도에 비해 전체적 구조에 묻혀 기대한 만큼 명확하게 드러나지 않는다는 것이다. 물론 개별 업무에 마감일, 중요도 혹은 플래그 등을 지정하여 운용하지만, 그 대상이 적지 않은 경우에 이 정도 수준의 관리 요소로서는 기대치를 만족시킬 수 없다는 것이다.

때문에 용어 비교 측면에서의 혼란이라고 할 수 있지만 전통적인 프로젝트 관리 체계와 GTD의 업무 요소의 관리 기능에서의 프로젝트가 동일한 용어를 사용함에 따라 시간이 지나 GTD 시스템의 관리 요소가 일정 수준 이상으로 증가하게 되면 이도저도 아닌 관리 방식이 되어 버릴 수 있다. GTD 시스템의 관리 범위가 넓은 경우라면 다들 비슷한 체험을 했으리라 예상된다.

물론 Things와 같은 다소 제한적 구조의 GTD 시스템에 느끼는 상대적인 답답함은 부정할 수 없다. 나 역시 OF의 선택에서 그런 이유가 가장 크다. 하지만 앞서 언급한 프로젝트 관리의 문제 역시 Things에 비해 OF를 운용할 때 더 심각하게 느껴질 수 있다.

그러므로 이러한 문제로 부터 벗어나 좀더 여유롭게 프로젝트 관리를 하기 위해선 OF 프로젝트 관리 기능을 명확하게 이해하고 자신만의 관리 기준을 정할 필요도 있다. 예로 프로젝트와 세부 프로젝트의 그룹 설정을 너무 순차적 내용으로 규정하려고 애를 쓸 필요가 없을 수도 있다. 사실 아직 일어나질 않은 일들의 관련성을 순차적으로 배치한다는 자체가 무리일 수 밖에 없고, 명확한 표현으로 구분되고 배열된 경우 수정이나 재배치가 상대적으로 힘들 수 있다. 계획은 언제나 계획일 뿐이라는 점에서 여유를 두는 것도 좋다. 일이 아닌 일의 관리 자체를 너무 완벽하게 작품처럼 꾸미는 것은-모든 경우는 아니겠지만-불필요할 수도 있다. 실제로 세부 계획이 명확하다고 수립된 프로젝트 조차 계획이 변경되는 것이 일상인 현실에서, GTD 시스템에서 아직 불분명한 사실들을 가지고 명확한 세부 계획을 수립하고 관리하기란 정말 어렵다.

또한 앞선 자심 언급한 바와 같이 계층화된 프로젝트에서 계층화는 일의 우선 순위에 따라 구성되고 배열될 뿐이지 일의 가치나 중요도에 따라 배치될 수는 없다. 왜냐하면 역시나 대부분의 일이 아직 실현 전의 상태이기 때문이다. 우리가 어떤 일이 얼마나 중요한 지 안다고 할지라도 실행이 요구되기 전이나 혹은 실행이 불필요한 상태에서도 실행할 수는 없다. 때문에 계층화 구성에서 의도한 가치에 따른 평가가 발생하지 않도록 해야한다.

더불어 계층화를 위한 요소를 너무 남발하지 않도록 해야 한다. 하나의 프로젝트가 여러 세부 프로젝트로, 또 각 세부 프로젝트의 내부는 또 다른 세부 요소로 구분될 때 발생할 수 있는 모든 요소를 일일이 점검해야 할 대상으로 수집하거나 입력할 필요는 없다. OF의 프로젝트는 실행하고 기대한 결과를 달성하기 위한 도구적 방식이지 프로젝트 자체를 우아하게 관리하는 위한 방식을 운용해서는 안되며 실제 그러한 기능을 제공하지도 않는다. 그런 점에서 OF에 만족하지 못하고 점점 프로젝트 관리 도구를 찾거나 관심을 보이게 되는 자신을 돌아 볼 수 있게 된다면 이러한 측면에서의 우려를 이해할 수 있으리라 본다.

마이크로소프트의 Project와 같이 대규모 프로젝트 관리 도구는 말 그대로 한 사람이 감당하기 힘든 범위의 프로젝트를 관리하기 위한 체계이다. 비록 한 개인이나 소그룹의 업무가 결코 복잡하지 않다고 할 수는 없더라도 그러한 많은 관리 자원을 다루기 위한 체계로 GTD의 계층적 업무 관리 체계의 불편함을 극복하려고 하는 것은 잘못된 판단이라고 본다.

E-메일 관리, 풍요 속의 빈곤 - 그 시작 ?

GTD 시스템, 소프트웨어가 아닌 관리 체계로서 골치 아픈 대상의 하나가 이-메일 메시지라는 것은 다시 강조할 필요가 없을 것이다. 블로그의 수 많은 포스팅에서도 이-메일 관리에 대한 의견과 대응을 적었다. 그러한 문제의 원인 중 하나가 예전과 달리 이-메일 계정의 생성이 쉽다보니 마음만 먹으면 수십 개의 이-메일 계정을 소유할 수도 있다. 특히 요즈음처럼 사용자 인증을 이-메일로 하는 경우 특별한 용도의 웹 서비스를 위한 별도 이-메일 계정을 만들어 사용하기도 한다. 어느 순간 자신의 얼마나 많은 이-메일 계정이 있는 지에 놀라는 경우도 있다. 반면 수십년 동안 한두 개의 이-메일 계정을 사용하는 경우도 결코 적지 않다. 이렇듯 많고 적든 이-메일 계정이란 것은 하나 생성하고 나서는 사용하지 않은 경우에도 중지나 제거 등을 하지 않고 결국 쌓인다. 사실 이런 경우는 문제가 될 것이 없다. 사용하지 않은 이-메일로 특별한 메시지가 올 경우도 드물고 오더라도 대부분 스팸이나 광고성 메시지이니 무시해도 상관없다.

하지만 특별한 경우인지는 모르지만 나의 경우는 꽤 많은 이-메일 계정을 사용한다. 일상적으로 사용하는 계정만 보더라도 대여섯 개는 넘고 관리하는 계정은 거의 십여 여개에 달한다. 개인용 한두 개, 업무용 두세 개, 외부용 한 두 개 등등, 생각해보면 정말 이렇게 이-메일 계정이 많아야 했는 지 의문이 들기도 한다. 하지만 이 정도 역시 제법 많이 그리고 주기적으로 정리한 것이라는 점이다.

그러므로 이-메일 관리의 가장 근간은 또 다시 강조하지만 사용하지 않거나 사용 빈도가 적인 이-메일 계정을 과감하게 삭제하는 것이다. 라이센스 등에 등록된경우라면 이-메일 변경이 가능한 지 혹은 단순한 로그인 네임으로만 사용되는 지 등을 파악하여 정리할 수도 있을 것이다. 만약 그럴 수 없다면 이-메일 계정의 포워딩 서비스를-가능하다면-이용하거나 혹은 별도의 이-메일 클라이언트를 이용하여 해당되는 모든 이-메일 계정을 나름대로 통합하여 관리하는 방법이 있을 것이다. 개인적으로 Spark 이-메일 클라이언트를 사용하여 후자의 방법을 사용한다. Spark의 다양하고 강력한 기능에 반한 애용자라면 지탄할 대응이 아닐까 싶다.

사실 한국에 살면서 네이버, 다음 등 이른바 포털을 사용하지 않을 수는 없고, 일단 작은 용도라면 사용하게 되면 이-메일 계정이 자동으로 생기고 시스템 관련 메시지가 해당 이-메일 계정으로 날라오는 어쩔 수 없지 않나 싶기도 하다. 이런 웹 기반 서비스의 이-메일 계정 가운데 IMAP나 POP3를 지원하지 않는 경우가 있다면 애무 당황스러울 것이다. 요즈음 업무 환경이 웹 기반으로 바뀌다보니 그런 경우가 의외로 적지 않은 것 같다. 나 역시 꽤나 오랜 시간 몸소 그런 경우를 겪어야 했다. 대개 웹 기반 메일 관리에 특별히 거부감이 없겠지만, 처음부터 이-메일 클라이언트 기반으로 메시지를 관리해 온 습관 덕에 웹 기반 이-메일 운용은 내게 있어 정말 어색하다.

물론 지금까지 넋두리처럼 적은 이야기는 실제 접하게 될 수 많은 이-메일 메시지 기반의 업무 관리나 GTD 시스템 운용에서 발생하는 여러 문제에 비하자면 문제라고 부르기도 어려운 수준이다. 더욱이 같은 이-메일 서비스가 컴퓨터 시스템, 운영체제 그리고 이-메일 클라이언트에 따라 서비스 수준이나 기능에 일관성이 없다며 정말 난감하다. GTD 사용자로서 앞으로 다루고자 하는 이-메일 메시지 관리의 많은 문제들이 그러한 요소에 기인하고 있기도 하다.

다양한 이-메일 서비스의 선택 혹은 선택의 여지 없는 사용, Windows나 macOS와 같은 특정 운영체제에서 구동되는 이-메일 클라이언트 성능과 기능의 문제, 더불어 예기치 못한 크고 작은 문제들로 인해 이-메일 서비스 자체를 포기해야 하는 등의 경우를 심심찮게 겪어 왔다. 그리고 그 가운데 여전히 해결되지 않은 문제가 이어지고 있다. 아마도 컴퓨터 시스템이나 스마트 폰의 일상이나 업무의 핵심 도구로 자리잡고 있는 가운데 여러 개의 이-메일 계정을 함께 운용하는 경우라면 비슷한 경험을 하고 있을 것이라 생각든다.

과연 K-프로젝트는 태어날 수 있을까 ?

내 삶에서 일정 관리, 업무 관리, 혹은 프로젝트 관리는 삶의 걸림돌을 해결하는 방안이라 생각했고, 그러한 해결은 컴퓨터 소프트웨어로 구현된 어플리케이션이 답이라 생각했던 시절이 꽤나 길었다. 지금 기억으로도 Apple Desktop, Multiplan. Think Tank, MS Project 등 셀 수 없는 어플리케이션들을 사용하면서 나름의 답을 찾으려고 했다. 하지만 솔직히 제대로 된 결과로 이어지진 못했다.

영어 표현의 문제도 있었고, 제한된 텍스트 화면의 한계 때문이기도 했고, 무엇보다도 업무 관리나 프로젝트 관리에 대한 제대로 된 개념이나 이론 그리고 경험도 없었지 않나 싶다. 하지만 그 시절을 지나 학교에서도, 학윈 과정에서도, 회사에서도 그러한 고민은 해결되지 않았다. 8-비트 컴퓨터에서도 64-비트 컴퓨터로 바뀐 세상에서도 삶이나 업무의 만족스러운 관리를 제공해주는 어플리케이션을 꼽으라면 선뜻 생각하기 어렵다.

그 오랜 시행착오의 결론을 한 마디로 적자면, 정말 Microsoft든 SAP든 어떤 소프트웨어 기반의 프로젝트 관리는 정말 한국인 혹은 한국식 업무에는 적용하기 쉽지 않다는 것이다. 그리고 그 고민은 이 순간에도 계속되고 있다. 도대체 이러한 소프트웨어를 제대로 활용하고 있는 기업이나 기관이 있다면 세계 어디라도 달려가서 보고 싶을 정도이다.

새로운 프로젝트, 프로젝트 관리 시스템 구축 프로젝트 자문을 위해 도입 측과 공급 측의 이야기를 듣고 있지만 정말 답이 없는 것 같다. 도입 측은 표준 규정과 예외 사안의 비중이 거의 같은 수준이다. 세상의 모든 것을 원한다. 그리고 공급측은 일명 전문가란 탈을 쓴 사기꾼 수준이다. 상대방이 원하는 세상의 모든 것을 구현할 수 있다.

과연 원하는 기능으로 프로젝트 관리 시스템이 구축될 수 있을까. 프로젝트 관리 프로젝트를 관리해야 프로젝트를 하다니.. 한편으로는 매우 흥미롭다. 정말 K-프로젝트가 태어날 수 있을까 ?

그렇다면 한국인에게 맞는 프로젝트 관리의 방식이란 무엇일까? 가장 일반적인 상황은 일이 많다는 것이다. 대개 한두 개의 프로젝트에 발을 걸치는 경우는 일상이며, 규모가 작거나 인원이 적다면 문어발 수준이 된다. 게다가 평소의 직급이나 직책으로서의 일은 여전하다. 그렇다보니 MS Project와 같은 관리 체계에서 자원이 대상으로 인원의 배치나 할당 시간이 현실적으로 무의미해지게 되고, 그 결과의 예측치는 그저 그래프 출력을 위한 값 이상의 가치는 없다고 여긴다.

더욱이 프로젝트 간의 이동이 잦다. 그나마 이동이 없더라도 서류상 무관한 프로젝트에도 유령 지원자들이 꽤 많이 활동하기도 한다. 좋은 점일 수도 있지만, 프로젝트의 예측 관리 측면에서는 이러한 사항을 염두에 두어야 할지 말지가 고민일 경우도 있다.

물론 규정 업무 시간에 따라 관리는 굳이 언급할 필요가 없을 것이다. 최근에는 이러한 관리가 더욱 곤란한데 인원을 채용하면 간단히 해결될 문제를 어쩔 수 없는 현실적 사정을 빌미로 이리저리 돌려막기를 하니, 그러한 상황을 현재 프로젝트 관리 소프트웨어에서 구현하기란 불가능하지 않나 싶다.

그 외 수 많은 한국스러운 프로젝트 관리의 방식이 과연이 새로운 프로젝트 관리 체계에 녹아 들 수 있을까? 솔직히 이게 구현되면 노벨상 수상감이라고 농담삼아 이야기한다. 프로젝트 관리를 위한 프로젝트, 다시 그 프로젝트를 위한 프로젝트 관리.. 한편으로는 매우 암담하다.

할 수 있는 일의 시작과 함정

사람들은 자신이 잘할 수 있는 생각하는 일이 언제나 그 잘할 수 있음의 대상으로서 지속된다고 생각한다. 때문에 일의 우선 순위에서 할 수 있는 일, 잘 할 수 있는 일은 뒤로 미뤄두고 지금 해야 하는 일에 집중하게 된다. 하지만 매 계절, 매 년 우리는 언제나 할 수 있는 일이나 하고 싶은 일들이 일 목록에 그대로 올려지 있음을 확인한다. 언제든 할 수 있는 일이기에 또 지금 고민할 일이 아니라고 평가하면서 다시금 뒤로 미루게 된다. 할 수 있는 일이니 시작은 언제하든 무슨 상관이겠는가. 시간이나 노력이 아닌 결심의 문제일 뿐이다. 하지만 대개는 심각한 착각이다.

과격한 비교일지 모르겠지만 주변에서 퇴직 후 혹은 기존 사업을 정리하고 새로운 창업을 하는 경우를 보면, 그 일을 비즈니스라 부르든 사업이라 부르든 혹은 장사라 부르든 이른바 창업에 대한 결정은 선택의 여지가 다양한 경우가 아닌 최후의 방안으로 창업에 뛰어든 사례가 많다.

자신이 잘 하는 일에 발휘할 역량을 대부분을 소모한 후, 선택의 여지가 없는 상황에서 창업을 하게 된다. 덕분에 마음 고생, 몸 고생 등 갖은 노고에도 불구하고 기대한 바를 얻기는 힘들다. 자신이 잘할 수 있다는 기대 외 다른 주변 역량을 모두 소진된 상태이니 결과는 충분히 예상될 수 있다.

할 수 있는 일을, 더욱이 하고 싶은 일이라면 그 일을 한 시점은 바로 지금이라고 할 수 있다. 아마도 지금 가장 잘 할 수 있는 일이라고 본다. 물론 미뤄도 아무 문제가 없을 수 있다. 그렇다면 더더욱 지금 처리하는 것이 가장 안전한다. 진행에 시간이 오래 걸린다면 지금이라도 시작해야 하지 않을까 한다.

할 수 있이나 하고 싶은 일이 있다면 가장 그 일을 잘 할 수 있는 지금이어야 한다. 그렇지 않으면 할 수 없은 일이 될 수도 있고, 더 심각하게는 하기 싫은 일이 될 수도 있다. 그럼 오랜 시간이 지난 후 자신이 하고 싶었던 잘 할 수 있다고 생각했던 일이 실상 할 수 없는 일이었고 하고 싶은 일로 착각하고 있었다는 것을 알게 된다. 얼마 남지 않은 시간을 다시금 하고 싶은 일을 찾거나 하고 싶은 일인지 스스로 고민에 빠져 허우적거리게 된 이들이 여전히 주변에 많다.

코로나로 인한 활동 제약의 순기능 ?

코로나 19 사태로 인해 수 많은 일을 겪었고 그리고 그로 인해 우리의 일상에 큰 변화를 맞이했다. 하지만 그러한 변화가 누구도 예상치 못하게 지속되었고 앞으로도 지속될 것으로 예상되고 있다. 덕분에 많은 일상의 변화가 더 이상 변화가 아닌 일상이 되어 가고 있다. 그 가운데 전에는 정말 예상치 못한 것이 업무와 관련한 사람을 직접 만나는 일이 필수적인 경우에서 가능한 지양해야 할 선택적 사안으로 변했다는 점이다.

만나러 간다는 자체도 찜찜하지만 만나야 하는 입장도 마찬가지다. 그래서 전화나 이-메일 혹은 화상 회의를 진행하기도 한다. 처음에는 어렵고 낯설었지만 어느새 일상이고, 그러한 상황에서 더욱 간편한 회의 환경을 만들거나 또는 단순화하고자 노력하고 있다. 심지어 회사나 학교 내에서는 다르지 않다. 이런 대응에 부정적 시각을 가진 이라도 몇 차례 직접적 주변에서 확진자가 나오고, 격리 상황을 겪고 나면 자연스럽게 비대면의 상황을 추구하게 된다. 물론 그럼에도 세상 다 산듯 막무가내인 경우도 없지는 않다.

이러한 변화는 관련된 많은 주변 산업에 영향을 미치고 있다. 관광을 위한 국내외 여행이 아닌 업무적 활동이 차지하는 비중이 상당한 여행이나 숙박 업계 등은 엎친데 겹친 겪이 아닐까 싶다. 사실 사업차 출장은 빈도는 적지만-자기 돈 쓰는 것이 아니라는 입장에서-씀씀이는 큰 편이다. 교통비나 유류비 지원을 편하게 요청할 수 없는 직급 낮은 이들도 고민스럽기는 마찬가지일 것이다.

그리고 한번 이러한 상황을 겪은 기업이나 학교에서는 출장 자체의 가치 혹은 출장에서의 비용에 대한 효용성을 보는 시각이 매우 냉정해졌다. 함께 하는 이도 줄었고 덕분에 씀씀이도 줄게 되고 그로 인해 결제의 빈도 역시 줄게된 덕에 비용 지출이 보다 쉽게 드러나게 되었다. 예전 같으면 업무적 비용에 개인적 비용이 묻혀지는 경우가 허다했지만 지금은 사실상 그런 식으로 대응하기란 쉽지 않다.

그러니 출장을 가서도 활동이 예전처럼 자유롭지 못하다. 움직이는 돈이 드는데, 장소와 내역이 쉽게 드러나니 허튼 짓 하기가 쉽지 않다. 그런 이유로 점점 출장 당사자들도 출장 자체를 꺼리게 된다. 문제가 지금까지 출장을 가야만했던 일의 상당한 부분이 아무런 문제없이 처리된다고는 것이고, 그로 인해 다음 출장 승낙을 기대하기가 어렵게 되었다는 것이다.

하지만 이러한 변화에 적응하지 못하고 전전긍긍하는 이들도 적지 않다. 디지털 기기나 소프트웨어 활용에 익숙지 않다면 온라인 화상 회의 등의 사용은 물론 낯선 상황에서의 업무 진행에서도 문제가 발생하고, 그로 인해 많은 일들이 취소 되거나 수정되기도 한다. 예로 학교라면 많은 학생들이 제대로 학교에 가서 수업을 받지도 못한 상태에선 값비싼 등록금의 가치를 느끼게 어렵게 되었고, 선생들도 온라인 강의에 노력한 수고가 학생들에게 온전히 전달되었는 지 확인하기 매우 어렵다.

짧은 학기를 가진 전문대학 등에서는 학생들이 제대로 학교를 가보지도 못한 채 졸업을 맞이하게 되는 정말 황당스러운 상황을 겪게 되었다. 물론 현재 상황으로 보아 4년제 대학교의 경우도 만만치 없는 상황을 맞고 있다. 이들에게 대학생으로서 시간은 어떤 의미로 생에 남을 지 안타깝다.

이러한 외부 활동 제약이 적지 않게 비용 지출을 줄이게 만들었다는 사실은 분명하다. 하지만 그 내용적 여부에 상관 없이 지속될 것이라는 사실에서 걱정과 우려를 하지 않을 수 없는 상황인 것도 분명하다.

빠른 맥으로 내 일상이 달라지지 않은 듯 ?

이미 한 세대를 지난 맥 사용자로서 애플의 제품 라인이 애플의 자체 마이크로프로세서, 즉 애플 실리콘으로 전환되고 있고, 또 출시된 M1 마이크로프로세서 탑재 모델의 성능에 대해-나의 예상과 달리-매우 우호적이다. 현재 나는 맥 미니 2018과 맥북프로 2011 13-인치를 사용하고 가끔씩 아내의 맥북프로 2019 13-인치를 몰래 사용하고 있다.

사실 맥 미니 2018이나 맥북프로 2019를 구입하게 된 것은 성능과 기능의 문제라기 보다는 맥북프로 2011에서 Mojave 운용체제의 지원가 공식적으로 중단되면서 대응하기 위한 방법이었다. 그렇다, 나의 GTD 시스템의 OmniFocus가 3.11 버전으로 업데이트되면서 Mojave 이상을 요구하기 시작했다. 그리고 OmniOutliner 5 마저 5.8 버전 이후부터 Mojave 이상을 요구했다.

그렇더라도 DevonThink와 Scrivener는 여전히 구형 OS에서도 잘 작동하기 때문에 버텨 볼 생각이었지만, 새로운 프로젝트 수행에 따른 시스템 구입 기회가 온 덕분에 마련할 수 있게 되었다.

그렇더라도 맥 미니 2018과 맥북프로 2019 모두 마이크로프로세서, CPU는 기본 사양으로 하고 여력의 비용으로는 메모리를 왕창 늘리고 주변기기 운용을 위한 여러 어댑터를 확보했다.

하지만 예전 같았다면 메모리나 내부 저장 장치 용량 보다는 우선 가장 빠른 CPU를 먼저 선정하고 나머지를 어떻게 구성하느냐로 고민했을 것이다. 언제부터인가 내게 있어 컴퓨터 시스템을 선택함에 있어 CPU는 가장 후순위로 밀려나게 되었다.

정확하게 언제인지는 기억나질 않지만 한참 워크스테이션이나 서버 도입의 최우선 기준이 ‘빠름’이었다. HP-UX 기반 워크스테이션과 서버를 사용하던 시절이었으니, CPU의 갯수가 늘어나거나 클럭 수가 한 단계 업그레이드 되는 건 거짓말 조금 보태서 거의 새로운 본체를 하나 구입하는 거랑 비슷한 수준이었다.

연구 개발의 성과는 빠른 CPU, 넘치는 메모리, 그리고 역시 빠른 3D 그래픽스 가속 장치에 의해 결정된다고 확신했다. 그리고 기대한 연구 성과가 부진한 탓을 컴퓨터 시스템의 성능 부족이나 필요한 소프트웨어의 부재로 변명했다.

하지만 명필은 붓을 탓하지 않는다고 했다는데, 어느 날 나의 연구 분야에서 세계 제일의 연구 성과를 내고 있는 미국의 모 대학의 P 교수 연구실을 보게 되었다. 사실 그의 명성에 비유하자만 연구실에 슈퍼 컴퓨터가 들어 앉아 있다고 해도 누구도 의문을 가지지 않을 수준이었다. 그러나 놀랍게도 그리고 당황스럽게도 그의 연구실에 있는 시스템은 출시된 지 한참이나 지금 더욱이 성능으로 보자면 도저히 이해할 수 있는 SGI와 SUN의 엔트리 레벨 워크스테이션들이 가득 했다. 정말 이게 다인지 눈을 의심했다.

사실 냉정하게 생각해보면 기하학적 이론에 기반한 3차원 비선형 곡면 모델링 연구에 고성능의 워크스테이션이나 서버가 반드시 요구되는 것은 아니다. 물론 있으면 좋겠지만 없어도 상관없다. 아무리 그렇더라도 내가 사용하는 하는 시스템에 비해 아마 열배는 느릴 것 같은 구형 시스템으로 그런 성과를 내고 있다는 것에 충격을 넘어 당황스럽고 황당하기까지 했다.

연구비는 차고 넘칠 것이니 일부러 그런 시스템을 여전히 사용하고 있다면 정말 그 자체로 충분하다는 것이다. 아니면 정말 학교 지하에 전용 슈퍼 컴퓨터를 숨겨 놓았는 지도 모르겠다.

어쨌든 이후 나의 빠른 컴퓨터에 대한 욕심 내지는 욕망은 일상의 우선 순위에서 다소 밀려나게 되었다. 물론 학교나 회사에서 시스템을 새로 구입하도록 해준다는 것에 대해 굳이 마다하지는 않았지만 개인적인 구입에 있어서는 빠른 성능 보다는 가능한 오래 사용할 수 있는 즉 업그레이드가 보장되는 제품 선택이 우선하게 되었다. 사실 비용적인 측면에서 보자면 후자가 더 비효율적일 수도 있다.

그래서 애플이 68K에서 PowerPC로 다시 X86으로 그리고 마침내 애플 실리콘으로 전환할 때에도 특별히 기대나 희망을 가지지 않았다. 더욱이 애플의 제품이나 아무리 속도나 빠르더라도 결구 지원 소프트웨어의 한계가 분명하니 결과는 예상하지 않아도 누구나 알 수 있었다. 물론 X86으로의 전환은 그 이전에 비해 매우 성공적이었다고 본다. 그러나 애플 실리콘으로 전환은 일단은 나쁘지 않은 선택이라고 하지만 최종 결과는 과연 어떻게 될지 누가 알겠는가.

빠른 업무 처리나 연구 개발의 완성을 위해 빠른 컴퓨터 시스템이 최우선적이라고 강변하는 이들을 보면 웃으면서 내 경험을 이야기해주기도 한다. 그리고 그 빠름으로 과연 오늘과 얼마나 다른 성과를 담보할 수 있는 지 스스로 한번 평가하는 시간을 가져보라고 한다. 충분 조건은 분명하지만 실제 필요 조건인지는 의문스러울 수 있을 것이다.

주변에서 오랜 맥 사용자인 내게 애플 새로운 M1 마이크로프로세서 그리고 곧 예고되는 M2 마이크로프로세서를 탑재한 맥 모델의 등장에 개인적으로 구입 의사에 대한 판단을 묻는 경우가 잦다. 그러면 한 마디만 해준다. 한/글(아래아 한글)이 현재 사용하고 있는 라이센스로 구동되지 않으니 직접 구입하셔야 합니다. 그리고 그 대응은 한결 같다.

클라우드 기반 서비스의 배신

주변에 클라우드 추종자가 적지 않다. 나 역시 개인 용도의 드랍박스와 마이크로소프트와 구글의 비즈니스 서비스를 사용하고 있지만, 그저 개인용 파일 공유나 백업 용도가 주라고 할 수 있다. 이제 업무 관련한 파일의 공유는 거의 클라우드 기반이 핵심 환경이다. 이제 클라우드 서비스 자체를 인식하지 못하고 있는 상황이다.

세 개의 클라우드 서비스 가운데 중심은 현재까지 마이크로소프트의 원 드라이브(OneDrive for Business)였다. 드랍박스의 프로페셔널 서비스를 포기한 이래, 용량 문제로 원 드라이브를 계속 사용해왔지만(각 1TB의 두 개 계정을 사용하고 있다), 의외로 자주 오류를 경험하고 있다. 전체적인 서비스 문제이기도 하고 자주 동기화 문제를 겪기도 한다. 얼마전에는 아예 동기화 자체가 한동안 수행되지 않기도 했다.

하지만 가장 큰 문제는 원 드라이브의 경우 새로 서비스가 시작되는 경우, 기존 파일에 대한 전체적인 동기화 점검을 매번 수행한다는 것이다. 거의 1TB에 달하는 용량의 동기화는 네트워크 상황에 따라 다르긴 하지만 짧게는 수 시간에서 길게는 하루를 넘기도 했다. 더욱이 Windows 환경과 macOS 환경 간의 동기화 문제도 만만치 않다.

이번에는 동기화 부재 사태가 몇 시간 단위에서 끝나지 않았다. 거의 하루를 넘어 지속되었고, 몇 번의 서비스 재시작이나 시스템 리부팅을 통해서도 해결되지 않아 결국 원 드라이브 재설치를 통해 다시 동기화를 수행했다. 하지만 동기화 자체 역시 매우 불안한 상태로 진행되고 있었다.

그래서 급하게 구글 G Suite 서비스의 구글 드라이브로 전환했다. 다만 순간 구글 드라이브와 백업 및 동기화 기능의 충돌로 당황하기도 했다. 사실 앞서 언급한 원 드라이브의 문제는 다른 클라우드 서비스에서도 종종 발생한다. 원 드라이브 못지 않게 사람을 괴롭히는 것은 역시 애플의 아이클라우드 동기화와 관련되어 있다. 구글 역시 앞서와 같은 문제로 계속 신경을 쓰게 만들고 있다. 역시 드랍박스만한 서비스가 없단 말인가?

사실 드랍박스를 사용하는 것도 나쁘지 않지만, 비용적 부담을 떠나 상대적으로 단순한 원격 파일 저장소로서의 기능이 핵심이다 보니 다른 환경적 서비스와는 차이가 있어 전환후에는 결국 다른 불편한 문제가 생길 것이 뻔하다 보니. 어느새 파일 저장소 이상의 활용 범위로 클라우드 서비스 환경이 확장되어 버린 탓인 것 같다.

이제 대부분의 주요한 서비스도 클라우드 기반으로 진화하고 확장하고 있다. PDM/PLM은 물론 3D CAD까지 클라우드 기반으로 출시되고 있는 상황이다. PLM이 클라우드 기반으로 운용된다면 다른 서비스는 굳이 언급할 필요가 없을 것이다. 하지만 ERP나 PDM/PLM이 클라우드로 운용되는 동안 네트워크 연결 혹은 속도 문제가 발생하면 어떤 사태가 발생할 지 알 수 없다. 물론 이에 대한 대응 조치를 위한 서버나 서비스를 별도로 마련할 수도 있지만, 결국 네트워크 연결이 끊어지면 어떤 경우라도 최악이다.

생각해보니 클라우드 서비스가 주는 효용성에 비례하여 문제 발생에 따른 충격은 절망적인 수준이었다. 클라우드 서비스 역시 어딘 가에 있을 오프라인 서버에 기반하고 있을 것이다. 물론 클러스터로 연결되어 서비스 중단 사태는 거의 없을 것이라고 한다. 물론 그 수치적인 값은 현실적으로 무중단에 가깝다. 그러나 완벽하지 않으니 그 불완전함에 언제 내가 닥칠 지 모른다.

결국 클라우드 서비스의 배신이 두려워 둘 이상의 클라우드 서비스를 사용하거나 따로 서버를 마련해서 백업하는 모순적 상황이 발생하고 있다. 답이라고 해서 항상 정답은 아닌 것 같다. 새로운 기술이 현재의 문제를 해결하는 그저 작은 시도일 뿐이 분명하다.