RAM/주소할당 문제

• 상위 항목: RAM

1 개요

이 항목에서는 하드웨어나 소프트웨어적인 문제로 설치된 메모리 주소를 처리하지 못하여 생기는 메모리 용량 문제를 설명한다. 메모리 컨트롤러, CPU 아키텍처 등의 한계로 인해 하드웨어가 관리 가능한 주소가 한정적이거나 운영체제, 응용 프로그램 등 소프트웨어에서 사용할 수 있는 주소가 제한되어 그 주소의 범위를 넘어가는 메모리를 쓸 수 없기 때문에 생긴다.

현실적인 경우에 비유하자면 서울시의 전화번호 체계가 02-xxxx-xxxx이기 때문에 8천만 회선을 초과하여(02-2000-0000부터 02-9999-9999까지) 부여하는 게 불가능한 것과 같은 이치이다. 서울시 전화국 교환기에 전화를 8천만대 이상 달아봤자 8천만대에만 전화번호를 부여할 수 있으므로 나머지는 무용지물이 된다.

후술할 문단을 제외하면 하드웨어적으로 사용 불가능한 경우는 메모리 컨트롤러에서 제한이 걸리는 경우가 대부분이다. 메모리 컨트롤러가 CPU에 통합되기 전에는 메인보드 칩셋에 있어서 메인보드 칩셋 종류에 따라서 제한이 걸리지만 통합된 후에는 CPU에 의해서 걸린다. 2016/08/30 인텔 기준 Xeon E7-8890 v4의 3072GB나 Core™ i7-6950X Processor Extreme Edition (25M Cache, up to 3.50 GHz) Core i7-6950X의 128GB를 최대 메모리로 보면 된다. 이런 문제는 메모리 가격의 하락→대용량의 메모리가 일반에 보급→더 큰 메모리를 제어하는 새로운 메모리 컨트롤러 내장의 수순으로 점진적으로 개선이 되는 부분이니 사용자 입장에선 대개 신경쓰지 않아도 되는 부분.

2 하드웨어 설계 상 생기는 문제

2.1 64KB 문제

과거 8비트나 일부 16비트 CPU 시스템의 경우 레지스터의 주소지정이 64 KB 로 제한되어 있었다. 예를 들어 인텔 8085/6502 등 대부분의 8비트 CPU와 DEC PDP-11 등 일부 16비트 미니컴퓨터는 주소지정이나 어드레스선이 16 비트 밖에 안되어 메모리를 최대 64KB 까지만 사용할 수 있었다. PDP-11 은 메모리관리 확장을 사용해서 물리적으로 256K~4M 까지 늘릴 수는 있었다. Apple-II나 일부 CP/M 시스템은 RAM 뱅크스위칭 등 별도 하드웨어의 도움을 받아 RAM 을 64 KB 보다 더 확장하는 것도 가능하긴 했으나 아래에 설명된 EMS 와 마찬가지로 응용 소프트웨어가 이를 인식하고 프로그램해야 하고 사용이 까다롭고 (프로그램용이 아닌) 데이터용으로만 사용가능한 등 제약이 심했다.

2.2 640KB 문제

• 해당 OS: MS-DOS 및 그 호환 OS

일명 기본 메모리 문제라고 하며 아마도 MS-DOS 시기를 거친 올드 컴덕들에게는 가장 유명한 메모리 문제이자 가장 많은 사람들을 엿먹인 문제이기도 하다. 나무위키에서 기본 메모리 문제로 검색하면 본 항목으로 리다이렉션된다.

MS-DOS의 기본 메모리(Conventional Memory)와 그에 관련된 주소 체계가 640KB로 제한되어 있어서 발생하는 문제이다. IBM PC 및 IBM PC XT에서 이용된 인텔 8088 CPU에서는 내부적으로 주소에 20비트를 이용하였으므로 주소 지정을 2²⁰=1MB까지만 할 수 있었다. 이에 맞춰 MS-DOS가 사용자 영역으로 640KB, 하드웨어 영역인 UMB(Upper Memory Block)를 384KB를 할당하였기에 이런 문제가 발생한다. 물론 IBM PC AT에서 채용된 80286 CPU는 주소를 최대 16MB(24비트)까지 이용할 수 있었고 80386 이후의 32비트 CPU에서는 4GB(32비트)까지 늘어났지만 MS-DOS에서는 그런 거 상관없이 CPU를 뭘 쓰든지 여전히 640KB만 이용할 수 있었다. 후술할 4GB 문제에서 32비트 운영체제에서는 램 8GB, 16GB를 달아도 4GB밖에 인식이 안 되고 그 중 몇백메가를 못 쓰는 것처럼(램 디스크를 써서 이용하는 방법 제외)장착된 램이 16MB라도 기본적으로 640KB를 넘는 메모리는 못 썼다. 왜 하드웨어가 발전했음에도 불구하고 이렇느냐 하면 MS-DOS는 기본적으로 x86의 실제 모드(Real mode)에서 동작하기 때문이다. x86 CPU의 실제 모드는 하위 호환성을 위해서 8086과 동일하게 동작하는 모드로 8086과 마찬가지로 20비트 주소 지정을 하므로 메모리는 1MB까지만 액세스가 가능하다. 1MB보다 상위의 메모리 영역에 접근하기 위해서는 보호 모드(Protected mode)로 동작해야 하는데 MS-DOS에서는 보호 모드를 지원하지 않았다.

