First Principles

Rohan Ganapavarapu의 Technological Involution은 기술 정체론, AI, 스타트업 문화, 하드테크를 한데 묶어 묻는다. 우리는 정말 더 이상 만들 것이 없는 시대에 도착했는가, 아니면 기술을 상상하고 믿는 방식이 먼저 낡아버린 것인가. Tech 핵심 정리 정체의 핵심: 문제는 가능성의 고갈보다 상상력의 수축이다. 우주, 원자력, 시간여행을 꿈꾸던 문화가 이제는 더 많은 AI와 더 많은 소프트웨어만 반복한다. 창업 문화의 함정: 창업자는 자기 확신으로 움직인다고 믿지만, 실제로는 VC, 인플루언서, 액셀러레이터가 유통한 논제를 자기 생각처럼 받아들이기 쉽다. AI의 한계: AI는 소프트웨어 엔지니어링에는 강력하지만, 현실 조직을 바꾸는 일은 여전히 운영 이해, 책임, 도메인 감각을 요구한다. 기회의 위치: 쉬운 SaaS보다 칩, 하드웨어 공급망, 엔터프라이즈 운영, 현장 문제처럼 접촉 비용이 큰 곳에 더 오래가는 가치가 있다. 새 기술의 조건: 좋은 제품은 억지 광고보다 제품 자체의 설득력과 시대적 욕구를 통해 퍼진다. 기술자는 다시 만들고 싶은 것에 대한 순수한 확신을 가져야 한다. 1) 정체는 기술보다 상상력에서 먼저 온다 글의 출발점은 1960년대식 미래 감각입니다. 당시 대중문화는 우주, 원자력, 정보기관의 기묘한 실험, 시간여행 같은 주제를 당연히 다음 세계의 후보로 상상했습니다. 중요한 것은 그 상상 중 일부가 실제 기술 개발의 방향이 되었다는 점입니다. ...

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가 빠르고 정확하게 일한다. 변경된 파일 중심으로 동작해야 함. Repo 속 맥락 : AI 세션은 매번 새로운 직원이 들어오는 것과 같다. 모든 원칙과 설계를 저장소 안에 명확히 문서화하라. 직접 소유(Own your Stack) : 핵심 부분(데이터, UI, i18n)은 직접 소유해 제품 경험을 완전히 통제하라. 옵션 가치 : 변경할 때마다 미래에 더 많은 선택지를 열어주는 방향으로 설계하라. 핵심 메시지 — 코딩이 병목에서 판단으로 AI 코딩 에이전트(Codex CLI + GPT 5.5)가 등장하면서 프로그래밍 방식이 근본적으로 바뀌었다. 이제 손으로 코드를 거의 쓰지 않게 되었고 , 에이전트가 인간 수준 이상의 코드를 몇 분 만에 작성한다. 코딩 자체는 더 이상 병목이 아니며, 엔지니어링의 본질은 “코드를 직접 쓰는 것” 에서 시스템을 지휘하고 판단하는 것 으로 이동했다. ...

출처: 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)으로 성능을 끌어올린다. 소프트웨어 전략: RadixArk(SGLang), Inferact(vLLM) 같은 엔진 경쟁의 핵심은 prefill(연산 중심)과 decode(메모리 중심)를 분리 최적화하는 스케줄링이다. 인프라 전략: KV cache를 GPU→CPU RAM→NVMe→S3로 계층화하면 긴 컨텍스트 비용을 줄이고 재사용률을 높일 수 있다. 시장 결론: 승자는 “NVIDIA 대체"보다 “특정 병목 해결"에서 먼저 나오며, 이후 클라우드·엔진·플랫폼에 통합될 확률이 높다. 1) 왜 지금도 GPU는 놀고 있는가 많은 팀이 “GPU가 비싸다"는 문제를 이야기하지만, 더 정확히는 “GPU 안의 연산 장치가 놀고 있다"는 문제가 큽니다. 이유는 단순합니다. ...

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

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

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

