[1부] CS 과제 공부하기

오늘은 회사에서 CS 학습 과제로 총 9가지 주제를 정리해보려고 한다.
이 중 일부는 이전에 작성한 글이 있어, 해당 내용은 기존 글 링크로 대체한다.

1. WebServer vs WAS 

https://balhae.tistory.com/312

Web Server와 WAS의 차이와 웹 서비스 구조

 

2. Get과 Post의 차이점

2-1. 기본 개념 차이

GET 메서드

• 서버로부터 데이터를 조회(읽기)할 때 사용
• 요청 파라미터가 URL에 노출됨
• 예: https://example.com/search?keyword=보안&page=1

POST 메서드

• 서버에 데이터를 전송하여 리소스를 생성/수정할 때 사용
• 요청 파라미터가 HTTP Body에 포함됨
• URL에는 파라미터가 노출되지 않음

---

2-2. 주요 차이점 비교표

구분	GET	POST
데이터 위치	URL 쿼리스트링	HTTP Request Body
URL 예시	/user?id=123&name=홍길동	/user
데이터 길이	제한 있음 (보통 2KB)	제한 없음 (서버 설정에 따라)
캐싱	가능 (브라우저 캐시)	불가능
북마크	가능	불가능
브라우저 히스토리	저장됨	저장 안 됨
뒤로가기	안전함	재전송 확인 필요
보안성	낮음	상대적으로 높음
멱등성	있음 (여러 번 호출해도 결과 동일)	없음
용도	조회, 검색	생성, 수정, 삭제, 로그인

---

2-3. 보안적 관점에서의 차이

2-3.1 GET의 보안 취약점

① URL 노출로 인한 정보 유출

# 로그인을 GET으로 처리하는 잘못된 예
GET /login?username=admin&password=1234

문제점:
✗ 브라우저 히스토리에 저장
✗ 서버 로그에 기록
✗ 프록시 서버 로그에 남음
✗ Referer 헤더를 통해 다른 사이트로 전송될 수 있음

 

② 서버 로그 파일 노출

# Apache 액세스 로그 예시
192.168.1.100 - - [21/Jan/2026:10:30:45] "GET /login?id=admin&pw=secret123 HTTP/1.1" 200
192.168.1.101 - - [21/Jan/2026:10:31:20] "GET /user?ssn=901234-1234567 HTTP/1.1" 200

→ 로그 파일이 유출되면 민감한 정보가 그대로 노출됨

 

③ Referer 헤더를 통한 정보 유출

시나리오:
사용자가 https://bank.com/transfer?account=123&amount=1000000 페이지에서
외부 링크를 클릭하면:

다음 사이트로 전송되는 HTTP 헤더:
Referer: https://bank.com/transfer?account=123&amount=1000000

→ 외부 사이트가 계좌번호와 금액 정보를 알 수 있음

 

④ 브라우저 캐싱 문제

GET 요청은 브라우저에 캐시될 수 있어서:
✗ 공용 PC에서 다음 사용자가 뒤로가기로 정보 조회 가능
✗ 캐시 파일 분석으로 민감 정보 복원 가능
✗ 중간자 공격 시 캐시된 데이터 탈취 가능

---

2-3.2 POST가 보안적으로 우수한 이유

① HTTP Body에 데이터 은닉

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

username=admin&password=1234

 

장점:

• ✓ URL에 노출되지 않아 서버 로그에 민감 정보 미기록
• ✓ 브라우저 히스토리에 파라미터 저장 안 됨
• ✓ Referer 헤더로 전송되지 않음
• ✓ 북마크로 공유되지 않음

② 데이터 길이 제한 없음

GET:  2KB 제한 → 복잡한 암호화 데이터 전송 어려움
POST: 무제한   → 긴 암호화 토큰, 대용량 데이터 전송 가능

 

③ CSRF 토큰 활용 가능

<form method="POST" action="/transfer">
    <input type="hidden" name="csrf_token" value="random_token_xyz123">
    <input name="amount" value="10000">
    <button type="submit">송금</button>
</form>

 

