테크리빗

(재직자 과정) 생성형AI 활용 보안역량강화 과정 모듈 1. 후기

테크리빗 — Thu, 23 Jul 2026 00:32:20 +0900

최근에 (재직자 과정) 생성형 AI 활용 보안역량강화 과정 - 모듈 1. 생성형 AI를 활용한 보안 데이터 처리 교육에 다녀왔습니다.
전문 과정이라기보다는, 말 그대로 AI의 기초 개념을 편하게 다지고 최신 트렌드를 가볍게 접해볼 수 있는 입문 교육이었습니다. 보안관제 교대 근무를 병행하며 수강했던 터라, 오히려 부담 없이 편안한 마음으로 들을 수 있어 딱 좋았습니다.

교육은 SK쉴더스 아카데미에서 진행하였습니다.

AI 트렌드와 채용 시장

강의 초반에는 생성형 AI가 폭발적으로 늘어나면서 IT 채용 시장이 어떻게 바뀌고 있는지, 그리고 AI를 둘러싼 강사님의 견해를 들을 수 있었습니다. AI 기초 용어나 기본 메커니즘도 한 번 더 정리할 수 있었습니다.

AI 기초 과정에 가까웠고 미토스에 대한 생각, AI로 인한 채용시장등 전반적인 AI 트렌드들을 들을수 있었습니다.

실무에서 바로 써먹는 프롬프트 꿀팁

개인적으로 이번 교육에서 소소하게 제일 유익했던 건 LLM 프롬프트 활용 팁이었습니다.

