IEEE TRANSACTIONS ON CLOUD COMPUTING Wenbiao Cao, Xiaoyong Tang, Tan Deng, Ronghui Cao, and Keqin Li https://ieeexplore.ieee.org/abstract/document/11143954

연구 배경

AIoT 발전으로 MEC(Multi-access Edge Computing) 중요성 증대

AIoT와 IoT의 발전으로 데이터 소스와 가까운 위치에서 분산 연산 수요 및 지연 민감 서비스 급증

엣지 컴퓨팅은 코어 혼잡 완화 및 QoS 향상에 효과적 그러나, 엣지 환경은 다음과 같은 한계 존재

• 자원 이질성(Heterogeneity)
• 자원 경쟁(Resource competition)
• 마감시간 제약(Deadline Constraints)

핵심 과제 : 제한된 이질적 리소스와 동적 요구사항의 충돌

해당 논문의 Edge-Node에 대한 정의

Firstly, edge nodes have obvious heterogeneity in terms of resource type, performance, and architecture. Secondly, resource competition is widely present in edge networks.

Such as gateways(access points), local servers, small data centers, and even high-performance terminal devices are geographically distributed.

관련 연구로 보는 주요 문제점

Task Dispatching and Scheduling in Edge Computing

대부분 정적인 태스크 처리 시간을 가정하며, 동적 자원 변화 및 경쟁 상황은 충분히 고려하지 못함

Heterogeneous Scheduling with Deadline Constraints

대부분 정적 자원 할당(static allocation) 기반이며, 온라인 자원 경쟁(online resource competition) 은 다루지 않음

Resource-aware Dynamic Task Scheduling

대부분 오프라인 모델에 의존하고 있으며, 이는 실제 동적 변화를 시의적절하게 반영할 수 없음

따라서 자원 인식(Resource-aware) 관점에서 동적 스케줄링 알고리즘을 제안하여 데드라인을 만족하면서 시스템 자원 효율을 높이고자 함

핵심 아이디어

RATGS(Resource-Aware Task Grouping Scheduling Strategy)

제한된 리소스로 최대한 많은 요청을 완료하는 것이 목표 데드라인 제약이 있는 태스크의 효과적인 스케줄링에 초점

1. Task Regrouping & Priority Response (Algorithm 1)
2. Resource-aware Greedy Scheduling (Algorithm 2)
3. Task Adjusting (DI/HRI/MRR, Algorithm 3)
4. Rescheduling (Algorithm 4)

   핵심 목표

   

식(2) => 연산 능력 가용 검사 식(3) => 메모리 가용 검사 *현재 사용중인 {컴퓨팅 파워, 메모리} + 할당하려는 CU의 {컴퓨팅 파워, 메모리} <= 엣지 노드의 총 {컴퓨팅 파워, 메모리} 용량 *

Algorithm

Regrouping의 필요성

초기에는 태스크들이 도착 시간(Arrival Time) 기준으로 단순 저장되기 때문에, 서비스 유형과 자원 요구가 뒤섞여 스케줄링 효율이 저하 -> 태스크를 서비스 유형(Service Type) 및 긴급도(Urgency) 기준으로 Regrouping

Algorithm 1

1. 태스크를 도착 시간에 따라 타이밍 그룹으로 분할
2. 각 타이밍 그룹의 태스크를 서비스 타입별 컴퓨터 그룹(X_h)에 매핑
3. 그 그룹의 기존 대기열의 각 태스크의 우선순위 및 평균 처리시간 계산
4. 우선순위 값에 따라 새 대기열 생성
5. 해당 서비스가 엣지에서 처리될 수 없으면 리모트 클라우드로 전송

Algorithm 2

즉시 가용 리소스가 있는 경우 (line 1~9)

• 가장 빠른 완료 시간을 가진 노드에 그리디 스케줄링 (line8~9)

리소스가 가득 찬 경우 (line 10~27)

• 각 슬롯 노드에 할당하여 EFT(Earliest Finish Time) 계산 (line 11~13)

데드라인 미충족 시 (line 14~27)

• 태스크 조정 호출 (line18~21)
• 실행가능한 솔루션이 없으면 리모트 클라우드로 스케줄링 (line22~25)

Algorithm 3

1. Direct Insertion(DI) (line 1~6) 새로운 태스크를 기존 실행 큐(PreScheme) 중간에 삽입하여 데드라인을 만족할 수 있는 위치를 찾음 특징 : 파편화된 리소스 활용하여 자원 낭비 감소 효과 : 데드라인 만족률 증가 2. Highest Reward Insertion(HRI) (line 7~15) 단순히 데드라인만 보는게 아닌 LTSS가 더 커지는 방향으로 태스크를 선택/재배치 특징 : Slack time을 활용하여 기다리면 더 가치있는 태스크를 살림 효과 : 전체 시스템 효용 극대화 3. Maximum Reward Replacement(MRR) (line 16~20) 가장 적은 재배치로 데드라인을 만족시키는 대안 탐색 특징 : 큰 구조 변경 없이 효율성 확보 효과 : 안정적이고 현실적인 조정 가능

Algorithm 4

Deadline 위반 태스크를 가장 빠른 EFT 노드로 재할당하여 CRD를 향상 시키는 것을 목표

가용 노드 집합 (AvaNodes) 생성 및 EFT 평가 (line 16) EFT 최소 노드 선정 (line 78) Deadline이내면 노드 갱신 및 우선순위 계산 (line 913) 충족 불가 시 리모트 클라우드로 전송 (line 1417)

실험 환경

워크로드

실제 애플리케이션 이미지 처리, ALU 논리 연산, 부동소수점 연산, 얼굴 매칭 등 Python으로 작성된 여러 프로그램 사용

시뮬레이션 데이터셋 알리바바 클라우드 실제 트레이스 데이터 활용 밀도 데이터셋 : 8개 서브셋 (밀도 1~8), 각 약 10,000개 태스크 분포 데이터셋 : 3개 서브셋 (다양한 분포), 각 약 25,000개 태스크

각 태스크 디스패처는 서로 다른 종류의 애플리케이션을 실행 각 디스패처는 50100ms 간격으로 01개의 태스크를 오프로딩

각 요청은 입력 메타데이터, 예상 마감시간 (Deadline), 긴급 여부(Expedited Flag)에 대한 정보 포함

서비스 인스턴스는 모두 pre-warmed 상태로 설정

평가지표

CRD(Completion Rate before Deadline) LTSS(Long-Term Satisfaction of System Service) ACT(Average Completion Time) Resource Utilization + RU Efficiency

비교 대상

• Dedas : 노드의 스케줄을 순차적으로 순회하여 작업에 적합한 삽입 위치 탐색삽입 불가 시, 총 완료 시간을 비용 요소로 고려하여 최적의 스케줄을 얻기 위해 작업을 교체
• RTH2S : 노드를 계층화하여 3단계 우선순위 큐와 EDF(Earliest Deadline First) 방식으로 스케줄링
• LSPT (LeastLoad + SRPT) : 부하가 가장 낮은 노드에 태스크를 보내고, 남은 처리시간이 짧은 순으로 실행
• LEDF (LeastLoad + EDF) : 부하 최소 + 가장 빠른 마감시간 순서로 태스크 할당
• SF (Self + FCFS) : 태스크가 스스로 가장 빠른 완료시간을 예측하여 FCFS로 실행

  실험 결과

  테스트베드

  

태스크 도착 밀도

태스크 분포

태스크가어떤 분포로 도착하여도 RATGS가 CRD가 가장 높은 것을 확인 가능 태스크 도착 불확실성을 반영하기 위한 시뮬레이션

컴퓨터 유닛 수에 따른 데드라인 미스율

RATGS : 22 CU에서 99.9% 완료 (가장 빠름) 다른 전략 : 더 많은 CU 필요 LSPT/LEDF : CU증가해도 ~80% 완료 즉, RATGS는 자원이 부족한 상황일수록 성능 우위 확인 가능

