애증의 컨플루언스

컨플루언스 위키의 존재를 처음 알게 된 시점으로부터는 이제 10년이 넘게 지났고 또 개인용으로 컨플루언스 위키를 사용할 결정을 내리고 컨플루언스 클라우드 프리미엄 서브스크립션을 사용하기 시작한 지도 이제 몇 년이 지났습니다. 그 이전까지 사용하던 도쿠위키와 비교해 장단점이 확실한데 컨플루언스가 원하는 대로 잘 동작할 때는 장점이 뚜렷하지만 원하는 기능을 지원하지 않을 때는 단점이 너무 뚜렷하게 드러나곤 합니다. 종종 컨플루언스 클라우드에서 제공하지 않는 기능을 사용하고 싶어 뭔가 시도하기를 반복하다가 자주 마스토돈에 화를 내다 보니 컨플루언스 위키를 사용하며 지금처럼 고통 받기 보다는 요구사항을 만족하는 도구를 만들어 보면 어떻겠느냐는 의견을 듣고 한번 생각해봤습니다. [계속]

현대의 새로운 글쓰기에 부정적이지 않음

이전에도 여러 가지 일은 오직 사람이 제대로 해 낼 수 있다고 생각해 왔습니다. 가령 바둑 두기, 그림 그리기, 언어를 받아 쓰기, 언어를 번역하기, 동식물을 구분하기, 자동차를 운전하기, 매장에서 주문 받기 등이 있는데 이 목록은 생각할 수록 굉장히 길게 쓸 수 있을 것 같습니다. 그런데 시간이 흐르면서 기계가 이런 일 중 생각보다 많은 일을 해낼 수 있음을 알게 되었습니다. 처음에 기계의 도움을 받아 아주 무거운 물건을 들어 올리거나 아주 멀리 까지 보내거나 사람을 아주 빨리 이동 시킬 때는 지금처럼 관심을 많이 받지는 않았던 것 같습니다. 물론 아예 좀 더 과거로 돌아가 산업혁명 시대에 방직 기계에 의해 일자리를 잃은 사람들이나 자동차 앞에서 적색 깃발을 든 사람이 거리를 걸어야 했던 시대에도 어쩌면 지금과 비슷한 수준의 관심을 받았을 수도 있습니다. [계속]

다이어그램 작성 도구 머메이드 영업

지난번에 복잡한 그림을 이번에는 어떤 도구를 사용해서 그리면 좋을지 고민하다가 머메이드를 추천 받아 사용했었습니다. 그 때 작업에도 머메이드를 유용하게 사용했을 뿐 아니라 그 후에도 머메이드로 그리기 어려운 몇 가지 상황을 제외하고 어지간한 다이어그램은 머메이드로 그리게 됐는데 사용에 익숙해짐에 따라 여러 모로 생산성이 높아졌습니다. 지난번 머메이드 사용기에 이어 오늘은 머메이드를 사용할 때 회의 상황에서 회의 진행과 동시에 머메이드로 그림을 그려 진행 도중에 바로바로 공유해 생각을 확인하고 의견을 정리하며 회의 종료와 동시에 이 모든 것을 한 번에 공유할 수 있는 민첩한 사용 시나리오를 소개하겠습니다. [계속]

엑셀 수식 복잡도 통제

어느 날 타임라인을 보다가 무서운 글을 봤습니다. 정확히는 글이 무섭다기보다는 그림이 무서웠는데 웃기긴 하지만 또 한편으로는 마냥 웃을 수는 없었는데 이 그림은 단순한 형식에 근거해 약간 과장된 모양이고 실제 일하는 데는 이보다 복잡도는 더 높고 길이는 비슷하거나 약간 짧은 수식이 종종 사용되기 때문입니다.

프로그래머가 아니어서 프로그래머들이 코드를 작성할 때와 비슷한 느낌일지 잘 모르겠지만 엑셀 수식은 분명 만들 때는 수식의 구성을 잘 이해하고 제한을 잘 파악하고 수식의 동작을 잘 설명할 수 있지만 시간이 조금만 지나면 이 수식은 그저 의미 없는 셀과 사칙연산자와 함수와 괄호의 의미 없는 나열에 불과해집니다. 수식은 분명 강력한 도구이기는 하지만 복잡도 관리에 실패하면 유지보수가 불가능해지고 심지어는 결과의 의미를 파악하지 못하거나 결과가 올바른지 확인할 수 없게 될 수도 있기 때문에 복잡도를 잘 관리해야 합니다. 오늘은 이 이야기를 해보겠습니다. [계속]

