[컴퓨터월드] IT 조직에 모빌리티(mobility)를 통합할 때 가장 어려운 점은 △부족한 스킬 세트를 탐색하고, 생성하며, 조율하는 것과 함께, △IT 조직 내부나 외부 어디에 해당 스킬 세트를 배치할 것인지를 결정하고, △모든 이해 관계자들과 모범사례를 공유하는 것이다.

기업 내에서 모빌리티 스킬 세트는 대부분 IT 조직 내 조금씩 산재해 있거나 특정 사업 부서에 집중되어 있다. 어느 사업 부서에 집중되어 있는가는 해당 기업의 비즈니스 목표에 따라 달라지며, 때로는 특정 비즈니스 리더의 정치적 영향력이라든지 예산에 따라 달라지기도 한다.

모빌리티 스킬 세트와 지식이 아직은 통상적인 것이 아니기 때문에 IT 조직에서는 조직 내 모빌리티 인재 보고 구조를 가능한 중앙 집중화해야 한다. 모빌리티가 점차 ‘일상적인 업무’로 스며들게 되면 다른 영역으로 확대될 수 있다. 하지만 오랜 기간 IT의 특징이 되어 온 중앙화된 ‘지휘 통제’ 조직은 더 이상 적용되지 않는 것이 현실이다.

일부 기업에서는 IT 조직이 여전히 고도로 중앙 집중화되어 있지만 다른 기업에서는 그 역할이 사업 부서들을 조율, 컨설팅, 지원하는 쪽으로 변하고 있다. 사업 부서들은 모빌리티 주도권을 개발하는데 필요한 인력과 예산, 고객과의 근접성을 가지고 있다.

이러한 모든 요인들이 IT 그룹이 모빌리티와 관련해 내리는 조직 의사결정에 영향을 미치게 될 것이다. CIO, IT I&O(Infrastructure and Operations: 인프라와 운영) 매니저, 보안 매니저, 개발자들은 모빌리티를 성공적으로 IT 조직에 통합시키기 위해 다음의 6가지 사항을 명심해야한다.

1. 복합 기능 모빌리티 감독 팀(Cross-Functional Mobility Oversight Team) 설립 또는 기존 모바일 최고 기관(MCoE: Mobile Center of Excellence)의 활용

복합 기능 모빌리티 감독 팀의 역할은 모빌리티 프로젝트로 인해 발생할 새로운 자원 요건뿐만 아니라 IT 조직 내·외부에 있는 기존의 모빌리티 프로젝트 전체를 파악하는 것이다. 이 팀은 모빌리티와 관련해 허용되는 것과 그렇지 못한 것에 관한 규정을 만들고 모빌리티에서 필요한 복합 기능 협력 과정의 거버넌스를 담당하며, 사업부서와 CIO 사무실간의 쌍방향 커뮤니케이션이 가능하도록 연락 담당자 역할을 한다.

IT 조직 전반에 모빌리티의 영향이 커지면 복합 기능 모빌리티 감독 팀은 CIO에게 직접 혹은 CIO 사무실로 보고를 해야 한다. 만약 CIO가 진정한 통합을 원한다면 감독 팀을 가까이 두는 것이 좋다.

IT 조직이 컨설팅/지원/서비스 브로커 역할을 하는 가운데 사업부서는 그룹 대부분의 활동에서 주도적인 역할을 해야 한다. 사업부서가 모빌리티를 주도하는 일부 기업에서는 MCoE가 CIO 실의 고위급 대표들과 I&O(Infrastructure and Operations: 인프라와 운영) 리더들로 구성된 집행 위원회에 보고한다.

보다 규모가 큰 기업의 경우 MCoE는 많게는 20~30명으로 구성되며, 각 멤버가 MCoE에 할애하는 시간은 한 주 또는 한 달 내 몇 시간에 불과하다. 이런 경우 IT 인원들로 구성된 소규모의 운영 위원회가 운영 이슈를 다루고 전체 그룹에게 보고를 하게 된다. 소규모 기업에서는 한 명이 하거나 파트타임 직원들이 팀을 이루어 IT 조직의 역할을 수행할 수도 있다.

권리를 명시한 문서는 장기적으로 모든 모빌리티 이니셔티브를 조율하고 거버넌스를 제공하기 위해서뿐만 아니라 단기적으로 초기 모빌리티 통합 노력을 지원하기 위해서도 필요하다. 커뮤니케이션과 협업 스킬이 우수한 인력을 포함하는 것 또한 중요하다.