컴퓨터 유닛 수에 따른 LTSS

컴퓨팅 유닛 수가 30에 도달하면 각 스케줄링 전략의 성능이 가장 좋아지는 경향이 있지만, 22 미만이면 RATGS의 성능이 LTSS 지표에서 모든 전략보다 우수

컴퓨터 유닛 수에 따른 ACT

컴퓨팅 유닛 수가 30을 초과하고 점진적으로 증가함에 따라 RATGS는 ACT에서 Dedas보다 약간 더 나은 성능을 보이기 시작 컴퓨팅 유닛 수가 증가함에 따라 최적의 스케줄링을 달성하기 위한 작업 조정 공간과 선택 사항이 더 넓어지기 때문

리소스 활용

RU(Resource Utilization) LSPT/LEDF: 평균 80% 이상 (최고) ->로드밸런싱 계열 RATGS: 고밀도 시 높음, 저밀도 시 낮음 RUE (RU Efficiency = CRD/RU) RATGS: 대조적 상황에서 최고 RUE 적은 리소스로 더 많은 태스크 완료 핵심발견 엣지 환경과 같은 자원이 제한된 환경에선 RUE가 더 중요한 지표 단순 활용보다 활용 효율성이 중요 RATGS는 제한된 리소스를 가장 효율적으로 활용

연구의 핵심 성과

• 이질적 자원 환경을 현실적으로 모델링
  • 노드별 성능, 메모리, 대역폭 등을 구체적으로 고려
• 다항시간 복잡도의 휴리스틱 솔루션 제시
  • NP-hard 문제를 O(n²) 내에서 근사적으로 해결
• 마감시간 제약과 자원 경쟁을 동시에 고려한 스케줄링 정식화
  • LTSS와 CRD를 통합적으로 최적화
• 단순한 RU보다 RUE의 성능지표로서의 가치
  • 자원이 한정된 환경에서 RUE가 성능지표로 더 적합한 것을 확인

    연구의 한계점 및 향후 연구

• 태스크 간 종속성 미고려
• 에너지 소비와 콜드 스타트로 인한 서비스 지연 무시

향후 연구

• 태스크 간 선후 관계를 반영한 스케줄링 모델
• 에너지 효율성 고려

문제 제기 및 연구의 필요성

기존 모델의 한계와 PTN 지원의 부재

상업 클라우드 서비스 제공 업체들의 대표적인 세 가지 가격 모델은 온디맨드, 예약, 스팟 인스턴스로 나눌 수 있음 이 중 온디맨드와 예약 인스턴스는 고정된 가격을 지불해야하며 유동성이 적음. 스팟 인스턴스는 비용 절약이 가능하지만 서비스 시작, 종료 시점 계획이 어렵고 최대 입찰 가격 초과 시 경고 없이 인스턴스가 종료되는 큰 단점이 존재함

이로 인해 중단 없이 선호하는 시간대 예약을 위한 협상 메커니즘이 필요한데, 아직까지 서비스 가격과 시간대 협상을 자동화하는 메커니즘이 없음 따라서 연구를 통해 Price and Time slot Negotiation(PTN) 메커니즘을 개발함

연구 목표

1. 시간대 선호도를 특성화하는 새로운 효용함수를 포함한 PTN 메커니즘 개발
2. 소비자와 제공자의 협상 전략을 위한 절충 및 양보 알고리즘 설계
3. 에이전트 기반 클라우드 테스트베드 구현
4. 실험을 통한 PTN 메커니즘 평가
5. 클라우드 리소스 가격 책정에 PTN 메커니즘 적용 사례 연구

   핵심 아이디어

   PTN(Prcie-Time-Slot Negotiation)

   가격과 시간대를 동시에 고려하는 통합 협상 시스템
6. 효용 함수 설계 a. 가격 효용 + 시간대 효용 = 총 효용 b. 개별 선호도를 정량적으로 표현
7. 스마트 협상 전략 a. 절충 및 시간의존적 양보 알고리즘으로 효율성 증대 b. 버스트 모드로 선택권 확대
8. 협상 프로토콜 a. Rubinstein's alternating offers protocol

   핵심 해결책

   협상 방식

   기존 방식 한 번에 하나의 제안만 가능 상대방이 거절하면 다음 라운드까지 대기

   VS

   버스트 모드 한 번에 총 효용이 같은 제안을 동시에 제시 기존 방식보다 빠른 합의에 도달

   효용함수

   기존방식 사용자의 다양한 시간대 선호도 반영 불가 시간대를 단순히 마감 기한 내에 있는지 여부만 확인

   vs

   새로운 시간대 효용 함수 비선형 함수로 복잡한 시간 선호도 표현 가능 소비자 : 선호하는 여러 시간대 구간을 자유롭게 설정 가능 공급자 : 수요 예측, 리소스 활용도, 시간 순서를 종합 고려

효용 함수

가격 효용함수

소비자 가격 효용 함수 공급자 가격 효용 함수

시간대 효용 함수

소비자 시간대 효용 함수

공급자 시간대 효용 함수

총 효용 함수

실험 환경

에이전트 기반 클라우드 테스트베드

Java 및 JADE(Java Agent Development) 프레임워크를 사용하여 설계하고 구현

모든 에이전트는 JADE Directory Facilitator를 통해 구현된 클라우드 시장 등록소에 등록 등록소에 등록된 소비자 에이전트는 제공자 에이전트를 인식하고 상호 통신 가능 사용자는 GUI를 통해 서비스 이름, 가격, 시간대, 협상 전략 등 서비스에 대한 선호도를 지정하고 에이전트를 생성 가능

실험 결과

(a) λC =3.0, λP =3.0, τC =50,andτP =50. (b)λC =3.0,λP =3.0,τC = 200,andτP = 200. (c) λC =1/3, λP =1/3, τC =50, andτP =50. (d)λC =1/3, λP =1/3, τC = 200, andτP = 200. (e)λC =3.0, λP =1/3, τC =50, and τP =200. (f) λC =1/3, λP =3.0, τC =50, andτP = 200. (g)λC =3.0, λP =1/3, τC = 200,andτP =50. (h)λC =1/3, λP =3.0, τC =200,andτP =50.

λ : 협상 전략, τ : 협상 기한 λ < 1 -> 관대함(빠르게 양보) λ = 1 -> 선형(일정하게 양보) λ > 1 -> 보수적(느리게 양보)

협상 속도

동일한 협상 전략, 기한을 가진 에이전트 쌍의 경우 -> (a) - (d) 협상 에이전트가 더 빠른 양보 전략을 선택할 수록 협상 시간이 빠른 것을 확인

다른 협상 전략, 기한을 가진 에이전트 쌍의 경우 -> (e) - (h) 서로 다른 전략과 마감 기한을 가졌을 때도 Burst 모드에서 협상 속도가 높아지는 것을 볼 수 있음 (f), (g)에서는 한 에이전트가 보수적 전략과 긴 마감기한을 선택하면 협상 속도가 느려지는 것을 볼 수 있음 그럼에도 B50이 H1보다 28.1% ~ 57.3% 빠른 것을 확인

총 효용

협상 전략과 기한에 좌우되지 않음 협상 전략과 기한이 서로 같거나 다르거나 상관없이 일관되게 다른 기법들보다 총 효용이 높게 나오는 것을 볼 수 있음. 다만, CL이 0.9일 때는 사용 가능한 시간대가 적어지면서 평균 총 효용이 줄어드는 것을 확인할 수 있음

Burst Mode의 제안 개수

동시 제안의 수 증가와 결과 향상량

버스트 모드를 사용할 때, 동시 제안의 수가 증가함에 따라 더 빠른 협상 속도와 더 높은 효용이 나타났지만, 향상량은  동시 제안의 수가 증가함에 따라 감소함.

