윈도우를 사용할 때 32비트 버전의 윈도우에서는 4GB 이상의 램을 활용할 수 없다는 이야기를 많이 들어보셨을 겁니다. 이 때 32비트 윈도우란 우리가 흔히 사용하는 윈도우 XP, 윈도우 비스타, 윈도우 7, 윈도우 8 의 32비트 버전을 의미합니다. 참고로 이러한 윈도우들은 윈도우의 제품 분류상 클라이언트 윈도우라고 부르고 있습니다.

클라이언트 윈도우 : 윈도우 XP, 윈도우 비스타, 윈도우 7, 윈도우 8
서버 윈도우 : 윈도우 서버 2003, 윈도우 서버 2008, 윈도우 서버 2008 R2, 윈도우 서버 2012



오늘 이야기의 대상이 되는 것은 바로 이러한 클라이언트 그룹의 윈도우들입니다. 그럼 이러한 클라이언트 그룹의 32비트 윈도우들은 어찌하여 4GB 이상의 램을 활용할 수 없게 된 것일까요? 그것을 이야기해보도록 하죠.

※ 참고! 이하 글의 설명에서 따로 언급하지 않는 한 윈도우라 지칭함은 이야기의 대상인 클라이언트 윈도우를 의미하는 것입니다.





실제 주소 지도와 4GB 한계 - Physical Address Map(PAM)

1. 실제 주소 지도(Physical Address Map)의 이해

윈도우가 시스템에 장착된 메모리를 사용하기 위해선 모든 메모리 공간에 대한 주소 정보가 필요합니다. 정확한 주소가 있어야만 원하는 위치에 제대로 접근(Access)할 수 있을테니까요. 그래서 시스템은 처음에 시작될 때 시스템에 장착된 모든 메모리 공간의 주소 정보를 담은 지도를 만듭니다. 이 지도가 바로 Physical Address Map(이하 PAM) 입니다. 즉, [PAM = 실제(물리) 메모리 주소 정보] 입니다. 시스템은 이렇게 작성한 PAM 정보를 윈도우에게 넘겨줍니다. 그럼 윈도우는 이렇게 시스템으로부터 넘겨 받은 PAM 을 토대로 메모리를 인식하고 접근하는 것입니다.

그래서 윈도우는 PAM 에 그 주소가 할당된 메모리만을 사용할 수 있습니다. 만약 PAM 에 포함되지 못한 메모리 공간이 있다면, 해당 메모리 공간은 윈도우에서는 인식할 수도 없고, 결국 사용할 수도 없는 것이죠.

그런데 지금까지 시스템은 32비트 체계였습니다. 32비트 CPU 는 32비트 주소 지정 방식(32bit Addressing)을 사용하였고, 그래서 할당할 수 있는 전체 메모리 공간의 개수도 이에 맞춰 32비트 즉, 2^32 * Byte = 4GB 가 되었습니다. 고로 PAM 에 할당할 수 있는 전체 메모리 주소는 2^32 * Byte 해서 4GB 의 크기를 가지게 된 것입니다. 결국, 이러한 한계로 인해 32비트 시스템에서 인식하여 사용할 수 있는 전체 메모리의 용량은 4GB 가 되었습니다.

또한 이러한 메모리 정보를 넘겨 받아 이를 관리해야 하는 32비트 윈도우의 메모리 관리자 역시 동일하게 32비트 체계로 메모리를 관리하였기에, 마찬가지로 32비트 윈도우 자체도 4GB 의 메모리만을 관리할 수 있습니다. 즉, 시스템과 윈도우 모두 32비트 주소 체계로 메모리를 관리하는 구조적인 이유로 4GB 메모리 인식 한계란 녀석이 생겨난 것입니다. 그래서 시스템에 메모리를 아무리 많이 달아도 32비트 시스템과 32비트 윈도우에선 4GB 이상의 메모리는 사용할 수 없었습니다. [* PAE 제외]




2. 시스템에 장착된 4GB 의 램을 모두 활용하지 못하는 이유

일단 이것을 먼저 이야기해야겠네요. 우선 32비트 시스템에서 최대로 사용할 수 있는 메모리의 용량은 4GB 라는 것을 알았습니다. 그런데 여기에서 다시 아래와 같은 의문을 많이 접하게 됩니다.


"제 시스템엔 분명 4GB 의 램이 달려 있는데 어째서 시스템 등록 정보에선 3.xGB 만 표시되는 건가요? 4GB 까지 쓸 수 있는 것 아니었나요? 이건 뭔가요? 제가 사용하는 램에 무슨 문제가 발생한 건가요?"


아니 왜 4GB 가 아닌 그보다 작은 용량으로 인식이 될까?


바로 위와 같은 상황인 것이죠. 분명 4GB 이상의 램이 장착되어 있으니, 32비트 윈도우의 4GB 인식 한계에 맞춰 4GB 를 사용할 수 있어야 할텐데, 실제로는 그보다 적은 3.xGB 만 인식을 하니 어리둥절할 뿐이죠. 이건 왜 그럴까요?


사실 이건 매우 간단한 겁니다. 먼저 여러분이 한 가지 반드시 아셔야 할 것이 시스템이 관리하는 모든 메모리란 램 하나만을 의미하는 것이 아니란 것입니다. 다른 말로 여러분의 컴퓨터에 메모리는 램 하나만 있는 것이 아니라는 것이죠. 당장 흔히 아는 그래픽 카드에도 메모리가 달려 있죠? 이처럼 컴퓨터를 구성하는 거의 모든 장치들은 각자의 메모리를 가지고 있습니다. 사운드 카드, 랜 카드와 같은 장치에도 메모리가 달려있고, 심지어 메인보드의 바이오스 조차도 메모리이니까요. 이러한 모든 장치들의 메모리(Device Memory)도 시스템에서 인식을 하고 사용할 수 있으려면 램과 마찬가지로 모두 그 주소를 할당받고 PAM 에 등록이 되어야 합니다. 즉, PAM 에 등록되는 메모리 주소 정보는 정확하게 이야기하면 아래와 같은 겁니다.

PAM = 장치 메모리 주소 + 램 메모리 주소


