Implement New Voicemail Solutions with Exchange Unified Messaging

아티클
08/24/2016

Communications and Collaboration

통합 메시징으로 마이그레이션 계획

Jeff Goodwin

한 눈에 보기:

음성 메일의 간략한 역사
마이그레이션 계획 시 고려해야 할 사항
마이그레이션 전략
다중 사이트 문제

기존 음성 메일 시스템에서 통합 메시징 플랫폼으로 마이그레이션하는 작업은 까다로운 프로젝트가 될 수 있습니다.그러나 몇 가지 적절한 계획을 마련한다면 최종 사용자가 겪을 수 있는 모든 장애를 최소화하면서 이러한 마이그레이션 작업을 매우 간편하게 수행할 수 있습니다.실제로

이러한 유형의 마이그레이션 프로젝트를 진행할 때는 서비스 장애 최소화를 가장 우선적인 목표로 삼는 것이 중요합니다.

마이그레이션 진행 중 무엇을 계획해야 할지 파악하기 위해서는 먼저 각 기업에서 음성 메일을 업무에 매우 중요한 응용 프로그램으로 여기는 이유를 이해해야 합니다.이러한 기본 정보를 토대로 통합 메시징으로 마이그레이션할 때 구현해야 할 기능에는 무엇이 있으며 그러한 기능이 관리자에게 중요한 의미를 갖는 이유를 이해할 수 있습니다.

음성 메일의 간략한 역사

여행을 시작할 지점을 모르는 상태에서 목적지에 도달하기 위한 방법을 계획할 수는 없는 법이기 때문에 필자는 기존 음성 메일 시스템의 기원과 아키텍처를 되짚어 보면서 이를 간략히 설명하고자 합니다.누가 최초로 음성 메일 시스템을 창안했는지에 대해서는 논란이 있는 것이 사실입니다.다만 최초의 상용 음성 메일 시스템은 VMX(Voice Message Exchange)로 명명되었습니다.

VMX는 오늘날 흔히 전자 메일을 주고받는 것처럼 원래 회사 내 다른 직원들에게 음성으로 의사를 전달할 방법을 제공하도록 설계되었습니다.이 시스템에는 메시지 보내기, 전달, 회신 등의 명령이 있었습니다.새로운 메시지가 수신되면 메시지 알림이 사용자에게 전달됩니다.알림 방법으로는 외부 호출(사용자의 특정 전화 번호 호출), 메시지 대기 표시(사용자 전화기의 표시등) 등 여러 가지가 있었습니다.

VMX 사용자가 계속 증가하자 여러 조직에서는 음성 메일 시스템 네트워크를 구축하기 시작했습니다.그 결과 기업 전체를 범위로 하는 음성 메일 솔루션이 개발되었으며 이 솔루션을 통해 직원들은 회사 전체 메일 그룹에 브로드캐스트 메시지를 보낼 수 있었습니다.

물론 음성 메일 시스템과 상호 작용하기 위한 방법을 제공하기 위해 TUI(누름 단추식 사용자 인터페이스)를 개발해야 했습니다.이러한 TUI는 세월이 흐르면서 변화했지만 아쉽게도 음성 메일의 표준 인터페이스는 없는 실정입니다.휴대폰에서 음성 메일을 받는 경우 "음성 메시지 청취는 1번을 누르세요." 같은 안내를 들어 본 적이 있을 것입니다.그러나 VUI(음성 사용자 인터페이스)를 사용하는 음성 기반의 음성 메일 시스템이 보편화되면서 TUI의 비중은 예전보다 더 줄어들었습니다.어쨌든 사용자가 특정 인터페이스에 대해 가질 수 있는 선호도를 과소 평가해서는 안 됩니다.

오늘날의 엔터프라이즈 음성 메일 시스템에는분산형 아키텍처와 중앙 집중식 아키텍처라는 두 가지 아키텍처가 사용됩니다.그림 1에서 시애틀, 뉴욕 및 오스틴 지점은 분산형 음성 메일 아키텍처를 갖추고 있는데, 여기서 음성 메일 시스템은 이들 각 지점에 배치되어 있습니다.이와는 달리 런던, 파리 및 글래스고 지점은 중앙 집중식 모델을 갖추고 있는데, 여기서 PBX 인프라는 서로 네트워크로 연결되어 있으며 모든 호출은 런던의 중앙 지점으로 다시 라우팅됩니다.두 모델은 각각 장단점이 있습니다.그러나 분산형 모델에서도 사이트 간에 메시지를 배달할 목적으로 음성 메일 시스템을 서로 네트워크로 연결할 수 있다는 점에 유의해야 합니다.

