클라우드 보안) 26.02.05

25~26 겨울방학/클라우드 보안

클라우드 보안) 26.02.05

kimchangmin02 2026. 2. 6. 10:05

web이랑 default가 뭐가 다른거였더라

그, private으로 접속하는 방법 쿼였다고 했더라

MSP와 CSP의 비유:
- CSP (Cloud Service Provider): 네이버 클라우드, AWS, MS 애저 등. **'땅과 건물'**을 제공하는 역할.
- MSP (Managed Service Provider): 클라우드 스퀘어 같은 회사. 제공된 인프라(건물) 내부에 **'인테리어'**를 하고 서비스를 구성해 주는 역할. 이번 교육은 이 '인테리어' 과정에서 보안을 어떻게 강화할지를 배우는 것임.

4. 보안의 3요소 (CIA) - 상세 설명

강사는 이 세 가지의 **'밸런스'**가 가장 중요하다고 강조함. 기밀성만 강조하면 서비스가 너무 느려지기 때문.

기밀성 (Confidentiality): 허가된 사람만 보기.
- 위협: 개인정보 유출, 비밀번호 평문 저장. (모든 사이트 비번을 다르게 쓰는 사람은 없으므로 평문 저장은 매우 위험).
- 방어: 암호화(AES-양방향, RSA-단방향/공개키), HTTPS, 접근 통제(ACG, NACL-방화벽 역할), 마스킹(포스트잇에 비번 적어 모니터에 붙이는 행위 등 물리적 유출 주의).

[ VPC (나의 거대한 네트워크 성) ]
   │
   ├── [ 서브넷 A (1층: 로비/공개구역) ] ─── <여기를 지키는 것이 NACL>
   │      ├── 서버 1 (웹 서버) ─────────────── <여기를 지키는 것이 ACG>
   │      └── 서버 2 (웹 서버) ─────────────── <여기를 지키는 것이 ACG>
   │
   └── [ 서브넷 B (2층: 금고실/비공개구역) ] ─ <여기를 지키는 것이 NACL>
          ├── 서버 3 (DB 서버) ─────────────── <여기를 지키는 것이 ACG>
          └── 서버 4 (DB 서버) ─────────────── <여기를 지키는 것이 ACG>

1. AES (양방향 / 대칭키 암호화)

핵심 개념: 암호화할 때 쓰는 키와 복호화(풀 때)할 때 쓰는 키가 똑같습니다.
수업 내용: 강사님이 "내가 사과라고 던지면 상대도 사과라고 받아야 한다"고 비유하며, 정보를 주고받을 때 양쪽이 같은 키를 공유해서 잠그고 푸는 방식이라고 설명하셨습니다.
특징: 속도가 빠르지만, 상대방에게 '키'를 안전하게 전달하는 것이 어렵다는 단점이 있습니다. (키를 뺏기면 다 털림)

2. RSA (공개키 / 비대칭키 암호화)

핵심 개념: 키가 두 개입니다. **공개키(Public Key)**로 잠그고, 나만 가진 **개인키(Private Key)**로 풉니다.
수업 내용: 강사님이 오늘 낸 **마지막 과제(PEM 키 접속)**의 원리입니다. 서버에는 '공개키'를 등록해두고(누가 봐도 상관없음), 내 PC에는 '개인키(PEM)'를 보관해서 인증하는 방식입니다.
특징: 키를 전달할 필요가 없어 보안성이 매우 높지만, 계산 과정이 복잡해 AES보다 속도가 느립니다.

3. 비교 정리 (강사님 핵심 요약)

구분	AES (대칭키)	RSA (공개키/비대칭키)
키의 개수	1개 (둘이 똑같은 거 가짐)	2개 (공개키 + 개인키)
강사님 키워드	양방향 (키 하나로 왔다 갔다)	공개키 (개인키와 짝꿍)
비유	현관문 열쇠 하나를 복사해서 나눠 가짐	우체통 (누구나 넣을 순 있지만, 주인만 열 수 있음)
오늘 실습	일반적인 데이터 암호화	SSH 접속(PEM 키) 과제

💡 참고 (헷갈릴 수 있는 '단방향'):
오늘 수업에서 **'단방향(One-Way)'**이라는 표현은 주로 SHA-256 같은 해시 함수를 말할 때 쓰셨습니다. 이건 한 번 암호화하면 절대 다시 풀 수 없는 것으로, 데이터베이스(DB)에 비밀번호를 저장할 때 "설령 유출돼도 원래 비번을 알 수 없게" 하기 위해 사용한다고 강조하셨던 그 내용입니다!

1. 단방향(One-Way)의 의미: "믹서기"

단방향 암호화는 과일을 넣고 갈아버린 **'주스'**와 같습니다.

사과를 넣고 믹서기를 돌리면 사과 주스가 나옵니다. (암호화)
하지만 그 사과 주스를 아무리 연구해도 다시 원래의 온전한 사과 모양으로 되돌릴 수는 없습니다. (복호화 불가)

이것이 SHA-256 같은 해시 함수의 특징입니다. 어떤 값을 넣어도 결과는 나오지만, 그 결과를 가지고 원래 값을 역추적하는 수학적 방법은 (현재 기술로는) 없습니다.

2. 그런데 로그인은 어떻게 확인하나요? (핵심 원리)

"서버도 내 비번을 모르는데 어떻게 내가 입력한 게 맞는지 알지?"의 답은 **'비교'**에 있습니다.

회원가입 시:
- 사용자가 password123 입력
- 시스템은 이걸 SHA-256으로 돌려서 a7b8c9...라는 외계어(해시값)를 만듦
- DB에는 원래 비번인 password123이 아니라 a7b8c9...만 저장함
로그인 시:
- 사용자가 다시 password123 입력
- 시스템은 사용자가 방금 입력한 비번을 똑같은 믹서기(SHA-256)에 넣고 돌림
- 결과물이 a7b8c9...가 나옴
- DB에 저장된 값과 방금 돌린 결과값이 일치하는지만 확인!

즉, 서버는 사용자의 실제 비밀번호가 무엇인지 몰라도, "입력한 걸 똑같이 암호화해보니 결과가 같네? 그럼 맞는 비번이겠군!" 하고 통과시켜 주는 것입니다.

3. "유출돼도 원래 비번을 알 수 없다"는 게 왜 중요한가요?

만약 해커가 사이트의 데이터베이스(DB)를 통째로 털어갔다고 가정해 봅시다.

양방향 암호화(또는 평문)인 경우: 해커가 DB를 열자마자 모든 사용자의 비밀번호(password123, love1234 등)를 그대로 보게 됩니다.
단방향 암호화인 경우: 해커는 a7b8c9..., e2f3g4... 같은 의미 없는 외계어 뭉치만 보게 됩니다. 이 외계어를 가지고 거꾸로 계산해서 원래 비밀번호를 알아낼 방법이 없기 때문에, 해커는 DB를 털었어도 정작 사용자의 진짜 비번은 알 수 없습니다.

. ACG가 뭔가요? (물리적 실체와 역할)

"네트워크에 끼우는 것"이라는 말은 아주 훌륭한 통찰입니다! 다만 물리적인 카드가 아니라 **'가상 네트워크 카드에 설정하는 소프트웨어 장치'**라고 보시면 됩니다.

물리적 정체: 서버(VM)를 만들면, 그 서버는 가상의 랜선과 연결된 **가상 네트워크 인터페이스(vNIC, 가상 랜카드)**를 가집니다. **ACG(Access Control Group)**는 이 가상 랜카드 바로 앞에 씌우는 **'가상 방화벽'**입니다.
"끼우는 것"의 의미: 클라우드 콘솔에서 서버를 설정할 때, "이 서버의 랜카드에는 '웹/SSH 허용'이라는 ACG를 적용(끼우기)해!"라고 명령하는 것입니다.
하는 일: 패킷이 전선을 타고 서버 근처에 왔을 때, OS(윈도우나 리눅스)가 그 데이터를 보기 전에 클라우드 시스템 수준에서 먼저 검사합니다.
- "주인님이 2200번은 통과시켜 주랬어. 통과!"
- "어? 22번은 금지 목록에 있네? 삭제!"
- 결과: 서버 OS는 ACG가 통과시켜준 데이터만 구경할 수 있습니다. 그래서 보안이 아주 강력해집니다.

퍼블릭 서브넷 (Public Subnet):
- 이 서브넷 안에 있는 서버들은 **공인 IP(Public IP)**를 가질 수 있습니다.
- 인터넷 게이트웨이(IGW)를 통해 외부 인터넷과 직접 통신이 가능합니다.
- 용도: 사용자가 직접 접속해야 하는 웹 서버(Web Server).
프라이빗 서브넷 (Private Subnet):
- 외부 인터넷에서 이 서브넷 안의 서버로 직접 들어올 수 없습니다.
- 공인 IP를 가질 수 없으며, 오직 VPC 내부 통신만 가능합니다.
- 용도: 보안이 생명인 **데이터베이스(DB)**나 비즈니스 로직(WAS) 서버.

거대한 VPC(10.0.0.0/16)를 하나로 통째로 쓰면 관리가 힘들고 보안에 취약합니다. 그래서 이를 작은 단위인 서브넷으로 쪼개는 것입니다.

무결성 (Integrity): 함부로 수정되지 않기.
- 예시: 통장 잔액 100만 원이 누군가에 의해 1만 원으로 수정되면 안 됨.
- 방어: 해시 함수(SHA-256), 디지털 서명. (금융권은 보안을 위해 외부 인터넷이 차단된 환경에서 작업하기도 함).
가용성 (Availability): 24시간 서비스가 돌아가기.
- 가용성이 없으면 기밀성/무결성도 의미가 없음(서비스가 안 되는데 보안이 무슨 소용인가).
- 위협: DDoS(패킷 때려박기), 랜섬웨어, SPOF(단일 실패 지점) - 특정 지점 한 곳만 공격해서 전체 서비스를 마비시키는 것.
- 방어: 이중화, 오토스케일링, 백업, CDN (콘텐츠 전송 네트워크 - 해외 사용자를 위해 각 지역 스토리지에 캐싱하여 속도와 가용성 높임), DR(재해 복구 - 화재 시 부산 IDC 등으로 즉시 전환).

5. 서버와 클라우드의 특징 (사소한 디테일 포함)

