294. 세그먼트 테이블 (Segment Table)

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

본질: 세그먼트 테이블 (Segment Table)은 세그멘트 번호를 실제 메모리 위치와 접근 규칙으로 바꾸는 주소 변환표이자 보호 정책표다.

가치: 각 세그먼트가 가변 길이이므로 Base (시작 주소), Limit (길이), Protection Bits (보호 비트)를 함께 관리해야 논리 구조와 메모리 보호를 동시에 성립시킬 수 있다.

판단 포인트: 세그먼트 테이블은 공유와 보호에는 강하지만, 세그먼트 수 증가·외부 단편화·변환 오버헤드가 커지면 단독 사용보다 페이징과의 혼용이 더 현실적이다.

Ⅰ. 개요 및 필요성

세그먼트 테이블은 세그멘테이션 (Segmentation) 환경에서 각 세그먼트의 시작 위치, 크기, 권한을 기록한 관리 표다. 프로그램은 코드, 데이터, 스택처럼 의미가 다른 영역으로 나뉘는데, 이들은 길이가 모두 다르므로 "몇 번 세그먼트가 어디서 시작하고 어디까지 유효한가"를 별도로 기억해야 한다. 바로 그 역할을 맡는 것이 세그먼트 테이블이다.

이 표가 필요한 이유는 논리 주소가 단순 숫자 하나가 아니라 (세그먼트 번호, 오프셋) 구조이기 때문이다. 운영체제와 하드웨어는 세그먼트 번호만 보고는 실제 메모리 위치를 알 수 없고, 오프셋이 허용 범위를 넘는지도 판단할 수 없다. 세그먼트 테이블이 없으면 주소 변환도 불가능하고, 다른 프로세스의 메모리를 침범하는 접근도 막기 어렵다.

특히 세그멘테이션은 "논리 단위별 보호"에 강점이 있다. 코드 세그먼트는 읽기/실행, 데이터 세그먼트는 읽기/쓰기, 스택 세그먼트는 아래 방향 성장처럼 서로 다른 정책을 줄 수 있는데, 이 정책의 집합이 세그먼트 테이블 엔트리 안에 담긴다. 즉 세그먼트 테이블은 단순 위치표가 아니라 메모리 경계선과 출입 규칙을 적어 둔 계약서다.

📢 섹션 요약 비유: 세그먼트 테이블은 건물 안내판이 아니라 "각 방의 위치, 크기, 출입 권한"까지 적힌 관리실 장부와 같다. 방 번호만 알아서는 부족하고, 어디까지 내 방인지와 들어가도 되는지도 함께 확인해야 안전하다.

Ⅱ. 아키텍처 및 핵심 원리

세그먼트 테이블의 핵심은 주소 변환보다 먼저 경계 검사를 수행한다는 점이다. 중앙처리장치인 CPU (Central Processing Unit)가 (s, d) 형태의 논리 주소를 내보내면, 메모리 관리 장치인 MMU (Memory Management Unit)는 먼저 세그먼트 번호 s가 유효한지, 다음으로 오프셋 d가 그 세그먼트 길이 안에 있는지 확인한다. 검사가 통과하면 최종 물리 주소는 Base + d로 계산된다.

이 과정에서 운영체제는 현재 프로세스의 세그먼트 테이블 위치를 STBR (Segment Table Base Register)에 넣고, 세그먼트 개수는 STLR (Segment Table Length Register)에 저장한다. 그래서 세그먼트 번호가 존재 범위를 벗어나면 테이블을 읽기도 전에 차단할 수 있다. 유효한 번호라면 MMU는 해당 엔트리에서 Base, Limit, 보호 비트, 존재 비트 같은 정보를 읽는다.

아래 그림은 세그먼트 테이블이 단순 조회표가 아니라, 번호 검사 → 엔트리 조회 → 경계/권한 검사 → 물리 주소 산출을 담당하는 흐름을 보여준다.

┌──────────────────────────────────────────────────────────────────────────────┐
│                 세그먼트 테이블 기반 주소 변환 및 보호 흐름                 │
├──────────────────────────────────────────────────────────────────────────────┤
│ 논리 주소 = (Segment s, Offset d)                                           │
│                                                                              │
│   CPU                                                                        │
│    │                                                                         │
│    ▼                                                                         │
│ [1] s < STLR ? ── 아니오 ───────────────▶ Trap                               │
│    │ 예                                                                     │
│    ▼                                                                         │
│ [2] STBR + s × 엔트리크기 ─────────────▶ 세그먼트 테이블 엔트리 읽기         │
│                                          ┌──────────────────────────────┐    │
│                                          │ Base │ Limit │ Prot │ Valid │    │
│                                          └──────────────────────────────┘    │
│    ▼                                                                         │
│ [3] d < Limit && 권한 허용 ? ─ 아니오 ─▶ Segmentation Fault                 │
│    │ 예                                                                     │
│    ▼                                                                         │
│ [4] Physical Address = Base + d                                             │
└──────────────────────────────────────────────────────────────────────────────┘

