Posts

Addy Osmani의 2026년 5월 3일 글 **“Agent Skills”**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다. 원문: Agent Skills — Addy Osmani TL;DR 요약 문제 정의: 에이전트의 기본 보상 신호는 “task complete"라서, 검증 가능한 증거 없이도 완료를 선언하기 쉽다. 핵심 해법: “규칙 문서"가 아니라 “실행 워크플로우"를 SKILL.md로 주입해 단계별 체크포인트와 종료조건을 강제한다. 구조화된 SDLC: /spec → /plan → /build → /test → /review → /ship (+ /code-simplify)로 사람의 시니어 프로세스를 복원한다. 실무 원칙 5가지: process over prose, anti-rationalization table, verification non-negotiable, progressive disclosure, scope discipline. 실행 메시지: 에이전트 시대일수록 “diff에 안 보이는 시니어 업무"를 시스템에 박아 넣어야 사고를 줄일 수 있다. 1) Skill의 본질: “지식"이 아니라 “행동 절차” 글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다. ...

프롬프트를 입력하면 몇 백 밀리초 뒤에 토큰이 스트리밍으로 나오기 시작합니다. 겉보기엔 단순하지만, 내부에서는 서로 병목이 다른 두 추론 단계가 연속으로 실행됩니다. 이 글은 해당 구조를 1차 원리(First Principles) 관점으로 정리한 글입니다. TL;DR 핵심 정리 추론은 두 단계다: 첫 토큰 전까지의 Prefill(TTFT) 과 이후 스트리밍의 Decode(ITL) 는 병목이 다르다. 성능 지표도 분리해야 한다: 시작이 느린 문제는 프롬프트 길이/연산 최적화, 스트리밍이 느린 문제는 메모리 대역폭/KV 캐시 최적화가 핵심이다. KV 캐시는 속도의 핵심이자 비용의 근원: 재계산을 막아 속도를 올리지만, 긴 컨텍스트에서 VRAM을 크게 소모한다. 양자화는 고효율 레버: FP16/BF16, INT8, INT4로 갈수록 메모리 절감과 처리량 개선 효과가 크다. 원문: https://x.com/akshay_pachaar/article/2050941458614751327 ...

Dr. Milan Milanović의 뉴스레터 글 **“The 20 Software Engineering Laws”(2026-04-23)**는 소프트웨어 실패를 “예외"가 아니라 “반복 가능한 패턴"으로 보게 해주는 체크리스트입니다. 아래는 원문의 20개 법칙을 빠르게 의사결정에 쓸 수 있도록 압축한 정리입니다. 원문: The 20 Software Engineering Laws 20 Laws 핵심 정리 이 글의 본질: 법칙은 “무엇을 해야 하는가"보다 “이미 어떤 일이 벌어지고 있는가"를 설명하는 진단 프레임이다. 실무 고빈도 함정: 늦은 프로젝트에 인원 추가(Brooks), KPI를 목표화해 왜곡 유도(Goodhart), 낙관 일정 산정(Hofstadter)이 반복된다. 설계 원칙: 작게 시작해 점진 진화(Gall), 단순성 우선(KISS), 장애를 기본값으로 설계(Murphy·Postel·CAP). 팀 운영 원칙: 팀이 커질수록 개인 생산성 저하(Ringelmann), 소수 핵심 인력 집중(Price), 과잉 자신감 리스크(Dunning-Kruger) 관리가 필요하다. 결론: 20개 법칙은 아키텍처·조직·일정·품질·스케일링 의사결정에서 “미리 실패 비용을 줄이는 안전장치"로 써야 한다. 1) 시스템이 만들어지는 방식 Gall’s Law: 동작하는 복잡계는 항상 먼저 동작한 단순계에서 진화한다. KISS: 단순함을 유지하라. 불필요한 복잡성은 미래 장애 비용이다. Conway’s Law: 조직의 커뮤니케이션 구조가 시스템 구조를 복제한다. Hyrum’s Law: API의 관측 가능한 모든 동작은 결국 누군가의 의존성이 된다. CAP Theorem: 분산 시스템은 일관성·가용성·분할 허용성 중 2개만 강하게 보장 가능하다. Zawinski’s Law: 소프트웨어는 기능 팽창 경향을 가진다. 실무 해석: 리라이트/플랫폼 전환 시 “완벽 설계"보다 “작은 성공 루프"를 먼저 만든다. ...