서버의 본질: PC와 구조는 같으나 '중단 없는 운영'이 목적. 따라서 대역폭, 발열 관리(냉각), 부품 이중화가 핵심.
클라우드 도입 이유 (DX 및 AX):
- DX(디지털 전환): 아날로그 서비스를 디지털로 바꾸는 것.
- AX(AI 전환): 서비스를 AI 기반으로 전환하는 최신 트렌드.
클라우드 비용이 '합리적'인 이유 (중요):
- 단순 요금만 보면 비쌀 수 있으나, 전혀 DX되지 않은 상태에서 인프라를 직접 구매(서버, 전기, 먼지 청소 등 관리)하고, 그걸 다룰 줄 아는 전문 엔지니어를 채용하는 시간과 비용을 전체적으로 고려했을 때 클라우드가 훨씬 '합리적'이라는 의미임.
클라우드 장점: 신속한 인프라 도입, 클릭 몇 번으로 고급 보안 장비(WAF 등) 설치 가능, 손쉬운 글로벌 서비스(미국 사업 시 영어만 준비하면 됨).
클라우드 단점: 운영비가 생각보다 비쌀 수 있음, 특정 업체 종속성, 인프라의 아주 낮은 단계(L1~L2 수준)는 직접 제어할 수 없음(이는 보안을 위한 제약이기도 함).
가상화: 60년대 개념 등장, 2000년대 상용화. 물리 서버 자원을 논리적으로 쪼개서 리눅스나 윈도우를 각각 올리는 방식.

2. 서버 가상화 이론 (심화 및 비유)

베어 메탈 서버 (Bare Metal): 가상화 레이어 없이 물리 서버를 통째로 할당받는 방식. 네이버 클라우드에서 일반 VM에 설치가 불가능한 '오라클 DB' 같은 특수 소프트웨어나 OS를 사용할 때 사용함.

베어 메탈: 가상화라는 '옷'을 입지 않은 생(Bare) 하드웨어(Metal) 그 자체.
쓰는 이유: 가상화로 인한 성능 손실을 없애기 위해, 혹은 오라클처럼 라이선스 규정이 까다로운 소프트웨어를 돌리기 위해.
한 줄 평: 클라우드 세상에서 만나는 "진짜 물리 서버 전용 렌탈" 서비스.

컴퓨터 본체 한 대를 통째로 빌린다고 생각하시면 됩니다. 그 '기계 덩어리' 안에 들어있는 모든 부품이 오직 당신만을 위해 돌아갑니다.

무엇의 '전체'인가요? (부품별 설명)

일반적인 클라우드 서버(VM)를 빌리면 CPU의 일부, 메모리의 일부만 떼어주지만, 베어 메탈은 다음을 통째로 넘겨줍니다.

CPU 전체: 예를 들어 그 기계에 코어가 64개 박혀 있다면, 64개 모두를 당신의 프로그램만 사용합니다. (남이 옆에서 내 CPU 자원을 뺏어갈 일이 0.0001%도 없습니다.)
메모리(RAM) 전체: 꽂혀 있는 256GB, 512GB의 램을 당신 혼자 다 씁니다. 가상화 OS가 중간에서 자기 몫으로 떼어가는 메모리조차 없습니다.
디스크(SSD/HDD) 전체: 가상으로 만든 저장 공간이 아니라, 서버에 직접 꽂힌 진짜 물리 디스크를 직접 읽고 씁니다. 속도가 훨씬 빠르겠죠.
랜카드(NIC) 전체: 네트워크를 주고받는 물리적인 입구 자체를 독점합니다.

왜 "베어(Bare) + 메탈(Metal)"인가요?

Metal (금속): 서버 컴퓨터 본체 껍데기와 그 안의 회로판(하드웨어)을 뜻합니다.
Bare (벌거벗은): 그 금속(서버) 위에 아무것도 안 입혔다는 뜻입니다.

정가상화 (Full Virtualization) vs 반가상화 (Para-virtualization):
- 정가상화: 바이너리 트랜슬레이션을 통해 OS 명령을 하드웨어로 직접 전달. OS 수정이 필요 없어 최신 OS(우분투, 로키 등) 대응이 빠름. 보안 취약점 대처에 유리함.
- 반가상화: 하이퍼바이저에 맞게 '수정된 게스트 OS'가 필요함. 최신 OS가 출시되어도 수정 과정 때문에 클라우드사에서 제공하기까지 시간이 오래 걸림.

용어가 정말 어렵죠? 컴퓨터 네트워크나 운영체제(OS) 전공 수업에서도 가장 까다로운 부분 중 하나입니다.

핵심은 이겁니다: "가짜 컴퓨터(VM) 안의 운영체제(Guest OS)가 진짜 하드웨어(CPU, 메모리)와 어떻게 대화할 것인가?"

이걸 **'통역 방식'**에 비유해서 아주 쉽게 풀어드릴게요.

배경 상황: "내가 왕이로소이다!"

운영체제(Windows, Linux 등)는 원래 **"내가 이 컴퓨터의 유일한 주인(왕)이다!"**라고 생각하도록 설계되었습니다. 그래서 하드웨어에 직접 명령을 내리죠.

그런데 가상화 환경에서는 진짜 왕은 **하이퍼바이저(관리자)**이고, 운영체제는 **가짜 왕(손님)**입니다. 가짜 왕이 진짜 왕처럼 명령을 내리면 사고가 나겠죠? 이걸 해결하는 두 가지 방식입니다.

1. 정가상화 (Full Virtualization): "실시간 통역사 방식"

가짜 왕(OS)은 자기가 가짜인 줄 전혀 모릅니다. 평소처럼 하드웨어에 "야! 이거 해!"라고 명령을 내립니다.

바이너리 트랜슬레이션 (통역): 중간에 있는 하이퍼바이저가 이 명령을 가로챕니다. 그리고 하드웨어가 알아들을 수 있게 실시간으로 말을 바꿔서(번역해서) 전달합니다.
OS 수정 없음: OS 입장에서는 바꾸는 게 없으니 아무 OS(윈도우든 최신 리눅스든)나 그냥 갖다 깔면 바로 돌아갑니다. 그래서 **"최신 OS 대응이 빠르다"**고 하는 겁니다.
단점: 실시간으로 모든 말을 번역하려니 통역사가 좀 힘듭니다(성능 오버헤드).

2. 반가상화 (Para-virtualization): "외국어 학습 방식"

가짜 왕(OS)에게 미리 교육을 시킵니다. "너 사실 가짜 왕이야. 그러니까 명령하지 말고, 나(하이퍼바이저)한테 **부탁(Hypercall)**을 해."

수정된 게스트 OS: 하이퍼바이저와 대화할 수 있도록 OS의 소스코드를 뜯어고쳐야 합니다. OS가 "나 가짜니까 도와줘"라고 말하게 만드는 거죠.
장점: 통역사 없이 직접 대화하는 식이라 속도가 아주 빠릅니다.
단점: OS가 출시될 때마다 클라우드 개발자들이 "자, 이 OS를 우리 하이퍼바이저에 맞게 뜯어고치자!" 하는 작업 시간이 필요합니다. 그래서 **"최신 OS 제공까지 시간이 오래 걸린다"**고 하는 겁니다.

한 눈에 비교 (비유)

구분	정가상화 (Full)	반가상화 (Para)
비유	동시 통역	외국어 직접 회화
OS의 상태	원래 쓰던 말 그대로 씀 (수정 X)	외국어를 배워야 함 (수정 O)
속도	통역 과정 때문에 조금 느림	직접 말하니 빠름
편의성	아무나(어떤 OS든) 바로 입주 가능	공부(수정)한 놈만 입주 가능
핵심 용어	바이너리 트랜슬레이션 (실시간 번역)	하이퍼콜(Hypercall) (정중한 요청)

질문하신 문장 다시 읽어보기

"정가상화: ... OS 수정이 필요 없어 최신 OS 대응이 빠름."
-> (해석) 통역사가 다 알아서 해주니까, 새로 나온 OS가 어떤 말을 쓰든 그냥 데려오면 바로 서비스할 수 있다!

"반가상화: ... 수정된 게스트 OS가 필요함. ... 제공하기까지 시간이 오래 걸림."
-> (해석) OS가 하이퍼바이저랑 친해지게(수정하게) 공부를 시켜야 하는데, 그 공부 시키는 시간이 걸려서 최신 OS를 바로 못 내놓는다!

요즘은 어떨까요?
요즘은 CPU 자체가 너무 좋아져서(하드웨어 가상화 지원), 굳이 OS를 힘들게 안 고쳐도(반가상화 안 해도) 정가상화처럼 편하면서 성능도 잘 나옵니다. 그래서 점점 정가상화나 하이브리드 방식을 더 많이 쓰는 추세입니다.

이제 이 복잡한 용어들이 좀 연결되시나요?

'가상화(Virtualization)'라는 단어가 참 추상적이죠. 아주 쉽게, **"하나를 여러 개인 척 속이는 기술"**이라고 생각하면 편합니다.

네트워크 시간에 배운 '가상 랜(VLAN)'이 "선은 하나인데 여러 개인 것처럼 나누는 것"이었죠? 가상화는 이걸 **컴퓨터 본체(CPU, 메모리)**에 적용한 겁니다.

1. 가상화가 없던 시절 (전통적인 방식)

옛날에는 컴퓨터 1대에 OS(윈도우나 리눅스)를 1개만 깔 수 있었습니다.

문제점: 만약 내가 산 서버가 엄청나게 좋은데(CPU 64코어), 정작 돌리는 프로그램은 아주 가벼운 거라면? 나머지 CPU 성능은 그냥 노는 꼴이 됩니다. 낭비가 심하죠.
비유: 거대한 63빌딩을 통째로 샀는데, 1층 구석방 한 칸만 쓰고 나머지 층은 다 비워두는 것과 같습니다.

2. 가상화(Virtualization)의 등장

"야, 이거 아깝다. 컴퓨터 한 대를 여러 대인 것처럼 쪼개서 쓰자!" 해서 나온 기술입니다. 이때 등장하는 것이 바로 **하이퍼바이저(Hypervisor)**라는 관리자 소프트웨어입니다.

하이퍼바이저의 역할: 진짜 물리적인 부품(CPU, RAM) 위에 올라앉아서, 그 자원들을 "조각조각" 냅니다.
가상 머신(VM): 하이퍼바이저가 떼어준 조각(CPU 2개, RAM 4GB 등)을 받아 마치 자기가 진짜 독립된 컴퓨터인 줄 알고 돌아가는 가짜 컴퓨터입니다.

하이퍼바이저(Hypervisor)가 하는 일