실제 모드에서 Himem.sys와 EMM386/QEMM386등의 메모리 관리자를 통해 640KB보다 상위에 있는 메모리를 사용할 수는 있었으나, CPU에서 실행되는 코드처럼 프로그램의 중요한 부분은 640KB 영역에 두고 용량 많이 먹는 데이터 쪽을 EMS/XMS 영역으로 넘긴다는 개념이었다. 원래 EMS(Expanded Memory Specification/중첩확장메모리)는 IBM PC AT가 등장한 1984년에 대용량의 메모리를 필요로 하는 기업 사용자를 위해 만들어진 규격인데, 당시에는 메모리 집적도가 낮았으므로 커다란 확장카드에 메모리를 다닥다닥 붙여서 ISA 슬롯에 장착해서 쓰는 물건이었다. 이렇게 생겼다. 일반적으로 게임할 때 사용했던 EMM386은 이것을 XMS(Extended Memory Specification/연속확장메모리) 환경에서 에뮬레이션하여 EMS용으로 만든 소프트웨어를 구동하는 것이다.

기본 메모리에 이것저것을 올리다 보면 어쩔 수 없이 기본 메모리가 점점 소모되는데, 이런 상태에서 기본 메모리를 많이 소모하는 프로그램을 돌리려 하면 메모리가 부족하다는 메시지를 뱉으면서 실패하게 된다. 따라서 아무리 장착된 메모리에 여유가 있더라도 결국 원활한 프로그램 실행을 위해서는 이 하위 640KB 영역을 확보하기 위해 사활을 걸어야 했다. MS-DOS 후반기인 90년대 중반 무렵에 나온 게임은 기본 메모리를 특히 왕창 처먹기 때문에 실행하기 전에 570~610KB의 메모리를 확보해 두어야 했을 정도인데 여기에는 피나는 노력이 수반되었다.

예를 들면 마우스, CD-ROM 드라이버나 백신 등 백그라운드에서 실행되는 메모리 상주 프로그램 역시 상시 실행되는 코드이므로 기본 메모리에 올라가 있어야 한다. 그나마 드라이버는 config.sys에서 DEVICEHIGH 명령어를 통해 하드웨어를 위해 예약된 공간인 UMB로 올릴 수 있었지만, 실행 파일로 제공되는 메모리 상주 응용프로그램은 이마저도 불가능했다. 이런 것이 하나에 많으면 30~150KB 정도 먹기 때문에 메모리 상주 프로그램을 최대한 줄여서 기본 메모리를 확보해 줘야 했다. CD-ROM 드라이버 같은 드라이버도 사용하지 않을 때는 제거하는 등 필사적인 노력을 했지만 다행히 도스 6.0 이후에는 DEVICEHIGH나 LOADHIGH 또는 INSTALLHIGH 명령어를 이용해 UMB에 올리는 것이 가능해졌다. 당대에 보편적으로 쓰였던 커맨드 셸인 Mdir은 이런 상황을 반영하여 다른 파일 실행 시 자신을 종료하여 메모리를 반환받은 후 파일을 실행하고 실행 파일을 종료하면 다시 복귀하는 배치 파일을 만드는 기능이 있었을 정도.

이런 사용자들의 피나는 투쟁(...)을 지원하기 위해 상주 프로그램들을 XMS/UMB로 넘겨서 610KB 이상으로 만들어주는 QEMM386이라는 메모리 관리 툴이 선풍적인 인기를 끌었으나 어스토니시아 스토리, 신검의 전설 2 같은 몇몇 게임과의 충돌 문제가 있었으며, 삼성 등의 메이커 PC는 기본 세팅에서 이미 UMB의 일부 영역을 사용 중인 경우가 있었다. 결국 MS도 MS-DOS 6.0부터 QEMM386만큼은 못하지만 자체적으로 640KB 영역을 튜닝해 주는 Memmaker.exe를 지원하기에 이른다. 하지만 6.0은 멀티 부팅이 가능했지만 Memmaker가 멀티 부팅을 인식하지 못한다는 문제가 있었고, 6.22에서 해당 문제가 수정되었다.

기본 메모리를 어떻게 확보한 다음 UMB 영역과 XMS 영역을 사용한다 하더라도 문제가 또 있었는데 프로그램마다 요구하는 메모리 영역이 달랐던 것이다. 어떤 프로그램은 UMB를 많이 요구하기도 하고, 어떤 프로그램은 XMS를 많이 요구하기도 하고, EMS를 요구하기도 하는 식이어서 그야말로 제각각. 후기에는 대체로는 XMS를 많이 사용했지만 PC-9801에서 이식한 DOS/V 게임들은 예외적으로 9801에서 EMS를 많이 사용했던 여파로 대부분 EMS를 사용했다. 한편으로는 DOS4GW 모듈 등을 이용하여 자체적으로 메모리를 관리하며 이용하는 게임들도 있었다. 이 게임들은 XMS/UMB 영역이 없는 것을 전제로 구동되기 때문에 클린 부팅(DOS의 안전 모드)도 많이 필요했다. 여러모로 예측 부족과 땜빵 확장(...)으로 인한 규격의 난립으로 사용자만 고생했던 시대였다.