Palantir가 공개한 “The Palantir Ontology"는 단순한 데이터 통합 전략이 아니라, 기업 운영을 의사결정 단위로 모델링해야 한다는 주장을 담고 있습니다. 이 글은 긴 원문을 실무 관점에서 빠르게 파악할 수 있도록 핵심만 압축한 정리입니다. TL;DR 핵심 정리 핵심 프레임: Ontology는 Data + Logic + Action + Security를 하나로 연결해, 분석 시스템이 아닌 운영 의사결정 시스템을 만든다. 중요한 포인트: 기업 데이터 자체보다, 누가/언제/어떤 맥락에서 어떤 결정을 내렸는지에 대한 의사결정 데이터와 계보 축적을 더 중시한다. 에이전트 활용 방식: LLM이 단순 조회(RAG)에 머무르지 않고, 기존 최적화 모델·시뮬레이터·업무 로직을 툴로 호출해 대안을 만들고 시나리오로 안전하게 검토한다. 실행과 통제: 액션(writeback)은 ERP/WMS/엣지 시스템까지 반영되지만, 권한·검증·감사 로그를 동일한 보안 체계로 강제해 자동화 리스크를 줄인다. 최종 메시지: 생성형 AI 도입 성패는 “모델 성능"보다 “의사결정 루프를 얼마나 안전하게 닫고 학습시키는 아키텍처를 갖췄는가"에 달려 있다는 주장이다. 원문: https://x.com/PalantirTech/status/2049136883528011954 ...

오늘(2026.4.30) 智谱(Zhipu / Z.ai)이 공개한 기술 블로그 **「Scaling Pain：超大规模 Coding Agent 推理实践」**는 GLM-5 시리즈가 초대규모 Coding Agent 호출 시나리오에서 겪은 추론 인프라 문제와, 이를 해결하기 위한 엔지니어링 최적화 결과를 처음으로 체계적으로 공개한 글입니다. 단순한 자랑이 아니라, 수요가 공급을 초과해 신규 구독을 제한해야 했던 몇 달의 누적 이슈에 대한 공식 답변에 가깝습니다. 원문: Scaling Pain — Z.ai Blog (2026-04-30) 핵심 도발 “Scaling up하니, 진짜 본 적 없는 아픔이 나왔다.” 이 정서가 글 전체의 톤입니다. 회피하지 않고 공개했다는 사실 자체가 이번 포스트의 위치를 결정합니다. ...

AI 애플리케이션 회사들이 점점 더 풀스택화되어 모델 레이어와 서비스 레이어로 진입하고 있는 가운데, 언제 자체 모델 학습에 뛰어들어야 하는가 라는 질문이 점점 무거워지고 있습니다. Tanay Jaipuria의 “To Train or Not to Train"은 이 결정을 둘러싼 트레이드오프를 짧고 명확하게 정리합니다. 원문: To Train or Not to Train — Tanay Jaipuria TL;DR 요약 풀스택화는 진행 중: 앱 레이어 회사들이 모델·서비스 레이어로 내려가고 있지만, 처음부터 사전학습 은 거의 항상 잘못된 선택이다. 현실적 경로: 강력한 오픈 웨이트 베이스 모델 위에서 post-training과 RL 을 얹는 방식이 디폴트가 되고 있다. 학습 트리거: 파이프라인의 특정 부분에서 작은 특화 모델이 프론티어 모델보다 의미 있게 더 잘하게 만들 만큼의 독점 데이터가 쌓였을 때, 그리고 회사가 빠르게 스케일링하며 데이터 트레이스를 모으거나 PMF 후 프론티어 모델로는 부족함을 느낄 때. 기회비용: post-training 인재는 희소·고비용. 같은 자원을 제품·유통의 다른 곳에 쓰는 것이 더 나은 경우가 많다. 가장 큰 리스크: 직접 학습한 모델이 다음 베이스 모델 릴리즈에 살아남지 못하는 것 — 프론티어 랩들의 릴리즈 사이클이 그 어느 때보다 빠르다. 2026년의 디폴트 답: 대부분의 초기 단계 앱 회사에게는 “아직은 아니다, 그러나 준비는 시작하라” — 데이터 수집을 지금 세팅하고, 비핵심 영역에서 작은 특화 모델 하나로 출발하라. 풀스택화의 큰 그림 AI 앱 회사들은 더 이상 단순히 프론티어 API를 얇게 감싸는 데 머물지 않습니다. 모델 레이어로 내려가 자체 학습을 하거나, 서비스 레이어로 올라가 도메인 전용 워크플로우를 통합하는 식으로 수직 통합 이 진행 중입니다. 이 글은 그중 모델 레이어 진입의 손익 에 초점을 맞춥니다. ...