하이퍼바이저는 일종의 **'중간 통역사'**입니다.

자원 분배: "1번 가상 컴퓨터야, 넌 전체 CPU 중에 10%만 써. 2번 넌 20% 써."
격리: "1번 컴퓨터가 고장 나서 블루스크린이 떠도, 2번 컴퓨터는 상관없게 해줄게."
속이기: 가상 컴퓨터 안에 설치된 윈도우(OS)는 자기가 가짜인 줄 모릅니다. 하이퍼바이저가 진짜 하드웨어인 척 응답해주기 때문입니다.

EOS/EOL (End of Service/Life): CentOS처럼 서비스가 종료된 OS는 보안 인증 심사를 받을 수 없음. 따라서 클라우드사가 최신 OS를 얼마나 빨리 제공하느냐가 보안 관리의 핵심임.

3. 네이버 클라우드 콘솔 접속 및 가이드 활용

플랫폼 선택: 반드시 '기업용'으로 접속. 공공존은 별도 인증 코드가 필요함.
로그인: 메인 계정이 아닌 '서브 계정(Sub Account)'으로 로그인. 최초 로그인 시 비밀번호 변경 필수.
2차 인증(2FA): 비밀번호 유출 시에도 보안을 유지할 수 있도록 강사는 항상 2차 인증을 사용함.
가이드 센터 활용: 실무에서도 매우 중요함. 사용 가이드, CLI 가이드, API 가이드가 한국어로 매우 잘 되어 있음. 서비스별 '시나리오'를 보면 권한 설정부터 접속까지 전 과정을 알 수 있음.
VPC 플랫폼: 기존 '클래식(Classic)' 환경은 현재 사라지는 추세이므로 무시하고 'VPC' 환경만 사용함.

4. 네트워크 구성 실습 (VPC & Subnet)

대시보드 기능: CPU/메모리/디스크/네트워크 사용량 모니터링 및 이벤트 알림(메일/문자) 설정 가능. 이는 가용성을 높이는 방법 중 하나임.
VPC 생성:
- 이름: lab-vpc-10
- IP 대역: 10.0.0.0/16 (16비트는 고정된 네트워크 주소, 뒤의 16비트는 호스트 주소).
서브넷(Subnet) 생성:
- 비유: VPC가 32평 아파트라면, 서브넷은 그 안의 방(10평 등)을 나누는 것.
- 목적: 웹, 와스, DB 서버를 용도별로 나누어 접근 제어(보안)를 하기 위함.
- 설정: 이름 lab-web-sub, 대역 10.0.10.0/24 (24비트로 쪼개면 서브넷 256개 생성 가능). 가용구역은 KR-2 선택.
- 퍼블릭 vs 프라이빗: 외부 통신이 필요한 웹 서버이므로 '퍼블릭' 선택.

5. ACG (Access Control Group) 설정

개념: 서버의 '네트워크 인터페이스(랜카드)'에 붙는 방화벽.
활용: 웹용/DB용 정책을 미리 만들어두고 서버 생성 시 복수 적용 가능. 서버를 추가할 때마다 방화벽을 새로 만들 필요 없이 기존 ACG를 갖다 붙이면 됨.
참고: 서브넷 단위 방화벽은 NaCl(Network ACL)이라고 부름.

6. SSL VPN 생성 (사전 작업)

생성에 3분에서 최대 30분까지 소요되므로 미리 생성함.
이름은 중복 방지를 위해 lab-[번호]-SSL-VPN 형식으로 지정.
비용은 계정 수에 따라 달라지므로 실습용 '유저 3개' 상품 선택.

7. 서버 생성 실습 (중요 디테일)

서버 스펙: 하이 CPU (2 vCPU, 4GB RAM) 최소 사양 선택.

코어 (Core): 진짜 요리사.
- 옛날 CPU는 요리사가 1명(싱글 코어)이었는데, 요즘은 한 칩 안에 요리사를 8명, 16명씩 넣습니다(멀티 코어). 요리사가 많을수록 여러 요리를 동시에 빨리 하겠죠?
쓰레드 (Thread): 요리사의 '손'.
- 인텔이나 AMD 같은 회사들이 기술을 부려서 요리사 1명이 마치 손이 2개인 것처럼 일을 하게 만들었습니다. (이걸 하이퍼쓰레딩이라고 부릅니다.)
- 물리적인 요리사는 1명이지만, 동시에 2개의 그릇을 다룰 수 있으니 컴퓨터 입장에서는 일꾼이 2명인 것처럼 보입니다.

RAM이 크면? 한꺼번에 많은 재료(데이터)를 올려두고 바로바로 요리할 수 있습니다.
RAM이 작으면? 작업대가 좁아서 재료를 냉장고(하드디스크)에서 계속 왔다 갔다 하며 가져와야 합니다. 속도가 엄청나게 느려지겠죠.

쓰레드(Thread): "놀고 있는 손을 활용하는 기술"

그런데 요리사(코어)가 일을 하다 보면 **'멍 때리는 시간'**이 생깁니다.
예를 들어: "고기가 익을 때까지(메모리에서 데이터를 가져올 때까지) 10초간 기다려야지."

이때 요리사는 가만히 서 있게 됩니다. 이게 너무 아까워서 만든 기술이 **쓰레드(하이퍼쓰레딩)**입니다.

물리적 실체: 코어는 한 개인데, 그 코어에게 명령을 전달하는 **'입구(통로)'**를 두 개로 만듭니다.
비유: 요리사는 1명인데, 양손에 칼을 쥐여주고 도마를 2개 줍니다.
- 왼쪽 도마에서 고기가 익기를 기다리는 동안(대기 시간),
- 오른쪽 도마에서 양파를 써는 겁니다.
성능: 일꾼(코어) 자체가 늘어난 건 아니라서 2배로 빨라지지는 않지만, 멍 때리는 시간이 줄어드니 대략 30% 정도 효율이 좋아집니다.

1. High CPU: "계산 천재 (두뇌형)"

비유: 복잡한 수학 문제를 엄청나게 빨리 풀어야 하는 수학자.
특징: 머리(CPU)는 엄청나게 좋아야 하지만, 책상(RAM)에 복잡하게 책을 여러 권 펼쳐둘 필요는 없습니다. 문제 하나하나를 빛의 속도로 해결하는 게 중요하니까요.
진짜 용도:
- 영상 인코딩: 영상을 압축하고 변환할 때 (CPU가 엄청 계산해야 함)
- 게임 서버: 총을 쐈을 때 맞았는지 안 맞았는지 실시간으로 계산할 때
- 과학 계산: 복잡한 시뮬레이션을 돌릴 때

2. High Memory: "박학다식한 사서 (암기형)"

비유: 수만 권의 책을 관리하는 도서관 사서.
특징: 엄청나게 복잡한 계산을 할 필요는 없지만, 한꺼번에 엄청나게 많은 데이터(책)를 책상(RAM) 위에 펼쳐놓고 바로바로 찾아줘야 합니다. 책상이 좁으면(RAM이 작으면) 창고(디스크)까지 갔다 오느라 너무 느려지거든요.
진짜 용도:
- 데이터베이스(DB): 수억 개의 고객 정보를 메모리에 다 올려두고 바로 검색할 때 (예: 오라클, MySQL)
- 캐시 서버(Redis): 자주 쓰는 데이터를 메모리에 쟁여두고 빛의 속도로 응답할 때
- 빅데이터 분석: 수 기가바이트의 로그 파일을 통째로 읽어서 분석할 때

1. 겉모습에 속지 마세요 (포장지 vs 알맹이)

우리가 손으로 잡는 그 네모난 금속 덩어리는 진짜 CPU가 아니라, **'보호 케이스(뚜껑)'**입니다.

그 뚜껑을 따보면, 안에는 손톱만한 **반도체 판(다이, Die)**이 들어있습니다. 이 판 위에는 수십억 개의 아주 미세한 전기 회로가 그려져 있는데, 제조사가 설계를 할 때 똑같은 계산기 회로를 여러 번 복사해서 그려 넣는 것입니다.

비유: 'CPU 칩 한 개'는 **'아파트 건물 한 동'**입니다.
코어: 그 건물 안에 있는 **'집 한 채(101호, 102호...)'**입니다.
건물은 하나지만, 그 안에 8가구가 독립적으로 살면서 각자 밥을 해 먹을 수 있죠? 그게 8코어입니다.

"8배 빠르다"는 말의 진짜 의미 (이게 중요!)

이 부분이 제일 헷갈리실 텐데, 사실 1가지 일을 할 때는 8배 빠르지 않습니다.

상황 A (일이 1개일 때): 라면 1개를 끓여야 합니다. 가스레인지(코어)가 8개 있다고 해서 라면이 8배 빨리 익나요? 아니죠. 화력(클럭 속도)이 중요하지 가스레인지 개수는 상관없습니다.
상황 B (일이 많을 때): 라면 100개를 끓여야 합니다. 이때는 가스레인지 1개 있는 집보다 8개 있는 집이 압도적으로(거의 8배) 빨리 끝냅니다.

결론: 요즘 컴퓨터는 한 번에 수백 개의 프로그램이 돌아가기 때문에(윈도우 기본 프로그램 + 카톡 + 브라우저 등), 일을 나눠서 할 수 있는 코어(일꾼)가 많은 게 훨씬 유리한 것입니다.

이니트 스크립트(Init Script) - 필수 설정:
- 배경: 현재 장소(대학)의 방화벽이 표준 SSH 포트인 22번을 차단하고 있음.
- 해결: 서버가 생성될 때 SSH 포트를 2200번으로 자동 변경하는 스크립트를 주입함.
- 명령어: sed 명령어를 사용해 sshd_config 파일의 22번 포트를 2200번으로 치환.
네트워크 인터페이스: 자동 할당(보통 10.0.10.6부터 시작).
공인 IP: 외부 접속을 위해 '새로운 공인 IP 할당' 선택.
인증 키(PEM):
- 비밀번호 확인을 위해 반드시 필요함.
- 서브 계정은 인증 키 분실 시 초기화가 매우 까다로움(메인 계정 접속+서버 정지 필요).
- 바탕화면에 전용 폴더를 만들어 안전하게 저장할 것.
최종 확인: 로키 리눅스 9.6, 하이 CPU, 50GB 디스크, 스크립트 적용 여부 확인 후 생성.

8. 기타 서버 지표 및 상품군