POST는 CSRF 보호 메커니즘을 적용하기 용이함

(✔CSRF: CSRF는 사용자가 로그인된 상태를 악용해, 사용자의 의도와 상관없이 공격자가 요청을 대신 보내게 만드는 공격이다. 그래서 서버는 CSRF 토큰 같은 걸로 “이 요청이 진짜 사용자 요청인지”를 확인한다. )

 

④ 브라우저 재전송 방지

POST 요청 후 뒤로가기 시:
"양식을 다시 제출하시겠습니까?" 경고 표시
→ 중복 거래 방지
→ 실수로 인한 중복 처리 방지

---

 

2-4. 활용 가이드라인

GET을 사용해야 하는 경우

✓ 검색 기능: /search?q=keyword
✓ 필터링: /products?category=electronics&price_min=10000
✓ 페이징: /articles?page=2
✓ 공유 가능한 URL: /post?id=123
✓ 캐싱이 필요한 조회: /api/users/123

 

POST를 반드시 사용해야 하는 경우

✓ 로그인: 사용자명, 비밀번호
✓ 회원가입: 개인정보
✓ 결제: 카드 정보, 계좌 정보
✓ 데이터 생성/수정/삭제
✓ 파일 업로드
✓ 민감한 검색 (의료 정보, 금융 정보 등)

 

 

3. L3와 L4 대해

3-1. OSI에 대해

3-1-1. OSI 7계층이란?

이거에 대해 알아보기전에 먼저 OSI(Open Systems Interconnection) 7계층은 네트워크 통신이 일어나는 과정을 7단계로 나눈 국제 표준 모델입니다. 각 계층은 독립적인 역할을 수행하며, 상위 계층은 하위 계층의 서비스를 이용합니다.

 

3-1-2. OSI 7계층 구조

7계층 - Application Layer (응용 계층)

• 역할: 사용자가 직접 사용하는 응용 프로그램과 네트워크 간의 인터페이스
• 프로토콜: HTTP, HTTPS, FTP, SMTP, DNS
• 실생활 비유: 편지를 쓰는 사람 (내용을 작성)

6계층 - Presentation Layer (표현 계층)

• 역할: 데이터의 형식 변환, 암호화, 압축
• 프로토콜: SSL, TLS, JPEG, MPEG
• 실생활 비유: 번역가 (언어를 상대방이 이해할 수 있게 변환)

5계층 - Session Layer (세션 계층)

• 역할: 통신 세션의 연결, 유지, 종료 관리
• 프로토콜: NetBIOS, RPC
• 실생활 비유: 통화 연결 관리자 (통화 시작과 종료를 관리)

4계층 - Transport Layer (전송 계층) ⭐ L4

• 역할: 종단 간 신뢰성 있는 데이터 전송 보장
• 프로토콜: TCP, UDP
• 포트 번호를 사용하여 응용 프로그램 구분
• 실생활 비유: 택배 기사 (물건을 확실하게 전달하고 배송 확인)

3계층 - Network Layer (네트워크 계층) ⭐ L3

• 역할: 서로 다른 네트워크 간의 경로 설정 및 라우팅
• 프로토콜: IP, ICMP, ARP
• IP 주소를 사용하여 목적지 식별
• 실생활 비유: 우체국 (주소를 보고 어느 지역으로 보낼지 결정)

2계층 - Data Link Layer (데이터 링크 계층)

• 역할: 같은 네트워크 내에서 직접 연결된 기기 간 데이터 전송
• 프로토콜: Ethernet, Wi-Fi, MAC
• MAC 주소를 사용
• 실생활 비유: 동네 배달원 (같은 동네 내에서 집 찾아가기)

1계층 - Physical Layer (물리 계층)

• 역할: 물리적인 전기 신호 전송
• 장비: 케이블, 허브, 리피터
• 실생활 비유: 도로와 차량 (실제로 물건을 운반하는 물리적 수단)

---

3-2. L3 (Network Layer) 깊이 파헤치기

3-2-1. L3의 핵심 역할

