기고 | 셰어포인트로 애플리케이션 개발 요구 사항 줄이기

많은 기업들이 주간이나 월간이 아닌 연간 단위로 애플리케이션 개발 요구 사항을 측정하고 있다. 셰어포인트를 사용해 이런 개발 요구 사항을 줄이고 올바른 방향 설정을 할 수 있는 방법에 대한 몇 가지 중요한 팁이 있다.

CIO들이 기업의 성공을 도울 수 있는 방법은 언제나 있다.

어떤 기업에서 일하느냐와 상관없이 일부 새 애플리케이션을 통합하고, 문제를 해결해 줄 COTS(Commercial Off-The-Shelf) 제품을 찾을 수 없을 때, 특정 부서를 위해 일부 애플리케이션을 개발해 달라는 요청이 끊이지 않을 것이다.

그리고 오늘 날 많은 CIO들은 해야 할 일이 산더미 같은데도 불구하고 예산은 그대로거나 축소돼 어려움을 겪곤 한다. 따라서 선망의 대상이 되는 CIO와 같은 직책을 맡고 있다면 제한된 예산으로 적재적소에서 인력을 활용하는 것이 항상 도전이 된다. 이는 '기업 내부의 만족도를 높이고, 구축해야 할 애플리케이션 잔량을 줄이려면 어떻게 해야 할까?'라는 질문으로 이어진다.

문제 파악하기
가장 먼저 깨달아야 할 부분은 애플리케이션 개발 요구 사항이 빙산의 일각과 같다는 것이다. 공식적으로 리스트에 오르기에 충분히 크고 가치 있는 프로젝트만 볼 수 있다는 점에서 그렇다. 이면에는 더 규모가 작고 덜 중요한 기업의 일부 요구에 따라 개발해야 하는 애플리케이션들이 있다. 최소 기준을 넘지 못했기 때문에 리스트에 등재되지 못했을 뿐이다.

대부분의 기업들은 이런 공식적인 최소 기준을 보유하고 있느냐와 상관없이 일부 프로젝트는 리스트에 올릴 가치가 없다는 점을 터득하고 있다. 개발 요구 사항으로 남아있는 요청이 얼마나 오래된 것인지 고려해보기 바란다. 또 많은 기업들이 주간이나 월간이 아닌 연간 단위로 애플리케이션 개발 요구 사항을 측정하고 있다.

무엇 때문인가?
애플리케이션의 목록을 작성하는 이유는 현재의 비용이 기업에 중요하기 때문이다. 또 다른 이유로는 기업이 스스로 솔루션을 풀 수 없기 때문이다. 만약 기업이 독자적으로 솔루션을 만들어 낼 툴과 기술을 가지고 있다면 최적일 것이다.

전통적으로 기업들이 독자적으로 솔루션을 만들 수 있을 때 문제를 초래했던 마이크로소프트 액세스(Microsoft Access)와 같은 툴들이 있었다. 문제는 기업이 어쩔 수 없이 독자적으로 솔루션을 만들어야 하기 때문이 아니라, 문제 있는 기술을 선택해서였다. 또 기업의 독자 개발 분야를 이해하기 위한 충분한 정보 공유도 없었다. 사용자는 독자적인 솔루션을 개발할 수 있고, 커뮤니케이션을 개선할 수 있는 더 나은 플랫폼을 선택해야 한다. 그래야 사용자가 구축한 솔루션과 관련된 부정적인 측면을 효과적으로 제거하고 기업이 혜택을 움켜쥘 수 있다.

현황은?
모든 설문 결과가 마이크로소프트 셰어포인트의 시장 침투율이 대단하다는 점을 보여주고 있다. 마이크로소프트의 조사 결과에 따르면, 포춘 500대 기업의 78%가 셰어포인트를 사용하고 있다. 사실 대부분의 기업에서 효과적으로 셰어포인트를 쓸 수 있다. 공식적으로 지원하는 플랫폼이 아니더라도 말이다. 그리고 셰어포인트는 대부분의 기업들이 보유하고 있음에도 불구하고 일반적으로 충분히 활용하지 않고 있는 플랫폼이다.

