28일 신고가 돌파 직후 10일간의 횡보, 그리고 -13% 8월 저점 대비 70% 오른 자리에서 들어간 돌파 매수가 단 하루의 급락으로 끝난 날의 기록. 요약 항목 값 총 거래 1건 승 / 패 0 / 1 총 P&L -7.07 USDT 총 수수료 -0.08 USDT 평균 P&L -7.07 USDT 승률 0% 포트폴리오 현황 항목 값 USDT 잔고 261.79 활성 포지션 AVAX(158), SHIB(0), APT(61), PEPE(0), ETHFI(42), MUBARAK(161), BROCCOLI714(53) 미실현 P&L +113.52 USDT 총 포트폴리오 736.96 USDT 거래 상세 1. DOTUSDT — SL (-) 항목 값 진입 2026-09-26 15:55:08 @ 1.287 청산 2026-10-07 02:01:17 @ 1.12 수량 41.91000000 매수 금액 53.94 USDT 매도 금액 46.94 USDT 수수료 -0.0757 USDT P&L -7.07 USDT (-13.12%) 보유 기간 10일 청산 유형 SL 진입 근거: 9월 7일 고점(약 1.29)으로 형성된 28일 Upper Channel을 9월 26일 상향 돌파, 시스템 룰에 따른 정상 진입. 8월 18일 저점 0.75 이후 MA7 > MA28 > MA90 정배열이 유지되던 구간으로, 추세 방향 자체는 상승과 일치. 다만 돌파 당일 볼륨은 9월 초 급등 때 대비 평범한 수준이었고, 돌파 폭도 직전 고점을 간신히 넘는 marginal break였음. 잘한 점 / 아쉬운 점: 잘한 점: 진입 다음 날부터 가격이 1.15~1.25 박스에 갇혀 10일간 재돌파 실패했음에도 SL 도달 전까지 임의 청산하지 않고 시스템을 신뢰함. 잘한 점: 10월 7일 장대 음봉이 SL 라인을 관통했지만 1.12 SL 가격에 체결되어 슬리피지 없이 손실을 제한함. 손실 금액은 포트폴리오의 약 1%로 2% 룰 내. 아쉬운 점: 저점 대비 70% 상승 후의 돌파였고, 직전 고점(9/7) 돌파 실패 이력이 있는 구간이라 Upper Channel이 저항으로 작동한 double-top 형태로 마무리됨. 아쉬운 점: 진입 후 한 번도 의미 있는 추가 상승이 없어 피라미딩 기회 자체가 없었음. 돌파 후 즉시 되밀리는 패턴은 추세 추종 관점에서 가장 비용이 큰 유형. 코인 소개: DOT 마켓 순위: #54 (CoinGecko) 카테고리: Smart Contract Platform, Polkadot Ecosystem, Proof of Stake (PoS), Layer 0 (L0), Pantera Capital Portfolio, GMCI 30 Index, GMCI Index, Made in USA, Coinbase 50 Index, Governance, Base Native Polkadot은 여러 체인(parachain)을 하나의 보안 계층 아래 연결하는 Layer 0 인터체인 플랫폼으로, 2026년 현재 Polkadot 2.0의 Agile Coretime 체제가 가동 중이며 Relay Chain을 대체하는 차세대 프로토콜 JAM(Join-Accumulate Machine)이 핵심 로드맵 네러티브. 2026년 3월 거버넌스를 통해 총 공급량 21억 개 hard cap과 인플레이션 53.6% 감축이 통과되어 토크노믹스가 크게 바뀐 점이 최근 가격 관심의 주요 배경. 시스템 업데이트 (해당 날짜 변경 없음) 일일 회고 오늘의 교훈 28일 신고가 돌파라도 직전 고점을 간신히 넘는 marginal break는 저항 재확인(double top)으로 끝날 확률이 높다. 돌파 폭과 볼륨은 시그널 강도의 핵심 변수. 돌파 후 10일간 진입가를 회복하지 못하는 포지션은 "추세가 아직 안 왔다"는 신호다. 이런 거래의 손실은 시스템이 당연히 지불해야 하는 비용이며, 터틀 방식에서 승률 0%인 날은 통계적으로 정상 범위. 잘한 점 SL 체결가가 설정가와 일치하여 급락장에서도 리스크 통제가 계획대로 작동함. 1회 손실이 포트폴리오의 약 1%로 2% 한도 내에 머물렀고, 미실현 +113 USDT의 다른 포지션들이 손실을 충분히 상쇄 중. 아쉬운 점 8월 저점 대비 70% 상승 후의 늦은 진입이었음에도 포지션 사이즈를 줄이는 장치가 없어 평범한 비중으로 늘어난 구간에 올라탐. 누적 P&L이 -393.5 USDT로 여전히 우하향 추세. 소액 승리는 잦지만 손실을 덮을 홈런급 거래가 부족한 구조가 이어지고 있음. 다음에 적용할 점 돌파 시그널의 품질 지표(직전 고점 대비 돌파 폭, 돌파 봉 볼륨 비율)를 백테스트로 검증하고, 유의미하면 진입 필터가 아닌 사이즈 조절 변수로 반영 검토. 보유 중인 7개 포지션의 미실현 수익을 TS로 끝까지 끌고 가는 데 집중. 손절은 계획대로 작동했으니 이제 수익을 길게 가져가는 쪽에서 기대값을 회복해야 함.
이번 실습에서는 ROS 2의 실행 인자 프로그래밍(Python)을 진행했다. argparse 를 이용해 실행 인자를 설정하고, checker 노드 실행 시 목표 합계값을 직접 전달하는 과정을 실습했다. 1. 실행 인자란? 실행 인자는 프로그램을 실행할 때 명령어와 함께 전달하는 값이다. 이전에 checker 노드를 실행하면서 다음과 같은 명령어를 사용했었다. ros2 run topic_service_action_rclpy_example checker -g 100 여기서 -g 100 이 실행 인자다. ros2 run ↓ checker 실행 ↓ -g 100 ↓ goal_total_sum = 100 PPT에서는 Parameter는 매개 변수, Argument는 실행 인자로 구분해서 설명하고 있다. 2. Python에서 실행 인자 처리 Python에서는 argparse 모듈을 이용해 실행 인자를 처리한다. 실행 인자를 처리하는 과정은 다음과 같다. 1. parser 만들기 ↓ 2. 인자 추가하기 ↓ 3. 인자 파싱하기 ↓ 4. args.xxx로 사용하기 checker/main.py 에서는 sys.argv[1:] 를 이용해 실행 인자를 전달받도록 작성되어 있다. def main(argv=sys.argv[1:]): 그리고 ArgumentParser 를 생성한다. parser = argparse.ArgumentParser( formatter_class=argparse.ArgumentDefaultsHelpFormatter) 3. 실행 인자 추가하기 -g 와 --goal_total_sum 을 실행 인자로 등록했다. parser.add_argument( '-g', '--goal_total_sum', type=int, default=50, help='Target goal value of total sum') 여기서 -g : 짧은 형태 --goal_total_sum : 긴 형태 type=int : 정수형으로 처리 default=50 : 기본값 50 help : 도움말에 표시할 설명 으로 설정되어 있다. 4. 실행 인자 파싱 등록한 실행 인자는 parse_args() 를 통해 분석한다. args = parser.parse_args() 그다음 args.goal_total_sum 을 이용해 실제 값을 사용할 수 있다. checker.send_goal_total_sum(args.goal_total_sum) 즉 실행 인자로 입력한 값이 Checker 의 Goal 값으로 전달된다. 전체적인 흐름은 다음과 같다. 실행 인자 입력 ↓ argparse ↓ parse_args() ↓ args.goal_total_sum ↓ send_goal_total_sum() 5. 기본값으로 실행 먼저 실행 인자를 입력하지 않고 checker 를 실행했다. ros2 run topic_service_action_rclpy_example checker 이 경우 별도의 -g 값을 입력하지 않았기 때문에 goal_total_sum 의 기본값인 50 이 사용된다. 6. -g 를 이용해 실행 이번에는 목표값을 100 으로 지정해서 실행했다. ros2 run topic_service_action_rclpy_example checker -g 100 -g 100 이 실행 인자로 전달되는 것을 확인했다. 즉, -g 100 ↓ args.goal_total_sum = 100 의 형태로 값이 전달된다. 7. -h 로 도움말 확인 실행 인자의 사용 방법을 확인하기 위해 -h 옵션도 사용했다. ros2 run topic_service_action_rclpy_example checker -h 실행 결과: usage: checker [-h] [-g GOAL_TOTAL_SUM] ... positional arguments: argv Pass arbitrary arguments to the executable options: -h, --help show this help message and exit -g GOAL_TOTAL_SUM, --goal_total_sum GOAL_TOTAL_SUM Target goal value of total sum (default: 50) -g 와 --goal_total_sum 을 사용할 수 있고, 기본값이 50 이라는 것을 확인할 수 있었다. 8. 긴 형태의 실행 인자 사용 짧은 형태인 -g 뿐만 아니라 긴 형태인 --goal_total_sum 도 사용할 수 있는지 확인했다. ros2 run topic_service_action_rclpy_example checker --goal_total_sum 100 실행 결과에서 Arithmetic action server is not available. 경고가 출력됐지만, 이는 실행 인자 오류가 아니라 당시 calculator 의 Action Server가 실행되고 있지 않았기 때문에 발생한 메시지였다. 실행 인자 자체는 정상적으로 인식되는 것을 확인했다. 9. 실행 인자가 실제로 사용되는 부분 확인 마지막으로 args.goal_total_sum 이 실제 코드에서 어디에 사용되는지 확인했다. checker.send_goal_total_sum(args.goal_total_sum) 즉 argparse 로 분석한 실행 인자를 send_goal_total_sum() 에 전달하고, 해당 값이 Action의 Goal 값으로 사용되는 구조다. 마무리 이번 실습을 통해 ROS 2 Python에서 실행 인자를 처리하는 방법을 확인했다. sys.argv[1:] 로 실행 인자 전달 argparse.ArgumentParser() 로 parser 생성 add_argument() 로 실행 인자 등록 parse_args() 로 실행 인자 분석 args.goal_total_sum 으로 값 사용 -g 100 으로 실행 인자 전달 --goal_total_sum 100 으로 긴 형태의 실행 인자 전달 -h 를 이용한 실행 인자 도움말 확인
『Real MySQL 8.0』 7장을 읽고, 핵심 개념을 쉽게 이해할 수 있도록 제 방식대로 정리한 글입니다. 📌 들어가기 전에 왜 데이터를 암호화할까? 개인정보, 결제 정보 같은 민감한 데이터 를 보호하기 위해서입니다. 서버의 디스크나 백업 파일이 유출되더라도, 암호화 키가 없으면 내용을 읽을 수 없게 만드는 것이 목적입니다. MySQL 8.0 암호화 대상 한눈에 보기 암호화 대상 설정 다루는 절 테이블(데이터 파일) ENCRYPTION = 'Y' 7.3 언두 로그 / 리두 로그 innodb_undo_log_encrypt , innodb_redo_log_encrypt 7.4 바이너리 로그 / 릴레이 로그 binlog_encryption 7.5 💡 테이블만 암호화하고 로그를 암호화하지 않으면, 로그 파일에 데이터가 평문으로 남을 수 있습니다. 그래서 실제로는 세 가지를 함께 고려해야 합니다. 7.1 MySQL 서버의 데이터 암호화 TDE (Transparent Data Encryption) MySQL의 데이터 암호화는 디스크에 쓰고 읽는 시점 에 동작합니다. [쓰기] 버퍼 풀 (평문) ──암호화──▶ 디스크 (암호문) [읽기] 디스크 (암호문) ──복호화──▶ 버퍼 풀 (평문) MySQL 서버의 다른 부분(쿼리 처리 등)은 데이터가 암호화됐는지 전혀 신경 쓰지 않습니다. 사용자 입장에서도 일반 테이블과 똑같이 사용합니다. 그래서 이 방식을 투명한 데이터 암호화(TDE, Transparent Data Encryption) 라고 부릅니다. 디스크에 저장된 상태의 데이터를 보호한다는 의미로 Data at Rest Encryption 이라고도 합니다. 에디션별 키 관리 방식 (키링 플러그인) 암호화 키는 키링(Keyring) 플러그인 을 통해 관리합니다. 에디션 사용 가능한 키링 커뮤니티 keyring_file (마스터 키를 디스크 파일 에 저장) 엔터프라이즈 keyring_file , keyring_encrypted_file , keyring_okv , keyring_aws 등 (외부 키 관리 서버 연동 가능) 7.1.1 2단계 키 관리 MySQL은 키를 두 단계 로 나눠서 관리합니다. ┌──────────── 키링 (외부 파일 / 키 관리 서버) ────────────┐ │ 🔑 마스터 키 (Master Key) │ └───────────────────────┬──────────────────────────┘ │ 테이블스페이스 키를 암호화 ▼ ┌──────────── 각 테이블 데이터 파일 헤더 ─────────────────┐ │ 🔐 테이블스페이스 키 (Tablespace Key) │ │ (마스터 키로 암호화된 상태로 저장) │ └───────────────────────┬──────────────────────────┘ │ 실제 데이터를 암호화 ▼ ┌──────────── 데이터 파일 ─────────────────────────────┐ │ 📄 암호화된 데이터 │ └──────────────────────────────────────────────────┘ 키 저장 위치 역할 마스터 키 키링(외부 파일 또는 키 관리 서버) 테이블스페이스 키를 암호화 테이블스페이스 키 각 테이블 데이터 파일의 헤더 (마스터 키로 암호화된 상태) 실제 데이터를 암호화 🧩 비유 테이블스페이스 키 = 각 방(테이블)의 문을 여는 열쇠 마스터 키 = 그 방 열쇠들을 넣어둔 금고의 열쇠 금고 열쇠(마스터 키)는 건물 밖(키링)에 따로 보관 왜 2단계로 나눌까? → 마스터 키 변경이 빠르다 보안 정책상 키는 주기적으로 변경 해야 합니다. ALTER INSTANCE ROTATE INNODB MASTER KEY; 마스터 키 변경 시 1. 새로운 마스터 키 발급 2. 모든 테이블스페이스 키를 기존 마스터 키로 복호화 3. 새 마스터 키로 다시 암호화해서 데이터 파일 헤더에 저장 → 데이터 파일 전체를 다시 암호화할 필요 없음 ✅ 키를 하나만 쓴다면 2단계 키를 쓴다면 키를 바꿀 때마다 모든 데이터 파일을 다시 암호화 → 매우 오래 걸림 테이블스페이스 키만 다시 암호화 → 빠름 💡 테이블스페이스 키는 MySQL 서버 외부로 노출되지 않기 때문에 따로 변경할 필요가 없습니다. 암호화 알고리즘 대상 알고리즘 테이블스페이스 키 암호화 AES 256비트 (ECB 모드) 실제 데이터 암호화 AES 256비트 (CBC 모드) 7.1.2 암호화와 성능 언제 암호화·복호화가 일어날까? 작업 시점 사용자 응답에 영향 복호화 디스크에서 읽어 버퍼 풀에 올릴 때 한 번 디스크에서 읽어야 하는 경우 약간 느려짐 암호화 더티 페이지를 디스크에 기록할 때 백그라운드 스레드가 처리하므로 거의 없음 버퍼 풀에 이미 있는 데이터 → 이미 복호화된 상태 → 추가 비용 없음 ✅ 버퍼 풀에 없는 데이터 → 디스크에서 읽으며 복호화 → 약간의 지연 💡 데이터 대부분이 버퍼 풀에 올라와 있는 서버라면, 암호화로 인한 성능 영향은 크지 않습니다. 책의 테스트에서도 페이지 하나를 읽고 쓰는 시간은 몇 배 늘어났지만, 마이크로초 단위 라 체감은 크지 않은 수준이었습니다. 암호화 + 압축을 함께 쓴다면? 1 압축 먼저 → 2 그 다음 암호화 이유 설명 압축 효율 암호화된 데이터는 랜덤한 바이트처럼 보여서 거의 압축되지 않음 → 압축을 먼저 해야 효과가 있음 버퍼 풀 활용 버퍼 풀에는 압축만 된(암호화되지 않은) 페이지 가 올라오므로, 버퍼 풀 안에서는 복호화가 필요 없음 7.1.3 암호화와 복제 소스 서버와 레플리카는 각자의 마스터 키를 가진다 ┌─── 소스 서버 ───┐ ┌─── 레플리카 ───┐ │ 🔑 마스터 키 A │ ──복제──▶ │ 🔑 마스터 키 B │ │ 데이터: 동일 │ │ 데이터: 동일 │ │ 파일 내용: 다름 │ │ 파일 내용: 다름 │ └───────────────┘ └───────────────┘ 복제 소스와 레플리카는 서로 다른 마스터 키 를 사용합니다. 그래서 데이터 내용은 같아도, 암호화된 데이터 파일 내용은 서로 다릅니다. ALTER INSTANCE ROTATE INNODB MASTER KEY 명령이 레플리카로 복제되더라도, 레플리카는 자기만의 새로운 마스터 키 를 생성합니다. ⚠️ 백업 시 주의 주의점 설명 키링 파일도 백업 키링 파일이 없으면 백업한 데이터를 복구할 수 없음 분리 보관 키링 파일을 데이터 백업과 같은 곳에 두면 암호화한 의미가 없음 → 별도로 안전하게 보관 💡 TDE를 사용한다면, 데이터 백업 + 키링 파일 백업 을 함께 관리해야 합니다. 7.2 keyring_file 플러그인 설치 keyring_file 플러그인이란? MySQL 커뮤니티 에디션에서 사용할 수 있는 키링 플러그인입니다. 마스터 키를 디스크의 파일 에 저장합니다. ⚠️ 마스터 키가 평문 파일 로 저장되기 때문에, 파일이 유출되면 암호화가 무의미해집니다. 파일 위치와 접근 권한을 철저히 관리해야 합니다. 설치 방법 키링 플러그인은 다른 플러그인보다 먼저 초기화되어야 하므로, early-plugin-load 옵션으로 설정합니다. # my.cnf [mysqld] early-plugin-load = keyring_file.so keyring_file_data = /very/secure/directory/tde_master.key 설정 설명 early-plugin-load MySQL 서버가 시작될 때 가장 먼저 로드할 플러그인 keyring_file_data 마스터 키를 저장할 파일 경로 💡 하나의 MySQL 서버에서 여러 인스턴스를 실행한다면, 인스턴스마다 다른 키링 파일 경로 를 지정해야 합니다. 설치 확인 SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'keyring%'; +--------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +--------------+---------------+ | keyring_file | ACTIVE | +--------------+---------------+ 서버를 시작하면 키링 파일이 빈 파일 로 생성됩니다. 실제 마스터 키는 암호화된 테이블을 처음 생성하거나 마스터 키를 로테이션할 때 만들어집니다. 💡 참고로 MySQL 8.0.24부터는 키링 플러그인 대신 컴포넌트 ( component_keyring_file ) 사용이 권장됩니다. 7.3 테이블 암호화 7.3.1 테이블 생성 암호화 테이블 생성 CREATE TABLE tab_encrypted ( id INT, data VARCHAR(100), PRIMARY KEY (id) ) ENCRYPTION = 'Y'; INSERT INTO tab_encrypted VALUES (1, 'test_data'); SELECT * FROM tab_encrypted; -- 일반 테이블과 똑같이 조회됨 💡 사용자 입장에서는 ENCRYPTION = 'Y' 옵션만 추가하면 되고, 사용 방법은 일반 테이블과 같습니다. 암호화된 테이블 확인 SELECT table_schema, table_name, create_options FROM information_schema.tables WHERE create_options LIKE '%ENCRYPTION="Y"%'; 모든 테이블을 기본으로 암호화하려면? SET GLOBAL default_table_encryption = ON; 이 설정을 켜면 ENCRYPTION 옵션을 지정하지 않아도 새로 생성하는 테이블이 자동으로 암호화 됩니다. 7.3.2 응용 프로그램 암호화와의 비교 암호화는 MySQL(TDE)에서 할 수도 있고, 애플리케이션에서 직접 할 수도 있습니다. [응용 프로그램 암호화] 애플리케이션: '1990' ──암호화──▶ 'xK9#mQ2...' ──저장──▶ MySQL → MySQL은 'xK9#mQ2...'가 무슨 값인지 모름 [TDE] 애플리케이션: '1990' ──저장──▶ MySQL ──디스크 기록 시 암호화──▶ 디스크 → MySQL 내부에서는 '1990'으로 인식 응용 프로그램 암호화의 문제점 애플리케이션에서 암호화한 값은 MySQL 입장에서 의미 없는 문자열 이기 때문에 이런 쿼리를 쓸 수 없습니다. -- birth_year 컬럼을 애플리케이션에서 암호화했다면 -- ❌ 범위 검색 불가 SELECT * FROM app_user WHERE birth_year BETWEEN 2000 AND 2010; -- ❌ 정렬 불가 SELECT * FROM app_user ORDER BY birth_year LIMIT 10; 문제 설명 범위 검색 불가 암호화된 값은 크기 비교가 의미 없음 정렬 불가 암호문 순서 ≠ 원래 값 순서 인덱스 활용 제한 범위 조건이나 정렬에 인덱스를 쓸 수 없음 비교 항목 응용 프로그램 암호화 TDE (MySQL 암호화) 암호화 위치 애플리케이션 MySQL 서버 (디스크 I/O 시점) 범위 검색 / 정렬 ❌ ✅ 인덱스 활용 제한적 일반 테이블과 동일 SQL로 조회 시 암호문 으로 보임 (DB 관리자도 내용을 모름) 평문 으로 보임 ✅ 정리 검색·정렬이 필요한 컬럼 → TDE DB 관리자에게도 노출되면 안 되는 민감한 컬럼(주민번호, 카드번호 등) → 응용 프로그램 암호화 보안 요구사항에 따라 두 가지를 함께 적용 할 수도 있습니다. 7.3.3 테이블스페이스 이동 테이블스페이스 이동이란? 테이블 데이터를 덤프해서 다시 넣는 대신, 데이터 파일( .ibd ) 자체를 복사 해서 다른 서버로 옮기는 기능입니다. 💡 데이터가 많을 때 mysqldump 로 덤프·적재하는 것보다 훨씬 빠릅니다. 일반 테이블 이동 과정 -- [원본 서버] FLUSH TABLES source_table FOR EXPORT; -- → source_table.cfg 파일 생성 (테이블 구조 정보) -- → .ibd, .cfg 파일 복사 UNLOCK TABLES; 암호화된 테이블이라면? 암호화된 테이블은 원본 서버의 마스터 키 로 테이블스페이스 키가 암호화되어 있습니다. 다른 서버는 그 마스터 키를 모르기 때문에, 파일만 복사하면 복호화할 수 없습니다. 그래서 FLUSH TABLES ... FOR EXPORT 실행 시 파일이 하나 더 생성됩니다. 파일 내용 .ibd 실제 데이터 파일 .cfg 테이블 구조 정보 .cfp 임시 마스터 키 로 암호화한 테이블스페이스 키 [원본 서버] FLUSH TABLES source_table FOR EXPORT; → 임시 마스터 키 생성 → 테이블스페이스 키를 임시 마스터 키로 암호화해서 .cfp 파일에 저장 → .ibd, .cfg, .cfp 파일 복사 UNLOCK TABLES; [대상 서버] ALTER TABLE target_table DISCARD TABLESPACE; → 복사한 .ibd, .cfg, .cfp 파일을 데이터 디렉터리에 배치 ALTER TABLE target_table IMPORT TABLESPACE; → .cfp 파일로 테이블스페이스 키를 복호화 → 대상 서버의 마스터 키로 다시 암호화해서 저장 ✅ ⚠️ .cfp 파일을 빠뜨리면 복구할 수 없습니다. 암호화된 테이블을 이동할 때는 반드시 .cfp 파일까지 함께 복사해야 합니다. 7.4 언두 로그 및 리두 로그 암호화 문제: 테이블만 암호화하면 로그는 평문 테이블 데이터 파일 → 암호화 ✅ 리두 로그 / 언두 로그 → 평문 ❌ ← 여기에 데이터 변경 내용이 그대로 남음 테이블을 암호화해도, 리두 로그와 언두 로그 에는 데이터 변경 내용이 평문으로 기록될 수 있습니다. MySQL 8.0.16부터 리두 로그와 언두 로그도 암호화할 수 있습니다. 설정 SET GLOBAL innodb_undo_log_encrypt = ON; SET GLOBAL innodb_redo_log_encrypt = ON; -- 설정 확인 SHOW GLOBAL VARIABLES LIKE 'innodb_%_log_encrypt'; 동작 방식 상황 결과 암호화를 켜면 켠 시점 이후 에 기록되는 로그만 암호화. 이전 로그는 평문 그대로 암호화를 끄면 이후 로그는 평문. 이미 암호화된 로그는 암호화된 상태 그대로 유지 ⚠️ 암호화를 껐더라도 이전에 암호화된 로그가 남아 있다면, 복구할 때 암호화 키가 여전히 필요 합니다. 키 관리 🔑 마스터 키 └─ 🔐 리두 로그 / 언두 로그 전용 프라이빗 키 (로그 파일 헤더에 암호화되어 저장) └─ 📄 리두 로그 / 언두 로그 데이터 암호화 리두 로그와 언두 로그는 테이블스페이스 키가 아니라, 각각의 프라이빗 키 로 암호화됩니다. 이 프라이빗 키는 마스터 키로 암호화 되어 로그 파일의 헤더 에 저장됩니다. 7.5 바이너리 로그 암호화 문제: 바이너리 로그도 평문 바이너리 로그에는 데이터 변경 내용이 그대로 기록됩니다. 바이너리 로그는 복제나 시점 복구(PITR)를 위해 오랫동안 보관 하는 경우가 많아서, 유출 위험도 큽니다. MySQL 8.0.14부터 바이너리 로그를 암호화할 수 있습니다. SET GLOBAL binlog_encryption = ON; 💡 바이너리 로그뿐 아니라 레플리카의 릴레이 로그 도 함께 암호화됩니다. 7.5.1 바이너리 로그 암호화 키 관리 바이너리 로그도 2단계 키 관리 방식을 사용합니다. ┌──────────── 키링 ────────────────────────────┐ │ 🔑 바이너리 로그 암호화 키 │ ← 테이블 암호화의 "마스터 키" 역할 └───────────────────┬─────────────────────────┘ │ 파일 키를 암호화 ▼ ┌──────────── 각 바이너리 로그 / 릴레이 로그 파일 헤더 ──┐ │ 🔐 파일 키 (File Key) │ ← 파일마다 하나씩 └───────────────────┬─────────────────────────┘ │ 실제 로그 데이터를 암호화 ▼ 📄 암호화된 바이너리 로그 키 비교 대상 역할 바이너리 로그 암호화 키 테이블 암호화의 마스터 키 파일 키를 암호화 파일 키 테이블 암호화의 테이블스페이스 키 바이너리 로그 파일마다 하나씩 생성되어 로그 데이터를 암호화 7.5.2 바이너리 로그 암호화 키 변경 ALTER INSTANCE ROTATE BINLOG MASTER KEY; 키 변경 과정 1. 새로운 바이너리 로그 암호화 키를 발급해서 키링 파일에 저장 2. 바이너리 로그 파일과 릴레이 로그 파일을 새 파일로 전환(로테이션) 3. 새로 생성되는 로그 파일의 파일 키는 새 암호화 키로 암호화 4. 기존 바이너리 로그·릴레이 로그 파일의 파일 키를 읽어서 새 암호화 키로 다시 암호화 (암호화되지 않은 로그 파일은 무시) 5. 모든 파일의 변환이 끝나면, 기존 바이너리 로그 암호화 키를 키링 파일에서 삭제 ⚠️ 4번은 보관 중인 바이너리 로그 파일이 많으면 시간이 오래 걸릴 수 있습니다. 대신 로그 데이터 전체가 아니라 파일 키만 다시 암호화 하므로, 2단계 키 관리 덕분에 그나마 빠르게 처리됩니다. 암호화 여부 확인 SHOW BINARY LOGS; +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | mysql-bin.000010 | 3047 | No | | mysql-bin.000011 | 512 | Yes | +------------------+-----------+-----------+ 7.5.3 mysqlbinlog 도구 활용 문제: 암호화된 바이너리 로그는 직접 열 수 없다 mysqlbinlog 는 바이너리 로그 내용을 확인하거나 시점 복구(PITR)를 할 때 많이 쓰는 도구입니다. 그런데 암호화된 바이너리 로그 파일을 직접 열면 에러가 발생 합니다. mysqlbinlog -vvv mysql-bin.000011 # → 파일이 암호화되어 있어서 읽을 수 없다는 에러 발생 ❌ 바이너리 로그 암호화 키는 MySQL 서버만 키링을 통해 접근할 수 있기 때문입니다. mysqlbinlog 는 키링에 직접 접근할 수 없습니다. 해결: MySQL 서버를 통해 읽기 mysqlbinlog -uroot -p -vvv --read-from-remote-server mysql-bin.000011 옵션 설명 --read-from-remote-server 파일을 직접 읽지 않고, MySQL 서버에 접속해서 바이너리 로그를 받아옴 mysqlbinlog ──요청──▶ MySQL 서버 (키링 접근 가능) │ 복호화 mysqlbinlog ◀──평문── MySQL 서버 💡 MySQL 서버가 바이너리 로그를 복호화해서 전달 하기 때문에 내용을 확인할 수 있습니다. ⚠️ 백업·복구 시 주의 백업해둔 암호화된 바이너리 로그를 나중에 사용하려면, 해당 키를 가진 MySQL 서버를 거쳐야 합니다. 그래서 바이너리 로그를 백업할 때는 키링 파일도 함께 백업 해야 합니다. ✍️ 마무리 정리 7.1 MySQL 서버의 데이터 암호화 TDE : 디스크에 쓸 때 암호화, 읽을 때 복호화. 사용자는 일반 테이블처럼 사용 2단계 키 관리 : 마스터 키(키링) → 테이블스페이스 키(데이터 파일 헤더) → 데이터 마스터 키 변경 시 테이블스페이스 키만 다시 암호화 하므로 빠름 버퍼 풀에 올라온 데이터는 복호화 상태 → 성능 영향은 크지 않음 압축과 함께 쓰면 압축 먼저, 암호화 나중 복제 소스와 레플리카는 각자의 마스터 키 사용, 키링 파일은 별도 백업 7.2 keyring_file 플러그인 설치 커뮤니티 에디션용, 마스터 키를 평문 파일 에 저장 → 파일 관리 주의 early-plugin-load 로 가장 먼저 로드 7.3 테이블 암호화 ENCRYPTION = 'Y' 로 생성, default_table_encryption 으로 기본값 설정 가능 응용 프로그램 암호화는 범위 검색·정렬 불가 , TDE는 제약 없음 암호화 테이블 이동 시 .cfp 파일 필수 7.4 언두 로그 및 리두 로그 암호화 innodb_undo_log_encrypt , innodb_redo_log_encrypt (8.0.16+) 켠 이후의 로그만 암호화, 끄더라도 기존 암호화 로그는 그대로 7.5 바이너리 로그 암호화 binlog_encryption (8.0.14+), 릴레이 로그도 함께 암호화 바이너리 로그 암호화 키 → 파일 키 → 로그 데이터 2단계
Warriors vs Northern Cape previews the 28th T20 match of the CSA T20 Challenge 2026, with both teams looking to strengthen their position in the competition. Warriors will aim to make the most of their batting depth and home conditions, while Northern Cape will look to counter with disciplined bowling and key contributions from their experienced players. With the match expected to feature an exciting contest between bat and ball, this Warriors vs Northern Cape Match Prediction covers the teams’ recent form, pitch conditions, predicted playing XIs and key players to watch before assessing who has the stronger chance of winning today’s match. Warriors vs Northern Cape, Match Details: Location: St George’s Park, Gqeberha, South Africa Venue: St George’s Park, Port Elizabeth Date & Time: 8th Oct/ 09:00 PM PST LOCAL Time Streaming: FanCode Establish: 1889 Capacity: 19,000 Owner: N/A Home Team: Sunrisers Eastern Cape End Name: Duckpond End & Park Drive End Flood Light: Yes Warriors vs Northern Cape Head-to-Head: Total Match: 0 Warriors: 0 Northern Cape: 0 No Result: 0 Tie: 0 Warriors vs Northern Cape Team Form: Warriors: NR, W, L, W, A Northern Cape: A, L, A, A, L Warriors vs Northern Cape Last Five Head-to-Head Matches: The teams haven’t faced each other till now. Warriors vs Northern Cape Weather Report: Temperature: 21° Humidity: 70% Wind Speed: 23 km/hr Cloud Cover: 5% Warriors vs Northern Cape Pitch Report: St George’s Park in Gqeberha generally offers a balanced T20 surface, with the new ball providing some assistance to pace bowlers while batters can score freely once they settle. Recent T20 data at the venue shows an average first-innings score of around 158, while the last five matches have produced an average of approximately 164, indicating that scoring conditions can improve for batters. Pacers have taken a larger share of wickets at the ground, although spinners can also play an important role as the innings progresses. Warriors vs Northern Cape Match Performance: Total Matches Played: 10 1st Batting Team Won: 4 2nd Batting Team Won: 6 No Result: 0 Average Batting Score: 134 Highest Score: 180/7 Lowest Score: 0/0 Pitch Report: Bowling Pitch Warriors Playing XI: Jean du Plessis, Jordan Hermann, Sibonelo Makhanya, Matthew De Villiers (C), Jp King, Patrick Kruger, Andile Mokgakane, Thomas Kaber, Beuran Hendricks, Wesley Bedja, Kerwin Mungroo Northern Cape Playing XI: Gerhardus Maree (C), Nonelela Yikha, Kyle Jacobs, Blake Simpson, Tahir Isaacs, Jordan Neill, Romano Terblanche, Ruan van Rooyen, Tshepo Ntuli, Johannes van Dyk, Odirile Modimokoane Injury and Availability: We will add any updates here. Warriors vs Northern Cape Match Prediction Tips: Who Will Win the Toss: Northern Cape Match Winner: Warriors Total Boundaries: 20+ Player Of The Match: Jordan Hermann 1st Innings Total: 180+ Most Wicket Taker: Matthew De Villiers Warriors vs Northern Cape Match Prediction: Warriors will win this match.
(출처: arXiv:2609.32993, Figure 2) X-Tree: Tokenizing Reusable Experience for Efficient Agent Generalization 저자 : Sitao Cheng, Xunjian Yin, Zhiyuan Sun, Yuxuan Li, Ruiwen Zhou, Xiangru Jian, Victor Zhong 소속 : University of Waterloo, Duke University, National University of Singapore 공개일 : 2026년 9월 26일 (arXiv v1, cs.AI) arXiv : https://arxiv.org/abs/2609.32993 코드 : https://github.com/sitaocheng/X-Tree · 프로젝트 페이지 : https://sitaocheng.github.io/xtree 분류 : LLM Agent / Reinforcement Learning / Skill Discovery / Experience Reuse 🔖 TL;DR (한눈에) 멀티스텝 에이전트 학습은 궤적(trajectory)을 평평한 액션 스트림 으로 소비한다. SFT와 RLVR은 모든 토큰에 같은 가중치를 주기 때문에, 과제마다 반복되는 하위 절차(sub-procedure)의 계층 구조를 전혀 활용하지 못한다 . 기존 에이전트 하네스는 이 구조를 쓰긴 하지만 LLM이 글로 써낸 스킬을 프롬프트에 넣는 방식 이라, 효과가 "검색해서 끼워넣기" 범위를 넘지 못하고 가중치에는 남지 않는다 . X-Tree는 LLM 호출 0회 로, 텍스트 토크나이저가 빈도만 세어 어휘를 만드는 것과 같은 방식으로 궤적에서 계층을 캐낸다. 액션을 verb⟨role⟩ 형태로 정규화한 뒤 재사용성 점수(X-Score) 로 인접 쌍을 BPE처럼 병합해 트리를 만든다. 각 노드는 "자주 등장하고 성공과 결부된 스킬이 하위 스킬로 어떻게 조립되는가"를 담고, 이를 데이터(오프라인 RL) · 보상(온라인 RLVR) · 컨텍스트(OPSD) 세 경로로 학습에 투입한다. WebArena·ScienceWorld·WebShop 3개 환경, 1.5B/3B/7B 3개 스케일에서 동일 데이터·동일 예산 조건으로 기존 레시피를 앞섰다(WebArena +4.5 SR, ScienceWorld +5.8 SR, WebShop +4.1 success). 특히 무작위 트리(17.9 SR)가 트리를 아예 안 쓴 경우(19.9 SR)보다 나빴다 — 성능이 "쪼개기" 자체가 아니라 구조의 질 에서 나온다는 증거. 한 줄 요약 : 에이전트 궤적 속에 암묵적으로 깔려 있던 "재사용 가능한 절차"를, LLM 없이 통계적 병합만으로 명시적 스킬 트리로 뽑아내고, 그 트리를 데이터·보상·컨텍스트 세 방향에서 모델 가중치에 심는 방법. 📄 초록(Abstract) 완역 멀티스텝 에이전트는 평평한 액션 스트림 위에서 학습된다. SFT와 RLVR은 모든 토큰에 균일한 가중치를 부여하며, 과제들에 걸쳐 반복적으로 나타나는 하위 절차들 — 즉 사람이 재사용 가능한 루틴으로부터 하향식(top-down)으로 계획을 세울 수 있게 해주는 그 계층 구조 — 을 무시한다. 이 구조는 쓰이지 않은 채 방치되고, 평평한 학습은 각각의 희소한 궤적을 그 내용이 허용하는 수준보다 덜 활용한다. 최근의 에이전트들은 그 구조를 실제로 사용하기는 하지만, 오직 LLM이 작성한 스킬을 컨텍스트에 넣는 형태로만 사용하며 가중치에는 결코 반영하지 않기 때문에, 그 이득이 검색(retrieval)의 범위를 넘어 일반화되지 않는다. 우리는 대신 이 계층 구조를 데이터 자체로부터 복원하여 그 위에서 학습하며, 이때 LLM 호출은 전혀 사용하지 않는다. 오직 세는 것만으로 어휘를 구축하는 텍스트 토크나이저를 따라, 우리는 액션 구간(span)들을 재사용성 기준으로 점수화하고 정규화된 액션들을 병합하여 재사용 가능한 경험 트리(reusable eXperience tree, X-Tree)를 만든다. 각 X-Tree 노드는 자주 등장하며 성공을 담지하는(success-bearing) 스킬이 하위 스킬들로부터 어떻게 구성되는지를 포착하여, 효율적인 일반화를 유도한다. 우리는 X-Tree를 세 가지 학습 설정에 통합한다: 각 노드를 하나의 학습 인스턴스로 쓰는 오프라인 RL, 적응적 스킬 보너스를 쓰는 온라인 RLVR, 그리고 X-Tree를 자기-교사(self-teacher)의 특권적 컨텍스트로 쓰는 온-폴리시 자기증류(on-policy self-distillation). WebArena, ScienceWorld, WebShop에서 세 가지 모델 스케일에 걸쳐, X-Tree는 동일한 데이터와 예산 조건에서 표준 레시피를 최대 WebArena 4.5% SR, ScienceWorld 5.8% SR, WebShop 4.1% success만큼 개선한다. 대조 분석들은 그 이득이 X-Tree의 구조와 세 가지 통합 방식에서 비롯됨을 보여준다. 요약 정리 : 저자들의 진단은 "데이터가 부족한 게 아니라, 있는 데이터를 평평하게 소비해서 덜 뽑아먹고 있다"는 것이다. 해법은 궤적에서 반복·성공 패턴을 통계적으로 병합해 스킬 계층(X-Tree)을 만드는 것. 핵심 차별점은 두 가지로, (1) 스킬 추출에 LLM을 쓰지 않아 결정론적이고 감사(audit) 가능하며, (2) 스킬을 프롬프트에 끼워넣는 데 그치지 않고 데이터·보상·컨텍스트 세 경로로 가중치에 학습시킨다 는 점이다. 🧩 왜 이 문제가 중요한가 (배경) 에이전트를 학습시킬 때 가장 비싼 자원은 GPU가 아니라 궤적 이다. 웹 환경에서 성공한 멀티스텝 궤적 하나를 얻으려면 긴 롤아웃과 검증이 필요하고, 사람이 라벨링하면 더 비싸다. 그런데 이 귀한 궤적을 학습에 넣는 방식은 지금까지 거의 한 가지였다. 액션을 토큰 시퀀스로 늘어놓고 SFT로 따라 하게 하거나, 에피소드 끝의 성공/실패 하나로 RLVR을 돌리는 것이다. 문제는 이 두 방식 모두 궤적을 구조 없는 긴 끈 으로 취급한다는 데 있다. 웹 에이전트가 쇼핑 사이트에서 "검색창에 질의를 입력하고 → 결과에서 상품을 고르고 → 옵션을 선택하고 → 구매"를 수행했다면, 이 네 단계는 과제가 바뀌어도 거의 그대로 재등장하는 덩어리 다. 사람은 이런 덩어리를 "루틴"으로 묶어 기억하고, 새 과제를 만나면 루틴 단위로 하향식 계획을 세운다. 반면 평평한 학습은 click 이라는 토큰 하나하나에 같은 무게를 둘 뿐, "이 네 개가 하나의 단위다"라는 사실을 모델에 알려주지 않는다. 이 지점이 바로 암묵지(tacit knowledge)의 데이터화 문제와 맞닿는다. 성공한 궤적 안에는 "이 환경에서 무엇이 통하는 절차인가"라는 지식이 이미 들어 있지만, 그것은 액션 나열 속에 암묵적으로 흩어져 있다. 명시적으로 꺼내 쓰려면 누군가 구조화해야 한다. 최근 연구들(AWM, Voyager, SkillWeaver 등)의 답은 "LLM에게 궤적을 읽히고 스킬을 글로 쓰게 하라"였다. 이 방식은 작동하지만 세 가지 비용을 치른다. 첫째, 스킬 추출 단계마다 LLM 호출 비용 이 든다. 둘째, LLM이 써낸 스킬 설명은 비결정론적이고 검증하기 어렵다 . 셋째, 그리고 가장 중요하게, 그 스킬은 추론 시점에 프롬프트로 검색해 넣어야만 효과가 있다. 모델 가중치는 스킬을 배우지 못했으므로, 검색이 실패하거나 컨텍스트에서 빠지면 이득도 사라진다. X-Tree는 이 세 비용을 동시에 공격한다. "LLM에게 요약을 시키지 말고, 토크나이저처럼 세기만 하라"는 것이 출발점이다. BPE가 코퍼스에서 자주 붙어 나오는 문자 쌍을 병합해 서브워드 어휘를 만드는 것처럼, 자주 붙어 나오고 성공과 결부된 액션 쌍을 병합해 스킬 어휘를 만든다. 그리고 그 어휘를 프롬프트가 아니라 학습 신호 로 쓴다. 🔬 방법론 X-Tree는 크게 두 부분이다. 궤적 풀에서 트리를 캐내는 마이닝 단계 , 그리고 그 트리를 학습에 투입하는 세 가지 통합 방식 이다. (출처: arXiv:2609.32993, Figure 1) 1단계: 액션 정규화 (Canonicalization) 원시 액션을 그대로 세면 아무것도 반복되지 않는다. click(element_id=4821) 과 click(element_id=7733) 은 문자열로는 다른 액션이지만, 추상 수준에서는 둘 다 "링크를 클릭했다"다. 그래서 각 액션을 verb⟨role⟩ 형태의 타입 토큰으로 바꾼다. verb : 액션의 함수 이름에서 가져온다. role : 그 verb가 작용하는 대상의 클래스. WebArena에서는 접근성 트리(accessibility tree)의 role을, ScienceWorld에서는 9개 객체 클래스 어휘(door, instrument, paint, container, device, plant, animal, substance, location)를 쓴다. slot : element ID, 입력한 텍스트, 옵션 값 같은 구체적 값은 심볼에서 제거하되 따로 저장한다 . 그래서 마이닝이 끝난 뒤에도 원래 값을 복원할 수 있다. 에이전트의 thought는 아예 제외한다. 예를 들어 WebArena에서 fill 과 type 은 모두 type 으로, goto / go_back / go_forward 는 모두 navigate 로 접힌다. 중요한 점은 이 매핑이 환경별로 액션 스페이스를 보고 한 번 작성하는 고정 템플릿 이라는 것이다. 학습도, LLM 호출도 없다. 2단계: X-Score로 병합 (Eq. 1) 인접한 두 심볼 u, v (각각 원시 액션이거나 이전 병합으로 만들어진 노드)에 대해 병합 후보 uv 의 점수를 이렇게 매긴다. X(u, v) = f_uv · (l_u + l_v)^{p_l} · (succ(uv) + ε)^{p_s} 세 항의 직관은 각각 반복성 · 길이 · 성공 이다. f_uv : 코퍼스 전체에서 (u,v) 가 인접해 등장한 횟수 → 자주 쓰이는 쌍일수록 높다. l_u + l_v : 후보가 펼쳐지는 원시 액션 개수(원시 액션은 l=1) → 긴 덩어리를 선호한다. succ(uv) : 그 f_uv 번의 등장 중 성공한 에피소드에 속한 비율 → 성공과 결부된 패턴을 선호한다. p_l , p_s : 길이와 성공의 가중 지수. 주요 3개 환경에서 p_l = 1, p_s = 1 , MiniWoB++에서는 p_s = 1.5 . ε = 0.001 . 이 공식의 효과는 명확하다. 길고 믿을 만하며 반복되는 쌍이, 자주 나오지만 짧거나 실패와 얽힌 쌍을 이긴다. 단순 빈도 기반 BPE와 결정적으로 다른 지점이 바로 succ 항이다. 여기에 압축 제약 이 붙는다. f_uv − 1 > η · (l_u + l_v) 병합은 코퍼스에서 f_uv − 1 개의 심볼 등장을 없애는 대신 길이 l_u + l_v 의 어휘 항목 하나를 추가한다. η 는 그 항목의 비용을 정한다. 이 제약이 없으면 코퍼스가 소수의 거대한 심볼로 붕괴한다. 3단계: 트리 구축 초기화 — 각 궤적을 정규화된 원시 액션 시퀀스로 두고, 원시 액션을 리프로 삼는다. 카운트 — 현재 코퍼스에서 모든 인접 쌍의 f_uv , 길이, succ 를 센다. 필터 — 압축 제약과 함께 빈도( f_min ), 길이( L_max ), 성공률( s_min ), 과제 유형 수( T_min ) 필터를 통과한 후보만 남긴다. 선택 — X-Score가 가장 높은 후보를 고른다. 병합 — 노드 v = uv 를 만들고 자식을 (u, v) 로 기록한 뒤, 코퍼스의 해당 인접 등장들을 v 로 치환한다. 노드는 길이 l_v , 깊이 d_v , 등장 횟수, 성공률을 함께 들고 있다. 후보가 없거나 스킬 상한 K 에 도달하면 멈춘다. 그렇지 않으면 2번으로. 깊이는 조립 트리의 높이 다. 리프는 d=0 이고, 내부 노드는 d_v = 1 + max(자식들의 깊이) . 트리를 궤적에 적용할 때는 가장 큰 노드로 궤적을 타일링(tiling) 하고, 어떤 스킬에도 덮이지 않은 위치는 원시 토큰으로 남긴다. 이 타일링이 세 가지 통합 방식 모두가 쓰는 단위다. 환경별 마이닝 하이퍼파라미터는 다음과 같다. 기호 의미 WebArena ScienceWorld WebShop η 압축 비용 0.3 0.5 0.5 K 스킬 상한 256 80 60 L_max 최대 스킬 길이(액션) 12 8 8 f_min 최소 쌍 빈도 4 5 5 s_min 최소 스킬 성공률 0 0.9 0 T_min 스킬당 최소 과제 유형 수 1 2 1 실제로 캐낸 트리의 규모는 이렇다. 벤치마크 마이닝 궤적 수 원시 액션 타입 수 캐낸 스킬 수 WebArena 7,974 139 256 (상한 도달) ScienceWorld 1,673 84 80 (상한 도달) WebShop 1,824 17 48 (압축 제약에 걸림) WebArena 학습에 쓰인 노드 집합은 총 5,148개 로, 깊이 1이 약 3.5k, 깊이 2가 1.2k, 깊이 3이 0.4k다. ScienceWorld에서는 깊이 6까지 나타난다. (출처: arXiv:2609.32993, Figure 5) 위 그림이 이 방법의 정체를 가장 잘 보여준다. ScienceWorld의 "침실에서 미지의 물질 B의 온도를 측정해 50도 이상이면 초록 상자, 미만이면 파란 상자에 넣어라"라는 과제에서, 18개 액션이 4개의 X-Tree 노드와 2개의 원시 액션, 즉 6개 토큰으로 압축된다. 그중 S2(보라색)는 서로 다른 두 토큰 안에 중첩되어 재등장한다. 통합 1: 오프라인 RL (데이터로서의 X-Tree) 궤적의 위치 t 에 있는 각 X-Tree 노드 v 가 하나의 RL 인스턴스 가 된다. 정책은 정답 접두사 s_<t 를 조건으로 받아 최대 l_v 스텝을 생성한다. 각 스텝 j 에서 정답 액션과 대상 요소를 모두 맞추면 match_j = 1 이고, 첫 불일치에서 롤아웃을 중단 한다. 맞춘 스텝에 대해서는 기록된 정답 관측(observation)을 붙여준다 — 그래서 롤아웃이 존재하지 않는 관측을 상상하지 않는다(오프라인 안전성). 보상은 c_v = ∏_j match_j (모든 스텝을 맞췄을 때만 1)로 두고, r = (1 − α) · (1/l_v) Σ_j match_j + α · (1 + γ·d_v) · c_v α = 0.3 , γ = 0.5 . 첫 항은 정답 경로를 따라가는 데 주는 조밀한 크레딧 , 둘째 항은 깊이 d_v 에 비례하는 완주 보너스 다. 깊은 노드를 끝까지 맞추는 것이 더 큰 보상을 받는다는 점이 "계층적 보상"의 실체다. 통합 2: 온라인 RLVR (보상으로서의 X-Tree) 그룹 g 안의 롤아웃 τ_i 에 대해, r_i = R_out(τ_i) + λ_g · Σ_{v ∈ matched(τ_i)} b_v λ_g = λ0 · clip(1 − w_g / w_ref, 0, 1) w_g 는 그룹에서 성공한 롤아웃의 비율이다. 이 설계의 핵심은 스스로 사라지는(self-fading) 보너스 라는 점이다. 아무 롤아웃도 성공하지 못했을 때 보너스는 최대 강도 λ0 이고, 그룹 성공률이 w_ref 에 도달하면 0으로 떨어진다. 즉 검증자의 결과 신호가 쓸모 있어지는 순간 정확히 그 시점에 shaping 항이 사라진다 . 시간 기반 스케줄이 아니라 성공률 기반이라는 점이 중요하다. 실제로 측정된 후반 학습 노출도는 n=2에서 0.50, n=16에서 0.18~0.26으로 떨어진다. 노드 보너스 b_v 는 ScienceWorld에서 1 + 0.5·d_v (에피소드당 1회), WebShop에서 10 · s_v · k_v / T 다. 중첩 매치에서는 외부 노드가 자신의 b_v 에서 내부에 이미 지급된 최대 보너스를 뺀 값 을 받아, 스킬과 하위 스킬의 이중 계산을 막는다. 통합 3: 온-폴리시 자기증류 OPSD (컨텍스트로서의 X-Tree) 학생과 교사가 같은 가중치 다. 차이는 프롬프트뿐으로, 교사는 검색된 X-Tree 스킬이 앞에 붙은 특권적 컨텍스트 를 본다. 둘이 같은 샘플 응답 y 를 채점하므로 로그확률이 위치별로 정렬된다. δ_t = log π_θ̄(y_t | s^tea) − log π_θ(y_t | s^stu) g_t = σ(β · δ_t) L = L_GRPO(R_out) + c · (1/|y|) Σ_t g_t (log π_θ̄(y_t | s^tea) − log π_θ(y_t | s^stu)) 게이트 g_t 는 교사가 더 확신하는 토큰에서 1에 가깝고, 학생이 이미 잘 아는 토큰에서 0에 가깝다. c = 0.01 , ScienceWorld는 β = 5 , WebShop은 β = 0 (게이트가 상수 0.5, 즉 균일 증류). 이 설정이 영리한 이유는 완전히 공정한 비교 를 가능하게 하기 때문이다. 자기-교사가 읽는 스킬 뱅크만 바꾼다. LLM이 쓴 뱅크(ScienceWorld는 gpt-oss-120b, WebShop은 GPT-o3)냐, 렌더링된 X-Tree냐. 다른 모든 것은 동일하다. 📊 실험 결과 WebArena: 오프라인 RL (Qwen2.5-7B, 694개 결정론적 과제, 30스텝 상한, 3패스 평균) Method gitlab (187) shopping (158) admin (156) reddit (112) map (67) wiki (14) All (694) Qwen2.5-7B-Instruct (base) 6.4 7.8 7.7 2.4 9.0 2.4 6.5 Go-Browse (SFT-Full, 2 epochs) 16.8 21.7 22.9 16.4 10.4 7.1 18.4 SFT-Full, 4 epochs (compute 매칭) 17.5 19.4 24.4 16.1 13.4 11.9 18.8 Offline RL w/ Outcome reward 15.5 23.4 23.1 15.2 7.5 14.3 18.2 Offline RL w/ Random span 18.4 20.9 26.6 14.7 11.9 14.3 19.5 X-Tree, Plain mixing (all depths) 16.1 24.5 25.4 19.9 14.4 23.8 20.7 X-Tree, Curriculum (d=1→2) 17.8 21.5 28.6 20.8 12.4 23.8 21.2 X-Tree Full 22.0 26.6 29.3 18.8 10.4 14.3 22.9 전체 SR 22.9는 SFT-Full(2 epochs) 18.4 대비 +4.5 다. 사이트별로 보면 gitlab(16.8→22.0)과 admin(22.9→29.3)처럼 양식 입력과 메뉴 탐색이 반복되는 곳에서 이득이 크고, map(10.4→10.4)과 wiki(7.1→14.3, 다만 과제가 14개뿐)처럼 반복 구조가 약한 곳에서는 이득이 없거나 노이즈 수준이다. 재사용 가능한 절차가 실제로 존재하는 사이트에서만 작동한다 는 해석이 자연스럽다. 어블레이션: 이득은 어디서 오는가 Method SR Δ X-Tree Full 22.9 – 트리 구조 검증 Whole trajectory (트리 없음) 19.9 −3.0 Random span 19.5 −3.4 Random tree 17.9 −5.0 오프라인 RL 설계 검증 X-Tree Plain mixing 20.7 −2.2 X-Tree Curriculum (d=1→2) 21.2 −1.7 Binary outcome reward 18.2 −4.7 SFT-Full, 2 epochs 18.4 −4.5 SFT-Full, 4 epochs 18.8 −4.1 이 표에서 가장 의미 있는 숫자는 Random tree 17.9 다. 무작위로 만든 트리는 트리를 아예 쓰지 않은 경우(19.9)보다도 2.0 포인트 나쁘다 . 궤적을 잘게 쪼개 학습 인스턴스 수를 늘리는 것 자체는 효과가 없고, 오히려 해로울 수 있다는 뜻이다. 성능은 X-Score가 고른 구조의 질 에서 나온다. 참고로 무작위 트리는 노드의 88%가 길이 2인 반면, 캐낸 트리는 43%만 길이 2다. 온라인 RLVR: 롤아웃 수에 따른 스케일링 (ScienceWorld, 1.5B) n Setting G0 (seen) G1 (unseen variation) G2 (unseen task) 2 outcome-only 12.9 13.7 11.8 2 + X-Tree bonus 14.6 15.5 13.0 4 outcome-only 24.2 23.9 12.1 4 + X-Tree bonus 28.0 27.5 16.5 8 outcome-only 38.6 36.2 22.8 8 + X-Tree bonus 39.8 39.5 25.6 16 outcome-only 47.5 49.0 26.6 16 + X-Tr
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 49/50편 (전체 349/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 348. 내부 확장·측면 이동 — 내부 확장·측면 이동 탐지 규칙 모음 340. 침투→확장→목표 연계 분석 1. 개념 G영역에서 배운 탐지·분석·대응을 하나의 실전 시나리오 로 종합합니다. 외부 웹 침투부터 내부 확산, 핵심 자산(DB 마스터) 장악, 유출 시도까지의 전 과정을 SOC 관점에서 탐지·조사·차단하는 흐름을 연습합니다. 실전 시나리오: 침투 → 핵심 자산 장악 1. 침투: 웹 취약점으로 web01 장악 2. 정찰: 내부 스캔·열거(G29·G30) 3. 인증 이동: SSH 키 재사용으로 db01(G10) 4. 상승·수집: 권한 상승·자격 수집(G36·G32) 5. 확산: db01→app01→dbmaster(G33·G35) 6. 목표: dbmaster 데이터 수집·유출(G37) ← 각 단계에서 탐지·차단 기회 이 시나리오는 가상의 예시이며, 각 단계마다 어떤 신호가 발생하고 어떻게 탐지·대응하는지를 종합합니다. 2. 왜 중요한가 실전 시나리오는 개별 탐지 지식을 하나의 사건 흐름으로 통합합니다. 각 단계마다 탐지·차단 기회가 있어, 다층 방어의 가치를 보여줍니다. 조기 단계(정찰·초기 이동) 탐지가 피해를 최소화함을 확인합니다. 3. 핵심 명령어 / 설정 단계 신호 탐지 룰 침투 웹 이상·웹셸 웹 로그 정찰 스캔·열거 106280·106290 인증 이동 키 재사용 106080 상승·수집 sudo·자격 수집 106350·106310 목표 핵심 자산·유출 106330·106360 4. 실습 (실습 예시) # 실전 시나리오 탐지 흐름 (분석 방법) # 단계별 신호를 시간순 종합 조회(타임라인) sudo ausearch -k lateral,recon,privesc,exfil -i --start recent 2>/dev/null | grep -E 'nmap|id_rsa|sudo|dbmaster|mysqldump' | sort # 확산 경로·허브 식별 sudo ausearch -k lateral -i --start recent 2>/dev/null | grep -oE 'srcip=10\.[0-9.]+.*addr=10\.[0-9.]+' | sort | uniq -c 5. 정상 상태 $ (단계별 신호) (평시 — 각 단계 신호 없음, 정상 운영) 평시에는 정찰·이동·상승·유출 신호가 없고, 단계가 연쇄되지 않는 정상 운영 상태입니다. 6. 이상 상태 $ (단계별 신호 — 시나리오 진행) 09:00 web01 웹셸(침투) 09:05 web01 nmap(정찰, 106280) 09:12 web01→db01 SSH 키 재사용(이동, 106080) 09:15 db01 sudo 상승(106350) + id_rsa 수집(106310) 09:20 db01→app01→dbmaster(확산, 106340) 09:25 dbmaster mysqldump → 외부 유출(106360) → 각 단계 탐지 룰 발동, 상관으로 캠페인 경보(106430) 각 공격 단계가 대응 탐지 룰을 발동 → 다층 탐지 상관 룰(106430)이 캠페인으로 묶어 경보 조기 단계(정찰·초기 이동) 차단 시 핵심 자산 보호 가능 7. 로그 분석 (분석 방법) 실전 시나리오 탐지·대응 흐름입니다(가상의 예시). [침투] web01 웹셸 ↓ 탐지: 웹 로그 이상 [정찰] nmap 스캔(106280) ← 차단 기회 1 ↓ [이동] SSH 키 재사용 db01(106080) ← 차단 기회 2 ↓ [상승·수집] sudo(106350)+키 수집(106310) ← 차단 기회 3 ↓ [확산] db01→app01→dbmaster(106340) ← 차단 기회 4 ↓ [목표] mysqldump→유출(106360) ← 마지막 기회 ↓ 상관 캠페인 경보(106430) → 대응 플레이북(G47) = 다층 탐지로 어느 단계든 차단 가능 차단 기회 효과 정찰 단계 피해 없음 이동 단계 확산 전 차단 확산 단계 핵심 자산 보호 목표 단계 유출 저지 조기 단계 탐지일수록 피해가 작음을 보여줍니다. 8. SOC 관제 포인트 실전 시나리오는 침투→정찰→이동→상승·수집→확산→목표 의 전 과정을 종합합니다. 각 단계마다 탐지 룰이 발동하고 상관으로 캠페인 경보가 나는 다층 방어를 확인합니다. 조기 단계(정찰·초기 이동) 탐지가 핵심 자산 보호와 피해 최소화의 열쇠입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,scenario,"> <rule id="106480" level="15" frequency="4" timeframe="1800"> <if_matched_group>lateral</if_matched_group> <same_field>audit.srcip</same_field> <description>침투-정찰-이동-확산-목표 전 단계 연쇄(실전 캠페인)</description> <mitre><id>T1190</id><id>T1021</id><id>T1041</id></mitre> </rule> </group> 단계별 룰과 상관 룰을 종합해 전 과정을 추적합니다. 조기 단계 경보에 신속 대응하면 핵심 자산 도달 전에 차단할 수 있습니다. 10. 대응 방법 초기 확인 — 단계별 신호를 시간순 종합(타임라인)해 시나리오를 재구성합니다. 범위 확인 — 각 단계 탐지 룰 발동·상관 경보·차단 기회를 확인합니다. 증거 확보 — 전 과정 타임라인·경로·증거를 보존합니다. 차단/조치 — 가장 이른 탐지 단계에서 확산 차단·자산 보호 대응을 진행합니다. 재발 방지 — 실전 시나리오 기반 측면 이동 탐지·대응을 연습·운영합니다. 11. 핵심 정리 단계 탐지 룰 침투 웹 로그 정찰 106280·106290 인증 이동 106080 목표 106330·106360 면접 포인트 "실전은 다층 탐지 — 조기 단계(정찰·이동) 차단이 핵심 자산을 지킴" 12. 다음 편 예고 다음 편 350. 내부 확장·측면 이동 — 내부 확장·측면 이동 징후 종합 정리 에서는 내부 확장·측면 이동 징후 전체를 종합하는 내부 확장·측면 이동 징후 종합 정리 를 다룹니다. 이전 편: 348. 내부 확장·측면 이동 — 내부 확장·측면 이동 탐지 규칙 모음 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 48/50편 (전체 348/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 347. 내부 확장·측면 이동 — 측면 이동 Alert 대응 절차 344. Wazuh 기반 측면 이동 탐지 1. 개념 G영역에서 설계한 측면 이동 탐지 규칙을 공격 단계별로 분류한 카탈로그 로 정리합니다. 정찰→인증 이동→원격 실행→확산→목표의 단계마다 핵심 룰을 매핑해, 다층 방어(defense in depth) 관점에서 운영합니다. 측면 이동 탐지 규칙 카탈로그(단계별) [정찰] 스캔·열거·디렉터리 [인증 이동] SSH·키 재사용·자격 재사용·PtH [원격 실행] 명령·스케줄러·SMB·DB·웹·터널 [확산] 경로·홉·자격 수집 [목표] 핵심 자산·상승 연계·유출 연계 [상관] 캠페인·부채꼴·체인 = 단계별 다층 탐지 카탈로그의 목적은 "어느 단계든 하나는 걸리게" 하는 다층 방어입니다. 단계별 룰을 모두 운영해 탐지 사각을 줄입니다. 2. 왜 중요한가 측면 이동은 여러 단계를 거치므로, 단계별 다층 룰이 탐지 확률을 높입니다. 어느 단계든 탐지하면 조기 차단 기회이므로 전 단계 커버가 중요합니다. 카탈로그로 룰을 체계화하면 누락 점검·튜닝·갱신이 쉬워집니다. 3. 핵심 명령어 / 설정 단계 핵심 룰 MITRE 정찰 106280·106290·106300 T1046·T1087 인증 이동 106080·106110·106130 T1021·T1550 원격 실행 106170·106200·106230 T1210·T1059 확산 106310·106320·106340 T1552·T1090 목표·상관 106330·106360·106430 T1041·T1078 4. 실습 (실습 예시) # 측면 이동 탐지 규칙 운영 점검 (분석 방법) # 적재된 G영역 룰 목록·레벨 확인 sudo grep -rE 'id="10(6)[0-9]{3}"' /var/ossec/etc/rules/ 2>/dev/null | grep -oE 'id="[0-9]+" level="[0-9]+"' | sort # 단계별 룰 커버리지 점검(누락 단계 확인) echo "정찰·인증이동·원격실행·확산·목표·상관 각 단계 룰 존재 여부 점검" # 전체 룰 문법 검증 sudo /var/ossec/bin/wazuh-logtest 5. 정상 상태 $ (룰 목록) (정찰~상관 전 단계 룰 적재·검증 통과) 정찰부터 상관까지 전 단계 룰이 적재되고 문법 검증을 통과해, 단계별 커버리지에 누락이 없는 상태가 정상입니다. 6. 이상 상태 운영 이슈 예: · 특정 단계 룰 누락 → 그 단계 탐지 사각 · 과도한 레벨·광범위 조건 → 오탐 폭증 · 기준선 예외 미설정 → 정상 관리 오탐 · 룰 미갱신 → 새 이동 기법 미탐 → 카탈로그로 누락·튜닝·갱신 점검 단계 누락 → 탐지 사각 → 전 단계 커버 확인 필요 광범위 조건·기준선 미설정 → 오탐 → 조건 정밀화·예외 설정 카탈로그 기반 정기 점검으로 사각·오탐·미탐 관리 7. 로그 분석 (분석 방법) 측면 이동 탐지 규칙 카탈로그 구조입니다(가상의 예시). 공격 단계 → 탐지 룰(다층) [정찰] ────── 106280(스캔)·106290(열거)·106300(디렉터리) [인증 이동] ── 106080(키 재사용)·106110(자격 재사용)·106130(계정 전환) [원격 실행] ── 106170(명령)·106200(SMB)·106230(DB)·106260(터널) [확산] ────── 106310(수집)·106320(경로)·106340(홉) [목표] ────── 106330(핵심 자산)·106360(유출 연계) [상관] ────── 106430(캠페인)·106450(흐름 연계) = 어느 단계든 하나는 걸리는 다층 방어 관점 운영 단계별 다층 커버 레벨 우선순위 기준선 오탐 제거 갱신 신규 기법 단계별 다층 커버 + 지속 튜닝이 카탈로그 운영의 핵심입니다. 8. SOC 관제 포인트 G영역 탐지 규칙을 공격 단계별 카탈로그 로 정리해 다층 방어를 운영합니다. 정찰→인증 이동→원격 실행→확산→목표→상관 전 단계를 커버해 사각을 줄입니다. 카탈로그로 누락 점검·오탐 튜닝·신규 기법 갱신을 체계적으로 관리합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,catalog,"> <!-- 단계별 룰은 각 편(106080~106450)을 참조, 베이스로 묶음 관리 --> <rule id="106470" level="3"> <if_group>lateral</if_group> <description>측면 이동 탐지 카탈로그(단계별 룰 묶음 관리)</description> <mitre><id>T1021</id></mitre> </rule> </group> lateral 그룹으로 전 단계 룰을 묶어 관리하고, 레벨·기준선 예외를 일괄 튜닝합니다. 정기적으로 커버리지·오탐·신규 기법을 점검·갱신합니다. 10. 대응 방법 초기 확인 — 단계별(정찰~상관) 룰 적재·커버리지·문법을 점검합니다. 범위 확인 — 레벨·조건·기준선 예외의 오탐·미탐 균형을 확인합니다. 증거 확보 — 룰 카탈로그·커버리지 맵·튜닝 이력을 문서화·보존합니다. 차단/조치 — 누락 단계는 룰 추가, 오탐은 예외·조건 정밀화로 지속 튜닝합니다. 재발 방지 — 측면 이동 탐지 규칙 카탈로그를 운영·갱신합니다. 11. 핵심 정리 단계 핵심 룰 정찰 106280·106290·106300 인증 이동 106080·106110·106130 원격 실행 106170·106200·106230 목표·상관 106330·106360·106430 면접 포인트 "단계별 다층 룰로 어느 단계든 탐지 — 카탈로그로 사각·오탐·갱신 관리" 12. 다음 편 예고 다음 편 349. 내부 확장·측면 이동 — 실전 시나리오 — 침투부터 핵심 자산 장악까지 에서는 침투부터 핵심 자산 장악까지의 실전 시나리오를 다루는 실전 시나리오 — 침투부터 핵심 자산 장악까지 를 다룹니다. 이전 편: 347. 내부 확장·측면 이동 — 측면 이동 Alert 대응 절차 📚 시리즈 전체 보기: 시스템 보안 · 취약점
『Real MySQL 8.0』 6장을 읽고, 핵심 개념을 쉽게 이해할 수 있도록 제 방식대로 정리한 글입니다. 📌 들어가기 전에 왜 데이터를 압축할까? 디스크에 저장된 데이터 파일이 커지면 여러 가지 문제가 생깁니다. 문제 설명 쿼리 성능 읽어야 할 데이터가 많아져 디스크 I/O 증가 백업·복구 시간 파일이 클수록 백업과 복구가 오래 걸림 저장 공간 비용 디스크 용량이 많이 필요함 그래서 MySQL은 데이터를 압축해서 저장 하는 방법을 제공합니다. MySQL의 두 가지 압축 방식 방식 다른 이름 한 줄 설명 페이지 압축 Transparent Page Compression 디스크에 쓸 때 압축 , 읽을 때 해제. OS의 펀치 홀 기능에 의존 테이블 압축 - 압축된 페이지를 정해진 크기(KEY_BLOCK_SIZE) 에 맞춰 저장 6.1 페이지 압축 페이지 압축이란? 데이터 페이지를 디스크에 저장하는 순간 압축 하고, 디스크에서 읽어올 때 압축을 해제 합니다. 그래서 버퍼 풀에는 압축이 해제된 상태 로 데이터가 올라옵니다. [쓰기] 버퍼 풀 (16KB, 원본) ──압축──▶ 디스크 (압축된 상태) [읽기] 디스크 (압축된 상태) ──해제──▶ 버퍼 풀 (16KB, 원본) 💡 MySQL 서버 내부에서는 데이터가 압축됐는지 신경 쓰지 않고 똑같이 처리합니다. 그래서 "투명한(Transparent)" 페이지 압축이라고 부릅니다. 문제: 압축 결과의 크기를 예측할 수 없다 16KB 페이지를 압축하면 결과가 7KB가 될지, 10KB가 될지 미리 알 수 없습니다. 그런데 하나의 테이블은 모든 페이지가 같은 크기 여야 관리할 수 있습니다. 페이지 A 압축 → 7KB 페이지 B 압축 → 11KB 페이지 C 압축 → 5KB → 크기가 제각각이면 파일 안에서 페이지 위치를 계산할 수 없음 😵 해결: 펀치 홀 (Punch Hole) 운영체제의 펀치 홀 기능을 이용해 이 문제를 해결합니다. 1 16KB 페이지를 압축 → 결과 7KB 2 디스크에 16KB 크기 그대로 기록 [압축 데이터 7KB][빈 공간 9KB] 3 뒤쪽 빈 공간 9KB에 펀치 홀을 뚫음 [압축 데이터 7KB][🕳️ 9KB] → 파일 시스템은 9KB를 운영체제에 반납 관점 크기 실제 디스크 사용량 7KB MySQL·운영체제가 보는 파일 크기 16KB (압축 데이터 + 펀치 홀 공간) 🧩 비유: 16칸짜리 주차 구역을 그대로 유지하되, 실제로 차를 7칸에만 세우고 나머지 9칸은 "여기는 비어 있음" 이라고 표시해서 다른 사람이 쓰게 돌려주는 것 페이지 압축의 한계 한계 설명 지원 환경 제약 펀치 홀은 운영체제뿐 아니라 하드웨어(파일 시스템) 도 지원해야 함 파일 복사 시 문제 일반적인 파일 복사 명령어는 펀치 홀을 지원하지 않아서, 복사하면 원래 크기(16KB)로 되돌아감 백업 도구 문제 XtraBackup 같은 백업 도구로 백업·복구할 때도 같은 문제가 생길 수 있음 ⚠️ 이런 이유로 페이지 압축은 실무에서 많이 사용되지 않습니다. 사용 방법 -- 테이블 생성 시 페이지 압축 적용 CREATE TABLE t1 (c1 INT) COMPRESSION = 'zlib'; -- 기존 테이블에 페이지 압축 적용 ALTER TABLE t1 COMPRESSION = 'zlib'; OPTIMIZE TABLE t1; -- 기존 데이터에도 압축을 적용하려면 테이블 재구성 필요 COMPRESSION 값 의미 zlib zlib 알고리즘으로 압축 lz4 lz4 알고리즘으로 압축 none 압축하지 않음 6.2 테이블 압축 테이블 압축이란? 운영체제나 하드웨어 제약 없이 사용할 수 있는 압축 방식입니다. 그래서 페이지 압축보다 활용도가 높습니다. 단점도 있다 단점 설명 버퍼 풀 공간 활용률 낮음 버퍼 풀에 압축된 페이지와 해제된 페이지를 둘 다 보관 쿼리 처리 성능 낮음 압축·해제 과정에서 CPU 사용 잦은 변경 시 압축률 저하 데이터가 자주 바뀌면 압축 효율이 떨어짐 6.2.1 압축 테이블 생성 사전 조건 압축 테이블은 별도의 테이블스페이스 를 사용해야 합니다. SHOW GLOBAL VARIABLES LIKE 'innodb_file_per_table'; -- ON 이어야 함 생성 방법 CREATE TABLE compressed_table ( c1 INT PRIMARY KEY ) ROW_FORMAT = COMPRESSED KEY_BLOCK_SIZE = 8; 옵션 설명 ROW_FORMAT = COMPRESSED 압축 테이블로 생성 (생략하면 KEY_BLOCK_SIZE 만 지정해도 자동으로 COMPRESSED 적용) KEY_BLOCK_SIZE 압축된 페이지가 저장될 목표 크기 (KB 단위) 💡 KEY_BLOCK_SIZE 는 1, 2, 4, 8, 16(KB) 중에서 정하며, 기본 페이지 크기(16KB) 기준으로 보통 4KB 또는 8KB 를 사용합니다. InnoDB 페이지 크기가 32KB, 64KB라면 테이블 압축을 사용할 수 없습니다. 압축 과정 (KEY_BLOCK_SIZE = 8KB 예시) 1 16KB 데이터 페이지를 압축 │ ├─ 압축 결과 ≤ 8KB → 그대로 디스크에 저장 ✅ (압축 완료) │ └─ 압축 결과 > 8KB → 원본 페이지를 둘로 나눔 (페이지 스플릿) [8KB] [8KB] │ │ ▼ ▼ 나뉜 페이지 각각에 대해 1부터 다시 반복 ⚠️ 압축 결과가 목표 크기(KEY_BLOCK_SIZE)보다 작아야 저장할 수 있습니다. 목표 크기를 넘으면 페이지 스플릿 이 일어나고, 이게 반복되면 성능이 떨어집니다. 6.2.2 KEY_BLOCK_SIZE 결정 KEY_BLOCK_SIZE 를 너무 작게 잡으면 압축 실패 → 페이지 스플릿 이 자주 발생합니다. 그래서 실제 적용 전에 샘플 데이터로 테스트 해보는 것이 중요합니다. 테스트 방법 -- 1) 인덱스별 압축 통계 수집 활성화 SET GLOBAL innodb_cmp_per_index_enabled = ON; -- 2) KEY_BLOCK_SIZE를 바꿔가며 테스트 테이블 생성 CREATE TABLE employees_comp4k ( emp_no INT NOT NULL, first_name VARCHAR(14) NOT NULL, hire_date DATE NOT NULL, PRIMARY KEY (emp_no), KEY ix_firstname (first_name), KEY ix_hiredate (hire_date) ) ROW_FORMAT = COMPRESSED KEY_BLOCK_SIZE = 4; -- 3) 실제 데이터 일부를 넣어봄 INSERT INTO employees_comp4k SELECT emp_no, first_name, hire_date FROM employees; -- 4) 인덱스별 압축 성공/실패 횟수 확인 SELECT table_name, index_name, compress_ops, compress_ops_ok, (compress_ops - compress_ops_ok) / compress_ops * 100 AS compression_failure_pct FROM information_schema.INNODB_CMP_PER_INDEX; 컬럼 의미 compress_ops 전체 압축 시도 횟수 compress_ops_ok 압축 성공 횟수 compression_failure_pct 압축 실패율 판단 기준 압축 실패율 = (compress_ops - compress_ops_ok) / compress_ops × 100 💡 일반적으로 압축 실패율이 3~5% 미만 이 되도록 KEY_BLOCK_SIZE 를 선택합니다. 예를 들어 4KB에서 실패율이 높고 8KB에서 낮다면, 8KB 를 선택하는 것이 좋습니다. 그런데 실패율이 전부는 아니다 상황 판단 INSERT만 하는 로그성 테이블 한 번 압축되면 다시 변경되지 않으므로, 실패율이 조금 높아도 압축률이 좋다면 사용 고려 변경이 잦은 테이블 실패율이 낮더라도 압축·해제가 반복되어 CPU 부담 → 압축을 다시 고민 ✅ 압축·해제는 CPU를 사용하는 작업 이라는 점을 함께 고려해야 합니다. 6.2.3 압축된 페이지의 버퍼 풀 적재 및 사용 버퍼 풀에 두 가지 버전을 함께 보관 압축 테이블의 페이지는 버퍼 풀에 이렇게 올라옵니다. ┌─────────────── InnoDB 버퍼 풀 ───────────────┐ │ │ │ [압축된 페이지 8KB] ──해제──▶ [해제된 페이지 16KB] │ │ ▲ ▲ │ │ LRU 리스트 Unzip_LRU 리스트 │ └─────────────────────────────────────────────┘ 리스트 관리 대상 LRU 리스트 압축된 페이지 + 압축 해제된 페이지 모두 Unzip_LRU 리스트 압축 해제된 페이지만 디스크에서 읽어온 압축된 페이지 를 그대로 보관하고, 실제로 데이터를 읽거나 변경하려면 압축을 해제한 페이지 가 필요하기 때문에 둘 다 가지고 있습니다. 이로 인한 문제 문제 설명 메모리 낭비 같은 데이터를 두 가지 형태로 들고 있어서 버퍼 풀 공간을 더 많이 씀 CPU 소모 압축 해제된 페이지를 버렸다가 다시 필요해지면, 또 압축 해제 를 해야 함 InnoDB의 해결 방법: Unzip_LRU 리스트 관리 상황 InnoDB의 동작 버퍼 풀 공간이 부족할 때 압축된 원본은 남기고, Unzip_LRU에서 압축 해제된 버전을 제거 압축된 페이지가 자주 사용될 때 Unzip_LRU에 해제된 페이지를 계속 유지 → 압축·해제 작업 최소화 압축된 페이지가 사용되지 않아 LRU에서 제거될 때 Unzip_LRU에서도 함께 제거 어댑티브(적응형) 알고리즘 InnoDB는 서버 상황을 보고 Unzip_LRU의 비율을 자동으로 조절 합니다. 서버 상황 동작 이유 CPU 사용량이 높음 Unzip_LRU 비율을 높게 유지 압축 해제를 덜 하도록 해서 CPU 절약 디스크 I/O 사용량이 높음 Unzip_LRU 비율을 낮게 유지 버퍼 풀 공간을 더 확보해서 디스크 읽기 감소 🧩 비유 CPU가 바쁠 때: "포장 다시 뜯기 힘드니까, 뜯어놓은 거 그냥 둬" 디스크가 바쁠 때: "창고 공간이 부족하니까, 뜯어놓은 건 치우고 포장된 것만 보관해" 6.2.4 테이블 압축 관련 설정 1 innodb_cmp_per_index_enabled innodb_cmp_per_index_enabled = ON 값 수집되는 통계 ON 인덱스별 압축 성공·실패 횟수 → INNODB_CMP_PER_INDEX OFF 테이블 단위 압축 통계만 수집 → INNODB_CMP 2 innodb_compression_level innodb_compression_level = 6 -- 0 ~ 9, 기본값 6 InnoDB 테이블 압축은 zlib 알고리즘 을 사용하며, 이 값으로 압축률을 정합니다. 값 압축 속도 압축률(저장 공간) CPU 낮을수록 빠름 낮음 (공간 더 사용) 적게 사용 높을수록 느림 높음 (공간 절약) 많이 사용 3 innodb_compression_failure_threshold_pct & innodb_compression_pad_pct_max innodb_compression_failure_threshold_pct = 5 -- 기본값 5(%) innodb_compression_pad_pct_max = 50 -- 기본값 50(%) 동작 방식 테이블 단위 압축 실패율 > innodb_compression_failure_threshold_pct → 압축하기 전에 원본 페이지 끝에 일부러 빈 공간(패딩)을 추가 → 빈 공간은 압축이 매우 잘 되므로 전체 압축률이 올라감 → 압축 결과가 KEY_BLOCK_SIZE보다 작아질 확률 증가 ✅ 설정 의미 innodb_compression_failure_threshold_pct 압축 실패율이 이 값을 넘으면 패딩 추가 시작 innodb_compression_pad_pct_max 패딩 공간은 실패율이 높을수록 늘어나며, 최대 이 비율(%)까지 커질 수 있음 💡 압축 실패로 인한 페이지 스플릿을 줄이기 위해, InnoDB가 스스로 압축 성공률을 높이는 장치 입니다. 4 innodb_log_compressed_pages innodb_log_compressed_pages = ON -- 기본값 ON 서버가 비정상 종료된 뒤 재시작할 때, 압축 알고리즘(zlib)의 버전이 바뀌었더라도 복구가 실패하지 않도록 압축된 데이터 페이지를 그대로 리두 로그에 기록 하는 옵션입니다. 장점 단점 압축 알고리즘을 업그레이드할 때 안전한 복구 보장 데이터 페이지를 통째로 기록하므로 리두 로그 증가량이 커짐 ⚠️ 압축 테이블을 사용 중이라면 리두 로그 공간이 얼마나 빨리 차는지 모니터링해야 합니다. 버퍼 풀에서 더티 페이지가 한꺼번에 많이 기록되는 패턴이라면, 이 옵션을 OFF 로 바꾼 뒤 모니터링해보는 것을 고려할 수 있습니다. ✍️ 마무리 정리 페이지 압축 vs 테이블 압축 항목 페이지 압축 테이블 압축 압축 시점 디스크에 쓸 때 정해진 크기에 맞춰 저장 버퍼 풀 상태 해제된 상태 만 보관 압축 + 해제 둘 다 보관 의존성 OS·하드웨어의 펀치 홀 지원 필요 제약 없음 설정 COMPRESSION = 'zlib' ROW_FORMAT = COMPRESSED , KEY_BLOCK_SIZE 실무 활용 낮음 (파일 복사·백업 문제) 상대적으로 높음 핵심 포인트 6.1 페이지 압축 디스크에 쓸 때 압축하고, 남는 공간은 펀치 홀 로 운영체제에 반납한다. 파일 복사·백업 시 펀치 홀이 사라지는 문제로 잘 쓰이지 않는다. 6.2.1 압축 테이블 생성 innodb_file_per_table = ON 필요 압축 결과가 KEY_BLOCK_SIZE 보다 크면 페이지 스플릿 발생 6.2.2 KEY_BLOCK_SIZE 결정 샘플 데이터로 테스트 후 INNODB_CMP_PER_INDEX 에서 압축 실패율 확인 실패율 3~5% 미만이 기준이지만, 테이블의 변경 빈도도 함께 고려 6.2.3 버퍼 풀 적재 압축 페이지(LRU)와 해제 페이지(Unzip_LRU)를 함께 보관 CPU가 바쁘면 해제 페이지를 유지하고, 디스크가 바쁘면 해제 페이지를 줄이는 적응형 알고리즘 6.2.4 관련 설정 압축 통계( innodb_cmp_per_index_enabled ), 압축률( innodb_compression_level ) 실패율이 높으면 패딩을 추가 해 압축 성공률을 높임 innodb_log_compressed_pages 는 리두 로그 증가량을 함께 모니터링 📚 참고 백은빈, 이성욱, 『Real MySQL 8.0 1권』, 위키북스 MySQL 8.0 Reference Manual - InnoDB Page Compression MySQL 8.0 Reference Manual - InnoDB Table Compression
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 50/50편 (전체 350/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 349. 내부 확장·측면 이동 — 실전 시나리오·침투부터 핵심 자산 장악까지 301. 내부 확장·측면 이동 징후 분석 개요 1. 개념 G영역 「내부 확장·측면 이동 징후」 50편을 종합 정리합니다. 측면 이동은 거점 하나에서 조직 전체로 확산 되는 공격 단계로, 침투와 목표 달성(유출·파괴) 사이의 핵심 고리입니다. G영역은 이 확산을 탐지·분석·차단하는 전 과정을 다뤘습니다. G영역 전체 체계 [기초] 개념·공격 단계·기반·기준선·분석 축(G01~G08) [인증 이동] SSH·키/자격 재사용·PtH·계정 전환(G09~G18) [원격 실행] 명령·스케줄러·SMB·DB·웹·터널(G19~G28) [정찰·확산] 스캔·열거·수집·경로·핵심 자산·연계(G29~G38) [로그 분석] 타임라인·상관·그래프(G39~G43) [SOC 연계] Wazuh·SIEM·NDR·대응·카탈로그·실전(G44~G50) = 개념부터 실전 운영까지 측면 이동 탐지의 핵심은 "개별 이벤트가 아닌 연결(상관)"입니다. 단일 이동은 정상처럼 보여도, 출발지·계정·시간으로 연결하면 확산 패턴이 드러납니다. 2. 왜 중요한가 측면 이동은 침투와 목표 사이의 핵심 고리로, 여기서 차단하면 피해를 막습니다. 개별 이벤트는 정상처럼 보여, 상관(연결)이 탐지의 본질입니다. 조기 단계(정찰·초기 이동) 탐지가 핵심 자산 보호의 열쇠입니다. 3. 핵심 명령어 / 설정 영역 핵심 기초 동-서 트래픽·4대 축·기준선 인증 이동 키/자격 재사용·PtH·계정 전환 원격 실행 명령·SMB·DB·웹·터널 정찰·확산 스캔·수집·경로·핵심 자산 SOC 연계 상관·Wazuh/SIEM·대응 4. 실습 (실습 예시) # G영역 종합 운영 점검 (분석 방법) # 측면 이동 탐지 체계 전반 점검 echo "1. 중앙 수집·정규화(G41) 정상 여부" echo "2. 단계별 룰 커버리지(G48) 누락 여부" echo "3. 상관 룰(G42·G44) 작동 여부" echo "4. 기준선(G04)·핵심 자산 등록(G34) 최신 여부" echo "5. 대응 플레이북(G47) 준비 여부" sudo /var/ossec/bin/wazuh-logtest # 룰 검증 5. 정상 상태 종합 점검(정상 운영): · 중앙 수집·정규화 정상 · 단계별 룰·상관 룰 적재·작동 · 기준선·핵심 자산 최신 · 대응 플레이북 준비 수집·정규화·단계별 룰·상관·기준선·대응이 모두 정비되어, 측면 이동을 다층으로 탐지·대응할 준비가 된 상태가 정상입니다. 6. 이상 상태 운영 미비 시 위험: · 중앙 수집 미비 → 확산 추적 불가(사각) · 단계 룰 누락 → 그 단계 사각 · 상관 미작동 → 개별 정상으로 미탐 · 기준선·자산 미갱신 → 오탐·사각 → 종합 점검으로 체계 완결성 유지 수집·정규화 미비 → 측면 이동 추적 자체가 불가(가장 큰 사각) 상관 미작동 → 개별 이벤트가 정상으로 보여 미탐 종합 점검으로 탐지 체계의 완결성을 지속 유지 7. 로그 분석 (분석 방법) G영역 종합 체계입니다(가상의 예시). [기초] 개념·4대 축·기준선(G01~G08) ↓ [탐지] 인증 이동·원격 실행·정찰·확산(G09~G38) ↓ [분석] 타임라인·상관·그래프(G39~G43) ↓ [SOC] Wazuh·SIEM·NDR·대응·카탈로그(G44~G48) ↓ [실전] 시나리오·종합(G49~G50) = 개념→탐지→분석→운영→실전 완결 체계 핵심 원리: 개별 이벤트 → (상관) → 확산 패턴 → 탐지·차단 흐름 결과 기초 판단 기준 탐지 단계별 신호 분석 사건 재구성 SOC 운영 탐지·대응 개념부터 실전까지 측면 이동을 다루는 완결 체계입니다. 8. SOC 관제 포인트 측면 이동은 거점 하나에서 조직 전체로 확산 되는, 침투와 목표 사이의 핵심 고리입니다. 탐지의 본질은 개별 이벤트의 상관(연결) 으로, 단일은 정상이어도 연결하면 확산이 보입니다. 중앙 수집·정규화·단계별 다층 룰·상관·기준선·대응을 갖춘 완결 체계가 핵심입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,"> <rule id="106490" level="12"> <if_group>lateral</if_group> <description>G영역 측면 이동 탐지 체계(종합 — 상관 기반 확산 탐지)</description> <mitre><id>T1021</id><id>T1078</id><id>T1210</id></mitre> </rule> </group> G영역 전 룰(106000~106480)을 lateral 그룹으로 통합 운영하고, 중앙 수집·상관·기준선·대응을 하나의 체계로 유지합니다. 정기 점검으로 완결성을 지킵니다. 10. 대응 방법 초기 확인 — 중앙 수집·정규화·단계별 룰·상관·기준선·대응을 종합 점검합니다. 범위 확인 — 측면 이동 탐지 체계의 커버리지·상관 작동·완결성을 확인합니다. 증거 확보 — 탐지 체계·룰 카탈로그·운영 문서를 보존·갱신합니다. 차단/조치 — 미비 항목은 보강하고, 신규 이동 기법은 룰·기준선에 반영합니다. 재발 방지 — G영역 측면 이동 탐지 체계를 지속 운영·발전시킵니다. 11. 핵심 정리 영역 핵심 기초 동-서·4대 축·기준선 인증/원격 이동 키·자격 재사용·SMB·DB·터널 정찰·확산 스캔·수집·경로·핵심 자산 SOC 연계 상관·Wazuh/SIEM·대응 면접 포인트 "측면 이동 탐지의 본질은 상관 — 개별은 정상, 연결하면 확산이 보인다" 12. 다음 편 예고 이것으로 G영역 「내부 확장·측면 이동 징후」를 마칩니다. 다음 영역에서 또 다른 보안 주제로 이어집니다. 이전 편: 349. 내부 확장·측면 이동 — 실전 시나리오 — 침투부터 핵심 자산 장악까지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › G. 내부 확장 · 측면 이동 징후 · 47/50편 (전체 347/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 346. 내부 확장·측면 이동 — 네트워크 탐지(NDR)·흐름 로그 연계 308. 내부 확장·측면 이동 판정 기준 1. 개념 측면 이동 경보는 확산 중인 활성 공격 일 가능성이 높아, 신속·체계적 대응이 필요합니다. 접수→분류→조사→격리→확산 차단→복구의 플레이북 으로 대응하되, 측면 이동 특성상 확산 차단(추가 이동 저지) 이 최우선입니다. 측면 이동 Alert 대응 절차 1. 접수·분류: 정탐/오탐, 심각도(핵심 자산 근접?) 2. 조사: 4대 축·경로 매핑·타임라인 3. 격리: 영향 호스트·허브 격리 4. 확산 차단: 경로 차단·자격증명 교체 5. 복구: 정리·패치·모니터링 6. 사후: 타임라인·보고·교훈 핵심: 확산 차단(추가 이동 저지)이 최우선 측면 이동은 진행 중이면 매 순간 확산되므로, 조사와 병행해 확산 차단을 서두릅니다. 허브(G43) 격리가 확산을 가장 효율적으로 끊습니다. 2. 왜 중요한가 측면 이동 경보는 활성 확산일 가능성이 높아 신속 대응이 필수입니다. 확산 차단(추가 이동 저지)이 조사보다 우선할 수 있습니다(진행 중). 허브 격리·자격증명 교체가 확산을 끊는 핵심 조치입니다. 3. 핵심 명령어 / 설정 단계 조치 우선순위 분류 정탐/오탐·심각도 즉시 조사 경로·타임라인 병행 격리 호스트·허브 높음 확산 차단 경로·자격 교체 최우선 복구 정리·패치 이후 4. 실습 (실습 예시) # 측면 이동 Alert 대응 (분석 방법) # 1. 영향 범위 확인(경로 매핑) sudo ausearch -k lateral -i --start recent 2>/dev/null | grep -oE 'srcip=10\.[0-9.]+.*addr=10\.[0-9.]+' | sort | uniq -c # 2. 활성 세션 확인(진행 중 이동) ss -tnp 2>/dev/null | grep -E ':22\b' | grep -E '10\.|192\.168\.' # 3. 증거 보존(격리 전 로그 수집) sudo ausearch -k lateral,privesc,exfil --start recent > /var/log/ir_lateral_$(date +%s).log 2>/dev/null 5. 정상 상태 대응 준비 상태(정상 운영): · 플레이북·연락망·격리 권한 준비됨 · 경보 접수 시 즉시 분류·대응 가능 플레이북·연락망·격리 권한이 준비되어, 경보 접수 시 지체 없이 분류·대응에 들어갈 수 있는 상태가 정상(대응 준비 완료)입니다. 6. 이상 상태 측면 이동 경보 대응 흐름(정탐): 1. 분류: 핵심 자산 근접 → 심각도 상 2. 조사: web01→db01→app01 경로, db01=허브 3. 격리: db01(허브) 우선 격리 → 확산 차단 4. 자격 교체: 관련 SSH 키·계정 전면 교체 5. 복구: 발판·도구 제거, 진입점 패치 핵심 자산 근접 경보 → 심각도 상향 → 신속 대응 허브(db01) 우선 격리 → 추가 확산 차단 경로 차단 + 자격증명 교체 → 측면 이동 봉쇄 7. 로그 분석 (분석 방법) 측면 이동 Alert 대응 절차입니다(가상의 예시). [접수] 106430 상관 경보(캠페인) ↓ 분류 정탐 + 핵심 자산 근접 → 심각도 상 ↓ 조사(병행) 경로: web01→db01→app01, 허브=db01 ↓ 확산 차단(최우선) db01(허브) 격리 → SSH 키·계정 교체 ↓ 복구 발판·도구 제거, web01 진입점 패치 ↓ 사후 타임라인·보고·탐지 규칙 보강 단계 핵심 조치 분류 심각도·정탐 조사 경로·허브 확산 차단 허브 격리·자격 교체 복구 정리·패치 확산 차단(허브 격리·자격 교체)이 대응의 최우선입니다. 8. SOC 관제 포인트 측면 이동 경보는 활성 확산 일 수 있어 신속·체계적 플레이북 대응이 필요합니다. 접수→분류→조사→격리→확산 차단→복구 중 확산 차단이 최우선 입니다. 허브(G43) 격리와 자격증명 전면 교체가 확산을 끊는 핵심 조치입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_g,lateral,response,"> <rule id="106460" level="14"> <if_sid>106430</if_sid> <description>측면 이동 캠페인 경보 — 대응 플레이북 가동(확산 차단 우선)</description> <mitre><id>T1021</id></mitre> </rule> </group> 고레벨 캠페인 경보는 자동 플레이북(격리·자격 교체 티켓)과 연동합니다. 격리 권한·연락망·증거 보존 절차를 사전 정비합니다. 10. 대응 방법 초기 확인 — 경보를 분류(정탐/오탐·심각도·핵심 자산 근접)합니다. 범위 확인 — 경로·허브·타임라인을 조사하며 확산 차단을 병행합니다. 증거 확보 — 증거 보존(격리 전 로그) 후 허브·호스트를 격리합니다. 차단/조치 — 경로 차단·자격증명 전면 교체·발판 제거·진입점 패치를 진행합니다. 재발 방지 — 사후 타임라인·보고·탐지 규칙 보강으로 측면 이동 대응을 마무리합니다. 11. 핵심 정리 단계 조치 분류 정탐/오탐·심각도 조사 경로·허브·타임라인 확산 차단 허브 격리·자격 교체(최우선) 복구 정리·패치·모니터링 면접 포인트 "측면 이동은 활성 확산 — 허브 격리+자격 교체로 확산 차단이 최우선" 12. 다음 편 예고 다음 편 348. 내부 확장·측면 이동 — 내부 확장·측면 이동 탐지 규칙 모음 에서는 내부 확장·측면 이동 탐지 규칙을 모으는 내부 확장·측면 이동 탐지 규칙 모음 을 다룹니다. 이전 편: 346. 내부 확장·측면 이동 — 네트워크 탐지(NDR)·흐름 로그 연계 📚 시리즈 전체 보기: 시스템 보안 · 취약점