IT 내·외부의 모바일 관련 이해 관계자 파악: 공식 모빌리티 통합에 대한 계획 시작 시점에는 대개 IT I&O 직원들로 구성된 MCoE의 운영 위원회가 IT 내부와 사업 부서에서 기존의 모빌리티 프로젝트, 디바이스, 지원 그룹들을 찾는 일을 담당한다. 제3자 활동도 반드시 파악해야 한다. 많은 모빌리티 프로젝트가 공식 IT 조직 범위 밖에서 시작되기 때문에 소규모 독립 활동의 경우 아무도 모르게 진행되기도 한다. 이 경우 노력이 중복되고 기존 자원 활용에 실패하거나 완전한 지원 또는 유지관리가 불가능해질 수도 있다.

모빌리티 감독 팀은 프로젝트를 파악하는 동시에 프로젝트 발주 조직(project owner)을 알아내야 한다. 발주 조직은 IT 조직 내 공식 그룹, IT 조직/사업부서/개인의 비밀개발조직(skunkworks)일 수 있다. 어떤 경우에는 모빌리티 프로젝트가 VAR(Value-Added Reseller: 부가가치 재판매업자), 컨설턴트, 계약업체 등 제3자에 의해 시작되기도 한다. 이러한 제3자들은 희귀 코드(orphan code)를 남겨 나중에 IT 조직의 지원을 받아야만 한다.

MCoE는 이러한 프로세스로 CIO와 협력함으로써, IT 조직이 어떤 프로젝트를 맡아야 하는지 혹은 기존의 발주 조직이 프로젝트를 그대로 맡아야 할지를 결정한다. 이러한 결정 아래 모든 IT 그룹(운영, 인프라, 보안, 지원 및 아키텍처 등)의 매니저들은 필요한 스킬 세트, 추가 인원, 예산 등과 관련해서 CIO와 협력할 수 있다.

거버넌스 및 검토 규정 수립: MCoE는 IT 조직 내·외부 모든 모빌리티 이해 관계자들을 위해서 협업 프로세스 수립을 지원할 수 있는 이상적인 위치에 있다. 이 협업 프로세스에는 신규 프로젝트 알림, 모든 비즈니스와 최종 사용자 요건 합의, 모바일 프로젝트를 상시 IT 지원 활동으로 전환하는 데에 필요한 확실한 아키텍처와 운영 요건 등이 포함된다.

모바일 규정이 있을 경우, 그 규정이 전반적인 기업 IT 규정과 일치하는 지 반드시 검토되어야 한다. 일치하지 않으면 모바일과 IT 규정을 재검토해서 일치시키는 것은 물론이고 여러 플랫폼을 거쳐 엔드-투-엔드 커버리지를 확보하도록 해야 한다.

쌍방향 커뮤니케이션 위한 사업부서와 CIO실 간 연락 담당자 역할 수행: MCoE는 IT 전략과 규정에 대해 모든 사업부서와 이야기할 수 있어야 하며, 동시에 부서의 의견을 수용해서 규정과 전략을 업데이트해야 한다. 이는 비즈니스 리더들이 목표를 달성할 수 있도록 돕는다. 커뮤니케이션 프로세스를 비롯해 모든 규정과 전략에 대한 검토는 적어도 1년에 한 번은 이루어져야 한다.

MCoE는 사업부서의 모바일 프로젝트 발주자와 모바일 애플리케이션 개발 팀이 IT 자원(네트워크 대역폭, 데이터 스토리지, 보안, 컴플라이언스, 운영 준비)에 미치는 영향을 평가할 수 있도록 지원한다. 그리고 사업부서의 비즈니스 요건에 귀를 기울이고, 모빌리티 프로젝트 계획을 조기에 통보 받을 수 있도록 절차를 마련한다.

또한 MCoE는 I&O 매니저들 간은 물론이고 사업부서 전반에서 모빌리티 관련 문제를 해결할 수 있도록 모범 사례를 공유할 수 있는 자리를 마련해야한다.

2. 무선 네트워크를 기존 IT 네트워크 운영 그룹에 맞춰 조정

무선 운영 그룹만의 툴과 프로세스는 다른 네트워크 그룹과는 구별되는 특징을 계속해서 유지하게 될 것이다. 하지만 중앙 집중화된 보고 체계가 마련되면 네트워크 아키텍처 설계와 대역폭 가용성에 대한 포괄적인 계획 환경이 만들어 진다. 무선 네트워크는 전체 비즈니스 요건을 바탕으로 포괄적인 기업 커넥티비티(Connectivity) 아키텍처에서 필수적인 부분이 되어야 한다.

네트워크 운영 팀과 네트워크 아키텍처 기획자들은 모바일 디바이스로 인한 대역폭 수요 증가를 완전히 이해하기 위해 무선 운영 팀과 긴밀하게 협력할 필요가 있다. 이 그룹들은 무선 아키텍처가 사무실 안에서 제대로 사용되고 있는 지를 보장하기 위해 협력해야 한다. 이를 통해 무선 주파수 방해를 줄이고 업무의 질을 높이며 IP 주소를 관리할 수 있게 된다.