답변 확신도 필터링
AI 특유의 환각(Hallucination) 현상이나 그럴듯한 거짓말을 줄이기 위해, 확신도 기준을 95% 이상으로 명시해서 확실한 정보만 골라 받는 기법입니다.
-> "몇 %로 판단했어? 95% 이상인 것만 답해줘."
주석(// TODO)을 활용한 코드 수정
AI에게 코드를 수정해 달라고 할 때 전체 코드를 무작정 다시 출력하게 하기보다, 변경할 위치에 TODO 주석을 달아달라고 요청하면 어디를 왜 고쳐야 하는지 한눈에 파악하기 훨씬 수월해집니다.
-> "수정이 필요한 부분에 // TODO: [설명] 으로 표시해줘."

Claude 연동 실습: CVE API & 대시보드

이론만 듣는 게 아니라 Claude(클로드)를 활용한 실습도 함께 진행했습니다.

CVE API를 연동하여 수집한 보안 데이터를 파싱하고, 이를 한눈에 볼 수 있는 가벼운 대시보드 형태로 개발해 보는 과정이었습니다. 생성형 AI를 활용해 반복적인 보안 데이터 처리나 자동화의 기본 틀을 잡는 감을 익히기에 유익한 실습이었습니다.

특히 강의 진행 중에 "Claude Code를 활용해서 진행해 보는 건 어떨까요?" 하고 강사님께 아이디어를 제안해 보았는데, 강사님께서 흔쾌히 수락하시고 수업에 바로 적용해 주셨습니다.

수료 총평

전반적으로 난이도가 높지 않아 가벼운 마음으로 AI 관련 기초 개념을 다지고, 현업 자동화 아이디어를 정리하기에 딱 좋은 과정이었습니다.

마음 같아서는 연달아 이어지는 모듈 2(취약점 진단)와 모듈 3(침해사고 대응) 과정도 바로 수강하고 싶었지만, 관제 교대 근무 스케줄상 이번에는 아쉽게 다음을 기약하게 되었습니다. 근무 일정을 잘 조율해서 후반기에 열리는 모듈 2, 3 과정은 꼭 신청해서 수강할 생각입니다.

퓨니코드(Punycode)와 호모그래프 공격

테크리빗 — Wed, 22 Jul 2026 23:58:29 +0900

퓨니코드(Punycode)란

DNS(도메인 네임 시스템)는 영어 알파벳(A-Z), 숫자(0-9), 하이픈(-)으로 이루어진 7비트 ASCII 문자만 인식할 수 있습니다.

하지만 영어가 익숙하지 않은 사용자는 자국어로 된 도메인주소를 통해 훨씬 직관적이고 쉽게 인터넷에 접근하고 싶어 합니다.

퓨니코드는 기존 DNS 시스템을 수정하지 않고도 다양한 언어의 도메인(IDN, 다국어 도메인)으로 접속할수 있게 해주는 기술입니다.

퓨니코드의 작동 방식

퓨니코드로 변환된 도메인은 항상 접두사 xn--로 시작합니다.

우리가 웹 브라우저 주소창에 한글.com을 입력하면
브라우저가 이를 자동으로 xn--bj0bj0b.com이라는 퓨니코드로 변환하여 도메인 네임 서버(DNS)에 요청을 보냅니다.
DNS는 xn-- 라는 접두사를 통해 해당 문자열이 PunyCode로 인코딩 된것임을 알수있습니다.

입력한 도메인: 한글.com
퓨니코드 변환: xn--bj0bj0b.com

보안 관점: 호모그래프 공격(Homograph Attack)

시각적으로 유사한 문자를 이용해 사용자가 정상 도메인으로 접속했다고 착각하게 만드는 피싱 공격에 활용될수있습니다.

예를들어 www.apple.com이라는 주소에서 알파벳 a와 비슷하게 생긴 키릴문자 a로 대체하는식 입니다.

Xudong Zheng이 키릴 문자(a)를 사용하여 Chrome과 Firefox에서 유효한 HTTPS 인증서와 함께 www.apple.com(xn--80ak6aa92e.com)을 등록하여 실제 호모그래프 공격에 사용될수 있음을 증명했습니다.

최근 웹 브라우저(Chrome, Safari 등)는 이러한 피싱을 막기 위해 주소창에 영문과 타 언어가 수상하게 혼용된 경우, 한글/타 언어 대신 xn--... 형태의 퓨니코드 주소를 그대로 노출시키는 보안 기능을 제공합니다. Xudong Zheng의 PoC 페이지를 보면 과거에는 apple.com으로 주소가 보였지만 26년 현재 접속시 퓨니코드로 주소가 보이는것을 볼수있습니다.

앞서 설명한 웹 브라우저의 보안 기능 강화로 전통적인 PC 환경의 퓨니코드 피싱은 크게 줄어든 추세입니다. 그러나 화면이 좁아 주소창이 쉽게 생략되는 모바일 환경이나, 발신자 이메일 주소 도메인(@company.com)을 위장하는 기업 대상 이메일 사기 등에서는 여전히 악용될 수 있습니다.

GSLB(Global Service Load Balancing)란

테크리빗 — Mon, 1 Jun 2026 20:49:29 +0900

GSLB란

여러 데이터센터(IDC) 간 트래픽 분산과 고가용성(HA)을 보장하는 지능형 DNS입니다.

GSLB는 Load Balancer인가, DNS인가?

GSLB에는 'Load Balancer'가 들어가지만, 실제 내부 동작 방식은 DNS에 훨씬 가깝습니다.

일반 로드밸런서 (L4/L7 Proxy):
사용자 트래픽의 '통로' 역할을 합니다. 클라이언트는 로드밸런서 IP로 직접 접속하고, 로드밸런서가 트래픽을 받아 뒤에 있는 실제 서버로 전달(Proxy)해 줍니다.
GSLB:
트래픽을 직접 중계하지 않고, '어느 주소(IP)로 가야 하는지' 길 안내만 해줍니다. 사용자가 IP를 물어보면 GSLB는 최적의 SLB IP만 알려주고 빠집니다. 그 이후 클라이언트와 서버는 GSLB를 거치지 않고 직접 SLB로 접속하여 통신합니다.

이 방식은 기존 DNS가 도메인 이름을 IP로 변환(Name Resolution)해 주는 동작 방식과 동일하기 때문에, 근본적으로 DNS 기반의 기술이라 부릅니다.

GSLB가 왜 '지능형 DNS'인가요?

일반적인 DNS 또한 하나의 도메인 주소(예: example.com)에 여러개의 IP주소를 제공하여 부하분산하는 DNS 로드밸런싱이 가능합니다. 하지만 DNS는 서버가 죽었는지 살았는지 확인하는 Health Check가 불가능하므로 가용성을 확보할 수 없다는 문제가 있습니다.

반면에 GSLB는 등록된 도메인에 대해 헬스 체크를 수행하고 살아있는 서버에 IP만 전달하므로 가용성을 확보할수 있습니다.

Health Check: 등록된 IDC/SLB의 상태를 주기적으로 확인하여 살아있는 서버의 IP만 반환합니다.
Geolocation (위치 기반 Routing): 사용자가 한국에 있는지, 일본에 있는지 접속 위치를 확인하여 가장 가까운 IDC로 안내합니다.
네트워크 상태 & 부하 고려: 각 IDC의 응답 속도(RTT)나 부하 상태를 고려해 최적의 IP를 제공합니다.

즉, 상황(서버 상태, 사용자 위치, 네트워크 지연)을 종합적으로 판단하여 최적의 IP를 동적으로 반환하기 때문에 '지능형 DNS'라고 부릅니다.

GSLB에서 'Global'의 진짜 의미

GSLB의 'Global'은 단지 '전 세계(국가 간)'에만 한정되는 단어가 아닙니다! 네트워크/인프라 관점에서 Global은 "단일 데이터센터(IDC)나 단일 네트워크 구역을 벗어난 광역(Multi-Data Center / Cross-Region)" 환경을 의미합니다.

Local Load Balancer (SLB - L4/L7): 하나의 IDC 내부에 있는 여러 대의 서버로 트래픽을 나눠줍니다. (예: 서울 IDC 안의 1번, 2번 웹 서버)
Global Load Balancer (GSLB): 서로 떨어져 있는 여러 IDC 간에 트래픽을 나눠줍니다. (예: 서울 IDC - 광주 IDC)

서울과 광주는 같은 한국이지만, 물리적으로 떨어져 있고 서로 다른 IP 대역 및 네트워크 망을 사용합니다. 따라서 이 둘을 묶어 제어하기 위해서는 Local이 아닌 Global(광역) 로드밸런서(GSLB)가 필요합니다.

같은 국가에서 여러 IDC를 쓰는 이유는 DR성격이 강해 보입니다.

(참고) 국내 Multi-IDC 구성과 DR(Disaster Recovery)
국내에서 서울 IDC와 광주 IDC를 함께 구성하는 것은 DR(재해 복구) 및 서비스 연속성 목적이 큽니다. 만약 서울 IDC에 정전, 지진, 대규모 DDoS 등 장애가 발생하면, GSLB가 Health Check로 이를 즉시 감지하고 사용자 접속을 광주 IDC로 자동 전환(Failover)하여 서비스 중단을 막아냅니다.

GSLB 동작원리

GSLB는 기존 DNS 체계에 "지능형 응답(Health Check + 위치/부하 고려)" 로직이 얹어진 형태입니다. 클라이언트가 웹사이트 www.example.com에 접속하려 할 때 GSLB가 동작하는 흐름은 다음과 같습니다.

1. Client의 도메인 주소 질의 (Local DNS 요청)

클라이언트가 브라우저에 www.example.com을 입력하면, 가장 먼저 PC에 설정된 Local DNS(예: KT/SKT/LGU+ 통신사 DNS, Google 8.8.8.8 등)에 해당 도메인의 IP 주소를 물어봅니다.

2. Local DNS의 iterative Query (기존 DNS 탐색)

Local DNS의 캐시에 해당 도메인이 없 다면, Root DNS ➔ TLD(.com) DNS를 거쳐 example.com 도메인의 네임서버(NS)가 누구인지 찾아 나섭니다.

3. GSLB로 위임 (Delegation)

example.com을 관리하는 상위 DNS는 Local DNS에게 example.com 에 대한 권한(NS)은 GSLB 장비(네임서버)가 가지고 있으니 GSLB로 가라"라고 GSLB의 IP를 응답합니다. 즉, 해당 도메인의 네임서버(NS 레코드)가 GSLB로 등록/위임되어 있는 상태입니다.

4. Local DNS ➔ GSLB 질의

Local DNS는 전달받은 GSLB로 직접 example.com의 IP를 달라고 질의(Query)합니다.

5. GSLB의 지능형 IP 선택 및 응답 (핵심 단계)

질의를 받은 GSLB는 일반 DNS처럼 고정된 IP를 주는 것이 아니라, 자신이 실시하고 있는 상태 정보를 실시간으로 비교합니다.

Health Check 확인: 서울 IDC와 광주 IDC 중 살아있는 IDC는 어디인가? (서울 IDC 정상확인)
Geolocation / RTT 확인: 요청을 보낸 Local DNS의 IP 위치가 어디인가? (한국 지역 확인)
부하 상태 확인: 어느 IDC의 SLB/서버 상태가 더 쾌적한가?

위 조건을 종합 판단하여 최적의 IDC(예: 서울 IDC SLB)의 VIP(IP 주소)를 A 레코드 값으로 Local DNS에게 전달합니다.

6. Local DNS ➔ Client 전달 및 실제 접속

Local DNS는 GSLB로부터 받은 IP를 Client에게 최종 응답합니다. (이때 TTL 정보도 함께 전달)
이후에는 Client는 전달받은 IP(서울 IDC SLB)로 GSLB를 거치지 않고 직접 HTTP/HTTPS (L4/L7) 접속을 수행합니다.

참고자료

[IT 용어] 페이로드(Payload)란?

테크리빗 — Sun, 11 Jan 2026 12:42:17 +0900

IT 공부를 하다 보면 네트워크, 보안, 웹 개발 등 다양한 분야에서 '페이로드(Payload)'라는 단어를 접하게 되는데요

각 분야마다 의미가 미묘하게 다릅니다. 실제로 지인이 "페이로드가 뭐야?"라고 물었을 때, "음... 데이터? 그 문자열 같은 거?"라고 얼버무리며 감각적으로만 이해하고 있다는 사실을 깨달았습니다. 그래서 이번 기회에 이 용어를 확실하게 정리해보고자 합니다.

출처: Gemeni

페이로드(Payload)란

페이로드란 데이터 패킷 전송 시 헤더나 메타데이터 같은 부가 정보를 제외한 '유의미한 데이터', 다시 말해 전송의 목적이 되는 핵심 데이터를 의미합니다.

(참고) 이 용어는 원래 운송업에서 유래했습니다. 트럭이나 비행기로 화물을 나를 때, 차체의 무게나 운전자의 무게를 뺀 '운임 요금을 매길 수 있는 짐(화물)의 무게'를 페이로드라고 부릅니다. IT에서도 이와 마찬가지로 '운송 수단(헤더)'을 뺀 '진짜 짐(데이터)'을 뜻합니다.

네트워크 관점 (Networking)

네트워크 통신에서 페이로드는 '캡슐화(Encapsulation)' 개념과 뗄 수 없는 관계입니다.

우리가 카카오톡 메시지를 보낼 때, 메시지 데이터는 안정적인 전송을 위해 여러 계층의 포장지(헤더)에 싸서 전송됩니다. 이때 포장지를 모두 벗겨낸 가장 안쪽의 Data가 바로 페이로드입니다.

출처: http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa.htm#google_vignette

(참고) OSI 7 계층 모델에서 상위 계층의 데이터(페이로드)에 헤더가 붙어 하위 계층으로 내려가면, 하위 계층 입장에서는 그 전체가 다시 자신의 페이로드가 되는 상대적인 개념을 갖기도 합니다.

백엔드 관점 (Development)

웹 개발, 특히 API 통신에서는 서버와 클라이언트가 주고받는 핵심 데이터를 의미합니다. 주로 POST 방식으로 데이터를 전송할 때, JSON이나 XML 형식으로 바디(Body)에 담기는 데이터 객체 자체를 페이로드라고 부릅니다.

아래는 로그인 요청 시 사용되는 HTTP Request 예시입니다. 여기서 헤더를 제외한, 중괄호 {} 사이에 있는 JSON 데이터가 바로 페이로드입니다.

POST /api/login HTTP/1.1
Content-Type: application/json

{
  "username": "user123",  <-- 이 JSON 객체 전체가
  "password": "password"      HTTP 요청의 페이로드입니다.
}

정보 보안 관점 (Security)

보안 분야에서 페이로드는 조금 더 공격적인 의미를 가집니다. 공격자가 취약점을 이용해 시스템에 침투했을 때, 실제로 시스템에서 실행시키고자 하는 악성 행위의 코드를 말합니다.

보통 익스플로잇(Exploit)라는 용어와 혼동하곤 하는데, 아래와 같이 구분할 수 있습니다.

익스플로잇(Exploit): 잠긴 문을 따는 도구 (취약점 공격 코드)
페이로드(Payload): 문을 따고 들어가서 수행하는 도둑질 (데이터 탈취, 쉘 획득, 랜섬웨어 실행 등)

즉, 문을 여는 것까지가 익스플로잇이라면, 그 안에서 실제로 피해를 입히는 행위가 페이로드입니다.

sed, awk, jq 명령어

테크리빗 — Fri, 9 Jan 2026 00:25:13 +0900

리눅스 서버에서 수만 줄의 로그나 설정 파일을 열지 않고도, CLI 환경에서 즉시 데이터를 추출하거나 수정할 수 있는 필수 명령어 3가지입니다.

sed(Stream Editor)

vi와 같은 편집기를 열지 않고 텍스트를 수정(Substitution), 치환, 삭제할 때 사용합니다.
주로 설정 파일의 내용을 스크립트로 자동 변경하거나, 개인정보(IP, 주민번호) 마스킹 처리에 활용됩니다.

기본문법
sed s/찾을문자/바꿀문자/g 파일명

# 1. (테스트) 화면에만 출력해보기 (원본 안 바뀜)
sed 's/True/False/g' config.conf

# 2. (실전) 원본 파일 내용을 덮어쓰기 (자동화 스크립트용)
sed -i 's/True/False/g' config.conf

(주의) 기본적으로는 화면에만 결과를 출력합니다. 원본 파일을 덮어쓰려면 -i (In-place) 옵션이 필수입니다.

awk(Aho, Weinberger, Kernighan)

텍스트를 '열(Column)' 단위로 쪼개서 데이터를 추출하고, 조건문을 걸어 통계를 낼 때 씁니다.
기본적으로 공백(스페이스, 탭)을 기준으로 열을 나눕니다. 엑셀의 '텍스트 나누기' 기능과 같습니다.

기본 문법
awk '{print $숫자} 파일명(여기서 숫자는 N번째 열)

# 1. 단순 추출: access.log에서 IP($1)와 상태코드($9)만 출력
awk '{print $1, $9}' access.log

# 2. 조건 필터링: 상태 코드가 '500'(서버 에러)인 줄의 IP만 뽑아라
awk '$9 == 500 {print $1}' access.log

sed, awk 왜 쓰는가?

파이썬(Python)은 강력하지만, DevOps 현장에서는 다음과 같은 이유로 sed, awk가 더 유리할 때가 많습니다.

속도 & 간편함: 파일 열기/읽기/쓰기 코드를 짤 필요 없이 단 한 줄(One-liner)로 끝납니다.
범용성: 파이썬이 설치되지 않은 레거시 서버나, 초경량 컨테이너 환경에서도 리눅스만 깔려있다면 100% 동작합니다.
파이프라인(|) 연결: 다른 명령어의 결과를 바로 받아 처리하기 좋습니다.

DevOps 활용 예시

# [배포 자동화] deployment.yaml 파일의 버전 태그를 v1.0 -> v2.0으로 즉시 변경
sed -i 's/v1.0/v2.0/g' deployment.yaml

# [장애 대응] 에러 난 파드(Pod)만 골라서 자동 삭제 (Kill)
# 조회 -> 'Error' 검색 -> 파드 이름($1)만 추출 -> 삭제 명령어로 전달
kubectl get pods -A | grep Error | awk '{print $1}' | xargs kubectl delete pod

jq(JSON Processor)

최신 클라우드/DevOps 환경(AWS, Kubernetes, Terraform)의 표준 데이터 형식인 JSON을 다루는 필수 도구입니다. sed와 awk는 구조화된 JSON 데이터 처리에 취약하므로, jq가 반드시 필요합니다.

기본 문법
명령어 | jq '.키이름'

# [가독성] 복잡한 JSON 결과를 예쁘게 정렬해서 보기 (Pretty Print)
aws ec2 describe-instances | jq .

# [데이터 추출] AWS 인스턴스 목록에서 'InstanceId' 값만 쏙 뽑아내기
aws ec2 describe-instances | jq '.Reservations[].Instances[].InstanceId'

실습 사이트

jq 연습: jqplay.org (강력 추천)

왼쪽에 JSON 데이터를 넣고, 상단에 명령어를 입력하면 오른쪽에 결과가 바로 나옵니다.
학습법: 구글에 "AWS json sample" 검색해서 넣고, 원하는 값만 뽑아보는 연습을 하세요.

sed/awk 연습: HackerRank - Linux Shell

해커랭크 사이트의 'Shell' 파트에 가시면 Grep, Sed, Awk 문제들이 단계별로 있습니다.
초반 5문제 정도만 풀어봐도 감이 옵니다.

HTTP의 역사: 0.9부터 3.0(QUIC)까지

테크리빗 — Fri, 2 Jan 2026 06:29:39 +0900

우리가 매일 사용하는 웹(Web)은 멈춰있지 않습니다. 브라우저 주소창에 URL을 입력하고 엔터를 누르는 그 찰나의 순간, 데이터를 조금이라도 더 빠르고 효율적으로 전송하기 위해 프로토콜은 끊임없이 진화해 왔습니다. 1991년 팀 버너스 리가 고안한 단순한 텍스트 전송 규약이 어떻게 오늘날의 초고속 UDP 통신으로 발전했는지, 그 치열했던 진화과정을 정리해보겠습니다.

1. 태초의 웹, 단순함 그 자체였던 HTTP/0.9

이야기는 1991년 팀 버너스 리의 연구실에서 시작됩니다. 당시의 HTTP는 그야말로 '생존'을 위한 최소한의 기능만 갖추고 있었습니다. 복잡한 인사말이나 부가 정보는 사치였죠.

클라이언트가 서버에게 말을 거는 방식은 너무나 단순했습니다.

(Request)
GET /index.html

보시다시피 버전 정보도, 헤더도 없습니다. 오직 "이 파일 줘"라는 한 마디뿐입니다. 서버의 대답도 쿨하기 그지없었습니다.

(Response)
<html>
  <body>
    Hello World! This is a simple text page.
  </body>
</html>

성공했다는 상태 코드(200 OK)조차 없이, 오직 본문 내용만 툭 던져주었습니다. 텍스트 위주의 초기 웹에서는 이 정도면 충분했지만, 웹이 성장하기엔 너무나 부족한 소통 방식이었습니다.

2. HTTP/1.0, 웹이 격식을 갖추기 시작하다

1996년, 웹은 더 이상 텍스트 쪼가리만 주고받는 곳이 아니게 되었습니다. 이미지를 보내야 했고, 브라우저의 종류를 알려야 했습니다. 그래서 HTTP/1.0부터는 헤더(Header)라는 명함을 교환하기 시작했습니다.

(Request)
GET /my-image.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0

(Response)
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 1348

(binary image data...)

이제 요청 끝에 HTTP/1.0이라는 버전이 붙었고, User-Agent로 자신이 누구인지 밝힙니다. 응답 역시 200 OK라며 성공 여부를 명확히 하고, Content-Type을 통해 "이건 텍스트가 아니라 이미지야"라고 친절하게 알려주게 되었죠.

하지만 치명적인 문제가 있었습니다. 이미지 하나를 받을 때마다 매번 연결을 끊고 다시 맺어야 했습니다.
위 처럼 파일을 10개 받으려면 전화도 10번 걸어야 하는 비효율적인 상황이었습니다.

3. HTTP/1.1, 효율성을 위해 연결을 유지하다 (Keep-Alive)

이 문제를 해결하기 위해 1997년 등장한 HTTP/1.1은 Keep-Alive라는 개념을 도입합니다. 한 번 연결하면 끊지 않고 계속 대화하자는 약속입니다.

(Request)
GET /index.html HTTP/1.1
Host: http://www.example.com
Connection: keep-alive

(Response)
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 3050

여기서 가장 중요한 건 Connection: keep-alive입니다. "전화 끊지 말고 잠깐 기다려, 다음 파일도 달라고 할 거니까"라는 의미죠. 또한 Host 헤더가 필수가 되면서 하나의 IP로 여러 도메인을 운영하는 가상 호스팅도 가능해졌습니다.

하지만 여전히 한계는 존재했습니다. 바로 HOL(Head-of-Line) Blocking, 즉 '앞차 막힘 현상'입니다.
연결은 하나인데 순서대로 처리해야 하다 보니, 앞의 무거운 이미지 하나 때문에 뒤에 있는 가벼운 파일들이 하염없이 기다려야만 했습니다.

[요청 1: 대용량 이미지] -> (전송 중... 3초 소요)
[요청 2: 텍스트 파일]   -> (이미지 다 받을 때까지 대기...)
[요청 3: 스타일 시트]   -> (앞에 두 개 다 끝날 때까지 대기...)

4. HTTP/2, 도로를 쪼개서 동시에 달리다 (Multiplexing)

2015년, 이 '줄 서기' 문제를 해결하기 위해 HTTP/2가 등장했습니다. 핵심은 멀티플렉싱(Multiplexing)입니다. 하나의 연결 안에 여러 개의 '가상 차선(Stream)'을 만들어 동시에 데이터를 쪼개서 보냅니다.

HTTP/2는 사람이 읽는 텍스트가 아닌, 이진 프레임(Binary Frame)으로 데이터를 주고받습니다. 이를 개념적으로 표현하면 다음과 같습니다.

(Stream 1) HEADERS: method=GET, path=/image.jpg
(Stream 3) HEADERS: method=GET, path=/style.css

(Stream 3) DATA: body { color: red; }  <-- 가벼운 CSS가 먼저 도착!
(Stream 1) DATA: (image part 1)
(Stream 1) DATA: (image part 2)

보시는 것처럼 요청은 순서대로 했지만, 응답은 파일 크기나 상황에 따라 뒤섞여서(Interleaving) 도착합니다. 더 이상 앞의 큰 파일 때문에 뒤의 작은 파일이 기다릴 필요가 없어진 것입니다.

하지만 완벽해 보이는 HTTP/2에도 아킬레스건은 있었습니다. 바로 기반이 되는 TCP 프로토콜입니다. 고속도로(HTTP/2)를 아무리 넓혀놔도, 도로 자체(TCP)가 유실되면(패킷 손실) 모든 차선이 멈춰버리는 문제는 여전했습니다.(TCP의 신뢰성있는 전송을 보장하기 위함.)

4. HTTP/3, TCP를 버리고 UDP로 혁신하다 (QUIC)

그래서 등장한 것이 최신 기술인 HTTP/3입니다. HTTP/3는 과감한 결단을 내립니다. 인터넷의 역사와 함께해 온 신뢰의 상징, TCP를 버리기로 한 것입니다. 대신 빠르지만 신뢰성이 낮다고 평가받던 UDP를 선택했고, 그 위에 구글이 개발한 QUIC이라는 새로운 프로토콜을 얹었습니다.

QUIC은 TCP가 하던 신뢰성 보장 기능을 애플리케이션 영역으로 가져와 재설계했습니다. 가장 큰 특징은 독립적인 스트림입니다. 이제는 패킷 하나가 손실되어도 해당 데이터만 잠시 멈출 뿐, 다른 데이터들은 아무 영향 없이 쌩쌩 달릴 수 있습니다. 진정한 의미의 병렬 처리가 가능해진 것입니다.

게다가 모바일 환경에서의 혁신도 이루어냈습니다. 예전에는 와이파이에서 LTE로 바뀌면 IP가 달라져 연결이 끊겼지만, QUIC은 고유한 ID로 연결을 식별하기 때문에 네트워크가 바뀌어도 끊김 없이 통신을 이어갑니다. 유튜브나 넷플릭스 같은 스트리밍 서비스가 이동 중에도 매끄러운 이유 중 하나가 바로 이 기술 덕분입니다.

마치며: 전송 계층을 넘나드는 진화

HTTP의 역사를 되짚어보면, 이는 단순한 기능 추가의 역사가 아닙니다. 병목 현상을 해결하기 위해 처음에는 헤더를 고치고(1.0/1.1), 그다음엔 메시지 구조를 바꾸고(2.0), 마침내 전송 계층 자체를 교체(3.0)하는 근본적인 재설계의 과정이었습니다.

지금도 웹 서버와 브라우저는 상황에 따라 HTTP/1.1, 2, 3을 오가며 최적의 방식으로 대화하고 있습니다. 단순한 텍스트 전송에서 시작해 전송 계층의 한계까지 뛰어넘은 HTTP. 그 끊임없는 진화 덕분에 우리는 오늘도 쾌적한 웹 서핑을 즐기고 있습니다.

User-Agent는 왜 자기를 크롬, 사파리라고 소개할까?

테크리빗 — Tue, 30 Dec 2025 04:44:43 +0900

보안 장비나 웹 서버 로그를 분석하다 보면, User-Agent(UA) 필드에서 이상한 점을 발견하게 됩니다.

왜 하나의 User-Agent에 Chorme이고, Mozilla이고, AppleWebKit이며, 심지어 Safari라고 적혀 있는 걸까?"

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

결론부터 말하면, 현대 브라우저의 User-Agent는 '호환성'을 위해 서로의 이름을 빌려 쓰는 구조로 되어 있습니다.

User-Agent의 역사

이 복잡한 이름의 기원은 1990년대 '브라우저 전쟁' 시절로 거슬러 올라갑니다.

Mozilla/5.0의 시작: 초창기 웹의 패권은 넷스케이프(Netscape, 코드명 Mozilla)가 쥐고 있었습니다. 많은 웹사이트가 User-Agent: Mozilla가 아니면 접속을 차단하거나 깨진 화면을 보여줬습니다.
MS의 꼼수: 후발 주자인 마이크로소프트의 Internet Explorer(IE)는 웹사이트들이 자신을 넷스케이프로 착각하게 만들어야 했습니다. 그래서 관행적으로 Mozilla/...를 UA 맨 앞에 붙이기 시작했습니다.
오픈소의 등장 (Gecko, KHTML): 이후 넷스케이프의 후예인 파이어폭스(Gecko 엔진)가 등장했고, 리눅스 진영에서는 KHTML 엔진이 나왔습니다. 이들도 호환성을 위해 like Gecko 같은 문구를 추가했습니다.
애플과 구글의 참전: 애플이 사파리(WebKit 엔진)를 만들 때 KHTML 기반임을 알리기 위해 KHTML, like Gecko를 넣었고, 구글이 크롬을 만들 땐 "나 사파리(WebKit) 기반이야!"라고 알리기 위해 Safari 키워드를 추가했습니다.

결국, 오늘날의 크롬 브라우저 UA에 Mozilla, AppleWebKit, Safari가 모두 포함되어 있는 것은 "나 이 모든 브라우저들과 호환되니까 막지 말고 화면을 제대로 보여줘!"라고 외치는 지극히 정상적인 신호입니다..

그럼 어떻게 구분하지?

그렇다면 다 섞여 있는 이 난장판 속에서 진짜 정체는 어떻게 파악해야 할까요? 핵심은 로그를 '뒤에서부터' 읽는 것입니다. 대부분의 브라우저는 자신의 '진짜 이름'을 문자열의 가장 마지막에 덧붙입니다.

브라우저	UA 특징 패턴
Chrome	... Chrome/버전 Safari/버전 (사파리 키워드로 끝나지만, 앞에 Chrome이 명시됨)
Edge	... Chrome/... Safari/... Edg/버전 (맨 뒤에 Edg가 붙음)
Whale	... Chrome/... Safari/... Whale/버전 (맨 뒤에 Whale이 붙음)
Safari	... AppleWebKit/... (중간에 Chrome 없음) ... Safari/버전

분석 팁: 로그에 AppleWebKit이나 Safari가 찍혀 있다고 해서 무조건 아이폰이나 맥북 사용자가 아닙니다. 전체 문자열에 Chrome, Edg, Android 등이 포함되어 있는지 반드시 확인해야 오탐(False Positive)을 줄일 수 있습니다.

보안 관점에서 '의심스러운 UA' 식별법

1) 너무 짧거나 성의 없는 UA