상황이 이 모양이다 보니 그때 그때마다 메모리 설정을 바꾸고 리부팅을 해야 하는 귀찮음을 감수해야 하는 경우도 드물지 않았다. 용도에 따라서 부팅 디스켓을 따로 만들어서 그나마 귀찮음을 줄일 수 있었다. CD롬 드라이버 유무, 마우스 유무 등에 따라 부팅 디스켓을 따로 준비해 두고 각 게임이 원하는 세팅으로 나눠두는 것. 당시에는 게임에 따라 정확히 세팅을 하는 것이 쾌적한 게임을 위한 최소한의 준비였다. 심하면 config.sys의 files와 buffer의 설정도 따지는 게임도 있었는데, 해당 게임에 꼭 맞는 수치라기 보다는 복잡한 메모리 설정 방법 대신 게임이 돌아갈 수 있게만 시동 파일 설정을 해주는 경우에 더 가까웠다. 하지만 부팅 디스켓을 쓰면 문제가 하나 있는데, OS를 플로피 디스크에 저장하기 때문에 뭔가 할 때마다 플로피디스크를 벅벅 소리내며 긁어 댄다는 점이다. MS-DOS 6.0부터는 자체에서 멀티부팅을 지원하면서 Config.sys와 Autoexec.bat에 각각의 설정을 추가해 원하는 설정으로 부팅할 수 있게 되었다.

근데 이렇게 고생을 해도, 결국 게임 하다가 다른 거 하려면 심한 경우 컴퓨터를 재부팅해야 한다는 건 변하지 않는다.(…) 그나마 EMM386 등의 메모리 관리자를 안 올렸거나 EMS를 아예 꺼 버린 경우를 제외하면 설정만 잘 해 놓으면 보통 재부팅까지는 가지 않을 수 있었다. MS-DOS가 단순한 OS라 하드 디스크로 부팅하는 경우엔 금방 재부팅이 가능하긴 했지만 귀찮기 그지 없는 상황인 것은 사실이다. MS-DOS 6.0 이후에는 기본 메모리를 너무나 열심히 확보한 나머지(...) 프로그램이 안 돌아가는 웃픈 상황도 가끔 발생했는데 이 경우는 LOADFIX를 이용해 기본 메모리의 첫 64KB 영역에 올라가지 못하도록 설정해야 했다.

이렇게 기본 메모리를 확보하고 관리하는 능력은 1990년대 중반까지 컴퓨터 초보자와 중급자를 가르는 기준이었으며 각종 PC 잡지의 단골 기사거리였다. 서점에는 10여종 이상 관련 서적이 나오기도 했다. 그리고 집에서 게임이 안 돌아간다고 학교 친구에게 메모리 잡아 달라고 부탁하는 경우도 종종 있었다. 당시 동급생 같은 일본의 에로게를 즐기던 게이머들은 설명서를 보고 따라하다가 정신을 차리고 보니 메모리 관리의 고수가 되기도 했다.

이렇게 수많은 이들을 곶통에 빠트리던 640KB의 벽은 1995년 Windows 95가 나오면서 서서히 사라지게 된다. Windows 2.0부터 이미 보호 모드를 사용하고 있어 윈도에서는 기본 메모리 문제가 없었지만 3.1까지는 DOS 위에서 돌아가는 GUI 셸에 가까웠고 보급률이 낮아 DOS를 주로 사용하는 일반 사용자는 이를 체감하지 못했다. 게다가 Windows 3.1까지는 DOS 수준의 그래픽 속도를 제공하는 API도 없었기 때문에 게임이 거의 대부분 DOS용이기도 했다. 윈도우 95로 PC OS의 패러다임 자체가 이동하면서 일반 유저들도 기본 메모리를 신경쓰지 않아도 되는 시대가 열렸다. 그렇지만 윈도우 95는 여전히 DOS 7.0을 내장하고 있었으나 이는 어디까지나 '호환용'이라서 게임을 비롯한 도스용 프로그램이 제대로 돌아가지 않았다. 오작동은 흔하고 좀 까다롭다 싶은 프로그램은 그냥 <이 버전에서 사용할 수 있는 프로그램이 아닙니다>라는 메시지만 내고 튕겨버리는 일도 잦았다. 그래서 한동안 윈도우 95와 MS-DOS 6.22로 멀티부팅을 하면서 이 고통에서 헤어나지 못하는 사람들이 많았다. 그러다가 시간이 흐르면서 도스용 프로그램들도 본격적으로 윈도우로 옮겨가고, 이 모든 고통의 원인(?)이었던 게임 역시 신작이 윈도우용으로 줄줄이 나오면서 서서히 옛말이 되어 갔다. 당시의 몇몇 게임들(워크래프트 2, 커맨드 앤 컨커 레드얼럿 등)은 도스용/윈도우 95용 실행 파일을 모두 제공하기도 했다. 그 뒤로 시간이 흐르고 흘러서 에뮬레이터로 도스 게임을 하려 들지 않는 이상엔 전혀 신경 쓰지 않아도 되는 문제였으나, 시간이 흐르면서 DOSBox 같은 에뮬레이터는 메모리를 알아서 잡아주기 때문에 기본 메모리 확보를 위한 피나는 투쟁은 호랑이 담배먹던 시절의 무용담이 되었다. 이 고통을 이해한다면 그대는 아재... 하지만 그 시절 야겜 좀 해보려다가 어느새 메모리 관리의 달인이 되었듯이, command.com, config.sys, autobat.exe의 사용법이 몸에 배도록 강요당하면서 역시 자신들도 모르는 사이 프로그래밍 언어에 친숙해지게 되었다. 여기서 한 발 더 나가면 HEX 값을 직접 건드리는 에디터가 나오고, 더 나가면 베이직에서 시작되는 프로그래밍 언어 교육이 이어진다.