그런데 이러한 장치 메모리들의 주소는 반드시 메모리 인식 한계인 4GB 안에서 할당받아야 합니다. 즉, 시스템에 4GB 를 초과하는 메모리가 장착되어 있다면, 반드시 장치 메모리들의 주소를 4GB 안에서 우선 할당하는 것이죠. 왜 그럴까요?

간단하게 생각해보세요. 만약에 4GB 를 초과하는 메모리를 가진 시스템에서 이러한 장치 메모리들이 4GB 내에서 처리되지 못하고 램에게 밀려버려서 결국 주소를 할당받지 못한다면 어떻게 될까요? 예로 그래픽 카드의 메모리가 주소를 할당받지 못해서 그래픽 메모리를 사용할 수 없게 된다면요? 그러면 우리는 모니터로 출력되는 이 화면을 볼 수 없게 됩니다. 즉, 컴퓨터가 정상적으로 작동하는데 꼭 필요한 장치들을 사용할 수 없는 사태가 발생하는 것이죠. 그래서 PAM 에 각 메모리들의 주소를 등록할 때는 이러한 장치 메모리들을 램보다 우선하여 4GB 내에서 처리하는 것입니다. [실제론 중간에 치고 들어오지만요.]

이를 매우 단순화시켜서 정리하면 장치 메모리 주소는 램 메모리 주소보다 우선하여 할당된다. 라고 정리할 수 있습니다. 이 때문에 [장치 메모리 + 램 메모리] 가 4GB 를 초과하는 상황이 되면, 장치 메모리들의 주소를 먼저 할당하다보니 4GB 외의 영역으로 램 메모리 공간의 일부가 밀려나게 되고, 이렇게 밀려난 램 메모리 공간은 주소를 할당받지 못하여, 결국 해당 램 메모리 공간은 사용할 수 없게 되는 겁니다.



결론적으로 32비트 시스템에서 사용 가능한 램의 최대 용량은 4GB 가 아니라 [4GB - 장치 메모리의 총합]이 되는 것입니다. 그래서 장치 메모리의 용량이 늘어나면 사용 가능한 램 용량도 그만큼 줄어들게 되겠죠. 이게 바로 시스템 등록 정보에서 표시되는 3.xGB 의 정체입니다.

참고로 그래픽 카드 중에는 그래픽 메모리가 256MB 인 녀석도 있고, 512MB 인 녀석도 있고, 1GB 인 녀석도 있듯이, 장치 메모리는 각 장치들마다 모두 조금씩 다릅니다. 즉, 시스템마다 장치 메모리의 총합은 모두 다르고, 결국 4GB 이상의 램이 장착된 시스템이라면 사용할 수 있는 램의 용량도 모두 조금씩 달라지게 되는 겁니다. 그래서 제 시스템은 사용 가능한 램 용량이 3.48GB 이지만 여러분의 시스템은 3.7GB 가 될 수도 3.2GB 가 될 수도 있는 겁니다.


"앞으로 왜 제 시스템은 3.xGB 만 인식하나요? 하긔 있긔? 없긔????"







4GB 의 인식 한계를 극복하는 PAE 기능의 등장과 윈도우의 대응

1. PAE 기능의 등장과 윈도우의 대응

앞서 말했다시피 기존까지 CPU 는 32비트 주소 지정 방식을 사용했습니다. 그래서 시스템 차원에서 4GB 인식 한계 문제가 있었죠. 이렇게 되자 인텔은 기존까지의 32비트 주소 지정 방식을 보완하여 확장한 36비트 주소 지정 방식(32bit Addressing)을 CPU 에 새롭게 추가하게 됩니다. 그것이 바로 PAE(Physical Address Extention, 실제 주소 확장) 기능입니다. 이러한 PAE 는 36비트 주소 지정 방식을 사용하기 때문에 2^36 * Byte = 64GB 의 메모리를 인식할 수 있습니다. 하지만 당장 클라이언트 윈도우에서는 이러한 PAE 에 대한 지원이 이루어지지는 않았기에 여전히 우리가 사용하던 32비트 윈도우에서의 메모리 인식 한계는 4GB 가 되었습니다.

CPU 에 이러한 PAE 기능이 추가된 지 한참이 지난 후 슬슬 4GB 이상의 메모리를 지원하는 것에 대한 필요성이 대두되었고, 먼저 윈도우 서버 제품군에서 지원이 되었으며, 이후 클라이언트 윈도우에서도 DEP(Data Execution Prevention) 지원의 필요성으로 드디어 윈도우 XP 서비스 팩 2 에 이르러 이러한 PAE 기능을 지원하게 됩니다.



그렇다면 PAE 기능을 지원하는 CPU 와 칩셋을 사용하고, 이러한 시스템에 PAE 기능을 지원하는 32비트 윈도우를 사용한다면, 과연 32비트 윈도우에서도 기존까지의 4GB 인식 한계를 넘어선 메모리를 인식하는 게 가능할까요? 이건 일단은 맞습니다. 서버 제품군의 32비트 윈도우에서는 이렇게 사용하고 있으니까요.

사실 현재 시점의 컴퓨터들은 모두 PAE 기능을 지원하고 있고, 현재 사용되는 윈도우 XP 서비스 팩 3 나 윈도우 비스타, 윈도우 7, 윈도우 8 모두 PAE 기능을 지원하고 있으니, 사실 현재 여러분이 사용하는 32비트 윈도우들은 PAE 기능이 활성화되어 있는 상태라면 4GB 를 넘어서는 메모리를 모두 인식은 하고 있는 겁니다.

그런데 여기에는 한 가지 함정이 있습니다. 하드웨어에서 지원해도 윈도우가 이를 지원하지 않으면 안 되는 겁니다. 사실 클라이언트 버전의 32비트 윈도우에서 지원하는 PAE 기능은 반쪽 짜리라고 할 수 있습니다. PAE 가 활성화되어 있다면 32비트 윈도우에서도 4GB 를 넘어서는 메모리를 모두 "인식"하는 것은 가능하지만, 실제로는 (클라이언트) 32비트 윈도우 자체에서 이러한 메모리의 관리를 기존과 동일하게 4GB 로 제한하고 있기 때문에, 결국엔 여전히 사용하지 못하는 것입니다.




