MS는 2005년 중반 64비트 서버 시스템을 제일 먼저 자사의 MSN 메신저 서버에 채택했고, 공식적인 발표로는 과거의 시스템에 비해 약 10배의 성능 증진 효과가 나타났다고 말했다.

MS의 말을 전적으로 믿기는 어렵지만, 64비트 컴퓨터를 도입하면 성능이 어느 정도 향상되는 것은 사실이다.

문제는, 기업 환경에서 64비트 시스템을 도입한다면, 도대체 언제 도입해야 하며, 어떻게 도입하는 것이 전반적인 엔터프라이즈 환경의 시스템을 안정적으로 운영하기 위한 방법인가 하는 점이다. 또한, 어떤 프로그램이 64비트로 옮겨가야 하며, 어떤 프로그램이 기존 시스템에 남아 있어야 하는지에 대한 판단도 매우 중요하다. 그러나 장기적으로는 64비트 시스템은 프로그램의 개발 패턴을 상당히 많이 수정하는 기폭제가 될 것이다.

64비트 이전 서버의 조건
엔터프라이즈 환경에서 64비트로 이전될 서버는 다음의 조건을 만족하는 대상을 우선 고려해야 한다.

잦은 메모리 입출력이 발생하는 서버

메모리 사용량이 상대적으로 많이 발생하는 서버

TCP/IP 소켓을 계속 연결한 형태로 동작하는 네트워크 서버

대용량 데이터베이스로 많은 트랜잭션이 발생되는 DB 서버

물론, 이러한 조건은 소요되는 메모리 용량 혹은 메모리 입출력의 빈도와 항상 직접적인 관계에 속하는 것이다. 또한, 위의 조건과 더불어 64비트로 이전되는 시스템은 반드시 64비트로 코드가 쉽게 재컴파일될 수 있는 상황이라야 한다.

따라서, C나 비주얼 베이직과 같은 언어로 작성된 프로그램의 경우 상대적으로 64비트 전환이 어렵다. C 언어의 경우 64비트 SDK를 사용해 컴파일할 수는 있지만 32비트 운영 환경에서 동작하던 모든 기능이 완벽하게 64비트에서도 동작한다고 보장할 수 없으며, 비주얼 베이직으로 작성된 코드는 애초부터 WOW를 생각하지 않고 시스템을 동작시킬 수 없다. 따라서, 애플리케이션의 바이너리 코드가 전부 64비트로 전환할 수 있는 시스템이 일차적으로 효율적인 64비트 이전이 가능한 서버로 분류된다.

닷넷 프레임워크로 작성된 프로그램의 64비트 이전
닷넷 프레임워크 기반 하에서 작성된 프로그램은 별도의 변환 없이도 64비트 시스템에서 잘 동작한다. 하지만, 이렇게 시스템을 동작시킨다면, 이전 회에서 말한 바와 같이, 32비트의 WOW상에서 운영되는 결과를 낳는다. 따라서, 이러한 방식의 운영은 가급적 회피하는 것이 좋으며, 닷넷 프레임워크 자체를 64비트 기반 하에서 재컴파일해 배포하는 것을 권장한다.

닷넷 프레임워크 기반 하에서 작성된 프로그램은 최소한 소스 레벨에서는 32비트와 64비트 시스템이 100% 호환된다. 즉 32비트 시스템에서 작성돼 잘 운영되던 코드라면 64비트 시스템에서도 컴파일 이후 별다른 수정 없이 동작하는 것을 보장할 수 있다.

닷넷 프레임워크로 작성된 프로그램의 64비트 이전으로 생기는 가장 확실한 효과는 메모리 과다 사용에 의한 시스템 프로세스 리사이클링을 획기적으로 줄일 수 있다는 점이다-이 말은 64비트 윈도우에서 닷넷 프레임워크 기반의 프로그램이 메모리를 덜 사용한다는 의미가 아니라, 고용량 시스템에서 메모리의 과다 사용과 같은 상황을 64비트 시스템이 훨씬 더 잘 견딘다는 것을 의미한다.