개인 작업에서 만들어진 바이너리 파일 버전관리 방법 소개

아무리 위키를 편하게 사용하고 있어도 컴퓨터를 사용하며 생산한 모든 정보를 위키 모양으로 저장할 수 있지는 않습니다. 표만 생각해도 위키로 만들 수 있는 표는 이전 시대에 비해서는 아주 조금 더 정교해졌지만 여전히 셀을 조금만 병합하면 편집할 수 없는 상태에 빠지기 쉽습니다. 또 작은 플로우차트 하나만 넣으려고 해도 위키만으로는 아무 것도 할 수 없습니다. 더군다나 현대에는 크로스플랫폼을 지원한다며 웹 기반으로 동작하는 앱이 많아 작업 결과를 문서 중간에 첨부하기 쉽지 않습니다. 가장 전통적인 접근은 그림으로 만들어 붙여 넣는 거지만 이러면 나중에 편집하기 어려워지고 또 노션이나 컨플루언스 같은 웹 기반 도구는 같은 웹 기반 앱의 작업 결과를 임베드 할 수 있기는 하지만 썩 안정적으로 동작하지 않기도 합니다. [계속]

스타일 기반의 문서작성

적어도 제가 보고 있는 인터넷 상의 타임라인에는 대략 반 년 정도 쿨타임이 찰 때마다 국내에 가장 널리 사용되는 것처럼 보이는 두 가지 위지윅 워드프로세서에 대한 이야기가 돌아오곤 합니다. 한글 워드프로세서는 한글을 입력하고 한국에서 문서를 만들고 사용하는데는 더할나위 없이 훌륭한 도구이지만 그 문서를 여러 사람들에게 공유하고 정보를 주고 받는 데는 별로 훌륭하지 않은 것 같아 보입니다. 이런 도구를 공공기관이나 학교에서 적극적으로 사용하고 문서를 필요로 하는 모든 사람들이 같은 도구를 사용하고 있으리라고 가정하는 자세가 여러 사람들을 불편하게 만들고 있습니다. 불편하다고 하면 문제가 작은 것 처럼 보이는데 사실상 정보 접근을 제한하고 있다고 봐야 합니다. [계속]

머메이드 사용기

개인적으로 복잡한 다이어그램의 등장을 좋지 않은 신호로 여깁니다. 설명하는데 다이어그램이 필요하다면 그 다이어그램은 최대한 단순한 모양이어야 합니다. 다이어그램이 복잡해진다면 그리는 사람이 다이어그램/을 통해 설명하려는 주제를 잘 이해하지 못할 수 있습니다. 또 설명 받는 사람에게 주제를 충분히 잘 이해 시키기 어려워진다는 의미이기도 합니다.

항상 다이어그램을 웬만하면 피하고 굳이 그려야 한다면 가장 간단한 모양을 유지하려고 노력했습니다. 다이어그램이 복잡해진다면 한번에 너무 많은 주체가 다이어그램에 출연하고 있거나 서로 다른 레벨의 주제를 같은 다이어그램으로 설명하려고 하고 있을 수 있습니다. 그래서 설명할 주제를 나누고 다른 수준에 침범하지 않도록 주의하곤 합니다. [계속]

마이크로블로그는 긴 글 공유에 적합하지 않을 것 같음

지난번 버퍼를 오토메이션으로 대신한 사례를 소개하면서 일주일에 다섯 번 씩 블로그 글을 트위터와 마스토돈에 공유하는 실험에 대해 설명했습니다. 미리 글을 작성해 버퍼라는 서비스를 통해 스케줄을 설정해 놓으면 신경 쓰지 않아도 스케줄에 따라 일주일에 다섯 번 글을 공유합니다. 최근 버퍼가 마스토돈을 지원하지 않아 처리 방법을 고민하다가 버퍼 서비스 사용을 중단하고 아이폰 오토메이션을 만들어 공유하기 시작했습니다. 그러다가 문득 현대에 글을 작성하는 일 자체가 의미 있는지, 그리고 트위터나 마스토돈같은 마이크로블로깅 서비스를 통해 블로그 글을 공유하는 행동에도 의미가 있기는 한지 생각해보게 됐습니다. [계속]

노션을 위키처럼 사용하지 마시오