IOPS (Input/Output Per Second): 디스크 용량이 늘어날수록 성능(아이옵스)이 향상되는 구조.
GPU 서버: AI 학습용으로 수요가 폭발적이라 자원이 부족함. 대량 필요 시 CSP와 사전 협의 필수.
클라우드 펑션 (Serverless):
- 서버 관리 없이 코드만 실행.
- 주의: "서버리스로 구축했다"는 말이 멋있어 보일 수 있지만, 호출 횟수가 적은(월 30~40건) 경우에만 비용 효율적임. 서비스 성격에 맞지 않게 무분별하게 쓰는 것은 지양해야 함.

1. 보안의 3요소 (CIA)와 실무적 관점

강사님은 기술보다 **'보안의 원리'**를 이해하는 것이 중요하다고 강조하며 다음과 같은 디테일을 설명했습니다.

기밀성 (Confidentiality)과 패스워드 저장 방식:
- DB 유출 상황: 보통 개인정보 유출은 서버 자체가 아니라 **데이터베이스(DB)**에서 일어납니다.
- 평문(Plain Text) 저장의 위험성: 만약 DB에 패스워드가 평문으로 저장되어 있다면, 유출되는 즉시 끝입니다. 특히 강사님은 "모든 사이트의 계정과 비번을 다르게 쓰는 사람은 100% 확신하건대 없다"고 말하며, 한 곳의 DB만 뚫려도 다른 모든 사이트가 털리는 '크리덴셜 스터핑'의 위험을 경고했습니다.
- 암호화의 효과: 패스워드가 암호화(해싱)되어 저장되어 있다면, 설령 DB 데이터가 통째로 유출되더라도 공격자가 이를 실제 비번으로 쓸 수 없기 때문에 안전합니다. 그래서 암호화가 중요한 것입니다.
- 물리적 유출: 기술적 암호화 외에도, 회사 인턴들이 포스트잇에 비번을 써서 모니터 밑에 붙여두는 것을 누군가 사진 찍어 유출하는 사례가 매우 흔하다고 언급했습니다.
무결성 (Integrity): 금융권 사례를 들며, 여행 가려고 모은 100만 원이 누군가에 의해 1만 원으로 수정되는 상황을 방지하는 것이 핵심이라고 설명했습니다.
가용성 (Availability): 서비스가 24시간 돌아가야 하며, 기밀성과 무결성이 완벽해도 가용성이 없으면(서비스가 안 되면) 보안 자체가 의미가 없다고 강조했습니다.

2. 클라우드 인프라의 사소한 팁과 배경

VPC와 클래식의 차이: 예전 플랫폼인 클래식은 무시해도 되며, 현재는 내가 직접 IP 대역(사이더 값)을 할당할 수 있는 VPC가 표준입니다.
서브넷(Subnet) 활용의 실제: 단순히 나누는 것이 아니라, 외부에서 인터넷으로 파일을 다운로드(예: 구글에서 프로그램 받기)해야 할 때는 반드시 퍼블릭 서브넷에 서버를 만들어야 통신이 가능하다고 설명했습니다.
공인 IP: 서버에 접근하려면 반드시 할당해야 하며, "반납 보호" 설정을 통해 실수로 IP가 바뀌는 것을 방지할 수 있습니다.

3. 서버 생성 및 운영의 디테일

인증 키(PEM) 관리의 중요성:
- 인증 키가 없으면 서버 패스워드를 알아낼 수 없습니다.
- 서브 계정의 한계: 여러분이 쓰는 서브 계정은 키 초기화 권한이 없습니다. 키를 잃어버리면 메인 계정 소유자가 서버를 정지시키고 키를 재할당해야 하는데, 이는 곧 서비스 중단을 의미하므로 실무에서는 매우 치명적입니다.
포트 변경(22 -> 2200)의 이유:
- 표준 포트인 22번(SSH)은 보안상 너무 유명해서 공격의 타겟이 되기 쉽습니다.
- 특히 오늘 실습 장소(영남대) 같은 교육 기관은 자체 방화벽으로 22번 포트의 외부 유출(Outbound)을 막아놓는 경우가 많습니다. 그래서 2200번으로 바꾸지 않으면 서버에 접속조차 할 수 없기 때문에 이니트 스크립트를 쓰는 것입니다.

"내가 시킨 배달" vs "불청객"

NAT 게이트웨이는 아주 똑똑한 **'심부름꾼'**입니다.

나갈 때 (요청): 안방(프라이빗)에 있는 서버가 "구글아, 파일 좀 줘!"라고 요청합니다. 이때 패킷이 NAT 게이트웨이를 지나가죠? 그럼 NAT 게이트웨이는 장부에 몰래 적어둡니다.
- (장부 내용: "지금 우리 안방 101호 서버가 구글한테 파일 달라고 했음. 이따 구글한테 답장 오면 101호 갖다줘야지.")
들어올 때 (응답): 구글이 파일을 보냅니다. NAT 게이트웨이는 장부를 확인합니다.
- "오, 아까 우리 101호가 시킨 거네? 이건 통과!" 하고 안방으로 들여보내 줍니다.

반면, 해커가 밖에서 먼저 말을 걸면?

해커: "야! 안방 서버 문 열어!" 하고 패킷을 보냅니다.
NAT 게이트웨이: (장부를 뒤적이며) "응? 우리 안방 서버가 너한테 말 걸었다는 기록이 없는데? 넌 뭐야? 꺼져!" 하고 차단해 버립니다.

Stateful(상태 유지) 기능

패킷은 당연히 왔다 갔다(왕복) 해야 통신이 됩니다.

여기서 "들어오지 못한다"는 말의 정확한 뜻은 **"밖에서 먼저 연결을 시도하는 것(Initial Request)은 절대 불가능하다"**는 뜻입니다.

가능한 경우 (안에서 시작):
- 안방 서버: "나 업데이트 파일 좀 받을게" (나감) -> 구글: "여기 있어" (들어옴) -> 성공!
불가능한 경우 (밖에서 시작):
- 해커: "나 너네 서버 접속해서 정보 좀 빼갈게" (들어오려 함) -> NAT 게이트웨이: "누구 맘대로? 장부에 없어!" -> 차단!

IOPS (아이옵스): 디스크 성능을 뜻하며, 클라우드에서는 디스크 용량을 크게 잡을수록 할당되는 IOPS 수치가 높아져 성능이 좋아지는 구조라고 설명했습니다.

*IOPS(Input/Output Operations Per Second)**는 쉽게 말해 "1초에 디스크가 얼마나 많이 읽고 쓸 수 있는가?"

- 용량(GB): 고속도로의 길이 (데이터를 얼마나 많이 저장하나?)
- IOPS: 톨게이트의 차선(창구) 수 (얼마나 빨리 차를 통과시키나?)

"왜 용량을 크게 잡으면 성능이 좋아지나요?"

이게 클라우드만의 독특한 규칙입니다. 보통 내 컴퓨터는 SSD를 사면 속도가 정해져 있죠? 하지만 클라우드는 **"네가 땅(용량)을 많이 사면, 그 땅에 들어오는 길(IOPS)도 더 넓게 만들어줄게"**라는 정책을 씁니다.

10GB 사면: 톨게이트 1개만 열어줌 (느림)
100GB 사면: 톨게이트 10개 열어줌 (빠름)

서버리스(Cloud Function)의 함정: "서버리스로 구축했다"는 말이 전문적으로 보일 수 있지만, 호출 횟수가 적을 때만 합리적입니다. 호출이 빈번한데 서버리스를 쓰면 오히려 비용 폭탄을 맞을 수 있으므로 상황에 맞게 제안해야 한다고 조언했습니다.

서버리스: '쓴 만큼만 내는' 방식이다.
- 조금만 쓸 때는 최고(효율적)!
- 너무 많이 쓰면 지옥(비용 폭탄)!
- 그래서 **"우리 서비스가 얼마나 자주 호출될지"**를 먼저 계산해보고 도입해야 합니다.

2. 네트워크 서비스 및 연결 방식의 디테일

DNS (Global DNS):
- 가비아 등 호스팅 업체에서 산 도메인을 네이버 클라우드 네임서버로 변경하여 등록 및 관리 가능.

가비아(Gabia)는 '도메인 편의점'입니다.

우리가 인터넷 주소인 www.naver.com이나 www.daum.net 같은 도메인 이름을 갖고 싶을 때, 국가 기관에 직접 가서 살 순 없잖아요? 그래서 그걸 대신 팔아주고 관리해주는 대행업체들이 있는데, 한국에서 가장 유명한 곳이 바로 가비아나 후이즈 같은 곳입니다.

가비아에서 하는 일: "이 주소(도메인) 주인은 나야!"라고 선언하고 돈을 내서 소유권을 가져오는 곳입니다.

가비아(도메인 가게): www.my-start-up.com이라는 주소를 1년에 2만 원 주고 삽니다. (소유권 획득)
네이버 클라우드(Global DNS): "나 가비아에서 주소 사 왔는데, 네가 관리 좀 해줘"라고 등록합니다. 그러면 네이버가 **"그래, 그럼 가비아에 가서 우리 네임서버 주소(예: ns1.ncloud.com)를 적어두고 와"**라고 알려줍니다.
다시 가비아: 도메인 관리 페이지에 들어가서, 기존 가비아 네임서버를 지우고 네이버가 알려준 주소로 바꿔 적습니다.
결과: 이제 전 세계 사람들이 www.my-start-up.com을 주소창에 치면 -> 가비아를 거쳐 -> 네이버 클라우드 네임서버에 물어보고 -> 내 서버로 찾아오게 됩니다.

CDN: 아까 설명한 대로 콘텐츠 전송 최적화 서비스.
IPsec VPN (Site-to-Site):
- 개념: 클라우드와 외부(공공기관, 공단 등)를 암호화된 통로로 연결.
- 비유: 바닥의 사각형 칸(사이트)과 다른 사이트를 연결하는 것.
- 사이트 투 사이트 vs 포인트 투 포인트: 포인트는 특정 서버 간 다이렉트 연결, 사이트는 VPC/서브넷 전체 대역 간의 연결.
VPC 피어링 (Peering):
- VPC끼리 통신하게 해주는 서비스.
- 보안 차이: IPsec VPN은 장비에서 암호화 처리를 하지만, VPC 피어링은 단순 네트워크 연결이므로 암호화가 안 됨. 용도에 맞게 선택해야 함.
NAT 게이트웨이 (NAT Gateway):
- 필요성: 프라이빗 서브넷(인터넷 안 됨)에 있는 서버도 라이브러리(Spring Boot 등)를 다운받으려면 외부로 나가야 함.
- 작동: 프라이빗 서버가 나트 게이트웨이의 공인 IP를 빌려 밖으로 나감. 외부 서버 입장에서는 나트 게이트웨이 IP만 찍힘.

