116. 협력적 프로세스 (Cooperating Process) vs 독립적 프로세스 (Independent Process)

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

본질: 독립적 프로세스 (Independent Process)는 다른 프로세스의 실행이나 데이터에 어떠한 영향도 주고받지 않는 단독 실행 단위이며, 협력적 프로세스 (Cooperating Process)는 다른 프로세스와 데이터, 자원, 또는 실행 타이밍을 공유하며 상호 작용하는 프로세스다.

가치: 협력적 프로세스는 정보 공유, 연산 속도 향상, 모듈성, 사용자 편의성 등의 이유로 필요하며, 이를 실현하기 위해 IPC (Inter-Process Communication), 공유 메모리 (Shared Memory), 메시지 전달 (Message Passing) 등의 OS 수준 통신 메커니즘이 필수적으로 요구된다.

융합: 현대 분산 시스템에서 마이크로서비스 (Microservice) 간의 REST API/gRPC 통신, 컨테이너 오케스트레이션에서의 파드(Pod) 간 데이터 공유, 병렬 컴퓨팅에서의 MPI (Message Passing Interface) 기반 클러스터 통신은 모두 협력적 프로세스 간 통신의 대규모 확장 형태다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 운영체제에서 실행되는 프로세스는 그 성격에 따라 독립적 프로세스와 협력적 프로세스로 분류된다. 독립적 프로세스는 자신의 주소 공간(Address Space)과 자원을 완전히 독점하며, 다른 프로세스의 존재를 인식하거나 영향을 주지 않는다. 반면 협력적 프로세스는 의도적으로 다른 프로세스와 데이터나 자원을 공유하며 공동의 목표를 달성하기 위해 상호 작용한다.
필요성: 단일 프로세스로는 해결할 수 없거나 비효율적인 작업이 존재한다. 예를 들어 대규모 데이터를 병렬로 처리해야 하거나, 여러 프로세스가 동일한 데이터베이스에 접근해야 하거나, 생산자-소비자 패턴으로 파이프라인 처리를 수행해야 하는 경우에는 프로세스 간 협력이 필수적이다. 이러한 협력을 안전하고 효율적으로 구현하기 위해 운영체제는 다양한 IPC 메커니즘을 제공해야 한다.
💡 비유: 독립적 프로세스는 자기 집에서 혼자 요리하는 사람과 같아서 이웃이 뭘 하든 상관없지만, 협력적 프로세스는 공용 주방(공유 자원)에서 여러 요리사가 서로 재료를 주고받으며 한 번에 대규모 연회를 준비하는 팀과 같습니다.
등장 배경: 초기 일괄 처리 (Batch Processing) 시스템에서는 프로세스가 순차적으로 실행되므로 프로세스 간 협력의 필요성이 거의 없었다. 그러나 시분할 (Time-Sharing) 시스템과 다중 프로그래밍 (Multiprogramming) 환경으로 진화하면서, 여러 프로세스가 동시에 실행되고 서로 데이터를 교환해야 하는 요구가 대두되었다. 이에 따라 파이프 (Pipe), 메시지 큐 (Message Queue), 공유 메모리 (Shared Memory) 등의 IPC 메커니즘이 단계적으로 발전했다.

독립적 프로세스와 협력적 프로세스의 메모리 구조 차이를 시각화하면, 왜 협력적 프로세스에 특별한 통신 메커니즘이 필요한지 이해할 수 있다.

