블로그 아카이브 | jyukki's Blog

아카이브 글

이 페이지는 블로그의 전체 글을 학습, 트렌드, 프로젝트 관점으로 빠르게 훑기 위한 허브입니다. 글 수가 늘어나면 최신 글만 따라가서는 맥락이 끊기기 쉬워서, 어떤 독자가 어떤 순서로 읽으면 좋은지 한눈에 잡을 수 있게 구조를 정리해 두는 편이 더 낫다고 생각했습니다.

특히 이 블로그는 단순 뉴스 요약보다, 실무 의사결정에 바로 연결되는 기준을 남기는 데 초점을 두고 있습니다. 그래서 같은 주제라도 “개념 설명”, “운영 관점 해석”, “프로젝트 구현 경험”이 섞여 있습니다. 아카이브를 볼 때는 최신순보다도, 지금 내게 필요한 읽기 목적이 무엇인지 먼저 정하고 들어오는 편이 효율적입니다.

이번 주 먼저 읽으면 좋은 흐름

이번 주의 새 글은 배포 결정을 위한 LLM 평가 → 관측 데이터의 완전성 → 플랫폼 리소스 계약 → 실행 권한의 경계라는 하나의 흐름으로 읽는 편이 좋습니다. 최근 글의 공통점은 새 기능을 도입할 수 있느냐가 아니라, 그 기능이 내놓는 수치와 결과를 어느 조건에서 신뢰하고 언제 사람에게 되돌릴지를 먼저 정한다는 데 있습니다.

처음 방문한 독자라면 아래 여섯 편을 순서대로 읽어 보세요. 평가 기준을 먼저 세우고, 그 기준을 만드는 관측 데이터가 누락되지 않는지 확인한 뒤, 인프라 계약과 에이전트 실행 경계로 넓혀 가는 동선입니다.

LLM 평가는 점수표가 아니라 배포 결정을 위한 Guardrail이 된다 : primary outcome, 안전 제약, 운영 guardrail을 섞지 않고 release gate로 만드는 기준을 잡습니다.
OpenTelemetry Metric Cardinality Limit과 데이터 완전성 : 총합이 남아 있어도 속성별 수치가 조용히 누락될 수 있는 overflow를 SLO·경보 관점에서 살핍니다.
Kubernetes Metrics API와 DRA 리소스 계약 : 관측·스케줄링 입력이 바뀔 때 API 버전, 리소스 소유권, fallback을 함께 검증하는 방법을 연결합니다.
OpenTelemetry Go Logs RC와 상관관계 계약 : 로그·trace·metric을 한 화면에 모으기 전에 어떤 correlation key와 누락 기준을 계약으로 둘지 확인합니다.
도구 선택과 데이터 이식성에 관한 9월 4일 개발 뉴스 : 코딩 에이전트의 도구 호출, 도메인·데이터 이식성, 신원확인의 문제를 통제권과 되돌림 관점으로 읽습니다.
AI의 실행 경계와 개발 기본값에 관한 9월 3일 개발 뉴스 : 로컬 LLM, 에이전트 거래, 로컬 검색을 도입할 때 읽기·쓰기 권한과 재검증 경계를 어떻게 나눌지 정리합니다.

이 흐름을 읽을 때는 다음 네 가지 질문을 붙이면 글 사이의 연결이 더 선명해집니다.

이 변경이 내리는 제품 또는 운영 결정은 무엇이며, 평균 점수와 별개로 절대 허용할 수 없는 실패는 무엇인가?
그 결정을 뒷받침하는 metric·log·trace가 속성별로도 완전한가? overflow·지연·누락 때 어떤 자동화가 멈춰야 하는가?
외부 API, 리소스, 데이터 저장소가 바뀔 때 owner·버전·fallback·rollback이 같은 변경 단위에 기록되는가?
에이전트가 읽기에서 쓰기 작업으로 넘어가는 순간에 서버 재검증, 최소 권한, idempotency, 사람 승인이 남는가?

조금 더 깊게 들어가고 싶다면 Synthetic Replay 기반 평가 Gate, OpenTelemetry 선언적 구성과 버전 계약, Agent Sandbox Egress Policy를 이어 읽어 보세요. 각각 재현 가능한 검증, telemetry 설정의 배포 안전성, 외부 호출 권한을 보강합니다.