사실 윈도우 XP 서비스 팩 2 에서 PAE 기능을 지원하게 되면서 마이크로소프트사 내부적으로도 모든 클라이언트 32비트 윈도우 제품들의 메모리 관리를 그에 맞게 전환하는 것을 검토했었다고 합니다. 그런데 실제로 그것을 적용하려고 테스트를 하다 보니 문제가 생긴 겁니다. 원인은 지금까지 만들어진 장치 드라이버들이 이러한 PAE 의 36비트 주소 지정 방식의 사용을 고려하지 않고 설계가 되었던 것이죠. 즉, 기존의 드라이버들이 4GB 이상의 메모리를 사용하는 환경을 고려하지 못한 셈입니다. 그래서 내부적으로 테스트를 진행한 결과 일부 장치 드라이버들로 인해 블루 스크린이나 장치 인식 불능 등의 여러 가지 문제가 발생하였다고 합니다.

결국 마이크로소프트사는 클라이언트 제품군의 윈도우들은 DEP 기능을 위해서 PAE 기능을 지원은 하지만, 대신 메모리 관리는 기존대로 유지하는 선택을 합니다. 즉, 이는 4GB 이상의 메모리를 인식을 할 수는 있는데, 윈도우 스스로 메모리 관리의 한계를 기존대로 4GB 로 제한을 해버린 겁니다. [물론 그 때까지도 4GB 메모리 용량은 클라이언트 환경에서는 흔히 접할 수 없는 용량이긴 했습니다. 괜히 무리수를 두진 않은 것이겠죠.] 

이러한 이유로 32비트 윈도우더라도 서버 제품군에선 4GB 를 넘어선 메모리를 사용할 수 있지만, 클라이언트 제품군에선 여전히 4GB 의 제한이 있는 것입니다. 이것이 글의 시작에 클라이언트 윈도우와 서버 윈도우를 분리하여 이야기한 이유입니다.


사담이지만 마이크로소프트사가 클라이언트 제품군에서 4GB 인식 한계 문제의 해결을 포기한 것에는 AMD 가 한몫을 하지 않았나 생각합니다. 2003년 12월 AMD 는 인텔을 다시 한 번 기습했죠. 바로 애슬론64 CPU 를 출시한 겁니다. 아직은 시기 상조라고 생각했던 64비트 CPU 를 데스크탑 시장에 툭 던져 버린 거죠. 게다가 인텔의 아이태니엄과 같은 순수 64비트 CPU 가 아닌 기존의 32비트 윈도우도 아무런 문제없이 실행할 수 있는 32비트 호환 64비트 CPU 를 출시한 겁니다. 한 마디로 이를 지원하는 64비트 윈도우만 출시되면 끝나는 상황이었죠. 그래서 마이크로소프트는 32비트 윈도우보다는 64비트 윈도우의 개발에 더욱 집중한 것이 아닐까 생각합니다. [그 땐 AMD 가 참 좋았는데 말이죠.]

참고로 윈도우에서 PAE 기능을 활성화하는 경우에는 아래에서 이야기할 가상 주소(Virtual Address)를 실제 주소(Physical Address)로 변환하는 CPU 의 주소 변환 단계가 2단계에서 3단계로 한 단계 더 추가되기 때문에, 약 8% 정도의 전체적인 성능 하락이 발생하게 됩니다. 일반적인 가정 사용자를 대상으로 하는 클라이언트 윈도우 제품군에서는 이래저래 참 그렇고 그런 상황이었다고 할 수 있겠네요.




2. 윈도우의 반쪽짜리 PAE 지원 후 나온 편법적인 운영들

다시 한 번 정리하자면 이야기한 것과 같이 클라이언트 제품군의 32비트 윈도우더라도 PAE 기능이 활성화되어 있으면, 시스템 자체에서는 4GB 를 넘어서는 메모리를 인식하는 것은 가능합니다. 하지만 이것을 정확하게 지원하려면 윈도우의 메모리 관리도 함께 손봐야 했고, 내부적인 테스트 결과 여러 가지 문제가 발생하자, 기존까지의 메모리 관리 체계를 계속 유지한 거죠. 그 결과 32비트 윈도우에서 4GB 를 초과하는 메모리 영역은 관리하지 않는 미할당 영역으로 남겨지게 되었습니다. 즉, 어찌보자면 애초에 PAE 기능을 지원하지 않았던 예전과는 다른 상황이라고 볼 수 있습니다.


그래서 이러한 상황에 맞춰 나온 한 가지 편법이 바로 '윈도우에게 버림받은 4GB 외의 나머지 미할당 램 공간' 을 활용하여 램 디스크를 만드는 것입니다. 즉, 어차피 인식은 되어 있는 상태이고, 단순히 미할당된 채 활용하지 않고 있는 것이니, 여러 써드 파티 램 디스크 프로그램에서 자체적으로 직접 해당 메모리 영역을 제어하여, 이를 램 디스크로 활용하는 방법이 나온 것입니다. 즉, 이러한 다소 편법적인 램 디스크의 활용은 PAE 지원을 기초로 한다고 할 수 있습니다. 그래서 PAE 가 활성화되어 있지 않다면 이러한 방법도 먹히질 않습니다. 혹시나 이 방법이 궁금하시다면 아래의 글들을 참고하세요.



또 이와는 다른 방법으로, 윈도우 비스타 이후부터는 어차피 서버 윈도우 제품군이나 클라이언트 윈도우 제품군이나 동일한 커널을 사용하지만, 단순히 클라이언트 윈도우에서 메모리를 제한하고 있는 것이기 때문에, 이러한 제한을 해제하도록 커널을 패치하고, 이에 맞춰 부팅 옵션을 수정하여 클라이언트 32비트 윈도우 제품군에서도 4GB 를 넘어서는 용량을 사용할 수 있도록 만드는 패치가 존재하기도 합니다. 즉, 윈도우에서 걸어 놓은 제한을 뚫는 방식인 것이죠. 이에 대한 내용은 스누피님께서 소개해주셨더군요.