L3은 서로 다른 네트워크를 연결하는 계층입니다. 집 주소처럼 고유한 IP 주소를 사용해 전 세계 어디든 데이터를 전달할 수 있습니다.

 

3-2-2. 실생활 비유로 이해하기

상황: 서울에 사는 당신이 부산에 있는 친구에게 선물을 보낸다고 가정해봅시다.

• IP 주소: 친구 집의 전체 주소 (부산광역시 해운대구 ○○동 123-45)
• 라우터: 각 지역의 우체국과 물류센터
• 라우팅: 서울 → 경기 물류센터 → 대전 물류센터 → 부산 물류센터 → 해운대구 우체국으로 가는 최적 경로를 찾는 과정

우체국 직원이 주소를 보고 "이건 부산이니까 남쪽으로 보내야겠다"라고 판단하는 것처럼, 라우터는 IP 주소를 보고 어느 방향으로 패킷을 전달할지 결정합니다.

 

3-2-3. L3 주요 기능

1. IP 주소 지정: 각 기기에 고유한 주소 부여
2. 라우팅: 최적의 경로를 찾아 데이터 전달
3. 패킷 분할 및 재조립: 큰 데이터를 작은 패킷으로 나누고 다시 합침
4. 네트워크 간 통신: 서로 다른 네트워크를 연결

3-2-4. L3 장비

• 라우터: 네트워크 간 경로를 설정하고 패킷을 전달
• L3 스위치: 스위칭과 라우팅 기능을 모두 수행

---

3-3. L4 (Transport Layer) 깊이 파헤치기

3-3-1. L4의 핵심 역할

L4는 실제 데이터가 정확하고 안전하게 전달되도록 보장하는 계층입니다. 포트 번호를 사용해 같은 컴퓨터 안에서 어떤 응

용 프로그램으로 데이터를 보낼지 구분합니다.

 

3-3-2. 실생활 비유로 이해하기

상황: 대형 아파트 단지에 택배가 도착했다고 가정해봅시다.

• IP 주소: 아파트 단지 주소 (○○아파트 123동)
• 포트 번호: 호수 (104동 402호)
• TCP: 등기 우편 (받는 사람의 서명을 받고, 분실되면 다시 보내줌)
• UDP: 일반 우편 (그냥 우편함에 넣고 감, 빠르지만 분실 가능)

아파트 경비실(라우터)에서 택배를 받으면, 104동까지는 L3이 전달하고, 402호 문 앞까지는 L4가 정확하게 배달하는 것입니다.

 

3-3-3. L4 주요 기능

1. 포트 번호 지정: 응용 프로그램 구분 (HTTP:80, HTTPS:443, SSH:22)
2. 오류 제어: 데이터 손상 검사 및 재전송
3. 흐름 제어: 수신자의 처리 속도에 맞춰 전송 속도 조절
4. 혼잡 제어: 네트워크 혼잡 방지

3-3-4. L4 장비

• L4 스위치: 포트 번호 기반으로 트래픽 분산 (로드 밸런싱)
• 방화벽: 포트와 프로토콜 기반 접근 제어

---

3-4. L3와 L4의 차이점 정리

구분	L3 (Network Layer)	L4 (Transport Layer)
주소 체계	IP 주소	포트 번호
역할	네트워크 간 경로 설정	종단 간 데이터 전송 보장
프로토콜	IP, ICMP, ARP	TCP, UDP
관심사	"어디로" 보낼까?	"어떻게" 보낼까?
장비	라우터, L3 스위치	L4 스위치, 방화벽
비유	우체국 (지역 간 배송)	택배 기사 (정확한 배달)

---

3-5. 실무에서의 활용

L3 활용 사례

• 라우팅: 서로 다른 네트워크(사무실 네트워크, 데이터센터)를 연결
• VPN: IP 기반으로 원격지 네트워크 연결
• 서브넷 분할: 네트워크를 논리적으로 나누어 관리

L4 활용 사례

• 로드 밸런싱: 웹 서버 여러 대에 트래픽 분산
• 방화벽 정책: 특정 포트만 허용/차단
• 서비스 구분: 같은 서버에서 웹(80), 메일(25), SSH(22) 동시 운영