3. 사설 IP 대역 및 NCP 규칙 (시험 단골)

RFC 1918 사설 IP 대역 (NCA 시험 문제 사례):
- A클래스: 10.0.0.0/8
- B클래스: 172.16.0.0/12
- C클래스: 192.168.0.0/16

1. 원래 배우신 것 (클래스 기본형)

네트워크 수업 시간에 배우신 건 공인 IP를 포함한 전체 주소 체계의 기준입니다.

Class A: 0~127로 시작 (기본 마스크 /8)
Class B: 128~191로 시작 (기본 마스크 /16)
Class C: 192~223로 시작 (기본 마스크 /24)

2. 지금 보시는 것 (사설 IP 전용 대역)

인터넷 세상에서 "우리끼리 집 안에서만 쓸 주소(사설 IP)를 따로 떼어놓자!"라고 약속한 범위가 있는데, 이게 RFC 1918 규정입니다. 여기서 숫자가 살짝 비틀립니다.

① A클래스: 10.0.0.0/8 (똑같음)

범위: 10.0.0.0 ~ 10.255.255.255
이건 배우신 대로 딱 /8만큼 떼어줬습니다. 아주 넓죠.

② B클래스: 172.16.0.0/12 (이게 왜 /12?)

배우신 대로라면: 172.16.0.0/16이어야 합니다.
실제 약속: 사설 IP로 쓰라고 준 범위가 172.16.0.0부터 172.31.255.255까지입니다.
172.16.x.x 하나만 준 게 아니라, 16번부터 31번까지 총 16개의 B클래스 대역을 통째로 묶어서 사설 IP용으로 준 겁니다.
이 16개를 하나로 묶어서 표현하려다 보니, 비트 계산상 /16에서 4비트를 앞으로 당긴 **/12**가 된 것입니다.

③ C클래스: 192.168.0.0/16 (이건 또 왜 /16?)

배우신 대로라면: 192.168.0.0/24여야 합니다. (예: 우리 집 공유기 192.168.0.1)
실제 약속: 사설 IP로 192.168.0.0부터 192.168.255.255까지 다 쓰라고 줬습니다.
즉, 192.168.0.x 한 구역만 주는 게 아니라 192.168.1.x, 192.168.2.x ... 해서 255번까지 다 준 거죠.
이걸 통째로 표현하니까 /24가 아니라 **/16**이 되는 겁니다.

NCP 서브넷 제약:
- 최소 /28(IP 16개)에서 최대 /16까지 생성 가능.
- 사소한 팁: 사설 IP 할당 시 6번부터 시작함. 이유: 네이버 클라우드에서 앞의 0~5번 IP를 네트워크 대표 주소, 브로드캐스트, DNS 등 부가 기능용으로 미리 점유(예약)하기 때문.

4. ACG vs NaCl (보안의 핵심 차이점)

ACG (Access Control Group):
- 위치: 서버(NIC) 단위.
- 특징: 스테이트풀(Stateful). 들어오는 문(인바운드)만 열어주면 나가는 문(아웃바운드)은 상태를 기억해 자동으로 허용됨.
NaCl (Network ACL):
- 위치: 서브넷 단위. (서브넷 내 모든 서버에 적용)
- 특징: 스테이트리스(Stateless). 들어오는 문과 나가는 문을 둘 다 수동으로 설정해야 함. 안 그러면 들어왔다가 응답을 못 나가서 서비스가 죽은 것처럼 보임.
- 우선순위: 1~200번 숫자가 있으며 낮은 숫자가 먼저 적용됨. 특정 국가(예: 중국) IP 대역만 골라 막고 싶을 때 매우 유용함.
실무 팁: NaCl은 복잡해서 실무에서는 ACG를 주로 사용하고, 특수한 대역 차단이 필요할 때만 NaCl을 섞어 씀.

5. 로드 밸런서 (Load Balancer) - L4 vs L7

ALB (Application Load Balancer - L7):
- 스마트한 분기: HTTP/HTTPS 헤더를 보고 도메인(web1.cloud.co.kr, web2...)이나 경로(/img, /data)별로 서버를 나눠 보낼 수 있음.
- IP 확인: 클라이언트 IP가 헤더(X-Forwarded-For)에 담겨서 들어옴.
NLB (Network Load Balancer - L4):
- 고성능: TCP/UDP 포트 기반 분산. 단순하고 빠름.
- IP 확인: 클라이언트 IP가 서버에 다이렉트로 찍힘.

6. 실습: 서버 접속 및 ACG 설정 디테일

관리자 비밀번호 확인:
- '서버 관리 및 설정 변경' -> '관리자 비밀번호 확인' 클릭.
- 아까 저장한 인증 키(PEM 파일)를 넣어 비밀번호를 획득. (메모장에 잠시 복사해둘 것)
ACG 규칙 추가 (매우 중요):
- 상황: 서버 생성 시 스크립트로 SSH 포트를 2200번으로 바꿨으나, 방화벽(ACG)에서 2200번을 안 열어주면 접속 불가.
- 방법: ACG 설정에서 TCP 2200번 포트 추가.
- 보안 설정: 소스에 0.0.0.0/0을 넣으면 어디서든 접속 가능하지만 위험함. 'myIP' 기능을 누르면 현재 내가 앉아 있는 자리의 IP만 등록되어 안전함. (카페 등 외부에서 하려면 다시 설정해야 함)
접속 명령어 (CMD/터미널):
- ssh -p 2200 root@[공인IP]
- 처음 접속 시 yes 입력 필수.
- 패스워드 입력 팁: 리눅스 패스워드는 입력 시 화면에 아무것도 안 보이는 것이 정상임. (보안상의 이유)
- 복사/붙여넣기 단축키: CMD 창에서 Ctrl+V가 안 될 때는 **Shift + Insert**를 사용할 것. 복사는 Ctrl + Insert.

7. 기타 강사 코멘트 및 환경

SSL VPN: 에이전트 설치 시 집이나 스타벅스에서도 사설 IP를 할당받아 서버 작업이 가능함. 보안적으로 매우 우수함.

1. 리눅스 환경 제어 및 기초 팁

화면 정리: clear 명령어를 치거나, 단축키 **Ctrl + L**을 사용하면 화면이 깔끔하게 정리됨.
명령어 이력 찾기: 키보드 방향키 위(↑) 버튼을 누르면 이전에 사용했던 명령어들을 순서대로 빠르게 조회할 수 있음.
히스토리 활용 (강사 팁): history 명령어를 입력하면 지금까지 썼던 명령어 리스트와 번호가 나옴. 번호를 이용해 재실행도 가능함.
커서 이동 및 삭제 단축키 (고급 팁):
- Ctrl + A: 커서를 줄 맨 앞으로 이동. (앞부분만 수정하고 싶을 때 유용)
- Ctrl + K: 커서 위치부터 줄 끝까지 모두 삭제.
- 예: 긴 명령어를 치다가 앞만 바꾸고 싶을 때 Ctrl + A로 이동 후 Ctrl + K로 지우고 새로 입력.

2. 주요 리눅스 명령어 실습 (약 20분간 진행)

man (Manual): 명령어의 사용 설명서를 보여줌. (예: man ls). 빠져나올 때는 **q**를 누름.
ls (List): 디렉토리/파일 목록 확인.
- -a: 숨겨진 파일(점 .으로 시작하는 파일)까지 모두 표시. 보안 설정 파일들은 주로 숨겨져 있음.
- -l: 상세 정보(권한, 소유주, 그룹) 표시. 보안 관리 시 특정 계정의 읽기/쓰기/실행 권한을 확인할 때 필수임.
mkdir (Make Directory): 폴더 생성.
- -p: 하위 폴더까지 한 번에 생성 (예: mkdir -p dir3/web/image). 업무 자동화 스크립트 짤 때 유용함.
cd (Change Directory): 경로 이동.
- cd ~ (또는 cd만 입력): 최초 홈 디렉토리로 이동.
- cd ..: 상위 폴더로 이동.
- cd .: 현재 폴더를 의미. 스크립트 실행 시 ./script.sh 형태로 사용.
pwd (Print Working Directory): 현재 위치한 절대 경로 표시. 자바(Java) 설정 등에서 경로 참조 시 복사해서 쓰기 좋음.
touch: 내용이 없는 빈 파일 생성.
rm (Remove): 파일 삭제.
- -r: 디렉토리 삭제.
- -rf: 묻지도 따지지도 않고 강제 삭제. 복구가 불가능하므로 매우 주의해서 사용해야 함.
cp (Copy): 복사. 디렉토리 복사 시에는 -r 옵션 필요.
mv (Move): 파일 이동 또는 이름 변경.
cat (Concatenate): 파일 내용 보기.
- 보안 팁: 중요한 설정(Config) 파일을 볼 때 vi로 열면 실수로 내용을 수정할 위험이 있으므로, 내용만 확인하고 싶을 때는 cat을 쓰는 것이 안전함.
head / tail: 파일의 상위/하위 내용만 보기. (기본 10줄, -n 5 식으로 줄 수 지정 가능). 로그 파일 확인할 때 유용함.
more: 파일 내용을 페이지 단위로 끊어서 보기.
file: 해당 파일이 텍스트인지, 이미지인지, 인코딩 방식(UTF-8 등)은 무엇인지 종류를 확인.

3. VI / VIM 에디터 실습

모드 이해: 입력 모드(Insert), 명령 모드(Command), 라인 모드(Line)로 나뉨.
실습 순서:
1. vi filename으로 열기.
2. i 또는 **a**를 눌러 인서트(Insert) 모드 진입 후 내용 입력.
3. **Esc**를 눌러 명령 모드로 복귀.
4. **: (콜론)**을 눌러 라인 모드 진입.
저장 및 종료:
- :wq: 저장하고 종료.
- :q!: 저장하지 않고 강제 종료.
- :wq!: 강제 저장 후 종료.
주요 기능:
- :set nu (또는 set number): 줄 번호 표시. 협업 시 "몇 번째 줄 수정해라"고 소통할 때 필수.
- /검색어: 내용 검색. 검색 후 **n**을 누르면 다음 검색어로 이동, **Shift + N**은 이전 검색어로 이동.

4. 네이버 클라우드 실무: 서버 이미지 생성