2.3 1MB의 벽과 A20 Line

이 부분은 하드웨어적 문제라기보단 8086과의 하위 호환성 때문에 생긴 구조이다. x86을 욕먹이는 지저분한 구조 중 하나라 문제 맞다 전술했듯 8086/8088은 20비트의 주소선을 사용하여 1MB까지의 메모리에 접근할 수 있었다. 8086 항목에도 나와 있지만 8086은 주소를 표시할 때 16비트 레지스터 2개를 사용하여 세그먼트(16비트):오프셋(16비트)의 형태로 표현한다. 그런데 주소를 16MB(24비트)까지 사용할 수 있는 80286이 나오면서, 이 세그먼트:오프셋 표기가 꼬이게 되어 하위 호환성에 문제가 생겼다. 그래서 기존 8086과의 호환성을 유지하기 위해서 주소 부분의 21번째 비트(0부터 카운트하므로)인 A20 라인을 기본적으로 비활성화하고 1MB보다 위의 메모리에 접근할 때 활성화하는 A20 Gate라는 구조를 집어넣었다. 이는 지금도 계속 이어져 오고 있으며, A20 Line을 활성화하지 않고 1MB를 넘어가면 실제와는 다른 엉뚱한 주소에 접근하는 것이 된다. 때문에 1MB 이상을 접근하고자 하는 OS는 반드시 A20 Line을 활성화해야 한다. 지금은 BIOS에서 자동으로 활성화시켜 주기도 한다. 인텔의 경우 네할렘부터는 A20 Line을 활성화하기 위한 물리적인 구조를 없애고 논리적인 명령으로만 처리하며, 하스웰부터는 A20 Line이 항상 활성화된 상태로 출시된다.

2.4 4GB 문제

• 해당 OS: 32비트 Windows NT를 비롯한 대부분의 32비트 OS. 설명은 주로 윈도 위주로 되어 있으나 다른 OS에서도 대동소이한 문제가 있다.

인텔은 32비트 CPU인 80386에서는 메모리 주소선으로 32비트를 이용하였고 이후의 32비트 인텔 CPU는 이 구조를 그대로 답습하였다. 메모리는 바이트 단위로 주소를 매기므로 2³²=4GB까지 주소를 부여할 수 있다는 말이 된다. 이는 전작인 80286의 16MB에 비하면 256배 증가한 것이다. 80386이 등장한 1986년 당시에는 80286의 16MB 공간도 대단히 크게 여겨지던 판이라 4GB는 거의 무한에 가까운 공간으로 인식되었고, 실제로도 아무런 문제 없이 상당히 긴 시간 동안 80386에서 성립된 메모리 구조가 그대로 이용되었다. 그러나 메모리를 낭비하고 남용하는 소프트웨어/프로세스들이 늘어나며기술의 발전이 거듭되며 21세기에 접어들어 4GB 주소도 부족해지는 날이 다가오고 말았다. 32비트 CPU와 운영체제는 기존과 호환성을 유지해야 하므로 근본적인 구조를 바꿀 수 없었고 이로 인해 32비트 체제가 사용되는 동안 4GB 제한은 계속되었다.

16비트 시대와 마찬가지로 주소의 일부는 하드웨어 영역으로 할당되어 있고, 나머지에서 다시 커널 공간이 빠지기 때문에 사용자가 실제로 쓸 수 있는 양은 더 작다. 하드웨어 영역으로 할당된 메모리 주소 중 일부는 다른 장치와 통신하기 위해서 예약된 메모리 영역이며, 이를 Memory-mapped I/O (MMIO)라고 한다. 여기에 더해 운영체제의 종류에 따라 시스템 영역에 할당되는 용량도 개개 컴퓨터마다 다르다. 따라서 딱 얼마만큼 쓸 수 있다고 잘라 말할 수는 없지만 실제로는 대략 2~3.75GB 정도 쓸 수 있다고 보면 된다. 이러한 근본적인 제약은 모바일 장치도 마찬가지라서, 많은 안드로이드 제조사들이 2GB 메모리 다음 PC처럼 4GB로 가지 않고 3GB로 간 이유 중 하나도 ARM 프로세서가 32비트에 머물러 있었기 때문에 4GB를 달아 봤자 전부 쓸 수 없기 때문이기도 했다.