---

4. 쿠키와 세션의 차이

https://balhae.tistory.com/274

쿠키 VS 세션

https://balhae.tistory.com/285

JWT vs 세션

https://balhae.tistory.com/266

AccessToken과 RefreshToken 인증 방식

---

5. 세션 클러스터링

5-1. 세션 클러스터링(Session Clustering)이란?

세션 클러스터링은 여러 대의 웹 서버(서버 클러스터)가 사용자 세션 정보를 공유하여, 사용자가 어느 서버에 접속하더라도 동일한 세션 상태를 유지할 수 있도록 하는 기술입니다.

 

세션: 사용자가 웹사이트에 접속해서 로그아웃하거나 일정 시간이 지날 때까지 유지되는 상태 정보 (로그인 정보, 장바구니 등)

클러스터링: 여러 대의 서버를 하나의 시스템처럼 동작하게 만드는 기술

세션 클러스터링: 클러스터 내 모든 서버가 세션 정보를 공유하여, 사용자가 어느 서버로 요청을 보내도 일관된 경험을 제공

5-2. 실생활 비유

상황: 전국에 지점이 있는 은행 시스템

• 세션 클러스터링 없이: 강남 지점에서 통장을 만들었는데, 다음 날 홍대 지점에 가니 "고객님 정보가 없네요?"라고 함
• 세션 클러스터링 적용: 모든 지점이 중앙 시스템으로 고객 정보를 공유해서, 어느 지점을 가든 동일한 서비스를 받을 수 있음

사용자는 서버 A, B, C 중 어디에 연결되든 상관없이 자신의 로그인 상태와 데이터를 유지할 수 있습니다.

 

5-3. 왜 세션 클러스터링이 필요한가?

5-3-1. 단일 서버의 문제점

 

과거에는 웹 서버 1대로 모든 사용자를 처리했습니다. 하지만 이런 구조는 여러 문제가 있습니다.

문제 1: 서버 과부하

• 사용자 1만 명이 동시 접속하면 서버 1대가 감당 못함
• 응답 속도 느려짐

문제 2: 장애 시 서비스 중단

• 서버가 다운되면 모든 서비스 중단
• 세션 정보 모두 손실

문제 3: 확장성 부족

• 트래픽 증가 시 대응 어려움

5-3-2. 해결책: 서버 여러 대 운영 (클러스터링)

 

여러 대의 서버를 두고 로드 밸런서로 트래픽을 분산시킵니다. 하지만 여기서 새로운 문제가 발생합니다.

 

바로 세션 불일치 문제!

사용자 요청 #1 → 로드 밸런서 → 서버A (로그인, 세션 생성)
사용자 요청 #2 → 로드 밸런서 → 서버B (세션 없음! 로그인 안 된 것으로 인식)

 

5-3-3. 실생활 비유

상황: 은행 지점이 여러 개 있는 경우

• 문제 상황: 강남 지점에서 통장을 만들었는데, 다음 날 홍대 지점에 가니 "고객님 정보가 없네요?"
• 해결 필요: 모든 지점이 고객 정보를 공유해야 함

이것이 바로 세션 클러스터링이 필요한 이유입니다.

 

5-4. 세션 클러스터링 방식

5-4-1. Sticky Session (Session Affinity)

개념: 한 사용자는 항상 같은 서버로만 연결되도록 고정

장점

• 구현이 간단함
• 추가 세션 저장소 불필요
• 빠른 응답 속도

단점

• 서버 간 부하 불균형 발생 가능
• 해당 서버 장애 시 세션 손실
• 확장성 제한

💡 실생활 비유
단골 미용실처럼 항상 같은 디자이너에게만 머리를 맡기는 것. 그 디자이너가 퇴사하면 내 헤어 스타일 기록이 사라짐.

 

동작 방식

로드 밸런서가 쿠키나 IP 주소를 보고 항상 같은 서버로 연결
사용자A → 항상 서버1
사용자B → 항상 서버2
사용자C → 항상 서버1

 

