기준: 교수님 출제 언급 항목 중심
구성: ① 암기해야 할 개념·공식 정리 ② 예상 문제 및 해설

1. 암기해야 할 개념과 공식 정리

1.1 강한 인공지능과 약한 인공지능

시험 포인트
예제를 보고 “강한 AI인지, 약한 AI인지” 구별할 수 있어야 한다. 현재 대부분의 AI 제품은 특정 기능에 특화되어 있으므로 약한 인공지능에 해당한다.

1.2 1차 인공지능 겨울의 시작 계기

• 일반적인 시험 답안: 라이트힐 보고서를 계기로 인공지능에 대한 기대가 꺾이고 지원이 줄어들면서 1차 인공지능 겨울이 시작되었다.
• 함께 알아둘 내용: 1969년 민스키와 페퍼트의 『Perceptrons』는 퍼셉트론이 XOR 문제를 해결하지 못하는 선형 분류기에 불과하다는 한계를 지적했고, 이는 신경망 연구 퇴조에 영향을 주었다.

한 줄 암기
1차 인공지능 겨울은 과도한 기대에 비해 성과가 부족했고, 라이트힐 보고서 등으로 지원이 축소되면서 시작되었다.

1.3 인공지능, 기계 학습, 신경망, 딥러닝의 포함 관계

포함 관계는 다음과 같다.

인공지능 ⊃ 기계 학습 ⊃ 신경망 ⊃ 딥러닝

• 인공지능: 인간의 지능적 기능을 컴퓨터로 구현하려는 큰 분야
• 기계 학습: 데이터를 이용해 모델이 규칙을 학습하는 방법
• 신경망: 뉴런 구조에서 영감을 받은 기계 학습 모델 계열
• 딥러닝: 신경망에 층을 많이 쌓아 깊게 만든 방법

1.4 데이터셋의 표현: 특징 벡터와 레이블

기계 학습에서 하나의 샘플은 보통 다음처럼 표현한다.

특징 벡터: x = (x1, x2, ..., xd)
레이블: y

• d: 특징의 개수, 즉 특징 벡터의 차원
• x: 샘플을 수치로 표현한 특징 벡터
• y: 해당 샘플의 정답 부류

예를 들어 iris 데이터에서 특징이 4개라면,

x = (꽃받침 길이, 꽃받침 너비, 꽃잎 길이, 꽃잎 너비)

1.5 원핫 코드

레이블이나 이름형 범주형 특징은 원핫 코드로 표현할 수 있다.

예: 붓꽃 3개 부류

예: 혈액형

시험 포인트

• 수치형 특징: 실수, 정수, 이진값처럼 거리 개념이 있는 특징
• 순서형 범주형 특징: 학점, 수능 등급처럼 순서가 있는 특징. 정수 부여 가능
• 이름형 범주형 특징: 혈액형, 지역처럼 거리 개념이 없는 특징. 원핫 코드가 적절

1.6 다차원 특징 공간에서 유클리디언 거리

두 점이 다음과 같을 때,

x = (x1, x2, ..., xd)
y = (y1, y2, ..., yd)

두 점 사이의 유클리디언 거리는 다음과 같다.

d(x, y) = sqrt((x1-y1)^2 + (x2-y2)^2 + ... + (xd-yd)^2)
        = sqrt(Σ(i=1 to d) (xi-yi)^2)

예:

x = (1, 2, 3), y = (4, 6, 3)
d(x,y) = sqrt((1-4)^2 + (2-6)^2 + (3-3)^2)
       = sqrt(9 + 16 + 0)
       = 5

1.7 혼동 행렬과 FN, FP, TP, TN

이진 분류에서는 먼저 무엇을 긍정 positive으로 볼지 정해야 한다. 예를 들어 환자 검출 문제라면 “환자”가 긍정이다.

거짓 부정 FN
실제로는 긍정인데 모델이 부정이라고 예측한 경우이다. 예를 들어 실제 환자인데 정상이라고 판정한 경우가 FN이다.

1.8 성능 측정 공식

정확률(Accuracy) = (TP + TN) / (TP + TN + FP + FN)

특이도(Specificity) = TN / (TN + FP)

민감도(Sensitivity) = TP / (TP + FN)

정밀도(Precision) = TP / (TP + FP)

재현률(Recall) = TP / (TP + FN)

• 민감도와 재현률은 공식이 같다.
• 의료 진단에서는 민감도와 특이도가 중요하게 쓰인다.
• 정보검색에서는 정밀도와 재현률이 중요하게 쓰인다.

1.9 정확률만으로 평가하면 안 되는 이유

정확률은 전체 샘플 중 맞힌 비율이다. 하지만 부류가 불균형한 경우 모델 성능을 제대로 반영하지 못한다.

예:

정상인 990명, 환자 10명
모델이 모두 정상이라고 예측

이 경우 정확률은 990/1000 = 99%로 매우 높지만, 환자 10명을 모두 놓쳤으므로 민감도는 0이다. 따라서 불균형 데이터에서는 정확률만 보지 말고 민감도, 특이도, 정밀도, 재현률 등을 함께 봐야 한다.

1.10 5-겹 교차 검증

5-겹 교차 검증은 데이터를 5개 부분으로 나누고, 매번 1개 부분을 검증용으로 남겨둔 뒤 나머지 4개로 학습하는 방법이다. 이렇게 총 5번 실험하고 5개의 성능을 평균낸다.

왜 한 번만 구하지 않는가?
훈련/테스트 분할이 우연히 좋거나 나쁘게 될 수 있기 때문이다. 교차 검증은 여러 번 나누어 평가한 뒤 평균을 내므로 우연의 영향을 줄이고 일반화 성능을 더 신뢰성 있게 추정할 수 있다.

1.11 SVM의 원리

SVM의 핵심 목표는 일반화 능력을 높이는 결정 경계를 찾는 것이다.

• SVM은 두 부류 사이의 거리를 최대화하는 결정 경계를 찾는다.
• 두 부류까지의 거리인 2s를 여백 margin이라고 한다.
• 여백이 클수록 새로운 데이터가 조금 변해도 결정 경계를 넘을 가능성이 낮아 일반화 능력이 좋아진다.

x의 역할
x는 샘플을 표현한 특징 벡터이다. SVM에서는 각 샘플 x가 특징 공간의 한 점으로 놓이고, 모델은 이 점들을 잘 나누는 결정 경계를 찾는다.

1.12 퍼셉트론의 구조와 연산

퍼셉트론은 입력층과 출력층으로 구성된 이진 분류기이다.

• 입력층: d+1개의 노드
• d: 특징 벡터의 차원
• x0 = 1: 바이어스 노드
• 각 입력 xi는 가중치 wi와 연결됨

퍼셉트론은 다음 값을 계산한다.

s = w0x0 + w1x1 + ... + wdxd

그리고 계단 함수를 적용한다.

τ(s) = +1, if s > 0
τ(s) = -1, if s <= 0

즉 퍼셉트론은 특징 벡터를 +1 또는 -1로 분류하는 장치이다.

1.13 OR 게이트와 AND 게이트 구별

OR 게이트 예시

w0 = -0.5, w1 = 1, w2 = 1
s = -0.5 + x1 + x2

하나라도 1이면 +1이므로 OR 게이트이다.

AND 게이트 예시

w0 = -1.5, w1 = 1, w2 = 1
s = -1.5 + x1 + x2

둘 다 1일 때만 +1이므로 AND 게이트이다.

1.14 경사 하강법의 규칙

경사 하강법은 손실 함수 J를 줄이는 방향으로 가중치를 조금씩 수정하는 방법이다.

일반적으로는 다음처럼 쓴다.

w ← w - ρ∇J

수업 자료의 표현으로 쓰면,

w ← w + ρ(-∇J)

• ρ: 학습률 learning rate
• ∇J: 손실 함수의 기울기
• 기울기의 반대 방향으로 이동해야 손실이 줄어든다.

1.15 퍼셉트론 학습 규칙

시험에서 식이 제공될 가능성이 있는 핵심 갱신식이다.

틀린 샘플 집합을 I라고 하면,

wi ← wi + ρ Σ(x∈I) y xi

행렬 형태로는,

W ← W + ρ Σ(x∈I) yx

샘플 하나만 업데이트한다면,

w_new = w_old + ρ y x

주의
바이어스까지 포함하려면 x0 = 1을 포함한 벡터로 계산해야 한다.

1.16 세대 epoch

훈련 집합에 있는 샘플 전체를 한 번 처리하는 일을 세대 epoch라고 한다.

예:

훈련 데이터가 1000개이고, 1000개를 모두 한 번 학습에 사용했다면 1 epoch

1.17 신경망 학습 알고리즘의 반복 절차

신경망 학습은 다음 절차를 반복한다.

전방 계산 → 오차 계산 → 후방 가중치 갱신

• 전방 계산: 입력을 넣어 예측값을 계산
• 오차 계산: 예측값과 실제 레이블의 차이를 계산
• 후방 가중치 갱신: 오차를 줄이는 방향으로 가중치 수정

1.18 스토캐스틱 경사 하강법 SGD

SGD는 훈련 집합 전체를 한 번에 사용하지 않고, 일부 샘플 또는 미니 배치를 사용해 가중치를 갱신하는 방법이다.

• 배치 모드: 전체 데이터를 모아 한 번에 갱신
• 패턴 모드: 샘플 하나마다 갱신
• 미니 배치: 일정한 크기의 부분 집합마다 갱신

부분 집합을 만들 때 랜덤 샘플링을 적용하므로 스토캐스틱 경사 하강법이라고 부른다.

1.19 다층 퍼셉트론의 동작

다층 퍼셉트론은 입력층, 은닉층, 출력층으로 구성된다.

샘플 하나에 대한 기본 흐름은 다음과 같다.

입력 x → 은닉층 z → 출력 o

행렬식으로 단순화하면,

z = τ1(U1 x^T)
o = τ2(U2 z^T)

• U1: 입력층과 은닉층 사이의 가중치 행렬
• U2: 은닉층과 출력층 사이의 가중치 행렬
• τ1, τ2: 활성 함수

다층 퍼셉트론은 원래 특징 공간을 더 분류하기 쉬운 은닉 공간으로 변환한 뒤 최종 분류한다.

1.20 소프트맥스 함수

소프트맥스는 출력값을 확률처럼 해석할 수 있게 바꿔주는 함수이다.

ok = exp(sk) / Σ(i=1 to c) exp(si)

특징:

o1 + o2 + ... + oc = 1

출력값 중 가장 큰 값의 인덱스를 최종 예측 부류로 선택한다.

1.21 1980년대 깊은 신경망이 잘 학습되지 않은 이유

1980년대에도 깊은 신경망의 아이디어는 있었지만 학습이 잘 되지 않았다.

주요 이유는 다음과 같다.

1. 그레이디언트 소멸 문제
   층이 깊어질수록 기울기가 점점 작아져 앞쪽 층의 가중치가 거의 갱신되지 않는다.

2. 작은 데이터셋 문제
   추정해야 할 매개변수는 많은데 데이터가 적어 과잉 적합이 발생하기 쉽다.

3. 과다한 계산 시간
   당시에는 GPU 등 고속 연산 장치가 부족해 학습 시간이 너무 오래 걸렸다.

2. 예상 문제 및 해설

문제 1. 강한 인공지능과 약한 인공지능을 구분하시오.

다음 중 약한 인공지능에 해당하는 것을 모두 고르시오.

1. 알파고
2. 영화 속 인간처럼 사고하고 감정을 느끼는 인조인간
3. 음성인식 스피커
4. 특정 언어를 다른 언어로 번역하는 번역기

정답

1, 3, 4

해설

현재 대부분의 인공지능은 특정 기능에 특화되어 있으므로 약한 인공지능이다. 2번은 다양한 지능을 복합적으로 수행하는 강한 인공지능의 예이다.

문제 2. 1차 인공지능 겨울이 시작된 계기를 서술하시오.

모범 답안