“백만 토큰당 $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 코딩 에이전트는 문서를 전혀 다른 방식으로 소비하며, 기존 포털은 점점 에이전트에게 보이지 않는 존재가 되고 있습니다. Addy Osmani는 이를 해결하기 위한 새로운 규율로 Agentic Engine Optimization(AEO) 을 제안합니다. 과거 SEO가 검색 크롤러를 위해 콘텐츠를 구조화했던 것처럼, AEO는 에이전트가 실제로 사용할 수 있도록 기술 콘텐츠를 구조화·포맷팅·제공하는 실천입니다. 왜 AEO인가 — 에이전트는 인간처럼 읽지 않는다 인간 패턴: 4~8분간 섹션을 점진적으로 클릭하며 탐색. 스크롤 깊이, 체류 시간, 링크 클릭 같은 분석 이벤트가 발생. 에이전트 패턴: 여러 페이지 탐색을 1~2개의 HTTP 요청으로 압축. 클라이언트 사이드 분석 이벤트는 전혀 남지 않음. 서버 로그에는 고유한 에이전트 핑거프린트가 남음 — Claude Code는 axios/1.8.4, Cline/Junie는 curl/8.4.0, Cursor는 got, Aider·OpenCode는 headless Chromium. 토큰 문제 — 문서 크기는 이제 1급 지표다 Cisco Secure Firewall Management Center REST API 퀵스타트는 193,217 토큰으로, 대부분 에이전트의 사용 가능 컨텍스트를 초과합니다. 이런 경우 에이전트는 조용히 잘라내거나, 건너뛰거나, 솔루션을 환각합니다. ...

Akshay Pachaar가 Anthropic, OpenAI, Perplexity, LangChain이 실제로 구축하고 있는 에이전트 하네스를 심층 분석합니다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리 등 stateless LLM을 capable agent로 변환하는 모든 것을 다룹니다. 원문: The Anatomy of an Agent Harness 핵심 주장 챗봇을 만들어 ReAct 루프에 도구 몇 개를 연결하면 데모에서는 작동한다. 프로덕션을 시도하면 무너진다 — 모델이 3단계 전에 한 일을 잊고, 도구 호출이 조용히 실패하고, 컨텍스트 윈도우가 쓰레기로 채워진다. 문제는 모델이 아니다. 모델을 둘러싼 모든 것이다. ...

Ashpreet Bedi(Agno 창업자)가 에이전트 구축과 프로덕션 운영 사이의 격차를 지적하며, 에이전틱 소프트웨어를 분산 시스템으로 다뤄야 한다는 체계적 프레임워크를 제시합니다. 원문: Systems Engineering: Building Agentic Software That Works / Agentic Software Engineering 핵심 주장 “에이전트 구축은 쉽지만, 프로덕션 환경에서 안정적으로 운영하는 것은 어렵다” 사용자 식별, 상태 유지, 동시 요청 처리, 환불 같은 민감한 작업, 실패한 도구 호출 처리가 필요한 순간, 그것은 더 이상 “LLM + 도구의 루프"가 아닌 분산 시스템 이 된다. 에이전틱 소프트웨어 배포의 3단계 단계 설명 핵심 Build(구축) 모델, 도구, 지식베이스, 메모리, 저장소, 보호 장치 정의 AI 엔지니어링 중심. 대부분의 프레임워크가 지원하는 영역 Serve(서빙) API로서 제공. 사용자별 범위 지정, 세션 관리, 수평 확장 대부분의 에이전트 제품이 여기서 정체됨 — 인프라 부족 Connect(연결) 사용자가 있는 곳과 통합 (Slack, Discord, MCP 등) “노트북의 에이전트는 실험, 사용자가 있는 곳의 에이전트가 제품” 에이전틱 소프트웨어의 6가지 기둥 1. Durability(내구성) 에이전트가 15단계 중 12단계에서 충돌하면, 재시작 시 부작용이 중복되거나 중요 컨텍스트가 손실된다. 일시 중지, 재개, 체크포인트, 우아한 복구가 필요하며, 내구성은 완전 재시작이 아닌 재개로 실패를 전환 한다. ...