협업툴로 일의 구조를 바꾼 디자이너 B
잡크래프팅의 개념과 실천 Ch.2 | EP.07
우리는 종종 '도구를 바꿨으니 더 잘 되겠지'라고 생각한다.
하지만 도구는 가능성을 열어줄 뿐,
몰입은 결국 구조 설계의 결과다.
Chapter 1. 일의 주도권은 구조에서 시작된다(3회)
Chapter 2. 잡크래프팅의 개념과 실천(7/10회차)
Chapter 3. 일의 구조를 전략적으로 설계하라(5회)
11화. 협업툴로 일의 구조를 바꾼 디자이너 B
“툴은 쓰는데, 왜 이렇게 힘들지?”
디자이너 B는 좋은 팀에 있었다.
기획자는 명확한 브리프를 전달했고, 개발자는 빠르게 피드백을 주었다.
디자인 리더는 매일 오전 ‘스탠드업 미팅’에서 팀의 컨디션을 묻고, 진행사항을 체크했다.
툴도 최고였다.
Notion으로 프로젝트 전반의 흐름을 관리하고,
Figma로 실시간 협업을 하고,
Slack과 Trello로 커뮤니케이션과 업무 진행을 분리했다.
모든 게 완벽했다.
그런데 어느 날,
B는 자신이 '탈진하고 있다'는 것을 깨달았다.
“툴을 쓰는 게 일이 됐어요.”
“디자인을 할 시간이 없는 거예요.”
B는 하루의 절반을
툴에 댓글을 달고, 메신저를 확인하고,
회의에 참석하고, 업데이트 노트를 정리하는 데 썼다.
디자인 작업은 언제나 남은 시간에 몰아치듯 진행됐다.
‘툴’은 일의 도우미여야 했다.
그런데 이제는 ‘툴을 돌리는 게 일’이 되어버린 것이다.
B는 문득 생각했다.
“이건 협업툴의 문제가 아닐 텐데.”
그렇다면 문제는 무엇일까?
툴을 도입하면 모든 것이 좋아질 줄 알았다.
하지만 실제로는 '툴의 수'만 늘어나고 있었다.
회의도, 피드백도, 진행 체크도
툴이 늘어날수록 오히려 사람 사이의 연결이 더 복잡해졌고, 일의 흐름은 더 느려졌다.
“다들 각자의 툴에서 메시지를 주고받고,
‘이건 어디에 써야 하지?’를 고민하고 있어요.”
툴은 사람을 대신하지 못했다.
툴은 구조가 아니었고,
툴을 잘 쓴다고 해서 일이 잘 돌아가는 것은 아니었다.
그때 B는 한 가지 질문을 던졌다.
“이 툴이 내 일에 어떤 구조를 만들고 있지?”
툴을 다시 보기 시작했다.
단지 기능의 집합이 아닌,
일의 흐름을 설계하는 ‘프레임’으로서의 협업툴.
툴을 쓰는 ‘방식’이
결국 일의 방식을 결정한다는 사실을,
그는 이때 처음 깨달았다.
협업툴은 도구가 아니라 구조다
디자이너 B는 Notion을 켜놓은 채 다시 앉았다.
이번에는 다르게 보기 시작했다.
페이지 단위로 늘어놓은 작업 문서가 아니라,
'일이 흘러가는 경로'를 보기 시작한 것이다.
‘이 문서는 누구를 위해 있는 걸까?’
‘누가 언제, 어떤 흐름으로 이 작업물을 접하게 될까?’
‘지금 내가 만든 이 공간이, 어떤 협업을 유도하고 있는 걸까?’
툴은 그 자체로는 기능일 뿐이다.
하지만 툴 위에 무엇을 얹느냐에 따라,
그것은 감정을 소진시키는 창구가 되기도 하고,
몰입을 유도하는 흐름이 되기도 한다.
B는 회의 일정을 슬랙이 아니라 Notion 캘린더에 통합했다.
일정과 관련 문서가 자동으로 연결되도록 템플릿을 구성했다.
기획자는 기획 의도를 Notion 문서 상단에 정리하고,
디자이너는 그 밑에 피드백과 버전 이력을 남겼다.
그리고 중요한 결심 하나.
회의 전 모든 자료는 사전에 공유되어야 한다는 규칙.
회의는 이제 '정보 전달'이 아니라 '의사결정'만을 위한 공간이 되었다.
그 순간,
툴은 ‘도구’에서 ‘구조’로 전환되었다.
툴을 다루는 기술이 아니라,
툴을 기반으로 한 일의 흐름이 설계된 것이다.
툴이 구조가 되는 전환점에는 '기능 중심 사고'에서 '흐름 중심 사고'로의 변화가 있다.
처음에는 누구나 툴의 기능을 탐색한다.
“댓글은 어떻게 다는 거지?”
“링크는 어떻게 연결해?”
“여기선 어떤 파일이 열리지?”
하지만 진짜 중요한 것은,
그 기능이 어떤 협업 흐름을 만들고 있는가다.
툴은 피드백의 속도를 바꾸는가?
정보가 분산되는 것을 방지하는가?
역할과 책임이 모호하지 않게 설계되어 있는가?
반복되는 업무를 자동화할 수 있는가?
툴은 우리가 어떻게 일하게 될지를 결정짓는 ‘프레임’이다.
디자이너 B는 Figma에서 작업을 시작할 때마다
왼쪽 사이드에 항상 ‘의도 / 흐름 / 대상’을 먼저 정리해 넣는다.
“이 작업은 어떤 맥락에서 시작되었고,
어떤 사용자 경험을 만들고자 하며,
누구와 어떤 방식으로 협업할 것인지”를.
이 작은 장치는
툴이 단지 디자인을 위한 캔버스가 아니라,
업무 설계의 출발점이라는 걸 의미한다.
툴은 단지 도구가 아니다.
툴은 일을 어떻게 설계하고 싶은지를 드러내는 공간이다.
툴을 사용하는 방식은 결국,
구조에 대한 태도를 드러낸다.
‘툴을 왜 쓰느냐’보다 더 중요한 질문은
‘툴을 어떻게 구성하고 있느냐’이다.
B는 깨달았다.
툴을 바꾸는 것보다 더 중요한 건,
툴에 어떤 흐름을 설계하느냐였다.
구조를 설계했더니, 감정 피로가 줄었다
디자이너 B는 이전 직장에서 매일 아침 팀원과의 스탠드업 미팅으로 하루를 시작했다.
“어제 뭐 했는지, 오늘 뭐 할 건지, 막힌 건 뭔지.”
형식은 간단했다. 하지만 그 짧은 15분이 B에겐 늘 긴장과 부담의 시간이었다.
누군가의 눈치를 보며 말해야 했고,
솔직하게 ‘아직 아이디어가 없어요’라고 말할 수 없었다.
말을 하지 않으면 성실하지 않은 사람처럼 비춰졌고,
말을 너무 많이 하면 쓸데없이 말이 많은 사람으로 낙인찍혔다.
그렇게 하루는 피로하게 시작되었다.
하지만 협업툴 기반의 구조를 재설계한 이후,
B는 그 15분짜리 피로를 문서 중심의 흐름으로 바꿔냈다.
매일 아침 Notion에는 ‘오늘 할 일’이 정리된다.
전날 저녁, B는 내일의 작업 계획을 문서에 정리한다.
상태값은 ‘진행 전 / 진행 중 / 검토 요청 / 완료’로 나뉜다.
슬랙 대신 노션의 태스크 보드에서 팀원은 필요한 정보를 확인한다.
이제 B는 매일 아침 말 대신 흐름으로 소통한다.
이렇게 되자 한 가지 변화가 생겼다.
“감정이 덜 상한다.”
일의 성과를 둘러싼 피드백이,
누군가의 표정이나 말투에 의존하지 않게 되었다.
회의 중 쏟아지는 감정적 압박이나,
잘못 전달된 톤에 대한 억측도 줄었다.
‘나는 왜 이런 말투로 듣지?’
‘지금 나를 불신하는 건가?’
‘회의 끝나고 따로 이야기하자는 건 뭘까?’
이런 감정 소모가 줄어들었다.
구조는 감정을 정리한다.
우리는 일을 할 때, ‘사람’과 ‘업무’의 경계를 종종 헷갈린다.
하지만 협업툴 기반 구조가 잘 설계되면,
‘사람’보다 ‘일’이 중심이 되는 구조가 가능하다.
말이 아닌 ‘상태값’으로 소통하고,
피드백이 아닌 ‘버전 로그’로 협의하며,
기억이 아닌 ‘히스토리’로 회고할 수 있다면,
조직 내 감정적 소모는 급격히 줄어든다.
B는 문득 스스로에게 물었다.
“내가 감정적으로 피곤했던 이유는,
정말 일이 많아서였을까?”
아니었다.
일은 항상 많았다.
하지만 구조가 없을 때,
그 일은 감정과 뒤섞였고,
그 피로는 말할 수 없이 컸다.
이제 B는 말한다.
“협업툴이 내 감정을 구해줬다”라고.
사람 때문이 아니라,
‘툴을 기반으로 한 구조의 설계’가 감정적 피로를 줄였다.
툴은 도구일 뿐이지만,
그 위에 얹힌 구조는
사람을 지치게도, 살리게도 한다.
도구에서 구조로, 구조에서 일 몰입으로
– 일의 흐름을 바꾼다는 것의 의미
디자이너 B는 Notion, Figma, Slack, Zoom, Linear 등 협업툴을 자유롭게 다룬다.
하지만 그는 말했다.
“도구가 일 몰입을 만들어주진 않아요.
결국 그 도구들이 얹혀 있는 ‘구조’가 중요하죠.”
그는 단순히 ‘툴을 잘 쓰는 사람’이 아니라,
‘툴을 통해 일의 흐름을 설계한 사람’이었다.
B는 일의 흐름을 다음과 같이 나누어 정의했다.
시작 단계: 누가 어떤 문제를 풀고 있는가?
진행 단계: 어떻게 접근하고, 어디까지 가고 있는가?
협업 단계: 어떤 논의와 피드백이 오갔는가?
정리 단계: 최종 산출물은 어디에 있으며, 누가 확인했는가?
이러한 흐름은 각 도구에 분산된 정보로는 만들어지지 않았다.
그는 여러 도구를 ‘하나의 흐름’으로 통합하는 구조를 고민했고,
이를 위해 다섯 가지 질문을 기준으로 구조를 설계했다.
1. 모든 일이 ‘흐름’ 위에 올라가 있는가?
: 구두 지시나 채팅 메시지가 아니라,
모든 업무는 태스크보드에 등록되어야 한다.
2. 진행 상태를 ‘보여줄 수 있는가’?
: ‘하고 있어요’가 아니라 ‘Doing’ 칸에 있는지로 판단한다.
3. 피드백은 ‘대화’가 아닌 ‘문서’에 남아 있는가?
: 회의 후 DM이 아니라, Figma 코멘트나 문서에 이력이 쌓이는가?
4. 산출물의 위치는 명확한가?
: 어디에 있는지 물어보지 않아도 되는가?
5. 회고와 다음 액션이 연결되는가?
: 정리는 곧 다음 일의 설계로 연결되는가?
이 다섯 가지 기준은 협업툴을 구조화하는 원칙이 되었고,
그 위에서 ‘몰입’이 작동하기 시작했다.
사람들은 더 이상,
“언제까지야?” “이거 어디 있어요?” “회의 뭐라고 했죠?”를 묻지 않았다.
대신,
“이거 저도 연결해볼게요”
“피드백 반영해서 다시 올릴게요”
“다음번에는 이 흐름으로 가보죠”라는 말이 많아졌다.
몰입은 감정이 아니다.
몰입은 정보의 흐름과 구조 속에서 작동하는 심리적 상태다.
디자이너 B가 경험한 몰입은,
‘일에 집중하고 싶다’는 마음만으로는 생기지 않았다.
그는 구조를 바꾸었다.
흐름을 기준으로 협업툴을 통합했고,
감정을 걷어내고 문서 기반 협업 구조를 만들었으며,
모든 일이 연결되는 일의 지도를 설계했다.
우리는 종종 '도구를 바꿨으니 더 잘 되겠지'라고 생각한다.
하지만 도구는 가능성을 열어줄 뿐,
몰입은 결국 구조 설계의 결과다.
툴은 몰입을 강요할 수 없다.
툴은 다만 몰입이 가능한 구조를 가능하게 만들 뿐이다.
디자이너 B는 더 이상 "이건 내 일이 아닌 것 같아요"라는 말을 하지 않는다.
그는 구조 안에서 스스로 ‘나의 일’을 정의할 수 있게 되었기 때문이다.
그리고 그렇게 말한다.
“나는 도구가 아니라 흐름을 설계한다.”
그가 일터에서 바꾼 것은 툴이 아니라 일의 작동 방식이었다.
그리고 그것이야말로 진짜 ‘잡크래프팅’이었다.