한 가지 반드시 명심하셔야 할 것이 애초에 마이크로소프트에서 메모리 관리를 4GB 로 제한한 이유가, 위에서 이야기한 것과 같이 일종의 장치 드라이버들과의 호환성이었기 때문에, 이 커널 패치 방식을 사용하는 경우 해당 문제와 직면할 수 있다는 것입니다. 그래서 어떠한 시스템에서는 아무런 문제가 없을 수 있지만, 어떠한 시스템에서는 즉시 문제가 발생할 수도 있다는 것이죠. 어떠한 장치에서 그러한 문제가 발생할 지는 사실 아무도 모른다고 할 수 있습니다. 일종의 되면 쓰고 안 되면 안 되는 복불복이라고 할 수 있겠네요.

그리고 이건 커널을 패치하는 좀 위험한 작업에 속하기도 합니다. 앞서의 램 디스크와는 다르게 이 방법은 윈도우가 한 순간에 맛탱이가 갈 수 있습니다. 그래서 이러한 편법도 존재하고 있다는 차원에서 소개를 하는 것이지, 그것을 꼭 사용해보라고 권장하는 것은 아닙니다. 그것을 명심하세요. 그러니 만약에 자신도 한 번 이러한 커널 패치를 적용해보고자 한다면, 미리 윈도우를 백업하시길 바랍니다.






가상 주소 공간의 이해 - VAS 와 페이징 파일, 4GT 옵션

※ 참고! 지금부터 이야기하는 가상 주소 공간은(Virtual Address Space) 위에서 이야기한 PAE 와는 별개의 내용입니다.

윈도우는 메모리 관리에 지금까지 이야기한 실제 메모리 공간(실제 주소)을 바로 사용하는 것이 아닌, 중간에 가상 주소 공간을 두고, [가상 주소 공간 - 메모리 관리자 - 실제 메모리] 의 메모리 관리 구조를 가지고 있습니다. 그런데 실제 메모리는 4GB 의 인식 한계를 가지고 있죠? 그래서 32비트 윈도우의 가상 주소 공간도 이에 맞춰 4GB 크기를 가지도록 설계하였습니다.

그리고 이러한 4GB 의 가상 주소 공간은 다시 2GB 의 커널 모드 공간2GB 의 유저 모드 공간으로 나누어집니다. 이 때 커널 모드 공간은 윈도우가 사용하는 공간이고, 유저 모드 공간은 우리가 보통 사용하는 일반 응용 프로그램들이 사용하는 공간입니다.




간단하게 프로그램이 실행되려면 프로그램이 우선 적절한 메모리 공간을 할당받고 그곳에 적재되어야 합니다. 이 때 말했다시피 윈도우의 메모리 관리자는 실제 메모리 공간에 해당 프로그램이 사용할 공간을 바로 준비하여 직접 메모리 공간을 할당해주는 것이 아닙니다. 그럼 어떻게 하느냐?

프로그램에게 메모리 요청이 오면 우선 메모리 관리자는 프로그램이 사용할 수 있는 2GB 의 가상 주소 공간을 던져주고는 프로그램에게 그곳에서 작업을 하라고 합니다. 그럼 프로그램은 윈도우가 제공한 가상 주소 공간에서 작업을 진행하는 겁니다. "이럴수가! 이 많은 메모리 공간을 전부 나에게 주다니? 나 아무래도 사랑받는 듯! 히힛~ '-'*" 하면서 말이죠. 참고로 이 때 프로그램이 제공받은 2GB 의 가상 주소 공간은 유저 모드 공간을 의미합니다.

그런데 이 때 또 다른 프로그램에게 메모리 요청이 들어오면 어떻게 될까요? 이 때도 마찬가지로 메모리 관리자는 해당 프로그램이 사용할 수 있는 별개의 2GB 가상 주소 공간을 또 던져줍니다. 또 다른 프로그램이 메모리 요청을 하면? 또 2GB 짜리 가상 주소 공간을 해당 프로그램에게 던져주죠. 즉, 유저 모드 가상 주소 공간이라는 것은 이처럼 프로그램 모두에게 개별적으로 제공되는 공간인 것입니다. 그리고 그 크기는 항상 최대 크기로 해서 제공이 됩니다. 그럼 각각의 프로그램들은 이렇게 독립적으로 제공된 자신만의 가상 공간에서 작업을 하는 것이죠. [이와는 달리 커널 모드 공간은 단일 공간으로 커널 모드를 사용하는 모든 프로세스에서 공유됩니다.] 

그런데 이렇게 프로그램이 사용하는 가상 주소 공간의 내용도 실행되려면 결국엔 실제 메모리로(실제 주소 공간으로) 옮겨져야 합니다. 이 또한 메모리 관리자가 담당하게 됩니다. 즉, 메모리 관리자는 프로그램들에게 가상 주소 공간을 제공해주고, 이러한 가상 주소 공간에서 프로그램들이 작업한 것들이 실제 메모리에 적재될 필요가 있다면, 이를 알아서 실제 메모리의 적절한 위치로 탑재를 하는 것이죠.

결론적으로 윈도우에서 응용 프로그램이 실행되는 구조를 정리하자면   ① 프로그램으로 부터 메모리 공간에 대한 요청이 들어오면   ② 메모리 관리자가 프로그램들에게 먼저 가상 주소 공간을 제공해주고   ③ 프로그램들은 자신에게 주어진 유저 모드의 2GB 가상 주소 공간에서 필요한 작업을 하고   ④ 이렇게 각각의 프로그램들이 가상 주소 공간에서 작업한 내용들은 다시 메모리 관리자가 바로 바로 실제 메모리 공간의 적절한 위치로 배치하는 것입니다. 간단하죠?



