Exchange 2007 SP1 가상화 여부 결정

 

마지막으로 수정된 항목: 2009-03-02

Hyper-V 기술이 적용된 Windows Server 2008과 Microsoft Hyper-V Server 2008이 출시되면서, 가상화된 Microsoft Exchange Server 2007 SP1(서비스 팩 1) 서버가 더 이상 실험실 영역에만 제한되어 사용되지 않습니다. 실제로 이 서버는 프로덕션 환경에 배포될 수 있으며 Microsoft의 모든 지원을 받을 수 있습니다. Microsoft에서는 2008년 8월에 Exchange 가상화를 위한 지원 정책 및 권장 사항을 게시했습니다. 이 문서에는 가장 근본적인 질문인 "Exchange를 가상화하는 것이 적절한가?"라는 질문에 대한 대답이 명시되어 있습니다.

Exchange Server의 성능 및 비즈니스 요구 사항으로 인해, Exchange Server를 배포할 때는 대부분 실제 서버에 배포한 Exchange 서버 역할을 사용합니다. 그러나 하드웨어 가상화 환경에서 Exchange를 실행하여 공간, 전력 및 배포 유연성 면에서 실질적인 이점을 얻을 수 있는 시나리오가 있습니다. 이 문서에는 다음과 같은 내용이 포함되어 있습니다.

  • 시나리오   이 섹션에서는 Exchange 2007 SP1을 가상화하는 것이 적합할 수 있는 네 가지 시나리오에 대해 설명합니다.

  • 기술 검사 목록   이 섹션에는 인프라에 대한 현재 부하를 고려할 때 Exchange 2007 SP1을 가상화하는 것이 적절한지 평가하는 데 도움이 되는 검사 목록이 제공됩니다.

시나리오

이 섹션에서는 다음의 네 가지 시나리오에 대해 설명합니다.

  • 고가용성을 유지하는 소규모 회사

  • 고가용성을 유지하는 원격 사무실 또는 지점

  • 재해 복구

  • 모바일 LAN

고가용성을 유지하는 소규모 회사

규모는 작지만 엔터프라이즈급 가용성을 유지해야 하는 조직이 있습니다. 예를 들어 전자 메일 서비스를 핵심 서비스로 제공하는 Contoso, Ltd.라는 가상의 회사가 있다고 가정해 보겠습니다. Contoso에는 250명의 사용자로 구성된 여러 소규모 지점 사이트가 있습니다. Contoso는 법적인 이유로 전자 메일 환경을 사내에 유지하고자 하며, 완벽하게 중복되는 전자 메일 시스템을 갖추고자 합니다. Contoso 사용자는 사서함이 2GB인 평균 사용자 메시징 프로필을 가집니다.

실제 하드웨어를 사용하여 모든 Exchange 서버 역할이 완벽하게 중복되도록 하려면 Contoso는 서버를 7개 배포해야 합니다. 즉, Active Directory 및 DNS용 서버 두 개, 파일 및 인쇄 서비스용 서버 한 개, 클라이언트 액세스 및 허브 전송 서버 역할을 모두 실행하는 서버 두 개, 그리고 CCR(클러스터 연속 복제) 환경에서 사서함 서버 역할을 실행하는 서버 두 개입니다. 이러한 서버에는 쿼드 코어 프로세서가 두 개 있다고 가정하며, RAM 크기는 설치된 각 역할에 대한 Microsoft 권장 사항을 기준으로 합니다. 각 CCR 노드의 RAM은 4GB이고 각 기타 서버의 RAM은 최소 2GB(사용자 및 트래픽 패턴 지원용)입니다. 평균 사용자 메시징 프로필을 사용하는 경우 코어가 8개 있는 서버의 일반적인 부하는 CPU의 35%-45%입니다.

가상화를 사용하는 경우 Contoso는 서버 3개만으로 동일한 수준의 중복성과 가용성을 유지할 수 있습니다. 각 실제 서버에서는 가상화된 여러 서버를 게스트 컴퓨터로 실행하게 됩니다. 이 시나리오에서는 쿼드 코어 프로세서가 두 개이고 RAM이 16GB인 실제 서버 3개만 사용해도 Contoso 사용자에게 서비스를 제공하는 데 충분합니다. 각 가상 서버는 가상 CPU 두 개를 사용하여 구성됩니다. 서버에는 RAM 및 프로세서 외에도 여러 개의 네트워크 어댑터와 중복 저장소 경로가 있어야 합니다. Contoso에서 관리해야 하는 Exchange 서버 수는 여전히 같기 때문에, 운영 및 유지 관리 측면에서는 이점이 없지만 공간, 전력 및 냉각 측면에서는 이점이 있습니다.