┌────────────────────────────────────────────────────────────────────┐
│       독립적 프로세스 vs 협력적 프로세스 메모리 구조 비교          │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  [독립적 프로세스 (Independent Process)]                           │
│                                                                    │
│  ┌───────────────────┐  ┌───────────────────┐                      │
│  │  프로세스 A        │  │  프로세스 B        │                    │
│  │  ┌─────────────┐  │  │  ┌─────────────┐  │                      │
│  │  │ Code        │  │  │  │ Code        │  │                      │
│  │  │ Data (독립) │  │  │  │ Data (독립) │  │                      │
│  │  │ Heap (독립) │  │  │  │ Heap (독립) │  │                      │
│  │  │ Stack       │  │  │  │ Stack       │  │                      │
│  │  └─────────────┘  │  │  └─────────────┘  │                      │
│  └───────────────────┘  └───────────────────┘                      │
│        ↕ 완전 분리, 서로 접근 불가                                 │
│                                                                    │
│  [협력적 프로세스 (Cooperating Process)]                           │
│                                                                    │
│  ┌───────────────────┐  ┌───────────────────┐                      │
│  │  프로세스 A        │  │  프로세스 B        │                    │
│  │  ┌─────────────┐  │  │  ┌─────────────┐  │                      │
│  │  │ Code        │  │  │  │ Code        │  │                      │
│  │  │ Data        │  │  │  │ Data        │  │                      │
│  │  │ Heap        │──│──│──│ Heap        │  │ ← 공유 영역          │
│  │  │ Stack       │  │  │  │ Stack       │  │                      │
│  │  └──────┬──────┘  │  │  └──────┬──────┘  │                      │
│  └─────────┼─────────┘  └─────────┼─────────┘                      │
│            │    IPC 메커니즘 필요!  │                              │
│            └────────┬─────────────┘                                │
│                     ▼                                              │
│         [OS IPC: 파이프/공유메모리/메시지큐/소켓]                  │
└────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 구조도는 독립적 프로세스와 협력적 프로세스의 가장 결정적인 차이인 "메모리 공간의 분리와 공유"를 보여준다. 독립적 프로세스의 주소 공간은 MMU (Memory Management Unit)에 의해 하드웨어적으로 완전히 격리되어 있으므로, 프로세스 A가 프로세스 B의 메모리에 접근하려 하면 Segmentation Fault가 발생한다. 반면 협력적 프로세스는 운영체제가 제공하는 IPC 메커니즘(공유 메모리, 파이프, 메시지 큐 등)을 통해 간접적으로 데이터를 교환할 수 있다. 특히 공유 메모리 방식에서는 두 프로세스의 가상 주소 공간 일부가 동일한 물리 메모리 페이지에 매핑되므로, 포인터를 통한 직접적인 데이터 접근이 가능해진다. 이때 운영체제는 이 공유 영역에 대한 동기화(Synchronization) 수단을 별도로 제공해야 한다.

📢 섹션 요약 비유: 독립적 프로세스는 각자 방이 잠긴 독립된 호텔 방들이라 서로 들어갈 수 없지만, 협력적 프로세스는 호텔 로비(OS IPC)를 통해 서로 물건을 전달하거나 공용 회의실(공유 메모리)을 함께 사용하는 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

협력적 프로세스의 네 가지 필요성

필요성	설명	실무 예시	비유
정보 공유 (Information Sharing)	여러 프로세스가 동일한 데이터에 동시 접근해야 함	여러 앱이 동시에 접근하는 공유 설정 데이터베이스	팀원들이 같은 문서를 편집
연산 속도 향상 (Computation Speedup)	작업을 하위 작업으로 분할하여 여러 CPU에서 병렬 실행	대규모 과학 계산, 영상 렌더링의 분산 처리	여러 사람이 퍼즐 조각을 동시에 맞춤
모듈성 (Modularity)	시스템을 독립적인 모듈로 분할하여 유지보수성 향상	컴파일러(어휘 분석→구문 분석→코드 생성) 파이프라인	자동차 조립 라인의 공정 분할
편의성 (Convenience)	단일 시스템이 여러 작업을 동시에 수행하도록 지원	복사-붙여넣기 버퍼, 셸 파이프라인(cmd1 \| cmd2)	한 사람이 동시에 청소와 빨래를 돌림

프로세스 간 협력의 형태

협력적 프로세스는 통신 방식에 따라 공유 메모리 기반과 메시지 전달 기반으로 나뉜다. 다음은 두 가지 방식의 동작 구조를 비교한 것이다.

