# Haxlys's Blog AI, software engineering, agent infrastructure, and investment notes from Haxlys. ## Posts ### 생성형 UI의 세 가지 길 — 통제형·선언형·개방형 인터페이스 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/generative-ui-three-approaches/ - Section: posts - Date: 2026-08-12 - Description: boda.sh의 Generative UI 글을 바탕으로, AI가 의도에 맞춰 인터페이스를 생성하는 세 가지 방식과 실제 제품에서 이를 조합하는 방법을 정리한다. - Tags: AI, GenUI, 생성형 UI, A2UI, AG-UI, MCP, 인터페이스 - Frameworks: Progressive Adoption, Specification-driven Design, Defense in Depth - Mental Models: Controlled Flexibility, Intent-based Interface, Separation of Concerns boda.sh의 Generative UI 글은 AI가 인터페이스를 만든다는 말을 세부적인 설계 선택으로 풀어낸다. 단순히 HTML을 생성하는 기술을 소개하는 데 그치지 않고, 사용자의 의도에 맞춰 화면을 얼마나 자유롭게 바꿀 것인지, 그 자유를 어떤 규칙과 안전장치로 제한할 것인지 설명한다. 원문: Generative UI GenUI 핵심 정리 문제의식: AI 응답의 긴 텍스트 벽을 목적에 맞는 카드, 지도, 플래시카드 같은 일시적 UI로 바꾼다. 세 가지 방식: 기존 컴포넌트를 연결하는 Static/Controlled, 허용된 컴포넌트와 레이아웃을 조합하는 Declarative, raw UI 코드를 생성하는 Open-ended로 나눈다. 안전한 경계: 선언형 방식에서는 컴포넌트 카탈로그와 스키마가 AI가 실행할 수 있는 범위를 결정한다. 개방형 방식은 샌드박스가 필요하다. 프로토콜의 역할 분리: AG-UI는 에이전트와 클라이언트 사이의 이벤트를 전달하고, A2UI는 화면을 구성하는 … --- ### 마찰은 기능이다 — AI가 낮춘 제작 비용과 판단의 공백 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/friction-is-a-feature-ai-judgment/ - Section: posts - Date: 2026-08-12 - Description: Emil Kowalski의 글을 바탕으로, AI가 제작 비용을 낮추면서 사라진 판단의 문턱을 어떻게 다시 설계해야 하는지 살펴본다. - Tags: AI, 제품 설계, 소프트웨어, 판단, 검증, Vibe Coding - Frameworks: Friction as Filter, Build vs. Validate, Human Judgment - Mental Models: Opportunity Cost, Validation, Threshold Effects Emil Kowalski의 글 Friction as a Feature는 제품이 줄이려 하는 **마찰(friction)**을 다른 각도에서 바라본다. 마찰은 느리고, 비효율적이며, 번거롭다. 그래서 제품은 오랫동안 마찰을 제거하는 방향으로 발전해 왔다. 하지만 제작 과정의 마찰에는 우리가 놓치기 쉬운 두 번째 역할이 있었다. 무엇을 만들기 전에 한 번 더 생각하게 만드는 문턱이었다. 이 글은 AI를 쓰지 말자거나 과거의 느린 제작 과정을 되살리자는 주장이 아니다. AI가 낮춘 제작 비용을 그대로 누리되, 그 비용이 우연히 담당했던 판단 기능을 제품과 팀의 과정 안에 다시 설계해야 한다는 제안이다. --- ### Coinbase가 AI 시대에 엔지니어 면접을 다시 설계한 방식 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/coinbase-ai-era-engineering-interviews/ - Section: posts - Date: 2026-08-12 - Description: Coinbase가 AI 생성 코드의 확산에 맞춰 엔지니어 면접을 어떻게 재설계했는지, 세 단계의 실험과 세 가지 평가 신호를 중심으로 살펴본다. - Tags: AI, 엔지니어링, 채용, 기술면접, 코딩에이전트 - Frameworks: Evidence-based iteration, Human-in-the-loop - Mental Models: Signal over Ritual, Feedback Loops Coinbase는 AI가 코드를 작성하는 환경에 맞춰 엔지니어 채용 면접을 1년 동안 다시 설계했다. 핵심 변화는 코드를 제한 시간 안에 직접 쓰는 능력에서 벗어나, AI를 어떻게 지시하고 결과를 검증하며 잘못된 판단을 교정하는지를 평가하는 방향으로 이동한 데 있다. 원문: Interviewing Engineers in the AI Era: Lessons from a Year of Rebuilding (Coinbase, 2026-07-13) TL;DR 핵심 정리 Coinbase의 AI 생성 코드 비중은 2025년 1분기 5.7%에서 4분기 50%를 넘었고, 현재는 인간 검토를 전제로 거의 100%까지 늘었다. 기존의 URL 단축기·메시지 큐 설계 같은 문제는 AI가 1분 안에 그럴듯한 답을 만들 수 있어, 암기력보다 판단력을 측정해야 하는 상황이 됐다. 면접은 프론트엔드 파일럿, 백엔드 저장소 기반 과제, 2026년 3월 전사 AI 역량 평가의 세 단계로 바뀌었다. 평가 기준은 AI … --- ### AI가 무엇이든 만들 수 있을 때, 남는 것은 취향이다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/taste-is-all-thats-left/ - Section: posts - Date: 2026-08-08 - Description: NotAShelf의 글을 바탕으로, AI가 제작 비용을 낮출수록 구현보다 선택·검증·삭제의 판단이 중요해지고 그 판단 감각은 마찰과 실패에서 형성된다는 주장을 살펴본다. - Tags: AI, 소프트웨어, 엔지니어링, 판단, 취향 - Frameworks: Taste as Judgment, Friction as Curriculum, Curation over Production - Mental Models: Bottleneck Shift, Signal-to-Noise, Opportunity Cost NotAShelf의 Taste Is All That’s Left는 AI가 무엇이든 빠르게 만들어 주는 시대에 소프트웨어 제작자의 가치가 어디로 이동하는지 묻는다. 원문의 답은 취향(taste)이다. 여기서 말하는 취향은 색상이나 문체에 대한 개인적 선호가 아니라, 여러 개의 그럴듯한 결과 중 무엇이 맞고 무엇이 부족한지 알아보는 판단 감각이다. Taste 핵심 정리 병목의 이동: AI는 아이디어를 작동하는 결과물로 바꾸는 비용을 크게 낮추지만, 무엇을 만들 가치가 있는지는 대신 결정하지 않는다. 노력이라는 필터의 제거: 예전에는 제작 비용이 낮은 품질의 결과물이 시장에 쏟아지는 것을 자연스럽게 억제했다. 이제 그 필터가 약해져 선택과 큐레이션이 중요해졌다. 취향의 형성: 취향은 좋은 결과물을 소비한다고 생기지 않는다. 직접 만든 나쁜 결과물을 오래 겪고 실패를 반복하면서 쌓인다. 보이지 않는 비용: 취향은 “다시 하자”라고 말하게 하지만, 그로 인해 막은 사고나 거절한 평 … --- ### AI 조언은 왜 사람을 더 확신에 찬 오답으로 이끄는가 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-advice-cognitive-surrender/ - Section: posts - Date: 2026-07-24 - Description: AI의 조언이 사람의 판단을 돕기보다 무지를 인정하는 습관을 억누를 수 있다는 최신 연구와 실무적 대응 원칙을 정리한다. - Tags: AI, 비판적 사고, 인지 편향, AI 리터러시, 연구 - Frameworks: 비판적 사고, 인간-도구 상호작용 - Mental Models: 인지적 항복, 자동화 편향, 불확실성 인식 AI에게 답을 물으면 판단이 더 정확해질 것이라고 생각하기 쉽다. 그러나 최근 연구는 AI가 틀린 답을 제시하는 상황에서, 사람의 정확도뿐 아니라 자신이 모른다는 사실을 알아차리는 능력까지 약화될 수 있다고 지적한다. 원문: AI advice made people three times less accurate but twice as confident TL;DR 요약 핵심 결과: AI를 사용할 수 있을 때 ‘모르겠다’고 답한 비율은 44%에서 3%로 감소했다. 정확도와 확신의 역전: 정답률은 27%에서 9%로 떨어졌지만, 답에 대한 확신은 30%에서 76%로 높아졌다. 실험 설계: 연구진은 AI가 자주 틀리는 영화 속 유니폼 색상 같은 시각적 세부사항을 질문했다. 실무 원칙: AI의 답을 먼저 보지 말고 자신의 판단을 기록한 뒤, 근거와 불확실성을 대조해야 한다. 연구가 보여준 판단의 변화 연구진은 프랑스와 이탈리아의 세 대학 소속 연구자들로, Valerio … --- ### 클라우드 소프트웨어 팩토리 — 코딩 에이전트를 ROI가 보이는 개발 시스템으로 바꾸는 법 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/cloud-software-factory/ - Section: posts - Date: 2026-07-15 - Description: Zach Lloyd가 제안하는 클라우드 소프트웨어 팩토리의 개념과 구조를 정리한다. 이슈 분류부터 배포·모니터링까지 에이전트와 사람이 협력하는 개발 자동화 루프, 핵심 인프라, ROI 측정법, 벤더 선택 기준을 살펴본다. - Tags: AI, 에이전트, 소프트웨어 팩토리, 하네스, SDLC, 클라우드, Warp - Frameworks: Systems Thinking, Feedback Loop, Factory Automation - Mental Models: Human Variability, Control Room, Build vs. Buy Warp 창업자이자 전 Google Docs 수석 엔지니어인 Zach Lloyd는 글 The guide to software factories에서 소프트웨어 개발의 다음 변화를 설명한다. 개발자가 터미널에서 코딩 에이전트를 직접 조종하는 방식에서, 이슈 분류부터 배포와 모니터링까지를 클라우드에서 자동으로 흘려보내는 클라우드 소프트웨어 팩토리로 이동한다는 주장이다. Factory 핵심 정리 핵심 변화: 대화형 에이전트를 개발자별 도구로 두는 대신, SDLC 전체를 하나의 자동화 루프로 연결한다. 자동화 범위: 원문에서 소개한 Warp 팀의 경험으로는 전체 PR의 약 20~30%를 자동화하고 있으며, 완전 자동화가 어려운 작업도 리뷰·검증·모니터링은 자동화할 수 있다. 세 계층: 클라우드 런타임·샌드박스, 오케스트레이션·통합·사람 개입, 측정·평가·메모리로 구성된다. 경영 관점: 토큰 사용량이 아니라 실제 출시된 제품과 비용의 비율로 에이전트의 사업 가치를 측정해야 한다. 도입 원칙: … --- ### AI 엔지니어링의 다음 단계 — AIEWF 2026이 보여준 5가지 변화 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-engineering-worlds-fair-2026-trends/ - Section: posts - Date: 2026-07-15 - Description: AI Engineer World’s Fair 2026에서 드러난 AI 엔지니어링의 다섯 가지 변화와, 에이전트를 실제 시스템에 적용하기 위해 필요한 하네스·루프·스킬의 역할을 정리한다. - Tags: AI, AI 엔지니어링, 에이전트, 하네스, 스킬 엔지니어링, 소프트웨어 개발 - Frameworks: Harness Engineering, Loop Engineering, Context Engineering, Skill Engineering - Mental Models: Human-in-the-loop, Control Loop, Software Factory Richard MacManus의 **「5 Trends That Defined AI Engineering at World’s Fair 2026」**은 AI Engineer World’s Fair 2026에서 반복해서 등장한 주제를 다룬다. 2023년의 관심사가 LLM이 자율적으로 행동할 수 있는지 증명하는 일이었다면, 이제는 에이전트를 신뢰할 수 있는 제품과 조직 시스템으로 운영하는 일이 중심이 되었다. 원문: 5 Trends That Defined AI Engineering at World’s Fair 2026 TL;DR 핵심 정리 관심사의 이동: 에이전트의 능력보다 에이전트를 둘러싼 하네스, 컨텍스트, 권한, 평가, 상태 관리가 중요해졌다. 루프 설계: 에이전트가 작업을 반복하는 내부 루프와 사람이 방향을 조정하고 결과를 평가하는 외부 루프를 분리해야 한다. 기업 도입: FDE와 소프트웨어 팩토리는 조직의 데이터·업무 흐름·승인 지점까지 함께 설계하는 역할로 확장된다. 개발자 인터 … --- ### AI 에이전트 스킬 컴파일하기 — 토큰 사용량 94% 줄이는 방법 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/compiling-an-ai-agent-skill/ - Section: posts - Date: 2026-07-15 - Description: 반복 실행되는 자연어 기반 에이전트 스킬에서 결정론적 작업을 코드로 옮기고, 의미 판단이 필요한 지점에만 LLM을 사용하는 방법을 정리한다. - Tags: AI, 에이전트, agent-skills, 하네스, 토큰 효율, LLM - Frameworks: Progressive Optimization, Compiler Thinking, Human-in-the-loop - Mental Models: Cost Amortization, Deterministic vs Semantic Work, 80/20 Vivek Haldar는 매일 자신의 과거 글을 다시 발굴해 LinkedIn 게시물 초안을 만드는 에이전트 스킬을 운영한다. 이 워크플로우는 원래 자연어 지시만으로 작성되어 있었다. 어떤 소스를 검색할지, 최근에 다룬 글인지 어떻게 확인할지, 어떤 글을 고를지, 최종 초안을 어떤 형태로 만들지 모두 스킬 문서에 적어 둔 방식이다. 원문: How I Cut an AI Agent’s Token Use by 94% — Vivek Haldar 핵심 핵심 정리 출발점: 자연어 스킬은 처음부터 완벽한 프로그램을 만들지 않고, 반복 실행하며 실제 워크플로우를 발견하게 한다. 컴파일 대상: 소스 조회, 콘텐츠 인벤토리 생성, 최근 게시물 확인, 필터링, 상태 관리는 일반 코드로 옮긴다. LLM이 맡을 일: 필터링된 후보 중 좋은 글을 고르고, LinkedIn 초안을 작성하는 의미 중심 작업만 남긴다. 측정 결과: 저자의 실행에서 토큰 사용량은 94%, 지연 시간은 87% 감소했고 출력 … --- ### Control the ideas, not the code — 코드를 보지 말고 아이디어를 통제하라 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/control-the-ideas-not-the-code-antirez/ - Section: posts - Date: 2026-07-15 - Description: antirez가 주장하는 AI 시대 프로그래밍의 핵심은 코드를 줄 단위로 읽는 것이 아니라, 설계·의도·품질을 통제하는 일로 이동한다는 점이다. - Tags: AI, LLM, antirez, Redis, 소프트웨어엔지니어링, 에이전트, 디자인 - Frameworks: Idea Control, Design over Implementation, Human-AI Division of Labor - Mental Models: Mythical Man-Month, Trade-off, Local vs Global Optimality antirez(Salvatore Sanfilippo)의 글 Control the ideas, not the code는 AI 시대에 프로그래머가 무엇을 통제해야 하는지를 다시 묻는다. 코드 그 자체가 아니라, 소프트웨어에 담긴 아이디어·설계·방향을 손에 쥐는 일이 중심이 된다는 주장이다. Ideas 핵심 정리 핵심 주장: 코드를 계속 보면 오히려 영향력이 줄어들 수 있다. 아이디어를 통제하면 줄 단위 코드 열람은 자주 비효율이 된다. LLM의 강약: 국소적으로 좋은 코드는 잘 쓰지만 큰 설계는 상대적으로 약하다. 함수·줄을 스캔하기보다 설계가 맞는지 묻는 편이 빠르다. 기회비용: 하루 8시간 중 코드 읽기에 쓰면, 방향 설정·아이디어·최적화·QA에 쓸 시간이 줄어든다. 실무 함의: 사람 손이 들어가는 제품에서는 코드 리뷰가 아직 필요할 수 있지만, 장기적으로는 설계 문서와 검증이 더 큰 자산이 된다. 왜 이 이야기를 계속하는가 antirez는 2024년 1월부터 AI 프로그래밍에 대해 … --- ### 우리에게 남은 일은 무엇인가 — ICML 2026 키노트에서 본 AI 시대 일자리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/what-will-be-left-for-us-to-work/ - Section: posts - Date: 2026-07-15 - Description: Arvind Narayanan의 ICML 2026 키노트를 바탕으로, AI as Normal Technology 프레임워크, 능력-신뢰성 격차, Decide-Execute-Deliver 구조, 그리고 평가로 이동하는 인간 역할 변화를 정리한다. - Tags: AI, 노동시장, 에이전트, 평가, Normal Technology, ICML, 일자리 - Frameworks: Diffusion of Innovations, Second-order thinking, Systems Thinking - Mental Models: Lump of Labor Fallacy, Jevons Paradox, Decide-Execute-Deliver Sandwich 프린스턴 대학의 Arvind Narayanan이 ICML 2026 키노트에서 던진 질문은 단순하다. AI 능력이 계속 올라갈 때, 우리에게 남은 일은 무엇인가? 그는 이 불안을 정면으로 다루며 AI as Normal Technology 프레임워크를 중심으로 세 가지 주장을 펼친다. 첫째, 재귀적 자기개선 같은 불연속성이 오기 전까지 이 프레임은 유효하다. 둘째, 랩에서 어떤 마일스톤을 달성해도 그것이 곧바로 전면 실업을 만들지 않는다. 셋째, 미래 직업은 지금과 근본적으로 달라지므로 대규모 적응이 필요하다. TL;DR 핵심 정리 AI as Normal Technology: AI는 산업혁명급 변환 기술이지만, 경제적 영향은 능력 → 제품 → 초기 채택 → 조직 적응의 네 단계를 거치며 적응은 수십 년이 걸린다. 능력-신뢰성 격차: 최근 24개월 프론티어 모델에서 accuracy는 크게 올랐으나 reliability는 5~10%p 수준만 개선되어, 완전 자동화보다 협업 에이전트가 당분간 … --- ### AI는 가장 인간적인 기술이 될 수 있다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/the-most-human-technology-ever-made/ - Section: posts - Date: 2026-07-14 - Description: Anish A가 AI를 시간 절약 도구가 아니라 만들기와 자기표현을 확장하는 기술로 해석한 논지를 정리한다. - Tags: AI, a16z, 생산성, 창작, 조직문화, 기술철학 - Frameworks: Making over consuming, Cost of making, Individuality at scale - Mental Models: Attention Economy, Effort Arbitrage, Tyranny of Consumption Anish A는 AI를 단순한 생산성 도구로 보지 않는다. 글에서 제시된 핵심은 분명하다. 대부분의 기술은 시간을 아끼도록 설계되었지만 AI는 사람들에게 **“하고 싶은 일을 더 오래, 더 많이, 더 멋지게 하기 위한 시간”**을 준다는 주장이다. 원문: The Most Human Technology Ever Made 핵심 포인트 핵심 정리 시간 논리의 전환: AI의 핵심 질문은 일량 축소가 아니라, 사람이 자기 주도적으로 무엇을 만들고 탐구할 수 있게 되는 시간의 증가다. 새로운 기술 분류: 언어, 인쇄술, 증기기관처럼 AI는 노동을 줄이면서도 인간표현의 폭을 넓힌 몇 안 되는 기술군에 넣을 수 있는 흐름으로 해석한다. 만드는 쪽으로 회귀: 소셜미디어가 소비 경쟁으로 몰리면 결과는 품질이 아닌 노이즈가 커지며, AI는 사용자가 직접 결과물을 만들어내는 쪽으로 기울게 만든다. 문턱 붕괴의 실증: 비개발자인 전기기사와 배관공의 사례는, AI가 전문성 문턱을 낮추고 적은 비용으로 실험· … --- ### 토큰 가격은 어디로 가는가 — Benedict Evans가 제시한 네 가지 질문 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ways-to-think-about-token-pricing/ - Section: posts - Date: 2026-07-11 - Description: Benedict Evans가 분석한 토큰 가격의 불확실성, 공급 부족과 인프라 투자, 프런티어 모델의 경쟁, 그리고 모델 기업이 실제 가치를 얼마나 가져갈 수 있는지에 대한 네 가지 질문을 정리한다. - Tags: AI, LLM, 토큰, 가격, 인프라, 시장분석, Benedict Evans - Frameworks: Supply and Demand, Value Capture, Top-Down Analysis - Mental Models: Commodity Infrastructure, S-Curve, Marginal Cost vs ROI 생성형 AI 시장에서 토큰 가격은 가장 쉽게 비교할 수 있는 숫자처럼 보인다. 하지만 Benedict Evans는 가격표만 보고 장기적인 산업 구조를 예측하기에는 아직 이르다고 말한다. 공급, 수요, 추론 효율, 데이터센터 투자, 모델 성능, 사용처의 투자수익률이 동시에 움직이고 있기 때문이다. 원문: Ways to think about token pricing — Benedict Evans (2026-07-09) 3줄 핵심 정리 현재 상태: 토큰 시장은 공급 부족 상태이며, 데이터센터 투자와 추론 효율 개선으로 향후 몇 년간 가격·수익 구조가 크게 바뀔 수 있다. 핵심 변수: 프런티어 성능이 얼마나 오래 앞서 나갈지, 모델 간 경쟁이 약해질지, 모델 기업이 제품의 가치를 직접 가져갈 수 있을지가 관건이다. 현재의 방향: 별도의 변화가 없다면 프런티어 모델은 저마진 범용 인프라에 가까워지고, 제품·데이터·업무 프로세스를 쌓는 기업이 더 많은 가치를 가져갈 가능성이 높다. 지금 확실히 … --- ### 데이터의 중요성 — AI 모델 경쟁의 진짜 해자는 어디에 있는가 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/data-moat-salience/ - Section: posts - Date: 2026-07-11 - Description: MBI Deep Dives의 The Salience of Data를 바탕으로, AI 기업의 장기 경쟁력이 컴퓨트보다 데이터 접근권과 사용자 데이터 플라이휠에서 갈릴 수 있다는 주장을 살펴본다. - Tags: AI, 데이터, LLM, 경쟁우위, Anthropic - Frameworks: Data Flywheel, Data Moat, Scaling Laws - Mental Models: Competitive Moat, Flywheel Effect, Commodity vs Scarcity MBI Deep Dives의 The Salience of Data는 AI 모델 회사의 지속 가능한 경쟁우위를 데이터에서 찾는다. 컴퓨트와 인재는 여전히 중요하지만, 시간이 지날수록 주요 연구소가 비슷한 수준의 자본·GPU·인재에 접근하게 된다면 결국 모델을 다르게 만드는 것은 어떤 데이터를 확보하고 학습하느냐라는 주장이다. Data 핵심 정리 핵심 주장: AI 기업의 장기 해자는 모델 구조보다 독점적 데이터 접근권에서 만들어질 가능성이 크다. 데이터 플라이휠: 사용자가 제품을 많이 사용할수록 실제 작업 데이터가 쌓이고, 그 데이터가 모델과 제품을 개선해 다시 사용자를 끌어오는 순환이 생긴다. 병목의 이동: 지금까지는 GPU가 부족한 컴퓨트 제한 국면이었다면, 앞으로는 공개 웹 바깥의 고품질 데이터가 부족한 데이터 제한 국면이 될 수 있다. 시장 신호: 외부 데이터 벤더에 대한 지출은 이미 연간 약 70억 달러이며, 2030년에는 10배 이상 커질 수 있다. 1. 비슷한 모델 사이에서 … --- ### Plan A 소개 - AI 시대를 위한 낙관적 통제 시나리오 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/introducing-plan-a/ - Section: posts - Date: 2026-07-11 - Description: Scott Alexander가 소개한 AI Futures Project의 Plan A를 바탕으로, 미·중 공동 통제, 검증 가능한 컴퓨트 거버넌스, 2035년 능력 상한과 2040년 이후의 발전 경로를 살펴본다. - Tags: AI, AI안전, AI정책, 국제협력, 장기미래 - Frameworks: Scenario Planning, International Coordination, Capability Governance - Mental Models: Race Dynamics, Mutual Assured Compute Destruction, Scenario Scrutiny Scott Alexander의 Introducing Plan A는 AI의 미래를 늦추느냐 가속하느냐의 단순한 선택지로 다루지 않는다. AI가 정말 빠르게 발전한다면, 사회가 어떤 미래를 목표로 삼을지 먼저 그려야 한다는 문제의식에서 출발한다. 글에서 소개하는 Plan A는 AI Futures Project가 만든 2040년까지의 긍정적 시나리오이자, 그 시나리오를 현실로 만들기 위한 국제 정책 제안이다. Plan A 핵심 정리 예측이 아닌 기준선: Plan A는 미래를 맞히겠다는 선언이 아니라, 정책 제안을 실제 연도별 사건으로 전개해 검증하는 시나리오다. 공동 통제: 미국과 중국이 AI 경쟁을 멈추고, 칩·데이터센터·연구 활동을 상호 투명하게 감시하는 체계를 만든다. 속도 조절: 2030~2035년에는 인간 최고 전문가 수준까지 발전하고, 2035년에 능력 상한을 둔 뒤 안전 연구를 진행한다. 번영의 배당: 안전하게 통제된 고성능 AI를 널리 활용해 시민 배당, 질병 치료, 극적인 … --- ### 소프트웨어 품질은 문제의 부재다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/notes-on-software-quality/ - Section: software - Date: 2026-07-09 - Description: Anthony Hobday가 말하는 소프트웨어 품질의 신호, 조직 규모의 한계, 품질을 지키는 구체적인 방법을 정리한다. - Tags: 소프트웨어품질, 제품품질, 인터페이스, 조직설계, 디자인 - Frameworks: Product Quality, Interface Design, Organizational Design - Mental Models: Diminishing Returns, Coordination Cost, Entropy Anthony Hobday의 글 Notes on software quality는 소프트웨어 품질을 낭만적인 장인정신이 아니라, 제품과 조직이 실제로 감당해야 하는 운영 문제로 다룬다. 핵심은 간단하다. 좋은 소프트웨어는 더 많은 기능을 가진 소프트웨어가 아니라, 사용자가 마주치는 문제를 더 적게 남기는 소프트웨어다. Quality 핵심 정리 핵심 주장: 품질은 “문제가 거의 없는 상태"에 가깝고, 완벽에 가까워질수록 필요한 노력은 급격히 커진다. 여섯 신호: 신뢰성, 속도, 명확성, 유효성, 효율성, 아름다움이 소프트웨어 품질을 판단하는 주요 축이다. 조직의 역할: 품질은 실무자의 선의만으로 만들어지지 않는다. 리더십이 품질을 원하고 허용해야 한다. 규모의 비용: 제품과 팀이 커질수록 관계와 조율이 폭증해 세계적 수준의 인터페이스 품질은 점점 어려워진다. 실천 방식: 별도 품질 팀, 버그 우선 정책, 정기적인 품질 개선일처럼 시간과 권한을 따로 확보해야 한다. 원 … --- ### AI 시대에 살아남는 사람들 - David Brooks가 말하는 정신적 노력의 격차 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/mental-effort-ai-age-david-brooks/ - Section: posts - Date: 2026-07-09 - Description: David Brooks의 The People Who Will Thrive in the AI Age를 바탕으로, AI가 업무와 학습을 편하게 만드는 동시에 정신적 노력의 격차를 키울 수 있다는 관점을 정리한다. - Tags: AI, David Brooks, The Atlantic, 인지, 학습, 생산성 - Frameworks: Human-AI Collaboration, Cognitive Effort, Education Reform - Mental Models: Desirable Difficulty, Cognitive Offloading, Self-Determination Theory David Brooks의 The Atlantic 글 The People Who Will Thrive in the AI Age는 AI 시대의 승자가 단순히 더 똑똑한 사람이 아니라, 정신적 노력을 어떻게 대하는가 로 갈릴 수 있다고 말한다. 원문은 2026년 6월 28일 게시됐고, 2026년 7월 6일에 수정됐다. AI 핵심 정리 일은 덜어지기보다 밀도가 높아진다: ActivTrak 분석에서 AI 도입자는 이메일·메시징·채팅 시간이 두 배 이상 늘었고, 비즈니스 소프트웨어 사용은 94% 증가했다. 핵심 변수는 의지다: Brooks는 지능이 풍부해질수록, 무엇을 원하고 어디까지 노력할지 결정하는 힘이 더 중요해진다고 본다. AI 사용자는 갈라진다: 낮은 노력으로 생산성만 얻는 사람, 위험을 알면서도 편의성에 빨려 들어가는 사람, AI를 자기 사고 확장의 도구로 쓰는 사람. 위험은 인지적 빈곤화다: AI가 너무 쉽게 답을 주면 기억, 비판적 사고, 동기, 호기심이 약해질 수 있다. 좋은 … --- ### 그래프 기반 에이전트 메모리: 공유 기억은 어떻게 안전해지는가 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/graph-based-agent-memory/ - Section: posts - Date: 2026-07-09 - Description: System Design Newsletter의 Graph based Agent Memory 글을 바탕으로, 여러 AI 에이전트가 하나의 기억을 안전하게 읽고 쓰려면 왜 그래프, 스키마, 브랜치, 커밋이 필요한지 정리한다. - Tags: AI, 에이전트, Agent-Memory, Graph, Omnigraph, RAG - Frameworks: Graph Memory, Typed Graph, Git-style Data Workflow - Mental Models: Shared State, Atomic Commit, Schema as Contract, Review before Merge AI 에이전트가 하나일 때는 기억 문제가 단순해 보입니다. 대화 내용이나 작업 노트를 어딘가에 저장하면 됩니다. 하지만 터미널의 코딩 에이전트, 브라우저 챗봇, 백그라운드 작업 에이전트가 같은 프로젝트를 동시에 다루기 시작하면 문제가 달라집니다. 각자 따로 기억하면 맥락이 끊기고, 하나의 저장소에 모두 쓰게 하면 잘못된 정보가 곧바로 모두의 입력이 됩니다. 원문: https://newsletter.systemdesign.one/p/graph-based-agent-memory 핵심 핵심 정리 문제: 공유 폴더는 텍스트 더미가 되고, 벡터 데이터베이스는 관계를 모르며, 둘 다 여러 에이전트의 동시 쓰기와 잘못된 쓰기를 안전하게 다루기 어렵다. 해법 방향: 기억을 문서 묶음이 아니라 타입이 있는 그래프로 만들면, 에이전트가 고객 -> 티켓 -> 담당자 -> 커밋처럼 연결된 사실을 따라갈 수 있다. 쓰기 안전성: Omnigraph는 S3 같은 객체 저장소 위에서 불변 버전과 … --- ### Apps After Agents: 에이전트 이후에도 앱이 남는 이유 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/apps-after-agents/ - Section: posts - Date: 2026-07-08 - Description: Kyle Mathews의 Apps After Agents를 바탕으로, 에이전트가 지식 노동을 자동화해도 앱이 사라지지 않는 이유를 기반층, 카메라/엔진 모드, 자동화 실패 패턴 관점에서 다룬다. - Tags: AI, 에이전트, 앱, 자동화, 소프트웨어, Substrate - Frameworks: Camera/Engine Mode, Automation Boundary, Substrate - Mental Models: Bainbridge Paradox, Frame Problem, Build vs Buy Kyle Mathews의 Apps After Agents는 “에이전트가 모든 앱을 대체할 것인가?“라는 질문에 반대편에서 답한다. 결론은 단순하다. 에이전트는 많은 일을 자동화하겠지만, 앱은 사라지지 않는다. 다만 앱의 의미가 바뀐다. TL;DR 핵심 정리 모델보다 기반층: 모델 성능은 빠르게 평준화된다. 오래 남는 자산은 테스트, 문서, 예외 기록, 의사결정 이력처럼 조직의 판단이 쌓이는 기반층이다. 엔진 영역과 카메라 영역: 에이전트는 검증이 싸고 반복 가능한 일에 강하다. 반대로 무엇을 봐야 하는지, 전제가 틀렸는지, 예외가 생겼는지 알아차리는 일은 계속 탐색이 필요하다. 자동화는 책임을 없애지 않는다: 자동화가 좋아질수록 사람은 감시 루프에서 빠지기 쉽다. 그래서 권한 제한, 체크리스트, 테스트, 승인 흐름 같은 안전장치가 더 중요해진다. 앱은 프롬프트보다 낫다: 사용자는 매번 질문을 잘 쓰고 싶어 하지 않는다. 좋은 앱은 사용자의 의도를 미리 구조화하고 … --- ### GenUI 디자인 — AI가 UI를 만들 때 디자이너가 설계해야 하는 것 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/designing-for-genui-ai-builds-ui/ - Section: posts - Date: 2026-07-08 - Description: gskinner의 GenUI 글을 바탕으로, AI가 런타임에 UI를 조립하는 시대에 디자이너의 일이 화면 설계에서 규칙, 컴포넌트, 가드레일 설계로 어떻게 이동하는지 정리했다. - Tags: AI, GenUI, Product Design, Flutter, Design System, gskinner - Frameworks: Design Systems, Human-AI Interaction, Runtime Composition - Mental Models: Inventory, Guardrails, Feedback Loop gskinner의 2026년 6월 16일 글 **“Designing for GenUI: What Changes When AI Builds the UI?”**는 AI가 화면을 런타임에 조립하는 시대에 제품 디자인이 어떻게 달라지는지 다룹니다. 핵심은 단순합니다. 디자이너가 더 이상 모든 화면을 직접 완성하는 사람이 아니라, AI가 화면을 만들 때 따라야 할 재료와 규칙을 설계하는 사람이 된다는 것입니다. 원문: Designing for GenUI: What Changes When AI Builds the UI? TL;DR 핵심 정리 화면에서 규칙으로 이동한다: GenUI에서는 모든 화면을 미리 설계하는 대신, AI가 어떤 상황에서 어떤 컴포넌트를 써야 하는지 정의한다. Hatcha가 사례다: gskinner는 Google 발표를 위해 Flutter 기반 이벤트 플래닝 앱 Hatcha를 만들며, 초대장과 대시보드가 맥락에 맞게 조립되는 경험을 실험했다. 디자인 시스 … --- ### Understanding Is the New Bottleneck - AI 시대의 병목은 이해다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/understanding-is-the-new-bottleneck-geoffrey-litt/ - Section: posts - Date: 2026-07-08 - Description: Geoffrey Litt의 Understanding Is the New Bottleneck을 바탕으로, AI가 구현 속도를 올릴수록 사람이 무엇을 이해해야 하는지와 그 이해가 왜 다음 병목이 되는지 정리한다. - Tags: AI, LLM, Geoffrey-Litt, 소프트웨어-개발, 이해 - Frameworks: Cognitive Bottleneck, Human-AI Collaboration, End-User Programming - Mental Models: Cognitive Debt, Feedback Loop, Tacit Knowledge Geoffrey Litt의 글 Understanding Is the New Bottleneck은 AI 코딩 시대의 병목이 어디로 이동하는지 묻는다. 예전에는 구현 속도가 문제였다. 이제는 AI가 초안을 빠르게 만들기 때문에, 사람이 그 결과를 이해하고 다음 판단으로 연결하는 능력이 더 큰 제약이 된다. Bottleneck 핵심 정리 병목 이동: AI는 작성 속도를 올리지만, 사람이 시스템을 이해하는 속도까지 자동으로 올리지는 않는다. 이해의 목적: 코드를 승인하기 위해서만 이해하는 것이 아니라, 다음 아이디어와 설계 판단에 참여하기 위해 이해해야 한다. 인지 부채: 읽지 않은 코드, 설명되지 않은 결정, 머릿속에 남지 않은 맥락은 나중에 더 큰 비용으로 돌아온다. 도구 방향: 좋은 AI 개발 환경은 사람을 생략하는 것이 아니라, 사람이 더 빠르게 파악하고 개입하도록 도와야 한다. 1) AI는 생산 병목을 없애지 않고 옮긴다 AI 코딩 도구가 잘하는 일은 분명하다. 함수 초안, UI … --- ### 자기개선을 위한 하네스 엔지니어링 - 모델을 둘러싼 시스템이 진짜 무대다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/harness-engineering-for-self-improvement/ - Section: posts - Date: 2026-07-08 - Description: Lilian Weng의 글을 바탕으로, AI 자기개선에서 모델 가중치뿐 아니라 도구, 메모리, 워크플로, 평가 루프를 묶는 하네스가 왜 중요한 최적화 대상인지 정리한다. - Tags: AI, 에이전트, 하네스, 자기개선, 컨텍스트 엔지니어링, Lilian Weng - Frameworks: Systems Thinking, Feedback Loop, Context Engineering - Mental Models: Recursive Self-Improvement, Search Space, Goodhart's Law Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다. Harness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다. 가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다. 중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다. 최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다. 현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, … --- ### AI 확장의 다음 병목은 데이터다 — A Stargate for Data 읽기 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/stargate-for-data/ - Section: posts - Date: 2026-07-08 - Description: Will DePue의 A Stargate for Data를 바탕으로, AI 발전의 병목이 컴퓨트에서 데이터 커버리지로 이동하고 있다는 주장을 정리한다. - Tags: AI, 데이터, 스케일링, LLM, Stargate - Frameworks: Scaling Laws, Data Moat, Strategic Asset - Mental Models: Bottleneck, One-time Subsidy, O-ring Theory Will DePue의 A Stargate for Data는 AI 산업의 관심이 컴퓨트에 치우쳐 있는 동안, 다음 병목은 데이터가 될 수 있다고 말한다. X에 올라온 원문 포스트는 이 문제의식을 짧게 던지고, LinkedIn 글은 그 배경을 길게 설명한다. Data 핵심 정리 핵심 주장: AI 발전은 모델 크기와 데이터 양을 함께 키우며 진행됐지만, 이제 공개 인터넷 데이터가 부족해지는 국면에 들어가고 있다. 전환점: 과거에는 GPU가 부족하고 인터넷 데이터는 충분했다. 앞으로는 컴퓨트가 커질수록, 각 산업의 비공개 지식과 실제 업무 데이터가 더 큰 병목이 된다. 시장 크기: DePue는 외부 데이터 벤더 지출이 이미 연간 약 70억 달러이며, 2030년에는 연간 1,000억 달러 이상으로 커질 수 있다고 본다. 경쟁 구도: 컴퓨트는 같은 칩과 비슷한 클러스터를 살 수 있지만, 데이터는 독점 계약·전문가 네트워크·품질 관리·도메인 커버리지로 차별화된다. 전략 질문: 컴퓨트를 위해 … --- ### 100x 에이전틱 엔지니어 — 병목은 모델에서 사람의 선호로 이동한다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/100x-agentic-engineer-fable-gpt56/ - Section: posts - Date: 2026-07-08 - Description: systematicls의 X Article을 바탕으로, 강한 코딩 에이전트 시대의 생산성 차이가 도구보다 선호·제약·검증 루프를 얼마나 잘 표현하는지에서 나온다는 주장을 정리했다. - Tags: AI, 에이전트, Fable, GPT, 소프트웨어엔지니어링, 하네스 - Frameworks: Preference Engineering, Agent Harness Engineering, Pareto Frontier - Mental Models: No Free Lunch, Trade-off Management, 80/20 Rule systematicls의 X Article “What The New 100x Agentic Engineer Looks Like In The Era Of Fable & GPT 5.6”은 에이전틱 코딩의 생산성 격차가 어디서 생기는지 다룬 글이다. 핵심은 단순하다. 모델이 강해질수록 차이는 “AI가 코드를 잘 쓰는가"보다 사람이 원하는 결과와 trade-off를 얼마나 정확히 표현하는가에서 난다. TL;DR 핵심 정리 평준화는 일어나지 않는다: 에이전트가 코드를 대신 써도, 에이전트 뒤의 사람이 가진 맥락·판단·선호에 따라 결과 품질은 크게 갈린다. 새 병목은 선호 표현이다: 강한 모델은 구현 후보를 많이 만들 수 있지만, 어떤 후보가 우리 상황의 Pareto frontier에 가까운지는 사람이 알려줘야 한다. 선언형과 명령형을 구분해야 한다: 목표만 중요한 일은 선언형으로 맡기고, 실패 비용이 큰 핵심 경로는 명령형 제약으로 좁혀야 한다 … --- ### Addy Osmani의 Agentic Autonomy Levels — AI 에이전트에게 어디까지 맡길 것인가 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-autonomy-levels-addy-osmani/ - Section: posts - Date: 2026-07-07 - Description: Addy Osmani의 Agentic Autonomy Levels는 AI 에이전트 활용을 0~5단계로 나누고, 더 높은 자율성보다 더 강한 검증·되돌리기·범위 통제가 먼저 필요하다고 말한다. - Tags: AI, 에이전트, Agentic-Autonomy, Addy-Osmani, Codex, Claude-Code, 검증 - Frameworks: Agentic Autonomy Levels, Calibrated Autonomy, Verification-first Delegation - Mental Models: Risk and Reversibility, Management by Exception, Orchestration Tax Addy Osmani의 2026년 7월 글 **“Agentic Autonomy Levels”**는 AI 코딩 에이전트에게 일을 맡길 때 필요한 기준을 다룹니다. 핵심은 단순합니다. 에이전트가 더 많이 할 수 있다는 사실과, 실제로 더 많이 맡겨도 된다는 판단은 별개입니다. 원문: X article / Substack 공개본 핵심 핵심 정리 두 축: 단일 에이전트가 얼마나 멀리 가는지(agency)와 여러 에이전트를 얼마나 잘 조율하는지(orchestration)를 분리해서 봐야 한다. 6단계: Assist, Supervised action, Scoped task delegation, Goal-driven autonomy, Parallel delegation, Managed-by-exception orchestration으로 올라간다. 판단 기준: 높은 자율성은 “믿어도 된다"가 아니라 “틀렸을 때 빨리 알고, 쉽게 되돌리고, 독립 … --- ### A Field Guide to Fable — 좋은 AI 결과는 모르는 것을 찾는 능력에서 나온다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/fable-finding-unknowns/ - Section: posts - Date: 2026-07-07 - Description: Thariq Shihipar의 'A Field Guide to Fable: Finding Your Unknowns'를 바탕으로, 강한 AI 모델을 잘 쓰는 핵심이 더 긴 지시문이 아니라 unknowns를 발견하고 줄이는 과정이라는 점을 정리했다. - Tags: AI, Claude, Fable, 에이전트, 프롬프트, 소프트웨어엔지니어링 - Frameworks: Known Unknowns, Blindspot pass, Iterative implementation - Mental Models: The map is not the territory, Assumption surfacing, Feedback loops 원문: A Field Guide to Fable: Finding Your Unknowns 참고: Know your unknowns — examples Fable 핵심 정리 핵심 주장: Fable급 모델에서는 “모델이 충분히 똑똑한가"보다 “내가 작업의 빈칸을 충분히 드러냈는가"가 결과를 좌우한다. 지도와 영토: prompt, skill, context는 지도이고 실제 코드베이스, 사용자 요구, 운영 제약은 영토다. 두 사이의 간격이 unknowns다. 네 가지 분류: known knowns, known unknowns, unknown knowns, unknown unknowns로 나누면 AI가 어디서 추측하게 되는지 보인다. 실무 방법: 구현 전에는 blindspot pass와 인터뷰, 구현 중에는 변경 기록, 구현 후에는 pitch나 quiz로 숨은 가정을 다시 꺼낸다. 1) 문제는 더 긴 prompt가 아니다 Thariq Shihipar의 … --- ### Some New Agentic Patterns - 에이전트가 동료 에이전트를 위해 도구를 고치는 방식 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/some-new-agentic-patterns/ - Section: posts - Date: 2026-07-07 - Description: Jesse Vincent의 글을 바탕으로, Prime Radiant가 구현 에이전트와 장기 실행 동료 에이전트를 직접 대화시켜 도구와 하네스를 개선한 방식을 정리한다. - Tags: AI, 에이전트, agentic-engineering, agent-harness, Slack - Frameworks: Agentic User in the Loop, Dogfooding, Compartmentalization - Mental Models: Feedback Loop, Least Privilege, Socio-technical Systems Jesse Vincent의 Some new agentic patterns는 에이전트를 더 잘 쓰는 프롬프트 팁이 아니다. 핵심은 에이전트를 위한 제품을 만들 때, 실제 사용자 역할의 에이전트가 구현 에이전트와 직접 대화하게 하는 개발 방식이다. 원문: Some new agentic patterns Agent Loop 핵심 정리 새 패턴: 사람이 중간에서 피드백을 전달하지 않고, Claude Code가 Slackline을 통해 Ada-sen에게 직접 테스트를 요청했다. 사용자 모델: Sen 2.0은 단순 비서가 아니라 자기 도구, 메모리, 작업공간, 자격 증명을 가진 장기 실행 동료 에이전트로 설계된다. 보안 전제: Lethal Trifecta를 완전히 없애는 대신, 외부 통신 권한과 자격 증명 접근을 임시 서브에이전트와 중재자 에이전트로 분리한다. 실무 포인트: 코딩 에이전트에 맞는 컨텍스트 압축은 여러 대화를 동시에 이어가는 페르소나형 에이전트에는 맞지 않을 수 있다. 결과: … --- ### AI 시대, 주니어 개발자 시장에 생긴 균열 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-junior-programmer-market-collapse/ - Section: posts - Date: 2026-07-07 - Description: AI가 주니어 개발자 채용 시장을 흔드는 동시에 소프트웨어 제작 능력을 더 넓은 직군으로 퍼뜨리고 있다는 Laurie Voss의 분석을 정리한다. - Tags: AI, 주니어개발자, 소프트웨어개발, 노동시장, 바이브코딩 - Frameworks: Second-order thinking, Labor Market Analysis - Mental Models: Abstraction Layer, Apprenticeship Model Laurie Voss는 AI가 프로그래밍이라는 직업을 없애고 있다기보다, 주니어 개발자가 성장하던 기존 경로를 먼저 무너뜨리고 있다고 본다. 동시에 소프트웨어를 만드는 능력은 마케터, 창업자, 교사, 분석가, PM 같은 더 넓은 직군으로 퍼지고 있다. 원문: AI has torched the market for junior programmers TL;DR 핵심 정리 주니어 시장의 충격이 가장 크다: Stanford Digital Economy Lab의 ADP 급여 데이터 기준 22~25세 개발자 고용은 2022년 말 고점 대비 19% 감소했다. 평균 지표는 착시를 만든다: 전체 소프트웨어 개발자 고용은 늘었지만, 주니어가 전체 개발자 중 작은 비중이라 평균만 보면 하락이 잘 보이지 않는다. 코드 작성 자체보다 판단의 가치가 커졌다: 명세대로 코드를 쓰는 역할은 줄고, 어떤 문제를 풀지 정하고 결과를 검증하는 역할은 상대적으로 강해지고 있다. 새로운 제작자는 이미 등장했다: … --- ### AI가 팀을 더 강하게 만드는지 측정하는 법 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/measure-ai-effectiveness-teams-ably/ - Section: posts - Date: 2026-07-02 - Description: Ably가 제안한 AI 효과 측정법을 바탕으로, 도구 사용량이 아니라 팀 역량 변화와 업무 방식 내재화를 보는 두 가지 KPI를 정리한다. - Tags: AI, 생산성, 팀운영, 조직문화, KPI - Frameworks: Evidence-Based Management, Capability Measurement - Mental Models: Goodhart's Law, Compounding, Leading Indicator AI 도구를 모두에게 열어주고, 사용량이 늘고, 슬랙에 성공 사례 채널이 생겼다고 해서 팀이 정말 더 강해졌다고 말할 수는 없다. Ably의 글은 이 착시를 정면으로 다룬다. 질문은 단순하다. AI가 우리 팀을 더 유능하게 만들고 있는가, 아니면 더 바쁘게 만들고 있는가? 원문: Is AI making your teams better, or just busier? TL;DR 핵심 정리 사용량은 쉬운 지표지만 약한 지표다: 매일 AI를 열어 같은 일을 조금 빨리 해도 높은 도입률로 보인다. 그러나 팀의 가능 업무 범위가 넓어졌는지는 알 수 없다. 두 가지 KPI가 핵심이다: AI로 새롭게 가능해진 결과가 있는지, AI가 일상 업무 방식 안에 얼마나 깊게 들어왔는지를 월별로 본다. 점수는 증거로만 오른다: 팀 리드가 1~5점으로 평가하되, “무엇을 했고 왜 더 나아졌는지” 사례가 없으면 점수 상승은 없다. 초기 2점은 실패가 아니다: Ably도 첫 평가에서 두 … --- ### AI가 줄여야 할 것은 인원수가 아니라 팀 크기다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-small-teams-not-headcount/ - Section: posts - Date: 2026-07-02 - Description: Miguel Carranza의 글을 바탕으로, AI 시대에 회사가 사람을 덜 뽑는 대신 더 작은 팀을 더 많이 만들어야 하는 이유를 정리한다. - Tags: AI, 조직설계, 엔지니어링매니지먼트, 스타트업, RevenueCat - Frameworks: Small Teams, Organizational Design, Strong Ownership - Mental Models: Coordination Cost, DRI, Span of Attention AI가 조직을 바꾼다는 말은 자주 인원 감축 이야기로 흘러갑니다. Miguel Carranza의 글은 방향을 다르게 잡습니다. 핵심은 사람을 덜 뽑자는 것이 아니라, 팀을 작게 쪼개 새로 합류한 사람이 더 많은 회의가 아니라 더 많은 병렬성을 만들게 하자는 주장입니다. 원문: AI shouldn’t shrink headcount. It should shrink teams Small Teams 핵심 정리 핵심 주장: AI의 조직 효과는 인원 감축보다 팀 크기 축소에 있다. 작은 팀은 결정권과 책임 소재가 뚜렷하다. 병목 이동: AI가 첫 구현과 낯선 코드 검토 비용을 낮추면, 중요한 일은 “코드를 누가 쓰는가"보다 “무엇을 만들고 언제 멈출지 판단하는가"가 된다. RevenueCat 사례: OCTO는 신뢰 높은 시니어 IC들이 새 베팅과 중요 프로젝트를 빠르게 검증하는 작은 조직 실험이었다. 제품팀 적용: 1~3명 엔지니어, 공유 … --- ### LinkedIn QA Agent - AI 자율 테스트가 바꾸는 품질 관리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/linkedin-qa-agent-autonomous-testing/ - Section: posts - Date: 2026-07-02 - Description: LinkedIn Engineering의 QA Agent 글을 바탕으로, VLM 기반 자율 테스트 에이전트가 전통적인 UI 테스트의 한계를 어떻게 넘는지 정리했다. - Tags: AI, QA, 자율테스트, 소프트웨어품질, LinkedIn, 에이전트 - Frameworks: Autonomous testing, Verification-first engineering, Human-in-the-loop - Mental Models: System 1 and System 2, Golden dataset, Precision over recall, Semantic memory LinkedIn Engineering이 2026년 6월 18일 공개한 **“Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing”**는 AI 에이전트가 실제 대규모 서비스의 품질 관리를 어떻게 바꿀 수 있는지 보여주는 사례입니다. 원문: Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing AI 핵심 정리 문제 배경: LinkedIn은 iOS, Android, Web, 36개 이상 언어, 사용자 유형, 멤버십, 실험 조합 때문에 전통적인 UI 자동화만으로 모든 변화를 따라가기 어렵다. 해결 방식: QA Agent는 selector에 의존하지 않고 VLM으로 화면을 읽으며, planner, analytical reasoning model, fine-tuned … --- ### It's Hard to Eval Is a Product Smell 핵심 정리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/eval-smell-product-design/ - Section: posts - Date: 2026-07-01 - Description: Hamel Husain의 2026-06-29 글을 바탕으로, AI 제품에서 평가 난이도가 제품 설계 문제로 이어지는 이유와 검증 가능한 산출물 설계 원칙을 정리한다. - Tags: AI, evals, product-design, 검증, Hamel Husain - Frameworks: Verification-first product design, Human-in-the-loop, Progressive disclosure - Mental Models: 검증 비용, 출처 추적, 인지 부하 Hamel Husain의 글 “It’s Hard to Eval” Is a Product Smell은 AI 제품에서 자주 나오는 말, “이 제품은 평가하기 어렵다"를 다르게 봅니다. 저자의 주장은 단순합니다. 평가가 어렵다면 평가 방식만의 문제가 아니라, 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호일 수 있습니다. TL;DR 핵심 정리 중심 주장: AI 산출물이 제품을 만든 사람에게도 확인하기 어렵다면, 사용자는 더 큰 비용을 들여 다시 검증해야 한다. 설계 방향: 최종 답만 보여주지 말고 출처, 가정, 중간 계산, 확인하지 못한 항목을 함께 보여줘야 한다. 반복 패턴: 데이터 분석, 수업 계획, 의료 보고서 모두 “완성본 생성"보다 “검증 가능한 작은 단위"가 중요하다. 실무 질문: 사용자는 무엇을 확인해야 하는가, 무엇과 비교할 수 있는가, 어떤 단위로 승인하거나 거절할 수 있는가 … --- ### Technological Involution - 기술 정체를 넘어 새 기술로 가는 조건 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/technological-involution/ - Section: posts - Date: 2026-07-01 - Description: Rohan Ganapavarapu의 Technological Involution을 바탕으로, 기술 정체와 창업 문화의 매너리즘을 넘어 다시 기술에 대한 확신을 회복하는 조건을 정리했다. - Tags: AI, 스타트업, 기술철학, 하드테크, 실리콘밸리 - Frameworks: Technological Stagnation, First Principles, Reality Contact, Bits vs Atoms - Mental Models: Involution, Conviction, Commoditization, Contact with Reality Rohan Ganapavarapu의 Technological Involution은 기술 정체론, AI, 스타트업 문화, 하드테크를 한데 묶어 묻는다. 우리는 정말 더 이상 만들 것이 없는 시대에 도착했는가, 아니면 기술을 상상하고 믿는 방식이 먼저 낡아버린 것인가. Tech 핵심 정리 정체의 핵심: 문제는 가능성의 고갈보다 상상력의 수축이다. 우주, 원자력, 시간여행을 꿈꾸던 문화가 이제는 더 많은 AI와 더 많은 소프트웨어만 반복한다. 창업 문화의 함정: 창업자는 자기 확신으로 움직인다고 믿지만, 실제로는 VC, 인플루언서, 액셀러레이터가 유통한 논제를 자기 생각처럼 받아들이기 쉽다. AI의 한계: AI는 소프트웨어 엔지니어링에는 강력하지만, 현실 조직을 바꾸는 일은 여전히 운영 이해, 책임, 도메인 감각을 요구한다. 기회의 위치: 쉬운 SaaS보다 칩, 하드웨어 공급망, 엔터프라이즈 운영, 현장 문제처럼 접촉 비용이 큰 곳에 더 오래가는 가치가 있다. 새 기술의 조건: 좋은 제품 … --- ### Code is the easy part - 청구 스크립트보다 도메인 모델이 먼저다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/code-is-the-easy-part-billing-entities/ - Section: posts - Date: 2026-06-30 - Description: Swizec Teller의 글을 바탕으로, 낡은 청구 스크립트 문제를 해결하려면 코드보다 먼저 비즈니스 개념과 데이터 모델을 다시 잡아야 한다는 교훈을 정리했다. - Tags: software-engineering, refactoring, billing, domain-model, startup - Frameworks: Domain Modeling, Incremental Refactoring, Socio-technical Systems - Mental Models: Data model first, Chesterton's Fence, Strangler Fig Pattern, Second-order Effects Swizec Teller의 Code is the easy part, or how we refactored half the business to fix a janky script는 낡은 청구 스크립트를 고친 이야기처럼 시작합니다. 하지만 핵심은 코드가 아닙니다. 회사가 커지면서 비즈니스 개념, 데이터 모델, 운영 습관, 고객 셀프서비스, 재무팀 도구까지 함께 바꿔야 했던 리팩터링 이야기입니다. 원문: Code is the easy part, or how we refactored half the business to fix a janky script Refactor 핵심 정리 표면 문제: 낡은 Python 스크립트가 모든 인보이스를 발행했고, 월말 청구는 종종 밤샘 작업이 됐다. 진짜 문제: 사용자, 기관, 랩, 구매 부서, 영업 구역, 데이터 공유 구조가 하나의 데이터 모델에 섞여 있었다. 핵심 해법: 협업 구조와 청구 구조를 분리하고, “이 주문을 어떻게 청구할까 … --- ### Software is becoming marketing - 소프트웨어 풍요 시대의 제품과 일자리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/software-is-becoming-marketing/ - Section: posts - Date: 2026-06-30 - Description: Tereza Tizkova의 Software is becoming marketing을 바탕으로, AI가 소프트웨어 제작 비용을 낮출 때 제품 시장과 개발자 커리어가 어떻게 바뀌는지 정리했다. - Tags: AI, 소프트웨어, SaaS, vibecoding, 제품전략 - Frameworks: Abundance economics, Power law, Jobs-to-be-done - Mental Models: Commoditization, Paradox of choice, Distribution moat, Outcome over tool Tereza Tizkova의 글 Software is becoming marketing은 AI가 코드를 대량 생산할 수 있게 된 뒤 소프트웨어 산업이 어디로 움직이는지 다룹니다. 핵심은 소프트웨어가 더 이상 희소한 산출물이 아니라, 마케팅처럼 누구나 만들고 누구나 평가하는 영역에 가까워진다는 주장입니다. AI 핵심 정리 진입 장벽 하락: 누구나 vibecoding으로 간단한 SaaS를 만들 수 있으면, 소프트웨어는 수학보다 마케팅에 가까운 평가 대상이 된다. 헌신 약화: 프로젝트 관리 도구가 3개일 때는 하나를 고르지만, 300개가 있고 직접 만들 수도 있으면 고객의 정착률은 낮아진다. 중간층 압박: 단순 기능을 월 $50에 파는 중간 규모 SaaS는 개인 제작 도구와 거대 플랫폼 사이에서 설 자리가 좁아진다. 서비스화: 기업은 회계 소프트웨어보다 장부 마감이라는 결과에 더 큰 돈을 쓴다. AI 시대의 큰 기회는 도구가 아니라 결과 판매다. 커리어 전략: 그저 괜찮은 개발자보다 기술 … --- ### AI-Native Divide — AI를 생활 인프라로 쓰는 사람과 아닌 사람의 격차 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-native-divide-daniel-miessler/ - Section: posts - Date: 2026-06-27 - Description: Daniel Miessler의 'The Coming Divide: AI-Native or Left Behind'를 바탕으로, AI 회의론과 별개로 개인의 학습·업무 역량 격차가 어떻게 커질 수 있는지 정리했다. - Tags: AI, Daniel Miessler, AI-native, 생산성, 학습 - Frameworks: AI-native literacy, Capability gap, Adoption curve - Mental Models: Compounding advantage, Opportunity cost, Tool leverage Daniel Miessler가 2026년 6월 25일에 쓴 “The Coming Divide: AI-Native or Left Behind” 는 AI에 대한 실망과 회의론이 커지는 시점에 던지는 경고입니다. 그는 AI 산업의 거품, 막대한 투자, 추론 비용의 불확실성을 부정하지 않습니다. 다만 그 우려가 “AI는 또 하나의 Crypto/NFT였으니 무시해도 된다"는 결론으로 굳어지는 순간, 개인의 역량 격차가 빠르게 벌어진다고 봅니다. 원문: The Coming Divide: AI-Native or Left Behind TL;DR 핵심 정리 핵심 주장: AI 거품을 비판하는 것과 AI 활용 능력을 포기하는 것은 다른 문제다. 전자는 건강한 경계지만, 후자는 앞으로의 기회 비용이 커질 수 있다. 격차의 본질: AI-native인 사람은 AI를 업무, 학습, 창작, 의사결정에 계속 엮고, 그렇지 않은 사람은 같은 일을 더 느리고 좁은 도구 세트로 … --- ### The annotated PyTorch training loop - PyTorch 학습 루프의 순서가 중요한 이유 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/annotated-pytorch-training-loop/ - Section: posts - Date: 2026-06-27 - Description: idlemachines의 The annotated PyTorch training loop를 바탕으로 PyTorch 학습 루프의 각 줄이 하는 일, 순서가 바뀌면 생기는 문제, 검증과 GPU 효율화 포인트를 한국어로 해설한다. - Tags: PyTorch, 딥러닝, 학습 루프, autograd, optimizer, GPU, 머신러닝 - Frameworks: Training Loop, Autograd, Gradient-Based Optimization - Mental Models: State Machine, Order Matters, Hidden State, Feedback Loop idlemachines의 The annotated PyTorch training loop는 PyTorch 학습 루프를 한 줄씩 해부하는 글입니다. 겉으로는 단순한 for 문처럼 보이지만, 실제로는 모델 상태, gradient buffer, autograd graph, optimizer state, scheduler state가 맞물려 돌아갑니다. 그래서 줄 하나가 조금만 엉뚱한 곳에 있어도 에러 없이 학습이 망가질 수 있습니다. 원문: The annotated PyTorch training loop PyTorch 핵심 정리 핵심 순서: model.train() -> zero_grad() -> forward -> loss -> backward() -> clipping -> optimizer.step() -> scheduler.step() -> model.eval() + no_grad()가 기본 골격이다. 가장 위험한 점: 잘못된 위치의 코드가 … --- ### The Founder’s Playbook: AI 네이티브 스타트업의 생애주기 재설계 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/the-founders-playbook-ai-native-startup/ - Section: posts - Date: 2026-06-19 - Description: Anthropic이 2026년 5월 공개한 The Founder’s Playbook을 바탕으로 AI를 인프라로 삼는 스타트업의 Idea부터 Scale까지 4단계와 창업자 역할 변화, 단계별 핵심 도전 과제, Claude 도구의 활용 전략을 다룬다. - Tags: AI, 스타트업, 에이전트, Claude, Agentic Coding, PMF, 창업 - Frameworks: Startup Lifecycle, Agent Orchestration, Evidence-Driven Building - Mental Models: Problem-Solution Fit, Product-Market Fit, Technical Debt Compounding, Data Flywheel The Founder’s Playbook: Building an AI-Native Startup은 Anthropic 팀이 2026년 5월에 발간한 문서로, AI를 기술과 조직 개발의 중심에 두는 스타트업의 새로운 생애주기를 정의한다. 기존 스타트업 성장 곡선이 validate → raise → hire → build의 반복이었다면, 이제 AI는 각 단계에서 요구되는 팀 규모와 자금 조달의 기대를 크게 낮춘다. 좋은 아이디어가 실행으로 이어지는 거리가 극적으로 짧아졌다. 원문: The Founder’s Playbook PDF TL;DR 핵심 정리 42%의 실패 원인: “아무도 원하지 않는 것을 만든다” — agentic coding으로 프로토타입 제작이 쉬워지면서 검증 없이 빌드하는 위험이 오히려 증가한다. Idea 단계 종료 기준: 문제-해결 적합성(PSF). 실제 인간 대화에서 얻은 정성적 증거로 “누가, 얼마나 자주, 얼마나 심각하게 이 문제를 겪 … --- ### The Dialogue Dividend — 혼자 생각보다 대화가 사고를 만드는 인지적 이유 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/the-dialogue-dividend/ - Section: posts - Date: 2026-06-19 - Description: The Signalist의 에세이 'The Dialogue Dividend'가 설명하는 대화의 구조적 이점, 인지 과학적 근거(Extended Mind, Argumentative Theory, ZPD), 그리고 원격·비동기·AI 환경이 비계획 대화를 어떻게 제거하는지와 그 위험 - Tags: 대화, 인지과학, 생산성, 조직문화, 의사결정, AI - Frameworks: Extended Mind, Argumentative Theory of Reasoning, Zone of Proximal Development - Mental Models: Cognitive Infrastructure, Social Feedback Loop, Unscheduled Interaction The Signalist의 에세이 “The Dialogue Dividend"는 깊은 사고가 문을 닫고 노이즈 캔슬링 헤드폰을 끼는 고립된 상태에서만 가능하다는 지배적인 모델에 도전합니다. 저자는 특정 동료와의 우연한 대화가 오랫동안 고민하던 문제를 순식간에 풀어주는 경험을 반복하면서, 답을 알려주지 않는 상대와의 교환 자체에서 혼자서는 만들어낼 수 없는 사고가 발생한다는 사실을 관찰했습니다. 원문: The Dialogue Dividend Dialogue Dividend 핵심 정리 정밀성 강제: 생각을 소리 내어 말하면 모호한 인상이 주어와 술어를 갖춘 평가 가능한 문장으로 변환되어 내부 독백보다 높은 정밀성을 요구한다 (Self-Explanation Effect). 실시간 교정 루프: 청자의 미간 찌푸림, 질문, “나도 본 적 있다"는 반응이 사고의 드리프트를 즉시 바로잡는다. 기계적 주의 신호만으로는 이 효과가 충분하지 않다 (Robot … --- ### AI 프로토타입 시대에도 여전히 엔지니어가 필요한 이유 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/yes-we-still-need-engineers/ - Section: posts - Date: 2026-06-17 - Description: AI 코딩 도구가 프로토타입 제작을 빠르게 만들었지만, 실제 제품화에는 백엔드, 테스트, 보안, 운영, 접근성, 확장성 등 엔지니어링 판단이 여전히 필요하다는 관점을 정리한다. - Tags: AI, 소프트웨어엔지니어링, 프로토타이핑, 코딩에이전트, 프로덕션 - Frameworks: Systems Thinking, Second-order thinking - Mental Models: Prototype vs Production, Automation Leverage Matt Sayar의 글 Yes, we still need engineers는 Claude Code 같은 AI 코딩 도구가 프로토타입 제작을 얼마나 빠르게 만들었는지 인정하면서도, 그 결과물이 곧바로 프로덕션 품질의 소프트웨어가 되는 것은 아니라고 말합니다. 핵심은 “AI가 코드를 빨리 만든다"와 “소프트웨어가 실제 사용자에게 안전하게 운영된다” 사이에는 여전히 넓은 엔지니어링 간극이 있다는 점입니다. 이 글은 원문의 주장을 바탕으로, AI 프로토타입과 프로덕션 엔지니어링의 차이를 한국어 독자를 위해 정리한 글입니다. 핵심 정리 프로토타입은 커뮤니케이션 도구다: AI로 만든 데모는 아이디어를 빠르게 보여주고 팀의 이해를 맞추는 데 강력하지만, 운영 가능한 제품과는 거리가 있다. 제품화에는 보이지 않는 작업이 많다: 백엔드 지원, 회귀 테스트, 기능 테스트, 보안 테스트, 성능 검증, 접근성, 권한 처리, 유지보수성 같은 요소가 필요하다. 운영 … --- ### Addy Osmani의 Agentic Code Review — 에이전트 시대의 병목은 작성이 아니라 검증이다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-code-review-addy-osmani/ - Section: posts - Date: 2026-06-17 - Description: Addy Osmani의 'Agentic Code Review'(2026-06-15)를 정리했다. 핵심은 AI가 코드 작성을 빠르게 만들수록 엔지니어링의 병목은 사람이 신뢰할 수 있는 검증 체계로 이동한다는 점이다. - Tags: AI, agentic-engineering, Addy Osmani, 코드리뷰, 검증, 소프트웨어엔지니어링 - Frameworks: Risk-based review, Human on the loop, Verification-first engineering - Mental Models: Blast radius, Borrowed confidence, Comprehension debt Addy Osmani의 2026년 6월 15일 글 **“Agentic Code Review”**는 AI 코딩 에이전트가 보편화된 뒤 코드 리뷰의 의미가 어떻게 바뀌었는지 다룹니다. 글의 핵심은 단순합니다. 코드 작성은 기계 속도로 빨라졌지만, 사람이 변경을 이해하고 신뢰하는 속도는 거의 그대로이기 때문에 병목은 리뷰와 검증으로 이동했다는 것입니다. 원문: Agentic Code Review — Addy Osmani TL;DR 핵심 정리 병목 이동: AI는 수천 줄의 코드를 빠르게 만들지만, 사람이 “이 변경을 믿어도 되는가"를 판단하는 속도는 그대로다. 데이터의 경고: Faros는 AI 채택이 높은 팀에서 code churn 861%, incidents-to-PR ratio 242.7%, median review duration 441.5%, zero-review merge 31.3% 증가를 보고했다. 상황별 리뷰: 솔로 프로토타입과 결제·인 … --- ### AI가 소프트웨어 엔지니어를 대체하지 못한 이유, 그리고 앞으로도 대체하지 못할 이유 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/why-ai-hasnt-replaced-software-engineers/ - Section: posts - Date: 2026-06-13 - Description: AI가 코딩 능력에서 가장 빠르게 진보했음에도 소프트웨어 엔지니어를 대체하지 못한 구조적 이유를 Decide-Execute-Deliver Sandwich 모델을 중심으로 분석한다. - Tags: AI, 코딩에이전트, 소프트웨어엔지니어링, 자동화, 노동시장, AI워싱 - Frameworks: Systems Thinking, Second-order thinking - Mental Models: Decide-Execute-Deliver Sandwich, Pareto Principle AI가 소프트웨어 엔지니어를 대체할 것이라는 전망이 끊임없이 제기되지만, 실제 데이터는 정반대의 그림을 보여주고 있습니다. AI 적용이 가장 빠르고 앞선 분야인 소프트웨어 엔지니어링에서조차 대규모 해고나 노동력 감소는 일어나지 않았으며, 그 이유는 단순히 AI의 능력 부족이 아니라 소프트웨어 개발이라는 작업의 근본적인 구조 에 있습니다. TL;DR 요약 AI 해고는 대부분 AI 워싱 : Block, Snap, Intuit 등 유명 기업의 해고 사례 분석 결과 실제 원인은 재정 압박과 구조조정이었으며, 뉴욕주 WARN Act에서 AI 관련 체크박스를 사용한 사례는 0.2%에 불과하다. Decide-Execute-Deliver Sandwich : AI는 중간의 Execute(코딩)만 압축했을 뿐, 양 끝의 Decide(무엇을 만들지 결정)와 Deliver(테스트·검증·배포·책임)는 여전히 인간의 깊은 맥락 이해가 필요하다. 코딩은 전체 업무의 일부에 불과하다 : 개발자들이 실제로 코딩에 … --- ### AI Is Slowing Down — Ed Zitron이 진단하는 AI 거품의 현실 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-is-slowing-down-summary/ - Section: posts - Date: 2026-06-11 - Description: Ed Zitron이 2026년 6월 8일 발표한 'AI Is Slowing Down'의 핵심 주장을 정리했다. AI 산업의 과도한 투자 대비 성장 둔화, token-based billing의 문제, 순환 경제 구조의 지속 불가능성을 다룬다. - Tags: AI, 거품, Ed Zitron, 경제, 투자 - Frameworks: 순환 경제 분석, 투자 수익률 분석, 거품 진단 - Mental Models: 자연 독점, 진입 장벽, 신호와 노이즈 Ed Zitron이 2026년 6월 8일 발표한 “AI Is Slowing Down” 은 AI 산업(특히 OpenAI와 Anthropic 중심)을 강하게 비판하는 장문의 분석입니다. 핵심 주장은 AI가 과도한 투자와 약속에 비해 성장 속도가 둔화되고 있으며, 이는 거품 붕괴의 신호 라는 것입니다. 원문: AI Is Slowing Down 3줄 핵심 정리 핵심 주장: AI 산업이 수조 달러 투자를 정당화하려면 2030년까지 연간 최소 $2~3T 매출이 필요하지만, 현재 수요는 OpenAI + Anthropic 두 회사에 집중되어 있고 그마저도 적자다. 지출 둔화 증거: Uber, T-Mobile, Brex 등이 token-based billing의 예측 불가능한 비용에 대응해 AI token 지출 상한(cap)을 도입했으며, CFO들은 ROI 측정이 거의 불가능하다고 보고한다. 순환 경제의 붕괴 위험: AI labs → hyperscalers → NVIDIA로 이 … --- ### Modern Engineering Values — AI 시대, 코딩이 병목이 아닐 때 엔지니어에게 남은 것 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/modern-engineering-values/ - Section: posts - Date: 2026-06-10 - Description: Christoph Nakazawa가 AI 코딩 에이전트 시대에 엔지니어링의 핵심 가치가 어떻게 변화하는지 실제 경험을 바탕으로 정리한 Modern Engineering Values의 핵심 내용 - Tags: AI, 에이전트, 엔지니어링, Codex, 개발철학 - Frameworks: First Principles - Mental Models: Strong Ownership, Option Value Christoph Nakazawa(React/Vite/Jest 핵심 기여자)가 2026년 6월, AI 코딩 에이전트(특히 Codex CLI + GPT 5.5)로 여러 프로젝트를 거의 100% AI로 개발/개선한 경험을 바탕으로 엔지니어링의 핵심 가치가 어떻게 변화해야 하는지 정리한 글입니다. 원문: Modern Engineering Values TL;DR 요약 강한 소유권(Strong Ownership) : 도메인을 깊이 아는 2~3명 팀이 독립된 저장소에서 일할 때 AI의 증폭 효과가 극대화된다. 코드 리뷰는 스타일 논쟁이 아닌 ‘정렬(alignment)’ 중심으로. 취향(Taste) : AI는 엄청난 양의 쓰레기 코드도 빠르게 생성한다. 중요한 것은 ‘무엇을 만들 가치가 있는지’ 판단하는 능력. 가드레일과 피드백 루프 : 린트·자동 테스트·빠른 검증 도구가 강력할수록 AI가 빠르고 정확하게 일한다. 변경된 파일 중심으로 동작해야 함. … --- ### Loop Engineering — 프롬프트 엔지니어링에서 시스템 설계로의 전환 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/loop-engineering/ - Section: posts - Date: 2026-06-10 - Description: Addy Osmani가 제시하는 Loop Engineering — AI 코딩 에이전트를 직접 프롬프트하는 대신, 에이전트를 프롬프트하고 관리하는 시스템(Loop)을 설계하는 접근법과 5가지 핵심 구성 요소. - Tags: AI, 에이전트, Loop-Engineering, 코딩, 자동화, 소프트웨어엔지니어링, Addy-Osmani - Frameworks: Loop Engineering, Agent Harness Engineering, Automation-First Design - Mental Models: 자기 증폭 루프, Maker-Checker 분리, 의도 누출 방지 Addy Osmani가 2026년 6월 8일 Substack을 통해 제시한 개념으로, AI 코딩 에이전트(Claude Code, Codex 등)를 직접 프롬프트 하는 대신 에이전트를 프롬프트하고 관리하는 시스템(Loop) 을 설계하는 접근법입니다. 원문: Loop Engineering TL;DR 요약 핵심 전환 : “에이전트를 프롬프트하지 말고, 에이전트를 프롬프트하는 Loop를 설계하라” — 프롬프트 엔지니어링에서 시스템 설계로의 전환. Loop의 정의 : AI가 스스로 작업 발견 → 처리 → 검증 → 다음 작업 결정하는 재귀적·자동화된 루프. 타이머 기반 실행, 하위 에이전트 생성, 자체 유지. 5+1 구성 요소 : Automations(스케줄 기반 작업 발견), Worktrees(병렬 작업 격리), Skills(프로젝트 지식 저장), Plugins(외부 도구 연결), Sub-agents(Maker-Checker 분리), Memory(디스크 기반 상태 관리 … --- ### 자동화된 의심 — AI 개발에서 신뢰를 회복하는 다중 에이전트 검증 프로세스 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/automated-doubt-development-process/ - Section: posts - Date: 2026-06-10 - Description: Alex Self의 Automated Doubt 프로세스 — 설계·구현·배포 전 단계에서 특화된 서브에이전트를 활용해 가정, 보안, 완전성을 철저히 검증하는 다중 에이전트 개발 워크플로. - Tags: AI, 에이전트, Claude, 개발프로세스, 검증, 품질, 소프트웨어엔지니어링 - Frameworks: Multi-Agent Verification, Pre/Post-Implementation Audit, Iterative Quality Negotiation - Mental Models: 자동화된 의심, 시차 검증, 품질 협상 Alex Self가 AI(특히 Claude)를 활용한 개발 과정에서 신뢰 부족 을 극복하기 위해 만든 ‘자동화된 의심(Automated Doubt)’ 프로세스를 소개합니다. 핵심은 다중 에이전트(multi-agent) 를 통해 설계·구현 단계에서 철저한 검증과 비판을 앞당기는 것입니다. 원문: My Automated Doubt Development Process TL;DR 요약 핵심 문제 : AI에 “너무 많이, 너무 빨리” 맡기다 신뢰를 잃음. 하나의 LLM으로는 놓치는 부분이 많다. 해결책 : 의심(doubt)을 자동화하고, 여러 관점(parallax)에서 반복 검증하는 다중 에이전트 프로세스. Phase 1 - Design : Pre-Implementation Architect, Assumption Excavator, Gap Analyzer 등으로 Spec 검증 (10~25개 findings). Phase 2 - Development … --- ### Senior에서 Staff로 성장하는 법 — AI 시대의 마인드셋 전환과 세 가지 차원 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/senior-to-staff-engineer-growth/ - Section: posts - Date: 2026-06-10 - Description: Jordan Cutler가 제시하는 Senior에서 Staff Engineer로 성장하는 핵심 마인드셋 — Surface Area 확장, 팀 간 영향력, 확장 가능한 시스템 구축의 세 가지 차원과 실전 사례. - Tags: 커리어, 성장, 시니어, 스태프, 소프트웨어엔지니어링, 리더십 - Frameworks: Multiplier Thinking, Systems Thinking, Second-order Thinking - Mental Models: 영향력 확장, 자기 증폭 시스템, 신뢰 자본 Jordan Cutler(Pinterest Staff Engineer)가 Senior에서 Staff Engineer로 성장하는 데 필요한 마인드셋 변화 와 실전 사례를 정리한 글입니다. Staff Engineer는 단순히 더 깊은 기술력이나 빠른 실행력이 아니라, 다른 차원의 영향력 을 발휘하는 역할이라는 점을 강조합니다. 원문: How to Grow From Senior to Staff Engineer in the AI Era TL;DR 요약 핵심 전환: Senior → Staff는 “내가 더 많은 코드를 쓰는 것"에서 “다른 사람들이 더 많은 일을 할 수 있게 만드는 것"으로의 전환이다. Surface Area 확장: 주어진 업무 외에 자발적으로 기회를 만들고 가치를 먼저 증명하면 조직적 영향력이 따라온다. 팀 간 영향력: 문제만 지적하지 말고, 데이터 + 구체적 해결책 + 도움 제안을 함께 전달해야 신뢰와 실행을 이끌어낸다. 확장 가능한 … --- ### Backpressure is all you need — 코딩 에이전트 위임의 병목을 사람에서 시스템으로 옮기기 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/backpressure-is-all-you-need-summary/ - Section: posts - Date: 2026-06-02 - Description: Lucas F. Costa의 'Backpressure is all you need'를 코딩 에이전트 운영 관점에서 요약한다. 핵심은 사람이 매번 LLM 출력물을 붙잡고 교정하는 대신, 테스트·타입·벤치마크·리뷰 에이전트·PR 모니터링 같은 자동화된 백프레셔를 에이전트 루프 안에 넣어 더 긴 위임을 안전하게 만드는 것이다. - Tags: AI, 에이전트, 백프레셔, 코딩 에이전트, 테스트, CI, 리뷰 에이전트, 소프트웨어 엔지니어링 - Frameworks: Backpressure, Agentic Feedback Loops, Human-in-the-loop Delegation - Mental Models: Move the Bottleneck, Shift-left Quality, Fast Feedback Loops, Guardrails over Handholding Lucas F. Costa의 **“Backpressure is all you need”(2026-05-23)**는 코딩 에이전트를 더 오래, 더 안전하게 위임하기 위한 운영 원칙을 설명합니다. 글의 핵심은 단순합니다. LLM이 코드를 빠르게 생산하는 시대에는 사람이 기본 백프레셔가 되면 안 됩니다. 사람이 매번 출력물을 읽고, 실패를 찾아주고, 다시 프롬프트에 복사해 넣는 구조는 위임이 아니라 병목입니다. 원문: Backpressure is all you need Backpressure 핵심 정리 문제 진단: 에이전트를 완전히 방치하면 저품질 PR이 쏟아지고, 모든 작은 결정을 사람이 검토하면 에이전트를 쓰는 의미가 줄어든다. 핵심 해법: 사람 대신 시스템이 먼저 “아직 안 된다"고 말하게 만든다. 테스트, 타입, 린트, 벤치마크, 리뷰 에이전트, PR 모니터링이 그 역할을 한다. 운영 원칙: 체크는 마지막에 한 번이 아니라 각 패치/반복마다 … --- ### AI 하드웨어 시장: 컴퓨트가 아니라 메모리 병목이 승부를 가른다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/ai-hardware-memory-bottleneck-market-map/ - Section: software - Date: 2026-05-27 - Description: AI 하드웨어 시장은 연산량 경쟁에서 메모리 대역폭 경쟁으로 이동하고 있습니다. 칩, 인퍼런스 엔진, KV 캐시, 패키징 계층별로 어떤 기업이 병목을 공략하는지 정리합니다. - Tags: AI, 하드웨어, GPU, HBM, LLM, 인퍼런스 - Frameworks: First Principles - Mental Models: Bottleneck Analysis 출처: https://www.categoryvc.com/writing/where-the-ai-hardware-market-is 이 글은 2026년 현재 AI 인퍼런스 시장을 “누가 더 많은 FLOPS를 내느냐"가 아니라 “누가 메모리 병목을 더 잘 푸느냐"의 관점으로 재정리합니다. 특히 LLM serving의 실제 병목이 prefill과 decode에서 다르게 나타난다는 점을 기준으로, 어떤 레이어에서 기업들이 경쟁하는지 살펴봅니다. TL;DR 핵심 정리 병목의 본질: H100급 GPU에서도 LLM autoregressive decode 구간은 메모리 대역폭 제약이 커서 Tensor Core 사용률이 낮아지기 쉽다. 칩 레벨 전략: Groq·Cerebras·d-Matrix류 접근은 연산 유닛 증설보다 메모리-연산 거리 단축(SRAM, scratchpad, wafer scale)으로 성능을 끌어올린다. 소프트웨어 전략: … --- ### Exploring Agent-Assisted Qualitative Analysis 핵심 정리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agent-assisted-qualitative-analysis-core-notes/ - Section: posts - Date: 2026-05-26 - Description: Shreya Shankar의 2026-05-21 글을 바탕으로, 에이전트 기반 정성 분석 실험에서 드러난 한계와 실무적 시사점을 정리한다. - Tags: AI, 에이전트, 정성분석, grounded-theory, human-in-the-loop - Frameworks: Grounded Theory, Human-in-the-loop, Evaluation Drift - Mental Models: 목표 불안정성, 신호 대 잡음, 검증 비용의 가시화 Shreya Shankar의 2026년 5월 21일 글 **“Exploring Agent-Assisted Qualitative Analysis”**는 “정성 분석(qualitative analysis)을 에이전트가 어디까지 도울 수 있는가"를 실제 실험으로 검토한 기록입니다. 핵심은 단순합니다. 에이전트가 텍스트를 많이 다루는 것과, 연구적으로 좋은 해석을 만드는 것은 전혀 다른 문제라는 점입니다. 원문: Exploring Agent-Assisted Qualitative Analysis TL;DR 핵심 정리 문제 설정: 저자는 grounded theory 기반 정성 분석을 대상으로, 사람 개입 정도와 멀티에이전트 구성을 바꿔 6개 조건을 비교했다. 핵심 관찰 1: 무개입 또는 약한 개입 조건에서 에이전트는 분석보다 재진술(paraphrase)에 가까운 출력을 내는 경향이 강했다. 핵심 관찰 2: exp1에서 “트윗 길이 ↔ 코드 수 … --- ### The Eternal Sloptember 핵심 정리 — '에이전트 도입'이 소프트웨어 품질을 악화시킬 수 있다는 경고 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/the-eternal-sloptember-summary/ - Section: posts - Date: 2026-05-26 - Description: geohot의 2026-05-24 글 The Eternal Sloptember를 정리했다. 핵심은 '코드 생성량 증가'와 '품질 하락'의 비대칭 리스크, 그리고 조직 단위 도입에서 발생하는 피드백 붕괴다. - Tags: AI, 에이전트, 소프트웨어품질, geohot, LLM - Frameworks: 품질-속도 트레이드오프, 조직 피드백 루프, 도구 적합성 판단 - Mental Models: 탐색-활용 균형, 굿하트의 법칙, 신호와 노이즈 분리 geohot(George Hotz)의 2026년 5월 24일 포스트 **“The Eternal Sloptember”**는 AI 코딩 에이전트에 대한 강한 반대 의견을 담고 있습니다. 글의 톤은 도발적이지만, 문제 제기는 실무적으로 중요합니다: 생산성 수치가 좋아 보여도 코드베이스의 평균 품질은 오히려 나빠질 수 있다는 주장입니다. 원문: The Eternal Sloptember TL;DR 요약 핵심 주장: geohot은 “AI 에이전트의 소프트웨어 개발 도입"이 장기적으로 매우 비싼 비용을 유발할 수 있다고 본다. 근거 경험: tinygrad 개발과 하드웨어 리버스 엔지니어링 사례에서, 초기 속도는 빨라도 마무리 품질·정합성에서 사람이 직접 하는 편이 더 낫다고 평가한다. 조직 리스크: 고성과자는 슬롭(sloppy output)을 교정하지만, 대기업은 피드백 루프가 느려 하위 성과자의 “겉보기 10배 생산성"이 평균 품질을 … --- ### 왜 시니어 개발자는 자신의 전문성을 전달하는 데 실패할까 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/why-senior-developers-fail-to-communicate-summary/ - Section: posts - Date: 2026-05-14 - Description: Tuhin Nair의 글을 바탕으로, 시니어 개발자가 복잡성 관리 언어로 말할 때 비개발 조직과 왜 엇갈리는지 핵심 논지를 정리했다. - Tags: communication, senior-developer, ai, software-engineering - Frameworks: Systems Thinking, Verification-first Engineering, Operational Excellence - Mental Models: Second-order Effects, Borrowed Confidence 이 글은 Tuhin Nair의 아티클 **「Why senior developers fail to communicate their expertise」(2026-05-12)**를 바탕으로, 시니어 개발자의 설명이 왜 조직에서 잘 받아들여지지 않는지 구조적으로 정리한 글이다. TL;DR 핵심 정리 시니어 개발자는 “덜 만들기, 재사용, 지연"을 통해 **복잡성(complexity)**을 관리하려고 한다. 반면 비즈니스 조직은 시장 학습 속도를 높여 **불확실성(uncertainty)**을 줄이는 데 집중한다. 그래서 시니어가 “유지보수성·안정성"만 강조하면, 상대의 핵심 문제를 해결하지 못해 설득이 실패한다. 저자가 제안한 실전 문장: “Can we try something quicker?” AI 시대에는 Speed(실험용)와 Scale(안정화용) 시스템을 분리해, 속도와 안정성을 동시에 달성하자는 제안이 나온다. 원문: … --- ### Useful Memories Become Faulty When Continuously Updated by LLMs - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/faulty-memory-summary/ - Section: posts - Date: 2026-05-13 - Description: LLM 에이전트가 경험을 텍스트 메모리로 반복 재작성할수록 성능이 떨어질 수 있다는 Dylan Zhang의 'Faulty Memory' 핵심 결과를 정리합니다. - Tags: LLM, Agent Memory, Continual Learning, ARC-AGI, ScienceWorld, WebShop - Frameworks: Continual Learning, Memory Consolidation - Mental Models: Lossy Compression, Interference LLM 에이전트 메모리의 정석처럼 여겨졌던 “경험 정리 → 텍스트 저장 → 반복 재작성” 루프가 실제로는 자기개선을 보장하지 않는다는 문제 제기입니다. 이 글은 Dylan Zhang의 **“Useful memories become faulty when continuously updated by LLMs”**를 빠르게 파악하려는 분들을 위한 정리입니다. TL;DR 요약 핵심 결과: GPT-5.4가 ARC-AGI에서 메모리 없이 100% 풀던 문제군이, 정답 기반 통합(consolidation) 후 **54%**까지 하락. 중요 포인트: 같은 데이터여도 업데이트 스케줄이 달라지면 메모리가 달라지고 성능도 달라짐(특히 Stream가 최악). 실패 원인 3가지: 잘못된 묶기(misgrouping), 과잉 일반화/간섭(interference), 반복 재작성에 따른 과적합(overfit). 실무 시사점: " 메모리 누적"보다 선별된 … --- ### 'Agentic Coding is a Trap': 속도 뒤에 숨은 인지 부채 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/agentic-coding-is-a-trap-summary/ - Section: software - Date: 2026-05-06 - Description: Lars Faye의 'Agentic Coding is a Trap' 핵심 주장(기술 위축의 역설, 감독자 역량 역설, 토큰 비용 불확실성)과 실무 대응 전략을 정리한다. - Tags: AI, 에이전트, agentic coding, 코드 리뷰, 인지 부채, 개발 생산성 - Frameworks: Human-in-the-loop, Risk Management - Mental Models: Second-order Effects, Dependency Risk 출처: https://larsfaye.com/articles/agentic-coding-is-a-trap Lars Faye는 “AI가 코드를 쓰고 인간은 오케스트레이션만 하면 된다”는 흐름이 생산성 혁신처럼 보이지만, 실제로는 팀의 핵심 개발 역량과 비용 구조를 동시에 흔들 수 있다고 경고한다. TL;DR 핵심 정리 핵심 문제: 에이전틱 코딩은 초반 산출 속도를 높이지만, 사람이 코드에서 멀어질수록 장기적으로 이해·설계·디버깅 능력 저하가 발생할 수 있다. 감독자 역설: AI 출력을 제대로 검증하려면 숙련 개발자의 판단력이 필수인데, AI 의존이 커질수록 그 판단력 자체가 약화되는 모순이 생긴다. 주니어 성장 리스크: ‘직접 작성→실패→수정’ 경험이 줄면 코드 리뷰만으로는 학습 곡선이 가파르게 떨어질 수 있다. 비용/벤더 리스크: 토큰 사용량과 모델 성능은 고정비가 아니라 변동성이 큰 외생 변수이므로, 전면 도입 시 예산·운영 안정성이 낮아질 수 있다. 실무 결론: 에이전트를 기본값 … --- ### Addy Osmani의 Agent Skills — 에이전트에게 시니어 엔지니어링 프로세스를 강제하는 방법 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agent-skills-addy-osmani/ - Section: posts - Date: 2026-05-06 - Description: Addy Osmani의 'Agent Skills'(2026-05-03)를 했다. 핵심은 에이전트에게 '코드 생성'만 시키지 말고, spec→plan→build→test→review→ship의 시니어 엔지니어링 루프를 워크플로우로 강제해야 한다는 점이다. - Tags: AI, agent-skills, Addy Osmani, SDLC, 프롬프트엔지니어링, 코드리뷰, 테스트 - Frameworks: Process over prose, Progressive disclosure, Verification-first SDLC - Mental Models: Anti-rationalization, Scope discipline, Code as liability 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가지: … --- ### LLM 추론 파이프라인 완전 해부: Prefill, Decode, KV Cache, Quantization - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/llm-inference-prefill-decode-kv-cache/ - Section: posts - Date: 2026-05-04 - Description: 프롬프트 입력부터 토큰 스트리밍까지, LLM 추론이 실제로 어떻게 돌아가는지 Prefill/Decode 분리와 KV 캐시 중심으로 정리합니다. - Tags: llm, inference, transformer, kv-cache, quantization - Frameworks: First Principles - Mental Models: Bottleneck Analysis, Systems Thinking 프롬프트를 입력하면 몇 백 밀리초 뒤에 토큰이 스트리밍으로 나오기 시작합니다. 겉보기엔 단순하지만, 내부에서는 서로 병목이 다른 두 추론 단계가 연속으로 실행됩니다. 이 글은 해당 구조를 1차 원리(First Principles) 관점으로 정리한 글입니다. TL;DR 핵심 정리 추론은 두 단계다: 첫 토큰 전까지의 Prefill(TTFT) 과 이후 스트리밍의 Decode(ITL) 는 병목이 다르다. 성능 지표도 분리해야 한다: 시작이 느린 문제는 프롬프트 길이/연산 최적화, 스트리밍이 느린 문제는 메모리 대역폭/KV 캐시 최적화가 핵심이다. KV 캐시는 속도의 핵심이자 비용의 근원: 재계산을 막아 속도를 올리지만, 긴 컨텍스트에서 VRAM을 크게 소모한다. 양자화는 고효율 레버: FP16/BF16, INT8, INT4로 갈수록 메모리 절감과 처리량 개선 효과가 크다. 원문: https://x.com/akshay_pachaar/article/2050941458614751327 --- ### The 20 Software Engineering Laws 핵심 정리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/the-20-software-engineering-laws-summary/ - Section: posts - Date: 2026-05-04 - Description: Dr. Milan Milanović의 'The 20 Software Engineering Laws'를 6개 주제와 실무 적용 포인트 중심으로 정리한 글. - Tags: 소프트웨어 엔지니어링, 법칙, 아키텍처, 팀 생산성, 의사결정 - Frameworks: First Principles, Systems Thinking - Mental Models: Trade-off Thinking, Second-order Effects 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), 장애를 기본값으로 설계 … --- ### Palantir Ontology 핵심 : 데이터 중심을 넘어 의사결정 중심 아키텍처로 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/palantir-ontology-decision-centric-architecture/ - Section: posts - Date: 2026-05-04 - Description: Palantir가 제시한 Ontology의 핵심을 데이터·로직·액션·보안 4요소와 Onyx 사례 중심으로 정리한 글. - Tags: palantir, ontology, aip, ai-agent, enterprise-ai - Frameworks: Systems Thinking, Agent-native Development, Verification-first Engineering - Mental Models: Borrowed Confidence, Trade-off Analysis Palantir가 공개한 “The Palantir Ontology"는 단순한 데이터 통합 전략이 아니라, 기업 운영을 의사결정 단위로 모델링해야 한다는 주장을 담고 있습니다. 이 글은 긴 원문을 실무 관점에서 빠르게 파악할 수 있도록 핵심만 압축한 정리입니다. TL;DR 핵심 정리 핵심 프레임: Ontology는 Data + Logic + Action + Security를 하나로 연결해, 분석 시스템이 아닌 운영 의사결정 시스템을 만든다. 중요한 포인트: 기업 데이터 자체보다, 누가/언제/어떤 맥락에서 어떤 결정을 내렸는지에 대한 의사결정 데이터와 계보 축적을 더 중시한다. 에이전트 활용 방식: LLM이 단순 조회(RAG)에 머무르지 않고, 기존 최적화 모델·시뮬레이터·업무 로직을 툴로 호출해 대안을 만들고 시나리오로 안전하게 검토한다. 실행과 통제: 액션(writeback)은 ERP/WMS/엣지 시스템까지 반영되지만, 권한·검증·감사 로그를 동일한 보안 체계로 … --- ### Scaling Pain — 智谱 GLM-5가 초대규모 Coding Agent 추론에서 실제로 부딪힌 벽 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/scaling-pain-zhipu-glm5-coding-agent/ - Section: posts - Date: 2026-04-30 - Description: 智谱(Z.ai)이 공개한 「Scaling Pain」은 GLM-5 시리즈가 초대규모 Coding Agent 호출에서 겪은 추론 인프라 문제를 처음으로 공개한 글이다. 처리량 +132%, 이상 출력률 만분의 십몇에서 만분의 3 미만으로의 개선, 그리고 SGLang 업스트림으로 환원된 PR #22811이 의미하는 바를 짚는다. - Tags: Z.ai, Zhipu, GLM-5, Coding Agent, SGLang, DeepSeek Sparse Attention, DSA, Huawei Ascend, Inference Infrastructure, Determinism, 오픈소스, 추론 최적화 - Frameworks: Coding Agent Workload vs Chat Workload, Determinism as Multi-turn SLA, Open-source Reciprocity - Mental Models: Scale-up Reveals New Pain, Throughput × Determinism × Long-context Stability, Infra as Product Differentiator 오늘(2026.4.30) 智谱(Zhipu / Z.ai)이 공개한 기술 블로그 **「Scaling Pain：超大规模 Coding Agent 推理实践」**는 GLM-5 시리즈가 초대규모 Coding Agent 호출 시나리오에서 겪은 추론 인프라 문제와, 이를 해결하기 위한 엔지니어링 최적화 결과를 처음으로 체계적으로 공개한 글입니다. 단순한 자랑이 아니라, 수요가 공급을 초과해 신규 구독을 제한해야 했던 몇 달의 누적 이슈에 대한 공식 답변에 가깝습니다. 원문: Scaling Pain — Z.ai Blog (2026-04-30) 핵심 도발 “Scaling up하니, 진짜 본 적 없는 아픔이 나왔다.” 이 정서가 글 전체의 톤입니다. 회피하지 않고 공개했다는 사실 자체가 이번 포스트의 위치를 결정합니다. --- ### 학습할 것인가, 말 것인가 — Tanay Jaipuria가 정리한 AI 앱 회사의 모델 레이어 진입 가이드 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/to-train-or-not-to-train/ - Section: posts - Date: 2026-04-29 - Description: Tanay Jaipuria의 'To Train or Not to Train'을 한국어로 정리한다 — AI 앱 회사가 모델 레이어로 풀스택화될 때, 사전학습은 피하고 post-training/RL을 언제·어떻게 시작해야 하는지, 그리고 베이스 모델 릴리즈 사이클이라는 가장 큰 리스크는 무엇인지. - Tags: AI, post-training, RL, 파인튜닝, 스타트업, 모델 레이어, Tanay Jaipuria - Frameworks: Build vs Buy, Opportunity Cost - Mental Models: Stack Migration, Proprietary Data Moat AI 애플리케이션 회사들이 점점 더 풀스택화되어 모델 레이어와 서비스 레이어로 진입하고 있는 가운데, 언제 자체 모델 학습에 뛰어들어야 하는가 라는 질문이 점점 무거워지고 있습니다. Tanay Jaipuria의 “To Train or Not to Train"은 이 결정을 둘러싼 트레이드오프를 짧고 명확하게 정리합니다. 원문: To Train or Not to Train — Tanay Jaipuria TL;DR 요약 풀스택화는 진행 중: 앱 레이어 회사들이 모델·서비스 레이어로 내려가고 있지만, 처음부터 사전학습 은 거의 항상 잘못된 선택이다. 현실적 경로: 강력한 오픈 웨이트 베이스 모델 위에서 post-training과 RL 을 얹는 방식이 디폴트가 되고 있다. 학습 트리거: 파이프라인의 특정 부분에서 작은 특화 모델이 프론티어 모델보다 의미 있게 더 잘하게 만들 만큼의 독점 데이터가 쌓였을 때, 그리고 회사가 빠르게 스케일링하며 데이터 트레이스를 모으거나 … --- ### 빌드하기 전 3가지 제약 — Jordan Lord이 10년 실패에서 추출한 창작자의 가드레일 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/jordan-lord-3-constraints/ - Section: posts - Date: 2026-04-29 - Description: Jordan Lord이 10년간 '너무 복잡하거나 정체성이 없는' 제품을 만들며 실패한 끝에 정리한 3가지 제약 — One Pager, Core Technology, Product Constraint. 제약은 창의성의 적이 아니라 탐색 공간을 좁혀 혁신을 강제하는 장치라는 주장을 정리한다. - Tags: Jordan Lord, Constraints, Product Design, One Pager, Core Technology, Product Identity, Indie Hacker, 제약기반설계, 제품철학 - Frameworks: Constraint-Driven Design, North Star Definition, Compounding Core Tech - Mental Models: Search Space Collapse, Pivot vs Foundation, Identity-Forming Constraint 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: 제품을 떠받치되 제품 자체는 아닌 핵심 기술 한 … --- ### 양자화 비주얼 가이드 — Maarten Grootendorst가 그림으로 푸는 LLM 경량화 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/visual-guide-to-quantization/ - Section: posts - Date: 2026-04-28 - Description: Maarten Grootendorst의 'A Visual Guide to Quantization'을 한국어로 정리한다 — FP32→FP16/BF16/INT8/INT4의 표현 손실, symmetric/asymmetric 양자화, calibration·clipping의 트레이드오프, PTQ(GPTQ·GGUF) vs QAT(BitNet·BitNet b1.58)까 … - Tags: LLM, Quantization, 양자화, GPTQ, GGUF, BitNet, QAT, PTQ, FP16, BF16, INT8, INT4, llama.cpp, Maarten Grootendorst - Frameworks: Quantization, Symmetric/Asymmetric Mapping, Block-wise Quantization, Quantization-Aware Training - Mental Models: Dynamic Range vs Precision, Quantization Error Redistribution, Wide vs Narrow Minima 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 비트, 정수 연산) … --- ### 에이전틱 엔지니어링 매니지먼트 — EM 역할에 에이전트를 적용하면 무엇이 보이는가 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-engineering-management/ - Section: posts - Date: 2026-04-28 - Description: Peter Szász가 제안하는 사고 실험 — 엔지니어링 매니저(EM) 역할을 Execution·Team Dynamics·Personal Development로 분해하고, 자율성 적합도(Autonomy Fitness)와 신뢰 경사(Trust Gradient)라는 두 축으로 어디까지 에이전트에게 맡길 수 있는지 평가한다. - Tags: AI, 에이전트, 엔지니어링매니지먼트, 리더십, 하네스, 자율성 - Frameworks: Systems Thinking, First Principles - Mental Models: Trust Gradient, Blast Radius Peter Szász가 “엔지니어링 매니저(EM) 역할에 에이전트를 적용하면 어떻게 될까?“라는 사고 실험을 통해 기회와 리스크를 동시에 드러내는 글입니다. 코드 완성에서 에이전틱 엔지니어링으로 넘어가는 흐름이 매니지먼트 영역까지 확장될 수 있는지 탐색합니다. 원문: Agentic Engineering Management TL;DR 요약 에이전트 정의: 사용자 프롬프트로부터 목표 달성까지 “도구 호출 → LLM 평가” 루프를 자율적으로 반복하는 시스템. EM 분해: Execution(실행), Team Dynamics(팀 다이내믹스), Personal Development(개인 성장) 3축. 위로 갈수록 사람과의 거리는 가깝고 리스크는 높아진다. 두 평가 축: ① Autonomy Fitness — 반복성·데이터 풍부도·모호성·가역성. ② Trust Gradient — 개인적일수록 신뢰 리스크 증가. 하네스 설계: confidence … --- ### 오늘의 하네스는 내일의 프롬프트 — 모델이 결국 하네스를 먹는다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/todays-harness-is-tomorrows-prompt/ - Section: posts - Date: 2026-04-27 - Description: Tanay Sai의 'Today's harness is Tomorrow's Prompt' . 2023년 2주짜리 RAG 파이프라인이 1M 토큰 컨텍스트에 통째로 먹힌 자기 경험에서 출발해, 하네스는 모델 한계의 우회로를 아키텍처로 포장한 것이며 유통기한이 점점 짧아진다고 진단한다. 이미 먹힌 사례 3가지(PDF·JSON·OCR)와 지금 짓고 있지만 곧 먹힐 … - Tags: AI, 하네스, LLM, RAG, 구조화 출력, 비전 모델, 멀티 에이전트, 브라우저 에이전트, 음성 AI, Tanay Sai - Frameworks: Harness Engineering, Workaround Decay, Throwaway Architecture - Mental Models: Capability Absorption, Scaffolding-as-Liability, Disposable Infrastructure 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 추 … --- ### 잃어버린 게으름의 위험 — Bryan Cantrill이 LLM 시대에 다시 꺼내는 프로그래머의 미덕 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/peril-of-laziness-lost/ - Section: posts - Date: 2026-04-27 - Description: Bryan Cantrill이 Larry Wall의 '게으름·조급함·자만'이라는 프로그래머의 세 미덕을 다시 꺼내, LLM이 왜 좋은 추상화를 만들지 못하는지 진단한다. Garry Tan의 '하루 37,000줄' 자랑과 DTrace 60,000줄을 나란히 놓으면, 시간 제약이 없는 생성기가 만든 코드가 어떻게 쓰레기 레이어케이크가 되는지가 드러난다. - Tags: Bryan Cantrill, Larry Wall, Programming Perl, Laziness, LLM, AI, Oxide, DTrace, Garry Tan, Code Quality, 소프트웨어공학 - Frameworks: Three Programmer Virtues, Constraint-Driven Engineering, Virtuous Laziness - Mental Models: Generation without Time Cost, Quantity vs Quality of Code, Layercake of Garbage Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다. 원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12) TL;DR 요약 세 가지 미덕: Larry Wall의 Programming Perl(“Camel Book”)이 말한 Laziness, Impatience, and Hubris는 좋은 소프트웨어 설계의 토대였다. 진짜 게으름: 문제를 머릿속에서 굴리고 또 굴려, 미래의 개발자에게 도움이 되는 강력한 추상화를 만들어내는 지적 노동이다. LLM의 결함: 일에 비용이 … --- ### 하네스 엔지니어링 — 좋은 모델 + 나쁜 하네스보다 평범한 모델 + 훌륭한 하네스가 이긴다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agent-harness-engineering/ - Section: posts - Date: 2026-04-27 - Description: Addy Osmani가 제시하는 '하네스 엔지니어링'의 핵심 원칙 — 에이전트 = 모델 + 하네스, 모든 실패는 룰이 되고, 모델이 강해지면 하네스는 줄어드는 게 아니라 이동한다. Claude Code·Cursor·Codex·Aider·Cline의 공통 패턴과 Harness-as-a-Service로의 전환을 정리한다. - Tags: AI, 에이전트, 하네스, Addy Osmani, Claude Code, AGENTS.md, Ralph Loop, HaaS - Frameworks: Harness Engineering, The Ratchet, Working Backwards from Behaviour - Mental Models: Skill Issue Reframe, Model-Harness Training Loop, Behavior-First Design Addy Osmani가 2026년 4월에 정리한 글입니다. 핵심 명제는 단순합니다 — 코딩 에이전트 = 모델 + 그 주변에 당신이 만든 모든 것이고, 그 “주변"을 진지하게 다루는 규율을 하네스 엔지니어링이라 부릅니다. 원문: Agent Harness Engineering — Addy Osmani (2026-04-19) 한 줄 A decent model with a great harness beats a great model with a bad harness. 평범한 모델 + 훌륭한 하네스가, 훌륭한 모델 + 나쁜 하네스를 이깁니다. Claude Code, Cursor, Codex, Aider, Cline이 종종 동일한 모델을 쓰면서 행동이 완전히 갈리는 이유는 모델이 아니라 하네스 차이에 있습니다. --- ### 에이전트는 구조와 유연성 사이에서 고를 수 없다 — Python 캠프 vs Markdown 캠프의 가짜 선택지 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agents-cant-choose-structure-flexibility/ - Section: posts - Date: 2026-04-25 - Description: The AI Frontier의 'Agents can't choose between structure and flexibility' 정리 — Python 대 Markdown 논쟁은 가짜 선택지다. 코드 최대주의는 에이전트의 추론을 제거하고, 마크다운 최대주의는 통제·디버그·교정 가능성을 포기한다. RunLLM과 Claude Code가 도달한 하이브리드 … - Tags: AI, Agent, LLM, Architecture, Python, Markdown, Harness, Guardrails, AGENTS.md, Agent-Native, RunLLM, AI SRE - Frameworks: Hybrid Agent Architecture, Code Harness, Intent vs Enforcement, Agent-Native Design - Mental Models: False Dichotomy, Failure Modes, Layer Separation, Parallel Hypothesis Evaluation LLM 하이프 사이클이 시작될 때, 우리 시대의 큰 논쟁 중 하나가 Python과 Markdown 사이의 에이전트 명세 언어 선택이 될 거라고는 아무도 예상하지 못했습니다. 하지만 The AI Frontier(Vikram Sreekanti 외)가 Agent Native 시리즈의 일부로 짚듯, 이 질문은 빠르게 AI 아키텍처에서 가장 결정적인 논쟁이 되었습니다. 글의 핵심 주장은 단순합니다 — 이 논쟁은 두 개의 방어 가능한 입장 사이의 선택이 아니라, 양쪽 모두 실패 모드라는 것입니다. 어느 쪽도 agent-native가 아니기 때문입니다. TL;DR 요약 가짜 선택지: Python 캠프는 단계의 엄격한 요구사항을 코드로 표현하고, Markdown 캠프는 영어로 목표·제약을 주고 계획을 맡긴다. 양쪽 다 극단에 가면 에이전트의 본질을 망친다. 코드 최대주의의 세 가지 실패: 인간의 직렬 가설 추적을 모방, 시도/배제 이유에 대한 가시성 부재, 시스템이 바뀌면 진화하지 못함 — … --- ### 당신의 모든 에이전트는 비동기로 간다 — HTTP 요청-응답이 더 이상 맞지 않는 이유 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/all-your-agents-are-going-async/ - Section: posts - Date: 2026-04-24 - Description: Zak Knill(Ably)이 던지는 인프라 진단 — 챗봇이 HTTP 요청-응답 위에 만들어진 것은 일종의 사고였고, 비동기 에이전트의 시대에는 이 선택이 깨진다. Durable State와 Durable Transport를 분리해서 보면 Anthropic Routines, Cloudflare Sessions API, OpenClaw 채널, Ably의 세션 … - Tags: AI, 에이전트, Async, HTTP, Durable Transport, Durable State, Zak Knill, Ably, Anthropic, Cloudflare, OpenClaw, 인프라 - Frameworks: Durable State vs Durable Transport, Session as First-class Primitive - Mental Models: Async Agent Lifecycle, Transport-State Separation, Connection Lifetime ≠ Work Lifetime LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다. 원문: All Your Agents Are Going Async — Zak Knill (2026) 핵심 도발 “The interesting thing is what agents can do while not being synchronously supervised by a human.” 흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다. --- ### 한 명의 개발자, 24개의 에이전트, 그리고 제로 얼라인먼트 — Maggie Appleton의 새로운 병목 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/zero-alignment-maggie-appleton/ - Section: posts - Date: 2026-04-24 - Description: GitHub Next의 Maggie Appleton이 던지는 질문 — 한 명이 24개 에이전트를 부린다는 비전은 왜 틀렸는가. 구현이 거의 공짜가 된 시대에 진짜 병목은 '무엇을 만들지 합의하는 일'이며, PR과 이슈는 더 이상 그 합의를 담을 그릇이 아니다. 'Ace' 프로토타입을 통한 멀티플레이어 에이전트 협업의 그림. - Tags: Maggie Appleton, AI, 에이전트, GitHub Next, Ace, Alignment, Coordination Debt, 협업도구, 팀스포츠, 소프트웨어공학 - Frameworks: Alignment Bottleneck, Coordination Debt, Multiplayer Prompting - Mental Models: Software as Team Sport, Shifting Bottleneck, Quality as Differentiator “한 명의 개발자가 24개의 Claude를 동시에 부린다.” — 2026년 에이전틱 개발 도구 마케팅이 즐겨 그리는 그림입니다. Maggie Appleton(GitHub Next, Staff Research Engineer)은 이 그림이 틀린 문제를 풀고 있다고 말합니다. 구현이 빨라진 만큼, 진짜 병목은 다른 곳으로 옮겨갔습니다 — 무엇을 만들지에 대한 팀의 합의. 원문: One Developer, Two Dozen Agents, Zero Alignment — Maggie Appleton (2026) 핵심 도발 “Software is not made by one person in a vacuum. It’s a team sport.” --- ### 인지 부채와 System 3 — Martin Fowler가 골라낸 '검증의 시대'를 위한 다섯 개의 조각 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/fowler-fragments-cognitive-debt-system-3/ - Section: posts - Date: 2026-04-24 - Description: Martin Fowler의 2026-04-02 Fragments 정리 — Storey의 Technical/Cognitive/Intent 삼중 부채, Shaw & Nave의 System 3와 Cognitive Surrender, Ajey Gore가 말하는 '검증이 비싸진 시대', 그리고 LLM과 함께 성장하는 Ubiquitous Language. - Tags: Martin Fowler, Cognitive Debt, Intent Debt, System 3, Cognitive Surrender, AI, LLM, Verification, Ubiquitous Language, 소프트웨어공학 - Frameworks: Three Layers of System Health, Tri-System Cognition, Ubiquitous Language - Mental Models: Cognitive Debt, Intent Debt, Cognitive Surrender, Cognitive Offloading, Generation-Review Asymmetry Martin Fowler가 간헐적으로 올리는 Fragments 시리즈는 최근 읽은 글들에 대한 짧은 주석 모음입니다. 2026년 4월 2일자는 유독 밀도가 높습니다 — 부채의 재정의, 사고 시스템의 확장, 검증의 경제학, 그리고 언어와 이름 짓기에 관한 다섯 개의 조각이 한 페이지에 놓여 있습니다. LLM이 코드를 생성하는 시대에 인간이 무엇에 집중해야 하는지에 대한 하나의 일관된 그림이 드러납니다. 원문: Fragments: April 2 — Martin Fowler (2026) 조각 1. 시스템 건강의 세 층위 — Technical / Cognitive / Intent Debt Margaret-Anne Storey의 논문이 제시하는 프레임은 기술 부채(technical debt) 개념의 한계를 정면으로 겨냥합니다. --- ### 확률적 엔지니어링과 24/7 직원 — 생성은 밤에도 멈추지 않지만, 검증은 그렇지 못하다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/probabilistic-engineering-24-7-employee/ - Section: posts - Date: 2026-04-18 - Description: Tim Davis가 말하는 확률적 엔지니어링의 시대 — 에이전트가 밤새 PR을 생성하지만 검증 용량은 그만큼 확장되지 않는다. 생성-검증 비대칭, 역할 파편화, 조용한 성능 저하, 그리고 '다음 모델을 위해 지금부터 근육을 키워야 한다'는 제안. - Tags: AI, 에이전트, Probabilistic Engineering, 소프트웨어공학, Tim Davis, Compound Loop, 코드 리뷰, Jevons Paradox, 조직 설계, 주니어 훈련 - Frameworks: Probabilistic vs Deterministic Engineering, Jevons Paradox, Agentic Fleet - Mental Models: Silent Degradation, Generation-Review Asymmetry, Build for the Model You Don't Have Yet 소프트웨어는 결정론적 공학에서 확률적 공학으로 전환되고 있습니다. 에이전트는 사람이 잠든 사이에도 코드를 생성하지만, 그것을 검증할 용량은 같이 자라지 않습니다. Tim Davis는 이 비대칭이 역할, 조직, 그리고 엔지니어가 살아남기 위해 쌓아야 할 근육 자체를 재편한다고 주장합니다. 원문: Probabilistic Engineering and the 24-7 Employee — Tim Davis (2026) 핵심 논제 “지식 노동 역사상 처음으로, 집에 간 사람이 자기 뇌의 유일한 사본을 들고 가지 않는다.” 저자가 운영하는 Compound Loop는 밤새 자율적으로 PR을 생성하는 코딩 시스템입니다. 24/7 근무하는 사람이 생긴 것이 아니라, 병렬화된 에이전트 노동이 생긴 것 — 이 차이가 모든 논의의 출발점입니다. --- ### LLM API의 숨은 비용 — 백만 토큰당 가격 비교를 멈춰라 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/hidden-llm-api-costs/ - Section: posts - Date: 2026-04-18 - Description: TensorZero의 Gabriel Bianconi가 실증한 LLM 가격의 함정 — 동일 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성한다. 도구 정의 워크로드에서 claude-opus-4-7은 gpt-5.4 대비 리스트 가격은 2배지만 실효 비용은 5.3배다. - Tags: LLM, API, 비용, 토크나이저, OpenAI, Anthropic, Google, TensorZero, LLMOps, 오픈소스, Gateway - Frameworks: Total Cost of Ownership, First Principles - Mental Models: Hidden Costs, Apples-to-Apples Comparison “백만 토큰당 $X” 는 LLM 가격을 비교하는 가장 흔한 기준이지만, TensorZero의 Gabriel Bianconi는 이 기준이 근본적으로 망가졌다고 주장합니다. 동일한 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성하기 때문입니다. 리스트 가격이 비슷해 보여도 실효 비용은 크게 벌어지며, 특히 도구(tool) 정의가 많은 에이전트 워크로드에서 순위가 뒤집힙니다. 원문: Stop comparing price per million tokens: the hidden LLM API costs — Gabriel Bianconi, TensorZero (2026-04-16) · 오픈소스: tensorzero/tensorzero 핵심 주장 같은 입력이 모델에 따라 2.65배 이상 더 많은 토큰을 생성한다. --- ### AI Knowledge Layer — 에이전트가 쓸모 있어지기 위한 지식 레이어 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-knowledge-layer/ - Section: posts - Date: 2026-04-17 - Description: Shann Holmberg가 제안하는 AI Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어(raw + compiled wiki) 구조로, RAG 대신 한 번 컴파일한 지식 그래프가 100편 이후부터 Q&A에서 RAG를 능가한다. - Tags: AI, 에이전트, 지식베이스, LLM, Karpathy, RAG, Obsidian, Claude Code - Frameworks: LLM Wiki Pattern, Two-Layer Knowledge System - Mental Models: Compilation vs Retrieval, Compound Knowledge Shann Holmberg는 에이전트가 쓸모 없는 근본 이유는 지식을 보관하지 않기 때문이라고 주장합니다. 모든 대화가 0에서 시작하고, 매번 비즈니스 맥락·목소리·목표를 재설명해야 하며, 결과는 늘 제네릭합니다. 해법은 에이전트와 사용자 사이에 앉는 Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어 시스템입니다. 20분 셋업, 매일 스스로 개선, 오픈소스. 원문: AI Knowledge Layer (and why your agents are useless without it) — Shann Holmberg · 구현체: shannhk/llm-wikid 핵심 문제 — 에이전트는 매번 0에서 시작한다 대부분의 팀이 겪는 패턴: --- ### Agentic Engine Optimization: AI 에이전트가 읽을 수 있는 문서를 만드는 새로운 규율 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-engine-optimization/ - Section: posts - Date: 2026-04-16 - Description: AI 코딩 에이전트가 개발자 문서를 소비하는 방식은 인간과 근본적으로 다르다. Addy Osmani가 제시하는 Agentic Engine Optimization(AEO)의 6계층 스택과 실무 체크리스트를 정리한다. - Tags: AI, AEO, SEO, 문서화, 에이전트, DevEx, API, llms.txt - Frameworks: AEO Stack, First Principles - Mental Models: Audience Segmentation, Token Economics 개발자 문서를 인간 독자만을 대상으로 최적화하는 시대가 끝나가고 있습니다. AI 코딩 에이전트는 문서를 전혀 다른 방식으로 소비하며, 기존 포털은 점점 에이전트에게 보이지 않는 존재가 되고 있습니다. Addy Osmani는 이를 해결하기 위한 새로운 규율로 Agentic Engine Optimization(AEO) 을 제안합니다. 과거 SEO가 검색 크롤러를 위해 콘텐츠를 구조화했던 것처럼, AEO는 에이전트가 실제로 사용할 수 있도록 기술 콘텐츠를 구조화·포맷팅·제공하는 실천입니다. 왜 AEO인가 — 에이전트는 인간처럼 읽지 않는다 인간 패턴: 4~8분간 섹션을 점진적으로 클릭하며 탐색. 스크롤 깊이, 체류 시간, 링크 클릭 같은 분석 이벤트가 발생. 에이전트 패턴: 여러 페이지 탐색을 1~2개의 HTTP 요청으로 압축. 클라이언트 사이드 분석 이벤트는 전혀 남지 않음. 서버 로그에는 고유한 에이전트 핑거프린트가 남음 — Claude Code는 axios/1.8.4, … --- ### 에이전트 하네스의 해부학 — Anthropic, OpenAI, LangChain이 실제로 구축하는 것 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/anatomy-of-an-agent-harness/ - Section: posts - Date: 2026-04-11 - Description: Anthropic, OpenAI, LangChain 등이 구축하는 에이전트 하네스의 12가지 구성요소와 7가지 핵심 설계 결정을 분석한다. 동일 모델이라도 하네스 설계에 따라 성능이 20+ 랭킹 차이를 보인다. - Tags: AI, 에이전트, 하네스, 아키텍처, LLM, 프로덕션 - Frameworks: Systems Thinking, First Principles - Mental Models: Layered Architecture, Von Neumann Architecture Akshay Pachaar가 Anthropic, OpenAI, Perplexity, LangChain이 실제로 구축하고 있는 에이전트 하네스를 심층 분석합니다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리 등 stateless LLM을 capable agent로 변환하는 모든 것을 다룹니다. 원문: The Anatomy of an Agent Harness 핵심 주장 챗봇을 만들어 ReAct 루프에 도구 몇 개를 연결하면 데모에서는 작동한다. 프로덕션을 시도하면 무너진다 — 모델이 3단계 전에 한 일을 잊고, 도구 호출이 조용히 실패하고, 컨텍스트 윈도우가 쓰레기로 채워진다. 문제는 모델이 아니다. 모델을 둘러싼 모든 것이다. --- ### 에이전틱 소프트웨어 엔지니어링 — 에이전트 구축은 쉽지만 프로덕션 운영은 분산 시스템 문제다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-software-engineering/ - Section: posts - Date: 2026-04-11 - Description: Ashpreet Bedi가 제시하는 에이전틱 소프트웨어 엔지니어링의 6가지 기둥(내구성·격리·거버넌스·지속성·규모·조합가능성)과 Build-Serve-Connect 3단계 프레임워크. 에이전트를 프로덕션 분산 시스템으로 다루는 체계적 접근법. - Tags: AI, 에이전트, 소프트웨어엔지니어링, 분산시스템, 프로덕션, 아키텍처 - Frameworks: Systems Thinking, First Principles - Mental Models: Layered Architecture, Feedback Loop Ashpreet Bedi(Agno 창업자)가 에이전트 구축과 프로덕션 운영 사이의 격차를 지적하며, 에이전틱 소프트웨어를 분산 시스템으로 다뤄야 한다는 체계적 프레임워크를 제시합니다. 원문: Systems Engineering: Building Agentic Software That Works / Agentic Software Engineering 핵심 주장 “에이전트 구축은 쉽지만, 프로덕션 환경에서 안정적으로 운영하는 것은 어렵다” 사용자 식별, 상태 유지, 동시 요청 처리, 환불 같은 민감한 작업, 실패한 도구 호출 처리가 필요한 순간, 그것은 더 이상 “LLM + 도구의 루프"가 아닌 분산 시스템 이 된다. 에이전틱 소프트웨어 배포의 3단계 단계 설명 핵심 Build(구축) 모델, 도구, 지식베이스, 메모리, 저장소, 보호 장치 정의 AI 엔지니어링 중심. 대부분의 프레임워크가 지원하는 영역 Serve(서빙) API로서 제공. 사용자별 … --- ### LLM 에이전트를 위한 강화학습 환경 분류법 — 모델이 아닌 환경이 에이전트의 행동을 결정한다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/rl-environments-for-llm-agents/ - Section: posts - Date: 2026-04-11 - Description: 모델 아키텍처가 아닌 RL 환경 설계가 에이전트 성능의 절반을 결정한다는 주장과 함께, 작업(T)·하네스(H)·검증기(V)·상태(S)·설정(C) 5요소 프레임워크를 상세히 분석한다. - Tags: AI, 강화학습, 에이전트, LLM, RL, 환경설계 - Frameworks: First Principles, Systems Thinking - Mental Models: Layered Architecture, Feedback Loop 모델 아키텍처와 사후 학습(post-training)에만 집중하는 현재 AI 개발 패러다임을 비판하며, “에이전트가 무엇을 배울 수 있는지 결정하는 것은 강화학습 환경"이라고 주장합니다. 환경 설계가 시스템 성능의 절반을 차지한다는 것이 핵심입니다. 원문: RL Environments for LLM Agents 핵심 주장 단일 턴 Q&A로만 학습한 모델은 50단계 엔터프라이즈 워크플로우에서 실패하고, 보상 함수가 형편없으면 모델이 문제를 풀기보다 지표를 조작하도록 학습된다. 모델이 아닌 환경이 에이전트의 행동을 형성 한다. 정준 루프(Canonical Loop): E = {T, H, V, S, C} RL 환경을 다섯 가지 요소로 정의한다: --- ### 코딩 에이전트의 핵심 구성요소 — 모델이 아닌 하네스가 성능을 결정한다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/components-of-a-coding-agent/ - Section: posts - Date: 2026-04-11 - Description: Sebastian Raschka가 분석한 코딩 에이전트의 6가지 핵심 구성요소. 모델 자체보다 하네스 아키텍처(컨텍스트 관리, 도구 접근, 메모리, 서브에이전트 등)가 최종 성능을 결정한다는 주장. - Tags: AI, 에이전트, 코딩, 아키텍처, LLM, 하네스 - Frameworks: Systems Thinking, First Principles - Mental Models: Layered Architecture Sebastian Raschka가 Claude Code, Codex 같은 코딩 도구들이 기존 채팅 인터페이스보다 강력한 이유는 더 나은 모델 때문이 아니라, 모델을 둘러싼 “에이전트 하네스(harness)“의 설계 때문이라고 분석합니다. 같은 모델이라도 다른 하네스에 넣으면 완전히 다른 성능을 보일 수 있습니다. 원문: Components of a Coding Agent 핵심 주장 “many real-world applications, the surrounding system, such as tool use, context management, and memory, plays as much of a role as the model itself” 최신 LLM들(GPT-5.4, Opus 4.6 등)의 기본 성능이 유사해진 지금, 하네스의 품질이 최종 성능의 차별화 요소 가 된다. --- ### Marc Andreessen의 AI 혁명론: 80년의 밤샘 성공과 소프트웨어 아키텍처의 재발명 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/pmarca-ai-revolution/ - Section: posts - Date: 2026-04-11 - Description: Marc Andreessen이 Latent Space 팟캐스트에서 제시한 AI 혁명론 . 80년 축적된 연구의 결실, 4가지 돌파구, 닷컴 버블과의 차이, Pi+OpenClaw 아키텍처, 소프트웨어 풍부성 시대를 다룬다. - Tags: AI, 에이전트, 오픈소스, 스케일링, 아키텍처, Marc Andreessen - Frameworks: Systems Thinking, Historical Analysis - Mental Models: Paradigm Shift, S-Curve Latent Space 팟캐스트에 출연한 Marc Andreessen(a16z 공동창업자)이 현재 AI 붐을 1943년 신경망 이론부터 축적된 80년의 기초 연구가 결실을 맺는 역사적 전환점으로 진단하며, 소프트웨어 아키텍처의 근본적 변화를 논합니다. 원문: Marc Andreessen - Latent Space Podcast 핵심 프레임: “80년의 밤샘 성공 (80 Year Overnight Success)” 현재 AI 붐은 단순한 기술 사이클이 아니라, 1943년 신경망 이론부터 축적된 80년의 기초 연구가 결실을 맺는 순간 이라는 진단. 1. 이번이 진짜 다른 이유 — 4가지 돌파구 과거 AI는 붐-폭락(AI 겨울)을 반복했지만, 이번에는 4가지 기능이 동시에 작동 중: --- ### AI 에이전트의 지속적 학습: 모델·하네스·컨텍스트 3계층 학습 프레임워크 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/continual-learning-for-ai-agents/ - Section: posts - Date: 2026-04-11 - Description: AI 에이전트의 학습은 모델 가중치 업데이트만이 아니라 모델·하네스·컨텍스트 3계층에서 각각 독립적으로 발생할 수 있다는 LangChain의 지속적 학습 프레임워크를 한다. - Tags: AI, 에이전트, 지속적학습, LangChain, LLM - Frameworks: Systems Thinking - Mental Models: Layered Architecture LangChain CEO Harrison Chase가 AI 에이전트의 지속적 학습(Continual Learning)에 대해 제시한 프레임워크를 합니다. 에이전트의 “학습"은 모델 가중치 업데이트만을 의미하지 않으며, 3가지 서로 다른 계층에서 발생할 수 있다는 것이 핵심 주장입니다. 원문: Continual Learning for AI Agents 핵심 주장 AI 에이전트의 “학습"은 모델 가중치 업데이트만이 아니라, 3가지 계층에서 각각 독립적으로 발생 할 수 있다. 에이전트 시스템의 3계층 구조 계층 설명 예시 (Claude Code) 모델 계층 모델 가중치 자체 Claude Sonnet 하네스 계층 에이전트를 구동하는 코드·지시문·도구 Claude Code 자체 컨텍스트 계층 하네스 외부의 설정 가능한 지시문·스킬 CLAUDE.md, /skills 각 계층별 학습 방법 모델 계층 학습 — SFT, RL, GRPO 등 전통적 학습 기법 사 … --- ### LLM 코딩에 은탄환은 없다 — Fred Brooks의 프레임워크로 본 AI 코딩 도구의 현실 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/no-silver-bullet-for-llm-coding/ - Section: software - Date: 2026-04-11 - Description: Django 핵심 기여자 James Bennett가 Fred Brooks의 '은탄환은 없다' 프레임워크를 통해 LLM 코딩 도구의 효과를 이론적·실증적으로 분석한 글 요약. METR, DORA, CircleCI 등의 데이터가 보여주는 현실. - Tags: AI, LLM, 코딩, 생산성, 소프트웨어공학, 은탄환 - Frameworks: First Principles, Second-order thinking - Mental Models: Occam's Razor, Cost-Benefit Analysis Django 핵심 기여자인 James Bennett가 LLM 코딩 도구의 효과에 대해 이론적·실증적 근거를 들어 회의적 분석을 제시한 글입니다. 원문: LLMs 핵심 프레임워크: Fred Brooks의 “은탄환은 없다” (1975) 소프트웨어 개발의 어려움을 두 가지로 구분합니다: 우발적(accidental) 어려움 — 도구로 제거 가능 (수동 메모리 관리 등) 본질적(essential) 어려움 — 사양, 설계, 테스트 등 소프트웨어 자체에 내재된 것 Brooks의 핵심 통찰: “어려운 부분은 개념을 구축하는 것이지, 그것을 표현하는 노동이 아니다.” 우발적 어려움이 전체의 90% 이상이 아닌 한 10배 생산성 향상은 불가능하며, 실제 비율은 훨씬 낮다고 저자는 봅니다. --- ### AI의 능력 향상은 비용 하락이 아닌 작업 범위 확대로 나타났다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-capability-not-cost-reduction/ - Section: posts - Date: 2026-03-31 - Description: AI 모델의 능력 향상이 주로 추론 비용 절감에서 온 것이 아니라, 모델이 더 길고 복잡한 작업을 처리할 수 있게 된 것에서 비롯된다는 반직관적인 관점을 다룬다. - Tags: AI, 스케일링, 비용, 추론, 자동화, 경제성 - Frameworks: First Principles - Mental Models: Cost-Benefit Analysis AI 모델의 **능력(capability)**이 크게 향상된 것은 주로 **추론 비용(inference cost)**이 인간 노동 대비 더 저렴해졌기 때문이 아니라, 모델이 **더 길고 복잡한 작업(longer/harder tasks)**을 처리할 수 있게 되었기 때문이라는 점을 강조합니다. 능력 향상(예: METR의 frontier time horizons 기준으로 몇 달마다 배로 증가)은 관찰되지만, 이는 “같은 작업을 더 싸게 하는” 형태가 아닙니다. 오히려 추론 비용이 상승하는 경향을 보이는데, 이는 모델이 더 긴/어려운 작업을 수행하기 때문에 발생하는 자연스러운 현상입니다. (더 많은 compute/token을 소모) 현재 frontier 모델들은 50% 신뢰도(reliability) horizon에서 인간 비용의 약 3% 수준으로 작업을 수행하며, 이 비용 비율(인간 대비)은 능력 향상에도 크게 변하지 않고 있다는 데이터가 제시됩니다. 핵심 포인트 --- ### AI 에이전트의 미래는 이미 와 있지만, 아직 균등하게 퍼지지는 않았다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-agents-future-context-gap/ - Section: posts - Date: 2026-03-31 - Description: AI 에이전트의 미래에 대한 통찰. 테크 업계에서는 폭발적으로 성장 중인 코딩 에이전트와 달리, 일반 지식 노동자겐 아직 초기 단계. 가장 큰 장벽인 'Context Gap'을 분석하고 향후 기회를 제시한다. - Tags: AI, 에이전트, 자동화, 기업, 컨텍스트, MCP, RAG - Frameworks: First Principles - Mental Models: Pareto Principle AI 에이전트의 미래는 이미 와 있지만, 아직 균등하게 퍼지지 않았다 (William Gibson 인용). 테크 업계에서는 코딩 에이전트가 폭발적으로 성장 중. 긴 작업을 처리하고, 제품 전체를 에이전트로 만드는 사례가 속출. 모델 성능이 급격히 좋아지면서 코딩 분야가 가장 먼저 변하고 있음. 일반 지식 노동자 (비테크 기업 포함)에게는 아직 초기 단계. AI는 질문 답변·정보 검색 정도의 ‘도우미’ 역할에 그치고, 대규모 자동화·실제 업무 생산은 미미함. 그러나 현재 모델만으로도 화이트칼라 업무의 상당 부분을 바꿀 수 있고, 앞으로 2년 내 각 분야 전문가를 능가할 가능성이 매우 높음. 가장 큰 장벽 = Context Gap (맥락 부족) 에이전트가 제대로 일하려면 조직의 ‘집단 지식’이 AI에게 읽기 쉬운 형태로 제공되어야 하는데, 대부분 기업은 다음과 같은 문제로 어려움을 겪음: --- ### Model Collapse Is Already Happening, We Just Pretend It Isn't - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/model-collapse/ - Section: software - Date: 2026-03-29 - Description: AI 모델이 합성 데이터로 훈련될 때 발생하는 모델 붕괴가 이미 진행 중이며, 업계가 규모 확대 전략만으로 문제를 해결하려 한다고 비판합니다. - Tags: AI, ModelCollapse, 합성데이터, 데이터품질, LLM - Frameworks: Verification-first Engineering - Mental Models: Borrowed Confidence 출처: https://cacm.acm.org/blogcacm/model-collapse-is-already-happening-we-just-pretend-it-isnt/ 핵심 주장 AI 모델이 이전 모델의 출력(합성 데이터) 으로 훈련될 때 발생하는 모델 붕괴(model collapse) 가 이미 진행 중이며, AI 업계가 이를 인정하지 않고 “더 큰 모델, 더 많은 데이터, 더 많은 컴퓨트"라는 규모 확대 전략으로만 문제를 해결하려 한다고 비판합니다. 모델 붕괴(Model Collapse)란? AI 모델이 자신의 이전 버전(또는 다른 AI)이 생성한 합성 텍스트/데이터로 반복 학습할 때 발생하는 현상입니다. 원본 데이터에 있던 희귀하고 독특하며 놀라운 패턴 (분포의 꼬리 부분, long tail)이 점차 사라짐 모델 출력이 점점 평평하고 제네릭(generic) 해지며, 다양성이 급격히 줄어듦 결국 통계적 평균 으로 수렴하면서 현실성과 정보 밀도가 낮아짐 모델은 … --- ### LLM의 양자화(Quantization): 기초부터 실전까지 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/quantization-llm/ - Section: software - Date: 2026-03-29 - Description: LLM이 너무 커서 일반 PC에서 돌리기 어려운 문제를 해결하는 양자화 기법을 기초부터 설명합니다. 모델 크기를 줄이면서 성능을 최대한 유지하는 방법을 다룹니다. - Tags: AI, LLM, 양자화, Quantization, 로컬AI, llama.cpp - Frameworks: Verification-first Engineering, Quantization - Mental Models: Borrowed Confidence 출처: https://ngrok.com/blog/quantization 주요 주제 이 글은 대형 언어 모델(LLM)의 양자화(Quantization) 를 기초부터 자세히 설명합니다. LLM이 너무 커서 일반 PC나 노트북에서 돌리기 어려운 문제를 해결하기 위해, 모델 크기를 줄이면서도 성능을 최대한 유지하는 방법을 다룹니다. 독자가 로컬 환경에서 강력한 LLM을 실제로 실행할 수 있도록 돕는 것이 목적입니다. 왜 양자화가 중요한가? 최신 LLM은 수십억~수조 개의 매개변수(Weights) 를 가짐 → 예: 80B 모델 = 약 159GB (float32 기준) 1T(조) 매개변수 모델은 2TB RAM 이 필요해 단일 머신에서 거의 불가능 양자화로 모델을 4배 작게 , 최대 2배 빠르게 만들 수 있음 (정확도 손실은 5~10% 수준) 핵심 개념 양자화(Quantization) : 고정밀 부동소수점(float32 등)을 낮은 비트(8비트, 4비트 등)로 변환하는 손실 압축 기법 부동소수점 … --- ### software 팩토리: AI 코딩 에이전트가 개발 팀을 바꾸는 방식 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/the-software-factory/ - Section: software - Date: 2026-03-24 - Description: AI 코딩 에이전트를 활용해 'software 팩토리'를 구축하면, 개발자는 설계·검토에 집중하고 팀 규모는 줄며 출시 속도는 몇 시간 단위로 빨라진다. - Tags: AI, software팩토리, 코딩에이전트, 개발생산성, 팀빌딩 - Frameworks: Agent-native Development, Verification-first Engineering, Operational Excellence - Mental Models: Feedback Loop, Borrowed Confidence 출처: https://alexop.dev/posts/the-software-factory/ 핵심 메시지 AI 코딩 에이전트(Claude Code 등)를 활용해 “software 팩토리” 를 구축하면, 개발 팀의 작업 방식이 완전히 바뀐다. 개발자는 더 이상 코드를 직접 많이 작성하지 않고, 설계·아키텍처·검토·의사결정 에 집중한다. 결과적으로 팀 규모는 크게 줄고, 출시 속도는 몇 시간 단위로 빨라진다. 기존 방식 vs. software 팩토리 기존 방식 (Beer Commerce 예시) 12명 체크아웃 팀 한 기능(할인 코드 추가) 추가에 10~14일 소요 대부분 시간이 핸드오프(BA → PO → Dev → QA)와 커뮤니케이션에서 사라짐 실제 코딩 시간은 고작 2~3일 software 팩토리 방식 --- ### AI 시대에 대규모 software 팀의 역할 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/large-software-teams-ai-age/ - Section: software - Date: 2026-03-24 - Description: AI가 개발 생산성을 극적으로 높였지만, 대규모 팀이 완전히 사라지는 것은 아니다. 최소 팀 규모는 줄어들고, 팀을 구성하는 이유가 달라지고 있다. - Tags: AI, software팀, 팀빌딩, 스타트업, 개발생산성 - Frameworks: Systems Thinking, Verification-first Engineering, Operational Excellence - Mental Models: Pareto Principle 출처: https://andresmax.com/large-software-teams-ai-age/ 주요 논제 AI 시대에 대규모 software 팀의 역할이 크게 바뀌고 있다. AI가 개발 생산성을 극적으로 높여 5인 팀 이 2016년의 50인 팀 수준의 출력을 낼 수 있게 되었지만, 대규모 팀이 완전히 사라지는 것은 아니다. 대신 최소 팀 규모는 줄어들고 , 팀을 구성하는 이유(제품 사고, 시스템 복잡성, 조직적 필요)가 달라졌다. 1. 대규모 팀의 기존 문제점과 AI의 영향 과거(2016년) MVP 개발 시 보통 5~7명 (백엔드 23명, 프론트 12명, 디자이너 1명, PM 1명)이 필요했다. 2026년 현재 AI 활용 시 2~3명 (풀스택 엔지니어 12명 + 코딩 가능한 디자이너 + PM 01명)으로 압축 가능. AI가 개인 생산성을 40~60% 향상시킨다. 구체적 가속화 예시: 보일러플레이트 코드: 몇 시간 → 몇 분 (5~10배) 디버깅: 3060분 → 1015분 (2~4 … --- ### 15명의 엔지니어가 말하는 AI 보조 엔지니어링 실전 가이드 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/ai-assisted-engineering-15-engineers/ - Section: software - Date: 2026-03-24 - Description: 15명의 실전 엔지니어·엔지니어링 리더들이 실제로 사용 중인 AI 보조 엔지니어링 경험을 정리한 글이다. - Tags: AI, 엔지니어링, 생산성, 코드리뷰, 워크플로우 - Frameworks: Second-order thinking - Mental Models: Pareto Principle 이 뉴스레터는 15명의 실전 엔지니어·엔지니어링 리더 들이 실제로 사용 중인 AI 보조 엔지니어링(AI-Assisted Engineering) 경험을 모아 정리한 글이다. 스타트업부터 대기업까지 다양한 규모와 배경의 사람들이 공유한다. 원문: How to Do AI-Assisted Engineering 핵심 메시지 AI는 생산성을 크게 높여 주지만, 단순히 “AI한테 코드 짜라고 시키면 끝"이 아니다. 엄격한 설계 + AI 구현 + 공격적인 리뷰 + 반복 이 핵심 공식이며, 인간의 판단과 감독 을 절대 빼놓을 수 없다는 점을 모든 기고자가 강조한다. 주요 워크플로우 패턴 (공통점) 아이데이션 / 설계 단계 (가장 중요) --- ### 분산된 지능에서 검증 가능한 책임으로: Vint Cerf의 인터넷 아키텍처 제안 - URL: https://hugo-blog-static-site.haxlys.workers.dev/posts/from-distributed-intelligence-to-verifiable-responsibility/ - Section: posts - Date: 2026-03-21 - Description: AI가 분산화되는 속도가 신뢰/책임 메커니즘보다 훨씬 빠른 현재, '검증 가능한 책임'을 인터넷 아키텍처 수준에서 설계해야 한다는 Vint Cerf의 논지를 정리합니다. - Tags: AI, 분산시스템, 인터넷아키텍처, 신뢰, 책임, VintCerf - Frameworks: First Principles - Mental Models: Borrowed Confidence 이 글은 2026년 3월 18일경 BLOG@CACM에 게시된 것으로, 저자는 Mallik Tatipamula , David Attermann , 그리고 인터넷의 아버지로 불리는 Vinton G. Cerf (Vint Cerf)입니다. 핵심 논지 AI와 지능이 빠르게 분산화(distributed)되고 있는 현재 상황에서, 신뢰(trust) 와 책임(responsibility) 는 여전히 중앙화된 전통적 모델(특정 조직·인간 감독)에 의존하고 있어 심각한 불일치가 발생하고 있다. → 지능 분산 속도 » 신뢰/책임 메커니즘 발전 속도 따라서 “검증 가능한 책임(verifiable responsibility)” 또는 “검증 가능한 분산 신뢰(verifiable distributed trust)” 를 인터넷 아키텍처 수준에서 근본적으로 설계해야 한다는 주장을 펼칩니다. --- ### 새로운 AI 시대, 진짜 희소 자원은 연구자 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/ai-era-researchers-not-engineers/ - Section: software - Date: 2026-03-11 - Description: AI가 공학적 실행을 빠르게 대체하는 시대일수록, 무엇을 시도하고 무엇을 포기할지 판단하는 연구자의 'taste'가 핵심 자산이 된다는 시사점을 정리 - Tags: ai, research, engineering, career, decision-making - Frameworks: Total Cost of Ownership, Agent-native Development, Verification-first Engineering - Mental Models: Bottleneck Analysis, Hidden Costs, Trade-off Analysis 새로운 AI 시대의 가장 중요한 인재는 엔지니어가 아니라 연구자 입니다. 누구나 AI로 “무료로 만들 수 있는” 시대가 되면, 진짜 차별점은 “무엇을 만들 가치가 있는가? 과연 만들 수 있는가?” 를 판단하는 능력이다. 연구자는 해결책이 없을 수도 있는 문제를 붙잡고, “이 베팅에 목숨 걸 만한가?” 를 결정하는 사람들입니다. 시장도 이미 이 사실을 반영하고 있다 퀀트 펌들은 포트폴리오 한 번 관리해 본 적 없는 학부생에게 $600k 를 준다. AI 랩(Meta Superintelligence Labs 등)은 연구자 한 명에게 4년간 $3억 까지 제안한다. → 한 번의 학습 비용이 수억 달러인데, 데이터 효율을 1~2%만 올려도 그 연구자가 수십 배로 돈을 벌어줍니다. 왜 연구는 자동화하기 어려운가? --- ### 진흙으로 만든 부가티: AI 시대의 엔지니어링 환상 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/illusion-of-building/ - Section: software - Date: 2026-03-08 - Description: AI의 발전으로 누구나 소프트웨어를 쉽게 만드는 것처럼 보이지만, 실제 제품을 구축하는 것과 시스템을 엔지니어링하는 사이에는 거대한 간극이 존재합니다. - Tags: ai, software-engineering, philosophy, technology - Frameworks: First Principles - Mental Models: Entropy 이 글은 AI의 발전으로 누구나 소프트웨어를 쉽게 ‘만드는 것’처럼 보이지만, 실제 **‘제품을 구축하는 것’**과 ‘시스템을 엔지니어링하는 것’ 사이에는 거대한 간극이 존재함을 지적합니다. 원문/참고 링크: https://uphack.io/blog/post/the-illusion-of-building 1. 진흙으로 만든 부가티 (The Clay Bugatti) 최근 “코딩 경험 없이 앱을 만들었다”, “주말 만에 스포티파이를 복제했다"는 식의 글들이 넘쳐납니다. 하지만 이는 베트남의 유튜버들이 진흙으로 부가티 모양을 빚어낸 것과 비슷합니다. 겉모습은 똑같지만, 시속 400km로 달려도 안전하게 설계된 실제 부가기의 ‘엔지니어링’은 전혀 들어있지 않습니다. 개발의 환상이란, 작동하는 것처럼 보이는 소프트웨어를 만드는 것이 실제로 작동하는 소프트웨어를 엔지니어 … --- ### 오픈 소스 LLM 아키텍처의 구조와 전략 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/open-source-llm-architecture/ - Section: software - Date: 2026-03-04 - Description: 주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략 분석 - Tags: llm, ai, architecture, opensource, transformer - Frameworks: Total Cost of Ownership, Context Management - Mental Models: Trade-off Analysis 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 분석합니다. 출처: https://blog.bytebytego.com/p/the-architecture-behind-open-source 이 글은 주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 다루고 있습니다. 주요 내용은 다음과 같습니다. 1. 핵심 아키텍처: Transformer 대부분의 오픈 소스 LLM은 Transformer 아키텍처를 기반으로 합니다. 하지만 효율성을 높이기 위해 오리지널 구조에서 몇 가지 변형을 가합니다. Decoder-only 구조: GPT 시리즈와 마찬가지로 대부분의 오픈 소스 모델(Llama, Mistral 등)은 다음 단어를 예측하는 데 최적화된 디코더 전용 구조를 채택합니다. 2. 주요 최적화 기술 성능과 효율성을 잡기 위해 사용되는 대표적인 기술들입니다. --- ### 컴파운드 엔지니어링: AI 에이전트 개발의 복리 루프 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/compound-engineering/ - Section: software - Date: 2026-02-19 - Description: Every의 Compound Engineering 가이드를 바탕으로, AI 에이전트 시대의 복리형 개발 루프와 핵심 원칙을 정리합니다. - Tags: AI, AI 에이전트, 소프트웨어 엔지니어링, 컴파운드 엔지니어링, 개발 생산성 - Frameworks: Compound Engineering, Agent-native Development - Mental Models: Compounding, Systems Thinking 출처: https://every.to/guides/compound-engineering Every의 가이드 “Compound Engineering” 은 AI 에이전트를 활용한 새로운 소프트웨어 개발 패러다임을 설명하고 있습니다. 핵심은 “전통적인 개발은 코드가 쌓일수록 복잡해져 속도가 느려지지만, 컴파운드 엔지니어링은 할수록 다음 작업이 더 쉬워지고 빨라진다” 는 것입니다. 1. 핵심 철학 (The Philosophy) 복리 효과(Compounding): 모든 단위 작업(코드, 문서, 툴링)이 다음 작업을 더 쉽게 만들어야 합니다. 시스템에 ‘취향’ 반영: 코드 리뷰 시 매번 수동으로 수정하는 대신, 설정·스키마·자동 검사 도구에 판단 기준을 녹여내어 시스템 자체가 학습하게 합니다. 직접 하기보다 가르치기: 코드를 직접 타이핑하는 시간보다 AI 에이전트에게 더 많은 컨텍스트를 제공하는 데 시간을 투자합니다. 2. 4단계 … --- ### Bias Toward Action: 실패 비용을 낮추는 행동 지향적 태도 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/bias-toward-action/ - Section: software - Date: 2026-02-19 - Description: Addy Osmani의 글 'Bias Toward Action' 핵심을 바탕으로, 실패 비용을 통제하며 빠르게 학습하는 실행 시스템의 원칙을 정리합니다. - Tags: Addy Osmani, Bias Toward Action, 실행, 의사결정, 엔지니어링 - Frameworks: Two-way doors vs One-way doors, Error Budget - Mental Models: Reversible Decisions, Blast Radius 출처: https://addyosmani.com/blog/bias-towards-action/ 이 글에서 저자는 “행동 지향성"이 단순히 무모하게 빨리 움직이는 것이 아니라, 학습 속도를 높이되 실패해도 치명적이지 않은 시스템을 구축하는 것 이라고 강조합니다. 1. 핵심 개념: “실행 가능한 최소한의 단계” 정의: 행동 지향성이란 실제 피드백을 얻을 수 있는 가장 작고 책임감 있는 단계 를 기본값으로 설정하는 것입니다. 오해: 단순히 스타트업 창업자가 소리치는 무모한 구호가 아닙니다. 제대로 된 행동 지향성은 “내가 틀렸을 때 어떻게 회복할지"를 정확히 아는 상태에서 움직이는 것입니다. 2. 가드레일(안전장치)의 중요성 빠르게 움직이는 팀은 단순히 속도가 빠른 것이 아니라, 실패해도 죽지 않는 시스템을 갖추고 있습니다. --- ### 컨텍스트 관리와 MCP: CLI와의 논쟁을 넘어서 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/context-management-and-mcp/ - Section: software - Date: 2026-02-04 - Description: Sentry 창립자 David Cramer가 제안하는 LLM 조종(Steering)과 서브에이전트 중심의 컨텍스트 관리 전략. - Tags: MCP, LLM, Context Management, AI Agents - Frameworks: Total Cost of Ownership, Agent-native Development, Context Management 출처: https://cra.mr/context-management-and-mcp/ 이 글은 Sentry의 창립자인 David Cramer가 작성한 것으로, 최근 개발자들 사이에서 벌어지는 “MCP(Model Context Protocol)냐 CLI(명령줄 인터페이스)냐” 의 논쟁이 본질을 벗어난 것임을 지적하며 ‘컨텍스트 관리와 조종(Steering)’ 의 중요성을 강조하고 있습니다. 1. MCP vs CLI 논쟁의 핵심 잘못된 비교: 많은 사람들이 CLI가 나왔으니 MCP를 쓸 필요가 없다고 말하지만, 이는 LLM이 컨텍스트를 어떻게 처리하는지 이해하지 못한 결과입니다. MCP의 진정한 가치: MCP는 단순한 API 프록시가 아니라, LLM이 도구를 더 정확하게 사용하도록 ‘조종(Steering)’ 하는 데 최적화되어 있습니다. MCP는 마크다운, XML 구조, 힌트 등을 활용해 모델이 이해하기 쉬운 형태로 정보를 … --- ### 인터페이스의 혁명: 채팅이 모든 것을 삼킨다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/chat-is-going-to-eat-the-world/ - Section: software - Date: 2026-02-03 - Description: 채팅이 GUI를 대체하는 기본 인터페이스로 부상하며, 개별 앱의 시대가 저물고 AI 에이전트 중심의 컴퓨팅 패러다임으로 이동하는 변화를 정리합니다. - Tags: AI, 채팅, 인터페이스, 에이전트, 앱 - Frameworks: Agent-native Development, Operational Excellence, Context Management 출처: https://deadneurons.substack.com/p/chat-is-going-to-eat-the-world 1. 인터페이스의 혁명: 채팅이 모든 것을 삼킨다 과거 소프트웨어는 복잡한 메뉴와 버튼으로 구성된 GUI(그래픽 사용자 인터페이스) 중심이었습니다. 하지만 이제 ‘채팅’은 단순한 기능이 아니라, 사용자가 컴퓨터와 상호작용하는 기본 운영 체제(OS) 가 되고 있습니다. 마크 안드레센이 “소프트웨어가 세상을 먹어치운다"고 했듯, 이제는 “채팅이 소프트웨어를 먹어치우고” 있습니다. 2. ‘앱’의 종말과 ‘에이전트’의 시대 사용자는 더 이상 특정 목적을 위해 개별 앱을 찾아다니거나 복잡한 사용법을 익힐 필요가 없습니다. 대신 자연어로 요청하면 AI 에이전트가 뒤에서 필요한 도구와 데이터를 호출해 결과를 가져다줍니다. 이로 인해 기존의 수많은 개별 앱과 웹사이트의 … --- ### 에이전틱 코딩의 80% 문제 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/the-80-problem-in-agentic-coding/ - Section: software - Date: 2026-01-29 - Description: AI 코딩 에이전트가 빠르게 80%를 만들고도 나머지 20%에서 막히는 이유(맥락·검증·루프)와 이를 넘기 위한 협업·테스트·작업 분할 제언을 정리합니다. - Tags: AI, 에이전트, 코딩, Agentic coding, 80% 문제, 테스트 자동화, 협업 - Frameworks: Agentic Workflow, Test Automation - Mental Models: Pareto Principle 출처: https://addyo.substack.com/p/the-80-problem-in-agentic-coding 1. 80% 문제란 무엇인가? 초기 성과(80%)의 함정 : AI 에이전트는 복잡한 코드 작성, 라이브러리 선택, 기본 구조 설계 등 작업의 80%를 순식간에 해냅니다. 하지만 이는 사용자에게 “거의 다 끝났다"는 착각을 줍니다. 나머지 20%의 난이도 : 실제 배포 가능한 수준으로 만드는 나머지 20%(엣지 케이스 처리, 기존 코드와의 완벽한 통합, 보안 및 성능 최적화 등)는 훨씬 더 어렵고 시간이 많이 걸립니다. 2. 왜 이런 문제가 발생하는가? 맥락 파악의 한계 : 에이전트가 전체 코드베이스의 비즈니스 로직이나 사소한 종속성을 완벽히 이해하지 못해 “그럴듯하지만 틀린” 코드를 생성할 때가 많습니다. 검증의 어려움 : AI가 짠 코드를 검토하는 것이 사람이 처음부터 짜는 것보다 더 많은 인지적 에너지를 소모할 수 있습니다 … --- ### The future of software engineering is SRE - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/the-future-of-software-engineering-is-sre/ - Section: software - Date: 2026-01-27 - Description: 코드 작성이 저렴해지면서 운영 우수성이 승리한다. 누구나 그린필드 데모를 만들 수 있지만, 서비스를 운영하는 것은 엔지니어링이 필요하다. - Tags: SRE, 소프트웨어 엔지니어링, 운영, DevOps, 엔지니어링 - Frameworks: Operational Excellence - Mental Models: The Computer Disease AI(LLM)와 노코드 툴의 발전으로 코드 작성 비용이 0에 수렴하는 시대에, 소프트웨어 엔지니어링의 미래는 무엇일까? 출처: The future of software engineering is SRE - Swizec Teller 1. 핵심 요지: “코드가 저렴해질수록 운영 능력이 승리한다” AI(LLM)와 노코드 툴의 발전으로 코드를 작성하는 비용은 0에 수렴하고 있습니다. 누구나 작동하는 데모(Greenfield demo)는 만들 수 있는 시대가 되었지만, 그 서비스를 안정적으로 ‘운영’하는 것 은 여전히 어렵고 중요한 문제라는 것이 글의 핵심입니다. 2. 소프트웨어 엔지니어링의 정의: “시간 위의 프로그래밍” 저자는 프로그래밍과 소프트웨어 엔지니어링을 구분합니다. --- ### Unrolling the Codex Agent Loop - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/unrolling-the-codex-agent-loop/ - Section: software - Date: 2026-01-27 - Description: OpenAI Codex 에이전트의 내부 동작 원리와 에이전트 루프, 프롬프트 구성, 성능 최적화 방법을 분석한 기술 블로그 글 요약 - Tags: Codex, AI 에이전트, 에이전트 루프, 프롬프트 캐싱, OpenAI, prompt cache miss - Frameworks: Agent Loop, Prompt Caching - Mental Models: Execution through Reasoning OpenAI에서 발표한 “Unrolling the Codex Agent Loop” 는 AI 에이전트인 Codex가 사용자 요청을 처리하기 위해 내부적으로 어떻게 동작하는지(에이전트 루프)를 심층 분석한 기술 블로그 글입니다. 출처: Unrolling the Codex Agent Loop - OpenAI 1. 에이전트 루프 (The Agent Loop) AI 에이전트의 핵심은 모델 자체가 아니라, 모델과 도구를 연결하는 ‘루프(순환 구조)’ 에 있습니다. 프로세스: 사용자 입력 → 프롬프트 구성 → 모델 추론(Inference) → 도구 호출(Tool Call) → 실행 결과 반영 → 재추론 → 최종 응답. 특징: 하나의 질문(Turn)에 대해 모델은 단순히 답변만 하는 것이 아니라, 수십에서 수백 번의 도구 호출(파일 읽기, 셸 명령어 실행 등)을 반복하며 스스로 문제를 해결합니다. 2. 프롬프트 구성 방식 Codex는 사용자의 입력을 그대 … --- ### 에이전트 규칙·기술·명령: 무엇을 언제 써야 할까 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/agent-skills-rules-commands/ - Section: software - Date: 2026-01-27 - Description: Builder.io 블로그를 바탕으로, AI 에이전트에서 규칙(Rules), 기술(Skills), 명령(Commands)의 차이와 언제 무엇을 사용할지에 대한 결정 기준을 정리합니다. - Tags: AI, 에이전트, 규칙, 기술, 명령, Rules, Skills, Commands - Frameworks: Progressive Disclosure, Lazy loading - Mental Models: Separation of concerns, Context efficiency AI 에이전트를 설계할 때 규칙(Rules), 기술(Skills), 명령(Commands) 을 어떻게 구분하고 사용할지가 핵심입니다. Builder.io 블로그 글을 바탕으로 세 개념의 정의, 사용 시점, 그리고 효과적인 기술 작성 방법을 정리했습니다. 원문: Agent skills, rules, and commands 1. 핵심 개념 정의 규칙 (Rules): 예외 없이 항상 적용되는 원칙입니다. (예: “절대 .env 파일을 커밋하지 마라”, “명명 규칙 준수”) 기술 (Skills): 특정 작업 시에만 불러오는 선택적 전문 지식입니다. 에이전트가 필요할 때만 ‘지연 로딩(Lazy loading)‘하여 컨텍스트 낭비를 줄입니다. (예: “UI 변경 시 체크리스트”, “배포 가이드”) 명령 (Commands): 사용자가 직접 실행하는 반복 가능한 워크플로우입니다. (예: … --- ### LLM과 현실적으로 마주하기: 실무 중심의 AI 활용 매트릭스 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/getting-real-with-llms/ - Section: software - Date: 2026-01-26 - Description: 작업의 복잡도와 부작용(Side-effects)이라는 두 축으로 AI의 유용성을 정의하고, 현재 LLM이 실제로 도움이 되는 영역과 단순히 '연기(Smoke & Mirrors)'에 불과한 영역을 구분하는 실무 중심의 분석. - Tags: LLM, AI, 엔지니어링, 프로덕션, 실무, 매트릭스 - Frameworks: 2x2 Matrix, Closed-loop vs Open-loop - Mental Models: Goodhart's Law, Blast Radius 보내주신 글은 현직 개발자와 관리자가 느끼는 “AI 환상(Hype)과 실제 업무 사이의 괴리” 를 아주 날카롭게 짚고 있습니다. 특히 단순한 성능 지표가 아닌, 작업의 복잡도 와 부작용(Side-effects) 이라는 두 축으로 AI의 유용성을 정의한 점이 매우 인상적입니다. 출처: Getting Real With LLMs - Gilad Peleg 🚀 실무 중심의 AI 활용 매트릭스 이 글은 엔지니어링 업무를 복잡도(X축) 와 부작용/파급력(Y축) 으로 나누어, 현재 LLM이 실제로 도움이 되는 영역과 단순히 “연기(Smoke & Mirrors)“에 불과한 영역을 구분합니다. --- ### MCP(Model Context Protocol) 베스트 프랙티스: AI 에이전트를 위한 UI 설계 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/mcp-best-practices/ - Section: software - Date: 2026-01-23 - Description: MCP는 REST API의 연장선이 아니라 AI 에이전트를 위한 사용자 인터페이스(UI)로 설계되어야 한다는 관점에서 6가지 베스트 프랙티스를 정리한 글. - Tags: MCP, AI, 에이전트, Model Context Protocol, 베스트 프랙티스 - Frameworks: Outcomes-over-operations, Agent-first-design - Mental Models: UI-for-AI, Minimal-calls MCP(Model Context Protocol) 서버를 설계할 때는 인프라가 아니라 “AI 에이전트를 위한 UI” 를 만든다는 관점이 핵심입니다. 출처: MCP Best Practices 이 글의 핵심은 “MCP(Model Context Protocol)는 REST API의 연장선이 아니라, AI 에이전트를 위한 사용자 인터페이스(UI)로 설계되어야 한다” 는 것입니다. 1. MCP란 무엇인가? 정의: LLM과 외부 도구, 데이터 소스, 서비스를 연결하는 표준 프로토콜. 핵심 요소: 도구(Tools, 실행 기능), 리소스(Resources, 읽기 전용 데이터), 프롬프트(Prompts, 사전 정의된 워크플로우). 오해: MCP는 단순한 REST API 래퍼가 아닙니다. 개발자가 아닌 ‘AI 에이전트’가 사용자임을 인식해야 합니다. 2. MCP 서버 구축을 위한 6가지 베스트 프랙티스 ① 운영(Operations)이 아 … --- ### Claude Code 인사이트: 도구보다 '무엇을 할 것인가'가 중요하다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/claude-code-purpose-over-tool/ - Section: software - Date: 2026-01-23 - Description: Zvi Mowshowitz의 Claude Code 사용기 3편. 도구 최적화에만 몰두하기보다, '오늘 내가 해야 할 가장 중요한 일'을 스스로 묻고 실행에 옮기는 것이 더 중요하다는 인사이트. - Tags: AI, Claude Code, 코딩 에이전트, 생산성, Anthropic, 목표 - Frameworks: Purpose-over-tool, Execution-first - Mental Models: First Principles, Priority clarity 이 글은 Zvi Mowshowitz가 ‘Claude Code’(Anthropic이 출시한 CLI 기반 코딩 에이전트 도구)를 사용하며 겪은 경험과 그 과정에서 얻은 인사이트를 다루는 시리즈의 세 번째 게시물입니다. 원문: Claude Codes 3 1. 도구 자체보다 ‘무엇을 할 것인가’가 중요 설정의 함정: 많은 사용자들이 자신의 작업 환경을 개선하거나 도구를 최적화하는 데 너무 많은 시간을 할애하지만, 정작 ‘실제로 유용한 일’을 하는 데는 소홀해지는 경향이 있음을 지적합니다. 실행의 어려움: Claude Code를 이용해 개인용 작업 관리 시스템(Task Management System)을 만드는 것은 단 몇 시간 만에 가능할 정도로 쉽지만, 가장 어려운 부분은 여전히 “오늘 내가 해야 할 가장 중요한 일은 무엇인가?“라고 스스로 묻고 실행에 옮기는 것이라고 강조합니다. 2. Claude … --- ### 에이전트 정신병: 우리는 미쳐가고 있는가? - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/agent-psychosis/ - Section: software - Date: 2026-01-18 - Description: AI 에이전트 코딩에 중독된 개발자들의 현실과 코드 품질 저하, 메인테이너의 부담에 대한 Armin Ronacher의 날카로운 관찰과 경고. - Tags: AI, 에이전트, 코딩, 생산성, 품질, 중독, 메인테이너 - Frameworks: Quality-over-speed, Technical-debt-management - Mental Models: Second-order thinking, Long-term thinking 많은 개발자가 AI 에이전트를 이용한 코딩에 중독되어 있습니다. 잠도 자지 않고 수많은 에이전트 세션을 동시에 돌리며 무언가를 계속 만들어내는데, 본인은 스스로가 “유례없이 생산적"이라고 느끼지만, 제삼자가 보기에는 마치 일종의 ‘정신병적 상태(Psychosis)‘처럼 보일 정도로 기계에 매몰되어 있다는 지적입니다. 원문: Agent Psychosis: Are We Going Insane? 1. 에이전트 중독과 ‘생산성 환상’ 많은 개발자가 AI 에이전트를 이용한 코딩에 중독되어 있습니다. 잠도 자지 않고 수많은 에이전트 세션을 동시에 돌리며 무언가를 계속 만들어내는데, 본인은 스스로가 “유례없이 생산적"이라고 느끼지만, 제삼자가 보기에는 마치 일종의 ‘정신병적 상태(Psychosis)‘처럼 보일 정도로 기계에 매몰되어 있습니다. --- ### AI가 코드를 짜줘도 왜 성과는 그대로인가? - 거대한 필터(The Great Filter) - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/the-great-filter-ai-productivity/ - Section: software - Date: 2026-01-14 - Description: AI 코딩 도구가 보급된 지 3년이 넘었지만 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는 근본적인 원인을 '거대한 필터' 개념으로 설명합니다. - Tags: AI, 개발 생산성, 조직 역량, DORA, 병목 현상 - Frameworks: Bottleneck Analysis, Continuous Delivery - Mental Models: Second-order Effects, JIT (Just-In-Time) AI 보조 도구가 등장했음에도 불구하고 왜 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는지, 그 근본적인 원인을 ‘거대한 필터(The Great Filter)’ 라는 개념으로 설명하는 글입니다. 원문: The Great Filter, or Why High Performance Still Eludes Most Dev Teams Even With AI 주요 내용 1. AI 생산성 역설 (The Gorman Paradox) AI 코딩 도구가 보급된 지 3년이 넘었지만, 앱 스토어의 제품 출시가 폭증하거나 기업의 이익, 국가 GDP가 눈에 띄게 상승하는 현상은 나타나지 않고 있습니다. AI는 분명 ‘코드’를 더 많이 만들어내지만, 대다수 팀에게 그것이 ‘순 가치’의 증가로 이어지지 않고 있습니다. 2. 고성과 팀과 저성과 팀의 차이 --- ### 엔지니어란 무엇인가? - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/what-is-an-engineer/ - Section: software - Date: 2026-01-14 - Description: 맥스 카낫-알렉산더(Max Kanat-Alexander)의 'What is an Engineer?'를 통해 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 고찰합니다. - Tags: 엔지니어링, AI, 소프트웨어 개발, 전문성 - Frameworks: First Principles - Mental Models: Domain Expertise 맥스 카낫-알렉산더(Max Kanat-Alexander)의 블로그 포스트 “What is an Engineer?” 는 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 깊이 있게 고찰한 글입니다. 원문: What is an Engineer? 맥스 카낫-알렉산더(Max Kanat-Alexander)의 블로그 포스트 “What is an Engineer?” 는 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 깊이 있게 고찰한 글입니다. 주요 내용은 다음과 같습니다. 1. 엔지니어링의 정의 저자는 사전적 정의(엔진이나 기계를 설계하는 일 등)가 현대의 소프트웨어 개발이나 AI 시대를 설명하기엔 부족하다고 지적하며, 자신만의 명쾌한 정의를 제시합니다. --- ### 로깅이 당신에게 거짓말을 하고 있다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/logging-lies-to-you/ - Section: software - Date: 2026-01-11 - Description: 단일 서버 시대의 로깅 방식이 분산 시스템에서는 왜 실패하는지, 그리고 Wide Events를 통한 해결책을 제시한다. - Tags: 로깅, 관찰가능성, 분산시스템, wide-events, observability - Frameworks: System Design, Observability - Mental Models: Context is King, Queryable Database 이 게시물은 분산 시스템 환경에서 전통적인 로깅 방식의 한계와, Wide Events(또는 Canonical Log Lines)를 통한 효과적인 관찰가능성(Observability) 개선 방안을 다룬다. 원문: Logging Sucks 1. 핵심 문제: “로그가 당신에게 거짓말을 하고 있다” 시대의 변화: 과거의 로깅 방식은 단일 서버(Monolith) 시대에 맞춰 설계됐다. 하지만 현재는 수많은 서비스와 DB, 캐시가 얽힌 분산 시스템이다. 쓰기 위주의 최적화: 개발자들은 로그를 남기기(Write)는 쉽게 하지만, 정작 문제가 생겨 검색(Query)할 때는 수만 줄의 파편화된 로그 속에서 의미 있는 정보를 찾기 매우 어렵다. 맥락 부족: 단순히 “사용자 123의 결제 실패"라는 텍스트 로그만으로는 왜 실패했는지, 당시의 세부 상황(DB 상태, 이전 단계 등)을 파악하기 어렵다. 2. 제안하는 해결책: Wide Events (또는 … --- ### 잘못된 최적화의 함정: 기술적 정답과 실제 유용성의 괴리 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/wrong-optimization-trap/ - Section: software - Date: 2026-01-09 - Description: 슈퍼마켓 바닥 청소 최적화 경험을 통해 본, 잘못된 지표를 최적화할 때 발생하는 문제와 현대 시스템의 최적화 오류에 대한 성찰이다. - Tags: 최적화, 알고리즘, 시스템 설계, AI, LLM - Frameworks: Cost-Benefit Analysis, System Design - Mental Models: Second-order Effects, Bottleneck Analysis 이 글은 슈퍼마켓에서 최소 임금을 받으며 일하던 시절, 바닥 청소 경로를 최적화하려다 깨달은 “잘못된 지표를 최적화하면 기술적으로는 완벽해 보여도 실제로는 쓸모없거나 해로운 결과를 낳는다” 는 교훈을 담는다. 원문: I Got Paid Minimum Wage to Solve 1. 문제의 시작: 단순한 작업의 복잡화 작성자는 슈퍼마켓 바닥을 쓸면서 “어떻게 하면 가장 적게 걷고도 모든 바닥을 다 쓸 수 있을까?“라는 의문을 갖게 된다. 이를 해결하기 위해 매장 내부를 그리드 그래프(Grid Graph)로 변환하고, 시뮬레이티드 어닐링(Simulated Annealing) 알고리즘을 사용해 최단 경로를 찾는 C++ 프로그램을 작성한다. 2. 알고리즘의 한계: ‘기술적 정답’과 ‘실제 유용성’의 괴리 알고리즘은 수학적으로 완벽한 최단 경로를 찾아낸다. 하지만 그 결과는 사람이 도저히 따라 할 수 없는 … --- ### 기술적 부채와 엔지니어링 생산성: Paul Dix의 견해 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/technical-debt-engineering-productivity/ - Section: software - Date: 2026-01-08 - Description: InfluxData 창업자 Paul Dix가 제시하는 기술적 부채 관리의 중요성과 엔지니어링 팀 생산성 향상을 위한 전략을 정리한다. - Tags: 기술적 부채, 엔지니어링, 생산성, 개발 문화 - Frameworks: Technical Debt Management, Quality over Speed - Mental Models: Long-term Thinking, Compound Interest 이 게시물에서 인플럭스데이터(InfluxData)의 창업자인 폴 딕스(Paul Dix)는 엔지니어링 팀의 생산성과 기술적 부채(Tech Debt) 에 대한 자신의 견해를 공유한다. 원문: Paul Dix on X 핵심 내용 기술적 부채의 위험성: 폴 딕스는 많은 팀들이 ‘기능 개발’에만 급급한 나머지 기술적 부채를 방치하고 있으며, 이것이 결국 팀의 발목을 잡는다고 경고한다. 생산성 저하: 부채가 쌓이면 코드 베이스가 복잡해지고 수정이 어려워져, 결과적으로 새로운 기능을 출시하는 속도가 기하급수적으로 느려지게 된다. 해결을 위한 제안: 단순히 기능을 추가하는 것보다 시스템을 단순화하고 유지보수 가능한 구조로 만드는 것에 우선순위를 두어야 한다. 엔지니어들이 코드의 품질을 개선하고 리팩토링할 수 있는 충분한 시간을 확보해 주는 문화가 필수적이다. 장기 관점: 장기적인 성공을 위해서는 “더 많이 만드는 것"보다 “제대로 만드는 것 … --- ### Gross Profit per Token - URL: https://hugo-blog-static-site.haxlys.workers.dev/investments/gross-profit-per-token-analysis/ - Section: investments - Date: 2026-01-08 - Description: AI 추론 회사 6곳(DeepSeek·Together AI·Manus·Anthropic·Groq·Perplexity)의 토큰당 총이익(GP)과 밸류에이션 간 상관관계를 분석한다. GP 배수는 20x~222x까지 분포하며, GP per Token과 밸류에이션의 상관계수는 0.70(R²=48.5%)으로 원시 토큰 볼륨(0.47)보다 1.5배 높다. - Tags: AI, 투자, 밸류에이션, 토큰, 수익성, GP배수 - Frameworks: Cost-benefit analysis - Mental Models: Pattern recognition Meta가 Manus를 25억 달러에 인수했습니다. 이번 인수 발표와 함께 Manus는 출시 후 8개월 만에 1억 달러의 ARR(연간 반복 수익)을 달성했으며, 출시 이후 147조 개의 토큰을 처리했다고 공개했습니다. 이러한 수치들을 사용하여 인수 가격을 설명할 수 있을까요? 공개 거래되는 소프트웨어 회사들은 71-72%의 총이익률(Gross Margin)을 보입니다. AI 회사들은 더 낮은 수준입니다. 토큰당 총이익(Gross Profit per Token)이 수익 잠재력을 더 잘 나타내는 지표일 수 있습니다. 일부 AI 회사들은 이미 매출 대신 총이익을 할당량 지표로 사용하고 있습니다. --- ### 바이브 코딩과 시스템 설계: AI 시대의 함정 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/vibe-coding-system-design-trap/ - Section: software - Date: 2026-01-08 - Description: AI 도구를 활용한 바이브 코딩의 빠른 속도 뒤에 숨겨진 시스템 설계 부재의 위험성을 경고하고, 지속 가능한 소프트웨어 개발을 위한 시스템 사고의 중요성을 다룬다. - Tags: ai, 개발, 시스템-설계, 엔지니어링, 개발-문화, ai-활용 - Frameworks: System Design, Technical Debt Management - Mental Models: Long-term Thinking, Second-order Effects 이 글은 최근 AI 도구(Cursor, Replit 등)를 활용해 코드를 빠르게 짜는 이른바 ‘바이브 코딩(Vibe Coding)’ 열풍 속에 숨겨진 위험성을 경고한다. 원문: Vibe Coding Without System Design is a Trap 1. 바이브 코딩(Vibe Coding)의 함정 정의: 정밀한 설계나 구조에 대한 고민 없이, AI에게 자연어로 지시하며 “느낌대로(vibe)” 결과물을 빠르게 만들어내는 방식이다. 문제점: 초기 데모나 프로토타입을 만드는 속도는 매우 빠르지만, 시스템 설계(System Design)가 결여되어 있어 실제 서비스화(Production) 단계에서 큰 벽에 부딪히게 된다. 2. ‘운영의 벽(The Operational Wall)’ 글쓴이는 프로토타입과 실제 제품 사이에는 거대한 간극이 존재한다고 강조한다. AI는 다음의 요소들을 자동으로 해결해 주지 않는다. --- ### AI는 탐색을 저렴하게 만들지만, 판단은 쉽게 만들지 않는다 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/ai-cheap-exploration-human-judgment/ - Section: software - Date: 2026-01-08 - Description: AI는 시도(탐색)의 비용을 획기적으로 낮춰주지만, 최종적인 판단(의사결정)의 책임은 여전히 인간에게 있다는 것을 다룹니다. - Tags: AI, 의사결정, 판단력, 탐색, 생산성 - Frameworks: Decision-making - Mental Models: Second-order thinking AI가 우리의 작업 방식을 어떻게 바꾸고 있는지에 대한 중요한 통찰을 다룹니다. AI는 탐색(Exploration)의 비용을 획기적으로 낮춰주지만, 최종적인 판단(Judgment)의 책임은 여전히 인간에게 있다는 것이 이 글의 핵심입니다. 원문: AI Makes Exploration Cheap, Not Decisions Easy 1. AI의 역할: 탐색의 비용 절감 과거에는 새로운 아이디어를 시도하려면 막대한 시간과 비용이 들었습니다. 하지만 AI는 이 탐색(Exploration) 과정을 비약적으로 단축시킵니다. 수일이 걸리던 프로토타이핑을 단 몇 시간 만에 해결합니다. 실패해도 손실이 거의 없는 ‘마법의 원(Magic Circle)’ 안에서 마음껏 실험할 수 있게 해줍니다. **“실패하는 속도”**를 높여줌으로써 더 나은 결과물에 빠르게 도달하게 돕습니다. 2. 변하지 않는 본질: 인간의 판단력(Judgment) AI는 수많은 옵션을 만들 … --- ### 생각을 아웃소싱하지 마라: Claude Code와 AI 코드 생성 도구 활용 가이드 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/dont-outsource-your-thinking/ - Section: software - Date: 2026-01-08 - Description: Anthropic의 Claude Code와 같은 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 가이드입니다. - Tags: AI, Claude Code, 개발 도구, AI 활용, 프롬프트 엔지니어링 - Frameworks: Context Management, Grounding, Implementation Planning - Mental Models: Domain Expertise, Self-healing Systems 이 블로그 포스트인 **“Don’t Outsource Your Thinking”**은 개발자가 Anthropic의 **Claude Code(CC)**와 같은 최신 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 글입니다. 원문: Don’t Outsource Your Thinking 이 블로그 포스트인 **“Don’t Outsource Your Thinking”**은 개발자가 Anthropic의 **Claude Code(CC)**와 같은 최신 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 글입니다. 핵심 요약은 다음과 같습니다. 1. 철학: “생각을 아웃소싱하지 마라” 가장 중요한 논지는 도구에 사고(thinking) 자체를 맡기지 말라는 것입니다. AI는 지루한 반복 작업(Grunt … --- ### 프롬프트 설계 전략: Gemini API 활용하기 - URL: https://hugo-blog-static-site.haxlys.workers.dev/software/prompt-design-strategies/ - Section: software - Date: 2025-12-08 - Description: Google의 Gemini API 문서에 소개된 프롬프트 설계 전략을 정리한 가이드입니다. LLM으로부터 원하는 결과를 얻기 위한 명확하고 구체적인 프롬프트 작성 방법을 다룹니다. - Tags: AI, Gemini, Prompt Engineering, LLM - Frameworks: Few-shot Prompting, Zero-shot Prompting - Mental Models: Pattern Recognition, Example-based Learning Google의 Gemini API 문서에 소개된 프롬프트 설계 전략을 정리해 보았습니다. LLM(대규모 언어 모델)으로부터 원하는 결과를 얻기 위해서는 명확하고 구체적인 프롬프트 작성이 필수적입니다. 원문 가이드: Gemini API 프롬프트 설계 전략, Google AI Developers on X 1. 명확하고 구체적인 요청 사항 (Clear and Specific Requests) 모델의 동작을 효과적으로 제어하는 가장 좋은 방법은 명확하고 구체적인 요청을 하는 것입니다. 단순히 질문을 던지는 것뿐만 아니라, 단계별 작업 지시나 페르소나(Persona)를 부여하는 것도 좋은 방법입니다. 입력 (Input) 구성 요소 프롬프트의 입력은 다음과 같은 형태로 구성될 수 있습니다: ---