이런 장점은 우선 고용량 웹서비스에서 바로 확인할 수 있다. 닷넷 프레임워크 기반에서 개발된 대용량 웹서비스의 프로세스는 수백 메가바이트의 메모리를 소모하는 경우가 빈번히 발견되며, 이는 허용된 워킹 셋 용량보다 높은 것이 다반사다. 현재까지 이 문제를 회피하기 위해 CPU 개수를 늘렸다면, 64비트 시스템의 도입은 그 자체만으로 가벼운(?) 수백 메가바이트의 메모리를 운용할 수 있게 해준다.

따라서 닷넷 프레임워크 기반 하에 작성된 대용량 응용 프로그램은 재컴파일 후 64비트 환경에 적용하는 것만으로도 획기적인 성능 향상을 도모할 수 있으며, 시스템의 안정성을 극도로 높일 수 있다. 하지만, 기껏해야 수 메가바이트의 메모리와 일 방문자 수백 명 수준의 작은 시스템을 운영한다면 64비트 시스템을 도입할 이유가 없다.

64비트 SQL 서버와 64비트 윈도우의 결합
64비트 SQL 서버와 64비트 윈도우가 결합해 운영되는 것은 64비트 윈도우를 가장 효과적으로 사용할 수 있는 방법 중의 하나다.

RDBMS는 일반적으로 사용할 수 있는 메모리의 정적 할당을 좋은 방법으로 권장하고 있지만, 실제 메모리를 정적으로 할당한다는 것은 운영체제의 입장에서는 그다지 달가운 일은 아닐 것이다. 또한 이 역시 가상 주소 공간을 점유하는 것일 뿐, 실제로는 한정된 물리적 메모리를 점유하기 위한 경쟁을 반복하게 된다.

SQL 서버 2000 이하의 버전에서는 이러한 메모리의 점유 문제가 튜닝의 중요한 포인트로 다가온다. SQL 서버에 의해 점유된 메모리가 많을수록 시스템은 느린 반응 속도를 보이며, 이를 방지하고자 SQL 서버에 정적 메모리를 할당했다가, 순간적인 사용량의 증가로 인해 정적 한계를 넘었을 때 시스템이 극도로 느려지는 현상이 벌어지기도 한다.

이러한 환경에서 64비트 윈도우는 일종의 탈출구 역할을 한다. 앞서 말한 바와 같이 시스템이 64비트로 이전했다고 해서 더 적은 메모리를 소모하는 것이 아니고, 더 많은 메모리를 소모해도 시스템이 잘 견딘다는 뜻이다.

사실, 소규모 시스템인 경우에는 SQL 서버의 64비트 버전 역시 과거 32비트 시스템에 비해 특별히 더 빨라진 것은 크게 느끼지 못할 가능성이 높다. 하지만, 정적 메모리와 동적 메모리의 설정 갈림길에서 헤매던 많은 관리자들의 고민을 덜어 줄 수 있는 방법이 64비트 시스템이라는 점은 확실하다.

메모리의 희생은 '시대적 대세'
64비트 시스템으로 훨씬 더 빠른 시스템을 운용할 수는 있지만, 64비트 시스템이 효과적이기 때문에 메모리가 덜 필요할 것이라고 생각하면 오산이다. 현재까지 컴퓨터의 발전 방향은 메모리를 점차 더 사용하는 방향으로 이어져 왔으며 64비트 시스템 역시 그 연장선상에 존재한다.

1기가바이트 메모리 모듈이 기본으로 장착된 최근의 컴퓨팅 환경에서, 빠른 시간 내에 대용량 데이터를 처리하려면 기존의 디스크가 했던 작업을 주 메모리로 자꾸 끌어 와야 한다. 물리적으로 디스크보다 메모리가 수천 배 정도 빠를 수밖에 없으며, 이러한 방법론으로 시스템이 발전한다면 프로그램은 '메모리 먹는 귀신'들이 될 수밖에 없다. 64비트 시스템의 가장 큰 장점은 한 번에 64비트를 처리할 수 있는 처리 능력보다는 관리할 수 있는 주소가 획기적으로 늘어난다는 점에 있다.

