폰 노이만 병목 현상(Von Neumann Bottlenect)
우리는 살다보면
병목 현상(Bottleneck)이라는 말은 한번쯤 들어봤을 것이다.
폰 노이만 구조에도 이런 병목 현상이 발생한다.
 |
| 폰 노이만 구조 병목 현상 |
위에서 언급한 분류를 다시 한번 언급하겠다.
제어 장치, 산술장치 → CPU(중앙처리장치)
메모리 → RAM, Cache 등
그외의 디바이스(저장 장치 등) → HDD, SSD , USB Drive ,CD Drive 등
폰 노이만 구조에서는
메모리와
그외의 디바이스를
메모리라는 이름으로 하나로 묶었던 것을 기억할 것이다.
하지만 현재 컴퓨터 아키텍처는 이를 분리하였는데,
이는 CPU의 처리속도는 빠른것에 비해,
메모리에서 CPU까지 전달 속도가 느림에 따라
메모리(저장 장치등을 말함)에서 CPU까지 아직 데이터가 도달하지 않았는데,
CPU는 이미 그 전에 전달 받은 처리를 끝내 대기하는 상태
즉,
병목 현상이 나타남에 따라
자주 쓰는 데이터들을 메모리(Ram, Cache 등)에 올려놓는 것으로
이 구조를 개선한 것이 현재의 컴퓨터 구조이다.
하지만, 이것은 개선한 것에 불과하며,
여전히
병목 현상은 나타난다.
이렇게 분리함에 따라
SSD나 HDD와 같은 저장장치를 비휘발성 메모리,
RAM과 Cache를 휘발성 메모리라고 학문으로서 분류되어 있지만
사실 크게 중요하지는 않다.
중요한 사실은
CPU처리 속도가 너무 빠른 것에 비해,
다른 장치들에서 CPU까지의 전달 속도가 매우 느리다는 것만
기억하면 된다.
특히, 소프트웨어로서 이야기 되어지는 것은
SSD나 HDD와 같은
즉,
저장 장치의 전달 속도가 비교적 매우 느리다는 것을
기억하기 바란다.
RAM이 컴퓨터 시스템에서 필요한 이유
RAM이라고 불리우는 메모리가 필요한 이유가 여기서 드러난다.
새로운 처리가 필요할 때마다
HDD나 SSD와 같은 저장 장치에서
다시 불러온다는 것은 매우 적절한 방법은 아니다.
왜냐하면 위에서 언급한 병목 현상이 발생하기 때문이다.
따라서 자주 사용할 법한 것들을
미리 다른 곳 올려 놓을 필요가 있으며,
이에 대한 솔루션으로서
현재 사용하고 있는 RAM이 탄생하고
지금까지도 사용하고 있는 것 이다.
만약 RAM이라는 중간 매개체가 없다면
컴퓨터는 병목 현상에 의해
실제 CPU의 처리 속도는 빠르지만
실제로는 처리 속도가 느린 것 처럼 보이는 현상이 나타났을 것 이다.
따라서 현재 컴퓨터 시스템에서
RAM라는 중간 매개체가 다소 이 병목 현상을
해결해 줄 수 있기 때문에
매우 유용하다는 사실에는 의심의 여지가 없다.
또한 컴퓨터를 사용해본 사람이라면
소프트웨어 실행 시 컴퓨터의 냉각 펜이
빠르게 돌아가는 것과
소프트웨어 실행 속도가 느리다는 것을 느낀 적이 있을 것이다.
그 이유는 크게 두 가지로 볼 수 있다.
두 번째, 불러왔을 때 자주 사용할 법한 것들을
따라서 소프트웨어를 처음 실행 했을 때,
이와 같은 처리가 동시에 진행되기 때문에
CPU는 계속해서 열을 내뿜는 것이며,
냉각 펜이 빠르게 돌아가는 것이다.
그렇기 때문에
소프트 웨어의 바운더리를 구성하는
운영체제가 실행되었을 때
냉각 펜이 빠르게 돌아가는 것은 고장이 아닌
너무나도 자연스러운 현상이다.
폰 노이만 병목 현상에 대한 좀 더 자세한 설명
좀 더 이해를 돕기 위해 예를 들어 설명해보자.
|
| 폰 노이만 구조 병목 현상 |
잠깐 위와 같은 그림을 봤을 것이다.
여기서
분홍색 박스를 일반적으로 가장 빠르다고 언급되는
SSD로 치환하고
빨간색 박스는
CPU,
주황색 박스의
메모리는
RAM으로 예를 들어보자.
(물론
Cache 메모리라면 훨씬 더 빠를 것이라 생각된다.)
또한
보라색 타원을 CPU와 RAM간의 전송 속도,
하늘색 타원을 SSD와 CPU간의 전송 속도라 가정해보자.
우선 그 전에 현재 기준(2020년) CPU속도와 RAM의 속도,
그리고 SSD의 속도를 알아볼 필요가 있다.
먼저 CPU의 경우,
CPU의 속도는 일반적으로 기가 헤르츠(Giga Hertz) 단위이며,
"GHz"로 이야기 되어 진다.
이는 해당 CPU가 초당 수행 할 수 있는 클럭 주기를 가르키며,
1.8GHz인 CPU는 초당 1,800,000,000개의 클럭 사이클을
수행 할 수 있다
인텔 i7-9700k의 경우
기본 속도는 3.6GHz이며,
부스트의 경우 최대 4.9Ghz이다.
이번 예에서는 좀 더 명확한 차이를 보여주기 위해
최대 속도인 4.9Ghz를 기준으로 잡겠다.
다음으로 RAM 경우,
RAM의 Clock 속도는 일반적으로 메가 헤르츠(Mega Hertz) 단위이며
"Mhz"로 이야기 되어 진다.
이는 해당 RAM이 초당 메모리에 엑세스 할 수 있는 횟수를
가르키며, CPU의 측정 방법과 동일하다.
현재 DDR4의 Clock 속도는 2133Mhz 또는 2400Mhz,
전송 속도는 3200Mb/s의 전송 속도를 가지고 있다.
RAM이 저장장치와 CPU와 다르게
2가지 전송 속도를 가지고 있는 것을 보면
매개체 역할을 하고 있다는 것을 확실히 느낄 수 있을 것이다.
마지막으로 SSD 경우,
SSD의 속도는 일반적으로 메가 바이트(Mega Byte) 단위이며,
"Mb/s"로 이야기 되어 진다.
이는 해당 SSD가 초당 MB의 읽기/쓰기가 가능하다는 것을
가르키며, 읽기/쓰기 속도가 따로 분류된다.
2020년 기준 Samsung 860 Evo의 경우 550Mb/s의 읽기 속도를
520Mb/s 의 쓰기 속도를 가지고 있다.
다만 여기서 몇 가지 유의할 점이 있다.
첫째, SSD와 같은 저장 장치는 비휘발성 메모리이며,
DDR4와 같은 메모리(SDRAM)는 휘발성 메모리라는 점
둘째, 둘의 용도는 매우 다르며, 전송 방식 또한 다르기 때문에
단순히 전송 속도만 놓고 비교하기는 적절치 못하다는 점
위와 같은 이유로 사실 저장 장치와
RAM을 비교하는 것은 적절하지는 못 하다.
실제로 SSD를 RAM처럼 활용할 수는 있지만,
성능이 매우 떨어진다.
하지만, 단순 전송속도만 놓고 봐도
확연히 차이가 나기 때문에 병목 현상이 나타나는 사실을
추출함에 있어서는 큰 문제는 없다고 생각한다.
따라서
이러한 결론에 따라 좀 더 이해를 돕기 위해
현재(2020년) 기준으로 하드웨어를 비교해보자.
CPU(인텔 i7-9700k)의 경우 기본 속도는 3.6GHz이며,
부스트의 경우 최대 4.9Ghz이다.
2020년 기준 DDR4의 Clock 속도는 2133Mhz 또는 2400Mhz,
전송 속도는 3200Mb/s의 전송 속도를 가지고 있다.
2020년 기준 SSD(Samsung 860 Evo)의 경우 550MB/s의 읽기 속도를
520MB/s 의 쓰기 속도를 가지고 있다.
위의 추출한 사실로 현재의 컴퓨터 아키텍처를 다시 한번 살펴보자.
|
| 폰 노이만 구조 병목 현상 |
먼저,
보라색 타원을 살펴보자.
1GHz가 1,000Mhz라는 사실에 따라
DDR4의 속도를 Ghz로 환산 하면,
2.133GHz 또는 2.4GHz가 될 수 있다.
(대략 Cache Memory의 경우 RAM의 10~100배의 효율을 가진다고 한다. )
단순히 수치만 놓고 비교하자면,
CPU와 RAM의 속도의 차이는 비교적 엄청나게 큰 차이는
아니라고도 할 수 있다.
이런 사실에 따라
일단
SSD에서 데이터를 가져와 RAM에 올려놓기만 한다면,
우리의 컴퓨터는 병목 현상이라고 불릴 정도로는 느려지지는 않을 것이다.
다음으로 문제의
하늘색 타원을 살펴보자.
위에서 추출한 사실로서
DDR4의 전송 속도는 3200MB/s로
현재 제일 빠르다는 저장 장치 SSD라고 해봤자
대략 550MB/s의 전송 속도를 가지기 때문에
이론상 약 6배의 전송 속도의 차이를 보인다.
따라서 여기서 흔히 채감할 수 있는
폰 노이만 병목 현상이라는 것이
발생할 것이라는 것은 너무나 자명하다.
따라서 이런 병목 현상이 발생할 수 있음에 따라
실제 사용자에게 나타나는
소프트웨어 프로그램의 속도는 매우 불안정할 것이다.
소프트웨어 개발자에게 병목 현상이
무슨 의미를 가지는가
내가 컴퓨터 아키텍처를
왜 설명하려고 했는지에 대한 본론은
사실 지금 부터 이다.
따라서 왜 개발자,
그 중 소프트웨어 개발자에게 '왜 컴퓨터 아키텍처를 알 필요가 있는가?'
에 대한 고찰과 성찰을 오래전 부터 했었고,
그에 대한 나의 결과가 이
'병목 현상'에 있다는 결론을 내렸다.
왜냐면 병목 현상이 발생했기 때문에
빠른 처리속도를 가지는 CPU와
비교적 느린 전송속도를 가지는 저장장치(HDD,SSD)의
중간 매개체가 필요했으며,
이에 대한 솔루션으로써 현실의 RAM 등장했기 때문이다.
이를 증명하듯이 RAM이라고 불리우는 메모리는
클럭 속도와 전송 속도 이 2가지 속도를 가지고 있다.
이런 사실을 소프트웨어 개발자로서
당연히 인지하고 있어야 하며 중요하지만,
이 것을 중요하게 생각하는 개발자들은 많지는 않은듯 하다.
왜냐하면 이런 병목 현상이 나타남에 따라
과거의 소프트웨어 개발자들은 이런 RAM의
제한된 메모리 용량을 가지고 있기 때문에
메모리 관리에 더 신경써야 했기 때문이다.
물론 하드웨어가 발달함과 동시에
가비지 컬렉터에 대한 개발자들의 인식이
과거에 비해 좋아지고,
가비지 컬렉터도 또한 발달하면서
현재에 들어서는 메모리(RAM)관리에 대한
필요성은 크게 줄어들었지만 말이다.
예전에 출판된 책들을 보면
한정된 메모리로 최대한의 퍼포먼스를 내기 위해서
코드를 짧게 하는 방식으로
혹은 메모리를 효율적으로 사용하는 방식을 사용해
프로그래밍을 했던 것을 확인할 수 있다.
그렇다면 이제
위에 잠깐 봤던 폰 노이만 구조의 확장을 다시 한번 살펴보자.
 |