일반 브라우저는 OS, 엔진, 버전 정보를 길게 나열합니다. 반면, 자동화 도구는 기본값 그대로 들어오는 경우가 많습니다.

Mozilla/5.0 (뒤에 아무 정보 없이 달랑 이것만 있는 경우)
Python-urllib/3.9, python-requests (파이썬 스크립트)
curl/7.68.0, axios (API 요청 도구)

2) 치명적인 오타 (Human Error)

공격자가 스크립트 작성 시 수동으로 UA를 조작하다가 실수를 범하기도 합니다. 정규 브라우저라면 절대 낼 수 없는 오타입니다.

Mozlila/5.0 (Mozilla의 오타)
AppleWebkit (WebKit의 대문자 'K' 표기 실수)

3) 'Headless' 키워드 노출

브라우저 창을 띄우지 않고 백그라운드에서 실행되는 봇들은 종종 자신의 정체를 숨기지 못합니다.

... Chrome/120.0.0.0 HeadlessChrome/120.0.0.0 ...
Headless라는 단어가 보이면 크롤러, 매크로, 혹은 자동화된 공격 도구일 가능성이 99%입니다.

참고자료

https://yozm.wishket.com/magazine/detail/1307/

코인 탈취 공격: 클립보드 하이재킹 (Clipboard Hijacking)

