대시보드를 다 만들고 일주일쯤 지난 어느 월요일, 저는 또 메신저로 “이번 주 입고 현황 좀 정리해줄래요?” 라는 요청을 받았습니다.
화면은 멀쩡히 돌아가고 있었습니다. 숫자도 맞았습니다. 그런데도 사람들은 여전히 저에게 물었고, 여전히 각자 엑셀을 만들고 있었습니다.
그날 알았습니다. SCM 자동화의 진짜 적은 SAP도, 데이터도, 코드도 아니라는 걸. ‘잘 만들었지만 아무도 안 쓰는 것’ — 이게 내부 도구가 죽는 가장 흔한 방식입니다.
이번 3편은 그래서 기능 이야기를 잠시 멈추고, 사람을 대시보드 안에서 일하게 ‘강제’하는 설계와, 그 설계에서 역산한 개발 체크리스트를 다룹니다.
왜 ‘기능’이 아니라 ‘사용 강제’가 핵심인가
내부 도구를 만들어 본 사람은 압니다. 기능은 만들면 됩니다. 어려운 건 사람의 습관을 바꾸는 것입니다.
사람은 익숙한 길을 버리지 않습니다. 이미 쓰던 엑셀, 이미 보내던 메일, 이미 묻던 메신저가 작동하는 한, 새 화면은 “있으면 좋은 것"에 머뭅니다. 있으면 좋은 도구는 결국 아무도 안 씁니다.
그래서 대시보드의 성패는 차트 디자인이 아니라 **“기존 방식을 못 쓰게 만들고, 새 방식만 남기느냐”**에 달려 있습니다. 저는 이걸 ‘사용 강제(forced adoption)‘라고 부릅니다.
💡 핵심: 채택률은 부탁이나 공지로 오르지 않는다. 다른 길을 막아야 온다.
사람을 대시보드로 끌어들이는 5가지 강제 장치
제가 실제로 효과를 본 순서대로 정리합니다. 위로 갈수록 강력합니다.
- ① 단일 창구화 — 기존 경로를 닫는다. “현황 정리해 달라"는 요청에 더 이상 엑셀을 만들어 주지 않습니다. 대신 “대시보드 보세요” 링크 하나로 답합니다. 옛길을 막지 않으면 새 길은 절대 안 생깁니다.
- ② 입력을 대시보드 안에서만 받는다. 현업이 반드시 해야 하는 입력(예: 입고 확인, 코멘트, 예외 사유)을 오직 대시보드에서만 가능하게 만듭니다. 그 작업을 하려면 들어올 수밖에 없습니다.
- ③ 보고·회의의 기준 화면으로 만든다. 주간 회의에서 팀장이 대시보드 화면을 띄웁니다. 상사가 그 숫자로 묻기 시작하면, 사람들은 자기 숫자가 거기서 어떻게 보이는지 신경 쓰게 됩니다.
- ④ 안 한 사람이 보이게 만든다. 누가 입력을 누락했는지 화면에 드러냅니다. 비난이 아니라 ‘공백의 가시화’입니다. 빈칸은 강한 동기입니다.
- ⑤ 마찰을 0에 가깝게 만든다. 위 강제가 먹히려면 3초 안에 끝나야 합니다. 로그인 한 번 더, 클릭 다섯 번 더면 사람들은 옛길로 돌아갑니다. 강제와 편의는 한 쌍입니다.
이 다섯 개는 따로 노는 팁이 아닙니다. “옛길을 막고(①), 새길에 일을 묶고(②), 윗선이 그 길을 보고(③), 누락이 드러나고(④), 그 길이 빠르다(⑤)” — 하나의 흐름입니다.
‘사용 강제’에서 역산한 개발 체크리스트
여기서 중요한 전환이 일어납니다. 위 다섯 장치를 실현하려면 무엇을 개발해야 하는지가 자동으로 정해진다는 것입니다. 즉 개발 체크리스트는 ‘있으면 좋은 기능 목록’이 아니라 **‘강제 장치를 받치는 필수 항목’**에서 역산됩니다.
| 강제 장치 | 필요한 개발 항목 | 우선순위 |
|---|---|---|
| ① 단일 창구화 | 공유 가능한 안정적 URL, 권한별 접근, 항상 최신 데이터 보장 | 높음 |
| ② 대시보드 내 입력 | 입력 폼·검증, 저장 이력, 동시 편집 충돌 처리 | 높음 |
| ③ 보고용 화면 | 회의용 요약 뷰, 기간 필터, 화면 캡처/내보내기 | 중간 |
| ④ 누락 가시화 | 미입력 표시, 담당자 매핑, 마감 알림 | 중간 |
| ⑤ 낮은 마찰 | SSO/자동 로그인, 빠른 로딩, 모바일 가독성 | 높음 |
이 표가 곧 개발 백로그입니다. ‘높음’부터 만들면, 기능을 다 만들기 전에도 채택이 시작됩니다.
💡 핵심: 체크리스트는 기능에서 시작하지 말고 **‘사람을 어떻게 묶을 것인가’**에서 시작해 역산하라.
체크리스트를 쓰는 법 — POC는 ‘가장 자주 받는 요청’부터
저는 모든 항목을 한 번에 만들지 않았습니다. 대신 이렇게 했습니다.
- 가장 자주 받는 자료 요청 1개를 골랐습니다(저는 ‘주간 입고 현황’이었습니다).
- 그 하나를 ①단일 창구 + ⑤낮은 마찰만으로 먼저 완성했습니다.
- 사람들이 “이건 그냥 링크가 빠르네"를 체감한 뒤에야 ②입력과 ④누락 가시화를 붙였습니다.
순서가 핵심입니다. 편의를 먼저 증명하고, 강제를 나중에 거는 것. 강제부터 걸면 반발만 남고, 편의만 주면 안 씁니다. 둘의 순서가 채택의 성패를 가릅니다.
3편을 마치며 — 다음 편 예고
2편까지가 ‘데이터를 어떻게 가져오고 저장하느냐’였다면, 3편은 **‘그걸 사람이 어떻게 쓰게 만드느냐’**였습니다. 정리하면:
- 자동화의 진짜 적은 코드가 아니라 ‘안 쓰는 습관’이다
- 채택은 부탁이 아니라 옛길 차단 + 새길 묶기로 온다
- 개발 체크리스트는 기능이 아니라 강제 장치에서 역산한다
- POC는 가장 자주 받는 요청 하나로, 편의 먼저 → 강제 나중
다음 편 예고:
- 4편: 대시보드 화면 구성 — 임원이 3초 만에 이해하는 카드 배치의 법칙
- 5편: PostgreSQL 테이블 설계 — AI에게 스키마를 그리게 하는 프롬프트 공개
- 6편: 운영 회고 — 무엇이 살아남고 무엇이 버려졌나
혹시 지금 만든 도구를 아무도 안 쓰고 있다면, 기능을 더 붙이기 전에 딱 하나만 자문해 보세요 — “사람들이 아직도 쓸 수 있는 옛길은 무엇인가?” 그 길을 찾아 막는 것이 다음 기능보다 먼저입니다. 댓글로 여러분의 ‘안 쓰는 도구’ 사연을 남겨주시면 다음 편 케이스로 녹여보겠습니다.
댓글