1차 인공지능 겨울은 인공지능에 대한 과도한 기대에 비해 실제 성과가 부족했고, 라이트힐 보고서 등을 계기로 연구 지원이 줄어들면서 시작되었다. 또한 퍼셉트론의 한계가 지적되면서 신경망 연구도 퇴조하였다.

문제 3. 다음 포함 관계를 올바르게 배열하시오.

신경망, 인공지능, 딥러닝, 기계 학습

정답

인공지능 ⊃ 기계 학습 ⊃ 신경망 ⊃ 딥러닝

문제 4. 특징 벡터의 의미를 설명하시오.

모범 답안

특징 벡터는 하나의 샘플을 여러 개의 특징 값으로 표현한 벡터이다. 보통 x = (x1, x2, ..., xd)로 나타내며, d는 특징의 개수 또는 특징 벡터의 차원이다.

문제 5. 다음 두 점 사이의 유클리디언 거리를 구하시오.

x = (1, 2, 3)
y = (4, 6, 3)

풀이

d(x,y) = sqrt((1-4)^2 + (2-6)^2 + (3-3)^2)
       = sqrt(9 + 16 + 0)
       = 5

정답

5

문제 6. 다음 특징 중 원핫 코드로 표현하는 것이 가장 적절한 것을 고르시오.

1. 키
2. 몸무게
3. 혈액형
4. 시험 점수

정답

3. 혈액형

해설

혈액형은 A, B, O, AB 사이에 거리 개념이 없는 이름형 범주형 특징이므로 원핫 코드가 적절하다.

문제 7. 거짓 부정 FN이 무엇인지 설명하시오.

모범 답안

거짓 부정 FN은 실제로는 긍정인 샘플을 모델이 부정으로 예측한 경우이다. 예를 들어 실제 환자인데 정상인으로 판정한 경우가 FN이다.

문제 8. 다음 혼동 행렬에서 정확률, 특이도, 민감도를 구하시오.

TP = 40
FN = 10
FP = 50
TN = 900

풀이

정확률 = (TP + TN) / (TP + TN + FP + FN)
      = (40 + 900) / (40 + 900 + 50 + 10)
      = 940 / 1000
      = 0.94 = 94%

특이도 = TN / (TN + FP)
      = 900 / (900 + 50)
      = 900 / 950
      ≈ 0.947 = 94.7%

민감도 = TP / (TP + FN)
      = 40 / (40 + 10)
      = 40 / 50
      = 0.8 = 80%

정답

정확률 94%, 특이도 약 94.7%, 민감도 80%

문제 9. 정확률만으로 모델을 평가하면 안 되는 이유를 설명하시오.

모범 답안

정확률은 전체 샘플 중 맞힌 비율이므로 부류가 불균형할 때 성능을 제대로 반영하지 못한다. 예를 들어 정상인이 990명, 환자가 10명인 데이터에서 모든 샘플을 정상으로 예측하면 정확률은 99%이지만 환자를 한 명도 찾지 못하므로 민감도는 0이다. 따라서 정확률뿐 아니라 민감도, 특이도, 정밀도, 재현률 등을 함께 봐야 한다.

문제 10. 5-겹 교차 검증 결과가 다음과 같을 때 평균 정확률을 구하시오.

0.90, 0.95, 0.88, 0.92, 0.91

풀이

평균 = (0.90 + 0.95 + 0.88 + 0.92 + 0.91) / 5
     = 4.56 / 5
     = 0.912

정답

0.912, 즉 91.2%

문제 11. 교차 검증에서 정확률을 한 번만 구하지 않고 평균을 내는 이유를 서술하시오.

모범 답안

데이터를 한 번만 훈련/테스트로 나누면 우연히 쉬운 테스트 집합이 선택되어 정확률이 높게 나오거나, 반대로 어려운 테스트 집합이 선택되어 낮게 나올 수 있다. 교차 검증은 여러 분할에서 성능을 측정하고 평균을 내므로 우연의 영향을 줄이고 일반화 성능을 더 신뢰성 있게 추정할 수 있다.

문제 12. SVM에서 여백 margin의 의미를 설명하시오.

모범 답안

SVM에서 여백은 결정 경계와 두 부류 사이의 거리이며, 두 부류까지의 거리인 2s를 여백이라고 한다. SVM은 이 여백을 최대화하는 결정 경계를 찾아 일반화 능력을 높인다.

문제 13. SVM에서 x는 어떤 역할을 하는가?

모범 답안

x는 하나의 샘플을 나타내는 특징 벡터이다. SVM은 각 샘플 x를 특징 공간의 한 점으로 보고, 이 점들을 잘 분리하는 결정 경계를 찾는다.

문제 14. 다음 퍼셉트론의 출력을 구하시오.

x0 = 1, x1 = 0, x2 = 1
w0 = -0.5, w1 = 1, w2 = 1
τ(s) = +1 if s > 0, otherwise -1

풀이

s = w0x0 + w1x1 + w2x2
  = (-0.5)(1) + (1)(0) + (1)(1)
  = 0.5

s > 0이므로 출력은 +1이다.

정답

+1

문제 15. 다음 퍼셉트론은 OR 게이트인가, AND 게이트인가?

w0 = -0.5, w1 = 1, w2 = 1
s = -0.5 + x1 + x2

풀이

하나라도 1이면 +1이다.

정답

OR 게이트

문제 16. 다음 퍼셉트론은 OR 게이트인가, AND 게이트인가?

w0 = -1.5, w1 = 1, w2 = 1
s = -1.5 + x1 + x2

풀이

둘 다 1일 때만 +1이다.

정답

AND 게이트

문제 17. 경사 하강법의 기본 아이디어를 설명하시오.

모범 답안

경사 하강법은 손실 함수의 값을 줄이기 위해 현재 위치에서 기울기의 반대 방향으로 매개변수를 조금씩 이동시키는 방법이다. 학습률은 한 번에 얼마나 이동할지를 조절하는 하이퍼 매개변수이다.

문제 18. 퍼셉트론 학습 규칙을 이용해 가중치를 갱신하시오.

현재 가중치 w = (0, 0, 0)
학습률 ρ = 0.1
샘플 x = (1, 1, 0)   # x0 포함
레이블 y = +1

퍼셉트론 학습 규칙:

w_new = w_old + ρ y x

풀이

w_new = (0, 0, 0) + 0.1 × (+1) × (1, 1, 0)
      = (0.1, 0.1, 0)

정답

w_new = (0.1, 0.1, 0)

문제 19. 퍼셉트론 학습 규칙으로 여러 틀린 샘플을 한 번에 반영하시오.

현재 가중치 w = (0.2, -0.1, 0.3)
학습률 ρ = 0.5
틀린 샘플 집합 I:
  x(1) = (1, 1, 0), y(1) = +1
  x(2) = (1, 0, 1), y(2) = -1

공식:

w_new = w_old + ρ Σ yx

풀이

y(1)x(1) = (+1)(1, 1, 0) = (1, 1, 0)
y(2)x(2) = (-1)(1, 0, 1) = (-1, 0, -1)

Σ yx = (1, 1, 0) + (-1, 0, -1)
     = (0, 1, -1)

ρ Σ yx = 0.5 × (0, 1, -1)
       = (0, 0.5, -0.5)

w_new = (0.2, -0.1, 0.3) + (0, 0.5, -0.5)
      = (0.2, 0.4, -0.2)

정답

w_new = (0.2, 0.4, -0.2)

문제 20. epoch의 의미를 설명하시오.

모범 답안

epoch는 훈련 집합에 있는 전체 샘플을 한 번 처리하는 단위이다. 즉 모든 훈련 샘플을 한 번씩 학습에 사용하면 1 epoch가 끝난 것이다.

문제 21. 신경망 학습 알고리즘의 세 단계를 순서대로 쓰시오.

정답

전방 계산 → 오차 계산 → 후방 가중치 갱신

문제 22. 다음 설명에 해당하는 용어를 쓰시오.

훈련 집합 전체를 한 번에 사용하지 않고, 랜덤 샘플링으로 만든 부분 집합 또는 미니 배치를 이용하여 경사 하강법을 수행하는 방법이다.

정답

스토캐스틱 경사 하강법, SGD

문제 23. 다음 다층 퍼셉트론의 은닉층 출력을 구하시오.

계단 함수는 s > 0이면 1, 아니면 -1이라고 하자.

x = (1, 0, 1)^T     # bias 포함
U1 = [ [-0.5,  1,  1],
       [ 1.5, -1, -1] ]

풀이

U1 x = [ (-0.5)(1) + (1)(0) + (1)(1),
         (1.5)(1) + (-1)(0) + (-1)(1) ]

     = [ 0.5,
         0.5 ]

둘 다 0보다 크므로 계단 함수를 적용하면,

z = (1, 1)

정답

z = (1, 1)

문제 24. 다음 값에 소프트맥스를 적용했을 때 가장 높은 확률을 갖는 부류를 고르시오.

s = (1, 2, 0)

풀이

exp(1) ≈ 2.718
exp(2) ≈ 7.389
exp(0) = 1
합 = 11.107

softmax ≈ (2.718/11.107, 7.389/11.107, 1/11.107)
        ≈ (0.245, 0.665, 0.090)

정답

두 번째 부류

문제 25. 1980년대에 깊은 신경망이 이미 등장했지만 학습이 잘 안 된 이유를 서술하시오.

모범 답안

1980년대에도 다층 퍼셉트론에 은닉층을 많이 두면 깊은 신경망을 만들 수 있었지만, 학습이 잘 되지 않았다. 그 이유는 층이 깊어질수록 그레이디언트가 작아지는 그레이디언트 소멸 문제, 매개변수에 비해 데이터가 적어 발생하는 과잉 적합 문제, 그리고 당시 컴퓨터 성능 부족으로 인한 과다한 계산 시간 때문이었다.

3. 마지막 암기 체크리스트

시험 직전에 아래 문장을 빈칸 없이 말할 수 있으면 된다.

1. 약한 인공지능은 특정 기능에 특화된 인공지능이다.
2. 1차 인공지능 겨울은 라이트힐 보고서 등을 계기로 지원이 줄며 시작되었다.
3. 포함 관계는 인공지능 ⊃ 기계 학습 ⊃ 신경망 ⊃ 딥러닝이다.
4. 특징 벡터는 x=(x1,x2,...,xd)로 쓴다.
5. 이름형 범주형 특징은 원핫 코드로 표현하는 것이 적절하다.
6. 유클리디언 거리는 sqrt(Σ(xi-yi)^2)이다.
7. FN은 실제 긍정인데 예측을 부정으로 한 경우이다.
8. 정확률은 불균형 데이터에서 성능을 과대평가할 수 있다.
9. 5-겹 교차 검증은 5개의 성능을 평균내어 우연의 영향을 줄인다.
10. SVM은 여백 2s를 최대화하는 결정 경계를 찾는다.
11. 퍼셉트론은 s=Σwixi를 계산하고 계단 함수를 적용하는 이진 분류기이다.
12. OR 게이트는 w0=-0.5, w1=1, w2=1로 표현 가능하다.
13. AND 게이트는 w0=-1.5, w1=1, w2=1로 표현 가능하다.
14. 경사 하강법은 기울기의 반대 방향으로 이동한다.
15. 퍼셉트론 학습 규칙은 w_new = w_old + ρ y x이다.
16. epoch는 훈련 집합 전체를 한 번 처리하는 것이다.
17. 신경망 학습은 전방 계산 → 오차 계산 → 후방 가중치 갱신을 반복한다.
18. SGD는 랜덤 샘플링한 부분 집합으로 갱신하는 경사 하강법이다.
19. 소프트맥스 출력의 합은 1이다.
20. 1980년대 깊은 신경망은 그레이디언트 소멸, 작은 데이터셋, 계산 시간 문제로 학습이 어려웠다.

10분 내외로 맞추려면 이렇게 진행하면 좋아.

PPT 110장은 배포 전략과 실습 흐름을 시각적으로 이해시키는 역할이고, 1115장은 --record deprecated, Gateway API, Progressive Delivery 같은 추가 조사 내용으로 구성되어 있어.

녹화 전 준비 상태