3. 애자일(agile) 모바일 개발 수용

전통적인 애플리케이션 개발은 선형적 접근법을 취하며 예측 가능한 주기에 걸쳐 다양한 IT 운영 그룹으로 전달된다. 반면, 모바일 앱은 모바일 디바이스와 개발 툴 시장과 사용자/비즈니스 요구가 빠르게 변하기 때문에 매달 업데이트 된다. 전통적인 개발 사이클로 모바일 앱을 처리하게 되면 일정이 늦어져 경쟁에서 밀릴 수 있다. 그렇기 때문에 애자일 모바일 개발 팀이 생기고 있다.

애자일 모바일 개발 팀은 필요한 스킬 세트가 모두 하나의 그룹으로 통합되고 팀의 모든 구성원이 전체 프로세스에 개입하는 하나의 반복적인 개발 사이클을 만든다. 이런 팀들은 공식적인 IT 조직 밖의 사업부서 내에 존재하며 계약업체나 벤더와 함께 일하는 경우가 많다.

IT 애플리케이션 개발 매니저가 모바일 애플리케이션을 통합하기 위한 첫 단계는 MCoE와 협력해서 기업과 사업부서 전반의 모든 모바일 애플리케이션 프로젝트에 대한 이해도를 높이는 것이다. 다음 단계는 스킬 세트, 툴, 프로세스, 거버넌스 관점에서 IT 내·외부의 기존 자원을 검토하는 것이다.

마케팅 부서와 같은 사업부서는 이미 예산과 개발자를 확보하고 있다. 이런 경우, IT 부서는 지원, 컨설팅, 조율의 역할을 맡게 된다. IT 애플리케이션 개발 직원들은 풀타임으로 사업부서 내 모바일 개발 팀에서 일하도록 배치될 수도 있고 IT 직원들이 여러 사업부서의 모바일 팀의 연락 담당자로 배정 될 수도 있다. IT 연락 담당자의 주요 역할은 외부 모바일 개발 팀이 애플리케이션을 만드는 데에 필요한 요건을 모두 파악하고, 프로젝트 출범 전에 애플리케이션 운영 팀이 작업하는 모든 신규 프로젝트에 대해 양방향 커뮤니케이션을 활성화하는 것이다. 이를 통해 필요한 백-엔드 IT 자원을 모두 이용할 수 있도록 보장한다.

특정 모바일 개발 그룹을 IT 애플리케이션 그룹의 일부로 공식적으로 포함시킬 것인지 아니면 사업 부서들과 함께 둘 것인지에 대한 결정은 예산을 누가 통제하는지, 어떤 비즈니스 지식이 필요한 지에 따라 달라진다. 고객과 직접 접하게 되는 애플리케이션의 경우에는 어느 정도의 고객 친밀도가 필요한 지에 따라서도 달라진다.

4. 모바일 리스크 분석의 핵심 보안 스킬 세트화

최종 사용자용 모바일 기기는 대부분 보안이 거의 적용되지 않은 기기들이다. 이러한 최종 사용자용 모바일 기기의 확산으로 인해 완전히 새로운 보안 위협이 등장하게 되었다. BYO(Bring Your Own)가 확산되고 기기의 편리성과 생산성이 개선되면서 이를 무시하거나 완전히 제거하는 것은 불가능하게 되었다.

IT 내부는 물론이고, 특히 IT 외부의 사업 부서에서 모바일 애플리케이션 개발이 신속하게 진행되고 있기 때문에 계속해서 개발 주기와 리스크가 생기고 있다. 보안 전문가들은 프로젝트의 전 기간에 걸쳐서 리스크 분석과 완화 지침 마련에 확실하게 집중해야 한다. 마찬가지로 모든 모바일 사례에서 데이터 보안에 대한 집중도 필요하다.

완벽히 보호하는 것은 불가능 하지만 리스크 평가로 어떤 비즈니스에서 어떤 애플리케이션에 대해 어떤 통제가 적절한 것인지에 대해 올바른 결정을 내릴 수는 있다. 예를 들어, 마케팅 목적으로 만들어졌거나 사업부서 내에서 만들어진 모바일 애플리케이션은 고위험 프로파일을 가지고 있을 지라도 비즈니스 혜택은 매우 클 수도 있다.

따라서 리스크 분석을 잘 아는 IT 보안 전문가들은 위험 완화 비용에 대한 실질적인 조언과 함께 보안 위험이 비즈니스에 미치는 영향을 비즈니스 리더들에게 반드시 알려야만 한다. IT 보안 매니저들은 리스크 분석에 정통한 보안 전문가를 고용하거나 기존 직원의 스킬을 향상시켜야 한다. 리스크 분석을 애자일 모바일 애플리케이션 개발 팀 멤버의 필요 요건으로 추가하거나 몇 명의 풀타임 직원에게 지정 팀과 협력하도록 업무를 부여한다.