다음 다이어그램에서는 이 시나리오를 보여줍니다.

가능한 소규모 지점 설계

참고

CCR 환경의 FSW(파일 공유 감시)를 호스팅하는 허브 전송 서버는 클러스터의 각 노드와 동일한 하이퍼바이저 루트 컴퓨터의 게스트가 아닙니다. 이는 클러스터링 솔루션의 단일 실패 지점을 제거하고 올바른 클러스터링 기능을 제공하기 위한 의도적 설정입니다.

이 시나리오의 경우 실제 서버 7개에서 실제 서버 3개와 가상 서버 7개로 전환하면 연간 전력은 25,754kWh, 비용은 $22,516를 절약할 수 있습니다. 이 수치 계산에는 Microsoft Virtualization 도구(영문)가 사용되었습니다.

Microsoft HyperGreen 보고서 7-to-3

하드웨어 가상화 환경용으로 Exchange 크기를 지정하는 작업은 실제 서버용으로 Exchange 크기를 지정하는 작업과 다르지 않습니다. 실제 서버를 사용하든 가상화된 서버를 사용하든 관계없이, 각 CCR 노드에는 데이터베이스에 대한 48개의 IOPS, 트랜잭션 로그에 대한 19개의 IOPS를 지원할 수 있는 저장소와 4GB RAM이 필요합니다. 이 시나리오의 경우 IOPS 요구 사항이 매우 낮으므로 가상화된 환경에서의 유지 관리가 가능합니다. 그리고 가상화된 Exchange 서버에서 호스팅되는 사용자 수가 적으므로 이 솔루션에는 고정 가상 하드 드라이브를 사용해도 충분합니다. 사용자 수가 많은 경우에는 외부 저장소를 사용하는 것이 좋습니다.

맨 위로 이동

고가용성을 유지하는 원격 사무실 또는 지점

이전에는 원격 사무실이나 지점에서 해당 사용자에게 충분한 성능을 제공하기 위해 로컬 Exchange 서버를 사용해야 하는 조직도 있었습니다. 그리고 캐시된 Exchange 모드, 외부에서 Outlook 사용 등의 향상된 기능을 통해 이러한 서버를 중앙 데이터 센터에 통합하는 것이 좋았습니다.

그러나 원격 사무실과의 네트워크 연결 상태가 좋지 않아 이들 조직이 원격 사무실이나 지점에서 로컬 Exchange 서버를 계속 사용해야 하는 경우도 있습니다. 이러한 위치의 경우 대개 사용자 수가 매우 적어 실제 서버를 Exchange 환경 전용으로 사용하는 것은 적절하지 않습니다. 이 시나리오에서 고려한 기술적 사항은 위 "고가용성을 유지하는 소규모 회사" 시나리오에서 설명한 것과 같습니다. Hyper-V 환경에서 Exchange 2007 SP1을 사용하는 회사에 대한 이 시나리오의 예제를 보려면 Caspian Pipeline Consortium(영문)에 대한 이 Windows Server 2008 고객 솔루션 사례 연구를 다운로드하십시오.

재해 복구

프로덕션 사이트에 사이트 복구 및 중복성을 제공하기 위해, 일부 조직에서는 Exchange 2007 주 프로덕션 인프라의 복제본이 포함된 웜 사이트를 필요로 하는 경우가 있습니다. 이 웜 사이트는 주 사이트가 손실되는 경우 주 사이트의 기능 수준에 최대한 근접한 수준의 기능을 제공하기 위한 것입니다. 그러나 중복 인프라를 대기용으로 유지하는 것은 SLA(서비스 수준 계약) 요구 사항이 높은 경우에는 유리할 수 있지만 일부 조직에게는 엄청나게 비용이 많이 들 수 있습니다.