B10에서 B50으로 넘어갈 때, 협상 속도와 총 효용은 각각 5.6%와 1.5% 증가하였지만, B50에서 B100으로 넘어갈 때, 협상 속도와 총 효용이 각각 0.7%와 0.6% 증가하였음.

이는 버스트 모드가 너무 많은 제안을 동시에 한다고 성능이 크게 달라지지 않는다는 것을 시사함. 따라서 계산 복잡도와 성능 개선을 잘 확인하며 제안 개수를 설정해야 함.

연구의 기여도

최초의 클라우드 서비스 예약을 위한 PTN 메커니즘 설계 및 구현

Burst Mode 절충, 양보 알고리즘 설계

• 협상 속도와 총 효용 모두 향상
• 다중 이슈 협상에서 동시 다중 제안 가능

  새로운 시간대 효용 함수 개발

• 다양한 시간대에 대한 서로 다른 선호도 특성화
• 기존 연구에서는 고려되지 않던 새로운 개념

  연구의 한계점 및 향후 연구

• 협상 메커니즘에서 다룬 쟁점의 수가 제한적
• 계산 복잡도가 더 효율적인 알고리즘 필요
• 사용자 친화적 인터페이스 부족
• 동적인 환경 변화에 대한 미고려

  향후연구

• 다른 협상 쟁점(QoS 등)을 고려하고 명시하는 것
• 버스트 모드의 동시 제안의 수를 적응적으로 제어하여 계산 복잡도를 줄이고 알고리즘 향상
• 높은 수준의 사용자 선호도를 시간대 효용 함수의 낮은 수준의 기술적 사양으로 변환하는 GUI

문제 제기 및 연구의 필요성

서비스 수준 협약을 위반할 가능성

기존 CSP는 고정된 SLA를 제시하지만, 시스템 자원이 부족해지면 SLA를 위반할 가능성이 높음 특히, 지역적으로 분산된 데이터 센터를 운영하는 클라우드 환경에서는 서비스 응답속도와 부하 분산 사이에 상관관계가 있는데, 고정된 SLA는 부하를 효율적으로 분산시키기 어렵게 만듦

이러한 문제를 해결하고자 분산 데이터센터 환경에서 SLA 위반을 줄이기 위한 가변 SLA기법을 제안하고 그 유효성을 평가하고자 이 논문이 작성됨

핵심 아이디어 및 해결책

핵심 아이디어

클라우드 서비스 공급자와 사용자 간의 자동화된 SLA 협상 메커니즘을 도입하여, 사용자의 요구사항과 시스템 자원 상황에 맞춰 서비스 품질을 미리 조율하는 것 이를 통해 고정 SLA로 인해 발생하는 문제들을 해결

해결책

다중 쟁점 협상 : 서비스 응답 속도와 가격을 주요 협상 쟁점으로 설정 공급자와 사용자는 이 두 가지 쟁점에 대한 만족도를 유틸리티 함수로 정의하고, 협상 에이전트가 최적의 합의점을 찾도록 함

가변 SLA 구현 : 협상을 통해 서비스 응답 속도와 가격을 유동적으로 결정하여, 사용자는 낮은 가격으로 느린 서비스를 받거나, 공급자는 부하 분산에 유리한 데이터센터에 작업을 할당할 수 있음

연구 결과 및 입증내용

결론 도출 과정

에이전트 기반의 클라우드 테스트베드를 구축하고, 가변 SLA 기법과 고정 SLA 기법의 성능을 비교하는 시뮬레이션을 수행함 1,000명, 5,000명, 10,000명의 사용자로 가정 후 테스트를 진행함

SLA위반 경감

가변 SLA를 적용했을 때, 고정 SLA를 사용했을 때 보다 위반 사용자의 수가 월등히 낮아진 것을 볼 수 있음

수익 증대

가변 SLA를 이용하면 클라우드 공급자에게 더 높은 수익을 제공하는 것을 그래프를 통해 확인할 수 있음

논문의 타당성 및 한계점

타당성

이 연구는 분산 데이터센터 환경의 문제점을 해결하기 위해 가변적인 SLA라는 새로운 접근법을 제시하고, 자동화된 협상 메커니즘을 적용하여 이를 구체적으로 구현함

실험을 통해 SLA 위반율 감소와 수익 증대라는 뚜렷한 결과를 확인할 수 있으므로, 논문의 주장은 매우 합당하다고 볼 수 있음

한계점

본 논문에서 언급된 직접적인 한계점이 없음 

그러나 저자가 향후 연구로 SLA 협상 기법에 기반한 자원 및 과금 정책 스케줄러 디자인을 고안할 계획이라고 밝히며, 이는 SLA 협상 외에 실제 클라우드 시스템의 자원 관리 및 요금 청구 방식과 연계하는 포괄적인 연구가 필요하다고 볼 수 있음

1. RAM과 보조기억장치의 차이

컴퓨터의 저장 장치는 데이터가 전원이 꺼진 후에도 유지되는지 여부에 따라 휘발성과 비휘발성으로 나뉩니다.

• RAM (Random Access Memory):

  • 휘발성 장치로, 전원이 꺼지면 모든 내용이 사라집니다.
  • CPU가 직접 접근하는 주기억장치이며, 현재 실행 중인 프로그램이나 데이터를 임시로 저장하는 '작업 공간' 역할을 합니다.
  • RAM의 용량이 클수록 더 많은 프로그램을 동시에 처리할 수 있어 작업 속도가 빨라집니다.

• 보조기억장치:

  • 비휘발성 장치로, 전원이 꺼져도 데이터가 보존됩니다.
  • 하드 디스크(HDD), SSD, CD-ROM, USB 메모리 등이 대표적입니다.
  • 프로그램과 데이터를 영구적으로 저장하는 역할을 합니다. CPU는 여기에 직접 접근하지 못하고, 실행에 필요한 데이터를 RAM으로 복사하여 사용합니다.

2. DRAM vs. SRAM: RAM의 두 얼굴

RAM은 크게 DRAM과 SRAM 두 종류로 나뉘며, 각각의 특성과 사용 목적이 다릅니다.

• DRAM (Dynamic RAM):

  • 저장된 데이터가 시간이 지나면 동적으로 사라지기 때문에, 주기적으로 데이터를 재활성화(재충전)해야 합니다.
  • 저렴하고 집적도가 높아 대용량 메모리인 주기억장치(RAM)로 널리 쓰입니다.

• SRAM (Static RAM):

  • 전원이 공급되는 동안 데이터가 유지되어 재충전이 필요 없습니다.
  • DRAM보다 속도가 빠르지만, 가격이 비싸고 소비 전력이 많으며 집적도가 낮습니다.
  • 대용량보다는 빠른 속도가 중요한 캐시 메모리에 주로 사용됩니다.

3. 발전된 RAM: SDRAM과 DDR SDRAM

• SDRAM (Synchronous Dynamic RAM):

  • CPU의 클럭 신호와 동기화되어 작동하는 발전된 형태의 DRAM입니다.
  • 클럭 타이밍에 맞춰 CPU와 데이터를 주고받아 비동기식 DRAM보다 훨씬 효율적입니다.

• DDR SDRAM (Double Data Rate SDRAM):

  • SDRAM의 발전형으로, 대역폭을 2배로 넓혀 한 클럭당 두 번씩 데이터를 주고받을 수 있게 되었습니다.
  • DDR2, DDR3, DDR4 등으로 발전하며 전송 속도가 계속 향상됩니다.

4. 메모리 관리 기술: 논리 주소와 물리 주소

CPU는 프로그램을 실행할 때 실제 메모리 주소를 직접 다루기 어렵기 때문에 가상의 주소를 사용합니다.

• 물리 주소: 메모리 하드웨어가 실제로 사용하는 주소.
• 논리 주소: CPU와 실행 중인 프로그램이 사용하는 가상의 주소.

