비즈니스 소프트웨어 도입 성공 전략 (3): “누가 쓸건데?” – 사용자 중심 도입법

소프트웨어 도입 계획은 보통 사용 부서와 IT 부서 요구사항 취합으로 시작된다.
하지만 “누가 실제로 쓸 것인가”를 충분히 파악하지 못하면, 도입 후 예상 밖의 사용자가 등장하며 요구사항이 충돌하고 프로젝트는 흔들린다.

디지털 자산 관리 프로젝트의 교훈

DAM(디지털 자산 관리) 플랫폼 구축 프로젝트를 직접 경험했다.
시작 당시 예상 사용자는 본사 디자이너와 문안 검토 부서 두 곳이었다.

그런데 프로젝트가 진행되면서 디자인 에이전시, 마케팅 부서, 해외 마케팅, 이커머스 부서까지 잇따라 추가되었다.
오픈 직전에는 뒤늦게 합류한 부서들이 일제히 요구사항을 쏟아내기 시작했고, 그때부터 혼란이 본격적으로 시작되었다.

당시에는 이 현상을 정확히 이해하지 못했다.
초반에 요구사항을 제출하라고 할 때는 내지 않다가, 개발이 끝나고 테스트 시점에 신규 요구사항을 내는 모습을 보며 현업 담당자의 무책임함이나 게으름, 혹은 업무 전문성 부족으로 이해하려고 했었다.

왜 요구사항은 늦게 나오는가

그러나 이후 여러 프로젝트를 하며 현업 담당자들과 함께 일하고 소통하다 보니, 이것은 단순히 개인의 태도 문제가 아니라 구조의 문제라는 것을 알게 되었다.

대부분의 기업은 현재 운영 중인 비즈니스를 기준으로 인력과 업무를 배분한다.
신규 소프트웨어 도입 프로젝트를 하더라도 기존 업무를 완전히 배제하고 프로젝트에만 참여할 수 있는 사람은 극소수다.
대부분은 현업 업무를 수행하면서 프로젝트에 추가 업무로 참여한다.

따라서 바쁜 일과 업무를 마친 뒤, 피로한 몸과 정신으로 프로젝트에 충분한 시간과 정성을 쏟기는 쉽지 않다.
프로젝트 초기에 요구사항 정리가 느슨해지는 이유 중 하나다.

게다가 기존에 소프트웨어 없이 처음으로 도입하는 프로젝트라면, 소프트웨어가 구체적으로 어떤 기능으로 어떤 작업을 도와주고 무엇을 대체할지 감이 잘 오지 않는 경우가 많다.
어느 정도 가시적인 모습이 드러나고 실제 사용이 임박하기 전까지는 요구사항이 선명하게 정리되지 않는 것도 자연스러운 일이다.

결국 많은 현업 담당자는 오픈이 가까워지고 나서야 “이제 정말 내가 써야 하는 시스템”으로 인식한다.
그 시점에서 비로소 구체적인 요구사항이 쏟아지기 시작한다.

현장에서 더 잘 작동하는 방식

그래서 실제 현장에서는 MVP(Minimum Viable Product)를 먼저 만들어 보여주고, 수정하면서 점진적으로 확산(Rollout)하는 방식을 더 선호한다.
초기에 전체 예산 규모를 정확히 가늠하기 어렵다는 단점은 있지만, 변화와 발전의 속도가 빠른 지금은 과거처럼 모든 요구사항과 모든 사용자를 한 번에 정리해 완벽한 소프트웨어를 만드는 일이 점점 더 어려워지고 있다.

오히려 소규모 팀이나 일부 부서를 위해 먼저 만들고, 실제 기능 테스트와 피드백을 거쳐 보완하면서 큰 규모로 확장하는 편이 더 좋은 결과를 내는 경우를 훨씬 많이 보았다.
Agile 방법론에서 차용한 방식으로, 예를 들어 3주 단위로 요구사항을 받아 구현하고 다시 보완하는 흐름이다.

물론 이 방식 역시 프로젝트가 누더기가 되는 경우가 있다.
그러나 오너십을 가진 사람이 책임감 있게 계속 주도하고, 전문가 집단의 지원이 지속적으로 가능하다면 현실적으로 가장 효과적인 접근일 수 있다.

그럼에도 초반에 반드시 볼 것

그렇다고 해서 초반 요구사항 정리가 불필요하다는 뜻은 아니다.
Agile이든 Waterfall이든, 도입 초기에 반드시 파악해야 할 핵심은 있다.
바로 “누가 쓸 것인가”와 “그들은 준비되어 있는가”다.

사용자 범위를 과소 추정하는 이유

IDC 보고서에 따르면 DAM의 실제 사용자는 디자이너뿐 아니라 마케터, 에이전시, 법무 팀까지 광범위하다.
그러나 도입 검토 단계에서는 대개 목소리 큰 부서 중심으로 요구사항이 모이고, 나중에 연결될 사용자들은 초기에 반영되지 않는다.

그래서 초기에는 단순해 보이던 프로젝트가, 실제 오픈이 가까워질수록 복잡해진다.
사용자 수가 늘어날수록 권한 구조, 승인 절차, 파일 분류 체계, 메타데이터 기준, 교육 방식까지 모두 다시 검토해야 하기 때문이다.

AI 시대, 지기(知己) 점검이 더 중요한 이유

사용자 파악이 더 중요해진 이유는 하나 더 있다.
AI 기능 탑재 소프트웨어가 넘쳐나는 시대에는 사용자 역량이 곧 활용도를 결정하기 때문이다.

AI 기능을 제대로 활용하려면 기본적인 디지털 리터러시와 데이터 이해도가 필요하다.
역량이 준비되지 않은 조직에 AI 솔루션을 도입하면, 더 똑똑한 시스템이 들어오는 것이 아니라 더 복잡한 도구를 방치하게 되는 결과가 나오기 쉽다.

지기(知己) 체크리스트

• 실사용자 범위: 현재 파악된 사용자 외에 간접 연관 부서는 없는가?
  뒤늦게 등장한 부서가 요구사항을 바꾸면 초기 설계가 쉽게 흔들린다.
• 디지털 역량: 사용자들의 현재 툴 활용 수준과 변화 수용 의지는 어느 정도인가?
  역량이 낮으면 교육 부담이 커지고, 변화 수용 의지가 약하면 시스템은 빠르게 방치된다.
• 변화관리 리더: 내부 챔피언(Champion)이 있는가?
  조직 안에서 실제 사용을 이끌 사람 없이 도입하면 초기 저항을 넘기기 어렵다.
• AI 활용 역량: AI 기능을 실제로 쓸 수 있는 사용자는 몇 명인가?
  AI는 기능이 아니라 사용 역량과 운영 습관 위에서 성과를 낸다.

지기(知己)의 핵심

소프트웨어는 도구다.
아무리 강력한 AI 기능도 사람과 조직이 준비되지 않으면 ROI는 나오지 않는다.

지기(知己)란 우리 조직의 실제 사용자와 역량을 정확히 파악하는 일이다.
도입 전 사용자 맵을 그리고, 각 사용자 그룹의 역할과 디지털 역량, 변화 수용 수준을 문서화하는 것이 성공의 가장 중요한 출발점이다.