참고로 메모리 관리자가 가상 주소 공간을 프로그램 모두에게 동일하게 최대 용량으로 제공해줬죠. 그럼 프로그램들은 "아싸 넓직하니 좋구나!" 하면서 자신에게 주어진 작업 공간을 활용하고요. 즉, 이러한 구조로 프로그램들은 마치 모든 메모리 공간을 혼자 독점하여 최대로 사용하는 것과 같은 효과를 얻을 수 있습니다. 그리고 가상 공간에서 열심히 작업만 하면, 메모리 관리자가 알아서 실제 메모리로 탑재도 해줍니다. 고로 응용 프로그램 차원에서는 현재 시스템의 메모리 용량이 얼만지, 실제 메모리 공간의 가용 상태는 어떤지, 내가 작업할 공간은 있는지 등등등, 메모리의 운영에 대해서는 전혀 알 필요도 없고 걱정할 필요도 없는 것이죠. 뭐 그냥 그렇다는 이야기입니다. [대신 메모리 관리자는 죽어 나겠지...]



그런데 이렇게 프로그램들이 모두 각자의 가상 주소 공간에서 원없이 작업을 하고, 그러한 결과물들을 모아서 실제 메모리로 올리다보면 필연적으로 실제 메모리 공간이 부족해지는 상황이 발생할 수 있습니다. 그럴 때 사용되는 것이 바로 윈도우의 가상 메모리 즉, 페이징 파일(Pagefile.sys) 입니다.

실제 메모리 공간이 부족한 상황이 발생하게 되면, 메모리 관리자는 실제 메모리 공간에서 지금 당장 사용되지 않는 내용을 디스크의 페이징 파일로(Pagefile.sys) 옮김으로써 실제 메모리 공간을 확보합니다. 그리고 이렇게 페이징 파일로 옮겨진 내용을 다시 사용한다는 요청이 오면 페이지 파일에서 다시 실제 메모리로 옮기는 것이고요. 실제 메모리 공간이 부족할 때마다 이것을 계속 반복하는 것이죠. 즉, 이러한 실제 메모리와(RAM) 가상 메모리(Pagefile.sys) 사이의 페이지 스왑을 통해 실제 메모리 공간의 사용 가능한 용량을 조절하는 겁니다. 간단하게 이야기하면 윈도우 가상 메모리의 작동 방식은 이렇습니다. [간혹 가상 메모리가 실제 메모리를 연장하는 것으로 알고 계신분들이 있더군요. 설명과 같이 가상 메모리는 실제 메모리 공간이 부족할 때 임시로 실제 메모리의 내용을 보관해두기 위한 곳입니다.]


문제는 이러한 스왑 과정은 많은 단계가 필요하고, 결정적으로 디스크는 램과 비교해서 정말 느리다는 겁니다. 그래서 이러한 실제 메모리와 가상 메모리 사이에서 페이지 스왑이 자주 발생하게 되면 그만큼 시스템의 성능은 떨어지게 됩니다. 이러한 문제를 해결하는 가장 근본적인 방법은 되도록이면 페이지 스왑이 일어나지 않도록 사용할 수 있는 실제 메모리 공간 즉, 램의 용량을 늘리는 것입니다. 결국은 램을 많이 장착해야 하는 것이죠. 하지만 32비트 윈도우는 최대로 관리할 수 있는 실제 메모리의 용량이 4GB 뿐이고, 이마저도 앞서 이야기했듯이 장치 메모리에게 자리를 내주다보면 결국 32비트 윈도우가 사용할 수 있는 램 공간은 3.xGB 정도만이 주어질 뿐입니다.

프로그램들의 용량은 점점 거대해지고 그만큼 이전보다 더욱 많은 메모리 공간이 필요해진 시점에서 이러한 32비트 윈도우의 메모리 인식 한계는 점점 더 큰 단점으로 작용하고 있습니다. 결국 이것은 지원 가능한 메모리의 용량이 비약적으로 증가한 64비트 윈도우가 필요해진 이유가 된 것이죠. 참고로 현재 64비트 윈도우는 윈도우 버전에 따라 1TB~192GB 정도의 메모리 용량을 지원하고 있습니다. 32비트 윈도우와는 비교가 되지 않는 용량이죠. 뭐 그렇다는 겁니다.



그런데 32비트 윈도우의 이러한 4GB 로 설계된 가상 주소 공간으로 인해 한 가지 문제가 더 발생하게 됩니다. 말했다시피 4GB 의 가상 주소 공간 중 윈도우가 사용하는 2GB 의 커널 모드 공간을 제외하면, 실제로 응용 프로그램이 사용할 수 있는 가상 주소 공간은 2GB 의 유저 모드 공간이 그 한계라고 할 수 있습니다. 고로 32비트 윈도우에서 실행되는 모든 프로그램들은 이 2GB 의 유저 공간에서 모든 것을 처리해야 하는 것이죠. 즉, 이는 실제 메모리가 4GB 아니 400GB 가 있더라도, 가상 주소 공간의 근본적인 구조상 하나의 프로그램이 활용할 수 있는 메모리 공간은 최대 2GB 를 넘지 못한다는 겁니다. 물론 설계 당시에야 2GB 라는 용량은 꿈과도 같은 용량이었죠.

그러나 세상이란 게 언제나 늘 그렇듯이 설계 당시에는 설마 했던 일들이 기술의 발전과 함께 결국엔 실제로 닥친다는 게 항상 문제입니다. 그러니까 프로그램들이 점점 거대해지면서 실제로 이 2GB 를 넘어서는 메모리 공간을 사용하려는 프로그램들이 실제로 등장을 했다는 겁니다.

얘가 메모리를 좀 많이 사용해서 여럿 힘들 게 했지...



그래서 윈도우에서 이러한 문제를 해결하기 위해 사용한 방법이 바로 가상 주소 공간을 변형하는 4GT(4 Gigabyte Tuning) 옵션입니다. 흔히 /3GB 옵션으로 많이 알려져 있죠. 4GT 옵션이란 사실 매우 간단합니다. 가상 주소 공간의 비율을 [유저 공간 2 : 커널 공간 2] 에서 [유저 공간 3 : 커널 공간 1] 로 바꿔주는 겁니다. 즉, 윈도우에서 사용하는 커널 모드 공간을 1GB 로 줄이고, 이렇게 확보한 공간을 유저 모드 공간에 추가하여 응용 프로그램이 사용할 수 있는 유저 모드 공간의 크기를 3GB 로 늘린 것입니다. 매우 간단하죠?