이러한 측면에서 디스크 I/O를 줄이기 위해 '메모리 먹는 귀신'으로 변신하는 SQL 서버나 통신 서버 시스템과 같은 고용량 서버군들은 64비트 이전 자체만으로 눈에 띄는 엔터프라이즈 시스템의 성능 향상을 노릴 수 있다.

메모리 한계가 명백했던 32비트 시스템에서는 가용 실제 메모리를 아무리 많이 장착하더라도 디스크 페이징을 피할 수 없는 구조로 작동됐기 때문에, 디스크 I/O를 줄이고자 한 작업이 오히려 부메랑으로 돌아오는 경우도 종종 볼 수 있었다. 따라서 64비트 시스템을 채용할 때는 '32비트 시스템보다 더 효과적인 메모리 관리'의 측면이 아닌 '32비트 시스템보다 더 메모리를 낭비하면서도 빠른 시간 내에 작업이 가능한' 시스템을 가정해야 하며, 그것이 훨씬 효율이 높은 업무 처리 결과로 다가오게 될 것이다. 우스갯소리로 32비트 시스템이 64비트 시스템으로 이전하면서 가장 많은 혜택을 볼 회사는 DRAM을 제작하는 반도체 회사라는 말이 있을 정도다.

64비트로 이전해 얻는 이득
많은 부하가 걸리는 시스템 자원 확보에 골치를 썩이면서, 현재 시스템의 주된 부하가 닷넷 기반 혹은 SQL 서버 그 자체라면, 64비트 시스템으로 이전하는 것이 확실한 효과를 주게 될 것이다.

물론, 64비트로 이전하면서 튜닝 포인트는 충분히 메모리를 사용할 수 있도록 처리하는 것이 좋다-이것이 메모리 릭(leak)을 유발하는 프로그램을 견딘다는 것은 아니다! 즉, 64비트 시스템은 CPU의 능력이 부족해 많은 연산을 처리하지 못했던 상황을 극복하는 것이 아니라, 컴퓨터와 운영체제의 구조 때문에 만들어졌던 하드디스크와 같은 보조 기억 장치가 발생하게 되는 부가적인 I/O로 인한 성능 저하를 차단하기 때문에 획기적인 성능을 발휘하도록 하는 것이다.

닷넷 기반이나 SQL 서버 그 자체가 아닌 응용 프로그램일 경우 WOW를 가정한다면 사실 64비트로 이전해 얻는 이득은 거의 없다고 보아도 무방하다. WOW가 아니라면, 프로그램 자원을 64비트로 모두 포팅해 컴파일하는 것이 64비트 시스템의 제 성능을 내는 방법이지만, 실제 이 방법을 사용하는 것은 그렇게 쉽지 않다. 64비트 시스템을 도입하는 비용과 더불어 32비트 코드를 모두 64비트로 전환하고, 테스트하는 비용이 상당하기 때문이다.

만일 4개의 CPU를 채용한 서버를 구매했지만, 응용 프로그램이 멀티프로세서를 지원하지 않는다면 해당 응용 프로그램은 단 1개의 CPU를 장착한 컴퓨터를 사용하는 것과 마찬가지 효과를 나타낼 것이다. 32비트 애플리케이션이 그대로 실행되는 64비트 시스템은 이러한 맹점이 존재한다.

모든 WOW가 성능이 저하되는 것은 아니다
64비트 상태에서 WOW로 돌아가는 응용 프로그램이 모두 성능이 저하된다고 볼 수는 없다. 대부분의 WOW 프로그램은 동일 성능의 32비트 CPU보다 느린 결과를 낳을 수 있겠지만, 멀티스레드가 아닌 멀티프로세스로 작성된 WOW일 경우 다량의 멀티프로세스가 운영되는 환경이라면 상당한 이득을 볼 수 있다.

