neck392

[CNN] VGG 구조를 참고한 경량 CNN 설계

neck392 — Mon, 8 Jun 2026 05:16:39 +0900

VGG 구조를 참고한 경량 CNN 설계

이번 글에서는 Food-101 음식 이미지 분류 프로젝트에서 사용한 VGG 구조를 참고한 경량 CNN을 정리한다. VGG-16은 Simonyan과 Zisserman이 제안한 CNN 구조로, 작은 3×3 convolution filter를 반복적으로 쌓아 깊은 네트워크를 구성하는 방식이 이미지 분류에서 효과적임을 보였다 [2]. 본 프로젝트에서는 해당 설계 아이디어를 참고하여, 프로젝트 환경에 맞게 더 작은 CNN 구조로 재구성하였다.

1. VGG-16이란?

VGG는 Simonyan과 Zisserman이 제안한 CNN 구조이다 [2]. 핵심 아이디어는 큰 convolution filter를 사용하는 대신, 작은 3×3 convolution filter를 여러 층에 반복적으로 쌓는 것이다. 이를 통해 이미지의 지역적인 특징을 단계적으로 학습할 수 있다.

흔히 VGG-16이라고 부르지만, 여기서 16은 convolution layer만 16개라는 뜻이 아니다. VGG-16은 일반적으로 13개의 convolution layer와 3개의 fully connected layer를 포함하여 총 16개의 학습 가능한 weight layer를 갖는 구조를 의미한다. MaxPooling layer는 중간중간 사용되지만, 학습되는 가중치가 없기 때문에 16개 layer 수에 포함하지 않는다.

정리
VGG-16 = 13개 Conv layer + 3개 Fully Connected layer
핵심 아이디어 = 작은 3×3 Conv를 반복적으로 쌓아 깊이를 늘리는 구조

2. 왜 VGG-16을 그대로 사용하지 않았는가?

Food-101은 101개 음식 클래스를 가진 대규모 이미지 데이터셋이다. 그러나 이번 프로젝트의 목적은 사전학습된 복잡한 모델을 사용하는 것이 아니라, 직접 설계한 CNN을 통해 이미지 데이터 분류 과정을 이해하는 것이었다. 따라서 VGG-16 전체 구조를 그대로 사용하지 않고, VGG의 핵심 아이디어만 가져와 경량 CNN으로 설계하였다.

즉, 본 프로젝트의 모델은 다음과 같이 이해할 수 있다.

구분	설명
VGG-16	13개 Conv layer와 3개 FC layer를 갖는 깊은 CNN 구조
본 프로젝트 모델	VGG의 3×3 Conv 반복 아이디어를 참고한 경량 CNN
차이점	VGG-16 전체 구조를 사용하지 않고 Conv block 수와 파라미터 수를 줄임

3. Baseline CNN 구조

먼저 기준 모델로 단순한 Baseline CNN을 구성하였다. Baseline CNN은 각 단계에서 Conv2D를 한 번 적용한 뒤 MaxPooling을 수행하는 구조이다.

Input
→ Rescaling
→ Conv2D + MaxPooling
→ Conv2D + MaxPooling
→ Conv2D + MaxPooling
→ Conv2D
→ GlobalAveragePooling2D
→ Dense
→ Softmax

이 구조는 비교적 단순하기 때문에 기준 모델로 사용하기 좋다. 하지만 Food-101처럼 클래스 수가 많고 음식 간 시각적 유사성이 큰 데이터셋에서는 더 풍부한 특징 추출이 필요할 수 있다.

4. VGG 구조를 참고한 경량 CNN

VGG 구조를 참고한 경량 CNN에서는 pooling을 하기 전에 Conv2D를 두 번 적용하였다. 즉, 이미지 크기를 줄이기 전에 같은 해상도에서 특징을 한 번 더 추출하도록 구조를 바꾸었다. 3×3 Conv를 반복한 뒤 pooling을 수행하는 설계 방향을 참고하여 프로젝트 환경에 맞는 CNN을 설계하였다.

Input
→ Rescaling
→ Conv2D → BatchNorm → ReLU
→ Conv2D → BatchNorm → ReLU
→ MaxPooling

→ Conv2D → BatchNorm → ReLU
→ Conv2D → BatchNorm → ReLU
→ MaxPooling

→ Conv2D → BatchNorm → ReLU
→ Conv2D → BatchNorm → ReLU
→ MaxPooling

→ Conv2D → BatchNorm → ReLU
→ GlobalAveragePooling2D
→ Dense
→ Softmax

이 구조를 짧게 표현하면 다음과 같다.

최종 구조의 핵심
(Conv2D + BatchNorm + ReLU) × 2 → MaxPooling

여기서 중요한 점은 Conv2D → Conv2D → BatchNorm 순서가 아니라는 것이다. 실제 구조는 각 Conv2D 뒤에 Batch Normalization과 ReLU를 적용하는 형태이다. 즉, Conv2D → BatchNorm → ReLU 단위를 반복한 뒤 MaxPooling을 수행한다.

5. Batch Normalization을 함께 사용한 이유

convolution layer 수를 늘리면 모델이 더 많은 특징을 학습할 수 있지만, 동시에 학습이 불안정해질 수도 있다. 실제 실험에서도 Batch Normalization을 적용하지 않은 경량 CNN은 거의 무작위 예측에 가까운 성능을 보였다.

Batch Normalization은 Conv2D 이후 생성된 feature map의 값 분포를 mini-batch 단위로 정리하는 층이다 [3]. 이를 통해 학습 과정에서 중간 출력값이 지나치게 흔들리는 문제를 완화하고, 깊어진 CNN 구조가 더 안정적으로 학습되도록 돕는다.

Batch Normalization에는 학습되는 값이 있다. 대표적으로 gamma와 beta가 학습 가능한 파라미터이며, 정규화된 값을 다시 조정하는 역할을 한다.

6. GlobalAveragePooling2D의 역할

마지막 convolution layer의 출력은 예를 들어 16×16×128 형태의 feature map이다. 이는 16×16 크기의 feature map이 128장 있다는 의미이다.

GlobalAveragePooling2D는 각 feature map의 모든 위치값을 평균내어 하나의 값으로 요약한다. 따라서 16×16×128 형태의 출력을 128개의 값으로 줄일 수 있다. Global Average Pooling은 Network in Network 논문에서 feature map을 요약하는 방식으로 제안되었다 [4].

16 × 16 × 128
→ 각 feature map의 평균 계산
→ 128

이 방식은 Flatten을 사용해 모든 위치값을 그대로 펼치는 방식보다 Dense layer로 전달되는 입력 크기를 줄일 수 있다. 따라서 모델을 더 간결하게 구성하는 데 도움이 된다.

7. Keras 구현 코드

아래는 실제 프로젝트에서 사용한 VGG 구조 참고 경량 CNN의 핵심 구현이다.

from tensorflow import keras
from tensorflow.keras import layers

IMG_SIZE = 128
NUM_CLASSES = 101

def conv_unit_bn(x, filters, idx):
    x = layers.Conv2D(
        filters,
        kernel_size=3,
        padding="same",
        use_bias=False,
        name=f"conv_{idx}"
    )(x)

    x = layers.BatchNormalization(name=f"bn_{idx}")(x)
    x = layers.ReLU(name=f"relu_{idx}")(x)

    return x

def build_model():
    inputs = keras.Input(shape=(IMG_SIZE, IMG_SIZE, 3), name="input_image")

    x = layers.Rescaling(1./255, name="rescaling")(inputs)

    # Block 1
    x = conv_unit_bn(x, 32, idx=1)
    x = conv_unit_bn(x, 32, idx=2)
    x = layers.MaxPooling2D(pool_size=2, name="pool_1")(x)

    # Block 2
    x = conv_unit_bn(x, 64, idx=3)
    x = conv_unit_bn(x, 64, idx=4)
    x = layers.MaxPooling2D(pool_size=2, name="pool_2")(x)

    # Block 3
    x = conv_unit_bn(x, 128, idx=5)
    x = conv_unit_bn(x, 128, idx=6)
    x = layers.MaxPooling2D(pool_size=2, name="pool_3")(x)

    # Final Conv
    x = conv_unit_bn(x, 128, idx=7)

    x = layers.GlobalAveragePooling2D(name="global_average_pooling")(x)
    x = layers.Dense(128, activation="relu", name="dense_1")(x)

    outputs = layers.Dense(
        NUM_CLASSES,
        activation="softmax",
        name="class_output"
    )(x)

    model = keras.Model(inputs=inputs, outputs=outputs)
    return model

8. Label Smoothing 적용

최종 모델에서는 Label Smoothing도 함께 적용하였다. 일반적인 one-hot encoding은 정답 클래스만 1이고 나머지 클래스는 0으로 둔다. 반면 Label Smoothing은 정답 클래스의 값을 조금 낮추고, 나머지 클래스에도 작은 확률을 나누어 주는 방식이다 [5].

일반 one-hot encoding
정답 클래스: 1.0
오답 클래스: 0.0

Label Smoothing
정답 클래스: 0.9
오답 클래스: 작은 확률 분배

Food-101은 101개 음식 클래스를 갖고 있으며, 서로 시각적으로 유사한 음식도 많다. 따라서 모델이 특정 정답 클래스에 지나치게 확신하는 것을 줄이기 위해 Label Smoothing을 적용하였다.

loss_fn = keras.losses.CategoricalCrossentropy(
    label_smoothing=0.1
)

9. 실험 결과

실험 결과, 단순 Baseline CNN보다 VGG 구조를 참고한 경량 CNN에 Batch Normalization과 Label Smoothing을 적용한 모델이 가장 좋은 validation 성능을 보였다. 특히 Batch Normalization을 적용하지 않은 경량 CNN은 거의 무작위 예측에 가까운 성능을 보였지만, Batch Normalization을 추가한 뒤 성능이 크게 향상되었다.