그림 1 일반적인 2가지 음성 메일 아키텍처 모델 (더 크게 보려면 이미지를 클릭하십시오.)

조직에서 분산형 모델을 사용하기로 결정하는 이유는 크게 3가지를 들 수 있습니다.즉, 로컬 가용성이 필요하고 네트워크로 연결할 수 없는 서로 다른 PBX 시스템을 사용하고 있으며 UDP(Uniform Dial Plan) 제약이 있다는 것이 바로 그 이유입니다.

몇몇 조직에서는 네트워크 연결이 끊긴 경우 로컬 PBX와 음성 메일 시스템이 계속 정상적으로 작동하여 사이트의 모든 시스템 기능을 제공하도록 하는 음성 메일 시스템을 필요로 합니다.IVR(대화형 음성 응답) 시스템은 계속 작동되며 외부 호출자들은 메시지를 계속 남길 수 있습니다.실제로 최종 사용자에게 미치는 영향은 없으며 작업은 계속 정상적으로 진행됩니다.익숙하게 느껴질 수 있는 이러한 이유로 많은 조직에서 Microsoft® Exchange Server를 실행하는 서버를 지역화하고 있는 것입니다.각 조직에서는 이러한 지역화된 서비스 제공 능력이 필요한지 여부를 판단하기 위해 위험 평가를 수행할 수도 있습니다.

기업 인수를 통해 성장하고 있는 조직의 경우 원격 사이트에는 인프라의 나머지 부분과 네트워크로 연결할 수 없는 PBX 플랫폼이 있는 경우가 많습니다.이 경우 조직에서는 많은 비용이 소요될 수 있는 PBX 전면 교체 프로젝트를 진행하거나 사이트를 그대로 유지하고 음성 메일 플랫폼을 네트워크로 연결하여 완벽한 음성 메시징 교환 기능을 제공할 수 있습니다.또한 타사 서버를 활용하여 조직 내 서로 다른 음성 메일 시스템을 네트워크로 연결할 수도 있습니다.

여러 PBX를 네트워크로 연결하기 위해서는 UDP(Uniform Dial Plan)가 필요합니다.UDP에서는 전화기와 음성 메일 내선 번호가 겹칠 수 없습니다.그림 1을 살펴보면 시애틀, 뉴욕 및 오스틴의 내선 번호 범위가 서로 겹쳐 있음을 알 수 있습니다.그 이유는 미국 지역에 있는 사이트에 대한 UDP가 없기 때문입니다.내선 번호 범위를 7자리 또는 10자리로 늘려 UDP를 만들 수도 있지만 이 경우 다른 문제점들이 나타납니다.

즉, 전화기마다 전화 걸기 템플릿을 바꿔야 하고 PBX에서 모든 사용자의 내선 번호를 변경해야 하며 시스템과 통합되는 모든 응용 프로그램을 변경해야 하는 문제가 발생할 수 있습니다.또한 내선 번호 범위를 늘리면 직원들이 다른 곳에 있는 누군가에게 연락하기 위해 7자리 또는 10자리의 번호를 기억하고 눌러야 하는 불편을 겪을 수 있습니다.

이러한 기본 기능과 구조적 문제점들은 지난 수년 동안 개선되었지만 음성 메일의 기본적인 사항은 달라지지 않았습니다.메시지 교환, 네트워킹, 알림 방법, 사용자 인터페이스 및 아키텍처는 모두 마이그레이션을 계획할 때 반드시 고려해야 할 중요한 요소들입니다.

마이그레이션 계획

