94. 스레드의 독립 자원 - Thread ID, PC, 레지스터 집합, 스택

핵심 인사이트 (3줄 요약)

본질: 스레드 (Thread)는 프로세스의 자원을 공유하지만, 독립적인 실행 흐름 (Execution Flow)을 유지하기 위해 스레드 ID (TID), 프로그램 카운터 (PC), 레지스터 (Registers), 스택 (Stack)은 스레드별로 고유하게 할당받는다.

가치: 스택과 PC를 독립적으로 보유함으로써, 여러 스레드가 코드 영역을 공유하면서도 서로 다른 함수 위치에서 자신만의 지역 변수를 가지고 충돌 없이 비동기적으로 함수를 호출하고 복귀할 수 있다.

판단 포인트: 컨텍스트 스위칭 (Context Switching) 시 스레드의 상태를 저장하고 복원하는 핵심 대상이 바로 이 독립 자원들이며, 이 자원들의 크기가 전체 시스템이 생성할 수 있는 동시성 (Concurrency) 밀도의 한계를 결정한다.

Ⅰ. 개요 및 필요성

스레드의 독립 자원 (Independent Resources)은 동일한 프로세스 내에서 여러 스레드가 논리적으로 독립된 실행 흐름을 보장받기 위해 운영체제 (OS, Operating System) 커널과 메모리 할당기가 개별 스레드마다 고유하게 부여하는 최소한의 실행 문맥 (Execution Context)이다.

모든 스레드가 프로그램 카운터 (PC)나 스택마저 공유한다면, 한 스레드가 함수 A를 실행하고 있을 때 다른 스레드가 함수 B를 실행하려 하면 명령 실행 위치와 지역 변수들이 뒤섞여 엉망이 된다. 따라서 코드(Code), 데이터(Data), 힙(Heap) 같은 공유 자원의 이점은 살리되, "실행의 추적"은 각자 관리해야만 멀티태스킹이 온전히 동작할 수 있다.

📢 섹션 요약 비유: 영화관에서 여러 사람이 같은 영화(Code)를 보더라도, 각자의 뇌리(Register)에 남는 감상 포인트와 기억의 위치(PC)는 모두 독립적으로 존재하는 것과 같다.

Ⅱ. 아키텍처 및 핵심 원리

독립 자원의 핵심은 다음 번에 실행할 주소를 기억하는 PC와, 자신만의 임시 공간인 Stack의 결합에 있다.

구성 요소	역할	내부 동작	관리 위치
Thread ID (TID)	스레드의 고유 식별자	OS 스케줄러가 타겟을 지정할 때 사용	TCB (Thread Control Block)
PC (Program Counter)	다음 번 실행할 명령어 주소	CPU Fetch 사이클마다 자동 증가 갱신	TCB 내 문맥 정보
Register 집합	연산의 중간 결과, 상태 플래그	문맥 교환 시 CPU에서 읽어와 백업됨	TCB (컨텍스트 저장소)
Stack (스택)	매개변수, 복귀 주소, 지역 변수 보관	함수 Call 시 Push, Return 시 Pop	프로세스 주소 공간 내 개별 할당

스레드 문맥 교환 시, 프로세스의 무거운 가상 메모리 매핑(TLB 등)은 그대로 두고 이 가벼운 독립 자원 정보들만 CPU와 TCB 사이에서 교체된다.

┌────────────────────────────────────────────────────────────────────────┐
│             독립적인 스택 (Stack)을 통한 함수 실행 격리 아키텍처             │
├────────────────────────────────────────────────────────────────────────┤
│ [Thread A Stack]                   [Thread B Stack]                    │
│                                                                        │
│ │                  │               │                  │                │
│ ├──────────────────┤ ◀ SP_A        ├──────────────────┤ ◀ SP_B         │
│ │ func_Y 지역변수   │               │ func_Z 지역변수   │                │
│ │ Return Addr(A)   │               │ Return Addr(B)   │                │
│ ├──────────────────┤               ├──────────────────┤                │
│ │ func_X 지역변수   │               │ func_W 지역변수   │                │
│ │ Return Addr(A)   │               │ Return Addr(B)   │                │
│ └──────────────────┘               └──────────────────┘                │
│                                                                        │
│ 결론: 스레드 A는 func_X → func_Y 호출 중, 스레드 B는 func_W → func_Z 호출 중 │
│ 동일한 Code 영역 함수를 공유하지만, 복귀 주소와 지역 변수는 전혀 섞이지 않음 │
└────────────────────────────────────────────────────────────────────────┘

다이어그램이 보여주듯, 각 스레드는 전용 스택 포인터 (SP, Stack Pointer)를 가지며 함수를 호출한다. 이 구조 덕분에 한 함수를 여러 스레드가 동시에 호출(Re-entrant)하더라도 데이터 충돌 없이 안전한 처리가 가능하다.

📢 섹션 요약 비유: 등산객들이 같은 산(Code)을 오르지만, 각자의 배낭(Stack)에는 본인만의 식량과 현재 어느 지점까지 왔는지 기록한 나침반(PC)이 따로 들어있는 것과 같다.

Ⅲ. 비교 및 연결

독립 자원의 구조를 가장 잘 이해할 수 있는 것은 전통적인 OS 스레드와 최신 코루틴 (Coroutine)의 비교다.

비교 항목	OS 스레드 (OS Thread)	코루틴 / 가상 스레드 (Virtual Thread)
제어 주체	OS 커널 스케줄러 (선점형)	사용자 레벨 런타임 (비선점형)
TCB / 컨텍스트	커널 메모리에 무거운 TCB 객체 보관	유저 힙 (Heap)에 가벼운 상태 객체로 저장
스택 크기 (핵심 차이)	고정된 큰 스택 할당 (보통 1~8MB)	필요 시 수십 바이트~KB 단위로 동적 확장
컨텍스트 스위칭	레지스터 백업 및 커널 모드 전환 오버헤드	함수 반환 수준의 가벼운 레지스터 백업

