Quick Flow
text
source code
-> compiler / linker
-> executable file
-> operating-system loader
-> process + virtual address space
-> thread scheduled on a CPU
-> instructions read and executed
-> memory and device I/OCPU는 명령을 실행하고, 메모리는 실행 중인 코드와 데이터를 보관하며, 운영체제는 프로세스·스레드·메모리·장치 접근을 관리합니다. 실행 파일은 재료이고 프로세스는 그 파일이 실제 자원과 실행 상태를 얻은 결과입니다.
이 흐름은 시스템 전체의 책임을 찾기 위한 지도입니다. Compile·Link·Load의 세부 오류 구분은 Compile·Link·Load 구분 카드에서 따로 다룹니다.
구성 요소
| 구성 요소 | 맡는 일 | 구분해야 할 것 |
|---|---|---|
| CPU | 명령 해석과 연산 | 파일을 보관하는 장치가 아닙니다. |
| Memory | 실행 중인 코드와 데이터의 작업 공간 | 영구 저장소와 수명이 다릅니다. |
| Storage | 실행 파일과 데이터를 지속적으로 보관 | CPU가 매 명령마다 직접 실행하는 공간이 아닙니다. |
| Operating System | 프로세스, 메모리, 파일, 장치와 권한 관리 | 애플리케이션 로직을 대신 실행하지 않습니다. |
| Device | 화면, 네트워크, 입력과 같은 외부 작업 수행 | 보통 드라이버와 OS 경계를 거쳐 접근합니다. |
프로그램이 파일을 읽는 한 줄도 내부에서는 시스템 호출, 파일 시스템, 저장 장치 요청을 거칠 수 있습니다. 각 계층은 다른 책임을 가지므로 성능 문제도 CPU 연산, 메모리 접근, 저장 장치 대기, 네트워크 대기로 나누어 봐야 합니다.
실행 경계
소스 코드는 CPU가 곧바로 실행하지 않습니다. 언어와 빌드 방식에 따라 기계어 또는 중간 표현으로 변환되고, 필요한 코드와 연결된 실행 결과물이 만들어집니다. 운영체제 로더가 이를 가상 주소 공간에 배치하고 기본 스레드를 준비해야 실제 명령 실행이 시작됩니다.
한 프로그램이 느리다고 CPU만 의심하면 원인을 놓칠 수 있습니다. CPU 사용률이 낮은데도 응답이 늦다면 디스크·네트워크·락 대기처럼 실행 흐름이 멈춘 경계를 먼저 확인합니다.
자주 틀리는 점
- 프로그램과 프로세스를 같은 말로 쓰지 않습니다. 하나의 실행 파일에서 여러 프로세스가 만들어질 수 있습니다.
- 메모리와 저장 장치를 같은 용량 문제로만 보지 않습니다. 접근 지연과 데이터 수명이 크게 다릅니다.
- 비동기 코드를 사용했다고 CPU 작업이 자동으로 병렬화되지는 않습니다.
- GPU가 있다고 모든 계산이 빨라지지 않습니다. 데이터를 옮기고 같은 연산을 충분히 많이 수행할 때 이점이 생깁니다.
참고 링크
2 sources