모델	Val Accuracy	Val Top-5 Accuracy
Baseline CNN	0.3399	0.6230
경량 CNN	0.0099	0.0495
경량 CNN + BatchNorm	0.4646	0.7491
경량 CNN + BatchNorm + Label Smoothing	0.4952	0.7684

최종 test set 평가에서는 다음과 같은 성능을 확인하였다.

지표	값
Test Accuracy	0.5354
Test Top-5 Accuracy	0.8128
Macro F1-score	0.5384

10. 정리

이번 실험에서 가장 중요한 점은 모델을 단순히 깊게 만드는 것만으로는 충분하지 않았다는 점이다. 실제로 Batch Normalization을 적용하지 않은 경량 CNN은 거의 무작위 예측에 가까운 성능을 보였다. 반면 VGG의 3×3 Conv 반복 구조를 참고하되, 각 Conv 뒤에 Batch Normalization과 ReLU를 추가한 모델은 성능이 크게 개선되었다. 여기에 Label Smoothing을 적용하자 validation accuracy와 validation top-5 accuracy가 모두 가장 높게 나타났다.

최종 결론
VGG 구조의 핵심 아이디어인 3×3 Conv 반복 구조를 적용하여 경량 CNN을 설계하고,
Batch Normalization으로 학습을 안정화하며,
Label Smoothing으로 과도한 확신을 줄였을 때 Food-101 분류 성능이 가장 좋았다.

Reference

L. Bossard, M. Guillaumin, and L. Van Gool, Food-101 – Mining Discriminative Components with Random Forests, Computer Vision – ECCV 2014 Workshops, 2014.
K. Simonyan and A. Zisserman, Very Deep Convolutional Networks for Large-Scale Image Recognition, International Conference on Learning Representations, 2015.
S. Ioffe and C. Szegedy, Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift, International Conference on Machine Learning, 2015.
M. Lin, Q. Chen, and S. Yan, Network in Network, International Conference on Learning Representations, 2014.
C. Szegedy, V. Vanhoucke, S. Ioffe, J. Shlens, and Z. Wojna, Rethinking the Inception Architecture for Computer Vision, IEEE Conference on Computer Vision and Pattern Recognition, 2016.

AEPC(Adaptive Excess-Preserving Clipping) 제안

neck392 — Mon, 18 May 2026 09:08:54 +0900

AEPC(Adaptive Excess-Preserving Clipping): 극단값을 단순 절단하지 않고 초과 정보를 보존하는 전처리 전략

정형 데이터 기반 회귀 모델을 학습하다 보면 자주 마주치는 문제가 있다. 바로 극단값(outlier)이다. 일부 feature는 대부분의 값이 특정 구간에 몰려 있지만, 소수의 값이 매우 크거나 매우 작게 나타난다. 이러한 극단값은 모델 학습 과정에서 손실을 크게 만들거나, 특정 변수의 영향력을 과도하게 키워 모델이 전체적인 데이터 경향을 안정적으로 학습하는 것을 방해할 수 있다.

일반적으로 이러한 문제를 완화하기 위해 clipping을 적용한다. 가장 흔한 방식은 특정 분위수를 기준으로 값을 제한하는 Quantile Clipping이다. 하지만 Quantile Clipping은 기준을 벗어난 값을 모두 동일한 상한 또는 하한으로 고정하기 때문에, 극단값이 가지고 있던 상대적 크기 정보가 사라질 수 있다.

이 문제를 완화하기 위해 본 프로젝트에서는 AEPC(Adaptive Excess-Preserving Clipping)라는 전처리 전략을 설계하였다.

AEPC는 극단값을 완전히 잘라내지 않고, 기준값을 벗어난 초과 정보의 일부를 보존하는 전처리 방식이다.

1. 실험 데이터 개요

실험에는 와인 품질 예측 데이터를 사용하였다. 데이터는 총 4,898개 샘플과 12개 컬럼으로 구성되어 있으며, 11개의 입력 feature와 quality 종속변수를 가진다. 실제 관측된 quality 값은 3부터 9까지 존재하였다.

입력 feature는 다음과 같다.

fixed acidity
volatile acidity
citric acid
residual sugar
chlorides
free sulfur dioxide
total sulfur dioxide
density
pH
sulphates
alcohol

전체 데이터는 train/validation/test를 60/20/20 비율로 분할하였다.

train set: 2,938개
validation set: 980개
test set: 980개

이 중 residual sugar, chlorides, total sulfur dioxide, density 등은 일부 값이 분포의 꼬리 부분에 크게 치우쳐 있어 극단값 완화가 필요한 변수로 확인되었다.

2. 기존 Quantile Clipping 방식

Quantile Clipping은 train set 기준으로 하위 분위수와 상위 분위수를 계산한 뒤, 해당 범위를 벗어난 값을 각각 하한값과 상한값으로 고정하는 방식이다.

예를 들어 하위 1% 분위수를 \(q_{0.01}\), 상위 99% 분위수를 \(q_{0.99}\)라고 하면 Quantile Clipping은 다음과 같이 정의할 수 있다.