영상 시작 전에 터미널은 YAML 파일이 있는 폴더에서 열어둬. 영상에서 굳이 cd 명령어를 보여주지 않아도 돼.

필요한 파일은 아래와 같아.

deployment-blue.yaml
deployment-green.yaml
nginx-service.yaml
deployment-stable.yaml
deployment-canary.yaml
nginx-service-canary.yaml
deployment-rolling-update.yaml

여기서 nginx-service-canary.yaml은 Canary 실습용 서비스 파일이야. Blue/Green 실습의 nginx-service.yaml은 처음에 version=blue를 바라보고, Canary 실습에서는 app=nginx만 바라보는 Service가 필요하므로 파일을 분리해두는 게 안전해.

최종 발표 대본 + 실습 명령어

슬라이드 1. 제목

대본

안녕하세요. 클라우드융합 개인 프로젝트 발표를 맡은 박시운입니다. 제가 맡은 주제는 Kubernetes Application Update이고, 세부적으로는 Blue/Green Update, Canary Update, Rolling Update 세 가지 배포 전략입니다.

이번 영상에서는 왼쪽에는 PPT를 띄워 각 배포 전략의 구조를 설명하고, 오른쪽 터미널에서는 실제 kubectl 명령어로 실습을 진행하겠습니다. 실습이 끝난 뒤에는 추가 조사 내용으로 최신 Kubernetes 운영 방식인 GitOps, Gateway API, Progressive Delivery까지 설명하겠습니다.

슬라이드 2. 배포 전략 비교

대본

2장에서는 세 가지 배포 전략을 비교합니다.

Blue/Green은 구버전과 신버전을 동시에 띄운 뒤 트래픽을 한 번에 전환하는 방식입니다. 자원은 많이 필요하지만 롤백이 빠릅니다.

Canary는 신버전을 일부 트래픽에만 먼저 배포해서 정상 동작을 검증하는 방식입니다. 위험을 빠르게 감지할 수 있습니다.

Rolling Update는 Pod를 하나씩 교체하면서 전체 시스템을 무중단으로 업데이트하는 방식입니다.

이제 이 세 가지 전략을 순서대로 실습하겠습니다.

1. Blue/Green Update 실습

슬라이드 3. Blue/Green Update 개념

대본

먼저 Blue/Green Update입니다.

Blue/Green Update는 구버전인 Blue와 신버전인 Green을 나란히 배포한 뒤, 트래픽을 한 번에 Green으로 전환하는 방식입니다.

장점은 롤백이 빠르다는 것입니다. Green 버전에 문제가 생기면 다시 Blue로 트래픽을 돌리면 됩니다.

단점은 Blue와 Green을 동시에 운영해야 하므로 전환 시점에 시스템 자원이 두 배 가까이 필요하다는 점입니다.

슬라이드 4. Service Selector 변경을 통한 트래픽 전환

대본

4장은 Kubernetes에서 Blue/Green 전환을 Service selector로 구현하는 구조입니다.

처음에는 nginx-svc 서비스가 version=blue인 Pod를 바라보게 하고, 이후 서비스의 selector를 version=green으로 바꾸면 트래픽이 Green Pod로 전환됩니다.

먼저 Blue와 Green Deployment, 그리고 nginx Service를 배포하겠습니다.

명령어

kubectl apply -f deployment-blue.yaml
kubectl apply -f deployment-green.yaml
kubectl apply -f nginx-service.yaml
kubectl get pod -o wide

대본

현재 Blue 버전과 Green 버전의 Pod가 모두 배포되었습니다. 다만 서비스는 아직 Blue 버전을 바라보도록 설정되어 있습니다.

이제 nginx-svc 서비스의 Endpoint를 확인하겠습니다.

명령어

kubectl describe svc nginx-svc

대본

출력 결과에서 Selector 부분을 보면 version=blue로 되어 있습니다.

Endpoints: 은 지금 실습 환경의 EndpointSlice 권한/버전 차이 때문에 표시되지않고 있습니다. 실제 Endpoint IP 변화는 kubectl get endpoints nginx-svc 명령으로 확인하겠습니다.

kubectl get endpoints nginx-svc
kubectl get pod -l app=nginx,version=blue -o wide

Endpoint에는 version=blue인 Pod의 IP가 연결되어 있습니다.

이제 실습 PDF와 동일하게 kubectl edit 명령어로 서비스 selector의 version 값을 blue에서 green으로 바꾸겠습니다.

명령어

kubectl edit svc nginx-svc

편집 방법

편집기가 열리면 아래 부분을 찾는다.

selector:
  app: nginx
  version: blue

이 부분을 아래처럼 바꾼다.

selector:
  app: nginx
  version: green

vi 편집기라면 i를 눌러 수정하고, 수정 후 Esc → :wq → Enter로 저장한다. nano 편집기라면 수정 후 Ctrl + O → Enter → Ctrl + X로 저장한다.

대본

서비스 selector를 version=green으로 수정했습니다. 이제 다시 nginx-svc를 확인해서 Endpoint가 Green Pod로 바뀌었는지 확인하겠습니다.

명령어

kubectl describe svc nginx-svc

kubectl get endpoints nginx-svc
kubectl get pod -l app=nginx,version=green -o wide

대본

이제 selector가 version=green으로 변경되었고, Endpoint도 Green Pod의 IP로 바뀐 것을 확인할 수 있습니다.

즉, 사용자는 동일한 nginx-svc 서비스로 접근하지만, 내부적으로는 Blue에서 Green으로 트래픽이 전환된 것입니다.

이것이 Blue/Green Update의 핵심입니다.

다음 실습을 위한 최소 정리 명령어

kubectl delete -f deployment-blue.yaml
kubectl delete -f deployment-green.yaml
kubectl delete -f nginx-service.yaml

짧은 설명

이 정리 명령어는 PDF에는 없지만, 한 영상에서 Canary 실습까지 이어서 진행하기 위해 필요합니다. Blue/Green Pod가 남아 있으면 Canary 실습의 Service가 기존 Pod까지 같이 바라볼 수 있기 때문입니다.

2. Canary Update 실습

슬라이드 5. Canary Update 개념

대본

다음은 Canary Update입니다.

Canary Update는 신버전을 전체 사용자에게 바로 배포하지 않고, 일부 서버나 일부 사용자에게만 먼저 배포해서 정상 동작을 확인한 뒤 전체로 확산하는 방식입니다.

이 방식은 장애가 발생하더라도 일부 트래픽에서만 문제가 나타나므로 위험을 빠르게 감지하고 피해 범위를 줄일 수 있습니다.

슬라이드 6. Canary 트래픽 분산과 Pod Scaling

대본

6장은 Canary에서 트래픽 분산과 Pod Scaling을 보여줍니다.

이번 실습에서는 Stable 버전 Pod 2개와 Canary 버전 Pod 1개를 먼저 배포합니다. 이후 Canary 버전이 정상 동작한다고 가정하고, Canary Pod를 2개로 늘리고 Stable Pod를 0개로 줄여 전체를 Canary 버전으로 전환하겠습니다.

먼저 Stable과 Canary Deployment를 배포하겠습니다.

명령어

kubectl apply -f deployment-stable.yaml
kubectl apply -f deployment-canary.yaml
kubectl apply -f nginx-service-canary.yaml
kubectl get pod && kubectl get svc
kubectl get deployment -o wide

대본

출력 결과를 보면 nginx-stable은 2개, nginx-canary는 1개가 실행 중입니다. 즉, Stable 버전 Pod 2개와 Canary 버전 Pod 1개가 배포된 상태입니다.

이제 서비스의 Endpoint를 확인하겠습니다.

명령어

kubectl describe service nginx-svc

대본

Service의 selector는 app=nginx이고, Endpoint에는 Stable Pod와 Canary Pod가 함께 포함되어 있습니다.

즉, 총 3개의 Pod 중 1개가 Canary이므로 대략 Stable 66%, Canary 33% 정도의 트래픽 분산을 기대할 수 있습니다.

이제 Canary 버전이 정상 동작한다고 가정하고 전체 업데이트를 진행하겠습니다.

명령어

kubectl scale deployment nginx-canary --replicas=2
kubectl scale deployment nginx-stable --replicas=0
kubectl get deployment -o wide
kubectl get pod -o wide

대본

이제 nginx-canary는 2개로 늘어났고, nginx-stable은 0개로 줄었습니다.

즉, 전체 트래픽이 Canary 버전으로 전환된 상태입니다.

이 방식은 Canary 배포의 기본 원리를 보여주기 좋지만, Pod 개수로 비율을 맞추는 방식이기 때문에 정확한 5%나 10% 같은 정밀한 트래픽 제어에는 한계가 있습니다. 이 한계는 뒤에서 Gateway API 설명과 연결됩니다.

다음 실습을 위한 최소 정리 명령어

kubectl delete -f deployment-stable.yaml
kubectl delete -f deployment-canary.yaml
kubectl delete -f nginx-service-canary.yaml

3. Rolling Update 실습

슬라이드 7. Rolling Update 개념

대본

다음은 Rolling Update입니다.

Rolling Update는 전체 시스템을 중단하지 않고 점진적으로 업데이트하는 방식입니다.

새 이미지의 컨테이너가 들어간 Pod를 하나 추가하고, 기존 이미지의 Pod를 하나 삭제하는 과정을 순차적으로 반복합니다.

이 방식은 자원 오버헤드를 최소화하면서 무중단 업데이트를 수행할 수 있기 때문에 Kubernetes Deployment에서 기본적으로 많이 사용됩니다.

슬라이드 8. 생성과 종료의 Cross Replacement

대본

8장은 Rolling Update 중 새 Pod 생성과 기존 Pod 종료가 교차로 일어나는 과정을 보여줍니다.

새 Pod가 ContainerCreating 상태가 되는 동시에 기존 Pod가 Terminating 상태가 됩니다. 이 교차 과정 덕분에 서비스가 중단되지 않고 업데이트될 수 있습니다.

먼저 Rolling Update용 Deployment를 배포하겠습니다.

명령어

kubectl apply -f deployment-rolling-update.yaml --record
kubectl get deployment nginx-rolling-update -o wide

대본

현재 nginx-rolling-update Deployment가 배포되었고, 이미지는 nginx:1.14입니다.

이제 이미지를 nginx:1.15로 변경하면서 Rolling Update를 수행하겠습니다.

실시간으로 Pod 생성과 종료를 보기 위해 터미널을 두 개 사용하겠습니다.

터미널 1 명령어

watch kubectl get pod

대본

터미널 1에서는 watch kubectl get pod 명령으로 Pod 상태를 실시간으로 확인합니다.

이제 터미널 2에서 이미지 업데이트 명령을 실행하겠습니다.

터미널 2 명령어

kubectl set image deployment nginx-rolling-update webpage=nginx:1.15 --record

대본

터미널 1을 보면 새 Pod가 ContainerCreating 상태로 생성되고, 기존 Pod가 Terminating 상태로 종료되는 것을 확인할 수 있습니다.

확인이 끝났으면 Ctrl + C로 watch 명령을 종료합니다.

이제 Rolling Update가 완료되었는지 확인하겠습니다.

명령어

kubectl rollout status deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wide

대본

출력 결과에서 이미지가 nginx:1.15로 변경되었고, Deployment가 정상적으로 rollout된 것을 확인할 수 있습니다.

슬라이드 9. Revision History와 Rollback

대본

9장은 Rolling Update의 revision history와 rollback을 보여줍니다.

kubectl rollout history 명령어로 업데이트 기록을 확인할 수 있고, kubectl rollout undo 명령어로 이전 버전 또는 특정 revision으로 되돌릴 수 있습니다.

먼저 rollback 실습을 위해 이미지를 1.16, 1.17, 1.18까지 순서대로 업데이트하겠습니다.

명령어

kubectl set image deployment nginx-rolling-update webpage=nginx:1.16 --record
kubectl rollout status deployment nginx-rolling-update

kubectl set image deployment nginx-rolling-update webpage=nginx:1.17 --record
kubectl rollout status deployment nginx-rolling-update

