"옛날 게 더 좋았어요" 사용자의 저항 속에서 배운 것
최근 우리나라를 뜨겁게 달군 이슈가 있었습니다. 바로 '국민 메신저'라고 불리는 카카오톡의 대규모 UI 개편과 그에 따른 사용자들의 엄청난 반발이었죠. "누구를 위한 개편이냐", "돌려달라"는 목소리가 컸습니다.
지난주에는 제가 다니고 있는 회사도 몇 년 만에 사내 포털 화면을 개편했습니다. 기존에 익숙하게 사용하던 화면이 하루아침에 달라지니 저 또한 많이 어색하고, 매일 사용하던 출퇴근 버튼의 위치도 낯설게 느껴졌었죠.
기획자임과 동시에 한 명의 사용자로서, 저도 이런 생각을 했습니다.
'사람들은 변화를 싫어한다.'
사실 이 생각은 요즘 제가 매일 마주하는 현실입니다. 오늘은 제가 역으로 서비스 제공자로서 느끼고 있는, 저희 서비스를 사용하고 있는 사용자의 저항과 제가 그 저항을 이겨내고 있는 경험을 공유해보려 합니다.
1. 내가 마주한 '저항'의 현장
저는 지금 사내 프로젝트 관리 도구를 기획하고 있습니다.
저희는 기존에 사내에서 사용하던 프로젝트 관리 도구(이하 '기존 도구')가 있었지만, 시간이 지나며 기술적으로 노후화되어 더 이상 새로운 기능을 개발하거나 유지보수하기가 어려운 한계가 있었습니다.
그래서 저희 팀은 이 '기존 도구'를 대체할 새로운 프로젝트 관리 도구(이하 '후속 도구')를 만들었고, 현재 '기존 도구'에서 '후속 도구'로의 데이터와 사용자 마이그레이션을 진행하고 있습니다.
팀원들과 야심 차게 "더 나은 시스템"을 외치며 후속 도구를 오픈했지만, 사용자들의 반응은 저희의 기대와는 사뭇 달랐습니다. "기존 도구에서는 되던 기능인데, 후속 도구에는 왜 없나요?", "UI가 바뀌니까 너무 불편해요. 그냥 기존 도구 쓰게 해 주세요."등의 의견이 주를 이루었습니다.
분명 후속 도구에는 기존 도구의 단점을 보완하고 더 깔끔한 UI와 사용성 측면에서 더 나은 사용자 경험을 제공하는 부분도 있었습니다. 하지만 동시에, 개발 과정 중에서 기능 우선순위에서 밀려나거나 새로운 정책에 맞춰 제거된 기능들도 존재합니다. 사용자들은 바로 그 '사라진 현재'에 반응하고 있었습니다.
2. 기획자와 사용자는 '서로 다른 곳'을 보고 있었다
처음에는 너무 극명한 부정적인 반응으로 인해 '분명 더 좋아진 부분들이 있는데, 왜 몰라줄까?' 하는 생각과 함께, ‘기존 시스템은 문제가 발생하면 더 이상 유지보수가 힘든데, 그땐 결국 본인들 업무에 손해일 텐데..’하는 억울한 마음도 잠시 들었습니다. 하지만 한발 물러서서 생각해 보니, 기획자인 저와 사용자들은 완전히 다른 곳을 바라보고 있었던 것 같습니다.
사용자는 '현재의 익숙함'을 잃는다.
사용자들에게 기존 도구는 단순히 '기능'이 아니었던 것 같습니다. 지난 몇 년간 매일 사용하며 손에 익은 '업무 방식 그 자체'였습니다. 어떤 버튼이 어디에 있는지, 이 기능을 누르면 다음엔 무엇이 나오는지 익숙한 패턴이 있었죠.
하지만 새롭게 개발한 '후속 도구'는 사용자에게 새로운 환경에 대해 다시 학습해야 하는 '비용'을 요구했습니다. 일례로 기존 사용자들이 사용하던 일부 기능이 후속 도구에서 제외된 것은 사용자들 입장에서는, 다른 여러 새로운 개선 방향에 공감하기도 전에 명백한 '기능 손실'로 먼저 다가왔습니다.
사람들은 '미래의 이득'보다 '현재의 손실'에 훨씬 더 민감하게 반응한다는 성향을 정말 현실에서 마주한 순간이었습니다.
기획자는 '미래의 가능성'을 본다.
반면, 초기 기획 단계에서 저희 팀이 바라보는 방향은 달랐습니다. 저희 눈에는 기존 도구의 '현재'가 아닌 '한계'가 보였습니다. 애초에 서비스 기술 스택도 매우 노후화되었고, 해당 서비스를 유지보수하거나 개발할 수 있는 개발자가 단 한 명뿐이라 부재 시 문제가 발생했을 때 대응조차 할 수 없는 구조였습니다.
저희가 후속 도구를 통해 본 것은 당장의 기능 하나하나가 아니라, '확장성', '안정성', 그리고 앞으로 변화하는 기술 환경에 맞추어 새로운 프로젝트 관리 방식을 담아낼 수 있는 그릇과 같은 '미래의 가능성'이었습니다. 사용자가 매일 쓰는 버튼 위치에 집중할 때, 저희는 더 이상의 확장 가능성이 없는 레거시 시스템을 통째로 교체하는 일에 집중하고 있었던 것이죠.
사용자는 '즉각적인 현재의 고통'을 호소하고, 기획자는 '추상적인 미래의 약속'을 하고 있었으니, 돌아보니 그 간극으로 인한 영향들은 어쩌면 언젠가는 반드시 찾아올 현실이었던 것 같습니다.
3. '저항'을 '설득'의 과정으로 만들기
카카오톡 사례에서 보았듯이, 이 간극을 무시하고 "우리가 만든 게 더 좋으니 그냥 쓰세요"라고 말하는 것은 가장 위험한 접근 방식입니다. '익숙함'이라는 것은 어쩌면 변화에 대한 저항의 요소가 됨과 동시에 서비스 이탈을 방지하는 강력한 무기가 되기도 하기 때문이죠.
때문에 사용자의 저항은 '장애물'이 아니라, 우리가 미처 고려하지 못했거나 그 중요도를 낮게 평가했던 부분을 알려주는, 어쩌면 가장 강력한 시그널로 받아들여야 하는 것 같습니다.
그래서 저는 이 '저항'을 '설득'과 '소통'의 과정으로 바꾸기 위해 계속해서 고민했고, 크게 3가지 방향성을 설정하고 직접 사용자들을 만나러 다니기 시작했습니다.
첫째, 우리가 왜 변해야 하는지 투명하게 공유했습니다.
저는 기존 도구 사용 조직의 PM분들을 모두 찾아다니며, 우리가 왜 후속 도구를 만들게 되었는지, 우리는 어떤 기능 개발 로드맵을 가지고 있는지, 현재 어떤 기능들이 준비되어 있는지 등을 설명함과 동시에 '왜 지금 이 변화가 필수적인지'에 대해 직접 설명하기 시작했습니다.
확실히 단순 메신저를 통한 소개나 통보 형식이 아닌, 직접 찾아가서 분명한 이유와 계획에 대해서 설명하니 기존 도구 사용 조직에서도 조금 더 열린 자세로 이야기를 들어주셨던 것 같습니다.
둘째, '사라진 기능'에 대한 피드백을 최우선으로 대응했습니다.
사용자들이 가장 크게 불만을 표했던 '기존 도구에서 사용하고 있었는데, 후속 도구에는 없는 기능'들을 기존 사용 조직들을 찾아가며 전수 재조사를 했습니다.
예를 들어 특정 기능에 대해 왜 없냐고 하면 "그 기능은 저희가 미처 파악하지 못했습니다. 백로그로 등록하고 우선순위를 높여서 2~4주 내로 개발하여 직접 테스트해 볼 수 있도록 제공하겠습니다."라고 빠르게 인정하고 반영했습니다. 혹은 구조상 사라질 수밖에 없었던 기능에 대해서는 "그 기능은 후속 도구의 새로운 정책과 맞지 않아 제외되었지만, 대체된 방식으로 업무를 하실 수 있습니다."라고 대안을 제시하고 가이드를 함께 제공하는 형식으로 대응했습니다.
셋째, 당장의 완벽함보다 '함께 만들어간다'는 인식을 주려 노력했습니다.
내부 팀에서는 이렇게 직접 사용자들의 목소리를 들으러 다니고, voc를 백로그로 구성하여 다음 스프린트에 반영하는 프로세스를 형성했습니다. 그리고 기능 개발이 완료되면 2주에서 4주 정도 실제 기존 도구의 데이터를 후속 도구로 마이그레이션 하여 제공한 후 파일럿 테스트 기간을 충분히 가지며 피드백을 받고 개선하는 모습을 지속적으로 보이기 위해서 노력했습니다.
이러한 과정을 거치니, 절대 이동하지 않을 것 같은 조직들이 하나둘씩 마이그레이션을 하기 시작했고, 이제는 아직 미처 찾아가지 못한 기존 도구 사용 조직에서 먼저 연락이 와서 마이그레이션을 희망한다는 일도 생기기 시작했습니다.
4. 마치며
물론 '변화'라는 것이 무조건 부정적인 요소임을 의미한다고 이야기하는 것은 아닙니다.
오히려 AI나 새로운 기술의 발전에 따라 우리가 그동안 고수하던 UI/UX 패턴도 정말 빠르게 변하고 있고, 또 세대에 따라 사용 경험이 달라지는 지금, '변화'는 더 나은 서비스를 위해 피할 수 없는 현실이기도 합니다.
그렇다면 이러한 환경에서 기획자에게 정말 중요한 것은, 그 변화된 환경을 사용자가 받아들이는 과정에서 느낄 수밖에 없는 '저항'을 어떻게 관리할 것인가에 대한 고민이지 않을까 생각합니다.
기획이란 단순히 새로운 기능을 제공하는 것 외에도, 사용자들이 기존의 익숙함('기존 도구')에서 새로운 가능성('후속 도구')으로 무사히 이동할 수 있도록 돕는 '변화 관리'도 정말 중요한 요소라는 것이 이번 프로젝트를 통해 제가 가장 크게 배우고 있는 부분입니다.
물론 '기존 도구'에서 '후속 도구'로 마이그레이션 하는 과정이 지금도 순탄치 않고, 여전히 기존 도구를 사용하고 있는 여러 조직에서 저희가 개발하고 있는 후속 도구에 대해 아쉬움을 표현합니다. 하지만 계속해서 그 목소리를 '저항'이 아닌, 우리가 더 나은 방향으로 나아가기 위해 반드시 들어야 할 '피드백'으로 받아들이고, 나아가 제한된 리소스와 우리가 설정한 새로운 방향성 안에서 어떻게 하면 사용자의 목소리를 최대한 반영할 수 있을지 고민하려 합니다.