테크리빗 — Sun, 28 Dec 2025 15:46:57 +0900

바로 며칠 전 터진 '17억 원대 가상자산 탈취 사건'을 통해 반드시 지켜야 할 보안 습관에 대해 이야기해 보려 합니다.

https://www.joongang.co.kr/article/25393253

악성코드로 비트코인 17억 가로챈 외국인 해커 한국 송환 | 중앙일보

악성 프로그램을 설치해 마음대로 수신 주소를 바꿔 17억원이 넘는 가상자산을 가로챈 외국인 해커가 한국으로 송환됐다. 경찰청 국가수사본부는 한국인 등을 상대로 가상자산을 가로챈 혐의를

www.joongang.co.kr

1. 도대체 어떻게 털린 걸까? (사건의 본질)

기사에서는 '메모리 해킹'이라고 하는데,

좀 더 정확한 용어는 바로 '클립보드 하이재킹(Clipboard Hijacking)'입니다.

자, 상황을 상상해봅시다.

코인을 보내려고 지갑 주소를 Ctrl+C (복사) 합니다.

그리고 거래소 화면에 Ctrl+V (붙여 넣기)를 할 것입니다.

당연히 복사한 주소가 그대로 붙었을 거라고 생각하겠죠?

그런데 그 찰나의 순간, 주소가 바뀌었다면?