이를 변환하는 장치가 바로 메모리 관리 장치(MMU)입니다. MMU는 논리 주소에 베이스 레지스터 값을 더해 실제 물리 주소를 계산합니다.

메모리 보호 기법

• 베이스 레지스터: 현재 프로그램의 시작 물리 주소를 저장합니다.
• 한계 레지스터: 현재 프로그램의 논리 주소 최대 크기를 저장합니다.
• 작동 방식: CPU가 메모리에 접근할 때, 접근하려는 논리 주소가 한계 레지스터 값을 넘지 않는지 검사하여 다른 프로그램의 영역을 침범하지 않도록 보호합니다.

5. 저장 장치 계층 구조와 캐시 메모리

컴퓨터의 저장 장치는 속도와 용량에 따라 계층적으로 구성됩니다.

• 원칙: CPU에 가까운 장치일수록 빠르고, 멀어질수록 느립니다. 또한, 속도가 빠를수록 용량은 작고 가격은 비쌉니다.

캐시 메모리

CPU와 RAM의 속도 차이를 줄이기 위해 탄생한 매우 빠른 임시 저장 장치입니다. CPU가 필요할 것으로 예측되는 데이터를 미리 가져와 저장해 둡니다. 메모리로부터 데이터를 가져올 때는 참조 지역성의 원리를 따릅니다.

• 캐시 히트: 예측이 맞아 캐시에서 데이터를 찾았을 때.
• 캐시 미스: 예측이 틀려 RAM에서 데이터를 가져와야 할 때.
• 종류: CPU 코어에 가까운 순서대로 L1, L2, L3 캐시가 있습니다. L1이 가장 빠르고 용량이 작습니다.
• 참조 지역성의 원리: 캐시 메모리가 데이터를 가져오는 핵심 원칙입니다.
  1. 시간 지역성: 최근에 사용된 데이터는 곧 다시 사용될 가능성이 높다.
  2. 공간 지역성: 사용된 데이터 근처의 데이터가 곧 사용될 가능성이 높다.

1. 클럭 (Clock)

클럭은 컴퓨터 부품들이 일사불란하게 움직일 수 있도록 해주는 시간 단위입니다. 마치 지휘자의 박수처럼, CPU는 이 클럭 신호에 맞춰 명령어를 처리합니다.

• 클럭 속도 (Clock Speed): 1초에 발생하는 클럭의 횟수로, 헤르츠(Hz) 단위로 나타냅니다. 일반적으로 클럭 속도가 빠를수록 CPU의 성능이 높아집니다.
• 클럭 속도의 한계: 클럭 속도를 무작정 높이면 발열이 심해져 CPU 성능에 오히려 악영향을 줄 수 있습니다. 이 때문에 클럭 속도를 높이는 데에는 한계가 있습니다.

2. 멀티코어 (Multi-core)

클럭 속도의 한계를 극복하기 위해 등장한 방식 중 하나가 코어 수를 늘리는 것입니다.

• 코어 (Core): 실제로 명령어를 실행하는 CPU의 핵심 부품입니다.
• 멀티코어 CPU: 여러 개의 코어를 한 칩에 집적한 CPU를 말합니다. 여러 개의 일꾼이 동시에 작업하는 것처럼, 여러 코어가 동시에 명령어를 처리하여 전체 성능을 향상시킵니다.
  • 예시: 2.4GHz 클럭의 단일 코어 CPU보다 1.9GHz 클럭의 멀티코어 CPU가 일반적으로 더 높은 성능을 보입니다.
• 주의사항: 코어 수가 많다고 해서 무조건 성능이 비례하여 증가하는 것은 아닙니다. 작업을 효율적으로 분배하는 기술이 중요하며, 작업량에 비해 코어 수가 지나치게 많으면 효율이 떨어질 수 있습니다.

3. 스레드 (Thread)

스레드는 CPU에서 명령어를 처리하는 단위로, 하드웨어 스레드와 소프트웨어 스레드로 구분해 이해하는 것이 좋습니다.

하드웨어 스레드

• 정의: 하나의 코어가 동시에 처리하는 명령어의 단위를 의미합니다.
• 멀티스레드 프로세서: 하나의 코어가 2개 이상의 명령어를 동시에 처리할 수 있는 기술입니다. 인텔의 하이퍼스레딩(Hyper-Threading) 기술이 대표적입니다.
  • 원리: 코어 내에 여러 개의 레지스터를 두어 마치 여러 개의 코어가 있는 것처럼 동작하게 합니다. 그래서 하드웨어 스레드를 논리 프로세서라고 부르기도 합니다.

소프트웨어 스레드

• 정의: 하나의 프로그램에서 독립적으로 실행되는 작업의 단위입니다.
  • 예시: 워드 프로그램에서 '입력 내용 보여주기', '맞춤법 검사', '자동 저장' 등의 기능을 각각의 스레드로 만들어 동시에 실행할 수 있습니다.

정리:

• 코어: 물리적으로 명령어를 실행하는 하드웨어 부품. (일꾼)
• 스레드: 명령어를 실행하는 논리적인 단위. (일꾼 한 명이 동시에 여러 개의 일을 할 수 있는 능력)
• 멀티코어: CPU에 물리적인 코어가 여러 개 있는 것.
• 멀티스레드: 하나의 코어가 여러 스레드를 동시에 처리할 수 있는 것.

CPU 성능 향상을 위한 명령어 병렬 처리 기법

CPU의 성능을 높이기 위해서는 클럭, 코어, 스레드 외에도 CPU가 쉬지 않고 일하게 만드는 명령어 병렬 처리 기술이 중요합니다.

1. 명령어 파이프라이닝 (Instruction Pipelining)

명령어 처리 과정을 여러 단계(인출, 해석, 실행, 결과 저장 등)로 나누고, 각 단계를 겹쳐서 동시에 처리하는 기법입니다. 마치 공장의 생산 라인처럼 여러 명령어를 연속적으로 처리하여 효율을 극대화합니다.

• 위험 요소:
  • 데이터 위험: 명령어 간 데이터 의존성 때문에 발생하는 문제. (예: 앞선 명령어의 결과가 다음 명령어에 필요할 때)
  • 제어 위험: 프로그램 분기(조건에 따라 실행 순서가 바뀌는 것)로 인해 미리 가져온 명령어들이 쓸모없게 되는 문제. 분기 예측 기술로 해결합니다.
  • 구조적 위험: 여러 명령어가 동시에 같은 CPU 부품(ALU, 레지스터 등)을 사용하려고 할 때 발생하는 문제.

2. 슈퍼스칼라 (Superscalar)

대부분의 현대 CPU가 채택하고 있는 구조로, 여러 개의 파이프라인을 동시에 사용하는 기법입니다. 여러 명령어를 한꺼번에 처리할 수 있어 처리 속도가 이론적으로 파이프라인 개수에 비례하여 빨라집니다.

3. 비순차적 명령어 처리 (Out-of-order Execution, OoOE)

데이터 의존성이 없는 명령어들을 순서와 관계없이 먼저 실행하여, 파이프라인이 멈추는 것을 방지하고 전체적인 성능을 높이는 기법입니다.

명령어 집합 아키텍처 (Instruction Set Architecture, ISA)

ISA는 CPU가 이해할 수 있는 명령어들의 모음으로, CPU의 언어와 같습니다. 대표적으로 CISC와 RISC가 있습니다.

CISC (Complex Instruction Set Computer)

• 특징: 복잡하고 다양한 기능의 명령어 집합을 사용합니다.
• 장점: 하나의 명령어로 복잡한 연산을 수행할 수 있어 프로그램을 이루는 명령어 수가 적습니다.
• 단점: 명령어의 길이가 가변적이고 실행 시간이 일정하지 않아 파이프라이닝에 불리합니다.

RISC (Reduced Instruction Set Computer)

