Lobsters

한 줄 요약: WebAssembly 런타임 선택은 성능 벤치마크보다 운영 경계의 문제에 가깝다. 코드를 미리 알고, 배포 대상을 통제하고, 런타임 서비스가 필요 없다면 wasm2c 같은 WebAssembly-to-C 경로는 여전히 강한 선택지다. 왜 지금 이슈인가 WebAssembly 런타임을 고를 때 보통 Wasmtime, Wasmer, JIT, AOT, WASI 지원 같은 항목부터 비교한다. 이번 논쟁은 조금 다른 방향에서 출발한다. 더 좋은 런타임을 고르는 문제가 아니라, 런타임을 아예 가져가지 않는 선택이 아직도 실무적으로 맞느냐다. 선정 글감의 저자는 libsodium 벤치마크에서 WABT의 wasm2c 경로를 다시 시험했다. WebAssembly 모듈을 C로 변환한 뒤 zig cc -O3 -march=native로 네이티브 실행 파일을 만드는 방식이다. 비교 대상은 Wasmer 7.1.0, Wasmtime 46.0.0, WABT wasm2c였고, 모든 빌드는 lime1+simd128+wide_arithmetic 기능 세트를 사용했다. ...

한 줄 요약: Base64로 감춘 Bash와 eval은 티셔츠 이스터에그여도 공급망 보안 문제처럼 보일 수 있다. 쟁점은 코드가 악성이냐보다, 사람이 확인하기 전에 실행되는 흐름을 어디까지 허용할지에 가깝다. 왜 지금 이슈인가 난독화된 Bash script, eval, Base64, 공급망 보안은 보안팀만 보는 단어가 아니다. 개발자는 문서, README, 설치 스크립트, CI 설정, SaaS 연동 가이드에서 이런 실행 경로를 자주 만난다. 이번 글감은 조금 엉뚱한 곳에서 시작됐다. Akamai가 UNIQLO Peace for All 캠페인 티셔츠 뒷면에 실제 코드를 넣었고, 그 코드는 Base64 문자열을 디코딩해 Bash 스크립트로 실행하는 형태였다. 디코딩하면 터미널에서 Peace for All 문구를 사인파처럼 출력하는 이스터에그가 나온다. ...

Trusted Publishing과 OIDC를 둘러싼 공급망 보안 논쟁의 핵심은 이 기능을 믿어도 되는지가 아니다. 이 기능이 무엇을 증명하고, 무엇을 증명하지 않는지 구분하는 일이다. 패키지 페이지에 초록 체크가 하나 더 생기면 사람은 안전 신호로 받아들인다. PyPI가 Trusted Publishing 상태를 눈에 띄게 보여주지 않는 이유도 여기에 있다. 기계가 검증해야 할 인증 결과를 사람에게 품질 보증처럼 보여주는 순간, 공급망 보안은 오히려 나빠진다. Trusted Publishing은 안전한 패키지를 고르는 기능이 아니다 Trusted Publishing은 PyPI가 2023년에 도입한 OIDC(OpenID Connect) 기반 게시 인증 방식이다. npm, RubyGems, crates.io, NuGet 같은 다른 패키지 생태계도 비슷한 방향을 받아들였다. 출발점은 단순하다. 레지스트리 API 토큰 같은 장기 자격 증명은 유출되기 쉽고, 실제 필요한 범위보다 넓게 발급되기 쉽다. ...

Postgres 하나로 Redis, Elasticsearch, Kafka까지 대신할 수 있다는 말은 절반만 맞다. 맞는 절반은 운영 복잡도를 줄이라는 경고다. 틀린 절반은 데이터베이스를 만능 런타임처럼 쓰면 된다는 착각이다. Postgres, 데이터베이스 아키텍처, Redis 대체, 검색, 큐, 벡터 검색을 한 문장에 넣으면 논쟁이 바로 붙는다. 이미 Postgres에 JSONB, SKIP LOCKED, full-text search, pgvector, PostGIS가 있는데 왜 저장소를 일곱 개나 굴리냐는 쪽이 있다. 캐시와 검색 엔진과 메시지 브로커는 실패 방식부터 다르니 한 통에 넣으면 장애 반경만 커진다는 반박도 나온다. ...

KVM 보안의 핵심 약속은 단순하다. 게스트는 게스트에 갇힌다. Januscape는 그 약속이 하이퍼바이저 바깥 코드가 아니라 리눅스 커널 안의 KVM/x86 MMU 경로에서 깨질 수 있음을 보여준다. Kubernetes와 클라우드 인프라에서 가상머신은 낡은 기술이 아니다. 컨테이너 워커 노드, CI 하네스, 보안 샌드박스, 멀티테넌트 빌드 환경, AI 에이전트 실행 격리까지 VM 위에 다시 VM을 얹는 구조가 흔해졌다. Januscape(CVE-2026-53359)가 불편한 이유는 여기에 있다. 이 취약점은 QEMU 장치 에뮬레이션 문제가 아니라 KVM/x86의 커널 내부 경로 문제다. 격리의 가장 낮은 층이 흔들리면 그 위에 쌓은 정책은 한꺼번에 방어선을 잃는다. ...