이러한 비용을 줄이기 위해 Hyper-V 환경에서 게스트 컴퓨터를 사용하여 전체 주 사이트의 복제본을 제공할 수 있습니다. 실제 Exchange 2007 서버를 사용하는 일반적인 웜 사이트 구성에는 대기 클러스터로 함께 구성된 하나 이상의 서버와, 클라이언트 액세스 및 허브 전송 서버 역할로 구성된 하나 이상의 다른 서버가 포함됩니다. 이 경우 웜 사이트 내에서 메시징 서비스만 중복되도록 하는데 실제 서버가 4개 필요합니다. 반면 실제 서버가 3개만 설치된 가상화된 솔루션에서는 CCR 환경의 사서함 서버 두 개와 중복 클라이언트 및 허브 전송 서버를 모두 포함하는 웜 사이트를 조직에 제공할 수 있습니다. 따라서 이 시나리오에서 Exchange를 가상화하면 보다 수준 높은 서비스를 사용자에게 제공하는 동시에 실제 서버에 배포된 유사 구성 솔루션과 비교할 때 공간 요구 사항을 낮추고 하드웨어, 전력 및 냉각 비용을 절감할 수 있습니다.

다음 다이어그램에서는 이 구성을 보여줍니다.

가능한 웜 사이트 재해 복구 구성

주 사이트에서는 사용자 수에 대한 규모와 메시징 프로필이 크기 때문에 실제 하드웨어를 사용합니다. 이 시나리오에서 웜 사이트는 주 사이트의 전체 사용자 수를 지원하도록 설계되었습니다. 웜 사이트는 감소된 성능으로 일시적으로 사용되지만, 이와 같이 많은 수의 사용자를 지원할 환경을 구성할 때에는 주의 깊게 고려해야 합니다.

다이어그램에서는 대기 클러스터를 포함하는 웜 사이트를 보여줍니다. 해당 노드 중 하나는 프로덕션 CCR 환경용 SCR(대기 연속 복제) 대상으로 구성되어 있습니다. 또한 도메인 컨트롤러 한 쌍도 배포됩니다. SCR 대상은 2노드 대기 클러스터입니다. 사이트에 오류가 발생하면 Restore-StorageGroupCopy를 사용하여 대기 클러스터가 활성화된 다음 Setup /recoverCMS 스위치를 사용하여 CMS(클러스터된 사서함 서버)가 복구됩니다. 대기 클러스터는 하드웨어 가상화 환경에서 게스트 컴퓨터이지만, 대기 클러스터를 사용하여 재해에서 복구하는 것과 같은 절차가 적용됩니다. 대기 클러스터가 온라인 상태가 되고 오류가 발생한 사이트의 CMS를 호스팅하게 되면, DNS 및 Active Directory 복제가 수행된 후에 메시징 서비스 및 데이터에 대한 클라이언트 액세스가 복원됩니다.

가상 웜 사이트는 주 사이트가 손실되는 경우 사용자에게 적절한 수준의 서비스를 제공할 수 있어야 합니다. 이 경우 웜 사이트에 대한 WAN/인터넷 링크로 인해 서비스 수준이 낮아질 수 있습니다. 그러나 사이트는 응급 기능을 제공하도록 설계되므로 잠깐 동안은 서비스 수준이 낮아져도 괜찮습니다. 하지만 주 사이트가 다운된 동안에는 웜 사이트에 대한 사이트 복구가 이루어지지 않습니다.

이 시나리오의 경우 실제 서버 8개에서 실제 서버 3개와 가상 서버 8개로 전환하면 연간 전력은 33,005kWh, 비용은 $28,225를 절약할 수 있습니다. 이 수치 계산에는 Microsoft Virtualization 도구(영문)가 사용되었습니다.

Microsoft HyperGreen 보고서 8-to-3

맨 위로 이동

모바일 LAN

회사, 기관 또는 정부 부서에서 특정 위치로 즉시 배포할 수 있는 완전한 네트워크 인프라를 필요로 하는 경우가 있습니다. 이와 같이 배포된 인프라는 위성 또는 기타 원격 WAN 기술을 통해 조직 네트워크에 연결됩니다. 예를 들어 NGO(비정부 기구)는 재해가 발생하는 경우에 대비하고 재해에 영향을 받는 커뮤니티에 서비스를 제공하는 로컬 서버를 설치해야 할 수 있습니다. 이러한 서버 하위 집합은 완전히 자체 포함되어 있어야 하고, 대상 위치의 직원에게 필요한 모든 서비스를 제공할 수 있어야 합니다.