5-4-2. Session Replication (세션 복제)

개념: 모든 서버가 세션 정보를 서로 복사해서 동기화

장점

• 어느 서버든 접속 가능
• 서버 장애 시에도 세션 유지
• 빠른 세션 접근

단점

• 서버가 많아질수록 네트워크 트래픽 증가
• 메모리 사용량 증가 (모든 서버가 모든 세션 저장)
• 동기화 오버헤드

실생활 비유: 모든 은행 지점이 고객 정보 파일을 복사해서 가지고 있는 것. 정보 업데이트할 때마다 모든 지점에 알려야 한다.

 

동작 방식

서버A: 세션1, 세션2, 세션3
서버B: 세션1, 세션2, 세션3 (복제본)
서버C: 세션1, 세션2, 세션3 (복제본)

주요 기술

• Tomcat Session Clustering
• WildFly/JBoss Clustering
• Multicast 기반 복제

5-4-3. Session Clustering (중앙 세션 저장소) ⭐ 가장 많이 사용

개념: 별도의 중앙 저장소에 세션을 저장하고, 모든 서버가 공유

장점

• 서버 대수에 관계없이 확장 가능
• 서버 장애 시에도 세션 유지
• 메모리 효율적 (각 서버가 모든 세션 저장 안 함)
• 서버 추가/제거 용이

단점

• 중앙 저장소 장애 시 전체 영향
• 네트워크 지연 발생 가능
• 추가 인프라 비용

실생활 비유: 모든 은행 지점이 본사의 중앙 데이터베이스를 조회하는 것. 어느 지점에 가든 같은 정보를 볼 수 있음.

 

동작 방식

서버A ─┐
서버B ─┼─→ Redis/Memcached (중앙 저장소)
서버C ─┘

모든 서버가 중앙 저장소에서 세션을 읽고 씀

 

주요 기술

Redis (가장 인기)

• In-Memory 데이터베이스
• 빠른 읽기/쓰기 속도
• TTL(Time To Live) 자동 만료 지원
• 데이터 영속성 옵션 제공
• 클러스터링 지원

Memcached

• 순수 캐시 전용
• Redis보다 단순하고 가벼움
• 데이터 영속성 없음

데이터베이스 (MySQL, PostgreSQL)

• 데이터 영속성 보장
• 속도는 느림
• 대용량 트래픽에 부적합

---

6. Character Set & Encoding이란?

6-1. 이론

컴퓨터는 0과 1밖에 모르는 '바보'입니다. 우리가 사용하는 "A", "가", "😊" 같은 문자를 컴퓨터가 이해하게 하려면 두 가지 단계가 필요합니다.

• Character Set (문자 집합): 문자에 고유한 숫자 번호를 매기는 '약속' (예: "A"는 65번이야) 즉 표현할 수 있는 문자들의 목록
• Encoding (인코딩): 그 숫자를 컴퓨터 메모리에 저장하기 위해 0과 1로 변환하는 '방식' (예: 65를 어떻게 2진수로 바꿀까?)

실생활 비유: 음식 주문 시스템

• Character Set (메뉴판): 메뉴판에 '김치찌개는 1번', '된장찌개는 2번'이라고 번호를 매겨놓은 상태
• Encoding (주문 방식): 그 번호를 주방에 전달할 때 '손가락으로 표시'할지, '종이에 적어서' 줄지, '무전기로' 말할지 정하는 규칙

6-2. 왜 문자 집합과 인코딩이 필요한가?

6-2-1. 단일 언어 시대의 한계 (ASCII)

과거에는 영어와 기본 기호만 처리하면 됐기 때문에 7비트(128개)면 충분했습니다. 하지만 한글, 한자, 아랍어 등이 등장하며 문제가 생겼습니다.

• 문제 1: 각 국가가 자기들만의 인코딩 방식(EUC-KR, Shift-JIS 등)을 만듦
• 문제 2: 서로 다른 인코딩을 사용하는 시스템끼리 데이터를 주고받으면 글자가 깨짐 (외계어 발생)
• 해결책: 전 세계 모든 문자를 담을 수 있는 거대한 그릇인 유니코드(Unicode)가 탄생