• 특징: 단순하고 적은 종류의 명령어를 사용합니다.
• 장점: 고정된 명령어 길이와 1클럭 내외의 실행 시간으로 파이프라이닝에 최적화되어 있습니다.
• 단점: CISC보다 많은 명령어를 사용해야 프로그램을 완성할 수 있습니다.

ALU (산술 논리 연산 장치)

받아들이는 정보

• 피연산자와 제어 신호
  • 레지스터를 통해 피연산자를 받아들이고, 제어장치로부터 수행할 연산을 알려주는 제어 신호를 받아들임
  • 받아들인 피연산자와 제어 신호로 산술 연산, 논리 연산 등 다양한 연산을 수행

내보내는 정보

• 결과값과 플래그
  • 결과값은 일시적으로 레지스터에 저장된 후 메모리에 저장 (프로그램의 실행 속도를 위해서)
  • 플래그는 연산 결과에 대한 추가적인 상태 정보를 뜻하며, 플래그 레지스터에 저장됨

플래그 종류 및 의미

제어장치 (Control Unit)

받아들이는 정보

• 클럭 신호
  • 컴퓨터의 모든 부품을 일사분란하게 움직일 수 있게 하는 시간 단위
  • (모든 부품이 클럭 박자에 맞춰서 작동하지만, 한 박자마다 작동하는 건 아님)
• 명령어
  • 명령어 레지스터로부터 해석할 명령어를 받아들이고, 해석한 뒤 제어신호를 발생시켜 수행할 내용을 알려줌
• 플래그
  • 플래그 값을 참고하여 제어신호를 발생시켜 올바른 정보 전달 및 동작 수행 유도
• 제어 신호
  • 제어 버스를 통해 외부로부터 전달된 제어 신호를 받아들이기도 함

내보내는 정보

• 외부에 전달하는 제어 신호:
  메모리와 입출력장치에 전달하는 신호
• 내부에 전달하는 제어 신호:
  ALU와 레지스터에 전달하는 신호

레지스터 (Register)

• 프로그램의 명령어와 데이터는 실행 전후로 반드시 레지스터에 저장됨
• 레지스터 속 값을 관찰하면 CPU 내에서 무슨 일이 벌어지고 있는지, 어떤 명령어가 어떻게 수행되는지 알 수 있음

주요 레지스터 종류

명령어 사이클 (Instruction Cycle)

• 명령어들은 일정한 주기가 반복되며 실행됨 (이 주기를 명령어 사이클이라고 함)
  • 인출 사이클: 메모리에 있는 명령어를 CPU로 가지고 오는 단계
  • 실행 사이클: 제어장치가 명령어 레지스터에 담긴 값을 해석하고, 제어 신호를 발생시키는 단계
  • 간접 사이클: 실행을 위해 다시 메모리에 접근하는 단계

인터럽트 (Interrupt)

종류

• 동기 인터럽트:
  CPU가 명령어를 수행하다가 오류 등 예외 상황에서 발생 (예외라고도 함)
• 비동기 인터럽트:
  입출력장치에 의해 발생.
  CPU가 지시한 작업을 완료하거나 입력을 받아들였을 때 CPU에 보내는 알림 (하드웨어 인터럽트라고도 함)

하드웨어 인터럽트 처리 순서

1. 입출력장치가 CPU에 인터럽트 요청 신호를 보냄
2. CPU는 실행 사이클이 끝나고 명령어를 인출하기 전, 항상 인터럽트 여부를 확인함
3. 인터럽트 플래그를 통해 현재 인터럽트를 받아들일 수 있는지 확인
4. 인터럽트를 받아들일 수 있다면 CPU는 지금까지의 작업을 백업
5. CPU는 인터럽트 벡터를 참조하여 인터럽트 서비스 루틴(ISR)을 실행
6. ISR 실행이 끝나면 백업해둔 작업을 복구하여 실행 재개

• CPU가 인터럽트 요청을 수행하려면 플래그 레지스터의 인터럽트 플래그가 활성화되어 있어야 함
• 정전이나 고장 등 치명적인 인터럽트는 무시할 수 없음

용어 정리

• 인터럽트 서비스 루틴(ISR): 인터럽트를 처리하는 프로그램 (인터럽트 핸들러)
• 인터럽트 벡터: ISR의 시작 주소 등 인터럽트 처리용 정보

예외의 종류

• 폴트 (fault):
  예외를 처리한 직후, 예외가 발생한 명령어부터 실행 재개
• 트랩 (trap):
  예외를 처리한 직후, 다음 명령어부터 실행 재개
• 중단 (abort):
  심각한 오류로 프로그램 강제 중단
• 소프트웨어 인터럽트:
  시스템 호출이 발생했을 때 나타남

언어 번역 방식, 주소 지정 방식 정리

고급 언어와 저급 언어

우리가 작성하는 소스코드는 컴퓨터가 직접 이해하지 못함.

• 우리는 고급 언어(C, C++, Java, Python 등)를 사용하고,
• 컴퓨터는 저급 언어(기계어, 어셈블리어)만 이해하기 때문

기계어와 어셈블리어

• 기계어: 2진수 혹은 16진수로 구성된 컴퓨터가 직접 이해하는 명령어
  → 사람이 해독하기 어려움

• 어셈블리어: 기계어를 사람이 조금 더 이해하기 쉬운 형태로 표현한 저급 언어
  → 어셈블리어를 알면 프로그램이 어떻게 동작하는지를 근본적인 수준에서 이해할 수 있음

소스 코드 번역 방식

소스코드를 컴퓨터가 이해할 수 있도록 저급 언어로 변환하는 방식은 두 가지가 있다.

1. 컴파일 방식

• 전체 소스 코드를 한 번에 번역해서 실행
• 번역된 결과: 목적 코드(object code)
• 예: C 언어

✅ 장점:

• 전체를 컴파일해두므로 실행 속도가 빠름

❌ 단점:

• 컴파일 과정에서 오류가 하나라도 있으면 실행 불가

2. 인터프리터 방식

• 소스 코드를 한 줄씩 번역하면서 실행
• 예: Python

✅ 장점:

• 오류가 있는 줄을 실행하기 전까지는 나머지 코드가 실행됨

❌ 단점:

• 매번 해석하며 실행하기 때문에 속도는 느림

⚠️ 고급 언어는 컴파일 언어 vs 인터프리터 언어처럼 명확히 나뉘지 않음.
많은 언어가 두 속성을 모두 갖거나 전환 가능하기 때문

명령어 구조

컴퓨터 명령어는 다음 두 부분으로 구성됨.

• 연산 코드 (Opcode): 어떤 연산을 할지 정의
• 오퍼랜드 (Operand): 연산에 사용할 데이터

오퍼랜드는 연산의 대상이며, 데이터, 메모리 주소, 레지스터 등이 올 수 있음.
그래서 오퍼랜드 필드를 주소 필드라고도 부름.

주소 지정 방식 (Addressing Modes)

오퍼랜드 필드에 연산 대상의 주소나 값을 명시하는 방식. 대표적으로 다섯 가지 방식

1. 즉시 주소 지정 방식 (Immediate Addressing)

• 데이터를 오퍼랜드 필드에 직접 명시
• 가장 단순하고 빠르지만, 표현 가능한 데이터 크기에 제한이 있음

2. 직접 주소 지정 방식 (Direct Addressing)

• 유효 주소를 직접 명시
• 표현 가능한 주소의 범위가 연산 코드 길이에 제한받음

3. 간접 주소 지정 방식 (Indirect Addressing)

• 유효 주소의 주소를 오퍼랜드 필드에 명시
• 표현 범위는 넓지만, 메모리 접근이 2회 필요하여 느림

4. 레지스터 주소 지정 방식 (Register Addressing)

• 데이터를 저장한 레지스터를 오퍼랜드 필드에 명시
• 메모리보다 빠름
• 그러나 사용 가능한 레지스터 수에 제한