AI 에이전트 보안의 핵심은 더 똑똑한 프롬프트가 아니다. 에이전트에게 넘긴 토큰이 어디까지 도망갈 수 있는지 줄이는 일이다. AI 에이전트가 캘린더, 메일, GitHub, 관측성 도구, 배포 시스템을 대신 만지기 시작하면 문제는 모델 성능에서 신원(identity)으로 옮겨간다. 사람은 요청을 해석하지만, 에이전트는 권한을 실행한다. 그 사이에 OAuth 토큰, OIDC 클레임, mTLS, 세션 기록, 리소스 발견 규격이 끼어든다. 가장 위험한 설계는 단순하다. 사용자가 한 번 로그인하고, 에이전트 런타임 안에 실제 액세스 토큰을 넣어 두는 방식이다. 그 토큰은 파일로 남고, 로그에 찍히고, 저장소에 커밋되고, 프롬프트 인젝션에 속은 에이전트가 외부로 보내버릴 수 있다. 이 구조에서는 에이전트가 뚫린 것이 아니라 토큰이 사람이 된 것이다. ...

장애는 꺼진 서비스를 다시 켜는 순간 끝나지 않는다. Kubernetes, Vault, Kafka 같은 인프라에서 더 위험한 시간은 복구가 시작된 뒤다. 복구는 선의의 부하다. 밀린 메시지를 다시 흘리고, 늦게 도착한 데이터를 재계산하고, DR 클러스터로 트래픽을 넘기고, 캐시가 식은 경로를 다시 데운다. 문제는 이 부하가 평상시 부하와 같은 모양으로 들어오지 않는다는 점이다. Aleksey Charapko가 쓴 metastability in recovery 글은 이 지점을 정확히 짚는다. 장애 전파를 막아도 복구 전파는 남는다. 시스템 A의 장애가 시스템 B로 직접 번지지 않았더라도, A가 회복하면서 밀린 일을 한꺼번에 B로 밀어 넣으면 B는 뒤늦게 복구 모드에 들어간다. B가 다시 원본 데이터를 재조회하면 메시지 버스나 저장소가 흔들린다. 복구가 또 다른 복구를 부른다. ...

홈랩, 셀프호스팅, 인프라 자동화, 관측성 논쟁의 핵심은 장비 숫자가 아니다. 운영 책임을 어디에 둘 것인가다. 서버를 네 대에서 한 대로 줄인 사람은 자유를 얻었고, LLM 게이트웨이를 직접 띄우려는 팀은 비용과 데이터 경로를 되찾으려 한다. 둘 다 같은 질문으로 모인다. 직접 운영한다는 말은 통제권을 갖는다는 뜻이다. 동시에, 장애의 마지막 담당자가 자신이라는 뜻이다. 셀프호스팅은 취미가 아니라 책임 경계 설계다 원문 속 홈랩은 일부러 작다. 여러 서버, 클러스터, 하이퍼바이저, 하이브리드 클라우드 조합을 버리고 단일 물리 서버 하나로 서비스를 모았다. 작성자는 네 대에서 한 대로 줄였기 때문에 유지보수가 75% 줄었다고 말한다. 이 수치는 멋진 자동화 도구보다 더 강한 메시지를 가진다. ...

Testcontainers는 실제 의존성을 띄운다. 그래서 믿음직해 보인다. 문제는 운영 장애가 실제 의존성의 정상 동작에서만 나오지 않는다는 점이다. 테스트 자동화에서 mocks, Testcontainers, fakes 논쟁이 다시 붙는 이유는 단순하다. 코드 생성 에이전트가 더 많은 코드를 만들수록, 팀의 병목은 작성 속도가 아니라 깨진 것을 얼마나 빨리 잡느냐로 옮겨간다. 빠른 테스트도 필요하고 실제 서비스에 가까운 테스트도 필요하다. 다만 둘 다 운영 장애의 핵심인 부분 실패(partial failure)를 놓치면 하네스는 안심 장치가 아니라 장식이 된다. Testcontainers가 잡는 버그와 끝내 놓치는 버그 Testcontainers의 장점은 분명하다. PostgreSQL, Kafka, Redis 같은 실제 의존성을 Docker 컨테이너로 띄우면 SQL 문법, 마이그레이션, 드라이버 설정, 기본 연결 흐름을 검증할 수 있다. 이 층의 버그는 mock으로 잡기 어렵다. ...

Linux kernel epoll 취약점 CVE-2026-46242의 핵심은 낯선 API가 아니다. 끌 수 없는 커널 기본 기능에서 6개 명령어 폭의 레이스가 99% 신뢰도의 권한 상승으로 이어졌다는 점이다. Bad Epoll은 epoll 서브시스템의 레이스 컨디션(Race Condition) 기반 사용 후 해제(Use-After-Free, UAF) 취약점이다. 비권한 프로세스가 root 권한을 얻을 수 있으며, 대상은 일반 Linux 서버와 데스크톱에 그치지 않는다. Android 기기와 Chrome 렌더러 샌드박스 이후 단계까지 위험 범위에 들어간다. 이 사건은 “AI가 커널 취약점을 찾을 수 있는가”보다 “AI가 찾은 버그 옆에 무엇이 남아 있었는가”에 가깝다. Anthropic의 Mythos는 같은 epoll 코드 경로에서 다른 레이스 버그를 찾았다. 그러나 Bad Epoll은 놓쳤다. 사람 연구자는 그 틈에서 실제 exploit과 root shell까지 도달했다. ...