블로그

한국어English日本語中文

#2026-03 762#culture 283#deep-dive 275#kubernetes 260#career 233#ai 220#llm 216#devops 195#2026-04 158#security 147#observability 118#database 113#communication 108#history 107#architecture 101#productivity 98#performance 93#linux 90#networking 89#finance 87#economy 84#mindset 80#psychology 79#ai-papers 78#food 78#it 78#travel 78#japanese 76#deep-learning 75#english 74#gpu 74#ai-agent 69#business-travel 69#postgresql 66#cs-fundamentals 63#rag 63#systems 63#python 55#learning 54#self-improvement 53

• 657,607개의 링크를 따라가 본 결과와 URL 수명 — 링크는 왜 404가 아니라 연결 실패로 죽는가

  2009년부터 2014년 사이에 만들어진 단축 링크 65만여 개를 2026년에 전부 따라가 본 조사가 공개됐습니다. 결과보다 중요한 것은 실패의 구성입니다. 죽은 링크의 대부분은 404가 아니라 연결 자체가 되지 않는 상태였고, 이는 내용이 옮겨진 것이 아니라 인프라가 사라졌다는 뜻입니다. 조사 방법의 한계까지 짚은 뒤에, 외부 URL을 데이터로 보관하는 시스템에서 무엇을 다르게 해야 하는지

  2026-08-14 · 13 분 읽기 #web#data-engineering#archival#reliability#url-design

• Gemini 3.7 Flash의 도입가와 3주 주기 — 모델 원가를 계약이 아니라 확률로 잡아야 하는 이유

  Gemini 3.7 Flash 발표에서 실무자가 봐야 할 것은 벤치마크 상승폭이 아니라 두 가지입니다. 하나는 특정 날짜에 단가가 두 배로 오르는 도입가 구조이고, 다른 하나는 직전 모델이 3주 전에 나왔다는 사실입니다. 이 둘이 겹치면 모델 원가는 고정비가 아니라 만료일이 붙은 조건부 값이 됩니다. 공개된 벤치마크가 무엇을 비교하고 무엇을 비교하지 않는지, 그리고 발표에서 끝내 공개되지 않

  2026-08-14 · 13 분 읽기 #llm#cost-optimization#benchmark#api-design#capacity-planning

• Cerebras Ultrafast와 에이전트 루프의 병목 — 초당 750토큰이 줄이지 못하는 시간

  Cerebras와 OpenAI가 초당 최대 750토큰을 내는 추론 티어를 공개했습니다. 발표문이 밝히는 원리는 연산량이 아니라 데이터 이동이고, 가중치를 웨이퍼 위 SRAM에 올려 두는 방식입니다. 왜 배치 1의 디코딩이 메모리 대역폭에 묶이는지, 발표된 배속 수치가 무엇을 재고 무엇을 재지 않는지, 그리고 토큰 생성이 빨라져도 줄지 않는 시간이 여러분의 에이전트 루프에서 몇 퍼센트인지 계산

  2026-08-14 · 14 분 읽기 #llm#inference#hardware#latency#performance

• 폐쇄망 운영 플레이북 — 보안 패치를 따라가고, 롤백하고, CVE 지연을 관리하기

  반입 절차가 완성된 다음의 이야기, 즉 폐쇄망을 몇 년간 굴리는 운영 편입니다. 먼저 폐쇄망에서 CVE 대응이 늦어지는 것이 팀의 게으름이 아니라 반입 주기라는 구조 때문임을 분명히 하고, 그 지연을 없앨 수 없다면 어떻게 측정하고 관리할지를 다룹니다. dnf updateinfo와 --security 계열 옵션으로 무엇이 밀려 있는지 세는 방법을 공식 문서 기준으로 정리하되, 반입 저장소에서

  2026-08-14 · 19 분 읽기 #linux#rhel#air-gap#dnf#security

• 폐쇄망 컨테이너 이미지 반입 — podman save와 skopeo는 다른 도구입니다

  RPM 반입 절차가 자리를 잡고 나면 다음 요구는 거의 항상 컨테이너 이미지입니다. podman save와 skopeo copy 계열이 어떻게 다른지 — 하나는 로컬 저장소를 거치고 다른 하나는 레지스트리에서 레지스트리로 직접 옮긴다는 점 — 부터 정리하고, 여러 이미지를 한 번에 다루는 폐쇄망 미러링에는 왜 skopeo sync가 정답인지 공식 문서의 표현과 함께 설명합니다. 트랜스포트 표

  2026-08-14 · 18 분 읽기 #linux#rhel#air-gap#podman#skopeo