따라서 이번 주의 추천 동선은 “더 많은 자동화”가 아니라 결정 기준 → 데이터 신뢰성 → 변경 계약 → 실행 권한을 차례로 확인하는 흐름입니다. 이 순서로 보면 AI 기능, 관측성, Kubernetes, 외부 플랫폼처럼 다른 주제도 결국 신뢰할 수 있는 입력과 되돌릴 수 있는 실행을 설계하는 문제로 만난다는 점을 확인할 수 있습니다.

이 아카이브를 가장 잘 쓰는 방법

1) 요즘 흐름을 빠르게 파악하고 싶을 때

최근 개발 트렌드 글부터 2, 3편 읽는 방식이 가장 빠릅니다. 단순히 새 기술 이름을 외우기보다,

왜 갑자기 팀들이 그 주제를 중요하게 보는지
비용, 품질, 운영 리스크가 어디서 바뀌는지
당장 체크해야 할 지표나 체크리스트가 무엇인지

를 같이 보는 데 초점을 맞추면 좋습니다.

바로 들어가기 좋은 글:

2) 개념을 체계적으로 다시 잡고 싶을 때

학습용 글은 용어 설명에서 끝나지 않고, 실제 시스템 설계나 장애 대응에 연결되는 예시를 같이 넣는 편입니다. 그래서 익숙한 주제라도 “왜 이 개념이 운영에서 중요해지는지”를 다시 정리할 때 읽기 좋습니다.

3) 프로젝트 맥락까지 보고 싶을 때

프로젝트 글은 결과만 나열하기보다, 중간에 부딪힌 문제와 설계가 바뀐 이유를 같이 남겨 두는 쪽을 선호합니다. 그래서 완성된 정답보다는 생각이 바뀌는 과정을 보고 싶은 분에게 더 잘 맞습니다.

대표 시리즈:

검색과 태그를 사용할 때 팁

특정 기술 이름이 분명하면 검색창으로 바로 찾는 편이 가장 빠릅니다.
주제가 넓다면 태그로 먼저 범위를 줄이고, 그다음 제목과 설명을 보는 편이 좋습니다.
비슷한 글이 여러 편일 때는 날짜보다 description과 key takeaway를 먼저 확인하면 중복 읽기를 줄일 수 있습니다.

QA/검증 글을 찾을 때

프로젝트 글에는 “QA"라는 단어가 제목과 본문에 자주 나오지만, 태그에서는 더 넓은 의미의 Quality Assurance로 묶어두는 편이 탐색에 유리합니다. QA는 버그를 찾는 단계만 뜻하지 않고, 릴리스 전에 어떤 실패 모드를 먼저 의심할지, 수정 뒤 어떤 회귀를 막을지, 운영자가 어떤 증거를 보고 배포를 승인할지까지 포함하기 때문입니다.

PGMUX 시리즈를 볼 때는 Quality Assurance 태그가 붙은 글을 단순 버그 수정 목록으로 읽기보다, 다음 질문을 들고 읽으면 더 얻는 게 많습니다.

정상 경로에서는 통과하지만 특정 조합에서 깨지는 조건은 무엇이었나?
테스트가 놓친 이유는 fixture 부족, 동시성 타이밍, 설정 reload, 프로토콜 경계 중 어디에 있었나?
수정이 다시 다른 경로를 깨뜨리지 않도록 어떤 체크를 추가했나?
릴리스 전에 사람이 봐야 하는 증거는 테스트 성공, race detector, 로그, 벤치마크, runbook 중 무엇인가?

이 관점으로 읽으면 QA 소견 6건과 운영 안전성 수정, QA 3차: 풀 안전성의 마지막 구멍들, QA 5차: 릴리즈 위생과 CI 안정성 같은 글이 단순 회고가 아니라 릴리스 게이트 설계 예시로 보입니다. 특히 AI 코드 리뷰나 자동 수정 도구를 붙이는 팀이라면, “찾았다"보다 “재발하지 않게 어떤 증거를 남겼나"를 중심으로 읽는 편이 좋습니다.