2025-06-02 주간 URL 모음

  • I use Zip Bombs to Protect my Server
    • 요약
      • 봇 트래픽 지배: 대부분의 웹 트래픽은 봇에서 발생하며, 여기에는 합법적인 봇(RSS 리더, 검색 엔진, AI 크롤러)과 웹사이트와 서버에 심각한 손상을 줄 수 있는 악성 봇(스패머, 스크래퍼, 해커)이 포함됩니다.
      • 집 폭탄 개념: 집 폭탄(zip bomb)은 압축 해제 시 극도로 큰 파일로 확장되는 작은 압축 파일로, 이를 처리하려는 시스템을 압도하고 충돌시킬 수 있습니다.
      • 웹 압축 배경: Gzip 압축은 전송 중 파일 크기를 줄여 로딩 시간을 크게 개선하기 위해 웹 역사 초기에 개발되었으며, 브라우저와 봇 모두 대역폭 효율성을 극대화하기 위해 이 기능을 지원합니다.
      • 방어 메커니즘: 저자는 악성 봇이 압축 해제를 시도할 때 1GB-10GB로 확장되는 압축 파일(1MB-10MB)을 제공하여 봇을 충돌시키는 방어 전략으로 집 폭탄을 사용합니다.
      • 구현 방법: 집 폭탄은 dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz 명령어를 사용하여 생성되며, 악성 활동이 감지될 때 적절한 HTTP 헤더(Content-Encoding: gzip)와 함께 제공됩니다.
      • 탐지 및 타겟팅: 시스템은 미들웨어를 사용하여 블랙리스트 IP, 스캐닝 패턴, 스팸 탐지 휴리스틱을 통해 악성 요청을 식별한 후 집 폭탄 응답을 제공합니다.
      • 효과성 및 한계: 이 기법은 악성 봇의 재방문을 성공적으로 줄이거나 제거하지만, 완벽하지는 않으며 콘텐츠를 부분적으로 읽는 정교한 공격자에 의해 탐지될 수 있습니다.
      • 리소스 고려사항: 저자는 서버 부하에 따라 집 폭탄 크기를 조정하고(높은 트래픽 시 더 작은 1MB 파일 사용), 합법적인 사용자가 이를 트리거할 수 있을 때는 일시적으로 기능을 비활성화합니다.
      • 커뮤니티 인사이트: 댓글들은 0 대신 공백 사용, 청크 응답을 통한 무한 집 폭탄 생성, 더 높은 압축률을 달성할 수 있는 고급 압축 방법과 같은 추가 기법들을 보여줍니다.
      • 실용적 결과: 서버 로그는 이 기법이 지속적인 봇 공격을 효과적으로 차단함을 보여주며, 공격적인 스캐너들은 일반적으로 집 폭탄 응답을 받은 후 사라집니다.
  • The Curse of Knowing How, or; Fixing Everything
    • 요약
      • 프로그래밍의 저주: 코딩을 배우면 망가진 소프트웨어에 대한 좌절감이 모든 것을 고쳐야 한다는 도덕적 의무로 바뀌며, 기술적 능력이 책임의 짐이 된다.
      • 고조된 인식: 프로그래밍 지식은 어디서나 비효율성을 알아차리게 만든다 - 비대한 웹사이트, 파싱할 수 없는 CLI 출력, 하드코딩된 설정 등 - 모든 소프트웨어를 개인적인 TODO 리스트로 바꿔버린다.
      • 끝없는 프로젝트 증후군: 저자는 "이것보다 더 잘 만들 수 있다"는 생각으로 정적 사이트 생성기부터 노트 작성 도구, 홈랩 대시보드에 이르기까지 30GB에 달하는 개인 프로젝트를 누적했다고 설명한다.
      • 시시포스와의 유사점: 신화 속 인물처럼 프로그래머들은 시스템 개선이라는 바위를 언덕 위로 끝없이 밀어 올리도록 운명지어졌지만, 시시포스와 달리 우리는 스스로 바위를 만들고 계속 다듬어 나간다.
      • 엔트로피는 항상 승리한다: 소프트웨어 솔루션은 필연적으로 쇠퇴한다 - 라이브러리는 사용 중단되고, API는 변경되며, 종속성은 깨진다 - 지속적인 유지보수가 필요하고 문제가 발생했을 때 죄책감을 만들어낸다.
      • "완료"의 착각: 프로그래머들은 완벽한 설정이 영원히 지속되고 자동화가 영구적으로 시간을 절약해줄 것이라고 스스로를 속이지만, 현실은 유지보수와 업데이트의 끝없는 순환이다.
      • 감정적 대처법으로서의 프로그래밍: 도구를 만드는 것은 종종 자기진정 행동이자 인생이 혼란스러울 때 통제감을 느끼는 방법으로 작용하며, 실제 삶에서는 부족한 즉각적인 피드백과 주체성을 제공한다.
      • 과도한 책임감으로 인한 번아웃: 진짜 번아웃은 과로에서 오는 것이 아니라, 잠재적으로 고칠 수 있는 기술을 가지고 있기 때문에 마주치는 모든 비효율성에 대해 책임감을 느끼는 데서 온다.
      • 놓아주는 법 배우기: 해결책은 모든 망가진 것이 고쳐질 필요가 없다는 것을 인식하고, 해결 가능한 문제에서 물러날 수 있는 절제력을 기르며, 도움을 위한 구축과 대처를 위한 구축을 구별하는 것이다.
      • 기술보다 감정적 숙련: 저자는 가장 중요한 기술은 기술적 능력이 아니라 감정적 명확성 - 어떤 문제가 당신의 에너지를 쏟을 가치가 있는지 알고 언제 문제를 그대로 두어야 하는지 아는 것이라고 결론짓는다.
  • Pixel is a unit of length and area
    • 요약
      • "픽셀"이라는 단위는 디지털 이미징에서 일관되지 않게 사용되는데, 때로는 선형 길이의 단위로(예: 폭 1920픽셀), 때로는 면적의 단위로(예: 카메라 센서의 1200만 픽셀) 사용된다.
      • 선형 단위로 취급될 때, 수학적 차원 분석에 따르면 픽셀 단위의 폭 × 높이를 곱하면 미터가 제곱미터를 만들어내는 것과 유사하게 제곱픽셀(pixel²)이 나와야 한다.
      • 그러나 일반적인 사용법에서는 픽셀을 면적 단위로 취급하여, 20×30 픽셀 이미지가 총 600픽셀을 가진다고 하는데, 이는 수학적으로 pixel² = pixel임을 의미하며, 픽셀을 라디안처럼 무차원으로 만든다.
      • 이러한 불일치는 순수 수학과 일상적 사용법 사이에 깔끔한 해결책이 없는 긴장을 만들어낸다.
      • 제안된 해결책 중 하나는 픽셀을 정사각형 단위로 정의하고 폭과 높이의 선형 측정을 위해 "픽셀-변" 또는 √pixel을 도입하는 것이다.
      • 다른 접근법은 픽셀을 엄격히 선형 단위로 취급하여, 모든 면적 측정을 현재의 "메가픽셀" 용어 대신 "제곱픽셀"로 표현하도록 요구하는 것이다.
      • 미터법 접두사 체계는 제곱픽셀 접근법에서 문제가 되는데, "메가픽셀"이 "제곱킬로픽셀" 같은 어색한 용어나 "800만 제곱픽셀" 같은 큰 숫자가 되어야 하기 때문이다.
      • 픽셀은 미터법 단위가 아니고 "미터당 픽셀" 같은 단순한 비율 계산 외에는 복잡한 계산에 거의 참여하지 않기 때문에, 이러한 용어 문제는 치명적이지 않다.
      • 픽셀 단위의 불일치는 다른 단위 충돌과 유사한데, 예를 들어 파운드가 질량과 힘 모두에 사용되는 반면, 미터법은 킬로그램과 뉴턴을 깔끔하게 분리하는 것과 같다.
      • 이 논의는 일반적인 용어가 과학자들이 계산에서 물리적 단위를 다룰 때 기대하는 규칙성을 어떻게 깨뜨릴 수 있는지를 강조한다.
  • Gemini Diffusion
    • 요약
      • Google은 Google I/O에서 기존의 자기회귀 생성 방식 대신 확산 기술을 사용하는 첫 번째 LLM인 Gemini Diffusion을 발표했습니다
      • 텍스트를 토큰별로 순차적으로 생성하는 기존 모델과 달리, 확산 모델은 노이즈를 단계별로 정제하여 출력을 생성하므로 더 빠른 반복과 오류 수정이 가능합니다
      • 핵심 장점은 놀라운 속도입니다 - 대화형 HTML+JavaScript로 시뮬레이션된 채팅 앱을 구축할 때 초당 857토큰으로 생성하며 한 자릿수 초 안에 완료되는 것을 시연했습니다
      • 성능은 약 2,000토큰/초로 실행되는 Cerebras Coder 도구와 비교할 만하며, "Gemini 2.0 Flash-Lite의 성능을 5배 빠른 속도로" 제공한다고 약속합니다
      • 기술적 설명: 확산은 자기회귀를 대체하는 것이지 트랜스포머를 대체하는 것이 아닙니다 - 이 모델은 여전히 트랜스포머 아키텍처를 사용하되 인과적 마스킹(causal masking)은 없을 가능성이 높습니다
      • 확산 LLM은 BERT의 마스크드 언어 모델링과 유사하게 작동합니다 - 다양한 비율(15%, 30%, 50%, 90%, 100%)의 마스크된 토큰으로 텍스트를 복구하도록 훈련됩니다
      • 생성 과정: 모든 MASK 토큰으로 시작하여, 완전한 시퀀스가 생성될 때까지 여러 단계에 걸쳐 반복적으로 마스크의 약 10%를 "최종" 토큰으로 교체합니다
      • 이는 순차적 텍스트 생성에서 병렬적, 반복적 정제 접근법으로의 중요한 전환을 나타냅니다
      • 이전의 상용 확산 모델로는 2024년 2월의 Inception Mercury가 있어, LLM에서는 비교적 새로운 접근법입니다
  • GitHub - pydantic/pydantic.run: Python browser sandbox.
    • 요약
      • Pydantic.run은 Pyodide 기반의 Python 브라우저 샌드박스로, 브라우저에서 Python 코드를 작성하고 실행할 수 있는 플랫폼
      • Pydantic, PydanticAI, Pydantic Logfire를 시연하기 위해 구축됨
      • 코드 저장은 CloudFlare R2 객체 스토리지에 저장되며 1년간 사용 가능
      • 의존성은 코드 실행 시 자동으로 설치되며, 두 가지 방식으로 정의 가능
      • 첫 번째 방식: 자동 추론 - 메타데이터가 없으면 코드의 import 문에서 의존성을 자동으로 추론
      • 두 번째 방식: PEP 723 스타일 - 파일 상단에 주석으로 의존성을 명시적으로 정의 (# /// script 블록 사용)
      • PEP 723 방식은 코드에서 직접 import하지 않는 의존성도 사용 가능하고 더 명시적임
      • 바이너리가 아닌 패키지의 경우 버전 고정도 가능 (Pyodide는 pydantic, numpy 같은 바이너리 패키지는 단일 버전만 지원)
      • 프로그래밍 방식으로 샌드박스 생성 가능 - https://pydantic.run/new에 GET 요청으로 files 파라미터에 JSON 객체 전달
      • API 응답은 302 리다이렉트로 새로 생성된 샌드박스로 이동하며, 동일한 files로 반복 요청 시 같은 샌드박스 재사용
  • GitHub - livingbio/typed-ffmpeg: Modern Python FFmpeg wrappers offer comprehensive support for complex filters, complete with detailed typing and documentation.
    • 요약
      • typed-ffmpegffmpeg-python에서 영감을 받아 포괄적인 타이핑 지원과 문서화를 제공하는 FFmpeg의 파이썬다운 인터페이스를 제공하는 현대적인 Python 라이브러리입니다
      • Zero Dependencies (의존성 없음): 최대 호환성과 보안을 위해 Python 표준 라이브러리만으로 완전히 구축되었습니다
      • 주요 특징: 사용자 친화적인 인터페이스, IDE 자동 완성을 지원하는 포괄적인 FFmpeg 필터 지원, 통합 문서화, 견고한 타이핑, 그리고 필터 그래프의 JSON 직렬화
      • 고급 기능: graphviz를 사용한 그래프 시각화, 필터 그래프의 검증 및 자동 수정, 포괄적인 입출력 옵션 지원, 그리고 모듈식 구성을 위한 부분 평가
      • 향후 개발: 확장된 FFmpeg 버전 지원(현재는 v6.0용으로 구축됨) 작업 중이며 지원되는 필터 범위를 확장하고 있습니다
      • 설치: pip install typed-ffmpeg로 설치 가능(시스템에 FFmpeg 필요), ffmpeg-python과의 호환성을 위해서는 pip install typed-ffmpeg-compatible 사용
      • 그래프 시각화: pip install 'typed-ffmpeg[graph]'로 제공되는 선택적 기능(Graphviz 설치 필요)
      • 인터랙티브 플레이그라운드: 로컬 설정 없이 FFmpeg 필터 실험, 그래프 시각화, 학습을 위한 브라우저 기반 환경
      • 개발 역사: 원래는 문서에서 FFmpeg SDK를 생성하기 위해 GPT-3를 사용하는 것으로 구상되었지만, 개발 가속화를 위해 AI 도구를 활용하면서도 전통적인 코드 생성 방법으로 전환했습니다
      • 헌정: 이 프로젝트는 저자의 아들 Austin의 일곱 번째 생일을 맞아 그에게 헌정되었으며, ffmpeg-python 프로젝트로부터의 영감을 인정합니다