또한, 다른 프로세스에 의해 메모리가 계속 페이징되고 있는 환경이라면 WOW를 쓰더라도 64비트 시스템을 운용하는 것이 페이징이 반복되는 32비트 시스템보다 훨씬 효율적이라고 볼 수 있다. 즉, 64비트 시스템의 I/O를 충분히 살릴 수 있다면 64비트로 이전을 감행하는 것이 훨씬 효율적인 결과를 얻게 된다. 각 응용 프로그램이 사용하는 CPU는 32비트 시스템이 더 효율적일 수 있지만, 페이징처럼 메모리 관리에 소모되는 CPU의 소모량이 이 응용 프로그램의 저하 소모량을 충분히 상쇄할 수 있다는 판단을 내릴 수 있으면 WOW 기반 하에서 64비트 시스템으로 전환하는 것도 충분히 생각해 볼 일이다.

32비트 시스템과 64비트 시스템의 혼용
현실적으로 기업 환경에서 가장 효율이 높은 방식은 32비트 시스템과 64비트 시스템을 혼용하는 것이다. 물론 이러한 시스템 운용 전략을 위해 MS는 서버 시스템 관련 소프트웨어를 제공하고 있다.

64비트로 당장 운용해도 좋은 부분들은 SQL 서버의 64비트 버전을 활용하는 것이 좋다. 이 작업은 테이블과 뷰, 혹은 저장 프로시저를 단순 이전하는 것으로 모든 업데이트 작업을 완료할 수 있다는 장점이 있다. 특히 과거 시스템의 소스 레벨의 재컴파일이 힘든 비주얼 베이직 기반이나 비주얼 C 기반의 응용 프로그램들은 전용 32비트 시스템에서 다음 시스템 개발 주기까지 운용하고, 닷넷이나 SQL과 같은 이전이 쉬운 시스템을 64비트 환경에서 운용하는 것이다. 이러한 방법은 64비트 시스템으로 운용하는 큰 효과를 보면서도 32비트 시스템을 무리하게 이전해 생기는 많은 시간과 비용을 줄여줄 수 있는 선택이라 할 수 있다.

만족스러운 시스템 이전의 포인트
현재 시스템에 걸리는 부하가 확연하며, 그 대부분이 메모리 워킹 셋의 부족으로 인한 디스크 I/O 때문이거나 실수 연산, 혹은 PKI 기반의 큰 수 연산 때문이라면 64비트 시스템으로 이전하는 것을 권하며, 그에 따른 큰 효과를 볼 수 있다. 물론, 모든 응용 프로그램을 쉽게 64비트로 이전할 수 있다는 기본적인 전제를 깔고서 말이다.

그러나, 이러한 문제로 인해 시스템이 부하가 걸린 것이 아니라면 64비트 이전은 사실 그렇게 큰 효과를 보지 못한다. 오히려, 현재 설계된 응용 프로그램의 로직을 재설계하고 튜닝 처리하는 것이 훨씬 효과적인 방법이다.

현재 시스템에 그리 큰 부하가 걸리지 않고, 하드웨어 처리 용량이 많이 남아 있다면 바로 64비트로 이전하는 것은 그다지 권장할 사항이 못 된다. 64비트 시스템의 도입은 하드웨어 튜닝에서 하나의 옵션일 뿐이며, 그 옵션이 정확히 적중하는 곳에서만 큰 효과를 발휘하게 된다.

만일, VOD 서비스 등의 여파로 인해 단순히 시스템의 부하가 많은 사용자의 대용량 파일 접속에 의해 일어난다면, 64비트 시스템은 사실 별 효과가 없을 수도 있다. 64비트 시스템이 처리해 줄 수 있는 I/O의 효과적인 속도 증진은 CPU와의 관계성의 문제이며, 스트림과 같은 형태는 오히려 저렴한 32비트 서버 여러 대와 고속 스토리지를 쓰는 것이 더 효율적이다.