엔트리 필드	의미	설계상 중요 포인트
Base	세그먼트가 시작하는 물리 주소	재배치 시 값 변경 필요
Limit	허용 가능한 길이 또는 마지막 경계	범위 초과 접근 차단
Protection Bits	읽기/쓰기/실행 권한	코드/데이터 분리 보호
Valid / Present	현재 엔트리의 유효 여부	존재하지 않는 세그먼트 차단

성능 측면에서는 테이블 조회가 추가 메모리 접근을 만든다는 점이 부담이다. 그래서 자주 쓰는 엔트리는 TLB (Translation Lookaside Buffer)나 세그먼트 디스크립터 캐시에 보관해 반복 조회 비용을 줄인다. 그러나 페이지 테이블과 달리 각 엔트리가 길이와 권한까지 다뤄야 하므로, 주소 변환은 곧 보호 검사와 연결된다는 점이 더 본질적이다.

📢 섹션 요약 비유: 세그먼트 테이블은 택배 분류표가 아니라 출입 게이트가 달린 창고 명부다. 창고 번호만 찾는 데서 끝나지 않고, 상자가 허용된 칸 안에 있는지와 열어볼 권한이 있는지까지 확인한 뒤에야 통과시킨다.

Ⅲ. 비교 및 연결

세그먼트 테이블을 정확히 이해하려면 페이지 테이블 (Page Table)과 Base/Limit 레지스터를 함께 비교해야 한다. Base/Limit 레지스터는 하나의 연속 구간만 관리하므로 단일 프로그램 보호에는 단순하고 빠르다. 반면 세그먼트 테이블은 코드·데이터·스택처럼 여러 구간을 각각 다른 정책으로 관리할 수 있어 더 유연하지만, 엔트리 수와 관리 비용이 늘어난다.

페이지 테이블과의 차이는 더 분명하다. 페이지는 모든 단위가 같은 크기라서 "어느 프레임에 있느냐"가 핵심이고, 세그먼트는 크기가 가변이므로 "어디서 시작하고 어디까지가 한계냐"가 핵심이다. 그래서 페이지 테이블의 기본 정보가 프레임 번호라면, 세그먼트 테이블의 기본 정보는 Base와 Limit다.

비교 항목	세그먼트 테이블	페이지 테이블
분할 기준	코드/데이터/스택 같은 논리 단위	고정 크기 페이지
핵심 정보	Base + Limit + 권한	Page Frame Number (페이지 프레임 번호)
보호 방식	세그먼트 경계와 권한 중심	페이지 단위 매핑과 권한 중심
주요 문제	외부 단편화, 엔트리 관리 부담	내부 단편화, 큰 테이블 크기
사용자 관점	프로그램 구조와 잘 대응	하드웨어 친화적, 논리 의미는 약함

운영체제 관점에서는 세그먼트 테이블이 "논리 구조를 보존한 보호"를 제공하고, 페이징은 "물리 메모리 관리 효율"을 제공한다. 그래서 현대 시스템은 세그멘테이션을 순수하게 밀어붙이기보다, 세그먼트 수준의 권한 모델 위에 페이지 기반 실제 할당을 얹는 혼합 구조를 택했다. x86 계열에서 역사적으로 세그먼트 디스크립터가 보호 모델을 제공하고, 실제 대규모 주소 공간 관리는 페이징이 담당한 이유가 여기에 있다.

📢 섹션 요약 비유: 세그먼트 테이블은 "방별 사용 규칙이 있는 건물 관리", 페이지 테이블은 "규격 상자로 창고를 채우는 물류 관리"에 가깝다. 하나는 의미와 보호에 강하고, 다른 하나는 배치 효율에 강하다.

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

실무에서 세그먼트 테이블은 과거 메인 메모리 관리의 주역이었지만, 현대 범용 운영체제에서는 순수 세그멘테이션보다 보호 보조 장치 또는 역사적 호환 계층으로 더 자주 만난다. 그 이유는 세그먼트 수가 많아질수록 테이블 관리가 복잡해지고, 세그먼트 길이가 제각각이라 외부 단편화 (External Fragmentation)가 누적되기 때문이다. 즉 보호와 공유는 좋지만, 대규모 메모리 운영에서는 비용이 빠르게 커진다.

그럼에도 세그먼트 테이블적 사고는 여전히 중요하다. 공유 라이브러리를 여러 프로세스가 함께 쓰도록 설계할 때, 읽기 전용 코드 영역과 쓰기 가능한 데이터 영역을 분리할 때, 혹은 권한이 다른 메모리 구역을 명확히 나눌 때 세그먼트 관점이 직접적인 설계 기준이 된다. 실제 구현이 페이지 기반이더라도, "경계와 권한을 먼저 나눈다"는 판단은 세그멘테이션 철학을 그대로 계승한다.

실무 판단 체크리스트

