2025년 12월 19일·7분
폰 노이만과 소프트웨어를 가능하게 한 저장 프로그램 컴퓨터
저장 프로그램 개념(종종 존 폰 노이만과 연관됨)이 어떻게 재사용 가능한 소프트웨어와 범용 컴퓨터, 현대적 프로그래밍을 가능하게 했는지 알아봅니다.
저장 프로그램 개념(종종 존 폰 노이만과 연관됨)이 어떻게 재사용 가능한 소프트웨어와 범용 컴퓨터, 현대적 프로그래밍을 가능하게 했는지 알아봅니다.
현대 컴퓨팅의 핵심에는 간단한 질문이 있습니다: 한 대의 기계가 매번 재구성하지 않고 여러 다른 작업을 수행하게 한 원동력은 무엇인가? 초기 전자 컴퓨터들은 빠르게 계산할 수 있었지만 “작업을 바꾼다”는 것은 종종 기계를 물리적으로 바꾸는 것을 의미했습니다. 저장 프로그램 아이디어는 컴퓨터를 진정으로 프로그래밍 가능하게 만든 전환점입니다.
저장 프로그램 컴퓨터는 작업을 수행하는 *명령(프로그램)*을 프로그램이 다루는 데이터와 같은 종류의 내부 메모리에 보관합니다. 하드웨어를 재배선하거나 패널을 수동으로 재구성하는 대신, 새로운 명령 집합을 메모리에 로드하고 다른 작업을 실행할 수 있습니다.
지금은 당연하게 들리지만, 이는 깊은 변화였습니다:
이것은 단순한 역사적 호기심이 아닙니다. 저장 프로그램 개념은 왜 “소프트웨어”가 하드웨어와 별개의 존재로 존재하는지, 그리고 왜 장치를 업데이트하면 칩을 바꾸지 않고도 새로운 기능을 활성화할 수 있는지를 설명합니다.
다음 섹션에서는 초기 컴퓨터들이 직면했던 문제, 저장 프로그램 접근법이 무엇을 바꿨는지, 이 아이디어를 명확히 한 사람들과 문서들(유명한 EDVAC 보고서 포함), 그리고 “폰 노이만 아키텍처”라는 용어가 어떻게 널리 쓰이는 설계의 대명사가 되었는지를 살펴보겠습니다.
존 폰 노이만의 이름이 저장 프로그램 컴퓨팅과 강하게 연관되어 있지만, 공로는 더 넓은 팀과 시대에 걸쳐 나뉘어 있습니다. 많은 연구자들이 최초의 실용 전자 컴퓨터를 만드는 과정에서 유사한 아이디어에 수렴하고 있었습니다. 이 글은 그 맥락을 유지합니다—팀의 노력이 아이디어가 빠르게 확산해 표준 모델이 된 이유를 설명하는 데 도움이 됩니다.
저장 프로그램 아이디어 이전에는 많은 초기 컴퓨터가 우리가 지금 말하는 방식으로 ‘소프트웨어를 실행’하지 않았습니다. 이들은 인상적인 속도로 계산했지만, 무엇을 할지 지시하는 것은 종종 기계를 물리적으로 바꾸는 것을 의미했습니다.
일반적인 접근법은 플러그보드, 패치 케이블, 스위치 패널을 사용하는 것이었습니다. 운영자는 소켓 사이에 선을 연결하고, 스위치 행을 설정하며, 때로는 신호가 올바른 순서로 도착하도록 타이밍 장치를 조정했습니다. “프로그램”은 파일이 아니라 임시 배선도였습니다.
이 방식은 작동했지만 숨겨진 비용이 있었습니다: 새로운 작업마다 작은 엔지니어링 프로젝트가 필요했습니다. 연산 순서를 바꾸려면 수십에서 수백 개의 연결을 옮겨야 했고, 잘못 꽂은 하나의 케이블은 논리가 하드웨어 연결에 흩어져 있기 때문에 찾기 어려운 미묘한 오류를 만들 수 있었습니다.
재구성에는 수시간 또는 수일이 걸릴 수 있었고, 특히 기계를 안전하게 전원 차단한 뒤 다시 배선하고 테스트해야 할 경우 더 그랬습니다. 결과적으로 유연성이 제한되었고, 이러한 기계들은 작업 전환이 너무 파괴적이어서 종종 오랜 시간 동안 하나의 계산에 예약되었습니다.
어떤 기계가 포병 사격표를 계산하도록 설정되어 있다고 상상해 보세요—고정된 수식을 반복하는 긴 계산입니다. 같은 기계로 인구조사의 통계 집계 같은 다른 문제를 풀고자 한다면, 단순히 “프로그램을 편집하고 다시 실행”하는 것이 아니라 연산 순서, 중간 저장 단계, 조건 검사 등이 모두 다를 수 있어 플러그보드 설계를 전면 수정하고 재검증해야 했습니다.
이것이 저장 프로그램 컴퓨터가 벗어나고자 한 세계입니다.
저장 프로그램 컴퓨터는 명령(프로그램)이 프로그램이 사용하는 데이터와 같은 작업 메모리에 존재하는 기계입니다. 다시 말해 컴퓨터는 “무엇을 할지”와 “무엇을 다룰지”를 별도로 취급하지 않습니다—둘 다 메모리의 비트 패턴으로 저장됩니다.
초기 컴퓨터 개척자들이 말한 메모리는 컴퓨터의 빠르고 직접 사용 가능한 내부 저장소를 의미했습니다—오늘날 우리가 RAM과 가장 밀접하게 연관시키는 것과 비슷합니다. 프로세서가 실행 중에 빠르게 읽고 쓸 수 있는 장소입니다.
이는 하드 드라이브나 SSD 같은 장기 저장장치와 다릅니다. 드라이브는 전원이 꺼져도 파일을 보관하기에 좋지만, 프로세서가 다음 명령을 가져오고 중간 결과를 업데이트하는 즉각적인 스크래치패드 역할은 할 수 없습니다.
명령이 메모리에 저장되면 작업 전환이 극적으로 쉬워집니다: 하드웨어를 재구성하지 않고 메모리에 새로운 프로그램을 로드해 실행하면 됩니다. 같은 범용 기계가 오전에는 급여 계산을 하고 오후에는 탄도 계산을 할 수 있는 이유가 바로 여기에 있습니다—작업 방법은 대체 가능한 비트 집합일 뿐입니다.
레시피와 재료가 같은 찬장에 보관된 주방을 상상해 보세요. 요리사(프로세서)는 찬장(메모리)에 반복해서 가서 다음 레시피 단계(명령)를 읽고 재료(데이터)를 꺼내거나 업데이트합니다.
다른 요리를 만들고 싶다면 주방을 새로 설계하지 않습니다. 단지 다른 레시피를 넣으면 됩니다—같은 조리대, 오븐, 도구를 사용하면서요.
존 폰 노이만은 “컴퓨터를 발명”한 사람도, 저장 프로그램 아이디어를 단독으로 만든 사람도 아닙니다. 그가 한 훌륭한 일은, 유망한 개념을 명확하게 진술하고 널리 공유 가능한 설계로 정리한 것입니다. 다른 엔지니어와 연구소들이 이를 바탕으로 구축할 수 있게 만든 점이 중요합니다.
폰 노이만은 전시와 전후의 컴퓨팅 프로젝트에 깊이 관여했고, 논리적 설계를 다듬어 여러 그룹에게 자문했습니다. 그는 복잡한 기술적 선택을 평이하고 조직적으로 설명하는 재능을 갖고 있었는데, 이는 초기 전자 컴퓨팅이 빠르게 진행되던 시기에 중요했습니다. 여러 그룹이 동시에 유사한 문제를 풀고 있었기 때문입니다.
더 중요한 점은 그가 프로그램 명령을 데이터와 같은 메모리에 저장할 수 있다는 방식에 대해 영향력 있는 설명을 작성하고 배포했다는 것입니다. 그 명확한 프레이밍은 다른 사람들이 이 접근법을 토론하고 가르치고 복제하기 쉽게 만들었습니다.
이름은 종종 아이디어를 처음 낸 사람에게 붙지 않고, 설명이 표준 참조점이 된 사람에게 붙습니다. 폰 노이만의 문서들은 널리 읽히고 인용되어서 후대의 사람들은 자연스럽게 ‘저장 프로그램 구성’을 그의 이름과 연결했습니다.
이 명명은 역사를 단순하게 만들기도 했습니다: 모든 기여자와 보고서를 나열하는 것보다 “폰 노이만 아키텍처”라고 하는 편이 간단합니다. 다만 이 약칭은 실제로 일어난 일을 가릴 수 있습니다.
초기 전자 컴퓨팅은 수학자, 엔지니어, 프로그래머가 함께한 협력적·교차 기관적 노력이었습니다. 저장 프로그램 개념은 토론, 초안, 프로토타입, 수정 과정을 통해 성숙해졌습니다. 폰 노이만의 지속적인 역할은 아이디어를 결집하고 전파하여 채택을 가속화한 것이지, 혼자 만들어낸 결과로 보기는 어렵습니다.
EDVAC(Electronic Discrete Variable Automatic Computer)는 전후의 초기 컴퓨터 프로젝트 중 하나로 “일회성” 기계를 넘어서는 방향을 모색했습니다. 하드웨어 노력만큼이나 중요한 것은 설계 아이디어를 명확하게 문서화하기로 한 결정이었습니다. 당시 컴퓨터 제작은 여전히 실험적 엔지니어링에 가까웠고 지식은 실험실 노트, 회의, 소수 전문가의 머릿속에 있었습니다. 보고서는 흩어진 통찰을 다른 팀들이 논의·비판·재사용할 수 있는 형태로 바꿀 수 있었습니다.
First Draft of a Report on the EDVAC(종종 “EDVAC 보고서”로 줄여 부름)는 저장 프로그램 아이디어를 개념적으로 제시했습니다: 컴퓨터는 프로그램 명령을 데이터와 같은 내부 메모리에 보관해야 한다. 그 메모리는 계산이 진행되는 동안 숫자를 보관하는 장소일 뿐만 아니라 다음에 기계가 무엇을 할지 알려주는 단계(명령)를 담는 장소이기도 합니다.
이 프레이밍은 컴퓨터를 고정 목적 장치보다는 메모리 내용만 바꿔 재작업할 수 있는 범용 기계처럼 느끼게 합니다. 시스템을 재배선하지 않고도 다른 작업을 하려면 다른 명령 시퀀스를 로드하면 됩니다.
개념 자체를 넘어서, 보고서는 사람들이 컴퓨터에 대해 표준화된 방식으로 말할 수 있도록 도왔습니다: 메모리, 제어, 연산, 입출력을 서로 다른 기능적 부분으로 분리해 함께 작동하는 모델로 설명했습니다. 공통된 어휘와 널리 읽히는 설명이 있으면 EDVAC뿐 아니라 전체 분야에 보편적 사고 모델을 제공해 저장 프로그램 컴퓨터를 설계·비교·개선하기 쉬워졌습니다.
“누가 저장 프로그램 컴퓨터를 발명했나?”라고 묻고 한 사람의 이름을 기대하는 것은 유혹적입니다. 하지만 과학과 공학은 거의 그렇게 작동하지 않습니다. 아이디어는 종종 병렬로 발전하고 토론을 통해 다듬어지며, 작동하는 하드웨어로 증명될 때 비로소 설득력을 얻습니다.
존 폰 노이만은 저장 프로그램 개념과 강하게 연관되지만 초기 작업에는 많은 사람과 그룹이 관여했습니다:
저장 프로그램 컴퓨터는 단일 통찰만이 아닙니다. (1) 명령을 데이터처럼 메모리에 둘 수 있다는 개념적 도약, (2) 신뢰성 있는 메모리와 제어 유닛을 구축하는 공학, (3) 설계를 사용할 수 있게 하는 프로그래밍 관행의 결합이 필요했습니다. 각기 다른 사람들이 각 부분에 기여했습니다.
또 다른 이유로 공로가 나뉩니다: 아이디어를 제안하는 것과 하루하루 안정적으로 작동하는 기계를 만드는 것은 다릅니다. 초기 보고서와 토론은 개념을 명확히 했고, 초기 프로토타입과 생산 시스템은 그것이 실현 가능함을 증명했습니다. 신중한 역사는 두 종류의 기여를 모두 존중합니다—단순한 “첫 발명자” 결론을 강요하지 않고요.
사람들이 “폰 노이만 아키텍처”라고 말할 때 보통 저장 프로그램 컴퓨터가 어떻게 조직되는지 보여주는 단순하고 널리 교육되는 모델을 가리킵니다. 이것은 상표나 단일 역사적 기계가 아니라, 많은 컴퓨터에서 다양한 형태로 나타나는 기본 설계 계획을 설명하는 편리한 레이블입니다.
개념적 수준에서 구도는 다음과 같습니다:
핵심은 CPU가 “프로그램”과 “숫자”를 위한 별도의 물리적 장소를 갖지 않는다는 점입니다. 필요한 모든 것을 메모리에서 가져옵니다.
CPU는 종종 fetch–decode–execute(가져오기–해독–실행) 루프를 반복하며 프로그램을 실행합니다:
이 설명은 단순화되어 있지만 핵심을 포착합니다: 프로그램은 메모리에 저장된 명령의 연속이고 CPU는 그것들을 차례로 수행합니다.
명령과 데이터가 같은 메모리에 있으면 컴퓨터는 매우 실용적인 방식으로 범용이 됩니다:
따라서 “폰 노이만 아키텍처”는 명령과 데이터를 공유하는 메모리, CPU, I/O를 갖춘 저장 프로그램 모델에 대한 편리한 약칭으로 이해하는 것이 좋습니다. 이는 폰 노이만의 명확한 설명과 강하게 연관되지만, 초기 이야기가 여러 기여자를 포함한다는 점을 잊어선 안 됩니다.
사람들은 종종 “폰 노이만”과 “하버드”를 상충하는 철학처럼 이야기하지만, 실제로는 컴퓨터가 명령과 데이터를 어떻게 정리해 CPU가 필요한 것을 가져오게 할지에 대한 두 가지 실용적 방식입니다.
폰 노이만식 설계에서는 명령과 데이터가 같은 메모리에 있고 보통 CPU로 가는 동일한 주요 경로를 공유합니다.
개념적으로 단순합니다: 프로그램은 메모리의 바이트일 뿐, 바로 옆에 숫자나 텍스트, 이미지가 있습니다. 또한 범용 컴퓨팅을 단순하게 만듭니다—소프트웨어는 같은 메커니즘으로 로드·변경·저장될 수 있습니다.
단점: 명령과 데이터가 같은 “도로”를 쓰면 대역폭 경쟁이 생길 수 있습니다(이를 흔히 “병목”으로 설명합니다).
하버드식은 명령 저장과 데이터 저장을 분리하고, 종종 명령과 데이터를 가져오는 경로도 별도로 둡니다.
이 분리는 다음 명령을 가져오는 동안 데이터를 읽거나 쓸 수 있게 해 작은 예측 가능한 시스템에서 유리합니다. 간단한 예로 많은 마이크로컨트롤러는 코드가 플래시에 있고 변수는 RAM에 있는 구조를 가집니다.
현대 CPU는 소프트웨어 관점에선 폰 노이만처럼 보이지만 내부적으로 하버드식 아이디어를 차용합니다. 흔한 예로는 **명령 캐시(I-cache)**와 **데이터 캐시(D-cache)**를 분리하는 것입니다. 프로그램에는 하나의 메모리처럼 느껴지지만 하드웨어는 코드와 데이터를 더 효율적으로 가져올 수 있습니다.
요점: 보편적 우승자는 없습니다. 폰 노이만은 단순성과 유연성을, 하버드는 분리와 처리량을 강조합니다. 많은 기계가 비용·전력·속도·프로그래밍 편의성의 균형을 맞추기 위해 둘을 섞어 씁니다.
저장 프로그램 컴퓨터는 단지 계산을 ‘실행’하는 것이 아니라 메모리에서 명령 집합을 로드하고 실행한 뒤 나중에 다른 집합을 로드할 수 있습니다. 이 전환은 소프트웨어를 재사용 가능하고 공유 가능한 것으로 만들었습니다: 프로그램은 한 번 작성해 저장·복사·개선·배포할 수 있으며 하드웨어를 만질 필요가 없습니다.
프로그램이 메모리에 있으면 동일한 물리적 컴퓨터가 명령만 바꿔서 여러 다른 작업을 수행할 수 있습니다. 이게 범용의 실제 의미입니다: 하나의 기계, 여러 프로그램. 컴퓨터는 더 이상 단일 워크플로로 정의되지 않습니다; 플랫폼이 됩니다.
현대적 예로 노트북이 이메일, 게임, 스프레드시트를 실행하는 것을 들 수 있습니다. 그 밑바닥에는 같은 아이디어가 있습니다: 하드웨어는 고정되어 있고 다양한 저장 프로그램이 로드되어 앱을 전환하게 합니다.
명령이 메모리의 데이터로 취급되면, 소프트웨어를 작성하는 데 도움이 되는 여러 계층의 도구를 만드는 것이 현실적이 됩니다:
이 도구들은 프로그램을 저장·이동·조작할 수 있다는 가정에 의존합니다. 그것이 소프트웨어를 특정 배선에 묶인 일회성 산물이 아닌 생태계로 만든 이유입니다.
한 가지 유용한 장기 관점: 저장 프로그램은 컴파일러와 OS를 가능하게 했고, 이 도구들이 더 야심찬 프로그램을 가능하게 했습니다—오늘날에는 자연어로 애플리케이션을 설명하면 도구가 실행 가능한 코드로 생성해 주는 수준까지 올라왔습니다. 예를 들어 Koder.ai는 채팅 인터페이스와 LLM, 에이전트 기반 워크플로를 활용해 의도(“무엇을 해야 하는가?”)에서 실행 가능한 코드(내보내기·배포·스냅샷으로 롤백 가능한 소스 코드)까지 빠르게 이어주는 vibe-coding 플랫폼입니다.
결과는 동일한 선순환입니다: 저장 프로그램이 더 나은 도구를 가능하게 했고, 더 나은 도구는 더 야심찬 소프트웨어를 가능하게 했습니다—컴퓨터를 유연한 범용 기계로 바꿨습니다.
저장 프로그램 아이디어는 컴퓨터를 유연하게 만들었지만, 엔지니어들이 여전히 논하는 실용적 제약도 드러냈습니다: 바로 “폰 노이만 병목”입니다. 일상적으로 말하면 CPU(작업자)와 메모리(창고) 사이의 도로에 생긴 교통 체증과 같습니다.
일반적인 저장 프로그램 설계에서 명령과 데이터는 메모리에 함께 있습니다. CPU는 명령을 가져오고, 필요한 데이터를 가져오고, 결과를 다시 쓰는데 종종 같은 연결을 통해 일어납니다. 그 연결이 정보를 충분히 빨리 옮기지 못하면 CPU는 기다리느라 시간을 허비하게 됩니다.
두 가지 관련된 요소가 이 병목을 결정합니다:
CPU는 초당 수십억 연산을 수행할 수 있어도, 메모리가 필요한 바이트를 꾸준히 공급하지 못하면 성능은 결국 느린 단계에 의해 제한됩니다.
이 문제는 널리 연구되는 공학적 고려사항이며, 현대 컴퓨터는 영향 완화를 위해 여러 기법을 사용합니다:
이 접근법들은 근본적인 “도로” 문제를 없애진 못하지만 혼잡을 줄여 CPU가 더 많은 시간을 실제 연산에 쓰게 돕습니다.
저장 프로그램 개념은 박물관 전시물이 아닙니다—일상적인 컴퓨팅의 유연성을 유지하는 방식입니다. 기기를 새로 ‘배선’할 필요 없이 메모리에 다른 명령을 로드해 실행하면 됩니다.
휴대폰에서 앱 아이콘을 누르면 운영체제는 그 앱의 코드(명령)를 저장소에서 메모리로 로드하고 CPU가 이를 실행하게 합니다. 노트북에서도 브라우저를 열거나 문서를 편집하거나 게임을 실행할 때 같은 일이 일어납니다. 서버에서는 수천 개의 변화하는 워크로드(웹 요청, DB 쿼리, 백그라운드 작업 등)를 하드웨어 변경 없이 처리하는 것이 더 명확하게 드러납니다.
심지어 ‘하드웨어처럼 보이는’ 기능도 소프트웨어 정의되는 경우가 많습니다. 네트워크 라우팅, 비디오 디코딩 경로, 사진 향상, 전력 관리 정책 등은 펌웨어와 시스템 소프트웨어로 업데이트되는 경우가 많아 같은 기기에서 동작을 바꾸는 것이 가능합니다.
파이썬, 자바스크립트 같은 언어는 보통 인터프리터나 가상 머신에서 실행됩니다. CPU가 소스 코드를 직접 실행하는 대신, 프로그램은 바이트코드나 내부 명령 구조로 번역되어 메모리에 저장되고 단계별로 실행됩니다. Java의 JVM, .NET, WebAssembly 런타임, 브라우저 자바스크립트 엔진은 모두 명령이 메모리의 데이터 구조가 되어 로드·이동·실행되는 방식에 의존합니다.
명령은 단지 메모리의 정보이기 때문에 공격자는 데이터를 통해 악성 코드를 밀어넣으려 합니다—고전적인 코드 인젝션 사례입니다. 메모리 보호, 코드 서명, 비실행 메모리 영역 같은 방어 기법이 신뢰할 수 없는 데이터를 실행 가능한 명령으로 취급되는 것을 막습니다.
이 모든 것은 저장 프로그램의 중심 약속으로 돌아옵니다: 같은 하드웨어에서 소프트웨어를 통해 유연함을 얻는 것입니다.
시스템을 볼 때(또는 사양을 읽을 때) 다음 질문이 기본 모델을 파악하는 데 도움이 됩니다:
더 읽기 쉬운 배경 글을 원하면 /blog를 둘러보세요.
참고: 명령을 실행 가능한 시스템으로 바꾸는 현대적 방법(직접 코드 작성이든 채팅 기반 빌드 플랫폼 사용이든)을 실험할 때 배운 점을 문서화해 두는 것을 권합니다. Koder.ai는 출판 콘텐츠와 추천으로 크레딧을 얻는 프로그램을 제공해 더 많은 실험과 튜토리얼을 지원하는 현실적인 방법이 될 수 있습니다.
저장 프로그램 컴퓨터는 프로그램 명령을 해당 명령이 다루는 데이터와 같은 내부 메모리에 보관합니다. 작업을 바꾸려면 하드웨어를 재배선하거나 재구성하는 대신 메모리에 다른 명령 집합을 로드하면 됩니다.
저장 프로그램 이전에는 많은 기계가 플러그보드, 패치 케이블, 스위치 설정으로 ‘프로그래밍’되었습니다. 연산 순서를 바꾸려면 수시간 또는 수일에 걸쳐 재배선을 하고 재시험해야 했고, 잘못 꽂은 한 케이블이 찾기 어려운 오류를 만들곤 했습니다.
여기서 “메모리”는 CPU가 실행 중에 읽고 쓰는 빠른 작업용 저장소(현대의 RAM과 유사)를 가리킵니다. 전원이 꺼져도 보존되는 장기 저장장치(디스크/SSD 등)와는 다릅니다.
EDVAC 보고서(First Draft of a Report on the EDVAC)는 명령과 데이터가 동일한 내부 메모리를 공유한다는 구성을 명확히 제시했고, 메모리·제어·연산·입출력 같은 공통 어휘를 제공해 다른 연구팀들이 개념을 토론하고 유사한 시스템을 더 빨리 설계·제작할 수 있게 했습니다.
폰 노이만의 이름이 널리 붙은 이유는 그의 설명이 많이 배포되고 참고하기 쉬웠기 때문이지, 그가 단독으로 발명했기 때문은 아닙니다. 저장 프로그램 접근법은 동시에 여러 연구자와 팀의 작업을 통해 발전했습니다.
“폰 노이만 아키텍처”는 보통 다음을 가리키는 모델입니다:
이 용어는 저장 프로그램 구조를 설명하는 편리한 레이블이지, 하나의 특정 기계나 단독 발명자를 지칭하는 절대적 주장으로 보긴 어렵습니다.
폰 노이만 방식에서는 명령과 데이터가 하나의 메모리를 공유하고 동일한 경로를 통해 CPU로 전달되는 반면, 하버드 방식은 명령 저장과 데이터 저장을 분리하고 종종 각각 별도의 경로를 둡니다. 현대 시스템은 소프트웨어 관점에서 폰 노이만처럼 보이면서 내부적으로는 명령/데이터 캐시 분리 등 하버드식 아이디어를 섞어 쓰는 경우가 많습니다.
“폰 노이만 병목(von Neumann bottleneck)”은 CPU와 메모리 사이의 데이터·명령 전송 경로의 제약에서 오는 성능 한계를 가리킵니다. 흔한 완화책은 캐시, 프리페칭(선예측 로딩), 병렬화(멀티코어, 연산과 메모리 접근의 중첩) 등으로, 근본 문제를 없애지는 못해도 CPU가 대기하는 시간을 줄여줍니다.
프로그램이 단지 메모리의 정보라서, 소프트웨어를 바꾸는 것으로 기기 동작을 업데이트할 수 있습니다. 그래서 같은 폰이나 노트북에서 앱을 바꿔 쓰거나 펌웨어·OS 업데이트로 새로운 기능을 추가할 수 있습니다. 즉, 하드웨어를 바꾸지 않고 동작을 전환할 수 있다는 점이 핵심입니다.
명령이 메모리에 데이터로 존재하기 때문에 공격자는 종종 **신뢰할 수 없는 데이터를 실행 가능한 코드로 바꿔 실행하려는 시도(코드 인젝션 등)**를 합니다. 이를 방지하기 위해 메모리 보호(실행 불가 영역), 코드 서명, 기타 제어 메커니즘이 사용됩니다.