툴과 사고의 전환 – 통합형 실무가로 Ch.2 | EP.03
그것은 일을 명확히 설계하고,
흐름을 가시화하며,
성과를 가속화하기 위한 도구다.
Chapter 1. 단절된 커리어, 다시 연결하기(4회)
Chapter 3. 시간, 성과, 몰입의 커리어 설계(5회)
“이제 Notion으로 정리하고 있어요.”
“Obsidian에 다 쌓아두고 있죠.”
“ChatGPT는 업무에 정말 많이 써요.”
이 말을 들었을 때, 처음엔 ‘이 사람은 일 잘하겠다’는 기대가 들었다.
하지만 막상 함께 일해보면,
생각보다 툴 사용은 많지만 결과물은 적다는 인상을 받게 된다.
툴을 많이 아는 사람일수록 일이 더 구조화되어 있고,
더 효율적일 거라는 믿음은 쉽게 깨진다.
Notion으로 정리했지만 정리는 목적이 없고,
Obsidian은 텍스트 창고에 불과하며,
ChatGPT는 가끔 물어보는 검색 도구 수준에 머문다.
툴을 ‘쓸 줄 아는 사람’과
툴로 ‘일을 설계하고
성과를 만드는 사람’ 사이에는 깊은 차이가 있다.
많은 실무자들이 말한다.
“Notion 강의 들었어요.”
“ChatGPT 프롬프트 짜는 법도 배웠죠.”
“마크다운 문법도 이제 잘 써요.”
그런데 업무는 여전히 벅차고,
문서 작성은 늘 제자리이고,
팀 협업은 도무지 나아지지 않는다.
이유는 간단하다.
툴을 ‘기능 중심’으로 익혔지,
‘일의 구조를 바꾸는 도구’로 사용하지 못했기 때문이다.
툴은 무기가 아니다.
툴은 운영체계(Work Operating System)를 재설계하는 장치다.
그러나 대부분은 툴을 사용법 중심의 학습으로 받아들이고,
업무의 맥락이나 흐름, 설계에는 연결하지 않는다.
그래서 배우기는 하지만, 성과에는 연결되지 않는다.
한 마케터는 이렇게 말했다.
“ChatGPT로 아이디어는 받는데, 결국 그걸 정리하는 데 시간이 더 걸려요.”
“Notion에 넣긴 했는데, 정리만 하다가 기획서가 늦어졌죠.”
툴이 오히려 ‘일’을 지연시키는 사례다.
반면 어떤 디자이너는 이렇게 말한다.
“프로젝트 시작 전에 Obsidian으로 컨셉 구조를 짜고,
ChatGPT로 레퍼런스를 정리한 후
Notion으로 업무 분배 구조를 설계했어요.
그러니 실제 디자인 작업 시간이 확 줄었죠.”
툴은 이럴 때 힘을 발휘한다.
‘일의 흐름’과 ‘성과 구조’를 바꿀 때,
툴은 진짜 무기가 된다.
문제는 많은 실무자가 툴을 따로 배우고,
업무는 따로 흘러가고 있다는 점이다.
툴은 결국 일의 흐름을 재설계하는 수단이 되어야 한다.
툴을 제대로 활용하는 사람은, 다음 질문을 항상 던진다.
“이 툴이 나의 일 흐름을 바꿔줄 수 있을까?”
“이 툴을 통해 반복되는 업무를 구조화할 수 있을까?”
“이 툴로 내가 시간을 줄이고, 성과를 높일 수 있는 루틴을 만들 수 있을까?”
이 질문에 ‘예’라고 답할 수 있어야
툴을 ‘사용’한 것이 아니라
툴로 ‘일했다’고 말할 수 있다.
툴은 자기계발의 결과가 아니라,
커리어의 구조를 바꾸는 기획 장치다.
툴을 능숙하게 다루는 것이 중요한 게 아니다.
툴을 통해 내 일을 재설계할 수 있는가가 핵심이다.
그래서 우리는 이제 묻고, 바꿔야 한다.
“툴을 쓸 줄 아는가?”가 아니라,
“툴로 어떤 구조를 만들었는가?”
이 질문에 답할 수 있는 사람만이
진짜 디지털 실무자다.
그리고 이제 그 기준이,
일의 미래를 결정짓는다.
“Notion을 배웠지만, 실무에선 그냥 엑셀로 다시 합니다.”
“GPT로 초안은 뽑았는데 결국 제가 다 고쳤어요.”
“Obsidian 깔아는 봤는데, 그냥 메모앱이랑 똑같더라고요.”
이런 말을 하는 사람들을 수없이 봐왔다.
툴을 ‘배운 사람’과, 툴로 실제 성과를 만든 사람은 명확히 다르다.
그리고 그 차이는 ‘능력’보다 사고방식의 차이에서 비롯된다.
많은 실무자들이 Notion, Obsidian, ChatGPT 같은 툴을 배운다.
강의도 듣고, 책도 읽고, 유튜브도 본다.
심지어 자격증을 따기도 한다.
그런데도 왜,
업무 성과는 이전과 다르지 않은가?
바로 ‘배움의 방식’ 때문이다.
대부분의 툴 학습은 기능 중심이다.
“이 버튼은 뭐고, 여긴 어떤 기능이 있어요.”
“이렇게 입력하면 자동으로 정리돼요.”
“여기에 템플릿을 넣으면 시간 줄일 수 있어요.”
물론 기능을 모르면 툴을 쓸 수 없다.
하지만 툴을 기능으로만 학습하면,
실제로는 ‘도구를 다루는 사람’에 머무르게 된다.
그리고 진짜 일하는 데 필요한 건
‘도구를 다루는 사람’이 아니라
‘일을 설계하는 사람’이다.
1. 툴은 쓸 줄 아는데, 뭘 해야 할지 모른다
→ 툴은 익혔지만, 일 자체를 어떻게 구조화할지 모른다.
Notion을 열고 마주한 첫 화면에서 멍해지는 사람들.
Obsidian을 켜놓고도 빈 화면만 가득한 노트.
GPT에게 무얼 물어볼지조차 모르겠는 실무자.
2. 툴이 일에 어떻게 연결되는지 모른다
→ ‘기능’은 외웠지만 ‘맥락’에 연결하지 못한다.
예를 들어, ‘업무 흐름에 따라 데이터가 쌓이게 하는 구조’가 아니라
‘좋아 보이는 템플릿을 흉내 내기’에 그치는 경우가 많다.
3. 툴을 써도 일이 안 줄고, 정리가 안 된다
→ 오히려 툴 사용이 새로운 업무처럼 느껴진다.
ChatGPT 요약도, Notion 정리도, Obsidian 링크도
‘일을 더 복잡하게 만들고 있다’는 느낌.
이런 경험을 반복하면
사람들은 결국 이런 말을 하게 된다.
“툴은 나랑 안 맞는 것 같아요.”
하지만 사실 툴이 문제가 아니라,
툴과 일의 연결 방식이 문제였던 것이다.
툴을 배웠지만 일은 그대로인 이유는,
툴을 기존 방식의 ‘보조 수단’ 정도로만 활용했기 때문이다.
Notion은 기존의 문서 폴더 정리를 대체하는 수준
GPT는 단순 검색 도구의 업그레이드 수준
Obsidian은 아날로그 메모장을 디지털로 옮긴 수준
이런 식의 사용은 ‘디지털화’는 되지만,
‘재설계’는 일어나지 않는다.
즉, 툴을 써도 업무의 본질은 그대로다.
이전의 비효율, 반복, 불명확한 흐름은
툴이라는 포장을 두른 채 계속된다.
그 결과, 툴을 쓴다는 ‘환상’만 있고
성과는 이전과 달라지지 않는다.
도구 중심 사용의 한계를 넘어서기 위해서는
툴을 바라보는 시선을 전환해야 한다.
툴은 ‘보조도구’가 아니라,
‘업무 구조를 재설계하는 장치’라는 전제 위에 있어야 한다.
즉, 툴을 쓰기 전에 물어야 할 것은
“이 기능을 어떻게 익히지?”가 아니라
“이 툴이 내 일의 흐름을 어떻게 바꿔줄 수 있을까?”다.
그리고 이 질문은
‘기능 중심 사고’에서 ‘설계 중심 사고’로의 전환을 요구한다.
결국, 실무에서 중요한 것은 툴을 아는 정도가 아니라,
툴을 어떻게 ‘맥락 속에 연결하느냐’다.
어떤 툴을 왜 쓰는가?
어디에서 시작해 어디로 이어지는가?
반복되는 부분을 어떻게 줄일 수 있는가?
어떻게 협업 흐름과 연결될 수 있는가?
이런 질문들에 답할 수 있어야
툴은 기능에서 도구,
도구에서 설계,
설계에서 성과로 연결된다.
“Notion을 아는 것이 중요한 게 아니라,
Notion으로 ‘무엇을 설계할 수 있는가’가 중요하다.”
이 말은 단순한 문장 이상이다.
현대의 실무 현장에 툴이 '있는 것'과 '작동하는 것'의 차이를 명확히 보여준다.
우리는 툴을 배우는 시대를 지나,
툴로 '일을 설계하는 시대'에 진입했다.
그 중심에는 세 가지 키워드가 있다:
구조화, 루틴화, 자동화.
툴을 쓴다고 일이 잘 되는 건 아니다.
하지만 구조를 만든 후에 툴을 적용하면
툴은 ‘설계의 도우미’로 기능한다.
예를 들어보자.
Notion을 단순 노트 공간으로 쓸 수도 있지만,
프로젝트 기획, 업무 트래킹, 문서 협업, 회고 관리 등
한 구조 안에서 유기적으로 작동하는 시스템으로 만들 수 있다.
Airtable 역시 단순한 데이터 관리 도구가 아니라,
‘기획 – 실행 – 성과분석’의 흐름을 시각화하고
팀 간 협업을 구조화하는 플랫폼이 될 수 있다.
구조화의 핵심은 ‘정보를 흐름으로 설계하는 것’이다.
즉, 툴은 단편적인 작업이 아닌
일의 전 과정을 설계하는 기반이 되어야 한다.
많은 사람들이 “업무가 반복적이라 지겹다”고 말한다.
하지만 반복은 ‘루틴화’를 통해 설계 가능한 영역이다.
매일 아침 이메일 확인
주간 회의 준비
콘텐츠 기획–작성–검토–업로드
고객 대응 기록 → CS 피드백 → 서비스 개선
이처럼 정기적으로 반복되는 업무는
툴을 통해 ‘루틴’으로 바꿔야 한다.
예시:
✅ Notion의 데일리 페이지 템플릿
→ 오늘 해야 할 일, 회의록, 미팅 준비가 자동 생성
✅ Obsidian의 Daily Note + Tag 시스템
→ 오늘 한 일의 기록이 자동으로 주간/월간 회고에 누적됨
✅ Slack + Google Calendar 자동 연동
→ 일과 시간에 맞춰 리마인드 및 회고 슬랙봇 알림
루틴화란, 업무 흐름을 '체계화'하고 '예측 가능'하게 만드는 작업이다.
루틴은 정신적 에너지를 절약하고,
중요한 일에 더 많은 집중력을 쓰게 만든다.
자동화란 ‘귀찮음을 없애는 기술’이 아니다.
시간과 에너지를 ‘전략적 판단’에 집중시키는 장치다.
툴은 더 이상 사람이 반복하지 않아도 되는 영역을
자동화할 수 있게 돕는다.
예를 들어:
✅ Google Form → Google Sheet → Google Data Studio
→ 고객 의견을 자동 취합하고 실시간 대시보드에 시각화
✅ Zapier, Make (Integromat)
→ ‘구글 캘린더 일정 → 슬랙 알림’
→ ‘이메일 수신 → 노션 카드 생성’
→ ‘설문 응답 → 자동 이메일 회신’
✅ GPT API 자동화
→ “이 텍스트를 문어체로 바꿔줘”
→ “주간 회의록을 요약해줘”
→ “고객 후기에서 긍정/부정 키워드 뽑아줘”
자동화는 ‘일을 대체하는 게 아니라,
일을 조율하는 사람’으로 우리를 바꾼다.
많은 실무자들이 툴을 ‘써보긴 했지만 정착하지 못했다’고 말한다.
그 이유는 단순하다.
툴을 기능으로 익혔고, 설계로 연결하지 않았기 때문이다.
Notion, Obsidian, Slack, Trello, GPT, Zapier 등은
단순한 앱이 아니다.
Notion은 정보 흐름을 설계하는 전략이고,
Obsidian은 사고 체계를 시각화하는 전략이며,
GPT는 콘텐츠 생성과 사고 보조 전략이고,
Zapier는 업무 자동화 전략이다.
우리는 툴을 ‘도구’가 아닌
‘일을 설계하고 통합하는 전략’으로 접근해야 한다.
같은 툴을 써도
누군가는 메모만 남기고,
누군가는 업무 전체를 통제한다.
그 차이는 ‘무엇을 설계할 것인가’를
스스로 정의하는 데서 시작된다.
이 툴로 어떤 흐름을 자동화할 수 있지?
팀원들이 이 툴을 써서 어떤 데이터를 남기게 할 수 있지?
툴을 통해 회의록이 아니라, ‘행동 촉발 구조’를 만들 수 있지?
이런 질문을 던질 줄 아는 사람,
즉 툴로 구조를 설계할 줄 아는 실무자가
앞으로의 커리어 설계에서 결정적 우위를 갖게 될 것이다.
“일이 너무 많아서 도저히 정리가 안 돼요.”
이 말은 마케팅 에이전시에서 일하던 2년 차 AE(어카운트 이그제큐티브) ‘윤지’가 한숨처럼 내뱉은 말이었다.
윤지는 클라이언트 커뮤니케이션부터 광고 예산 관리, 콘텐츠 기획 조율, 미팅 참석까지…
매일 일에 밀리고, 쫓기고, 허덕이며 하루를 끝냈다.
툴은 이미 많았다.
Notion, Slack, Excel, Zoom, Gmail, ClickUp…
오히려 툴이 많아서 더 복잡했다.
“툴이 일을 도와주는 게 아니라, 일이 툴에 끌려다닌다”는 말이 딱 맞았다.
그러던 어느 날, 팀 리더가 윤지에게 말했다.
“툴은 그대로 두고, 너의 업무 흐름 자체를 한 번 그려보자.
‘무슨 일이’, ‘언제’, ‘어디서’, ‘어떻게’ 일어나고 있는지.”
윤지는 화이트보드 앞에 섰고,
자신이 매주 반복하는 루틴을 나열하기 시작했다.
월요일 오전: 콘텐츠 일정 기획 회의
화요일~수요일: 클라이언트 피드백 정리 및 조율
목요일: 광고 예산 정산 보고서 작성
금요일: 다음 주 업무 계획과 주간 회고
이 흐름에 따라 “반복적이고 규칙적인 업무 구조”가 있다는 걸 처음 깨달았다.
문제는 그 구조가 툴마다 분산돼 있었고, 연결되지 않았다는 것이었다.
윤지는 이 흐름을 기반으로 다음과 같은 구조를 만들기 시작했다.
Notion에 주간 업무 템플릿을 만들고,
각 항목을 미리 배치해 매주 복붙하지 않아도 되게 했다.
Slack에는 매주 정해진 요일, 정해진 시간에 자동 리마인더가 울리도록 설정했다.
“화요일 오전 9시 → 클라이언트 피드백 공유”
“목요일 오후 3시 → 예산 정산 보고서 초안 완료”
Google Drive에는 프로젝트별 폴더를 구성하고,
Notion과 연동하여 회의록과 산출물이 자동 연결되게 만들었다.
ClickUp을 통해 마감일 기준 업무 카운트다운을 시각화했다.
마감이 3일 남은 업무는 ‘주의’, 1일 이내 업무는 ‘긴급’으로 분류되어 대시보드에 뜨도록 설정했다.
툴은 하나도 새로 바꾸지 않았다.
단지 툴을 ‘구조화된 흐름’에 따라 연결하고,
툴을 ‘따라 쓰는 것’이 아니라 ‘움직이는 설계도’로 삼은 것이다.
불과 두 달 후, 윤지의 하루는 완전히 달라졌다.
매일 아침, Notion 데일리 페이지가 자동 생성되고,
그 안에 오늘 할 일이 순서대로 정리되어 있었다.
회의가 끝나면 회의록이 자동 저장되고,
주요 결정사항은 클릭 한 번으로 담당자에게 알림이 갔다.
프로젝트가 중간에 꼬일 일이 거의 없었다.
각 툴에서 상황이 ‘가시화’되어 있었기 때문이다.
윤지는 ‘일을 하는 사람’에서
‘일을 설계하고 조율하는 사람’으로 바뀌었다.
“일이 줄어들진 않았어요. 하지만 머릿속이 가벼워졌고,
무엇보다 ‘지금 내가 뭘 하고 있는지’가 훨씬 선명해졌어요.”
윤지는 자신이 툴을 그렇게 ‘못 쓰는 사람’은 아니라고 생각해왔다.
하지만 그건 기능을 ‘이해한 수준’일 뿐,
툴로 ‘설계해본 경험’은 없었다.
그녀는 말한다.
“Notion 강의, ClickUp 유튜브, 다 봤지만…
그게 내 일에 연결되지 않으면, 아무 소용 없더라고요.”
윤지는 지금 신입 사원이 입사하면 이렇게 교육한다.
툴 기능은 최소한만 알려주고,
본인이 어떤 흐름을 만들고 싶은지를 먼저 말하게 하고,
흐름을 구현하는 방식으로 툴을 설계하게 한다.
결과는?
신입 사원들은 빠르게 자율성과 업무 이해도를 높이고 있다.
툴이 아니라
‘일을 설계하는 감각’을 먼저 익히기 때문이다.
윤지의 사례가 보여주는 것은 단순하지 않다.
툴을 많이 안다고 해서 실무를 잘하는 것이 아니며,
툴을 몰라도 ‘구조화 사고’를 가진 사람은 빠르게 적응할 수 있다는 것이다.
툴은 기능이 아니라, 감각이다.
그리고 그 감각은 이렇게 정의된다.
“툴을 도구로 쓰는 게 아니라,
툴로 일의 흐름을 설계하는 사람.”
우리는 더 이상
‘툴을 잘 쓰는 사람’이 아니라
‘툴로 일하는 사람’을 필요로 한다.
“우리는 변화를 시도했지만, 도구는 예전 그대로였어요.
결국 사람도, 문화도, 흐름도 과거에 머물렀죠.”
이 말은 어느 공공기관 산하 A재단의 팀장이 퇴사 전 남긴 말이다.
그는 ‘디지털 전환 추진 TF’의 주도자였고, 새로운 변화의 상징이었다.
하지만 ‘툴은 남고, 사람만 바뀌는’ 현실 앞에서 번아웃됐다.
A재단은 코로나19 이후 빠르게 원격 근무 체계를 도입했다.
Zoom과 Teams를 통해 회의는 디지털로 전환되었고,
모두가 각자의 자리에서 모니터를 보며 회의했다.
하지만 문제는 그 다음이었다.
회의록은 여전히 종이로 작성되어, 인편으로 회람되었다.
결재는 여전히 프린트, 도장, 봉투로 이루어졌다.
심지어 어느 직원은 이렇게 말했다.
“그냥 출근해서 결재 올리면 빨라요.
디지털? 그건 불편하고 답답하죠.”
즉, 겉은 디지털인데 속은 아날로그인 조직이 되어버린 것이다.
A재단은 내부적으로도 다양한 툴을 도입했다.
업무 협업 도구: Trello, Notion
문서 작성: Google Docs, Hancom Docs
커뮤니케이션: Slack, Email, Kakao Work
일정 공유: Google Calendar, Outlook
문제는 “모든 툴이 각각 따로 놀았다”는 데 있다.
회의 일정은 Google Calendar로 공지했지만,
실제 시간 조율은 카톡방에서 이루어졌다.
보고서는 Notion에 작성하라고 했지만,
윗선은 여전히 한글파일로 출력된 보고서를 원했다.
Trello 보드는 존재했지만, 누가 어느 일을 하는지
주간보고 메일로만 다시 정리해야 했다.
결국 직원들은 말한다.
“툴은 많지만, 일은 더 복잡해졌어요.”
디지털 도입은 효율을 높이기 위한 것이었다.
하지만 구성원들은 오히려 ‘툴 피로’에 시달렸다.
같은 내용을 세 번 쓰고,
여러 플랫폼을 왔다 갔다 하며,
정보가 흩어지고,
책임의 흐름은 불분명해졌다.
결국 몇몇 직원은 메모장과 이메일만 사용하는 방식으로 되돌아갔다.
한 직원은 이렇게 말했다.
“툴은 그럴싸한데, 정작 일은 더 손이 많이 가요.
나는 그냥 다 프린트해서 책상에 펴놓고 일해요.”
이 재단은 사회적 가치, 지역협업, 청년 일자리 등
복잡하고 융합적인 프로젝트를 수행해야 했다.
즉, 업무는 ‘정형화된 보고서 작성’이 아니라
‘다양한 이해관계자와 협력하고, 유연하게 대응하는 프로젝트 수행’이 중심이 되었다.
하지만 그 일에 맞는 업무 흐름과 툴의 통합적 설계는 전혀 이루어지지 않았다.
프로젝트는 협업인데,
툴은 여전히 개인 작업 기반이었다.
일은 흐름인데,
툴은 기능 단위로만 도입되었다.
목표는 유연한 대응인데,
툴은 절차만 늘어나게 했다.
A재단의 실패는 툴 때문이 아니었다.
툴은 충분했다. 다양했고, 기능도 강력했다.
문제는 그 툴들이 ‘어떤 흐름’을 전제로 연결되지 않았다는 점이었다.
즉, 툴은 일하는 방식의 표현일 뿐인데,
‘일의 방식’ 자체가 설계되어 있지 않았던 것이다.
“일의 흐름이 명확해야 툴이 빛난다.
툴은 기술이 아니라 업무의 구조다.”
디지털 전환은 기술의 도입이 아니라
‘일을 어떻게 설계할 것인가’에 대한 질문이다.
툴은 그 설계를 구현하는 수단일 뿐이다.
‘이 툴을 쓸까, 저 툴을 쓸까’를 고민하기 전에
“우리는 어떤 흐름으로 일하고 있는가”를 먼저 물어야 한다.
“회의 후 회의록은 어떻게 공유되고,
누가 어떤 액션을 언제까지 실행해야 하며,
그 결과는 어디서 확인되는가?”
이 흐름이 그려져야
비로소 툴은 일을 자동화하고, 가시화하고, 구조화하는 도구가 된다.
마지막으로 A재단 팀장이 퇴사하며 남긴 말을 인용한다.
“우리는 툴을 도입했다고 생각했지만,
사실 아무것도 바뀐 게 없었다.
일하는 방식이 그대로인데,
도구만 바뀐다고 효율이 오를 수는 없다.”
이 말은 우리 모두에게 다음과 같은 질문을 던진다.
당신의 조직은 툴을 사용하고 있는가?
아니면 툴에 끌려다니고 있는가?
그리고 이 질문의 답은,
‘일을 구조화하려는 의지’에 달려 있다.
우리는 종종 새로운 툴을 도입하면 모든 게 바뀔 거라 믿는다.
하지만 실상은 그렇지 않다.
툴은 일하는 방식을 바꾸는 ‘수단’이지, 그 자체가 목적은 아니다.
Notion, Trello, Slack, ChatGPT…
이 모든 도구는 ‘무엇을 위해’ 존재하는가?
그것은 일을 명확히 설계하고,
흐름을 가시화하며,
성과를 가속화하기 위한 도구다.
툴이 효과를 발휘하려면
그 전에 ‘일의 구조’가 먼저 설계되어야 한다.
현재 사용하는 툴 리스트를 써보자.
그리고 그 툴이 각각 어떤 ‘일의 흐름’과 연결되어 있는지를 점검해보자.
단순히 도구 이름만 알고 있는 게 아니라,
실제로 업무 프로세스 속에 어떻게 녹아 있는지를 분석해야 한다.
예)
Trello: 주간 단위 업무 관리 (백로그 → 진행중 → 완료)
Notion: 사내 위키 + 회의록 관리 + 템플릿 기반 보고서
Google Calendar: 일정 공유 + 알림 중심 업무 리듬 설계
‘툴로 일하는 구조’를 그려보자.
당신의 하루 혹은 한 주 업무 중 하나를 선택해서,
그 흐름을 툴 중심으로 재구성해보자.
예)
① 업무 접수 → ② Trello에 할당 → ③ 진행 상황 주간 공유 (Slack)
→ ④ 완료 후 결과 정리 (Notion) → ⑤ 주간 회고 작성 (Google Doc)
이런 흐름을 만들면
툴은 업무를 시각화하고, 구조화하며, 자동화하는 강력한 무기가 된다.
‘툴 활용’이 아니라 ‘툴 기반 구조화’를 팀 문화로 만들자.
혼자만 잘 써선 의미 없다.
팀 전체가 같은 흐름과 구조를 공유할 때,
툴은 비로소 진짜 생산성과 몰입을 만들어낸다.
나는 지금 어떤 툴로 일하고 있는가?
그 툴은 ‘일의 흐름’을 설계하는 데 어떻게 활용되고 있는가?
내가 사용하는 툴은 나를 더 몰입하게 만드는가, 아니면 피로하게 만드는가?
그리고
내가 바꾸어야 할 것은 ‘도구’가 아니라 ‘일의 구조’일지도 모른다.