이러한 상황에서는 모바일 LAN을 쉽게 전송할 수 있어야 합니다. 모바일 LAN에서는 폼 요소가 작은 동시에 효율성이 높아야 로컬 사용자에게 필요한 모든 서비스를 제공하면서 최대한 적은 공간을 사용할 수 있습니다. 그리고 모바일 LAN이 멀리 떨어진 위치에 배포될 수 있기 때문에, 여분의 부품을 구하기가 어려운 위치에서 단일 실패 지점이 발생하지 않도록 내결함성 기능도 제공해야 합니다.

이 시나리오에서는 Hyper-V 서버를 사용하여 Exchange 서비스, 파일 서버 서비스 및 도메인 인프라 서비스를 간단한 폼 요소에서 호스팅할 수 있습니다.

참고

Exchange 2007 SP1을 가상화하려면 IO를 많이 사용하는 응용 프로그램을 루트 서버에 설치해서는 안 됩니다.

다음 다이어그램에서는 도메인 인프라 시스템과 Exchange 2007을 호스팅하는 Hyper-V 서버에 적용 가능한 구성을 보여줍니다. 이 시나리오의 특성상 동일한 게스트 컴퓨터에는 Exchange 서버 역할을 결합하지 않았습니다.

가능한 모바일 LAN 구성

다이어그램에서는 필요한 모든 서버 서비스를 위치에 관계없이 로컬로 제공해야 하는 조직을 위한 포괄적 네트워크 솔루션을 보여줍니다. 이 솔루션은 크기를 가능한 작게 유지하면서 높은 수준의 내결함성과 시스템 가용성도 제공할 수 있습니다.

랙에는 하이퍼바이저 루트 서버와 워크스테이션을 지원하는 데 충분한 네트워크 인프라 장비도 필요합니다. 하이퍼바이저 루트 시스템에는 iSCSI 또는 파이버 채널 SAN이 사용됩니다. SAN은 게스트 시스템에 필요한 성능을 제공할 수 있도록 충분한 스핀들을 주어야 합니다. 이 시나리오에서는 단일 42U 랙에 필요한 모든 항목을 포함할 수 있습니다.

이 시나리오의 경우 실제 서버 14개에서 실제 서버 3개와 가상 서버 14개로 전환하면 연간 전력은 91,012kWh, 비용은 $73,891를 절약할 수 있습니다. 이 수치 계산에는 Microsoft Virtualization 도구(영문)가 사용되었습니다.

Microsoft HyperGreen 보고서 14-to-3

맨 위로 이동

기술 검사 목록

앞서 설명한 각 시나리오에서 Exchange를 실제 하드웨어에 배포하면 리소스 사용률이 떨어지게 됩니다. 다음 검사 목록은 Exchange 환경을 통합하는 것이 적절한지 결정하는 데 도움이 될 수 있습니다. 이 검사 목록을 확인한 결과 하드웨어 사용률이 낮다면 다음 작업을 수행할 것을 고려하십시오.

  • 소규모 조직의 경우에는 가상화를 통해 Exchange 역할을 완전히 중복시킴으로써 실제 서버 사용 공간을 실제 서버 3개까지 줄일 수 있습니다.

  • 사용률이 낮은 하드웨어가 중앙 데이터 센터로 통합할 수 없는 지점 또는 원격 사무실에 있는 경우에는 가상화를 사용해 해당 위치에서 실제 서버 사용 공간을 줄일 수 있습니다.

  • 다른 시나리오에서는 서버 용량이 사용자 부하에 부합하는 정도를 다시 파악하여 Exchange 환경의 규모를 좀 더 줄일 수 있습니다. 실제 서버 수를 줄이면 사용률을 원하는 수준까지 높일 수 있습니다. 이 시나리오에서는 가상화를 사용하지 않아도 됩니다.

하드웨어 사용률이 낮으면 Exchange 환경의 용량이 너무 많은 것입니다. 이는 사용량이 급격하게 증가하는 경우 또는 예상되는 확장을 염두에 둔 설계 때문일 수도 있고, 실수로 인한 것일 수도 있습니다. 용량이 어느 정도 많은 것은 적절합니다. 이 점에 대해서는 다음 검사 목록에 설명되어 있습니다.

참고