kubectl set image deployment nginx-rolling-update webpage=nginx:1.18 --record
kubectl rollout status deployment nginx-rolling-update

대본

이제 여러 번 이미지가 변경되었기 때문에 revision history가 생성되었습니다.

업데이트 기록을 확인하겠습니다.

명령어

kubectl rollout history deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wide

대본

현재 이미지는 nginx:1.18입니다.

이제 바로 전 업데이트 버전인 nginx:1.17로 rollback하겠습니다.

명령어

kubectl rollout undo deployment nginx-rolling-update

대본

kubectl rollout undo 명령은 기본적으로 바로 이전 revision으로 되돌립니다.

현재 이미지 버전을 다시 확인하겠습니다.

명령어

kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update

대본

현재 이미지가 nginx:1.17로 rollback된 것을 확인할 수 있습니다.

이번에는 특정 revision을 지정해서 nginx:1.15 버전으로 rollback하겠습니다. 실습 PDF에서는 revision 2가 nginx:1.15 버전에 해당합니다.

명령어

kubectl rollout undo deployment nginx-rolling-update --to-revision=2

대본

이제 특정 revision으로 rollback했습니다.

현재 이미지와 업데이트 기록을 다시 확인하겠습니다.

명령어

kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update

대본

현재 이미지가 nginx:1.15로 변경된 것을 확인할 수 있습니다.

이처럼 Rolling Update는 점진적으로 배포할 수 있을 뿐 아니라, revision history를 이용해서 원하는 과거 버전으로 안전하게 rollback할 수 있습니다.

슬라이드 10. 최적의 배포 전략

대본

10장은 지금까지 실습한 세 가지 배포 전략을 어떤 상황에서 선택할지 정리하는 슬라이드입니다.

클러스터 자원이 충분하고 빠른 롤백이 중요하다면 Blue/Green이 적합합니다.

실제 사용자 트래픽을 통해 신버전 안정성 검증이 필요하다면 Canary가 적합합니다.

자원 제약 속에서 표준적인 무중단 배포를 원한다면 Rolling Update가 적합합니다.

즉, 완벽한 단일 배포 전략은 없습니다. 인프라 자원, 트래픽 민감도, 롤백의 긴급성을 종합적으로 고려해서 시스템에 맞는 최적의 라우팅 전략을 설계하는 것이 중요합니다.

이제 실습은 마무리하고, 11장부터는 추가 조사 내용인 최신 Kubernetes 운영 방향을 설명하겠습니다.

4. 추가 조사 내용 설명

슬라이드 11. 최신화 방향

대본

11장부터는 추가 조사 내용입니다.

지금까지는 Blue/Green, Canary, Rolling Update라는 기본 배포 전략을 실습했습니다.

하지만 최신 Kubernetes 운영에서는 이 전략들이 단순한 수동 kubectl 명령어 수준을 넘어 GitOps, Gateway API, Progressive Delivery와 결합하는 방향으로 발전하고 있습니다.

즉, 앞의 실습은 배포 전략의 기본 원리를 보여주는 것이고, 11장 이후는 이 원리가 실무 환경에서 어떻게 더 자동화되고 정밀해지는지를 설명하는 부분입니다.

슬라이드 12. --record deprecated와 GitOps

대본

12장은 Rolling Update 실습에서 사용한 --record 옵션과 관련된 최신 이슈입니다.

실습에서는 PDF 흐름과 동일하게 kubectl set image ... --record 명령어를 사용했습니다. 이 옵션은 rollout history에서 변경 원인을 남기기 위해 사용됩니다.

하지만 Kubernetes v1.22 changelog에서는 kubectl --record 플래그가 deprecated 되었다고 명시되어 있습니다. 즉, 최신 운영에서는 이 방식이 더 이상 권장되는 중심 방식은 아닙니다. (GitHub)

그래서 최신 방식에서는 kubernetes.io/change-cause annotation을 직접 남기거나, 더 나아가 Argo CD나 Flux 같은 GitOps 도구를 사용해 Git commit history를 배포 이력의 기준으로 삼습니다.

예를 들면 이런 방식입니다.

kubectl annotate deployment/nginx-rolling-update \
  kubernetes.io/change-cause="nginx 이미지를 1.15로 업데이트" \
  --overwrite

즉, 과거에는 kubectl 명령어 자체가 이력 관리의 중심이었다면, 최신 운영에서는 Git commit, Pull Request, merge history가 배포 이력의 중심이 됩니다.

슬라이드 13. Ingress NGINX 은퇴와 Gateway API 전환

대본

13장은 Canary 배포에서 트래픽 비율을 제어하는 방식의 변화입니다.

앞에서 실습한 Canary는 Stable Pod 2개, Canary Pod 1개처럼 Pod 개수를 조절해서 트래픽 비율을 간접적으로 맞추는 방식이었습니다.

하지만 Pod 개수 기반 방식은 정확한 10%나 5% 같은 비율 제어가 어렵습니다.

기존에는 Ingress-NGINX에서도 annotation을 통해 Canary weight를 지정할 수 있었지만, 이것은 ingress-nginx 컨트롤러 전용 설정에 가까웠습니다.

Gateway API에서는 HTTPRoute의 backendRefs.weight를 사용해서 여러 backend 사이의 트래픽 비율을 지정할 수 있습니다. 공식 Gateway API 문서에서도 HTTPRoute weight는 rollout이나 canary 변경 중 backend 간 트래픽을 나누는 데 사용할 수 있다고 설명합니다. (Gateway API)

예시는 다음과 같습니다.

rules:
  backendRefs:
  - name: nginx-stable
    port: 80
    weight: 90
  - name: nginx-canary
    port: 80
    weight: 10

이렇게 하면 Stable 서비스에는 대부분의 트래픽을 보내고, Canary 서비스에는 일부 트래픽만 보낼 수 있습니다.

다만 weight는 정확히 “퍼센트 값” 자체는 아니고, 전체 weight 합계 대비 비율입니다. Gateway API 스펙에서도 weight는 weight / 전체 weight 합계로 계산된다고 설명합니다. (Gateway API)

즉, 기존 실습은 Pod 개수 기반 Canary이고, 최신 방식은 Gateway API의 weight 기반 라우팅으로 더 정밀하게 트래픽을 제어하는 방식입니다.

슬라이드 14. 메트릭 기반의 자동화된 롤아웃

대본

14장은 Progressive Delivery, 즉 메트릭 기반의 자동화된 롤아웃입니다.

앞의 실습에서는 사람이 직접 kubectl scale, kubectl set image, kubectl rollout undo 명령어를 실행했습니다.

하지만 실무에서는 이 과정을 자동화할 수 있습니다.

예를 들어 처음에는 Canary 버전에 트래픽을 5%만 보냅니다. 그 다음 Prometheus나 Datadog 같은 모니터링 도구로 에러율, 응답 지연 시간, 성공률 같은 메트릭을 확인합니다.

정상이라면 트래픽을 10%, 20%, 50%처럼 점진적으로 늘립니다. 반대로 문제가 발생하면 자동으로 rollback합니다.

이때 Prometheus는 트래픽을 직접 제어하는 도구가 아니라, 메트릭을 수집하고 제공하는 역할입니다. 실제 판단과 제어는 Argo Rollouts나 Flagger 같은 컨트롤러가 담당합니다.

Argo 공식 페이지에서도 Argo Rollouts는 Canary와 Blue-Green 같은 고급 Kubernetes 배포 전략을 쉽게 수행하기 위한 도구라고 설명합니다. (Argo Project)

즉, Progressive Delivery는 단순 배포가 아니라, 메트릭으로 안전성을 확인하면서 점진적으로 배포하는 방식입니다.

슬라이드 15. Progressive Delivery Architecture

대본

마지막 15장은 Progressive Delivery의 전체 아키텍처입니다.

흐름은 왼쪽에서 오른쪽으로 진행됩니다.

먼저 개발자가 코드를 수정하고 Git에 commit합니다. Argo CD는 Git 저장소의 manifest를 Kubernetes 클러스터와 동기화합니다.

그 다음 Argo Rollouts가 배포 전략을 관리합니다. Gateway API의 HTTPRoute는 Stable Pod와 Canary Pod 사이의 트래픽 비율을 담당합니다.

예를 들어 Stable Pod에는 90%의 트래픽을 보내고, Canary Pod에는 10%의 트래픽만 보냅니다.

그리고 Gateway 계층과 Pod에서 발생하는 요청 수, 에러율, 지연 시간 같은 메트릭은 Prometheus로 수집됩니다.

중요한 점은 Prometheus가 Gateway API를 직접 제어하지 않는다는 것입니다. Prometheus는 메트릭을 제공하고, Argo Rollouts나 Flagger가 이 메트릭을 기반으로 배포 성공 여부를 판단합니다.

정상이라면 Argo Rollouts가 Gateway API의 weight를 조정해 Canary 트래픽을 더 늘립니다. 문제가 발생하면 weight를 Stable 쪽으로 되돌려 자동 rollback합니다.

정리하면 흐름은 다음과 같습니다.

Git Commit
→ Argo CD
→ Argo Rollouts
→ Gateway API
→ Stable / Canary Pod
→ Prometheus 메트릭 수집
→ Argo Rollouts 판단
→ Gateway API weight 조정 또는 rollback

결론적으로 Blue/Green, Canary, Rolling은 배포 전략의 기본이고, 최신 Kubernetes 운영에서는 GitOps의 선언적 관리, Gateway API의 정밀한 라우팅, Prometheus 기반 관측성, Argo Rollouts 기반 자동화를 결합한 Progressive Delivery로 발전하고 있습니다.

최종 마무리 멘트

대본

지금까지 Kubernetes Application Update 주제로 Blue/Green, Canary, Rolling Update를 설명하고 실제 kubectl 명령어로 실습을 진행했습니다.

Blue/Green은 Service selector를 바꿔 트래픽을 빠르게 전환하는 방식입니다.

Canary는 일부 트래픽만 신버전에 보내 위험을 줄이는 방식입니다.

Rolling Update는 Pod를 순차적으로 교체하면서 무중단 업데이트를 수행하는 방식입니다.

그리고 추가 조사 내용으로, 최신 Kubernetes 운영에서는 GitOps 기반 이력 관리, Gateway API 기반 트래픽 weight 제어, Prometheus 메트릭 분석, Argo Rollouts 기반 자동 rollback을 결합한 Progressive Delivery로 발전하고 있다는 점을 확인했습니다.

이상으로 발표와 실습을 마치겠습니다.

최종 실습 명령어만 모은 버전

영상 중 복사해서 쓰기 편하게 명령어만 다시 모아두면 아래와 같아.

Blue/Green

kubectl apply -f deployment-blue.yaml
kubectl apply -f deployment-green.yaml
kubectl apply -f nginx-service.yaml
kubectl get pod -o wide

kubectl describe svc nginx-svc

kubectl edit svc nginx-svc

수정 내용:

selector:
  app: nginx
  version: green

kubectl describe svc nginx-svc

kubectl delete -f deployment-blue.yaml
kubectl delete -f deployment-green.yaml
kubectl delete -f nginx-service.yaml

Canary

kubectl apply -f deployment-stable.yaml
kubectl apply -f deployment-canary.yaml
kubectl apply -f nginx-service-canary.yaml
kubectl get pod && kubectl get svc
kubectl get deployment -o wide

kubectl describe service nginx-svc

kubectl scale deployment nginx-canary --replicas=2
kubectl scale deployment nginx-stable --replicas=0
kubectl get deployment -o wide
kubectl get pod -o wide

kubectl delete -f deployment-stable.yaml
kubectl delete -f deployment-canary.yaml
kubectl delete -f nginx-service-canary.yaml

Rolling Update

kubectl apply -f deployment-rolling-update.yaml --record
kubectl get deployment nginx-rolling-update -o wide

터미널 1:

watch kubectl get pod

터미널 2:

kubectl set image deployment nginx-rolling-update webpage=nginx:1.15 --record

확인:

kubectl rollout status deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wide

Revision 생성