┌────────────────────────────────────────────────────────────────────┐
│           협력적 프로세스의 두 가지 통신 모델                      │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  [공유 메모리 모델 (Shared Memory)]                                │
│                                                                    │
│  ┌───────────┐                         ┌───────────┐               │
│  │ 프로세스 A │──── 쓰기 (Write) ────▶ │  공유      │              │
│  │           │◀─── 읽기 (Read) ───── │  메모리    │                │
│  └───────────┘                         │  영역      │              │
│                                        └─────▲─────┘               │
│  ┌───────────┐                               │                     │
│  │ 프로세스 B │──── 읽기/쓰기 ────────────────┘                    │
│  │           │                                                     │
│  └───────────┘                                                     │
│  특징: 빠름, 동기화(뮤텍스/세마포어) 필수, 메모리 누수 위험        │
│                                                                    │
│  ─────────────────────────────────────────────                     │
│                                                                    │
│  [메시지 전달 모델 (Message Passing)]                              │
│                                                                    │
│  ┌───────────┐    send(msg)    ┌─────────┐   recv(msg)             │
│  │ 프로세스 A │───────────────▶ │  OS     │───────────▶ ┌──┐       │
│  │ (송신자)   │                │ 커널    │              │B │       │
│  └───────────┘                │ 메시지  │◀──────────── └──┘        │
│                               │ 큐     │   send(reply)             │
│                               └─────────┘                          │
│  특징: 안전(커널이 중개), 속도 느림(커널 개입), 구현 단순          │
│                                                                    │
│  ┌────────────────────────────────────────────────────────┐        │
│  │ 트레이드오프:                                           │       │
│  │  공유 메모리 = "직접 대화" (빠르지만 충돌 위험)            │    │
│  │  메시지 전달 = "우편 배달" (안전하지만 지연 발생)            │  │
│  └────────────────────────────────────────────────────────┘        │
└────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 두 통신 모델의 핵심 차이는 "커널의 개입 정도"다. 공유 메모리 모델에서는 프로세스들이 직접 공유된 메모리 영역에 읽고 쓰므로 커널의 개입이 최소화되어 속도가 빠르지만, 동시에 두 프로세스가 같은 데이터를 수정할 때 데이터 일관성(Data Consistency)이 깨지는 경합 조건 (Race Condition)이 발생할 수 있다. 따라서 뮤텍스 (Mutex)나 세마포어 (Semaphore) 같은 동기화 도구가 반드시 필요하다. 반면 메시지 전달 모델에서는 모든 데이터가 커널을 경유하여 전달되므로 프로세스 간의 메모리 공유가 없어 경합 조건이 원천적으로 발생하지 않지만, 매 메시지마다 시스템 콜과 커널 모드 전환이 발생하므로 속도가 상대적으로 느리다.

협력적 프로세스가 OS 설계에 미치는 영향

협력적 프로세스의 존재는 운영체제 설계에 근본적인 영향을 미친다. 운영체제는 다음 기능을 반드시 제공해야 한다.

IPC 메커니즘: 파이프, 메시지 큐, 공유 메모리, 소켓 등 프로세스 간 통신 수단
동기화 도구: 세마포어, 뮤텍스, 조건 변수 등 공유 자원의 동시 접근 제어
자원 보호: 한 프로세스가 공유 자원을 파괴하더라도 다른 프로세스에 영향을 최소화하는 보호 메커니즘

📢 섹션 요약 비유: 공유 메모리는 여러 사람이 같은 화이트보드에 동시에 글씨를 쓰는 것(빠르지만 지저분해질 수 있음)이고, 메시지 전달은 우편물을 주고받는 것(안전하지만 배달 시간 걸림)과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

독립적 vs 협력적 프로세스 심층 비교

비교 항목	독립적 프로세스 (Independent)	협력적 프로세스 (Cooperating)	실무 판단 포인트
주소 공간	완전히 분리됨	공유 메모리 또는 IPC로 연결	데이터 공유 필요 여부
실행 순서	임의 순서로 실행 가능	타이밍에 의존적인 순서 보장 필요	작업 간 선후관계 존재 여부
결과 예측	항상 동일 (결정론적)	실행 순서에 따라 결과 다를 수 있음	결과의 재현성 요구 여부
OS 지원 필요성	기본 스케줄링만으로 충분	IPC, 동기화, 보호 메커니즘 필수	시스템 설계 복잡도
오류 전파	독립적, 다른 프로세스에 영향 없음	한 프로세스 오류가 시스템 전체로 확장 가능	장애 격리 요구사항