Exchange에 가상화를 사용할지 결정할 때는 하드웨어 사용률 외에 다른 점도 고려해야 합니다. Exchange 환경에 가상화를 추가하면 백업, 모니터링, 저장소 구성 등 여러 영역이 보다 복잡해집니다. 자세한 내용은 하드웨어 가상화 환경에서 Exchange 서버에 대한 Microsoft 지원 정책 및 권장 사항을 참조하십시오.

검사 목록 1번 – 성능 카운터

다음 검사 목록에서는 모니터링을 통해, Exchange 환경의 사용률이 낮은지 알 수 있는 성능 카운터에 대해 간략히 설명합니다. 이러한 카운터는 가상화된 Exchange 서버가 아닌 실제 Exchange 서버에서 수집해야 합니다. Exchange 인프라 계획은 사서함 서버 역할을 기반으로 하므로, 아래 검사 목록에는 대부분 사서함 서버 메트릭이 사용됩니다.

이러한 각 카운터는 일정한 간격(최소 1주일)으로 수집하는 것이 좋습니다. 데이터를 수집한 후에는 결과를 예상 값과 비교할 수 있습니다. 관측된 값이 아래의 예상 값보다 작으면 서버 하드웨어의 사용률이 낮아지고 있는 것입니다.

검사 목록의 카운터는 System Center Operations Manager를 사용하지 않고 모니터링에 나와 있습니다. 서버는 프로덕션 환경에 배치한 후에 모니터링해야 합니다.

참고

Windows Server 2008에서 프로세서 성능을 모니터링하여 운영 체제로 인해 프로세서 주파수가 떨어지지 않는지를 확인하는 것이 좋습니다. 프로세서 주파수가 떨어지면 실제로는 CPU 사용률이 낮으며 전력을 절약하기 위해 프로세서가 낮게 제한되어 있어도 CPU 사용률이 높은 것으로 생각할 수 있습니다.

성능 카운터 검사 목록

범주 표시기 예상 값 현재 값

일반 성능 카운터(모든 Exchange Server)

Processor% Total

평균적으로 40%보다 작아야 합니다.

[ ]

System\Processor Queue Length(모든 인스턴스)

프로세서당 5를 넘지 않아야 합니다.

[ ]

Network Interface(*)\Bytes Total/sec

1000Mbps 네트워크 어댑터의 경우 30-35Mbps 미만이어야 합니다.

[ ]

사서함 서버 관련 성능 카운터

MSExchangeIS Client (*)\RPC Average Latency

평균적으로 30밀리초보다 작아야 합니다.

[ ]

Process(Microsoft.Exchange.Search.ExSearch)\% Processor time

일반적으로 전체 CPU의 1%보다 작아야 하며 3% 이상으로 유지될 수 없습니다.

[ ]

MSExchange Store Interface(_Total)\RPC Latency average (msec)

항상 100밀리초보다 작아야 합니다.

[ ]

MSExchange Store Interface(_Total)\RPC Requests outstanding

항상 0이어야 합니다.

[ ]

CCR, LCR 및 SCR 사서함 서버 관련 성능 카운터

MSExchange Replication(*)\CopyQueueLength

CCR 및 SCR의 경우 항상 10보다 작아야 합니다.

LCR(로컬 연속 복제)의 경우에는 항상 1보다 작아야 합니다.

[ ]

맨 위로 이동

검사 목록 2번 – 사용자 프로필 요소

서버 사용률이 낮은지를 좀 더 빠른 시간 내에(정확도는 떨어짐) 확인하려면 프로세서 및 메모리 구성 계획에 나와 있는 일반 크기 조정 지침을 사용하여 프로세서 코어를 사용자 프로필과 비교하면 됩니다. 조직의 사용자 프로필을 확인하려면 해당 문서의 사용자 프로필 표를 참조하십시오. 사용자 편의를 위해 아래에도 표가 나와 있습니다.

사용자 유형(사용 프로필) 하루에 약 50KB의 메시지 크기를 보내기/받기

낮음

5개 보냄/20개 받음

평균

10개 보냄/40개 받음

높음

20개 보냄/80개 받음

매우 높음

30개 보냄/120개 받음