또한 IT 보안 팀이 전체 조직을 대신해서 리스크 관련 의사 결정을 내리지 않기 위해 IT 부서가 아닌 의사 결정자를 참여시키는 것이 중요하다.

5. 모바일 플랫폼의 최종 사용자 지원을 기존 IT 최종 사용자 또는 클라이언트 컴퓨팅 프로세스에 통합

MCoE는 초기 모빌리티 목록 작성을 위해 사용되고 있는 최종 사용자 모바일 디바이스, 앱, 툴을 파악해야 한다. 이 작업에는 비즈니스 동인과 모든 플랫폼의 중요도는 물론이고 소유자와 사용자를 파악하는 것도 포함된다.

이러한 목록이 마련되면 최종 사용자 컴퓨팅 매니저, 서비스 데스크 매니저, 지원 역할을 맡은 운영/인프라 매니저가 각 모빌리티 플랫폼에 필요한 지원의 수준을 결정해야 한다. 모든 모바일 플랫폼을 같은 수준으로 지원할 수도 없고 그래서도 안 된다.

어떤 최종 사용자 지원 자원(스킬, 툴, 프로세스 등)이 필요한지 파악하기 위해서는 갭 분석을 실시해야만 한다.

분명한 것은 관련 팀 스킬의 일부 또는 전체를 외부적으로 확대 또는 확장해야만 할 경우가 많이 있다는 것이다. 예를 들어, 안드로이드나 무선 커넥티비티를 지원하는 새로운 스킬 세트가 필요할 때가 있다. 이러한 변화는 기존 직무 기술서의 구조를 변경시켜야 할 정도로 매우 큰 변화다. 지원, 엔지니어링 팀은 다음 작업을 할 필요가 있다.

■ 내부적으로 어떤 플랫폼과 통합 지원을 확보하고 있는지 여부와 어떤 것을 외부에서 조달해야 하는지 파악한다.
■ 최종 사용자 지원과 엔지니어링 갭을 파악하고 그 갭을 타깃화된 개발, 고용, 제공자 계약으로 채운다.
■ 직책, 레벨, 보상에 맞춰 스킬을 확장한다.
■ 새로운 플랫폼 지원을 팀 온보딩(onborading), 교차 교육(cross-training), 개인 개발 계획과 통합한다.

6. 모빌리티 영향 감안해 핵심 인프라 팀 운영 가정 재검토

앞서 언급한 조직에 미치는 직접적인 영향 외에도 모빌리티는 모든 기존 인프라 영역에 걸쳐서 오래 전에 만들어진 사용 패턴을 급격하게 변화시킨다. 이러한 변화는 운영 시간, 처리 용량 전망, 일반적인 세션 길이, 동시 사용자 라이센싱 비율, 성장률, 사용자 한 명 당 지원 담당자 수 등과 같은 기존의 핵심 가정을 바꾼다.

기업에서 모빌리티 프로젝트를 계획할 때, 모든 운영 지원 팀은 모빌리티로 인한 변화 가능성을 감안해서 핵심 가정을 검토해야만 한다. 이러한 변화의 예는 다음과 같다.

■ 가용성 요건 변화와 현 유지보수 일정 축소
■ 운용 시간 요건 확대
■ 처리용량 계획 가정의 변화
■ 변동성 증가(모바일 사용 패턴으로 인한 평균-피크 차이 확대)

일부 변화는 프로세스와 툴 변화로 수용할 수 있지만 다른 변화는 잠재적으로 직원채용과 스킬을 변화시킬 것이다. 이러한 영향은 특정 모빌리티 주도권에 따라서는 물론이고 조직마다 차이가 크게 나타날 것이다. 그 결과 각 팀은 서비스와 비용 영향을 명확히 하고 약속한 서비스 수준을 유지하기 위해 공동의 대응 옵션을 마련해야 한다. 이를 위해 잠재적 영향을 예상하고 솔루션을 제안한 다음 그 결과를 다른 팀과 공유할 책임이 있다.

팀 크기와 일정을 확대해서 늘어난 운영 시간을 커버하는 것도 하나의 옵션이 될 것이다. 또 다른 옵션은 진단과 서비스 복구 역량을 개선해서 기존에 상시 운영되고 있는 운영 센터의 수준을 향상시키는 것이다.

조직에 미치는 영향이 겉으로 드러나고 완화 옵션이 파악되면 I&O 리더들은 자금을 조정하고, 기대 수준을 설정하며, 적절한 변화가 이뤄졌고 전달됐음을 명확히 하기 위해 기업 모빌리티 프로그램 팀과 함께 협력해야만 한다.