• 하네스 지문과 버전 관리 — 기록 없는 변경을 추적 가능하게

  프롬프트 커밋도 모델 변경도 없는데 성공률이 움직였다면, 무엇을 되돌려야 할까요. 하네스 엔지니어링 시리즈 7편은 하네스를 구성하는 모든 결정을 정규화된 해시 하나로 요약하는 하네스 지문을 다룹니다. 지문에 무엇을 넣고 무엇을 빼는지, 왜 지문이 같아야 비교가 성립하는지, 그리고 지문 이력으로 회귀를 이등분해 롤백하는 방법까지 정리했습니다.

  2026-08-12 · 9 분 읽기 #llm#agent#harness-engineering#하네스엔지니어링#AI에이전트

• 하네스 엔지니어로 성장하기 — 왜 생긴 직무이고 무엇을 연습해야 하나

  하네스 엔지니어라는 직함은 채용 공고에 드물지만, 그 일은 에이전트를 배포하는 모든 팀에 이미 있습니다. 하네스 엔지니어링 시리즈 마지막 8편에서 이 직무가 왜 생겼는지, 기존 소프트웨어 역량이 어떻게 재배치되는지, 그리고 관측과 지문부터 자기 개선 루프까지 여섯 개의 근육을 하네스 RPG의 6개 티어로 단계별 연습하는 경로를 정리했습니다.

  2026-08-12 · 9 분 읽기 #llm#agent#harness-engineering#하네스엔지니어링#AI에이전트

• 도구 표면 설계 — 스키마 한 줄이 성공률을 움직입니다

  도구를 더 붙였는데 에이전트 성공률이 떨어지는 일은 드물지 않습니다. 도구 표면은 에이전트의 인터페이스이고, 이름·설명·파라미터·실패 반환·응답 크기가 전부 설계 대상입니다. 하네스 엔지니어링 시리즈 3편에서 도구 수의 저주, 네임스페이싱과 설명 문구, 포카요케 파라미터, 실패를 돌려주는 형식까지 도구 표면 설계를 정리했습니다.

  2026-08-12 · 10 분 읽기 #llm#agent#harness-engineering#하네스엔지니어링#AI에이전트

• 컨텍스트 예산 — 무엇을 넣을지가 아니라 무엇을 뺄지가 설계입니다

  컨텍스트 창은 아직 남았는데 에이전트 정확도는 떨어집니다. 컨텍스트는 유한한 주의 예산이고, 도구 스키마도 그 예산을 먹습니다. 하네스 엔지니어링 시리즈 2편에서 프롬프트 누적을 플레이북으로 바꾸는 법, 드롭 정책과 컴팩션의 기준, 서브에이전트 위임의 비용까지 컨텍스트 예산 설계를 정리했습니다.

  2026-08-12 · 11 분 읽기 #llm#agent#harness-engineering#하네스엔지니어링#AI에이전트

• 지금 주목받는 오픈소스 (6) 스타 수가 말해 주지 않는 것

  스타 수는 인기 지표이지 위험 지표가 아닙니다. 오픈소스를 프로덕션에 들이기 전에 실제로 확인해야 하는 신호를 정리합니다. 최근 커밋과 릴리스 주기, 이슈 응답, 기여자 분포와 버스 팩터를 GitHub API로 직접 세는 방법, 라이선스가 자동 분류되지 않을 때 LICENSE 파일을 직접 읽어야 하는 이유, 그리고 도입 전 체크리스트를 담았습니다. 시리즈에서 실제로 확인한 사례를 근거로 삼았

  2026-08-12 · 10 분 읽기 #open-source#governance#supply-chain#risk#devops

• 지금 주목받는 오픈소스 (1) AI 에이전트와 LLM 도구

  LLM 애플리케이션 스택은 추론 서버, 오케스트레이션, 게이트웨이, 에이전트, RAG로 층이 갈라졌습니다. 각 층에서 실제로 쓰이는 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 프로젝트마다 무엇을 대체하는지, 성숙도가 어느 정도인지, 어떤 상황에서 쓰면 안 되는지를 함께 정리했고, 저장소 경로와 라이선스, 스타 수, 최근 푸시 날짜는 2026년 8월 12일 GitHub에서

  2026-08-12 · 10 분 읽기 #open-source#llm#ai-agent#ai-platform#rag

• 컨테이너 인프라의 세대교체 — 자리를 내준 11개 프로젝트가 남긴 것

  한때 컨테이너 인프라의 기본 구성이었다가 지금은 다른 것으로 대체된 프로젝트 11개를 공식 공지와 저장소 보관 상태만 근거로 정리합니다. rkt, dockershim, Classic Swarm, Docker Machine, Compose V1, Heapster, Apache Mesos, PodSecurityPolicy, CoreOS Container Linux, ingress-nginx, 그

  2026-08-12 · 19 분 읽기 #open-source#kubernetes#container#docker#infrastructure

