Logic in Code,
Freedom in Travel.

TL;DR: 2017년에 심어진 커널 크립토 최적화 코드 한 줄이 로컬 권한 탈취(LPE)로 이어지는 취약점이 터졌다. PoC는 이미 공개됐고, 732바이트짜리 Python 스크립트 하나로 Ubuntu/RHEL/Amazon Linux/SUSE 전부 루트 탈취가 가능하다.1. 배경과 문제: "계정 비밀번호 백도어, 커널 업데이트는 리스크가 크다."우리 서버는 OVH 베어메탈 위에서 동작하는 온프레미스 환경이다. 어느 날 모니터링 채널에 CVE 하나가 올라왔다.CVE-2026-31431, 일명 "Copy Fail" 이며 영향받는 배포판은 Ubuntu/Amazon Linux/RHEL/SUSE 인데 사실상 웬만한 서버에 설치되어 있는 리눅스 전부이다.문제는 커널 업데이트를 바로 실행하기에는 애매한 상황이었다. ..

이슈팀장님과 같은 버스를 타고 지하철에서 갈라졌는데, 서비스 장애 모니터링 슬랙 채널에서 알림이 쏟아지기 시작했다.핸드폰으로 빠르게 영향 범위(Blast Radius) 를 파악했다. 다행히 장애 도메인은 예상보다 작았다. 웹서버 티어(Tier)와 해당 DB 인스턴스에만 국한되었고, 권위 네임서버(Authoritative DNS)와 기타 부가 서비스들은 정상 응답을 유지하고 있었다. 장애 인지까지 MTTD(Mean Time To Detect) 약 3~5분 모니터링 시스템이 역할을 잘 해줘서 일찍 알았다. 용어Blast Radius (영향 범위): 장애가 실제로 영향을 미치는 시스템의 범위. 좁을수록 복구가 쉽다.MTTD (Mean Time To Detect): 장애가 발생한 시점부터 인지하는 데까지 걸린 ..

AWS 엔지니어 Salvatore Dipietro가 Linux 7.0 개발 커널에서 PostgreSQL 처리량이 이전 커널 대비 절반(0.51x)으로 떨어진 다는것을 발견했다.Graviton4 서버(96 vCPU)에서 pgbench 1,024 커넥션으로 벤치마킹? 했더니 아래와 같은 성능 이슈가 나왔다. Linux 6.x: 정상 처리량Linux 7.0: 50,751 TPS (절반 수준)패치 적용 후: 98,565 TPS (복구)해당 이슈는 단순한 버그가 아니라는 점이다. 커널 메인테이너들이 "이건 PostgreSQL이 고쳐야 할 문제"라고 이슈를 남겼다. 트러블슈팅: 어디서 문제가 발생했나커널 프리엠션 모델 단순화bisecting 으로 추적한 결과해보니 범인은 Intel 개발자 Peter Zijlstr..

솔라나 메인넷 노드 서버를 운영하기 위해서는 하드웨어 스팩이 좋아야 한다.내가 관리하는 솔라나 서버는 Intel Xeon Gold 6442Y (48코어), 256GB RAM이라는 엄청난 스펙을 가지고 있지만 블록체인 노드의 지랄맞은 특성으로 인해 동기화 지연, Docker NAT 라우팅 문제, Nginx 포트 고갈(TIME_WAIT), I/O 최적화 과정까지 이슈가 있었다.트러블슈팅 1. 점점 멀어지는 블록 동기화노드를 설치하고 스냅샷을 다운받고 블록 동기화 진행 과정을 solana catchup 명령어로 모니터링을 하는데 블록이 점점 멀어졌다. 블록이 멀어진다는 것은 입금을 확인하는데 걸리는 시간이 지연되고, 출금도 지연되는 것이다. 즉 노드가 죽은거나 마찬가지였다. 조치 1: --only-known-..

"우리 서버는 요청이 잘 가는데요, 우리는 문제가 없어요" 라는 말은 조심스러워 해야 하는 말이다.구체적인 원인을 찾는데만 3개월이 걸린 이슈가 있었다.PG사(결제 대행사) 서버가 우리쪽 서버로 "완료" 통지(Webhook)를 보냈는데, 우리 서버에는 아무런 요청도, 로그도 남지 않는 현상이 있었다. PG사는 "너희 서버가 503(Service Unavailable)을 응답하고 있어"라고 주장했고, 나는 "Nginx, Apache 로그를 다 뒤져봐도 요청 온 흔적조차 없다" 고 응답했다. PG사의 웹훅 버그 가능성부터 /etc/hosts 설정을 통해 전혀 다른 IP로 DNS 캐싱이 되어 있는 것은 아닌지 의심했다. 하지만 PG사는 단순히 'curl' 요청 결과만을 근거로 문제가 없다는 답변만 반복할 뿐..

PHP 와 Node.js 생태계에서 개발하면서 문서가 너무 없거나, 너무 많아서 원하는 내용을 찾기 힘든 경우가 많았다.1. 문서가 부실한 이유: "개발자의 딜레마와 현실"오픈소스가 문서화보다 기능 구현에 쏠릴 수 밖에 없는 원인 The Code is Truth코드를 작성한 사람은 코드의 흐름을 너무 잘 알고 있을 것이다. 그래서 주석이나 문서 없이도 변수명과 함수 구조만 보면 잘 안다. 프로그래밍 언어 특성에 따라 자바스크립트 생태계는 코드를 빨리 짜고 배포하는 문화가 강하다. "일단 동작하게 만드는 것(Make it work)"이 우선시되다 보니 문서는 뒷전으로 밀리는 것 같다. 이로인해 `README.md`에 설치 방법만 있고, 구체적인 사용법이나 엣지 케이스에 대한 설명이 없는 경우가 많은 것 같..