6-2-2. 주요 Character Set (문자 집합) 방식

종류	특징	비유
ASCII	영어, 숫자, 특수문자만 포함 (128개)	아주 작은 동네 수첩
ANSI	ASCII에 각 나라 언어를 확장한 것 (EUC-KR 등)	동네마다 양식이 다른 장부
Unicode	전 세계 모든 문자에 고유 번호 부여	전 세계 공통 백과사전

 

6-3. 인코딩 방식 (Encoding) ⭐ 가장 중요

유니코드라는 '번호표'가 있어도, 이걸 실제로 어떻게 저장하느냐에 따라 효율이 달라집니다.

 

6-3-1. UTF-8 (가변 길이 인코딩) - 가장 많이 사용

• 개념: 문자에 따라 1바이트에서 4바이트까지 길이를 다르게 사용
• 특징:
  • 영어는 1바이트, 한글은 3바이트로 처리
  • ASCII와 완벽하게 호환됨
  • 웹 표준이며 가장 효율적임
• 비유: 글자 크기에 맞춰서 박스 크기를 조절하는 '스마트 포장법'

6-3-2. UTF-16 (고정/가변 혼합)

• 개념: 기본적으로 2바이트 또는 4바이트 사용
• 특징
  • 한글을 2바이트로 저장할 수 있어 한글 위주 데이터에선 UTF-8보다 용량이 적을 수 있음
  • 하지만 ASCII 호환성이 떨어지고 관리가 복잡함
• 비유: 모든 물건을 중형 또는 대형 박스에만 담는 방식

6-3-4. EUC-KR / CP949 (한글 전용)

• 개념: 한글만을 위해 만들어진 과거의 방식
• 특징: 
  • 한글 2바이트 처리
  • 유니코드와 호환되지 않아 현대 웹 환경에선 권장되지 않음
• 비유: 우리나라에서만 통용되는 지역 화폐

6-4. 왜 글자가 깨질까요? (Decoding Error)

우리가 흔히 보는 ``나 뷁 같은 현상은 인코딩(저장 규칙)과 디코딩(해석 규칙)이 일치하지 않을 때 발생합니다.

• 상황: "안녕"을 UTF-8(규칙 A)로 저장함
• 오류: 읽을 때 EUC-KR(규칙 B)로 해석하려고 함
• 결과: 컴퓨터는 엉뚱한 번호를 찾아내어 이상한 글자를 출력함

---

7. 암호화 단반향 양방햐 공개키 비공개키 암호화 종류

7-1. 단방향 vs 양방향 암호화 비교

구분	단방향 (One-Way)	양방향 (Two-Way)
복호화 (다시 풀기)	불가능	가능
핵심 목적	데이터의 무결성 확인 (진위 여부), 비밀번호 저장	데이터의 안전한 전송 및 보관
주요 용도	비밀번호 저장, 파일 변조 확인	개인정보 암호화, 이메일 보안
특징	같은 입력값은 항상 같은 결과값이 나옴	키(Key)가 있어야 원래 내용을 볼 수 있음
주요 알고리즘	MD5, SHA-1, SHA-256, SHA-512, bcrypt, scrypt	7-2에 설명

 

7-2. 대칭키 vs 비대칭키(공개키/개인키) 비교

구분	대칭키 (Symmetric)	비대칭키 (Asymmetric / Public Key)
사용 키 개수	1개 (암호화 키 = 복호화 키)	2개 (공개키로 암호화, 개인키로 복호화)
키 전달 문제	키를 전달하다 탈취당할 위험이 있음	공개키는 공개되어도 안전함 (개인키만 보관)
암호화 속도	매우 빠름	느림 (연산 과정이 복잡함)
주요 알고리즘	AES, DES, 3DES, ARIA, SEED, ChaCha20	RSA, ECC, DSA, ElGamal, Diffie-Hellman
암호화 키	동일한 키	공개키
복호화 키	동일한 키	비밀키
실생활 비유	금고 비밀번호 (번호만 알면 누구나 염)	우체통 (넣는 건 누구나, 꺼내는 건 주인만)

 