통합 메시징은 사용자가 음성 메일을 사용하는 방법, 아키텍처 설계 방법 그리고 관리자들이 관리 업무를 수행하는 방법에 이르기까지 조직의 모든 부분에 걸쳐 변화를 가져옵니다.이러한 모든 차이점들은 통합 메시징 시스템으로 마이그레이션할 때 반드시 해결해야 합니다.마이그레이션 계획 시 고려해야 할 사항을 검사 목록으로 나열하면 다음과 같습니다.

메시지 네트워킹 기존 음성 메일 플랫폼에서 Exchange 통합 메시징으로 전환하는 조직은 일정 기간 동안 두 가지 방식을 병용해야 합니다.사용자 조직에서 서로 다른 음성 메일 시스템을 상호 운용할 시스템인 메시지 네트워킹을 이미 배포한 경우에는 기존 시스템 목록에 통합 메시징 시스템을 추가하기만 하면 됩니다.여러 위치에 개별 음성 메일 또는 PBX 시스템이 있는 조직의 경우 메시지 네트워킹을 구축할 것을 적극 권장합니다.

인프라 통합 메시징을 위한 인프라를 설계할 때는 네트워킹 요구 사항, 전화 통신 통합, 서버 배치 등을 결정해야 합니다.기본 배포 전략을 충분히 숙지하지 못한 경우에는 필자의 이전 기사인 "Exchange Server 2007을 사용한 통합 메시징 배포"(technet.microsoft.com/magazine/cc137737)를 참조하시기 바랍니다.

AA(자동 전화 교환) 많은 시스템에서 주간, 야간 및 각 부서별로 서로 다른 다양한 자동 전화 교환 기능을 제공합니다.기존 음성 메일 시스템에서 자동 전화 교환 기능을 사용하려면 해당 조직의 통신 팀과 협력해야 합니다.

MWI(메시지 대기 신호) 솔루션에서 메시지 대기 신호 없이도 기능을 수행하도록 할 수도 있지만 흔히 사용자들에게는 이러한 기능이 필요할 수 있습니다.따라서 빨간색 표시등 알림에 대한 사용자들의 선호도를 간과해서는 안 됩니다.다행히도 몇몇 업체에서 Exchange Server용 메시지 알림 표시등 응용 프로그램을 제공하고 있습니다.

팩스 지원 많은 수의 기존 음성 메일 플랫폼에서 수신 팩스를 지원합니다.또한 Exchange 통합 메시징에서도 수신 팩스 기능을 지원하기 때문에 새로 배포할 때 이 기능을 지원하도록 계획할 수 있습니다.

IVR(대화형 음성 응답) 일부 기존 음성 메일 플랫폼에서는 Exchange 통합 메시징에서는 사용할 수 없는 IVR(대화형 음성 응답) 응용 프로그램을 지원합니다.적절한 대안을 찾을 때까지는 이러한 시스템을 그대로 유지할 수도 있습니다.

관리 Exchange 통합 메시징에서는 Active Directory® 및 Exchange 사서함 서버 역할을 사용합니다.통합 메시징 배포가 관리, 시스템 요구 사항 등에 어떤 영향을 미치는지 계획해야 합니다.

사용자 인터페이스 새 UI를 배포할 경우 사용자를 대상으로 교육을 실시해야 합니다.Exchange 통합 메시징에서는 대부분의 휴대폰 공급업체들이 제공하는 것과 매우 유사한 인터페이스를 사용합니다. 따라서 인터페이스는 대부분의 사용자들이 쉽게 사용할 수 있어야 합니다.또한 음성 인식 기능이 지원되므로 사용자들은 누름 단추를 사용할 필요가 없습니다.Exchange Server에서는 이러한 기능을 Outlook® Voice Access라고 합니다.

교육 통합 메시징은 사용자들이 통신하고 음성 메일을 사용하는 방식에 대한 패러다임을 바꾸고 있습니다.UI 교육 외에도 사용자들에게 최선의 사용 방법과 보다 효율적인 새로운 통신 방법을 제시하기 위한 교육도 함께 실시해야 합니다.예를 들어 사용자들은 받은 편지함에서 음성 메일을 사용하는 방법 또는 일부 고급 통합 메시징 설정을 구성하는 방법을 잘 모를 수도 있습니다.

실제 마이그레이션 전략