OS 스레드는 독립 자원 중 특히 스택을 고정된 메가바이트(MB) 단위로 낭비하며 확보한다. 수만 개를 띄우면 메모리가 고갈된다. 반면 코루틴이나 Go의 고루틴은 이 독립 자원(스택)을 극단적으로 경량화하여 동적 할당함으로써 한 대의 서버에서 수십만 개의 동시성을 확보할 수 있게 한다.

📢 섹션 요약 비유: OS 스레드가 각 요리사에게 무조건 100평짜리 대형 주방(고정 스택)을 할당한다면, 코루틴은 필요한 만큼만 넓어지는 조립식 테이블(동적 스택)을 주는 것과 같다.

Ⅳ. 실무 적용 및 기술사 판단

독립 자원의 오용은 치명적인 프로세스 전체 장애를 부른다.

스택 오버플로우 (Stack Overflow): 깊은 재귀 호출을 하거나 스택 영역에 수십 MB짜리 거대한 지역 변수 배열을 선언하면, 스택이 OS가 허용한 경계를 넘어버려 하드웨어 MMU가 Page Fault를 던지고, 커널은 해당 스레드가 속한 프로세스 자체를 Kill 해버린다 (Segfault). 이를 회피하기 위해 거대한 배열은 반드시 공유 자원인 Heap 영역에 할당(malloc, new)해야 한다.
스레드 로컬 누수: Java Spring 등에서 Thread Local Storage (TLS)에 사용자의 보안 인증 정보를 남기고 초기화(remove())하지 않으면, 스레드 풀에서 다음 번 재사용될 때 전혀 엉뚱한 사용자가 그 정보를 이어받는 대형 보안 사고가 터진다. 스레드 독립 자원은 생명주기가 끝날 때 반드시 정리되어야 한다.
📢 섹션 요약 비유: 개인 서랍(스택)에 물건을 너무 꽉 채워 넣어 서랍장이 터져버리면, 방 안의 다른 사람들(프로세스 내 다른 스레드)까지 모두 쫓겨나게 되는 것과 같다.

Ⅴ. 기대효과 및 결론

독립 자원은 프로세스 내에서 가벼운 형태의 격리를 제공하여, 문맥 교환에 걸리는 오버헤드를 마이크로초(us) 단위로 줄이면서도 여러 비동기 요청을 투명하게 처리할 수 있는 완벽한 구조를 선사한다.

미래에는 하드웨어 스레딩 (SMT)의 발전에 따라 CPU 코어 내에 물리적인 PC와 레지스터 셋을 다수 탑재하여 독립 자원의 스위칭 비용을 사실상 0으로 만드는 아키텍처, 혹은 유저 공간에서 컨텍스트를 극단적으로 줄이는 그린 스레드 (Green Thread) 기술로 양극화되며 발전할 것이다. 독립 자원은 "동시성이란 무엇인가"를 정의하는 가장 원초적인 메모리이자 지표로 남을 것이다.

📢 섹션 요약 비유: 스레드의 독립 자원은 무대 위 배우들의 각자 머릿속에 든 대본과 같아서, 모두가 한 무대(프로세스)에 서더라도 헷갈림 없이 자신만의 연기(실행)를 완벽하게 해낼 수 있게 해준다.

📌 관련 개념 맵

개념	연결 포인트
TCB (Thread Control Block)	스레드의 독립 자원인 PC, 레지스터 상태, TID를 보관하는 OS의 핵심 자료구조
스레드 풀 (Thread Pool)	매번 스택을 할당/해제하는 비용을 막기 위해 미리 독립 자원 세트를 만들어놓고 빌려 쓰는 패턴
재진입성 (Reentrancy)	동일 코드를 여러 스레드가 동시 실행해도 안전한 성질, 독립된 스택 구조 덕분에 보장됨
Thread Local Storage (TLS)	스레드마다 고유하게 할당되는 전역 상태 공간으로, 락(Lock) 없이 스레드 전용 데이터를 다룰 때 독립 자원처럼 쓰임

📈 관련 키워드 및 발전 흐름도

멀티 프로세싱 한계 (무거운 문맥 교환)
    │
    ▼
프로세스 내 공유 자원 분리 (Code, Data, Heap 공유)
    │
    ▼
스레드 독립 자원 확립 (TID, PC, Register, Stack)
    │
    ▼
스레드 풀 (Thread Pool) 및 TLS 최적화 적용
    │
    ▼
초경량 가상 스레드 (Virtual Thread) / 코루틴의 동적 스택 확장 진화

이 흐름도는 문맥 교환 비용을 낮추기 위해 하드웨어 레벨의 필수 자원만 남기고 공유하는 구조로의 발전을 보여준다.

👶 어린이를 위한 3줄 비유 설명

스레드 독립 자원은 공책 한 권(프로세스)을 친구들과 같이 쓸 때, "내가 어디까지 읽었지?" 표시하는 **개인용 책갈피 (PC)**와 같아요.
그리고 복잡한 계산을 할 때 남의 공책에 낙서하면 안 되니까, 각자 주머니에 넣어두고 쓰는 **나만의 작은 메모장 (Stack)**이기도 해요.
이 책갈피와 메모장이 스레드마다 따로따로 있기 때문에, 수십 명의 친구들이 한 방에 모여 있어도 각자 하던 일을 헷갈리지 않고 착착 해낼 수 있답니다!