PATH, 프로세스와 스레드, 그리고 동기·비동기
한 줄 요약
설치한 도구가 어떻게 인식되는지(PATH)부터 프로그램이 실제로 실행되는 구조(프로세스·스레드·CPU)까지, 눈에 안 보이는 층을 훑었다.
1. 오늘 배운 것
오늘 배운 것들은 전부 평소에는 보이지 않는 층이다. 설치한 도구가 왜 인식되는지, 실행한 프로그램이 어디서 도는지, 화면이 왜 멈추지 않는지. 순서대로 아래로 내려가는 구조라서 그 순서대로 정리했다.
1-1. 설치한 도구는 어떻게 “인식”되는가 — PATH
node라고 입력했을 때 셸은 그게 뭔지 모른다.
대신 PATH에 등록된 폴더들을 위에서부터 순서대로 뒤져서 node.exe를 찾는다. 찾으면 실행하고, 끝까지 없으면 “용어가 인식되지 않습니다”가 뜬다.
여기서 중요한 건, 그 오류가 설치 실패를 뜻하지 않을 수도 있다는 점이다. 프로그램은 멀쩡히 깔려 있는데 PATH에 그 폴더가 없으면 똑같은 오류가 난다.
PATH는 두 군데에 나뉘어 있다.
| 구분 | 적용 범위 |
|---|---|
| 사용자 변수 PATH | 내 계정에서만 유효 |
| 시스템 변수 PATH | 이 컴퓨터의 모든 계정에 유효 |
둘은 따로 보이지만, 명령을 찾을 때는 합쳐져서 하나의 목록처럼 탐색된다.
내 PC를 열어보니 nodejs 경로는 시스템 변수에, npm 경로는 사용자 변수에 들어 있었다.
설치 방식에 따라 나뉜 결과이고, 규칙이라기보다 둘 중 어디든 목록에 있으면 인식된다가 핵심이다.
알아두면 좋은 것: PATH는 터미널이 켜질 때 한 번 읽힌다. 그래서 설치 직후에는 창을 새로 열어야 인식된다.
1-2. 실행 중인 프로그램의 구조 — 프로세스와 스레드
- 프로세스 — 실행 중인 프로그램 하나. 자기만의 메모리 공간을 따로 갖는다.
- 스레드 — 그 프로세스 안에서 실제로 명령을 수행하는 흐름. 하나의 프로세스 안에 여러 개가 있을 수 있다.
핵심 차이는 메모리를 나눠 쓰느냐 아니냐다.
- 같은 프로세스 안의 스레드끼리는 메모리를 공유한다 → 서로 데이터를 바로 주고받아 빠르지만, 한쪽이 망가뜨리면 같이 영향을 받는다.
- 프로세스끼리는 메모리가 분리되어 있다 → 서로를 들여다볼 수 없고, 하나가 멈춰도 다른 쪽은 멀쩡하다.
브라우저 탭 하나가 먹통이 돼도 다른 탭은 살아 있는 이유가 이것이다. 리소스 모니터를 열면 지금 돌아가는 프로세스와 각 프로세스가 몇 개의 스레드를 갖고 있는지 직접 볼 수 있다.
1-3. 그 스레드들을 누가 배분하는가 — CPU와 커널
- CPU — 실제로 계산을 수행하는 부품.
- 메모리(RAM) — 지금 작업 중인 데이터를 잠깐 올려두는 작업대.
- 코어 — CPU 안의 실제 일꾼. 코어가 많으면 동시에 처리할 수 있는 일이 늘어난다.
- 커널 — 운영체제의 핵심. 어떤 스레드에게 CPU를 얼마나 줄지 결정한다.
작업 관리자를 열어보니 코어 수와 논리 프로세서 수가 달랐다. 논리 프로세서는 일꾼이 물리적으로 늘어난 게 아니라, 일꾼 한 명이 일감 줄을 두 개 받는 것에 가깝다. 한쪽 작업이 데이터를 기다리며 노는 틈에 다른 줄의 작업을 끼워 처리하니, 운영체제 입장에서는 일꾼이 두 명처럼 보인다. 다만 일꾼이 두 배가 된 건 아니므로 성능이 두 배가 되지는 않는다.
1-4. 동기와 비동기
- 동기(synchronous) — 요청을 보내고 결과가 올 때까지 멈춰서 기다린다. 그동안 다른 일을 못 한다.
- 비동기(asynchronous) — 요청만 던져 놓고 바로 다음 일을 진행한다. 결과는 준비되면 그때 처리한다.
카페로 바꿔 보면 이렇다. 주문하고 카운터 앞에 서서 커피가 나올 때까지 기다리면 동기, 진동벨을 받고 자리에 돌아가 할 일을 하다가 벨이 울리면 가지러 가면 비동기다.
가장 헷갈렸던 부분을 정리하면 이렇다.
비동기 = 여러 개를 동시에 처리하는 것이 아니다. 비동기는 기다리는 일을 다른 쪽에 맡기고 나는 멈추지 않는 것이다. 커피가 더 빨리 나오는 게 아니라, 기다리는 동안 내가 멈춰 있지 않은 것뿐이다.
그래서 스레드를 여러 개 쓰지 않아도 비동기는 가능하다. 네트워크 응답처럼 오래 걸리지만 CPU는 놀고 있는 일이 있을 때, 그 대기를 브라우저나 운영체제에 넘겨두고 내 코드는 계속 진행하는 방식이다. 웹에서 이게 없으면 데이터를 불러오는 몇 초 동안 화면 전체가 굳는다.
1-5. 웹은 무엇으로 만들어지는가
| 언어 | 역할 | 집에 비유하면 |
|---|---|---|
| HTML | 구조 — 무엇이 있는가 | 골조와 방 배치 |
| CSS | 표현 — 어떻게 보이는가 | 벽지, 색, 배치 |
| JavaScript | 동작 — 무엇이 일어나는가 | 전기 배선과 스위치 |
그리고 이 코드가 어디서 실행되는지로 프론트엔드와 백엔드가 갈린다.
- 프론트엔드 — 사용자의 브라우저에서 실행된다. 화면과 상호작용을 담당한다.
- 백엔드 — 서버에서 실행된다. 데이터 저장, 로그인 처리처럼 남에게 보이면 안 되는 일을 맡는다.
왜 필요한가
바이브 코딩에서 AI에게 일을 맡기더라도, 결과가 이상할 때 판단하는 건 결국 나다. “명령을 찾을 수 없다”가 PATH 문제인지 설치 문제인지, 화면이 굳는 게 동기 처리 때문인지 구분하려면 오늘 배운 어휘가 있어야 질문이라도 제대로 할 수 있다. 오늘 내용은 기능이 아니라 앞으로 읽게 될 에러 메시지의 사전에 가깝다.
2. 실습 / 코드
2-1. 환경 변수에서 PATH 확인하기
Win + R → sysdm.cpl → 고급 탭 → 환경 변수 버튼.
위쪽이 사용자 변수, 아래쪽이 시스템 변수다. 각각의 Path를 선택해 편집을 누르면 등록된 폴더 목록이 보인다.
확인한 결과는 이랬다.
[시스템 변수] Path
C:\Program Files\nodejs\ ← node
[사용자 변수] Path
C:\Users\<사용자명>\AppData\Roaming\npm ← npm
같은 내용을 PowerShell로도 볼 수 있다. (다음 시간에 직접 해보기)
$env:Path -split ';' # PATH에 등록된 폴더를 한 줄씩 나열
Get-Command node # node가 실제로 어느 경로에서 발견되는지 확인
2-2. 작업 관리자에서 코어와 논리 프로세서 확인하기
Ctrl + Shift + Esc → 성능 탭 → CPU.
오른쪽 아래에 코어 수와 논리 프로세서 수가 따로 표시된다.
코어: 4 (실제 일꾼 수)
논리 프로세서: 8 (운영체제에게 보이는 일꾼 수)
두 숫자가 다르면 앞서 정리한 그 이유다.
프로세스별 스레드는 Win + R → resmon (리소스 모니터) → CPU 탭에서 볼 수 있다.
3. 그림 / 스크린샷
4. 막혔던 점과 해결
| 막힌 지점 | 원인 | 해결 방법 |
|---|---|---|
| 동기/비동기 개념이 잘 잡히지 않음 | “비동기 = 동시에 여러 개를 처리하는 것”으로 잘못 이해했다. 그러면 스레드와 뭐가 다른지 구분이 안 된다 | 관점을 “기다리는 동안 내가 무엇을 하는가” 로 바꿨다. 비동기는 일을 늘리는 게 아니라 대기를 남에게 맡기는 것 (그림 3) |
| PATH가 사용자 변수와 시스템 변수로 나뉘어 있어 어디에 뭐가 있어야 하는지 헷갈림 | 둘을 별개의 규칙으로 생각했다 | 명령을 찾을 때는 두 목록이 합쳐져 탐색된다. “어디에 있어야 한다”가 아니라 “목록 안에 있기만 하면 된다”로 정리 |
아직 남은 것: 비동기를 개념으로는 잡았지만 코드로 본 적이 없다.
setTimeout 정도로 실행 순서를 눈으로 확인해 봐야 진짜로 이해한 게 될 것 같다.
5. 스스로 확인하기
node를 입력했을 때 컴퓨터가 하는 일을 순서대로 설명할 수 있는가?- “명령을 찾을 수 없습니다”가 반드시 설치 실패를 뜻하지 않는 이유를 말할 수 있는가?
- 프로세스와 스레드의 차이를 메모리 기준으로 설명할 수 있는가?
- 코어 수와 논리 프로세서 수가 다른 이유를 설명할 수 있는가?
- 비동기를 “동시 처리”가 아닌 말로 설명할 수 있는가?
- 프론트엔드와 백엔드를 실행되는 위치로 구분할 수 있는가?
6. 더 알아볼 것
- 리소스 모니터를 직접 열어 브라우저 탭 수와 프로세스 수를 비교해 보기
setTimeout으로 실행 순서를 찍어 보며 비동기를 코드로 확인하기- JavaScript가 싱글 스레드인데도 비동기가 되는 원리 (이벤트 루프)
- PowerShell로 PATH 확인하기 —
$env:Path,Get-Command - 지난 회차의 숙제: PowerShell 기초 문법 (아직 진행 중)