• 지금 주목받는 오픈소스 (3) 인프라와 데이터베이스

  데이터베이스와 인프라 영역은 라이선스 변경과 포크가 판을 다시 짠 분야입니다. 분석 엔진, 임베디드 데이터베이스, 포스트그레스 확장, 쿠버네티스 오퍼레이터, IaC까지 실제로 자리를 잡은 오픈소스 11개를 스타 순위가 아니라 해결하는 문제별로 묶어 소개합니다. 무엇을 대체하는지, 어느 정도 성숙했는지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는

  2026-08-12 · 9 분 읽기 #open-source#database#infrastructure#postgresql#kubernetes

• 지금 주목받는 오픈소스 (5) 데이터와 ML 파이프라인

  데이터 파이프라인은 스케줄러 하나로 해결되지 않습니다. 적재, 변환, 오케스트레이션, 실행 엔진, 모델 수명 주기, 검색 저장소가 각각 다른 도구의 영역이 되었습니다. 이 층들에서 실제로 쓰이는 오픈소스 11개를 스타 순위가 아니라 담당 구간별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수, 최근 푸시는

  2026-08-12 · 9 분 읽기 #open-source#data-engineering#mlops#python#rust

• 언어와 런타임의 세대교체 — 공식 EOL 공지로 읽는 11개 프로젝트

  공식 종료 공지가 남아 있는 언어와 프레임워크, 런타임 11개를 정리합니다. Python 2, AngularJS, Vue 2, Nashorn, 자바 애플릿과 웹 스타트, Mono, Xamarin, PhoneGap, Atom, io.js, jQuery Mobile을 각각 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠

  2026-08-12 · 20 분 읽기 #open-source#javascript#java#python#framework

• 기본값에서 내려온 빌드 도구들 — 프론트엔드 툴체인 10개가 자리를 내준 이유

  한때 프론트엔드 프로젝트의 기본값이었다가 지금은 새 프로젝트에서 잘 고르지 않게 된 도구 10개를, 공식 폐기 공지와 저장소 보관 상태 같은 확인 가능한 근거만으로 정리합니다. Create React App, Bower, TSLint, Karma, Protractor, PhantomJS, LibSass와 node-sass, Moment.js, Rome, Grunt를 각각 무엇이었나, 왜 그때

  2026-08-12 · 16 분 읽기 #open-source#frontend#build-tools#deprecation#javascript

• 지금 주목받는 오픈소스 (4) 관측 가능성과 보안

  관측 데이터는 양이 곧 비용이고, 보안 도구는 파이프라인에 들어가지 못하면 쓰이지 않습니다. 계측 표준, 저장 엔진, eBPF 기반 런타임 감시, 공급망 검증까지 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 담당하는 층별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는 202

  2026-08-12 · 9 분 읽기 #open-source#observability#security#opentelemetry#ebpf

• 지금 주목받는 오픈소스 (2) 빌드·에디터·CLI·터미널

  패키지 설치, 린트, 번들링처럼 하루에 수십 번 반복되는 작업이 네이티브 언어로 다시 쓰이면서 대기 시간이 초 단위에서 밀리초 단위로 내려갔습니다. 빌드 도구, 에디터, 터미널, CLI 영역에서 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수

  2026-08-12 · 9 분 읽기 #open-source#developer-tools#cli#rust#performance

• 무엇이 기술을 교체시키는가 — 우리 스택이 그 궤적 위에 있는지 점검하는 법

  자리를 내준 오픈소스 시리즈의 마지막 편입니다. 앞선 세 편에서 다룬 30여 개 프로젝트를 가로질러, 기술을 교체시키는 힘이 무엇인지 다섯 가지로 정리합니다. 플랫폼 흡수, 운영 부담, 유지보수 인력, 라이선스 변경, 문제 정의의 이동. 특히 라이선스 변경은 MongoDB와 Elastic, HashiCorp, Redis 사례를 어디에서 어디로 바뀌었는지 사실만으로 표에 정리하고, 그 결과 생

  2026-08-12 · 14 분 읽기 #open-source#architecture#license#migration#governance

• 데이터 저장소와 큐의 세대교체 — 라이선스, 포크, 그리고 Attic으로 간 프로젝트들

  데이터 계층에서 자리를 내주었거나 배포 조건이 바뀐 프로젝트 10개를 공식 발표문과 Apache Attic 기록만 근거로 정리합니다. Redis와 Elasticsearch, MongoDB의 라이선스 변경과 그로 인해 생긴 Valkey, OpenSearch 포크를 사실만으로 다루고, Kafka에서 ZooKeeper가 빠진 과정, Apache Attic으로 이관된 Sqoop과 Oozie, Gir

  2026-08-12 · 18 분 읽기 #open-source#database#kafka#redis#elasticsearch