vistalog

하루 업무의 60%가 어제와 똑같은 반복이라면, 그 시간을 통째로 돌려받을 수 있다면 어떨까요. 시리는 단순한 음성 비서 업그레이드가 아닙니다. 앱 인텐트(App Intents) 프레임워크를 기반으로 앱 내부 기능을 직접 호출하는 구조로 재설계되었고, 저는 이걸 실제로 써보고 나서야 그 차이를 실감했습니다. 앱 인텐트란 무엇인가, 그리고 왜 이번이 다른가 앱 인텐트(App Intents)란 앱이 자신의 특정 기능을 시스템에 등록해 두는 일종의 명세서입니다. 쉽게 말해 앱이 "저는 이런 동작을 할 수 있습니다"라고 시리, Spotlight, 위젯 같은 시스템 경험에 미리 신고해 놓는 구조입니다. iOS 16부터 도입된 이 프레임워크는 기존의 SiriKit보다 훨씬 유연하고, 서드파티 앱도 같은 방식으로 참여할 수 있다는 점에서 의미가 큽니다. 기존 시리가 "타이머 맞춰줘", "전화 걸어줘" 수준에 머물렀다면, 앱 인텐트 기반의 시리는 일부 상황에서는 앱의 상태와 맥락을 반영한 명령 실행이 가능해지고 있습니다. 예를 들어 파일 정리 명령 하나가 단축어(Shortcuts) 또는 자동화 설정과 결합하면 여러 앱 동작을 연결해 실행할 수 있습니다. 제가 처음 이 구조를 이해했을 때 솔직히 이건 예상 밖이었습니다. 단순히 "더 똑똑해진 시리"가 아니라 운영 체계 자체가 바뀐 느낌이었습니다. 애플이 공식 문서에서 밝힌 지원 범위도 상당합니다. App Intents 프레임워크는 iOS 16.0 이상, macOS 13.0 이상, watchOS 9.0 이상, visionOS 1.0 이상을 포함한 전 플랫폼을 커버합니다( 출처: Apple Developer Documentation ). 하나의 앱 인텐트 구현이 아이폰, 맥북, 애플워치에서 동시에 작동하는 구조이니, 디바이스를 넘나드는 자동화가 가능해지는 것입니다. 화면 인식이 바꾼 업무 흐름, 직접 써본 이야기 화면 인식(Onscreen Awa...

협업 툴을 바꿀 때마다 온보딩에만 며칠이 사라진 경험, 한 번쯤 있지 않으신가요? 저는 그 고통을 꽤 여러 번 반복했습니다. Asana, Notion, Trello까지 거쳤는데 결국 팀이 제대로 쓰지 않으면 다 소용없더라고요. 그러다 반쯤 포기하는 심정으로 꺼낸 게 애플 미리 알림이었습니다. 당시 저는 콘텐츠 제작 중심의 프로젝트를 프리랜서 1~2명 포함해 4인 팀으로 운영하고 있었고, 유료 협업 툴을 따로 쓸 여건이 안 됐어요. 그렇게 시작한 게 6주짜리 프로젝트였는데, 예상보다 일찍 마무리되면서 처음으로 "이게 마지막 툴이어야겠다"는 확신이 생겼습니다. 칸반보드, 미리 알림으로 정말 구현이 될까요? 솔직히 말하면 처음엔 저도 반신반의했어요. 미리 알림은 장보기 목록이나 쓰는 앱 아닌가 싶었거든요. 그런데 막상 세팅을 마치고 팀원들한테 공유하고 나서 일주일 만에 생각이 바뀌었습니다. 칸반(Kanban)이란 작업의 상태 변화를 시각화하는 방법론입니다. 단순히 할 일을 나열하는 게 아니라, '준비 → 진행 중 → 완료'처럼 흐름(Flow)을 눈으로 보이게 만드는 것이 핵심입니다. Trello나 Notion이 익숙하신 분이라면 바로 떠오르는 그 보드 형태 맞습니다. 미리 알림의 섹션(Section) 기능은 iOS 13부터 존재했고, 열(Column) 보기 방식은 이후 업데이트에서 강화되어 현재는 iPhone, iPad, Mac 모두에서 안정적으로 사용할 수 있습니다. 보기 옵션을 '열(Column)'로 바꾸는 순간, 섹션들이 나란히 펼쳐지면서 칸반 보드 구조가 그대로 나왔습니다. 처음 봤을 때 생각보다 그럴싸해서 저도 좀 놀랐어요. 많은 분들이 이걸 '칸반 모드'라고 부르는 이유가 여기 있습니다. 실제로 섹션을 '준비', '진행 중', '검토', ...

생산성 도구라면 무조건 Notion이라고 저도 한동안 그렇게 믿었습니다. 그런데 몇 달 전, 정교하게 구축해둔 Notion 대시보드를 닫고 Apple Notes를 열었을 때, 오히려 일이 더 빨리 끝났습니다. 이 글은 두 도구 중 어느 쪽이 무조건 옳다고 말하려는 것이 아닙니다. 프로젝트의 크기와 팀의 맥락에 따라 답이 달라진다는 것, 제가 직접 겪으면서 느낀 이야기를 풀어봅니다. 노션 열풍 속에서 생긴 의문, 그 배경 Notion이 생산성 커뮤니티에서 주목받기 시작한 건 관계형 데이터베이스(Relational Database) 기능 때문이었습니다. 관계형 데이터베이스란 서로 다른 정보 묶음을 논리적으로 연결하여 한 화면에서 통합 관리할 수 있는 구조를 말합니다. 예를 들어 프로젝트 목록과 팀원 역할, 마감일을 하나의 뷰에서 엮어서 볼 수 있다는 점이 당시에는 꽤 매력적으로 느껴졌습니다. 저도 팀 프로젝트를 시작할 때마다 "무조건 Notion으로 해야지"를 외치던 시기가 있었습니다. 칸반 보드(Kanban Board), 그러니까 업무 진행 상태를 카드 형식으로 시각화하는 방식을 구성하고, 갤러리 뷰로 콘텐츠를 정리하고, 자동화 규칙까지 연결하면 뭔가 대단한 시스템이 완성된 것 같은 기분이 들었습니다. 문제는 그 기분이 실제 업무 속도와는 별개였다는 점입니다. 팀원 중 한 명이 조심스럽게 꺼낸 말이 아직도 기억납니다. "Notion 유지보수 하느라 시간을 너무 많이 쓰는 것 같아요." 그 말을 듣고 나서야, 저도 주말에 Notion 시스템을 '완성'하는 데 몇 시간을 쏟고 있다는 걸 깨달았습니다. 실제로 주말마다 2~3시간씩 시스템을 정리하는 데 시간을 쓰고 있었습니다. 시스템을 위한 시스템을 만들고 있었던 셈입니다. 이런 현상을 생산성 연구자들은 메타워크(Meta-work)라고 부릅니다. 메타워크란 ...

한 주가 끝날 때마다 "이번 주도 뭔가 엄청 바빴는데, 뭘 했지?" 싶은 기분이 드신 적 있으신가요. 저는 꽤 오랫동안 그 질문에 시원한 답을 못 했습니다. 캘린더는 빽빽했고, 알림은 쉴 새 없이 울렸습니다. 그런데 막상 한 주 치 결과물을 돌아보면 공허했습니다. 캘린더를 단순한 일정판이 아니라 진짜 생산성 도구로 다시 설계하기 시작한 것이 계기가 됐습니다. 당시 하루 평균 10개 이상의 일정과 알림을 처리하는 환경이었고, 대부분이 회의와 메시지 대응으로 채워져 있었습니다. 색상 코딩, 보기 좋은 그림 말고 의사결정 도구로 처음에 캘린더 색상을 접했을 때는 솔직히 그냥 꾸미기 기능이라고 생각했습니다. 빨간색, 파란색, 초록색으로 블록을 채워 넣으면 일정판이 예뻐 보이는 것 그 이상도 이하도 아닌 것처럼 느껴졌습니다. 실제로 색에 아무 의미도 두지 않고 일정을 넣다 보니, 꽉 찬 캘린더에 휘둘리면서도 정작 한 주를 마무리하고 나면 "결과물이 어디 갔지?" 하는 의문만 남았습니다. 전환점이 된 건 색상 코딩(Color Coding)을 시스템으로 정의하면서부터였습니다. 색상 코딩이란 캘린더의 각 일정 블록에 업무 성격에 따라 고유한 색을 부여하는 방법입니다. 저는 먼저 '집중 업무'와 '단순 지원'이라는 두 축으로 색을 나누고, 거기서 개인 업무, 팀 업무, 프로젝트 업무를 구분하는 색들을 정의했습니다. 분류된 색으로 채워진 캘린더를 다시 봤을 때, 제가 실제로는 급박하고 중요한 일보다 굳이 없어도 됐을 일들에 대부분의 시간을 쓰고 있었다는 걸 눈으로 확인할 수 있었습니다. 단, 처음에 야심차게 색을 여섯 가지 이상으로 나눴다가 낭패를 봤습니다. 일정을 등록할 때마다 "이게 무슨 색이었더라?"를 고민하게 되더니 결국 시스템 자체를 안 쓰게 됐습니다. 색상 체계는 최대한 심플하게 가져가야 유지됩니다....