협력적 프로세스 간의 생산자-소비자 (Producer-Consumer) 관계를 시각화하면, 프로세스 간 협력이 왜 필요한지 구체적으로 이해할 수 있다.

┌──────────────────────────────────────────────────────────────────────┐
│     협력적 프로세스의 전형적 예: 생산자-소비자 (Producer-Consumer)   │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌────────────┐    데이터 생성    ┌──────────────────────┐           │
│  │  생산자 A   │──────────────▶  │    공유 버퍼          │           │
│  │ (Producer) │                 │  ┌───┬───┬───┬───┐   │             │
│  └────────────┘                 │  │ 5 │ 3 │ 8 │   │   │             │
│                                 │  └───┴───┴───┴───┘   │             │
│  ┌────────────┐                 │  (데이터를 쌓아두는 곳) │          │
│  │  생산자 B   │──────────────▶  └──────────┬───────────┘            │
│  │ (Producer) │                             │                        │
│  └────────────┘                             │                        │
│                              ┌──────────────▼───────────┐            │
│                              │    소비자 (Consumer)       │          │
│                              │    데이터를 가져가 처리     │         │
│                              └──────────────────────────┘            │
│                                                                      │
│  필수 규칙:                                                          │
│  1. 버퍼가 가득 차면 생산자는 대기 (동기화)                          │
│  2. 버퍼가 비면 소비자는 대기 (동기화)                               │
│  3. 생산자와 소비자는 동시에 버퍼에 접근하면 안 됨 (상호배제)        │
│                                                                      │
│  이 규칙을 OS가 강제하는 도구: 세마포어(Semaphore), 뮤텍스(Mutex)    │
└──────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 생산자-소비자 패턴은 협력적 프로세스의 가장 대표적인 응용 사례다. 여러 생산자 프로세스가 데이터를 생성하여 공유 버퍼에 넣고, 소비자 프로세스가 버퍼에서 데이터를 꺼내 처리한다. 이 과정에서 세 가지 핵심 동기화 규칙이 필요하다. 첫째, 버퍼가 가득 찼을 때 생산자는 더 이상 데이터를 넣을 수 없으므로 대기해야 한다(오버플로우 방지). 둘째, 버퍼가 비어있을 때 소비자는 데이터를 꺼낼 수 없으므로 대기해야 한다(언더플로우 방지). 셋째, 생산자와 소비자가 동시에 버퍼에 접근하면 데이터 일관성이 깨지므로 상호 배제 (Mutual Exclusion)가 보장되어야 한다. 이 세 가지 조건을 운영체제가 제공하는 세마포어(또는 뮤텍스)를 통해 구현하는 것이 협력적 프로세스 설계의 핵심이다.

과목 융합 관점

데이터베이스 (DB): 협력적 프로세스 간의 동시 접근 문제는 데이터베이스의 트랜잭션 격리 수준 (Isolation Level)과 트랜잭션 동시성 제어 (Concurrency Control)의 근간이다. 난 읽기 (Dirty Read), 반복 불가능 읽기 (Non-repeatable Read), 팬텀 읽기 (Phantom Read) 등의 문제는 프로세스 간 데이터 공유에서 발생하는 경합 조건과 본질적으로 동일하다.
네트워크 (Network): 분산 시스템에서의 협력적 프로세스 통신은 네트워크 프로토콜(TCP/IP 소켓)을 통해 구현된다. 로컬 IPC는 네트워크 통신의 특수한 경우(루프백)로 간주할 수 있으며, 두 환경 모두에서 메시지 순서 보장, 신뢰성, 흐름 제어가 핵심 설계 요구사항이다.
📢 섹션 요약 비유: 협력적 프로세스는 마치 오케스트라 단원들처럼 각자 악기를 연주하면서도 지휘자(OS의 동기화 도구)의 박자에 맞춰 조화로운 음악(협력적 결과)을 만들어내는 것과 같습니다.

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

실무 시나리오