보호 목적이 주된가, 아니면 대규모 메모리 배치 효율이 주된가?
세그먼트 수 증가가 테이블 조회 비용과 문맥 교환 부담을 감당 가능한 수준으로 유지하는가?
공유가 필요한 영역과 금지해야 할 쓰기 영역이 논리적으로 명확히 구분되는가?
외부 단편화가 커질 때 압축 (Compaction) 비용을 받아들일 수 있는가?

안티패턴

모든 객체를 잘게 세그먼트로 만들어 보호를 세밀하게 하려는 설계
권한 비트를 느슨하게 잡아 코드/데이터 분리 효과를 잃는 설정
보호 모델은 세그먼트식으로 설계했는데 실제 단편화 비용은 검토하지 않는 접근

기술사 관점에서는 "세그먼트 테이블이 왜 단독 표준이 되지 못했는가"를 설명할 수 있어야 한다. 답은 간단히 성능이 느려서가 아니라, 가변 길이의 아름다움이 곧 관리 복잡성과 외부 단편화 비용으로 되돌아오기 때문이다. 따라서 세그먼트 테이블은 보호와 공유의 원리를 설명할 때 채택하고, 실제 대규모 주소 공간 관리 해법으로는 페이징 혼용을 함께 제시하는 것이 균형 잡힌 답안이다.

📢 섹션 요약 비유: 맞춤 서랍장은 물건 성격별 정리에 좋지만, 물건 종류가 지나치게 많아지면 서랍 설명서부터 복잡해진다. 결국 정리 규칙은 맞춤형으로 가져가되, 실제 수납은 규격 상자와 섞어 쓰는 것이 현실적이다.

Ⅴ. 기대효과 및 결론

세그먼트 테이블의 가장 큰 효과는 메모리를 "연속 바이트 집합"이 아니라 "의미 있는 구역"으로 다루게 만든다는 점이다. 이 관점 덕분에 주소 변환과 메모리 보호가 분리되지 않고 함께 설계된다. 결과적으로 코드 공유, 읽기 전용 보호, 스택 경계 감시처럼 운영체제와 하드웨어가 협력해야 하는 기능을 직관적으로 설명할 수 있다.

반면 한계도 분명하다. 세그먼트가 가변 길이이므로 메모리 배치가 복잡하고, 연속 공간 요구 때문에 외부 단편화가 누적되며, 세그먼트가 많아지면 테이블 관리와 캐시 적중 관리가 어려워진다. 그래서 현대 시스템은 세그먼트 테이블의 철학은 유지하되, 실제 공간 배분은 페이지 중심으로 재구성하는 쪽으로 진화했다.

결국 세그먼트 테이블은 "주소를 적어 둔 목록"으로 기억하면 반쪽 이해다. 정확한 기억법은 논리 구역별 위치·경계·권한을 한 번에 정의하는 메모리 통제판이라는 것이다. 세그멘테이션 자체는 축소되었어도, 이 통제판 사고방식은 오늘날의 메모리 보호, 권한 분리, 안전한 실행 모델 속에 계속 살아 있다.

📢 섹션 요약 비유: 세그먼트 테이블은 집 주소록이 아니라 집 계약서에 가깝다. 어디 사는지만 적는 것이 아니라, 어느 방까지 쓸 수 있고 무엇을 해도 되는지까지 함께 정해 놓기 때문이다.

📌 관련 개념 맵

개념	연결 포인트
세그멘테이션 (Segmentation)	세그먼트 테이블이 직접 지원하는 논리 단위 메모리 관리 방식
Base/Limit 레지스터	세그먼트 테이블 엔트리의 핵심 필드를 이루는 기본 보호 메커니즘
STBR / STLR	현재 프로세스의 세그먼트 테이블 위치와 길이를 하드웨어에 알려 주는 제어 정보
TLB (Translation Lookaside Buffer)	자주 참조되는 세그먼트 엔트리를 캐싱해 변환 지연을 줄이는 장치
외부 단편화 (External Fragmentation)	가변 길이 세그먼트 배치가 남기는 대표적 운영 비용
페이징과 세그멘테이션 혼용	보호의 논리성과 배치 효율을 함께 얻기 위한 현대적 절충안

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

단일 Base/Limit 보호
    │
    ▼
세그멘테이션 (Segmentation)
    │
    ▼
세그먼트 테이블 (Segment Table)
    │
    ├──▶ 보호 비트 · 공유 세그먼트
    │
    ▼
TLB (Translation Lookaside Buffer) · 디스크립터 캐싱
    │
    ▼
페이징과 세그멘테이션 혼용
    │
    ▼
현대 메모리 보호 모델의 권한 분리 사고

이 흐름은 "단일 경계 보호 → 다중 논리 구역 관리 → 성능 보완 → 하이브리드 메모리 관리"로 발전하는 방향을 보여준다.

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

세그먼트 테이블은 학교에서 "몇 반이 어느 교실을 쓰고, 어디까지 써도 되는지" 적어 둔 배정표예요.
어떤 반이 자기 교실 밖 복도까지 책상을 놓으려고 하면 선생님이 바로 막아요.
그래서 모두가 자기 자리를 안전하게 쓰면서도, 필요한 교실은 함께 나눠 쓸 수 있어요.