| 폰 노이만 구조의 확장 |
기억이 날지는 모르겠지만,
나는 전에 위와 같은 사진을 언급한 적이 있다.
앞서 언급한 이유는 지금을 위해
강조하기 위해서 이다.
전에 언급했다시피,
결국 소프트웨어 엔지니어로서의 영역은
보라색 박스 부분이다.
지금이야 과거에 비해
하드웨어가 비약적으로 상승해
메모리 관리의 중요성에 대해 언급이 줄어들었지만,
과거 하드웨어가 충분하지 않던 시절에서
메모리 관리는 필수 였다.
Fotran과 Cobol등을 비롯한 프로그래밍 언어는 거의
역사 속의 산물로 사라져가고 있는 현실에서
그렇기에 어쩌면 과거의 산물인대도 불구하고,
C언어라는 프로그래밍 언어가 살아남아 있고
많이 쓰여져 있다는 것이 과연 우연일까?
어쨋든 이에 대한 것은 후에 '언어'에 대해 이야기할 때
다시 언급하기로 하고 다시 본론으로 돌아가자.
아는 사람은 알겠지만,
C언어는 메모리 관리 뿐만 아니라
소프트웨어 최적화에 가장 적합한 언어로
평가 받아지고 있기 때문에,
최적화가 필요한 소프트웨어 분야는
대게 C언어로 프로그래밍 되어 있다고 해도 과언이 아니다.
이런 C언어의 특수성 때문에
앞으로도 C언어는 계속해서 살아남을 것이라고
생각하고 있다.
(Go와 같은 차세대 언어가 어떻게 될지에 따라 달렸겠지만)
따라서 우리는 소프트웨어 개발자로서
메모리 관리의 필요성을 인지할 필요가 있다.
왜냐하면, 분야에 따라
지금도 이런 메모리 관리가 필요한 분야가 많고,
4차 산업 혁명이 진행되고 있는 지금
그 핵심이 머신 러닝이 될것으로 예상되고 있는 지금
메모리 관리의 필요성이 더 줄어 들것인가
아니면 더 늘어날 것인가는 지금으로서는 알 수 없지만
필요성이 더 줄어 든다고 해도
완전히 없어지지는 않을 것이며,
이러한 사실은 개발자로서의 가치는
더욱 높게 평가 받을 것이다.
반대로 필요성이 늘어난다면,
당신은 시장이라는 거대한 파도에 같이
올라탈 수 있기 때문에,
최소한 당신의 가치는 떨어지지는 않을 것이다.
따라서 당신이 메모리 관리의 필요성에 대해
충분히 인지하고 있고,
더 앞서나가 메모리 관리 기법에 통달해 있다면,
혹은 통달해 있지 않더라도,
개발자로서의 향상심을 가지고 있는 사람이라면
그렇지 않더라도 그에 준하는 자세가 되어있다면
당신은 소프트웨어 개발자로서의
미래의 가치는 최소한 떨어지지는 않을 것이다.
메모리 누수(Memory Leak)에 대해
메모리 누수의 경우에는
학사적 지식을 배울 때 자주 언급되지 않는 내용이지만
(특히 Computer Engineering의 경우)
이에 대해 소프트웨어 개발자로서 인지하고 있어야 한다.
왜냐하면 위에서 언급했듯이
처리 장치인 CPU의 속도에 비해
저장 공간인 HDD나 SDD가 느리기 때문에
비교적 빠른 Memory에 미리 올려 놓게 된다.
하지만 문제는 이런 Memory는
HDD나 SDD에 비해 가격이 비싸기 때문에
용량이 그다지 높지 못하다.
그렇기 때문에 컴퓨터 시스템에서 Memory와
비 휘발성 Memory인 HDD나 SDD의 격차는 매우 크다.
현재 일반적으로 컴퓨터 사용되는 RAM의 경우
16Gbyte ~ 32Gbyte이며
비 휘발성 Memory인 HDD나 SDD는 1Tbyte인 것을 생각하면
32배~64배 까지 용량 차이가 난다고 볼 수 있다.
그렇기 때문에 RAM은 비교적 자원이 부족하며,
효율적으로 사용하기 위해서는
당연히 메모리를 할당하고 해제 하는 것이 필요하다.
문제는 컴퓨터에서 소프트웨어를 사용하는면서
정확히는 이런 메모리를 할당하고 해제하는 과정에서
여러가지 이유에 의해 메모리 누수(Memory Leak)가 발생한다.
여러가지 이유가 언급될 수 있으나
그 중에 매우 일반적이고, 개발자가 야기 할 수 있는 것은
코드에서 메모리를 할당 했지만 제대로 해제하지 않아
메모리 누수가 발생하는 경우이다.
일반적으로 가비지 컬렉션(Garbage Collection, CG) 없는
C 언어 계열의 언어에서 나타날 수 있다.
왜냐하면 가비지 컬렉션을 지원하지 않는 언어들은
직접 프로그래머가 코드를 통해
메모리를 할당하고 해제하기 때문이다.
그렇기 때문에 코드 상에 메모리를 할당하고
해제 하는 코드를 작성하지 않으면
계속해서 그 만큼 메모리 누수가 발생하기 때문에
결국 빠른 시간내에 메모리가 고갈되어
시스템이 멈추게 될 것이다.
가비지 컬렉션은 가비지 컬렉션이라는
내부 프로그램에 의해 자동적으로 메모리를 할당 및 해제 해주기 때문에
비교적 그러한 버그가 발생할 경우가 적다.
하지만 가비지 컬렉션이 메모리를 완벽하게
할당과 해제를 한다고 하기에는 힘들다.
가비지 컬렉션이
어느 시점에 어느 메모리를 해제하는지는 알 수 없으며
가비지 컬렉션을 작동시키기 위해 사용할 수 있는
한정된 메모리를 가비지 컬렉션 작동하기 위해
메모리를 할당해야만 한다.
따라서 메모리 누수는 가비지 컬렉션이
있건 없건 여부와 상관없이
현재 컴퓨팅 시스템을 이용하고 있다면 발생할 수 밖에 없다.
역으로 가비지 컬렉션을 사용하지 않는 언어의 경우
적절히 할당과 해제를 할 수 있다면
가비지 컬렉션을 가지고 있는 언어보다 뛰어난 퍼포먼스를 낼 수 있다.
나는 이 것이 C언어 계열이 과거부터 지금 까지
계속해서 쓰여지고 있는 이유라고 생각하고 있다.
이러한 이유로
Apple 사의 프로그래밍 언어인 object-c는
Object-c 2.0에서 일시적으로 사용한 적이 있으나
ARC(Automatic Reference Counting)을 사용하게 되면서
Mac OS X v10.8이 후 부터는 가비지 컬렉션을 사용하지 않는다.
따라서 만약 컴퓨터에 대해 2가지를 알 필요가 있다면
나는 폰 노이만 병목 현상과 메모리 누수 현상을 꼽을 것 이다.
왜냐하면 이 두 가지 현상은
컴퓨터가 소프트웨어를 이용하는 과정에서
생길 수 밖에 없는 현상이며,
컴퓨터 아키텍처의 한계에 의해 발생할 수 있는
두 가지를 포함한 여러가지 한계가
소프트 웨어가 영향을 주고 있기 때문에
알 수 없는 버그가 생길 때,
이러한 것들을 의심해볼 필요가 있기 때문이다.
마치며
지금까지 폰 노이만 병목 현상과
메모리 누수에 대한 이야기를 나누어 보았다.
사실 폰 노이만 병목 현상과 메모리 누수에 대해
학문적으로 들어가서 더 자세하게 이야기 할 수 도 있을 것이다.
하지만, 학문적으로 깊게 들어간다고 해서
시간적인 효용이 그렇게 높지는 않다.
왜냐하면 적어도 소프트웨어 개발자는
이론위에 현실의 시스템을 쌓는 것이 아니라
현실의 시스템에 이론을 쌓아야 하기 때문이다.
그렇기 때문에 컴퓨터 개론에서 가져가야 하는 핵심은
현 컴퓨터 아키텍처가 가지고 있는 문제점에 대한 이해와
그리고 언제든지 현실의 시스템에 적용할 수 있도록
자신만의 청사진, 즉 직감을 가지는 것이다.
그렇지 못하고 단순히 지식만 쌓는 것은
현실에서 솔루션을 제시해주기는 힘들 것 이다.
컴퓨터 시스템에 대한 직감을 얻는데에 도움이 되길 바란다.
가비지 컬렉션에 대해 :