대규모 조직에서 통합 메시징 솔루션으로 마이그레이션하는 과정에는 흔히 여러 문제점들이 나타날 수 있습니다.그러나 필자는 지난 10년간 통합 통신 분야에서 일하면서 매우 구체적인 요구 사항이 있는 상당히 복잡한 조직에서도 성공적으로 마이그레이션을 수행한 것을 목격했습니다.

단일 사이트 조직이든, 다중 사이트 조직이든 관계없이 다음 5가지 기본 단계를 중심으로 마이그레이션 전략을 수립한다면 도움이 될 것입니다.

솔루션을 계획 및 설계합니다.
통합 메시징 서버 역할을 설치 및 구성합니다.
파일럿 그룹을 마이그레이션합니다.
파일럿 그룹에서 수렴한 의견을 토대로 설계를 수정합니다.
사용자를 마이그레이션합니다.

물론 다중 사이트 조직은 단일 사이트 시나리오에서는 잘 발생하지 않는 몇 가지 문제를 겪고 있습니다.자세한 내용은 "다중 사이트 문제" 추가 기사에서 별도로 살펴보겠습니다.

솔루션을 계획 및 설계하는 일은 마이그레이션 과정에서 가장 중요한 단계에 해당합니다.이 작업에는 통합 메시징 팀을 배정하는 것이 좋습니다.통합 메시징 팀은 통신, Active Directory, Exchange, 네트워킹, 보안, 교육 및 프로젝트 관리 분야에 대한 전문 지식을 갖춘 조직 내 여러 부서의 담당자들로 구성해야 합니다.또한 조직의 기존 PBX, 음성 메일 및 전자 메일 인프라에 대한 상세한 아키텍처 도면을 확보해야 합니다.

설계가 완료되면 통합 메시징 서버 역할을 설치 및 구성할 수 있습니다.기존 음성 메일 시스템과 병행하여 통합 메시징 서버를 설치하는 것을 주저하지 말아야 합니다.문서에 수록된 최선의 방법을 따라야 합니다.

이제 통합 메시징 서버를 평가해 볼 준비가 되었습니다.사용자들로 구성된 소규모 파일럿 그룹을 지정하여 새 시스템으로 마이그레이션합니다.그룹은 25~50명의 사용자로 구성하면 됩니다.사용자를 신중하게 선별한 다음, IT 및 통신 담당자에서 부장 및 영업 사원에 이르기까지 다양한 사용자 그룹으로 구성된 파일럿 그룹을 만듭니다.이처럼 다양한 유형의 사용자들을 참여시킴으로써 시스템이 대상에 맞게 설계되었는지 여부, 고려해야 할 특정 요구 사항, 사용자들에게 필요한 교육 항목 등을 보다 정확하게 파악할 수 있습니다.

파일럿 그룹의 의견을 수렴한 후에는 테스트 과정에서 밝혀진 모든 문제를 해결할 수 있도록 시스템 설계를 수정해야 합니다.특히 "고려해야 할 사항" 섹션에서 필자가 설명한 항목을 다시 살펴본 후 그러한 사항들을 해당 조직에 맞게 적절히 처리했는지 확인해야 합니다.여기서 수행한 가장 일반적인 변경 사항은 주로 교육과 관계가 있다는 것에 유의하십시오.

마지막 단계에서는 사용자를 마이그레이션합니다.시스템을 프로덕션 환경으로 전면 마이그레이션하는 방법에 대해서는 다양한 의견과 전략이 있습니다.그 중에서 많이 사용되는 두 가지 방법은 점진적 마이그레이션과 일괄 전환(flash-cut)입니다.

수주 또는 수개월의 기간 동안 사용자 커뮤니티를 점진적으로 마이그레이션할 경우 기존 사용자와 통합 메시징 사용자 간에 음성 메일이 단절됩니다.이로 인해 사용자들은 음성 메일을 통해 서로에게 메시지를 전달할 수 없게 됩니다.또한 시스템 설계에 메시지 네트워킹 솔루션을 포함하지 않을 경우 비즈니스 통신 중 일부가 중단됩니다.따라서 이 마이그레이션 방법을 사용할 경우에는 최초 설계 단계에서 메시지 네트워킹 솔루션을 포함하는 것이 좋습니다.