5. 레지스터 간접 주소 지정 방식 (Register Indirect Addressing)

• 데이터를 메모리에 저장하고,
  그 주소를 저장한 레지스터를 오퍼랜드 필드에 명시
• 간접 주소 지정과 유사하지만, 메모리 접근은 1번만 필요

연산 코드의 유형

명령어의 연산 코드는 다음과 같은 유형으로 나뉨.

1. 데이터 전송 (Data Transfer)
2. 산술/논리 연산 (Arithmetic/Logical Operations)
3. 제어 흐름 변경 (Control Flow)
4. 입출력 제어 (I/O Control)

정보의 단위

• bit: 0과 1을 나타내는 가장 작은 정보 단위
• byte: 8개의 비트를 묶은 단위

💡 1kB = 1,000 byte
1KiB = 1,024 byte
(kB는 10진수 기준, KiB는 2진수 기준)

이진법에서의 음수 표현

컴퓨터에서 음수를 표현할 때 가장 널리 쓰이는 방식은 2의 보수(Two’s Complement)이다.

• 2의 보수란?
  어떤 수를 그보다 큰 2ⁿ에서 뺀 값
  예: 8비트 기준이면 2⁸ = 256, -5는 256 - 5 = 251

• 쉽게 생각하면

  모든 0과 1을 뒤집고(1의 보수) → 거기에 1을 더한 값

또한 컴퓨터 내부에서는 양수와 음수를 구분하기 위해 플래그 비트(보통 최상위 비트)를 사용한다.

16진수의 사용

이진수만으로 정보를 표현하면 길이가 너무 길어지는 단점이 있다.
그래서 컴퓨터에서는 종종 16진수를 사용한다.

• 16진수는 4비트로 1자리를 표현할 수 있어, 이진수보다 짧고 가독성이 좋다
• 예: 0xF는 4비트 이진수 1111에 해당

문자 집합과 인코딩

• 문자 집합(Character Set): 컴퓨터가 표현할 수 있는 문자들의 모음
• 문자 인코딩(Encoding): 문자를 컴퓨터가 이해할 수 있도록 0과 1로 변환하는 과정
• 문자 디코딩(Decoding): 0과 1의 코드 → 사람이 이해할 수 있는 문자로 바꾸는 과정

아스키 코드 (ASCII)

• 7비트 인코딩으로 128개의 문자 표현 가능
• 영어, 숫자, 특수문자 등은 표현 가능하지만 한글은 표현 불가

한글 인코딩 방식

1. 완성형 인코딩 (EUC-KR 등)

• 초성, 중성, 종성을 미리 조합한 글자 단위에 고유 코드를 부여
• 예: "가", "각", "간"처럼 완성된 글자에만 코드 부여
• 대표 인코딩: EUC-KR
  • 약 2,350자 표현 가능
  • 단점: 문자 집합에 없는 글자는 표현 불가
  • 이를 보완한 방식이 CP949

하지만 CP949도 모든 한글을 표현하기엔 부족하다.

2. 조합형 인코딩

• 초성, 중성, 종성 각각에 코드를 부여하고 조합해서 글자 생성
• 장점: 모든 조합을 표현할 수 있지만 구현이 복잡하고 비표준화 문제 발생

유니코드(Unicode)

• 전 세계 대부분의 문자, 특수문자, 이모티콘까지 표현 가능한 글로벌 표준 문자 집합
• 하나의 코드로 거의 모든 문자 표현 가능
• 유니코드는 글자에 부여된 값 자체를 저장하지 않고, 다양한 인코딩 방식 사용:
  • UTF-8: 가변 길이 인코딩, 웹에서 가장 많이 사용됨
  • UTF-16: 2바이트 또는 4바이트 사용
  • UTF-32: 고정 4바이트, 메모리 사용 많지만 처리 간편

• 성능, 용량, 비용을 계산할 수 있기 때문
• 프로그램이 실제 하드웨어에서 어떻게 작동하는지 이해할 수 있음

컴퓨터 구조의 핵심 구성

크게 두 가지로 나뉨:

1. 컴퓨터가 이해하는 정보
2. 컴퓨터의 4가지 핵심 부품

컴퓨터가 이해하는 정보

● 데이터

• 컴퓨터가 처리하는 정적인 정보
• 예: 숫자, 문자, 이미지, 동영상 등

● 명령어

• 데이터를 처리하고 컴퓨터를 작동시키는 지시 정보
• 프로그램 = 명령어 + 데이터

컴퓨터의 4가지 핵심 부품

중앙처리장치 (CPU)

• 컴퓨터의 두뇌
• 메모리에 저장된 명령어를 읽고 해석하고 실행하는 역할
• 다음 3가지 구성 요소로 나뉨:

ALU (산술논리연산장치)

• 계산과 논리 연산을 담당
• 컴퓨터 내부의 계산기 역할

레지스터

• CPU 내부의 작은 임시 저장소
• 명령 실행에 필요한 값들을 잠시 저장

제어장치

• 명령어를 해석하고
• 다른 부품에 제어신호를 보내는 역할

주기억장치 (메모리)

• 현재 실행 중인 프로그램의 명령어와 데이터 저장
• 프로그램이 실행되기 위해선 메모리에 로드되어야 함
• 주소(Address) 개념을 사용해 빠르게 접근

보조기억장치

• 메모리는 휘발성 + 고가 + 용량 제한이 있음
• 장기 보관용으로 보조기억장치 필요
• 예: HDD, SSD, USB, DVD, CD-ROM 등
• 비교 요약:
  • 메모리 → 실행 중인 프로그램 저장
  • 보조기억장치 → 보관용 프로그램 저장

입출력장치 (I/O Device)

• 컴퓨터 외부와 정보 교환하는 장치
• 예: 마이크, 스피커, 프린터, 마우스, 키보드 등

메인보드 (Motherboard)

• 컴퓨터 부품을 장착할 수 있는 중앙 회로판
• 내부에 다양한 슬롯과 연결 단자가 있음
• 부품 간 정보 전달은 버스(Bus)를 통해 이루어짐
• 가장 핵심적인 버스: 시스템 버스

시스템 버스 구성

시스템 버스는 아래 3가지로 구성됨:

• 주소 버스 (Address Bus)

  • 메모리의 주소 정보를 전달

• 데이터 버스 (Data Bus)

  • 명령어와 데이터 내용을 전달

• 제어 버스 (Control Bus)

  • 제어 신호를 전달하여 동작을 조율

📌 운영체제란?

운영체제(Operating System, OS)는 하드웨어를 효율적으로 사용하게 해주는 소프트웨어이며, 사용자와 하드웨어 간의 인터페이스 역할을 한다.

• 컴퓨팅 자원의 추상화를 제공
• 자원 관리 정책의 결정, 운용, 강제 수행

🧩 운영체제의 주요 기능

• 하드웨어 장치 관리
  장치 초기화, 입출력 처리, 장치 제어

• 프로그램 관리
  프로그램의 적재, 실행, 오류 처리
  다중 프로그램 실행 지원

• 사용자 관리
  사용자 인증 및 권한 제어, 데이터 접근 제어

• 서비스 관리
  네트워크, 파일 시스템, 시스템 서비스 관리

🧭 운영체제와 일반 애플리케이션의 차이점

• OS는 항상 동작 중이며 자원을 감시하고 통제
• 하드웨어 제어 권한을 가짐

⚙️ 운영체제의 구성 요소

• 커널(Kernel) : OS의 핵심. 하드웨어와 직접 상호작용
• OS 서비스 : 보안 모니터, 윈도우 매니저 등 시스템 제공 기능
• 라이브러리 : 자주 사용하는 함수 및 서브루틴 집합

Kernel 중심으로 OS를 정의하는 관점도 존재

2강

💡 OS 설계 시 고려 사항

🖥 전형적인 컴퓨터 시스템 구조