엔터프라이즈의 '현재가 아닌 미래'
64비트 시스템이 활성화될 첫 타깃은 서버 솔루션이라기보다는 멀티미디어 환경이다. 과도한 메모리 사용과 끝없는 실수 연산이 매개되는 부분이며, CPU의 성능과 하드웨어 성능의 극한을 치닫는 특성이 있기 때문이다. MPEG 인코딩이나 렌더링과 같은 작업은 64비트 시스템을 도입하는 것만으로도 엄청난 효율성을 느낄 수 있다. 물론, 사용하는 그래픽 소프트웨어가 64비트 버전으로 최적화돼 컴파일된 것이라는 전제가 있기는 하지만 말이다.

64비트 시스템의 일차적 배포나 활용은 서버 버전의 64비트인 롱혼보다는 XP의 64비트 버전이 될 가능성이 훨씬 높다. 서버 시스템을 운용하는 회사에서 64비트 시스템으로 이전하는 것이 전체 시스템 성능을 높일 수 있는 환경은 현재 환경에서는 생각보다 많지 않다. 하지만, 64비트 시스템은 엔터프라이즈에서는 현재가 아닌 미래의 요구를 반영해 줄 수 있는 시스템의 기초가 된다.

기업의 많은 정보 처리는 점차 멀티미디어 환경을 갖추게 되고, 언젠가는 회의 기록을 데이터베이스에 타자로 기록하는 것이 아니라, 실시간 인코딩을 통한 동영상으로 저장할 수도 있다. 또 웹이나 기타 다른 모바일 수단으로 접속한 많은 고객들의 문의를 요약해 저장하는 것이 아니라, 그 자체로 저장할 수 있으며, 필요한 내용을 자동으로 추출할 수 있는 시스템이 점차 요구될 지도 모른다. 이러한 모든 작업을 수행하기에는 현재 32비트 시스템의 설계 구조로는 불가능하다. 4G의 플랫 메모리 구조로는 집 앞에서 빌려 보는 DVD 하나조차 담지 못하는 결함을 안고 있기 때문이다.

엔터프라이즈 환경에서 64비트의 도입 효과
현재 시스템의 파워가 부족하고, 그 이유가 I/O와 관련됐다면 엔터프라이즈 환경에서 64비트를 도입해 큰 이득을 보게 될 것이다. 그러나, 별로 부하가 걸리지 않는 시스템을 좀더 빠르게 응답하도록 해 볼 요량이라면 시스템의 도입보다는 코드의 최적화 튜닝이 훨씬 더 큰 도움을 줄 것이다.

따라서, 64비트 시스템으로 전체 시스템을 이전할 계획이 있다면 현재 시스템의 부하 원인이나 응답 저하 요인을 철저하게 분석해 시스템의 이전에 따른 실익을 계산해 봐야 한다. 일반적으로 과거 시스템을 기준으로 한다면 하드웨어 시스템 기반을 바꾸는 것보다는 튜닝이 훨씬 더 좋은 효과를 내게 된다.

현재 시스템의 성능 요구와는 무관하게 앞으로 사용자들의 기대치는 지금보다 훨씬 높아질 것이며, 그러한 요구들을 지금 32비트 기반 시스템에서 반영하기에는 구조적으로 쉽지 않다. 따라서, 시스템의 요구가 있지 않더라도 현재부터 모든 시스템을 64비트 기반에서 개발한다면, 향후 정말 이러한 변화가 이루어졌을 때 훨씬 쉽게 많은 문제를 해결할 수 있게 될 것이다.

선택은, 시스템을 도입하는 각 회사의 몫이며, 64비트 시스템이 많은 사람들이 생각하듯이 각 회사의 절대적인 지향점은 아니지만, 많은 회사의 미래 지향점이 될 수는 있다는 것이다. @