일괄 전환(flash-cut) 마이그레이션에서는 모든 사용자를 한 번에 이동합니다.일반적으로 조직에서는 주말 동안에 이러한 유형의 마이그레이션을 수행하기 때문에 중대한 장애가 발생할 경우 시스템을 테스트하고 구성을 변경하며 마이그레이션을 취소할 수 있는 시간적 여유가 있습니다.

어떤 방법을 선택하든 파일럿 그룹으로부터 수집한 일반적인 질문과 답변을 바탕으로 지원 센터 직원들을 교육해야 합니다.또한 지원 센터 담당자들이 사용자 활성화, 사용자 활성화 여부 검증, 암호 변경 등 주요 작업을 능숙하게 수행할 수 있도록 해야 합니다.

마이그레이션 연습

예제 마이그레이션을 진행할 경우 통합 메시징으로의 마이그레이션을 성공적으로 수행하기 위해서는 내부 및 외부 사용자의 업무 중단을 가능한 최소화하면서 기존 음성 메일 플랫폼에서 통합 메시징으로 사용자의 음성 메일 사서함을 이동하는 데 1차적인 목표를 두어야 합니다.

그림 2에서는 조직의 아키텍처를 자세히 보여 줍니다.이 조직은 이러한 혼합된 Exchange 아키텍처를 변경할 계획이 없습니다.미국에 소재한 지점의 주 데이터 센터는 시애틀에 있습니다.오스틴 지점의 모든 IT 응용 프로그램은 시애틀에서 제공되며 뉴욕 지점은 지역화된 Exchange 서비스를 보증합니다.미국에 소재한 지점들의 음성 메일은 서로 다른 PBX 인프라로 인해 분산되어 있습니다.기술적 측면에서 중앙 집중식 음성 메일을 제공할 목적으로 PBX 인프라를 네트워크로 연결할 수는 없습니다.이와는 달리 유럽에 소재한 지점들의 중앙 집중식 데이터 센터는 런던에 있습니다.유럽에서 운용되는 모든 IT 및 통신 응용 프로그램은 이 중앙 데이터 센터에서 제공됩니다.

그림 2 마이그레이션 이전의 아키텍처 예제 (더 크게 보려면 이미지를 클릭하십시오.)

전체 음성 메일 인프라는 Octel(현재 Avaya) 플랫폼을 기반으로 합니다.모든 음성 메일 시스템은 OAN(Octel Analog Networking)을 통해 네트워크로 연결되어 있습니다. OAN은 아날로그 전화선과 시외 전화를 사용하여 네트워크로 연결된 음성 메일 메시지를 보내는 전용 네트워킹 프로토콜입니다.이 아키텍처에서는 사이트 간의 회사 전체 음성 메시징을 처리할 수 있습니다.

다중 사이트 문제

다중 사이트 조직에서는 통합 메시징을 배포할 때 여러 가지 문제점에 직면합니다.다행스러운 점은 다른 조직에서 이미 발생한 몇 가지 문제점으로부터 교훈을 얻을 수 있다는 것입니다.이 기사에서 모든 문제점을 다룰 수는 없지만 다양한 조직과 함께 작업을 수행하면서 필자가 경험했던 문제점 중 가장 일반적인 몇 가지를 살펴보겠습니다.

"중앙 집중식 Exchange Server 아키텍처와 혼합된 전화 통신 환경을 보유하고 있습니다."

분산 환경은 설계하기 쉽습니다.통합 메시징 서버를 배치하고 이를 각 사이트의 로컬 PBX와 통합하면 됩니다.하지만 중앙 집중식 또는 혼합된 환경이라면 어떨까요?생각해 볼 문제는 바로 "해당 사이트에서 로컬 통합 메시징 서비스가 지속적으로 제공되어야 하는지 여부"입니다.로컬 통합 메시징 서비스가 지속적으로 제공되는 경우 해당 사이트는 중앙 집중식 Exchange 서버와 연결이 끊어질 수 있지만 자동 전화 교환 기능은 계속 제공할 수 있으며 외부 호출자(주로 고객)들은 메시지를 남길 수 있습니다.이 문제에 대한 해답은 해당 사이트가 얼마나 업무에 중요하며 솔루션은 어느 정도 관리가 가능한지에 따라 달라질 수 있습니다.