이 문제를 해결하기 위해서 32비트 CPU가 상용화된 후 펜티엄 프로에서 PAE(Physical Address Extension/물리주소확장)이라는 개념이 도입되어서 최대 36비트 메모리 주소를 사용하여 64GB까지 사용할 수 있었다. 하지만 32비트 구조의 근본적인 문제는 이것으로 해결하지 못했기 때문에 64비트 아키텍처가 등장한 뒤에야 근본적인 문제가 해결되었다. 64비트 메모리 주소를 사용하면 최대 16EB까지 메모리를 사용할 수 있기 때문에 가까운 시일 내에 메모리 부족 문제는 일어나지 않겠지만, 16EB까지 금방 갈 수 없으리라고 판단했기 때문에 발전 과정에서 여러 종류의 하드웨어 및 소프트웨어적 제약 사항이 생겼다. 물론 4GB 문제처럼 하드웨어가 본질적으로 내재하고 있는 문제가 아니기 때문에 필요에 따라 제약은 풀려갈 것이며 사용자가 신경쓸 만한 문제는 아니다.

2.4.1 4GB 문제의 해결책

32비트 시대에도 4GB 문제를 예견하지 못하진 않아서 일찌감치 1996년에 펜티엄 프로에서 PAE(Physical Address Extension: 물리 주소 확장)라는 기술이 일종의 과도기적 대안으로 도입되었고, 이를 이용하면 주소에 36비트를 이용하여 총 64GB까지 이용할 수 있었다. 하지만 이것은 전체 메모리를 64GB까지 꽂아서 쓸 수 있다는 것이지 프로그램 내부에서 이용하는 가상 주소는 이전과 마찬가지로 32비트이므로 애플리케이션에서 할당할 수 있는 메모리 크기에는 변함이 없었다. 단, 여러 개의 물리 페이지를 할당해 놓고, 필요한 부분만 가상 주소에 매핑해서 사용하는 구조 특성 상 최대 2GB까지만 사용할 수 있다는 것은 아니었다. 그러나 한 번에 매핑해서 사용할 수 있는 크기는 2G로 제한되기 때문에 매핑된 페이지를 교체하려면 작업이 번거로웠다. 여기까지 고려하고 만든다면 2G의 한계를 극복하고 사용할 수 있었지만, 많은 수의 응용 프로그램들이 이를 고려하지 않고 만들어졌던 데다가 결정적으로 64비트가 도입되면서 더 이상 이런 복잡한 체계를 붙들고 있을 필요가 없어졌다.

PAE가 아니더라도 32비트 시스템에서 4GB 공간을 넘어서 사용하는 또 다른 방법은 페이지 크기를 4MB로 하는 것이다. 이 방법은 PDE에 물리 주소 4비트를 추가로 지정하여 PAE처럼 물리 메모리를 64GB까지 사용할 수 있었다 (단, 하드웨어가 지원한다면). 하지만 관리가 불편해서인지 현재는 거의 사장된 거나 다름없는 기법이다. 현재 대부분의 32비트 OS들은 4KB 페이지를 사용하고 있다.

결국 근본적인 해결책은 64비트 도입으로 물리적인 주소 자체를 늘려버리는 것으로, CPU 아키텍처와 OS를 전부 64비트로 갈아치워버리면 저런 문제로 골치를 앓을 일 자체가 없다. 4GB 문제가 점차 현실적으로 다가옴에 따라 PowerPC나 MIPS 같은 다른 아키텍처에서는 일찌감치 64비트로의 이전을 실시하고 있었으나 x86은 호환성의 문제로 이전이 늦어졌다가 AMD의 AMD x86-64 아키텍처가 나오면서 64비트 시대가 열렸다. 인텔 역시 64비트 아키텍처인 IA64를 일찌감치 만들어뒀지만 이쪽은 기존의 x86 호환성이 망했어요였다. AMD x86-64 아키텍처에서는 메모리 주소를 최대 64비트까지 지정할 수 있도록 했지만, 64비트 주소로 표현 가능한 16EiB(18,446,744,073,709,551,615 바이트) 메모리를 단시일 내에는 사용할 수 없다고 판단했기 때문에 최초에는 40비트까지만 사용할 수 있게 했다가 2000년대 후반에 48비트로 늘렸다. 이런 제약을 둔 이유는 페이징 때문으로, 주소 지정을 하는 비트 수 만큼 필요한 페이지 테이블의 용량이 함께 늘어나기 때문이다. 이론적으로 페이지 테이블의 구조 상 최대 52비트까지 확장이 가능하며 이 때는 메모리를 최대 4PB/4096TB까지 사용할 수 있지만, 48비트 주소만 사용해도 메모리를 최대 256TB까지 사용할 수 있다. 아직까지 CPU 하나 당 최대 지원 메모리가 수백GB-2TB 정도이기 때문에 당분간은 충분할 듯 하다. 그러고는 조금만 미래로 가보면 램이 테라바이트 단위가 되고 지금 우리가 512메가바이트 램 보듯 보겠지 AMD64 아키텍처는 이 주소 공간을 절반으로 나누어서 아래쪽 절반은 사용자 영역, 위쪽 절반은 커널 및 하드웨어 영역으로 사용한다. 그래서 64비트 리눅스의 경우 사용자 공간으로 아래쪽 절반인 최대 8EB까지만 쓸 수 있다.

