Storage Device Management Overview(저장장치 관리 개요)

이번 주차에서는 저장장치 관리(Storage Device Management)에 대해 학습한다. 프로그램 실행 과정에서 생성된 데이터는 전원이 꺼져도 유지되어야 하므로 보조기억장치(Secondary Storage)에 저장된다.

운영체제(Operating System)는 이러한 데이터를 디스크(Disk) 구조에 맞게 효율적으로 저장하고, 필요할 때 빠르게 접근할 수 있도록 관리한다.

이번 시간에는 디스크의 구조(Disk Structure), 데이터 접근 방식(Data Access Method), 저장장치 관리의 전체 흐름을 중심으로 살펴본다.

이번 주차의 학습 목표는 다음과 같다. 먼저 디스크의 구조와 접근 시간(Access Time)의 구성 요소를 설명할 수 있어야 한다. 또한 디스크 접근 비용(Disk Access Cost)을 줄이기 위한 기법을 이해하고, RAID와 같은 저장 방식(Storage Method)의 특징도 설명할 수 있어야 한다.

마지막으로 실습을 통해 디스크 접근 특성(Disk Access Characteristics)과 성능 차이(Performance Difference)를 분석하는 것이 이번 주차의 핵심이다.

Why Storage Device Management Is Needed

개념 로딩(Concept Loading)을 통해 저장장치 관리(Storage Device Management)의 필요성을 생각해보자.

첫 번째 질문이 있다. 컴퓨터에서 파일을 복사하거나 프로그램을 실행할 때를 떠올려보자. 데이터의 크기가 비슷한데도 어떤 경우는 빠르게 처리되고, 어떤 경우는 유독 느리게 느껴지는 경험이 있다. 그렇다면 데이터의 크기가 비슷한데도 속도가 달라지는 이유는 무엇일까?

디스크(Disk)는 데이터를 어디에 저장하고, 어떤 순서로 접근하느냐에 따라 성능 차이가 발생한다. 즉, 단순히 데이터를 저장하는 것만으로는 충분하지 않고, 효율적인 접근(Efficient Access)을 위한 관리 방식이 필요하다.

그래서 운영체제(Operating System)는 저장장치 관리(Storage Device Management)를 통해 디스크 접근(Disk Access)을 최적화하고, 전체 시스템 성능(System Performance)을 향상시킨다.

두 번째 질문이 있다. 여러 프로그램(Program)이 동시에 디스크에 접근 요청을 보내는 상황을 생각해보자. 이때 요청이 들어온 순서대로 처리하는 것이 항상 효율적일까? 아니면 처리 순서에 따라 성능이 달라질까?

만약 비효율적인 순서로 요청을 처리하면 디스크의 이동이 많아지고, 전체 처리 시간(Total Processing Time)이 증가할 수 있다. 이처럼 디스크에서는 요청을 어떤 순서로 처리하느냐에 따라 성능 차이가 발생한다.

따라서 운영체제는 디스크 스케줄링(Disk Scheduling)을 통해 요청 처리 순서(Request Processing Order)를 조정하고, 더 효율적인 디스크 접근이 이루어지도록 관리한다. 이번 시간에는 이러한 저장장치 관리의 필요성과 디스크 접근 최적화 과정을 중심으로 살펴본다.

추가로 알아두면 좋은 점

디스크 스케줄링(Disk Scheduling)은 특히 하드 디스크(HDD, Hard Disk Drive)에서 중요하다. HDD는 데이터를 읽기 위해 디스크 헤드(Disk Head)가 이동해야 하므로, 요청 처리 순서에 따라 탐색 시간(Seek Time)이 크게 달라질 수 있다.

반면 SSD(Solid State Drive)는 물리적인 디스크 헤드가 없기 때문에 HDD보다 탐색 시간의 영향은 작지만, 운영체제는 여전히 입출력 요청(I/O Request)을 효율적으로 관리해야 한다.

Disk Structure and Access Process(디스크 구조와 접근 과정)

저장장치(Storage Device)의 동작을 이해하기 위해 먼저 디스크(Disk)의 기본 구조와 데이터가 저장되는 물리적인 단위를 살펴본다.

디스크는 데이터를 일정한 물리적 단위(Physical Unit)로 저장하며, 운영체제(Operating System)는 이러한 구조를 바탕으로 데이터를 읽고 쓴다. 따라서 저장장치 관리를 이해하려면 디스크가 어떤 구조로 이루어져 있고, 데이터가 어떤 단위로 저장되는지 알아야 한다.

또한 디스크에 접근할 때는 단순히 데이터를 바로 읽는 것이 아니라, 여러 단계의 접근 과정이 발생한다. 대표적으로 디스크 헤드(Disk Head)가 원하는 위치로 이동하는 탐색 시간(Seek Time), 원하는 섹터(Sector)가 헤드 아래로 올 때까지 기다리는 회전 지연 시간(Rotational Latency), 실제 데이터를 읽거나 쓰는 전송 시간(Transfer Time)이 포함된다.

이번 내용에서는 디스크의 기본 구조와 데이터 저장 단위, 그리고 탐색 시간(Seek Time), 회전 지연(Rotational Latency), 전송 시간(Transfer Time)을 중심으로 디스크 접근 과정(Disk Access Process)을 살펴본다.

추가로 알아두면 좋은 점

디스크 접근 시간(Disk Access Time)은 보통 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)을 합쳐서 이해한다. 특히 HDD(Hard Disk Drive)는 물리적으로 헤드가 움직이고 원판이 회전하기 때문에 이 요소들이 성능에 큰 영향을 준다.

Physical Disk Structure and Data Organization

디스크(Disk)는 여러 장의 플래터(Platter)로 이루어진 저장장치(Storage Device)이다. 플래터는 원형의 형태로 회전하면서 데이터를 저장한다.

각 플래터의 표면에는 동심원 형태의 트랙(Track)이 존재한다. 이 트랙은 다시 더 작은 단위인 섹터(Sector)로 나뉘며, 실제 데이터는 섹터 단위로 저장된다.

또한 여러 플래터에서 같은 위치에 있는 트랙들을 모으면 실린더(Cylinder)를 구성한다. 디스크는 이러한 플래터, 트랙, 섹터, 실린더 구조를 기반으로 데이터를 읽고 쓴다.

하지만 운영체제(Operating System)는 이러한 물리적 구조를 그대로 직접 사용하지 않는다. 대신 논리 블록(Logical Block) 단위를 기준으로 데이터를 관리한다.

즉, 디스크의 물리적인 구조 위에 논리적인 관리 단위를 두어 데이터를 효율적으로 저장하고 접근할 수 있도록 구성되어 있다고 이해할 수 있다.

추가로 알아두면 좋은 점

섹터(Sector)는 디스크에서 실제 데이터가 저장되는 물리적 단위이고, 블록(Block)은 파일 시스템(File System)이 데이터를 관리하는 논리적 단위이다.

즉, 운영체제는 사용자가 복잡한 플래터(Platter), 트랙(Track), 섹터(Sector) 구조를 직접 신경 쓰지 않아도 되도록 블록 단위로 추상화(Abstraction)해서 관리한다.

Physical Disk Structure Diagram(디스크의 물리 구조 그림 설명)

그림은 디스크(Disk)의 물리 구조와 함께 고정 헤드 디스크(Fixed-Head Disk)와 이동 헤드 디스크(Movable-Head Disk)의 차이를 보여준다.

먼저 오른쪽의 이동 헤드 디스크(Movable-Head Disk)를 보면, 여러 장으로 겹쳐 있는 원판이 플래터(Platter)이다. 플래터는 실제 데이터가 저장되는 원판으로, 디스크의 저장 공간을 이루는 핵심 요소이다.

각 플래터 표면에는 동심원 형태의 트랙(Track)이 존재한다. 트랙은 데이터가 저장되는 원형 경로이며, 각 트랙은 다시 더 작은 단위인 섹터(Sector)로 나뉜다. 섹터는 실제 데이터가 기록되는 물리적인 저장 구역이다.

또한 여러 플래터에서 같은 반지름 위치에 있는 트랙들을 세로로 묶으면 실린더(Cylinder)가 된다. 실린더는 헤드(Head)가 같은 위치에 고정된 상태에서 접근할 수 있는 트랙들의 집합이라고 볼 수 있다.

플래터 옆으로 길게 뻗어 있는 구조는 암(Arm)이다. 암은 읽기/쓰기 헤드(Read/Write Head)를 원하는 트랙 위치까지 이동시키는 역할을 한다. 암 끝에 붙어 있는 작은 장치가 바로 읽기/쓰기 헤드이며, 이 헤드가 플래터 표면의 데이터를 실제로 읽거나 기록한다.

암 바깥쪽의 구동 장치는 액추에이터(Actuator)로 볼 수 있다. 이 장치는 암을 안쪽이나 바깥쪽으로 움직여, 헤드가 원하는 트랙으로 이동할 수 있도록 한다.

중앙에 세로로 연결된 부분은 축(Spindle)이다. 축은 플래터를 회전시키는 역할을 하며, 디스크는 이 회전을 통해 원하는 섹터가 헤드 아래에 오도록 해서 데이터를 읽고 쓴다.

이제 왼쪽의 고정 헤드 디스크(Fixed-Head Disk)를 보면, 각 트랙마다 고정된 읽기/쓰기 헤드가 하나씩 배치되어 있다. 즉 트랙마다 전용 헤드가 따로 존재하기 때문에 헤드를 이동시키지 않고도 해당 트랙에 바로 접근할 수 있다. 그래서 접근 속도가 빠르다는 특징이 있다.

반면 이동 헤드 디스크(Movable-Head Disk)는 하나의 읽기/쓰기 헤드가 여러 트랙 사이를 이동하면서 접근하는 구조이다. 따라서 필요한 트랙으로 헤드를 옮기는 과정이 필요하고, 이로 인해 탐색 시간(Seek Time)이 발생한다. 이러한 헤드 이동 시간은 디스크 접근 시간(Access Time)에 영향을 준다.

정리하면, 고정 헤드 디스크는 각 트랙마다 헤드가 따로 있어 빠르게 접근할 수 있고, 이동 헤드 디스크는 하나의 헤드가 여러 트랙을 이동하면서 접근하기 때문에 구조는 비교적 단순하지만 접근 시간의 영향을 더 크게 받는다. 즉 이 그림은 디스크를 구성하는 요소들의 위치와 역할, 그리고 고정 헤드 방식과 이동 헤드 방식의 차이를 함께 보여주는 구조라고 할 수 있다.

이동 헤드 디스크(Movable-Head Disk)가 많이 사용되는 이유는 큰 저장 용량을 더 효율적이고 경제적으로 구현할 수 있기 때문이다. 고정 헤드 디스크(Fixed-Head Disk)는 각 트랙마다 별도의 헤드가 필요하기 때문에 트랙 수가 많아질수록 구조가 복잡해지고 비용이 증가한다. 반면 이동 헤드 디스크는 하나의 헤드가 여러 트랙을 이동하며 접근하므로 탐색 시간(Seek Time)은 발생하지만, 더 적은 장치로 많은 데이터를 저장할 수 있다.

추가로 알아두면 좋은 점

실제 현대 하드디스크(HDD, Hard Disk Drive)는 대부분 이동 헤드 디스크(Movable-Head Disk) 구조를 사용한다. 고정 헤드 디스크(Fixed-Head Disk)는 개념 설명용으로 자주 등장하지만, 현재는 일반적으로 널리 사용되지는 않는다.

또한 SSD(Solid State Drive)는 플래터, 트랙, 섹터, 헤드 같은 기계적 구조가 없기 때문에 HDD와는 다른 방식으로 데이터에 접근한다.

Logical Blocks and Physical Sectors(논리 블록과 물리 섹터)

디스크(Disk)의 물리 구조 위에서 데이터가 실제로 어떤 단위로 관리되는지 살펴보자.

디스크에서 데이터를 저장하는 가장 작은 물리적 단위는 섹터(Sector)이다. 하지만 운영체제(Operating System)는 일반적으로 이 섹터를 직접 하나씩 제어하지 않는다. 섹터 단위의 실제 읽기와 쓰기는 디스크 컨트롤러(Disk Controller)와 같은 하드웨어 계층에서 처리된다.

섹터 하나의 크기는 작기 때문에 운영체제가 이를 그대로 관리하면 비효율적일 수 있다. 그래서 운영체제는 여러 개의 섹터를 묶어 논리 블록(Logical Block) 단위로 관리한다.

즉, 파일(File)은 물리적인 섹터 단위가 아니라 논리적인 블록 단위로 디스크에 저장되고 접근된다. 이 과정에서 사용자가 보는 파일의 위치와 실제 디스크에 저장된 물리적 위치는 서로 다를 수 있다.

따라서 운영체제는 복잡한 물리적 저장 구조를 사용자에게 직접 노출하지 않고, 논리 블록 단위를 통해 더 효율적인 저장과 접근이 가능하도록 관리한다고 이해할 수 있다.

Logical Blocks and Physical Sectors Diagram

이 그림은 디스크(Disk)에서 데이터가 저장되는 물리적 구조를 보여준다.

오른쪽의 원형 그림을 보면 여러 개의 작은 구역으로 나뉘어 있는 부분이 보이는데, 각각의 구역이 섹터(Sector)이다. 섹터는 실제 데이터가 저장되는 가장 작은 물리적 단위이다.

이 섹터들은 원형의 경로를 따라 배열되어 있는데, 이 원형의 경로를 트랙(Track)이라고 한다. 즉 하나의 트랙은 여러 개의 섹터로 구성된다.

왼쪽 그림을 보면 여러 개의 플래터(Platter)가 쌓여 있는 구조를 확인할 수 있다. 이때 여러 플래터에서 같은 반지름 위치에 있는 트랙들을 세로로 연결해서 보면 이를 실린더(Cylinder)라고 한다.

즉 이 그림은 디스크에서 데이터가 트랙과 섹터 단위로 나뉘어 저장되고, 여러 플래터를 기준으로는 실린더 구조로 묶여 관리된다는 점을 보여준다.

추가로 알아두면 좋은 점

운영체제(Operating System)는 이러한 물리적 구조를 직접 사용자에게 보여주지 않는다. 대신 여러 섹터를 묶은 논리 블록(Logical Block) 단위로 데이터를 관리한다.

즉, 물리적으로는 섹터(Sector)와 트랙(Track) 구조를 가지지만, 논리적으로는 블록(Block) 단위로 저장하고 접근한다고 이해하면 된다.

Components of Disk Access Time(디스크 접근 시간의 구성)

디스크(Disk)에서 데이터를 읽고 쓰는 과정은 메모리(Memory)처럼 주소를 바로 읽는 방식과 다르다. 디스크는 기계적인 동작(Mechanical Operation)이 함께 이루어지기 때문에 데이터 요청이 즉시 처리되지 않는다.

먼저 디스크 헤드(Disk Head)가 원하는 트랙(Track) 위치로 이동해야 한다. 그다음 플래터(Platter)가 회전하면서 필요한 섹터(Sector)가 헤드 아래로 도달해야 한다. 이후에야 실제 데이터의 읽기(Read), 쓰기(Write), 전송(Transfer)이 이루어진다.

따라서 디스크 접근 시간(Disk Access Time)은 하나의 요소로만 결정되지 않는다. 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)과 같은 여러 단계가 순차적으로 진행되면서 전체 접근 시간이 만들어진다.

각 단계에서 소요되는 시간이 누적되면 전체 디스크 성능(Disk Performance)과 입출력 성능(I/O Performance)에 영향을 준다. 결국 디스크 접근 시간은 저장장치 성능(Storage Device Performance)을 결정하는 중요한 요소라고 할 수 있다.

추가로 알아두면 좋은 점

디스크 접근 시간(Disk Access Time)은 일반적으로 다음과 같이 이해할 수 있다.

Disk Access Time = Seek Time + Rotational Latency + Transfer Time

이 개념은 주로 하드 디스크(HDD, Hard Disk Drive)에 해당한다. SSD(Solid State Drive)는 기계적으로 움직이는 헤드나 회전하는 플래터가 없기 때문에 탐색 시간과 회전 지연의 영향이 거의 없다.

Components of Disk Access Time Diagram

이 그림은 디스크 접근 시간(Disk Access Time)이 어떤 요소들로 구성되는지를 보여준다.

먼저 이동 헤드 디스크(Movable-Head Disk)에서는 읽기/쓰기 헤드(Read/Write Head)가 데이터가 저장된 트랙(Track) 위치까지 이동해야 한다. 이때 헤드가 원하는 트랙으로 이동하는 시간을 탐색 시간(Seek Time)이라고 한다.

그다음 헤드가 원하는 트랙에 도착하더라도, 필요한 데이터가 바로 헤드 아래에 있는 것은 아니다. 디스크가 회전하면서 원하는 섹터(Sector)가 헤드 아래로 올 때까지 기다려야 하는데, 이 시간을 회전 지연 시간(Rotational Latency)이라고 한다.

이후 원하는 섹터가 헤드 아래에 도착하면 실제로 데이터를 읽거나 쓰고, 그 데이터를 전송하는 과정이 이루어진다. 이때 소요되는 시간을 전송 시간(Transfer Time)이라고 한다.

즉, 디스크 접근 시간은 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)이 합쳐져서 결정된다.

이 세 가지 요소 중 어느 하나라도 길어지면 전체 디스크 성능(Disk Performance)과 입출력 성능(I/O Performance)에 영향을 주게 된다. 따라서 디스크 접근 시간은 저장장치 성능(Storage Device Performance)을 결정하는 중요한 요소라고 할 수 있다.

추가로 알아두면 좋은 점

전송 시간(Transfer Time)은 단순히 기다리는 시간이 아니라, 원하는 섹터가 도착한 뒤 실제 데이터를 읽거나 쓰고 전달하는 데 걸리는 시간이다.

보통 디스크 접근 시간은 다음과 같이 정리한다.

Disk Access Time = Seek Time + Rotational Latency + Transfer Time

이 개념은 주로 HDD(Hard Disk Drive)에 해당하며, SSD(Solid State Drive)는 기계적인 헤드 이동과 회전이 없기 때문에 탐색 시간과 회전 지연의 영향이 거의 없다.

Seek Time, Rotational Latency, and Transfer Time

앞에서 디스크 접근 시간(Disk Access Time)을 구성하는 세 가지 요소를 살펴보았다. 이번에는 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)을 조금 더 자세히 정리해보자.

먼저 탐색 시간(Seek Time)은 디스크 헤드(Disk Head)가 현재 위치에서 요청된 데이터가 저장된 트랙(Track)까지 이동하는 데 걸리는 시간이다. 즉, 데이터를 읽거나 쓰기 전에 헤드가 먼저 원하는 위치로 이동해야 한다는 의미이다.

탐색 시간은 디스크 접근 시간 중 큰 비중을 차지하는 요소이다. 헤드가 이동해야 하는 거리가 멀수록 더 많은 시간이 필요하다. 따라서 데이터가 디스크의 어느 위치에 저장되어 있는지에 따라 전체 처리 속도와 성능 차이가 발생할 수 있다. 이후에 살펴볼 디스크 스케줄링(Disk Scheduling) 기법도 이러한 헤드 이동을 줄이는 방향으로 활용된다.

다음으로 회전 지연 시간(Rotational Latency)은 헤드가 원하는 트랙에 도착한 이후, 목표 섹터(Sector)가 헤드 아래에 올 때까지 기다리는 시간을 의미한다. 즉, 헤드가 올바른 트랙에 도착했더라도 필요한 데이터가 바로 아래에 없다면 디스크가 회전할 때까지 기다려야 한다.

디스크는 일정한 속도로 계속 회전하기 때문에 이 과정에서 추가적인 대기 시간이 발생한다. 평균적으로는 한 바퀴 회전 시간의 절반 정도가 회전 지연 시간으로 발생한다고 볼 수 있다. 따라서 같은 트랙 안에 데이터가 있더라도 섹터의 위치에 따라 실제 접근 시간은 달라질 수 있다.

마지막으로 전송 시간(Transfer Time)은 원하는 위치를 찾은 이후, 데이터를 실제로 읽거나 쓰고 메모리(Memory)로 전달하는 데 걸리는 시간이다. 탐색 시간과 회전 지연 시간이 데이터 접근을 위한 준비 과정이라면, 전송 시간은 실제 데이터 처리가 이루어지는 단계라고 볼 수 있다.

전송 시간은 디스크와 메모리 사이의 전송 속도(Transfer Rate)와 데이터 크기(Data Size)에 따라 달라진다. 전송해야 할 데이터의 양이 많을수록 더 많은 시간이 필요하고, 데이터가 적다면 전송 시간도 짧아진다. 다만 일반적으로 탐색 시간과 회전 지연 시간에 비해서는 상대적으로 짧은 편이다.

정리하면, 디스크 접근 시간은 탐색 시간, 회전 지연 시간, 전송 시간이 합쳐져 결정된다. 이 중 특히 탐색 시간과 회전 지연 시간은 HDD(Hard Disk Drive)의 기계적인 구조 때문에 발생하는 중요한 성능 요소이다.

추가로 알아두면 좋은 점

평균 회전 지연 시간(Average Rotational Latency)은 보통 디스크가 한 바퀴 도는 시간의 절반으로 계산한다. 예를 들어 디스크가 한 바퀴 도는 데 10ms가 걸린다면, 평균 회전 지연 시간은 약 5ms로 볼 수 있다.

또한 이 개념은 주로 HDD(Hard Disk Drive)에 해당한다. SSD(Solid State Drive)는 회전하는 플래터(Platter)나 이동하는 헤드(Head)가 없기 때문에 탐색 시간과 회전 지연 시간이 거의 발생하지 않는다.

Why Seek Time Is Important(탐색 시간이 중요한 이유)

디스크 접근 시간(Disk Access Time)을 구성하는 세 가지 요소 중 일반적으로 탐색 시간(Seek Time)이 전체 접근 시간에서 큰 비중을 차지하는 경우가 많다.

가장 큰 이유는 디스크 헤드(Disk Head)가 원하는 트랙(Track)까지 실제로 물리적으로 이동해야 하기 때문이다. 즉, 단순한 전기적 신호 처리만으로 끝나는 것이 아니라 기계적인 움직임(Mechanical Movement)이 동반되기 때문에 시간이 더 많이 필요하다.

또한 헤드가 이동해야 하는 거리에 따라 소요 시간이 크게 달라진다. 가까운 트랙으로 이동할 때와 먼 트랙으로 이동할 때의 차이가 크기 때문에, 탐색 시간은 회전 지연 시간(Rotational Latency)보다 변동 폭이 크게 나타날 수 있다.

따라서 디스크 접근 시간에서 탐색 시간은 중요한 성능 요소로 다루어진다. 이후에 살펴볼 디스크 스케줄링(Disk Scheduling)도 이러한 헤드 이동 거리를 줄여 전체 접근 시간을 줄이는 방향으로 동작한다.

Total Disk Access Time(전체 디스크 접근 시간)

정리하면 디스크 접근 시간(Disk Access Time)은 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)이 합쳐져서 결정된다. 일반적으로는 이 중 탐색 시간이 전체 성능에 가장 큰 영향을 주는 경우가 많다.

요청을 어떤 순서로 처리하느냐에 따라 디스크 헤드(Disk Head)의 이동 거리가 달라지고, 그에 따라 전체 접근 시간도 달라진다. 따라서 디스크 성능(Disk Performance)을 높이기 위해서는 요청 처리 순서(Request Processing Order)를 효율적으로 관리하는 것이 중요하다.

탐색 시간이 실제 성능에 얼마나 큰 영향을 주는지 수치로 계산해보자. 주어진 조건은 다음과 같다.

탐색 시간(Seek Time)은 50ms, 회전 지연 시간(Rotational Latency)은 16.8ms이다. 전송 시간(Transfer Time)은 바이트(Byte)당 0.00094ms이다.

예제에서는 1KB를 1024바이트(Byte)로 계산한다. 따라서 1KB 데이터를 전송하는 시간은 다음과 같다.

0.00094ms × 1024 = 0.96256ms

이 값을 이용해 디스크 종류에 따른 전체 접근 시간을 비교할 수 있다.

먼저 이동 헤드 디스크(Movable-Head Disk)는 헤드가 원하는 트랙으로 이동해야 하므로 탐색 시간, 회전 지연 시간, 전송 시간을 모두 더해야 한다.

50 + 16.8 + 0.96256 = 67.76256ms

따라서 이동 헤드 디스크의 전체 접근 시간은 약 67.76ms이다.

반면 고정 헤드 디스크(Fixed-Head Disk)는 각 트랙마다 헤드가 존재하므로 헤드 이동 과정이 필요하지 않다. 따라서 탐색 시간을 제외하고 회전 지연 시간과 전송 시간만 더하면 된다.

16.8 + 0.96256 = 17.76256ms

따라서 고정 헤드 디스크의 전체 접근 시간은 약 17.76ms이다.

결국 같은 조건이라도 디스크 구조(Disk Structure)에 따라 전체 접근 시간은 크게 달라질 수 있다. 특히 탐색 시간(Seek Time)이 전체 디스크 성능에 큰 영향을 준다는 점을 확인할 수 있다.

추가로 알아두면 좋은 점

또한 고정 헤드 디스크(Fixed-Head Disk)는 탐색 시간이 거의 없다는 장점이 있지만, 각 트랙마다 헤드가 필요하므로 구조가 복잡하고 비용이 높다. 그래서 실제 현대 HDD(Hard Disk Drive)에서는 대부분 이동 헤드 디스크(Movable-Head Disk) 구조가 사용된다.

Factors Affecting Disk Performance (디스크 성능 결정 요소)

디스크 성능(Disk Performance)은 단순히 데이터 크기(Data Size)만으로 결정되지 않는다. 오히려 데이터를 처리하기 위해 디스크 헤드(Disk Head)가 얼마나 이동해야 하는지가 더 큰 영향을 주는 경우가 많다.

헤드의 이동 거리가 길어질수록 탐색 시간(Seek Time)이 증가하고, 그만큼 전체 디스크 접근 시간(Disk Access Time)도 함께 늘어난다.

또한 데이터가 디스크의 여러 위치에 분산되어 저장되어 있다면, 헤드는 여러 위치로 이동해야 한다. 이 경우 디스크 접근이 비효율적으로 이루어져 성능이 낮아질 수 있다.

요청이 처리되는 순서(Request Processing Order)도 중요하다. 같은 요청들이 들어오더라도 어떤 순서로 처리하느냐에 따라 헤드의 전체 이동 경로가 크게 달라질 수 있다.

즉, 디스크 성능은 데이터의 크기보다 헤드 이동 거리(Head Movement Distance), 데이터 배치(Data Placement), 요청 처리 순서(Request Processing Order)에 더 큰 영향을 받을 수 있다고 이해할 수 있다.

추가로 알아두면 좋은 점

이 내용은 이후에 살펴볼 디스크 스케줄링(Disk Scheduling)과 연결된다. 디스크 스케줄링은 여러 디스크 요청의 처리 순서를 조정하여 헤드 이동 거리를 줄이고, 전체 접근 시간을 줄이기 위한 기법이다.

Disk Access Order and Performance(디스크 접근 순서와 성능)

디스크 접근 순서(Disk Access Order)에 따라 성능이 어떻게 달라지는지 살펴보자.

디스크에 들어오는 요청 집합(Request Set)이 같더라도, 어떤 순서로 처리하느냐에 따라 전체 성능은 달라질 수 있다. 그 이유는 요청 처리 순서(Request Processing Order)에 따라 디스크 헤드(Disk Head)가 이동하는 경로와 총 이동 거리가 달라지기 때문이다.

만약 요청을 비효율적인 순서로 처리하면 헤드의 이동 거리가 길어지고, 그만큼 탐색 시간(Seek Time)이 증가한다. 탐색 시간이 증가하면 전체 디스크 접근 시간(Disk Access Time)도 함께 늘어나게 된다.

반대로 불필요한 헤드 이동을 줄이는 순서로 요청을 처리하면 더 짧은 시간 안에 더 많은 요청을 처리할 수 있다. 즉, 효율적인 요청 처리 순서를 결정하는 것이 디스크 성능(Disk Performance)을 높이는 데 중요하다.

정리하면, 디스크 성능은 요청의 개수만으로 결정되는 것이 아니라 요청을 어떤 순서로 처리하는지에 따라 크게 달라질 수 있다. 비효율적인 처리 순서는 성능 저하로 이어지고, 효율적인 처리 순서를 결정하는 방식이 바로 디스크 스케줄링(Disk Scheduling)의 핵심이다.

추가로 알아두면 좋은 점

디스크 스케줄링(Disk Scheduling)은 여러 디스크 입출력 요청(I/O Request)의 처리 순서를 조정하여 헤드 이동 거리(Head Movement Distance)를 줄이는 기법이다.

대표적인 방식으로는 FCFS(First-Come, First-Served), SSTF(Shortest Seek Time First), SCAN, C-SCAN 등이 있다. 이 방식들은 이후에 디스크 요청을 어떤 기준으로 처리할지 비교할 때 중요하게 다루어진다.

SSD and HDD Comparison (SSD와 HDD 비교)

이러한 접근 특성(Access Characteristics)은 모든 저장장치(Storage Device)에서 동일하게 나타나는 것은 아니다. 저장장치의 종류가 달라지면 데이터에 접근하는 방식과 성능 특성(Performance Characteristics)도 달라진다.

대표적으로 SSD(Solid State Drive)와 HDD(Hard Disk Drive)를 비교하면 그 차이를 쉽게 확인할 수 있다.

먼저 SSD는 기계적으로 움직이는 헤드(Head)나 플래터(Platter)가 없다. 따라서 탐색 시간(Seek Time)과 회전 지연 시간(Rotational Latency)이 거의 발생하지 않으며, 빠른 접근 속도(Access Speed)를 제공한다.

또한 SSD는 데이터의 위치에 따른 성능 차이가 HDD보다 작다. 하지만 내부 병렬 구조(Internal Parallelism), 컨트롤러(Controller), 플래시 메모리(Flash Memory) 관리 방식에 따라 성능 차이가 발생할 수 있다.

반면 HDD는 헤드 이동(Head Movement)과 디스크 회전(Disk Rotation)이 필요한 구조이다. 따라서 데이터가 어디에 저장되어 있는지에 따라 접근 시간이 크게 달라질 수 있다. 가까운 위치의 데이터는 빠르게 접근할 수 있지만, 멀리 떨어진 데이터에 접근하려면 더 많은 시간이 필요하다.

다만 SSD도 모든 접근에서 성능 차이가 완전히 사라지는 것은 아니다. SSD는 헤드 이동은 없지만, 연속된 데이터를 처리하는 순차 접근(Sequential Access)과 여러 위치에 분산된 데이터를 처리하는 랜덤 접근(Random Access) 사이에서 성능 차이가 발생할 수 있다. 이는 SSD 내부 컨트롤러의 동작 방식과 데이터 관리 방식의 영향을 받기 때문이다.

즉, 저장장치의 종류에 따라 데이터 접근 방식과 성능 구조가 다르다. 지금까지는 저장장치의 구조, 데이터 접근 방식, 그리고 디스크 성능에 영향을 주는 요소들을 살펴보았다.

추가로 알아두면 좋은 점

HDD에서는 탐색 시간(Seek Time)과 회전 지연 시간(Rotational Latency)이 성능에 큰 영향을 준다. 반면 SSD는 기계적인 이동이 없기 때문에 이러한 요소의 영향은 거의 없고, 대신 컨트롤러(Controller), 캐시(Cache), 플래시 메모리 구조(Flash Memory Structure), 쓰기 방식(Write Operation) 등이 성능에 영향을 줄 수 있다.

따라서 디스크 스케줄링(Disk Scheduling)은 HDD에서 특히 중요하며, SSD에서는 HDD와 같은 헤드 이동 최적화보다 내부 병렬 처리, 쓰기 최적화, 수명 관리 같은 요소가 더 중요해진다.

Disk Scheduling and RAID (디스크 스케줄링과 RAID)

이번에는 디스크 요청 처리 순서를 결정하는 디스크 스케줄링(Disk Scheduling)과 여러 디스크를 활용해 성능과 안정성을 높이는 RAID(Redundant Array of Independent Disks)에 대해 살펴본다.

앞 차시에서 살펴본 것처럼, 헤드 이동(Head Movement)과 회전 동작(Rotation)이 필요한 디스크에서는 요청 처리 방식에 따라 성능 차이가 크게 나타날 수 있다. 디스크 성능(Disk Performance)을 높이기 위해서는 전체 접근 시간(Disk Access Time)을 줄이는 것이 중요하다.

이때 중요한 기준이 되는 것이 요청을 어떤 순서로 처리할 것인가이다. 요청 순서를 효율적으로 조정하면 디스크 헤드(Disk Head)의 이동 거리를 줄일 수 있고, 그 결과 전체 접근 시간도 감소시킬 수 있다.

운영체제(Operating System)는 이러한 디스크 요청(Disk Request)을 효율적으로 관리하기 위해 여러 가지 디스크 스케줄링 기법(Disk Scheduling Algorithm)을 사용한다.

즉, 디스크 접근 순서(Disk Access Order)를 최적화하는 것은 저장장치 성능뿐만 아니라 전체 시스템 성능(System Performance)을 향상시키는 중요한 요소라고 할 수 있다.

추가로 알아두면 좋은 점

디스크 스케줄링(Disk Scheduling)은 특히 HDD(Hard Disk Drive)에서 중요하다. HDD는 물리적으로 헤드가 이동하기 때문에 요청 순서에 따라 탐색 시간(Seek Time)이 크게 달라질 수 있다.

RAID(Redundant Array of Independent Disks)는 여러 개의 디스크를 하나처럼 묶어 사용하는 방식이다. 목적에 따라 데이터 접근 속도를 높이거나, 일부 디스크가 고장 나도 데이터를 복구할 수 있도록 안정성(Reliability)을 높이는 데 사용된다.

Overview of Disk Scheduling(디스크 스케줄링 개요)

디스크 스케줄링(Disk Scheduling)은 디스크 요청(Disk Request)의 처리 순서를 결정하는 기법이다.

디스크 요청은 여러 프로그램(Program)이나 프로세스(Process)로부터 발생하며, 일반적으로 큐(Queue) 형태로 순차적으로 도착한다. 하지만 요청이 들어온 순서대로 처리하는 것이 항상 가장 효율적인 것은 아니다.

같은 요청 집합(Request Set)이라도 어떤 순서로 처리하느냐에 따라 디스크 성능(Disk Performance)이 달라질 수 있다. 그 이유는 처리 순서에 따라 디스크 헤드(Disk Head)의 이동 경로와 총 이동 거리(Total Head Movement)가 달라지기 때문이다.

요청 처리 순서(Request Processing Order)를 적절히 조정하면 불필요한 헤드 이동을 줄일 수 있고, 그 결과 디스크 접근 시간(Disk Access Time)을 감소시킬 수 있다.

이처럼 디스크 요청의 처리 순서를 결정하는 기법을 디스크 스케줄링(Disk Scheduling)이라고 한다. 이를 위해 여러 가지 스케줄링 알고리즘(Scheduling Algorithm)이 사용되며, 각 알고리즘은 서로 다른 성능 특성(Performance Characteristics)을 가진다.

추가로 알아두면 좋은 점

디스크 스케줄링(Disk Scheduling)의 핵심 목표는 디스크 헤드의 이동 거리를 줄여 탐색 시간(Seek Time)을 줄이는 것이다.

대표적인 디스크 스케줄링 알고리즘에는 FCFS(First-Come, First-Served), SSTF(Shortest Seek Time First), SCAN, C-SCAN 등이 있다.

Disk Scheduling Algorithms (디스크 스케줄링 알고리즘)

디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)은 디스크 요청(Disk Request)을 어떤 순서로 처리할 것인지 결정하는 방식이다. 요청 처리 순서에 따라 디스크 헤드(Disk Head)의 이동 거리와 접근 시간(Access Time)이 달라지기 때문에, 알고리즘에 따라 성능 차이가 발생한다.

대표적인 방식으로는 먼저 들어온 요청을 먼저 처리하는 FCFS(First-Come, First-Served)가 있다. 이 방식은 구조가 단순하지만, 요청 순서에 따라 헤드 이동 거리가 길어질 수 있다.

SSTF(Shortest Seek Time First)는 현재 헤드 위치에서 가장 가까운 요청을 우선 처리하는 방식이다. 헤드 이동 거리를 줄일 수 있지만, 멀리 있는 요청이 오래 기다릴 수 있다는 특징이 있다.

SCAN은 헤드가 한 방향으로 이동하면서 지나가는 요청을 처리하고, 끝까지 이동한 뒤 반대 방향으로 다시 요청을 처리하는 방식이다. 엘리베이터가 한 방향으로 이동하면서 층을 처리하는 방식과 비슷하게 이해할 수 있다.

C-SCAN(Circular SCAN)은 헤드가 한 방향으로만 요청을 처리하고, 끝까지 이동한 뒤 다시 처음 방향으로 돌아와 같은 방식으로 처리하는 알고리즘이다. 요청 처리의 균형을 맞추는 데 유리하다.

LOOK과 C-LOOK은 SCAN, C-SCAN과 비슷하지만 디스크의 끝까지 무조건 이동하지 않고, 실제 요청이 존재하는 구간까지만 이동한다. 따라서 불필요한 헤드 이동을 줄일 수 있다.

정리하면, 각 디스크 스케줄링 알고리즘은 헤드 이동 방식이 서로 다르며, 그에 따라 접근 시간과 성능 특성도 달라진다. 이후에는 각 알고리즘의 동작 방식과 장단점을 하나씩 살펴본다.

추가로 알아두면 좋은 점

FCFS는 가장 단순하지만 성능 최적화가 부족할 수 있고, SSTF는 가까운 요청을 우선 처리해 평균 탐색 시간을 줄일 수 있지만 기아 현상(Starvation)이 발생할 수 있다.

SCAN, C-SCAN, LOOK, C-LOOK은 헤드 이동 방향을 기준으로 요청을 처리하여 전체적인 헤드 이동을 줄이기 위한 방식이다. 특히 LOOK과 C-LOOK은 실제 요청이 있는 범위까지만 이동하므로 SCAN 계열보다 불필요한 이동을 줄일 수 있다.

Common Track Request Sequence(공통 트랙 요청 순서)

스케줄링 알고리즘(Scheduling Algorithm)을 살펴보기 전에, 같은 조건에서 비교하기 위한 예제를 먼저 확인한다.

표에 제시된 값들은 디스크(Disk)에 순서대로 들어온 요청들의 트랙 번호(Track Number)를 의미한다. 즉 15번 트랙 요청이 먼저 들어오고, 그다음 8, 17, 11, 3, 23, 19, 14, 20 순서로 요청이 도착한 상황이라고 가정한다.

이후에는 이 동일한 요청 집합(Request Set)을 가지고 각 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)이 어떤 순서로 요청을 처리하는지 비교한다.

중요한 점은 요청 데이터 자체는 같지만, 처리 순서(Request Processing Order)가 달라지면 디스크 헤드(Disk Head)의 이동 거리와 전체 접근 시간(Disk Access Time)이 달라질 수 있다는 것이다.

따라서 이 표는 각 알고리즘의 성능 차이(Performance Difference)를 비교하기 위한 기준 자료라고 할 수 있다.

추가로 알아두면 좋은 점

디스크 스케줄링 알고리즘을 비교할 때는 보통 초기 헤드 위치(Initial Head Position)와 요청 트랙 순서(Request Track Sequence)가 함께 필요하다.

요청 순서가 같더라도 초기 헤드 위치가 달라지면 총 헤드 이동 거리(Total Head Movement)가 달라질 수 있기 때문이다.

FCFS Disk Scheduling(FCFS 디스크 스케줄링)

FCFS(First-Come, First-Served) 스케줄링은 먼저 도착한 디스크 요청(Disk Request)을 먼저 처리하는 가장 단순한 방식이다. 큐(Queue)에 들어온 순서를 그대로 유지하기 때문에 구현이 쉽고, 요청이 들어온 순서대로 처리된다는 점에서 공정성(Fairness)이 높다는 장점이 있다.

하지만 FCFS는 요청이 위치한 트랙(Track)의 위치를 고려하지 않는다. 따라서 처리 순서에 따라 디스크 헤드(Disk Head)의 이동 경로가 비효율적으로 길어질 수 있다. 특히 멀리 떨어진 요청이 앞에 있으면, 뒤에 있는 요청들이 오래 기다리는 문제가 발생할 수 있다.

예를 들어 요청 순서가 15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20이라고 하자. FCFS는 도착한 순서를 그대로 처리하므로 헤드는 이 순서대로 이동한다.

15에서 8로 이동하면 7만큼 이동하고, 8에서 17로 이동하면 9만큼 이동한다. 이후 17에서 11은 6, 11에서 3은 8, 3에서 23은 20, 23에서 19는 4, 19에서 14는 5, 14에서 20은 6만큼 이동한다.

이를 모두 더하면 총 헤드 이동 거리(Total Head Movement)는 다음과 같다.

7 + 9 + 6 + 8 + 20 + 4 + 5 + 6 = 65

즉, FCFS는 요청 순서를 그대로 따르기 때문에 헤드가 좌우로 여러 번 이동할 수 있다. 이로 인해 불필요한 이동 거리가 증가하고, 전체 접근 시간(Disk Access Time)이 길어질 수 있다.

정리하면 FCFS는 구조가 단순하고 공정하지만, 디스크 헤드의 이동 거리를 줄이는 데에는 효율적이지 않을 수 있는 방식이다.

추가로 알아두면 좋은 점

이 계산에서는 주어진 요청들 사이의 이동 거리만 더한 것이다. 만약 초기 헤드 위치(Initial Head Position)가 따로 주어진다면, 초기 위치에서 첫 번째 요청인 15번 트랙까지 이동하는 거리도 함께 계산해야 한다.

SSTF Disk Scheduling(SSTF 디스크 스케줄링)

SSTF(Shortest Seek Time First) 스케줄링은 현재 디스크 헤드(Disk Head) 위치를 기준으로 가장 가까운 요청을 먼저 처리하는 방식이다. 즉, 매 단계마다 이동 거리가 가장 짧은 요청을 선택하여 탐색 시간(Seek Time)을 줄이도록 동작한다.

이 방식은 FCFS(First-Come, First-Served)보다 평균 탐색 시간(Average Seek Time)을 줄일 수 있어 처리 효율이 향상된다는 장점이 있다. 하지만 가까운 요청만 계속 선택하게 되면, 멀리 있는 요청은 오랫동안 처리되지 못할 수 있다. 이처럼 특정 요청이 계속 지연되는 문제를 기아 현상(Starvation)이라고 한다.

그림은 SSTF 방식으로 요청을 처리할 때 헤드가 실제로 이동하는 경로를 보여준다. 현재 헤드 위치가 15라고 하면, 가장 가까운 요청을 우선 선택한다.

15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙번호이지만 가까운 위치를 계속 선택하기 때문에

15 → 14 → 17 → 19 → 20 → 23 → 11 → 8 → 3 로 이동 된 것이다.

먼저 15에서 14로 이동하면 1만큼 이동한다. 그다음 14에서 17로 3만큼, 17에서 19로 2만큼, 19에서 20으로 1만큼 이동한다. 이후 20에서 23으로 3만큼 이동한다.

그다음 남아 있는 요청 중 가장 가까운 위치를 계속 선택하여 11, 8, 3 순서로 처리한다. 이때 23에서 11은 12, 11에서 8은 3, 8에서 3은 5만큼 이동한다.

따라서 총 헤드 이동 거리(Total Head Movement)는 다음과 같다.

1 + 3 + 2 + 1 + 3 + 12 + 3 + 5 = 30

즉, SSTF는 가까운 요청을 우선 처리하기 때문에 헤드가 좌우로 크게 왕복하는 이동을 줄일 수 있다. 그 결과 총 이동 거리가 30으로 계산되며, 앞서 살펴본 FCFS의 65보다 훨씬 효율적인 결과를 보인다.

정리하면 SSTF는 평균 탐색 시간을 줄이는 데 효과적이지만, 멀리 떨어진 요청이 계속 밀릴 수 있다는 점을 함께 고려해야 하는 방식이다.

추가로 알아두면 좋은 점

SSTF(Shortest Seek Time First)는 현재 위치에서 가장 가까운 요청을 선택하기 때문에 평균 성능은 좋아질 수 있다. 하지만 항상 전체 최적의 이동 경로를 보장하는 것은 아니다.

또한 가까운 요청이 계속 새로 들어오면 먼 위치의 요청은 계속 뒤로 밀릴 수 있으므로, 기아 현상(Starvation)이 발생할 가능성이 있다는 점이 중요하다.

SCAN Disk Scheduling(SCAN 디스크 스케줄링)

SCAN 스케줄링(SCAN Scheduling)은 디스크 헤드(Disk Head)가 한 방향으로 이동하면서 이동 경로에 있는 요청들을 순차적으로 처리하는 방식이다. 한쪽 끝까지 이동한 뒤에는 방향을 반대로 바꾸어 다시 요청을 처리한다.

이 방식은 엘리베이터가 위아래로 이동하면서 지나가는 층의 요청을 처리하는 방식과 비슷하기 때문에 엘리베이터 알고리즘(Elevator Algorithm)이라고도 불린다.

SCAN은 헤드 이동 경로가 비교적 일정하기 때문에 예측 가능성(Predictability)이 높고, 안정적인 처리가 가능하다. 또한 SSTF(Shortest Seek Time First)처럼 가까운 요청만 계속 선택하는 방식이 아니기 때문에 특정 요청이 계속 밀리는 기아 현상(Starvation)이 발생할 가능성이 상대적으로 낮다.

15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙 번호

15 → 14 → 11 → 8 → 3 → 0 → 17 → 19 → 20 → 23 SCAN 스케줄링의 이동순서

그림에서는 현재 헤드가 15번 트랙에서 시작해 한쪽 방향으로 이동한다. 먼저 14번 트랙을 처리하고, 이어서 11, 8, 3 순서로 요청을 처리한다. 이후 디스크의 끝 방향인 0번 위치까지 이동한 뒤 방향을 바꾸어 반대쪽으로 이동한다.

반대 방향으로 이동하면서 17, 19, 20, 23 순서로 요청을 처리한다. 즉, 중간에 방향을 바꾸지 않고 한 방향으로 끝까지 이동한 뒤 다시 돌아오면서 요청을 처리하는 방식이다.

이 예제에서 총 헤드 이동 거리(Total Head Movement)는 약 38로 계산된다. 따라서 SCAN은 FCFS(First-Come, First-Served)보다 더 효율적이며, 동시에 공정성(Fairness)도 함께 고려한 방식이라고 할 수 있다.

추가로 알아두면 좋은 점

SCAN은 한 방향으로 이동하면서 요청을 처리하기 때문에 헤드 이동이 비교적 규칙적이다. 그래서 FCFS보다 불필요한 왕복 이동을 줄일 수 있고, SSTF보다 특정 요청이 오래 밀릴 가능성도 낮다.

다만 계산에서 디스크의 끝을 어디까지 포함하느냐에 따라 총 이동 거리가 달라질 수 있다. 요청이 있는 마지막 트랙인 23까지만 계산하면 15 → 0 → 23이므로 총 이동 거리는 38이다. 만약 실제 디스크 끝인 24까지 이동한다고 계산하면 총 이동 거리는 39가 된다.

C-SCAN Disk Scheduling(C-SCAN 디스크 스케줄링)

C-SCAN(Circular SCAN) 스케줄링은 디스크 헤드(Disk Head)가 한 방향으로만 이동하면서 경로상에 있는 요청들을 순차적으로 처리하는 방식이다.

SCAN과 마찬가지로 이동 중에 만나는 요청을 처리하지만, 끝 지점에 도달했을 때 반대 방향으로 요청을 처리하지 않는다. 대신 처음 위치로 다시 이동한 뒤, 다시 같은 방향으로 요청을 처리한다.

즉, C-SCAN은 디스크를 원형 구조처럼 보고 한 방향으로 순환하면서 요청을 처리하는 방식이라고 할 수 있다.

이 방식은 모든 요청이 비슷한 방식으로 서비스를 받기 때문에 대기 시간(Waiting Time)의 편차가 비교적 작다. 따라서 요청을 균등하게 처리할 수 있고, 특정 구간의 요청만 반복적으로 유리해지는 현상을 줄일 수 있다. 이런 점에서 공정성(Fairness)이 높은 스케줄링 방식이라고 볼 수 있다.

예제에서 현재 헤드가 15번 트랙에서 시작한다고 하자. C-SCAN은 한쪽 방향으로 먼저 이동하면서 14, 11, 8, 3 순서로 요청을 처리한다. 이후 디스크의 끝 방향인 0번 위치까지 이동한다.

그다음에는 반대 방향으로 요청을 처리하지 않고, 바로 반대쪽 끝인 24번 위치로 이동한다. 이후 다시 같은 방향으로 이동하면서 23, 20, 19, 17 순서로 요청을 처리한다.

즉, C-SCAN은 한 방향의 처리 흐름만 유지하고, 끝에 도달하면 시작 지점으로 순환해서 다시 같은 방향으로 처리하는 방식이다.

이 예제에서 총 헤드 이동 거리(Total Head Movement)는 46으로 계산된다. SCAN보다 이동 거리는 늘어날 수 있지만, 대기 시간의 편차를 줄이고 요청을 더 균등하게 처리할 수 있는 방식이라고 이해할 수 있다.

추가로 알아두면 좋은 점

C-SCAN은 SCAN보다 공정한 대기 시간 분포를 제공하는 것이 목적이다. SCAN은 방향을 바꾼 뒤 바로 근처 요청을 다시 처리할 수 있기 때문에 특정 위치의 요청이 상대적으로 유리할 수 있다.

반면 C-SCAN은 한 방향으로만 서비스를 제공하므로, 요청들이 좀 더 일정한 주기로 처리된다. 다만 끝에서 반대쪽 끝으로 돌아가는 이동은 실제 요청을 처리하지 않는 이동이므로 총 헤드 이동 거리는 증가할 수 있다.

LOOK Disk Scheduling(LOOK 디스크 스케줄링)

LOOK 스케줄링(LOOK Scheduling)은 기본 동작 방식이 SCAN스케줄링(SCAN Scheduling)과 유사하지만, 디스크의 끝까지 이동하지 않는 방식이다.

SCAN은 한 방향으로 이동하면서 요청을 처리한 뒤 디스크의 끝까지 이동했다. LOOK은 현재 이동 방향에 요청이 존재하는 마지막 위치까지만 이동한다. 그 지점에서 방향을 바꾸어 다시 반대 방향의 요청을 처리한다.

즉, 요청이 없는 구간까지 불필요하게 이동하지 않기 때문에 디스크 헤드(Disk Head)의 이동 거리를 줄일 수 있다. 그 결과 접근 시간(Access Time)이 개선되고, 전체 처리 효율도 높아질 수 있다.

LOOK 방식은 SCAN의 장점을 유지하면서 불필요한 이동을 줄인 개선형 방식이라고 할 수 있다. 이러한 이유로 실제 환경에서는 SCAN보다 더 효율적으로 사용될 수 있다.

15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙번호

15 → 14 → 11 → 8 → 3 → 17 → 19 → 20 → 23 LOOK스케줄링 이동순서

그림을 기준으로 보면, 헤드는 15번 트랙에서 시작해 한쪽 방향으로 이동한다. 이동 과정에서 14, 11, 8, 3 순서로 요청을 처리한다. SCAN과 달리 요청이 없는 0번 끝까지 이동하지 않고, 마지막 요청 위치인 3번에서 방향을 바꾼다.

이후 반대 방향으로 이동하면서 17, 19, 20, 23 순서로 요청을 처리한다. 즉, 요청이 존재하는 범위까지만 이동하고, 불필요한 끝 구간 이동은 생략하는 방식이다.

따라서 LOOK 알고리즘은 SCAN보다 헤드 이동 거리를 줄일 수 있으며, 요청 처리의 효율성을 높일 수 있는 방식이다.

추가로 알아두면 좋은 점

또한 주어진 요청 집합을 기준으로 계산하면, LOOK의 이동 경로는 15 → 14 → 11 → 8 → 3 → 17 → 19 → 20 → 23이다. 이 경우 총 이동 거리는 다음과 같다.

1 + 3 + 3 + 5 + 14 + 2 + 1 + 3 = 32

따라서 이 요청 기준에서는 LOOK의 총 이동 거리는 32로 계산하는 것이 더 정확하다. 다만 강의 자료에서 시작점이나 끝점 포함 방식이 다르게 설정되어 있다면 계산값이 달라질 수 있다.

C-LOOK Disk Scheduling(C-LOOK 디스크 스케줄링)

C-LOOK 스케줄링(C-LOOK Scheduling)은 기본적으로 LOOK 스케줄링(LOOK Scheduling)과 유사하지만, 한 방향으로만 요청을 처리하는 방식이다.

현재 방향으로 이동하면서 요청을 처리하다가 마지막 요청 위치에 도달하면 방향을 바꾸지 않는다. 대신 반대편에 있는 첫 번째 요청 위치로 바로 이동한 뒤, 다시 같은 방향으로 요청을 처리한다.

즉, C-LOOK은 LOOK의 장점처럼 요청이 없는 디스크 끝 지점까지 불필요하게 이동하지 않는다. 동시에 C-SCAN(Circular SCAN)처럼 한 방향으로 순환 처리하기 때문에 비교적 균등한 요청 처리가 가능하다.

따라서 C-LOOK은 헤드 이동 거리(Head Movement Distance)를 줄이면서도 공정성(Fairness)을 함께 고려한 효율적인 디스크 스케줄링 방식이라고 할 수 있다. C-SCAN과 비교하면 실제 요청이 없는 끝 지점까지 이동하지 않기 때문에 더 효율적인 순환 처리가 가능하다.

15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙번호

15 → 14 → 11 → 8 → 3 → 23 → 20 → 19 → 17 C-LOOK 이동순서

그림을 기준으로 보면, 현재 헤드(Disk Head)는 15번 트랙에서 시작해 한쪽 방향으로 이동한다. 그 과정에서 14, 11, 8, 3 순서로 요청을 처리한다.

이후 LOOK처럼 반대 방향으로 되돌아가며 처리하지 않고, 마지막 요청인 3번에서 반대편의 첫 번째 요청 위치인 23번으로 바로 이동한다. 그다음 같은 방향으로 다시 이동하면서 20, 19, 17 순서로 요청을 처리한다.

즉, C-LOOK은 요청이 존재하는 구간만 순환하면서 처리하고, 요청이 없는 끝 지점 이동은 생략하는 방식이다.

이 예제에서 총 헤드 이동 거리(Total Head Movement)는 38로 계산된다. C-SCAN보다 이동 거리를 줄이면서도 순환 처리의 공정성을 유지할 수 있는 방식이다.

정리하면 C-LOOK은 LOOK과 C-SCAN의 장점을 결합한 개선형 순환 스케줄링 방식이라고 이해할 수 있다.

추가로 알아두면 좋은 점

C-LOOK은 C-SCAN과 달리 디스크의 실제 끝까지 이동하지 않고, 요청이 있는 마지막 위치까지만 이동한다. 그래서 불필요한 헤드 이동을 줄일 수 있다.

이 예제의 이동 경로는 15 → 14 → 11 → 8 → 3 → 23 → 20 → 19 → 17로 볼 수 있다. 총 이동 거리는 다음과 같다.

1 + 3 + 3 + 5 + 20 + 3 + 1 + 2 = 38

따라서 강의에서 제시한 총 이동 거리 38은 이 경로를 기준으로 하면 맞는 계산이다.

Comparison of Disk Scheduling Algorithms

지금까지 여러 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)을 살펴보았다. 각 알고리즘에 따라 디스크 헤드(Disk Head)의 이동 경로와 총 이동 거리(Total Head Movement)가 달라진다는 것을 확인할 수 있었다.

헤드의 이동 거리가 달라지면 탐색 시간(Seek Time)도 달라지고, 그 결과 전체 디스크 접근 시간(Disk Access Time)과 성능(Disk Performance)에도 차이가 발생한다.

일반적으로 헤드의 평균 이동 거리(Average Head Movement)가 짧을수록 탐색 시간이 감소하므로 성능 향상에 유리하다. 예를 들어 SSTF(Shortest Seek Time First)는 현재 위치에서 가장 가까운 요청을 먼저 처리하기 때문에 이동 거리를 줄이는 데 효과적이다.

하지만 SSTF는 가까운 요청만 계속 선택할 경우, 멀리 있는 요청이 오랫동안 처리되지 못하는 기아 현상(Starvation)이 발생할 수 있다.

반면 SCAN 계열 알고리즘(SCAN-Based Algorithm)은 헤드 이동 경로가 비교적 일정하고, 요청을 균형 있게 처리할 수 있다. 따라서 성능(Performance)과 공정성(Fairness) 사이의 균형을 제공하는 방식이라고 할 수 있다.

결국 어떤 디스크 스케줄링 알고리즘이 항상 가장 좋다고 보기는 어렵다. 시스템 환경(System Environment), 요청 패턴(Request Pattern), 공정성 요구(Fairness Requirement), 성능 목표(Performance Goal)에 따라 적절한 방식을 선택하는 것이 중요하다.

추가로 알아두면 좋은 점

디스크 스케줄링(Disk Scheduling)은 주로 HDD(Hard Disk Drive)처럼 헤드 이동이 필요한 저장장치에서 중요한 의미를 가진다. SSD(Solid State Drive)는 물리적인 헤드 이동이 없기 때문에 HDD와 같은 방식의 탐색 시간 최적화 효과는 상대적으로 작다.

정리하면, FCFS는 단순하고 공정하지만 비효율적일 수 있고, SSTF는 이동 거리를 줄이지만 기아 현상이 생길 수 있다. SCAN, C-SCAN, LOOK, C-LOOK은 헤드 이동 방향을 기준으로 요청을 처리하여 성능과 공정성의 균형을 맞추려는 방식이다.

Auxiliary Disk Optimization Methods(디스크 성능 향상을 위한 보조 최적화 방법)

지금까지 디스크 스케줄링(Disk Scheduling)을 통해 요청 처리 순서(Request Processing Order)를 조정하는 방법을 살펴보았다. 하지만 디스크 성능 향상(Disk Performance Improvement)은 스케줄링만으로 이루어지는 것은 아니다.

이를 보완하기 위해 다양한 보조 최적화 방법(Auxiliary Optimization Method)이 함께 사용된다.

대표적으로 디스크 요청 재정렬(Request Reordering)을 통해 헤드 이동 거리(Head Movement Distance)를 줄일 수 있다. 요청을 그대로 처리하는 것이 아니라, 더 효율적인 순서로 다시 정렬하면 탐색 시간(Seek Time)을 줄이는 데 도움이 된다.

또한 Read-Ahead 기법은 앞으로 필요할 가능성이 높은 데이터를 미리 읽어두는 방식이다. 특히 연속 접근(Sequential Access)이 많은 경우, 다음에 사용할 데이터를 미리 준비해두면 접근 성능을 높일 수 있다.

Write Buffering은 여러 쓰기 요청(Write Request)을 바로 처리하지 않고 버퍼(Buffer)에 모아두었다가 한 번에 처리하는 방식이다. 이를 통해 디스크 접근 횟수(Disk Access Count)를 줄이고, 쓰기 성능을 향상시킬 수 있다.

여기에 운영체제 캐시(OS Cache)와 저장장치 내부 캐시(Device Cache)를 함께 활용하면 전체 접근 속도(Access Speed)를 더 향상시킬 수 있다.

즉, 디스크 성능을 높이기 위해서는 스케줄링뿐만 아니라 요청 재정렬, Read-Ahead, Write Buffering, Cache와 같은 보조 최적화 방법을 함께 사용하는 것이 중요하다. 이후에는 이러한 방법들을 하나씩 살펴본다.

추가로 알아두면 좋은 점

Read-Ahead는 순차적으로 데이터를 읽을 때 효과적이지만, 임의 접근(Random Access)이 많을 경우에는 미리 읽은 데이터가 실제로 사용되지 않아 효율이 떨어질 수 있다.

Write Buffering은 성능을 높이는 데 도움이 되지만, 데이터가 실제 디스크에 기록되기 전에 전원이 꺼지면 데이터 손실 위험이 있을 수 있다. 그래서 운영체제는 동기화(Synchronization)나 플러시(Flush) 같은 방식으로 안정성을 함께 관리한다.

Request Reordering(요청 재정렬)

요청 재정렬(Request Reordering)은 디스크 요청(Disk Request)의 처리 순서를 다시 구성하여 더 효율적으로 처리하는 방법이다.

디스크 요청을 도착한 순서 그대로 처리하는 것이 아니라, 서로 가까운 위치에 있는 요청들을 묶어서 처리하면 디스크 헤드(Disk Head)의 이동 거리를 줄일 수 있다.

이렇게 하면 헤드가 불필요하게 멀리 이동했다가 다시 돌아오는 동작을 줄일 수 있고, 그 결과 탐색 시간(Seek Time)과 전체 접근 시간(Disk Access Time)을 감소시키는 효과가 있다.

요청 재정렬은 앞에서 살펴본 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)과 함께 사용되며, 전체 디스크 처리 효율(Disk Processing Efficiency)을 높이는 데 기여한다.

추가로 알아두면 좋은 점

요청 재정렬은 성능 향상에는 도움이 되지만, 특정 요청이 계속 뒤로 밀리지 않도록 공정성(Fairness)도 함께 고려해야 한다.

즉, 가까운 요청만 계속 우선 처리하면 일부 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있기 때문에, 성능과 공정성 사이의 균형이 중요하다.

Read-Ahead(미리 읽기)

Read-Ahead는 앞으로 필요할 것으로 예상되는 데이터를 미리 읽어 두는 방식이다. 즉, 아직 요청되지 않은 데이터라도 곧 필요할 가능성이 높다고 판단되면 미리 읽어서 캐시(Cache)에 저장해둔다.

이 방식은 특히 파일을 순차적으로 읽는 순차 접근(Sequential Access) 상황에서 효과적이다. 현재 데이터를 읽고 있다면, 그다음 데이터도 연속해서 필요할 가능성이 높기 때문이다.

미리 읽어둔 데이터가 실제로 요청되면, 다시 디스크(Disk)에 접근하지 않고 캐시에서 바로 전달할 수 있다. 이를 통해 디스크 접근 횟수(Disk Access Count)를 줄이고, 전체 읽기 성능(Read Performance)을 향상시킬 수 있다.

하지만 예측이 빗나가면 문제가 될 수 있다. 미리 읽어둔 데이터가 실제로 사용되지 않는다면 불필요한 입출력(I/O)이 발생하고, 캐시 공간(Cache Space)도 낭비될 수 있다.

따라서 Read-Ahead는 앞으로 사용할 가능성이 높은 데이터를 미리 준비하여 접근 속도를 높이는 최적화 기법이라고 이해할 수 있다.

추가로 알아두면 좋은 점

Read-Ahead는 순차 접근(Sequential Access)에서는 효과적이지만, 랜덤 접근(Random Access)이 많은 경우에는 효율이 떨어질 수 있다.

즉, 다음에 어떤 데이터를 읽을지 예측하기 쉬운 상황에서는 성능 향상에 도움이 되지만, 접근 위치가 계속 바뀌는 경우에는 불필요한 데이터까지 읽게 될 수 있다.

Write Buffering(쓰기 버퍼링)

Write Buffering은 쓰기 성능(Write Performance)을 높이기 위한 최적화 방법이다. 데이터를 즉시 디스크(Disk)에 기록하지 않고, 먼저 메모리 버퍼(Memory Buffer)에 저장한 뒤 나중에 한꺼번에 처리하는 방식이다.

이 방식은 여러 개의 작은 쓰기 요청(Write Request)을 모아서 처리할 수 있기 때문에 디스크 접근 횟수(Disk Access Count)를 줄이는 데 도움이 된다. 디스크에 매번 접근하는 대신 일정량의 데이터를 모아 한 번에 기록하면 전체 입출력 성능(I/O Performance)을 향상시킬 수 있다.

특히 순차적인 쓰기 작업(Sequential Write)이 많은 환경에서는 Write Buffering이 효율적으로 동작할 수 있다. 작은 쓰기 요청들을 모아 연속적으로 처리하면 디스크 접근이 더 효율적으로 이루어지기 때문이다.

하지만 버퍼에만 저장된 상태에서 시스템 장애(System Failure)나 전원 문제(Power Failure)가 발생하면, 아직 디스크에 기록되지 않은 일부 데이터가 손실될 가능성이 있다.

따라서 Write Buffering은 쓰기 성능을 높이는 데 효과적이지만, 데이터 안정성(Data Reliability)을 함께 고려해야 하는 방식이다.

추가로 알아두면 좋은 점

Write Buffering은 성능 향상에는 도움이 되지만, 데이터가 실제 디스크에 기록되기 전까지는 손실 위험이 있다. 그래서 운영체제(Operating System)는 플러시(Flush)나 동기화(Synchronization)를 통해 버퍼에 있는 데이터를 디스크에 반영한다.

예를 들어 sync 같은 동작은 메모리 버퍼에 있는 변경 내용을 실제 저장장치에 기록하도록 하는 역할을 한다.

Improving Access Speed with Cache

읽기(Read)와 쓰기(Write) 성능을 높이는 방법 외에도, 자주 사용하는 데이터를 빠르게 제공하기 위해 캐시(Cache) 방식이 함께 사용된다.

캐시는 자주 접근하는 데이터(Frequently Accessed Data)를 메모리(Memory)에 임시로 저장해두는 구조이다. 이후 같은 데이터가 다시 요청되면 디스크(Disk)에 직접 접근하지 않고, 메모리에서 빠르게 제공할 수 있다.

이 방식은 같은 데이터를 반복해서 사용하는 경우에 효과적이다. 디스크 접근 횟수(Disk Access Count)를 줄일 수 있기 때문에 입출력 대기 시간(I/O Waiting Time)을 크게 줄이는 데 도움이 된다.

또한 캐시는 Read-Ahead와 함께 사용될 수 있다. 앞으로 필요할 가능성이 높은 데이터를 미리 읽어 캐시에 저장해두면, 실제 요청이 들어왔을 때 더 빠르게 데이터를 전달할 수 있다.

캐시에는 운영체제(Operating System)가 관리하는 운영체제 캐시(OS Cache)도 있고, 디스크 장치 내부에 포함된 하드웨어 캐시(Hardware Cache)도 있다. 두 캐시가 함께 사용되면 전체 저장장치 접근 속도(Storage Access Speed)를 더 향상시킬 수 있다.

다만 캐시의 효율은 어떤 데이터를 오래 유지하고, 어떤 데이터를 교체할 것인지에 따라 달라진다. 따라서 캐시 교체 정책(Cache Replacement Policy)도 저장장치 성능을 결정하는 중요한 요소라고 할 수 있다.

추가로 알아두면 좋은 점

캐시는 자주 사용되는 데이터를 빠르게 제공할 수 있지만, 캐시 공간(Cache Space)은 제한되어 있다. 그래서 운영체제는 LRU(Least Recently Used)와 같은 캐시 교체 정책(Cache Replacement Policy)을 사용해 어떤 데이터를 유지하고 제거할지 결정한다.

또한 쓰기 캐시(Write Cache)의 경우, 데이터가 실제 디스크에 기록되기 전에 장애가 발생하면 데이터 손실 위험이 있을 수 있으므로 안정성 관리도 함께 필요하다.

RAID Storage Configuration(RAID 저장장치 구성 방식)

지금까지는 하나의 디스크(Disk)의 접근 성능(Access Performance)을 높이는 방법을 살펴보았다. 이번에는 여러 개의 디스크를 함께 사용하여 성능과 안정성을 높이는 RAID 구조(RAID Structure)에 대해 알아본다.

RAID(Redundant Array of Independent Disks)는 여러 개의 물리적 디스크(Physical Disk)를 묶어서 하나의 논리적인 저장장치(Logical Storage Device)처럼 사용하는 방식이다.

RAID를 사용하면 데이터 입출력(Input/Output)을 여러 디스크에 나누어 처리할 수 있다. 이를 통해 하나의 디스크만 사용할 때보다 성능 향상(Performance Improvement)을 기대할 수 있다.

또한 데이터를 여러 디스크에 분산 저장(Distributed Storage)하거나 중복 저장(Redundant Storage)함으로써, 일부 디스크에 장애(Failure)가 발생하더라도 데이터 안정성(Data Reliability)을 높일 수 있다.

즉, RAID는 저장장치의 성능 향상과 데이터 보호(Data Protection)를 함께 고려한 저장장치 구성 방식이라고 이해할 수 있다.

추가로 알아두면 좋은 점

RAID는 목적에 따라 성능을 높이는 방식과 안정성을 높이는 방식이 다르다. 예를 들어 RAID 0은 데이터를 여러 디스크에 나누어 저장해 성능을 높이지만, 중복 저장이 없어 디스크 하나가 고장 나면 데이터 손실 위험이 크다.

반면 RAID 1은 같은 데이터를 두 개 이상의 디스크에 복제하여 안정성을 높이는 방식이다. 이후 RAID 0, RAID 1, RAID 5처럼 RAID 수준(RAID Level)에 따라 특징이 달라진다고 이해하면 좋다.

RAID Levels(RAID 수준)

RAID(Redundant Array of Independent Disks)는 하나의 방식만 존재하는 것이 아니라, 디스크를 구성하는 방법에 따라 여러 수준(Level)으로 나뉜다.

대표적인 RAID 수준에는 RAID 0, RAID 1, RAID 2, RAID 3, RAID 4, RAID 5, RAID 6이 있다. 각 수준마다 데이터 저장 방식(Data Storage Method), 성능 향상 방식(Performance Improvement Method), 장애 대응 방식(Fault Tolerance Method)이 다르게 구성된다.

또한 RAID 0+1, RAID 1+0처럼 두 가지 RAID 방식을 결합한 조합 구조(Nested RAID)도 존재한다. 이러한 방식은 성능과 안정성을 함께 고려하기 위해 사용된다.

다만 이번 내용에서는 모든 RAID 수준을 세부적으로 다루기보다는, RAID의 기본 원리를 이해하는 데 핵심이 되는 RAID 0, RAID 1, RAID 5를 중심으로 살펴본다.

추가로 알아두면 좋은 점

RAID 0은 성능 향상에 초점을 둔 방식이고, RAID 1은 데이터 복제(Mirroring)를 통한 안정성 향상에 초점을 둔 방식이다.

RAID 5는 데이터와 패리티(Parity)를 여러 디스크에 분산 저장하여 성능과 안정성을 함께 고려하는 방식이다. 따라서 RAID의 기본 개념을 이해할 때는 RAID 0, RAID 1, RAID 5를 중심으로 비교하면 좋다.

RAID 0: Striping(RAID 0: 스트라이핑)

RAID 0은 데이터를 여러 디스크(Disk)에 나누어 저장하는 방식으로, 분산 저장(Distributed Storage) 또는 스트라이핑(Striping) 방식이라고도 한다.

그림을 보면 데이터 A, B, C, D가 각각 다른 디스크에 나누어 저장되고, 그다음 데이터 E, F, G, H도 각 디스크에 분산되어 기록되는 구조를 확인할 수 있다.

이처럼 데이터를 일정한 단위로 나누어 여러 디스크에 동시에 저장하는 방식을 스트라이핑(Striping)이라고 한다. 여러 디스크가 동시에 읽기(Read)와 쓰기(Write)에 참여할 수 있기 때문에 입출력 성능(I/O Performance)을 높일 수 있다.

또한 모든 디스크의 저장 공간을 데이터 저장에 사용할 수 있으므로 저장 공간 활용(Storage Utilization)도 효율적이다.

하지만 RAID 0은 중복 저장(Redundancy)이나 오류 복구 정보(Recovery Information)를 제공하지 않는다. 따라서 디스크 하나만 고장 나더라도 전체 데이터 복구가 어려워질 수 있다.

즉, RAID 0은 데이터 안정성(Data Reliability)보다는 성능(Performance)을 우선하는 환경에 적합한 방식이라고 이해할 수 있다.

추가로 알아두면 좋은 점

RAID 0은 이름에 RAID가 들어가지만, 실제로는 중복성(Redundancy)이 없다. 따라서 중요한 데이터를 안전하게 보관하기 위한 방식이라기보다는, 빠른 읽기와 쓰기 성능이 필요한 경우에 사용하는 방식으로 이해하는 것이 좋다.

RAID 1: Mirroring (RAID 1: 미러링)

RAID 1은 동일한 데이터를 두 개 이상의 디스크(Disk)에 동시에 복사해서 저장하는 방식이다. 이 방식을 미러링(Mirroring)이라고도 한다.

하나의 디스크에 기록된 내용이 다른 디스크에도 그대로 저장되기 때문에, 같은 데이터가 여러 곳에 존재하게 된다. 따라서 디스크 하나에 장애(Failure)가 발생하더라도 다른 디스크에 남아 있는 데이터를 이용해 서비스를 계속할 수 있다.

RAID 1은 읽기(Read) 작업을 여러 디스크에 나누어 처리할 수 있기 때문에 읽기 성능(Read Performance)이 향상될 수 있다. 하지만 같은 데이터를 중복 저장(Redundant Storage)하기 때문에 실제 사용 가능한 저장 공간(Storage Capacity)의 효율은 낮아진다.

그림으로 보면, 왼쪽 디스크에 ABCD가 저장되면 바로 옆 디스크에도 동일한 ABCD가 그대로 복사되어 저장된다. 마찬가지로 EFGH, IJKL, MNOP도 각각 한 쌍의 디스크에 동일하게 복제된다.

즉, 두 개의 디스크가 하나의 데이터 집합(Data Set)을 함께 보관하는 구조라고 볼 수 있다. 이처럼 동일한 데이터를 동시에 저장해두기 때문에 한쪽 디스크에 문제가 생겨도 다른 디스크를 이용해 데이터를 계속 사용할 수 있다.

정리하면 RAID 1은 저장 공간 효율(Storage Efficiency)은 낮지만, 데이터 안정성(Data Reliability)이 매우 중요한 환경에 적합한 방식이다.

추가로 알아두면 좋은 점

RAID 1은 데이터 보호(Data Protection)에 강하지만, 백업(Backup)을 완전히 대체하는 것은 아니다. 예를 들어 사용자가 실수로 파일을 삭제하거나, 악성코드로 데이터가 손상되면 복제된 디스크에도 같은 변경이 반영될 수 있다.

따라서 RAID 1은 디스크 고장에 대비하는 방식이고, 중요한 데이터는 별도의 백업도 함께 필요하다고 이해하면 좋다.

RAID 5: Distributed Parity(RAID 5: 분산 패리티)

RAID 5는 패리티(Parity) 기반의 저장 방식이다. 데이터 블록(Data Block)과 패리티 정보를 여러 디스크(Disk)에 분산해서 저장하는 구조이다.

여기서 패리티(Parity)는 디스크 장애가 발생했을 때 손실된 데이터를 복구하기 위한 계산 정보라고 이해할 수 있다. 여러 디스크 중 하나에 장애(Failure)가 발생하더라도, 남아 있는 데이터와 패리티 정보를 이용해 손실된 데이터를 복구할 수 있다.

RAID 5는 읽기 작업(Read Operation)이 여러 디스크에 분산되어 수행되기 때문에 읽기 성능(Read Performance)을 높일 수 있다. 또한 패리티를 통해 장애 복구가 가능하므로 성능(Performance)과 안정성(Reliability) 사이에서 비교적 균형 잡힌 구조를 제공한다.

다만 데이터를 기록할 때는 패리티를 함께 계산하고 저장해야 한다. 따라서 쓰기 작업(Write Operation)에서는 추가적인 패리티 계산 과정이 필요하며, 이로 인해 쓰기 성능(Write Performance)이 저하될 수 있다.

RAID 5는 최소 3개의 디스크가 필요하며, 저장 공간 효율(Storage Efficiency), 읽기 성능, 장애 복구 기능을 함께 고려할 수 있어 일반적인 서버 환경(Server Environment)에서 널리 사용되는 방식이다.

그림으로 보면 각 디스크에는 데이터 블록과 패리티 블록(Parity Block)이 함께 저장된다. 이때 패리티는 특정 디스크 하나에 고정되지 않고 여러 디스크에 분산되어 배치된다.

예를 들어 첫 번째 줄에서는 마지막 디스크에 Parity 0이 저장되고, 다음 줄에서는 다른 디스크에 Parity 1이 저장되는 방식으로 패리티 위치가 바뀐다. 이렇게 패리티를 분산하면 특정 디스크 하나에 패리티 처리 부담이 집중되는 것을 줄일 수 있다.

만약 디스크 하나에 장애가 발생하더라도, 같은 줄에 남아 있는 데이터 블록들과 패리티 정보를 이용해 손실된 블록을 다시 계산할 수 있다.

정리하면 RAID 5는 데이터를 분산 저장하면서 패리티를 함께 관리하여, 저장 공간 효율, 읽기 성능, 장애 복구 기능을 모두 고려한 실용적인 RAID 방식이라고 이해할 수 있다.

추가로 알아두면 좋은 점

RAID 5는 디스크 1개 장애까지는 복구할 수 있지만, 동시에 2개 이상의 디스크가 고장 나면 데이터 복구가 어려울 수 있다. 2개 디스크 장애까지 대비하려면 RAID 6처럼 이중 패리티(Double Parity)를 사용하는 방식이 필요하다.

또한 RAID 5는 패리티 계산 때문에 작은 쓰기 작업(Random Write)이 많은 환경에서는 성능이 떨어질 수 있다. 따라서 읽기 작업이 많고 저장 공간 효율과 안정성을 함께 고려해야 하는 환경에 적합하다.

Comparison of RAID Performance and Reliability(RAID 성능과 안정성 비교)

RAID 수준(RAID Level)에 따라 성능(Performance), 안정성(Reliability), 저장 공간 효율(Storage Efficiency)이 달라진다.

RAID 0은 데이터를 여러 디스크(Disk)에 분산 저장(Striping)하기 때문에 입출력 성능(I/O Performance)이 높다는 장점이 있다. 여러 디스크가 동시에 읽기와 쓰기에 참여할 수 있기 때문이다. 하지만 중복 저장(Redundancy)이나 복구 정보(Recovery Information)가 없기 때문에, 디스크 하나에 장애가 발생하면 데이터 보호(Data Protection)를 제공하기 어렵다.

RAID 1은 동일한 데이터를 여러 디스크에 복제 저장(Mirroring)하는 방식이다. 따라서 디스크 하나에 문제가 발생하더라도 다른 디스크에 남아 있는 데이터를 이용할 수 있어 안정성이 매우 높다. 하지만 같은 데이터를 중복해서 저장해야 하므로 실제 사용할 수 있는 저장 공간의 효율은 낮아진다.

RAID 5는 데이터(Data)와 패리티(Parity)를 여러 디스크에 분산 저장하는 방식이다. 이를 통해 읽기 성능(Read Performance)과 장애 복구 기능(Fault Tolerance)을 함께 제공할 수 있다. 따라서 RAID 5는 성능과 안정성 사이에서 비교적 균형 잡힌 방식이라고 할 수 있다.

결국 어떤 RAID 수준이 가장 좋다고 단정하기는 어렵다. 성능이 중요한지, 데이터 안정성이 중요한지, 저장 공간 효율이 중요한지에 따라 적합한 RAID 수준이 달라진다. 따라서 사용 목적(Purpose)과 운영 환경(Operating Environment)에 맞게 적절한 RAID 수준을 선택하는 것이 중요하다.

추가로 알아두면 좋은 점

RAID 0은 성능은 좋지만 안정성이 낮고, RAID 1은 안정성은 높지만 저장 공간 효율이 낮다. RAID 5는 성능, 안정성, 저장 공간 효율을 균형 있게 고려한 방식이다.

다만 RAID는 디스크 고장에 대비하는 기술이지, 백업(Backup)을 완전히 대체하는 기술은 아니다. 실수로 파일을 삭제하거나 데이터가 손상되면 RAID 구성 안에서도 문제가 그대로 반영될 수 있으므로 중요한 데이터는 별도 백업이 필요하다.

Storage Device Practice Overview(저장장치 실습 개요)

앞서 디스크(Disk)의 구조, 접근 시간(Access Time), 성능 향상 기법(Performance Optimization Method)을 살펴보았다. 이제 이러한 개념들이 실제 시스템(System)에서 어떻게 나타나는지 확인하는 실습을 진행한다.

이번 실습에서는 순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 차이를 확인하고, FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First) 스케줄링을 비교한다. 또한 버퍼링(Buffering)과 캐시(Cache)가 성능에 어떤 영향을 주는지도 함께 살펴본다.

첫 번째 실습은 순차 접근과 랜덤 접근의 차이를 확인하는 내용이다. 디스크는 데이터가 저장된 위치와 접근 방식에 따라 접근 시간이 달라질 수 있다.

연속된 위치의 데이터를 차례대로 읽는 순차 접근은 헤드 이동(Head Movement)이나 위치 변경 비용이 적기 때문에 비교적 효율적으로 처리된다.

반면 떨어진 위치의 데이터를 반복해서 읽는 랜덤 접근은 헤드 이동이나 위치 변경 비용이 증가할 수 있다. 이로 인해 순차 접근보다 더 많은 시간이 걸릴 수 있다.

따라서 이번 실습에서는 접근 방식에 따라 왜 성능 차이가 발생하는지 직접 확인해본다.

추가로 알아두면 좋은 점

순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 성능 차이는 특히 HDD(Hard Disk Drive)에서 크게 나타난다. HDD는 헤드 이동과 회전 지연이 있기 때문이다.

반면 SSD(Solid State Drive)는 물리적인 헤드 이동이 없기 때문에 HDD보다 랜덤 접근 성능이 좋지만, 내부 컨트롤러(Controller)와 플래시 메모리(Flash Memory) 구조에 따라 순차 접근과 랜덤 접근 사이의 성능 차이가 완전히 사라지는 것은 아니다.

Sequential Access and Random Access Comparison

순차 접근(Sequential Access)은 현재 위치 다음의 데이터를 연속해서 계속 읽어나가는 방식이다. 반면 랜덤 접근(Random Access)은 필요한 위치로 직접 이동한 뒤 해당 데이터를 읽는 방식이다.

파일 안에서 읽기 위치를 직접 변경할 때는 lseek() 함수를 사용한다. 이번 실습에서는 lseek()를 이용해 접근 위치를 계속 바꾸면서, 위치 변경이 많아질수록 처리 시간이 증가할 수 있다는 점을 확인한다.

그림의 핵심 코드를 보면 먼저 순차 접근은 다음과 같이 이루어진다.

lseek(fd, 0, SEEK_SET);
read(fd, buf, BLOCK_SIZE);

여기서 fd는 열린 파일을 가리키는 파일 디스크립터(File Descriptor)이다. 0은 이동할 위치를 의미하고, SEEK_SET은 파일의 시작 지점(Start Point)을 기준으로 위치를 정하겠다는 의미이다.

이후 read()를 실행하면 현재 오프셋(Offset) 위치에서 BLOCK_SIZE만큼 데이터를 읽어 buf에 저장한다. 한 번 읽고 나면 파일 오프셋은 자동으로 다음 위치로 이동하므로, 반복해서 읽으면 파일을 앞에서부터 차례대로 읽는 순차 접근이 된다.

반면 랜덤 접근은 다음과 같은 방식으로 이루어진다.

offset = (rand() % 1024) * BLOCK_SIZE;
lseek(fd, offset, SEEK_SET);
read(fd, buf, BLOCK_SIZE);

이 코드는 0부터 1023 사이의 임의의 블록 번호를 선택하고, 여기에 BLOCK_SIZE를 곱해 실제 파일 안에서 이동할 위치를 결정한다. 이후 lseek()를 통해 파일 오프셋을 해당 위치로 직접 이동시키고, read()를 통해 그 위치의 데이터를 읽는다.

즉, 순차 접근은 현재 위치에서 다음 데이터를 계속 읽는 방식이고, 랜덤 접근은 lseek()를 이용해 매번 다른 위치로 이동한 뒤 읽는 방식이다.

두 방식을 같은 횟수만큼 반복해서 실행 시간을 비교하면, 접근 위치를 계속 바꾸는 랜덤 접근이 순차 접근보다 더 많은 처리 비용을 가질 수 있다는 점을 확인할 수 있다.

추가로 알아두면 좋은 점

순차 접근은 파일의 다음 위치를 계속 읽기 때문에 운영체제(Operating System)의 Read-Ahead나 캐시(Cache) 효과를 받기 쉽다.

반면 랜덤 접근은 매번 다른 위치로 이동하기 때문에 HDD(Hard Disk Drive)에서는 헤드 이동(Head Movement)과 탐색 시간(Seek Time)의 영향이 커질 수 있다. SSD(Solid State Drive)는 물리적인 헤드 이동이 없기 때문에 랜덤 접근의 부담이 HDD보다 작지만, 순차 접근과 랜덤 접근의 성능 차이가 완전히 사라지는 것은 아니다.

Sequential and Random Access Example Code

이 예제는 순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 실행 시간을 직접 측정하여 성능 차이를 확인하기 위한 코드이다.

먼저 make_test_file() 함수에서는 실험용 파일(Test File)을 생성한다. open() 함수에서 O_CREAT, O_TRUNC, O_WRONLY 옵션을 사용하여 파일이 없으면 새로 만들고, 기존 파일이 있으면 내용을 비운 뒤 쓰기 전용으로 연다.

그다음 여러 개의 블록 데이터(Block Data)를 반복해서 기록한다. 즉, 순차 접근과 랜덤 접근 실험에 사용할 충분한 크기의 파일을 미리 만들어두는 과정이다.

메인 함수(Main Function)에서는 이 파일을 읽기 전용(Read Only)으로 연 뒤, 순차 접근 시간과 랜덤 접근 시간을 각각 측정한다.

순차 접근은 lseek()를 사용해 파일의 시작 위치로 이동한 뒤, 반복문에서 read()만 수행하여 연속된 블록을 차례대로 읽는다. 이 경우 한 번 읽을 때마다 오프셋(Offset)이 자동으로 다음 위치로 이동하므로 파일을 앞에서부터 순서대로 읽게 된다.

반면 랜덤 접근은 rand()를 사용해 임의의 블록 위치를 정하고, lseek()로 매번 다른 위치로 이동한 뒤 read()를 수행한다. 즉, 파일 안의 여러 위치를 반복적으로 이동하면서 데이터를 읽는 방식이다.

마지막으로 clock() 함수를 이용해 순차 접근과 랜덤 접근의 실행 시간을 측정하고 출력한다.

실행 결과를 보면 순차 접근 시간은 0.001248초, 랜덤 접근 시간은 0.004913초로 측정되었다. 같은 양의 데이터를 읽더라도 순차 접근이 랜덤 접근보다 더 빠르게 나타난 것을 확인할 수 있다.

그 이유는 순차 접근은 연속된 위치를 읽기 때문에 위치 변경 비용이 거의 발생하지 않지만, 랜덤 접근은 매번 다른 위치로 이동해야 하므로 추가적인 처리 지연과 탐색 비용(Seek Cost)이 발생할 수 있기 때문이다.

따라서 이 예제는 저장장치(Storage Device)가 연속된 위치를 읽는 접근 방식에 더 유리하며, 디스크 접근 순서(Disk Access Order)가 성능에 영향을 준다는 점을 확인할 수 있는 실습이다.

추가로 알아두면 좋은 점

실습 결과는 실행 환경에 따라 달라질 수 있다. 운영체제 캐시(OS Cache)가 작동하면 두 번째 실행부터는 디스크에서 직접 읽는 것이 아니라 메모리 캐시에서 읽을 수 있기 때문에 시간이 더 짧게 측정될 수 있다.

Disk Scheduling Simulation(디스크 스케줄링 시뮬레이션)

디스크(Disk)는 같은 요청 집합(Request Set)이 들어오더라도, 어떤 순서로 처리하느냐에 따라 접근 비용(Access Cost)이 달라질 수 있다.

즉, 요청 처리 순서(Request Processing Order)에 따라 디스크 헤드(Disk Head)의 이동 거리와 전체 처리 시간(Total Processing Time)이 달라진다. 따라서 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)은 효율적인 요청 처리 순서를 결정하기 위해 필요하다.

이번 실습에서는 대표적인 디스크 스케줄링 방식인 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First)를 비교하여 성능 차이를 직접 확인한다.

디스크 요청(Disk Request)은 일반적으로 큐(Queue) 형태로 순차적으로 도착한다. 운영체제(Operating System)는 이 요청들을 어떤 순서로 처리할지 결정하며, 이 과정이 디스크 스케줄링(Disk Scheduling)이다.

특히 HDD(Hard Disk Drive)에서는 헤드가 이동한 거리가 길어질수록 탐색 시간(Seek Time)이 증가하고, 전체 접근 시간(Disk Access Time)에도 큰 영향을 준다.

따라서 가능한 한 헤드 이동 거리(Head Movement Distance)를 줄이는 방향으로 요청을 처리하면 전체 디스크 성능(Disk Performance)을 개선할 수 있다.

이번 시뮬레이션에서는 FCFS와 SSTF가 같은 요청 집합을 어떻게 다르게 처리하는지 살펴보고, 그 결과 총 헤드 이동 거리(Total Head Movement)가 어떻게 달라지는지 비교한다.

추가로 알아두면 좋은 점

FCFS는 요청이 도착한 순서대로 처리하기 때문에 구현이 단순하고 공정하지만, 헤드 이동 거리가 길어질 수 있다.

SSTF는 현재 헤드 위치에서 가장 가까운 요청을 먼저 처리하므로 총 이동 거리를 줄이는 데 유리하지만, 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다.

Disk Scheduling Simulation(디스크 스케줄링 시뮬레이션)

디스크(Disk)는 같은 요청 집합(Request Set)이 들어오더라도, 어떤 순서로 처리하느냐에 따라 접근 비용(Access Cost)이 달라질 수 있다.

즉, 요청 처리 순서(Request Processing Order)에 따라 디스크 헤드(Disk Head)의 이동 거리와 전체 처리 시간(Total Processing Time)이 달라진다. 따라서 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)은 효율적인 요청 처리 순서를 결정하기 위해 필요하다.

이번 실습에서는 대표적인 디스크 스케줄링 방식인 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First)를 비교하여 성능 차이를 직접 확인한다.

디스크 요청(Disk Request)은 일반적으로 큐(Queue) 형태로 순차적으로 도착한다. 운영체제(Operating System)는 이 요청들을 어떤 순서로 처리할지 결정하며, 이 과정이 디스크 스케줄링(Disk Scheduling)이다.

특히 HDD(Hard Disk Drive)에서는 헤드가 이동한 거리가 길어질수록 탐색 시간(Seek Time)이 증가하고, 전체 접근 시간(Disk Access Time)에도 큰 영향을 준다.

따라서 가능한 한 헤드 이동 거리(Head Movement Distance)를 줄이는 방향으로 요청을 처리하면 전체 디스크 성능(Disk Performance)을 개선할 수 있다.

이번 시뮬레이션에서는 FCFS와 SSTF가 같은 요청 집합을 어떻게 다르게 처리하는지 살펴보고, 그 결과 총 헤드 이동 거리(Total Head Movement)가 어떻게 달라지는지 비교한다.

추가로 알아두면 좋은 점

FCFS는 요청이 도착한 순서대로 처리하기 때문에 구현이 단순하고 공정하지만, 헤드 이동 거리가 길어질 수 있다.

SSTF는 현재 헤드 위치에서 가장 가까운 요청을 먼저 처리하므로 총 이동 거리를 줄이는 데 유리하지만, 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다.

FCFS and SSTF Simulation Code

이 코드는 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First) 스케줄링 방식의 총 헤드 이동 거리(Total Head Movement)를 계산하는 핵심 부분이다.

먼저 FCFS 코드를 살펴보면, 반복문을 통해 요청 배열(Request Array)을 앞에서부터 차례대로 처리한다. 여기서 abs(current - request[i])는 현재 헤드 위치(Current Head Position)에서 다음 요청 위치(Request Position)까지의 이동 거리를 의미한다.

이 값을 total에 계속 누적하고, 이후 current = request[i]를 통해 현재 헤드 위치를 방금 처리한 요청 위치로 변경한다. 즉, FCFS는 요청이 도착한 순서를 그대로 따라가면서 이동 거리를 차례대로 누적 계산하는 방식이다.

반면 SSTF 코드는 아직 처리하지 않은 요청들 가운데 현재 헤드 위치에서 가장 가까운 요청을 찾는 구조이다. 내부 반복문에서 각 요청과 현재 위치 사이의 거리를 계산하고, 그중 가장 작은 거리인 min을 가진 요청의 인덱스(Index)를 idx로 선택한다.

그다음 선택된 요청을 처리 완료 상태로 표시하고, 해당 이동 거리인 min을 total에 더한다. 이후 현재 위치도 선택된 요청 위치로 변경한다.

즉, SSTF는 매 단계마다 가장 가까운 요청을 선택하여 총 헤드 이동 거리를 줄이도록 동작하는 방식이다.

이 두 코드를 실행해서 결과를 비교하면, 같은 요청 집합(Request Set)이라도 처리 순서(Request Processing Order)에 따라 전체 이동 비용(Total Movement Cost)이 어떻게 달라지는지 확인할 수 있다.

추가로 알아두면 좋은 점

또한 SSTF는 총 이동 거리를 줄이는 데 효과적이지만, 가까운 요청만 계속 선택하면 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다.

FCFS and SSTF Simulation Example Code

이 코드는 같은 요청 집합(Request Set)에서 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First) 방식의 총 헤드 이동 거리(Total Head Movement)를 비교하는 예제이다.

먼저 요청 배열(Request Array)에는 다음과 같은 디스크 요청들이 저장되어 있다.

int request[N] = {98, 183, 37, 122, 14, 124, 65, 67};

초기 헤드 위치(Initial Head Position)는 다음과 같이 53으로 설정되어 있다.

int head = 53;

FCFS 부분에서는 요청 배열을 앞에서부터 순서대로 처리한다. 현재 헤드 위치(Current Head Position)와 다음 요청 위치(Request Position)의 차이를 절댓값으로 계산하고, 그 값을 total_fcfs에 누적한다.

즉, FCFS는 요청이 도착한 순서를 그대로 따라가면서 헤드가 얼마나 이동하는지를 계산하는 방식이다.

반면 SSTF 부분에서는 아직 처리되지 않은 요청들 가운데 현재 헤드 위치에서 가장 가까운 요청을 찾는다. 내부 반복문에서 모든 후보 요청과의 거리를 비교하고, 가장 짧은 거리의 요청을 선택한다.

이 과정을 모든 요청이 처리될 때까지 반복하면서 총 이동 거리를 total_sstf에 누적한다. 마지막으로 FCFS와 SSTF의 결과를 출력하여 알고리즘에 따라 이동 비용(Movement Cost)이 어떻게 달라지는지 확인한다.

실행 결과를 보면 FCFS의 총 이동 거리는 640, SSTF의 총 이동 거리는 246으로 나타난다. 즉, SSTF가 FCFS보다 헤드 이동 거리를 크게 줄일 수 있다는 것을 확인할 수 있다.

그 이유는 FCFS는 요청이 도착한 순서를 그대로 처리하지만, SSTF는 현재 위치에서 가장 가까운 요청을 우선 처리하기 때문이다.

따라서 요청 처리 순서(Request Processing Order)는 디스크 성능(Disk Performance)에 직접적인 영향을 준다. 이 실습은 디스크 스케줄링(Disk Scheduling)이 왜 필요한지 확인할 수 있는 예제라고 할 수 있다.

추가로 알아두면 좋은 점

또한 SSTF는 총 헤드 이동 거리를 줄이는 데 효과적이지만, 가까운 요청이 계속 들어오면 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다. 따라서 성능과 공정성(Fairness)을 함께 고려해야 한다.

Buffering Effect Practice(버퍼링 효과 확인)

이번 실습은 버퍼링(Buffering)이 디스크 성능(Disk Performance)에 어떤 영향을 주는지 확인하는 내용이다.

디스크 쓰기 작업(Write Operation)은 프로그램에서 write() 함수를 호출했다고 해서 항상 즉시 디스크(Disk)에 기록되는 것은 아니다. 운영체제(Operating System)는 성능 향상을 위해 데이터를 먼저 메모리 버퍼(Memory Buffer)에 저장한 뒤, 나중에 한꺼번에 디스크에 기록할 수 있다.

즉, 프로그램이 write()를 호출하는 시점과 실제 데이터가 디스크에 기록되는 시점은 서로 다를 수 있다.

이러한 버퍼링 방식은 여러 개의 작은 쓰기 요청(Write Request)을 모아서 처리할 수 있기 때문에 디스크 접근 횟수(Disk Access Count)를 줄이는 데 도움이 된다. 디스크에 매번 접근하지 않고 한 번에 처리하면 전체 입출력 성능(I/O Performance)을 향상시킬 수 있다.

이번 실습에서는 버퍼링이 디스크 접근 횟수와 전체 성능에 어떤 영향을 주는지 확인한다. 이를 통해 운영체제가 왜 데이터를 즉시 디스크에 기록하지 않고, 메모리 버퍼를 활용해 쓰기 작업을 최적화하는지 이해할 수 있다.

추가로 알아두면 좋은 점

버퍼링(Buffering)은 성능 향상에는 도움이 되지만, 데이터가 아직 디스크에 기록되기 전에 시스템 장애(System Failure)나 전원 문제(Power Failure)가 발생하면 데이터 손실 위험이 있을 수 있다.

따라서 운영체제는 필요할 때 플러시(Flush)나 동기화(Synchronization)를 통해 버퍼에 있는 데이터를 실제 디스크에 반영한다.

Buffering Effect Practice(버퍼링 효과 확인)

이번 실습은 버퍼링(Buffering)이 디스크 성능(Disk Performance)에 어떤 영향을 주는지 확인하는 내용이다.

디스크 쓰기 작업(Write Operation)은 프로그램에서 write() 함수를 호출했다고 해서 항상 즉시 디스크(Disk)에 기록되는 것은 아니다. 운영체제(Operating System)는 성능 향상을 위해 데이터를 먼저 메모리 버퍼(Memory Buffer)에 저장한 뒤, 나중에 한꺼번에 디스크에 기록할 수 있다.

즉, 프로그램이 write()를 호출하는 시점과 실제 데이터가 디스크에 기록되는 시점은 서로 다를 수 있다.

이러한 버퍼링 방식은 여러 개의 작은 쓰기 요청(Write Request)을 모아서 처리할 수 있기 때문에 디스크 접근 횟수(Disk Access Count)를 줄이는 데 도움이 된다. 디스크에 매번 접근하지 않고 한 번에 처리하면 전체 입출력 성능(I/O Performance)을 향상시킬 수 있다.

이번 실습에서는 버퍼링이 디스크 접근 횟수와 전체 성능에 어떤 영향을 주는지 확인한다. 이를 통해 운영체제가 왜 데이터를 즉시 디스크에 기록하지 않고, 메모리 버퍼를 활용해 쓰기 작업을 최적화하는지 이해할 수 있다.

추가로 알아두면 좋은 점

버퍼링(Buffering)은 성능 향상에는 도움이 되지만, 데이터가 아직 디스크에 기록되기 전에 시스템 장애(System Failure)나 전원 문제(Power Failure)가 발생하면 데이터 손실 위험이 있을 수 있다.

따라서 운영체제는 필요할 때 플러시(Flush)나 동기화(Synchronization)를 통해 버퍼에 있는 데이터를 실제 디스크에 반영한다.

Buffering and fsync()

버퍼링(Buffering)은 디스크 쓰기 성능(Write Performance)을 높이기 위한 방식이다. write() 함수는 데이터를 즉시 디스크(Disk)에 기록하는 것이 아니라, 우선 커널 버퍼(Kernel Buffer)에 저장한다.

이후 운영체제(Operating System)는 일정 시점에 버퍼에 모인 데이터를 실제 디스크에 반영한다. 이렇게 여러 번의 작은 쓰기 요청(Write Request)을 모아서 처리하면 디스크 접근 횟수(Disk Access Count)를 줄일 수 있고, 전체 입출력 효율(I/O Efficiency)을 높일 수 있다.

반대로 fsync()는 버퍼에 있는 데이터를 즉시 디스크에 강제로 기록하도록 요청하는 함수이다. 즉, write()만 호출한 경우에는 데이터가 커널 버퍼에 머물 수 있지만, fsync()를 호출하면 해당 파일과 관련된 변경 내용을 실제 디스크에 반영하게 된다.

사진에 포함된 핵심 코드는 버퍼링 동작과 fsync()의 차이를 확인하기 위한 부분이다.

write(fd, buf, SIZE);

// 강제 디스크 반영
fsync(fd);

먼저 write(fd, buf, SIZE)는 파일에 데이터를 기록하라는 요청을 운영체제에 전달한다. 이 호출은 비교적 빠르게 종료될 수 있으며, 실제 디스크 기록 작업은 운영체제가 나중에 처리할 수 있다.

그다음 fsync(fd)를 호출하면 해당 파일의 버퍼 내용을 즉시 디스크에 반영하도록 요청한다. 따라서 write()만 사용한 경우와 write() 뒤에 fsync()까지 수행한 경우를 비교하면, 강제로 디스크에 저장하는 과정에서 실행 시간이 어떻게 달라지는지 확인할 수 있다.

정리하면, 버퍼링은 쓰기 요청을 모아 처리하여 성능을 높이는 방식이고, fsync()는 데이터 안정성을 위해 버퍼 내용을 실제 디스크에 강제로 기록하는 방식이다.

추가로 알아두면 좋은 점

write()가 성공했다고 해서 데이터가 반드시 즉시 물리 디스크에 저장되었다는 뜻은 아니다. 운영체제의 버퍼에 기록된 상태일 수 있다.

반면 fsync()는 데이터 손실 위험을 줄이는 데 도움이 되지만, 실제 디스크 기록을 기다려야 하므로 실행 시간이 더 길어질 수 있다. 즉, 버퍼링은 성능을 높이고, fsync()는 안정성을 높이는 방향의 기능이라고 이해하면 좋다.

Buffering Effect Example Code

이 예제는 버퍼링(Buffering)만 사용할 때와 매번 fsync()를 사용할 때의 실행 시간을 비교하는 코드이다.

먼저 버퍼링만 사용하는 경우에는 파일을 연 뒤, 반복문 안에서 write()를 여러 번 수행한다. 이때 각 쓰기 요청(Write Request)은 운영체제(Operating System)의 커널 버퍼(Kernel Buffer)를 통해 처리된다. 따라서 write()를 호출할 때마다 실제 디스크(Disk)에 바로 기록되지 않을 수 있다.

반면 fsync()를 사용하는 경우에는 같은 방식으로 write()를 수행한 뒤, 반복적으로 fsync() 함수를 호출한다. 이는 데이터를 쓸 때마다 버퍼에 있는 내용을 실제 디스크에 강제로 반영하도록 하는 구조이다.

두 경우 모두 clock() 함수를 이용해 전체 수행 시간을 측정하고, 마지막에는 close()를 통해 파일을 닫는다. 이를 통해 버퍼링만 사용할 때와 fsync()를 매번 사용할 때 성능 차이가 어떻게 나타나는지 확인할 수 있다.

실행 결과를 보면 버퍼링만 사용하는 경우는 0.002341초, fsync()를 사용하는 경우는 0.128942초로 측정된다. 즉, fsync()를 매번 호출하면 수행 시간이 크게 증가하는 것을 확인할 수 있다.

그 이유는 버퍼링 방식은 여러 쓰기 요청을 모아서 처리할 수 있지만, fsync()는 매번 실제 디스크 기록이 완료될 때까지 기다려야 하기 때문이다.

따라서 버퍼링은 디스크 접근 횟수(Disk Access Count)를 줄여 성능 향상에 도움이 되지만, 즉시 기록을 보장하려면 그만큼 추가 비용이 발생한다.

즉, 이 실습은 쓰기 성능(Write Performance)과 데이터 안전성(Data Safety) 사이에 트레이드 오프(Trade-off)가 존재한다는 점을 보여준다.

추가로 알아두면 좋은 점

write()는 데이터를 커널 버퍼에 기록한 뒤 빠르게 반환될 수 있지만, fsync()는 버퍼 내용을 실제 저장장치에 반영하도록 강제한다.

그래서 fsync()는 데이터 손실 위험을 줄이는 데 도움이 되지만, 성능 측면에서는 비용이 크다. 중요한 데이터는 안정성이 필요하므로 fsync()가 유용할 수 있고, 일반적인 대량 쓰기에서는 버퍼링을 활용하는 것이 더 효율적일 수 있다.

Cache Effect Practice(캐시 효과 확인)

이번 실습은 캐시(Cache)가 디스크 접근 성능(Disk Access Performance)에 어떤 영향을 주는지 확인하는 내용이다.

같은 파일(File)을 반복해서 읽을 때, 매번 수행 시간이 동일하지 않을 수 있다. 그 이유는 운영체제(Operating System)가 디스크(Disk)에서 읽은 데이터를 메모리(Memory)에 캐시 형태로 저장해둘 수 있기 때문이다.

첫 번째 접근에서는 실제 디스크에서 데이터를 읽어야 하므로 시간이 더 걸릴 수 있다. 하지만 이후 같은 데이터를 다시 요청하면, 운영체제가 디스크에 다시 접근하지 않고 메모리에 저장된 캐시 데이터를 사용할 수 있다.

이렇게 캐시에서 데이터를 제공하면 디스크 접근 횟수(Disk Access Count)가 줄어들고, 전체 읽기 성능(Read Performance)이 향상될 수 있다.

따라서 이번 실습은 같은 파일을 반복해서 읽을 때 캐시가 성능에 어떤 영향을 주는지 확인하는 예제이다. 이를 통해 디스크 접근은 항상 실제 디스크에서만 이루어지는 것이 아니라, 운영체제의 캐시 구조를 통해 더 빠르게 처리될 수 있다는 점을 이해할 수 있다.

추가로 알아두면 좋은 점

운영체제 캐시(OS Cache)는 한 번 읽은 데이터를 메모리에 보관해두었다가 같은 데이터가 다시 요청될 때 빠르게 제공한다.

다만 실습 결과는 실행 환경에 따라 달라질 수 있다. 이미 파일이 캐시에 올라와 있다면 첫 번째 실행부터 빠르게 측정될 수 있고, 시스템의 메모리 상태나 다른 작업에 따라 결과가 달라질 수 있다.

Cache Effect Practice(캐시 효과 확인)

이번 실습은 캐시(Cache)가 디스크 접근 성능(Disk Access Performance)에 어떤 영향을 주는지 확인하는 내용이다.

같은 파일(File)을 반복해서 읽을 때, 매번 수행 시간이 동일하지 않을 수 있다. 그 이유는 운영체제(Operating System)가 디스크(Disk)에서 읽은 데이터를 메모리(Memory)에 캐시 형태로 저장해둘 수 있기 때문이다.

첫 번째 접근에서는 실제 디스크에서 데이터를 읽어야 하므로 시간이 더 걸릴 수 있다. 하지만 이후 같은 데이터를 다시 요청하면, 운영체제가 디스크에 다시 접근하지 않고 메모리에 저장된 캐시 데이터를 사용할 수 있다.

이렇게 캐시에서 데이터를 제공하면 디스크 접근 횟수(Disk Access Count)가 줄어들고, 전체 읽기 성능(Read Performance)이 향상될 수 있다.

따라서 이번 실습은 같은 파일을 반복해서 읽을 때 캐시가 성능에 어떤 영향을 주는지 확인하는 예제이다. 이를 통해 디스크 접근은 항상 실제 디스크에서만 이루어지는 것이 아니라, 운영체제의 캐시 구조를 통해 더 빠르게 처리될 수 있다는 점을 이해할 수 있다.

추가로 알아두면 좋은 점

운영체제 캐시(OS Cache)는 한 번 읽은 데이터를 메모리에 보관해두었다가 같은 데이터가 다시 요청될 때 빠르게 제공한다.

다만 실습 결과는 실행 환경에 따라 달라질 수 있다. 이미 파일이 캐시에 올라와 있다면 첫 번째 실행부터 빠르게 측정될 수 있고, 시스템의 메모리 상태나 다른 작업에 따라 결과가 달라질 수 있다.

Cache Effect Code(캐시 효과 확인 코드)

캐시(Cache)는 디스크에서 읽은 데이터를 운영체제(Operating System)가 메모리(Memory)에 임시로 저장해두는 방식이다. 이후 동일한 데이터를 다시 읽으면 디스크(Disk)에 다시 접근하지 않고, 메모리 캐시에서 바로 가져올 수 있다.

즉, 느린 저장장치(Storage Device) 대신 빠른 메모리를 활용하여 처리 시간을 줄이는 방식이다. 같은 데이터에 대한 반복 접근이 많을수록 캐시 사용 여부에 따라 성능 차이가 크게 나타날 수 있다.

사진에 포함된 코드는 동일한 파일(File)을 두 번 읽으면서 캐시 효과를 확인하기 위한 핵심 코드이다.

먼저 make_test_file(filename)을 통해 실험에 사용할 테스트 파일(Test File)을 생성한다. 충분한 크기의 파일을 만들어 실제 읽기 동작을 측정할 수 있도록 준비하는 과정이다.

그다음 첫 번째 read(fd, buf, SIZE)를 수행하면 파일의 데이터를 읽는다. 이때 데이터는 실제 디스크에서 읽혀올 수 있으며, 운영체제는 읽은 데이터를 메모리 캐시에 함께 저장할 수 있다.

이후 lseek(fd, 0, SEEK_SET)을 실행하면 파일 오프셋(Offset)을 다시 처음 위치로 이동시킨다. 즉, 같은 데이터를 다시 읽기 위해 시작 위치를 재설정하는 과정이다.

마지막으로 두 번째 read(fd, buf, SIZE)를 수행하면 동일한 데이터를 다시 읽는다. 이때 이미 데이터가 메모리 캐시에 존재한다면, 디스크에 다시 접근하지 않고 더 빠르게 처리될 수 있다.

따라서 첫 번째 읽기 시간과 두 번째 읽기 시간을 비교하면, 캐시가 디스크 접근 성능(Disk Access Performance)에 어떤 영향을 주는지 확인할 수 있다.

추가로 알아두면 좋은 점

캐시 효과는 실행 환경에 따라 다르게 나타날 수 있다. 이미 파일이 캐시에 올라와 있으면 첫 번째 읽기부터 빠르게 측정될 수 있고, 시스템 메모리 상태에 따라 결과가 달라질 수 있다.

Cache Effect Example Code(캐시 효과 확인 예제 코드)

위 코드는 동일한 파일(File)을 두 번 읽어서 첫 번째 읽기 시간과 두 번째 읽기 시간을 비교하는 예제이다. 이를 통해 운영체제 캐시(OS Cache)가 파일 읽기 성능에 어떤 영향을 주는지 확인할 수 있다.

먼저 상수 정의 부분에서는 읽기 크기(Size), 반복 횟수(Repeat Count), 파일 크기(File Size)가 설정된다. 이후 make_test_file() 함수를 이용해 실험에 사용할 테스트 파일(Test File)을 생성한다.

make_test_file()에서는 open()으로 파일을 열고, write()를 이용해 약 2MB 크기의 데이터를 파일에 기록한다. 즉, 캐시 효과(Cache Effect)를 측정할 수 있도록 실험용 데이터를 미리 준비하는 과정이다.

그다음 main() 함수에서는 생성된 파일을 읽기 전용(Read Only)으로 연다. 이후 첫 번째 읽기 시간을 측정한다. 반복문 안에서 read()를 여러 번 수행하면서 파일 내용을 순차적으로 읽어오는데, 이 첫 번째 읽기에는 실제 디스크 접근(Disk Access)이 포함될 수 있기 때문에 상대적으로 시간이 더 걸릴 수 있다.

첫 번째 읽기가 끝난 뒤에는 lseek(fd, 0, SEEK_SET)을 사용해 파일 위치를 다시 처음으로 이동한다. 이는 동일한 파일을 처음부터 다시 읽을 수 있도록 오프셋(Offset)을 재설정하는 과정이다.

그다음 두 번째 읽기에서도 같은 방식으로 read()를 반복 수행하고 시간을 다시 측정한다. 이때 첫 번째 읽기에서 사용된 데이터가 운영체제의 메모리 캐시(Memory Cache)에 남아 있다면, 두 번째 읽기는 디스크에 다시 접근하지 않고 더 빠르게 처리될 수 있다.

마지막으로 첫 번째 읽기 시간(First Read Time)과 두 번째 읽기 시간(Second Read Time)을 출력하여 캐시 효과를 비교한다.

정리하면, 이 코드는 같은 파일을 반복해서 읽을 때 첫 번째 읽기보다 두 번째 읽기가 더 빨라질 수 있음을 확인하는 예제이다. 이는 운영체제가 한 번 읽은 데이터를 메모리에 캐시해두고, 이후 같은 데이터 요청이 들어오면 디스크 대신 캐시에서 빠르게 제공할 수 있기 때문이다.

추가로 알아두면 좋은 점

이 실습 결과는 실행 환경에 따라 달라질 수 있다. 파일이 이미 운영체제 캐시에 올라와 있다면 첫 번째 읽기도 빠르게 측정될 수 있고, 메모리 상태나 백그라운드 작업에 따라 시간 차이가 작게 나타날 수도 있다.

또한 clock()은 프로그램이 사용한 CPU 시간(CPU Time)을 측정하는 함수이기 때문에, 실제 디스크 입출력 시간(Wall-Clock Time)을 정확히 비교하려면 환경에 따라 clock_gettime() 같은 함수를 사용하는 것이 더 적절할 수 있다.

Cache Effect Execution Result(캐시 효과 실행 결과)

실행 결과를 보면 첫 번째 읽기(First Read)는 0.004821초, 두 번째 읽기(Second Read)는 0.001237초로 측정되었다. 즉, 두 번째 읽기가 첫 번째 읽기보다 더 빠르게 수행된 것을 확인할 수 있다.

그 이유는 첫 번째 읽기 과정에서 사용된 데이터가 운영체제(Operating System)의 메모리 캐시(Memory Cache)에 저장되었기 때문이다. 이후 같은 데이터를 다시 읽을 때는 디스크(Disk)에 직접 접근하지 않고, 메모리에 저장된 캐시(Cache)를 통해 더 빠르게 데이터를 가져올 수 있다.

따라서 운영체제는 반복적으로 사용되는 데이터에 대해 디스크 접근 횟수(Disk Access Count)를 줄이고, 전체 입출력 성능(I/O Performance)을 개선할 수 있다.

다만 캐시 상태(Cache State), 시스템 상황(System Condition), 백그라운드 작업(Background Process)에 따라 실행 시간은 달라질 수 있다. 따라서 중요한 것은 정확한 시간 값 자체보다, 첫 번째 읽기와 두 번째 읽기 사이에서 캐시 효과가 나타날 수 있다는 점을 이해하는 것이다.

이번 실습에서는 순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 차이, 디스크 스케줄링(Disk Scheduling), 버퍼링(Buffering), 캐시(Cache)의 효과가 실제 시스템에서 어떻게 나타나는지 확인하는 것이 핵심이다.

추가로 알아두면 좋은 점

캐시 효과는 항상 같은 크기로 나타나는 것은 아니다. 이미 파일이 캐시에 올라와 있거나, 시스템 메모리 상태가 달라지면 첫 번째 읽기와 두 번째 읽기의 시간 차이가 작게 나타날 수도 있다.

실습결과

이 실습을 통해 순차 접근 시간이 랜덤 접근 시간보다 더 빠르게 측정되는 것을 확인하였다. 이는 순차 접근이 연속된 데이터를 차례대로 읽는 방식이기 때문에, 랜덤 접근보다 디스크 접근 비용이 상대적으로 적기 때문이다.

디스크 스케줄링 시뮬레이션(Disk Scheduling Simulation)은 같은 디스크 요청 목록(Request Queue)을 FCFS, SSTF 같은 알고리즘으로 처리했을 때 총 헤드 이동 거리(Total Head Movement)가 얼마나 달라지는지 확인하기 위한 코드였다.

실습을 통해 순서대로 처리하는 FCFS 보다는 가까운 작업을 먼저 처리하는 SSTF의 이동거리가 더 짧았다. 이로 인해 디스크 스케줄링이 탐색 시간(Seek Time)을 줄이는 데 어떤 영향을 주는지 볼 수 있었다.

버퍼링 코드(Buffering Code)는 write()만 사용할 때와 매번 fsync()를 사용할 때의 시간을 비교해서, 버퍼링(Buffering)이 쓰기 성능(Write Performance)에 어떤 영향을 주는지 확인하는 코드였다. 즉, 디스크 성능 전체라기보다는 디스크 쓰기 성능과 안정성 사이의 트레이드오프(Trade-off)를 확인하는 실습이었다.

여러 쓰기 요청을 메모리에 모아두었다가 나중에 처리할 수 있기 때문에 버퍼링을 사용한 코드가 더 빨랐다. fsync 사용이 더 느린이유는 매번 실제 디스크 기록을 강제하기 때문에 대기 시간이 증가하기 때문이다.

캐시 코드(Cache Code)는 같은 파일을 두 번 읽었을 때 첫 번째 읽기와 두 번째 읽기 시간이 어떻게 달라지는지 비교해서, 운영체제 캐시(OS Cache)가 읽기 성능(Read Performance)에 어떤 영향을 주는지 확인하는 코드였다. 즉, 반복 읽기에서 디스크 접근 횟수(Disk Access Count)를 줄여 성능이 좋아질 수 있음을 확인하는 실습이다.

이 실습을 통해 동일한 파일을 반복해서 읽을 경우, 두 번째 읽기가 더 빠르게 수행될 수 있음을 확인하였다. 이는 운영체제가 첫 번째 읽기 데이터를 메모리 캐시에 저장해두고, 이후 같은 데이터를 다시 요청할 때 디스크 접근을 줄일 수 있기 때문이다.

이번 강의는 새로운 소프트웨어 테스트(Software Testing) 내용을 배우는 시간이 아니라, 한 학기 동안 학습한 핵심 내용을 키워드 중심으로 정리하고 점검하는 시간이다. 지난 시간에는 AI 소프트웨어 테스트(AI Software Testing)의 정의와 필요성을 살펴보았다. 특히 일반 소프트웨어와 달리 AI 소프트웨어(AI Software)는 데이터(Data)와 모델(Model)에 크게 의존하기 때문에, AI 소프트웨어의 특성을 반영한 별도의 테스트 기법(Test Techniques)이 필요하다는 점을 학습했다.

AI 소프트웨어 테스트에서는 기존 소프트웨어 테스트와 마찬가지로 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)의 개념이 적용된다. 블랙박스 테스트는 AI 모델 내부 구조를 직접 보지 않고 입력값(Input)과 출력값(Output)의 관계를 중심으로 검증하는 방식이다. 반면 화이트박스 테스트는 AI 모델의 내부 구조, 특히 신경망(Neural Network)이나 뉴런 커버리지(Neuron Coverage)와 같은 요소를 고려하여 테스트하는 방식이다.

또한 AI 소프트웨어를 안전하게 테스트하기 위해 가상 기반 테스트 환경(Virtual-based Testing Environment)과 디지털 트윈(Digital Twin)을 활용하는 방법도 학습했다. 현실 환경에서는 위험한 상황이나 예외적인 상황을 직접 재현하기 어렵기 때문에, 시뮬레이션 환경(Simulation Environment)을 통해 다양한 시나리오(Scenario)를 안전하게 반복 테스트할 수 있다. 특히 자율주행(Autonomous Driving), 드론(Drone), 물류 시스템(Logistics System)처럼 실제 테스트 비용과 위험이 큰 분야에서 이러한 방식이 중요하게 사용된다.

이번 정리 강의의 목표는 전체 수업의 목표와도 연결된다.

첫 번째 목표는 소프트웨어 품질 확보(Software Quality Assurance)의 중요성을 인식하는 것이다. 소프트웨어 테스트는 단순히 오류를 찾는 활동이 아니라, 소프트웨어가 요구사항(Requirements)을 충족하고 안정적으로 동작하는지 확인함으로써 품질을 확보하는 중요한 활동이다. 따라서 테스트는 개발의 마지막 단계에서만 수행되는 부가적인 작업이 아니라, 소프트웨어 품질을 보장하기 위한 핵심 프로세스라고 볼 수 있다.

두 번째 목표는 소프트웨어 테스트 프로세스(Software Testing Process)를 설명할 수 있는 것이다. 소프트웨어 테스트는 단순히 테스트를 실행하는 것만을 의미하지 않는다. 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가(Test Evaluation), 테스트 개선(Test Improvement)과 같은 단계가 포함된다. 이러한 과정은 PDCA(Plan-Do-Check-Act) 관점에서도 이해할 수 있다. 즉, 테스트를 계획하고 실행한 뒤 결과를 확인하고, 문제점을 개선하는 반복적인 품질 관리 활동이다.

세 번째 목표는 다양한 소프트웨어 테스트 기법(Software Test Techniques)을 설명할 수 있는 것이다. 수업에서는 블랙박스 테스트와 화이트박스 테스트를 중심으로 여러 테스트 방법을 학습했다. 블랙박스 테스트에는 동등 분할 테스트(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 조합 테스트(Combinatorial Testing), 변성 테스트(Metamorphic Testing), 탐색적 테스트(Exploratory Testing) 등이 포함될 수 있다. 화이트박스 테스트에서는 코드 구조나 내부 로직을 기반으로 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage), 그리고 AI 모델의 경우 뉴런 커버리지(Neuron Coverage)와 같은 개념을 활용할 수 있다.

정리하면, 이번 강의는 한 학기 동안 배운 소프트웨어 품질(Software Quality), V-모델(V-Model), 테스트 프로세스(Test Process), 테스트 기법(Test Techniques), AI 소프트웨어 테스트(AI Software Testing)를 전체적으로 복습하는 시간이다. 이 내용을 통해 소프트웨어 테스트가 품질 확보를 위한 핵심 활동이며, 테스트는 계획부터 설계, 수행, 평가, 개선까지 이어지는 체계적인 프로세스라는 점을 다시 확인할 수 있게 될 것이다.

Software Quality and V-Model

소프트웨어 품질(Software Quality)과 V-모델(V-Model)에서 가장 중요한 출발점은 소프트웨어(Software)의 정의를 이해하는 것이다. 소프트웨어는 단순히 프로그램 코드만을 의미하는 것이 아니라, 사용자의 요구사항(Requirements)을 만족시키기 위해 만들어진 프로그램, 데이터, 문서, 절차 등을 포함하는 개념이다. 이러한 소프트웨어는 하드웨어처럼 눈에 보이는 물리적 제품은 아니지만, 자동차, 항공기, 의료기기, 금융 시스템 등 다양한 실제 제품과 서비스의 동작에 큰 영향을 준다.

소프트웨어는 변경이 쉽고 복잡도가 높으며, 개발 과정에서 사람이 직접 논리와 구조를 설계한다는 특징을 가진다. 이러한 특징 때문에 요구사항이 잘못 정의되거나, 설계가 부정확하거나, 구현 과정에서 실수가 발생하면 소프트웨어 결함(Software Defect)이 생길 수 있다. 결함은 단순한 프로그램 오류로 끝나는 것이 아니라, 실제 제품의 오작동이나 서비스 장애로 이어질 수 있다. 특히 자동차나 항공기처럼 안전이 중요한 분야에서는 소프트웨어 결함이 큰 사고로 연결될 수 있기 때문에 품질 확보가 매우 중요하다.

이러한 문제를 줄이기 위해 수업에서는 제품 품질(Product Quality)뿐만 아니라 프로세스 품질(Process Quality)의 중요성을 강조했다. 제품 품질은 최종적으로 만들어진 소프트웨어가 요구사항을 만족하고 안정적으로 동작하는지를 의미한다. 반면 프로세스 품질은 소프트웨어를 개발하고 유지보수하는 과정이 체계적이고 적절하게 수행되었는지를 의미한다. 좋은 개발 프로세스를 갖추면 결함을 줄이고, 결과적으로 더 나은 제품 품질을 확보할 수 있다.

이때 중요한 개발 및 테스트 관점으로 V-모델(V-Model)이 등장한다. V-모델은 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Test)의 관계를 체계적으로 보여주는 모델이다. 개발 단계에서 정의한 요구사항과 설계 내용은 이후 테스트 단계에서 검증되어야 한다. 즉, 요구사항을 기준으로 인수 테스트(Acceptance Testing)를 수행하고, 설계를 기준으로 시스템 테스트(System Testing), 통합 테스트(Integration Testing), 단위 테스트(Unit Testing)를 수행하는 방식으로 연결된다.

정리하면, 소프트웨어 품질과 V-모델의 핵심 흐름은 하나의 시나리오로 이해할 수 있다. 먼저 소프트웨어의 정의와 특징을 이해하고, 이러한 특징 때문에 품질 문제가 발생할 수 있음을 파악한다. 품질 문제는 소프트웨어 결함으로 이어지고, 결함은 실제 제품이나 서비스에 영향을 줄 수 있다. 따라서 소프트웨어 품질을 확보하기 위해 제품 품질과 프로세스 품질을 함께 관리해야 하며, 이를 체계적으로 수행하기 위한 방법으로 V-모델을 적용할 수 있다.

Software의 정의

소프트웨어(Software)는 단순히 하드웨어(Hardware)를 제어하는 프로그래밍 명령어(Programming Instructions)나 소스 코드(Source Code)의 집합만을 의미하지 않는다. 물론 소스 프로그램(Source Program)이나 실행 가능한 프로그램(Executable Program)은 소프트웨어의 중요한 구성 요소이다. 하지만 소프트웨어를 더 넓게 보면, 개발 과정에서 만들어지는 다양한 산출물(Artifacts)까지 포함하는 개념이다.

소프트웨어는 고객 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing), 배포(Deployment)와 같은 일련의 소프트웨어 개발 프로세스(Software Development Process)를 통해 만들어진다. 이 과정에서 단순히 코드만 생성되는 것이 아니라, 요구사항 명세서(Requirements Specification), 아키텍처 설계서(Architecture Design Document), 상세 설계서(Detailed Design Document), 테스트 결과서(Test Result Report), 배포 문서(Deployment Document), 데이터(Data) 등 다양한 결과물이 함께 만들어진다.

따라서 소프트웨어는 프로그램 코드만을 가리키는 좁은 개념이 아니라, 프로그램을 포함하여 소프트웨어 개발과 유지보수 과정에서 생성되는 모든 관련 산출물의 집합이라고 이해할 수 있다. 즉, 소프트웨어는 소스 코드(Source Code), 문서(Document), 데이터(Data), 테스트 결과(Test Results), 프로세스(Process)와 같은 요소들을 포함하는 종합적인 개념이다.

이러한 정의가 중요한 이유는 소프트웨어 품질(Software Quality)을 평가할 때 코드만 보면 충분하지 않기 때문이다. 요구사항이 잘못 작성되었거나, 설계 문서가 부정확하거나, 테스트 결과가 제대로 관리되지 않으면 최종 프로그램이 정상적으로 동작하더라도 품질 문제가 발생할 수 있다. 따라서 소프트웨어를 이해할 때는 구현 단계에서 나온 코드뿐만 아니라, 개발 전 과정에서 만들어지는 산출물까지 함께 고려해야 한다.

정리하면, 소프트웨어는 하드웨어를 제어하는 명령어 집합만이 아니라, 소스 프로그램을 포함하여 요구사항 분석, 설계, 구현, 테스트, 배포 과정에서 생성되는 문서와 데이터, 테스트 결과 등 모든 산출물을 포함하는 개념이 된다.

Software의 특징

소프트웨어(Software)는 대표적으로 네 가지 특징을 가진다. 이러한 특징들은 소프트웨어 품질 문제(Software Quality Issue)와 결함(Defect)이 발생하는 원인이 될 수 있으며, 최종적으로는 소프트웨어가 탑재된 자동차, 항공기, 의료기기와 같은 실제 제품에도 영향을 줄 수 있다.

첫 번째 특징은 비가시성(Invisibility)이다. 소프트웨어는 하드웨어처럼 눈으로 구조를 직접 확인하기 어렵다. 작은 프로그램은 코드의 흐름을 비교적 쉽게 파악할 수 있지만, 수천 줄, 수만 줄, 수십만 줄 이상의 대형 소프트웨어가 되면 내부 구성 요소와 전체 구조를 한눈에 이해하기 어렵다. 이 때문에 소프트웨어의 구조적 문제나 결함을 발견하기가 쉽지 않다.

두 번째 특징은 비선형적이고 복잡한 구조(Nonlinear and Complex Structure)이다. 소프트웨어는 여러 모듈(Module)로 구성되며, 각 모듈은 독립적으로 존재하면서도 서로 데이터를 주고받고 기능적으로 연결된다. 이러한 관계가 많아질수록 소프트웨어는 단순한 선형 구조로 이해하기 어려워지고, 하나의 변경이 다른 부분에 예상하지 못한 영향을 줄 수 있다.

세 번째 특징은 닳아 없어지지 않지만 계속 변경된다는 점(Does Not Wear Out but Changes)이다. 하드웨어(Hardware)는 시간이 지나면 물리적으로 마모되거나 고장날 수 있지만, 소프트웨어 자체는 물리적으로 닳지 않는다. 대신 사용자의 요구 변화, 운영 환경 변화, 기능 추가, 결함 수정 등에 따라 계속 변경된다. 이러한 변경은 소프트웨어가 탑재된 제품이나 서비스가 사용되는 동안 지속될 수 있으며, 변경 과정에서 새로운 결함이 발생할 가능성도 있다.

네 번째 특징은 사람 중심의 작업(Human-centered Work)이라는 점이다. 소프트웨어 개발은 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing) 등 많은 단계에서 사람의 판단과 작업에 의존한다. 따라서 개발 과정에는 항상 휴먼 에러(Human Error)가 포함될 가능성이 있다. 이러한 오류가 소프트웨어 결함으로 이어지고, 결함이 실제 시스템의 고장(Failure)이나 사고(Accident)로 연결될 수 있다.

결국 소프트웨어의 비가시성, 복잡성, 지속적인 변경, 사람 중심의 개발 과정은 모두 소프트웨어 품질을 저해할 수 있는 요인이 된다. 그래서 소프트웨어 개발이 포함된 IT 프로젝트(IT Project)의 성공률을 높이기 위해서는 단순히 프로그래밍(Programming)만 잘하는 것이 아니라, 요구사항 분석, 설계, 구현, 테스트를 체계적으로 수행하는 프로세스(Process)가 필요하다. 즉, 소프트웨어 품질을 확보하기 위해서는 개발 프로세스를 체계적으로 적용하고, 각 단계에서 품질을 점검하는 노력이 중요하다.

Impact of Software Defects

소프트웨어(Software)는 사람이 직접 분석하고 설계하며 구현하는 결과물이기 때문에, 개발 과정에서 휴먼 에러(Human Error)가 발생할 수 있다. 요구사항을 잘못 이해하거나, 설계 단계에서 논리적 오류가 생기거나, 구현 과정에서 잘못된 코드를 작성하는 것이 모두 휴먼 에러의 예가 될 수 있다.

이러한 휴먼 에러는 단순한 실수로 끝나지 않고, 소프트웨어 내부의 결함(Fault)으로 남을 수 있다. 이후 결함이 실제 실행 과정에서 드러나면 고장(Failure)으로 이어질 수 있다. 즉, 소프트웨어 문제는 error → fault → failure의 흐름으로 전파될 수 있다.

여기서 에러(Error)는 사람이 저지른 실수나 잘못된 판단을 의미하고, 결함(Fault)은 그 실수가 소프트웨어 산출물 안에 남은 상태를 의미한다. 고장(Failure)은 소프트웨어가 실행되었을 때 요구된 기능을 제대로 수행하지 못하는 실제 현상을 의미한다. 작은 실수나 결함이라도 시스템 안에서 전파되면 예상보다 큰 문제로 발전할 수 있다.

특히 소프트웨어가 자동차, 항공기, 의료기기, 금융 시스템, 원자력 시스템과 같은 안전 중요 시스템(Safety-critical System)에 사용될 경우, 결함의 영향은 매우 심각해질 수 있다. 단순한 프로그램 오류가 사람의 생명, 경제적 손실, 환경 피해와 연결될 수 있기 때문이다. 따라서 소프트웨어 결함은 단순히 개발자의 실수나 프로그램 오류로만 볼 것이 아니라, 실제 사회적 피해로 이어질 수 있는 중요한 품질 문제로 이해해야 한다.

결국 소프트웨어 개발에서는 작은 에러와 결함을 가볍게 넘기지 않는 태도가 필요하다. 결함이 상위 단계로 전파되어 큰 사고를 일으키지 않도록, 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing), 유지보수(Maintenance) 전 과정에서 체계적인 프로세스(Process)를 적용해야 한다. 철저한 소프트웨어 개발 프로세스와 테스트 활동은 결함을 조기에 발견하고, 고장과 사고로 이어지는 위험을 줄이기 위한 핵심 방법이라고 할 수 있다.

Process Quality & Product Quality

소프트웨어 품질(Software Quality)은 크게 프로세스 품질(Process Quality)과 제품 품질(Product Quality)로 나누어 볼 수 있다. 최종적으로 우리가 확보하고자 하는 것은 사용자가 실제로 사용하는 소프트웨어 제품(Software Product)이나 시스템(System)의 품질이다. 즉, 제품이 요구사항(Requirements)을 만족하고, 안정적으로 동작하며, 사용 목적에 맞게 기능을 수행해야 한다.

하지만 제품 품질을 높이기 위해서는 단순히 프로그램을 잘 구현하는 것만으로는 부족하다. 좋은 소프트웨어를 만들기 위해서는 소프트웨어를 개발하는 과정, 즉 프로세스(Process)가 체계적으로 관리되어야 한다. 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing), 배포(Deployment), 유지보수(Maintenance) 과정이 명확하게 정의되고, 그 절차에 따라 수행되어야 최종 제품의 품질도 높아질 수 있다.

이때 프로세스 품질은 PDCA Cycle을 기반으로 이해할 수 있다. 먼저 Plan 단계에서는 프로세스의 목표를 달성하기 위한 계획과 절차가 정의되어야 한다. Do 단계에서는 정의된 프로세스에 따라 실제 개발과 테스트 활동을 수행한다. Check 단계에서는 계획대로 잘 진행되고 있는지 확인하고 통제(Control)한다. 마지막으로 Act 단계에서는 문제가 있거나 부족한 부분을 지속적으로 개선(Improvement)한다.

즉, 소프트웨어 품질 확보는 한 번의 테스트 수행으로 끝나는 것이 아니라, 계획하고 수행하고 점검하고 개선하는 반복적인 활동이다. 테스트 활동(Test Activities) 역시 PDCA 관점에서 이루어져야 한다. 테스트를 계획(Test Planning)하고, 테스트 케이스(Test Case)를 설계(Test Design)하고, 테스트를 수행(Test Execution)한 뒤, 결과를 평가(Test Evaluation)하고 개선(Test Improvement)하는 과정이 필요하다.

결국 프로세스 품질과 제품 품질은 서로 연결되어 있다. 체계적인 프로세스가 잘 운영되면 결함(Defect)을 조기에 발견하고 줄일 수 있으며, 이는 최종 제품의 품질 향상으로 이어진다. 따라서 소프트웨어 테스트(Software Testing)는 단순히 오류를 찾는 활동이 아니라, PDCA 기반의 품질 관리 활동(Quality Management Activity)으로 이해해야 한다.

V-Model 생명주기 프로세스

V-Model은 소프트웨어 개발 활동(Development Activities)과 테스트 활동(Test Activities)을 서로 대응시켜 품질을 확보하는 생명주기 모델(Life Cycle Model)이다. V-Model의 왼쪽은 요구사항 분석(Requirements Analysis), 아키텍처 설계(Architecture Design), 상세 설계(Detailed Design), 구현(Implementation)과 같은 개발 영역으로 구성된다. 오른쪽은 단위 테스트(Unit Testing), 통합 테스트(Integration Testing), 시스템 테스트(System Testing), 인수 테스트(Acceptance Testing)와 같은 테스트 영역으로 구성된다.

V-Model의 핵심은 개발 단계와 테스트 단계가 서로 연결되어 있다는 점이다. 고객 또는 사용자 요구사항(Customer/User Requirements)은 인수 테스트(Acceptance Testing)와 대응된다. 사용자가 요구한 기능과 조건을 최종 시스템이 만족하는지 확인하는 단계이기 때문이다. 요구사항 분석(Requirements Analysis)은 시스템 테스트(System Testing)와 대응된다. 시스템 전체가 분석된 요구사항을 충족하는지 검증하는 단계이다.

아키텍처 설계(Architecture Design)는 통합 테스트(Integration Testing)와 대응된다. 아키텍처 설계에서는 시스템을 구성하는 주요 컴포넌트(Component)와 모듈(Module) 간의 관계를 정의하므로, 통합 테스트에서는 이 구성요소들이 서로 올바르게 연동되는지 확인한다. 상세 설계(Detailed Design)는 단위 테스트(Unit Testing)와 대응된다. 상세 설계에서 정의한 개별 모듈이나 함수가 구현 후 올바르게 동작하는지 확인하는 단계가 단위 테스트이다.

V-Model에서 중요한 것은 단순히 개발이 끝난 뒤 테스트를 수행한다는 의미가 아니다. 왼쪽 개발 단계에서 만들어지는 산출물(Artifact)의 품질이 오른쪽 테스트 단계의 품질에 직접적인 영향을 준다는 점이다. 예를 들어 요구사항 분석서(Requirements Specification)의 품질이 낮거나 모호하면, 이를 기반으로 작성되는 시스템 테스트 케이스(System Test Case)의 품질도 낮아질 수밖에 없다. 따라서 테스트 품질을 높이기 위해서는 개발 산출물의 품질도 함께 높여야 한다.

이를 위해 V-Model에서는 검증(Verification)과 확인(Validation)을 강조한다. 검증은 개발 산출물이 정해진 기준과 명세에 맞게 만들어졌는지 확인하는 활동이고, 확인은 최종 제품이 사용자 요구와 실제 사용 목적을 만족하는지 확인하는 활동이다. 즉, V-Model은 개발 과정에서 만들어진 산출물을 계속 점검하고, 최종적으로 소프트웨어가 올바르게 만들어졌는지 확인하는 구조를 가진다.

또한 품질 확보를 위해서는 개발자가 자신의 산출물만 스스로 확인하는 것보다, 제3자의 관점에서 리뷰(Review)하고 점검하는 것이 중요하다. 예를 들어 요구사항 분석 단계에서 나온 분석서는 시스템 테스트 담당자나 품질 담당자가 함께 검토할 수 있다. 이렇게 테스트 담당자가 개발 초기 단계부터 참여하면, 요구사항이 테스트 가능한 형태로 작성되었는지 확인할 수 있고, 이후 테스트 케이스를 더 정확하게 설계할 수 있다.

결국 V-Model은 개발 영역과 테스트 영역을 분리해서 보는 모델이 아니라, 서로 병행하며 품질을 높여가는 모델이다. 왼쪽 개발 산출물의 품질이 좋아야 오른쪽 테스트 산출물의 품질도 좋아지고, 테스트 활동 역시 개발 초기 단계부터 함께 고려되어야 한다. 궁극적으로 V-Model의 목적은 개발과 테스트를 체계적으로 연결하여 소프트웨어 품질(Software Quality)을 확보하는 것이라고 할 수 있다.

Software Testing Process

두 번째 챕터에서는 소프트웨어 테스트 프로세스(Software Testing Process)에 대해 학습한다. 이 챕터의 핵심은 테스트를 단순히 수행하는 활동으로만 보는 것이 아니라, 체계적인 프로세스(Process)로 이해하는 것이다.

먼저 중요한 키워드는 테스트의 정의(Definition of Testing)이다. 테스트는 소프트웨어가 요구사항(Requirements)을 만족하는지 확인하고, 결함(Defect)을 발견하기 위한 활동이다.

테스트를 체계적으로 수행하기 위해 PDCA 관점의 테스트 프로세스(PDCA-based Test Process)를 살펴보았다. 테스트는 계획(Plan), 수행(Do), 확인(Check), 개선(Act)의 흐름에 따라 반복적으로 관리되어야 한다.

또한 ISO/IEC/IEEE 29119의 테스트 프로세스(Test Process)도 중요한 내용으로 등장한다. 이는 소프트웨어 테스트를 체계적으로 수행하기 위한 표준 프로세스이다.

테스트를 제대로 수행하기 위해서는 먼저 테스트 계획(Test Planning)이 필요하다. 테스트 계획을 세울 때는 어떤 부분을 우선적으로 테스트할지 판단해야 하며, 이를 위해 위험 기반 테스트(Risk-based Testing)가 강조된다. 위험이 큰 부분을 먼저 고려하여 테스트 계획을 수립하는 것이 중요하다.

마지막으로 테스트 프로세스의 자동화(Test Process Automation)도 주요 키워드이다. 테스트 자동화는 테스트 활동을 더 효율적으로 수행하기 위한 방법이다.

정리하면, 이 챕터의 주요 키워드는 테스트의 정의(Definition of Testing), PDCA 기반 테스트 프로세스(PDCA-based Test Process), ISO/IEC/IEEE 29119 테스트 프로세스(Test Process), 테스트 계획(Test Planning), 위험 기반 테스트(Risk-based Testing), 테스트 프로세스 자동화(Test Process Automation)이다.

Definition of Testing

테스트(Testing)의 근본적인 목적은 소프트웨어에 결함이 없음을 증명하는 것이 아니라, 소프트웨어 안에 존재하는 결함(Defect)을 발견하는 것이다. 즉, 테스트를 잘 수행했다는 것은 단순히 프로그램이 실행되는 것을 확인했다는 뜻이 아니라, 숨어 있는 결함을 효과적으로 찾아냈다는 의미이다.

소프트웨어는 개발자가 직접 만들기 때문에, 만든 사람이 스스로 테스트할 경우 문제를 놓칠 가능성이 있다. 따라서 품질을 더 객관적으로 확인하기 위해서는 제3자 관점(Third-party Perspective)에서 테스트하는 것이 중요하다. 조직 내부에서도 개발자와는 다른 관점의 테스터(Tester)가 소프트웨어를 평가하면, 사용자가 실제로 겪을 수 있는 문제를 더 잘 발견할 수 있다.

또한 테스터는 소프트웨어를 실제 사용하는 사용자(User)의 관점도 고려해야 한다. 소프트웨어가 개발자의 PC에서는 잘 동작하더라도, 실제 사용자 환경(User Environment)에서도 항상 잘 동작한다고 보장할 수는 없다. 운영체제(Operating System), 하드웨어(Hardware), 네트워크(Network), 사용 방식 등 다양한 환경에 따라 문제가 발생할 수 있기 때문이다.

따라서 테스트는 다양한 사용자 환경을 구성하고, 체계적인 방법으로 수행되어야 한다. 결론적으로 테스트의 핵심 목적은 결함을 발견하는 것이며, 이를 위해 제3자 관점에서 사용자의 실제 환경을 고려하여 소프트웨어를 평가하는 것이 중요하다.

PDCA-based Test Process

PDCA 관점의 테스트 프로세스(PDCA-based Test Process)는 테스트를 단순히 입력값을 넣고, 실행하고, 결과를 확인하는 활동으로만 보지 않는다. 테스트를 제대로 수행하기 위해서는 테스트 수행 이전에 Plan, Do, Check, Act의 과정이 체계적으로 진행되어야 한다.

이 개념은 V-Model과도 연결된다. V-Model의 왼쪽 영역에서 요구사항 분석(Requirements Analysis), 설계(Design)와 같은 개발 활동이 진행될 때, 오른쪽 테스트 활동도 함께 계획되고 설계되어야 한다. 즉, 개발이 모두 끝난 뒤에 테스트를 생각하는 것이 아니라, 개발 초기 단계부터 어떤 테스트를 수행할지 함께 고려해야 한다. 이렇게 개발 담당자와 테스트 담당자가 함께 소통하면 산출물(Artifacts)의 품질도 자연스럽게 높아지게 된다.

테스트 계획 단계(Test Planning)에서는 전체 테스트 계획을 수립한다. 이때 어떤 기능(Feature)을 테스트할지, 테스트 범위는 어디까지인지, 어떤 방식으로 테스트할지 등을 정한다. 테스트 설계 단계(Test Design)에서는 테스트 케이스(Test Case)를 개발하고, 테스트 절차(Test Procedure)를 정의하며, 테스트 환경(Test Environment)을 준비한다. 이러한 활동들은 실제 테스트를 수행하기 전에 먼저 진행되어야 한다.

그 다음 실제 테스트 수행(Test Execution)이 이루어진다. 테스트는 사람이 직접 수행할 수도 있고, 자동화 도구(Test Automation Tool)를 활용하여 수행할 수도 있다. 테스트 수행 후에는 결과를 확인하고 평가해야 한다. 발견된 문제가 실제 결함(Defect)인지, 테스트 프로세스(Process)의 문제인지, 또는 자동화 도구가 잘못 판단한 것인지 분석해야 한다.

이후에는 평가 결과를 바탕으로 개선(Improvement)을 수행한다. 테스트 과정에서 부족했던 부분이나 잘못된 절차가 있다면 수정하고, 더 나은 테스트 프로세스로 개선해 나가야 한다. 즉, 테스트는 한 번 수행하고 끝나는 것이 아니라, Plan, Do, Check, Act의 흐름에 따라 반복적으로 관리되어야 한다.

정리하면, PDCA 기반 테스트 프로세스는 테스트 활동을 체계적으로 계획하고, 수행하고, 평가하고, 개선하는 과정이다. 이를 통해 테스트 프로세스의 품질(Process Quality)을 높일 수 있고, 결과적으로 소프트웨어 제품의 품질(Product Quality)도 향상될 수 있게 된다.

ISO/IEC/IEEE 29119 Test Process

ISO/IEC/IEEE 29119는 소프트웨어 테스트 프로세스(Software Test Process)를 국제 표준으로 정의한 문서이다. 이 표준은 수업에서 여러 번 다루어진 중요한 내용이며, 테스트를 체계적으로 수행하기 위한 기준을 제시한다.

ISO/IEC/IEEE 29119의 테스트 프로세스는 크게 세 가지로 나눌 수 있다. 첫 번째는 조직 차원의 테스트 프로세스(Organizational Test Process), 두 번째는 테스트 관리 프로세스(Test Management Process), 세 번째는 동적 테스트 프로세스(Dynamic Test Process)이다.

조직 차원의 테스트 프로세스는 조직 전체에서 테스트를 어떻게 수행할 것인지에 대한 정책(Test Policy)과 전략(Test Strategy)을 수립하는 단계이다. 테스트가 개인이나 프로젝트마다 제각각 수행되는 것이 아니라, 조직 차원에서 일관된 기준과 방향을 가지고 수행될 수 있도록 기반을 마련하는 역할을 한다.

테스트 관리 프로세스는 실제 테스트가 제대로 수행될 수 있도록 계획하고 관리하는 과정이다. 테스트 계획(Test Planning), 테스트 모니터링(Test Monitoring), 테스트 통제(Test Control), 테스트 완료 활동(Test Completion) 등이 여기에 포함될 수 있다. 즉, 동적 테스트를 수행하기 전에 무엇을 어떻게 테스트할지 관리하는 역할을 한다.

동적 테스트 프로세스는 실제로 소프트웨어를 실행하여 테스트하는 과정이다. 테스트 케이스(Test Case)를 설계하고, 테스트 절차(Test Procedure)를 만들고, 테스트 환경(Test Environment)을 준비한 뒤 실제 테스트를 수행한다. 이후 나온 결과를 확인하고 결함(Defect)을 보고하는 활동도 포함된다.

이 세 가지 프로세스는 서로 분리되어 있는 것이 아니라 연결되어 있다. 조직 차원의 테스트 프로세스에서 수립된 정책과 기준은 테스트 관리 프로세스로 전달되고, 테스트 관리 프로세스는 다시 동적 테스트 프로세스가 제대로 수행될 수 있도록 방향을 제공한다. 반대로 동적 테스트 프로세스에서 나온 결과는 테스트 관리 프로세스로 전달되어 평가되고, 다시 조직 차원의 테스트 프로세스 개선에도 활용된다.

즉, ISO/IEC/IEEE 29119 테스트 프로세스에는 PDCA(Plan-Do-Check-Act)의 개념이 반영되어 있다. 테스트를 계획하고 수행한 뒤, 결과를 평가하고 개선하는 흐름이 조직 차원, 관리 차원, 실제 테스트 수행 차원에서 반복적으로 이루어진다. 이를 통해 테스트 프로세스의 품질을 높이고, 궁극적으로 소프트웨어 제품 품질(Product Quality)을 향상시키는 것이 목적이다.

Flow of ISO/IEC/IEEE 29119 Test Process

ISO/IEC/IEEE 29119 테스트 프로세스(Test Process)는 테스트를 조직 관점, 프로젝트 관점, 실제 수행 관점으로 나누어 체계적으로 관리하는 구조이다. 이 프로세스 안에는 PDCA(Plan-Do-Check-Act)의 흐름이 반영되어 있다.

먼저 조직 차원의 테스트 프로세스(Organizational Test Process)에서는 조직 전체의 테스트 방향을 정한다. 테스트 조직(Test Organization)을 어떻게 구성할 것인지, 테스트 환경(Test Environment)을 어떻게 마련할 것인지, 어떤 기준과 원칙으로 테스트를 수행할 것인지와 같은 테스트 정책(Test Policy)을 수립한다. 이를 바탕으로 조직 차원의 테스트 전략(Test Strategy)이 만들어지고, 이 전략은 프로젝트 차원의 테스트 관리 프로세스(Test Management Process)로 전달된다.

테스트 관리 프로세스에서는 프로젝트 차원에서 테스트 계획(Test Planning)이 시작된다. 이는 PDCA의 Plan에 해당한다. 이 단계에서는 테스트 대상(Test Object), 테스트 목표(Test Objective), 테스트 범위(Test Scope) 등을 정한다. 즉, 무엇을 테스트할 것인지, 어떤 목적을 가지고 테스트할 것인지 계획하는 단계이다.

이후 테스트 계획은 동적 테스트 프로세스(Dynamic Test Process)로 전달된다. 동적 테스트 프로세스에서는 단위 테스트(Unit Testing), 통합 테스트(Integration Testing), 시스템 테스트(System Testing), 인수 테스트(Acceptance Testing) 또는 성능 테스트(Performance Testing), 보안 테스트(Security Testing) 등에 대한 테스트 설계(Test Design)와 구현(Test Implementation)이 이루어진다. 또한 실제 테스트를 수행하기 위한 테스트 환경(Test Environment)도 준비한다. 이 과정 역시 실제 테스트 실행 전에 수행되어야 하는 Plan 단계로 볼 수 있다.

그 다음에는 실제 테스트 수행(Test Execution)이 이루어진다. 테스트 명세(Test Specification)가 준비되고 테스트 환경이 구성된 상태에서, 입력값(Input)을 넣고 출력 결과(Output)가 기대한 대로 나오는지 확인한다. 이 단계는 PDCA의 Do에 해당한다.

테스트 수행 후에는 결과를 확인하고 평가(Test Evaluation)한다. 테스트 결과가 요구사항을 만족하는지, 결함(Defect)이 발견되었는지, 테스트 과정에 문제가 있었는지 확인한다. 이후 테스트 프로세스도 완벽하지 않기 때문에, 더 효율적으로 수행하기 위해 개선(Test Improvement)이 필요하다. 이 과정은 PDCA의 Check와 Act에 해당한다.

정리하면, ISO/IEC/IEEE 29119는 테스트를 조직 차원의 테스트 프로세스, 테스트 관리 프로세스, 동적 테스트 프로세스로 구분한다. 조직 차원의 정책과 전략이 프로젝트 테스트 계획으로 전달되고, 다시 실제 동적 테스트 설계와 수행으로 이어진다. 그리고 테스트 결과는 다시 평가와 개선으로 연결된다. 즉, 테스트 프로세스 전체가 PDCA 사이클을 기반으로 반복적으로 개선되는 구조이다.

Test Planning and Risk-based Test Strategy

테스트 계획(Test Planning)은 테스트 프로세스에서 가장 중요한 부분 중 하나이다. 테스트 계획이란 테스트하고자 하는 대상(Test Object)을 이해하고, 테스트 범위(Test Scope)를 정하며, 어떤 방식으로 테스트할지, 누가 수행할지, 어떤 도구(Test Tool)를 사용할지, 어떤 절차(Test Procedure)를 따를지를 미리 정하는 과정이다.

이때 특히 중요한 것은 위험 기반 테스트 계획(Risk-based Test Planning)을 수립하는 것이다. 위험(Risk)이란 아직 발생하지 않았지만 앞으로 문제가 될 수 있는 잠재적인 요소를 의미한다. 테스트 계획 단계에서는 아직 테스트를 수행하기 전이므로, 테스트 관점에서 어떤 문제가 발생할 수 있는지를 미리 생각해야 한다.

예를 들어 고객이 요구사항(Requirements)을 명확하게 제공하지 않았다면, 이를 기반으로 작성되는 테스트 케이스(Test Case)의 품질도 낮아질 수 있다. 또한 여러 요구사항 중에서 고객(Customer), 사용자(User), 이해관계자(Stakeholder) 입장에서 가장 중요한 요구사항이 무엇인지 파악하는 것도 필요하다. 이러한 과정을 통해 테스트 관점의 위험을 분석할 수 있다.

위험 기반 테스트 전략(Risk-based Test Strategy)이 필요한 이유는 프로젝트의 자원이 항상 제한되어 있기 때문이다. 일정(Schedule), 비용(Cost), 인력, 장소, 도구와 같은 자원은 무한하지 않다. 따라서 모든 요구사항을 동일한 수준으로 동시에 테스트하기는 어렵다. 이때 위험 분석(Risk Analysis)을 통해 중요한 요구사항과 위험도가 높은 부분을 우선적으로 테스트해야 한다.

즉, 위험 기반 테스트 전략은 고객, 사용자, 이해관계자 관점에서 중요한 요구사항을 찾아내고, 그 요구사항에서 발생할 수 있는 위험을 완화(Mitigation)하거나 해결할 수 있는 방법을 테스트 계획에 반영하는 것이다. 테스트 계획 단계에서는 반드시 이러한 위험 기반 관점을 고려해야 하며, 이를 통해 제한된 자원을 효율적으로 사용하고 테스트의 효과를 높일 수 있게된다.

Test Process Automation

테스트 프로세스 자동화(Test Process Automation)는 PDCA(Plan-Do-Check-Act)에 기반한 테스트 프로세스의 전체 또는 일부를 도구(Tool)를 활용해 수행하는 개념이다. 즉, 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 결과 확인과 개선(Test Evaluation and Improvement) 중 필요한 부분을 자동화하여 테스트를 더 효율적으로 수행하려는 것이다.

하지만 테스트 프로세스 전체를 무조건 자동화하는 것이 항상 좋은 것은 아니다. 각 단계에 맞는 도구를 구축하고 운영하기 위해서는 많은 비용(Cost), 시간(Time), 인력(Resource)이 필요하다. 따라서 자동화는 모든 영역에 적용하기보다, 실제로 효과가 크고 반복적으로 수행되는 필요한 부분에 적용하는 것이 중요하다.

수업에서는 대표적으로 테스트 설계 자동화(Test Design Automation)와 테스트 수행 자동화(Test Execution Automation)를 살펴보았다. 테스트 설계 자동화는 테스트 케이스(Test Case)를 만들거나 조합하는 과정을 도구로 지원하는 것이고, 테스트 수행 자동화는 사람이 반복적으로 실행해야 하는 테스트를 도구를 통해 자동으로 수행하는 것이다.

정리하면, 테스트 프로세스 자동화는 테스트 활동을 더 효율적으로 수행하기 위한 방법이다. 다만 자동화에는 비용과 운영 부담이 따르기 때문에, 꼭 필요한 부분을 선택하여 적용해야 한다. 이번 챕터에서는 PDCA 관점의 테스트 프로세스와 ISO/IEC/IEEE 29119 국제표준을 함께 살펴보았으며, 테스트 자동화는 이러한 프로세스를 효율적으로 운영하기 위한 수단으로 이해할 수 있다.

📌Test Design Automation은 “어떤 테스트 케이스를 만들까?”를 도와주는 도구이다.
예: PICT로 입력값 조합을 자동 생성

📌Test Execution Automation은 “그 테스트를 자동으로 실행하자”에 가깝다.
예: Selenium이나 Katalon으로 웹사이트 동작을 자동 테스트

Software Test Techniques and AI Testing

세 번째 챕터에서는 소프트웨어 테스트 기법(Software Test Techniques)과 AI 테스트(AI Testing)에 대해 복습한다. 이 챕터의 핵심은 테스트 설계 기법(Test Design Techniques)을 어떻게 분류하고, 일반 소프트웨어와 AI 소프트웨어에 각각 어떤 방식으로 적용할 수 있는지 이해하는 것이다.

먼저 테스트 설계 기법 분류(Classification of Test Design Techniques)를 살펴본다. 테스트 기법은 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 나눌 수 있다. 블랙박스 테스트는 내부 구조를 보지 않고 요구사항(Requirements)이나 명세(Specification)를 기반으로 입력과 출력의 관계를 확인하는 방식이다. 반면 화이트박스 테스트는 소프트웨어 내부 구조(Internal Structure), 코드 로직(Code Logic), 제어 흐름(Control Flow) 등을 기반으로 테스트하는 방식이다.

이후에는 블랙박스 테스트 설계 기법(Black-box Test Design Techniques)의 종류를 살펴본다. 블랙박스 테스트에서는 동등 분할(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 결정 테이블 테스트(Decision Table Testing), 상태 전이 테스트(State Transition Testing) 등 요구사항과 입력 조건을 기반으로 테스트 케이스(Test Case)를 설계하는 방법들이 포함된다.

다음으로 화이트박스 테스트 설계 기법(White-box Test Design Techniques)의 종류를 살펴본다. 화이트박스 테스트에서는 소스 코드(Source Code)의 구조를 기준으로 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage), 조건 커버리지(Condition Coverage) 등을 확인한다. 즉, 코드 내부가 얼마나 충분히 테스트되었는지를 평가하는 데 초점을 둔다.

또한 일반 소프트웨어 테스트 기법뿐만 아니라 AI 소프트웨어 테스트(AI Software Testing)의 품질 특성과 기법도 함께 복습한다. AI 소프트웨어는 데이터(Data)와 모델(Model)에 의존하며, 정확도(Accuracy), 편향성(Bias), 강건성(Robustness), 데이터 품질(Data Quality)과 같은 요소가 중요하다. 따라서 기존 테스트 기법을 그대로 적용하는 것에는 한계가 있을 수 있고, AI 소프트웨어의 특성을 반영한 테스트 기법이 필요하다.

정리하면, 이번 챕터의 주요 키워드는 테스트 설계 기법 분류(Classification of Test Design Techniques), 블랙박스 테스트(Black-box Testing), 화이트박스 테스트(White-box Testing), 일반 소프트웨어 테스트 기법(General Software Test Techniques), AI 소프트웨어 품질과 테스트(AI Software Quality and Testing)이 된다.

Test Design Techniques Classification

테스트 설계 기법(Test Design Techniques)은 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 분류할 수 있다. 두 기법의 차이는 테스트 대상 소프트웨어(Software)의 내부 로직을 보는지, 보지 않는지에 있다.

블랙박스 테스트(Black-box Testing)는 이름 그대로 소프트웨어 내부를 ‘검은 상자’처럼 보고, 내부 로직(Internal Logic)이나 소스 코드(Source Code)는 고려하지 않는 테스트 방법이다. 테스트하는 사람은 소프트웨어 안에서 어떤 코드가 실행되는지 직접 확인하지 않고, 입력값(Input)을 넣었을 때 출력값(Output)이 요구사항에 맞게 나오는지를 확인한다.

따라서 블랙박스 테스트에서는 테스트 케이스(Test Case)를 만들 때 요구사항 명세서(Requirements Specification), 설계서(Design Document)와 같은 스펙(Specification)을 기반으로 한다. 그래서 블랙박스 테스트는 명세 기반 테스트(Specification-based Testing) 또는 스펙 기반 테스트라고도 부른다.

반면 화이트박스 테스트(White-box Testing)는 소프트웨어 내부의 소스 코드를 직접 들여다보고 테스트하는 방법이다. 즉, 코드의 구조(Code Structure), 로직(Logic), 조건문, 반복문, 실행 경로(Path)를 고려하여 테스트 케이스를 설계한다. 목표는 소스 코드 안의 가능한 독립적인 경로(Independent Path)를 최대한 많이 테스트하는 것이다.

화이트박스 테스트에서는 테스트 케이스를 만들기 위해 소스 코드를 분석해야 한다. 전체 소스 코드의 구성 요소와 구조를 파악한 뒤, 어떤 부분이 실행되었고 어떤 경로가 테스트되었는지를 확인한다. 그래서 화이트박스 테스트는 구조 기반 테스트(Structure-based Testing)라고도 부른다.

정리하면, 블랙박스 테스트는 내부 코드를 보지 않고 요구사항과 출력 결과를 중심으로 테스트하는 방법이고, 화이트박스 테스트는 소스 코드의 내부 구조와 실행 경로를 분석하여 테스트하는 방법이다. 이 차이가 두 테스트 설계 기법을 구분하는 가장 중요한 기준이다.

📌위에서 배운 PICT는 페어와이즈 테스팅또는 조합 테스팅을 위한 도구로 블랙박스 테스트 설계 자동화(Test Design Automation) 도구와 관련이 있다.

예를 들어 로그인 기능을 테스트할 때:

브라우저: Chrome, Edge, Firefox
운영체제: Windows, macOS
계정 상태: 정상, 잠김, 만료

이런 입력 조건들을 조합해서 테스트 케이스를 자동으로 만들어주는 것이 PICT이라고 할 수 있다. 이 과정에서 소스 코드는 보지 않기 때문이다.

📌Selenium은 웹 애플리케이션을 자동으로 실행하고 테스트하는 도구이다. 예를 들어 사용자가 버튼을 클릭하고, 로그인하고, 페이지가 이동하고, 결과 메시지가 나타나는지를 자동으로 확인할 수 있다. 이것도 보통은 소스 코드 내부 구조를 직접 분석하지 않고, 사용자의 관점에서 입력과 출력, 화면 동작을 확인한다. 그래서 Selenium은 주로 블랙박스 테스트 수행 자동화(Test Execution Automation) 도구로 볼 수 있다.

예를 들어:

로그인 페이지에 아이디와 비밀번호 입력
로그인 버튼 클릭
메인 페이지로 이동하는지 확인
오류 메시지가 제대로 나오는지 확인

이런 테스트는 내부 코드가 아니라 사용자 화면과 결과를 기준으로 하므로 블랙박스 테스트에 가깝다.

Black-box Test Design Techniques

블랙박스 테스트(Black-box Testing)는 소프트웨어 내부의 소스 코드(Source Code)나 로직(Logic)을 직접 보지 않고, 요구사항(Requirements)이나 명세(Specification)를 기반으로 테스트 케이스(Test Case)를 설계하는 방법이다. 수업에서는 블랙박스 테스트 설계 기법으로 총 7가지를 학습했다.

첫 번째는 신택스 테스팅(Syntax Testing)이다. 입력값(Input)이 정해진 형식이나 규칙에 맞는지 확인하는 테스트 방식이다. 입력이 올바른 경우와 올바르지 않은 경우를 나누어, 시스템이 각각의 입력을 제대로 처리하는지 확인한다.

두 번째는 동등 분할(Equivalence Partitioning)이다. 입력값이 일정한 범위(Range)를 가질 때, 그 범위를 여러 구간으로 나누고 각 구간의 대표값을 선택하여 테스트하는 방법이다. 예를 들어 성적 관리 시스템에서 점수 구간을 나누고, 각 구간의 대표 점수를 입력하여 결과가 올바르게 나오는지 확인할 수 있다.

세 번째는 경계값 분석(Boundary Value Analysis)이다. 동등 분할에서 나눈 각 구간의 경계 부분을 중심으로 테스트하는 방법이다. 결함은 입력 범위의 중간보다 경계 부분에서 발생할 가능성이 높기 때문에, 구간의 시작값과 끝값 주변을 집중적으로 테스트한다.

네 번째는 결정 테이블 테스팅(Decision Table Testing)이다. 입력 조건(Input Condition)과 출력 결과(Output Result)가 true 또는 false처럼 나누어질 때, 그 조건들의 조합을 표로 정리하여 테스트하는 방법이다. 여러 조건이 함께 작용하여 결과가 달라지는 경우에 유용하다.

다섯 번째는 상태 전이 테스팅(State Transition Testing)이다. 시스템이 여러 상태(State)를 가지고 있고, 이벤트(Event)에 따라 다른 상태로 전이되는 경우에 사용하는 테스트 기법이다. 예를 들어 대기 상태(Waiting State), 실행 상태(Running State), 정지 상태(Stopped State)처럼 시스템의 상태를 정의하고, 이벤트 발생에 따라 상태가 올바르게 변하는지 확인한다. 이때 상태 머신(State Machine)이나 상태 전이 다이어그램(State Transition Diagram)을 활용할 수 있다.

여섯 번째는 시나리오 테스팅(Scenario Testing)이다. 사용자가 실제로 시스템을 사용하는 흐름을 시나리오(Scenario)로 정리하고, 그 흐름에 따라 테스트하는 방법이다. 수업에서는 ATM 현금 인출기(ATM Cash Withdrawal)를 예로 들었다. 정상적으로 현금을 인출하는 시나리오뿐만 아니라, 잘못된 입력, 오류 발생, 다른 기능 사용과 같은 다양한 상황도 함께 테스트할 수 있다.

일곱 번째는 페어와이즈 테스팅(Pairwise Testing)이다. 여러 입력값의 모든 조합을 테스트하기 어려울 때, 두 개의 입력값 쌍(Pair)을 중심으로 조합하여 테스트하는 방법이다. 예를 들어 A, B, C라는 입력 조건이 있을 때 A-B, A-C, B-C처럼 두 조건씩 조합하여 테스트한다. 수업에서는 이 부분을 도구(Tool) PICT를 사용하여 실습하기도 했다.

정리하면, 블랙박스 테스트 설계 기법에는 신택스 테스팅, 동등 분할, 경계값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 시나리오 테스팅, 페어와이즈 테스팅이 있다. 이 기법들의 공통점은 소스 코드 내부를 직접 분석하지 않고, 요구사항 명세서나 설계서와 같은 스펙을 기반으로 테스트 케이스를 만든다는 점이다.

White-box Test Design Techniques

화이트박스 테스트(White-box Testing)는 소스 코드(Source Code)의 내부 구조와 실행 경로를 분석하여 테스트 케이스(Test Case)를 설계하는 방법이다. 블랙박스 테스트가 요구사항이나 명세를 기반으로 테스트한다면, 화이트박스 테스트는 실제 소스 코드의 구조를 직접 확인하면서 테스트한다는 점이 특징이다.

수업에서는 화이트박스 테스트 설계 기법으로 크게 7가지를 살펴보았다. 여기서 가장 중요한 개념은 테스트 커버리지(Test Coverage)이다. 테스트 커버리지는 소스 코드의 전체 구조, 문장, 분기, 조건, 경로 중에서 얼마나 많은 부분이 테스트되었는지를 나타내는 기준이다. 예를 들어 문장 테스팅(Statement Testing)을 수행하면 문장 커버리지(Statement Coverage)를 확인하고, 분기 테스팅(Branch Testing)을 수행하면 분기 커버리지(Branch Coverage)를 확인한다.

첫 번째는 문장 테스팅(Statement Testing)이다. 문장 테스팅은 소스 코드 안의 실행 가능한 문장(Statement)이 얼마나 테스트되었는지를 확인하는 방법이다. 일반적으로 세미콜론(Semicolon)으로 끝나는 명령문 단위가 테스트 대상이 될 수 있으며, 전체 문장 중 몇 개가 실행되었는지를 기준으로 문장 커버리지를 계산한다.

두 번째는 분기 테스팅(Branch Testing)이다. 분기 테스팅은 if문과 같은 분기 구조에서 Yes/No 또는 True/False 경로가 모두 테스트되었는지를 확인하는 방법이다. 즉, 조건식 전체의 결과가 참인 경우와 거짓인 경우를 모두 확인하여 분기 커버리지를 높이는 것이 목적이다.

세 번째는 조건 테스팅(Condition Testing)이다. 조건 테스팅은 하나의 분기문 안에 여러 개의 개별 조건(Condition)이 있을 때, 각 조건이 참과 거짓을 모두 가질 수 있도록 테스트하는 방법이다. 분기 테스팅이 전체 분기 결과를 본다면, 조건 테스팅은 분기 안에 포함된 각각의 조건을 개별적으로 본다는 차이가 있다.

네 번째는 분기/조건 테스팅(Branch/Condition Testing)이다. 이는 분기 테스팅과 조건 테스팅을 함께 고려하는 방법이다. 전체 분기 결과도 확인하고, 동시에 분기 안에 있는 개별 조건들도 테스트한다.

다섯 번째는 변경 조건/결정 테스팅(Modified Condition/Decision Testing, MC/DC)이다. MC/DC는 분기/조건 테스팅을 더 강화한 방식으로, 각 개별 조건이 전체 결정 결과(Decision)에 독립적으로 영향을 주는지를 확인하는 테스트 기법이다. 조건이 여러 개인 복잡한 분기문에서 테스트 적합성을 높이기 위해 사용된다.

여섯 번째는 다중 조건 테스팅(Multiple Condition Testing)이다. 다중 조건 테스팅은 조건들의 모든 조합을 테스트하는 방법이다. 모든 조건 조합을 확인하기 때문에 커버리지는 높아질 수 있지만, 조건이 많아질수록 테스트 케이스 수가 크게 증가할 수 있다.

일곱 번째는 기본 경로 테스팅(Basis Path Testing)이다. 기본 경로 테스팅은 소스 코드의 독립적인 실행 경로(Independent Path)를 찾아 테스트하는 방법이다. 이때 순환 복잡도(Cyclomatic Complexity)를 활용하여 프로그램의 복잡도를 계산하고, 테스트해야 할 독립 경로의 수를 파악한다. 수업에서는 이 순환 복잡도를 구하는 방법도 함께 학습했다.

이러한 기법들은 문장 테스팅, 분기 테스팅, 조건 테스팅처럼 비교적 낮은 커버리지에서 시작하여, 분기/조건 테스팅, MC/DC, 다중 조건 테스팅으로 갈수록 더 높은 커버리지를 목표로 한다. 하지만 실제 프로젝트에서는 비용(Cost), 일정(Schedule), 자원(Resource)이 제한되어 있기 때문에 무조건 가장 높은 커버리지를 목표로 하기보다, 상황에 맞는 적절한 테스트 기법을 선택해야 한다.

정리하면, 화이트박스 테스트 설계 기법의 핵심은 소스 코드를 직접 분석하여 테스트 케이스를 만들고, 테스트 커버리지를 높이는 것이다. 문장, 분기, 조건, 경로가 얼마나 테스트되었는지를 확인하는 커버리지 개념을 잘 이해하는 것이 중요하다.

AI Software Quality Characteristics

AI 소프트웨어(AI Software)는 일반 소프트웨어가 가지는 품질 특성(Quality Characteristics)을 함께 가진다. 예를 들어 기능 적합성(Functional Suitability), 사용성(Usability), 호환성(Compatibility), 성능 효율성(Performance Efficiency)과 같은 특성은 일반 소프트웨어와 AI 소프트웨어 모두에서 중요하다.

하지만 AI 소프트웨어는 일반 소프트웨어와 구분되는 고유한 특성도 가진다. 대표적으로 적응성(Adaptability), 자율성(Autonomy), 진화(Evolution), 유연성(Flexibility), 편향성(Bias), 성능 메트릭(Performance Metrics), 투명성(Transparency), 복잡성(Complexity), 비결정성(Non-determinism) 등이 있다.

이러한 특성은 AI 소프트웨어가 데이터(Data)를 기반으로 동작하기 때문에 나타난다. AI 모델(AI Model)은 훈련 데이터(Training Data)를 학습하고, 그 학습 결과를 바탕으로 새로운 입력에 대한 예측(Prediction)이나 판단(Decision)을 수행한다. 따라서 더 많은 데이터나 새로운 데이터를 학습하면서 성능이 달라지거나, 환경 변화에 적응하는 모습을 보일 수 있다.

또한 AI 소프트웨어는 일정 수준의 자율성(Autonomy)을 가질 수 있다. 사람이 모든 규칙을 직접 코드로 작성하는 것이 아니라, 모델이 데이터에서 패턴(Pattern)을 학습하고 그에 따라 판단하기 때문이다. 이 과정에서 AI 모델은 유연하게 동작할 수 있지만, 동시에 훈련 데이터에 포함된 편향(Bias)을 함께 학습할 위험도 있다.

AI 소프트웨어의 또 다른 특징은 복잡성과 비결정성이다. AI 모델, 특히 신경망(Neural Network) 기반 모델은 내부 구조가 복잡하여 결과가 어떻게 도출되었는지 이해하기 어려울 수 있다. 또한 학습 방식, 실행 환경, 확률적 처리 방식 등에 따라 같은 입력에 대해서도 결과가 달라질 수 있다. 이러한 특성 때문에 AI 소프트웨어는 일반 소프트웨어보다 테스트하기 어려운 부분이 존재한다.

정리하면, AI 소프트웨어는 일반 소프트웨어의 품질 특성을 가지면서도 데이터 기반 동작으로 인해 적응성, 자율성, 진화, 편향성, 투명성, 복잡성, 비결정성과 같은 고유한 품질 특성을 가진다. 이러한 특성 때문에 AI 소프트웨어만을 위한 테스트 기법(AI Software Test Techniques)이 연구되고 적용되고 있다.

AI Software Test Technique Classification

AI 소프트웨어 테스트 기법(AI Software Test Techniques)은 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 나눌 수 있다. 일반 소프트웨어 테스트에서도 블랙박스와 화이트박스로 나누어 테스트 기법을 분류했듯이, AI 소프트웨어에서도 같은 기준을 적용할 수 있다.

블랙박스 테스트(Black-box Testing)는 AI 모델(AI Model)의 내부 구조나 동작 원리를 직접 고려하지 않고, 입력(Input)에 대한 출력(Output)이 적절한지만 확인하는 방법이다. 일반 소프트웨어에서는 내부 소스 코드 로직(Source Code Logic)을 보지 않고 테스트했다면, AI 소프트웨어에서는 AI 모델 내부를 보지 않고 입력 데이터에 대해 올바른 결과가 나오는지를 확인한다. 대표적인 AI 블랙박스 테스트 기법으로는 변성 테스트(Metamorphic Testing), 탐색적 테스트(Exploratory Testing) 등이 있다.

반면 화이트박스 테스트(White-box Testing)는 AI 모델 내부의 신경망 구조(Neural Network Structure)와 동작을 고려하여 테스트하는 방법이다. 즉, AI 모델이 어떤 구조로 구성되어 있고, 입력 데이터가 들어왔을 때 내부 뉴런(Neuron)들이 어떻게 활성화되는지를 확인하면서 테스트 케이스(Test Case)를 설계하고 수행한다. 이 점이 블랙박스 테스트와의 가장 큰 차이이다.

AI 소프트웨어의 화이트박스 테스트에서 중요한 개념은 커버리지(Coverage)이다. 일반 소프트웨어에서 소스 코드가 얼마나 테스트되었는지를 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage) 등으로 확인했던 것처럼, AI 소프트웨어에서는 신경망을 구성하는 뉴런들이 얼마나 많이 테스트되었는지를 확인한다. 수업에서는 이와 관련하여 뉴런 커버리지(Neuron Coverage)를 간단히 살펴보았다.

정리하면, AI 소프트웨어 테스트 기법도 일반 소프트웨어 테스트와 마찬가지로 블랙박스 테스트와 화이트박스 테스트로 나눌 수 있다. 블랙박스 테스트는 AI 모델 내부를 보지 않고 입력과 출력의 관계를 중심으로 테스트하는 방법이고, 화이트박스 테스트는 AI 모델 내부의 신경망 구조와 뉴런 커버리지를 고려하여 테스트하는 방법이다. AI 소프트웨어 테스트는 아직 활발히 연구가 진행 중인 분야이며, AI의 특성을 반영한 다양한 테스트 기법들이 계속 발전하고 있다.

이번 시간에는 운영체제(Operating System) 수업의 실습 준비 과정으로 가상화(Virtualization)의 개념을 간단히 살펴보고, Unix(유닉스)를 설치하는 과정을 다룬다. 앞으로 실습에서는 실제 컴퓨터에 직접 운영체제를 설치하는 것이 아니라, 가상화 환경(Virtualized Environment)을 이용해 별도의 운영체제를 실행하게 된다.

가상화(Virtualization)란 하나의 실제 컴퓨터 안에서 또 다른 컴퓨터 환경을 만들어 사용하는 기술이다. 예를 들어 현재 사용 중인 Windows나 macOS 안에서 가상 머신(Virtual Machine)을 만들고, 그 안에 Unix나 Linux 같은 다른 운영체제를 설치해 실행할 수 있다. 이렇게 하면 실제 컴퓨터의 설정을 크게 변경하지 않고도 다양한 운영체제 환경을 실습할 수 있다는 장점이 있다.

이번 수업의 목표는 가상화(Virtualization)가 무엇인지 이해하고, 이를 이용해 Unix(유닉스)를 설치해 보는 것이다. 수업이 끝난 후에는 가상화가 어떤 개념인지 간단히 설명할 수 있어야 하며, Unix 환경에서 기본적인 명령어(Command)를 실행할 준비가 되어 있어야 한다.

Unix(유닉스)는 Linux(리눅스)와 완전히 같은 운영체제는 아니지만, 역사적 맥락과 사용 방식이 매우 비슷하다. 특히 터미널(Terminal)에서 사용하는 기본 명령어(Command)는 상당 부분 동일하거나 유사하다. 따라서 Unix를 학습하면 Linux를 이해하는 데에도 도움이 되고, 반대로 Linux에서 배운 명령어 지식도 Unix 환경에서 활용할 수 있다.

이번 실습에서는 Unix를 직접 설치하면서 운영체제 실습 환경을 구성하게 된다. 이후 수업에서 파일 시스템(File System), 프로세스(Process), 명령어(Command), 권한(Permission) 등 운영체제의 핵심 개념을 배우기 위해서는 먼저 Unix 또는 Linux와 같은 실습 환경이 필요하다. 따라서 이번 시간은 본격적인 운영체제 실습을 시작하기 위한 기초 준비 단계라고 볼 수 있다.

Additional Notes (추가 설명)

가상 머신(Virtual Machine)은 실제 컴퓨터 안에 만들어진 “가짜 컴퓨터”라고 생각하면 이해하기 쉽다. 이 가상 머신 안에는 별도의 운영체제(Operating System)를 설치할 수 있고, 실제 컴퓨터와는 분리된 환경에서 안전하게 실습할 수 있다.

Unix(유닉스)와 Linux(리눅스)는 같은 것은 아니지만, Linux는 Unix의 철학과 구조를 많이 참고하여 만들어졌다. 그래서 명령어(Command), 파일 구조(File Structure), 터미널 사용 방식(Terminal Usage)이 비슷하다.

운영체제 수업에서 Unix/Linux 환경을 사용하는 이유는 운영체제의 내부 구조를 이해하기 좋기 때문이다. 특히 프로세스(Process), 파일(File), 권한(Permission), 메모리(Memory), 커널(Kernel) 같은 개념을 명령어와 실습을 통해 직접 확인할 수 있다.

Booting, BIOS, and UEFI (부팅, BIOS, UEFI)

Computer Components (컴퓨터 구성 요소)

이번 내용은 가상화(Virtualization)를 이해하기 전에, 컴퓨터가 기본적으로 어떻게 구성되고 어떻게 부팅(Booting)되는지를 살펴보는 부분이다. 컴퓨터를 사용하려면 먼저 하드웨어(Hardware)가 필요하고, 그 하드웨어 위에서 동작하는 소프트웨어(Software)가 필요하다.

하드웨어(Hardware)는 컴퓨터의 물리적인 장치들을 의미한다. 대표적으로 CPU(Central Processing Unit), 메모리(Memory), 스토리지(Storage), 마더보드(Motherboard), 파워서플라이(Power Supply), 그리고 입출력 장치(I/O Device)가 있다. CPU는 명령을 처리하는 핵심 장치이고, 메모리는 실행 중인 프로그램이 임시로 사용하는 공간이다. 스토리지는 운영체제와 파일이 저장되는 장치이며, 마더보드는 여러 부품을 연결하는 중심 역할을 한다.

반면 소프트웨어(Software)는 하드웨어 위에서 실행되는 프로그램을 의미한다. 대표적으로 운영체제(Operating System), 응용 프로그램(Application Program), 컴파일러(Compiler) 등이 있다. 운영체제는 하드웨어와 응용 프로그램 사이에서 중간 역할을 하며, 사용자가 컴퓨터 자원을 편리하게 사용할 수 있도록 관리한다.

Booting as a Connection Between Hardware and Software (하드웨어와 소프트웨어의 결합으로서의 부팅)

부팅(Booting)이란 컴퓨터가 전원이 켜진 뒤 운영체제(Operating System)를 실행할 준비를 하는 과정이다. 다시 말해, 하드웨어(Hardware)와 소프트웨어(Software)가 연결되는 첫 단계라고 볼 수 있다.

컴퓨터는 전원이 켜지자마자 바로 운영체제를 실행할 수 있는 것이 아니다. 먼저 하드웨어가 정상적으로 작동하는지 확인하고, 어느 저장 장치(Storage)에서 운영체제를 불러올지 찾아야 한다. 이 과정을 담당하는 것이 과거에는 BIOS(Basic Input-Output System)였고, 최근 컴퓨터에서는 주로 UEFI(Unified Extensible Firmware Interface)가 사용된다.

리눅스(Linux)의 부팅 과정을 예로 들면, 크게 BIOS를 사용하는 방식과 UEFI를 사용하는 방식으로 나눌 수 있다. 쉽게 말하면 BIOS는 오래된 컴퓨터에서 많이 사용되던 방식이고, UEFI는 최근 컴퓨터에서 사용하는 방식이라고 이해할 수 있다.

BIOS Booting (BIOS 기반 부팅)

BIOS(Basic Input-Output System)는 오래된 방식의 펌웨어(Firmware)이다. 펌웨어(Firmware)는 하드웨어와 운영체제 사이에서 가장 먼저 실행되는 낮은 수준의 소프트웨어라고 볼 수 있다.

BIOS 방식에서는 컴퓨터가 켜지면 먼저 마더보드(Motherboard)와 기본 하드웨어를 확인한다. 그 후 운영체제를 부팅하기 위해 정해진 위치를 찾는다. 이때 중요한 개념이 MBR(Master Boot Record)이다.

MBR(Master Boot Record)은 저장 장치(Storage)의 특정 위치에 존재하는 부팅 정보 영역이다. BIOS는 이 위치를 찾아가고, 그곳에 있는 부트로더(Bootloader)를 실행한다. 부트로더(Bootloader)는 운영체제를 실제로 불러오는 역할을 한다.

예전에는 이 부팅 위치가 손상되면 나머지 데이터가 멀쩡하더라도 컴퓨터가 정상적으로 부팅되지 않는 문제가 있었다. 예를 들어 하드디스크 안의 파일들은 그대로 남아 있어도, 부트 섹터(Boot Sector)가 손상되면 운영체제를 시작할 수 없었다. 그래서 예전 컴퓨터에서는 부팅 관련 영역을 복구하는 작업이 중요한 문제였다.

UEFI Booting (UEFI 기반 부팅)

UEFI(Unified Extensible Firmware Interface)는 BIOS를 대체하기 위해 등장한 새로운 방식의 펌웨어(Firmware)이다. 최근 컴퓨터에서는 대부분 UEFI를 사용한다.

UEFI 방식에서는 GPT(GUID Partition Table)를 사용한다. GPT는 GUID Partition Table의 약자로, 기존의 MBR보다 더 현대적인 파티션 테이블(Partition Table) 방식이다. 여기서 GUID(Globally Unique Identifier)는 전 세계적으로 고유한 식별자를 의미한다.

UEFI에서는 부트로더(Bootloader)가 EFI 부트로더(EFI Bootloader) 형태로 관리된다. 리눅스(Linux) 환경에서는 GRUB(Grand Unified Bootloader)이 자주 사용된다. GRUB은 사용자가 여러 운영체제 중 하나를 선택하거나, 리눅스 커널(Linux Kernel)을 불러오는 역할을 한다.

BIOS가 정해진 부트 섹터(Boot Sector)를 찾아가는 방식에 가깝다면, UEFI는 더 구조화된 방식으로 부팅 정보를 관리한다. 그래서 큰 용량의 저장 장치(Storage)를 다루거나, 다양한 운영체제 환경을 관리하는 데 더 적합하다.

Why UEFI Replaced BIOS (UEFI가 BIOS를 대체하게 된 이유)

BIOS는 초기 개인용 컴퓨터 시대에 만들어진 방식이다. 당시에는 저장 장치(Storage)의 용량이 지금처럼 크지 않았다. 교수님 설명처럼 예전에는 킬로바이트(KB), 메가바이트(MB) 단위의 저장 용량을 사용하는 경우가 많았지만, 지금은 스마트폰조차 기가바이트(GB) 단위의 저장 용량을 사용한다.

이처럼 컴퓨터의 저장 용량과 하드웨어 구조가 크게 발전하면서, 기존 BIOS 방식만으로는 현대적인 컴퓨터 환경을 충분히 지원하기 어려워졌다. 그래서 더 큰 저장 장치, 더 유연한 부팅 방식, 더 확장성 있는 구조를 지원하기 위해 UEFI가 등장하게 되었다.

즉, BIOS에서 UEFI로 변화한 이유는 단순히 이름이 바뀐 것이 아니라, 컴퓨터 하드웨어의 발전과 저장 장치 용량 증가에 맞춰 부팅 구조 자체가 더 현대적으로 바뀐 것이라고 볼 수 있다.

Additional Notes (추가 설명)

가상화(Virtualization)를 공부할 때 부팅(Booting)을 먼저 이해하면 도움이 된다. 가상 머신(Virtual Machine)도 결국 하나의 “가짜 컴퓨터”처럼 동작하기 때문에, 그 안에서도 BIOS 또는 UEFI와 비슷한 방식으로 운영체제가 부팅된다.

BIOS와 UEFI의 차이는 처음에는 어렵게 느껴질 수 있지만, 간단히 정리하면 BIOS는 오래된 부팅 방식이고 UEFI는 현대적인 부팅 방식이다. BIOS는 MBR과 관련이 깊고, UEFI는 GPT와 관련이 깊다고 함께 기억하면 좋다.

리눅스(Linux)를 설치할 때 설치 화면에서 BIOS 모드인지 UEFI 모드인지에 따라 파티션 설정 방식이 달라질 수 있다. 특히 UEFI 환경에서는 EFI System Partition(ESP)이라는 별도의 파티션이 사용될 수 있다. 지금 단계에서는 세부 설정을 모두 외우기보다는, 운영체제가 부팅되기 위해서는 펌웨어(Firmware), 부트로더(Bootloader), 저장 장치(Storage)의 부팅 정보가 함께 작동해야 한다는 흐름을 이해하는 것이 중요하다.

Linux Boot Process and Runlevel (리눅스 부팅 과정과 런레벨)

What is Booting? (부팅이란 무엇인가)

부팅(Booting)이란 컴퓨터에 전원이 켜진 뒤, 운영체제(Operating System)를 사용할 수 있는 상태가 되기까지의 과정이다. 컴퓨터는 전원이 들어온다고 바로 사용할 수 있는 것이 아니라, 먼저 하드웨어(Hardware)가 정상인지 확인하고 운영체제를 불러오는 단계를 거친다.

이 과정에서 CPU, RAM, 마더보드(Motherboard), 스토리지(Storage) 등이 제대로 연결되어 있는지 확인된다. 특히 서버(Server)는 메모리 용량이 크기 때문에 부팅 중 메모리 체크(Memory Check)에 시간이 오래 걸릴 수 있다.

BIOS, UEFI, and GRUB (BIOS, UEFI, GRUB)

부팅이 시작되면 가장 먼저 BIOS(Basic Input-Output System) 또는 UEFI(Unified Extensible Firmware Interface)가 실행된다. 이들은 하드웨어를 확인하고, 운영체제를 불러올 수 있는 저장 장치(Storage)를 찾는 역할을 한다.

그 다음에는 GRUB(Grand Unified Bootloader)이라는 부트로더(Bootloader)가 실행된다. GRUB은 리눅스에서 사용할 커널(Kernel)을 선택하고 불러오는 역할을 한다. 즉, BIOS나 UEFI가 하드웨어적인 준비를 담당한다면, GRUB은 운영체제의 핵심인 커널을 실행하는 단계로 연결해 준다.

Kernel and initramfs (커널과 initramfs)

GRUB이 커널(Kernel)을 불러오면, 커널은 메모리(Memory)에 올라가 실행된다. 커널은 보통 압축된 형태로 저장되어 있기 때문에 부팅 과정에서 압축을 해제한 뒤 실행된다.

이후 initramfs(initial RAM file system) 또는 initrd(initial RAM disk)가 사용된다. 이것은 실제 루트 파일 시스템(Root File System)을 사용하기 전까지 임시로 사용하는 파일 시스템이다. 쉽게 말하면, 리눅스가 본격적으로 시작되기 전 필요한 준비 작업을 하기 위한 임시 공간이다.

커널은 하드웨어를 초기화하고, 필요한 드라이버(Driver)를 불러온 뒤, 실제 루트 파일 시스템(Root File System)을 마운트(Mount)한다. 루트 파일 시스템은 리눅스 전체 파일 구조의 출발점이기 때문에 반드시 정상적으로 연결되어야 한다.

init Process and Runlevel (init 프로세스와 런레벨)

커널 초기화가 끝나면 init 프로세스(init process)가 실행된다. init 프로세스는 PID 1(Process ID 1)을 가지며, 사용자 영역(User Space)에서 가장 먼저 실행되는 프로세스이다.

이후 시스템은 정해진 런레벨(Runlevel)에 따라 어떤 상태로 부팅할지 결정한다. 전통적인 리눅스에서는 런레벨이 0부터 6까지 나뉜다.

Runlevel 0은 시스템 종료(Halt), Runlevel 1은 싱글 유저 모드(Single-user Mode), Runlevel 2와 3은 멀티 유저 모드(Multi-user Mode), Runlevel 5는 GUI(Graphical User Interface)가 포함된 멀티 유저 모드, Runlevel 6은 재부팅(Reboot)을 의미한다.

서버(Server)는 보통 그래픽 화면을 사용하지 않기 때문에 Runlevel 3과 비슷한 환경에서 동작한다. 반대로 GUI 환경을 설치하면 Runlevel 5처럼 그래픽 화면으로 부팅될 수 있다.

Boot Flow Summary (부팅 흐름 요약)

리눅스 부팅 과정은 간단히 다음 흐름으로 정리할 수 있다.

전원 켜짐 → BIOS/UEFI 실행 → GRUB 실행 → 커널(Kernel) 로딩 → initramfs/initrd 사용 → 루트 파일 시스템(Root File System) 마운트 → init 프로세스 실행 → 런레벨(Runlevel)에 따른 사용자 환경 진입

Additional Notes (추가 설명)

전통적인 리눅스에서는 Runlevel(런레벨)을 사용했지만, 최신 Ubuntu, Fedora, CentOS 계열에서는 대부분 systemd를 사용한다. 그래서 실제 명령어에서는 runlevel보다 target이라는 표현을 더 자주 볼 수 있다.

운영체제 수업에서는 부팅 과정을 외우는 것보다 흐름을 이해하는 것이 더 중요하다. 핵심 흐름은 “펌웨어(Firmware) → 부트로더(Bootloader) → 커널(Kernel) → initramfs/initrd → 루트 파일 시스템(Root File System) → init/systemd → 사용자 환경(User Environment)” 순서로 기억하면 좋다.

Real and Virtual Computers (진짜와 가짜 컴퓨터)

Virtualization Concept (가상화의 개념)

가상화(Virtualization)는 실제 하드웨어(Hardware)를 그대로 사용하는 것이 아니라, 하드웨어처럼 보이는 환경을 소프트웨어적으로 만들어 사용하는 것을 말한다. 예를 들어 우리가 리눅스(Linux)를 실제 컴퓨터에 직접 설치하지 않고, Virtual Machine(가상 머신)에 설치해서 사용하는 것도 가상화의 한 예이다.

컴퓨터를 구성하는 CPU, Memory, Storage, Motherboard 같은 하드웨어 요소를 실제 물리 장치가 아닌 “가짜 환경”으로 만들어 사용하면, 하나의 컴퓨터 안에서 여러 운영체제(Operating System)를 실행하거나 실습 환경을 안전하게 구성할 수 있다.

Virtual, Emulate, Simulate (Virtual, Emulate, Simulate의 차이)

가짜로 무언가를 만든다는 의미에서 비슷하게 사용되는 용어로 Virtual, Emulate, Simulate가 있다. 세 단어는 모두 “진짜는 아니지만 진짜처럼 보이거나 동작하게 만든다”는 공통점이 있지만, 의미에는 조금씩 차이가 있다.

Virtual(가상)은 실제로 존재하지 않지만, 실제와 같거나 실제와 같은 효과를 얻는 것을 의미한다. 예를 들어 Virtual Machine(가상 머신)은 실제 컴퓨터 한 대가 더 있는 것은 아니지만, 사용자는 마치 별도의 컴퓨터를 사용하는 것처럼 운영체제를 설치하고 실행할 수 있다.

Emulate(에뮬레이트)는 어떤 대상을 흉내 내거나 복제해서 원래의 것과 같거나 비슷하게 동작하도록 만드는 것이다. 다만 실제 원본과 완전히 같은 것은 아니며, 원본의 동작 방식을 따라 하도록 만든 것에 가깝다. 예를 들어 특정 게임기나 오래된 컴퓨터 환경을 현대 컴퓨터에서 실행하는 Emulator(에뮬레이터)가 이에 해당한다.

Simulate(시뮬레이트)는 실제는 아니지만, 겉으로 보기에 실제와 비슷하게 보이거나 동작하도록 만드는 것이다. 원래 대상의 내부 구조를 완전히 복제한다기보다는, 외부에서 관찰되는 현상이나 동작을 비슷하게 재현하는 데 초점이 있다.

Virtual은 실제와 같은 효과를 제공하는 것, Emulate는 원래 대상을 흉내 내어 동작하게 만드는 것, Simulate는 실제처럼 보이는 상황이나 동작을 재현하는 것에 가깝다. 운영체제 수업에서 사용하는 가상 머신(Virtual Machine)은 이 중 Virtualization의 대표적인 예라고 볼 수 있다.

Additional Notes (추가 설명)

간단히 구분하면 Virtualization은 “실제로 있는 것처럼 사용하게 만드는 것”, Emulation은 “다른 시스템을 흉내 내는 것”, Simulation은 “현상이나 상황을 비슷하게 재현하는 것”이라고 이해하면 된다.

운영체제 실습에서는 Virtual Machine(가상 머신)을 통해 Unix나 Linux를 설치하기 때문에, 실제 컴퓨터를 망가뜨릴 걱정 없이 안전하게 명령어와 시스템 설정을 실습할 수 있게 된다.

History of Virtualization (가상화의 역사)

Background of Virtualization (가상화의 등장 배경)

가상화(Virtualization)는 갑자기 등장한 기술이 아니라, 1960년대부터 시작된 오래된 개념이다. 초기의 컴퓨터(Computer)는 지금처럼 개인이 쉽게 사용하는 장비가 아니었다. 가격이 매우 비쌌고, 크기도 컸으며, 전문 지식을 가진 사람만 다룰 수 있는 도구였다.

문제는 이렇게 비싼 컴퓨터를 한 번에 한 사람만 사용할 수 있었다는 점이다. 컴퓨터 자체의 비용뿐만 아니라, 컴퓨터를 관리할 전문가(Expert), 설치 공간(Space), 운영 비용도 필요했기 때문에 자원을 효율적으로 사용하는 방법이 중요해졌다.

Batch Processing (배치 처리)

초기에는 컴퓨터가 쉬는 시간을 줄이기 위해 Batch Processing(배치 처리) 방식이 등장했다. Batch Processing은 사람이 직접 하나씩 명령을 실행하는 것이 아니라, 여러 작업(Job)을 모아서 한 번에 컴퓨터에 전달하는 방식이다.

이 방식은 컴퓨터의 낭비되는 시간을 줄이는 데 도움이 되었다. 하지만 여전히 여러 사람이 동시에 컴퓨터를 사용하는 것은 어려웠다.

Time Sharing (시분할)

여러 사용자가 하나의 컴퓨터를 함께 사용하기 위해 등장한 개념이 Time Sharing(시분할)이다. Time Sharing은 컴퓨터의 사용 시간을 아주 짧은 단위로 나누어 여러 사용자에게 번갈아 제공하는 방식이다.

사용자 입장에서는 자신이 혼자 컴퓨터를 사용하는 것처럼 느끼지만, 실제로는 컴퓨터가 매우 빠르게 여러 사용자의 작업을 번갈아 처리하고 있는 것이다. 이를 통해 한 사용자의 작업이 끝날 때까지 다른 사용자가 기다릴 필요 없이, 여러 사람이 동시에 시스템을 공유할 수 있게 되었다.

Connection to Virtualization (가상화와의 연결)

가상화(Virtualization)는 이러한 자원 공유(Resource Sharing)의 필요성에서 발전한 개념이다. 실제 하드웨어(Hardware)는 하나이지만, 사용자나 시스템 입장에서는 여러 개의 독립된 환경을 사용하는 것처럼 보이게 만드는 것이다.

즉, 가상화의 핵심은 컴퓨터 자원을 더 효율적으로 사용하기 위한 것이다. 초기 컴퓨터의 비싼 비용과 제한된 사용 방식이 Batch Processing과 Time Sharing을 만들었고, 이러한 흐름이 이후 가상화 기술로 이어졌다고 볼 수 있다.

Additional Notes (추가 설명)

Batch Processing(배치 처리)은 “작업을 모아서 한 번에 처리하는 방식”이고, Time Sharing(시분할)은 “여러 사용자가 동시에 쓰는 것처럼 시간을 나눠 사용하는 방식”이다.

가상화(Virtualization)를 이해할 때는 “가짜 컴퓨터를 만든다”는 표현보다, “비싼 하드웨어 자원을 더 효율적으로 나누어 쓰기 위해 발전한 기술”이라고 이해하면 더 정확하다.

Evolution of Virtualization (가상화의 발전 과정)

1970s: Operating Systems and Virtual Resources (1970년대: 운영체제와 가상 자원)

1970년대에는 운영체제(Operating System)가 발전하면서 하나의 컴퓨터 안에서 여러 프로그램이 독립적으로 자원을 사용할 수 있게 되었다. 이때부터 운영체제에서 Virtual(가상)이라는 개념이 자주 등장한다.

대표적인 예가 Virtual Memory(가상 메모리)이다. 실제 RAM(Random Access Memory)은 하나이지만, 각 프로그램은 자신만의 독립적인 메모리 공간을 사용하는 것처럼 동작한다. 또한 VFS(Virtual File System)처럼 실제 파일 시스템의 차이를 숨기고, 프로그램이 통일된 방식으로 파일에 접근할 수 있게 해주는 구조도 가상화의 한 형태라고 볼 수 있다.

즉, 하나의 Mainframe Computer(메인프레임 컴퓨터)에서 여러 프로그램이 독립적으로 하드웨어 자원(Hardware Resource)을 사용하는 것처럼 만들어졌고, 이를 통해 여러 프로그램을 동시에 실행할 수 있게 되었다.

1980s: Personal Computers and Swap (1980년대: 개인용 컴퓨터와 스왑)

1980년대에는 Personal Computer(개인용 컴퓨터)가 대중화되기 시작했다. 이전에는 회사나 기관에서 주로 사용하던 컴퓨터가 점차 개인 가정에서도 사용되기 시작한 것이다.

이 시기에는 Virtual Memory(가상 메모리) 개념과 함께 Swap(스왑)이 중요해졌다. Swap은 RAM이 부족할 때 Storage(스토리지)의 일부 공간을 마치 메모리처럼 사용하는 방식이다. 예를 들어 RAM 용량이 작아서 더 이상 프로그램을 실행하기 어려운 상황에서, 디스크 공간을 임시 메모리처럼 활용해 하드웨어의 한계를 보완하려는 시도였다.

또한 당시에는 업무용 컴퓨터와 개인용 컴퓨터의 하드웨어 특성이 달랐기 때문에, 같은 프로그램이라도 환경에 맞게 따로 만들어야 하는 문제가 있었다. 서로 다른 컴퓨터 간에 데이터(Data)를 주고받는 것도 지금처럼 자연스럽지 않았기 때문에, 호환성(Compatibility)이 중요한 과제가 되었다.

1990s: Diverse Operating Systems and JVM (1990년대: 다양한 운영체제와 JVM)

1990년대에는 Windows, Macintosh, OS/2 등 다양한 Operating System(운영체제)이 등장했다. 운영체제와 하드웨어가 다양해지면서, 개발자는 각각의 환경에 맞게 프로그램을 작성하고 Compile(컴파일)해야 하는 어려움을 겪었다.

이 문제를 해결하는 데 중요한 역할을 한 것이 JVM(Java Virtual Machine)이다. JVM은 Java 프로그램이 특정 하드웨어나 운영체제에 직접 의존하지 않고 실행될 수 있도록 해주는 가상 실행 환경이다. 즉, JVM만 설치되어 있다면 같은 Java 프로그램을 여러 운영체제에서 실행할 수 있었다.

이 개념은 당시 매우 혁신적이었고, Java가 인기를 얻는 중요한 이유가 되었다. 또한 Android(안드로이드) 환경에도 가상 머신(Virtual Machine)의 개념이 사용된다.

이후 VMware와 같은 상용 Virtualization Software(가상화 소프트웨어)도 등장했다. 이를 통해 하나의 컴퓨터 안에서 여러 운영체제를 실행하는 환경이 점점 현실화되었다.

After the 2000s: Virtual Machines, Containers, and Cloud (2000년대 이후: 가상 머신, 컨테이너, 클라우드)

2000년대 이후에는 현재 우리가 사용하는 Virtual Machine(가상 머신) 개념이 본격적으로 정착되었다. 예전에는 Multi-booting(멀티 부팅)을 통해 하나의 컴퓨터에 여러 운영체제를 설치할 수는 있었지만, 한 번에 하나의 운영체제만 실행할 수 있었다.

예를 들어 Windows와 Linux를 같은 컴퓨터에 설치해도 동시에 사용할 수는 없었고, 부팅할 때 하나를 선택해야 했다. 또한 각 운영체제의 데이터가 따로 관리되기 때문에 공용으로 사용하려면 별도의 저장 방식이 필요했다.

하지만 Virtual Machine(가상 머신)을 사용하면 하나의 실제 컴퓨터 안에서 여러 운영체제를 동시에 실행할 수 있다. Windows를 사용하면서 Linux를 함께 실행하거나, 실습용 Unix/Linux 환경을 따로 구성하는 것이 가능해진 것이다.

이후 가상화 기술은 Container(컨테이너) 기술로도 발전했다. 컨테이너는 운영체제 전체를 가상화하기보다는, 애플리케이션(Application)이 실행되는 환경을 가볍게 분리하는 방식이다.

이러한 발전은 Cloud Computing(클라우드 컴퓨팅)이 대중화되는 중요한 기반이 되었다. 하나의 물리 서버(Physical Server)를 여러 사용자와 서비스가 나누어 사용할 수 있게 되었고, 필요한 만큼 서버 환경을 빠르게 만들고 관리할 수 있게 되었다.

Additional Notes (추가 설명)

Virtual Machine(가상 머신)과 Container(컨테이너)는 비슷해 보이지만 차이가 있다. 가상 머신은 운영체제 전체를 포함한 컴퓨터 환경을 가상화하고, 컨테이너는 애플리케이션 실행 환경을 가볍게 분리한다.

간단히 말하면, Virtual Machine은 “가짜 컴퓨터 한 대를 만드는 것”에 가깝고, Container는 “프로그램이 실행될 공간만 따로 분리하는 것”에 가깝다. 클라우드와 서버 개발에서는 두 개념 모두 매우 중요하게 사용된다.

Features, Advantages, and Disadvantages of Virtualization (가상화의 특징, 장점과 단점)

Advantages of Virtualization (가상화의 장점)

가상화(Virtualization)의 가장 큰 장점은 자원 사용률(Resource Utilization)을 높일 수 있다는 점이다. 하나의 물리 머신(Physical Machine)에서 여러 개의 가상 머신(Virtual Machine)을 실행할 수 있기 때문에, CPU, Memory, Storage 같은 하드웨어 자원을 쉬는 시간 없이 더 효율적으로 사용할 수 있다.

또한 비용 절감(Cost Reduction)이 가능하다. 예전에는 새로운 컴퓨터 환경이 필요할 때마다 하드웨어를 따로 준비하고, 디스크를 포맷한 뒤 운영체제(Operating System)와 필요한 프로그램을 설치해야 했다. 하지만 가상화 환경에서는 이미 만들어 둔 가상화 이미지(Virtualization Image)를 복제하면 거의 같은 환경을 빠르게 만들 수 있다.

이처럼 가상 머신을 소프트웨어적으로 빠르게 생성할 수 있다는 점은 매우 큰 장점이다. 물리적인 컴퓨터를 새로 구매하거나 설치하지 않아도 되기 때문에 개발 환경, 실습 환경, 테스트 환경을 빠르게 구성할 수 있다.

또 다른 장점은 장애 복구(Failure Recovery)가 쉬워졌다는 점이다. 가상 머신은 이미지나 스냅샷(Snapshot) 형태로 관리할 수 있기 때문에, 문제가 생겼을 때 이전 상태로 되돌리거나 같은 환경을 다시 만드는 과정이 상대적으로 간단하다. 물론 파일 자체가 손상된 경우에는 별도의 복구 과정이 필요하지만, 전체 시스템 환경을 복원하는 작업은 훨씬 쉬워졌다.

이러한 특징들이 모여 클라우드 컴퓨팅(Cloud Computing)을 가능하게 만든 기반이 되었다. 클라우드에서는 하나의 물리 서버(Physical Server)를 여러 가상 환경으로 나누어 사용자에게 제공할 수 있기 때문이다.

Disadvantages of Virtualization (가상화의 단점)

가상화에는 단점도 있다. 먼저 가상화 소프트웨어(Virtualization Software) 자체가 자원을 사용한다. 실제 하드웨어 위에 가상화 계층(Virtualization Layer)이 하나 더 추가되기 때문에, CPU나 Memory 같은 자원의 일부가 가상화 소프트웨어를 운영하는 데 사용된다.

또한 업무용 환경에서는 추가 비용(Cost)이 발생할 수 있다. 개인 사용자는 무료 가상화 프로그램을 사용할 수 있는 경우가 많지만, 기업 환경에서는 VMware 같은 상용 가상화 솔루션을 사용해야 할 수도 있고, 라이선스 비용이 발생할 수 있다.

마지막으로 가상화 환경을 운영하고 유지관리(Maintenance)하기 위한 전문 인력(Expert Staff)이 필요하다. 가상 머신을 만들고 관리하는 것 자체는 쉬워졌지만, 실제 기업 환경에서는 성능 관리, 장애 대응, 보안 설정, 백업 관리 등이 필요하기 때문에 전문적인 지식이 요구된다.

Additional Notes (추가 설명)

가상화의 핵심은 “하드웨어를 더 효율적으로 나누어 쓰는 것”이다. 그래서 서버, 클라우드, 개발 환경에서 매우 중요하게 사용된다.

단점으로는 성능 오버헤드(Overhead)가 있다. Overhead는 어떤 기능을 사용하기 위해 추가로 들어가는 자원이나 비용을 의미한다. 가상화에서는 가상화 소프트웨어가 중간에 들어가기 때문에 약간의 성능 손실이 생길 수 있다. 다만 현대 가상화 기술에서는 이 손실이 많이 줄어들었기 때문에, 장점이 단점보다 큰 경우가 많다.

Basic Terms in Virtualization (가상화 기본 용어)

Hypervisor / VMM (하이퍼바이저 / 가상 머신 모니터)

Hypervisor(하이퍼바이저) 또는 VMM(Virtual Machine Monitor)은 가상 머신(Virtual Machine)과 실제 하드웨어(Hardware) 사이에서 동작하는 프로그램이다.

가상 머신이 CPU, Memory, Storage 같은 하드웨어 자원을 사용할 수 있도록 관리하며, 가상 머신의 생성(Create), 삭제(Delete), 실행(Run), 중지(Stop) 같은 작업도 담당한다.

즉, Hypervisor는 여러 개의 가상 머신이 하나의 물리 컴퓨터 자원을 나누어 사용할 수 있게 해주는 핵심 소프트웨어이다.

Virtual Machine, VM (가상 머신)

Virtual Machine(VM, 가상 머신)은 실제 컴퓨터처럼 동작하는 가상의 컴퓨터 환경이다. 실제 하드웨어에 운영체제(Operating System)를 직접 설치한 컴퓨터와 구분하기 위해 VM이라는 용어를 사용한다.

VM은 하나의 물리 컴퓨터 자원을 공유해서 사용하지만, 각 VM은 서로 독립적으로 분리(Isolation)되어 있다. 따라서 일반적으로 한 VM에서 발생한 일이 다른 VM에 직접 영향을 주지 않는다.

각 VM은 별도의 운영체제를 설치하고, 사용자 계정도 따로 만들며, 네트워크에서도 별도의 MAC Address(MAC 주소)를 받을 수 있다. 그래서 사용자는 VM을 마치 독립된 컴퓨터처럼 사용할 수 있다.

물론 설정에 따라 Host와 Guest 사이에 파일 공유나 네트워크 연결을 만들 수 있지만, 기본 개념은 서로 분리된 독립적인 컴퓨터 환경이라고 이해하면 된다.

Host and Guest (호스트와 게스트)

Host(호스트)는 Hypervisor가 설치되어 있는 실제 물리 컴퓨터를 의미한다. 예를 들어 내 노트북에 VirtualBox나 VMware를 설치했다면, 그 노트북이 Host가 된다.

Guest(게스트)는 Hypervisor 위에서 실행되는 가상 컴퓨터이다. 즉, VirtualBox 안에 설치한 Linux나 Unix 같은 운영체제가 Guest Operating System(게스트 운영체제)에 해당한다.

Host와 Guest라는 용어를 따로 사용하는 이유는 두 환경의 역할이 다르기 때문이다. Host Operating System(호스트 운영체제)은 실제 컴퓨터에서 실행되는 운영체제이고, Guest Operating System(게스트 운영체제)은 가상 머신 안에서 실행되는 운영체제이다.

Full Virtualization (전가상화)

Full Virtualization(전가상화)은 하드웨어를 거의 완벽하게 흉내 내는 가상화 방식이다. Guest Operating System(게스트 운영체제)은 자신이 가상화 환경에서 실행되고 있다는 사실을 몰라도 된다.

즉, 운영체제를 수정하지 않고 그대로 설치해서 사용할 수 있다. 사용자는 실제 컴퓨터에 운영체제를 설치하는 것과 거의 같은 방식으로 VM에 운영체제를 설치할 수 있다.

이 방식은 사용하기 편하고 이상적인 방식이지만, 하드웨어를 완전히 흉내 내야 하기 때문에 성능 부담(Overhead)이 생길 수 있다.

Para-virtualization (반가상화)

Para-virtualization(반가상화)은 Guest Operating System이 자신이 가상화 환경에서 실행되고 있다는 사실을 알고 동작하는 방식이다.

이 방식에서는 Guest Operating System의 수정이 필요할 수 있다. 대신 Hypercall(하이퍼콜)을 사용하여 Hypervisor와 더 직접적으로 소통할 수 있기 때문에, 더 좋은 성능을 얻을 수 있다.

Full Virtualization이 “운영체제를 그대로 설치해서 쓰는 방식”이라면, Para-virtualization은 “가상화 환경에 맞게 운영체제가 협력하는 방식”이라고 이해할 수 있다.

Additional Notes (추가 설명)

Full Virtualization(전가상화)은 편리하지만 성능 부담이 있을 수 있고, Para-virtualization(반가상화)은 운영체제 수정이 필요할 수 있지만 성능 면에서 유리할 수 있다.

초보 단계에서는 이렇게 기억하면 된다.
Full Virtualization은 “그냥 일반 컴퓨터인 것처럼 속여서 실행하는 방식”이고, Para-virtualization은 “가상화 환경임을 알고 협력해서 실행하는 방식”이다.

QEMU Virtualization Environment (QEMU 가상화 환경)

What is QEMU? (QEMU란 무엇인가)

QEMU는 오픈소스(Open Source) 가상화 및 에뮬레이션 도구이다. QEMU는 하드웨어 전체를 가상으로 제공할 수 있으며, 이를 통해 실제 컴퓨터 안에서 또 다른 컴퓨터 환경을 실행할 수 있다.

QEMU는 단순히 운영체제(Operating System)를 실행하는 것뿐만 아니라, 특정 CPU나 하드웨어 환경을 흉내 내는 기능도 제공한다. 그래서 다른 CPU 구조에 맞게 컴파일된 프로그램이나 운영체제를 실행할 수 있다.

System Emulation (시스템 에뮬레이션)

System Emulation은 컴퓨터 전체를 가상으로 흉내 내는 방식이다. CPU, Memory, Disk, I/O Device 같은 하드웨어를 가상으로 제공해서, Guest Operating System(게스트 운영체제)이 실제 컴퓨터에 설치된 것처럼 동작하게 만든다.

예를 들어 QEMU가 특정 CPU 모델과 하드웨어 구성을 제공하면, 운영체제는 자신이 실제 그 하드웨어 위에서 실행되고 있다고 인식할 수 있다. 즉, QEMU는 운영체제가 필요로 하는 하드웨어 환경을 소프트웨어적으로 만들어주는 역할을 한다.

User Mode Emulation (유저 모드 에뮬레이션)

QEMU는 User Mode Emulation도 지원한다. 이는 운영체제 전체를 실행하는 것이 아니라, 특정 CPU에 맞게 컴파일된 프로그램을 다른 환경에서 실행할 수 있게 해주는 방식이다.

예를 들어 A라는 CPU용으로 만들어진 프로그램이 있다면, QEMU가 A CPU처럼 동작하는 환경을 제공해서 해당 프로그램이 실행될 수 있도록 도와준다. 이때 프로그램은 마치 원래 CPU에서 실행되는 것처럼 동작할 수 있다.

Example Commands (예시 명령어)

사진에 나온 명령어는 QEMU에서 가상 머신을 실행하거나 디스크 이미지를 만드는 예시이다.

qemu-system-x86_64 --machine pc --cpu max --smp 4 --m 2048

이 명령어는 x86_64 아키텍처용 가상 머신을 실행하는 명령어이다. --machine pc는 일반 PC 형태의 가상 머신을 사용한다는 의미이고, --cpu max는 가능한 CPU 기능을 최대한 사용하겠다는 의미이다. --smp 4는 CPU 코어를 4개 사용한다는 뜻이며, --m 2048은 메모리 2048MB, 즉 2GB를 할당한다는 의미이다.

qemu-img create -f raw img_disk 10G

이 명령어는 10GB 크기의 디스크 이미지(Disk Image)를 만드는 명령어이다. -f raw는 raw 형식의 이미지 파일을 만들겠다는 뜻이고, img_disk는 생성될 이미지 파일의 이름이다.

Additional Notes (추가 설명)

QEMU는 단독으로도 사용할 수 있지만, Linux 환경에서는 KVM(Kernel-based Virtual Machine)과 함께 사용하면 성능이 더 좋아질 수 있다. QEMU가 하드웨어를 가상으로 제공하고, KVM이 실제 CPU의 가상화 기능을 활용해 실행 속도를 높여주는 방식이다.

초보 단계에서는 QEMU를 “가상의 컴퓨터 하드웨어를 만들어주는 도구”라고 이해하면 충분하다.

KVM and Virtualization Tools (KVM과 가상화 도구)

KVM (Kernel-based Virtual Machine)

KVM(Kernel-based Virtual Machine)은 리눅스 커널(Linux Kernel)에 포함되어 있는 오픈소스(Open Source) 가상화 기술이다. KVM은 별도의 외부 프로그램처럼만 존재하는 것이 아니라, 리눅스 커널 소스 코드 안에 포함되어 함께 배포된다. 따라서 리눅스 커널 소스를 내려받으면 KVM 관련 소스도 함께 포함되어 있다고 볼 수 있다.

KVM은 Intel VT(Intel Virtualization Technology) 또는 AMD-V(AMD Virtualization) 같은 하드웨어 가상화 기능을 지원하는 x86 하드웨어에서 Full Virtualization(전가상화)을 제공한다. 즉, 게스트 운영체제(Guest Operating System)를 특별히 수정하지 않고도 가상 머신(Virtual Machine) 안에 설치해 사용할 수 있다.

KVM as a Kernel Module (커널 모듈로서의 KVM)

KVM은 리눅스의 커널 모듈(Kernel Module) 형태로 동작할 수 있다. 커널 모듈은 리눅스 커널에 필요한 기능을 추가로 붙여 사용하는 방식이다.

즉, KVM은 리눅스 커널 수준에서 CPU의 가상화 기능을 활용하여 가상 머신이 더 효율적으로 실행되도록 돕는다. 그래서 단순히 소프트웨어로 모든 하드웨어를 흉내 내는 방식보다 성능 면에서 유리하다.

virt-install (가상 머신 설치 도구)

사진에 나온 virt-install은 KVM 자체가 아니라, 가상 머신을 생성하고 설치할 때 사용하는 관리 도구이다. 이 도구를 사용하면 명령어로 가상 머신의 이름, CPU 개수, RAM 용량, 디스크 이미지, 설치 ISO, 네트워크 설정 등을 지정할 수 있다.

예시 명령어에서는 ubuntu24-vm이라는 이름의 가상 머신을 만들고, CPU 2개, RAM 4096MB, 디스크 20GB를 할당한다. 또한 Ubuntu 24.04 ISO 파일을 CD-ROM처럼 연결하여 운영체제를 설치할 수 있게 한다.

여기서 중요한 점은 실제 컴퓨터에 물리적인 CD-ROM이 없어도, ISO 이미지(ISO Image)를 가상 CD-ROM처럼 연결해서 운영체제를 설치할 수 있다는 것이다.

Additional Notes (추가 설명)

QEMU와 KVM은 함께 사용되는 경우가 많다. QEMU는 가상 하드웨어를 제공하고, KVM은 리눅스 커널의 가상화 기능을 이용해 실행 성능을 높여준다.

초보 단계에서는 KVM을 “리눅스 커널이 제공하는 빠른 가상화 기능”, virt-install을 “가상 머신을 만드는 명령어 도구”로 이해하면 충분하다.

KVM(Kernel-based Virtual Machine): 리눅스 커널에 포함된 오픈소스 가상화 기술

Linux Kernel(리눅스 커널): 리눅스 운영체제의 핵심 부분

Kernel Module(커널 모듈): 커널에 기능을 추가하기 위해 사용하는 모듈

Intel VT(Intel Virtualization Technology): 인텔 CPU에서 제공하는 하드웨어 가상화 기능

AMD-V(AMD Virtualization): AMD CPU에서 제공하는 하드웨어 가상화 기능

Full Virtualization(전가상화): 게스트 운영체제를 수정하지 않고 그대로 실행할 수 있는 가상화 방식

virt-install: 명령어로 가상 머신을 생성하고 운영체제를 설치하는 도구

ISO Image(ISO 이미지): CD/DVD 내용을 파일 하나로 만든 이미지 파일

Guest Operating System(게스트 운영체제): 가상 머신 안에 설치되어 실행되는 운영체제

Containers and Virtualization (컨테이너와 가상화)

What is a Container? (컨테이너란 무엇인가)

컨테이너(Container)는 말 그대로 하나의 “박스”처럼 생각할 수 있다. 프로그램을 실행하는 데 필요한 파일, 라이브러리(Library), 설정(Configuration), 실행 환경(Runtime Environment)을 하나로 묶어 패키징(Packaging)한 것이다.

가상 머신(Virtual Machine)은 보통 운영체제(Operating System) 전체를 포함해서 하나의 컴퓨터처럼 동작한다. 반면 컨테이너(Container)는 운영체제 전체를 새로 설치하기보다는, 응용 프로그램(Application)을 실행하는 데 필요한 최소한의 요소만 담는 방식으로 발전했다.

Minimal Environment (최소 실행 환경)

수업에서 리눅스(Linux)를 설치할 때 서버 버전(Server Version)을 minimal로 설치하면, 일반 설치보다 프로그램이 적게 설치된다. 이는 서버에서 굳이 필요하지 않은 그래픽 환경(GUI), 로그인 도구, 여러 응용 프로그램 등을 제외하고 꼭 필요한 기능만 남긴 것이다.

컨테이너(Container)도 이와 비슷한 방향으로 이해할 수 있다. 초기에는 컨테이너 안에 운영체제에 가까운 구성 요소가 많이 포함되기도 했지만, 최근에는 응용 프로그램(Application)과 실행에 필요한 라이브러리(Library), 도구(Tool)만 담는 가벼운 방식으로 많이 사용된다.

즉, 컨테이너는 “프로그램 실행에 필요한 것만 담은 작은 실행 상자”라고 볼 수 있다.

Difference Between VM and Container (가상 머신과 컨테이너의 차이)

가상 머신(Virtual Machine)은 운영체제 전체를 포함한 독립적인 컴퓨터 환경을 만든다. 그래서 VM 안에는 게스트 운영체제(Guest Operating System)가 설치되고, 그 위에서 프로그램이 실행된다.

반면 컨테이너(Container)는 보통 운영체제 전체를 포함하지 않고, 호스트 운영체제(Host Operating System)의 커널(Kernel)을 공유하면서 실행된다. 대신 각 컨테이너는 서로 분리(Isolation)되어 독립적으로 동작한다.

이 때문에 컨테이너는 가상 머신보다 용량이 작고, 실행 속도가 빠르며, 필요한 환경을 더 쉽게 배포할 수 있다.

Containers and Microservices (컨테이너와 마이크로서비스)

컨테이너(Container)는 마이크로서비스(Microservices) 구조에서도 많이 사용된다. 마이크로서비스는 하나의 큰 프로그램을 여러 개의 작은 서비스(Service)로 나누어 독립적으로 관리하는 방식이다.

예를 들어 하나의 컨테이너에는 웹 서버(Web Server)만 넣고, 다른 컨테이너에는 데이터베이스(Database)를 넣고, 또 다른 컨테이너에는 컴파일(Compile)이나 코드 관리 도구를 넣을 수 있다. 이렇게 각 기능을 작은 단위로 나누면 개발, 배포, 유지보수가 더 쉬워진다.

즉, 컨테이너는 각각 독립적으로 실행되는 작은 실행 환경이고, 마이크로서비스는 이런 작은 실행 환경들을 조합해 전체 프로그램을 구성하는 방식이라고 이해할 수 있다.

Additional Notes (추가 설명)

가상 머신(Virtual Machine)은 “컴퓨터 한 대를 통째로 가상으로 만드는 것”에 가깝고, 컨테이너(Container)는 “프로그램 실행에 필요한 환경만 가볍게 포장하는 것”에 가깝다.

그래서 운영체제 실습처럼 전체 OS 환경이 필요할 때는 가상 머신이 적합하고, 실제 서비스 배포나 개발 환경 분리에는 컨테이너가 많이 사용된다.

NetBSD and BSD Family Overview (NetBSD와 BSD 계열 운영체제 개요)

Origin of NetBSD’s Name (NetBSD 이름의 유래)

NetBSD는 BSD 계열에서 발전한 Unix-like Operating System(유닉스 계열 운영체제)이다. 쉽게 말하면, Unix의 영향을 받은 BSD를 기반으로 만들어진 무료 오픈소스 운영체제(Open Source Operating System)라고 이해할 수 있다.

NetBSD라는 이름에서 Net은 Internet(인터넷)과 관련이 있다. NetBSD 프로젝트는 인터넷을 통해 협업하고, 이메일과 네트워크 기반 버전 관리 시스템(Version Control System)을 사용해 운영체제를 개발한 초기 오픈소스 프로젝트 중 하나였다. 그래서 Internet이 프로젝트를 가능하게 한 중요한 기반이 되었고, 이를 반영해 이름에 Net이 들어가게 되었다.

BSD는 Berkeley Software Distribution의 약자로, Unix에서 파생된 운영체제 계열을 의미한다. 따라서 NetBSD라는 이름은 Internet을 기반으로 협업한 BSD 계열 운영체제라는 의미를 담고 있다.

NetBSD and Real-World Usage (NetBSD와 실제 활용)

NetBSD는 소프트웨어와 하드웨어 제품 개발에 활용될 수 있다. 강의에서는 예시로 Apple의 Darwin, Sony PlayStation, Apple AirPods 등이 언급되었다. 즉, BSD 계열 운영체제나 그 구조는 실제 상용 제품과 임베디드 장치(Embedded Device)에서도 사용될 수 있다.

여기서 중요한 점은 NetBSD가 단순히 학습용 운영체제가 아니라, 다양한 하드웨어 환경에서 동작할 수 있도록 설계된 운영체제라는 것이다.

NetBSD, FreeBSD, and OpenBSD

BSD 계열에는 대표적으로 NetBSD, FreeBSD, OpenBSD가 있다. 모두 Unix-like Operating System이지만, 중점적으로 추구하는 방향이 조금씩 다르다.

NetBSD는 Portability(이식성)와 Clean Code(깔끔한 코드)를 중요하게 여긴다. 다양한 하드웨어에서 동작할 수 있도록 설계되어 있으며, 임베디드 시스템(Embedded System)이나 특정 장치 환경에서 활용될 수 있다.

FreeBSD는 Performance(성능)와 Scalability(확장성)에 강점이 있다. 서버(Server) 환경에서 안정적으로 동작하는 데 초점이 있으며, 상용 서비스나 서버 운영 환경에 적합하다. 다만 실제 서버 운영에서는 Linux가 더 익숙하거나 편하다면 Linux를 사용해도 큰 문제는 없다.

OpenBSD는 Security(보안)와 Correctness(정확성)에 중점을 둔다. 보안성이 중요한 시스템, 예를 들어 Firewall(방화벽), IPS(Intrusion Prevention System, 침입 방지 시스템) 같은 보안 장비를 만들 때 활용될 수 있다. 직접 운영체제를 새로 개발하는 것은 어렵고 시간이 많이 들기 때문에, 이미 검증된 OpenBSD 같은 운영체제를 기반으로 사용할 수 있다.

Additional Notes (추가 설명)

BSD 계열과 Linux는 모두 Unix-like Operating System으로 분류되지만, 역사와 라이선스(License), 개발 방식에는 차이가 있다. 처음 학습할 때는 “Linux와 BSD는 명령어와 사용 방식이 비슷한 Unix 계열 운영체제”라고 이해하면 충분하다.

NetBSD, FreeBSD, OpenBSD를 간단히 구분하면 다음처럼 기억할 수 있다. NetBSD는 다양한 장치에서 동작하는 이식성 중심, FreeBSD는 서버 성능 중심, OpenBSD는 보안 중심이다.

Preparing to Install NetBSD on Linux (Linux에서 NetBSD 설치 준비)

Installation Environment (설치 환경)

이번 실습에서는 Linux(리눅스) 환경 안에서 Unix-like Operating System(유닉스 계열 운영체제)인 NetBSD를 설치하는 준비 과정을 다룬다. 굳이 Linux 안에서 NetBSD를 설치하는 이유는 이 과목이 Linux를 중심으로 진행되는 수업이기 때문이다.

현재 실습 구조를 보면, 실제 하드웨어(Hardware) 위에 Windows 운영체제가 있고, 그 위에 VirtualBox(버추얼박스)를 설치한 뒤 Linux를 실행하고 있다. 그리고 다시 그 Linux 안에서 QEMU를 이용해 NetBSD를 설치하려는 구조이다.

즉, NetBSD는 실제 물리 컴퓨터에 직접 설치되는 것이 아니라, QEMU가 제공하는 가상 하드웨어(Virtual Hardware) 위에서 실행된다. 엄밀히 말하면 Linux는 VirtualBox가 보여주는 가상 하드웨어를 사용하고, NetBSD는 Linux 안에서 QEMU가 보여주는 또 다른 가상 하드웨어를 사용하는 것이다.

Step 1: Install QEMU (1단계: QEMU 설치)

첫 번째 준비 단계는 QEMU를 설치하는 것이다. QEMU는 가상 하드웨어를 제공해주는 오픈소스(Open Source) 가상화 및 에뮬레이션 도구이다.

Linux에서 QEMU를 설치하기 위해 다음 명령어를 사용할 수 있다.

여기서 sudo는 관리자 권한으로 명령어를 실행한다는 의미이고, apt install은 Ubuntu 계열 Linux에서 패키지를 설치할 때 사용하는 명령어이다. qemu-system은 시스템 전체를 에뮬레이션하거나 가상 머신을 실행하는 데 필요한 QEMU 패키지이다.

Step 2: Download NetBSD Image (2단계: NetBSD 이미지 다운로드)

두 번째 단계는 NetBSD 설치 이미지(Image)를 다운로드하는 것이다. NetBSD 공식 웹사이트에 접속해서 자신의 가상 하드웨어 환경에 맞는 이미지를 선택해 다운로드한다.

NetBSD는 다양한 하드웨어에서 동작하는 것을 목표로 하는 운영체제이기 때문에, 다운로드할 때 어떤 CPU 아키텍처(Architecture)나 시스템용 이미지를 받을지 선택해야 한다. 일반적인 PC 환경이라면 x86 또는 amd64 계열 이미지를 선택하는 경우가 많다.

다운로드한 NetBSD 이미지 파일은 이후 QEMU에서 가상 CD-ROM이나 설치 디스크처럼 사용된다. 즉, 실제 CD나 USB 없이도 이미지 파일을 이용해 운영체제를 설치할 수 있다.

Additional Notes (추가 설명)

이번 실습 구조는 “가상 머신 안에서 또 다른 가상 머신을 실행하는 구조”에 가깝다. 그래서 실제 컴퓨터에 직접 설치하는 것보다 성능이 느릴 수 있다.

하지만 실습 목적에서는 안전하게 여러 운영체제를 설치하고 삭제해볼 수 있다는 장점이 있다. 운영체제 설치 실습에서는 실제 컴퓨터를 건드리지 않고 가상 환경에서 연습하는 것이 훨씬 안전하다.

Creating and Running a NetBSD Virtual Machine with QEMU (QEMU로 NetBSD 가상 머신 생성 및 실행)

Creating a Virtual Disk Image (가상 디스크 이미지 만들기)

이제 NetBSD를 설치하기 위한 실제 단계로 들어간다. 운영체제(Operating System)를 설치하려면 CPU, RAM, Disk 같은 하드웨어 자원이 필요하다. QEMU에서는 실제 하드디스크 대신 디스크 이미지(Disk Image) 파일을 만들어 가상 하드디스크처럼 사용한다.

예시 명령어는 다음과 같다.

qemu-img create -f qcow2 netbsd.qcow2 4G

이 명령어는 netbsd.qcow2라는 이름의 4GB짜리 가상 디스크를 만든다. 여기서 qcow2는 QEMU에서 자주 사용하는 디스크 이미지 형식이다. 지금 단계에서는 qcow2의 내부 구조까지 자세히 알 필요는 없고, “가상 머신이 사용할 하드디스크 파일”이라고 이해하면 충분하다.

Running the QEMU Virtual Machine (QEMU 가상 머신 실행하기)

디스크 이미지를 만들었다면, 다음 단계는 QEMU로 가상 머신(Virtual Machine)을 실행하는 것이다.

예시 명령어는 다음과 같다.

qemu-system-x86_64 -m 512m -smp 1 -drive file=netbsd.qcow2,format=qcow2 \
-cdrom NetBSD-10.1-amd64.iso -boot d -net nic,model=virtio -net user

이 명령어는 x86_64 구조의 가상 머신을 실행하고, RAM은 512MB, CPU는 1개로 설정한다. -drive 옵션은 앞에서 만든 netbsd.qcow2 디스크 이미지를 가상 하드디스크로 연결하는 부분이다.

-cdrom NetBSD-10.1-amd64.iso는 다운로드한 NetBSD ISO 이미지를 가상 CD-ROM처럼 연결하는 옵션이다. 실제 CD-ROM을 사용하지 않더라도, ISO 파일을 CD처럼 인식시켜 운영체제를 설치할 수 있다.

-boot d는 CD-ROM에서 먼저 부팅하겠다는 의미이다. 즉, NetBSD 설치 ISO로 부팅해서 가상 디스크에 NetBSD를 설치하는 흐름이다.

GUI Display Issue and SSH X Forwarding (GUI 화면 문제와 SSH X 포워딩)

QEMU를 실행했을 때 gtk initialization failed 같은 메시지가 보일 수 있다. 이는 QEMU가 그래픽 화면(GUI, Graphical User Interface)을 띄우려고 했지만, 현재 환경에서 그래픽 화면을 표시할 수 없을 때 발생할 수 있다.

SSH 접속은 기본적으로 텍스트 기반 CLI(Command Line Interface) 접속이다. 하지만 QEMU처럼 그래픽 창을 띄워야 하는 프로그램은 화면 정보를 내 컴퓨터로 전달해야 한다. 이때 사용하는 것이 X Forwarding(X 포워딩)이다.

원격 Linux에 SSH로 접속해서 QEMU 그래픽 화면을 띄우려면 ssh -Y 또는 ssh -X 옵션을 사용할 수 있다. Windows에서 접속하는 경우에는 Xming 같은 X Server(X 서버)가 필요하고, macOS에서는 XQuartz를 사용할 수 있다.

X Server는 원격에서 전달된 그래픽 화면 정보를 내 컴퓨터에서 표시해주는 역할을 한다. 즉, SSH로 접속한 원격 서버에서 실행한 GUI 프로그램을 내 컴퓨터 화면에 띄울 수 있게 해준다.

Additional Notes (추가 설명)

지금 단계에서 중요한 것은 명령어 옵션을 모두 외우는 것이 아니라, QEMU가 “가상의 컴퓨터”를 만들기 위해 CPU, RAM, Disk, CD-ROM 같은 요소를 옵션으로 지정한다는 흐름을 이해하는 것이다.

간단히 정리하면 qemu-img는 가상 디스크를 만드는 명령어이고, qemu-system-x86_64는 실제로 가상 머신을 실행하는 명령어이다.

NetBSD Installation Steps: Boot and Disk Setup

Starting the NetBSD Installer (NetBSD 설치 프로그램 시작)

앞에서 만든 QEMU 가상 머신(QEMU Virtual Machine) 실행 명령어를 입력하면 NetBSD 설치 화면이 나타난다. 처음 부팅 화면에서는 1. Boot normally를 선택하면 된다. 이는 특별한 복구 모드나 옵션 없이 일반적인 방식으로 NetBSD 설치 환경을 시작한다는 의미이다.

부팅 후 파란색 설치 화면이 나타나면 언어 선택 화면에서 Installation messages in English를 선택한다. 한국어는 선택지에 없는데, 이는 NetBSD 사용자가 상대적으로 많지 않고 한국어 번역 지원이 제공되지 않기 때문이라고 이해할 수 있다.

그 다음 Keyboard Type(키보드 종류) 선택 화면에서는 특별히 바꿀 필요가 없다면 unchanged를 선택한다. 만약 본인이 사용하는 키보드 배열이 다르다면 해당하는 옵션을 선택하면 된다.

Choosing Installation to Hard Disk (하드디스크 설치 선택)

다음으로 NetBSD-10.1 Install System 화면이 나오면 NetBSD를 하드디스크(Hard Disk)에 설치하는 옵션을 선택한다. 여기서 말하는 하드디스크는 실제 컴퓨터의 물리 디스크가 아니라, 앞에서 만든 netbsd.qcow2 가상 디스크 이미지(Disk Image)를 의미한다.

QEMU에서는 이 이미지 파일을 가상 하드디스크처럼 보여주기 때문에, NetBSD 설치 프로그램은 마치 실제 디스크에 운영체제를 설치하는 것처럼 인식한다.

Partition Concept (파티션 개념)

설치 과정에서 디스크를 변경해도 되는지 묻는 화면이 나온다. 운영체제를 설치하려면 디스크에 파일 시스템(File System)을 만들고, 필요한 영역을 나누는 작업이 필요하기 때문이다.

디스크(Disk)는 하나의 저장 공간이지만, 필요에 따라 여러 구역으로 나누어 사용할 수 있다. 이 구역을 Partition(파티션)이라고 한다. 예전에는 디스크 전체를 하나의 운영체제가 모두 사용하는 경우가 많았지만, 저장 장치의 용량이 커지면서 하나의 디스크를 여러 용도로 나누어 사용하는 방식이 중요해졌다.

예를 들어 하나의 디스크 안에서 일부는 NetBSD, 일부는 Linux, 일부는 Windows용으로 나누어 사용할 수 있다. 이렇게 나누어진 각각의 영역이 파티션이다.

Boot Sector and GPT (부트 섹터와 GPT)

운영체제를 설치할 때는 단순히 파일만 복사하는 것이 아니라, 컴퓨터가 어디에서 부팅해야 하는지도 정해야 한다. 이와 관련된 개념이 Boot Sector(부트 섹터)와 Partition Table(파티션 테이블)이다.

이번 설치에서는 디스크 크기를 앞에서 만든 그대로 4GB로 사용한다. 이후 파티션 방식으로는 기본값인 GPT(Guid Partition Table)를 선택한다. GPT는 현대적인 파티션 테이블 방식으로, UEFI 환경에서 많이 사용된다.

지금 단계에서는 GPT의 세부 구조를 모두 이해할 필요는 없고, “디스크를 어떻게 나누고 부팅 정보를 어떻게 관리할지 정하는 방식”이라고 이해하면 충분하다.

Additional Notes (추가 설명)

이번 실습에서 디스크를 변경한다고 해도 실제 Windows나 Linux 디스크가 바뀌는 것은 아니다. QEMU 안에서 사용하는 netbsd.qcow2 파일만 가상 하드디스크로 사용되기 때문에 비교적 안전하게 실습할 수 있다.

다만 설치 과정에서는 항상 “내가 지금 실제 디스크를 건드리는지, 가상 디스크를 건드리는지”를 구분하는 습관이 중요하다. 실제 운영체제 설치에서는 이 부분을 잘못 선택하면 기존 데이터가 삭제될 수 있기 때문이다.

NetBSD Disk Partitioning and Swap

Disk Geometry and Partition Setup (디스크 구조와 파티션 설정)

NetBSD 설치 과정에서 디스크 크기를 4GB로 설정한 뒤에는 This is the correct geometry를 선택하면 된다. 여기서 말하는 geometry는 디스크 구조를 의미하는데, 이번 실습에서는 QEMU에서 만든 가상 디스크(Disk Image)를 사용하므로 기본값을 그대로 사용하면 된다.

그다음에는 NetBSD에 맞게 디스크 파티션(Partition)을 설정하는 단계가 나온다. 실제 하드디스크라면 기존 파티션을 삭제하거나, 직접 크기를 조정하거나, 다른 운영체제와 나누어 사용하는 등 여러 선택지가 있을 수 있다. 하지만 이번 실습에서는 새로 만든 4GB 가상 디스크를 사용하므로 자동 설정 옵션인 Set sizes of NetBSD partitions를 선택하면 된다.

파티션(Partition)이란 하나의 디스크(Disk)를 여러 구역으로 나누어 사용하는 것이다. 예를 들어 하나의 디스크 안에 일부는 NetBSD, 일부는 Linux, 일부는 Windows용으로 나누어 사용할 수 있다. 운영체제를 설치할 때는 어느 영역에 시스템을 설치할지, 부팅 정보는 어디에 둘지 등을 정해야 한다.

Swap Partition (스왑 파티션)

파티션 설정 화면을 보면 Swap(스왑)이라는 항목이 보인다. Swap은 RAM(Random Access Memory)이 부족할 때 디스크(Storage)의 일부 공간을 임시 메모리처럼 사용하는 기능이다.

예를 들어 가상 머신에 RAM을 512MB로 설정했는데 여러 프로그램이 실행되면서 메모리가 부족해질 수 있다. 이때 당장 자주 사용하지 않는 메모리 내용을 디스크의 Swap 영역으로 옮기고, RAM 공간을 비워 다른 작업을 계속할 수 있게 한다.

물론 디스크는 RAM보다 훨씬 느리기 때문에 Swap을 사용하면 성능은 느려질 수 있다. 하지만 메모리가 부족해서 프로그램을 아예 실행하지 못하는 것보다는, 느리더라도 디스크를 보조 메모리처럼 사용하는 것이 더 나은 선택이 될 수 있다.

Swap and Modern Systems (스왑과 현대 시스템)

과거에는 RAM 용량이 작았기 때문에 Swap이 매우 중요했다. 예를 들어 32비트(32-bit) 시스템에서는 주소 지정(Addressing)의 한계 때문에 사용할 수 있는 메모리에 제한이 있었다. 그래서 부족한 메모리를 보완하기 위해 Swap을 자주 사용했다.

하지만 현재는 64비트(64-bit) 시스템이 일반적이고, 컴퓨터에 장착되는 RAM 용량도 매우 커졌다. 그래서 일반적인 데스크톱 환경에서는 예전만큼 Swap을 적극적으로 사용하지 않는 경우도 있다. 그럼에도 서버나 가상 머신 환경에서는 메모리 부족 상황을 대비해 Swap 영역을 설정하는 것이 여전히 의미가 있다.

Additional Notes (추가 설명)

이번 실습에서는 실제 디스크가 아니라 QEMU의 가상 디스크를 사용한다. 따라서 파티션을 설정하거나 포맷해도 실제 Windows나 Linux 디스크가 변경되는 것은 아니다.

Swap은 “RAM을 늘려주는 마법 같은 기능”이라기보다는, RAM이 부족할 때 디스크를 임시 대기 공간으로 사용하는 기능이다. 그래서 시스템 안정성에는 도움이 되지만, 성능 자체는 RAM보다 느리다는 점을 함께 기억하면 좋다.

NetBSD Installation Configuration

Partition Size Check (파티션 크기 확인)

NetBSD 설치 과정에서 디스크 설정을 진행하면 free space 2131 MB와 같은 문구가 보일 수 있다. 이는 해당 공간이 아직 사용되지 않은 빈 공간(Free Space)으로 남아 있다는 의미이다. 이번 실습에서는 특별히 수정하지 않고 그대로 진행하면 된다.

이후 파티션 크기(Partition Size)를 확인하는 화면에서 a: 3583, b: 512와 같은 값이 보인다. 여기서 a는 NetBSD가 설치될 주요 파일 시스템(File System) 영역이고, b는 스왑(Swap) 영역으로 이해할 수 있다.

설정이 괜찮다면 Partition sizes ok를 선택하고, 이어서 Shall we continue? 질문에는 Yes를 선택한다.

Console and Installation Type (콘솔과 설치 방식 선택)

다음 단계에서는 콘솔(Console)을 선택한다. 여기서는 Use BIOS console을 선택하면 된다. 이는 설치 화면을 어떤 방식으로 표시할지 정하는 부분이다.

그다음 Select your distribution 화면에서는 Full installation을 선택한다. 처음 설치하는 단계에서는 굳이 구성 요소를 제외할 필요가 없기 때문에 전체 설치를 선택하는 것이 좋다. 필요에 따라 가벼운 설치를 원한다면 minimal 설치를 선택할 수도 있다.

Installation Source (설치 소스 선택)

설치 파일을 어디에서 가져올지 선택하는 화면에서는 CD-ROM / DVD / install image media를 선택한다. 앞에서 QEMU 실행 명령어를 통해 NetBSD ISO Image(ISO 이미지)를 가상 CD-ROM(Virtual CD-ROM)으로 연결했기 때문이다.

만약 네트워크를 통해 설치하려면 HTTP, FTP, NFS 같은 옵션을 사용할 수도 있다. 하지만 이번 실습에서는 이미 다운로드한 ISO 이미지를 사용하므로 CD-ROM 방식으로 진행한다.

Password and Device Setup (비밀번호와 장치 설정)

설치가 진행된 뒤 Hit enter to continue 메시지가 나오면 Enter를 눌러 다음 단계로 넘어간다.

이후 Root Password(루트 비밀번호)를 설정하는 화면이 나온다. 루트 계정(root account)은 시스템 관리자 권한을 가진 계정이므로, 설치 후 관리 작업에 사용된다.

그 다음 USB 장치 등을 지금 테스트할 것인지 묻는 화면이 나오면 Not now, continue!를 선택한다. 이는 지금 바로 외부 장치를 연결해 확인하지 않고, 다음 단계로 넘어가겠다는 의미이다.

Final Configuration and SSHD (최종 설정과 SSHD)

마지막으로 지금까지 선택한 설정을 확인하는 화면이 나온다. 여기서 파티션 설정, 설치할 프로그램, 시스템 설정 등을 확인할 수 있다.

이 상태로 설치를 마치려면 Finished configuring을 선택하면 된다.

다만 원격 접속(Remote Access)을 사용하려면 Enable sshd 항목을 Yes로 바꾸는 것이 좋다. sshd는 SSH 서버 데몬(SSH Server Daemon)으로, 외부에서 SSH(Secure Shell)를 통해 NetBSD에 접속할 수 있게 해준다.

키보드의 방향키와 Spacebar(스페이스바)를 이용해 항목을 이동하고, Enter를 눌러 Yes/No 값을 바꿀 수 있다. Enable sshd를 Yes로 설정한 뒤 Finished configuring을 선택하면 기본 설정이 완료된다.

이번 단계에서는 NetBSD 설치를 위한 파티션 크기를 확인하고, BIOS Console을 사용하도록 설정한 뒤, Full installation을 선택한다. 설치 소스는 앞에서 연결한 ISO 이미지를 사용하므로 CD-ROM/DVD/install image media를 선택한다.

이후 루트 비밀번호를 설정하고, 최종 설정 화면에서 필요하다면 Enable sshd를 Yes로 변경한다. SSHD를 활성화하면 설치 후 원격에서 NetBSD 시스템에 접속할 수 있게 된다.

Additional Notes (추가 설명)

이번 실습에서는 가상 디스크를 사용하므로 파티션 설정을 기본값으로 진행해도 큰 문제가 없다. 실제 컴퓨터에 운영체제를 설치할 때는 기존 데이터가 삭제될 수 있으므로 파티션 선택을 훨씬 더 신중하게 해야 한다.

sshd는 서버 실습에서 매우 중요하다. GUI 없이 CLI 환경으로 서버를 관리할 때는 SSH를 통해 원격 접속하는 경우가 많기 때문이다.

Finishing NetBSD Installation and Exiting QEMU

Reboot After Installation (설치 후 재부팅)

NetBSD 설치 설정이 끝나면 다시 NetBSD-10.1 Install System 화면이 나타난다. 이때는 다시 설치를 반복하는 것이 아니라, Install NetBSD to hard disk가 아닌 Reboot the computer를 선택한다.

하지만 재부팅을 해도 다시 Installation messages in English 화면으로 돌아오고, 다시 설치 메뉴가 나타날 수 있다. 이는 설치가 실패했다는 뜻이라기보다는, QEMU가 여전히 NetBSD 설치 ISO Image(설치 이미지)로 부팅하고 있기 때문이다.

즉, 가상 머신(Virtual Machine)이 하드디스크가 아니라 CD-ROM ISO에서 다시 부팅하고 있어서 설치 화면이 반복되는 것이다.

Why the Installer Appears Again (설치 화면이 다시 나오는 이유)

앞에서 QEMU를 실행할 때 -cdrom NetBSD-10.1-amd64.iso 옵션을 사용했다. 이 옵션은 ISO 파일을 가상 CD-ROM(Virtual CD-ROM)처럼 연결한다는 뜻이다. 또한 -boot d 옵션을 사용하면 CD-ROM에서 먼저 부팅하게 된다.

그래서 NetBSD가 가상 디스크(Disk Image)에 설치되었더라도, QEMU를 같은 명령어로 다시 실행하면 계속 설치 ISO로 부팅될 수 있다. 이 때문에 설치 화면이 도돌이표처럼 반복되는 것이다.

How to Exit QEMU (QEMU 종료 방법)

이 상황에서 Windows 컴퓨터나 VirtualBox 전체를 끌 필요는 없다. QEMU는 Linux 터미널에서 실행 중인 하나의 프로세스(Process)이기 때문이다.

처음에 qemu-system-x86_64 ... 명령어를 실행했을 때, QEMU가 하나의 프로그램으로 실행되었다. 우리가 보는 파란 설치 화면은 실제 컴퓨터가 아니라, QEMU 프로세스가 보여주는 가상 머신 화면이다.

따라서 설치가 끝난 뒤 QEMU를 종료하려면 Linux 터미널에서 Ctrl + C를 누르면 된다. 그러면 실행 중이던 QEMU 프로세스가 종료되고, 가상 머신 화면도 사라진다.

After Exiting QEMU (QEMU 종료 후)

QEMU를 종료했다고 해서 설치한 NetBSD가 사라지는 것은 아니다. NetBSD는 앞에서 만든 netbsd.qcow2 디스크 이미지(Disk Image)에 설치되어 있다.

다음에 NetBSD를 실행할 때는 설치 ISO로 다시 부팅하지 않도록 해야 한다. 즉, CD-ROM 설치 이미지로 부팅하는 것이 아니라, 설치가 완료된 가상 하드디스크(Virtual Hard Disk)에서 부팅해야 한다.

Additional Notes (추가 설명)

설치가 끝난 뒤 다시 설치 화면이 나오는 가장 흔한 이유는 Boot Order(부팅 순서)가 여전히 CD-ROM을 먼저 보도록 되어 있기 때문이다.

간단히 말하면, 설치할 때는 ISO에서 부팅하고, 설치가 끝난 뒤에는 가상 디스크에서 부팅해야 한다.

Booting NetBSD from the Installed Disk

Running QEMU Without CD-ROM (CD-ROM 제거 후 QEMU 실행)

NetBSD 설치가 끝난 뒤에는 다시 Linux Terminal(리눅스 터미널)로 돌아온다. 이때 이전 설치 명령어와 달리 -cdrom 옵션이 빠진 명령어를 사용한다.

qemu-system-x86_64 -m 512m -smp 1 -drive file=netbsd.qcow2,format=qcow2 \
-net nic,model=virtio -net user

이 명령어는 이미 설치가 완료된 netbsd.qcow2 디스크 이미지(Disk Image)에서 NetBSD를 부팅하라는 의미이다. 설치할 때는 ISO Image(ISO 이미지)를 CD-ROM처럼 연결했지만, 이제는 운영체제가 디스크에 설치되어 있으므로 CD-ROM이 필요하지 않다.

여기서 -m 512m은 RAM을 512MB로 설정한다는 뜻이고, -smp 1은 CPU를 1개 사용한다는 뜻이다. -drive 옵션은 NetBSD가 설치된 가상 하드디스크(Virtual Hard Disk)를 연결하는 부분이다.

Logging into NetBSD (NetBSD 로그인)

QEMU를 실행하면 NetBSD 부팅 화면이 나타난다. 처음 메뉴에서는 1. Boot normally를 선택하면 된다. 이후 부팅 메시지가 화면에 출력되고, 마지막에 커서가 깜빡이는 로그인 화면이 나타난다.

이때 설치 과정에서 설정한 비밀번호를 입력하면 로그인할 수 있다. 로그인 후 프롬프트(Prompt)에 #가 보이면 Root User(루트 사용자)로 로그인한 상태이고, $가 보이면 일반 사용자(Regular User)로 로그인한 상태이다.

Root User는 시스템 관리자 권한을 가진 계정이므로, 시스템 설정이나 프로그램 설치 같은 작업을 수행할 수 있다.

Starting X Window (X Window 실행)

NetBSD에 로그인한 뒤 그래픽 환경을 실행하고 싶다면 프롬프트에서 다음 명령어를 입력한다.

startx

startx는 X Window System(X 윈도우 시스템)을 시작하는 명령어이다. X Window System은 Unix/Linux 계열 운영체제에서 GUI(Graphical User Interface)를 제공하는 기본적인 그래픽 시스템이다.

즉, 터미널 기반 CLI(Command Line Interface) 환경에서 그래픽 화면을 실행하고 싶을 때 startx를 사용할 수 있다.

Nested Virtualization Environment (중첩된 가상화 환경)

이번 실습 환경은 실제 컴퓨터 위에 Windows가 있고, 그 위에서 VirtualBox가 Linux를 실행하며, 다시 Linux 안에서 QEMU가 NetBSD를 실행하는 구조이다. 즉, 여러 단계로 가상화가 겹쳐 있는 Nested Virtualization(중첩 가상화) 환경이라고 볼 수 있다.

이런 구조에서도 NetBSD는 비교적 작은 용량으로 설치되고 실행된다. 실습에서는 RAM 512MB, 디스크 4GB 정도로도 기본적인 운영이 가능하다. 이를 통해 운영체제 자체는 생각보다 적은 하드웨어 자원으로도 동작할 수 있다는 점을 알 수 있다.

반대로 고성능 게임기나 그래픽 중심 장치에서는 운영체제보다 그래픽 처리 장치(Graphics Processing Unit, GPU)의 역할이 더 중요할 수 있다. 운영체제는 기본적인 시스템 관리를 담당하고, 화려한 그래픽 처리는 주로 그래픽 하드웨어의 지원을 받는다.

Summary (정리)

NetBSD 설치 후에는 더 이상 ISO 이미지로 부팅하지 않고, netbsd.qcow2 가상 디스크에서 직접 부팅한다. 이를 위해 QEMU 실행 명령어에서 -cdrom 옵션을 제거한다.

부팅 후 Boot normally를 선택하고 로그인하면 NetBSD를 사용할 수 있다. 프롬프트가 #이면 루트 사용자, $이면 일반 사용자이다. 그래픽 환경이 필요하면 startx 명령어로 X Window System을 실행할 수 있다.

Additional Notes (추가 설명)

설치할 때는 ISO 이미지에서 부팅하고, 설치가 끝난 뒤에는 가상 디스크에서 부팅해야 한다. 그래서 설치 후 실행 명령어에서는 -cdrom과 -boot d 옵션을 제거하는 것이 중요하다.

# 프롬프트는 강력한 관리자 권한을 의미하므로 명령어를 입력할 때 주의해야 한다. 시스템 파일을 수정하거나 삭제할 수 있기 때문이다.

실습 결과

설치 후 ISO 이미지 없이 netbsd.qcow2 가상 디스크에서 부팅하였고, root 계정으로 로그인하여 NetBSD가 정상적으로 실행되는 것을 확인하였다. Minimal installation으로 설치했기 때문에 X Window 실행은 진행하지 않았다

Server Hardware and Its Characteristics (서버 하드웨어와 특징)

서버(Server)는 일반 개인용 컴퓨터(Personal Computer)보다 훨씬 높은 성능과 안정성을 요구하는 컴퓨터 시스템이다. 개인용 컴퓨터는 주로 한 명의 사용자가 개인적인 작업을 하기 위해 사용하는 반면, 서버는 여러 사용자가 동시에 접속하여 서비스를 이용할 수 있도록 항상 동작해야 한다.

서버와 개인용 컴퓨터의 가장 큰 차이점 중 하나는 운영 시간(Uptime)이다. 과거에는 전기를 아끼기 위해 컴퓨터를 사용하지 않을 때 꺼두는 것이 일반적이었다. 하지만 서버는 웹사이트, 금융 서비스, 행정 시스템, 데이터베이스(Database) 등 다양한 서비스를 계속 제공해야 하기 때문에 하루 24시간, 일주일 내내 켜져 있어야 한다. 따라서 서버 하드웨어(Server Hardware)는 장시간 안정적으로 작동할 수 있도록 설계되어야 한다.

또한 서버는 높은 수준의 보안(Security)을 유지해야 한다. 개인용 컴퓨터는 주로 개인이 사용하는 장치이기 때문에 문제가 생기더라도 영향 범위가 비교적 작다. 하지만 서버는 다수의 사용자가 접근하는 시스템이므로 보안 문제가 발생하면 그 피해가 훨씬 커질 수 있다. 예를 들어 금융권 서버(Financial Server)가 마비되거나 행정기관 서버(Government Server)가 중단된다면 많은 사람들이 서비스를 이용하지 못하게 되고, 복구에도 오랜 시간이 걸릴 수 있다. 이러한 이유로 서버는 외부 공격, 무단 접근, 데이터 유출 등을 막기 위한 보안 체계가 중요하다.

서버는 동시에 많은 사용자의 접속을 처리할 수 있어야 한다. 개인용 컴퓨터는 보통 한 명 또는 소수의 사용자가 사용하는 것을 기준으로 만들어졌기 때문에 대량의 접속 요청을 처리하기 어렵다. 많은 사용자가 동시에 접속하면 CPU, 메모리(Memory), 저장장치(Storage), 네트워크 대역폭(Network Bandwidth) 등 여러 자원이 빠르게 부족해질 수 있다. 따라서 서버는 높은 하드웨어 성능(Hardware Performance)과 안정적인 네트워크 처리 능력(Network Performance)을 갖추어야 한다.

결국 서버 하드웨어(Server Hardware)는 높은 성능, 긴 운영 시간, 강력한 보안, 많은 사용자 접속 처리 능력을 모두 감당할 수 있어야 한다. 개인용 컴퓨터와 비교했을 때 서버는 단순히 성능이 좋은 컴퓨터가 아니라, 여러 사용자를 위한 서비스를 안정적으로 제공하기 위해 설계된 시스템이라고 볼 수 있다.

Uptime(운영 시간)은 서버가 중단되지 않고 계속 동작하는 시간을 의미한다. 서버에서는 이 Uptime이 매우 중요하며, 서비스가 멈추는 시간을 Downtime(중단 시간)이라고 한다.

Network Bandwidth(네트워크 대역폭)는 일정 시간 동안 네트워크를 통해 전송할 수 있는 데이터의 양을 의미한다. 많은 사용자가 동시에 서버에 접속하면 네트워크 대역폭이 부족해질 수 있다.

Server Software and Daemon-Based Operation (서버 소프트웨어와 데몬 기반 동작)

서버(Server)는 단순히 성능이 높은 하드웨어(Hardware)만을 의미하지 않는다. 서버 하드웨어 위에는 반드시 운영체제(Operating System)와 서버 역할을 수행하는 소프트웨어(Software)가 설치되어야 한다. 그래서 “서버를 설치한다”라고 하면 처음에는 서버 전용 하드웨어가 따로 있어야 한다고 생각할 수 있지만, 실제로는 개인용 컴퓨터(Personal Computer)나 가상 머신(Virtual Machine) 위에도 서버 소프트웨어를 설치하여 서버처럼 동작하게 만들 수 있다.

예를 들어 우분투 리눅스(Ubuntu Linux)를 설치할 때 데스크톱 버전(Desktop Version)이 아니라 서버 버전(Server Version)을 설치했다면, 물리적으로는 개인용 컴퓨터 위에서 실행되고 있더라도 기능적으로는 서버 역할을 수행할 수 있다. 즉 서버와 클라이언트(Client)의 구분은 단순히 하드웨어 종류로만 결정되는 것이 아니라, 실제로 어떤 기능을 수행하는지에 따라 달라진다. 클라이언트의 요청(Request)을 받아 처리하고 응답(Response)을 제공한다면 그 시스템은 서버로 볼 수 있다.

서버 소프트웨어(Server Software)는 하드웨어 위에 설치되어 클라이언트의 요청을 처리하는 역할을 한다. 이 소프트웨어는 개인용 컴퓨터에 설치하든, 서버급 하드웨어(Server-Class Hardware)에 설치하든 기본적인 동작 원리는 같다. 다만 실제 서비스 환경에서는 많은 요청을 안정적으로 처리해야 하기 때문에 더 높은 성능과 안정성이 요구된다.

서버 소프트웨어의 중요한 특징 중 하나는 데몬(Daemon) 형태로 동작한다는 점이다. 리눅스(Linux)에서 프로그램 이름 뒤에 &를 붙이면 해당 프로그램을 백그라운드(Background)에서 실행할 수 있다. 백그라운드 실행은 사용자가 직접 화면에서 계속 조작하지 않아도 프로그램이 뒤에서 동작하는 방식이다. 서버 프로그램도 이와 비슷하게 사용자의 직접적인 개입 없이 계속 실행된다.

하지만 데몬(Daemon)은 단순히 백그라운드에서 실행되는 프로그램보다 더 서버 관리에 적합한 형태라고 볼 수 있다. 데몬은 시스템이 시작될 때 자동으로 실행될 수 있고, 사용자가 직접 명령을 입력하지 않아도 지속적으로 동작한다. 또한 서버 운영을 위해 필요한 관리 기능이나 보호 기능도 함께 포함될 수 있다. 따라서 데몬은 백그라운드에서 지속적으로 실행되며, 사용자와 직접 상호작용하지 않고 필요한 서비스를 제공하는 프로그램이라고 정리할 수 있다.

Linux Server Version and Desktop Version (리눅스 서버 버전과 데스크톱 버전)

리눅스 서버 버전(Linux Server Version)과 데스크톱 버전(Desktop Version)의 가장 큰 차이는 사용 목적과 사용자 상호작용(User Interaction)에 있다. 데스크톱 운영체제(Desktop Operating System)는 개인 사용자가 키보드(Keyboard), 마우스(Mouse), 화면(Display)을 통해 직접 조작하는 환경을 기준으로 만들어진다. 따라서 사용자가 입력했을 때 빠르게 반응하는 응답성(Responsiveness)이 중요하다. 우리가 스마트폰(Smartphone)이나 개인용 컴퓨터를 사용할 때 버튼을 누르면 즉시 반응하기를 기대하는 것과 같다.

반면 서버 운영체제(Server Operating System)는 사용자가 직접 화면을 보며 계속 조작하는 환경을 전제로 하지 않는다. 서버는 대부분 혼자 백그라운드에서 동작하면서 클라이언트의 요청을 처리한다. 따라서 키보드나 마우스 입력에 즉각 반응하는 것보다, 네트워크 요청(Network Request), 프로세스 처리(Process Handling), 파일 관리(File Management), 보안(Security), 안정성(Stability) 같은 기능적인 부분이 더 중요하다.

이 때문에 우분투 서버(Ubuntu Server)를 설치하면 일반적인 그래픽 화면(Graphical User Interface, GUI)이 아니라 검은 터미널 화면(Command Line Interface, CLI)이 나타난다. 이는 오류가 아니라 서버용 운영체제가 사용자 편의성을 위한 그래픽 환경보다 기능성과 자원 효율(Resource Efficiency)을 더 중요하게 설계되었기 때문이다. GUI가 없으면 그래픽 화면을 유지하는 데 필요한 CPU, 메모리(Memory), 저장 공간(Storage)을 줄일 수 있고, 그 자원을 서버 기능에 더 집중할 수 있다.

결국 데스크톱 운영체제는 사용자가 직접 조작하기 편한 환경에 초점을 맞추고, 서버 운영체제는 서비스를 안정적으로 제공하는 기능에 초점을 맞춘다. 이 차이는 운영체제 내부의 스케줄러(Scheduler) 관점에서도 이해할 수 있다. 데스크톱 환경에서는 사용자의 입력에 빠르게 반응하는 작업의 우선순위가 중요하지만, 서버 환경에서는 여러 클라이언트 요청을 효율적이고 안정적으로 처리하는 것이 더 중요하다.

Daemon(데몬)은 리눅스나 유닉스(Unix) 계열 시스템에서 백그라운드로 계속 실행되며 특정 서비스를 제공하는 프로그램을 의미한다. 예를 들어 웹 서버(Web Server), 데이터베이스 서버(Database Server), SSH 서버(SSH Server) 등이 데몬 형태로 동작할 수 있다.

CLI(Command Line Interface)는 명령어를 입력해서 컴퓨터를 조작하는 방식이고, GUI(Graphical User Interface)는 아이콘, 창, 버튼처럼 시각적인 요소를 이용해 조작하는 방식이다. 서버에서는 보통 CLI를 많이 사용하는데, 이는 자원을 적게 사용하고 원격 관리(Remote Administration)에 적합하기 때문이다.

서버(Server)와 클라이언트(Client)의 구분은 물리적인 기계의 종류보다 역할(Role)에 따라 결정된다. 같은 컴퓨터라도 다른 컴퓨터의 요청을 처리하면 서버가 될 수 있고, 다른 서버에 요청을 보내 서비스를 이용하면 클라이언트가 될 수 있다.

백그라운드 실행(Background Execution)과 데몬(Daemon)은 비슷하지만 완전히 같은 개념은 아니다. 백그라운드 실행은 단순히 프로그램을 뒤에서 실행하는 방식이고, 데몬은 시스템 서비스(System Service)로서 자동 실행, 지속 실행, 관리 기능 등을 포함하는 경우가 많다.

X11 and the X Window System (X11과 X 윈도우 시스템)

리눅스 서버(Linux Server)를 설치하면 일반적인 윈도우 창(Window)이 뜨지 않고, 검은색 터미널 화면(Command Line Interface, CLI)만 보이는 경우가 많다. 반면 리눅스 데스크톱 버전(Linux Desktop Version)이나 안드로이드(Android)처럼 리눅스 커널(Linux Kernel)을 기반으로 하는 시스템에서는 화면에 창이 뜨고, 사용자는 마우스(Mouse), 키보드(Keyboard), 화면(Screen)을 통해 그래픽 환경(Graphical User Interface, GUI)을 사용할 수 있다. 그렇다면 리눅스 기반 시스템에서 이런 그래픽 화면은 어떻게 동작하는지 이해할 필요가 있다.

과거 유닉스(Unix) 계열 시스템에서는 그래픽 화면을 처리하기 위해 X Window System, 즉 X11(X Window System)이라는 구조를 사용했다. X11의 중요한 특징은 화면 출력도 클라이언트-서버 구조(Client-Server Architecture)로 동작한다는 점이다. 일반적으로 우리가 생각하는 서버(Server)와 클라이언트(Client)의 관계는 사용자의 컴퓨터가 클라이언트이고, 멀리 있는 데이터센터(Data Center)의 컴퓨터가 서버인 경우가 많다. 사용자가 웹사이트에 접속하거나 정보를 요청하면, 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 제공하는 구조이다.

하지만 X11(X Window System)에서는 이 개념이 조금 반대로 보일 수 있다. 사용자의 앞에 있는 컴퓨터, 즉 키보드(Keyboard), 마우스(Mouse), 화면(Screen)을 가진 워크스테이션(Workstation)이 X Server(X 서버)가 된다. 그리고 실제로 실행되는 원격 프로그램(Remote Program)이 X Client(X 클라이언트)가 된다. 처음 들으면 헷갈릴 수 있지만, 여기서 서버와 클라이언트는 물리적인 위치가 아니라 기능적인 역할(Role)에 따라 구분된다.

X Server and X Client (X 서버와 X 클라이언트)

X Server(X 서버)는 사용자의 화면(Screen), 키보드(Keyboard), 마우스(Mouse) 같은 입출력 장치(Input/Output Devices)를 관리한다. 사용자가 실제로 보는 화면을 그려주고, 사용자의 입력을 받아 처리하는 역할을 한다. 따라서 X11 구조에서는 사용자 앞에 있는 컴퓨터가 X 서버가 된다.

반대로 X Client(X 클라이언트)는 화면에 표시될 프로그램이다. 예를 들어 원격 컴퓨터(Remote Machine)에서 실행 중인 프로그램이 “이 창을 화면에 띄워 주세요”라고 요청하면, 그 요청을 X Server(X 서버)가 받아 사용자의 화면에 창을 표시한다. 즉 X 클라이언트는 실제 응용 프로그램(Application Program)이고, X 서버는 그 응용 프로그램의 화면 출력을 담당하는 시스템이라고 볼 수 있다.

첨부된 그림에서도 위쪽의 User’s Workstation(사용자 워크스테이션)에 Keyboard(키보드), Mouse(마우스), Screen(화면)이 있고, 그 안에 X Server(X 서버)가 위치해 있다. 그리고 X Client(X 클라이언트)는 같은 컴퓨터 안에 있을 수도 있고, 네트워크(Network)를 통해 연결된 Remote Machine(원격 컴퓨터)에 있을 수도 있다. 원격 컴퓨터에서 실행되는 X Client(X 클라이언트)는 네트워크를 통해 X Server(X 서버)에 화면 출력을 요청하고, 사용자는 자신의 화면에서 그 결과를 볼 수 있다.

Why the Server Is on the User Side (왜 사용자의 컴퓨터가 서버인가)

일반적인 웹 서비스(Web Service)에서는 사용자의 컴퓨터가 클라이언트(Client)이고, 서비스를 제공하는 컴퓨터가 서버(Server)이다. 하지만 X11(X Window System)에서는 사용자의 화면을 제공하는 쪽이 X Server(X 서버)이기 때문에 사용자의 컴퓨터가 서버가 된다.

서버(Server)는 어떤 서비스를 제공하는 쪽이다. X11에서 제공되는 서비스는 화면 출력(Display Output), 키보드 입력(Keyboard Input), 마우스 입력(Mouse Input) 관리이다. 따라서 사용자의 컴퓨터가 이 서비스를 제공하므로 X Server(X 서버)라고 부른다. 반면 원격에서 실행되는 프로그램은 화면을 직접 가지고 있지 않고, X Server에게 “내 화면을 표시해 달라”고 요청하므로 X Client(X 클라이언트)가 된다.

이 부분은 서버와 클라이언트의 개념을 기능적 관점(Functional Perspective)에서 이해하는 좋은 예시이다. 서버와 클라이언트는 반드시 “멀리 있는 고성능 컴퓨터 = 서버”, “내 앞의 컴퓨터 = 클라이언트”로 정해지는 것이 아니다. 어떤 기능을 제공하느냐, 어떤 쪽이 요청을 보내느냐에 따라 역할이 달라질 수 있다.

X11 and Remote Display (X11과 원격 화면 출력)

X11(X Window System)의 중요한 특징 중 하나는 원격 화면 출력(Remote Display)이 가능하다는 점이다. 원격 컴퓨터(Remote Machine)에서 프로그램이 실행되더라도, 그 프로그램의 창(Window)을 사용자의 화면에 띄울 수 있다. 이때 원격 프로그램은 X Client(X 클라이언트)로 동작하고, 사용자의 컴퓨터는 X Server(X 서버)로 동작한다.

예를 들어 서버에 직접 모니터가 연결되어 있지 않더라도, 원격에서 실행한 프로그램의 그래픽 화면을 사용자의 컴퓨터로 전달할 수 있다. 사용자는 자신의 키보드와 마우스로 프로그램을 조작하고, 그 결과를 자신의 화면에서 확인할 수 있다. 이 개념은 나중에 배우게 될 SSH(Secure Shell)와도 연결된다. SSH는 기본적으로 텍스트 기반 원격 접속(Remote Text Login)을 제공하지만, 설정에 따라 X11 Forwarding(X11 포워딩)을 사용하면 원격 프로그램의 그래픽 화면을 로컬 화면에 띄우는 것도 가능하다.

Linux Server and GUI (리눅스 서버와 GUI)

리눅스 서버 버전(Linux Server Version)은 기본적으로 GUI(Graphical User Interface)를 포함하지 않는 경우가 많다. 서버는 사용자가 직접 화면을 보며 마우스로 조작하는 것보다, 네트워크 요청(Network Request)을 처리하고 서비스를 안정적으로 실행하는 것이 더 중요하기 때문이다. 그래서 리눅스 서버를 설치하면 검은 터미널 화면만 보이고, 창이나 아이콘 같은 그래픽 환경이 나타나지 않는다.

하지만 GUI가 없다고 해서 서버에서 그래픽 프로그램을 전혀 사용할 수 없는 것은 아니다. X11(X Window System) 같은 구조를 이용하면, 실제 프로그램은 서버나 원격 컴퓨터에서 실행되고 화면은 사용자의 컴퓨터에 표시할 수 있다. 즉 리눅스 서버는 기본적으로 텍스트 기반으로 관리되지만, 필요하다면 원격 화면 출력(Remote Display) 방식으로 그래픽 정보를 확인할 수도 있다.

다만 이번 단계에서는 X11의 세부 동작 원리를 모두 깊게 이해할 필요는 없다. 중요한 것은 리눅스나 유닉스 계열 시스템에서 그래픽 화면도 클라이언트-서버 구조(Client-Server Architecture)로 동작할 수 있으며, X11에서는 사용자의 화면을 관리하는 쪽이 X Server(X 서버)이고, 화면에 표시될 프로그램이 X Client(X 클라이언트)라는 점이다.

X11(X Window System)은 유닉스(Unix)와 리눅스(Linux) 계열 시스템에서 오래 사용된 그래픽 시스템이다. 현대 리눅스 데스크톱에서는 Wayland(웨이랜드)라는 새로운 디스플레이 서버 프로토콜(Display Server Protocol)도 많이 사용되지만, X11 개념은 리눅스 그래픽 환경을 이해하는 데 여전히 중요하다.

X Server(X 서버)는 화면, 키보드, 마우스를 관리하는 쪽이고, X Client(X 클라이언트)는 화면에 표시될 응용 프로그램(Application Program)이다. 이 때문에 X11에서는 사용자의 앞에 있는 컴퓨터가 서버가 될 수 있다.

SSH(Secure Shell)는 원격 서버에 접속할 때 사용하는 대표적인 텍스트 기반 원격 접속 도구이다. 일반적으로는 터미널 명령어(Command)를 입력해 서버를 관리하지만, X11 Forwarding(X11 포워딩)을 사용하면 원격 서버에서 실행한 GUI 프로그램을 내 컴퓨터 화면에 띄울 수도 있다.

이번 내용에서 가장 헷갈리기 쉬운 부분은 “왜 내 앞의 컴퓨터가 서버인가?”이다. 서버(Server)는 물리적으로 멀리 있는 컴퓨터라는 뜻이 아니라, 어떤 기능을 제공하는 프로그램 또는 시스템이라는 뜻이다. X11에서는 내 컴퓨터가 화면 출력 서비스를 제공하므로 X Server(X 서버)가 된다.

SSH for Server Configuration and Remote Access (서버 설정과 원격 접속 SSH)

서버(Server)를 관리할 때 가장 중요한 기능 중 하나는 원격 접속(Remote Access)이다. 서버는 항상 사용자의 눈앞에 있는 컴퓨터가 아닐 수 있고, 데이터센터(Data Center), 다른 사무실, 또는 물리적으로 멀리 떨어진 장소에 있을 수 있다. 이런 서버를 직접 모니터(Monitor), 키보드(Keyboard), 마우스(Mouse)에 연결해서 조작하는 것은 매우 불편하기 때문에, 네트워크(Network)를 통해 원격으로 접속하는 방법이 필요하다.

과거에는 원격 접속을 위해 텔넷(Telnet)이라는 프로그램이 많이 사용되었다. 텔넷(Telnet)은 멀리 있는 컴퓨터에 접속해서 마치 그 컴퓨터 앞에서 명령어를 입력하는 것처럼 사용할 수 있게 해주는 원격 접속 프로그램(Remote Login Program)이었다. 예전에는 서버와 단말기(Terminal)를 물리적인 전선으로 연결해서 입력과 출력을 주고받는 방식이었기 때문에, 서버에서 멀리 떨어진 장소에서는 사용하기 어려웠다. 하지만 텔넷을 사용하면 집이나 다른 층의 사무실에서도 네트워크를 통해 서버에 접속할 수 있었다.

그러나 텔넷(Telnet)에는 큰 보안 문제(Security Problem)가 있었다. 사용자가 입력하는 아이디, 비밀번호, 명령어 같은 정보가 암호화(Encryption)되지 않은 상태로 전송되었기 때문이다. 즉 네트워크 중간에서 데이터를 볼 수 있는 사람이 있다면, 사용자가 입력한 내용을 그대로 확인할 수 있었다. 서버는 보안이 매우 중요한 시스템이기 때문에 이러한 방식은 위험하다. 이런 이유로 텔넷은 현재 거의 사용되지 않고, SSH(Secure Shell)로 대체되었다.

SSH and Secure Remote Login (SSH와 안전한 원격 접속)

SSH(Secure Shell)는 서버에 안전하게 원격 접속하기 위한 대표적인 프로그램이다. SSH는 텔넷처럼 원격 서버(Remote Server)에 접속하여 명령어(Command)를 입력하고 결과를 확인할 수 있게 해주지만, 중요한 차이점은 통신 내용을 암호화(Encryption)한다는 점이다. 따라서 사용자가 입력하는 비밀번호(Password), 명령어(Command), 서버에서 돌아오는 결과(Output)가 네트워크 중간에서 쉽게 노출되지 않는다.

서버 관리를 할 때 SSH는 매우 기본적인 도구이다. 리눅스 서버(Linux Server)는 보통 GUI(Graphical User Interface)보다 CLI(Command Line Interface)를 중심으로 관리되기 때문에, SSH를 통해 원격으로 접속한 뒤 터미널(Terminal)에서 명령어를 입력하여 서버를 설정하고 관리한다.

SSH Service and Restart (SSH 서비스와 재시작)

리눅스에서 SSH는 하나의 서비스(Service) 형태로 동작한다. 즉 백그라운드(Background)에서 계속 실행되면서 외부에서 들어오는 SSH 접속 요청을 기다린다. 사용자가 SSH 서버 프로그램을 설치하면 기본적인 접속 기능은 사용할 수 있지만, 설정 파일(Configuration File)을 수정한 경우에는 변경 사항이 바로 적용되지 않을 수 있다.

이럴 때는 SSH 서비스를 다시 시작(Restart)해야 한다. 강의에서 언급된 명령어는 다음과 같다.

sudo systemctl restart ssh.service

여기서 sudo는 관리자 권한(Superuser Privilege)으로 명령어를 실행한다는 의미이고, systemctl은 리눅스에서 서비스(Service)를 관리하는 명령어이다. restart는 서비스를 다시 시작하라는 뜻이며, ssh.service는 SSH 서비스(Service)를 의미한다. 즉 이 명령어는 SSH 서비스를 다시 시작해서 변경된 설정이 적용되도록 하는 명령어이다.

SSH Port and Configuration File (SSH 포트와 설정 파일)

SSH는 기본적으로 22번 포트(Port 22)를 사용한다. 포트(Port)는 네트워크에서 특정 서비스(Service)를 구분하기 위한 번호라고 이해할 수 있다. 예를 들어 웹페이지 접속에 사용되는 HTTP(HyperText Transfer Protocol)는 일반적으로 80번 포트(Port 80)를 사용하고, SSH는 보통 22번 포트를 사용한다.

하지만 22번 포트는 SSH의 기본 포트(Default Port)로 널리 알려져 있기 때문에, 외부 공격자가 SSH 접속을 시도할 때 가장 먼저 확인하는 포트가 될 수 있다. 그래서 보안 설정의 한 방법으로 SSH 포트를 다른 번호로 변경하기도 한다. 예를 들어 22번 대신 90번, 190번처럼 다른 포트 번호를 사용할 수 있다.

SSH 포트를 변경하려면 다음 설정 파일(Configuration File)을 수정한다.

/etc/ssh/sshd_config

이 파일은 SSH 서버 데몬(SSH Daemon), 즉 sshd의 설정 파일이다. 여기에서 Port에 해당하는 줄을 찾아 원하는 숫자로 변경하면 SSH 접속 포트를 바꿀 수 있다. 설정 파일을 수정한 뒤에는 앞에서 본 것처럼 SSH 서비스를 재시작해야 변경 사항이 적용된다.

sudo systemctl restart ssh.service

단, 포트를 변경한 후에는 접속할 때도 새 포트 번호를 지정해야 한다. 예를 들어 포트를 190번으로 바꾸었다면 다음과 같은 방식으로 접속해야 한다.

ssh -p 190 사용자이름@서버주소

여기서 -p 옵션은 접속할 포트 번호(Port Number)를 지정하는 옵션이다.

Telnet vs SSH (텔넷과 SSH의 차이)

텔넷(Telnet)과 SSH(Secure Shell)는 모두 원격 접속(Remote Access)을 위한 도구라는 공통점이 있다. 하지만 가장 큰 차이는 보안(Security)이다. 텔넷은 데이터를 암호화하지 않고 전송하기 때문에 중간에서 통신 내용을 가로채면 사용자의 입력 정보를 볼 수 있다. 반면 SSH는 통신 내용을 암호화하여 전송하므로 훨씬 안전하다.

따라서 현대 서버 환경에서는 텔넷을 거의 사용하지 않고 SSH를 사용한다. 특히 서버에는 관리자 계정, 시스템 설정, 서비스 운영과 관련된 중요한 정보가 많기 때문에, 원격 접속 도구는 반드시 보안을 고려해야 한다.

Additional Notes (추가 설명)

Port(포트)는 네트워크에서 특정 프로그램이나 서비스를 구분하는 번호이다. 같은 서버 안에서도 웹 서버(Web Server), SSH 서버(SSH Server), 데이터베이스 서버(Database Server) 등이 동시에 실행될 수 있는데, 각각 다른 포트를 사용하여 구분된다.

SSH 기본 포트(Default SSH Port)는 22번이다. 하지만 보안상의 이유로 포트를 바꾸는 경우도 있다. 다만 포트를 바꾸는 것만으로 완전한 보안이 되는 것은 아니다. 이것은 공격 시도를 줄이는 보조적인 방법일 뿐이며, 강한 비밀번호(Strong Password), 공개키 인증(Public Key Authentication), 방화벽(Firewall) 설정 등이 함께 필요하다.

sshd_config에서 sshd는 SSH Daemon(SSH 데몬)을 의미한다. 데몬(Daemon)은 백그라운드에서 계속 실행되며 특정 서비스를 제공하는 프로그램이다. SSH 데몬은 외부에서 들어오는 SSH 접속 요청을 기다리다가, 사용자가 접속하면 인증(Authentication)을 처리하고 터미널 환경을 제공한다.

systemctl은 리눅스에서 서비스(Service)를 관리하는 대표적인 명령어이다. 예를 들어 서비스를 시작(Start), 중지(Stop), 재시작(Restart), 상태 확인(Status)할 때 사용할 수 있다.

sudo systemctl status ssh.service

위 명령어를 사용하면 현재 SSH 서비스가 정상적으로 실행 중인지 확인할 수 있다.

SSH Key-Based Login (SSH 키 기반 로그인)

SSH(Secure Shell)를 사용해 원격 서버(Remote Server)에 접속할 때 보통은 다음과 같은 형태의 명령어를 사용한다.

ssh username@server_address

여기서 username은 서버에 존재하는 사용자 계정(User Account)이고, server_address는 도메인 이름(Domain Name)이나 IP 주소(IP Address)가 될 수 있다. 이렇게 접속을 시도하면 비밀번호(Password)를 입력하라는 화면이 나타나고, 올바른 비밀번호를 입력하면 원격 서버에 로그인할 수 있다.

하지만 이 방식은 서버에 접속할 때마다 매번 비밀번호를 입력해야 한다는 불편함이 있다. 서버를 자주 관리하거나, 여러 서버에 반복적으로 접속해야 하는 환경에서는 매번 비밀번호를 입력하는 방식이 비효율적일 수 있다. 이런 문제를 해결하기 위해 사용하는 방법이 SSH Key-Based Login(SSH 키 기반 로그인)이다.

Public Key and Private Key (공개키와 개인키)

SSH 키 기반 로그인(SSH Key-Based Login)에서는 공개키(Public Key)와 개인키(Private Key)라는 두 개의 키(Key)를 사용한다. 이 두 키는 서로 짝을 이루는 관계이다.

개인키(Private Key)는 사용자 본인만 가지고 있어야 하는 중요한 키이다. 말 그대로 개인적으로 보관해야 하는 키이며, 다른 사람에게 노출되면 안 된다. 개인키는 사용자가 “정말 이 키의 주인인지”를 증명하는 데 사용된다.

반면 공개키(Public Key)는 서버에 등록해 둘 수 있는 키이다. 이름 그대로 공개될 수 있는 키이지만, 그렇다고 해서 아무 곳에나 무분별하게 배포해도 된다는 뜻은 아니다. 공개키가 서버의 특정 계정에 등록되면, 그 공개키와 짝이 되는 개인키를 가진 사용자는 비밀번호 없이 해당 계정으로 접속할 수 있기 때문이다.

즉 SSH 키 기반 로그인에서는 클라이언트(Client) 쪽에는 개인키(Private Key)가 있고, 서버(Server) 쪽에는 공개키(Public Key)가 저장된다. 사용자가 SSH로 접속을 시도하면 서버는 등록된 공개키와 사용자의 개인키가 서로 짝이 맞는지 검증한다. 검증에 성공하면 비밀번호를 입력하지 않아도 로그인이 가능해진다.

Creating SSH Keys with ssh-keygen (ssh-keygen으로 SSH 키 생성하기)

SSH 키를 만들 때는 ssh-keygen 명령어를 사용한다. 강의 자료에서는 다음과 같은 형식이 제시되었다.

ssh-keygen -t 알고리즘

예를 들어 RSA 알고리즘(RSA Algorithm)을 사용하고, 키 길이를 4096비트(Bit)로 지정하려면 다음과 같이 입력할 수 있다.

ssh-keygen -t rsa -b 4096

여기서 -t 옵션은 사용할 암호화 알고리즘(Algorithm)을 지정하는 옵션이고, -b 옵션은 키의 길이(Key Length)를 지정하는 옵션이다. 알고리즘에는 RSA, Ed25519 등 여러 종류가 있으며, 어떤 암호화 방식을 사용할지 선택할 수 있다.

명령어를 실행하면 사용자의 홈 디렉토리(Home Directory) 아래에 있는 .ssh 디렉토리(Directory)에 키 파일이 생성된다. 예를 들어 RSA 알고리즘을 사용하면 보통 다음과 같은 파일이 만들어진다.

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

id_rsa는 개인키(Private Key)이고, id_rsa.pub는 공개키(Public Key)이다. 파일 이름 끝에 .pub가 붙어 있으면 공개키라고 이해하면 된다.

Copying the Public Key to the Server (공개키를 서버에 복사하기)

키를 생성한 뒤에는 공개키(Public Key)를 로그인하려는 서버 계정에 복사해야 한다. 이때 사용하는 대표적인 명령어가 ssh-copy-id이다.

ssh-copy-id username@server_address

예를 들어 서버의 계정 이름이 koreacu이고 서버 주소가 192.168.0.10이라면 다음과 같이 사용할 수 있다.

ssh-copy-id koreacu@192.168.0.10

이 명령어를 실행하면 내 컴퓨터에 있는 공개키가 원격 서버의 해당 계정으로 복사된다. 그리고 서버의 홈 디렉토리 아래 .ssh/authorized_keys 파일에 공개키 내용이 저장된다.

~/.ssh/authorized_keys

authorized_keys 파일은 “이 계정으로 접속을 허용할 공개키 목록”이라고 이해하면 된다. 이 파일 안에 등록된 공개키와 짝이 맞는 개인키를 가진 사용자는 해당 계정으로 SSH 접속을 할 수 있다.

만약 ssh-copy-id 명령어를 사용할 수 없는 상황이라면, 공개키 파일의 내용을 직접 복사해서 서버의 .ssh/authorized_keys 파일에 붙여 넣을 수도 있다. 즉 공개키 자체는 텍스트 형태의 긴 문자열이므로, 이 내용을 서버의 해당 파일에 저장하면 된다.

File Permissions for authorized_keys (authorized_keys 파일 권한 설정)

SSH 키 기반 로그인에서 파일 권한(File Permission)은 매우 중요하다. 특히 .ssh/authorized_keys 파일은 아무나 수정할 수 있으면 안 된다. 만약 다른 사용자나 그룹(Group, Others)이 이 파일에 마음대로 쓰기(Write)를 할 수 있다면, 누군가 자신의 공개키를 추가해서 서버에 접속할 수 있는 위험이 생긴다.

그래서 강의 자료에서는 다음 명령어가 제시되었다.

chmod go-w .ssh/authorized_keys

여기서 chmod는 파일 권한을 변경하는 명령어이고, go-w는 group과 others에서 write 권한을 제거하라는 의미이다. 조금 더 풀어서 보면 다음과 같다.

g는 group을 의미한다. o는 others를 의미한다. -w는 write permission, 즉 쓰기 권한을 제거한다는 의미이다.

따라서 이 명령어는 .ssh/authorized_keys 파일에 대해 그룹 사용자와 다른 사용자들이 쓰기 권한을 갖지 못하도록 설정하는 명령어이다. 이렇게 해야 다른 사람이 마음대로 공개키를 추가하는 일을 막을 수 있다.

Why SSH Keys Are Useful (SSH 키 기반 로그인이 유용한 이유)

SSH 키 기반 로그인(SSH Key-Based Login)을 사용하면 매번 비밀번호를 입력하지 않아도 서버에 접속할 수 있다. 특히 서버나 클러스터(Cluster)를 관리할 때 매우 편리하다. 여러 대의 서버에 반복적으로 접속해야 하거나, 특정 계정으로 자동 접속해야 하는 경우 SSH 키 방식이 자주 사용된다.

예를 들어 클라우드(Cloud) 환경에서 서버 인스턴스(Instance)를 만들거나, 규모가 큰 클러스터링 프로그램(Clustering Program)을 설치할 때 SSH 키를 이용한 접속 설정을 요구하는 경우가 많다. 이는 서버 간 접속이나 자동화된 관리 작업에서 비밀번호 입력 방식보다 훨씬 효율적이기 때문이다.

또한 SSH 키 방식은 비밀번호 기반 로그인(Password-Based Login)보다 보안적으로 더 강하게 설정할 수 있다. 개인키(Private Key)를 안전하게 관리하고, 필요하다면 개인키에 암호(Passphrase)를 추가하면 더 안전하게 사용할 수 있다.

Security Considerations for SSH Keys (SSH 키 사용 시 보안 주의사항)

SSH 키를 사용할 때 가장 중요한 것은 개인키(Private Key)를 안전하게 보관하는 것이다. 개인키는 사용자의 신분을 증명하는 핵심 정보이기 때문에 절대 다른 사람에게 공유하면 안 된다. 개인키가 유출되면, 그 키와 짝이 되는 공개키가 등록된 서버에 다른 사람이 접속할 수 있는 위험이 생긴다.

공개키(Public Key)는 개인키보다 덜 민감하지만, 그래도 관리가 필요하다. 공개키가 서버의 authorized_keys 파일에 등록되면 그 키와 짝이 맞는 개인키를 가진 사용자는 접속 권한을 갖게 된다. 따라서 서버 관리자는 authorized_keys 파일에 어떤 공개키가 등록되어 있는지 확인하고, 더 이상 필요 없는 키는 제거해야 한다.

암호화 알고리즘(Encryption Algorithm)과 키 길이(Key Length)도 중요하다. 과거에는 128비트(Bit) 암호화도 매우 안전하다고 여겨졌지만, 컴퓨터 성능이 발전하면서 더 강한 암호화 방식이 필요해졌다. 강의에서 언급된 것처럼 양자컴퓨터(Quantum Computer)가 발전하면 기존 암호화 방식 중 일부는 더 쉽게 공격받을 가능성도 있다. 따라서 실제 환경에서는 현재 권장되는 알고리즘과 충분한 키 길이를 사용하는 것이 중요하다.

전체적으로 보면 SSH 키 기반 로그인은 “클라이언트에는 개인키를 보관하고, 서버에는 공개키를 등록해 두는 방식”이다. 그리고 접속할 때 두 키가 서로 짝이 맞는지 검증하여, 비밀번호 없이 안전하게 로그인할 수 있도록 해준다.

Additional Notes (추가 설명)

ssh-keygen -t rsa -b 4096은 RSA 방식으로 4096비트 키를 만드는 예시이다. 최근에는 다음과 같이 Ed25519 알고리즘(Ed25519 Algorithm)을 사용하는 경우도 많다.

ssh-keygen -t ed25519

개인키(Private Key)는 보통 ~/.ssh/id_rsa 또는 ~/.ssh/id_ed25519처럼 .pub가 붙지 않은 파일이다. 이 파일은 절대 공유하면 안 된다.

공개키(Public Key)는 보통 ~/.ssh/id_rsa.pub 또는 ~/.ssh/id_ed25519.pub처럼 .pub가 붙은 파일이다. 이 파일의 내용을 서버의 ~/.ssh/authorized_keys에 등록한다.

SSH 키 기반 로그인을 설정한 뒤에는 다음처럼 접속할 수 있다.

ssh username@server_address

설정이 제대로 되어 있다면 비밀번호 입력 없이 바로 로그인된다. 단, 개인키에 Passphrase(개인키 암호)를 설정했다면 접속 시 해당 암호를 입력해야 할 수 있다.

SSHFS and Remote File Access (SSHFS와 원격 파일 접근)

SSHFS(SSH File System)는 SSH(Secure Shell) 프로토콜을 사용해서 원격 서버(Remote Server)에 있는 파일이나 디렉터리(Directory)를 내 로컬 컴퓨터(Local Computer)에서 직접 접근할 수 있게 해주는 방식이다. 일반적인 SSH 접속은 터미널(Terminal)을 통해 명령어를 입력하고 결과를 확인하는 방식이지만, SSHFS를 사용하면 원격 서버의 파일을 내 컴퓨터의 파일 탐색기(File Explorer)나 Finder처럼 열어볼 수 있다.

예를 들어 실습 환경에서 가상 머신(Virtual Machine)에 우분투 서버(Ubuntu Server)를 설치했다고 하자. 보통은 윈도우(Windows), 맥(Mac), 리눅스(Linux) 같은 로컬 컴퓨터에서 SSH로 접속한 뒤 터미널에서 명령어를 입력하여 파일을 확인하거나 설정 파일(Configuration File)을 수정한다. 이 방식은 서버 관리에는 적합하지만, 이미지 파일(Image File)이나 여러 문서 파일을 직접 확인해야 할 때는 불편할 수 있다.

기존 방식에서는 원격 서버에 있는 이미지 파일을 보고 싶다면 SCP(Secure Copy)를 사용해서 파일을 로컬 컴퓨터로 복사한 뒤, 이미지 뷰어(Image Viewer)로 열어보는 과정을 거쳐야 한다. 하지만 SSHFS를 사용하면 원격 서버의 디렉터리를 내 컴퓨터의 특정 폴더에 연결해 둘 수 있다. 그러면 파일 탐색기에서 원격 파일 목록이 보이고, 파일을 더블클릭하면 로컬 파일처럼 바로 열 수 있다.

Installing SSHFS (SSHFS 설치)

SSHFS를 사용하려면 먼저 클라이언트(Client) 쪽에 SSHFS 프로그램을 설치해야 한다. 우분투(Ubuntu)에서는 다음 명령어로 설치할 수 있다.

sudo apt install sshfs

여기서 sudo는 관리자 권한(Superuser Privilege)으로 명령어를 실행한다는 뜻이고, apt는 우분투에서 패키지(Package)를 설치하거나 관리할 때 사용하는 패키지 관리자(Package Manager)이다. sshfs는 SSH를 이용해 원격 파일 시스템(Remote File System)을 마운트(Mount)할 수 있게 해주는 프로그램이다.

Mounting Remote Files with SSHFS (SSHFS로 원격 파일 마운트하기)

SSHFS를 사용하면 원격 서버의 특정 디렉터리를 내 로컬 컴퓨터의 디렉터리에 연결할 수 있다. 강의 자료에서는 다음과 같은 형태의 명령어가 제시되었다.

sshfs -o idmap=user id@remote_host:/remote/path ~/remote_files

이 명령어는 원격 서버(Remote Host)에 있는 /remote/path 디렉터리를 내 컴퓨터의 ~/remote_files 디렉터리에 연결하는 명령이다. 연결이 완료되면 ~/remote_files 폴더 안에서 원격 서버의 파일들을 로컬 파일처럼 볼 수 있다.

여기서 id는 원격 서버에 로그인할 사용자 계정(User Account)이고, remote_host는 원격 서버의 IP 주소(IP Address)나 도메인 이름(Domain Name)이다. /remote/path는 원격 서버에서 접근하려는 경로(Path)이고, ~/remote_files는 내 컴퓨터에서 원격 파일을 보여줄 마운트 지점(Mount Point)이다.

예를 들어 원격 서버의 사용자 이름이 koreacu, 서버 주소가 192.168.0.10, 원격 디렉터리가 /home/koreacu/project, 로컬 연결 폴더가 ~/remote_files라면 다음과 같이 사용할 수 있다.

sshfs -o idmap=user koreacu@192.168.0.10:/home/koreacu/project ~/remote_files

이후 내 컴퓨터에서 ~/remote_files 폴더를 열면 원격 서버의 /home/koreacu/project 안에 있는 파일들이 보이게 된다.

Unmounting SSHFS (SSHFS 연결 해제하기)

SSHFS로 연결한 원격 디렉터리를 더 이상 사용하지 않을 때는 마운트 해제(Unmount)를 해야 한다. 강의 자료에서는 다음 명령어가 제시되었다.

fusermount -u ~/remote_files

여기서 fusermount는 FUSE(File System in Userspace) 기반 파일 시스템을 마운트하거나 해제할 때 사용하는 명령어이고, -u 옵션은 unmount, 즉 연결 해제를 의미한다. 이 명령어를 실행하면 ~/remote_files에 연결되어 있던 원격 디렉터리 연결이 해제된다.

SSHFS vs NFS (SSHFS와 NFS의 차이)

강의에서 NFS(Network File System)도 함께 언급되었다. NFS는 네트워크를 통해 원격 디렉터리를 공유하는 대표적인 방식이다. 하지만 SSHFS와 NFS는 동작 방식과 사용 목적에 차이가 있다.

NFS(Network File System)는 보통 시스템 차원(System Level)에서 디렉터리를 공유한다. 서버 관리자가 특정 디렉터리를 export하고, 다른 컴퓨터들이 그 디렉터리를 네트워크를 통해 마운트해서 사용하는 방식이다. 여러 사용자나 여러 시스템이 공통으로 접근해야 하는 공유 디렉터리를 만들 때 자주 사용된다.

반면 SSHFS(SSH File System)는 SSH 로그인 정보를 기반으로 사용자 대 사용자(User-to-User), 계정 대 계정(Account-to-Account) 형태로 연결된다. 즉 내가 SSH로 로그인할 수 있는 계정의 권한 범위 안에서 원격 파일에 접근하는 방식이다. 그래서 별도의 시스템 차원 공유 설정 없이도, SSH 접속 권한만 있으면 비교적 쉽게 원격 파일을 로컬처럼 사용할 수 있다.

이 차이를 간단히 정리하면, NFS는 서버가 디렉터리를 시스템 차원에서 공유하는 방식이고, SSHFS는 사용자가 SSH 계정을 통해 자신의 권한으로 원격 디렉터리에 접근하는 방식이다.

Why SSHFS Is Convenient (SSHFS가 편리한 이유)

SSHFS의 가장 큰 장점은 원격 파일을 로컬 파일처럼 다룰 수 있다는 점이다. SSH만 사용할 경우에는 터미널에서 ls, cd, cat, nano, vim 같은 명령어를 사용해 파일을 확인하고 수정해야 한다. 물론 서버 관리에는 이 방식이 중요하지만, 파일이 많거나 이미지, 문서, 코드 파일을 자주 열어봐야 한다면 불편할 수 있다.

예를 들어 원격 서버의 특정 디렉터리 안에 이미지 파일이 있다고 하자. SSH만 사용한다면 파일 이름을 확인하고, 필요하면 SCP로 파일을 복사한 뒤 로컬에서 열어봐야 한다. 하지만 SSHFS를 사용하면 해당 디렉터리가 내 컴퓨터의 폴더처럼 보이기 때문에 파일을 더블클릭해서 바로 이미지 뷰어로 확인할 수 있다.

이미지 파일뿐만 아니라 텍스트 파일(Text File), 설정 파일(Configuration File), 소스 코드(Source Code), 문서 파일(Document File) 등도 로컬 프로그램으로 바로 열어볼 수 있다. 따라서 SSHFS는 서버의 파일을 더 편리하게 확인하고 수정하기 위한 도구라고 볼 수 있다.

다만 SSHFS는 편리성을 위한 도구이지, 모든 서버 작업을 대체하는 것은 아니다. 서버 설정 변경, 프로그램 설치, 서비스 재시작 같은 작업은 여전히 SSH 터미널을 통해 명령어로 수행하는 경우가 많다. SSHFS는 특히 파일을 확인하거나 편집하는 작업에서 편리함을 제공한다.

Additional Notes (추가 설명)

Mount(마운트)는 어떤 저장장치나 원격 파일 시스템을 내 컴퓨터의 특정 디렉터리에 연결해서 사용할 수 있게 만드는 것을 의미한다. SSHFS에서는 원격 서버의 디렉터리를 내 컴퓨터의 폴더처럼 연결한다.

SCP(Secure Copy)는 SSH를 이용해 원격 서버와 로컬 컴퓨터 사이에서 파일을 복사하는 명령어이다. 파일을 한 번 복사해서 가져오는 방식이라면 SCP가 적합하고, 원격 디렉터리를 계속 로컬처럼 열어보고 싶다면 SSHFS가 더 편리하다.

FUSE(File System in Userspace)는 일반 사용자가 커널(Kernel) 내부를 직접 수정하지 않고도 파일 시스템(File System)을 사용할 수 있게 해주는 구조이다. SSHFS는 FUSE를 기반으로 동작한다.

SSHFS를 사용하려면 원격 서버에 SSH 접속이 가능해야 한다. 즉 SSH 서버(SSH Server)가 실행 중이어야 하고, 사용자가 해당 계정으로 로그인할 권한을 가지고 있어야 한다.

SSHFS를 사용할 때 연결할 로컬 디렉터리, 예를 들어 ~/remote_files는 미리 만들어 두는 것이 좋다.

mkdir ~/remote_files

그 다음 sshfs 명령어를 실행하면 원격 디렉터리를 이 폴더에 연결할 수 있다.

LAMP Stack and Apache Web Server

LAMP Stack(LAMP 스택)은 예전부터 웹 서비스(Web Service)를 구축할 때 많이 사용되던 대표적인 서버 소프트웨어 구성이다. LAMP는 Linux, Apache, MySQL, PHP의 앞 글자를 모은 이름이다. 여기서 Linux(리눅스)는 운영체제(Operating System), Apache(아파치)는 웹 서버(Web Server), MySQL은 데이터베이스(Database), PHP는 웹 페이지를 동적으로 처리하기 위한 서버 사이드 언어(Server-side Language)를 의미한다.

웹 서비스를 제공하려면 단순히 서버 하드웨어(Server Hardware)만 있는 것으로는 부족하다. 서버 하드웨어 위에 운영체제(Operating System)를 설치하고, 그 위에 웹 요청을 처리할 서버 프로그램(Server Program)을 설치해야 한다. LAMP는 이런 웹 서비스 환경을 구성하는 대표적인 조합이라고 볼 수 있다.

Apache Web Server (아파치 웹 서버)

Apache(Apache HTTP Server)는 클라이언트(Client), 즉 사용자의 웹 브라우저(Web Browser)로부터 들어오는 요청(Request)을 받아 웹 페이지(Web Page)를 응답(Response)으로 돌려주는 웹 서버 프로그램(Web Server Program)이다.

예를 들어 사용자가 브라우저 주소창에 서버의 IP 주소(IP Address)를 입력하면, 브라우저는 해당 서버에 웹 페이지를 요청한다. 이때 서버에 Apache가 설치되어 있고 정상적으로 실행 중이라면, Apache가 요청을 받아 기본 페이지(Default Page)를 사용자에게 보여준다.

우분투(Ubuntu)에서는 Apache를 다음과 같이 설치할 수 있다.

sudo apt install apache2

여기서 apache2는 우분투에서 Apache 웹 서버를 설치할 때 사용하는 패키지(Package) 이름이다. 설치가 완료된 뒤 Apache가 정상적으로 실행되고 있다면, 웹 브라우저에서 해당 컴퓨터의 IP 주소로 접속했을 때 Apache 기본 페이지가 나타난다. 이 기본 페이지가 보인다는 것은 웹 서버(Web Server)가 정상적으로 설치되고 실행되고 있다는 의미이다.

Apache Service Restart (아파치 서비스 재시작)

Apache도 SSH처럼 리눅스에서 서비스(Service) 형태로 동작한다. 즉 백그라운드(Background)에서 계속 실행되면서 외부에서 들어오는 웹 요청(Web Request)을 기다린다.

Apache 설정 파일(Configuration File)을 수정한 경우에는 변경 사항을 적용하기 위해 서비스를 다시 시작(Restart)해야 한다. 강의에서 언급된 명령어는 다음과 같다.

sudo systemctl restart apache2.service

이 명령어는 apache2.service를 재시작하여 변경된 설정이 적용되도록 한다. 만약 설정 파일을 수정했는데 웹 페이지가 제대로 보이지 않는다면, 설정값을 잘못 입력했거나 문법 오류(Configuration Error)가 있을 가능성이 있다. 이 경우에는 설정 파일을 다시 확인하고 수정한 뒤 Apache를 다시 재시작해야 한다.

Apache Configuration Files (아파치 설정 파일)

Apache의 주요 설정 파일(Configuration Files)은 보통 /etc/apache2 디렉터리 아래에 위치한다.

/etc/apache2

이 디렉터리 안에는 Apache 동작을 제어하는 여러 설정 파일들이 있다. 강의에서 언급된 대표적인 파일은 다음과 같다.

/etc/apache2/apache2.conf
/etc/apache2/ports.conf
/etc/apache2/magic

apache2.conf는 Apache의 전체적인 기본 설정을 담당하는 주요 설정 파일이다. Apache가 어떻게 동작할지, 어떤 설정 파일들을 포함할지 등의 기본적인 내용이 들어 있다.

ports.conf는 Apache가 어떤 포트(Port)에서 요청을 받을지 설정하는 파일이다. 웹 서버는 보통 HTTP(HyperText Transfer Protocol)의 기본 포트인 80번 포트(Port 80)를 사용한다. 사용자가 브라우저에서 서버 IP 주소로 접속했을 때 Apache가 응답하려면, Apache가 해당 포트에서 요청을 기다리고 있어야 한다.

magic 파일은 파일의 형식(File Type)을 판단하는 데 사용될 수 있는 설정과 관련이 있다. 강의에서는 세부적인 내용보다는 Apache 설정 파일들이 /etc/apache2 아래에 모여 있다는 점을 중심으로 이해하면 된다.

Default Page and Testing Apache

Apache를 처음 설치한 뒤 웹 브라우저에서 Apache가 설치된 컴퓨터의 IP 주소로 접속하면 기본 페이지(Default Page)가 나타난다. 이 페이지는 Apache가 정상적으로 설치되었고, 웹 서버가 클라이언트의 요청을 받을 준비가 되어 있다는 것을 확인하는 용도이다.

예를 들어 가상 머신(Virtual Machine)에 Ubuntu Server를 설치하고 그 안에 Apache를 설치했다면, 같은 네트워크에서 해당 가상 머신의 IP 주소로 접속하여 Apache 기본 페이지가 보이는지 확인할 수 있다. 기본 페이지가 보인다면 웹 서버 설치는 성공한 것이다.

만약 설정을 변경한 뒤 페이지가 보이지 않는다면 다음과 같은 가능성을 생각해볼 수 있다. Apache 서비스가 실행 중이 아닐 수 있고, 설정 파일에 오류가 있을 수 있으며, 포트 설정이 잘못되었거나 네트워크 연결 문제가 있을 수도 있다. 이때는 설정을 다시 확인하고 Apache 서비스를 재시작해야 한다.

sudo systemctl restart apache2.service

결국 Apache 실습의 기본 흐름은 Apache 설치, IP 주소로 접속하여 기본 페이지 확인, 설정 파일 수정, 서비스 재시작, 다시 접속해서 결과 확인의 순서로 이해할 수 있다.

Role of LAMP in Web Services (웹 서비스에서 LAMP의 역할)

LAMP Stack(LAMP 스택)은 웹 서비스가 동작하기 위해 필요한 기본 구성 요소를 하나의 조합으로 묶어 이해하는 방식이다. Linux는 서버의 운영체제 역할을 하고, Apache는 웹 브라우저의 요청을 받아 웹 페이지를 제공한다. MySQL은 회원 정보, 게시글, 상품 정보 같은 데이터를 저장하는 데이터베이스 역할을 한다. PHP는 사용자의 요청에 따라 동적인 웹 페이지(Dynamic Web Page)를 생성하는 역할을 한다.

예를 들어 사용자가 웹사이트에 접속하면 Apache가 요청을 받는다. 만약 단순한 HTML 파일(HTML File)이라면 Apache가 바로 파일을 응답으로 보낼 수 있다. 하지만 로그인, 게시판, 검색처럼 데이터가 필요한 기능이라면 PHP가 요청을 처리하고, 필요한 데이터를 MySQL에서 가져온 뒤 결과 페이지를 만들어 Apache를 통해 사용자에게 전달한다.

따라서 LAMP는 웹 서버(Web Server), 데이터베이스(Database), 서버 사이드 프로그래밍(Server-side Programming)이 함께 동작하는 전형적인 웹 서비스 구조라고 볼 수 있다.

Additional Notes (추가 설명)

Apache(Apache HTTP Server)는 웹 서버(Web Server) 프로그램이다. 사용자의 브라우저가 보낸 HTTP 요청(HTTP Request)을 받아 HTML, 이미지, CSS, JavaScript 같은 웹 리소스(Web Resource)를 응답으로 보내는 역할을 한다.

LAMP Stack(LAMP 스택)의 구성은 다음과 같이 정리할 수 있다.

Linux  : 운영체제(Operating System)
Apache : 웹 서버(Web Server)
MySQL  : 데이터베이스(Database)
PHP    : 서버 사이드 언어(Server-side Language)

Apache 설정을 수정한 뒤 바로 결과가 적용되지 않는 경우가 많기 때문에, 설정 변경 후에는 서비스를 재시작(Restart)해야 한다.

sudo systemctl restart apache2.service

Apache가 정상 실행 중인지 확인하려면 다음 명령어도 사용할 수 있다.

sudo systemctl status apache2.service

웹 브라우저에서 서버 IP 주소로 접속했을 때 Apache 기본 페이지(Default Page)가 보이면, Apache 웹 서버가 정상적으로 설치되고 실행 중이라고 이해하면 된다.

Apache Directory Structure and Enable System (Apache 디렉토리 구조와 활성화 방식)

Apache2(Apache HTTP Server)를 설치하면 설정 파일(Configuration File)들이 /etc/apache2/ 디렉토리 아래에 정리되어 있다. 이 디렉토리에는 conf-available, conf-enabled, mods-available, mods-enabled, sites-available, sites-enabled와 같은 하위 디렉토리들이 존재한다.

이 구조에서 핵심은 available과 enabled의 차이를 이해하는 것이다. available은 “사용 가능한 설정”이라는 의미이고, enabled는 “현재 실제로 활성화되어 적용 중인 설정”이라는 의미이다. 즉 어떤 설정 파일이 available 디렉토리에 있다고 해서 Apache에 바로 적용되는 것은 아니다. 그 설정을 실제로 사용하려면 enabled 상태로 만들어야 한다.

Apache Available and Enabled Directories

conf-available 디렉토리에는 Apache에서 사용할 수 있는 설정 파일(Configuration Files)들이 들어 있다. 하지만 이 파일들은 아직 적용된 상태가 아니라, 필요할 때 선택해서 활성화할 수 있는 후보라고 볼 수 있다.

반대로 conf-enabled 디렉토리에는 실제로 Apache에 적용되는 설정들이 들어 있다. 보통 conf-enabled 안의 파일들은 conf-available에 있는 파일을 직접 복사한 것이 아니라, 심볼릭 링크(Symbolic Link) 형태로 연결되어 있다. Apache는 재시작(Restart)될 때 enabled 디렉토리에 있는 설정들을 읽고 적용한다.

이와 같은 구조는 모듈(Module)과 사이트(Site) 설정에서도 동일하게 사용된다.

mods-available에는 사용 가능한 Apache 모듈(Module)과 관련 설정 파일들이 들어 있다.
mods-enabled에는 실제로 활성화된 모듈들이 들어 있다.
sites-available에는 사용 가능한 가상 호스트(Virtual Host) 설정 파일들이 들어 있다.
sites-enabled에는 실제로 활성화되어 Apache에 적용되는 사이트 설정들이 들어 있다.

Available vs Enabled (사용 가능 상태와 활성화 상태)

available과 enabled의 관계는 “설치되어 있지만 아직 사용하지 않는 상태”와 “실제로 사용 중인 상태”의 차이로 이해할 수 있다.

예를 들어 어떤 Apache 모듈(Module)이 mods-available에 존재한다면, 그 모듈은 시스템에 준비되어 있는 상태이다. 하지만 아직 Apache가 그 모듈을 사용하고 있는 것은 아니다. 사용자가 해당 모듈을 활성화하면 mods-enabled에 심볼릭 링크(Symbolic Link)가 만들어지고, Apache를 재시작한 뒤 실제로 적용된다.

사이트 설정(Site Configuration)도 마찬가지이다. sites-available에는 여러 개의 웹사이트 설정을 준비해 둘 수 있다. 그중 실제로 서비스할 사이트만 sites-enabled로 활성화하면 Apache가 해당 사이트 설정을 읽어 웹 서비스를 제공한다.

Apache Helper Commands (Apache 도구 명령어)

Apache에서는 사용자가 직접 파일을 복사하거나 링크를 만드는 대신, 전용 도구 명령어(Helper Commands)를 사용해 설정을 활성화하거나 비활성화할 수 있다. 강의 자료에 나온 대표적인 명령어는 다음과 같다.

a2enconf
a2disconf
a2enmod
a2dismod
a2ensite
a2dissite

a2enconf는 Apache 설정(Configuration)을 활성화(enable)할 때 사용한다.

a2disconf는 활성화된 설정을 비활성화(disable)할 때 사용한다.

a2enmod는 Apache 모듈(Module)을 활성화할 때 사용한다.

a2dismod는 활성화된 모듈을 비활성화할 때 사용한다.

a2ensite는 사이트 설정(Site Configuration)을 활성화할 때 사용한다.

a2dissite는 활성화된 사이트 설정을 비활성화할 때 사용한다.

예를 들어 특정 사이트 설정을 활성화하려면 다음과 같은 방식으로 사용할 수 있다.

sudo a2ensite 사이트설정파일이름

모듈을 활성화하려면 다음과 같이 사용할 수 있다.

sudo a2enmod 모듈이름

이 명령어들은 내부적으로 available 디렉토리에 있는 파일을 enabled 디렉토리로 연결해 주는 역할을 한다. 사용자가 직접 파일을 복사하는 것이 아니라, Apache가 정해둔 방식에 따라 설정을 활성화하는 것이다.

Applying Apache Settings (Apache 설정 적용)

Apache 설정을 available에서 enabled 상태로 바꾸었다고 해서 항상 즉시 적용되는 것은 아니다. Apache는 설정 파일을 읽고 동작하는 서비스(Service)이기 때문에, 설정을 변경한 뒤에는 보통 Apache를 다시 시작(Restart)해야 한다.

sudo systemctl restart apache2.service

Apache가 재시작되면 enabled 디렉토리에 연결된 설정 파일들을 읽고 실제 서비스에 반영한다. 따라서 설정 파일을 수정하거나, 모듈을 활성화하거나, 사이트 설정을 변경한 뒤에는 재시작을 통해 변경 사항을 적용해야 한다.

이 구조를 이해하면 Apache 설정 관리가 조금 더 명확해진다. /etc/apache2/ 아래에는 사용 가능한 설정들이 모여 있고, 실제로 적용되는 설정들은 enabled 디렉토리에 연결된다. 그리고 Apache가 다시 시작될 때 enabled된 설정들이 적용되어 웹 서버(Web Server)가 동작하게 된다.

Additional Notes (추가 설명)

심볼릭 링크(Symbolic Link)는 원본 파일을 직접 복사하지 않고, 다른 위치에서 그 파일을 가리키도록 만든 연결 파일이다. Apache의 enabled 디렉토리에는 보통 실제 설정 파일 복사본이 아니라, available 디렉토리에 있는 파일을 가리키는 심볼릭 링크가 들어간다.

available은 “설치되어 있고 선택 가능하지만 아직 적용되지 않은 상태”이고, enabled는 “현재 Apache가 읽어서 적용하는 상태”라고 기억하면 쉽다.

Apache 설정을 변경한 뒤 웹페이지가 제대로 보이지 않는다면 설정 파일의 문법 오류(Configuration Syntax Error), 잘못된 포트 설정(Port Configuration), 사이트 설정 오류(Site Configuration Error) 등을 의심할 수 있다. 이때는 설정을 다시 확인한 뒤 Apache를 재시작해야 한다.

실습에서는 직접 a2ensite, a2enmod 같은 명령어를 사용해 보면 available에서 enabled로 연결되는 구조를 더 쉽게 이해할 수 있다. 특히 나중에 여러 웹사이트를 한 서버에서 운영하거나, PHP 모듈(PHP Module), SSL 모듈(SSL Module) 등을 활성화할 때 이 구조가 자주 사용된다.

MySQL Server in LAMP (LAMP의 MySQL 서버)

MySQL(MySQL Server)은 LAMP(Linux, Apache, MySQL, PHP) 구성에서 데이터베이스(Database)를 담당하는 서버 프로그램이다. 웹 서비스에서 회원 정보, 게시글, 상품 정보 같은 데이터를 저장하고 관리할 때 사용된다.

MySQL은 Ubuntu에서 다음 명령어로 설치할 수 있다.

sudo apt install mysql-server

설치 후 MySQL 서비스를 재시작할 때는 두 가지 방식이 있다.

sudo service mysql restart
sudo systemctl restart mysql.service

service 명령어는 예전 방식이고, systemctl은 최근 Linux(Ubuntu)에서 주로 사용하는 방식이다. 둘 다 MySQL 서비스를 재시작하는 명령어이지만, 요즘은 보통 systemctl을 더 많이 사용한다. MySQL이 실행될 때 발생하는 메시지나 오류는 journalctl로 확인할 수 있다.

sudo journalctl -u mysql

여기서 journalctl은 서비스 로그(Service Log)를 확인하는 명령어이다. MySQL이 정상적으로 실행되지 않거나 문제가 생겼을 때 원인을 확인하는 데 사용한다.

MySQL의 주요 설정 파일은 /etc/mysql/ 아래에 있다. 특히 다음 파일에서 네트워크 접속 관련 설정을 변경할 수 있습니다.

/etc/mysql/mysql.conf.d/mysqld.cnf

이 파일 안의 bind-address 설정은 MySQL 서버가 어떤 IP 주소에서 접속을 받을지 결정하는 중요한 설정이다.

마지막으로 MySQL을 실제로 사용하려면 다음 명령어를 입력한다.

sudo mysql

사진에서는 “시작”이라고 되어 있지만, 여기서는 MySQL 프로그램을 실행해서 사용하는 의미에 가깝다.

Additional Notes (추가 설명)

mysql-server는 MySQL 데이터베이스 서버(Database Server)를 설치하는 패키지이다.

systemctl restart mysql.service는 MySQL 서버를 재시작해서 설정 변경을 적용할 때 사용한다.

journalctl -u mysql은 MySQL 서비스의 로그(Log)를 확인하는 명령어이다. 오류가 났을 때 가장 먼저 확인해볼 수 있다.

PHP Script in LAMP (LAMP에서 PHP 스크립트)

PHP(PHP Script)는 LAMP(Linux, Apache, MySQL, PHP) 구성에서 동적인 웹 페이지(Dynamic Web Page)를 처리하는 역할을 한다. PHP는 단독으로 사용하기보다는 웹 서버(Web Server)인 Apache와 DB 서버(Database Server)인 MySQL이 함께 설치되어 있어야 PHP가 웹 서비스 안에서 의미 있게 사용될 수 있다.

사진에 나온 설치 명령어는 다음과 같다.

sudo apt install php libapache2-mod-php php-cli php-cgi php-mysql

여기서 libapache2-mod-php는 Apache가 PHP 코드를 실행할 수 있게 해주는 모듈(Module)이고, php-mysql은 PHP가 MySQL과 연결할 수 있게 해주는 패키지이다. 즉 PHP는 단독 프로그램이라기보다 Apache와 MySQL 사이에서 웹 요청을 처리하고 데이터베이스와 연결해 주는 역할을 한다.

PHP 설정을 변경한 뒤에는 Apache를 재시작한다.

sudo systemctl restart apache2.service

이는 PHP가 Apache 웹 서버 안에서 동작하기 때문이다. PHP 설정을 바꿨는데 Apache를 재시작하지 않으면 변경 내용이 바로 적용되지 않을 수 있다.

주요 설정 파일은 다음과 같다.

/etc/php/8.3/cli/php.ini
/etc/php/8.3/apache2/php.ini

여기서 8.3은 PHP version(PHP 버전)이므로 사용자 환경에 따라 다를 수 있다. Ubuntu(우분투)를 기준으로 한 경로이기 때문에, 다른 Linux distribution(리눅스 배포판)에서는 설치 명령어나 설정 파일 위치가 달라질 수 있다.

Additional Notes (추가 설명)

php-cli는 터미널(Command Line)에서 PHP를 실행할 때 사용한다.

php-cgi는 웹 서버와 PHP가 CGI 방식으로 연동될 때 사용될 수 있다.

Linux kernel(리눅스 커널)의 기본은 같지만, Ubuntu, CentOS, Fedora 같은 distribution(배포판)에 따라 패키지 관리자, 명령어, 설정 파일 위치가 달라질 수 있으므로 실습 환경이 Ubuntu인지 항상 확인하는 것이 좋다.

Viewing Image Files in Linux (리눅스에서 그림 파일 보기)

리눅스 서버(Linux Server)는 보통 GUI(Graphical User Interface)가 없는 최소 환경으로 설치되기 때문에, 그림 파일(Image File)을 바로 창으로 열어보기 어렵다. 서버는 사용자의 화면 반응성보다 서비스 실행과 관리에 초점을 두기 때문에, Windows처럼 익숙한 화면 환경이 기본으로 제공되지 않는 경우가 많다.

그림 파일을 확인하는 방법은 여러 가지가 있다. 가장 기본적인 방법은 터미널(Terminal)에서 파일 목록을 확인하는 것이다. 하지만 이미지 내용을 직접 보려면 다른 방법이 필요하다.

첫 번째 방법은 Window Manager(윈도우 매니저)를 설치하는 것이다. Window Manager는 X Window System(X 윈도우 시스템)에서 창을 띄우고 관리하는 프로그램이다. 이것을 사용하면 원격 Linux 환경에서도 GUI처럼 그림 파일을 볼 수 있다. 다만 서버 환경에서는 꼭 필요한 경우가 아니면 잘 사용하지 않는다.

두 번째 방법은 sshFS(SSH File System)를 사용하는 것이다. 원격 서버의 디렉토리를 내 컴퓨터에 연결하면, 서버에 있는 이미지 파일을 내 컴퓨터의 파일 탐색기(File Explorer)에서 보는 것처럼 열 수 있다.

세 번째 방법은 Python SimpleHTTPServer를 사용하는 것이다. 서버에 Python이 설치되어 있다면 Apache(Apache Web Server)를 따로 설치하지 않아도 간단한 웹 서버(Web Server)를 실행할 수 있다.

python -m SimpleHTTPServer 포트번호

또는 Python 3에서는 보통 다음 명령어를 사용한다.

python3 -m http.server 포트번호

이렇게 실행하면 웹 브라우저(Web Browser)를 통해 해당 디렉토리의 파일 목록을 볼 수 있고, 이미지 파일도 클릭해서 확인할 수 있다.

Additional Notes (추가 설명)

Window Manager(윈도우 매니저)는 GUI 창을 띄우고 관리하는 프로그램이다.

sshFS는 원격 서버의 파일을 내 컴퓨터 폴더처럼 연결해서 보는 방식이다.

Python SimpleHTTPServer는 간단히 임시 웹 서버를 열어 파일을 확인할 때 유용하다.

핵심은 Linux 서버에서는 그림 파일을 바로 보는 환경이 기본이 아니기 때문에, Window Manager, sshFS, Python 웹 서버 같은 방법을 이용해 확인할 수 있다는 점이다.

Apache Home Directory (Apache 홈 디렉토리)

Apache(Apache Web Server)를 설치하면 웹 페이지 파일들이 저장되는 기본 홈 디렉토리(Home Directory)가 정해져 있다. Ubuntu 기준으로 Apache의 기본 웹 문서 디렉토리는 다음 위치이다.

/var/www/html

이 디렉토리 안에 있는 파일들이 웹 브라우저를 통해 사용자에게 보여진다. 예를 들어 기본 페이지는 보통 다음 파일이다.

/var/www/html/index.html

사용자가 새로 my.html 같은 파일을 만들면 다음과 같은 경로에 위치할 수 있다.

/var/www/html/my.html

그리고 웹 브라우저에서 서버의 IP 주소나 도메인으로 접속하면 Apache가 이 디렉토리 안의 파일을 찾아서 보여준다.

Apache Default Site Configuration (Apache 기본 사이트 설정)

사진에 나온 설정 파일은 Apache의 기본 사이트 설정 파일이다.

/etc/apache2/sites-enabled/000-default.conf

이 파일 안에는 Apache가 어떤 디렉토리를 웹 페이지의 기준 위치로 사용할지 설정되어 있다. 사진에서 중요한 부분은 다음 줄이다.

DocumentRoot /var/www/html

DocumentRoot는 웹 서버가 사용자에게 보여줄 파일들이 있는 최상위 디렉토리(Root Directory)를 의미한다. 즉 현재 설정에서는 /var/www/html 안에 있는 파일들이 웹 서비스의 기본 파일로 사용된다.

Web Hosting and Multiple Sites (웹 호스팅과 여러 사이트 운영)

기본적으로 Apache를 처음 설치하면 하나의 기본 사이트가 /var/www/html을 기준으로 동작한다. 그래서 처음에는 “서버 한 대당 홈페이지 하나만 운영할 수 있나?”라고 생각할 수 있다.

하지만 실제 웹 호스팅(Web Hosting) 회사들은 서버 한 대에서 여러 개의 홈페이지를 운영하기도 한다. 이때는 Apache의 Virtual Host(가상 호스트) 설정을 사용해서 사이트마다 다른 디렉토리와 도메인을 연결한다. 예를 들어 하나의 서버 안에서도 A 사이트는 /var/www/siteA, B 사이트는 /var/www/siteB처럼 나누어 운영할 수 있다.

Additional Notes (추가 설명)

/var/www/html은 Apache의 기본 웹 페이지 파일 위치이다.

DocumentRoot는 웹 서버가 실제로 파일을 찾아서 보여주는 기준 디렉토리이다.

000-default.conf는 Apache의 기본 사이트 설정 파일이다.

Linux에서 서버를 관리하려면 이런 경로를 직접 찾아가고, 설정 파일을 확인하고, 필요한 파일을 수정하는 연습이 중요하다.

실습화면

가상머신안에 Apache2를 설치하였다. Apache를 설치하면 보통 자동으로 /var/www/html 디렉토리가 생성된다. index.html은 Apache 웹 서버(Apache Web Server)가 기본으로 보여주는 첫 번째 웹페이지 파일이다. 즉 브라우저에서 서버 IP 주소로 접속했을 때:

http://서버IP주소

Apache는 자동으로 /var/www/html/index.html 파일을 찾아서 보여줍니다.

예를 들어 index.html 안에 이런 내용이 있으면:

Hello Apache

브라우저에서 서버 IP로 접속했을 때 Hello Apache가 보이게 됩니다.

정리하면:

/var/www/html        → 웹사이트 파일들이 들어가는 기본 폴더
index.html           → 웹사이트 첫 화면 파일
DocumentRoot         → Apache가 웹 파일을 찾는 기준 위치

그래서 index.html은 “홈페이지의 메인 페이지”라고 이해하면 된다. 블로그로 비유하면, 사용자가 주소만 입력했을 때 가장 먼저 보이는 첫 화면이 된다. cat index.html을 했을 때 <html>, <head>, <body>, <div> 같은 <> 태그가 많이 보이는 이유는 index.html이 HTML 파일이기 때문이다.

HTML File (HTML 파일)

index.html은 웹 브라우저가 읽는 문서 파일이다. 사람이 보기에는 태그가 잔뜩 있는 코드처럼 보이지만, 브라우저는 이 태그들을 해석해서 우리가 보는 웹페이지 화면으로 보여준다.

예를 들어 파일 안에 이런 내용이 있으면:

<h1>Hello Apache</h1>
<p>This is my first web page.</p>

터미널에서 cat index.html을 하면 태그까지 그대로 보인다.

<h1>Hello Apache</h1>
<p>This is my first web page.</p>

하지만 브라우저에서 접속하면 태그는 보이지 않고 이렇게 보인다.

Hello Apache
This is my first web page.

Apache Default Page (Apache 기본 페이지)

Apache를 설치하면 기본으로 만들어지는 index.html에는 “Apache2 Ubuntu Default Page” 같은 안내 페이지 코드가 들어 있다. 그래서 cat index.html을 하면 태그가 아주 많이 보이는 것이 정상이다.

위의 연습은 DocumentRoot /var/www/html2 를 이용해서 html2 를 따로 만들어서 Hello html2 문구를 넣어보았다.

User-Specific Home Directory in Apache (Apache 사용자별 홈 디렉토리)

Apache의 userdir 기능은 “각 사용자 계정마다 자기 홈페이지 폴더를 하나씩 가질 수 있게 해주는 기능”이다. Apache(Apache Web Server)는 기본적으로 /var/www/html을 홈 디렉토리(DocumentRoot)로 사용한다. 이 위치에 index.html 같은 파일을 두면 웹 브라우저에서 서버 주소로 접속했을 때 해당 파일이 보인다.

/var/www/html

하지만 아래처럼 서버에 여러 사용자 계정(User Account)이 있을 경우를 생각해보자

/home/heesunoh
/home/mis
/home/student1

각 사용자마다 자기 홈페이지를 만들게 하고 싶다면, 모든 사람이 /var/www/html을 같이 쓰는 것보다 자기 홈 디렉토리 안에 홈페이지 폴더를 따로 갖는 것이 편하다. 그래서 Apache는 이렇게 정한다.

각 사용자 홈 디렉토리 안의 public_html 폴더를 홈페이지 폴더로 쓰자.

예를 들어 사용자 이름이 heesunoh라면 다음 위치가 사용자 홈페이지 디렉토리가 될 수 있다. 이 폴더가 heesunoh 사용자의 개인 홈페이지 공간이 되는것이다.

/home/heesunoh/public_html

이 안에 index.html 파일을 아래처럼 만들면 웹에서 접속할 수 있다.

/home/heesunoh/public_html/index.html

그리고 웹에서는 아래처럼 볼 수 있게 하는 기능이다.

http://서버IP/~heesunoh/index.html

그런데 Apache는 처음부터 이 기능을 켜두지 않는다. 그래서 userdir 모듈을 활성화해야 한다. 이때 사용하는 것이 userdir 모듈(Module)이다. userdir을 사용하면 각 사용자의 홈 디렉토리(Home Directory) 안에 있는 public_html 디렉토리를 웹 페이지 공간으로 사용할 수 있다. 관련 설정 파일은 다음 위치에 있다.

/etc/apache2/mods-available/userdir.conf

사진 속 설정의 의미는 다음과 같다. 이는 각 사용자의 홈 디렉토리 아래 public_html을 웹 디렉토리로 사용하겠다는 의미이다.

UserDir public_html

이 기능을 사용하려면 userdir 모듈을 활성화해야 한다.

/etc/apache2/sites-enabled/000-default.conf
→ 서버의 기본 홈페이지 설정
→ DocumentRoot /var/www/html

/etc/apache2/mods-available/userdir.conf
→ 사용자별 홈페이지 설정
→ /home/사용자/public_html

root 계정은 이 기능을 사용하지 못하게 막겠다는 뜻이다. 보안상 root의 개인 홈페이지를 열어두지 않는 것이다.

<Directory /home/*/public_html>

/home/사용자이름/public_html 형태의 모든 사용자 디렉토리에 적용되는 설정이다. 여기서 *는 모든 사용자 이름을 의미한다.

sudo a2enmod userdir
sudo systemctl restart apache2.service

Additional Notes (추가 설명)

/var/www/html은 서버 전체의 기본 홈페이지 디렉토리이다.

/home/사용자이름/public_html은 사용자별 홈페이지 디렉토리이다.

userdir 모듈을 활성화하면 여러 사용자가 각자 자신의 홈 디렉토리 안에 홈페이지 파일을 둘 수 있다.

정리하면, 기본 Apache 홈페이지는 /var/www/html에 있고, 사용자별 홈페이지는 userdir 설정을 통해 /home/사용자/public_html에서 제공할 수 있다.ㅇ

실습결과 1; /etc/apache2/mods-available/userdir.conf 파일의 실제 내용을 확인했다.

실습결과 2; Apache가 현재 기본 DocumentRoot로 설정된 html2안의 index.html파일을 잘 읽어서 응답함을 확인했다.

User-Specific Home Directory with userdir (userdir를 이용한 사용자별 홈 디렉토리)

이전 실습에서는 Apache의 기본 홈페이지 위치를 배웠다면 지금 실습하려는 부분은 방금 배운 내용을 “실제로 켜고 테스트하는 단계”이다.

Apache(Apache Web Server)는 기본적으로 /var/www/html을 웹 서비스의 기본 홈 디렉토리(DocumentRoot)로 사용한다. 하지만 서버에 여러 사용자 계정(User Account)이 있을 경우, 각 사용자마다 개인 홈페이지를 제공할 수도 있다. 이때 사용하는 기능이 userdir 모듈(Module)이다. 그런데 이건 아직 “기능이 준비되어 있다”는 뜻이지, 실제로 작동한다는 뜻은 아니다. 그래서 이번 실습에서는 이 기능을 실제로 활성화하고, 내 계정 안에 public_html 폴더를 만들어서 웹페이지가 보이는지 확인하는 단계이다. userdir을 활성화하려면 다음 명령어를 사용한다.

sudo a2enmod userdir
sudo systemctl restart apache2

이 명령어는 /etc/apache2/mods-available/userdir.conf에 있는 사용 가능한 모듈 설정을 /etc/apache2/mods-enabled/ 쪽으로 활성화하는 역할을 한다. Apache에서 userdir 기능을 켜는 명령어이고 즉 ~사용자이름 주소로 사용자별 홈페이지에 접근할 수 있게 한다. 명령어 실행 후에는 Apache가 친절하게 재시작이 필요하다고 알려준다. 여기까지 Apache에서 사용자별 홈페이지 기능(userdir)을 켠 상태가 되었다.

userdir 설정이 활성화되면 각 사용자의 홈 디렉토리(Home Directory) 안에 있는 public_html 디렉토리가 개인 홈페이지 공간으로 사용된다. 예를 들어 사용자 계정이 heesunoh라면 다음 위치에 홈페이지 파일을 만들 수 있다.

/home/heesunoh/public_html/index.html

그리고 웹에서 접속할 때는 보통 다음과 같이 사용자 이름 앞에 물결표시(~)를 붙인다.

http://서버IP주소/~heesunoh/

사진 속 설정 파일에서도 중요한 부분은 다음 내용이다.

UserDir public_html <Directory /home/*/public_html>

UserDir public_html은 각 사용자의 홈 디렉토리 아래 public_html 폴더를 웹 디렉토리로 사용하겠다는 뜻이다. /home/*/public_html에서 *는 여러 사용자 계정을 의미한다. 즉 /home/user1/public_html, /home/user2/public_html처럼 사용자마다 다른 홈페이지 디렉토리를 가질 수 있다.

Additional Notes (추가 설명)

/var/www/html은 서버 전체의 기본 홈페이지 위치이고, /home/사용자명/public_html은 사용자별 홈페이지 위치이다.

가끔 오래된 홈페이지 주소에서 ~username 형태를 볼 수 있는데, 이는 Apache의 userdir 기능을 사용한 사용자별 홈페이지 방식일 가능성이 높다.

실습할 때는 public_html 디렉토리를 직접 만들어야 한다.

mkdir ~/public_html
echo "<h1>My Homepage</h1>" > ~/public_html/index.html

실습결과

주소는 맞게 찾았는데, Apache가 그 파일/폴더에 접근할 권한이 없다”는 뜻이 확인되었다. 권한 설정이 아직 부족한 상태로 다음 슬라이드에서 권한 설정을 세팅할것이다.

User-Specific Directory Permissions (사용자별 디렉토리 권한)

Apache의 userdir 기능을 사용하면 각 사용자의 홈 디렉토리(Home Directory) 안에 public_html 디렉토리를 만들어 개인 홈페이지를 제공할 수 있다. 예를 들어 사용자 계정이 mis라면 웹 파일은 다음 위치에 둘 수 있다.

/home/mis/public_html/index.html

이때 중요한 것은 permission(권한)이다. Apache가 웹 페이지 파일에 도착하려면 중간 경로인 /home/mis와 ~/public_html 디렉토리를 통과할 수 있어야 한다. 그래서 디렉토리에는 execution permission(실행 권한)이 필요하다.

chmod 711 /home/$USER
mkdir ~/public_html
chmod 711 ~/public_html

여기서 711은 소유자(owner)는 rwx, 그룹(group)과 기타 사용자(others)는 x 권한만 가진다는 뜻이다. 디렉토리에서 x 권한은 “실행”이라기보다 그 디렉토리를 통과하거나 접근할 수 있는 권한으로 이해하면 된다. 즉 다른 사용자가 내 홈 디렉토리의 파일 목록을 읽을 수는 없지만, 정확한 경로를 알고 있으면 public_html 안의 웹 파일까지 접근할 수 있게 된다.

웹 페이지 파일 자체는 읽기 권한(read permission)이 있어야 한다. 그래서 index.html에는 다음처럼 읽기 권한을 준다.

chmod 744 ~/public_html/index.html

744는 소유자는 읽기, 쓰기, 실행이 가능하고, 그룹과 기타 사용자는 읽기만 가능하다는 뜻이다. 웹 브라우저로 접속하는 외부 사용자는 이 파일을 수정할 필요는 없고 읽기만 하면 되므로 read permission(읽기 권한)이 필요하다.

접속 주소는 보통 다음과 같은 형태가 된다.

http://서버IP주소/~사용자이름/index.html

예를 들어 사용자 이름이 mis라면 다음처럼 접속할 수 있다.

http://10.211.55.9/~mis/index.html

Additional Notes (추가 설명)

디렉토리의 x 권한은 해당 디렉토리를 “통과”할 수 있는 권한이다. 파일의 x 권한처럼 프로그램 실행만 의미하는 것이 아니다.

711은 다른 사용자가 디렉토리 목록을 볼 수는 없지만, 정확한 파일 경로를 알면 접근할 수 있게 하는 설정이다.

744는 웹 페이지 파일을 외부에서 읽을 수 있게 하기 위한 권한 설정이다. Apache가 index.html을 읽을 수 있어야 웹페이지가 정상적으로 보인다.

실습결과

권한을 부여했고 정상적으로 확인할 수 있었다.

User Directory Without Tilde Using mod_rewrite (mod_rewrite를 이용한 물결표 없는 사용자 디렉토리 접속)

Apache(Apache Web Server)의 userdir 기능을 사용하면 사용자별 홈페이지에 보통 다음과 같이 접속한다.

http://서버IP/~사용자이름/

여기서 ~사용자이름 형태는 오래된 방식의 개인 홈페이지 주소에서 자주 볼 수 있다. 하지만 이 방식은 서버에 어떤 사용자 계정(User Account)이 존재하는지 외부에 드러낼 수 있다는 단점이 있다. 사용자 이름이 노출되면, 해당 계정을 대상으로 비밀번호 추측 공격이나 피싱(Phishing) 시도가 이루어질 가능성이 있다.

이를 줄이기 위해 mod_rewrite 모듈(Module)을 사용할 수 있다. mod_rewrite는 사용자가 입력한 URL을 Apache 내부에서 다른 경로로 바꿔서 처리하게 해주는 기능이다. 먼저 다음 명령어로 rewrite 모듈을 활성화한다.

sudo a2enmod rewrite

활성화 후에는 Apache를 재시작해야 적용된다.

sudo systemctl restart apache2

그다음 Apache 설정 파일에 rewrite 규칙을 추가한다.

RewriteEngine On

RewriteCond %{REQUEST_URI} ^/([^/]+)
RewriteCond /home/%1/public_html -d RewriteRule ^/([^/]+)(.*) /home/\(1/public_html\)2 [L]

이 설정을 적용하면 기존처럼 ~를 붙이지 않고도 사용자 홈페이지에 접속할 수 있다.

기존 방식: http://서버IP/~mis/index.html

변경 후: http://서버IP/mis/index.html

즉 사용자가 /mis/index.html로 접속하면 Apache가 내부적으로 /home/mis/public_html/index.html을 찾아서 보여주는 방식이다.

Additional Notes (추가 설명)

mod_rewrite는 URL Rewrite(URL 재작성)를 담당하는 Apache 모듈이다.

RewriteEngine On은 rewrite 기능을 켜는 설정이다.

RewriteRule은 사용자가 입력한 주소를 실제 서버 내부 경로로 바꿔주는 규칙이다.

핵심은 ~username 형태를 직접 보여주지 않고도, 사용자별 public_html 디렉토리에 있는 홈페이지를 접속할 수 있게 만드는 것이다.

실습 결과

Apache 설정안에 Rewrite를 설정하였다.

수정된 내용을 업데이트하고 curl을 이용해 제대로 적용되었는지 확인하였다.

User Directory Access Without Tilde (물결표 없이 사용자 디렉토리 접속하기)

Apache(Apache Web Server)의 userdir 기능을 사용하면 사용자별 홈페이지에 보통 다음과 같이 접속한다.

http://서버IP/~사용자이름/index.html

예를 들어 사진의 첫 번째 화면처럼 다음 주소로 접속하면 사용자 mis의 public_html 디렉토리에 있는 index.html 파일을 볼 수 있다.

http://10.211.55.9/~mis/index.html

그런데 앞에서 설정한 mod_rewrite를 적용하면 ~ 없이도 같은 사용자 홈페이지에 접속할 수 있다.

http://10.211.55.9/mis/index.html

사진의 두 번째 화면이 바로 이 결과이다. 주소에는 ~가 없지만, 실제로는 Apache가 내부적으로 /home/mis/public_html/index.html 파일을 찾아서 보여준다.

즉 두 주소는 겉으로 보이는 URL(URL 주소)은 다르지만, 최종적으로 접근하는 파일은 같은 파일이다.

~ 있는 방식:
http://10.211.55.9/~mis/index.html

~ 없는 방식:
http://10.211.55.9/mis/index.html

실습에서 no ~라는 문구를 추가한 이유는 rewrite 설정이 제대로 적용되었는지 확인하기 위해서이다. 원래 같은 index.html 파일을 보여주지만, 파일 내용을 조금 바꿔서 새 주소 방식도 정상적으로 적용되었는지 확인한 것이다.

Additional Notes (추가 설명)

~username 방식은 Apache의 userdir 기능에서 사용하는 오래된 사용자별 홈페이지 주소 방식이다.

mod_rewrite를 사용하면 사용자가 입력한 주소를 서버 내부의 실제 파일 경로로 바꿔서 처리할 수 있다.

핵심은 ~mis/index.html과 /mis/index.html이 겉으로는 다른 주소처럼 보이지만, 설정 후에는 같은 사용자 홈페이지 파일을 보여줄 수 있다는 점이다.

실습결과

물결 표시가 있게/ 없게 가능한지 확인하였고 정상적으로 작동하였다.

Name-Based Virtual Hosting (이름 기반 가상 호스팅)

Apache(Apache Web Server)에서는 하나의 서버(Host Server) 안에서 여러 개의 웹 사이트(Web Site)를 운영할 수 있다. 이를 Virtual Host(가상 호스트)라고 한다. 사진에서는 Apache 공식 문서의 Virtual Host 예제를 참고하라고 안내하고 있다.

여기서 중요한 개념은 domain name(도메인 이름)이다. 예를 들어 하나의 서버가 1.1.1.1이라는 IP 주소(IP Address)를 가지고 있고, koreacu.ac.kr과 다른 옛날 홈페이지 주소가 모두 같은 내용을 보여줘도 된다면, 두 domain name이 같은 IP를 가리키게 하면 된다. 이 경우 웹 서버 입장에서는 같은 서버로 접속하는 것이므로 비교적 단순하다.

하지만 domain name마다 서로 다른 내용을 보여줘야 한다면 설정이 달라진다. 예를 들어 siteA.com은 A 홈페이지 파일을 보여주고, siteB.com은 B 홈페이지 파일을 보여줘야 한다면 Apache에서 Virtual Host(가상 호스트)를 설정해야 한다. 그러면 하나의 Apache 서버 안에서도 domain name에 따라 서로 다른 DocumentRoot(문서 루트)를 사용할 수 있다.

예를 들면 다음과 같은 방식이다.

siteA.com → /var/www/siteA
siteB.com → /var/www/siteB

즉 서버는 하나지만, 접속한 이름(domain name)에 따라 다른 웹 페이지 디렉토리를 보여줄 수 있다. 웹호스팅(Web Hosting) 회사들이 하나의 서버에서 여러 홈페이지를 운영할 수 있는 이유도 이런 방식과 관련이 있다.

Additional Notes (추가 설명)

domain name(도메인 이름)은 사람이 기억하기 쉬운 웹사이트 주소이고, 실제 접속은 IP Address(IP 주소)를 통해 이루어진다.

같은 내용을 보여줄 경우에는 여러 domain name이 같은 IP를 가리키게 하면 된다.

서로 다른 내용을 보여줄 경우에는 Apache의 Virtual Host(가상 호스트) 설정을 사용해 domain name별로 다른 DocumentRoot를 지정할 수 있다.

IP-Based Virtual Hosting (IP 주소 기반 가상 호스팅)

Apache(Apache Web Server)에서는 하나의 서버에서 여러 웹 사이트(Web Site)를 운영할 수 있다. 앞에서는 domain name(도메인 이름)을 기준으로 서로 다른 사이트를 구분하는 방법을 배웠고, 이번에는 IP address(IP 주소)를 기준으로 구분하는 방법이다.

예를 들어 하나의 서버에서 다음처럼 서로 다른 IP 주소로 접속했을 때 다른 웹사이트를 보여줄 수 있다.

10.211.55.9   → 첫 번째 웹사이트
10.211.55.100 → 두 번째 웹사이트

처음에는 “컴퓨터 한 대에는 IP 주소가 하나만 있는 것 아닌가?”라고 생각할 수 있다. 과거에는 물리적인 컴퓨터를 여러 대 준비해야 하는 경우가 많았지만, 현재는 하나의 머신(Machine) 안에서도 여러 IP 주소를 설정하거나, VM(Virtual Machine), 네트워크 설정, 가상화 기술을 통해 여러 주소를 서비스할 수 있다.

즉 IP-Based Virtual Hosting(IP 주소 기반 가상 호스팅)은 하나의 Apache 서버가 여러 IP 주소를 받아들이고, 접속한 IP 주소에 따라 다른 DocumentRoot(문서 루트)를 보여주는 방식이다.

예를 들면 다음과 같이 설정할 수 있다.

10.211.55.9   → /var/www/site1
10.211.55.100 → /var/www/site2

이렇게 하면 같은 Apache 서버를 사용하더라도 접속한 IP 주소에 따라 서로 다른 웹 페이지를 제공할 수 있다.

Additional Notes (추가 설명)

Virtual Host(가상 호스트)는 하나의 서버에서 여러 웹사이트를 운영하기 위한 Apache 기능이다.

Name-Based Virtual Host(이름 기반 가상 호스트)는 domain name(도메인 이름)으로 사이트를 구분한다.

IP-Based Virtual Host(IP 기반 가상 호스트)는 IP address(IP 주소)로 사이트를 구분한다.

실제 설정 방법은 Apache 공식 문서의 Virtual Host 예제를 참고하면 된다. 강의에서는 “하나의 서버에서도 여러 IP 주소나 여러 사이트를 서비스할 수 있다”는 개념을 이해하는 것이 핵심이다.

Port-Based Virtual Hosting (포트 기반 가상 호스팅)

Apache(Apache Web Server)는 하나의 서버에서 여러 웹사이트를 운영할 수 있다. 앞에서는 domain name(도메인 이름)이나 IP address(IP 주소)를 기준으로 웹사이트를 나누는 방법을 배웠고, 이번에는 port number(포트 번호)를 기준으로 나누는 방법이다.

기본적으로 웹 서버는 HTTP 요청을 받을 때 80번 포트(Port 80)를 사용한다. 그래서 사용자가 아래처럼 접속하면 사실은 80번 포트로 접속하는 것이다.

http://10.211.55.9

이는 실제로는 다음과 같은 의미이다.

http://10.211.55.9:80

하지만 다른 포트를 사용하면 같은 IP 주소에서도 다른 웹사이트를 운영할 수 있다. 예를 들어 9999번 포트를 사용하면 다음처럼 접속할 수 있다.

http://10.211.55.9:9999

이 경우 기존의 /var/www/html은 80번 포트용 홈 디렉토리(DocumentRoot)로 사용하고, 새로 만든 /var/www/port9999는 9999번 포트용 홈 디렉토리로 사용할 수 있다.

sudo mkdir /var/www/port9999/

그리고 이 디렉토리의 소유자를 현재 사용자로 바꾸면 매번 root 권한 없이 파일을 만들고 수정할 수 있다.

sudo chown \(USER:\)USER /var/www/port9999/

새로운 포트용 설정 파일(Configuration File)은 처음부터 만들기보다 기존 Apache 기본 설정 파일을 복사해서 사용하는 것이 편리하다.

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/port9999.conf

이후 port9999.conf에서 VirtualHost의 포트 번호와 DocumentRoot를 9999번 포트용으로 수정하면 된다.

Additional Notes (추가 설명)

port(포트)는 같은 IP 주소 안에서 서비스를 구분하는 번호이다.

80번 포트는 기본 웹 서비스(HTTP)에 사용된다.

9999번처럼 다른 포트를 사용하면 같은 서버와 같은 IP 주소에서도 다른 웹사이트를 운영할 수 있다.

핵심은 IP 주소나 도메인을 새로 사지 않아도, 포트 번호를 다르게 해서 별도의 웹 서비스 공간을 만들 수 있다는 점이다.

Port-Based VirtualHost Configuration (포트 기반 VirtualHost 설정)

Apache(Apache Web Server)에서 다른 포트 번호(Port Number)를 사용하려면, 기존 설정 파일을 복사해서 새로운 설정 파일을 만들 수 있다. 예를 들어 9999번 포트용 웹사이트를 만들려면 다음처럼 새 디렉토리를 만든다.

sudo mkdir /var/www/port9999/

그리고 해당 디렉토리의 소유자를 현재 사용자로 바꾸면, 매번 sudo를 쓰지 않고도 파일을 만들거나 수정할 수 있다.

sudo chown \(USER:\)USER /var/www/port9999/

그다음 기존 Apache 기본 설정 파일을 복사해서 9999번 포트용 설정 파일을 만든다.

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/port9999.conf

복사한 port9999.conf 파일에서는 두 부분을 수정한다. 첫 번째는 VirtualHost의 포트 번호이고, 두 번째는 DocumentRoot이다.

<VirtualHost *:9999>
    DocumentRoot /var/www/port9999
</VirtualHost>

<VirtualHost *:9999>는 9999번 포트로 들어오는 요청을 이 설정에서 처리하겠다는 뜻이다. DocumentRoot /var/www/port9999는 9999번 포트로 접속했을 때 보여줄 웹 파일의 위치를 의미한다.

Additional Notes (추가 설명)

기본 웹사이트는 보통 80번 포트와 /var/www/html을 사용한다.

http://서버IP
→ /var/www/html

9999번 포트를 추가하면 같은 서버에서도 다른 웹사이트처럼 사용할 수 있다.

http://서버IP:9999
→ /var/www/port9999

즉 포트 번호(Port Number)를 다르게 하면 하나의 서버에서 여러 웹사이트를 구분해서 운영할 수 있다.

실습결과

기존 기본 사이트 설정 파일을 복사해서 port9998.conf를 만들고, VirtualHost 포트를 9998로 바꿨다. 그리고 DocumentRoot를 /var/www/port9998로 지정하였다.

Apache Listen Port Configuration (Apache 포트 수신 설정)

Port-Based Virtual Hosting(포트 기반 가상 호스팅)을 사용하려면 VirtualHost 설정만 바꾸는 것으로 끝나지 않는다. Apache가 해당 포트로 들어오는 요청을 받을 수 있도록 ports.conf에도 포트를 추가해야 한다.

Apache의 포트 설정 파일은 다음 위치에 있다.

sudo vi /etc/apache2/ports.conf

기본적으로 Apache는 80번 포트(Port 80)를 사용한다.

Listen 80

여기에 9999번 포트로도 웹 요청을 받게 하려면 다음 줄을 추가한다.

Listen 9999

즉 설정 파일에는 다음과 같이 들어갈 수 있다.

Listen 80
Listen 9999

이렇게 해야 Apache가 80번 포트뿐만 아니라 9999번 포트에서도 요청을 기다리게 된다. 그리고 앞에서 만든 port9999.conf에서는 9999번 포트로 들어온 요청이 /var/www/port9999 디렉토리를 보도록 설정한다.

<VirtualHost *:9999> 
    DocumentRoot /var/www/port9999
</VirtualHost>

설정을 바꾼 뒤에는 Apache를 재시작해야 적용된다.

sudo systemctl restart apache2

Additional Notes (추가 설명)

ports.conf의 Listen 9999는 “Apache가 9999번 포트에서 요청을 받을 준비를 하겠다”는 뜻이다.

port9999.conf의 <VirtualHost *:9999>는 “9999번 포트로 들어온 요청을 어떤 웹사이트 설정으로 처리할지” 정하는 부분이다.

즉 9999번 포트 웹사이트를 만들려면 두 가지가 필요하다.

1. ports.conf에 Listen 9999 추가

2. port9999.conf에 <VirtualHost *:9999> 설정

실습결과

Apache가 9999번 포트 요청을 받을 수 있도록 ports.conf에 Listen 9999를 추가하였다. 마지막으로 새 사이트 설정을 활성화하고 Apache를 재시작하였다. curl http://localhost:9998 확인하면 9998번 포트용 웹페이지가 출력된것을 확인했다.

Port-Based Site Enable and Restart (포트 기반 사이트 활성화와 재시작)

Apache(Apache Web Server)에서 9999번 포트용 웹사이트를 만들려면, 앞에서 만든 설정 파일 port9999.conf를 활성화해야 한다. 설정 파일을 만들기만 하면 Apache가 바로 사용하는 것이 아니라, sites-enabled에 연결되어야 실제 적용된다. 사이트 활성화 명령어는 다음과 같다.

sudo a2ensite port9999.conf

이 명령어를 실행하면 Apache가 port9999.conf 사이트 설정을 사용할 수 있게 된다. 실행 결과로 “새 설정을 적용하려면 Apache를 reload 또는 restart 하라”는 안내가 나온다.

그다음 Apache 서비스를 다시 시작한다.

sudo systemctl restart apache2

이제 웹 브라우저에서 다음 주소로 접속하면 9999번 포트용 웹페이지가 보인다.

http://10.211.55.9:9999

기본 웹사이트는 80번 포트를 사용하므로 다음처럼 접속한다.

http://10.211.55.9

반면 9999번 포트 웹사이트는 주소 뒤에 :9999를 붙여야 한다.

http://10.211.55.9:9999

즉 같은 IP 주소(IP Address)를 사용하더라도 포트 번호(Port Number)를 다르게 하면 서로 다른 웹사이트처럼 운영할 수 있다.

Additional Notes (추가 설명)

a2ensite는 Apache 사이트 설정(Site Configuration)을 활성화하는 명령어이다.

port9999.conf는 9999번 포트로 들어오는 요청을 처리하기 위한 설정 파일이다.

9999번 포트를 사용하려면 다음 세 가지가 모두 필요하다.

1. /etc/apache2/ports.conf 에 Listen 9999 추가

2. /etc/apache2/sites-available/port9999.conf 설정

3. sudo a2ensite port9999.conf 후 Apache 재시작

첫 번째 질문이 있다. 컴퓨터에 파일을 저장하는 상황을 떠올려보자. 과제 파일, 사진, 동영상처럼 다양한 파일을 계속 저장하다 보면 파일의 수가 많아질수록 어떤 문제가 발생할까?

파일의 수가 많아지면 필요한 파일을 찾는 데 오랜 시간이 걸릴 수 있다. 또한 파일이 어디에 저장되어 있는지 헷갈릴 수도 있다. 아무 기준 없이 파일이 저장되어 있다면 원하는 파일을 빠르게 찾는 것은 더욱 어려워진다.

이처럼 데이터를 단순히 저장하는 것만으로는 부족하다. 파일을 효율적으로 사용하기 위해서는 체계적으로 관리하는 구조가 필요하다. 운영체제(Operating System)는 파일 시스템(File System)을 통해 파일을 구조적으로 관리하고, 사용자가 원하는 파일에 효율적으로 접근할 수 있도록 지원한다.

두 번째 질문이 있다. 파일을 저장할 때 우리는 디스크(Disk)의 실제 위치를 직접 지정하지 않는다. 보통 파일 이름(File Name)만 정해서 저장한다. 그렇다면 저장된 파일은 실제로 어디에 저장되는 것일까? 또한 나중에 파일을 사용할 때는 어떤 기준으로 찾아오게 될까?

파일의 이름과 실제 저장 위치(Storage Location)는 분리되어 있다. 실제 파일 데이터는 보조기억장치(Secondary Storage)의 특정 위치에 저장되며, 운영체제가 이 위치 정보를 체계적으로 관리한다.

만약 이러한 위치 정보가 제대로 관리되지 않는다면 파일을 찾는 데 시간이 오래 걸리거나, 원하는 파일을 찾지 못하는 상황이 발생할 수 있다. 따라서 이번 내용에서는 파일의 저장 위치를 운영체제가 어떻게 관리하는지, 그리고 파일을 효율적으로 찾기 위해 어떤 구조를 사용하는지 살펴본다.

파일 시스템(File System) 학습 개요

이번 주차는 파일 시스템(File System)에 대해 학습한다. 프로그램이 실행되면서 생성되는 데이터를 지속적으로 보관하기 위해서는 보조기억장치(Secondary Storage)에 저장해야 한다.

이때 운영체제(Operating System)는 데이터를 단순히 저장하는 것이 아니라, 파일(File)이라는 논리적인 단위로 관리한다. 이를 통해 사용자가 데이터를 효율적으로 저장하고 접근할 수 있도록 지원한다.

이번 시간에는 파일의 구성 방식과 관리 방법, 그리고 파일이 디스크(Disk)에 저장되고 접근되는 전체적인 흐름을 살펴본다. 특히 파일과 디렉토리(Directory)의 구성, 아이노드(Inode)를 통한 파일 접근 과정, 디스크 블록(Block) 단위의 저장 방식을 학습한다.

또한 파일이 디스크에 저장될 때 사용되는 연속 할당(Contiguous Allocation), 연결 할당(Linked Allocation), 인덱스 할당(Indexed Allocation) 방식의 특징을 이해하고, 각 방식의 접근 성능과 저장 공간 효율을 비교한다.

마지막으로 파일 입출력(File Input/Output) 실습을 통해 파일 디스크립터(File Descriptor)와 오프셋(Offset)의 의미를 이해한다. 또한 파일이 여러 프로세스(Process) 간에 공유될 때 어떤 구조로 동작하는지도 함께 살펴본다.

파일 시스템(File System)의 개념과 역할

먼저 파일 시스템(File System)의 개념과 역할에 대해 살펴보자. 파일 시스템이란 파일을 생성(Create), 저장(Store), 검색(Search), 수정(Update)하는 전체 과정을 관리하는 운영체제(Operating System)의 중요한 구성 요소이다.

파일 시스템은 디스크(Disk)의 물리적인 저장 구조를 사용자에게 직접 보여주지 않는다. 대신 파일(File)이라는 논리적인 단위를 통해 사용자가 데이터를 쉽게 저장하고 접근할 수 있도록 도와준다.

또한 파일 시스템은 개별 파일만 관리하는 것이 아니라, 디렉토리(Directory) 구조와 메타데이터(Metadata)를 포함해 전체 저장 공간을 관리한다. 여기서 메타데이터란 파일의 실제 내용이 아니라, 파일의 크기(File Size), 생성 시간(Creation Time), 접근 권한(Access Permission), 저장 위치(Storage Location)처럼 파일을 관리하기 위한 정보를 의미한다.

결국 파일 시스템은 사용자가 복잡한 저장 구조를 직접 신경 쓰지 않아도 데이터를 효율적으로 저장하고 찾을 수 있도록 해주는 핵심적인 관리 구조라고 이해할 수 있다.

파일 시스템(File System)의 역할

파일 시스템(File System)이 실제로 어떤 역할을 수행하는지 살펴보자.

먼저 파일 시스템은 파일을 생성(Create), 삭제(Delete), 수정(Update)하는 기본적인 작업을 처리한다. 또한 파일마다 접근 권한(Access Permission)을 관리하여 허용된 사용자만 파일을 읽거나 수정할 수 있도록 보호 기능(Protection)을 수행한다.

또한 파일 시스템은 디스크 공간(Disk Space)을 효율적으로 관리한다. 각 파일이 디스크의 어느 위치에 저장되어 있는지 추적하고, 사용자가 파일 이름(File Name)만으로도 해당 파일에 접근할 수 있도록 지원한다.

파일 시스템은 사용자와 저장장치(Storage Device) 사이에서 인터페이스(Interface) 역할도 수행한다. 사용자는 복잡한 디스크 구조를 직접 알 필요 없이 파일과 디렉토리(Directory)를 통해 데이터를 사용할 수 있다.

마지막으로 파일 시스템은 데이터의 일관성(Consistency)과 무결성(Integrity)을 유지한다. 여러 작업이 동시에 이루어지는 상황에서도 데이터가 손상되지 않고 올바른 상태로 유지되도록 관리하는 역할을 한다.

파일 시스템(File System)의 내부 구조

파일 시스템(File System)의 내부 구조는 사용자의 요청이 실제 디스크(Disk)에 접근하기까지의 흐름으로 이해할 수 있다.

먼저 사용자는 파일 생성(Create), 읽기(Read), 쓰기(Write)와 같은 작업을 요청한다. 파일 시스템은 이 요청을 받아 처리하며, 이 과정에서 디렉토리 관리(Directory Management)와 파일 조작(File Operation)이 이루어진다.

그다음 단계에서는 파일이 레코드(Record) 단위로 나뉘고, 논리적인 파일 구조(Logical File Structure)가 실제 디스크의 블록 구조(Block Structure)에 맞게 변환된다.

이후에는 블록 캐시(Block Cache)를 통해 디스크 접근 횟수를 줄인다. 자주 사용하는 데이터를 메모리(Memory)에 유지하면 매번 디스크에 접근하지 않아도 되므로 파일 접근 속도를 높일 수 있다.

오른쪽으로 갈수록 실제 디스크와 가까운 영역이다. 이 단계에서는 파일 할당(File Allocation), 빈 공간 관리(Free Space Management), 디스크 스케줄링(Disk Scheduling)과 같은 작업이 수행된다.

즉, 이 구조는 사용자의 파일 요청이 파일 시스템을 거쳐 최종적으로 디스크에 접근하는 전체 흐름을 보여준다.

파일(File)의 개념

파일(File)은 이름을 가진 하나의 논리적인 데이터 집합이다. 파일은 여러 데이터로 구성되어 있지만, 사용자 입장에서는 하나의 단위로 다룰 수 있다.

실제로 파일은 디스크(Disk)에 여러 블록(Block)으로 나뉘어 저장될 수 있다. 하지만 사용자는 파일을 여러 조각으로 인식하지 않고, 하나의 연속된 데이터처럼 사용한다.

즉, 파일의 실제 저장 위치나 내부 구조는 사용자에게 직접 보이지 않는다. 이러한 정보는 운영체제(Operating System)가 내부적으로 관리한다.

따라서 파일은 사용자가 데이터를 쉽게 다룰 수 있도록 제공되는 논리적인 데이터 단위(Logical Data Unit)이며, 실제 저장 구조와 관리는 운영체제가 담당한다고 이해할 수 있다.

파일(File)의 구성 요소

파일(File)은 여러 단계의 구성 요소로 이루어진다.

먼저 가장 작은 단위로 필드(Field)가 있다. 필드는 이름, 학번, 점수처럼 개별적인 정보를 의미한다.

이러한 필드들이 모이면 하나의 레코드(Record)가 된다. 레코드는 의미 있는 데이터의 묶음으로, 예를 들어 한 학생에 대한 전체 정보를 하나의 레코드라고 볼 수 있다.

여러 개의 레코드는 블록(Block) 단위로 저장된다. 블록은 디스크(Disk)에서 데이터를 읽고 쓰는 기본 단위이기 때문에, 운영체제(Operating System)는 실제로 블록 단위를 기준으로 데이터를 처리한다.

마지막으로 여러 블록이 모여 하나의 파일(File)을 구성한다. 즉, 파일은 필드(Field), 레코드(Record), 블록(Block)이라는 계층 구조를 통해 구성된다고 할 수 있다.

파일(File)의 속성

파일(File)은 실제 데이터뿐만 아니라, 파일을 관리하기 위한 다양한 정보도 함께 가진다.

파일의 속성(File Attribute)에는 파일 이름(File Name), 파일 크기(File Size), 저장 위치(Storage Location)와 같은 기본 정보가 포함된다. 운영체제(Operating System)는 이러한 정보를 통해 파일을 식별하고 접근한다.

또한 파일의 생성 시간(Creation Time), 수정 시간(Modification Time)과 같은 시간 정보도 관리된다. 접근 권한(Access Permission)과 같은 보호 정보도 포함되어 있어 파일의 읽기(Read), 쓰기(Write), 수정(Update) 권한을 제어할 수 있다.

이러한 속성들은 파일의 실제 내용을 직접 담고 있지는 않지만, 파일을 효율적으로 관리하고 보호하기 위해 반드시 필요한 정보라고 할 수 있다.

파일(File)의 속성과 데이터 연결 구조

파일(File)의 속성과 데이터가 어떻게 연결되는지 그림 구조를 통해 살펴보자.

먼저 디렉토리(Directory)에는 파일 이름(File Name)과 해당 파일을 가리키는 인덱스(Index) 정보가 저장되어 있다. 사용자가 파일 이름으로 접근하면, 운영체제(Operating System)는 디렉토리를 통해 해당 파일을 찾는다.

그다음 인덱스(Index)를 통해 파일 헤더(File Header)로 연결된다. 파일 헤더에는 파일 크기(File Size), 생성 시간(Creation Time), 접근 권한(Access Permission)과 같은 파일 속성(File Attribute)이 저장되어 있다.

또한 파일 헤더에는 실제 데이터가 저장된 위치를 가리키는 주소 정보(Address Information)도 포함된다. 운영체제는 이 주소를 따라가 실제 데이터 블록(Data Block) 또는 인덱스 블록(Index Block)에 접근한다.

정리하면, 파일은 디렉토리(Directory), 파일 헤더(File Header), 데이터 블록(Data Block)의 구조를 통해 접근된다. 사용자는 파일 이름만 사용하지만, 내부적으로는 운영체제가 파일 속성과 저장 위치 정보를 이용해 실제 데이터를 찾아간다.

File Operations(파일 연산)

이번에는 파일 연산(File Operation)에 대해 살펴본다. 파일 연산은 파일을 열고, 데이터를 읽거나 쓰고, 사용이 끝나면 닫고, 필요하면 삭제하는 일련의 과정으로 이해할 수 있다.

먼저 open은 파일을 식별하고 접근을 준비하는 단계이다. 파일 이름(File Name)을 기준으로 디렉토리(Directory)를 탐색하고, 해당 파일의 위치(Location)와 속성(Attribute) 정보를 찾아온다.

read/write는 실제 데이터를 처리하는 단계이다. 이때 현재 파일 내 위치를 오프셋(Offset)이라고 하며, 운영체제(Operating System)는 이 오프셋을 기준으로 데이터를 읽거나 쓴다. 데이터를 처리하면 파일 포인터(File Pointer)의 위치도 함께 이동한다.

close는 파일 사용이 끝났을 때 수행되는 단계이다. 파일과 관련된 자원(Resource)을 반환하고, 파일 접근 상태를 종료한다.

마지막으로 delete는 파일을 제거하는 작업이다. 파일을 삭제하고, 해당 파일이 사용하던 디스크 공간(Disk Space)을 해제한다.

즉, 파일 연산은 파일을 열고(open), 사용하고(read/write), 닫고(close), 필요하면 삭제하는(delete) 흐름으로 이루어진다고 이해할 수 있다.

Directory(디렉토리)

디렉토리(Directory)는 파일 이름(File Name)과 실제 저장 위치를 가리키는 아이노드(Inode)를 연결하는 구조이다.

사용자는 파일 이름으로 파일에 접근하지만, 운영체제(Operating System)는 디렉토리를 통해 해당 파일의 아이노드를 찾고, 이를 바탕으로 실제 저장 위치와 연결한다.

또한 디렉토리는 여러 파일을 그룹화(Grouping)하는 역할을 한다. 관련된 파일을 함께 관리할 수 있게 해주며, 파일 탐색(File Search)을 더 효율적으로 만들어준다.

디렉토리는 계층 구조(Hierarchical Structure)를 통해 파일을 체계적으로 관리한다. 사용자는 폴더(Folder)처럼 보이는 디렉토리 구조를 이용해 파일을 분류하고 쉽게 찾을 수 있다.

📌아이노드(Inode)는 파일의 실제 데이터 자체를 저장하는 공간이 아니라, 파일의 메타데이터(Metadata)와 데이터 블록(Data Block)의 위치 정보를 저장하는 구조이다.

즉, 디렉토리는 보통 “파일 이름 → 아이노드 번호(Inode Number)”를 연결하고, 아이노드는 “파일 정보 → 실제 데이터 블록 위치”를 연결한다고 이해하면 좋다.

Directory Structure(디렉토리 구조)

디렉토리(Directory)는 계층 구조(Hierarchical Structure)를 가진다. 즉, 하나의 디렉토리 안에 또 다른 디렉토리가 포함될 수 있으며, 이를 통해 전체 파일을 체계적으로 관리할 수 있다.

일반적으로 디렉토리 구조는 루트 디렉토리(Root Directory)를 기준으로 여러 개의 디렉토리와 파일(File)이 트리 구조(Tree Structure) 형태로 구성된다.

이러한 디렉토리 계층 구조를 사용하면 파일을 논리적으로 구분할 수 있고, 사용자는 원하는 파일을 더 효율적으로 탐색할 수 있다.

📌루트 디렉토리(Root Directory)는 디렉토리 구조의 가장 위에 있는 시작점이다. 리눅스/유닉스(Linux/Unix)에서는 /로 표현하고, 윈도우(Windows)에서는 보통 C:\와 같은 드라이브 단위로 표현된다.

Directory Organization(디렉토리 구조의 조직 방식)

앞서 디렉토리(Directory)의 역할을 살펴보았다면, 이번에는 디렉토리 구조(Directory Structure)가 어떻게 조직되는지 살펴본다.

초기의 파일 시스템(File System)은 모든 파일을 하나의 공간에 저장하는 단일 디렉토리 구조(Single-Level Directory Structure)로 시작하였다. 하지만 파일의 수가 증가하면서 파일을 구분하고 관리하는 것이 점점 어려워졌다.

이를 해결하기 위해 계층적 디렉토리 구조(Hierarchical Directory Structure)가 사용되기 시작했다. 트리 구조(Tree Structure)가 도입되면서 하나의 디렉토리 안에 하위 디렉토리(Subdirectory)를 포함할 수 있게 되었고, 파일을 주제나 목적에 따라 체계적으로 분류하고 관리할 수 있게 되었다.

또한 그래프 구조(Graph Structure)에서는 하나의 파일을 여러 위치에서 참조할 수 있다. 이를 통해 파일 공유(File Sharing)가 가능하지만, 여러 경로에서 같은 파일을 참조하기 때문에 관리가 더 복잡해질 수 있다.

Directory Structure 2(디렉토리 구조 2)

디렉토리가 어떻게 구성되고 연결되는지 살펴보자. 디렉토리 구조는 루트 디렉토리(Root Directory)에서 시작되며, 그 아래에 여러 하위 디렉토리(Subdirectory)와 파일(File)이 연결되는 형태로 구성된다.

디렉토리(Directory)는 단순히 이름만 저장하는 것이 아니라, 파일 이름(File Name)이나 하위 디렉토리 이름과 함께 해당 대상을 가리키는 아이노드 번호(Inode Number)를 함께 저장한다.

운영체제(Operating System)는 이 아이노드 번호를 따라가면서 파일의 실제 정보와 저장 위치를 확인하고, 최종적으로 데이터 블록(Data Block)에 접근한다. 여기서 아이노드 번호(Inode Number)는 파일의 정보와 위치를 찾기 위해 사용하는 고유한 식별자이다.

예를 들어 디렉토리 안에 p3라는 항목이 있고, 그 옆에 5067과 같은 값이 저장되어 있다면, 이 값은 해당 파일이나 디렉토리를 가리키는 아이노드 번호이다. 운영체제는 이 번호를 이용해 해당 파일의 메타데이터(Metadata)와 데이터 위치를 찾아간다.

또한 데이터 블록(Data Block)은 실제 파일 내용이 저장되어 있는 디스크 공간을 의미한다. 디렉토리는 파일 이름과 아이노드 번호를 연결하고, 아이노드는 실제 데이터 블록의 위치를 관리한다고 이해할 수 있다.

각 디렉토리에는 .과 .. 항목도 존재한다. .은 현재 디렉토리(Current Directory)를 의미하고, ..은 부모 디렉토리(Parent Directory)를 의미한다. 이를 통해 사용자는 계층 구조 안에서 현재 위치를 기준으로 이동할 수 있다.

정리하면, 디렉토리는 파일 이름과 실제 저장 위치를 연결하고, 계층적인 파일 탐색을 가능하게 하는 구조이다.

📌디렉토리(Directory)는 보통 “파일 이름 → 아이노드 번호(Inode Number)”를 저장한다. 반면 아이노드(Inode)는 파일 크기, 권한, 시간 정보 같은 메타데이터(Metadata)와 실제 데이터 블록(Data Block)의 위치 정보를 저장한다.

즉, 파일 접근 과정은 보통 파일 이름 → 디렉토리 → 아이노드 → 데이터 블록의 흐름으로 이해하면 좋다.

Tree-Structured Directory(트리 구조 디렉토리)

트리 구조 디렉토리(Tree-Structured Directory)는 루트 디렉토리(Root Directory)를 기준으로 하위 디렉토리(Subdirectory)가 계층적으로 확장되는 구조이다.

하나의 디렉토리(Directory) 아래에는 여러 개의 하위 디렉토리와 파일(File)이 포함될 수 있다. 이러한 구조가 반복되면서 전체 파일 시스템(File System)이 구성된다.

트리 구조 디렉토리는 파일을 목적별, 사용자별, 기능별로 구분하여 체계적으로 관리할 수 있게 해준다. 따라서 파일의 탐색(File Search)과 관리 효율이 높아 일반적으로 많이 사용되는 디렉토리 구조이다.

Tree-Structured Directory Diagram(트리 구조 디렉토리 그림 설명)

그림을 보면 루트 디렉토리(Root Directory)를 기준으로 여러 사용자 디렉토리(User Directory)가 나뉘어 있는 것을 확인할 수 있다.

각 사용자 디렉토리 안에는 다시 하위 디렉토리(Subdirectory)와 파일(File)이 포함되어 있다. 이러한 구조가 반복되면서 전체 파일 시스템(File System)이 트리 구조(Tree Structure) 형태로 구성된다.

트리 구조 디렉토리(Tree-Structured Directory)는 경로(Path)를 따라 파일을 탐색할 수 있게 해준다. 또한 파일을 사용자별, 목적별, 종류별로 체계적으로 분류할 수 있기 때문에 파일 관리가 효율적이다.

따라서 트리 구조는 현재 가장 일반적으로 사용되는 디렉토리 구조라고 할 수 있다.

트리 구조에서는 파일의 위치를 경로(Path)로 표현한다. 예를 들어 /user1/report.txt와 같은 경로는 루트 디렉토리(Root Directory)에서 시작해 user1 디렉토리 안의 report.txt 파일에 접근한다는 의미이다.

Graph-Structured Directory(그래프 구조 디렉토리)

그래프 구조 디렉토리(Graph-Structured Directory)는 하나의 파일(File)이나 디렉토리(Directory)를 여러 경로(Path)에서 참조할 수 있는 구조이다.

즉, 동일한 파일을 여러 위치에서 공유(File Sharing)할 수 있다는 특징이 있다. 이를 통해 파일의 중복 저장을 줄이고, 데이터를 더 효율적으로 활용할 수 있다.

하지만 그래프 구조는 트리 구조(Tree Structure)보다 관리가 복잡하다. 특히 순환 구조(Cycle)가 발생하면 파일 탐색(File Search) 과정에서 같은 경로를 반복해서 따라가게 되어 무한 반복(Infinite Loop) 문제가 생길 수 있다.

따라서 실제 시스템에서는 순환이 발생하지 않도록 제한한 비순환 그래프(Acyclic Graph) 형태로 사용하는 경우가 많다.

Graph-Structured Directory Diagram(그래프 구조 디렉토리 그림 설명)

그래프 구조 디렉토리(Graph-Structured Directory)는 하나의 파일(File)이나 디렉토리(Directory)가 여러 경로(Path)를 통해 연결될 수 있는 구조이다. 즉, 하나의 파일이 두 개 이상의 디렉토리에서 참조되면서 동일한 데이터를 여러 위치에서 사용할 수 있다.

그림에서 실선은 기본적인 디렉토리 계층 구조(Hierarchical Structure)를 나타내고, 점선은 추가적인 참조(Reference)나 공유 관계(Sharing Relationship)를 의미한다.

예를 들어 order 아래의 mail, expo는 일반적인 하위 디렉토리 관계로 실선으로 연결되어 있다. 반면 copy는 다른 방식으로 연결되어 있으며, copy 아래의 항목은 실선뿐만 아니라 program, expo와도 점선으로 연결되어 있다.

이처럼 그래프 구조에서는 하나의 대상이 여러 위치에서 참조될 수 있고, 경우에 따라 순환 관계(Cycle)가 발생할 수도 있다. 순환 관계가 생기면 파일 탐색(File Search) 과정에서 반복이 발생하거나, 디렉토리 구조 관리가 복잡해질 수 있다.

따라서 그래프 구조 디렉토리는 파일 공유(File Sharing)에는 유리하지만, 탐색과 관리 측면에서는 추가적인 고려가 필요한 구조라고 이해할 수 있다.

UNIX File System Structure(UNIX 파일 시스템 구조)

이제 파일 시스템(File System)이 디스크(Disk) 내부에서 어떻게 구성되는지 살펴본다.

UNIX 파일 시스템(UNIX File System)은 하나의 공간으로 구성되는 것이 아니라, 여러 영역으로 나뉘어 관리된다. 대표적으로 부트 블록(Boot Block), 슈퍼블록(Superblock), 아이노드 영역(Inode Area), 데이터 블록(Data Block)으로 구성되며, 각 영역은 서로 다른 역할을 수행한다.

이처럼 기능별로 영역을 분리해서 관리하면 파일 시스템의 효율성(Efficiency)과 안정성(Stability)을 높일 수 있다.

이 구조에서 가장 중요한 개념은 아이노드(Inode)이다. 아이노드는 파일의 실제 데이터 자체를 저장하는 공간이 아니라, 파일의 메타데이터(Metadata)와 데이터 위치 정보(Location Information)를 저장하는 구조이다.

예를 들어 아이노드에는 파일 크기(File Size), 접근 권한(Access Permission), 소유자 정보(Owner Information) 등이 포함된다. 실제 파일 데이터는 아이노드가 가진 포인터(Pointer)를 통해 데이터 블록(Data Block)에 접근하여 찾을 수 있다.

즉, 파일 이름(File Name)은 디렉토리(Directory)가 관리하고, 아이노드(Inode)는 파일의 정보와 실제 데이터 위치를 관리한다고 이해하면 된다.

UNIX/Linux 계열에서는 일반적으로 디렉토리(Directory)가 “파일 이름(File Name) → 아이노드 번호(Inode Number)”를 연결하고, 아이노드(Inode)가 “파일 정보(Metadata) → 데이터 블록(Data Block) 위치”를 연결한다.

따라서 파일 접근 흐름은 보통 다음과 같이 이해할 수 있다.

파일 이름(File Name) → 디렉토리(Directory) → 아이노드(Inode) → 데이터 블록(Data Block)

Inode Internal Structure(아이노드 내부 구조)

아이노드(Inode) 내부에는 여러 개의 포인터(Pointer)가 포함되어 있다. 이 포인터들은 실제 파일 데이터가 저장된 데이터 블록(Data Block)을 가리키는 역할을 한다.

먼저 직접 블록 포인터(Direct Block Pointer)는 데이터 블록을 바로 가리키는 구조이다. 파일 크기가 작은 경우에는 직접 블록 포인터만으로도 충분히 데이터를 찾을 수 있다.

하지만 파일 크기가 커지면 직접 포인터만으로는 모든 데이터 블록을 가리키기 어렵다. 이때 간접 포인터(Indirect Pointer)가 사용된다.

일중 간접 포인터(Single Indirect Pointer)는 인덱스 블록(Index Block)을 한 번 거쳐 데이터 블록에 접근한다. 이중 간접 포인터(Double Indirect Pointer)와 삼중 간접 포인터(Triple Indirect Pointer)는 인덱스 블록을 여러 단계 거쳐 더 많은 데이터 블록을 연결할 수 있다.

즉, 아이노드는 파일 크기에 따라 직접 포인터(Direct Pointer), 일중 간접 포인터(Single Indirect Pointer), 이중 간접 포인터(Double Indirect Pointer), 삼중 간접 포인터(Triple Indirect Pointer)를 사용해 확장된다. 이를 통해 작은 파일은 빠르게 접근하고, 큰 파일은 효율적으로 저장할 수 있다.

직접 포인터(Direct Pointer)는 데이터 블록을 바로 가리키기 때문에 접근 속도가 빠르다. 반면 간접 포인터(Indirect Pointer)는 중간에 인덱스 블록(Index Block)을 거치므로 접근 단계가 늘어나지만, 훨씬 큰 파일을 저장할 수 있게 해준다.

Actual File Access Process(파일 접근의 실제 동작)

실제 파일이 어떤 방식으로 접근되는지 살펴보자. 사용자는 파일 이름(File Name)으로 파일에 접근하지만, 운영체제(Operating System) 내부에서는 다른 방식으로 처리된다.

파일 이름은 주로 디렉토리(Directory)에서 사용된다. 운영체제는 디렉토리에서 파일 이름을 찾고, 해당 파일과 연결된 아이노드(Inode)를 확인한다. 실제 파일의 정보와 저장 위치는 이 아이노드를 통해 결정된다.

또한 프로그램(Process)은 파일 이름을 계속 사용하는 것이 아니라, 파일을 열 때 얻은 파일 디스크립터(File Descriptor, FD)를 기준으로 파일에 접근한다. 파일 디스크립터는 열린 파일을 식별하기 위해 운영체제가 제공하는 내부 번호이다.

즉, 사용자는 파일 이름으로 접근한다고 생각하지만, 운영체제 내부에서는 디렉토리(Directory), 아이노드(Inode), 파일 디스크립터(File Descriptor)를 통해 파일 접근이 이루어진다. 사용자가 보는 방식과 운영체제가 처리하는 방식이 다르다는 점이 핵심이다.

일반적으로 파일 접근 흐름은 다음과 같이 이해할 수 있다.

파일 이름(File Name) → 디렉토리(Directory) → 아이노드(Inode) → 파일 디스크립터(File Descriptor) → 데이터 블록(Data Block)

File Access Flow(파일 접근 흐름)

실제 파일 접근 흐름은 먼저 파일 이름(File Name)을 기준으로 디렉토리(Directory)를 탐색하는 것에서 시작된다. 운영체제(Operating System)는 디렉토리에서 해당 파일 이름과 연결된 아이노드 번호(Inode Number)를 찾는다.

그다음 아이노드(Inode)를 통해 파일의 정보와 실제 데이터 위치를 확인한다. 아이노드에는 파일의 메타데이터(Metadata)와 데이터 블록(Data Block)을 가리키는 위치 정보가 저장되어 있다.

마지막으로 운영체제는 해당 데이터 블록(Data Block)에 접근하여 읽기(Read) 또는 쓰기(Write) 작업을 수행한다.

더 정확히는 파일 이름과 아이노드가 직접 연결되는 것이 아니라, 디렉토리(Directory)가 중간에서 파일 이름과 아이노드 번호(Inode Number)를 연결한다.

따라서 실제 흐름은 파일 이름(File Name) → 디렉토리(Directory) → 아이노드(Inode) → 데이터 블록(Data Block)으로 이해하면 더 정확하다.

File Protection and Access Control(파일 보호와 접근 제어)

여러 사용자가 하나의 파일을 함께 사용할 경우, 누구나 자유롭게 수정할 수 있다면 데이터가 덮어씌워지거나 삭제되는 문제가 발생할 수 있다. 그래서 운영체제(Operating System)는 파일을 보호하고, 사용자별로 접근을 제어하는 기능을 제공한다.

파일 보호(File Protection)는 허가되지 않은 접근을 막아 데이터를 안전하게 유지하는 기능이다. 특히 여러 사용자가 동시에 파일을 사용하는 환경에서는 파일 보호 기능이 필수적이다.

접근 제어(Access Control)는 사용자별로 읽기(Read), 쓰기(Write), 실행(Execute)과 같은 작업 권한을 구분하는 역할을 한다. 예를 들어 A 사용자는 파일을 읽기만 가능하고, B 사용자는 파일을 수정할 수 있도록 다르게 설정할 수 있다.

접근 제어 방식에는 ACL(Access Control List) 방식과 그룹 기반 방식(Group-Based Access Control)이 있다. ACL 방식은 사용자별로 세밀한 권한 설정이 가능하지만, 관리가 복잡해질 수 있다. 반면 그룹 기반 방식은 여러 사용자를 그룹으로 묶어 권한을 관리하기 때문에 상대적으로 단순하고 효율적이다.

리눅스/유닉스(Linux/Unix)에서는 파일 권한을 보통 소유자(User), 그룹(Group), 기타 사용자(Others)로 나누어 관리한다. 각 대상에 대해 읽기(Read), 쓰기(Write), 실행(Execute) 권한을 설정할 수 있다.

UNIX Permission Structure(UNIX 권한 구조)

유닉스(UNIX)에서는 파일 접근 권한(File Permission)을 사용자 종류에 따라 구분해서 관리한다. 사용자는 크게 소유자(User/Owner), 그룹(Group), 기타 사용자(Others)로 나뉜다.

권한은 보통 -rwx rwx rwx와 같은 형태로 표현된다. 맨 앞의 문자는 파일 종류(File Type)를 의미한다. 일반 파일이면 -, 디렉토리(Directory)이면 d로 표시된다.

그 뒤의 권한은 세 묶음으로 나뉜다. 첫 번째 묶음은 소유자(User/Owner), 두 번째 묶음은 그룹(Group), 세 번째 묶음은 기타 사용자(Others)에 대한 권한을 나타낸다.

각 권한에서 r은 읽기(Read), w는 쓰기(Write), x는 실행(Execute)을 의미한다. 예를 들어 rwx r-x r--라고 표시되어 있다면, 소유자는 읽기, 쓰기, 실행이 모두 가능하다. 그룹 사용자는 읽기와 실행만 가능하고, 기타 사용자는 읽기만 가능하다는 뜻이다.

이처럼 유닉스는 사용자 그룹을 구분하고, 읽기(Read), 쓰기(Write), 실행(Execute) 권한을 조합하여 파일 접근을 제어한다. 지금까지는 파일 시스템(File System)의 구조, 파일 접근 방식, 그리고 접근 권한까지의 전체 흐름을 살펴보았다.

디렉토리(Directory)에서 실행 권한(Execute Permission)은 파일 실행과는 의미가 다르다. 디렉토리에 x 권한이 있어야 그 디렉토리 안으로 들어가거나 내부 파일에 접근할 수 있다.

Need for File Storage Structure(파일 저장 구조가 필요한 이유)

파일 저장 구조(File Storage Structure)가 필요한 이유는 디스크(Disk)가 항상 연속된 공간을 보장하지 않기 때문이다. 메모리(Memory)처럼 파일을 하나의 연속된 덩어리로 저장하기 어려운 경우가 많다.

그래서 파일(File)은 여러 개의 블록(Block)으로 나뉘어 디스크의 서로 다른 위치에 저장될 수 있다. 또한 파일이 생성(Create), 삭제(Delete), 확장(Extend)되는 과정에서 블록의 배치도 계속 달라질 수 있다.

이처럼 파일의 저장 위치가 계속 변하기 때문에, 운영체제(Operating System)가 이를 관리하지 않으면 파일 위치를 추적하거나 접근하는 것이 어려워진다.

따라서 운영체제는 파일이 어떤 블록에 저장되어 있는지 관리하기 위해 파일 저장 구조(File Storage Structure)를 사용한다.

파일 저장 구조는 파일 할당 방식(File Allocation Method)과 연결된다. 대표적인 방식으로는 연속 할당(Contiguous Allocation), 연결 할당(Linked Allocation), 인덱스 할당(Indexed Allocation)이 있다.

File Storage Structure Diagram(파일 저장 구조 그림 설명)

각 파일이 어떤 블록(Block)에 저장되어 있는지는 파일 테이블(File Table) 형태로 관리할 수 있다.

예를 들어 파일 A(File A)의 블록 번호가 1, 3, 9라면, 파일 A의 데이터가 디스크(Disk)의 1번, 3번, 9번 블록에 나누어 저장되어 있다는 의미이다.

저장장치(Storage Device)를 보면 이러한 블록들이 서로 떨어진 위치에 분산되어 저장될 수 있다. 따라서 파일을 읽을 때는 각 블록의 위치를 따라가며 데이터를 가져와야 한다.

운영체제(Operating System)는 이러한 블록 위치 정보(Block Location Information)를 관리한다. 그리고 분산되어 저장된 데이터를 하나의 연속된 파일(File)처럼 연결해주는 역할을 한다.

즉, 실제 저장은 여러 블록에 나뉘어 분산되어 있지만, 사용자는 하나의 파일처럼 사용할 수 있다. 이것이 파일 저장 구조(File Storage Structure)가 필요한 이유이다.

📌 파일이 여러 블록에 분산되어 저장되는 현상을 단편화(Fragmentation)와 연결해서 이해할 수 있다. 파일 시스템(File System)은 블록 위치를 관리하여 사용자가 단편화된 저장 구조를 직접 신경 쓰지 않아도 되게 한다.

File and Disk Storage Relationship(파일과 디스크 저장의 관계)

이제 파일의 블록(Block)이 실제 디스크(Disk)에서 어떻게 관리되는지 살펴본다.

파일(File)은 사용자 입장에서 하나의 논리적인 순서(Logical Order)를 가진다. 예를 들어 파일은 0, 1, 2, 3과 같은 순서의 블록들로 구성되며, 이를 논리 블록 번호(VBN, Virtual Block Number)라고 한다.

하지만 실제 디스크에서는 이 데이터가 반드시 연속적으로 저장되는 것이 아니다. 파일의 각 블록은 디스크의 여러 물리적인 위치에 나누어 저장될 수 있으며, 이때 실제 디스크 위치를 나타내는 번호를 물리 블록 번호(LBN, Logical Block Number)라고 한다.

즉, 파일 내부에서는 논리 블록 번호(VBN)를 기준으로 순서가 정해지지만, 실제 디스크에서는 물리 블록 번호(LBN)를 기준으로 저장 위치가 결정된다.

파일 시스템(File System)은 이 두 구조를 연결하는 매핑 정보(Mapping Information)를 관리한다. 이를 통해 실제 블록들이 디스크에 흩어져 있어도 사용자는 파일을 논리적으로 연속된 데이터처럼 사용할 수 있다.

File and Disk Storage Relationship 2 (파일과 디스크 저장의 관계 2)

그림을 보면 왼쪽에는 논리적인 파일 구조(Logical File Structure)가 있고, 각 블록은 논리 블록 번호(VBN, Virtual Block Number)를 기준으로 순서가 정해져 있다.

반면 오른쪽의 디스크(Disk)에서는 데이터가 서로 떨어진 물리 블록(Physical Block)에 저장되어 있는 것을 확인할 수 있다. 즉, 파일 안에서는 0, 1, 2, 3처럼 순서가 있어도 실제 디스크에서는 연속된 위치에 저장되지 않을 수 있다.

이때 VBN에서 LBN으로 향하는 화살표는 운영체제(Operating System)가 논리 블록(Logical Block)을 물리 블록(Physical Block)으로 변환하는 매핑(Mapping) 과정을 의미한다.

예를 들어 논리 블록 0번이 디스크의 558번 위치에 저장될 수 있다. 이처럼 논리적인 순서와 실제 저장 위치는 서로 다르게 연결될 수 있다.

따라서 파일을 읽을 때는 단순히 디스크의 연속된 위치를 따라가는 것이 아니라, 운영체제가 매핑 정보(Mapping Information)를 이용해 각 물리 블록을 순서대로 찾아가며 데이터를 읽는다.

VBN(Virtual Block Number)은 파일 안에서의 논리적인 블록 순서를 의미하고, LBN(Logical Block Number)은 실제 저장장치에서 블록이 위치한 주소를 의미한다.

핵심은 사용자는 파일을 연속된 데이터처럼 보지만, 실제 디스크에서는 여러 위치에 나뉘어 저장될 수 있으며 운영체제가 이를 연결해준다는 점이다.

Physical Structure of Disk(디스크의 물리적 구조)

파일이 저장되는 디스크(Disk)의 물리적 구조를 살펴보자. 디스크는 여러 개의 원판(Platter)으로 구성되어 있으며, 각 원판은 트랙(Track)과 섹터(Sector)로 나뉘어 데이터를 저장한다.

실제 데이터는 섹터(Sector) 단위로 저장된다. 디스크에 접근할 때는 원하는 위치로 헤드(Head)가 이동하는 시간과, 원판이 회전하면서 원하는 섹터가 헤드 아래로 올 때까지 기다리는 회전 지연 시간(Rotational Latency)이 발생한다.

즉, 디스크 접근에는 헤드 이동 시간(Seek Time)과 회전 지연 시간(Rotational Latency)이라는 비용이 포함된다. 그래서 디스크에서 데이터를 읽고 쓰는 속도는 단순히 데이터 크기뿐만 아니라, 데이터가 어디에 저장되어 있는지에도 영향을 받는다.

하지만 이러한 물리적인 구조는 사용자에게 직접 보이지 않는다. 파일 시스템(File System)이 디스크 구조를 추상화(Abstraction)해서 관리하기 때문에, 사용자는 복잡한 디스크 구조를 몰라도 파일(File) 단위로 데이터를 쉽게 사용할 수 있다.

이 설명은 전통적인 하드 디스크(HDD, Hard Disk Drive)에 해당한다. SSD(Solid State Drive)는 회전하는 원판이나 헤드가 없기 때문에 헤드 이동 시간(Seek Time)이나 회전 지연 시간(Rotational Latency)이 거의 없다. 다만 운영체제는 HDD든 SSD든 파일 시스템(File System)을 통해 파일을 논리적인 단위로 관리한다.

Disk Block and File Storage Structure(디스크 블록과 파일 저장 구조)

디스크(Disk)는 실제로 섹터(Sector) 단위로 데이터를 저장하지만, 파일 시스템(File System)은 여러 섹터를 묶어 블록(Block) 단위로 관리한다. 이 블록은 파일 저장(File Storage)과 입출력(Input/Output)의 기본 단위가 된다.

운영체제(Operating System)는 데이터를 한 바이트(Byte)씩 처리하기보다는 블록 단위로 읽고 쓴다. 디스크 특성상 작은 단위로 여러 번 접근하는 것보다, 더 큰 단위로 한 번에 읽고 쓰는 것이 효율적이기 때문이다.

블록 안에는 파일 데이터(File Data)가 저장된다. 필요한 경우에는 다음 블록의 위치 정보(Location Information)가 포인터(Pointer) 형태로 포함될 수도 있다. 이는 파일의 여러 블록을 서로 연결해 관리하기 위한 방식이다.

블록 크기(Block Size)는 시스템에서 미리 정해진 값으로 사용되며, 보통 1KB, 2KB, 4KB처럼 2의 거듭제곱 형태로 설정된다. 즉, 파일 시스템은 디스크의 물리적인 섹터를 그대로 사용하는 것이 아니라, 여러 섹터를 묶은 블록 단위로 파일을 저장하고 관리한다.

블록 크기(Block Size)가 너무 작으면 관리해야 할 블록 수가 많아져 오버헤드(Overhead)가 커질 수 있다. 반대로 블록 크기가 너무 크면 작은 파일을 저장할 때 남는 공간이 생겨 내부 단편화(Internal Fragmentation)가 발생할 수 있다.

File and Block Relationship(파일과 블록의 관계)

정리하면 하나의 파일(File)은 여러 개의 블록(Block)으로 구성된다. 이러한 블록들은 디스크(Disk)상에서 항상 연속적으로 저장되는 것이 아니라, 서로 떨어진 위치에 저장될 수도 있다.

파일의 크기(File Size)에 따라 필요한 블록의 개수가 결정된다. 파일이 작으면 적은 수의 블록만 필요하고, 파일이 커질수록 더 많은 블록이 필요하다.

파일의 읽기(Read)와 쓰기(Write) 작업도 모두 블록 단위로 이루어진다. 운영체제(Operating System)는 파일을 바이트(Byte) 단위로 하나씩 처리하기보다는, 블록 단위로 데이터를 읽고 쓰는 방식으로 관리한다.

이때 블록의 배치 방식(Block Allocation Method)에 따라 파일 접근 성능(File Access Performance)이 달라질 수 있다. 예를 들어 블록이 연속적으로 배치되어 있으면 빠르게 접근할 수 있지만, 여러 위치에 흩어져 있으면 접근 속도가 느려질 수 있다.

접근 속도가 느려지는 이유는 디스크 접근 횟수가 늘어날 수 있기 때문이다. 특히 HDD(Hard Disk Drive)에서는 헤드 이동 시간(Seek Time)이 발생하기 때문에 성능에 영향을 줄 수 있다. 반면 SSD(Solid State Drive)는 물리적인 헤드 이동이 없어서 흩어진 블록에 접근할 때의 영향이 HDD보다 상대적으로 작다.

따라서 이후에 살펴볼 파일 할당 방식(File Allocation Method)에서는 블록을 어떻게 배치하고 관리할 것인지가 중요한 요소가 된다.

Characteristics of Block-Based Storage(블록 기반 저장의 특징)

디스크(Disk)는 데이터를 블록(Block) 단위로 저장하고 관리한다. 이러한 블록 기반 저장 방식에는 몇 가지 특징이 있다.

먼저 파일의 크기(File Size)가 블록 크기(Block Size)보다 작은 경우, 블록 내부에 사용되지 않는 공간이 발생할 수 있다. 이를 내부 단편화(Internal Fragmentation)라고 한다.

내부 단편화(Internal Fragmentation)는 할당된 블록 안에서 남는 공간이 생기는 문제이다. 예를 들어 블록 크기가 4KB인데 파일 크기가 1KB라면, 나머지 3KB는 사용되지 않는 공간으로 남을 수 있다.

하지만 블록 단위로 데이터를 처리하면 디스크 입출력(Disk I/O)을 한 번에 수행할 수 있기 때문에, 전체적인 입출력 성능은 효율적으로 향상될 수 있다.

또한 파일 시스템(File System)은 각 블록의 위치 정보를 메타데이터(Metadata) 형태로 관리한다. 따라서 블록이 어떻게 배치되어 있는지에 따라 파일 접근 속도(File Access Speed)가 달라질 수 있다.

Key Design Issues in File Storage Structure(저장 구조 설계의 핵심 문제)

파일을 여러 블록(Block)으로 나누어 저장할 때는 이 블록들을 어떤 방식으로 배치할 것인지 결정해야 한다. 이것이 파일 저장 구조(File Storage Structure) 설계의 핵심 문제이다.

블록을 연속적으로 배치하면 파일 접근 속도(File Access Speed)는 빨라질 수 있다. 하지만 연속된 빈 공간을 확보해야 하므로 저장 공간 효율(Storage Efficiency)이 떨어질 수 있다.

반대로 블록을 흩어진 위치에 저장하면 디스크 공간을 더 유연하게 사용할 수 있지만, 파일을 읽을 때 여러 위치를 따라가야 하므로 접근 속도가 느려질 수 있다.

즉, 파일 저장 구조에는 성능(Performance)과 저장 효율(Efficiency) 사이의 트레이드 오프(Trade-off)가 존재한다.

또한 파일 시스템(File System)은 내부 단편화(Internal Fragmentation)를 줄이고, 파일 크기 변화에도 유연하게 대응할 수 있어야 한다. 결국 파일 시스템 설계에서는 성능, 효율, 유연성(Flexibility) 사이의 균형을 맞추는 것이 중요하다.

이러한 설계 문제를 해결하기 위해 파일 시스템은 연속 할당(Contiguous Allocation), 연결 할당(Linked Allocation), 인덱스 할당(Indexed Allocation)과 같은 파일 할당 방식(File Allocation Method)을 사용한다. 더 자세한 내용은 앞서 배워볼 예정이다.

Overview of File Allocation Methods(파일 할당 방식의 개요)

파일 할당 방식(File Allocation Method)에서 중요한 것은 파일을 구성하는 블록(Block)을 디스크(Disk)에 어떻게 배치할 것인가이다.

즉, 파일 할당 방식은 파일의 여러 블록을 디스크의 어느 위치에 저장하고, 이 블록들을 어떻게 연결해서 관리할지를 결정하는 방법이다.

할당 방식에 따라 파일 접근 속도(File Access Speed)와 디스크 공간 활용 방식(Disk Space Utilization)이 달라진다. 따라서 파일 할당 방식은 파일 시스템(File System)의 성능을 결정하는 중요한 개념이다.

대표적인 파일 할당 방식(File Allocation Method)에는 연속 할당(Contiguous Allocation), 연결 할당(Linked Allocation), 인덱스 할당(Indexed Allocation)이 있다. 각각 접근 속도, 저장 효율, 파일 크기 변화 대응 방식에서 차이가 있다.

Contiguous Allocation(연속 할당)

연속 할당(Contiguous Allocation)은 파일을 디스크(Disk)의 하나의 연속된 구간에 저장하는 방식이다. 가장 직관적이고 단순한 파일 할당 방식(File Allocation Method)이라고 할 수 있다.

이 방식에서는 파일의 시작 위치(Start Block)와 길이(Length)만 알면 전체 데이터를 쉽게 찾을 수 있다. 따라서 파일의 저장 구조가 단순하고 관리하기 쉽다.

또한 데이터 블록(Block)이 연속적으로 배치되기 때문에 파일 접근 속도(File Access Speed)가 빠르다는 장점이 있다. 특히 파일을 순서대로 읽는 순차 접근(Sequential Access)에 효율적이다.

Contiguous Allocation Structure(연속 할당의 구조)

연속 할당(Contiguous Allocation)의 구조를 그림으로 살펴보면, 디렉토리(Directory)에 파일 이름(File Name), 시작 블록(Start Block), 길이(Length)가 함께 저장되어 있는 것을 확인할 수 있다.

예를 들어 CTR.doc 파일의 시작 블록이 1이고 길이가 4라면, 디스크(Disk)의 1번 블록부터 4개의 연속된 블록을 이 파일이 사용한다는 의미이다.

오른쪽 디스크 구조를 보면 파일이 중간에 끊기지 않고 연속된 공간을 차지하고 있다. 이처럼 연속 할당은 파일을 시작 위치와 길이로 관리하며, 하나의 연속된 구간에 저장하는 방식이다.

연속 할당은 시작 블록과 길이만 알면 원하는 위치를 계산하기 쉽기 때문에 직접 접근(Direct Access)에 유리하다. 예를 들어 파일의 세 번째 블록에 접근하려면 시작 블록 + 2처럼 계산할 수 있다.

Characteristics of Contiguous Allocation(연속 할당의 특징)

연속 할당(Contiguous Allocation)은 데이터 블록(Block)이 디스크(Disk)에 연속적으로 저장되는 방식이다. 따라서 디스크 헤드 이동(Disk Head Movement)이 최소화되어 높은 입출력 성능(I/O Performance)을 보일 수 있다.

이 방식은 파일을 처음부터 순서대로 읽는 순차 접근(Sequential Access)에도 효율적이고, 특정 위치를 바로 찾아가는 직접 접근(Direct Access)에도 효율적이다.

하지만 단점도 존재한다. 파일을 삭제하거나 이동하는 과정에서 디스크 중간중간에 빈 공간이 생기면서 단편화(Fragmentation) 문제가 발생할 수 있다. 이로 인해 큰 파일을 저장할 때 필요한 연속된 공간을 확보하기 어려워질 수 있다.

또한 파일 크기(File Size)가 증가했을 때 뒤쪽에 연속된 빈 공간이 없다면, 파일 전체를 다른 위치로 이동해야 하는 문제가 생길 수 있다.

그래서 실제 파일 시스템(File System)에서는 연속 할당을 그대로 사용하기보다는 익스텐트(Extent) 기반 방식으로 변형해서 사용하는 경우가 많다. 이 부분은 이후에 다시 살펴보자

📌익스텐트(Extent)는 여러 개의 연속된 블록을 하나의 묶음으로 관리하는 방식이다. 즉, 파일 전체가 하나의 연속 구간에 있어야 하는 것은 아니지만, 가능한 한 연속된 블록 묶음 단위로 저장하여 성능과 유연성을 함께 확보하려는 방식이다.

Linked Allocation(연결 할당)

연결 할당(Linked Allocation)은 연속 할당(Contiguous Allocation)의 단점을 보완하기 위한 방식이다. 이 방식은 파일을 여러 블록(Block)으로 나누어 저장하고, 각 블록을 포인터(Pointer)로 연결하여 하나의 파일로 구성한다.

각 블록에는 다음 블록의 위치 정보(Location Information)가 포함되어 있다. 운영체제(Operating System)는 이 포인터를 따라가면서 파일 데이터를 순서대로 읽는다.

연결 할당은 파일을 반드시 연속된 공간에 저장할 필요가 없다. 따라서 디스크(Disk)의 흩어진 빈 공간을 활용할 수 있고, 파일 크기(File Size)가 증가할 때도 비교적 유연하게 확장할 수 있다.

연결 할당은 순차 접근(Sequential Access)에는 적합하지만, 특정 위치로 바로 이동하는 직접 접근(Direct Access)에는 불리하다. 중간 블록에 접근하려면 첫 블록부터 포인터를 따라가야 하기 때문이다.

Linked Allocation Diagram(연결 할당 그림 설명)

그림을 보면 하나의 파일(File)이 연속된 공간이 아니라 여러 디스크 블록(Disk Block)에 나누어 저장되어 있는 것을 확인할 수 있다.

예를 들어 COT.doc 파일의 시작 블록(Start Block)이 18번이라고 하면, 18번 블록에는 다음 블록인 19번의 위치 정보가 저장되어 있다. 19번 블록으로 이동하면 다시 2번 블록으로 연결된다.

2번 블록에는 더 이상 다음 블록을 가리키는 연결 정보가 없으므로, 이 지점이 파일의 끝(End of File)을 의미한다. 즉, 이 파일은 18 → 19 → 2 순서로 구성되어 있다고 볼 수 있다.

이처럼 연결 할당(Linked Allocation)은 각 블록이 다음 블록의 위치를 포인터(Pointer)로 가지고 있기 때문에, 처음 블록만 알면 나머지 블록들을 순서대로 따라가며 파일을 읽을 수 있다.

따라서 파일은 물리적으로는 디스크 여러 위치에 흩어져 저장되어 있지만, 논리적으로는 하나의 파일처럼 동작한다.

연결 할당(Linked Allocation)은 연속된 빈 공간이 필요 없기 때문에 저장 공간 활용에는 유리하다. 하지만 중간 블록에 바로 접근하려면 앞에서부터 포인터를 따라가야 하므로 직접 접근(Direct Access) 성능은 떨어질 수 있다.

Characteristics of Linked Allocation(연결 할당의 특징)

연결 할당(Linked Allocation)은 파일을 앞에서부터 순서대로 읽는 순차 접근(Sequential Access)에서는 큰 문제가 없다. 각 블록(Block)의 포인터(Pointer)를 따라가며 차례대로 읽으면 되기 때문이다.

하지만 파일의 중간 위치에 바로 접근하려면 문제가 생긴다. 원하는 블록으로 바로 이동할 수 없고, 처음 블록부터 순서대로 포인터를 따라가야 한다. 이러한 방식을 포인터 체이싱(Pointer Chasing)이라고 한다.

또한 블록들이 디스크(Disk) 전체에 흩어져 저장될 수 있기 때문에, 파일을 읽을 때마다 디스크 헤드 이동(Disk Head Movement)이 자주 발생할 수 있다. 이로 인해 탐색 비용(Seek Cost)이 증가하고 접근 속도가 느려질 수 있다.

중간 블록이 손상될 경우에도 문제가 발생한다. 해당 블록 이후의 연결 정보가 끊어지면 파일의 일부를 읽지 못할 수 있다.

이러한 단점을 보완하기 위해 포인터 정보를 각 블록 안에 저장하지 않고, 한곳에 모아서 관리하는 FAT(File Allocation Table) 방식이 사용되기도 한다.

FAT(File Allocation Table)는 파일의 각 블록이 다음에 어떤 블록으로 이어지는지를 별도의 테이블에 저장하는 방식이다. 연결 할당의 기본 개념은 유지하되, 블록 연결 정보를 한곳에서 관리한다는 점이 특징이다.

Indexed Allocation(인덱스 할당)

앞서 연속 할당(Contiguous Allocation)과 연결 할당(Linked Allocation)을 살펴보았다. 연속 할당은 접근 속도가 빠르지만 연속된 공간을 확보하기 어렵고, 연결 할당은 파일 크기 변화에 유연하지만 직접 접근 속도가 느리다는 문제가 있다.

이러한 단점을 보완하기 위해 사용하는 방식이 인덱스 할당(Indexed Allocation)이다.

인덱스 할당은 데이터 블록(Data Block)을 서로 직접 연결하지 않고, 별도의 인덱스 블록(Index Block)에 각 데이터 블록의 위치 정보를 모아서 저장하는 방식이다.

파일을 읽을 때는 블록을 처음부터 순차적으로 따라가는 것이 아니라, 인덱스 블록을 통해 원하는 데이터 블록의 위치를 바로 확인할 수 있다.

따라서 인덱스 할당은 연결 할당보다 직접 접근(Direct Access)에 유리하고, 파일이 디스크의 여러 위치에 나뉘어 저장되어도 관리가 비교적 효율적이다.

인덱스 할당(Indexed Allocation)은 인덱스 블록(Index Block)을 추가로 사용하기 때문에, 파일마다 인덱스 정보를 저장하기 위한 별도의 공간이 필요하다. 즉, 접근 성능은 좋아지지만 인덱스 블록을 위한 저장 공간 오버헤드(Overhead)가 발생할 수 있다.

Indexed Allocation Structure(인덱스 할당 구조)

그림을 보면 디렉토리(Directory)에 파일 이름(File Name)과 함께 인덱스 블록(Index Block)의 위치가 저장되어 있다.

예를 들어 test 파일의 인덱스 블록이 8번이라면, 8번 블록에는 18, 20, 5, 7, 14, 9와 같이 실제 데이터 블록(Data Block)의 위치가 목록 형태로 저장되어 있다.

마지막 값이 -1인 경우에는 더 이상 연결된 블록이 없다는 의미이며, 파일의 끝(End of File)을 나타내는 표시로 이해할 수 있다.

이처럼 인덱스 블록(Index Block)은 파일을 구성하는 데이터 블록의 위치를 한곳에 모아서 관리한다. 따라서 실제 데이터가 디스크(Disk)에 흩어져 있어도 필요한 블록의 위치를 바로 확인할 수 있다.

즉, 인덱스 할당(Indexed Allocation)은 연결 할당(Linked Allocation)처럼 블록을 순차적으로 따라갈 필요 없이, 인덱스 블록을 통해 원하는 데이터 블록에 직접 접근할 수 있는 방식이다.

인덱스 할당(Indexed Allocation)은 직접 접근(Direct Access)에 유리하지만, 인덱스 블록(Index Block)을 따로 저장해야 하므로 추가 저장 공간이 필요하다. 또한 파일이 매우 커지면 하나의 인덱스 블록만으로 모든 데이터 블록 위치를 저장하기 어려울 수 있다.

Characteristics of Indexed Allocation(인덱스 할당 방식의 특징)

인덱스 할당(Indexed Allocation)은 인덱스 블록(Index Block)을 통해 데이터 블록(Data Block)의 위치를 한 번에 확인할 수 있는 방식이다.

이 방식은 원하는 블록의 위치를 바로 찾을 수 있기 때문에 직접 접근(Direct Access)이 가능하다. 따라서 처음 블록부터 순서대로 따라가야 하는 연결 할당(Linked Allocation)보다 접근 성능이 더 빠르다.

또한 데이터 블록들이 디스크(Disk)에 흩어져 있어도 인덱스 블록에 전체 위치 정보가 정리되어 있기 때문에 관리가 비교적 쉽다.

하지만 하나의 인덱스 블록에 저장할 수 있는 주소(Address)의 수에는 제한이 있다. 따라서 큰 파일을 저장할 때는 하나의 인덱스 블록만으로 모든 데이터 블록을 가리키기 어려워질 수 있다.

이를 해결하기 위해 다단계 인덱스 구조(Multi-Level Index Structure)나 유닉스(UNIX)의 아이노드(Inode)처럼 직접 포인터(Direct Pointer)와 간접 포인터(Indirect Pointer)를 함께 사용하는 방식이 사용된다.

다만 간접 포인터를 사용하는 경우에는 중간의 간접 블록(Indirect Block)을 거쳐야 하므로 추가적인 접근 비용(Access Cost)이 발생할 수 있다.

인덱스 할당(Indexed Allocation)은 연속 할당(Contiguous Allocation)과 연결 할당(Linked Allocation)의 단점을 보완한 방식이다. 직접 접근이 가능하면서도 파일이 반드시 연속된 공간에 저장될 필요가 없기 때문에, 성능과 유연성의 균형을 맞추는 방식이라고 이해하면 좋다.

Comparison of File Allocation Methods(파일 할당 방식 비교)

지금까지 세 가지 파일 할당 방식(File Allocation Method)을 살펴보았다.

연속 할당(Contiguous Allocation)은 구조가 단순하고 파일 접근 속도(File Access Speed)가 빠르다. 하지만 파일을 저장하기 위해 연속된 빈 공간이 필요하기 때문에 디스크 공간 활용(Disk Space Utilization)에 제약이 생길 수 있다.

연결 할당(Linked Allocation)은 파일 블록(Block)을 흩어진 공간에 저장할 수 있어 공간 활용에는 유리하다. 하지만 원하는 블록에 접근하려면 처음부터 포인터(Pointer)를 따라가야 하므로 접근 효율이 떨어질 수 있다.

인덱스 할당(Indexed Allocation)은 데이터 블록의 위치 정보를 인덱스 블록(Index Block)에 모아서 관리한다. 따라서 직접 접근(Direct Access)이 가능하고 구조적으로 균형이 잡혀 있다. 다만 별도의 인덱스 공간(Index Space)이 필요하다는 특징이 있다.

정리하면 연속 할당은 빠르지만 공간 확보가 어렵고, 연결 할당은 유연하지만 접근 속도가 느릴 수 있으며, 인덱스 할당은 접근성과 유연성의 균형을 제공하지만 추가 공간이 필요하다.

파일 할당 방식은 파일 시스템(File System)의 성능과 저장 효율을 결정하는 중요한 요소이다. 실제 파일 시스템에서는 하나의 방식만 단순히 사용하기보다, 익스텐트(Extent), 아이노드(Inode), 인덱스 구조(Index Structure) 등을 조합하여 성능과 효율을 함께 고려하는 경우가 많다.

Design Considerations for File Systems(파일 시스템 설계 고려 요소)

결국 파일 시스템(File System)을 설계할 때는 하나의 방식만 고려하는 것이 아니라 여러 요소를 함께 살펴봐야 한다.

먼저 파일 접근 패턴(File Access Pattern)에 따라 적합한 저장 방식이 달라진다. 파일을 처음부터 순서대로 읽는 순차 접근(Sequential Access)의 비중이 높은지, 특정 위치에 바로 접근하는 직접 접근(Direct Access) 또는 임의 접근(Random Access)의 비중이 높은지에 따라 효율적인 할당 방식이 달라질 수 있다.

또한 디스크 접근 비용(Disk Access Cost)도 중요한 요소이다. 특히 HDD(Hard Disk Drive)에서는 헤드 이동 시간(Seek Time)과 회전 지연 시간(Rotational Latency)이 발생하기 때문에, 블록(Block)이 어떻게 배치되어 있는지가 성능에 영향을 준다.

저장 효율(Storage Efficiency)과 접근 성능(Access Performance) 사이에는 항상 트레이드 오프(Trade-off)가 존재한다. 따라서 실제 파일 시스템에서는 하나의 방식만 사용하는 것이 아니라 여러 방식을 결합한 하이브리드 구조(Hybrid Structure)를 사용하는 경우가 많다.

예를 들어 ext4와 같은 파일 시스템(File System)에서는 연속 할당(Contiguous Allocation)을 확장한 익스텐트(Extent) 방식과 인덱스 구조(Index Structure)를 함께 활용한다. 이를 통해 연속적인 저장의 성능 장점과 큰 파일을 관리하기 위한 유연성을 함께 확보할 수 있다.

File System Operation in Practice(파일 시스템의 실제 동작)

이제 앞에서 살펴본 개념들이 실제 시스템(System)에서 어떻게 동작하는지 살펴본다.

프로그램이 실행되면 파일이 생성(Create)되거나, 기존 파일에 접근(Access)하고, 데이터를 읽고 쓰는 작업(Read/Write)이 이루어진다. 사용자는 파일 이름(File Name)을 기준으로 파일을 사용하지만, 운영체제(Operating System) 내부에서는 디렉토리(Directory), 아이노드(Inode), 파일 디스크립터(File Descriptor), 오프셋(Offset) 등을 통해 파일 접근이 처리된다.

이번 내용에서는 프로그램 실행 과정에서 파일이 어떻게 생성되고 접근되는지, 그리고 이러한 작업이 시스템 내부에서 어떤 구조로 처리되는지를 중심으로 살펴본다.

파일을 open하면 운영체제는 파일 이름을 찾아 아이노드(Inode) 정보를 확인하고, 열린 파일을 관리하기 위해 파일 디스크립터(File Descriptor)를 반환한다. 이후 프로그램은 파일 이름이 아니라 이 파일 디스크립터를 사용해 read, write, close 같은 작업을 수행한다.

File Descriptor(fd)(파일 디스크립터)

실습에서는 먼저 파일 디스크립터(File Descriptor, fd)에 대해 살펴본다.

시스템 내부에서 파일은 파일 이름(File Name)으로 계속 접근되는 것이 아니라, 파일 디스크립터(fd)라는 정수값(Integer Value)을 통해 접근된다.

프로그램이 open 함수를 호출하면 운영체제(Operating System)는 해당 파일을 열고, 그 파일을 식별하기 위한 파일 디스크립터를 반환한다.

이후 read나 write 같은 파일 입출력(File I/O) 연산은 파일 이름이 아니라 fd를 기준으로 수행된다. 즉, 사용자는 파일 이름으로 파일을 구분하지만, 운영체제는 열린 파일을 문자열이 아닌 정수값인 파일 디스크립터로 관리한다고 이해할 수 있다.

파일 디스크립터(fd)는 프로세스(Process)마다 따로 관리된다. 같은 숫자의 fd라도 프로세스가 다르면 서로 다른 파일을 가리킬 수 있다.

Core Code: open() and write()

핵심 코드를 통해 파일 디스크립터(File Descriptor, fd)가 어떻게 사용되는지 살펴보자.

int fd = open("lab1.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);

open() 함수는 파일을 열고, 그 결과로 파일 디스크립터(fd)를 반환한다. 이때 옵션(Option)을 통해 파일을 여는 방식을 결정한다.

O_CREAT는 파일이 없으면 새로 생성하겠다는 의미이다. O_TRUNC는 파일이 이미 존재할 경우 기존 내용을 지우겠다는 의미이다. O_WRONLY는 파일을 쓰기 전용(Write Only)으로 열겠다는 의미이다.

따라서 이 코드는 lab1.txt 파일이 없으면 새로 만들고, 이미 존재한다면 기존 내용을 지운 뒤 쓰기 전용으로 여는 코드이다.

뒤에 있는 0644는 파일 권한(File Permission)을 의미한다. 소유자(Owner)는 읽기(Read)와 쓰기(Write)가 가능하고, 그룹(Group)과 기타 사용자(Others)는 읽기만 가능한 권한이다.

다음으로 write() 함수는 파일 이름이 아니라 fd를 기준으로 데이터를 기록한다.

write(fd, "ABC\n", 4);

여기서 "ABC\n"은 기록할 문자열이고, 4는 총 4바이트(Byte)를 기록한다는 의미이다. 즉 A, B, C 세 글자와 줄바꿈 문자(Newline)까지 포함해 총 4바이트가 파일에 저장된다.

fd는 커널(Kernel)의 열린 파일 테이블(Open File Table)과 연결되어 있기 때문에, 파일의 상태와 현재 위치 정보도 함께 관리된다. 또한 동일한 파일이라도 open()을 다시 호출하면 새로운 fd가 생성된다. 이 부분은 파일 디스크립터의 동작을 이해하는 데 중요한 특징이므로 반드시 기억해야 한다.

📌 O_TRUNC는 “기존 파일을 삭제”하는 것이 아니라, 파일 자체는 유지하되 기존 내용을 비워서 파일 크기를 0으로 만드는 옵션이다.

File Descriptor(fd)(파일 디스크립터)

open() 함수는 파일(File)을 생성하거나 열면서 접근 권한(Access Permission)과 접근 방식(Access Mode)을 함께 설정한다.

예를 들어 O_WRONLY | O_CREAT | O_TRUNC와 같은 옵션(Option)을 사용하면 파일을 쓰기 전용으로 열지, 파일이 없을 때 새로 만들지, 기존 내용을 비울지를 결정할 수 있다.

파일을 열면 운영체제(Operating System)는 해당 파일을 식별하기 위한 파일 디스크립터(File Descriptor, fd)를 생성한다. 이후 프로그램은 파일 이름(File Name)이 아니라 이 fd를 기준으로 파일에 접근한다.

write() 함수는 메모리(Memory)에 있는 데이터를 파일에 기록하는 역할을 한다. 이 과정에서도 파일 이름을 직접 사용하는 것이 아니라, open()을 통해 얻은 파일 디스크립터(fd)를 사용한다.

즉, 파일은 사용자 입장에서는 이름으로 구분되지만, 프로그램 실행 중에는 파일 디스크립터(fd)를 통해 관리되고 접근된다고 이해할 수 있다.

File Descriptor Example(파일 디스크립터 실제 예제)

파일 디스크립터(File Descriptor, fd)의 실제 예제를 살펴보자.

open() 함수는 lab1.txt 파일을 열도록 되어 있다. 이때 O_CREAT 옵션이 있으면 파일이 존재하지 않을 경우 새로 생성하고, O_TRUNC 옵션이 있으면 기존 파일의 내용을 비워 초기화한다.

open() 함수가 실행되면 결과로 파일을 식별하는 정수값(Integer Value)인 fd가 반환된다. 이 fd는 열린 lab1.txt 파일을 가리키는 역할을 한다.

이후 write() 함수는 파일 이름이 아니라 fd를 기준으로 데이터를 기록한다. 즉, lab1.txt라는 이름을 직접 사용하는 것이 아니라, open()을 통해 얻은 fd를 이용해 해당 파일에 데이터를 쓰는 방식이다.

마지막으로 close() 함수를 호출하면 파일 사용이 끝났음을 운영체제(Operating System)에 알리고, 파일과 관련된 자원(Resource)을 반환한다.

정리하면 파일 접근 흐름은 open() → fd 반환 → write(fd) → close(fd) 순서로 이루어진다.

close()를 호출하지 않으면 열린 파일과 관련된 자원이 계속 유지될 수 있다. 따라서 파일 사용이 끝나면 close(fd)를 통해 파일을 닫는 것이 중요하다.

File Descriptor Execution Result(파일 디스크립터 실행 결과)

실행 결과를 보면 fd 값이 3으로 출력된 것을 확인할 수 있다. 이 값은 운영체제(Operating System)가 해당 파일에 할당한 파일 디스크립터 번호(File Descriptor Number)이다.

일반적으로 파일 디스크립터 0, 1, 2는 미리 정해진 용도로 사용된다. 0은 표준 입력(Standard Input), 1은 표준 출력(Standard Output), 2는 표준 오류(Standard Error)를 의미한다.

따라서 프로그램에서 새 파일을 열면 보통 그다음 번호인 3부터 파일 디스크립터가 할당된다고 이해할 수 있다.

이후 write() 함수를 통해 두 개의 문자열이 lab1.txt 파일에 기록된다. 마지막으로 close()가 호출되면서 파일이 정상적으로 닫히고, 관련 자원(Resource)이 반환된다.

생성된 lab1.txt 파일을 열어보면 두 문자열이 순서대로 저장되어 있는 것을 확인할 수 있다. 즉, 프로그램은 파일 이름이 아니라 fd 값을 기준으로 파일에 데이터를 쓰고 닫는 과정을 수행한 것이다.

fd 값이 항상 반드시 3으로 고정되는 것은 아니다. 이미 다른 파일이나 자원이 열려 있다면 4, 5처럼 다른 번호가 할당될 수 있다. 중요한 점은 0, 1, 2가 표준 입출력용으로 예약되어 있고, 새로 여는 파일은 사용 가능한 가장 작은 fd 번호를 받는다는 것이다.

Offset-Based File Access(오프셋 기반 파일 접근)

두 번째 실습에서는 파일의 현재 위치(Current Position), 즉 오프셋(Offset)을 기준으로 파일 접근이 이루어지는 과정을 살펴본다.

write()를 수행하면 현재 오프셋 위치에 데이터가 기록되고, 기록이 끝난 뒤 오프셋은 자동으로 다음 위치로 이동한다. 따라서 별도의 위치를 지정하지 않으면 데이터는 기존 내용 뒤에 계속 이어서 기록된다.

하지만 특정 위치에 데이터를 기록하거나, 파일 중간에 있는 내용을 읽고 싶은 경우에는 lseek() 함수를 사용한다. lseek()는 파일의 오프셋을 원하는 위치로 직접 이동시키는 역할을 한다.

결국 파일의 읽기(Read)와 쓰기(Write) 결과는 현재 오프셋이 어디에 위치해 있는지에 따라 결정된다고 이해할 수 있다.

오프셋(Offset)은 열린 파일 안에서 “다음에 읽거나 쓸 위치”를 의미한다. 같은 파일이라도 파일 디스크립터(File Descriptor, fd)를 어떻게 열었는지에 따라 오프셋이 따로 관리될 수 있다.

File Offset and lseek()(파일 오프셋과 lseek())

핵심 코드에서 먼저 다음과 같이 문자열을 파일에 기록한다.

write(fd, "ABCDEFGH\n", 9);

이 코드는 ABCDEFGH와 줄바꿈 문자(Newline)를 포함해 총 9바이트(Byte)를 파일에 저장한다. 이 상태에서 파일에는 문자열이 순서대로 기록된다.

그다음 lseek() 함수가 사용된다.

lseek(fd, 2, SEEK_SET);

여기서 SEEK_SET은 파일의 시작 위치(Start)를 기준으로 한다는 의미이다. 따라서 이 코드는 파일의 처음부터 2바이트 이동한 위치로 파일 오프셋(Offset)을 옮기는 동작이다.

즉, 파일의 처음으로 돌아가는 것이 아니라 파일 중간 위치로 이동하는 것이다.

이후 다음 코드가 실행된다.

write(fd, "XXX", 3);

이 상태에서 "XXX"를 기록하면 기존 데이터가 뒤로 밀리는 것이 아니라, 현재 오프셋 위치부터 기존 내용을 덮어쓰기(Overwrite) 한다.

처음 파일 내용이 다음과 같았다면,

ABCDEFGH

인덱스 기준으로 A는 0번, B는 1번, C는 2번 위치에 있다. lseek(fd, 2, SEEK_SET)은 2번 위치인 C로 이동한다는 의미이다.

따라서 "XXX"를 쓰면 기존의 CDE가 XXX로 덮어쓰기 되어 최종 결과는 다음과 같이 된다.

ABXXXFGH

즉, lseek()는 파일의 현재 위치를 이동시키고, 이후의 write()는 그 위치부터 데이터를 덮어쓴다고 이해하면 된다.

lseek(fd, 2, SEEK_SET)에서 2는 “두 번째 글자”가 아니라 “파일 시작 지점에서 2바이트 떨어진 위치”를 의미한다. 문자열 인덱스가 0부터 시작하기 때문에 실제로는 세 번째 문자 위치인 C에 해당한다.

File Offset and lseek() Concept

(파일 오프셋과 lseek()의 개념)

파일(File)에는 항상 현재 접근 위치(Current Position)인 오프셋(Offset)이 존재한다. read()와 write() 연산은 이 오프셋을 기준으로 수행된다.

파일을 읽거나 쓰면 오프셋은 작업이 끝난 위치 다음으로 자동 이동한다. 따라서 별도로 위치를 지정하지 않으면 파일은 현재 위치부터 계속 이어서 처리된다.

원하는 위치에서 파일을 읽거나 쓰고 싶다면 lseek() 함수를 사용해 오프셋을 직접 이동시킬 수 있다.

lseek()에서 기준이 되는 값에는 SEEK_SET, SEEK_CUR, SEEK_END가 있다. SEEK_SET은 파일의 시작 위치, SEEK_CUR은 현재 위치, SEEK_END는 파일의 끝을 기준으로 오프셋을 이동한다.

중요한 점은 lseek() 자체가 파일 내용을 수정하는 함수가 아니라는 것이다. lseek()는 파일의 접근 위치만 바꾸며, 실제 데이터 변경은 이후에 수행되는 read()나 write()에 의해 이루어진다.

lseek()는 파일 포인터(File Pointer)의 위치를 이동시키는 함수라고 이해하면 쉽다. 다만 여기서 말하는 포인터는 메모리 주소 포인터가 아니라, 파일 안에서 다음 작업이 이루어질 위치를 의미한다.

Overwriting Data with lseek()(특정 위치 이동 후 데이터 덮어쓰기)

이 예제는 파일의 특정 위치로 이동한 뒤 데이터를 덮어쓰는 과정을 확인하는 코드이다.

먼저 open()을 통해 lab2.txt 파일을 연다. 이후 첫 번째 write()를 수행하면 문자열이 파일에 순서대로 기록된다.

그다음 lseek()를 사용해 파일의 시작 위치(Start)를 기준으로 2번 위치로 이동한다. 이때 오프셋(Offset)이 파일의 중간 위치로 변경된다.

이 상태에서 두 번째 write()를 수행하면 기존 데이터를 뒤로 밀어 넣는 것이 아니라, 현재 오프셋 위치인 2번 위치부터 덮어쓰기(Overwrite)가 이루어진다.

마지막으로 다시 lseek()를 사용해 파일의 처음으로 이동한 뒤, read()를 통해 변경된 파일 내용을 확인한다.

즉, 이 예제는 lseek()로 파일의 접근 위치를 이동시키고, 그 위치에서 write()를 수행하면 기존 데이터가 덮어쓰기 된다는 점을 보여준다.

write()는 삽입(Insert)이 아니라 덮어쓰기(Overwrite) 방식으로 동작한다. 따라서 중간 위치에서 데이터를 쓰면 기존 내용이 뒤로 밀리는 것이 아니라, 해당 위치의 데이터가 새 데이터로 바뀐다.

lseek() Execution Result(lseek() 실행 결과)

파일의 실행 결과를 보면 기존 내용이 ABCDEFGH에서 ABXXFGH로 변경된 것을 확인할 수 있다.

처음에는 파일에 ABCDEFGH가 순서대로 저장되어 있었다. 이후 lseek()를 통해 파일의 시작을 기준으로 2번 위치로 이동한 뒤, XX를 기록하면서 기존의 CD 부분이 덮어쓰기 된 것이다.

여기서 중요한 점은 lseek()가 기존 데이터를 뒤로 밀어내는 기능이 아니라는 것이다. lseek()는 파일의 현재 접근 위치(Offset)를 이동시키는 역할만 한다. 이후 write()가 실행되면 현재 오프셋 위치부터 기존 데이터가 덮어쓰기(Overwrite) 된다.

따라서 파일은 단순히 끝에만 이어서 기록되는 구조가 아니라, 현재 오프셋(Offset)을 기준으로 읽기(Read)와 쓰기(Write)가 수행되는 구조라고 이해할 수 있다.

결과가 ABXXFGH라면 실제로는 2바이트인 XX가 기록된 경우에 해당한다. 만약 2번 위치에서 XXX처럼 3바이트를 기록했다면 기존의 CDE가 덮어쓰기 되어 결과는 ABXXXFGH가 된다.

Descriptor Sharing with dup()(디스크립터 공유)

이번 실습은 파일 디스크립터(File Descriptor, fd)를 어떻게 생성하느냐에 따라 파일 접근 방식이 달라지는 것을 확인하는 내용이다.

먼저 open()을 두 번 호출하면 서로 다른 fd가 생성된다. 이 경우 각 fd는 독립적인 파일 상태(File State)와 오프셋(Offset)을 가진다. 따라서 한 fd에서 파일 위치가 이동하더라도 다른 fd에는 영향을 주지 않는다.

반면 dup()을 사용하면 기존 fd를 복제하지만, 내부적으로는 같은 열린 파일 상태(Open File Description)를 공유한다. 이 경우 파일 위치를 나타내는 오프셋(Offset)도 함께 공유된다.

따라서 한쪽 fd에서 read(), write(), lseek() 등을 수행해 오프셋이 변경되면, 다른 fd에도 그 변화가 영향을 미친다.

결국 중요한 것은 fd 값 자체가 아니라, 두 fd가 내부적으로 같은 파일 상태를 공유하는지 여부이다.

open()을 두 번 호출하면 같은 파일을 열더라도 서로 독립적인 열린 파일 상태(Open File Description)가 만들어진다.

하지만 dup()은 fd 번호만 새로 만들고, 기존 fd가 가리키던 열린 파일 상태를 함께 사용한다. 이 차이는 파일 오프셋(Offset) 공유 여부를 이해하는 데 중요한 부분이므로 기억해두는 것이 좋다.

dup() Descriptor Sharing Example

핵심 코드를 보면 다음과 같이 dup()을 사용한다.

fd3 = dup(fd1);

dup(fd1)은 기존 파일 디스크립터(File Descriptor)인 fd1을 복제하여 새로운 파일 디스크립터 fd3을 생성한다. 이때 fd1과 fd3은 번호는 다르지만, 내부적으로는 같은 열린 파일 상태(Open File Description)를 공유한다.

따라서 두 fd는 같은 파일 오프셋(Offset)도 공유한다.

예를 들어 다음 코드가 실행된다고 하자.

write(fd1, "A", 1);

처음 오프셋이 0인 상태에서 fd1을 통해 "A"를 1바이트 기록하면, 0번 위치에 A가 저장되고 오프셋은 1번 위치로 이동한다.

이후 fd3을 통해 다음 코드가 실행된다.

write(fd3, "B", 1);

fd3도 fd1과 같은 오프셋을 공유하기 때문에, 현재 오프셋인 1번 위치에 B가 기록된다.

즉, 서로 다른 fd를 사용하더라도 dup()으로 생성된 fd들은 같은 파일 상태와 오프셋을 공유하므로, 하나의 파일에 이어서 기록되는 것처럼 동작한다.

중요한 점은 fd1과 fd3의 숫자값이 같은 것이 아니라, 두 fd가 같은 열린 파일 상태(Open File Description)를 가리킨다는 것이다.

그래서 dup()으로 복제된 fd 사이에서는 오프셋 변화가 서로 영향을 준다. 이 부분은 파일 디스크립터 공유를 이해하는 데 중요한 특징이므로 기억해두는 것이 좋다.

Descriptor Sharing with dup()

dup()은 기존 파일 디스크립터(File Descriptor)를 복제해서 새로운 fd를 생성하는 함수이다.

이때 단순히 fd 번호만 복사되는 것이 아니라, 동일한 열린 파일 상태(Open File Description)를 함께 공유한다. 따라서 파일의 현재 위치를 나타내는 오프셋(Offset)도 함께 공유된다.

예를 들어 한쪽 fd에서 write()를 수행하면 오프셋이 이동하고, 다른 fd에서도 그 이동된 오프셋을 기준으로 이어서 기록된다. 즉, 서로 다른 fd를 사용하더라도 같은 파일 상태를 공유하기 때문에 하나의 흐름처럼 동작한다.

반면 open()을 두 번 호출하면 같은 파일을 열더라도 각각 독립적인 파일 상태를 가진다. 이 경우 오프셋도 따로 관리되므로, 한쪽 fd의 위치 변화가 다른 fd에 영향을 주지 않는다.

결국 중요한 것은 fd 값 자체가 아니라, 내부적으로 파일 상태를 공유하는지 여부이다. 이 부분은 dup()과 open()의 차이를 이해하는 데 중요한 특징이므로 기억해두는 것이 좋다.

dup()으로 생성된 fd는 기존 fd와 같은 열린 파일 상태(Open File Description)를 가리킨다. 그래서 오프셋(Offset)뿐만 아니라 파일 상태 플래그(File Status Flags)도 공유될 수 있다. 다만 fd 번호 자체와 fd별 설정은 서로 다를 수 있다.

File Descriptor and Offset Example

이 예제는 파일 디스크립터(File Descriptor)에 따라 오프셋(Offset)이 어떻게 달라지는지 확인하는 실습이다.

먼저 fd1은 open() 함수를 통해 lab3.txt 파일을 한 번 연다. 그리고 fd2도 마찬가지로 open() 함수를 통해 같은 lab3.txt 파일을 다시 연다.

즉, open()을 두 번 호출하면 같은 파일이라도 서로 독립적인 열린 파일 상태(Open File Description)를 가지게 된다. 따라서 fd1과 fd2의 오프셋(Offset)은 각각 따로 관리된다.

반면 fd3은 dup() 함수를 통해 fd1을 복제해서 만들어진다. 이 경우 fd1과 fd3은 fd 번호는 다르지만, 동일한 열린 파일 상태를 공유한다. 따라서 두 fd는 같은 오프셋을 함께 사용한다.

그다음 코드에서는 write()를 수행한 뒤, lseek()를 통해 off1, off2, off3 값을 확인한다. 이 값들은 각각 fd1, fd2, fd3의 현재 위치, 즉 오프셋을 나타낸다.

정리하면 fd1과 fd3은 dup()으로 연결되어 같은 오프셋을 공유하고, fd2는 같은 파일을 열었더라도 별도로 open()된 것이기 때문에 독립적인 오프셋을 가진다.

lseek(fd, 0, SEEK_CUR)을 사용하면 현재 오프셋(Current Offset)을 확인할 수 있다. 여기서 SEEK_CUR은 현재 위치를 기준으로 한다는 뜻이고, 이동 값이 0이므로 위치를 바꾸지 않고 현재 위치만 확인하는 방식이다.

dup() Execution Result

실행 결과를 보면 먼저 fd1을 통해 A를 기록했을 때, fd1의 오프셋(Offset)이 1로 이동한다.

이때 fd3도 함께 1로 이동한 것을 확인할 수 있다. 이는 fd3가 dup(fd1)을 통해 생성되었기 때문에, fd1과 동일한 열린 파일 상태(Open File Description)를 공유하기 때문이다.

반면 fd2는 같은 lab3.txt 파일을 가리키더라도 open()을 통해 별도로 열린 파일 디스크립터(File Descriptor)이므로, 오프셋이 0으로 유지된다.

즉, 실행 결과를 통해 fd1과 fd3은 같은 오프셋을 공유하고, fd2는 독립적으로 동작한다는 것을 확인할 수 있다.

dup()으로 생성된 fd는 기존 fd와 같은 오프셋(Offset)을 공유한다. 반면 같은 파일이라도 open()을 다시 호출해서 얻은 fd는 독립적인 오프셋을 가진다. 이 차이는 파일 디스크립터 공유를 이해하는 데 중요한 부분이므로 기억해두는 것이 좋다.

dup() Code Explanation 2

그다음 코드에서 fd2를 기준으로 다음 쓰기 작업을 수행한다.

write(fd2, "B", 1);

fd2는 open()을 통해 별도로 생성된 파일 디스크립터(File Descriptor)이기 때문에, fd1, fd3와는 독립적인 오프셋(Offset)을 가진다. 따라서 이 작업을 수행하면 fd2의 오프셋만 1로 이동하고, fd1과 fd3의 오프셋은 그대로 유지된다.

마지막으로 다음 코드가 실행된다.

write(fd3, "C", 1);

fd3는 dup(fd1)을 통해 생성되었기 때문에 fd1과 같은 열린 파일 상태(Open File Description)를 공유한다. 따라서 fd3를 통해 쓰기 작업을 수행하면 fd3의 오프셋뿐만 아니라 fd1의 오프셋도 함께 이동한다.

결국 이 예제는 open()으로 생성된 fd2는 독립적으로 동작하고, dup()으로 연결된 fd1과 fd3는 오프셋을 포함한 파일 상태(File State)를 공유한다는 점을 보여준다.

같은 파일을 가리키더라도 open()으로 따로 열었는지, dup()으로 복제했는지에 따라 오프셋 공유 여부가 달라진다. 이 부분은 파일 디스크립터(File Descriptor)의 동작을 이해하는 데 중요한 내용이므로 기억해두는 것이 좋다.

File State Sharing with fork()(fork()에서의 파일 상태 공유)

이번에는 서로 다른 프로세스(Process)에서 파일 상태(File State)가 어떻게 동작하는지 살펴보는 예제이다.

먼저 fork()가 수행되면 자식 프로세스(Child Process)는 부모 프로세스(Parent Process)의 파일 디스크립터(File Descriptor)를 그대로 상속받는다.

이때 단순히 fd 값만 복사되는 것이 아니라, 동일한 열린 파일 상태(Open File Description)를 공유한다. 따라서 한쪽 프로세스에서 write()를 수행하면 오프셋(Offset)이 변경되고, 이 변화는 다른 프로세스에도 반영된다.

즉, 서로 다른 프로세스라 하더라도 같은 열린 파일 상태를 공유한다면 하나의 파일에 이어서 접근하는 것처럼 동작한다.

결국 파일 상태는 각 프로세스가 따로 관리하는 것이 아니라, 커널(Kernel) 내부에서 관리된다. 여러 프로세스는 이 커널의 파일 상태를 함께 공유할 수 있다.

fork() 후 부모와 자식 프로세스는 같은 열린 파일 상태(Open File Description)를 공유하므로 오프셋도 공유된다. 이 부분은 dup()과 비슷하게 이해할 수 있으며, 파일 공유 동작을 이해하는 데 중요한 내용이므로 기억해두는 것이 좋다.

File Sharing with fork()(fork()에서의 파일 공유)

이번 예제는 서로 다른 프로세스(Process)에서 파일 상태(File State)가 어떻게 공유되는지 확인하는 실습이다.

fork()는 이전 주차에서도 사용했기 때문에 기본 동작은 익숙할 수 있다. 하지만 여기서의 핵심은 프로세스를 나누는 동작 자체가 아니라, fork() 이후 부모 프로세스(Parent Process)와 자식 프로세스(Child Process)가 파일 자원(File Resource)을 어떻게 공유하는지 확인하는 것이다.

코드를 보면 fork() 이후 자식 프로세스는 "CHILD\n"를 파일에 기록하고, 부모 프로세스는 "PARENT\n"를 파일에 기록한다.

이때 자식 프로세스는 부모 프로세스의 파일 디스크립터(File Descriptor)를 그대로 상속받는다. 단순히 fd 값만 복사되는 것이 아니라, 동일한 열린 파일 상태(Open File Description)를 공유한다.

따라서 두 프로세스의 write()는 서로 완전히 독립적으로 수행되는 것이 아니라, 하나의 파일에 이어서 기록되는 형태로 동작한다. 한쪽 프로세스에서 write()를 수행하면 오프셋(Offset)이 이동하고, 이 변경된 오프셋은 다른 프로세스에도 반영된다.

즉, 이전에는 fork()의 프로세스 생성에 초점을 두었다면, 이번 실습에서는 fork() 이후 파일 상태가 어떻게 공유되는지를 확인하는 것이 핵심이다.

fork() 이후 부모와 자식은 같은 열린 파일 상태(Open File Description)를 공유하기 때문에 오프셋(Offset)도 공유한다. 이 부분은 dup()으로 생성된 fd가 오프셋을 공유하는 것과 비슷하게 이해할 수 있다.

다만 부모와 자식 중 어느 쪽이 먼저 실행될지는 스케줄링(Scheduling)에 따라 달라질 수 있다. 그래서 파일에는 두 문자열이 순차적으로 기록되지만, 실행 순서에 따라 CHILD가 먼저 기록될 수도 있고 PARENT가 먼저 기록될 수도 있다.

File Sharing with fork() Code Example

이 코드는 fork() 이후 부모 프로세스(Parent Process)와 자식 프로세스(Child Process)가 파일 상태(File State)를 어떻게 공유하는지 확인하는 예제이다.

먼저 open()을 통해 lab4.txt 파일을 연다. 이때 파일 디스크립터(File Descriptor, fd)가 생성되고, 이후 fork()가 수행되면서 부모와 자식 프로세스로 나뉜다.

fork() 이후 자식 프로세스는 write(fd, "CHILD\n", 6)을 수행하여 파일에 CHILD를 기록한다. 부모 프로세스는 wait(NULL)을 통해 자식 프로세스가 먼저 실행되도록 기다린 뒤, write(fd, "PARENT\n", 7)을 수행한다.

이때 자식 프로세스는 부모 프로세스의 fd를 상속받기 때문에, 두 프로세스는 동일한 열린 파일 상태(Open File Description)와 오프셋(Offset)을 공유한다.

따라서 자식이 먼저 CHILD를 기록하면 오프셋이 그 다음 위치로 이동하고, 이후 부모가 같은 오프셋을 기준으로 PARENT를 이어서 기록한다. 즉, 서로 다른 프로세스라도 같은 파일 상태를 공유하면 하나의 파일에 순서대로 이어 쓰는 것처럼 동작한다.

정리하면 이 예제의 핵심은 fork() 이후 부모와 자식 프로세스가 파일 디스크립터를 상속받고, 동일한 열린 파일 상태와 오프셋을 공유한다는 점이다.

첨부된 코드에서는 open()이 먼저 실행된 뒤 fork()가 수행된다. 그래서 자식 프로세스가 부모의 fd를 상속받을 수 있다.

또한 부모 프로세스에서 wait(NULL)을 사용했기 때문에 자식이 먼저 기록하고, 그다음 부모가 기록된다. 만약 wait()가 없다면 부모와 자식 중 누가 먼저 실행될지는 스케줄링(Scheduling)에 따라 달라지게 된다.

fork() File Sharing Execution Result

프로세스와 파일 공유(fork) 실행 결과를 보면, 화면에는 자식 프로세스(Child Process)와 부모 프로세스(Parent Process)의 완료 메시지가 출력된다.

lab4.txt 파일의 내용을 확인하면 자식 프로세스가 먼저 CHILD를 기록하고, 그다음 부모 프로세스가 PARENT를 이어서 기록한 것을 볼 수 있다.

이때 두 프로세스는 같은 파일 디스크립터(File Descriptor)를 상속받았기 때문에 동일한 열린 파일 상태(Open File Description)를 공유한다. 따라서 오프셋(Offset)도 함께 공유된다.

자식 프로세스가 먼저 파일에 데이터를 기록하면 오프셋이 그 다음 위치로 이동하고, 부모 프로세스는 이동된 오프셋을 기준으로 데이터를 이어서 기록한다.

즉, 부모와 자식 프로세스가 각각 파일을 따로 쓰는 것이 아니라, 하나의 파일에 순차적으로 기록되는 구조로 이해할 수 있다.

이 예제에서는 부모 프로세스가 wait()를 사용하기 때문에 자식 프로세스가 먼저 실행된 뒤 부모 프로세스가 기록한다. 만약 wait()가 없다면 실행 순서는 운영체제의 스케줄링(Scheduling)에 따라 달라지게 된다.

Summary of File Access Structure(파일 접근 구조 정리)

파일 접근(File Access)은 파일 이름(File Name)이 아니라 파일 디스크립터(File Descriptor, fd)를 통해 이루어진다. 프로그램은 open()을 통해 파일을 열고 fd를 반환받은 뒤, 이후의 read(), write(), close() 작업을 fd 기준으로 수행한다.

또한 파일 내부에서 읽고 쓰는 현재 위치는 오프셋(Offset)으로 관리된다. write()나 read()가 수행되면 오프셋은 자동으로 이동하며, lseek()를 사용하면 원하는 위치로 오프셋을 직접 이동시킬 수 있다.

이번 실습에서는 dup()과 fork()를 통해 파일 디스크립터와 오프셋이 여러 주체 간에 공유될 수 있다는 점도 확인했다. dup()으로 생성된 fd는 기존 fd와 동일한 열린 파일 상태(Open File Description)를 공유하고, fork() 이후 부모와 자식 프로세스도 같은 열린 파일 상태를 공유할 수 있다.

따라서 파일은 단순히 데이터가 저장된 공간이 아니라, 파일 디스크립터(fd), 오프셋(Offset), 커널 내부의 열린 파일 상태(Open File Description)까지 함께 포함된 하나의 상태 객체(State Object)로 이해할 수 있다.

파일 이름(File Name)은 파일을 처음 찾을 때 사용되고, 파일을 연 뒤에는 fd를 통해 접근한다. 중요한 점은 fd 번호 자체보다, 그 fd가 어떤 열린 파일 상태(Open File Description)를 가리키고 있는지이다. 이 부분은 open(), dup(), fork()의 차이를 이해하는 핵심이므로 기억해두는 것이 좋다.

Ubuntu Practice Results

File Descriptor Practice Result (파일 디스크립터 실습 결과)

실습 결과를 보면 fd = 3으로 출력된 것을 확인할 수 있다. 이 값은 open()을 통해 lab1.txt 파일을 열었을 때 운영체제(Operating System)가 반환한 파일 디스크립터(File Descriptor) 번호이다.

버추얼머신(Virtual Machine)의 sf_shared 폴더를 확인하면 lab1.txt 파일이 생성되어 있는 것을 볼 수 있다. 파일 안에는 다음과 같이 두 개의 문자열이 순서대로 기록되어 있다.

Operating Systems
File Descriptor Test

겉으로 보기에는 단순히 파일에 문자열을 쓰는 작업처럼 보인다. 하지만 실제 내부에서는 파일 이름(File Name)이 아니라 파일 디스크립터(fd)를 기준으로 파일에 접근하고 데이터를 기록한다.

즉, open()을 통해 파일이 생성되고, write()를 통해 데이터가 기록되며, 마지막으로 close()를 통해 파일 사용이 종료되고 관련 자원(Resource)이 반환된다.

이 실습을 통해 파일은 실행 중에 이름이 아니라 fd를 기준으로 관리되며, 파일 접근은 시스템 호출(System Call)을 통해 이루어진다는 것을 확인할 수 있었다.

lseek() Practice Result (lseek() 실습 결과)

두 번째 실습은 파일의 특정 위치로 이동한 뒤 데이터를 덮어쓰는 과정을 확인하는 실습이다.

실행 결과를 보면 처음에는 ABCDEFGH가 파일에 저장되어 있었지만, lseek()를 통해 2번 위치로 이동한 뒤 XXX를 기록하면서 기존의 일부 데이터가 덮어쓰기 된 것을 확인할 수 있었다.

이후 lab2.txt 파일이 생성되었는지 sf_shared 폴더에서 확인할 수 있었고, 파일 안의 문자열이 중간 위치부터 변경된 것도 확인할 수 있었다.

겉으로 보기에는 문자열이 단순히 수정된 것처럼 보이지만, 실제로는 오프셋(Offset)을 이동한 뒤 해당 위치에서 write()가 수행된 결과이다.

중요한 점은 데이터가 뒤로 밀리는 것이 아니라, 현재 오프셋 위치부터 그대로 덮어쓰기(Overwrite) 된다는 것이다. 이 실습을 통해 파일 접근은 단순한 순차 구조가 아니라 오프셋을 기준으로 이루어지며, lseek()를 통해 파일 내 위치를 직접 제어할 수 있다는 것을 확인할 수 있었다.

lseek()는 파일 내용을 직접 바꾸는 함수가 아니라, 파일의 현재 접근 위치(Current Offset)를 이동시키는 함수이다. 실제 데이터 변경은 그 이후에 실행되는 write()에 의해 이루어진다.

dup() Practice Result (dup() 실습 결과)

세 번째 실습은 파일 디스크립터(File Descriptor)의 생성 방식에 따라 오프셋(Offset)이 어떻게 달라지는지 확인하는 예제였다.

실행 결과를 보면 A 기록 후에는 fd1과 fd3의 오프셋이 함께 1로 이동하고, fd2는 0으로 유지된다. 이는 fd3가 dup(fd1)으로 생성되어 fd1과 동일한 열린 파일 상태(Open File Description)를 공유하기 때문이다.

그다음 fd2에서 B를 기록하면 fd2의 오프셋만 1로 이동한다. fd2는 같은 lab3.txt 파일을 열었지만, open()을 통해 별도로 생성되었기 때문에 독립적인 오프셋을 가진다.

마지막으로 fd3에서 C를 기록하면 fd3와 파일 상태를 공유하는 fd1의 오프셋도 함께 2로 이동한다. 반면 fd2는 독립적으로 동작한다.

실제로 lab3.txt 파일의 내용이 BC로 나타나는 것은, fd2가 독립적인 오프셋 0번 위치에서 B를 기록하면서 앞부분을 덮어쓰고, 이후 fd3가 공유된 오프셋 위치에서 C를 이어서 기록했기 때문이다.

이 실습을 통해 파일 디스크립터는 단순한 정수값이 아니라, 내부적으로 어떤 열린 파일 상태를 공유하는지에 따라 동작이 달라진다는 것을 확인할 수 있었다.

open()을 다시 호출해 생성한 fd는 같은 파일을 가리키더라도 독립적인 오프셋을 가진다. 반면 dup()으로 생성한 fd는 기존 fd와 열린 파일 상태(Open File Description)를 공유하므로 오프셋도 함께 이동한다. 이 차이는 중요한 부분이므로 기억해두는 것이 좋다.

File Sharing with fork() Practice Result

이 예제는 fork() 이후 부모 프로세스(Parent Process)와 자식 프로세스(Child Process)가 파일을 어떻게 공유하는지 확인하는 실습이었다.

실행 결과를 보면 화면에는 child: write complete, parent: write complete 메시지가 출력된다. 또한 lab4.txt 파일이 생성되었고, 파일 내용을 확인하면 먼저 CHILD가 기록되고 그다음 PARENT가 이어서 기록된 것을 볼 수 있다.

겉으로는 부모 프로세스와 자식 프로세스가 각각 파일에 쓰는 것처럼 보인다. 하지만 실제로는 두 프로세스가 같은 파일 디스크립터(File Descriptor)를 상속받고, 동일한 열린 파일 상태(Open File Description)와 오프셋(Offset)을 공유하면서 하나의 파일에 순차적으로 기록하는 구조이다.

이 실습에서는 wait()를 사용했기 때문에 자식 프로세스가 먼저 실행되어 CHILD를 기록하고, 이후 부모 프로세스가 PARENT를 이어서 기록되었다.

이 실습을 통해 fork() 이후에도 파일 상태(File State)는 공유될 수 있으며, 여러 프로세스(Process)가 하나의 파일을 함께 사용할 수 있다는 점을 확인할 수 있었다.

fork() 이후 부모와 자식은 같은 열린 파일 상태(Open File Description)를 공유하므로 오프셋(Offset)도 함께 공유된다. 따라서 한쪽 프로세스가 파일에 쓰면 오프셋이 이동하고, 다른 프로세스는 이동된 위치부터 이어서 작업하게 된다.

다만 wait()가 없다면 부모와 자식 중 누가 먼저 실행될지는 스케줄링(Scheduling)에 따라 달라질 수 있다.

AI 소프트웨어 테스트 개요 (Overview of AI Software Testing)

이번 강의에서는 AI 소프트웨어 테스트(AI Software Testing)와 관련하여 세 가지 핵심 내용을 간단히 정리한다. 첫 번째는 AI 소프트웨어 테스트가 무엇인지, 그리고 왜 필요한지를 이해하는 것이다. AI 소프트웨어는 일반 소프트웨어와 달리 데이터(Data)와 모델(Model)을 기반으로 동작하는 경우가 많기 때문에, 입력 조건이나 학습 데이터에 따라 결과가 달라질 수 있다. 따라서 AI 소프트웨어가 기대한 대로 동작하는지 확인하고, 예측 결과의 정확성(Accuracy), 신뢰성(Reliability), 안정성(Safety)을 검증하는 테스트 과정이 필요하다.

두 번째는 AI 소프트웨어에도 적용할 수 있는 테스트 기법(Test Techniques)이 있다는 점이다. 일반 소프트웨어 테스트에서 사용하는 기능 테스트(Functional Testing), 성능 테스트(Performance Testing), 회귀 테스트(Regression Testing)와 같은 개념은 AI 소프트웨어에도 활용될 수 있다. 다만 AI 소프트웨어는 결과가 항상 고정적이지 않을 수 있기 때문에, 테스트할 때 데이터 품질(Data Quality), 모델의 예측 성능(Prediction Performance), 편향성(Bias), 예외 상황 처리(Exception Handling) 등을 함께 고려해야 한다.

세 번째는 테스트를 더 효율적으로 수행하기 위한 가상 기반 소프트웨어 테스트 환경(Virtual Software Testing Environment)에 대한 이해이다. 실제 환경에서 AI 소프트웨어를 테스트하기 어렵거나 비용이 많이 드는 경우, 시뮬레이션(Simulation)이나 가상 환경(Virtual Environment)을 활용할 수 있다. 이러한 환경은 다양한 조건을 반복적으로 실험할 수 있게 해주며, 특히 자율주행(Autonomous Driving), 로봇(Robotics), 스마트 시스템(Smart Systems)처럼 실제 테스트가 위험하거나 복잡한 분야에서 유용하다.

정리하면, 이번 강의의 목표는 AI 소프트웨어 테스트의 필요성, AI 소프트웨어에 적용 가능한 테스트 기법, 그리고 가상 기반 테스트 환경의 개념을 이해하는 것이다. AI 소프트웨어는 데이터와 모델에 크게 의존하므로, 단순히 프로그램이 실행되는지만 확인하는 것이 아니라 결과의 품질과 신뢰성을 함께 검증하는 것이 중요하다.

AI 소프트웨어 테스트의 정의 (Definition of AI Software Testing)

AI 소프트웨어 테스트(AI Software Testing)의 개념은 기존에 학습한 소프트웨어 테스트(Software Testing)의 기본 목적에서 출발할 수 있다. 일반적인 소프트웨어 테스트의 목적은 개발된 소프트웨어가 요구사항(Requirements), 아키텍처(Architecture), 설계(Design)를 만족하는지 확인하는 것이다. 만약 소프트웨어가 정해진 요구사항이나 설계를 만족하지 못한다면, 이를 결함(Defect)이라고 부른다. 따라서 테스트의 핵심 목적은 다양한 관점과 환경에서 소프트웨어를 실행하고 검증하여, 존재할 수 있는 결함을 최대한 많이 찾아내는 데 있다.

AI 소프트웨어 테스트도 이 기본 개념에서 크게 벗어나지 않는다. 기존의 소프트웨어 테스트 앞에 AI(Artificial Intelligence)라는 개념이 추가된 것으로 이해할 수 있다. 인공지능 기술(AI Technology)을 적용하여 학습이 완료된 모델(Trained Model)은 하나의 AI 소프트웨어(AI Software)로 볼 수 있다. 따라서 AI 소프트웨어 테스트란, 이 훈련 완료 모델이 요구사항을 충족하는지, 의도한 기능을 정상적으로 수행하는지, 그리고 실제 사용 환경에서 신뢰할 수 있는 결과를 내는지를 검증(Verification)하고 확인(Validation)하는 프로세스라고 할 수 있다.

즉, 기존 소프트웨어 테스트의 대상이 일반 프로그램에서 AI 모델(AI Model) 또는 AI 기반 소프트웨어(AI-based Software)로 바뀐 것이다. 이 테스트 프로세스를 통해 AI 모델의 정확도(Accuracy), 정밀성(Precision), 편향성(Bias) 등을 평가할 수 있다. AI 소프트웨어는 단순히 코드가 오류 없이 실행되는지만 보는 것이 아니라, 모델이 얼마나 올바른 판단을 내리는지, 특정 데이터나 사용자 집단에 대해 편향된 결과를 내지 않는지, 그리고 다양한 입력 상황에서도 안정적으로 동작하는지를 함께 확인해야 한다.

AI 소프트웨어 테스트 프로세스(AI Software Testing Process)는 기존 소프트웨어 개발에서 사용되는 V-Model의 흐름과도 연결된다. AI 소프트웨어 역시 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Test)의 단계를 거치며, AI 특성상 훈련 데이터 준비(Training Data Preparation), 모델 학습(Model Training), 모델 평가(Model Evaluation)와 같은 과정이 중요하게 포함된다. V-Model의 왼쪽 단계에서 정의한 요구사항과 데이터 준비 과정이 적절했는지를, 오른쪽 테스트 단계에서 검증하는 구조로 이해할 수 있다.

AI 소프트웨어는 일반 소프트웨어의 품질 특성(Quality Characteristics)도 가지고 있다. 예를 들어 기능 적합성(Functional Suitability), 성능 효율성(Performance Efficiency), 호환성(Compatibility), 사용성(Usability) 등이 이에 해당한다. AI 소프트웨어도 결국 사용자가 요구한 기능을 제공해야 하며, 효율적으로 동작하고, 다른 시스템과 잘 연동되며, 사용하기 쉬워야 한다.

하지만 AI 소프트웨어에는 일반 소프트웨어와 구분되는 고유한 품질 특성도 존재한다. 대표적으로 적응성(Adaptability), 자율성(Autonomy), 진화(Evolution), 유연성(Flexibility), 편향성(Bias) 등이 있다. AI 모델은 데이터와 환경에 따라 결과가 달라질 수 있고, 일부 시스템은 스스로 판단하거나 변화하는 상황에 적응해야 한다. 따라서 AI 소프트웨어 테스트는 이러한 고유한 특성이 실제로 적절하게 구현되어 있는지, 그리고 그 과정에서 위험하거나 부정확한 결과가 발생하지 않는지를 확인하는 것을 목표로 한다.

정리하면, AI 소프트웨어 테스트는 인공지능 기술이 적용된 모델이나 시스템이 요구사항을 만족하고 정상적으로 동작하는지 확인하는 테스트 프로세스이다. 기존 소프트웨어 테스트가 결함을 찾아내는 활동이었다면, AI 소프트웨어 테스트는 여기에 더해 모델의 정확도, 정밀성, 편향성, 적응성, 자율성 등 AI 고유의 품질 특성까지 함께 평가한다는 점에서 차이가 있다.

AI 소프트웨어 특성을 반영한 테스트 기법의 필요성

(Need for Test Techniques Reflecting AI Software Characteristics)

AI 소프트웨어(AI Software)는 일반 소프트웨어와 달리 모델(Model)이 훈련 데이터(Training Data)를 기반으로 학습하고, 새로운 입력에 대해 예측(Prediction)이나 판단(Decision)을 수행한다. 따라서 AI 소프트웨어를 테스트할 때는 단순히 프로그램이 실행되는지, 기능이 동작하는지만 확인하는 것으로는 충분하지 않다. 모델이 얼마나 정확하게 예측하는지, 결과가 얼마나 정밀한지, 특정 데이터나 사용자 집단에 대해 편향된 결과를 내지 않는지도 함께 확인해야 한다.

AI 모델의 성능은 훈련 데이터에 크게 의존한다. 훈련 데이터의 양이 부족하거나, 데이터가 편향되어 있거나, 실제 사용 환경을 충분히 반영하지 못하면 모델의 예측 결과도 부정확해질 수 있다. 이 때문에 AI 소프트웨어 테스트에서는 코드의 결함뿐만 아니라 데이터 품질(Data Quality), 데이터 편향(Data Bias), 모델 성능(Model Performance)도 중요한 평가 대상이 된다.

또한 AI 소프트웨어는 추론 과정(Inference Process)이 복잡하고, 경우에 따라 비결정적 동작(Non-deterministic Behavior)을 보일 수 있다. 비결정적 동작이란 같은 입력을 넣었을 때 항상 완전히 같은 결과가 나오지 않을 수 있다는 뜻이다. AI 모델은 학습 데이터, 학습 방식, 확률적 처리 방식, 실행 환경 등에 따라 결과가 달라질 수 있기 때문이다. 따라서 AI 소프트웨어 테스트에서는 하나의 입력에 대해 하나의 정답만 확인하는 방식보다, 허용 가능한 결과 범위(Acceptable Range)나 성능 기준(Performance Criteria)을 정해 평가하는 방식이 필요하다.

결국 AI 소프트웨어에는 기존 소프트웨어 테스트 기법만으로는 충분히 검증하기 어려운 부분이 있다. 기능 테스트(Functional Testing), 성능 테스트(Performance Testing), 회귀 테스트(Regression Testing)와 같은 기존 기법도 여전히 필요하지만, 여기에 더해 정확도 평가(Accuracy Evaluation), 정밀성 평가(Precision Evaluation), 편향성 테스트(Bias Testing), 데이터 품질 테스트(Data Quality Testing), 강건성 테스트(Robustness Testing)처럼 AI의 특성을 반영한 테스트 기법이 함께 사용되어야 한다.

정리하면, AI 소프트웨어 테스트는 일반 소프트웨어 테스트의 개념을 바탕으로 하지만, AI 모델의 데이터 의존성(Data Dependency), 예측 성능(Prediction Performance), 복잡한 추론 과정, 비결정적 동작 가능성 등을 추가로 고려해야 한다. 이러한 이유로 AI 소프트웨어의 특징을 반영한 별도의 테스트 기법이 필요하다.

성적관리 AI 소프트웨어에서 기존 테스트 기법 적용의 한계

(Limitations of Traditional Test Techniques in AI Grade Management Software)

기존의 성적관리 소프트웨어(Grade Management Software)는 요구사항(Requirements)이 비교적 명확하게 정해져 있다. 예를 들어 “0점 이상 70점 미만은 F”, “70점 이상 80점 미만은 C”, “80점 이상 90점 미만은 B”, “90점 이상 100점 이하는 A”와 같이 점수 구간과 등급 기준을 명확하게 정의할 수 있다. 이런 경우에는 요구사항을 기준으로 설계하고 구현한 뒤, 동등 분할 테스트(Equivalence Partitioning)나 경계값 분석(Boundary Value Analysis)을 적용하여 테스트 케이스(Test Case)를 만들 수 있다.

예를 들어 70점 이상 80점 미만 구간이 하나의 동등 분할 영역이라면, 이 구간 안의 대표값을 선택하여 테스트할 수 있다. 또한 69점, 70점, 79점, 80점처럼 등급이 바뀌는 경계값을 중심으로 테스트하면 요구사항이 제대로 구현되었는지 확인할 수 있다. 즉, 일반 소프트웨어에서는 요구사항이 명확하기 때문에 이를 기준으로 입력값을 나누고, 각 구간을 대표하는 테스트 데이터를 선정하는 방식이 효과적으로 사용될 수 있다.

하지만 성적관리 AI 소프트웨어(AI Grade Management Software)의 경우에는 상황이 달라질 수 있다. AI 소프트웨어는 사람이 직접 모든 규칙을 코드로 작성하는 것이 아니라, 주어진 훈련 데이터(Training Data)를 바탕으로 모델(Model)이 학습한다. 예를 들어 모델이 70점 이상 80점 미만, 80점 이상 90점 미만의 데이터만 학습한 상태라면, 모델은 이 두 점수 구간에 대해서는 비교적 잘 예측할 수 있을 수 있다. 그러나 50점대 점수나 90점 이상 100점 이하의 점수처럼 훈련 데이터에 충분히 포함되지 않은 입력이 들어오면, 모델이 정확한 결과를 예측하지 못할 가능성이 있다.

이것은 AI 모델이 훈련 데이터에 크게 의존하기 때문이다. 모델이 다양한 학생 그룹(Student Group), 다양한 점수 구간, 다양한 성적 패턴을 학습하지 못했다면, 새로운 학생 그룹이나 학습하지 않은 점수 범위에 대해서는 신뢰하기 어려운 결과를 낼 수 있다. 따라서 AI 소프트웨어 테스트에서는 단순히 입력값을 몇 개의 구간으로 나누어 테스트하는 것만으로는 충분하지 않을 수 있다. 훈련 데이터가 전체 상황을 충분히 대표하고 있는지, 특정 구간이나 집단에 치우쳐 있지 않은지, 새로운 입력에 대해서도 안정적인 예측을 할 수 있는지를 함께 확인해야 한다.

또한 AI 소프트웨어는 요구사항이 훈련 데이터에 따라 변하거나 불명확해질 수 있다는 특징이 있다. 일반 소프트웨어에서는 요구사항이 명확히 정의되어 있어야 동등 분할이나 경계값 분석을 적용하기 쉽다. 하지만 AI 소프트웨어는 모델이 데이터로부터 규칙을 학습하기 때문에, 사람이 사전에 모든 판단 기준을 명확하게 정의하기 어려운 경우가 많다. 이처럼 요구사항 자체가 데이터와 학습 결과에 따라 달라질 수 있다면, 기존의 동등 분할 테스트나 경계값 분석만으로는 충분한 테스트가 어렵다.

정리하면, 동등 분할 테스트(Equivalence Partitioning)와 경계값 분석(Boundary Value Analysis)은 요구사항이 명확한 일반 소프트웨어에서는 효과적인 테스트 기법이다. 그러나 AI 소프트웨어는 훈련 데이터에 따라 모델의 판단 기준이 형성되고, 학습하지 않은 데이터에 대해서는 예측 성능이 떨어질 수 있다. 따라서 AI 소프트웨어를 테스트할 때는 기존 테스트 기법뿐만 아니라 데이터 품질(Data Quality), 데이터 분포(Data Distribution), 편향성(Bias), 일반화 성능(Generalization Performance)을 함께 검증해야 한다.

비결정적 동작을 고려한 AI 소프트웨어 테스트 기법의 필요성

(Need for AI Testing Techniques Considering Non-deterministic Behavior)

AI 소프트웨어(AI Software)는 입력에 따라 결과가 달라질 수 있는 비결정적 동작(Non-deterministic Behavior)을 보일 수 있다. 일반 소프트웨어는 요구사항이 명확하게 정의되어 있으면, 같은 입력에 대해 항상 같은 결과가 나오는 것을 기대할 수 있다. 예를 들어 성적관리 소프트웨어에서 90점 이상 100점 이하의 점수를 입력하면 A가 나와야 한다는 요구사항이 있다면, 동등 분할 테스트(Equivalence Partitioning)를 통해 해당 구간의 대표값을 넣고 결과가 요구사항과 일치하는지 확인할 수 있다.

하지만 AI 소프트웨어는 같은 입력이나 비슷한 입력에 대해 항상 완전히 일관된 결과를 보장하기 어려울 수 있다. 모델(Model)이 훈련 데이터(Training Data)를 기반으로 확률적 예측(Probabilistic Prediction)을 수행하거나, 실행 환경과 학습 방식에 따라 결과가 달라질 수 있기 때문이다. 따라서 동등 클래스(Equivalence Class)의 대표값을 넣었을 때 항상 예상한 결과가 나오는지만 확인하는 기존 방식에는 한계가 있다. AI 소프트웨어에서는 결과가 요구사항에 맞는지만 보는 것이 아니라, 다양한 입력 상황에서도 모델이 안정적이고 신뢰할 수 있는 예측을 하는지 확인해야 한다.

예를 들어 이미지 분류 모델(Image Classification Model)을 테스트한다고 가정할 수 있다. 이 모델이 특정 이미지에만 의존하지 않고 다양한 이미지에 대해 골고루 예측할 수 있는지 확인하기 위해, 무작위로 생성된 이미지(Randomly Generated Images)를 입력하여 분류 정확도(Classification Accuracy)를 테스트할 수 있다. 이를 통해 모델이 훈련 데이터와 비슷한 이미지에만 잘 반응하는 것이 아니라, 새로운 입력 데이터에 대해서도 어느 정도 일반화(Generalization)할 수 있는지 확인할 수 있다.

또 다른 방법은 이미지에 노이즈(Noise)를 추가하여 테스트하는 것이다. 예를 들어 이미지의 픽셀값(Pixel Value)을 의도적으로 변경하거나, 이미지의 좌우 위치를 바꾸거나, 밝기와 대비를 조정할 수 있다. 이렇게 변형된 이미지를 입력했을 때 모델이 잘못된 분류를 하는지 확인하면, 모델의 강건성(Robustness)을 평가할 수 있다. 즉, 약간의 변화나 방해 요소가 있어도 모델이 안정적으로 올바른 결과를 내는지 확인하는 것이다.

자율주행 자동차 시스템(Autonomous Driving System)에서도 AI 특성을 반영한 테스트가 필요하다. 실제 도로에서는 매우 다양한 상황이 발생할 수 있기 때문에, 단순한 정상 주행 상황만 테스트하는 것으로는 충분하지 않다. 예를 들어 터널을 빠져나오자마자 앞에 고장 난 차량이 있고, 반대편 차선에서는 차량이 다가오는 상황처럼 위험도가 높은 최악의 상황(Worst-case Scenario)을 설정할 수 있다. 이러한 시나리오 기반 테스트(Scenario-based Testing)를 통해 다양한 교통 상황을 시뮬레이션(Simulation)하고, AI 시스템이 안전하게 판단하고 주행할 수 있는지 검증해야 한다.

정리하면, AI 소프트웨어는 비결정적 동작 가능성과 데이터 의존성을 가지고 있기 때문에 기존의 동등 분할 테스트만으로는 충분하지 않을 수 있다고 할 수 있겠다.

데이터 품질과 양을 고려한 AI 소프트웨어 테스트 기법의 필요성

(Need for AI Testing Techniques Considering Data Quality and Quantity)

AI 소프트웨어(AI Software)의 성능은 훈련에 사용된 데이터(Training Data)의 품질(Quality)과 양(Quantity)에 크게 의존한다. 일반 소프트웨어는 개발자가 작성한 명확한 규칙과 요구사항에 따라 동작하지만, AI 소프트웨어는 데이터를 기반으로 패턴(Pattern)을 학습하고 그 결과를 바탕으로 예측(Prediction)이나 분류(Classification)를 수행한다. 따라서 데이터가 다양하고 품질이 좋을수록 AI 모델(Model)의 성능도 향상될 가능성이 높다.

하지만 훈련 데이터에 특정 패턴이나 편향(Bias)이 존재하면, AI 모델 역시 그 편향을 학습할 수 있다. 예를 들어 동양인 얼굴 데이터를 중심으로 학습한 얼굴 인식 AI 모델(Face Recognition AI Model)에 서양인 얼굴 데이터가 입력된다면, 모델이 충분히 학습하지 못한 데이터이기 때문에 정확도가 낮아질 수 있다. 이는 모델이 다양한 집단의 데이터를 균형 있게 학습하지 못했을 때 발생할 수 있는 데이터 편향(Data Bias)의 예시이다.

이러한 특성 때문에 AI 소프트웨어에는 기존의 동등 분할 테스트(Equivalence Partitioning)를 그대로 적용하는 데 한계가 있다. 동등 분할은 입력값을 일정한 구간이나 그룹으로 나누고, 각 구간의 대표값을 테스트하는 방식이다. 그러나 AI 모델은 단순히 입력 구간만으로 결과가 결정되는 것이 아니라, 훈련 데이터의 분포(Data Distribution), 데이터의 다양성(Data Diversity), 품질, 편향 여부에 따라 결과가 달라질 수 있다. 따라서 구간을 나누어 대표값만 테스트하는 방식으로는 AI 모델의 실제 성능을 충분히 확인하기 어렵다.

예를 들어 이미지 분류 모델(Image Classification Model)을 테스트할 때, 훈련 데이터의 양이 증가함에 따라 모델의 성능이 실제로 향상되는지 확인할 수 있다. 데이터 양을 단계적으로 늘려가며 정확도(Accuracy), 정밀도(Precision), 재현율(Recall) 등의 성능 지표가 어떻게 변화하는지 평가하는 것이다. 이를 통해 모델이 더 많은 데이터를 학습했을 때 일반화 성능(Generalization Performance)이 좋아지는지 확인할 수 있다.

또한 특정 클래스(Class)가 훈련 데이터에 과대표적으로 포함되어 있는지 확인하는 방식으로 데이터 편향성을 테스트할 수 있다. 예를 들어 이미지 분류 모델에서 특정 동물, 특정 인종, 특정 사물 이미지가 지나치게 많이 포함되어 있다면, 모델은 그 클래스에 유리한 방향으로 학습될 수 있다. 따라서 다양한 클래스가 균형 있게 포함된 데이터셋(Dataset)을 준비하고, 모델이 특정 클래스에 치우친 예측을 하지 않는지 검증해야 한다.

마지막으로 데이터 품질의 다양성도 테스트해야 한다. 이미지 분류 모델에 고품질 이미지(High-quality Image)뿐만 아니라 저품질 이미지(Low-quality Image), 흐릿한 이미지(Blurred Image), 어두운 이미지(Dark Image), 노이즈가 있는 이미지(Noisy Image) 등을 입력하여 모델의 정확도를 평가할 수 있다. 이를 통해 실제 환경에서 데이터 품질이 일정하지 않더라도 모델이 안정적으로 동작하는지 확인할 수 있다.

정리하면, AI 소프트웨어의 성능은 훈련 데이터의 품질과 양에 크게 영향을 받는다. 따라서 AI 소프트웨어 테스트에서는 단순한 입력값 구간 테스트뿐만 아니라 데이터 양에 따른 성능 변화, 데이터 편향성, 클래스 불균형(Class Imbalance), 데이터 품질 다양성까지 함께 검증해야 한다.

2️⃣ AI Software Testing Techniques

ISO/IEC/IEEE 29119의 AI 소프트웨어 테스트 기법 분류

(Classification of AI Software Test Techniques in ISO/IEC/IEEE 29119)

ISO/IEC/IEEE 29119에서는 AI 소프트웨어 테스트 기법을 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 구분해서 이해할 수 있다. 이는 기존 일반 소프트웨어 테스트에서도 사용했던 분류 방식과 유사하다.

먼저 블랙박스 테스트(Black-box Testing)는 소프트웨어의 내부 구조나 구현 방식을 직접 보지 않고, 요구사항(Requirements)이나 명세(Specification)를 기반으로 테스트 케이스(Test Case)를 설계하는 방법이다. 그래서 명세 기반 테스트(Specification-based Testing)라고도 한다. 일반 소프트웨어에서는 입력값을 넣었을 때 요구사항에 맞는 출력값이 나오는지를 확인했다면, AI 소프트웨어에서도 같은 개념이 적용된다.

AI 소프트웨어의 블랙박스 테스트에서는 AI 모델(AI Model)의 내부 구조는 직접 분석하지 않고, 입력 데이터(Input Data)에 대해 출력값(Output)이 적절하게 나오는지를 확인한다. 예를 들어 이미지 분류 모델(Image Classification Model)에 이미지를 입력했을 때, 그 이미지가 사람인지, 동물인지, 또는 동물이라면 개인지 고양이인지를 올바르게 분류하는지 확인하는 방식이다. 즉, 모델 내부에서 어떤 계산이 이루어졌는지보다는 입력에 따른 결과가 요구사항에 맞는지를 중심으로 테스트한다.

반면 화이트박스 테스트(White-box Testing)는 내부 구조를 고려하여 테스트 케이스를 설계하는 방법이다. 기존 일반 소프트웨어에서는 소스 코드(Source Code)의 내부 로직(Internal Logic), 조건문, 반복문, 분기 구조 등을 기준으로 테스트를 수행했다. 그래서 구조 기반 테스트(Structure-based Testing)라고도 한다.

AI 소프트웨어의 경우, 이 내부 구조는 단순한 소스 코드 로직만이 아니라 훈련 데이터(Training Data)를 통해 만들어진 AI 모델의 구조로 확장해서 이해할 수 있다. 특히 딥러닝 모델(Deep Learning Model)에서는 신경망(Neural Network)의 내부 구조와 동작을 고려하여 테스트를 수행할 수 있다. 예를 들어 특정 입력을 넣었을 때 신경망의 어떤 뉴런(Neuron)이나 계층(Layer)이 활성화되는지 확인하고, 모델 내부가 얼마나 다양한 방식으로 테스트되었는지를 평가할 수 있다.

일반 소프트웨어의 화이트박스 테스트에서는 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage)처럼 코드가 얼마나 테스트되었는지를 측정했다. AI 소프트웨어에서는 이와 유사하게 신경망 커버리지(Neural Network Coverage)나 뉴런 커버리지(Neuron Coverage)와 같은 개념이 중요하게 다루어진다. 이는 테스트 데이터가 모델 내부의 다양한 뉴런이나 경로를 얼마나 활성화했는지를 확인하려는 시도이다.

정리하면, AI 소프트웨어 테스트도 기존 소프트웨어 테스트처럼 블랙박스 테스트와 화이트박스 테스트로 구분할 수 있다. 블랙박스 테스트는 AI 모델의 내부 구조를 보지 않고 입력과 출력의 관계를 중심으로 검증하는 방식이고, 화이트박스 테스트는 AI 모델의 내부 구조, 특히 신경망의 동작과 활성화 정도를 고려하여 테스트하는 방식이다. 차이점은 기존 소프트웨어에서는 테스트 대상의 내부 구조가 주로 소스 코드였다면, AI 소프트웨어에서는 그 대상이 AI 모델과 신경망 구조로 확장된다는 점이다.

AI 소프트웨어의 블랙박스 테스트 설계 기법

(Black-box Test Design Techniques for AI Software)

AI 소프트웨어(AI Software)에 적용할 수 있는 블랙박스 테스트 설계 기법(Black-box Test Design Techniques)에는 조합 테스트(Combinatorial Testing), 백투백 테스트(Back-to-back Testing), 변성 테스트(Metamorphic Testing), 탐색적 테스트(Exploratory Testing) 등이 있다. 블랙박스 테스트는 AI 모델(AI Model)의 내부 구조를 직접 분석하지 않고, 입력 데이터(Input Data)에 대해 어떤 출력(Output)이 나오는지를 중심으로 테스트하는 방식이다.

조합 테스트(Combinatorial Testing)는 여러 입력값이나 조건을 조합하여 테스트 케이스(Test Case)를 만드는 기법이다. 이는 AI 소프트웨어뿐만 아니라 일반 소프트웨어에서도 충분히 사용할 수 있는 테스트 방법이다.

하지만 AI 소프트웨어에서는 조합 테스트를 적용하는 데 한계가 있을 수 있다. AI 모델은 입력 특성(Feature), 파라미터(Parameter), 데이터 조건이 매우 많을 수 있기 때문이다. 특히 대규모 AI 모델의 경우 수많은 매개변수와 입력 조건을 모두 조합하여 테스트하는 것은 현실적으로 어렵다. 따라서 모든 조합을 테스트하기보다는 중요한 조합을 선별하거나, 위험도가 높은 입력 조건을 중심으로 테스트하는 방식이 필요하다.

백투백 테스트(Back-to-back Testing)는 동일한 입력을 여러 개의 서로 다른 AI 모델에 넣고, 그 결과를 비교하는 테스트 기법이다. AI 소프트웨어에서는 모델이 얼마나 정확하게 예측(Prediction)하는지가 중요하기 때문에, 하나의 모델 결과만 보는 것이 아니라 다른 방식으로 개발된 모델들과 비교하여 신뢰성을 확인할 수 있다.

예를 들어 같은 문제를 해결하기 위해 A 모델, B 모델, C 모델을 각각 다른 알고리즘(Algorithm), 다른 개발자, 또는 다른 학습 방식으로 만든다고 가정할 수 있다. 이후 동일한 입력 데이터를 세 모델에 넣었을 때 결과가 서로 유사하거나 일관되게 나온다면, 해당 예측 결과에 대한 신뢰도를 높일 수 있다. 반대로 모델마다 결과가 크게 다르다면, 어떤 모델이 왜 다른 판단을 했는지 추가 분석이 필요하다.

변성 테스트(Metamorphic Testing)와 탐색적 테스트(Exploratory Testing)도 AI 소프트웨어의 블랙박스 테스트 기법에 포함될 수 있다. 변성 테스트는 정답을 명확히 알기 어려운 상황에서 입력을 변형하고, 그에 따른 출력 관계가 예상한 특성을 유지하는지 확인하는 방식이다. 탐색적 테스트는 사전에 모든 테스트 케이스를 정해두기보다, 테스터가 시스템을 사용하고 관찰하면서 새로운 결함이나 이상 동작을 찾아내는 방식이다. 이 두 기법은 다음 내용에서 더 자세히 다룰 수 있다.

정리하면, AI 소프트웨어의 블랙박스 테스트는 모델 내부 구조보다는 입력과 출력의 관계를 중심으로 수행된다. 조합 테스트는 다양한 입력 조건의 조합을 확인하는 데 사용되고, 백투백 테스트는 여러 AI 모델의 결과를 비교하여 예측의 일관성과 신뢰성을 확인하는 데 활용된다. 다만 AI 소프트웨어는 입력 조건과 파라미터가 매우 많기 때문에, 모든 조합을 테스트하기보다는 효율적인 테스트 설계가 중요하다.

변성 테스트 (Metamorphic Testing)

변성 테스트(Metamorphic Testing)는 AI 모델(AI Model)의 복잡성(Complexity)과 비결정성(Non-determinism) 때문에 예상 결과(Expected Result)를 명확하게 정하기 어려운 경우에 사용할 수 있는 테스트 기법이다. 일반적인 소프트웨어 테스트에서는 입력값(Input)에 대해 예상 결과를 미리 정하고, 실제 결과(Actual Result)와 비교하여 테스트 통과 여부를 판단한다. 하지만 AI 소프트웨어(AI Software)는 모델의 구조가 복잡하고, 경우에 따라 같은 입력이나 비슷한 입력에 대해서도 결과가 달라질 수 있어 예상 결과를 단정하기 어려운 경우가 있다.

이때 변성 테스트는 특정 입력에 대한 정확한 출력값 하나를 확인하기보다, 입력이 변화했을 때 출력이 어떤 관계(Relation)를 가져야 하는지를 기준으로 테스트한다. 즉, “입력이 이렇게 바뀌면 출력도 이런 방식으로 유지되거나 변화해야 한다”는 관계를 설정하고, AI 모델이 그 관계를 만족하는지 확인하는 방식이다.

예를 들어 이미지 분류 모델(Image Classification Model)을 생각해볼 수 있다. 원본 이미지가 고양이(Cat)라면, 이 이미지의 밝기(Brightness)를 조금 바꾸어도 본질적으로는 여전히 고양이 이미지이다. 따라서 AI 모델이 잘 만들어졌다면 밝기가 바뀐 이미지도 고양이로 분류해야 한다. 마찬가지로 고양이 이미지를 좌우 반전(Horizontal Flip)하더라도 이미지의 방향만 바뀐 것이므로, 모델은 여전히 고양이로 판단할 수 있어야 한다.

이처럼 변성 테스트에서는 원본 입력(Source Input)을 변형하여 새로운 입력(Follow-up Input)을 만들고, 두 입력에 대한 출력 사이의 관계가 적절한지 확인한다. 원본 고양이 이미지를 고양이로 분류했다면, 밝기만 바꾼 이미지나 좌우 반전한 이미지도 고양이로 분류해야 한다는 식이다. 여기서 중요한 것은 정확한 출력값 하나보다, 입력 변화에 따른 출력의 일관성(Consistency)과 관계성(Relation)을 검증하는 것이다.

자율주행 자동차(Autonomous Vehicle)에서도 변성 테스트를 적용할 수 있다. 예를 들어 자율주행차가 특정 도로를 정방향으로 안전하게 주행했다면, 같은 도로를 반대 방향으로 주행할 때도 주변 환경(Environment)을 인식하고 안전하게 주행할 수 있어야 한다. 물론 주행 방향이 바뀌면 도로 표지판, 차선, 차량 흐름 등 조건도 달라질 수 있지만, 기본적으로 AI 모델은 변화된 입력 상황에서도 적절한 주행 판단을 내려야 한다.

정리하면, 변성 테스트는 AI 소프트웨어에서 예상 결과를 정확히 정하기 어려울 때 유용한 테스트 기법이다. 입력값을 조금씩 변형하고, 그에 따른 출력값이 논리적으로 타당한 관계를 유지하는지 확인한다. 이미지 분류에서는 밝기 변경이나 좌우 반전 후에도 같은 객체로 분류되는지 확인할 수 있고, 자율주행에서는 주행 방향이나 환경 조건이 달라져도 안전한 판단을 하는지 검증할 수 있다.

탐색적 테스트 (Exploratory Testing)

탐색적 테스트(Exploratory Testing)는 AI 소프트웨어(AI Software)가 학습하지 못한 알려지지 않은 케이스(Unknown Case)를 찾아내기 위해 반복적으로 테스트를 수행하는 기법이다. AI 모델(AI Model)은 훈련 데이터(Training Data)를 기반으로 학습하지만, 현실의 모든 데이터를 전부 학습할 수는 없다. 따라서 실제 사용 환경에서는 훈련 데이터에 포함되지 않았던 새로운 상황이 나타날 수 있고, 이 경우 모델이 예측하지 못한 동작을 하거나 전혀 엉뚱한 결과를 낼 가능성이 있다.

탐색적 테스트는 이러한 알려지지 않은 케이스를 계속 찾아가는 것을 목표로 한다. 기존 테스트 결과를 활용하고, 입력 데이터(Input Data)에 대해 다양한 추출(Sampling)과 조합(Combination) 기법을 적용하면서 반복적으로 테스트를 수행한다. 즉, 미리 정해진 테스트 케이스만 실행하는 것이 아니라, 테스트 과정에서 발견된 결과를 바탕으로 새로운 테스트 케이스(Test Case)를 계속 만들어 나가는 방식이다.

예를 들어 자율주행 자동차(Autonomous Vehicle)를 테스트한다고 하면, 먼저 입력 영역(Input Domain)을 정의해야 한다. 시골길인지 도심 도로인지, 날씨가 맑은지 비가 오는지, 터널이 있는지, 앞에 고장 난 차량이 있는지, 반대편에서 차량이 오는지와 같은 조건을 정리한다. 이후 이러한 조건을 조합하여 테스트 케이스를 생성하고, 시뮬레이션(Simulation)을 통해 테스트를 수행한다.

AI 소프트웨어의 탐색적 테스트에서는 실제 환경보다 시뮬레이션 기반 테스트(Simulation-based Testing)가 중요하다. 특히 자율주행처럼 안전과 관련된 시스템에서는 알려지지 않은 케이스가 실제 사고로 이어질 수 있기 때문이다. 따라서 위험한 상황이나 예측하기 어려운 상황은 먼저 가상 환경(Virtual Environment)에서 반복적으로 실험하는 것이 안전하다.

테스트를 수행한 뒤에는 결과를 확인하고, 문제가 발견되면 수정 후 재테스트(Retest)를 진행한다. 만약 테스트 과정에서 기존에 알려지지 않았던 새로운 케이스가 발견되면, 이를 신규 테스트 케이스(New Test Case)로 추가하여 다시 테스트한다. 또한 테스트 결과의 위험도(Risk Level)를 분석하여, 위험도가 높은 상황이라면 우선적으로 추가 테스트 케이스를 만들고 검증해야 한다.

정리하면, 탐색적 테스트는 이미 알려진 케이스(Known Case)만 확인하는 것이 아니라, 알려지지 않은 케이스를 하나씩 찾아가며 테스트 범위와 커버리지(Coverage)를 넓히는 방식이다. AI 소프트웨어는 모든 상황을 미리 학습하기 어렵기 때문에, 탐색적 테스트를 통해 새로운 입력 상황과 위험한 사례를 계속 발견하고 보완하는 과정이 필요하다.

AI 소프트웨어의 화이트박스 테스트 설계 기법

(White-box Test Design Techniques for AI Software)

AI 소프트웨어(AI Software)에 대한 화이트박스 테스트(White-box Testing)는 AI 모델(AI Model)의 내부 구조를 고려하여 테스트하는 방법이다. 일반 소프트웨어의 화이트박스 테스트가 소스 코드(Source Code)의 내부 로직과 구조를 기반으로 테스트 케이스(Test Case)를 설계하는 것처럼, AI 소프트웨어에서는 모델 내부의 신경망(Neural Network) 구조와 뉴런(Neuron)의 동작을 중심으로 테스트를 수행한다.

AI 모델에서 각각의 뉴런은 일반 소프트웨어의 코드 구성 요소와 유사하게 볼 수 있다. 따라서 화이트박스 테스트에서는 테스트 데이터를 입력했을 때 모델 내부의 뉴런들이 얼마나 많이 활성화(Activation)되는지, 즉 얼마나 넓은 범위의 내부 구조가 테스트되었는지를 확인하는 것이 중요하다. 이는 일반 소프트웨어 테스트에서 문장 커버리지(Statement Coverage)나 분기 커버리지(Branch Coverage)를 높이려는 것과 비슷한 개념이다.

AI 소프트웨어의 화이트박스 테스트 설계 기법은 크게 뉴런 커버리지(Neuron Coverage), 임계점 커버리지(Threshold Coverage), 부호 변경 커버리지(Sign Change Coverage), 값 변경 커버리지(Value Change Coverage) 등으로 나눌 수 있다. 이들은 모두 AI 모델 내부의 뉴런이 어떻게 반응하고 변화하는지를 기준으로 테스트 범위를 넓히기 위한 방법이다.

가장 기본이 되는 개념은 뉴런 커버리지(Neuron Coverage)이다. 뉴런 커버리지는 테스트 입력을 통해 AI 모델 내부의 뉴런들이 얼마나 많이 활성화되었는지를 측정하는 방식이다. 이후 임계점 커버리지, 부호 변경 커버리지, 값 변경 커버리지와 같은 기법들은 뉴런 커버리지 개념을 바탕으로 조금 더 세부적인 변화나 조건을 고려하는 방식으로 확장된다.

정리하면, AI 소프트웨어의 화이트박스 테스트는 AI 모델의 내부 구조를 분석하고, 신경망 안의 뉴런들이 충분히 테스트되었는지를 확인하는 방식이다. 일반 소프트웨어에서 코드 커버리지(Code Coverage)를 높이는 것이 중요하듯이, AI 소프트웨어에서는 뉴런 커버리지와 같은 모델 내부 커버리지(Model Coverage)를 높이는 것이 중요한 테스트 목표가 된다.

신경망 구조 참고 (Neural Network Structure)

신경망(Neural Network)은 사람의 두뇌에서 뉴런(Neuron)들이 서로 연결되어 정보를 처리하는 방식에서 영감을 받아 만들어진 계산 모델(Computational Model)이다. AI 모델(AI Model)은 여러 개의 노드(Node) 또는 뉴런으로 구성되며, 이러한 뉴런들이 여러 층(Layer)으로 연결되어 입력 데이터를 처리하고 결과를 출력한다.

예를 들어 벚꽃과 배꽃을 구분한다고 생각해볼 수 있다. 사람은 과거의 경험을 바탕으로 꽃의 색, 모양, 크기, 잎의 형태 등을 보고 판단한다. 이와 비슷하게 AI 모델도 입력된 데이터를 바탕으로 특징(Feature)을 학습하고, 이를 이용해 새로운 데이터가 어떤 대상에 해당하는지 예측(Prediction)하거나 분류(Classification)한다.

신경망은 일반적으로 입력 레이어(Input Layer), 은닉 레이어(Hidden Layer), 출력 레이어(Output Layer)로 구성된다. 입력 레이어는 외부에서 데이터를 입력받는 부분이다. 이미지 분류 모델(Image Classification Model)의 경우, 이미지의 픽셀값(Pixel Value)이 입력 데이터가 될 수 있다.

은닉 레이어는 입력 레이어에서 받은 정보를 처리하고 계산하는 부분이다. 이 단계에서 AI 모델은 입력 데이터의 특징을 추출하고, 여러 계산 과정을 거쳐 출력 결과를 만들기 위한 정보를 정리한다. 은닉 레이어가 여러 개로 깊게 구성된 모델을 딥러닝 모델(Deep Learning Model)이라고 볼 수 있다.

출력 레이어는 최종 결과를 외부에 제공하는 역할을 한다. 예를 들어 꽃 이미지를 입력했을 때, 출력 레이어는 해당 이미지가 벚꽃인지, 배꽃인지와 같은 분류 결과를 제공한다. 즉, 신경망은 입력 데이터를 받아 은닉 레이어에서 계산을 수행하고, 출력 레이어를 통해 최종 판단 결과를 내는 구조로 동작한다.

정리하면, 신경망은 사람의 두뇌 구조에서 영감을 받은 AI 모델의 기본 구조이며, 입력 레이어, 은닉 레이어, 출력 레이어로 구성된다. 입력 레이어는 데이터를 받고, 은닉 레이어는 계산과 특징 추출을 수행하며, 출력 레이어는 최종 예측 결과를 제공한다.

뉴런 커버리 (Neuron Coverage)

뉴런 커버리지(Neuron Coverage)는 신경망(Neural Network) 내부의 뉴런(Neuron)이 테스트 데이터셋(Test Dataset)에 의해 얼마나 활성화되었는지를 측정하는 화이트박스 테스트(White-box Testing) 개념이다. 일반 소프트웨어에서 코드의 문장이나 분기가 얼마나 실행되었는지를 커버리지(Coverage)로 확인하듯이, AI 소프트웨어에서는 모델 내부의 뉴런이 얼마나 많이 활성화되었는지를 기준으로 테스트 범위를 확인할 수 있다.

뉴런은 입력값(Input Value)을 계산하여 활성값(Activation Value)이라는 출력값을 생성한다. 특정 입력 데이터가 들어왔을 때 어떤 뉴런은 활성화(Activation)되고, 어떤 뉴런은 거의 반응하지 않거나 비활성화(Deactivation)될 수 있다. 테스트 데이터셋을 넣었을 때 활성화되는 뉴런이 많을수록 신경망 내부의 다양한 부분이 테스트되었다고 볼 수 있다.

예를 들어 이미지 분류 모델(Image Classification Model)을 테스트할 때, 기존 데이터셋으로는 전체 23개의 뉴런 중 20개만 활성화되었다고 가정할 수 있다. 이 경우 3개의 뉴런은 아직 테스트 데이터에 의해 충분히 사용되지 않은 상태이다. 더 다양한 이미지를 추가하면 기존에 비활성화되었던 뉴런이 활성화될 수 있고, 그 결과 모델 내부의 더 넓은 부분을 테스트할 수 있다.

뉴런 커버리지는 다음과 같이 계산할 수 있다.

뉴런 커버리지(Neuron Coverage) = 활성화된 뉴런 수 / 전체 뉴런 수 × 100%

예를 들어 전체 뉴런이 23개이고, 그중 20개가 활성화되었다면 뉴런 커버리지는 20 / 23 × 100 = 86.96%가 된다. 이후 새로운 이미지를 추가하여 23개의 뉴런이 모두 활성화되었다면 뉴런 커버리지는 23 / 23 × 100 = 100%가 된다.

즉, 뉴런 커버리지는 테스트 데이터가 AI 모델 내부의 뉴런을 얼마나 폭넓게 자극했는지 확인하는 지표이다. 이를 통해 기존 테스트 데이터로는 확인하지 못했던 모델 내부 동작을 더 많이 살펴볼 수 있으며, 비활성화된 뉴런을 활성화할 수 있는 새로운 테스트 데이터를 추가하는 방식으로 테스트 범위를 넓힐 수 있다.

정리하면, AI 소프트웨어 테스트에서는 블랙박스 테스트(Black-box Testing) 관점에서 변성 테스트(Metamorphic Testing), 탐색적 테스트(Exploratory Testing) 등을 사용할 수 있고, 화이트박스 테스트 관점에서는 뉴런 커버리지(Neuron Coverage)와 같은 기법을 사용할 수 있다. 뉴런 커버리지는 AI 모델 내부 구조를 기준으로 테스트 범위를 확인하는 대표적인 방법이며, 이후 임계점 커버리지(Threshold Coverage), 부호 변경 커버리지(Sign Change Coverage), 값 변경 커버리지(Value Change Coverage)와 같은 기법으로 확장될 수 있다.

3️⃣ Virtual-based AI software testing environment

가상 기반 AI 소프트웨어 테스트 환경(Virtual-based AI Software Testing Environment)은 실제 하드웨어(Hardware)나 실제 소프트웨어 환경을 직접 사용하지 않고, 디지털 트윈(Digital Twin)이나 시뮬레이션(Simulation)을 활용하여 AI 소프트웨어(AI Software)를 테스트하는 환경을 말한다. 꼭 AI 소프트웨어에만 적용되는 개념은 아니지만, AI 소프트웨어는 현실 세계의 다양한 상황을 학습하고 판단해야 하는 경우가 많기 때문에 가상 기반 테스트 환경의 필요성이 특히 크다.

디지털 트윈(Digital Twin)은 현실 세계의 물리적 환경을 가상 공간에 동일하거나 유사하게 구현한 것을 의미한다. 예를 들어 실제 도로에 센서(Sensor), 카메라(Camera), 건물, 차량, 보행자 등이 있다면, 이러한 요소들을 가상 환경 안에 재현할 수 있다. 또한 현실에서 교통 상황이나 주변 환경이 변하면, 가상 환경에서도 그 변화를 반영하여 실제와 비슷한 조건을 만들 수 있다. 현실 세계와 가상 세계를 서로 대응시키는 개념이기 때문에 ‘트윈(Twin)’이라는 표현이 사용된다.

이러한 가상 환경에서는 자율주행 자동차(Autonomous Vehicle), 드론(Drone), 물류 시스템(Logistics System), 항만 시스템(Port System), 군사 훈련 시스템(Military Training System) 등 다양한 AI 소프트웨어를 테스트할 수 있다. 실제 도로, 공중, 항만, 물류 창고, 훈련장을 그대로 사용하지 않고도 가상으로 환경을 구성한 뒤, 그 안에서 AI 모델이 어떻게 판단하고 동작하는지 확인할 수 있다.

가상 기반 테스트 환경이 필요한 가장 큰 이유는 현실 세계에서 테스트하기 어려운 제약이 많기 때문이다. 예를 들어 자율주행 자동차의 사고 상황이나 위험한 도로 상황을 실제로 일부러 재현하는 것은 매우 위험하다. 또한 현실에서는 비가 오는 날, 안개가 낀 날, 터널을 빠져나오자마자 장애물이 있는 상황, 갑자기 보행자가 뛰어나오는 상황처럼 다양한 엣지 케이스(Edge Case)를 모두 직접 테스트하기 어렵다.

가상 환경에서는 이러한 위험한 시나리오(Scenario)나 예외적인 상황을 비교적 안전하게 재현할 수 있다. 사고 위험이 큰 상황도 실제 사람이나 장비를 위험에 빠뜨리지 않고 테스트할 수 있으며, 같은 조건을 여러 번 반복해서 실행할 수도 있다. 이를 통해 AI 소프트웨어가 다양한 환경에서도 안정적으로 판단하는지, 위험 상황에서 적절하게 반응하는지 확인할 수 있다.

또한 가상 테스트 환경은 시간과 비용을 줄이는 데도 도움이 된다. 현실에서 여러 환경을 직접 구성하려면 많은 비용과 시간이 필요하지만, 가상 환경을 한 번 구축해두면 다양한 조건을 바꾸어가며 반복적으로 테스트할 수 있다. 여러 테스트를 병렬적으로 동시에 수행할 수도 있기 때문에 전체 테스트 일정과 비용을 줄이는 효과가 있다.

정리하면, 가상 기반 AI 소프트웨어 테스트 환경은 현실 세계를 디지털 트윈이나 시뮬레이션으로 구현하고, 그 안에서 AI 소프트웨어를 안전하고 반복적으로 테스트하는 환경이다. 특히 AI 소프트웨어는 예측하기 어려운 상황, 위험한 시나리오, 다양한 엣지 케이스에 대응해야 하므로, 가상 환경을 활용한 테스트가 매우 중요하다.

1️⃣Overview of AI Software

AI 소프트웨어 개요(AI Software Overview)

AI 소프트웨어(AI Software)는 인공지능 기술을 활용해 만들어지는 소프트웨어 제품이다. 일반적인 소프트웨어가 정해진 명령과 규칙에 따라 동작한다면, AI 소프트웨어는 데이터를 바탕으로 판단하거나 예측하고, 사람의 지능적인 작업을 모방하도록 만들어진다.

AI 소프트웨어에는 기계학습(Machine Learning), 자연어 처리(Natural Language Processing), 컴퓨터 비전(Computer Vision), 빅데이터(Big Data) 등의 기술이 복합적으로 적용될 수 있다. 이를 통해 사용자의 질문에 답변하거나, 주변 환경을 인식하고, 상황에 맞게 스스로 판단하여 행동할 수 있다.

예를 들어 챗봇(Chatbot)이나 GPT와 같은 대화형 인공지능 모델(Conversational AI Model)은 사람이 대화하는 것처럼 사용자의 요청에 자연스럽게 응답한다. 또한 서빙 로봇이나 물류 로봇은 주변 상황을 인식하고, 멈추거나 이동해야 하는 상황을 판단하여 서비스를 제공한다.

자율주행 자동차(Autonomous Vehicle)도 AI 소프트웨어가 활용되는 대표적인 사례이다. 자율주행 자동차는 도로, 사람, 차량, 장애물 등 다양한 환경을 인식하고, 운전자가 판단하듯이 안전한 주행을 수행하도록 설계된다.

따라서 AI 소프트웨어는 사람이 수행하는 판단, 예측, 인식, 대화와 같은 지능적인 작업을 모방하거나, 스스로 판단하여 작업을 수행할 수 있도록 돕는 소프트웨어라고 정리할 수 있다.

기존 소프트웨어와 AI 소프트웨어의 차이(Difference Between Traditional Software and AI Software)

기존 소프트웨어(Traditional Software)는 정해진 요구사항(Requirements)을 만족하도록 개발된다. 사용자가 제시한 기능이나 조건에 맞게 동작하면 품질이 좋은 소프트웨어라고 판단할 수 있다. 즉, 요구사항이 비교적 명확하게 정의되어 있고, 그 요구사항대로 동작하는지가 중요한 기준이 된다.

반면 AI 소프트웨어(AI Software)는 모든 요구사항을 명확하게 정의하기 어렵다는 특징이 있다. 사람도 모든 상황을 미리 경험하지 못하지만, 과거의 경험을 바탕으로 새로운 상황을 판단한다. AI 소프트웨어도 이와 비슷하게 제한된 데이터(Data)를 바탕으로 학습하고, 새로운 상황이 주어졌을 때 학습한 내용을 기반으로 판단하거나 예측한다.

따라서 AI 소프트웨어는 기존 소프트웨어처럼 모든 동작을 미리 정해두기보다는, 학습 데이터(Training Data)를 기반으로 상황에 맞는 결과를 만들어내는 방식으로 동작한다. 이 점이 기존 소프트웨어와 AI 소프트웨어의 가장 큰 차이이다.

AI 소프트웨어의 동작 방식(How AI Software Works)

AI 소프트웨어(AI Software)는 데이터(Data)를 기반으로 학습하고, 학습한 내용을 바탕으로 새로운 상황을 예측(Prediction)하거나 판단(Decision)한다. 입력된 데이터에서 규칙적인 패턴(Pattern)을 찾고, 이를 통해 학습된 모델(Model)을 만든다.

예를 들어 동물을 식별하는 AI는 개와 고양이 이미지 데이터를 학습한다. 이때 각 이미지에는 “개(Dog)” 또는 “고양이(Cat)”처럼 정답을 표시한 레이블(Label)이 붙어 있을 수 있다. AI는 이러한 학습 데이터(Training Data)를 신경망(Neural Network)이나 알고리즘(Algorithm)을 통해 학습하고, 개와 고양이를 구분하는 모델을 만든다.

이후 새로운 이미지 데이터가 들어오면, 학습된 모델은 해당 이미지가 개에 가까운지 고양이에 가까운지 예측한다. 다만 AI의 판단은 항상 100% 정확한 것이 아니라, 학습한 데이터와 패턴을 바탕으로 가장 가능성이 높은 결과를 예측하는 것이다.

따라서 AI 소프트웨어의 품질을 확보하기 위해서는 충분한 양의 데이터뿐만 아니라, 데이터가 정확하고 적절하게 구성되어 있는지도 중요하다. 잘못된 데이터나 부족한 데이터로 학습하면 AI 모델의 예측 결과도 부정확해질 수 있다.

AI 소프트웨어에서 발생할 수 있는 문제점(Problems in AI Software)

AI 소프트웨어(AI Software)는 데이터(Data)를 기반으로 학습하고 예측하기 때문에, 품질 문제가 발생할 수 있다. 대표적인 문제는 크게 세 가지로 정리할 수 있다.

첫째, 훈련 데이터(Training Data)의 품질이 낮거나 편향(Bias)될 수 있다. 데이터가 부족하거나 잘못되어 있으면 AI 모델(Model)도 잘못된 패턴을 학습하게 된다. 또한 특정 집단이나 상황에 치우친 데이터로 학습하면 실제 결과도 편향될 수 있다.

둘째, 훈련 과정(Training Process)에서 에포크(Epoch) 수나 파라미터(Parameter) 값이 적절하지 않을 수 있다. 학습이 너무 부족하면 모델이 충분히 패턴을 배우지 못하고, 반대로 너무 과도하게 학습하면 훈련 데이터에만 지나치게 맞춰지는 문제가 생길 수 있다.

셋째, 훈련 데이터와 실제 데이터(Real-world Data) 사이에 차이가 생길 수 있다. AI 모델은 학습한 환경과 실제 사용 환경이 다르면 예상보다 낮은 성능을 보일 수 있다. 특히 시간이 지나면서 환경이 변하면 기존 모델의 판단이 부정확해질 수 있다.

훈련 데이터 품질과 편향(Training Data Quality and Bias)

AI 소프트웨어(AI Software)의 성능은 훈련 데이터(Training Data)의 품질에 큰 영향을 받는다. 훈련 데이터의 품질이 낮으면, 이를 바탕으로 학습한 모델(Model)의 성능도 떨어질 수밖에 없다.

예를 들어 얼굴 인식(Face Recognition) AI를 학습할 때 흐릿한 이미지, 조명이 좋지 않은 이미지, 각도가 불안정한 이미지가 많이 포함되어 있다면 모델이 얼굴을 정확하게 식별하기 어렵다. 즉, 데이터가 부정확하거나 품질이 낮으면 AI의 판단 결과도 부정확해질 수 있다.

또한 훈련 데이터가 특정 인종, 성별(Gender), 연령(Age)에 치우쳐 있으면 편향(Bias) 문제가 발생할 수 있다. 특정 그룹의 데이터가 많으면 그 그룹에 대해서는 성능이 좋을 수 있지만, 데이터가 부족한 그룹에 대해서는 성능이 낮아질 수 있다. 따라서 다양한 집단을 포함한 균형 잡힌 데이터가 필요하다.

마지막으로 훈련 데이터가 특정 인물이나 특정 환경(Environment)에만 한정되어 있으면 일반화(Generalization) 능력이 부족해질 수 있다. 예를 들어 자율주행 자동차(Autonomous Vehicle)가 도시 환경 위주로만 학습했다면, 시골길이나 낯선 도로 환경에서는 안전하게 판단하지 못할 수 있다. 따라서 AI 모델이 실제 환경에서도 잘 동작하려면 다양한 상황과 환경을 반영한 데이터로 학습해야 한다.

훈련 과정의 문제: 과적합과 과소적합(Overfitting and Underfitting)

AI 소프트웨어(AI Software)는 훈련 과정(Training Process)에서 에포크(Epoch) 수나 파라미터(Parameter) 값이 적절하지 않으면 품질 문제가 발생할 수 있다. 대표적인 문제는 과적합(Overfitting)과 과소적합(Underfitting)이다.

과적합(Overfitting)은 모델(Model)이 훈련 데이터(Training Data)에 지나치게 맞춰진 상태를 말한다. 에포크 수가 너무 많거나 모델이 너무 복잡하면, 훈련 데이터에서는 좋은 성능을 보이지만 새로운 데이터(Unseen Data)에 대해서는 정확도가 떨어질 수 있다. 예를 들어 훈련 데이터의 대부분이 개 이미지이고 고양이 이미지는 적다면, 모델은 개는 잘 구분하지만 고양이는 제대로 예측하지 못할 수 있다.

과소적합(Underfitting)은 모델이 훈련 데이터의 패턴(Pattern)을 충분히 학습하지 못한 상태를 말한다. 에포크 수가 너무 적거나 모델 구조가 너무 단순하면, 훈련 데이터와 새로운 데이터 모두에서 성능이 낮게 나타날 수 있다. 예를 들어 감정 분석 AI가 “좋다”, “나쁘다”처럼 단순한 감정만 학습했다면, 복잡한 감정 상태를 제대로 구분하지 못할 수 있다.

따라서 AI 모델을 개발할 때는 에포크 수, 모델 복잡도(Model Complexity), 파라미터 값을 적절하게 조정하여 훈련 데이터에만 치우치지 않고 새로운 데이터에도 잘 동작하도록 만들어야 한다.

훈련 데이터와 실제 환경의 차이(Training-Serving Data Difference)

AI 소프트웨어(AI Software)는 훈련 데이터(Training Data)를 기반으로 학습하지만, 실제 사용 환경(Real-world Environment)이 훈련 환경과 다르면 예상대로 동작하지 못할 수 있다.

예를 들어 자율주행 자동차(Autonomous Vehicle)의 AI 모델이 주로 차량이 있는 도로 데이터만 학습했다면, 실제 도로에서 보행자(Pedestrian), 자전거(Bicycle), 공사 구간(Construction Zone) 같은 다양한 요소를 제대로 인식하지 못할 수 있다.

또한 훈련된 환경과 실제 운영 환경이 달라지는 경우도 문제가 된다. 예를 들어 모델이 건조하고 밝은 날씨의 도로만 학습했다면, 비가 오거나 안개가 낀 상황에서는 정확한 판단이 어려울 수 있다. 도로 구조가 바뀌거나 우회도로가 생기는 경우도 모델 성능에 영향을 줄 수 있다.

특히 자율주행처럼 안전(Safety)이 중요한 시스템에서는 이러한 차이가 큰 문제가 될 수 있다. 실제 환경에서도 AI가 안정적으로 판단하고 제어할 수 있도록 다양한 상황을 반영한 데이터와 지속적인 검증이 필요하다.

정리(Summary): AI 소프트웨어와 품질 문제(AI Software and Quality Issues)

지금까지 AI 소프트웨어(AI Software)의 정의와 품질에 영향을 주는 문제점을 살펴보았다. AI 소프트웨어는 데이터(Data)를 기반으로 학습하고, 학습된 모델(Model)을 통해 판단하거나 예측하는 소프트웨어이다.

AI 소프트웨어의 품질 문제는 주로 데이터와 모델 측면에서 발생한다. 훈련 데이터(Training Data)의 품질이 낮거나 편향되면 모델의 성능이 떨어질 수 있고, 훈련 과정에서 에포크(Epoch)나 파라미터(Parameter)가 적절하지 않으면 과적합(Overfitting) 또는 과소적합(Underfitting)이 발생할 수 있다. 또한 훈련 환경과 실제 사용 환경이 다르면 모델이 예상대로 동작하지 않을 수 있다.

기존 소프트웨어(Traditional Software)는 정해진 요구사항(Requirements)을 얼마나 잘 만족하는지가 품질의 기준이 된다. 하지만 AI 소프트웨어는 모든 상황과 요구사항을 명확히 정의하기 어렵다. 아직 경험하지 못한 데이터와 환경이 많기 때문에, 제한된 학습 데이터를 바탕으로 최대한 적절한 결과를 내야 한다.

따라서 AI 소프트웨어의 품질 확보(Quality Assurance)는 앞으로 계속 해결해야 할 중요한 과제이다. AI가 실제 환경에서도 신뢰성 있게 동작하려면 데이터 품질, 모델 학습 과정, 실제 환경 변화까지 함께 고려해야 한다.

2️⃣Quality Issues and Characteristics of AI Software

AI 소프트웨어의 품질 문제와 영향(Quality Issues and Impact of AI Software)

이번 챕터에서는 AI 소프트웨어(AI Software)의 품질 문제와 특성에 대해 살펴본다. AI 소프트웨어는 자율주행 자동차(Autonomous Vehicle), 항공기(Aircraft), 의료기기(Medical Device)와 같은 최종 제품 안에서 시스템(System)이나 서브시스템(Subsystem)을 제어하는 중요한 요소가 될 수 있다.

AI 소프트웨어에 결함(Defect)이 발생하면 단순히 소프트웨어 내부 문제로 끝나지 않는다. 개발자의 실수, 낮은 품질의 데이터(Data), 편향된 데이터(Biased Data), 새로운 환경을 반영하지 못한 학습 문제 등으로 인해 모델(Model)의 성능이 낮아질 수 있다. 예를 들어 개를 고양이로 잘못 판단하는 것처럼 잘못된 예측이나 분류가 발생할 수 있다.

이러한 오류는 상위 서브시스템과 전체 시스템으로 전달되어 최종 제품의 동작에 영향을 줄 수 있다. 특히 자율주행처럼 안전이 중요한 분야에서는 AI 소프트웨어가 경험하지 못한 환경에서 오동작을 일으키고, 그 결과 인명 피해, 상해, 경제적 손실, 환경적 피해로 이어질 수 있다.

따라서 AI 소프트웨어의 품질 문제는 단순한 성능 저하가 아니라 실제 사고와 위해(Harm)로 연결될 수 있는 중요한 문제이다.

AI 소프트웨어의 위험성(Risks of AI Software)

AI 소프트웨어(AI Software)는 다양한 분야에서 활용되지만, 결함이나 악용이 발생하면 실제 피해(Harm)로 이어질 수 있다. 대표적인 사례로는 딥페이크(Deepfake), 피싱(Phishing), AI 예술(AI Art), 의료 AI(Medical AI) 문제가 있다.

딥페이크(Deepfake)는 AI를 이용해 특정 인물의 얼굴이나 목소리를 실제처럼 흉내 내는 기술이다. 이를 악용하면 유명인이나 공인을 사칭해 가짜 광고, 투자 사기, 구매 유도 영상 등을 만들 수 있다. 실제로 호주 Scamwatch도 유명인 딥페이크를 이용한 투자 사기가 증가하고 있다고 경고했다.

대화형 인공지능(Conversational AI)도 악용될 수 있다. ChatGPT와 같은 생성형 AI(Generative AI)를 사용하면 자연스러운 문장이나 이메일을 쉽게 만들 수 있기 때문에, 피싱 이메일(Phishing Email)이나 사기 메시지가 더 그럴듯하게 작성될 수 있다. 사용자가 이를 진짜로 착각해 링크를 클릭하면 개인정보 유출이나 경제적 피해가 발생할 수 있다.

AI 예술(AI Art)도 논쟁이 되고 있다. 예를 들어 2022년 미국 콜로라도 주립 박람회(Colorado State Fair)에서 Jason Allen의 AI 생성 이미지가 디지털 아트 부문에서 1위를 차지하면서, AI로 만든 예술을 어떻게 평가하고 보상해야 하는지 논쟁이 커졌다.

의료 분야에서도 AI 소프트웨어의 위험성이 나타날 수 있다. IBM Watson for Oncology는 암 치료 추천에 사용된 AI 시스템이었는데, 2018년 STAT 보도에 따르면 내부 문서에서 안전하지 않거나 부정확한 치료 추천 사례가 지적되었다. 의료 AI가 환자의 상태나 실제 환경을 충분히 반영하지 못하면 잘못된 치료 방향을 제시할 수 있고, 이는 환자에게 큰 위해로 이어질 수 있다.

따라서 AI 소프트웨어의 위험성은 단순한 기술 오류를 넘어 경제적 손실, 사회적 논쟁, 개인정보 피해, 의료 사고와 같은 다양한 형태의 Harm으로 연결될 수 있다.

AI 소프트웨어의 품질 특성(Quality Characteristics of AI Software)

AI 소프트웨어(AI Software)는 기존 소프트웨어(Traditional Software)처럼 기능적 특성(Functional Characteristics)과 비기능적 특성(Non-functional Characteristics)을 가진다. 하지만 AI 소프트웨어는 데이터와 모델을 기반으로 학습하고 판단하기 때문에, 기존 소프트웨어와 구분되는 추가적인 품질 특성도 함께 고려해야 한다.

AI 소프트웨어의 대표적인 품질 특성에는 적응성(Adaptability), 자율성(Autonomy), 진화성(Evolution), 유연성(Flexibility), 편향성(Bias), 성능 메트릭(Performance Metric), 투명성(Transparency), 복잡성(Complexity), 비결정성(Non-determinism)이 있다.

이러한 특성들은 AI 소프트웨어가 실제 환경에서 얼마나 안정적으로 동작하는지, 새로운 상황에 얼마나 잘 대응하는지, 판단 과정이 얼마나 설명 가능한지 등을 평가하는 데 중요한 기준이 된다.

일반 소프트웨어의 품질 특성(ISO/IEC 25010 SQuaRE)

ISO/IEC 25010 SQuaRE는 시스템과 소프트웨어의 품질 특성(Quality Characteristics)을 정의한 국제 표준이다. 특정 산업에만 한정되지 않고 금융, 자동차, 의료, 공공 시스템 등 다양한 분야의 소프트웨어 품질을 평가하는 기준으로 활용될 수 있다.

이 표준에서는 좋은 품질의 소프트웨어가 갖추어야 할 대표적인 특성으로 기능 적합성(Functional Suitability), 성능 효율성(Performance Efficiency), 호환성(Compatibility), 사용성(Usability), 신뢰성(Reliability), 보안성(Security), 유지보수성(Maintainability), 이식성(Portability)을 제시한다. 즉, 소프트웨어가 원하는 기능을 제대로 수행하고, 성능이 좋으며, 다른 시스템과 잘 호환되고, 사용하기 쉽고, 안정적이며, 보안과 유지보수 측면에서도 문제가 적어야 좋은 품질이라고 볼 수 있다.

AI 소프트웨어(AI Software)도 기본적으로 이러한 일반 소프트웨어 품질 특성을 만족해야 한다. 다만 AI 소프트웨어는 데이터(Data)와 모델(Model)을 기반으로 학습하고 판단하기 때문에, 여기에 더해 적응성(Adaptability), 자율성(Autonomy), 편향성(Bias), 투명성(Transparency), 비결정성(Non-determinism)과 같은 추가적인 품질 특성도 함께 고려해야 한다.

AI 소프트웨어의 품질 특성: 적응성, 자율성, 진화(Adaptability, Autonomy, Evolution)

AI 소프트웨어(AI Software)는 기존 소프트웨어와 달리 환경 변화나 새로운 데이터에 따라 동작 방식이 달라질 수 있다. 그중 대표적인 품질 특성으로 적응성(Adaptability), 자율성(Autonomy), 진화(Evolution)가 있다.

적응성(Adaptability)은 환경이나 상황 변화에 맞춰 소프트웨어가 자동으로 조정되는 능력이다. 예를 들어 스마트홈 시스템(Smart Home System)은 사용자의 생활 패턴을 학습하여 에너지 사용을 조절할 수 있다. 사용자가 집에 없는 시간에는 에너지를 절약하고, 수면 시간에는 온도나 습도를 조절하는 방식이 이에 해당한다.

자율성(Autonomy)은 사람의 개입 없이 소프트웨어가 스스로 작업을 수행하고 의사결정(Decision Making)을 내리는 능력이다. 대표적인 예는 자율주행 자동차(Autonomous Vehicle)이다. 자율주행 자동차는 주변 환경을 인식하고, 차선 변경(Lane Change), 속도 조절(Speed Control) 등을 판단하며 안전하게 주행해야 한다.

진화(Evolution)는 시간이 지나면서 새로운 데이터(Data)나 요구사항(Requirements)을 반영해 성능을 향상시키는 능력이다. 예를 들어 대화형 인공지능 모델(Conversational AI Model)은 특정 시점까지의 데이터를 학습해 답변을 생성한다. 이후 새로운 데이터와 요구사항을 반영해 다시 학습하거나 개선되면 더 나은 성능을 제공할 수 있다.

AI 소프트웨어의 품질 특성: 유연성, 편향성, 성능 메트릭(Flexibility, Bias, Performance Metrics)

유연성(Flexibility)은 AI 소프트웨어가 다양한 데이터 유형(Data Type)이나 작업 유형(Task Type)에 맞게 조정될 수 있는 능력이다. 예를 들어 음성 인식 소프트웨어(Speech Recognition Software)는 여러 언어, 다양한 사람의 발음, 억양, 사투리까지 인식할 수 있어야 한다. 특정한 형태의 데이터만 처리하는 것이 아니라, 다양한 입력 상황에 대응할 수 있는 능력이 유연성이다.

편향성(Bias)은 AI 모델(Model)이 특정 그룹이나 특성에 대해 치우친 예측을 내리는 경향을 말한다. 훈련 데이터(Training Data)가 특정 인종, 성별, 연령, 환경에 치우쳐 있으면 모델도 그 방향으로 편향될 수 있다. 예를 들어 AI 채용 소프트웨어(AI Recruiting Software)가 특정 성별이나 인종에게 불리한 판단을 내린다면 공정성(Fairness)에 문제가 생긴다. 따라서 AI 소프트웨어는 편향을 줄이고 공정한 판단을 할 수 있도록 관리되어야 한다.

성능 메트릭(Performance Metrics)은 AI 소프트웨어의 성능을 수치로 평가하는 기준이다. 대표적인 지표로 정확도(Accuracy), 정밀도(Precision), 재현율(Recall)이 있다.

정확도(Accuracy)는 전체 예측 중 올바르게 예측한 비율이다. 예를 들어 100개의 이메일 중 90개를 올바르게 분류했다면 정확도는 90%이다.

정밀도(Precision)는 AI가 스팸(Spam)이라고 예측한 것 중 실제로 스팸인 비율이다. 예를 들어 AI가 15개를 스팸으로 예측했고, 그중 실제 스팸이 13개라면 정밀도는 13/15이다.

재현율(Recall)은 실제 스팸 메일 중에서 AI가 스팸으로 올바르게 찾아낸 비율이다. 예를 들어 실제 스팸이 20개인데 AI가 그중 15개를 찾아냈다면 재현율은 15/20이다.

이처럼 AI 소프트웨어의 성능은 정확도, 정밀도, 재현율 같은 지표를 통해 평가할 수 있으며, 이러한 지표를 개선하는 것이 품질 향상과 연결된다.

AI 소프트웨어의 품질 특성: 투명성, 복잡성, 비결정성(Transparency, Complexity, Non-determinism)

투명성(Transparency)은 AI 소프트웨어가 어떤 근거와 과정을 통해 판단했는지 설명하거나 이해할 수 있게 하는 특성이다. AI 모델은 많은 데이터를 학습하고 복잡한 방식으로 결과를 예측하기 때문에, 내부 판단 과정을 사람이 바로 이해하기 어려울 수 있다. 예를 들어 이미지 분류 모델(Image Classification Model)이 고양이를 인식했다면, 어떤 특징을 보고 고양이라고 판단했는지 시각화하거나 설명할 수 있어야 한다. 이처럼 AI의 판단 과정을 이해 가능하게 만드는 것이 투명성이다.

복잡성(Complexity)은 AI 모델의 구조가 얼마나 복잡한지, 얼마나 많은 파라미터(Parameter)를 가지고 있는지를 의미한다. 심층 신경망(Deep Neural Network)은 매우 많은 파라미터를 사용해 데이터를 학습한다. 일반적으로 모델이 복잡할수록 더 다양한 패턴을 학습할 수 있어 성능이 높아질 수 있지만, 그만큼 내부 구조를 이해하거나 관리하기 어려워진다. 따라서 성능을 높이면서도 복잡성을 줄이려는 연구도 계속 진행되고 있다.

비결정성(Non-determinism)은 AI 모델의 결과가 항상 100% 확정적이지 않고, 확률적 판단에 기반할 수 있다는 특성이다. AI 소프트웨어는 모든 데이터를 학습할 수 없기 때문에 새로운 상황에서 정답에 가까운 결과를 예측한다. 따라서 기존 소프트웨어처럼 정해진 입력에 대해 항상 명확한 결과가 나오는 방식과는 차이가 있다. 이러한 불확실성이 AI 소프트웨어의 비결정성과 연결된다.

정리하면 AI 소프트웨어는 기존 소프트웨어의 품질 특성뿐 아니라 적응성(Adaptability), 자율성(Autonomy), 진화(Evolution), 유연성(Flexibility), 편향성(Bias), 성능 메트릭(Performance Metrics), 투명성(Transparency), 복잡성(Complexity), 비결정성(Non-determinism) 같은 추가적인 품질 특성을 함께 고려해야 한다.

3️⃣ AI Software Development and Quality

AI 소프트웨어 개발 품질(AI Software Development Quality)

AI 소프트웨어(AI Software)는 하나의 제품(Product)이기 때문에, 품질을 확보하려면 개발과 운영 과정 전체의 품질을 높이는 것이 중요하다. 앞에서 살펴본 것처럼 AI 소프트웨어는 데이터(Data), 모델(Model), 학습 과정(Training Process), 실제 운영 환경(Operational Environment)에 따라 품질 문제가 발생할 수 있다.

따라서 AI 소프트웨어의 품질을 높이기 위해서는 단순히 결과만 확인하는 것이 아니라, 개발 프로세스(Development Process)를 체계적으로 관리해야 한다. 데이터 수집, 데이터 품질 검토, 모델 학습, 평가(Evaluation), 배포(Deployment), 운영 및 모니터링(Monitoring) 과정이 잘 관리되어야 최종 AI 제품의 품질도 높아질 수 있다.

기존 소프트웨어와 마찬가지로 AI 소프트웨어도 개발 프로세스를 따르지만, AI는 데이터와 학습 과정이 핵심이기 때문에 기존 소프트웨어와는 다른 관리 기준이 필요하다. 특히 데이터 품질 기준(Data Quality Criteria), 모델 평가 기준(Model Evaluation Criteria), 운영 중 성능 변화 확인이 중요하다.

결국 AI 소프트웨어의 품질을 확보하기 위해서는 제품 자체만 보는 것이 아니라, 제품을 개발하고 운영하는 프로세스의 품질(Process Quality)을 함께 높여야 한다.

V모델(V-Model)과 AI 소프트웨어 개발(AI Software Development)

AI 소프트웨어(AI Software)도 기존 소프트웨어처럼 V모델(V-Model)을 기반으로 개발할 수 있다. V모델은 개발 단계와 테스트 단계를 서로 연결하여, 개발 초반부터 품질을 관리하는 방식이다.

기존 V모델의 왼쪽에는 고객/사용자 요구사항(Customer/User Requirements), 요구사항 분석(Requirements Analysis), 아키텍처 설계(Architecture Design), 상세 설계(Detailed Design)가 있다. 아래쪽에는 구현(Coding)이 있으며, 오른쪽에는 단위 테스팅(Unit Testing), 통합 테스팅(Integration Testing), 시스템 테스팅(System Testing), 인수 테스팅(Acceptance Testing)이 배치된다.

V모델의 핵심은 각 개발 단계에 대응되는 테스트를 함께 고려하는 것이다. 즉, 개발이 끝난 뒤에만 테스트하는 것이 아니라 요구사항과 설계 단계부터 어떤 기준으로 검증할지 생각해야 한다. 이렇게 앞단계부터 품질을 관리해야 최종 제품의 품질도 높아질 수 있다.

AI 소프트웨어도 V모델을 완전히 벗어나는 것은 아니다. 다만 AI 소프트웨어는 데이터(Data), 모델(Model), 학습(Training), 평가(Evaluation) 같은 요소가 중요하기 때문에 기존 V모델과 용어와 적용 방식에는 차이가 있을 수 있다.

V모델 기반 AI 소프트웨어 시스템 개발(V-Model-based AI Software System Development)

AI 소프트웨어(AI Software)를 포함한 전체 시스템도 V모델(V-Model)을 기반으로 개발할 수 있다. 먼저 시스템 관점에서 요구사항을 분석하고, 시스템 아키텍처(System Architecture)를 설계한다. 이후 시스템을 구성하는 요소 중 어떤 부분을 일반 소프트웨어(Traditional Software)로 개발할지, 어떤 부분을 AI 소프트웨어로 개발할지 결정한다.

일반 소프트웨어는 기존 V모델처럼 요구사항 분석(Requirements Analysis), 아키텍처/상세 설계(Architecture/Detailed Design), 구현(Coding), 단위/통합 테스팅(Unit/Integration Testing), 시스템 테스팅(System Testing)의 과정을 따른다.

AI 소프트웨어도 V모델의 개념을 적용할 수 있다. 다만 용어와 절차가 조금 다르다. AI 소프트웨어는 먼저 가능한 범위 안에서 요구사항을 정의한다. 예를 들어 “고양이와 강아지를 분류하는 모델을 만든다”와 같은 목표를 설정한다. 이후 훈련 데이터(Training Data)를 준비하고, 데이터를 기반으로 모델을 훈련(Training)한다. 그다음 평가 데이터(Evaluation Data)를 사용해 모델을 테스트하고, 최종적으로 모델이 요구사항을 만족하는지 확인한다.

이후 일반 소프트웨어와 AI 소프트웨어는 하나의 시스템으로 통합되고, 통합 테스팅(Integration Testing), 시스템 테스팅(System Testing), 인수 테스팅(Acceptance Testing)을 거쳐 최종 제품으로 완성된다.

핵심은 AI 소프트웨어도 품질 확보(Quality Assurance)를 위해 체계적인 개발 프로세스를 따라야 한다는 점이다. V모델은 개발 단계와 테스트 단계를 연결하여 초기 단계부터 품질을 관리할 수 있게 해준다.

AI 소프트웨어 개발의 주요 단계: 요구사항 분석(Requirements Analysis)

AI 소프트웨어 개발의 첫 단계는 요구사항 분석(Requirements Analysis)이다. 이 단계에서는 사용자(User), 고객(Customer), 이해관계자(Stakeholder)의 요구사항을 이해하고, AI가 해결해야 할 문제를 정의한다.

AI 소프트웨어는 기존 소프트웨어처럼 모든 요구사항을 완벽하게 정의하기 어렵지만, 가능한 범위 안에서 목표와 기준을 정해야 한다. 예를 들어 고양이 판별 AI를 만든다면, 단순히 고양이인지 아닌지만 분류할 것인지, 다른 동물도 함께 구분할 것인지, 고양이의 품종까지 세부적으로 분류할 것인지 등을 정해야 한다.

또한 입력 데이터(Input Data)의 범위도 요구사항에 포함된다. 고양이 얼굴만 판별할 것인지, 전신 이미지를 대상으로 할 것인지, 국내 고양이만 다룰 것인지 전 세계 다양한 고양이를 포함할 것인지도 결정해야 한다.

AI 소프트웨어에서는 성능 메트릭(Performance Metrics)도 중요한 요구사항이 된다. 예를 들어 정확도(Accuracy) 90%, 정밀도(Precision) 85%, 재현율(Recall) 90%와 같이 목표 성능을 정할 수 있다.

결국 AI 소프트웨어의 요구사항 분석은 기능적 요구사항(Functional Requirements)뿐만 아니라, 일반 소프트웨어 품질 특성과 AI 소프트웨어 고유의 품질 특성을 함께 고려하여 정리하는 과정이다.

훈련 데이터 준비(Training Data Preparation)

AI 소프트웨어 개발의 다음 단계는 훈련 데이터 준비(Training Data Preparation)이다. 요구사항 분석을 통해 AI가 어떤 문제를 해결해야 하는지 정했다면, 그 요구사항을 만족할 수 있는 데이터셋(Dataset)을 설계하고 준비해야 한다.

예를 들어 요구사항이 “고양이인지 아닌지만 판별한다”라면, 이미지마다 “고양이(Cat)” 또는 “고양이가 아님(Not Cat)”이라는 레이블(Label)이 붙은 데이터를 준비하면 된다.

반면 고양이의 종류까지 구분해야 한다면, 고양이 품종마다 다른 레이블을 부여한 이미지 데이터가 필요하다. 이 경우 단순한 이진 분류(Binary Classification)가 아니라 여러 종류를 구분하는 다중 분류(Multi-class Classification)가 된다.

또한 같은 종류의 고양이라도 자세, 배경, 밝기, 촬영 각도 등이 다양한 이미지를 준비해야 한다. 그래야 AI 모델(Model)이 특정 조건에만 맞춰지는 것이 아니라, 다양한 상황에서도 고양이를 잘 판별할 수 있다.

즉, 훈련 데이터 준비는 AI 소프트웨어의 요구사항에 맞게 데이터를 수집하고, 레이블을 붙이고, 다양한 상황을 반영하도록 데이터셋을 구성하는 과정이다.

모델 훈련과 테스트(Model Training and Testing)

세 번째 단계는 준비한 훈련 데이터(Training Data)를 이용해 AI 모델(Model)을 훈련하고, 모델이 제대로 학습되었는지 테스트하는 과정이다. 이 단계에서는 적절한 AI 모델을 선택하고, 훈련용 데이터셋(Training Dataset)을 기반으로 학습을 진행한다.

훈련이 끝난 뒤에는 훈련 데이터에 포함되지 않은 새로운 데이터(Unseen Data)나 테스트 데이터셋(Test Dataset)을 사용해 모델 성능을 평가해야 한다. 훈련 데이터에서만 성능이 좋고 새로운 데이터에서 성능이 낮다면, 실제 환경에서는 원하는 결과를 내기 어렵기 때문이다.

평가 결과가 부족하다면 선택한 AI 모델이 적절한지, 파라미터(Parameter)가 잘 설정되었는지, 훈련 데이터의 양이 충분한지, 데이터가 편향(Bias)되어 있지는 않은지 점검해야 한다. 필요하다면 모델을 수정하거나 데이터를 보완한 뒤 다시 훈련과 테스트를 진행한다.

또한 AI 소프트웨어는 한 번 높은 성능이 나왔다고 끝나는 것이 아니다. 실제 환경에서는 새로운 데이터와 상황이 계속 등장하기 때문에 지속적인 테스트(Continuous Testing)가 필요하다. 제품이 사용되는 동안 모델의 성능을 계속 확인하고, 필요한 경우 재학습(Retraining)이나 업데이트(Update)를 통해 품질을 유지해야 한다.

일반 소프트웨어와 AI 소프트웨어 개발의 차이(Difference Between Traditional Software and AI Software Development)

일반 소프트웨어(Traditional Software)와 AI 소프트웨어(AI Software)의 차이는 연역(Deduction)과 귀납(Induction)의 개념으로 이해할 수 있다.

일반 소프트웨어는 연역적(Deductive) 방식에 가깝다. 먼저 요구사항(Requirements)이라는 큰 전제를 정하고, 이를 만족하기 위해 설계(Design), 구현(Implementation), 테스트(Testing)를 구체화한다. 따라서 요구사항을 기준으로 예상 결과(Expected Result)를 정의하고, 실제 결과가 이를 만족하는지 테스트할 수 있다.

반면 AI 소프트웨어는 귀납적(Inductive) 방식에 가깝다. 개별 데이터 사례를 학습하고, 그 사례들로부터 일반적인 패턴이나 규칙을 찾아낸다. 예를 들어 여러 고양이 데이터를 보고 고양이의 특징을 학습한 뒤, 새로운 이미지가 들어왔을 때 고양이인지 판단하는 방식이다. Example: Observation 1: Every swan I have ever seen is white. Observation 2: Every swan my friends have seen is white. Conclusion: Therefore, all swans are white.

AI 소프트웨어는 모든 가능한 사례를 데이터로 수집하고 학습할 수 없기 때문에, 요구사항을 기존 소프트웨어처럼 명확하게 정의하기 어렵다. 알려지지 않은 상황(Unknown)이 많고, 실제 환경에서 새로운 데이터가 계속 등장하기 때문이다. 그래서 AI 소프트웨어는 일반 소프트웨어와 다른 개발 및 테스트 기법이 필요하다.

소프트웨어 버전과 버전 관리 (Software Version & Version Control)

소프트웨어에서 버전(Version) 은 특정 소프트웨어나 코드의 상태를 구분하기 위해 붙이는 식별자(Identifier) 이다. 우리가 스마트폰 앱이나 운영체제를 업데이트할 때 “현재 버전”, “최신 버전”, “업데이트 버전”이라는 표현을 자주 접하는데, 이때의 버전은 단순한 숫자가 아니라 해당 소프트웨어가 어느 시점의 상태인지 알려주는 기준이 된다.

예를 들어 어떤 프로그램에 문제가 생겨 고객센터에 문의하면, 보통 “어떤 버전을 사용하고 있나요?”라는 질문을 받는다. 이는 같은 프로그램이라도 버전에 따라 기능, 오류, 동작 방식이 다를 수 있기 때문이다. 따라서 버전은 소프트웨어를 구분하고 문제를 추적하기 위한 중요한 정보가 된다.

버전을 이해하기 위해 먼저 식별자(Identifier) 의 개념을 볼 필요가 있다. 식별자는 어떤 대상을 다른 대상과 구분하기 위해 붙이는 이름이나 번호를 말한다. 사람에게는 이름이나 학번, 사물에는 제품 번호나 모델명 등이 식별자가 될 수 있다. 이름만으로도 대상을 구분할 수 있지만, 번호를 사용하면 더 정확하고 세부적으로 구분할 수 있다. 그래서 소프트웨어 버전에서는 보통 숫자를 많이 사용한다. 숫자는 순서를 나타내기 쉽고, 변경 이력을 관리하기에도 편리하기 때문이다.

코드를 작성할 때도 버전의 개념이 필요하다. 아주 짧고 단순한 코드는 수정하거나 변경할 일이 거의 없을 수도 있다. 하지만 실제 소프트웨어 개발에서는 코드가 계속 수정되고 확장된다. 기능이 추가되거나 오류가 고쳐지고, 구조가 바뀌는 일이 반복된다. 이때 변경된 코드들을 모두 같은 것으로 볼 것인지, 아니면 서로 다른 상태로 구분할 것인지가 중요해진다.

컴퓨터 입장에서는 줄바꿈이나 빈칸 같은 변화가 실행 결과에 영향을 주지 않을 수도 있다. 예를 들어 일부 프로그래밍 언어에서는 공백이나 줄바꿈이 프로그램의 동작에 큰 영향을 주지 않는다. 하지만 사람 입장에서는 코드의 가독성, 구조, 이해도에 큰 차이를 만들 수 있다. 따라서 어떤 변경을 버전으로 구분할 것인지, 어떤 변경은 단순한 편집으로 볼 것인지도 버전 관리에서 생각해야 할 부분이다.

버전이라는 개념은 디지털 시대에만 생긴 것은 아니다. 컴퓨터가 널리 사용되기 전에도 문서, 서류, 설계도, 계약서 등은 종이 형태로 관리되었다. 같은 문서라도 작성 날짜가 다르거나 서식이 바뀌거나 내용이 수정되면 서로 다른 문서로 구분해야 했다. 이때도 “완전히 다른 문서로 볼 것인가?”, “같은 문서의 수정본으로 볼 것인가?”와 같은 판단이 필요했다. 이러한 개념이 소프트웨어 개발에서도 이어져, 변경된 내용을 기록하고 이전 상태와 비교하며 필요할 때 재사용할 수 있도록 발전한 것이 버전 관리(Version Control) 이다.

소프트웨어에서는 버전을 보통 숫자로 표시한다. 예를 들어 1.0, 1.1, 2.0과 같은 형태가 대표적이다. 숫자 버전은 소프트웨어의 변경 정도나 출시 순서를 표현하기 쉽다. 그러나 숫자만으로는 사람이 기억하거나 부르기 어려울 때도 있다. 그래서 소프트웨어나 프로젝트에 코드명(Code Name) 또는 프로젝트명(Project Name) 을 붙이기도 한다.

예를 들어 어떤 소프트웨어의 공식 버전은 숫자로 관리하되, 개발 과정이나 출시 단계에서는 사람이 부르기 쉬운 이름을 함께 사용할 수 있다. 숫자 버전은 정확한 식별에 유리하고, 코드명이나 프로젝트명은 의사소통과 기억에 유리하다. 즉, 버전 번호와 코드명은 서로 다른 목적을 가진다. 버전 번호는 정확한 구분을 위한 것이고, 코드명은 사람이 쉽게 이해하고 부르기 위한 이름에 가깝다.

결국 소프트웨어 버전은 단순히 숫자를 붙이는 작업이 아니라, 소프트웨어의 변화 과정을 기록하고 구분하는 체계이다. 어떤 기능이 추가되었는지, 어떤 오류가 수정되었는지, 어떤 시점의 코드가 사용되었는지를 알기 위해 버전이 필요하다. 이러한 버전 정보가 체계적으로 관리되어야 여러 사람이 함께 개발할 때 혼란을 줄이고, 문제가 발생했을 때 원인을 추적할 수 있다.

따라서 버전 관리(Version Control) 는 소프트웨어 개발에서 매우 중요한 개념이다. 버전 관리를 통해 개발자는 변경 이력을 남기고, 이전 상태로 되돌아가거나, 여러 개발자가 동시에 작업한 내용을 비교하고 통합할 수 있다. 소프트웨어가 계속 변화하는 대상이라는 점에서, 버전은 그 변화를 기록하고 관리하기 위한 기본 단위라고 할 수 있다.

버전 표기 방식 (Version Numbering)

소프트웨어의 버전 표기 방식(Version Numbering) 은 소프트웨어의 변경 정도를 쉽게 구분하기 위해 사용된다. 기본적으로는 숫자를 사용하며, 숫자를 어떻게 배치하느냐에 따라 소프트웨어가 얼마나 크게 바뀌었는지, 어떤 성격의 변경이 있었는지를 파악할 수 있다.

대표적인 방식으로 시맨틱 버저닝(Semantic Versioning, SemVer) 이 있다. 시맨틱 버저닝은 보통 MAJOR.MINOR.PATCH 형식으로 버전을 표기한다. 예를 들어 2.1.3이라는 버전이 있다면, 2는 메이저 버전(Major Version), 1은 마이너 버전(Minor Version), 3은 패치 버전(Patch Version) 을 의미한다.

메이저 버전(Major Version) 은 기존 버전과 호환되지 않을 정도로 큰 변화가 있을 때 증가한다. 예를 들어 기존에 사용하던 API(Application Programming Interface) 가 크게 바뀌어 이전 방식으로는 더 이상 정상적으로 사용할 수 없다면 메이저 버전이 올라간다.

마이너 버전(Minor Version) 은 기존 버전과 호환성을 유지하면서 새로운 기능이 추가되었을 때 증가한다. 즉, 기존 사용자는 큰 문제 없이 계속 사용할 수 있지만, 새로운 기능이 더해진 경우이다.

패치 버전(Patch Version) 은 기존 버전과 호환성을 유지하면서 버그를 수정했을 때 증가한다. 새로운 기능을 추가하기보다는 오류를 고치거나 안정성을 개선하는 변경에 해당한다.

따라서 MAJOR.MINOR.PATCH 형식의 번호만 보아도 소프트웨어가 완전히 크게 바뀐 것인지, 기능이 조금 추가된 것인지, 단순히 오류가 수정된 것인지 어느 정도 파악할 수 있다. 예를 들어 1.2.3에서 1.2.4로 바뀌었다면 보통 작은 버그 수정으로 이해할 수 있고, 1.2.3에서 2.0.0으로 바뀌었다면 기존과 호환되지 않는 큰 변화가 있었을 가능성이 높다.

하지만 모든 소프트웨어가 반드시 이 규칙을 따르는 것은 아니다. 시맨틱 버저닝은 널리 사용되는 규칙이지만, 프로젝트의 성격이나 개발 문화에 따라 버전 번호를 다르게 정하는 경우도 많다. 어떤 프로젝트는 날짜를 버전으로 사용하기도 하고, 어떤 프로젝트는 내부 기준에 따라 메이저 번호를 올리기도 한다.

숫자 뒤에는 문자나 단어가 추가되기도 한다. 대표적으로 알파(Alpha), 베타(Beta), 릴리스 후보(Release Candidate, RC) 가 있다. 시맨틱 버저닝에서는 정식 릴리스 전 버전을 1.0.0-alpha, 1.0.0-beta, 1.0.0-rc.1과 같은 방식으로 표기할 수 있다. 이러한 표기는 아직 최종 배포 전 단계라는 의미를 가진다.

알파 버전(Alpha Version) 은 개발 초기 테스트 단계에 가깝다. 프로그램의 주요 기능이 어느 정도 만들어졌더라도 아직 안정성이 부족할 수 있고, 개발자나 내부 테스트 인원이 문제를 찾는 단계라고 볼 수 있다.

베타 버전(Beta Version) 은 알파보다 더 완성도 있는 테스트 단계이다. 기능이 어느 정도 마무리된 상태에서 실제 사용자 환경에 가깝게 테스트하는 경우가 많다. 프로젝트에 따라 일반 사용자에게 공개되기도 하고, 제한된 사용자에게만 제공되기도 한다.

릴리스 후보(Release Candidate, RC) 는 정식 배포 직전 단계의 버전이다. 큰 문제가 발견되지 않으면 이 버전이 최종 릴리스로 이어질 수 있다. 즉, “이 정도면 배포해도 될 것 같다”라고 판단되는 후보 버전이라고 이해할 수 있다.

다만 알파, 베타, 릴리스 후보의 의미도 프로젝트마다 조금씩 다를 수 있다. 어떤 프로젝트에서는 베타 단계에서도 기능이 추가될 수 있고, 어떤 프로젝트에서는 베타 이후부터는 새 기능을 넣지 않고 버그 수정만 진행하기도 한다. 따라서 이러한 용어는 일반적인 흐름을 이해하는 기준으로 보면 된다.

리눅스 커널(Linux Kernel) 도 버전 번호를 사용하지만, 현재의 리눅스 커널 버전 방식은 시맨틱 버저닝을 엄격하게 따르는 방식이라고 보기는 어렵다. 과거 리눅스 커널은 버전 번호에서 안정 버전과 개발 버전을 구분하는 규칙을 사용한 적이 있다. 예를 들어 2.x 시기에는 짝수 마이너 버전을 안정 버전, 홀수 마이너 버전을 개발 버전으로 구분하는 방식이 사용되었다. 그러나 2.6 커널 이후에는 이러한 방식이 더 이상 사용되지 않게 되었다.

최근의 리눅스 커널에서는 메이저 버전이 올라간다고 해서 반드시 API가 크게 깨지거나, 엄청난 기능 변화가 있었다는 뜻은 아니다. 리누스 토르발스(Linus Torvalds)는 리눅스 커널의 큰 버전 번호 변경이 기능 기반이나 안정/불안정 구분을 의미하지 않으며, 큰 숫자를 피하기 위한 성격도 있다고 설명한 바 있다. 따라서 리눅스 커널의 버전 번호는 시맨틱 버저닝의 MAJOR.MINOR.PATCH 의미와 그대로 대응시키기보다는, 리눅스 커널 프로젝트 고유의 릴리스 흐름으로 이해하는 것이 더 정확하다.

결국 버전 표기 방식은 소프트웨어의 변경 이력을 간단하고 명확하게 전달하기 위한 약속이다. 시맨틱 버저닝(Semantic Versioning) 은 그중 가장 널리 알려진 방식이지만, 모든 프로젝트가 반드시 같은 방식으로 버전을 관리하는 것은 아니다. 따라서 버전 번호를 볼 때는 숫자의 형식뿐만 아니라, 해당 프로젝트가 어떤 버전 정책을 사용하는지도 함께 확인해야 한다.

리눅스 라이브러리 버전 표기 방식 (Linux Library Versioning)

소프트웨어 버전 표기 방식에는 앞서 살펴본 시맨틱 버저닝(Semantic Versioning) 외에도 여러 방식이 존재한다. 특히 리눅스/유닉스 계열에서 사용되는 공유 라이브러리(Shared Library) 의 버전 표기에는 일반적인 MAJOR.MINOR.PATCH 방식과 다른 기준이 사용되기도 한다.

그 예로 Libtool 버전 정보(Libtool Version Info) 에서 사용하는 current:revision:age 형식이 있다. 여기서 current, revision, age는 단순히 “큰 변경, 작은 변경, 버그 수정”을 의미하는 것이 아니라, 라이브러리의 인터페이스(Interface) 와 호환성(Compatibility) 을 기준으로 해석된다. GNU Libtool 문서에 따르면 current는 해당 라이브러리가 구현하는 가장 최신 인터페이스 번호이고, revision은 현재 인터페이스의 구현 번호이며, age는 최신 인터페이스와 가장 오래된 호환 인터페이스 사이의 차이를 의미한다.

이 방식은 특히 라이브러리의 ABI(Application Binary Interface) 호환성을 관리하기 위해 사용된다. 프로그램이 어떤 공유 라이브러리를 사용할 때, 단순히 기능이 추가되었는지만 중요한 것이 아니라 기존 프로그램이 새 라이브러리와 함께 실행되어도 문제가 없는지가 중요하다. 그래서 current:revision:age 방식은 라이브러리가 어떤 인터페이스 범위까지 호환되는지를 표현하기 위한 목적을 가진다.

예를 들어 current는 라이브러리가 제공하는 최신 인터페이스 번호를 나타내고, age는 그 라이브러리가 과거의 몇 단계 인터페이스까지 호환되는지를 나타낸다. 따라서 current - age부터 current까지의 인터페이스를 지원한다고 볼 수 있다. 만약 current와 age가 같은 두 라이브러리가 있다면, 동적 링커(Dynamic Linker)는 보통 더 높은 revision 값을 가진 라이브러리를 선택한다.

이 점에서 current:revision:age는 시맨틱 버저닝(Semantic Versioning) 과 구분된다. 시맨틱 버저닝의 MAJOR.MINOR.PATCH는 일반적으로 API 변경 정도를 사람이 이해하기 쉽게 표현하는 방식이다. 반면 current:revision:age는 라이브러리 인터페이스와 바이너리 호환성을 관리하기 위한 도구적 성격이 강하다. 즉, 숫자가 세 부분으로 나뉘어 있다는 점은 비슷하지만, 각 숫자가 의미하는 바는 서로 다르다.

또한 이 방식은 보통 사람이 직접 보는 제품 버전이라기보다는, 빌드 도구나 운영체제의 라이브러리 로딩 과정에서 의미를 가지는 경우가 많다. Libtool 은 current:revision:age 정보를 바탕으로 각 플랫폼에 맞는 공유 라이브러리 버전 이름을 생성한다. 따라서 이 숫자들을 일반적인 소프트웨어 출시 버전처럼 해석하면 혼동이 생길 수 있다.

최근에는 모든 프로젝트가 이러한 기준을 엄격하게 따르지는 않는다. 소프트웨어 규모가 커지고 개발 주기가 빨라지면서, 버전 번호를 어떤 기준으로 올릴 것인지가 프로젝트마다 달라졌기 때문이다. 실제로 Libtool 문서에서도 버전 정보를 너무 자주 갱신하면 current 인터페이스 번호가 빠르게 커질 수 있으므로, 공개 릴리스 직전에만 업데이트하라고 설명한다.

예전에는 버전 번호가 한 자리나 두 자리 수준인 경우가 많아 비교적 단순하게 느껴졌지만, 시간이 지나면서 .20, .30을 넘어 .110, .111처럼 세 자리 숫자가 등장하는 경우도 생겼다. 이렇게 숫자가 커지면 사용자가 버전 번호만 보고 변경 의미를 직관적으로 파악하기 어려워질 수 있다. 그래서 어떤 프로젝트는 시맨틱 버저닝을 따르고, 어떤 프로젝트는 날짜 기반 버전(Date-based Versioning)을 사용하며, 또 어떤 프로젝트는 자체적인 릴리스 정책에 따라 버전을 붙인다.

결국 버전 표기 방식은 하나의 고정된 정답이 아니라, 프로젝트의 목적과 관리 방식에 따라 선택되는 약속이다. 시맨틱 버저닝(Semantic Versioning) 은 사람이 변경 정도를 이해하기 쉽게 만드는 데 유용하고, Libtool의 current:revision:age 방식 은 리눅스/유닉스 계열 공유 라이브러리의 인터페이스와 바이너리 호환성을 관리하는 데 유용하다. 따라서 버전 번호를 볼 때는 숫자의 형식만 보고 판단하기보다, 해당 프로젝트가 어떤 버전 정책을 사용하는지 함께 확인해야 한다.

버전 관리와 소프트웨어 개발의 핵심 도구 (Version Control & Core Tool for Software Development)

소프트웨어 개발에서 버전(Version) 을 숫자로 표기하는 것도 중요하지만, 실제 개발 과정에서는 그 버전을 어떻게 기록하고 관리할 것인지가 더 중요하다. 단순히 1.0, 2.1.3과 같은 숫자를 붙이는 것만으로는 충분하지 않다. 누가 그 버전을 결정했는지, 어떤 파일들이 그 버전에 포함되는지, 이전 버전과 무엇이 달라졌는지를 함께 관리해야 하기 때문이다.

초기에는 별도의 버전 관리 도구(Version Control Tool) 없이 파일 안에 직접 버전 정보를 적는 방식이 사용되었다. 예를 들어 코드 파일의 주석(Comment)에 “이 파일은 1.0 버전이다”, “현재 버전은 2.1.3이다”와 같은 내용을 남기는 식이었다. 파일 수가 적고 개발자가 한 명이거나 소규모인 경우에는 이런 방식도 어느 정도 효과가 있었다. 이는 종이 문서를 관리하던 방식과 비슷하다. 종이 문서에서도 작성일, 수정일, 문서 번호, 개정 번호 등을 표시하여 어떤 문서가 최신인지 구분했는데, 이러한 관리 방식이 초기 소프트웨어 개발에도 이어진 것이다.

하지만 소프트웨어의 규모가 커지면서 상황이 달라졌다. 코드 파일이 10개, 100개, 1000개로 늘어나고, 여러 개발자가 동시에 프로젝트에 참여하게 되면서 단순히 파일 안에 주석으로 버전 정보를 적는 방식은 한계가 생겼다. 어떤 파일이 언제 수정되었는지, 누가 수정했는지, 어떤 이유로 바뀌었는지, 이전 상태로 되돌릴 수 있는지 등을 사람이 직접 관리하기 어려워졌기 때문이다.

이러한 문제를 해결하기 위해 등장한 것이 버전 관리 시스템(Version Control System, VCS) 이다. 버전 관리 시스템은 프로젝트의 변경 이력을 추적하고, 파일의 상태를 관리하며, 여러 개발자가 협업할 수 있도록 도와주는 소프트웨어 개발의 핵심 도구이다.

버전 관리 시스템을 사용하면 개발자는 코드의 변경 내용을 기록할 수 있다. 어떤 파일이 수정되었는지, 어떤 줄이 추가되거나 삭제되었는지, 누가 언제 변경했는지 확인할 수 있다. 또한 문제가 발생했을 때 이전 상태로 되돌아가거나, 특정 시점의 코드를 다시 확인할 수도 있다. 이러한 기능은 개인 개발뿐만 아니라 팀 개발에서도 매우 중요하다.

과거에는 소규모 팀이나 개인 프로젝트에서는 이력 추적이 크게 중요하지 않다고 생각할 수도 있었다. 하지만 현대 소프트웨어 개발 환경에서는 코드의 양이 많든 적든 버전 관리 도구를 사용하는 것이 거의 기본이 되었다. 작은 프로젝트라도 시간이 지나면 수정 내용이 누적되고, 실수로 코드를 잘못 변경할 수 있으며, 이전 상태를 확인해야 할 일이 생기기 때문이다. 따라서 오늘날에는 개인 프로젝트에서도 Git 과 같은 버전 관리 도구를 사용하는 것이 일반적이다.

대표적인 버전 관리 도구로는 Git 이 있다. Git은 현재 가장 널리 사용되는 분산 버전 관리 시스템(Distributed Version Control System) 중 하나이다. 특히 리눅스 커널(Linux Kernel) 소스 코드는 Git을 사용해 관리된다. 리눅스 커널은 매우 큰 규모의 오픈소스 프로젝트이며, 전 세계의 많은 개발자가 참여한다. 이런 프로젝트에서는 변경 이력을 정확하게 추적하고, 여러 개발자의 작업을 조율하는 것이 매우 중요하기 때문에 Git과 같은 도구가 필수적이다.

버전 관리 도구는 특히 텍스트 파일(Text File) 로 작성된 소스 코드를 관리하는 데 강점을 가진다. 소스 코드는 대부분 문자로 이루어져 있고, 줄(Line) 단위로 구성되어 있기 때문에 이전 버전과 현재 버전을 비교하기 쉽다. 예를 들어 어떤 줄이 추가되었는지, 어떤 줄이 삭제되었는지, 어떤 함수가 수정되었는지를 비교할 수 있다. 이러한 비교 결과를 차이 비교(Diff) 라고 한다.

반면 바이너리 파일(Binary File) 은 텍스트 파일처럼 줄 단위로 비교하기 어렵다. 바이너리 파일은 실행 파일, 이미지, 영상, 압축 파일, 오디오 파일처럼 사람이 직접 읽는 문자 구조가 아니라 연속된 바이트(Byte) 데이터로 구성된다. 텍스트 파일은 줄바꿈 문자(Newline Character)인 \n 또는 \r\n을 기준으로 줄을 나눌 수 있지만, 바이너리 파일에는 이런 줄 구조가 명확하지 않다.

따라서 바이너리 파일은 텍스트 소스 코드처럼 “몇 번째 줄이 바뀌었다”라고 비교하기 어렵다. 물론 Git 같은 도구도 바이너리 파일 자체를 저장하고 관리할 수는 있지만, 텍스트 파일처럼 세부 변경 내용을 보기 좋게 비교하는 데에는 한계가 있다. 예를 들어 이미지 파일이 수정되었다면 Git은 “파일이 변경되었다”는 사실은 알 수 있지만, 일반적인 텍스트 코드처럼 “어떤 줄이 추가되었다”라고 보여주기는 어렵다.

결국 버전 관리 시스템은 소프트웨어 개발에서 변경 이력을 체계적으로 관리하기 위한 도구이다. 과거에는 파일 안에 버전 정보를 직접 적는 방식도 사용되었지만, 현대 개발 환경에서는 Git과 같은 전문적인 버전 관리 도구를 사용하는 것이 표준에 가깝다. 특히 여러 사람이 협업하거나 프로젝트가 장기적으로 유지되는 경우, 버전 관리는 선택이 아니라 필수적인 개발 과정이라고 할 수 있다.

버전 관리 유형: 분산 관리와 중앙 관리 (Types of Version Control: Distributed & Centralized)

버전 관리 시스템(Version Control System, VCS) 은 프로젝트의 변경 이력을 관리하는 방식에 따라 크게 분산 버전 관리(Distributed Version Control) 와 중앙 집중식 버전 관리(Centralized Version Control) 로 나눌 수 있다. 이 구분은 우리가 일상에서 접하는 여러 시스템과도 비슷하다. 예를 들어 정부나 조직 운영 방식에서도 권한과 정보가 여러 곳에 나뉘어 있는 분산 구조(Distributed Structure) 가 있고, 한 곳에 모여 있는 중앙집중 구조(Centralized Structure) 가 있다. 버전 관리도 이와 비슷하게, 변경 이력을 어디에 저장하고 어떻게 공유하느냐에 따라 방식이 달라진다.

1. 분산 버전 관리 (Distributed Version Control)

분산 버전 관리(Distributed Version Control) 는 말 그대로 프로젝트의 저장소가 여러 곳에 나뉘어 존재하는 방식이다. 각 개발자는 단순히 파일 일부만 내려받는 것이 아니라, 프로젝트의 변경 이력까지 포함한 거의 완전한 저장소 사본을 자신의 컴퓨터에 보관한다.

즉, 개발자 A, B, C가 같은 프로젝트를 작업한다면 각자의 컴퓨터에는 단순한 코드 파일뿐만 아니라, 과거 변경 이력과 커밋 기록까지 포함된 저장소가 존재한다. 그래서 중앙 서버에 항상 접속하지 않아도 자신의 컴퓨터에서 변경 이력을 확인하거나, 새로운 변경 내용을 기록할 수 있다.

이 방식에서는 “원본 저장소가 어디인가?”라는 질문이 생길 수 있다. 분산 방식에서는 기술적으로 각 저장소가 독립적인 이력을 가지고 있기 때문에, 반드시 하나의 원본만 존재해야 하는 것은 아니다. 다만 실제 협업에서는 보통 팀이 기준이 되는 저장소를 정한다. 예를 들어 GitHub, GitLab, Bitbucket 같은 원격 저장소(Remote Repository)를 기준 저장소로 삼고, 개발자들은 자신의 로컬 저장소(Local Repository)에서 작업한 뒤 변경 내용을 주고받는다.

대표적인 분산 버전 관리 도구로는 Git 과 Mercurial 이 있다. 특히 Git은 오늘날 가장 널리 사용되는 버전 관리 도구 중 하나이며, 리눅스 커널(Linux Kernel)을 비롯한 많은 오픈소스 프로젝트와 실무 개발 환경에서 사용된다.

분산 버전 관리의 장점은 중앙 서버에 문제가 생겨도 각 개발자의 로컬 저장소에 이력이 남아 있다는 점이다. 인터넷 연결이 없거나 중앙 서버에 접속할 수 없는 상황에서도 커밋(Commit), 로그 확인(Log), 브랜치 생성(Branch) 같은 작업을 할 수 있다. 또한 여러 저장소끼리 변경 내용을 주고받을 수 있기 때문에 유연한 협업 구조를 만들 수 있다.

하지만 분산 방식도 단점이 있다. 저장소 구조와 브랜치, 병합(Merge), 충돌 해결(Conflict Resolution) 같은 개념을 이해해야 하므로 처음 배우는 입장에서는 복잡하게 느껴질 수 있다. 또한 팀의 기준 저장소를 명확히 정하지 않으면 어떤 버전이 공식 버전인지 혼란이 생길 수 있다.

1. 중앙 집중식 버전 관리 (Centralized Version Control)

중앙 집중식 버전 관리(Centralized Version Control) 는 프로젝트의 저장소와 변경 이력이 중앙 서버 한 곳에 모여 있는 방식이다. 개발자들은 중앙 저장소(Central Repository)에 접속하여 파일을 내려받고, 수정한 뒤 다시 중앙 저장소에 반영한다.

이 방식에서는 원본이 비교적 명확하다. 프로젝트의 공식 이력과 파일은 중앙 서버에 있고, 개발자들은 그 중앙 서버를 기준으로 작업한다. 예를 들어 개발자 A, B, C, D가 있든, 천 명이나 만 명의 개발자가 있든 모두 같은 중앙 저장소를 바라보게 된다.

대표적인 중앙 집중식 버전 관리 도구로는 SVN(Subversion) 과 Perforce 가 있다. SVN은 과거부터 많이 사용된 중앙 집중식 버전 관리 시스템이고, Perforce는 대규모 프로젝트나 게임 개발처럼 대용량 파일과 엄격한 파일 잠금(File Locking)이 필요한 환경에서 사용되는 경우가 많다.

중앙 집중식 버전 관리의 장점은 구조가 비교적 단순하다는 점이다. 원본 저장소가 중앙에 있으므로 어떤 저장소가 기준인지 명확하고, 권한 관리나 접근 제어를 중앙에서 통제하기 쉽다. 회사나 조직 입장에서는 누가 어떤 파일에 접근할 수 있는지, 어떤 변경을 반영할 수 있는지 관리하기 편리하다.

하지만 단점도 분명하다. 중앙 서버나 스토리지에 접근할 수 없으면 개발자들이 주요 작업을 진행하기 어렵다. 특히 커밋이나 최신 이력 확인처럼 중앙 저장소와 연결이 필요한 작업이 제한될 수 있다. 또한 중앙 저장소에 장애가 발생하면 전체 팀의 작업 흐름이 영향을 받을 수 있다.

중앙 집중식 버전 관리에서도 개발자 컴퓨터에 파일이 잠시 저장될 수는 있다. 하지만 이것은 보통 캐싱(Caching) 이나 작업 사본(Working Copy)에 가깝다. 프로젝트의 공식 변경 이력과 원본 저장소는 중앙 서버에 보관된다. 이 점이 분산 버전 관리와의 큰 차이이다.

공유 디스크와 버전 관리 시스템의 차이 (Shared Disk vs Version Control System)

중앙 집중식 버전 관리를 보면 NFS(Network File System) 같은 공유 디스크를 사용하는 것과 비슷해 보일 수 있다. 예를 들어 하나의 서버에 있는 디렉토리를 개발자 A와 B가 함께 사용한다면, 모두 같은 파일을 보는 구조이므로 중앙 저장소와 비슷하게 느껴질 수 있다.

하지만 공유 디스크와 버전 관리 시스템은 목적과 기능이 다르다. 공유 디스크는 기본적으로 파일을 여러 사람이 함께 접근할 수 있게 해주는 저장 공간이다. 모든 개발자가 같은 디렉토리의 파일을 열고 수정할 수 있다. 그러나 이것만으로는 변경 이력을 체계적으로 관리하기 어렵다.

반면 버전 관리 시스템(Version Control System) 은 단순히 파일을 공유하는 것을 넘어, 누가 언제 어떤 내용을 수정했는지 기록한다. 이전 버전과 현재 버전을 비교할 수 있고, 특정 시점으로 되돌아갈 수도 있으며, 여러 사람이 동시에 작업한 내용을 병합하거나 충돌을 해결할 수도 있다. 또한 커밋 메시지(Commit Message)를 통해 변경 이유를 남길 수 있고, 브랜치(Branch)를 사용해 기능 개발과 안정 버전을 분리할 수도 있다.

따라서 공유 디스크는 “같은 파일을 함께 쓰는 공간”에 가깝고, 버전 관리 시스템은 “변경 이력을 추적하고 협업을 체계적으로 관리하는 도구”에 가깝다. 겉으로 보기에는 둘 다 중앙 서버에 파일이 있다는 점에서 비슷해 보일 수 있지만, 실제 개발 관리 측면에서는 버전 관리 시스템이 훨씬 엄격하고 편리한 기능을 제공한다.

결국 분산 방식과 중앙 집중 방식은 어느 한쪽이 항상 더 좋다고 말하기 어렵다. 분산 버전 관리(Distributed Version Control) 는 각 개발자가 완전한 이력을 가지고 독립적으로 작업할 수 있다는 장점이 있고, 중앙 집중식 버전 관리(Centralized Version Control) 는 기준 저장소가 명확하고 중앙 통제가 쉽다는 장점이 있다. 프로젝트의 규모, 협업 방식, 보안 요구사항, 파일의 종류에 따라 적절한 방식을 선택하는 것이 중요하다.

버전 관리의 특징 (Features of Version Control)

버전 관리(Version Control) 는 단순히 파일을 공유하는 것에서 끝나지 않는다. 앞에서 NFS(Network File System) 같은 공유 디스크와 비교했을 때, “공유한다”는 관점에서는 비슷해 보일 수 있다. 하지만 버전 관리 시스템은 단순 공유보다 훨씬 더 엄격하고 체계적인 기준과 기능을 제공한다. 핵심은 파일을 저장하는 것뿐만 아니라, 파일의 변경 이력을 관리하고, 이전 상태로 되돌리고, 여러 사람이 함께 작업할 수 있게 해준다는 점이다.

초기에는 별도의 버전 관리 도구(Version Control Tool) 없이 매우 원시적인 방식으로 파일을 관리하기도 했다. 예를 들어 문서 파일이나 코드 파일을 수정할 때 기존 파일과 같은 이름으로 저장하면 이전 내용은 사라진다. 어제 작성한 내용과 오늘 수정한 내용의 차이를 알기 어렵고, 실수로 덮어쓰면 이전 상태로 돌아가기도 어렵다.

그래서 가장 단순한 방법으로 파일 이름을 바꾸어 저장하는 방식이 사용되었다. 예를 들어 원본 파일이 일기장.hwp라면, 수정본을 일기장1.hwp, 일기장2.hwp처럼 저장하는 식이다. 코드 파일도 마찬가지로 main.c, main_old.c, main_v2.c처럼 이름을 바꾸어 여러 개의 파일로 보관할 수 있다. 이렇게 하면 특정 기능이 이전 버전에서는 잘 작동했는데 현재 버전에서는 작동하지 않을 때, 예전 파일을 다시 열어보거나 복사해서 되돌릴 수 있다.

이 방식은 혼자 작업하거나 아주 작은 규모의 프로젝트에서는 어느 정도 사용할 수 있다. 파일 수가 적고 변경 내용이 단순하다면, 파일 이름만으로도 대략적인 버전 구분이 가능하기 때문이다. 하지만 이 방식은 곧 한계에 부딪힌다. 파일이 많아지고, 수정 횟수가 늘어나고, 여러 사람이 동시에 작업하면 어떤 파일이 최신인지, 어떤 파일이 안정적인 버전인지, 누가 무엇을 바꾸었는지 알기 어려워진다.

현업에서도 처음에는 사람 이름이나 아이디를 파일명에 붙이는 방식으로 구분할 수 있다고 생각할 수 있다. 예를 들어 main_heesu.c, main_john.c, report_final_v3.hwp처럼 저장하는 방식이다. 하지만 이런 방식은 체계적인 버전 관리라고 보기 어렵다. 파일 이름은 많아지지만, 변경 이유나 정확한 수정 내용은 알기 어렵고, 여러 사람이 수정한 내용을 하나로 합치는 것도 어렵다.

문서 프로그램의 경우에는 자체적으로 수정 이력을 저장하는 기능이 있기도 하다. 예를 들어 한글 문서나 워드 문서에서는 변경 내용 추적, 자동 저장, 이전 버전 복원 같은 기능을 제공할 수 있다. 하지만 이런 방식은 문서 내부에 수정 이력이 함께 저장되기 때문에 파일 크기가 커질 수 있다. 실제 문서 내용은 짧아도, 수정 이력과 부가 정보가 많이 쌓이면 파일 크기가 커지는 문제가 생길 수 있다. 따라서 소프트웨어 개발처럼 많은 파일과 긴 변경 이력을 다루는 환경에서는 단순 문서 이력 기능만으로는 충분하지 않다.

결국 파일 이름을 바꾸어 보관하는 방식은 기본적인 버전 구분에는 사용할 수 있지만, 실제 개발 환경에서는 한계가 크다. 혼자 작업하거나 몇 명이 간단히 작업할 때는 가능하지만, 인원이 늘어나고 코드의 양이 많아지면 관리가 어려워진다. 이때 필요한 것이 전문적인 버전 관리 시스템(Version Control System, VCS) 이다.

버전 관리 시스템이 제공하는 중요한 특징은 크게 되돌림(Rollback/Revert), 협업(Collaboration), 추적(Tracking), 파생(Branching) 으로 정리할 수 있다.

첫 번째 특징은 되돌림(Rollback/Revert) 이다. 버전 관리 시스템을 사용하면 언제든지 이전 버전의 상태로 돌아갈 수 있다. 새로운 기능을 추가하다가 문제가 생기거나, 수정한 코드가 예상과 다르게 동작할 경우 과거의 안정적인 상태를 확인하거나 복원할 수 있다. 이 기능은 실수를 줄이고, 개발자가 더 안전하게 코드를 수정할 수 있도록 도와준다.

두 번째 특징은 협업(Collaboration) 이다. 여러 개발자가 같은 프로젝트를 동시에 작업할 때, 단순히 같은 폴더를 공유하는 방식만으로는 충돌을 피하기 어렵다. 버전 관리 시스템은 각 개발자의 변경 내용을 기록하고, 서로 다른 작업 내용을 비교하고 병합할 수 있도록 도와준다. 따라서 다수의 개발자가 같은 프로젝트를 작업하더라도 변경 내용을 체계적으로 공유할 수 있다.

세 번째 특징은 추적(Tracking) 이다. 버전 관리 시스템은 언제, 누가, 무엇을, 왜 변경했는지 기록한다. 단순히 파일의 최신 상태만 저장하는 것이 아니라, 변경 이력 전체를 남긴다. 이를 통해 문제가 발생했을 때 어떤 변경이 원인이 되었는지 찾아볼 수 있고, 특정 기능이 언제 추가되었는지도 확인할 수 있다.

네 번째 특징은 파생(Branching) 이다. 버전 관리 시스템에서는 기존 코드에서 별도의 흐름을 만들어 새로운 버전을 개발할 수 있다. 이를 브랜치(Branch) 라고 한다. 예를 들어 안정적인 버전은 그대로 유지하면서, 새로운 기능을 실험하는 별도의 개발 흐름을 만들 수 있다. 이후 기능이 안정되면 다시 원래 흐름에 합칠 수 있는데, 이를 병합(Merge) 이라고 한다.

이러한 기능들은 단순히 특정 버전 관리 프로그램만의 기능이라기보다, 소프트웨어 개발에서 자연스럽게 필요해진 기능들이다. 파일 이름을 바꾸어 저장하는 방식도 작은 규모에서는 일종의 버전 관리처럼 사용할 수 있지만, 되돌림, 협업, 추적, 파생을 체계적으로 제공하지는 못한다. 그래서 현대 소프트웨어 개발에서는 Git, SVN(Subversion), Perforce 같은 버전 관리 도구를 사용하여 변경 이력을 관리한다.

결국 버전 관리의 핵심은 “파일을 여러 개 저장하는 것”이 아니라 “변경의 흐름을 관리하는 것”이다. 어떤 상태로 되돌아갈 수 있어야 하고, 누가 무엇을 바꾸었는지 알 수 있어야 하며, 여러 사람이 동시에 작업할 수 있어야 한다. 또한 필요할 때는 기존 버전에서 새로운 개발 흐름을 만들어갈 수 있어야 한다. 이러한 이유로 버전 관리는 소프트웨어 개발의 핵심 도구가 되었다.

버전 관리를 위한 처리 단계 (Version Control Workflow)

버전 관리(Version Control) 는 단순히 파일을 저장하는 것이 아니라, 원본을 보관하고, 복사본에서 작업하고, 수정 내용을 기록하며, 필요할 때 새로운 흐름으로 분기하고 다시 통합하는 과정을 포함한다. 이러한 과정을 이해하면 Git 같은 버전 관리 도구가 왜 필요한지 더 쉽게 이해할 수 있다.

가장 먼저 생각할 수 있는 것은 저장고(Repository) 이다. 저장고는 파일과 변경 이력이 보관되는 공간이다. 일반적으로 디스크(Disk)나 서버 저장소(Storage)에 위치하며, 프로젝트의 소스 코드, 문서, 설정 파일, 그리고 그동안의 변경 기록이 함께 저장된다. 단순히 현재 파일만 보관하는 것이 아니라, 누가 언제 어떤 내용을 변경했는지에 대한 이력도 함께 관리한다는 점이 중요하다. 그래서 저장고는 단순한 폴더라기보다, 프로젝트의 기록을 담고 있는 데이터베이스(Database)에 가깝다고 볼 수 있다.

다음은 복사본(Working Copy / Working Tree) 이다. 사용자는 보통 저장고의 원본 파일을 직접 수정하지 않고, 자신의 작업 공간에 복사본을 만들어 작업한다. 원본을 직접 수정하면 기존 상태가 훼손될 수 있고, 어떤 내용이 어떻게 바뀌었는지 관리하기 어렵다. 그래서 원본은 저장고에 보관해두고, 사용자는 복사본에서 파일을 수정한다. 이렇게 하면 원본과 현재 작업 중인 파일을 비교하여 어떤 차이가 생겼는지 확인할 수 있다.

예를 들어 저장고에 있는 파일을 기준으로 개발자가 자신의 컴퓨터에 복사본을 가져온 뒤 코드를 수정한다고 생각할 수 있다. 이때 수정한 내용은 아직 저장고에 반영된 것이 아니다. 단지 작업자의 복사본에서만 바뀐 상태이다. 이 단계에서는 변경 내용을 확인하고, 테스트하고, 필요한 경우 다시 수정할 수 있다.

그다음 단계는 수정본(Commit / Revision) 이다. 사용자가 작업을 완료하고 변경 내용을 저장고에 기록하면, 그 내용은 하나의 수정본이 된다. Git에서는 이 과정을 보통 커밋(Commit) 이라고 부른다. 커밋은 단순히 파일을 저장하는 것이 아니라, 특정 시점의 변경 내용을 하나의 기록으로 남기는 것이다. 이 기록에는 변경된 파일, 변경 내용, 작성자, 시간, 설명 메시지 등이 포함될 수 있다.

수정본이 저장고에 기록되면, 그 상태는 이후 작업의 새로운 기준이 될 수 있다. 즉, 이전 원본에서 출발해 새로운 변경 내용이 반영된 또 하나의 기준 상태가 만들어지는 것이다. 그래서 버전 관리는 단순히 “파일을 덮어쓰기” 하는 방식이 아니라, 변경된 상태들을 순서대로 기록하면서 프로젝트의 흐름을 만들어가는 방식이라고 할 수 있다.

이후에는 분기(Branch) 라는 개념이 등장한다. 분기는 기존의 코드 흐름에서 갈라져 나온 새로운 작업 흐름이다. 새로운 기능을 실험하거나, 기존 버전은 안정적으로 유지하면서 다른 방향의 개발을 진행하고 싶을 때 사용한다. 예를 들어 현재 안정 버전은 그대로 두고, 새로운 기능을 추가하는 별도의 브랜치를 만들 수 있다. 이 브랜치에서는 기존 원본을 기준으로 새로운 개발을 이어가지만, 원래 흐름에는 바로 영향을 주지 않는다.

분기는 “새로운 원본”처럼 생각할 수도 있다. 기존 저장고의 특정 시점을 기준으로 새로운 작업 흐름을 만들고, 그 안에서 독립적으로 수정과 테스트를 진행하기 때문이다. 만약 새로운 기능이 실패하면 해당 분기를 버릴 수도 있고, 성공하면 원래 흐름에 합칠 수도 있다. 이처럼 분기는 새로운 기능을 안전하게 점검하거나, 여러 버전을 동시에 관리하기 위한 중요한 기능이다.

마지막으로 통합(Merge / Integration) 이 있다. 통합은 수정본이나 분기된 작업 내용을 하나로 합치는 과정이다. 여러 사람이 각자 작업한 내용을 하나의 코드 흐름으로 합치거나, 새로운 기능 브랜치에서 작업한 내용을 안정 브랜치에 반영할 때 통합이 이루어진다.

예를 들어 새로운 기능을 개발하기 위해 별도의 브랜치를 만들었다고 하자. 그 기능이 충분히 테스트되고 안정적이라고 판단되면, 해당 브랜치의 변경 내용을 기존 메인 브랜치(Main Branch)에 합친다. 이 과정이 병합(Merge)이다. 통합을 통해 여러 갈래로 나뉘어 있던 변경 내용을 하나의 프로젝트 상태로 정리할 수 있다.

하지만 통합 과정이 항상 자동으로 깔끔하게 끝나는 것은 아니다. 서로 다른 작업자가 같은 파일의 같은 부분을 수정했다면 충돌(Conflict) 이 발생할 수 있다. 이 경우 버전 관리 도구는 충돌이 발생한 위치를 알려주고, 개발자가 어떤 내용을 남길지 직접 결정해야 한다. 따라서 통합은 단순히 “파일을 합치는 일”이 아니라, 여러 변경 흐름을 비교하고 조정하는 과정이라고 볼 수 있다.

정리하면, 버전 관리를 위한 기본 처리 단계는 저장고(Repository), 복사본(Working Copy), 수정본(Commit / Revision), 분기(Branch), 통합(Merge / Integration) 으로 이해할 수 있다. 저장고는 원본과 이력을 보관하는 곳이고, 복사본은 사용자가 실제로 작업하는 공간이다. 수정본은 변경 내용을 저장고에 기록한 결과이며, 분기는 새로운 작업 흐름을 만드는 과정이다. 통합은 나뉘어진 변경 내용을 다시 하나로 합치는 단계이다.

이러한 흐름 덕분에 버전 관리 시스템은 단순한 파일 저장소를 넘어서, 소프트웨어 개발의 변경 이력을 체계적으로 관리하고 협업을 가능하게 하는 핵심 도구가 된다.

📌

Repository → 프로젝트 이력 전체가 저장되는 공간
Working Tree → 사용자가 실제 파일을 수정하는 공간
Staging Area → 커밋하기 전에 변경 내용을 잠시 올려두는 공간
Commit → 변경 내용을 하나의 기록으로 저장하는 것
Branch → 독립적인 작업 흐름
Merge → 브랜치의 변경 내용을 합치는 것

버전 관리 프로그램의 종류: SCCS (Types of Version Control Systems: SCCS)

버전 관리 프로그램의 종류를 살펴볼 때 가장 초기 사례 중 하나로 SCCS(Source Code Control System) 를 들 수 있다. SCCS는 Bell Labs 에서 개발된 초기 버전 관리 시스템으로 알려져 있으며, 1970년대 초반에 등장했다. 당시 컴퓨터와 소프트웨어 개발 환경은 지금처럼 대중화되지 않았지만, 이미 소스 코드의 변경 이력을 관리해야 할 필요성은 존재했다.

SCCS는 1972년 무렵 Marc Rochkind 가 Bell Labs에서 개발을 시작한 것으로 알려져 있다. 초기에는 IBM System/370 환경에서 사용되었고, 이후 UNIX 환경에서도 사용되었다. 이는 버전 관리가 최근에 생긴 개념이 아니라, 컴퓨터와 소프트웨어 개발이 본격적으로 발전하던 시기부터 이미 중요한 문제였다는 것을 보여준다.

SCCS의 목적은 소스 코드와 같은 텍스트 파일의 변경 이력을 관리하는 것이었다. 여러 버전의 파일을 따로따로 계속 복사해두는 대신, 하나의 관리 체계 안에서 파일의 여러 버전을 보관하고, 필요할 때 과거 버전을 다시 꺼내 사용할 수 있게 해주었다. IBM 문서에서도 SCCS는 하나의 파일에 여러 버전이 동시에 존재할 수 있도록 하며, 변경 사항을 추적할 수 있게 해주는 시스템으로 설명된다.

SCCS의 특징 중 하나는 각 소스 파일 안에 SCCS ID 문자열(SCCS ID String) 을 넣는 관습이다. C 언어 코드에서는 보통 sccsid라는 문자열 변수를 만들어 그 안에 파일 이름, 버전, 날짜, 작성자 또는 설명 같은 정보를 넣었다. 예를 들면 다음과 같은 형태이다.

static char sccsid[] = "@(#)example.c 1.0 2026-05-24";

이 방식은 단순한 주석(Comment)과는 조금 다르다. 주석은 컴파일 과정에서 보통 제거되기 때문에 실행 파일이나 오브젝트 파일(Object File)에 남지 않는다. 반면 sccsid처럼 문자열 변수로 작성하면, 컴파일된 결과물 안에도 해당 문자열이 포함될 수 있다. 그래서 나중에 바이너리 파일(Binary File)이나 오브젝트 파일 안에서 특정 문자열을 검색하여, 어떤 소스 파일의 어떤 버전이 사용되었는지 확인할 수 있다.

정리하면, SCCS(Source Code Control System) 는 초기 버전 관리 시스템 중 하나로, 소스 코드의 변경 이력을 관리하고 과거 버전을 다시 꺼내 사용할 수 있도록 도와주었다. 또한 sccsid 문자열을 통해 컴파일된 프로그램 안에서도 소스 파일의 버전 정보를 확인할 수 있게 했다. 이 방식은 오늘날의 Git과는 다르지만, 소프트웨어 변경 이력을 체계적으로 관리하려는 초기 시도였다는 점에서 중요한 의미를 가진다.

추가적으로 SCCS는 현대적인 Git과 비교하면 오래된 방식이지만, 버전 관리의 기본 문제를 이미 다루고 있었다는 점에서 중요하다. 즉, “어떤 파일이 언제 어떻게 바뀌었는가”, “과거 버전을 다시 가져올 수 있는가”, “컴파일된 결과물이 어떤 소스에서 만들어졌는가”라는 문제는 1970년대에도 이미 중요했다.

또한 sccsid 방식은 오늘날에도 개념적으로는 이해할 가치가 있다. 현대 소프트웨어에서도 실행 파일 안에 빌드 번호(Build Number), 커밋 해시(Commit Hash), 빌드 날짜(Build Date)를 포함시키는 경우가 있기 때문이다. 이는 문제가 발생했을 때 해당 프로그램이 정확히 어떤 소스 코드에서 만들어졌는지 추적하기 위한 목적이다.

버전 관리 프로그램의 종류: RCS (Types of Version Control Systems: RCS)

RCS(Revision Control System) 는 SCCS 이후에 등장한 초기 버전 관리 시스템 중 하나이다. RCS는 주로 텍스트 형식의 파일, 특히 소스 코드(Source Code), 문서(Documentation), 테스트 데이터(Test Data)처럼 자주 수정되는 파일의 변경 이력을 추적하고 관리하기 위해 사용되었다. GNU RCS 문서에서도 RCS는 여러 개의 파일 리비전(Revision)을 저장, 검색, 기록, 식별, 병합할 수 있는 시스템으로 설명된다.

RCS의 중요한 특징은 수정된 전체 파일을 매번 모두 저장하는 것이 아니라, 변경된 부분만 저장하는 델타 저장 방식(Delta Storage) 을 사용한다는 점이다. 여기서 델타(Delta) 는 이전 버전과 비교했을 때 달라진 부분, 즉 차이점(Difference)을 의미한다. 예를 들어 A라는 파일이 있고, 그다음 버전에서 몇 줄만 수정되었다면 파일 전체를 다시 저장하는 대신 “어떤 줄이 바뀌었는가”만 기록하는 방식이다. RCS 논문에서도 저장 공간을 절약하기 위해 연속된 리비전 사이의 차이, 즉 델타를 저장한다고 설명한다.

RCS의 또 다른 특징은 기본적으로 한 파일에 대해 한 사용자만 수정하도록 하는 잠금 방식(Locking Mechanism) 이다. 여러 사용자가 같은 파일을 동시에 수정하면 서로의 변경 내용이 충돌할 수 있다. 그래서 RCS에서는 사용자가 파일을 수정하기 전에 해당 파일을 체크아웃(Check-out)하고 잠금(Lock)을 걸어, 다른 사용자가 동시에 같은 파일을 수정하지 못하도록 관리했다. 이는 “동시에 수정 불가”라는 방식으로 이해할 수 있다.

이 방식은 당시의 개발 환경에서는 매우 자연스러운 선택이었다. 여러 사람이 같은 파일을 동시에 고치면 어느 변경을 살릴 것인지, 어떤 내용이 최신인지, 서로의 작업이 어떻게 섞여야 하는지 판단하기 어렵다. 특히 현대의 Git처럼 강력한 병합(Merge) 기능이 일반화되기 전에는, 충돌을 나중에 해결하기보다는 처음부터 동시에 수정하지 못하도록 막는 방식이 더 안전하게 느껴질 수 있었다.

물론 파일을 동시에 수정하는 것이 기술적으로 완전히 불가능한 것은 아니다. 현대의 버전 관리 시스템에서는 여러 사람이 같은 파일을 각자 수정한 뒤, 나중에 변경 내용을 비교하고 병합할 수 있다. 하지만 같은 부분을 서로 다르게 수정하면 충돌(Conflict) 이 발생한다. RCS의 잠금 방식은 이런 충돌 상황을 미리 줄이기 위해 “한 번에 한 사람만 수정”하도록 제한한 구조라고 볼 수 있다.

운영체제 관점에서 보면, 이것은 공유 자원(Shared Resource)을 여러 사용자가 동시에 접근할 때 발생할 수 있는 문제와도 연결된다. 하나의 파일을 여러 사용자가 동시에 수정하면 데이터 일관성(Data Consistency)이 깨질 수 있고, 마지막에 저장한 사람이 이전 사람의 작업을 덮어쓰는 문제가 생길 수 있다. 따라서 RCS의 잠금 방식은 공유 파일을 안전하게 관리하기 위한 초기 버전 관리 시스템의 접근법이라고 할 수 있다.

정리하면, RCS(Revision Control System) 는 텍스트 파일의 변경 이력을 관리하기 위한 초기 버전 관리 시스템이다. RCS는 전체 파일을 매번 저장하기보다 변경된 부분만 저장하는 델타 저장 방식(Delta Storage) 을 사용하여 저장 공간을 절약했다. 또한 하나의 파일에 대해 한 사용자만 수정할 수 있도록 하는 잠금 방식(Locking) 을 통해 협업 중 발생할 수 있는 충돌을 줄이려 했다. 이러한 특징은 이후 버전 관리 시스템이 발전하는 데 중요한 기반이 되었다.

RCS의 방식은 오늘날 Git과 다르게 느껴질 수 있다. Git은 보통 여러 사람이 각자의 브랜치(Branch)에서 자유롭게 수정한 뒤, 나중에 병합(Merge)하면서 충돌을 해결하는 방식에 가깝다.

반면 RCS는 파일 단위 잠금(File Locking)을 통해 애초에 동시에 수정하는 상황을 줄이려는 방식이었다. 그래서 RCS는 “충돌이 생기면 나중에 해결하자”보다는 “충돌이 생기지 않도록 먼저 잠그자”에 가까운 사고방식을 가진 버전 관리 시스템이라고 볼 수 있다.

버전 관리 프로그램의 종류: CVS (Concurrent Versions System)

CVS(Concurrent Versions System) 는 RCS 이후에 널리 사용된 버전 관리 시스템 중 하나이다. 이름에 들어 있는 Concurrent 는 “동시에 진행되는”, “병행하는”이라는 의미를 가진다. 즉, CVS는 여러 사용자가 같은 프로젝트를 함께 작업할 수 있도록 만든 버전 관리 시스템이다.

CVS는 기본적으로 서버-클라이언트 방식(Server-Client Model) 으로 동작한다. 여기서 서버(Server) 는 프로젝트의 원본 저장소(Repository)를 보관하는 중앙 공간이고, 클라이언트(Client) 는 개발자가 실제로 작업하는 개인 컴퓨터나 작업 환경을 의미한다. 개발자는 서버에 있는 프로젝트를 자신의 컴퓨터로 가져와 수정하고, 수정이 끝나면 다시 서버에 반영한다.

이 점에서 CVS는 이전의 RCS와 차이가 있다. RCS는 기본적으로 개별 파일 단위의 버전 관리에 가깝고, 하나의 파일을 한 사용자가 잠그고 수정하는 방식이 중심이었다. 반면 CVS는 여러 파일로 이루어진 프로젝트 전체를 관리하고, 여러 사용자가 동시에 작업하는 환경을 더 적극적으로 지원했다. 그래서 CVS는 초기의 중앙 집중식 협업 버전 관리 도구로 이해할 수 있다.

CVS에서도 서버에 저장된 프로젝트를 클라이언트가 가져오는 과정을 체크아웃(Check-out) 이라고 한다. 말 그대로 서버에 있는 파일들을 사용자의 작업 공간으로 “가져오는” 과정이다. 사용자는 체크아웃한 복사본(Working Copy)을 자신의 컴퓨터에서 수정한다. 이때 서버의 원본 저장소가 바로 바뀌는 것은 아니고, 클라이언트의 작업 복사본만 수정된다.

수정이 끝난 뒤에는 변경 내용을 서버에 반영해야 한다. 이 과정을 체크인(Check-in) 또는 CVS에서는 보통 커밋(Commit) 이라고 부른다. 사용자가 커밋하면, 클라이언트에서 수정한 내용이 중앙 서버의 저장소에 기록된다. 이때 서버에는 새로운 리비전(Revision)이 만들어지고, 변경 이력도 함께 남는다.

CVS는 내부적으로 RCS와 관련이 깊다. 초기 CVS는 파일별 이력 관리를 위해 RCS 파일 형식을 활용했다. 그래서 CVS도 텍스트 파일의 변경 이력을 추적하고, 어느 부분이 수정되었는지 관리할 수 있었다. 다만 RCS가 파일 하나를 중심으로 관리했다면, CVS는 여러 파일과 디렉토리로 이루어진 프로젝트를 중앙 저장소에서 함께 관리할 수 있도록 확장한 방식이라고 볼 수 있다.

강의에서 언급된 심볼릭 링크(Symbolic Link) 부분은 조심해서 이해할 필요가 있다. CVS는 일반 파일과 달리 심볼릭 링크를 완전한 파일 시스템 객체로 깔끔하게 버전 관리하는 데 한계가 있었다. 그래서 심볼릭 링크가 프로젝트 안에 있을 때, 그것을 그대로 보존하거나 추적하는 방식이 현대적인 Git과는 다르게 제한적일 수 있다. 즉, CVS는 텍스트 기반 소스 코드 관리에는 적합했지만, 파일 시스템의 다양한 속성이나 특수 파일을 완벽하게 다루는 도구는 아니었다.

CVS에서 중요한 점은 여러 사용자가 동시에 작업할 수 있다는 것이다. 예를 들어 개발자 A, B, C가 같은 프로젝트를 체크아웃해서 각자 수정할 수 있다. RCS처럼 한 파일을 반드시 한 사람만 잠그고 수정해야 하는 구조와 비교하면, CVS는 더 유연한 협업을 가능하게 했다.

하지만 여러 사람이 동시에 작업할 수 있다는 것은 충돌 가능성도 생긴다는 뜻이다. 예를 들어 세 명의 개발자가 같은 파일을 가져가서 각자 수정했다고 하자. 개발자 A가 먼저 서버에 커밋하면, 서버의 최신 버전은 A의 수정 내용이 반영된 상태가 된다. 이후 개발자 B가 자신의 수정본을 그대로 커밋하려고 하면 문제가 생길 수 있다. 왜냐하면 B가 작업을 시작했을 때의 파일 버전과 서버의 현재 최신 버전이 달라졌기 때문이다.

이때 CVS는 단순히 B의 파일로 서버의 최신 파일을 덮어쓰는 방식으로 처리하지 않는다. 서버는 보통 사용자의 작업 복사본이 최신 버전을 기준으로 하고 있는지 확인한다. 만약 서버에 이미 다른 사용자의 변경 내용이 반영되어 있다면, B는 먼저 업데이트(Update) 를 통해 서버의 최신 변경 내용을 자신의 작업 복사본에 가져와야 한다. 그 후 자신의 수정 내용과 서버의 최신 수정 내용을 합친 뒤 다시 커밋해야 한다.

만약 A, B, C가 서로 다른 부분을 수정했다면 CVS가 자동으로 병합(Merge)할 수 있는 경우도 있다. 예를 들어 A는 함수 a를 수정하고, B는 함수 b를 수정하고, C는 함수 c를 수정했다면 서로 수정 위치가 다르기 때문에 비교적 쉽게 합쳐질 수 있다. 하지만 세 사람이 같은 함수의 같은 부분을 수정했다면 충돌(Conflict) 이 발생할 수 있다. 이 경우 CVS는 충돌이 발생한 부분을 표시하고, 개발자가 직접 어떤 내용을 남길지 결정해야 한다.

따라서 “서버는 최신 버전의 수정본만 인정한다”는 표현은 “가장 마지막에 커밋한 사람의 내용만 무조건 남는다”는 뜻으로 이해하면 안 된다. 더 정확하게는, CVS는 서버의 최신 리비전을 기준으로 변경 내용을 반영하려고 하며, 사용자의 작업 복사본이 오래된 상태라면 먼저 최신 변경 내용을 가져와 병합하도록 요구한다고 이해하는 것이 좋다.

정리하면, CVS(Concurrent Versions System) 는 중앙 서버에 저장소를 두고, 여러 클라이언트가 프로젝트를 체크아웃하여 수정한 뒤 다시 커밋하는 방식의 버전 관리 시스템이다. RCS의 파일 이력 관리 개념을 확장하여 여러 사람이 하나의 프로젝트를 함께 개발할 수 있도록 만든 도구이며, 충돌을 완전히 없애지는 못하지만 업데이트, 병합, 충돌 표시 기능을 통해 협업을 가능하게 했다.

CVS는 오늘날 Git만큼 많이 사용되지는 않지만, RCS에서 SVN, Git으로 이어지는 버전 관리 시스템 발전 과정에서 중요한 위치를 가진 도구이다.

버전 관리 프로그램의 종류: Apache Subversion (SVN)

Apache Subversion(SVN) 은 CVS 이후에 등장한 대표적인 중앙 집중식 버전 관리 시스템(Centralized Version Control System) 이다. Subversion은 보통 명령어 이름을 따서 SVN 이라고도 부른다. Apache Subversion 공식 사이트에서도 SVN을 오픈소스 버전 관리 시스템이며, 기업 환경에서도 사용할 수 있는 중앙 집중식 버전 관리 도구로 설명하고 있다.

SVN은 Apache License 에 따라 배포되는 오픈소스 소프트웨어이다. 여기서 중요한 점은 오픈소스(Open Source) 라는 말이 단순히 “코드를 볼 수 있다”는 뜻만은 아니라는 것이다. 오픈소스 소프트웨어는 라이선스 조건에 따라 사용, 수정, 배포가 허용된다. 다만 어떤 조건으로 사용할 수 있는지는 라이선스마다 다르기 때문에, 실제 프로젝트나 상업적 제품에 사용할 때는 반드시 라이선스 내용을 확인해야 한다.

특히 소프트웨어를 이용해 제품을 만들거나 수익을 얻고자 한다면 라이선스(License) 를 이해하는 것이 매우 중요하다. 오픈소스라고 해서 모든 조건이 같은 것은 아니다. 어떤 라이선스는 비교적 자유롭게 상업적 사용을 허용하고, 어떤 라이선스는 수정한 소스 코드 공개나 저작권 표시 유지 같은 조건을 요구한다. 따라서 “오픈소스니까 아무렇게나 사용해도 된다”라고 생각하면 위험하다.

다만 Apache License 2.0 은 비교적 허용적인 퍼미시브 라이선스(Permissive License) 에 속한다. Apache License 2.0은 사용, 복제, 수정, 배포, 2차 저작물 작성 등을 허용하며, 특허 라이선스 조항도 포함한다. Apache License의 원문에서도 저작권 라이선스가 무상, 전 세계적, 비독점적, 영구적으로 부여된다고 설명한다.

따라서 “오픈소스는 누구나 볼 수 있지만, 돈을 벌려면 반드시 원저작자에게 허가를 받거나 돈을 지불해야 한다”라고 일반화하는 것은 정확하지 않다. 라이선스에 따라 다르다. Apache License 2.0처럼 상업적 사용을 허용하는 라이선스도 있고, GPL처럼 배포 시 소스 코드 공개 의무가 강하게 붙는 라이선스도 있다. 핵심은 오픈소스마다 조건이 다르므로, 사용 전에 해당 라이선스를 확인해야 한다는 점이다.

SVN은 기능적으로 CVS(Concurrent Versions System) 의 한계를 개선하고 강화하기 위해 만들어졌다. CVS도 중앙 서버에 저장소를 두고 여러 사용자가 작업하는 방식이었지만, 파일 이름 변경, 디렉토리 이동, 원자적 커밋(Atomic Commit) 등에서 한계가 있었다. SVN은 이러한 문제를 개선하기 위해 설계되었다. Subversion은 2000년에 CollabNet에서 시작되었고, CVS와 비슷하게 동작하면서 CVS의 버그와 부족한 기능을 보완하는 것을 목표로 만들어졌다.

SVN의 중요한 특징 중 하나는 파일 이름 변경(Rename) 이나 파일 이동(Move), 그리고 디렉토리 구조의 변경을 버전 관리 이력 안에서 다룰 수 있다는 점이다. CVS는 주로 개별 파일 단위의 이력 관리에 초점이 있었기 때문에, 파일 이름을 바꾸거나 위치를 옮겼을 때 이력을 자연스럽게 보존하는 데 어려움이 있었다. 반면 SVN은 파일뿐만 아니라 디렉토리(Directory) 자체도 버전 관리 대상으로 다룬다. 그래서 파일이나 디렉토리를 옮기거나 복사할 때도 변경 이력을 추적하기가 더 쉬워졌다.

SVN은 오늘날 Git만큼 주류로 사용되지는 않지만, 여전히 일부 조직이나 오래된 프로젝트에서는 유지보수 목적으로 사용될 수 있다. 특히 오래전에 개발된 시스템은 전체 버전 관리 도구를 Git으로 옮기는 비용이 크거나, 기존 업무 흐름이 SVN에 맞춰져 있는 경우가 있다. 이런 경우에는 치명적인 문제가 없다면 기존 틀을 유지하면서 SVN을 계속 사용하는 경우도 있다.

따라서 SVN은 “지금 새 프로젝트에서 반드시 배워야 하는 최신 도구”라기보다는, 버전 관리 시스템의 발전 과정에서 CVS의 한계를 보완한 중요한 도구로 이해하면 좋다. RCS, CVS, SVN을 거쳐 Git 같은 분산 버전 관리 시스템이 널리 사용되기 시작했으며, 이 흐름을 이해하면 오늘날 Git이 왜 강력한 도구로 자리 잡았는지도 더 잘 이해할 수 있을 것이다.

📌SVN과 CVS의 차이를 간단히 정리하면 다음과 같다.

CVS 는 파일 단위 관리 성격이 강하고, 디렉토리 이동이나 파일 이름 변경 이력 관리가 불편했다.
SVN 은 디렉토리까지 버전 관리 대상으로 다루며, 여러 파일 변경을 하나의 리비전으로 묶어 관리할 수 있다.
SVN 은 원자적 커밋(Atomic Commit)을 지원하여 여러 파일 변경이 모두 반영되거나 모두 실패하도록 처리할 수 있다.
Git 은 SVN과 달리 분산 버전 관리 시스템(Distributed Version Control System)이므로, 각 개발자가 로컬에 전체 이력을 가진 저장소를 둘 수 있다.

버전 관리 프로그램의 종류: Git

Git 은 현재 가장 대표적인 분산 버전 관리 시스템(Distributed Version Control System, DVCS) 이다. Git은 리눅스 커널(Linux Kernel)을 만든 리누스 토르발스(Linus Torvalds) 가 2005년에 만들었다. Git이 만들어진 배경에는 리눅스 커널 개발 과정에서 사용하던 기존 버전 관리 도구인 BitKeeper 와 관련된 문제가 있었다.

리눅스 커널 개발자들은 한동안 BitKeeper 라는 버전 관리 시스템을 사용했다. BitKeeper는 분산 버전 관리 기능을 가진 도구였지만, 독점 소프트웨어(Proprietary Software)였다. 이후 라이선스 문제로 리눅스 커널 개발자들이 BitKeeper를 계속 사용하기 어려워지면서, 리누스 토르발스는 리눅스 커널 개발에 적합한 새로운 버전 관리 도구를 직접 만들게 되었다. 이 도구가 바로 Git이다. GitHub Blog에서도 Git은 2005년 4월 7일 첫 커밋이 만들어졌고, 리눅스 커널 개발자들이 BitKeeper 접근 권한을 잃은 뒤 만들어졌다고 설명한다.

Git의 가장 큰 특징은 완전한 분산 관리(Distributed Management) 가 가능하다는 점이다. 중앙 집중식 버전 관리 시스템에서는 중앙 서버가 원본 저장소 역할을 하고, 개발자들은 그 서버에서 파일을 받아 작업한 뒤 다시 서버에 반영한다. 반면 Git에서는 각 개발자가 자신의 컴퓨터에 프로젝트의 전체 변경 이력을 포함한 저장소를 가질 수 있다.

즉, Git에서는 단순히 파일의 현재 상태만 복사하는 것이 아니라, 과거 커밋 이력까지 포함한 저장소 전체를 로컬에 보관한다. 그래서 중앙 서버에 접속하지 않아도 커밋(Commit)을 만들고, 로그(Log)를 확인하고, 브랜치(Branch)를 만들고, 이전 상태로 되돌아가는 작업을 할 수 있다. 중앙 서버는 협업을 위해 자주 사용되지만, Git의 구조상 반드시 하나의 중앙 서버만 원본이어야 하는 것은 아니다.

이 점에서 Git은 기존 도구의 단순한 점진적 개선이라기보다, 버전 관리 방식을 크게 바꾼 도구로 볼 수 있다. CVS나 SVN 같은 중앙 집중식 버전 관리 시스템에서는 중앙 저장소가 기준이 되는 경우가 많았다. 하지만 Git에서는 각 개발자의 저장소가 독립적인 이력을 가질 수 있고, 필요에 따라 서로 변경 내용을 주고받을 수 있다. 그래서 오픈소스 프로젝트처럼 전 세계의 개발자가 참여하는 환경에 매우 잘 맞는다.

Git은 무료 오픈소스 소프트웨어(Free and Open Source Software) 이다. Git 공식 사이트에서도 Git을 무료 오픈소스 분산 버전 관리 시스템이라고 설명한다. Git은 빠르고 효율적으로 작은 프로젝트부터 매우 큰 프로젝트까지 처리할 수 있도록 설계되었다.

Git의 또 다른 장점은 브랜치와 병합이 강력하다는 점이다. Git에서는 새로운 기능을 실험하기 위해 브랜치를 만들고, 기능이 안정되면 다시 메인 브랜치(Main Branch)에 병합할 수 있다. 이 과정이 비교적 빠르고 가볍기 때문에, 현대 개발에서는 기능별 브랜치(Feature Branch), 버그 수정 브랜치(Bugfix Branch), 릴리스 브랜치(Release Branch) 같은 방식이 널리 사용된다.

Git은 현재 개인 프로젝트, 기업 개발, 오픈소스 프로젝트에서 매우 널리 사용된다. GitHub, GitLab, Bitbucket 같은 서비스도 Git을 기반으로 협업 기능을 제공한다. 다만 Git과 GitHub는 같은 것이 아니다. Git은 버전 관리 도구이고, GitHub는 Git 저장소를 온라인에서 호스팅하고 협업할 수 있도록 도와주는 플랫폼이다.

정리하면, Git 은 리눅스 커널 개발 과정에서 필요에 의해 만들어진 대표적인 분산 버전 관리 시스템이다. 기존에 사용하던 BitKeeper의 라이선스 문제가 계기가 되었고, 리누스 토르발스가 리눅스 커널 개발에 적합한 도구로 만들었다. Git은 각 개발자가 전체 저장소 이력을 로컬에 보관할 수 있기 때문에 중앙 서버에만 의존하지 않고, 완전한 분산 방식으로 프로젝트를 관리할 수 있다. 현재는 현대 소프트웨어 개발에서 가장 널리 사용되는 버전 관리 도구라고 할 수 있다.

📌Git을 이해할 때는 다음 구분이 중요하다.

Git 은 버전 관리 프로그램이다.
GitHub 는 Git 저장소를 온라인에서 관리하고 협업할 수 있게 해주는 서비스이다.
GitLab 과 Bitbucket 도 Git 저장소 호스팅과 협업 기능을 제공하는 플랫폼이다.

즉, Git을 배운다는 것은 GitHub 사용법만 배우는 것이 아니라, 커밋(Commit), 브랜치(Branch), 병합(Merge), 충돌 해결(Conflict Resolution), 원격 저장소(Remote Repository) 같은 버전 관리 개념을 배우는 것이다.

버전 관리에서 중요한 문제 중 하나는 여러 개발자가 같은 파일을 동시에 수정할 때 발생하는 충돌이다. 같은 파일이라도 서로 다른 함수를 수정하면 병합이 가능할 수 있지만, 같은 함수나 같은 코드 영역을 수정하면 충돌이 발생할 수 있다. 잠금 방식은 충돌을 줄일 수 있지만 작업 효율을 떨어뜨릴 수 있고, 병합 방식은 협업 효율은 높지만 충돌 해결이 필요하다. 따라서 버전 관리는 안전성과 효율성 사이에서 적절한 균형을 찾는 과정이다.

버전 관리의 고려사항: 파일 동시 변경 (Version Control Consideration: Concurrent File Changes)

버전 관리를 사용할 때 중요한 고려사항 중 하나는 여러 개발자가 같은 파일을 동시에 변경하는 상황이다. 소프트웨어 개발에서는 한 파일을 한 사람만 수정하는 경우도 있지만, 실제 협업 환경에서는 여러 개발자가 같은 파일을 동시에 수정하는 일이 자주 발생한다. 이때 변경 내용이 서로 어떻게 겹치는지에 따라 문제가 없을 수도 있고, 충돌이 발생할 수도 있다.

컴퓨터 시스템에서 여러 사용자가 같은 자원에 동시에 접근하는 것은 항상 조심해야 할 문제이다. 운영체제에서 여러 프로세스가 같은 데이터에 동시에 접근하면 동기화(Synchronization) 문제나 경쟁 상태(Race Condition) 가 발생할 수 있는 것처럼, 버전 관리에서도 여러 개발자가 같은 파일을 동시에 수정하면 변경 내용이 서로 충돌할 수 있다.

가장 단순한 해결 방법은 잠금(Lock) 을 사용하는 것이다. 한 개발자가 특정 파일을 수정하는 동안 다른 개발자가 그 파일을 수정하지 못하게 막는 방식이다. 이 방식은 충돌을 예방하는 데 효과적이다. 예를 들어 개발자 A가 main.c 파일을 잠그고 수정하고 있다면, 개발자 B는 A가 작업을 끝내기 전까지 같은 파일을 수정할 수 없다. 이렇게 하면 두 사람이 같은 파일을 동시에 수정해서 생기는 충돌을 줄일 수 있다.

하지만 잠금 방식에는 단점도 있다. 파일 전체를 잠그면 다른 개발자의 작업이 불필요하게 막힐 수 있다. 예를 들어 개발자 A는 같은 파일 안의 함수 login()을 수정하고 있고, 개발자 B는 전혀 다른 함수인 logout()을 수정하려고 할 수 있다. 두 작업은 서로 직접적인 충돌이 없을 수도 있지만, 파일 전체가 잠겨 있으면 B는 작업을 진행할 수 없다. 이 경우 협업 효율이 떨어진다.

그래서 현대 버전 관리 시스템에서는 단순히 파일 전체를 잠그는 방식만 사용하지 않고, 변경 내용을 비교하고 병합하는 방식을 많이 사용한다. 여러 개발자가 같은 파일을 수정하더라도 서로 다른 부분을 수정했다면 자동으로 합칠 수 있다. 예를 들어 개발자 A가 파일의 위쪽 함수를 수정하고, 개발자 B가 아래쪽 함수를 수정했다면 버전 관리 시스템은 두 변경 내용을 비교하여 하나의 파일로 병합할 수 있다.

반면 같은 파일 안에서도 같은 함수, 같은 줄, 같은 코드 블록을 서로 다르게 수정하면 충돌(Conflict) 이 발생할 가능성이 높다. 예를 들어 개발자 A와 B가 모두 calculateTotal() 함수의 같은 부분을 수정했다면, 버전 관리 시스템은 어떤 변경 내용을 최종적으로 남겨야 할지 자동으로 판단하기 어렵다. 이 경우 개발자가 직접 충돌 부분을 확인하고, 어떤 코드를 남길지 결정해야 한다.

따라서 버전 관리에서 중요한 것은 “같은 파일을 수정했는가”만이 아니라, “같은 파일의 어느 부분을 수정했는가”이다. 같은 파일이라도 서로 다른 함수나 서로 다른 위치를 수정했다면 병합이 가능할 수 있다. 하지만 같은 함수나 같은 코드 영역을 수정했다면 충돌이 발생할 수 있다.

이 문제는 협업 방식과도 연결된다. 파일을 어떻게 나누어 설계하느냐, 함수와 모듈을 얼마나 명확하게 분리하느냐, 누가 어떤 영역을 담당하느냐에 따라 충돌 가능성이 달라진다. 하나의 거대한 파일에 모든 기능이 들어 있다면 여러 개발자가 같은 파일을 자주 수정하게 되고, 충돌 가능성도 높아진다. 반대로 기능별로 파일과 모듈이 잘 나뉘어 있다면 각 개발자가 독립적으로 작업할 수 있어 충돌이 줄어든다.

결국 버전 관리에서 파일 동시 변경은 단순한 도구 문제가 아니라 개발 구조와 협업 방식의 문제이기도 하다. 잠금(Lock) 을 사용하면 안전성은 높아질 수 있지만 작업 효율은 떨어질 수 있고, 병합(Merge) 중심으로 관리하면 효율은 높아지지만 충돌을 해결해야 하는 부담이 생길 수 있다. 따라서 프로젝트의 성격, 파일의 종류, 팀의 작업 방식에 따라 적절한 관리 방법을 선택해야 한다.

특히 텍스트 기반 소스 코드에서는 병합 방식이 자주 사용되지만, 이미지, 영상, 실행 파일, 디자인 파일 같은 바이너리 파일(Binary File) 은 줄 단위 비교와 병합이 어렵기 때문에 잠금 방식이 더 적합할 수 있다. 예를 들어 게임 개발에서 3D 모델 파일이나 큰 이미지 파일을 여러 사람이 동시에 수정하면 자동 병합이 어렵기 때문에, 파일 잠금을 통해 한 번에 한 사람만 수정하도록 관리하는 경우가 있다.

정리하면, 버전 관리에서 파일 동시 변경을 고려할 때는 다음 두 가지 상황을 구분해야 한다. 여러 개발자가 같은 파일의 서로 다른 함수를 수정하는 경우에는 자동 병합이 가능할 수 있다. 하지만 여러 개발자가 같은 함수나 같은 코드 영역을 수정하는 경우에는 충돌이 발생할 가능성이 높다. 그래서 버전 관리는 단순히 파일을 저장하는 도구가 아니라, 협업 과정에서 변경 내용을 안전하고 효율적으로 관리하기 위한 체계라고 할 수 있다.

버전 관리에서 충돌은 같은 파일에서만 발생하는 것이 아니다. 서로 다른 파일을 수정했더라도 두 파일이 서로 의존하고 있다면 문제가 생길 수 있다. 예를 들어 한 파일에서 함수의 이름이나 매개변수를 바꾸면, 그 함수를 사용하는 다른 파일도 함께 수정되어야 한다. 따라서 버전 관리에서는 파일의 위치나 이름뿐만 아니라 파일 간 의존성도 함께 고려해야 한다.

버전 관리의 고려사항: 파일 간 의존성 (Version Control Consideration: File Dependency)

버전 관리에서 고려해야 할 또 다른 문제는 파일 간 의존성(File Dependency) 이다. 앞에서 살펴본 문제는 여러 개발자가 같은 파일(Same File) 을 수정할 때 발생하는 상황이었다. 이때 핵심은 같은 파일 안에서 같은 부분을 수정했는지, 아니면 서로 다른 부분을 수정했는지였다.

이번에 다루는 문제는 조금 다르다. 여기서는 개발자들이 서로 다른 파일(Different Files) 을 수정하고 있다. 겉으로 보면 같은 파일을 수정하는 것이 아니기 때문에 충돌이 없을 것처럼 보인다. 하지만 실제 소프트웨어 개발에서는 파일들이 서로 독립적으로 존재하지 않는 경우가 많다. 하나의 파일이 다른 파일을 참조하거나, 한 파일의 변경이 다른 파일의 동작에 영향을 줄 수 있다. 이것이 의존성(Dependency) 문제이다.

예를 들어 개발자 A가 user.c 파일을 수정하고, 개발자 B가 auth.c 파일을 수정한다고 하자. 두 사람은 서로 다른 파일을 수정하고 있으므로 버전 관리 시스템 입장에서는 직접적인 줄 단위 충돌은 없을 수 있다. 하지만 auth.c가 user.c의 함수나 구조체를 사용하고 있다면 문제가 생길 수 있다. A가 user.c 안의 함수 이름, 매개변수, 반환값을 바꾸면 B가 수정한 auth.c 코드가 더 이상 정상적으로 동작하지 않을 수 있다.

이처럼 서로 다른 파일을 수정했더라도 파일 사이에 의존 관계(Dependency Relationship) 가 있다면 충돌과 비슷한 문제가 발생할 수 있다. 버전 관리 시스템은 텍스트의 같은 줄이 동시에 수정되었는지는 비교할 수 있지만, 서로 다른 파일의 논리적 관계까지 항상 완벽하게 판단하지는 못한다. 따라서 Git 같은 도구에서 병합이 성공했다고 해서 프로그램이 반드시 정상적으로 동작한다는 뜻은 아니다.

반대로 파일 간 의존성이 거의 없다면, 서로 다른 파일을 수정하는 작업은 비교적 안전하게 병합될 수 있다. 예를 들어 개발자 A가 로그인 화면의 문구를 수정하고, 개발자 B가 전혀 다른 통계 출력 파일을 수정했다면 두 변경은 서로 영향을 주지 않을 가능성이 높다. 이런 경우에는 버전 관리 시스템이 자동으로 변경 내용을 합치기 쉽고, 실제 프로그램 실행에도 문제가 적을 수 있다.

따라서 버전 관리에서 중요한 점은 “같은 파일을 수정했는가”뿐만 아니라 “서로 다른 파일이지만 기능적으로 연결되어 있는가”이다. 같은 파일의 서로 다른 함수를 수정하는 문제는 텍스트 충돌에 가깝고, 서로 다른 파일의 의존성 문제는 구조적 충돌이나 의미적 충돌에 가깝다.

예를 들어 한 개발자가 payment.h 파일에서 함수 선언을 바꾸고, 다른 개발자가 payment.c 파일에서 기존 함수 정의를 기준으로 코드를 수정했다면 두 파일은 다르지만 서로 강하게 연결되어 있다. 병합 과정에서는 충돌이 나지 않을 수도 있지만, 컴파일 단계에서 오류가 발생할 수 있다. 또는 컴파일은 되더라도 실행 결과가 잘못될 수도 있다.

이런 문제를 줄이기 위해서는 파일 간 의존성을 잘 관리해야 한다. 기능별로 모듈(Module)을 분리하고, 인터페이스(Interface)를 명확히 정의하며, 한 파일의 변경이 다른 파일에 어떤 영향을 주는지 확인해야 한다. 또한 변경 내용을 병합한 뒤에는 반드시 빌드(Build)와 테스트(Test)를 수행해야 한다. 버전 관리 시스템이 변경 이력을 관리해주더라도, 프로그램의 동작까지 자동으로 보장해주는 것은 아니기 때문이다.

현대 개발 환경에서는 이런 문제를 줄이기 위해 CI(Continuous Integration) 를 사용하기도 한다. CI는 여러 개발자의 변경 내용을 자주 통합하고, 통합될 때마다 자동으로 빌드와 테스트를 실행하는 방식이다. 이를 통해 서로 다른 파일을 수정했지만 의존성 때문에 발생하는 문제를 빠르게 발견할 수 있다.

정리하면, 버전 관리의 파일 관련 고려사항은 두 단계로 나누어 볼 수 있다. 첫 번째는 같은 파일 안에서 같은 부분을 수정했는지, 다른 부분을 수정했는지의 문제이다. 두 번째는 서로 다른 파일을 수정했더라도 그 파일들이 서로 의존성을 가지고 있는지의 문제이다. 파일이 다르다고 해서 항상 안전한 것은 아니며, 의존성이 있는 파일이라면 한쪽의 변경이 다른 쪽의 오류로 이어질 수 있다.

Git 기본 설치 패키지 (Basic Git Installation Packages)

리눅스/유닉스 환경에서 Git 을 사용하려면 먼저 Git 패키지를 설치해야 한다. Ubuntu나 Debian 계열 리눅스에서는 보통 APT(Advanced Package Tool) 를 사용하여 패키지를 설치한다. 가장 기본적인 설치 명령어는 다음과 같다.

sudo apt install git

이 명령어는 Git을 사용하기 위한 기본 구성 요소를 설치한다. 일반적으로 Git 저장소를 만들고, 파일을 추가하고, 커밋하고, 브랜치를 만들고, 원격 저장소와 연결하는 기본적인 작업은 이 패키지만 설치해도 충분하다. 즉, Git을 처음 배우거나 일반적인 개발 작업을 하기 위해서는 git 패키지만 설치하면 된다.

Debian 패키지 설명에서도 git 패키지는 최소한의 의존성으로 Git의 주요 구성 요소를 제공한다고 설명한다. 그래픽 인터페이스, 다른 버전 관리 시스템과의 연동 도구, 웹 인터페이스 같은 추가 기능은 별도의 git* 패키지로 제공된다.

반면 다음과 같은 명령어도 있다.

sudo apt install git-all

git-all은 Git 하나만 설치하는 것이 아니라, Git과 관련된 다양한 부가 패키지들을 함께 설치하는 패키지이다. 예를 들어 Git GUI, Git Web Interface, Git SVN, Git CVS, Git Email 등 여러 보조 도구가 함께 설치될 수 있다. 그래서 git-all을 설치하면 설치되는 파일과 의존성 패키지의 양이 훨씬 많아질 수 있다.

쉽게 말해 sudo apt install git은 Git의 기본 기능을 설치하는 것이고, sudo apt install git-all은 Git과 관련된 거의 모든 부가 기능까지 함께 설치하는 방식이라고 볼 수 있다. 그래서 단순히 Git 명령어를 사용해 버전 관리를 배우고자 한다면 git만 설치해도 충분하다. 반대로 Git을 웹 인터페이스와 함께 사용하거나, SVN/CVS 같은 다른 버전 관리 시스템과 연동하거나, 이메일 기반 패치 작업처럼 특수한 기능까지 사용하려면 git-all을 고려할 수 있다.

그러나 초보자나 일반적인 개발자에게 git-all은 보통 필요하지 않다. 설치되는 패키지가 많고, 사용하지 않는 기능까지 함께 설치될 수 있기 때문이다. 특히 수업이나 개인 프로젝트에서 Git의 기본 명령어를 배우는 정도라면 git-all보다는 git 패키지를 설치하는 것이 더 간단하고 적절하다.

Git 설치 후에는 다음 명령어로 설치 여부와 버전을 확인할 수 있다.

git --version

이 명령어를 실행했을 때 git version 2.x.x와 같은 형태로 출력되면 Git이 정상적으로 설치된 것이다. 이후에는 사용자 이름과 이메일을 설정해야 한다. Git은 커밋을 만들 때 누가 변경했는지 기록하기 때문에, 처음 설치한 뒤에는 다음과 같이 기본 사용자 정보를 설정한다.

git config --global user.name "사용자이름"
git config --global user.email "이메일주소"

정리하면, Git을 가장 간단하게 사용하려면 sudo apt install git을 실행하면 된다. git-all은 Git 관련 부가 기능을 한꺼번에 설치하는 패키지이므로, 특별히 필요한 기능이 있을 때만 사용하는 것이 좋다. 일반적인 Git 학습과 개발 작업에서는 기본 git 패키지만으로도 충분하다.

📌초보자 기준으로는 다음 순서가 가장 적절하다.

sudo apt update
sudo apt install git
git --version

그다음 Git 사용자 정보를 설정한다.

git config --global user.name "사용자이름"
git config --global user.email "이메일주소"

git-all은 Git의 모든 관련 기능을 실험해보고 싶은 경우에는 사용할 수 있지만, 처음 배우는 단계에서는 보통 필요하지 않다.

Git에서 커밋은 특정 순간의 프로젝트 전체 모습을 찍은 사진과 같다. 하지만 매번 모든 파일을 새로 복사해서 저장하는 것은 아니다. 바뀐 파일은 새로 저장하고, 바뀌지 않은 파일은 이전에 저장된 객체를 다시 가리킨다. 그래서 Git은 전체 프로젝트의 스냅샷을 관리하면서도 저장 공간을 효율적으로 사용할 수 있다.

Git 버전의 개념: 스냅샷 방식 (Git Version Concept: Snapshot Model)

Git에서 하나의 버전(Version) 이 결정된다는 것은 단순히 변경된 파일 몇 개만 따로 저장한다는 뜻이 아니다. Git은 특정 시점의 프로젝트 전체 모습을 하나의 스냅샷(Snapshot) 처럼 기록한다. 여기서 스냅샷은 사진을 찍는 것과 비슷한 개념이다. 어느 순간의 프로젝트 상태를 하나의 장면처럼 남겨두는 것이다.

그림을 보면 시간이 오른쪽으로 흐르고, Version 1부터 Version 5까지의 버전이 차례로 나타난다. 각 버전 아래에는 File A, File B, File C 또는 A1, B1, C2처럼 파일의 상태가 표시되어 있다. 이 그림은 Git이 각 버전에서 프로젝트 전체 상태를 어떻게 바라보는지 설명하기 위한 예시이다.

Version 1에서는 File A, File B, File C가 존재한다. 이후 Version 2에서는 File A가 A1로 바뀌고, File C가 C1로 바뀐다. 반면 File B는 이전과 동일하다. 그림에서 실선으로 표시된 것은 이전 버전과 비교했을 때 변경된 파일을 의미하고, 점선으로 표시된 것은 이전 버전과 내용이 동일한 파일을 의미한다.

Version 3을 보면 A1과 B는 점선으로 표시되어 있다. 이는 Version 2와 비교했을 때 A1과 B는 바뀌지 않았다는 뜻이다. 반면 C1은 C2로 바뀌었기 때문에 새로운 파일 상태로 표시된다. 즉, Version 3이라는 버전은 전체 프로젝트의 상태를 나타내지만, 실제로 새롭게 저장해야 하는 내용은 변경된 C2뿐이라고 볼 수 있다.

이때 중요한 점은 Git이 “버전마다 프로젝트 전체를 사진처럼 기억한다”는 관점과 “변경되지 않은 파일을 매번 새로 복사하지 않는다”는 관점을 함께 가진다는 것이다. 사용자가 보는 관점에서는 Version 3도 A1, B, C2를 모두 포함한 완전한 프로젝트 상태이다. 그러나 내부 저장 방식에서는 이미 이전 버전에 존재하던 A1과 B를 굳이 다시 저장하지 않고, 기존 객체를 참조할 수 있다.

예를 들어 Version 2의 B와 Version 3의 B가 완전히 같은 내용이라면, Git은 같은 내용을 가진 파일을 또 하나 복사해서 저장할 필요가 없다. 이미 저장된 파일 내용을 다시 가리키면 된다. 그래서 Git은 변경된 파일은 새롭게 저장하고, 변경되지 않은 파일은 기존에 저장된 객체를 재사용한다. Git 공식 문서에서도 커밋 객체는 특정 시점의 프로젝트 스냅샷을 나타내는 트리 객체를 가리키며, 변경된 파일에 대해서는 새로운 blob 객체를 저장하고 트리와 커밋 객체를 만든다고 설명한다.

이 구조를 조금 더 기술적으로 보면 Git은 주로 블롭(Blob), 트리(Tree), 커밋(Commit) 객체를 사용한다. 블롭 객체(Blob Object) 는 파일의 실제 내용을 저장한다. 트리 객체(Tree Object) 는 디렉토리 구조와 파일 이름, 그리고 각 파일 내용이 어떤 블롭 객체를 가리키는지를 저장한다. 커밋 객체(Commit Object) 는 특정 시점의 최상위 트리와 부모 커밋, 작성자 정보, 커밋 메시지 등을 저장한다. Git 문서에서도 커밋 객체는 특정 시점의 디렉토리 트리 스냅샷을 나타내는 트리 객체를 참조한다고 설명한다.

따라서 Git의 버전은 단순히 “이전 버전에서 무엇이 바뀌었는가”만 저장하는 방식과는 다르다. Git은 각 커밋을 프로젝트 전체 상태의 스냅샷처럼 다룬다. 하지만 저장 공간을 낭비하지 않기 위해, 내용이 같은 파일은 같은 객체를 재사용한다. 즉, Version 5에서 A2가 이전 버전과 같다면 다시 저장하지 않고 기존 A2를 참조할 수 있고, B2나 C3처럼 변경된 파일만 새로운 내용으로 저장하면 된다.

이 방식은 Git을 이해할 때 매우 중요하다. 사용자는 각 커밋을 “그 시점의 전체 프로젝트 상태”로 생각하면 된다. 하지만 Git 내부에서는 변경되지 않은 파일을 매번 통째로 복사하지 않고, 이미 존재하는 파일 내용 객체를 재사용한다. 그래서 Git은 전체 스냅샷을 관리하면서도 저장 공간을 효율적으로 사용할 수 있다.

정리하면, Git에서 하나의 버전은 특정 순간의 프로젝트 전체 모습을 담은 스냅샷(Snapshot) 이다. 변경된 파일은 새 객체로 저장되고, 변경되지 않은 파일은 기존 객체를 다시 참조한다. 따라서 그림의 점선은 “이전 버전과 동일하므로 새로 저장하지 않고 기존 것을 참조할 수 있다”는 의미로 이해할 수 있다. Git은 이런 방식으로 버전마다 전체 프로젝트 상태를 관리하면서도, 불필요한 중복 저장을 줄인다.

Git은 파일의 상태를 Modified, Staged, Committed 로 구분한다. 파일을 수정하면 Modified 상태가 되고, git add를 실행하면 Staged 상태가 되며, git commit을 실행하면 Committed 상태가 된다. 이 구조를 통해 Git은 어떤 변경을 다음 커밋에 포함할지 선택할 수 있게 해준다.

Git의 기본: 파일의 세 가지 상태 (Git Basics: Three File States)

Git은 파일이 변경되었는지, 변경된 파일이 다음 커밋에 포함될 준비가 되었는지, 그리고 변경 내용이 실제로 저장소에 기록되었는지를 구분해서 관리한다. 이때 Git에서 파일은 기본적으로 수정됨(Modified), 스테이지됨(Staged), 커밋됨(Committed) 이라는 세 가지 상태를 가진다.

먼저 수정됨(Modified) 은 파일의 내용이 이전에 저장된 상태와 달라졌다는 뜻이다. 예를 들어 a.c라는 파일이 있고, 이전에는 a라는 내용만 있었는데 이후에 b라는 내용이 추가되었다면 Git은 이 파일을 수정된 파일로 인식한다. 파일 이름은 여전히 a.c로 같지만, 이전 버전과 비교했을 때 내용이 달라졌기 때문에 Modified 상태가 된다.

이때 Git은 아주 작은 변경도 파일의 변경으로 인식할 수 있다. 코드 한 줄을 추가하거나 삭제하는 것뿐만 아니라, 공백, 줄바꿈, 주석문 변경도 파일 내용이 달라진 것으로 볼 수 있다. 물론 실제로 이 변경이 프로그램의 실행 결과에 영향을 주는지는 별개의 문제이다. Git 입장에서는 파일의 내용이 이전과 달라졌는지가 중요하다.

다음은 스테이지됨(Staged) 상태이다. Staged는 수정된 파일을 다음 커밋에 포함하기 위해 준비해 둔 상태를 말한다. 쉽게 말하면, 변경된 파일을 바로 저장소에 확정하는 것이 아니라, 먼저 스테이징 영역(Staging Area) 에 올려두는 것이다. Git에서는 보통 git add 명령어를 사용해 수정된 파일을 스테이징 영역에 올린다.

예를 들어 a.c 파일을 수정한 뒤 다음 명령어를 실행하면, 해당 파일은 Staged 상태가 된다.

git add a.c

이 상태는 “이 파일의 변경 내용을 다음 커밋에 포함하겠다”라고 표시해 둔 것과 같다. 즉, Staged 상태는 커밋 직전의 대기 상태라고 볼 수 있다.

마지막은 커밋됨(Committed) 상태이다. Committed는 스테이징 영역에 올라간 변경 내용이 Git의 로컬 저장소(Local Repository)에 실제로 기록된 상태를 말한다. Git에서는 보통 git commit 명령어를 사용해 변경 내용을 커밋한다.

git commit -m "Update a.c"

커밋이 완료되면 해당 변경 내용은 Git의 로컬 데이터베이스에 저장된다. 이때 Git은 단순히 파일을 복사해서 저장하는 것이 아니라, 변경된 상태를 하나의 기록으로 남긴다. 이 기록에는 어떤 파일이 변경되었는지, 누가 변경했는지, 언제 변경했는지, 어떤 메시지를 남겼는지 등의 정보가 포함된다.

따라서 Git에서 커밋(Commit) 은 단순히 “명령어를 실행한다”는 의미가 아니라, 프로젝트의 특정 시점 상태를 로컬 저장소에 저장하는 작업이다. Git은 이러한 커밋들을 통해 프로젝트의 변경 이력을 관리한다. 그래서 Git을 데이터베이스 관점에서 보면, 각 커밋은 프로젝트의 한 시점에 대한 기록이고, Git 저장소는 이러한 기록들이 쌓여 있는 데이터베이스라고 볼 수 있다.

정리하면 Git에서 파일의 세 가지 상태는 다음과 같다. Modified 는 파일이 수정되었지만 아직 다음 커밋에 포함되도록 준비되지 않은 상태이다. Staged 는 수정된 파일이 다음 커밋에 포함되도록 스테이징 영역에 올라간 상태이다. Committed 는 변경 내용이 로컬 저장소에 저장 완료된 상태이다.

이 세 가지 상태를 이해하면 Git의 기본 흐름도 자연스럽게 이해할 수 있다. 먼저 파일을 수정하면 Modified 상태가 되고, git add로 스테이징 영역에 올리면 Staged 상태가 되며, git commit으로 저장소에 기록하면 Committed 상태가 된다. Git의 기본 작업 흐름은 이 세 단계를 중심으로 움직인다.

파일 수정 → git add → git commit
Modified → Staged → Committed

결국 Git은 파일이 단순히 “있다” 또는 “없다”로만 관리되는 것이 아니라, 변경되었는지, 커밋 준비가 되었는지, 저장소에 기록되었는지를 구분해서 관리한다. 이 구조 덕분에 개발자는 어떤 변경을 커밋에 포함할지 선택할 수 있고, 프로젝트의 변경 이력을 더 세밀하게 관리할 수 있게되었다.

Git 설정은 시스템(System), 글로벌(Global), 로컬(Local) 범위로 나뉜다. 시스템 설정은 모든 사용자에게 적용되고, 글로벌 설정은 특정 사용자에게 적용되며, 로컬 설정은 특정 저장소에만 적용된다. 같은 설정이 여러 범위에 존재하면 더 구체적인 설정이 우선 적용되므로, 최종적으로는 로컬 설정이 가장 우선적으로 적용된다.

Git 사용 설정 종류 (Git Configuration Levels)

Git을 사용하기 위해서는 기본적인 설정(Configuration) 이 필요하다. Git 설정은 사용자 이름, 이메일, 편집기, 줄바꿈 처리 방식, 별칭(alias) 등 Git이 동작할 때 참고하는 여러 정보를 저장한다. 이 설정은 적용 범위에 따라 크게 시스템(System), 글로벌(Global), 로컬(Local) 세 가지로 나눌 수 있다.

Git 설정에서 중요한 특징은 오버라이드(Override) 구조이다. 오버라이드는 기존 설정을 더 구체적인 설정이 덮어쓴다는 뜻이다. 즉, 넓은 범위의 설정이 먼저 적용되더라도, 더 좁은 범위에서 같은 항목을 다시 설정하면 좁은 범위의 설정이 우선 적용된다.

가장 넓은 범위는 시스템 설정(System Configuration) 이다. 시스템 설정은 해당 컴퓨터를 사용하는 모든 사용자에게 적용되는 설정이다. 리눅스 환경에서는 보통 다음 경로에 저장된다.

/etc/gitconfig

이 설정은 컴퓨터 전체에 적용되기 때문에, 같은 시스템을 사용하는 모든 사용자가 영향을 받는다. 예를 들어 학교 실습실이나 서버처럼 여러 사용자가 같은 컴퓨터를 사용하는 환경에서는 시스템 설정이 공통 기본값처럼 작동할 수 있다.

두 번째는 글로벌 설정(Global Configuration) 이다. 글로벌 설정은 특정 사용자에게 적용되는 설정이다. 즉, 같은 컴퓨터 안에서도 사용자 계정마다 다른 Git 설정을 가질 수 있다. 리눅스에서는 보통 다음 위치에 저장된다.

~/.gitconfig

또는 다음 위치가 사용될 수 있다.

~/.config/git/config

여기서 ~는 현재 사용자의 홈 디렉토리(Home Directory)를 의미한다. 예를 들어 사용자 이름이 student라면 ~/.gitconfig는 /home/student/.gitconfig와 같은 의미가 될 수 있다. 일반적으로 Git을 처음 설치한 뒤 사용자 이름과 이메일을 설정할 때 이 글로벌 설정을 많이 사용한다.

예를 들어 다음 명령어는 현재 사용자에게 적용되는 이름과 이메일을 설정한다.

git config --global user.name "사용자이름"
git config --global user.email "이메일주소"

세 번째는 로컬 설정(Local Configuration) 이다. 로컬 설정은 특정 Git 저장소, 즉 특정 프로젝트에만 적용되는 설정이다. 로컬 설정은 해당 프로젝트 폴더 안의 다음 파일에 저장된다.

.git/config

로컬 설정은 프로젝트 단위로 적용되기 때문에 가장 구체적인 설정이다. 예를 들어 개인 프로젝트에서는 개인 이메일을 사용하고, 회사 프로젝트에서는 회사 이메일을 사용해야 한다면 로컬 설정을 통해 프로젝트마다 다른 이메일을 지정할 수 있다.

Git 설정의 우선순위는 일반적으로 다음과 같다.

System → Global → Local

즉, 시스템 설정이 가장 넓은 기본값이고, 글로벌 설정이 그 위에 적용되며, 로컬 설정이 최종적으로 가장 우선 적용된다. 같은 설정 항목이 여러 위치에 존재한다면, 더 구체적인 로컬 설정이 글로벌 설정을 덮어쓰고, 글로벌 설정은 시스템 설정을 덮어쓴다.

예를 들어 시스템 설정에는 사용자 이름이 Linux User로 되어 있고, 글로벌 설정에는 Student로 되어 있으며, 특정 프로젝트의 로컬 설정에는 Project Developer로 되어 있다면, 해당 프로젝트 안에서는 최종적으로 Project Developer가 적용된다. 이것이 Git 설정에서 말하는 오버라이드(Override) 의 의미이다.

이 구조는 Git을 여러 환경에서 유연하게 사용할 수 있게 해준다. 모든 사용자에게 공통으로 적용할 설정은 시스템 범위에 두고, 개인 사용자가 자주 쓰는 기본 설정은 글로벌 범위에 둔다. 그리고 특정 프로젝트에서만 달라져야 하는 설정은 로컬 범위에 둔다.

정리하면, Git 설정은 시스템(System), 글로벌(Global), 로컬(Local) 세 단계로 나뉜다. 시스템 설정은 컴퓨터 전체와 모든 사용자에게 적용되고, 글로벌 설정은 특정 사용자에게 적용되며, 로컬 설정은 특정 저장소나 프로젝트에 적용된다. 같은 설정이 여러 단계에 존재할 경우, 더 구체적인 설정이 더 넓은 설정을 덮어쓰며, 최종적으로는 로컬 설정이 가장 우선적으로 적용된다.

Git 사용 설정 확인과 변경 (Git Configuration Check & Set)

Git을 사용하려면 먼저 기본 설정을 확인하고 필요한 값을 지정해야 한다. Git 설정은 앞에서 본 것처럼 시스템(System), 글로벌(Global), 로컬(Local) 범위로 나뉘며, 같은 설정이 여러 곳에 존재할 경우 더 좁은 범위의 설정이 우선 적용된다. 즉, System → Global → Local 순서로 갈수록 우선순위가 높아지고, 최종적으로는 특정 저장소의 로컬 설정(Local Configuration) 이 가장 우선적으로 적용된다.

현재 Git에 어떤 설정들이 적용되어 있는지 확인하려면 터미널에서 다음 명령어를 사용할 수 있다.

git config --list --show-origin

여기서 --list는 현재 적용 가능한 Git 설정 목록을 보여주는 옵션이고, --show-origin은 각 설정이 어느 파일에서 온 것인지 함께 보여주는 옵션이다. 이 명령어를 사용하면 설정값뿐만 아니라 해당 설정이 시스템 설정(System Configuration) 에서 온 것인지, 글로벌 설정(Global Configuration) 에서 온 것인지, 아니면 로컬 설정(Local Configuration) 에서 온 것인지 확인할 수 있다.

Git 설정을 변경할 때는 적용 범위에 따라 옵션을 다르게 사용한다. 특정 프로젝트, 즉 현재 Git 저장소에만 설정을 적용하려면 --local 옵션을 사용한다.

git config --local user.name "korea cyber university"
git config --local user.email "noreply@koreacu.ac.kr"

이 명령어는 현재 저장소의 .git/config 파일에 사용자 이름과 이메일을 저장한다. 따라서 이 설정은 현재 프로젝트에서만 적용된다. 예를 들어 개인 프로젝트에서는 개인 이메일을 사용하고, 학교 과제 저장소에서는 학교 이메일을 사용하고 싶을 때 로컬 설정을 사용할 수 있다.

특정 사용자 계정 전체에 적용하려면 --global 옵션을 사용한다.

git config --global user.name "사용자이름"
git config --global user.email "이메일주소"

글로벌 설정은 보통 현재 사용자의 홈 디렉토리에 있는 다음 파일에 저장된다.

~/.gitconfig

또는 환경에 따라 다음 경로가 사용될 수도 있다.

~/.config/git/config

여기서 ~는 현재 사용자의 홈 디렉토리(Home Directory)를 의미한다. 따라서 --global은 컴퓨터 전체가 아니라, 현재 로그인한 특정 사용자에게 적용되는 설정이라고 이해하면 된다.

컴퓨터의 모든 사용자에게 공통으로 적용되는 설정은 --system 옵션을 사용한다.

git config --system user.name "공통사용자이름"

시스템 설정은 리눅스 환경에서 보통 다음 파일에 저장된다.

/etc/gitconfig

이 파일은 시스템 전체 설정이므로 일반 사용자 권한으로는 수정이 제한될 수 있다. 따라서 실제로 --system 설정을 변경하려면 관리자 권한이 필요할 수 있다.

sudo git config --system user.name "공통사용자이름"

정리하면, --system은 모든 사용자에게 적용되는 설정이고, --global은 현재 사용자에게 적용되는 설정이며, --local은 현재 Git 저장소에만 적용되는 설정이다. 같은 항목이 여러 위치에 설정되어 있으면 더 구체적인 설정이 기존 설정을 오버라이드(Override) 한다. 즉, 로컬 설정이 글로벌 설정을 덮어쓰고, 글로벌 설정이 시스템 설정을 덮어쓴다.

명령어를 입력할 때는 따옴표의 종류도 주의해야 한다. 일반적으로 값에 공백이 들어갈 때는 작은따옴표(')나 큰따옴표(")를 사용할 수 있다.

git config --local user.name "korea cyber university"
git config --local user.name 'korea cyber university'

두 명령어는 일반적인 문자열 설정에서는 비슷하게 동작한다. 하지만 백틱(`)은 작은따옴표가 아니다. 리눅스 셸에서 백틱은 명령어 실행 결과를 치환하는 용도로 사용될 수 있으므로, 단순 문자열을 감쌀 때 작은따옴표와 혼동하면 안 된다.

예를 들어 아래처럼 백틱을 사용하면 단순 문자열이 아니라 셸이 그 안의 내용을 명령어처럼 해석하려고 할 수 있다.

git config --local user.name `korea cyber university`

따라서 Git 설정 값을 입력할 때는 보통 큰따옴표(" ") 또는 작은따옴표(' ')를 사용하는 것이 안전하다. 특히 사용자 이름처럼 공백이 포함될 수 있는 값은 따옴표로 감싸는 것이 좋다.

결국 Git 설정은 “어디에 적용할 것인가”가 핵심이다. 모든 사용자에게 적용할 설정은 System, 현재 사용자에게 적용할 설정은 Global, 특정 프로젝트에만 적용할 설정은 Local 범위에 저장한다. 그리고 실제 적용 결과를 확인할 때는 git config --list --show-origin을 사용하면 어떤 설정이 어느 파일에서 왔는지 확인할 수 있다.

Git 사용 설정: 편집기와 기본 브랜치 설정 (Git Configuration: Editor & Default Branch)

Git을 사용할 때는 사용자 이름과 이메일뿐만 아니라, 기본 편집기와 기본 브랜치 이름도 설정할 수 있다. 이러한 설정은 Git을 사용할 때 반복적으로 적용되는 기본 동작을 정하는 역할을 한다.

먼저 기본 편집기(Default Editor) 설정이 있다. Git에서는 커밋 메시지(Commit Message)를 입력해야 하는 경우가 많다. 보통 간단한 커밋 메시지는 다음처럼 명령어에서 바로 작성할 수 있다.

git commit -m "커밋 메시지"

하지만 -m 옵션을 사용하지 않고 git commit만 실행하면, Git은 커밋 메시지를 입력하라고 편집기 창을 연다. 이때 어떤 편집기를 열 것인지 정하는 설정이 core.editor 이다.

예제에서는 다음과 같이 Vim을 기본 편집기로 설정하고 있다.

git config --global core.editor vim

이 명령어는 현재 사용자(Global) 범위에서 Git의 기본 편집기를 Vim 으로 설정한다. 이후 커밋 메시지를 직접 입력해야 할 때 Git은 Vim을 실행한다.

다만 모든 사용자가 Vim을 편하게 사용하는 것은 아니다. Vim은 리눅스/유닉스 환경에서 오래전부터 많이 사용된 강력한 텍스트 편집기지만, 처음 사용하는 사람에게는 조작 방식이 어렵게 느껴질 수 있다. Vim을 사용하지 않는다면 다른 편집기를 설정해도 된다. 예를 들어 Nano 를 사용하고 싶다면 다음처럼 설정할 수 있다.

git config --global core.editor nano

또는 Emacs 를 사용한다면 다음과 같이 설정할 수 있다.

git config --global core.editor emacs

즉, Git에서 편집기 설정이 필요한 이유는 Git 자체가 문서를 작성하기 위해서라기보다, 커밋 메시지처럼 사용자가 직접 텍스트를 입력해야 하는 상황에서 어떤 편집기를 사용할지 정하기 위해서이다.

다음으로 기본 브랜치(Default Branch) 이름 설정이 있다. Git에서 새 저장소를 만들면 기본 브랜치가 생성된다. 과거에는 기본 브랜치 이름으로 master가 많이 사용되었지만, 최근에는 main을 사용하는 경우가 많다. 그래서 새 Git 저장소를 만들 때 기본 브랜치 이름을 main으로 지정하려면 다음 명령어를 사용할 수 있다.

git config --global init.defaultBranch main

이 설정은 이후 git init으로 새 저장소를 만들 때 기본 브랜치 이름을 main으로 지정하게 한다. 이미 만들어진 저장소의 브랜치 이름을 바꾸는 명령어가 아니라, 앞으로 새로 생성할 저장소의 기본 브랜치 이름을 정하는 설정이라는 점이 중요하다.

정리하면, Git 설정에서는 사용자의 작업 환경에 맞게 기본 편집기와 기본 브랜치 이름을 지정할 수 있다. core.editor는 Git이 커밋 메시지 등을 입력받을 때 사용할 편집기를 정하는 설정이고, init.defaultBranch는 새 저장소를 만들 때 기본으로 생성될 브랜치 이름을 정하는 설정이다.

Git 사용: 저장소 초기화와 .git 디렉토리 (Git Usage: Repository Initialization & .git Directory)

Git을 사용하려면 먼저 버전 관리를 적용할 디렉토리에서 저장소 초기화(Repository Initialization) 를 해야 한다. Git을 설치했다고 해서 모든 디렉토리가 자동으로 Git 저장소가 되는 것은 아니다. 사용자가 원하는 프로젝트 디렉토리로 이동한 뒤, 그 위치에서 Git 저장소를 만들겠다고 지정해야 한다.

이를 위해 사용하는 명령어가 다음과 같다.

git init

git init 명령어를 실행하면 현재 디렉토리 안에 숨김 디렉토리인 .git 디렉토리가 생성된다. 리눅스/유닉스 환경에서는 이름이 점(.)으로 시작하는 파일이나 디렉토리는 기본적으로 숨김 파일(Hidden File)로 취급된다. 그래서 일반적인 ls 명령어만으로는 보이지 않을 수 있고, 다음처럼 -a 옵션을 사용해야 확인할 수 있다.

ls -a

.git 디렉토리는 Git 저장소의 핵심이다. 이 안에는 버전 관리에 필요한 여러 정보가 저장된다. 예를 들어 커밋 이력(Commit History), 브랜치 정보(Branch Information), 설정 파일(Configuration File), 객체 데이터(Object Data), 인덱스(Index) 등이 .git 디렉토리 안에 보관된다.

즉, 우리가 프로젝트 폴더에서 보는 일반 파일들은 실제 작업 파일이고, .git 디렉토리는 그 파일들의 변경 이력을 관리하는 내부 저장소라고 볼 수 있다. 사용자는 보통 소스 코드 파일을 수정하고 git add, git commit 같은 명령어를 사용하지만, Git은 내부적으로 .git 디렉토리에 필요한 정보를 기록하면서 버전 관리를 수행한다.

중요한 점은 .git 디렉토리를 삭제하면 해당 프로젝트의 Git 이력이 사라진다는 것이다. 예를 들어 프로젝트 폴더 안에 main.c, README.md 같은 파일이 남아 있더라도, .git 디렉토리를 삭제하면 Git은 더 이상 그 폴더를 Git 저장소로 인식하지 못한다. 현재 파일 자체는 남아 있을 수 있지만, 이전 커밋 이력, 브랜치 정보, 로컬 설정 등 버전 관리와 관련된 정보는 사라진다.

따라서 .git 디렉토리는 일반적인 폴더처럼 함부로 삭제하면 안 된다. 특히 Git을 처음 배우는 단계에서는 “.git은 Git이 자동으로 만든 숨김 폴더니까 지워도 되겠지”라고 생각할 수 있지만, 실제로는 Git 저장소의 핵심 데이터가 들어 있는 중요한 디렉토리이다.

다만 .git 디렉토리를 삭제한다고 해서 현재 작업 중인 파일 자체가 반드시 삭제되는 것은 아니다. 예를 들어 프로젝트 폴더 안의 a.c, b.c, index.html 같은 파일은 그대로 남아 있을 수 있다. 하지만 Git이 관리하던 변경 이력과 저장소 정보는 사라진다. 그래서 해당 폴더는 Git 입장에서는 그냥 일반 디렉토리가 된다.

정리하면, Git을 사용하기 위해서는 프로젝트 디렉토리에서 git init을 실행하여 저장소를 초기화한다. 이때 생성되는 .git 디렉토리에는 Git 버전 관리에 필요한 핵심 정보들이 저장된다. 따라서 .git 디렉토리를 삭제하면 현재 파일은 남아 있더라도, Git이 관리하던 이력과 저장소 정보는 사라진다는 점을 반드시 알아두어야 한다.

📌추가 설명 (Additional Notes)

.git 디렉토리를 확인하는 기본 흐름은 다음과 같다.

mkdir my-project
cd my-project
git init
ls -a

이때 .git이 보이면 해당 디렉토리가 Git 저장소로 초기화된 것이다.

Git 저장소인지 확인하고 싶다면 다음 명령어를 사용할 수 있다.

git status

Git 저장소 안이라면 현재 브랜치와 파일 상태가 출력된다. 반대로 .git 디렉토리가 없거나 Git 저장소가 아니라면 오류 메시지가 나타난다.

Git 기본 사용법: 새 파일 추가와 Untracked 상태 (Git Basic Usage: Adding a New File & Untracked State)

Git 저장소를 만든 뒤 새 파일을 생성하면, Git은 그 파일을 자동으로 버전 관리 대상으로 포함하지 않는다. 예를 들어 Git 저장소 안에서 다음과 같이 helloWorld.c 파일을 만들었다고 하자.

vi helloWorld.c

또는 다른 편집기를 사용해서 같은 파일을 만들 수도 있다.

nano helloWorld.c

이렇게 새 파일을 만들고 나서 현재 Git 저장소의 상태를 확인하려면 다음 명령어를 사용한다.

git status

git status는 현재 저장소에서 어떤 파일이 변경되었는지, 어떤 파일이 스테이징 영역(Staging Area)에 올라가 있는지, 어떤 파일이 아직 Git의 관리 대상이 아닌지를 보여준다.

새로 만든 helloWorld.c 파일은 처음에는 Untracked Files 항목에 표시된다. 여기서 Untracked 는 Git이 아직 해당 파일을 추적하지 않는다는 뜻이다. 즉, 파일은 실제 디렉토리 안에 존재하지만, Git은 아직 이 파일의 변경 이력을 관리하지 않는다.

화면에 표시된 메시지를 보면 다음과 같은 내용이 나온다.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        helloWorld.c

이 문장은 “이 파일을 다음 커밋에 포함하려면 git add <file> 명령어를 사용하라”는 뜻이다. 즉, Git에게 “이 파일을 앞으로 관리 대상으로 삼아라”라고 알려주어야 한다.

이를 위해 다음 명령어를 입력한다.

git add helloWorld.c

git add는 파일을 스테이징 영역(Staging Area) 에 올리는 명령어이다. 새 파일의 경우에는 이 명령어를 통해 Git이 해당 파일을 추적하기 시작한다. 즉, helloWorld.c는 더 이상 Untracked 상태가 아니라, 다음 커밋에 포함될 준비가 된 Staged 상태가 된다.

여기서 중요한 점은 Git이 파일을 자동으로 모두 기록하지 않는다는 것이다. Git 저장소 안에 파일이 존재한다고 해서 무조건 버전 관리 대상이 되는 것은 아니다. 사용자가 git add를 통해 명시적으로 추가해야 Git이 해당 파일을 관리 대상으로 인식한다.

이는 실수를 줄이기 위한 구조이기도 하다. 프로젝트 폴더 안에는 임시 파일, 실행 결과 파일, 로그 파일, 빌드 결과물처럼 버전 관리에 포함하지 않아야 하는 파일도 있을 수 있다. Git은 사용자가 어떤 파일을 기록할지 선택할 수 있도록, 새 파일을 처음부터 자동으로 추적하지 않고 Untracked 상태로 둔다.

정리하면, Git 저장소 안에서 새 파일을 만들면 처음에는 Untracked 상태가 된다. 이 상태는 Git이 아직 해당 파일을 감시하거나 기록하지 않는 상태이다. 새 파일을 버전 관리 대상으로 포함하려면 git add 파일명 명령어를 실행해야 한다. 이후 파일은 Staged 상태가 되고, 다음 git commit을 실행할 때 저장소 이력에 기록될 수 있다.

vi helloWorld.c
git status
git add helloWorld.c
git status

이 흐름을 통해 새 파일이 Git에서 어떻게 관리 대상으로 들어가는지 확인할 수 있다.

📌추가 설명 (Additional Notes)

Git에서 새 파일을 추가하는 기본 흐름은 다음과 같다.

echo "hello world" > helloWorld.c
git status
git add helloWorld.c
git status
git commit -m "Add helloWorld.c"

상태 변화는 다음처럼 이해할 수 있다.

Untracked → Staged → Committed

즉, 새 파일은 처음에는 Git이 모르는 파일이고, git add를 실행하면 다음 커밋에 포함될 준비가 되며, git commit을 실행하면 Git 이력에 저장된다.

새 파일을 만들면 Git은 처음에 그 파일을 Untracked 상태로 표시한다. git add를 실행하면 파일은 Staged 상태가 되어 다음 커밋에 포함될 준비가 된다. 하지만 아직 커밋된 것은 아니므로, 실제 이력에 저장하려면 git commit을 실행해야 한다.

Git 기본 사용법: git add와 Staged 상태 (Git Basic Usage: git add & Staged State)

Git 저장소 안에서 새로운 파일을 만들면, 처음에는 Git이 그 파일을 자동으로 관리하지 않는다. 예를 들어 helloWorld.c라는 파일을 새로 만들고 git status를 실행하면, Git은 이 파일을 추적되지 않은 파일(Untracked File) 로 표시한다. 이는 파일이 실제 디렉토리 안에는 존재하지만, 아직 Git의 버전 관리 대상에는 포함되지 않았다는 뜻이다.

새 파일을 Git의 관리 대상으로 포함하려면 git add 명령어를 사용한다.

git add helloWorld.c

이 명령어를 실행하면 helloWorld.c 파일은 Git의 스테이징 영역(Staging Area) 에 올라간다. 스테이징 영역은 다음 커밋(Commit) 에 포함할 변경 내용을 임시로 모아두는 공간이다. 즉, git add는 단순히 “파일을 감시 대상으로 등록한다”는 의미도 있지만, 더 정확하게는 “이 파일의 현재 변경 내용을 다음 커밋에 포함하도록 준비한다”는 뜻이다.

git add helloWorld.c를 실행한 뒤 다시 git status를 확인하면, 화면에는 다음과 비슷한 내용이 나타난다.

Changes to be committed:
  new file:   helloWorld.c

여기서 Changes to be committed 는 “커밋될 예정인 변경 사항”이라는 뜻이다. 그리고 new file: helloWorld.c 는 새 파일인 helloWorld.c가 다음 커밋에 포함될 준비가 되었다는 의미이다. 이 상태가 바로 Staged 상태이다.

이전 단계의 Untracked 상태와 비교하면 차이가 분명하다. Untracked 상태에서는 Git이 아직 해당 파일을 관리하지 않는다. 하지만 git add를 실행하면 Git은 그 파일을 다음 커밋에 포함할 대상으로 인식한다. 다만 아직 커밋이 완료된 것은 아니다. 즉, 파일이 Git 이력에 영구적으로 저장된 상태는 아니고, 커밋을 기다리는 상태이다.

화면에 보이는 use "git rm --cached <file>..." to unstage라는 문장은, 스테이징 영역에 올린 파일을 다시 내리고 싶을 때 사용할 수 있는 안내이다. 예를 들어 실수로 helloWorld.c를 git add 했다면 다음 명령어로 스테이징 상태를 취소할 수 있다.

git rm --cached helloWorld.c

이 명령어는 파일 자체를 삭제하는 것이 아니라, Git의 스테이징 영역에서만 제거한다. 즉, helloWorld.c 파일은 작업 디렉토리에 그대로 남아 있지만, 다음 커밋에 포함될 예정에서는 빠지게 된다. 새 파일의 경우 다시 Untracked 상태로 돌아간다고 이해하면 된다.

정리하면, 새 파일을 만들면 처음에는 Untracked 상태가 된다. 이후 git add helloWorld.c를 실행하면 해당 파일은 Staged 상태가 되어 다음 커밋에 포함될 준비가 된다. 하지만 아직 Committed 상태는 아니므로, 실제 Git 이력에 저장하려면 이후에 git commit을 실행해야 한다.

vi helloWorld.c
git status
git add helloWorld.c
git status
git commit -m "Add helloWorld.c"

이 흐름에서 상태 변화는 다음과 같이 정리할 수 있다.

Untracked → Staged → Committed

Git의 기본 사용법에서 이 흐름은 매우 중요하다. Git은 새 파일이 생겼다고 해서 바로 기록하지 않고, 사용자가 git add로 명시적으로 다음 커밋에 포함할 변경 내용을 선택하게 한다. 이 구조 덕분에 개발자는 어떤 파일을 커밋할지 직접 결정할 수 있다.

Git 기본 사용법: 커밋으로 현재 상태 저장하기 (Git Basic Usage: Commit)

Git에서 파일을 새로 만들고 git add로 스테이징 영역에 올렸다면, 다음 단계는 커밋(Commit) 이다. 커밋은 현재까지 준비된 변경 내용을 Git 저장소에 영구적인 기록으로 남기는 작업이다. 쉽게 말하면, 지금 상태를 하나의 버전으로 “박제해서 보관하는 것”이라고 이해할 수 있다.

커밋을 실행할 때는 보통 다음과 같이 git commit 명령어를 사용한다.

git commit -m "first git commit"

여기서 -m 옵션은 커밋 메시지(Commit Message) 를 명령어 안에서 바로 작성하겠다는 의미이다. 커밋 메시지는 사람이 나중에 변경 내용을 이해할 수 있도록 남기는 설명이다. 따라서 아무 의미 없는 문장보다는, “무엇을 변경했는지”를 알 수 있는 내용을 작성하는 것이 좋다.

예를 들어 새 파일 helloWorld.c를 처음 추가한 상황이라면 다음과 같은 메시지를 사용할 수 있다.

git commit -m "Add helloWorld.c"

커밋을 실행하면 Git은 스테이징 영역에 올라와 있던 변경 내용을 로컬 저장소(Local Repository)에 기록한다. 이때 화면에는 커밋 결과가 출력된다. 예시 화면에서는 다음과 같은 내용이 보인다.

[master (root-commit) 1c686a5] first git commit
 1 file changed, 5 insertions(+)
 create mode 100644 helloWorld.c

여기서 root-commit 은 이 저장소에서 처음 만들어진 커밋이라는 뜻이다. 아직 이전 커밋이 없기 때문에, 첫 번째 커밋은 루트 커밋(Root Commit)이 된다.

1 file changed는 하나의 파일이 변경되었다는 의미이고, 5 insertions(+)는 다섯 줄이 추가되었다는 의미이다. create mode 100644 helloWorld.c는 helloWorld.c라는 새 파일이 생성되었고, 일반 파일 권한 모드로 저장되었다는 뜻이다.

중간에 보이는 1c686a5 같은 알 수 없는 문자와 숫자의 조합은 커밋 해시(Commit Hash) 또는 커밋 ID(Commit ID) 의 짧은 형태이다. Git은 각 커밋을 고유하게 식별하기 위해 해시 값을 사용한다. 이 값은 커밋마다 다르게 생성되며, 나중에 특정 커밋으로 이동하거나, 특정 시점의 내용을 확인하거나, 이전 상태로 되돌릴 때 사용할 수 있다.

즉, 커밋 해시는 Git에서 각 버전을 구분하는 식별자(Identifier) 역할을 한다. 사람이 보기에는 복잡한 문자처럼 보이지만, Git 입장에서는 “이 커밋이 정확히 어떤 기록인가”를 구분하는 중요한 값이다.

커밋을 완료한 뒤 다시 상태를 확인하려면 다음 명령어를 사용한다.

git status

커밋이 정상적으로 완료되었고 추가로 수정된 파일이 없다면 다음과 같은 메시지가 나타난다.

On branch master
nothing to commit, working tree clean

여기서 nothing to commit 은 현재 커밋할 변경 내용이 없다는 뜻이다. working tree clean 은 작업 디렉토리(Working Tree)가 깨끗하다는 뜻으로, 마지막 커밋 이후 변경된 파일이 없다는 의미이다.

즉, 파일을 수정하고 git add로 스테이징한 뒤 git commit으로 저장소에 기록했기 때문에, 현재 작업 공간에는 Git이 새로 기록해야 할 변화가 남아 있지 않은 상태이다.

정리하면, git commit은 Git에서 변경 내용을 하나의 버전으로 확정하는 명령어이다. git add가 다음 커밋에 포함할 파일을 준비하는 단계라면, git commit은 그 준비된 변경 내용을 실제 Git 이력에 저장하는 단계이다. 커밋이 만들어지면 Git은 고유한 커밋 해시를 부여하고, 이 값을 통해 나중에 특정 버전을 찾거나 되돌아갈 수 있다.

Git의 기본 흐름은 다음과 같이 정리할 수 있다.

파일 생성 또는 수정 → git add → git commit → git status 확인

상태 변화로 보면 다음과 같다.

Untracked 또는 Modified → Staged → Committed

결국 Git에서 커밋은 단순한 저장이 아니라, 프로젝트의 특정 시점을 기록하는 작업이다. 앞으로 Git을 실습할 때는 파일을 수정하고, 변경 내용을 스테이징하고, 커밋을 만든 뒤, git status로 현재 상태가 깨끗한지 확인하는 흐름을 반복하게 된다.

📌추가 설명 (Additional Notes)

커밋 메시지는 나중에 이력을 볼 때 매우 중요하다. 예를 들어 다음처럼 작성하는 것이 좋다.

git commit -m "Add helloWorld.c"
git commit -m "Fix login error"
git commit -m "Update README"

반대로 다음처럼 너무 모호한 메시지는 좋지 않다.

git commit -m "update"
git commit -m "fix"
git commit -m "test"

커밋 메시지는 “나중에 내가 봐도 이 변경이 무엇인지 알 수 있게” 작성하는 것이 가장 좋다.

Git에서 새 파일은 처음에 Untracked 상태이다. git add를 하면 Staged 상태가 되고, git commit을 하면 저장소에 기록되어 Unmodified 상태가 된다. 이후 파일을 수정하면 Modified 상태가 되며, 다시 git add와 git commit을 거쳐 새로운 버전으로 저장된다. Git은 이 과정을 통해 어떤 변경을 기록할지 사용자가 직접 선택할 수 있게 해준다.

파일의 상태 변화 주기 (File Status Lifecycle in Git)

Git에서 파일은 작업 과정에 따라 여러 상태를 오가게 된다. 대표적인 상태는 추적되지 않음(Untracked), 수정되지 않음(Unmodified), 수정됨(Modified), 스테이지됨(Staged) 이다. 이 상태 변화를 이해하면 Git의 기본 사용 흐름을 더 쉽게 따라갈 수 있다.

먼저 Untracked 상태는 Git이 아직 관리하지 않는 파일을 의미한다. 새 파일을 만들었지만 아직 git add를 하지 않았다면, Git은 그 파일을 추적 대상으로 보지 않는다. 즉, 파일은 디렉토리에 존재하지만 Git의 변경 이력에는 포함되지 않은 상태이다.

이 파일을 Git의 관리 대상으로 포함하려면 git add 명령어를 사용한다.

git add 파일명

새 파일에 대해 git add를 실행하면 파일은 Staged 상태가 된다. 여기서 Staged는 무대(Stage)에 올려놓았다는 의미처럼 이해할 수 있다. 즉, “이 파일을 다음 커밋(Commit)에 포함하겠다”라고 표시한 상태이다.

그다음 git commit을 실행하면 Staged 상태에 있던 파일이 Git 저장소에 기록된다. 커밋이 완료되면 해당 파일은 Git이 알고 있는 최신 원본 상태가 된다. 이 상태를 Unmodified 라고 한다. Unmodified는 마지막 커밋 이후 파일이 수정되지 않았다는 뜻이다.

git commit -m "커밋 메시지"

이후 사용자가 파일 내용을 다시 수정하면, Git은 해당 파일을 Modified 상태로 인식한다. Modified는 이미 Git이 추적하고 있는 파일이지만, 마지막 커밋 이후 내용이 바뀐 상태를 의미한다. 예를 들어 helloWorld.c 파일을 커밋한 뒤 다시 내용을 추가하거나 수정하면, 그 파일은 Modified 상태가 된다.

Modified 상태의 파일을 다시 다음 커밋에 포함하려면 git add를 실행해야 한다. 이때 git add는 단순히 새 파일을 추적 대상으로 등록하는 역할만 하는 것이 아니라, 수정된 파일의 현재 상태를 다음 커밋에 포함하도록 스테이징(Staging) 하는 역할을 한다.

git add helloWorld.c

이렇게 하면 Modified 상태였던 파일은 다시 Staged 상태가 된다. 그리고 git commit을 실행하면 그 변경 내용이 새로운 커밋으로 저장되고, 파일은 다시 Unmodified 상태가 된다.

따라서 Git에서 기본적인 상태 변화는 다음과 같이 이해할 수 있다.

Untracked → Staged → Unmodified → Modified → Staged → Unmodified

조금 더 실제 작업 흐름으로 표현하면 다음과 같다.

파일 생성
git add 파일명
git commit -m "첫 커밋"
파일 수정
git add 파일명
git commit -m "수정 내용 저장"

여기서 Remove the file 은 파일을 더 이상 Git이 추적하지 않게 만드는 상황을 의미할 수 있다. 예를 들어 추적 중인 파일을 삭제하고 그 변경을 커밋하면, Git은 해당 파일이 제거되었다는 사실을 이력에 기록한다. 반대로 새 파일을 git add 했다가 다시 스테이징에서 내리거나 추적 대상에서 제외하면, 새 파일은 다시 Untracked 상태로 돌아갈 수 있다.

중요한 점은 Git이 파일을 자동으로 무조건 저장하지 않는다는 것이다. 파일을 수정하면 Modified 상태가 되고, 그 변경을 커밋에 포함하려면 사용자가 직접 git add로 Staged 상태로 만들어야 한다. 그리고 git commit을 해야 비로소 Git의 이력에 저장된다.

결국 Git의 파일 상태 변화는 “작업한 내용을 바로 저장하는 방식”이 아니라, 사용자가 어떤 변경을 다음 버전으로 남길지 선택하는 구조이다. 이 구조 덕분에 여러 파일을 수정했더라도 필요한 변경만 골라 커밋할 수 있고, 변경 이력을 더 깔끔하게 관리할 수 있다.

Git 사용자 설정이다. user.name은 커밋 작성자 이름이고, user.email은 커밋 작성자 이메일이다. core.editor vim은 Git이 메시지를 입력받을 때 사용할 기본 편집기를 vim으로 설정한 것이다. init.defaultBranch heesu는 앞으로 git init으로 새 저장소를 만들 때 기본 브랜치 이름을 heesu로 하겠다는 뜻이다.

Git 저장소 안에서 파일 상태를 확인하고, 새 파일을 Git 관리 대상으로 추가하였다. README.md가 처음에는 Untracked 상태였고, git add README.md 후에는 커밋 준비 상태인 Staged 상태가 된 화면이다.

git commit -a -m 'first commit w12'로 .gitignore와 README.md를 커밋했고, 이후 git status에서 working tree clean이 나와 더 이상 저장할 변경사항이 없다는 화면이다.

echo 로 second line을 추가하니 modified: README.md가 뜬다. git diff로 바뀐 상태를 확인하는 연습을 했다.

git commit이후에 git log에서 자세한 설명을 확인했다.

commit 이후엔 second line이 추가된 README.md 가 원본이 되었다.

checkout으로 입력하니 second line이 사라졌다. 그후 switch로 다시 second line이 돌아온것을 확인할수있다.

1️⃣ Virtual Memory and Demand Paging

가상메모리(Virtual Memory)

이번 주차에서는 메모리 관리(Memory Management) 중 가상메모리(Virtual Memory)를 학습한다. 프로세스(Process)가 실행되려면 메모리가 필요하지만, 실제 물리 메모리(Physical Memory)는 크기가 제한되어 있다. 따라서 모든 프로그램을 한 번에 메모리에 올려 실행하기는 어렵다.

이를 해결하기 위해 운영체제(Operating System)는 가상메모리를 사용한다. 가상메모리는 프로그램 전체가 아니라, 실행에 필요한 부분만 메모리에 올려 사용하는 방식이다. 대표적인 방법이 요구 페이징(Demand Paging)이다. 필요한 페이지(Page)가 메모리에 없을 때는 페이지 부재(Page Fault)가 발생하고, 운영체제가 해당 페이지를 메모리로 가져온다.

또한 메모리가 부족하면 기존 페이지 중 하나를 교체해야 한다. 이를 위해 페이지 대치 알고리즘(Page Replacement Algorithm)이 사용된다. 대표적인 알고리즘으로는 먼저 들어온 페이지를 교체하는 FIFO(First-In, First-Out)와, 가장 오래 사용되지 않은 페이지를 교체하는 LRU(Least Recently Used)가 있다.

페이지 교체가 너무 자주 발생하면 실제 프로그램 실행보다 페이지를 넣고 빼는 데 시간이 더 많이 걸릴 수 있다. 이런 현상을 스래싱(Thrashing)이라고 하며, 시스템 성능을 크게 떨어뜨린다.

이번 주차의 핵심은 가상메모리의 필요성, 요구 페이징, 페이지 부재, 페이지 대치 알고리즘, 스래싱의 흐름을 연결해서 이해하는 것이다.

가상메모리(Virtual Memory)의 필요성 예제

가상메모리(Virtual Memory)의 필요성은 책상과 책장의 예시로 쉽게 이해할 수 있다. 집에서 공부할 때 책상 위에는 지금 당장 사용하는 책이나 노트만 올려두고, 나머지 책들은 책장에 보관해두는 경우가 많다.

만약 모든 책을 한꺼번에 책상 위에 올려둔다면 책상이 금방 복잡해지고, 오히려 필요한 책을 찾거나 사용하는 데 불편함이 생길 수 있다. 책상 공간은 제한되어 있기 때문에, 현재 필요한 자료만 올려두는 것이 더 효율적이다.

컴퓨터의 메모리(Memory)도 이와 비슷하다. 물리 메모리(Physical Memory)의 크기는 제한되어 있기 때문에, 프로그램 전체를 한 번에 메모리에 올리는 것은 비효율적일 수 있다. 그래서 운영체제(Operating System)는 실행에 필요한 부분만 메모리에 올리고, 나머지는 보조기억장치(Secondary Storage)에 두었다가 필요할 때 가져온다.

이처럼 필요한 것만 선택적으로 가져와 사용하는 방식이 가상메모리의 핵심 개념이다. 가상메모리는 제한된 물리 메모리를 더 효율적으로 사용하게 해주며, 여러 프로그램이 동시에 실행될 수 있도록 돕는다.

필요한 데이터 가져오기(Demand Paging)

프로그램은 실행되기 위해 메모리(Memory)에 적재되어야 한다. 하지만 실제 물리 메모리(Physical Memory)보다 더 큰 프로그램을 실행해야 하는 경우도 있다. 이때 프로그램 전체를 한 번에 메모리에 올리는 대신, 실행에 필요한 부분만 선택적으로 올려 사용할 수 있다.

이 방식이 가능하려면, 실행 중 필요한 데이터가 메모리에 있는지 확인해야 한다. 만약 필요한 데이터가 메모리에 올라와 있지 않다면 페이지 부재(Page Fault)가 발생한다. 그러면 운영체제(Operating System)는 해당 데이터를 보조기억장치(Secondary Storage)에서 찾아 메모리로 가져온 뒤, 프로그램 실행을 계속 진행한다.

따라서 이번 내용의 핵심 질문은 두 가지로 정리할 수 있다. 첫 번째는 왜 모든 내용을 한 번에 메모리에 올리지 않는가이고, 두 번째는 필요한 데이터를 어떻게 가져와 사용할 것인가이다. 이 두 질문을 중심으로 가상메모리(Virtual Memory)의 필요성과 동작 방식을 이해해야 한다.

가상메모리(Virtual Memory)의 필요성

이번 차시에서는 가상메모리(Virtual Memory)의 동작을 이해하기 위해, 프로그램을 필요한 부분만 메모리에 올려 실행하는 방식과 실행 중 필요한 데이터를 가져오는 과정을 살펴본다.

프로그램(Program)이 실행되기 위해서는 먼저 메모리(Memory)에 적재되어야 한다. 하지만 여기서 문제가 발생한다. 프로그램의 크기가 점점 커지면서 실제 물리 메모리(Physical Memory)보다 더 큰 프로그램도 실행해야 하는 상황이 생긴다.

또한 컴퓨터에서는 하나의 프로그램만 실행되는 것이 아니라, 여러 프로그램이 동시에 실행되는 경우가 많다. 즉, 메모리의 크기는 제한되어 있는데 메모리를 필요로 하는 프로그램의 수와 크기는 계속 늘어나는 상황이 된다.

이러한 문제를 해결하기 위해 운영체제(Operating System)는 프로그램 전체를 한 번에 메모리에 올리지 않고, 실행에 필요한 부분만 선택적으로 메모리에 올리는 가상메모리 방식을 사용한다. 가상메모리는 제한된 물리 메모리를 효율적으로 사용하고, 여러 프로그램이 동시에 실행될 수 있도록 돕는 중요한 메모리 관리 기법이다.

기존 메모리 적재 방식의 한계(Limitations of Traditional Memory Loading)

기존 방식처럼 프로그램(Program) 전체를 메모리(Memory)에 한 번에 올려 실행한다고 생각해보자. 이 경우 실제로 지금 당장 사용하지 않는 부분까지 함께 메모리에 적재되기 때문에, 불필요하게 메모리 공간을 차지하게 된다.

더 큰 문제는 프로그램의 크기가 물리 메모리(Physical Memory)보다 큰 경우이다. 프로그램 중 일부만 사용하면 실행할 수 있는 상황이라도, 전체를 한 번에 메모리에 올려야 한다면 실행 자체가 불가능해질 수 있다.

결국 문제의 핵심은 필요한 만큼만 사용하면 되는데, 전체를 모두 메모리에 올려야 하는 구조에 있다. 이러한 방식은 메모리 낭비(Memory Waste)를 발생시키고, 큰 프로그램의 실행을 제한한다.

따라서 운영체제(Operating System)는 프로그램 전체가 아니라 실행에 필요한 부분만 선택적으로 메모리에 올리는 방법이 필요하다. 이 문제를 해결하기 위해 등장한 개념이 가상메모리(Virtual Memory)이다.

해결 방안: 가상메모리(Virtual Memory)

기존 메모리 적재 방식의 한계를 해결하기 위한 방법이 가상메모리(Virtual Memory)이다. 가상메모리의 핵심은 프로그램(Program) 전체를 한 번에 메모리(Memory)에 올리는 것이 아니라, 실행에 필요한 부분만 선택적으로 메모리에 올려 사용하는 것이다.

이렇게 하면 지금 당장 사용하지 않는 부분은 굳이 물리 메모리(Physical Memory)를 차지하지 않는다. 그 결과 제한된 메모리 공간을 더 효율적으로 사용할 수 있다.

또한 프로그램의 전체 크기가 실제 메모리보다 크더라도, 필요한 부분을 나누어 메모리에 올리면서 실행할 수 있다. 즉, 가상메모리는 메모리 낭비를 줄이고, 더 큰 프로그램이나 여러 프로그램을 동시에 실행할 수 있도록 도와주는 메모리 관리(Memory Management) 방식이다.

가상메모리(Virtual Memory)의 동작 구조

그림을 보면 각 프로세스(Process)가 요구하는 메모리 크기가 상당히 크다는 것을 알 수 있다. 예를 들어 프로세스 A(Process A)는 4GB의 메모리를 요구하고, 다른 프로세스들도 각각 일정한 크기의 메모리를 필요로 한다.

하지만 실제 물리 메모리(Physical Memory)는 이 모든 프로세스를 동시에 그대로 담기에는 부족한 경우가 많다. 따라서 운영체제(Operating System)는 메모리 관리자(Memory Manager) 역할을 하면서, 각 프로세스를 전체 그대로 메모리에 올리지 않는다.

대신 실행에 필요한 부분만 선택적으로 물리 메모리에 올리고, 당장 사용하지 않는 나머지 부분은 저장장치(Storage), 즉 보조기억장치(Secondary Storage)에 두고 관리한다.

즉, 프로세스가 요구하는 전체 메모리 크기와 실제 물리 메모리에 올라가는 크기는 다를 수 있다. 이 차이를 운영체제가 조정해주는 구조가 바로 **가상메모리(Virtual Memory)**이다.

가상메모리(Virtual Memory)의 개념

가상메모리(Virtual Memory)의 가장 중요한 특징은 프로그램(Program) 전체가 아니라 일부만 메모리(Memory)에 올라간 상태에서도 실행될 수 있다는 점이다. 즉, 지금 당장 필요한 부분만 물리 메모리(Physical Memory)에 올라가고, 나머지 부분은 메모리에 없는 상태로 존재한다.

여기서 메모리에 없다는 것은 데이터가 사라졌다는 의미가 아니다. 당장 사용하지 않는 부분은 저장장치(Storage), 즉 보조기억장치(Secondary Storage)에 유지되어 있다가 필요한 시점에 다시 메모리로 올라온다.

중요한 것은 프로그램이 바라보는 관점과 실제 시스템 내부의 구조가 다르다는 점이다. 프로그램 입장에서는 전체 메모리 공간이 하나의 연속된 공간처럼 보인다. 즉, 프로그램은 자신이 필요한 메모리 전체를 끊김 없이 사용할 수 있다고 인식한다.

하지만 실제 시스템 내부에서는 물리 메모리에 일부만 올라와 있고, 나머지는 저장장치에 나뉘어 저장되어 있다. 운영체제(Operating System)는 이 과정을 관리하면서 필요한 부분을 메모리에 올리고, 필요하지 않은 부분은 저장장치에 두는 방식으로 동작한다.

결국 가상메모리는 프로그램에게는 연속적인 메모리 공간을 제공하는 것처럼 보이게 하면서, 실제 내부에서는 필요한 부분만 나누어 관리하는 메모리 관리(Memory Management) 방식이다.

요구 페이징(Demand Paging)의 개념

앞에서 살펴본 것처럼 가상메모리(Virtual Memory)에서는 프로그램(Program) 전체가 아니라 일부만 메모리(Memory)에 올라간 상태에서도 실행될 수 있다.

그렇다면 메모리에 올라와 있지 않은 나머지 부분은 언제, 어떻게 사용될까?

프로그램은 처음부터 필요한 모든 내용을 메모리에 올리지 않고 실행을 시작한다. 하지만 실행이 진행되다 보면 현재 메모리에 없는 코드(Code)나 데이터(Data)가 필요해질 수 있다. 이때 운영체제(Operating System)는 필요한 부분을 그 시점에 메모리로 가져온다.

이처럼 처음부터 모든 페이지(Page)를 메모리에 올리는 것이 아니라, 실제로 필요해졌을 때 해당 페이지를 메모리에 적재하는 방식을 요구 페이징(Demand Paging)이라고 한다.

즉, 요구 페이징은 “필요할 때 가져온다”는 개념을 바탕으로 한다. 이를 통해 메모리 사용량을 줄이고, 프로그램 실행에 필요한 부분만 효율적으로 관리할 수 있게 된다.

요구 페이징(Demand Paging)의 핵심 특징

요구 페이징(Demand Paging)은 프로그램(Program)을 시작할 때 모든 내용을 미리 메모리(Memory)에 올려두는 방식이 아니다. 실행 중에 실제로 필요한 순간이 되었을 때, 해당 부분을 메모리로 가져와 사용하는 방식이다.

즉, 어떤 페이지(Page)가 필요해지기 전까지는 물리 메모리(Physical Memory)에 올리지 않는다. 그러다가 프로그램이 해당 페이지에 접근하려는 시점에 운영체제(Operating System)가 그 페이지를 메모리로 가져오고, 실행을 계속 이어가게 한다.

이 방식에서는 실행 과정에 따라 필요한 데이터(Data)나 코드(Code)만 선택적으로 메모리에 올라간다. 따라서 프로그램 전체가 항상 메모리에 존재할 필요는 없다.

하지만 프로그램 입장에서는 자신이 사용하는 전체 메모리 공간이 하나의 연속된 공간처럼 보인다. 실제 시스템 내부에서는 일부만 메모리에 있고 나머지는 저장장치(Storage)에 있는 구조이지만, 프로그램은 이 차이를 직접 인식하지 않고 실행을 계속한다.

결국 요구 페이징은 필요한 부분만 필요할 때 메모리에 올려 메모리를 효율적으로 사용하는 가상메모리(Virtual Memory)의 핵심 동작 방식이라고 볼 수 있다.

요구 페이징(Demand Paging)의 동작 과정

요구 페이징(Demand Paging)은 프로그램(Program)이 실행되는 중 특정 주소(Address)에 접근할 때 동작한다. 먼저 운영체제(Operating System)는 해당 주소에 필요한 데이터(Data)가 현재 물리 메모리(Physical Memory)에 올라와 있는지 확인한다.

만약 해당 데이터가 메모리에 존재한다면, 프로그램은 바로 그 데이터를 사용하고 실행을 계속 이어간다. 하지만 필요한 데이터가 메모리에 없다면, 즉시 사용할 수 없기 때문에 운영체제가 저장장치(Storage)에서 해당 데이터를 찾아 물리 메모리로 가져온다.

그 후 운영체제는 원래 실행하려던 명령(Instruction)을 다시 수행하게 하고, 프로그램은 중단되었던 흐름을 이어서 진행한다.

정리하면, 요구 페이징은 프로그램이 특정 주소에 접근했을 때 필요한 데이터가 메모리에 있는지 확인하고, 없을 경우 저장장치에서 가져와 메모리에 적재한 뒤 다시 실행을 이어가는 방식이다.

요구 페이징(Demand Paging)의 동작 관점

요구 페이징(Demand Paging)은 메인 메모리(Main Memory)와 보조기억장치(Secondary Storage) 사이에서 데이터를 주고받으며 동작한다. 그림에서 왼쪽은 메인 메모리, 오른쪽은 보조기억장치를 나타낸다.

프로그램 A(Program A)와 프로그램 B(Program B)가 실행 중이지만, 두 프로그램의 전체 내용이 모두 메모리에 올라와 있는 것은 아니다. 실제로는 실행에 필요한 일부만 메인 메모리에 올라와 있고, 나머지 부분은 보조기억장치에 저장되어 있다.

프로그램 실행이 진행되다가 현재 메모리에 없는 데이터(Data)가 필요해지면, 운영체제(Operating System)는 보조기억장치에 있는 해당 데이터를 메모리로 가져온다. 이때 메모리에 빈 공간이 부족하면 기존에 메모리에 있던 일부 데이터가 보조기억장치로 나가고, 새로 필요한 데이터가 그 자리를 대신 차지한다.

즉, 요구 페이징은 메모리와 보조기억장치 사이에서 필요한 데이터가 들어오고 나가는 교체 과정을 통해 프로그램 실행을 이어가는 방식이다. 이 그림은 요구 페이징이 실제로 이러한 데이터 교체(Page Replacement) 과정을 통해 동작한다는 점을 보여준다.

적재 방식 비교(Loading Method Comparison)

페이지(Page)는 프로그램(Program)을 일정한 크기로 나눈 단위이다. 즉, 프로그램 전체를 하나의 덩어리로 관리하는 것이 아니라 여러 개의 작은 블록(Block)으로 나누어 각각 메모리(Memory)에 올리고 관리하는 구조라고 볼 수 있다.

페이지를 메모리에 올리는 방식은 크게 선적재(Preloading)와 요구 페이징(Demand Paging)으로 비교할 수 있다.

선적재(Preloading)는 프로그램을 실행하기 전에 필요한 페이지를 미리 메모리에 올리는 방식이다. 이 방식은 초기에 많은 페이지를 한꺼번에 올려야 하므로 실행 준비 시간이 길어질 수 있다. 또한 실제로 사용하지 않는 페이지까지 메모리에 포함될 수 있어 메모리 낭비가 발생할 수 있다.

반면 요구 페이징(Demand Paging)은 프로그램 실행 중 필요한 페이지가 생겼을 때 그때그때 메모리에 올리는 방식이다. 필요한 페이지만 선택적으로 가져오기 때문에 초기 적재 부담이 줄어들고, 메모리를 더 효율적으로 사용할 수 있다.

따라서 두 방식의 핵심 차이는 페이지를 언제 메모리에 올리느냐에 있다. 선적재는 실행 전에 미리 올리는 방식이고, 요구 페이징은 실행 중 실제로 필요해진 시점에 올리는 방식이다.

페이지 부재(Page Fault)의 개념

요구 페이징(Demand Paging)에서 중요한 개념 중 하나는 페이지 부재(Page Fault)이다. 프로그램(Program)이 실행되는 중 특정 주소(Address)의 페이지(Page)에 접근했을 때, 해당 페이지가 현재 메모리(Memory)에 없는 경우가 있다. 이때 페이지 부재가 발생한다.

운영체제(Operating System)는 먼저 페이지 테이블(Page Table)을 통해 해당 페이지가 메모리에 있는지 확인한다. 페이지 테이블에는 각 페이지가 현재 메모리에 올라와 있는지를 나타내는 값이 저장되어 있다. 이 값이 1이면 페이지가 메모리에 존재한다는 의미이고, 0이면 아직 메모리에 없다는 의미이다.

페이지가 메모리에 있으면 프로그램은 바로 해당 페이지에 접근할 수 있다. 반대로 페이지가 메모리에 없다면 페이지 부재가 발생하고, 운영체제는 필요한 페이지를 저장장치(Storage)에서 가져와 메모리에 적재한다.

여기서 중요한 점은 페이지 부재를 단순한 오류(Error)로 보면 안 된다는 것이다. 요구 페이징에서는 처음부터 프로그램 전체가 아니라 일부 페이지만 메모리에 올려두기 때문에, 실행 중 메모리에 없는 페이지가 필요해지는 상황은 자연스럽게 발생한다.

따라서 페이지 부재는 문제가 생겼다는 의미라기보다, 이제 해당 페이지가 필요하다는 신호라고 볼 수 있다. 즉, 페이지 부재는 운영체제가 필요한 페이지를 메모리에 가져오도록 만드는 정상적인 동작 과정의 일부이다.

페이지 부재(Page Fault)와 타당 비트(Valid Bit)

페이지 부재(Page Fault)는 프로그램(Program)이 특정 페이지(Page)에 접근하려고 할 때, 해당 페이지가 현재 메모리(Memory)에 없는 경우 발생한다. 이를 확인하기 위해 운영체제(Operating System)는 페이지 테이블(Page Table)을 사용한다.

그림을 보면 논리 주소(Logical Address)에서 시작해 페이지 테이블을 거쳐 물리 메모리(Physical Memory)로 연결되는 구조를 확인할 수 있다. 이때 페이지 테이블에는 각 페이지가 현재 메모리에 올라와 있는지를 표시하는 값이 포함되어 있다. 이 값을 타당 비트(Valid Bit) 또는 비타당 비트(Invalid Bit)라고 한다.

타당 비트가 1이면 해당 페이지가 현재 메모리에 존재한다는 의미이다. 따라서 프로그램은 바로 물리 메모리에 접근하여 실행을 이어갈 수 있다. 반대로 비타당 비트가 0이면 해당 페이지가 아직 메모리에 올라와 있지 않다는 의미이다.

이 경우에는 해당 페이지를 바로 사용할 수 없기 때문에 페이지 부재가 발생한다. 그러면 운영체제는 필요한 페이지를 저장장치(Storage)에서 찾아 메모리로 가져오는 과정을 수행한다.

즉, 타당 비트와 비타당 비트는 각 페이지가 현재 메모리에 존재하는지 판단하고, 프로그램이 해당 페이지에 접근할 수 있는지를 결정하는 기준이라고 볼 수 있다.

페이지 부재(Page Fault) 발생 시점

페이지 부재(Page Fault)는 프로그램(Program)이 실행되는 과정에서 자연스럽게 여러 번 발생할 수 있다. 요구 페이징(Demand Paging)에서는 처음부터 모든 페이지(Page)를 메모리(Memory)에 올려두지 않기 때문이다.

먼저 프로그램을 처음 실행했을 때 페이지 부재가 발생할 수 있다. 아직 필요한 페이지들이 모두 메모리에 올라와 있지 않은 상태이기 때문에, 처음 접근하는 페이지에서 페이지 부재가 발생한다.

또한 실행이 진행되면서 이전에 사용하지 않았던 새로운 코드(Code)나 데이터(Data) 영역에 접근할 때도 페이지 부재가 발생할 수 있다. 프로그램의 실행 흐름이 바뀌거나 다른 기능을 사용하게 되면, 그 순간 새로운 페이지가 필요해질 수 있기 때문이다.

결국 페이지 부재는 한 번만 발생하는 현상이 아니다. 프로그램이 실행되는 동안 필요한 페이지가 메모리에 없을 때마다 반복적으로 발생할 수 있으며, 이는 요구 페이징 구조에서 나타나는 정상적인 동작 과정이라고 볼 수 있다.

페이지 부재(Page Fault) 처리 흐름

페이지 부재(Page Fault)가 발생하면 운영체제(Operating System)가 개입하여 처리를 시작한다. 먼저 프로그램(Program)이 특정 주소(Address)에 접근하면, 운영체제는 페이지 테이블(Page Table)을 통해 해당 페이지(Page)가 메모리(Memory)에 있는지 확인한다.

이때 해당 페이지가 메모리에 없다면 페이지 부재 처리가 시작된다. 운영체제는 저장장치(Storage)에 있는 해당 페이지를 찾아 읽어오고, 그 페이지를 물리 메모리(Physical Memory)에 적재한다.

페이지가 메모리에 올라오면 운영체제는 중단되었던 명령(Instruction)을 다시 실행한다. 실제 내부 동작에서는 프로그램 실행이 잠시 멈췄다가 다시 이어지지만, 프로그램 입장에서는 중단 없이 연속적으로 실행되는 것처럼 보인다.

정리하면, 페이지 부재 처리 흐름은 페이지 테이블 확인, 운영체제 개입, 저장장치에서 페이지 읽기, 메모리 적재, 중단된 명령 재실행의 과정으로 이루어진다.

페이지 부재(Page Fault) 처리 흐름 그림

그림은 페이지 부재(Page Fault)가 발생했을 때 처리되는 과정을 단계별로 보여준다.

먼저 프로세스(Process)가 실행되는 중 1️⃣논리 주소(Logical Address)를 통해 특정 페이지(Page)에 접근을 시도한다. 이때 운영체제(Operating System)는 2️⃣페이지 테이블(Page Table)을 확인하여 해당 페이지가 현재 메모리(Memory)에 있는지 판단한다.

만약 해당 페이지가 메모리에 없다면 3️⃣페이지 부재가 발생한다. 그러면 운영체제가 개입하여 메모리 안에서 4️⃣비어 있는 공간을 찾고, 5️⃣저장장치(Storage)에 있는 해당 페이지를 가져와 그 공간에 적재한다.

6️⃣페이지가 메모리에 올라오면 7️⃣페이지 테이블의 정보도 새롭게 수정된다. 이후 운영체제는 중단되었던 명령(Instruction)을 8️⃣다시 실행하여 프로세스가 계속 진행되도록 한다.

정리하면 페이지 부재 처리 흐름은 논리 주소 접근, 페이지 테이블 확인, 페이지 부재 발생, 운영체제 개입, 페이지 적재, 페이지 테이블 수정, 명령 재실행의 순서로 이해할 수 있다.

요구 페이징(Demand Paging)의 동작과 핵심 결과

요구 페이징(Demand Paging)에서는 프로그램(Program)이 특정 페이지(Page)에 접근할 때마다 해당 페이지가 메모리(Memory)에 있는지 확인한다. 페이지가 이미 메모리에 있다면 프로그램 실행은 바로 이어진다.

반대로 해당 페이지가 메모리에 없다면 페이지 부재(Page Fault)가 발생한다. 이 경우 운영체제(Operating System)는 저장장치(Storage)에서 필요한 페이지를 가져와 메모리에 적재하고, 중단되었던 명령(Instruction)을 다시 실행한다.

이 과정이 반복되면서 실제로 필요한 페이지들만 메모리에 유지된다. 따라서 프로그램 전체를 한 번에 메모리에 올리지 않아도 실행할 수 있고, 메모리 낭비를 줄일 수 있다.

즉, 요구 페이징은 필요한 부분만 메모리에 유지하면서도 프로그램 실행이 계속 이어지도록 해주는 가상메모리(Virtual Memory)의 핵심 동작 방식이다.

지금까지는 가상메모리의 개념, 요구 페이징의 동작 방식, 그리고 페이지 부재가 발생하고 처리되는 과정을 살펴보았다.

2️⃣ Page Replacement Algorithms and Thrashing

페이지 대치(Page Replacement)의 필요성

이번에는 메모리에 올라온 페이지(Page)를 어떤 기준으로 교체할지 결정하는 페이지 대치 알고리즘(Page Replacement Algorithm)과 스레싱(Thrashing) 현상에 대해 살펴본다.

요구 페이징(Demand Paging)에서는 프로그램 실행 중 필요한 페이지를 계속 메모리(Memory)로 가져온다. 하지만 여기서 문제가 발생한다. 메모리에 올릴 수 있는 페이지의 개수, 즉 프레임(Frame)의 수는 물리 메모리(Physical Memory)의 크기에 의해 결정되기 때문에 무한히 늘릴 수 없다.

따라서 메모리에 항상 여유 공간이 있는 것은 아니다. 이미 대부분의 공간이 사용 중인 상태에서 새로운 페이지를 메모리에 올려야 하는 상황이 자주 발생할 수 있다.

이때 새로운 페이지를 적재하려면, 기존에 메모리에 올라와 있던 페이지 중 하나를 제거해야 한다. 즉, 어떤 페이지를 내보내고 어떤 페이지를 계속 유지할 것인지 선택해야 하는 문제가 생긴다.

이처럼 제한된 메모리 공간에서 새로운 페이지를 적재하기 위해 기존 페이지를 교체해야 하며, 이때 필요한 기준이 바로 페이지 대치 알고리즘이다.

페이지 대치(Page Replacement)의 필요성 그림

이 그림은 새로운 페이지(Page)를 메모리(Memory)에 올려야 할 때, 왜 페이지 대치(Page Replacement)가 필요한지를 보여준다.

현재 물리 메모리(Physical Memory)에는 여러 페이지가 이미 적재되어 있다. 각 사용자 또는 프로세스(Process)는 자신만의 논리 주소 공간(Logical Address Space)과 페이지 테이블(Page Table)을 가지고 있으며, 페이지 테이블을 통해 어떤 페이지가 메모리에 올라와 있는지 확인할 수 있다.

예를 들어 특정 프로세스가 load M 명령을 실행한다고 하면, 이는 M 페이지에 있는 데이터를 사용하려는 동작이다. 그런데 페이지 테이블을 확인했을 때 M 페이지에 프레임 번호(Frame Number)가 없고 비타당 상태(Invalid State)로 표시되어 있다면, 현재 메모리에 없는 페이지라는 의미가 된다.

이 경우 M 페이지가 필요해졌기 때문에 페이지 부재(Page Fault)가 발생한다. 운영체제(Operating System)는 M 페이지를 보조기억장치(Secondary Storage)에서 가져와 물리 메모리에 적재해야 한다.

하지만 물리 메모리에 빈 프레임(Free Frame)이 없다면, 이미 메모리에 올라와 있는 페이지 중 하나를 제거해야 한다. 그리고 그 자리에 새로 필요한 M 페이지를 올리게 된다.

즉, 이 그림은 각 프로세스가 논리 주소 공간과 페이지 테이블을 따로 가지고 있어도, 실제 물리 메모리는 공유되기 때문에 새로운 페이지를 올리기 위해 기존 페이지를 교체해야 하는 상황이 발생한다는 것을 보여준다. 이때 어떤 페이지를 내보낼지 결정하는 기준이 페이지 대치 알고리즘(Page Replacement Algorithm)이다.

페이지 대치(Page Replacement)의 개념

페이지 대치(Page Replacement)는 메모리에 빈 공간이 없을 때, 새로운 페이지(Page)를 올리기 위해 기존 페이지 중 하나를 제거하고 그 자리에 필요한 페이지를 적재하는 과정이다.

새로운 페이지를 메모리(Memory)에 올려야 하는데 빈 프레임(Free Frame)이 없다면, 운영체제(Operating System)는 현재 메모리에 있는 페이지 중 하나를 선택해야 한다. 이때 선택되어 메모리에서 제거되는 페이지를 희생 페이지(Victim Page)라고 한다.

희생 페이지는 메모리에서 제거되고, 필요한 경우 저장장치(Storage)로 이동한다. 그 다음 운영체제는 보조기억장치(Secondary Storage)에서 새로 필요한 페이지를 읽어와 메모리에 적재한다.

마지막으로 페이지 테이블(Page Table)을 갱신하여 새 페이지가 어느 프레임(Frame)에 들어갔는지 반영한다. 즉, 페이지 대치는 기존 페이지를 하나 내보내고, 새로운 페이지를 그 자리에 올린 뒤, 변경된 상태를 페이지 테이블에 기록하는 과정이라고 이해할 수 있다.

페이지 대치(Page Replacement) 개념 그림

이 그림은 페이지 대치(Page Replacement)가 실제로 어떤 흐름으로 이루어지는지를 보여준다. 메모리(Memory)에 빈 공간이 없는 상태에서 새로운 페이지(Page)를 올려야 한다면, 먼저 현재 메모리에 있는 페이지 중 하나를 희생 페이지(Victim Page)로 선택해야 한다.

1번 과정에서는 기존 페이지 중 하나가 희생 페이지로 선택되어 메모리 밖으로 나간다. 이때 어떤 페이지가 선택되는지는 고정되어 있지 않고, 페이지 대치 알고리즘(Page Replacement Algorithm)에 따라 달라진다. 예를 들어 M 페이지가 희생 페이지로 선택되었다면, M 페이지는 메모리에서 제거되어 저장장치(Storage)로 이동한다.

2번 과정에서는 M 페이지가 더 이상 메모리에 없다는 사실을 반영하기 위해 페이지 테이블(Page Table)의 상태가 변경된다. 즉, 해당 페이지의 정보가 비타당 상태(Invalid State)로 수정된다.

3번 과정에서는 현재 필요한 페이지를 저장장치에서 읽어와 메모리로 가져온다. 예를 들어 A 페이지가 필요하다면, 앞에서 비워진 프레임(Frame)에 A 페이지가 적재된다.

마지막 4번 과정에서는 새로 올라온 A 페이지의 위치가 반영되도록 페이지 테이블이 갱신된다. 즉, A 페이지가 어느 프레임에 들어갔는지 기록하고, 해당 페이지를 타당 상태(Valid State)로 변경한다.

결국 페이지 대치는 기존 페이지를 하나 내보내고, 그 자리에 새로운 페이지를 올린 뒤, 변경된 내용을 페이지 테이블에 반영하는 과정이라고 이해할 수 있겠다.

페이지 대치 알고리즘(Page Replacement Algorithm)의 목표

페이지 대치(Page Replacement)가 필요한 상황을 이해했다면, 다음으로 중요한 질문은 어떤 페이지(Page)를 선택해서 내보낼 것인가이다. 어떤 페이지를 희생 페이지(Victim Page)로 선택하느냐에 따라 전체 시스템 성능이 크게 달라질 수 있다.

페이지 대치 알고리즘(Page Replacement Algorithm)은 기본적으로 페이지 부재(Page Fault)가 발생하는 횟수를 줄이는 것을 목표로 한다. 페이지 부재가 자주 발생하면 운영체제(Operating System)가 저장장치(Storage)에서 페이지를 다시 가져와야 하므로 실행 속도가 느려질 수 있다.

특히 이미 제거했던 페이지가 곧바로 다시 필요해지는 상황이 반복되면 불필요한 페이지 교체가 계속 발생한다. 이런 경우 메모리(Memory)는 계속 페이지를 넣고 빼는 데 사용되고, 실제 프로그램 실행 효율은 떨어지게 된다.

따라서 페이지 대치 알고리즘의 핵심은 가능하면 당장 필요하지 않을 페이지를 선택해 내보내는 것이다. 결국 어떤 기준으로 페이지를 선택하느냐에 따라 알고리즘의 성능 차이가 발생하게 된다.

페이지 대치 알고리즘(Page Replacement Algorithm): 프레임 수(Frame Count)와 페이지 부재(Page Fault)

페이지 대치 알고리즘(Page Replacement Algorithm)을 이해하려면 먼저 프레임(Frame)의 개념을 살펴볼 필요가 있다. 메모리(Memory)의 프레임 수는 동시에 메모리에 올려둘 수 있는 페이지(Page)의 개수를 의미한다. 즉, 프레임이 많을수록 프로그램(Program)이 사용하는 데이터를 더 많이 메모리에 유지할 수 있다.

프로그램이 실행될 때 페이지들은 일정한 순서로 계속 참조된다. 이러한 페이지 접근 순서를 참조 문자열(Reference String)이라고 한다. 프로그램은 이 참조 문자열을 따라가며 필요한 페이지를 하나씩 요청하게 된다.

프레임 수가 많아지면 한 번 메모리에 가져온 페이지를 더 오래 유지할 수 있다. 따라서 같은 페이지를 다시 요청했을 때, 그 페이지가 아직 메모리에 남아 있을 가능성이 높아진다. 그 결과 페이지 부재(Page Fault)가 줄어들 수 있다.

반대로 프레임 수가 적으면 메모리에 유지할 수 있는 페이지 수가 제한된다. 이 경우 새로운 페이지를 가져오기 위해 기존 페이지를 더 자주 교체해야 하고, 이미 내보낸 페이지가 다시 필요해지는 상황도 발생할 수 있다.

결국 프레임 수는 페이지 부재의 발생 빈도와 직접적으로 관련이 있다. 프레임이 많을수록 페이지를 더 많이 유지할 수 있어 페이지 부재가 줄어들 가능성이 높고, 프레임이 적을수록 페이지 교체가 자주 발생하게 된다.

프레임 수(Frame Count)와 페이지 부재(Page Fault)

프레임(Frame)은 메모리(Memory)에 페이지(Page)를 올려둘 수 있는 공간을 의미한다. 따라서 프레임 수가 많다는 것은 동시에 더 많은 페이지를 메모리에 유지할 수 있다는 뜻이다.

그래서 일반적인 경우엔 프레임수가 증가할수록 '페이지부재' 횟수는 감소하는 경향을 보이게 된다. 참조 문자열에따라 실행하는 과정에서 이미 사용했던 페이지가 메모리에 계속 남아있게되면서 다시 가져와야하는 상황이 줄어들기 때문이다.

결국 메모리에 더 많은 페이지를 유지할 수 있을수록 저장장치(Storage)에서 데이터를 다시 읽어오는 횟수가 줄어들고, 그 결과 페이지 부재도 감소한다. 따라서 대부분의 경우 프레임 수가 늘어나면 프로그램 실행 성능이 좋아진다고 볼 수 있다고 이해하자.

프레임 수(Frame Count)와 페이지 부재(Page Fault)의 예

프레임 수(Frame Count)와 페이지 부재(Page Fault)의 관계를 볼 때, 항상 같은 결과가 나타나는 것은 아니라는 점을 알아둘 필요가 있다.

그림의 왼쪽에는 참조 문자열(Reference String)이 제시되어 있다. 참조 문자열은 프로그램(Program)이 실행되는 동안 페이지(Page)에 접근하는 순서를 의미한다. 이 문자열을 보면 같은 페이지가 반복해서 등장하는 것을 확인할 수 있다. 즉, 프로그램은 새로운 페이지만 계속 사용하는 것이 아니라, 이미 사용했던 페이지를 다시 참조하는 패턴을 가진다.

따라서 어떤 페이지를 메모리(Memory)에 계속 유지하느냐가 페이지 부재 횟수에 큰 영향을 준다. 이미 사용했던 페이지가 메모리에 남아 있다면 다시 접근할 때 바로 사용할 수 있지만, 메모리에서 제거된 상태라면 다시 페이지 부재가 발생하게 된다.

오른쪽 그래프는 같은 참조 문자열을 기준으로 프레임 수를 바꿔가며 실행했을 때의 결과를 보여준다. 일반적으로 프레임 수가 많아질수록 페이지 부재 횟수는 감소하는 경향이 있다. 메모리에 더 많은 페이지를 유지할 수 있기 때문에, 이미 사용했던 페이지를 다시 참조할 때 페이지 부재가 발생할 가능성이 줄어들기 때문이다.

다만 모든 경우에 프레임 수가 증가한다고 항상 페이지 부재가 줄어드는 것은 아니다. 특정 페이지 대치 알고리즘(Page Replacement Algorithm)에서는 같은 참조 문자열을 사용하더라도 예상과 다른 결과가 나타날 수 있다. 이 점은 이후 페이지 대치 알고리즘을 이해하는 데 중요한 부분이다.

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)

가장 기본적인 페이지 대치 알고리즘(Page Replacement Algorithm) 중 하나는 선입선출 방식인 FIFO(First-In, First-Out)이다.

FIFO는 이름 그대로 먼저 메모리(Memory)에 들어온 페이지(Page)를 먼저 제거하는 방식이다. 즉, 페이지가 메모리에 적재된 순서를 기준으로 가장 오래전에 들어온 페이지가 교체 대상이 된다.

이 구조는 자료구조(Data Structure)에서 배우는 큐(Queue)와 비슷하게 이해할 수 있다. 먼저 들어온 데이터가 앞쪽에 위치하고, 새로운 페이지가 들어와야 할 때는 가장 앞에 있는 페이지가 제거된다.

FIFO는 적재된 순서만 관리하면 되기 때문에 구현이 매우 단순하다. 따라서 이해하기 쉽고 구현하기 쉬운 페이지 대치 알고리즘이라고 볼 수 있다.

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)의 한계

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)은 구조가 단순하다는 장점이 있지만, 한계도 분명하다.

가장 큰 한계는 페이지(Page)가 실제로 사용되고 있는지와 관계없이, 단순히 메모리(Memory)에 들어온 순서만을 기준으로 제거 대상이 결정된다는 점이다. 즉, 가장 오래전에 들어온 페이지가 현재도 계속 사용되고 있는 중요한 페이지일 수 있는데도 교체 대상이 될 수 있다.

또한 FIFO는 페이지가 과거에 언제 들어왔는지만 고려할 뿐, 앞으로 다시 사용될 가능성은 반영하지 못한다. 따라서 실제 프로그램(Program)의 사용 패턴을 충분히 고려하지 못하고, 비효율적인 페이지 교체(Page Replacement)가 발생할 수 있다.

결국 FIFO는 구현이 쉽고 이해하기 쉬운 방식이지만, 페이지의 실제 사용 빈도나 중요도를 반영하지 못한다는 한계를 가진다.

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)의 동작 과정

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)은 메모리에 먼저 들어온 페이지(Page)를 먼저 제거하는 방식이다. 이 과정은 큐(Queue)의 앞쪽에 있는 페이지를 제거하고, 새로 들어온 페이지를 뒤쪽에 추가하는 흐름으로 동작한다.

1️⃣ 먼저 FIFO 큐(Queue)의 헤드(Head)에 있는 페이지가 제거 대상, 즉 희생 페이지(Victim Page)로 선택된다. 이 페이지는 가장 먼저 메모리(Memory)에 들어온 페이지이므로 교체 대상이 된다.

2️⃣ 그다음 선택된 희생 페이지는 메모리에서 제거되어 저장장치(Storage)로 이동한다. 이 과정을 스왑 아웃(Swap Out)이라고 한다. 페이지가 메모리에서 나갔기 때문에, 해당 페이지에 대한 페이지 테이블(Page Table)의 정보도 갱신된다.

3️⃣ 이때 타당 비트(Valid Bit)는 0으로 변경되어 비타당 상태(Invalid State)가 된다.

4️⃣ 이후 새로 필요한 페이지를 저장장치에서 가져와 메모리에 적재한다. 이 과정을 스왑 인(Swap In)이라고 한다.

5️⃣ 새 페이지가 메모리에 올라오면 페이지 테이블도 다시 갱신된다. 새 페이지가 어느 프레임(Frame)에 들어갔는지 기록하고, 타당 비트를 1로 변경하여 타당 상태(Valid State)로 표시한다.

6️⃣ 마지막으로 새로 적재된 페이지는 FIFO 큐의 뒤쪽에 추가된다. 이렇게 하면 메모리에 들어온 순서가 다시 정리되고, 다음에 페이지 교체가 필요할 때는 다시 큐의 앞쪽에 있는 페이지가 제거 대상이 된다.

즉, FIFO 방식은 기존 페이지를 스왑 아웃(Swap Out)하고, 새로운 페이지를 스왑 인(Swap In)한 뒤, 새 페이지를 큐의 뒤쪽에 추가하는 과정을 반복하는 페이지 대치 방식이다.

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm) 예시

그림의 위쪽에는 하나의 참조 문자열(Reference String)이 주어져 있다. 참조 문자열은 프로그램(Program)이 실행되는 동안 페이지(Page)를 요청하는 순서를 의미한다. 예를 들어 페이지가 1, 2, 3, 2, 1, 5, 2, 1, 6과 같은 순서로 요청되면, 프로그램은 이 순서에 따라 필요한 페이지에 접근하게 된다.

이때 프로그램이 어떤 페이지를 사용하려고 했는데, 해당 페이지가 현재 메모리(Memory)에 없다면 페이지 부재(Page Fault)가 발생한다.

그림에서는 프레임(Frame) 수가 3개일 때 FIFO(First-In, First-Out) 방식으로 페이지가 어떻게 적재되고 교체되는지를 보여준다. 처음 1이 요청되면 메모리가 비어 있으므로 첫 번째 프레임에 적재되고 페이지 부재가 발생한다. 이후 2와 3도 아직 메모리에 없기 때문에 각각 페이지 부재가 발생하며 프레임이 채워진다.

그다음 2와 1처럼 이미 메모리에 있는 페이지가 다시 요청되면 페이지 부재 없이 그대로 사용된다. 하지만 5처럼 메모리에 없는 새로운 페이지가 요청되면 다시 페이지 부재가 발생한다. 이때 빈 프레임이 없으므로 FIFO 규칙에 따라 가장 먼저 들어온 페이지인 1이 제거되고, 그 자리에 5가 적재된다.

이러한 과정을 참조 문자열의 끝까지 반복하면, FIFO 방식에서는 먼저 들어온 페이지를 기준으로 계속 교체가 이루어진다. 따라서 페이지가 실제로 자주 사용되는지와 관계없이, 가장 오래전에 적재된 페이지가 제거될 수 있다.

단, 녹취록에 나온 예시 참조 문자열이 1, 2, 3, 2, 1, 5, 2, 1, 6만을 의미한다면 페이지 요청 횟수가 9번이므로 페이지 부재가 14번 발생할 수는 없다. 14번의 페이지 부재는 그림에 표시된 더 긴 전체 참조 문자열을 기준으로 한 결과로 보는 것이 자연스럽다.

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)의 문제점

선입선출 페이지 대치 알고리즘(FIFO Page Replacement Algorithm)은 단순히 먼저 들어온 페이지(Page)를 먼저 제거하는 방식이다. 하지만 이 방식은 메모리(Memory)를 더 많이 할당해도 항상 성능이 좋아지는 것은 아니라는 한계를 가진다.

그림의 왼쪽에는 하나의 참조 문자열(Reference String)이 주어져 있고, 이를 기준으로 프레임(Frame)을 3개 사용했을 때와 4개 사용했을 때의 결과가 비교되어 있다. 일반적으로는 프레임 수가 늘어나면 더 많은 페이지를 메모리에 유지할 수 있으므로 페이지 부재(Page Fault)가 줄어드는 것이 자연스럽다.

하지만 이 예시에서는 프레임이 3개일 때 페이지 부재가 9번 발생했고, 프레임을 4개로 늘렸을 때는 오히려 페이지 부재가 10번으로 증가하였다. 즉, 메모리를 더 많이 할당했음에도 페이지 부재가 더 많이 발생한 것이다.

이러한 현상을 벨라디의 이상 현상(Belady’s Anomaly)이라고 한다. 이는 FIFO와 같은 일부 페이지 대치 알고리즘에서 나타날 수 있는 문제로, 프레임 수를 늘렸는데도 페이지 부재 횟수가 오히려 증가하는 현상을 의미한다.

결국 FIFO는 구현이 쉽고 단순하지만, 실제 페이지 사용 패턴을 고려하지 않기 때문에 메모리를 더 많이 사용해도 성능이 나빠질 수 있다는 한계를 가진다.

최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)

최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)은 앞으로 가장 오랫동안 사용되지 않을 페이지(Page)를 선택해서 제거하는 방식이다. 즉, 과거에 언제 사용되었는지가 아니라 앞으로 언제 다시 사용될지를 기준으로 희생 페이지(Victim Page)를 결정한다.

이 방식에서는 가장 나중에 다시 사용될 페이지, 또는 앞으로 사용되지 않을 페이지를 제거한다. 이렇게 하면 불필요한 페이지 교체(Page Replacement)를 최소화할 수 있기 때문에 페이지 부재(Page Fault) 횟수를 가장 적게 만들 수 있다.

다만 이 알고리즘은 앞으로의 페이지 참조 순서, 즉 미래의 참조 정보(Future Reference Information)를 알고 있다는 가정이 필요하다. 실제 실행 중에는 미래에 어떤 페이지가 사용될지 정확히 알 수 없기 때문에 현실적으로 구현하기는 어렵다.

따라서 최적 페이지 대치 알고리즘은 실제 운영체제(Operating System)에서 그대로 사용되기보다는, 다른 페이지 대치 알고리즘의 성능을 비교하는 기준으로 사용된다. 즉, 가장 이상적인 성능을 보이는 기준 알고리즘(Benchmark Algorithm)이라고 이해할 수 있다.

최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)의 한계

최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)은 앞으로 어떤 페이지(Page)가 언제 다시 사용될지를 미리 알고 있어야 한다. 하지만 실제 시스템에서는 프로그램(Program)의 미래 참조(Future Reference)를 정확히 알 수 없다.

따라서 이 알고리즘을 실제 운영체제(Operating System)에서 그대로 구현하는 것은 불가능하다. 실행 중인 프로그램이 앞으로 어떤 순서로 페이지에 접근할지 미리 예측할 수 없기 때문이다.

그래서 최적 페이지 대치 알고리즘은 실제로 사용하는 방식이라기보다 이론적인 기준(Theoretical Standard)으로 활용된다. 다른 페이지 대치 알고리즘(Page Replacement Algorithm)이 얼마나 효율적으로 동작하는지 평가할 때, 이론적으로 가장 좋은 경우와 비교하는 기준으로 사용된다.

즉, 최적 페이지 대치 알고리즘은 현실적으로 구현하기는 어렵지만, 페이지 부재(Page Fault)를 최소화할 수 있는 이상적인 알고리즘으로서 성능 비교의 기준이 된다.

최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)의 동작 과정

최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)은 앞으로 가장 오랫동안 사용되지 않을 페이지(Page)를 선택해 교체하는 방식이다. 같은 참조 문자열(Reference String)이 주어지고 프레임(Frame)이 3개라고 할 때, 참조 문자열의 흐름을 보면서 어떤 페이지를 제거할지 결정한다.

처음에는 1, 2, 3 페이지가 차례대로 요청되어 프레임이 채워지고, 이 과정에서 페이지 부재(Page Fault)가 발생한다. 이후 새로운 페이지인 5가 필요해지면, 현재 메모리에 있는 1, 2, 3 중 어떤 페이지를 제거할지 선택해야 한다.

이때 최적 알고리즘은 현재 위치 이후의 참조 문자열을 확인한다. 5 다음에 2가 먼저 다시 사용되고, 그다음 1이 다시 사용되며, 3은 그보다 더 나중에 사용된다면 3이 교체 대상이 된다. 즉, 현재 메모리에 있는 페이지 중 앞으로 가장 늦게 다시 사용될 페이지를 제거하는 것이다.

이 방식은 단순히 먼저 들어온 페이지를 제거하는 것이 아니라, 앞으로의 참조 순서를 기준으로 가장 효율적인 선택을 한다. 따라서 불필요한 페이지 교체를 최소화할 수 있고, 전체 페이지 부재 횟수도 줄어든다.

이 예제에서는 최적 페이지 대치 알고리즘을 적용했을 때 총 페이지 부재 횟수가 9회로 나타난다. 이는 앞에서 살펴본 FIFO(First-In, First-Out) 방식보다 더 적은 결과이다. 결국 최적 페이지 대치 알고리즘은 미래의 참조 정보를 알고 있다는 가정하에서 페이지 부재를 최소화하는 이론적으로 가장 효율적인 알고리즘이다.

LRU 페이지 대치 알고리즘(LRU Page Replacement Algorithm)

LRU(Least Recently Used) 페이지 대치 알고리즘은 가장 오랫동안 사용되지 않은 페이지(Page)를 선택해서 제거하는 방식이다. 앞으로 어떤 페이지가 사용될지 정확히 알 수 없기 때문에, 대신 과거의 사용 이력(Usage History)을 기준으로 판단한다.

이 알고리즘은 최근에 사용된 페이지는 다시 사용될 가능성이 높고, 오랫동안 사용되지 않은 페이지는 앞으로도 사용되지 않을 가능성이 높다고 가정한다. 따라서 메모리(Memory)에 있는 페이지 중 가장 오래 사용되지 않은 페이지를 희생 페이지(Victim Page)로 선택한다.

LRU는 미래의 참조 정보를 알 수 없다는 현실적인 한계를 고려하여, 과거의 참조 기록을 바탕으로 최적 페이지 대치 알고리즘(Optimal Page Replacement Algorithm)에 가까운 선택을 하려는 방식이다.

즉, LRU는 실제 사용 패턴을 어느 정도 반영할 수 있기 때문에 FIFO(First-In, First-Out)보다 효율적인 결과를 기대할 수 있는 대표적인 페이지 대치 알고리즘이다.

LRU 페이지 대치 알고리즘(LRU Page Replacement Algorithm)의 특징

LRU(Least Recently Used) 페이지 대치 알고리즘은 최근에 사용된 페이지(Page)는 다시 사용될 가능성이 높다는 가정을 바탕으로 동작한다. 따라서 각 페이지가 마지막으로 사용된 시점을 기준으로, 가장 오랫동안 사용되지 않은 페이지를 교체 대상으로 선택한다.

이 방식은 과거의 사용 이력(Usage History)을 반영하기 때문에 FIFO(First-In, First-Out)보다 더 합리적인 선택이 가능하다. 단순히 먼저 들어온 페이지를 제거하는 것이 아니라, 실제로 최근에 사용되었는지를 고려하기 때문이다.

하지만 LRU가 동작하려면 각 페이지가 언제 사용되었는지를 기록해야 한다. 예를 들어 페이지 사용 시간(Use Time)을 저장하거나, 스택(Stack)과 같은 구조를 이용해 사용 순서(Use Order)를 관리할 수 있다.

즉, LRU는 페이지 사용 패턴을 반영할 수 있어 효율적인 페이지 대치가 가능하지만, 이를 구현하기 위해 추가적인 정보 관리 비용(Management Cost)이 필요하다는 특징이 있다.

LRU 페이지 대치 알고리즘(LRU Page Replacement Algorithm)의 동작 흐름

LRU(Least Recently Used) 페이지 대치 알고리즘은 가장 오랫동안 사용되지 않은 페이지(Page)를 교체 대상으로 선택하는 방식이다. 참조 문자열(Reference String)이 주어지고 프레임(Frame)이 3개일 때, 페이지 요청 순서에 따라 메모리 상태가 계속 갱신된다.

처음 1, 2, 3 페이지가 차례대로 들어올 때는 메모리가 비어 있는 상태이기 때문에 각각 페이지 부재(Page Fault)가 발생하고, 프레임이 하나씩 채워진다.

이후 2가 다시 요청되면 이미 메모리에 있기 때문에 페이지 교체는 발생하지 않는다. 대신 2는 가장 최근에 사용된 페이지로 갱신된다. 그다음 1이 요청될 때도 마찬가지로 교체 없이 사용되며, 이번에는 1이 가장 최근에 사용된 페이지가 된다.

이 상태에서 5가 요청되면 메모리가 이미 가득 차 있기 때문에 기존 페이지 중 하나를 제거해야 한다. LRU에서는 가장 오래 사용되지 않은 페이지를 선택한다. 이때 3은 처음 들어온 이후로 다시 사용되지 않았고, 1과 2는 최근에 사용되었기 때문에 3이 제거된다. 그 자리에 5가 새로 적재된다.

이후에도 페이지가 요청될 때마다 최근 사용 시점을 기준으로 가장 오래 사용되지 않은 페이지를 교체한다. 이 과정을 끝까지 반복하면 예제에서는 총 11회의 페이지 부재가 발생한다.

즉, LRU의 핵심은 단순히 메모리에 들어온 순서가 아니라 실제 사용 이력(Usage History)을 기준으로 교체 대상을 결정한다는 점이다.

전역 대치(Global Replacement), 지역 대치(Local Replacement)

페이지 대치(Page Replacement)에서 중요한 문제 중 하나는 교체 대상을 어느 범위까지 볼 것인가이다. 즉, 특정 프로세스(Process) 내부에서만 희생 페이지(Victim Page)를 선택할 것인지, 아니면 메모리(Memory)에 올라와 있는 모든 프로세스의 페이지를 대상으로 선택할 것인지에 따라 동작 방식이 달라진다.

이 기준에 따라 페이지 대치는 전역 대치(Global Replacement)와 지역 대치(Local Replacement)로 나눌 수 있다.

전역 대치(Global Replacement)는 희생 페이지를 선택할 때 메모리에 있는 모든 프로세스의 프레임(Frame)을 대상으로 하는 방식이다. 따라서 한 프로세스가 새로운 페이지(Page)를 필요로 할 때, 다른 프로세스가 사용 중인 프레임을 가져올 수도 있다. 이 방식은 시스템 전체 관점에서는 메모리를 효율적으로 사용할 수 있지만, 특정 프로세스 입장에서는 자신에게 할당된 프레임을 빼앗길 수 있기 때문에 성능이 불안정해질 수 있다.

반면 지역 대치(Local Replacement)는 각 프로세스가 자신에게 할당받은 프레임 안에서만 페이지 교체를 수행하는 방식이다. 다른 프로세스의 프레임에는 영향을 주지 않기 때문에 각 프로세스의 실행은 비교적 안정적으로 유지될 수 있다. 하지만 전체 메모리를 유연하게 활용하기는 어렵기 때문에, 시스템 전체 관점에서는 효율이 떨어질 수 있다.

결국 전역 대치와 지역 대치는 메모리 효율성과 프로세스 안정성 사이의 차이를 보여준다. 전역 대치는 전체 메모리 활용에는 유리하지만 개별 프로세스 성능이 흔들릴 수 있고, 지역 대치는 개별 프로세스의 안정성은 높지만 전체 메모리 활용 효율은 낮아질 수 있다.

페이지 버퍼링 알고리즘(Page Buffering Algorithm)

지금까지는 어떤 페이지(Page)를 선택해서 교체할지, 즉 페이지 대치 알고리즘(Page Replacement Algorithm)에 대해 살펴보았다. 하지만 페이지 부재(Page Fault)가 발생했을 때는 어떤 페이지를 교체할지도 중요하지만, 실제 성능에는 디스크 입출력(Disk I/O) 시간이 큰 영향을 준다.

페이지 부재가 발생하면 필요한 페이지를 보조기억장치(Secondary Storage)에서 메모리(Memory)로 가져와야 한다. 이 과정에서 가장 큰 지연은 디스크에서 데이터를 읽어오는 시간 때문에 발생한다. 따라서 무엇을 교체할 것인가뿐만 아니라, 페이지 부재를 얼마나 빠르게 처리할 것인가도 중요하다.

이러한 지연을 줄이기 위해 사용하는 기법이 페이지 버퍼링(Page Buffering)이다. 페이지 버퍼링은 페이지 부재가 발생했을 때 바로 사용할 수 있는 여유 프레임(Free Frame)을 미리 확보해두거나, 제거된 페이지를 버퍼(Buffer)에 잠시 유지해두는 방식이다.

이렇게 하면 새로운 페이지가 필요할 때 바로 적재할 수 있는 공간이 준비되어 있기 때문에 처리 지연을 줄일 수 있다. 또한 경우에 따라 제거된 페이지가 다시 필요해지면 디스크에서 다시 읽어오지 않고 버퍼에 남아 있는 페이지를 재사용할 수도 있다.

결국 페이지 버퍼링은 디스크 입출력 지연을 줄이기 위해 미리 공간을 준비하고, 제거된 페이지를 잠시 보관하여 페이지 부재 처리 시간을 줄이는 기법이라고 이해할 수 있겠다.

스래싱(Thrashing)

페이지 대치 알고리즘(Page Replacement Algorithm)과 페이지 버퍼링(Page Buffering)을 통해 가상메모리(Virtual Memory)의 성능을 어느 정도 개선할 수 있다. 하지만 메모리(Memory)가 부족하거나 실행 중인 프로세스(Process)가 지나치게 많아지면 이러한 기법만으로는 성능을 유지하기 어렵다.

이처럼 페이지 부재(Page Fault)가 과도하게 발생하는 현상을 스래싱(Thrashing)이라고 한다. 정상적인 경우에는 페이지 교체(Page Replacement)가 발생하더라도 프로그램 실행이 계속 이어진다. 하지만 스래싱 상태에서는 페이지를 메모리로 가져오고 다시 내보내는 작업이 반복되면서, 실제 프로그램 실행은 거의 이루어지지 않는다.

이 경우 CPU(Central Processing Unit)는 대부분의 시간을 작업이 끝나기를 기다리는 데 사용하고, 디스크(Disk)는 계속해서 페이지를 읽고 쓰는 작업만 수행하게 된다. 결국 시스템 전체가 실제 실행보다 페이지 교체에 대부분의 시간을 사용하는 비효율적인 상태에 빠지게 된다.

따라서 스래싱은 단순히 페이지 부재가 많이 발생하는 문제가 아니라, 메모리 부족으로 인해 시스템 성능 전체가 크게 저하되는 현상이라고 이해할 수 있다.

스레싱(Thrashing) 발생 원인

스레싱(Thrashing)의 발생 원인은 결국 메모리 부족(Memory Shortage)과 관련이 있다. 프로세스(Process)에 할당된 프레임(Frame) 수가 부족하면, 프로세스가 필요로 하는 페이지(Page)를 메모리에 충분히 유지할 수 없다. 이 경우 필요한 페이지가 메모리에 없어서 페이지 부재(Page Fault)가 계속 발생하게 된다.

또한 동시에 실행되는 프로세스의 수가 너무 많아져도 스레싱이 발생할 수 있다. 실행 중인 프로세스가 많아지면 각 프로세스에 할당될 수 있는 메모리의 양이 줄어들고, 그 결과 각 프로세스가 필요한 페이지를 충분히 유지하지 못하게 된다.

이때 중요한 개념이 워킹 셋(Working Set)이다. 워킹 셋은 프로세스가 일정 시간 동안 실제로 자주 사용하는 페이지들의 집합을 의미한다. 프로세스가 원활하게 실행되려면 이 워킹 셋을 메모리에 유지할 수 있어야 한다.

하지만 워킹 셋을 유지할 만큼의 메모리가 확보되지 않으면, 필요한 페이지를 계속 가져오고 다시 내보내는 상황이 반복된다. 이로 인해 페이지 부재가 과도하게 발생하고, 결국 스레싱 상태에 빠지게 된다.

즉, 스레싱의 핵심 원인은 프로세스가 자주 사용하는 페이지 집합인 워킹 셋을 메모리에 유지할 만큼 충분한 프레임이 확보되지 않는 데 있다.

스래싱(Thrashing) 동작 과정

스래싱(Thrashing)이 발생하면 페이지 교체(Page Replacement)가 반복되는 악순환 구조로 이어진다.

먼저 프로그램(Program) 실행 중 페이지 부재(Page Fault)가 계속 증가하기 시작한다. 필요한 페이지(Page)가 메모리(Memory)에 없기 때문에 운영체제(Operating System)는 새로운 페이지를 메모리에 올려야 한다.

그런데 메모리에 여유 공간이 부족하면, 새로운 페이지를 올리기 위해 기존에 있던 페이지 중 하나를 제거해야 한다. 문제는 이렇게 제거된 페이지가 얼마 지나지 않아 다시 필요해질 수 있다는 점이다.

그러면 운영체제는 다시 그 페이지를 가져오기 위해 또 다른 페이지를 제거하게 된다. 이 과정이 반복되면 메모리는 계속 페이지를 가져오고 내보내는 작업에 사용되고, 실제 프로그램 실행은 거의 이루어지지 않게 된다.

즉, 스래싱은 페이지 부재 증가, 기존 페이지 제거, 제거된 페이지의 재요청, 또 다른 페이지 제거가 반복되면서 실행보다 페이지 교체가 더 많이 발생하는 상태라고 이해할 수 있다.

스래싱(Thrashing)과 워킹 셋(Working Set)

스래싱(Thrashing)의 동작 과정을 이해하기 위해서는 워킹 셋(Working Set)의 개념을 함께 살펴볼 필요가 있다. 워킹 셋은 프로세스(Process)가 일정 시간 동안 실제로 자주 사용하는 페이지(Page)들의 집합을 의미한다.

그림에서는 프로그램이 실행되면서 페이지 참조열(Page Reference String)을 따라 여러 페이지를 순서대로 참조하는 모습을 보여준다. 이때 특정 시점을 기준으로 바로 이전의 일정 구간, 즉 델타(Delta)만큼의 범위 안에서 최근에 사용된 페이지들을 모아 워킹 셋을 구한다.

예를 들어 t1 시점에서 왼쪽으로 델타=10 범위를 보면, 이 구간 안에서 참조된 페이지는 2, 1, 5, 7이다. 따라서 이때의 워킹 셋은 [2, 1, 5, 7]이 된다.

t2 시점에서도 같은 방식으로 왼쪽의 델타=10 범위를 확인한다. 이 구간에서는 7, 5, 1, 3, 4가 참조되었으므로, t2 시점의 워킹 셋은 [7, 5, 1, 3, 4]가 된다.

t3 시점에서는 최근에 참조된 페이지가 3, 4로 줄어든다. 따라서 이때의 워킹 셋은 [3, 4]가 된다.

이 그림이 보여주는 핵심은 워킹 셋이 고정된 하나의 집합이 아니라는 점이다. 프로그램이 실행되는 시점에 따라 최근에 자주 참조되는 페이지의 묶음은 계속 달라진다. 따라서 운영체제(Operating System)는 각 시점의 워킹 셋을 메모리(Memory)에 유지할 수 있도록 관리해야 한다.

만약 워킹 셋을 충분히 메모리에 유지하지 못하면, 방금까지 필요했던 페이지를 계속 내보내고 다시 가져오는 일이 반복된다. 이런 상황이 심해지면 페이지 교체(Page Replacement)가 실제 실행보다 더 많이 발생하게 되고, 결국 스래싱으로 이어질 수 있다.

또한 델타의 크기도 중요하다. 델타가 너무 작으면 실제로 필요한 페이지들을 충분히 포함하지 못할 수 있다. 반대로 델타가 너무 크면 현재는 자주 사용하지 않는 페이지까지 포함하게 되어 메모리를 낭비할 수 있다.

워킹 셋(Working Set)과 프레임 수(Frame Count)

이 그림은 워킹 셋(Working Set)의 크기와 프레임 수(Frame Count)에 따라 페이지 부재 비율(Page Fault Rate)이 어떻게 달라지는지를 보여준다.

가로축은 메모리(Memory)에 할당된 프레임 수를 의미하고, 세로축은 페이지 부재 비율을 의미한다. 프레임 수가 매우 적은 구간에서는 페이지 부재 비율이 매우 높게 나타난다. 이 구간은 프로세스(Process)의 워킹 셋보다 할당된 프레임 수가 적은 상태라고 볼 수 있다.

즉, 프로세스가 자주 사용하는 페이지(Page)들을 메모리에 모두 유지하지 못하기 때문에, 필요한 페이지를 계속 가져오고 다시 내보내는 상황이 반복된다. 그 결과 페이지 부재가 급격히 증가하며, 이 상태가 바로 스래싱(Thrashing)이 발생하는 구간이다.

프레임 수를 점점 늘리면 페이지 부재 비율이 급격히 떨어지는 구간이 나타난다. 이 지점은 메모리가 워킹 셋을 수용할 수 있게 되는 구간이다. 자주 사용하는 페이지들이 메모리에 유지되기 때문에 페이지 부재가 크게 감소한다.

그 이후로 프레임 수를 더 늘리면 페이지 부재 비율은 계속 줄어들 수 있지만, 감소 폭은 점점 작아진다. 이미 대부분의 워킹 셋이 메모리에 유지되고 있기 때문에 추가적인 프레임을 더 제공해도 성능 개선 효과가 크지 않기 때문이다.

따라서 핵심은 각 프로세스의 워킹 셋을 충분히 담을 수 있을 만큼의 프레임이 확보되어야 한다는 점이다. 그래야 페이지 부재를 줄이고 스래싱을 방지할 수 있다.

스래싱(Thrashing)의 영향

스래싱(Thrashing)이 발생하면 시스템 전체에 여러 가지 영향이 연쇄적으로 나타난다. 가장 먼저 페이지 부재율(Page Fault Rate)이 급격하게 증가한다. 필요한 페이지(Page)가 계속 메모리(Memory)에 없기 때문에, 운영체제(Operating System)는 반복적으로 페이지를 가져와야 한다.

이로 인해 디스크 입출력(Disk I/O)이 크게 증가한다. 페이지를 계속 읽고 쓰는 작업이 반복되면서 디스크(Disk)가 과도하게 사용되는 상태가 된다.

반대로 CPU(Central Processing Unit)는 실제 작업을 제대로 수행하지 못하고, 대부분의 시간을 디스크 작업이 끝나기를 기다리는 데 사용하게 된다. 즉, CPU는 놀고 있고 디스크만 계속 동작하는 비정상적인 상태가 되는 것이다.

이러한 상황이 계속되면 프로그램 실행보다 페이지 교체(Page Replacement)에 더 많은 시간이 사용된다. 결과적으로 시스템 전체 성능(System Performance)이 크게 저하된다.

CPU 이용률(CPU Utilization)과 다중 프로그래밍 수준(Degree of Multiprogramming)

다중 프로그래밍 수준(Degree of Multiprogramming)이 증가한다는 것은 동시에 실행되는 프로세스(Process)의 수가 많아진다는 의미이다. 초기에는 프로세스 수가 늘어날수록 CPU(Central Processing Unit)가 처리할 작업도 많아지기 때문에 CPU 이용률 (CPU Utilization)이 증가한다.

예를 들어 한 프로세스가 입출력(I/O) 작업으로 기다리는 동안, 다른 프로세스가 CPU를 사용할 수 있다. 따라서 CPU가 쉬는 시간이 줄어들고, 시스템 전체의 처리 효율이 좋아질 수 있다.

하지만 프로세스 수가 일정 수준을 넘어서면 문제가 발생한다. 동시에 실행되는 프로세스가 너무 많아지면 각 프로세스에 할당되는 메모리(Memory)의 양이 줄어든다. 그 결과 각 프로세스가 자신의 워킹 셋(Working Set)을 충분히 메모리에 유지하지 못하게 되고, 페이지 부재(Page Fault)가 증가한다.

페이지 부재가 많아지면 운영체제(Operating System)는 필요한 페이지(Page)를 디스크(Disk)에서 계속 가져와야 한다. 이 과정에서 프로세스들은 실제 실행보다 대기 시간이 길어지고, CPU는 디스크 작업이 끝나기를 기다리게 된다.

결국 다중 프로그래밍 수준이 증가하면 처음에는 CPU 이용률이 높아지지만, 일정 수준을 넘어서면 스래싱(Thrashing)이 발생하면서 CPU 이용률이 급격히 감소한다. 즉, 프로세스 수를 무조건 늘리는 것이 항상 좋은 것은 아니며, 메모리가 감당할 수 있는 수준 안에서 적절하게 조절해야 한다.

CPU 이용률(CPU Utilization)과 다중 프로그래밍 수준(Degree of Multiprogramming) 그래프

이 그래프는 다중 프로그래밍 수준(Degree of Multiprogramming)이 CPU 이용률(CPU Utilization)에 어떤 영향을 주는지를 보여준다.

초기에는 동시에 실행되는 프로세스(Process)의 수가 증가할수록 CPU가 처리할 작업도 많아지기 때문에 CPU 이용률이 증가한다. 한 프로세스가 입출력(I/O)이나 페이지 처리로 기다리는 동안 다른 프로세스가 실행될 수 있기 때문이다.

하지만 일정 수준을 넘어서면 문제가 발생한다. 프로세스 수가 너무 많아지면 각 프로세스에 할당되는 프레임(Frame) 수가 부족해지고, 워킹 셋(Working Set)을 메모리(Memory)에 충분히 유지하지 못하게 된다. 그 결과 페이지 부재(Page Fault)가 증가하고, 스래싱(Thrashing)이 발생한다.

스래싱 구간에서는 프로세스들이 실제 실행보다 페이지를 가져오고 내보내는 작업에 더 많은 시간을 사용한다. 이로 인해 디스크 입출력(Disk I/O)은 증가하지만 CPU는 대기하는 시간이 많아져 CPU 이용률이 급격히 감소한다.

즉, 다중 프로그래밍 수준이 낮을 때는 프로세스 수를 늘리는 것이 CPU 이용률을 높이는 데 도움이 된다. 하지만 너무 많이 늘리면 메모리 부족으로 인해 스래싱이 발생하고, 오히려 CPU 이용률이 떨어진다. 따라서 운영체제(Operating System)는 메모리가 감당할 수 있는 적정 수준에서 프로세스 수를 조절해야 한다.

스래싱(Thrashing) 해결 방법

스래싱(Thrashing)이 발생하면 시스템은 실제 실행보다 페이지 교체(Page Replacement)에 더 많은 시간을 사용하게 된다. 따라서 해결 방법은 메모리(Memory)에 걸리는 부담을 줄이는 방향으로 접근해야 한다.

대표적인 방법은 동시에 실행되는 프로세스(Process)의 수를 줄이는 것이다. 즉, 다중 프로그래밍 수준(Degree of Multiprogramming)을 낮추어 각 프로세스가 사용할 수 있는 메모리 공간을 늘리는 방식이다.

또 다른 방법은 일부 프로세스를 일시적으로 중단하거나 제거하여, 남아 있는 프로세스들에게 더 많은 프레임(Frame)을 확보해주는 것이다. 이렇게 하면 각 프로세스가 자신의 워킹 셋(Working Set)을 메모리에 유지할 가능성이 높아지고, 페이지 부재(Page Fault)의 발생도 줄어들 수 있다.

결국 스래싱을 해결하려면 너무 많은 프로세스가 제한된 메모리를 나누어 쓰는 상황을 완화해야 한다. 각 프로세스가 필요한 페이지들을 충분히 유지할 수 있도록 프레임을 확보해주는 것이 핵심이다.

스래싱(Thrashing) 방지 기법

스래싱(Thrashing)을 근본적으로 방지하기 위해서는 각 프로세스(Process)가 실행에 필요한 만큼의 메모리(Memory)를 유지할 수 있도록 관리하는 것이 중요하다. 즉, 프로세스가 자주 사용하는 페이지(Page)를 충분히 메모리에 올려둘 수 있어야 한다.

대표적인 방법은 워킹 셋 모델(Working Set Model)이다. 워킹 셋 모델은 각 프로세스가 일정 시간 동안 자주 사용하는 페이지들의 집합, 즉 워킹 셋(Working Set)을 메모리에 유지하도록 관리하는 방식이다. 프로세스의 워킹 셋을 메모리에 유지할 수 있으면 페이지 부재(Page Fault)를 줄이고 스래싱을 예방할 수 있다.

또 다른 방법은 페이지 부재 빈도(Page Fault Frequency, PFF)를 기준으로 프레임(Frame) 수를 조절하는 방식이다. 페이지 부재율(Page Fault Rate)이 높으면 해당 프로세스에 할당된 프레임 수가 부족하다는 의미로 보고 프레임을 늘려준다. 반대로 페이지 부재율이 낮으면 프레임이 과도하게 할당된 상태일 수 있으므로 프레임 수를 줄인다.

즉, 스래싱 방지의 핵심은 프로세스가 필요로 하는 페이지를 충분히 유지할 수 있도록 프레임 수를 조절하는 것이다. 이를 통해 페이지 부재가 과도하게 발생하지 않도록 하고, 시스템 성능 저하를 막을 수 있다.

페이지 부재 빈도(Page Fault Frequency, PFF) 기반 스래싱(Thrashing) 방지

페이지 부재 빈도(Page Fault Frequency, PFF) 방식은 페이지 부재율(Page Fault Rate)을 기준으로 프레임 수(Frame Count)를 조절하여 스래싱(Thrashing)을 방지하는 방법이다.

이 그래프는 페이지 부재율이 일정한 범위 안에 유지되도록 프레임 수를 조절하는 흐름을 보여준다. 페이지 부재율이 상한(Upper Bound)을 넘으면, 해당 프로세스(Process)에 할당된 프레임 수가 부족하다는 의미로 볼 수 있다. 따라서 프레임 수를 증가시켜 더 많은 페이지(Page)를 메모리(Memory)에 유지하도록 하고, 페이지 부재율을 낮춘다.

반대로 페이지 부재율이 하한(Lower Bound)보다 낮으면, 해당 프로세스에 프레임이 과도하게 할당되어 있을 가능성이 있다. 이 경우에는 프레임 수를 줄여 다른 프로세스가 메모리를 사용할 수 있도록 한다.

즉, PFF 방식은 페이지 부재율이 너무 높지도, 너무 낮지도 않게 일정 범위 안에서 유지되도록 프레임 수를 조절하는 기법이다. 이를 통해 각 프로세스가 필요한 만큼의 메모리를 확보하게 하고, 페이지 부재가 과도하게 발생하는 스래싱 상태를 예방할 수 있다.

3️⃣ Virtual Memory Operation Observation Practice

가상메모리(Virtual Memory) 실습 확인

지금부터는 가상메모리(Virtual Memory) 환경에서 페이지(Page)가 실제로 어떻게 동작하는지 프로그램 실행을 통해 확인한다.

앞에서 요구 페이징(Demand Paging)과 페이지 부재(Page Fault)의 개념을 살펴보았다. 요구 페이징은 프로그램 실행 중 필요한 페이지를 그때그때 메모리(Memory)로 가져오는 방식이고, 페이지 부재는 필요한 페이지가 현재 메모리에 없을 때 발생하는 현상이다.

이제는 이러한 개념들이 실제 시스템(System)에서 어떻게 나타나는지 직접 확인해볼 차례이다. 프로그램을 실행하면서 메모리 접근 과정에서 페이지가 어떻게 적재되고, 페이지 부재가 어떤 방식으로 발생하는지 살펴볼 수 있다.

가상메모리(Virtual Memory) 실습 목표

이번 실습에서는 가상 주소 공간(Virtual Address Space)을 확보하는 시점과 실제 메모리(Memory)에 적재되는 시점의 차이를 확인한다. 또한 페이지(Page)에 처음 접근했을 때와 다시 접근했을 때 어떤 차이가 나타나는지도 비교한다.

추가로 fork 이후에 복사 후 쓰기(Copy-on-Write, COW)가 어떻게 동작하는지도 함께 살펴본다. 이를 위해 단순히 코드를 실행하는 것이 아니라, 특정 기준을 가지고 결과를 관찰하는 것이 중요하다.

이번 실습에서는 mmap, fork, getrusage() 호출을 사용해 메모리 동작을 확인한다. 특히 getrusage()는 프로그램 실행 중 발생한 페이지 부재(Page Fault) 횟수를 확인할 수 있게 해준다.

여기서 중요한 관찰 기준은 페이지 부재이다. 페이지 부재는 크게 마이너 페이지 부재(Minor Page Fault)와 메이저 페이지 부재(Major Page Fault)로 나눌 수 있다.

마이너 페이지 부재는 디스크 접근 없이 메모리 할당이나 페이지 연결이 이루어지는 경우를 의미한다. 반면 메이저 페이지 부재는 필요한 데이터를 가져오기 위해 실제 디스크 입출력(Disk I/O)이 발생하는 경우를 의미한다.

따라서 이번 실습에서는 페이지에 처음 접근하거나 쓰기 작업이 발생하는 순간, 마이너 페이지 부재 값이 어떻게 변화하는지를 중심으로 관찰한다. 이를 통해 가상메모리 환경에서 페이지가 실제로 언제 메모리에 적재되고, 요구 페이징(Demand Paging)이 어떻게 나타나는지 확인할 수 있다.

요구 페이징(Demand Paging) 관찰

이번 실습에서는 페이지(Page)에 처음 접근했을 때 페이지 부재(Page Fault)가 발생하는지, 그리고 실제 메모리(Memory)가 언제 할당되는지를 확인한다.

요구 페이징(Demand Paging)의 동작 방식에서 mmap() 함수를 사용하면 먼저 가상 주소 공간(Virtual Address Space)만 확보된다. 이 시점에서는 실제 물리 메모리(Physical Memory)가 아직 할당된 상태가 아니다.

이후 프로그램이 해당 메모리에 실제로 접근하는 순간, 비로소 물리 메모리에 적재가 이루어진다. 이 과정에서 각 페이지에 처음 접근할 때마다 페이지 부재가 발생할 수 있다.

즉, mmap()으로 주소 공간을 확보하는 것과 실제 메모리가 할당되는 시점은 다르다. 이번 실습에서는 이 차이를 확인하면서, 요구 페이징이 실제 시스템에서 어떻게 나타나는지 관찰한다.

핵심 코드(Core Code)

핵심 코드는 mmap()을 통해 가상 주소 공간(Virtual Address Space)을 확보하고, 이후 각 페이지(Page)에 실제로 접근하면서 페이지 부재(Page Fault)가 발생하는지를 확인하는 부분이다.

먼저 char *buf = mmap(...); 코드는 mmap() 함수를 사용해 가상 주소 공간을 확보하는 역할을 한다. 이 시점에서는 주소 공간만 예약된 상태이고, 실제 물리 메모리(Physical Memory)는 아직 할당되지 않는다.

그다음 buf[i * page_size] = 1; 코드는 각 페이지에 한 번씩 접근하도록 만든다. 이 접근이 일어나는 순간 해당 페이지가 처음으로 사용되고, 그때 실제 물리 메모리에 적재가 이루어진다. 이 과정에서 페이지 부재가 발생한다.

여기서 중요한 점은 각 페이지는 처음 접근할 때만 페이지 부재가 발생한다는 것이다. 같은 페이지에 다시 접근하면 이미 메모리에 올라와 있기 때문에 추가적인 페이지 부재는 발생하지 않는다.

즉, 이 실습에서 페이지 부재는 단순한 접근 횟수보다 서로 다른 페이지를 처음 접근한 횟수와 관련이 있다. mmap()으로 주소 공간을 확보하는 시점과 실제 메모리가 할당되는 시점이 다르다는 것을 이 코드를 통해 확인할 수 있다.

요구 페이징(Demand Paging) 관찰 코드

이 코드는 페이지 부재(Page Fault)가 언제 발생하는지를 확인하기 위해 세 가지 시점으로 나누어 측정한다.

먼저 long f1 = get_faults();를 통해 프로그램 시작 시점의 페이지 부재 횟수를 저장한다. 그 다음 char *buf = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);를 호출하여 가상 주소 공간(Virtual Address Space)을 확보한다.

이후 long f2 = get_faults();를 통해 mmap() 호출 이후의 페이지 부재 횟수를 확인한다. 이 시점에서는 실제 메모리 접근이 이루어진 것이 아니기 때문에 페이지 부재 횟수는 거의 변하지 않는다. 즉, mmap()은 가상 주소 공간만 확보할 뿐, 실제 물리 메모리(Physical Memory)를 바로 할당하는 것은 아니다.

그 다음 반복문 for (int i = 0; i < pages; i++) buf[i * page_size] = 1;을 통해 각 페이지(Page)에 한 번씩 접근한다. 이 부분이 각 페이지에 처음 접근하는 순간이며, 이때 실제 물리 메모리 적재가 이루어지고 페이지 부재가 발생한다.

마지막으로 f3 = get_faults();를 통해 접근 이후의 페이지 부재 횟수를 확인하면, 접근한 페이지 수만큼 페이지 부재가 증가한 것을 확인할 수 있다.

즉, 이 코드는 mmap() 시점에는 페이지 부재가 거의 발생하지 않지만, 실제로 각 페이지에 접근하는 순간 페이지 부재가 발생한다는 것을 확인하기 위한 코드이다. 이를 통해 요구 페이징(Demand Paging)에서는 주소 공간을 확보하는 시점과 실제 메모리가 할당되는 시점이 다르다는 것을 알 수 있다.

요구 페이징(Demand Paging) 관찰 결과

실행 결과를 보면 세 시점에서의 마이너 폴트(Minor Fault) 값을 비교할 수 있다. 이번 실습에서는 특히 마이너 폴트의 변화에 집중한다.

먼저 프로그램 시작 시점에서는 마이너 폴트 값이 minor: 320처럼 일정한 값으로 나타난다. 그다음 mmap() 호출 이후를 보면 마이너 폴트 값이 minor: 322 정도로 거의 변하지 않은 것을 확인할 수 있다. 이는 mmap() 함수가 실제 물리 메모리(Physical Memory)를 바로 할당하는 것이 아니라, 가상 주소 공간(Virtual Address Space)만 확보한다는 것을 보여준다.

반면 실제로 페이지(Page)에 접근한 이후에는 마이너 폴트 값이 minor: 1340처럼 크게 증가한다. 이 증가는 각 페이지에 처음 접근하는 순간 페이지 부재(Page Fault)가 발생했기 때문이다. 즉, 확보된 가상 주소 공간에 실제로 접근할 때 물리 메모리가 연결되면서 마이너 폴트가 증가한 것이다.

따라서 이 실습 결과의 핵심은 mmap() 이후에는 페이지 부재가 거의 증가하지 않지만, 실제 페이지에 접근하는 순간 마이너 폴트가 크게 증가한다는 점이다. 이를 통해 요구 페이징(Demand Paging)에서는 가상 주소 공간을 확보하는 시점과 실제 메모리가 할당되는 시점이 다르다는 것을 확인할 수 있다.

단, 마이너 폴트의 숫자 자체는 실행 환경에 따라 달라질 수 있다. 운영체제(Operating System)의 상태나 기존 실행 이력에 따라 초기값이나 증가량은 다르게 나타날 수 있으므로, 중요한 것은 숫자 자체보다 mmap() 이후와 실제 접근 이후의 변화 흐름이다.

요구 페이징(Demand Paging) 관찰 결과 해석

실행 결과를 정리하면, mmap() 함수는 실제 물리 메모리(Physical Memory)를 바로 할당하는 것이 아니라 가상 주소 공간(Virtual Address Space)만 확보한다는 것을 확인할 수 있다.

따라서 mmap()을 호출한 직후에는 페이지 부재(Page Fault)가 거의 증가하지 않는다. 아직 해당 주소 공간에 실제로 접근하지 않았기 때문이다.

반면 확보된 주소 공간의 각 페이지(Page)에 실제로 접근하는 순간, 그때 물리 메모리에 적재가 이루어진다. 이 과정에서 마이너 폴트(Minor Fault)가 증가한다.

즉, 요구 페이징(Demand Paging)에서는 주소 공간을 확보하는 시점과 실제 메모리가 할당되는 시점이 다르다. 실제 메모리는 페이지에 처음 접근하는 순간 할당되며, 이때 페이지 부재가 발생한다고 이해할 수 있다.

실행 결과 해석(Result Interpretation)

Fault의 의미를 보면, 마이너 폴트(Minor Fault)는 디스크 접근(Disk Access) 없이 메모리 할당(Memory Allocation)이 이루어지는 경우를 의미한다. 반면 메이저 폴트(Major Fault)는 필요한 데이터를 가져오기 위해 디스크 입출력(Disk I/O)이 발생하는 경우를 의미한다.

이번 실습에서는 마이너 폴트가 증가하는 모습을 통해 요구 페이징(Demand Paging)의 동작을 확인하였다. mmap() 함수로 가상 주소 공간(Virtual Address Space)을 확보했을 때는 실제 물리 메모리(Physical Memory)가 바로 할당되지 않았고, 페이지(Page)에 실제로 접근하는 순간 메모리가 사용되면서 마이너 폴트가 증가하였다.

결국 가상메모리(Virtual Memory)의 핵심은 메모리가 할당되는 시점이 단순히 주소 공간을 확보한 시점이 아니라, 실제로 해당 페이지에 접근하는 시점이라는 점이다.

실습 결과

요구 페이징 재접근 특성 관찰 Observation of Re-access Characteristics in Demand Paging

이번 실습에서는 페이지(Page)에 처음 접근했을 때 페이지 부재(Page Fault)가 발생하는 것에서 한 단계 더 나아가, 이미 접근했던 페이지에 다시 접근했을 때 어떤 변화가 있는지 확인한다.

핵심은 동일한 페이지를 다시 접근할 때 페이지 부재가 다시 발생하는지 관찰하는 것이다. 요구 페이징(Demand Paging)에서는 페이지에 처음 접근하는 순간 물리 메모리(Physical Memory)에 적재가 이루어지고, 이때 페이지 부재가 발생한다.

하지만 한 번 메모리에 적재된 페이지는 이후 다시 접근할 때 그대로 재사용될 수 있다. 따라서 같은 페이지에 다시 접근하는 경우에는 일반적으로 추가적인 페이지 부재가 발생하지 않는다.

이번 실습에서는 처음 접근과 재접근을 비교하면서, 페이지가 한 번 물리 메모리에 올라온 이후에는 어떻게 재사용되는지 확인한다. 이를 통해 요구 페이징에서 페이지 부재는 단순한 접근 횟수가 아니라, 처음 접근하는 페이지 수와 관련이 있다는 점을 이해할 수 있다.

Observation of Re-access Characteristics in Demand Paging

핵심 코드는 같은 방식으로 페이지(Page)에 접근하는 반복문이 두 번 실행되는 구조이다. 이를 통해 처음 접근할 때와 다시 접근할 때 페이지 부재(Page Fault)가 어떻게 달라지는지 확인할 수 있다.

첫 번째 루프(First Loop)는 각 페이지에 처음 접근하는 과정이다. 이때 각 페이지는 아직 물리 메모리(Physical Memory)에 올라와 있지 않기 때문에, 페이지마다 페이지 부재가 발생한다. 즉, 처음 접근하는 순간 실제 메모리 적재가 이루어진다.

반면 두 번째 루프(Second Loop)는 이미 한 번 접근했던 동일한 페이지에 다시 접근하는 과정이다. 이 경우 해당 페이지들은 이미 메모리에 올라와 있기 때문에 추가적인 페이지 부재는 거의 발생하지 않는다.

즉, 이 코드는 첫 접근(First Access)과 재접근(Re-access)의 차이를 확인하기 위한 예제이다. 페이지는 한 번 메모리에 올라오면 이후 다시 접근할 때 그대로 재사용될 수 있으며, 같은 페이지에 반복해서 접근한다고 해서 매번 페이지 부재가 발생하는 것은 아니다라는 걸 알수있다.

Core Code for Observing Re-access Characteristics in Demand Paging

이 코드는 같은 페이지(Page)에 대한 접근을 두 번 수행하면서, 각각 페이지 폴트(Page Fault)의 변화를 비교하는 코드이다.

먼저 첫 번째 순회(First Pass)에서는 before 값을 통해 현재 마이너 폴트(Minor Fault) 수를 저장한 뒤, 반복문을 통해 각 페이지에 한 번씩 접근한다. 이때 모든 페이지는 처음 접근되는 상태이기 때문에, 각 페이지마다 페이지 폴트가 발생한다. 따라서 첫 번째 순회 결과에서는 페이지 수만큼 마이너 폴트가 증가하는 것을 확인할 수 있다.

두 번째 순회(Second Pass)에서는 이미 한 번 접근했던 동일한 페이지에 다시 접근한다. 이 경우 해당 페이지들은 이미 물리 메모리(Physical Memory)에 올라와 있는 상태이기 때문에, 추가적인 페이지 폴트는 거의 발생하지 않는다. 따라서 두 번째 순회의 결과는 첫 번째 순회와 비교했을 때 매우 작거나 0에 가까운 값으로 나타난다.

결국 이 코드는 첫 접근(First Access)에서는 페이지 폴트가 발생하지만, 재접근(Re-access) 시에는 같은 페이지가 이미 메모리에 적재되어 있기 때문에 페이지 폴트가 거의 발생하지 않는다는 점을 수치적으로 확인하기 위한 예제라고 할 수 있다.

Example Execution Result

실행 결과를 보면 첫 번째 순회(First Pass)에서 마이너 폴트(Minor Fault)가 1024만큼 증가한 것을 확인할 수 있다. 이는 페이지(Page) 수가 1024개이기 때문에, 각 페이지에 처음 접근하면서 모든 페이지에서 페이지 폴트(Page Fault)가 발생했기 때문이다.

반면 두 번째 순회(Second Pass)에서는 마이너 폴트 증가량이 0으로 나타난다. 이는 첫 번째 순회에서 이미 접근했던 페이지들이 모두 물리 메모리(Physical Memory)에 올라와 있기 때문이다. 따라서 같은 페이지에 다시 접근할 때는 추가적인 페이지 폴트가 발생하지 않는다.

이 결과를 통해 페이지는 처음 접근할 때 메모리에 적재되고, 한 번 적재된 이후에는 다시 접근해도 그대로 재사용된다는 점을 확인할 수 있다. 즉, 요구 페이징(Demand Paging)에서는 페이지 폴트가 매번 발생하는 것이 아니라, 해당 페이지에 처음 접근할 때 주로 발생한다고 이해할 수 있다.

Result Interpretation

지금까지의 결과를 정리하면, 페이지(Page)에 처음 접근할 때는 해당 페이지가 아직 메모리(Memory)에 없기 때문에 페이지 폴트(Page Fault)가 발생한다.

하지만 한 번 물리 메모리(Physical Memory)에 적재된 이후에는 같은 페이지에 다시 접근하더라도 추가적인 페이지 폴트는 발생하지 않는다. 이미 해당 페이지가 메모리에 올라와 있기 때문에 그대로 재사용될 수 있기 때문이다.

또한 페이지 폴트의 증가량은 단순한 접근 횟수로 결정되는 것이 아니라, 처음 접근한 서로 다른 페이지 수에 의해 결정된다. 이는 메모리가 페이지 단위(Page Unit)로 관리되기 때문이다.

따라서 이 실습의 핵심은 각 페이지는 처음 접근할 때만 페이지 폴트가 발생하고, 한 번 적재된 페이지는 메모리에 유지되는 동안 재사용된다는 점이다.

실습결과

Copy-on-Write 관찰(Observation of Copy-on-Write)

세 번째 실습에서는 fork() 이후 메모리(Memory)가 어떻게 복사되는지 확인한다. 특히 쓰기 작업(Write)이 발생하는 시점에 Copy-on-Write가 어떻게 동작하는지, 그리고 그 결과 부모 프로세스(Parent Process)와 자식 프로세스(Child Process)의 메모리가 어떻게 분리되는지를 살펴본다.

핵심 개념은 fork()가 호출되었을 때 부모 프로세스와 자식 프로세스가 처음부터 메모리를 완전히 따로 복사해서 가지는 것이 아니라는 점이다. 처음에는 두 프로세스가 같은 메모리 공간을 공유하는 상태로 시작한다.

하지만 이후 부모 프로세스나 자식 프로세스 중 하나가 해당 메모리에 쓰기 작업을 수행하면, 그 순간 실제 복사가 이루어진다. 이렇게 쓰기 시점에 복사가 발생하는 방식을 Copy-on-Write라고 한다.

즉, Copy-on-Write는 처음에는 메모리를 공유하다가, 실제로 내용을 변경하려는 순간에만 복사하여 부모와 자식의 메모리를 분리하는 방식이다. 이를 통해 불필요한 메모리 복사를 줄이고, fork() 이후의 메모리 사용을 더 효율적으로 관리할 수 있다.

Copy-on-Write Core Code

Copy-on-Write 핵심 코드는 크게 세 단계로 나누어 이해할 수 있다.

먼저 fork() 이전에는 buf[i * page_size] = 1 코드를 통해 부모 프로세스(Parent Process)가 각 페이지(Page)에 먼저 접근한다. 이 과정에서 해당 페이지들은 물리 메모리(Physical Memory)에 적재된다.

그 이후 pid_t pid = fork();가 호출되면 부모 프로세스와 자식 프로세스(Child Process)가 생성된다. 이 시점에서는 메모리 전체가 바로 복사되는 것이 아니라, 두 프로세스가 같은 페이지를 공유하는 상태가 된다.

이후 자식 프로세스가 buf[i * page_size] += 1과 같이 공유 중인 페이지에 쓰기 작업(Write)을 시도하면 Copy-on-Write가 발생한다. 공유된 페이지는 바로 수정될 수 없기 때문에, 쓰기 시점에 페이지 폴트(Page Fault)가 발생한다.

운영체제(Operating System)는 이 페이지 폴트를 계기로 해당 페이지를 복사하고, 자식 프로세스에게 새로운 페이지를 할당한다. 그 결과 자식 프로세스는 복사된 새 페이지를 사용하고, 부모 프로세스는 기존 페이지를 그대로 유지한다.

즉, Copy-on-Write는 fork() 직후에는 메모리를 공유하다가, 실제 쓰기 작업이 발생하는 순간에만 페이지를 복사하여 부모와 자식 프로세스의 메모리를 분리하는 방식이다.

Copy-on-Write Core Code

이 코드는 Copy-on-Write가 어떤 시점에서 발생하는지를 확인하기 위한 코드이다.

먼저 fork() 이전에는 부모 프로세스(Parent Process)가 반복문을 통해 각 페이지(Page)에 한 번씩 접근한다. 이 과정에서 페이지가 물리 메모리(Physical Memory)에 적재된다.

그다음 fork()가 호출되면 부모 프로세스와 자식 프로세스(Child Process)가 생성된다. 이 시점에서는 실제 메모리 복사가 일어나지 않고, 두 프로세스가 동일한 페이지를 공유한다.

이후 자식 프로세스에서 buf[i * page_size] += 1 코드가 실행되면 공유된 페이지에 쓰기 작업(Write)이 발생한다. 이때 공유된 페이지는 읽기 전용(Read-only) 상태이기 때문에 페이지 폴트(Page Fault)가 발생한다.

운영체제(Operating System)는 이 페이지 폴트를 계기로 해당 페이지를 복사하고, 자식 프로세스에게 새로운 페이지를 할당한다. 이 과정이 Copy-on-Write이다.

따라서 자식 프로세스에서는 쓰기 작업이 발생한 시점에 마이너 폴트(Minor Fault)가 증가하는 것을 확인할 수 있다. 반면 부모 프로세스는 기존 페이지를 그대로 유지하므로, 자식 프로세스의 쓰기 작업이 부모 프로세스의 메모리 값에는 영향을 주지 않는다.

Copy-on-Write Observation Result

실행 결과를 보면 자식 프로세스(Child Process)와 부모 프로세스(Parent Process)의 차이를 확인할 수 있다.

먼저 자식 프로세스에서는 마이너 폴트(Minor Fault)가 256만큼 증가한 것을 볼 수 있다. 이는 자식 프로세스가 각 페이지(Page)에 쓰기 작업(Write)을 수행하는 순간마다 페이지 폴트(Page Fault)가 발생했기 때문이다. 즉, 자식 프로세스가 접근한 페이지 수만큼 Copy-on-Write가 발생했다고 볼 수 있다.

또한 자식 프로세스의 첫 번째 페이지 값은 기존 값 1에서 2로 증가하였다. 이는 자식 프로세스가 해당 페이지에 쓰기 작업을 수행했기 때문이다.

반면 부모 프로세스의 첫 번째 페이지 값은 여전히 1로 유지된다. 이는 자식 프로세스가 공유 페이지를 직접 수정한 것이 아니라, 쓰기 시점에 별도의 페이지를 복사해서 사용했기 때문이다.

따라서 Copy-on-Write는 fork() 직후에는 부모와 자식이 같은 페이지를 공유하지만, 쓰기 작업이 발생하는 순간 페이지를 복사하여 두 프로세스의 메모리를 분리한다. 이로 인해 자식 프로세스의 변경은 부모 프로세스에 영향을 주지 않는다는 것을 알 수 있다.

Copy-on-Write Result Interpretation

지금까지의 결과를 정리하면, fork() 직후에는 부모 프로세스(Parent Process)와 자식 프로세스(Child Process)가 동일한 페이지(Page)를 공유한다. 이 상태에서는 실제 메모리 복사(Memory Copy)가 바로 이루어지지 않고, 같은 데이터를 함께 사용하는 구조가 된다.

이후 자식 프로세스가 해당 페이지에 쓰기 작업(Write)을 수행하면, 그 시점에서 Copy-on-Write가 발생한다. 즉, 복사는 fork()가 호출되는 순간이 아니라 실제로 write가 발생하는 순간에 이루어진다.

이때 자식 프로세스는 새롭게 복사된 페이지를 사용하고, 부모 프로세스는 기존 페이지를 그대로 유지한다. 따라서 자식 프로세스가 값을 변경하더라도 부모 프로세스의 메모리 값에는 영향을 주지 않는다.

또한 Copy-on-Write는 페이지 폴트(Page Fault)를 이용해 실제 복사 시점을 지연시키는 방식이라고 이해할 수 있다. 처음에는 메모리를 공유하다가, 쓰기 작업이 발생할 때만 필요한 페이지를 복사함으로써 불필요한 메모리 복사를 줄일 수 있다.

이번 실습은 복잡한 구현보다는 코드를 실행하고 결과를 관찰하는 것이 핵심이다. mmap(), fork(), getrusage()를 통해 가상 주소 공간(Virtual Address Space), 요구 페이징(Demand Paging), 페이지 폴트(Page Fault), Copy-on-Write의 동작을 실제 결과로 확인하는 데 목적이 있다.

실습 결과

1️⃣ Core Concepts of Test Automation

테스트 자동화의 학습목표 (Learning Objectives of Test Automation)

이번 강의의 목표는 테스트 자동화(Test Automation)의 개념과 적용 범위를 이해하는 것이다. 테스트 자동화란 사람이 반복적으로 수행하던 테스트 활동을 도구나 프로그램을 이용해 자동으로 처리하거나 지원하는 것을 말한다. 자동화는 테스트 시간을 줄이고, 반복 테스트를 일관되게 수행하며, 테스트 효율을 높이기 위해 필요하다.

테스트 자동화는 테스트 프로세스의 여러 단계에 적용될 수 있다. 그중 대표적인 것이 테스트 설계 자동화(Test Design Automation)이다. 이는 테스트 케이스(Test Case), 테스트 데이터(Test Data), 테스트 조건(Test Condition) 등을 자동으로 생성하거나 설계 과정을 지원하는 것이다.

또 다른 핵심 영역은 테스트 수행 자동화(Test Execution Automation)이다. 이는 작성된 테스트를 자동으로 실행하고, 실제 결과(Actual Result)와 기대 결과(Expected Result)를 비교하며, 테스트 결과를 기록하는 과정을 지원한다.

결국 테스트 자동화는 단순히 테스트를 실행하는 것만이 아니라, 테스트 설계부터 수행까지 테스트 활동 전반의 효율성과 정확성을 높이는 데 목적이 있다.

테스트 자동화 핵심 개념 (Core Concepts of Test Automation)

테스트 자동화(Test Automation)는 테스트 프로세스의 전체 또는 일부를 도구(Tool)를 활용해 자동으로 수행하거나 지원하는 것을 의미한다. 테스트 프로세스에는 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가(Test Evaluation), 테스트 개선(Test Improvement) 등이 포함되며, 이 중 필요한 부분을 자동화할 수 있다.

일반적으로 자동화(Automation)는 사람이 직접 수행하던 반복적인 절차를 시스템이나 도구가 대신 수행하도록 만드는 것이다. 사람이 직접 모든 단계를 수행하면 입력 실수, 절차 누락, 결과 확인 오류 등이 발생할 수 있고, 시간과 비용도 많이 든다. 반면 자동화를 적용하면 반복 작업에서 발생하는 실수를 줄이고, 사람은 더 창의적이고 중요한 업무에 집중할 수 있다.

예를 들어 로그인 기능을 매뉴얼 테스트(Manual Testing)로 수행하는 경우, 테스터는 웹사이트 주소를 입력하고, 아이디와 비밀번호를 입력한 뒤, 로그인 버튼을 클릭하고, Welcome 페이지가 정상적으로 나타나는지 직접 확인해야 한다.

Selenium과 JUnit을 활용한 로그인 테스트 자동화 예시

(Login Test Automation with Selenium and JUnit)

문법을 자세히 이해하는 것보다 중요한 것은 각 코드가 어떤 역할을 하는지 이해하는 것이다. 예를 들어 로그인 기능을 자동화하는 테스트 메소드가 shouldVisitWelcomePage()라고 하면, 이 메소드는 사용자가 로그인했을 때 Welcome 페이지로 정상 이동하는지를 확인하는 역할을 한다.

먼저 Selenium의 driver.get() 메소드는 테스트할 웹사이트 주소로 이동하는 기능을 한다. 매뉴얼 테스트(Manual Testing)에서는 테스터가 매번 웹사이트 주소를 직접 입력해야 하지만, 자동화 테스트(Automated Testing)에서는 driver.get("웹 사이트 주소")처럼 주소를 코드로 한 번 작성해두면 반복 실행할 때마다 동일한 주소로 접속할 수 있다. 이를 통해 주소 입력 실수를 줄일 수 있다.

다음으로 driver.findElement().sendKeys()는 웹페이지에서 특정 입력란을 찾아 값을 입력하는 역할을 한다. 예를 들어 아이디 입력란을 찾아 사용자 아이디를 입력하고, 비밀번호 입력란을 찾아 비밀번호를 입력할 수 있다. 웹페이지의 id 속성이나 xpath 등을 이용해 원하는 요소(Element)를 찾고, sendKeys()를 통해 값을 넣는 방식이다.

로그인 버튼을 누르는 과정은 click() 메소드를 통해 자동화할 수 있다. 예를 들어 로그인 버튼 요소를 찾은 뒤 click()을 실행하면, 사람이 직접 버튼을 클릭하는 것처럼 자동으로 로그인 버튼이 눌린다. 이렇게 웹사이트 접속, 아이디 입력, 비밀번호 입력, 버튼 클릭 과정을 코드로 작성해두면 같은 테스트를 여러 번 반복해도 동일한 절차로 실행할 수 있다.

마지막으로 JUnit의 assertEquals() 메소드는 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교하는 역할을 한다. 테스트에서는 예상한 결과와 실제 실행 결과가 같은지 확인하는 과정이 중요하다. 예를 들어 로그인 후 나타나야 하는 “웰컴 메시지”를 기대값으로 두고, 실제 웹페이지에서 getText()로 가져온 메시지와 비교한다. 두 값이 같으면 테스트가 정상적으로 통과한 것이고, 다르면 결함(Defect)이 발생했을 가능성이 있다고 볼 수 있다.

정리하면 Selenium은 웹페이지를 열고, 입력란에 값을 넣고, 버튼을 클릭하는 등 사용자의 행동을 자동화하는 데 사용된다. JUnit은 그 결과가 예상한 값과 같은지 검증하는 데 사용된다. 따라서 Selenium과 JUnit을 함께 사용하면 로그인 기능처럼 반복적으로 확인해야 하는 테스트를 효율적으로 자동화할 수 있다.

이러한 과정을 Selenium이나 JUnit 같은 테스트 도구를 활용해 자동화할 수 있다. Selenium은 웹 애플리케이션(Web Application)의 동작을 자동으로 제어하고 테스트할 수 있는 프레임워크이며, JUnit은 Java 기반의 테스트를 지원하는 도구이다. 예를 들어 Selenium을 이용하면 웹사이트 접속, 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭 과정을 코드로 작성할 수 있다.

또한 JUnit의 assertEquals()와 같은 메소드를 사용하면 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교할 수 있다. 로그인 후 나타나야 하는 Welcome 메시지를 기대값으로 설정하고, 실제 웹페이지에서 가져온 메시지와 비교하여 두 값이 같으면 테스트가 정상적으로 수행된 것으로 볼 수 있다.

결국 테스트 자동화는 사람이 반복적으로 수행하던 테스트 절차를 코드와 도구로 자동화하여, 테스트 시간을 줄이고 실수를 줄이며 효율성을 높이는 방법이다. 특히 반복 테스트(Repeated Testing), 회귀 테스트(Regression Testing), 입력 데이터가 많은 테스트에서 효과적으로 활용된다.

테스트 자동화의 필요성 (Necessity of Test Automation)

테스트 자동화(Test Automation)가 필요한 이유는 반복적인 테스트를 효율적으로 수행하고, 사람의 실수를 줄이며, 일관된 방식으로 테스트를 진행하기 위해서이다.

첫 번째 필요성은 반복적인 작업을 효율적으로 수행할 수 있다는 점이다. 소프트웨어는 요구사항이 계속 변경될 수 있기 때문에, 기존 기능이 여전히 정상적으로 동작하는지 반복해서 확인해야 한다. 이때 테스트 절차를 코드화해두면, 입력값만 바꿔가며 같은 테스트를 쉽게 반복할 수 있다. 특히 회귀 테스트(Regression Testing)처럼 기존 기능을 계속 다시 확인해야 하는 경우 자동화의 효과가 크다.

또한 부하 테스트(Load Testing)에서도 테스트 자동화가 필요하다. 예를 들어 시스템이 100명의 동시 접속자를 허용해야 한다면, 실제 사용자 100명을 모집해서 동시에 접속시키는 것은 비용과 시간이 많이 든다. 대신 테스트 스크립트(Test Script), 스레드(Thread), 프로세스(Process) 등을 이용해 여러 사용자가 동시에 접속하는 상황을 가상으로 만들 수 있다. 이를 통해 시스템이 많은 부하를 받는 상황에서도 안정적으로 동작하는지 확인할 수 있다.

두 번째 필요성은 실수를 줄이고 일관되게 테스트할 수 있다는 점이다. 사람이 직접 테스트를 수행하면 잘못된 데이터를 입력하거나, 정해진 절차를 빠뜨리는 실수가 발생할 수 있다. 하지만 테스트 자동화를 적용하면 미리 작성된 테스트 코드(Test Code)에 따라 동일한 절차가 반복적으로 실행되기 때문에, 테스트를 더 일관성 있게 수행할 수 있다.

예를 들어 로그인 기능을 테스트할 때 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭, 결과 확인 과정을 코드로 작성해두면 매번 같은 방식으로 테스트할 수 있다. 이를 통해 입력 실수나 절차 누락을 줄일 수 있다.

다만 테스트 자동화가 모든 테스트에 항상 적합한 것은 아니다. 테스트 자동화는 테스트 프로세스 전체에 적용될 수도 있지만, 필요한 일부 과정에만 적용될 수도 있다. 특히 반복적으로 수행되는 부분, 실수가 자주 발생하는 부분, 많은 데이터를 다루는 부분이 자동화 대상이 된다.

반대로 반복이 거의 없거나, 화면 전환이 자연스러운지처럼 사람이 직접 보고 판단하는 것이 더 적절한 테스트도 있다. 예를 들어 e북에서 페이지가 부드럽게 넘어가는지 확인하는 경우에는 자동화보다 사람이 직접 확인하는 것이 더 명확할 수 있다.

결론적으로 테스트 자동화는 무조건 많이 적용하는 것이 아니라, 비용 대비 효과가 큰 부분에 집중해서 적용해야 한다. 반복이 많고 실수 가능성이 높은 테스트를 자동화할 때, 테스트 시간과 비용을 줄이고 테스트 품질을 높일 수 있게 된다.

테스트 프로세스에서 자동화 가능한 부분

(Automation Areas in the Test Process)

테스트 자동화(Test Automation)는 테스트 프로세스 전체에 적용될 수도 있고, 필요한 일부 단계에만 적용될 수도 있다. 따라서 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가(Test Evaluation), 테스트 개선(Test Improvement) 등 여러 단계에서 자동화가 가능하다.

먼저 테스트 계획(Test Planning) 단계에서는 테스트 일정, 인력, 범위 등을 관리해야 한다. 이 과정은 사람이 직접 계획할 수도 있지만, 일정 관리 도구나 테스트 관리 도구(Test Management Tool)를 사용하면 일부 작업을 자동화하거나 체계적으로 관리할 수 있다.

테스트 설계(Test Design) 단계에서는 테스트 케이스(Test Case), 테스트 데이터(Test Data), 테스트 조건(Test Condition) 등을 만드는 과정에서 자동화가 많이 활용될 수 있다. 특히 반복적으로 작성해야 하는 테스트 케이스나 다양한 입력값을 기반으로 하는 테스트 데이터 생성은 자동화의 효과가 크다.

테스트 수행(Test Execution) 단계는 테스트 자동화가 가장 많이 적용되는 부분 중 하나이다. 작성된 테스트 케이스를 자동으로 실행하고, 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교하며, 테스트 결과를 기록하는 과정이 자동화될 수 있다.

테스트 평가(Test Evaluation)와 테스트 개선(Test Improvement) 단계에서도 자동화가 가능하다. 테스트 수행 결과로 나온 데이터를 도구를 통해 분석하면, 결함 발생률, 테스트 성공률, 반복적으로 실패하는 기능 등을 파악할 수 있다. 이러한 데이터는 이후 테스트 프로세스를 개선하는 데 활용될 수 있다.

다만 테스트 자동화에서 특히 집중하는 부분은 테스트 설계(Test Design)와 테스트 수행(Test Execution)이다. 테스트 케이스를 만들고, 이를 실제로 실행하며 결과를 확인하는 과정에서 자동화의 효과가 크기 때문이다.

정리하면, 테스트 자동화는 테스트 프로세스의 여러 단계에 적용될 수 있지만, 모든 단계를 무조건 자동화하는 것은 아니다. 필요성과 효과를 고려하여 자동화할 부분을 선택해야 하며, 특히 테스트 설계와 테스트 수행 단계가 핵심적인 자동화 대상이 된다.

테스트 설계 자동화의 개념 (Concept of Test Design Automation)

두 번째 시간에는 테스트 설계 자동화(Test Design Automation)의 개념과 적용 방법을 간단한 예시를 통해 살펴본다.

테스트 설계 자동화란 테스트 설계 프로세스(Test Design Process)의 전체 또는 일부를 도구(Tool)를 활용해 자동화하는 것을 의미한다. 특히 테스트 케이스(Test Case)를 개발하거나, 테스트 수행을 위한 환경(Test Environment)을 준비하는 과정에서 반복적이고 실수가 발생하기 쉬운 작업이 자동화 대상이 된다.

테스트 설계 단계에서는 테스트할 조건을 정리하고, 그 조건을 바탕으로 테스트 케이스와 테스트 데이터를 만든다. 이 과정이 매번 수작업으로 이루어지면 누락이나 입력 오류가 발생할 수 있다. 따라서 도구를 사용해 테스트 케이스 생성, 테스트 데이터 준비, 테스트 환경 구성 등을 지원하면 더 효율적이고 일관된 테스트 설계가 가능하다.

ISO/IEC/IEEE 29119의 동적 테스트 프로세스(Dynamic Test Process)를 기준으로 보면, 테스트 설계 자동화의 주요 대상은 테스트 설계 및 구현(Test Design and Implementation)과 테스트 환경 구성 및 유지(Test Environment Set-up and Maintenance) 단계이다. 즉, 테스트를 실제로 수행하기 전에 필요한 테스트 케이스, 테스트 데이터, 테스트 환경을 준비하는 부분이 테스트 설계 자동화의 핵심 범위라고 볼 수 있다.

정리하면, 테스트 설계 자동화는 테스트를 실행하기 전에 필요한 준비 과정을 도구로 지원하거나 자동화하는 것이다. 이를 통해 반복적인 설계 작업을 줄이고, 실수를 줄이며, 테스트 준비 과정을 더 체계적으로 관리할 수 있다.

테스트 케이스 개발 자동화 (Test Case Development Automation)

테스트 케이스 개발 자동화(Test Case Development Automation)는 테스트 설계 기법(Test Design Technique)을 도구에 적용하여 테스트 케이스(Test Case)를 자동으로 생성하거나 지원하는 것이다.

테스트 케이스는 보통 블랙박스 테스트 설계 기법(Black-box Test Design Technique)이나 화이트박스 테스트 설계 기법(White-box Test Design Technique)을 적용해 만든다. 하지만 사람이 직접 테스트 케이스를 만들면 커버리지(Coverage)를 충분히 만족하는 케이스를 빠짐없이 설계하기 어렵고, 누락이나 실수가 발생할 수 있다. 따라서 테스트 설계 기법이 적용된 도구를 활용하면 더 효율적으로 테스트 케이스를 만들 수 있다.

예를 들어 성적에 따라 학점을 부여하는 요구사항이 있다고 하자. 90점 이상 100점 이하는 A, 80점 이상 90점 미만은 B, 70점 이상 80점 미만은 C를 부여하는 방식이다. 이때 각 점수 구간은 같은 결과를 기대할 수 있는 동치 클래스(Equivalence Class)로 볼 수 있다.

동등 분할 테스트(Equivalence Partitioning)는 이러한 입력값의 범위를 의미 있는 구간으로 나누고, 각 구간에서 대표값을 선택해 테스트하는 블랙박스 테스트 기법이다. 예를 들어 90100 구간에서는 95를 대표값으로 선택하고, 8090 구간에서는 85를 대표값으로 선택해 예상한 학점이 나오는지 확인할 수 있다.

이러한 요구사항 명세서(Requirement Specification)를 테스트 설계 도구에 반영하면, 도구가 각 구간의 대표값을 찾아 테스트 케이스를 생성할 수 있다. 더 나아가 생성된 테스트 케이스를 기반으로 실제 테스트 수행까지 연결할 수도 있다.

정리하면, 테스트 케이스 개발 자동화는 테스트 설계 기법을 도구로 지원하여 테스트 케이스를 더 빠르고 일관성 있게 만들기 위한 방법이다. 특히 동등 분할 테스트처럼 일정한 규칙이 있는 테스트 설계에서는 자동화의 효과가 크다.

택배 예약 시스템 예시와 동등 분할의 한계 (Parcel Reservation System Example and Limitation of Equivalence Partitioning)

이번 예시는 테스트 케이스 개발 자동화(Test Case Development Automation)를 이해하기 위한 것이다. 택배 예약 시스템(Parcel Reservation System)에서는 주요 입력 요소(Input Factor)로 택배 무게(Parcel Weight), 배송 지역(Delivery Area), 배송 기간(Delivery Period)이 있다.

동등 분할 테스트(Equivalence Partitioning)를 적용하면 각 입력 요소를 의미 있는 구간이나 값으로 나누고, 각 구간에서 대표값(Representative Value)을 선택한다. 예를 들어 택배 무게는 여러 무게 구간으로 나누고, 배송 지역은 A, B, C, 배송 기간은 일반 배송과 익일 배송으로 나눌 수 있다. 이렇게 나누어진 동치 클래스(Equivalence Class)에서 대표값을 뽑아 테스트 케이스를 만들 수 있다.

이러한 요구사항이 명확하게 정의되어 있다면, 도구를 활용해 테스트 케이스를 자동으로 생성할 수 있다. 택배 무게처럼 범위가 있는 값은 각 구간의 대표값을 선택하고, 배송 지역이나 배송 기간처럼 선택지가 정해진 값은 해당 값을 그대로 테스트 데이터로 사용할 수 있다.

하지만 동등 분할 테스트의 한계는 입력값들의 조합(Combination)을 충분히 고려하지 않는다는 점이다. 동등 분할은 각 입력 요소가 개별적으로 잘 동작하는지를 확인하는 데 초점을 둔다. 예를 들어 택배 무게, 배송 지역, 배송 기간을 각각 테스트할 수는 있지만, 특정 무게와 특정 지역, 특정 배송 기간이 함께 조합되었을 때 발생하는 문제는 놓칠 수 있다.

이 문제를 해결하는 가장 단순한 방법은 모든 조합을 테스트하는 것이다. 예를 들어 택배 무게가 5개 구간, 배송 지역이 3개, 배송 기간이 2개라면 전체 조합은 5 × 3 × 2 = 30개가 된다. 모든 조합을 테스트하면 조합으로 인한 결함을 더 많이 발견할 수 있지만, 테스트 케이스 수가 많아져 시간, 비용, 자원이 많이 필요하다.

따라서 현실적인 대안으로 페어와이즈 테스팅(Pairwise Testing)을 사용할 수 있다. 페어와이즈 테스팅은 모든 입력값의 전체 조합을 테스트하는 대신, 두 입력 요소 사이의 값 조합을 최소 한 번 이상 포함하도록 테스트 케이스를 설계하는 방법이다. 이를 통해 테스트 케이스 수를 줄이면서도 조합으로 인해 발생할 수 있는 결함을 어느 정도 확인할 수 있다.

정리하면, 동등 분할 테스트는 각 입력값의 대표값을 선택해 효율적으로 테스트하는 데 유용하지만, 입력값 간 조합 문제를 충분히 다루기 어렵다. 이 한계를 보완하기 위해 전체 조합 테스트나 페어와이즈 테스팅 같은 방법을 고려할 수 있으며, 이러한 테스트 케이스 생성 과정도 도구를 통해 자동화할 수 있다.

페어와이즈 테스팅 (Pairwise Testing)

페어와이즈 테스팅(Pairwise Testing)은 모든 입력값의 전체 조합을 테스트하기 어려울 때 사용하는 조합 테스트 기법(Combinatorial Testing Technique)이다. 시간과 비용의 제약 때문에 모든 조합을 테스트할 수 없는 경우, 두 개의 입력 요소(Input Factor) 값들이 최소 한 번 이상 함께 조합되도록 테스트 케이스(Test Case)를 설계한다.

전체 조합 테스트(Exhaustive Testing)는 가능한 모든 입력값 조합을 확인하기 때문에 결함을 찾을 가능성은 높지만, 입력 요소가 많아질수록 테스트 케이스 수가 급격히 증가한다. 반면 페어와이즈 테스팅은 모든 조합을 다 확인하지는 않지만, 두 입력값 간의 주요 조합을 포함하도록 하여 테스트 케이스 수를 줄이면서도 일정 수준의 효과를 얻을 수 있다.

예를 들어 입력 요소가 A, B, C 세 개이고, 각 요소에 두 개의 값이 있다고 하자. A는 A1, A2, B는 B1, B2, C는 C1, C2를 가진다. 모든 조합을 테스트하면 2 × 2 × 2 = 8개의 테스트 케이스가 필요하다.

하지만 페어와이즈 테스팅에서는 세 요소 전체의 모든 조합을 확인하는 대신, 두 요소씩 묶은 조합을 고려한다. 즉 A와 B, A와 C, B와 C의 값 조합이 최소 한 번 이상 포함되도록 테스트 케이스를 구성한다.

예를 들어 다음과 같이 테스트 케이스를 만들 수 있다.

이렇게 구성하면 전체 8개 조합을 모두 테스트하지 않아도, A-B, A-C, B-C 사이의 가능한 값 조합을 최소 한 번씩 확인할 수 있다. 예를 들어 TC1에서는 A1-B1, A1-C1, B1-C1 조합이 확인되고, TC2에서는 A1-B2, A1-C2, B2-C2 조합이 확인된다.

즉 페어와이즈 테스팅은 전체 조합을 모두 테스트하지 않는다는 한계가 있지만, 테스트 케이스 수를 줄이면서 입력값 간 조합 문제를 효율적으로 확인할 수 있는 방법이다.

다만 입력 요소나 값의 개수가 많아지면 사람이 직접 페어와이즈 테스트 케이스를 설계하기 어려워진다. 예를 들어 A1, A2뿐 아니라 A3, A4처럼 값이 늘어나고 입력 요소도 많아지면 조합이 복잡해진다. 이때는 페어와이즈 테스트 케이스를 자동으로 생성해주는 도구를 활용하는 것이 효과적이다.

택배 예약 시스템의 페어와이즈 테스팅 적용

(Applying Pairwise Testing to a Parcel Reservation System)

택배 예약 시스템(Parcel Reservation System)에서는 입력 요소(Input Factor)로 택배 무게(Parcel Weight), 배송 지역(Delivery Area), 배송 기간(Delivery Period)이 있다.

이 예시에서 택배 무게는 5개의 대표값(Representative Value), 배송 지역은 A, B, C의 3개 값, 배송 기간은 일반과 익일의 2개 값으로 나뉜다. 모든 조합 테스트(All Combination Testing)를 수행하면 5 × 3 × 2 = 30개의 테스트 케이스(Test Case)가 필요하다.

모든 조합을 테스트하면 입력값들의 조합을 가장 넓게 확인할 수 있지만, 테스트 케이스 수가 많아져 시간, 비용, 자원이 많이 필요하다. 따라서 현실적으로는 비효율적일 수 있다.

이때 페어와이즈 테스팅(Pairwise Testing)을 적용하면 테스트 케이스 수를 줄일 수 있다. 예시에서는 전체 30개의 테스트 케이스 대신 15개의 페어와이즈 테스트 케이스를 만든다. 이 15개 케이스는 모든 조합을 전부 확인하지는 않지만, 택배 무게와 배송 지역, 택배 무게와 배송 기간, 배송 지역과 배송 기간 사이의 주요 쌍 조합(Pair Combination)을 포함하도록 구성된다.

즉 페어와이즈 테스팅은 전체 조합을 모두 테스트하지 않으면서도, 두 입력 요소 간의 조합을 최대한 효율적으로 확인하는 방법이다. 이를 통해 테스트 케이스 수를 줄이고, 테스트 수행에 필요한 시간과 비용을 줄일 수 있다.

하지만 입력 요소와 값이 많아지면 사람이 직접 페어와이즈 테스트 케이스를 만드는 것은 헷갈리고 어렵다. 그래서 이런 경우에는 페어와이즈 테스트 케이스를 자동으로 생성해주는 도구(Test Case Generation Tool)를 활용할 수 있다. 이처럼 테스트 케이스 수를 줄이면서도 중요한 조합을 확인할 수 있는 부분이 테스트 설계 자동화(Test Design Automation)가 필요한 이유이다.

PICT를 활용한 테스트 케이스 자동 생성(Automatic Test Case Generation with PICT)

이번 예시는 페어와이즈 테스팅 도구(Pairwise Testing Tool)인 PICT를 활용해 테스트 케이스(Test Case)를 자동으로 생성하는 방법이다.

예시에서는 스마트폰 제품 명세(Smartphone Product Specification)를 기준으로 테스트 케이스를 만든다. 입력 요소(Input Factor)는 크기(Size), 무게(Weight), 저장 공간(Storage), 메모리(Memory), 배터리(Battery) 총 5가지이다. 각 요소는 2개의 값을 가진다. 예를 들어 크기는 6.1 inch와 6.8 inch, 무게는 220g과 240g, 저장 공간은 256GB와 512GB, 메모리는 8GB와 12GB, 배터리는 16hrs와 18hrs로 나눌 수 있다.

이 모든 값을 전체 조합(All Combination)으로 테스트하면 2 × 2 × 2 × 2 × 2 = 32개의 테스트 케이스가 필요하다. 하지만 모든 조합을 테스트하면 시간과 비용이 많이 들기 때문에, 페어와이즈 테스팅(Pairwise Testing)을 적용해 테스트 케이스 수를 줄일 수 있다.

이 예시에서 중요한 점은 제품의 각 요소가 독립적으로만 문제를 일으키는 것이 아니라, 서로 조합되었을 때 품질 문제(Quality Issue)가 발생할 수 있다는 것이다. 예를 들어 스마트폰의 크기(Size)가 커지면 무게(Weight)가 증가할 수 있고, 무게나 배터리 사용 시간(Battery Life)에 따라 사용자의 불편함이 생길 수도 있다. 따라서 각 요소를 따로 보는 것뿐만 아니라, 요소들 간의 조합도 함께 고려해야 한다.

PICT는 이러한 입력 요소와 값들을 기반으로, 두 요소 간의 조합(Pair Combination)이 포함되도록 테스트 케이스를 자동으로 생성해주는 도구이다. 사람이 직접 조합을 계산하면 복잡하고 실수하기 쉽지만, PICT를 사용하면 더 적은 수의 테스트 케이스로 주요 조합을 확인할 수 있다.

정리하면, PICT를 활용한 테스트 케이스 자동 생성은 전체 조합 테스트보다 테스트 케이스 수를 줄이면서도, 입력 요소 간의 중요한 조합을 확인하기 위한 방법이다. 이는 테스트 설계 자동화(Test Design Automation)의 대표적인 예시라고 볼 수 있다.

PICT 도구 적용 과정 (Applying the PICT Tool)

PICT는 페어와이즈 테스팅(Pairwise Testing)을 적용하여 테스트 케이스(Test Case)를 자동으로 생성해주는 도구이다. 이번 예시에서는 스마트폰 제품 명세(Smartphone Product Specification)를 테스트 데이터(Test Data)로 만들고, 이를 PICT에 입력하여 테스트 케이스를 생성한다.

먼저 11주차 자료에서 PICT 도구(PICT Tool)와 테스트 데이터(Test Data) 파일을 PC로 다운로드한다. 테스트 데이터 파일은 스마트폰의 요구사항이나 제품 명세를 바탕으로 작성된 예시 파일이다. 여기에는 크기(Size), 무게(Weight), 저장 공간(Storage), 메모리(Memory), 배터리(Battery)와 같은 입력 요소와 각 요소의 값들이 정리되어 있다.

다운로드가 끝나면 명령 프롬프트(Command Prompt, cmd)를 실행하고, PICT 도구와 테스트 데이터 파일이 있는 경로로 이동한다. 이후 pict.exe testdata.txt 명령어를 입력하면, testdata.txt에 작성된 입력값을 바탕으로 페어와이즈 테스트 케이스가 자동으로 생성된다.

PICT 내부에는 테스트 케이스를 생성하는 알고리즘이 포함되어 있지만, 이번 강의에서는 알고리즘 자체를 자세히 이해하는 것보다 입력 요소들 사이의 두 값 조합(Pair Combination)을 어떻게 만들어내는지 이해하는 것이 중요하다. 즉, PICT를 활용하면 사람이 직접 복잡한 조합을 계산하지 않아도, 주요 조합을 포함하는 테스트 케이스를 효율적으로 만들 수 있다.

정리하면, PICT 적용 과정은 테스트 데이터를 준비하고, 명령 프롬프트에서 PICT를 실행하여 테스트 케이스를 자동 생성하는 방식이다. 이는 테스트 설계 자동화(Test Design Automation)의 실제 적용 예시라고 볼 수 있다.

PICT를 활용한 테스트 케이스 자동 생성 결과

(Test Case Generation Result with PICT)

스마트폰 제품 명세(Smartphone Product Specification)는 테스트 데이터(Test Data) 파일에 정리되어 있다. 이 파일에는 크기(Size), 무게(Weight), 저장 공간(Storage), 메모리(Memory), 배터리(Battery)와 같은 입력 요소와 각 요소의 값이 포함된다.

이 테스트 데이터를 PICT 도구(PICT Tool)에 입력하면, 페어와이즈 테스팅(Pairwise Testing)을 만족하는 테스트 케이스가 자동으로 생성된다. 예시에서는 전체 조합을 모두 테스트하면 32개의 테스트 케이스가 필요하지만, PICT를 적용하면 7개의 테스트 케이스만으로 주요 쌍 조합(Pair Combination)을 확인할 수 있다.

즉 Size와 Weight, Size와 Storage, Size와 Memory, Size와 Battery뿐만 아니라, Weight와 Storage, Memory와 Battery처럼 각 입력 요소들 사이의 두 값 조합을 고려한 테스트가 가능하다. 이를 통해 모든 조합을 테스트하지 않더라도 중요한 조합을 효율적으로 확인할 수 있다.

테스트 설계(Test Design) 단계에서는 테스트 설계 기법(Test Design Technique)을 이용해 직접 테스트 케이스를 만들 수도 있다. 하지만 사람이 직접 만들 경우 불필요한 테스트 케이스가 많아지거나, 반대로 중요한 조합을 빠뜨려 커버리지(Coverage)를 충분히 확보하지 못할 수 있다.

이때 PICT와 같은 도구를 사용하면 커버리지를 일정 수준 유지하면서도 테스트 케이스 수를 줄일 수 있다. 따라서 테스트 케이스를 더 효율적이고 체계적으로 생성할 수 있으며, 이는 테스트 설계 자동화(Test Design Automation)의 대표적인 예시라고 볼 수 있다.

테스트 환경 준비 자동화 (Test Environment Preparation Automation)

테스트 환경 준비 자동화(Test Environment Preparation Automation)는 테스트를 수행하기 위한 시스템 환경을 수동으로 구성하는 대신, 스크립트(Script)나 도구(Tool)를 사용해 자동으로 구성하는 것을 의미한다.

예를 들어 웹 테스트(Web Testing)를 수행한다면 웹페이지 주소, 포트 번호(Port Number), 설정값(Configuration Value), 필요한 도구와 라이브러리 정보 등을 미리 스크립트에 기록해둘 수 있다. 이후 이 스크립트를 실행하면 테스트에 필요한 환경을 자동으로 구성할 수 있다.

테스트 환경을 수동으로 구성하면 개발 환경(Development Environment)에서는 잘 동작하던 애플리케이션이 테스트 환경(Test Environment)이나 운영 환경(Production Environment)에서는 제대로 동작하지 않는 경우가 생길 수 있다. 이는 각 환경에 설치된 도구, 라이브러리(Library), 버전(Version), 설정값 등이 다르기 때문에 발생할 수 있다.

이러한 문제를 줄이기 위해 테스트 환경도 가능한 한 개발 환경, 테스트 환경, 운영 환경이 동일하거나 유사하게 구성되도록 관리해야 한다. 이를 위해 인프라(Infrastructure)를 코드처럼 관리하는 IaC(Infrastructure as Code) 개념을 활용할 수 있다.

IaC는 서버, 네트워크, 설정값, 라이브러리 등 인프라 구성 정보를 코드로 작성하고 관리하는 방식이다. 이를 사용하면 개발자, 테스터, 운영 담당자가 같은 환경을 기준으로 작업할 수 있고, 환경 차이로 인한 오류를 줄일 수 있다.

정리하면, 테스트 환경 준비 자동화는 테스트 환경을 일관되게 구성하고, 수동 설정에서 발생할 수 있는 실수를 줄이기 위한 방법이다. 특히 여러 환경에서 동일한 조건으로 테스트해야 할 때 효과적이다.

도커 기반 개발 및 운영 환경 자동 구성 예시

(Docker-based Environment Automation Example)

개발 및 운영 환경을 자동으로 구성하는 대표적인 도구 중 하나가 도커(Docker)이다. 도커는 애플리케이션 실행에 필요한 라이브러리(Library), 미들웨어(Middleware), 시스템 도구(System Tool), 런타임 환경(Runtime Environment) 등을 컨테이너(Container)라는 단위로 패키징하여 관리한다.

기존의 가상 머신(Virtual Machine)은 하나의 컴퓨터 안에 또 다른 운영체제(OS)를 설치하고, 그 위에 빌드 도구, 테스트 도구, 애플리케이션 등을 설치하는 방식이다. 이 경우 OS 위에 또 다른 OS가 올라가기 때문에 비교적 무겁고, 많은 컴퓨터 자원이 필요하다.

반면 도커는 호스트 운영체제(Host OS)를 공유하면서 필요한 실행 파일과 설정 파일만 컨테이너 단위로 묶어 실행한다. 따라서 가상 머신보다 가볍고, 자원을 더 효율적으로 사용할 수 있다.

예를 들어 개발 환경에서는 빌드(Build), 테스트(Test), 지속적 통합(Continuous Integration)을 위해 Jenkins, Git, 테스트 도구 등을 사용할 수 있다. 이러한 도구들을 각각 컨테이너로 구성하면 환경을 더 쉽게 관리할 수 있다. 빌드 환경에 문제가 생기면 빌드 컨테이너만 수정하면 되고, 테스트 환경에 문제가 생기면 테스트 컨테이너를 수정하면 된다.

테스트 환경도 도커를 활용해 자동으로 구성할 수 있다. 테스트를 수행하기 위해 필요한 도구와 설정을 컨테이너로 만들어두면, 매번 서버를 직접 설정하지 않아도 동일한 테스트 환경을 빠르게 실행할 수 있다. 이를 통해 개발 환경과 테스트 환경의 차이를 줄이고, 테스트 자동화(Test Automation)를 더 효율적으로 수행할 수 있다.

정리하면, 도커는 컨테이너(Container)를 이용해 개발, 빌드, 테스트, 운영 환경을 일관되게 구성할 수 있도록 돕는 도구이다. 테스트 환경 준비 자동화(Test Environment Preparation Automation)에서도 도커를 활용하면 환경 구성의 실수를 줄이고, 자원을 효율적으로 사용하며, 반복 가능한 테스트 환경을 만들 수 있다.

테스트 수행 자동화의 개념 (Concept of Test Execution Automation)

이번 챕터에서는 테스트 자동화(Test Automation) 중 실제 테스트를 실행하는 단계인 테스트 수행 자동화(Test Execution Automation)를 살펴본다.

테스트 수행 자동화란 이미 설계된 테스트 케이스(Test Case)를 실행하고, 테스트 결과(Test Result)를 판정하며, 결과를 기록하거나 보고하는 과정에서 반복적이고 실수가 발생하기 쉬운 작업을 도구(Tool)를 활용해 자동화하는 것을 의미한다.

ISO/IEC/IEEE 29119 표준의 동적 테스트 프로세스(Dynamic Test Process)를 기준으로 보면, 테스트 수행 자동화의 주요 대상은 테스트 수행(Test Execution)과 테스트 결과 보고(Test Result Reporting) 단계이다. 즉, 테스트를 실제로 실행하고 그 결과를 확인·기록·보고하는 부분이 자동화 대상이 된다.

다만 테스트 수행 자동화가 제대로 이루어지기 위해서는 그 전에 테스트 설계(Test Design)와 테스트 환경 구성(Test Environment Set-up)이 적절하게 준비되어 있어야 한다. 테스트 케이스가 명확하지 않거나 테스트 환경이 불안정하면, 자동화된 테스트 수행도 신뢰하기 어렵기 때문이다.

정리하면, 테스트 수행 자동화는 준비된 테스트 케이스를 도구를 통해 반복 실행하고, 기대 결과(Expected Result)와 실제 결과(Actual Result)를 비교하며, 테스트 결과를 체계적으로 기록하는 과정이다. 이를 통해 테스트 수행 과정의 시간과 실수를 줄이고, 반복 테스트를 더 일관되게 수행할 수 있다.

Selenium IDE를 활용한 회원가입 웹페이지 반복 테스트

(Repeated Web Page Testing with Selenium IDE)

이번 예시는 회원가입 웹페이지(Sign-up Web Page)를 대상으로 Selenium IDE를 적용해 테스트 수행을 자동화하는 과정이다. Selenium IDE는 웹 애플리케이션(Web Application)의 동작을 녹화하고 재실행할 수 있는 테스트 자동화 도구(Test Automation Tool)이다.

테스터가 직접 웹페이지에서 아이디를 입력하고, 도메인을 선택하거나 입력하고, 화면을 클릭하는 과정을 Selenium IDE로 녹화하면, 이후 같은 절차를 반복 실행할 수 있다. 즉 사람이 매번 같은 테스트 절차를 수행하지 않아도, 녹화된 테스트 시나리오(Test Scenario)를 도구가 대신 실행할 수 있다.

예시에서는 위메프 회원가입 화면의 이메일 ID 입력 기능을 테스트 대상으로 한다. 전체 회원가입 기능이 아니라, 이메일 ID와 도메인 입력이 정상적으로 처리되는지만 확인한다.

테스트 케이스명(Test Case Name)은 “이메일 ID 입력 정상”이다. 시나리오는 먼저 이메일 ID 입력 영역을 클릭하고, 이메일 ID에 cuk을 입력한다. 그다음 @ 기호 다음의 도메인 영역을 클릭하면, 아직 도메인이 입력되지 않았기 때문에 “이메일 형식을 다시 확인해 주세요.”라는 빨간 메시지가 표시되어야 한다.

이후 사용자가 도메인 영역을 다시 클릭하고 cuk.edu를 입력한 뒤, 회원가입 페이지의 빈 영역을 클릭하면 더 이상 이메일 형식 오류 메시지가 표시되지 않아야 한다. 즉 올바른 이메일 형식인 cuk@cuk.edu가 완성되었기 때문에 오류 메시지가 사라지는 것이 정상적인 예상 결과(Expected Result)이다.

이 테스트의 입력값(Input Value)은 이메일 ID인 cuk과 도메인인 cuk.edu이다. 예상 결과는 이메일 형식이 정상적으로 입력되었을 때 아무 오류 메시지도 표시되지 않는 것이다.

정리하면, 이 예시는 사람이 직접 반복해야 하는 회원가입 입력 절차를 Selenium IDE로 녹화하고 재실행하여 테스트 수행 자동화(Test Execution Automation)를 적용하는 사례이다. 간단한 이메일 입력 테스트처럼 보이지만, 실제로는 클릭, 입력, 오류 메시지 확인, 재입력, 결과 확인이라는 여러 단계가 필요하기 때문에 자동화의 효과를 확인하기 좋은 예시이다.

📌Selenium IDE 설치 관련 변경 사항

(Change in Selenium IDE Installation)

강의 예시에서는 크롬 브라우저(Chrome Browser)에서 Selenium IDE를 설치하고, 회원가입 웹페이지의 테스트 과정을 녹화하여 반복 실행하는 방식으로 설명한다.

하지만 현재 공지에 따르면 크롬 웹스토어(Chrome Web Store)에서 Selenium IDE가 정상적으로 지원되지 않아, 강의와 동일한 방식으로 직접 설치하고 실행하기는 어렵다. 따라서 해당 실습은 실제 설치보다는 녹화 영상을 참고하여 Selenium IDE의 동작 방식과 테스트 수행 자동화(Test Execution Automation)의 개념을 이해하는 데 초점을 두면 된다.

대신 Selenium IDE와 유사하게 웹 브라우저에서 사용자의 동작을 녹화하고 재생할 수 있는 대체 도구로 Katalon Recorder를 사용할 수 있다. Katalon Recorder도 웹 애플리케이션(Web Application)의 클릭, 입력, 검증 과정을 기록하고 반복 실행하는 데 활용할 수 있으므로, Selenium IDE 실습의 대안으로 적절하다.

정리하면, 이 예시는 특정 도구 설치 자체보다 웹 테스트 과정을 녹화(Record)하고 재생(Playback)하여 반복 테스트를 자동화하는 개념을 이해하는 것이 핵심이다. Selenium IDE를 직접 사용하기 어렵다면 Katalon Recorder와 같은 대체 도구를 통해 비슷한 방식의 테스트 수행 자동화를 경험할 수 있다.

1️⃣ Overview of Memory Management and Address Structure

메모리 관리 (Memory Management)

이번 주차에는 메모리 관리(Memory Management)에 대해 알아본다. 프로세스(Process)가 실행되기 위해서는 반드시 메모리(Memory)가 필요하다. 여러 프로세스가 동시에 실행될 때는 이 메모리를 효율적으로 나누고 보호하는 것이 중요하다. 따라서 이번 시간에는 운영체제(Operating System)가 메모리를 어떻게 관리하는지 공부한다.

이번 주차의 목표는 먼저 메모리 관리의 필요성과 메모리가 수행하는 역할을 이해하는 것이다. 또한 논리 주소(Logical Address)와 물리 주소(Physical Address)의 차이를 설명할 수 있어야 한다.

이어서 연속 메모리 할당 방식(Contiguous Memory Allocation)의 구조를 이해하고, 분할 방식(Partitioning)의 특징을 살펴본다. 또한 메모리 배치 전략(Memory Placement Strategy)과 단편화(Fragmentation) 문제가 무엇인지 설명할 수 있어야 한다.

마지막으로 비연속 메모리 할당 방식(Non-Contiguous Memory Allocation)의 개념을 이해한다. 특히 페이징(Paging)과 세그멘테이션(Segmentation)의 구조, 그리고 주소 변환(Address Translation) 과정이 어떻게 이루어지는지 살펴본다.

즉, 이번 주차에서는 메모리의 기본 개념을 이해하고, 다양한 메모리 할당 방식을 학습한 뒤, 주소 변환이 이루어지는 과정까지 차례대로 살펴볼 예정이다.

❓메모리 관리의 필요성 (Need for Memory Management)

메모리 관리(Memory Management)의 필요성에 대해 생각해보자. 한 컴퓨터에서 여러 프로그램이 동시에 실행된다고 가정하면, 각 프로그램이 실행되기 위해서는 메모리에 적재되어야 한다.

그런데 운영체제(Operating System)가 메모리를 따로 관리하지 않고 프로그램들이 자유롭게 사용한다면 어떤 일이 발생할까? 서로 다른 프로그램이 같은 메모리 영역(Memory Area)을 사용하게 되면 데이터(Data)가 덮어써지거나 다른 프로그램의 영역을 침범하는 문제가 발생할 수 있다.

이로 인해 프로그램이 비정상적으로 동작하거나, 심한 경우에는 시스템 전체에 오류가 발생할 수 있다. 즉, 이 질문은 메모리를 안전하게 보호하고 관리해야 할 필요성을 이해하게 해주는 질문이다.

❓메모리 주소와 주소 연결 (Memory Address and Address Mapping)

다음 질문을 살펴보자. 프로그램이 실행될 때는 메모리 주소(Memory Address)를 이용해서 데이터를 읽고 저장한다. 그렇다면 프로그램이 사용하는 주소가 실제 메모리의 물리적인 위치와 항상 동일할까?

여러 프로그램이 동시에 실행되는 환경에서는 각 프로그램이 사용하는 주소를 그대로 사용할 수 없다. 따라서 물리 주소(Physical Address)와 논리 주소(Logical Address)를 구분할 필요가 있으며, 이 둘을 연결해주는 과정이 필요하다.

운영체제(Operating System)는 프로그램이 사용하는 주소를 실제 메모리의 위치와 연결해주어야 한다. 즉, 프로그램이 바라보는 주소와 실제 메모리상의 위치가 어떻게 대응되는지를 관리해야 한다.

정리하면, 첫 번째 질문은 “왜 메모리 관리(Memory Management)가 필요한가?”에 대한 질문이다. 두 번째 질문은 “주소를 어떻게 연결할 것인가?”에 대한 문제이다. 오늘은 이 두 가지를 중심으로 공부할 예정이다.

메모리 관리의 복잡성과 이중성 (Complexity and Duality of Memory Management)

이번 차시에서는 메모리 관리(Memory Management)의 필요성과 기본 개념을 이해하기 위해, 먼저 메모리가 수행하는 역할과 주소 구조(Address Structure)에 대해 살펴본다.

초기 일괄 처리 시스템(Batch Processing System)을 떠올려보면, 당시에는 한 번에 하나의 작업(Job)만 실행되는 구조였다. 따라서 하나의 프로그램(Program)만 메모리에 올라갔고, 다른 프로그램과 메모리 영역이 겹칠 일이 없었다. 이 때문에 메모리 관리는 비교적 어렵지 않았다.

하지만 현재의 시스템에서는 여러 프로그램이 동시에 실행되며, 이 프로그램들이 함께 메모리에 올라오게 된다. 이렇게 되면 하나의 메모리를 여러 프로그램이 공유하게 되고, 서로 간섭하지 않도록 관리해야 하는 문제가 생긴다. 결국 여러 프로그램이 하나의 메모리를 함께 사용하게 되면서 메모리 관리는 점점 더 복잡해진다.

메모리 관리에는 이중성(Duality)도 존재한다. 각 프로세스(Process)의 입장에서 보면, 자신에게 할당된 메모리를 독립적으로 사용하고 싶어 한다. 즉, 다른 프로세스의 영향을 받지 않고 자기 영역만 안전하게 사용하기를 원한다.

반면 운영체제(Operating System)의 입장에서는 하나의 메모리를 여러 프로세스가 사용할 수 있도록 효율적으로 관리해야 한다. 이 과정에서 각 프로세스는 자신의 메모리가 침범되지 않도록 보호(Protection)를 요구하게 된다.

결국 운영체제는 메모리를 효율적으로 활용해야 하는 동시에, 각 프로세스의 메모리 보호도 함께 보장해야 한다. 메모리 관리는 이러한 두 가지 요구를 동시에 만족시켜야 하는 중요한 역할을 수행한다.

메모리 관리의 이중성 (Duality of Memory Management)

메모리 관리(Memory Management)의 이중성은 메모리를 바라보는 관점이 서로 다르다는 점에서 이해할 수 있다.

먼저 프로세스(Process) 입장에서의 메모리(Memory)는 자신만의 메모리 공간이 따로 존재하는 것처럼 보인다. 각 프로세스는 다른 프로세스와 메모리를 전혀 공유하지 않고, 독립적으로 사용하는 것처럼 인식한다.

반면 메모리 관리자(Memory Manager) 입장에서의 메모리는 여러 프로세스가 나누어 사용하는 구조이다. 운영체제(Operating System)는 메모리를 구분해서 각 프로세스에 할당하고, 필요에 따라 재배치하며 관리한다.

결국 메모리 관리의 핵심은 프로세스에게는 메모리가 독립적으로 보이게 하면서, 실제로는 하나의 메모리를 여러 프로세스가 공유하도록 만드는 것이다.

메모리 관리 작업 (Memory Management Operations)

메모리 관리(Memory Management)에서 실제로 어떤 작업이 이루어지는지 살펴보자.

먼저 실행할 프로그램과 데이터를 메모리로 가져오는 과정이 필요하다. 그리고 메모리에 올라온 프로세스를 어느 위치에 배치할 것인지 결정해야 한다. 또한 메모리가 부족해지면 어떤 프로세스를 내보낼지도 결정해야 한다.

결국 메모리 관리는 가져오기(Fetch), 배치(Placement), 재배치(Replacement)의 과정으로 이루어지며, 이 세 가지를 중심으로 동작한다고 볼 수 있다.

그림을 보면 메모리 관리의 흐름을 한눈에 확인할 수 있다. 먼저 실행할 프로세스는 하드 디스크(Hard Disk)와 같은 보조기억장치(Secondary Storage)에 저장되어 있다가, 필요할 때 메모리로 가져오게 된다. 이렇게 메모리로 가져오는 과정을 가져오기(Fetch)라고 한다.

그다음 메모리로 올라온 프로세스를 어느 위치에 둘 것인지 결정하는 과정을 배치(Placement)라고 한다. 만약 메모리가 부족한 경우에는 이미 메모리에 올라와 있는 프로세스 중 일부를 내보내고, 새로운 프로세스를 넣어야 한다. 이러한 과정을 재배치(Replacement)라고 한다.

이처럼 메모리 관리는 가져오기(Fetch), 배치(Placement), 재배치(Replacement)의 흐름 속에서 이루어진다고 볼 수 있다.

메모리 주소와 주소 공간 (Memory Address and Address Space)

메모리 주소(Memory Address)와 주소 공간(Address Space)의 개념을 조금 더 구체적으로 살펴보자.

메모리(Memory)는 하나의 연속된 주소 공간으로 이루어져 있다. 각 메모리 위치는 서로 다른 고유한 주소(Address)를 가지며, CPU는 이 주소를 이용해 데이터를 읽거나 명령어(Instruction)를 가져온다.

즉, 프로그램(Program)이 실행되는 과정에서는 특정 위치를 직접 지정하기보다, 주소를 기준으로 메모리에 접근한다고 볼 수 있다.

따라서 메모리 주소는 데이터(Data)가 어디에 있는지 구분하고, 해당 위치에 정확하게 접근하기 위한 기준으로 이해할 수 있다.

주소 공간 (Address Space)

프로그램(Program)이 실행될 때 각 프로그램은 자신이 사용할 수 있는 메모리 범위를 가진다. 이 범위 안에서 명령어(Instruction)와 데이터(Data)를 저장하고 접근하게 된다.

여기서 중요한 점은 각 프로세스(Process)가 서로 독립적인 주소 공간(Address Space)을 가진다는 것이다. 즉, 한 프로세스가 사용하는 주소와 다른 프로세스가 사용하는 주소는 서로 분리되어 있다.

이렇게 주소 공간이 분리되어 있기 때문에 여러 프로그램이 동시에 실행되더라도 서로 간섭하지 않고 동작할 수 있다.

논리 주소와 물리 주소 (Logical Address and Physical Address)

앞에서 각 프로세스(Process)가 독립적인 주소 공간(Address Space)을 가진다고 했다. 그렇다면 여기서 한 가지 의문이 생긴다. 프로그램(Program)이 사용하는 주소와 실제 메모리(Memory)의 위치는 과연 같을까?

먼저 프로그램이 사용하는 주소를 논리 주소(Logical Address)라고 한다. 이 주소는 프로그램이 실행되는 과정에서 CPU가 생성하며, 프로그램이 직접 사용하는 주소이다. 즉, 프로그램의 입장에서 사용하는 주소라고 이해할 수 있다.

반면 실제 메모리에 데이터(Data)가 저장되는 물리적인 위치도 따로 존재한다. 이를 물리 주소(Physical Address)라고 한다. 물리 주소는 실제 메모리 하드웨어(Memory Hardware)에서 사용하는 주소이며, 운영체제(Operating System)가 관리하는 대상이라고 볼 수 있다.

결국 프로그램이 사용하는 논리 주소와 실제 메모리의 물리 주소는 서로 다르다. 따라서 이 두 주소를 구분해서 이해하는 것이 중요하다.

논리 주소와 물리 주소의 차이는 그림을 통해 직관적으로 이해할 수 있다. 왼쪽을 보면 각 프로세스가 자신만의 주소 공간을 독립적으로 가지고 있다. 그래서 각 프로세스는 자신의 주소가 연속적으로 구성되어 있는 것처럼 인식한다.

하지만 실제 물리 메모리(Physical Memory)를 보면, 하나의 메모리 공간 안에 여러 프로세스가 섞여 배치되어 있다. 실제 메모리에서는 각 프로세스의 데이터가 반드시 처음부터 끝까지 연속적으로 존재하지 않을 수도 있다.

이때 중요한 점은 논리 주소와 물리 주소가 반드시 1:1로 대응되는 것이 아니라, 서로 다른 위치로 변환되어 연결된다는 것이다. 결국 프로세스 입장에서는 연속된 주소 공간을 사용하는 것처럼 보이지만, 실제로는 운영체제가 주소를 적절히 변환하여 물리 메모리에 배치하고 있다고 이해하면 된다.

주소 변환의 필요성 (Need for Address Translation)

앞서 본 그림처럼 프로그램(Program)은 논리 주소(Logical Address)를 기준으로 메모리(Memory)에 접근하지만, 실제 메모리는 물리 주소(Physical Address)를 기준으로 동작한다.

즉, 프로그램이 사용하는 주소와 실제 메모리가 사용하는 주소가 서로 다르기 때문에, 이 둘을 연결해주는 과정이 필요하다. 이 과정을 주소 변환(Address Translation)이라고 볼 수 있다.

또한 중요한 문제는 이 주소를 언제 실제 물리적 위치와 연결할 것인지이다. 논리 주소와 물리 주소를 연결하는 것뿐만 아니라, 그 연결이 이루어지는 시점도 함께 결정해야 한다.

결국 주소 변환에서 중요한 핵심은 논리 주소와 물리 주소를 연결하는 것, 그리고 그 연결 시점을 결정하는 것이라고 할 수 있다.

주소 바인딩 방식 (Address Binding Methods)

다음은 주소를 실제 메모리 위치에 언제 연결할 것인지에 따라 주소 바인딩(Address Binding) 방식을 나누어 살펴본다.

주소 바인딩은 크게 세 가지로 구분된다. 첫 번째는 컴파일 시간 바인딩(Compile-Time Binding)이다. 이는 프로그램을 컴파일(Compile)하는 시점에 이미 물리 주소(Physical Address)가 결정되는 방식이다.

두 번째는 적재 시간 바인딩(Load-Time Binding)이다. 이는 프로그램이 메모리(Memory)에 적재될 때 주소가 결정되는 방식이다.

세 번째는 실행 시간 바인딩(Execution-Time Binding)이다. 이는 프로그램이 실행되는 동안 주소 변환(Address Translation)이 이루어지는 방식이다. 이처럼 주소를 연결하는 시점에 따라 각기 다른 바인딩 방식이 존재한다.

그림을 보면 주소 바인딩이 실제로 어떻게 이루어지는지 이해할 수 있다. 먼저 컴파일 단계(Compile Stage)에서는 원시 코드(Source Code)가 컴파일러(Compiler)를 거쳐 목적 파일(Object File)로 변환된다. 이 단계에서는 프로그램이 사용할 주소가 어느 정도 결정되는 과정이 이루어진다.

다음 적재 단계(Load Stage)에서는 여러 라이브러리(Library)와 목적 파일(Object File)이 링커(Linker)를 통해 하나로 연결된다. 이후 로더(Loader)에 의해 메모리에 적재되며, 이 과정에서 실제 메모리에 올라갈 위치가 결정된다.

마지막 실행 단계(Execution Stage)에서는 프로그램이 메모리에 올라간 이후에도 필요에 따라 주소 변환이 계속 이루어진다. 즉, 실행 중에도 주소가 동적으로 연결되는 방식이라고 볼 수 있다.

이처럼 주소 바인딩은 컴파일(Compile), 적재(Load), 실행(Execution)의 흐름 속에서 단계적으로 이루어진다고 이해할 수 있다.

실행 시간 주소 바인딩 (Execution-Time Address Binding)

주소 바인딩(Address Binding)은 컴파일 시점(Compile Time), 적재 시점(Load Time), 실행 시점(Execution Time)으로 나누어 이루어진다. 이 중에서 특히 중요한 것이 실행 시간 바인딩(Execution-Time Binding)이다.

앞에서 프로그램(Program)이 실행되는 동안에도 주소 변환(Address Translation)이 계속 이루어진다고 했다. 실행 시간 바인딩 방식에서는 프로그램이 메모리(Memory)의 고정된 위치에 묶여 있지 않아도 실행될 수 있다. 즉, 메모리의 어느 위치에 올라가더라도 문제없이 동작할 수 있다.

또한 실행 중에도 필요에 따라 프로세스(Process)의 위치를 다른 곳으로 이동시킬 수 있다. 따라서 실행 시간 바인딩은 메모리를 보다 유연하게 사용할 수 있도록 해주는 방식이라고 볼 수 있다.

MMU (Memory Management Unit)

지금까지 주소 바인딩(Address Binding)이 이루어지는 과정을 살펴보았다. 이제 이렇게 결정된 주소가 실제 실행 과정에서 어떻게 변환되는지 생각해볼 필요가 있다. 이 역할을 수행하는 장치가 바로 MMU(Memory Management Unit)이다.

MMU는 논리 주소(Logical Address)를 물리 주소(Physical Address)로 변환해주는 하드웨어 장치이다. CPU가 생성한 논리 주소를 입력으로 받아, 실제 메모리(Memory)에서 사용되는 물리 주소로 바꿔준다.

이 장치는 CPU 내부 또는 CPU 패키지(CPU Package)에 포함되어 있으며, 프로그램(Program)이 메모리를 사용할 때마다 주소 변환(Address Translation)을 담당한다.

따라서 MMU는 논리 주소를 물리 주소로 변환해주면서, 각 프로세스(Process)가 독립적인 메모리를 사용하는 것처럼 보이도록 만들어주는 역할을 한다.

MMU의 역할 (Role of MMU)

이 그림은 MMU(Memory Management Unit)가 어떤 역할을 하는지 보여준다. 프로세스(Process)에서 생성된 논리 주소(Logical Address)가 MMU로 전달되면, MMU는 이 주소를 변환하여 물리 주소(Physical Address)로 바꿔준다.

그다음 변환된 물리 주소를 기준으로 실제 메모리(Memory)에 대한 접근이 이루어진다. 즉, 프로세스가 사용하는 논리 주소가 바로 메모리에 접근하는 것이 아니라, MMU를 거쳐 물리 주소로 변환된 뒤 실제 메모리에 접근하게 된다.

이 과정에서 MMU는 고정 분할(Fixed Partitioning), 동적 분할(Dynamic Partitioning), 페이징(Paging), 세그멘테이션(Segmentation)과 같은 다양한 메모리 관리 기법(Memory Management Techniques)을 기반으로 주소 변환(Address Translation)을 수행한다.

결국 중요한 점은 이러한 기법들이 서로 다른 방식으로 구현될 뿐, MMU가 수행하는 핵심 역할은 논리 주소(Logical Address)를 물리 주소(Physical Address)로 변환하는 것이라는 점이다.

메모리 보호의 필요성 (Need for Memory Protection)

여러 프로세스(Process)가 하나의 물리 메모리(Physical Memory)를 함께 사용하는 환경을 떠올려보자. 이때 잘못된 주소(Address)로 접근하게 되면 다른 프로세스의 데이터(Data)를 침범할 수 있다.

또한 사용자 프로그램(User Program)이 운영체제(Operating System)의 영역까지 접근하게 되면, 시스템(System) 자체가 손상될 위험도 존재한다. 이러한 오류는 단순히 하나의 프로그램에서 끝나는 것이 아니라, 시스템 전체의 오류로 확산될 수도 있다.

따라서 운영체제는 이러한 문제를 방지하기 위해 메모리 보호(Memory Protection) 기능을 반드시 제공해야 한다.

메모리 보호와 기준 레지스터 (Memory Protection and Base Register)

메모리 보호(Memory Protection)를 구현하기 위한 방법 중 하나가 기준 레지스터(Base Register)이다. 기준 레지스터는 베이스 레지스터(Base Register)라고도 하며, 프로세스(Process)가 사용할 수 있는 메모리(Memory)의 시작 주소를 저장하는 역할을 한다.

프로그램(Program)이 사용하는 논리 주소(Logical Address)에 기준 레지스터의 값, 즉 베이스 값(Base Value)을 더하면 물리 주소(Physical Address)가 만들어진다. 각 프로세스마다 서로 다른 베이스 값을 가지도록 설정하기 때문에, 각 프로세스는 서로 다른 메모리 영역(Memory Area)을 사용하게 된다.

결국 기준 레지스터는 논리 주소를 물리 주소로 변환할 때 기준이 되는 값을 제공하는 역할을 한다고 볼 수 있다.

그림을 통해 기준 레지스터를 이용한 주소 변환(Address Translation) 과정을 확인할 수 있다. 예를 들어 프로세스에서 생성된 논리 주소가 346이고, 기준 레지스터에 저장된 값이 1400이라면 두 값을 더해 1746이라는 물리 주소가 만들어진다.

이렇게 생성된 물리 주소를 기준으로 실제 메모리에 접근하게 된다. 이처럼 논리 주소에 기준값을 더해 물리 주소를 생성하는 방식이 기준 레지스터 방식이다.

경계 레지스터를 이용한 메모리 보호 (Memory Protection with Limit Register)

기준 레지스터(Base Register)와 함께 사용되는 것이 경계 레지스터(Limit Register)이다. 경계 레지스터는 프로세스(Process)가 사용할 수 있는 메모리(Memory)의 크기, 즉 허용된 범위(Limit)를 저장한다.

이때 CPU가 생성한 논리 주소(Logical Address)가 허용된 범위를 초과하는지 MMU(Memory Management Unit)와 같은 하드웨어가 검사한다. 만약 프로세스가 허용된 범위를 벗어난 주소로 접근하려고 하면, 해당 접근은 차단된다.

이렇게 해서 프로세스가 자신에게 할당된 메모리 영역(Memory Area)을 넘어가지 못하도록 보호할 수 있다.

그림을 통해 경계 레지스터가 어떻게 메모리를 보호하는지 살펴볼 수 있다. 경계 레지스터에는 프로세스가 접근할 수 있는 메모리의 범위가 저장되어 있다. 그러면 CPU가 생성한 논리 주소가 이 범위를 벗어나는지 MMU가 검사하게 된다.

그림에서 운영체제 영역(Operating System Area)은 상위 주소 영역에 위치하고, 사용자 프로그램 영역(User Program Area)은 아래쪽 영역만 사용하도록 제한되어 있다. 따라서 프로그램이 허용된 범위를 벗어나 운영체제 영역에 접근하려고 하면, 해당 접근은 차단된다.

즉, 경계 레지스터는 사용자 프로그램(User Program)이 운영체제 영역을 침범하지 못하도록 보호하는 역할을 한다.

메모리 보호 동작 과정 (Memory Protection Operation)

메모리 보호(Memory Protection)가 실제로 동작하는 흐름을 살펴보자.

먼저 CPU가 생성한 논리 주소(Logical Address)가 MMU(Memory Management Unit)로 전달된다. MMU는 이 논리 주소가 허용된 범위, 즉 경계값(Limit Value) 안에 있는지 검사한다.

만약 논리 주소가 허용된 범위 안에 있다면, 기준값(Base Value)을 더해 물리 주소(Physical Address)를 생성한다. 반대로 논리 주소가 허용된 범위를 초과하면 예외(Exception)가 발생하고, 이때 운영체제(Operating System)가 개입하게 된다.

즉, 모든 메모리 접근 과정에서는 하드웨어 수준에서 보호 검사(Protection Check)가 수행된다고 이해할 수 있다.

그림을 통해 메모리 보호가 실제로 어떻게 이루어지는지 구체적으로 살펴보자. 먼저 각 프로세스(Process)마다 기준 레지스터(Base Register)와 경계 레지스터(Limit Register) 값이 설정되어 있다. 기준 레지스터는 시작 주소(Start Address)를 의미하고, 경계 레지스터는 사용할 수 있는 범위(Limit)를 의미한다.

이를 바탕으로 실제 동작 순서를 보면, 프로세스가 생성한 논리 주소가 먼저 허용된 범위 안에 있는지 검사된다. 즉, 이 주소가 경계 레지스터 값보다 작은지를 MMU가 먼저 확인한다.

이 조건을 만족하는 경우에만 그다음 기준 레지스터 값을 더해 물리 주소를 생성한다. 따라서 메모리 보호 과정은 먼저 범위를 검사하고, 그다음 주소 변환(Address Translation)을 수행하는 순서로 이루어진다고 볼 수 있다.

반대로 논리 주소가 허용된 범위를 벗어나면 트랩(Trap)이 발생한다. 이 경우 주소 지정 오류(Addressing Error)로 처리되며, 운영체제가 개입하게 된다.

이처럼 기준 레지스터와 경계 레지스터를 이용하면, 각 프로세스가 자신에게 허용된 범위 안에서만 메모리를 사용하도록 제어할 수 있다.

메모리 보호 예제 (Memory Protection Example)

하나의 예제를 통해 메모리 보호(Memory Protection)가 어떻게 동작하는지 확인해보자.

어떤 프로세스(Process)의 기준값(Base Value)이 1000이고, 경계값(Limit Value)이 500이라고 가정한다. 여기서 중요한 점은 경계값이 마지막 주소값이 아니라, 프로세스가 사용할 수 있는 메모리의 크기(Memory Size)를 의미한다는 것이다.

따라서 해당 프로세스가 실제로 접근할 수 있는 물리 주소(Physical Address)의 범위는 1000부터 1499까지가 된다.

이때 논리 주소(Logical Address)가 200이라면, 이 값은 경계값의 범위 안에 있다. 따라서 기준 레지스터(Base Register)의 값이 더해져 물리 주소 1200으로 변환되고, 정상적으로 메모리에 접근할 수 있다.

반대로 논리 주소가 600이라면, 이 값은 경계값을 초과한다. 따라서 접근이 차단되고 예외(Exception)가 발생한다. 이 경우 프로그램(Program)이 강제로 종료되거나, 운영체제(Operating System)가 개입하여 처리하게 된다.

지금까지 메모리 관리(Memory Management)의 기본 개념과 주소 변환(Address Translation), 그리고 메모리 보호 방법까지 살펴보았다. 다음에는 이러한 개념을 바탕으로 실제 메모리 할당 방식(Memory Allocation Methods)에 대해 살펴볼 예정이다.

2️⃣ Contiguous memory allocation method

연속 메모리 할당 방식 (Contiguous Memory Allocation)

이번에는 메모리(Memory)를 실제로 어떤 방식으로 나누어 사용하는지 살펴보기 위해, 연속 메모리 할당 방식(Contiguous Memory Allocation)에 대해 알아본다.

앞에서 프로세스(Process)가 실행되기 위해서는 반드시 메모리에 적재되어야 한다고 배웠다. 메모리를 할당하는 방식은 크게 두 가지로 나눌 수 있는데, 연속 메모리 할당(Contiguous Memory Allocation)과 불연속 메모리 할당(Non-Contiguous Memory Allocation)이다.

먼저 살펴볼 연속 메모리 할당 방식은 프로세스를 하나의 연속된 공간에 적재하는 방식이다.

그림을 통해 메모리 할당 방식의 전체 구조를 정리해보자. 메모리 할당 방식은 크게 연속 메모리 할당 방식과 불연속 메모리 할당 방식으로 나뉜다.

연속 메모리 할당 방식은 하나의 프로세스를 메모리의 연속된 공간에 배치하는 방식이다. 반면 불연속 메모리 할당 방식은 하나의 프로세스를 여러 개의 분산된 공간에 나누어 배치하는 방식이다.

이 중에서 지금부터는 연속 메모리 할당 방식에 해당하는 방법들을 살펴본다.

단일 프로그래밍 방식 (Single Programming)

먼저 가장 단순한 형태인 단일 프로그래밍(Single Programming) 방식에 대해 살펴본다. 단일 프로그래밍 방식은 한 번에 하나의 프로그램(Program)만 메모리(Memory)에 적재해서 실행하는 방식이다. 따라서 메모리는 운영체제(Operating System)와 사용자 프로그램(User Program)이 나누어 사용하는 구조를 가진다.

하지만 이 방식에서는 프로그램이 입출력(I/O) 작업을 수행하는 동안 CPU가 아무 작업도 하지 못하고 대기 상태(Waiting State)가 될 수 있다. 따라서 단일 프로그래밍 구조는 매우 단순하지만, 전체 자원 활용(Resource Utilization) 효율은 낮은 방식이라고 볼 수 있다.

다음으로 단일 프로그램의 메모리 구조(Memory Structure)를 살펴보면, 메모리가 어떻게 나뉘어 사용되는지 확인할 수 있다. 메모리는 크게 운영체제 영역(Operating System Area)과 사용자 영역(User Area)으로 구분된다.

운영체제 영역에는 시스템 코드(System Code)와 핵심 기능이 저장되고, 사용자 영역에는 실제 실행 중인 프로그램이 올라오게 된다. 여기서 중요한 점은 사용자 프로그램이 운영체제 영역에 접근하지 못하도록 보호된다는 것이다.

이러한 구조를 통해 단일 프로그램 환경에서는 하나의 프로그램이 메모리를 독점적으로 사용하면서 안정적으로 실행될 수 있게 된다.

단일 프로그램의 메모리 적재 과정 (Memory Loading in Single Programming)

단일 프로그램(Single Program) 환경에서 프로그램(Program)이 메모리(Memory)에 올라오는 과정을 살펴보자.

사용자 프로그램(User Program)은 메모리의 사용자 영역(User Area)에 적재된다. 프로그램은 실행될 때마다 디스크(Disk)와 같은 보조기억장치(Secondary Storage)에서 메모리로 올라오게 된다.

새로운 프로그램을 실행하면 기존에 실행되던 프로그램은 메모리에서 제거되고, 새로운 프로그램이 다시 적재된다. 즉, 단일 프로그램 환경은 한 번에 하나의 프로그램만 메모리를 사용하는 구조라고 볼 수 있다.

다중 프로그래밍의 필요성 (Need for Multiprogramming)

연속 메모리 할당 방식(Contiguous Memory Allocation)에서 다중 프로그래밍(Multiprogramming)이 왜 필요한지 살펴보자.

단일 프로그램 환경(Single Program Environment)에서는 한 번에 하나의 프로그램(Program)만 실행된다. 따라서 프로그램이 입출력(I/O) 작업을 수행하는 동안에는 CPU가 아무 일도 하지 않고 대기하게 된다.

이로 인해 CPU와 메모리(Memory) 자원이 비효율적으로 사용된다. 따라서 여러 프로그램을 동시에 실행하여 **자원 활용률(Resource Utilization)**을 높일 필요가 있다.

이러한 요구를 해결하기 위해 고정 분할 방식(Fixed Partitioning)과 같은 메모리 할당 방식(Memory Allocation Method)이 사용된다.

고정 분할 방식 (Fixed Partitioning)

고정 분할 방식(Fixed Partitioning)은 운영체제(Operating System)가 메모리(Memory)를 여러 개의 고정된 크기 영역으로 나누어 관리하는 방식이다.

각 영역에는 하나의 프로그램(Program)만 적재되며, 이를 통해 여러 프로그램이 동시에 실행될 수 있는 구조가 만들어진다. 이때 분할 영역(Partition)의 크기는 미리 고정되어 있기 때문에 실행 중에는 변경되지 않는다.

따라서 고정 분할 방식은 구조가 단순하다는 장점이 있지만, 메모리를 유연하게 활용하기에는 한계가 있다.

그림을 통해 고정 분할 방식이 어떻게 동작하는지 살펴보자. 운영체제는 메모리를 미리 여러 개의 고정된 영역으로 나누고, 각 영역에 하나의 프로그램을 할당한다.

그림에서 A, B, C 와 같은 각 영역에 프로그램이 하나씩 올라와 있는 것을 볼 수 있다. 각 영역은 독립적으로 사용되기 때문에 여러 프로그램을 동시에 실행할 수 있다.

하지만 각 영역의 크기가 고정되어 있으므로, 프로그램의 크기에 따라 사용되지 않는 남는 공간이 발생할 수 있다는 점도 함께 고려해야 한다.

내부 단편화 (Internal Fragmentation)

분할 내부에 사용되지 않고 남는 공간을 내부 단편화(Internal Fragmentation)라고 한다. 내부 단편화는 프로세스(Process)의 크기가 분할된 영역(Partition)의 크기보다 작을 때 발생한다.

이때 남은 공간은 다른 프로세스가 사용할 수 없기 때문에, 결과적으로 메모리(Memory) 낭비가 발생하게 된다.

그림을 통해 내부 단편화가 실제로 어떻게 나타나는지 살펴보자. 오른쪽을 보면 메모리가 모두 20KB 크기의 고정된 영역으로 나뉘어 있다. 각 영역에는 하나의 프로세스가 할당된다.

그런데 왼쪽의 프로세스들을 보면 각각의 크기가 40KB, 18KB, 30KB, 17KB처럼 분할 크기와 정확히 맞지 않는다. 예를 들어 크기가 18KB인 프로세스 B(Process B)는 20KB짜리 하나의 영역에 적재되지만, 2KB의 공간이 남게 된다. 17KB인 프로세스 D(Process D)도 20KB짜리 하나의 영역을 사용하면서 3KB의 공간이 사용되지 않고 남게 된다.

이처럼 고정된 크기의 분할에 맞추어 프로세스를 적재하다 보면, 각 분할 내부에 사용되지 않는 공간이 발생한다. 이 남는 공간을 내부 단편화라고 이해할 수 있다.

가변 분할 방식과 외부 단편화 (Variable Partitioning and External Fragmentation)

앞서 고정 분할 방식(Fixed Partitioning)에서는 분할 크기(Partition Size)가 고정되어 있기 때문에 내부 단편화(Internal Fragmentation)가 발생한다고 배웠다. 이러한 문제를 해결하기 위한 방식이 가변 분할 방식(Variable Partitioning)이다.

가변 분할 방식에서는 프로세스(Process)의 크기에 맞게 메모리(Memory)를 연속된 공간으로 동적으로 할당한다. 즉, 메모리를 미리 고정된 크기로 나누는 것이 아니라, 필요할 때마다 적절한 크기로 나누어 사용한다. 따라서 필요한 만큼만 메모리를 할당할 수 있고, 그만큼 메모리 낭비를 줄일 수 있다.

가변 분할 방식에서는 프로세스 크기에 맞는 연속된 빈 공간을 찾아 그 위치에 프로세스를 적재한다. 고정된 크기로 나누어놓은 공간을 사용하는 것이 아니라, 필요한 크기만큼 공간을 할당하는 방식이다. 실행 중이던 프로세스가 종료되면 해당 위치에는 다시 빈 공간이 생긴다. 이렇게 메모리 안에 빈 공간이 생성되면, 또 다른 프로세스가 그 공간을 사용할 수 있다.

그림을 통해 가변 분할 방식에서 메모리가 어떻게 변화하는지 살펴보자. 프로세스들은 각자의 크기에 맞게 연속된 공간에 적재된다. 그런데 일부 프로세스가 종료되면 그 위치에는 빈 공간이 생긴다.

이때 빈 공간들이 메모리 중간중간에 끊어진 형태로 남게 된다. 이처럼 연속되지 않는 작은 빈 공간이 여러 개로 나뉘어 발생하는 현상을 외부 단편화(External Fragmentation)라고 한다.

즉, 전체적으로는 여유 공간이 충분하더라도 연속된 공간이 부족하면 새로운 프로세스를 적재하지 못하는 문제가 발생할 수 있다.

외부 단편화와 메모리 압축 (External Fragmentation and Memory Compaction)

앞서 그림에서 확인했듯이, 프로세스(Process)의 생성과 종료가 반복되면 빈 공간(Free Space)이 메모리(Memory)의 여러 위치에 분산되어 생기게 된다.

이렇게 연속되지 않는 빈 공간들이 많아지면, 전체 여유 공간은 충분하더라도 연속된 공간이 부족해서 새로운 프로세스를 적재하기 어려워질 수 있다. 이러한 현상을 외부 단편화(External Fragmentation)라고 한다.

결과적으로 외부 단편화가 발생하면 메모리 활용 효율(Memory Utilization)이 저하된다. 이 문제를 해결하기 위해 메모리 재배치(Memory Relocation), 즉 압축(Compaction)이 필요할 수 있다.

메모리 압축 (Memory Compaction)

메모리 압축(Memory Compaction)은 분산되어 있는 빈 공간(Free Space)을 하나의 연속된 공간으로 합치는 방식이다. 이를 위해 프로세스(Process)들을 한쪽으로 이동시켜 흩어져 있는 빈 공간을 하나로 모은다.

이렇게 하면 외부 단편화(External Fragmentation) 문제를 완화할 수 있다. 하지만 프로세스를 이동시키는 과정에서 추가적인 오버헤드(Overhead)가 발생할 수 있다.

그림을 통해 메모리 압축이 어떻게 이루어지는지 살펴보자. 왼쪽을 보면 프로세스들 사이에 빈 공간이 여러 군데로 나뉘어 있는 것을 확인할 수 있다. 이 상태에서는 전체 여유 공간이 충분하더라도 연속된 공간이 부족하기 때문에 새로운 프로세스를 적재하기 어려울 수 있다.

이러한 문제를 해결하기 위해 압축을 수행한다. 프로세스들을 한쪽으로 이동시켜 흩어져 있던 빈 공간을 하나의 연속된 공간으로 모으는 것이다.

오른쪽 그림을 보면 압축이 수행된 후 하나의 큰 빈 공간이 만들어진 것을 확인할 수 있다. 이처럼 메모리 압축을 통해 외부 단편화 문제를 해결할 수 있지만, 프로세스를 이동하는 과정에서 오버헤드가 발생할 수 있다는 점도 함께 고려해야 한다.

메모리 통합 (Memory Coalescing)

연속 메모리 할당 방식(Contiguous Memory Allocation)에서 외부 단편화(External Fragmentation)를 해결하는 또 다른 방법으로 메모리 통합(Memory Coalescing)이 있다.

메모리 통합은 서로 인접해 있는 빈 공간(Free Space)들을 하나로 합치는 방법이다. 이 방식은 프로세스(Process)를 이동시키지 않고, 빈 공간끼리만 병합(Merge)하기 때문에 압축(Compaction) 방식에 비해 오버헤드(Overhead)가 적다는 특징이 있다.

하지만 메모리 통합은 인접한 빈 공간이 있을 때만 수행될 수 있다. 따라서 외부 단편화를 완전히 해결하기보다는 부분적으로 완화하는 방식이라고 볼 수 있다.

메모리 배치 전략의 필요성

(Need for Memory Placement Strategy)

지금까지 살펴본 것처럼 가변 분할 방식(Variable Partitioning)에서는 프로세스(Process)의 생성과 종료가 반복되면서 빈 공간(Free Space)이 계속 생긴다.

이때 빈 공간을 어떻게 활용하느냐에 따라 메모리 사용 효율(Memory Utilization)이 달라진다. 즉, 프로세스를 어떤 공간에 배치할 것인가에 따라 결과가 달라질 수 있다.

따라서 가변 분할 방식에서는 프로세스를 어떤 기준으로 배치할 것인지가 중요한 문제가 된다.

메모리 배치 전략과 단편화 (Memory Placement Strategy and Fragmentation)

가변 분할 방식(Variable Partitioning)에서는 여러 개의 빈 공간(Free Space) 중에서 프로세스(Process)를 어디에 배치할 것인지 선택해야 한다. 이때 어떤 기준으로 공간을 선택하느냐에 따라 메모리 사용 효율(Memory Utilization)이나 성능(Performance)이 달라질 수 있다.

그래서 다양한 메모리 배치 전략(Memory Placement Strategy)이 존재한다. 대표적인 방식으로는 최초 적합(First Fit), 최적 적합(Best Fit), 최악 적합(Worst Fit)이 있다.

먼저 최초 적합(First Fit) 방식은 메모리의 앞쪽부터 순차적으로 빈 공간을 탐색하다가, 조건을 만족하는 첫 번째 공간에 프로세스를 바로 배치하는 방식이다. 이 방식은 필요한 공간을 찾는 즉시 할당하기 때문에 탐색을 빠르게 끝낼 수 있고, 할당 속도(Allocation Speed)가 빠르다는 특징이 있다.

다만 뒤쪽에 더 적절한 공간이 있더라도 그 공간은 고려하지 않는다. 앞쪽에서 조건을 만족하는 공간을 발견하면 바로 배치하기 때문에, 메모리 앞부분에 작은 빈 공간들이 남을 수 있다는 단점이 있다.

그림을 통해 최초 적합 방식이 어떻게 동작하는지 살펴보자. 현재 13KB 크기의 프로세스가 들어온 상황이라고 가정한다. 이때 메모리의 앞쪽부터 빈 공간을 탐색한다.

가장 먼저 발견된 빈 공간이 16KB라면, 이 공간은 요구 크기인 13KB를 만족한다. 따라서 프로세스는 이 위치에 바로 배치된다. 그 결과 16KB 공간 중 일부만 사용되고, 나머지 공간은 그대로 남게 된다.

이처럼 최초 적합 방식은 조건을 만족하는 첫 번째 공간에 바로 할당하는 방식이다. 따라서 탐색 속도는 빠르지만, 메모리 앞쪽에 작은 빈 공간이 계속 남을 수 있다는 특징을 가진다.

최적 적합 방식 (Best Fit)

이번에는 최적 적합(Best Fit) 방식에 대해 살펴본다. 최적 적합 방식은 메모리(Memory)에 있는 모든 빈 공간(Free Space)을 탐색한 뒤, 요구 크기에 가장 근접한 공간을 선택하는 방식이다. 즉, 프로세스(Process)가 들어갈 수 있는 공간 중에서 가장 작은 적합 공간을 선택한다.

이 방식은 불필요하게 큰 공간을 사용하는 것을 줄일 수 있기 때문에, 공간 낭비를 줄일 수 있다는 특징이 있다.

예를 들어 13KB 크기의 프로세스가 들어온다고 가정해보자. 이때 16KB 공간이 있더라도, 더 근접한 14KB 공간이 있다면 14KB 공간이 선택된다.

다만 최적 적합 방식은 모든 빈 공간을 탐색해야 하기 때문에 탐색 비용(Search Cost)이 크다. 또한 결과적으로 작은 크기의 빈 공간들이 많이 남게 되는 문제가 발생할 수 있다.

그림에서는 현재 13KB 크기의 프로세스가 들어온 상황을 보여준다. 이때 메모리에 존재하는 모든 빈 공간을 확인한다. 그 결과 16KB, 14KB, 5KB, 30KB와 같은 공간들 중에서 요구 크기와 가장 근접한 14KB 공간이 선택된다.

따라서 최초 적합(First Fit) 방식처럼 16KB 공간을 사용하는 것이 아니라, 더 작은 14KB 공간에 배치가 이루어진다.

이처럼 최적 적합 방식은 가장 알맞은 크기의 공간을 선택하기 때문에 공간 낭비를 줄일 수 있다. 하지만 모든 빈 공간을 탐색해야 하므로 탐색 비용이 크고, 작은 크기의 빈 공간이 점점 남게 되는 문제가 발생할 수 있다.

최악 적합 방식 (Worst Fit)

이번에는 최악 적합(Worst Fit) 방식에 대해 살펴본다. 최악 적합 방식은 메모리(Memory)에 있는 빈 공간(Free Space) 중에서 가장 큰 공간을 선택해 프로세스(Process)를 배치하는 방식이다.

예를 들어 13KB 크기의 프로세스가 들어온다고 가정해보자. 이때 14KB나 16KB 공간이 있더라도 해당 공간을 선택하지 않고, 가장 큰 30KB 공간에 프로세스를 배치한다.

이 방식은 큰 공간을 사용한 뒤에도 비교적 큰 여유 공간을 남길 수 있다는 특징이 있다. 하지만 큰 공간이 계속 분할되면서 결과적으로 작은 빈 공간들이 많이 생성될 수 있다는 문제도 있다.

그림에서는 현재 13KB 크기의 프로세스가 들어온 상황을 보여준다. 이때 메모리에 있는 빈 공간들 중 가장 큰 30KB 공간을 선택한다. 16KB나 14KB처럼 더 적절해 보이는 공간이 있더라도 사용하지 않고, 가장 큰 공간에 배치가 이루어진다.

이처럼 최악 적합 방식은 가장 큰 빈 공간을 먼저 사용하면서 상대적으로 큰 여유 공간을 유지하려는 특징이 있다. 그러나 그 큰 공간이 분할되면서 결과적으로 작은 크기의 빈 공간들이 많이 생성될 수 있다.

연속 메모리 할당 방식의 한계 (Limitations of Contiguous Memory Allocation)

지금까지 살펴본 것처럼 연속 메모리 할당 방식(Contiguous Memory Allocation)에서는 메모리(Memory)를 사용하는 과정에서 여러 개의 작은 공간으로 나뉘는 단편화(Fragmentation)가 발생할 수 있다.

이렇게 공간이 나뉘어 있으면 전체적으로는 여유 공간이 충분하더라도, 연속된 공간이 부족해서 메모리를 사용할 수 없는 경우가 생긴다. 그 결과 메모리 활용 효율(Memory Utilization)이 떨어지게 된다.

연속 메모리 할당 방식에서 단편화는 두 가지 형태로 나타난다. 먼저 내부 단편화(Internal Fragmentation)는 할당된 공간 내부에서 사용되지 않고 남는 공간이 발생하는 경우이다. 반면 외부 단편화(External Fragmentation)는 빈 공간이 여러 조각으로 나뉘어 흩어져 존재하는 경우이다.

이처럼 내부 단편화와 외부 단편화가 발생하면, 사용할 수 있는 메모리 공간이 충분하더라도 연속된 공간을 확보하기 어려워질 수 있다. 따라서 경우에 따라서는 메모리를 다시 정리해주는 작업이 필요하다. 하지만 이 과정에서도 추가적인 비용(Cost)이 발생한다.

결국 이러한 구조적인 한계를 해결하기 위해서는 연속된 공간에만 의존하지 않는 방식이 필요하다. 다음 시간에는 비연속 메모리 할당 방식(Non-Contiguous Memory Allocation)에 대해 알아볼 예정이다.

3️⃣ Non-contiguous memory allocation method

비연속 메모리 할당 방식 (Non-Contiguous Memory Allocation)

지금부터는 비연속 메모리 할당 방식(Non-Contiguous Memory Allocation)이 어떻게 이루어지는지 살펴본다.

앞서 연속 메모리 할당 방식(Contiguous Memory Allocation)의 구조와 한계를 공부했다면, 이번에는 그 문제를 해결하기 위한 비연속 메모리 할당 방식이 어떻게 작동하는지 알아볼 예정이다.

비연속 메모리 할당 방식은 프로세스(Process)를 하나의 연속된 공간에 배치하는 것이 아니라, 여러 개의 떨어진 공간에 나누어 배치하는 방식이다. 그리고 이렇게 분산된 공간을 하나의 연속된 공간처럼 사용할 수 있도록 관리한다.

결국 비연속 메모리 할당 방식은 연속 메모리 할당 방식에서 발생했던 단편화 문제(Fragmentation Problem)를 해결하기 위해 도입된 방식이라고 볼 수 있다.

페이징 (Paging)

그럼 비연속 메모리 할당 방식(Non-Contiguous Memory Allocation)이 어떤 방식으로 구현되는지 살펴보자. 먼저 페이징(Paging)의 개념에 대해 알아본다.

페이징은 프로세스(Process)를 하나의 연속된 공간으로 사용하는 것이 아니라, 동일한 크기의 페이지(Page) 단위로 나누어 관리하는 방식이다. 메모리(Memory) 역시 동일한 크기의 프레임(Frame) 단위로 나누어 사용한다.

이렇게 나누어진 페이지들은 서로 다른 프레임에 자유롭게 배치될 수 있다. 따라서 프로세스가 실제 메모리 안에서 여러 위치에 분산되어 있더라도, 하나의 연속된 공간처럼 사용할 수 있게 된다.

그림을 통해 페이징 방식이 어떻게 동작하는지 살펴보자. 프로세스는 페이지 단위로 나뉘고, 각 페이지는 메모리의 서로 다른 위치에 있는 프레임에 적재된다. 즉, 하나의 프로세스가 메모리 안에서 연속된 공간에 존재하는 것이 아니라 여러 위치에 나누어 배치되는 구조이다.

이때 MMU(Memory Management Unit)가 논리 주소(Logical Address)를 물리 주소(Physical Address)로 변환하면서 각 페이지가 어느 프레임에 있는지 연결해준다. 그래서 실제로는 프로세스가 메모리 곳곳에 분산되어 있더라도, 프로그램(Program)의 입장에서는 하나의 연속된 공간처럼 사용할 수 있다.

페이징에서의 주소 변환 (Address Translation in Paging)

페이징(Paging)에서 주소 변환(Address Translation)이 어떻게 이루어지는지 살펴보자.

논리 주소(Logical Address)는 페이지 번호(Page Number, p)와 변위(Offset, d)로 구성된다. 이때 페이지 번호를 기준으로 페이지 테이블(Page Table)을 확인하고, 해당 페이지가 저장된 프레임 번호(Frame Number, f)를 찾는다.

그다음 찾은 프레임 번호와 기존의 변위를 결합하여 최종적인 물리 주소(Physical Address)를 만든다. 즉, 논리 주소의 페이지 번호와 변위는 물리 주소의 프레임 번호와 변위로 변환되는 구조라고 이해할 수 있다.

이 과정에서 페이지 테이블은 주소 변환의 핵심 역할을 수행한다.

그림을 보면, 프로세스(Process)가 생성한 논리 주소는 페이지 번호(p)와 변위(d)로 나뉘어 MMU(Memory Management Unit)로 전달된다. MMU는 페이지 번호(p)를 이용해 페이지 테이블에서 해당 페이지가 위치한 프레임 번호(f)를 찾는다.

이후 찾은 프레임 번호(f)에 기존의 변위(d)를 그대로 결합하여 물리 주소를 생성한다. 이렇게 만들어진 물리 주소를 기준으로 실제 메모리(Physical Memory)의 해당 프레임 위치에 접근하게 된다.

즉, 페이지 번호는 프레임 번호로 변환되고, 변위는 그대로 유지된다. 이를 통해 최종적으로 실제 메모리 위치가 결정된다.

페이지 테이블 구조 (Page Table Structure)

이제 페이지 테이블(Page Table)이 어떤 구조로 되어 있는지 살펴보자. 페이지 테이블은 각 페이지(Page)가 어느 프레임(Frame)에 저장되어 있는지를 기록해두는 자료구조(Data Structure)이다.

이때 페이지 번호(Page Number)를 인덱스(Index)로 사용하여, 해당 페이지가 위치한 프레임 번호(Frame Number)를 빠르게 찾을 수 있다. 즉, 페이지 테이블의 각 항목은 페이지 번호에 대응하는 프레임 번호로 구성되어 있다고 볼 수 있다.

결국 페이지 테이블은 논리 주소(Logical Address)와 물리 주소(Physical Address)를 연결해주는 핵심적인 역할을 한다.

그림을 통해 페이지 테이블이 실제로 어떻게 매핑(Mapping)되는지 확인해보자. 왼쪽에는 논리 주소 공간(Logical Address Space)이 있고, 각 페이지 번호가 페이지 테이블의 인덱스로 사용된다.

예를 들어 논리 주소의 페이지 번호가 2라고 하면, 페이지 테이블의 2번 인덱스를 조회한다. 그 결과 해당 페이지가 프레임 번호 4에 저장되어 있다는 것을 확인할 수 있다. 따라서 이 데이터는 오른쪽의 물리 메모리(Physical Memory)에서 4번 프레임 위치에 존재하게 된다.

이처럼 페이지 번호를 기준으로 페이지 테이블을 조회하면, 해당 데이터가 저장된 실제 위치를 찾아 접근할 수 있다. 즉, 페이지 번호를 알고 있다면 해당 데이터가 저장된 물리 메모리 위치를 빠르게 찾을 수 있는 구조라고 이해하면 된다.

페이징의 장점과 한계 (Advantages and Limitations of Paging)

이제 페이징(Paging)을 왜 사용하는지 생각해보자. 페이징의 가장 큰 특징은 연속된 메모리 공간(Contiguous Memory Space)이 없어도 프로세스(Process)를 실행할 수 있다는 점이다.

즉, 메모리(Memory)의 여러 위치에 흩어져 있는 공간을 묶어서 사용하는 것이 가능하다. 따라서 연속 메모리 할당 방식(Contiguous Memory Allocation)에서 문제가 되었던 외부 단편화(External Fragmentation)는 사실상 발생하지 않는다.

그 결과 메모리를 더 유연하게 사용할 수 있고, 전체적인 메모리 활용 효율(Memory Utilization)도 좋아진다. 또한 메모리를 동일한 크기의 단위로 나누어 관리하기 때문에 구조가 단순해지고 관리도 쉬워진다는 특징이 있다.

지금까지 페이징의 장점을 살펴보았다면, 이번에는 한계를 살펴보자. 페이징 방식에서도 메모리를 페이지(Page) 단위로 나누어 관리하기 때문에, 페이지 크기보다 작은 데이터가 들어가면 일부 공간이 남을 수 있다. 따라서 단편화 문제가 완전히 사라지는 것은 아니며, 내부 단편화(Internal Fragmentation)는 여전히 발생할 수 있다.

또한 페이지 테이블(Page Table)을 따로 관리해야 하므로 추가적인 메모리 공간이 필요하다. 주소 변환(Address Translation) 과정에서도 페이지 테이블을 한 번 더 거쳐야 하기 때문에 추가적인 연산이 발생한다.

그 결과 메모리 접근 속도(Memory Access Speed)가 다소 느려질 수 있다는 한계도 존재한다.

세그멘테이션 (Segmentation)

이번에는 세그멘테이션(Segmentation) 기법을 살펴본다. 페이징(Paging)이 메모리를 일정한 크기로 나누는 방식이었다면, 세그멘테이션은 프로그램(Program)을 의미 단위로 나누는 방식이다.

예를 들어 코드 영역(Code Segment), 데이터 영역(Data Segment), 스택 영역(Stack Segment)처럼 프로그램의 논리적인 구조(Logical Structure)를 기준으로 나눈다. 따라서 각 세그먼트(Segment)는 서로 다른 크기를 가질 수 있다. 이처럼 프로그램의 구조를 그대로 반영한다는 점이 세그멘테이션의 특징이다.

그림을 보면 세그멘테이션은 페이징과 접근 방식이 다르다는 것을 확인할 수 있다. 페이징은 동일한 크기로 나누어 배치하는 방식이지만, 세그멘테이션에서는 각 영역의 크기가 서로 다르게 유지된 상태로 메모리에 배치된다.

즉, 프로그램을 나누는 기준이 크기(Size)가 아니라 의미(Meaning)라는 점이 핵심이다. 코드, 데이터, 스택처럼 서로 다른 역할을 하는 영역들이 각각 독립적으로 메모리에 배치된다.

이때도 실제 메모리(Physical Memory)에서는 세그먼트들이 분산되어 저장될 수 있지만, 프로그램 입장에서는 하나의 논리적인 구조로 이어져 있는 것처럼 보이게 된다.

세그멘테이션에서의 주소 변환 (Address Translation in Segmentation)

이제 세그멘테이션(Segmentation)에서 주소가 어떻게 변환되는지 살펴본다. 세그멘테이션은 페이징(Paging)과 구조는 비슷하지만, 주소를 나누는 기준이 다르다는 점이 중요하다.

세그멘테이션에서 논리 주소(Logical Address)는 세그먼트 번호(Segment Number)와 변위(Offset)로 구성된다. 먼저 세그먼트 번호를 이용해 세그먼트 테이블(Segment Table)에서 해당 세그먼트의 시작 위치(Base)와 길이(Limit)를 확인한다.

이때 변위가 허용된 범위, 즉 세그먼트의 길이를 넘지 않았는지 검사한다. 문제가 없다면 세그먼트의 시작 주소(Base Address)에 변위(Offset)를 더해 최종적인 물리 주소(Physical Address)를 생성한다.

즉, 페이징이 페이지 번호(Page Number)를 프레임 번호(Frame Number)로 변환하는 것이 중심이었다면, 세그멘테이션은 먼저 범위 검사(Limit Check)를 수행한 뒤 실제 위치를 계산하는 방식이라고 이해할 수 있다.

그림을 보면 세그멘테이션에서 주소 변환이 어떤 순서로 이루어지는지 더 명확하게 확인할 수 있다. 왼쪽 상단의 가상 주소(Virtual Address), 즉 논리 주소는 세그먼트 번호(Segment)와 변위(Offset)로 구성되어 있다.

MMU(Memory Management Unit)는 세그먼트 번호를 이용해 세그먼트 테이블에서 해당 세그먼트의 정보를 찾는다. 이때 중요한 점은 변위가 허용된 범위 안에 있는지 Yes/No로 검사한다는 것이다.

즉, 변위 값은 경계값(Limit Value)보다 작아야 정상적인 접근이 가능하다. 만약 조건을 만족하지 못하면 트랩(Trap)이 발생하고, 주소 오류(Address Error)로 처리된다.

반대로 조건을 만족하면 세그먼트의 시작 주소(address)에 변위(Offset)를 더해 최종적인 물리 주소를 생성한다. 정리하면, 세그멘테이션에서는 MMU가 먼저 변위가 허용 범위 안에 있는지 검사하고, 그다음 기준 주소(Base Address)에 변위를 더해 물리 주소를 구성한다.

세그멘테이션의 특징 (Characteristics of Segmentation)

세그멘테이션(Segmentation)의 특징을 정리해보면, 가장 큰 특징은 프로그램(Program)의 논리 구조(Logical Structure)를 그대로 반영해서 메모리(Memory)를 관리할 수 있다는 점이다.

따라서 코드(Code), 데이터(Data), 스택(Stack)과 같은 단위를 각각 따로 관리할 수 있다. 이를 통해 메모리 보호(Memory Protection)나 공유(Sharing)가 더 유연하게 이루어질 수 있다.

또한 세그먼트(Segment)마다 크기가 다르기 때문에, 프로그램의 구조에 맞게 메모리를 사용할 수 있다.

다만 각 세그먼트는 메모리의 연속된 공간에 배치되어야 한다. 따라서 세그멘테이션 방식에서도 외부 단편화(External Fragmentation)가 발생할 수 있다는 한계가 있다.

페이징과 세그멘테이션 비교 (Paging vs Segmentation)

이제 페이징(Paging)과 세그멘테이션(Segmentation)을 함께 놓고 보면, 두 방식의 차이가 더 명확하게 보인다.

먼저 페이징은 메모리(Memory)를 일정한 크기로 나누어 단순하게 관리하는 방식이다. 반면 세그멘테이션은 프로그램(Program)의 의미 단위로 나누어, 프로그램의 구조를 그대로 반영하는 방식이다.

페이징은 구조가 단순하고 관리가 쉽다는 장점이 있다. 하지만 페이지(Page) 단위로 메모리를 나누기 때문에, 일부 공간이 사용되지 않고 남는 내부 단편화(Internal Fragmentation)가 발생할 수 있다.

세그멘테이션은 프로그램의 논리 구조(Logical Structure)를 잘 반영하고, 보호(Protection)나 공유(Sharing)를 유연하게 처리할 수 있다는 장점이 있다. 하지만 각 세그먼트(Segment)가 연속된 공간에 배치되어야 하기 때문에 외부 단편화(External Fragmentation)가 발생할 수 있다.

주소 변환(Address Translation) 방식에서도 차이가 있다. 페이징은 페이지 번호(Page Number)를 프레임 번호(Frame Number)로 변환하는 방식이라면, 세그멘테이션은 세그먼트의 시작 위치(Base)에 변위(Offset)를 더해 실제 위치를 계산하는 방식이다.

이처럼 두 방식을 비교해보면, 각각의 장단점이 분명하게 드러난다.

소프트웨어 테스팅(Software Testing): 테스트 수행, 결함 관리, 평가와 개선

오늘은 테스트를 수행하고, 그 결과를 평가하며, 문제점을 개선하는 과정에 대해 학습한다. 이번 강의에서 이해해야 할 학습 목표는 크게 세 가지이다.

첫 번째는 **테스트 수행(Test Execution)**이 무엇인지 이해하는 것이다. 테스트 수행이란 실제로 테스트를 진행하는 활동을 의미하며, 이 과정에서 어떤 주요 활동들이 이루어지는지 설명할 수 있어야 한다.

두 번째는 **테스트 결함 관리(Test Defect Management)**에 대해 이해하는 것이다. 테스트를 수행하면 결함(Defect)이 발견될 수 있는데, 이러한 결함을 체계적으로 관리하는 과정이 필요하다. 따라서 테스트 결함 관리가 무엇인지, 그리고 왜 필요한지 그 필요성까지 설명할 수 있어야 한다.

마지막으로 테스트 과정에 대한 **평가와 개선(Evaluation and Improvement)**을 이해해야 한다. 테스트가 제대로 수행되었는지는 정기적으로 평가되어야 하며, 평가 결과 발견된 문제점은 개선되어야 한다. 이를 위해 테스트 과정을 평가하는 방법과, 문제점을 개선하는 활동이 무엇인지 알아야 한다.

정리하면, 이번 강의의 목표는 테스트 수행(Test Execution)의 의미와 주요 활동을 이해하고, 테스트 결함 관리(Test Defect Management)의 필요성을 파악하며, 테스트 과정의 평가와 개선(Evaluation and Improvement) 활동을 설명할 수 있도록 하는 것이다.

1️⃣ Core Concepts of Test Execution

테스트 계획과 설계 기반의 테스트 수행(Test Execution Based on Test Planning and Design)

테스트(Test)는 실제 수행에 들어가기 전에 반드시 선행되어야 할 과정이 있다. 입력값(Input)에 대해 결과(Output)가 적절한지 확인하기 전에, 먼저 테스트를 계획(Test Planning)하고 설계(Test Design)하는 과정이 필요하다.

테스트를 하나의 프로세스(Process)로 볼 때, 우리는 PDCA 관점에서 테스트를 체계적으로 수행해야 한다고 배웠다. 여기서 D에 해당하는 단계가 바로 테스트 수행(Test Execution)이다. 테스트 수행이란 테스트 케이스(Test Case)를 바탕으로 테스트 절차(Test Procedure)에 따라 실제 테스트 환경(Test Environment)에서 테스트를 실행하는 활동이다. 이때 테스트는 사람이 직접 수동(Manual)으로 수행할 수도 있고, 자동화 도구(Automation Tool)를 사용하여 수행할 수도 있다. 중요한 것은 테스트 케이스를 실행한 뒤, 그 결과가 기대한 결과와 일치하는지를 판단하는 것이다.

하지만 테스트 수행이 제대로 이루어지기 위해서는 그 이전 단계가 탄탄하게 준비되어 있어야 한다. 특히 테스트 계획(Test Plan)과 테스트 설계(Test Design)가 기반이 되어야 한다. 이 부분은 V-Model을 학습할 때도 강조되었다. V-Model에서 왼쪽은 개발 활동(Development Activity), 오른쪽은 테스트 활동(Test Activity)을 의미한다. 오른쪽의 테스트 활동에서는 실제 테스트를 수행하지만, 왼쪽의 개발 활동이 진행되는 동안 이미 테스트 계획과 테스트 설계가 충분히 이루어져 있어야 한다.

그 이유는 명확하다. 테스트 계획 수립(Test Planning), 테스트 케이스 개발(Test Case Development), 테스트 절차 정의(Test Procedure Definition), 테스트 환경 준비(Test Environment Setup)와 같은 사전 과정이 모두 준비되어야 실제 테스트 수행 단계에서 체계적인 테스트가 가능하기 때문이다. 이러한 준비가 되어 있으면 입력값을 넣고 출력 결과가 적절한지 확인할 때 시간에 쫓기지 않고, 충분히 준비된 상태에서 안정적으로 테스트를 진행할 수 있다.

다시 말해 테스트 수행(Test Execution)이란 입력에 대해 결과가 적절한지를 확인하는 활동이다. 그러나 이 수행이 제대로 이루어지기 위해서는 그 이전 과정인 테스트 계획(Test Planning)과 테스트 설계(Test Design)가 제대로 수립되어 있어야 한다. 이것이 체계적인 테스트 수행에서 가장 중요한 부분이다.

ISO/IEC/IEEE 29119의 테스트 수행(Test Execution)

ISO/IEC/IEEE 29119는 소프트웨어 테스트와 관련된 국제 표준(International Standard)이다. 이 표준에서 테스트 수행(Test Execution)은 동적 테스트 프로세스(Dynamic Test Process) 안에 포함된다.

동적 테스트 프로세스 안에는 여러 세부 활동이 있다. 먼저 테스트 설계 및 구현(Test Design and Implementation), 테스트 환경 구성 및 유지(Test Environment Setup and Maintenance)는 테스트 수행 전에 이루어지는 테스트 설계(Test Design) 관련 활동에 해당한다. 이러한 활동을 통해 테스트에 필요한 준비가 완료되면, 그 결과를 바탕으로 실제 테스트를 수행하고, 수행 결과가 적절한지 판단한 뒤 테스트 결과를 보고(Test Result Reporting)하게 된다. 이 부분이 테스트 수행(Test Execution)에 해당한다.

이 국제 표준에서도 테스트 수행은 사전 준비가 완료된 상태에서 진행된다는 점을 강조한다. 테스트 수행을 위해서는 테스트 명세서(Test Specification)와 테스트 환경(Test Environment)이 이미 준비되어 있어야 한다. 즉, 테스트 수행 단계에서 테스트 케이스(Test Case)를 새로 만드는 것이 아니라, 앞 단계에서 테스트 계획과 설계가 충분히 이루어진 상태에서 테스트를 실행하는 것이다.

따라서 테스트 수행(Test Execution)은 단독으로 이루어지는 활동이 아니라, 테스트 명세서(Test Specification), 테스트 환경(Test Environment), 테스트 설계(Test Design)와 같은 사전 준비를 기반으로 진행된다. 이러한 준비가 충분히 되어 있을 때 테스트 수행은 보다 체계적이고 안정적으로 이루어질 수 있다. 이 점을 잘 기억해야 한다.

테스트 수행과 테스트 결과 보고(Test Execution and Test Result Reporting)

테스트 수행(Test Execution)이란 테스트 절차(Test Procedure)를 실제로 실행하고, 그 테스트 실행 결과(Test Execution Result)를 기록하는 활동이다. 테스트 수행은 테스트 케이스(Test Case)에 기반하여 정해진 절차대로 진행된다.

예를 들어 로그인 기능(Login Function)을 테스트한다고 하면, 사용자는 먼저 로그인 화면을 표시하고, 아이디(ID)를 입력한 뒤, 탭(Tab) 키를 눌러 비밀번호 입력 칸으로 이동한다. 이후 비밀번호(Password)를 입력하고 엔터(Enter)를 누르는 식으로 일련의 절차를 수행한다. 이러한 과정은 임의로 진행되는 것이 아니라, 미리 작성된 테스트 케이스와 테스트 절차에 따라 실행된다.

테스트를 수행한 뒤에는 그 결과를 테스트 케이스에 기록한다. 실제 결과가 기대한 결과와 일치하는지 확인하고, 해당 테스트가 통과(Pass)했는지 또는 실패(Fail)했는지를 명확히 남긴다.

그 다음 단계는 테스트 결과 보고(Test Result Reporting)이다. 테스트 결과 보고란 테스트 실행 결과를 분석한 내용을 바탕으로 결함(Defect)을 식별하고, 그 결함에 대한 상세 정보를 기록하는 과정이다. 즉, 테스트 수행을 통해 얻은 결과를 정리하고, 발견된 문제를 체계적으로 보고하는 활동이라고 할 수 있다.

테스트 수행의 주요 활동(Main Activities of Test Execution)

테스트 수행(Test Execution)의 주요 활동 중 하나는 테스트 케이스 실행(Test Case Execution)이다. 테스트 케이스 실행이란 정의된 테스트 절차(Test Procedure)와 테스트 환경(Test Environment)에 따라 단위 테스트(Unit Test), 통합 테스트(Integration Test), 시스템 테스트(System Test), 인수 테스트(Acceptance Test) 등의 테스트 케이스(Test Case)를 실제로 실행하고, 그 결과를 기록하는 활동이다.

테스트 케이스는 테스트 수행 단계에서 새로 만드는 것이 아니라, 앞선 테스트 설계(Test Design) 단계에서 이미 작성되어 있어야 한다. V-Model 관점에서도 개발 활동이 진행되는 동안 테스트 설계가 함께 이루어지고, 그 과정에서 테스트 케이스가 만들어진다. 따라서 테스트 수행 단계에서는 이미 준비된 테스트 케이스를 바탕으로 실제 실행을 진행한다.

테스트는 사람이 직접 수동(Manual)으로 수행할 수도 있고, 자동화 도구(Automation Tool)를 사용하여 수행할 수도 있다. 중요한 것은 어떤 방식으로 실행하든 테스트 케이스에 정의된 입력값(Input)과 예상 출력값(Expected Output)을 기준으로 실제 실행 결과(Actual Result)를 확인하고 기록하는 것이다.

테스트 케이스 양식을 보면 보통 TC_1, TC_2와 같이 테스트 케이스 ID(Test Case ID)가 구분되어 있고, 입력값(Input), 예상 출력값(Expected Output), 실행 결과(Actual Result), 조치사항(Action Item), 조치결과(Action Result) 등을 기록하는 칸이 있다. 이 중 테스트 케이스 ID, 입력값, 예상 출력값과 같은 항목은 테스트 설계 단계에서 이미 작성되어 있어야 한다. 테스트 케이스는 요구사항 문서(Requirements Document)를 바탕으로 만들 수도 있고, 코드(Code)를 기준으로 만들 수도 있다. 또한 화이트박스 테스트(White-box Test)인지 블랙박스 테스트(Black-box Test)인지에 따라 테스트 케이스를 만드는 방식도 달라질 수 있다.

예를 들어 로그인 기능(Login Function)을 테스트한다고 할 때, 테스트 케이스의 목적이 “로그인 시 아이디와 비밀번호의 대소문자를 구분하여 처리한다”라고 되어 있다고 하자. 이때 TC_1의 입력값이 CUK/korea라면, 예상 출력값은 “아이디 없음” 경고가 되어야 한다. 아이디의 대소문자를 구분해야 하기 때문에, 등록된 아이디와 대소문자가 다르면 정상 로그인이 되면 안 되기 때문이다.

그런데 실제 실행 결과(Actual Result)에 “정상 로그인”이라고 나온다면, 이는 예상 출력값과 다르므로 문제가 있는 것이다. 이 경우 조치사항(Action Item)에는 “디버깅 필요(Debugging Required)”와 같은 내용이 기록될 수 있다. 이후 문제가 수정되면 조치결과(Action Result)에 “아이디 없음 경고 표시”와 같이 해결된 내용을 기록한다.

정리하면, 테스트 수행 단계에서는 이미 설계된 테스트 케이스를 실제로 실행하고 그 결과를 기록한다. 이 과정에서 실행 결과(Actual Result), 조치사항(Action Item), 조치결과(Action Result)는 테스트 수행 중에 작성되지만, 그 외의 테스트 케이스 ID(Test Case ID), 입력값(Input), 예상 출력값(Expected Output), 테스트 목적(Test Objective) 등은 테스트 설계 단계에서 미리 준비되어 있어야 한다.

테스트 수행의 주요 활동: 테스트 결과 판정(Main Activities of Test Execution: Test Result Evaluation)

테스트 수행(Test Execution)의 주요 활동 중 하나는 테스트 결과 판정(Test Result Evaluation)이다. 테스트 결과 판정이란 테스트 수행 결과를 분석하여 결함(Defect) 여부를 판단하고, 결함으로 확인된 경우 그 상세 내용을 기록하는 활동이다.

테스트 케이스(Test Case)에 맞게 테스트를 정상적으로 수행했더라도, 그 결과가 반드시 결함이라고 단정할 수는 없다. 테스트 결과가 실제 결함일 수도 있지만, 결함이 아닐 수도 있기 때문이다. 따라서 테스트 결과를 다시 확인하고 분석하여, 해당 결과가 결함인지 아닌지를 판단하는 과정이 필요하다. 결함으로 판단될 경우에는 그 내용을 상세하게 기록해야 한다.

결함을 상세하게 기록해야 하는 이유는 커뮤니케이션(Communication) 때문이다. V-Model을 기준으로 보면 왼쪽은 개발 활동(Development Activity), 오른쪽은 테스트 활동(Test Activity)에 해당한다. 테스트는 개발자가 작성한 코드(Code)를 대상으로 수행되지만, 테스터(Tester)가 직접 그 코드를 개발한 것은 아니기 때문에 테스트 결과가 성공인지 실패인지는 알 수 있어도, 내부적으로 왜 그런 결과가 발생했는지까지는 정확히 알기 어려울 수 있다. 따라서 개발자가 결함 내용을 충분히 이해할 수 있도록 테스트 결과를 구체적이고 명확하게 작성해야 한다.

즉, 테스트 결과는 단순히 성공(Pass) 또는 실패(Fail)로만 기록해서는 부족하다. 왜 실패했는지, 어떤 상황에서 문제가 발생했는지, 어떤 부분을 조치해야 하는지를 분석하고 기록해야 한다. 이 과정에서 테스트와 개발 사이의 커뮤니케이션이 매우 중요해진다.

예를 들어 결함 ID(Defect ID)가 Defect 001이고, 대상 기능(Target Function)이 로그인(Login) 기능이라고 하자. 테스터(Tester)는 고려인이며, 테스트 일자(Test Date)도 함께 기록되어 있다. 결함 제목(Defect Title)은 “아이디 대소문자 처리 결함”이다.

앞서 로그인 테스트에서 아이디를 대문자 CUK로 입력했을 때, 예상 결과(Expected Result)는 “아이디 없음 경고”가 표시되는 것이었다. 그러나 실제 결과(Actual Result)는 정상 로그인으로 나타났다. 이 경우 상세 설명(Description)에는 아이디의 대소문자를 구분해야 함에도 불구하고, 대문자로 입력한 아이디가 정상적으로 로그인 처리되었다는 내용을 구체적으로 작성해야 한다.

조치사항(Action Item)에는 login() 함수의 대소문자 처리 로직(Case-sensitive Logic)에 대한 디버깅(Debugging)이 필요하다고 기록할 수 있다. 또한 결함의 심각도(Severity)도 함께 분석하여 기록한다. 이 예시에서는 심각도를 “매우 심각(Critical)”으로 판단할 수 있다. 로그인 기능은 사용자가 시스템을 사용할 때 가장 먼저 접하는 기능이므로, 이 기능에 결함이 있으면 전체 시스템 사용에 미치는 영향이 클 수 있기 때문이다.

정리하면, 테스트 수행(Test Execution)이란 앞서 준비된 테스트 케이스(Test Case)를 실제로 실행하고, 그 결과로 나타난 문제점이나 이상 현상이 결함(Defect)에 해당하는지 판단하는 과정이다. 그리고 결함으로 판단된 경우에는 개발자가 이해하고 조치할 수 있도록 결함의 상세 내용을 명확하게 기록해야 한다.

Java-based Source Code Coverage Tools: JUnit, EclEmma

테스트를 사람이 직접 수동(Manual)으로 수행하는 데에는 한계가 있을 수밖에 없다. 특히 소스코드(Source Code)를 기반으로 화이트박스 테스트(White-box Test)를 수행할 때 중요한 개념 중 하나가 커버리지(Coverage)이다. 커버리지란 코드가 테스트를 통해 얼마나 실행되었는지를 나타내는 기준이다.

이러한 커버리지 측정을 도와주는 도구들도 존재한다. 대표적으로 Eclipse 환경에서 사용할 수 있는 JUnit과 EclEmma가 있다. 이들은 Java 기반 테스트에서 활용할 수 있는 도구로, 플러그인(Plugin) 형태로 제공된다.

JUnit은 Java 프로그램에서 테스트 코드를 작성하고 실행할 때 사용할 수 있는 도구이다. Eclipse 환경에서 JUnit을 사용하면 클래스(Class)별로 테스트 결과를 확인할 수 있고, Line Coverage와 Branch Coverage를 통해 코드가 얼마나 테스트되었는지 볼 수 있다. Line Coverage는 문장 또는 코드 라인이 얼마나 실행되었는지를 의미하고, Branch Coverage는 조건문이나 분기문이 얼마나 테스트되었는지를 의미한다. 테스트가 완료된 부분은 녹색으로, 테스트가 수행되지 않은 부분은 빨간색으로 표시되어 시각적으로 확인할 수 있다.

EclEmma 역시 Eclipse 환경에서 커버리지 측정(Coverage Measurement)에 사용되는 도구이다. EclEmma를 사용하면 소스코드가 테스트된 정도를 색상으로 확인할 수 있다. 녹색은 테스트가 완료된 부분을 의미하고, 노란색은 일부만 테스트된 부분을 의미하며, 빨간색은 테스트가 수행되지 않은 부분을 의미한다. 이를 통해 개발자나 테스터는 어떤 코드가 충분히 테스트되었고, 어떤 부분이 아직 테스트되지 않았는지 쉽게 파악할 수 있다.

이처럼 JUnit과 EclEmma 같은 도구를 활용하면 사람이 직접 모든 테스트 결과를 확인하는 것보다 훨씬 효율적으로 테스트 수행 결과와 코드 커버리지(Code Coverage)를 확인할 수 있다. Java 프로그램을 테스트할 때 이러한 플러그인을 설치하여 활용해 보는 것도 좋은 방법이다.

지금까지는 테스트 수행(Test Execution)이라는 프로세스(Process)에 대해 살펴보았다.

2️⃣ Test Defect Management

다음은 테스트 결함관리 부분이다. 결함관리가 무엇인지, 왜 필요한지 위주로 살펴보도록할것이다. 테스트를 하고 나면 결함들이 나오게 된다. 그 결함을 관리하는 과정을 '테스트 결함 관리'라고한다.

테스트 결함 관리 정의(Test Defect Management)

앞서 테스트 수행(Test Execution) 과정을 통해 단위 테스트(Unit Test), 통합 테스트(Integration Test), 인수 테스트(Acceptance Test) 등 여러 테스트 활동을 진행하였다. 이러한 테스트 단계에서 발생한 결함(Defect)을 식별하고, 결함을 해결하기 위해 조치하는 일련의 프로세스를 테스트 결함 관리(Test Defect Management) 또는 결함 관리 프로세스(Defect Management Process)라고 한다.

결함 관리는 테스트 과정에서 발견된 결함을 체계적으로 관리하기 위해 사용된다. 테스트를 통해 어떤 결함이 발견되었는지, 결함이 몇 개 존재하는지, 그중 몇 개가 해결되었는지 등을 관리 관점에서 측정할 수 있어야 한다. 이러한 측정 결과를 바탕으로 테스트 활동의 상태를 파악할 수 있으며, 이후 테스트 측정(Test Measurement), 테스트 조정(Test Control), 품질 관리(Quality Management)와 같은 관리 프로세스의 기반이 된다.

결함 관리 프로세스(Defect Management Process)의 흐름을 살펴보면, 먼저 테스트를 수행한 뒤 예상 결과(Expected Result)와 실제 결과(Actual Result)를 비교한다. 만약 두 결과가 일치하면 정상적으로 테스트가 수행된 것이고, 불일치가 발생하면 결함 가능성이 있는 상황으로 본다.

이후 해당 문제를 결함으로 식별(Identification)하고 분석(Analysis)한다. 분석 결과 실제 결함이 아니거나 잘못된 테스트로 판단되면 해당 테스트는 종료된다. 반면 실제 결함으로 판단되면 결함을 등록(Defect Registration)하고, 누가 수정할 것인지 담당자를 지정하여 결함 조치(Defect Action)를 진행한다.

결함 조치가 완료되었다고 해서 바로 끝나는 것은 아니다. 수정된 결함이 실제로 해결되었는지 확인하기 위해 반드시 재테스트(Retest)를 수행해야 한다. 재테스트를 통해 결함이 정상적으로 해결되었는지 다시 확인한 뒤, 문제가 없다고 판단되면 테스트 종료(Test Closure)를 확인하게 된다.

따라서 결함 관리 프로세스는 단순히 테스트를 수행하고 결함을 해결하는 것으로 끝나는 과정이 아니다. 결함을 식별하고, 분석하고, 등록하고, 조치한 뒤, 재테스트를 통해 실제 해결 여부를 확인하는 전체 과정을 의미한다.

이러한 과정을 거치면서 결함의 상태(Defect Status)는 계속 변화한다. 예를 들어 결함이 새롭게 등록된 상태는 오픈(Open), 수정이 진행 중인 상태는 진행 중(In Progress), 조치가 완료된 상태는 해결(Resolved)로 관리될 수 있다. 이렇게 결함 상태를 데이터로 측정하고 관리함으로써, 테스트 과정뿐만 아니라 근본적인 품질 관리(Quality Management)까지 이루어질 수 있다.

테스트 결함 관리의 필요성 (Necessity of Test Defect Management)

일반적으로 관리(Management)란 데이터를 수집하고, 그 데이터를 기반으로 일이 제대로 실행될 수 있도록 모니터링(Monitoring)하고 통제(Control)하는 활동을 의미한다. 결함 관리(Defect Management)도 마찬가지이다. 테스트 과정에서 발견된 결함을 체계적으로 수집하고 관리함으로써 소프트웨어의 품질(Quality)을 확보하는 것이 목적이다.

결함은 결국 품질 관리(Quality Management)와 연결된다. 개발 과정에서 개발자들은 실수로 인해 여러 가지 결함(Defect)을 만들 수 있다. 만약 이러한 결함이 해결되지 않은 채 사용자에게 배포되고 운영된다면, 그때부터는 큰 품질 문제가 될 수 있다. 사용자 클레임(Claim)이 발생할 수 있고, 문제를 해결하기 위해 더 큰 비용을 치러야 할 수도 있다.

따라서 결함 관리는 실제 사용자에게 소프트웨어가 배포되기 전에 개발 영역에서 결함을 찾아내고, 이를 체계적으로 관리하여 개발 단계의 품질을 최대한 확보하기 위한 목적으로 수행된다.

테스트 결함 관리(Test Defect Management)의 필요성은 크게 세 가지로 정리할 수 있다.

첫 번째는 결함 상태(Defect Status)를 기반으로 결함 조치 현황을 모니터링하는 데 활용된다는 점이다. 결함은 처음 식별(Identification)된 뒤 등록(Registration), 분석(Analysis), 평가(Evaluation), 처리(Handling), 해결(Resolution), 재확인(Recheck)과 같은 여러 상태를 거친다. 이러한 상태를 기준으로 현재 결함이 어느 단계에 있는지, 조치가 제대로 이루어지고 있는지를 모니터링할 수 있다.

두 번째는 결함 관련 지표(Defect Metrics)를 기반으로 품질 현황을 정량적으로 관리하는 데 활용된다는 점이다. 단순히 품질이 좋다거나 나쁘다고 판단하는 것이 아니라, 데이터를 지표화하여 정량적으로 관리하는 것이 중요하다. 예를 들어 결함 조치율(Defect Resolution Rate), 테스트 케이스 실패율(Test Case Failure Rate)과 같은 지표를 통해 품질 상태를 객관적으로 파악할 수 있다. 이를 통해 현재 소프트웨어의 품질 수준을 보다 명확하게 관리할 수 있다.

세 번째는 결함 유형(Defect Type)을 파악하고 원인 분석(Cause Analysis)에 활용할 수 있다는 점이다. 한 번 발생한 결함은 이후 다른 유사한 프로젝트에서도 다시 발생할 가능성이 있다. 따라서 같은 문제가 반복되지 않도록 결함의 유형을 파악하고, 그 원인이 사람의 문제인지, 도구(Tool)의 문제인지, 절차(Process)의 문제인지 등을 분석해야 한다. 이러한 분석은 향후 결함을 예방하고 품질을 개선하는 데 중요한 기반이 된다.

정리하면, 테스트 결함 관리(Test Defect Management)는 결함을 단순히 기록하는 활동이 아니라, 결함 상태를 모니터링하고, 품질 현황을 정량적으로 관리하며, 결함의 원인을 분석해 향후 품질 개선(Quality Improvement)에 활용하기 위한 중요한 관리 활동이다.

결함 상태 기반의 결함 조치 현황 모니터링

(Monitoring Defect Handling Status Based on Defect Status)

결함 상태(Defect Status)는 결함이 현재 어떤 단계에 있는지를 나타내는 기준이다. 결함이 처음 생성(Create Defect)되면 오픈(Open) 상태가 된다. 이후 담당자가 지정되고, 담당자가 해당 결함을 처리하기 시작하면 진행 중(In Progress) 상태가 된다. 담당자가 결함을 모두 해결하면 해결됨(Resolved) 상태가 된다.

그러나 결함이 해결되었다고 해서 바로 종료되는 것은 아니다. 이후 제3자가 해당 결함이 실제로 해결되었는지 확인하는 과정을 거치게 된다. 이 확인 작업까지 완료되어야 비로소 종료(Closed) 상태가 된다.

결함은 중간에 다시 열릴 수도 있다. 예를 들어 결함이 해결된 뒤 재테스트(Retest)를 수행했을 때 문제가 다시 발견되면 재오픈(Reopened) 상태가 된다. 심지어 몇 달 전에 완전히 해결되었다고 판단한 결함이라도, 이후 유사한 문제가 다시 발생하면서 기존 결함이 완전히 해결된 것이 아니었다고 판단될 수 있다. 이 경우에도 결함은 다시 Reopened 상태가 될 수 있다.

이처럼 결함은 Open, In Progress, Resolved, Closed, Reopened와 같은 상태를 거치며 관리된다. 이러한 흐름을 결함 워크플로우(Defect Workflow)라고 한다.

관리자, 특히 품질 관리자(Quality Manager)는 이러한 결함 상태를 바탕으로 프로젝트의 결함 조치 현황을 모니터링한다. 예를 들어 현재 프로젝트에서 Open 상태의 결함이 10개, In Progress 상태의 결함이 5개, Resolved 상태의 결함이 3개, Closed 상태의 결함이 5개라는 식으로 결함의 상태를 파악할 수 있다. 이를 통해 결함이 제대로 조치되고 있는지, 아직 해결되지 않은 결함이 얼마나 남아 있는지, 최종적으로 종료된 결함은 얼마나 되는지를 확인할 수 있다.

결함 관리의 목표는 발견된 결함이 최종적으로 모두 Closed 상태가 되도록 관리하는 것이다. 하지만 실제 프로젝트에서는 결함이 수십 개, 수백 개씩 발생할 수 있고, 유사한 결함이 반복해서 나타날 수도 있다. 따라서 결함을 효과적으로 관리하기 위해서는 결함의 상태 관리(Defect Status Management)가 반드시 필요하다.

결함 관련 지표 기반의 품질 현황 관리

(Quality Status Management Based on Defect Metrics)

테스트를 수행하면 많은 결함(Defect)이 발견될 수 있다. 이때 테스트 결함과 관련된 여러 데이터를 수집하고, 그 데이터를 기반으로 품질(Quality)과 결함에 대한 지표(Metrics)를 만들 수 있다. 이러한 지표를 활용하면 품질 현황을 정량적으로 관리할 수 있다.

가장 쉽게 사용할 수 있는 지표 중 하나는 평균 결함 건수(Average Defect Count)이다. 평균 결함 건수는 결함 건수(Defect Count)를 테스트 대상 모듈 수(Number of Test Target Modules)로 나누어 계산할 수 있다. 예를 들어 10개의 모듈을 테스트했는데 20개의 결함이 발견되었다면, 하나의 모듈에서 평균적으로 2개의 결함이 발생한 것으로 볼 수 있다. 이를 통해 20개 또는 30개의 모듈을 테스트할 경우 어느 정도의 결함이 발생할 수 있는지 예측할 수 있고, 특정 모듈에서 결함이 많이 발생하는지도 파악할 수 있다.

또 다른 지표는 심각도별 결함 건수(Number of Defects by Severity)이다. 결함은 전체 시스템 품질에 미치는 영향에 따라 심각도(Severity)를 나눌 수 있다. 예를 들어 해킹 위험, 보안 위험, 오동작으로 인한 제품 운영 문제처럼 시스템 전체에 큰 영향을 미치는 결함은 높은 심각도로 분류될 수 있다. 반면 영향이 작은 결함은 낮은 심각도로 분류된다.

심각도별 결함 비율은 각 심각도별 결함 건수(Number of Defects by Each Severity)를 전체 결함 건수(Total Defect Count)로 나누어 파악할 수 있다. 예를 들어 전체 결함이 10개일 때, 마이너(Minor) 결함이 2개, 보통(Major) 결함이 5개, 매우 심각(Critical) 결함이 3개라면 각각 2/10, 5/10, 3/10의 비율로 나타낼 수 있다. 이를 통해 매우 심각한 결함이 3개 발생했다는 사실을 확인할 수 있고, 해당 결함들을 우선순위(Priority)에 따라 먼저 조치한 뒤 배포 여부를 결정할 수 있다.

결함의 유형별 분포 비율(Defect Distribution by Type)도 중요한 지표이다. 결함에는 여러 종류가 있다. 단순한 문법 오류(Syntax Error)일 수도 있고, 서로 다른 A와 B 두 인터페이스(Interface) 사이에서 발생하는 결함일 수도 있으며, 성능 문제(Performance Issue)와 관련된 결함일 수도 있다. 이러한 결함 유형을 분류하고 비율로 파악하면 어떤 종류의 문제가 자주 발생하는지 확인할 수 있다.

또한 결함 조치율(Defect Resolution Rate)과 같은 지표를 통해 결함이 얼마나 해결되고 있는지도 관리할 수 있다. 결함의 상태(Status)를 비율로 파악하면 현재 결함 처리 현황을 보다 명확하게 확인할 수 있다.

테스트 케이스 실패율(Test Case Failure Rate)도 결함 관리에서 활용할 수 있는 지표이다. 테스트 케이스(Test Case)를 수행하면 결과는 성공(Pass) 또는 실패(Fail)로 나뉜다. 여기서 실패란 처음에 예상한 결과(Expected Result)가 나오지 않았다는 의미이다. 테스트 케이스의 관점에서 보면 실패가 반드시 나쁜 것은 아니다. 오히려 실패한 테스트 케이스를 통해 결함을 발견할 수 있기 때문에, 테스트가 제대로 수행되었다고 볼 수도 있다.

테스트 케이스 실패율은 결함으로 식별된 테스트 케이스 수(Number of Test Cases Identified as Defects)를 전체 테스트 케이스 수(Total Number of Test Cases)로 나눈 뒤 100을 곱해 계산할 수 있다. 이를 통해 전체 테스트 케이스 중 어느 정도가 결함과 연결되었는지를 파악할 수 있다.

이 외에도 결함과 관련된 다양한 지표를 활용할 수 있다. 이러한 지표들은 단순히 결함을 기록하는 데 그치지 않고, 품질 현황을 정량적으로 파악하고 관리하는 데 사용된다. 궁극적으로 결함 관련 지표(Defect Metrics)를 활용하면 보다 체계적인 품질 관리(Quality Management)가 가능해진다.

결함 유형 파악 및 원인 분석에 활용

(Defect Type Identification and Cause Analysis)

결함(Defect)이 한 번 발생했다고 해서 다시 발생하지 않는다는 보장은 없다. 결함은 재발할 수 있기 때문에, 결함 관리(Defect Management)를 통해 현재 결함이 Open 상태인지, Closed 상태인지 지속적으로 파악하고 분석해야 한다.

결함을 관리할 때는 단순히 해결 여부만 확인하는 것이 아니라, 해당 결함이 어떤 유형의 결함이었는지도 함께 파악해야 한다. 결함 유형(Defect Type)에는 문법 문제(Syntax Issue), 논리 문제(Logic Issue), 할당 문제(Assignment Issue), 인터페이스 문제(Interface Issue), 성능 문제(Performance Issue), 검사 문제(Checking Issue), 데이터 문제(Data Issue) 등이 있을 수 있다.

이러한 결함 유형을 분석하면 어떤 결함이 많이 발생하는지 확인할 수 있다. 예를 들어 분석 결과 Syntax 결함이 가장 많이 발생하고, 그다음으로 Logic과 관련된 결함이 많이 발생했다면, 해당 유형의 결함을 중심으로 개선 활동을 진행할 수 있다.

많이 발생하는 결함은 우선적으로 해결해야 하며, 이후 같은 결함이 다시 발생하지 않도록 예방 활동도 함께 이루어져야 한다. 이를 위해 개발자 교육(Developer Training)을 진행하거나, 매뉴얼 및 지침서(Manual and Guideline)를 작성할 수 있다. 또한 정적 분석(Static Analysis)을 통해 개발 단계에서 결함을 사전에 확인할 수 있도록 가이드할 필요가 있다.

결함이 발생하면 수정하고 다시 확인하는 과정이 반복된다. 만약 같은 결함이 계속 발생한다면, 회사 입장에서는 시간과 비용의 낭비가 된다. 따라서 결함 관리는 단순히 결함을 해결하는 데 그치는 것이 아니라, 결함의 원인(Cause)을 분석하고 재발을 방지(Recurrence Prevention)하기 위한 목적으로도 활용된다.

[참고] 미국 소프트웨어 기업의 결함 조치율 현황

(Defect Resolution Rate in U.S. Software Companies)

미국 소프트웨어 기업의 평균 결함 조치율(Defect Resolution Rate)은 약 75~85% 수준이며, AT&T, IBM과 같은 기업들은 99% 수준의 결함 조치율을 달성하고 있다.

소프트웨어의 규모를 기능 점수(Function Point) 기준으로 판단할 때, 기능 점수당 결함 수(Number of Defects per Function Point)를 활용할 수 있다. 이는 소프트웨어 규모 대비 얼마나 많은 결함이 발생하는지를 나타내는 자료이다.

먼저 미흡한 조직의 경우, 품질(Quality)의 중요성에 대한 인식이 부족하다. 이러한 조직은 품질보다는 비용 절감(Cost Reduction)을 우선으로 하는 경향이 있다. 그 결과 기능 점수당 결함 수가 810개로 매우 많고, 결함 조치율은 5055% 수준에 머무른다. 즉, 발견된 결함 중 약 40% 이상이 해결되지 않는 상태로 남아 있기 때문에 품질 수준이 매우 낮다고 볼 수 있다.

다음으로 평균적인 기업의 경우, 기능 점수당 결함 수는 약 46개이며, 결함 조치율은 7585% 수준이다. 이 경우에도 여전히 약 20% 정도의 결함은 해결되지 않은 채 남아 있을 수 있다. 많은 소프트웨어 조직들이 이 평균 수준에 속한다고 볼 수 있다.

반면 최상위 기업들은 기능 점수당 결함 수가 13개 수준으로 낮고, 결함 조치율은 9099%에 이른다. 이는 개발 단계에서 대부분의 결함이 해결되는 조직이라는 의미이며, 품질 수준이 매우 우수한 조직이라고 할 수 있다.

많은 조직들이 여전히 평균 수준에 머물러 있다. 하지만 오늘날은 소프트웨어의 중요성이 더욱 강조되는 소프트웨어 중심 시대이다. 그럴수록 품질의 중요성을 인식하고, 개발자로서 소프트웨어 품질을 높이기 위해 지속적으로 노력하는 자세가 중요하다.

테스트 평가와 개선(Test Evaluation and Improvement)

앞서 테스트 프로세스(Test Process)는 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 평가와 개선(Evaluation and Improvement)의 순서로 이루어진다고 배웠다. 또한 이 과정은 PDCA 사이클(PDCA Cycle)에 따라 진행된다.

테스트 평가와 개선(Test Evaluation and Improvement)은 PDCA에서 C와 A, 즉 확인(Check)과 조치(Act)에 해당한다. 앞 단계에서 테스트를 계획하고, 설계하고, 수행했다면, 이후에는 그 테스트가 얼마나 효과적으로 이루어졌는지를 평가해야 한다. 그리고 평가 결과 테스트가 효과적이지 않다고 판단되면, 테스트 프로세스를 개선해야 한다.

예를 들어 몇 시간 동안 수백 개의 테스트를 수행했는데 모든 결과가 성공(Pass)으로 나왔다고 하자. 이 경우 제품의 품질(Quality)이 좋다고 판단할 수도 있다. 하지만 반대로 테스트 케이스(Test Case)가 제대로 만들어지지 않았기 때문에 결함을 발견하지 못한 것이라고 판단할 수도 있다. 즉, 테스트 결과가 모두 성공이라고 해서 반드시 테스트가 효과적이었다고 단정할 수는 없다.

또한 테스트는 정해진 일정(Schedule)과 기간(Duration) 안에서 수행되어야 한다. 그런데 테스트 수행 시간이 지나치게 오래 걸린다면, 테스트 케이스가 효율적으로 설계되었는지, 테스트 도구(Test Tool)나 장비(Equipment)에 문제가 있는지, 또는 인력(Personnel) 측면에서 문제가 있는지를 확인해야 한다. 이처럼 테스트가 적절하게 수행되었는지를 평가하고, 필요한 경우 개선하는 과정이 중요하다.

따라서 테스트 평가와 개선(Test Evaluation and Improvement) 단계에서는 테스트 결과 분석 및 평가(Test Result Analysis and Evaluation)가 이루어진다. 그리고 분석 결과를 바탕으로 대책 수립(Countermeasure Planning)과 시정안 권고(Corrective Action Recommendation)가 진행된다.

참고: ISO/IEC 33063 Process Assessment Model for Software Testing

ISO/IEC 33063은 소프트웨어 테스팅(Software Testing) 프로세스를 평가하기 위한 표준이다. 앞서 테스트 프로세스(Test Process)는 여러 계층으로 구성되어 있다고 배웠다. 크게 조직 차원의 테스트 프로세스(Organizational Test Process), 테스트 관리 프로세스(Test Management Process), 동적 테스트 프로세스(Dynamic Test Process)로 나눌 수 있으며, 이러한 구조는 ISO/IEC/IEEE 29119 표준에서 다루는 내용이다.

다만 테스트 평가와 개선(Test Evaluation and Improvement)에 대해서는 ISO/IEC/IEEE 29119가 아니라, ISO/IEC 33063 표준을 참고한다. ISO/IEC 33063은 소프트웨어 테스팅 프로세스가 얼마나 적절하게 수행되고 있는지를 평가하기 위한 기준을 제시한다.

즉, ISO/IEC/IEEE 29119가 테스트 프로세스의 구조와 활동을 설명하는 표준이라면, ISO/IEC 33063은 그 테스트 프로세스를 평가하는 데 활용되는 표준이라고 볼 수 있다. 따라서 ISO/IEC 33063은 앞서 살펴본 ISO/IEC/IEEE 29119의 세 가지 테스트 프로세스를 평가하기 위한 기준으로 활용된다.

이 표준은 테스트 프로세스가 제대로 수행되고 있는지 확인하고, 개선이 필요한 부분을 찾는 데 참고할 수 있다.

참고: ISO/IEC 33063 Process Assessment Model for Software Testing

ISO/IEC 33063에서는 소프트웨어 테스팅(Software Testing) 프로세스를 평가한 뒤, 해당 프로젝트(Project) 또는 조직(Organization)의 능력과 역량을 등급으로 정의한다. 이 등급은 0부터 5까지의 능력 수준(Capability Level)으로 제시되며, 0이 가장 낮은 수준이고 5가 가장 우수한 수준이다.

먼저 레벨 0(Level 0)은 불완전한 프로세스(Incomplete Process)에 해당한다. 테스트 프로세스(Test Process) 자체가 존재하지 않거나, 프로세스가 있더라도 실제 수행 결과가 거의 없는 상태이다. 체계적인 테스트 설계(Test Design) 없이 테스트 수행(Test Execution)에만 급급하고, 일부 테스트 결과만 남아 있는 매우 부족한 조직이라고 볼 수 있다.

레벨 1(Level 1)은 수행된 프로세스(Performed Process)에 해당한다. 이 수준의 조직은 테스트를 실제로 수행한다. 예를 들어 블랙박스 테스트(Black-box Test)나 화이트박스 테스트(White-box Test) 기법을 적용하여 테스트를 진행하고, 그 결과도 존재한다. 하지만 여전히 많은 조직들이 레벨 0과 레벨 1 사이에 머물러 있다.

우리가 지향해야 할 수준은 적어도 레벨 2(Level 2)이다. 레벨 2는 관리된 프로세스(Managed Process)를 의미한다. 이 수준에서는 PDCA Cycle에 기반하여 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가와 개선(Test Evaluation and Improvement) 과정이 지속적으로 운영된다. 즉, 테스트가 단순히 수행되는 것에 그치지 않고, 관리 관점에서 체계적으로 진행되는 조직이라고 할 수 있다.

레벨 3(Level 3)은 정립된 프로세스(Established Process)에 해당한다. 레벨 2와 레벨 3은 적용 범위에서 차이가 있다. 레벨 2가 개별 프로젝트(Project) 단위에서 테스트 프로세스를 관리하는 수준이라면, 레벨 3은 조직(Organization) 차원에서 표준 테스트 프로세스(Standard Test Process)가 정립되어 있는 수준이다. 즉, 특정 프로젝트에만 적용되는 것이 아니라 조직 전체에서 공통적으로 활용할 수 있는 테스트 프로세스가 마련되어 있는 단계이다.

레벨 4(Level 4)는 예측 가능한 프로세스(Predictable Process)에 해당한다. 이 수준에서는 한두 개의 테스트 케이스(Test Case) 결과만으로 품질을 판단하는 것이 아니라, 여러 유사 프로젝트에서 수집한 정량적 데이터(Quantitative Data)를 기반으로 품질을 예측한다. 예를 들어 20~30개 이상의 프로젝트 결과를 모아 표준화된 프로세스(Standardized Process)를 분석하고, 이를 통해 향후 프로젝트의 품질을 예측하는 방식이다.

레벨 5(Level 5)는 최적화된 프로세스(Optimizing Process)에 해당한다. 레벨 5에서는 레벨 4에서 예측한 결과를 바탕으로 문제점을 분석하고, 테스트 프로세스를 지속적으로 개선(Continuous Improvement)한다. 즉, 정량적 데이터와 예측 결과를 활용하여 조직의 테스트 역량을 계속 발전시키는 단계라고 볼 수 있다.

다만 레벨 4와 레벨 5는 매우 이상적인 수준에 가깝다. 따라서 모든 조직이 반드시 이 단계까지 도달해야 한다고 보기보다는, 실무에서는 우선 레벨 2를 목표로 하는 것이 현실적이다. 즉, 단순히 프로젝트를 수행하는 수준을 넘어 PDCA Cycle에 기반하여 테스트를 계획하고, 설계하고, 수행하고, 평가하고 개선하는 관리된 프로세스(Managed Process)를 갖추는 것이 중요하다.

이후 레벨 2가 안정적으로 이루어진다면, 조직 차원의 표준 테스트 프로세스를 정립하는 레벨 3(Level 3)까지 고려해볼 수 있다.

테스트 평가와 개선의 주요 활동: 테스트 결과 분석 및 평가

(Main Activities of Test Evaluation and Improvement: Test Result Analysis and Evaluation)

테스트 평가와 개선(Test Evaluation and Improvement)의 주요 활동 중 하나는 테스트 결과 분석 및 평가(Test Result Analysis and Evaluation)이다. 이는 수행된 테스트가 얼마나 효과적이었는지, 그리고 그 효과를 달성하기 위해 어느 정도의 비용이 소요되었는지를 평가하는 과정이다.

먼저 테스트 효과성(Test Effectiveness)은 테스트를 통해 얼마나 많은 결함(Defect)을 검출했는지를 기준으로 평가한다. 테스트의 목적은 결함을 찾는 데 있으므로, 좋은 테스트 케이스(Test Case)는 결함을 잘 발견할 수 있어야 한다. 테스트 케이스를 여러 개 작성했을 때, 테스트 결과가 성공(Pass)이라는 것은 예상 결과(Expected Result)와 실제 결과(Actual Result)가 일치했다는 의미이다. 반대로 실패(Fail)는 예상한 결과가 나오지 않았다는 뜻이며, 이 경우 결함을 발견했을 가능성이 있다.

따라서 테스트 케이스 실패율(Test Case Failure Rate)은 테스트 효과성을 평가하는 지표로 활용될 수 있다. 테스트 케이스 실패율은 실패한 테스트 케이스 수(Number of Failed Test Cases)를 전체 테스트 케이스 수(Total Number of Test Cases)로 나눈 뒤 100을 곱해 계산한다.

예를 들어 전체 테스트 케이스가 30개이고, 그중 실패한 테스트 케이스가 15개라면 테스트 케이스 실패율은 다음과 같다.

15개 / 30개 × 100% = 50%

이는 전체 테스트 케이스 중 50%가 실패했으며, 그만큼 결함 발견과 연결될 수 있음을 의미한다. 즉, 테스트 케이스 실패율은 테스트가 결함을 얼마나 찾아냈는지를 보여주는 효과성 지표로 볼 수 있다.

다음으로 테스트 효율성(Test Efficiency)은 테스트 효과를 달성하는 데 소요된 비용이나 공수(Effort)를 함께 고려하는 지표이다. 같은 효과를 얻더라도 더 적은 시간과 비용으로 수행했다면 더 효율적인 테스트라고 볼 수 있다.

예를 들어 테스트 효과성(Test Effectiveness), 즉 테스트 케이스 실패율이 50%이고, 테스트 소요 비용 또는 공수(Test Effort)가 5시간이라고 하자. 이때 테스트 효율성(Test Efficiency)은 테스트 효과성을 테스트 소요 비용으로 나누어 계산할 수 있다.

테스트 효율성(Test Efficiency) = 테스트 효과성(Test Effectiveness) / 테스트 소요 비용(Test Effort)

따라서 위 예시는 다음과 같이 계산된다.

50% / 5시간 = 시간당 10%

이는 테스트를 수행할 때 시간당 약 10% 수준의 결함 발견 효과를 얻을 수 있는 테스트가 수행되었다고 해석할 수 있다.

이처럼 테스트 결과 분석 및 평가(Test Result Analysis and Evaluation)는 테스트 케이스 실패율(Test Case Failure Rate), 테스트 효과성(Test Effectiveness), 테스트 효율성(Test Efficiency)과 같은 지표를 기반으로 테스트 프로세스(Test Process)가 얼마나 적절하게 수행되었는지를 평가하는 과정이다. 지표를 활용하면 테스트 활동의 성과를 정량적으로 파악할 수 있고, 이후 테스트 프로세스를 개선하는 데 필요한 근거로 활용할 수 있다.

테스트 평가와 개선의 주요 활동: 대책 수립 및 시정안 권고

(Main Activities of Test Evaluation and Improvement: Countermeasure Planning and Corrective Action Recommendation)

테스트 평가와 개선(Test Evaluation and Improvement)의 주요 활동에는 대책 수립(Countermeasure Planning)과 시정안 권고(Corrective Action Recommendation)가 포함된다. 이는 테스트 효과성(Test Effectiveness)과 테스트 효율성(Test Efficiency)을 높이기 위해 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution) 등의 활동에 대한 개선 방안을 마련하고, 그에 따라 조치를 수행하는 과정이다.

먼저 테스트 계획(Test Planning)에 대한 개선 방안을 살펴볼 수 있다. 테스트 효과성 지표(Test Effectiveness Metric)에는 테스트 케이스 실패율(Test Case Failure Rate)이 있다. 테스트 케이스 실패율이 낮다는 것은 결함을 검출하지 못한 테스트 케이스가 많다는 의미로 볼 수 있다. 엄밀히 말하면 테스트 케이스(Test Case)가 결함을 잘 찾지 못하도록 만들어졌다는 뜻이므로, 테스트 케이스의 품질을 다시 검토해야 한다.

이 경우 개선 방안으로 위험 분석(Risk Analysis)을 철저히 수행할 수 있다. 결함이 발생할 가능성이 높은 기능이나 품질에 큰 영향을 미치는 기능을 중심으로 테스트하면 테스트의 효과성을 높일 수 있다. 따라서 기존에 위험 분석을 제대로 수행하지 않았던 조직이라면, 테스트 효과를 높이기 위해 테스트 계획 단계에서 위험 분석을 반드시 진행하도록 권고할 수 있다.

다음으로 테스트 설계(Test Design)에 대한 개선 방안을 살펴볼 수 있다. 테스트 소요 비용(Test Cost)이나 공수(Effort)가 크다는 것은 많은 시간과 인력을 들였음에도 테스트가 충분히 효과적이지 않을 수 있다는 의미이다. 그 원인을 분석해 보니 사람이 반복적인 테스트를 일일이 수동(Manual)으로 수행하고 있었다면, 테스트 자동화(Test Automation)를 개선 방안으로 제시할 수 있다.

테스트 자동화 도구(Test Automation Tool)를 도입하면 사람이 반복적으로 수행하던 부분을 도구 기반으로 실행할 수 있다. 이를 통해 반복 작업에 드는 시간과 비용을 줄이고, 사람은 더 창의적이고 생산적인 업무에 집중할 수 있다.

즉, 대책 수립과 시정안 권고는 테스트 평가 결과를 바탕으로 테스트 계획, 설계, 수행 활동의 문제점을 찾고, 테스트 효과성과 효율성을 높이기 위한 개선 방안을 제시하는 활동이다. 테스트 자동화(Test Automation)는 이러한 개선 방안 중 하나이며, 이후 주차에서 더 자세히 다룰 예정이다.

테스트 프로세스 전체 요약 (Summary of Test Process)

지금까지 테스트(Test)를 평가하고 개선하는 과정까지 살펴보았다. 전체 내용을 간략히 정리하면 다음과 같다.

테스트 표준(Test Standard)에서는 테스트 프로세스(Test Process)를 크게 세 가지 범주로 나눈다. 첫 번째는 조직 차원의 테스트 프로세스(Organizational Test Process), 두 번째는 테스트 관리 프로세스(Test Management Process), 세 번째는 동적 테스트 프로세스(Dynamic Test Process)이다.

먼저 조직 차원의 테스트 프로세스(Organizational Test Process)는 전체 조직 차원에서 테스트 정책(Test Policy)과 테스트 전략(Test Strategy)을 수립하는 활동이다. 하지만 처음 수립한 정책과 전략이 항상 완전한 것은 아니기 때문에, 실제 테스트를 수행하면서 얻은 피드백(Feedback)을 바탕으로 계속 업데이트하고 개선해야 한다.

다음으로 프로젝트 차원의 테스트 관리 프로세스(Test Management Process)는 테스트를 체계적으로 수행하기 위해 테스트 계획(Test Planning)을 세우는 과정이다. 프로젝트 단위에서 어떤 테스트를 어떻게 수행할 것인지 계획하고, 테스트가 일정과 목표에 맞게 진행될 수 있도록 관리한다.

실제로 테스트를 수행하는 부분은 동적 테스트 프로세스(Dynamic Test Process)에 해당한다. 동적 테스트 프로세스는 테스트 설계 및 구현(Test Design and Implementation), 테스트 환경 구성 및 유지(Test Environment Setup and Maintenance), 테스트 수행(Test Execution), 테스트 결과 보고(Test Result Reporting)로 이루어진다. 이 과정에서 테스트 케이스(Test Case)를 실행하고, 결과를 기록하며, 결함(Defect)을 식별하고 보고한다.

동적 테스트 프로세스에서 나온 결과와 데이터는 다시 테스트 관리 프로세스로 전달된다. 이후 테스트 관리 차원에서는 이 데이터를 측정(Measurement)하고, 모니터링(Monitoring)하며, 필요한 경우 제어(Control)한다. 테스트가 완료되면 그 결과는 다시 조직 차원으로 전달되어, 조직의 테스트 정책과 전략을 지속적으로 개선하는 데 활용된다.

즉, 테스트 프로세스는 단순히 테스트를 수행하고 끝나는 것이 아니라, 조직 차원의 정책과 전략, 프로젝트 차원의 계획과 관리, 실제 테스트 수행과 결과 보고가 서로 연결되어 순환하는 구조이다. 테스트를 통해 얻은 데이터와 피드백은 다시 상위 프로세스로 전달되고, 이를 기반으로 테스트 프로세스 전체가 지속적으로 개선된다.

이 내용은 그동안 여러 주차에 걸쳐 학습한 테스트 프로세스의 세부 내용을 종합적으로 정리한 요약 자료로 이해할 수 있다.

프로세스(Process)와 프로그램(Program)의 차이

첫 번째로 다루는 개념은 프로세스(Process) 와 프로그램(Program) 의 차이이다.
일상적으로는 두 용어를 크게 구분하지 않고 사용하는 경우가 많다. 하지만 전공 수업이나 운영체제(Operating System) 분야에서는 두 개념을 구분해서 사용한다.

일반적인 사용에서는 큰 차이가 없어 보일 수 있지만, 시스템을 이해하기 위해서는 프로그램과 프로세스를 나누어 생각해야 한다.

프로그램(Program)

프로그램은 기본적으로 스토리지(Storage) 에 저장되어 있는 상태를 의미한다. 여기서 스토리지는 디스크, SSD, USB, CD와 같은 저장장치를 포함한다.

프로그램은 결국 이러한 저장장치 안에 보관되어 있는 명령어(Instruction)들의 모임이다.

즉, 엔지니어가 프로그램을 작성하고 저장하면, 그것은 파일(File)의 형태로 스토리지에 존재하게 된다.

교수님은 프로그램의 특징을 다음과 같이 설명했다.

• 스토리지에서 제거되기 전까지 계속 존재한다.

• 파일 형태로 생성되고 보존된다.

• 스토리지(Storage)에 저장된 상태이다.

• 명령어들의 집합이다.

• 파일(File) 형태로 존재한다.

• 실행되기 전의 정적인 상태(static state)를 의미한다.

• 프로세스(Process)와 구분하기 위해 CPU와 RAM을 사용하지 않는다고 설명한다.

여기서 “CPU와 RAM을 사용하지 않는다”는 표현은 절대적인 의미라기보다는, 프로세스(Process)와 구분하기 위한 설명이라고 강조했다. 실제로는 프로그램을 작성하거나 저장하는 과정 자체가 컴퓨터 위에서 이루어지므로 CPU와 RAM이 완전히 사용되지 않는 것은 아니다. 다만 운영체제 개념에서는, 저장장치에 보관된 정적인 상태(static state)의 대상을 설명하기 위해 이렇게 표현한다.

프로세스(Process)

그렇다면 프로세스(Process)는 무엇을 의미할까?

일상적으로는 프로그램과 프로세스를 거의 같은 의미처럼 사용하는 경우가 많다. 하지만 운영체제(Operating System)를 배우는 과정에서는 두 개념을 구분해서 이해해야 한다. 프로그램이 단순히 저장되어 있는 상태라면, 프로세스는 실제로 실행되면서 활동하고 있는 상태를 의미한다. 교수님 설명에서 가장 중요하게 강조된 부분은 다음이다.

프로세스는 CPU와 RAM을 사용하고 있으며, 그 안에서 존재하는 실행 단위이다.

앞에서 프로그램은 스토리지(Storage)에 저장되어 있는 명령어들의 집합이라고 설명했다. 디스크(Disk), SSD, USB 같은 저장장치 안에 파일(File) 형태로 존재하는 것이 프로그램이다. 이 상태의 프로그램은 정적인 상태(static state)에 가깝다.

반면 프로세스는 저장되어 있던 프로그램이 실제로 실행되면서 CPU와 RAM 자원을 사용하는 상태를 의미한다. 즉, 프로그램이 움직이기 시작한 순간부터 프로세스라는 개념으로 바라보게 되는 것이다.

교수님은 이 부분을 설명하면서 “CPU와 RAM에 존재해야 프로세스라고 말할 수 있다”고 표현했다. 결국 프로세스라는 개념은 단순히 저장된 파일이 아니라, 시스템 자원을 사용하며 실제로 동작하고 있는 상태를 나타내기 위해 등장한 것이다.

프로그램이 실행되는 과정도 함께 설명했다.

우리가 작성한 프로그램은 원래 스토리지에 저장되어 있다. 하지만 실행 버튼을 누르는 순간 운영체제(Operating System)는 그 프로그램을 메모리(RAM)로 옮긴다. 교수님은 이 과정을 “로드(load)”라고 설명했다.

여기서 load라는 표현은 단순히 데이터를 읽는다는 의미보다, 실제로 짐을 옮기는 것에 가까운 개념이라고 설명했다. 예를 들어 창고에 있던 물건을 배송 차량으로 옮기는 것처럼, 스토리지에 저장되어 있던 프로그램 코드가 RAM으로 이동하는 것이다.

즉 프로그램 실행 과정은 다음과 같이 이해할 수 있다.

스토리지(Storage)에 저장되어 있던 프로그램이 실행 요청을 받으면, 운영체제가 해당 프로그램을 RAM으로 적재(load)한다. 이후 CPU는 RAM에 올라온 명령어와 데이터를 읽어 연산을 수행한다. 그리고 이 데이터들은 CPU 내부의 Cache나 Register 같은 구성 요소를 오가며 처리된다.

교수님은 특히 Register를 언급하면서, CPU 안에서 매우 빠르게 데이터를 주고받으며 연산이 이루어진다고 설명했다. 결국 이러한 과정이 반복되면서 화면 출력이나 계산 결과처럼 사용자가 직접 확인할 수 있는 결과가 만들어진다.

또한 프로세스는 메모리 안에서 여러 영역으로 나뉘어 동작한다고 설명했다. 대표적으로 다음과 같은 구조를 가진다.

• 코드(Code)

• 데이터(Data)

• 스택(Stack)

• 힙(Heap)

즉 프로세스는 단순히 “실행 중이다”라는 의미만 가지는 것이 아니라, 메모리 안에서 여러 영역을 구성하며 체계적으로 동작하는 실행 단위라고 볼 수 있다.

동시 실행(Concurrent Execution)과 작업(Job)

앞에서는 프로그램(Program)과 프로세스(Process)의 차이를 구분해서 살펴보았다.
이번에는 그 개념에서 이어져, 컴퓨터가 실제로 어떻게 여러 작업을 실행하는지와 Job이라는 표현에 대해 설명한다. 교수님은 먼저 하나의 질문을 던졌다.

컴퓨터는 한 번에 하나의 프로그램만 실행할까, 아니면 동시에 여러 개를 실행할까?

결론부터 말하면 컴퓨터는 여러 작업을 동시에 실행하고 있다. 스마트폰 역시 마찬가지이다.

우리가 스마트폰이나 컴퓨터를 사용할 때는 보통 하나의 화면만 집중해서 보고 있기 때문에, 마치 하나의 프로그램만 실행되는 것처럼 느껴질 수 있다. 하지만 실제 내부에서는 브라우저, 메신저, 음악 재생, 네트워크 처리, 운영체제 서비스 등 수많은 프로그램이 동시에 동작하고 있다.

물론 사용자가 직접 인터랙션(interaction)하고 있는 프로그램은 보통 하나처럼 보인다. 예를 들어 키보드를 입력하거나 화면을 터치할 때는 현재 활성화된 프로그램만 눈에 띈다. 그러나 동영상을 띄워두거나 여러 창(window)을 동시에 배치하면, 여러 프로그램이 함께 동작하고 있다는 사실을 더 쉽게 확인할 수 있다.

Job(작업)의 의미

이 과정에서 교수님은 Job(작업) 이라는 표현을 소개했다.

Job이라는 용어는 초기 컴퓨터 역사에서 유래했다고 설명했다. 과거에는 사람이 펀치카드(Punch Card)를 사용하여 컴퓨터에 작업을 요청했고, 컴퓨터는 이를 순서대로 처리하는 배치 처리(Batch Processing) 방식을 사용했다. 여기서 하나의 작업 단위를 Job이라고 부르게 된 것이다.

교수님은 컴퓨터 용어 중 상당수가 원래 사람이 일하던 환경에서 가져온 표현이라고 설명했다. 컴퓨터는 결국 사람의 일을 대신 처리하는 기계이기 때문에, 실제 인간 사회에서 사용되던 용어들이 컴퓨터 분야로 자연스럽게 넘어왔다는 것이다.

예를 들어 전공자들은 “함수(Function)”라는 말을 들으면 프로그래밍 개념을 먼저 떠올리지만, 다른 분야 사람들은 전혀 다른 의미를 생각할 수도 있다. 이처럼 컴퓨터 분야에서는 특정 단어가 거의 고유명사처럼 사용되지만, 원래는 일반적인 의미를 가진 용어였다는 점을 강조했다.

하나의 Job과 여러 개의 프로세스

교수님은 하나의 작업(Job)이 반드시 하나의 프로세스(Process)만 의미하는 것은 아니라고 설명했다. 하나의 작업(Job)은 하나 이상의 프로세스로 구성될 수 있다. 앞에서 프로세스는 CPU와 RAM을 사용하며 실제로 동작하고 있는 살아있는 상태라고 설명했다. 이러한 프로세스 여러 개를 하나로 묶어서 하나의 Job으로 볼 수 있다는 것이다.

• 프로세스(Process) → 실제 실행 단위

• 잡(Job) → 사용자 입장에서 묶어서 바라보는 작업 단위라고 이해할 수 있다.

커널(Kernel) 관점과 사용자(User) 관점

교수님은 프로세스와 잡을 구분하는 또 다른 기준으로 “누가 관리하느냐”를 설명했다. 프로세스(Process)는 운영체제의 커널(Kernel) 관점에서 추적하고 관리하는 대상이다. 반면 Job은 사용자(User)나 쉘(Shell) 관점에서 관리하는 작업 단위이다.

즉 운영체제 내부에서는 각각의 프로세스를 개별적으로 관리하지만, 사용자는 여러 프로세스를 하나의 작업처럼 다루게 되는 경우가 있다는 의미이다.

이 때문에 각각 다른 식별자(identifier)를 사용한다.

• 프로세스 → PID(Process ID)

• 작업(Job) → JID(Job ID)

교수님은 여기서 “왜 이렇게 비슷한 개념을 계속 세분화하는가?”라는 의문이 생길 수 있다고 설명했다. 하지만 전공이나 전문 분야로 갈수록 더욱 세밀한 구분이 필요해진다고 말했다.

예를 들어 우리가 일상적으로는 모두 “쌀”이라고 부르지만, 실제로는 품종과 특성이 매우 다양하게 나뉘는 것과 비슷한 개념이라고 설명했다.

백그라운드(Background) 실행

마지막으로 교수님은 Job이라는 표현이 보통 백그라운드(background)에서 실행되는 프로그램을 의미하는 경우가 많다고 설명했다. 여기서 백그라운드는 사용자가 직접 화면에서 조작하지 않아도 뒤에서 계속 실행되는 상태를 의미한다.

그리고 이에 대비되는 개념이 바로 포어그라운드(Foreground)이다. Foreground는 사용자가 현재 직접 상호작용(interaction)하고 있는 실행 상태를 의미하며, 이에 대한 내용은 다음 슬라이드에서 이어서 설명한다고 언급했다.

동시 실행과 포어그라운드(Foreground)

프로그램과 프로세스(Process)의 차이를 이해했다면, 이제 실제 컴퓨터가 어떻게 여러 작업을 처리하는지 자연스럽게 이어서 생각해볼 수 있다. 컴퓨터는 한 번에 하나의 프로그램만 실행하는 것처럼 보이기도 하지만, 실제로는 여러 작업이 동시에 실행되고 있다.

스마트폰만 보더라도 쉽게 알 수 있다. 사용자는 현재 하나의 앱 화면만 보고 터치하고 있을 수 있지만, 그 뒤에서는 음악 재생, 네트워크 통신, 알림 처리, 메신저, 운영체제 서비스 등 수많은 프로그램이 함께 동작하고 있다. 컴퓨터 역시 마찬가지이다.

다만 사용자가 직접 보고 상호작용(interaction)하는 프로그램은 보통 하나처럼 느껴진다. 특히 리눅스(Linux) 터미널(Terminal) 환경에서는 이러한 특징이 더욱 뚜렷하게 보인다.

리눅스 서버에 접속하면 흔히 검은 화면의 문자 기반 환경을 보게 된다. 사용자는 쉘(Shell)에 명령어(command)를 입력하고 엔터(Enter)를 누른다. 그러면 프로그램이 실행되고, 실행이 끝나면 다시 입력을 기다리는 상태로 돌아간다. 이때 화면에는 깜빡이는 커서(cursor)가 나타난다.

보통 우리가 예제로 실행하는 프로그램들은 수행 시간이 매우 짧다. 그래서 명령을 입력하면 곧바로 결과가 출력되고 다시 프롬프트(prompt)가 나타난다. 이러한 흐름에 익숙해지다 보니, 자연스럽게 “현재 실행 중인 작업이 끝나야 다음 입력을 할 수 있다”는 방식으로 터미널 환경을 이해하게 된다.

즉 기본적인 쉘 환경은 다음과 같은 흐름으로 동작한다.

1. 사용자가 명령어를 입력한다.

2. 프로그램이 실행된다.

3. 실행이 종료된다.

4. 다시 입력 대기 상태로 돌아간다.

이 구조만 보면 하나의 터미널에서는 동시에 여러 작업을 할 수 없는 것처럼 느껴질 수 있다. 하지만 실제로는 그렇지 않다.

Ctrl + Z 와 작업(Job) 제어

쉘 환경에서는 실행 중인 프로그램을 일시적으로 멈출 수도 있다. 대표적인 방법이 Ctrl + Z 이다.

실행 중인 프로그램에서 Ctrl + Z를 입력하면 현재 작업이 중단(suspend)된다. 중요한 점은 프로그램이 종료되는 것이 아니라, 실행이 멈춘 상태로 유지된다는 것이다.

중단된 작업들은 jobs 명령어를 통해 확인할 수 있다.

이러한 방식은 GUI(Graphical User Interface)에 익숙한 사용자들에게는 다소 낯설 수 있다. 일반적인 데스크톱 환경에서는 여러 창(window)을 띄워놓고 프로그램을 동시에 실행하기 때문에, foreground나 background를 직접 의식하지 않는 경우가 많다.

하지만 현재 다루는 CLI(Command Line Interface) 환경은 하나의 터미널 창 안에서 여러 작업을 관리해야 하는 구조이다. 그래서 작업을 어떻게 중단하고, 다시 실행하며, 앞에서 실행할지 뒤에서 실행할지를 구분하는 개념이 중요해진다.

Foreground와 Background

이 과정에서 등장하는 개념이 바로 Foreground와 Background이다.

Foreground(포어그라운드)는 사용자가 현재 직접 상호작용하고 있는 상태를 의미한다. 키보드 입력을 받고 화면에 결과를 출력하며, 사용자가 “지금 보고 있는 작업”이라고 생각하면 이해하기 쉽다. 반면 Background(백그라운드)는 사용자가 직접 보고 있지는 않지만 뒤에서 계속 실행되고 있는 상태를 의미한다.

예를 들어 현재 터미널에서 직접 실행 중인 프로그램은 foreground 작업이고, 뒤에서 계속 동작하도록 돌려놓은 프로그램은 background 작업이 된다.

이처럼 하나의 작업 공간 안에서도 “앞에서 실행되는 작업”과 “뒤에서 실행되는 작업”이 나뉘어 존재하게 된다.

fg 와 bg 명령어

중단된 작업은 다시 실행할 수도 있다.

fg 명령어를 사용하면 작업을 foreground 상태로 가져와 다시 실행할 수 있고, bg 명령어를 사용하면 background 상태에서 계속 실행되도록 만들 수 있다.

즉 Ctrl + Z로 잠시 멈춘 프로그램을 다시 앞에서 실행할 수도 있고, 사용자가 다른 작업을 계속할 수 있도록 뒤에서 실행시킬 수도 있는 것이다.

이러한 기능은 하나의 터미널 환경 안에서도 여러 작업을 효율적으로 관리할 수 있게 해준다.

Job 번호(Job ID)

쉘(Shell)은 여러 작업(Job)을 동시에 관리할 수 있기 때문에, 각 작업에는 번호가 부여된다. 이를 Job ID(JID)라고 한다.

사용자는 이 번호를 기준으로 어떤 작업이 실행 중인지, 어떤 작업이 중단되었는지, 어떤 작업을 foreground나 background로 전환할 것인지 관리하게 된다.

앞에서 프로세스(Process)가 운영체제 커널(Kernel) 관점에서 관리되는 실행 단위였다면, Job은 사용자와 쉘 관점에서 관리되는 작업 단위라고 볼 수 있다.

동시 실행과 백그라운드(Background)

백그라운드(Background)는 사용자가 직접 보고 입력하지는 않지만, 뒤에서 계속 실행되고 있는 작업을 의미한다. 즉 백그라운드 프로세스(background process)로 실행되는 프로그램을 백그라운드 작업이라고 부른다.

리눅스(Linux)나 유닉스(UNIX) 쉘(Shell)에서는 명령어 뒤에 &를 붙이면 프로그램을 백그라운드로 실행할 수 있다.

예를 들어 일반적으로 프로그램을 실행하면 해당 작업이 끝날 때까지 터미널을 사용할 수 없다. 하지만:

command &

처럼 실행하면 프로그램은 뒤에서 계속 동작하고, 사용자는 바로 프롬프트(prompt)를 다시 받아 다른 명령을 입력할 수 있게 된다. 즉 터미널의 제어권(control)을 다시 돌려받는 것이다.

하지만 백그라운드 작업도 화면 출력(output)을 할 수 있다. 프로그램이 표준출력(Standard Output)을 사용하면, 뒤에서 실행 중이어도 터미널 화면에 내용이 출력될 수 있다.

이 경우 사용자가 다른 작업을 하고 있는데 갑자기 로그나 메시지가 화면에 출력되어 작업 흐름을 방해할 수 있다.

이를 막기 위해 사용하는 설정이:

stty tostop

이다. 이 설정을 사용하면 백그라운드 작업이 터미널 화면에 출력하려고 할 때 해당 작업을 정지(stop)시킬 수 있다. 즉 백그라운드 프로그램이 터미널을 함부로 사용하는 것을 막는 역할을 한다.

동시 실행과 데몬(Daemon)

데몬(Daemon)은 사용자가 직접 상호작용(interaction)하지 않는 상태에서 뒤에서 계속 실행되는 프로그램을 의미한다. 즉 사용자가 키보드로 입력하거나 화면을 직접 조작하지 않아도 시스템 내부에서 지속적으로 동작하는 프로세스(process)이다.

보통 데몬은 백그라운드(background) 프로세스 형태로 실행된다. 사용자는 존재를 크게 의식하지 않지만, 시스템 기능을 유지하거나 특정 서비스를 제공하기 위해 계속 동작하고 있다.

예를 들어 서버(server) 기능이나 네트워크(network) 관련 서비스들도 대부분 이러한 방식으로 동작한다.

데몬 프로그램은 관습적으로 이름 끝에 d가 붙는 경우가 많다. 예를 들어 일반 프로그램이:

hello.c

처럼 작성된다면, 데몬 형태로 동작하는 프로그램은:

hellod

또는 이름 끝에 d를 붙이는 방식으로 표현하는 경우가 많다. 다만 이는 어디까지나 관습(convention)일 뿐이며, 반드시 그렇게 해야 하는 것은 아니다.

또한 데몬은 보통 시스템이 시작될 때부터 함께 실행되며, 오랫동안 지속적으로 동작한다. 이 과정에서 관리자 권한인 root 권한으로 실행되는 경우도 많다.

즉 데몬은:

• 사용자가 직접 조작하지 않고

• 백그라운드에서 실행되며

• 시스템 시작과 함께 동작하고

• 장시간 계속 실행되는 프로그램이라고 이해할 수 있다.

📌데몬(Daemon)과 백그라운드(Background)의 차이

데몬(Daemon)과 백그라운드(Background)는 모두 뒤에서 실행된다는 공통점이 있지만, 완전히 같은 개념은 아니다.

백그라운드 프로세스는 단순히 사용자가 직접 제어하지 않고 뒤에서 실행되고 있는 모든 프로그램을 의미한다. 예를 들어 &를 붙여 실행한 프로그램이나, 터미널에서 직접 보고 있지 않지만 계속 동작 중인 작업들이 모두 백그라운드에 해당할 수 있다.

반면 데몬(Daemon)은 그중에서도 특정한 특징을 가진 프로그램을 따로 부르는 이름이다. 즉 백그라운드 프로세스라는 큰 범주 안에 데몬이라는 개념이 포함된다고 볼 수 있다. 데몬은 단순히 “뒤에서 실행되는 프로그램”이 아니라, 시스템 기능을 위해 계속 동작하는 백그라운드 프로그램이라고 이해할 수 있다.

또 하나 중요한 점은 용어 사용에서 “프로그램”과 “프로세스”가 혼용된다는 것이다.

데몬을 설명할 때도 “백그라운드 프로세스로 실행되는 프로그램”이라는 표현을 사용했는데, 이는 실제로는 같은 대상을 서로 다른 관점에서 부르는 것이다.

• 프로그램(Program) → 저장된 실행 파일

• 프로세스(Process) → 실행 중인 상태

하지만 실제 설명에서는 두 용어가 문맥에 따라 혼용되는 경우가 많다. 데몬 역시 “프로그램”이라고 부르기도 하고 “프로세스”라고 부르기도 한다.

결론적으로 정리하면 다음과 같다.

• 백그라운드: 뒤에서 실행되는 모든 작업

• 데몬: 그중에서도 시스템 서비스처럼 지속적으로 동작하는 특수한 백그라운드 프로세스

• 프로그램/프로세스: 문맥에 따라 혼용되지만, 엄밀히는 실행 전/실행 중 상태의 차이

이처럼 운영체제(Operating System) 개념에서는 용어가 엄격하게 나뉘어 있지만, 실제 설명이나 시험에서는 문맥에 따라 서로 섞여 사용되기도 한다. 따라서 “같은 의미로도 쓰이지만, 구분하면 다르다”는 관점으로 이해하는 것이 중요하다.

프로세스 정보 확인: ps(process status) (1/3)

ps(process status) 명령어는 현재 실행 중인 프로세스(Process)의 상태를 확인하는 데 사용된다. 즉, 특정 시점에서 시스템 안에서 어떤 프로세스들이 동작하고 있는지를 보여주는 도구이다.

PID (Process ID)

각 프로세스는 생성될 때 고유한 ID를 부여받는다. 이를 PID(Process ID)라고 한다. 컴퓨터는 기본적으로 모든 대상을 숫자로 구분한다. 사람은 이름으로 구분하는 것이 익숙하지만, 컴퓨터는 효율적인 처리를 위해 숫자 기반으로 식별한다. 프로세스도 마찬가지로 각각 고유한 숫자 ID를 가진다. 이 PID는 프로세스가 생성되는 순서에 따라 부여되며, 시스템 환경에 따라 표현할 수 있는 범위가 달라진다. 예를 들어 32비트 시스템과 64비트 시스템은 처리 가능한 숫자의 범위와 관리 방식이 다를 수 있다.

PID 범위와 관리

리눅스(Linux)에서는 PID의 최대값을 확인할 수 있다.

cat /proc/sys/kernel/pid_max

이 값은 시스템 설정에 따라 달라지며, 생성 가능한 PID의 최대 범위를 의미한다.

예를 들어 최대값이 100이라고 가정했을 때, 프로세스가 계속 생성되어 100을 초과하면 단순히 0으로 돌아가는 방식이 아니라, 사용 가능한 다른 번호를 찾아 할당하게 된다.

즉 PID는 순환 구조처럼 보일 수 있지만, 실제로는 시스템이 사용 가능한 번호를 재배치하는 방식으로 관리된다.

PID 0과 1

리눅스 시스템에는 특별한 PID가 존재한다.

• PID 0: swapper / idle task (kernel thread)

• PID 1: init (또는 systemd 등 초기 사용자 공간 프로세스)

PID 0은 시스템 내부에서 CPU가 할 일이 없을 때 동작하는 idle 상태와 관련된 커널(kernel) 프로세스이다. 일반적으로 사용자에게 직접 보이는 프로세스는 아니다.

PID 1은 시스템이 부팅될 때 가장 먼저 실행되는 기본 프로세스로, 이후 다른 모든 프로세스의 시작점이 된다.

부모-자식 구조 (PPID)

프로세스에는 부모-자식 관계가 존재한다. 이를 나타내는 것이 PPID(Parent Process ID)이다.

즉 새로운 프로세스는 기존 프로세스에 의해 생성되며, 이 관계를 통해 시스템은 프로세스 구조를 트리(tree) 형태로 관리한다.

ps 명령 출력 정보

ps 명령을 실행하면 다음과 같은 정보들이 함께 출력된다.

• PID (Process ID)

• TTY (Terminal Type)

• TIME (CPU 사용 시간)

• CMD / COMMAND (실행된 명령어)

이 정보들을 통해 현재 어떤 프로세스가 실행되고 있는지, 어떤 터미널에서 실행되었는지, 어떤 명령으로 시작되었는지를 확인할 수 있다.

의미 정리

ps 명령은 단순히 프로세스 목록을 보여주는 것이 아니라, 시스템이 현재 어떤 작업들을 어떤 PID로 관리하고 있는지를 확인할 수 있는 도구이다.

즉 컴퓨터 내부에서는 모든 실행 단위가 숫자(PID)로 관리되고 있으며, 이를 통해 프로세스를 추적하고 제어할 수 있다.

ps 추가 설명 (Additional Explanation of ps (process status)) (2/3)

ps(process status) 명령어를 사용하면 현재 실행 중인 프로세스(Process)의 다양한 정보를 확인할 수 있다. 단순히 어떤 프로세스가 실행 중인지뿐만 아니라, 언제 시작되었고 어떤 상태로 동작하고 있는지도 함께 볼 수 있다.

그중 STIME 또는 START 항목은 프로세스의 시작 시간을 의미한다. 최근에 실행된 프로세스는 시간 형태로 표시되지만, 24시간 이상 지난 프로세스는 시간 대신 날짜 형태로 출력된다.

예를 들어 어떤 프로세스가 아주 오랫동안 실행 중이라고 해서, ps 명령이 “3000시간째 실행 중” 같은 정보를 자세하게 보여주지는 않는다. 애초에 ps는 현재 시점의 상태를 간단하게 확인하기 위한 도구이기 때문이다. 따라서 오래 실행된 프로세스는 “언제 시작되었는가” 정도만 표시해주는 방식으로 동작한다.

또 다른 중요한 항목은 STAT이다. 이는 현재 프로세스의 상태(state)를 나타낸다.

프로세스는 단순히 실행 중인 것만이 아니라, 대기(waiting), 중단(stopped), 실행(running) 등 여러 상태를 가질 수 있다. STAT 항목은 이러한 현재 상태를 문자 형태로 보여준다.

특히 BSD 형식의 ps 출력에서는 추가적인 상태 표시가 함께 붙기도 한다.

예를 들어: <, N, L, s, l, +

같은 문자들이 나타날 수 있는데, 이는 프로세스의 우선순위(priority), 세션(session) 여부, 멀티스레드(multithread) 상태 등 다양한 특성을 나타낸다.

즉 STAT는 단순히 “실행 중인가?”만 표시하는 것이 아니라, 현재 프로세스가 어떤 특성을 가진 상태인지까지 표현하는 정보라고 볼 수 있다.

이러한 프로세스 상태 개념은 운영체제(Operating System) 수업에서 더 자세히 다루게 된다. 운영체제 이론에서는 보통 프로세스 상태를 3단계, 5단계 등으로 나누어 설명한다.

예를 들어:

• 실행(Running), 준비(Ready), 대기(Waiting)

같은 형태로 구분한다. 하지만 실제 리눅스(Linux) 시스템에서 확인하는 상태와 운영체제 교과서에서 배우는 개념은 완전히 같지는 않을 수 있다.

이는 실제 운영체제가 이론적인 모델을 그대로 사용하는 것이 아니라, 시스템 발전 과정에서 불필요한 기능이 제거되거나 새로운 기능이 추가되고 성능 개선이 이루어졌기 때문이다.

즉 운영체제 수업에서 배우는 상태 모델은 개념 이해를 위한 구조이고, 리눅스는 이를 실제 시스템 환경에 맞게 구현하고 발전시킨 결과라고 이해할 수 있다.

Showing Current Process Status with ps (3/3)

ps(process status) 명령어는 현재 시점에서 실행 중인 프로세스(Process)의 상태를 보여준다. 이때 출력되는 정보에는 메모리 사용량, CPU 사용률, 프로세스 그룹 정보 등 다양한 항목이 포함된다.

RSS (Resident Set Size)

RSS(Resident Set Size)는 현재 프로세스가 실제로 사용 중인 물리 메모리(physical memory)의 크기를 의미한다. 보통 1000-byte 단위로 표시된다.

즉 프로세스가 RAM 안에서 실제 점유하고 있는 메모리 양이라고 이해할 수 있다.

VSZ (Virtual Memory Size)

VSZ(Virtual Memory Size)는 프로세스가 사용하는 가상 메모리(virtual memory)의 전체 크기를 의미한다. 일반적으로 1024-byte 단위로 표시된다.

이는 실제 물리 메모리만이 아니라, 프로세스가 사용할 수 있도록 할당된 가상 주소 공간까지 포함한 개념이다.

%CPU

%CPU는 해당 프로세스가 사용하는 CPU 비율을 의미한다. 이는 CPU time과 실제 경과 시간(real time)의 비율을 기준으로 계산된다. 즉 특정 프로세스가 전체 시간 중 얼마나 CPU를 사용하며 동작했는지를 보여주는 값이다.

%MEM

%MEM은 시스템의 전체 물리 메모리 대비 현재 프로세스의 RSS 비율을 의미한다. 즉 컴퓨터 전체 메모리 중에서 현재 프로세스가 얼마나 메모리를 사용하고 있는지를 퍼센트(%) 형태로 보여주는 항목이다.

PGID (Process Group ID)

PGID(Process Group ID)는 프로세스 그룹(Process Group)을 구분하기 위한 번호이다.