Jordan Lord(소프트웨어 엔지니어, Footium 등 인디 프로젝트 창작자)이 자신의 블로그에 올린 글 “3 constraints before I build anything” 은 단순합니다. 제약이 없는 빌드는 실패한다. 그가 10년간 너무 복잡하거나 정체성이 없는 제품을 만들며 깨달은 것은, 시작 전에 강제로 통과시켜야 하는 3개의 게이트가 있다는 사실입니다. 원문: 3 constraints before I build anything — Jordan Lord TL;DR 요약 전제: 제약은 창의성을 막는 게 아니라 탐색 공간을 좁혀 혁신적 해법을 끌어낸다. 빌드 전에 3가지 게이트를 강제로 통과시켜야 한다. The One Pager: 아이디어는 한 페이지에 북극성으로 정리되어야 한다. 타협 불가·정밀·야심차되·간결. 한 페이지를 넘기면 너무 복잡한 것이고, 만들지 말아야 한다. Core Technology: 제품을 떠받치되 제품 자체는 아닌 핵심 기술 한 조각. 방법론·스킬·도구·다른 제품 무엇이든. 제품은 피벗해도 핵심 기술은 누적되며, 긴 시간 지평에서 비선형적 이득을 만든다. Product Constraint: 제품의 전면에 드러나는 자기만의 제약. 사용자가 직접 보고 상호작용하는 가시적 제약이 곧 제품의 정체성이다. 회고: Jordan은 이 3가지가 없는 상태에서 10년간 만든 제품이 어디로도 가지 못했다고 인정한다. 출발점 — 왜 제약인가 Jordan의 주장은 인디 해커 커뮤니티의 통념과 정반대 방향에서 시작합니다. “무엇이든 빠르게 만들고 시장이 답하게 하라” 가 아니라, “만들기 전에 스스로를 좁혀라” 는 것입니다. ...

Maarten Grootendorst가 Exploring Language Models 뉴스레터에 공개한 A Visual Guide to Quantization은 LLM 양자화의 직관을 50여 장의 커스텀 비주얼로 풀어낸 글입니다. 이 글은 그 핵심을 한국어로 정리합니다 — 숫자 표현의 기초부터 FP32→INT4의 매핑 수학, GPTQ·GGUF의 작동 원리, 그리고 1-bit/1.58-bit BitNet까지. 원문: A Visual Guide to Quantization — Maarten Grootendorst TL;DR 요약 문제: 70B 모델을 FP32(full-precision)로 로딩하면 약 280GB. 비트 수가 많을수록 표현 범위(dynamic range)와 인접 값 간 거리(precision)가 동시에 커진다. 데이터 타입: FP32 → FP16(범위 좁음) → BF16(FP16과 같은 16비트지만 FP32 수준 범위, 딥러닝 표준) → INT8(1/4 비트, 정수 연산) → INT4까지. 매핑 방식: Symmetric(absmax) 은 0 중심 대칭, Asymmetric(zero-point) 는 zero-point z를 두고 비대칭 매핑. Outlier 처리에는 clipping이 필요하고, 범위 선택은 calibration(percentile/MSE/KL)으로 결정한다. PTQ vs QAT: PTQ는 학습 후 양자화(빠르고 단순), QAT는 학습 중 fake quant로 양자화 노이즈를 학습 → INT4 같은 저비트 영역에서 PTQ보다 우월. 4-bit 영역: GPTQ는 inverse-Hessian으로 weight 중요도를 가중해 양자화 오차를 분배(GPU). GGUF는 super/sub 블록의 이중 스케일 양자화로 CPU 오프로딩을 가능하게 한다(llama.cpp). 1-bit 시대: BitNet은 weights를 {-1, 1}로, BitNet b1.58은 {-1, 0, 1} ternary로. 0의 추가가 곱셈을 덧셈으로 환원하고 feature filtering을 가능하게 한다 — “13B BitNet b1.58은 3B FP16 LLM보다 효율적”. Part 1. LLM의 “문제점” LLM은 수십억 개 파라미터(주로 weights)와 추론 중 만들어지는 activations로 구성됩니다. 가능한 적은 비트로 값을 표현해야 메모리와 연산 비용을 줄일 수 있습니다. ...