\[ x' = \begin{cases} q_{0.01}, & x \lt q_{0.01} \\ x, & q_{0.01} \le x \le q_{0.99} \\ q_{0.99}, & x \gt q_{0.99} \end{cases} \]

즉, 아래쪽 극단값은 하위 1% 분위수로 끌어올리고, 위쪽 극단값은 상위 99% 분위수로 낮춘다.

실제 데이터에서 Quantile Clipping 기준은 다음과 같이 계산되었다.

Feature	q01 lower	q99 upper	min before	max before
fixed acidity	5.0000	9.2000	3.8000	14.2000
residual sugar	0.9000	18.8630	0.7000	65.8000
chlorides	0.0200	0.1570	0.0120	0.3460
total sulfur dioxide	50.0000	243.0000	9.0000	366.5000
density	0.9889	1.00038	0.98711	1.03898

예를 들어 residual sugar의 경우 train set 기준 상위 99% 분위수는 18.863이고, 원본 최댓값은 65.8이었다. 따라서 Quantile Clipping을 적용하면 다음과 같이 변환된다.

\[65.8 \rightarrow 18.863\]

또한 total sulfur dioxide의 경우 원본 최댓값 366.5는 상위 99% 분위수인 243.0으로 제한된다.

\[366.5 \rightarrow 243.0\]

하단 극단값도 동일하게 처리된다. fixed acidity의 경우 하위 1% 분위수가 5.0이고, 원본 최솟값이 3.8이므로 다음과 같이 변환된다.

\[3.8 \rightarrow 5.0\]

이 방식은 극단값의 영향을 줄이는 데 효과적이다. 그러나 상한을 초과한 값들은 모두 같은 값으로 바뀌고, 하한보다 작은 값들도 모두 같은 값으로 바뀐다. 즉, 극단값 구간 안에서 원래 값들이 가지고 있던 상대적 차이가 사라진다.

예를 들어 residual sugar의 상위 극단값들은 원래 서로 다른 크기를 갖지만, Quantile Clipping 이후에는 모두 18.863으로 고정된다.

Original	Quantile Clipping
65.80	18.863
26.05	18.863
23.50	18.863
20.70	18.863

즉, Quantile Clipping은 안정적이지만, 극단값의 상대적 순서와 크기 정보를 제거한다는 한계가 있다.

3. 기존 클리핑 방식을 개선하기 위한 AEPC 제안

AEPC는 이러한 한계를 완화하기 위해 설계한 방식이다. AEPC는 극단값을 기준값으로 완전히 고정하지 않고, 기준값을 벗어난 부분의 일부만 보존한다.

이를 위해 하단 cap과 상단 cap을 각각 정의한다.

lower cap: \(c_L\)
upper cap: \(c_U\)

그리고 하단 극단값과 상단 극단값에 대해 각각 보존 비율을 둔다.

lower alpha: \(\alpha_L\)
upper alpha: \(\alpha_U\)

양방향 AEPC는 다음과 같이 정의할 수 있다.

\[ x' = \begin{cases} c_L + \alpha_L(x - c_L), & x \lt c_L \\ x, & c_L \le x \le c_U \\ c_U + \alpha_U(x - c_U), & x \gt c_U \end{cases} \]

이 수식에서 \(x\)는 원본 값, \(x'\)는 AEPC 적용 후 값이다.

하단 극단값에서는 \(x - c_L\)이 음수이다. 따라서 \(x\)가 하단 cap보다 작으면, 원래 값과 cap 사이의 차이를 \(\alpha_L\) 비율만큼만 보존한다.

상단 극단값에서는 \(x - c_U\)가 양수이다. 따라서 \(x\)가 상단 cap보다 크면, cap을 초과한 부분을 \(\alpha_U\) 비율만큼만 보존한다.

여기서 \(\alpha\)는 hard clipping과 원본 유지 사이의 절충 정도를 의미한다.

\[\alpha = 0 \Rightarrow \text{hard clipping}\] \[\alpha = 1 \Rightarrow \text{original value}\]

즉, \(\alpha\)가 0에 가까울수록 기존 clipping처럼 강하게 값을 제한하고, \(\alpha\)가 1에 가까울수록 원본 값을 더 많이 유지한다.

4. AEPC cap 계산 방식

AEPC에서는 cap을 단순히 1%와 99% 분위수로 고정하지 않는다. 각 feature의 분포를 기준으로 하단 cap과 상단 cap을 따로 계산한다.

먼저 다음 통계량을 계산한다.

\[Q_1,\ Q_3,\ IQR\]

여기서 IQR은 다음과 같다.

\[IQR = Q_3 - Q_1\]

상단 cap 후보는 다음과 같이 계산한다.

\[c_{U,raw} = Q_3 + 3.0 \times IQR\]

하단 cap 후보는 다음과 같이 계산한다.

\[c_{L,raw} = Q_1 - 3.0 \times IQR\]

일반적인 IQR 기반 이상치 기준에서는 \(1.5 \times IQR\)을 많이 사용하지만, AEPC에서는 \(3.0 \times IQR\)을 사용하였다. 그 이유는 너무 많은 값을 극단값으로 간주하지 않고, 실제 꼬리 영역에 해당하는 값만 완화하기 위해서이다.

다만 raw cap이 너무 낮거나 높게 설정되는 것을 방지하기 위해 분위수 범위로 한 번 더 제한한다.

상단 cap은 다음과 같이 제한한다.

\[c_U = \min(\max(c_{U,raw}, Q_{97.5}), Q_{99.5})\]

즉, 상단 cap은 다음 범위 안에서 결정된다.

\[Q_{97.5} \le c_U \le Q_{99.5}\]

하단 cap은 다음과 같이 제한한다.

\[c_L = \min(\max(c_{L,raw}, Q_{0.5}), Q_{2.5})\]

즉, 하단 cap은 다음 범위 안에서 결정된다.

\[Q_{0.5} \le c_L \le Q_{2.5}\]

이렇게 하면 AEPC는 대부분의 일반적인 값은 그대로 유지하고, 하단과 상단의 꼬리 영역에 해당하는 값만 완화한다.

실제 데이터에서 Bidirectional AEPC 기준은 다음과 같이 계산되었다.

Feature	lower cap	upper cap	min before	max before
fixed acidity	4.8000	9.6000	3.8000	14.2000
residual sugar	0.8000	19.84725	0.7000	65.8000
chlorides	0.018685	0.100725	0.0120	0.3460
total sulfur dioxide	32.3700	249.9725	9.0000	366.5000
density	0.988614	1.000631	0.98711	1.03898

이 기준을 보면 AEPC는 Quantile Clipping처럼 값을 분위수 경계에 바로 고정하지 않고, 각 feature의 분포와 tail 특성을 반영하여 완화 기준을 정한다.

5. alpha 계산 방식

AEPC에서 가장 중요한 값은 \(\alpha\)이다. \(\alpha\)는 cap을 벗어난 값을 얼마나 보존할지 결정한다.

본 프로젝트에서는 \(\alpha\)를 고정값으로 두지 않고, feature별 tail 특성을 반영하여 계산하였다.

이를 위해 세 가지 점수를 사용하였다.

\[S_{tail},\ S_{target},\ S_{cont}\]

각 점수의 의미는 다음과 같다.

점수	의미
\(S_{tail}\)	cap을 벗어난 값이 얼마나 반복적으로 등장하는가
\(S_{target}\)	cap 밖의 값들이 target과 얼마나 관련되어 있는가
\(S_{cont}\)	tail이 한두 개만 튀는 형태인지, 연속적으로 존재하는지

최종 보존 점수는 다음과 같이 계산하였다.

\[S_{preserve} = 0.3S_{tail} + 0.5S_{target} + 0.2S_{cont}\]

그리고 이를 \(\alpha\)로 변환한다.

\[\alpha = \alpha_{min} + (\alpha_{max} - \alpha_{min})S_{preserve}\]

실험에서는 다음 범위를 사용하였다.

\[\alpha_{min} = 0.1\] \[\alpha_{max} = 0.9\]

따라서 \(S_{preserve}\)가 클수록 \(\alpha\)가 커지고, cap을 벗어난 정보를 더 많이 보존한다.

6. 각 스코어의 정의

6.1 Tail Ratio Score

먼저 cap을 벗어난 샘플 집합을 정의한다. 상단 tail은 다음과 같다.

\[T_U = \{x_i \mid x_i \gt c_U\}\]

하단 tail은 다음과 같다.

\[T_L = \{x_i \mid x_i \lt c_L\}\]

전체 샘플 수를 \(n\)이라고 하면 tail ratio는 다음과 같다.

\[r_{tail} = \frac{|T|}{n}\]

이를 기준 tail 비율 \(r_{ref}\)와 비교해 점수화한다.

\[S_{tail} = \min\left(\frac{r_{tail}}{r_{ref}}, 1\right)\]

본 프로젝트에서는 \(r_{ref}=0.05\)를 기준으로 두었다. 즉, cap 밖의 값이 전체의 5%에 가까울수록 tail ratio score가 커진다.

이 점수는 cap 밖의 값이 단순히 우연히 등장한 이상치인지, 아니면 어느 정도 반복적으로 나타나는 분포의 일부인지를 판단하기 위한 값이다.

6.2 Target Signal Score

극단값을 보존할지 판단할 때 가장 중요한 기준은 target과의 관련성이다.

따라서 AEPC에서는 tail 구간의 target 평균과 일반 구간의 target 평균 차이를 계산한다. tail 구간의 target 값을 \(y_{tail}\), 나머지 구간의 target 값을 \(y_{body}\)라고 하면 다음과 같이 정의할 수 있다.

\[ S_{target} = \min\left( \frac{|\mu(y_{tail}) - \mu(y_{body})|}{\sigma(y)}, 1 \right) \]

이 수식은 다음 질문에 답한다.

cap 밖의 값들이 실제 quality와 관련된 차이를 가지고 있는가?

만약 tail 구간의 quality 평균이 body 구간의 quality 평균과 많이 다르다면, 해당 극단값은 단순 노이즈가 아니라 예측에 의미 있는 신호일 수 있다.

6.3 Tail Continuity Score

마지막으로 tail이 한두 개만 튀는 형태인지, 아니면 꼬리 구간이 어느 정도 연속적으로 존재하는지를 확인한다.

상단 tail에서는 excess를 다음과 같이 정의한다.

\[e_i = x_i - c_U,\quad x_i \gt c_U\]

하단 tail에서는 excess를 다음과 같이 정의한다.

\[e_i = c_L - x_i,\quad x_i \lt c_L\]

즉, cap에서 얼마나 벗어났는지를 양수로 계산한다.

Tail continuity score는 다음과 같이 계산한다.

\[S_{cont} = \frac{\operatorname{median}(e)}{\max(e) + \epsilon}\]

여기서 \(\epsilon\)은 0으로 나누는 것을 방지하기 위한 작은 값이다.

이 값은 tail이 일부 값만 비정상적으로 튀는 형태인지, 아니면 꼬리 구간이 비교적 연속적으로 존재하는지를 판단하기 위한 보조 지표이다.

7. 알파값을 정하기 위한 스코어 계수(가중치)

AEPC의 보존 점수는 다음과 같이 계산된다.

\[S_{preserve} = 0.3S_{tail} + 0.5S_{target} + 0.2S_{cont}\]

이 계수는 모델이 자동으로 학습한 값이 아니라, AEPC의 설계 목적을 반영한 경험적 가중치이다.

가장 큰 가중치는 \(S_{target}\)에 부여하였다.

\[0.5S_{target}\]

AEPC의 목적은 극단값을 무조건 보존하는 것이 아니다. 예측에 의미 있을 가능성이 있는 극단값을 더 많이 보존하는 것이다. 따라서 tail 구간이 target과 얼마나 관련되어 있는지가 가장 중요한 기준이라고 판단하였다.

두 번째로 큰 가중치는 \(S_{tail}\)에 부여하였다.

\[0.3S_{tail}\]

cap 밖의 값이 한두 개만 존재한다면 단순 이상치일 가능성이 크다. 반면 cap 밖의 값이 반복적으로 나타난다면 해당 feature가 원래 가지고 있는 분포 특성일 수 있다. 따라서 tail ratio는 target signal보다는 낮지만 중요한 보조 기준으로 보았다.

마지막으로 \(S_{cont}\)에는 가장 낮은 가중치를 부여하였다.

\[0.2S_{cont}\]

tail continuity는 tail이 연속적인지 확인하는 지표이지만, target과 직접적으로 연결되는 기준은 아니다. 따라서 보조적인 안정성 판단 기준으로 두었다.

정리하면 AEPC의 가중치 구조는 다음 우선순위를 반영한다.

\[S_{target} \gt S_{tail} \gt S_{cont}\]

즉, 다음과 같다.

\[0.5 \gt 0.3 \gt 0.2\]

8. 실제 데이터 적용 예시 1: residual sugar

residual sugar는 상단 극단값이 매우 크게 나타난 feature이다.

train set에서 residual sugar의 Quantile Clipping 상한은 18.863이고, 원본 최댓값은 65.8이었다. 반면 AEPC의 상단 cap은 19.84725, 상단 alpha는 0.223661로 계산되었다.

Quantile Clipping을 적용하면 다음과 같다.

\[65.8 \rightarrow 18.863\]

AEPC를 적용하면 다음과 같이 계산된다.

\[x' = c_U + \alpha_U(x - c_U)\] \[x' = 19.84725 + 0.223661(65.8 - 19.84725)\] \[x' = 19.84725 + 0.223661 \times 45.95275\] \[x' \approx 30.125\]

즉, Quantile Clipping은 65.8을 18.863으로 강하게 절단하지만, AEPC는 30.125로 완화한다.

Original	Quantile Clipping	AEPC
65.80	18.863	30.125
26.05	18.863	21.235
23.50	18.863	20.664
20.70	18.863	20.038

이 결과를 보면 AEPC는 극단값을 그대로 두지는 않지만, 원래 값이 더 컸다는 상대적 정보는 유지한다.

9. 실제 데이터 적용 예시 2: total sulfur dioxide

total sulfur dioxide도 AEPC의 특성이 잘 드러나는 feature이다.

train set에서 total sulfur dioxide의 Quantile Clipping 상한은 243.0이고, 원본 최댓값은 366.5였다. 반면 AEPC의 상단 cap은 249.9725, 상단 alpha는 0.531410으로 계산되었다.

Quantile Clipping을 적용하면 다음과 같다.

\[366.5 \rightarrow 243.0\]

AEPC를 적용하면 다음과 같다.

\[x' = c_U + \alpha_U(x - c_U)\] \[x' = 249.9725 + 0.531410(366.5 - 249.9725)\] \[x' = 249.9725 + 0.531410 \times 116.5275\] \[x' \approx 311.896\]

Original	Quantile Clipping	AEPC
366.5	243.0	311.896
344.0	243.0	299.940
307.5	243.0	280.543
272.0	243.0	261.678

Quantile Clipping은 상한을 초과한 값을 모두 243.0으로 고정한다. 반면 AEPC는 초과분의 약 53%를 보존하여 원래 값들의 상대적 크기 차이를 유지한다.

10. 실제 데이터 적용 예시 3: 하단 극단값

AEPC는 상단 극단값뿐 아니라 하단 극단값도 같은 원리로 처리할 수 있다.

예를 들어 fixed acidity의 경우 Quantile Clipping 하한은 5.0이고 원본 최솟값은 3.8이었다. Bidirectional AEPC에서는 하단 cap이 4.8로 계산되었다.

Quantile Clipping은 다음과 같이 처리한다.

\[3.8 \rightarrow 5.0\]

반면 AEPC는 하단 cap을 기준으로 다음 수식을 적용한다.

\[x' = c_L + \alpha_L(x - c_L)\]

여기서 \(x - c_L\)는 음수이다. 따라서 원본 값이 cap보다 낮았다는 정보를 일부 보존하면서, 값을 cap 방향으로 완화한다.

예를 들어 설명을 위해 \(c_L = 4.8\), \(\alpha_L = 0.4\)라고 두면 다음과 같이 계산된다.

\[x' = 4.8 + 0.4(3.8 - 4.8)\] \[x' = 4.8 + 0.4(-1.0)\] \[x' = 4.8 - 0.4\] \[x' = 4.4\]

즉, Quantile Clipping은 3.8을 5.0으로 완전히 끌어올리지만, AEPC는 4.4처럼 원래 값이 낮았다는 정보를 일부 보존한 상태로 완화할 수 있다.

11. 상관관계 변화 확인

AEPC 적용 후 feature와 quality 간의 관계가 어떻게 변했는지 확인하기 위해 Pearson 및 Spearman 상관계수를 비교하였다.

여기서 중요한 점은 상관관계의 방향이 아니라 강도를 비교해야 한다는 것이다. 예를 들어 어떤 feature가 quality와 음의 상관관계를 갖는다면, 상관계수가 -0.22에서 -0.25로 변했을 때 숫자 자체는 작아졌지만, 절댓값은 커졌으므로 관계의 강도는 증가했다고 볼 수 있다.

따라서 본 분석에서는 다음 값을 함께 확인하였다.

\[|\text{corr}(x, quality)|\]

11.1 Pearson 상관계수

Pearson 상관계수는 값의 선형적 크기 관계에 민감하다. 따라서 극단값의 크기를 어떻게 조정했는지에 영향을 받을 수 있다.

실험 결과 chlorides에서 가장 뚜렷한 변화가 나타났다.

Raw feature 기준:

Feature	Original corr	Quantile corr	AEPC corr
chlorides	-0.216275	-0.233189	-0.249089

log1p 적용 후:

Feature	Original corr	Quantile corr	AEPC corr
chlorides	-0.222471	-0.237445	-0.252598

즉, chlorides는 AEPC 적용 후 Pearson 상관계수의 절댓값이 가장 크게 증가하였다. log1p 적용 후 기준으로 보면 원본의 절댓값은 0.222471, Quantile Clipping은 0.237445, AEPC는 0.252598이었다.

\[|corr_{original}| = 0.222471\] \[|corr_{qclip}| = 0.237445\] \[|corr_{AEPC}| = 0.252598\]

이 결과는 AEPC가 chlorides에서 극단값의 크기 효과를 조정하면서 quality와의 선형 관계를 더 뚜렷하게 만들었을 가능성을 보여준다.

다만 이러한 효과가 모든 feature에서 동일하게 나타난 것은 아니다. 예를 들어 total sulfur dioxide는 AEPC 적용 후 Pearson 상관계수 절댓값이 원본보다 소폭 감소하였다.

Raw Pearson 기준으로 보면 다음과 같다.

Feature	Original corr	Quantile corr	AEPC corr
total sulfur dioxide	-0.168759	-0.170613	-0.167668

따라서 AEPC는 모든 변수의 상관관계를 일괄적으로 증가시키는 방식이 아니라, feature의 tail 특성에 따라 관계 변화가 다르게 나타나는 전처리 방식으로 보는 것이 적절하다.

11.2 Spearman 상관계수

Spearman 상관계수는 값의 크기보다 순위 기반 관계를 반영한다.

실험 결과 Spearman 상관계수는 AEPC 적용 전후에 거의 변하지 않았다.

예를 들어 chlorides의 Spearman 상관계수는 다음과 같았다.

Feature	Original Spearman	Quantile Spearman	AEPC Spearman
chlorides	-0.323436	-0.323453	-0.323436

density도 거의 동일하였다.

Feature	Original Spearman	Quantile Spearman	AEPC Spearman
density	-0.342469	-0.342448	-0.342469

이는 AEPC가 데이터의 순위 구조를 크게 바꾸기보다는, cap 밖의 값의 크기만 완화하는 방식으로 작동했음을 보여준다.

순위 구조는 거의 유지한다.
극단값의 크기 효과는 완화한다.
일부 feature에서는 target과의 Pearson 관계가 더 뚜렷해질 수 있다.

12. Quantile Clipping과 AEPC의 수식적 차이

두 방식의 차이는 수식으로 보면 더 명확하다.

Quantile Clipping에서는 상한을 넘는 두 값 \(x_1, x_2\)가 있을 때 다음과 같이 가정할 수 있다.

\[x_1 \gt x_2 \gt q_{0.99}\]

변환 후에는 다음과 같이 된다.

\[x_1' = x_2' = q_{0.99}\]

즉, 상한을 넘은 값들의 순서 정보가 사라진다.

반면 AEPC에서는 다음과 같이 가정할 수 있다.

\[x_1 \gt x_2 \gt c_U\]

이때 AEPC 적용 후 값은 다음과 같다.

\[x_1' = c_U + \alpha_U(x_1 - c_U)\] \[x_2' = c_U + \alpha_U(x_2 - c_U)\]

그리고 \(\alpha_U \gt 0\)이면 다음 관계가 유지된다.

\[x_1' \gt x_2'\]

하단 극단값도 마찬가지다. \(x_1 \lt x_2 \lt c_L\)이고 \(\alpha_L \gt 0\)이면 AEPC 적용 후에도 다음 관계가 유지된다.

\[x_1' \lt x_2'\]

즉, AEPC는 상단과 하단 극단값 모두에서 값의 상대적 순서를 보존한다.

13. 한계와 향후 개선 방향

AEPC는 극단값을 완전히 제거하지 않고 일부 정보를 보존한다는 장점이 있다. 하지만 모든 상황에서 Quantile Clipping보다 항상 우수하다고 볼 수는 없다.

극단값이 실제로 노이즈라면 AEPC가 불필요한 정보를 남길 수 있다. 반대로 극단값이 target과 관련된 의미 있는 신호라면 AEPC가 Quantile Clipping보다 유리할 수 있다.

또한 이번 실험에 사용한 와인 품질 데이터는 종속변수인 quality가 5, 6, 7 구간에 크게 집중되어 있다. 실제로 대부분의 샘플이 중간 품질 등급에 몰려 있기 때문에, 입력 feature의 극단값을 일부 보존하더라도 target 측면에서 충분히 뚜렷한 차이를 만들기 어려울 수 있다. 즉, AEPC가 극단값의 상대적 정보를 보존하더라도, 종속변수 자체가 중간 등급에 편중되어 있다면 그 효과가 제한적으로 나타날 가능성이 있다.

따라서 본 실험 결과만으로 AEPC의 일반적인 유효성을 단정하기는 어렵다. AEPC가 실제로 다양한 정형 회귀 문제에서 유효한 전처리 전략인지 확인하기 위해서는, target 분포가 더 다양하거나 극단 구간의 target 차이가 뚜렷한 데이터셋을 포함하여 추가적인 실험과 검증이 필요하다.

또한 본 프로젝트에서 사용한 \((0.3, 0.5, 0.2)\) 가중치는 모델 학습으로 최적화된 값이 아니라, AEPC 설계 의도를 반영한 경험적 가중치이다. 특히 target 관련성을 가장 중요하게 보고 0.5의 가중치를 부여하였으며, tail의 반복성과 연속성에는 각각 0.3과 0.2를 부여하였다. 그러나 이 가중치 조합이 최적이라는 의미는 아니다. 데이터셋의 분포, target과의 관계, 극단값의 형태에 따라 적절한 가중치가 달라질 수 있으므로, 계수 조합에 대한 추가적인 실험과 민감도 분석이 필요하다.

향후에는 다음과 같은 추가 검증이 필요하다.

가중치 조합에 대한 ablation study
alpha_min, alpha_max 변화에 따른 민감도 분석
하단 AEPC와 상단 AEPC의 개별 효과 비교
여러 random seed 기반 반복 실험
target 분포가 서로 다른 다양한 정형 회귀 데이터셋에 대한 일반화 검증

결론

AEPC는 극단값을 단순히 제거하는 것이 아니라, 극단값의 영향을 줄이면서도 cap을 벗어난 정보의 일부를 보존하기 위한 전처리 전략이다.

핵심 수식은 다음과 같다.

\[ x' = \begin{cases} c_L + \alpha_L(x - c_L), & x \lt c_L \\ x, & c_L \le x \le c_U \\ c_U + \alpha_U(x - c_U), & x \gt c_U \end{cases} \]

이 방식은 hard clipping과 원본 유지 사이의 절충점을 만든다.

\[\alpha = 0 \Rightarrow \text{hard clipping}\] \[\alpha = 1 \Rightarrow \text{original value}\]

Quantile Clipping은 극단값을 안정적으로 제한하지만, 기준 밖의 값을 모두 같은 값으로 고정한다. 반면 AEPC는 기준 밖의 값을 완화하면서도 원래 값의 상대적 순서와 일부 크기 정보를 유지한다.

결국 AEPC는 극단값 제거가 아니라 극단값 완화와 정보 보존 사이의 균형을 목표로 한 전처리 방식이다.

[네트워크] IPv4 주소의 구분과 할당 가능 주소 계산 예제

neck392 — Wed, 21 May 2025 00:02:28 +0900

침해사고 분석 문제들을 풀어보면 공격자 IP를 식별하는 과정을 필요로 한다. IP 주소 공간에 대해 깊이 있는 내용을 탐구해 본다.

1. IP 주소: 129.3.4.5

첫 번째 바이트: 129
이진수: 10000001이므로 맨 앞 두 비트가 10
혹은, 첫 바이트가 128 to 191에 속함

따라서 클래스 B에 해당한다.

클래스 B의 구조에서 Prefix는 16비트이며 Suffix도 16비트(32-16)이다.

따라서 Net ID는 129.3이 되며,

Host ID는 4.5가 된다.

호스트 부분을 모두 0으로 설정한 129.3.0.0가 네트워크 주소이며,

호스트 부분을 모두 1로 설정한 IP: 129.3.255.255가 브로드캐스트 주소가 된다.

할당 가능한 주소의 개수

그렇다면 할당 가능한 호스트의 개수는 몇 개일까?

Suffix가 16비트이므로 2^16 = 65,536 이지만

네트워크 주소와 브로드캐스트 주소를 제외해야 하므로

2^16 - 2 = 65,534(개)

<정리>

IP 주소        : 129.3.4.5/16
이진 표현      : 10000001.00000011.00000100.00000101

[ Net ID ]     : 앞 16비트 → 129.3
[ Host ID ]    : 뒤 16비트 → 4.5

Network addr   : 129.3.0.0/16
Broadcast addr : 129.3.255.255/16
Host 범위      : 129.3.0.1 ~ 129.3.255.254
할당 가능한 호스트 수 : 2^16 - 2 = 65,534 개

2. IP 주소: 167.199.170.82/27

마지막 8비트가 82이다. 이진수로 표현하면 01010010가 된다.

27+5=32이므로 마지막 5비트가 Suffix이다.

호스트 비트 00000
→ 10100111.11000111.10101010.01000000
→ 167 .199 .170 .64

네트워크 주소: 167.199.170.64/27

호스트 비트 11111
→ 10100111.11000111.10101010.01011111
→ 167 .199 .170 .95

브로드캐스트 주소: 167.199.170.95

네트워크 주소 : 167.199.170.64/27 ← Host bits = 00000
브로드캐스트 주소 : 167.199.170.95 ← Host bits = 11111
할당 가능한 주소 : 167.199.170.65 ~ 167.199.170.94
호스트 개수 : 2^5 - 2 = 30 개

Reference

[1] B. A. Forouzan, Data Communications and Networking, 5th ed., New York: McGraw-Hill Education, 2013.

[네트워크] IPv4 Address Space

neck392 — Tue, 20 May 2025 23:02:35 +0900

침해사고 분석 문제들을 풀어보면 공격자 IP를 식별하는 과정을 필요로 한다. IP 주소 공간에 대해 깊이 있는 내용을 탐구해 본다.

IPv4에서 주소 공간이란 사용 가능한 모든 IP 주소의 범위를 의미한다.

IPv4는 32비트 주소를 사용 (MAC 주소는 48비트)
주소 공간은 2^32개가 된다.

2^32 = 4,294,967,296

즉, 이론적으로 약 43억 개의 고유한 IP 주소를 만들 수 있다.

제한 사항

이론상 43억 개의 주소가 존재하지만, 모든 주소가 실제 사용 가능한 것은 아니다.

사용 불가능한 주소

127.0.0.0/8	루프백(Loopback) 주소
0.0.0.0	미지정 주소 (Default route 등)
192.168.0.0/16, 10.0.0.0/8 등	사설(Private) IP 주소
224.0.0.0 ~ 239.255.255.255	멀티캐스트(Multicast)
240.0.0.0 ~ 255.255.255.255	미래 예약(Reserved)

이로 인해 사용 가능한 IPv4 주소는 이론치보다 훨씬 적다. 그러나 IPv6는 128비트 주소를 사용한다.

2^128 ≈ 3.4 × 10^38

사실상 무제한에 가까운 IP 주소 제공이 가능하다.

<IPv6의 표현 방식>

IP 주소의 구조

<Ip의 구조>

하나의 IP 주소는 네트워크를 식별하는 부분과 개별 장치를 식별하는 부분으로 나누어 진다.

총 32비트로 구성된 주소
예: 192.168.1.10 8비트 × 4 = 32비트

Prefix (n bits): 네트워크 부분

앞쪽의 n비트는 "어느 네트워크인가?"를 나타낸다.
예를 들어 /24이면 앞 24비트가 prefix이다. (즉, 끝의 /n의 값은 프리픽스의 길이를 의미)

<프리픽스의 길이와 예시>

이 값이 같으면 같은 네트워크에 있는 장치들이다.

192.168.1.0/24에서 Prefix(=net id)는 192.168.1이 된다.

Suffix ((32 - n) bits): 호스트(장치) 부분

뒤쪽의 (32 - n)비트는 "네트워크 내에서 어떤 장치인가?"를 나타낸다.
즉, 동일한 네트워크 내에서 각 장치를 구별하는 용도이다.

192.168.1.10에서 10이 Suffix(=host id)이다.

IPv4 주소 클래스(Classful Addressing)

IPv4 주소는 과거에 주소 크기(네트워크 규모)에 따라 5개의 클래스(A~E)로 나누었다. 이 방식을 클래스풀(classful) 주소 지정 방식이라고 한다.

클래스	맨 앞 비트	Prefix 길이	Suffix 길이	첫 바이트 범위	용도
A	0xxx xxxx	8비트	24비트	0 ~ 127	대규모 네트워크
B	10xx xxxx	16비트	16비트	128 ~ 191	중간 규모 네트워크
C	110x xxxx	24비트	8비트	192 ~ 223	소규모 네트워크
D	1110 xxxx	해당 없음	해당 없음	224 ~ 239	멀티캐스트용 주소
E	1111 xxxx	해당 없음	해당 없음	240 ~ 255	실험적 / 예약됨 (사용 안 함)

첫 바이트의 비트 형태에 따라 클래스가 결정된다고도 표현할 수 있다.

Reference

Behrouz A. Forouzan, Data Communications and Networking, 5th Edition, McGraw-Hill Education, 2013. ISBN: 9780073376226.

[네트워크 해킹] OSI 7 계층과 패킷 분석 개요

neck392 — Sun, 30 Mar 2025 10:29:50 +0900

네트워크 개요

정보보안 관점에서 네트워크가 중요한 이유

네트워크와 관련된 다양한 해킹 공격 시나리오가 존재
MTIM, ARP 스푸핑, 디도스 등등

네트워크란?

단순히 시스템 컴퓨터에 한정되지 않고 객체, 사람 등이 서로 연결되어 정보나 자원을 교환하거나 상호작용 하는 구조나 시스템을 의미
컴퓨터 네트워크는 컴퓨터 기기들이 서로 연결되어 정보를 공유할 수 있도록 구성된 시스템

네트워크의 종류

LAN : 논리적, 물리적 영역 안에서 연결된 네트워크
WAN : 넓은 지리적 영역에 걸쳐있는 컴퓨터 및 자원을 연결

도시, 국가, 대륙 간 ISP(end system에게 다양한 네트워크 접속을 제공)에 의해 관리된다.

하위 계층 ISP는 국가, 국제 상위 계층 ISP를 통해 연결된다.

인터넷

전 세계적으로 컴퓨터 장치(end system)를 연결하는 컴퓨터 네트워크 (네트워크의 네트워크)

패킷

end system에서 수신하여 end system으로 보내지는 데이터
보내고자하는 데이터를 segment 단위로 나누고, 각 segment에 헤더를 연결하여 전송
캡슐화된 시스템에 의거하여 목적지에서 다시 조립

경로(=path or route)

패킷이 수신되어 end system에 도달하는 동안 거쳐온 모든(일련의) 통신 링크

OSI 7 계층

프로토콜 스택을 거치면서 기존 정보에 헤더를 붙여서 캡슐화 한다. 여기서 프로토콜은 장치 간에 통신할 때 지켜야 하는 규약이며 메시지의 형식, 순서, 메시지 전송, 수신시 수행하는 작업을 정의한다. 라우터는 3계층 패킷 교환기(네트워크 계층 주소 사용), 스위치(패킷 스위치이지만 mac 주소 사용)는 2계층 패킷 교환기이다.

계층적 구조를 사용하는 이유

계층 구조는 크고 복잡한 시스템의 정의된 특정 부분을 논의할 수 있게 해준다. -> 단순화
어떤 계층의 하나의 형태가 변하더라도 나머지 계층에 크게 영향을 주지 않는다.

물리 계층

단위: 비트
프레임 내부의 각 비트를 한 노드에서 다음 노드로 이동 (실제 전송 매체에 의존한다.)

데이터링크 계층

단위: 프레임
전체 프레임을 한 네트워크 요소에서 이웃 네트워크 요소로 이동
서비스가 해당 링크 계층에서 사용하는 프로트콜에 의해 결정된다.
다음 상위 계층인 네트워크 계층은 "데이터그램"을 링크 계층으로 보낸다 즉, "링크 계층 서비스에 의존"한다. 라고 표현할 수 있다.

네트워크 계층

단위: 데이터그램(=패킷)
한 호스트에서 다른 호스트로 데이터의 최적의 경로를 선택하고 데이터그램을 전송한다. 즉 라우팅의 역할을 수행
네트워크 계층을 가진 모든 인터넷 요소는 ip 프로토콜을 수행한다.
상위 계층 전송 계층에서 세그먼트를 운반한다.

전송 계층

단위: 세그먼트
클라이언트와 서버 간에 애플리케이션 계층 메시지를 전송하는 서비스 제공
TCP
- 연결 지향형 서비스를 제공
- 흐름 제어를 포함(송신자와 수신자와의 속도 일치)
- 혼잡 제어 기능 제공(출발지의 전송률을 줄임)
UDP
- 비연결형 서비스 제공
- 신뢰성, 흐름 제어, 혼잡 제어등을 제공하지 않는다.
- 따라서 영화같은 데이터 량이 방대한 서비스에서 깨짐 현상이 일어난다.

세션 계층

기기 간 통신을 담당하고 제어한다(생성, 유지, 종료).
리소스 낭비를 방지하기 위하여 세션 개방과 종료의 시간을 결정한다(인증과 재연결 포함).

표현 계층(구문 계층이라 표현하기도 한다.)

구문과 의미론에 따라 데이터를 변형하기도 한다.
즉, 응용 계층에서 요구하는 대부분의 암호화와 복호화를 수행한다.

응용 계층

단위: 메시지
네트워크 애플리케이션과 애플리케이션 계층 프로토콜
end system에 있는 애리케이션 간에 메시지를 교환하는데 사용
소프트웨어와 직접 상호작용을 수행

TCP/IP 와 OSI

두 모델에서 2개의 계층인 세션 계층과 표현 계층이 TCP/IP 프로토콜 그룹에는 없다. 그 이유는 크게 2가지로 유추해 볼 수 있다.

TCP/IP는 하나 이상의 전송층 프로토콜을 가지고 있다.
- 세션층의 일부 기능은 몇몇 전송층 프로토콜에서 가능
응용 계층이 단순히 소프트웨어의 한 부분만은 아니다.
- 만약 세션 그리고 표현 계층에서 사용하는 기능 중 몇 개가 특정 응용 계층에서 필요로 한다면, 소프트웨어의 한 부분으로 개발할 수 있다.

OSI 모델이 TCP/IP 모델을 모두 대체하지 못한 이유

OSI 모델은 TCP/IP 모델 이후에 나타났으나 TCP/IP 모델을 완벽히 대체하지는 못하였다.

OSI 모델은 TCP/IP 모델이 나오고 많은 시간이 흐른 뒤에 등장하였다.
- TCP/IP 모델이 이미 완전히 자리잡고, 많은 돈과 시간이 TCP/IP 그룹에 투자되고 난 이후에 완성되었다.
OSI 모델의 일부 계층은 완전히 정의되지 않았다.
- 표현 계층과 세션 계층에 의해 제공된 서비스들이 문서에는 기술되어 있으나 두 계층에 대한 실제 프로토콜은 완전히 정의되거나 기술되지 않았다. 당연히 이에 따라 대응하는 소프트웨어가 완전히 개발되지 않았다.
OSI가 완전히 구현되었을 때 TCP/IP 프로토콜에서 OSI 모델로 완전히 전환하기 위한 충분히 높은 수준의 성능을 보여주지 못하였다.

네트워크 패킷 분석

WireShark를 사용하여 실제 패킷을 간략하게 분석해본다. 와이어샤크는 호스트 장치에서 발생하는 네트워크 패킷을 캡쳐하고 분석할 수 있는 도구이다. 디지털 포렌식적 관점에서 트래픽이 오갈 때 공격자 행위를 유추 및 분석(명확한 타임라인 확보 등)하는 것에 가치가 있는 도구이다. 이번에는 와이어샤크로 간단한 분석을 진행해 본다.

와이어샤크 도구를 처음 실행해보면 많은 패킷이 오가는 것을 식별할 수 있으며 만약 엣지 브라우저를 사용하고 있으면 크롬 기반이기에 QUIC 프로토콜이 많은 것을 확인할 수 있다.

패킷을 분석해보기 React를 사용하여 간단한 페이지를 제작하여 로컬호스트로 접속하는 과정을 와이어샤크로 캡쳐해 본다.

<로컬호스트 열기(npm start)>

react로 간단한 페이지를 제작한 후에 npm start 명령어를 입력하여 로컬호스트로 접속가능한 웹 페이지를 간단하고 빠르게 실행할 수 있다. (3000포트 사용 설정)

<구현한 웹페이지>

웹페이지에 접속하기전 와이어샤크 캡처를 시작한 후에 http 패킷 분석을 진행한다.

http 필터를 적용하고 보면 여러 해당 패킷들을 확인할 수 있다. 로컬 호스트로 된 페이지에 접속하였으므로 Source와 Destination의 IP가 동일하다. 빨간색 박스의 HTTP 처음 통신 과정 응답에서 보통 HTTP/1.1 200 OK로 시작하지만 304 Not Modified인 이유는 브라우저 캐시 때문이다. 이는 react를 로컬호스트로 실행하면 생기는 정상적인 동작이며 이전에 브라우저에서 한번 받아본 적이 있으면 파일 변경 여부에 대한 조건부 요청을 보내고 파일이 변경되지 않았으면 304 Not Modified로 응답하며 브라우저는 캐시에 저장된 파일을 그대로 사용한다. 리소스를 수정한 뒤에 새로 저장하여 빌드하면 파일의 해시와 타임스탬프가 변경되기에 브라우저가 새 파일을 인식하고 200 OK를 보내게 된다.

<개요>

위의 개요에서 Frame은 데이터링크에서 사용하는 단위이며 데이터 링크 계층에서 네트워크 요소로 전달하기 위한 모든 데이터를 담고있기에 Frame을 오버레이(클릭)하면 모든 데이터가 select된다.

상단에 0100 4개의 비트를 사용하여 Version을 나타낸다. Protocol에서 TCP를 사용함(세그먼트가 어떤 프로토콜을 사용하는 지)을 나타내고 있으며 Time to Live(TTL)에서는 네트워크에서 데이터가 헛돌게 하지 않기 위하여 라우팅 되는 과정에서 제한을 걸어둔다. Header Checksum에서는 데이터그램의 비트 손실 여부를 판단한다.

상단에 Source Port(59185)와 Destination Port(3000)을 확인할 수 있다. Sequence Number와 Acknowledgment Number를 통하여 TCP로 요청과 응답을 받으며 신뢰적인 연결임을 알 수 있다.

상기의 http request를 확인해보면 http 버전(1.1) method인 GET 방식을 확인(URL로 접속하였기 때문)할 수 있으며 Host 즉 서버에 대한 정보(주소)도 확인할 수 있다. 밑으로 많은 Header들을 볼 수 있는데 여기서 User-Agent는 본인이 현재 접속한 장치의 환경을 나타낸다. 브라우저 서버는 여기서 모바일 및 컴퓨터 장치를 식별하여 웹페이지를 다르게 나타낸다.

요청에 대한 응답 패킷을 확인해보면 Date로 날짜도 확인할 수 있다. 이후 빨간색 동그라미의 \r\n 개행 아래에는 응답에 대한 본문(데이터)이 담겨 있다.

추가 기능

<follow -> TCP Stream 클릭>

<요청과 응답 확인>

와이어샤크에서 패킷을 우클릭하고 follow -> tcp stream을 클릭하면 오고간 데이터들을 직관적으로 확인할 수 있다.

<Statistics -> Flow Graph 클릭>

추가적으로 Statistics -> Flow Graph를 클릭하면 TCP의 3-way handshake 과정을 포함하여 직관적으로 확인할 수 있다. 앞서 TCP 상세에서의 SYN과 ACK가 오고가는 과정을 한눈에 알기 쉽다. 좌측 하단의 Limit to display filter를 클릭하면 와이어샤크에서 적용한 필터를 Flow Graph에서도 적용할 수 있으며 "ip.addr == (주소)"필터를 사용하여 더욱 편하게 확인할 수 있다. 위의 TCP 연결에서는 로컬호스트를 사용하였기에 소스 주소와 목적지 주소가 동일하여 예외적으로 일반적인 경우보다 직관성이 떨어진다.

Reference

Behrouz A. Forouzan, Data Communications and Networking 5th ed, McGraw-Hill Education, 2012.

[메모리] 단일 프로그래밍 연속 메모리 할당

neck392 — Thu, 26 Dec 2024 00:21:03 +0900

단일 프로그래밍 환경에서의 연속 메모리 할당은 단일 사용자 환경의 연속 메모리 할당이라고도 할 수 있다.

<메모리할당 - 연속 메모리 - 단일 프로그래밍>

메모리 할당(=적재)에서 말 그대로 연속적으로 메모리를 적재하는 것이 연속 메모리 할당이다. 연속 메모리 할당은 다시 한번에 하나의 프로그램만 실행시키는 단일 프로그래밍 환경과 여러 프로그램을 동시에 메모리에 적재하고 실행시키는 다중 프로그래밍(=멀티 프로그래밍) 환경으로 나눌 수 있으며 여기서는 단일 프로그래밍 환경을 다룬다.

<전형적인 단일 프로그래밍 연속 메모리 할당 시스템>

초기 컴퓨터 시스템에서 단일 사용자(하나의 프로그램)만이 실행될 수 있었고 자원도 해당 프로그램 혼자만 사용하였다. 그리고 프로그램은 메모리보다 클 수 없었으며 프로그래머가 직접 배치 과정을 수행하여 항상 같은 메모리 위치에 적재하였다.

그러나 시스템 설계자들은 기본 기능을 구현한 입출력 코딩을 입출력 제어 시스템(Input/Output Control System, IOCS)에 통합하여 각 프로그램을 위하여 새로 작성할 필요없이 IOCS 루틴을 호출해 원하는 작업을 수행하였다. IOCS는 코딩 과정을 매우 간단하고 빠르게 진행하게 해주었으며 입출력 제어 시스템 구현은 현태 운영체제 개념의 시작이라 할 수 있다.

단일 프로그래밍 환경에서 연속 메모리 할당은 사용자 영역과 운영체제가 상주하는 모니터 영역, 사용하지 않는 미사용 영역으로 나눌 수 있다. 여기서 운영체제가 상주하는 모니터 영역은 상위나 하위 모두 둘 수 있다.

메모리를 제어하는 모든 권한이 사용자에게 있기 때문에 사용자가 주소를 잘못 지정하면 운영체제가 손상되는 문제가 생긴다. 따라서 아래 그림과 같이 경계(한계) 레지스터를 사용하여 사용자 프로그램이 메모리 주소를 참조할 때마다 경계 레지스터를 검사한 후 실행하여 메모리를 보호한다.

<경계 레지스터를 활용한 메모리 보호 기법 적용>

앞서 연속 메모리 할당 시스템에서 프로그램은 메모리보다 클 수 없다고 서술하였으며 따라서 프로그램의 크기가 제한되었다. 소프트웨어 설계자들은 이러한 메모리의 한계를 극복하기 위하여 중첩(Overlay)을 생성하여 메인 메모리보다 큰 프로그램을 실행할 수 있게 해주었다. 프로그래머는 프로그램을 논리적인 구역으로 나누고 프로그램이 특정 구역에 필요한 메모리를 요구하지 않을 때, 시스템은 해당 구역의 일부나 전체를 필요한 구역의 메모리와 교체할 수 있다.

중첩과 관련된 자세한 내용은 블로그 앞의 글에서 짚고 넘어갔으므로 생략한다.

[Dreamhack] BMP Recovery Write-up

neck392 — Wed, 25 Dec 2024 02:30:49 +0900

1. BMP Recovery

<문제 설명>

<문제 파일>

<또 백만년만에 쓰는 롸업이다>

2. Explanation

디지털 포렌식을 공부하며 처음하였던 것이 각 파일 구조를 기반으로 바이너리 데이터를 분석하는 것이었기에 이 문제를 보고 자신있게 시작했던 기억이 난다. 아무튼 우선 chal.py를 열어서 코드를 분석한다.

<chal.py>

flag.bmp 파일을 열어서 data에 해당 파일의 바이너리 데이터를 저장하고

1) data[:0x1C] = b'\x00' * 0x1C
- 첫 번째 바이트부터 0x1C까지
- 즉, 0~28바이트까지 '00'으로 저장(1C이므로 길이는 28바이트)
2) data[0x22:0x36] = b'\x00' * 0x14
- 0x22번째 바이트 부터 0x36번째 바이트까지 0x14길이의 데이터를 '00'으로 저장
- 34번째 바이트부터 54번째 바이트까지 20바이트를 '00'으로 저장

이후에 다시 수정한 파일을 flag.bmp.broken으로 저장한다.

<flag.bmp.broken 파일 확인>

16진수 한 개의 값은 2개의 문자로 이루어져 있으며 문자 1개의 크기는 4bit이므로 16진수 한 개의 값은 4bit+4bit=1byte가 된다.

따라서 flag.bmp.broken 파일을 확인해보면 위와 같이 빨간 박스 안의 28바이트가 00으로 수정되었으며 파란 박스 안의 20바이트가 00으로 수정되었음을 알 수 있다.

우선 BitMapFile Header에 정의된 구조체에 의거하여 14바이트의 File Header 데이터를 수정해본다.

우선 처음 2바이트는 .bmp 파일의 파일 시그니처인 '42 4D'를 입력한다[1].

<속성에서 파일 크기 확인>

다음 4바이트는 파일의 크기를 입력한다. 파일 속성에서 파일 크기 14,309,622 바이트를 확인할 수 있으며 16진수로 변환하면 "00 DA 58 F6"이 되지만 컴퓨터는 데이터를 Little Endian 방식으로 처리하기 때문에 이에 맞게 "F6 58 DA 00"를 입력해준다[2].

다음 2바이트 + 2바이트 총 4바이트는 는 예약된 영역이므로 항상 0이다. 따라서 "00"을 입력한다[3][4].

그 다음 4바이트는 픽셀 데이터의 시작 위치(오프셋)로 헤더 영역들의 length 합을 입력하며 file header의 14바이트와 info header의 40바이트를 더하여 54바이트, 16진수로 "36"을 입력한다[5].

파일명도 flag.bmp로 저장하고 작업을 편리하게 하기 위하여 나머지는 010 editer를 사용하여 분석 및 수정한다.

<010 editor 사용>

file header는 hxd editor로 수정하였기에 info(info header)를 살펴본다.

<가로(Width)와 세로(Height)를 제외한 나머지 값 입력>

info header의 크기는 40바이트이므로 biSize에 40을 입력한다.

biPlanes의 지원되는 값은 1로 고정되므로 1을 입력한다.

biSizeImage는 이미지 데이터의 크기이다. 전체 데이터의 크기가 14309622이므로 header 크기인 54바이트를 제외하면 14309568바이트가 된다. 밑의 나머지 데이터는 일반적으로 0이다.

<입력한 데이터>

Width와 Height값을 구하기 위하여 경우의 수를 생각해본다.

PNG 파일은 CRC 값을 이용하여 width와 height 값을 구할 수 있지만 BMP 파일에서는 불가능하다.

이미지 데이터의 크기가 14309568바이트(14309622 - 54)이며 픽셀에 할당된 바이트 수가 24bit(biBitCount)이므로 3바이트이다. 따라서 픽셀 데이터의 크기는 14309568 / 3을 수행하면 4,769,856바이트가 된다.

따라서 Width * Height = 4,769,856이 되는 경우의 수를 코드를 짜서 살펴본다.

def findDimensions(totalPixels):
    dimensions = set()
    for width in range(1, int(totalPixels**0.5) + 1):
        if totalPixels % width == 0:
            height = totalPixels // width
            dimensions.add((width, height))
            dimensions.add((height, width))
    return sorted(dimensions)

totalPixels = 4769856
dimensions = findDimensions(totalPixels)

for width, height in dimensions:
    print(f"Width: {width}, Height: {height}")

<모든 경우의 수 출력>

위와 같이 Width * Height = 4,769,856이 되는 모든 경우의 수를 출력해보니 경우의 수가 많으므로 직접 바이너리 데이터를 수정해가며 찾는 것 보다는 각 경우의 수에 해당하는 Width와 Height 값들을 수정 및 각각의 bmp 파일로 저장하여 명확히 복구된 이미지 파일을 찾아본다.

def findDimensions(totalPixels):
    dimensions = set()
    for width in range(1, int(totalPixels**0.5) + 1):
        if totalPixels % width == 0:
            height = totalPixels // width
            dimensions.add((width, height))
            dimensions.add((height, width))
    return sorted(dimensions)

def convertLittleEndianBytes(value, length):
    return value.to_bytes(length, 'little')

def saveBmpFiles(originalBmpPath, totalPixels):
    dimensions = findDimensions(totalPixels)

    with open(originalBmpPath, 'rb') as bmpFile:
        originalData = bmpFile.read()

    for width, height in dimensions:
        modifiedData = bytearray(originalData)

        widthBytes = convertLittleEndianBytes(width, 4)
        heightBytes = convertLittleEndianBytes(height, 4)

        modifiedData[18:22] = widthBytes
        modifiedData[22:26] = heightBytes

        newFileName = f"flag_{width}x{height}.bmp"
        with open(newFileName, 'wb') as newBmpFile:
            newBmpFile.write(modifiedData)

originalBmpPath = 'flag.bmp'
totalPixels = 4769856
saveBmpFiles(originalBmpPath, totalPixels)

<코드 동작 결과>

위와 같이 코드를 동작하였을 때 정상적으로 Width와 Height 길이에 대한 경우의 수에 따른 bmp 파일들이 생성되며 여기서 이미지가 명확히 보이는 파일을 찾아보면

위와 같이 flag를 찾을 수 있다.

3. Reference

https://velog.io/@jaeyoonheo/bmp-reader

https://blog.naver.com/lunchtime82/100055581202

[Dreamhack] sleepingshark Write-up

neck392 — Tue, 24 Dec 2024 03:29:08 +0900

1. sleepingshark

2022 Fall GoN Open Qual

<문제 설명>

<문제 파일>

2. Explanation

dump.pcap 파일을 Wireshark로 열어보면 아래와 같이 나타난다.

<문제 파일 열기>

HTTP 통신이 많기에 server로의 요청 내역들만 모아본다.

위와 같이 Statistics > HTTP > Requests에서 확인할 수 있다.

URL의 Query string을 보았을 때 SELECT와 FROM 등 SQL 문법으로 보이는 문자열들을 확인할 수 있으며 SQL Injection 공격을 시도 중인 것으로 유추할 수 있다.

따라서, 명확히 판단하기 위하여 http 패킷을 분석 해본다. 위 사진과 같이 http로 필터링을 한 후에 무작위의 19번 패킷의 Info를 URL Decode한다.

SELECT IF(ASCII(SUBSTRING((SELECT flag FROM s3cr3t LIMIT 1),34,1))=45, SLEEP(3), 0)

위와 같은 Query String을 확인할 수 있다. 쿼리문을 분석해보면 다음과 같다.

SELECT flag FROM s3cr3t LIMIT 1
- s3cr3t라는 테이블에서 flag라는 컬럼의 1번째 행의 데이터
SUBSTRING((SELECT flag FROM s3cr3t LIMIT 1), 34, 1)
- flag 컬럼 데이터에서 34인덱스의 문자를 추출(0부터 시작)하여 반환
- 34는 start position 즉 추출을 시작할 문자의 위치를 의미
- 1은 length 추출할 문자의 길이를 의미
IF(ASCII(...) = 45, SLEEP(3), 0)
- 추출한 문자의 ASCII 값이 45인지 확인(45는 -(하이픈)을 의미)
- 조건이 참(TRUE)이면 3초 동안 지연 후 응답(SLEEP(3)).
- 조건이 거짓(FALSE)이면 지연 시간 없이 즉시 응답을 반환(0).

쿼리문을 분석해보았을 때 처음 유추하였던 것과 같이 SQL Injection 공격이 맞으며 그 중에서도 정확히는 Time-Based Bllind SQL Injection 공격을 시도하고 있음을 알 수 있다. 3초 동안 지연 후 응답된다는 것은 웹 페이지가 3초 동안 로딩되며 3초 이후에 정상적으로 웹 페이지가 로딩 후 동작되는 것을 의미한다. 이를 통하여 조건의 논리를 알 수 있다.

<쿼리문들 중 성공 여부 확인>

http 패킷 중에서 3초 뒤에 응답이 온 패킷을 필터링하였을 때 위와 같이 조건이 true인 패킷들이 존재한다.

따라서 위와 같은 형태의 쿼리문이 포함된 http 패킷들을 요청하였을 때 3초 뒤에 응답이 온 패킷들 즉, 요청 값이 True인 패킷들만 모아서 Query String을 분석하면 flag를 획득할 수 있다.

Python의 pyshark 라이브러리를 사용하여 코드를 짜본다.

import pyshark
import urllib.parse
import re

def extractLongDelayTimeRequests(pcapFile, setTime):
    cap = pyshark.FileCapture(pcapFile, display_filter='http')

    requestTimes = {}
    flag_parts = []

    for packet in cap:
        if 'HTTP' in packet:
            try:
                if hasattr(packet.http, 'request_full_uri'):
                    streamIndex = packet.tcp.stream
                    requestTime = float(packet.sniff_timestamp)
                    requestTimes[streamIndex] = (packet, requestTime)

                elif hasattr(packet.http, 'response_code'):
                    streamIndex = packet.tcp.stream
                    responseTime = float(packet.sniff_timestamp)

                    if streamIndex in requestTimes:
                        requestPacket, requestTime = requestTimes[streamIndex]
                        delayTime = responseTime - requestTime

                        if delayTime > setTime:
                            fullUri = requestPacket.http.request_full_uri
                            decodedUri = urllib.parse.unquote(fullUri)
                            print(f"Request Info (Encoded URI): {fullUri}")
                            print(f"Request Info (Decoded URI): {decodedUri}")
                            print(f"Delay Time: {delayTime} seconds")
                            print("")

                            match = re.search(r'SUBSTRING.*?,(\d+),1\)\)=(\d+)', decodedUri)
                            if match:
                                position = int(match.group(1))
                                ascii_value = int(match.group(2))
                                if len(flag_parts) < position:
                                    flag_parts.extend([None] * (position - len(flag_parts)))
                                flag_parts[position - 1] = chr(ascii_value)

            except AttributeError:
                continue

    cap.close()

    flag = ''.join([char for char in flag_parts if char])
    print(f"Extracted Flag: {flag}")

pcapFile = 'dump.pcap'
setTime = 3
extractLongDelayTimeRequests(pcapFile, setTime)

우선 위와 같이 Delay Time, 지연 시간이 3초 이상인 패킷들을 식별하여 해당 패킷의 Info와 Decode한 값들을 출력되게 하였다. 조건이 참인 모든 패킷들이 출력된다. 이후 Decode한 Query String에서 문자의 위치에 해당하는 아스키 코드 값을 조합하여 flag를 출력한다(출력되는 패킷들은 모두 조건이 True인 패킷들).

<코드 동작 결과>

코드를 동작시키면 위와 같이 flag를 획득할 수 있다.

3. Reference

https://taesam.tistory.com/25

https://blog.naver.com/stop2y/221033895075

https://www.urldecoder.org/

[Dreamhack] lolololologfile Write-up

neck392 — Thu, 19 Dec 2024 16:57:13 +0900

1. lolololologfile

2022 Christmas CTF

<문제 설명>

<문제 파일>

<이백만년만에 쓰는 롸업>

2. Explanation

문제 설명을 확인해보면 flag가 담긴 PDF 파일을 삭제하였다고 한다. FTK Imager로 분석해보았을 때 휴지통 아티팩트에도 남겨진 데이터가 없는 것으로 보아 휴지통에서도 완전히 삭제된 파일이라 유추할 수 있다. 따라서 비할당된 영역(unallocated space)을 통하여 PDF 파일 복구를 시도한다.

완전히 삭제된 파일은 경우에 따라 복구할 수 있다. NTFS 뿐만이 아니라 FAT 등의 파일 시스템은 실제 클러스터에 저장된 내용을 삭제하는 것이 아니라 파일에 할당된 클러스터를 사용 가능한 상태로 바꾸어 클러스터들이 다른 파일에 할당될 수 있게 한다. 따라서, 이미 덮어 써진 파일은 복구가 불가능하지만 그렇지 않은 삭제된 파일들은 복구할 수 있다.

삭제되어 데이터와 클러스터와의 연결이 끊어진 데이터들은 비할당 영역에 존재한다.

즉, 비할당 영역은 디렉토리 엔트리 정보가 사라지고 파일 데이터만 남아있는 공간을 뜻한다. 주로 포맷 이전의 데이터, 디렉토리 엔트리 정보 즉 메타데이터가 사라진 데이터들이 남아있다. FAT 영역에서 0x00의 값을 갖는 클러스터가 비할당 클러스터인데, 이 부분을 분석하면 데이터 카빙이 가능하다.

문제 파일을 FTK Imager로 열어본다.

<비할당된 영역 확인>

비할당 영역에 위와 같이 남겨진 데이터들이 존재함을 식별할 수 있다.

02067 파일의 바이너리 데이터를 확인해보면 PDF 파일의 헤더 시그니처를 식별할 수 있다. PDF 파일 구조를 기반으로 PDF 파일의 푸터 시그니처도 찾아본다.

<PDF 파일의 푸터 시그니처 식별>.

"CTRL+F"를 통하여 PDF 파일의 푸터 시그니처인 "25 25 45 4F 46"을 찾아본 결과 05082 파일에서 발견할 수 있다.

따라서, "02067" 파일과 "03405", "04466", "05082" 파일들을 Export하여 하나의 파일로 합치는 과정을 수행한다.

<하나로 합친 무제1 파일>

각 파일들의 바이터리 데이터를 순차적으로 연결하여 "무제1"로 저장한뒤에 .pdf 파일로 확장자를 추가한다.

해당 파일을 열어보면

다음과 같이 flag를 획득할 수 있다.

[메모리] 메모리 할당(적재) 개요

neck392 — Mon, 9 Dec 2024 04:23:35 +0900

<메모리 할당 방법>

초기 컴퓨터 시스템에서는 프로그램을 실행하려면 운영체제가 프로그램 전체를 수용할 수 있는 연속적인 메인 메모리 공간을 확보해야 했다. 프로그램이 여유 메모리보다 큰 경우 이를 실행할 수 없었다. 이와 같이 연속적인 메인 메모리 공간에 프로그램을 할당하는 방식을 연속 메모리 할당(Contiguous Memory Allocation)이라고 한다.

연속 메모리 할당에서 발생하는 문제점을 해결하기 위해 불연속 메모리 할당(Noncontiguous Memory Allocation)을 통해 메모리를 더 효율적으로 사용할 수 있다. 제한된 압축으로 메모리 할당을 변화시켜 외부 단편화 문제를 해결하면 연속적인 공간을 만들 수는 있지만, 실행 시간이 낭비된다.

불연속 메모리 할당은 프로그램을 블록 또는 세그먼트(Segment)로 나누고, 하나의 프로그램에 대하여 연속적으로 붙어 있지 않은 슬롯(Slot)들에 이 정보를 배치할 수 있다. 프로그램 전체를 수용하기엔 너무 작은 메모리 홀(사용하지 않는 작은 공간)을 활용할 수 있게 되었다(외부 단편화=메모리 홀 문제 해결). 운영체제에 더 큰 오버헤드(프로그램이 실행되거나 데이터를 저장하는 데 직접적으로 사용되지 않는 추가적인 메모리 소비)가 발생하지만, 다중 프로그래밍 수준(한번에 메인 메모리에 위치할 수 있는 프로세스 수)이 증가한다. 고정 분할에 해당하는 페이징은 프로그램 하나를 분할하는 기준에 따라 동일한 크기로 나누어 메모리에 적재한다. 세그먼테이션은 크기는 일정하지 않지만 여러 의미 단위로 나누어 메모리로 적재한다.

연속 메모리 할당

고정 분할 방법은 크기가 다른 프로세스에 모두 같은 크기의 메모리를 할당하여 메모리 낭비를 초래
프로세스의 크기에 따라 메모리를 다르게 분할하는 가변 분할 방법 제시
그러나 연속 메모리 할당에서 고정 분할과 가변 분할 모두 효과적인 메모리 활용법은 아니다(내부, 외부 단편화 문제).

불연속 메모리 할당

프로그램 하나가 물리적 주소의 여러 공간에 분산
고정분할에 해당하는 페이징은 프로그램 하나를 분할하는 기준에 따라 동일한 크기로 나누어 메모리에 적재
가변분할에 해당하는 세그먼테이션은 크기는 일정하지 않지만 여러 의미 단위로 나누어 메모리에 적재

Reference

Harvey M. Deitel, Paul J. Deitel, and David R. Choffnes, Operating Systems, 3rd ed., Pearson, 2003.
Hyun-Hoe Koo, Operating System: Principles and Structure Illustrated, 1st ed., Hanbit Academy, 2016. (7th printing, 2022).