시나리오 -- 다중 프로세스 웹 서버의 세션 데이터 공유: 여러 Nginx 워커 프로세스가 사용자 세션 정보를 각자의 메모리에 저장하여, 로드 밸런서를 통해 다른 워커로 요청이 전달되면 세션이 유실되는 문제.
- 판단: 독립적 프로세스 구조에서 발생하는 전형적인 정보 공유 한계다. 해결책으로 Redis와 같은 공유 메모리 기반 외부 세션 스토어를 도입하여, 모든 워커가 동일한 세션 데이터에 접근할 수 있도록 협력적 프로세스 구조로 전환해야 한다. 이때 Redis의 원자적 연산(SET, GET)이 동기화 메커니즘 역할을 한다.
시나리오 -- 파이프라인 병렬 처리의 모듈성 설계: 대규모 비디오 트랜스코딩 시스템에서 인코딩(Producer), 필터링, 패키징(Consumer)을 각각 독립 프로세스로 분리하고, 파이프(Pipe)로 연결하여 모듈성과 장애 격리를 동시에 달성.
- 판단: 협력적 프로세스의 모듈성 원칙을 적극 활용한 올바른 설계다. 각 단계를 독립 프로세스로 분리하면 한 단계의 장애가 다른 단계로 전파되는 것을 막을 수 있고(장애 격리), 개별 모듈을 독립적으로 업데이트하거나 확장할 수 있다(모듈성). 파이프를 통한 메시지 전달은 커널이 버퍼를 관리하므로 동기화 오버헤드를 최소화하면서 안전한 통신을 보장한다.

협력적 프로세스 설계 시 통신 모델 선택을 위한 의사결정 흐름을 요약한다.

┌─────────────────────────────────────────────────────────────────────┐
│      협력적 프로세스 통신 모델 선택 의사결정 트리                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   [프로세스 간 데이터 교환 설계]                                    │
│                │                                                    │
│                ▼                                                    │
│       통신 대상이 동일한 머신 내에 있는가?                          │
│          ├─ 예 ─────▶ 데이터 전송 속도가 성능 병목인가?             │
│          │                │                                         │
│          │                ├─ 예 ──▶ [공유 메모리 (Shared Memory)]   │
│          │                │                 │                       │
│          │                │                 └─▶ 동기화 필수         │
│          │                │                                         │
│          │                └─ 아니오 ─▶ [메시지 큐 / 파이프]         │
│          │                                │                         │
│          │                                └─▶ 구현 단순             │
│          │                                                          │
│          └─ 아니오 (네트워크 경유)                                  │
│                │                                                    │
│                ▼                                                    │
│       신뢰성이 중요한가?                                            │
│          ├─ 예 ──▶ [TCP 소켓 / gRPC]                                │
│          │                │                                         │
│          │                └─▶ 순서 보장, 재전송                     │
│          │                                                          │
│          └─ 아니오 ──▶ [UDP 소켓 / 멀티캐스트]                      │
│                           │                                         │
│                           └─▶ 속도 우선, 손실 허용                  │
│                                                                     │
│  핵심: 성능(공유메모리) vs 안전성(메시지전달) vs 거리(소켓)         │
└─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 의사결정 트리는 협력적 프로세스 간 통신 모델을 선택할 때 고려해야 할 세 가지 핵심 축(거리, 성능, 신뢰성)을 명확히 보여준다. 동일한 머신 내에서 대량의 데이터를 고속으로 교환해야 하는 경우(예: 비디오 프레임 처리)에는 공유 메모리가 최적이지만, 동기화 로직이 복잡해진다는 트레이드오프를 감수해야 한다. 네트워크를 경유하는 경우에는 소켓 기반 통신이 필수이며, 데이터 손실이 허용되지 않는 금융 거래 시스템에서는 TCP 기반의 신뢰성 높은 통신을 선택하고, 실시간 스트리밍 같은 지연 민감 시스템에서는 UDP 기반의 빠른 통신을 선택해야 한다.

도입 체크리스트