프로세서 및 메모리 구성 계획에 나와 있는 것처럼, 크기 조정시 프로필이 평균인 활성 사서함 1,000개당 대략적으로 프로세서 코어가 한 개 필요합니다. 예를 들어 사용 프로필이 평균인 4,000개의 사서함이 있는 서버에는 4개의 프로세서 코어가 필요합니다. 사용 프로필이 높음인 경우에는 평균 프로필보다 많은 프로세서 주기가 필요하므로, 프로필이 높음인 활성 사서함의 경우에는 프로세서 코어당 750개로 계획합니다. 다음 검사 목록에는 프로세서 코어를 완전히 사용하기 위해 필요한 사용자 수를 이 논리를 적용해 요약해 놓았습니다.

사용자 프로필 요소 검사 목록

범주 표시기 예상 값 현재 값

낮음 사용자 프로필

프로세서 코어당 권장 수 = 2000

≤1,000

[ ]

평균 사용자 프로필

프로세서 코어당 권장 수 = 1000

≤500

[ ]

높음 사용자 프로필

프로세서 코어당 권장 수 = 750

≤375

[ ]

매우 높음 사용자 프로필

프로세서 코어당 권장 수 = 500

≤250

[ ]

평균 사용자의 권장 수는 프로세서 코어당 1,000명이므로, 프로필이 평균인 사서함의 활성 사용자 수가 500명 이하이면 하나의 사서함 서버 프로세서 코어를 완전히 활용하기에 사용자가 부족한 것입니다. 실제 Exchange 서버의 경우 사서함 서버 역할에서 효율적으로 사용되는 최대 프로세서 코어 수는 8개입니다. 프로세서 및 메모리 구성 계획을 참조하십시오. 8개보다 많은 코어를 사용하는 서버에 사서함을 배포해도 확장성이 크게 향상되지 않습니다.

이 검사 목록을 사용하여 사서함 서버 프로세서 코어 수를 측정하는 것은 다른 Exchange 서버 역할을 검토하기 위한 좋은 시작점이 됩니다. 허브 전송 및 클라이언트 액세스 서버용 Exchange 인프라 계획 방법이 부분적으로 사서함 서버에 대한 프로세서 코어 비율(사서함:허브 및 사서함:CAS)을 기반으로 하기 때문입니다. 예를 들어 허브 전송 서버에서 전송 바이러스 백신 소프트웨어를 실행하는 경우 사서함:허브 서버 비율은 5:1이고, 그렇지 않은 경우에는 7:1입니다. 따라서 사서함 서버 프로세서 코어 하나를 완전히 사용하기에 사용자 수가 부족한 경우에는 허브 전송 프로세서 코어가 완전히 사용되지 않을 가능성이 큽니다. 즉, 허브 전송 및/또는 클라이언트 액세스 서버에 대해 가상화를 사용해야 할 수 있습니다.

결론

Hyper-V 기술이 적용된 Windows Server 2008이 출시되고, 최근에는 Microsoft Hyper-V Server 2008이 출시되면서 새로운 Exchange Server 2007 SP1 배포 옵션을 사용할 수 있게 되었습니다. 대부분의 경우 Exchange를 실제 하드웨어에서 유지하면 가상화를 사용하는 것에 비해 관리 효율이 향상되고 TCO(총 소유 비용)도 낮아집니다. 그러나 가상화된 Exchange 인프라를 사용하여 공간, 전력 및 배포 유연성 면에서 실질적인 이점을 얻을 수 있는 시나리오도 있습니다.

현재 하드웨어의 사용률이 얼마나 낮은지에 따라, Exchange 아래에 가상 계층을 추가함으로써 환경이 복잡해지더라도 가상화를 통한 이점을 활용하는 것이 더 나은지가 결정됩니다. 일반적으로 기본 서버를 완전히 사용하기에는 Exchange 배포 규모가 너무 작은 환경에서는 가상화를 사용하는 것이 유용합니다. 소규모 Exchange 배포, 연결 상태가 좋지 않은 원격 사이트, 특정 재해 복구 시나리오 및 모바일 LAN 배포의 경우에는 가상화를 사용하는 것이 적합합니다.

대부분의 조직에서 Exchange는 업무상 중요한 응용 프로그램입니다. 가상화된 환경을 설계할 때 이 점을 염두에 두고 가상화된 Exchange 서버에 대한 Microsoft 지원 정책 및 권장 사항을 따르면 환경을 올바르게 설정할 수 있습니다.

자세한 내용