트위터와 마스토돈을 통해 문서에 특정 리비전을 가리킬 방법이 필요해요라는 이전에 쓴 글을 공유했습니다. 지난 몇 년 사이에 사용하던 미디어위키, 도쿠위키, 컨플루언스 같은 도구에서는 한 문서의 이전 버전을 주소로 가리킬 수 있었습니다. 그래서 한 문서에서 다른 문서를 인용할 때 문서의 특정 버전을 인용할 수 있었는데 위키에서 문서는 계속해서 수정되는 것이기 때문에 인용하는 시점에는 문서에 있었던 내용이 이후 시간이 지나 없어졌을 수 있습니다. 그러면 이전 문서가 잘못된 인용을 하게 됩니다. 그래서 문서의 특정 버전을 주소로 가리킬 수 있으면 이후 문서가 수정되더라도 잘못된 인용을 할 가능성이 낮아집니다. [계속]

개인 위키에 컨플루언스 추천해요

이전에 내가 컨플루언스를 싫어하는 이유 같은 글을 쓰긴 했지만 여전히 개인 위키와 웹사이트에 컨플루언스를 사용하고 있고 앞으로도 꽤 오랫동안 사용할 것 같습니다. 마음에 안 드는 곳이 없는 것은 아니지만 다른 솔루션을 생각하기 쉽지 않습니다.

트위터 타임라인을 지켜보면 가끔 개인 위키를 만들고 싶은 분들의 글을 보게 되는데 여러 위키가 물망에 오르며 종종 여기에는 컨플루언스도 지나가곤 했습니다. 하지만 컨플루언스는 기업용 도구라는 의식이 강해서인지 아주 잠깐 고려 대상에 올라왔다가 순식간에 사라졌습니다. 개인적으로는 이 상황이 좀 답답했습니다. 개인적으로 컨플루언스를 2년 이상 개인 위키와 웹사이트를 운영하는데 사용해 왔고 규모가 큰 팀에서도 꽤 오래 사용해 왔습니다. 이 도구가 규모가 큰 그룹이 사용할 것을 생각하고 만들어진 것은 맞지만 개인이 사용하기에도 괜찮은 장점이 있습니다. [계속]

파일시스템에 의존하지 않는 문서작성환경

트위터 타임라인에서 프로그래밍 환경이 파일시스템으로부터 분리되면 좋지 않겠느냐는 글을 보았습니다. 저는 직접 코드를 작성하는 일을 하는 사람은 아니지만 문득 매일 작성하는 문서 거의 대부분이 파일시스템에 저장되지 않는다는 사실을 생각했습니다. 전통적인 개발환경은 파일시스템에 뿌리를 두고 있고 현대에도 이 환경 자체는 크게 변하지 않은 것 같습니다. 그런데 문서 작성은 그 기반이 상당히 많이 바뀐 것 같습니다.

오래 전에 개발하며 남긴 자료를 보니 문서 파일이 많습니다. 작업을 시작하기 전에 주요 요구사항을 기입한 텍스트 파일부터 시작해서 기획서 워드 파일, 기획서에 포함된 드로잉을 만드는데 사용한 파워포인트나 비지오 파일, 기능을 개발하면서 데이터를 주고 받는데 사용한 엑셀 파일 등. 작업을 수행하는데 여러 ‘파일’이 필요했고 이들을 한 번에 찾을 수 있도록 관리해야 했는데 파일을 생성하는 프로그램에 따라 서로 다른 경로 규칙을 사용해 파일을 관리하기 어려운 상황이 생기기도 했습니다. 가령 어떤 앱은 ‘내 문서’ 디렉토리에 파일을 저장하려고 하고 다른 누군가는 ‘내 문서’ 하위에 그 프로그램 혼자 사용하는 경로에 저장 하려고도 했습니다. 또 다른 누군가는 아예 드라이브 루트에 디렉토리를 만들려고 하기도 했구요. [계속]

왜 컨플루언스에 같은 이름 파일을 올리면 문제가 생길까