내부적으로 PC에 몰래 숨어있던 악성코드가 메모리(RAM)에 상주하면서 네가 '복사하기'를 누르는 순간만 기다립니다.

그러다 클립보드에 코인 지갑 주소 같은 문자열이 들어오면, 순식간에 해커의 지갑 주소로 바꿔치기를 해버리는 거죠.

우리는 보통 주소가 너무 기니까 '앞자리 몇 개', '뒷자리 몇 개'만 확인하고 전송 버튼을 누르잖아요?

해커들은 그것까지 노려서 앞뒤가 비슷한 주소를 생성해서 공격합니다. 소름 돋지 않나요?

그럼 이 악성코드는 어디서 왔을까요?

바로 '불법 프로그램'입니다. 윈도우 정품 인증 툴(KMSAuto) 같은 크랙 프로그램에 트로이 목마처럼 숨어 들어온 거죠.

2. 그래서 어떻게 해야 하나요?

"에이, 설마 제가 당하겠어요?"라고 생각하고 있죠?

보안 사고는 그 방심을 틈타서 들어옵니다. 내 자산을 지키기 위해 코인전송시 2가지를 대응방안을 권장드립니다.

1. '불법프로그램' 깔지 마세요.

소프트웨어 라이선스는 더더욱 존중해야 합니다.