• Hardware: CPU, Memory, Chipset, I/O Bus, 주변장치 등
• System Software: OS, DBMS, 하이퍼바이저, 컴파일러, 링커 등
• Application: 사용자가 실행하는 응용 프로그램들

🧱 전형적인 OS 구조

User Level
 └── Application
 └── Libraries (공용 함수 모음)

Kernel Level
 └── Portal OS Layer (시스템 호출 담당)
 └── Machine-Dependent Layer (부트로더, 디바이스 드라이버 등)

🔄 멀티태스킹과 OS 구성 요소

멀티태스킹: 하나 이상의 프로그램이 동시에 실행되는 것

1. 프로세스 관리

• 목표: I/O와 계산 동시 처리, 시간 공유, 다중 CPU 지원
• 유의점: 자원 낭비 방지, 동기화, 상호 배제, 공정성, 교착 상태 방지

2. 메모리 관리

• 목표: 편리한 프로그래밍, 메모리 효율성, 보조 저장소 전송
• 유의점: 보호 및 공정한 분배

3. I/O 장치 관리

• 목표: 장치-애플리케이션 간 상호작용, 새 장치 대응
• 유의점: 효율성, 보호, 공유

4. 파일 시스템

• 목표: 디스크 블록 관리, 파일-디스크 매핑
• 유의점: 신뢰성, 안정성, 효율성, 관리 용이성
• 일반 동작: 파일 열기 → 읽기/쓰기 → 닫기

🧾 컴퓨터 프로그램이란?

• 명령어(Instructions): CPU가 처리하는 기계어 코드
• 데이터(Data): 명령어가 읽고 쓰는 자료
• 코딩(Coding): 프로그래밍 언어로 명령어를 기술하는 행위
• 프로그램 이미지: 실행 가능한 형태의 데이터 묶음
  (Object File, Executable File 등)

📦 응용프로그램의 메모리 구성

응용 프로그램은 4개의 세그먼트로 구성된다.

힙과 스택은 서로 반대 방향으로 확장하여 충돌을 방지함

🔍 프로그램 실행 순서

🚀 부트스트랩 과정

부트스트랩(Bootstrap) 과정

컴퓨터 전원 On → OS 실행까지의 순서:

1. 전원 On
2. BIOS (ROM에 저장된 펌웨어)가 실행
3. BIOS가 부트로더를 메모리에 적재
4. 부트로더가 OS 커널을 메모리에 적재
5. 커널이 메모리에 올라오면 운영체제 시작

❗ BIOS는 디스크에 존재할 수 있는가?

아니다.

BIOS는 디스크 초기화 전에 실행되어야 하므로 ROM에 존재한다.

운영체제를 깊이 이해하려면, 프로세스의 상태 변화와 생성 구조를 반드시 알아야 합니다.
이 글에서는 프로세스의 상태(state), 계층 구조, 그리고 프로세스 생성 방식(fork/exec)을 다뤄보겠습니다.

🧠 프로세스의 상태

운영체제는 프로세스를 다음과 같은 5가지 상태로 구분하여 관리한다.

📌 상태 전이 예시

• 실행 중 타이머 인터럽트 발생 → 다시 준비 상태로 전환
• 실행 중 입출력 요청 발생 → 대기 상태로 전환
• 입출력 완료 → 준비 상태 복귀

🌳프로세스의 계층 구조

운영체제는 프로세스를 트리 형태로 계층적으로 관리한다.

🧩 부모와 자식 프로세스

• 프로세스가 시스템 호출을 통해 새로운 프로세스를 생성하면,
  • 생성자 = 부모 프로세스
  • 생성된 프로세스 = 자식 프로세스
• 각 프로세스는 고유한 PID를 갖는다.
• 일부 운영체제는 PCB에 부모의 PID(PPID)를 기록함.

🌲 계층 구조

• 컴퓨터 부팅 시 최초의 프로세스가 생성됨
• 이후 자식 프로세스들이 연속적으로 생성되어 트리 구조 형성

🔍 pstree 명령어를 통해 현재 시스템의 프로세스 계층 구조를 시각화할 수 있다.

🔧 프로세스 생성 기법

운영체제는 fork()와 exec() 시스템 호출을 이용해 새로운 프로세스를 생성한다.

1️⃣ fork() - 복사

• 부모 프로세스를 그대로 복사하여 자식 프로세스를 생성
• PID와 메모리 위치는 다르지만, 코드, 데이터 등은 동일
• 자식이 바로 exec()를 호출하지 않으면, 부모와 동일한 코드 실행

2️⃣ exec() - 변환

• 자식 프로세스가 실행 중인 코드를 다른 프로그램으로 교체
• 코드 영역과 데이터 영역을 새로운 프로그램으로 덮어씀
• 나머지 영역(힙, 스택)은 초기화됨

📌 자식 프로세스를 독립적인 새 프로그램으로 만들고 싶다면, fork() 후 exec() 호출이 필수

🧾 정리

• 프로세스는 상태에 따라 동작 흐름이 전환되고,
• 트리 구조로 계층화되어 관리되며,
• fork와 exec의 반복을 통해 생성된다.

운영체제를 이해하기 위해 반드시 짚고 넘어가야 할 핵심 개념이 있다.
바로 프로세스(Process) 와 이를 운영체제가 어떻게 관리하는가에 대한 이야기다.

🧠 프로세스란?

컴퓨터는 부팅과 동시에 수많은 프로세스를 실행한다.

✅ 포어그라운드 vs 백그라운드

• 포어그라운드 프로세스: 사용자가 직접 확인 가능한 실행 중인 프로세스
• 백그라운드 프로세스: 사용자 눈에 보이지 않는 곳에서 실행됨
  • 사용자와 직접 상호작용하는 경우도 있고,
  • 자율적으로 동작하는 경우도 있음
    → 유닉스: 데몬(Daemon), 윈도우: 서비스(Service) 라고 부름

⚙️ 운영체제의 프로세스 관리

운영체제는 프로세스의 실행 순서를 제어하고, 자원을 분배한다.
이를 위해 사용하는 구조가 바로 PCB (Process Control Block) 이다.

📋 PCB란 무엇인가?

PCB(Process Control Block) 는 프로세스에 대한 정보를 저장하는 커널의 자료 구조이다.

📌 역할

• 각 프로세스를 식별하고 관리
• 커널 영역에서 생성 및 소멸
• 프로세스의 생성/종료와 함께 PCB도 생성/삭제됨

📁 PCB에 저장되는 정보 목록

• 프로세스 ID (PID)
  고유 식별 번호 (같은 프로그램을 2번 실행하면 서로 다른 PID 부여)

• 레지스터 값
  프로세스의 실행 상태 복원을 위한 저장 값 (문맥 저장용)

• CPU 스케줄링 정보
  어떤 프로세스가 언제 CPU를 할당받을지 결정하는 데 필요

• 메모리 관리 정보
  메모리 주소, 베이스/한계 레지스터, 페이지 테이블 정보 등

• 파일/입출력 장치 목록
  프로세스가 열어둔 파일, 사용하는 장치 목록 등

🔄 문맥 교환 (Context Switching)

프로세스 실행이 전환될 때, 운영체제는 다음을 수행한다:

1. 현재 프로세스의 정보(문맥)를 PCB에 저장
2. 새로운 프로세스의 문맥을 복원하여 실행 이어감

⏱️ 문맥 교환은 매우 빠르게 일어나기 때문에 사용자 입장에서는 여러 프로세스가 동시에 실행되는 것처럼 보임

⚠️ 하지만 너무 잦은 문맥 교환은 오버헤드를 유발할 수 있으므로 빈도 조절이 중요하다.

🧩 프로세스의 메모리 구조

💡메모리 구조를 이해하면, 메모리 누수나 오버플로우 같은 오류를 사전에 방지할 수 있다.