기술적: 협력적 프로세스 간 공유 자원에 대한 경합 조건(Race Condition) 가능성을 모두 식별했는가? 동기화 도구(뮤텍스, 세마포어)가 올바르게 적용되어 데드락(Deadlock)이 발생하지 않는가?
운영·보안적: 협력적 프로세스 중 하나가 악의적으로 공유 메모리를 오염시킬 경우, 다른 프로세스에 미치는 영향을 최소화하는 샌드박스(Sandbox) 또는 메모리 보호(Memory Protection)가 적용되어 있는가?
📢 섹션 요약 비유: 공용 부엌에서 요리할 때는 조리법(동기화 규칙)을 엄격히 지키지 않으면 음식이 뒤섞여 망치듯이, 협력적 프로세스도 명확한 규칙 없이 자원을 공유하면 데이터가 엉망이 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	독립적 프로세스만 사용	협력적 프로세스 + IPC 도입	개선 효과
정량 (연산 속도)	단일 CPU 코어 활용	다중 코어 병렬 연산	처리량 N배 증가 (N=코어 수)
정량 (데이터 일관성)	각 프로세스가 데이터 복제본 유지	공유 스토어로 중복 제거	메모리 소모 60~80% 절감
정성 (모듈성)	단일 거대 프로세스 (Monolith)	독립 모듈 분리, 장애 격리	유지보수성 및 장애 격리 획득

미래 전망

마이크로서비스 아키텍처와 협력적 프로세스의 확장: 클라우드 네이티브 환경에서는 협력적 프로세스의 개념이 단일 머신을 넘어 수백 대의 서버로 확장되었다. Kubernetes의 파드(Pod) 내 컨테이너 간 공유 네임스페이스, 서비스 메시(Service Mesh)를 통한 gRPC 통신은 협력적 프로세스의 클라우드 규모 구현이다.
공유 메모리의 하드웨어 가속: RDMA (Remote Direct Memory Access)와 CXL (Compute Express Link) 기술이 발전하면서, 네트워크를 경유하더라도 메시지 전달의 커널 개입을 우회하고 원격 메모리에 직접 접근하는 기술이 상용화되고 있다. 이는 협력적 프로세스 간의 통신 속도를 극적으로 향상시킨다.
📢 섹션 요약 비약: 협력적 프로세스는 오케스트라의 단원들처럼 각자 독립적인 역할을 수행하면서도 지휘자(OS 동기화)의 통제 아래 하나의 완성된 결과물을 만들어내며, 이 패턴은 클라우드 시대의 마이크로서비스로 진화하여 더 큰 규모로 확장되고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
IPC (Inter-Process Communication)	협력적 프로세스가 데이터를 교환하기 위해 운영체제가 제공하는 핵심 통신 인프라로, 파이프, 메시지 큐, 공유 메모리, 소켓 등의 기법을 포괄한다.
세마포어 (Semaphore)	협력적 프로세스가 공유 자원에 동시 접근할 때 발생하는 경합 조건을 제어하기 위해 Edsger Dijkstra가 제안한 동기화 도구다.
생산자-소비자 문제 (Producer-Consumer)	협력적 프로세스의 가장 전형적 동작 패턴으로, 생산자가 데이터를 생산하고 소비자가 소비하는 파이프라인 구조에서 동기화의 필요성을 보여준다.
경합 조건 (Race Condition)	협력적 프로세스가 공유 자원에 동시 접근할 때 실행 순서에 따라 결과가 달라지는 현상으로, 동기화 도구로 방지해야 하는 핵심 문제다.
마이크로서비스 (Microservice)	협력적 프로세스의 클라우드 규모 확장 형태로, 독립 배포 가능한 서비스들이 네트워크 기반 메시지 전달(API)로 협력하는 분산 시스템 아키텍처다.

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

독립적 프로세스는 각자 자기 방에서 혼자 노는 아이들이라서 친구가 뭘 하든 상관없지만, 협력적 프로세스는 같은 놀이터에서 모래성(공유 데이터)을 함께 만드는 친구들이에요.
함께 모래성을 만들 때는 "내가 먼저 쌓을게!" 하고 차례를 정하지 않으면(동기화) 모래성이 무너지거나 엉망이 될 수 있어서, 선생님(OS)이 규칙을 정해줘야 해요.
이렇게 여러 프로세스가 협력하면 혼자 하는 것보다 훨씬 빠르고 멋진 결과물을 만들 수 있어서, 요즘 컴퓨터 시스템은 수많은 프로세스가 서로 도우며 일하도록 만들어진답니다!