윤리적인 이유도 있지만, 보안적인 이유가 더 큽니다.

세상에 공짜는 없어요. 해커들이 수십만 원짜리 프로그램을 왜 공짜로 크랙 해서 배포할까요? 자선사업가라서? 절대 아니죠. 그 파일 안에 백도어(Backdoor)나 키로거, 그리고 이번 같은 클립보드 하이재킹 툴을 심어놓기 때문입니다.

코인 거래를 하거나 중요한 개발을 하는 PC라면, 반드시 정품 소프트웨어만 사용하세요. 그게 가장 싸게 먹히는 보험입니다.

2. 송금은 무조건 '두 번'에 나눠서 하세요.

이건 귀찮아도 무조건 지켜야 하는 '국룰'입니다.

1차 전송 (테스트): 최소 금액(전송 가능한 가장 적은 단위)만 먼저 보내보세요.
확인: 상대방(혹은 내 다른 지갑)에 정상적으로 도착했는지 확인하세요.
2차 전송 (본 송금): 확인이 끝났다면, 방금 성공한 그 '최근 거래 내역'의 주소를 클릭해서 나머지를 보내세요.

"아, 수수료 아깝게 왜 두 번 보내요?"

17억 잃는 것보다 수수료 몇백 원, 몇천 원 더 내는 게 낫지 않을까요?