그런데 이러한 4GT 옵션을 무작정 사용하기도 좀 그렇습니다. 우선 이렇게 유저 모드 공간을 늘리더라도 대부분의 프로그램들은 이렇게 늘어난 3GB 의 유저 모드 공간을 정상적으로 활용하지 못하고, 기존대로 2GB 의 공간만을 사용한다는 겁니다. 왜냐? 해당 프로그램들은 애초에 2GB 의 유저 모드 공간을 사용하도록 만들어졌기 때문이죠.

이렇게 늘어난 3GB 의 유저 모드 공간을 정상적으로 활용하기 위해선 해당 프로그램이 이러한 3GB 공간을 모두 사용할 수 있도록 만들어져야 합니다. 그렇기 때문에 4GT 옵션을 반드시 필요로 하는 프로그램(그것을 지원하도록 만들어진 프로그램)을 사용할 것이 아니라면 4GT 옵션은 적용하나 마나 아무런 필요가 없는 옵션이 되는 것이죠. 그래서 "오홋! 3GB 로 늘리면 응용 프로그램들이 그만큼 더 많은 공간을 사용할 수 있을테니 좋겠네? 나는 무조건 적용해야지!" 할 성질의 옵션은 아니라는 이야기입니다.

다음으로 문제가 되는 게 커널 모드 공간은 커널, 시스템 캐시, Paged Pool, Nonpaged Pool 등, 윈도우의 운영과 관리에 핵심적인 요소들이 사용하는 공간입니다. 4GT 옵션이란 게 이러한 커널 모드 공간을 쥐어짜서 줄여놓은 형태이죠. 그래서 결국 이는 윈도우 운영의 핵심 자원이 줄어든 것이고, 이것은 윈도우에 미처 생각치 못한 악영향을 미칠 수 있습니다. 즉, 응용 프로그램의 메모리 부족이 아닌 윈도우의 핵심적인 운영부에서 메모리 부족 현상이 발생할 수 있는 것이죠.

이러한 이유들로 4GT 옵션의 적용은 신중해야 합니다. 더욱이 만약 시스템의 전체 램 용량이 1~2GB 와 같이 작은 환경이라면 실질적인 효용 가치도 없는 옵션이라고 할 수 있습니다. 아무리 응용 프로그램이 사용하는 유저 모드 가상 주소 공간의 크기를 늘리더라도 실제 램에 이를 올릴 수 있는 공간이 준비되어 있지 않다면 말짱 도루묵일 뿐이기 때문이죠. 그러니 4GT 옵션은 램 용량이 충분한 상황에서(인식 한계까지 램이 장착된 상황에서) 프로그램이 꼭 필요로 할 때만 사용하는 것이 좋습니다.


대략적이었지만 가상 주소 공간에 대해서 정리를 해보았습니다. 어떻게 도움이 되었나 모르겠네요. 여담으로 가상 주소 공간과 가상 메모리(페이징 파일)은 전혀 다른 의미입니다. 헷갈리지 마세요. ^^ 그리고 지금 이야기한 4GT 옵션과 앞서 이야기한 PAE 기술은 전혀 별개의 내용입니다.






마치며...

지금까지 알아본 것과 같이 32비트 윈도우는 실제 메모리의 4GB 인식(관리) 제한에 더해 가상 주소 공간의 4GB 제한까지 있으니, 메모리의 관리에 있어서 만큼은 64비트 윈도우에 비해 확실하게 떨어진다고 할 수 있습니다. 이래저래 프로그램들은 점점 더 고사양화되어가고, 시스템에 장착되는 메모리의 용량은 자꾸 늘어가는 현재의 상황에서 32비트 윈도우가 설 자리는 점점 줄어들고 있는 것이죠.

참고로 위에서 미처 언급을 하지 못했는데요. 64비트 윈도우의 경우 유저 모드 가상 주소 공간의 크기는 무려 8TB 나 됩니다. 커널 모드 공간도 8TB 이고요. 스케일의 차이가 다르죠? 그런데 여기에서 한 가지 알아두셔야 할 것이 이것은 64비트 프로그램에게 주어지는 가상 주소 공간이라는 것입니다. 만약 64비트 윈도우에서 32비트 프로그램을 실행하는 경우에는 기존과 동일하게 2GB 의 유저 모드 공간을 제공해줍니다. 그래도 32비트 윈도우에 비해 더 나은 점이라면 앞서 말한 4GT 기술을 사용할 수 있도록 제작된 프로그램을 실행하는 경우엔 자동으로 4GB 의 유저 모드 공간을 제공해준다는 것입니다. 그래도 이건 나름 괜찮죠?

이러한 연유로 동일한 32비트 프로그램을 사용하더라도 64비트 윈도우가 32비트 윈도우에 비해 좀 더 나은 환경을 보장해준다고 말할 수도 있을 듯 합니다. 물론 가장 좋은 것은 64비트 윈도우에서 64비트 프로그램을 사용하는 것이겠지만요. ^^


어떻게 제가 정리한 내용이 여러분들께 도움이 되었을지 모르겠네요. 윈도우의 메모리 관리 부분이란 게 사실 깊이 들어가면 좀 너무 전문적이고 심란한 부분이 많습니다. 사실 저도 100% 아는 것은 아니고요. 그래도 오늘 글에서 이야기한 정도만 대략적으로라도 알고 계신다면 충분히 도움이 될 수 있을 거라고 생각합니다. 그런데 이러한 구조나 개념적인 부분에 대한 설명은 보다 정확하고 확실해야 하는데, 사실 제가 정리한 내용이 어찌보자면 너무 전문적인 부분인지라 그 의미들을 정확히 맞게 전달하고 있는지 다소 걱정이 되네요. 그래도 대략적인 큰 틀에서 보자면 많이 틀리진 않았으리라 생각됩니다. 그래도 혹시나 모르니 제 설명 중 잘못되었거나 오류가 있다면 알려주시길 바랍니다.

긴 글 읽어주셔서 감사하고요. 다른 글 정리하다가 어떻게 이게 튀어 나오게 되었는지 모르겠네요. 너무 장황하게 나온 듯 싶기도 하고요. 뭐 어쩔 수 없죠. 아무튼, 이번 글은 여기서 마치도록 하겠습니다. 감사합니다. ^^