어쨌거나 4GB를 넘는 메모리를 사용하려면 하드웨어와 운영체제가 모두 64비트를 지원해야 한다. 컴퓨터 부품은 싫어도 CPU와 아키텍처를 맞춰야 하기에 하드웨어 쪽은 일찌감치 64비트로 갈아탔다. AMD는 2003년(애슬론 64/옵테론), 인텔은 2004년(펜티엄4 프레스캇 - 초기 모델은 제외)부터 64비트 지원 프로세서가 나오기 시작했다. 사실 소프트웨어 쪽이 대응이 늦어 이런 장벽이 만들어졌다. 특히 클라이언트용 윈도우는 2010년대 초반까지만 해도 32비트가 여전히 많이 쓰였다.

MS 윈도우의 경우 클라이언트 버전은 x86-64의 등장에 발맞추어 윈도 XP 64비트 에디션을 내놓았지만 망했어요가 되었고 윈도우 비스타부터 아예 64비트 버전을 동봉해 놓았으나, DSP 버전은 비트별로 나누어져 있다. 응용 프로그램의 메모리 요구량은 세월이 갈수록 높아지기만 하므로 32비트 OS는 몇 년 내로 자취를 감추게 될 것이다. 실제로 서버용 Windows의 경우 Server 2008 이후 32비트 버전을 출시하지 않고 있다. Red Hat의 RHEL도 Version 7부터는 64비트 버전만 나온다 근데 아무래도 윈도우 10까지 32비트가 있는 걸로 보아 아주 사라지는 것은 아직 좀 더 있어야 할 것 같다. 뭐 어차피 2038년이 되면 싫어도 없어질 거지만

CPU가 64비트 아키텍처라고 하더라도 칩셋 등 다른 하드웨어에 의해서 제한이 걸리기도 한다. 예를 들어 인텔 945 및 965 칩셋 시리즈의 경우 칩셋이 4GB의 메모리 주소만 처리 가능하기에 64비트라고 하더라도 4GB의 메모리를 모두 사용하지는 못한다. 물론 이 하드웨어가 나왔을 당시의 스펙에 맞추어서 세팅이 된 것이기 때문에 이런 경우는 해당 하드웨어가 현역일 당시에는 문제가 되지 않았던 것이 대부분. 이 외에도 32비트 시스템과 호환성을 위해서 하드웨어 영역의 경우는 지금도 4GB 아래에 위치하는 경우가 대부분이다. 물론 OS가 똑똑하다면 하드웨어 용으로 예약된 메모리 주소를 우회해서 실제 장착된 RAM에 매핑해 준다.

2.5 16EB 문제

• 해당 OS: 64비트 Windows를 비롯한 대부분의 64비트 OS

문제라고 하기엔 머쓱한 것이 당장에 문제가 되고 있는 문제가 아니며 16EB라는 용량은 GB 단위의 메모리가 보편적인 현재로서는 이론적으로만 존재할 정도로 멀리 있기 때문이다. 과거와 같은 개발 속도(1년 6개월 마다 2배)가 이어진다면 공돌이를 계속 갈아 넣는다면, 가정용 컴퓨터에는 2070년쯤 생길 문제라고 보면 된다. 일단은 이론상의 문제일 뿐이지만 결국 메모리 주소 공간이라는 근본적인 문제가 해결되지 않는 한 언젠간 다가올 수밖에 없는 문제이다. 4GB 문제도 20년 넘게 '이론적인' 문제였지만 지금은 현실적인 문제다.

하지만 이건 무어의 법칙이 계속 유효할 때의 이야기고, 2016년 현재 많은 컴퓨터 부품 설계에 한계가 오고 있는 시점에서 무어의 법칙은 공식적으로 깨졌으므로 모르는 일이다. 어디서 외계인을 더 고문해 신기술을 뽑아낸다면 잠시 주춤한 무어의 법칙을 앞지르는 수준의 성능을 가진 컴퓨터가 나올지 모르나, 그렇지 못하면 무어의 법칙은 깨질 운명이고, 2016년 2월 공식적으로 깨졌다.

3 소프트웨어상의 제한으로 인해 생기는 문제

3.1 윈도 9x의 512MB 문제

• 해당 OS: Windows 95, Windows 98, Windows Me

Windows 9x 시리즈가 공통적으로 가지고 있었던 문제. Windows 95, Windows 98, Windows Me는 32비트 OS임에도 512MB 이상의 메모리를 쓸 수 없게 되어 있으며, 이를 초과하는 메모리를 장착했을 경우 메모리 부족 이라는 오류를 내뱉는다. 뭣?

이 문제에 대처를 위해서는 시스템 파일 설정을 손대서 OS가 인식하는 메모리를 512MB로 제한해야만 한다. 9x 시스템을 사용할 일이 있다면 아래 문서를 참고하자.

• 마이크로소프트가 제공하는 해결책
• 남는 메모리를 램디스크에 할당하는 방법

이 문제는 다른 메모리 문제와 달리 아키텍처와는 무관하며 일종의 OS 설계상의 한계점으로 일종의 버그에 가까운 문제. 위의 문서에도 나와있지만 윈도 9x의 32비트 보호모드 캐시(Vcache)의 크기는 메모리의 크기에 따라서 자동으로 최대 캐시 크기와 메모리 주소를 설정하는데, 메모리가 512MB가 넘어가면 최대 캐시 크기가 지나치게 커져서 가상 메모리 주소가 전부 소진되어버려서 생기는 현상이라고 한다. OS 구조 자체가 전혀 다른 Windows NT 계열에는 이런 문제가 없다.