운영체제는 사용자 영역에서 다음과 같이 프로세스 메모리를 구분한다:

🧱 정적 할당 영역 (Static Allocation Area)

🔹 코드 영역 (Code Segment)

• 기계어 명령어가 저장되는 영역
• CPU가 실행할 수 있는 실행 파일의 텍스트 코드
• 읽기 전용 (수정 불가)

🔹 데이터 영역 (Data Segment)

• 전역 변수, 정적 변수가 저장됨
• 프로그램 실행 내내 유지됨
• 실행 중 값은 변경 가능하나 영역 자체의 크기는 고정

✅ 이 두 영역은 프로그램이 실행되기 전부터 크기와 구조가 정해져 있으므로 정적 할당 영역이라 한다.

🔄 동적 할당 영역 (Dynamic Allocation Area)

🔹 힙 영역 (Heap Segment)

• 프로그래머가 직접 동적으로 메모리 할당 (malloc, new 등)
• 수동으로 해제하지 않으면 메모리 누수 발생 가능
• 크기 유동적이며 실행 중 계속 변할 수 있음

🔹 스택 영역 (Stack Segment)

• 함수 호출 시 생성되는 매개변수, 지역 변수 저장
• 함수 종료 시 자동 소멸 (Last In First Out 구조)
• PUSH / POP 방식으로 작동

📌 정리

• 힙 영역: 낮은 주소 → 높은 주소로 성장
• 스택 영역: 높은 주소 → 낮은 주소로 성장
• 서로 반대 방향으로 커지므로, 충돌하지 않도록 주의해야 함

✅ 이 두 영역은 프로그램 실행 중 동적으로 크기가 변하므로 동적 할당 영역이라 부른다.

📌 마무리

운영체제는 단순히 프로세스를 실행하는 것이 아니라,
PCB를 통해 정보를 저장하고, 문맥을 교환하며, 메모리 구조를 세밀하게 관리한다.

이러한 구조를 이해하는 것은 시스템 성능과 안정성의 핵심을 파악하는 데 반드시 필요하다.

운영체제는 사용자를 위한 프로그램이 아니라, 사용자가 실행하는 프로그램을 위한 프로그램이다.
즉, 응용 프로그램이 안전하고 효율적으로 실행되도록 시스템 자원을 관리하고 제어하는 핵심적인 소프트웨어다.

운영체제의 구성 요소 🧩

✅ 커널 (Kernel)

운영체제의 핵심 서비스를 담당하는 부분으로, 다음과 같은 역할을 수행한다:

• 하드웨어 자원 접근 및 조작
• 프로그램이 올바르고 안전하게 실행되도록 제어
• 프로세스, 메모리, 입출력 등의 핵심 기능 관리

커널은 메모리 상에서 커널 모드로만 접근 가능한 보호된 영역이다.

✅ 사용자 인터페이스 (User Interface)

운영체제와 사용자가 상호작용할 수 있는 통로이다. 커널에 포함된 기능은 아니다.

• GUI (Graphic User Interface): 그래픽 요소를 통해 상호작용 (예: 윈도우, 아이콘)
• CLI (Command Line Interface): 명령어 기반 상호작용 (예: 터미널, 쉘)

이중 모드 (Dual Mode) 🖥️

CPU는 명령어를 실행할 때 두 가지 모드 중 하나로 동작한다.

👤 사용자 모드 (User Mode)

• 일반적인 응용 프로그램이 실행되는 영역
• 커널 영역 접근 불가, 하드웨어 직접 조작 불가

🛡️ 커널 모드 (Kernel Mode)

• 커널 코드를 실행할 수 있는 운영체제 전용 모드
• 모든 명령어와 하드웨어 자원 접근 가능

🔁 시스템 호출 (System Call)

사용자 모드에서 운영체제의 기능이 필요할 때, 커널 모드로 전환하기 위한 요청

• 일종의 인터럽트로 동작
• CPU는 현재 작업을 백업하고 커널로 진입 → 작업 수행 → 원래 작업으로 복귀

📂 시스템 호출의 예시

• 프로세스 생성/종료
• 파일 생성/열기/저장
• 디렉터리 관리
• 디스크 및 장치 접근

운영체제의 핵심 서비스 🔧

📌 프로세스 관리

• 프로세스: 실행 중인 프로그램
• CPU는 한 번에 하나의 프로세스만 실행 → CPU 스케줄링 필요

📌 메모리 관리

• 실행 중인 프로세스를 메모리에 적절히 할당/해제

📌 입출력 관리

• 장치의 인터럽트 요청을 처리하여 입출력 수행

📌 파일 시스템 관리

• 파일 생성/저장/삭제/탐색 등

핵심 정리 🧠

• 운영체제의 핵심 기능은 커널이 담당
• 사용자 프로세스가 운영체제 서비스를 사용하려면 → 시스템 콜을 통해 커널 모드로 전환
• 커널은 CPU, 메모리, 입출력 장치, 파일 시스템 등을 관리하는 중심 요소

더 알아보기: 가상 머신과 하이퍼바이저 모드 🧱

🧪 가상 머신(Virtual Machine)

• 소프트웨어로 구현한 가상의 컴퓨터
• 하나의 컴퓨터에 여러 운영체제와 프로그램 설치 가능
• 가상 머신 자체는 응용 프로그램으로 취급됨

🔐 하이퍼바이저 모드 (Hypervisor Mode)

• 가상 머신이 커널 모드로 직접 접근하기 어려운 문제를 해결하기 위해 생긴 새로운 CPU 모드
• 하드웨어 가상화를 지원하는 CPU는 커널 모드 외에 하이퍼바이저 전용 모드를 제공

📘 운영체제를 이해하는 것은 시스템을 제어하고 최적화할 수 있는 첫걸음이다.

운영체제(OS, Operating System)는
실행할 프로그램에 필요한 시스템 자원을 할당하고, 프로그램이 올바르게 실행되도록 관리하는 특별한 프로그램이다.

운영체제도 하나의 프로그램이므로, 실행되기 위해 메모리에 적재된다.

🔧 운영체제의 핵심 역할

운영체제는 단순한 소프트웨어가 아니다.
하드웨어 자원과 응용 프로그램 사이에서 중심적인 역할을 수행한다.

✅ 1. 자원 할당 및 관리

• 프로그램 실행에 필요한 요소(메모리, CPU 등 컴퓨터 부품)를 적절히 분배
• 응용 프로그램을 메모리에 적재하고 필요 시 삭제
• 메모리를 사용자 영역과 커널 영역으로 구분하여 커널은 운영체제가 차지

✅ 2. CPU 스케줄링

• CPU의 사용 순서와 사용 시간을 조절
• 동시에 여러 프로그램이 실행되는 멀티태스킹 환경을 효율적으로 지원

✅ 3. 시스템 규칙 제공

• 응용 프로그램들이 지켜야 할 규칙(인터페이스, API 등)을 정의
• 시스템 자원의 충돌을 방지하고, 전체 시스템의 안정성을 유지

🚀 운영체제는 왜 중요한가?

우리가 만드는 모든 프로그램은 결국 하드웨어 위에서 실행된다.
그리고 하드웨어를 직접 다루는 프로그램이 바로 운영체제다.

운영체제는 인간보다 하드웨어를 먼저, 더 깊이 이해하고 있다.
따라서 우리가 만든 프로그램에서 발생하는 문제는 운영체제와의 인터랙션을 이해함으로써 해결의 실마리를 찾을 수 있다.

운영체제를 이해한다는 것은, 단순히 시스템을 아는 것을 넘어 문제 해결 능력을 갖추는 핵심적인 기반이 된다.

📌 마무리

운영체제는 단순한 배경 프로그램이 아니라,
시스템 전체를 설계하고 통제하는 핵심 관리자다.
개발자라면 반드시 깊이 있게 이해하고 있어야 할 기술 기반이다.