Peter Szász가 “엔지니어링 매니저(EM) 역할에 에이전트를 적용하면 어떻게 될까?“라는 사고 실험을 통해 기회와 리스크를 동시에 드러내는 글입니다. 코드 완성에서 에이전틱 엔지니어링으로 넘어가는 흐름이 매니지먼트 영역까지 확장될 수 있는지 탐색합니다. 원문: Agentic Engineering Management TL;DR 요약 에이전트 정의: 사용자 프롬프트로부터 목표 달성까지 “도구 호출 → LLM 평가” 루프를 자율적으로 반복하는 시스템. EM 분해: Execution(실행), Team Dynamics(팀 다이내믹스), Personal Development(개인 성장) 3축. 위로 갈수록 사람과의 거리는 가깝고 리스크는 높아진다. 두 평가 축: ① Autonomy Fitness — 반복성·데이터 풍부도·모호성·가역성. ② Trust Gradient — 개인적일수록 신뢰 리스크 증가. 하네스 설계: confidence threshold, dry-run, blast radius limit, reversibility, audit trail로 자율성 강도 조절. 결론: 신뢰가 깨지면 매니지먼트는 무너진다. 그러나 하네스 설계가 없으면 EM은 “풀타임 에이전트 베이비시터"가 된다. 핵심 정의 Agent: 초기 프롬프트에서 시작해 목표가 충족될 때까지 도구 호출과 LLM 평가를 반복하는 루프. Engineering Management: 비즈니스 목표에 부합하는 결과(outcome)를 전달하도록 팀을 이끄는 일. EM의 일은 세 가지로 분해된다: ...

Tanay Sai의 글 입니다. 2023년 PDF 폴더에 대한 영업팀 질의 응대를 위해 2주간 짜낸 RAG 파이프라인 — 청킹·임베딩·벡터 스토어·리랭커 — 이, 오늘은 사용자가 100페이지짜리 PDF 20개를 1M 토큰 컨텍스트에 드롭하고 질문 한 번 던지는 것으로 대체되었다는 자기 고백에서 시작합니다. 원문: Today’s harness is Tomorrow’s Prompt — Tanay Sai TL;DR 요약 하네스의 정의: 모델이 혼자서는 잘 못하는 일을 하게 만드는 스캐폴딩. 단순한 래퍼 이상으로, 모델이 할 수 있는 일을 측정 가능하게 끌어올리는 구조물. 모든 하네스 = 모델 한계의 우회로. 벡터 스토어는 컨텍스트가 작아서, 파서는 출력이 약간 틀려서, 에이전트 프레임워크는 모델이 계획을 못 해서 존재한다. 이미 먹힌 3가지: PDF 채팅(RAG 파이프라인), 구조화 출력(JSON 베깅 + 정규식), 이미지 읽기(Tesseract OCR + LLM 추측). 곧 먹힐 후보 3가지: 멀티 에이전트 스웜(AutoGen/CrewAI), 브라우저 스크립팅(Playwright + DOM 스냅샷), 캐스케이딩 음성 파이프라인(Whisper → LLM → ElevenLabs). 빌더의 진짜 질문: “내 하네스가 얼마나 영리한가"가 아니라 “How long until the model eats it?”. 결론: 짓지 말라는 게 아니다. 버릴 수 있을 만큼 싸게 지어라(build them cheap enough to throw away). 시작은 자기 고백 — 2주짜리 RAG가 컨텍스트에 먹힌 이야기 In 2023, I spent two weeks wiring up a RAG pipeline so a sales team could ask questions about a folder of PDFs. Chunking, embeddings, a vector store, a reranker. Today, a user drops twenty 100-page PDFs into a 1M-token context window and the model handles it. ...