돌다리도 두들겨 보고 건너는 습관, 이게 진짜 고수입니다.

3. '주소록(Whitelist)' 기능을 적극 활용하세요.

매번 주소를 Ctrl+C, Ctrl+V 하는 건 귀찮기도 하지만, 보안상으로도 가장 위험한 행동입니다.

자주 보내는 거래소나 개인 지갑 주소는 미리 거래소나 지갑 앱의 '주소록' 기능에 등록해 두세요.

저장된 주소를 클릭해서 전송하면 클립보드를 거치지 않기 때문에, 악성코드가 주소를 바꿔치기할 틈이 아예 사라집니다. 공격 경로를 원천 차단하는 셈이죠.

(주의) 단, 처음 주소를 등록할 때는 정말 눈을 부릅뜨고 확인해야 합니다. 등록하는 순간에 하이재킹 당하면, 그 뒤로는 계속 해커한테 돈을 보내게 되니까요.

https://0urtrees.tistory.com/256

바이낸스 코인출금 보안설정, 화이트리스트 등록방법

안녕하세요? 해외거래소 바이낸스에서는 코인 출금과 관련한 보안설정 옵션을 갖고 있습니다. 그것은 바로 "화이트리스트" 인데요. 화이트리스트로 등록한 주소가 아닌 기타 주소로는 출금을

0urtrees.tistory.com

마치며: 자유에는 책임이 따릅니다.

오늘 이야기한 내용은 엄청난 보안 기술이 필요한 게 아닙니다.

'한 번 더 의심하고, 정해진 원칙을 지키는 태도'가 전부죠.

마지막으로 꼭 기억해야 할 게 있어요.

우리가 열광하는 '암호화폐'와 '블록체인'의 핵심은 탈중앙화(Decentralization)잖아요?

이건 반대로 말하면, 은행처럼 비밀번호를 찾아주거나 잘못 보낸 돈을 취소해 줄 '고객센터'가 존재하지 않는다는 뜻이기도 합니다.

내 자산을 지키는 주체도, 책임지는 주체도 오직 '나 자신'뿐입니다.

탈중앙화된 세상에서 자유를 누리는 만큼, 보안에 대해서는 중앙 집중형 시스템보다 훨씬 더 엄격하고 냉정해져야 합니다.

이 글을 읽은 분들은, 부디 "복사 붙여넣기" 한 방에 피 같은 자산을 날리는 일이 없기를 바랍니다.

구간 합 (Interval Sum)

테크리빗 — Tue, 23 Dec 2025 02:59:51 +0900

구간합이란

배열의 처음부터 특정 인덱스까지의 합(누적 합)을 미리 구해놓은 별도의 배열(합 배열)을 이용하여,

특정 구간의 합의 시간복잡도를 O(N)에서 O(1)으로 줄일 수 있습니다.

핵심 공식

1차원 합배열 공식

기존 리스트 A가 있을 때 합 배열 S는 아래와 같은 구조입니다.

S [i] = A [0] + A [1] +... + A [i]

위와 같은 합배열을 좀 더 추상화시키면 아래와 같습니다.

S [i] = S [i-1] + A [i]

1차원 구간합 공식

그렇다면 합배열을 이용해 구간합을 구하는 공식은 어떻게 될까요?

A [2]부터 A [5]까지의 구간합을 구한다고 하면

A [0] ~ A[5] 부터 A[0] ~ A [1]의 차이를 구하는 것과 같습니다.

이는 S [5] - S [1]로 표현할 수 있습니다.

이를 추상화해서