이전에 컨플루언스와 노션을 사용하며 서로의 특징을 비고한 적이 있습니다. (내가 노션을 싫어하는 이유, 내가 컨플루언스를 싫어하는 이유) 개인적으로 이런 도구들을 위키의 한 종류라고 보고 도구의 특징을 쉽게 받아들여 왔습니다. 하지만 요즘 세상에 이런 도구가 위키라는 개념으로부터 시작된 문서 관리 도구라고 모두가 받아들이기를 기대하는 것은 올바르지 않다는 생각이 들었습니다. 도구의 특징을 설명하기 위해서는 규모가 큰 위키의 한 종류라고 대강 설명하는 대신 도구의 목적과 특징을 직접 설명하는 편이 낫습니다. 컨플루언스가 전통적인 위키의 특징으로부터 시작한 동작을 현대에도 그대로 유지하고 있어 불편한 점들이 있는데 이 중 당장 생각나는 두 가지를 설명하겠습니다. [계속]

위키에서 같은 페이지 안에서 관계 있는 항목에 의미를 부여하는 요구사항

개인 할일관리에 지라를 사용하는 요령을 공유한 적이 있습니다. 지독하게 게으르지만 조금이라도 덜 게을러지기 위해 생각나는 여러 일들을 잘게 쪼개 할일로 만들어 놓고 하나하나 수행하고 있습니다. 트렐로로도 똑같은 효과를 낼 수 있습니다. 다만 지라는 여러 동작을 입맛에 맞게 바꿀 수 있었기 때문에 보기에 아름답지 않고 또 사용하기에 좀 더 불편함을 감수하고 지라를 선택했습니다.

내가 컨플루언스를 싫어하는 이유에서 문서 사이에 링크를 건 의미를 입력할 수 없다는 점에 불만을 표했는데 지라에서는 태스크 사이에 몇 가지 관계를 입력할 수 있어 주제 사이에 단순한 연결 뿐 아니라 연관관계를 기록하고 이후 참고할 수 있어 좋았습니다. 경제적 여건 상 컨플루언스에만 돈을 내고 있어 지라에 큰 이미지나 비디오를 첨부해야 하는 상황에는 지라 이슈에 대응하는 컨플루언스 페이지를 생성해 사용하고 있습니다. [계속]

구독 서비스를 가계부에 기록할 때 하는 고민

유료 가계부 서비스인 후잉을 꽤 오래 사용하고 있습니다. 처음에는 제 요구사항을 어느 정도 만족하는 다른 서비스가 없었습니다. 후잉이 유일했습니다. 오랜 시간이 흐르며 요즘 세상에는 신용카드 회사나 전자상거래 사이트를 직접 읽어 소비를 자동으로 기록하고 분류하고 또 통계를 내 주는 서비스도 있는 것 같습니다. 하지만 오랜 기간에 걸친 경로 의존성으로 인해 함부로 가계부 서비스를 갈아탈 생각이 들지는 않습니다. 결정적으로 세월이 흐르며 여러 가계부 앱이나 서비스가 나타났다가 사라지는 동안에도 우직하게 유지 보수 되고 있어 크게 신뢰하고 있습니다. [계속]

위키와 함께 동작하는 데이터베이스에 대한 요구사항

이전 문서 아무데나 가리킬 수 있는 URI에 대한 요구사항에 이어 오늘은 위키에 통합되어 동작하는 데이터베이스에 대한 요구사항을 생각해봤습니다. 노션 데이터베이스 기능을 굉장히 부러워 했습니다. 내가 알고 있는 그 데이터베이스가 노션과 잘 통합되어 있어 아무데서나 원하는 모양으로 불러올 수 있고 데이터베이스 자체만으로도 독립적으로 입출력 할 수 있습니다. 여러 페이지에서 데이터베이스의 서로 다른 레코드나 값 하나를 불러와 즉시 인용할 수도 있고 간단한 계산을 할 수도 있습니다.

이전에 도쿠위키를 사용하던 시대에는 struct 플러그인이 비슷한 역할을 했으나 기능이 한참 모자랐습니다. 특히 페이지에서 데이터베이스 상의 레코드 하나를 가져올 수는 있었지만 값 하나를 불러와 인라인에 바로 사용할 수는 없었습니다. 노션의 이 기능 하나만으로도 노션으로 이전을 심각하게 고민할 정도였습니다. [계속]

문서 아무데나 가리킬 수 있는 URI에 대한 요구사항

노션과 컨플루언스를 번갈아 쓰며 아쉬운 점 중 하나는 노션에는 문서 아무데나 가리킬 수 있는 URI 체계가 있지만 컨플루언스에는 없다는 점입니다. 노션은 페이지 하위의 블릿포인트나 문단이나 임베드 각각이 모두 블록이라는 단위로 구분됩니다. 페이지 주소 하위에서도 블록 각각에 대한 주소를 얻을 수 있습니다. 다른 페이지에서 특정 페이지를 인용할 때 페이지 자체를 인용하는 대신 페이지 하위의 블록 주소를 인용해 링크를 클릭할 때 정확한 위치로 보낼 수 있습니다. 반면 컨플루언스는 페이지 하위에서는 헤더에만 주소만 인용할 수 있습니다. [계속]