어차피 윈도 9x가 현역이던 시절엔 램값이 컴퓨터 부품 중 제일 비쌌기 때문에 이런 설계라고 해도 512MB를 초과하는 메모리를 장착할 사람이 없어 전혀 문제가 없었고, 128MB는 커녕 64MB만 돼도 램 많다는 소리를 들을 수 있었다. 윈도 9x는 가정용이다. 서버나 워크스테이션 같은 전문 영역에서 윈도를 쓸 경우에는 NT를 사용했고 NT는 저런 문제가 없다. 윈도우 Me가 발표되고 2001년도쯤 가서야 128MB 탑재 컴퓨터가 보편화되기 시작했다. 이 무렵부터 일부 파워유저가 512MB나 그 이상의 메모리를 장착하기 시작했지만 그 정도의 골수 파워유저들은 저 문제를 이미 인지하고 있었고 안정성 문제도 있어 NT 커널인 윈도우 2000으로 넘어가는 게 일반적이었기 때문에 역시 문제가 되지 않았다. 512MB 이상 메모리가 대중화됐을 때는 약 2003년도 이후로 이미 대세가 Windows XP로 넘어간 후였으므로 결과적으로 이 512MB 문제는 거의 문제가 되지 않은 이슈이며 한참 지나 램 업체간의 치킨 게임이 벌어지고 나서야 일반에게 인지된 문제였다.

현재는 9x가 시장 수명이 다한지 오래되었으므로 별 의미는 없는 문제이지만 고전게임 구동을 위해서 VMWare, VirtualBox 같은 가상 머신에 9x를 올려 사용하는 경우가 있으므로 가상 머신 설정을 할 때 이 점을 미리 염두에 두는 것이 좋다.

3.2 32비트 윈도에서의 PAE 제한

• 해당 OS: 32비트 Windows NT 계열 중 일부 서버 버전을 제외한 대부분의 버전.

최초의 32비트 윈도인 윈도 NT 3.1은 펜티엄 프로보다 한참 먼저인 1993년에 나왔고 당연히 32비트의 한계를 벗어나기 위해 도입된 PAE를 지원하지 않았다. PAE가 나온 이후의 버전에서도 서버용 중에서도 고급 버전을 제외하고는 4GB를 넘겨서 사용할 수 있는 32비트 버전은 없다. CPU에서는 기능을 제공하지만 OS 레벨에서 지원하지 않는 셈. 참고 본래 윈도우 XP에서는 서비스팩 1까지는 이 기능을 활성화 시킬 수 있는 방법이 있었으나, 타사에서 만든 드라이버들이 불안정해지는 문제로 이후 버전에서는 막아버렸다고 한다. 아래에 나오는 Large Address Aware(LAA)와 비슷한 이유 때문이다.

그나마 일반 사용자용 윈도우에서도 제한적인 PAE 지원 덕분에 낭비되는 메모리를 램디스크로 활용할 수는 있으며, 프로세스의 메모리 영역 보호에도 PAE의 기능을 적용하고 있다. 하지만 4GB 이상 영역을 램디스크에서 끌어다 쓰는 것도 문제가 있어서, 다 끌어다 쓰면 블루스크린이나 프리징 등 문제가 생기는 경우가 많아서 일정 용량은 남기고 안 쓰는 설정이 되어 있는 경우가 대부분이다. 보통 최소 8MB 정도는 남겨 놓으며, 프로그램에 따라 설정 방법 및 기본값이 조금씩 다르다.

윈도 XP 64비트 버전은 완성도가 영 좋지 못했고 이어 나온 윈도 비스타도 다양한 문제점으로 사용자들의 호응을 얻지 못했기 때문에 4GB 이상의 메모리를 장착한 컴퓨터가 어느 정도 일반 사용자의 가시권 안에 들어온 이후에도 4GB 문제는 사용자들에게 현실적인 문제점이었고, 그나마 해결책이라고 할 수 있는 PAE도 MS의 정책으로 막혀버렸기 때문에 제한에 불만을 품은 사람들이 관련 시스템 파일만 서버의 그것으로 바꾸는 식으로 클라이언트용 윈도우에서도 64GB PAE를 쓸 수 있게 하는 개조가 여럿 나왔다.

예를 들면 이런 거. 물론 저런 임의 개조로 인한 모든 결과(어떠한 문제가 발생하든 간에!)는 자기 책임이므로 주의할 것. 윈도 7이 시장에서 대호평을 받고 사용자들이 대거 64비트 윈도로 옮겨탄 이후에는 큰 의미가 없어졌다.

3.3 32비트 윈도에서의 2GB 할당 제한

• 해당 OS: Windows XP를 포함한 32비트 Windows NT 계열 OS

NT 커널을 쓰는 32비트 윈도에서 총 메모리를 4GB까지만 인식할 수 있다는 점은 전술했지만, 32비트 윈도에는 한 프로세스 당 총 2GB까지만 할당할 수 있게 제한이 되어 있는 문제도 있다. 4GB를 장착하고 있더라도 실제 한 프로그램이 독점적으로 쓸 수 있는 메모리는 2GB로 제한이 걸리는 것. 이 제약은 윈도 NT를 설계했을 당시부터 있던 구조상의 한계라서 64비트 윈도에서 32비트 애플리케이션을 동작할 때도 똑같이 적용된다. 당연한 이야기지만 64비트 애플리케이션을 동작할 때는 이런 제약이 없다. 이 때문에 하드웨어-OS-애플리케이션이 모두 64비트여야 진짜 64비트 기능을 이용할 수 있다는 이야기가 나오는 것.