"컴퓨터에 램이 4GB 이상 달려 있다면 그냥 64비트 윈도우를 설치해서 사용하세요. 그게 정신 건강에 좋습니다."


 

 

신고
캐플 블로그에 공개된 글은 반드시 원본 글의 링크를 포함시키는 조건으로 자유롭게 이용하실 수 있습니다.
하지만 블로그의 발전을 위하여 되도록이면 링크로 글을 소개해주시길 부탁드립니다. ^^

- 상업적인 용도의 사이트는 대상에서 제외됩니다. -
- 글에는 오류가 있을 수 있고, 추후 수정 또는 재발행될 수 있습니다. -
  1. 이전 댓글 더보기
  2. BlogIcon 니드뽀폴쉐 2013.03.30 20:01 신고  댓글주소  수정/삭제  댓글쓰기
    재밌게 잘 봤습니다.
    3.X 표시 부분은 이런저런 (댓)글 엄청 읽고 나서야 이해했는데...
    역시 깔끔하십니다.ㅜㅜ

    약 20년 전에 첨 컴터를 샀을때 MS-DOS 5.0이 기본이었는데 당시에는 두꺼운 도스용 책을 주더군요. 제조사 로고가 박힌... 어릴때 멋도 모르고 열심히 읽으며 특히 고민했던게 메모리 관련이었습니다.
    640KB가 기본이고 그 이상의 고위영역 메모리(?), 중첩확장 메모리(?) 뭐 이런것 때문에 고민을 많이 했는데 결국 별 의미는 없었...ㅋㅋ
    나중에 보니 게임을 할 때 config.sys 파일을 수정할 때나 알면 가끔 도움 되는 정보더군요.


    그나저나... x86 클라이언트용 윈도우의 4GB제한은 일부러 안푸는 것 같았는데 마소에서도 고민을 하다 포기했다는게 놀랍네요. @.@a
    • BlogIcon CApple 2013.03.30 20:05 신고  댓글주소  수정/삭제
      아마 꼭 필요하다면 어떻게든 풀었을 겁니다. 서버에서는 진작에 풀었거든요. ^^a
    • 2013.03.30 20:12  댓글주소  수정/삭제
      비밀댓글입니다
    • BlogIcon CApple 2013.03.30 20:21 신고  댓글주소  수정/삭제
      그러한 부분은 그렇게 가는 것이 장기적으로 더 도움이 되지 않을까 생각합니다. 그러한 문제로 아예 해당 서비스 자체가 사라진다면 오히려 그것이 더 손해일테니까요. 신경 써 주셔서 감사합니다. ^^
    • Darkness Angel 2013.03.30 20:33 신고  댓글주소  수정/삭제
      저랑 같은 추억을 가지고 계시네요

      가끔 미친게임이 610~620kb달라고하고, EMS안 먹으면 장치드라이브 로드 목록까지 수정해야 억지로 돌아갔죠; (그런주제 SB지원인 넘들은 대체 무슨수로 드라이브 올리란걸까요 -_-)
    • BlogIcon 니드뽀폴쉐 2013.03.30 21:56 신고  댓글주소  수정/삭제
      ㄴ당시 애들이 특정 게임용 부팅디스켓을 들고 다니곤 했는데, 게임에 소질이 없어서 그냥 구경만 하다보니 예전에 책에서 본 것들이구나 정도였네요.ㅋ
    • BlogIcon CApple 2013.03.30 22:04 신고  댓글주소  수정/삭제
      Devicehigh=......
  3. Darkness Angel 2013.03.30 20:32 신고  댓글주소  수정/삭제  댓글쓰기
    앗; OS및 하드웨어의 메모리 관리관련 제가 정리해서 링크 던질려고했는데, 몇시간만에 갱신된걸 발견해버렸군요; ㅠ.ㅜ

    참고로 커널 패치 이외에도 MBR이나 기타 부분을 변형해도 PAE옵션 활성화 가능합니다 (부작용은 동일)
    • BlogIcon CApple 2013.03.30 21:30 신고  댓글주소  수정/삭제
      사실 이 글이 먼저 작성되었고, 공개하기 전에 관련이 있는 예전에 작성했던 페이징 파일 글을 링크로 추가하려고 조금 다듬어서 추가로 끌어올린 것입니다. ㅎㅎㅎ 한 번에 몰아서 포스팅이 공개되면 좀 그렇기에 오전 오후로 나눠서 차례로 공개한 것이고요. (이제 보니 글에 링크를 안 걸어놨네요;;;) 아참~ 그리고 말씀하신 내용은 정리하시고 트랙백으로 보내주시면 되죠. 그러라고 있는 트랙백인데요. ^^

      p.s 커널 패치 외에도 다른 방법도 있었군요. 좋은 정보 감사합니다. ^^
  4. BlogIcon Minty99 2013.03.30 21:06 신고  댓글주소  수정/삭제  댓글쓰기
    마지막 말이...ㅋ...ㄷㄷㄷ
  5. BlogIcon Minty99 2013.03.31 20:31 신고  댓글주소  수정/삭제  댓글쓰기
    다음뷰 베스트글, 축하드립니다~^^
  6. 필마 2013.06.05 15:14 신고  댓글주소  수정/삭제  댓글쓰기
    32비트 운영체재의 4기가 메오리의 한계.. 평소 궁금했는데 자세한 설명으로 대충 이해를 했습니다.
    좋은글 감사 합니다.
  7. rkrtjd 2013.07.10 14:50 신고  댓글주소  수정/삭제  댓글쓰기
    예전에 램디스크로 돌려진 여분용량을 다시 램으로 활용하는 방법이 있던 것으로 알고 있습니다.
    이 방법을 사용하면 32bit에서도 램 용량을 늘릴 수 있다고 했었죠.
    물론 램디스크의 종류마다 지원유무가 다릅니다.
    즉 실제 인식 램용량+램디스크로 돌려진 걸 다시 램으로 돌린 용량=원래 램용량
    이란거죠.
    아마 무료 램디스크 중에 지원되는 게 있었을 겁니다.
    근데 그게 근본적으로 스누피님의 글 내용과 원리가 같은건지는 모르겠네요.
  8. 김컴맹 2013.09.13 04:00 신고  댓글주소  수정/삭제  댓글쓰기
    와! 어려운 내용이 귀에 쏙 들어오는 마법 @_@b
    우연히 찾게되었는데 많은 걸 배워가고 있어요 ㅎ

    제 노트북이 똥컴이라 램이 2GB인데 시스템과 각종 프로그램들이 IDLE로 차지하는 공간만 거의 1GB 되더라고요 ㅠ
    으... 용량압박이 장난아니에요 ㅠ_ㅠ;
  9. 지나가는 행인 2013.09.16 13:26 신고  댓글주소  수정/삭제  댓글쓰기
    완전 잘보고 갑니다 ㅎㅎ
  10. BlogIcon 비필 2013.10.05 22:31 신고  댓글주소  수정/삭제  댓글쓰기
    저도 게임때문에 3GB 옵션 했다가 블루스크린 몇번보고 64비트로 갈아탔었죠...
    그당시에는 이렇게 정리가 잘된 글이 없어가지고 고생했습니다.
    좋은글 잘보고 갑니다.
  11. live 2014.02.04 21:38 신고  댓글주소  수정/삭제  댓글쓰기
    이업계에서밥먹고사는사람이지만그동안피상적으로알고있던내용인데명쾌하게정리해주셔서감사드립니다.추천을안누를수가없네요.^^
  12. BlogIcon ㅁㄴ 2014.04.13 04:10 신고  댓글주소  수정/삭제  댓글쓰기
    윈도우 외의 운영체제에도 동일하게 적용되나요?
  13. 종달 2014.09.13 01:31 신고  댓글주소  수정/삭제  댓글쓰기
    궁금한게 있습니다... 4G이내의 시스템 메모리를 가진 유저들이 64Bit시스템을 설치 할경우(물론CPU가 지원된다는 조건하에)이득이 있을까요? 애플의 경우 시스템을 기본64Bit로 고정해서 쓰는데요 굳이 32Bit 호환해도 될텐데 통합한데는 이유가 있을거같아서요 제 생각에는 메모리 주소값이 늘어나서 램이 적더라도 한번에 처리되는 정보량이 많아져서 순간적인 처리 속도가 빠르지 않나... 라는 생각을 해봅니다만... 맞을까요?
  14. 지나가는 행인 2015.01.19 12:39 신고  댓글주소  수정/삭제  댓글쓰기
    사실 .. 2^32 비트가 4기가 라서 32 bit머신이 4기가 인건 아닙니다만......
  15. BlogIcon iiminuii 2015.01.20 10:27 신고  댓글주소  수정/삭제  댓글쓰기
    정리 정말 잘 하시네요. 잘 읽고 있습니다. ^^
    읽다보니 pae 설명시작부에 [32비트 주소 지정 방식을 보완하여 확장한 36비트 주소 지정 방식(32bit Addressing)을 CPU 에 새롭게 추가하게 됩니다. ] 요런 내용이 있는데요...

    36비트 주소 지정 방식(32bit Addressing) 이부분에 괄호안에 32bit로 쓰여진 오타가 보여서요..
    수정해두면 좋겠다 싶어 글 남김니다..

    내용이 좋아서 걍 지나칠 수 없네요

    좋은하루 되세요
  16. 달달 2015.02.13 11:02 신고  댓글주소  수정/삭제  댓글쓰기
    굳굳!! 훌륭한 글입니다.
  17. 지나갈려면걍지나갈것 2015.05.15 18:55 신고  댓글주소  수정/삭제  댓글쓰기
    사실 .. 2^32 비트가 4기가 라서 32 bit머신이 4기가 인게 맞습니다만......
  18. 행인3 2015.09.03 18:51 신고  댓글주소  수정/삭제  댓글쓰기
    좋은 자료 감사합니다~정리 잘하시는게 부럽네요 ㅎ
  19. 행인4 2015.12.02 10:48 신고  댓글주소  수정/삭제  댓글쓰기
    좋은글 감사합니다 많은 도움이 되었습니다 ^^
  20. 공돌이 2016.02.10 01:55 신고  댓글주소  수정/삭제  댓글쓰기
    좋은 글 감사합니다.
    궁금한 것이 하나 있습니다.
    4GT 설정을 하지 않고 램을 3g만 설치하면 커널과 어플리케이션이 어떻게 나누어 지나요?
    커널 2g 어플 1g
    커널 1g 어플 2g
    아니면 1:1로 1.5g씩 인가요?
    • 심소량 2016.02.11 23:50 신고  댓글주소  수정/삭제
      저렇게 나눠지는 메모리 공간은 애초에 가상 메모리 공간이므로, 물리 메모리의 크기와는 관련이 없습니다. 가상 메모리는 모든 프로세스에 대해 각각 4GB가 존재하지요.

      그 중 사용되지 않는 영역은 운영 체제가 내버려 두고 (접근하려고 하면 오류가 발생), 프로세스가 사용하는 영역만을 물리 메모리와 연결합니다.

      만약 모든 프로세스가 사용하는 메모리 내용을 전부 물리 메모리에 올려 두기에 물리 메모리가 부족할 경우는 현재 사용되고 있지 않은 부분을 잠깐 하드 디스크에 내려 두고 배치표를 바꾸는 것입니다.
  21. BlogIcon 데브심 2016.12.29 10:25 신고  댓글주소  수정/삭제  댓글쓰기
    메모리에 대해서 정보를 찾다가 좋은 글 읽고 갑니다. 감사합니다 ^^

댓글을 달아 주세요

- 댓글에선 예의를 지켜주시기 바라며, 블로그지기는 댓글에서 따로 활동하지 않습니다.

* 티스토리 사용자는 여기를 클릭하시면 로그인 됩니다.

BBCode 안내   굵게 밑줄 기울임 취소선   취소선 취소선 취소선 취소선   왼쪽 정렬 가운데 정렬 오른쪽 정렬   코드박스 인용구 이미지   이미지 업로드-Imgur.com