사이트에서 로컬 통합 메시징 서비스를 지속적으로 제공해야 한다면 해당 사이트에는 원격 통합 메시징 서버가 좋은 해결책이 될 수 있습니다.이러한 경우가 아니라면 로컬 사이트에 SIP 게이트웨이를 설치하면 됩니다.Exchange 통합 메시징은 융통성이 있으므로 PBX 인프라를 네트워크로 연결할 필요가 없고 UDP(Uniform Dialing Plan)에 대한 요구 사항도 없습니다.

"현재 Exchange 아키텍처를 업그레이드하는 중입니다."

많은 고객들이 자신의 Exchange 인프라를 업그레이드하면서도 통합 메시징 마이그레이션을 시작하는 데는 주저하고 있습니다.통합 메시징으로 전환하기로 이미 결정했다면 Exchange 서버가 업그레이드되는 동안 마이그레이션을 진행하는 것이 좋습니다.업그레이드 계획에 따라 마이그레이션을 진행하면 되며 이로 인해 프로젝트가 많이 복잡해지지는 않습니다.

"10명 이하의 직원들이 근무하는 소규모 사이트를 다수 운영하고 있으며 이 사이트 중 일부에는 PBX가 없습니다."

PBX가 배치되어 있는 비교적 작은 규모의 사이트에서는 로컬 사이트에 SIP 게이트웨이를 설치하기만 하면 됩니다.PBX가 없는 사이트의 경우 통합 메시징 시스템으로의 호출 라우팅을 위해 전화를 중앙 PBX로 전달하는 데는 몇 가지 전화 통신 방법을 사용할 수 있습니다.즉, 조직 내부의 규모가 작은 원격 사이트에 매우 저렴한 비용으로 통합 메시징 서비스를 배포할 수 있습니다.

이러한 소규모 사이트는 마이그레이션 수행에 대한 실험실 역할을 한다는 점에 유의해야 합니다.일반적인 마이그레이션 전략 중 하나는 네트워크의 경계에서 시작하여 중심부로 이동하는 것입니다.먼저 소규모 사이트부터 마이그레이션한 다음, 통합 메시징 팀과 사후 검토를 실시하여 성공적으로 진행된 사이트와 문제가 발생한 사이트를 파악하도록 합니다.그런 다음 이 과정에서 얻은 유용한 정보를 또 다른 사이트를 마이그레이션할 때 활용하면 됩니다.

통합 메시징 팀은 네트워크의 경계에서 중심부로 마이그레이션을 진행하기로 결정했습니다.모든 지점에서 통합 메시징 서버는 최선의 Exchange 서버 아키텍처 구축 방법에 따라 배치됩니다.통합 메시징 팀은 "고려해야 할 사항" 섹션에서 설명한 항목들을 염두에 두면서 각 사이트에 해당하는 계획 문서를 작성합니다.이러한 문서는 서버 설치 및 구성, 사용자 교육 그리고 마이그레이션 전략 계획에 사용됩니다.

각 사이트에서 통합 메시징 팀은 사용자들을 통합 메시징 시스템으로 일괄 전환한 후 대안을 찾을 때까지 계속 사용할 IVR 응용 프로그램을 지원하도록 기존 플랫폼을 유지할 계획을 마련합니다.통합 메시징 팀은 마이그레이션을 수행한 후 30일 동안 기다린 다음 또 다른 지점의 마이그레이션 작업을 수행하기로 결정했습니다.이러한 대기 기간은 더 많은 사용자들을 전환하고 지원 센터에 도움을 요청하기 전에 각 사이트가 새 플랫폼에 맞게 조정되었는지 확인하는 데 목적이 있습니다.

조직에서는 오스틴 지점부터 먼저 마이그레이션하기로 결정합니다.오스틴 지점의 전자 메일 서비스는 시애틀에서 제공되므로 통합 메시징 팀은 시애틀에 통합 메시징 서버 역할을 설치하고, 오스틴 지점에는 SIP 게이트웨이를 설치하여 PBX를 통합합니다.기존 음성 메일 플랫폼은 네트워크로 서로 연결되어 있으므로 통합 메시징 팀은 메시지 네트워킹 서버를 설치하여 통합 메시징 플랫폼을 네트워크로 연결해야 하는 문제를 해결해야 합니다.사용자들은 새 시스템에 관한 교육을 받고 마이그레이션은 순조롭게 진행되므로 통합 메시징 팀은 다음 지점인 뉴욕을 마이그레이션하기로 결정합니다.