많은 기업들에서 셰어포인트의 활용도가 떨어지는 이유는 협력 촉진 목적으로 지원했었기 때문이다. 이보다 뚜렷하지 않은 이유는 알려진 바가 없었다. 일부 사용자가 협력 업무를 수행하는 데는 성공적이었다. 그러나 다른 많은 사람들은 활용법을 확신 못했다. 아마도 일부 기업들은 셰어포인트를 소규모 문서 관리 시스템으로 도입했을 수 있다. 그리고 현재의 기준에서 보자면 파일을 저장하기에는 너무 비싸지고 있다.

대부분의 경우, 기업 사용자들은 독자적으로 솔루션을 개발하는데 따른 가치를 보지 못했다. 또 비즈니스 부문의 플랫폼 활용 인식이나 욕구를 창출할 능력도 갖고 있지 않다.

도입과 참여
인프라 담당 팀이 셰어포인트를 지원하고 있다고 가정해보자. 기술적으로도 문제가 없다. 하지만 도입률은 기대치에 못 미칠 것이다. 인프라 팀은 "왜 셰어포인트를 사용하지 않을까? 익스체인지(Exchange)를 설치했을 때와 동일한 일을 했다. 그런데 먹히지 않는다"라고 말할 것이다. 답은 익스체인지, 더 자세히 말해 이메일은 성숙한 서비스라는 사실에 있다.

필자는 1990년대 초 기업들이 이메일 도입에 나섰을 때를 기억한다. 새롭고 사용하기 어려웠지만, 강력했기 때문이다. 인프라 팀은 구축만 하면 사람들이 따라올 것이라고 기대하고 있다. 그러나 사람들에게 익숙하지 않은 방식으로 구성된 툴에는 적합하지 않다.

셰어포인트 도입에서 근본적인 문제는 이메일과 비교하기 때문이다. 이런 비교는 잘못됐다. 이메일은 독자적인 솔루션이기 때문이다. 또 그 핵심을 들여다봤을 때 솔루션 구축을 위한 플랫폼이 아니다. 메시지 전달과 커뮤니케이션을 위한 툴이다. 유용할 수 있도록 이메일에 무언가를 구축하듯 할 필요가 없다. 셰어포인트는 이런 구축 없이도 유용할 수 있다. 그러나 기업이 이를 기반으로 솔루션을 구축할 때 가장 가치가 있다.

사용자가 부가가치 창출을 위해 또는 수용을 위해 셰어포인트를 사용할 필요가 없다. 대신 소수의 사용자들은 다른 사람들이 사용할 수 있는 플랫폼에 솔루션을 구축하는 활동에 온전히 참여해야 한다. 이런 참여와 솔루션 창출은 셰어포인트의 도입을 견인하는데 중요하다. 또 기업 가치 창출에는 더욱 중요하다.

비용
참여를 이끌어내서 애플리케이션 개발 요구 사항을 줄이기 위한 실제 비용은 돈이 아니다. 이는 이미 실행에 옮긴 투자를 바라보는, 그리고 이런 투자에 따른 교육과 선진 사례에서 더 큰 파급효과를 가져오는 방식을 바꾸는 것이다. 성숙한 학습 방법을 계획해 더 많은 사용자들이 독자적인 솔루션 창조 활동에 참여할 수 있도록 이끌 수 있다. 또 애플리케이션 개발 팀이 덜 관여해도 된다. 현업의 요구사항을 해결하도록 지원하기 위해 이러한 참여식 접근법을 활용함으로써 기업은 커뮤니케이션 수준을 높이고 애플리케이션의 구축 건수를 최소화하고, 진행중인 사업과의 관계를 강화할 수 있다.

*Robert Bogue는 현재 셰어포인트 서버를 위한 8번째 마이크로소프트 MVP 수상자로 엔드 유저를 위한 셰어포인트 가이드를 포함해 22권의 저서를 발간했다. 그는 마이크로소프트 패턴 및 프랙티스 챔피언이기도 하며 포춘 500 대 기업을 대상으로 셰어포인트를 더 잘 활용할 방법에 대해 컨설팅을 제공하는 국제적으로 유명한 연사이기도 하다. ciokr@idg.co.kr