i번째부터 j번째까지의 합을 구한다고 한다면 아래와 같습니다.

S(i, j) = S [j] - S [i-1]

출처: https://velog.io/@alkwen0996/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EB%88%84%EC%A0%81%ED%95%A9Prefix-Sum-2%EC%B0%A8%EC%9B%90-%EB%88%84%EC%A0%81%ED%95%A9Prefix-Sum-of-Matrix

2차원 합배열

2차원 합 배열 공식은 수식으로만 보면 복잡하지만, '넓이 구하기(면적)' 관점에서 보면 매우 직관적입니다.

핵심은 "이미 구해놓은 넓이를 재활용하자"는 것입니다.

A [0,0] ~ A [4,2]를 의미하는 S [4,2]인 녹색영역의 직사각형 넓이(합배열)를 구하려면 어떻게 해야 할까요?

이걸 매번 처음부터 다 더하는 게 아니라, A [4,2]를 기준으로 내 바로 위쪽과 내 바로 왼쪽에 있는 이미 계산된 직사각형들을 합쳐서 만듭니다.

출처: https://velog.io/@alkwen0996/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EB%88%84%EC%A0%81%ED%95%A9Prefix-Sum-2%EC%B0%A8%EC%9B%90-%EB%88%84%EC%A0%81%ED%95%A9Prefix-Sum-of-Matrix

위쪽 직사각형인 S [3,2]와 왼쪽 직사각형인 S [4,1]를 더해주고, 중복되는 영역인 S [3,1]를 빼준다음 A [4,2]만 더하면 됩니다.

이를 식으로 나타내면 아래와 같습니다.

S [4,2] = S [3,2] + S [4,1] - S [3,1] + A [4,2]

이를 추상화하면 아래와 같습니다.

S [i][j] = S [i-1][j] + S [i][j-1] - S [i-1][j-1] + A [i][j]가 됩니다.

2차원 구간합

A [3,3] ~ A [4,4]인 파란색 영역을 구간합으로 구하고 싶으면 어떻게 해야 할까요?

전체 구간합인 S [4,4]에서 주황색 영역인 S [2,4]와 초록색 영역인 S [4,2]를 빼준다음 두 번 빼버린 부분인 S [2,2]를 더 해주면 됩니다.

정리하면 A [3,3] ~ A [4,4] = S [4,4] - S [2,4] - S [4,2] + S [2,2]입니다.

출처: https://velog.io/@alkwen0996/%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EB%88%84%EC%A0%81%ED%95%A9Prefix-Sum-2%EC%B0%A8%EC%9B%90-%EB%88%84%EC%A0%81%ED%95%A9Prefix-Sum-of-Matrix

면접에 나오는 라우팅 프로토콜과 라우티드 프로토콜

테크리빗 — Mon, 22 Dec 2025 20:09:37 +0900

최근 클라우드 및 네트워크 엔지니어 신입 면접 질문들을 검색하다 보니, "라우팅 프로토콜과 라우티드 프로토콜의 차이"를 묻는 경우가 있다는 것을 알게 되었습니다.

솔직히 현업에서는 이 두 용어를 엄격하게 구분해서 쓰는 경우는 못 봤기에, 아마도 기본기를 확인하기 위한 전형적인 '면접용 질문'이 아닐까 조심스럽게 생각해 봅니다.

두 프로토콜을 구분하기 전에 '라우팅'이라는 개념이 무엇인지부터 짚고 넘어가보겠습니다.

라우팅(Routing)이란?

라우팅(Routing)은 쉽게 말해 "데이터가 목적지까지 가는 최적의 경로를 찾는 행위"입니다.

우리가 내비게이션을 켜고 목적지를 찍으면, 수많은 도로 중에서 가장 빠르고 안 막히는 최적의 경로를 찾아주는 것을 통해 내비게이션이 라우팅을 했다고 볼 수 있습니다.

출처: https://www.geeksforgeeks.org/computer-networks/what-is-routing/

이 '길 찾기' 과정에서 누가 이동하는지(대상)와 어떤 알고리즘으로 길을 찾는지(방법)에 따라 두 프로토콜이 나뉩니다.

라우티드 프로토콜 (Routed Protocol)

라우터가 경로를 찾으려면 패킷에 "나는 서울로 갑니다"라는 목적지 주소가 적혀 있어야 합니다. 이때 "주소는 맨 앞 몇 번째 비트에 적고, 어떤 형식을 따르자"라고 정의한 약속이 바로 라우티드 프로토콜입니다.

가장 대표적인 예시가 바로 우리가 매일 쓰는 IP(IPv4, IPv6)입니다.

출처: https://www.cloudflare.com/ko-kr/learning/network-layer/internet-protocol/

(참고) 과거에는 IPX, AppleTalk 포함하여 라우티드 프로토콜이라고 부름.

(주의) TCP, HTTP는 라우티드 프로토콜일까?

결론부터 말하면 아닙니다. 라우터는 3 계층 장비로서 겉봉투에 적힌 IP 주소만 보고 길을 안내하기 때문에, 내용물인 TCP나 HTTP는 라우티드 프로토콜이라고 부르지 않습니다.

(동적) 라우팅 프로토콜 (Routing Protocol)

라우팅 프로토콜은 쉽게 말해 라우팅을 알아서 해주는 프로토콜입니다.

관리자가 일일이 길을 지정하는 '정적(Static) 라우팅'과 달리, 네트워크 상황에 맞춰 자동으로 최적 경로를 찾아주기 때문에 동적(Dynamic) 라우팅을 할 때 사용됩니다. 라우팅 프로토콜을 사용한다면, 동적라우팅을 쓰는구나라고 이해하면 됩니다.

대표적인 프로토콜은 RIP, OSPF, EIGRP, BGP가 있습니다.

정리

라우티드 프로토콜은 라우팅 경로를 이동하는 데이터 패킷 다시말해 IP 패킷을 의미한다.

라우팅 프로토콜은 동적라우팅을 위해 사용되는 프로토콜이다.