린 워크플로우 미니멀리즘 6주 실험: 업무 단계 14개를 7개로 줄인 기록

업무 효율을 높이려고 처음 한 일은 도구를 더 추가하는 것이었습니다. Notion에 데이터베이스를 만들고, Google Calendar에 시간 블록을 넣고, Slack 알림을 세분화하고, Google Sheets로 업무 현황표까지 만들었습니다. 그런데 이상하게도 도구는 늘었는데 일이 빨라지지는 않았습니다. 오히려 하루가 끝나면 “오늘 뭘 했지?”라는 느낌이 남았습니다. 그래서 2026년 1월 6일부터 2026년 2월 16일까지 6주 동안 린 워크플로우 미니멀리즘 실험을 진행했습니다.

실험 목표는 단순했습니다. 업무 단계를 줄이되, 업무 흐름을 잃지 않는 것이었습니다. 기존에는 업무 단계가 14개였습니다. 아이디어 수집, 검토 대기, 우선순위 지정, 일정 배정, 자료 요청, 작성 중, 검토 중, 수정 중, 승인 대기, 예약 대기, 공유 완료, 보류, 재검토, 완료처럼 너무 잘게 나눠져 있었습니다. 처음에는 체계적이라고 생각했지만, 실제로는 상태를 옮기는 데 시간을 쓰고 있었습니다.

실험 환경과 기존 문제

업무 환경은 재택근무였고, 사용 도구는 Notion, Google Calendar, Slack, Google Sheets였습니다. 평일 기준 업무 시간은 오전 9시 30분부터 오후 6시 30분까지 약 9시간이었습니다. 주 업무는 콘텐츠 기획, 일정 관리, 협업 요청 정리, 보고서 작성이었습니다. 실험 전 하루 평균 할 일 수는 23개였고, 하루 평균 도구 전환 횟수는 68회였습니다. Notion을 보다가 Slack을 확인하고, 다시 Calendar를 열고, Sheets에서 현황을 확인하는 식이었습니다.

가장 큰 문제는 업무 누락이었습니다. 실험 전에는 업무 누락이 주 6건 정도 발생했습니다. 여기서 업무 누락은 “내가 할 일로 인식했지만 마감 시간까지 처리하지 못했거나, 다른 팀원이 다시 알려준 경우”로 기록했습니다. 알림 확인 횟수도 하루 평균 47회였습니다. 정작 중요한 업무를 하는 시간보다 알림을 보고 상태를 정리하는 시간이 더 길게 느껴졌습니다.

기존 업무 단계 14개가 만든 병목

처음 만든 Notion 상태값은 9개였습니다. Inbox, 검토중, 예정, 진행중, 자료대기, 피드백대기, 수정중, 승인대기, 완료였습니다. 여기에 Google Sheets에서는 별도로 우선순위, 담당자 확인, 회의 필요, 보류, 재검토 같은 표시를 붙였습니다. 결국 실제 업무 흐름은 14단계처럼 굴러갔습니다.

상태값이 많으면 정확해질 줄 알았지만, 반대로 헷갈렸습니다. 예를 들어 외부 자료를 기다리는 업무를 “자료대기”에 둘지 “피드백대기”에 둘지 애매했습니다. 회의에서 수정 의견이 나온 업무는 “수정중”인지 “검토중”인지 매번 고민했습니다. 하루 업무 정리 시간도 평균 42분이나 걸렸습니다. 일하는 시간이 아니라 일을 정리하는 시간이 너무 길었습니다.

첫 번째 실패: 상태값을 무작정 삭제했다

1주 차에 가장 크게 실패했습니다. 업무 단계를 줄이겠다고 Notion 상태값 9개 중 5개를 한 번에 삭제했습니다. 검토중, 예정, 자료대기, 수정중, 승인대기를 없애고 Inbox, Doing, Done 정도로 단순화했습니다. 문제는 진행 중인 업무 5건의 위치를 잃어버린 것입니다.

특히 1월 9일에는 외부 자료를 기다리던 보고서 2건, 승인 대기 중이던 콘텐츠 1건, 수정 중이던 문서 2건이 모두 Doing 안에 섞였습니다. Slack에서 “이 건 승인 요청 올라간 상태 맞나요?”라는 질문을 받고 나서야 상태가 사라진 업무를 다시 확인했습니다. 복구하는 데 1시간 25분이 걸렸고, 그날 회의 전 준비 시간은 평균 28분보다 긴 41분까지 늘었습니다. 이때 알게 된 것은 단계를 줄이는 것과 흐름을 지우는 것은 다르다는 점이었습니다.

두 번째 실패: 알림을 너무 많이 껐다

