많은 기업들이 DX를 외치며 새로운 시스템과 도구를 도입하지만, 기대만큼 효과를 보지 못하거나 흐지부지되는 경우를 종종 봅니다. 저희 회사도 예외는 아니었고, DX 담당자로서 "좋은 툴만 도입하면 모든 게 해결될 거야!"라는 기대와는 다른 현실에 부딪히곤 했습니다. 원인이 무엇일까요? 값비싼 툴이 부족해서일까요? 아니면 직원들의 역량이 부족해서일까요?
제가 경험한 바로는, DX의 성공을 가로막는 가장 큰 장애물은 '도구' 그 자체가 아닌, 눈에 보이지 않는 '조직적, 심리적 장벽'이었습니다.
DX의 필요성에 대해 경영진이나 팀장급 리더들이 공감하지 못하거나, 단기적인 성과에 우선순위를 두면서 DX 추진 동력이 약해지는 경우가 많습니다. 새로운 방식 도입에 대한 막연한 불안감, 변화에 따르는 리스크 회피, 혹은 단순히 기존 방식에 대한 만족(또는 타성) 때문일 수 있습니다. 예산이나 자원 지원은 미미한 채 DX 담당 부서에만 책임을 넘기는 듯한 상황은 담당자로서 큰 어려움으로 다가옵니다.
새로운 도구나 업무 프로세스를 도입해도, 구성원들이 배우는 것에 부담을 느끼거나 "몇 번 써보다가 결국 원래 하던 대로" 돌아가는 일은 비일비재합니다. 특히 업무가 바쁘거나 압박감이 심할수록 익숙하고 편한 예전 방식을 찾게 되죠. 이는 단순히 개인의 게으름이나 저항이라기보다는, 변화에 대한 심리적 안정감 부족, 새로운 방식의 명확한 이점 체감 부족, 그리고 지속적인 지원과 격려의 부재에서 비롯될 수 있습니다.
이러한 조직적, 심리적 장벽 앞에서 거창한 '빅뱅' 방식의 DX 추진은 오히려 더 큰 저항에 부딪힐 수 있습니다. 제가 찾은 해법은 바로 **'작은 시작'을 통해 '빠른 성공'을 만들고, 이를 바탕으로 점진적으로 변화를 확산시켜 나가는 것**이었습니다.
DX 담당자로서 겪었던 어려움 속에서, 다음과 같은 '작은 시작'들이 실질적인 변화의 물꼬를 텄던 경험을 공유합니다.
초기 상황: 저희 회사 CX(고객 경험) 부서는 여러 공용 이메일 주소로 고객 문의를 처리하고 있었습니다. HubSpot 도입 초기, 모든 기능을 한 번에 익히는 것에 대한 부담감을 느끼는 팀원들이 있었습니다.
작은 시작: 먼저 개발 작업 없이 바로 적용 가능한 HubSpot의 '공용 받은편지함(Conversations Inbox)' 기능으로 기존 Gmail 채널을 통합했습니다. 여러 메일 계정을 따로 관리할 필요 없이 한 곳에서 모든 고객 문의를 확인하고 담당자를 지정할 수 있게 되자, CX팀은 "오히려 편해졌다"는 긍정적인 반응을 보였습니다.
다음 단계로 확장: 몇 달 후, CX팀이 HubSpot Inbox 기능에 충분히 익숙해지고 그 편리함을 체감하게 되었습니다. 이 긍정적인 경험을 바탕으로, 기존 홈페이지에서 사용하던 외부 채팅 서비스('해피톡')를 'HubSpot 챗봇' 및 '실시간 채팅'으로 전환하고, 이 역시 Inbox로 통합하는 더 큰 변화를 추진했습니다. 이 작업은 개발팀의 협조가 필요했지만, CX팀은 이미 HubSpot Inbox 환경에 대한 신뢰와 익숙함이 있었기에 새로운 채팅 시스템 도입에도 큰 거부감 없이 빠르게 적응했습니다.
결과 및 교훈: 이후 CX팀은 HubSpot의 이메일 템플릿, 스니펫, 자동 응답 규칙 등 다양한 기능을 적극적으로 활용하며 더 빠르고 일관된 고객 응대가 가능해졌습니다. 처음부터 모든 것을 바꾸려 했다면 어려웠을 변화가, **'작은 성공'과 '점진적인 익숙함'을 통해 자연스럽게 수용되고 더 큰 DX 효과**로 이어진 것입니다.
(출처: 허브스팟)
사례 2: '플로우' 프로젝트 관리 표준화 - 네이밍 규칙 통일만으로 업무 효율 UP!
문제 상황: 저희가 개발하고 사용하는 협업툴 '플로우' 내에서도 초기에는 프로젝트명이나 개별 업무명의 작성 규칙이 팀별, 개인별로 일관되지 않아 필요한 정보를 검색하는 데 시간이 걸리거나, 담당자 변경/부재 시 업무 내용을 파악하는 데 어려움이 있었습니다.
작은 시작 (규칙의 도입): 새로운 기능 개발이나 시스템 변경 없이, 기존 '플로우' 사용 방식에서 **프로젝트명, 업무명, 관련 태그 등에 대한 표준 네이밍 규칙을 정의**하고 전사적으로(또는 특정 주요 부서부터) 가이드라인을 공유하며 교육을 진행했습니다. 예를 들어, 프로젝트명은 '[부서명/TF명]-[프로젝트 종류]-[연도]' 형식으로, 업무명은 '[요청/문의/오류]-[세부 내용]' 형식으로 구체화했습니다.
결과 및 교훈: 이 '작은 규칙' 하나만으로도 플로우 내에서 필요한 프로젝트나 업무를 검색하고 찾는 시간이 눈에 띄게 단축되었습니다. 신규 팀원이 합류하거나 담당자가 변경되어도 업무 히스토리를 이해하기 훨씬 수월해졌고, 업무 누락 방지에도 기여했습니다. 이는 **큰 시스템 변경 없이 '업무 방식의 표준화'라는 작은 변화만으로도 DX를 개선하고 팀의 효율을 높일 수 있음**을 보여준 경험이었습니다. 중요한 것은 리더의 의지와 구성원들의 적극적인 참여 유도였습니다.
인식의 장벽: 많은 동료들이 '자동화'나 'API 연동'이라고 하면 매우 복잡하고 개발자들만 할 수 있는 어려운 기술이라고 생각하는 경향이 있었습니다. 이로 인해 자신의 업무에서 반복적이고 비효율적인 부분을 발견하더라도 개선 아이디어를 내거나 자동화를 시도하는 것을 주저했습니다.
작은 시작 (경험의 제공): 이 인식을 바꾸기 위해, DX 담당 부서에서 먼저 **Google Sheets와 몇 줄의 간단한 Google Apps Script를 사용하여** 영업팀에 그렇게 특별하지는 않지만 있으면 매우 편리해지는 기능들을 만들어 주었습니다. 그리고 이를 팀별 미팅에서 시연하고, 원하는 팀에게는 해당 스크립트 템플릿을 공유하거나 간단한 교육을 제공했습니다.
결과 및 교훈: "API 연동이나 자동화가 생각보다 접근하기 쉽고, 내 업무와 관련된 다양한 곳에 활용될 수 있구나!"라는 긍정적인 인식이 전파되기 시작했습니다. 몇몇 팀에서는 AI를 이용하여 스스로 간단한 자동화 스크립트를 만들어보는 등 적극적인 모습을 보이기도 했습니다. 이는 **혁신적인 아이디어는 결국 많은 사람들의 다양한 경험과 작은 시도에서 나온다는 것을 확인**시켜 주었습니다. 따라서 DX를 추진할 때, 많은 구성원이 '작은 성공'이나 '새로운 기술 경험'이라도 직접 해볼 수 있도록 지원하는 것이 매우 중요하다고 느꼈습니다.
이러한 작은 성공들은 DX를 위한 중요한 첫걸음이지만, 이것이 지속적인 문화로 정착되기 위해서는 꾸준한 노력이 필요합니다. DX 담당자로서 저는 다음과 같은 점들을 중요하게 생각합니다.
진정한 DX는 단순히 최신 기술이나 비싼 도구를 도입하는 것이 아니라, 조직 구성원들의 일하는 방식과 생각의 변화를 이끌어내는 여정입니다. 그리고 그 변화의 시작은 거창한 계획이 아닌, 오늘 당장 해결할 수 있는 '아주 작은 불편함'을 찾아 개선하려는 시도에서 비롯될 수 있습니다.
이 글을 읽는 여러분도 각자의 업무 환경에서 '작은 시작'을 통해 DX의 성공을 경험하시길 바랍니다. 작은 변화가 때로는 예상치 못한 큰 혁신을 가져올 수 있습니다. 최근에는 대형 프로젝트의 성공만이 업무 혁신을 의미하지 않는다는 것을 깊이 깨닫고 있습니다.
긴 글 읽어주셔서 감사합니다.