태그: #reliability
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 25 편
프로덕션 감각 — 장애를 겪어 본 사람이 다르게 보는 것들
같은 설계 문서를 읽어도 장애를 겪어 본 사람은 다른 것을 읽습니다. 이게 새벽에 깨지면 무슨 로그가 남는지, 되돌리는 데 몇 분이 걸리는지, 되돌린 뒤 이미 들어간 데이터는 어떻게 되는지입니다. 이 글은 프로덕션이 왜 코드가 아니라 상태인지, 100퍼센트가 왜 옳은 신뢰성 목표가 아닌지, 관측과 롤백과 점진 배포가 왜 도구 도입이 아니라 기본값의 문제인지, 그리고 장애를 직접 겪지 않고도
2026-08-15 · 13 분 읽기 #career#skills#sre#production#reliability657,607개의 링크를 따라가 본 결과와 URL 수명 — 링크는 왜 404가 아니라 연결 실패로 죽는가
2009년부터 2014년 사이에 만들어진 단축 링크 65만여 개를 2026년에 전부 따라가 본 조사가 공개됐습니다. 결과보다 중요한 것은 실패의 구성입니다. 죽은 링크의 대부분은 404가 아니라 연결 자체가 되지 않는 상태였고, 이는 내용이 옮겨진 것이 아니라 인프라가 사라졌다는 뜻입니다. 조사 방법의 한계까지 짚은 뒤에, 외부 URL을 데이터로 보관하는 시스템에서 무엇을 다르게 해야 하는지
2026-08-14 · 13 분 읽기 #web#data-engineering#archival#reliability#url-designAI 에이전트를 프로덕션에서 운영한다는 것 — 멱등성, 예산, 그리고 확신에 찬 오답
에이전트를 프로토타입에서 프로덕션으로 옮길 때 늦게 발견되는 운영 표면이 있습니다. 재시도된 도구 호출의 멱등성, 예산과 스텝 한도, 비결정적 제어 흐름의 관측 가능성, 도구별 권한 경계, 그리고 에이전트가 확신에 차서 틀렸을 때의 에스컬레이션 경로입니다. 최근 GeekNews Ask GN에 올라온 분석은 벤치마크 트레이스 6,780건에서 중복 도구 실행 8,042건을 찾았고, 그중 159건
2026-07-31 · 29 분 읽기 #ai#agents#observability#reliability#mcp레이트 리밋 알고리즘 고르기 — 고정 윈도우, 슬라이딩, 토큰 버킷의 실제 차이
분당 100회로 막았는데 200회가 통과하는 것은 버그가 아니라 고정 윈도우 알고리즘의 정의된 동작입니다. 고정 윈도우, 슬라이딩 로그, 슬라이딩 윈도우 카운터, 토큰 버킷 네 가지의 메모리와 정확도 트레이드오프를 표로 비교하고 경계 문제를 숫자로 확인합니다. 분산 환경에서 레디스 원자적 연산이 왜 필요한지, 노드별 로컬 리밋이 만드는 오차가 얼마나 되는지, IP를 키로 삼으면 무엇이 깨지는
2026-07-26 · 22 분 읽기 #web#rate-limiting#api-design#redis#reliabilityTemporal Worker Versioning GA — 리플레이 모델이 만든 배포 문제, 두 세대를 버리고 나온 세 번째 답
Temporal 같은 내구 실행 엔진은 이벤트 이력을 리플레이해 장애를 견디는데, 바로 그 리플레이 때문에 "실행 중인 워크플로가 있는 채로 새 코드를 배포"하는 일이 이 모델에서 가장 까다로운 문제가 됩니다. Temporal은 2026년 3월 30일 Worker Versioning의 GA를 발표했고 OSS 서버로는 v1.31.0(4월 29일)에 명시됐습니다 — 2023년 6월 첫 프리뷰 이
2026-07-17 · 24 분 읽기 #distributed-systems#durable-execution#temporal#workflow-engine#reliabilityAI 에이전트는 프로덕션에서 어떻게 실패하는가 — 14가지 실패 모드, 그리고 재시도가 안전하지 않은 이유
에이전트를 프로덕션에 올리면 세 가지가 아픕니다. 첫째, 실패는 모델이 아니라 시스템 설계에서 납니다 — UC 버클리의 MAST 연구는 실행 트레이스 1642건을 분류해 14가지 실패 모드를 뽑았고, 그중 44.2%가 시스템 설계 이슈였습니다. 둘째, 가장 흔한 실패 모드 두 개(단계 반복 15.7%, 종료 조건 미인지 12.4%)가 곧바로 토큰 청구서입니다. 셋째, 바로 그 두 개가 재시도
2026-07-17 · 40 분 읽기 #ai#agents#observability#reliability#mcp결제 멱등성: 이중 결제를 막는 법
네트워크는 언젠가 반드시 끊기고, 끊기면 재시도합니다. 그런데 결제에서 재시도는 이중 결제가 될 수 있습니다. 멱등성 키, 중복 제거 윈도우, 유니크 제약, 재시도+타임아웃 문제, at-least-once에 dedup을 더하는 설계, 결제 상태 기계, 그리고 Stripe 스타일 멱등성 구현까지 — 돈을 한 번만 청구하는 법을 정리합니다.
2026-07-02 · 27 분 읽기 #payments#idempotency#reliabilityExactly-once는 환상인가: 결제·메시징의 정확성
전달 보장의 세 등급(at-most-once, at-least-once, exactly-once)이 실제로 뜻하는 것, 왜 exactly-once "전달"은 원리적으로 불가능하지만 exactly-once "처리"는 멱등성·중복 제거·트랜잭션 아웃박스로 달성 가능한지, 두 장군 문제가 알려 주는 것, 그리고 Kafka의 exactly-once가 무엇을 진짜로 보장하는지까지. 결제와 메시징의 정
2026-06-28 · 27 분 읽기 #distributed-systems#messaging#reliability레이트 리미팅 알고리즘 완전정복: 고정 윈도우·슬라이딩 윈도우·토큰 버킷·리키 버킷
고정 윈도우, 슬라이딩 윈도우 로그와 카운터, 토큰 버킷, 리키 버킷까지 대표적인 레이트 리미팅 알고리즘을 하나씩 대조합니다. 버스트를 어떻게 다룰지, Redis로 분산 환경에서 어떻게 구현할지, 그리고 429와 Retry-After, 클라이언트의 백오프 예절까지 정리합니다.
2026-06-25 · 21 분 읽기 #systems#api#reliability멱등성과 재시도: 신뢰할 수 있는 API
네트워크는 언젠가 반드시 실패하고, 실패하면 재시도해야 합니다. 문제는 "이미 처리됐는데 응답만 못 받은" 경우입니다. 멱등성이 무엇인지, 안전한 HTTP 메서드와 그렇지 않은 메서드, POST를 위한 멱등성 키, "정확히 한 번"이라는 신화, 그리고 지수 백오프와 지터로 천둥 소리 무리를 피하는 법을 정리합니다.
2026-06-21 · 24 분 읽기 #api#reliability#distributed-systems마이그레이션 사고 사례와 체크리스트 — 남의 실패에서 배우기
마이그레이션은 가장 흔하면서도 가장 아픈 장애의 원천입니다. 락 폭주, 복제 지연, 데이터 손실, 롤백 불가 같은 전형적 사고 유형을 짚고, 세 건의 가상 포스트모템으로 증상에서 원인과 교훈을 끌어내며, 예방 패턴과 종합 체크리스트로 정리합니다.
2026-06-16 · 27 분 읽기 #database#migration#postmortem#incident#reliabilityExpand-Contract 패턴 — 무중단 스키마 변경의 정석
운영 중인 데이터베이스의 스키마를 무중단으로 바꾸는 표준 기법인 Expand-Contract 패턴을 정리합니다. 컬럼 추가, 이름 변경, 삭제, 제약 조건 추가 같은 시나리오별 SQL과 더블 라이트, 점진적 백필, 애플리케이션 코드 협업, 롤백 전략까지 단계별로 다룹니다.
2026-06-16 · 24 분 읽기 #database#migration#zero-downtime#expand-contract#reliabilityDB 마이그레이션 전략 개론 — 스키마, 데이터, 그리고 무중단
데이터베이스 마이그레이션의 종류와 위험, 버전 관리형 마이그레이션, 무중단 배포 원칙을 체계적으로 정리합니다. 트랜잭셔널 DDL, 백업과 드라이런, 환경 승격, 팀 프로세스, 사고 예방 체크리스트까지 실전 관점에서 다룹니다.
2026-06-16 · 30 분 읽기 #database#migration#schema#devops#reliability잘 실패하는 코드 — 에러 핸들링과 회복탄력성 설계 깊이 파보기 (2026)
에러 핸들링은 기능을 다 만든 뒤 붙이는 장식이 아니라 설계 그 자체다. 실패의 종류를 분류하고, 예외와 에러 값 중 무엇을 쓸지 정하고, 경계에서 검증하고 코어를 신뢰하며, 모든 원격 호출에 타임아웃을 걸고, 재시도에 지터를 넣고, 멱등성으로 안전하게 재시도하고, 서킷 브레이커로 장애를 격리하고, 우아하게 성능을 낮추는 — 코드 레벨에서 잘 실패하는 소프트웨어를 설계하는 법.
2026-05-14 · 43 분 읽기 #error-handling#resilience#retry#circuit-breaker#timeout에이전트 평가 시스템 2026 — Inspect AI·Promptfoo·Phoenix·LangSmith·OpenAI Evals 심층 비교 (모델이 아니라 에이전트를 측정한다)
LLM 평가는 모델을 측정한다. 에이전트 평가는 모델 + 하네스 + 도구가 실제 작업을 끝까지 끌고 가는지를 측정한다. 두 개는 완전히 다른 문제다. 2026년 현재 에이전트 평가 프레임워크의 지도를 그린다 — UK AISI의 Inspect AI(점점 골든 스탠더드), Promptfoo(OSS CLI), Arize Phoenix(OSS 옵저버빌리티+eval), LangSmith(LangCha
2026-05-14 · 34 분 읽기 #agent-evaluation#inspect-ai#promptfoo#phoenix#langsmith로드/성능 테스트 도구 2026 — k6·Locust·Vegeta·Gatling·Artillery·JMeter 심층 비교 (JMeter 너머의 풍경)
성능 테스트는 2026년에도 어렵다. 그러나 도구는 확실히 좋아졌다. JS로 짜는 k6, Python으로 짜는 Locust, 한 줄로 끝내는 Vegeta, 엔터프라이즈의 Gatling, YAML로 빨리 붙이는 Artillery, 마이크로 벤치마크의 wrk/wrk2와 autocannon, 그리고 여전히 살아 있는 JMeter. gRPC·WebSocket·브라우저 모드까지 손이 닿는 k6의 확장
2026-05-14 · 31 분 읽기 #load-testing#performance-testing#k6#locust#vegetaDurable Execution 엔진 2026 — Temporal·Restate·Inngest·Trigger.dev·DBOS 깊이 비교: 크론과 재시도 지옥에서 벗어나는 법
장시간 실행되는 워크플로를 더 이상 크론과 큐와 if-else로 짜지 마라. 2026년의 답은 Durable Execution이다. Temporal·Restate·Inngest·Trigger.dev·DBOS, 그리고 AWS Step Functions·Cadence·Azure Durable Functions까지 — 결정적 재실행·체크포인팅·워크플로 코드 패러다임이 어떻게 백엔드를 다시 짜고 있
2026-05-14 · 40 분 읽기 #durable-execution#temporal#restate#inngest#trigger-dev유명 포스트모템 해부 — Cloudflare·Fastly·AWS·Knight Capital·GitLab의 실패에서 배우기
Cloudflare 2022 BGP, Fastly 2021 인터넷 절반 다운, AWS S3 2017 오타, Knight Capital 8분 $440M, GitLab DB wipe 등 — 유명한 실패에서 추출한 패턴과 교훈.
2026-04-15 · 16 분 읽기 #postmortem#sre#outage#reliability#cultureChaos Engineering 완전 해부 — Netflix Simian Army, LitmusChaos/Chaos Mesh, AWS FIS, Game Day
2010년 Netflix가 왜 프로덕션 서버를 무작위로 죽이기 시작했나. Chaos Monkey 철학부터 4가지 원칙, Simian Army 전체 구성, LitmusChaos/Chaos Mesh/AWS FIS 도구 비교, Game Day 훈련 설계, 비난 없는 포스트모템까지.
2026-04-15 · 20 분 읽기 #chaos-engineering#sre#reliability#netflix#kubernetesAWS Well-Architected Framework 완전 가이드 2025: 6개 기둥, 실전 적용, 비용/보안/성능
AWS Well-Architected Framework의 모든 것! 6개 기둥(Operational Excellence, Security, Reliability, Performance, Cost, Sustainability), 실전 체크리스트, AWS Well-Architected Tool 사용법, 일반적 안티패턴, 마이그레이션 시 적용.
2026-04-15 · 22 분 읽기 #aws#well-architected#cloud-architecture#security#reliability