문서를 어떤 도구로 써야 할까

오늘(2022년 8월 15일)을 기준으로 한 최근 제 트위터 타임라인은 특정 업계에 이력서를 어떤 파일 포멧으로 제출할 지에 대한 이야기로 따뜻해진 상태입니다. 개인적으로는 이미 정답이 있는 주제가 이렇게 타임라인을 따뜻하게 만들 일인가 싶지만 어떤 분들 입장에서는 아직 정답을 찾아야 하는 문제일지도 모릅니다. 그래서 오늘은 제가 생각하는 이 문제, ‘문서를 어떤 도구로 써야 할까’를 이야기해 보겠습니다.

문서는 사용될 환경과 문서를 사용할 사람에 따라 구분할 수 있습니다. 문서를 볼 환경에 따라 종이에 인쇄해 페이지 단위로 볼 것을 고려한 전통적인 문서, 그리고 모니터를 통해 아래에서 위로 스크롤 하며 볼 것을 고려한 문서가 있습니다. 또 문서를 볼 사람에 따라 문서를 공유 받은 사람의 환경에서 보여야만 하는 문서가 있습니다. 문서를 작성하는 근본적인 목적은 정보의 기록과 공유이기 때문에 문서를 공유 받아 읽을 환경과 사람을 고려해야만 합니다. [계속]

위키에서 문서 이름과 위치 변경은 히스토리에 포함되어야 할까?

컨플루언스 위키에서 문서 제목을 바꾸다가 문득 든 질문입니다. 위키에서 문서 이름과 위치 변경은 히스토리에 포함되어야 할까요? 오래 전에 사용하던 도쿠위키에서는 문서 이름이나 경로를 바꾸면 문서 히스토리에 나타났습니다. 이때부터 문서 이름과 경로 역시 문서의 일부라고 생각했습니다. 컨플루언스에는 문서 이름과 경로를 바꿔도 히스토리에 나타나지 않습니다. 히스토리에는 오직 문서 내용 변경사항만 남는데 이 차이는 뭘지 생각해봤습니다. [계속]

문서에 특정 리비전을 가리킬 방법이 필요해요

노션을 사용하면서 여느 위키에서 흔히 찾아볼 수 있는 문서의 이전 리비전을 주소로 가리킬 수 있는 기능이 없다는데 당황했습니다. 이전 리비전을 가리킬 수도 없고 히스토리 페이지를 가리킬 수고 없었습니다. 개인적으로 문서는 계속해서 변하기 때문에 어느 시점에 다른 문서 내용을 발췌한 문서를 작성하면 시간이 흐름에 따라 발췌한 부분이 없어질 수 있습니다. 그러면 미래의 어느 시점에 이 문서는 잘못된 내용을 보여주게 됩니다. 그래서 개인적으로는 다른 문서를 가리킬 때 참고로 그 문서의 리비전을 가리키는 링크를 포함해 놓곤 하는데 노션에서는 이렇게 할 수 없어 불안한 느낌이 들었습니다. [계속]

계층형 위키를 쓰며 느끼는 관리방법의 충돌

어느 날 링크 기반으로 사용하던 문서를 계층형으로 정리해 달라는 요청을 수행하다가 문득 모든 문서가 같은 계층에 있고 서로의 링크만으로 관리되던 클래식한 위키 사용 방식에 익숙했는데 현대의 위키 소프트웨어에 문서를 계층으로 구성하는 기능이 들어가면서 링크와 계층구조를 함게 관리해야 하는 어려움이 생긴 것 같다는 생각이 들었습니다. 지금은 주로 사용하는 컨플루언스와 노션 모두 문서를 계층으로 관리할 수 있지만 오래 전부터 위키를 사용하던 습관 때문에 계층을 어느 정도 따르기는 하지만 문서가 어느 계층에 속하는지에 신경쓰기 보다는 문서의 링크가 있으면 문제 없다고 생각해 왔는데 제 생각과 계층에 따른 정리 방법을 각각 생각해 보려고 합니다. [계속]

위키에 오래된 리비전에 의미가 있을까?