kubectl set image deployment nginx-rolling-update webpage=nginx:1.16 --record
kubectl rollout status deployment nginx-rolling-update

kubectl set image deployment nginx-rolling-update webpage=nginx:1.17 --record
kubectl rollout status deployment nginx-rolling-update

kubectl set image deployment nginx-rolling-update webpage=nginx:1.18 --record
kubectl rollout status deployment nginx-rolling-update

Rollback

kubectl rollout history deployment nginx-rolling-update
kubectl get deployment nginx-rolling-update -o wide

kubectl rollout undo deployment nginx-rolling-update

kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update

kubectl rollout undo deployment nginx-rolling-update --to-revision=2

kubectl get deployment nginx-rolling-update -o wide
kubectl rollout history deployment nginx-rolling-update

이 버전이 발표용 최종본으로 쓰기 가장 깔끔해. PDF에 있는 핵심 명령어를 유지했고, get nodes, current-context, 시작 전 전체 삭제 같은 부가 명령어는 본편에서 제거했어.

• focus) agentic ai 기반 설계/해석 자동화
• dx: 가전사업부, mx: 모바일사업부 => +로봇연구또한 최근 하고 있음.
• 기획(DIA, PIA)->설계(DVR)->검증(PVR)-> 양산(PRA,SRA) 단계로 구성되어있음. 보통 해석단계가 설계+검증 단계임.
• TEARDOWN: 해당 키워드를 통해 관련 하드웨어를 분해한 모습을 확인가능함.
• MX 사업부는 본질적으로 FR(무선통신) 사업부임. (다른 국가로의 망 호환성이나 외부로 부터의 영향을 최소화...)
• SI(잘닦인 트랙), PI(단단한 노면), EMI(날씨에 흔들리지 않게) => 신호 무결성을 보장
• 공정 단계에서 예기치못한 변수를 제어하기 위해 공정의 균일도에 대한 시뮬레이션을 먼저 돌려, 공정의 오차율을 감소
• 사람이 반복적으로 하는 일에 대해 AI agent가 대체될 수 있도록 해당 부문에 포커스되고 있음
• 공통적으로 중시하는 것) 학부의 기본기 + ai 를 활용하는 것 -> 프롬프트/ 컨텍스트 설계/ 결과 검증까지가 활용력이다. 이러한 반복되는 일들을 발견하고, 스크립트->파이프라인->에이전트로 확장하는 사고 방식이 업무 자동화 사고이다. -
• 빠른 의사소통을 위해 영어는 필수적이다. 다다익선
• ai 같은 경우 생산성을 위해 보안문제로 금지가 되었던 ds 사업부까지 허용을 검토하여 올해 느슨(?)해져서 사용을 권장하고 있음. (올해 6월 예정) 하지만 여전히 사업관련 기밀은 ai 사용이 금지되고 있음. 본인이 agent를 만들어 사용해도 괜찮음.
• 보통 대학원을 회사에서 보내주는 사람들은 상위 고과자임. ( 입사하고 나서도 열심히 해야겐네....)

최호익, ds 부문/경영진단팀 일하는 방식의 변화에 대하여 연사님

• sait(한국기술연구센터): ai 센터 -> 삼성전자: 경영진단팀
• 메모리사업부: hbm가 수익을 굉장히 많이 내는 줄 알지만, 현재까진 ddr5 같은 레거시 메모리가 잘 팔려서 요즘 핫한거임
• 파운드리사업부: 해당 사업부가 정말 기술적인 부서임.
• s.lsi
• 기업이 ai 를 본격적으로 도입하고 업무가 변경되었을때 내가 본질적으로 할 수 있는건 무엇일까? 라는 고민을 해봐야함.

우린 이전 포스팅에서 OpenStackClient 개발 환경 세팅 openstack server list 명령어를 통해 인스턴스들을 확인해 보았습니다

미션 1

openstack server list 결과에 user name과 project name 이라는 컬럼을 기본 출력에 추가하고, 그 값을 출력하도록 만들어주세요

미션 2

미션 1에서 컬럼을 추가하면, 실패하는 테스트 케이스가 다수 발생합니다. 모든 테스트 케이스가 통과하도록, 테스트 케이스 자체를 수정해주세요

조건) 새로 추가한 컬럼이 기본 값인 상태입니다. 이 컬럼이 기본인 조건을 만들고 테스트 케이스를 수정해야합니다

① 어느 부분을 수정해야 할까?

server list 라는 명령어를 처리하는 python-openstackclient/openstackclient/compute/v2/server.py 부분을 살펴보겠습니다 이 함수가 칼럼에 관여하는 친구인거 같다 column_headers 투성이 server.py 파일

            columns = (
                'ID',
                'Name',
                'Status',
                'Networks',
                'Image Name',
                'Flavor Name',
            )
        column_headers = (
            'ID',
            'Name',
            'Status',
            'Networks',
            'Image',
            'Flavor',
        )

이런식으로 담겨있을 줄 알았으나,,,

             columns: tuple[str, ...] = (
                'id',
                    'name',
                'status',
            )
        column_headers: tuple[str, ...] = (
            'ID',
            'Name',
            'Status',
        )

어림도 없지 암 이렇게 되어있어서 봤더니

        if sdk_utils.supports_microversion(compute_client, '2.47'):
            columns += ('flavor_name',)
            column_headers += ('Flavor',)
        else:
            if parsed_args.long:
                columns += (
                    'flavor_name',
                    'flavor_id',
                )
                column_headers += (
                    'Flavor Name',
                    'Flavor ID',
                )
            else:
                if parsed_args.no_name_lookup:
                    columns += ('flavor_id',)
                else:
                    columns += ('flavor_name',)
                column_headers += ('Flavor',)

        #새로 추가한 부분
        columns += (
            'project_name',
            'user_name',
        )
        column_headers += (
            'Project Name',
            'User Name',
        )

명령어에 따라 동적으로 추가시키려고 코드가 이런식으로 작성되어있었다. project_name이나 user_name 같은 경우 조건 기반 동적 구성할 필요는 없어서 이렇게 코드를 추가해줬습니다

이제 ListServer의 기본 columns에 project_name과 user_name을 추가했고, server list의 기본 출력 순서가 기존 ID, Name, Status, Networks, Image, Flavor에서 ID, Name, Status, Networks, Image, Flavor, Project Name, User Name으로 바뀝니다.

+) 추가적으로

if parsed_args.columns:
            for c in parsed_args.columns:
                if c in ('Project ID', 'project_id'):
                    columns += ('project_id',)
                    column_headers += ('Project ID',)
                if c in ('User ID', 'user_id'):
                    columns += ('user_id',)
                    column_headers += ('User ID',)
                    ...
                #새로 추가한 부분
                if c in ('Project Name', 'project_name'):
                    columns += ('project_name',)
                    column_headers += ('Project Name',)
                if c in ('User Name', 'user_name'):
                    columns += ('user_name',)
                    column_headers += ('User Name',)

같은 파일에 컬럼 옵션 처리가 되어 있는 코드가 보이는데, Project Name과 User Name을 넣어서, -c 옵션으로도 선택 가능하게 했습니다.

② 반환 되는 것들을 확인해보자

보다시피 새로 추가한 칼럼인 유저 네임과 프로젝트 네임이 굉장히 러프(?)하다 여기서 필요하다고 느끼는건 저 값을 받아서 대조하여 출력값을 채워줄 무언가가 필요하다.

즉, OpenStack의 기본 서버 응답에는 user_id, project_id만 포함되어 있으며, 실제 사람이 읽을 수 있는 이름(name)은 별도의 Identity 서비스 조회를 통해 가져와야 한다.

project_names = {}
        user_names = {}
        if data:
            for project_id in {
                s.project_id for s in data if getattr(s, 'project_id', None)
            }:
                try:
                    project_names[project_id] = identity_common.find_project(
                        identity_client,
                        project_id,
                    ).name
                except Exception:  # noqa: S110
                    # retrieving project names is not crucial, so we swallow
                    # any exceptions
                    pass

            for user_id in {
                s.user_id for s in data if getattr(s, 'user_id', None)
            }:
                try:
                    user_names[user_id] = identity_common.find_user(
                        identity_client,
                        user_id,
                    ).name
                except Exception:  # noqa: S110
                    # retrieving user names is not crucial, so we swallow any
                    # exceptions
                    pass

출력 값 채우는 로직에서는 각 서버의 project_id와 user_id를 모아 identity_common.find_project와 identity_common.find_user로 이름을 조회한 뒤, server 객체의 project_name과 user_name에 넣도록 구현하였다. 이미지와 플레버 이름 조회 흐름은 그대로 유지했고, 새 컬럼만 추가로 계산하는 구조이다

+) 근데 이게 정말 최선일까? 분명 기존 코드에 데이터를 가져오는 로직이 있을것이다.

"서버 단위 데이터 처리 흐름을 통합하여 응집도를 높이고, 조건 기반 로직과 캐싱을 자연스럽게 적용하기 위한 구조 개선을 하고싶다..." 라는 생각이 들때쯤

 # Populate image_name, image_id, flavor_name and flavor_id attributes
        # of server objects so that we can display those columns.
        project_names = {}
        user_names = {}
        for s in data:
            if sdk_utils.supports_microversion(compute_client, '2.69'):
                if getattr(s, 'status') == 'UNKNOWN':
                    continue

            if 'id' in s.image and s.image.id is not None:
                image = images.get(s.image['id'])
                if image:
                    s.image_name = image.name
                s.image_id = s.image['id']
            else:            
                s.image_name = IMAGE_STRING_FOR_BFV
                s.image_id = IMAGE_STRING_FOR_BFV
            ## 해당 for문 내부에 코드를 구현했다
            project_id = getattr(s, 'project_id', None)
            if project_id and project_id not in project_names:
                try:
                    project_names[project_id] = identity_common.find_project(
                        identity_client,
                        project_id,
                    ).name
                except Exception:  # noqa: S110
                    pass
            s.project_name = project_names.get(project_id)

            user_id = getattr(s, 'user_id', None)
            if user_id and user_id not in user_names:
                try:
                    user_names[user_id] = identity_common.find_user(
                        identity_client,
                        user_id,
                    ).name
                except Exception:  # noqa: S110
                    pass
            s.user_name = user_names.get(user_id)

합치려고 보니 서버마다 find_project와 find_user를 매번 호출하면? -> 오히려 중복 조회가 늘어나지 않을까...?

그래서 루프를 합치되 ID별 캐시는 유지하는 방향으로 개선을 시도 즉, 지금의 딕셔너리 캐시 방식은 유지하고, 그 캐시 채우기와 서버 객체 값 세팅을 같은 for s in data: 안에서 처리하는 쪽이 균형이 좋을 거 같아 구조화를 해보았다

사실 실제로 기여하는 사람들 입장에선 저 밈 수준으로 매우 간단한 작업이고 당연한 수순일 순 있다. 하지만 난 오픈소스 기여 호소인이므로 자세하게 설명할거다.

정리) 단도직입적으로 남들이 "그래서 그냥 비슷한 기능의 for문 찾아서 내부에 포함시켰다는 거냐?"라고 질문한다면 무시하지말고 이렇게 답변하면 된다

첫번째 구현 방식: 캐시를 먼저 만들고, 나중에 한 번 더 서버를 순회 개선한 방식: 한 번의 서버 순회 안에서 캐시 조회/갱신과 s.project_name, s.user_name 세팅을 같이 수행

해당 포스팅은 1주차 과제였던 "개발환경에서 openstack server list 명령어 실행 결과 확인" 을 기반으로 내부적으로 코드가 어떻게 흐르는지 파악하는 것입니다

방향 설정: nova 의 정보를 어느시점에서 가져오고 렌더링할 서버 정보를 가져오는 건 take_action 의 어느 시점인지를 중점으로 분석

[작은 강의] 이런 오픈소스코드 분석은 어떻게 하면 좋은가?

openstack --debug server list

해당 로그들 속에서

greb -R "{궁금한 문자열}"

만약 검색이 안된다면 가상환경에 설치된 라이브러리들이 호출을 통해 문자열을 출력하고 있는것