개념: 현재까지 설정된 서버의 상태(OS, 설치 프로그램, 설정값)를 통째로 '스냅샷' 찍듯 저장하는 것. 나중에 이 이미지를 복제해서 똑같은 서버를 여러 대 만들 수 있음.
생성 절차:
1. 콘솔 -> 서버 선택 -> '서버 관리 및 설정 변경' -> '내 서버 이미지 생성'.
2. 이름 규칙 (실무 팁): 서버명-날짜(YYMMDD) 형태로 지을 것 (예: web-svr-001-260205). 서비스가 계속 업데이트되므로 생성 시점을 명확히 해야 관리하기 쉬움.
3. 스토리지 변경: 이미지 생성 시점에 스토리지 용량을 늘려 저장하는 것도 가능함.
4. 확인: 서버 메뉴 옆 '서버 이미지' 항목에서 '생성 중' 상태를 확인 가능.
주의: 이미지 생성 중에는 서버 설정 변경이 제한될 수 있음.

1. 프라이빗 서브넷(Private Subnet) 생성

목적: 외부 인터넷과 직접 연결되지 않는 격리된 네트워크 환경을 조성하여 보안을 강화함.
절차:
1. VPC -> Subnet Management -> '서버넷 생성'.
2. 이름: lab-web-pri-subnet (프라이빗임을 명시).
3. IP 주소 범위: 10.0.20.0/24.
4. 가용구역: KR-2.
5. 인터넷 게이트웨이 전용 여부: 반드시 'Private' 선택 (가장 중요).
6. 용도: 일반.

2. 서버 이미지를 활용한 서버 생성 (SVR 2)

절차:
1. Server -> '서버 이미지' 메뉴 진입.
2. 아까 생성한 이미지(web-svr-001-날짜) 선택 후 '서버 생성'.
3. VPC 선택 후 서브넷을 방금 만든 '프라이빗 서브넷'(10.0.20.0/24)으로 지정.
4. 스펙: 하이 CPU 2코어/4GB.
5. 이름: lab-web-svr-002.
6. 스크립트: '포트 체인지 스크립트(2200번)' 선택.
7. 특이사항: 프라이빗 서브넷이므로 '공인 IP 할당' 항목이 비활성화됨.
8. 인증 키 및 ACG: 기존 것(웹 ACG, 디폴트 ACG)과 동일하게 설정.

3. 웹 서버(Nginx) 설치 및 ACG 실습 (SVR 1)

Nginx 설치 명령어:
- yum install -y nginx
- systemctl start nginx (서비스 시작)
- systemctl enable nginx (재부팅 시 자동 실행)
- systemctl status nginx (상태 확인 - Active: running)
웹 접속 확인 및 ACG 보안:
1. 서버 내부 확인: curl localhost.
2. 외부 브라우저 확인: 공인 IP 입력 (최초 접속 실패).
3. 원인 및 해결: 웹 ACG에서 80번 포트가 닫혀 있음. ACG 설정에서 0.0.0.0/0(모두 허용) 또는 myIP를 소스로 하여 80번 포트를 추가해야 접속 가능함.
4. 보안 팁: 스마트폰(LTE/5G)으로 접속 테스트 시 myIP로 설정하면 접속이 안 되는 것을 통해 접근 제어의 동작을 확인할 수 있음.

4. 실무형 아키텍처 및 보안 강화 (LB 활용)

기존 방식: 웹 서버를 퍼블릭에 두고 직접 노출.
클라우드 권장 방식: 웹 서버도 프라이빗 서브넷에 숨기고, 앞단에 **로드 밸런서(LB)**를 배치함.
보안 원리:
- LB가 443(HTTPS) 포트로 요청을 받아 복호화한 후, 웹 서버에는 80(HTTP) 포트로 전달.
- 웹 서버 ACG에는 'LB 서브넷'만 소스로 등록하여 외부의 직접적인 공격을 차단함.

5. 프라이빗 서버(SVR 2) 접속 방법: 바스티온 호스트

문제: 프라이빗 서버는 공인 IP가 없어 집이나 외부에서 직접 SSH 접속이 불가능함.
해결 방법 (바스티온/점프 서버):
1. 먼저 퍼블릭 서버(SVR 1)에 접속함.
2. SVR 1에서 사설 IP를 통해 SVR 2로 다시 접속함.
ACG 설정: SVR 2의 ACG에 SVR 1의 사설 IP(10.0.10.6)로부터 2200번 포트 접근을 허용해야 함.
명령어: ssh -p 2200 root@10.0.20.6 (사설 IP 주소 사용).

6. NAT 게이트웨이(NAT Gateway) 구축

문제: 프라이빗 서버는 외부에서 들어올 수도 없지만, 스스로 밖으로 나갈 수도 없음(ping 8.8.8.8 실패). 이로 인해 yum install 등이 불가능함.
NAT 게이트웨이 생성 절차:
1. 전용 서브넷 생성: 이름 lab-gw-sub, 대역 10.0.200.0/24, Public, 용도 'NAT 게이트웨이'.
2. 나트 게이트웨이 생성: 유형 '공인'(외부 통신용).
라우트 테이블(Route Table) 설정:
1. 프라이빗 라우트 테이블 선택 -> '라우트 설정'.
2. Destination: 0.0.0.0/0 (모든 외부행).
3. Target Type: NAT Gateway.
4. Target Name: 생성한 나트 게이트웨이 선택.
확인: 설정 후 SVR 2에서 ping 8.8.8.8이 성공하고 yum install -y nginx가 가능해짐.

7. IP 확인을 통한 NAT 동작 검증

SVR 1 (Public): curl https://find-ip.me 호출 시 서버 본인의 공인 IP가 찍힘.
SVR 2 (Private): 동일 명령어 호출 시 본인의 공인 IP가 없으므로 NAT 게이트웨이의 공인 IP가 찍힘. 이를 통해 나트 게이트웨이를 타고 나간다는 것을 실증함.

8. 기타 실무 지식

사설 나트(Private NAT): IP 대역이 겹치는 두 환경을 연결할 때 IP를 변조하여 통신하게 함. 보안상 사설 IP를 숨기기 위해 쓰기도 함.
서버 접속 콘솔: 네이버 클라우드 대시보드에서 제공하는 기능. 패스워드 복사/붙여넣기가 안 되어 불편하지만, 네트워크 장애 시 최후의 수단으로 로그를 확인할 때 사용함.
다음 실습 예고: SSL VPN 에이전트를 설치하여 바스티온 없이 프라이빗 서버에 직접 접근하는 방법을 배울 예정.

1. NAT 게이트웨이의 상세 동작 원리와 비유

IP 변환의 역할: 사설 IP(예: 10.0.20.6)는 그 자체로 인터넷 통신이 불가능함. NAT 게이트웨이는 이 사설 IP를 외부 통신이 가능한 **'공인 IP'**로 변환하여 전송함.
라우팅(Routing)의 중요성:
- 단순히 NAT 게이트웨이를 만든다고 인터넷이 되는 것이 아님.
- 비유: 목적지(0.0.0.0/0)로 가려면 반드시 NAT 게이트웨이라는 '통로'를 거쳐가라고 길(경로)을 지정해줘야 함. 이것이 라우트 테이블 설정임.
IP 충돌(Collision) 해결:
- 두 회사가 똑같은 사설 대역(10.0.0.0/24)을 쓰고 있다면 서로 통신이 안 됨. (어디가 어딘지 모르기 때문)
- 이때 NAT 게이트웨이를 이용해 출발지 IP를 다른 대역(예: 192.168.0.6)으로 변조(SNAT)하여 보내면 충돌 없이 통신할 수 있음. 하지만 설정이 복잡하므로 가급적 대역을 다르게 설계하는 것이 최선임.

2. SSL VPN 사용자 설정 및 에이전트 설치