뉴욕 지점에는 자체 사서함 및 허브 전송 서버가 있습니다.따라서 최상의 방법은 통합 메시징 서버를 뉴욕에 설치하는 것입니다.통합 메시징 팀은 마이그레이션 계획 문서에 따라 서버를 설치합니다.이 서버는 음성 메일 네트워크에 포함될 메시지 네트워킹 서버의 노드 목록에 추가됩니다.사용자들은 교육을 받고 통합 메시징으로 순조롭게 마이그레이션됩니다.

오스틴 지점의 마이그레이션 과정에서 시애틀 지점에는 이미 통합 메시징 서버가 배포되었습니다.통합 메시징 팀은 시애틀과 오스틴 지점 모두를 지원하는 데 충분한 수의 음성 메일 포트가 이 서버에 있는 것을 확인합니다.시애틀 지점의 사용자들은 교육을 받고 통합 메시징으로 마이그레이션됩니다.

유럽의 아키텍처는 설계하기가 훨씬 더 수월합니다.PBX 인프라는 네트워크로 연결되어 있으며 Exchange는 중앙 집중화되어 있습니다.통합 메시징 서버는 런던에 배포되어 있고 가장 작은 사이트를 시작으로 각 사이트가 마이그레이션됩니다.그림 3에서는 최종 아키텍처를 보여 줍니다.

그림 3 마이그레이션 이후의 아키텍처 예제 (더 크게 보려면 이미지를 클릭하십시오.)

계획 준수의 중요성

필자는 통합 메시징 마이그레이션 실패 문제를 해결해달라는 요청을 여러 번 받았습니다.이들 조직 중 많은 수가 핵심 규칙을 하나 이상 어겼습니다.

첫째, 통합 메시징은 단순히 음성 메일 시스템을 의미하는 것은 아니라는 점을 기억하십시오.이것은 업무 수행에 중요한 응용 프로그램이며 또 그렇게 여겨야 합니다.사용자들은 음성 메일 기술을 사용하여 정보를 교환합니다.이는 비즈니스 응용 프로그램이라는 점을 염두에 두어야 하며 본 기사에서 설명한 모든 고려 사항이 반영될 수 있도록 마이그레이션을 계획해야 합니다.

통합 메시징으로 마이그레이션을 진행할 때는 절대적으로 통신 팀과 함께 작업을 진행해야 합니다.통신 팀은 회사 인프라에 통합되는 전화 통신 응용 프로그램을 누구보다도 잘 알고 있습니다.

통합 메시징으로 마이그레이션을 수행할 때 엔터프라이즈 솔루션에 대해 계획하십시오.초기 단계에서는 단일 사이트만 구현할 수도 있지만 항상 전체 네트워트에 관한 청사진을 마련해 두어야 합니다.예를 들어 메시지 네트워킹을 다른 사이트에는 제공하지 않고 단일 사이트를 구현하면 사용자 간 통신이 영향을 받게 됩니다.이러한 작업은 결코 수월하지 않을 수 있으므로 모든 IT 응용 프로그램을 고려하는 아키텍처를 설계할 때는 전문가와 상의해야 합니다.

마지막으로 교육의 중요성을 간과해서는 안 됩니다.통합 메시징은 사용자들이 통신하고 음성 메일을 사용하는 방식에 대한 패러다임을 바꾸고 있습니다.언뜻 단순하게 보이는 것도 다른 사람들에게는 간단한 문제가 아닐 수 있습니다.올바른 교육은 원활한 전환을 가능하게 하는 지름길입니다.

Jeff Goodwin은 VIA Group의 수석 기술자이자 Exchange 및 통합 메시징 설계 및 배포 분야의 전문가입니다.문의 사항이 있으면 jgoodwin@theviagroup.com으로 연락하십시오.

목차

추가 리소스