2주 차에는 알림 스트레스를 줄이려고 Slack과 Calendar 알림을 크게 줄였습니다. 하루 평균 알림 확인 횟수를 47회에서 20회 이하로 낮추고 싶었습니다. 그래서 Slack 채널 12개 중 8개를 음소거하고, Google Calendar 알림도 회의 10분 전 1회만 남겼습니다.

그런데 1월 16일 중요한 승인 요청 1건을 반나절 늦게 확인했습니다. 오전 10시 20분에 올라온 승인 요청을 오후 3시 40분에 확인했습니다. 약 5시간 20분 늦어진 셈입니다. 이 요청은 당일 오후 외부 전달 전에 확인해야 하는 자료였고, 결국 팀원이 한 번 더 Slack으로 직접 멘션했습니다. 알림을 줄이는 것은 맞지만, 긴급 업무까지 묻히면 안 된다는 기준이 필요했습니다.

개선 방식: 수집, 처리, 진행, 완료 4단계로 단순화

3주 차부터 기준을 다시 만들었습니다. 업무 흐름은 수집, 처리, 진행, 완료 4단계로 단순화했습니다. Notion 상태값은 Inbox, Doing, Waiting, Done만 유지했습니다. Inbox는 아직 정리하지 않은 업무, Doing은 내가 직접 처리 중인 업무, Waiting은 승인이나 자료를 기다리는 업무, Done은 완료된 업무로 정했습니다.

긴급 업무는 별도 상태값을 만들지 않고, 태그로만 표시했습니다. 예를 들어 긴급 승인이 필요한 업무에는 긴급 태그를 붙이고, Slack에서는 해당 업무만 멘션 알림을 유지했습니다. 이렇게 하니 상태값은 4개로 줄었지만, 업무 흐름은 사라지지 않았습니다.

[최종 Notion 상태값]
Inbox: 수집만 된 업무
Doing: 내가 처리 중인 업무
Waiting: 자료·승인·피드백 대기
Done: 완료된 업무

[긴급 표시 기준]
마감 24시간 이내 + 다른 사람 일정에 영향 있음 = 긴급 태그

워크플로우 개선 전후 표

업무 흐름	기존 방식	문제점	개선 후 방식	실제 효과	주의할 점
업무 수집	Slack, Sheets, Notion에 각각 기록	같은 업무가 2번 이상 등록됨	모든 업무를 Notion Inbox에 먼저 수집	하루 할 일 수 23개에서 15개로 감소	수집 후 처리 시간을 따로 잡아야 함
상태 관리	상태값 9개 사용	업무 위치 판단에 시간 소요	Inbox, Doing, Waiting, Done 4개 유지	업무 정리 시간 42분에서 19분으로 감소	대기 업무는 Waiting에 반드시 남겨야 함
알림 확인	Slack 대부분 알림 ON	하루 평균 47회 확인	긴급·멘션·승인 요청만 알림 유지	하루 평균 21회로 감소	중요 채널까지 끄면 누락 발생
회의 준비	회의 직전 자료 검색	준비 시간 평균 28분	회의 전날 Waiting 업무와 관련 문서 정리	준비 시간 평균 14분으로 감소	회의 링크와 문서 링크를 같이 넣어야 함
업무 완료	완료 후 별도 기록 누락	나중에 무엇을 했는지 찾기 어려움	Done 이동 시 결과 링크 1개 첨부	주간 회고 작성 시간 감소	완료 기준을 너무 복잡하게 만들면 안 됨

수치로 본 6주 변화

6주 실험 후 가장 눈에 띈 변화는 도구 전환 횟수였습니다. 하루 평균 도구 전환 횟수는 68회에서 31회로 줄었습니다. Notion에서 업무를 확인하고, Google Calendar에서 시간을 확인하고, Slack에서 요청을 다시 찾던 흐름을 줄인 덕분입니다. 업무 수집은 Notion Inbox에 통일하고, 일정이 있는 업무만 Google Calendar에 넣었습니다.

하루 평균 할 일 수는 23개에서 15개로 줄었습니다. 할 일이 실제로 줄었다기보다, 중복 등록과 의미 없는 작은 업무를 제거한 결과였습니다. 예전에는 “메일 확인”, “Slack 확인”, “자료 열기” 같은 5분 이하 행동도 할 일로 넣었습니다. 개선 후에는 10분 이상 걸리거나 다른 사람에게 영향을 주는 업무만 등록했습니다.

업무 누락 건수는 주 6건에서 주 2건으로 줄었습니다. 특히 Waiting 상태값이 효과가 컸습니다. 이전에는 승인 대기나 자료 대기 업무가 진행 중 업무와 섞였지만, 개선 후에는 Waiting만 보면 내가 기다리는 업무가 보였습니다. 알림 확인 횟수도 하루 평균 47회에서 21회로 줄어 알림 스트레스가 낮아졌습니다.

회의 전 준비 시간이 줄어든 이유