사용자 계정 생성:
- SSL VPN 메뉴 -> '사용자 설정'.
- ID, 비밀번호, 이메일, 휴대폰 번호 입력. (분실 시 삭제 후 재생성 또는 수정 가능)
에이전트(Agent) 설치:
- 가이드에 제공된 URL(빅아이피, BIG-IP Edge Client)에서 본인 OS(윈도우/맥)에 맞는 파일 다운로드.
접속 정보 입력:
- 에이전트 실행 후 '서버 선택'에 NCP 대시보드에 나온 접속 URL(https://sslvpn-kr-vpc-01.ncloud.com 등) 입력.
2차 인증(2FA):
- 로그인 시 등록한 휴대폰/이메일로 인증번호 전송 및 입력 필수. (보안 강화)
주의 사항: 맥(Mac) 버전은 환경이나 칩셋(M1/M2 등)에 따라 에이전트 작동이 원활하지 않을 수 있음. 그럴 경우 윈도우 가상 머신 등을 활용해야 함.

3. SSL VPN 네트워크 통합 (라우팅 및 ACG)

VPN만 연결했다고 바로 서버에 접속되는 것이 아님. 아래의 '마지막 퍼즐'을 맞춰야 함.

VPN IP 풀(Pool) 확인:
- 내 로컬 PC에서 ipconfig /all 입력.
- NCP SSL VPN에서 할당받은 가상 IP(예: 172.16.0.3) 확인. (보통 172.16.0.0/20 또는 /23 대역)
라우트 테이블 설정 (매우 중요):
- VPC -> Route Table -> 프라이빗/퍼블릭 테이블 모두 설정.
- Destination: SSL VPN의 IP 풀(172.16.0.0/23).
- Target Type: SSL VPN.
- 이유: 서버가 응답을 줄 때 "아, 이 IP(VPN 사용자)는 SSL VPN 통로로 돌려보내야 하는구나"라고 알 수 있게 경로를 지정하는 것임.
ACG 설정:
- 디폴트 ACG/웹 ACG 설정 진입.
- 포트: 2200(SSH용), 80(웹용).
- 허용 소스: SSL VPN의 IP 풀(172.16.0.0/23).
- 이제 바스티온 서버를 거치지 않고, 로컬 PC에서 프라이빗 서버의 사설 IP(10.0.20.6)로 다이렉트 SSH 접속 및 웹 브라우저 접속이 가능해짐.

4. 실무적 활용 사례: 인트라넷(Intranet)

외부에서는 절대 접근할 수 없고, 회사 내부망이나 SSL VPN을 통해서만 접근 가능한 웹 페이지(예: 국토부 관리 페이지, 기업 기밀 정보망).
이러한 시스템은 서버 자체를 프라이빗 서브넷에 숨기고, 인증된 사용자만 VPN을 통해 들어오도록 설계하여 보안을 극대화함.

5. 1일 차 과제: 패스워드 없는 SSH 접속 (Key-based Auth)

문제 제기: 매번 패스워드를 입력하는 것은 번거로울 뿐 아니라 '키로거' 등에 의해 유출될 위험이 있음.
과제 내용:
1. 패스워드 입력 없이 **PEM 키(프라이빗 키)**만으로 서버에 즉시 로그인되도록 설정할 것.
2. 프라이빗 서브넷 서버(10.0.20.6)와 퍼블릭 서버(10.0.10.6) 모두 적용 시도.
강사의 힌트:
- 비대칭 키 암호화 방식 활용.
- 서버에 **퍼블릭 키(Public Key)**를 등록하고, 내 PC의 **프라이빗 키(Private Key)**로 인증하는 원리.
- SSL VPN 환경을 먼저 구축해야 프라이빗 서버에 테스트 가능함. (안 되면 퍼블릭 서버로 테스트)
당부: 내일까지 해결하지 못해도 상관없으나, 보안 실무에서 매우 중요한 개념이니 꼭 시도해볼 것.

6. 사소한 팁 및 기타

단축키: 리눅스 터미널에서 Ctrl + A(맨 앞으로), Ctrl + K(커서 이후 삭제) 등 활용 권장.
과정 관리: 실습이 끝나면 서버를 '정지'하여 불필요한 비용 발생을 방지할 것.

1. SSL VPN의 물리적 정체: "가상 랜선(Virtual NIC)"

지금까지 우리는 네이버 서버에 **공인 IP(Public IP)**를 붙여서 인터넷에 노출시켰습니다. 하지만 SSL VPN을 쓰면 서버에서 공인 IP를 아예 떼어버릴 수 있습니다.

동작 원리: 여러분의 학교 PC에 **VPN 에이전트(프로그램)**를 설치하고 실행하죠? 그 순간, 여러분의 컴퓨터 운영체제(OS)에는 **가상의 랜카드(가상 NIC)**가 하나 더 생깁니다.
물리적 연결: 이 가상 랜카드는 인터넷을 타고 네이버 클라우드 안에 있는 **'SSL VPN 게이트웨이(입구)'**와 암호화된 터널로 연결됩니다.
결과: 이제 여러분의 학교 PC는 **네이버 클라우드 내부 네트워크(VPC)**에 직접 랜선을 꽂은 것과 똑같은 상태가 됩니다.

2. 왜 "SSL" VPN인가? (학교 방화벽을 속이는 법)

아까 학교 방화벽이 22번 포트를 막았다고 했죠? 그런데 학교 방화벽도 절대로 못 막는 포트가 있습니다. 바로 **443번(HTTPS)**입니다. 이걸 막으면 아무도 네이버, 구글 검색을 못 하니까요.

SSL VPN의 전략: VPN 에이전트는 모든 데이터를 HTTPS(443번 포트) 패킷으로 감쌉니다.
학교 방화벽의 시선: "음, 443번 포트네? 평범한 웹 서핑인가 보군. 통과!"
현실: 그 HTTPS 패킷 안에는 사실 서버로 보내는 SSH 데이터가 숨겨져 있습니다.

3. SSH 접속 방식이 어떻게 달라지나?

지금까지와 SSL VPN을 썼을 때의 접속 명령어를 비교해 보세요.

구분	일반 접속 (지금까지 한 것)	SSL VPN 접속 (앞으로 할 것)
목적지 IP	공인 IP (인터넷 주소)	사설 IP (10.0.0.6 같은 내부 주소)
포트 번호	2200번 (우회 포트)	22번 (표준 포트 그대로 사용 가능!)
통로	인터넷 광장 (누구나 볼 수 있음)	전용 터널 (누구도 볼 수 없음)

왜 VPN을 쓰면 22번 포트를 그대로 쓸 수 있나요?
이미 VPN 터널을 통해 "네이버 클라우드 내부"로 들어와 있기 때문입니다. 학교 방화벽은 이미 통과했고, 내부망끼리의 통신이므로 굳이 2200번으로 숨길 필요가 없어진 것입니다.

4. ACG와의 관계 (보안 강화)

SSL VPN을 쓰면 ACG(가상 방화벽) 설정을 더 빡빡하게 할 수 있습니다.

기존: "인터넷 세상(0.0.0.0/0)에 있는 누구든 2200번으로 오면 들여보내 줘."
VPN 사용: "인터넷은 다 차단해! 오직 **SSL VPN 터널을 타고 들어오는 우리 직원(가상 IP)**만 22번 포트로 들어오게 해줘."

이렇게 되면 해커는 서버의 IP를 알아도 아예 접근할 문(Port) 자체가 안 보여서 공격 시도조차 못 하게 됩니다.

5. 요약: 물리적 데이터 흐름

에이전트 실행: 학교 PC OS에 172.16.x.x 같은 가상 IP가 부여됨. (가상 랜카드 장착)
데이터 전송: 여러분이 ssh 10.0.0.6 (서버 사설 IP)을 칩니다.
암호화: VPN 에이전트가 이 패킷을 443번(웹 포트) 데이터로 감싸서 네이버로 쏩니다.
통과: 학교 방화벽은 "웹 트래픽이네" 하고 허가합니다.
도착: 네이버 클라우드 VPN 게이트웨이가 패킷을 받아 껍데기(443)를 벗기고 순수한 SSH 데이터를 꺼냅니다.
배달: 클라우드 내부망을 타고 서버의 22번 포트로 안전하게 배달됩니다.

한마디로: SSL VPN은 학교 방화벽을 우아하게 통과하면서, 서버를 인터넷의 위협으로부터 완전히 숨겨주는 암호화된 전용 통로입니다. 강사님이 "이게 훨씬 안전하다"고 하신 이유가 바로 이것입니다!

1. 패킷의 이중 구조 (Encapsulation)

SSL VPN을 사용하면 하나의 데이터가 두 개의 패킷으로 감싸집니다.

① 내부 패킷 (실제 데이터)

출발지 IP: 172.16.0.5 (VPN 에이전트가 부여받은 가상 IP)
목적지 IP: 10.0.20.6 (네이버 서버의 사설 IP)
이 패킷은 학교 네트워크에서는 길을 찾을 수 없는 주소들입니다. 그래서 이 상태로는 밖으로 나갈 수 없습니다.

② 외부 패킷 (운송용 패킷)

출발지 IP: 학교 내부 PC의 실제 IP (예: 210.x.x.x)
목적지 IP: 네이버 SSL VPN 게이트웨이의 공인 IP
포트 번호: TCP 443 (HTTPS)
학교 방화벽은 이 **'외부 패킷'**만 봅니다. 목적지가 네이버 클라우드이고 포트가 443(웹)이므로 정상적인 웹 통신으로 판단하고 통과시킵니다.

2. 가상 NIC(랜카드)와 운영체제의 동작

"애초에 IP가 있어야 한다"는 부분은 이렇게 해결됩니다.

가상 인터페이스 생성: SSL VPN 에이전트를 실행하면, 리눅스나 윈도우 커널에 **'Virtual NIC'**이라는 가상 장치가 생성됩니다.
IP 할당: 네이버 클라우드 VPN 서버가 이 가상 장치에 **사설 IP(예: 172.16.0.5)**를 부여합니다.
라우팅 테이블 조작: 에이전트는 운영체제의 **라우팅 테이블(경로 장부)**에 다음과 같은 규칙을 추가합니다.
- "목적지가 10.0.0.0 대역(네이버 서버)이라면, 실제 랜선으로 보내지 말고 가상 인터페이스로 보내라."

3. 물리적 데이터 흐름 (Step-by-Step)

사용자가 학교 PC에서 ssh 10.0.20.6 명령을 입력했을 때의 물리적 과정입니다.

애플리케이션 계층: SSH 접속 요청 데이터가 생성됩니다.
전송 계층: TCP 헤더가 붙습니다 (목적지 포트 22).
네트워크 계층 (내부 패킷): 목적지 IP를 10.0.20.6으로 설정합니다.
커널의 판단: 라우팅 테이블을 확인하니 이 IP는 '가상 인터페이스'로 가야 합니다. 패킷이 가상 인터페이스로 전달됩니다.
VPN 에이전트의 가공 (터널링): 가상 인터페이스에 도착한 패킷 전체를 통째로 암호화한 뒤, 다시 새로운 패킷(외부 패킷) 안에 집어넣습니다.
- 이때 외부 패킷의 목적지는 네이버 VPN 게이트웨이의 공인 IP가 됩니다.
물리적 전송: 이제 이 패킷은 실제 랜카드를 통해 학교 밖으로 나갑니다. 학교 방화벽은 443번 포트 트래픽이므로 통과시킵니다.
VPN 게이트웨이 도착: 네이버 클라우드 입구에 있는 VPN 장비가 이 패킷을 받습니다.
복호화 및 추출: 장비가 겉껍데기(외부 패킷)를 벗기고 암호화를 풉니다. 그러면 그 안에 들어있던 **'내부 패킷(목적지 10.0.20.6)'**이 나타납니다.
내부 배달: 이 패킷은 이제 네이버 클라우드 내부 네트워크(VPC)를 타고 10.0.20.6 서버로 배달됩니다.

4. 왜 이게 가능하고 안전한가?

가능한 이유: TCP/IP 프로토콜은 데이터 부분에 무엇이 들어있든 상관하지 않습니다. **"패킷 안에 패킷을 넣는 것(Tunneling)"**이 기술적으로 허용되기 때문입니다.
안전한 이유: 학교 경비원(방화벽)은 겉봉투(외부 패킷)만 볼 수 있고, 그 안에 무엇이 들어있는지(내부 패킷)는 암호화되어 있어 절대 알 수 없습니다.
서버 보호: 서버(10.0.20.6)는 공인 IP가 없어도 됩니다. VPN 게이트웨이가 패킷을 안쪽에서 직접 전달해주기 때문에, 인터넷 세상에 노출되지 않고도 통신이 가능해집니다.

결론적으로: SSL VPN은 **기존의 IP(학교 IP)**를 이용해 **가짜 통로(외부 패킷)**를 만들고, 그 안으로 **진짜 데이터(내부 패킷)**를 암호화해서 숨겨 보내는 기술입니다. IP 주소가 두 세트가 쓰이기 때문에 가능한 일입니다.

1. 바스티온 호스트 (Bastion Host) - "보안 대문"

왜 필요한가요?
프라이빗 서브넷(사설망)에 있는 서버들은 인터넷과 단절되어 있어 해커가 공격할 수 없지만, 반대로 정상적인 관리자도 들어갈 방법이 없습니다. 이때 관리를 위해 잠시 거쳐가는 '검문소'가 바로 바스티온 호스트입니다.

작동 원리:
1. 바스티온 호스트는 퍼블릭 서브넷에 위치하며 공인 IP를 가집니다.
2. 관리자는 먼저 인터넷을 통해 바스티온 호스트로 SSH 접속을 합니다.
3. 바스티온 서버 안에서 다시 프라이빗 서버의 사설 IP로 접속(Jump)합니다.
보안상 장점:
- 모든 서버의 문(포트)을 열어둘 필요 없이, 바스티온 호스트 딱 한 대의 문만 잘 감시하면 됩니다.
- 누가 들어왔는지 로그를 한 곳에서 집중 관리할 수 있습니다.
비유: 아파트 단지(VPC) 내의 각 가정(프라이빗 서버)으로 바로 갈 수 없게 막아두고, **경비실(바스티온)**을 반드시 거쳐서 방문증을 끊고 들어가게 하는 것과 같습니다.

2. 로드 밸런서 (Load Balancer) - "트래픽 교통정리"

왜 필요한가요?
유명한 맛집에 손님이 몰리면 줄이 길어지고 서비스가 느려지죠? 서버도 마찬가지입니다. 한 대의 서버에 트래픽이 몰려 터지는 것을 막기 위해 여러 대의 서버로 일을 공평하게 나눠주는 장치입니다.

① L4 로드 밸런서 (네트워크 계층)

기준: IP 주소와 포트 번호만 보고 기계적으로 나눕니다.
특징:
- 데이터의 내용을 열어보지 않기 때문에 속도가 매우 빠르고 효율적입니다.
- 단순히 "80번 포트로 오면 1번 서버로 보내!" 식의 처리를 합니다.
비유: 은행 입구에서 번호표를 뽑아주는 기계입니다. 손님이 어떤 업무(내용)를 보러 왔는지 묻지 않고, 그냥 비어있는 창구로 순서대로 보냅니다.

② L7 로드 밸런서 (애플리케이션 계층)

기준: **데이터의 내용(URL, 쿠키, 이미지 요청 등)**을 보고 스마트하게 나눕니다.
특징:
- 패킷의 내용을 열어봐야 하므로 L4보다 조금 느릴 수 있지만 훨씬 정교합니다.
- 예: ncloud.com/image로 오면 이미지 전용 서버로 보내고, ncloud.com/pay로 오면 결제 전용 서버로 보내는 식입니다.
비유: 식당의 호스트(지배인)입니다. 예약 손님인지, 아이가 있는지, 고기를 구울 것인지를 물어보고 그에 딱 맞는 자리로 안내해 줍니다.

💡 보안 관점에서의 로드 밸런서 (중요!)

오늘 수업에서 **"LB를 앞단에 두면 보안이 강화된다"**고 했던 이유를 기억하시나요?

서버 은폐: 사용자는 로드 밸런서의 IP만 알 뿐, 그 뒤에 있는 실제 웹 서버들의 IP는 알 수 없습니다. (공격 대상이 숨겨짐)
공격 차단: L7 로드 밸런서는 비정상적인 URL 요청이나 악성 데이터를 내용 수준에서 1차적으로 걸러내는 방패 역할을 할 수 있습니다.

요약하자면:

바스티온: 관리자가 점검하러 들어갈 때 쓰는 보안 통로.
로드 밸런서: 사용자가 서비스를 이용하러 들어올 때 트래픽을 나눠주고 서버를 숨겨주는 장치.

로드밸런서(Load Balancer, LB)는 클라우드 인프라의 '입구'에서 교통정리를 하는 경찰관이라고 생각하면 가장 쉽습니다.

왜 입구에 두는지, 그리고 L4와 L7이 어떻게 다른지 아주 쉽게 풀어드릴게요.

1. 로드밸런서의 역할: "혼자 일하면 죽으니까요"

로드밸런서의 핵심 역할은 **부하 분산(Load Balancing)**입니다.

상황: 내 서비스가 대박이 나서 사용자가 10만 명으로 늘었습니다. 서버 1대로는 도저히 버틸 수 없어 서버를 3대로 늘렸습니다.
문제: 사용자가 www.my-web.com을 치고 들어올 때, 3대의 서버 중 어디로 가야 할까요? 사용자가 직접 고를 순 없잖아요?
해결: 입구에 로드밸런서를 세워둡니다. 사용자는 로드밸런서의 주소로만 접속하고, 로드밸런서가 "1번 너 한가하네? 여기 손님 받아", "2번 너는 좀 쉬어" 하면서 골고루 일을 나눠줍니다.

입구에 두면 좋은 점:

가용성 (Health Check): 1번 서버가 고장 나면 로드밸런서가 귀신같이 알고 손님을 2, 3번으로만 보냅니다. (사용자는 고장 난 줄도 모름)
확장성: 손님이 더 많아지면 서버를 10대로 늘리고 로드밸런서에 연결만 하면 됩니다.

2. L4(NLB) vs L7(ALB): "어디까지 보고 판단하는가?"

이 두 가지의 차이는 **"입구에서 손님의 요청을 얼마나 자세히 뜯어보느냐"**의 차이입니다.

① NLB (L4 - Network Load Balancer): "단순한 주차 요원"

판단 기준: IP 주소와 포트 번호(Port)만 봅니다.
비유: 주차장 입구에서 "승용차는 1층으로, 트럭은 2층으로 가세요"라고만 안내하는 요원입니다.
특징:
- 빠름: 내용은 안 보고 껍데기만 보고 보내니까 처리 속도가 엄청 빠릅니다. (대규모 트래픽에 유리)
- IP 확인: 손님의 얼굴(IP)을 그대로 서버에 전달합니다. 서버 로그를 찍어보면 손님의 진짜 IP가 바로 찍힙니다.

② ALB (L7 - Application Load Balancer): "꼼꼼한 리셉션 데스크"

판단 기준: HTTP 데이터 내용(URL, 헤더, 쿠키 등)을 다 뜯어봅니다.
비유: 호텔 로비에서 "식사하러 오셨나요? 식당은 2층입니다.", "숙박 손님인가요? 체크인 카운터로 가세요."라고 물어보고 안내하는 비서입니다.
특징:
- 스마트함: www.cloud.com/img로 들어오면 이미지 전용 서버로, /video로 들어오면 영상 전용 서버로 나눠 보낼 수 있습니다.
- IP 확인 (X-Forwarded-For): ALB는 자기가 직접 손님과 대화한 뒤 서버에 "대신 전해주는" 방식입니다. 그래서 서버가 로그를 찍으면 손님 IP가 아니라 로드밸런서 IP가 찍힙니다.
- 해결책: "진짜 손님 IP는 이거였어!"라고 봉투 뒷면에 적어주는데, 그게 바로 **X-Forwarded-For(XFF)**라는 헤더입니다.

3. 한눈에 비교

구분	NLB (L4)	ALB (L7)
비유	주차 요원 (빠르고 단순)	호텔 비서 (꼼꼼하고 똑똑)
보는 것	IP, 포트번호	URL 경로, 헤더, 쿠키
성능	매우 높음 (초당 수백만 건 가능)	중간 (내용을 읽어야 해서 NLB보단 느림)
주요 기능	단순 연결 전달	경로별 분기 (/api, /img 등)
손님 IP 확인	서버 로그에 바로 찍힘	XFF 헤더를 열어봐야 함

요약하자면!

로드밸런서 왜 쓰나요? 서버 여러 대를 효율적으로 써서 서비스가 안 죽게 하려고 씁니다.
NLB는 언제 쓰나요? 그냥 엄청나게 많은 데이터를 아주 빠르게 전달만 하면 될 때 씁니다.
ALB는 언제 쓰나요? 접속하는 주소(URL)에 따라 다른 서버로 보내주고 싶을 때, 즉 '스마트한 배달'이 필요할 때 씁니다.

이제 입구에 서 있는 이 '교통경찰'들의 차이가 좀 보이시나요? 90% 이상의 일반적인 웹 서비스에서는 똑똑한 **ALB(L7)**를 주로 사용한답니다!

1. NLB = Network Load Balancer

Network (네트워크): 컴퓨터들이 서로 데이터를 주고받는 통로, 즉 '망' 자체를 뜻합니다.
왜 L4인가? (Layer 4): OSI 7계층 중 4번째 층인 **전송 계층(Transport Layer)**에서 일하기 때문입니다.
하는 일: 데이터의 내용(편지 내용)은 안 보고, **보내는 사람 주소(IP)**와 **받는 문 번호(Port)**만 보고 기계적으로 배달합니다.
- 예: "1.2.3.4 주소에서 80번 포트로 왔네? 1번 서버로 가!"

2. ALB = Application Load Balancer

Application (애플리케이션/응용): 우리가 쓰는 '앱'이나 '웹 서비스' 그 자체를 뜻합니다.
왜 L7인가? (Layer 7): OSI 7계층 중 맨 꼭대기인 7번째 층, **응용 계층(Application Layer)**에서 일하기 때문입니다.
하는 일: 데이터의 내용(HTTP 편지 내용)을 실제로 읽습니다. 누가 보냈는지뿐만 아니라, 무슨 내용을 요청했는지까지 보고 판단합니다.
- 예: "오, 편지를 뜯어보니 /login 페이지를 보여달라고 하네? 이건 로그인 전용 서버로 가!"

'25~26 겨울방학 > 클라우드 보안' 카테고리의 다른 글

🔒클라우드 보안) 시험준비(2)(26.02.10) (0)	2026.02.10
클라우드 보안)vpc (0)	2026.02.07
클라우드 보안) ssh 이해 (0)	2026.02.07
클라우드 보안) 26.02.06 (0)	2026.02.06
클라우드 보안) 26.02.05(용어) (0)	2026.02.06

현재글클라우드 보안) 26.02.05

kimchangmin02 님의 블로그

kimchangmin02 님의 블로그 입니다.

마인크래프트 모드, 개발일지, 포지 모딩, 자바, 포지, 몹 만들기, 게임 개발, 마인크래프트모딩, 모딩 강좌, 커스텀 몹, Java, Forge, 게임개발, 마인크래프트, Ai, 1.18.2, 몹 ai, 모드 개발, 주민 ai, 마인크래프트 모딩,

Today :
Yesterday :

« 2026/04 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30