---

8. 유닉스 & 리눅스 명령어: Crontab (스케줄링 작업)

8-1. Crontab이란?

Crontab(크론탭)은 리눅스나 유닉스 계열 시스템에서 특정 시간에 특정 작업을 자동으로 실행하게 해주는 '예약 실행(스케줄링)' 도구입니다.

• Cron: 백그라운드에서 주기적으로 정해진 작업을 실행하는 프로세스 (데몬)
• Crontab: 그 작업을 언제, 어떻게 실행할지 적어놓은 '시간표(Table)'

💡 실생활 비유

매일 아침 7시에 울리는 스마트폰 알람과 같습니다. 한 번 설정해두면 내가 신경 쓰지 않아도 정해진 시간에 맞춰 시스템이 일을 수행합니다.

 

---

8-2. Crontab 설정 기본 문법

크론탭은 5개의 별(*)과 실행할 명령어로 구성됩니다.

필드 (순서)	의미	범위
1번째 (*)	분 (Minute)	0 ~ 59
2번째 (*)	시 (Hour)	0 ~ 23
3번째 (*)	일 (Day of Month)	1 ~ 31
4번째 (*)	월 (Month)	1 ~ 12
5번째 (*)	요일 (Day of Week)	0 ~ 6 (0:일요일, 6:토요일)

---

8-3. 주요 명령어

터미널에서 크론탭을 관리할 때 사용하는 명령어들입니다.

명령어	기능	비유
crontab -e	크론탭 설정 편집 (Edit)	시간표 작성/수정하기
crontab -l	설정된 내용 확인 (List)	내 시간표 구경하기
crontab -r	모든 크론탭 삭제 (Remove)	시간표 초기화하기

---

8-4. 실전 활용 예시

자주 쓰이는 설정 방식들을 표로 정리했습니다.

실행 주기	Crontab 설정값	설명
매분마다	* * * * * /path/script.sh	매분 0초에 스크립트 실행
매일 새벽 3시	0 3 * * * /path/script.sh	서버가 한가한 새벽에 데이터 백업
매주 월요일 오전 9시	0 9 * * 1 /path/script.sh	업무 시작 시간 맞춰 주간 보고서 생성
10분마다	*/10 * * * * /path/script.sh	특정 간격으로 반복 작업 수행

---

8-5. 왜 Crontab이 필요한가? (사용 이유)

1. 반복 작업 자동화: 매일 수동으로 하던 로그 정리, DB 백업 등을 자동화하여 실수를 방지합니다.
2. 리소스 효율: 트래픽이 적은 새벽 시간에 무거운 배치(Batch) 작업을 돌려 서버 부담을 분산합니다.
3. 시스템 모니터링: 주기적으로 시스템 상태를 체크하고 관리자에게 알림을 보내는 용도로 활용됩니다.

---

9. 보안의 핵심: SSL(Secure Sockets Layer) & TLS(Transport Layer Security)

9-1. SSL/TLS란?

웹사이트와 브라우저 사이의 통신을 암호화하여 해커가 중간에서 정보를 훔쳐보지 못하게 만드는 보안 프로토콜입니다.

• SSL: 1990년대 초반에 넷스케이프에서 처음 만든 보안 규격입니다.
• TLS: SSL의 결함을 보완하고 업그레이드한 SSL의 최신 버전입니다.

💡 핵심 포인트

사실상 지금 우리가 사용하는 기술은 대부분 TLS이지만, 사람들에게 익숙한 용어인 SSL로 혼용해서 부르는 경우가 많습니다. (마치 모든 스테이플러를 '호치케스'라고 부르는 것과 비슷합니다.)

9-2. 실생활 비유: 봉인된 특급 우편

