Communications
Exchange Server 2007을 사용한 통합 메시징 배포
Jeff Goodwin
한 눈에 보기:
- 전화 통신 기본 사항
- 통합 메시징 설계 고려 사항
- 사용자 마이그레이션
여러분은 조직 환경에 Exchange Server 2007 통합 메시징을 배포하기로 결정했습니다. 이에 따라 통합 메시징 서버 역할을 설치하고 이를 기존 PBX와 통합했습니다. 이제 여러분을 비롯하여 다른 10명의 직원에게 오는 음성 메일, 전자 메일 및 팩스 메시지가 Exchange에 저장됩니다. 이것으로
중요한 작업은 끝냈다고 생각할 수도 있습니다. 하지만 업무에 영향을 주지 않고 동일한 기능을 여러 사이트에 분산된 수천 명의 구독자에게 배포하려면 어떻게 해야 할까요?
이 문서의 내용이 이러한 작업에 도움이 된다면 좋겠습니다. 이 문서는 사용자 환경에 통합 메시징을 배포하는 방법을 이해하고 배포와 관련된 전화 통신의 개념을 쉽게 받아들일 수 있도록 작성되었습니다. Exchange Server 2007 통합 메시징의 설치, 구성 또는 기능과 관련하여 도움이 필요한 경우 이 문서의 뒷부분에 나오는 "통합 메시징 리소스" 추가 기사를 참조하십시오. 이 외에도 Microsoft는 고객에게 Exchange Server 2007 통합 메시징의 배포, 설계 및 상담 서비스를 제공할 수 있는 통합 메시징 전문 업체를 선별해 놓았습니다. 통합 메시징의 설치, 구성 또는 배포와 관련하여 도움이 필요한 경우 추가 기사에 나열된 전문 업체 중 한 곳에 문의하십시오.
시작
통합 메시징 기술이 Exchange에서 전혀 새로운 기술은 아닙니다. 많은 조직에서는 이미 Exchange와 통합되는 통합 메시징 제품을 제공하고 있습니다. 하지만 Exchange Server 2007은 통합 메시징을 기본적으로 지원하는 최초의 Exchange 버전입니다. 통합 메시징이 소개된 이후 많은 고객이 조직 내 소규모 그룹에 Exchange Server 2007 통합 메시징을 배포했습니다. 하지만 여러 가지 이유로 소규모 그룹을 제외한 다른 사용자에게는 통합 메시징을 배포하지 않았습니다. 가장 큰 이유는 대부분의 Exchange 관리자가 전화 통신의 개념이나 통합 메시징 서비스를 구현하는 데 필요한 기술에 익숙하지 않아서 이러한 솔루션을 설계하여 조직에 배포하는 데 많은 어려움을 겪고 있기 때문입니다.
다른 배포 프로젝트와 마찬가지로 단계별 접근 방법을 취하면 최선의 결과를 얻을 수 있습니다. 통합 메시징 프로젝트는 다섯 단계로 진행되어야 합니다. 여기에는 아키텍처 계획, 솔루션 테스트, 사용자 커뮤니티 파일럿 테스트, 교육, 새 시스템으로 사용자 마이그레이션이 있습니다. 프로젝트를 계획할 때 조직의 IT 그룹과 전화 통신 그룹이 모두 참여하도록 하는 것이 중요합니다.
사용자가 기존의 음성 메일 플랫폼에서 일상적으로 사용하던 여러 기능을 통합 메시징에 복제해야 하며, 이것이 가능하지 않은 경우에는 대체 솔루션을 설계하여 새 시스템 구현 시 사용자가 받을 영향을 최소화해야 합니다. 이것이 바로 전화 통신 팀에서 지원해야 할 핵심 영역입니다. 이와 동시에 전화 통신 팀은 배포 작업이 시작될 때 새 음성 메일 플랫폼을 관리 및 지원하고 관련 문제를 해결하는 데 필요한 사항을 IT 팀을 통해 습득해야 합니다.
전화 통신 기본 사항
통합 메시징의 기본 아키텍처, 호출 흐름 및 관련 용어를 이해하면 계획을 수립하기가 훨씬 쉽습니다. 그림 1에서는 회사의 기존 전화 통신 시스템에 통합된 통합 메시징 솔루션의 예를 보여 줍니다. 지금부터는 이와 같은 방법으로 통합 메시징을 배포할 때 접하게 되는 몇 가지 일반적인 개념 및 기술에 대해 좀 더 자세히 살펴보겠습니다.
그림 1** PBX 및 통합 메시징 솔루션 **(더 크게 보려면 이미지를 클릭하십시오.)
PBX(Private Branch Exchange)는 조직 내에서 사용되는 개인 전화 네트워크입니다. 이 시스템에서 각 사용자는 PBX에 연결된 전화를 사용하며 이 전화를 통해 대개 4자리나 5자리의 내선 번호를 사용하여 내부의 다른 사용자에게 전화를 걸거나 외부로 전화를 겁니다.
여러 위치에서 PBX를 사용하는 조직에서는 특정 PBX 공급업체의 네트워킹 기술을 통해 시스템을 서로 연결하는 경우도 있습니다. 이를 통해 네트워크로 연결된 PBX의 모든 사용자는 내선 번호만 눌러 서로 전화를 걸 수 있습니다.
통합 메시징에는 Exchange 메시징과 실제 전화 통신 시스템이라는 서로 다른 두 시스템을 통합하는 작업이 포함됩니다. 통합 메시징 서버와 전화 통신 아키텍처 간의 통신은 SIP(Session Initiation Protocol)를 사용하여 수행됩니다. PBX 기술에 따라서는 SIP를 통해 통합 메시징 서버와 직접 통신할 수 있지만 SIP 게이트웨이가 필요한 경우도 있습니다. 그림 1에서는 PBX가 T1 회선을 통해 SIP 게이트웨이에 연결되어 있습니다. 통합 메시징으로 호출이 전달되면 PBX가 발신자 전화 번호, 수신자 전화 번호, 이유 코드 등의 정보를 SIP 게이트웨이로 보내서 누구에게 걸려 온 호출인지를 통합 메시징 서버에서 알 수 있도록 합니다.
일부 PBX는 IP 네트워크를 통해 네트워크로 연결할 수 있습니다. 전화 통신 네트워킹에서는 IP 네트워크를 통해 중앙 집중화된 음성 메일 솔루션으로 호출을 리디렉션할 수 있는 기능을 제공합니다. 예를 들어 그림 2에서 취리히는 네트워크를 통해 다시 런던으로 연결됩니다.
그림 2** 더 복잡한 통합 메시징 배포 **(더 크게 보려면 이미지를 클릭하십시오.)
호출 흐름
통합 메시징 리소스
외부 호출자로부터 통합 메시징 구독자 전화로 호출이 왔다고 가정해 보겠습니다. 이 경우 통합 메시징 구독자가 사무실에 없으므로 호출을 받을 수 없습니다. 그림 1을 보면 이 메시지의 경로를 추적할 수 있습니다.
PBX는 호출을 SIP 게이트웨이로 보냅니다. 그러면 SIP 게이트웨이가 SIP over TCP를 통해 통합 메시징 서버와 호출을 협상합니다. 통합 메시징 서버는 수신자가 누구인지 알려 주는 통합 데이터를 SIP 게이트웨이로부터 받습니다. 그러면 통합 메시징 서버가 구독자의 인사말을 재생하고 외부 호출자가 메시지를 녹음할 수 있도록 합니다. 그런 다음 녹음된 메시지는 통합 메시징 구독자의 Exchange 사서함으로 배달됩니다.
이 호출 흐름은 실제 흐름을 다소 간단하게 설명한 것입니다. 메시지가 녹음될 때 통합 메시징 서버는 SMTP를 통해 메시지를 허브 전송 서버로 전달하여 메시지가 사서함 서버로 배달될 수 있도록 한다는 것을 이해하는 것이 중요합니다.
이제 통합 메시징 구독자가 전화(Outlook® Voice Access를 사용하는 경우)나 컴퓨터(Outlook 2007 또는 Outlook Web Access를 사용하는 경우)를 통해 자신의 Exchange 사서함에 액세스합니다. Outlook 2007이나 Outlook Web Access를 사용하는 경우에도 '전화에서 재생'이라는 기능을 통해 전화로 메시지에 액세스할 수 있습니다. 이 기능을 사용하면 컴퓨터를 통해 메시지에 액세스하는 대신 지정된 전화에서 벨이 울리도록 설정하여 선택한 메시지를 통합 메시징에서 재생하도록 할 수 있습니다. 이 방법을 사용하는 경우 통합 메시징 서버가 클라이언트 액세스 서버 및 사서함 서버 모두와 상호 작용합니다. 로컬 클라이언트 액세스 서버가 없는 원격 사무실에 통합 메시징 서버를 배치하는 경우 통합 메시징 서버가 클라이언트 액세스 서버에 연결하기 위해 WAN을 경유해야 하는데, 이로 인해 성능이 저하될 수 있다는 점을 반드시 기억하고 있어야 합니다.
시스템 설계
Exchange 아키텍처 설계는 크게 중앙 집중화된 설계와 분산된 설계의 두 가지 방식으로 나뉩니다. 일반적으로 통합 메시징 아키텍처는 Exchange 아키텍처를 따릅니다. 즉, 사서함 서버를 배포한 곳에는 통합 메시징 서버도 배포합니다. 물론, 어느 규칙이라도 예외는 있습니다.
통합 메시징 아키텍처를 설계할 때는 다음과 같은 다섯 가지 기본 사항을 고려해야 합니다.
- 서버 배치
- 통합 메시징 서버의 수
- SIP 게이트웨이
- 사서함 저장소
- 통합 메시징 사이트 구성
비즈니스 연속성도 간과해서는 안 됩니다. 일반적으로 Exchange와 관련된 재해 복구 계획을 사용하여 통합 메시징 관련 요소를 확인할 수 있습니다.
샘플 배포 시나리오는 통합 메시징 서버 역할을 이해하는 데 도움이 됩니다. 그림 2에서는 규모가 큰 조직에 배포된 Exchange Server 2007 및 통합 메시징을 보여 줍니다.
다소 복잡한 이 설계에서 주 데이터 센터는 시애틀과 런던입니다. 이 두 위치에서는 사서함 서버와 허브 전송 서버가 로컬에 있으므로 통합 메시징 서버가 해당 사용자 커뮤니티를 담당합니다. 두 위치 모두에는 로컬 통합 메시징 서버로 들어오는 모든 호출에 대한 응답을 담당하는 IP PBX가 있습니다.
중간 규모 사이트는 뉴욕과 글래스고에 있습니다. 이 두 위치에서는 사서함 서버와 허브 전송 서버가 로컬에 있으므로 통합 메시징 서버가 해당 사용자 커뮤니티를 담당합니다. 주 데이터 센터와 마찬가지로 두 사이트 모두에는 로컬 통합 메시징 서버로 들어오는 모든 호출에 대한 응답을 담당하는 IP PBX가 있습니다.
소규모 사이트에는 로컬 사서함 서버나 허브 전송 서버가 없지만 주 데이터 센터를 통해 통합 메시징 기능이 제공됩니다. 오스틴에는 로컬 SIP 게이트웨이에 대해 아날로그 연결을 사용하는 NEC PBX가 있습니다. 로컬 최종 사용자에게 걸려 온 호출은 SIP 게이트웨이로 전달됩니다. 그러면 SIP 게이트웨이가 시애틀의 통합 메시징 서버와 협상하여 통합 메시징을 통해 호출에 대한 응답을 제공합니다.
취리히에는 IP 네트워크를 통해 런던의 Avaya Communication Manager에 네트워크로 연결된 Avaya Communication Manager가 있습니다. 로컬 사용자에게 걸려 온 호출은 Avaya Communication Manager 네트워크를 통해 전달됩니다. 그러면 Avaya Communication Manager가 런던의 통합 메시징 서버와 협상하여 통합 메시징을 통해 호출에 대한 응답을 제공합니다.
이 예에서 시애틀 사이트에는 Exchange 사서함 서버와 통합 메시징 서버가 물리적으로 동일한 위치에 있습니다. 단일 사이트 아키텍처에서는 사서함, 통합 메시징, 클라이언트 액세스 등의 모든 서버와 PBX 장비가 동일한 사이트 내에 배치됩니다. 여러 사이트가 있는 회사의 경우에는 설계가 복잡해집니다. 이러한 복잡함으로 인해 어려움을 느낄 수도 있지만 통합 메시징의 몇 가지 기본 원칙을 제대로 이해한다면 쉽게 관리할 수 있습니다.
그림 2에서 볼 수 있듯이 한 사이트에 사서함 서버가 있으면 통합 메시징 서버도 동일한 사이트에 배치하는 것이 좋습니다. 시애틀, 런던, 뉴욕, 글래스고에는 모두 이 설계가 적용됩니다. 오스틴과 취리히에는 로컬 사서함 서버가 없지만 IP 네트워크를 통해 이 곳에도 통합 메시징 서비스를 제공할 수 있습니다. 오스틴에는 로컬 아날로그 PBX가 있습니다. 이 경우 시애틀의 통합 메시징 서버에 대한 IP 네트워크 연결을 제공하는 데 SIP 게이트웨이를 사용해야 합니다. 취리히에는 로컬 IP PBX가 있고 이 IP PBX는 네트워크를 통해 다시 런던의 PBX에 연결됩니다. 따라서 취리히의 사용자에게 온 호출은 전화 통신 네트워크를 경유하여 다시 런던의 PBX와 통합 메시징 서버로 전송됩니다.
취리히의 구독자에게 온 호출은 네트워크를 경유하고 런던의 중앙 집중화된 통합 메시징 시스템에서 처리되므로 네트워크 연결이 끊기면 연결이 복구될 때까지 취리히의 모든 구독자에게 온 호출은 응답되지 않습니다. 네트워크 연결이 끊긴 경우에도 로컬에서 서비스가 지속적으로 제공되어야 하는 경우에는 취리히에 통합 메시징 서버를 배치할 수 있습니다. 그러면 네트워크 연결이 끊기더라도 통합 메시징 서버가 계속해서 호출에 응답하고 네트워크가 복구되면 이를 전달할 수 있습니다.
서버 배치는 사용자 환경에 맞게 아키텍처를 설계할 때 고려해야 할 가장 중요한 요소입니다. 그림 3의 순서도를 보면 적절한 서버 배치를 결정하는 데 도움이 됩니다.
그림 3** 서버 배치 결정 **(더 크게 보려면 이미지를 클릭하십시오.)
필요한 서버 수 예측
그 다음으로 고려해야 할 사항은 사용자 커뮤니티를 지원하는 데 필요한 통합 메시징 서버의 수입니다. 필요한 서버의 수는 실제로 몇 가지 사이트별 요소에 따라 다릅니다.
통합 메시징의 확장성은 서버에서 지원되는 동시 호출의 수(전화 통신의 경우 호출되는 포트 수)를 기준으로 결정됩니다. 시스템으로 들어오는 각 호출에 응답하려면 통합 메시징 서버에 전용 네트워크, CPU, 메모리 및 디스크 리소스를 할당해야 합니다. 리소스를 추가하면 통합 메시징 서버가 더 많은 동시 호출을 지원할 수 있습니다. 이러한 리소스는 늘 그렇듯 제한되기 마련이므로 통합 메시징 서버는 리소스에 과부하가 발생하지 않는 범위 내에서 가능한 수의 동시 호출만 처리할 수 있습니다.
Erlang의 트래픽 분석 계산법을 사용하면 구독자 수를 지원하는 데 필요한 포트 수를 결정할 수 있습니다. 이 계산법에 대해서는 여기에서 자세히 설명하지 않습니다. 전화 통신 관리자에게 기존 음성 메일 시스템에서 사용하는 음성 메일 포트 수를 문의하면 필요한 포트 수를 보다 쉽게 확인할 수 있습니다. 현장 경험에 비추어 볼 때 일반 음성 메일 시스템과 통합 메시징 시스템의 포트 요구 사항은 거의 비슷합니다.
일반적으로 서버당 구현하는 포트 수가 60개를 넘지 않도록 하는 것이 좋습니다. 이 수는 소프트웨어나 하드웨어의 제한 사항과는 아무 관계가 없으며 포트가 60개인 단일 서버에서 대략 5,000명의 사용자를 지원할 수 있다는 사실에 근거를 두고 산출한 것입니다. 단일 서버가 중단되면 규모가 매우 큰 전체 구독자 기반 중에서 해당 서버만 중단될 뿐입니다.
통합 메시징 서버를 구현할 때 N+1 중복 설계를 아키텍처에 포함할 수도 있습니다. 그림 4에서는 완전히 중복되는 서버 및 SIP 게이트웨이 설계를 보여 줍니다. 이 설계에 따르면 통합 메시징 서버 1이 중단되는 경우 SIP 게이트웨이 1이 자동으로 통합 메시징 서버 2와 호출을 협상합니다. SIP 게이트웨이 간에 호출 부하가 고르게 분산되도록 PBX를 프로그래밍할 수도 있습니다. 예를 들어 시스템으로 들어오는 첫 번째 호출은 SIP 게이트웨이 1로 라우팅하고 두 번째 호출은 SIP 게이트웨이 2로 라우팅할 수 있습니다. 각 게이트웨이가 교대로 호출을 수신하도록 함으로써 통합 메시징 서버 간에 호출을 고르게 분산하고 부하를 공유할 수 있습니다.
그림 4** 중복성 제공을 위한 서버 간의 호출 분산 **(더 크게 보려면 이미지를 클릭하십시오.)
현재 Exchange Server 2007 통합 메시징 솔루션에서는 AudioCodes와 Dialogic의 두 가지 SIP 게이트웨이 공급자가 지원됩니다. 설계에 SIP 게이트웨이를 포함해야 하는 경우 설계에 필요한 세션(포트) 수를 지원하는 SIP 게이트웨이를 구입해야 합니다. 예를 들어 32개의 포트가 필요하면 적어도 32개 이상의 세션을 지원하는 게이트웨이를 사용해야 합니다.
사용 중인 PBX가 통합 메시징과 함께 작동하는지 여부나 어떤 게이트웨이를 사용해야 할지 잘 모르는 경우 "통합 메시징 리소스" 추가 기사를 참조하십시오. 추가 기사에 나열된 링크를 통해 Microsoft에서 제공하는 구체적인 지침 및 조직의 특정 요구 사항을 평가할 수 있도록 도움을 주는 통합 메시징 전문 업체 카탈로그를 볼 수 있습니다. 필자의 경험에 비추어 보면 SIP 게이트웨이 및 Exchange 통합 메시징과 함께 사용할 수 없는 PBX는 그다지 많지 않으며 일부 PBX의 경우 기본적으로 SIP over TCP를 사용하여 통합 메시징 서버와 통신할 수 있습니다.
Exchange 통합 메시징은 음성 메일 메시지 저장을 위해 G.711 PCM Linear, GSM 06.10 및 WMA(Windows Media® 오디오)의 세 가지 오디오 코덱을 지원합니다. PCM Linear WAV 파일은 오디오에 초당 약 16KB를 사용합니다. WMA는 통합 메시징의 기본 오디오 코덱으로, 초당 1.1kb(킬로비트)로 오디오를 압축하며 헤더 크기가 7KB입니다. GSM 06.10은 초당 1.6kb로 오디오를 압축하지만 WMA 인코딩보다 헤더가 작습니다.
WMA와 GSM 06.10 인코딩의 경우 음성 메시지의 음성 품질이 양호합니다. WMA나 GSM 코덱을 사용해 본 현장 경험에 비추어 보면 조직에서 음성 메일을 얼마나 많이 사용하는지 여부에 따라 사서함 저장소 크기가 10%-20% 정도 늘어날 수 있습니다.
사용자 환경에서 사용할 오디오 코덱을 결정할 때는 최종 사용자가 사용하는 모바일 장치 및 기타 운영 체제를 염두에 두어야 합니다. 오디오 코덱에 대한 질문은 대개 사용자가 자신의 Windows Mobile® 장치에서 음성 메일을 수신할 수 있는지에 관한 것입니다. 다른 운영 체제를 사용하는 경우도 고려의 대상입니다. 조직에서 WMA 파일을 재생할 수 없는 Linux 시스템을 대규모로 배포했을 수 있습니다. 어떤 경우에 해당하든 이러한 요소가 있으면 사용자 교육 시 고려해야 할 지원 센터 리소스 요구 사항이 늘어납니다.
구성 및 테스트
통합 메시징 아키텍처가 중앙 집중화되어 있는지 또는 분산되어 있는지 여부에 관계없이 조직에 통합 메시징을 배포하기 전에 먼저 수많은 음성 메일 요구 사항을 검토해야 합니다. "통합 메시징 검사 목록" 추가 기사에는 프로젝트 팀에서 논의해야 할 자세한 항목이 나열되어 있습니다. 통합 메시징을 구현하려는 각 사이트에서 모든 항목에 대한 정보를 수집해야 합니다. IT 팀과 전화 통신 팀은 이러한 항목을 고려할 때 상호 협력해야 합니다.
시스템을 설계하고 구성 작업을 마친 후에는 테스트 시스템을 가동하여 설계가 적절한지 검사해야 합니다. 여러 사이트를 대상으로 한 설계의 경우 적어도 둘 이상의 서로 다른 사이트를 테스트하여 POC(개념 증명)를 보여 주고 설계가 올바르게 작동하는지 검사하는 것이 좋습니다.
구성 요구 사항을 바탕으로 기능 테스트 계획을 수립한 다음 이를 수행해야 합니다. 기능 테스트 계획에는 구독자 액세스 방법(전화, Outlook 2007 및 Outlook Web Access), 관리 방법, 하드웨어 및 네트워크 중단이 포함되어야 합니다.
테스트가 완료된 후 모든 사용자들이 통합 메시징에 기존 음성 메일 시스템의 기능이 완벽하게 복제되었다는 데 동의하거나 복제할 수 없는 구성 또는 기능을 지원하기 위해 대체 솔루션을 설계해야 한다는 것에 동의한 경우에는 시스템을 테스트하기 위한 파일럿 사용자 그룹을 선정해야 합니다. 파일럿 그룹을 활용하면 사용자 환경에서 구독자를 기존 음성 메일 시스템에서 통합 메시징으로 이동(전화 통신 용어로는 전환)하는 데 필요한 단계를 파악할 수 있습니다. 일반적으로 구독자를 전환하는 데 필요한 단계는 다음과 같습니다.
- 기존 음성 메일 시스템에서 구독자를 비활성화합니다.
- Exchange 관리 콘솔을 통해 Active Directory의 구독자가 통합 메시징을 사용하도록 설정합니다.
- 전화 연결 경로를 통합 메시징 파일럿 번호로 변경합니다.
기존 사서함으로 메시지가 전송되지 않도록 기존 음성 메일 시스템에서 구독자를 반드시 비활성화해야 합니다.
파일럿 단계에서는 구독자가 시스템 기능과 관련하여 제기한 질문을 기록해야 합니다. 이러한 세부 사항을 문서화하면 교육 단계에서 일반적인 문제를 해결할 수 있습니다.
성공적인 전환을 위해서는 교육이 반드시 필요합니다. 사용자는 특정한 사용자 인터페이스를 사용하여 전화를 통해 음성 메일에 액세스하는 것에 익숙해져 있습니다. 예를 들어 일부 음성 메일 시스템의 경우 메시지를 청취하려면 5번을 눌러야 합니다. Exchange 통합 메시징에서는 1번을 누르거나 "음성 메일(Voicemail)"이라고 말해야 합니다. 또는 Outlook 2007이나 Outlook Web Access를 사용하여 음성 메시지를 재생해야 합니다. 통합 메시징 구독자 교육에는 전화 통신 사용자 인터페이스 탐색, Outlook Voice Access 탐색, Outlook/Outlook Web Access 탐색 과정을 포함해야 합니다.
Exchange 2007 통합 메시징을 사용하면 Outlook Voice Access에 기본으로 제공되는 음성 명령 실행 기능을 사용할 수 있습니다. 일부 사용자는 시스템의 새로운 기능에 상당한 흥미를 보이는데, 이 경우 기존 사용자 인터페이스에서 새로운 사용자 인터페이스로 전환하기가 훨씬 쉽습니다.
Exchange 통합 메시징에는 통합 메시징을 사용하도록 사용자를 설정하면 해당 사용자에게 사용자 지정 텍스트 전자 메일 메시지를 보내는 기능이 있습니다. 이러한 사용자 지정 메시지를 통해 FAQ(질문과 대답), 구독자 설명서, 지원 센터 전화 번호 등으로 연결되는 유용한 웹 링크를 제공할 수 있습니다. 음성 메일 시스템에 액세스하는 방법이나 구독자의 고유 암호와 같은 정보도 포함할 수 있습니다. 이 기능은 통합 메시징을 사용하도록 최종 사용자를 설정할 때 얻을 수 있는 가장 강력한 기능 중 하나입니다.
사용자 마이그레이션
통합 메시징 검사 목록
다음 단원에서는 통합 메시징 시스템의 몇 가지 기본 요소를 정의하고 Exchange Server 2007 통합 메시징의 배포 및 구성을 준비할 때 확인해야 할 몇 가지 질문을 보여 줍니다. 이러한 질문을 배포 계획을 수립하기 위한 검사 목록으로 사용할 수 있습니다.
다이얼 플랜 통합 메시징 다이얼 플랜은 논리적으로 PBX 및 관련 내선 번호에 해당합니다. 다음과 같은 다이얼 플랜의 몇 가지 측면을 사전에 검토해야 합니다.
- 내선 번호에는 몇 자리의 숫자를 사용합니까?
- 통합 메시징 시스템의 파일럿 번호는 무엇입니까?
- 사용자가 외부 회선에 전화를 걸려면 어떤 번호를 눌러야 합니까?
- 메시지에는 어떤 오디오 코덱을 사용합니까?
- 회사 교환원의 내선 번호는 무엇입니까?
헌트 그룹 및 파일럿 번호 헌트 그룹은 특정 순서로 호출을 수신하도록 구성된 일련의 내선 번호입니다. 파일럿 번호는 헌트 그룹에 액세스하기 위해 호출되는 기본 내선 번호입니다. 헌트 그룹 구성원 내선 번호의 수는 설계에 포함된 음성 메일 포트 수와 같아야 합니다.
사서함 정책 음성 메일 사서함 정책은 Exchange 사서함 정책과 거의 비슷합니다. 다음은 검토할 만한 몇 가지 정책입니다.
- 음성 메일을 삭제하기 전에 며칠 동안 보관합니까?
- 음성 메일 암호 재설정 간격은 어떻게 됩니까?
- 음성 메일 백업 정책은 무엇입니까?
- 최소 암호 길이 요구 사항은 무엇입니까?
- 사서함을 잠그기 전까지 허용할 최대 로그온 시도 횟수는 얼마입니까?
AA(자동 전화 교환) 자동 전화 교환은 특정 구독자가 지정되지 않은 들어오는 호출에 응답합니다. 자동 전화 교환은 호출자에게 정보를 제공하고 호출자를 조직 내의 특정 위치로 리디렉션할 수 있습니다. Exchange 통합 메시징은 AA 탐색을 위한 DTMF 및 음성 기능을 제공합니다. 고려해야 할 사항은 다음과 같습니다.
- 주간, 야간, 공휴일에 각기 다른 AA 메시지를 사용합니까? 이러한 메시지는 문서화하고 기록해야 합니다.
- AA 메뉴에서 누구에게 전화를 걸 수 있습니까?
- AA를 사용할 때 음성 탐색 기능을 사용할 수 있습니까?
- AA를 사용하는 데 여러 언어가 필요합니까?
일반 또는 야간 사서함 일부 조직에서는 호출자가 일반 배달 메시지를 남길 수 있도록 일반 또는 야간 음성 메일 사서함을 사용합니다. 회사에 이러한 사서함이 있는 경우 Exchange 사서함을 만들고 통합 메시징을 사용하도록 설정해야 합니다.
MWI(메시지 대기 신호) 메시지 대기 신호란 사서함에 읽지 않은 음성 메시지가 있음을 알려 주는 전화기의 불빛을 말합니다. 전화기의 메시지 대기 신호 기능이 배포 요구 사항에 해당하는지 검토해야 합니다.
다중 내선 번호 지원 대부분의 조직에는 여러 개의 전화 번호를 사용하는 직원이 있습니다. 통합 메시징을 사용하도록 이러한 구독자를 설정할 때 해당 내선 번호를 모두 연결해야 합니다. 작업을 시작하기 전에 여러 개의 전화 번호를 사용하는 직원의 목록을 만들면 편리합니다.
IVR(대화식 음성 응답) 지원 기존의 일부 음성 메일 시스템에서는 통합 메시징으로 복제할 수 없는 IVR 응용 프로그램을 지원합니다. 대체하려는 시스템에 이러한 응용 프로그램이 연결되어 있는지 확인합니다. 이러한 응용 프로그램은 기존 시스템에 그대로 두거나 대체 IVR 응용 프로그램으로 바꿔야 할 수 있습니다.
음성 메일 네트워킹 음성 메일 네트워킹은 한 시스템에서 다른 시스템으로 메시지를 전송할 수 있는 기능을 제공합니다. 예를 들어 대규모 기업의 경우 CEO가 조직 전체에 음성 메시지를 보내거나 소방 훈련과 같은 일반 정보를 알려야 할 경우가 있습니다. 음성 메일 네트워크가 구축되어 있으면 직원이 어떤 음성 메일 시스템을 사용하든 CEO가 음성 메시지를 한 번 녹음한 후 이를 회사 내 모든 직원에게 보낼 수 있습니다. 현재 Exchange 통합 메시징에는 기존의 다른 음성 메일 시스템과 네트워크로 연결할 수 있는 기능이 없습니다.
팩스 지원 기존의 일부 음성 메일 플랫폼에서는 수신 팩스를 지원하므로 전화 번호 하나로 음성 메시지와 수신 팩스를 모두 받을 수 있습니다. Exchange Server 2007 통합 메시징에서는 수신 팩스를 지원하므로 기존 기능 대신 사용할 수 있습니다. 이 기능은 단방향이므로 송신 팩스 기능은 지원되지 않습니다. 송신 팩스 기능이 필요한 경우 이를 지원하는 타사 제품을 사용해야 합니다.
시스템을 완전한 프로덕션 환경으로 마이그레이션하는 방법에 대해서는 다양한 견해가 있습니다. 그 중에서 많이 사용되는 두 가지 방법은 점진적 마이그레이션과 일괄 전환(flash-cut)입니다. 어떤 방법을 선택하든 파일럿 그룹으로부터 수집하여 기록한 일반적인 질문을 바탕으로 지원 센터 직원들을 교육해야 합니다. 또한 통합 메시징을 사용하도록 사용자를 설정하는 방법, 사용자가 설정되었는지 확인하는 방법, 암호를 변경하는 방법 등도 교육해야 합니다.
이전의 음성 메일 시스템에서 통합 메시징으로 사용자를 마이그레이션하는 작업은 쉽지만 사전에 알고 있어야 할 한 가지 중요한 사항이 있습니다. 바로 음성 메일 네트워킹입니다. 전자 메일 시스템을 통해 다른 전자 메일 사용자와 시스템에 메시지를 보내고, 전달하고, 회신할 수 있는 것처럼 음성 메일을 통해서도 다른 음성 메일 사용자와 시스템에 메시지를 보내고, 전달하고, 회신할 수 있습니다.
현재 기존 음성 메일 시스템을 사용하고 있는 Alice와 Brian이 있다고 가정해 보십시오. Brian은 통합 메시징으로 마이그레이션되었고 기존 음성 메일 시스템을 사용하고 있는 Alice에게 메시지를 보내려고 합니다. 하지만 두 사용자가 서로 다른 시스템을 사용하고 있으므로 더 이상 서로에게 음성 메일을 보내거나 전달하거나 회신할 수 없습니다. 아쉽게도 음성 메일이 서로 고립된 것입니다.
기존의 음성 메일 시스템에서는 일종의 네트워킹 프로토콜 변환기를 사용하여 서로 다른 시스템을 네트워크로 연결함으로써 이 문제를 해결했습니다. 하지만 현재로서는 서로 다른 시스템을 네트워크를 통해 Exchange Server 2007 통합 메시징에 연결할 수 있도록 지원하는 네트워킹 프로토콜 변환기가 없습니다. 조직에 따라서는 이것이 큰 문제가 아닐 수도 있지만 소규모 그룹에서 사용자를 마이그레이션하는 경우에는 반드시 알고 있어야 할 사항입니다.
필자는 사이트 단위로 모든 사용자를 새 시스템으로 일괄 전환하는 방법을 선호합니다. 일괄 전환(flash-cut)이란 이전 시스템의 사용을 중단하고 새 시스템에서 새로 시작하는 것을 말합니다. 이 작업은 대개 주말에 이루어집니다. 사용자가 금요일에 퇴근한 후 월요일에 출근하면 새 음성 메일 시스템이 기다리고 있습니다. 일부 관리자는 소규모 기업 고객이나 원격 위치에서만 일괄 전환을 사용해야 한다고 말합니다. 그러나 필자는 사용자 수가 7,000명이 넘는 단일 위치에서 일괄 전환을 수행하는 데 참여한 적이 있었는데 당시 지원 센터에 도움을 요청한 직원은 전체의 1%도 되지 않았습니다. 프로젝트의 다른 모든 단계를 철저히 계획하여 올바르게 수행한다면 완전한 프로덕션 시스템으로의 전환이 원활하게 이루어질 것입니다.
하지만 여러 사이트를 완전한 프로덕션 환경으로 전환할 때는 먼저 소규모의 원격 사이트를 한 번에 하나씩 전환한 후에 가장 큰 규모의 사이트를 이동하는 것이 좋습니다. 소규모 사이트에서 얻은 경험을 검토하여 필요한 변경 사항을 프로젝트 계획에 반영합니다.
일반적으로 새로운 시스템을 사용하기 전에 모든 사용자 교육을 완료해야 하고 통합 메시징을 사용하도록 모든 사용자를 설정해야 합니다. 다음은 음성 메일 시스템의 일괄 전환을 준비하는 데 필요한 단계별 방법입니다.
가장 먼저 해야 할 작업은 통합 메시징 시스템이 완벽하게 설치, 구성 및 테스트되었는지 확인하는 것입니다.
그런 다음 소규모 그룹 단위로 교육을 실시합니다. 교육에 참석하는 사용자에게 각자의 사서함이 새 음성 메일 시스템에서 가동되기 전에 활성화될 것이라는 점을 설명합니다. 그런 다음 사서함에 로그인한 후 암호를 변경하고 인사말을 녹음하여 각자의 사서함을 초기화하도록 사용자들에게 알려 줍니다. 교육이 끝나면 즉시 통합 메시징을 사용하도록 사용자들을 설정하여 전환을 시작하기 전에 사용자들이 각자의 사서함을 초기화할 수 있도록 합니다.
마지막으로, 모든 교육이 끝나면 기존의 음성 메일 시스템에서 모든 사용자를 비활성화하고 사용자의 전화를 Exchange 통합 메시징으로 전달하는 작업을 수행하기에 적합한 주말을 선택합니다. 월요일 아침이 되면 조직의 모든 사용자를 위한 새 통합 메시징 시스템이 가동될 것입니다.
전환 시작
지원해야 할 대상이 단일 사이트인지 여러 사이트가 있는 대규모 조직인지 여부에 관계없이 이 문서에서 제공하는 정보는 분명히 도움이 될 것입니다. 여러 사이트가 있는 조직의 경우 설계가 복잡해질 수 있지만 사용자가 50명이든 5,000명이든 기본 요구 사항은 같습니다.
통합 메시징 솔루션을 배포할 때 IT 팀과 전화 통신 팀이 상호 협력해야 한다는 사실은 아무리 강조해도 지나치지 않습니다. 필자의 경험으로 미루어 보면 통합 메시징 프로젝트를 본 궤도에서 이탈하게 만들 수 있는 여러 가지 요인 중에서도 특히 IT 팀과 전화 통신 팀 간의 불협화음 및 솔루션에 대한 의견 불일치는 곧바로 실패로 이어집니다. 기술의 수렴은 그다지 어려운 것이 아닙니다. 하지만 팀의 협력을 도모하거나 성공적인 프로젝트 배포 계획을 수립하려면 IT와 전화 통신 모두에 대해 잘 알고 있는 조직 외부의 누군가로부터 도움이 필요할 수도 있습니다.
Jeff GoodwinVIA Group의 수석 기술자이자 Exchange 및 통합 메시징 설계 및 배포 분야의 전문가입니다. 문의 사항이 있으면 jgoodwin@theviagroup.com으로 연락하십시오.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..