가상환경으로 들어가서 greb -R "{궁금한 문자열}"

호출이 되고 있는 경로를 찾았다면,

해당 경로 파일을 열어서 hook, 함수 등 종속적으로 호출하고 있는 것을 확인

만약, 속한 class 를 확인 하였다면 해당 클래스 검색 -> 호출하고 있는 것들 중 진짜 내가 찾는 것과 관련된 것들 걸러내기

=> 단편적인 요소를 찾고 상향식으로 분석

추천) https://wikidocs.net/230415 traceback를 사용하면 좀 더 수월하게 확인이 가능

주요 라이브러리

• OSC_lib ( 다른 lib, cli, sdl)
• stevedore ( 동적 louder )( csl 에서 사용하기 위한 것들을 동적으로 불러와 사용하기 위한 것들 )
• keystoneouth ( 인증 관련)

-> stevedore, keystoneouth 에 빠지면 return 값 정도만 확인하고 빠져나오세요

OpenStack CLI 클라이언트(python-openstackclient)를 로컬에서 직접 개발하고 디버깅하기 위한 VSCode 환경 구축 방법 (+근데 윈도우 환경을 곁들인...)

이 게시물을 읽고 계신다면, 분명 주위에서 파이참을 사용하라고 권유했을거고 당신의 윈도우 환경에 안타까움을 표했을겁니다...

그럼에도 불구하고 꿋꿋하게 환경세팅을 하려고 제 게시물을 읽고 있는 당신에게 경의를 표하며... 지금이라도 주변의 말을 들으세요

_참고) 본격적인 포스팅에 앞서 윈도우 명령어 앞엔 🪟으로 기입하겠습니다_

[환경세팅을 하기에 앞서, 간략한 사전 지식 및 전체 흐름]

1. 클라우드 컴퓨팅은 원격지의 리소스를 API 호출을 통해 제어합니다. 사용자는 웹 대시보드(GUI)를 사용할 수도 있지만, 개발 생산성과 자동화를 위해 CLI(Command Line Interface) 도구인 python-openstackclient를 사용

-> 마치 쿠버네티스의 kubectl과 비슷한 역할이랄까

2. 해당 프로젝트는 파이썬을 사용합니다. 그러므로 의존성 문제를 예방하기 위해 가상환경을 사용합니다 -> 시스템 전역에 패키지 설정하면^^..... 버전 충돌쇼

-> 정리하자면 가상환경(내방) > 라이브러리 모음집 설치 > 구동

① 소스코드 clone

자신의 작업 디렉토리에 python-openstackclient 코드를 clone 받습니다. git clone https://opendev.org/openstack/python-openstackclient

② clouds.yaml 생성

python-openstackclient를 clone 받은 위치에 아래 내용으로 clouds.yaml 파일을 생성합니다.

clouds:
  my-cloud:
    auth:
      auth_url: http://<ip>/identity
      username: "admin" # 할당 받은 값 넣으세요
      password: "1234" # 할당 받은 값 넣으세요
      project_name: "admin" # 할당 받은 값 넣으세요
      user_domain_name: "Default"
      project_domain_name: "Default"
    region_name: "RegionOne"
    interface: "public"
    identity_api_version: "3"

③ Visual Studio Code에서 python-openstackclient 폴더 열기

visual studio code를 이용할 경우, IDE로서의 기능보다 코드를 분석하고 수정하는 용도로 주로 활용하게 됩니다. 따라서, openstackclient 실행과 로그 분석은 터미널에서 합니다. code내에서 터미널을 열고 작업을 이어갑니다.

vscode 자체를 관리자 권한으로 설치하면 git bash도 관리자 권한으로 내부에서 사용가능하다고 Reddit에 토론기록이 남아있긴한데, 그 누구도 성공적인 시도였다는 후기가 없다 옆에 git bash 관리자 권한으로 열어서 작업하는 걸 추천 드립니다

④ virtualenv 생성 (가상 환경 만들고 만든 환경에 들어가기)

python3 -> python: 윈도우 환경에서는 python 명령어가 3.x 버전을 가리키는 기본 실행 파일명이므로 교체

.venv/bin/activate -> .venv/Scripts/activate: 윈도우 파이썬 가상 환경은 실행 파일(Script)을 bin이 아닌 Scripts 디렉토리에 저장

아래 명령어로 virtualenv를 생성합니다. python3 -m venv .venv 🪟python -m venv .venv 그리고 virtualenv 를 활성화합니다. source .venv/bin/activate 🪟source .venv/Scripts/activate -> ex) 이게 가상환경(내 방) 가는 길인거다 정상적으로 활성화되었다면 다음과 같이 터미널에 표시됩니다.

⑤ python-openstackclient 의 의존 라이브러리 설치하기

pip3->pip: 리눅스와 달리 윈도우 가상 환경(.venv/Scripts)에는 pip3.exe 파일이 생성되지 않는 경우가 많습니다.

이제 의존 라이브러리를 설치합니다. 아래 명령어로 의존 라이브러리를 설치합니다. pip3 install -r requirements.txt -> 실행용 🪟pip install -r requirements.txt pip3 install -r test-requirements.txt -> 테스트나 코드 품질 검사용 🪟pip install -r test-requirements.txt

⑥ python-openstackclient를 develop 모드로 설치하기

이제 virtualenv 에 python-openstackclient 자체를 설치합니다. 일반적으로 파이썬 코드를 받아 설치할 때는 python setup.py install을 이용하지만, 개발을 위해서는 아래 명령어로 develop 모드로 설치해아 합니다. python3 setup.py develop 🪟python setup.py develop

⑦ openstack server list 실행해보기

python-openstackclient의 main 함수는 openstackclient/shell.py 에 있습니다. 하지만 PyCharm 과 다르게 우리는 openstackclient를 virtualenv에 설치했으므로 openstack 명령어를 그대로 사용해도 됩니다. 아래 명령어로 결과를 확인해봅니다. openstack server list --os-cloud my-cloud 이 때 인스턴스 이름은 test_instance_계정명 으로 된 것이 나와야합니다. 여기까지 되었다면 openstackclient 코드를 개발할 준비가 완료되었습니다.

• routes.tsx

import { createBrowserRouter } from "react-router";
import Home from "@pages/Home";
import Page1 from "@pages/Page1";
import Page2 from "@pages/Page2";

const router = createBrowserRouter([
  { path: '/home', element: <Home /> },
  { path: '/page1', element: <Page1 /> }, 
  { path: '/page2', element: <Page2 /> },
]);

export default router;

• App.tsx

import { RouterProvider } from 'react-router';
import router from './routes';

function App() {
  return (
    <>
      <RouterProvider router={ router } />
    </>
  );
}

export default App;

• Header.tsx

  import { Link } from "react-router";
  