• HTTP (일반 우편): 누구나 편지 봉투를 뜯어서 내용을 볼 수 있는 일반 엽서 상태
• HTTPS (SSL/TLS 적용): 특수 제작된 금고 상자에 편지를 넣고, 받는 사람만 가진 열쇠로 열 수 있는 특급 보안 우편

9-3. SSL/TLS의 주요 역할

역할	설명
암호화 (Encryption)	제3자가 데이터를 가로채도 내용을 읽을 수 없게 만듦
인증 (Authentication)	내가 접속한 사이트가 진짜 그 사이트가 맞는지 확인 (피싱 방지)
데이터 무결성 (Integrity)	전송 중에 데이터가 변조되지 않았음을 보장

 

9-4. 동작 방식: SSL 핸드셰이크(Handshake)

데이터를 주고받기 전, 클라이언트(브라우저)와 서버가 서로 인사를 나누며 암호화 방식을 정하는 과정입니다. 위에서 설명한 공개키(비대칭키)와 대칭키 방식이 여기서 모두 쓰입니다.

 

9-4-1. naver.com 접속 시 발생하는 SSL/TLS 핸드셰이크 과정

1단계: Client Hello (브라우저 → 네이버 서버)

사용자가 주소창에 엔터를 치면 브라우저가 네이버 서버에 첫 인사를 건넵니다.

• 보내는 정보: 브라우저가 지원하는 TLS 버전, 지원하는 암호화 방식(Cipher Suite), 그리고 임의의 난수(Client Random)를 전달합니다.

2단계: Server Hello & Certificate (네이버 서버 → 브라우저)

네이버 서버가 응답합니다.

• 보내는 정보: 브라우저가 제안한 방식 중 하나를 선택하고, 자신의 신분증인 'SSL/TLS 인증서'를 보냅니다. 이 인증서 안에는 네이버의 공개키가 들어있습니다.

3단계: 인증서 검증 (브라우저의 확인 작업) ⭐ 중요

브라우저는 받은 인증서가 가짜인지 확인합니다.

• 방법: 브라우저에 내장된 '신뢰할 수 있는 기관(CA)' 목록과 대조합니다. 만약 인증서의 디지털 서명이 유효하다면 "이 서버는 진짜 네이버가 맞구나!"라고 신뢰하게 됩니다.

4단계: Pre-Master Secret 생성 및 전달 (브라우저 → 네이버 서버)

진짜인 게 확인됐으니, 이제 데이터를 암호화할 '비밀번호'를 만들어야 합니다.

• 동작: 브라우저는 임의의 비밀번호(Pre-Master Secret)를 생성합니다.
• 암호화: 이걸 그냥 보내면 해커가 가로채겠죠? 그래서 아까 받은 네이버의 공개키로 이 비밀번호를 꽁꽁 얼려버립니다.

5단계: 비밀번호 복호화 (네이버 서버)

서버는 암호화된 비밀번호를 받습니다.

• 동작: 서버는 자신만 가지고 있는 개인키(Private Key)를 꺼내서 브라우저가 보낸 비밀번호를 풀어냅니다.
• 결과: 이제 브라우저와 네이버 서버만 아는 공통의 대칭키(세션키)가 생겼습니다.

6단계: 통신 준비 완료 (Change Cipher Spec)

양측은 "이제부터 우리가 공유한 이 대칭키로 모든 데이터를 암호화해서 주고받자!"라고 최종 확인 사인을 보냅니다.

 

7단계: 데이터 전송 (HTTPS 시작)

이제 우리가 보는 뉴스, 메일 등의 데이터가 대칭키(AES 등)로 암호화되어 전송됩니다. 주소창에는 초록색 자물쇠 아이콘이 뜹니다.

 

9-5. HTTP vs HTTPS (보안 적용 여부)

구분	HTTP	HTTPS (HTTP over SSL/TLS)
포트 번호	80번	443번
보안성	암호화 없음 (위험)	강력한 암호화 (안전)
검색 노출	검색 순위에서 밀릴 수 있음	구글 등 검색 엔진 최적화(SEO) 우대
신뢰도	브라우저에 '주의 요함' 표시	주소창 옆에 자물쇠 아이콘 표시

---