회의 전 준비 시간은 평균 28분에서 14분으로 줄었습니다. 이전에는 회의 30분 전에 Slack 대화, Notion 문서, Sheets 현황표를 따로 열어봤습니다. 어떤 자료가 최신인지 찾는 데 시간이 많이 걸렸습니다.

개선 후에는 Calendar 일정에 Notion 업무 링크를 붙였습니다. 회의 안건과 관련된 업무가 Waiting인지 Doing인지 바로 확인할 수 있게 했습니다. 회의 전날 오후 5시에 다음 날 회의 3개를 미리 확인하고, 필요한 문서 링크를 Calendar 설명란에 넣었습니다. 이 작업은 하루 평균 8분 걸렸지만, 회의 직전 준비 시간을 절반으로 줄여줬습니다.

업무 처리 속도를 높인 기준

업무 처리 속도를 높이는 데 가장 도움이 된 기준은 “상태 변경은 하루 2번만 한다”였습니다. 이전에는 업무가 조금만 바뀌어도 상태를 옮겼습니다. 그러다 보니 실제 업무보다 정리 시간이 길어졌습니다. 개선 후에는 오전 9시 40분과 오후 5시 30분, 하루 2번만 Notion 상태를 정리했습니다.

오전에는 Inbox를 비우고 오늘 할 Doing을 정했습니다. 오후에는 Doing 중 끝난 것은 Done으로 옮기고, 답변을 기다리는 것은 Waiting으로 옮겼습니다. 이 기준을 적용한 뒤 하루 업무 정리 시간은 42분에서 19분으로 줄었습니다.

비교 기준별 체감 결과

비교 기준	실험 전	실험 후	체감 변화
업무 누락	주 6건	주 2건	대기 업무가 덜 묻힘
알림 스트레스	하루 47회 확인	하루 21회 확인	집중 흐름이 덜 끊김
도구 전환 횟수	하루 68회	하루 31회	업무 시작 전 망설임 감소
업무 처리 속도	정리 시간이 길었음	업무 정리 19분	실제 처리 시간 증가
유지 가능성	상태값이 많아 피로함	상태값 4개 유지	6주 동안 유지 가능

최종 결론: 린 워크플로우는 무조건 줄이는 것이 아니었다

6주 동안 린 워크플로우 미니멀리즘을 실험하면서 가장 크게 배운 것은 “줄이는 것” 자체가 목표가 아니라는 점입니다. 처음에는 업무 단계를 줄이면 무조건 효율이 오를 줄 알았습니다. 그래서 상태값을 무작정 삭제했다가 진행 중인 업무 5건의 위치를 잃어버렸습니다. 알림도 너무 많이 껐다가 중요한 승인 요청 1건을 반나절 늦게 확인했습니다.

결국 효과가 있었던 방식은 업무 흐름을 잃지 않는 선에서 불필요한 단계를 제거하는 것이었습니다. 기존 업무 단계 14개는 7개 흐름으로 줄였고, Notion 상태값은 9개에서 Inbox, Doing, Waiting, Done 4개로 정리했습니다. 긴급 업무는 별도 상태로 만들지 않고 태그로만 표시했습니다.

실험 전 하루 평균 할 일은 23개였지만 개선 후 15개로 줄었고, 도구 전환 횟수는 68회에서 31회로 줄었습니다. 업무 누락은 주 6건에서 주 2건으로 줄었고, 알림 확인 횟수는 하루 평균 47회에서 21회로 감소했습니다. 하루 업무 정리 시간은 42분에서 19분으로 줄었고, 회의 전 준비 시간은 평균 28분에서 14분으로 줄었습니다.

린 워크플로우의 핵심은 단순히 적게 쓰는 것이 아니었습니다. 어떤 업무가 들어오고, 어디서 처리되고, 무엇을 기다리고, 언제 끝났는지 흐름이 보여야 했습니다. 제 경험상 가장 좋은 구조는 복잡한 생산성 시스템이 아니라, 매일 유지할 수 있는 최소한의 기준이었습니다.

린 워크플로우를 설계하기 전 확인해야 할 체크리스트

현재 업무 단계가 몇 개인지 실제로 세어봤는가?
상태값이 많아서 업무 위치를 찾는 데 시간이 걸리지는 않는가?
수집, 진행, 대기, 완료 흐름이 끊기지 않게 남아 있는가?
삭제하려는 상태값 안에 진행 중인 업무가 남아 있지는 않은가?
알림을 줄이더라도 긴급 승인 요청은 놓치지 않게 설정했는가?
하루 도구 전환 횟수를 줄일 기준이 있는가?
회의 일정에 관련 문서 링크를 미리 붙여두는가?
업무 정리 시간을 하루 2번 이하로 제한할 수 있는가?
긴급 업무를 별도 상태가 아니라 태그로 표시할 수 있는가?
6주 이상 유지 가능한 단순한 구조인가?