function Header() { return (

export default Header;

![](https://velog.velcdn.com/images/bab_shunn/post/160998d1-9775-4b6b-8c59-bbbbf77f6e8f/image.png)
![](https://velog.velcdn.com/images/bab_shunn/post/398acf05-e81c-4194-bd5c-b2dc16e000f4/image.png)
![](https://velog.velcdn.com/images/bab_shunn/post/15d64cc6-dc16-4caa-9f44-a6f88d6fa749/image.png)

물론이야. 아래는 fetch 직접 사용과 useFetch 커스텀 훅을 비교 정리한 velog용 글 형식의 간단한 개념 정리야:

fetch 직접 사용 vs 커스텀 훅(useFetch) 사용 비교

1. fetch 직접 사용

개요

React 컴포넌트 내부에서 fetch() 함수를 직접 호출하여 데이터를 요청하고, useState, useEffect 등을 통해 상태를 관리하는 방식.

장점

• 코드 흐름이 직관적이고 이해하기 쉬움
• API 요청마다 다른 로직을 유연하게 작성 가능

단점

• 여러 컴포넌트에서 동일한 요청을 구현할 경우 코드 중복이 많아짐
• 로딩, 에러, 데이터 상태 등을 매번 직접 관리해야 함
• UI와 비즈니스 로직이 섞여 코드가 복잡해질 수 있음

2. useFetch 커스텀 훅 사용

개요

API 요청 및 관련 상태 관리(loading, error, data)를 커스텀 훅으로 분리하여 관리하는 방식. 주로 재사용성과 관심사 분리를 위해 사용함.

장점

• 로직 재사용이 가능하여 코드 중복 최소화
• 로딩, 에러 처리 등의 상태 관리가 일관됨
• 컴포넌트는 UI에만 집중할 수 있어 코드 구조가 깔끔해짐
• 유지보수가 쉬움 (훅 하나만 수정하면 됨)

단점

• 초기에 구조를 이해하고 설정하는 데 시간이 필요함
• 훅 내부를 커스터마이징하려면 추가 작업이 필요할 수 있음
• 단순한 요청에도 훅 사용이 과할 수 있음

결론

• 작은 프로젝트나 간단한 요청에는 fetch 직접 사용이 편리
• 여러 컴포넌트에서 같은 API를 호출하거나 상태 관리가 필요한 경우에는 useFetch 커스텀 훅을 사용하는 것이 효율적

3) useReducer

useState와 역할은 비슷한데, useState가 제공하는 기능 이외에도 상태 업데이트 로직을 외부 함수로 분리할 수 있는 기능을 제공한다.

useState와 useReducer의 차이는 위 그림과 같다. 상태를 관리한다는 목적은 동일한데 상태를 업데이트하는 방법이 약간 다르다. useReducer는 미리 정의된 reducer 함수에 action과 이전 상태값을 입력값으로 넣어서 새로운 상태를 계산한다는 차이점이다.

4) useRef

useRef는 특정 DOM에 접근하여 DOM 조작을 가능하게 하는 훅이다. 리액트 프로젝트에서도 특정 요소를 선택해야하는 상황이 생길 수 있는데 이러한 상황에서 useRef 함수를 사용할 수 있게 된다.

가장 큰 특징은 useRef는 따로 상태 변경 함수가 없고 직접 .current의 상태를 변경하기 때문에 변경 사항이 자동으로 브라우저 화면에 반영되지 않는다는 점이다.

하지만 컴포넌트 지역 변수와 다르게 useRef 상태는 컴포넌트가 언마운트될 때까지 유지되기 때문에, 여러 이유로 인해 해당 컴포넌트 render 함수가 실행되면 useRef 변경 사항이 화면에 반영될 수 있다.

{/* 변경 사항이 자동으로 화면에 반영된다. */}
<button onClick={() => setCount((prev) => prev + 1)}>
  useState 상태 업데이트
</button>

{/* 변경 사항이 자동으로 화면에 반영되지 않는다. 상태는 유지된다. */}
<button onClick={() => reference.current++}>
  useRef 상태 업데이트
</button>

그래서 useRef는 주로 자동으로 화면을 렌더링하지 않아도 되는 상태를 관리할 때 사용한다. 화면 렌더링과 관련이 없는 상태를 useState로 관리하면 render 함수가 불필요하게 실행되기 때문이다.

참고:

• React Hooks 이해하기 (2)
• Hook의 개요
• JDevelog:티스토리

리액트 훅

• 1. 웹 개발의 변천사
• 2. 리액트 개발에 자주 사용하는 자바스크립트 문법

• 간단한 todoList 실습 (dom 객체를 다루는데에 좀 더 익숙해지기 위한)

• 간단한 counter 실습 (dom 객체를 다루는 코드는 js 파일에서 관리하고 해당 코드를 함수로 만들어 html 파일에서 dom조작을 함수를 통해 더 간결한 코드를 작성합니다. 마지막엔 코드를 하나의 함수로 만들고, 좀 더 유연한 사용을 위해 컴포넌트로 쪼개어 사용할 수 있는 것들을 함수로 만들어 최종적으로 rootNode에 추가합니다.)

+)사진이 깨져서 pdf로도 저장했는데 벨로그는 pdf가 안올라가네요...? 호호,,

• const haru2 = haru; → 얕은 복사(X) → 참조 복사
• const haru3 = Object.assign({}, haru); 또는 { ...haru } → 얕은 복사(O)

  JavaScript 자체 내장 메서드로는 진정한 깊은 복사(deep copy)는 제공되지 않음! (라이브러리를 사용하거나 로데쉬..., json을 통해 부분적으로 구현 가능하긴함

haru2 = haru;

• 같은 객체를 가리키는 참조 복사
• 그래서 haru.age++ 하면 haru2.age도 같이 바뀝니다.

  const haru2 = haru;
  haru.age++; // haru2.age도 같이 증가함

Object.assign({}, haru) 또는 { ...haru }

• 얕은 복사(shallow copy)
• )
• haru 객체의 최상위 속성만 새 객체로 복사
• 중첩 객체가 있다면 그 안은 참조로 복사

예시:

const haru = { name: '하루', age: 5, pet: { type: 'dog' } };
const copy = { ...haru };
copy.pet.type = 'cat';
console.log(haru.pet.type); // 'cat' (내부 객체는 공유됨)

정리하면:

unknown type

TypeScript 3.0 부터 새로 추가된 타입 문자 그대로 알려지지 않은 타입 이다. unknown 타입으로 선언된 변수의 값으로는 모든 타입이 올 수 있다. (any타입과 비슷) 그렇다면 unknown 과 any 의 차이점은 무엇일까?

unknown 과 any의 차이

unknown에는 메서드를 호출할 수 없다.

어떤 타입인지 확실하지 않기 때문에 타입스크립트는 어떠한 연산이든 실행하지 않는다.

let userInput: unknown;
console.log(userInput.length); // ❌ 에러

unknown 타입을 가진 변수는 any를 제외하고 다른 타입을 가진 변수에 할당할 수 없다. 다시 말해, 고정된 타입을 가지고 있는 변수에 unknown 타입을 가진 변수를 할당할 수 없다.

let userInput: unknown;
let userName: string;

userInput = 5; // ⭕️ 작동
userInput = 'Harry'; // ⭕️ 작동
userName = userInput; // ❌ 에러

unknown 타입을 가진 변수를 다른 변수에 할당하기 위해서는 타입 체크를 해주면 된다.

let userInput: unknown;
let userName: string;

userInput = 5;
userInput = 'Harry';
if (typeof userInput === 'string') { 
  userName = userInput; // ⭕️ 작동
}

unknown 타입을 쓰는 이유

변수의 값으로 어떤 타입이 올지 미정인 상태에서 any를 쓴다면 타입스크립트를 사용하는 이유가 없다.(typescipt: 그럴거면 js로 돌아가.)

이럴 때 any 보다 깐깐한(?) unknown 타입을 사용하는 것이 좋다. (타입 선언 이후 조건문 등으로 타입 체크 코드 작성하면 unknown 타입을 잘 사용할 수 있다!)

요구사항

문서내의 모든 버튼을 클릭했을때, 각각 "btn-0 클릭", "btn-1 클릭", "btn-2 클릭" ... "btn-n 클릭"을 콘솔에 출력하시오.

<script>
      window.onload = function () {
        const btns = document.querySelectorAll("button");
        // IIFE pattern
        for (var i = 0; i < btns.length; i++) {
          btns[i].addEventListener("click", function () {
            console.log(`btn-${num}클릭`);
          });
        }
      };
    </script>

위의 그림에서 알수 있듯이 var을 사용하면 원하는 결과를 얻을 수 없다.

왜 그런걸까?

1. i = 0일 때, function() { console.log(i); } 함수를 배열에 저장.

2. i = 1일 때도 또 함수 저장.

3. i = 2일 때도 또 함수 저장.

그래서 funcs에는 함수가 3개 저장:

[
  function() { console.log(i); },
  function() { console.log(i); },
  function() { console.log(i); }
]

이 세 함수는 모두 같은 i를 바라보고 있다! (어매나)

현재 위 코드에서 i는 모든 함수들이 같이 보는 공용 메모장 같은 것 반복문은 메모장에 숫자 적으면서 함수들을 저장해두는 거고, 함수들은 "나중에 저 메모장에 적힌 거 보고 출력할게!" 라고 약속해놓은 상황. 근데 반복문이 끝나고 나면, 메모장에는 3만 써 있음. (var라는 놈이 이래서 문제다,,) 그래서 함수들이 실행될 때마다 3만 출력

<script>
      window.onload = function () {
        // 문서내의 모든 버튼을 클릭했을때
        // 각각 "btn-0 클릭", "btn-1 클릭", "btn-2 클릭"
        // ... "btn-n 클릭"을 콘솔에 출력하시오.
        const btns = document.querySelectorAll("button");
        // IIFE pattern
        for (var i = 0; i < btns.length; i++) {
          ((num) => {
            btns[i].addEventListener("click", function () {
              console.log(`btn-${num}클릭`);
            });
          })(i);
        }
      };
    </script>

이런 방식으로 해결할 수 있다.

하지만 지금은 2025년.

ECMA6의 시대.

우리는 let과 forEach를 사용함으로써 이를 해결할 수 있다.

    // ECMA5 forEach
    // Array.prototype.forEach: 배열의 각 요소를 순회하면서 지정한 콜백 함수를 실행
    // 콜백 함수는 첫번째 인자로 배열의 요소, 두번째 인자로 요소의 인덱스를 전달받는다.
    // [btn1, btn2, btn3].forEach((btn, i) => { });
    btns.forEach(function(btn, i){
      btn.addEventListener('click', function(){
        console.log(`btn-${i} 클릭`);
      });
    });

    // ECMA6 let
    for(let i=0; i<btns.length; i++){
      btns[i].addEventListener('click', function(){
        console.log(`btn-${i} 클릭`);
      });
        }

이벤트(event)는 어떤 사건을 의미한다. 브라우저에서의 이벤트란 예를 들어 사용자가 버튼을 클릭했을 때, 웹페이지가 로드되었을 때와 같은 것인데 이것은 DOM 요소와 관련이 있다.

이벤트가 발생하는 시점이나 순서를 사전에 인지할 수 없으므로 일반적인 제어 흐름과는 다른 접근 방식이 필요하다. 즉, 이벤트가 발생하면 누군가 이를 감지할 수 있어야 하며 그에 대응하는 처리를 호출해 주어야 한다.

브라우저는 이벤트를 감지할 수 있으며 이벤트 발생 시에는 통지해 준다. 이 과정을 통해 사용자와 웹페이지는 상호작용(Interaction)이 가능하게 된다.

<!DOCTYPE html>
<html>
<body>
  <button class="myButton">Click me!</button>
  <script>
    document.querySelector('.myButton').addEventListener('click', function () {
      alert('Clicked!');
    });
  </script>
</body>
</html>

이벤트가 발생하면 그에 맞는 반응을 하여야 한다. 이를 위해 이벤트는 일반적으로 함수에 연결되며 그 함수는 이벤트가 발생하기 전에는 실행되지 않다가 이벤트가 발생되면 실행된다. 이 함수를 이벤트 핸들러라 하며 이벤트에 대응하는 처리를 기술한다.

2. 이벤트 루프(Event Loop)와 동시성(Concurrency)

브라우저는 단일 쓰레드(single-thread)에서 이벤트 드리븐(event-driven) 방식으로 동작한다.

단일 쓰레드는 쓰레드가 하나뿐이라는 의미이며 이말은 곧 하나의 작업(task)만을 처리할 수 있다는 것을 의미한다. 하지만 실제로 동작하는 웹 애플리케이션은 많은 task가 동시에 처리되는 것처럼 느껴진다. 이처럼 자바스크립트의 동시성(Concurrency)을 지원하는 것이 바로 이벤트 루프(Event Loop)이다.

브라우저의 환경을 그림으로 표현하면 아래와 같다. 이벤트 루프(Event Loop)와 브라우저의 환경

구글의 V8을 비롯한 대부분의 자바스크립트 엔진은 크게 2개의 영역으로 나뉜다.

Call Stack(호출 스택) 작업이 요청되면(함수가 호출되면) 요청된 작업은 순차적으로 Call Stack에 쌓이게 되고 순차적으로 실행된다. 자바스크립트는 단 하나의 Call Stack을 사용하기 때문에 해당 task가 종료하기 전까지는 다른 어떤 task도 수행될 수 없다.

Heap 동적으로 생성된 객체 인스턴스가 할당되는 영역이다.

이와 같이 자바스크립트 엔진은 단순히 작업이 요청되면 Call Stack을 사용하여 요청된 작업을 순차적으로 실행할 뿐이다. 앞에서 언급한 동시성(Concurrency)을 지원하기 위해 필요한 비동기 요청(이벤트를 포함) 처리는 자바스크립트 엔진을 구동하는 환경 즉 브라우저(또는 Node.js)가 담당한다.

Event Queue(Task Queue) 비동기 처리 함수의 콜백 함수, 비동기식 이벤트 핸들러, Timer 함수(setTimeout(), setInterval())의 콜백 함수가 보관되는 영역으로 이벤트 루프(Event Loop)에 의해 특정 시점(Call Stack이 비어졌을 때)에 순차적으로 Call Stack으로 이동되어 실행된다. Event Loop(이벤트 루프) Call Stack 내에서 현재 실행중인 task가 있는지 그리고 Event Queue에 task가 있는지 반복하여 확인한다. 만약 Call Stack이 비어있다면 Event Queue 내의 task가 Call Stack으로 이동하고 실행된다. 아래의 예제가 어떻게 동작할지 살펴보자.

function func1() { console.log('func1'); func2(); }

function func2() { setTimeout(function () { console.log('func2'); }, 0);

func3(); }

function func3() { console.log('func3'); }

func1(); 함수 func1이 호출되면 함수 func1은 Call Stack에 쌓인다. 그리고 함수 func1은 함수 func2을 호출하므로 함수 func2가 Call Stack에 쌓이고 setTimeout가 호출된다. setTimeout의 콜백함수는 즉시 실행되지 않고 지정 대기 시간만큼 기다리다가 “tick” 이벤트가 발생하면 태스크 큐로 이동한 후 Call Stack이 비어졌을 때 Call Stack으로 이동되어 실행된다.

event-loop

이벤트 루프(Event Loop)에 의한 setTimeout 콜백함수의 실행

DOM 이벤트 핸들러도 이와 같이 동작한다.

function func1() { console.log('func1'); func2(); }

function func2() { // foo const elem = document.querySelector('.foo');

elem.addEventListener('click', function () { this.style.backgroundColor = 'indigo'; console.log('func2'); });

func3(); }

function func3() { console.log('func3'); }

func1(); 함수 func1이 호출되면 함수 func1은 Call Stack에 쌓인다. 그리고 함수 func1은 함수 func2을 호출하므로 함수 func2가 Call Stack에 쌓이고 addEventListener가 호출된다. addEventListener의 콜백함수는 foo 버튼이 클릭되어 click 이벤트가 발생하면 태스크 큐로 이동한 후 Call Stack이 비어졌을 때 Call Stack으로 이동되어 실행된다.

#3. 이벤트의 종류 대표적인 이벤트를 소개한다. 자세한 사항은 Event reference을 참조 바란다.

#3.1 UI Event Event Description load 웹페이지의 로드가 완료되었을 때 unload 웹페이지가 언로드될 때(주로 새로운 페이지를 요청한 경우) error 브라우저가 자바스크립트 오류를 만났거나 요청한 자원이 존재하지 않는 경우 resize 브라우저 창의 크기를 조절했을 때 scroll 사용자가 페이지를 위아래로 스크롤할 때 select 텍스트를 선택했을 때 #3.2 Keyboard Event Event Description keydown 키를 누르고 있을 때 keyup 누르고 있던 키를 뗄 때 keypress 키를 누르고 뗏을 때 #3.3 Mouse Event Event Description click 마우스 버튼을 클릭했을 때 dbclick 마우스 버튼을 더블 클릭했을 때 mousedown 마우스 버튼을 누르고 있을 때 mouseup 누르고 있던 마우스 버튼을 뗄 때 mousemove 마우스를 움직일 때 (터치스크린에서 동작하지 않는다) mouseover 마우스를 요소 위로 움직였을 때 (터치스크린에서 동작하지 않는다) mouseout 마우스를 요소 밖으로 움직였을 때 (터치스크린에서 동작하지 않는다) #3.4 Focus Event Event Description focus/focusin 요소가 포커스를 얻었을 때 blur/foucusout 요소가 포커스를 잃었을 때 #3.5 Form Event Event Description input input 또는 textarea 요소의 값이 변경되었을 때 contenteditable 어트리뷰트를 가진 요소의 값이 변경되었을 때 change select box, checkbox, radio button의 상태가 변경되었을 때 submit form을 submit할 때 (버튼 또는 키) reset reset 버튼을 클릭할 때 (최근에는 사용 안함) #3.6 Clipboard Event Event Description cut 콘텐츠를 잘라내기할 때 copy 콘텐츠를 복사할 때 paste 콘텐츠를 붙여넣기할 때 #4. 이벤트 핸들러 등록 이벤트가 발생했을 때 동작할 이벤트 핸들러를 이벤트에 등록하는 방법은 아래와 같이 3가지이다.

#4.1 인라인 이벤트 핸들러 방식 HTML 요소의 이벤트 핸들러 어트리뷰트에 이벤트 핸들러를 등록하는 방법이다.

이 방식은 더 이상 사용되지 않으며 사용해서도 않된다. 오래된 코드에서 간혹 이 방식을 사용한 것이 있기 때문에 알아둘 필요는 있다. HTML과 Javascript는 관심사가 다르므로 분리하는 것이 좋다.

최근 관심을 받고 있는 CBD(Component Based Development) 방식의 Angular/React/Vue.js와 같은 프레임워크/라이브러리에서는 인라인 이벤트 핸들러 방식으로 이벤트를 처리한다. CBD에서는 HTML, CSS, 자바스크립트를 뷰를 구성하기 위한 구성 요소로 보기 때문에 관심사가 다르다고 생각하지 않는다.

주의할 것은 onclick과 같이 on으로 시작하는 이벤트 어트리뷰트의 값으로 함수 호출을 전달한다는 것이다. 다음에 살펴볼 이벤트 핸들러 프로퍼티 방식에는 DOM 요소의 이벤트 핸들러 프로퍼티에 함수 호출이 아닌 함수를 전달한다.

이때 이벤트 어트리뷰트의 값으로 전달한 함수 호출이 즉시 호출되는 것은 아니다. 사실은 이벤트 어트리뷰트 키를 이름으로 갖는 함수를 암묵적으로 정의하고 그 함수의 몸체에 이벤트 어트리뷰트의 값으로 전달한 함수 호출을 문으로 갖는다. 위 예제의 경우, button 요소의 onclick 프로퍼티에 함수 function onclick(event) { foo(); }가 할당된다.

즉, 이벤트 어트리뷰트의 값은 암묵적으로 정의되는 이벤트 핸들러의 문이다. 따라서 아래와 같이 여러 개의 문을 전달할 수 있다.

#4.2 이벤트 핸들러 프로퍼티 방식 인라인 이벤트 핸들러 방식처럼 HTML과 Javascript가 뒤섞이는 문제는 해결할 수 있는 방식이다. 하지만 이벤트 핸들러 프로퍼티에 하나의 이벤트 핸들러만을 바인딩할 수 있다는 단점이 있다.

#4.3 addEventListener 메소드 방식 addEventListener 메소드를 이용하여 대상 DOM 요소에 이벤트를 바인딩하고 해당 이벤트가 발생했을 때 실행될 콜백 함수(이벤트 핸들러)를 지정한다.

Event Listener

addEventListener 메소드

addEventListener 함수 방식은 이전 방식에 비해 아래와 같이 보다 나은 장점을 갖는다.

하나의 이벤트에 대해 하나 이상의 이벤트 핸들러를 추가할 수 있다. 캡처링과 버블링을 지원한다. HTML 요소뿐만아니라 모든 DOM 요소(HTML, XML, SVG)에 대해 동작한다. 브라우저는 웹 문서(HTML, XML, SVG)를 로드한 후, 파싱하여 DOM을 생성한다. addEventListener 메소드는 IE 9 이상에서 동작한다. IE 8 이하에서는 attachEvent 메소드를 사용한다.

if (elem.addEventListener) { // IE 9 ~ elem.addEventListener('click', func); } else if (elem.attachEvent) { // ~ IE 8 elem.attachEvent('onclick', func); } addEventListener 메소드의 사용 예제를 살펴보자.

위와 같이 대상 DOM 요소(target)를 지정하지 않으면 전역객체 window, 즉 DOM 문서를 포함한 브라우저의 윈도우에서 발생하는 click 이벤트에 이벤트 핸들러를 바인딩한다. 따라서 브라우저 윈도우 어디를 클릭하여도 이벤트 핸들러가 동작한다.

위 예제는 input 요소에서 발생하는 blur 이벤트에 이벤트 핸들러를 바인딩하였다. 사용자 이름이 최소 2자 이상이야한다는 규칙을 세우고 이에 부합하는지 확인해보자.

2자 이상이라는 규칙이 바뀌면 이 규칙을 확인하는 모든 코드를 수정해야 한다. 따라서 이러한 방식의 코딩은 바람직하지 않다. 이유는 규모가 큰 프로그램의 경우 수정과 테스트에 소요되는 자원의 낭비도 문제이지만 수정에는 거의 대부분 실수가 동반되기 때문이다.

2자 이상이라는 규칙을 상수화하고 함수의 인수로 전달도록 수정하자. 이렇게 하면 규칙이 변경되어도 함수는 수정하지 않아도 된다.

그런데 addEventListener 메소드의 두번째 매개변수는 이벤트가 발생했을 때 호출될 이벤트 핸들러이다. 이때 두번째 매개변수에는 함수 호출이 아니라 함수 자체를 지정하여야 한다.

function foo() { alert('clicked!'); } // elem.addEventListener('click', foo()); // 이벤트 발생 시까지 대기하지 않고 바로 실행된다 elem.addEventListener('click', foo); // 이벤트 발생 시까지 대기한다 따라서 이벤트 핸들러 프로퍼티 방식과 같이 이벤트 핸들러 함수에 인수를 전달할 수 없는 문제가 발생한다. 이를 우회하는 방법은 아래와 같다.

#5. 이벤트 핸들러 함수 내부의 this #5.1 인라인 이벤트 핸들러 방식 인라인 이벤트 핸들러 방식의 경우, 이벤트 핸들러는 일반 함수로서 호출되므로 이벤트 핸들러 내부의 this는 전역 객체 window를 가리킨다.

자식 요소에서 발생한 이벤트가 부모 요소로 전파되는 것을 버블링이라 하고, 자식 요소에서 발생한 이벤트가 부모 요소부터 시작하여 이벤트를 발생시킨 자식 요소까지 도달하는 것을 캡처링이라 한다. 주의할 것은 버블링과 캡처링은 둘 중에 하나만 발생하는 것이 아니라 캡처링부터 시작하여 버블링으로 종료한다는 것이다. 즉, 이벤트가 발생했을 때 캡처링과 버블링은 순차적으로 발생한다.

캡처링은 IE8 이하에서 지원되지 않는다.

event flow

www.w3.org/TR/DOM-Level-3-Events

addEventListener 메소드의 세번째 매개변수에 true를 설정하면 캡처링으로 전파되는 이벤트를 캐치하고 false 또는 미설정하면 버블링으로 전파되는 이벤트를 캐치한다.

      //HTML 문서 로딩 완료, 이미지, CSS 같은 외부 컨텐츠 로딩 완료 후에 발생하는 이벤틏
      window.addEventListener("load", function () {});

      //HTML 문서 로딩 완료(DOM 객체 생성 완료) 후에 발생하는 이벤트
      document.addEventListener("DOMContentLoaded", function () {};

자바스크립트 코드를 짜며 window객체와 document객체의 차이에 대해 잘 알지 못하고 사용한 점이 생각나서 포스팅한 게시물입니다.

평소에 window / document 객체를 참조하는 흔한 작업들은 다음과 같았다.

1. 이벤트 리스너 등록

window.addEventListener("scroll", function () {});
document.addEventListener("click", function() {});

2. dom에 접근

document.body.style.backgroundColor = "#fafafc";
document.getElementById("nextForm").focus();

3. 스크롤 위치 이동

window.scrollTo(pos);

4. 창 닫기 / 열기

window.close();
window.open(url);

나열해놓고 보니 window객체와 document객체에서 하는 일이 뭔가 미묘하게 다른 건 알겠다.

하지만 여전히 명확한 차이가 무엇인지, 두 객체의 addEventListener가 어떤 차이인지 모르겠다.

다행히 이러한 궁금증을 나만 가진것이 아니었기 때문에 다른 분들이 stackoverflow에 작성하신 질문들이 있었고, 거기엔 좋은 답변들이 준비되어 있었다.

https://stackoverflow.com/questions/9895202/what-is-the-difference-between-window-screen-and-document

https://stackoverflow.com/questions/12045440/difference-between-document-addeventlistener-and-window-addeventlistener

결론만 요약하자면 다음과 같다.

• window 객체는 브라우저라는 host 환경에서 동작하는 최상위 객체로, 브라우저 환경에서 동작하는 여러 API들의 가교 역할을 한다. document, history, location, setTimout, cookieStore 등 다른 브라우저 api에 접근을 제공한다.

• JSDom등의 환경에서는 표준 window 객체의 인터페이스를 바탕으로 구현한 더미 window 객체(더미라고 해도 몇몇 기능들은 동작한다)를 사용하게 되는데 이 경우에는 실제 브라우저의 인터페이스와 다를 수 있으니 주의해야 한다.

• document 객체는 window에 로드되는 HTML 문서 그 자체를 나타내며(document 객체가 존재), 해당 문서 내부의 HTML Element, Css 등을 제어할 수 있는 여러 메서드를 제공한다. 보편적으로 window 객체의 프로퍼티로 제공된다. document 객체는 window.document 혹은 document로 접근이 가능하다.

• 일반적으로 querySelector 등의 메서드로 css selector 기반의 element 쿼리를 많이 하게 된다.

• window 객체는 전역으로 선언되어 있기 때문에 window객체 안에 있는 요소는 "window."와 같이 window객체를 참조하지 않고도 property 이름으로 바로 접근이 가능하다. 예컨대 window.innerHeight는 그냥 innerHeight로 접근이 가능하다. ( 오... 신기... 하지만 혼동이나 scope 등의 문제로 window.innerHeight 이런 식으로 사용하는 게 좋을 것 같다. ) document객체와 window객체에서 수용 가능한 eventList가 다르기 때문에, 같은 addEventListener이 있다고 하더라도, 각 용도에 맞게 호출해야 한다.

[결론] window.addEventLister VS document.addEventLister

사실 둘의 차이는 명확하지 않다. stackoverflow 에 나와 있는 설명에 의하면 각각이 제어하는 이벤트 리스너에 차이가 있기 때문에 구분해서 써야한다고 한다. 대표적으로 resize 이벤트가 있는데 이 이벤트의 경우 window 이벤트 리스너에는 있지만 document 이벤트 리스너에는 있지 않다.

하지만 click 과 같이 window 와 document 에 공통으로 들어가 있는 이벤트도 있는데 이 경우stackoverflow 의 답변은 이렇다.

전파된 이벤트의 유일한 주요 차이점은 타이밍입니다. 이벤트는 계층 구조에서 document 가 window 보다 먼저 발생하지만 일반적으로 그 차이는 중요하지 않으므로 둘 중 하나를 선택해도 됩니다. 일반적으로 전파된 이벤트를 처리할 때는 이벤트의 소스와 가장 가까운 객체를 선택하는 것이 필요에 부합합니다. 즉, 둘 다 작동할 때 window 보다 document 를 선택하는 것이 좋습니다.

직접 같은 이벤트를 등록하고 이벤트를 실행해보면, document 로 등록한 이벤트가 먼저 실행이 된다.

참조: https://nookpi.tistory.com/56