설정을 건드려서 커널 영역의 크기를 변경하면 32비트 윈도 기준 3GB까지, 64비트 윈도 기준 4GB까지 사용이 가능하기는 하며 이를 Large Address Aware (LAA)라고 한다. 이론상 3GB까지 쓸 수 있지만 기본적으로 사용 가능한 것이 아니라 1차적으로 윈도 설정을 건드려 LAA를 활성화를 시켜줘야 하며 LAA가 활성화가 되어있더라도 애플리케이션이 LAA를 지원해야 하는 문제가 있다. LAA 지원이 기본적으로 비활성화된 이유 중에는 포인터 처리 문제가 있다. 32비트 포인터의 최상위 비트가 1이면 하드웨어 및 커널 주소라서 프로그램에서는 사용할 수 없기 때문에, 대부분 프로그램에서는 포인터 연산 결과 최상위 비트가 1이 되면 오류가 있는 것으로 취급했고, 일부 프로그램에서는 이 값을 특수한 용도로 사용했다. 그런데 LAA 지원 환경에서는 실제 할당된 메모리 주소가 최상위 비트 1이 될 수 있기 때문에 이 가정이 모두 깨진다. 64비트 윈도에서는 기본적으로 32비트 애플리케이션을 구동할 때 LAA가 활성화된 상태로 구동되므로 애플리케이션이 LAA를 지원하기만 하면 4GB를 다 끌어다 쓸 수가 있다. 커널 영역은 64비트 영역의 Higher Half로 이사 갔기 때문에 호환성 문제도 없다. 야 신난다

LAA에 대해서 더 알아 보려면 정리한 글을 읽어보자. 단, 구체적으로 LAA Flag를 강제로 고쳐주는 프로그램은 Large Address Aware.exe란 프로그램이 훨씬 편리하기 때문에 이쪽이 대세이다. 또한 치팅 방지 보호가 되어있는 게임의 경우 유저의 임의 해킹(실행 파일 변조)로 걸리는 수가 있으니 조심할 것. 싱글플레이만 있는데도 이게 문제가 되는 대표적인 사례가 베데스다 폴아웃 시리즈, 아무래도 스팀 DRM에 걸리는 것 같다. 그래서 전용 로더를 통해 우회하는 프로그램이 나왔다. 폴아웃3용, 뉴 베가스용

3.4 64비트 윈도의 메모리 제한

실은 64비트 윈도에도 역시 메모리 용량 제약이 있다. 윈도우 7 기준으로 홈 베이직/프리미엄은 8GB/16GB에 불과하며, Pro 이상 상위 에디션도 192GB이고, 그나마 서버 에디션들도 최고 2TB까지라 64bit 아키텍처나 하드웨어의 메모리 한계에 비해 한참 낮은 용량이다. 윈도우 10의 경우 홈 버전을 제외한 나머지 버전들은 2TB까지 지원하며, 홈 버전의 경우 128GB이다. 이건 64비트용 윈도우 XP 한계와 같다. 모든 윈도우 제품들의 물리적 메모리 인식 한계에 관한 표. 현재 DDR4 16GB 단품이 나온 상황에서 돈만 보태면 일반 소비자가 64GB 시스템을 구축할 수 있다. 메모리 한계 사태는 근시일 내에 다시 일어날 수도 있다. 심지어 X99 계열 보드 중 메모리 슬롯이 8개인 모델은 진짜로 128GB 시스템 구축이 가능하다! 설마 128GB 시스템 구축을 해놓고 OS는 홈 버전을 사진 않겠지

물론 이러한 제한은 기술적인 문제가 아닌 OS 운영의 편의, 자원 활용의 효율성 등의 문제 때문에 의도적으로 MS가 걸어둔 제한으로, 대용량의 메모리가 일반화되어 제한치에 가까워질 때마다 MS에서 그 제약을 풀어주는 조치를 취할 것이므로 서버급의 램을 처바를 돈지랄을 할 것이 아니라면 피부에 와닿을 만한 문제는 아니다. 어쨌거나 64비트 아키텍처가 가지는 물리적인 제약은 16EB이기 때문. 당장 윈도 10부터가 윈도 7에 비해 메모리 상한이 크게 늘어있는 것이 예시가 될 것이다.

3.5 VRAM 4GB 제한

• 해당 앱: Direct X 9 기반 게임

Direct X 9 기반 게임을 돌릴 경우, 그래픽 카드의 VRAM이 최대 4GB로 제한되는 문제가 있다. 당연히 Direct 10 이상을 쓴 게임에서는 생기지 않는 문제이며, VRAM이 4GB를 넘는 그래픽 카드가 나오면서 문제가 발견되었다. Direct X 9가 XP 이하 윈도용 라이브러리이기 때문에 RAM처럼 주소 할당이 32bit라서 생기는 문제인 듯하다. 라데온 HD 7000 시리즈, 지포스 GTX TITAN부터의 최상위급 카드를 쓴다면 주의해야 될 문제이다.