업무용으로 노션을 사용하면서 엔터프라이즈 섭스크립션을 제외한 나머지 모든 요금제가 히스토리를 이전 30일어치만 유지하는 것을 보고 상당히 당황했었습니다. 처음에는 이것이 과연 올바른 동작인가 하는 생각을 했는데 이전 위키 같은 문서관리도구에서 이전 리비전의 의미가 무엇인지 생각해보고 또 리비전에 대한 생각을 정리할 계기가 되었습니다. 노션의 리비전 관리 동작을 잠깐 설명하면 월 20달러 짜리 엔터프라이즈 섭스크립션을 제외한 나머지 섭스크립션에서는 히스토리를 30일 까지만 보관합니다. 반대로 말하면 지난 30일 이전 히스토리는 사라집니다. 퍼스널 프로나 팀 버전은 최대 월 8달러를 내는데 이 요금제에서는 30일 이전 리비전에 영구적으로 접근할 수 없습니다. [계속]

개인 할일관리 사례

트위터에서 할일목록을 관리하는 이야기를 보고 제 할일관리 스타일을 공유해봐도 재미있지 않을까 하는 생각을 했습니다. 트위터에서 이런 팁을 공유해 주시는 분들 상당수가 엔지니어셔서 요령을 따라하려고 해도 쉽지 않거나 다른 직군 입장에서는 잘 와 닿지 않는 부분도 있었습니다. 그래서 오늘은 제가 할일을 관리하고 기록하는 방식을 공유해 보려고 합니다. 다만 회사 할일을 공개하면 회사와 계약을 깨게 되니까 ‘완전히 똑같은’ 방식으로 관리하고 있는 제 개인 할일을 기준으로 설명하겠습니다. [계속]

내가 컨플루언스를 싫어하는 이유

지난번에 '내가 노션을 싫어하는 이유'를 소개한 적이 있습니다. 비슷한 시기에 트위터를 통해 컨플루언스를 개인적으로 활용하는 이유와 장단점을 소개한 적이 있는데 시간이 지나고 보니 이 상태로 두면 균형이 잘 안 맞는다는 생각이 들었습니다. 어쩔 수 없이 노션도 컨플루언스도 적극적으로 사용하는 입장에서 한쪽의 단점만 이야기해 놓고 아무것도 안 하고 있는 건 문제가 있다는 생각이 들었습니다. 그래서 오늘은 제가 컨플루언스를 싫어하는 이유를 소개합니다. [계속]

내가 노션을 싫어하는 이유

지난달 초 트위터에 노션을 싫어하는 이유 몇 가지를 적은 적이 있습니다. 며칠 전 사람들이 왜 노션을 싫어하는지 모르겠다는 다른 트위터 글을 언듯 지나쳤기 때문입니다. 시간이 흘러 원문을 찾을 수 없게 됐지만 여전히 노션은 마음에 안 들고 노션을 쓸 때마다 짜증이 솟구치는데 왜 노션을 이렇게 싫어하는지 그 이유를 좀 정리하려고 합니다. 일단 제 배경을 잠깐 설명 드리면 지금은 업무용으로는 노션을, 개인용으로는 컨플루언스를 사용하고 있습니다. 거의 낮에는 노션, 밤에는 컨플루언스 같은 느낌입니다. 대규모로 사용할 수 있는 두 제품을 비교하며 사용하는 입장입니다. 하지만 둘 중의 하나를 선택해야만 하는 상황이 온다면 당연히 컨플루언스를 선택할 입장에서 하는 이야기임을 염두해 주세요. [계속]

개인 할일관리에 지라 사용

이전에 몇몇 할일 관리 앱을 전전했습니다. 한동안흔 OmniFocus를 써보기도 하고 애플 생태계에서는 거의 표준에 가까운 Things를 기웃거리기도 했습니다. 이 앱들은 GTD 기반의 앱들이었고 제 할일의 중요도와 시급성의 상당부분을 제 스스로 결정할 수 없는 상황에서 활용하기에 좋은 방법이라고 생각했습니다. 그래서 이런 앱들을 기웃거렸습니다. 또 한동안은 윈도우 머신에도 동기화되길 원했기 때문에 구글 제품이나 마이크로소프트 제품을 사용해보기도 했습니다. 당연히 이 각각의 방법에는 모두 장단점이 잇었고 제 요구사항을 잘 수용하는 앱을 찾기는 아주 어려웠습니다. [계속]

글 목록