1️⃣ Basic Concepts and Necessity of CPU Scheduling

CPU Scheduling; Who Does the OS Give the CPU to First?

Last week, we examined the concepts of processes and threads, looking at how execution flows are divided and how the operating system manages execution units.

Once you understand these concepts, a natural question arises: when multiple processes and threads exist simultaneously, who should the CPU be allocated to first? If all processes want to run at the same time, what criteria does the operating system use to make that decision?

This week's topic, CPU scheduling, starts from exactly these questions.

CPU 스케줄링; 운영체제는 누구에게 먼저 CPU를 줄까?

지난주에는 프로세스와 스레드의 개념을 살펴보며, 실행의 흐름이 어떻게 나뉘는지 그리고 운영체제가 실행 단위를 어떻게 관리하는지 확인했다.

개념을 익히고 나면 자연스럽게 이런 의문이 생긴다. 여러 프로세스와 스레드가 동시에 존재할 때, CPU는 과연 누구에게 먼저 할당되어야 할까? 모든 프로세스가 동시에 실행되길 원한다면, 운영체제는 어떤 기준으로 CPU를 나눠줄까?

이번 주제인 CPU 스케줄링은 바로 이 질문에서 출발한다.

Why Things Appear to Run Simultaneously

While listening to music, web pages still open instantly and messenger notifications keep coming through. To our eyes, all of these tasks seem to be happening at the same time.

In reality, the CPU can only process one task at a single moment. So are these multiple tasks truly running simultaneously?

The answer lies in rapid context switching. The operating system allocates the CPU to each task in extremely short intervals, taking turns. Because these switches happen so fast, it feels to the human eye as though everything is running at once.

So how does the operating system decide which task to run next? This is the core problem of CPU scheduling.

동시에 실행되는 것처럼 보이는 이유

음악을 듣는 동안에도 웹페이지는 바로 열리고, 메신저 알림은 끊기지 않는다. 우리 눈에는 이 작업들이 모두 동시에 이루어지는 것처럼 보인다.

그런데 사실 CPU는 한 순간에 단 하나의 작업만 처리할 수 있다. 그렇다면 이 여러 작업들은 정말로 동시에 실행되고 있는 걸까?

답은 빠른 전환(Context Switching) 이다. 운영체제는 각 작업에 CPU를 아주 짧은 시간 동안 번갈아 가며 할당한다. 이 전환이 너무 빠르기 때문에 사람의 눈에는 마치 모든 작업이 동시에 돌아가는 것처럼 느껴지는 것이다.

그렇다면 운영체제는 어떤 기준으로 다음 실행할 작업을 결정할까? 이것이 바로 CPU 스케줄링의 핵심 문제다.

The Core Problem of CPU Scheduling

Let's look at the situation more concretely. Opening a web page requires the CPU to process data. Displaying a messenger notification also uses the CPU. Even playing music involves CPU processing.

If all three of these tasks demand the CPU at the same moment, what choice should the operating system make? Should it run whichever task arrived first? Should it process the task that finishes fastest? Should it prioritize tasks that directly interact with the user?

The problem of deciding who gets the CPU, when, and for how long is the essence of CPU scheduling. The criteria chosen will significantly affect the system's response time, processing efficiency, and user experience.

CPU 스케줄링의 핵심 문제

상황을 조금 더 구체적으로 살펴보자. 웹페이지를 열 때는 데이터 처리를 위해 CPU가 필요하고, 메신저 알림을 표시할 때도, 음악이 재생되는 동안에도 CPU 처리가 이루어진다.

만약 이 세 가지 작업이 동시에 CPU를 요구하는 순간이 온다면 운영체제는 어떤 선택을 해야 할까?

• 먼저 도착한 작업을 실행할까?

• 가장 빨리 끝나는 작업을 먼저 처리할까?

• 사용자와 직접 상호작용하는 작업을 우선시할까?

이처럼 CPU를 누구에게, 언제, 얼마나 줄 것인가를 결정하는 문제가 바로 CPU 스케줄링의 핵심이다. 어떤 기준을 선택하느냐에 따라 시스템의 반응속도, 처리 효율, 사용자 경험이 크게 달라질 수 있다.

The Multi-Programming Environment

Modern operating systems keep multiple programs loaded in memory at the same time. Browsers, messengers, music players, and document editors all exist in a ready state simultaneously- meaning there are always multiple candidates requesting execution.

However, the CPU cannot process multiple programs at once. It can only handle one execution flow at a time, so even when many programs exist, the CPU must take turns processing them in order.

The operating system selects one of the ready processes and assigns the CPU to it. In a multi-programming environment, the process of deciding in what order the CPU is used — that is, scheduling — becomes essential.

다중 프로그래밍 환경

현대 운영체제는 여러 프로그램을 동시에 메모리에 올려둔다. 브라우저, 메신저, 음악 재생기, 문서 편집기 등 여러 프로세스가 동시에 준비 상태에 존재한다는 뜻이다. 즉, 실행을 요구하는 대상이 여러 개인 상황이 항상 발생한다.

그러나 CPU는 동시에 여러 프로그램을 처리할 수 있는 장치가 아니다. 한 시점에는 하나의 실행 흐름만 처리할 수 있기 때문에, 여러 프로그램이 존재하더라도 CPU는 순서를 정해 번갈아 가며 처리할 수밖에 없다.

이때 운영체제는 준비 상태에 있는 여러 프로세스 중 하나를 선택해 CPU를 할당한다. 결국 다중 프로그래밍 환경에서는 CPU를 어떤 순서로 사용할지 결정하는 과정, 즉 스케줄링이 필수적으로 요구된다.

The Illusion of Simultaneous Execution

The execution order is never directly exposed to the user. As a result, each program appears to run independently. The browser opens pages on its own; the messenger displays notifications on its own.

But in reality, the operating system is coordinating all of these execution flows behind the scenes. It continuously decides which process to keep in the running state and when to switch to another.

Because this process is invisible to the user, we feel as though multiple programs are running simultaneously. This is what we call the illusion of concurrent execution — and making this illusion feel natural is one of the key roles of CPU scheduling.

사용자가 느끼는 동시 실행의 착시

실행 순서는 사용자에게 직접 노출되지 않는다. 그 결과 각 프로그램은 마치 독립적으로 실행되는 것처럼 보인다. 브라우저는 브라우저대로 페이지를 열고, 메신저는 메신저대로 알림을 표시한다.

하지만 실제로는 운영체제가 이 모든 실행 흐름을 보이지 않는 곳에서 조율하고 있다. 어떤 프로세스를 실행 상태로 둘 것인지, 언제 다른 프로세스로 전환할 것인지를 운영체제가 끊임없이 결정한다.

이 과정이 사용자 눈에 보이지 않기 때문에, 우리는 여러 프로그램이 동시에 실행되는 것처럼 느끼게 된다. 이것이 바로 동시 실행의 착시다. 그리고 이 착시를 자연스럽게 만드는 것이 곧 CPU 스케줄링의 역할이기도 하다.

The Secret of Apparent Simultaneous Execution

Why does it look like multiple programs are running at the same time? As mentioned, the CPU handles only one task at a time. Execution targets are processed one by one in order, not simultaneously.

The secret is in execution switching. The operating system pauses the currently running process and switches to another. When needed, it returns to the previous process. Because this switching repeats at very high speed, it feels to the user as though multiple programs are operating at once.

The key point is that multiple processes are not truly running at the same time. The operating system rapidly swaps out which process is using the CPU — this is the actual mechanism behind multi-programming environments.

실행 전환: 동시 실행의 비밀

왜 여러 프로그램이 동시에 실행되는 것처럼 보이는 걸까? 앞서 말했듯 CPU는 한 시점에 하나의 작업만 처리한다. 실행 대상은 동시에 처리되는 것이 아니라 순서를 정해 하나씩 처리된다.

그 비밀은 실행 전환에 있다. 운영체제는 현재 실행 중인 프로세스를 잠시 멈추고 다른 프로세스로 전환한다. 그리고 다시 필요해지면 이전에 실행하던 프로세스로 돌아온다. 이 전환이 매우 빠른 속도로 반복되기 때문에, 사용자 입장에서는 여러 프로그램이 동시에 작동하는 것처럼 느껴지는 것이다.

여기서 중요한 점은, 여러 프로세스를 진짜로 동시에 실행하는 것이 아니라는 사실이다. 운영체제가 실행 대상을 빠르게 바꾸면서 CPU를 나눠 쓰는 방식, 이것이 다중 프로그래밍 환경의 실제 동작 원리다.

How Is the Next Process Selected?

We now know the CPU alternates between multiple execution targets. A natural question follows: among the many processes in the ready state, who gets the CPU first?

This is not simply a matter of ordering. Which task runs first directly affects the overall behavior and performance of the system. If a heavy task occupies the CPU for a long time, lighter tasks the user is waiting for will be delayed accordingly.

So who makes this decision? The operating system does. It judges what criteria to use when selecting the next process to run, and this judgment directly affects the response speed and efficiency that users experience.

Ultimately, how execution order is determined governs the system's performance and capability. This is why CPU scheduling is considered a core responsibility of the operating system, not just a routine management task.

실행 대상은 어떻게 선택될까?

CPU가 여러 실행 대상을 번갈아 처리한다는 것을 알았다. 그렇다면 자연스럽게 다음 질문이 생긴다. 준비 상태에 있는 여러 프로세스 중 누가 먼저 CPU를 사용할 것인가?

이 선택은 단순한 순서의 문제가 아니다. 어떤 작업을 먼저 실행하느냐에 따라 시스템 전체의 동작 방식과 성능이 직접적으로 달라진다. 예를 들어 무거운 작업이 CPU를 오래 점유하면, 사용자가 기다리는 가벼운 작업은 그만큼 늦게 처리된다.

그렇다면 이 순서는 누가 결정하는 걸까? 바로 운영체제다. 운영체제는 어떤 기준으로 다음 실행할 프로세스를 선택할지 판단하며, 이 판단이 사용자가 체감하는 반응 속도와 시스템 효율에 직결된다.

결국 실행 순서를 어떻게 정하느냐가 시스템의 성능과 가능성을 좌우한다. 이것이 CPU 스케줄링이 단순한 관리 기법을 넘어 운영체제의 핵심 역할로 다뤄지는 이유다.

The Ready Queue and CPU Scheduling

A process does not stay in one place — it moves through a flow of states.

At the center of that flow is the Ready Queue. The ready queue is where processes waiting to be assigned the CPU gather. Processes that are prepared to execute but have not yet received the CPU wait here.

When a process requests I/O, it leaves the CPU and moves to an I/O device queue. Once the I/O completes, it returns to the ready queue to wait for the CPU again. Processes continuously move between these two queues based on their state.

The important point is that CPU scheduling happens in the ready queue. The operating system selects one process from the ready queue and assigns it the CPU — and this selection process is CPU scheduling itself.

준비 큐와 CPU 스케줄링

프로세스는 한 곳에 머무르는 것이 아니라, 상태에 따라 이동하는 흐름으로 구성되어 있다.

그 흐름의 중심에 준비 큐(Ready Queue) 가 있다. 준비 큐는 CPU를 할당받기 위해 기다리는 프로세스들이 모여 있는 공간이다. 실행 준비는 완료되었지만 아직 CPU를 받지 못한 상태의 프로세스들이 여기에 대기한다.

한편 프로세스가 입출력을 요청하면 CPU를 떠나 입출력 장치 큐로 이동한다. 입출력 작업이 끝나면 다시 준비 큐로 돌아와 CPU 할당을 기다린다. 이처럼 프로세스는 준비 큐와 입출력 장치 큐 사이를 상태에 따라 오가는 구조다.

중요한 점은 CPU 스케줄링은 준비 큐에서 일어난다는 것이다. 운영체제는 준비 큐에 있는 프로세스 중 하나를 선택해 CPU를 할당하며, 이 선택 과정 자체가 바로 CPU 스케줄링이다.

What CPU Scheduling Means

In an environment where multiple processes share a single CPU, many processes may be ready to execute. But only one can actually use the CPU at any given moment. The operating system must therefore choose which of the candidate processes to transition into the running state.

This process of deciding which process to run next among many candidates is CPU scheduling. Put simply, CPU scheduling is the operating system's decision-making process for determining which process executes first.

CPU 스케줄링의 의미

지금까지의 내용을 바탕으로 CPU 스케줄링의 의미를 정리해보자.

하나의 CPU를 여러 프로세스가 함께 사용하는 환경에서는 실행 가능한 프로세스가 여러 개 존재한다. 하지만 실제로 CPU를 사용하는 대상은 한 시점에 단 하나다. 따라서 운영체제는 여러 프로세스 후보 중에서 어떤 프로세스를 실행 상태로 전환할지 선택해야 한다.

이처럼 여러 프로세스 중에서 실행할 대상을 결정하는 과정이 바로 CPU 스케줄링이다. 다시 말해, CPU 스케줄링이란 어떤 프로세스를 먼저 실행할지를 판단하는 운영체제의 결정 과정이라고 할 수 있다.

When Does CPU Scheduling Occur?

A process stays in the ready state until it is assigned the CPU. The operating system selects one ready process and transitions it to the running state. In other words, CPU scheduling occurs at the moment a process transitions from the ready state to the running state.

An important nuance: scheduling does not happen at every state change. It only occurs when the CPU needs to be newly assigned — when a new process must be chosen to run.

CPU 스케줄링은 언제 발생할까?

CPU 스케줄링이 무엇인지 알았다면, 이제 그것이 언제 일어나는지를 살펴보자.

프로세스는 CPU를 할당받기 전까지 준비 상태에 머문다. 운영체제는 준비 상태에 있는 프로세스 중 하나를 선택해 실행 상태로 전환한다. 즉, CPU 스케줄링은 프로세스가 준비 상태에서 실행 상태로 전환되는 순간에 발생한다.

여기서 중요한 점은, 모든 상태 변화에서 스케줄링이 발생하는 것이 아니라는 것이다. CPU를 새로 할당해야 하는 시점, 즉 실행할 프로세스를 새로 골라야 하는 순간에만 스케줄링이 이루어진다.

When Does Scheduling Repeat?

After a process is created, it moves through various states. For example, when a running process transitions from the running state to the waiting state due to an I/O request or time expiration, the CPU becomes idle. The operating system then selects another process from the ready state and assigns the CPU to it. Once the I/O completes, the process returns to the ready state and becomes a candidate for the next execution.

In this way, scheduling occurs repeatedly every time a process undergoes a state change.

It is worth noting that throughout this process, the long-term, medium-term, and short-term schedulers each intervene at different points. For now, however, it is enough to understand the overall structure. The specific role of each scheduler will be covered separately in the next session.

스케줄링은 언제 반복되는가?

프로세스는 생성 이후 여러 상태를 오가게 된다. 예를 들어 실행 중이던 프로세스가 입출력 요청이나 시간 만료로 인해 실행 상태에서 대기 상태로 이동하면, CPU는 비게 된다. 그러면 운영체제는 준비 상태에 있는 다른 프로세스를 선택해 CPU를 할당한다. 입출력이 끝난 프로세스는 다시 준비 상태로 돌아와 다음 실행 대상의 후보가 된다.

이처럼 프로세스의 상태 변화가 일어날 때마다 스케줄링은 반복적으로 발생한다.

한편 이 과정에는 단기, 중기, 장기 스케줄러가 각각 서로 다른 지점에서 개입한다. 다만 이번 내용에서는 전체적인 구조만 이해하는 것으로 충분하다. 각 스케줄러의 구체적인 역할은 다음 시간에 따로 다룰 예정이다.

The Repeated Cycle of Process State Changes and Scheduling

After creation, a process continuously cycles between ready, running, and waiting states. Each time a state change occurs, scheduling happens again.

Scheduling is not a one-time event. It is a continuous decision process that repeats every time a process changes state. When a running process transitions to a waiting state due to an I/O request or time expiration, the CPU becomes free, and a process that returns to the ready state becomes a candidate again.

Ultimately, scheduling is required every time the CPU becomes idle. The operating system selects the next process from the ready queue at each such moment, and this cycle repeats continuously for as long as the system runs.

프로세스 상태 변화와 스케줄링

프로세스는 생성 이후 준비, 실행, 대기 상태 사이를 계속해서 오간다. 그리고 이 상태 변화가 일어날 때마다 스케줄링은 반복적으로 발생한다.

즉, 스케줄링은 한 번으로 끝나는 과정이 아니다. 프로세스의 상태 전환이 일어날 때마다 계속 이루어지는 결정 과정이다. 실행 중이던 프로세스가 입출력 요청이나 시간 만료로 인해 상태가 바뀌면 CPU는 비게 되고, 준비 상태로 돌아온 프로세스는 다시 선택 대상이 된다.

결국 CPU가 비는 순간마다 스케줄링이 필요하다. 운영체제는 그 순간마다 준비 큐에서 다음 실행할 프로세스를 선택하고, 이 과정이 시스템이 동작하는 내내 끊임없이 반복된다.

Why Is CPU Scheduling Necessary?

The CPU can only process one task at a time. Yet execution requests continuously arrive from multiple sources simultaneously. Many tasks demand the CPU at once, and the CPU cannot handle them all immediately.

Therefore, a process for deciding which task to handle first — determining execution order — is absolutely necessary. Without establishing execution order, the system cannot function normally.

Deciding execution order is not optional. CPU scheduling is a structurally necessary process in any multi-programming environment.

CPU 스케줄링은 왜 필요한가?

CPU는 한 시점에 하나의 작업만 처리할 수 있다. 그러나 실행 요청은 계속해서 여러 곳에서 동시에 발생한다. 여러 작업이 동시에 CPU를 요구하지만, CPU는 그 모든 요청을 즉시 처리할 수 없다.

따라서 어떤 작업을 먼저 처리할 것인지, 실행 순서를 결정하는 과정이 반드시 필요하다. 만약 실행 순서를 정하지 않는다면 시스템은 정상적으로 동작할 수 없게 된다.

결국 실행 순서를 정한다는 것은 선택의 문제가 아니다. CPU 스케줄링은 다중 프로그래밍 환경에서 구조적으로 반드시 필요한 과정이다.

Why Execution Order Matters

The result of scheduling ultimately manifests as waiting time. Depending on which task is selected first, the time other tasks must wait before receiving the CPU changes — and so does when they get a response.

Users have no visibility into which algorithm the system uses internally. Instead, they evaluate the system based on how quickly the screen responds and how fast requests are answered. Even with the same resources and tasks, the performance users perceive can vary significantly depending on execution order.

In other words, scheduling is not merely about setting an order of execution. It is a critical factor that determines the performance users experience.

실행 순서가 중요한 이유

그렇다면 실행 순서는 왜 중요할까? 스케줄링의 결과는 결국 대기 시간으로 나타난다. 어떤 작업을 먼저 선택하느냐에 따라 다른 작업이 CPU를 받을 때까지 기다려야 하는 시간이 달라지고, 그에 따라 응답 시점도 달라지기 때문이다.

사용자는 시스템 내부에서 어떤 알고리즘이 사용되는지 알지 못한다. 대신 화면이 얼마나 빨리 반응하는지, 요청에 얼마나 빠르게 응답하는지를 기준으로 시스템을 평가한다. 같은 자원, 같은 작업이라도 실행 순서에 따라 사용자가 체감하는 성능은 크게 달라질 수 있다.

즉, 스케줄링은 단순히 실행 순서를 정하는 문제가 아니다. 사용자가 느끼는 시스템의 성능을 결정하는 핵심 요소다.

The Purpose of CPU Scheduling

The CPU is the busiest resource in any system. Since multiple tasks are constantly competing for it, minimizing idle CPU time is essential. How execution opportunities are divided among tasks is equally important.

The goal is not simply to finish any particular task quickly. How execution opportunities are distributed directly determines the overall performance of the system.

The purpose of CPU scheduling is to use the CPU efficiently while improving total system performance. Scheduling is the operating system's strategy for maximizing performance without wasting CPU resources.

CPU 스케줄링의 목적

지금까지 왜 실행 순서를 정해야 하는지 살펴보았다. 그렇다면 스케줄링은 무엇을 잘하기 위해 존재하는 걸까?

CPU는 시스템에서 가장 바쁜 자원이다. 여러 작업이 동시에 CPU를 기다리는 상황이 반복되기 때문에, CPU가 쉬고 있는 상황을 최소화하는 것이 중요하다. 동시에 여러 작업에게 실행 기회를 어떻게 나눌지도 핵심적인 문제다.

여기서 중요한 점은, 단순히 어떤 작업을 빨리 끝내는 것이 목표가 아니라는 것이다. 실행 기회를 어떻게 분배하느냐에 따라 전체 시스템의 성능이 달라지기 때문이다.

결국 CPU 스케줄링의 목적은 CPU를 효율적으로 사용하면서 전체 시스템의 성능을 향상시키는 것이다. 즉, 스케줄링은 CPU를 낭비하지 않으면서 시스템 성능을 높이기 위한 운영체제의 전략이라고 볼 수 있다.

Another Goal: Fairness and Stability

The goal of CPU scheduling is not performance alone. Efficiency matters, but in an environment where many processes share the CPU, fairness is also critical.

No single process should be allowed to monopolize the CPU indefinitely. Nor should any process go unselected for so long that it waits forever — this situation is called starvation, and when it recurs, trust in the system erodes.

As the number of competing tasks grows, competition intensifies. If scheduling criteria are designed to favor certain tasks, others will consistently be pushed back. When this happens repeatedly, it becomes difficult to predict when any given task will execute, and responsiveness suffers.

Scheduling is therefore not just a matter of increasing throughput. It is equally a matter of maintaining fairness and stable responsiveness.

스케줄링의 또 다른 목표: 공정성과 안정성

CPU 스케줄링의 목표는 성능 향상만이 아니다. CPU를 효율적으로 사용하는 것도 중요하지만, 여러 프로세스가 함께 사용하는 환경에서는 공정성도 중요한 요소다.

특정 프로세스가 CPU를 계속 독점하는 상황은 발생해선 안 된다. 또한 어떤 프로세스가 오랫동안 선택받지 못해 계속 대기하는 상황도 문제가 된다. 이를 기아 상태(Starvation) 라고 하며, 이 상태가 반복되면 시스템에 대한 신뢰가 떨어질 수밖에 없다.

실행을 요구하는 작업이 많아질수록 작업 간 경쟁도 심해진다. 이때 스케줄링 기준이 특정 작업에 유리하게 설계되어 있다면, 일부 작업은 계속 밀릴 수밖에 없다. 이런 상황이 반복되면 어떤 작업이 언제 실행될지 예측하기 어려워지고, 응답성에도 부정적인 영향을 미치게 된다.

따라서 스케줄링은 단순히 처리 속도를 높이는 문제가 아니라, 공정성과 안정적인 응답성을 함께 유지하는 문제이기도 하다.

Why Multiple Scheduling Approaches Are Needed

Can a single execution-order criterion apply to every situation? The priorities vary by system purpose. Sometimes fast response is critical; sometimes total throughput matters more; sometimes fairness is the top priority. The most appropriate scheduling approach depends on which criterion takes precedence.

The operating system selects an execution-order criterion to match the system's purpose, and the system's performance characteristics change accordingly. This is why many different scheduling approaches exist rather than just one.

The specific behavior of each scheduling algorithm will be examined in detail in the next session.

왜 다양한 스케줄링 방식이 필요한가?

지금까지 스케줄링이 CPU의 효율적 사용뿐 아니라 공정성과 안정성도 함께 추구해야 한다는 것을 살펴보았다. 여기서 한 가지 질문이 생긴다. 모든 상황에 동일한 실행 순서 기준을 적용할 수 있을까?

시스템의 목적에 따라 우선순위는 달라진다. 빠른 응답이 중요한 경우도 있고, 전체 처리량이 더 중요한 경우도 있으며, 공정성이 최우선인 경우도 있다. 어떤 기준을 우선하느냐에 따라 더 적합한 스케줄링 방식이 달라지는 것이다.

따라서 운영체제는 시스템의 목적에 맞는 실행 순서 기준을 선택하게 되고, 그 기준에 따라 시스템의 성능 특성도 달라진다. 이것이 스케줄링 방식이 하나가 아니라 여러 가지 존재하는 이유다.

각각의 스케줄링 알고리즘이 구체적으로 어떻게 동작하는지는 다음 시간에 자세히 살펴볼 예정이다.

2️⃣ Management Structure and Selection Criteria of CPU Scheduling

Why the Operating System Manages Execution Order

Multiple processes simultaneously request CPU execution. But because the CPU is a single resource, it cannot handle all requests at once. The result is that processes compete for one CPU.

Without a criterion for which process to run first, certain processes may monopolize the CPU and execution order becomes unpredictable. The operating system must therefore directly select and manage which ready process runs next.

What criterion guides that selection? This is the central question of CPU scheduling, and the various algorithms that answer it will be explored in the next session.

CPU 실행 순서는 왜 운영체제가 관리하는가?

현재 시스템에는 여러 프로세스가 동시에 CPU 실행을 요청한다. 그러나 CPU는 하나의 자원이기 때문에 모든 요청을 동시에 처리할 수 없다. 결국 여러 프로세스가 CPU 하나를 두고 경쟁하는 구도가 만들어진다.

이때 어떤 프로세스를 먼저 실행할지에 대한 기준이 없다면, 특정 프로세스가 CPU를 독점하거나 실행 순서를 예측하기 어려운 상황이 발생한다. 따라서 운영체제가 준비 상태에 있는 프로세스 중 어떤 것을 먼저 실행할지를 직접 선택하고 관리해야 한다.

그렇다면 그 선택은 어떤 기준으로 이루어질까? 이것이 바로 CPU 스케줄링의 핵심 질문이며, 다음 시간에는 이 기준들, 즉 다양한 스케줄링 알고리즘을 구체적으로 살펴볼 예정이다.

Why Execution Order Must Be Managed

In a modern system, multiple processes can request CPU execution at the same time. However, because the CPU is a single shared resource, all processes must take turns using it. Furthermore, execution requests can overlap in time — meaning situations where multiple processes simultaneously compete for the same CPU can arise at any moment.

In such an environment, conflicts over execution order arise naturally. Without a criterion for deciding which process runs first, certain processes may end up holding the CPU for an extended period, and execution results become difficult to predict.

For this reason, a structure that systematically manages CPU execution order is absolutely necessary. This is the fundamental reason why the operating system is responsible for CPU scheduling.

실행 순서가 관리되어야 하는 이유

현재 시스템에서는 여러 프로세스가 동시에 CPU 실행을 요청할 수 있다. 그러나 CPU는 하나의 자원이기 때문에 여러 프로세스가 함께 공유해서 사용해야 한다. 더불어 실행 요청은 시간적으로 겹쳐서 발생할 수 있다. 즉, 여러 프로세스가 같은 CPU를 두고 동시에 실행을 요구하는 상황이 언제든 생길 수 있다.

이런 환경에서는 자연스럽게 실행 순서 충돌이 발생한다. 어떤 프로세스를 먼저 실행할지에 대한 기준이 없다면 특정 프로세스가 CPU를 오래 독점하게 되고, 실행 결과 역시 예측하기 어려워진다.

따라서 이러한 환경에서는 CPU 실행 순서를 체계적으로 관리하는 구조가 반드시 필요하다. 이것이 운영체제가 CPU 스케줄링을 담당하는 근본적인 이유다.

What Does the Operating System Manage, and How?

We established that a structure for managing CPU execution order is necessary. So what exactly does the operating system manage, and how does it do so?

First, the subject of management is the pool of candidate processes registered in the ready queue - processes that are in an executable state but have not yet been assigned the CPU. These processes are not simply waiting; they are candidates that the operating system can select as the next execution target.

Next, looking at the method of management: the operating system maintains a waiting order based on the ready queue and selects one process from it to transition into the running state. The entity that performs this selection is the scheduler.

To summarize, CPU scheduling is the process of selecting the next execution target from among the candidates in the ready queue.

운영체제는 무엇을, 어떻게 관리하는가?

CPU 실행 순서를 관리하는 구조가 필요하다고 했다. 그렇다면 운영체제는 구체적으로 무엇을, 어떻게 관리하는 걸까?

먼저 관리 대상은 준비 큐에 등록된 실행 후보 프로세스들이다. 실행 가능한 상태에 있으면서도 아직 CPU를 할당받지 못한 프로세스들이 여기에 해당한다. 이 프로세스들은 단순히 대기하는 것이 아니라, 운영체제가 다음 실행 대상으로 선택할 수 있는 후보들이다.

다음으로 관리 방식을 살펴보면, 운영체제는 준비 큐를 기반으로 대기 순서를 유지하고 그 중 하나의 프로세스를 선택해 실행 상태로 전환한다. 이 선택을 수행하는 주체가 바로 스케줄러다.

정리하면, CPU 스케줄링이란 준비 큐에 있는 실행 후보 중에서 다음 실행 대상을 선택하는 과정이다.

The Scheduling Queue

The scheduling queue is a data structure that collects and manages processes waiting to execute. In data structures, a queue follows FIFO (First In, First Out) — the first element in is the first one out. The operating system uses this structure to manage process waiting states.

There are two fundamental types of scheduling queues. The ready queue holds processes in an executable state that are waiting for CPU allocation — CPU scheduling operates on these processes. The I/O device queue is where processes go when they issue an I/O request during execution; once I/O completes, they return to the ready queue.

Both are queues in structure, but they are managed separately based on what is being waited for and what role each plays.

스케줄링 큐란 무엇인가?

앞서 실행 후보 프로세스들이 준비 큐를 중심으로 관리된다고 했다. 이처럼 실행을 기다리는 프로세스들을 모아서 관리하는 자료구조를 일반적으로 스케줄링 큐(Scheduling Queue) 라고 부른다.

스케줄링 큐에는 CPU를 바로 사용할 수는 없지만 실행 가능한 상태에 있는 프로세스들이 등록된다. 즉, 스케줄링 큐는 CPU 할당 대상이 되는 프로세스들의 집합이며, 운영체제는 이 큐에 있는 프로세스들을 대상으로 다음 실행 대상을 선택한다.

정리하면, 스케줄링 큐는 실행 대기 프로세스를 체계적으로 관리하고 실행 순서를 결정하기 위한 기준이 되는 구조다. CPU 스케줄링은 결국 이 큐를 어떻게 운용하느냐의 문제라고도 볼 수 있다.

Process Execution Flow Based on the Scheduling Queue

Let's trace how a process flows through the system centered on the scheduling queue.

When one of the processes waiting in the ready queue is selected, it is assigned the CPU and transitions to the running state. If the process requires I/O during execution, it temporarily leaves the CPU and moves to the I/O device queue. Once the I/O completes, the process returns to the ready queue and becomes a candidate for execution again. When all of its work is finished, the process moves to the terminated state.

Throughout this flow, the operating system continuously selects the next execution target from the processes in the ready queue. CPU scheduling is ultimately the core mechanism that sustains this entire cyclical flow.

스케줄링 큐 기반 프로세스 실행 흐름

스케줄링 큐를 중심으로 프로세스가 어떻게 흘러가는지 정리해보자.

준비 큐에서 대기 중인 프로세스 중 하나가 선택되면 CPU를 할당받아 실행 상태로 전환된다. 실행 중에 입출력이 필요해지면 프로세스는 잠시 CPU를 떠나 입출력 장치 큐로 이동한다. 입출력이 완료되면 해당 프로세스는 다시 준비 큐로 돌아와 실행 후보가 된다. 그리고 모든 작업이 끝나면 프로세스는 종료 상태로 이동한다.

이 흐름 속에서 운영체제는 준비 큐에 있는 프로세스 중 다음 실행 대상을 끊임없이 선택한다. 결국 CPU 스케줄링은 이 순환적인 흐름 전체를 지탱하는 핵심 메커니즘이라고 할 수 있다.

Types of Scheduling Queues

In data structures, a queue follows a First In, First Out (FIFO) principle — the first element to enter is the first to leave. The operating system uses this structure to manage the waiting states of processes.

However, there is not just one queue. There are two fundamental types.

The first is the Ready Queue. This is where processes in an executable state wait for CPU allocation. CPU scheduling operates on the processes held in this queue.

The second is the I/O Device Queue. This is where a process goes when it issues an I/O request during execution. It waits here until the I/O completes, at which point it returns to the ready queue.

Both share the same queue structure, but the key point is that they are managed as separate queues based on what is being waited for and what role each serves.

스케줄링 큐의 종류

자료구조에서 큐(Queue)는 먼저 들어온 데이터가 먼저 나가는 선입선출(FIFO, First In First Out) 구조다. 운영체제도 이 큐를 활용해 프로세스의 대기 상태를 관리한다.

다만 이 큐가 하나만 존재하는 것이 아니다. 대표적인 기본 큐는 두 가지다.

첫 번째는 준비 큐(Ready Queue) 다. CPU 할당을 기다리는 실행 가능한 상태의 프로세스들이 모여 있는 공간이며, CPU 스케줄링은 바로 이 준비 큐에 있는 프로세스들을 대상으로 이루어진다.

두 번째는 입출력 장치 큐(I/O Device Queue) 다. 실행 도중 입출력을 요청한 프로세스가 이동하는 공간이다. 입출력이 완료될 때까지 여기서 대기하다가, 완료되면 다시 준비 큐로 돌아온다.

구조는 모두 큐이지만, 기다리는 대상과 역할에 따라 서로 다른 큐로 나누어 관리된다는 점이 핵심이다.

Scheduling Is Not a Single Decision

Scheduling does not occur only once. The operating system manages execution at multiple points in time, each serving a different purpose.

For example, when a new job enters the system, there is a stage for deciding whether to accept it right now. When the number of executable processes grows large, there is a stage for deciding which processes to keep in memory. And when the CPU actually becomes idle, a stage is needed to select which ready process to run immediately.

Scheduling is therefore not a single decision — it is a structure composed of multiple management stages. Each stage intervenes at a different point in time and for a different purpose, collectively coordinating the overall execution flow of the system.

스케줄링은 하나의 결정이 아니다

스케줄링은 하나의 순간에만 이루어지는 과정이 아니다. 운영체제는 시스템의 여러 시점에서 서로 다른 목적을 가지고 실행을 관리한다.

예를 들어 시스템에 새로운 작업이 들어올 때, 이 작업을 지금 받아들일지 결정하는 단계가 있다. 실행 가능한 프로세스가 많아지면 어떤 프로세스를 메모리에 유지할지 조절하는 단계도 존재한다. 그리고 실제로 CPU가 비는 순간이 되면, 준비 상태에 있는 프로세스 중 지금 당장 실행할 대상을 선택하는 단계가 필요하다.

이처럼 스케줄링은 단일한 결정이 아니라, 여러 관리 단계로 나누어 이루어지는 구조다. 각 단계는 서로 다른 시점에, 서로 다른 목적을 위해 개입하며 전체 시스템의 실행 흐름을 함께 조율한다.

The Long-Term Scheduler

When a program requests execution, the job first waits on disk. However, because memory capacity is limited, not all jobs can be loaded into memory immediately. This is where the long-term scheduler intervenes.

The long-term scheduler selects which jobs on disk to load into memory. Rather than deciding who gets the CPU, it decides which jobs to admit into the system as execution candidates. Because the number of processes loaded into memory determines how many processes can exist in the ready state at any given time, the long-term scheduler effectively controls the degree of multi-programming.

It is also worth noting that this decision does not happen frequently — it occurs intermittently, only as new jobs arrive.

장기 스케줄러

프로그램이 실행을 요청하면 해당 작업은 우선 디스크에서 대기한다. 그러나 메모리 용량에는 한계가 있기 때문에 모든 작업을 바로 메모리에 올릴 수는 없다. 이때 개입하는 것이 장기 스케줄러(Long-term Scheduler) 다.

장기 스케줄러는 디스크에 존재하는 작업 중 어떤 작업을 메모리에 올릴지 선택한다. 즉, CPU를 누구에게 줄지 결정하는 것이 아니라, 어떤 작업을 실행 후보로 시스템 안에 들여보낼 것인가를 결정하는 단계다. 메모리에 올라온 프로세스의 수에 따라 동시에 준비 상태로 존재하는 프로세스의 수가 달라지기 때문에, 장기 스케줄러는 곧 다중 프로그래밍의 정도를 결정하는 역할을 한다.

또한 이 결정은 자주 일어나는 것이 아니라, 새로운 작업이 유입될 때마다 간헐적으로 발생한다는 점도 기억해두자.

Summary of the Long-Term Scheduler's Role

Let's trace the long-term scheduler's flow of operation.

When a job arrives on disk, the long-term scheduler intervenes and selects which jobs to load into memory. Selected jobs are loaded into memory and registered as processes in the ready queue. From there, the short-term scheduler selects one of the processes in the ready queue and has it executed by the CPU.

In summary, the long-term and short-term schedulers divide their responsibilities across different stages. The long-term scheduler decides which jobs enter the system, while the short-term scheduler selects the actual CPU execution target. The specific behavior of the short-term scheduler will be examined in a later session.

장기 스케줄러의 역할 정리

장기 스케줄러의 동작 흐름을 정리해보자.

작업이 디스크에 도착하면 장기 스케줄러가 개입해 디스크에 있는 작업 중 어떤 것을 메모리에 올릴지 선택한다. 선택된 작업은 메모리에 올라와 준비 큐에 등록된 프로세스가 된다. 이후 단기 스케줄러(Short-term Scheduler) 가 준비 큐에 있는 프로세스 중 하나를 선택해 CPU에 의해 실행되도록 한다.

결론적으로 장기 스케줄러와 단기 스케줄러는 서로 다른 단계에서 역할을 나눠 담당한다. 장기 스케줄러는 시스템에 들어올 작업을 결정하고, 단기 스케줄러는 실제 CPU 실행 대상을 선택한다. 단기 스케줄러의 구체적인 동작은 추후에 살펴볼 예정이다.

The Medium-Term Scheduler

Even after the long-term scheduler loads jobs into memory, the state of memory continues to change. As the number of running or ready processes grows, memory can become scarce. This is where the medium-term scheduler intervenes.

The medium-term scheduler temporarily suspends some of the processes currently in memory, a process known as swap-out. Conversely, when memory space becomes available, it reloads suspended processes back into memory — a process known as swap-in.

In other words, the medium-term scheduler is responsible for regulating the number of processes maintained in memory. If the long-term scheduler controls how much work enters the system, the medium-term scheduler balances memory resources among the jobs already inside.

중기 스케줄러

장기 스케줄러가 작업을 메모리로 들여보낸 이후에도 메모리 상태는 계속 변한다. 실행 중이거나 준비 중인 프로세스가 많아지면 메모리가 부족해질 수 있는데, 이때 개입하는 것이 중기 스케줄러(Medium-term Scheduler) 다.

중기 스케줄러는 메모리에 올라와 있는 프로세스 중 일부를 일시적으로 중단 상태로 전환한다. 이 과정을 스왑 아웃(Swap-out) 이라고 한다. 반대로 메모리 공간에 여유가 생기면 중단된 프로세스를 다시 메모리로 불러오는데, 이 과정을 스왑 인(Swap-in) 이라고 한다.

즉, 중기 스케줄러는 메모리에 유지되는 프로세스의 수를 조절하는 역할을 담당한다. 장기 스케줄러가 시스템에 들어올 작업의 양을 결정한다면, 중기 스케줄러는 이미 들어온 작업들 사이에서 메모리 자원을 균형 있게 유지하는 역할을 한다고 이해하면 된다.

Summary of the Medium-Term Scheduler's Role

The medium-term scheduler manages processes that are already in memory — including both running and ready processes. When the number of processes causes memory to become overloaded, it suspends some of them and removes them from memory.

The defining characteristic of the medium-term scheduler is that it acts as a balancer between the long-term and short-term schedulers. While the long-term scheduler controls the volume of incoming work and the short-term scheduler determines which process gets the CPU, the medium-term scheduler adjusts the number of processes kept in memory to relieve system load.

중기 스케줄러의 역할 정리

중기 스케줄러의 관리 대상은 이미 메모리에 올라와 있는 프로세스다. 실행 중이거나 준비 상태에 있는 프로세스 모두가 여기에 포함된다. 시스템의 프로세스가 많아져 메모리가 과부하 상태가 되면, 중기 스케줄러는 이들 중 일부를 중단 상태로 전환해 메모리에서 내보낸다.

중기 스케줄러의 핵심 특징은 장기 스케줄러와 단기 스케줄러 사이에서 균형을 맞추는 조정자 역할을 한다는 점이다. 장기 스케줄러가 시스템에 들어오는 작업의 규모를 조절하고, 단기 스케줄러가 CPU 실행 대상을 결정한다면, 중기 스케줄러는 메모리에 유지되는 프로세스 수를 조정해 시스템 부하를 완화하는 역할을 담당한다.

The Short-Term Scheduler

The short-term scheduler selects which process in the ready queue to assign the CPU to. In other words, it is the stage that decides which of the many ready processes to transition into the running state right now.

This decision occurs very frequently. Every time a process terminates, an I/O request is made, or a time quantum expires, the short-term scheduler intervenes and selects the next execution target.

Among the three schedulers, the short-term scheduler has the most direct impact on system responsiveness and performance. All of the scheduling criteria and algorithms covered in later sessions are applied to this scheduler.

단기 스케줄러

단기 스케줄러(Short-term Scheduler)는 준비 큐에 있는 프로세스 중에서 CPU를 할당할 프로세스를 선택하는 역할을 한다. 즉, 준비 상태에 있는 여러 프로세스 중 지금 당장 실행 상태로 전환할 하나를 결정하는 단계다.

이 결정은 매우 자주 발생한다. 프로세스가 종료되거나, 입출력 요청이 발생하거나, 시간 할당량이 끝나는 순간마다 단기 스케줄러가 개입해 다음 실행 대상을 선택한다.

단기 스케줄러는 세 가지 스케줄러 중 시스템의 응답성과 성능에 가장 직접적인 영향을 미치는 스케줄러다. 이후에 배우게 될 다양한 스케줄링 기준과 알고리즘도 바로 이 단기 스케줄러에 적용된다.

The Dispatcher: Actually Handing Over the CPU

Once the short-term scheduler selects which process will use the CPU, the dispatcher intervenes in the next step. The dispatcher is the execution module responsible for actually transferring CPU control to the selected process. During this process, a context switch takes place, and the system transitions to user mode to begin actual execution.

To summarize the roles: the short-term scheduler decides who runs, and the dispatcher handles the transition to the running state. In other words, at the moment a process moves from the ready state to the running state, the short-term scheduler and the dispatcher work together.

디스패처: CPU를 실제로 넘기는 역할

단기 스케줄러가 준비 큐에 있는 프로세스 중 CPU를 사용할 프로세스를 선택하면, 그 다음 단계에서 디스패처(Dispatcher) 가 개입한다. 디스패처는 선택된 프로세스에게 CPU 제어를 실제로 넘기는 실행 담당 모듈이다. 이 과정에서 문맥 교환(Context Switching)이 이루어지며, 사용자 모드로 전환해 실제 실행이 시작된다.

역할을 정리하면 다음과 같다. 단기 스케줄러는 누구를 실행할지 결정하고, 디스패처는 실제 실행 상태로 전환하는 역할을 담당한다. 즉, 준비 상태에서 실행 상태로 넘어가는 순간에 단기 스케줄러와 디스패처가 함께 작동한다.

When the Short-Term Scheduler Intervenes

The short-term scheduler intervenes every time a specific event occurs. Concretely, it operates in the following situations.

When a running process terminates, when a process relinquishes the CPU due to an I/O request, when I/O completes and a process returns to the ready state, and when a time quantum expires or an interrupt occurs.

In this way, the short-term scheduler intervenes at every moment a process undergoes a state transition. Among the three schedulers — long-term, medium-term, and short-term — the short-term scheduler operates by far the most frequently.

단기 스케줄러의 개입 시점

단기 스케줄러는 특정 사건이 발생하는 순간마다 개입한다. 구체적으로는 다음과 같은 상황에서 작동한다.

실행 중인 프로세스가 종료될 때, 프로세스가 입출력 요청으로 인해 CPU를 반납할 때, 입출력이 완료되어 프로세스가 다시 준비 상태로 돌아올 때, 그리고 시간 할당량이 만료되거나 인터럽트가 발생할 때가 이에 해당한다.

이처럼 단기 스케줄러는 프로세스의 상태 전환이 이루어지는 순간마다 개입한다. 장기, 중기, 단기 세 가지 스케줄러 중에서 가장 빈번하게 동작하는 것이 바로 단기 스케줄러다.

Summary: Who Manages CPU Scheduling

Let's take a consolidated look at where each of the three schedulers intervenes in the process state transition flow.

The long-term scheduler decides which jobs to admit into memory at the creation stage — it selects which jobs on disk to load. The medium-term scheduler regulates the number of processes kept in memory by temporarily suspending some and reloading others. The short-term scheduler intervenes at the moment a process transitions from the ready state to the running state and selects which process to assign the CPU to.

These three schedulers intervene at different points in time, but they all operate together on a single process state transition flow. The system as a whole can only run stably when each scheduler's role interlocks properly with the others.

CPU 스케줄링의 관리 주체 정리

지금까지 배운 세 가지 스케줄러가 프로세스 상태 전이 흐름 속에서 어디에 개입하는지 한눈에 정리해보자.

장기 스케줄러는 생성 단계에서 메모리 진입을 결정한다. 디스크에 있는 작업 중 어떤 것을 메모리에 올릴지 선택하는 역할이다. 중기 스케줄러는 메모리 안에서 프로세스를 일시 중단하거나 다시 불러오는 방식으로 메모리에 유지되는 프로세스 수를 조절한다. 단기 스케줄러는 준비 상태에서 실행 상태로 넘어가는 순간에 개입해 CPU를 할당할 프로세스를 선택한다.

이 세 스케줄러는 서로 다른 시점에 개입하지만, 하나의 프로세스 상태 전이 흐름 위에서 함께 작동한다. 각자의 역할이 맞물려야 비로소 시스템 전체가 안정적으로 동작할 수 있다.

Preemptive vs. Non-Preemptive Scheduling

We said that the short-term scheduler intervenes every time a process state change occurs. This raises an important question: can the short-term scheduler forcibly stop a running process at any time?

The answer to this question divides scheduling into two major types. Preemptive scheduling can forcibly halt a running process and hand the CPU to another, while non-preemptive scheduling waits until the running process voluntarily relinquishes the CPU on its own.

Which approach is chosen significantly affects the system's responsiveness, fairness, and processing efficiency.

선점 vs 비선점 스케줄링

단기 스케줄러는 프로세스 상태 변화가 발생할 때마다 개입한다고 했다. 여기서 한 가지 중요한 질문이 생긴다. 단기 스케줄러는 실행 중인 프로세스를 언제든지 강제로 중단시킬 수 있을까?

이 질문에 대한 답에 따라 스케줄링 방식은 크게 두 가지로 나뉜다. 실행 중인 프로세스를 강제로 중단하고 다른 프로세스에게 CPU를 넘길 수 있는 선점 스케줄링(Preemptive Scheduling) 과, 실행 중인 프로세스가 스스로 CPU를 반납할 때까지 기다리는 비선점 스케줄링(Non-preemptive Scheduling) 이다.

어떤 방식을 선택하느냐에 따라 시스템의 응답성, 공정성, 그리고 처리 효율이 달라진다.

Non-Preemptive Scheduling

In non-preemptive scheduling, a process that has been assigned the CPU continues running until it terminates on its own or transitions to a waiting state due to an I/O request. The operating system does not intervene midway to forcibly stop the running process.

The advantage of this approach is that it is structurally simple and incurs low management overhead. Because context switches do not occur frequently, overall overhead remains low.

However, if a long-running task claims the CPU first, all other processes must wait until that task finishes. This can result in response delays, which is the key drawback.

Ultimately, non-preemptive scheduling can be understood as a structure that allows a process to keep running until it voluntarily gives up the CPU.

비선점 스케줄링

비선점 스케줄링(Non-preemptive Scheduling)은 CPU를 할당받은 프로세스가 스스로 종료되거나 입출력 요청으로 인해 대기 상태로 전환될 때까지 계속 실행되는 방식이다. 즉, 운영체제가 중간에 개입해 실행 중인 프로세스를 강제로 중단시키지 않는다.

이 방식의 장점은 구조가 단순하고 관리 부담이 적다는 것이다. 문맥 교환이 자주 발생하지 않기 때문에 오버헤드도 낮다.

그러나 실행 시간이 긴 작업이 먼저 CPU를 점유하면, 그 작업이 끝날 때까지 다른 프로세스는 계속 기다려야 한다. 이로 인해 응답 지연이 발생할 수 있다는 것이 단점이다.

결국 비선점 방식은 프로세스가 CPU를 자발적으로 반납할 때까지 실행을 계속 허용하는 구조라고 이해하면 된다.

Preemptive Scheduling

In preemptive scheduling, the operating system can reclaim the CPU from a running process whenever it judges this to be necessary. If the time quantum expires or a higher-priority process becomes ready, the currently running task can be halted and replaced with another process.

Rather than waiting for a process to give up the CPU on its own, the operating system directly intervenes and changes the execution flow. This approach prevents any single task from monopolizing the CPU for too long, making it well-suited for improving system responsiveness. The downside is that a context switch occurs every time a process is replaced, which can introduce additional overhead.

To summarize the difference simply: non-preemptive scheduling never takes the CPU away, while preemptive scheduling can reclaim it when needed. The various CPU scheduling algorithms that determine actual execution order are built on top of these two approaches, and they will be examined one by one in the next session.

선점 스케줄링

선점 스케줄링(Preemptive Scheduling)에서는 운영체제가 필요하다고 판단하면 실행 중인 프로세스의 CPU를 중간에 회수할 수 있다. 시간 할당량이 만료되었거나 더 높은 우선순위의 프로세스가 준비 상태가 되면, 현재 실행 중인 작업을 중단시키고 다른 프로세스로 교체할 수 있다.

즉, 프로세스가 스스로 CPU를 반납하기를 기다리는 것이 아니라, 운영체제가 직접 개입해 실행 흐름을 바꿀 수 있는 구조다. 이 방식은 특정 작업이 CPU를 오래 독점하는 것을 막을 수 있어 시스템의 응답성을 높이는 데 유리하다. 다만 프로세스가 교체될 때마다 문맥 교환이 발생하기 때문에 추가적인 오버헤드가 생길 수 있다는 단점이 있다.

두 방식의 차이를 간단히 정리하면, 비선점은 CPU를 빼앗지 않고, 선점은 필요하다면 CPU를 회수할 수 있는 방식이다. 이 두 방식을 토대로 실제 실행 순서를 결정하는 다양한 CPU 스케줄링 알고리즘이 만들어지며, 이에 대해서는 다음 시간에 하나씩 살펴볼 예정이다.

CPU Scheduling Execution Flow

We have now examined the structure and management entities of CPU scheduling. Let's look at actual execution examples to see how the execution flow of processes plays out in practice.

In particular, we will explore why execution order in situations that appear to involve simultaneous multi-process operation can differ from what we might expect.

CPU 스케줄링 실행 흐름

지금까지 CPU 스케줄링의 구조와 관리 주체를 살펴보았다. 이번에는 실제 실행 예제를 통해 프로세스의 실행 흐름이 어떻게 나타나는지 확인해보자.

특히 여러 프로세스가 동시에 작동하는 것처럼 보이는 상황에서, 실행 순서가 왜 우리가 예상하는 것과 다르게 나타나는지도 함께 살펴볼 것이다.

We Do Not Decide Execution Order

Although multiple processes appear to run simultaneously, the CPU actually handles only one execution at a time. The CPU alternates between processes in very short time intervals, which makes it feel to the user as though everything is running concurrently.

The important point here is that we do not directly specify this execution order. The operating system decides it. As a result, execution outcomes may not always be identical. Even when running the same program, the operating system may make different choices depending on the state of the system at that moment.

실행 순서는 우리가 정하지 않는다

여러 프로세스가 동시에 실행되는 것처럼 보이지만, 실제 CPU는 한 번에 하나의 실행만 처리한다. CPU는 매우 짧은 시간 단위로 프로세스를 번갈아 실행하기 때문에, 사용자 입장에서는 동시에 실행되는 것처럼 느껴지는 것이다.

여기서 중요한 점은, 우리가 이 실행 순서를 직접 지정하지 않는다는 것이다. 실행 순서는 운영체제가 결정한다. 따라서 실행 결과가 항상 동일하게 나타나지 않을 수 있다. 같은 프로그램을 실행하더라도 그 순간의 시스템 상태에 따라 운영체제가 다른 선택을 할 수 있기 때문이다.

Apparent Concurrency in Practice

When fork() creates parent and child processes, both processes execute a loop, print output, and wait briefly.

Let's look at usleep(1000000) used in the example. While the familiar sleep() waits in units of seconds, usleep() waits in microseconds. usleep(1000000) means 1,000,000 microseconds — that is, 1 second. If the wait time is shortened further, the parent and child processes alternate CPU usage more frequently, causing their output to appear more densely interleaved. This example deliberately uses a short wait time to make the effect of scheduling-driven execution order changes more clearly visible.

The key thing to notice is the output order. In some runs, parent appears first; in others, child appears first. We did not specify this order, yet the operating system alternates between the two processes and their output becomes mixed.

This is an example of apparent concurrency. In reality the processes take turns, but the output looks as though they are running simultaneously.

실행 예제로 보는 겉보기 동시성

fork()를 통해 부모 프로세스와 자식 프로세스가 생성되면, 두 프로세스는 각각 반복문을 실행하며 출력하고 잠시 대기한다.

여기서 사용된 usleep(1000000)을 살펴보자. 기존에 사용하던 sleep()은 초 단위로 대기하지만, usleep()은 마이크로초 단위로 대기한다. usleep(1000000)은 1,000,000 마이크로초, 즉 1초를 의미한다. 만약 대기 시간을 더 짧게 줄이면 부모와 자식 프로세스가 더 자주 CPU를 번갈아 사용하게 되어 출력이 더 촘촘하게 섞여 나온다. 이 예제는 의도적으로 짧은 대기 시간을 활용해 스케줄링에 의해 실행 순서가 바뀌는 모습을 더 명확하게 보여주기 위한 것이다.

여기서 주목해야 할 점은 출력 순서다. 어떤 경우에는 parent가 먼저 출력되고, 어떤 경우에는 child가 먼저 출력된다. 우리가 이 순서를 지정하지 않았음에도 운영체제가 두 프로세스를 번갈아 실행하면서 결과가 섞여 나타나는 것이다.

이것이 바로 겉보기 동시성의 예다. 실제로는 번갈아 실행되지만, 출력은 마치 동시에 실행되는 것처럼 보인다.

The Non-Determinism of Execution Order

Apparent concurrency reveals an important characteristic: even with an identical program, the output order of execution results may differ from run to run.

Why does this happen? Because we did not directly specify which process receives the CPU first. Among the processes in the ready state, which one runs first depends on the scheduling decision made at that moment. In other words, the selection of the execution target is not fixed.

As a result, running the same program again may produce a different order of results. This property is called the non-determinism of execution order.

실행 순서의 비결정성

겉보기 동시성에서 한 가지 중요한 특징이 드러난다. 동일한 프로그램이더라도 실행 결과의 출력 순서가 매번 같지 않을 수 있다는 것이다.

왜 이런 일이 발생할까? CPU를 먼저 할당받을 프로세스를 우리가 직접 지정하지 않았기 때문이다. 준비 상태에 있는 프로세스 중 누가 먼저 실행될지는 그 순간의 스케줄링 판단에 따라 달라진다. 즉, 실행 대상의 선택은 고정되어 있지 않다.

따라서 동일한 프로그램을 다시 실행하면 결과 순서가 달라질 수 있다. 이를 실행 순서의 비결정성이라고 한다.

Observing Non-Determinism Through an Example

Consider an example that uses fork() to create parent and child processes. This time, rather than focusing on the fact that each process has an independent execution flow, we pay attention to the fact that output order differs between runs even with the same program.

The child process prints child and the parent process prints parent. The code has no loops and no wait functions. Yet in some runs parent appears first, and in others child appears first.

This is not because the code differs. It is because the process that receives the CPU first can vary at each execution. The selection of the execution target is not fixed — it is determined by the scheduling decision made at that moment.

This property — whereby execution result order can differ from run to run even with an identical program — is called the non-determinism of execution order. This example demonstrates that non-determinism in its simplest possible form.

실행 순서의 비결정성 — 예제로 확인하기

fork()를 이용해 부모와 자식 프로세스를 생성하는 예제를 살펴보자. 이번에는 두 프로세스가 각각 독립적인 실행 흐름을 가진다는 점보다, 같은 프로그램을 실행해도 출력 순서가 매번 같지 않다는 점에 주목한다.

자식 프로세스는 child를 출력하고, 부모 프로세스는 parent를 출력한다. 이 코드에는 반복문도 없고 대기 함수도 없다. 그럼에도 어떤 경우에는 parent가 먼저, 어떤 경우에는 child가 먼저 출력될 수 있다.

이 현상은 코드가 달라서가 아니다. CPU를 먼저 할당받는 대상이 실행 시점마다 달라질 수 있기 때문이다. 실행 대상의 선택은 고정되어 있지 않으며, 그 순간의 스케줄링 판단에 따라 결정된다.

이처럼 동일한 프로그램이더라도 실행 결과의 순서가 매번 달라질 수 있는 성질을 실행 순서의 비결정성이라고 한다. 이 예제는 그 비결정성을 가장 단순한 형태로 보여주는 코드다.

The Repeated Cycle of Execution and Waiting

To understand why execution order is not fixed, we need to revisit process state changes.

A process that enters the running state does not continue using the CPU indefinitely. When an I/O request occurs, the running process transitions to the waiting state. Once the wait completes, it returns to the ready state and becomes a candidate for execution again. The flow of running → waiting → running is not a one-time sequence — it is a repeating structure.

The key point is that the moment a process transitions to the waiting state, it can no longer use the CPU. As a result, the CPU becomes idle and the operating system selects another ready process.

In a structure where execution and waiting repeat like this, the entity using the CPU constantly changes. That is why CPU execution order is not fixed and continues to vary.

실행과 대기의 반복

실행 순서가 고정되어 있지 않은 이유를 이해하려면 프로세스의 상태 변화를 다시 생각해볼 필요가 있다.

프로세스는 한 번 실행 상태가 되었다고 해서 계속 CPU를 사용하는 것이 아니다. 실행 중이던 프로세스는 입출력 요청이 발생하면 대기 상태로 전환된다. 대기 작업이 끝나면 다시 준비 상태로 돌아와 실행 대상 후보가 된다. 즉, 실행 → 대기 → 실행의 흐름이 한 번으로 끝나는 것이 아니라 반복되는 구조다.

여기서 중요한 점은, 프로세스가 대기 상태로 전환되는 순간 해당 프로세스는 더 이상 CPU를 사용할 수 없게 된다는 것이다. 그 결과 CPU는 비게 되고, 운영체제는 준비 상태에 있는 다른 프로세스를 선택한다.

이처럼 실행과 대기가 반복되는 구조에서는 CPU를 사용하는 주체가 계속 바뀔 수밖에 없다. 그래서 CPU 실행 순서 역시 고정되지 않고 계속 달라질 수 있는 것이다.

Execution and Waiting in Practice

In the example code, the process prints CPU running, waits briefly, then prints I/O waiting, and waits again — this flow repeats.

The sleep() that follows printf("CPU running\n") does not mean the process keeps holding the CPU — it means the process transitions to a waiting state for a period. The repeating structure is: print CPU running → wait → print I/O waiting → wait.

This example simply illustrates the alternating structure of process execution and waiting. Each time such a state change occurs, the CPU can select a different execution target, and as a result execution order continues to vary.

예제로 보는 실행과 대기의 반복

예제 코드에서는 CPU running을 출력한 뒤 잠시 대기하고, 이어서 I/O waiting을 출력한 뒤 다시 대기하는 흐름이 반복된다.

여기서 printf("CPU running\n") 뒤에 오는 sleep()은 프로세스가 CPU를 계속 점유하는 것이 아니라, 잠시 대기 상태로 전환되는 것을 의미한다. 즉, CPU running 출력 → 대기 → I/O waiting 출력 → 대기의 흐름이 반복되는 구조다.

이 예제는 프로세스의 실행과 대기가 번갈아 나타나는 구조를 단순하게 보여준다. 이러한 상태 변화가 발생할 때마다 CPU는 다른 실행 대상을 선택할 수 있고, 그 결과 실행 순서는 계속 달라질 수 있다.

Preemptive Scheduling: Switching Without Waiting

The examples seen so far involved the CPU passing to another process when a process transitioned to the waiting state. In preemptive scheduling, however, the CPU can be switched even when a process is not in the waiting state.

In preemptive scheduling, the operating system can reclaim the CPU and reassign it to another process even if the current task has not finished. This allows shorter tasks or higher-priority tasks to be handled more quickly, making it well-suited for improving system responsiveness.

The downside is that a context switch occurs every time a process is swapped out, which can introduce additional overhead.

The key point here is that the operating system can intervene and reassign the CPU even when a process is not in the waiting state. This is the most significant difference from the non-preemptive approach.

선점 스케줄링: 대기 없이도 교체된다

앞서 살펴본 예제는 프로세스가 대기 상태로 전환될 때 CPU가 다른 프로세스에게 넘어가는 구조였다. 그런데 선점 스케줄링에서는 프로세스가 대기 상태가 아니더라도 CPU가 교체될 수 있다.

선점 스케줄링에서는 작업이 아직 끝나지 않았더라도 운영체제가 판단에 따라 CPU를 회수하고 다른 프로세스에게 재할당할 수 있다. 이 방식은 짧은 작업이나 높은 우선순위의 작업을 더 빠르게 처리할 수 있어 시스템의 응답성을 향상시키는 데 유리하다.

다만 실행 중이던 작업을 중단하고 다른 작업으로 전환할 때마다 문맥 교환이 발생하기 때문에 추가적인 오버헤드가 생길 수 있다.

여기서 핵심은 대기 상태가 아니어도 운영체제가 개입해 CPU를 재할당할 수 있다는 점이다. 이것이 비선점 방식과의 가장 큰 차이다.

Preemptive Scheduling Example Code

This example does not directly implement preemptive scheduling. It is an example designed to observe execution results in an environment where preemptive scheduling is operating.

Looking at the code, the parent and child processes each run a while loop and continuously print their own messages. Neither process terminates on its own, and no instruction to yield the CPU has been written. In other words, the code contains no command to stop execution or hand off to another process.

Yet the execution results show output alternating between the two. This switching is not caused by the code — it is caused by the operating system's preemptive behavior. The operating system uses timer interrupts to reclaim the CPU from the running process after a set interval and switch to another.

In short, this example demonstrates that even when a process does not voluntarily relinquish the CPU, the operating system can intervene and swap execution.

선점 스케줄링 예제 코드

이 예제는 선점 스케줄링을 직접 구현한 코드가 아니다. 선점 스케줄링이 동작하는 환경에서 실행 결과를 관찰하기 위한 예제다.

코드를 보면 부모와 자식 프로세스가 각각 while 반복문을 수행하며 계속해서 자신의 메시지를 출력한다. 두 프로세스 모두 스스로 종료하지 않으며, CPU를 반납하는 명령도 작성되어 있지 않다. 즉, 코드 안에는 실행을 중단하거나 다른 프로세스로 넘기라는 명령이 전혀 없다.

그럼에도 실행 결과를 보면 출력이 번갈아 나타난다. 이 교체는 코드 때문이 아니라 운영체제의 선점 동작 때문이다. 운영체제는 타이머 인터럽트를 통해 일정 시간이 지나면 실행 중인 프로세스의 CPU를 회수하고 다른 프로세스로 전환한다.

즉, 이 예제는 프로세스가 스스로 CPU를 내려놓지 않더라도 운영체제가 개입해 실행을 교체할 수 있다는 것을 보여주는 코드다.

Non-Preemptive Scheduling: Only Voluntary Yielding

In contrast to preemptive scheduling, non-preemptive scheduling does not allow the operating system to forcibly stop a running process. Once a process is assigned the CPU, it continues running until its task finishes or it voluntarily transitions to a waiting state.

This structure is simple and incurs low management overhead. However, if a long-running task claims the CPU first, all other tasks must wait until it completes. This can lead to response delays that directly affect the performance users perceive.

비선점 스케줄링: 자발적 반납만 허용

선점 스케줄링과 대비되는 비선점 스케줄링을 살펴보자. 비선점 스케줄링에서는 운영체제가 실행 중인 프로세스를 강제로 중단시키지 않는다. 한 번 CPU를 할당받은 프로세스는 작업이 끝나거나 스스로 대기 상태로 전환될 때까지 계속 실행된다.

이 구조는 단순하고 관리 부담이 적다는 장점이 있다. 그러나 실행 시간이 긴 작업이 먼저 CPU를 점유하면, 그 작업이 끝날 때까지 다른 작업은 계속 기다려야 한다는 단점이 있다. 결국 응답 지연이 발생할 수 있으며, 이는 사용자 체감 성능에도 직접적인 영향을 미친다.

Non-Preemptive Scheduling Example Code

This example also does not directly implement non-preemptive scheduling. It is designed to observe the execution flow under non-preemptive conditions by creating a situation where forced switching does not occur.

After using fork() to create parent and child processes, the parent calls sleep(6) so that it waits until the child finishes. The important point is that sleep() is not simply a function that passes time — it is a call that transitions the process to a waiting state for a period. In other words, the parent does not continue using the CPU; it voluntarily enters a waiting state and becomes unable to use the CPU. During that time, the child process runs its loop and completes all of its output.

The execution results show all of the child's output appearing first, followed by the parent's output. This is not because the operating system forcibly stopped a running process — it is because the parent voluntarily transitioned to the waiting state, causing the CPU to pass to the child.

In short, this example shows how execution flow changes when a process voluntarily relinquishes the CPU.

비선점 스케줄링 예제 코드

이 예제 역시 비선점 스케줄링을 직접 구현한 코드가 아니다. 강제 교체가 발생하지 않는 상황을 만들어 비선점 방식에서의 실행 흐름을 관찰하는 예제다.

fork()를 이용해 부모와 자식 프로세스를 생성한 뒤, 부모 프로세스는 sleep(6)을 호출해 자식이 끝날 때까지 기다리도록 구성했다. 여기서 중요한 점은 sleep()이 단순히 시간을 보내는 함수가 아니라, 해당 프로세스를 일정 시간 동안 대기 상태로 전환시키는 호출이라는 것이다. 즉, 부모는 CPU를 계속 사용하는 것이 아니라 스스로 대기 상태로 들어가 CPU를 사용할 수 없게 된다. 그 사이에 자식 프로세스는 반복문을 통해 자신의 출력을 끝까지 수행한다.

실행 결과를 보면 자식의 출력이 모두 나타난 뒤 부모의 출력이 이어지는 것을 확인할 수 있다. 운영체제가 실행 중인 프로세스를 강제로 중단시킨 것이 아니라, 부모가 스스로 대기 상태로 전환되었기 때문에 CPU가 자식에게 넘어간 것이다.

즉, 이 예제는 프로세스가 CPU를 자발적으로 반납할 때 실행 흐름이 어떻게 달라지는지를 보여주는 코드다.

Summary

Process execution is not controlled by the user — it is managed by the operating system. Which process uses the CPU and when is not fixed in advance; it varies with the scheduling policy applied, and that policy determines the responsiveness users experience.

CPU scheduling is the mechanism that decides and controls the execution flow of processes. In the next session, we will examine the specific criteria used to determine execution order — the various scheduling algorithms — one by one.

정리

프로세스의 실행은 사용자가 직접 제어하는 것이 아니라 운영체제가 관리한다. 어떤 프로세스가 언제 CPU를 사용할지는 고정되어 있지 않으며, 적용되는 스케줄링 방식에 따라 실행 순서가 달라진다. 그리고 그 순서에 따라 사용자가 느끼는 응답성도 달라진다.

이처럼 프로세스의 실행 흐름을 결정하고 제어하는 것이 바로 CPU 스케줄링이다. 다음 시간에는 이 실행 순서를 결정하는 구체적인 기준, 즉 다양한 스케줄링 알고리즘을 하나씩 살펴볼 예정이다.

Practice: Observing Apparent Concurrency

Let's directly observe what happens when fork() creates parent and child processes that each run independently.

The execution results show the messages of the parent and child interleaved in the output. Although it looks as though the two processes are running simultaneously, the CPU handles only one task at a time. The reason output alternates is that the operating system switches execution targets at very high speed.

What this practice demonstrates is that the two processes are not truly running at the same time, what we see is apparent concurrency, produced by rapid execution switching.

실습으로 확인하는 겉보기 동시성

fork()를 호출했을 때 부모 프로세스와 자식 프로세스가 각각 생성되어 실행되는 것을 직접 확인해보자.

실행 결과를 보면 부모와 자식의 메시지가 섞여서 출력되는 것을 볼 수 있다. 겉으로 보기엔 두 프로세스가 동시에 실행되는 것처럼 보이지만, CPU는 한 번에 하나의 작업만 처리한다. 출력이 번갈아 나오는 이유는 운영체제가 실행 대상을 매우 빠르게 전환하기 때문이다.

이 실습을 통해 확인할 수 있는 것은, 실제로 두 프로세스가 동시에 실행되는 것이 아니라 빠른 실행 전환에 의해 만들어지는 겉보기 동시성이라는 점이다.

Practice: Observing Non-Determinism of Execution Order

This example is a simple program with no loops and no wait functions — the parent and child each print one message.

Running it shows that sometimes child appears first, and sometimes parent appears first. The code is identical, but who receives the CPU first is not fixed.

What this practice demonstrates is that even with an identical program, the order of execution results can differ from run to run. The selection of the execution target is not predetermined — non-determinism is inherent in CPU scheduling.

실습으로 확인하는 실행 순서의 비결정성

이 예제는 반복문도, 대기 함수도 없이 부모와 자식 프로세스가 각각 한 번씩 메시지를 출력하는 단순한 코드다.

실행해보면 어떤 경우에는 child가 먼저 출력되고, 어떤 경우에는 parent가 먼저 출력된다. 코드는 동일하지만 누가 먼저 CPU를 할당받는지는 고정되어 있지 않기 때문이다.

이 실습을 통해 확인할 수 있는 것은, 동일한 프로그램이더라도 실행 결과의 순서가 매번 달라질 수 있다는 점이다. 실행 대상의 선택은 미리 결정되어 있지 않으며, CPU 스케줄링에는 비결정성이 존재한다.

Practice: Observing Repeated Execution and Waiting

This example includes a call to sleep(). Remember that sleep() does not merely delay time — it transitions the process to a waiting state for a period.

Running it shows that after one process prints a message and appears to pause, the other process's output follows. This is because the process transitions to a waiting state via sleep() and can no longer use the CPU, at which point the operating system selects another ready process.

What this lab demonstrates is that processes repeat cycles of execution and waiting, and after each wait period, they pass through the ready state before running again.

실습으로 확인하는 실행과 대기의 반복

이 예제는 sleep() 호출을 포함한다. sleep()은 단순히 시간을 지연시키는 것이 아니라, 해당 프로세스를 일정 시간 동안 대기 상태로 전환시키는 호출이라는 점을 기억하자.

실행해보면 한 프로세스가 메시지를 출력한 뒤 잠시 멈추는 것처럼 보이고, 그 사이에 다른 프로세스의 출력이 이어지는 것을 확인할 수 있다. 실행 중이던 프로세스가 sleep()과 함께 대기 상태로 전환되면서 CPU를 사용할 수 없게 되고, 그 순간 운영체제는 준비 상태에 있는 다른 프로세스를 선택하기 때문이다.

이 실습을 통해 확인할 수 있는 것은, 프로세스는 실행과 대기를 반복하며 대기 이후에는 준비 상태를 거쳐 다시 실행된다는 흐름이다.

Practice: Observing Preemptive Scheduling

This example has both parent and child processes running while loops. The code contains no instruction to stop execution. Yet the execution results show the parent and child output alternating infinitely. Press Ctrl+C to terminate.

This switching does not happen because the processes voluntarily give up the CPU. It happens because the operating system forcibly swaps the running process at fixed time intervals.

What this lab demonstrates is the core characteristic of preemptive scheduling: even when execution is not finished, the operating system can reclaim the CPU when it judges this necessary.

실습으로 확인하는 선점 스케줄링

이 예제는 부모와 자식 프로세스가 모두 while 반복문을 수행하는 구조다. 코드 안에는 실행을 중단하라는 명령이 없다. 그럼에도 실행 결과를 보면 부모와 자식의 출력이 무한히 번갈아가며 나타난다. 종료하려면 Ctrl+C를 누르면 된다.

이 교체는 프로세스가 스스로 CPU를 내려놓은 것이 아니다. 운영체제가 일정 시간 단위로 실행 중인 프로세스를 강제로 교체하기 때문에 나타나는 결과다.

이 실습을 통해 확인할 수 있는 것은, 실행이 끝나지 않았더라도 운영체제가 필요하다고 판단하면 CPU를 회수할 수 있다는 선점 스케줄링의 핵심 특징이다.

Practice: Observing Non-Preemptive Scheduling

This example is configured so that one process calls sleep() and temporarily enters a waiting state.

Running it shows that one side finishes first, and then the other side executes. No forced switching occurs mid-execution. This is because the next process only runs once the running process voluntarily transitions to a waiting state or terminates.

What this practice allows us to directly observe is the defining characteristic of non-preemptive scheduling: execution flow only transfers when a process voluntarily relinquishes the CPU.

실습으로 확인하는 비선점 스케줄링

이 예제는 한 프로세스가 sleep()을 호출해 일시적으로 대기 상태로 들어가도록 구성한 코드다.

실행해보면 한쪽 작업이 먼저 끝난 뒤 다른 쪽 작업이 실행되는 것을 확인할 수 있다. 실행 도중 강제로 교체되는 모습은 나타나지 않는다. 실행 중인 프로세스가 스스로 대기 상태로 전환되거나 종료되어야 비로소 다음 프로세스의 실행이 이루어지기 때문이다.

이 실습을 통해 프로세스가 자발적으로 CPU를 반납할 때만 실행 흐름이 전환되는 비선점 스케줄링의 특징을 직접 확인할 수 있다.

1️⃣ Text File

Linux and Unix: Are They the Same?

Linux and Unix are not completely identical, but they can be considered very similar from a user's perspective. Looking at their internal structure, there are real differences, and there is also the distinction that Unix is paid while Linux is free. However, since they are not significantly different in terms of actual usage, learning how to use Linux will allow you to adapt to a Unix environment without much difficulty.

In this session, we will look at how to edit text files in a Linux environment.

텍스트 파일 편집: 리눅스와 유닉스는 같은가?

리눅스와 유닉스는 완전히 동일하지는 않지만, 사용자 관점에서는 매우 유사하다고 할 수 있다. 내부 구조를 들여다보면 실질적인 차이가 존재하고, 유닉스가 유료인 반면 리눅스는 무료라는 차이점도 있다. 하지만 실제 사용법 측면에서는 크게 다르지 않기 때문에, 리눅스를 중심으로 운영체제 사용법을 익혀두면 유닉스 환경에서도 무리 없이 적응할 수 있다.

이번 시간에는 실제 리눅스 환경에서 텍스트 파일을 어떻게 편집하는지 살펴본다.

What is a Text File?

The most familiar example of a text file is the .txt file. By definition, a text file is a file that stores electronically represented characters arranged in sequence.

The difference becomes clear when compared to a PPT file. PPT requires a specific company's editor which is PowerPoint - to open it, whereas text files are not tied to any specific format. There is a dedicated viewer for text files called a text editor, but since it comes pre-installed on computers at no additional cost, it is referred to as a basic editor.

So why is this basic editor necessary? The simplest reason is that it is needed for handling program inputs and modifying various system settings. Since text files are stored in a human-readable format, opening one in an editor lets you see characters like A, B, and C directly.

Early computers were developed around the alphabet, so non-alphabetic characters like Korean were not supported. Today, however, the underlying structure has evolved to support a wide range of languages.

텍스트 파일이란?

텍스트 파일은 평소에 익숙하게 접해온 .txt 파일이 대표적인 예다. 정의하자면, 전자적인 문자가 나열된 형태로 저장된 파일을 텍스트 파일이라고 한다.

PPT 파일과 비교하면 차이가 명확해진다. PPT는 파워포인트라는 특정 회사의 편집기가 있어야만 열람이 가능한 반면, 텍스트 파일은 특정 형식에 종속되지 않는다. 텍스트 파일을 열기 위한 전용 뷰어, 즉 텍스트 편집기가 존재하지만, 추가 비용 없이 컴퓨터에 기본으로 설치되어 있기 때문에 '기본 편집기'라고 부른다.

그렇다면 이 기본 편집기는 왜 필요할까? 가장 간단한 이유는 프로그램의 입력값을 다루거나 각종 설정을 변경할 때 필요하기 때문이다. 텍스트 파일은 사람이 읽기 쉬운 형식으로 되어 있어, 편집기로 열면 A, B, C와 같은 문자를 그대로 확인할 수 있다.

초기 컴퓨터는 알파벳 중심으로 발전해왔기 때문에 한국어와 같은 비알파벳 문자는 지원되지 않았다. 그러나 현재는 기본 구조 수준에서 다양한 언어를 지원할 수 있도록 발전하였다.

How to Check a Text File

To check whether a file is in text format, use the file command.

file ~/.profile

This will return something like .profile: ASCII text, confirming it is a text file. On the other hand,

file /usr/bin/ls

returns something like ELF 64-bit LSB pie executable .... This is an executable file, commonly referred to as a binary file. A binary file is represented in binary and is formatted for computers to process rather than for humans to read.

텍스트 파일 확인 방법

현재 다루는 파일이 텍스트 형식인지 확인하려면 file 명령어를 사용한다.

file ~/.profile

위 명령어를 입력하면 .profile: ASCII text와 같이 텍스트 형식임을 알려준다. 반면,

file /usr/bin/ls

를 입력하면 ELF 64-bit LSB pie executable ...과 같은 결과가 출력된다. 이는 실행 가능한 파일로, 통상 바이너리 파일이라고 부른다. 바이너리 파일은 이진수로 표현된 파일로, 사람이 읽기보다는 컴퓨터가 처리하기에 적합한 형식이다.

ASCII and Encoding

As mentioned earlier, Korean was added to computers later, which relates to ASCII - the early character encoding system. ASCII is composed of 7 bits and divides characters into two categories:

• Printable characters: 32 ~ 126

• Control characters (non-printable): 0 ~ 31, 127

Computers recognize everything as numbers. For example, uppercase A is stored as 65 and lowercase a as 97. These numbers are converted into human-readable characters according to ASCII-based encoding and decoding rules. Both 65 and 97 fall within the printable character range.

ASCII와 인코딩

한글은 컴퓨터에 나중에 적용되었다고 언급했는데, 이는 초기 컴퓨터 문자 체계인 ASCII와 관련이 있다. ASCII는 7비트로 구성되며, 문자는 크게 두 종류로 나뉜다.

• 출력 가능한 문자: 32 ~ 126

• 제어 문자 (출력되지 않는 문자): 0 ~ 31, 127

컴퓨터는 모든 것을 숫자로 인식한다. 예를 들어 대문자 A는 65, 소문자 a는 97로 저장되며, ASCII 기반의 인코딩·디코딩 규칙에 따라 이 숫자들이 사람이 읽을 수 있는 문자로 변환된다. 65와 97은 모두 출력 가능한 문자 범위에 해당한다.

Viewing File Contents: head

head is a command that outputs the beginning (head) of a file. It is used when you only want to check the first part of a text file that is organized line by line.

The reason for viewing only the beginning goes back to the limitations of early monitors. While modern monitors can display large amounts of text on a single screen, early monitors could only display around 40–80 characters wide and about 20 lines tall. Before that, there were no screens at all — punch card devices were used to output one line at a time. Because what could be shown on screen was so limited, and like a TV where content that has scrolled past cannot be seen again, commands were needed to view just a portion of a file.

Usage: head ~/.profile outputs the default 10 lines, and head -n 7 ~/.profile outputs only 7 lines using the -n option. The -n can be omitted and it will work the same way.

텍스트 파일 내용 보기: head

head는 파일의 앞부분(머리 부분)을 출력하는 명령어다. 텍스트 파일은 문자들이 줄 단위로 구성되어 있는데, 그 중 앞부분만 확인하고 싶을 때 사용한다.

굳이 앞부분만 보는 이유는 초기 모니터의 한계에서 비롯된다. 현재의 모니터는 많은 양의 텍스트를 한 화면에 표시할 수 있지만, 초기 모니터는 가로 40~80자, 세로 20줄 내외만 표현 가능했다. 그 이전에는 화면 자체가 없었고 펀치카드 장치로 한 줄씩 출력하는 방식을 사용했다. 이처럼 한 화면에 표시할 수 있는 내용이 제한적이었기 때문에, TV 화면처럼 한번 지나간 내용은 다시 볼 수 없는 환경에서 파일의 일부분만 확인하기 위한 명령어가 필요했다.

사용법은 다음과 같다.

head ~/.profile을 입력하면 기본값인 10줄이 출력되며, head -n 7 ~/.profile과 같이 -n 옵션으로 출력할 줄 수를 직접 지정할 수도 있다. -n은 생략해도 동일하게 동작한다.

Viewing File Contents: tail

tail is the counterpart to head - just like the relationship between a head and a tail, it outputs the end of a file. Entering tail -n 7 ~/.profile outputs the last 7 lines of the file. The usage is the same as head, but the result is different. In summary, head outputs from the beginning and tail outputs from the end.

Note that depending on the user's environment, the .profile file may not exist or its contents may differ. If the file has not been modified from its initial state, the results from head and tail may look nearly the same, but if changes have been made, the results will differ.

텍스트 파일 내용 보기: tail

tail은 head와 상응하는 명령어로, 머리와 꼬리의 관계처럼 파일의 뒷부분을 출력한다. tail -n 7 ~/.profile을 입력하면 파일의 마지막 7줄을 출력한다는 점에서 head와 사용법은 같지만 결과는 다르다. 정리하자면 head는 앞에서부터, tail은 뒤에서부터 지정한 줄 수만큼 출력한다고 이해하면 된다.

단, 사용자 환경에 따라 .profile 파일이 없거나 내용이 다를 수 있다. 초기 설정 그대로라면 head와 tail의 결과가 거의 동일하게 보일 수 있지만, 중간에 내용을 수정했다면 결과에 차이가 생긴다.

The Meaning of ~

Why do we use ~ in commands? The ~ symbol represents the home directory of the currently logged-in user. It is both a relative and absolute reference. In most cases, users continue with the account they initially logged in with, but administrators can switch to another user without logging out. In that case, ~ points to the home directory of the switched user. In other words, ~ always refers to the home directory of the currently active user.

~의 의미

명령어에서 ~를 사용하는 이유는 무엇일까? ~는 현재 로그인한 사용자의 홈 디렉토리를 의미한다. 상대적인 표시이면서도 절대적인 위치를 가리킨다는 특징이 있다. 대부분의 경우 처음 로그인한 계정을 계속 사용하지만, 관리자는 로그아웃 없이도 다른 사용자로 전환할 수 있다. 이 경우 ~는 전환된 사용자의 홈 디렉토리를 가리키게 된다. 즉, ~는 항상 현재 활성화된 사용자의 홈 디렉토리를 의미한다.

Viewing File Contents: cat

cat stands for "concatenate files and print on the standard output." It is a command that joins files together and outputs their contents to the standard output device.

What is the standard output device? In modern terms, it is natural to think of a monitor, but this has not always been the case. In the early days of computing, the standard output device was paper — a printer. Therefore, saying "output to the monitor" is specific to a particular situation. The more accurate expression is "output to the standard output device." More details on standard output will be covered later.

Usage: entering cat ~/.profile outputs the entire contents of that file to the standard output device. In a typical environment, this will appear on the monitor.

텍스트 파일 내용 보기: cat

cat은 "concatenate files and print on the standard output" 파일을 이어 붙여 표준 출력장치로 내용을 출력하는 명령어다.

여기서 표준 출력장치란 무엇일까? 현재 기준으로는 모니터라고 생각하면 자연스럽지만, 이것이 항상 당연한 것은 아니다. 컴퓨터 초창기에는 표준 출력장치가 모니터가 아닌 종이, 즉 프린터였다. 따라서 "모니터에 출력된다"는 표현은 특정 상황에 한정된 표현이며, 보다 정확하게는 "표준 출력장치로 출력된다"고 하는 것이 맞다. 표준 출력에 대한 자세한 내용은 이후에 다룰 예정이다.

사용법은 다음과 같다. cat ~/.profile을 입력하면 해당 파일의 전체 내용이 표준 출력장치로 출력된다. 일반적인 환경에서는 모니터에 출력되는 것을 확인할 수 있다.

Viewing File Contents: more

more is a command that displays file contents divided according to the terminal screen size. Unlike cat, which outputs everything at once, more shows only as much as the current screen can display.

Running more ~/.profile shows --More-- (32%) at the bottom of the screen, meaning 32% of the total document is currently displayed. The amount shown varies depending on the terminal window size — whether it shows 24 lines or 50 lines depends on the current screen. Since it allows you to read through the entire content in order rather than cutting off a portion like head or tail, it is more useful when you actually want to read a file.

텍스트 파일 내용 보기: more

Display the contents of a file in a terminal

more는 파일의 내용을 터미널 화면 크기에 맞춰 나눠서 출력하는 명령어다. cat처럼 파일 전체를 한꺼번에 출력하는 것이 아니라, 현재 화면에 표시할 수 있는 만큼만 보여준다.

more ~/.profile을 실행하면 화면 하단에 --More-- (32%)와 같은 표시가 나타나는데, 이는 전체 문서 중 32%가 현재 화면에 표시되었다는 의미다. 화면 크기는 사용자마다 다를 수 있어 24줄짜리 화면이든 50줄짜리 화면이든 현재 터미널 창의 크기에 따라 표시되는 양이 달라진다. head나 tail처럼 일부만 잘라서 보는 것이 아니라 전체 내용을 순서대로 읽어나갈 수 있기 때문에, 파일 내용을 실제로 읽어볼 때 더 유용한 명령어다.

Viewing File Contents: less

Despite its name, less has more features than more. While more only allows forward navigation, less allows you to move both forward and backward freely. Like the scrollbar on the right side of a web browser, less lets you scroll up and down through the file content, making it more convenient for reading long files.

To exit less, press q.

텍스트 파일 내용 보기: less

less는 이름과 달리 more보다 기능이 많은 명령어다. more가 앞으로만 이동 가능한 반면, less는 앞뒤로 자유롭게 이동할 수 있다. 웹 브라우저 오른쪽의 스크롤 바처럼 파일 내용을 위아래로 자유롭게 탐색할 수 있어 긴 파일을 읽을 때 더욱 편리하다.

Using cat with << (Here Document)

In addition to standalone use, cat can be used together with the << operator. << is called the here document operator and allows you to input multiple lines of text at once.

Usage: type cat << end and press Enter, then input the desired content line by line. When finished, type end on the last line and press Enter to terminate input.

cat과 << (Here Document) 활용

cat은 단독으로 사용하는 것 외에도 << 연산자와 함께 복합적으로 활용할 수 있다. <<는 here document 연산자라고 부르며, 여러 줄의 텍스트를 한 번에 입력할 수 있게 해준다.

사용법은 다음과 같다. cat << end를 입력하고 엔터를 누른 뒤, 원하는 내용을 한 줄씩 입력한다. 입력이 끝나면 마지막 줄에 end를 입력하고 엔터를 누르면 입력이 종료된다.

Using cat, <<, and > Together

Adding > (redirect output) to the here document operator << allows you to save the input content to a file.

The > is the redirect output operator, meaning send the output to the specified file instead of the monitor. So > new.txt means save the input content to a file named new.txt. By using cat, <<, and > together, you can easily create a text file.

cat, <<, >를 함께 활용하기

앞서 살펴본 here document 연산자 <<에 >(redirect output)를 추가하면 입력한 내용을 파일로 저장할 수 있다.

여기서 >는 redirect output 연산자로, 출력 결과를 모니터 대신 지정한 파일로 보내라는 의미다. 즉 > new.txt는 입력한 내용을 new.txt라는 이름의 텍스트 파일로 저장하라는 뜻이 된다. 이처럼 cat, <<, >를 함께 사용하면 간단하게 텍스트 파일을 생성할 수 있다.

Using echo with > and >>

echo is a command that outputs the text you type. When used with >, it saves the content to a file.

Here, > overwrites any existing file content. In contrast, >> appends to the existing content. If > is used instead of >>, the existing sample-text would be gone and only another-line would remain. In summary, > means overwrite and >> means append. One thing to note: if >> is used when there is no existing content, since there is nothing to append to, a new file will be created with the input as the first line.

echo와 >, >> 활용

echo는 입력한 텍스트를 출력하는 명령어로, >와 함께 사용하면 내용을 파일로 저장할 수 있다.

여기서 >는 기존 파일 내용을 덮어쓴다. 반면 >>는 기존 내용에 이어붙이는 역할을 한다. 만약 >>대신 >를 사용했다면 기존의 sample-text는 사라지고 another-line만 출력된다. 정리하자면 >는 덮어쓰기, >>는 이어붙이기라고 이해하면 된다. 한 가지 주의할 점은, 아무 내용도 없는 상태에서 >>를 사용하면 이어붙일 내용이 없으므로 새 파일이 생성되며 입력한 내용이 첫 줄로 저장될 것이다.

Editing Text Files: sed

Once a file is created, editing becomes necessary. As content grows, it is not practical to recreate the file every time a single character needs to be fixed. This is where sed comes in, defined as "stream editor for filtering and transforming text."

cat sample.txt | sed 's/-/*/'

The meaning of 's/-/*/' is as follows: s stands for substitute, meaning replace - with *. Running the command outputs the following:

sample*text
another*line

Importantly, the original file is not changed. Running cat sample.txt again still outputs sample-text and another-line. The result of sed is only shown on the standard output device and is not applied to the original file.

텍스트 파일 편집: sed

파일을 만들었다면 이제 편집이 필요하다. 내용이 많아질수록 한 글자 때문에 파일을 매번 새로 만들 수는 없기 때문이다. 이때 사용하는 것이 sed로, "stream editor for filtering and transforming text"로 정의된다. 즉 텍스트를 걸러내고 변환하는 스트림 편집기다.

여기서 's/-/*/'의 의미는 다음과 같다. s는 substitute(치환)를 뜻하며, -를 *로 바꾸라는 의미다. 위 명령어를 실행하면 결과는 아래와 같이 출력된다.

sample*text
another*line

단, 중요한 점은 원본 파일은 변경되지 않는다는 것이다. cat sample.txt를 다시 실행하면 여전히 sample-text, another-line으로 출력된다. sed의 결과는 표준 출력장치에 보여지기만 할 뿐, 원본 파일에 적용되지 않기 때문이다.

Saving to a File: tee

To save the result of sed to a file, use the tee command. tee is defined as "read from standard input and write to standard output and files," meaning it can simultaneously write to both the standard output device and a file. In other words, the result is displayed on screen and saved to a file at the same time — two benefits in one.

Running cat sample.txt outputs sample-text and another-line. Piping this to tee smpl.txt displays the same content on screen while also saving it to a new file called smpl.txt. Running cat smpl.txt afterward will show the same result as cat sample.txt.

파일로 저장하기: tee

sed의 결과를 파일에 저장하려면 tee 명령어를 활용한다. tee는 "read from standard input and write to standard output and files"로 정의되며, 표준 입력에서 읽어온 내용을 표준 출력장치와 파일 양쪽에 동시에 쓸 수 있다. 즉, 화면에도 결과가 출력되면서 파일에도 저장되는 일석이조의 명령어다.

cat sample.txt를 실행하면 sample-text, another-line이 출력된다. 여기에 tee smpl.txt를 연결하면 같은 내용이 화면에 출력됨과 동시에 smpl.txt라는 새 파일에도 저장된다. 이후 cat smpl.txt를 실행하면 sample.txt의 결과와 동일하게 sample-text, another-line이 출력되는 것을 확인할 수 있다.

2️⃣ Use a Text Editor

Installing vim

Before installing vim, the package list needs to be updated. When Ubuntu was first installed, it may have only known about version 1.0, but version 1.5 with bug fixes may have since been released. Running sudo apt update refreshes the package list to its latest state. Then install vim with sudo apt install vim, and check the installed version by running vim --version.

vim 설치

vim을 설치하기 전에 먼저 패키지 목록을 최신화해야 한다. 우분투를 처음 설치했을 때는 1.0 버전만 알고 있었더라도, 이후 버그 패치 등을 거쳐 1.5 버전이 출시되었을 수 있기 때문이다. sudo apt update를 실행하면 패키지 목록이 최신 상태로 갱신된다. 이후 sudo apt install vim으로 vim을 설치하고, vim --version을 입력하면 현재 설치된 vim의 버전을 확인할 수 있다.

The vim Launch Screen

Type vi or vim at the prompt and press Enter to launch the editor. On the launch screen, each line begins with a ~ symbol — but be careful here. The ~ used in file paths means the current user's home directory, while the ~ at the start of each line in the vim screen means an empty line with no content. They look the same but mean completely different things, so be careful not to confuse them.

The numbers displayed on the right side of the screen indicate the current cursor position, representing the line (row) and column. In the center of the screen, a brief explanation and manual for using vim is displayed.

vim 실행 화면

프롬프트에서 vi 또는 vim을 입력하고 엔터를 누르면 편집기 화면이 실행된다. 실행 화면에서 각 줄 맨 앞에 ~ 표시가 보이는데, 여기서 주의할 점이 있다. 경로에서 사용하는 ~는 현재 사용자의 홈 디렉토리를 의미하지만, vim 화면에서 줄 맨 앞에 표시되는 ~는 아무 내용도 없는 빈 줄을 의미한다. 같은 모양이지만 전혀 다른 의미이므로 혼동하지 않도록 주의해야 한다.

화면 오른쪽에 표시되는 숫자는 현재 커서의 위치를 나타내며, 줄(row, line)과 칸(column)을 의미한다. 화면 가운데에는 vim 사용 시 참고할 수 있는 간단한 설명과 매뉴얼이 표시된다.

vim's Two Modes

vim is divided into two main modes. One is INSERT mode, where you can directly type text or program code, indicated by -- INSERT -- at the bottom of the screen. The other is NORMAL mode, where instead of typing, you navigate - moving the cursor and finding specific locations.

When first encountering vim, this mode concept can be very confusing. Pressing keys does not type characters; the cursor just moves. However, this mode distinction is actually one of vim's strengths.

vim의 두 가지 모드

vim은 크게 두 가지 모드로 구분된다. 하나는 INSERT 모드로, 텍스트나 프로그램 코드를 직접 입력할 수 있는 상태다. 화면 하단에 -- INSERT --라고 표시된다. 다른 하나는 NORMAL 모드로, 텍스트를 입력하는 것이 아니라 커서를 이동하거나 원하는 위치를 찾는 등의 탐색을 하는 상태다.

처음 vim을 접하면 이 모드 개념이 굉장히 혼란스럽게 느껴진다. 키보드를 눌러도 글자가 입력되지 않고 커서만 움직이기 때문이다. 그러나 이 모드 구분이 오히려 vim의 장점으로 작용하기도 한다.

NORMAL Mode and EX Mode

NORMAL mode, as mentioned, is a state for navigation — moving the cursor, scrolling the screen, deleting content, pasting, and so on. Pressing : in NORMAL mode switches to EX mode, where you can enter commands.

EX mode originates from the concept of a line editor, derived from the era before visual interfaces when text was processed one line at a time.

To return to NORMAL mode from INSERT mode, press ESC. Pressing ESC twice guarantees a return to NORMAL mode regardless of the current state.

Entering INSERT Mode

INSERT mode is the state where text can be directly entered. From NORMAL mode, pressing any of i, I, a, A, o, O activates INSERT mode, shown by -- INSERT -- at the bottom of the screen. All of them enter INSERT mode, but each key differs in where the cursor is positioned when input begins.

• i — starts input at the current cursor position

• I — starts input at the beginning of the current line

• a — starts input one position after the current cursor

• A — starts input at the end of the current line

• o — creates a new line below the current line and starts input there

• O — creates a new line above the current line and starts input there

The cursor shape may appear as an underline, a block, or other forms. It is good practice to press ESC twice to ensure you are in NORMAL mode before trying each key to observe the differences in cursor placement.

vim INSERT 모드 진입 방법

INSERT 모드는 텍스트를 직접 입력할 수 있는 상태로, NORMAL 모드에서 i, I, a, A, o, O 중 하나를 누르면 화면 하단에 -- INSERT --가 표시되며 진입할 수 있다. 모두 INSERT 모드로 전환된다는 공통점이 있지만, 각 키마다 커서가 시작되는 위치가 다르다.

각 키의 동작 차이는 다음과 같다. i는 현재 커서 위치에서, I는 현재 줄의 맨 앞에서 입력이 시작된다. a는 현재 커서의 다음 글자 위치에서 입력이 시작되며, A는 현재 줄의 맨 끝에서 시작된다. o는 현재 줄의 다음 줄에 새 줄을 만들어 입력할 수 있고, O는 현재 줄의 이전 줄에 새 줄을 만들어 입력할 수 있다.

커서 모양도 밑줄, 네모 등 여러 형태로 표시될 수 있다. ESC를 습관적으로 두 번 눌러 NORMAL 모드로 확실히 전환한 뒤 각 키를 눌러보면 커서 위치가 달라지는 것을 직접 확인할 수 있다.

Creating an Example File and UTF-8 Encoding

Entering man ls > vimLS.txt saves the manual for the ls command into a file called vimLS.txt. man ls outputs the manual, and > redirects that output to a file. Running file vimLS.txt afterward shows the file's attributes — the result will show UTF-8 text.

This differs from earlier when file ~/.profile returned ASCII. ASCII is composed of 7 bits and can only represent 128 characters, which is not enough to include Korean and many other languages. UTF-8 was developed to overcome this limitation. It is a newly established encoding standard that accommodates languages with large character sets, such as Korean, Japanese, and Chinese, and is now used almost universally. When Korean characters fail to display properly, it is often referred to as a CJK problem - an abbreviation for Chinese, Japanese, Korean - indicating the system cannot represent those characters. The saved file can be opened in vim by running vim vimLS.txt.

vim 예시 파일 생성과 UTF-8 인코딩

man ls > vimLS.txt를 입력하면 ls 명령어의 설명서 내용이 vimLS.txt 파일로 저장된다. man ls는 ls 명령어의 매뉴얼을 출력하는 명령어이고, >로 리다이렉트하여 그 내용을 파일에 저장하는 것이다. 이후 file vimLS.txt를 입력하면 해당 파일의 속성을 확인할 수 있는데, 결과로 UTF-8 text가 출력된다.

앞서 file ~/.profile에서는 ASCII로 출력되었던 것과 차이가 있다. ASCII는 7비트로 구성되어 128가지 문자만 표현할 수 있기 때문에 한글을 비롯한 다양한 언어를 표현하지 못한다. 이러한 한계를 극복하기 위해 등장한 것이 UTF-8 인코딩 방식이다. UTF-8은 한글, 일본어, 중국어처럼 표현해야 할 문자 수가 많은 언어를 수용하기 위해 새롭게 제정된 인코딩 방식으로, 요즘은 거의 대부분 UTF-8을 사용한다. 한글이 제대로 표시되지 않을 때 CJK 문제라는 표현을 쓰는데, 이는 Chinese, Japanese, Korean의 약자로 해당 언어들의 문자를 표현하지 못하는 상태를 의미한다. 이렇게 저장된 파일은 vim vimLS.txt를 입력하면 저장된 내용을 vim 편집기에서 확인할 수 있다.

vim Cursor Movement

Opening vim vimLS.txt displays information at the bottom such as "vimLS.txt" 249L, 8383B. Here, 249L is the total number of lines including blank lines, and 8383B is the number of bytes the document occupies. The 1,1 in the bottom right indicates the current cursor position — line (row) and column.

One thing to note about bytes: CJK characters — Korean, Japanese, Chinese — typically occupy 2 bytes. For example, the word "한글" appears as two characters visually, but internally it is stored as more bytes than that.

Cursor movement can be done with h, j, k, l instead of the arrow keys — left, down, up, and right respectively. This is a legacy from early keyboards that lacked arrow keys. Since computers at that time were paper-based, directional movement was unnecessary. In the modern era, arrow keys are available, but the h, j, k, l convention remains a vim tradition and is still fully supported.vim 커서 이동

vim vimLS.txt를 입력하면 편집기 화면이 열리며, 화면 하단에 "vimLS.txt" 249L, 8383B와 같은 정보가 표시된다. 여기서 249L은 빈 줄을 포함한 전체 줄 수를 의미하고, 8383B는 문서가 차지하는 바이트 수를 의미한다. 화면 오른쪽 하단의 1,1은 현재 커서의 위치로, 줄(row)과 칸(column)을 나타낸다.

바이트 수와 관련하여 한 가지 알아둘 점이 있다. CJK 문자, 즉 한국어, 일본어, 중국어는 보통 2바이트를 차지한다. 예를 들어 "한글"은 눈에 보이기엔 두 글자지만 컴퓨터 내부에서는 그보다 더 많은 바이트로 처리된다.

커서 이동은 방향키 대신 h, j, k, l 키로 할 수 있다. 각각 왼쪽, 아래, 위, 오른쪽에 해당한다. 이는 초기 키보드에 방향키가 없었던 시절의 흔적이다. 당시 컴퓨터는 종이 기반으로 작동했기 때문에 상하좌우 이동이 필요 없었고, 별도의 키 매핑이 필요했다. 현대에는 키보드가 발전하여 방향키를 사용할 수 있지만, h, j, k, l 방식은 vim의 전통으로 남아 있으며 vim improved에서도 동일하게 사용 가능하다.

Cursor Movement: Beginning and End of a Line

In NORMAL mode, 0, \(, and ^ allow quick movement within a line. 0 moves to the very beginning of the line, \) moves to the very end, and ^ moves to the first non-blank character of the line. For example, if there are spaces at the start of a line, 0 moves to the absolute beginning including those spaces, while ^ moves to where the actual content starts. This can also help identify whether the leading space was created with the spacebar or the tab key.

Note that cursor movement commands including h, j, k, l only work in NORMAL mode. Always confirm you have pressed ESC to switch to NORMAL mode before using them.

vim 커서 이동: 줄의 시작과 끝

NORMAL 모드에서 0, \(, ^ 키를 사용하면 커서를 줄 단위로 빠르게 이동할 수 있다. 0을 누르면 줄의 맨 앞으로, \)를 누르면 줄의 맨 끝으로 이동한다. ^를 누르면 줄에서 내용이 시작되는 첫 번째 문자로 이동한다. 예를 들어 줄 앞에 빈칸이 있는 경우, 0은 빈칸을 포함한 맨 앞으로 이동하지만 ^는 실제 내용이 시작되는 위치로 이동한다. 이를 통해 해당 빈칸이 스페이스바로 만들어진 것인지 탭 키로 만들어진 것인지도 확인할 수 있다.

주의할 점은 h, j, k, l을 비롯한 커서 이동 명령은 반드시 NORMAL 모드에서만 작동한다는 것이다. ESC 키를 눌러 NORMAL 모드로 전환된 것을 확인한 뒤 사용하도록 하자.

Screen-Level Movement

Beyond line-by-line movement, you can jump by entire screens. In NORMAL mode, Ctrl+f moves one full screen down, Ctrl+b moves one full screen up, Ctrl+d moves half a screen down, and Ctrl+u moves half a screen up. This is useful for navigating long files much faster than moving one line at a time.

vim 화면 단위 이동

한 줄씩 이동하는 것 외에도 화면 단위로 한 번에 이동할 수 있다. NORMAL 모드에서 Ctrl키와 함께 사용하며, Ctrl+f는 한 화면 아래로, Ctrl+b는 한 화면 위로 이동한다. Ctrl+d는 화면의 절반만큼 아래로, Ctrl+u는 화면의 절반만큼 위로 이동한다. 한 줄씩 이동하는 것보다 빠르게 원하는 위치로 점프할 수 있어 긴 파일을 탐색할 때 유용하다.

Jumping to a Specific Line

For files with tens of thousands of lines, even screen-level movement can take a long time. In NORMAL mode, pressing gg jumps to the first line, and pressing G jumps to the last line. Typing a line number followed by G jumps directly to that line.

This is one of the most powerful reasons to use vim — no need to scroll with a mouse to reach a specific location. While the experience varies by user, many people use vim not just because it looks impressive, but because it genuinely meets their needs.

vim 특정 줄로 이동

페이지가 수만 줄에 달하는 파일이라면 화면 단위 이동으로도 한참을 이동해야 한다. 이때 특정 줄로 바로 이동하는 기능을 활용할 수 있다. NORMAL 모드에서 gg를 누르면 첫 번째 줄로, 대문자 G를 누르면 맨 마지막 줄로 이동한다. 이동하고 싶은 줄 번호를 입력한 뒤 G를 누르면 해당 줄로 바로 이동할 수 있다.

이것이 vim을 사용하는 가장 강력한 이유 중 하나다. 마우스로 스크롤하지 않아도 원하는 위치로 즉시 이동할 수 있기 때문이다. 사용자에 따라 경험은 다르겠지만, vim을 사용하는 사람들은 단순히 멋있어서가 아니라 실제로 필요하기 때문에 사용하는 경우가 많다.

Word-Level Movement

Movement is also possible at the word level. In NORMAL mode, pressing w moves to the next word and b moves to the previous word.

One important thing to keep in mind is that case matters. For example, |, l, and I look visually similar but are entirely different characters. Catching these differences quickly comes from a developer's eye, and the more you work with computers from a developer's perspective, the more naturally this awareness develops.

vim 단어 단위 이동

한 문자씩 혹은 화면 단위 이동 외에도 단어 단위로 이동하는 것도 가능하다. NORMAL 모드에서 w를 누르면 다음 단어로, b를 누르면 이전 단어로 이동한다.

여기서 주의해야 할 점은 대소문자를 반드시 구분해야 한다는 것이다. 예를 들어 |, l, I는 시각적으로 비슷해 보이지만 모두 다른 문자다. 이러한 차이를 빠르게 캐치하는 것은 개발자적 감각에서 비롯되며, 컴퓨터를 개발자 입장에서 많이 다뤄볼수록 자연스럽게 익숙해진다.

Word-Level Movement 2: B and W

Unlike lowercase b and w, uppercase B and W use whitespace as the word boundary. Lowercase versions recognize special characters and punctuation as word boundaries, while uppercase versions only recognize spaces. Therefore, W moves to the word after the next space, and B moves to the word before the previous space. Since the movement range is broader than the lowercase versions, navigation is faster.

vim 단어 단위 이동 2: 대문자 B, W

앞서 살펴본 소문자 b, w와 달리 대문자 B, W는 빈칸을 기준으로 단어 단위 이동을 한다. 소문자는 특수문자나 구두점 등을 단어의 경계로 인식하지만, 대문자는 오직 빈칸만을 기준으로 삼는다. 따라서 W는 다음 빈칸 너머의 단어로, B는 이전 빈칸 너머의 단어로 이동한다. 이동 범위가 소문자보다 넓기 때문에 더 빠르게 이동할 수 있다.

Entering INSERT Mode 1: i and a

To type actual text or code in NORMAL mode, you need to switch to INSERT mode. The two most common keys are lowercase i and a. Both enter INSERT mode, but they differ in where input begins.

For example, if the cursor is on the second character of a 5-character text, pressing i starts input at the current position (second character), while pressing a starts input one position after (third character). In short, i starts at the current position and a starts one character to the right.

vim INSERT 모드 진입 1: i와 a

NORMAL 모드에서 실제 문자나 코드를 입력하려면 INSERT 모드로 전환해야 한다. 대표적인 방법이 소문자 i와 a이며, 둘 다 INSERT 모드로 진입하지만 커서 위치에 차이가 있다.

예를 들어 5칸짜리 텍스트에서 커서가 두 번째 칸에 위치해 있다고 가정하면, i를 누르면 현재 커서 위치인 두 번째 칸부터 입력이 시작된다. 반면 a를 누르면 현재 커서의 바로 다음 위치인 세 번째 칸부터 입력이 시작된다. 즉 i는 현재 위치에서, a는 현재 위치의 한 칸 뒤에서 입력이 시작된다는 차이가 있다.

Entering INSERT Mode 2: o and O

Lowercase o creates a new line below the current cursor position and begins input at the first character of that new line. Uppercase O creates a new line above the current cursor position and begins input at the first character of that new line.

Deleting and Undoing

In NORMAL mode, pressing x deletes the single character at the current cursor position. Pressing uppercase D deletes everything from the current cursor position to the end of the line. Pressing dd deletes the entire line.

For undoing, this is similar to Ctrl+Z in Windows. Pressing u in NORMAL mode undoes one action at a time, stepping back through previous states with each press. Uppercase U restores the entire current line to its state before any changes were made.

vim 삭제와 되돌리기

NORMAL 모드에서 x를 누르면 현재 커서 위치의 한 글자가 삭제된다. 대문자 D를 누르면 현재 커서 위치부터 줄의 끝까지 한 번에 삭제된다. dd를 누르면 커서가 있는 줄 전체가 삭제된다.

되돌리기는 윈도우의 Ctrl+Z와 유사한 개념이다. NORMAL 모드에서 u를 누르면 누를 때마다 이전 상태로 한 단계씩 되돌아간다. 대문자 U는 커서가 있는 줄 전체를 변경 이전 상태로 되돌린다.

Replacing a Single Character

As learned, x deletes a single character at the cursor position. To replace rather than delete a character, there are two methods.

Pressing ~ toggles the case of the character at the cursor position between uppercase and lowercase. This is useful in alphabetic language environments and does not apply to CJK characters like Korean, Japanese, or Chinese.

In NORMAL mode, pressing r followed by a desired key replaces the character at the cursor with the newly pressed character — a quick way to swap a single character without the extra step of deleting and retyping.

vim 한 글자 바꾸기

앞서 x는 현재 커서 위치의 한 글자를 삭제한다고 배웠다. 삭제가 아닌 한 글자만 바꾸고 싶을 때는 두 가지 방법을 사용할 수 있다.

~를 누르면 커서 위치의 문자 대소문자가 전환된다. 알파벳 기반의 언어권에서 유용하게 활용할 수 있으며, 한국어, 일본어, 중국어와 같은 CJK 문자에는 해당되지 않는다.

NORMAL 모드에서 r을 누른 뒤 원하는 키를 입력하면 현재 커서 위치의 글자가 새로 입력한 문자로 바뀐다. 삭제 후 다시 입력하는 번거로움 없이 한 글자를 빠르게 교체할 수 있다.

Searching for Content

In NORMAL mode, pressing / moves the cursor to the bottom of the screen. Type the search term and press Enter to jump to the matching location. / searches in the forward (downward) direction from the current cursor position. Pressing n continues searching in the same direction, while N searches in the opposite direction.

Pressing ? instead searches in the backward (upward) direction. In this case, n continues in the same direction (upward) and N goes in the opposite direction (downward). Note that forward and backward here refer to the direction of the search, not the visual position on screen.

vim 내용 찾기

NORMAL 모드에서 /를 누르면 화면 맨 아래로 커서가 이동한다. 찾고자 하는 문구를 입력하고 엔터를 누르면 해당 내용이 있는 위치로 이동한다. /는 현재 커서 위치에서 뒤쪽 방향으로 탐색을 시작한다. 이때 n을 누르면 같은 방향(뒤쪽)으로 계속 탐색하고, N을 누르면 반대 방향(앞쪽)으로 탐색한다.

반대로 ?를 누르고 문구를 입력하면 앞쪽 방향으로 탐색을 시작한다. 이 경우 n은 진행 방향 그대로 앞쪽으로, N은 반대 방향인 뒤쪽으로 탐색한다. 여기서 앞쪽과 뒤쪽은 화면 기준이 아닌 탐색이 진행되는 방향을 기준으로 한다는 점에 주의해야 한다.

Other vim Commands

Commands used after input can be referenced from the ed editor documentation. There are a great many commands, and knowing regular expressions will be an advantage in understanding and using them.

A notable example is :s/short/SHORT/gc, which replaces all instances of short with SHORT in the file. This is similar to the sed 's/-/*/' covered earlier. Here, gc stands for global confirm — it finds and replaces throughout the entire document while asking for confirmation each time.

Regular expressions are a vast topic — broad enough to be a subject on their own — so it is not possible to cover everything in this session. It is recommended to explore them separately when time allows, or through a related course.

For learning vim, the built-in help tutorial is a good resource, and https://vim-adventures.com/ offers a game-based approach to learning vim commands. Note that the site is paid.

vim 기타 명령어

입력 후 사용하는 명령어는 ed 편집기 사용법을 참고하면 된다. 사용법이 매우 많으며, regular expression(정규 표현식)을 알고 있다면 이해와 활용에 유리하다.

대표적인 예로 :s/short/SHORT/gc는 파일 안의 모든 short를 SHORT로 변경하는 명령어다. 앞서 배운 sed 's/-/*/'와 유사한 방식이다. 여기서 gc는 global confirm의 약자로, 문서 전체에서 찾아 바꾸되 매번 확인을 거친다는 의미다.

정규 표현식은 그 자체로 하나의 과목이 될 만큼 방대한 주제이므로 이번 시간에 모두 다루기는 어렵다. 관련 과목을 수강하거나 시간이 날 때 별도로 찾아보는 것을 권장한다.

vim 학습에 도움이 되는 자료로는 vim 내장 help의 튜토리얼이 있으며, https://vim-adventures.com/ 에서 게임 형식으로 사용법을 익힐 수도 있다. 단, 해당 사이트는 유료임을 참고하자.

What is Test Design?

Test design is an activity performed after test planning is complete. It is the stage where you define what to test and how to test it. During this process, the test targets and scope are determined, enabling more efficient test execution.

In software testing, it is practically impossible to verify every possible combination. For example, with just 2 variables that hold True/False values, there are already 4 combinations. As the number of variables grows to 20 or 100, the number of possible combinations increases exponentially, making exhaustive testing completely infeasible. This is precisely why an efficient test strategy is needed — and test design plays that central role.

From a PDCA cycle perspective, test design falls under the P (Plan) phase. This is because it is preparatory work that must be completed before tests are actually executed dynamically. Specifically, this phase includes test case development, test procedure definition, and test environment preparation. Each of these activities will be covered in detail in subsequent posts.

테스트 설계란 무엇인가?

테스트 설계는 테스트 계획이 완료된 이후에 수행되는 활동으로, 무엇을 어떻게 테스트할지를 구체화하는 단계다. 이 과정에서 테스트 대상과 범위가 결정되며, 이를 바탕으로 보다 효율적인 테스트를 수행할 수 있게 된다.

소프트웨어 테스트에서 모든 경우의 수를 전부 검증하는 것은 현실적으로 불가능하다. 예를 들어 True/False 값을 가지는 변수가 단 2개만 있어도 조합은 4가지가 되는데, 변수가 20개, 100개로 늘어나면 가능한 조합의 수는 기하급수적으로 증가해 완전한 테스트 자체가 불가능해진다. 바로 이 때문에 효율적인 테스트 전략이 필요하며, 테스트 설계가 그 핵심 역할을 담당한다.

PDCA 사이클 관점에서 테스트 설계는 P(Plan) 단계에 해당한다. 실제 테스트를 동적으로 실행하기 이전에 사전에 준비해야 하는 작업이기 때문이다. 구체적으로는 테스트 케이스 개발, 테스트 절차 정의, 테스트 환경 준비가 이 단계에 포함된다. 각 세부 활동에 대한 내용은 이후 강의에서 다룰 예정이다.

Test Design as Defined by ISO/IEC/IEEE 29119

ISO/IEC/IEEE 29119 is an international standard for software testing. Let's look at how test design is positioned within this standard.

The standard divides the test process into two main areas: the Test Management Process and the Dynamic Test Process. Test planning takes place within the test management process, and its outputs are passed on to the dynamic test process where actual testing activities occur.

Within the dynamic test process, there are two areas that correspond to test design.

The first is Test Design and Implementation. This stage takes the test plan as input and concretizes what and how to test, with Test Basis analysis as its starting point.

The second is Test Environment Setup and Maintenance. Based on the environment requirements identified during test design and implementation, this activity involves building and managing the actual test environment.

The outputs of these two stages; the test cases and the prepared test environment; are passed together to the Test Execution stage, where dynamic testing finally takes place.

In summary, the key point is that within the 29119 standard, test design is defined as a concept that encompasses not just writing test cases, but also setting up the test environment.

ISO/IEC/IEEE 29119에서 정의하는 테스트 설계

ISO/IEC/IEEE 29119는 소프트웨어 테스팅에 관한 국제 표준으로, 이 표준에서 테스트 설계가 어떻게 위치하는지를 살펴보자.

표준에서 테스트 프로세스는 크게 테스트 관리 프로세스와 동적 테스트 프로세스로 구분된다. 테스트 계획은 테스트 관리 프로세스에서 진행되며, 그 결과가 동적 테스트 프로세스로 전달되어 실제 테스트 활동이 이루어진다.

동적 테스트 프로세스 내에서 테스트 설계에 해당하는 영역은 두 가지다.

첫째, 테스트 설계 및 구현이다. 테스트 계획을 입력으로 받아 테스트 베이시스(Test Basis)를 도출하는 단계로, 무엇을 어떻게 테스트할지 구체화된다.

둘째, 테스트 환경 구성 및 유지다. 테스트 설계 및 구현 단계에서 도출된 환경 요구사항을 바탕으로 실제 테스트 환경을 구성하고 관리하는 활동이다.

이 두 단계의 결과물, 즉 테스트 케이스와 준비된 테스트 환경이 함께 테스트 수행 단계로 전달되어 비로소 동적 테스트가 실제로 실행된다.

정리하면, 29119 표준에서 테스트 설계는 단순히 테스트 케이스를 작성하는 것에 그치지 않고, 테스트 환경 구성까지 포함하는 개념으로 정의된다는 점이 핵심이다.

Test Design and Implementation / Test Environment Setup and Maintenance

ISO/IEC/IEEE 29119 divides test design into two major activities.

Test Design and Implementation is the stage where test cases and procedures are defined based on the test scope and strategy identified in the test plan. The starting point is Test Basis analysis. The Test Basis refers to the artifacts that serve as the foundation for creating test cases. In the V-model, for example, architecture design artifacts serve as the basis for creating integration test cases - the left-side (development) artifacts that are referenced to build right-side (test) cases. By analyzing the Test Basis, the following items are derived: Test requirements, Test conditions, Test coverage criteria and Test cases.

Test Environment Setup and Maintenance requires that an appropriate environment and data be ready before tests can actually be executed. Taking automotive software as an example, testing may begin in a PC environment, gradually expand to a laboratory setting, and ultimately extend to a real road environment where actual vehicles operate. Constructing these various test environments and preparing the necessary data for each is the core activity of this stage.

테스트 설계 및 구현 / 테스트 환경 구성 및 유지

ISO/IEC/IEEE 29119 표준에서 테스트 설계는 크게 두 가지 활동으로 나뉜다.

테스트 설계 및 구현 테스트: 계획에서 식별된 테스트 범위와 전략을 바탕으로 테스트 케이스와 절차를 구체화하는 단계다. 이 과정의 출발점은 테스트 베이시스(Test Basis) 분석이다. 테스트 베이시스란 테스트 케이스를 만들기 위한 기반이 되는 산출물을 말한다. V모델을 예로 들면, 통합 테스트 케이스를 만들 때 아키텍처 설계 산출물이 그 기반이 된다. 즉, 오른쪽(테스트 단계)의 케이스를 만들기 위해 참조하는 왼쪽(개발 단계)의 산출물이 테스트 베이시스에 해당한다. 이 테스트 베이시스를 분석함으로써 다음 항목들을 도출하게 된다.

• 테스트 요구사항

• 테스트 조건

• 테스트 커버리지

• 기준 테스트 케이스

테스트 환경 구성 및 유지: 테스트를 실제로 실행하려면 적절한 환경과 데이터가 준비되어야 한다. 자동차 소프트웨어를 예로 들면, 초기에는 PC 환경에서 테스트하지만 점차 실험실 환경으로 확장되고, 최종적으로는 실제 차량이 주행하는 도로 환경에서까지 테스트가 이루어질 수 있다. 이처럼 다양한 테스트 환경을 구성하고, 각 환경에서 필요한 데이터를 준비하는 것이 이 단계의 핵심 활동이다.

The Need for Test Design

Why is test design necessary? It can be summarized into two main purposes.

First, to perform efficient and effective testing.

Second, to properly verify software across diverse platforms and environments.

More detailed coverage of each purpose follows below.

테스트 설계의 필요성

테스트 설계는 왜 필요한 걸까? 크게 두 가지 목적으로 정리할 수 있다.

첫째, 효율적이면서 효과적인 테스트를 수행하기 위해서다.

둘째, 다양한 플랫폼과 환경에서 소프트웨어를 제대로 검증하기 위해서다.

각 목적에 대한 더 자세한 내용은 이어지는 내용에서 다룰 예정이다.

Two Reasons Why Test Design is Necessary

1. Efficient and Effective Test Execution Verifying every single test case is simply not realistic. Projects always operate under limited resources — people, budget, tools, and equipment. Therefore, a systematic approach is needed to secure sufficient coverage with a minimal number of test cases. What matters is not the sheer volume of test cases, but the ability to derive cases with a high probability of detecting defects. Even with tens of thousands of test cases, if only a handful of defects are found, it cannot be considered good testing. Test design provides the systematic techniques to achieve this.

2. Verification Across Diverse Environments and Platforms No matter how well software runs on a developer's PC, it is meaningless if it does not operate reliably in the actual user environment. To verify behavior across various operating systems, browsers, hardware, and devices, the corresponding environments must be set up in advance. From the V-model perspective, starting to build the test environment only after coding is finished is already too late. Test environments, equipment, and tool configurations must be prepared in parallel with the left-side activities of writing test specifications and specs.

Key Point: Test design does not happen after coding — it proceeds in parallel with the development activities of the V-model.

테스트 설계의 필요성; 두 가지 이유

1. 효율적이고 효과적인 테스트 수행: 모든 테스트 케이스를 일일이 검증하는 것은 현실적으로 불가능하다. 프로젝트에서는 인력, 비용, 도구, 장비 등 자원이 항상 제한되어 있기 때문이다. 따라서 적은 수의 테스트 케이스로 충분한 커버리지를 확보하는 체계적인 접근이 필요하다. 이때 중요한 것은 단순히 테스트 케이스의 수가 아니라 결함을 발견할 확률이 높은 테스트 케이스를 도출하는 것이다. 테스트 케이스가 수만 개라도 발견한 결함이 극히 일부에 불과하다면 좋은 테스트라고 할 수 없다. 테스트 설계는 이를 위한 체계적인 기법을 제공한다.

2. 다양한 환경과 플랫폼에서의 검증: 개발자 PC에서 아무리 잘 동작하는 소프트웨어라도, 실제 사용자 환경에서 안정적으로 동작하지 않으면 의미가 없다. 다양한 운영체제, 브라우저, 하드웨어, 디바이스에서의 동작 여부를 검증하려면 해당 환경이 미리 구축되어 있어야 한다. V모델 관점에서 보면, 테스트 환경 구축은 코딩이 끝난 후에 시작해서는 너무 늦다. 테스트 명세와 테스트 스펙을 작성하는 왼쪽 활동과 병행해서 실제 테스트 환경, 장비, 도구 세팅을 함께 준비해 나가야 한다.

핵심 포인트: 테스트 설계는 코딩 이후가 아닌, V모델의 개발 활동과 함께 진행된다는 점을 반드시 기억하자.

Test Design Activity ① Test Case Development

The first major activity in test design is test case development. Based on the Test Basis; the left-side V-model artifacts such as requirements documents, design documents, and code. This involves writing test cases to verify that the software properly satisfies its requirements.

A test case is a document that systematically records test conditions, input values, expected output values, and actual results. Let's look at a concrete example.

In TC_1, since the lowercase "cuk" is stored in the DB, entering "CUK" in uppercase should produce an "ID not found" warning. If the actual result is "Login successful," it means case sensitivity is not properly implemented, and debugging is required. Once resolved, if "ID not found" warning appears correctly, the defect is fixed.

TC_2's expected output and actual result both show "Incorrect password warning," so it is determined to be functioning correctly.

In this way, test cases are written based on the Test Basis; test specs, design documents, etc. — to systematically verify that the software meets its requirements.

테스트 설계의 주요 활동 ① 테스트 케이스 개발

테스트 설계의 첫 번째 주요 활동은 테스트 케이스 개발이다. 요구사항, 설계서, 코드 등 V모델 왼쪽의 산출물인 테스트 베이시스를 기반으로, 소프트웨어가 요구사항을 제대로 만족하는지 확인하기 위한 테스트 케이스를 작성하는 작업이다.

테스트 케이스는 테스트 조건, 입력값, 예상 출력값, 실행 결과 등을 체계적으로 기록한 문서다. 아래 예시를 통해 구체적으로 살펴보자.

TC_1의 경우 DB에 소문자 cuk로 저장되어 있으므로 대문자 CUK 입력 시 "아이디 없음 경고"가 예상 출력값이다. 그런데 실행 결과가 "정상 로그인"이라면 대소문자 구분이 제대로 구현되지 않은 것이므로 디버깅이 필요하다. 조치 후 "아이디 없음 경고"가 정상 출력되면 결함이 해결된 것이다.

TC_2는 예상 출력값과 실행 결과가 모두 "비밀번호 틀림 경고"로 일치하므로 정상 동작으로 판단한다.

이처럼 테스트 케이스는 테스트 스펙이나 설계서 등 테스트 베이시스를 기반으로, 소프트웨어가 요구사항을 만족하는지를 체계적으로 검증하기 위한 형태로 작성된다.

[Reference] Test Case Components

There are certain components that must be included when writing a test case.

ID is a naming convention used to identify each test case. When there are hundreds or thousands of test cases, a systematic ID system is essential for distinguishing them. For example, unit tests might use UT-1, UT-2, and system tests might use ST-1, ST-2.

Conditions are the preconditions required for the test to run. These specify what must be in place before execution — such as a specific environment being set up, or certain variable values being pre-stored.

Expected output is the anticipated result when the test runs correctly. Just as "ID not found warning" is the expected output when an uppercase ID is entered in the earlier example, each test case must have a clearly defined expected result defined in advance.

In addition, the test purpose, test execution date, and assigned tester should also be recorded when writing test cases.

[참고] 테스트 케이스의 구성 항목

테스트 케이스를 작성할 때 반드시 포함되어야 하는 구성 항목들이 있다.

ID는 테스트 케이스를 식별하기 위한 명명 규칙이다. 테스트 케이스가 수백, 수천 개에 달하는 경우 각각을 구분할 수 있어야 하므로 체계적인 ID 부여가 필수다. 예를 들어 유닛 테스트라면 UT-1, UT-2, 시스템 테스트라면 ST-1, ST-2와 같은 형식으로 작성한다.

조건은 테스트가 수행되기 위한 사전 조건이다. 특정 환경이 갖춰져 있어야 한다거나, 변수값이 미리 저장되어 있어야 하는 등 테스트 실행 전에 반드시 정의되어 있어야 하는 항목들을 명시한다.

예상 출력값은 테스트가 정상적으로 수행될 때 기대되는 결과값이다. 앞선 예시에서 대문자 아이디 입력 시 "아이디 없음 경고"가 출력되어야 하는 것처럼, 테스트 케이스마다 명확한 기대값이 사전에 정의되어 있어야 한다.

이 외에도 테스트 목적, 테스트 수행 날짜, 담당 테스터 등의 항목도 테스트 케이스 작성 시 함께 기록되어야 한다.

Test Design Activity ② Test Procedure Definition

The second major activity in test design is test procedure definition. This involves determining the specific order in which various tests — unit, integration, system, acceptance, etc. — will be performed.

Integration Test Procedure Example

In the V-model, integration testing verifies that interfaces between modules operate correctly, based on the software architecture. A representative artifact used here is the sequence diagram — a diagram that represents the flow of function calls between modules from top to bottom.

For example, when integration testing software composed of Mod_A through Mod_G, the procedure can be defined incrementally as follows. Rather than integrating all modules at once, you first verify that Function_A() between A and D operates correctly, then add E in step 2, followed by F, G, and so on. When software contains dozens or hundreds of modules, integrating everything at once is impossible — which is why defining a step-by-step procedure starting from small units is essential.

Key Point

Test procedure definition is not a concept exclusive to integration testing. Systematically defining the execution order applies to all test types, including unit testing and acceptance testing. From the V-model perspective, test procedure definition must be carried out in parallel with the left-side development activities.

테스트 설계의 주요 활동 ② 테스트 절차 정의

테스트 설계의 두 번째 주요 활동은 테스트 절차 정의다. 단위, 통합, 시스템, 인수 등 다양한 테스트를 어떤 순서로 수행할지 구체적인 절차를 결정하는 활동이다.

통합 테스트 절차 예시

V모델에서 통합 테스트는 소프트웨어 아키텍처를 기반으로 모듈 간 인터페이스가 적절히 동작하는지를 검증한다. 이때 활용되는 대표적인 산출물이 시퀀스 다이어그램이다. 시퀀스 다이어그램은 모듈 간에 수행되는 함수 호출 흐름을 위에서 아래로 표현한 다이어그램이다.

예를 들어 Mod_A ~ Mod_G로 구성된 소프트웨어를 통합 테스트한다면, 절차는 다음과 같이 단계적으로 정의할 수 있다. 한 번에 모든 모듈을 통합하는 것이 아니라, 1단계에서 A와 D 간의 Function_A() 호출이 정상 동작하는지 확인한 뒤, 2단계에서 E를 추가하고, 이후 F, G를 순차적으로 붙여가며 검증하는 방식이다. 소프트웨어 내에 수십, 수백 개의 모듈이 존재할 때 한 번에 통합하는 것은 불가능하므로, 이처럼 작은 단위부터 순서대로 통합해 나가는 절차가 반드시 필요하다.

핵심 포인트

테스트 절차 정의는 통합 테스트에만 해당하는 개념이 아니다. 단위 테스트, 인수 테스트 등 모든 테스트 유형에서 수행 순서를 체계적으로 정의하는 것이 필요하다. 또한 V모델 관점에서 테스트 절차 정의는 개발의 왼쪽 활동과 함께 병행하여 수행되어야 한다는 점을 반드시 기억하자.

Test Design Activity ③ Test Environment Preparation

The third major activity in test design is test environment preparation. This involves deciding in which environment each test; unit, integration, system, acceptance - will actually be executed, and building that environment in advance.

Test environment preparation requires not just software, but also hardware, tools, and equipment. Taking an automotive electronic control system as an example, the environment expands incrementally as integration progresses:

1. Application Software — standalone test

2. Platform Software — integration and test

3. Hardware (ECU) — integration and test

4. Sensor / Actuator — connection and test

5. Mechanics — full system test including mechanical components

Software development alone does not make testing possible. Sensors that provide input to the controller, actuators that handle actual operation, and mechanical components must all be prepared at each stage well in advance.

For this reason, test environment preparation should not begin after development is complete. It must be systematically planned and built in parallel with the left-side activities of the V-model.

테스트 설계의 주요 활동 ③ 테스트 환경 준비

테스트 설계의 세 번째 주요 활동은 테스트 환경 준비다. 단위, 통합, 시스템, 인수 등 각 테스트를 실제로 어떤 환경에서 수행할지 결정하고, 그에 맞는 환경을 미리 구축하는 활동이다.

테스트 환경 준비에는 소프트웨어뿐만 아니라 하드웨어, 도구, 장비 등이 함께 갖춰져야 한다. 자동차 전자 제어 시스템을 예로 들면, 전체 구조는 다음과 같이 단계적으로 통합되며 테스트 환경도 이에 맞춰 확장된다.

1. Application Software 단독 테스트

2. Platform Software 통합 후 테스트

3. Hardware(ECU) 통합 후 테스트

4. Sensor / Actuator 연결 후 테스트

5. Mechanics(기계적 구성 요소) 포함한 전체 시스템 테스트

이처럼 소프트웨어만 개발한다고 테스트가 가능한 것이 아니다. 제어기에 입력을 제공하는 센서, 실제 구동을 담당하는 액추에이터, 그리고 기계적 구성 요소까지 각 단계에서 필요한 환경이 미리미리 준비되어 있어야 한다.

이러한 이유로 테스트 환경 준비는 개발이 완료된 후에 시작하는 것이 아니라, V모델의 왼쪽 활동과 병행하여 사전에 체계적으로 계획하고 구축해 나가야 한다.

2️⃣ Classification of Test Design Techniques

Classification of Test Design Techniques

When creating test cases, systematic test design techniques are applied. Before exploring the types of techniques, let's take a moment to think about it with the V-model in mind.

How can test design techniques be classified?

In the V-model, unit, integration, system, and acceptance tests correspond to each stage of development. Just as the target and purpose of testing differ at each stage, the techniques used to derive test cases can also be classified in various ways depending on the criteria and perspective. The specific classification will be explored in the content that follows.

테스트 설계 기법의 분류

테스트 케이스를 만들 때는 체계적인 테스트 설계 기법을 적용한다. 기법의 종류를 살펴보기 전에, 먼저 V모델을 떠올리며 스스로 생각해보자.

테스트 설계 기법은 어떤 기준으로 분류할 수 있을까?

V모델에서는 개발 단계에 따라 단위, 통합, 시스템, 인수 테스트가 대응된다. 각 단계마다 테스트의 대상과 목적이 다르듯, 테스트 케이스를 도출하는 기법도 그 기준과 관점에 따라 다양하게 분류될 수 있다. 구체적인 분류 방법은 이어지는 내용에서 살펴보도록 하자.

Classification of Test Design Techniques — Black Box vs. White Box

Test design techniques are broadly divided into two categories: Black Box Testing and White Box Testing.

Black Box Testing (Specification-Based Testing)

A "black box" refers to a state where the internal structure and details are not visible. Black box testing focuses solely on whether the output for a given input is appropriate, without considering the software's internal logic. For example, the goal is to verify that inputting 1 and 2 produces 3; not to examine what logic internally calculated that result.

Test cases are derived not from source code, but from the left-side artifacts of the V-model — requirements documents and design specifications. Because it is based on specifications rather than code, it is also known as Specification-Based Testing.

White Box Testing (Structure-Based Testing)

A "white box" refers to a state where the internal structure and details are fully visible. White box testing creates test cases from the source code itself, with the goal of covering as many of the program's internal flows and paths as possible.

Since test cases are derived from the algorithms and logic defined in the source code or detailed design documents, it is also called Structure-Based Testing, as it involves examining the entire structure of the program.

테스트 설계 기법의 분류; 블랙박스 vs 화이트박스

테스트 설계 기법은 크게 블랙박스 테스트와 화이트박스 테스트 두 가지로 나뉜다.

블랙박스 테스트 (명세 기반 테스트)

블랙박스란 내부 구조나 세부 내용이 보이지 않는 상태를 의미한다. 블랙박스 테스트는 소프트웨어의 내부 로직은 고려하지 않고, 입력에 대해 적절한 출력이 나오는지에만 집중한다. 예를 들어 1과 2를 입력했을 때 3이 출력되는지를 확인하는 것이지, 내부적으로 어떤 로직을 통해 3이 계산되었는지는 보지 않는다.

테스트 케이스를 만들 때도 소스코드가 아닌 V모델의 왼쪽 산출물, 즉 요구사항 명세서나 설계 스펙을 기반으로 도출한다. 코드가 아닌 명세를 기반으로 한다는 점에서 명세 기반 테스트(Specification-based Test) 라고도 불린다.

화이트박스 테스트 (구조 기반 테스트)

화이트박스는 내부 구조와 세부 내용이 보이는 상태를 의미한다. 화이트박스 테스트는 소스코드 그 자체를 대상으로 테스트 케이스를 만들며, 프로그램 내부의 다양한 흐름과 경로를 최대한 커버하는 것을 목표로 한다.

소스코드 또는 상세 설계서에 정의된 알고리즘과 로직을 기반으로 테스트 케이스를 도출하기 때문에, 프로그램의 전체 구조를 들여다본다는 의미에서 구조 기반 테스트(Structure-based Test) 라고도 불린다.

Black Box Testing (Specification-Based Testing) — In Depth

Black box testing excludes the software's internal logic entirely and focuses only on whether the output for a given input is correct. Because test cases are derived from specifications such as requirements documents and design documents — rather than source code — it is also referred to as specification-based or spec-based testing.

For example, consider a program that outputs the largest number among several inputs. The internal comparison algorithm used is irrelevant. Based on the specification, the following test cases are derived:

• Case where A is the largest

• Case where B is the largest

• Case where C is the largest

• Case where A is entered as a negative number

The essence of black box testing is verifying that the program produces the correct output in each of these situations.

블랙박스 테스트 (명세 기반 테스트) 심화

블랙박스 테스트는 소프트웨어 내부의 로직은 배제하고, 입력에 대한 출력 값에만 초점을 두는 테스트 방법이다. 테스트 케이스는 소스코드가 아닌 요구사항 명세서나 설계서 등의 스펙을 기반으로 도출하기 때문에 명세 기반 테스트, 스펙 기반 테스트라고도 불린다.

예를 들어 여러 숫자 중 가장 큰 수를 출력하는 프로그램이 있다고 하자. 내부적으로 어떤 비교 알고리즘을 사용하는지는 관심 밖이다. 스펙을 기반으로 다음과 같은 테스트 케이스를 도출한다.

• A가 가장 큰 경우

• B가 가장 큰 경우

• C가 가장 큰 경우

• A를 음수로 입력하는 경우

이처럼 프로그램이 각 상황에서 올바른 출력을 내는지를 확인하는 것이 블랙박스 테스트의 핵심이다.

White Box Testing (Structure-Based Testing) — In Depth

White box testing aims to test as many independent paths within the source code as possible. Test cases are derived from the source code itself, or equivalent detailed design documents and algorithm logic.

While the form of inputs and outputs is the same as in black box testing, white box testing directly examines the internal logic, creating a test case for each individual execution path within the program. Using the "largest number output" program as an example:

Because it examines the entire internal structure and aims to cover every independent path without omission, this approach is also called Structure-Based Testing.

화이트박스 테스트 (구조 기반 테스트) 심화

화이트박스 테스트는 소스코드 내의 모든 독립적인 경로를 최대한 테스트하는 방법이다. 소스코드, 혹은 이에 준하는 상세 설계서와 알고리즘 로직을 기반으로 테스트 케이스를 도출한다.

입력과 출력의 형태는 블랙박스 테스트와 동일하지만, 내부 로직을 직접 들여다보기 때문에 프로그램 안에 존재하는 다양한 실행 경로 하나하나를 테스트 케이스로 만든다. 앞서 살펴본 큰 수 출력 프로그램을 예로 들면 다음과 같다.

이처럼 내부 구조를 모두 들여다보며 독립적인 경로를 빠짐없이 커버하려 한다는 점에서 구조 기반 테스트(Structure-based Test) 라고도 부른다.

[Reference] Test Approaches by V-Model Stage

The test target, environment, and applicable technique differ at each stage of the V-model.

Unit Testing targets individual modules such as functions and files, and is conducted in the developer's own development environment. Since test cases are derived directly from source code, white box testing is applied.

Integration Testing verifies the interfaces between internal and external modules, and is typically conducted in a laboratory environment. Because both source code and specifications are often referenced together, it can be applied in a gray box form that combines white box and black box approaches.

System Testing covers the entire integrated software, verifying not only functional aspects but also non-functional qualities such as performance, usability, maintainability, and compatibility. It is conducted in an environment similar to the actual operating environment, and can also be applied in gray box form.

Acceptance Testing verifies the final software from the user's perspective in a real-world environment, confirming that it operates according to the requirements defined by the user. Since users have no need to examine internal code, black box testing is applied, using requirements definition documents and similar specs as the Test Basis.

[참고] V모델 단계별 테스트 방안

V모델의 각 테스트 단계별로 테스트 대상, 환경, 적용 기법이 달라진다.

단위 테스트 ㅡ 단위 모듈(함수, 파일 등)을 대상으로 하며, 개발자의 개발 환경에서 진행된다. 소스코드 자체를 기반으로 테스트 케이스를 도출하기 때문에 화이트박스 테스트가 적용된다.

통합 테스트 ㅡ 내부 및 외부 모듈 간의 인터페이스를 검증하는 단계로, 보통 실험실 환경에서 진행된다. 소스코드와 스펙을 함께 참조하는 경우가 많아 화이트박스와 블랙박스를 혼합한 그레이박스 형태로 적용이 가능하다.

시스템 테스트 ㅡ 통합된 소프트웨어 전체를 대상으로 기능적 측면뿐만 아니라 성능, 사용성, 유지보수성, 호환성 등 비기능적인 부분까지 검증하는 단계다. 실제 운영환경과 유사한 환경에서 진행되며, 그레이박스 형태로도 적용 가능하다.

인수 테스트 ㅡ 사용자 관점에서 최종 소프트웨어를 실제 환경에서 검증하는 단계로, 사용자가 제시한 요구사항대로 동작하는지를 확인한다. 사용자가 내부 코드를 볼 필요가 없으므로 요구사항 정의서 등의 스펙을 테스트 베이시스로 삼는 블랙박스 테스트가 적용된다.

3️⃣ Block box testing Preview

Black Box Test Design Techniques

Black box testing is an approach that excludes the internal logic of source code and verifies whether the output for a given input is appropriate. Test cases are derived from specifications such as requirements documents and architecture design documents. ISO/IEC/IEEE 29119 defines a variety of black box test techniques. Representative techniques include:

• Syntax Testing

• Equivalence Partitioning

• Boundary Value Analysis

• And many more

In this post, we will use Syntax Testing to understand the fundamental concept of black box test techniques. The remaining techniques will be covered in subsequent posts.

블랙박스 테스트 설계 기법

블랙박스 테스트는 소스코드의 내부 로직은 배제하고, 입력에 대한 출력이 적절한지를 검증하는 방식이다. 테스트 케이스는 요구사항 명세서, 아키텍처 설계서 등의 스펙을 기반으로 도출된다. ISO/IEC/IEEE 29119 표준에서는 다양한 블랙박스 테스트 기법을 정의하고 있다. 대표적인 기법으로는 다음과 같은 것들이 있다.

• 신택스 테스팅 (Syntax Testing)

• 동등 분할 (Equivalence Partitioning)

• 경계값 분석 (Boundary Value Analysis)

• 그 외 다수

이번에는 신택스 테스팅(Syntax Testing) 을 통해 블랙박스 테스트 기법의 기본 컨셉을 살펴보고, 나머지 기법들은 이어지는 내용에서 다룰 예정이다.

Black Box Test Technique ① Syntax Testing

Syntax Testing is one of the easiest black box test techniques to apply. The core concept is to divide input values into Valid and Invalid categories and create test cases accordingly. Test cases are derived from requirements documents or design specifications.

Example: User Registration ㅡ Username Input

Username condition: Korean characters only, minimum 2 characters, maximum 8 characters

When "홍길동 99" is entered, the expected output is "Number included — invalid," but if the actual result shows "Normal," it means the program failed to properly detect the number, indicating a defect.

In this way, Syntax Testing verifies only the output result — without looking at the internal logic at all — by creating test cases based on the valid/invalid conditions defined in the specification. The same approach can be applied to all input fields such as username, password, and email address.

블랙박스 테스트 기법 ① 신택스 테스팅 (Syntax Testing)

신택스 테스팅은 블랙박스 테스트 기법 중 가장 쉽게 적용할 수 있는 방법이다. 핵심 개념은 입력값을 적합(Valid) 과 부적합(Invalid) 으로 구분하여 테스트 케이스를 만드는 것이다. 테스트 케이스는 요구사항 명세서나 설계 스펙을 기반으로 도출된다.

예시: 회원가입 — 사용자 이름 입력

사용자 이름 조건: 2자리 이상 8자리 이하의 한글만 허용

"홍길동 99" 입력 시 예상 출력값은 "숫자 포함 부적합 경고"이지만 실행 결과가 "정상"으로 출력된다면, 프로그램이 숫자를 제대로 인식하지 못한 것이므로 결함이 존재한다는 것을 알 수 있다.

이처럼 신택스 테스팅은 내부 로직은 전혀 보지 않고, 스펙에 정의된 적합/부적합 조건을 기준으로 테스트 케이스를 만들어 출력 결과만을 검증하는 방식이다. 아이디, 비밀번호, 이메일 주소 등 모든 입력 항목에 동일한 방식으로 적용할 수 있다.

Syntax Testing Applied — Shopping Mall Product Search Feature

Let's apply Syntax Testing to a product search feature in a shopping mall system. This feature allows users to enter a product name or product number as a keyword, and the system searches for and displays the matching product.

All valid/invalid conditions are derived from the specification (requirements documents, design documents, etc.). Test cases can only be accurately created when these conditions are clearly defined.

The Importance of Specifications

There is a critical point that must be emphasized here. From the V-model perspective, test cases are built from the left-side artifacts — requirements definitions and design documents. If these artifacts are not properly written, it becomes difficult to accurately derive test cases. In the worst case, testers may end up creating test cases based on guesswork rather than a solid specification.

Ultimately, good testing starts with good specs. Never forget that the thoroughness with which left-side artifacts are written determines the overall quality of the entire test design activity.

신택스 테스팅 적용 예시; 쇼핑몰 상품 검색 기능

쇼핑몰 시스템의 상품 검색 기능을 예시로 신택스 테스팅을 적용해보자. 이 기능은 사용자가 상품명 또는 상품 번호를 키워드로 입력하면 해당 상품을 검색하여 표시하는 기능이다. 이 적합/부적합 조건은 모두 스펙(요구사항 명세서, 설계서 등) 으로부터 도출된다. 조건이 명확히 정의되어 있어야 테스트 케이스를 정확하게 만들 수 있다.

스펙의 중요성

여기서 반드시 짚고 넘어가야 할 점이 있다. V모델 관점에서 테스트 케이스는 왼쪽의 산출물, 즉 요구사항 정의서나 설계서를 기반으로 만들어진다. 따라서 이 산출물들이 제대로 작성되어 있지 않으면 테스트 케이스를 정확히 도출하기가 어려워진다. 최악의 경우 테스터가 스펙 없이 추측에 의존해 테스트 케이스를 만들게 되는 상황이 발생할 수 있다.

결국 좋은 테스트는 좋은 스펙에서 시작된다. 왼쪽 산출물을 충실히 작성하는 노력이 테스트 설계 활동 전체의 품질을 좌우한다는 점을 반드시 기억하자.

Syntax Testing Applied — Writing Test Cases for the Product Search Feature

Let's write actual test cases based on the valid/invalid conditions defined earlier.

Product Name Test Cases

When "노트북^^" is entered, the special characters are ignored and laptop search results are displayed. Since this differs from the expected output defined in the spec, it is identified as a defect and debugging is required.

When "AA12345678" is entered, the letters are not properly recognized and the result shows "Normal." This is likewise identified as a defect and the code must be corrected.

Key Takeaway

Every step of this process — identifying input variables, defining valid/invalid conditions, and deriving test cases — is based not on source code, but on specifications such as requirements documents and architecture design documents. Ultimately, the quality of test cases depends on the quality of the specifications. Always remember: how thoroughly the left-side artifacts of the V-model are written determines the overall completeness of the entire test effort.

신택스 테스팅 적용 예시; 쇼핑몰 상품 검색 기능의 테스트 케이스 작성

앞서 정의한 적합/부적합 조건을 바탕으로 실제 테스트 케이스를 작성해보자.

"노트북^^" 입력 시 특수 기호를 무시하고 노트북 검색 결과가 출력되었다. 스펙에 명시된 예상 출력값과 다르므로 결함으로 판단하고 디버깅이 필요하다.

"AA12345678" 입력 시 영문을 제대로 인식하지 못하고 정상으로 출력되었다. 마찬가지로 결함으로 판단하고 코드를 수정해야 한다.

핵심 정리

이 모든 과정 ~ 입력 변수를 찾고, 적합/부적합 조건을 정의하고, 테스트 케이스를 도출하는 것 은 소스코드가 아닌 요구사항 명세서, 아키텍처 설계서 등의 스펙을 기반으로 이루어진다. 결국 테스트 케이스의 품질은 스펙의 품질에 달려 있다. V모델의 왼쪽 산출물을 얼마나 충실하게 작성하느냐가 테스트 전체의 완성도를 결정한다는 점을 반드시 기억하자.

1️⃣ Core Concepts of Test Planning

What is a Test Plan?

To perform software testing systematically, prior planning is essential. Regardless of what is being managed, proceeding without a plan leads to losing direction, and testing is no exception. This is why we have consistently emphasized from previous weeks that a Test Plan must be established before testing begins.

A concept studied alongside this is the PDCA cycle. A continuous loop of Plan → Do → Check → Act. The test plan corresponds to the Plan phase, which is the starting point of this cycle. In this phase, we clearly define what to test, how far to test, and what goals we aim to achieve through testing at a high level.

The reason a test plan goes beyond mere preparation is that all subsequent activities; test design, execution, evaluation, and improvement; are carried out based on this plan. In other words, the test plan serves as the foundation that sets the direction and criteria for all downstream activities.

In summary, the test plan is the compass of the entire test process. The clearer the plan, the more consistently and efficiently all subsequent testing activities can be carried out.

테스트 계획(Test Plan)이란?

소프트웨어 테스트를 체계적으로 수행하기 위해서는 반드시 사전 계획이 필요하다. 어떤 대상을 관리하든 계획 없이 진행하면 방향을 잃기 쉽고, 테스트도 마찬가지다. 그래서 우리는 테스트를 시작하기 전에 반드시 테스트 계획(Test Plan) 을 세워야 한다는 점을 이전 주차부터 꾸준히 강조해왔다.

이와 관련하여 함께 학습한 개념이 바로 PDCA 사이클이다. PDCA란 Plan(계획) → Do(실행) → Check(평가) → Act(개선)의 순환 구조를 말하며, 테스트 계획은 이 사이클의 출발점인 Plan 단계에 해당한다. 이 단계에서는 무엇을 테스트할 것인지, 어디까지 테스트할 것인지, 그리고 상위 수준에서 테스트를 통해 달성하고자 하는 목표가 무엇인지를 명확하게 정의한다.

테스트 계획이 단순한 준비 작업에 그치지 않는 이유는, 이후에 이루어지는 테스트 설계, 수행, 평가 및 개선의 모든 활동이 바로 이 계획을 기준으로 전개되기 때문이다. 즉, 테스트 계획은 다음 작업들의 방향과 기준을 잡아주는 토대 역할을 한다.

정리하자면, 테스트 계획은 테스트 전체 프로세스의 나침반이다. 계획이 명확할수록 이후의 모든 테스트 활동이 더 일관성 있고 효율적으로 이루어질 수 있다.

Test Planning in the ISO/IEC/IEEE 29119 Standard

ISO/IEC/IEEE 29119 is an international standard covering software testing as a whole, structured into three layers. At the top is the Organizational Test Process, which establishes test policies and strategies applicable across the entire organization. Below that is the Test Management Process, responsible for planning and managing testing at the individual project level. Finally, the Dynamic Test Process is where actual test design, execution, and result processing take place. The test plan corresponds to the first activity within the Test Management Process.

There is one important principle to note here. A test plan is not created independently without context ; it must reflect the test policies and strategies established in the Organizational Test Process. Only when the direction of the higher layer is naturally embedded into the lower-level plan can consistent testing be achieved throughout the project.

So what exactly should a test plan document contain? First, the scope and test items must be clearly identified, defining what and how far to test. Next, the test objectives must be set, defining what the testing aims to achieve. Finally, a test strategy must be developed based on the Organizational Test Process, outlining how to achieve those objectives.

Throughout this process, the word strategy appears frequently. This refers not simply to "what to do," but to the specific methodology for "how to proceed systematically." Without a strategy, testing can easily lose its direction. Therefore, strategy is a core component that must be included in the test plan document.

Ultimately, the 29119 standard positions the test plan within a hierarchical flow of Organizational Policy → Test Strategy → Execution, and the test plan document is the tangible output that formalizes this flow.

ISO/IEC/IEEE 29119 표준에서의 테스트 계획

ISO/IEC/IEEE 29119는 소프트웨어 테스트 전반을 다루는 국제 표준으로, 크게 세 개의 계층으로 구성되어 있다. 가장 상위에는 조직 전체에 적용되는 테스트 정책과 전략을 수립하는 조직 차원의 테스트 프로세스가 있고, 그 아래에는 개별 프로젝트 수준에서 테스트를 계획하고 관리하는 테스트 관리 프로세스, 그리고 실제 테스트 설계와 실행, 결과 처리가 이루어지는 동적 테스트 프로세스가 순서대로 위치한다. 테스트 계획은 이 중 테스트 관리 프로세스의 첫 번째 활동에 해당한다.

여기서 한 가지 중요한 원칙이 있다. 테스트 계획은 아무런 맥락 없이 독립적으로 세워지는 것이 아니라, 반드시 상위 계층인 조직 차원의 테스트 프로세스에서 만들어진 테스트 정책과 전략을 반영해야 한다는 점이다. 상위 계층의 방향성이 하위 계획에 자연스럽게 녹아들어야만 프로젝트 전반에 걸쳐 일관성 있는 테스트가 가능하기 때문이다.

그렇다면 테스트 계획서에는 구체적으로 무엇이 담겨야 할까. 먼저 무엇을 어디까지 테스트할 것인지 대상과 범위를 명확히 식별해야 하고, 이번 테스트를 통해 달성하고자 하는 바를 테스트 목표로 설정해야 한다. 그리고 조직 차원의 테스트 프로세스를 기반으로 그 목표를 달성하기 위한 테스트 전략을 수립해야 한다.

이 과정에서 유독 전략(Strategy) 이라는 단어가 자주 등장하는데, 이는 단순히 "무엇을 할 것인가"에 머무르지 않고 "어떻게 체계적으로 해나갈 것인가"에 대한 구체적인 방법론을 의미한다. 목표만 있고 전략이 없다면 테스트는 쉽게 방향을 잃을 수 있기 때문에, 전략은 테스트 계획서의 핵심 구성 요소로 반드시 포함되어야 한다.

결국 29119 표준은 테스트 계획을 조직의 정책 → 테스트 전략 → 실행으로 이어지는 계층적 흐름 속에 위치시키고 있으며, 테스트 계획서는 바로 이 흐름을 하나의 문서로 구체화한 결과물이라고 할 수 있다.

Detailed Process of Test Planning in 29119

To develop a test plan, the process begins with understanding the project context. Only by grasping the overall picture; including the development scope and overall schedule - can the test scope be defined and a high-level test concept be formed. This concept then shapes the rough outline of the test plan and development schedule.

Once the schedule takes shape, the next step is risk identification and analysis; identifying and analyzing potential risk factors across the project. The methods identified to mitigate these risks are then incorporated into the test strategy design. Afterward, specific human resources and schedules are determined; who will perform the testing, what resources will be used, when and how; and these are documented in the test plan document. The completed document goes through consensus with stakeholders and is shared, completing the test planning process.

The most critical part of this entire flow is the three-step sequence of risk identification and analysis → risk mitigation identification → test strategy design. Planning is fundamentally an act of preparing for future events in advance. Therefore, risks that could affect test execution must always be included in the test plan. Ultimately, the core principle emphasized by the 29119 standard is that test planning must be risk-based.

29119 테스트 계획의 세부 프로세스

테스트 계획을 수립하기 위해서는 가장 먼저 프로젝트의 컨텍스트를 이해하는 것에서 출발한다. 개발하고자 하는 범위나 전체 일정 등 프로젝트의 전반적인 맥락을 파악해야 비로소 테스트의 범위가 정해지고, 테스트에 대한 전체적인 구상이 가능해진다. 이 구상을 바탕으로 테스트 계획과 개발 일정의 큰 틀이 만들어진다.

일정의 윤곽이 잡히면 그 다음으로는 위험 식별 및 분석 단계가 이어진다. 프로젝트 전반에 걸쳐 어떤 위험 요소가 존재하는지 찾아내고 이를 분석하는 과정이다. 이렇게 분석된 위험을 완화하기 위한 방법을 도출하고, 그 방법을 반영하여 테스트 전략을 설계하게 된다. 이후 누가 수행할 것인지, 어떤 자원을 사용할 것인지, 언제 어떻게 진행할 것인지와 같은 구체적인 인적 자원과 일정을 결정하여 테스트 계획서로 문서화한다. 완성된 계획서는 관련자들과 합의를 거쳐 공유되며 테스트 계획 수립이 마무리된다.

이 전체 흐름에서 가장 중요하게 짚어야 할 부분은 위험 식별 및 분석, 위험 완화 방법 식별, 테스트 전략 설계로 이어지는 세 단계다. 계획이란 본질적으로 미래에 일어날 일들을 미리 대비하는 행위다. 그렇기 때문에 테스트 계획을 세울 때도 앞으로의 테스트 수행에 영향을 미칠 수 있는 리스크를 반드시 계획 안에 포함시켜야 한다. 결국 테스트 계획은 위험을 기반으로 수립된다는 것이 29119 표준이 강조하는 핵심 원칙이다.

그렇다면 구체적으로 어떤 기준으로 위험을 식별하고 분석하는 것인지가 자연스러운 다음 질문이 된다. 다음 시간에는 바로 이 위험을 식별하고 분석하는 기준과 방법에 대해 자세히 살펴볼 예정이다.

Structure of the Test Plan Document; Master Test Plan and Level Test Plans

Once test planning is complete, the resulting artifact is the test plan document, which is divided into two types: the Master Test Plan and Level Test Plans.

The Master Test Plan is a comprehensive document that consolidates and manages all the subordinate level test plans. Its purpose is to oversee and control multiple test levels and non-functional testing from a holistic perspective — it is essentially the top-level plan that coordinates the entire testing effort.

Beneath the Master Test Plan are individual Level Test Plans, each specific to a particular test level. These detail the test strategy, specific activities, detailed schedule, test owners, execution methods, and tools for each test level. The test types covered correspond to the right side of the V-model; unit testing, integration testing, system testing, acceptance testing — as well as non-functional testing such as load and performance testing.

In summary, if the Master Test Plan is the big picture that provides an overview of all testing, then the Level Test Plans are the detailed blueprints that specify exactly how each test will be conducted within that big picture.

테스트 계획서의 구성; 총괄 테스트 계획과 단계별 테스트 계획

테스트 계획 수립이 완료되면 그 결과물로 테스트 계획서가 만들어진다. 테스트 계획서는 크게 총괄 테스트 계획과 단계별 테스트 계획 두 가지로 나뉜다.

먼저 총괄 테스트 계획은 하위에 존재하는 여러 단계별 테스트 계획들을 하나로 묶어 종합적으로 관리하는 계획서다. 여러 테스트 단계와 비기능 테스트 등을 전체적인 시각에서 관리하고 통제하는 것이 목적이며, 말 그대로 테스트 전반을 조율하는 최상위 계획서라고 볼 수 있다.

그리고 이 총괄 테스트 계획 아래에는 각 단계별로 세분화된 단계별 테스트 계획이 존재한다. 단계별 테스트 계획에서는 각 테스트 단계에서 수행할 테스트 전략, 구체적인 활동, 세부 일정, 테스트 담당자, 수행 방법, 사용 도구 등을 상세하게 계획한다. 대상이 되는 테스트 유형은 V 모델의 오른쪽에 해당하는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 그리고 사용량이나 성능 등을 검증하는 비기능 테스트까지 포함된다.

정리하자면, 총괄 테스트 계획이 전체 테스트를 조망하는 큰 그림이라면, 단계별 테스트 계획은 그 큰 그림 안에서 각 테스트를 어떻게 실제로 수행할 것인지를 구체적으로 담아낸 세부 설계도라고 할 수 있다.

Contents of the Master Test Plan and Level Test Plans

Since the test plan document is divided into master and level plans, the depth and specificity of content in each naturally differs.

The Master Test Plan contains high-level content: the test purpose and scope explaining why testing is being conducted; the test item definition clarifying what will be tested; the test strategy and approach describing how testing will proceed; the overall schedule; the organizational structure and roles defining who is responsible for what; and assumptions and constraints that may affect test execution. In short, the Master Test Plan is a document capturing the big picture of all testing.

Based on this master plan, individual Level Test Plans are created — separate documents for each test level such as unit, integration, system, and acceptance testing. These contain much more specific content: the test scope and strategy for that level, the activities and objectives to be performed, the characteristics of the test items, test design methods, constraints during execution, input/output work products, test tools to be used, the detailed schedule, and the final deliverables.

Ultimately, while the Master Test Plan provides the overall direction and criteria, the Level Test Plans serve as detailed execution guides explaining exactly how each test level will be carried out. Only when the two documents are organically connected can systematic and consistent test execution be achieved.

[예시] 총괄 및 단계별 테스트 계획서의 구성 항목

테스트 계획서는 총괄과 단계별로 나뉘는 만큼, 각각에 담기는 내용의 수준과 세부성도 자연스럽게 달라진다.

총괄 테스트 계획서에는 상위 수준의 내용들이 담긴다. 테스트를 왜 수행하는지에 대한 테스트 목적 및 범위, 무엇을 테스트할 것인지를 정의하는 테스트 대상 시스템 정의, 테스트를 어떻게 진행할 것인지에 대한 테스트 전략과 수행 절차, 전체적인 일정, 누가 어떤 역할을 맡을 것인지에 대한 조직 구성 및 역할, 그리고 테스트 수행에 영향을 줄 수 있는 가정 및 제약사항 등이 포함된다. 즉, 총괄 테스트 계획서는 테스트 전반을 조망하는 큰 그림을 담은 문서라고 할 수 있다.

이 총괄 계획서를 기반으로 단계별 테스트 계획서가 만들어진다. 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트와 같이 각 테스트 단계별로 세분화된 계획서가 따로 작성되며, 여기에는 훨씬 구체적인 내용들이 담긴다. 해당 단계에서의 테스트 범위 및 전략, 수행해야 할 활동과 목적, 테스트 대상의 특성, 테스트 설계 방법, 수행 시의 제약사항, 테스트의 입출력 산출물, 활용할 테스트 도구, 세부 일정, 그리고 최종적으로 만들어지는 산출물 등이 해당된다.

결국 총괄 테스트 계획서가 전체 방향과 기준을 제시하는 문서라면, 단계별 테스트 계획서는 그 기준 아래에서 각 테스트 단계를 실제로 어떻게 수행할 것인지를 상세하게 풀어낸 실행 지침서라고 볼 수 있다. 두 문서가 유기적으로 연결될 때 비로소 체계적이고 일관성 있는 테스트 수행이 가능해진다.

Input/Output Work Products and Exit Criteria for Unit and System Test Plans

Let us examine how a Level Test Plan is structured in practice, using unit testing and system testing as examples.

Unit Test Plan

To conduct unit testing, the input work products required are the unit test plan and unit test cases. After executing the test cases, the output work product; the test results report; is produced. Tools such as JUnit, a Java-based testing framework, are used in this process.

A key aspect of unit testing is the exit criteria. Since unit testing involves directly examining the source code, coverage - a measure of how much code has been tested - is used as the exit criterion. The two most common types are statement coverage (the ratio of executed statements to total statements) and branch coverage (the ratio of tested branches or decision points). A target value is set based on these metrics, and the test is considered complete when the target is met.

System Test Plan

System testing is performed based on the results of requirements analysis in the V-model. Like unit testing, the input work products are the system test plan and test cases, and the output work product after execution is the test results report. Tools such as JMeter may be used at this level.

The exit criteria for system testing are based on requirements coverage — the percentage of total requirements for which testing has been performed. A target percentage is set and serves as the completion benchmark.

While detailed schedules, test owners, and specific execution methods are also included in the plan, even the input/output work products and exit criteria alone illustrate how concretely and measurably a Level Test Plan must be written.

[예시] 단위 테스트 및 시스템 테스트 계획서의 입/출력 산출물과 완료 기준

단계별 테스트 계획서가 실제로 어떻게 구성되는지를 단위 테스트와 시스템 테스트를 예시로 살펴보자.

단위 테스트 계획서

단위 테스트를 수행하기 위해서는 먼저 입력 산출물로 단위 테스트 계획서와 단위 테스트 케이스가 필요하다. 테스트 케이스를 기반으로 테스트를 수행하고 나면 출력 산출물인 테스트 결과서가 만들어진다. 이 과정에서는 Java 기반의 JUnit과 같은 테스트 도구가 활용된다.

단위 테스트에서 주목해야 할 부분은 완료 기준이다. 단위 테스트는 실제 코드를 직접 들여다보며 수행하기 때문에, 얼마나 많은 코드를 테스트했는지를 나타내는 커버리지(Coverage) 를 완료 기준으로 활용한다. 대표적으로 문장 커버리지와 분기 커버리지가 있는데, 문장 커버리지는 전체 문장 수 대비 테스트가 수행된 문장 수의 비율로, 분기 커버리지는 조건문이나 분기문이 얼마나 테스트되었는지의 비율로 산출된다. 이 수치를 기반으로 목표치를 설정하고, 그 목표를 달성했을 때 테스트가 완료된 것으로 판단한다.

시스템 테스트 계획서

시스템 테스트는 V 모델 기준으로 요구사항 분석 결과를 바탕으로 수행된다. 단위 테스트와 마찬가지로 테스트를 실제로 수행하기 위한 입력 산출물로 시스템 테스트 계획서와 테스트 케이스가 필요하며, 수행 후에는 출력 산출물인 테스트 결과서가 생성된다. 이 단계에서는 JMeter와 같은 도구가 활용될 수 있다.

시스템 테스트의 완료 기준은 요구사항 커버리지를 기반으로 한다. 전체 요구사항 중 실제로 테스트가 수행된 요구사항이 몇 퍼센트인지를 산출하여 목표치를 설정하고, 이를 완료 기준으로 삼는 것이다.

물론 이 외에도 테스트 수행을 위한 세부 일정, 담당자, 구체적인 수행 방법 등 다양한 요소들이 계획서에 포함되지만, 입출력 산출물과 완료 기준만 보더라도 단계별 테스트 계획서가 얼마나 구체적이고 측정 가능한 형태로 작성되어야 하는지를 잘 알 수 있다.

Why the Test Plan Matters

There is a clear reason why the test plan is developed so meticulously. A test plan is not merely about creating a document. It becomes the baseline for all test design and execution that follows. Testing is designed and executed based on the scope, strategy, and exit criteria defined in the plan, and the test plan also serves as the foundation for monitoring whether testing is proceeding as planned.

Without a plan, it is nearly impossible to judge whether testing is heading in the right direction. No matter how skilled the testers are, their efforts are unlikely to yield proper results without a clear plan. This is precisely why the importance of the Plan phase is repeatedly emphasized in software testing. The test plan is both the starting point and the backbone of successful testing.

테스트 계획, 왜 중요한가

테스트 계획을 이렇게 꼼꼼하게 수립하는 데는 분명한 이유가 있다. 테스트 계획은 단순히 문서를 만드는 작업에 그치는 것이 아니라, 이후에 이루어지는 테스트 설계와 수행 전반의 기준점이 되기 때문이다. 계획서에 정의된 범위, 전략, 완료 기준 등을 토대로 테스트가 설계되고 실행되며, 테스트가 계획대로 제대로 진행되고 있는지를 모니터링하는 기반 역할도 바로 테스트 계획이 담당한다.

결국 계획 없이는 테스트가 올바른 방향으로 가고 있는지조차 판단하기 어렵다. 아무리 뛰어난 테스터가 있더라도 명확한 계획이 없다면 그 노력이 제대로 된 결과로 이어지기 힘들다. 이것이 바로 소프트웨어 테스트에서 Plan의 중요성을 거듭 강조하는 이유이며, 테스트 계획은 성공적인 테스트의 시작이자 전체를 관통하는 근간이라고 할 수 있다.

2️⃣ Risk Management Overview

What is Risk?

Earlier, we learned that the ISO/IEC/IEEE 29119 standard emphasizes a risk-based test strategy in the test planning process. Let us now examine what risk management is and how its process unfolds.

First, what is Risk? It is actually a concept we encounter in everyday life ; "there is a risk of rain today," "this investment carries a high risk," "there are safety risks on a construction site." As these examples show, risk is not a special concept; it refers to an uncertain event or situation that may occur in the future.

The same applies to software testing. Unexpected events can occur during test execution, and such uncertainties can affect the quality and outcomes of testing. This is why identifying and managing risks in advance is a core element of test planning.

위험(Risk)이란 무엇인가

앞서 테스트 계획을 수립하는 과정에서 ISO/IEC/IEEE 29119 표준이 위험 기반의 테스트 전략을 강조한다는 것을 배웠다. 그렇다면 본격적으로 위험 관리란 무엇인지, 그리고 그 프로세스는 어떻게 진행되는지 살펴보자.

먼저 위험(Risk) 이란 무엇일까. 사실 위험이라는 단어는 우리가 일상생활에서도 흔하게 접하는 개념이다. 예를 들어 "오늘 비가 올 위험이 있다", "이 투자는 위험 부담이 크다", "공사 현장에는 안전 위험이 존재한다"와 같이, 우리는 이미 다양한 맥락에서 위험이라는 개념을 자연스럽게 사용하고 있다. 이처럼 위험은 특별한 개념이 아니라, 미래에 발생할 수 있는 불확실한 사건이나 상황을 가리키는 말이다.

소프트웨어 테스트에서도 마찬가지다. 테스트를 수행하는 과정에서도 예상치 못한 일들이 발생할 수 있고, 이러한 불확실성이 테스트의 품질과 결과에 영향을 미칠 수 있다. 그렇기 때문에 위험을 미리 파악하고 관리하는 것이 테스트 계획의 핵심이 되는 것이다. 이어서 위험 관리의 구체적인 프로세스를 살펴보도록 하자.

Risk vs. Issue. Potential Problem vs. Actual Problem

To understand risk more clearly, let us compare two contrasting concepts: Potential Problem and Actual Problem.

A Potential Problem is something that has not yet occurred but may happen in the future; this is Risk. An Actual Problem, on the other hand, is a problem that has already occurred; this is an Issue. Schedule delays, budget overruns, major scope changes, quality defects discovered in production, and customer complaints are all examples of Issues that have already materialized.

In practice, many organizations and individuals operate primarily in Issue mode; reacting to problems as they arise, only to be consumed by the next issue in an endless cycle. We see this pattern repeatedly in real-world disasters and accidents: countermeasures are developed only after the incident has occurred, after lives have been lost and economic damage has been done. This is the hallmark of Issue-driven work.

Working more systematically means operating in Risk mode; anticipating potential problems before they occur and preparing countermeasures in advance. As discussed, the act of planning is inherently about preparing for future events that have not yet happened, which means plans must always incorporate Risk.

Ultimately, risk-based planning is not a concept limited to testing. In any project or work environment, the key to systematic management is shifting from reacting to Issues after they erupt to proactively identifying and preparing for Risks.

Risk vs Issue, 잠재적 문제와 실제 문제

위험(Risk)을 좀 더 명확하게 이해하기 위해 상반되는 두 개념을 비교해보자. 바로 Potential Problem(잠재적 문제) 과 Actual Problem(실제 문제) 이다.

Potential Problem은 지금 당장 발생하지는 않았지만, 미래에 발생할 수도 있는 문제를 의미한다. 이것이 바로 Risk다. 반면 Actual Problem은 이미 발생한 문제, 즉 Issue를 가리킨다. 일정 지연, 예산 초과, 프로젝트의 대규모 변경, 품질 문제 발생, 고객 클레임 접수 등이 모두 이미 터진 Issue에 해당한다.

많은 조직과 개인이 실제로는 Issue 중심으로 일을 한다. 문제가 터지고 나서야 부랴부랴 대응하고, 또 다른 문제가 터지면 다시 그것을 처리하느라 바쁜 악순환이 반복되는 것이다. 우리 주변에서 일어나는 각종 재난이나 사고를 돌아봐도 마찬가지다. 사고가 발생하고 나서야 대책을 마련하고, 이미 소중한 생명과 막대한 경제적 손실이 발생한 뒤에야 제도가 바뀌는 모습을 우리는 너무나 자주 목격한다. 이것이 전형적인 Issue 중심의 일 처리 방식이다.

반면 보다 체계적으로 일을 한다는 것은 Risk 중심으로 일을 한다는 것을 의미한다. 문제가 터지기 전에 미리 잠재적인 위험을 예측하고, 그에 대한 대책을 사전에 마련하는 것이다. 앞서 배운 것처럼 계획을 세운다는 행위 자체가 아직 발생하지 않은 미래의 일들을 대비하는 것이기 때문에, 계획 안에는 반드시 Risk가 포함되어 있어야 한다.

결국 위험 기반으로 계획을 세우는 것은 단순히 테스트에만 국한된 이야기가 아니다. 어떤 프로젝트든, 어떤 업무든 체계적으로 관리하고자 한다면 Issue가 터난 후에 반응하는 방식에서 벗어나, Risk를 미리 식별하고 대비하는 방식으로 일하는 것이 핵심임을 반드시 기억하자.

프로젝트에서의 위험(Risk) 정의

프로젝트가 성공적으로 완료되기 위해서는 내외부 참여자, 예산, 시스템, 기술, 고객 등 수많은 구성 요소들이 유기적으로 잘 맞물려 돌아가야 한다. 그리고 일반적으로 프로젝트의 성공 여부는 품질(Quality), 비용(Cost), 납기(Delivery) 세 가지를 모두 만족했는지를 기준으로 판단한다.

여기서 위험(Risk)의 정의가 자연스럽게 도출된다. 이 세 가지 요소 중 적어도 하나에라도 영향을 줄 수 있는 잠재적인(Potential) 이벤트 또는 상태를 바로 위험, 즉 Risk라고 정의한다.

중요한 것은 "줄 수 있는"이라는 표현에 담긴 잠재성이다. 실제로 영향을 준 것이 아니라, 영향을 줄 수도 있는 가능성만으로도 Risk로 간주한다는 점이다. 예를 들어 핵심 개발자의 이탈 가능성, 기술적 난이도로 인한 일정 지연 가능성, 요구사항의 잦은 변경 가능성 등이 모두 Risk에 해당한다. 아직 아무 일도 일어나지 않았지만, 그것이 현실이 되었을 때 프로젝트의 품질, 비용, 납기에 영향을 미칠 수 있다면 그 자체로 Risk인 것이다.

결국 프로젝트에서 위험을 관리한다는 것은, 이처럼 프로젝트의 성공을 위협할 수 있는 잠재적 요소들을 미리 식별하고 대비하는 활동이라고 할 수 있다.

2. Risk Management Process

Definition of Risk in a Project Context

For a project to be completed successfully, numerous components, internal and external stakeholders, budget, systems, technology, and customers - must work together in harmony. Generally, the success of a project is judged by whether it satisfies all three of the following criteria: Quality (Q), Cost (C), and Delivery (D).

위험 관리 프로세스

위험 관리 프로세스란 소프트웨어 프로젝트의 목표인 품질, 비용, 일정을 성공적으로 만족시키기 위해, 프로젝트에 존재하는 위험을 미리 식별하고 분석하여 대비해나가는 일련의 활동을 말한다.

이 프로세스는 크게 세 단계로 진행된다.

Risk Identification

Risk identification is the activity of finding potential problems that could affect the achievement of project goals — quality, cost, and schedule. It involves continuously asking, "What risks could arise when performing this activity?" as the project plan is developed.

This is easier said than done, because without it being a habit, it is easy to skip over. Many people are accustomed to working through a to-do list and lack the practice of proactively looking for potential problems. However, failing to identify risks allows small risks to grow into Issues — what could have been contained at 1 grows into 10 and then 100.

Methods for Identifying Risks

There are three commonly used methods for systematically identifying risks.

The first is using a Risk Database. Organizations that manage risks well maintain a risk database containing records of past risks and how they were resolved. Referencing this database makes it easier to identify risks that could arise in the current project.

The second is using an Issue Database. Even organizations without a risk database typically have records of past issues — in the form of spreadsheets or meeting minutes. These past issues can recur in the next project, making them potential risks. An issue database alone can be sufficient for deriving current project risks.

The third is using a Risk Checklist. By reviewing a checklist item by item with Yes/No responses, potential risks for the project can be identified. Items marked "No" represent risk factors that could materialize.

Risk Examples in a Testing Project

To illustrate how risk identification works in practice, consider the following examples from a testing project.

The first is a sudden change in customer priorities. A situation may arise where, after a test strategy and test cases have already been developed, a customer suddenly requests that a specific feature be tested first. Although it has not happened yet, it is entirely plausible, and a response strategy should be prepared in advance.

The second is the risk associated with an external test outsourcing vendor. When an external vendor is contracted because internal resources are insufficient for testing, the vendor may go bankrupt or fail to fulfill the contract. This can lead to schedule delays and cost overruns, so contingency plans must be prepared.

The third is insufficient tester competency. A test team may include both experienced professionals and junior employees with limited testing experience. Testing performed without adequate competency can directly affect quality and must therefore be identified as a significant risk factor.

Risk Identification Must Become a Habit

Ultimately, the starting point of risk identification is simple: habitually asking "What risks could arise as I carry out this work?" whenever planning. By repeatedly leveraging past issue databases and checklists to uncover as many risks as possible, the capability to execute projects on a risk-based foundation will naturally develop over time.

위험 식별(Risk Identification)

위험 식별이란 프로젝트의 목표인 품질, 비용, 일정의 달성에 영향을 줄 수 있는 잠재적인 문제를 찾아내는 활동이다. 프로젝트 계획을 수립해나가면서 "이 활동을 할 때는 어떤 위험이 있을 수 있을까?"를 끊임없이 자문하는 과정이 바로 위험 식별이다.

이것이 말처럼 쉽지 않은 이유는 습관이 되어있지 않으면 자연스럽게 넘어가기 쉽기 때문이다. 많은 사람들이 해야 할 일의 목록만 생각하며 일을 처리하는 데 익숙하다 보니, 잠재적인 문제를 미리 찾는 연습이 부족한 경우가 많다. 하지만 위험 식별을 놓치면 작은 위험이 Issue로 번져 1로 막을 수 있었던 것이 10이 되고 100이 되는 상황을 맞이하게 된다.

위험을 찾아내는 방법

위험을 체계적으로 식별하기 위해 일반적으로 활용하는 방법은 크게 세 가지다.

첫 번째는 위험 DB 활용이다. 위험 관리를 잘 하는 조직이라면 과거에 발생했던 위험과 그 해결 방법이 기록된 위험 DB를 보유하고 있다. 이 DB를 참고하면 현재 프로젝트에서 발생할 수 있는 위험을 보다 수월하게 찾아낼 수 있다.

두 번째는 이슈 DB 활용이다. 위험 DB가 없는 조직이라도 과거에 발생한 문제들을 기록한 이슈 DB는 갖고 있는 경우가 많다. 엑셀 파일이나 회의록 형태로 남아있는 과거의 이슈들은 다음 프로젝트에서도 똑같이 발생할 수 있는 잠재적 위험이 된다. 즉, 이슈 DB만으로도 현재 프로젝트의 위험을 충분히 도출해낼 수 있다.

세 번째는 위험 체크리스트 활용이다. 체크리스트를 항목별로 Yes/No로 점검하며 이 프로젝트에서 발생 가능한 위험을 확인하는 방식이다. No로 표시된 항목들은 곧 발생할 수 있는 위험 요소가 된다.

실제 테스트 프로젝트에서의 위험 예시

위험 식별이 실제로 어떻게 이루어지는지 테스트 프로젝트를 예시로 살펴보자. 먼저 고객 우선순위의 갑작스러운 변경이다. 테스트 전략과 테스트 케이스를 이미 만들어 놓은 상황에서 고객이 갑자기 특정 기능을 먼저 테스트해달라고 요청하는 경우가 생길 수 있다. 아직 발생하지는 않았지만 충분히 일어날 수 있는 위험이며, 이에 대한 대응 전략을 미리 마련해두어야 한다.

다음으로 외부 테스트 아웃소싱 업체의 리스크다. 내부 인력만으로 테스트를 수행하기 어려워 외부 업체와 계약했을 때, 그 업체가 파산하거나 계약을 이행하지 못하는 상황이 발생할 수 있다. 이 경우 일정 지연과 비용 낭비로 이어질 수 있기 때문에 사전에 대처 방안을 준비해야 한다.

마지막으로 테스터의 역량 부족이다. 테스트 팀 안에는 전문가도 있지만 경험이 부족한 신입 직원도 있을 수 있다. 역량이 충분히 갖추어지지 않은 상태에서 테스트를 수행하면 품질에 직접적인 영향을 미칠 수 있으므로, 이 역시 중요한 위험 요소로 식별해야 한다.

위험 식별, 습관이 되어야 한다

결국 위험 식별의 출발점은 단순하다. 계획을 세울 때 "이 일을 수행하다 보면 어떤 위험이 생길 수 있을까?"라는 질문을 습관적으로 던지는 것이다. 과거의 이슈 DB나 체크리스트를 적극 활용하여 최대한 많은 위험을 찾아내려는 노력을 반복하다 보면, 자연스럽게 위험에 기반하여 프로젝트를 수행하는 역량이 갖추어지게 된다.

Risk Analysis

Once risk identification has produced a large number of risk factors, the next step is risk analysis. It is not feasible to prepare countermeasures for all 20–30 identified risks, given the constraints of cost, schedule, and resources that every project faces. The core of risk analysis is therefore evaluating the magnitude of each identified risk to determine which risks to prioritize for management.

Two Evaluation Criteria for Risk Analysis

Risk magnitude is measured using two factors: probability of occurrence and impact.

Probability of occurrence refers to the likelihood that the risk will actually materialize. It is typically scored as 1 (Low) for below 30%, 2 (Medium) for 30%–80%, and 3 (High) for above 80%. Impact refers to how significantly the risk would affect Quality, Cost, and Delivery if it occurred, and is similarly scored as 1 (Low) for below 10%, 2 (Medium) for 10%–20%, and 3 (High) for above 20%.

Deriving Risk Levels via a Risk Matrix

By quantifying both criteria, they can be represented in a Risk Matrix. Risk levels are derived by multiplying or combining the probability and impact scores. For instance, a probability of 1 (Low) and impact of 1 (Low) results in a low-level risk, while a probability of 2 (Medium) and impact of 2 (Medium) results in a level 4 (Medium) risk. The example from the risk identification phase — a sudden change in customer priorities — would be evaluated as probability 2 (Medium) and impact 3 (High), resulting in a level 6 (High) risk.

Why Risk Analysis is Essential

Once the risk level hierarchy is established, it becomes clear which of the 20 identified risks require priority management. High-level risks are managed first, followed by medium-level risks. While it would be ideal to address every risk if time, cost, and resources were unlimited, projects always operate within constraints. Risk analysis is therefore an essential activity in systematic project management, ensuring that limited resources are focused on the most critical risks.

위험 분석(Risk Analysis)

위험 식별을 통해 수많은 위험 요소들이 도출되고 나면, 그 다음 단계는 위험 분석이다. 20~30개에 달하는 위험 요소 모두에 대해 대책을 마련하는 것은 현실적으로 불가능하다. 프로젝트에는 항상 비용, 일정, 자원과 같은 제약이 존재하기 때문이다. 따라서 식별된 위험들의 크기를 평가하여 어떤 위험을 중점적으로 관리할 것인지 우선순위를 정하는 것이 위험 분석의 핵심이다.

위험 분석의 두 가지 평가 기준

위험의 크기를 측정하기 위해서는 두 가지 요소를 평가한다. 바로 발생 확률과 영향도다.

발생 확률은 해당 위험이 실제로 일어날 가능성을 의미하며, 일반적으로 30% 이하는 1(하), 30%80%는 2(중), 80% 이상은 3(상)과 같이 점수로 구분한다. 영향도는 위험이 발생했을 때 품질(Quality), 비용(Cost), 납기(Delivery)에 얼마나 큰 영향을 미치는지를 나타내며, 10% 이하는 1(하), 10%20%는 2(중), 20% 이상은 3(상)으로 동일하게 점수화한다.

위험 매트릭스를 통한 등급 산출

이렇게 두 가지 기준을 점수화하면 이를 매트릭스 형태로 표현할 수 있다. 발생 확률과 영향도를 곱하거나 조합하여 위험의 등급을 산출하는 방식이다. 예를 들어 발생 확률이 1(하)이고 영향도가 1(하)이면 전체적으로 낮은 수준의 위험이 되고, 발생 확률이 2(중)이고 영향도가 2(중)이면 4(중) 수준의 위험이 된다. 앞서 위험 식별 단계에서 예시로 들었던 고객 우선순위의 갑작스러운 변경의 경우, 발생 확률 2(중)에 영향도 3(상)으로 평가되어 6(상) 수준의 고위험에 해당한다.

위험 분석이 필수적인 이유

이와 같이 위험 등급 체계를 정하고 나면 20개의 위험 요소 중 어떤 것을 중점적으로 관리해야 할지가 명확해진다. 고수준으로 분류된 위험들을 최우선으로 관리하고, 그 다음 순위로 중간 수준의 위험들을 관리하는 방식이다. 시간과 비용, 자원이 충분하다면 모든 위험에 대응할 수 있겠지만, 현실적으로 프로젝트는 항상 한정된 자원 안에서 운영된다. 그렇기 때문에 위험 분석을 통해 우선순위를 정하고 한정된 자원을 가장 중요한 위험에 집중적으로 투입하는 이 과정은 체계적인 프로젝트 관리에 있어 필수적인 활동이라고 할 수 있다.

Risk Mitigation Identification

Having identified and prioritized risks, the final step is developing countermeasures. Risk mitigation means preparing responses that either reduce the probability of a risk occurring or minimize its impact if it does occur, bringing it down to an acceptable level. There are four categories of risk mitigation strategies.

1) Risk Avoidance

This approach completely eliminates the possibility of a risk occurring. For example, performing integration testing using the Big Bang approach; integrating dozens or hundreds of modules all at once; makes it extremely difficult to trace which module caused a defect. To eliminate this risk from the outset, adopting an incremental integration test strategy instead of Big Bang is a classic example of risk avoidance. The key is creating an environment where the risk cannot occur in the first place.

2) Risk Mitigation

Rather than eliminating a risk entirely, this approach reduces it to an acceptable level. For example, when there is a risk that customer requirement priorities may suddenly change, the goal is to reduce the probability of that change from 50% to 10–20%. This can be achieved by engaging the customer actively from the early stages of development to lock down requirements as much as possible, thereby reducing the probability of change at the source.

3) Risk Transference

This approach does not solve the risk directly but instead transfers the responsibility or impact to another party. It is most commonly used when the probability is low but the potential damage is high. For example, to guard against the possibility of a test outsourcing vendor failing to fulfill the contract, requiring the vendor to purchase performance bond insurance, even at additional cost; transfers the financial risk to a third party. In practice, many organizations mandate performance bond insurance for inter-agency contracts. This is not an evasion of responsibility but a rational strategy for reducing the impact of risks that are difficult to manage internally.

4) Risk Acceptance

This approach accepts risks that fall within a tolerable level. For example, if testers lack sufficient competency but must be included in order to complete testing successfully, the risk can be accepted by investing in test training to build their skills over time. If it is judged that they will be able to perform adequately once trained, then the risk is accepted and managed accordingly.

These four mitigation strategies must be selected appropriately based on the magnitude and nature of each risk identified and analyzed. Most importantly, the key is to understand what risk is, practice the three-phase risk management process of Identification → Analysis → Mitigation systematically, and use it to prevent small risks from becoming large Issues. The risk management concepts learned here will serve as a critical foundation when developing the risk-based test strategy covered in future sessions.

위험 완화 방안 식별(Risk Mitigation Identification)

위험을 식별하고 우선순위를 분석했다면, 이제 그 위험들에 대한 대책을 마련하는 단계가 남아있다. 위험 완화란 위험이 발생할 확률을 낮추거나, 발생하더라도 그 영향도를 최소화하여 허용 가능한 수준으로 낮추기 위한 대책을 마련하는 것이다. 위험 완화 방안은 크게 네 가지로 구분된다.

1) 위험 회피 (Avoidance)

위험이 발생할 가능성을 애초에 완전히 제거하는 방법이다. 예를 들어 통합 테스트를 빅뱅(Big Bang) 방식으로 진행하면, 수십~수백 개의 모듈을 한꺼번에 통합하기 때문에 문제가 발생했을 때 어느 모듈에서 비롯된 것인지 추적하기가 매우 어렵다. 이러한 위험을 처음부터 없애기 위해 빅뱅 방식 대신 점진적 통합 테스트 전략을 채택하는 것이 위험 회피의 대표적인 예다. 처음부터 위험이 발생할 수 없는 환경을 만드는 것이 핵심이다.

2) 위험 완화 (Mitigation)

위험을 완전히 없애는 것이 아니라, 허용 가능한 수준 이하로 낮추는 방법이다. 예를 들어 고객의 요구사항 우선순위가 갑자기 변경될 위험이 있을 때, 그 변경 가능성을 50%에서 10~20%로 줄이는 것을 목표로 한다. 이를 위해 개발 후반부가 아닌 초기 단계부터 고객을 적극적으로 참여시켜 요구사항을 최대한 확정짓는 방식으로 위험의 발생 확률 자체를 낮출 수 있다.

3) 위험 전이 (Transference)

위험을 내가 직접 해결하는 것이 아니라, 외부의 힘을 빌려 위험의 책임이나 영향을 다른 주체에게 이전하는 방법이다. 발생 확률은 낮지만 피해가 클 경우에 주로 활용된다. 예를 들어 테스트 아웃소싱 업체가 계약을 이행하지 못하는 상황에 대비하여, 비용이 다소 들더라도 업체가 이행보증보험에 가입하도록 하여 피해를 최소화하는 것이 대표적인 사례다. 실제 현업에서도 기관 간 계약 시 이행보증보험 가입을 의무화하는 경우가 많다. 이는 책임 회피가 아니라, 감당하기 어려운 위험의 영향도를 줄이기 위한 합리적인 선택이다.

4) 위험 수용 (Acceptance)

허용 가능한 수준의 위험을 그대로 받아들이는 방법이다. 예를 들어 테스터의 역량이 부족하더라도, 해당 인력을 포함하여 테스트를 성공적으로 수행해야 하는 상황이라면 테스트 교육을 통해 역량을 키우는 것을 선택할 수 있다. 당장은 부족하더라도 시간이 지나면 충분히 수행 가능하다고 판단한다면, 그 위험을 감내하고 수용하는 것이다.

이 네 가지 위험 완화 방안은 앞서 식별하고 분석한 위험의 크기와 성격에 따라 적절하게 선택되어야 한다. 무엇보다 중요한 것은 위험이 무엇인지 이해하고, 식별 → 분석 → 완화의 세 단계로 이루어진 위험 관리 프로세스를 체계적으로 실천하는 것이다. 이를 통해 나중에 큰 Issue로 번질 수 있는 문제들을 사전에 차단하고, 프로젝트를 안정적으로 이끌어 나갈 수 있다. 앞으로 학습할 위험 기반의 테스트 전략 수립에서도 오늘 배운 위험 관리의 개념과 프로세스가 핵심적인 토대로 활용될 것이다.

3️⃣ Risk-based testing strategy

What is Risk-Based Testing?

Risk-Based Testing is a strategy that identifies potential problems that could arise in a project and applies the risk management process; Risk Identification → Analysis → Mitigation; integrated into the testing effort.

Just as resources are constrained in a project, testing resources - cost, tools, equipment, and personnel — are always limited. In this environment, the essence of the risk-based test strategy is to invest available resources most efficiently based on risk, in order to achieve the testing objective of discovering as many defects as possible.

위험 기반 테스트(Risk-Based Test)란?

위험 기반 테스트란 프로젝트에서 발생할 수 있는 잠재적인 문제들을 찾아내고, 위험 관리 프로세스인 위험 식별 → 분석 → 완화의 과정을 테스트에 융합하여 적용하는 전략이다.

프로젝트에서 자원이 제한되어 있듯이, 테스트에서도 비용, 도구, 장비, 인원은 항상 제한되어 있다. 이러한 환경에서 가지고 있는 자원을 가장 효율적으로 활용하기 위해, 다양한 결함을 발견한다는 테스트의 목표를 달성하기 위해 위험에 기반하여 자원을 집중적으로 투입하는 것이 바로 위험 기반 테스트 전략의 본질이다.

Goals Achievable Through Risk-Based Testing

There are three key benefits expected from risk-based testing.

The first is improved software product quality. By identifying and analyzing risks and establishing priorities, the factors most likely to contribute to product defects are naturally surfaced. Focusing testing efforts on these factors naturally elevates product quality.

The second is improved overall test coverage. Concentrating on higher-priority areas means testing the features that customers and stakeholders care about most first. This ensures meaningful test coverage where it matters most.

The third is improved test efficiency. By directing limited resources toward high-risk areas, greater test effectiveness is achieved with the same resources. Risk-based testing is ultimately the most rational test strategy for achieving maximum quality impact with limited resources.

위험 기반 테스트를 통해 얻을 수 있는 목표

위험 기반 테스트를 통해 기대할 수 있는 효과는 크게 세 가지다.

첫 번째는 소프트웨어 제품 품질 향상이다. 위험을 식별하고 분석하여 우선순위를 정하다 보면 자연스럽게 제품의 결함에 가장 큰 영향을 미칠 수 있는 요소를 찾게 된다. 이 요소들을 중점적으로 테스트함으로써 제품의 품질이 자연스럽게 높아진다.

두 번째는 전체 테스트 커버리지 개선이다. 우선순위가 낮은 부분보다 높은 부분에 집중한다는 것은, 고객과 이해관계자들이 가장 중요하게 생각하는 영역을 먼저 충분히 테스트한다는 의미다. 이를 통해 실질적으로 의미 있는 테스트 커버리지를 확보할 수 있다.

세 번째는 테스트 효율성 향상이다. 한정된 자원을 위험 수준이 높은 영역에 집중 투입함으로써, 같은 자원으로 더 큰 테스트 효과를 얻을 수 있다. 결국 위험 기반 테스트는 "적은 자원으로 최대의 품질 효과를 내기 위한" 가장 합리적인 테스트 전략이라고 할 수 있다.

Risk Analysis Criteria from a Testing Perspective

Risk analysis involves evaluating the probability of occurrence and impact of identified risks to establish priorities. Let me examine how these two criteria are applied specifically from a testing perspective.

Probability of Occurrence; Likelihood of Defects

In a testing context, probability of occurrence refers to the likelihood that defects will arise during testing. The following factors contribute to this likelihood.

First is source code complexity. Code with nested loops inside conditionals, or so-called spaghetti code, is structurally complex and more prone to defects. Inter-module coupling complexity is also significant — the more tightly interdependent the modules, the more likely unexpected defects are to emerge. Implementation technology difficulty is another contributing factor. Lines of Code (LOC) also matter — the more lines of code, the greater the likelihood of defects. Finally, developer competency cannot be overlooked; the difference in skill between junior, mid-level, and senior developers directly affects defect probability.

Impact ; Effect on Business When a Defect Occurs

Impact refers to how significantly a functional failure would affect the business. The factors that compose impact include the following.

First is user criticality — how important the function is to the user determines the degree of impact. Economic and safety damage is also a key criterion; if a failure leads to financial loss or safety incidents, the impact is correspondingly high. Damage to the organization's reputation must also be considered — incidents involving hacking, payment failures, or authentication issues can severely undermine organizational credibility. Finally, frequency of use contributes to impact; the more frequently a function is used, the more people are affected when a defect occurs.

Risk Exposure

By comprehensively evaluating the factors composing probability and impact, the magnitude of each risk is classified as Low, Medium, or High. This is referred to as Risk Exposure, and it determines the priority of which areas to focus testing on. By concentrating test resources on areas with high Risk Exposure, the most effective testing possible is achieved within the constraints of available resources.

테스트 관점에서의 위험 분석 기준

위험 분석은 식별된 위험들에 대해 발생 확률과 영향도를 평가하여 우선순위를 정하는 과정이다. 테스트 측면에서 이 두 가지 기준을 어떻게 적용하는지 구체적으로 살펴보자.

발생 확률; 결함이 생길 가능성

테스트에서의 발생 확률이란 테스트를 수행할 때 결함이 발생할 가능성을 의미한다. 즉, 어떤 프로그램이나 모듈에서 결함이 많이 생길 것인가를 따져보는 것이다. 이에 영향을 미치는 요소들은 다음과 같다.

먼저 소스코드의 복잡성(Complexity) 이다. 분기문 안에 반복문이 중첩되어 있거나 이른바 스파게티 코드처럼 구조가 복잡할수록 결함이 발생할 가능성이 높아진다. 또한 모듈 간 상호 관계의 복잡성도 중요한 요소인데, 여러 모듈이 얽히고 설킨 구조일수록 예상치 못한 결함이 생기기 쉽다. 구현 기술의 난이도가 높은 경우도 마찬가지다. 그리고 코드의 규모(Lines of Code) 도 중요한데, 코드 라인이 많아질수록 그만큼 결함이 발생할 가능성도 함께 커진다. 마지막으로 개발자의 역량도 빼놓을 수 없다. 초급, 중급, 고급 개발자의 실력 차이는 결함 발생 확률에 직접적인 영향을 미친다.

영향도; 결함 발생 시 비즈니스에 미치는 영향

영향도란 기능 장애가 발생했을 때 비즈니스 전반에 얼마나 큰 영향을 미치는가를 평가하는 기준이다. 영향도를 구성하는 요소들도 다양하다.

먼저 사용자의 취급 중요도다. 사용자가 해당 기능을 얼마나 중요하게 여기는지에 따라 영향도가 달라진다. 경제적·안전적 피해 또한 중요한 기준이다. 기능 고장이 발생했을 때 금전적 손실이나 안전 문제로 이어진다면 그만큼 영향도가 높다. 조직의 대외 이미지 피해도 빼놓을 수 없는데, 해킹이나 결제·인증 문제가 발생하면 조직의 신뢰도에 큰 타격을 줄 수 있다. 마지막으로 기능 사용 빈도도 영향도에 기여한다. 사용자가 자주 쓰는 기능일수록 결함이 발생했을 때 더 많은 사람들에게 영향을 미치기 때문이다.

위험 노출도(Risk Exposure)

이처럼 발생 확률과 영향도를 구성하는 요소들을 종합적으로 평가하면, 각 위험 요소의 크기가 저, 중, 고 수준으로 산출된다. 이를 위험 노출도(Risk Exposure) 라고 하며, 이 수치를 기반으로 어떤 영역을 중점적으로 테스트할 것인지 우선순위가 결정된다. 결국 테스트 자원을 위험 노출도가 높은 영역에 집중 투입함으로써, 한정된 자원 안에서 가장 효과적인 테스트를 수행할 수 있게 되는 것이다.

Example: Risk Analysis; Vaccine Appointment System

Let me examine how risk analysis works in practice using a vaccine appointment booking system.

The main requirements of this system include functions such as member registration, member withdrawal, login, logout, and vaccine appointment booking. For each function, the probability of defects occurring and the impact on the business if they do are evaluated on a scale of 1–5, and the two values are multiplied to derive the risk magnitude. It is important to note that this evaluation must be performed by domain experts familiar with the system.

For example, the member registration function is evaluated with a probability of 3 and impact of 4, resulting in a risk magnitude of 12. The member withdrawal function scores a probability of 2 and impact of 1, yielding a risk magnitude of only 2. The login function, on the other hand, scores a probability of 4 and impact of 5, resulting in the highest risk magnitude of 20. This is because if login is unavailable, all core system functions — appointment booking, inquiry, and cancellation — become completely inaccessible, warranting the highest impact rating.

By deriving risk magnitudes for all requirements in this way, it becomes clearly apparent which functions are high-risk and which are low-risk. This enables the development of a differentiated test strategy — concentrating more test resources on high-risk functions and allocating relatively fewer resources to low-risk ones. Risk analysis is ultimately a rational decision-making tool for distributing limited test resources most effectively.

[예시] 위험 분석 - 백신 접종 예약 시스템

위험 분석이 실제로 어떻게 이루어지는지 백신 접종 예약 시스템을 예시로 살펴보자.

이 시스템의 주요 요구사항으로는 회원 가입, 회원 탈퇴, 로그인, 로그아웃, 접종 예약 등의 기능이 있다. 각 기능에 대해 결함이 발생할 확률과 발생 시 비즈니스에 미치는 영향도를 1~5점 척도로 평가하고, 두 값을 곱하여 위험의 크기를 산출한다. 이 평가는 반드시 해당 시스템과 관련된 전문가가 수행해야 한다는 점이 중요하다.

예를 들어 회원 가입 기능은 발생 확률 3, 영향도 4로 평가되어 위험의 크기가 12가 된다. 회원 탈퇴 기능은 발생 확률 2, 영향도 1로 위험의 크기가 2에 그친다. 반면 로그인 기능은 발생 확률 4, 영향도 5로 위험의 크기가 20으로 가장 높게 산출된다. 로그인이 불가능하면 예약, 조회, 취소 등 시스템의 모든 핵심 기능을 아예 사용할 수 없게 되기 때문에 영향도가 최고 수준으로 평가된 것이다.

이처럼 모든 요구사항 항목에 대해 동일한 방식으로 위험의 크기를 산출하면, 어떤 기능이 고위험이고 어떤 기능이 저위험인지가 명확하게 드러난다. 이를 토대로 위험의 크기가 큰 기능에는 더 많은 테스트 자원을 집중하고, 위험의 크기가 작은 기능에는 상대적으로 적은 자원을 투입하는 차별화된 테스트 전략을 수립할 수 있다. 결국 위험 분석은 한정된 테스트 자원을 가장 효과적으로 배분하기 위한 합리적인 의사결정 도구인 셈이다.

Example: Unit Test Planning Based on Risk Analysis

Let me examine how risk analysis results are applied to actual test planning, again using the vaccine appointment booking system.

Risk Level Classification

Requirements are classified into four risk levels based on the scores derived from risk analysis. Level 1 represents the highest risk area with both high probability and high impact. Level 2 has low probability but high impact. Level 3 has high probability but low impact. Level 4 has both low probability and low impact.

Applying this to the vaccine appointment system: login, vaccine appointment, member registration, and appointment inquiry are classified as Level 1 (High Risk) with both high probability and high impact. Appointment cancellation falls under Level 2, while member withdrawal and logout are classified as Level 3 due to their relatively low risk magnitude.

Exit Criteria by Risk Level

These risk classifications are directly used to differentiate the exit criteria and test methods when developing the test plan.

For Level 1 high-risk items, the strictest criteria are applied. To minimize the likelihood of defects and reduce their impact if they do occur, the most rigorous coverage criterion — MC/DC (Modified Condition/Decision Coverage) at 100% completion — is set as the exit criterion. The goal is to test as wide a range of code as possible, leaving no room for hidden defects.

For Level 2 items, while not as strict as MC/DC, branch and condition coverage at 100% completion is set as the exit criterion. Sufficient testing is performed given the high impact, but with somewhat more flexibility than Level 1.

For Level 3 low-risk items, since the impact is relatively limited, statement coverage at 100% completion is set as the exit criterion, allowing for efficient allocation of test resources.

Significance of Risk-Based Test Planning

By incorporating risk analysis results into the test plan, strict criteria are applied to critical functions while appropriate criteria are applied to less critical ones, enabling the most effective use of limited resources. For instance, if the login function has a defect, all core system functions are paralyzed, customers stop using the service, and the company faces significant losses. In contrast, defects in Level 3 functions such as member withdrawal or logout have relatively limited impact. Ultimately, a risk-based test plan is a rational approach that addresses the greatest risks first and most thoroughly, effectively enhancing software product quality.

Risk Factor-Based Risk Analysis Example

Going one step further from the risk analysis method discussed earlier, let me examine an approach that breaks down risk factors by requirement for more granular analysis.

The basic structure remains the same; probability and impact are evaluated per requirement ; but here, risk is broken down into the following sub-categories for more systematic analysis:

• LOP (Loss of Power)

• CFD (Corrupted File Data)

• UUA (Unauthorised User Access)

• DNS (Database Not Synchronized)

• UUD (Unclear User Documentation)

• ST (Slow Throughput)

Each requirement is assessed against these risk factors, scores are assigned, and all scores are summed to derive the final risk magnitude for that requirement. For example, comparing Requirement 1 and Requirement 2, Requirement 2 scores 67 points, indicating a higher overall risk. This leads to the conclusion that more test resources should be concentrated on functions related to Requirement 2.

This approach goes beyond simply evaluating probability and impact, by itemizing specific risk factors for systematic review, it enables a more rigorous and precise risk analysis.

This concludes our examination of what risk is, how the risk management process is structured, and why this analysis is indispensable for developing a test strategy. Ultimately, a risk-based test strategy is an approach that incorporates all of these processes into the test plan, focusing on the most critical risks within limited resources to effectively improve software quality. The risk management concepts learned here will continue to serve as a critical foundation in the upcoming phases of test design and execution.

[예시]위험 분석 기반의 단위 테스트 계획 수립 예시

위험 분석 결과를 실제 테스트 계획에 어떻게 반영하는지 백신 접종 예약 시스템을 통해 살펴보자.

위험 등급 분류

위험 분석을 통해 산출된 점수를 기반으로 요구사항들을 네 가지 등급으로 분류한다. 1등급은 발생 확률과 영향도가 모두 높은 최고위험 영역이고, 2등급은 발생 확률은 낮지만 영향도가 높은 영역이다. 3등급은 발생 확률은 높지만 영향도가 낮은 영역이며, 4등급은 발생 확률과 영향도가 모두 낮은 저위험 영역이다.

백신 접종 예약 시스템에 적용하면, 로그인, 접종 예약, 회원 가입, 예약 조회는 발생 확률과 영향도가 모두 높은 1등급 고위험 항목에 해당한다. 예약 취소는 2등급에 해당하며, 회원 탈퇴와 로그아웃은 위험의 크기가 상대적으로 작아 3등급으로 분류된다.

등급별 테스트 완료 기준

이렇게 분류된 위험 등급은 테스트 계획을 수립할 때 완료 기준과 테스트 방법을 차별화하는 데 직접적으로 활용된다.

1등급 고위험 항목에 대해서는 가장 엄격한 기준을 적용한다. 결함의 발생 가능성을 최대한 줄이고 결함이 발생하더라도 그 영향도를 낮추어야 하기 때문에, 가장 높은 수준의 커버리지 기준인 MCDC 커버리지 100% 완료를 완료 기준으로 삼는다. 최대한 넓은 범위의 코드를 빠짐없이 테스트하여 결함이 숨어있을 가능성을 철저히 차단하는 것이다.

2등급 항목에 대해서는 MCDC만큼 엄격하지는 않더라도, 분기 및 조건 커버리지 100% 완료를 완료 기준으로 설정한다. 영향도가 높은 만큼 충분한 수준의 테스트를 수행하되, 1등급보다는 다소 유연한 기준을 적용하는 것이다.

3등급 저위험 항목은 상대적으로 영향도가 작기 때문에 문장 커버리지 100% 완료 정도를 완료 기준으로 삼아 테스트 자원을 효율적으로 배분한다.

위험 기반 테스트 계획의 의의

이처럼 위험 분석 결과를 테스트 계획에 반영하면, 중요한 기능에는 타이트한 기준을 적용하고 그렇지 않은 기능에는 적절한 수준의 기준을 적용하여 한정된 자원을 가장 효과적으로 활용할 수 있다. 예를 들어 로그인 기능에 결함이 발생한다면 예약, 조회, 취소 등 시스템의 모든 핵심 기능이 마비되어 고객은 서비스 이용을 멈추게 되고, 회사 입장에서는 막대한 손실로 이어질 수 있다. 반면 회원 탈퇴나 로그아웃과 같은 3등급 기능에 결함이 발생하더라도 그 영향은 상대적으로 제한적이다. 결국 위험 기반 테스트 계획은 가장 큰 위험을 가장 먼저, 가장 철저하게 다루어 소프트웨어 제품의 품질을 효과적으로 높이는 합리적인 접근 방식이라고 할 수 있다.

위험 요인 기반의 위험 분석 예시

앞서 살펴본 위험 분석 방법에서 한 단계 더 나아가, 요구사항별 위험 요인(Risk Factor)을 세분화하여 분석하는 방법을 살펴보자.

기본적인 구조는 동일하다. 요구사항 항목별로 발생 확률과 영향도를 평가하되, 여기서는 위험을 보다 체계적으로 분석하기 위해 위험 요인을 아래와 같이 소분류로 세분화한다.

• LOP (Loss of Power) — 전력 손실

• CFD (Corrupted File Data) — 파일 데이터 손상

• UUA (Unauthorised User Access) — 비인가 사용자 접근

• DNS (Database Not Synchronized) — 데이터베이스 미동기화

• UUD (Unclear User Documentation) — 불명확한 사용자 문서

• ST (Slow Throughput) — 느린 처리 속도

각 요구사항에 대해 이 위험 요인들을 하나씩 점검하고 점수를 부여한 뒤, 모든 점수를 합산하여 해당 요구사항의 최종 위험 크기를 산출한다. 예를 들어 요구사항 1번과 2번을 비교했을 때, 요구사항 2번이 67점으로 더 높은 위험 크기를 가지고 있어 더 큰 위험을 내포하고 있음을 알 수 있다. 이를 통해 요구사항 2번과 관련된 기능에 더 많은 테스트 자원을 집중해야 한다는 판단을 내릴 수 있다.

이 방식은 단순히 발생 확률과 영향도만을 평가하는 것에서 벗어나, 구체적인 위험 요인을 항목화하여 빠짐없이 점검할 수 있다는 점에서 보다 체계적이고 정밀한 위험 분석이 가능하다.

여기까지 위험이 무엇인지, 위험 관리 프로세스가 어떻게 구성되는지, 그리고 왜 이 분석이 테스트 전략 수립에 반드시 필요한지를 살펴보았다. 결국 위험 기반 테스트 전략이란 이 모든 과정을 테스트 계획에 녹여내어, 한정된 자원 안에서 가장 중요한 위험에 집중함으로써 소프트웨어의 품질을 효과적으로 높이는 접근 방식이다. 앞으로 배울 테스트 설계와 수행 단계에서도 오늘 학습한 위험 관리의 개념이 핵심적인 기반으로 계속 활용될 것이다.

1️⃣ Concept and Creation of Processors

How Does an Operating System Manage Running Tasks?

When using a computer, it's perfectly natural to have a web browser, messenger, and music player all open at the same time. From the user's perspective, it looks like several programs are simply running all at once; but the operating system is examining this situation in far greater detail.

So how exactly does the operating system distinguish and manage these executions? Rather than jumping straight to the answer, let's build up the concepts one by one so the answer emerges naturally. Getting a firm grasp of this big picture first will make topics like scheduling and synchronization - which come later, much easier to understand.

운영체제는 실행 중인 작업을 어떤 단위로 관리할까?

컴퓨터를 사용하다 보면 웹브라우저, 메신저, 음악 재생 프로그램을 동시에 켜두는 일이 자연스럽다. 사용자 입장에서는 여러 프로그램이 그냥 한꺼번에 돌아가는 것처럼 보이지만, 운영체제 입장에서는 이 상황을 훨씬 세밀하게 들여다보고 있다.

그렇다면 운영체제는 이 실행들을 도대체 어떤 단위로 구분하고 관리하는 걸까? 이 질문에 바로 답을 내놓기보다는, 답이 자연스럽게 나올 수 있도록 개념을 하나씩 쌓아가 보자. 이 큰 흐름을 먼저 잡아두면, 나중에 배우게 될 스케줄링이나 동기화 같은 주제들도 훨씬 수월하게 이해할 수 있을 것이다.

1. The Basic Concept of a Process

What's the Difference Between a Program and a Process?

In everyday conversation, "program" and "process" are often used interchangeably. In operating systems, however, the two concepts are clearly distinct.

A program is a file stored on a storage device - a static state that has not yet been executed. Simply put, it's a chunk of code that's ready to run but isn't doing anything yet.

A process, on the other hand, is the state in which that program has been loaded into memory and is actually running. From the moment something becomes a process, the operating system allocates system resources such as CPU and memory to that execution and begins treating it as a single, independent unit to manage.

To summarize: in terms of execution status, a program is in a non-running state, while a process is in a state where it has been allocated CPU time and is actively running. There's also a difference in resource usage. A program uses no resources at all, but a process actively consumes system resources like CPU and memory as it executes.

1. 프로세스 기본 개념

프로그램과 프로세스, 무엇이 다를까?

일상적인 대화에서는 '프로그램'과 '프로세스'를 크게 구분하지 않고 쓰는 경우가 많다. 하지만 운영체제에서는 이 두 개념이 명확하게 갈린다.

프로그램은 저장장치에 저장된 파일, 즉 아직 실행되지 않은 정적인 상태를 말한다. 쉽게 말해 실행될 준비는 됐지만 아직 아무것도 하고 있지 않은 코드 덩어리다.

반면 프로세스는 그 프로그램이 메모리에 올라가 실제로 실행되고 있는 상태를 말한다. 프로세스가 되는 순간부터 운영체제는 CPU와 메모리 같은 시스템 자원을 해당 실행에 할당하고, 이를 하나의 독립적인 관리 대상으로 다루기 시작한다.

정리하면 이렇다. 실행 여부를 기준으로 보면, 프로그램은 실행되지 않은 상태이고 프로세스는 CPU를 할당받아 실제로 실행 중인 상태다. 자원 사용 면에서도 차이가 있다. 프로그램은 자원을 전혀 사용하지 않지만, 프로세스는 실행되면서 CPU와 메모리 같은 시스템 자원을 실제로 소비한다.

One Program, Multiple Processes

There's an important point worth highlighting here. Even if it's the same program, running it multiple times creates a different process for each execution.

For example, suppose you launch the same web browser twice. There is only one program file stored on disk, but the operating system recognizes each execution as a separate process and manages them independently. The file is one, but the running instances are two.

This matters because, going forward, you need to remember that the basic unit the operating system manages is not the "program" but the "process." Scheduling, memory allocation, and synchronization all revolve around processes.

하나의 프로그램, 여러 개의 프로세스

여기서 한 가지 중요한 포인트가 있다. 하나의 프로그램이라도 여러 번 실행되면, 그 실행마다 서로 다른 프로세스가 만들어진다는 것이다.

예를 들어 같은 웹브라우저를 두 번 실행했다고 하자. 디스크에 저장된 프로그램 파일은 하나지만, 운영체제는 각각의 실행을 별개의 프로세스로 인식하고 따로따로 관리한다. 파일은 하나여도 실행 중인 인스턴스는 둘인 셈이다.

이 개념이 중요한 이유는, 앞으로 운영체제가 관리하는 기본 단위가 '프로그램'이 아니라 바로 '프로세스'라는 점을 기억해야 하기 때문이다. 스케줄링도, 메모리 할당도, 동기화도 모두 프로세스를 중심으로 돌아간다.

Seeing Processes in Action Through Task Manager

There's a way to make the concept of the operating system managing execution in process units feel more concrete. That's Windows Task Manager.

When you open Task Manager, you see a list of all the processes currently running on your computer. Every single item in that list is an execution unit - " a process " managed by the operating system. Some were launched directly by you; others are tasks the operating system runs internally, invisible to the user.

Here's something interesting: even if you only have a few windows open on screen, opening Task Manager reveals that dozens of processes are actually running simultaneously. This shows that the range of execution the user perceives and the range the operating system actually manages are entirely different things.

Task Manager is a window that lets you see this reality with your own eyes. Through this screen, you can intuitively understand that the operating system's execution is not a single flow, but is divided into multiple execution units that are managed concurrently.

작업 관리자로 확인하는 프로세스의 실체

운영체제가 프로세스 단위로 실행을 관리한다는 개념을 조금 더 실감 나게 확인할 수 있는 방법이 있다. 바로 윈도우의 작업 관리자다.

작업 관리자를 열면 현재 컴퓨터에서 실행 중인 프로세스들이 목록 형태로 쭉 나열된다. 이 목록의 항목 하나하나가 바로 운영체제가 관리하는 실행 단위, 즉 프로세스다. 내가 직접 실행한 프로그램도 있고, 사용자 눈에는 보이지 않지만 운영체제가 내부적으로 돌리고 있는 작업들도 함께 포함되어 있다.

여기서 흥미로운 점이 있다. 화면에 띄워 놓은 창이 몇 개 없더라도, 작업 관리자를 열어보면 실제로는 수십 개의 프로세스가 동시에 동작하고 있다는 걸 확인할 수 있다. 사용자가 인식하는 실행의 범위와 운영체제가 실제로 관리하는 실행의 범위가 전혀 다르다는 뜻이다.

작업 관리자는 이 사실을 눈으로 직접 확인시켜 주는 창구다. 운영체제의 실행은 단순히 하나의 흐름이 아니라, 여러 개의 실행 단위로 나뉘어 동시에 관리되고 있다는 것을 이 화면을 통해 직관적으로 이해할 수 있다.

The Moment a Program Becomes a Process

To understand the relationship between a program and a process, it helps to trace the flow of execution step by step.

It starts on disk. A program is stored there as a file; an executable made up of code and static data. In this state, nothing is running yet. It's not using the CPU, it's not occupying memory; it's simply a file sitting quietly on disk.

When the user runs the program, the situation changes. The program on disk is loaded into memory, and once it is loaded and in an executable state, we call it a process. That process then receives CPU time, and actual computation begins.

To recap: a program is an executable file stored on disk; a process is the state in which that program has been loaded into memory and is running. Even the same program, when executed multiple times, can produce that many different processes in memory.

The core takeaway from this flow is one thing: the very moment a program is loaded into memory, it transforms into a process - a managed entity under the operating system's control. Before that moment it's merely a stored file, but once it's in memory, the operating system recognizes it as an independent execution unit and begins allocating and managing resources like CPU and memory.

프로그램이 프로세스가 되는 순간

프로그램과 프로세스의 관계를 이해하려면 실행이 일어나는 흐름을 단계별로 따라가 보는 것이 좋다.

시작은 디스크다. 디스크에는 프로그램이 파일의 형태로 저장되어 있다. 이 프로그램은 코드와 정적인 데이터로 이루어진 실행 파일로, 이 상태에서는 아직 아무것도 실행되고 있지 않다. CPU를 사용하는 것도 아니고, 메모리를 점유하는 것도 아닌, 그냥 디스크 위에 가만히 놓인 파일일 뿐이다.

여기서 사용자가 프로그램을 실행하면 상황이 바뀐다. 디스크에 있던 프로그램이 메모리로 올라오게 되고, 메모리에 적재되어 실행 가능한 상태가 된 것을 바로 프로세스라고 부른다. 그리고 이 프로세스가 CPU를 할당받으면서 비로소 실제 연산이 시작된다.

다시 한번 정리하면 이렇다. 프로그램은 디스크에 저장된 실행 파일이고, 프로세스는 그 프로그램이 메모리에 적재되어 실행 중인 상태다. 같은 프로그램이라도 여러 번 실행하면 메모리에는 그만큼 서로 다른 프로세스가 생성될 수 있다.

이 흐름에서 핵심은 딱 하나다. 프로그램이 메모리에 적재되는 바로 그 순간, 운영체제의 관리 대상인 프로세스로 전환된다는 것이다. 그 전까지는 그저 저장된 파일에 불과하지만, 메모리에 올라오는 순간부터 운영체제는 이를 독립적인 실행 단위로 인식하고 CPU와 메모리 같은 자원을 할당하며 관리하기 시작한다.

2. Process Structure and Creation

The Memory Structure of a Process

When we say a process is loaded into memory, it's not simply a matter of one chunk of program code being dumped in. The various roles needed for execution are separated and each occupies its own region in a structured layout. Understanding this structure makes it much clearer how the operating system systematically manages running processes.

2.프로세스의 구성과 생성

프로세스의 메모리 구조

프로세스가 메모리에 올라간다고 했을 때, 단순히 프로그램 코드 하나가 통째로 올라가는 것이 아니다. 실행에 필요한 여러 역할들이 구분되어 각자의 영역을 차지하는 구조로 배치된다. 이 구조를 이해하면 운영체제가 실행 중인 프로세스를 어떻게 체계적으로 관리하는지 훨씬 명확하게 보인다.

Code Region

First is the code region. As the name implies, this is where the program's instructions - the commands the CPU reads and executes one by one - are stored. It's the region that defines the program's behavior itself.

Data Region

Next is the data region. This is where data used throughout the entire program is stored - things like global variables and static variables. Rather than being used only within a specific function, these are data that are referenced broadly throughout the program's execution.

Heap Region

Then there's the heap region. The heap is a memory area that is dynamically allocated while the program runs. For example, creating a new object during execution or requesting additional memory on the fly falls into this category. Its defining characteristic is that its size isn't fixed in advance - it's used flexibly according to the flow of execution.

Stack Region

Finally, there's the stack region. This is where information related to function calls, along with local variables and parameters, is stored. Every time a function is called, the necessary information is pushed onto the stack, and when the function returns, it is popped off — so the amount of space used changes continuously with the flow of execution.

Each Process Has an Independent Memory Space

Through this structure ; code, data, heap, and stack - the operating system manages the memory a process needs during execution in a role-based, systematic way.

There's one point that must be emphasized here: each process holds this memory structure independently. Process A's memory space and Process B's memory space do not directly access or mix with each other. As a result, even if a problem occurs in one process, it does not affect others. This independence is a critical foundation that allows the operating system to manage multiple processes simultaneously and stably.

코드 영역

가장 먼저 코드 영역이다. 이름 그대로 실행할 프로그램의 명령어들이 저장되는 공간이다. CPU는 이 영역에 저장된 명령어를 하나씩 읽어가며 실행한다. 프로그램의 동작 자체를 정의하는 영역이라고 볼 수 있다.

데이터 영역

다음은 데이터 영역이다. 전역 변수나 정적 변수처럼 프로그램 전체에 걸쳐 사용되는 데이터들이 이곳에 저장된다. 특정 함수 안에서만 쓰이는 것이 아니라, 프로그램이 실행되는 동안 전반적으로 참조되는 데이터들의 자리다.

힙 영역

그다음은 힙 영역이다. 힙은 프로그램이 실행되는 도중에 동적으로 할당되는 메모리 공간이다. 예를 들어 실행 중에 새로운 객체를 생성하거나, 필요에 따라 메모리를 추가로 요청하는 경우가 여기에 해당한다. 미리 크기를 정해두는 것이 아니라 실행 흐름에 따라 유동적으로 사용된다는 점이 특징이다.

스택 영역

마지막으로 스택 영역이다. 함수 호출과 관련된 정보, 그리고 지역 변수와 매개변수가 저장되는 공간이다. 함수가 호출될 때마다 필요한 정보가 쌓이고, 함수가 종료되면 다시 걷혀나가는 방식으로 동작하기 때문에 사용량이 실행 흐름에 따라 계속해서 변한다.

각 프로세스는 독립된 메모리 공간을 가진다

코드, 데이터, 힙, 스택으로 나뉜 이 구조를 통해 운영체제는 프로세스가 실행되는 데 필요한 메모리를 역할별로 체계적으로 관리한다.

여기서 반드시 짚고 넘어가야 할 점이 하나 있다. 각 프로세스는 이 메모리 구조를 서로 독립적으로 가진다는 것이다. 프로세스 A의 메모리 공간과 프로세스 B의 메모리 공간은 서로 직접 접근하거나 섞이지 않는다. 덕분에 한 프로세스에서 문제가 생기더라도 다른 프로세스에 영향을 주지 않도록 보호된다. 이 독립성이 운영체제가 여러 프로세스를 안정적으로 동시에 관리할 수 있는 중요한 기반이 된다.

The Memory Layout of a Process

When a process is loaded into memory, the data isn't all jumbled together. The data needed for execution is divided into four regions based on its nature and laid out systematically.

Looking at the structure from the bottom up, the code region sits at the very bottom, followed above it by the data region, then the heap region, with the stack region at the very top.

The code region holds the program instructions that the CPU reads and executes one by one. The data region holds data used broadly throughout the program, such as global and static variables. The heap region is for dynamically allocated memory during execution - for instance, when char *cp = malloc(10000) requests memory mid-run, this region is used. The stack region stores local variables and parameters declared inside functions - things like float f or int i belong here.

One thing worth noting in this structure is that the heap and stack expand toward each other. The heap grows upward as more dynamic allocations occur; the stack grows downward as function calls accumulate. The empty space between them serves as a buffer to accommodate this expansion.

The reason memory is divided into regions like this is simple: to keep data of different natures clearly separated so they don't get mixed together during execution. The operating system allocates and manages memory for each process based on exactly this structure.

프로세스의 메모리 배치 구조

프로세스가 메모리에 올라갈 때, 모든 데이터가 한데 뒤섞여 저장되는 것이 아니다. 실행에 필요한 데이터들은 그 성격에 따라 네 개의 영역으로 나뉘어 체계적으로 배치된다.

구조를 아래에서부터 살펴보면, 가장 아래에 코드 영역이 위치하고 그 위로 데이터 영역, 힙 영역, 그리고 가장 위에 스택 영역이 자리한다.

코드 영역에는 CPU가 하나씩 읽어 실행할 프로그램 명령어들이 저장된다. 데이터 영역에는 전역변수나 정적 변수처럼 프로그램 전반에 걸쳐 사용되는 데이터들이 올라간다. 힙 영역은 실행 중에 동적으로 할당되는 메모리 공간으로, char *cp = malloc(10000)처럼 실행 도중 메모리를 요청하는 경우 이 영역이 사용된다. 스택 영역에는 함수 안에서 선언된 지역변수와 매개변수가 저장되는데, float f나 int i 같은 지역변수가 여기에 해당한다.

이 구조에서 한 가지 눈여겨볼 점은 힙과 스택이 서로를 향해 확장된다는 것이다. 힙은 동적 할당이 늘어날수록 위쪽으로 커지고, 스택은 함수 호출이 쌓일수록 아래쪽으로 확장된다. 두 영역 사이의 빈 공간이 이 확장을 수용하는 여유분 역할을 한다.

이렇게 메모리를 영역별로 구분해서 사용하는 이유는 하나다. 프로세스가 실행되는 동안 성격이 서로 다른 데이터들이 뒤섞이지 않도록 명확히 분리해서 관리하기 위해서다. 운영체제는 바로 이 구조를 기준으로 각 프로세스에 메모리를 할당하고 관리한다.

How Is a Process Created?

A process doesn't spontaneously appear out of nowhere. The entity that creates a new process is always an already-running existing process.

The process that creates a new one is called the parent process; the newly created one is called the child process. A child process, once running, can itself spawn further children. As this relationship repeats, processes form a tree-shaped hierarchical structure.

The operating system performs two roles simultaneously in this process: allocating an independent memory space for the new child process, and completing the preparation work so it can begin executing immediately. From the moment a child process is created, it becomes an independent execution unit with its own memory space.

At this stage, there's no need to dig deep into system calls or specific implementation details. The two core ideas are: processes are created by existing processes, and that relationship forms a parent-child hierarchy. Keeping this concept in mind provides a solid foundation for understanding topics like scheduling and inter-process communication that come later.

프로세스는 어떻게 만들어질까?

프로세스는 갑자기 혼자 생겨나지 않는다. 새로운 프로세스를 만들어내는 주체는 항상 이미 실행 중인 기존의 프로세스다.

이때 새로운 프로세스를 만들어낸 쪽을 부모 프로세스, 그로 인해 새롭게 생성된 쪽을 자식 프로세스라고 부른다. 자식 프로세스 역시 실행되고 나면 또 다른 자식을 낳을 수 있다. 이런 관계가 반복되면서 프로세스들은 나무 모양의 계층 구조를 이루게 된다.

운영체제는 이 과정에서 두 가지 역할을 함께 수행한다. 새로운 자식 프로세스를 위한 독립된 메모리 공간을 할당하고, 곧바로 실행에 들어갈 수 있도록 준비 작업을 마친다. 자식 프로세스는 생성되는 순간부터 자신만의 메모리 공간을 가지는 독립적인 실행 단위가 된다.

지금 단계에서 시스템 호출이나 구체적인 구현 방식까지 깊이 파고들 필요는 없다. 핵심은 두 가지다. 프로세스는 기존 프로세스에 의해 생성된다는 것, 그리고 그 관계는 부모와 자식이라는 계층 구조로 이어진다는 것이다. 이 개념을 머릿속에 잡아두면, 이후에 배울 스케줄링이나 프로세스 간 통신 같은 주제들을 이해하는 데 든든한 발판이 된다.

The Process Tree and the Parent-Child Relationship

Given that parent-child relationships are formed, processes don't exist as scattered, independent entities - they form a hierarchical tree structure. Every process in this tree has some parent process, and ultimately all processes derive from a single root process at the top.

There's an important point here: changes in a parent process's state can affect its child processes. In particular, when a parent process terminates, how its child processes are handled is determined by the operating system's policy.

For reference, in a Linux environment, a process called init serves as the starting point for all processes. No matter which running process you trace upward through its parents, you'll eventually reach init.

Understanding this parent-child relationship makes it easier to naturally connect to topics you'll encounter later, such as process termination and resource cleanup.

프로세스 트리 구조와 부모-자식 관계

부모와 자식 관계가 만들어진다고 했는데, 이 관계를 기준으로 보면 프로세스들은 서로 독립적으로 흩어져 있는 것이 아니라 계층적인 트리 구조를 이룬다. 모든 프로세스는 이 트리 안에서 반드시 어떤 부모 프로세스를 가지고 있으며, 최종적으로는 하나의 최상위 프로세스로부터 파생된다.

여기서 한 가지 중요한 점이 있다. 부모 프로세스의 상태 변화가 자식 프로세스에도 영향을 줄 수 있다는 것이다. 특히 부모 프로세스가 종료되는 경우, 자식 프로세스를 어떻게 처리할지는 운영체제의 정책에 따라 결정된다.

참고로 리눅스 환경에서는 init이라는 프로세스가 모든 프로세스의 시작점 역할을 한다. 실행 중인 어떤 프로세스든 부모를 따라 트리를 거슬러 올라가다 보면 결국 이 init 프로세스와 연결된다.

이렇게 부모와 자식 간의 관계를 이해해두면, 이후에 다루게 될 프로세스 종료나 자원 정리 같은 내용들도 자연스럽게 연결지어 이해할 수 있게 된다.

The Process Tree: A Hierarchy Starting from init

At the top of the process tree in a Linux environment sits init - the process that holds PID 1. This is the very first process to run on the system, and all processes ultimately derive from it.

Below it in the hierarchy sits the Shell process. When a user logs into the system, a shell process is created for that user. The shell receives commands the user types and passes them to the operating system - from the user's perspective, it's the launching point that starts program execution.

Programs like web browsers, chat applications, media players, and text editors are all created as child processes with the shell as their parent. Rather than each user-run program appearing independently out of nowhere, they are created hierarchically through the shell, within a parent-child relationship.

In this way, processes are managed within a tree-structured hierarchy. No matter which process you trace upward, it eventually connects to init. Understanding this entire flow as a single picture makes later topics - process termination, resource cleanup - much easier to connect and comprehend.

프로세스 트리, init에서 시작되는 계층 구조

리눅스 환경에서 프로세스 트리의 최상위에는 init이라는 프로세스가 있다. PID 1번을 가지는 이 프로세스가 시스템에서 가장 먼저 실행되는 출발점으로, 모든 프로세스는 결국 이 init으로부터 파생된다.

그 아래 계층에는 쉘(Shell) 프로세스가 위치한다. 사용자가 시스템에 로그인하면 해당 사용자를 위한 쉘 프로세스가 생성된다. 쉘은 사용자가 입력한 명령어를 받아 운영체제에 전달해주는 역할을 하는데, 사용자 입장에서는 프로그램을 실행할 때 그 실행을 시작해주는 출발점이라고 보면 된다.

웹브라우저, 채팅, 미디어플레이어, 편집기 같은 프로그램들은 모두 이 쉘을 부모로 두는 자식 프로세스로 생성된다. 사용자가 실행하는 프로그램들이 각각 독립적으로 뚝 생겨나는 것이 아니라, 쉘이라는 프로세스를 거쳐 부모-자식 관계 속에서 계층적으로 만들어진다는 뜻이다.

이처럼 프로세스는 트리 구조의 계층 관계 안에서 관리된다. 어떤 프로세스든 부모를 따라 위로 거슬러 올라가다 보면 결국 init과 연결된다. 이 전체 흐름을 하나의 그림으로 이해해두면, 이후에 배울 프로세스 종료나 자원 정리 같은 내용들도 자연스럽게 연결지어 이해할 수 있게 된다.

From Execution Request to Actual Execution

When a user runs a program, several steps proceed in sequence inside the operating system. Let's trace the flow from the moment an icon is clicked or a command is entered to the point where the program actually starts running.

First, when the user's execution request comes in, the operating system creates a new process via a system call. The representative system call function used here is fork(). Through this call, a new child process is born from an existing process.

Once the process is created, the operating system allocates the memory space that process needs to run. The code, data, heap, and stack regions discussed earlier are each secured at this point. After memory allocation, the preparation work of initializing CPU state and execution position follows. Only when this preparation is complete can the process receive CPU time and move into the actual execution phase.

At this stage, there's no need to memorize functions like fork() or the specifics of implementation. What matters is holding the overall flow; execution request → process creation → memory allocation → execution preparation; as a single picture in your mind. Understanding this flow makes subsequent topics like scheduling and process management connect much more naturally.

프로그램 실행 요청부터 실제 실행까지

사용자가 프로그램을 실행하면 운영체제 내부에서는 여러 단계가 순서대로 진행된다. 아이콘을 클릭하거나 명령어를 입력하는 순간부터 실제로 프로그램이 동작하기까지의 흐름을 따라가 보자.

먼저 사용자의 실행 요청이 들어오면 운영체제는 시스템 호출을 통해 새로운 프로세스를 생성한다. 이때 사용되는 대표적인 시스템 호출 함수가 fork()다. 이 호출을 통해 기존 프로세스로부터 새로운 자식 프로세스가 만들어진다.

프로세스가 생성되고 나면 운영체제는 그 프로세스가 실행되는 데 필요한 메모리 공간을 할당한다. 앞서 살펴본 코드, 데이터, 힙, 스택 영역이 이 시점에 각각 확보된다. 메모리 할당이 끝나면 CPU 상태와 실행 위치를 초기화하는 실행 준비 작업이 이어진다. 이 준비가 완료되어야 비로소 프로세스가 CPU를 할당받아 실제 실행 단계로 넘어갈 수 있다.

이 단계에서 fork() 같은 함수나 세부 구현 방식을 외우려 할 필요는 없다. 중요한 것은 프로그램 실행 요청 → 프로세스 생성 → 메모리 할당 → 실행 준비라는 전체 흐름을 하나의 그림으로 머릿속에 담아두는 것이다. 이 흐름을 이해하고 있으면 이후에 배울 스케줄링이나 프로세스 관리 같은 내용들도 훨씬 자연스럽게 연결된다.

3.Condition of Process

The State Changes of a Process

A process doesn't stay in the same state from beginning to end once it's created. It transitions through several states as it runs. Let's trace that flow in order.

The very first is the New state. This is the phase where the process is just being created and is not yet ready to execute.

Once creation is complete, it moves to the Ready state. All preparations for execution are done, but the process hasn't been allocated CPU time yet - it's waiting its turn. It's capable of running, but is waiting because no CPU is available.

When a Ready process is allocated CPU time, it becomes Running. This is the state where instructions are actually being executed. At any given moment, generally only one process can be running on a single CPU. A process can be sent back to Ready if it loses the CPU.

If a situation arises during Running where the process must wait for an external event - like an I/O operation - it transitions to the Waiting state. In this state the process doesn't use the CPU, and once the awaited event completes, it returns to Ready to wait for CPU allocation again.

Finally, when execution is entirely complete, the process reaches the Terminated state. This is where the process's lifecycle ends.

Ultimately, a process operates by continuously changing states within the flow of creation → ready → running → waiting → termination. Understanding this flow of state changes makes it much more natural to later understand how scheduling decides which process to choose at which moment.

프로세스의 상태 변화

프로세스는 한번 생성되면 처음부터 끝까지 같은 상태로 머무는 것이 아니다. 실행되는 동안 여러 상태를 오가며 변화한다. 이 흐름을 순서대로 따라가 보자.

가장 처음은 New 상태다. 프로세스가 막 생성되고 있는 단계로, 아직 실행 준비가 완료되지 않은 상태를 의미한다.

생성이 완료되면 Ready 상태로 넘어간다. 실행에 필요한 준비는 모두 끝났지만 아직 CPU를 할당받지 못해 차례를 기다리는 상태다. 실행 가능한 상태이지만 CPU가 없어서 대기 중인 것이다.

Ready 상태의 프로세스가 CPU를 할당받으면 Running 상태가 된다. 실제로 명령어가 수행되는 상태로, 일반적으로 한 시점에 CPU 하나에서 실행될 수 있는 프로세스는 단 하나뿐이다. 실행 중에 CPU를 빼앗기면 다시 Ready 상태로 돌아가기도 한다.

Running 도중 입출력 작업처럼 외부 사건을 기다려야 하는 상황이 생기면 Waiting 상태로 전환된다. 이 상태에서는 CPU를 사용하지 않으며, 기다리던 사건이 완료되면 다시 Ready 상태로 돌아가 CPU 할당을 기다린다.

마지막으로 실행이 모두 끝나면 Terminated 상태가 된다. 프로세스의 생명 주기가 마무리되는 단계다.

결국 프로세스는 생성 → 준비 → 실행 → 대기 → 종료라는 일련의 흐름 속에서 상태를 끊임없이 바꾸며 동작한다. 이 상태 변화의 흐름을 이해해두면, 이후에 배울 스케줄링이 어떤 시점에 어떤 프로세스를 선택하는지도 훨씬 자연스럽게 이해할 수 있게 된다.

The Flow of Process State Transitions

Let's trace which states a process passes through during execution and what triggers each state change.

프로세스 상태 변화의 흐름

프로세스가 실행되는 동안 어떤 상태를 거치고, 어떤 계기로 상태가 바뀌는지 흐름을 따라가 보자.

Basic Flow

Most simply: after being created, a process waits in a non-running state, then is dispatched and moves to the running state when it receives CPU time. When execution ends, it moves to the terminated state. However, if an interrupt occurs during execution, it can return to the non-running state. This is the most basic skeleton of process state changes.

기본 흐름

가장 단순하게 보면, 프로세스는 생성된 후 비실행 상태에 머물다가 CPU를 할당받는 순간 디스패치되어 실행 상태로 넘어간다. 실행이 끝나면 종료 상태로 이동한다. 단, 실행 중에 인터럽트가 발생하면 다시 비실행 상태로 돌아갈 수 있다. 이것이 프로세스 상태 변화의 가장 기본적인 골격이다.

Detailed State Changes

In practice, when the operating system manages processes, this flow is more granular.

After a process is created, rather than immediately receiving CPU time, it first enters the ready state. The ready state means all preparations for execution are done but the process is still waiting for CPU allocation. The process by which the operating system selects one process from those in the ready state and hands it the CPU is called a dispatch. The dispatch is precisely the transition action that occurs when moving from ready to running.

A process in the running state can be sent back to ready depending on circumstances - for example, when its allocated time runs out, or when a higher-priority process needs the CPU. Meanwhile, if a situation requiring the process to wait for an external event (such as an I/O request) arises during execution, the process moves to the waiting state. It doesn't use the CPU while waiting, and once the awaited event completes, it returns to ready and waits for CPU allocation again.

After repeating this cycle, once execution is fully complete, the process moves to the terminated state.

The two key points here are: processes don't proceed in just one direction - they repeatedly cycle through ready, running, and waiting states depending on circumstances - and at the center of that flow is the dispatch, the transition from ready to running.

구체적인 상태 변화

실제로 운영체제가 프로세스를 관리할 때는 이 흐름이 좀 더 세분화된다.

프로세스가 생성되면 곧바로 CPU를 받는 것이 아니라 먼저 준비 상태로 들어간다. 준비 상태는 실행에 필요한 모든 준비는 끝났지만 CPU를 아직 할당받지 못해 차례를 기다리는 상태다. 여기서 운영체제가 실행할 프로세스를 하나 골라 CPU를 넘겨주는 과정을 디스패치라고 한다. 준비에서 실행으로 넘어가는 바로 그 전환 동작이 디스패치다.

실행 상태에 들어간 프로세스는 상황에 따라 다시 준비 상태로 돌아올 수 있다. 할당된 시간이 끝났거나, 더 우선순위가 높은 프로세스에게 CPU를 넘겨줘야 할 경우가 그 예다. 한편 실행 중에 입출력 요청처럼 외부 사건을 기다려야 하는 상황이 생기면 프로세스는 대기 상태로 이동한다. 대기 상태에서는 CPU를 사용하지 않으며, 기다리던 사건이 완료되면 다시 준비 상태로 돌아와 CPU 할당을 기다린다.

이 과정을 반복하다가 실행이 모두 끝나면 프로세스는 최종적으로 종료 상태로 이동한다.

여기서 핵심은 두 가지다. 프로세스는 한 방향으로만 쭉 진행되는 것이 아니라 상황에 따라 준비, 실행, 대기를 반복해서 오간다는 것, 그리고 그 흐름의 중심에 준비에서 실행으로 전환되는 디스패치라는 과정이 있다는 것이다.

2️⃣ Process State and Management

1. Process State Changes

Why Process State Changes Are Necessary

Although it looks like multiple programs are running simultaneously on a computer, the CPU can only execute one process at a time. Because of this constraint, the operating system must continuously make important decisions: which process to run right now, and when to stop the currently running process and switch to another.

Throughout this process, a process doesn't stay only in the running state - it is managed by moving back and forth between the ready and waiting states. The flow that emerges as the operating system switches and manages processes is called process state change.

This concept goes beyond simply describing what state a process is in. It is a fundamental prerequisite for understanding process management techniques like scheduling and synchronization that we'll explore later, which is why it's important to get a firm grasp of this flow now.

프로세스 상태 변화의 필요성

컴퓨터에서 여러 프로그램이 동시에 실행되는 것처럼 보이지만, CPU는 한 순간에 단 하나의 프로세스만 실행할 수 있다. 이 제약이 있기 때문에 운영체제는 끊임없이 중요한 판단을 내려야 한다. 지금 어떤 프로세스를 실행할 것인지, 언제 실행 중인 프로세스를 멈추고 다른 프로세스로 전환할 것인지를 계속해서 결정해야 하는 것이다.

이 과정에서 프로세스는 실행 상태에만 머무는 것이 아니라 준비와 대기 상태를 오가며 관리된다. 운영체제가 프로세스를 전환하고 관리하는 과정에서 나타나는 이러한 흐름을 프로세스의 상태 변화라고 한다.

이 개념은 단순히 프로세스가 어떤 상태에 있는지를 설명하는 데서 그치지 않는다. 앞으로 살펴볼 스케줄링이나 동기화 같은 프로세스 관리 기법들을 이해하기 위한 기본 전제가 되는 개념이기 때문에, 지금 이 흐름을 확실히 잡아두는 것이 중요하다.

What Would Happen Without Process State Changes?

Without process state changes, the operating system would be unable to properly distinguish between multiple processes. If there's no information about which process should be running right now and which is waiting, there's no way to decide who should receive the CPU.

Ultimately, process state changes don't merely display a process's current situation. They serve as the management standard that allows multiple processes to share the CPU and use system resources efficiently.

From this perspective, process state change can be understood as the most fundamental management mechanism the operating system uses to reclaim and reallocate the CPU. The reason the operating system appears to handle multiple processes simultaneously is precisely because it manages them by rapidly switching the CPU based on these state changes.

프로세스 상태 변화가 없다면 어떻게 될까?

만약 프로세스의 상태 변화가 없다면 운영체제는 여러 프로세스를 제대로 구분할 수 없게 된다. 어떤 프로세스가 지금 실행되어야 하는지, 어떤 프로세스가 대기 중인지에 대한 정보가 없으면 CPU를 누구에게 할당해야 할지 결정할 수 없기 때문이다.

결국 프로세스의 상태 변화는 단순히 프로세스의 현재 상황을 표시하는 것에 그치지 않는다. 여러 프로세스가 CPU를 나눠 쓸 수 있도록 하고, 시스템 자원을 효율적으로 사용하기 위한 관리 기준이 된다.

이 관점에서 보면 프로세스의 상태 변화는 운영체제가 CPU를 회수하고 다시 할당하기 위해 사용하는 가장 기본적인 관리 방식이라고 이해할 수 있다. 운영체제가 여러 프로세스를 동시에 다루는 것처럼 보이는 것도, 결국 이 상태 변화를 기반으로 CPU를 빠르게 전환하며 관리하기 때문에 가능한 일이다.

The Operating System Decides State Changes

Process state changes don't occur arbitrarily at any random time. A state change means the operating system is intervening in the execution flow, and this intervention only happens at specific moments.

In other words, a process does not change its own state. State changes occur only at the moment the operating system determines that intervention is necessary. There's one important point here: state changes take place exclusively in kernel mode. User programs never directly change their own state.

This means the operating system holds complete authority over process management. From the process's perspective, it cannot decide on its own when to run or when to stop — all such decisions are made by the operating system in kernel mode. This structure allows multiple processes to share the CPU in an orderly fashion and prevents any single process from monopolizing or destabilizing the entire system.

상태 변화는 운영체제가 결정한다

프로세스의 상태 변화는 아무 때나 임의로 발생하는 것이 아니다. 상태가 바뀐다는 것은 곧 운영체제가 실행 흐름에 개입하겠다는 의미이며, 이 개입은 항상 특정 시점에서만 일어난다.

다시 말해 프로세스가 스스로 자신의 상태를 바꾸는 것이 아니다. 운영체제가 개입이 필요하다고 판단한 순간에 비로소 상태 변화가 일어난다. 여기서 한 가지 중요한 점이 있다. 이 상태 변화는 반드시 커널 모드에서만 이루어진다는 것이다. 사용자 프로그램이 직접 자신의 상태를 바꾸는 일은 없다.

이 사실은 운영체제가 프로세스 관리의 주도권을 완전히 쥐고 있다는 것을 의미한다. 프로세스 입장에서는 언제 실행되고 언제 멈출지를 스스로 결정할 수 없으며, 그 모든 판단은 운영체제가 커널 모드에서 내린다. 이 구조 덕분에 여러 프로세스가 질서 있게 CPU를 나눠 쓸 수 있고, 한 프로세스가 시스템 전체를 독점하거나 불안정하게 만드는 상황을 막을 수 있다.

When Does the Operating System Intervene?

There are specific triggers that cause the operating system to change a process's state. The most representative cases are as follows.

The first is when a process is allocated CPU time. When a process that was waiting in the ready state receives the CPU, the operating system transitions it to the running state.

The second is when a process has used up its entire allocated CPU time. The operating system limits how long each process can hold the CPU; when that time expires, it stops the running process and switches to another.

The third is when a process requests an I/O operation, or when a previously requested I/O operation completes. When an I/O request comes in, the process is transitioned to the waiting state; when the operation completes, it returns to the ready state. The operating system intervenes directly to change the state at both of these moments.

Ultimately, based on these three triggers, a process cycles repeatedly through the running, ready, and waiting states. Through this flow, the operating system coordinates multiple processes so they can share the CPU in an orderly manner.

운영체제는 어떤 순간에 개입할까?

운영체제가 프로세스의 상태를 변경하는 데는 특정한 계기가 있다. 대표적인 경우를 살펴보면 다음과 같다.

첫 번째는 프로세스가 CPU를 할당받는 순간이다. 준비 상태에서 기다리던 프로세스가 CPU를 받게 되면 운영체제는 해당 프로세스를 실행 상태로 전환한다.

두 번째는 프로세스가 할당된 CPU 사용 시간을 모두 소진했을 때다. 운영체제는 각 프로세스가 CPU를 무한정 점유하지 못하도록 사용 시간을 제한하는데, 그 시간이 끝나면 실행 중인 프로세스를 멈추고 다른 프로세스로 전환한다.

세 번째는 프로세스가 입출력 작업을 요청하거나, 요청했던 입출력 작업이 완료되었을 때다. 입출력 요청이 들어오면 해당 프로세스는 대기 상태로 전환되고, 작업이 완료되면 다시 준비 상태로 돌아온다. 이 두 시점 모두 운영체제가 직접 개입해 상태를 변경한다.

결국 이 세 가지 시점을 기준으로 프로세스는 실행, 준비, 대기 상태를 반복해서 오가게 된다. 운영체제는 이 흐름을 통해 여러 프로세스가 CPU를 질서 있게 나눠 쓸 수 있도록 조율하는 것이다.

Terms for State Transitions

We've already looked at the flow of process state changes. Now let's define the terms used to describe each specific moment of transition. Dispatch and timeout are expressions that refer to the concrete moments when the operating system intervenes and a process's state changes.

Dispatch refers to the moment the operating system selects one process from those in the ready state and transitions it to the running state. Simply put, it's the exact moment the operating system decides "I'm going to run this process now." Dispatch is the transition point from ready to running.

Timeout is the transition in the opposite direction. When a running process has exhausted its allocated CPU time, the operating system sends that process back to the ready state. The transition that occurs at this moment is called a timeout — that is, time expiration.

Looking at the two terms together makes the flow clear. Dispatch takes a process from ready to running; timeout brings it back from running to ready. The operating system coordinates multiple processes taking turns with the CPU by repeating these two transitions.

상태 전환을 표현하는 용어

프로세스의 상태가 바뀌는 흐름은 앞서 살펴봤다. 여기서는 그 상태가 바뀌는 각각의 순간을 부르는 용어를 정리해보자. 디스패치와 타임아웃은 운영체제가 개입해서 프로세스의 상태가 전환되는 구체적인 순간을 가리키는 표현이다.

디스패치는 운영체제가 준비 상태에 있는 프로세스 중 하나를 골라 실행 상태로 전환하는 순간을 가리킨다. 쉽게 말해 운영체제가 "이 프로세스를 이제 실행하겠다"고 결정하는 바로 그 순간이다. 준비 상태에서 실행 상태로 넘어가는 전환점이 디스패치다.

타임아웃은 그 반대 방향의 전환이다. 실행 중인 프로세스가 할당된 CPU 사용 시간을 모두 소진하면, 운영체제는 해당 프로세스를 다시 준비 상태로 돌려보낸다. 이때 발생하는 전환을 타임아웃, 즉 시간 종료라고 한다.

두 용어를 함께 놓고 보면 흐름이 명확해진다. 디스패치는 준비에서 실행으로, 타임아웃은 실행에서 준비로 돌아오는 전환이다. 운영체제는 이 두 가지 전환을 반복하면서 여러 프로세스가 CPU를 번갈아 사용할 수 있도록 조율한다.

Block and Wakeup

While dispatch and timeout were terms for transitions between the ready and running states, let's now look at the transition terms related to the waiting state.

Block refers to the moment a running process transitions to the waiting state — when it requests an I/O operation or must wait for a specific event. The process has reached a point where it can no longer proceed on its own, and the operating system places it in the waiting state. While in this waiting state, the process does not use the CPU.

Wakeup is the opposite. When the awaited I/O operation completes or the specific event is resolved, the operating system wakes up the waiting process and moves it to the ready state. One important note: a wakeup does not immediately put the process into the running state. It returns to the ready state and goes through the normal process of waiting for CPU allocation.

With all four transition terms together, the entire flow of process state changes becomes clear at a glance. Execution begins with a dispatch, returns to ready via a timeout, enters waiting via a block, and comes back to ready via a wakeup. The operating system continuously coordinates the execution of multiple processes through these four transitions.

Block과 Wakeup

앞서 디스패치와 타임아웃이 준비와 실행 사이의 전환을 표현하는 용어였다면, 이번에는 대기 상태와 관련된 전환 용어를 살펴보자.

Block은 실행 중인 프로세스가 입출력 작업을 요청하거나 특정 사건을 기다려야 하는 경우, 실행 상태에서 대기 상태로 전환되는 순간을 가리킨다. 프로세스가 스스로 더 이상 진행할 수 없는 상황이 되어 운영체제에 의해 대기 상태로 보내지는 것이다. 이 대기 상태에 머무는 동안에는 CPU를 사용하지 않는다.

Wakeup은 그 반대다. 기다리던 입출력 작업이 완료되거나 특정 사건이 해결되면, 운영체제는 대기 중이던 프로세스를 다시 깨워 준비 상태로 이동시킨다. 이 전환을 Wakeup이라고 한다. 주의할 점은 Wakeup이 된다고 해서 곧바로 실행 상태로 가는 것이 아니라는 점이다. 다시 준비 상태로 돌아와 CPU 할당을 기다리는 순서를 밟게 된다.

이제 네 가지 전환 용어를 함께 놓고 보면 프로세스 상태 변화의 전체 흐름이 한눈에 정리된다. 디스패치로 실행이 시작되고, 타임아웃으로 준비 상태로 돌아오며, Block으로 대기에 들어가고, Wakeup으로 다시 준비 상태로 복귀한다. 운영체제는 이 네 가지 전환을 통해 여러 프로세스의 실행을 끊임없이 조율한다.

2. Process Control Block (PCB)

We've seen which states a process passes through and what triggers each state change. Thinking carefully about this process, a natural question arises.

For the operating system to manage processes, it needs various information about each one. It needs to know what state a process is currently in — whether it's Ready, Running, or Waiting. It also needs to know where to resume execution when a process that was interrupted starts running again, as well as information about how that process had been using the CPU.

So where exactly is all this information stored? Let's find the answer in what follows.

2. 프로세스 제어 블록(PCB)

지금까지 프로세스가 어떤 상태를 거치고, 어떤 계기로 상태가 바뀌는지 살펴봤다. 그런데 이 과정을 곰곰이 생각해보면 자연스럽게 한 가지 의문이 생긴다.

운영체제가 프로세스를 관리하려면 각 프로세스에 대한 여러 정보가 필요하다. 지금 이 프로세스가 어떤 상태에 있는지, 즉 Ready인지 Running인지 Waiting인지를 알아야 한다. 실행이 중단되었다가 다시 재개될 때 어디서부터 이어서 실행해야 하는지도 알아야 한다. 그 프로세스가 CPU를 어떻게 사용하고 있었는지와 같은 정보도 필요하다.

그렇다면 이런 정보들은 과연 어디에 저장되는 걸까? 다음 내용에서 이 질문의 답을 찾아보자.

What Is a PCB?

The answer to the question posed earlier; where is information about processes stored?; is the Process Control Block (PCB).

The operating system uses a data structure called a PCB to manage each process's state and execution information separately. Each time a process is created, a corresponding PCB is created for it, and this PCB is stored in the kernel area.

One important point to note here: a PCB is a management data structure that contains only the information needed to manage a process's execution. The actual execution content — the process's code, data, and stack — is not included in the PCB. That content exists separately in the process's memory space: the code region, data region, heap, and stack, as we saw earlier.

As an analogy, a PCB is like a management card recording information about a process. Rather than containing actual execution content, it's a structure that gathers only the information the operating system needs to manage and control that process.

PCB란 무엇인가?

앞서 던진 질문, 프로세스에 관한 정보는 어디에 저장되는가에 대한 답이 바로 프로세스 제어 블록(PCB, Process Control Block) 이다.

운영체제는 프로세스의 상태와 실행 정보를 프로세스마다 따로 관리하기 위해 PCB라는 자료구조를 사용한다. 프로세스가 하나 생성될 때마다 그에 대응하는 PCB가 하나씩 만들어지며, 이 PCB는 커널 영역에 저장된다.

여기서 한 가지 중요한 점을 짚고 넘어가야 한다. PCB는 프로세스의 실행을 관리하기 위한 정보만 담고 있는 관리용 자료구조라는 것이다. 프로세스의 코드, 데이터, 스택처럼 실행 내용 자체는 PCB에 포함되지 않는다. 그 내용들은 앞서 살펴본 것처럼 프로세스의 메모리 공간인 코드 영역, 데이터 영역, 힙, 스택에 따로 존재한다.

쉽게 비유하자면 PCB는 프로세스에 대한 정보를 기록해둔 관리 카드 같은 것이다. 실제 실행 내용이 담긴 것이 아니라, 운영체제가 그 프로세스를 관리하고 제어하기 위해 필요한 정보들만 모아둔 구조체다.

The Relationship Between a Process and Its PCB

Each time a process is created, a corresponding PCB is created in the kernel area. When Process A is created, PCB A is created; when Process B is created, PCB B is created. There are as many PCBs in the kernel area as there are running processes.

The key point here is that the operating system doesn't handle processes directly — it manages each process's state and execution information through its PCB. From the operating system's perspective, the PCB is what represents a process. All judgments about which process to run next, what state it's currently in, and how it had been using the CPU are made based on the information contained in the PCB.

Simply put, a process is the actual entity running in memory, while the PCB is the information portal the operating system consults to manage that process. The operating system looks at the PCB before the process itself to understand and control it.

프로세스와 PCB의 관계

프로세스가 생성될 때마다 그에 대응하는 PCB가 커널 영역에 하나씩 만들어진다. 프로세스 A가 생성되면 PCB A가, 프로세스 B가 생성되면 PCB B가 만들어지는 식이다. 실행 중인 프로세스의 수만큼 PCB가 커널 영역에 존재하게 된다.

여기서 중요한 점은 운영체제가 프로세스를 직접 다루는 것이 아니라 PCB를 통해 프로세스의 상태와 실행 정보를 관리한다는 것이다. 운영체제 입장에서는 PCB가 곧 프로세스를 대표하는 존재다. 어떤 프로세스를 다음에 실행할지, 지금 어떤 상태에 있는지, CPU를 어떻게 사용하고 있었는지와 같은 판단을 모두 PCB에 담긴 정보를 기준으로 내린다.

쉽게 말해 프로세스는 메모리에서 실제로 실행되는 실체이고, PCB는 운영체제가 그 프로세스를 관리하기 위해 참조하는 정보 창구라고 볼 수 있다. 운영체제는 프로세스 자체보다 PCB를 먼저 들여다보며 프로세스를 파악하고 제어한다.

Information Stored in a PCB

A PCB contains various pieces of information the operating system needs to manage a process. Let's look at the main items.

First is the process identifier. A unique number identifying each process — the PID (Process ID) — is stored here. The operating system uses this identifier to distinguish and manage multiple processes.

Next is the process state. The PCB records which state the process is currently in: created, ready, running, waiting, or terminated. The operating system uses this information to determine which process to run and which is waiting.

One of the most important items is the Program Counter. When a process is interrupted during execution, the system needs to know where to resume when it runs again. The program counter stores the address of the next instruction to be executed. Because this value is stored, when a process resumes after being interrupted, it doesn't restart from the beginning — it continues precisely from where it left off.

PCB에 저장되는 정보

PCB에는 운영체제가 프로세스를 관리하는 데 필요한 여러 정보들이 담겨 있다. 대표적인 항목들을 살펴보자.

먼저 프로세스 식별자다. 각 프로세스를 구분하기 위한 고유한 숫자, 즉 PID(Process ID)가 저장된다. 운영체제는 이 식별자를 기준으로 여러 프로세스를 서로 구별하고 관리한다.

다음은 프로세스 상태다. 현재 이 프로세스가 생성, 준비, 실행, 대기, 종료 중 어떤 상태에 있는지가 PCB에 기록된다. 운영체제는 이 정보를 보고 어떤 프로세스를 실행할지, 어떤 프로세스가 대기 중인지를 판단한다.

그리고 가장 중요한 항목 중 하나가 프로그램 카운터(Program Counter) 다. 프로세스가 실행되다가 중단되면, 다음에 다시 실행될 때 어디서부터 이어서 실행해야 하는지를 알아야 한다. 프로그램 카운터는 바로 그 다음에 실행해야 할 명령어의 주소를 저장해두는 값이다. 이 값이 있기 때문에 프로세스가 중단되었다가 재개될 때 처음부터 다시 시작하는 것이 아니라 멈췄던 지점에서 정확히 이어서 실행할 수 있다.

Information Stored in a PCB (Continued)

Beyond the identifier, state, and program counter, a few more important pieces of information are stored in the PCB.

Register values. While a process is running, the CPU's registers hold various values needed for the current computation. When an interrupt occurs or a timeout stops the process, the register values at that moment are saved in the PCB. When the process runs again later, those saved register values are restored exactly, allowing it to return to precisely the state it was in before it was interrupted. Because both the program counter and register values are saved together, a process can resume as if it had never been interrupted.

Scheduling-related information is also included in the PCB. This includes the process's priority, its position in the scheduling queue, and other parameters needed for scheduling decisions. The operating system uses this information to determine which process to run next.

Ultimately, the PCB serves as the repository for all information needed to fully restore a process to its previous state when it resumes after being interrupted; losing nothing in the process.

PCB에 저장되는 정보 (계속)

앞서 살펴본 식별자, 상태, 프로그램 카운터 외에도 PCB에는 몇 가지 중요한 정보가 더 저장된다.

레지스터 값이다. 프로세스가 실행되는 동안 CPU의 레지스터에는 현재 연산에 필요한 여러 값들이 담겨 있다. 그런데 인터럽트가 발생하거나 타임아웃으로 프로세스가 중단되면, 그 순간 레지스터에 있던 값들을 PCB에 저장해둔다. 이후 해당 프로세스가 다시 실행될 때 PCB에 저장해둔 레지스터 값을 그대로 복원함으로써, 중단되기 직전의 상태로 정확히 되돌아갈 수 있다. 프로그램 카운터와 레지스터 값이 함께 저장되기 때문에 프로세스는 마치 중단된 적이 없었던 것처럼 이어서 실행될 수 있는 것이다.

스케줄링 관련 정보도 PCB에 포함된다. 이 프로세스의 우선순위가 얼마인지, 스케줄링 큐에서 어느 위치에 있는지, 그 밖에 스케줄링 결정에 필요한 매개변수들이 여기에 저장된다. 운영체제는 이 정보를 바탕으로 다음에 어떤 프로세스를 실행할지 판단한다.

결국 PCB는 프로세스가 중단되었다가 재개될 때 아무것도 잃지 않고 이전 상태로 완전히 복구될 수 있도록 필요한 모든 정보를 보관하는 역할을 한다.

Information Stored in a PCB (Wrap-up)

Beyond the information already covered, a few more items are included in the PCB.

Accounting information. Records of how much CPU time the process has used, its actual usage time, the maximum allowed time, and similar resource usage details are recorded here. Identifying information such as account number and job number is also included.

I/O status information is also stored. What I/O operations the process has currently requested, and what files are currently open ; this information is recorded in the PCB.

Finally, memory management information. Which areas of memory the process is using, and information related to memory allocation, are included in the PCB.

Looking at all the information contained in a PCB together, it becomes clear that the PCB does far more than simply track a process's execution state. Through the PCB, the operating system grasps and manages not just the process's execution flow, but its resource usage as well. In the end, a single PCB concentrates all management information about a given process.

PCB에 저장되는 정보 (마무리)

PCB에는 앞서 살펴본 정보들 외에도 몇 가지가 더 포함된다.

계정 정보다. 해당 프로세스가 CPU를 얼마나 사용했는지, 실제 사용 시간은 얼마인지, 사용 가능한 상한 시간은 얼마인지와 같은 자원 사용 내역이 기록된다. 계정 번호나 작업 번호 같은 식별 정보도 함께 포함된다.

입출력 상태 정보도 저장된다. 현재 이 프로세스가 어떤 입출력 작업을 요청했는지, 현재 열려 있는 파일은 무엇인지와 같은 정보가 PCB에 기록된다.

마지막으로 메모리 관리 정보다. 이 프로세스가 메모리의 어느 영역을 사용하고 있는지, 메모리 할당과 관련된 정보들이 PCB에 포함된다.

이렇게 PCB에 담긴 정보들을 종합해서 보면, PCB가 단순히 프로세스의 실행 상태만 관리하는 것이 아님을 알 수 있다. 운영체제는 PCB를 통해 프로세스의 실행 흐름은 물론, 자원 사용 현황까지 함께 파악하고 관리한다. 결국 PCB 하나에 해당 프로세스에 관한 모든 관리 정보가 집약되어 있는 셈이다.

The Key Role of the PCB in Context Switching

Among the various pieces of information stored in the PCB, the ones most critically used when a context switch occurs are register values and the program counter.

The moment a running process is interrupted, the operating system saves the register values and program counter at that point into the process's PCB. When another process runs and then switches back to this process, the operating system restores exactly the values that were saved in the PCB. As a result, the process can resume precisely from where it was interrupted, as if nothing had happened.

Because these two pieces of information are safely stored in the PCB, the operating system can rapidly switch among dozens of processes while fully maintaining each process's execution flow.

So what order are the PCB-stored values actually saved and restored in when a process switch occurs? Let's look at that step-by-step in the next section.

문맥 교환과 PCB의 핵심 역할

PCB에 저장되는 여러 정보 중에서 문맥 교환이 발생할 때 가장 핵심적으로 활용되는 것은 레지스터 값과 프로그램 카운터다.

프로세스가 실행되다가 중단되는 순간, 운영체제는 그 시점의 레지스터 값과 프로그램 카운터를 해당 프로세스의 PCB에 저장해둔다. 이후 다른 프로세스가 실행되다가 다시 이 프로세스로 전환되면, 운영체제는 PCB에 저장해뒀던 값들을 그대로 복원한다. 덕분에 프로세스는 마치 아무 일도 없었던 것처럼 중단된 지점부터 정확히 이어서 실행될 수 있다.

이 두 가지 정보가 PCB에 안전하게 보관되어 있기 때문에, 운영체제는 수십 개의 프로세스를 빠르게 전환하면서도 각 프로세스의 실행 흐름을 온전히 유지할 수 있는 것이다.

그렇다면 실제로 프로세스가 전환될 때 PCB에 저장된 정보들이 구체적으로 어떤 순서로 저장되고 복원되는지, 다음 내용에서 그 과정을 단계별로 살펴보자.

3. Context Switching

What Is a Context Switch?

In an environment where multiple processes run on a single CPU, there inevitably comes a moment when the currently running process must be stopped and the CPU handed to another process - for example, when a time slice expires due to timeout, or when a process must transition to the waiting state due to an I/O request.

At this moment, the operating system must handle two things simultaneously: safely interrupting the current process's execution flow, and preparing the next process to resume precisely from where it previously left off.

The operation that handles both of these at once is the context switch. A context switch is not simply a matter of handing the CPU to another process — it refers to the entire sequence of saving the current process's execution state to its PCB and restoring the previous state from the next process's PCB. This process is what allows multiple processes to take turns using a single CPU while each maintains its own execution flow.

문맥 교환이란?

하나의 CPU에서 여러 프로세스가 실행되는 환경에서는 현재 실행 중인 프로세스를 멈추고 다른 프로세스에게 CPU를 넘겨야 하는 순간이 반드시 생긴다. 타임아웃으로 사용 시간이 끝났거나, 입출력 요청으로 대기 상태로 전환되어야 하는 경우가 대표적인 예다.

이 순간 운영체제는 두 가지를 동시에 처리해야 한다. 현재 실행 중인 프로세스의 실행 흐름을 안전하게 중단시키는 것, 그리고 다음에 실행할 프로세스가 이전에 멈췄던 지점부터 정확히 이어서 실행될 수 있도록 준비하는 것이다.

이 두 가지를 한꺼번에 처리하는 동작이 바로 문맥 교환(Context Switch) 이다. 문맥 교환은 단순히 CPU를 다른 프로세스에게 넘기는 것이 아니라, 현재 프로세스의 실행 상태를 PCB에 저장하고 다음 프로세스의 PCB에서 이전 상태를 복원하는 일련의 과정 전체를 가리킨다. 이 과정이 있기 때문에 여러 프로세스가 하나의 CPU를 번갈아 사용하면서도 각자의 실행 흐름을 유지할 수 있는 것이다.

When Does a Context Switch Occur?

A context switch doesn't happen arbitrarily at any time. It only occurs at the moment the operating system determines it needs to change which process the CPU is executing.

There are three representative triggers. When an interrupt occurs in the running process; when the allocated time slice expires; and when an I/O request makes it impossible for the current process to continue executing. At these moments, the operating system decides whether to switch the CPU's execution target.

There's an important point here: an interrupt doesn't necessarily cause a context switch. Even if an interrupt occurs, if the operating system determines that the current process can continue running, no context switch takes place.

In other words, a context switch is not the interrupt itself - it is the result of the decision the operating system makes after the interrupt. An interrupt is merely a signal giving the operating system an opportunity to intervene; whether an actual context switch happens is a decision the operating system makes based on the circumstances.

문맥 교환은 언제 발생할까?

문맥 교환은 임의로 아무 때나 발생하는 것이 아니다. 운영체제가 CPU의 실행 대상을 바꿔야 한다고 판단한 순간에만 일어난다.

대표적인 계기는 세 가지다. 실행 중인 프로세스에 인터럽트가 발생했을 때, 할당된 타임 슬라이스가 종료되었을 때, 그리고 입출력 요청으로 인해 현재 프로세스가 더 이상 실행을 이어갈 수 없는 상황이 됐을 때다. 이런 시점에 운영체제는 CPU 실행 대상을 전환할지 여부를 결정한다.

여기서 한 가지 중요한 점이 있다. 인터럽트가 발생했다고 해서 반드시 문맥 교환이 일어나는 것은 아니라는 것이다. 인터럽트가 발생하더라도 운영체제가 현재 프로세스를 계속 실행해도 된다고 판단하면 문맥 교환은 일어나지 않는다.

즉 문맥 교환은 인터럽트 그 자체가 아니라, 인터럽트 이후 운영체제가 내린 판단의 결과다. 인터럽트는 운영체제에게 개입할 기회를 주는 신호일 뿐이고, 실제로 문맥 교환을 할지 말지는 운영체제가 상황을 보고 결정하는 것이다.

The Actual Sequence of a Context Switch

When a context switch occurs, the operating system proceeds in the following order.

First, it saves the execution position and CPU state of the currently running process. The program counter and register values discussed earlier are recorded in that process's PCB. This save must be completed so that when the process runs again later, it can resume exactly from where it stopped.

Once saving is complete, it retrieves and restores the execution position and CPU state stored in the next process's PCB. Through this restoration, the CPU reaches a state where it can pick up where the new process previously left off.

These two steps - saving the previous process's state to its PCB and restoring the next process's state from its PCB to switch the CPU's execution target - constitute the entire operation called a context switch.

Ultimately, context switching is only possible because of the PCB. Because each process's execution state is safely preserved in the PCB, the operating system can rapidly switch among dozens of processes while fully maintaining each process's execution flow.

문맥 교환이 발생하면 운영체제는 다음과 같은 순서로 동작한다.

먼저 현재 실행 중이던 프로세스의 실행 위치와 CPU 상태를 저장한다. 앞서 살펴본 프로그램 카운터와 레지스터 값들이 해당 프로세스의 PCB에 기록되는 것이다. 이 저장이 완료되어야 나중에 이 프로세스가 다시 실행될 때 중단된 지점부터 정확히 이어갈 수 있다.

저장이 끝나면 다음에 실행할 프로세스의 PCB에 저장되어 있던 실행 위치와 CPU 상태를 꺼내어 복원한다. 이 복원 과정을 통해 CPU는 새로운 프로세스가 이전에 멈췄던 지점부터 실행을 이어받을 수 있는 상태가 된다.

이 두 단계, 즉 이전 프로세스의 상태를 PCB에 저장하고 다음 프로세스의 상태를 PCB에서 복원하여 CPU의 실행 대상을 전환하는 전체 과정을 문맥 교환이라고 한다.

결국 문맥 교환은 PCB가 있기 때문에 가능한 동작이다. 각 프로세스의 실행 상태가 PCB에 안전하게 보관되어 있기 때문에, 운영체제는 수십 개의 프로세스를 빠르게 전환하면서도 각 프로세스의 실행 흐름을 온전히 유지할 수 있다.

The Step-by-Step Sequence of a Context Switch

Let's trace the specific sequence of a context switch through the transition between P1 and P2.

While P1 is running, its time slice expires and the operating system intervenes. The operating system first saves P1's current state ; its program counter and register values ; into PCB1. This is the moment P1's execution flow is safely preserved.

Once saving is complete, the operating system retrieves P2's PCB2 and restores the previously saved execution state. Through this restoration, the CPU reaches a state where it can resume P2 from where it previously stopped. The control of the CPU passes from P1 to P2, and P2 begins executing.

The same pattern repeats every time the process switches. The current process's state is saved to its PCB, and the next process's state is restored from its PCB.

The key here is that a context switch does not swap the processes themselves. The essence of a context switch is the repeated cycle of saving and restoring via the PCB. The processes remain in memory as they are; the operating system transfers execution states through the PCBs to switch which process the CPU is running.

문맥 교환의 실제 진행 순서

문맥 교환이 구체적으로 어떤 순서로 진행되는지 P1과 P2의 전환 과정을 통해 살펴보자.

P1이 실행 중이다가 타임 슬라이스가 종료되면 운영체제가 개입한다. 운영체제는 가장 먼저 현재 실행 중이던 P1의 상태, 즉 프로그램 카운터와 레지스터 값을 PCB1에 저장한다. P1의 실행 흐름이 안전하게 보관되는 순간이다.

저장이 완료되면 운영체제는 다음에 실행할 P2의 PCB2를 가져와 이전에 저장해뒀던 실행 상태를 복원한다. 이 복원 과정을 통해 CPU는 P2가 이전에 멈췄던 지점부터 이어서 실행할 수 있는 상태가 된다. 이렇게 CPU의 제어권이 P1에서 P2로 넘어가고 P2가 실행을 시작한다.

이후에도 프로세스가 바뀔 때마다 동일한 방식이 반복된다. 현재 프로세스의 상태는 PCB에 저장되고, 다음 프로세스의 상태는 PCB에서 복원된다.

여기서 핵심은 문맥 교환이 프로세스 자체를 바꾸는 것이 아니라는 점이다. PCB를 기준으로 저장과 복원을 반복하는 과정이 문맥 교환의 본질이다. 프로세스들은 메모리에 그대로 있고, 운영체제가 PCB를 통해 실행 상태를 주고받으며 CPU의 실행 대상을 전환하는 것이다.

Summarizing the Relationship Between PCBs and Context Switching

Let's pull together everything we've covered.

All of a process's state information is stored in the PCB. When a context switch occurs, the current process's state is saved to its PCB, and the next process's previous state is restored from its PCB — that is how process switching is carried out.

From this perspective, the PCB's role becomes clear. The PCB is not simply a place to record process information - it is the management standard that maintains the information needed to resume an interrupted process's execution. Without the PCB, there would be no way to know where a process stopped or what state it was in, making context switching impossible altogether.

In conclusion, a context switch can be summarized as the process of switching the execution target based on the PCB. Each time a process switches, saving and restoring via the PCB repeats, and through this process the operating system manages multiple processes sharing a single CPU without interruption.

PCB와 문맥 교환의 관계 정리

지금까지 살펴본 내용을 한 번 정리해보자.

프로세스의 상태 정보는 모두 PCB에 저장된다. 문맥 교환이 발생하면 현재 프로세스의 상태를 PCB에 저장하고, 다음 프로세스의 PCB에서 이전 상태를 복원하는 방식으로 프로세스 전환이 이루어진다.

이 관점에서 보면 PCB의 역할이 명확해진다. PCB는 단순히 프로세스 정보를 기록해두는 공간이 아니라, 중단된 프로세스의 실행을 다시 이어서 수행할 수 있도록 필요한 정보를 유지해주는 관리 기준이다. PCB가 없다면 프로세스가 어디서 멈췄는지, 어떤 상태였는지를 알 수 없기 때문에 문맥 교환 자체가 불가능하다.

결론적으로 문맥 교환은 PCB를 기준으로 실행 대상을 바꾸는 과정이라고 정리할 수 있다. 프로세스가 전환될 때마다 PCB에 저장과 복원이 반복되고, 운영체제는 이 과정을 통해 여러 프로세스가 하나의 CPU를 끊김 없이 나눠 쓸 수 있도록 관리한다.

The Overhead of Context Switching

Context switching is a necessary process that allows multiple processes to share the CPU. But it comes with a cost: while a context switch is taking place, the CPU cannot perform any actual work and comes to a momentary halt.

During this time, all the CPU does is save the previous process's state to the PCB and load the next process's state from the PCB. No actual computation takes place. This — consuming CPU time without performing real work — is what we call overhead.

The more frequently context switches occur, the more this overhead accumulates, ultimately affecting overall system performance. The more often processes switch, the less time the CPU has available for actual work.

Therefore, the operating system should not trigger context switches unconditionally — it must manage them so they occur only when necessary and as infrequently as possible. The number of context switches is directly linked to system performance. The specifics of how the operating system selects which process to run and how it moderates the number of switches will be explored in depth in the CPU scheduling chapter.

문맥 교환의 오버헤드

문맥 교환은 여러 프로세스가 CPU를 나눠 쓰기 위해 반드시 필요한 과정이다. 하지만 여기에는 한 가지 비용이 따른다. 문맥 교환이 일어나는 동안 CPU는 실제 작업을 수행하지 못하고 멈추게 된다는 것이다.

이 시간 동안 CPU가 하는 일은 이전 프로세스의 상태를 PCB에 저장하고, 다음 프로세스의 상태를 PCB에서 불러오는 것뿐이다. 실제 연산은 전혀 이루어지지 않는다. 이처럼 실제 작업은 하지 않으면서 CPU 시간이 소모되는 부분을 오버헤드라고 한다.

문맥 교환이 자주 발생할수록 이 오버헤드는 누적되고, 결과적으로 전체 시스템 성능에 영향을 미치게 된다. 프로세스 전환이 잦을수록 CPU가 실제 작업에 쓸 수 있는 시간이 그만큼 줄어드는 셈이다.

따라서 운영체제는 문맥 교환을 무조건 발생시키는 것이 아니라, 필요한 경우에만 최소한으로 일어날 수 있도록 관리해야 한다. 문맥 교환 횟수는 시스템 성능과 직접적으로 연결되어 있기 때문이다. 이와 관련된 구체적인 내용, 즉 운영체제가 어떤 기준으로 CPU 실행 대상을 선택하고 전환 횟수를 조율하는지는 CPU 스케줄링 챕터에서 본격적으로 다루게 된다.

The Relationship Between Time Slice Size and Context Switching

Let's examine how frequently context switches occur depending on time slice size, and how that affects system performance, through three cases.

Case A is when the time slice is large. A single process occupies the CPU for a long time, and context switches occur relatively infrequently. Because more time is spent on actual work, overhead is low. However, if one process monopolizes the CPU for too long, other processes may have to wait a long time.

Case B is when the time slice is appropriately sized. Process execution time and context switching are balanced. Multiple processes share the CPU evenly while overhead doesn't become excessive — an ideal state.

Case C is when the time slice is excessively small. Context switches occur repeatedly almost the instant a process starts running. The time spent saving and restoring state exceeds the time the CPU spends on actual work. Overhead accumulates significantly and overall system performance degrades.

In the end, if the time slice is too small, context switches occur excessively and overhead grows; if it's too large, a particular process ends up monopolizing the CPU. The number of context switches is directly linked to system performance, and finding the right balance is a central challenge in CPU scheduling.

타임 슬라이스 크기와 문맥 교환의 관계

타임 슬라이스의 크기에 따라 문맥 교환이 얼마나 자주 발생하는지, 그리고 그것이 시스템 성능에 어떤 영향을 주는지 세 가지 경우를 통해 살펴보자.

A는 타임 슬라이스가 큰 경우다. 하나의 프로세스가 오랜 시간 CPU를 점유하고, 문맥 교환은 상대적으로 드물게 발생한다. 실제 작업에 쓰이는 시간이 길기 때문에 오버헤드는 낮다. 다만 한 프로세스가 CPU를 너무 오래 독점하면 다른 프로세스가 오래 기다려야 하는 문제가 생길 수 있다.

B는 타임 슬라이스가 적당한 경우다. 프로세스 실행 시간과 문맥 교환이 균형을 이루고 있다. 여러 프로세스가 고르게 CPU를 나눠 쓰면서도 오버헤드가 과도하지 않은 이상적인 상태다.

C는 타임 슬라이스가 지나치게 작은 경우다. 프로세스가 실행을 시작하자마자 문맥 교환이 반복적으로 발생한다. CPU가 실제 작업을 수행하는 시간보다 상태를 저장하고 복원하는 데 쓰는 시간이 더 많아지는 상황이다. 오버헤드가 크게 누적되어 시스템 전체 성능이 떨어진다.

결국 타임 슬라이스가 너무 작으면 문맥 교환이 과도하게 발생해 오버헤드가 커지고, 너무 크면 특정 프로세스가 CPU를 독점하는 문제가 생긴다. 문맥 교환 횟수는 시스템 성능과 직접적으로 연결되어 있으며, 이 균형을 어떻게 맞출 것인가가 CPU 스케줄링의 핵심 과제가 된다.

The Next Challenges in Process Management

We've confirmed that context switching allows the operating system to switch between processes. But in an environment where multiple processes exist simultaneously, simply being able to switch is not enough.

When there are multiple processes, new problems naturally arise. When several processes are waiting, which one should run first? When multiple processes try to use the same resource at the same time, how should that be coordinated?

Ultimately, switching between processes is just the beginning. Maintaining the entire system stably and efficiently requires additional management beyond the switching itself — scheduling to determine execution order, and synchronization to coordinate resource use. What we'll explore going forward is precisely how these problems are solved.

프로세스 관리의 다음 과제

문맥 교환을 통해 운영체제가 프로세스 간의 전환을 수행할 수 있다는 것을 확인했다. 그런데 여러 프로세스가 동시에 존재하는 환경에서는 단순히 전환이 가능하다는 것만으로는 충분하지 않다.

프로세스가 여럿 존재한다면 자연스럽게 새로운 문제들이 생겨난다. 대기 중인 프로세스가 여러 개일 때 그 중 어떤 프로세스를 먼저 실행할 것인가, 여러 프로세스가 같은 자원을 동시에 사용하려 할 때 이를 어떻게 조율할 것인가와 같은 문제들이다.

결국 프로세스를 전환하는 것 자체는 시작에 불과하다. 시스템 전체를 안정적이고 효율적으로 유지하기 위해서는 전환 이후의 관리, 즉 어떤 순서로 실행할지를 결정하는 스케줄링과 자원 사용을 조율하는 동기화 같은 추가적인 관리 기법이 필요하다. 앞으로 살펴볼 내용들이 바로 이 문제들을 어떻게 해결하는지에 대한 것이다.

The Core Challenges of Process Management Ahead

In an environment where multiple processes run together, there are additional problems the operating system must solve. Let's lay out the key challenges we'll be examining one by one.

The first is CPU scheduling. Among multiple waiting processes, which one gets the CPU? In what order and by what criteria is execution order determined?

The second is memory management. When multiple processes must share limited memory, how is memory allocated to each process and managed efficiently?

The third is inter-process communication. When processes with independent memory spaces need to exchange information, how is that handled?

The fourth is synchronization. When multiple processes try to access the same data simultaneously, conflicts can occur. Managing this situation to maintain data consistency and prevent conflicts requires dedicated techniques.

These four are the core issues in process management we'll be covering going forward. For now, get a broad sense that these problems exist — the specific details of each will be examined one by one in the chapters ahead.

앞으로 다룰 프로세스 관리의 핵심 과제들

여러 프로세스가 함께 실행되는 환경에서 운영체제가 추가로 해결해야 할 문제들이 있다. 앞으로 하나씩 살펴볼 핵심 과제들을 먼저 정리해두자.

첫 번째는 CPU 스케줄링이다. 대기 중인 여러 프로세스 중에서 어떤 프로세스에게 CPU를 줄 것인지, 어떤 순서와 기준으로 실행 순서를 결정할 것인지의 문제다.

두 번째는 메모리 관리다. 한정된 메모리를 여러 프로세스가 나눠 써야 하는 상황에서 각 프로세스에게 메모리를 어떻게 할당하고 효율적으로 관리할 것인지의 문제다.

세 번째는 프로세스 간 통신이다. 서로 독립된 메모리 공간을 가진 프로세스들이 필요에 따라 정보를 주고받아야 할 때, 이를 어떤 방식으로 처리할 것인지의 문제다.

네 번째는 동기화다. 여러 프로세스가 동일한 데이터에 동시에 접근하려 할 때 충돌이 발생할 수 있다. 이런 상황에서 데이터의 일관성을 유지하고 충돌을 막기 위한 관리 방법이 필요하다.

이 네 가지가 앞으로 다루게 될 프로세스 관리의 핵심 이슈다. 지금은 이런 문제들이 존재한다는 것을 큰 그림으로 파악해두고, 각 항목에 대한 구체적인 내용은 이후에 하나씩 살펴보게 될 것이다.

3️⃣ Process Execution and Control

Process Execution System Calls: fork()

Before directly observing process execution and control in a Ubuntu environment, let's first define the relevant terminology. There are representative system calls the operating system uses to manage processes from creation to termination. The first one we'll look at is fork().

fork() is a system call that creates one new process based on the currently running process. The newly created process is called the child process, and the original process is called the parent process.

When fork() is called, the parent process's memory space is logically duplicated to create the new process. The two processes created this way have different PIDs and run completely independently after creation.

There's an important point here. Code written after the fork() call is executed in both the parent and the child process. In other words, the execution flow splits into two branches after fork(), with each process independently continuing its own flow. Understanding this characteristic is essential for accurately grasping how code behaves after fork().

프로세스 실행 관련 시스템 호출; fork()

우분투 환경에서 프로세스의 실행과 제어를 직접 확인하기에 앞서, 먼저 관련 용어를 정리해두자. 운영체제가 프로세스의 생성부터 종료까지 관리하는 데 사용하는 대표적인 시스템 호출들이 있다. 그 중 첫 번째로 살펴볼 것이 fork()다.

fork()는 현재 실행 중인 프로세스를 기준으로 새로운 프로세스를 하나 더 생성하는 시스템 호출이다. 이때 새롭게 만들어진 프로세스를 자식 프로세스, 기존의 프로세스를 부모 프로세스라고 부른다.

fork()가 호출되면 부모 프로세스의 메모리 공간이 논리적으로 복제되어 새로운 프로세스가 만들어진다. 이렇게 생성된 두 프로세스는 서로 다른 PID를 가지게 되며, 생성 이후에는 완전히 독립적으로 실행된다.

여기서 중요한 점이 있다. fork() 호출 이후에 작성된 코드는 부모 프로세스와 자식 프로세스 모두에서 실행된다는 것이다. 즉 fork() 이후의 실행 흐름이 두 갈래로 나뉘어, 각 프로세스가 자신의 흐름을 독립적으로 이어서 실행하게 된다. 이 특성을 이해하고 있어야 fork() 이후의 코드 동작을 정확히 파악할 수 있다.

Distinguishing Parent from Child Using fork()'s Return Value

When fork() is called, both the parent and child processes execute the same code simultaneously. So how can you tell whether the currently executing code is running in the parent or the child? The answer is through fork()'s return value.

The return value falls into three cases. In the parent process, the PID of the newly created child process is returned. In the child process, 0 is returned. And if process creation fails, -1 is returned.

Using this difference in return values, you can clearly determine within the code after fork() whether the current execution context is the parent or the child. If the return value is 0, it's running in the child process; if the value is greater than 0, it's running in the parent. By using this return value as a condition to branch the code inside the program, you can control the parent and child to perform different behaviors.

fork()의 반환값으로 부모와 자식 구분하기

fork()를 호출하면 부모와 자식 프로세스가 동시에 같은 코드를 실행하게 된다. 그렇다면 현재 실행 중인 코드가 부모 프로세스에서 돌아가고 있는지, 자식 프로세스에서 돌아가고 있는지를 어떻게 구분할 수 있을까? 바로 fork()의 반환값을 통해 구분할 수 있다.

반환값은 세 가지 경우로 나뉜다. 부모 프로세스에서는 새로 생성된 자식 프로세스의 PID가 반환된다. 자식 프로세스에서는 0이 반환된다. 그리고 프로세스 생성에 실패한 경우에는 -1이 반환된다.

이 반환값의 차이를 이용하면 fork() 이후의 코드 안에서 지금 실행 중인 주체가 부모인지 자식인지를 명확하게 구분할 수 있다. 반환값이 0이면 자식 프로세스에서 실행 중인 것이고, 0보다 큰 값이면 부모 프로세스에서 실행 중인 것이다. 프로그램 안에서 이 반환값을 조건으로 분기를 나누면 부모와 자식이 서로 다른 동작을 수행하도록 제어할 수 있다.

The Execution Flow After fork()

Let's trace the process by which a single process splits into two execution flows via fork().

When the program starts, the main function executes, and the moment fork() is called, a new child process is created. From this point on, both the parent and child process exist simultaneously, and both continue executing from the code immediately after fork().

After that, the two processes execute different code blocks based on the return value. Because the child process receives 0, it executes the child's code block; the parent process receives the child's PID and executes the parent's code block. After each executes its respective code block, the two processes independently finish and terminate.

There's one thing that must be remembered here: it is not predetermined which process - parent or child - will run first. The parent might run first, or the child might. Because this depends on the operating system's scheduling decisions, the output order of the program can change every time it runs.

Ultimately, after fork(), a single piece of code runs separately in both the parent and child processes, and the order of execution is decided by the operating system.

fork() 이후의 실행 흐름

fork()를 통해 하나의 프로세스가 두 개의 실행 흐름으로 나뉘는 과정을 살펴보자.

프로그램이 시작되면 메인 함수가 실행되고, fork()가 호출되는 순간 새로운 자식 프로세스가 생성된다. 이 시점부터 부모 프로세스와 자식 프로세스가 동시에 존재하게 되며, 둘 다 fork() 다음 코드부터 실행을 이어간다.

이후 두 프로세스는 반환값을 기준으로 서로 다른 코드 블록을 실행한다. 자식 프로세스는 반환값이 0이기 때문에 자식 프로세스용 코드 블록을 실행하고, 부모 프로세스는 자식의 PID를 반환받아 부모 프로세스용 코드 블록을 실행한다. 각자의 코드 블록을 실행한 후 두 프로세스는 서로 독립적으로 실행을 마치고 종료된다.

여기서 반드시 기억해야 할 점이 있다. 부모와 자식 중 어느 프로세스가 먼저 실행될지는 정해져 있지 않다는 것이다. 부모가 먼저 실행될 수도 있고, 자식이 먼저 실행될 수도 있다. 이는 운영체제의 스케줄링 결정에 따라 달라지기 때문에 프로그램의 출력 결과는 실행할 때마다 순서가 바뀔 수 있다.

결국 fork() 이후에는 하나의 코드가 부모와 자식 프로세스에서 각각 실행되며, 그 실행 순서는 운영체제가 결정한다는 점을 이해해두어야 한다.

exec() — The System Call That Changes What a Process Runs

The system call used when an already-created process needs to switch to running a different program is exec(). It replaces the currently running process entirely with a new program.

The key here is that no new process is created. The process itself — its PID — remains the same. However, the code region, data region, and stack region that the process was running are all completely replaced with the contents of the new program. Think of it as keeping the process's shell intact while swapping out everything running inside it.

The outcome of an exec() call is also clearly defined. If the call succeeds, the original program's execution flow is completely terminated, and any code written after exec() does not execute — because there is no flow to return to once the replacement has occurred. Conversely, if the call fails, no replacement takes place, so the original program's flow continues and the code on the next line after exec() executes.

exec() is commonly used together with fork(). The typical pattern is to create a child process with fork() and then call exec() within the child to run an entirely different program.

exec() — 실행 내용을 바꾸는 시스템 호출

이미 생성된 프로세스가 실행할 프로그램을 바꿔야 할 때 사용하는 시스템 호출이 exec()다. 현재 실행 중인 프로세스를 완전히 새로운 프로그램으로 교체하는 역할을 한다.

여기서 핵심은 새로운 프로세스가 만들어지는 것이 아니라는 점이다. 프로세스 자체, 즉 PID는 그대로 유지된다. 하지만 그 프로세스가 실행하던 코드 영역, 데이터 영역, 스택 영역이 모두 새로운 프로그램의 내용으로 완전히 교체된다. 프로세스라는 껍데기는 그대로 두고 안에서 실행되는 내용만 통째로 바꾸는 것이라고 이해하면 된다.

exec()의 동작 결과도 명확하게 구분된다. 호출이 성공하면 기존 프로그램의 실행 흐름은 완전히 종료되고, exec() 이후에 작성된 코드는 실행되지 않는다. 이미 새로운 프로그램으로 교체되었기 때문에 돌아올 흐름 자체가 없어지는 것이다. 반대로 호출이 실패한 경우에는 교체가 이루어지지 않았기 때문에 기존 프로그램의 흐름이 그대로 유지되어 exec() 다음 줄의 코드가 실행된다.

exec()는 보통 fork()와 함께 사용되는 경우가 많다. fork()로 자식 프로세스를 생성한 뒤, 자식 프로세스에서 exec()를 호출해 전혀 다른 프로그램을 실행시키는 패턴이 대표적인 활용 방식이다.

Analyzing the exec() Execution Flow Example

This example is code that lets you directly observe how a process's execution flow changes before and after exec() is called. Let's follow the flow step by step.

First, a message is printed via printf before exec() is called. Up to this point, the original program's flow is executing normally.

Next, execl("/bin/ls", "ls", NULL) is called. The moment this single line executes, the current process is completely replaced by /bin/ls — the ls program that outputs a directory's file listing. The meaning of each argument is as follows.

The first argument, /bin/ls, is the full path of the file the operating system will actually execute. The operating system looks at this path to decide which file to run. The second argument, ls, specifies the name the executed program will recognize itself by. Even if you change the second argument to hello, the operating system will still execute /bin/ls, but internally the program will recognize its own name as hello. To avoid confusion, it is conventional to pass the same name as the executable file. The final NULL is a marker telling the operating system that the argument list ends here. Because exec-family functions can accept multiple arguments, the end must be explicitly indicated.

Once execl() succeeds, the original program's flow is completely gone. That's why the printf("exec 호출 후\n") written below it does not execute — there is no flow to return to.

The core takeaway from this example is one thing: exec() does not create a new process — it completely replaces the current process's execution content.

exec() 실행 흐름 예제 분석

이 예제는 exec() 호출 전후로 프로세스의 실행 흐름이 어떻게 바뀌는지를 직접 확인할 수 있는 코드다. 흐름을 단계별로 따라가보자.

먼저 printf를 통해 exec() 호출 전 메시지가 출력된다. 여기까지는 기존 프로그램의 흐름이 그대로 실행되는 구간이다.

그다음 execl("/bin/ls", "ls", NULL)이 호출된다. 이 한 줄이 실행되는 순간 현재 프로세스는 /bin/ls, 즉 디렉토리 파일 목록을 출력하는 ls 프로그램으로 완전히 교체된다. 각 인자의 의미를 살펴보면 다음과 같다.

첫 번째 인자 /bin/ls는 운영체제가 실제로 실행할 파일의 전체 경로다. 운영체제는 이 경로를 보고 어떤 파일을 실행할지 결정한다. 두 번째 인자 ls는 실행된 프로그램이 자기 자신을 어떤 이름으로 인식할지를 지정하는 값이다. 만약 두 번째 인자를 hello로 바꿔도 운영체제는 여전히 /bin/ls를 실행하지만, 실행된 프로그램 내부에서는 자신을 hello라는 이름으로 인식하게 된다. 혼란을 피하기 위해 실행 파일의 이름과 프로그램이 인식하는 이름을 동일하게 전달하는 것이 관례다. 마지막 NULL은 인자 목록이 여기서 끝났음을 운영체제에게 알려주는 표식이다. exec 계열 함수는 여러 인자를 받을 수 있기 때문에 끝을 명시적으로 표시해줘야 한다.

execl() 호출이 성공하면 기존 프로그램의 흐름은 완전히 사라진다. 그래서 그 아래에 작성된 printf("exec 호출 후\n")는 실행되지 않는다. 돌아올 흐름 자체가 없어지기 때문이다.

이 예제에서 확인할 수 있는 핵심은 하나다. exec()는 새로운 프로세스를 만드는 것이 아니라, 현재 프로세스의 실행 내용을 완전히 교체한다는 것이다.

The Combination of fork() and exec()

In practice, exec() is rarely used alone — it is almost always used together with fork(). Let's look at how this combination works.

First, fork() is called, creating parent and child processes. The child process initially executes the same code as the parent, but the moment execl("/bin/ls", "ls", NULL) is called on the child's side, the child's execution content is completely replaced by the ls program. Afterward, the parent continues executing its own code while the child, now replaced by ls, outputs the directory file listing. As a result, the parent's output and the ls output from the child both appear together.

This pattern is important because it is the fundamental way commands are executed in a shell. When a user types a command in the terminal, the shell creates a child process with fork(), then calls exec() in that child to replace it with the program corresponding to the entered command. The parent shell process remains intact and prepares to receive the next command, while the child process handles command execution. This structure is exactly why the shell becomes the parent process of user programs in the process tree we examined earlier.

fork()와 exec()의 조합

실제 운영체제에서 exec()는 단독으로 사용되기보다 대부분 fork()와 함께 사용된다. 이 조합이 어떻게 동작하는지 살펴보자.

먼저 fork()가 호출되면 부모 프로세스와 자식 프로세스가 생성된다. 자식 프로세스는 처음에는 부모와 동일한 코드를 실행하다가, 자식 프로세스 쪽에서 execl("/bin/ls", "ls", NULL)이 호출되는 순간 자식 프로세스의 실행 내용이 ls 프로그램으로 완전히 교체된다. 이후 부모 프로세스는 자신의 코드를 그대로 이어서 실행하고, 자식 프로세스는 ls 프로그램으로 교체되어 디렉토리 파일 목록을 출력한다. 결과적으로 부모 프로세스의 출력과 자식 프로세스에서 실행된 ls의 결과가 함께 나타나게 된다.

이 패턴이 중요한 이유는 바로 쉘에서 명령어를 실행할 때 사용되는 기본 방식이기 때문이다. 사용자가 터미널에 명령어를 입력하면 쉘은 fork()로 자식 프로세스를 생성하고, 그 자식 프로세스에서 exec()를 호출해 입력한 명령어에 해당하는 프로그램으로 교체한다. 부모인 쉘 프로세스는 그대로 유지되면서 다음 명령어를 받을 준비를 하고, 자식 프로세스가 명령어를 실행하는 것이다. 앞서 프로세스 트리에서 쉘이 사용자 프로그램들의 부모 프로세스가 된다고 했던 것이 바로 이 구조 때문이다.

exit() — The System Call for Terminating a Process

exit() is the system call used to terminate a running process. The moment it is called, the current process terminates immediately, and no code executes afterward. Like exec() examined earlier, it is a function from which execution does not continue after it's called.

When a process calls exit(), it notifies the operating system that this process is terminating. In this process, the operating system cleans up the resources the process had been using — memory, open files, and so on — and returns them to the system. The resources the process had been occupying are reclaimed at this point.

There's one more thing to note here. The termination information passed through exit() is delivered to the operating system as well. This information is stored so that the parent process can retrieve it later. A structure exists that allows the parent process to find out how the child process terminated. How this is actually handled in practice will be seen concretely through the wait() system call we'll look at next.

exit() — 프로세스 종료 시스템 호출

exit()는 실행 중인 프로세스를 종료할 때 사용하는 시스템 호출이다. 호출되는 순간 현재 프로세스는 즉시 종료되며, 이후 어떤 코드도 실행되지 않는다. 앞서 살펴본 exec()와 마찬가지로 호출 이후 실행 흐름이 이어지지 않는 함수다.

프로세스가 exit()를 호출하면 운영체제에게 이 프로세스가 종료됨을 알린다. 이 과정에서 운영체제는 해당 프로세스가 사용하던 메모리, 열려 있던 파일 같은 자원들을 정리해서 다시 시스템으로 돌려보낸다. 프로세스가 점유하고 있던 자원이 이 시점에 회수되는 것이다.

여기서 한 가지 더 짚고 넘어갈 점이 있다. exit()를 통해 전달되는 종료 정보가 운영체제에 함께 전달된다는 것이다. 이 정보는 부모 프로세스가 나중에 확인할 수 있도록 보관된다. 자식 프로세스가 어떻게 종료되었는지를 부모 프로세스가 알 수 있는 구조가 마련되어 있는 셈이다. 이 부분이 실제로 어떻게 처리되는지는 다음에 살펴볼 wait() 시스템 호출을 통해 구체적으로 확인하게 될 것이다.

Analyzing the exit() Example

The moment exit(0) is called, the process terminates immediately. As a result, the printf("이 문장은 실행되지 않는다.") written below it does not execute. Even though the code exists, the flow after exit() is completely blocked.

Let's also note the meaning of the number passed to exit() — the exit status value. 0 means the process terminated normally without any problems. Values other than 0, such as 1 or 2, are used to distinguish what kind of error occurred. As mentioned earlier, this exit status value is passed to the operating system so the parent process can retrieve it later.

The core takeaway from this example is one thing: once exit() is called, no subsequent code ever executes, and the program's execution ends immediately on the spot.

exit() 예제 분석

exit(0)이 호출되는 순간 프로세스는 즉시 종료된다. 그렇기 때문에 그 아래에 작성된 printf("이 문장은 실행되지 않는다.")는 실행되지 않는다. 코드가 존재하더라도 exit() 이후의 흐름은 완전히 차단되는 것이다.

여기서 exit()에 전달되는 숫자, 즉 종료 상태값의 의미도 짚어두자. 0은 프로세스가 문제 없이 정상적으로 종료되었음을 뜻한다. 반면 1이나 2 같은 0 이외의 값들은 어떤 종류의 오류가 발생했는지를 구분하는 데 사용된다. 이 종료 상태값은 앞서 언급했듯이 부모 프로세스가 나중에 확인할 수 있도록 운영체제에 전달된다.

이 예제를 통해 확인할 수 있는 핵심은 하나다. exit()가 호출되면 그 이후의 코드는 절대 실행되지 않으며, 프로그램의 실행이 그 자리에서 즉시 끝난다는 것이다.

wait() — The System Call for Waiting on a Child Process to Terminate

wait() is a system call that causes a parent process to wait until its child process terminates.

When a parent process calls wait(), if the child process is still running, the parent enters the waiting state. Only when the child process terminates does the parent process resume execution. In this process, the parent process can also retrieve the child's exit status value. The exit status value we saw earlier with exit() is delivered to the parent process at this moment.

One of wait()'s important roles is controlling execution order. Using wait() guarantees that the parent process won't terminate before the child. We said that after fork(), which runs first — parent or child — depends on the operating system's scheduling; by using wait(), you can clearly establish that the parent only moves on to the next step after the child has fully terminated. For this reason, wait() is also a system call used for synchronization between parent and child processes.

wait() — 자식 프로세스의 종료를 기다리는 시스템 호출

wait()는 부모 프로세스가 자식 프로세스가 종료될 때까지 기다리도록 만드는 시스템 호출이다.

부모 프로세스가 wait()를 호출하면 자식 프로세스가 아직 실행 중인 경우 부모는 대기 상태로 들어간다. 자식 프로세스가 종료되면 그제서야 부모 프로세스가 다시 실행을 이어간다. 이 과정에서 부모 프로세스는 자식 프로세스의 종료 상태값도 함께 회수할 수 있다. 앞서 exit()에서 살펴봤던 종료 상태값이 바로 이 시점에 부모 프로세스에게 전달되는 것이다.

wait()의 중요한 역할 중 하나는 실행 순서의 제어다. wait()를 사용하면 부모 프로세스가 자식보다 먼저 종료되지 않는다는 것이 보장된다. fork() 이후에는 부모와 자식 중 누가 먼저 실행될지 운영체제의 스케줄링에 따라 달라진다고 했는데, wait()를 사용하면 자식이 완전히 종료된 이후에 부모가 다음 단계로 넘어간다는 순서를 명확히 정할 수 있다. 이런 이유로 wait()는 부모와 자식 프로세스 간의 동기화에 사용되는 시스템 호출이기도 하다.

Analyzing the wait() Example

This example shows how fork(), exit(), and wait() are used together to control the execution order of parent and child processes.

First, a child process is created via pid_t pid = fork(). The child process then prints a "child process running" message, waits briefly with sleep(2), and terminates with exit(0).

Meanwhile, after fork(), the parent process doesn't immediately execute the next code — it calls wait(NULL) and stays in the waiting state until the child process fully terminates. Only after the child terminates with exit(0) does the parent wake up from the waiting state, print the "parent running after child terminated" message, and continue executing the subsequent code.

This example makes wait()'s role clear. Without wait(), there's no guarantee which of the parent and child runs first; but by using wait(), it is solidly guaranteed that the parent runs after the child terminates. Ultimately, wait() should be understood as the means by which a parent process waits for its child's termination and handles the result.

wait() 예제 분석

이 예제는 fork(), exit(), wait()가 함께 사용되어 부모와 자식 프로세스의 실행 순서가 어떻게 제어되는지를 보여준다.

먼저 pid_t pid = fork()를 통해 자식 프로세스가 생성된다. 이후 자식 프로세스는 "자식 프로세스 실행" 메시지를 출력하고, sleep(2)로 잠시 대기한 뒤 exit(0)으로 종료된다.

한편 부모 프로세스는 fork() 이후 곧바로 다음 코드를 실행하지 않고 wait(NULL)을 호출하여 자식 프로세스가 완전히 종료될 때까지 대기 상태로 머문다. 자식 프로세스가 exit(0)으로 종료되고 나서야 부모 프로세스가 대기 상태에서 깨어나 "자식 종료 후 부모 실행" 메시지를 출력하며 이후 코드를 이어서 실행한다.

이 예제를 통해 wait()의 역할이 명확하게 드러난다. wait()가 없다면 부모와 자식 중 누가 먼저 실행될지 보장할 수 없지만, wait()를 사용함으로써 자식이 종료된 이후에 부모가 실행된다는 순서가 확실하게 보장된다. 결국 wait()는 부모 프로세스가 자식 프로세스의 종료를 기다리고 그 결과를 처리하는 방법이라고 이해하면 된다.

Zombie Processes

exit() and wait() must be used as a matched pair. When the two don't properly interlock, a state called a zombie process occurs.

A zombie process is a process whose execution has already ended but which hasn't been fully cleaned up and remains in the system as a trace. When a child process calls exit() to terminate, the operating system temporarily holds onto the exit status value so the parent process can retrieve it. But if the parent process never calls wait(), no one retrieves that information. Even though the child's execution is over, its termination information hasn't been collected, so it can't be fully cleaned up and remains in the system.

A zombie process itself doesn't use the CPU, so it might not seem like a major problem at first. But as zombie processes accumulate, they continue to occupy system resources like PIDs — and over time, this leads to waste of system resources. Therefore, when writing a program that creates child processes, the parent process must always properly handle the child's termination through wait().

좀비 프로세스

exit()와 wait()는 짝을 이루어 사용되어야 한다. 이 둘이 제대로 맞물리지 않으면 좀비 프로세스라는 상태가 발생한다.

좀비 프로세스란 자식 프로세스의 실행은 이미 끝났지만 완전히 정리되지 않고 시스템에 흔적으로 남아있는 상태의 프로세스를 말한다. 자식 프로세스가 exit()를 호출해 종료되면 운영체제는 그 종료 상태값을 부모 프로세스가 확인할 수 있도록 잠시 보관해둔다. 그런데 부모 프로세스가 wait()를 호출하지 않으면 이 정보를 아무도 회수하지 않는 상황이 된다. 자식 프로세스는 실행이 끝났음에도 불구하고 종료 정보가 회수되지 않아 완전히 정리되지 못한 채 시스템에 남게 되는 것이다.

좀비 프로세스 자체는 CPU를 사용하지 않기 때문에 당장 큰 문제처럼 보이지 않을 수 있다. 하지만 좀비 프로세스가 누적되면 PID와 같은 시스템 자원을 계속 점유하게 되어 장기적으로 시스템 자원 낭비로 이어질 수 있다. 따라서 자식 프로세스를 생성하는 프로그램을 작성할 때는 반드시 부모 프로세스에서 wait()를 통해 자식의 종료를 올바르게 처리해주어야 한다.

How Zombie Processes Are Created

Let's look specifically at the path through which a zombie process comes into being.

When a child process calls exit(), its execution ends. At this point, the operating system must hold onto the child's termination information so the parent can retrieve it. But if the parent process never calls wait(), there's no way to deliver that information. And the operating system can't simply discard it either. The result is that the operating system leaves the child process's PCB in the kernel area as-is.

This is exactly the zombie process state. The execution is over, but the PCB hasn't been reclaimed, so the process remains in the system as a trace.

To summarize: a zombie process occurs when exit() and wait() fail to pair up. The child has terminated via exit(), but the parent hasn't retrieved the termination information via wait(). Only when these two system calls properly interlock is the child process's PCB fully cleaned out of the kernel and the process's lifecycle completely concluded.

좀비 프로세스가 만들어지는 과정

좀비 프로세스가 어떤 경로로 생겨나는지 그 과정을 구체적으로 살펴보자.

자식 프로세스가 exit()를 호출하면 실행은 끝난다. 이때 운영체제는 자식 프로세스의 종료 정보를 부모 프로세스가 확인할 수 있도록 보관해두어야 한다. 그런데 부모 프로세스가 wait()를 호출하지 않으면 이 종료 정보를 전달할 방법이 없다. 그렇다고 운영체제가 이 정보를 그냥 버릴 수도 없다. 결국 운영체제는 자식 프로세스의 PCB를 커널 영역에 그대로 남겨두게 된다.

바로 이 상태가 좀비 프로세스다. 실행은 이미 끝났지만 PCB가 회수되지 않아 시스템에 흔적으로 남아있는 프로세스인 것이다.

정리하면 좀비 프로세스는 exit()와 wait()가 짝을 이루지 못할 때 발생한다. 자식은 exit()로 종료했지만 부모가 wait()로 종료 정보를 회수하지 않은 상황이다. 이 두 시스템 호출이 제대로 맞물려야만 자식 프로세스의 PCB가 커널에서 완전히 정리되고, 프로세스의 생명 주기가 온전히 마무리된다.

The Impact of Zombie Processes on the System

Because a zombie process has finished executing, it doesn't use the CPU or perform any computation. So it can appear as though there's no immediate problem.

However, a zombie process's PCB remains in the kernel area, meaning it continues to occupy system resources like PIDs. PIDs are a limited resource in the system. As zombie processes begin to accumulate one by one, the available PID pool shrinks, and in extreme cases, the system can reach a point where new processes can no longer be created.

In the end, as zombie processes accumulate, PID resources are wasted and the operating system's management efficiency degrades ; a state where resources are being held without any execution taking place. This is why the parent process must always properly handle child process termination through wait().

좀비 프로세스가 시스템에 미치는 영향

좀비 프로세스는 실행이 끝난 상태이기 때문에 CPU를 사용하거나 어떤 연산을 수행하지는 않는다. 그래서 당장 눈에 띄는 문제가 없는 것처럼 보일 수 있다.

하지만 좀비 프로세스는 PCB가 커널 영역에 그대로 남아있기 때문에 PID와 같은 시스템 자원을 계속 점유하고 있다. PID는 시스템에서 사용할 수 있는 개수가 한정되어 있는 자원이다. 좀비 프로세스가 하나둘 쌓이기 시작하면 사용 가능한 PID가 그만큼 줄어들고, 극단적인 경우에는 새로운 프로세스를 생성할 수 없는 상황까지 이어질 수 있다.

결국 좀비 프로세스가 누적될수록 PID 자원이 낭비되고 운영체제의 관리 효율도 떨어지게 된다. 실행도 하지 않으면서 자원만 붙들고 있는 상태가 계속되는 것이다. 이것이 부모 프로세스에서 반드시 wait()를 통해 자식 프로세스의 종료를 제대로 처리해주어야 하는 이유다.

Analyzing the Zombie Process Example

This example is code that lets you directly observe how a zombie process is created when wait() is absent.

The child process prints a "Child process terminated" message and immediately terminates. Meanwhile, the parent process, without calling wait(), prints a "Parent process running" message and enters the waiting state via sleep(2).

The output order can change every time the program runs, because after fork(), which of the parent or child runs first is determined by the operating system's scheduling. But what's important in this example is not the output order. The key is that a situation has been created where the child process can terminate first while the parent hasn't called wait().

Even after the child terminates, if the parent never calls wait(), the operating system cannot immediately clean up the child's termination information. So it leaves part of the child's PCB in the kernel temporarily. This state — execution finished but termination information not yet collected — is exactly the condition that produces a zombie process.

Ultimately, this example illustrates what goes wrong when exit() and wait() fail to pair up. Any program that creates child processes must use wait() to properly handle the child's termination.

좀비 프로세스 발생 예제 분석

이 예제는 wait()가 없을 때 좀비 프로세스가 어떻게 만들어지는지를 직접 확인할 수 있는 코드다.

자식 프로세스는 "Child process 종료" 메시지를 출력한 뒤 바로 종료된다. 반면 부모 프로세스는 wait()를 호출하지 않은 채 "Parent process 실행중" 메시지를 출력하고 sleep(2)로 대기 상태에 들어간다.

출력 순서는 실행할 때마다 달라질 수 있다. fork() 이후에는 부모와 자식 중 누가 먼저 실행될지 운영체제의 스케줄링에 따라 결정되기 때문이다. 하지만 이 예제에서 중요한 것은 출력 순서가 아니다. 핵심은 부모 프로세스가 wait()를 호출하지 않은 상태에서 자식 프로세스가 먼저 종료될 수 있는 상황이 만들어졌다는 점이다.

자식이 종료된 이후에도 부모가 wait()를 호출하지 않으면 운영체제는 자식 프로세스의 종료 정보를 바로 정리하지 못한다. 그래서 커널에 자식 프로세스의 PCB 일부를 잠시 남겨두게 된다. 실행은 끝났지만 종료 정보가 회수되지 않은 이 상태가 바로 좀비 프로세스가 발생하는 조건이다.

결국 이 예제는 exit()와 wait()가 짝을 이루지 못했을 때 어떤 문제가 생기는지를 보여주는 사례다. 자식 프로세스를 생성하는 프로그램에서는 반드시 wait()를 통해 자식의 종료를 올바르게 처리해주어야 한다.

Ubuntu Practice

fork() Lab

The core takeaway from this lab is that after fork(), the parent and child processes have completely independent execution flows.

The moment fork() is called, the two processes go their separate ways. Which one runs first afterward is not determined by the program code ;it is decided by the operating system's scheduling. That's why even running the same code can produce output in a different order each time.

This is something that must always be kept in mind when writing programs that deal with processes. You should never try to control the execution order after fork() through the order in which code is written. If a guaranteed order is required, synchronization mechanisms like wait() must be used explicitly. In the end, this lab is an example that simultaneously demonstrates process independence, the non-determinism of scheduling, and the necessity of system calls to control it.

이번 실습을 통해 확인할 수 있는 핵심은 fork() 이후 부모와 자식 프로세스가 완전히 독립적인 실행 흐름을 가진다는 점이다.

fork()가 호출되는 순간 두 프로세스는 각자의 길을 간다. 이후 어느 쪽이 먼저 실행될지는 프로그램 코드가 결정하는 것이 아니라 운영체제의 스케줄링에 의해 결정된다. 그렇기 때문에 같은 코드를 실행하더라도 실행할 때마다 출력 순서가 달라질 수 있다.

이 점은 앞으로 프로세스를 다루는 프로그램을 작성할 때 반드시 염두에 두어야 할 부분이다. fork() 이후의 실행 순서를 코드 작성 순서로 제어하려 해서는 안 된다. 순서를 보장해야 하는 상황이라면 wait()와 같은 동기화 수단을 명시적으로 사용해야 한다. 결국 이번 실습은 프로세스의 독립성과 스케줄링의 비결정성, 그리고 그것을 제어하기 위한 시스템 호출의 필요성을 한꺼번에 보여주는 예제라고 할 수 있다.

exec() Lab

This example is code that lets you directly observe how a process's execution flow changes when exec() is called.

Looking at the output, the content written before the exec() call appears normally, but the code written after the exec() call does not produce output. The moment exec() succeeds, the current process's code and execution content are completely replaced by a new program. Once the replacement occurs, there is no flow to return to the original program, so the code written below it absolutely does not execute.

The core takeaway from this example is one thing: exec() does not create a new process — it replaces the entire execution content of the current process. The process itself is preserved; only the program running inside it is replaced. This example clearly demonstrates the distinction between fork() ; a call that creates a new process ; and exec(); a call that changes the content of an existing one.

이 예제는 exec()가 호출되었을 때 기존 프로그램의 실행 흐름이 어떻게 바뀌는지를 직접 확인할 수 있는 코드다.

실행 결과를 보면 exec() 호출 전에 작성된 출력은 정상적으로 나타나지만, exec() 호출 후에 작성된 코드는 출력되지 않는다. exec()가 성공하는 순간 현재 프로세스의 코드와 실행 내용이 완전히 새로운 프로그램으로 교체되기 때문이다. 교체가 이루어진 이후에는 기존 프로그램으로 돌아올 흐름 자체가 사라지기 때문에 그 아래에 작성된 코드는 절대 실행되지 않는다.

이 예제를 통해 확인할 수 있는 핵심은 하나다. exec()는 새로운 프로세스를 만드는 것이 아니라 현재 프로세스의 실행 내용을 통째로 바꾸는 것이라는 점이다. 프로세스 자체는 그대로 유지되고 그 안에서 실행되는 프로그램만 교체된다. fork()가 프로세스를 새로 만드는 호출이라면, exec()는 기존 프로세스의 내용을 바꾸는 호출이라는 차이를 이 예제가 명확하게 보여준다.

fork() + exec() Combined Lab

This example demonstrates the typical usage flow of fork() and exec() — the most commonly used combination in actual operating systems.

One thing that stands out is that the output order differs every time the program runs. The parent process prints its own message, while the child process is replaced via exec() with the ls program and outputs the directory listing. Which of the two runs first is determined by the operating system's scheduling, which is why the order of results changes with each run.

The core takeaway from this example is the basic process creation pattern in which fork() and exec() are used together. Creating a new process with fork() and then calling exec() in the child to replace it with an entirely different program — this structure is the most fundamental way programs are executed in an operating system. The pattern the shell uses to execute user commands follows exactly this approach. In a single example, you can confirm both concepts: the division of roles between fork() and exec(), and the non-determinism of execution order.

이 예제는 실제 운영체제에서 가장 많이 사용되는 fork()와 exec()의 전형적인 사용 흐름을 보여준다.

실행할 때마다 출력 순서가 매번 달라진다는 점이 눈에 띈다. 부모 프로세스는 자신의 메시지를 출력하고, 자식 프로세스는 exec()를 통해 ls 프로그램으로 교체되어 디렉토리 목록을 출력한다. 둘 중 누가 먼저 실행될지는 운영체제의 스케줄링이 결정하기 때문에 실행할 때마다 결과의 순서가 바뀌는 것이다.

이 예제를 통해 확인할 수 있는 핵심은 fork()와 exec()가 함께 사용되는 기본적인 프로세스 생성 패턴이다. fork()로 새로운 프로세스를 생성하고, 자식 프로세스에서 exec()를 호출해 전혀 다른 프로그램으로 교체하는 이 구조가 운영체제에서 프로그램을 실행하는 가장 기본적인 방식이다. 앞서 살펴봤던 쉘이 사용자의 명령어를 실행하는 방식도 바로 이 패턴을 따른다. fork()와 exec()의 역할 분담, 그리고 실행 순서의 비결정성이라는 두 가지 개념을 이 예제 하나로 함께 확인할 수 있다.

exit() Lab

This example is code that lets you directly observe that a process's execution terminates immediately when exit() is called.

Looking at the output, only the content written before exit(0) appears; the printf("이 문장은 실행되지 않습니다\n") written below it does not. The moment exit() is called, the process terminates on the spot instantly, and the subsequent code never even gets the chance to execute.

The core takeaway from this example is that exit() is the definitive termination point of a process. Even without reaching the end of a function or the last line of the program, the exact moment exit() is called, is when the process ends. Just like exec() examined earlier, this example clearly demonstrates that exit() is also a function from which execution flow is completely blocked after it is called.

이 예제는 exit()가 호출되었을 때 프로세스의 실행이 즉시 종료됨을 직접 확인할 수 있는 코드다.

실행 결과를 보면 exit(0) 이전에 작성된 내용만 출력되고, 그 아래에 작성된 printf("이 문장은 실행되지 않습니다\n")는 출력되지 않는다. exit()가 호출되는 순간 프로세스의 실행이 그 자리에서 즉시 종료되고, 이후의 코드는 실행될 기회조차 얻지 못하기 때문이다.

이 예제를 통해 확인할 수 있는 핵심은 exit()가 프로세스의 명확한 종료 지점이라는 것이다. 함수의 끝이나 프로그램의 마지막 줄까지 도달하지 않더라도, exit()가 호출된 바로 그 순간이 프로세스가 끝나는 시점이 된다. 앞서 살펴본 exec()와 마찬가지로 exit() 역시 호출 이후의 흐름이 완전히 차단되는 함수라는 점을 이 예제가 명확하게 보여준다.

wait() Lab

This example is code that lets you directly observe the behavior of a parent process waiting for a child process to terminate when wait(NULL) is called.

Looking at the output, the "child process running" message appears first, followed by a brief pause, then the "parent running after child terminated" message. The parent process's output only appears after the child process has run first and fully terminated.

This is possible because the parent process called wait(NULL) and entered the waiting state until the child terminated. We said that after fork(), there's no guarantee which of the parent or child runs first — but by using wait(), the execution order is clearly guaranteed: the parent only moves to the next step after the child has fully terminated.

The core takeaway from this example is that wait() does more than simply wait for the child to terminate — it plays the role of synchronizing the execution order between the parent and child processes.

이 예제는 부모 프로세스가 wait(NULL)을 호출했을 때 자식 프로세스의 종료를 기다리는 동작을 직접 확인할 수 있는 코드다.

실행 결과를 보면 "자식 프로세스 실행" 메시지가 먼저 출력되고, 잠시 텀이 생긴 뒤에 "자식 종료 후 부모 실행" 메시지가 출력된다. 자식 프로세스가 먼저 실행되고 완전히 종료된 이후에야 부모 프로세스의 출력이 나타나는 것이다.

이것이 가능한 이유는 부모 프로세스가 wait(NULL)을 호출하며 자식 프로세스가 종료될 때까지 대기 상태에 들어갔기 때문이다. fork() 이후에는 부모와 자식 중 누가 먼저 실행될지 보장할 수 없다고 했는데, wait()를 사용함으로써 자식이 완전히 종료된 이후에 부모가 다음 단계로 넘어간다는 실행 순서가 명확하게 보장된다.

이 예제를 통해 확인할 수 있는 핵심은 wait()가 단순히 자식의 종료를 기다리는 것을 넘어, 부모와 자식 프로세스 사이의 실행 순서를 동기화하는 역할을 한다는 점이다.

이 예제는 부모 프로세스가 wait()를 호출하지 않았을 때 좀비 프로세스가 발생하는 상황을 직접 확인할 수 있는 코드다.

파일을 실행하면 자식 프로세스는 메시지를 출력하고 종료된다. 부모 프로세스는 sleep()으로 대기 상태에 들어간다. 겉으로 보기에는 자식 프로세스가 정상적으로 종료된 것처럼 보인다. 출력도 나왔고 실행도 끝났으니 아무 문제가 없어 보이는 것이다.

하지만 부모 프로세스 코드에 wait()가 없다. 자식 프로세스가 exit()로 종료되었지만 부모가 wait()를 호출하지 않았기 때문에 운영체제는 자식의 종료 정보를 부모에게 전달하지 못한 채 커널에 그대로 남겨두게 된다. 실행은 끝났지만 PCB가 완전히 정리되지 않은 상태, 즉 좀비 프로세스가 만들어진 것이다.

이 예제가 보여주는 핵심은 좀비 프로세스는 겉으로 드러나지 않는다는 점이다. 출력 결과만 봐서는 정상적으로 종료된 것과 구별이 되지 않는다. 하지만 내부적으로는 커널에 자식 프로세스의 정보가 남아 자원을 점유하고 있다. 이것이 wait()를 반드시 짝을 맞춰 사용해야 하는 이유다.

Core Concept of the Test

Impact of Software Defects

What is the purpose of testing? The software we develop is ultimately embedded in final products such as automobiles, aircraft, and mobile devices. A small mistake made by a developer becomes a fault, which then leads to a failure. These failures propagate to the higher-level subsystems that contain the software, then from the subsystem to the system, and finally to the end product, ultimately becoming a major hazard that leads to an accident. This results in harm; including casualties, economic losses, and environmental disasters. A small error originating in software can propagate through fault propagation and escalate into a critical problem. When a fault occurs due to a small human mistake, the primary goal of testing is to detect that fault. By discovering faults through testing, they can be contained rather than propagated to higher-level systems, ultimately reducing the likelihood of accidents. For this reason, testing must be conducted systematically by a third party based on predefined test cases. This is the purpose and role of testing.

[Reference] Difference Between Testing and Debugging

Testing and debugging are easily confused, but they are clearly distinct concepts with different purposes and roles.

• The primary purpose of testing is to discover unknown faults. Debugging, on the other hand, aims to accurately correct already known faults identified through testing. There is also a difference in terms of who is responsible. Testing can be performed by internal team members, but a third party such as an external test team can discover more unknown faults by approaching the system from a different perspective. Debugging, however, is best handled by internal developers who are familiar with the system, as it requires locating and correcting known faults.

• The key activities also differ. The core activity of testing is fault detection, and test cases must be prepared in advance to carry this out systematically. In debugging, the first step is fault localization; identifying the exact location of the fault, such as which bit in memory is affected or between which modules in a connected system the fault occurred. This is followed by fault identification, which involves determining the type of fault, such as whether it is a compilation error or a logical error. Finally, fault correction, the act of properly fixing the identified fault, is the concluding activity of debugging.

In conclusion, testing is the activity of finding faults without prior knowledge of what went wrong, while debugging is the activity of precisely fixing faults with full knowledge of what the problem is.

Error, Defect, Failure 용어

In the context of software quality, it is important to clearly distinguish between three terms: Error, Defect, and Failure.

• An error is the concept that causes a defect and refers to a mistake made by a person, typically a developer or analyst. In other words, it refers to the incorrect human action itself. An error leads to a defect, also referred to as a fault or bug.

• A defect is a flaw embedded in a product as a result of an error, and it becomes the root cause of failures or problems. That is, if an error is the human act, then a defect is the flaw left behind in the code or artifact as a consequence of that act.

• A failure is the state of malfunction that manifests when the system is actually executed due to an underlying defect. In other words, a failure is the phenomenon in which a latent defect surfaces in the runtime environment.

In summary, a human mistake known as an error produces a defect embedded in the product, and that defect manifests as a failure during system execution. The three terms are linked in a cause-and-effect chain, and understanding each one clearly is fundamental to software quality management.

Example of Error, Defect, and Failure

The concepts of Error, Defect, and Failure in software quality engineering can be illustrated through a concrete example. Consider the following simple pseudocode: Speed = Distance / Time. In this code, Time is positioned in the denominator of the division operation. If the value of Time becomes 0, a divide-by-zero exception will occur.

Mapping the three terms to this scenario makes each concept clear. First, the error is the developer's failure to consider the case where Time could be 0 — a mistake that occurred in the developer's thinking. Next, the defect is the resulting absence of exception-handling code in the program to address the case where Time equals 0 — a flaw reflected in the code itself. Finally, the failure is the occurrence of a Divide By Zero Exception when the program is actually executed with a Time value of 0 — the actual malfunction of the system.

The reason software quality engineering distinguishes between these three concepts is to propose appropriate countermeasures at each stage. At the error stage, training and process improvements are needed to reduce human mistakes. At the defect stage, code reviews and static analysis can eliminate defects before they lead to failures. By clearly distinguishing each stage, it becomes possible to accurately identify the root cause of a problem and systematically establish preventive and corrective measures.

Common Misconceptions About Testing

There are three common misconceptions about software testing.

The first misconception is that testing proves the absence of defects. However, the fundamental purpose of testing is not to prove that there are no defects, but to discover as many unknown defects as possible. Testing is, in essence, an activity that demonstrates the existence of defects. To achieve this, testing should be performed by a third party rather than the developer who built the product, and it should be conducted across diverse environments. Testing across various operating systems such as Windows, iOS, and Android can uncover defects that the developer had not anticipated.

The second misconception is that testing is easy and that all defects can be found. If testing is viewed simply as checking outputs against inputs, it may appear straightforward. However, proper testing requires thorough planning, design, and analysis, as well as a deep understanding of the product under development. Therefore, testing is by no means an easy task, and testers must also possess sufficient knowledge and competence in development. Furthermore, finding all defects is practically impossible. In the era of artificial intelligence, programs can have hundreds of millions of parameters, making it infeasible to test every possible combination within a reasonable timeframe. For this reason, it is important to incorporate the concept of defect prevention from the outset. Through activities such as reviews conducted during the requirements analysis and design phases, defects should be prevented from propagating to subsequent stages before testing even begins.

The third misconception is that testing only needs to take place after the implementation, or coding, phase. From the perspective of the V-Model, however, testing should not begin after coding is complete. Rather, it must be initiated from the earliest stages of development, including requirements analysis and design. Test planning and preparation should begin before implementation starts, enabling quality to be managed systematically throughout the entire development lifecycle.

Test Process Details - 1

What is Systematic Testing?

To understand systematic testing, one must first think of the concept of PDCA. PDCA stands for Plan, Do, Check, and Act, and serves as the foundational framework for any organization to carry out its projects in a structured manner. Systematic testing refers to a state in which a process built upon this PDCA framework is established and followed throughout all testing activities.

1. Test Process from a PDCA Perspective

In the Plan phase, the overall test purpose, scope, schedule, and methods are established, and the features to be tested are selected. For example, in a shopping mall system, features such as member management and order history would be defined as test targets during this phase. Once the plan is established, test design follows, during which test cases are developed and test procedures are defined. From the perspective of the V-Model, test cases are derived based on requirements, architecture, and detailed design, meaning that test case development should begin immediately upon completion of the Plan phase. The test environment must also be prepared at this stage. This includes not only the environment in which the software operates independently, but also the environment in which it interfaces with related hardware devices, and even the real-world operating environment — for instance, if the software is embedded in a vehicle, testing must be conducted during actual driving conditions. Testing across diverse environments is essential to uncovering unknown defects. In particular, once coding is complete in the V-Model, there is likely insufficient time to plan and design tests. This is because the focus must shift to executing the actual tests on the running program. Therefore, it is essential to remember that test planning and design must be carried out in parallel with development in order to improve overall quality.

In the Do phase, the test cases developed during the Plan phase are actually executed and the test results are evaluated. This work can be automated using testing tools, which automatically assess results once test cases are provided as input.

In the Check and Act phases, the test results are analyzed and their adequacy is assessed. Based on the analysis, countermeasures are established and corrective actions are taken. If the identified issues are determined to stem not from defects themselves but from problems in the process or development environment, corrective action recommendations are issued accordingly.

In conclusion, it is essential to remember that systematic testing is not merely about executing tests, but rather an activity in which test planning, design, execution, evaluation, and improvement are carried out organically across the entire PDCA cycle.

[Reference] ISO/IEC/IEEE 29119 Testing Standard

ISO/IEC/IEEE 29119 is the most representative international standard in the field of software testing, jointly established by three international organizations: ISO, IEC, and IEEE. This standard defines a multi-layer test process to ensure that testing is conducted systematically and correctly.

The key emphasis of this standard is that the test process should not be addressed solely at the project level, but that a test process and its foundations must first be established at the organizational level. In other words, the standard requires a top-down structure in which the process and infrastructure for effective testing are first defined at the organizational level, cascaded down to the project and task management level, and ultimately executed by test engineers in accordance with those established criteria.

Specifically, this standard defines a multi-layer test process consisting of four layers, each following a top-down structure in which direction and criteria are passed from higher to lower levels.

The first layer is the organizational test process. At this level, test policies and test strategies that apply across the entire organization are established. This serves as the highest-level foundation that sets the direction and criteria for all subsequent testing activities.

The second layer is the project-level test management process. Based on the policies and strategies established at the organizational level, a test management process is constructed at the project level. This process includes three key activities: test planning, monitoring and control, and test completion.

The third layer is the test management process. Building upon the project-level test management process, this layer involves establishing a more granular test management process broken down by task, phase, and test type. The same three activities; test planning, monitoring and control, and test completion; are applied at this level as well. Although the composition of activities is identical between the second and third layers, they are distinct stages that differ in their scope and level of application.

The fourth layer is the dynamic test execution process. This is the stage in which the software is actually executed and tested based on the criteria and processes passed down from the upper layers. To carry out testing effectively at this stage, test design and implementation must first be completed, followed by the setup and maintenance of the test environment, after which actual test execution takes place.

The key point is that testing should not be viewed merely as an execution activity. Rather, direction and criteria must first be defined and communicated at the organizational and project levels before testing begins. Subsequent chapters will examine in detail what each of the organizational, test management, and dynamic test layers specifically covers.

2. Organizational Test Process

The organizational test process sits at a higher level than the testing carried out at the project level, and represents the stage at which the direction and criteria for testing across the entire organization are defined. This process consists of three key activities.

The first activity is organizational test specification development. This involves developing an organizational test policy specification and an organizational test strategy specification based on the organization's test objectives. For example, if quality achievement targets are set in stages, this activity would involve concretely developing the policies and strategies needed to achieve 50% coverage at stage one, 30% at stage two, and 100% at stage three, broken down to the level of unit testing, integration testing, and so forth.

The second activity is monitoring and control of organizational test specification utilization. This involves monitoring whether the organizational test specifications developed in the first activity are being effectively applied across projects and tasks within the organization, and exercising control when they are not being properly followed. Policies and strategies established at the organizational level must be applied to all subordinate projects, and appropriate control measures must be taken when this is not the case.

The third activity is organizational test specification update. No matter how well-crafted the initial policies and strategies may be, issues are likely to surface when they are applied to real projects. For instance, if shortcomings in an existing policy are revealed during unit test execution, that policy must be revised and improved. The core of this activity lies in continuously incorporating feedback and results from the application of the specifications at the project and task level, and iteratively improving the organizational test policy and strategy specifications.

In conclusion, the organizational test process is not a one-time activity of establishing policies and strategies, but rather a cyclical process of monitoring whether the developed specifications are being correctly applied in practice, and continuously improving them based on the outcomes.

Example of Organizational Test Policy and Strategy Specifications

The organizational test policy and strategy specifications are structured hierarchically, beginning with the highest-level policy specification and cascading down to increasingly detailed strategy specifications.

At the highest level sits the organizational test policy specification. This document contains the broadest set of criteria applicable to all testing activities across the organization, and includes the test purpose, test process, test organization and roles, referenced test standards, test asset management and reuse methods, and policies for test process evaluation and improvement.

Below this sits the organizational test strategy specification. This layer defines more granular test strategies based on the policy specification, and includes risk management related to testing, test selection and prioritization, test documentation, configuration management, defect management, the use of automation tools, and individual test strategies related to performance and security testing.

The next layer defines strategies by specific test type. This is where decisions are made regarding which testing methods will be applied in practice, including unit testing strategy, integration testing strategy, and system testing strategy.

At the lowest layer sit the most granular strategies, including project-level test strategies and individual test-level test strategies. At this layer, specific strategies are defined that apply directly to particular projects or individual test units.

In conclusion, the organizational test policy and strategy specifications represent a system designed to ensure that consistent test criteria are communicated from the organizational policy specification, which captures the overall direction of the organization - all the way down to the project and individual test level through a progressively detailed hierarchical structure.

Test Process Details - 2

1. Test Management Process

Having previously examined the organizational test process, we established that test policies and strategies are formulated in the form of specifications. The test management process is the process by which these established strategies are reflected in the actual projects and individual tasks within the organization, and by which the testing activities carried out within them are systematically managed.

The concept of "management" here is directly linked to the PDCA framework discussed earlier. When PDCA is applied to the test management process, it is structured as follows. First, a test plan is established, corresponding to the Plan phase. Actual test execution is then carried out in the dynamic test process as the Do phase. Whether the results are proceeding appropriately is verified and acted upon in the test monitoring and control phase, corresponding to Check and Act. Finally, upon completion of testing, a test completion report is produced.

Furthermore, if changes arise during the monitoring and control phase, the test plan must also be continuously updated. A plan is not a fixed document once established; rather, it is a living document that must be consistently revised to reflect test execution results and changes in circumstances.

In conclusion, the test management process consists of test planning, test monitoring and control, and test completion, and is a PDCA-based management activity designed to ensure that the organization's test policies and strategies are systematically executed and managed at the project and task level.

Test Management Process; Detailed Composition

The test management process consists of three key activities: test planning, test monitoring and control, and test completion.

In the first activity, test planning, the scope and targets of testing are identified at the project and task level, and the test strategy defined within the organizational test process is established by referencing it as an input.

In the second activity, test monitoring and control, the execution of the dynamic test process is monitored based on the test plan, and the current state of testing is continuously tracked. If issues arise during execution, the testing activities must be appropriately controlled and necessary corrective actions must be taken.

In the third activity, test completion, the artifacts generated after testing is concluded are systematically managed. Since these artifacts may be reused in the future, they must be properly stored, and the test environment must also be organized with reusability in mind. Once these activities are completed, a final test closure report is produced.

Detailed Activities of Test Planning

Test planning is not merely a matter of setting a schedule; rather, it consists of the following highly systematic detailed activities.

The first activity is understanding the context. Before planning the tests, it is essential to first understand the overall situation, including the project's objectives, requirements, relevant stakeholders, and overall schedule. Through this understanding, the scope of testing is clarified and the direction for structuring the test plan is formulated. This process yields a preliminary test plan and development schedule.

The second activity is risk identification and analysis. Risk management is a critical element of project management. During the course of testing, a wide range of risk factors may arise, such as changes in requirements, shifts in priorities, or the replacement of personnel. These risks must be identified and analyzed in advance, and methods for mitigating them must be derived. The analyzed risks and their mitigation strategies are then incorporated into the test strategy design.

The third activity is test strategy design and resource determination. Based on the risk analysis, the test strategy is designed, and the human resources and detailed schedule to be allocated are determined accordingly.

The fourth activity is drafting the test plan. Based on the preceding activities, an initial draft of the test plan is produced. However, the plan at this stage is not yet a finalized document and must go through a review and consensus process involving the relevant stakeholders.

Finally, through the review and consensus process, an agreed-upon test plan is produced and shared with all relevant stakeholders.

In conclusion, it is essential to remember that test planning is not a simple preparatory step, but rather a highly systematic process that spans from understanding the context through risk analysis, strategy design, resource determination, plan drafting, and review and consensus.

Detailed Activities of Test Monitoring and Control

Test monitoring and control is the process of verifying that testing is proceeding correctly in accordance with the established test plan, and taking appropriate corrective action when necessary.

The input to this process is the test plan. Once the test plan is received, the setup required for monitoring and control is configured accordingly. The content of tests executed in the dynamic test execution phase is then compared against the plan, and test measurement is performed. Based on these measurement results, monitoring is carried out. During monitoring, the progress of testing is continuously tracked, and if any deviation from the plan is identified, control activities are initiated. For example, if unit testing has not been performed or integration testing has been omitted, appropriate corrective measures are taken for those activities that have deviated from the plan.

Reporting must also be carried out on these activities. A representative indicator for test status reporting is test case effectiveness, which is expressed as a percentage representing the ratio of the number of defects found to the number of test cases executed. Furthermore, if there are 100 requirements, the degree to which the test cases satisfy those requirements can be measured as a percentage, providing insight into how well the product meets its requirements.

In conclusion, test monitoring and control is not merely about confirming whether testing has been completed, but rather a systematic process of quantitatively measuring and reporting test progress and quality satisfaction levels based on data.

Detailed Activities of Test Completion

Even after testing has been successfully conducted, the test completion phase involves a set of systematic preparatory activities for future testing.

The first activity is verification of the test asset repository. The assets generated during the testing process are reviewed and organized, with decisions made regarding where and how they will be stored. This is done to ensure that these assets can be reused in future testing efforts.

The second activity is test environment restoration. The environment that was configured for testing is restored to its original state so that it can be utilized again in future tests.

The third activity is retrospective review and lessons learned. The strengths and shortcomings of the current round of testing are reflected upon and documented, so that they can be used to improve the quality of future testing activities.

Finally, the test completion report is produced. The report includes a test summary, a comparison of planned versus actual results, test effectiveness metrics, and requirements satisfaction levels. Furthermore, since defects that were not discovered during testing may still remain in the software, the report must also address residual risk identification, post-test countermeasures, test artifact management, a list of reusable assets, and lessons learned, all compiled and managed in report form.

In conclusion, the test completion phase is not simply about wrapping up testing, but consists of a highly systematic set of activities encompassing asset storage, environment restoration, retrospective review, and completion reporting. It is important to remember that the entire process covered so far; test planning, test monitoring and control, and test completion, constitutes a PDCA-based process for systematically managing testing.

2. Dynamic Test Process

Having examined test planning at the task level, the dynamic test process consists of a series of activities carried out to actually execute testing based on that plan.

The first activity is test design and implementation. Test cases are developed based on requirements documents, and the test cases and procedures required for actual test execution are concretely developed at this stage. The second activity is test environment setup and maintenance. The environment in which testing will actually take place is configured and maintained in accordance with the test environment requirements. The appropriate environment must be set up in advance — whether testing will be conducted in a PC environment, an actual vehicle environment, or otherwise — to suit the characteristics of the test target. The third activity is test execution. Tests are executed based on the test specification. The manner in which test results are handled varies depending on whether the issue identified was previously known. If it is a known issue, it must be resolved, and the process of determining how to address the defect continues through test result reporting.

One important point concerns when the test design and environment configuration activities that precede the actual Do phase of test execution take place. It is essential to remember that when the requirements analysis and architecture design processes on the left side of the V-Model are being carried out, test design and environment configuration are also conducted in parallel. The core principle of the dynamic test process is that test preparation must begin from the earliest stages of development, not just immediately before test execution.

Dynamic Test Process; Detailed Composition

The dynamic test process consists of four activities: test design and implementation, test environment setup and maintenance, test execution, and test result reporting.

In the first activity, test design and implementation, test cases and test procedures are developed in accordance with the test scope and test strategy identified in the test plan. Specifically, this involves analyzing the test basis. The development artifacts used to conduct testing, and deriving test requirements, test conditions, test coverage criteria, and test cases.

In the second activity, test environment setup and maintenance, the environment and data required for actual test execution must be prepared. The test environment encompasses not only a standalone software environment such as a PC, but also embedded environments that include hardware, and even vehicle environments, depending on the characteristics of the test target.

In the third activity, test execution, actual tests are run using the previously developed test procedures, and the results of each test execution are recorded in the form of Pass or Fail.

In the fourth activity, test result reporting, defects are identified and recorded based on an analysis of the test execution results. This ensures that discovered defects are systematically managed and that the necessary follow-up actions can be initiated.

[Reference] Test Basis: Concept and Examples

The test basis refers to the development artifacts required for conducting testing; specifically, the documents and materials that serve as the foundation for deriving test cases and test procedures.

Viewed through the lens of the V-Model, the development artifacts on the left side correspond to the test activities on the right side. The test basis utilized at each test level is as follows.

For unit testing, which corresponds to the detailed design phase, the detailed design document serves as the test basis. Since detailed design is concrete to a degree comparable to actual source code, the source code itself is also a representative test basis artifact for unit testing. Integration testing verifies whether the interfaces between individual modules are appropriate; accordingly, the architecture design document that forms the basis for this verification serves as the test basis. System testing uses the requirements specification, the output of requirements analysis; as its basis. Finally, since acceptance testing is the stage at which the highest-level requirements of the customer and end users are verified, the requirements definition document and use case definition document serve as the test basis.

In conclusion, the test basis comprises the artifacts that must be referenced at each test level in order to derive test cases and test procedures, and it is important to understand that the development artifacts on the left side of the V-Model directly provide the foundation for the test activities on the right.

Using Linux, Installing Programs

1. Getting Started

When Linux starts, a login screen appears. Entering the login details used during initial setup and pressing Enter will prompt for a password. The password is not displayed on screen. In the case of Ubuntu, information such as the kernel version and current system status is shown. This information cannot be changed by the user.

In Linux/Unix, uppercase and lowercase letters are treated differently. Additionally, the number 0, the letter O, the number 1, the pipe symbol |, lowercase l, and uppercase I all look similar but are different characters. The same applies to the backtick ` and the single quote '. Furthermore, computers convert human-readable characters into numbers for processing. The language humans recognize is called a high-level language, while the language machines recognize is called a low-level language. Humans interpret symbols based on their everyday meaning, whereas computers convert them into numbers. For example, the letter A (a) that humans recognize is converted by computers to 65 and 97 respectively in ASCII code.

Linux/Unix Accounts: Groups and Users Linux is an environment where multiple people can use a single computer simultaneously. Those users may be team members or administrators, making it crucial to manage who is allowed to do what. The units used to manage this are users and groups. A user is simply a single login account. An account is required to access the system, and permissions are granted accordingly. Individual permissions can be assigned directly to a user, and these take priority over group permissions. For example, even if a group is blocked from accessing file A, if user kim is granted access directly, kim can still access it. A group is a unit for managing permissions by bundling users together. A single user can belong to multiple groups simultaneously. A group itself cannot execute anything or log in; there must be a user within it for it to have any meaning. As an analogy, a group is like a "type of access pass" and a user is "the person holding that pass." The pass itself does not open the door. When a new account is created, a group with the same name is automatically created alongside it. Create account 'kim' → User 'kim' is created → Group 'kim' is also automatically created The permission priority is as follows: individual (user) permissions take precedence over group permissions. Permissions can be assigned to groups in bulk, and individual permissions can override them when exceptions are needed.

root root is the superuser account with full administrative privileges over the entire system. Every file can be read, modified, and deleted, every setting can be changed, and other user accounts can be created or removed. Because the name "root" is publicly known and identical across every Linux system in the world, it is the primary target for hacking. Distributions like Ubuntu block direct root login by default and use the sudo command instead. Root login can be enabled for convenience, but doing so exposes the system to hacking. The root user's home directory is located at /root. It is important to be aware of the dual meaning of the term "root directory". It can refer to the root account's home directory, but it can also refer to the top-level directory of the entire filesystem, /.

sudo sudo is not available to everyone; only users who have been granted the permission can use it. The account created during the initial installation of Linux is automatically granted sudo privileges, but accounts created afterward do not have sudo access by default and must be explicitly granted it by an administrator. The users who can use sudo and the scope of their access are managed in a file called /etc/sudoers. This file allows fine-grained control over which users can run sudo and which specific commands they are permitted to execute. An important point here is that having sudo privileges does not mean inheriting all of root's permissions. Logging in directly as root grants full access to all system privileges, whereas sudo allows only the permissions explicitly defined in /etc/sudoers. In other words, sudo is not a system that copies the entire set of root's keys; it lends only the specific keys needed for a given situation.

Prompt: The prompt is the text displayed at the beginning of the line in the terminal where commands are entered. Its basic format is username@computername:directory\(, and this single line contains everything about who the current user is, where they are, and what permissions they hold. The username is the name of the account currently logged in. Since Linux allows switching to a different account during use; including switching to root if the user has the necessary permissions and knows the password, the current username is always displayed in the prompt so it is immediately clear who is performing actions. The computer name is the name of the machine currently connected to, displayed to distinguish which computer is being used when remotely connected to another machine. The directory indicates the current working folder, where ~ is a special symbol representing the logged-in user's home directory. For example, the home directory of the account test is /home/test, which is abbreviated as . The symbol at the very end of the prompt indicates the current permission level. # is displayed when the user has root privileges, and \) is displayed for regular users. The specific symbol may vary depending on the shell being used, but Ubuntu uses \( by default. For example, if the terminal displays test@test:\), the currently logged-in user is test, the connected computer name is also test, the current location is test's home directory, and the $ symbol confirms regular user privileges. If the user switches to root, the prompt changes to root@test:~#, with both the username and the trailing symbol changing simultaneously, making the privilege change immediately visible.

Logging Out (logout, exit) Linux/Unix systems are rarely powered off and are often running 24 hours a day. Because multiple users can use the system simultaneously, shutting down after one user finishes would inconvenience others still using it. However, when an administrator needs to stop the operating system, commands such as shutdown and poweroff are used. These commands can only be executed with root privileges. logout and exit terminate only the current user's session visible on screen, whereas shutdown and poweroff bring the entire system down, making it completely inaccessible.

Adding and Deleting Accounts: Accounts are added using useradd and deleted using userdel. However, these commands only perform basic operations; meaning they do not automatically create a home directory or password for the account. A home directory does not refer to the /home folder itself, but rather to the personal space represented by ~ for each account. While a personal computer is typically owned and used entirely by one person, Linux/Unix is designed for multiple users to use a single system simultaneously, so storage space is divided and shared among users. The personal space allocated to each account is what is referred to as a home directory. Therefore, an account's home directory means the personal space where that account can store and use files, which is a different concept from the /home directory where all users' home directories are collectively stored. This distinction is important to keep in mind. There are also adduser and deluser commands, which must be separately installed as they are not built into the operating system. Unlike useradd and userdel, these include additional functionality such as prompting for a password during account creation.

Built-in Manual Linux/Unix provides a built-in manual that can be accessed by typing commands directly in the terminal. It is not included by default due to storage constraints and must be installed separately. The manual is divided into sections numbered 1 through 9, each covering a different type of content such as commands, system calls, and configuration files. The section numbers do not need to be memorized as they can be looked up easily when needed.

2. Copying and Installation

Copying vs. Installing Copying is simply placing identical content in a different location, much like photocopying a document. The content is the same, but the copy may not be usable depending on the computer environment. Installing goes beyond copying by performing additional procedures; it makes the software usable in the new environment by supplementing what is missing and incorporating information specific to the installation location.

The limitations of copying can be understood through an analogy. If a wireless internet device used at home is physically moved to an office, it may or may not work, because the device was configured for the home internet connection and only the location has changed. The same applies to software: copying source code to a new location does not mean it can be run immediately.

The process from copying to execution is as follows: the source code is copied, a compiler and libraries are installed separately, paths and linked files are configured for the environment, and only after all of these steps can the executable (binary file) be run.

Installation automatically handles all the steps required to make software usable anywhere. Returning to the earlier analogy, it is like pulling a dedicated line within the office building and performing a proper installation.

The installation process works as follows: the executable (binary file) is automatically copied to the appropriate location, and a script for environment configuration; including path assignment and linked file specification - is executed automatically, leaving the software ready to use immediately.

In summary, copying is the act of moving files, while installing is the process of automatically performing all the necessary configurations and procedures to make the software actually function in that environment. This is why simply copying a program is not sufficient, and depending on the purpose, the process is divided into full installation and simply copying the executable file.

3. Program

How to Use apt When installing a program in Ubuntu, the following command is used. linux@linux:~$ sudo apt install openssh-server Running this command first prompts for the sudo password, which is the password set when the account was first created. Once the password is entered, the installation proceeds. At this point, apt does not simply install openssh-server alone - it automatically installs all the libraries and additional programs required for that program to function. At the end of the installation process, a [Y/N] prompt appears asking for confirmation of these additional installations.

In other words, apt is a tool that installs all the files and libraries needed to use a program in a single operation. Taking openssh-server as an example, there are multiple dependency files required to run this program, and rather than the user having to find and install each one individually, apt identifies and installs them all at once.

Package List Management: apt retrieves packages by referencing package repository information. On Ubuntu, the files /etc/apt/sources.list and /etc/apt/sources.list.d/ubuntu.sources store repository information, and apt uses this to fetch the required packages from those repositories. The version information in the repository list can be updated with the sudo apt update command. It is important to distinguish between types of updates: the update prompted by the system at first login is related to critical security patches from the operating system's perspective, whereas the update performed manually with sudo apt update refreshes the version information of the package list. Since not everything needs to be kept up to date at all times, updates can be performed selectively as needed. apt is a program that manages the installation and removal of software on Debian-based Linux distributions.

Installing a Package; sudo apt install package-name

Removing a Package: sudo apt remove package-name.. If it is necessary to also delete files created during the installation of a package,

purge is used instead of remove. sudo apt purge package-name The difference between remove and purge is that remove deletes only the package itself, while purge deletes both the package and all associated files created during installation. Upgrading a Package To upgrade installed packages to the latest version, the following two commands are executed in order.

sudo apt update / sudo apt upgrade: apt update first refreshes the version information in the package list, after which apt upgrade upgrades the actual packages to their latest versions.

5. How to use dpkg

While apt automatically manages everything required for installation, dpkg is a tool that installs only a single package bundle. Unlike apt, it does not automatically install dependent libraries or additional programs - it processes only the one specified package. It is important not to confuse dpkg with compression. Compression bundles multiple files together for the purpose of transfer or storage. dpkg, on the other hand, manages files necessary for running a program as a single package unit. The fundamental difference is that dpkg manages units of executable programs, not simple file bundles.

Using Commands

passwd

The passwd command is used to change the password of an account. When the prompt displays linux@linux:~$, the account name to be changed corresponds to the first linux at the very beginning of the prompt.

whoami

There are situations where it is necessary to confirm which account is currently being used when executing commands. One such example is when an administrator connects as a regular user in order to provide technical support. Running the whoami command immediately displays the name of the account currently in use.

id

Running the id command outputs more detailed information compared to whoami. It displays comprehensive information about the currently active account, including user and group data. The numbers shown in the output are important, as files are represented by numbers during the process of copying and moving them.

who

The who command displays a list of accounts currently logged into the system. On a personal Ubuntu Linux system used by a single person, only one account will be shown. However, if multiple accounts are logged in simultaneously or multiple terminals are open, all logged-in accounts will be listed.

The output of the who command also includes an item indicating the method of login, which is divided into two types. tty (teletypewriter) refers to a direct physical connection, while pts (pseudo-terminal slave) refers to a virtual connection. In other words, if the user is sitting directly in front of the computer, the connection is shown as tty, and if connected remotely, it is shown as pts.

w

The w command shows what is currently happening on the system. The output is displayed in the following format.

13:12:33 up 21min,  2 users,  load average: 0.00, 0.00, 0.00
USER     TTY FROM             LOGIN@  IDLE  JCPU  PCPU  WHAT

The current time, system uptime, number of logged-in users, and system load average are all displayed on a single line. Below that, detailed information for each logged-in account is listed. jcpu refers to the total CPU time used by all processes running under that account, while pcpu refers to the CPU time used by the process currently shown in the what column.

These commands do not need to be memorized in detail. Simply knowing that they exist is enough, as they can easily be looked up through a search when needed.

date

Running the date command outputs the time configured on the system. An important point to note is that this time does not necessarily match the actual real-world time. Since the output reflects the time set on the system, it may differ from the actual time if a user has manually changed it. This works the same way as the time settings on a mobile phone; it can be set to automatically sync with the current time, or manually configured to a desired time by the user.

touch

The touch command updates the access time and modification time of a file to the current time. Options that begin with - are called flags. The main flags available for touch are as follows.

-t is used to change the time to a user-specified time rather than the current time. -m changes only the modification time of the file. -a changes only the access time of the file.

Detailed descriptions of each flag can be found in the built-in manual using man touch, or through external websites. There is no need to memorize the specific options - they can be looked up and applied as needed.

printenv, env

printenv and env are commands used to check what environment the computer is currently operating in. Running either command outputs the current environment information, and it is also possible to hide an ID or change a group for security purposes. The env command is used in the following format.

linux@linux:~$ env [NAME=VALUE] ... [COMMAND [ARG] ...]

This sets the environment variable specified by NAME to the value of VALUE and then executes COMMAND. In other words, rather than permanently changing the entire system environment, it applies the specified environment value only for the duration of that particular command execution.

ls

ls is the most commonly used command for files and directories, displaying the contents of the current directory. A variety of flags can be used alongside it.

Running ls -F appends an indicator to each file name to show the type of file. Running ls without -F displays only the file names without any indicators.

The reason indicators were introduced is that when ls first appeared, color display was not supported and output was shown in a single color, making it difficult to distinguish file types. Color support is now standard, so indicators are no longer strictly necessary, but the feature is maintained because some users still rely on it and there is no reason to remove it. Preserving existing functionality for the sake of compatibility is a general principle in computing.

. and ..

. refers to the current directory, while .. is a relative notation referring to the directory one level above the current directory.

Permissions and File Types

Running ls -lh /etc outputs detailed information about files and directories. The character displayed at the very beginning of each line indicates the type of file. d indicates a directory, l (lowercase L) indicates a symbolic link, and - indicates a regular file. For a simple view, ls -F can be used, and for a detailed view, ls -lh is the appropriate option.

Permissions are divided among four targets: u for the owner (user), g for the group, o for others, and a for all.

When a file's permissions are displayed as drwxr-xr-x, the leading d indicates the file type, and the remaining characters are read in groups of three.

rwx  /  r-x  /  r-x
 u       g       o

The meaning of each character is as follows: r means read permission (4), w means write permission (2), and x means execute permission (1).

In binary notation, the values corresponding to r, w, and x are 4, 2, and 1 respectively. Permissions can be set by specifying the sum of these values.

Full permission  : 4+2+1 = 7  →  rwx
Read/Write only  : 4+2   = 6  →  rw-
Read only        : 4     = 4  →  r--

For example, setting permissions to 644 results in rw-r--r--, and setting them to 777 results in rwxrwxrwx. More complex administrator-level permission features also exist using s and t, but at this stage it is sufficient to simply be aware that such features exist.

pwd

The pwd command displays the current working directory. When permissions are frequently changed or tasks accumulate, it can become easy to lose track of the current location. In practice, pwd is used frequently.

cd

The cd command is used to navigate between directories. cd . moves to the current directory, meaning the location does not change. cd .. moves one level up to the parent directory. cd ~ moves to the home directory of the currently logged-in user.

The reason ~ is used is that it allows relative path expression. For example, to navigate to the bin directory under a specific user's home directory, cd ~/bin can be used. Without ~, the full path such as cd /home/linux/bin would need to be typed out each time. When there are many users across various environments, each user's home directory path is different, making absolute paths impractical. Using ~/bin universally implies each user's own bin directory under their respective home directory, which is why ~ is an essential notation.

du

While Windows and Mac allow users to easily check storage usage through a file explorer, Linux Ubuntu uses the du command for this purpose. du stands for disk usage and shows how much disk space the current directory or file occupies.

df

The df command is used to check how much of the filesystem is being used. For example, if a 1TB disk is installed and 200GB is in use, the remaining 800GB will not be shown unless it has been mounted. A volume must be mounted before it can be recognized and used by the system.

The main flags are as follows: -a displays all filesystems including all types, and -h displays file sizes in a human-readable format. For example, using the -h option outputs sizes in units such as KB, MB, and GB instead of bytes.

mkdir, rmdir

mkdir is used to create a directory.

rmdir is used to delete a directory. Adding the -p flag allows deletion of both parent and child directories simultaneously.

cp

The cp command is used to copy files, creating an exact duplicate of the original. When copying, there are important points to note regarding file names. If the files are in different directories, the original and the copy may share the same name. However, within the same directory, two files cannot have the same name, so the copy must be given a different name. If a file with the same name already exists in the destination directory - for example, when copying a src file to a dst file and a file named dst already exists, the system will ask whether to overwrite it. This is an area that requires particular care when using Linux. Windows and Mac display overwrite warnings by default, whereas Linux may overwrite without warning depending on the settings. There is a difference in terms of efficiency, but it is important to judge which approach is more appropriate depending on the situation.

mv

The mv command is used to move a file or directory from its current location to another. If the destination is a different directory, the file is fully moved to that location. If used within the same directory, it can also serve as a way to rename a file without actually moving it.

rm

Directories can be deleted using rmdir. The rm command is also used for deletion.

chown, chmod

chown is used to change the owner of a file or directory. For example, it can be used to change the owner from root to test, or from test to root. Because this involves changing ownership, the user must have the appropriate permissions to execute it.

chmod is used to change the execution permissions of a file or directory. Permissions can be set using either the numeric method or the rwx character method. The symbols used in the character method have the following meanings: + adds a permission, - removes a permission, and = assigns only the specified permissions while removing any that are not explicitly stated. For example, u+rw means adding read (r) and write (w) permissions to the owner (u).

Summary

Linux is an environment where multiple users can work simultaneously, making permission management critically important. Because root holds full control over the entire system, a successful attack could expose everything, resulting in a serious security breach. Anyone in a position to manage root privileges must always be aware of the responsibility that comes with it.

When copying or moving files, it is essential to develop the habit of verifying whether overwriting an existing file is intentional. Accidental overwrites are often difficult or impossible to undo.

There are multiple ways to install programs. While it is possible to compile source code directly and copy it, this approach is difficult to manage and time-consuming. For this reason, Ubuntu primarily uses package management tools such as apt and dpkg. Among these, apt is the most widely used. At this stage, it is sufficient to know the names of packages and how to perform updates.

1️⃣ Composition of computer hardware

1. Four Major Components of a computer
   : Processor (CPU), Memory, System Bus, and I/O Devices. All components are connected through the system bus and operate together as a single system.

• CPU: The central unit that performs calculations and processes instructions Memory; A space where programs and data needed during CPU operations are temporarily stored. The CPU can only directly process data that is loaded into memory System Bus; A common pathway through which the CPU, memory, and I/O devices exchange data I/O Devices; All devices used to interact with the outside world, including keyboards, mice, disks, monitors, and network devices.

Hardware Connection Structure Here is a structural overview of how each component is actually connected.

• Inside the CPU: Composed of the ALU, registers, and control unit, it not only performs calculations but also controls the order and timing of instructions

• Memory (RAM): Holds currently running programs and data. The CPU exchanges data with memory through the system bus

• I/O Devices: Not directly connected to the CPU, but indirectly connected through an I/O controller

The most critical point is that all components are connected through the system bus, and all instruction delivery and addressing takes place through this pathway. The operating system uses this structure to utilize the CPU, allocate memory, and control I/O devices.

• Von Neumann Architecture This is the most representative computer architecture followed by the majority of computers today. Two Most Important Characteristics First, the CPU, memory, I/O devices, and storage devices are all connected through a single bus.

• Second, programs are stored in memory just like data. Because the CPU interprets the contents of memory as instructions and executes them, a program must be loaded into memory before it can run.

• Why Is This Important? This is because the role of the operating system, which will be covered later, is centered around this memory. The operating system regulates execution order, allocates resources, and manages the system based on the programs loaded into memory.

• Key Perspective Rather than focusing on the historical background of Von Neumann, the goal is simply to understand the concept that "a computer executes programs centered around memory."

2. Processor(CPU) and Registers

• Processor (CPU): The CPU is the entity that actually executes programs stored in memory. It is the central unit in a computer that executes program instructions, interpreting commands stored in memory, performing the necessary operations, and controlling the overall flow of execution. The CPU also directly retrieves programs and data stored in memory, processes them, and stores the results back in memory. In other words, if memory is the space that stores programs, the CPU is the entity that actually executes them.

• Components of the Processor: The CPU is composed of three elements. Registers, ALU (Arithmetic Logic Unit), and the control unit; each playing a different role in processing a single instruction.

• Registers are extremely fast temporary storage spaces inside the CPU that temporarily hold data and instructions retrieved from memory, as well as intermediate results of operations. Registers are the reason the CPU can work so quickly.

• The ALU (Arithmetic Logic Unit) is the part responsible for actual calculations, performing arithmetic operations such as addition and subtraction, as well as logical operations such as comparisons.

• The Control Unit decides which instruction to execute and directs the registers and ALU on when and how to operate through control signals. It manages the overall flow through the internal bus.

• In summary, registers handle storage, the ALU handles computation, and the control unit handles control; these three elements work together to execute a single instruction.

• Registers are the storage space the CPU uses at the moment it executes an instruction. Values needed for execution, data required for operations, and intermediate results produced during calculations are all temporarily stored here. Because it would take too long for the CPU to travel back and forth to memory every time it works, information that is immediately needed is loaded into registers for processing.

• Registers are therefore most directly connected to the flow of program execution and are the first storage space the CPU accesses. However, since they exist inside the CPU, their number and capacity are very limited; but in return, they are extremely fast.

• Components of Registers There are multiple registers inside the CPU, and each register plays a different role during the instruction execution process.

• PC (Program Counter) Stores the address of the next instruction to be executed. The CPU uses this value to determine where to fetch the next instruction

• IR (Instruction Register) Stores the currently executing instruction fetched from memory

• MAR (Memory Address Register) Stores the memory address to be accessed

• MBR (Memory Buffer Register) Temporarily stores the instruction or data value read from memory

• ACC / DR Stores data used in operations and the results of those operations.

• Actual arithmetic and logical operations are performed by the ALU These registers and memory are connected through the system bus, and the CPU executes programs by exchanging instructions and data between registers and memory. Ultimately, this structure represents the core of the entire execution flow in which the CPU fetches → interprets → computes → and stores the results of instructions.

3.Cache and Memory

• Cache is a high-speed memory located between the CPU and main memory. While the CPU has a very fast processing speed, main memory is relatively slow to access. This speed difference often causes the CPU to stall while waiting for memory to respond, and cache memory is used to alleviate this problem.

• Cache is a space that pre-stores instructions and data frequently used by the CPU, allowing it to retrieve needed data directly from the nearby cache rather than going all the way to main memory. In summary, cache is a type of memory, but it should be understood as a performance-oriented structural element designed to help the CPU operate faster.

• Memory is a device that stores currently running programs and data. When a program is executed, the program and the data it needs must be loaded into memory, and the CPU reads from this memory to carry out instructions. In other words, memory is the workspace where the CPU performs its operations while the computer is running. When designing a computer system, memory and storage devices are typically selected based on three criteria.

• The first is speed; how quickly data can be read and written.

• The second is cost; how much it costs per unit of capacity.

• The third is volatility; whether data is retained when the power is turned off. Since no single storage device can satisfy all three criteria simultaneously, computer systems combine these characteristics in a hierarchical structure.

• Main memory is the representative storage device that the CPU can directly access, and along with registers, it is the memory most closely connected to the CPU. When executing a program, the program's instructions and data must be located in main memory. Anything not in memory cannot be accessed by the CPU and therefore cannot be executed.

• Main memory also serves to store intermediate results and temporary data generated during program execution. Main memory is generally implemented using DRAM technology, making it a volatile memory that can only retain data while power is supplied. Therefore, when the power is turned off, all contents of main memory are lost. As a result, main memory is a core storage space for program execution, but it is not a storage device suited for long-term data retention.

• Memory Hierarchy Computer memory is not a single layer but a structure divided into multiple layers. The higher up in the hierarchy, the closer to the CPU; meaning faster speed but smaller capacity. The lower down, the slower the speed, but the larger the capacity and the lower the cost.

• The CPU can directly access data in registers, cache, and main memory, but cannot directly access secondary storage. Therefore, programs stored in secondary storage must first be transferred to main memory before they can be executed. The reason for using this hierarchical structure is simple — because it is not possible to make all data storage both fast and cheap, the hierarchy strikes a balance between speed and cost in order to maximize CPU performance.

  

• System Bus The hardware components inside a computer do not operate independently; They work together by exchanging data with one another. The system bus is the pathway that connects the CPU, main memory, and I/O devices into a single system. Rather than connecting each device directly to one another, the system bus is structured so that all devices exchange data and control signals through a common pathway. Whether the CPU is fetching instructions from memory, receiving input data from an I/O device, or storing processed results, all data movement takes place through the system bus. In short, the system bus is the connection structure that ties all hardware inside the computer together into one unified system.

• System Bus Signal Types Although the system bus appears to be a single pathway, it is actually divided based on the type of information being transmitted. Depending on the nature of the signals being carried, it is divided into three types: address bus, data bus, and control bus. The address bus is the pathway that tells the CPU where to access. It specifies which location in memory or among devices is to be used. The data bus is the pathway through which actual instructions and data travel. The content being processed moves between the CPU, memory, and I/O devices through this bus. The control bus carries signals that control the manner and sequence of operations, such as read operations, write operations, I/O requests, and whether a task has started or completed.

• In summary, the address bus handles where, the data bus handles what, and the control bus handles how — these three buses work together to ensure proper communication between the CPU, memory, and I/O devices.

  

• I/O Devices The CPU cannot communicate with users through main memory alone; this is where I/O devices come in. I/O devices are hardware that connects the computer with the user or the external environment. They serve roles such as receiving input via a keyboard, displaying results on a monitor, and storing or transmitting data through disks or networks. These I/O devices do not connect directly to the CPU or main memory, but instead exchange data through the system bus.

• They are broadly divided into three categories based on their role.

• Input Devices: Keyboard, Mouse, Camera

• Output Devices: Monitor, Printer, Speaker

• Storage / Communication: Disk (SSD/HDD), Network Card

• In summary, I/O devices are the components that allow information processed inside the computer to connect with the outside world. I/O Devices and the Operating System I/O devices are extremely diverse and complex in terms of hardware. Their operating methods, speeds, and control mechanisms are all different. If application programs had to directly control every device individually, they would become enormously complex. This is why the operating system takes on this role. Because the operating system manages I/O devices with different characteristics in a consistent manner, application programs do not need to worry about the specific operating methods of each device; they simply work using common operations such as read, write, and output. The actual device control is carried out by the operating system on their behalf. Ultimately, although I/O devices are diverse and complex at the hardware level, the operating system hides that complexity, allowing application programs to operate in the same way regardless of the type of device.

2️⃣ Processing of program and data

1) Command and Data

• Information handled by a computer is broadly divided into data and command. Data refers to values that enter through input devices or are processed during program execution, while instructions are directives telling the CPU what tasks to actually perform; such as "add these values," "store this," or "move to the next step." An important point here is that a program is not one large task, but rather a collection of many individual instructions. These commands are stored at specific memory addresses, and the CPU fetches and executes them one by one in order. In other words, the CPU reads instructions stored in memory one at a time, and uses the necessary data alongside them to carry out the entire program.

• CPU command - Level Operation; The CPU processes one instruction at a time, and each instruction goes through a defined set of steps. First, if the required data is in main memory, it is brought into a register through the bus; this is the preparation phase for performing an operation. Next, the value stored in the register is passed to the ALU, where the actual operation such as ADD is performed. Once the operation is complete, the result is either stored back in a register or, if necessary, moved to memory. The control unit manages the sequence of this entire flow, and the CPU repeats this process for every single command.

In summary, the CPU executes a program by continuously repeating the basic cycle of fetching data, computing, and moving the result. Instruction Execution Cycle The following is the process the CPU goes through when executing a single instruction. Regardless of which command is being executed, the CPU always repeats the same defined sequence.

• 1. Command Fetch; Based on the address pointed to by the Program Counter (PC), the next command to be executed is retrieved from memory and stored in the Instruction Register (IR)

• 2. Instruction Decode / PC Update; The CPU interprets what the fetched instruction means, and updates the PC to point to the next instruction. This is the step that determines what to do and where to go next -

• 3. Operand Fetch. If the instruction requires data, the relevant values are retrieved from memory or registers Instruction Execute.

• 4. The actual operation; such as arithmetic, logical, or comparison operations - is carried out by hardware including the ALU Result Store.

• 5. Once the operation is complete, the result is stored in a register or written to memory if necessary Move to Next Instruction - The CPU returns to step 1 for the next instruction, and this cycle repeats continuously.

• CPU-Memory Speed Gap; CPU and Memory Speed Difference The most significant problem in computer performance is the speed gap between the CPU and memory. The CPU is extremely fast at interpreting and executing instructions, while main memory is relatively slow to access.

• This means the CPU is often ready to execute the next instruction, but the required data has not yet been loaded from memory; leaving the CPU with nothing to do but wait for a memory response.

• If this waiting time repeats, overall system performance will suffer no matter how powerful the CPU is. Over time, CPU performance has risen steeply while memory performance has grown only gradually, causing the gap to widen.

• This gap is known as the processor-memory performance gap, and it means that even if CPU speed continues to increase, the overall system performance will be bottlenecked at the point where memory access cannot keep up.

• Cache Memory; Cache memory is used to alleviate the speed gap between the CPU and main memory. It is a fast storage space located between the CPU and main memory that temporarily stores instructions and data frequently used by the CPU.

• As a result, the CPU can retrieve needed data directly from the cache without accessing main memory every time. Cache is not a replacement for main memory; it is a supplementary storage space designed to assist main memory access and reduce CPU waiting time.

• How Cache Memory Works When the CPU needs an instruction or data, it checks the cache first rather than going directly to main memory. If the required data is already in the cache, this is called a cache hit; the CPU can retrieve the data immediately without accessing main memory, enabling very fast processing.

• On the other hand, if the data is not in the cache, this is called a cache miss; in this case, the CPU must go all the way to main memory, which takes more time. The retrieved data is then stored in the cache to prepare for future accesses.

• In summary, a cache hit is fast and reduces memory access, while a cache miss is slow and requires memory access. The effectiveness of cache depends on how frequently cache hits occur.

• Why Cache Works Effectively; Locality The reason cache is effective is due to a property called locality. The tendency for memory access during program execution to be concentrated and repeated within a specific range, rather than occurring randomly. Locality is divided into two types.

• Temporal locality refers to the characteristic that data or instructions used recently are likely to be used again in the near future. Variables inside loops or repeatedly executed instructions are typical examples.

• Spatial locality refers to the characteristic that if a particular memory location is accessed, nearby instructions or data are also likely to be used soon. Processing an array in order or executing a sequence of consecutive instructions are representative examples; in such cases, loading not just the needed data but also nearby data into the cache at once increases the probability of cache hits on future accesses.

• Cache is therefore not simply a fast memory; it is a structure designed to exploit these locality characteristics to reduce memory access and improve performance.

2. Bottleneck

When a program runs, the CPU does not just perform calculations; it uses various resources such as memory access, cache usage, and I/O processing in sequence. If even one of these resources is slow, the entire flow will be delayed at that point. The slowest processing stage that limits overall performance in this way is called a bottleneck. For example, even if the CPU itself is very fast, if memory access is slow, the CPU must wait for the response; and as a result, the overall program speed is determined by memory performance.

To address this, systems use structures such as alleviating memory access delays with cache and improving the processing methods themselves to reduce I/O-related bottlenecks.

• Common Flow of I/O Device Processing I/O devices are physically much slower than the CPU. Therefore, if the CPU simply waits whenever an I/O operation occurs, efficiency drops significantly. For this reason, how much the CPU should be involved in I/O processing becomes an important design consideration for the operating system.

• In some cases the CPU directly checks the device status, while in others the device sends a completion signal after finishing its task. Depending on the I/O processing method, the CPU can either be tied up waiting or freed to perform other work. The operating system uses various I/O processing methods to maximize system performance.

• Polling; is a method in which the CPU periodically checks the status of an I/O device directly after making a request. The CPU continuously asks the device whether it is ready. The advantage of this method is that it is very simple to implement; it only requires checking device status without complex control logic. However, because the CPU repeatedly checks status without doing any other work even when the device is not yet ready, CPU resources are wasted and overall system efficiency drops.

• Interrupt; With the interrupt method, the CPU does not check device status directly. Instead, after making an I/O request, it hands the task off to the device and continues performing other work. When the device finishes its task, it sends a signal to the CPU ; this signal is called an interrupt. The CPU temporarily pauses its current work, handles the device's completion request, and then returns to its original task. In other words, rather than the CPU continuously checking device status, the device calls the CPU only when needed. Because the CPU can perform other work during I/O wait time, this method uses CPU resources far more efficiently than polling. The flow of the interrupt method is as follows. First, the CPU sends an I/O request to the device and continues other work without waiting. The device processes the requested data, and upon completion sends an interrupt to the CPU. Multiple devices can generate interrupts simultaneously, but the CPU can only handle one interrupt at a time. When an interrupt occurs, the CPU stops its current work and passes control to the kernel. The operating system processes multiple simultaneous interrupts one by one in order of priority. Once all handling is complete, the CPU returns to its original task. The key point is that the CPU does not continuously check the device. There is no resource waste, and the device calls the CPU only when necessary.

• DMA (Direct Memory Access); With DMA, the CPU only sets the conditions for the transfer; such as where data should come from, where it should go, and how much should be transferred. The actual data transfer is then handed off to the DMA controller. Once this setup is complete, the CPU no longer participates directly in the data transfer process and moves on to other work. The actual data movement occurs directly between the I/O device and memory without passing through the CPU. When the transfer is complete, the DMA controller generates an interrupt to notify the CPU that the transfer has finished.

  

• In this way, the CPU only configures the transfer once at the beginning, and all subsequent repetitive data movement is handled entirely by the DMA controller. DMA is therefore the most efficient I/O method, consuming almost no CPU resources even for large-volume data transfers.

Summary of I/O Methods I/O processing methods have evolved based on how much CPU involvement is required.

1️⃣ Quality and the V-Model Life Cycle Process

1. Definition of Quality

"Quality" is a term we use all the time; we say a product or service is "high quality" or "low quality." But how exactly is quality defined?

Definitions by Leading Scholars

• W. E. Deming (Father of Quality): "Quality is meeting the needs of customers."

• J. M. Juran: "Quality is fitness for use."

• P. B. Crosby: "Quality is conformance to requirements."

Synthesizing these definitions, quality is determined by how well a product or service satisfies customer or user needs - in other words, how closely it conforms and how fit it is for its intended purpose.

Definition of Quality: The totality of characteristics of a product or service that bear on its ability to satisfy stated and implied requirements.

Stated Requirements vs. Implied Requirements

• Stated requirements: Requirements that are documented or formally and explicitly defined.

• Implied requirements: Requirements that are not documented but are implicitly expected by the user. Customers often cannot fully articulate everything they need, and these taken-for-granted, hidden expectations are what we call implied requirements.

Therefore, a development organization must uncover and analyze not only stated requirements but especially implied requirements, and reflect them in the product or service - only then can the team deliver what customers truly want.

2. Two Perspectives on Quality

What is ultimately delivered to the customer is the final product, but evaluating quality does not mean looking at the end deliverable alone. Quality must be viewed from two perspectives.

1) Process Quality

This refers to the quality of the entire workflow, including development, maintenance, and the work products produced at each stage. The higher the process quality, the more positive its impact on product quality. Process quality is based on the PDCA cycle.

• Plan: Establish a plan before starting work.

• Do: Execute the work according to the plan.

• Check: Regularly monitor whether the work is on track.

• Act: Continuously improve the process.

Organizations that follow the PDCA cycle demonstrate strong process quality, ensuring that all work products are managed systematically.

2) Product Quality

Work products generated through the process must ensure traceability and consistency. Only when the final software or system satisfies the customer's requirements can we say the product quality is good.

Key Takeaway: It is not just the final deliverable that matters. Process quality must be raised first — this improves the quality of intermediate work products at each stage, which in turn elevates the quality of the final deliverable.

[Reference] Quality Management System Based on PDCA

A quality management system takes inputs such as customer requirements and the needs and expectations of relevant stakeholders, and operates across departments — including planning, marketing, sales, R&D, development, testing, and production — all working in accordance with the PDCA cycle. Even a single coding task follows the Plan → Do → Check → Act cycle. Through this, organizations continuously improve customer satisfaction, QMS performance, and the quality of products and services.

[Reference] Relationship Between Process Quality and Product Quality: The BMW Case Study

BMW divided its component suppliers into two groups — those with high process quality and those with low process quality — and analyzed the relationship between process quality and product quality. Product quality was measured by the number of defects discovered prior to SOP (Start of Production).

High process quality organization:

• 16 months before SOP: 50% of total defects identified

• 11 months before SOP: 90% of total defects identified → 11 months of buffer time remaining

Low process quality organization:

• 8 months before SOP: 50% of total defects identified

• 2 months before SOP: 90% of total defects identified → 10% of defects still unresolved just before production begins

The gap between the two groups in reaching the 90% defect detection milestone is a striking 9 months. This case study clearly demonstrates that process quality has an enormous impact on product quality — and this applies not only to the automotive industry but across all industries.

3. V-Model Life Cycle Process

The V-Model is a software development life cycle (SDLC) model in which the development activities on the left side correspond directly to the testing activities on the right side. It is a model that places strong emphasis on Verification and Validation (V&V), and is also named after the initials of these two concepts.

[Reference] Concepts of Verification and Validation

• Verification: Confirming that the product conforms to its specifications, requirements, and design specs. "Are we building the product right?"

• Validation: Confirming that the product meets the user's intended use and purpose. "Are we building the right product?"

Example: Testing an electric vehicle against its technical specifications is Verification; evaluating it from the actual end user's perspective is Validation.

[Reference] V&V Techniques

V&V techniques are broadly divided into Static methods and Dynamic methods.

• Static methods: Techniques for finding defects without executing the program.

  • Review: Document and code reviews (e.g., peer review, walkthrough, inspection)

  • Analysis: Static code analysis, formal methods, etc.

• Dynamic methods: Techniques for finding defects by actually executing the program.

  • Testing: Black-box testing, white-box testing, etc.

Development–Test Correspondence in the V-Model

• Customer/User Requirements ↔ Acceptance Testing (AT)

• Requirements Analysis ↔ System Testing (ST)

• Architectural Design ↔ Integration Testing (IT)

• Detailed Design ↔ Unit Testing (UT)

• Implementation (coding) → Execute tests sequentially, starting from Unit Testing

It is important to note that this correspondence does not mean "run the tests as soon as each development phase is complete." Rather, as each development phase progresses, the corresponding test planning activities — including test procedures, test approaches, environment setup, and test case development — are carried out in parallel. The actual test execution begins after the code is implemented and proceeds in the order: Unit Testing → Integration Testing → System Testing → Acceptance Testing.

Advantages of the V-Model

• Improved quality of work products: By applying static methods such as reviews and analysis, defects in requirements documents, architecture documents, and code can be identified before execution, improving the overall quality of all work products.

• Shorter schedule through parallel development and test planning: Running development and test planning in parallel fosters close communication between teams. As the quality of upstream work products improves, the workload in downstream phases is reduced — leading to an overall shorter project schedule.

2️⃣ Process Overview

1. Definition and Role of a Process

In general terms, a process defines the steps, sequences, and procedures for carrying out a piece of work. That is the dictionary definition. But when we look at the role a process actually plays, we can see something more specific.

A process exists so that we can systematically create products; such as vehicles, systems, components, or software - that satisfy customer requirements, including functional requirements, non-functional requirements, and constraints. What does it take to do work well? Work proceeds systematically when procedures and methods, tools and equipment, and personnel are properly integrated. A process can therefore be defined as "the means of integrating procedures/methods, tools/equipment, and personnel in order to build a product that satisfies customer requirements."

Consider a waste sorting facility as an example. When a garbage truck arrives and workers need to sort plastics, aluminum, and paper efficiently, they need defined procedures, equipment set up for efficient sorting, and clearly assigned personnel. When all of these elements work together naturally, the sorting operation runs smoothly. In the same way, a process acts as the glue that integrates procedures, methods, tools, equipment, and people so that work can be done well. The role of a process is significant.

2. Defining a Plan Means Defining a Process

Defining a process and creating a plan are essentially the same thing. Planning is not simply about writing a to-do list — it includes defining the process itself. In other words, a plan must define more than just a schedule. A process binds together procedures, methods, tools, equipment, systems, and personnel. The same applies when planning. To perform testing effectively, you need applicable methods and procedures, systems and equipment for efficiency, and personnel assigned to the right roles. Only when all of these elements are properly in place does the work proceed smoothly.

In short, planning is not merely a to-do list — it is the act of defining a process, and a process-driven plan is what truly matters.

[Reference] How to Define a Process: ETVX

ETVX is a framework for systematically defining the activities to be performed at each stage of a process. The acronym stands for:

• Entry Criteria: The conditions that must be met before a task can begin — the entry gate for starting the work.

• Task: The detailed activities to be performed and the steps in which they are carried out.

• Verification: The criteria for verifying that the work in progress is being done correctly — a mid-process quality check.

• eXit Criteria: The conditions that must be satisfied for the work to be considered complete — the final completion gate.

ETVX can be applied to each phase of software development, including requirements development, design/implementation, and testing. Here is an example of how ETVX is applied to the software requirements development process in practice.

• Process: Software Requirements Development

• Purpose: Analyze customer and system requirements to develop software requirements.

Applying ETVX:

• Entry Criteria: Customer requirements and system requirements analysis results are delivered as inputs.

• Task: Analyze, specify, and review the software requirements.

• Verification: Check that customer and system requirements are properly reflected in the software requirements. Confirm that an objective review of the software requirements has been conducted.

• eXit Criteria: System requirements must be fully converted into software requirements, and the software requirements review must be completed with no outstanding issues.

In addition to the ETVX steps, a process definition also includes Tools, Methods, and Roles — because a process encompasses not just procedures but also tools, equipment, and personnel.

• Tools: Requirements modeling tools, requirements management systems.

• Methods: Stakeholder interviews (using checklists), inspection-based reviews.

• Roles: Requirements analysis → performed by the requirements engineer; requirements specification → performed by the requirements engineer; requirements review → performed by reviewers such as the architect and tester.

By defining procedures, methods, tools, equipment, and personnel within the ETVX framework, teams can clearly understand each process and apply the right approach at every stage. This framework is widely used in industry and is well worth knowing.

3️⃣ Test Overview

1. Definition of Testing

Let's look at some of the most widely referenced definitions of software testing.

Myers defines testing as "the process of executing a program with the intent of finding defects." This definition emphasizes that the fundamental purpose of testing is defect detection.

Craig and Jaskiel define testing as "a lifecycle process that engineers, uses, and maintains testware in order to measure and improve the quality of the software being tested." Here, testware refers to the various work products and tools produced during the planning and design of testing activities. In other words, this definition frames testing as the systematic and engineering-based application of testware to measure and improve how well a software product satisfies both stated and implied customer requirements.

IEEE Std 829 defines testing as "the process of analyzing a software item to detect the differences between existing and required conditions and to evaluate the features of the software item." This definition focuses on identifying the gap between the expected behavior of a system and its actual behavior under defect, error, or bug conditions.

While these definitions vary in focus, they share a common goal: to find as many defects and bugs as possible — before the software is released. Once code is complete, it undergoes a series of test levels including Unit Testing, Integration Testing, System Testing, and Acceptance Testing, with various techniques applied at each level. Since defects discovered after deployment or production cause far greater quality issues, the priority is early defect detection across multiple perspectives before release.

2. The Test Process from a PDCA Perspective

As discussed in the context of the V-Model, actual test execution only becomes possible once the code has been implemented. However, the preparation that takes place before execution is equally critical. The test process as a whole follows the PDCA cycle.

Plan — Test Planning

The overall test plan is established and the features to be tested are identified. This phase covers planning activities such as defining the test schedule, test scope, test items, test strategy, and test environment. In the V-Model, test planning runs in parallel with the development phases — customer/user requirements, requirements analysis, architectural design, and detailed design — with corresponding test plans being prepared alongside each. Close communication and collaboration between the development team (left side of the V) and the test team (right side of the V) is the core concept of the V-Model.

Plan — Test Design

Based on the test plan, test cases are developed and test procedures are defined. The test environment is also prepared to replicate real-world usage conditions. For example, in automotive software development, this would mean setting up an environment that reflects actual road conditions.

Do — Test Execution

The prepared test cases are executed and the actual results are compared against expected results to produce a pass/fail verdict.

Check / Act — Test Evaluation and Improvement

Test results are analyzed and evaluated. Progress is monitored and controlled against the test plan, corrective actions are taken when issues arise, and the test process itself is continuously improved.

In summary, testing is not simply the act of execution (Do). The full test process encompasses the entire PDCA cycle — planning, design, execution, and evaluation/improvement — and this is an important point to keep in mind.

[Reference] ISO/IEC/IEEE 29119 Software Testing Standard

An internationally recognized standard for software testing exists in the form of ISO/IEC/IEEE 29119. The standard is structured as follows:

• Part 1 — Concepts and Vocabulary: Defines common concepts and terminology used in software testing.

• Part 2 — Test Processes: Defines the framework for software test processes.

• Part 3 — Test Documentation: Defines requirements for test work products and documentation.

• Part 4 — Test Techniques: Defines test design techniques applicable to software testing.

• Part 5 — Keyword-Driven Testing: Covers test automation through the use of keyword-driven test scripts.

The standard defines the test process using a multi-layer architecture consisting of three levels:

1) Organizational Test Process

At the organizational level, the Test Policy and Test Strategy are established. These are then passed down to the project level, where they serve as the governing framework for all test activities.

2) Test Management Process

This process operates at the project level and manages testing across different test levels and types — including Unit, Integration, Performance, and Security Testing. It defines a series of activities: test planning, test monitoring and control, and test completion.

3) Dynamic Test Process

This is the process by which testing is actually carried out. It consists of a series of activities including test design and implementation, test environment setup and maintenance, test execution, and test results reporting.

This standard provides an internationally agreed-upon framework for establishing and operating a systematic test process, and is widely referenced in industry practice.

2️⃣ Development and characteristics of operating systems
3️⃣ Establishing a practical environment

1️⃣ Concept and role of operating system

Definition of an Operating System

The core software that coordinates all operations between the user and hardware

5 Key Roles

• Intermediary between the user and hardware

• Controls and manages the execution of applications

• Allocates and manages computer resources

• Provides input/output control and data management services

• Provides an abstracted execution environment that hides the details of hardware

2. Computer System Structure

User (Human, device, other computer)
  ↕
Software (Operating System) ← Core
  ↕
Hardware (CPU, memory, storage, I/O device)

These layers can never be skipped.

3. Main Roles of the OS (3 Roles)

4. Goals of OS Development (3 Goals)

• Convenience; Hides complex hardware and provides intuitive interfaces (mouse, touch) → Accessible to everyone

• Efficiency; Manages resources in a balanced, waste-free manner → Higher throughput, faster response, stable operation

• Improved Control Services; Stably controls I/O devices and system state in multi-user and multi-program environments

Main Functions of the OS (7 Functions)

① Memory Management

• Manages RAM allocation and reclamation when programs are executed

• Memory is volatile → All data is lost when power is turned off

② Secondary Storage Management

• Stores data on SSDs and HDDs (non-volatile, large capacity but slow)

• Loads only what is needed into main memory, and moves the rest back to storage

• Always works in conjunction with memory management

③ Process Management

• Manages running programs as individual process units

• Divides CPU time into small slices and distributes them to each process

• Prevents resource monopolization and conflicts

④ Input/Output Device Management

• Abstracts the differences between diverse devices such as keyboards, mice, and printers

• Standardizes I/O so that programs can interact with all devices in a uniform way

• Prevents conflicts during simultaneous requests and handles them efficiently

⑤ File (Data) Management

• Systematically stores and manages documents, photos, executables, and other files

• Prevents file corruption even when multiple users or programs access the same file

⑥ System Protection (User Access Control)

• Defines and manages permissions for who can do what

• Protects the system from malicious access and faulty programs

⑦ Networking and Command Interpreter

• Manages external communication such as internet access and file transfers

• Translates command-line inputs and button clicks into actual system operations

One-line Summary: An operating system is the core software that makes computers convenient for users, efficient for the system, and stable for the overall environment.

2️⃣ Development and characteristics of operating systems

💡 Development Process of Operation System

Why Did Operating Systems Become Necessary?

In the early days of computing, humans managed everything directly. There were two core problems: setting up tasks and handling input/output took far too long, and since the CPU was fast while I/O was slow, the CPU was constantly sitting idle. In trying to solve this inefficiency, an automated management system — the operating system — was born.

The Evolution of Operating Systems

💡Three Major Types of Operating Systems

• Batch Processing OS: Collects jobs and processes them in order. Automation achieved, but CPU efficiency remained low

• Time-Sharing OS: Divides CPU time into tiny slices and alternates between tasks → fast response times, multi-user support

• Distributed OS: Connects multiple computers via a network to operate as a single system → improved performance and reliability, the foundation of cloud computing

💡What Is OS Structure?

OS structure refers to how the functions of an operating system are internally organized and designed. It is not about describing what the OS does on the surface, but rather how it is architected on the inside. The central concept is the kernel, which is responsible for managing core resources such as the CPU and memory, with various services arranged around it. In short, the difference in OS structure comes down to how functions are arranged and separated within the system.

🤔Why Is OS Structure Necessary?

There are two main reasons why a defined operating system structure is needed.

• Functional Complexity: Early operating systems had relatively little to do, but today's OS is responsible for processor management, file protection, network handling, and much more. Implementing all of these functions without any structured design would make the system nearly impossible to maintain.

• Structure Determines Outcomes: Even with the same set of functions, the choice of structure directly affects the system's performance, stability, extensibility, and maintainability. A poorly designed structure means that modifying a single function could impact the entire system, whereas a well-designed structure allows only the necessary parts to be updated without broader side effects.

Four Types of OS Structure

There are four main types of OS structure, each designed differently depending on its purpose and use environment.

1) Monolithic Structure

The earliest and simplest form of OS structure. All operating system functions run within a single kernel space, meaning nothing is separated — everything is packed together in one place. Functions within the kernel call each other directly with no intermediate steps, which makes processing very fast with minimal overhead. However, the dependency between functions is extremely high, meaning a problem in one area can spread to the entire system, making it difficult to maintain and debug. In short: fast, but risky. Early UNIX and MS-DOS were built on this structure.

Looking at the structure from the top down, users sit at the very top, followed by user programs such as shells, compilers, and system libraries. When these user programs make a request, they enter the kernel through a system call. Inside the kernel, all functions; including the file system, processor scheduling, memory management, and I/O management; are packed together within a single kernel space. In this structure, the kernel knows everything and manages everything directly.

However, the dependency between functions is extremely high, meaning a problem in one area can spread to the entire system, making maintenance difficult. The larger the structure grows, the harder it becomes to manage. Ultimately, the monolithic structure is one that gains fast performance by placing all functions into a single kernel, but at the cost of safety and maintainability

2) Modular Structure

Born from the question: "What if we kept the monolithic base but managed functions as separate, interchangeable parts?" The modular structure maintains the monolithic foundation but separates functions into independent modules that can be dynamically loaded or removed as needed; much like plugging in or unplugging components. Its greatest strength is balance: it preserves the performance of a monolithic structure while significantly improving flexibility and maintainability. The downside is that dependencies between modules must be carefully managed, and loading a faulty module can still affect kernel stability. Modern UNIX-based systems such as Linux and Solaris use this structure.

3) Layered Structure

A structure with a strict top-to-bottom hierarchy. The OS is divided into multiple layers, and each layer can only interact with the layer directly below it — skipping layers is not allowed. This makes it easy to pinpoint exactly which layer a problem occurred in, improving overall stability and debuggability. However, because every request must pass through each layer one by one, the number of calls increases and performance suffers. The rigid rules between layers also make it inflexible when adding new features or modifying existing ones. As a result, while layered structure is easy to understand and well-organized in theory, it is rarely used in commercial operating systems due to its performance limitations. It has been used in educational OS environments such as THE operating system.

Looking at the structure from top to bottom, the layers are stacked as follows. The most important point here is that each layer can only interact with the layer directly below it. Skipping any intermediate layer is strictly impossible. While this structure is very easy to understand, applying it directly to a real operating system places a significant burden in terms of both performance and flexibility. In short, the layered structure is well-suited for understanding and design, but has clear limitations when it comes to real-world performance.

4) Microkernel Structure

Starts from the idea of "leave only the essentials in the kernel." Only the most fundamental functions - process management, memory management, and inter-process communication ; remain in the kernel. Everything else, such as file systems and device management, is moved out to user space. This results in a smaller kernel with significantly improved safety and security. The tradeoff is that the kernel and user space must frequently exchange messages, which introduces some performance overhead. Real-world examples include Mach, MINIX, and QNX — with QNX being widely used in safety-critical fields such as automotive and medical devices. macOS and Windows, on the other hand, use a hybrid structure that incorporates only some microkernel concepts rather than adopting it fully.

The structure can be mapped out as follows. Only the core functions remain in the kernel, while everything else; such as the file system and device management is moved out to user space. Services in user space can only communicate with the kernel through system calls. As a result, the structure is cleanly separated, and even when a problem occurs, its impact does not spread widely across the system. In short, this is a structure that minimizes the kernel in order to maximize stability and extensibility.

🤔Why Do Modern Operating Systems Use a Hybrid Structure?

네, 해당 부분도 한국어 요약과 영어 번역 함께 정리해드립니다!

한국어

왜 현대 운영체제는 혼합 구조인가?

이유는 크게 두 가지입니다.

첫 번째, 구조마다 장단점이 너무 뚜렷하기 때문입니다. 단일 구조는 성능은 좋지만 관리가 어렵고, 마이크로 커널은 안정성은 좋지만 성능이 아쉬우며, 계층 구조는 이해하기는 쉽지만 유연성이 부족합니다. 하나의 구조만으로는 모든 요구를 동시에 만족시키기 어렵습니다.

두 번째, 운영체제에 대한 요구가 너무 많아졌기 때문입니다. 현대 운영체제는 단순히 작동만 하면 되는 수준이 아닙니다. 높은 성능, 안정성과 보안, 다양한 하드웨어 지원, 지속적인 기능 확장까지 모두 요구받습니다. 현실적으로 단 하나의 구조가 이 모든 것을 충족시키기는 불가능에 가깝습니다. 그래서 운영체제는 상황에 맞게 구조를 섞는 방법을 선택하게 되었습니다.

결론적으로 현대 운영체제는 하나의 구조를 고집하지 않고, 여러 구조의 장점을 취하고 단점은 최대한 줄이기 위해 혼합 구조를 사용합니다.

• 리눅스: 모놀리식 구조 기반 + 모듈 구조 결합

• Windows·macOS: 모놀리식 + 마이크로 커널 개념 혼합

핵심 결론: 현대 운영체제는 완벽한 구조를 찾는 것이 아닌, 현실적인 타협을 선택한 결과물이다.

🤔Why Do Modern Operating Systems Use a Hybrid Structure?

There are two main reasons.

First, every structure has clear and distinct trade-offs. The monolithic structure offers great performance but is difficult to manage. The microkernel structure is highly stable but falls short in performance. The layered structure is easy to understand but lacks flexibility. No single structure can realistically satisfy all requirements at the same time.

Second, the demands placed on operating systems have grown enormously. Modern operating systems are no longer expected to simply run; they must deliver high performance, strong stability and security, support for a wide variety of hardware, and continuous feature expansion all at once. It is practically impossible for any single structure to meet all of these demands. As a result, operating systems have chosen to mix structures depending on the situation.

In conclusion, modern operating systems do not commit to a single structure. Instead, they adopt the strengths of multiple structures while minimizing their respective weaknesses through a hybrid approach.

• Linux: Monolithic base + Modular structure combined

• Windows & macOS: Monolithic + Microkernel concepts blended together

Key Takeaway: Modern operating systems are not the result of finding a perfect structure — they are the product of practical compromise.

3️⃣ Establishing a practical environment

💡Virtual Machines

1. What Is a Virtual Machine?

A virtual machine (VM) is a technology that divides the resources of a single physical computer into multiple independent execution environments. Using virtualization software, you can create several virtual computers on one laptop, each running a different operating system just like a real machine. Since each virtual machine operates independently, any problem that occurs inside a VM does not affect the actual host laptop.

2. Why Use Virtual Machines?

Directly installing an operating system on a personal PC can lead to the following problems.

• Incorrect settings can prevent the system from booting or cause system damage

• Once a problem occurs, restoring the original state is difficult

• Switching between multiple operating systems for practice is a significant burden on a personal PC

Virtual machines solve all of these issues. Multiple operating systems can be practiced safely on a single PC, and recovery is easy even if something goes wrong.

3. Host-Based Virtualization

This course uses a host-based virtualization approach, where virtualization software is installed on top of the existing operating system and virtual machines are run within it. This method allows direct installation on a personal PC and easy recovery, making it the most suitable approach for hands-on practice.

The practice workflow is as follows.

Install Virtualization Software → Create Virtual Machine → Install Ubuntu OS

4. Virtualization Software: VirtualBox

This course uses VirtualBox for hands-on practice.

• Advantages: Free to use, relatively simple installation and setup, beginner-friendly

• Note: VirtualBox does not work properly — or at all — on MacBooks with Apple Silicon chips (M1·M2·M3). Students with these devices must use alternative virtualization software.

5. Linux Distribution for Practice: Ubuntu

The operating system to be installed inside the virtual machine is Ubuntu Linux. It was chosen for three reasons.

• Provides a user-friendly interface accessible even to beginners

• Well-supported by learning resources and an active community

• Relatively straightforward to install and use in a virtual machine environment

At the end of this chaper - I was able to install Ubuntu in the VM using VirtualBox! yay.

1️⃣ Hardware Basics

Hardware is anything physical you can touch and feel on a computer. It is divided into three main components: CPU, Memory, and Storage.

The CPU (Central Processing Unit) is like the brain of a computer. It processes all the instructions and is produced by companies such as AMD and Intel.

Memory temporarily stores data that the CPU is currently working with, allowing for fast processing. A common example is RAM. Traditionally, RAM was known as volatile storage — meaning everything is lost when the power is turned off — while storage was non-volatile and could be recovered. However, in recent years, memory that retains data even without power has emerged. For now, the key distinction is whether data remains accessible after the power is cycled on and off.

Storage preserves data even when the power is off, saving files in a permanent format. It is divided into HDD (Hard Disk Drive) and SSD (Solid State Drive).

Other hardware includes input/output devices such as keyboards, monitors, printers, and speakers. There are also network devices like the NIC (Network Interface Card). The NIC gets its name from the first letters of "Network Interface Card." While modern motherboards often have it built in, it was originally a separate card-shaped device, similar in size to a credit card.

2️⃣ Software Basics

Unlike hardware, software has no physical form you can touch. It is divided into four categories: System Software, Operating Systems, Device Drivers, and Application Software — though the boundaries between them are not always clear-cut.

System Software manages the hardware and serves as the foundation for all other software running on the computer.

Operating Systems manage the computer's resources. Common examples include Linux, Windows, Unix, and Android.

Device Drivers are software that operates and manages specific hardware devices. A new driver is added each time a new device is introduced.

Application Software is software that performs specific tasks for the user, such as installing and updating apps.

A Closer Look at Operating Systems

Can a program run without an operating system? The answer is yes! Early computers actually worked this way. Even today, it is still possible through microcontrollers.

So why do we have operating systems? They were developed to help us use and manage computer resources more efficiently. Operating systems didn't always exist — they came about as computers grew more complex and the need for better resource management increased.

Here's the English version continuing the same blog style:

3️⃣Unix - A Closer Look

If you worked with computers in the 20th century, Unix was something you almost certainly had to know. It was the dominant operating system of the time, widely used from the latter half of the 20th century onwards. Back then, Unix made computers available for free or at a very low cost, which helped drive the adoption of operating systems overall.

Unix was developed in 1969 at Bell Labs, a research division of AT&T, the telecommunications company.

How did we get here?

Before Unix, there was a software system called Multics. In the early days of computing, programs were written on a 1:1 basis for each specific machine — completely different from today where the same software can run across many different devices. Every time a new machine came out, developers had to repeat the same work all over again. This made the need for a unified, portable software system very clear.

Key Features of Unix

Time Sharing System Unix introduced the concept of sharing resources and time among multiple users. Think of it like a food delivery app: an Uber driver doesn't just deliver for one customer. They handle multiple orders. Similarly, Unix supports multiple users (multi-user) and multiple processes (multi-processing) running at the same time.

Command Line Interface (CLI) Unlike today's large graphical displays, early technology only allowed users to view and input one line at a time on screen.

Everything is a File In Unix, everything is treated and processed as a file.

Batch Processing Before time sharing, computers used batch processing, where tasks were collected and processed one at a time. When one person's job finished, the next person could use the computer. This was how computers were shared back then.

The introduction of the Time Sharing System changed everything. It allowed user 1, 2, and 3 to all work at the same time, rather than waiting in line. This became the foundation of what we know as the Unix system.

4️⃣Linux - A Quick Look

Linux was first released in 1991 by Linus Benedict Torvalds, starting out based on an operating system called MINIX.

MINIX was originally developed as an educational alternative to the expensive UNIX, making it more accessible for learning purposes. Linux began from MINIX and later expanded by incorporating many of the functional features of UNIX.

During the era when Unix dominated the market, Unix did not provide its source code. Instead, it would install Unix for you, and once you became comfortable using it, the environment practically encouraged you to go work for the company. For students who wanted to learn, it was a very restrictive environment — and for teachers, it was equally difficult to teach something so closed off.

This is the background that gave birth to Linux.

What I find really inspiring is that Linus started Linux as a hobby while he was still a student, through a MINIX class he was taking at the time. As a student myself, I find that really motivating. It's a reminder that great things can start from simply learning and being curious! 🌱

Study Summary

Unix was an operating system developed by inheriting the time sharing concept from Multics. It was a highly scalable system, but eventually lost its market dominance to Linux. Why?

The risks associated with using Unix for free were significant. There was a time when Unix was a mandatory subject at universities, and because of that it was already widely spread with strong technical support. However, when Linux launched in the 1990s, it was completely free to use and had incorporated many of Unix's best features.

Unix kept its source code private, meaning users could only use it as provided without being able to modify it. Linux was the complete opposite — open and accessible. While official technical support for Linux does require payment, most distributions are free to install and use.

1️⃣문자열 매칭 (String Matching)
2️⃣원시적 매칭 (Naive Matching Algorithm)
3️⃣오토마타 이용 매칭 (Automata Theory)
4️⃣라빈-카프 알고리즘(Rabin-Karp Algorithms)
5️⃣KMP 알고리즘과 실패 함수 (KMP Algorithm and Failure Function)
6️⃣보이어-무어 알고리즘(Boyer-Moore Algorithm)

1️⃣문자열 매칭 (String Matching)

문자열 매칭 (String Matching)이란 텍스트 문자열에 주어진 **패턴 문자열 (Pattern)**이 나타나는 위치를 찾아내는 과정을 말한다. 일반적으로 패턴 문자열은 텍스트보다 매우 짧은 경우가 많다.

문자열 매칭 알고리즘은 다양한 분야에서 활용된다.

• 문서 작업: 특정 문자열을 검색하는 알고리즘

• 인터넷 검색: 키워드 검색

• 데이터베이스: 항목 값 비교 또는 검색

• 백신 프로그램: 악성코드 패턴 탐지

2️⃣원시적 매칭 (Naive Matching Algorithm)

원시적 매칭은 텍스트에서 패턴 문자열을 찾기 위해 **순차적으로 하나씩 비교 (Sequential Comparison)**하는 방식이다. 이는 실무에서 거의 사용되지 않지만, 다른 문자열 매칭 알고리즘을 이해하기 위해 기본적으로 알아야 하는 개념이다. 시간 복잡도 (Time Complexity)는 O(mn) 패턴 길이 m, 텍스트 길이 n로 모든 위치를 하나씩 검사하기 때문에 효율이 떨어질 수 있다.

✅ 작동 과정 (How it Works)

1. 첫 번째 위치부터 비교 (Compare from the first position)
   텍스트의 첫 번째 문자부터 패턴의 첫 번째 문자까지 하나씩 비교한다.

   • 매칭에 실패하면 패턴을 한 칸 뒤로 이동한다.

   • 이 과정을 텍스트 끝까지 반복한다.

2. 패턴이 매칭되었을 경우 (When the pattern matches)
   패턴의 모든 문자가 텍스트의 해당 위치에서 일치하면 해당 위치를 출력하게 된다.

✅원시적 매칭의 작동 원리(Principal Work of Native Matching Algorithms)

텍스트: bobycatsoaropt, 패턴: soar

1. 텍스트의 처음부터 soar를 비교:

   • b와 s 비교 → 실패

   • o와 s 비교 → 실패

   • ...

2. 패턴을 한 칸씩 이동하며 비교:

   • s와 s → 성공

   • o와 o → 성공

   • a와 a → 성공

   • r와 r → 성공 (완전 매칭)

💡중요한 포인트 (Key Points)

• 순차적 비교 (Sequential Comparison): 문자 하나씩 비교

• 패턴 이동 (Pattern Shift): 매칭 실패 시 한 칸 이동

• 응용 분야 (Applications): 인터넷 검색, 데이터베이스 검색, 백신 프로그램 등

• 단점 (Disadvantages): 시간 복잡도가 높아 대규모 데이터에는 비효율적

원시적 매칭 의사코드 (Pseudocode for Naive String Matching Algorithm)

• 텍스트 탐색 범위 설정 (Set search range in text):

  • 반복문은 i = 1부터 i = n−m + 1까지 진행된다.

  • 이는 패턴의 길이 m만큼 텍스트에서 잘라 비교할 수 있도록 범위를 제한하는 것이다.

• 비교 조건 (Comparison condition):

  • 현재 텍스트의 i번째부터 i + m − 1 번째까지의 문자열을 패턴과 비교한다.

  • 모든 문자가 동일할 경우 매칭이 발견된다.

• 시간 복잡도 (Time Complexity):

  • n은 텍스트의 길이, m은 패턴의 길이로, 최악의 경우 O(mn)만큼의 연산이 필요하다.

💡중요한 포인트 (Key Points)

• 탐색 범위 조정 (Adjust search range): 패턴이 텍스트 끝을 초과하지 않도록 n−m+1 까지만 탐색

• 조건 검사 (Condition check): 텍스트의 특정 부분이 패턴과 동일한지 비교

• 시간 복잡도 (Complexity): 비효율적이지만 개념 이해에 중요

원시적 매칭의 비효율적인 사례 (Inefficiency of Naive String Matching)

💡요약: 원시적 문자열 매칭은 순차적으로 모든 위치에서 비교하기 때문에, 특히 패턴의 대부분이 매칭되다가 마지막에 불일치가 일어나는 경우, 이미 비교한 부분까지 모두 반복해야 하므로 비효율적이다. 이러한 문제를 개선하기 위해 패턴 문자열의 앞부분과 뒷부분의 일치 여부를 활용하는 고급 알고리즘이 필요하다.

• 1번째 시도: abcdabcd는 매칭되지만 d와 w에서 불일치 발생.

• 2번째 시도: 패턴을 한 칸 이동, 처음부터 다시 비교 → 실패.

• 3~4번째 시도: 반복적으로 비교 → 실패.

• 5번째 시도: 최종적으로 완전한 매칭 성공

• 이 과정에서 이미 일치했던 abc를 계속 비교하며 연산이 낭비된다 (파란색 박스)

✅ 비효율적인 사례 설명 (Example of Inefficiency):

• 패턴 문자열과 텍스트의 일부가 매칭되더라도, 마지막 문자에서 불일치가 발생하면 앞서 비교했던 모든 연산이 무의미해진다.

• 텍스트에서 패턴을 한 칸씩 이동하며 처음부터 다시 비교를 시작해야 한다.

✅ 첨부 예제와 연결된 설명 (Example Analysis):

• 텍스트 (Text): ...abcdabcdabcwz, 패턴 (Pattern): abcdabcwz

✅문제점 (Problem): 매칭 실패 시 매번 처음부터 다시 비교하고 불필요한 연산이 많아 시간 효율성이 떨어진다.

💡 중요한 포인트 (Key Points)

• 마지막 문자 불일치 (Mismatch at the last character): 불필요한 반복 연산 발생.

• 패턴의 앞/뒤 일치 정보 활용 (Use pattern prefix/suffix): 효율적인 매칭 가능.

• 비효율성의 해결 (Resolving inefficiency): 오토마타(automata)이용 매칭

3️⃣오토마타 이론 (Automata Theory)

오토마타는 수학적이고 추상적인 기계로, 현재 상태를 기반으로 입력에 따라 상태를 변화시키며 출력을 생성한다. 이는 컴퓨터 과학에서 알고리즘과 문제를 해결하는 데 매우 유용하며, 문자열 매칭에서도 활용될 수 있다.

✅ 오토마타 이론이란? (What is Automata Theory)

• 어원 (Etymology): 오토 (Auto): 자동, 마토 (Mata): 기계

• 정의 (Definition): 오토마타는 문제를 해결하기 위해 유한한 상태를 정의하고, 특정 규칙에 따라 상태를 전환하며 출력을 생성하는 **추상적 기계 (Abstract Machine)**이다. 이는 실제 컴퓨터가 아닌 수학적으로 모델링된 개념이다.

✅오토마타의 예(Example of Automata Theory)

현재 컴퓨터의 상태와 입력에 따라 생성되는 결과가 정의되어 있고 특정규칙에 따라 출력 결과가 달라지는 오토마타 이론의 좋은 예제이다.

• 상태 (States):

  1. off 상태

  2. 절전 상태

  3. on 상태

• 전이 (Transitions):

  • 전원 스위치를 켜면 off → 절전 상태

  • 입력(키보드/마우스)이 있으면 절전 상태 → on 상태

  • 일정 시간 입력이 없으면 on 상태 → 절전 상태

  • 전원 스위치를 끄면 모든 상태에서 off 상태로 복귀

✅ 원시적 매칭과 오토마타 이용 매칭 비교(Comparison of Naive Matching and Automata-Based Matching)

1. 원시적 매칭 vs. 오토마타 이용 매칭 (Naive Matching vs. Automata-Based Matching):

   • 원시적 매칭은 패턴의 문맥을 고려하지 않아 불필요한 연산이 많다.

   • 오토마타는 상태와 문맥을 활용하여 효율적으로 비교 연산을 줄이게 된다.

오토마타 이론 #1: 구성요소 (Components of Automata)

오토마타는 아래 5가지 구성 요소로 정의된다:

1. Q (상태 집합, Set of states): 시스템이 가질 수 있는 모든 상태의 집합.

2. q₀ (시작 상태, Initial state): 입력 처리를 시작하는 초기 상태.

3. A (목표 상태의 집합, Set of accept states): 입력을 받아들이는 종료 상태(들).

4. Σ (입력 알파벳, Input alphabet): 시스템이 처리할 수 있는 입력의 집합.

5. δ (상태 전이 함수, Transition function): 특정 상태에서 특정 입력을 받을 때 이동할 다음 상태를 정의하는 함수.

오토마타 이론 #2: 상태 전이 함수 다이어그램 표현(Example of Transition Function Diagram)

1. 시작 상태 (State 0):

   • 아무 문자도 처리하지 않은 초기 상태이다.

   • 첫 번째 입력이 a라면 상태 1로 이동한다.

2. 상태 1:

   • 입력이 b라면 상태 2로 이동한다.

   • 만약 다른 문자가 오면 상태 0으로 돌아간다.

   • 이유: 패턴이 ababaca로 시작하므로 b가 와야 다음으로 진행된다.

3. 상태 2 → 상태 6:

   • 올바른 입력이 계속되면 상태가 차례로 증가하게 된다.
     예: 상태 2에서 a → 상태 3, 상태 3에서 b → 상태 4...

4. 상태 7:

   • 입력된 문자가 ababaca와 완전히 매칭되면 최종 상태 7에 도달한다.

   • 이는 패턴을 성공적으로 찾았다는 뜻이다.

5. 잘못된 입력 처리:

   • 예: 상태 5에서 b가 오면 전 단계 상태 4로 되돌아간다.

   • 이는 이미 매칭된 일부 정보를 재사용하여 불필요한 비교를 줄이기 위함이다.

   • 원시적 매칭이었다면 처음부터 돌아가지만 오토마타는 중간 단계로 이동하기 때문에 비교연산을 줄일 수 있는 것이다.

상태 전이 함수는 위에서 언급된 예제처럼 다이어그램도 표시할 수 있고 이번 예제와 같이 테이블로도 구성할 수 있다.

오토마타 #2: 상태 전이 함수 테이블 구성 (Automata Transition Function Table Representation)

✅ 상태 전이 함수란? (What is Transition Function): 상태 전이 함수는 현재 상태에서 입력 문자를 기반으로 다음 상태를 결정한다.

• 예: 상태 0에서 입력이 a이면 상태 1로 이동.

• 이는 문자열 매칭 과정을 구조적으로 표현하는 방법이다.

✅ 테이블 구성 (Table Representation): 상태 전이 다이어그램을 테이블 형태로 변환한다.

• 행 (Row): 현재 상태.

• 열 (Column): 입력 문자.

• 값 (Value): 다음 상태.

1. 왼쪽 기본 테이블 (Full Table): 모든 알파벳에 대해 상태를 정의한다.

2. 압축된 테이블 (Compressed Table): 패턴에 등장하는 문자(a, b, c)만 고려하고, 나머지 문자(기타)는 한 열로 압축하여 테이블을 단순화하고 시간을 절약하였다.

💡중요포인트:

• 기존 방식: 모든 알파벳에 대해 상태를 정의 → 테이블이 복잡

• 개선 방식: 패턴에 등장하는 문자만 고려 → 테이블이 단순화되고 연산 효율 증가

오토마타 #3: 의사코드 표현 (Pseudocode in Automata)

오토마타를 활용해 문자열 매칭을 수행하는 과정을 의사코드로 확인해보자.

δ(delta) 오토마타에서 상태 전이 함수 (Transition Function)를 의미한다. 오토마타가 현재 상태에서 특정 입력을 받았을 때 어디로 이동해야 하는지를 결정하는 역할을 한다.

• δ(delta) 그리스 문자의 이름으로, 수학과 컴퓨터 과학에서 함수나 변화(transition)를 나타낼 때 자주 사용한다.

FA-Matcher (A[], δ[][], f):
▷ f : 목표 상태 (Final state), 
▷ n : 텍스트 A의 길이, 
▷ m : 패턴 길이

q ← 0  ▷ q는 현재 상태를 나타냄

for i ← 1 to n:  ▷ 텍스트의 각 문자를 처리
    q ← δ(q, A[i])  ▷ 현재 상태와 입력 문자에 따라 상태 전이
    if (q = f):  ▷ 현재 상태가 최종 상태라면
        A[i - m + 1]에서 매칭이 발생했음을 알린다.

1. 변수 정의 (Variables):

   • q: **현재 상태 (Current state)**를 나타낸다. 시작 상태는 0이다.

   • δ: **상태 전이 함수 (Transition function)**이다. 현재 상태와 입력 문자에 따라 다음 상태를 반환한다.

   • f: **최종 상태 (Final state)**로, 패턴 매칭이 완료되었음을 나타낸다.

2. 작동 과정 (How It Works):

   • q ← 0: 시작 상태에서 시작한다.

   • for 루프는 텍스트의 각 문자를 차례로 처리한다.

   • q ← δ (q, A[i]): 현재 상태와 입력 문자 A[i]를 상태 전이 함수에 넣어 다음 상태로 이동한다.

   • if (q = f): 현재 상태가 최종 상태에 도달하면 매칭이 발생했음을 출력한다.

     • 매칭이 발생한 위치는 i − m+1 이다.

오토마타 #4: 수행 시간 분석 (Time Complexity of String Matching Using Automata)

오토마타를 이용한 문자열 매칭의 수행 시간은 크게 두 부분으로 나눌 수 있다:

1. 매칭 수행 시간: 텍스트의 길이에 비례.

2. 오토마타 상태 전이 함수 준비 시간: 패턴과 알파벳 크기에 비례.

✅ 매칭 수행 시간 (Matching Time)

• for 루프: 텍스트의 각 문자에 대해 한 번씩 상태 전이를 수행 → O(n)

• 상태 전이 함수 실행: 한 번의 전이가 O(1)이므로 효율적.

• 매칭 수행 시간은 텍스트의 길이 n에 선형적으로 비례합니다.

✅상태 전이 함수 준비 시간 (Setup Time for Transition Function)

• 입력 알파벳의 개수: ∣Σ∣ 사용 가능한 문자(예: 영어 소문자 26개).

• 패턴 길이: m

• 준비 시간: O(∣Σ∣m) 모든 문자와 패턴의 길이에 대해 전이 상태를 정의.

✅총 수행 시간: Θ(n+∣Σ∣m)

• n: 텍스트의 길이

✅예제 수행 시간 계산 (Example Calculation)

• 입력 데이터:

  • 텍스트 길이 n=1000

  • 패턴 길이 m=10

  • 알파벳 크기 ∣Σ∣=26

• 계산:

  • 매칭 수행 시간: O(n) = O(1000)

  • 상태 전이 함수 준비 시간: O(∣Σ∣m) = O(26⋅10) = O(260).

  • 총 수행 시간: O(1000+260) = O(1260)

💡중요포인트:

• 오토마타 기반 매칭은 텍스트 길이에 선형적으로 비례하여 효율적이다.

• 상태 전이 함수 준비 시간이 추가로 필요하지만, 이는 매칭 단계의 효율성을 보장하는 투자이다.

• 입력 데이터의 특성(텍스트 길이, 패턴 길이, 알파벳 크기)에 따라 성능이 결정된다.

4️⃣라빈 - 카프 알고리즘(Rabin-Karp Algorithms)

문자열 매칭 알고리즘으로 라빈 카프 알고리즘에 대해서 배워본다. 문자열 패턴을 숫자로 변환하여 비교하는 효율적인 알고리즘이다.

• 라빈 카프 알고리즘(Rabin-Karp Algorithms): 가능한 문자들에 대해 숫자를 대응하고 패턴을 하나의 진수로 표현해서 만약 121 이라는 숫자가 있을 때, 문자로 하면 3개의 문자가 되듯이, 어떤 문자의 패턴이 있을때 그것을 각각의 문자로 할당해서 진수 표현하는 것이다. 이것을 “수치화 과정”이라고 한다.

• 수치화 (Numerical Transformation): 문자열의 각 문자를 숫자로 매핑하고, 해당 숫자를 특정 진수(base)로 표현하여 문자열을 숫자로 변환하는 과정

• 이 과정을 통해 빠르게 문자열의 패턴을 비교할 수 있게 된다.

✅수치화의 예 (Example of Numerical Transformation)

주어진 데이터: 알파벳 집합 Σ={a,b,c,d,e}, 크기 ∣Σ∣=5

• 매핑: a=0, b=1, c=2, d=3, e=4

• 진수로 변환:

  • c = 2⋅5^2 : 2×25 = 50

  • a = 0 ⋅ 5^1 : 0×5 = 0

  • d = 3 ⋅ 5^0 : 3×1 = 3

• 합산:

  • 50 + 0 + 3 = 53

💡라빈-카프 알고리즘의 중요포인트

• 문자열을 숫자로 변환하여, 숫자 비교로 문자열 패턴 매칭을 수행한다.

• 효율성: 숫자 비교는 문자열 비교보다 빠르며, 해시 값을 이용하여 중복 계산을 줄일 수 있게된다.

✅수치화 계산 방법 기본 개념 (Basic Numerical Calculation)

문자를 숫자로 변환 (Mapping Characters to Numbers): 문자열의 각 문자를 고유한 숫자로 매핑한다.

진수로 표현 (Representing in Base ddd): 문자열의 각 문자를 진수 기반으로 표현하여 수치화한다.

• 예) 10진수(기본 진수 d=10)를 사용하여 P[m] 다음과 같이 표현:

• p=P[m] + 10⋅P[m−1] + 102⋅P[m−2] + ⋯ + 10m−1⋅P[1]

  • P[1]: 가장 왼쪽 문자 → 가장 큰 자리수.

  • P[m]: 가장 오른쪽 문자 → 가장 작은 자리수.

일반적인 계산 방식 (Basic Calculation): 텍스트에서 부분 문자열 A[i⋯i+m−1]를 수치화하는 계산:

• 시간 복잡도 O(m): 각 문자마다 10을 곱하면서 반복 계산.

• 전체 텍스트에 대해 비교: n개의 부분 문자열에 대해 계산 → 총 O(mn)

  • 문제점: 원시적 매칭과 성능 차이가 없음.

✅수치화 계산의 개선 방법 (Optimization in Calculation)

• 점화식 사용 (Using Recursive Formula):

• 이전 계산값 ai−1을 재활용하여 다음 값 ai를 계산에 활용한다.

• 첫 번째 문자 영향 제거: −10m−1 ⋅ A[i−1]

• 새로운 문자 추가: +A[i + m−1]

💡🤔최적화 효과가 있을까? 그렇다.

• 각 부분 문자열 계산이 O(1)로 줄어듦.

• 전체 텍스트 비교 시간: O(n)

• 미리 계산된 10m−1는 반복 사용 가능.

💡중요 포인트:

1. 수치화 개념 (Numerical Transformation): 문자열을 숫자로 변환해 효율적으로 비교한다.

2. 기본 계산 방식의 한계 (Limitations of Basic Calculation): 시간 복잡도 O(mn)으로 원시적 매칭과 동일한 점

3. 점화식을 통한 개선 (Optimization Using Recursive Formula): 이전 계산값을 활용하여 불필요한 연산 제거한다. O(n)시간 복잡도로 최적화하였다.

4. 효율성 (Efficiency): 덧셈과 곱셈 각각 2회로 계산 가능 → 이뜻은 실행 속도가 대폭 증가되었다는 뜻이다.

✅라빈-카프 알고리즘 수치화를 이용한 매칭 예제 (Example of Matching Using Numerical Transformation in the Rabin-Karp Algorithm)

💡 요약 (Summary)

1. 수치화 계산 방법 (Numerical Calculation):

   • 문자열의 각 문자를 진수로 변환하여 수치값을 계산한다.

   • P[]: 패턴 문자열 → 고유 수치값 계산.

   • A[]: 텍스트의 부분 문자열 → 고유 수치값 계산 후 패턴과 비교.

2. 점화식을 사용한 계산 (Using Recursive Formula):

   • 이전 계산값을 활용해 현재 값을 효율적으로 계산한다.

   • 수치값이 같으면 문자열 매칭 성공하였다는 뜻이다

3. 효율성: 점화식을 통해 한 칸씩 이동하며 효율적으로 비교할 수 있다.

❤️ P[] 패턴 문자열의 수치화 (Numerical Transformation of Pattern): eeaab

• 각 문자에 고유한 값을 부여한다. e=4, a=0, b=1

• e=4, 5^4=625, a = 0, b = 1 결과: p=300

❤️A[] 텍스트 문자열의 수치화 (Numerical Transformation of Text): acebb

• 처음 5개의 문자를 가져와 수치 계산.

• 결과: a1 = 356

• 매칭 실패 (Does not match p = 3001)

❤️문자열의 수치화 대신 점화식을 사용한 효율적 계산 (Efficient Calculation Using Recursive Formula)

• ai−1​: 이전 계산값.

• 5m−1⋅A[i−1]: 빠지는 첫 번째 문자.

• A[i+m−1]: 추가되는 마지막 문자.

❤️ 계산 과정 (Calculation Process)

a2​: cebbc

• 결과: a2 = 1782

• 매칭 실패 (Does not match p=3001).

a3​: ebbce

• 결과: a3 = 2664

• 매칭 실패 (Does not match p=3001).

a7: eeaab

• 결과: a7 = 3001

• 매칭 성공 (Matches p=3001).

💡중요한 포인트 (Key Points)

1. 수치화의 효율성 (Efficiency of Numerical Transformation):

   • 점화식을 통해 이전 계산값을 재활용한다.

   • 계산 복잡도를 O(mn)에서 O(n)으로 줄였다.

2. 정확성 (Accuracy):

   • 동일한 문자열은 동일한 수치값을 가진다.

   • 수치값이 일치하면 문자열 매칭 성공하게 된다.

3. 효율적 매칭 (Efficient Matching):

   • 한 칸씩 이동하며 계산 → 빠르고 정확한 비교가 가능하다.

💡왜 수치화를 하는 걸까? (Why Use Numerical Transformation?)

문자열 비교는 한 문자씩 순서대로 확인해야 하므로 시간이 오래 걸리게 된다.
라빈-카프는 문자열을 숫자로 변환하고 숫자끼리 비교하므로 더 빠르게 매칭 여부를 확인할 수 있다.

✅라빈-카프 알고리즘 수치화를 이용한 의사코드 표현 (Pseudocode for Rabin-Karp Algorithm Using Numerical Transformation)

💡요약: 아래 예제 코드는 **패턴 문자열 P[]**를 텍스트 문자열 A[]에서 찾아내는 과정을 보여준다. 문자열을 숫자로 변환(수치화)하고, 이 숫자값을 비교하여 매칭 여부를 확인한다.

1. 초기화 (Initialization)

p ← 0; a₁ ← 0

• p: 패턴 문자열 P[]의 수치값을 저장하는 변수이다.

• a₁: 텍스트의 첫 번째 부분 문자열의 수치값을 저장하는 변수이다.

2. 패턴과 첫 번째 부분 문자열의 수치값 계산

for i ← 1 to m:
    p ← d * p + P[i]
    a₁ ← d * a₁ + A[i]

• i: 현재 패턴과 텍스트의 문자를 계산하는 위치.

• 패턴 수치값 계산:

  • p = d⋅p+P[i] : 기존 값에 d를 곱하고 현재 문자의 값을 더한다.

  • 예: eeaab → p = 4⋅5^4 + 4⋅5^3 + 0⋅5^2 + 0⋅5^1 + 1⋅5^0 = 3001

• 첫 번째 텍스트 부분 문자열 수치값 계산: a1 = d⋅a1+A[i]

  • 예: acebb → a1 = 0⋅5^4 + 2⋅5^3 + 4⋅5^2 + 1⋅5^1 + 1⋅5^0 = 356

3. 나머지 부분 문자열의 수치값 계산 (점화식 사용)

for i ← 1 to n - m + 1:
    if (i ≠ 1):
        aᵢ ← d * (aᵢ₋₁ - dᵐ⁻¹ * A[i-1]) + A[i+m-1]

• i≠1: 두 번째 부분 문자열부터 계산한다.

• 점화식 설명:

  • aᵢ: 새로운 부분 문자열의 수치값.

  • aᵢ₋₁​: 이전 부분 문자열의 수치값.

  • dm−1: 패턴 길이에 따라 계산된 상수.

  • A[i−1]: 빠지는 문자.

  • A[i+m−1]: 추가되는 문자.

예제 계산:

• a1 = 356

• a2 = 5⋅(a1−0⋅625)+2 = 1782

• a3 = 5⋅(a2−2⋅625)+4 = 2664

4. 매칭 여부 확인

if (p = aᵢ): A[i] 자리에서 매칭이 되었음을 알린다.

• 패턴의 수치값 p와 현재 부분 문자열의 수치값 aᵢ​를 비교.

• 값이 같다면 패턴이 텍스트의 해당 위치에서 매칭됨을 의미.

예제:

• 패턴 p=3001

• a₇ = 3001 → 매칭 성공

💡중요포인트

1. 수치화: 문자열을 숫자로 변환하여 비교한다.

2. 점화식: 이전 계산값을 재활용해 효율적 계산을 한다.

3. 매칭 성공 조건: 패턴 수치값 p와 부분 문자열 수치값 aᵢ​가 같으면 매칭이 성공된다.

4. 효율성: 반복 계산을 줄이고 O(n) 시간 안에 패턴 매칭을 완료한다.

✅라빈-카프 알고리즘 수치화를 이용한 매칭의 문제점

💡요약: 문자열 패턴과 텍스트의 수치화 과정에서 계산 결과가 너무 커져 **오버플로우 (Overflow)**가 발생할 수 있다. 이를 해결하기 위해 **모듈러 연산 (Modulo operation)**을 사용하여 값을 제한한다.

• 라빈-카프 알고리즘 (Rabin-Karp Algorithm):

  • 문자열 패턴과 텍스트를 **해시값 (Hash value)**으로 변환한 뒤, 빠르게 비교한다.

  • 모듈러 연산을 적용하여 효율적으로 수치화된 값 비교 수행할 수 있게 된다.

• 장점: 빠른 매칭 가능하고 모듈러 연산을 통해 값의 크기를 제한하여 오버플로우 방지한다.

❤️ 문제점과 해결책 (Challenges and Solutions)

1. 문제점:

   • 문자 집합 Ω와 패턴 길이 m에 따라 ai가 매우 커질 수 있음.
     예: a_i = d(a_{i-1} - d^{m-1}A[i-1]) + A[i+m-1]

   • 너무 큰 숫자는 레지스터의 크기를 초과해 **오버플로우 (Overflow)**가 발생한다.

2. 해결책: **모듈러 연산 (Modulo operation)**을 적용하여 값을 제한한다.

   • 식 변경: bi ​= (d(bi−1​−(dm−1 modq) ⋅ A[i−1]) + A[i+m−1])

   • q 값: 충분히 큰 소수를 선택해 충돌을 최소화한다.

   • 이 방법은 해시테이블의 해시값 계산과 유사하다.

❤️ 라빈-카프 알고리즘의 작동 원리 (How Rabin-Karp Works)

• 패턴 해시값 계산 (Hash Calculation for Pattern):

  • P[]=e,e,a,a,b

  • 계산: p = (4⋅5^4+4⋅5^3+0⋅5^2+0⋅5^1+1) mod 113 = 63

• 원문 해시값 계산 (Hash Calculation for Text):

  • 원문 A[]: a, c, e, b, b, c, e, e, a, b, c, e, e, d, b…

  • 처음 5개의 해시값 a1 = 17

  • 슬라이딩 윈도우 방식으로 다음 해시값 계산: a2 = 87

• 매칭 과정 (Matching Process): 패턴 해시값 p=63 과 원문 해시값 ai를 비교하여 해시값이 같으면 실제 문자열을 확인하여 매칭 여부 판단한다.

• 결과: a7 = 63에서 매칭 성공하였다.

💡중요포인트: 라빈-카프 알고리즘은 빠르고 효율적인 문자열 매칭 알고리즘이다.

• 문제: 문자열 수치화 값이 커져 오버플로우 발생 가능.

• 해결: 모듈러 연산으로 값 크기를 제한하여 문제 해결.

• 라빈-카프 알고리즘 작동 원리:

  • 패턴과 텍스트를 해시값으로 변환해 비교.

  • 해시값이 같으면 매칭 성공(문자열도 추가 확인).

• 효율성: 슬라이딩 윈도우 방식으로 이전 계산 재활용 → 빠른 연산.

• 결과: 패턴 해시값 p와 텍스트 해시값 ai가 동일한 경우 매칭 확인하게 된다.

❤️ 라빈-카프 알고리즘 의사코드 요약 (Rabin-Karp Algorithm Pseudocode Summary)

• 모듈러 연산 사용 (Use of Modulo Operation):

  • 해시값 계산 중 값이 커지는 것을 방지하기 위해 모든 계산에 모듈러 연산이 적용되었다.

  • p, bi​, h 계산 시 mod q를 사용한다.

• 시간복잡도 (Time Complexity):

  • 전체 비교에 O(n + km), 평균적으로 O(n)의 복잡도를 갖는다.

• 작동 원리 (How it Works):

  • 패턴 P의 해시값 p와 텍스트 A의 해시값 bi​를 계산한다.

  • 해시값이 일치하면, 실제 문자열도 비교하여 매칭 여부 확인하게 된다.

**💡중요포인트: 모듈러 연산 (Modulo Operation)**을 통해 수치화 과정에서 값이 너무 커지지 않도록 계산마다 사용하여 오버플로우를 방지한다. 패턴 해시값 p와 텍스트 해시값 bi를 비교하여 매칭 여부를 빠르게 판단하고 슬라이딩 윈도우를 사용하여 효율적으로 계산한다. 문자열 매칭을 빠르게 수행이 가능하고 큰 데이터를 처리할때 효율적이다. 또한 해시값 충돌 가능성 때문에 해시값이 같을 경우 문자열을 추가로 비교하여 정확성을 보장한다.

5️⃣KMP 알고리즘과 실패 함수 (KMP Algorithm and Failure Function)

💡 요약 (Summary)

1. KMP 알고리즘의 핵심 (Core Idea of KMP):

   • 매칭 실패 시 처음으로 돌아가지 않고, 중간 지점으로 복귀하여 이전 비교 결과를 활용한다. 이를 통해 비교 연산 횟수가 감소하게 된다.

2. 실패 함수 (Failure Function):

   • 매칭 실패 시 돌아갈 중간 지점을 미리 계산하고 저장하는 함수이다.

   • 패턴의 중복 정보를 활용하여 불필요한 연산을 줄일 수 있다.

3. KMP vs. 오토마타: 오토마타와 유사한 방식으로 동작하지만, 준비 작업이 더 단순하고 빠르다는 장점이 있다. (오토마타는 상태함수 준비시 좀 복잡하다)

✅ KMP 알고리즘 vs. 오토마타 매칭 비교 (KMP Algorithm vs. Automata Matching)

1. 원시적 매칭과의 차이 (Compared to Naive Matching):

   • 원시적 매칭: 매칭 실패 시 처음으로 돌아가 다시 비교.

   • 오토마타와 KMP: 실패 시 중간 상태로 이동해 이전 결과를 재활용.

2. KMP와 오토마타의 공통점 (Similarities):

   • 둘 다 문맥 활용: 매칭 실패 시 중간 상태로 이동해 불필요한 연산 제거.

3. KMP와 오토마타의 차이점 (Differences):

   • 오토마타: 상태 전이 함수를 상태 다이어그램으로 정의. 준비 과정이 복잡하지만 체계적이다.

   • KMP: 실패 함수를 이용해 중간 지점을 계산한다. 준비 과정이 단순하고 빠르다.

✅KMP 알고리즘 작동 원리 (How KMP Works)

1. 패턴 매칭:

   • 텍스트와 패턴을 비교하면서 실패 시 중간 지점으로 이동한다.

   • 실패 함수 π[i]를 사용하여 복귀 지점을 결정한다.

2. 실패 함수의 역할 (Role of Failure Function):

   • 매칭 실패 시 처음으로 돌아가지 않고, 이미 매칭된 부분을 활용해 비교를 이어간다.

   • 예: π[8] = 4 → 8번째 자리에서 실패하면 4번째 자리로 복귀하게 된다.

3. 실패 함수 계산 (Failure Function Calculation):

   • 패턴 내에서 부분 문자열의 중복 정보를 활용하여 재활용한다.

   • 패턴의 각 위치에서 실패 시 복귀할 위치를 저장한다.

✅예제 분석 (Example Analysis)

매칭 실패 예시: 텍스트: A[], 패턴: P[] = abcdabcwz

• 텍스트에서 abcdabcd 까지 매칭 후 d≠w에서 실패가 발생하였다.

• 실패 함수로 인해 중복된 abc를 살리고, d부터 비교를 재개한다.

실패 함수 예시: P [1:9] = abcdabcwz

• π[8]=4: 8번째 자리에서 실패 시 4번째 자리 d로 이동한다.

• 결과적으로 4칸 점프하여 불필요한 연산 제거하게 된다.

✅KMP의 장점 (Advantages)

1. 효율적 비교: 실패 함수로 중복 비교를 줄여 평균적으로 O(n+m)시간 복잡도를 가진다.

2. 중복 활용: 패턴 내부 중복을 활용해 이전 결과를 재활용한다.

3. 실제 응용: 텍스트 검색, 네트워크 패턴 매칭, 데이터 분석 등에 사용된다.

✅ KMP 알고리즘과 실패 함수 준비 의사코드 (KMP Algorithm and Failure Function Pseudocode)

💡 요약 (Summary)

1. 실패 함수 준비 (Failure Function Preparation):

   • 목적: 패턴 내 중복 정보를 활용해 매칭 실패 시 돌아갈 위치를 미리 계산.

   • 시간복잡도: Θ(m), 패턴의 길이 m에 비례.

2. KMP 알고리즘 (KMP Algorithm):

   • 매칭 실패 시 실패 함수 π[j]를 이용해 중간 지점으로 점프.

   • 원문의 각 문자에 대해 비교 진행 → Θ(n) 시간 소요.

   • 전체 시간복잡도: Θ(n+m)

• k: 패턴의 접두사 길이를 나타냄.

• π[j]: 매칭 실패 시 복귀 위치를 저장.

• if (k = 0 or A[j] = P[k]) j++, k++; k = 0이거나 원문의 값이 A[j] = P[k]패턴의 값과 일치하면 계속 증가하다가 π[j] <- k 실패함수 값을 업데이트해준다.

• else j <-π[j] 매칭 실패 시 j를 π[j]로 업데이트하여 중간 지점으로 복귀한다.

• 매칭 성공 시, 매칭된 위치를 출력하고 다시 π[j]를 이용해 다음 비교 시작.

• 먼저 패턴에 대한 실패 함수를 준비한다. preprocessing(p) 그다음엔 while문을 돌며 실패가 일어났을 경우에 해당 지점으로 점프를 해나가게 된다. else j <-π[j] 그러다가 전체적으로 매칭이 일어나면 매칭이 되고 처음으로 다시 돌아가게된다. j <-π[j]

✅시간복잡도 분석 (Time Complexity Analysis)

• 실패 함수 준비: Θ(m), 패턴의 길이에 비례

• KMP 알고리즘: Θ(n), 원문의 길이에 비례.

• 전체 시간복잡도: Θ(n + m), 효율적 문자열 매칭 가능.

• 실패 함수를 준비하는데 패턴의 길이만큼의 시간이 필요해서 preprocessing() = Θ(m)이고 while 루프는 원문의 문자를 하나씩 보기때문에 Θ(n)이다.

6️⃣보이어-무어 알고리즘(Boyer-Moore Algorithm)

기존의 라빈 카프 알고리즘이나 kmp알고리즘은 텍스트 문자열을 처음부터 적어도 1번씩은 검색하기 때문에 세타n의 수행시간이 필요한다. 텍스트를 왼쪽에서 오른쪽으로 비교하기때문에 최선의 경우에도 n만큼의 시간이 필요하다. 보이어 무어는 생각의 전환을 하였다. 텍스트 문자열을 전부 보지 않고 점프를 하며 일부만 보는것이다 또한 패턴을 왼쪽이 아닌 오른쪽부터 비교하게 된다. 긴문자열의 패턴이 5개라면 5번째부터 본다. 매칭이 되지 않는다면 앞에있는 4개는 보지 않고 뛰어넘게된다. 이렇게 반복하는 방식이다. 실무적으로 높은 성능을 보이는 알고리즘으로 많이 사용되고 있다.

✅ 보이어-무어 알고리즘 작동 원리 (How it Works)

1. 비교 방향: 전체 텍스르로 보면 앞으로 진행하지만 패턴으로 보면 반대방향으로 진행한다.

   • 패턴: 오른쪽에서 왼쪽으로 비교.

   • 텍스트: 여전히 왼쪽에서 오른쪽으로 진행.

2. 불일치 처리:

   • KMP알고리즘이 실패함수를 사용하는 것처럼 보이어무어 함수도 불일치 시 “점프 테이블”을 참고해 특정 칸 수를 건너뛴다.

   • 검색하는 텍스트보다 패턴이 훨씬 짧고 여러번 찾을 때 유리하다.

   • 실무적으로 문자열 매칭 알고리즘을 사용할때 보이어 무어 알고리즘이 벤치 마크 표준으로 사용될 정도로 많이 사용되고 있다.