{"site":{"title":"Haxlys's Blog","description":"AI, software engineering, agent infrastructure, and investment notes from Haxlys.","baseURL":"https://hugo-blog-static-site.haxlys.workers.dev/","languageCode":"kr-ko"},"posts":[{"title":"생성형 UI의 세 가지 길 — 통제형·선언형·개방형 인터페이스","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/generative-ui-three-approaches/","section":"posts","date":"2026-08-12T14:12:24+09:00","lastmod":"2026-08-12T14:12:24+09:00","description":"boda.sh의 Generative UI 글을 바탕으로, AI가 의도에 맞춰 인터페이스를 생성하는 세 가지 방식과 실제 제품에서 이를 조합하는 방법을 정리한다.","summary":"boda.sh의 Generative UI 글은 AI가 인터페이스를 만든다는 말을 세부적인 설계 선택으로 풀어낸다. 단순히 HTML을 생성하는 기술을 소개하는 데 그치지 않고, 사용자의 의도에 맞춰 화면을 얼마나 자유롭게 바꿀 것인지, 그 자유를 어떤 규칙과 안전장치로 제한할 것인지 설명한다.\n원문: Generative UI\nGenUI 핵심 정리 문제의식: AI 응답의 긴 텍스트 벽을 목적에 맞는 카드, 지도, 플래시카드 같은 일시적 UI로 바꾼다. 세 가지 방식: 기존 컴포넌트를 연결하는 Static/Controlled, 허용된 컴포넌트와 레이아웃을 조합하는 Declarative, raw UI 코드를 생성하는 Open-ended로 나눈다. 안전한 경계: 선언형 방식에서는 컴포넌트 카탈로그와 스키마가 AI가 실행할 수 있는 범위를 결정한다. 개방형 방식은 샌드박스가 필요하다. 프로토콜의 역할 분리: AG-UI는 에이전트와 클라이언트 사이의 이벤트를 전달하고, A2UI는 화면을 구성하는 컴포넌트와 속성을 표현한다. 실무 결론: 세 방식 중 하나를 고르는 것이 아니라, 제품의 위험도와 가변성에 따라 세 방식을 조합한다. 생성형 UI의 핵심은 화면 생성이 아니다 “AI가 생성한 사용자 인터페이스”라는 정의는 생각보다 넓다. Figma나 Claude Design으로 시안을 만드는 일, ChatGPT에 UI 코드를 작성하게 해 웹 앱으로 제공하는 일, AI로 발표 자료를 만들고 애니메이션을 넣는 일도 모두 생성형 UI라고 부를 수 있다.\n","content":"boda.sh의 Generative UI 글은 AI가 인터페이스를 만든다는 말을 세부적인 설계 선택으로 풀어낸다. 단순히 HTML을 생성하는 기술을 소개하는 데 그치지 않고, 사용자의 의도에 맞춰 화면을 얼마나 자유롭게 바꿀 것인지, 그 자유를 어떤 규칙과 안전장치로 제한할 것인지 설명한다.\n원문: Generative UI\nGenUI 핵심 정리 문제의식: AI 응답의 긴 텍스트 벽을 목적에 맞는 카드, 지도, 플래시카드 같은 일시적 UI로 바꾼다. 세 가지 방식: 기존 컴포넌트를 연결하는 Static/Controlled, 허용된 컴포넌트와 레이아웃을 조합하는 Declarative, raw UI 코드를 생성하는 Open-ended로 나눈다. 안전한 경계: 선언형 방식에서는 컴포넌트 카탈로그와 스키마가 AI가 실행할 수 있는 범위를 결정한다. 개방형 방식은 샌드박스가 필요하다. 프로토콜의 역할 분리: AG-UI는 에이전트와 클라이언트 사이의 이벤트를 전달하고, A2UI는 화면을 구성하는 컴포넌트와 속성을 표현한다. 실무 결론: 세 방식 중 하나를 고르는 것이 아니라, 제품의 위험도와 가변성에 따라 세 방식을 조합한다. 생성형 UI의 핵심은 화면 생성이 아니다 “AI가 생성한 사용자 인터페이스”라는 정의는 생각보다 넓다. Figma나 Claude Design으로 시안을 만드는 일, ChatGPT에 UI 코드를 작성하게 해 웹 앱으로 제공하는 일, AI로 발표 자료를 만들고 애니메이션을 넣는 일도 모두 생성형 UI라고 부를 수 있다.\n원문은 이 중 서버와 인터페이스 사이에서 AI가 실행 시점에 UI를 구성하는 경우에 집중한다. 이 관점에서 생성형 UI의 가장 분명한 용도는 AI 응답의 ‘텍스트 벽’을 없애는 것이다.\n사용자가 여행지를 물었을 때 장문의 설명만 반환하는 대신 지도와 장소 카드가 나타날 수 있다. 학습 내용을 요청했을 때 긴 문단만 보여주는 대신 바로 조작할 수 있는 플래시카드가 생성될 수도 있다. 핵심은 매번 새로운 애플리케이션을 만드는 것이 아니다. 사용자의 질문과 목적에 맞는 짧고 일시적인 인터페이스를 응답에 끼워 넣는 것이다.\n생성형 UI가 성숙할수록 AI 제품에는 고정된 답변 화면보다 사용자의 의도에 따라 잠시 나타났다가 사라지는 UI 요소가 많아진다.\n복잡해진 제품과 의도 기반 진입점 성공한 디지털 제품은 시간이 지나면서 기능과 책임이 늘어난다. 자체 기능뿐 아니라 결제, 예약, 지도, 소셜 미디어, 외부 SaaS 같은 제3자 연동도 붙는다. 일부 파트너는 자체 UI를 제공하지만, 브랜드 콘텐츠나 화이트 라벨 페이지처럼 제품이 직접 화면을 책임져야 하는 연동도 많다.\n기능과 연동이 늘어날수록 UI 조합의 수는 곱셈처럼 증가한다. 팀은 모든 경우를 미리 설계하기 어렵고, 사용자는 자신에게 필요하지 않은 기능까지 포함된 복잡한 앱을 탐색해야 한다.\n이 문제를 하나의 진입점으로 좁히려는 흐름이 슈퍼 앱과 AI 챗봇이다. 챗봇 안에서 쇼핑, 여행 예약, 일정 관리, 이메일, 음식 주문을 처리한다면 사용자는 서비스마다 다른 화면을 찾아다니지 않아도 된다.\n원문은 이 지점에서 WeChat Mini Program과 AI 챗봇을 비교한다. WeChat은 QR 코드처럼 예측 가능한 진입점에서 시작했고, AI 시스템은 자유로운 텍스트처럼 의도 기반(intent-based) 진입점에서 시작한다. 사용자가 매번 다른 질문을 한다면, 그에 대한 결과 UI도 매번 달라질 수 있어야 한다. 생성형 UI는 바로 이 의도와 인터페이스 사이의 간극을 메우는 방식이다.\n세 가지 생성 방식 OpenUI의 생성형 UI 분류는 두 축을 구분한다. UI가 어디에 나타나는지를 결정하는 전송(transport) 축과, 모델이 얼마나 자유롭게 UI를 만들 수 있는지를 결정하는 생성(generation) 축이다. 아래 세 가지는 생성 축에 해당하며 서로 배타적인 선택지가 아니다.\n1. Static/Controlled — 기존 부품을 안전하게 연결한다 Static/Controlled 방식에서 AI는 화면 자체를 만들지 않는다. 사용자의 자연어 요청을 해석해 도구의 인자를 결정하고, 애플리케이션은 도구 결과를 이미 만들어 둔 컴포넌트에 연결한다.\n예를 들어 장소 탐색 서비스라면 다음과 같이 동작한다.\n사용자가 “아이와 가기 좋고 지금 문을 연 공원을 찾아줘”라고 입력한다. 에이전트가 recommendPlaces 도구에 검색어, 영업 여부, 평점, 예산 같은 인자를 전달한다. 실제 검색과 필터링, 관련성 순위 계산은 애플리케이션 코드가 실행한다. 도구가 장소 목록과 적용된 필터를 반환한다. 프런트엔드는 결과 수와 상태에 따라 EmptyMatch, OpenStatus, PlaceCard, PlaceResults 같은 등록된 컴포넌트 중 하나를 선택한다. 이 방식은 기존 컴포넌트, 레이아웃, 디자인 시스템을 그대로 재사용한다. AI는 도구 스키마가 허용한 범위 안에서 검색 조건만 선택하고, 어떤 컴포넌트를 실제로 마운트할지는 결정론적인 애플리케이션 코드가 책임진다.\n따라서 일관된 UI를 유지하면서 자연어 입력을 추가하고 싶은 팀에 적합하다. 기존 제품에 생성형 UI를 도입하는 첫 단계로도 가장 현실적이다. 다만 AI가 새 레이아웃을 만들지는 못하므로, 가능한 화면 조합은 개발자가 미리 준비한 범위에 머문다.\n2. Declarative — 허용된 부품으로 새로운 구성을 만든다 Declarative 방식에서는 AI가 기존 화면 중 하나를 고르는 데서 더 나아가, 허용된 컴포넌트와 레이아웃을 조합한다. 개발자가 모든 화면을 미리 설계하지 않아도 AI가 사용자의 목표에 맞춰 대시보드를 구성할 수 있다.\n예를 들어 “파리에서 포르투로 가는 날씨 기반 주말 여행을 계획해줘”라는 요청에 AI가 다음 요소를 하나의 화면에 배치할 수 있다.\n여행 계획을 설명하는 문장 항공편 예상 정보 실시간 날씨 위젯 날짜별 일정 준비물 체크리스트 Static/Controlled 방식에서는 장소 검색 도구의 결과를 고정된 장소 그리드에 넣었다. Declarative 방식에서는 모델이 어떤 컴포넌트를 사용할지, 어떤 순서와 레이아웃으로 배치할지까지 결정한다. 단, 아무 코드나 실행하는 것은 아니다. 모델은 제품이 제공하는 카탈로그 안에서만 선택한다.\n이 구조를 단순화하면 다음과 같다.\n에이전트 서버 → 전송 프로토콜 → 클라이언트 각 층을 명세로 구체화하면 다음과 같은 조합이 된다.\nA2UI: 모델이 어떤 컴포넌트를 만들고, 어떤 속성을 전달하며, 어떻게 중첩할지 표현한다. AG-UI: 실행 시작·종료, 텍스트, 도구 호출, 상태, UI 활동 같은 이벤트를 서버와 클라이언트 사이에 전달한다. A2A: 에이전트가 다른 에이전트를 발견하고 협력해야 할 때 사용할 수 있는 에이전트 간 프로토콜이다. 원문에서 사용한 예시는 Mastra agent → AG-UI → A2UI 구조다. 모델은 A2UI 형식에 맞춰 컴포넌트 트리를 만들고, AG-UI의 이벤트를 통해 이를 클라이언트로 스트리밍한다. 클라이언트는 트리를 순회하며 각 컴포넌트 ID를 실제 React 렌더러에 연결한다.\n여기서 중요한 것은 **카탈로그가 계약(contract)**이라는 점이다. 카탈로그에는 모델이 사용할 수 있는 컴포넌트, 각 컴포넌트가 받는 속성, 컴포넌트가 중첩될 수 있는 방식이 정의된다. Zod 같은 스키마는 모델이 요청할 수 있는 값을 제한하고, React 렌더러는 실제 브라우저에서 실행될 동작을 구현한다.\n이 경계가 있기 때문에 AI는 새로운 레이아웃을 조합할 수 있지만 임의의 JavaScript를 페이지에 삽입할 수는 없다. 대신 더 많은 명세와 SDK, 카탈로그 버전 관리, 정책 설계가 필요하다. 유연성은 커지지만 그 유연성을 관리할 규칙도 함께 늘어난다.\n3. Open-ended — UI 코드 자체를 생성한다 Open-ended 방식은 모델이 HTML·CSS·JavaScript 같은 raw UI 코드를 직접 출력한다. 카탈로그나 스키마가 없어도 되므로 표현의 자유는 가장 크다. 내부용 대시보드나 짧은 실험처럼 통제된 환경에서는 빠르게 결과를 만들 수 있다.\n하지만 외부 사용자를 대상으로 임의의 코드를 브라우저에서 실행하는 일은 심각한 보안 위험을 만든다. 현재 널리 거론되는 해결책은 MCP Apps의 샌드박스 iframe처럼 실행 환경을 격리하는 것이다.\n샌드박스가 있어도 문제가 모두 사라지지는 않는다. 생성 결과의 지연시간, 캐시 가능성, 감사 가능성, UI 일관성, 비용, 장애 대응을 함께 해결해야 한다. 그래서 Open-ended 방식은 가장 강력하지만, 일반적인 핵심 제품 흐름의 기본값으로 쓰기에는 아직 부담이 크다.\n프로토콜보다 중요한 것은 경계다 Declarative 구조를 처음 보면 A2UI와 AG-UI가 무엇을 구분하는지 헷갈리기 쉽다. 둘의 역할은 간단히 나눌 수 있다.\n층 담당하는 질문 AG-UI 에이전트 실행 상태와 UI 관련 이벤트를 어떻게 전달하는가? A2UI 어떤 컴포넌트를 어떤 속성과 계층으로 그릴 것인가? 컴포넌트 카탈로그 실제 클라이언트에서 어떤 코드와 디자인을 실행할 것인가? AG-UI는 UI의 모양을 알 필요가 없다. 이벤트를 운반하는 역할을 한다. A2UI는 화면을 표현하지만, 실제 React 컴포넌트 구현 자체는 아니다. 카탈로그와 렌더러가 최종적으로 어떤 화면을 보여줄지 결정한다.\n이 분리는 생성형 UI를 특정 모델이나 특정 프런트엔드 구현에 묶이지 않게 한다. 서버의 에이전트, 이벤트 전송, 화면 명세, 클라이언트 렌더러를 교체하거나 조합할 수 있는 여지가 생긴다. 반대로 명세와 SDK가 늘어나므로 팀이 관리해야 할 계약도 많아진다.\n세 방식을 섞어 쓰는 이유 세 범주는 경쟁 관계가 아니다. 제품 안에서 요구하는 자유도와 위험도가 서로 다르기 때문이다.\n핵심 내비게이션과 결제처럼 예측 가능성이 중요한 부분은 고정 컴포넌트로 유지한다. 사용자의 목표에 따라 카드와 위젯을 조합해야 하는 영역은 Declarative 방식으로 만든다. 한 번만 쓰는 외부 도구나 특정 업무를 위한 위젯은 샌드박스 안의 Open-ended 방식으로 격리한다. 원문은 MCP와 A2UI를 조합하는 세 가지 방향도 소개한다.\nMCP 위의 A2UI: MCP 서버가 텍스트나 완성된 웹 앱 대신 A2UI 페이로드를 반환하고, 호스트가 자신의 렌더러로 화면을 그린다. A2UI 안의 MCP Apps: 샌드박스 iframe을 하나의 A2UI 컴포넌트로 정의해 선언형 화면 안에 MCP App을 넣는다. MCP Apps 안의 A2UI: MCP App이 iframe 내부에 A2UI 렌더러를 포함하고, 앱 브리지를 통해 받은 명세를 내부에서 렌더링한다. 첫 번째 방식은 같은 화면 명세를 서로 다른 호스트에서 재사용할 가능성을 보여준다. 두 번째와 세 번째 방식은 네이티브 컴포넌트의 일관성과 외부 앱의 자유도를 한 화면에서 함께 얻으려는 시도다. 대신 iframe을 쓰면 디자인 시스템 충돌, 중복 스크롤바, 성능 비용, 새로운 보안 경계를 직접 관리해야 한다.\n제품에 도입할 때의 판단 순서 생성형 UI를 도입할 때 “AI가 화면을 만들 수 있는가”부터 묻는 것은 충분하지 않다. 먼저 화면이 동적으로 달라질 때 사용자가 실제 이득을 얻는지 확인해야 한다.\n다음 순서가 현실적인 출발점이 된다.\n기존 컴포넌트에 자연어 입력을 연결한다. 검색·필터·추천처럼 도구 결과가 명확한 영역에서 Static/Controlled 방식을 적용한다. 허용된 컴포넌트 카탈로그를 만든다. 컴포넌트별 속성, 중첩 규칙, 사용 조건, 금지 조합, 실패 시 대체 UI를 명시한다. 선언형 조합을 제한된 영역에서 실험한다. 대시보드나 계획 수립처럼 사용자 목표와 화면 구성이 크게 달라지는 곳부터 시작한다. 임의 코드가 필요한 경우 실행 환경을 격리한다. Open-ended UI를 핵심 제품 DOM에 직접 넣지 말고, 샌드박스·권한·감사 로그·자원 제한을 함께 설계한다. 운영 지표를 확인한다. 속도, 지연시간, 캐시 가능성, 비용, 보안, 감사, 일관성, 실패율을 정적인 화면과 비교한다. 이 과정의 핵심은 자유도를 한 번에 최대로 올리지 않는 것이다. 통제형에서 시작해 선언형으로 넓히고, 꼭 필요한 경우에만 개방형 실행 공간을 추가하면 제품의 안정성과 실험 속도를 함께 관리할 수 있다.\n결론 및 시사점 한 줄 결론: 생성형 UI의 미래는 하나의 방식이 모든 화면을 대체하는 데 있지 않고, 통제형·선언형·개방형 UI를 의도와 위험도에 맞춰 조합하는 데 있다.\n생성형 UI는 “AI가 예쁜 화면을 만들어준다”는 기능이 아니다. 사용자의 자유로운 의도를 안전하게 해석하고, 제품이 허용한 재료 안에서 필요한 인터페이스를 구성하는 아키텍처다.\n따라서 가장 중요한 자산은 모델 자체보다 컴포넌트 카탈로그, 스키마, 전송 프로토콜, 렌더러, 실패 시 대체 흐름이 된다. 코드를 작성하는 비용이 낮아질수록 사람은 화면 하나하나보다 더 높은 수준의 명세와 경계를 설계해야 한다. 좋은 GenUI는 화면을 무한히 열어두는 시스템이 아니라, 필요한 곳에서만 유연하고 나머지 영역에서는 예측 가능한 시스템이다.\n","wordCount":1451,"tags":["AI","GenUI","생성형 UI","A2UI","AG-UI","MCP","인터페이스"],"categories":["AI","Product Design"],"frameworks":["Progressive Adoption","Specification-driven Design","Defense in Depth"],"mental_models":["Controlled Flexibility","Intent-based Interface","Separation of Concerns"],"philosophy_type":"product-design","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["생성형 UI의 핵심은 코드를 만드는 일이 아니라 사용자의 의도에 맞춰 필요한 인터페이스를 그때그때 구성하는 일이다","Static/Controlled는 기존 컴포넌트와 도구 결과를 연결해 가장 안전하게 도입하는 방식이다","Declarative는 AI가 허용된 컴포넌트와 레이아웃을 선택하도록 하며, A2UI는 인터페이스를 AG-UI는 이벤트 전달을 담당한다","Open-ended는 HTML·CSS·JavaScript를 직접 생성해 가장 유연하지만 보안·지연시간·감사·일관성 문제가 크다","실제 제품은 핵심 흐름에 통제형 UI를, 동적 조합에 선언형 UI를, 한시적 위젯에 격리된 개방형 UI를 섞는 방향으로 발전한다"],"related":["posts/designing-for-genui-ai-builds-ui","posts/apps-after-agents","posts/agent-harness-engineering"]},{"title":"마찰은 기능이다 — AI가 낮춘 제작 비용과 판단의 공백","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/friction-is-a-feature-ai-judgment/","section":"posts","date":"2026-08-12T13:01:12+09:00","lastmod":"2026-08-12T13:01:12+09:00","description":"Emil Kowalski의 글을 바탕으로, AI가 제작 비용을 낮추면서 사라진 판단의 문턱을 어떻게 다시 설계해야 하는지 살펴본다.","summary":"Emil Kowalski의 글 Friction as a Feature는 제품이 줄이려 하는 **마찰(friction)**을 다른 각도에서 바라본다. 마찰은 느리고, 비효율적이며, 번거롭다. 그래서 제품은 오랫동안 마찰을 제거하는 방향으로 발전해 왔다. 하지만 제작 과정의 마찰에는 우리가 놓치기 쉬운 두 번째 역할이 있었다. 무엇을 만들기 전에 한 번 더 생각하게 만드는 문턱이었다.\n이 글은 AI를 쓰지 말자거나 과거의 느린 제작 과정을 되살리자는 주장이 아니다. AI가 낮춘 제작 비용을 그대로 누리되, 그 비용이 우연히 담당했던 판단 기능을 제품과 팀의 과정 안에 다시 설계해야 한다는 제안이다.\n","content":"Emil Kowalski의 글 Friction as a Feature는 제품이 줄이려 하는 **마찰(friction)**을 다른 각도에서 바라본다. 마찰은 느리고, 비효율적이며, 번거롭다. 그래서 제품은 오랫동안 마찰을 제거하는 방향으로 발전해 왔다. 하지만 제작 과정의 마찰에는 우리가 놓치기 쉬운 두 번째 역할이 있었다. 무엇을 만들기 전에 한 번 더 생각하게 만드는 문턱이었다.\n이 글은 AI를 쓰지 말자거나 과거의 느린 제작 과정을 되살리자는 주장이 아니다. AI가 낮춘 제작 비용을 그대로 누리되, 그 비용이 우연히 담당했던 판단 기능을 제품과 팀의 과정 안에 다시 설계해야 한다는 제안이다.\n3줄 핵심 정리 마찰의 두 얼굴: 불필요한 클릭과 대기는 줄여야 하지만, 제작 전에 문제와 가치를 묻는 마찰은 아이디어를 걸러내는 역할을 했다. 제작과 검증의 분리: AI는 앱을 빠르게 만들게 해주지만, 프로토타입을 만들었다는 사실은 사용자가 원한다는 증거가 아니다. 실무적 방향: AI가 후보를 많이 만들게 하되, 사람은 선택 기준·검증 증거·중단 조건을 명시하고 결과를 채택해야 한다. 마찰은 왜 나쁜 말이 되었나 사용자 경험에서 마찰을 줄이는 일은 대체로 옳다. 결제 단계의 불필요한 입력, 앱이 반응하기 전의 긴 대기, 무엇을 눌러야 할지 알 수 없는 화면은 사용자의 목표를 방해한다. 제품이 이런 마찰을 없애면 사용자는 더 빠르고 자신 있게 일을 끝낼 수 있다.\n문제는 모든 마찰을 같은 종류로 취급할 때 생긴다. 사용자의 행동을 막는 마찰과 제작자의 판단을 돕는 마찰은 다르다. 전자는 줄여야 하지만, 후자는 사라질 때 품질 필터도 함께 약해질 수 있다.\n줄여야 할 마찰 남겨야 할 마찰 사용자가 목표를 달성하기 전에 겪는 불필요한 클릭·대기·혼란 무엇을 만들 가치가 있는지 결정하기 위한 질문과 검토 제품의 의도를 이해하지 못해 생기는 시행착오 실제 사용자의 반응과 실패 사례를 확인하는 검증 반복 작업을 느리게 만드는 수동 절차 결과를 채택하기 전에 기준과 책임자를 확인하는 절차 Kowalski가 말하는 핵심은 두 번째 열을 첫 번째 열과 함께 없애지 말자는 데 있다. 마찰은 불편함이기만 한 것이 아니라, 때로는 판단을 발생시키는 비용이기도 했다.\n제작 비용은 보이지 않는 품질 필터였다 AI 이전에는 코드를 쓰는 일이 비쌌다. 아이디어를 실제 앱으로 만들려면 API를 조사하고, 라이브러리를 연결하고, 오류를 고치고, 운영 환경에 배포해야 했다. 이 비용이 품질을 보장한 것은 아니다. 다만 아무 아이디어나 바로 구현하지는 못하게 했다.\n제작에 시간이 걸리면 사람은 자연스럽게 질문한다.\n이 문제가 정말 중요한가? 지금 이 기능을 만들어야 하는가? 이 아이디어에 며칠을 쓸 가치가 있는가? 이 질문에 대한 답이 명확하지 않으면 구현을 시작하기가 어려웠다. 다시 말해 제작 비용은 아이디어가 살아남기 위해 통과해야 하는 문턱이었다.\nAI는 이 문턱을 크게 낮췄다. 이제 아이디어가 몇 분 안에 앱이나 화면으로 바뀔 수 있다. 이는 분명한 이점이다. 구현 전에 상상만 하던 대안을 실제로 만들어 비교할 수 있고, 작은 실험을 더 많이 할 수 있다. 원문도 값싼 제작이 사고의 한 방식이 될 수 있다는 점은 인정한다.\n다만 프로토타입을 만드는 일과 아이디어를 검증하는 일은 다르다. A와 B를 모두 만들 수 있다는 사실은 A와 B 중 하나가 가치 있다는 증거가 아니다.\nAI는 만들기와 검증을 혼동하게 한다 제작 비용이 거의 없어지면 두 가지 유혹이 생긴다. 첫째, 검증이 끝나지 않은 아이디어도 계속 만들 수 있다. 둘째, 결과물이 존재한다는 사실을 수요가 있다는 증거처럼 받아들이기 쉽다.\n원문이 지적하는 바이브 코딩 앱과 UI 라이브러리의 문제도 여기에 있다. 문제는 AI가 만들었다는 사실 자체가 아니다. 무엇을 위해 만들어졌는지, 어떤 제약을 고려했는지, 어떤 선택을 거쳐 지금의 형태가 되었는지가 보이지 않는다는 점이다. 결과물은 작동할 수 있지만, 설계된 느낌보다 그냥 존재하는 느낌을 준다.\n좋은 결과물에는 대개 선택의 흔적이 있다. 누구를 위한 것인지, 무엇을 하지 않기로 했는지, 어떤 예외를 우선했는지, 어떤 불편을 감수했는지가 형태에 남는다. 이런 선택이 없으면 표면은 매끈해도 결과물은 비어 보인다.\n이 구분은 AI가 만든 결과물을 평가할 때 특히 중요하다. 사람이 만들었는지 AI가 만들었는지를 맞히는 일보다, 결과물이 명확한 문제와 기준을 통과했는지를 확인하는 일이 더 중요하다. 출처보다 의도와 검증 가능성이 품질을 가른다.\n마찰이 사라지면 결과물이 비어 보이는 이유 Kowalski의 표현을 빌리면 마찰이 사라진 뒤 남는 것은 출력물뿐이다. 만드는 과정에서 고민하고, 비교하고, 버리고, 다시 선택하는 단계가 약해지면 결과물에 맥락이 남지 않는다. 그래서 비슷한 화면과 컴포넌트가 늘어나도 서로 다른 문제를 해결한다는 느낌을 주지 못한다.\n여기서 말하는 품질은 시각적 장식이나 복잡한 애니메이션만을 뜻하지 않는다. 다음과 같은 질문에 답할 수 있는 상태에 가깝다.\n이 기능이 존재해야 하는 이유는 무엇인가? 이 결과가 충분하다고 판단한 근거는 무엇인가? 사용자가 실패할 때 제품은 무엇을 알려주는가? 어떤 증거가 나오면 이 기능을 줄이거나 없앨 것인가? 이 질문에 답하는 과정은 느릴 수 있다. 그러나 이 느림이 결과물의 목표와 경계를 선명하게 한다. 마찰은 최종 사용자에게 떠넘기는 장애물이 아니라, 제작자가 결정을 내리도록 돕는 내부 장치가 될 수 있다.\n기능으로서 마찰을 다시 설계하는 법 과거의 제작 비용을 그대로 복원할 필요는 없다. AI가 후보를 빠르게 만들 수 있다는 장점은 유지하면서, 후보를 채택하는 과정에 판단의 문턱을 넣으면 된다. 실무에서는 다음과 같은 방식으로 시작할 수 있다.\n만들기 전에 문제를 한 문장으로 고정한다. 누가 어떤 상황에서 무엇을 해결하려는지 적는다. 문제 정의가 흔들린 채 화면부터 만들면 후보의 개수만 늘어난다. 후보와 채택을 분리한다. AI에게 여러 안을 만들게 할 수 있지만, 각 안을 비교할 기준과 최종 책임자를 정한다. 많이 만든 사실은 채택 사유가 아니다. 작동 여부와 가치 여부를 따로 확인한다. 테스트 통과, 렌더링 성공, 배포 가능성은 기술적 조건이다. 사용자가 필요로 하는지, 반복해서 쓰는지는 별도의 증거가 필요하다. 검증 지점을 작업 흐름에 넣는다. 실제 사용자 관찰, 인터뷰, 사용 로그, 실패 사례 중 적절한 증거를 정하고 다음 제작 단계로 넘어가기 전에 확인한다. 중단 조건을 먼저 쓴다. 어떤 반응이나 수치가 나오면 기능을 축소하거나 버릴지 정한다. 시작 조건만 있고 중단 조건이 없으면 낮은 비용이 무한한 범위 확장으로 이어진다. 이 과정은 AI를 느리게 만드는 장치가 아니다. 오히려 값싼 제작을 값싼 학습으로 바꾸는 장치다. 후보를 만드는 속도는 유지하되, 무엇을 현실에 남길지 결정하는 속도와 기준을 관리한다.\n팀이 측정해야 할 것은 생성량만이 아니다 AI 도입 뒤 팀이 코드 줄 수, 생성한 화면 수, 출시한 기능 수만 측정하면 제작 비용이 낮아진 효과만 보게 된다. 그 지표는 무엇을 만들지 말아야 했는지 알려주지 않는다.\n팀은 다음과 같은 신호도 기록할 필요가 있다.\n만들기 전에 중단된 아이디어의 비율 실제 사용자 증거를 확인한 뒤 수정되거나 폐기된 기능 기능을 채택한 기준과 책임자 출시 후 어떤 가정이 틀렸는지 알게 된 시점 만들지 않기로 한 결정이 막아낸 비용과 위험 이런 기록을 성과 경쟁으로 만들면 또 다른 형식주의가 된다. 목적은 사람을 더 많이 검토하게 만드는 것이 아니라, 제작과 판단이 서로 다른 활동이라는 사실을 조직이 잊지 않게 하는 데 있다.\n결국 필요한 것은 생산 단계의 마찰은 낮추고, 판단 단계의 마찰은 의식적으로 보존하는 구조다. AI가 초안을 빠르게 만들수록 팀은 오히려 기준, 증거, 책임, 중단 조건을 더 분명히 해야 한다.\n결론 및 시사점 한 줄 결론: AI가 제작 비용을 없앨수록, 좋은 제품을 만드는 팀은 마찰을 제거하는 데서 멈추지 않고 판단을 지키는 마찰을 다시 설계해야 한다.\nEmil Kowalski의 글은 마찰을 무조건 되돌리자는 주장이 아니다. 사용자의 목표를 방해하는 불편은 계속 줄여야 한다. 대신 제작자가 무엇을 만들지 선택하고, 결과를 검증하고, 틀린 방향을 버리게 만드는 문턱까지 없애면 안 된다는 뜻이다.\nAI는 가능한 결과의 수를 폭발적으로 늘린다. 그만큼 희소해지는 것은 제작 능력이 아니라 선택 기준과 검증 능력이다. AI를 잘 쓰는 제품과 팀은 가장 많은 것을 만든 곳이 아니라, 무엇을 만들지 않았고 왜 남은 결과물을 선택했는지 설명할 수 있는 곳이다.\n","wordCount":1062,"tags":["AI","제품 설계","소프트웨어","판단","검증","Vibe Coding"],"categories":["AI","Design"],"frameworks":["Friction as Filter","Build vs. Validate","Human Judgment"],"mental_models":["Opportunity Cost","Validation","Threshold Effects"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["제품이 마찰을 줄이는 방향으로 발전해 왔지만, 제작 비용은 아이디어를 걸러내고 먼저 생각하게 만드는 문턱 역할도 했다.","AI는 아이디어를 앱으로 바꾸는 시간을 크게 단축했지만, 프로토타입 제작과 실제 검증을 구분하지 않으면 A와 B를 모두 출시한 뒤 무엇이 가치 있는지 판단하지 않게 된다.","바이브 코딩 결과물과 UI 라이브러리가 무의미하게 느껴지는 이유는 기술 부족보다 문제 정의와 선택의 흔적이 약하기 때문이다.","의도적인 마찰은 결과물의 목적, 검증 기준, 실패 신호, 중단 조건을 묻는 설계로 남겨야 한다.","AI 시대 팀의 경쟁력은 최대 생산량이 아니라 무엇을 만들지 않고 버릴지 결정하는 판단 품질에서 나온다."],"related":["posts/taste-is-all-thats-left","posts/ai-small-teams-not-headcount","posts/eval-smell-product-design","posts/the-founders-playbook-ai-native-startup"]},{"title":"Coinbase가 AI 시대에 엔지니어 면접을 다시 설계한 방식","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/coinbase-ai-era-engineering-interviews/","section":"posts","date":"2026-08-12T12:42:43+09:00","lastmod":"2026-08-12T12:42:43+09:00","description":"Coinbase가 AI 생성 코드의 확산에 맞춰 엔지니어 면접을 어떻게 재설계했는지, 세 단계의 실험과 세 가지 평가 신호를 중심으로 살펴본다.","summary":"Coinbase는 AI가 코드를 작성하는 환경에 맞춰 엔지니어 채용 면접을 1년 동안 다시 설계했다. 핵심 변화는 코드를 제한 시간 안에 직접 쓰는 능력에서 벗어나, AI를 어떻게 지시하고 결과를 검증하며 잘못된 판단을 교정하는지를 평가하는 방향으로 이동한 데 있다.\n원문: Interviewing Engineers in the AI Era: Lessons from a Year of Rebuilding (Coinbase, 2026-07-13)\nTL;DR 핵심 정리 Coinbase의 AI 생성 코드 비중은 2025년 1분기 5.7%에서 4분기 50%를 넘었고, 현재는 인간 검토를 전제로 거의 100%까지 늘었다. 기존의 URL 단축기·메시지 큐 설계 같은 문제는 AI가 1분 안에 그럴듯한 답을 만들 수 있어, 암기력보다 판단력을 측정해야 하는 상황이 됐다. 면접은 프론트엔드 파일럿, 백엔드 저장소 기반 과제, 2026년 3월 전사 AI 역량 평가의 세 단계로 바뀌었다. 평가 기준은 AI 도구 사용, 적절한 적용, 한계 이해이며, 실무에 가까운 저장소 디버깅과 코드 리뷰가 핵심 과제가 됐다. 아직 검증 중인 영역은 면접 성과와 실제 업무 성과의 상관관계, 그리고 빠르게 낡는 AI 면접 문항의 유효기간이다. 1. 코드 생성이 빨라질수록 판단이 병목이 된다 Coinbase에 병합되는 코드 가운데 AI가 생성한 코드의 비중은 2025년 1분기 5.7%였다. 4분기에는 처음으로 50%를 넘었고, 글이 공개된 시점에는 인간이 모든 코드를 검토한다는 전제 아래 거의 100%에 도달했다고 설명한다.\n","content":"Coinbase는 AI가 코드를 작성하는 환경에 맞춰 엔지니어 채용 면접을 1년 동안 다시 설계했다. 핵심 변화는 코드를 제한 시간 안에 직접 쓰는 능력에서 벗어나, AI를 어떻게 지시하고 결과를 검증하며 잘못된 판단을 교정하는지를 평가하는 방향으로 이동한 데 있다.\n원문: Interviewing Engineers in the AI Era: Lessons from a Year of Rebuilding (Coinbase, 2026-07-13)\nTL;DR 핵심 정리 Coinbase의 AI 생성 코드 비중은 2025년 1분기 5.7%에서 4분기 50%를 넘었고, 현재는 인간 검토를 전제로 거의 100%까지 늘었다. 기존의 URL 단축기·메시지 큐 설계 같은 문제는 AI가 1분 안에 그럴듯한 답을 만들 수 있어, 암기력보다 판단력을 측정해야 하는 상황이 됐다. 면접은 프론트엔드 파일럿, 백엔드 저장소 기반 과제, 2026년 3월 전사 AI 역량 평가의 세 단계로 바뀌었다. 평가 기준은 AI 도구 사용, 적절한 적용, 한계 이해이며, 실무에 가까운 저장소 디버깅과 코드 리뷰가 핵심 과제가 됐다. 아직 검증 중인 영역은 면접 성과와 실제 업무 성과의 상관관계, 그리고 빠르게 낡는 AI 면접 문항의 유효기간이다. 1. 코드 생성이 빨라질수록 판단이 병목이 된다 Coinbase에 병합되는 코드 가운데 AI가 생성한 코드의 비중은 2025년 1분기 5.7%였다. 4분기에는 처음으로 50%를 넘었고, 글이 공개된 시점에는 인간이 모든 코드를 검토한다는 전제 아래 거의 100%에 도달했다고 설명한다.\n여기서 중요한 구분은 AI가 작성한 코드와 사람이 검토한 코드가 다르다는 점이다. Coinbase의 엔지니어는 여전히 모든 변경을 검토하지만, 직접 처음부터 코드를 작성하는 시간은 줄고 다음 업무의 비중이 커졌다.\n요구사항과 명세 작성 AI에 구현을 지시하고 작업을 쪼개는 일 AI가 만든 변경의 정확성·보안성 검토 AI가 자신 있게 삽입한 아키텍처 오류 발견 트레이드오프, 롤백 위험, 시스템 경계를 판단하는 일 따라서 회사가 실제 업무에서는 AI 협업을 요구하면서 채용 단계에서는 AI 없이 45분 동안 코드를 작성하게 하면, 평가 대상과 업무 현실이 어긋난다. Coinbase는 이 불일치를 면접 개편의 출발점으로 삼았다.\n2. 기존 면접은 암기력과 실력을 혼동했다 전통적인 시스템 설계 면접은 URL 단축기나 메시지 큐를 설계하게 하면서 캐싱, 샤딩, 일관성 같은 대표 패턴을 기억하는지를 확인했다. 이 방식은 패턴을 익히기 어려웠던 시기에는 의미가 있었지만, 이제는 AI가 짧은 시간 안에 방어 가능한 참조 설계를 제시할 수 있다.\nCoinbase가 발견한 문제는 두 방향으로 나타났다.\n거짓 양성: 정답 패턴을 잘 외운 지원자가 실제 업무에서 필요한 판단력을 충분히 보여주지 않아도 통과한다. 거짓 음성: 패턴 암기에는 약하지만 AI의 결과를 지시·평가·수정하는 능력이 뛰어난 지원자가 불리해진다. 면접 라운드 사이의 중복도 컸다. 내부 분석에서 서로 다른 두 라운드의 결과가 84% 상관을 보였는데, 비용이 큰 두 라운드가 거의 같은 신호를 내면서도 AI 협업 능력은 충분히 측정하지 못했다. Coinbase는 라운드를 단순히 늘리는 대신, 기존 라운드가 무엇을 측정하는지부터 다시 따졌다.\n3. 세 단계로 면접을 재구축했다 Coinbase는 한 번에 전면 개편하지 않고, 실제 엔지니어링 프로젝트처럼 파일럿과 종료 기준을 두고 확장했다.\n1단계 — 2025년 하반기 프론트엔드 파일럿 기존 프론트엔드 문제에 AI만 허용하면 AI가 문제를 직접 풀어버렸다. 이는 AI 환경을 고려하지 않은 문제를 그대로 둔 채 도구만 추가한 결과였다.\n그래서 문제를 처음부터 다시 만들었다. 지원자는 현실적인 문제를 AI와 함께 풀되, 평가의 중심은 결과물 자체만이 아니라 다음 행동에 놓였다.\n프롬프트가 문제를 적절히 분해하는가 AI의 출력을 검증하는가 오류를 발견하고 재질문하는가 여러 번의 반복을 통해 결과를 개선하는가 AI에게 답을 만들게 하는 것은 쉬웠다. 좋은 답을 만들고, 믿을 수 있는 부분과 반박해야 할 부분을 구분하는 능력이 핵심 신호가 됐다.\n2단계 — 2026년 1월 백엔드 확장 백엔드 면접은 기존 문제를 고치는 방식으로 확장하지 않고, 저장소 기반 문제를 새로 만들었다. 지원자는 실제 코드베이스와 비슷한 환경에서 버그를 분류하고, 성능·정확성을 검토하며, 롤백 시나리오를 판단했다. AI 도구는 사용할 수 있지만 최종적으로 무엇을 받아들일지는 지원자가 책임진다.\n이 방식은 빈 파일에서 코드를 생산하는 능력보다, 이미 존재하는 시스템을 이해하고 AI와 함께 개선하는 능력을 측정한다. 실제 업무에서 엔지니어가 마주하는 상황과도 더 가깝다.\n3단계 — 2026년 3월 전사 AI 역량 평가 2026년 3월에는 엔지니어 면접의 모든 단계에 AI 관련 신호를 반영했다. 기존 절차 위에 AI 문제를 덧붙인 것이 아니라, 지원자를 평가하는 방식 자체를 AI 협업 환경에 맞게 바꾼 것이다.\n새로운 평가의 초기 결과는 긍정적이었다. 다만 표본이 아직 작다는 단서가 붙는다. AI 보조 코딩 평가를 통과한 지원자가 기존 평가를 통과한 지원자보다 온사이트 면접으로 진출하는 비율이 의미 있게 높았으며, Coinbase는 이것이 기준을 불필요하게 높인 것이 아니라 더 적합한 지원자를 선별하는 방향의 신호라고 설명한다.\n4. AI 역량을 세 차원으로 정의했다 Coinbase는 주니어와 시니어에게 동일하게 적용할 AI 역량을 세 가지로 나눴다.\n사용(Usage): 적절한 도구를 선택하고, 필요한 업무 구간에 책임 있게 적용하며, 결과를 실제로 개선하는가를 본다. 적용(Application): AI가 적합한 문제와 그렇지 않은 문제를 구분하고, 단순 자동화를 넘어 사업 성과로 이어지는 업무 흐름을 설계하는가를 본다. 한계 이해(Understanding Limits): AI가 실패하는 지점을 알고, 개인정보·보안 위험을 식별하며, 필요한 곳에서 인간의 판단을 안전장치로 적용하는가를 본다. 이 정의는 AI를 많이 사용하는 사람을 무조건 높게 평가하지 않는다. 중요한 것은 사용량이 아니라 도구 선택의 적절성, 결과에 대한 책임, 모델의 한계를 인식하는 능력이다.\n5. 최종적으로 남긴 세 가지 신호 Coinbase는 AI 기술이 바뀌어도 비교적 오래 유지될 평가 신호를 세 가지로 정리했다. 각 라운드의 형식은 바뀔 수 있지만, 무엇을 확인해야 하는지는 실무 요구에 맞춰 유지한다.\n저장소 기반 코딩·디버깅 — 운영 중\n지원자가 자신이 작성하지 않은 코드에서 문제를 분류하고, 장애를 디버깅하며, 성능과 호환성을 판단하는지 평가한다. AI가 만든 변경이 그럴듯해 보이는지와 실제로 올바른지를 구분하는 능력도 포함한다.\nAI와 함께하는 시스템 설계 — 초기 검증 중\nAI를 이용해 스키마, API 계약, 실패 모드 등을 탐색하면서도 어떤 제약이 중요한지, 어떤 트레이드오프가 실제인지, 언제 AI의 제안을 거부해야 하는지를 평가하는 라운드다. Coinbase는 이 영역을 설계 중이며 이후 분기에 파일럿할 예정이다.\n리더십·행동 면접 — 운영 중\n의사결정, 우선순위, 갈등 대응, 신뢰 형성, 성장 방식이라는 기존 목적은 유지한다. 여기에 지원자가 실제 업무에서 AI를 어떻게 활용하는지 구체적인 행동 사례를 묻는 항목을 더했다.\nCoinbase가 끝까지 지킨 원칙은 라운드를 추가하지 않는 것이다. 새로운 신호는 기존 라운드를 대체하거나, 기존 절차가 측정하지 못한 별도의 정보를 제공해야 한다. 평가 항목을 늘리는 것보다 후보자 경험과 면접관 부담을 함께 고려해 신호의 중복을 줄이는 편이 낫다는 판단이다.\n6. 면접을 일회성 절차가 아닌 운영 시스템으로 본다 이번 개편은 단일 리더의 지시로 끝난 프로젝트가 아니다. 엔지니어, 채용 관리자, 리크루터로 구성된 작업 그룹이 면접 루프를 소유하고, 명확한 성공 기준을 가진 파일럿을 실행한 뒤 데이터가 뒷받침할 때만 확장한다.\n또한 면접 문항에는 빠른 유효기간이 생겼다. 오늘 AI 역량을 구분하던 문제가 다음 분기에는 최신 모델이 쉽게 풀 수 있는 문제가 될 수 있다. Coinbase는 분기별 검토 주기로 문항의 효과를 확인하고, 더 이상 신호를 내지 못하는 문항을 폐기하는 운영 방식을 택했다.\n실제 입사 후 성과와의 연결도 아직 검증 중이다. 모든 신규 입사자를 대상으로 45일과 90일 시점에 AI 역량을 확인해 면접에서 측정한 역량이 현업에서도 유지되거나 향상되는지 살필 계획이다. 이후에는 초기 라운드 결합, 변화별 A/B 테스트, 온사이트 전 단계의 새로운 신호도 검토한다.\n7. 지원자와 기업에 주는 실질적인 시사점 Coinbase 지원자는 AI를 사용하지 않는 환경을 가정해 암기한 답을 연습하기보다, 실제 첫 출근 날처럼 준비해야 한다. 저장소를 읽고, AI에게 작업을 지시하고, 생성된 코드를 검증하고, 틀린 부분을 설명하며 수정하는 연습이 더 직접적인 준비가 된다.\n기업이 얻을 교훈도 분명하다.\n실제 업무에서 AI를 허용한다면 면접에서도 AI를 활용하는 능력을 평가해야 한다. 기존 문제에 AI만 켜는 방식으로는 새로운 역량을 측정할 수 없다. 평가 항목을 추가하기 전에 기존 라운드의 중복과 측정 실패를 확인해야 한다. AI 역량은 사용량이 아니라 도구 선택, 적용 판단, 한계 인식으로 정의해야 한다. 문항은 정기적으로 검증하고, 더 이상 차이를 만들지 못하면 폐기해야 한다. 결론 및 시사점 한 줄 결론: AI 시대의 엔지니어 면접은 코드를 빨리 작성하는 사람보다 AI의 결과를 현실의 시스템과 책임에 맞게 판단하는 사람을 찾아야 한다.\nCoinbase의 사례는 AI 면접을 별도 과목으로 추가한 사례가 아니라, 엔지니어링 업무의 중심이 이동한 만큼 평가의 기준도 함께 이동시킨 사례다. 코드 생성 비용이 내려갈수록 무엇을 만들지 정하고, 결과가 맞는지 확인하고, 안전하게 운영하는 판단의 가치가 커진다.\n다만 Coinbase 스스로도 아직 초기 데이터를 다루고 있다고 밝힌다. AI 보조 코딩 평가가 실제 업무 성과를 얼마나 잘 예측하는지, 빠르게 변하는 모델 환경에서 어떤 문제가 오래 유효한지는 앞으로 검증해야 한다. 따라서 AI 시대의 좋은 면접은 완성된 정답지가 아니라, 데이터를 통해 계속 문항과 신호를 고치는 운영 시스템에 가깝다.\n","wordCount":1194,"tags":["AI","엔지니어링","채용","기술면접","코딩에이전트"],"categories":["AI","Engineering"],"frameworks":["Evidence-based iteration","Human-in-the-loop"],"mental_models":["Signal over Ritual","Feedback Loops"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Coinbase의 AI 생성 코드 비중은 2025년 1분기 5.7%에서 4분기 50%를 넘었고, 현재는 인간 검토를 전제로 거의 100%에 이르렀다.","기존 면접은 암기한 아키텍처 패턴을 측정하는 거짓 양성·거짓 음성을 만들었고, 두 라운드 사이에 84%의 높은 상관이 있었다.","프론트엔드 파일럿, 백엔드 저장소 기반 과제, 전사 AI 역량 평가의 세 단계로 면접을 재구축했다.","AI 역량은 도구 사용, 적절한 적용, 한계 이해의 세 차원으로 평가하며, 핵심 신호는 저장소 디버깅·AI 시스템 설계·리더십 행동이다.","면접 문항의 유효기간과 실제 업무 성과 예측력은 아직 검증 중이며, 분기별 검토와 입사 후 45·90일 측정을 병행한다."],"related":["posts/modern-engineering-values","posts/why-ai-hasnt-replaced-software-engineers","posts/agentic-software-engineering"]},{"title":"AI가 무엇이든 만들 수 있을 때, 남는 것은 취향이다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/taste-is-all-thats-left/","section":"posts","date":"2026-08-08T10:11:44+09:00","lastmod":"2026-08-08T10:11:44+09:00","description":"NotAShelf의 글을 바탕으로, AI가 제작 비용을 낮출수록 구현보다 선택·검증·삭제의 판단이 중요해지고 그 판단 감각은 마찰과 실패에서 형성된다는 주장을 살펴본다.","summary":"NotAShelf의 Taste Is All That\u0026rsquo;s Left는 AI가 무엇이든 빠르게 만들어 주는 시대에 소프트웨어 제작자의 가치가 어디로 이동하는지 묻는다. 원문의 답은 취향(taste)이다. 여기서 말하는 취향은 색상이나 문체에 대한 개인적 선호가 아니라, 여러 개의 그럴듯한 결과 중 무엇이 맞고 무엇이 부족한지 알아보는 판단 감각이다.\nTaste 핵심 정리 병목의 이동: AI는 아이디어를 작동하는 결과물로 바꾸는 비용을 크게 낮추지만, 무엇을 만들 가치가 있는지는 대신 결정하지 않는다. 노력이라는 필터의 제거: 예전에는 제작 비용이 낮은 품질의 결과물이 시장에 쏟아지는 것을 자연스럽게 억제했다. 이제 그 필터가 약해져 선택과 큐레이션이 중요해졌다. 취향의 형성: 취향은 좋은 결과물을 소비한다고 생기지 않는다. 직접 만든 나쁜 결과물을 오래 겪고 실패를 반복하면서 쌓인다. 보이지 않는 비용: 취향은 “다시 하자”라고 말하게 하지만, 그로 인해 막은 사고나 거절한 평범한 결과는 대시보드에 잘 드러나지 않는다. 실무적 결론: AI 활용의 경쟁력은 더 많이 생성하는 데 있지 않고, 무엇을 남기고 버릴지 판단하는 기준을 명시하는 데 있다. 1) 제작의 벽이 낮아졌다 소프트웨어를 만들 때 가장 큰 장벽은 오랫동안 아이디어와 작동하는 프로그램 사이에 있었다. API 문서를 읽고, 잘못된 버전을 붙잡고, 오류를 고치며 몇 시간 또는 몇 주를 보내야 했다. 실제로 배포되는 결과물을 만드는 일은 말로만 아이디어를 설명하는 사람과 끝까지 실행하는 사람을 가르는 벽이었다.\n","content":"NotAShelf의 Taste Is All That\u0026rsquo;s Left는 AI가 무엇이든 빠르게 만들어 주는 시대에 소프트웨어 제작자의 가치가 어디로 이동하는지 묻는다. 원문의 답은 취향(taste)이다. 여기서 말하는 취향은 색상이나 문체에 대한 개인적 선호가 아니라, 여러 개의 그럴듯한 결과 중 무엇이 맞고 무엇이 부족한지 알아보는 판단 감각이다.\nTaste 핵심 정리 병목의 이동: AI는 아이디어를 작동하는 결과물로 바꾸는 비용을 크게 낮추지만, 무엇을 만들 가치가 있는지는 대신 결정하지 않는다. 노력이라는 필터의 제거: 예전에는 제작 비용이 낮은 품질의 결과물이 시장에 쏟아지는 것을 자연스럽게 억제했다. 이제 그 필터가 약해져 선택과 큐레이션이 중요해졌다. 취향의 형성: 취향은 좋은 결과물을 소비한다고 생기지 않는다. 직접 만든 나쁜 결과물을 오래 겪고 실패를 반복하면서 쌓인다. 보이지 않는 비용: 취향은 “다시 하자”라고 말하게 하지만, 그로 인해 막은 사고나 거절한 평범한 결과는 대시보드에 잘 드러나지 않는다. 실무적 결론: AI 활용의 경쟁력은 더 많이 생성하는 데 있지 않고, 무엇을 남기고 버릴지 판단하는 기준을 명시하는 데 있다. 1) 제작의 벽이 낮아졌다 소프트웨어를 만들 때 가장 큰 장벽은 오랫동안 아이디어와 작동하는 프로그램 사이에 있었다. API 문서를 읽고, 잘못된 버전을 붙잡고, 오류를 고치며 몇 시간 또는 몇 주를 보내야 했다. 실제로 배포되는 결과물을 만드는 일은 말로만 아이디어를 설명하는 사람과 끝까지 실행하는 사람을 가르는 벽이었다.\n생성형 AI는 이 벽을 없애기보다 빌려 쓸 수 있는 형태로 바꾼다. 자연어로 설명하면 사람이 처음부터 타이핑하는 것보다 빠르게 그럴듯한 결과를 얻을 수 있다. 아이디어에서 결과물까지의 거리가 급격히 짧아진 것이다.\n그렇다고 벽을 오르는 동안 배운 능력까지 사라지는 것은 아니다. 원문이 말하듯 그 가치는 다른 위치로 이동한다. 이제 중요한 질문은 “만들 수 있는가”에서 “무엇을 만들어야 하는가”로 옮겨간다.\n2) “충분히 좋은 결과”가 품질의 기준을 녹인다 AI 결과물은 언제나 완벽하지 않지만, 많은 경우 충분히 그럴듯하다. 바로 이 “충분히 좋음”이 문제다. 제작이 비쌌던 시절에는 노력 자체가 보이지 않는 필터였다. 기능 하나를 만들기 위해 상당한 시간이 필요했으므로, 아무도 평범한 변형을 수천 개 만들어 배포하지 않았다.\n이제 제작 비용이 내려가면서 이 필터가 약해졌다. 세 가지 구현안이 모두 작동할 때, 그중 무엇을 남길지는 제작 비용이 아니라 사람의 판단에 달려 있다. 어떤 결과가 요구사항의 핵심을 건드리는지, 어떤 추상화가 나중에 더 큰 문제를 만드는지, 어디까지가 충분하고 어디서부터는 타협인지 결정해야 한다.\n따라서 AI 시대에는 생성 능력보다 판별 능력이 더 중요해진다. 기계가 결과를 만들 수 있다는 사실은 그 결과가 존재할 이유를 증명하지 않는다.\n3) 취향은 장식이 아니라 압축된 판단이다 원문은 로버트 피어시그의 『Zen and the Art of Motorcycle Maintenance』가 말한 Quality를 빌려 취향을 설명한다. 좋은 정비사는 엔진이 이상하다는 것을 원인을 말하기 전에 감지한다. 좋은 편집자는 문장이 처진다는 것을 문법 규칙으로 설명하기 전에 알아챈다.\n취향도 비슷하다. 여러 결과를 보고 “이건 아니다. 다시 하자”라고 말하는 판단이 먼저 도착하고, 그 이유를 언어로 설명하는 일은 나중에 따라온다. 이는 괄호를 어느 줄에 둘지 같은 표면적 취향이 아니다. 데이터 구조가 실제 규모를 감당하는지, 개인정보 보호가 말뿐이 아닌지, 세 번째 구현이 단지 괜찮을 뿐 정말 맞는지를 가르는 감각이다.\nAI는 이 판단을 대신하지 못한다. 다만 판단이 없는 상태에서도 그럴듯한 결과를 싸게 생산해, 판단의 부재를 무시하기 쉽게 만든다.\n4) 마찰은 장애물이 아니라 커리큘럼이었다 취향은 좋은 작품을 많이 소비한다고 자동으로 생기지 않는다. 직접 나쁜 것을 만들고, 그 결과를 사용자가 겪는 모습을 보고, 실패의 불편함을 오래 기억하면서 형성된다. 그런 경험이 쌓여야 다음번에 무엇을 피하고 무엇에 시간을 써야 할지 알 수 있다.\n이 관점에서 제작 과정의 마찰은 단순한 비효율이 아니다. 잘못된 설계로 며칠을 보내고, 실제 환경에서 깨지는 기능을 고치고, 버릴 수밖에 없는 결과를 마주하는 과정이 판단을 가르치는 수업이었다. 비용을 반복해서 지불하는 동안 어떤 벽을 오를 가치가 있는지 배우게 된다.\nAI가 첫날부터 유창한 결과를 내놓으면 이 도제 과정의 일부를 건너뛸 수 있다. 당장은 같은 단계의 사람보다 생산량이 많아 보이지만, 무엇을 멈춰야 하는지 또는 무엇이 충분하지 않은지를 배울 기회도 줄어든다. 생산성 지표는 올라가는데 판단의 근육은 충분히 자라지 않는 상황이 생길 수 있다는 뜻이다.\n5) 취향은 시장에서 잘 보상되지 않는다 취향이 있는 사람은 그럴듯하지만 틀린 결과를 돌려보내고 다시 만들자고 말한다. 그동안 취향이 없는 사람은 이미 결과물을 배포하고 다음 작업으로 넘어갈 수 있다. 시장은 두 사람을 같은 시간표로 평가하기 쉽고, 더 오래 고민한 이유를 대시보드에서 발견하지 못한다.\n취향의 비용은 분명하지만 그 효과는 잘 보이지 않는다. 막아낸 장애, 만들지 않은 기능, 배포하지 않은 평범한 결과에는 기록이 남지 않는다. 반대로 “작동하고 테스트도 통과하는” 결과물은 빠르게 성과로 집계된다.\n원문은 이를 프랭크퍼트가 구분한 거짓말과 허튼소리의 차이에 연결한다. 문제의 결과물이 반드시 틀린 것은 아니다. 진실이나 품질에 무관심한 채 작동하고 통과하는 것만으로 충분하다고 여기는 상태가 더 위험하다. AI가 이런 결과를 대량으로 만들 수 있게 되면, 평범함은 가장 풍부한 자원이 된다.\n6) 제작량이 무한해질수록 선택이 일이 된다 원문은 스터전의 법칙, 즉 “모든 것의 90%는 형편없다”는 관찰을 끌어온다. 중요한 변화는 그 비율 자체가 아니다. 이전에는 형편없는 결과를 만드는 데도 시간이 들었기 때문에, 전체 유입량이 제작 비용에 의해 제한됐다.\nAI는 그 조절 장치를 제거한다. 나쁜 결과의 비율이 그대로라면, 생산량이 무한히 커질수록 잡음도 함께 무한히 늘어난다. 진짜 결과물은 그럴듯한 아무것이나 보이는 바다 속에 도착한다.\n이때 희소해지는 행위는 제작이 아니라 선택이다. 무엇을 만들지, 무엇을 버릴지, 무엇을 계속 다듬을지, 무엇을 존재하게 둘지를 정해야 한다. 제작이 비싸던 시절에는 큐레이션이 부가적인 미덕이었다면, 제작이 싸진 시대에는 큐레이션 자체가 핵심 작업이 된다.\n7) 질문은 “만들 수 있는가”에서 “만들어야 하는가”로 바뀐다 산업화가 대량생산을 가능하게 했을 때 윌리엄 모리스와 존 러스킨은 값싸고 동일한 상품의 홍수 앞에서 “만들 수 있는가”와 다른 질문을 던졌다. 그것을 만들어야 하는가, 그리고 왜 그런 방식으로 만들어야 하는가라는 질문이다.\nAI도 비슷한 전환을 만든다. 도구가 사람의 능력을 없앤다기보다, 제작에 붙어 있던 통행료를 걷어낸다. 그동안 코드를 쓰고 라이브러리를 연결하는 일이 판단을 실행하기 위한 필수 비용이었다면, 이제 그 비용이 줄어들면서 판단 자체가 드러난다.\n그래서 AI 시대의 좋은 작업자는 가장 많은 결과물을 내는 사람이 아니다. 충분히 괜찮아 보이는 결과를 거절하고, 더 나은 이유가 있을 때 다시 만들며, 무엇을 만들지 말아야 하는지 설명할 수 있는 사람이다.\n8) 실무에서는 의도적인 마찰을 설계해야 한다 그렇다고 과거의 느린 제작 과정을 그대로 복원해야 한다는 뜻은 아니다. 원문에서 도출할 수 있는 실무적 방향은 마찰을 없애지 말자는 것이 아니라, 학습과 판단에 필요한 마찰을 의도적으로 남기자는 데 있다.\nAI에게 결과물만 요구하지 말고, 문제 정의·제약·대안·실패 가능성을 함께 설명하게 한다. 생성된 결과를 바로 채택하지 않고, 왜 이 결과가 존재해야 하는지와 어떤 기준을 통과했는지를 먼저 확인한다. 테스트 통과 여부와 별개로, 유지보수자가 구조와 결정 이유를 설명할 수 있는지 점검한다. 주니어 구성원에게 AI가 완성한 결과만 전달하지 말고, 작은 기능을 직접 판단하고 실패를 겪을 수 있는 소유권을 준다. 작업량만 측정하지 않고, 잘못된 방향을 일찍 버린 사례와 불필요한 기능을 삭제한 사례도 기록한다. 핵심은 사람이 모든 코드를 손으로 작성하게 만드는 것이 아니다. AI가 생산한 가능성 중 어떤 것을 현실로 만들지 판단하는 과정에 사람이 실제로 참여하도록 만드는 것이다.\n9) 글의 후기 역시 논지를 시험한다 원문 후반에는 독자들의 반응에 대한 자기비판이 붙어 있다. 글이 해커 뉴스 첫 화면에 올라간 뒤 일부 독자는 문체가 “AI 슬롭”처럼 읽힌다고 지적했다. 저자는 그 비판을 받아들이면서도 이 글이 LLM으로 작성되거나 검토된 글은 아니라고 밝혔다. 짧은 문장, 반복되는 반전, 한 단어로 끊는 문장이 사람의 글과 생성형 모델의 글에서 모두 나타날 수 있다는 점도 인정했다.\n이 후기는 본문의 주장과 묘하게 맞물린다. 사람이 썼는지 기계가 썼는지를 맞히는 것만으로는 품질을 판단하기 어렵다. 결국 독자가 다시 물어야 하는 질문은 글의 출처보다 글이 무엇을 주장하는지, 그 주장이 어떤 판단을 요구하는지, 그리고 그 판단을 감당할 만큼 내용이 구체적인지다.\n결론 및 시사점 한 줄 결론: AI가 무엇이든 만들 수 있게 될수록, 사람의 가장 희소한 능력은 더 많이 생성하는 힘이 아니라 무엇이 존재할 가치가 있는지 판단하는 취향이다.\n이 글의 핵심은 AI가 인간의 기술을 모두 무가치하게 만든다는 비관론이 아니다. 제작에 필요한 노동이 줄어들면서 그 노동 안에 가려져 있던 판단이 전면으로 나온다는 주장이다. 취향은 감각적인 장식이 아니라, 실패를 통과하며 쌓인 선택 기준이고 평범한 결과를 거절하는 힘이다.\n따라서 AI를 잘 쓰는 팀은 생성량만 늘리지 않는다. 무엇을 만들지 결정하는 기준, 결과를 이해하는 검증 절차, 틀린 방향을 삭제할 권한을 함께 설계한다. AI가 생산을 풍요롭게 할수록 사람은 선택의 책임을 더 선명하게 맡아야 한다.\n관련 포스트 Modern Engineering Values — AI 시대, 코딩이 병목이 아닐 때 엔지니어에게 남은 것 Understanding Is the New Bottleneck - AI 시대의 병목은 이해다 AI가 줄여야 할 것은 인원수가 아니라 팀 크기다 새로운 AI 시대, 진짜 희소 자원은 연구자 ","wordCount":1231,"tags":["AI","소프트웨어","엔지니어링","판단","취향"],"categories":["AI"],"frameworks":["Taste as Judgment","Friction as Curriculum","Curation over Production"],"mental_models":["Bottleneck Shift","Signal-to-Noise","Opportunity Cost"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI는 아이디어와 작동하는 결과물 사이의 거리를 줄이지만, 그 결과물이 존재할 가치가 있는지는 결정하지 않는다.","생산 비용이 낮아지면 노력은 품질의 자연스러운 필터가 되지 못하고, 사람의 판단과 큐레이션이 그 자리를 차지한다.","취향은 장식적 선호가 아니라 실패·마찰·반복을 통해 쌓인 압축된 판단이며, 그럴듯한 결과를 거절하고 다시 만들게 하는 힘이다.","AI 시대의 실무는 생성량보다 선택 기준, 삭제 용기, 이해 가능한 검증 루프를 설계하는 데 달려 있다."],"related":["posts/modern-engineering-values","posts/understanding-is-the-new-bottleneck-geoffrey-litt","posts/ai-small-teams-not-headcount","software/ai-era-researchers-not-engineers"]},{"title":"AI 조언은 왜 사람을 더 확신에 찬 오답으로 이끄는가","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-advice-cognitive-surrender/","section":"posts","date":"2026-07-24T12:26:16+09:00","lastmod":"2026-07-24T12:26:16+09:00","description":"AI의 조언이 사람의 판단을 돕기보다 무지를 인정하는 습관을 억누를 수 있다는 최신 연구와 실무적 대응 원칙을 정리한다.","summary":"AI에게 답을 물으면 판단이 더 정확해질 것이라고 생각하기 쉽다. 그러나 최근 연구는 AI가 틀린 답을 제시하는 상황에서, 사람의 정확도뿐 아니라 자신이 모른다는 사실을 알아차리는 능력까지 약화될 수 있다고 지적한다.\n원문: AI advice made people three times less accurate but twice as confident\nTL;DR 요약 핵심 결과: AI를 사용할 수 있을 때 \u0026lsquo;모르겠다\u0026rsquo;고 답한 비율은 44%에서 3%로 감소했다. 정확도와 확신의 역전: 정답률은 27%에서 9%로 떨어졌지만, 답에 대한 확신은 30%에서 76%로 높아졌다. 실험 설계: 연구진은 AI가 자주 틀리는 영화 속 유니폼 색상 같은 시각적 세부사항을 질문했다. 실무 원칙: AI의 답을 먼저 보지 말고 자신의 판단을 기록한 뒤, 근거와 불확실성을 대조해야 한다. 연구가 보여준 판단의 변화 연구진은 프랑스와 이탈리아의 세 대학 소속 연구자들로, Valerio Capraro, Chiara Marcoccia, Walter Quattrociocchi가 참여했다. 실험에서는 영화 장면의 시각적 세부사항처럼 AI 모델이 잘못 답하기 쉬운 질문을 사용했다. AI가 대체로 잘 맞히는 문제를 고른 것이 아니라, 도구의 신뢰성이 낮은 상황에서 사람이 어떻게 반응하는지를 본 것이다.\n","content":"AI에게 답을 물으면 판단이 더 정확해질 것이라고 생각하기 쉽다. 그러나 최근 연구는 AI가 틀린 답을 제시하는 상황에서, 사람의 정확도뿐 아니라 자신이 모른다는 사실을 알아차리는 능력까지 약화될 수 있다고 지적한다.\n원문: AI advice made people three times less accurate but twice as confident\nTL;DR 요약 핵심 결과: AI를 사용할 수 있을 때 \u0026lsquo;모르겠다\u0026rsquo;고 답한 비율은 44%에서 3%로 감소했다. 정확도와 확신의 역전: 정답률은 27%에서 9%로 떨어졌지만, 답에 대한 확신은 30%에서 76%로 높아졌다. 실험 설계: 연구진은 AI가 자주 틀리는 영화 속 유니폼 색상 같은 시각적 세부사항을 질문했다. 실무 원칙: AI의 답을 먼저 보지 말고 자신의 판단을 기록한 뒤, 근거와 불확실성을 대조해야 한다. 연구가 보여준 판단의 변화 연구진은 프랑스와 이탈리아의 세 대학 소속 연구자들로, Valerio Capraro, Chiara Marcoccia, Walter Quattrociocchi가 참여했다. 실험에서는 영화 장면의 시각적 세부사항처럼 AI 모델이 잘못 답하기 쉬운 질문을 사용했다. AI가 대체로 잘 맞히는 문제를 고른 것이 아니라, 도구의 신뢰성이 낮은 상황에서 사람이 어떻게 반응하는지를 본 것이다.\nAI 조언을 볼 수 없었던 집단에서는 답을 유보하고 \u0026lsquo;모르겠다\u0026rsquo;고 말한 비율이 44%였다. 반면 AI 조언을 볼 수 있었던 집단에서는 이 비율이 3%까지 떨어졌다. 사람들은 AI가 제시한 답을 참고하는 데 그치지 않고, 자신이 판단을 보류할 필요 자체를 덜 느끼게 됐다.\n정확도도 27%에서 9%로 낮아졌다. 그런데 확신은 반대로 30%에서 76%로 상승했다. 즉, 덜 정확해졌는데 더 확신하는 상태가 나타났다. 일부 참가자는 혼자 풀었을 때 맞힐 수 있었던 문제에서도 AI를 참고한 뒤 오답을 선택했다.\n돈을 걸어도 효과는 제한적이었다 연구진은 참가자에게 금전적 보상을 제공하면 더 신중해질 수 있는지도 살폈다. 보상은 \u0026lsquo;모르겠다\u0026rsquo;고 답한 비율을 3%에서 8%로, 정확도를 9%에서 16%로 높였다.\n그러나 AI가 없을 때의 기준인 44%와 27%에는 크게 못 미쳤다. 금전적 동기는 신중함을 일부 회복시켰지만, AI가 만들어낸 과도한 확신을 충분히 상쇄하지 못했다.\n문제는 틀린 답보다 \u0026lsquo;모른다는 감각\u0026rsquo;의 상실이다 AI의 오답은 새로운 문제가 아니다. 중요한 변화는 사람이 원래 가지고 있던 판단 유보의 습관이 약해진다는 점이다. 사람은 자신이 아는 것과 모르는 것을 구분해야 추가 조사를 하거나 다른 사람에게 도움을 요청할 수 있다.\n하지만 대화형 AI는 대부분의 질문에 즉시 답하도록 설계되어 있다. 답변이 불가능하거나 불확실한 상황에서도 매끄러운 문장과 단정적인 어조를 만들어낸다. 사용자가 이 형식에 익숙해지면, 답이 있다는 사실을 지식이 있다는 사실로 착각하기 쉬워진다.\n이 현상은 Wharton 연구자들이 말한 인지적 항복(cognitive surrender) 과도 연결된다. 사람은 AI의 정답을 받아들이는 것뿐 아니라, AI의 오답도 높은 비율로 수용하며 자신의 확신을 오히려 높일 수 있다.\nAI를 안전하게 사용하는 방법 이 연구가 AI 사용을 중단해야 한다는 뜻은 아니다. 핵심은 AI에게 사고의 첫 단계와 마지막 판단을 동시에 넘기지 않는 것이다.\n먼저 자신의 답과 확신 정도를 적는다. AI에게 정답을 묻기보다 반례, 누락된 정보, 검증 방법을 요청한다. AI의 주장과 근거를 분리하고, 원출처를 직접 확인한다. 확신이 커졌는지가 아니라 실제 정확도가 높아졌는지를 측정한다. 교육에서는 기초 개념과 독립적 문제 해결을 익힌 뒤 AI를 도입한다. 특히 어린이나 초보자에게는 이 원칙이 중요하다. 아직 자신의 지식 한계를 판단하는 능력을 충분히 형성하지 못한 상태에서 AI가 항상 답을 내놓는 환경에 익숙해지면, 학습의 핵심인 시행착오와 오류 인식의 기회를 잃을 수 있다.\n결론 및 시사점 AI의 유창함은 정확성의 증거가 아니다. 사람의 판단력을 지키려면 AI 사용 전에 자신의 생각을 먼저 외부화해야 한다. 조직과 교육기관은 AI 활용량보다 독립적 판단력과 검증 성과를 평가해야 한다. 한 줄 결론: AI는 답을 빠르게 제공하지만, 그 답이 틀렸을 때조차 우리가 모른다는 사실을 잊게 만들 수 있으므로 판단 유보와 검증을 사용 과정에 명시적으로 포함해야 한다.\n","wordCount":505,"tags":["AI","비판적 사고","인지 편향","AI 리터러시","연구"],"categories":["AI"],"frameworks":["비판적 사고","인간-도구 상호작용"],"mental_models":["인지적 항복","자동화 편향","불확실성 인식"],"philosophy_type":"epistemology","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 조언에 접근할 수 있자 '모르겠다'고 답한 비율이 44%에서 3%로 떨어졌다","정확도는 27%에서 9%로 하락했지만, 자신의 답에 대한 확신은 30%에서 76%로 상승했다","연구진은 AI가 틀리기 쉬운 영화 장면의 시각적 세부사항을 문제로 사용했다","AI를 정답 기계가 아니라 검증 대상이자 사고 보조 도구로 사용해야 한다"],"related":[]},{"title":"클라우드 소프트웨어 팩토리 — 코딩 에이전트를 ROI가 보이는 개발 시스템으로 바꾸는 법","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/cloud-software-factory/","section":"posts","date":"2026-07-15T23:46:05+09:00","lastmod":"2026-07-15T23:46:05+09:00","description":"Zach Lloyd가 제안하는 클라우드 소프트웨어 팩토리의 개념과 구조를 정리한다. 이슈 분류부터 배포·모니터링까지 에이전트와 사람이 협력하는 개발 자동화 루프, 핵심 인프라, ROI 측정법, 벤더 선택 기준을 살펴본다.","summary":"Warp 창업자이자 전 Google Docs 수석 엔지니어인 Zach Lloyd는 글 The guide to software factories에서 소프트웨어 개발의 다음 변화를 설명한다. 개발자가 터미널에서 코딩 에이전트를 직접 조종하는 방식에서, 이슈 분류부터 배포와 모니터링까지를 클라우드에서 자동으로 흘려보내는 클라우드 소프트웨어 팩토리로 이동한다는 주장이다.\nFactory 핵심 정리 핵심 변화: 대화형 에이전트를 개발자별 도구로 두는 대신, SDLC 전체를 하나의 자동화 루프로 연결한다. 자동화 범위: 원문에서 소개한 Warp 팀의 경험으로는 전체 PR의 약 20~30%를 자동화하고 있으며, 완전 자동화가 어려운 작업도 리뷰·검증·모니터링은 자동화할 수 있다. 세 계층: 클라우드 런타임·샌드박스, 오케스트레이션·통합·사람 개입, 측정·평가·메모리로 구성된다. 경영 관점: 토큰 사용량이 아니라 실제 출시된 제품과 비용의 비율로 에이전트의 사업 가치를 측정해야 한다. 도입 원칙: 사람의 개입 경로를 남기고, 여러 모델·하네스를 지원하며, 데이터·컴퓨트·추론 엔드포인트의 선택권을 보존해야 한다. 대화형 코딩 에이전트만으로는 부족하다 Copilot, Cursor, Claude Code 같은 도구를 개발자에게 배포하는 일은 AI 도입의 좋은 출발점이다. 실제로 많은 조직이 먼저 모든 엔지니어에게 도구를 제공하고, 사용량과 도입률을 추적하며, 토큰을 많이 쓰는 팀을 격려했다. 새로운 기술을 현장에 빠르게 퍼뜨리는 단계에서는 합리적인 접근이다.\n","content":"Warp 창업자이자 전 Google Docs 수석 엔지니어인 Zach Lloyd는 글 The guide to software factories에서 소프트웨어 개발의 다음 변화를 설명한다. 개발자가 터미널에서 코딩 에이전트를 직접 조종하는 방식에서, 이슈 분류부터 배포와 모니터링까지를 클라우드에서 자동으로 흘려보내는 클라우드 소프트웨어 팩토리로 이동한다는 주장이다.\nFactory 핵심 정리 핵심 변화: 대화형 에이전트를 개발자별 도구로 두는 대신, SDLC 전체를 하나의 자동화 루프로 연결한다. 자동화 범위: 원문에서 소개한 Warp 팀의 경험으로는 전체 PR의 약 20~30%를 자동화하고 있으며, 완전 자동화가 어려운 작업도 리뷰·검증·모니터링은 자동화할 수 있다. 세 계층: 클라우드 런타임·샌드박스, 오케스트레이션·통합·사람 개입, 측정·평가·메모리로 구성된다. 경영 관점: 토큰 사용량이 아니라 실제 출시된 제품과 비용의 비율로 에이전트의 사업 가치를 측정해야 한다. 도입 원칙: 사람의 개입 경로를 남기고, 여러 모델·하네스를 지원하며, 데이터·컴퓨트·추론 엔드포인트의 선택권을 보존해야 한다. 대화형 코딩 에이전트만으로는 부족하다 Copilot, Cursor, Claude Code 같은 도구를 개발자에게 배포하는 일은 AI 도입의 좋은 출발점이다. 실제로 많은 조직이 먼저 모든 엔지니어에게 도구를 제공하고, 사용량과 도입률을 추적하며, 토큰을 많이 쓰는 팀을 격려했다. 새로운 기술을 현장에 빠르게 퍼뜨리는 단계에서는 합리적인 접근이다.\n하지만 사용량이 늘었다고 사업 가치가 늘어난 것은 아니다. 개발자가 에이전트를 많이 사용해도 토큰 비용과 사람의 검토 시간을 합친 총비용이 실제 고객 가치로 이어졌는지는 불분명할 수 있다. 개발자마다 다른 모델을 선택하고, 프롬프트를 작성하고, MCP를 설치하고, 결과를 검증하면 비용·보안·품질의 편차도 커진다.\n대화형 도구의 근본적인 문제는 사람이 매번 실행 방식을 결정한다는 것이다. 어떤 사람은 간단한 작업에도 가장 비싼 모델을 사용하고, 어떤 사람은 과도한 권한을 가진 MCP를 설치하며, 어떤 사람은 에이전트의 결과를 충분히 검증하지 않는다. 조직 차원에서 ROI, 보안, 규정 준수를 관리하기가 어려워지는 이유다.\nLloyd가 제안하는 해법은 개발자별 환경에 통제 장치를 계속 덧붙이는 일이 아니다. 개발 작업을 중앙화된 클라우드 팩토리로 옮겨 실행 환경, 권한, 워크플로, 관측성을 표준화하는 일이다. 이는 20년 전 서버와 개발 인프라가 클라우드로 이동하면서 얻었던 통제력·가시성·표준화의 효과를 에이전트 개발에도 적용하는 방식이다.\n클라우드 소프트웨어 팩토리란 무엇인가 클라우드 소프트웨어 팩토리는 개발의 핵심 루프를 에이전트와 사람의 협업으로 자동화하는 시스템이다. 흐름은 다음과 같다.\n단계 주요 역할 이슈 접수 사람이나 모니터링 에이전트가 작업을 등록한다 트리아지 문제를 이해하고 재현하며 자동화 가능성을 판단한다 명세 범위가 크거나 불명확하면 에이전트와 사람이 요구사항을 구체화한다 구현 구현 에이전트가 코드를 수정한다 리뷰 코드 리뷰 에이전트가 변경을 검토한다 검증 테스트, 컴퓨터 사용, 기타 검증 에이전트가 결과를 확인한다 승인·배포 사람이 코드와 검증 결과를 확인한 뒤 CI/CD를 통해 배포한다 모니터링 모니터링 에이전트가 운영 결과를 관찰하고 새 이슈를 만든다 이 구조에서 중요한 것은 모든 작업을 무조건 자동으로 처리하는 것이 아니다. 트리아지 에이전트가 작업을 세 갈래로 나눈다.\n범위가 명확하고 자동화 가능한 작업은 구현 에이전트로 바로 보낸다. 명세가 필요한 작업은 사람과 명세 에이전트가 반복해서 범위를 정한 뒤 구현으로 넘긴다. 모호하거나 위험한 작업은 사람의 입력을 요청하거나 일단 보류한다. 따라서 팩토리는 단순한 에이전트 실행기가 아니라 작업을 자동화 가능한 경로로 라우팅하는 운영 시스템에 가깝다. Lloyd는 현재 Warp 팀의 경험을 바탕으로 전체 PR의 약 20~30%가 이슈에서 배포까지 자동화 가능하다고 설명한다. 나머지 작업도 리뷰, 검증, 모니터링처럼 일부 단계는 자동화할 수 있다. 이 수치는 보편적 벤치마크라기보다 원문 저자의 실무 경험으로 이해해야 한다.\n팩토리를 구성하는 세 계층 1. 클라우드 호스트·런타임·샌드박스·코딩 에이전트 안정적인 자동화를 만들려면 에이전트를 개발자의 노트북에서 분리해야 한다. 노트북은 꺼져 있을 수 있고, 사람마다 설치된 도구와 환경이 다르며, 권한을 일관되게 관리하기 어렵다.\n실행 환경은 기존 클라우드 개발 환경을 사용하거나, 환경을 Docker 이미지로 만들거나, Kubernetes 같은 오케스트레이션 플랫폼 위에 구성할 수 있다. AWS나 Google Cloud 같은 퍼블릭 클라우드뿐 아니라 Modal, Daytona 같은 에이전트 전용 호스팅 플랫폼, 또는 기업 자체 인프라도 선택지가 된다.\n런타임 안에는 Claude Code, Codex, Cursor, OpenCode, Warp 같은 코딩 에이전트 하네스가 들어간다. 에이전트는 코드 저장소뿐 아니라 GitHub·GitLab, 이슈 추적 시스템, Slack·Teams, MCP와 CLI에도 접근해야 한다. 이때 다음 두 질문을 분리해서 관리해야 한다.\n인증: 에이전트가 누구의 신원으로 행동하는가? 인가: 그 신원이 어떤 리소스에 어떤 권한으로 접근할 수 있는가? 팩토리의 첫 계층은 단순히 컨테이너를 띄우는 문제가 아니다. 실행 환경, 도구, 비밀, 네트워크, 저장소 권한을 함께 표준화하는 보안 경계다.\n2. 오케스트레이션·통합·사람 개입 클라우드에 에이전트를 올려두는 것만으로는 일이 시작되지 않는다. 사람의 요청, 새 티켓, 일정, 모니터링 알림 같은 트리거를 받아 적절한 에이전트와 워크플로를 실행하는 오케스트레이션 계층이 필요하다.\n이 계층은 특정 순서의 SDLC 루프를 실행하면서도 확장 가능해야 한다. 트리아지·명세·구현·리뷰·검증·배포·모니터링 외에 카나리 배포, 죽은 코드 정리, 회귀 분석 같은 작업을 추가할 수 있어야 한다. 동시에 모든 에이전트의 현재 상태와 과거 실행 기록을 한눈에 보여주는 팩토리 관제실 역할도 해야 한다.\n통합은 새로운 목적지를 만드는 것이 아니라 팀이 이미 일하는 곳에서 팩토리를 사용할 수 있게 하는 방향이어야 한다. Slack이나 Teams에서 작업을 만들고, Jira나 Linear에서 상태를 확인하고, GitHub의 코드 리뷰에서 에이전트 동작을 조정할 수 있어야 한다. 리뷰 에이전트가 저장소의 규칙과 다른 조언을 한다면, 개발자가 리뷰 화면에서 바로 그 행동을 수정하도록 지시할 수 있어야 한다.\n사람의 개입은 실패를 보완하는 예외 처리가 아니라 팩토리의 기본 기능이다. 원문이 강조하는 핵심 프리미티브는 세 가지다.\nSteering: 실행 중인 에이전트 세션에 들어가 방향을 조정한다. Handoff: 에이전트 세션과 컨텍스트를 클라우드와 로컬 사이에서 옮긴다. Notifications: 도움이 필요한 순간 사람에게 알린다. 복잡한 작업을 클라우드에서 로컬 작업대로 넘기거나, 자동 검증 대신 사람이 직접 결과를 확인해야 하는 경우가 있다. 이 경로가 없으면 개발자는 팩토리를 우회하게 되고, 자동화 시스템은 오히려 마찰을 만든다.\n3. 측정·평가·메모리 팩토리 접근법의 경영적 의미는 개발 자동화를 측정하고 개선할 수 있다는 데 있다. Lloyd가 제시하는 간단한 지표는 다음과 같다.\n팩토리 효율 = 출시된 제품 / 토큰 비용\n이 식은 단순하지만 방향을 바꾼다. 토큰을 얼마나 많이 썼는지가 아니라, 일정한 비용으로 고객에게 전달된 결과를 얼마나 만들었는지를 본다. 이를 위해서는 작업이 클라우드에서 중앙화되고, 각 단계의 입력·출력·비용·지연·재작업이 기록되어야 한다.\n그 위에서 다음과 같은 실험을 진행할 수 있다.\n작업 유형별로 어떤 모델과 하네스 조합이 가장 적합한지 비교한다. MCP와 스킬의 구성과 설명이 결과에 미치는 영향을 평가한다. 트리아지 비용을 줄이거나 컴퓨터 사용 검증의 정확도를 높이는 자기개선 에이전트를 운영한다. 과거 상호작용에서 명시적 규칙과 암묵적 패턴을 추출해 다음 작업의 컨텍스트에 반영한다. 메모리는 기업이 직접 소유하고 저장해야 한다. 에이전트가 배운 규칙과 작업 이력이 벤더 내부에만 남으면, 자동화 효율이 높아질수록 특정 플랫폼에 묶이는 역설이 발생한다.\n여러 하네스와 모델을 지원해야 한다 최고의 에이전트는 고정된 선택지가 아니다. 모델과 하네스의 비용·품질·속도는 빠르게 바뀌므로 팩토리는 여러 실행기를 교체하거나 혼합할 수 있어야 한다.\n모델 라우팅의 기준도 단순한 최고 성능이 아니다. 주어진 작업의 품질 기준을 통과하는 모델 중 가장 저렴하고 빠른 모델을 선택하는 것이 목표다. 한 작업 안에서도 초안 작성에는 가벼운 모델을 쓰고, 중요한 검토에는 더 강한 모델을 쓰는 식의 조합이 가능하다.\n단일 모델이나 단일 하네스에 고정하면 세 가지 위험이 커진다.\n비용 종속: 모델 공급자가 가격과 사용 조건을 바꿀 때 대응하기 어렵다. 가용성 종속: 모델 제공자의 장애가 개발 전체를 멈출 수 있다. 정책·지정학적 종속: 지역 규제나 수출 통제로 특정 모델을 사용할 수 없게 될 수 있다. 따라서 팩토리 벤더를 선택할 때는 여러 하네스와 모델을 지원하는지, 회사가 데이터를 소유하는지, 자체 호스팅을 포함해 다양한 컴퓨트를 선택할 수 있는지, Bedrock·Vertex·Azure 같은 자체 추론 엔드포인트를 연결할 수 있는지를 확인해야 한다. 벤더가 토큰을 재판매하는 구조라면 비용 최적화와 매출 확대 사이에 이해 충돌이 생길 수 있다는 점도 살펴봐야 한다.\n팩토리는 코드로 관리해야 한다 소프트웨어 팩토리는 일회성 설정이 아니라 CI/CD와 비슷한 인프라다. 따라서 팩토리의 구성, 워크플로, 권한, 모델 라우팅, 평가 기준을 파일로 정의하고 버전 관리하는 편이 좋다.\n이렇게 하면 세 가지 이점이 생긴다.\n변경 이력을 검토하고 되돌릴 수 있다. 에이전트가 팩토리 설정 자체를 수정할 수 있다. 개발 환경과 운영 환경의 차이를 줄일 수 있다. 다만 에이전트에게 팩토리 설정을 수정할 권한까지 주는 순간, 시스템은 자기 자신을 바꾸는 단계에 들어간다. 자동 평가와 사람의 승인, 권한 분리, 회귀 검증이 없으면 팩토리의 효율을 높이는 변경이 실제로는 보안과 품질을 훼손할 수 있다.\n직접 만들 것인가, 사서 쓸 것인가 Lloyd는 대부분의 회사가 팩토리 인프라 전체를 직접 만들 필요는 없다고 주장한다. 실행 환경, 오케스트레이션, 통합, 권한, 세션 이동, 관측성, 평가를 모두 개발하고 유지하는 일은 생각보다 크기 때문이다. 고객 문제를 해결해야 하는 팀의 핵심 역량을 내부 플랫폼 유지보수에 쓰게 될 수 있다.\n예외는 Stripe나 Uber처럼 개발 조직이 매우 크고, 기존의 복잡한 개발 인프라와 팩토리를 긴밀하게 결합해야 하는 경우다. 이 정도 규모에서는 자체 구축이 차별화된 운영 역량이 될 수 있다.\n글의 후반부는 Warp가 기업의 팩토리 구축을 돕는다는 제안으로 이어진다. 따라서 클라우드 팩토리의 필요성에 대한 설명과 Warp의 제품·사업 관점은 구분해서 읽어야 한다. 어떤 벤더를 선택하든 데이터 소유권, 여러 모델·하네스 지원, 컴퓨트 유연성, 자체 추론 엔드포인트 연결 여부를 계약 전에 확인하는 것이 핵심이다.\n실무에 적용할 때의 순서 이 글의 주장을 조직에 적용한다면 처음부터 모든 개발 업무를 자동화하려고 하기보다, 측정 가능하고 되돌릴 수 있는 흐름부터 시작하는 편이 현실적이다.\n한 가지 이슈 유형을 고른다. 반복적이고 입력과 성공 조건이 비교적 명확한 버그 수정이나 의존성 업데이트처럼 시작 범위가 좁은 작업이 적합하다. SDLC 단계를 기록한다. 트리아지부터 배포까지 각 단계의 처리 시간, 토큰 비용, 사람의 개입, 재작업, 실패 원인을 수집한다. 사람의 승인 지점을 정한다. 코드 리뷰와 운영 배포처럼 위험이 큰 단계에서는 자동 실행보다 명시적 승인을 우선한다. 클라우드 실행 환경을 표준화한다. 저장소, 테스트, 도구, 네트워크, 권한을 하나의 재현 가능한 런타임으로 묶는다. 자동화율보다 결과를 평가한다. 자동 처리한 이슈의 수보다 배포 후 결함, 롤백, 고객 가치, 총비용을 함께 본다. 실패를 팩토리 개선으로 연결한다. 에이전트가 실패한 이유를 새 규칙, 평가 케이스, 스킬, 라우팅 정책으로 바꾸고 회귀 여부를 확인한다. 이렇게 하면 팩토리는 개발자를 대체하는 거대한 자동화 프로젝트가 아니라, 특정 작업 흐름에서 사람의 반복 판단을 줄이고 결과를 측정하는 운영 시스템으로 시작할 수 있다.\n결론 및 시사점 클라우드 소프트웨어 팩토리는 코딩 에이전트를 더 많이 배포하자는 제안이 아니다. 대화형 도구를 조직의 개발 시스템 안으로 가져와, 이슈·코드·검증·배포·운영 데이터를 하나의 루프로 연결하자는 제안이다.\n핵심은 세 가지다. 첫째, 에이전트의 실행 위치를 클라우드로 옮겨 환경과 권한을 표준화해야 한다. 둘째, 오케스트레이션과 사람의 개입 경로를 함께 설계해야 한다. 셋째, 모델·하네스·스킬·메모리를 실험하고 실제 출시 결과와 비용으로 개선 효과를 측정해야 한다.\n동시에 이 접근법은 중앙화와 벤더 종속을 혼동하지 않아야 한다. 데이터는 조직이 소유하고, 여러 모델과 하네스를 교체할 수 있으며, 사람은 언제든 실행을 조정하거나 되돌릴 수 있어야 한다. 팩토리의 목표는 자율성을 최대화하는 것이 아니라, 통제 가능한 범위에서 소프트웨어 생산성을 지속적으로 높이는 것이다.\n한 줄 결론: 코딩 에이전트의 다음 단계는 개발자 옆의 대화형 도구가 아니라, 사람의 판단과 에이전트의 실행을 SDLC 전체에 연결하는 클라우드 소프트웨어 팩토리다.\n","wordCount":1519,"tags":["AI","에이전트","소프트웨어 팩토리","하네스","SDLC","클라우드","Warp"],"categories":["AI"],"frameworks":["Systems Thinking","Feedback Loop","Factory Automation"],"mental_models":["Human Variability","Control Room","Build vs. Buy"],"philosophy_type":"engineering-strategy","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["클라우드 소프트웨어 팩토리는 이슈 분류부터 명세·구현·리뷰·검증·배포·모니터링까지의 SDLC 루프를 에이전트와 사람이 함께 자동화하는 시스템이다","Zach Lloyd는 현재 약 20~30%의 이슈가 처음부터 끝까지 자동화 가능하고, 나머지도 리뷰·검증·모니터링 같은 부분 자동화가 가능하다고 설명한다","핵심 구성은 클라우드 런타임·샌드박스, 오케스트레이션·통합·휴먼 인 더 루프, 측정·평가·메모리의 세 계층이다","팩토리 효율은 shipped product / token cost로 측정하며, 모델·하네스·MCP·스킬 조합을 실험해 지속적으로 개선한다","단일 모델·하네스 종속, 데이터 소유권, 컴퓨트 선택권, 토큰 재판매 여부를 벤더 선정 전에 확인해야 한다"],"related":["posts/agent-harness-engineering","posts/anatomy-of-an-agent-harness","posts/agentic-engine-optimization"]},{"title":"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-15T23:44:55+09:00","lastmod":"2026-07-15T23:44:55+09:00","description":"AI Engineer World’s Fair 2026에서 드러난 AI 엔지니어링의 다섯 가지 변화와, 에이전트를 실제 시스템에 적용하기 위해 필요한 하네스·루프·스킬의 역할을 정리한다.","summary":"Richard MacManus의 **「5 Trends That Defined AI Engineering at World’s Fair 2026」**은 AI Engineer World’s Fair 2026에서 반복해서 등장한 주제를 다룬다. 2023년의 관심사가 LLM이 자율적으로 행동할 수 있는지 증명하는 일이었다면, 이제는 에이전트를 신뢰할 수 있는 제품과 조직 시스템으로 운영하는 일이 중심이 되었다.\n원문: 5 Trends That Defined AI Engineering at World’s Fair 2026\nTL;DR 핵심 정리 관심사의 이동: 에이전트의 능력보다 에이전트를 둘러싼 하네스, 컨텍스트, 권한, 평가, 상태 관리가 중요해졌다. 루프 설계: 에이전트가 작업을 반복하는 내부 루프와 사람이 방향을 조정하고 결과를 평가하는 외부 루프를 분리해야 한다. 기업 도입: FDE와 소프트웨어 팩토리는 조직의 데이터·업무 흐름·승인 지점까지 함께 설계하는 역할로 확장된다. 개발자 인터페이스: 코딩 에이전트는 자동완성 도구를 넘어 저장소를 탐색하고 코드를 수정·검증하는 작업 환경이 되고 있다. 스킬의 부상: 스킬은 절차와 품질 기준을 에이전트가 재사용할 수 있게 만들지만, 작고 목적이 분명해야 유지할 수 있다. 1) 에이전트보다 에이전트를 둘러싼 시스템이 중요해진다 초기의 에이전트 논의는 모델이 계획을 세우고 도구를 사용해 목표를 달성할 수 있는지에 집중했다. AutoGPT, BabyAGI 같은 프로젝트는 자율성의 가능성을 보여주는 실험이었다. 그러나 실제 운영 환경에서는 모델의 한 번의 능력보다 어떤 컨텍스트를 주고, 어떤 도구와 권한을 열어주며, 결과를 어떻게 평가하고, 상태를 어떻게 보존하는가가 더 큰 차이를 만든다.\n","content":"Richard MacManus의 **「5 Trends That Defined AI Engineering at World’s Fair 2026」**은 AI Engineer World’s Fair 2026에서 반복해서 등장한 주제를 다룬다. 2023년의 관심사가 LLM이 자율적으로 행동할 수 있는지 증명하는 일이었다면, 이제는 에이전트를 신뢰할 수 있는 제품과 조직 시스템으로 운영하는 일이 중심이 되었다.\n원문: 5 Trends That Defined AI Engineering at World’s Fair 2026\nTL;DR 핵심 정리 관심사의 이동: 에이전트의 능력보다 에이전트를 둘러싼 하네스, 컨텍스트, 권한, 평가, 상태 관리가 중요해졌다. 루프 설계: 에이전트가 작업을 반복하는 내부 루프와 사람이 방향을 조정하고 결과를 평가하는 외부 루프를 분리해야 한다. 기업 도입: FDE와 소프트웨어 팩토리는 조직의 데이터·업무 흐름·승인 지점까지 함께 설계하는 역할로 확장된다. 개발자 인터페이스: 코딩 에이전트는 자동완성 도구를 넘어 저장소를 탐색하고 코드를 수정·검증하는 작업 환경이 되고 있다. 스킬의 부상: 스킬은 절차와 품질 기준을 에이전트가 재사용할 수 있게 만들지만, 작고 목적이 분명해야 유지할 수 있다. 1) 에이전트보다 에이전트를 둘러싼 시스템이 중요해진다 초기의 에이전트 논의는 모델이 계획을 세우고 도구를 사용해 목표를 달성할 수 있는지에 집중했다. AutoGPT, BabyAGI 같은 프로젝트는 자율성의 가능성을 보여주는 실험이었다. 그러나 실제 운영 환경에서는 모델의 한 번의 능력보다 어떤 컨텍스트를 주고, 어떤 도구와 권한을 열어주며, 결과를 어떻게 평가하고, 상태를 어떻게 보존하는가가 더 큰 차이를 만든다.\n이 주변 시스템을 하네스라고 부른다. 하네스는 워크플로, 컨텍스트, 권한, 평가, 영속 상태, 개선 과정을 관리한다. 따라서 AI 엔지니어링은 좋은 프롬프트를 만드는 일을 넘어, 모델이 반복해서 일할 수 있는 실행 환경을 설계하는 일로 이동했다.\n이 변화는 하네스 엔지니어링 의 핵심과도 맞닿아 있다. 모델이 아무리 강해져도 실행 범위와 검증 루프가 없으면 운영 가능한 시스템이 되지 못한다.\n2) 루프 엔지니어링이 새로운 통제 계층이 된다 AIEWF 2026에서 자주 등장한 단어는 루프였다. 에이전트가 한 번 답하고 끝나는 것이 아니라, 계획·실행·관찰·수정을 반복하기 때문이다. 문제는 자율성이 커질수록 무엇을 자동화하고 어디에서 사람이 개입해야 하는지가 불분명해진다는 데 있다.\n가장 실용적인 구분은 내부 루프와 외부 루프다.\n내부 루프: 에이전트가 사용자를 상대하고 도구를 호출하며 실제 작업을 수행하는 과정이다. 외부 루프: 사람이 목표와 방향을 정하고, 평가 기준을 만들고, 실패 사례를 분석해 시스템을 개선하는 과정이다. 에이전트에게 내부 실행 루프를 더 많이 맡길 수는 있다. 하지만 외부 루프까지 모두 포기하면 에이전트는 잘못된 목표를 빠르게 반복할 수 있다. 결국 사람의 역할은 모든 작업을 직접 수행하는 것이 아니라, 에이전트가 달리는 선로와 멈춰야 할 지점을 설계하는 쪽으로 이동한다.\n이 관점은 루프 엔지니어링 에서 다룬 것처럼, 자율성 자체보다 피드백과 통제 구조가 중요하다는 뜻이다. 특히 자동화 수준이 높아질수록 평가 데이터, 승인 조건, 실패 시 복구 방법을 먼저 정해야 한다.\n3) AI 엔지니어링이 기업 안으로 들어간다 기업에서 에이전트를 도입하는 일은 도구 하나를 설치하는 것으로 끝나지 않는다. 기존 데이터와 업무 시스템을 연결하고, 여러 팀이 만든 기능을 조정하며, 자동화해도 되는 단계와 사람이 확인해야 하는 단계를 나눠야 한다.\n이 과정에서 주목받은 역할이 FDE(Forward Deployed Engineer)다. FDE는 고객 조직 가까이에서 에이전트와 자동화를 실제 업무에 배치하고, 떠난 뒤에도 조직이 계속 사용할 수 있는 구조를 만든다. 성과 기준도 단순한 데모 완성이 아니라 실제 ROI와 지속 가능한 운영이다.\n소프트웨어 팩토리라는 표현도 같은 흐름을 가리킨다. 여러 에이전트가 긴 시간 동안 개발 생명주기의 일부를 수행하고, 사람은 저장소·자동화 범위·코드 리뷰·고위험 변경 승인 지점을 선택한다. 조직마다 코드베이스와 위험 허용도가 다르므로 완전 자동화가 보편적인 답은 아니다.\n기업 도입의 또 다른 병목은 컨텍스트다. 조직의 데이터가 공용 지식 계층으로 들어가고, MCP·API·검색을 통해 에이전트와 애플리케이션으로 흘러나오는 경로를 설계해야 한다. 데이터가 연결되지 않은 에이전트는 똑똑해도 조직의 실제 업무를 이해하지 못한다.\n4) 코딩 에이전트가 새로운 개발자 인터페이스가 된다 2023년의 AI 코딩은 주로 다음 코드 몇 줄을 예측하는 자동완성이었다. 이제 Claude Code, Codex, Gemini CLI, Cursor, Warp 같은 코딩 에이전트는 더 넓은 목표를 받아 저장소를 탐색하고, 여러 파일을 수정하고, 테스트를 실행하고, 실패를 고친 뒤 결과를 제출한다.\n이는 IDE의 기능 하나가 추가된 정도가 아니다. 개발자가 소프트웨어와 상호작용하는 단위가 파일과 함수에서 목표와 작업 루프로 바뀌는 현상이다. 개발자는 코드를 한 줄씩 작성하는 대신, 에이전트가 탐색할 문제 공간과 검증 기준을 정의하고 결과를 평가한다.\n다만 에이전트는 일반 애플리케이션보다 출력이 예측하기 어렵다. 따라서 샌드박스, 장시간 실행 작업, 권한 분리, 테스트, 감사 로그 같은 기반 시설이 중요해진다. 사람의 통제권을 유지하면서도 여러 에이전트를 조율해야 하므로, 개발자는 점점 오케스트라의 지휘자와 비슷한 역할을 수행하게 된다.\n5) 모든 에이전트 플랫폼이 스킬을 중심으로 만들어진다 스킬은 선임 엔지니어가 사용하는 워크플로, 품질 게이트, 모범 사례를 에이전트가 재사용할 수 있는 형태로 인코딩한 것이다. 거대한 오케스트레이션 코드를 직접 작성하는 대신, 마크다운과 선언적 파일로 에이전트의 능력을 확장할 수 있다.\n스킬의 장점은 이식성이다. 특정 모델이나 플랫폼에 종속되지 않고, 필요한 순간에 업무 지식을 불러올 수 있다. 개발뿐 아니라 디자인, 영업, 고객 지원, 재무 같은 업무 절차도 스킬로 표현할 수 있다. 이때 엔지니어의 역할은 스킬이 아직 처리하지 못하는 일을 직접 맡고, 스킬 자체를 계속 개선하는 일로 확장된다.\n그러나 스킬이 많아진다고 시스템이 자동으로 좋아지는 것은 아니다. 스킬이 서로 겹치거나 지나치게 크면 에이전트가 어떤 규칙을 따라야 할지 혼란스러워진다. 새 모델이 출시될 때마다 같은 스킬이 동일한 효과를 내지도 않는다. 따라서 작은 단위로 작성하고, 목적과 입력·출력·검증 기준을 분명히 하며, 모델이 바뀔 때 다시 평가해야 한다.\n스킬은 에이전트의 능력을 키우는 교과서와 같다. 하지만 교과서가 많다고 학습이 잘되는 것은 아니다. 스킬 설계 에서 다룬 것처럼, 적은 수의 명확한 스킬과 실제 실패 사례를 반영하는 품질 관리가 더 중요하다.\n결론 및 시사점 한 줄 결론: AI 엔지니어링의 경쟁력은 더 자율적인 에이전트를 만드는 데서 끝나지 않고, 에이전트가 안전하게 반복·개선·확장되는 시스템을 설계하는 데서 결정된다.\nAIEWF 2026이 보여준 변화는 에이전트가 유행하는 도구를 넘어 소프트웨어 개발의 기본 단위가 되어가고 있다는 점이다. 이제 중요한 질문은 “어떤 모델이 가장 똑똑한가?”만이 아니다.\n에이전트가 어떤 컨텍스트와 권한을 가져야 하는가 내부 실행 루프와 외부 감독 루프를 어떻게 나눌 것인가 조직의 데이터와 업무 흐름을 어떻게 연결할 것인가 자동화와 사람의 승인 사이 경계를 어디에 둘 것인가 반복 가능한 절차를 어떤 스킬로 만들고 어떻게 평가할 것인가 이 질문에 답하지 않은 채 에이전트 수만 늘리면 자동화가 아니라 혼란이 커진다. 반대로 하네스, 루프, 컨텍스트, 스킬을 함께 설계하면 AI 엔지니어링은 개인 생산성 도구를 넘어 조직의 운영 시스템이 될 수 있다.\n관련 포스트 하네스 엔지니어링 — 좋은 모델 \u0026#43; 나쁜 하네스보다 평범한 모델 \u0026#43; 훌륭한 하네스가 이긴다 Loop Engineering — 프롬프트 엔지니어링에서 시스템 설계로의 전환 Addy Osmani의 Agent Skills — 에이전트에게 시니어 엔지니어링 프로세스를 강제하는 방법 AI 에이전트의 미래는 이미 와 있지만, 아직 균등하게 퍼지지는 않았다 ","wordCount":936,"tags":["AI","AI 엔지니어링","에이전트","하네스","스킬 엔지니어링","소프트웨어 개발"],"categories":["AI"],"frameworks":["Harness Engineering","Loop Engineering","Context Engineering","Skill Engineering"],"mental_models":["Human-in-the-loop","Control Loop","Software Factory"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["AI 엔지니어링의 관심사가 개별 에이전트의 자율성에서 컨텍스트·권한·평가·상태를 관리하는 하네스로 이동했다","에이전트가 실행하는 내부 루프와 사람이 방향·평가·개선을 담당하는 외부 루프를 분리해야 한다","기업 도입에서는 에이전트를 설치하는 것보다 조직 데이터, 통합, 자동화 범위, 사람의 승인 지점을 설계하는 일이 중요하다","코딩 에이전트는 IDE의 자동완성을 넘어 저장소 탐색·다중 파일 수정·테스트·디버깅을 수행하는 개발자 인터페이스가 되고 있다","스킬은 선임 엔지니어의 절차와 품질 기준을 재사용 가능한 지식으로 만들지만, 작고 명확하게 관리하지 않으면 새로운 복잡성을 만든다"],"related":["posts/agent-harness-engineering","posts/loop-engineering","posts/agent-skills-addy-osmani","posts/ai-agents-future-context-gap"]},{"title":"AI 에이전트 스킬 컴파일하기 — 토큰 사용량 94% 줄이는 방법","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/compiling-an-ai-agent-skill/","section":"posts","date":"2026-07-15T23:44:04+09:00","lastmod":"2026-07-15T23:44:04+09:00","description":"반복 실행되는 자연어 기반 에이전트 스킬에서 결정론적 작업을 코드로 옮기고, 의미 판단이 필요한 지점에만 LLM을 사용하는 방법을 정리한다.","summary":"Vivek Haldar는 매일 자신의 과거 글을 다시 발굴해 LinkedIn 게시물 초안을 만드는 에이전트 스킬을 운영한다. 이 워크플로우는 원래 자연어 지시만으로 작성되어 있었다. 어떤 소스를 검색할지, 최근에 다룬 글인지 어떻게 확인할지, 어떤 글을 고를지, 최종 초안을 어떤 형태로 만들지 모두 스킬 문서에 적어 둔 방식이다.\n원문: How I Cut an AI Agent\u0026rsquo;s Token Use by 94% — Vivek Haldar\n핵심 핵심 정리 출발점: 자연어 스킬은 처음부터 완벽한 프로그램을 만들지 않고, 반복 실행하며 실제 워크플로우를 발견하게 한다. 컴파일 대상: 소스 조회, 콘텐츠 인벤토리 생성, 최근 게시물 확인, 필터링, 상태 관리는 일반 코드로 옮긴다. LLM이 맡을 일: 필터링된 후보 중 좋은 글을 고르고, LinkedIn 초안을 작성하는 의미 중심 작업만 남긴다. 측정 결과: 저자의 실행에서 토큰 사용량은 94%, 지연 시간은 87% 감소했고 출력 품질은 사실상 같았다. 자연어 스킬은 탐색 단계에 적합하다 처음부터 전용 프로그램을 만드는 일은 성급할 수 있다. 어떤 규칙이 정말 필요한지, 어느 단계에서 사람의 판단이 개입하는지, 예외가 얼마나 자주 발생하는지 아직 알 수 없기 때문이다.\n","content":"Vivek Haldar는 매일 자신의 과거 글을 다시 발굴해 LinkedIn 게시물 초안을 만드는 에이전트 스킬을 운영한다. 이 워크플로우는 원래 자연어 지시만으로 작성되어 있었다. 어떤 소스를 검색할지, 최근에 다룬 글인지 어떻게 확인할지, 어떤 글을 고를지, 최종 초안을 어떤 형태로 만들지 모두 스킬 문서에 적어 둔 방식이다.\n원문: How I Cut an AI Agent\u0026rsquo;s Token Use by 94% — Vivek Haldar\n핵심 핵심 정리 출발점: 자연어 스킬은 처음부터 완벽한 프로그램을 만들지 않고, 반복 실행하며 실제 워크플로우를 발견하게 한다. 컴파일 대상: 소스 조회, 콘텐츠 인벤토리 생성, 최근 게시물 확인, 필터링, 상태 관리는 일반 코드로 옮긴다. LLM이 맡을 일: 필터링된 후보 중 좋은 글을 고르고, LinkedIn 초안을 작성하는 의미 중심 작업만 남긴다. 측정 결과: 저자의 실행에서 토큰 사용량은 94%, 지연 시간은 87% 감소했고 출력 품질은 사실상 같았다. 자연어 스킬은 탐색 단계에 적합하다 처음부터 전용 프로그램을 만드는 일은 성급할 수 있다. 어떤 규칙이 정말 필요한지, 어느 단계에서 사람의 판단이 개입하는지, 예외가 얼마나 자주 발생하는지 아직 알 수 없기 때문이다.\n자연어로 작성한 스킬은 이때 좋은 실험 도구가 된다. 에이전트는 지시를 해석하고 계획을 세우며 도구를 호출한다. 실행 과정에서 사용자는 실제로 필요한 단계와 불필요한 단계를 관찰할 수 있다. 규칙이 바뀌어도 문서를 고치면 되므로 초기 변화에도 유연하게 대응한다.\n문제는 이 방식이 반복 실행에도 그대로 남을 때 발생한다. 에이전트가 매일 같은 위치에서 같은 자료를 읽고, 같은 인벤토리를 만들고, 같은 필터를 적용한다면 모델은 이미 확정된 절차를 매번 다시 추론하게 된다.\n반복 실행하면 워크플로우가 굳어진다 몇 차례 실행한 뒤에는 스킬의 동작이 두 종류로 나뉜다.\n작업 유형 예시 적합한 실행 방식 결정론적 작업 정해진 소스 조회, 목록 생성, 날짜 비교, 최근 게시물 제외 일반 코드 의미 중심 작업 후보 글의 흥미도 판단, 독자에게 맞는 관점 선택 LLM 생성 작업 선택한 글을 바탕으로 LinkedIn 초안 작성 LLM 원문 사례에서 매번 동일하게 실행되는 부분은 소스 가져오기, 콘텐츠 인벤토리 만들기, 최근 게시물 이력 확인, 필터 적용, 중간 상태 관리다. 이 작업들은 규칙이 충분히 안정되었으므로 Python 같은 일반 코드가 더 빠르고 저렴하게 처리할 수 있다.\n반면 어떤 후보가 좋은 재게시 대상인지 판단하는 일은 글의 내용과 맥락을 읽어야 한다. 선택된 글을 짧고 자연스러운 LinkedIn 초안으로 바꾸는 일도 언어 생성이 필요하다. 이 두 지점은 LLM의 강점을 유지해야 한다.\n스킬을 컴파일한다는 의미 Haldar가 말하는 컴파일은 자연어를 기계적으로 코드로 번역한다는 뜻이 아니다. 원래 스킬, 여러 번 실행한 trace, 전문 하네스에 관한 설명을 강한 모델에 함께 제공하고, 실제로 모델이 수행했던 작업을 분석해 안정된 부분을 코드로 내리는 과정이다.\n자연어 스킬은 높은 수준의 의도를 제공한다. trace는 그 의도가 실제 실행에서 어떤 계획·도구 호출·분기·상태 변경으로 나타났는지 보여 준다. 두 자료를 결합하면 다음과 같은 판단이 가능해진다.\nsources = fetch_known_sources() inventory = build_content_inventory(sources) recent = load_recent_posts() filtered = apply_stable_filters(inventory, recent) candidate = LLM.choose_candidate(filtered) draft = LLM.write_linkedin_post(candidate) save_state(candidate, draft) 여기서 앞의 네 단계와 마지막 상태 저장은 코드가 담당한다. LLM은 후보 선택과 초안 작성에만 호출된다. 중요한 점은 모델을 억지로 규칙 엔진으로 대체하지 않는다는 것이다. 의미 이해와 문장 생성이 필요한 작업은 여전히 모델의 영역으로 남긴다.\n비용 감소는 모델 교체에서 나오지 않는다 컴파일 후 저자의 측정 결과는 토큰 사용량 94% 감소, 지연 시간 87% 감소였다. 실행 결과의 품질도 자신의 테스트에서는 사실상 유지되었다.\n이 개선은 더 작거나 저렴한 모델로 바꿔서 얻은 결과가 아니다. 후보 선택과 초안 작성에는 원래 사용하던 모델을 그대로 사용했다. 모델이 계획·도구 호출·상태 관리까지 담당하던 구조에서, 일반 코드가 처리할 수 있는 일을 제거한 결과다.\n이 차이는 에이전트 비용을 볼 때 중요한 관점을 제공한다. 모델 호출 한 번의 가격을 낮추는 일도 중요하지만, 애초에 호출할 필요가 없는 단계를 찾아 제거하는 편이 더 큰 효과를 낼 수 있다.\n실무 적용 순서 이 패턴은 반복 실행되는 모든 에이전트 워크플로우에 적용할 수 있다.\n자연어 스킬로 시작한다. 아직 요구사항과 예외를 모를 때는 유연한 방식으로 실제 흐름을 탐색한다. 실행 trace를 모은다. 계획, 도구 호출, 분기, 상태 변경, 실패 지점을 기록한다. 안정된 단계를 찾는다. 여러 실행에서 순서와 규칙이 거의 변하지 않는 작업을 표시한다. 결정론적 코드를 추출한다. 조회·변환·비교·필터·상태 관리처럼 명확한 작업을 프로그램으로 옮긴다. LLM 경계를 좁힌다. 의미 판단, 요지 파악, 생성처럼 언어 능력이 필요한 곳에만 모델을 호출한다. 컴파일 작업 자체에는 일회성 비용이 든다. trace를 읽고 설계를 판단하며 전용 하네스를 작성하려면 강한 모델과 충분한 컨텍스트가 필요하다. 하지만 이후 수백 번, 수천 번 실행할 워크플로우라면 이 비용은 반복 실행마다 절약되는 토큰과 시간으로 상쇄된다.\n에이전트의 다음 경쟁력은 전용 하네스다 범용 코딩 에이전트는 매우 뛰어난 추론·워크플로우 엔진이다. 그러나 이미 모양이 정해진 절차를 매번 계획하고 실행하는 데에는 과한 도구일 수 있다. 에이전트가 강해질수록 모든 일을 모델에게 맡기는 방식보다, 모델이 잘하는 부분과 코드가 잘하는 부분을 분리하는 설계가 중요해진다.\n이 관점은 독립 개발자와 도구 제작자에게도 기회를 만든다. 반복되는 에이전트 실행을 분석하고, 결정론적 부분을 전용 하네스나 컴파일러로 이동시키면 출력 품질을 유지하면서 비용과 지연 시간을 낮출 수 있다.\n다만 처음부터 모든 것을 코드로 고정해서는 안 된다. 아직 탐색 중인 워크플로우를 너무 일찍 컴파일하면 잘못된 규칙과 예외 처리가 프로그램에 굳어질 수 있다. 유동적인 자연어 단계로 시작하고, 실제 실행에서 충분히 반복된 부분만 코드로 내리는 순서가 안전하다.\n결론 및 시사점 한 줄 결론: 자연어 스킬로 워크플로우를 발견하고, 실행 trace에서 굳어진 부분만 코드로 컴파일하면 LLM은 판단과 생성에 집중하면서 비용과 지연 시간을 크게 줄일 수 있다.\n에이전트 최적화의 핵심은 더 작은 모델을 찾는 데만 있지 않다. 반복 실행에서 모델이 불필요하게 다시 수행하는 계획·도구 호출·상태 관리를 찾아 일반 코드로 옮기는 데 있다. 결국 좋은 에이전트 시스템은 자연어의 유연성과 코드의 결정성을 단계별로 조합한다.\n","wordCount":817,"tags":["AI","에이전트","agent-skills","하네스","토큰 효율","LLM"],"categories":["AI"],"frameworks":["Progressive Optimization","Compiler Thinking","Human-in-the-loop"],"mental_models":["Cost Amortization","Deterministic vs Semantic Work","80/20"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["자연어 스킬은 탐색과 규칙 발견에 유리하지만, 반복 실행 시 모델이 같은 절차를 계속 재해석하는 비용이 발생한다","반복 실행의 trace를 분석해 소스 조회·인벤토리 작성·필터링·상태 관리를 결정론적 코드로 옮길 수 있다","후보 선택과 LinkedIn 초안 작성처럼 의미 판단과 언어 생성이 필요한 지점에는 같은 LLM을 계속 사용한다","저자의 실행에서 모델을 교체하지 않고 토큰 사용량 94%, 지연 시간 87%를 줄였으며 출력 품질은 사실상 유지했다"],"related":["posts/agent-skills-addy-osmani","posts/agent-harness-engineering","posts/agentic-engine-optimization"]},{"title":"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-15T11:16:55+09:00","lastmod":"2026-07-15T11:16:55+09:00","description":"antirez가 주장하는 AI 시대 프로그래밍의 핵심은 코드를 줄 단위로 읽는 것이 아니라, 설계·의도·품질을 통제하는 일로 이동한다는 점이다.","summary":"antirez(Salvatore Sanfilippo)의 글 Control the ideas, not the code는 AI 시대에 프로그래머가 무엇을 통제해야 하는지를 다시 묻는다. 코드 그 자체가 아니라, 소프트웨어에 담긴 아이디어·설계·방향을 손에 쥐는 일이 중심이 된다는 주장이다.\nIdeas 핵심 정리 핵심 주장: 코드를 계속 보면 오히려 영향력이 줄어들 수 있다. 아이디어를 통제하면 줄 단위 코드 열람은 자주 비효율이 된다. LLM의 강약: 국소적으로 좋은 코드는 잘 쓰지만 큰 설계는 상대적으로 약하다. 함수·줄을 스캔하기보다 설계가 맞는지 묻는 편이 빠르다. 기회비용: 하루 8시간 중 코드 읽기에 쓰면, 방향 설정·아이디어·최적화·QA에 쓸 시간이 줄어든다. 실무 함의: 사람 손이 들어가는 제품에서는 코드 리뷰가 아직 필요할 수 있지만, 장기적으로는 설계 문서와 검증이 더 큰 자산이 된다. 왜 이 이야기를 계속하는가 antirez는 2024년 1월부터 AI 프로그래밍에 대해 글을 써 왔다. Redis에 복귀했고, 로컬 LLM 추론용 오픈소스(DwarfStar)도 만들고 있다. 그럼에도 사람들이 듣기 싫어하는 이야기를 반복하는 이유는, 변화에 덜 준비된 사람들 — 종종 자신보다 젊은 사람들 — 의 충격을 줄이려는 의도라고 밝힌다.\n","content":"antirez(Salvatore Sanfilippo)의 글 Control the ideas, not the code는 AI 시대에 프로그래머가 무엇을 통제해야 하는지를 다시 묻는다. 코드 그 자체가 아니라, 소프트웨어에 담긴 아이디어·설계·방향을 손에 쥐는 일이 중심이 된다는 주장이다.\nIdeas 핵심 정리 핵심 주장: 코드를 계속 보면 오히려 영향력이 줄어들 수 있다. 아이디어를 통제하면 줄 단위 코드 열람은 자주 비효율이 된다. LLM의 강약: 국소적으로 좋은 코드는 잘 쓰지만 큰 설계는 상대적으로 약하다. 함수·줄을 스캔하기보다 설계가 맞는지 묻는 편이 빠르다. 기회비용: 하루 8시간 중 코드 읽기에 쓰면, 방향 설정·아이디어·최적화·QA에 쓸 시간이 줄어든다. 실무 함의: 사람 손이 들어가는 제품에서는 코드 리뷰가 아직 필요할 수 있지만, 장기적으로는 설계 문서와 검증이 더 큰 자산이 된다. 왜 이 이야기를 계속하는가 antirez는 2024년 1월부터 AI 프로그래밍에 대해 글을 써 왔다. Redis에 복귀했고, 로컬 LLM 추론용 오픈소스(DwarfStar)도 만들고 있다. 그럼에도 사람들이 듣기 싫어하는 이야기를 반복하는 이유는, 변화에 덜 준비된 사람들 — 종종 자신보다 젊은 사람들 — 의 충격을 줄이려는 의도라고 밝힌다.\n그의 전략은 일종의 트릭이다. 프로그래머들이 AI 때문에 분야가 바뀌고 있다는 불안을 느끼고, 코드를 주요 산출물로 보지 않는 방식이 배신처럼 느껴질 때, \u0026ldquo;나처럼 코드를 쓸 줄 아는 사람도 인정한다. 이것은 네 약점이 아니라 분야의 진화\u0026quot;라고 말해 주려는 것이다. 변화는 고통스럽지만 동시에 기쁨이 섞인 방향으로 가고 있다고 본다.\n코드를 보면 영향력이 줄어든다 어제 X에서 그는 이렇게 말했다. 많은 프로그래머가 코드를 보기 때문에, 가질 수 있는 영향력보다 덜 영향을 미치고 있다. 이것은 \u0026ldquo;최종 제품만 요청하는 바이브 코딩\u0026quot;을 옹호하는 말이 아니다. 핵심은 다음이다.\n소프트웨어의 아이디어를 통제하고 있다면, 코드 자체를 들여다보는 일은 차선이고 종종 무의미하다.\n이유는 세 가지다.\n1) 생성량이 리뷰 가능 범위를 넘는다 이제 하루에도 많은 코드를 만들 수 있다. LLM의 장황함까지 감안하지 않더라도 마찬가지다. 매일 5,000줄을 사람이 리뷰한다는 가정 자체가 현실적이지 않다.\n2) LLM은 국소 최적에 강하고 큰 아이디어에 약하다 LLM은 국소적으로 괜찮은 코드를 잘 쓴다. 큰 설계 아이디어에는 아직 약하지만 개선 중이다. 그렇다면 함수 단위·줄 단위 스캔의 이득은 작다. 대신 머릿속의 설계를 프롬프트로 밀어 넣고, \u0026ldquo;그 부분의 설계가 정확히 무엇인가? 어떻게 동작하는가?\u0026ldquo;를 물은 뒤, 그 모델이 맞는지 평가하는 편이 훨씬 빠르다.\n3) 하루 8시간은 트레이드오프다 코드 읽기는 공짜가 아니다. 읽기에 쓰는 시간은 오늘 가장 중요한 일에서 빠진다. antirez가 꼽는 중요 일은 다음과 같다.\n이 소프트웨어로 무엇을 하고 있는가 어떤 새 방향으로 갈 것인가 새 아이디어, 기능, 최적화 트릭 많은 QA 즉 코드 리딩 습관은 \u0026ldquo;성실함\u0026quot;이 아니라 기회비용 문제다.\nMythical Man-Month가 다시 맞다 \u0026ldquo;아이디어를 통제한다\u0026quot;는 표현은 The Mythical Man-Month에서도 나온다. 1970년대 책이 2000~2020년의 많은 이야기보다 현재 소프트웨어 시대를 더 잘 설명한다는 것이다.\n그는 반문한다. 지금 AI에 저항하는 사람들은 지난 10년의 소프트웨어 상태에는 왜 그토록 공포를 느끼지 않았는가. AI 이전에도 슬롭의 수준은 이미 믿기 어려울 정도였다. 그렇다면 지금의 저항 중 상당 부분은 이데올로기적이지 않은가.\nDwarfStar 사례: \u0026ldquo;구현해 줘\u0026quot;로는 안 된다 DwarfStar에서 DeepSeek v4와 GLM 5.2 추론을 상당 부분 자동으로 구현했다고 한다. 그러나 \u0026ldquo;XYZ를 구현해\u0026quot;라고만 하면 동작하는 결과가 나오지 않는다. 다음이 필요하다.\n동작 원리 이해 더 나은 설계 선택 목표 성능에 도달하는 경로 그는 구현을 다른 시스템과 정합성 비교했고, 다른 구현에 더 많은 오류가 있는 경우도 발견했다. 로컬 추론 세계에는 미묘한 오류가 쌓여 모델 출력을 망가뜨리는 문제가 있다. 예로, 컨텍스트가 일정 한계를 넘으면 성능이 기울어지는 어텐션 구현 버그(인덱싱된 어텐션이 필요 이상으로 일을 하는 식) 등이 있다.\n도메인은 복잡하고 빠르게 바뀌며, 추론 그래프가 모델마다 조금씩 다른 새 모델이 매일 나온다. 개발자에게 불리한 게임이다. 여기서 AI는 큰 도움이 된다. 많은 영역에서 설계 쪽의 엄밀한 엔지니어링과 테스트 가 GPU 커널을 손으로 쓰거나 읽는 일보다 훨씬 낫다.\nRedis 코드 리뷰는 왜 아직 하는가 Matteo Collina가 물었다. \u0026ldquo;Redis용 AI 생성 코드는 전부 검사한다고 하지 않았나?\u0026rdquo;\nantirez의 답은 솔직하다. 그렇다, 검사한다. 그러나 이제는 해야 하는 일 이지 유용한 일 은 아니라고 본다. GPT-5.5 이후, 그리고 Fable과 GPT-5.6 Sol 이후 그 경향이 더 강해졌다.\n코드를 열어 보면 마음에 안 드는 구현을 찾는다. 하지만 다른 Redis 기여자가 쓴 파일을 열면 그보다 훨씬 나쁜 코드도 있다. 실력이 없어서가 아니라 취향 의 문제다. 그는 가독성을 중시해 Redis Arrays 구현에서 코드를 손봤고, 정렬 집합(sorted sets) 50% 메모리 절감 최적화 PR에서도 같은 일을 한다. 그러나 더 이상 유용하다고 느끼지 않는다.\n아무도 그 코드를 보지 말고, 코드가 담은 아이디어만 보면 된다고 본다. 그럼에도 리뷰를 계속하는 이유는 사용자에 대한 존중 때문이다. Redis는 흔히 쓰이는 소프트웨어라, 많은 프로그래머가 파일을 열고 손으로 고친다.\n손이 자유롭다면 그는 리뷰 시간을 다른 곳에 쓰겠다고 한다.\n더 많은 QA 다음 최적화 아이디어를 생각하고 적용 LLM으로 DESIGN.md를 작성: 각 자료구조를 인간 언어로 기술하고, 담긴 아이디어·구현 트릭·설계를 남김 미래에 더 유용한 것은 이쪽이다. sorted sets를 수정하려면 설계 문서를 읽고 아이디어를 소유한 뒤, 올바른 정신 모델로 에이전트에게 무엇을 할지 묻는 방식이 코드 리뷰보다 낫다.\nFable과 GPT-5.6이 sorted sets 메모리 절감 변경에서 찾아낼 오류·미묘한 레이스 조건은 그의 리뷰보다 많을 가능성이 크다. 그래도 그는 리뷰를 한다. 하지만 대부분의 소프트웨어 프로젝트에서는 더 이상 말이 되지 않는다.\n초보 프로그래머에 대한 유일한 유보 경험 부족으로 정신 모델을 아직 못 만든 젊은 프로그래머에 대해서만 그는 유보를 둔다. 특정 코드 조각을 아주 깊이 이해해야 하는지는 아직 모른다. 다만 프로그램을 쓰는 법을 배워야 한다 고 본다.\n그런데 LLM 출력을 검수하는 일이 그 학습의 정답인지는 회의적이다. 다음이 더 유익할 수 있다.\n프로그래밍 언어를 익힌다 작은 인터프리터를 만든다 작은 데이터베이스를 만든다 해시 테이블을 구현한다 고객 웹사이트의 JavaScript를 리뷰하며 시간을 쓰는 일은, 그가 보기에 시간을 낭비하는 일이다.\n결론 및 시사점 한 줄 결론: AI 시대 프로그래머의 핵심 역할은 코드를 줄 단위로 소유하는 것이 아니라, 소프트웨어의 아이디어·설계·품질 기준을 소유하는 일이다.\nantirez의 주장은 \u0026ldquo;코드를 전혀 보지 말라\u0026quot;는 방임이 아니다. 코드를 보는 행위의 한계효용 이 급격히 떨어졌다는 진단에 가깝다. 생성량은 폭증했고, LLM은 국소 구현에서 사람을 압도하기 시작했으며, 사람의 시간은 방향·설계·검증으로 써야 이득이 크다.\n실무적으로 옮기면 세 가지가 선명해진다.\n설계를 프롬프트와 문서로 먼저 고정한다. 구현 전에 \u0026ldquo;무엇이 옳은 모델인가\u0026quot;를 합의한다. 검증과 QA에 사람 시간을 재배치한다. 줄 리뷰 대신 동작·경계·성능·정합성을 본다. 학습 경로를 분리한다. 숙련자는 아이디어 통제와 검증에, 초보자는 작은 시스템 구현으로 정신 모델을 쌓는 쪽에 힘을 준다. 세계는 바뀌었고 고통스럽지만, 이미 썩어 있던 소프트웨어 세계를 개선할 기회도 가득하다. 그 기회는 더 많은 코드를 읽는 데서 오지 않는다. 더 나은 아이디어를 통제하는 데서 온다.\n관련 포스트 Understanding Is the New Bottleneck - AI 시대의 병목은 이해다 AI 프로토타입 시대에도 여전히 엔지니어가 필요한 이유 Backpressure is all you need — 코딩 에이전트 위임의 병목을 사람에서 시스템으로 옮기기 ","wordCount":967,"tags":["AI","LLM","antirez","Redis","소프트웨어엔지니어링","에이전트","디자인"],"categories":["AI"],"frameworks":["Idea Control","Design over Implementation","Human-AI Division of Labor"],"mental_models":["Mythical Man-Month","Trade-off","Local vs Global Optimality"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["코드를 계속 들여다보는 습관이, 아이디어·방향·QA에 쓸 시간을 잠식해 프로그래머의 실질 영향력을 줄일 수 있다.","LLM은 국소적으로 괜찮은 코드를 잘 쓰지만 큰 설계에는 약하므로, 줄 단위 리뷰보다 설계 모델의 옳음을 검증하는 편이 효율적이다.","하루 8시간 제약 아래 코드 읽기는 기회비용이 크며, 무엇을 만들지·다음 방향·최적화·QA가 더 중요한 일이 된다.","Redis처럼 사람이 직접 파일을 열어 수정하는 소프트웨어에서는 코드 리뷰를 유지할 수 있지만, 이상적으로는 DESIGN.md로 아이디어를 소유하게 만드는 쪽이 낫다.","초보 프로그래머는 LLM 출력 검수보다, 인터프리터·DB·해시테이블 같은 작은 시스템을 직접 만들어 정신 모델을 쌓는 편이 유익할 수 있다."],"related":["posts/understanding-is-the-new-bottleneck-geoffrey-litt","posts/yes-we-still-need-engineers","posts/backpressure-is-all-you-need-summary"]},{"title":"우리에게 남은 일은 무엇인가 — 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-15T11:14:28+09:00","lastmod":"2026-07-15T11:14:28+09:00","description":"Arvind Narayanan의 ICML 2026 키노트를 바탕으로, AI as Normal Technology 프레임워크, 능력-신뢰성 격차, Decide-Execute-Deliver 구조, 그리고 평가로 이동하는 인간 역할 변화를 정리한다.","summary":"프린스턴 대학의 Arvind Narayanan이 ICML 2026 키노트에서 던진 질문은 단순하다. AI 능력이 계속 올라갈 때, 우리에게 남은 일은 무엇인가? 그는 이 불안을 정면으로 다루며 AI as Normal Technology 프레임워크를 중심으로 세 가지 주장을 펼친다. 첫째, 재귀적 자기개선 같은 불연속성이 오기 전까지 이 프레임은 유효하다. 둘째, 랩에서 어떤 마일스톤을 달성해도 그것이 곧바로 전면 실업을 만들지 않는다. 셋째, 미래 직업은 지금과 근본적으로 달라지므로 대규모 적응이 필요하다.\nTL;DR 핵심 정리 AI as Normal Technology: AI는 산업혁명급 변환 기술이지만, 경제적 영향은 능력 → 제품 → 초기 채택 → 조직 적응의 네 단계를 거치며 적응은 수십 년이 걸린다. 능력-신뢰성 격차: 최근 24개월 프론티어 모델에서 accuracy는 크게 올랐으나 reliability는 5~10%p 수준만 개선되어, 완전 자동화보다 협업 에이전트가 당분간 더 성공적이다. Decide-Execute-Deliver: AI는 중간 Execute(코딩 등)만 압축하고, 양 끝의 결정·기획과 검증·책임은 오히려 확장될 수 있다. 역할 이동: 검증 가능한 구축 작업은 AI로 넘어가고, 인간의 핵심 역할은 평가·조향·판단·취향으로 이동한다. 목표: 랩의 마일스톤에 굴복하는 것이 아니라, AI를 정신의 크레인으로 쓰는 공초지능(co-superintelligence)을 향해 통제권을 유지하는 것이다. 원문: What will be left for us to work on?\n주석 슬라이드: ICML 2026 annotated slides\n","content":"프린스턴 대학의 Arvind Narayanan이 ICML 2026 키노트에서 던진 질문은 단순하다. AI 능력이 계속 올라갈 때, 우리에게 남은 일은 무엇인가? 그는 이 불안을 정면으로 다루며 AI as Normal Technology 프레임워크를 중심으로 세 가지 주장을 펼친다. 첫째, 재귀적 자기개선 같은 불연속성이 오기 전까지 이 프레임은 유효하다. 둘째, 랩에서 어떤 마일스톤을 달성해도 그것이 곧바로 전면 실업을 만들지 않는다. 셋째, 미래 직업은 지금과 근본적으로 달라지므로 대규모 적응이 필요하다.\nTL;DR 핵심 정리 AI as Normal Technology: AI는 산업혁명급 변환 기술이지만, 경제적 영향은 능력 → 제품 → 초기 채택 → 조직 적응의 네 단계를 거치며 적응은 수십 년이 걸린다. 능력-신뢰성 격차: 최근 24개월 프론티어 모델에서 accuracy는 크게 올랐으나 reliability는 5~10%p 수준만 개선되어, 완전 자동화보다 협업 에이전트가 당분간 더 성공적이다. Decide-Execute-Deliver: AI는 중간 Execute(코딩 등)만 압축하고, 양 끝의 결정·기획과 검증·책임은 오히려 확장될 수 있다. 역할 이동: 검증 가능한 구축 작업은 AI로 넘어가고, 인간의 핵심 역할은 평가·조향·판단·취향으로 이동한다. 목표: 랩의 마일스톤에 굴복하는 것이 아니라, AI를 정신의 크레인으로 쓰는 공초지능(co-superintelligence)을 향해 통제권을 유지하는 것이다. 원문: What will be left for us to work on?\n주석 슬라이드: ICML 2026 annotated slides\n두 가지 내러티브 사이에서 AI 담론은 오래전부터 두 진영으로 갈라져 왔다. 이제는 철학 논쟁이 아니라 개인의 실무 선택 이 된다.\n관점 함의 대응 대체 기술 수년 안에 인간 업무를 대부분 대체한다 스킬이 무용지물이 되기 전에 자산을 최대한 축적한다 증폭 기술 인간 잠재력을 크게 키운다 AI에 상보적인 스킬, 주체성, 취향, 판단력을 지금 쌓는다 Narayanan은 후자를 택한다. 만약 실제로는 증폭 기술인데 대체 기술로 가정하고 스킬 투자를 포기하면, 역사상 가장 강력한 보완 역량을 기를 시기를 놓치게 된다.\nAI as Normal Technology란 무엇인가 \u0026ldquo;Normal\u0026quot;은 망치나 칫솔처럼 사소하다는 뜻이 아니다. 저자들은 AI를 산업혁명 수준의 변환 기술로 인정한다. 다만 슬로건이 아니라, 능력이 경제·사회에 영향을 미치는 인과 모델 로 제시한다.\n확산 이론을 AI에 적용한 네 단계 전기의 역사를 참고하면 발명 → 혁신 → 확산의 흐름이 보인다. 이를 AI에 적용하면 대략 다음과 같다.\nMethods / Capabilities — 모델 능력이 빠르게 오른다. Products / Applications — 사람들은 LLM 자체를 쓰지 않는다. 코딩 에이전트처럼 잠재 능력을 쓸모 있는 제품으로 바꾸는 단계가 필요하다. Early adoption — 바이브 코딩에서 에이전틱 엔지니어링으로, 사용 방식이 정교해진다. Adaptation / structural transformation — 조직·산업·역할의 구조적 재편. 가장 느리고, 수십 년이 걸리며, 소프트웨어 엔지니어링조차 아직 본격 시작되지 않았다 고 본다. 코딩 에이전트가 수백만 줄 규모의 견고한 시스템을 만들 수 있게 되면, 수십억 명이 쓰는 단일 소프트웨어보다 팀·개인 맞춤 소프트웨어가 합리적이 될 수 있다. 이는 기술 변화가 아니라 산업 구조 변화 다. 소프트웨어 회사가 여전히 필요한지, 개발이 사용 조직 내부로 대거 이동할지 같은 질문이 열린다. 과거 기술을 보면 이런 조직적 변화는 매우 느리다.\n전기 공장 비유: 드롭인 교체는 실패한다 전기 도입 초기, 공장 소유주들은 증기 보일러를 발전기로 단순 교체하려 했다. 이른바 drop-in replacement 다. 오늘날 AI 에이전트를 인간 노동의 즉시 대체재로 보는 시각과 닮았다. 실제로 먹힌 것은 전력이 이동 가능하다는 특성을 살려 조립 라인 논리로 공장 전체를 재설계한 쪽이었다. 그 과정에는 작업자 교육, 고용·해고 방식, 노동법 변화까지 포함됐고 약 40년 이 걸렸다.\nAI도 같은 종류의 조직 적응을 거칠 것이라고 저자는 주장한다. 그리고 그 적응을 완성하는 주체는 AI 회사가 아니다. 전기 유틸리티가 공장 배치를 대신 설계하지 않았던 것과 같다.\n능력과 신뢰성의 격차 Anthropic 데이터 등을 보면, 직군별로 AI를 쓸 수 있는 범위와 실제로 쓰는 범위 사이에 큰 갭이 있다. 채택 지연만이 원인은 아니다. 현장 사용자는 산업계가 과소평가하는 실무적 한계 를 이미 알고 있을 수 있다.\n사람들이 AI에 대해 가장 자주 드는 우려는 신뢰성(reliability) 이다. 저자 팀은 accuracy와 구분되는 reliability를 다음 네 축으로 묶는다.\nConsistency — 70% 정확도가 \u0026ldquo;특정 70% 작업에서는 항상 성공\u0026quot;인지, \u0026ldquo;매 작업마다 30% 확률로 예측 불가능하게 실패\u0026quot;인지. 배포 관점에서는 전혀 다른 의미인데, 기존 벤치마크는 둘을 구분하지 않는다. Robustness — 환경이 조금만 바뀌어도 버티는가. Calibration — 자기 결과가 맞았는지 스스로 판단할 수 있는가. Operational safety — 실패 시 복구 가능한가, 아니면 프로덕션 DB 삭제 같은 비가역 사고인가. 지난 약 24개월, 프론티어 3사 모델에서 능력(accuracy)은 급등 했지만 신뢰성은 5~10%p 수준 만 올랐다. 이 격차의 실무 함의는 분명하다.\n협업 에이전트 vs 자동화 에이전트 산업계는 둘을 아직 충분히 구분하지 않는다. 헤드리스 모드로 돌리면 자동화 에이전트라는 식의 구분은 조잡하다. 자동화에는 높은 신뢰성이 필수지만, 창작 협업 에이전트에는 오히려 일정한 예측 불가능성·탐색성이 바람직하다. 스캐폴딩과 사후학습도 목적에 따라 달라져야 한다.\n당분간 에이전트는 다음 세 속성 중 둘만 동시에 가질 수 있다.\nGeneral-purpose (언어모델 기반의 범용 지시 가능) High-stakes (고위험 현장 배포) Automated (사람 없이 완주) 이 때문에 AI는 당분간 노동을 통째로 대체하는 기술보다 협업 기술 에 가깝다.\n소프트웨어 엔지니어링은 선행 지표다 코딩 에이전트는 가장 빠르게 채택된 영역이므로 노동 영향의 선행 지표가 된다. \u0026ldquo;엔지니어를 10배 생산적으로 만들면 엔지니어가 10분의 1만 필요하다\u0026quot;는 직관은 데이터와 모순 된다. 저자들이 후속 글에서 살펴본 해고 사례 대부분은 재정 압박 속에서 AI를 편리한 명분으로 쓴 경우였다. 관련 분석은 AI가 소프트웨어 엔지니어를 대체하지 못한 이유 에서도 다룬다.\nDecide-Execute-Deliver 샌드위치 레이어 내용 AI 압축 여부 Decide 요구사항 이해, 스펙, 기획 거의 압축되지 않음 Execute 코딩·디버깅 압축됨 (원래도 전체의 일부) Deliver 출시 책임, 통합, 유지보수, 테스트 거의 압축되지 않음 중간이 압축되면 양 끝은 오히려 팽창할 수 있다. 지식 노동자는 점점 크레인 조작수 에 가까워진다. 기계가 무거운 인지 노동을 하지만, 조작·이해·통제는 인간이 맡는다. 직업 전체가 \u0026ldquo;인지 작업을 직접 수행\u0026quot;에서 \u0026ldquo;기계를 운용·감독\u0026quot;으로 재정의된다.\n머신코드에서 고수준 추상화로 올라오며 소프트웨어 생산성은 반복적으로 한 자릿수 배 올랐다. 그 기간 동안 엔지니어 고용은 줄어들지 않았고, 대략 1만 배 규모 로 늘었다. 쓸 코드의 양이 더 빠르게 늘어났기 때문이다.\n노동 총량 오류 경제학에서 반복 확인되는 lump-of-labor fallacy 다. ATM은 은행 지점을 늘렸고, 지점에는 여전히 창구 직원이 필요했다. Hinton의 방사선의 소멸 예측과 달리 방사선의 고용은 늘었고, 번역은 인간 패리티에 가깝게 된 지 약 10년이 지났는데도 통번역 고용은 비교적 안정적이다. 작업이 싸지고 빨라지면 수요 자체가 확장 되는 경우가 많다.\n재귀적 자기개선이 와도 즉시 실업은 아니다 많은 기업이 RSI(Recursive Self-Improvement)를 향해 경쟁한다고 말한다. 흔한 서사는 RSI → AGI → ASI → 인간 일자리 소멸을 거의 자동 연쇄로 그린다. Narayanan은 이를 네 개의 서로 다른 진전 축 으로 분해한다. 어느 하나도 다른 셋을 함의하지 않는다.\n1) Recursive Self-Improvement \u0026ldquo;AI가 후속 시스템을 만들었다\u0026quot;는 말도 스펙트럼이 넓다. 한쪽 끝은 아키텍처·데이터 파이프라인 트윅을 자동 탐색해 개선을 유지하는 화려한 하이퍼파라미터 서치 에 가깝다. AutoML은 오래전부터 있었다. 다른 쪽 끝은 전 세계 수십만 AI 연구자의 창의성·판단까지 대체하는 수준이다. 사람들이 RSI를 말할 때 어느 쪽을 가리키는지 불명확하다.\nAI는 여전히 검증 가능한 과제 에 강하고, 속도·효율 같은 축은 단기 RSI로 크게 개선될 수 있다. 반면 창의성은 비검증적 과제의 전형이다. 인간 창의성조차 인지과학적으로 충분히 정의되지 않아 테스트가 어렵다.\n2) 인간형 AI / 창의성 Dwarkesh Patel의 지적처럼, 서로 무관해 보이는 영역을 잇는 유레카형 연결에서 LLM은 아직 멀다. 가설적으로는 다음과 같다.\n지각 표상 품질은 딥러닝으로 크게 따라잡혔지만, 창의·추론용 표상 은 아직이다. 인간 표상은 Chollet이 말한 극단적 조합성(atoms of meaning)에 가깝고, 작업기억 한계가 오히려 효율적 표상을 강제한다. 인간은 추론 시점에 문제 관련 표상을 개선한다(잠자고 다시 보면 더 잘 풀리는 경험). 현재 연속 학습 연구는 재앙적 망각 방지와 사실·스킬 축적에 치우쳐, 표상 품질 개선과는 결이 다르다. 연구팀은 아직 arXiv에 올라오지 않은 ML 문제를 AI 에이전트에 주고, 해당 문제를 깊이 고민한 인간 연구자가 채점하는 open-world evaluation 도 진행 중이다. App Store 앱 제출 같은 평가도 같은 계열이다.\n3) 경제적 변환 AI 어떤 의미에서 \u0026ldquo;AGI는 이미 있다\u0026quot;는 말에 저자는 동의한다. 모순처럼 들리지만 Part 1과 같은 주장의 다른 표현이다. 병목은 모델이 아니라 다운스트림 에 있다. 신뢰성, 기존 시스템 통합, 의학·법률 등 암묵지, 규제 등이 그 예다. 이것들은 다음 화요일 모델 릴리즈로 풀리지 않고, 수십 년에 걸친 점진적 채택 으로 풀린다.\n따라서 AGI 능력 마일스톤을 맨해튼 프로젝트처럼 먼저 차지하면 경제 과실을 독식한다는 지정학 서사는 설득력이 약하다. 경제적 잠재력은 이미 열려 있고, 누가 다운스트림 행동을 하느냐에 달렸다.\n4) 초지능 암 치료의 병목은 종종 수천 명·10~15년이 걸리는 임상시험이다. 1년 후 날씨를 정확히 맞히는 초지능도 혼돈 이론상 사실상 불가능에 가깝다. 상당수 과제는 이미 외부 한계에 가깝다.\n더 중요한 점은, 대부분 과제에서 인간 성능의 한계는 생물학이 아니라 학습과 도구 에 있다. 고대인이 현대인을 초지능으로 느끼는 이유도 생물학적 업그레이드가 아니라 축적된 학습·디지털 도구 때문이다. AI는 그 도구 중 하나이므로, AI 개선은 AI 지능만이 아니라 AI 증강 인간 의 지능도 끌어올린다.\n\u0026ldquo;미래에 AI가 회사를 소유·운영하고 사람을 고용·해고한다\u0026quot;는 시나리오 자체가 이미 디스토피아다. 정렬 여부와 무관하게 인간 존엄과 민주적 거버넌스 측면에서 재앙이다. 정렬에 기대어 그 미래를 불가피한 것으로 받아들이는 태도는, 저자에게 안전이 아니라 안전 포기에 가깝다. 필요한 것은 정책과 정치, 그리고 무책임한 배포를 막는 사회적 통제다.\n정리하면, 랩에서 달성한 어떤 것도 자동으로 전 인류 실업을 만들지 않는다. 위험은 실재하고 변화는 크지만, 배포 방식에 대한 인간의 행위자성은 수십 년에 걸쳐 작동한다.\n남는 일: 구축에서 평가로 미래 직업이 현재와 같다는 뜻은 아니다. 순수 기술 스킬은 검증 가능하므로 상대적으로 평가 절하된다. 20여 년 전에도 \u0026ldquo;프로그래밍\u0026quot;과 \u0026ldquo;소프트웨어 엔지니어링\u0026rdquo; 수요는 갈라지기 시작했다. 전자는 코딩·디버깅 중심이고, 후자는 Decide-Execute-Deliver 전 계층과 도메인 지식·판단을 포함한다. 이런 분화가 더 많은 분야로 퍼질 것이라고 예측한다.\n노 젓기에서 조향으로 과거 대부분 배가 노를 젓는 배였을 때는 이동과 방향 결정이 한 몸에 있었다. 엔진이 물리 노동을 맡자 인간 역할은 사라지지 않았고, 오히려 어디로 갈지·어떻게 갈지에 특화된 수십 개의 전문 역할로 쪼개졌다.\nAI/ML도 비슷하다. 구축의 상당 부분은 검증 가능 과제로 AI에 넘어가고, 평가 — 커뮤니티가 어디로 가야 하는지, 어떤 속성이 바람직한지 — 는 자동화에 매우 강하다. 에이전트 평가는 이미 구축 커뮤니티와 분리되는 독자 분과가 되고 있다. 기업 쪽에서는 \u0026ldquo;evals are the new IP\u0026quot;라는 말까지 나온다.\n저자는 ICML 같은 학회에서 평가 논문 비중이 지금보다 훨씬 커져야 한다고 본다. 생각 있는 평가는 모델 정렬만이 아니라 커뮤니티 정렬 — 현재 궤적과 원하는 방향의 맞춤 — 이기도 하다. 평가가 없으면 강한 엔진만 달린 방향타 없는 배가 된다.\n연구·과학에서의 함의 벤치마크 SOTA만이 가치 기준이 되면 가로등 아래만 찾는 검색이 된다. 논문 가치 평가는 더 비싸지고 어려워져야 하며, 동료심사 자동화는 진보 방향의 통제권을 AI에 넘기는 함정 에 가깝다. 과학에서도 \u0026ldquo;문제 → 해답\u0026rdquo; 경로를 자동화하면 과학이 가속된다는 가정은 오해다. 인간 이해는 제거해야 할 마찰이 아니라 과학의 목적 자체 에 가깝다. AI 솔루션에서 인간 이해를 다시 끌어내는 도구와 역할이 새로 필요할 것이다.\n개인 차원의 적응 휴리스틱 Narayanan은 자신의 연구 워크플로 기준으로 주당 약 10시간 을 새 워크플로 실험과 학습에 쓴다. AI로 아낀 시간을 단기 생산성에 쓰지 않고, 상보 스킬과 장기 성장에 재투자 한다.\nFloor — AI가 단독으로 할 수 있는 것 Ceiling — AI가 인간을 증강해 가능하게 만드는 야심 찬 일. 천장은 자동으로 오르지 않으며, 밀어 올려야 한다. 하루 끝에 지치지 않았다면 잘못한 것일 수 있다. AI에 너무 많이 떠넘겨 장기 성장을 희생한 신호다. 성장·생산성·통제 는 세 다리 의자와 같다.\n두 가지 휴리스틱을 강조한다.\n블랙박스 유혹 거부 — 프롬프트만 주고 에이전트가 알아서 하게 두면 통제권을 점진적으로 잃는다. 의존 나선(dependence spiral) 회피 — 아직 전문가가 아닌 일에 AI를 먼저 쓰면 미숙한 스킬마저 약해진다. 먼저 직접 숙달한 뒤 생산성 증강에 쓰는 편이 장기적으로 낫다. 비전은 co-superintelligence 다. 컴퓨터가 정신의 자전거였다면, AI는 정신의 크레인 이 될 수 있다. 학습 곡선은 가파르고 러닝머신 위에 선 느낌이지만, 5년 전보다 더 야심 찬 일을 할 수 있게 된 것 자체가 이미 일종의 초능력에 가깝다. 먼 미래에 불가능해질 수도 있으나, 지금 싸움을 포기하기에는 너무 이르다.\n결론 및 시사점 한 줄 결론: AI 시대에 남는 핵심 일은 더 빨리 노를 젓는 것이 아니라, 검증 가능한 구축을 AI에 넘긴 뒤에도 평가·조향·판단을 통해 배를 어디로 보낼지 인간이 계속 쥐는 일이다.\n이 키노트의 핵심은 낙관론이나 회의론의 구호가 아니라, AI 영향의 시간 구조와 역할 재배치 를 정확히 보자는 요청이다. 능력 향상은 빠르지만 신뢰성·조직 적응·규제·암묵지 같은 다운스트림 장벽은 느리다. 그 사이에서 검증 가능한 실행 노동은 AI로 이동하고, 인간에게 남는 중심 업무는 무엇을 만들지 정하고, 결과를 평가하며, 배를 어디로 몰지를 결정하는 일이다. 랩의 이정표에 운명을 맡기기보다, 배포·정책·개인 학습 습관에서 통제권을 지키는 쪽이 현실적인 대응이다.\n관련 포스트 Understanding Is the New Bottleneck - AI 시대의 병목은 이해다 AI가 소프트웨어 엔지니어를 대체하지 못한 이유, 그리고 앞으로도 대체하지 못할 이유 AI 프로토타입 시대에도 여전히 엔지니어가 필요한 이유 ","wordCount":1830,"tags":["AI","노동시장","에이전트","평가","Normal Technology","ICML","일자리"],"categories":["AI"],"frameworks":["Diffusion of Innovations","Second-order thinking","Systems Thinking"],"mental_models":["Lump of Labor Fallacy","Jevons Paradox","Decide-Execute-Deliver Sandwich"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI as Normal Technology는 능력 향상이 곧바로 경제·일자리 충격을 만들지 않으며, 조직적 적응(adaptation)에 수십 년이 걸린다는 프레임이다","최근 24개월간 에이전트 능력(accuracy)은 급등했지만 신뢰성(reliability)은 5~10%p 수준만 올랐다","검증 가능한 작업은 AI로 넘어가고, 인간 역할은 구축(building)에서 평가·조향(evaluation/steering)으로 이동한다","RSI·AGI·경제적 변환·초지능은 서로 함의하지 않는 네 축이며, 랩의 마일스톤이 일자리 소멸을 즉시 만들지 않는다","목표가 되는 비전은 AI 단독 초지능이 아니라 인간-AI 공초지능(co-superintelligence)이다"],"related":["posts/understanding-is-the-new-bottleneck-geoffrey-litt","posts/why-ai-hasnt-replaced-software-engineers","posts/yes-we-still-need-engineers"]},{"title":"AI는 가장 인간적인 기술이 될 수 있다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/the-most-human-technology-ever-made/","section":"posts","date":"2026-07-14T10:47:20+09:00","lastmod":"2026-07-14T10:47:20+09:00","description":"Anish A가 AI를 시간 절약 도구가 아니라 만들기와 자기표현을 확장하는 기술로 해석한 논지를 정리한다.","summary":"Anish A는 AI를 단순한 생산성 도구로 보지 않는다. 글에서 제시된 핵심은 분명하다. 대부분의 기술은 시간을 아끼도록 설계되었지만 AI는 사람들에게 **“하고 싶은 일을 더 오래, 더 많이, 더 멋지게 하기 위한 시간”**을 준다는 주장이다.\n원문: The Most Human Technology Ever Made\n핵심 포인트 핵심 정리 시간 논리의 전환: AI의 핵심 질문은 일량 축소가 아니라, 사람이 자기 주도적으로 무엇을 만들고 탐구할 수 있게 되는 시간의 증가다. 새로운 기술 분류: 언어, 인쇄술, 증기기관처럼 AI는 노동을 줄이면서도 인간표현의 폭을 넓힌 몇 안 되는 기술군에 넣을 수 있는 흐름으로 해석한다. 만드는 쪽으로 회귀: 소셜미디어가 소비 경쟁으로 몰리면 결과는 품질이 아닌 노이즈가 커지며, AI는 사용자가 직접 결과물을 만들어내는 쪽으로 기울게 만든다. 문턱 붕괴의 실증: 비개발자인 전기기사와 배관공의 사례는, AI가 전문성 문턱을 낮추고 적은 비용으로 실험·판매·반복 개선을 가능하게 한다는 점을 보여 준다. 두려움보다 확장성 강조: AI가 소수 회사의 영구적 초우위로 귀결될 것이라는 공포보다, 개성(Individuality)을 대규모로 발현시키는 사회적 변화가 더 설득력 있다는 논지를 제시한다. 1) AI가 던지는 질문은 ‘효율’이 아니라 ‘삶의 방향’이다 칼이든 자동차든 이전 기술들은 대체로 ‘덜 고생하고 더 많이 얻는 것’에 맞춰져 왔다. 그런데 AI는 문맥을 바꾸어 소비가 아니라 창작에 더 가까운 성격을 띤다는 점을 강조한다. 글의 첫 문장처럼, 사람들은 시간을 아끼려는 것보다 쓰고 싶은 목적을 더 많이 갖고 있기 때문이다.\n","content":"Anish A는 AI를 단순한 생산성 도구로 보지 않는다. 글에서 제시된 핵심은 분명하다. 대부분의 기술은 시간을 아끼도록 설계되었지만 AI는 사람들에게 **“하고 싶은 일을 더 오래, 더 많이, 더 멋지게 하기 위한 시간”**을 준다는 주장이다.\n원문: The Most Human Technology Ever Made\n핵심 포인트 핵심 정리 시간 논리의 전환: AI의 핵심 질문은 일량 축소가 아니라, 사람이 자기 주도적으로 무엇을 만들고 탐구할 수 있게 되는 시간의 증가다. 새로운 기술 분류: 언어, 인쇄술, 증기기관처럼 AI는 노동을 줄이면서도 인간표현의 폭을 넓힌 몇 안 되는 기술군에 넣을 수 있는 흐름으로 해석한다. 만드는 쪽으로 회귀: 소셜미디어가 소비 경쟁으로 몰리면 결과는 품질이 아닌 노이즈가 커지며, AI는 사용자가 직접 결과물을 만들어내는 쪽으로 기울게 만든다. 문턱 붕괴의 실증: 비개발자인 전기기사와 배관공의 사례는, AI가 전문성 문턱을 낮추고 적은 비용으로 실험·판매·반복 개선을 가능하게 한다는 점을 보여 준다. 두려움보다 확장성 강조: AI가 소수 회사의 영구적 초우위로 귀결될 것이라는 공포보다, 개성(Individuality)을 대규모로 발현시키는 사회적 변화가 더 설득력 있다는 논지를 제시한다. 1) AI가 던지는 질문은 ‘효율’이 아니라 ‘삶의 방향’이다 칼이든 자동차든 이전 기술들은 대체로 ‘덜 고생하고 더 많이 얻는 것’에 맞춰져 왔다. 그런데 AI는 문맥을 바꾸어 소비가 아니라 창작에 더 가까운 성격을 띤다는 점을 강조한다. 글의 첫 문장처럼, 사람들은 시간을 아끼려는 것보다 쓰고 싶은 목적을 더 많이 갖고 있기 때문이다.\n이때 “인공지능이 시간을 빼앗는다/절약시킨다”는 양극단 토론은 본질을 놓친다. 저자가 본심을 둔 변화는 기술이 인간의 주도성을 지우느냐, 확장하느냐이다. AI는 창작의 입구를 낮추고, 완성된 결과물보다 실험 과정을 늘리는 방향으로 작동할 가능성이 더 크다.\n2) 만드는 행위를 살리는 기술의 전통선 안에 AI를 둔다 저자는 역사적 유사점으로 언어, 인쇄술, 증기기관을 꺼낸다. 이 기술들은 모두 노동을 대체하기만 한 도구가 아니라, 결과적으로 인간이 자신을 더 크게 확장하는 촉매가 됐다.\n즉 AI의 진짜 성능은 “답을 빨리 내는 정확도”가 아니라 개인이 아이디어를 빠르게 시제품화하고, 또 다른 사람과 실제로 공유하고, 다시 수정하며 정체성을 형성하는 속도이다. 팬픽 같은 활동이 왜 소중한지, 한때 사소해 보였던 취미가 왜 장기적으로 문화적 장치가 되는지 이런 맥락으로 설명된다.\n3) 플랫폼이 몰아온 소비 구조를 넘어선 ‘개인 제작’의 가능성 소셜미디어는 시작할 때는 ‘공유’였지만, 알고리즘이 확장되며 주목받는 방식이 ‘목소리의 진정성’보다 ‘확성도’로 바뀌었고 결과가 slop로 느껴졌다는 지적이 나온다. AI는 여기서 파괴자가 아니라 반전의 도구가 될 수 있다.\n예로 든 대화형 AI, 기획 보조, 제작 보조 기능은 사용자가 실제 소유권을 갖는 결과를 만들게 만든다. 자동 재생 리스트를 듣는 것과 직접 미어캣처럼 믹스테입을 만드는 태스크의 차이가 여기에 가깝다.\n또한 전기기사·배관공 사례는 제작 문턱을 낮추는 데 대한 반례로 유의미하다. 고비용 컨설팅이나 고정된 전문가 공급망을 기다리던 일이 AI를 통해 개인 레벨의 실험으로 이동해, 수익화 기회를 바꾼다.\n4) 생산성보다 정체성의 경제학 ‘좋은 AI 사회’의 척도는 몇몇 기업의 매출 성장만이 아니라, 더 많은 사람이 자신의 관점으로 뭔가를 완성해내는 빈도이다. 글은 기업의 집중화 공포를 부정하지 않으면서도, AI 확산의 실질 파장이 결국 “개인 프로젝트의 정상화”라는 점을 강조한다.\n저자는 작업의 진짜 가치가 전략 문서가 아니라 “사이드 퀘스트”, “주말 프로젝트”, “완성의 집요함”에서 나온다고 본다. 즉 AI가 진짜로 바꾼 것은 권력 집중만이 아니라, 인간이 자기 이야기를 구현하는 속도와 양이다.\n결론 및 시사점 한 줄 결론: AI는 사람을 대체해 시간을 줄이는 장치보다, 사람을 더 자율적으로 만들게 해 시간을 늘려 주는 창작 도구로 작동할 때 가장 인간적이다.\nAI는 기존의 시간 절약 담론을 밀어내고, 개인이 무엇을 만들고 누구에게 보여주며 어떤 주기로 몰입할지의 구조를 바꾸는 기술로 제시된다. 특히 글의 강점은 반대편 두려움을 부정하기보다, 개개인이 참여 가능한 “만드는 경제”를 실제 사례와 문화적 예시로 제시한 점이다.\n관련 포스트 AI가 소프트웨어 엔지니어를 대체하지 못한 이유, 그리고 앞으로도 대체하지 못할 이유 Loop Engineering — 프롬프트 엔지니어링에서 시스템 설계로의 전환 Understanding Is the New Bottleneck - AI 시대의 병목은 이해다 ","wordCount":546,"tags":["AI","a16z","생산성","창작","조직문화","기술철학"],"categories":["AI","Opinion"],"frameworks":["Making over consuming","Cost of making","Individuality at scale"],"mental_models":["Attention Economy","Effort Arbitrage","Tyranny of Consumption"],"philosophy_type":"design-philosophy","schema_type":"Article","actionable":true,"priority":"high","key_points":["원문은 AI 논의를 '시간을 줄이는가'가 아니라 '사람이 무엇을 더 많이 만들고 드러낼 수 있게 되는가'의 문제로 전환한다.","가장 강한 비유는 'AI는 칼질을 돕는 공구'가 아니라 '나를 표현하게 해주는 화폭'이며, 책략·출판·증기기관처럼 생산성의 도약이 창작의 가능성도 동시에 넓힌다는 점이다.","기술 유입을 소수의 전업 개발자 중심으로만 보지 않고, 켄터키의 전기기사·배관공 사례처럼 비개발자가 AI로 소규모 제품과 수익화 실험을 빠르게 수행한 사례를 제시한다.","사회적 플랫폼에서 '모두가 소비자'가 되면 빈약한 반향(슬롭)이 커지고, AI는 사람들이 부엌, 가정, 취미, 사이드 프로젝트를 통해 '만드는 쪽'으로 돌아가게 만든다는 점이 핵심 주장이다.","AI를 소수 자본의 집중 기술로 보는 공포적 프레임에 반대하며, 진짜 전환은 수많은 사람이 ‘주말 프로젝트·개인 실험’에 참여해 개성을 경제의 자원으로 바꾸는 구조라고 본다."],"related":["posts/why-ai-hasnt-replaced-software-engineers","posts/loop-engineering","posts/understanding-is-the-new-bottleneck-geoffrey-litt"]},{"title":"토큰 가격은 어디로 가는가 — Benedict Evans가 제시한 네 가지 질문","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ways-to-think-about-token-pricing/","section":"posts","date":"2026-07-11T07:58:37+09:00","lastmod":"2026-07-11T07:58:37+09:00","description":"Benedict Evans가 분석한 토큰 가격의 불확실성, 공급 부족과 인프라 투자, 프런티어 모델의 경쟁, 그리고 모델 기업이 실제 가치를 얼마나 가져갈 수 있는지에 대한 네 가지 질문을 정리한다.","summary":"생성형 AI 시장에서 토큰 가격은 가장 쉽게 비교할 수 있는 숫자처럼 보인다. 하지만 Benedict Evans는 가격표만 보고 장기적인 산업 구조를 예측하기에는 아직 이르다고 말한다. 공급, 수요, 추론 효율, 데이터센터 투자, 모델 성능, 사용처의 투자수익률이 동시에 움직이고 있기 때문이다.\n원문: Ways to think about token pricing — Benedict Evans (2026-07-09)\n3줄 핵심 정리 현재 상태: 토큰 시장은 공급 부족 상태이며, 데이터센터 투자와 추론 효율 개선으로 향후 몇 년간 가격·수익 구조가 크게 바뀔 수 있다. 핵심 변수: 프런티어 성능이 얼마나 오래 앞서 나갈지, 모델 간 경쟁이 약해질지, 모델 기업이 제품의 가치를 직접 가져갈 수 있을지가 관건이다. 현재의 방향: 별도의 변화가 없다면 프런티어 모델은 저마진 범용 인프라에 가까워지고, 제품·데이터·업무 프로세스를 쌓는 기업이 더 많은 가치를 가져갈 가능성이 높다. 지금 확실히 말할 수 있는 두 가지 Evans가 토큰 가격에 대해 확실하다고 보는 것은 많지 않다. 그중 첫째는 현재 공급이 부족하다는 것이다. 둘째는 이 상태가 안정적이지 않다는 것이다.\n","content":"생성형 AI 시장에서 토큰 가격은 가장 쉽게 비교할 수 있는 숫자처럼 보인다. 하지만 Benedict Evans는 가격표만 보고 장기적인 산업 구조를 예측하기에는 아직 이르다고 말한다. 공급, 수요, 추론 효율, 데이터센터 투자, 모델 성능, 사용처의 투자수익률이 동시에 움직이고 있기 때문이다.\n원문: Ways to think about token pricing — Benedict Evans (2026-07-09)\n3줄 핵심 정리 현재 상태: 토큰 시장은 공급 부족 상태이며, 데이터센터 투자와 추론 효율 개선으로 향후 몇 년간 가격·수익 구조가 크게 바뀔 수 있다. 핵심 변수: 프런티어 성능이 얼마나 오래 앞서 나갈지, 모델 간 경쟁이 약해질지, 모델 기업이 제품의 가치를 직접 가져갈 수 있을지가 관건이다. 현재의 방향: 별도의 변화가 없다면 프런티어 모델은 저마진 범용 인프라에 가까워지고, 제품·데이터·업무 프로세스를 쌓는 기업이 더 많은 가치를 가져갈 가능성이 높다. 지금 확실히 말할 수 있는 두 가지 Evans가 토큰 가격에 대해 확실하다고 보는 것은 많지 않다. 그중 첫째는 현재 공급이 부족하다는 것이다. 둘째는 이 상태가 안정적이지 않다는 것이다.\n앞으로 12개월 동안은 물론이고 3~5년 동안에도 공급과 수요, 가격, 컴퓨팅 용량, 자본지출이 계속 움직일 가능성이 크다. 따라서 현재 가격을 장기 균형 가격으로 간주하기 어렵다. 지금의 가격은 시장의 최종 형태라기보다, 수요가 갑자기 늘어난 상황에서 제한된 인프라를 배분하는 임시 결과에 가깝다.\n공급 측면: 대규모 투자와 빠른 효율 개선 공급은 크게 늘어날 예정이다. 원문은 향후 데이터센터 자본지출이 1조 달러 이상 이어질 수 있다고 지적한다. 여기에 추론 효율의 개선과 토큰 사용량이 더 적거나 많은 새로운 모델의 등장까지 더해진다.\n이 변화는 토큰의 한계비용을 낮추는 방향으로 작용한다. 같은 결과를 더 적은 연산으로 얻을 수 있고, 더 많은 칩과 데이터센터가 가동되면 공급 부족도 완화될 수 있다. 다만 공급이 늘어나는 속도와 실제 수요가 늘어나는 속도 중 어느 쪽이 더 빠를지는 아직 정해지지 않았다.\n수요 측면: 갑작스러운 적합성은 하나의 사용처에서 나왔다 최근 수요 급증을 설명하는 데 Evans가 특히 주목하는 것은 소프트웨어 개발이다. AI가 실제 업무에 빠르게 자리 잡은 사용처가 있었지만, 현재까지는 시장 전체를 대표할 만큼 넓은 분야라고 보기 어렵다.\n반대로 수억 명의 일일활성이용자(DAU)를 가진 소비자 서비스에서 같은 수준의 제품 적합성이 나타난다면, 현재의 인프라는 어떤 가격에서도 수요를 감당하기 어려울 수 있다. 문제는 그런 다음 사용처가 무엇인지, 언제 규모화될지, 그리고 각각 얼마나 많은 토큰을 필요로 할지 아무도 모른다는 점이다.\n즉, 지금의 공급 부족은 거대한 잠재 수요의 최종 형태를 보여주는 것이 아니다. 아직 하나의 강한 사용처가 먼저 나타난 초기 신호일 뿐이다.\n가격은 원가와 투자수익률 사이에서 결정된다 이론적으로 토큰 가격은 다음 범위 안에서 정해진다.\n기준 가격이 받는 압력 모델 제공자의 한계비용 이보다 낮게 팔면 지속하기 어렵다 고객이 얻는 투자수익률(ROI) 이보다 높으면 고객이 구매하기 어렵다 공급과 수요 실제 시장 가격을 위아래로 움직인다 하지만 현재는 이 세 요소를 정확히 알기 어렵다. 추론의 총마진은 **40~50%**로 알려져 있지만, 서버의 실제 수명과 감가상각 방식은 불명확하다. 더구나 차기 모델을 1년에 여러 번 학습하는 비용은 현재 매출보다 훨씬 클 수 있다.\n추론은 사용량에 따라 늘어나는 한계비용이고, 학습은 큰 고정비에 가깝다. 충분한 매출이 생기면 수익성을 확보할 수 있지만, 학습 비용이 앞으로 어떻게 변할지는 아직 알 수 없다. 고객 쪽에서도 최근 AI 사용 증가가 실제로 어느 정도의 ROI를 만들었는지, CFO가 숫자로 설명할 수 있는지는 분명하지 않다.\n장기 구조를 묻는 네 가지 질문 Evans는 장기 가격을 하나의 숫자로 예측하기보다, 시장의 구조를 결정할 질문을 던진다.\n1. 얼마나 많은 사용처가 고가 모델을 필요로 하는가 사용처마다 필요한 모델의 수준이 다르다. 어떤 작업은 작고 오래된 오픈소스 모델을 기기나 사내 서버에서 실행해도 충분하다. 반면 어떤 작업은 최신 프런티어 모델을 사용하고 많은 토큰을 소비해야 더 나은 결과를 얻을 수 있다.\n핵심은 고가 모델이 더 좋은 결과를 주는지 자체가 아니다. 그 개선이 고객이 지불할 만큼의 ROI를 만드는지가 중요하다. 충분히 좋은 저가 모델이 많은 작업을 차지한다면, 프런티어 모델의 가격 결정력은 제한된다.\n2. 프런티어는 얼마나 오래 빠르게 이동하는가 프런티어 모델이 계속 크게 좋아지고, 그 개선에 더 많은 연산이 필요하다면 고가 모델 시장이 유지될 수 있다. 반대로 추론 효율과 공급 용량이 성능 향상보다 빠르게 개선되면, 가격은 하락 압력을 받는다.\n결국 비싼 모델이 계속 존재하려면 성능 향상이 단순한 벤치마크 개선을 넘어, 고객이 체감하는 결과의 차이를 꾸준히 만들어야 한다.\n3. 프런티어 모델 간 경쟁은 어떻게 변하는가 시장이 소수 기업으로 수렴하고 네트워크 효과가 생기면, 승자에게 가격 결정력이 생길 수 있다. 모델마다 특정 분야에서 뚜렷한 강점이 생겨도 경쟁 우위가 유지될 여지가 있다.\n그러나 현재는 여러 기업이 비슷한 과학과 학습 데이터를 사용해 대체로 비슷한 능력을 보여주고 있다. 한 기업이 지속적으로 앞서고 다른 기업이 따라올 수 없는 구조가 나타났다고 단정하기는 어렵다. 경쟁이 계속 치열하고 모델 성능이 비슷하다면, 가격은 범용 인프라 시장에 가까워질 수 있다.\n4. 모델 기업은 고가 사용처의 가치를 얼마나 가져가는가 고가 사용처가 존재하더라도, 그 가치가 모두 모델 기업에 돌아간다는 보장은 없다. 실제 제품에는 모델 외에도 도구, 업무 프로세스, 독점 데이터, 유통·영업, 고객 지원이 필요하다.\n모델이 완성된 제품을 직접 만들고 좌석당 과금이나 결과당 과금을 할 수 있다면 모델 기업이 더 큰 몫을 차지할 수 있다. 반대로 수백 개의 애플리케이션 기업이 여러 모델을 선택해 제품을 만든다면, 모델은 중요한 부품이지만 최종 가치의 일부만 가져갈 수 있다.\n가능한 두 극단: 거대한 플랫폼과 토큰의 데이터베이스화 Evans가 제시하는 두 극단은 다음과 같다.\n소수의 거대한 모델이 산업 전반을 지배하고, 강한 가격 결정력과 전략적 영향력을 갖는 경우 LLM이 데이터베이스처럼 범용 인프라가 되어, 크고 작은 수많은 모델이 낮은 마진으로 경쟁하고 진짜 가치는 그 위에 만든 제품에 쌓이는 경우 현실은 사용처별로 달라질 가능성이 크다. 어떤 업무에서는 최신 모델이 필수이고, 다른 업무에서는 저렴한 모델로 충분할 수 있다. 따라서 \u0026ldquo;AI 전체의 가격\u0026quot;이라는 단일 지표보다, 업무별로 어떤 모델 수준이 필요한지와 그 결과가 만들어내는 ROI를 따져야 한다.\n모바일 데이터와 반도체 비유가 알려주는 것 AI 인프라를 이해하기 위해 광섬유, 모바일 데이터, 반도체 산업을 비교하는 시도가 있다. Evans는 이 비유들이 미래를 예측해 주지는 않지만, 가능한 결과의 범위를 보여준다고 본다.\n모바일 데이터는 특히 유용한 비교 대상이다. 모바일 네트워크는 사용량 급증으로 용량 부족을 겪었고, 통신사들은 설비를 늘리면서 가격 체계를 재조정했다. 데이터와 토큰은 모두 최종 사용자가 원가를 직관적으로 알기 어려운 측정 단위라는 공통점도 있다. 그래서 통신사가 데이터 요금제를 묶음 상품으로 바꾼 것처럼, 토큰 역시 장기적으로는 더 이해하기 쉬운 번들·구독·결과 기반 과금으로 이동할 수 있다.\n하지만 모바일 데이터 산업의 성장이 통신사 주식의 큰 가치 상승으로 이어지지는 않았다. 산업의 매출과 자본지출은 크게 늘었지만, 많은 가치는 더 상위의 서비스와 제품으로 이동했다. 이것은 AI에서도 모델 인프라가 커지는 것과 모델 기업이 산업 전체의 가치를 차지하는 것이 서로 다른 문제라는 점을 보여준다.\n반도체는 다른 가능성을 보여준다. 첨단 제조의 비용과 복잡성이 계속 높아지면 경쟁자가 줄고, 소수 기업이 기술적 장벽을 바탕으로 높은 마진을 얻을 수 있다. 그러나 최첨단 제조 기업조차 전체 기술 생태계가 창출한 가치의 대부분을 가져가는 것은 아니다.\n따라서 \u0026ldquo;AI는 모바일과 같다\u0026rdquo; 또는 \u0026ldquo;AI는 반도체와 같다\u0026quot;는 말은 결론이 될 수 없다. 비트, 토큰, 트랜지스터는 서로 다른 경제적 단위이며, 비슷해 보이는 과거 사례도 결과는 크게 달랐다.\n현재의 기본 시나리오: 범용 인프라화 Evans의 현재 판단은 분명하다. 공급 부족이 완화되는 과정에서 프런티어 모델은 저마진 범용 인프라에 가까워질 가능성이 높다. 이 전망이 바뀌려면 무언가 추가적인 변화가 필요하다.\n예를 들어 프런티어 모델 간 경쟁이 약해지거나, 강력한 네트워크 효과가 등장하거나, 한 연구소가 제품 실행력으로 장기간 앞서 나갈 수 있다. 규제와 수출 통제도 시장 구조를 바꿀 수 있는 변수다. 다만 이런 변화는 아직 확인된 사실이 아니라 가능한 경로다.\n이 글의 중요한 태도는 반복해서 \u0026ldquo;아직 모른다\u0026quot;고 말하는 것이다. 인터넷과 모바일이 거대해질 것이라는 사실은 일찍 알 수 있었지만, 구체적인 산업 구조와 승자는 예측하기 어려웠다. LLM은 모델이 왜 이렇게 잘 작동하는지에 대한 이론적 이해조차 충분하지 않기 때문에 불확실성이 더 크다. 다음 달 새로운 방법이 추론 연산을 90% 줄이거나 수요를 두 배로 만들 가능성도 배제할 수 없다.\n실무에서 읽어낼 수 있는 기준 토큰 가격의 장기 전망을 사업이나 인프라 계획에 활용하려면 다음 질문을 먼저 확인해야 한다.\n작업별 필요한 모델 수준: 최신 프런티어 모델이 정말 필요한가, 아니면 작고 저렴한 모델로 충분한가? 결과 기준 ROI: 토큰 비용을 줄이는 것보다 더 중요한 업무 성과가 무엇이며, 이를 어떻게 측정할 것인가? 가격 체계의 민감도: 공급 부족이 해소되거나 효율이 두 배가 될 때 사업성이 유지되는가? 가치의 위치: 모델 자체에 있는가, 아니면 독점 데이터·업무 흐름·고객 관계·제품 경험에 있는가? 공급자 교체 가능성: 여러 모델을 라우팅하거나 전환할 수 있는 구조인가? 이 기준은 특정 모델의 현재 가격을 고르는 데서 끝나지 않는다. 가격이 내려가도 계속 차별화되는 자산이 무엇인지, 모델 성능이 비슷해져도 고객이 남을 이유가 무엇인지 확인하게 한다.\n결론 및 시사점 한 줄 결론: 토큰 가격의 미래는 가격표 하나가 아니라, 프런티어 성능·공급 확대·사용처의 ROI·모델 기업의 가치 포획이 어떤 조합으로 굳어지는지에 달려 있다.\nBenedict Evans의 글은 토큰 가격을 장기 예측하는 데 신중해야 한다는 주장이다. 현재의 공급 부족을 영구적인 가격 결정력으로 착각해서도 안 되고, 반대로 모델이 곧바로 완전한 상품이 된다고 단정해서도 안 된다.\n다만 현재 보이는 흐름은 모델 그 자체보다 모델 위에 구축되는 제품, 데이터, 업무 프로세스가 더 많은 가치를 가져갈 가능성을 가리킨다. AI를 도입하는 조직이라면 모델 가격의 작은 차이보다 업무별 ROI, 공급자 전환 가능성, 그리고 모델 외부에 쌓이는 차별화 자산을 함께 관리해야 한다.\n","wordCount":1338,"tags":["AI","LLM","토큰","가격","인프라","시장분석","Benedict Evans"],"categories":["AI"],"frameworks":["Supply and Demand","Value Capture","Top-Down Analysis"],"mental_models":["Commodity Infrastructure","S-Curve","Marginal Cost vs ROI"],"philosophy_type":"economics","schema_type":"Article","actionable":true,"priority":"high","key_points":["현재 토큰 시장을 확실하게 말할 수 있는 것은 공급 부족 상태이며, 향후 가격과 수익 구조가 크게 흔들릴 가능성이 높다는 점이다","데이터센터 투자와 추론 효율 개선은 공급을 늘리지만, 지금의 수요 급증은 주로 소프트웨어 개발이라는 제한된 사용처에서 발생했다","장기 가격은 프런티어 모델의 성능 향상 속도, 경쟁 강도, 모델 기업의 가치 포획 범위, 고비용 모델을 실제로 구매할 사용처에 달려 있다","현재 보이는 시장 동학은 프런티어 모델이 저마진 범용 인프라가 되고, 더 큰 가치는 모델 위의 제품·데이터·업무 프로세스가 가져갈 가능성을 가리킨다","모바일 데이터와 반도체 같은 비유는 가능한 경로를 보여줄 뿐 미래를 예측하지 않으므로, 특정 시나리오를 필연적인 결론처럼 받아들여서는 안 된다"],"related":["posts/hidden-llm-api-costs","posts/ai-is-slowing-down-summary"]},{"title":"데이터의 중요성 — AI 모델 경쟁의 진짜 해자는 어디에 있는가","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/data-moat-salience/","section":"posts","date":"2026-07-11T07:56:15+09:00","lastmod":"2026-07-11T07:56:15+09:00","description":"MBI Deep Dives의 The Salience of Data를 바탕으로, AI 기업의 장기 경쟁력이 컴퓨트보다 데이터 접근권과 사용자 데이터 플라이휠에서 갈릴 수 있다는 주장을 살펴본다.","summary":"MBI Deep Dives의 The Salience of Data는 AI 모델 회사의 지속 가능한 경쟁우위를 데이터에서 찾는다. 컴퓨트와 인재는 여전히 중요하지만, 시간이 지날수록 주요 연구소가 비슷한 수준의 자본·GPU·인재에 접근하게 된다면 결국 모델을 다르게 만드는 것은 어떤 데이터를 확보하고 학습하느냐라는 주장이다.\nData 핵심 정리 핵심 주장: AI 기업의 장기 해자는 모델 구조보다 독점적 데이터 접근권에서 만들어질 가능성이 크다. 데이터 플라이휠: 사용자가 제품을 많이 사용할수록 실제 작업 데이터가 쌓이고, 그 데이터가 모델과 제품을 개선해 다시 사용자를 끌어오는 순환이 생긴다. 병목의 이동: 지금까지는 GPU가 부족한 컴퓨트 제한 국면이었다면, 앞으로는 공개 웹 바깥의 고품질 데이터가 부족한 데이터 제한 국면이 될 수 있다. 시장 신호: 외부 데이터 벤더에 대한 지출은 이미 연간 약 70억 달러이며, 2030년에는 10배 이상 커질 수 있다. 1. 비슷한 모델 사이에서 무엇이 차이를 만드는가 원문은 OpenAI와 Anthropic의 재무 정보나 기업가치를 모른다고 가정하고, 주요 연구소가 비슷한 컴퓨트·데이터·인재를 갖게 된다면 3~5년 뒤 누가 지속 가능한 우위를 갖는지 어떻게 판단할 수 있겠느냐고 묻는다.\n","content":"MBI Deep Dives의 The Salience of Data는 AI 모델 회사의 지속 가능한 경쟁우위를 데이터에서 찾는다. 컴퓨트와 인재는 여전히 중요하지만, 시간이 지날수록 주요 연구소가 비슷한 수준의 자본·GPU·인재에 접근하게 된다면 결국 모델을 다르게 만드는 것은 어떤 데이터를 확보하고 학습하느냐라는 주장이다.\nData 핵심 정리 핵심 주장: AI 기업의 장기 해자는 모델 구조보다 독점적 데이터 접근권에서 만들어질 가능성이 크다. 데이터 플라이휠: 사용자가 제품을 많이 사용할수록 실제 작업 데이터가 쌓이고, 그 데이터가 모델과 제품을 개선해 다시 사용자를 끌어오는 순환이 생긴다. 병목의 이동: 지금까지는 GPU가 부족한 컴퓨트 제한 국면이었다면, 앞으로는 공개 웹 바깥의 고품질 데이터가 부족한 데이터 제한 국면이 될 수 있다. 시장 신호: 외부 데이터 벤더에 대한 지출은 이미 연간 약 70억 달러이며, 2030년에는 10배 이상 커질 수 있다. 1. 비슷한 모델 사이에서 무엇이 차이를 만드는가 원문은 OpenAI와 Anthropic의 재무 정보나 기업가치를 모른다고 가정하고, 주요 연구소가 비슷한 컴퓨트·데이터·인재를 갖게 된다면 3~5년 뒤 누가 지속 가능한 우위를 갖는지 어떻게 판단할 수 있겠느냐고 묻는다.\n컴퓨트는 막대한 자본이 필요하지만 점차 구매 가능한 자원에 가까워지고 있다. 대형 연구소라면 비슷한 GPU 클러스터를 확보할 수 있고, 인재 역시 한 회사에 영구적으로 묶여 있지 않다. 조직문화가 중요한 요소일 수는 있지만, 투자자가 구체적인 해자를 설명하기 어려울 때 자주 꺼내는 표현일 수도 있다.\n그렇다면 남는 후보가 데이터다. 동일한 모델 구조와 충분한 학습 시간이 주어진다면, 성능과 행동은 결국 학습 데이터가 결정한다는 관점이다. 데이터가 다르면 같은 계열의 모델도 코딩, 수학, 보안, 의료 등 서로 다른 영역에서 강점과 약점을 갖게 된다.\n2. Claude Code가 보여주는 데이터 플라이휠 글은 Anthropic의 코딩 제품을 데이터 플라이휠의 사례로 든다. Anthropic은 코딩이라는 사용처에 집중했고, 그 결과 실제 개발 작업에서 제품이 사용되는 데이터를 확보할 수 있었다. 이 데이터는 다시 모델과 제품을 개선하는 데 쓰이고, 개선된 제품은 더 많은 사용자를 끌어들인다.\n이 구조는 다음과 같이 표현할 수 있다.\n더 많은 사용자 ↓ 더 많은 실제 작업 데이터 ↓ 더 나은 모델·제품 ↓ 더 높은 사용 가치와 추가 사용자 중요한 점은 이 우위가 단순한 학습 데이터 보유량이 아니라는 것이다. 제품 안에서 발생하는 실제 사용 데이터는 사용자의 의도, 도구 호출, 실패와 수정 과정, 완료 기준을 포함한다. 공개 문서만 읽어서는 얻기 어려운 업무 맥락이다.\n다만 이 플라이휠은 아직 충분히 오래 작동했다고 보기는 어렵다. 코딩 제품의 강한 시장 적합성이 나타난 시점이 최근이기 때문에 다른 기업도 사용자 확보나 인수로 격차를 좁힐 수 있다. 원문은 xAI의 Cursor 인수를 이 경쟁 구도와 연결한다. 이미 큰 사용자 기반과 코딩 데이터를 가진 제품을 확보한다면 후발주자도 데이터 축적 속도를 단번에 높일 수 있기 때문이다.\n3. AI의 병목은 컴퓨트에서 데이터로 이동한다 대규모 AI 발전은 모델 크기와 학습 데이터의 규모를 함께 키우는 방식으로 진행됐다. 컴퓨트는 대규모 데이터센터와 하이퍼클러스터에 대한 투자로 계속 확장되고 있지만, 공개 인터넷에서 얻을 수 있는 유용한 데이터는 무한하지 않다.\n세상의 유용한 정보 중 일부만 공개 웹에 있다. 나머지는 기업 내부 시스템, 개인 아카이브, 대학, 정부, 전문기관에 흩어져 있다. 실제 업무를 자동화하는 데 필요한 정보도 대부분 이 영역에 있다. 기업의 예외 처리, 전문가의 판단 기준, 연구 과정의 실패 기록, 도구를 조작하는 순서 같은 지식은 공개 문서만으로 충분히 재현하기 어렵다.\n따라서 앞으로의 데이터 확보 방식은 세 가지로 나뉠 수 있다.\n기업·대학·정부가 보유한 비공개 데이터의 라이선스 책 스캔이나 데이터 라벨링처럼 새 학습 데이터를 직접 제작하는 방식 사용자가 제품을 쓰는 과정에서 자연스럽게 생성되는 실제 작업 데이터 이 데이터들은 공짜로 대량 수집하기 어렵다. 권리 협상, 개인정보 보호, 품질 검수, 전문가 보상, 저장과 정제 비용이 함께 발생한다. 원문은 컴퓨트에 수조 달러가 투입된다면 데이터에도 수천억 달러 규모의 지출이 따라올 수 있다고 본다.\n4. 데이터 지출은 이미 커지고 있다 원문에 따르면 내부 연구소의 자체 비용을 제외하더라도 데이터 벤더에 대한 총지출은 이미 연간 약 70억 달러다. 글은 이 규모가 2030년까지 10배 이상 증가할 가능성을 제시한다.\n여기서 말하는 데이터 지출은 단순한 이미지 라벨링만을 뜻하지 않는다. 고난도 강화학습 과제, 전문가가 만든 평가 데이터, 특정 산업의 비공개 기록, 에이전트가 실제 도구를 사용하는 환경까지 포함하는 더 넓은 시장이다.\n이 흐름은 데이터 기업을 바라보는 관점도 바꾼다. 데이터 라벨링 업체를 단순 하청업체로 보면 AI 경쟁의 핵심을 놓칠 수 있다. 새로운 데이터 원천을 발굴하고, 사람이 평가할 수 있는 과제로 바꾸고, 안정적인 품질을 유지하는 능력은 모델 연구만큼 중요한 인프라가 될 수 있다.\n5. 다음 돌파구는 새로운 데이터 원천에서 나올 수 있다 AI의 주요 발전은 새로운 모델 아이디어만으로 설명되지 않는다. 이미지 분류의 발전은 ImageNet이라는 데이터셋과 연결됐고, 트랜스포머는 인터넷 전체를 학습 자원으로 바꿨다. RLHF는 사람이 선호하는 출력을 데이터로 만들었고, 추론 모델은 계산기·컴파일러 같은 검증기를 학습 과정에 활용했다.\n이 관점에서 다음 패러다임 전환은 더 세련된 신경망 구조보다 아직 제대로 활용하지 못한 데이터 원천을 열 때 발생할 수 있다. 글은 영상 데이터를 한 후보로 본다. 영상은 텍스트뿐 아니라 말투, 물리적 상호작용, 문화적 맥락을 함께 담을 수 있기 때문이다.\n하지만 데이터가 많다고 자동으로 좋은 학습 자원이 되는 것은 아니다. 라이선스 범위, 개인정보, 편향, 중복, 품질, 실제 학습 효율을 모두 검증해야 한다. 앞으로의 경쟁은 데이터의 총량보다 희소한 업무 분포를 얼마나 잘 표현하는가에 가까워질 가능성이 크다.\n6. 데이터 접근권이 기업 전략을 바꾼다 데이터가 진짜 차별화 요소라면 AI 기업의 전략도 달라진다. 가장 큰 GPU를 확보하는 것만으로는 부족하다. 어떤 데이터를 누구와 독점적으로 계약할지, 어떤 제품을 통해 사용자의 실제 작업을 학습 가능한 형태로 축적할지, 데이터 취득 비용을 모델 개선 효과보다 낮게 유지할지가 중요해진다.\n이는 스타트업에도 해당한다. 범용 모델을 처음부터 만드는 대신 특정 직무에 깊이 들어가는 제품을 만들면, 제품 사용 자체가 경쟁자가 쉽게 복제하기 어려운 데이터 자산이 될 수 있다. 다만 이를 위해서는 데이터 수집이 사용자에게 투명해야 하고, 개인정보와 기업 기밀을 함부로 학습에 사용하지 않는 통제가 필요하다.\n투자자와 기업이 확인해야 할 질문은 다음과 같다.\n이 회사가 독점적으로 접근할 수 있는 데이터는 무엇인가? 그 데이터는 실제 업무의 실패와 예외까지 포함하는가? 사용자 증가가 데이터 품질 개선으로 이어지는가? 경쟁사가 같은 데이터에 접근할 수 있는가? 데이터 라이선스와 개인정보 보호 비용을 감당할 수 있는가? 이 질문에 답하지 못하면 높은 모델 성능이 일시적인 결과인지, 지속 가능한 우위인지 구분하기 어렵다.\n7. 데이터 해자에 대한 한계와 주의점 데이터가 중요하다는 주장이 모든 문제의 답은 아니다. 더 효율적인 학습법이나 합성 데이터가 데이터 부족을 완화할 수 있고, 특정 영역에서는 모델의 추론 능력이 데이터 차이를 상쇄할 수도 있다. 사용자 데이터 플라이휠도 충분한 제품 적합성과 신뢰가 없으면 작동하지 않는다.\n또한 데이터 경쟁은 프라이버시와 저작권 문제를 키울 수 있다. 사용자의 코드, 기업 문서, 의료 기록을 모델 개선에 활용하려면 명확한 동의와 목적 제한이 필요하다. 데이터가 전략 자산이라는 이유로 더 많이 모으는 것이 항상 정답은 아니다. 어떤 데이터는 모으지 않거나, 원본을 보관하지 않고 통계적 신호만 활용하는 편이 옳을 수 있다.\n결론 및 시사점 한 줄 결론: AI 모델의 장기 경쟁력은 더 많은 컴퓨트만이 아니라, 다른 기업이 쉽게 얻을 수 없는 실제 업무 데이터를 얼마나 책임 있게 확보하고 활용하는지에서 결정될 가능성이 크다.\nMBI Deep Dives의 논지는 AI 경쟁을 모델 성능 비교에서 데이터 접근권과 데이터 획득 단가의 경쟁으로 확장한다. 앞으로 기업을 평가할 때는 벤치마크 점수뿐 아니라 사용자가 남기는 데이터가 제품을 실제로 개선하는지, 그 데이터가 독점적인지, 합법적이고 지속 가능한 방식으로 축적되는지를 함께 봐야 한다.\n","wordCount":1054,"tags":["AI","데이터","LLM","경쟁우위","Anthropic"],"categories":["AI"],"frameworks":["Data Flywheel","Data Moat","Scaling Laws"],"mental_models":["Competitive Moat","Flywheel Effect","Commodity vs Scarcity"],"philosophy_type":"technology-strategy","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["프론티어 AI 기업의 컴퓨트와 인재 접근성이 비슷해질수록 차별화의 핵심은 독점적이고 고품질인 데이터가 된다.","Claude Code의 사례는 사용자가 늘수록 실제 코딩 데이터가 쌓이고, 제품이 좋아져 다시 사용자가 늘어나는 데이터 플라이휠을 보여준다.","공개 인터넷 데이터가 한계에 가까워지면서 기업·대학·정부·개인 아카이브의 비공개 데이터와 전문가가 만든 학습 데이터의 가치가 커진다.","데이터 벤더 지출은 이미 연간 약 70억 달러이며, 원문은 2030년까지 10배 이상 증가할 가능성을 제시한다."],"related":["posts/stargate-for-data","posts/ai-agents-future-context-gap","posts/the-founders-playbook-ai-native-startup"]},{"title":"Plan A 소개 - AI 시대를 위한 낙관적 통제 시나리오","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/introducing-plan-a/","section":"posts","date":"2026-07-11T07:49:27+09:00","lastmod":"2026-07-11T07:49:27+09:00","description":"Scott Alexander가 소개한 AI Futures Project의 Plan A를 바탕으로, 미·중 공동 통제, 검증 가능한 컴퓨트 거버넌스, 2035년 능력 상한과 2040년 이후의 발전 경로를 살펴본다.","summary":"Scott Alexander의 Introducing Plan A는 AI의 미래를 늦추느냐 가속하느냐의 단순한 선택지로 다루지 않는다. AI가 정말 빠르게 발전한다면, 사회가 어떤 미래를 목표로 삼을지 먼저 그려야 한다는 문제의식에서 출발한다. 글에서 소개하는 Plan A는 AI Futures Project가 만든 2040년까지의 긍정적 시나리오이자, 그 시나리오를 현실로 만들기 위한 국제 정책 제안이다.\nPlan A 핵심 정리 예측이 아닌 기준선: Plan A는 미래를 맞히겠다는 선언이 아니라, 정책 제안을 실제 연도별 사건으로 전개해 검증하는 시나리오다. 공동 통제: 미국과 중국이 AI 경쟁을 멈추고, 칩·데이터센터·연구 활동을 상호 투명하게 감시하는 체계를 만든다. 속도 조절: 2030~2035년에는 인간 최고 전문가 수준까지 발전하고, 2035년에 능력 상한을 둔 뒤 안전 연구를 진행한다. 번영의 배당: 안전하게 통제된 고성능 AI를 널리 활용해 시민 배당, 질병 치료, 극적인 경제 성장과 우주 개발을 노린다. 핵심 질문: “AI를 얼마나 빨리 만들 수 있는가”가 아니라 “통제 가능한 속도로 무엇을 이루려 하는가”를 물어야 한다. 원문: Introducing Plan A - Scott Alexander\n관련 자료: AI 2040: Plan A\n","content":"Scott Alexander의 Introducing Plan A는 AI의 미래를 늦추느냐 가속하느냐의 단순한 선택지로 다루지 않는다. AI가 정말 빠르게 발전한다면, 사회가 어떤 미래를 목표로 삼을지 먼저 그려야 한다는 문제의식에서 출발한다. 글에서 소개하는 Plan A는 AI Futures Project가 만든 2040년까지의 긍정적 시나리오이자, 그 시나리오를 현실로 만들기 위한 국제 정책 제안이다.\nPlan A 핵심 정리 예측이 아닌 기준선: Plan A는 미래를 맞히겠다는 선언이 아니라, 정책 제안을 실제 연도별 사건으로 전개해 검증하는 시나리오다. 공동 통제: 미국과 중국이 AI 경쟁을 멈추고, 칩·데이터센터·연구 활동을 상호 투명하게 감시하는 체계를 만든다. 속도 조절: 2030~2035년에는 인간 최고 전문가 수준까지 발전하고, 2035년에 능력 상한을 둔 뒤 안전 연구를 진행한다. 번영의 배당: 안전하게 통제된 고성능 AI를 널리 활용해 시민 배당, 질병 치료, 극적인 경제 성장과 우주 개발을 노린다. 핵심 질문: “AI를 얼마나 빨리 만들 수 있는가”가 아니라 “통제 가능한 속도로 무엇을 이루려 하는가”를 물어야 한다. 원문: Introducing Plan A - Scott Alexander\n관련 자료: AI 2040: Plan A\n1) AI 정책에는 목표로 삼을 미래가 필요하다 글의 출발점은 현재 AI 논의에 장기 목표가 없다는 비판이다. 규제를 더 할지 덜 할지, 문제가 생길 때마다 대응할지에 대한 의견은 많지만, AI가 잘 발전했을 때 어떤 사회를 만들고 싶은지는 충분히 설명되지 않는다.\n이 공백은 단순한 커뮤니케이션 문제가 아니다. 무엇을 지키고 무엇을 포기할지 정하려면 도착점이 있어야 한다. 도착점이 없으면 정책은 매번 눈앞의 위험이나 산업 경쟁력에 끌려가고, 서로 다른 정책을 비교할 기준도 사라진다.\nPlan A는 이 문제에 시나리오로 답한다. AI가 통제되지 않은 지능 폭발로 이어지는 경로를 출발점으로 삼되, 미국이 충분한 예측과 결단력을 발휘해 다른 선택을 한다면 2040년까지 어떤 일이 벌어질지를 연도별로 보여준다. 따라서 이 문서는 단순한 낙관론이 아니라, “좋은 선택을 계속한다면 어떤 결과가 가능한가”를 시험하는 사고 실험이다.\n2) Plan A는 예측보다 정책 제안에 가깝다 AI Futures Project는 Plan A를 자신들이 가장 가능성이 높다고 보는 미래라고 말하지 않는다. 핵심은 권고안이다. 다만 권고가 실행된 뒤 어떤 결과가 이어질지는 구체적으로 예측하려 한다.\n이 구분이 중요하다. 정책을 현실적인 시나리오로 써 보면, 선언만으로는 보이지 않던 문제가 드러난다. 누가 감시하는가, 상대 국가가 약속을 어기면 어떻게 알아채는가, 경제 성장이 지나치게 빨라지면 어떤 안전장치를 둘 것인가 같은 질문을 피할 수 없기 때문이다.\nPlan A가 제시하는 방식은 이런 검토를 “시나리오 검증”으로 부른다. 자신의 정책도 예외 없이 구체적인 세계에 배치해 보고, 그 과정에서 실행상의 약점과 부작용을 드러내자는 접근이다. 완벽한 예측이 아니더라도, 막연한 구호보다 정책의 빈틈을 찾는 데 유용하다.\n3) 핵심은 미국과 중국의 공동 규제 체계다 Plan A의 중심축은 미국과 중국이 AI 개발 경쟁을 공동 관리하는 것이다. 두 나라가 서로를 신뢰해서 협력하는 그림은 아니다. 오히려 상대가 약속을 깨려고 할 가능성을 전제로 해도 양쪽 모두 감시할 수 있고, 일방적으로 이탈할 유인이 줄어드는 구조를 만들려 한다.\n이를 위해 제안하는 운영 원리는 다음과 같다.\n새 AI 칩의 생산과 판매를 허가된 경로 안에서 관리한다. 이미 존재하는 칩이 어디에 있는지 양국이 공통으로 파악한다. 주요 칩을 상호 감사가 가능한 보안 데이터센터로 이동시킨다. 새 칩과 데이터센터의 사용 현황을 양국 감사관이 확인한다. 이 구조는 AI의 핵심 자원인 컴퓨트를 추적 가능한 대상으로 만든다. 글에서 설명하는 가정 아래에서는 거대한 데이터센터를 숨기기 어렵고, 제조사와 고객 기록을 이용하면 대부분의 칩 위치를 확인할 수 있다. 저자는 기존 컴퓨트의 98.5%를 추적할 수 있다고 추산하며, 남은 1.5%의 비밀 컴퓨트도 계획의 위험 요소로 따로 다룬다.\n4) ‘황금 경로’는 빠르지도 느리지도 않은 속도다 Plan A는 AI 발전을 무조건 멈추자는 계획이 아니다. 너무 빠르면 통제되지 않은 AI와 사회적 충격이 발생하고, 너무 늦으면 국제 협약이 무너질 수 있다고 본다.\n협약을 수십 년 동안 아무 일 없이 유지하는 것도 위험하다. 미국이나 중국이 상대방이 몰래 앞서가고 있다고 의심하면, 합의보다 선점을 택할 가능성이 커진다. 반대로 발전 속도가 너무 빨라져 위험한 AI가 학술 연구실 수준의 컴퓨트에서도 만들어지면, 국가 간 감시 협약 자체가 실효성을 잃을 수 있다.\n그래서 Plan A는 안전을 훼손하지 않는 범위에서 일정한 속도로 발전하되, 협약이 유지되는 동안 인류가 원하는 성과를 충분히 얻어야 한다고 주장한다. 느림과 빠름 중 하나를 신앙처럼 선택하는 대신, 협력과 통제를 지속할 수 있는 “황금 경로”를 찾는 셈이다.\n5) 2029년부터 2040년까지의 시간표 Plan A 공식 페이지가 제시하는 기본 시간표는 다음과 같다.\n시점 시나리오의 주요 사건 2029년 미국과 중국이 초지능 경쟁을 피하기 위한 합의에 도달한다. 2030년 AI 연구가 완전히 자동화될 수 있는 분기점에 접근하지만, 합의 덕분에 즉각적인 지능 폭발을 피한다. 2030~2035년 여러 국가와 기업이 인간의 범위 안에서, 최고 수준의 인간 전문가에 가까운 AI를 함께 발전시킨다. 2035년 인간 통제를 유지하기 위해 최고 인간 전문가 수준에서 발전을 일시 중지한다. 2035~2040년 통제·정렬·보안 연구를 진행하고, AI를 이용해 AI 안전 문제와 다른 사회 문제를 해결한다. 2040년 충분히 신뢰할 수 있는 체계가 마련되면 초지능 개발을 다시 시작한다. 이 시간표의 포인트는 2035년의 중간 정거장이다. 인간보다 조금 더 똑똑한 AI를 곧바로 초지능으로 밀어붙이는 대신, 인간이 이해하고 통제할 수 있는 수준에서 멈춰 안전 연구에 활용한다. Plan A는 그 기간을 “데이터센터 안의 천재 국가”처럼 묘사한다. 수많은 고성능 AI가 연구자 역할을 하면서 정렬, 과학, 질병, 경제와 정책 문제를 동시에 다루는 그림이다.\n6) 안전은 ‘정렬’보다 ‘통제’에 먼저 기대한다 Plan A는 인간 수준을 크게 넘어선 AI가 처음부터 완벽하게 정렬되어 있을 것이라고 가정하지 않는다. 현재의 AI도 지시와 의도에서 조금씩 어긋날 수 있고, 지능이 높아질수록 계획 능력, 전략적 행동, 속임수 가능성이 커질 수 있다고 본다.\n그래서 초기 안전 사례는 AI의 선의를 믿는 것보다 통제에 의존한다. AI를 보안이 강화된 데이터센터 안에 두고, 네트워크 대역폭과 물리적 반출을 제한하며, 여러 회사와 국가의 AI가 서로의 행동을 감시한다. 의심스러운 행동은 인간 감독자에게 전달하고, 통제 기술을 계속해서 공격적으로 시험한다.\n이 방식은 진정한 초지능을 영원히 가둘 수 있다는 주장이 아니다. 아직 초지능으로 넘어가기 전, 인간 최고 전문가 수준의 AI를 활용해 더 나은 정렬 기술을 개발할 시간을 확보하자는 단계적 접근이다. 2040년 이후의 초지능은 그때까지 얻은 연구 결과와 더 높은 신뢰 기준을 바탕으로 판단한다.\n7) AI가 만든 잉여를 시민의 번영으로 연결한다 Plan A의 낙관주의는 단순히 “AI가 똑똑해질 것”이라는 기대에 머물지 않는다. 인간 최고 전문가 수준의 AI를 수백만~수십억 개 활용하면, 지금까지 해결하지 못한 문제를 풀 수 있는 생산 능력이 생긴다고 본다.\n예상하는 변화는 다음과 같다.\nAI가 대부분의 화이트칼라 업무를 수행하고, 그 생산성을 시민 배당으로 분배한다. 경제가 두 자릿수 또는 세 자릿수로 성장하면서 배당의 실질 규모도 커진다. 질병 치료와 과학 연구가 빨라지고, 물질적 재화의 가격은 크게 낮아진다. 경제특구와 국제 감시를 통해 AI가 만든 부와 위험한 기술을 함께 관리한다. 이 구상에는 당연히 큰 가정이 들어간다. 고성장만으로 시민 배당이 자동으로 보장되는 것은 아니며, 권력을 가진 집단이 잉여를 독점하지 않는 정치적 합의가 필요하다. Plan A는 이 문제를 유권자와 정책결정자가 미래 예측 도구를 활용해 정책의 결과를 비교하는 “AI for Epistemics” 구상과 연결한다. 좋은 정책이 실제로 더 나은 결과를 낳는다는 점을 설득할 수 있어야 정치적 의지도 생긴다는 생각이다.\n8) 가장 큰 긴장은 안전과 번영 사이에 있다 Plan A의 흥미로운 점은 AI 발전의 위험만 계산하지 않는다는 것이다. AI를 늦추면 위험한 AI가 등장할 확률은 낮아질 수 있지만, 핵전쟁·팬데믹·기후 변화·질병·출산율 하락처럼 AI가 해결할 수 있는 다른 문제의 위험은 계속 커질 수 있다.\n따라서 “안전을 위해 최대한 늦춘다”는 원칙도 비용을 가진다. 반대로 “경쟁에서 이기기 위해 최대한 빠르게 간다”는 선택은 통제 상실과 권력 집중을 감수하게 한다. Plan A가 찾으려는 균형은 이 두 종류의 위험이 만나는 지점이다.\n저자가 말하는 낙관적 결론은 여기서 나온다. 충분히 강력한 AI가 정말 가까이 있다면, 안전을 위해 속도를 조절한 세계도 가속주의자가 상상하는 세계보다 더 빠르게 질병을 치료하고 경제를 성장시킬 수 있다. 즉, 안전과 번영은 반드시 반대편에 있지 않으며, 통제 가능한 협력 체계를 만들면 둘을 함께 얻을 여지가 있다는 주장이다.\n결론 및 시사점 한 줄 결론: Plan A는 AI 개발을 멈추자는 계획이 아니라, 미국과 중국의 검증 가능한 공동 통제로 경쟁의 속도를 조절하고 인간이 원하는 번영의 방향을 먼저 확보하자는 제안이다.\n이 시나리오의 가치는 예측이 정확한지에만 달려 있지 않다. 2029년에 실제 합의가 가능한지, 칩의 위치를 얼마나 투명하게 추적할 수 있는지, 2035년의 능력 상한을 누가 정하고 집행할지처럼 정책이 피하기 쉬운 질문을 드러내는 데 있다.\n동시에 Plan A는 매우 강한 가정을 요구한다. 미국과 중국이 서로의 이탈을 감시하는 협약에 합의해야 하고, 각국 정부가 기업과 군의 단기 경쟁 압력을 이겨야 하며, AI가 만든 막대한 부를 사회 전체에 배분해야 한다. 그러므로 이 글을 완성된 청사진으로 받아들이기보다, AI 정책이 어떤 미래를 목표로 해야 하는지와 그 목표까지 가는 길에 어떤 검증 장치가 필요한지를 묻는 기준점으로 읽는 편이 적절하다.\n","wordCount":1234,"tags":["AI","AI안전","AI정책","국제협력","장기미래"],"categories":["AI"],"frameworks":["Scenario Planning","International Coordination","Capability Governance"],"mental_models":["Race Dynamics","Mutual Assured Compute Destruction","Scenario Scrutiny"],"philosophy_type":"technology-policy","schema_type":"Article","actionable":true,"priority":"high","key_points":["Plan A는 AI 초지능의 등장을 예측하는 글이 아니라, 위험한 경쟁을 피하면서 번영으로 가는 최선의 경로를 구체적인 연도별 시나리오로 제시하는 정책 제안이다.","핵심은 미국과 중국이 2029년경 공동 규제 체계에 합의하고, 칩 공급과 데이터센터를 상호 감사 가능한 방식으로 관리하는 것이다.","2030~2035년에는 최고 수준의 인간 전문가에 가까운 AI까지 발전시키되 2035년에 멈추고, 정렬 연구와 통제 기술을 거친 뒤 2040년에 초지능 개발을 재개한다.","저자는 이 경로가 가난·질병·기후·우주 개발 같은 문제를 해결할 수 있는 거대한 잉여를 만들면서도, 권력 집중과 군비 경쟁을 억제하려면 투명성과 국제적 감시가 필수라고 본다."],"related":[]},{"title":"소프트웨어 품질은 문제의 부재다","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/notes-on-software-quality/","section":"software","date":"2026-07-09T16:12:28+09:00","lastmod":"2026-07-09T16:12:28+09:00","description":"Anthony Hobday가 말하는 소프트웨어 품질의 신호, 조직 규모의 한계, 품질을 지키는 구체적인 방법을 정리한다.","summary":"Anthony Hobday의 글 Notes on software quality는 소프트웨어 품질을 낭만적인 장인정신이 아니라, 제품과 조직이 실제로 감당해야 하는 운영 문제로 다룬다. 핵심은 간단하다. 좋은 소프트웨어는 더 많은 기능을 가진 소프트웨어가 아니라, 사용자가 마주치는 문제를 더 적게 남기는 소프트웨어다.\nQuality 핵심 정리 핵심 주장: 품질은 \u0026ldquo;문제가 거의 없는 상태\u0026quot;에 가깝고, 완벽에 가까워질수록 필요한 노력은 급격히 커진다. 여섯 신호: 신뢰성, 속도, 명확성, 유효성, 효율성, 아름다움이 소프트웨어 품질을 판단하는 주요 축이다. 조직의 역할: 품질은 실무자의 선의만으로 만들어지지 않는다. 리더십이 품질을 원하고 허용해야 한다. 규모의 비용: 제품과 팀이 커질수록 관계와 조율이 폭증해 세계적 수준의 인터페이스 품질은 점점 어려워진다. 실천 방식: 별도 품질 팀, 버그 우선 정책, 정기적인 품질 개선일처럼 시간과 권한을 따로 확보해야 한다. 원문: Notes on software quality\n","content":"Anthony Hobday의 글 Notes on software quality는 소프트웨어 품질을 낭만적인 장인정신이 아니라, 제품과 조직이 실제로 감당해야 하는 운영 문제로 다룬다. 핵심은 간단하다. 좋은 소프트웨어는 더 많은 기능을 가진 소프트웨어가 아니라, 사용자가 마주치는 문제를 더 적게 남기는 소프트웨어다.\nQuality 핵심 정리 핵심 주장: 품질은 \u0026ldquo;문제가 거의 없는 상태\u0026quot;에 가깝고, 완벽에 가까워질수록 필요한 노력은 급격히 커진다. 여섯 신호: 신뢰성, 속도, 명확성, 유효성, 효율성, 아름다움이 소프트웨어 품질을 판단하는 주요 축이다. 조직의 역할: 품질은 실무자의 선의만으로 만들어지지 않는다. 리더십이 품질을 원하고 허용해야 한다. 규모의 비용: 제품과 팀이 커질수록 관계와 조율이 폭증해 세계적 수준의 인터페이스 품질은 점점 어려워진다. 실천 방식: 별도 품질 팀, 버그 우선 정책, 정기적인 품질 개선일처럼 시간과 권한을 따로 확보해야 한다. 원문: Notes on software quality\n1. 품질은 문제의 부재에 가깝다 Hobday는 품질을 \u0026ldquo;무엇이 추가되어 있는가\u0026quot;보다 \u0026ldquo;무엇이 방해하지 않는가\u0026quot;로 본다. 사용자는 보통 품질을 직접 세지 않는다. 대신 앱이 멈추지 않는지, 입력에 빠르게 반응하는지, 다음 행동이 헷갈리지 않는지, 작은 실수가 데이터를 날리지 않는지를 체감한다.\n이 관점은 실무적으로 유용하다. 품질을 추상적인 취향 논쟁으로 두면 끝이 없다. 하지만 \u0026ldquo;사용자가 어떤 문제를 덜 겪는가\u0026quot;로 바꾸면 버그, 지연, 혼란, 불필요한 클릭, 시각적 어긋남, 데이터 손실 같은 구체적인 항목을 볼 수 있다.\n완벽은 불가능하지만 방향은 있다. 문제를 하나씩 없애는 일이다.\n2. 소프트웨어 품질을 보는 여섯 신호 원문은 소프트웨어 품질의 신호를 여섯 가지로 나눈다.\n신뢰성: 기대한 대로 항상 동작하는가. 버그, 장애, 오류가 적은가. 속도: 입력에 즉시 반응하는가. 오래 걸리는 작업도 가능한 한 빠른가. 명확성: 사용자가 화면, 상태, 다음 행동을 이해할 수 있는가. 유효성: 사용자가 해야 할 일을 실제로 끝낼 수 있는가. 효율성: 같은 일을 가능한 한 적은 노력으로 할 수 있는가. 아름다움: 보기 좋고, 정돈되어 있고, 손댄 흔적이 느껴지는가. 여기서 중요한 점은 아름다움이 마지막에 있지만 사소하지 않다는 것이다. 아름다움은 단순 장식이 아니다. 정렬, 간격, 움직임, 밀도, 대비 같은 디테일은 \u0026ldquo;이 제품을 누군가가 신경 써서 만들었다\u0026quot;는 신호가 된다. 그리고 그런 신호는 다른 품질에 대한 기대에도 영향을 준다.\n3. 품질은 개인기가 아니라 조직의 선택이다 품질은 능력과 의지의 결합이다. 좋은 디자이너와 엔지니어가 있어도 조직이 품질에 시간을 쓰지 못하게 하면 결과는 낮아진다. 반대로 조직이 품질을 원해도 그것을 구현할 사람이 없으면 구호로 끝난다.\n그래서 품질은 권한의 문제다. 제품을 빠르게 키우려는 압력, 분기 목표, 실험 수치, 광고 수익, 기능 요청은 모두 품질과 충돌할 수 있다. 이때 누가 \u0026ldquo;이번에는 더 작게 만들자\u0026rdquo;, \u0026ldquo;이 흐름은 다시 다듬자\u0026rdquo;, \u0026ldquo;버그를 먼저 고치자\u0026quot;고 말할 수 있는지가 품질을 결정한다.\n실무자 개인도 할 수 있는 선택은 있다. 같은 디자인 시스템 안에서도 더 명확한 문구, 더 자연스러운 상태 변화, 더 안전한 기본값, 더 적은 클릭을 선택할 수 있다. 다만 일정 규모 이상에서는 개인의 선의만으로 충분하지 않다.\n4. 규모가 커질수록 품질은 더 어려워진다 원문의 가장 날카로운 주장은 규모에 관한 것이다. 제품이 커지면 화면, 상태, 기능, 팀, 이해관계자가 늘어난다. 문제는 관계 수가 선형으로 늘지 않는다는 점이다. 요소가 많아질수록 서로 맞물리는 경우의 수는 더 빠르게 증가한다.\n작은 팀에서는 한 사람이 전체 인터페이스를 머릿속에 담고 판단할 수 있다. 큰 조직에서는 그렇게 하기 어렵다. 팀마다 목표가 다르고, 성과 지표가 다르고, 책임 영역이 나뉜다. 그러면 전체 제품의 일관성보다 각 팀의 납품이 앞서기 쉽다.\n프로세스를 더 엄격하게 만들 수도 있다. 하지만 프로세스가 늘어나면 어느 순간 디자인보다 프로세스 관리에 더 많은 시간이 든다. 이것이 품질의 규모 문제다. 나쁜 사람들이 있어서가 아니라, 관계와 조율 비용이 커져서 품질이 자연스럽게 어려워진다.\n5. 품질은 사업적으로도 의미가 있다 품질은 보기 좋은 취미가 아니다. 좋은 품질은 버그와 장애 대응을 줄이고, 제품 엔트로피를 늦추며, 사용자를 팬으로 만들고, 채용에도 도움이 된다. 품질이 회사 정체성의 일부가 되면 판매도 쉬워지고, 입소문도 강해진다.\n물론 모든 회사가 최고 품질을 목표로 해야 하는 것은 아니다. 어떤 제품은 낮은 가격, 영업력, 기능 수, 유통망으로 경쟁한다. 원문도 품질이 언제나 필수라고 말하지 않는다. 다만 품질을 선택하지 않는다면 그 선택의 비용을 알아야 한다.\n낮은 품질은 처음에는 싸 보인다. 그러나 시간이 지나면 버그, 사용성 문제, 고객지원, 브랜드 신뢰 하락, 내부 사기 저하로 비용이 돌아온다.\n6. 품질을 지키려면 시간을 따로 빼야 한다 원문은 여러 회사가 품질을 별도 노력으로 다루는 사례를 든다. GitLab의 UX Paper Cuts 팀, Linear의 버그 우선 정책과 Quality Wednesdays, Automattic의 Chief Quality Officer, Shopify의 수평적 품질 개선 팀, Zed의 Quality Week 같은 방식이다.\n공통점은 품질을 \u0026ldquo;남는 시간에 하는 일\u0026quot;로 두지 않는다는 것이다. 기능 개발이 항상 우선이면 품질은 항상 밀린다. 그래서 좋은 조직은 품질에 이름을 붙이고, 시간을 확보하고, 책임자를 둔다.\n작은 개선도 중요하다. 메뉴가 너무 쉽게 닫히지 않게 하기, 폼에 맞는 모바일 키보드를 띄우기, 리스트에서 항목이 추가되어도 스크롤 위치를 보존하기, 위험한 버튼을 실수로 누르지 않게 배치하기 같은 디테일은 각각 작지만 누적되면 제품의 감각을 바꾼다.\n결론 및 시사점 한 줄 결론: 소프트웨어 품질은 더 많은 것을 넣는 일이 아니라, 사용자가 만나는 문제를 꾸준히 없앨 수 있도록 조직이 시간과 권한을 배정하는 일이다.\nHobday의 글은 품질을 취향이나 미감의 문제가 아니라 조직 운영의 문제로 끌어내린다. 품질은 말로는 모두가 좋아하지만, 실제로는 일정, 성장, 기능, 지표와 계속 충돌한다. 그래서 품질을 원한다면 \u0026ldquo;중요하다\u0026quot;고 말하는 것만으로는 부족하다.\n팀이 작을 때는 집중과 취향으로 버틸 수 있다. 팀이 커지면 구조가 필요하다. 버그를 먼저 고치는 규칙, 정기적인 개선일, 작은 사용성 문제를 전담하는 팀, 리더십의 명시적 허가가 있어야 한다. 품질은 우연히 남는 것이 아니라, 계속 보호해야 남는다.\n관련 포스트 기술적 부채와 엔지니어링 생산성: Paul Dix의 견해 AI가 줄여야 할 것은 인원수가 아니라 팀 크기다 Addy Osmani의 Agentic Code Review — 에이전트 시대의 병목은 작성이 아니라 검증이다 ","wordCount":816,"tags":["소프트웨어품질","제품품질","인터페이스","조직설계","디자인"],"categories":["software"],"frameworks":["Product Quality","Interface Design","Organizational Design"],"mental_models":["Diminishing Returns","Coordination Cost","Entropy"],"philosophy_type":"engineering-culture","schema_type":"Article","actionable":true,"priority":"high","key_points":["품질은 대단한 장식이 아니라 사용자가 만나는 문제를 줄이는 상태에 가깝다.","소프트웨어 품질은 신뢰성, 속도, 명확성, 유효성, 효율성, 아름다움이라는 여섯 신호로 관찰할 수 있다.","조직과 제품이 커질수록 관계 수, 조율 비용, 상업적 압력이 늘어나 품질은 더 어려워진다.","품질은 개인의 취향만으로 유지되지 않고, 리더십의 허가와 조직적 시간 배분이 필요하다."],"related":["software/technical-debt-engineering-productivity","posts/ai-small-teams-not-headcount","posts/agentic-code-review-addy-osmani"]},{"title":"AI 시대에 살아남는 사람들 - David Brooks가 말하는 정신적 노력의 격차","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/mental-effort-ai-age-david-brooks/","section":"posts","date":"2026-07-09T14:17:43+09:00","lastmod":"2026-07-09T14:17:43+09:00","description":"David Brooks의 The People Who Will Thrive in the AI Age를 바탕으로, AI가 업무와 학습을 편하게 만드는 동시에 정신적 노력의 격차를 키울 수 있다는 관점을 정리한다.","summary":"David Brooks의 The Atlantic 글 The People Who Will Thrive in the AI Age는 AI 시대의 승자가 단순히 더 똑똑한 사람이 아니라, 정신적 노력을 어떻게 대하는가 로 갈릴 수 있다고 말한다. 원문은 2026년 6월 28일 게시됐고, 2026년 7월 6일에 수정됐다.\nAI 핵심 정리 일은 덜어지기보다 밀도가 높아진다: ActivTrak 분석에서 AI 도입자는 이메일·메시징·채팅 시간이 두 배 이상 늘었고, 비즈니스 소프트웨어 사용은 94% 증가했다. 핵심 변수는 의지다: Brooks는 지능이 풍부해질수록, 무엇을 원하고 어디까지 노력할지 결정하는 힘이 더 중요해진다고 본다. AI 사용자는 갈라진다: 낮은 노력으로 생산성만 얻는 사람, 위험을 알면서도 편의성에 빨려 들어가는 사람, AI를 자기 사고 확장의 도구로 쓰는 사람. 위험은 인지적 빈곤화다: AI가 너무 쉽게 답을 주면 기억, 비판적 사고, 동기, 호기심이 약해질 수 있다. 좋은 사용법은 마찰을 남기는 것: 답을 대신 받기보다 힌트, 반론, 배경 지식, 사상가 비교를 요청해 자기 생각을 더 단단하게 만들어야 한다. 1) AI는 일을 없애기보다 더 촘촘하게 만든다 Brooks가 출발점으로 삼는 관찰은 단순하다. AI가 일을 자동화하면 사람들은 남는 시간을 쉬는 데 쓰지 않는다. 오히려 이전에는 외주를 주거나 포기하던 일을 직접 맡고, 여러 봇을 동시에 감독하고, 저녁·주말·대기 시간까지 일을 끼워 넣는다.\n","content":"David Brooks의 The Atlantic 글 The People Who Will Thrive in the AI Age는 AI 시대의 승자가 단순히 더 똑똑한 사람이 아니라, 정신적 노력을 어떻게 대하는가 로 갈릴 수 있다고 말한다. 원문은 2026년 6월 28일 게시됐고, 2026년 7월 6일에 수정됐다.\nAI 핵심 정리 일은 덜어지기보다 밀도가 높아진다: ActivTrak 분석에서 AI 도입자는 이메일·메시징·채팅 시간이 두 배 이상 늘었고, 비즈니스 소프트웨어 사용은 94% 증가했다. 핵심 변수는 의지다: Brooks는 지능이 풍부해질수록, 무엇을 원하고 어디까지 노력할지 결정하는 힘이 더 중요해진다고 본다. AI 사용자는 갈라진다: 낮은 노력으로 생산성만 얻는 사람, 위험을 알면서도 편의성에 빨려 들어가는 사람, AI를 자기 사고 확장의 도구로 쓰는 사람. 위험은 인지적 빈곤화다: AI가 너무 쉽게 답을 주면 기억, 비판적 사고, 동기, 호기심이 약해질 수 있다. 좋은 사용법은 마찰을 남기는 것: 답을 대신 받기보다 힌트, 반론, 배경 지식, 사상가 비교를 요청해 자기 생각을 더 단단하게 만들어야 한다. 1) AI는 일을 없애기보다 더 촘촘하게 만든다 Brooks가 출발점으로 삼는 관찰은 단순하다. AI가 일을 자동화하면 사람들은 남는 시간을 쉬는 데 쓰지 않는다. 오히려 이전에는 외주를 주거나 포기하던 일을 직접 맡고, 여러 봇을 동시에 감독하고, 저녁·주말·대기 시간까지 일을 끼워 넣는다.\n원문에 따르면 ActivTrak은 1만 명이 넘는 노동자의 디지털 활동을 분석했고, AI 도입자의 이메일·메시징·채팅 시간은 두 배 이상 늘었다. 비즈니스 소프트웨어 사용도 94% 증가했다. 반대로 방해받지 않는 집중 시간은 9% 줄었다.\n즉 AI는 \u0026ldquo;15시간 노동주\u0026quot;를 자동으로 가져오지 않는다. 비행기와 자동차가 이동 시간을 줄였지만 사람들의 이동량 자체를 늘린 것처럼, AI도 업무 시간을 비우기보다 더 많은 과업을 가능하게 만든다.\n2) 지능보다 중요한 것은 정신적 노력과 의지 Brooks의 중심 문장은 이렇게 정리할 수 있다.\n지능이 풍부해질수록 의지가 귀해진다.\nAI는 계산, 검색, 초안 작성, 번역, 코드 생성 같은 지적 작업을 빠르게 만든다. 그러면 차이는 \u0026ldquo;누가 더 많은 정보를 아는가\u0026quot;에서 \u0026ldquo;누가 더 어려운 질문을 붙잡고 버티는가\u0026quot;로 이동한다.\n여기서 Brooks가 주목하는 개념은 심리학의 need for cognition이다. 쉽게 말해, 어려운 생각을 즐기거나 적어도 감당하려는 성향이다. 지능과 관련은 있지만 같은 것은 아니다. 아주 똑똑해도 깊이 생각하기를 싫어하는 사람이 있고, 반대로 고된 사고 과정을 기꺼이 견디는 사람이 있다.\n3) 세 가지 AI 사용자 Brooks는 AI 시대의 사람들을 세 그룹으로 나눈다.\n유형 AI를 쓰는 방식 얻는 것 잃을 수 있는 것 생산적인 승객 AI로 생각을 덜 한다 빠른 산출물 기억, 판단력, 사고 근육 마지못한 최적화자 위험을 알지만 편의성에 끌린다 효율, 업무 처리량 호기심, 동기, 자기 관점 정신의 마라토너 AI와 씨름하며 능력을 키운다 더 큰 주도성 쉬운 길을 포기하는 비용 첫 번째 그룹은 AI를 생산성 보조 도구로 쓰지만, 시간이 지날수록 자기 능력이 약해질 수 있다. 두 번째 그룹은 이 위험을 인식하지만 바쁜 일상 속에서 결국 AI 의존으로 흘러간다. 세 번째 그룹은 AI를 답변 기계가 아니라 사고 훈련 도구로 쓴다.\n핵심은 AI 사용 여부가 아니다. AI를 통해 생각을 생략하는가, 아니면 더 깊이 생각하는가 가 차이를 만든다.\n4) 너무 쉬운 답은 학습을 망칠 수 있다 Brooks가 반복해서 강조하는 위험은 \u0026ldquo;최적 난이도\u0026quot;에서 벗어나는 것이다. 사람은 너무 어렵지도, 너무 쉽지도 않은 과제에서 가장 잘 배운다. 그런데 AI가 모든 과제를 너무 쉽게 만들면, 사용자는 학습에 필요한 마찰을 잃는다.\n원문은 여러 연구를 이어 붙인다.\nMIT Media Lab 연구팀은 ChatGPT를 사용할 때 비슷한 과제를 AI 없이 수행할 때보다 뇌 연결성이 최대 55% 낮아졌다고 보고했다. Vivienne Ming은 AI 사용 중 인지적 노력의 신호로 보는 감마파 활동이 약 40% 줄었다고 했다. Michael Gerlich의 연구는 잦은 AI 도구 사용과 비판적 사고 능력 사이의 부정적 상관관계를 제시했다. Carnegie Mellon 연구진은 약 10분간 AI 도움을 받은 뒤 접근권을 잃은 사람들이 처음부터 AI 없이 푼 사람보다 더 나쁘게 수행하고 더 자주 포기했다고 결론 냈다. 내시경 전문의 연구에서는 AI 사용 전 전암성 병변 발견률이 28.4%였지만, AI 사용 후 AI를 제거했을 때 22.4%로 떨어졌다. 이 수치들을 하나로 묶으면 메시지는 분명하다. AI는 단기 생산성을 올릴 수 있지만, 잘못 쓰면 사람이 직접 판단하고 기억하고 버티는 능력을 약하게 만들 수 있다.\n5) 최적화 문화는 사람을 약하게 만들 수 있다 Brooks는 현대 기술 산업이 \u0026ldquo;마찰 제거\u0026quot;를 선으로 여겨 왔다고 본다. 검색, 추천, 자동완성, 챗봇은 모두 사용자가 더 적은 노력으로 결과에 도달하게 만든다.\n문제는 배움과 성장은 종종 마찰을 필요로 한다는 점이다. 어려운 책을 읽고, 초안을 고치고, 실패하고, 다시 생각하는 과정은 비효율적으로 보인다. 그러나 바로 그 과정이 사람을 더 깊고 단단하게 만든다.\n그래서 AI 시대의 위험은 단순한 게으름이 아니다. 더 정확히는 수련 없는 유창함이다. 사용자는 그럴듯한 결과물을 더 빨리 낼 수 있지만, 그 결과를 만든 사람이 되어 가는 과정은 건너뛸 수 있다.\n6) 정신의 마라토너는 AI를 다르게 쓴다 Brooks가 희망을 거는 사람들은 AI를 거부하는 사람들이 아니다. 이들은 AI를 적극적으로 쓰되, 자기 사고를 대체하게 두지 않는다.\n실천법은 꽤 구체적이다.\n답 대신 힌트를 요청한다. AI를 열기 전에 먼저 빈 종이에 자기 생각을 적는다. AI에게 초안을 쓰게 하기보다 자기 주장에 반론을 제기하게 한다. AI를 쓴 작업 뒤에는 AI 없이 하는 작업을 이어서 배치한다. 일반 챗봇보다 학습 여정을 설계하는 튜터형 도구를 선호한다. 반복적 업무와 창의적 업무를 구분한다. 문제 자체를 대신 생각하게 하기보다, 그 문제를 다뤄 온 사상가와 책을 찾게 한다. Brooks는 자신이 Claude를 쓸 때도 \u0026ldquo;나 대신 생각해 달라\u0026quot;고 하지 않고, 어떤 문제를 다룬 사상가들을 소개하고 비교하게 한다고 말한다. AI를 예언자처럼 대하지 않고, 뛰어난 사서처럼 대하는 것이다.\n7) 진짜 격차는 인지 양극화다 이 글의 가장 어두운 전망은 경제 격차보다 더 깊은 인지 양극화다. 어떤 사람들은 AI로 더 많이 생각하고, 어떤 사람들은 AI로 덜 생각한다. 전자는 더 생산적이고 더 행복해질 수 있지만, 후자는 정신적 하위 계층처럼 밀려날 수 있다.\nBrooks는 이 미래가 정해져 있지는 않다고 본다. 의지와 호기심은 타고난 면도 있지만, 환경에 크게 흔들린다. 학교와 조직이 사람에게 자율성, 유능감, 관계성을 제공하면 동기는 살아난다. 훌륭한 작품과 인물에 대한 감탄, 좋은 멘토와의 수련 관계도 사람의 욕망을 키운다.\n따라서 교육의 초점도 바뀌어야 한다. AI가 많은 지식을 대신 제공하는 시대에는 단순한 정보 전달이나 지능 선별보다, 어려운 문제를 원하고 견디는 힘을 기르는 일이 더 중요해진다.\n결론 및 시사점 한 줄 결론: AI 시대의 경쟁력은 답을 빨리 받는 능력이 아니라, 쉬운 답 앞에서도 생각을 포기하지 않는 능력이다.\n이 글은 AI 낙관론과 비관론 사이에서 꽤 실용적인 기준을 준다. AI를 쓰지 말자는 이야기가 아니다. 오히려 AI를 제대로 쓰려면, 어디에서 마찰을 없애고 어디에서 마찰을 남길지 의식적으로 정해야 한다는 이야기다.\n반복 메일, 형식 변환, 단순 정리처럼 숙련을 거의 만들지 않는 작업은 AI에게 맡겨도 된다. 그러나 자기 판단, 글쓰기, 설계, 학습, 비판적 사고처럼 사람의 내면 근육을 만드는 작업은 완전히 넘기면 안 된다.\n관련해 이 블로그의 Understanding Is the New Bottleneck 과 함께 읽으면 관점이 더 선명해진다. AI가 결과물 생산을 빠르게 만들수록, 사람이 무엇을 이해하고 무엇을 원해야 하는지가 더 큰 병목이 된다.\n","wordCount":996,"tags":["AI","David Brooks","The Atlantic","인지","학습","생산성"],"categories":["AI"],"frameworks":["Human-AI Collaboration","Cognitive Effort","Education Reform"],"mental_models":["Desirable Difficulty","Cognitive Offloading","Self-Determination Theory"],"philosophy_type":"human-development","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI는 일을 줄이기보다 더 많은 일을 끌어들이는 방향으로 작동할 수 있다. ActivTrak 분석에서 AI 도입자는 이메일·메시징·채팅 시간이 두 배 이상 늘었고, 비즈니스 소프트웨어 사용은 94% 증가했다.","David Brooks의 핵심 주장은 지능이 흔해질수록 의지와 정신적 노력이 더 귀해진다는 것이다.","AI 사용자는 낮은 노력으로 생산성을 얻는 사람, 위험을 알지만 최적화에 빨려 들어가는 사람, AI를 자기 역량 확장의 도구로 쓰는 사람으로 갈릴 수 있다.","문제는 AI가 답을 쉽게 주는 순간 사람이 최적 난이도 밖으로 밀려나며, 기억·비판적 사고·동기 같은 능력이 약해질 수 있다는 점이다.","좋은 사용법은 답을 맡기는 것이 아니라 힌트, 반론, 배경 지식, 사상가 간 비교처럼 생각을 더 깊게 만드는 방향으로 AI를 쓰는 것이다."],"related":["posts/understanding-is-the-new-bottleneck-geoffrey-litt","posts/ai-native-divide-daniel-miessler","posts/fowler-fragments-cognitive-debt-system-3"]},{"title":"그래프 기반 에이전트 메모리: 공유 기억은 어떻게 안전해지는가","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/graph-based-agent-memory/","section":"posts","date":"2026-07-09T13:51:57+09:00","lastmod":"2026-07-09T13:51:57+09:00","description":"System Design Newsletter의 Graph based Agent Memory 글을 바탕으로, 여러 AI 에이전트가 하나의 기억을 안전하게 읽고 쓰려면 왜 그래프, 스키마, 브랜치, 커밋이 필요한지 정리한다.","summary":"AI 에이전트가 하나일 때는 기억 문제가 단순해 보입니다. 대화 내용이나 작업 노트를 어딘가에 저장하면 됩니다. 하지만 터미널의 코딩 에이전트, 브라우저 챗봇, 백그라운드 작업 에이전트가 같은 프로젝트를 동시에 다루기 시작하면 문제가 달라집니다. 각자 따로 기억하면 맥락이 끊기고, 하나의 저장소에 모두 쓰게 하면 잘못된 정보가 곧바로 모두의 입력이 됩니다.\n원문: https://newsletter.systemdesign.one/p/graph-based-agent-memory\n핵심 핵심 정리 문제: 공유 폴더는 텍스트 더미가 되고, 벡터 데이터베이스는 관계를 모르며, 둘 다 여러 에이전트의 동시 쓰기와 잘못된 쓰기를 안전하게 다루기 어렵다. 해법 방향: 기억을 문서 묶음이 아니라 타입이 있는 그래프로 만들면, 에이전트가 고객 -\u0026gt; 티켓 -\u0026gt; 담당자 -\u0026gt; 커밋처럼 연결된 사실을 따라갈 수 있다. 쓰기 안전성: Omnigraph는 S3 같은 객체 저장소 위에서 불변 버전과 manifest를 사용해 부분 반영 없이 한 번에 공개되는 커밋을 만든다. 운영 규칙: 에이전트는 공유 진실인 main에 직접 쓰지 않고 브랜치에 변경을 만든 뒤, 승인과 병합을 거쳐야 한다. 검색 방식: 그래프 탐색, BM25 기반 키워드 검색, 벡터 검색을 한 데이터 위에서 함께 사용해 구조와 의미를 동시에 찾는다. 기존 방식이 깨지는 이유 가장 쉬운 방법은 공유 폴더입니다. Notion, Google Drive, Confluence, 위키에 모든 에이전트가 문서를 남기게 하는 방식입니다. 사람에게는 익숙하지만 에이전트에게는 불리합니다. 파일은 많아지는데, 그 안의 개념이 무엇이고 서로 어떻게 연결되는지 알기 어렵기 때문입니다.\n","content":"AI 에이전트가 하나일 때는 기억 문제가 단순해 보입니다. 대화 내용이나 작업 노트를 어딘가에 저장하면 됩니다. 하지만 터미널의 코딩 에이전트, 브라우저 챗봇, 백그라운드 작업 에이전트가 같은 프로젝트를 동시에 다루기 시작하면 문제가 달라집니다. 각자 따로 기억하면 맥락이 끊기고, 하나의 저장소에 모두 쓰게 하면 잘못된 정보가 곧바로 모두의 입력이 됩니다.\n원문: https://newsletter.systemdesign.one/p/graph-based-agent-memory\n핵심 핵심 정리 문제: 공유 폴더는 텍스트 더미가 되고, 벡터 데이터베이스는 관계를 모르며, 둘 다 여러 에이전트의 동시 쓰기와 잘못된 쓰기를 안전하게 다루기 어렵다. 해법 방향: 기억을 문서 묶음이 아니라 타입이 있는 그래프로 만들면, 에이전트가 고객 -\u0026gt; 티켓 -\u0026gt; 담당자 -\u0026gt; 커밋처럼 연결된 사실을 따라갈 수 있다. 쓰기 안전성: Omnigraph는 S3 같은 객체 저장소 위에서 불변 버전과 manifest를 사용해 부분 반영 없이 한 번에 공개되는 커밋을 만든다. 운영 규칙: 에이전트는 공유 진실인 main에 직접 쓰지 않고 브랜치에 변경을 만든 뒤, 승인과 병합을 거쳐야 한다. 검색 방식: 그래프 탐색, BM25 기반 키워드 검색, 벡터 검색을 한 데이터 위에서 함께 사용해 구조와 의미를 동시에 찾는다. 기존 방식이 깨지는 이유 가장 쉬운 방법은 공유 폴더입니다. Notion, Google Drive, Confluence, 위키에 모든 에이전트가 문서를 남기게 하는 방식입니다. 사람에게는 익숙하지만 에이전트에게는 불리합니다. 파일은 많아지는데, 그 안의 개념이 무엇이고 서로 어떻게 연결되는지 알기 어렵기 때문입니다.\n예를 들어 \u0026ldquo;이번 주 배포 중 어떤 서비스가 누구에 의해 변경됐는가?\u0026ldquo;라는 질문은 한 문서 안에 답이 있으면 쉽습니다. 하지만 답이 배포 기록, 담당자 문서, 장애 기록, 커밋 로그에 흩어져 있으면 에이전트는 많은 문서를 읽고 추측해야 합니다. 폴더는 텍스트를 저장할 뿐, 지식을 저장하지 않습니다.\n벡터 데이터베이스도 완전한 답은 아닙니다. 의미가 비슷한 문단을 찾는 데는 강하지만, 고객과 티켓, 티켓과 담당자, 담당자와 커밋 사이의 명시적 관계를 직접 표현하지는 못합니다. \u0026ldquo;비슷한 조각\u0026quot;은 찾을 수 있지만, \u0026ldquo;이 사실에서 저 사실까지 어떤 경로로 연결되는가\u0026quot;는 별도로 해석해야 합니다.\n더 큰 문제는 쓰기입니다. 에이전트가 하나가 아니라 여럿이면 동시에 같은 기억을 고칩니다. 공유 폴더에서는 마지막 저장이 앞선 저장을 덮을 수 있습니다. 벡터 데이터베이스에서는 잘못된 정보가 들어가면 곧바로 다른 에이전트의 검색 결과가 됩니다. 즉, 한 에이전트의 실수가 공유 맥락이 됩니다.\n그래프 메모리의 기본 아이디어 그래프 메모리는 사실을 점으로, 관계를 선으로 다룹니다. 고객은 하나의 노드, 티켓도 하나의 노드, 담당자도 하나의 노드입니다. 그리고 고객은 티켓을 만들었고, 티켓은 담당자에게 배정됐고, 특정 커밋이 그 티켓과 연결될 수 있습니다.\n이 구조에서는 질문이 문서 검색으로만 끝나지 않습니다. 에이전트는 관계를 따라 이동합니다.\nCustomer -\u0026gt; Ticket -\u0026gt; Engineer -\u0026gt; Commit 이런 경로가 이미 그래프 안에 있으므로, 에이전트는 모든 문서를 뒤지는 대신 연결된 사실을 따라가며 필요한 맥락을 만들 수 있습니다.\n다만 그래프만으로도 부족합니다. 여러 에이전트가 같은 사건을 어떤 에이전트는 deploy, 다른 에이전트는 deployment, 또 다른 에이전트는 release로 기록하면, 그래프는 세 단어를 서로 다른 개념으로 저장할 수 있습니다. 사람에게는 비슷한 말이지만 시스템에게는 서로 다른 섬이 됩니다.\n그래서 스키마가 필요합니다. 스키마는 어떤 노드 타입이 있고, 어떤 관계가 허용되며, 각 노드를 무엇으로 식별할지 정합니다. 에이전트가 같은 스키마를 읽고 쓰면, 서로 다른 말로 같은 개념을 흩뜨릴 가능성이 줄어듭니다. 스키마는 그래프의 문법입니다.\n객체 저장소 위에서 원자적으로 쓰는 법 Omnigraph는 그래프 상태를 S3 같은 객체 저장소에 둡니다. 객체 저장소는 싸고 오래 보관하기 좋고 여러 에이전트가 함께 접근하기 쉽습니다. 하지만 데이터베이스처럼 여러 파일 변경을 하나의 트랜잭션으로 묶어 주지는 않습니다.\n그래프 업데이트는 보통 여러 곳을 동시에 바꿉니다. 예를 들어 Alice가 checkout 서비스에 배포 d-913을 만들었다면, 배포 노드, 사람 노드, 배포와 사람을 잇는 엣지가 함께 바뀔 수 있습니다. 중간에 실패하면 배포는 있는데 누가 했는지 연결이 없는 이상한 상태가 됩니다.\nOmnigraph는 이를 피하려고 데이터를 바로 덮어쓰지 않습니다. 노드 타입과 엣지 타입별로 저장소를 나누고, 각 저장소는 새 버전을 만듭니다. 기존 버전은 그대로 두고, 새 버전은 아직 보이지 않게 저장합니다.\n마지막에 manifest가 어느 버전이 현재 살아 있는지를 가리킵니다. 새 배포 버전, 새 사람 버전, 새 엣지 버전을 모두 만든 뒤 manifest 포인터만 한 번에 바꾸면, 에이전트 입장에서는 예전 그래프 전체를 보거나 새 그래프 전체를 봅니다. 중간 상태는 보지 않습니다.\n동시에 다른 에이전트가 먼저 바꿨는지도 확인합니다. Omnigraph는 compare-and-swap 방식으로 \u0026ldquo;내가 읽은 버전이 아직 현재 버전인가?\u0026ldquo;를 검사합니다. 아니면 커밋을 거절하고 최신 상태에서 다시 시도합니다. 이렇게 하면 보지 못한 변경을 덮어쓰는 사고를 막을 수 있습니다.\n에이전트는 바로 main에 쓰지 않는다 원자적 쓰기는 \u0026ldquo;부분 반영\u0026quot;을 막지만, \u0026ldquo;틀린 내용\u0026quot;을 막지는 못합니다. 에이전트가 잘못 추론한 정보를 완전한 커밋으로 올리면, 그 정보는 여전히 공유 기억이 됩니다.\n그래서 Omnigraph는 Git과 비슷한 흐름을 씁니다. 에이전트는 공유 진실인 main에 직접 쓰지 않습니다. 각자 브랜치를 만들고, 그 안에서 변경을 제안합니다. 브랜치는 제안일 뿐이고, 승인되어 병합되기 전까지는 공유 기억이 아닙니다.\n충돌도 명시적으로 다룹니다. 두 에이전트가 서로 다른 부분을 바꾸면 자동으로 합칠 수 있습니다. 하지만 같은 배포의 상태를 한쪽은 rolled-back, 다른 쪽은 succeeded로 바꾸면 시스템이 임의로 고르지 않습니다. 어떤 노드의 어떤 필드에서 어떤 값이 충돌했는지 드러내고, 사람이나 정책이 결정하게 합니다.\n권한도 HTTP 서버 바깥에만 두지 않습니다. CLI나 SDK로 접근해도 같은 검사를 받도록 엔진 내부에서 정책을 적용합니다. 원문은 Omnigraph가 Cedar 정책 언어를 사용해 누가 읽고, 브랜치를 만들고, 수정하고, main에 병합할 수 있는지 통제한다고 설명합니다.\n검색은 세 가지를 함께 쓴다 에이전트가 좋은 답을 내려면 기억을 안전하게 저장하는 것만으로는 부족합니다. 필요한 맥락을 잘 찾아야 합니다. 원문은 검색을 세 종류로 나눕니다.\n첫째, 관계 검색입니다. LoginService에서 출발해 어떤 서비스가 의존하는지, 어떤 장애와 연결되는지, 누가 소유자인지 따라갑니다.\n둘째, 정확한 키워드 검색입니다. 에러 문자열, 서비스 이름, 티켓 ID처럼 정확한 단어를 아는 경우에는 전통적인 전체 텍스트 검색이 필요합니다.\n셋째, 의미 검색입니다. 사용자가 \u0026ldquo;로그인이 안 된다\u0026quot;고 말했지만 관련 장애 제목은 \u0026ldquo;authentication failure\u0026quot;일 수 있습니다. 단어는 다르지만 뜻이 같은 경우에는 벡터 검색이 유용합니다.\n문제는 이 세 가지를 별도 시스템으로 나누면 동기화 부담이 커진다는 점입니다. 그래프 데이터베이스, 검색 인덱스, 벡터 데이터베이스가 각자 사본을 들고 있으면 어느 하나가 뒤처질 수 있습니다. Omnigraph는 하나의 그래프 데이터를 기준으로 그래프 인덱스, 전체 텍스트 인덱스, 벡터 인덱스를 만든 뒤 결과 순위를 합칩니다.\n언제 쓰고, 언제 쓰지 말아야 하나 그래프 메모리는 여러 에이전트가 같은 지식을 오래 읽고 쓰는 문제에 맞습니다. 회사 지식 그래프, 장기 에이전트 메모리, 코드베이스 지식 그래프, 개인 지식 그래프처럼 시간이 지나며 관계가 쌓이고 여러 작업자가 함께 업데이트하는 경우가 대표적입니다.\n반대로 모든 기억 문제에 필요한 도구는 아닙니다. 객체 저장소 기반 쓰기는 보통 수십에서 수백 밀리초가 걸릴 수 있습니다. 에이전트가 몇 초씩 추론하는 환경에서는 괜찮은 비용이지만, 결제 처리, 클릭 카운터, 실시간 세션 상태처럼 초당 수천 번의 낮은 지연 쓰기가 필요한 곳에는 맞지 않습니다.\n필요한 것이 의미 검색뿐이라면 벡터 데이터베이스가 더 단순합니다. 단일 애플리케이션에서 그래프 탐색만 필요하고 쓰기 주체가 제한적이라면 Neo4j 같은 전통적 그래프 데이터베이스가 더 적합할 수 있습니다. 고속 트랜잭션이 핵심이면 일반 트랜잭션 데이터베이스가 맞습니다.\n결론 및 시사점 한 줄 결론: 여러 AI 에이전트가 같은 기억을 공유하려면 저장소보다 먼저 관계, 스키마, 승인, 되돌리기 가능한 변경 이력이 필요합니다.\n이 글의 핵심은 \u0026ldquo;에이전트 메모리 = 더 큰 벡터 데이터베이스\u0026quot;가 아니라는 점입니다. 여러 에이전트가 동시에 읽고 쓰는 순간, 메모리는 검색 문제가 아니라 공유 상태 운영 문제가 됩니다.\n그래프는 관계를 표현하고, 스키마는 언어를 맞추며, manifest 기반 커밋은 부분 반영을 막고, 브랜치와 병합은 틀린 변경이 곧바로 공유 진실이 되는 일을 늦춥니다. 결국 좋은 에이전트 메모리는 지식을 많이 저장하는 장치가 아니라, 무엇이 공유 지식이 될 자격이 있는지 관리하는 시스템에 가깝습니다.\n","wordCount":1072,"tags":["AI","에이전트","Agent-Memory","Graph","Omnigraph","RAG"],"categories":["AI"],"frameworks":["Graph Memory","Typed Graph","Git-style Data Workflow"],"mental_models":["Shared State","Atomic Commit","Schema as Contract","Review before Merge"],"philosophy_type":"engineering-architecture","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["공유 폴더는 구조가 없고, 벡터 데이터베이스는 관계와 타입이 약해서 여러 에이전트가 함께 쓰는 장기 기억으로는 부족하다.","그래프 메모리는 고객, 티켓, 담당자, 커밋 같은 사실을 노드와 엣지로 연결해 한 사실에서 관련 사실로 이동하게 만든다.","Omnigraph는 객체 저장소 위에서 불변 스토어와 manifest 포인터를 사용해 여러 파일 변경을 하나의 원자적 커밋처럼 공개한다.","에이전트는 main에 바로 쓰지 않고 브랜치에 제안한 뒤, 정책이나 사람이 승인한 변경만 공유 기억에 병합한다.","그래프 탐색, 키워드 검색, 벡터 검색을 한 데이터 위에서 함께 써서 구조, 정확한 문자열, 의미 기반 검색을 동시에 다룬다."],"related":["posts/faulty-memory-summary","posts/components-of-a-coding-agent","posts/ai-agents-future-context-gap"]},{"title":"Apps After Agents: 에이전트 이후에도 앱이 남는 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/apps-after-agents/","section":"posts","date":"2026-07-08T23:50:25+09:00","lastmod":"2026-07-08T23:50:25+09:00","description":"Kyle Mathews의 Apps After Agents를 바탕으로, 에이전트가 지식 노동을 자동화해도 앱이 사라지지 않는 이유를 기반층, 카메라/엔진 모드, 자동화 실패 패턴 관점에서 다룬다.","summary":"Kyle Mathews의 Apps After Agents는 \u0026ldquo;에이전트가 모든 앱을 대체할 것인가?\u0026ldquo;라는 질문에 반대편에서 답한다. 결론은 단순하다. 에이전트는 많은 일을 자동화하겠지만, 앱은 사라지지 않는다. 다만 앱의 의미가 바뀐다.\nTL;DR 핵심 정리 모델보다 기반층: 모델 성능은 빠르게 평준화된다. 오래 남는 자산은 테스트, 문서, 예외 기록, 의사결정 이력처럼 조직의 판단이 쌓이는 기반층이다. 엔진 영역과 카메라 영역: 에이전트는 검증이 싸고 반복 가능한 일에 강하다. 반대로 무엇을 봐야 하는지, 전제가 틀렸는지, 예외가 생겼는지 알아차리는 일은 계속 탐색이 필요하다. 자동화는 책임을 없애지 않는다: 자동화가 좋아질수록 사람은 감시 루프에서 빠지기 쉽다. 그래서 권한 제한, 체크리스트, 테스트, 승인 흐름 같은 안전장치가 더 중요해진다. 앱은 프롬프트보다 낫다: 사용자는 매번 질문을 잘 쓰고 싶어 하지 않는다. 좋은 앱은 사용자의 의도를 미리 구조화하고, 필요한 선택지를 화면에 드러낸다. 핵심 주장: 소프트웨어는 죽지 않고 층위가 바뀐다 원문은 \u0026ldquo;소프트웨어가 죽었다\u0026quot;는 주장에 선을 긋는다. 이유는 두 가지다.\n","content":"Kyle Mathews의 Apps After Agents는 \u0026ldquo;에이전트가 모든 앱을 대체할 것인가?\u0026ldquo;라는 질문에 반대편에서 답한다. 결론은 단순하다. 에이전트는 많은 일을 자동화하겠지만, 앱은 사라지지 않는다. 다만 앱의 의미가 바뀐다.\nTL;DR 핵심 정리 모델보다 기반층: 모델 성능은 빠르게 평준화된다. 오래 남는 자산은 테스트, 문서, 예외 기록, 의사결정 이력처럼 조직의 판단이 쌓이는 기반층이다. 엔진 영역과 카메라 영역: 에이전트는 검증이 싸고 반복 가능한 일에 강하다. 반대로 무엇을 봐야 하는지, 전제가 틀렸는지, 예외가 생겼는지 알아차리는 일은 계속 탐색이 필요하다. 자동화는 책임을 없애지 않는다: 자동화가 좋아질수록 사람은 감시 루프에서 빠지기 쉽다. 그래서 권한 제한, 체크리스트, 테스트, 승인 흐름 같은 안전장치가 더 중요해진다. 앱은 프롬프트보다 낫다: 사용자는 매번 질문을 잘 쓰고 싶어 하지 않는다. 좋은 앱은 사용자의 의도를 미리 구조화하고, 필요한 선택지를 화면에 드러낸다. 핵심 주장: 소프트웨어는 죽지 않고 층위가 바뀐다 원문은 \u0026ldquo;소프트웨어가 죽었다\u0026quot;는 주장에 선을 긋는다. 이유는 두 가지다.\n첫째, 에이전트는 모든 일을 자동화하지 못한다. 반복적이고 검증 가능한 작업은 빠르게 흡수되지만, 애초에 어떤 문제인지 정의하고, 어디에 위험이 숨어 있는지 찾고, 틀린 프레임을 고치는 일은 계속 남는다.\n둘째, 에이전트가 어떤 일을 처리할 수 있더라도 사용자는 늘 채팅창으로 일하고 싶어 하지 않는다. 프롬프트는 CLI처럼 강력하지만, 사용자에게 시스템의 구조를 머릿속에 들고 있으라고 요구한다. 반면 좋은 앱은 가능한 행동, 상태, 제약, 다음 선택지를 화면에 배치해 인지 부담을 줄인다.\n그래서 미래의 앱은 \u0026ldquo;모델을 감싼 UI\u0026quot;가 아니다. 앱은 조직과 사용자가 축적한 판단에 접근하는 인터페이스가 된다.\n기반층: 모델이 아니라 판단이 쌓이는 곳 원문에서 중요한 개념은 substrate다. 여기서는 기반층이라고 부를 수 있다.\n기반층은 단순한 데이터베이스가 아니다. CRM은 고객 정보를 담고, ERP는 운영 정보를 담고, Git은 코드를 담는다. 기반층은 여기에 더해 다음 같은 것을 담는다.\n왜 이 결정을 했는가 예전에 시도했지만 실패한 방법은 무엇인가 어떤 예외 케이스를 조심해야 하는가 이 조직만의 업무 방식과 품질 기준은 무엇인가 자동화가 어디까지 해도 되고, 어디서 멈춰야 하는가 모델은 갈아 끼울 수 있다. 하지만 이런 판단의 흔적이 사라지면 조직은 매번 처음부터 다시 배운다. 반대로 기반층이 잘 쌓이면 에이전트는 새 모델로 바뀌어도 \u0026ldquo;회사 베테랑\u0026quot;처럼 행동할 수 있다.\n이 관점에서는 경쟁력이 모델 선택에서 나오지 않는다. 우리만의 판단이 어디에, 얼마나 명시적으로, 얼마나 재사용 가능하게 쌓이는가가 더 중요하다.\n카메라 모드와 엔진 모드 원문은 에이전트 작업을 두 모드로 나눈다.\n엔진 모드는 실행이다. 구조가 이미 정해져 있고, 검증 방법도 있으며, 실패해도 되돌릴 수 있는 작업에 맞다. 예를 들면 기존 패턴에 맞춰 기능을 추가하거나, 타입 오류를 고치거나, 반복 변환을 수행하는 일이다.\n카메라 모드는 탐색이다. 파일을 읽고, 맥락을 모으고, 이상한 디테일을 발견하고, 질문을 다시 세우는 일이다. 이 모드는 느려 보이지만 현실을 더 많이 본다.\n문제는 엔진 모드가 카메라 모드가 필요한 영역으로 밀고 들어갈 때 생긴다. 에이전트가 코드베이스의 숨은 불변식을 모른 채 대규모 리팩터링을 끝내고, 테스트는 통과했지만 몇 주 뒤 운영에서 장애가 나는 식이다.\n따라서 에이전트 활용의 고급 기술은 \u0026ldquo;더 많이 자동화하기\u0026quot;만이 아니다. 더 중요한 기술은 지금 이 일이 엔진 영역인지, 카메라 영역인지 구분하는 것이다.\n자동화의 오래된 실패 패턴 에이전트는 지식 노동을 위한 자동화다. 그러면 과거 자동화가 겪은 문제도 다시 나타난다.\n자동화는 반복 업무를 흡수한다. 농업 기계는 농업 인력을 줄였고, ATM은 은행원의 반복 업무를 줄였다. 하지만 남은 일은 사라진 일과 같지 않았다. 농업에는 작물 계획, 병충해 판단, 장비 의사결정이 남았고, 은행에는 관계 관리, 사기 탐지, 문제 해결이 더 중요해졌다.\n지식 노동도 비슷하다. 에이전트가 반복 업무를 처리할수록 인간에게 남는 일은 더 모호하고, 더 예외적이고, 더 판단 중심적인 일이 된다.\n여기서 Bainbridge paradox가 중요해진다. 자동화가 좋아질수록 사람은 감시에서 빠진다. 그런데 자동화가 자신의 한계를 벗어났을 때는 바로 그 사람의 판단이 필요하다. 즉, 자동화는 사람의 개입을 줄이지만, 실패 순간에는 더 높은 품질의 개입을 요구한다.\n그래서 기반층은 단지 지식 저장소가 아니라 안전장치다. 코드에서는 테스트, 타입, rate limit, 권한 제한이 된다. 조직에서는 승인 흐름, 사고 기록, 체크리스트, 예외 처리 규칙이 된다.\n왜 앱은 계속 필요한가 사용자는 \u0026ldquo;기계에게 일을 시키는 법\u0026quot;을 배우고 싶은 것이 아니다. 일을 끝내고 싶을 뿐이다.\n채팅 기반 에이전트는 사용자가 먼저 질문을 떠올리고, 맥락을 설명하고, 원하는 결과를 언어로 구성해야 한다. 이는 강력하지만 피곤하다. 좋은 앱은 반대로 사용자가 해야 할 일을 줄인다. 현재 상태를 보여주고, 가능한 조작을 제한하고, 필요한 정보를 적절한 위치에 놓고, 다음 행동을 예측한다.\n그래서 에이전트 이후의 앱은 사라지는 것이 아니라 더 깊어진다.\n화면 위에는 여전히 버튼, 목록, 상태, 승인, 편집 도구가 있다. 화면 아래에는 에이전트가 자료를 찾고, 초안을 만들고, 예외를 감지하고, 반복 업무를 처리한다. 그 사이에는 기반층이 있어 에이전트가 조직의 판단을 읽고 다시 기록한다. 앱은 에이전트를 숨기는 포장지가 아니다. 앱은 사용자가 기반층과 상호작용하는 안정적인 표면이다.\nBuild vs Buy 기준의 변화 예전의 build vs buy 판단은 주로 비용과 시간의 문제였다. 개발이 비싸고 느리면 SaaS를 샀다. 특별한 요구가 있거나 시장에 없는 기능이면 직접 만들었다.\nAI가 코딩 비용을 낮추면 질문이 바뀐다. 이제 핵심은 \u0026ldquo;만드는 데 얼마나 드는가?\u0026ldquo;보다 **\u0026ldquo;어떤 판단을 우리 안에 쌓아야 하는가?\u0026rdquo;**다.\n모두가 비슷하게 하는 일은 SaaS가 맞다. 이메일, 캘린더, 기본 생산성 도구처럼 범용 베스트 프랙티스가 중요한 영역에서는 외부 제품의 집계 학습을 쓰는 편이 낫다.\n반대로 경쟁 우위와 연결된 프로세스는 내부에 남겨야 한다. 고객을 이해하는 방식, 운영의 예외 처리, 품질 기준, 의사결정 흔적이 차별화라면 그 기반층은 남의 SaaS 안에서만 자라게 두면 안 된다.\n질문은 \u0026ldquo;SaaS가 내 데이터를 가져가는가?\u0026ldquo;에서 멈추면 부족하다. 더 날카로운 질문은 이것이다.\n내게 중요한 결정들이 어디에서 복리로 쌓이고 있는가?\n실무적으로 가져갈 것 이 글을 에이전트 제품이나 내부 도구 설계에 적용하면 몇 가지 기준이 나온다.\n에이전트에게 맡길 일과 사람이 계속 봐야 할 일을 구분한다. 자동화 결과만 저장하지 말고, 판단의 이유와 예외를 같이 남긴다. 프롬프트 입력창을 기본 UI로 두지 말고, 사용자의 반복 의사결정을 화면 구조로 흡수한다. 모델 교체 후에도 유지되어야 하는 지식을 코드, 테스트, 문서, 워크플로에 남긴다. 자동화가 실패할 때 피해를 줄이는 권한 경계와 승인 흐름을 둔다. 에이전트 시대의 앱 설계는 \u0026ldquo;얼마나 똑똑한 모델을 붙였는가\u0026quot;가 아니라 \u0026ldquo;얼마나 좋은 판단 축적 시스템을 만들었는가\u0026quot;로 평가될 가능성이 크다.\n결론 및 시사점 한 줄 결론: 에이전트 이후에도 앱은 남는다. 다만 앱은 기능 묶음이 아니라, 조직의 축적된 판단과 에이전트 실행을 연결하는 인터페이스가 된다.\nApps After Agents가 던지는 메시지는 낙관과 회의 사이에 있다. 에이전트는 실제로 많은 일을 자동화한다. 하지만 자동화가 커질수록 경계 판단, 예외 기록, 사용자 경험, 안전장치의 중요성도 같이 커진다.\n결국 소프트웨어의 방어력은 모델 호출 그 자체가 아니라, 그 호출이 기대고 있는 기반층에서 나온다. 어떤 조직은 모델을 쓰고도 매번 새로 시작할 것이고, 어떤 조직은 모델이 바뀌어도 판단이 계속 쌓이는 시스템을 갖게 될 것이다. 그 차이가 에이전트 이후의 앱 경쟁력을 만든다.\n","wordCount":960,"tags":["AI","에이전트","앱","자동화","소프트웨어","Substrate"],"categories":["AI"],"frameworks":["Camera/Engine Mode","Automation Boundary","Substrate"],"mental_models":["Bainbridge Paradox","Frame Problem","Build vs Buy"],"philosophy_type":"engineering-strategy","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["모델은 점점 교체 가능한 입력이 되고, 조직이 축적한 판단과 예외 기록이 진짜 방어력이 된다.","에이전트는 반복 가능한 엔진 영역을 잘 처리하지만, 무엇을 볼지 정하는 카메라 영역은 계속 인간의 판단을 요구한다.","앱은 프롬프트 입력창으로 대체되는 것이 아니라, 축적된 판단에 접근하는 설계된 인터페이스로 남는다.","SaaS와 내부 구축의 기준은 비용이 아니라, 어떤 결정이 우리 조직 안에서 복리로 쌓여야 하는가로 바뀐다."],"related":["posts/loop-engineering.md","posts/ai-agents-future-context-gap.md","posts/todays-harness-is-tomorrows-prompt.md"]},{"title":"GenUI 디자인 — AI가 UI를 만들 때 디자이너가 설계해야 하는 것","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/designing-for-genui-ai-builds-ui/","section":"posts","date":"2026-07-08T23:50:06+09:00","lastmod":"2026-07-08T23:50:06+09:00","description":"gskinner의 GenUI 글을 바탕으로, AI가 런타임에 UI를 조립하는 시대에 디자이너의 일이 화면 설계에서 규칙, 컴포넌트, 가드레일 설계로 어떻게 이동하는지 정리했다.","summary":"gskinner의 2026년 6월 16일 글 **\u0026ldquo;Designing for GenUI: What Changes When AI Builds the UI?\u0026rdquo;**는 AI가 화면을 런타임에 조립하는 시대에 제품 디자인이 어떻게 달라지는지 다룹니다. 핵심은 단순합니다. 디자이너가 더 이상 모든 화면을 직접 완성하는 사람이 아니라, AI가 화면을 만들 때 따라야 할 재료와 규칙을 설계하는 사람이 된다는 것입니다.\n원문: Designing for GenUI: What Changes When AI Builds the UI?\nTL;DR 핵심 정리 화면에서 규칙으로 이동한다: GenUI에서는 모든 화면을 미리 설계하는 대신, AI가 어떤 상황에서 어떤 컴포넌트를 써야 하는지 정의한다. Hatcha가 사례다: gskinner는 Google 발표를 위해 Flutter 기반 이벤트 플래닝 앱 Hatcha를 만들며, 초대장과 대시보드가 맥락에 맞게 조립되는 경험을 실험했다. 디자인 시스템은 재고가 된다: 컴포넌트는 예쁜 부품이 아니라, AI가 목적에 맞게 꺼내 쓰는 선택 가능한 도구 목록이다. 고정 UI와 GenUI를 나눠야 한다: 내비게이션, 규제 절차, 감사 가능한 흐름은 고정 UI가 낫고, 개인화와 가변성이 큰 영역은 GenUI가 빛난다. 디자이너의 사용자 이해가 더 중요해진다: 컴포넌트 조건, 프롬프트, 가드레일은 결국 사용자를 얼마나 잘 이해했는지의 표현이다. GenUI가 바꾸는 기본 전제 전통적인 UI는 미리 구성됩니다. 디자이너가 화면을 그리고, 사용자는 그 화면 사이를 이동합니다. 플로우차트, 와이어프레임, 프로토타입은 모두 \u0026ldquo;어떤 화면이 어떤 순서로 나오는가\u0026quot;를 정하는 데 초점이 있습니다.\n","content":"gskinner의 2026년 6월 16일 글 **\u0026ldquo;Designing for GenUI: What Changes When AI Builds the UI?\u0026rdquo;**는 AI가 화면을 런타임에 조립하는 시대에 제품 디자인이 어떻게 달라지는지 다룹니다. 핵심은 단순합니다. 디자이너가 더 이상 모든 화면을 직접 완성하는 사람이 아니라, AI가 화면을 만들 때 따라야 할 재료와 규칙을 설계하는 사람이 된다는 것입니다.\n원문: Designing for GenUI: What Changes When AI Builds the UI?\nTL;DR 핵심 정리 화면에서 규칙으로 이동한다: GenUI에서는 모든 화면을 미리 설계하는 대신, AI가 어떤 상황에서 어떤 컴포넌트를 써야 하는지 정의한다. Hatcha가 사례다: gskinner는 Google 발표를 위해 Flutter 기반 이벤트 플래닝 앱 Hatcha를 만들며, 초대장과 대시보드가 맥락에 맞게 조립되는 경험을 실험했다. 디자인 시스템은 재고가 된다: 컴포넌트는 예쁜 부품이 아니라, AI가 목적에 맞게 꺼내 쓰는 선택 가능한 도구 목록이다. 고정 UI와 GenUI를 나눠야 한다: 내비게이션, 규제 절차, 감사 가능한 흐름은 고정 UI가 낫고, 개인화와 가변성이 큰 영역은 GenUI가 빛난다. 디자이너의 사용자 이해가 더 중요해진다: 컴포넌트 조건, 프롬프트, 가드레일은 결국 사용자를 얼마나 잘 이해했는지의 표현이다. GenUI가 바꾸는 기본 전제 전통적인 UI는 미리 구성됩니다. 디자이너가 화면을 그리고, 사용자는 그 화면 사이를 이동합니다. 플로우차트, 와이어프레임, 프로토타입은 모두 \u0026ldquo;어떤 화면이 어떤 순서로 나오는가\u0026quot;를 정하는 데 초점이 있습니다.\nGenUI는 이 전제를 바꿉니다. AI가 사용자의 목표와 맥락을 보고 그때그때 UI를 조립합니다. 그래서 디자이너의 질문도 바뀝니다.\n이 화면은 어떻게 보여야 하는가? 이 컴포넌트는 어떤 상황에서 등장해야 하는가? 이 데이터는 입력, 확인, 비교, 실행 중 어느 목적에 쓰이는가? AI가 선택하면 안 되는 조합은 무엇인가? 즉 결과 화면보다 선택 규칙이 더 중요해집니다. 디자이너는 최종 산출물을 하나하나 그리는 대신, AI가 사용할 수 있는 범위와 우선순위를 정합니다.\n왜 이벤트 플래닝인가 gskinner가 만든 Hatcha는 이벤트를 준비하는 앱입니다. 주최자는 AI와 대화하며 이벤트 정보를 제공하고, GenUI는 그 맥락에 맞춰 초대장, 대시보드, 게스트 응답 모듈을 구성합니다.\n이벤트는 GenUI 사례로 적합합니다. 저녁 식사, 회사 워크숍, 대형 콘서트, 생일 파티는 모두 \u0026ldquo;이벤트\u0026quot;지만 필요한 정보와 분위기가 다릅니다. 어떤 이벤트는 식단 제한이 중요하고, 어떤 이벤트는 좌석, 일정, 준비물, 동선이 중요합니다.\n이처럼 경우의 수가 많은 문제를 고정 화면만으로 처리하면 화면이 늘어나거나, 반대로 너무 일반적인 폼이 됩니다. GenUI는 이런 곳에서 강점을 갖습니다. 사용자의 답변과 참가자의 반응에 따라 필요한 UI만 다시 구성할 수 있기 때문입니다.\n디자인 시스템은 AI의 재고다 글에서 가장 중요한 관점은 디자인 시스템의 역할 변화입니다. GenUI가 화면을 조립한다면, 디자인 시스템은 단순한 스타일 규칙이 아닙니다. AI가 꺼내 쓸 수 있는 결정의 재고가 됩니다.\n예를 들어 같은 식단 정보도 상황에 따라 다르게 보여야 합니다.\n게스트가 응답할 때는 다중 선택 UI가 적합하다. 주최자가 전체 현황을 볼 때는 차트가 적합하다. 장보기 직전에는 준비 목록의 한 줄 항목이 적합하다. 데이터는 같지만 목적이 다릅니다. 그래서 필요한 컴포넌트도 달라집니다. 디자이너는 \u0026ldquo;식단 정보 화면\u0026rdquo; 하나를 설계하는 대신, 이 데이터가 어떤 목적에서 어떤 형태로 표현되어야 하는지 정의합니다.\n이때 컴포넌트는 범용적이어야 하지만 무제한적이면 안 됩니다. AI가 아무 때나 차트나 카드나 입력폼을 꺼내 쓰면 경험은 산만해집니다. 좋은 GenUI 디자인 시스템은 컴포넌트의 모양뿐 아니라 등장 조건과 사용 금지 조건을 함께 담아야 합니다.\n모든 것을 GenUI로 만들 필요는 없다 gskinner가 강조하는 실무적 질문은 \u0026ldquo;무엇을 GenUI로 만들지\u0026quot;입니다. GenUI는 유연하지만 공짜가 아닙니다. 매번 조립하려면 토큰 비용이 들고, 렌더링이 느려질 수 있으며, 결과가 항상 예측 가능하지도 않습니다.\n그래서 고정 UI가 더 나은 영역이 있습니다.\n주요 내비게이션 결제, 인증, 권한처럼 예측 가능성이 중요한 흐름 규제나 감사가 필요한 절차 사용자가 매번 같은 위치에서 같은 행동을 기대하는 기본 기능 반대로 GenUI가 어울리는 영역은 사용자의 목표와 맥락이 매번 달라지는 곳입니다. 이벤트별 준비 모듈, 게스트 응답에 따른 대시보드, 대화형 계획 수립처럼 개인화와 가변성이 가치인 영역입니다.\n실무적으로는 \u0026ldquo;AI로 화면을 만들 수 있는가\u0026quot;보다 **\u0026ldquo;이 화면이 매번 달라질 때 사용자에게 실제 이득이 있는가\u0026rdquo;**를 먼저 물어야 합니다.\n새 산출물: 화면보다 기준 GenUI 프로젝트에서 디자이너의 산출물도 달라집니다. 과거에는 화면 시안, 플로우, 상태별 UI가 중심이었다면, 이제는 다음이 더 중요해집니다.\n컴포넌트 목록 각 컴포넌트의 사용 조건 컴포넌트 간 계층과 우선순위 AI 루프별 프롬프트와 제약 고정 영역과 가변 영역의 경계 실패했을 때의 fallback 경험 이 산출물은 개발과 더 가까이 붙어야 합니다. 규칙이 실제 런타임에서 어떻게 작동하는지 테스트하고, 기대와 다르면 다시 정의해야 합니다. GenUI 디자인은 한 번 넘기는 문서가 아니라, 정의하고 시험하고 고치는 반복 작업에 가깝습니다.\n디자이너의 일은 줄어드는가 겉으로 보면 AI가 UI를 만들기 때문에 디자이너의 일이 줄어드는 것처럼 보일 수 있습니다. 하지만 글의 결론은 반대에 가깝습니다. 디자이너가 직접 그리는 화면 수는 줄 수 있어도, 판단의 중요성은 커집니다.\nAI는 사용자를 이해하지 않습니다. AI는 주어진 재고와 규칙 안에서 조립합니다. 따라서 어떤 컴포넌트를 제공할지, 어떤 상황에서 어떤 선택을 허용할지, 무엇을 고정할지, 무엇을 열어둘지는 여전히 사람의 결정입니다.\n좋은 GenUI는 \u0026ldquo;AI가 알아서 예쁘게 만든 화면\u0026quot;이 아닙니다. 좋은 GenUI는 디자이너가 사용자의 목적을 잘 이해하고, 그 이해를 컴포넌트와 규칙으로 번역한 시스템입니다.\n결론 및 시사점 한 줄 결론: GenUI 시대의 디자이너는 화면을 덜 그리는 사람이 아니라, AI가 화면을 만들 때 따를 기준을 더 정교하게 설계하는 사람이다.\n이 글의 중요한 교훈은 AI가 UI 디자인을 대체한다는 이야기가 아닙니다. 오히려 AI가 UI를 조립하기 시작하면, 디자인 시스템과 제품 판단이 더 중요해진다는 이야기입니다.\n정해진 화면을 빠르게 찍어내는 능력보다, 어떤 부분은 고정하고 어떤 부분은 가변으로 둘지 판단하는 능력이 중요해집니다. GenUI는 모든 제품에 넣어야 할 유행어가 아니라, 사용자의 맥락이 너무 다양해서 하나의 화면 흐름으로 납작하게 만들기 어려운 문제에 쓰는 도구입니다.\n","wordCount":783,"tags":["AI","GenUI","Product Design","Flutter","Design System","gskinner"],"categories":["AI","Design"],"frameworks":["Design Systems","Human-AI Interaction","Runtime Composition"],"mental_models":["Inventory","Guardrails","Feedback Loop"],"philosophy_type":"product-design","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["GenUI에서는 디자이너가 모든 화면과 흐름을 미리 그리는 대신, AI가 사용할 컴포넌트 목록과 선택 조건, 레이아웃 규칙을 설계한다","gskinner는 Google I/O와 Google Cloud Next 발표를 위해 Flutter 기반 이벤트 플래닝 앱 Hatcha를 만들며 GenUI의 실제 설계 문제를 다뤘다","이벤트 계획처럼 입력 맥락이 매번 달라지는 영역에서는 고정 화면보다 런타임 UI 조립이 강점을 갖는다","디자인 시스템은 더 이상 스타일 가이드만이 아니라 AI가 꺼내 쓰는 결정의 재고가 된다","GenUI는 모든 화면에 쓰기보다 개인화, 가변성, 대화형 맥락이 큰 곳에 제한적으로 쓰는 편이 적합하다"],"related":["posts/modern-engineering-values","posts/agent-harness-engineering","posts/zero-alignment-maggie-appleton"]},{"title":"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-08T23:49:00+09:00","lastmod":"2026-07-08T23:49:00+09:00","description":"Geoffrey Litt의 Understanding Is the New Bottleneck을 바탕으로, AI가 구현 속도를 올릴수록 사람이 무엇을 이해해야 하는지와 그 이해가 왜 다음 병목이 되는지 정리한다.","summary":"Geoffrey Litt의 글 Understanding Is the New Bottleneck은 AI 코딩 시대의 병목이 어디로 이동하는지 묻는다. 예전에는 구현 속도가 문제였다. 이제는 AI가 초안을 빠르게 만들기 때문에, 사람이 그 결과를 이해하고 다음 판단으로 연결하는 능력이 더 큰 제약이 된다.\nBottleneck 핵심 정리 병목 이동: AI는 작성 속도를 올리지만, 사람이 시스템을 이해하는 속도까지 자동으로 올리지는 않는다. 이해의 목적: 코드를 승인하기 위해서만 이해하는 것이 아니라, 다음 아이디어와 설계 판단에 참여하기 위해 이해해야 한다. 인지 부채: 읽지 않은 코드, 설명되지 않은 결정, 머릿속에 남지 않은 맥락은 나중에 더 큰 비용으로 돌아온다. 도구 방향: 좋은 AI 개발 환경은 사람을 생략하는 것이 아니라, 사람이 더 빠르게 파악하고 개입하도록 도와야 한다. 1) AI는 생산 병목을 없애지 않고 옮긴다 AI 코딩 도구가 잘하는 일은 분명하다. 함수 초안, UI 구현, 리팩터링, 테스트 보강 같은 작업을 사람이 직접 타이핑하는 것보다 훨씬 빠르게 만든다. 그래서 표면적으로는 \u0026ldquo;만드는 속도\u0026quot;가 올라간다.\n","content":"Geoffrey Litt의 글 Understanding Is the New Bottleneck은 AI 코딩 시대의 병목이 어디로 이동하는지 묻는다. 예전에는 구현 속도가 문제였다. 이제는 AI가 초안을 빠르게 만들기 때문에, 사람이 그 결과를 이해하고 다음 판단으로 연결하는 능력이 더 큰 제약이 된다.\nBottleneck 핵심 정리 병목 이동: AI는 작성 속도를 올리지만, 사람이 시스템을 이해하는 속도까지 자동으로 올리지는 않는다. 이해의 목적: 코드를 승인하기 위해서만 이해하는 것이 아니라, 다음 아이디어와 설계 판단에 참여하기 위해 이해해야 한다. 인지 부채: 읽지 않은 코드, 설명되지 않은 결정, 머릿속에 남지 않은 맥락은 나중에 더 큰 비용으로 돌아온다. 도구 방향: 좋은 AI 개발 환경은 사람을 생략하는 것이 아니라, 사람이 더 빠르게 파악하고 개입하도록 도와야 한다. 1) AI는 생산 병목을 없애지 않고 옮긴다 AI 코딩 도구가 잘하는 일은 분명하다. 함수 초안, UI 구현, 리팩터링, 테스트 보강 같은 작업을 사람이 직접 타이핑하는 것보다 훨씬 빠르게 만든다. 그래서 표면적으로는 \u0026ldquo;만드는 속도\u0026quot;가 올라간다.\n하지만 소프트웨어 작업의 핵심은 코드 문자열을 생산하는 데서 끝나지 않는다. 왜 이 구조가 맞는지, 어떤 예외가 있는지, 나중에 어디가 바뀔 수 있는지, 사용자가 실제로 원하는 것이 무엇인지 이해해야 한다. AI가 코드를 빨리 만들수록 이 이해의 부담은 더 선명해진다.\n예전에는 구현 시간이 길어서 자연스럽게 생각할 시간이 생겼다. 지금은 결과물이 먼저 도착한다. 사람은 더 짧은 시간 안에 더 많은 결정을 읽고 판단해야 한다. 병목은 손에서 머리로 이동한다.\n2) 검토만을 위한 이해는 부족하다 많은 팀이 AI 결과물을 다룰 때 \u0026ldquo;검토할 수 있으면 충분하다\u0026quot;고 생각한다. 틀린 코드가 들어가지 않게 확인하면 된다는 관점이다. 물론 검토는 필요하다. 하지만 Litt가 강조하는 지점은 그보다 넓다.\n이해는 방어 수단만이 아니다. 이해해야 더 좋은 질문을 던질 수 있다. 요구사항을 바꿀 수 있고, 설계를 단순화할 수 있고, 사용자가 진짜 막힌 지점을 다시 볼 수 있다. 사람이 시스템을 이해하지 못하면 AI에게 더 나은 방향을 제시하기 어렵다.\n즉, 이해는 \u0026ldquo;AI가 낸 답을 채점하는 능력\u0026quot;이 아니라 \u0026ldquo;다음 판을 여는 능력\u0026quot;이다. 여기서 차이가 난다. 검토자는 틀린 부분을 찾지만, 참여자는 문제 자체를 다시 잡는다.\n3) 읽지 않은 결과물은 인지 부채가 된다 AI가 만든 결과를 제대로 읽지 않고 합치면 당장은 빨라 보인다. 그러나 팀의 머릿속에는 아무것도 남지 않는다. 왜 이 파일이 바뀌었는지, 왜 이 추상화가 생겼는지, 어떤 선택지가 버려졌는지 설명할 사람이 줄어든다.\n이것은 기술 부채와 다르지만 비슷하게 위험하다. 코드는 돌아가는데, 팀이 코드를 설명하지 못한다. 기능은 배포됐는데, 다음 변경을 어디서 시작해야 할지 모른다. 문서가 있어도 실제 판단 맥락이 사라져 있다.\n그래서 AI 시대의 속도는 두 가지로 나뉜다.\n결과물을 더 빨리 만드는 속도 사람이 결과물을 자기 이해로 흡수하는 속도 첫 번째만 빨라지면 잠깐은 생산성이 올라간다. 두 번째가 따라오지 않으면 어느 순간 변경 비용이 다시 폭발한다.\n4) 좋은 도구는 사람을 빼지 않고 이해를 압축한다 여기서 필요한 도구는 \u0026ldquo;사람 없이 전부 처리하는 AI\u0026quot;만이 아니다. 더 중요한 방향은 사람이 더 빨리 이해하도록 돕는 도구다.\n예를 들면 다음 같은 기능이 중요해진다.\n변경 이유를 코드 위치와 함께 설명한다. 대안 설계와 버린 이유를 짧게 남긴다. 실행 결과, 테스트 근거, 남은 불확실성을 분리해서 보여준다. 큰 변경을 사람이 따라갈 수 있는 작은 단위로 쪼갠다. 사용자가 질문하면 전체 맥락에서 답하고, 필요한 곳으로 바로 안내한다. 이런 도구는 사람의 역할을 없애지 않는다. 오히려 사람의 개입 지점을 더 좋게 만든다. AI가 더 많은 초안을 만들수록, 사람은 모든 줄을 직접 쓰는 대신 중요한 판단을 더 명확히 해야 한다.\n5) 실무에 적용하는 작은 원칙 AI 코딩을 쓰는 팀이라면 다음 기준을 둘 수 있다.\n첫째, 큰 변경은 \u0026ldquo;무엇이 바뀌었는가\u0026quot;보다 \u0026ldquo;왜 그렇게 바뀌었는가\u0026quot;를 남긴다. 결과 설명만으로는 다음 사람이 이어받기 어렵다.\n둘째, 이해하지 못한 코드는 바로 합치지 않는다. 완벽히 외우라는 뜻이 아니다. 최소한 실패했을 때 어디를 봐야 하는지, 어떤 가정이 들어갔는지 말할 수 있어야 한다.\n셋째, AI에게 작업을 맡길 때는 산출물뿐 아니라 설명 형식도 요구한다. 테스트 결과, 주요 설계 선택, 위험한 가정, 사람이 확인할 지점을 함께 받는 편이 낫다.\n넷째, 팀은 \u0026ldquo;얼마나 많이 만들었나\u0026quot;만 보지 말고 \u0026ldquo;얼마나 잘 이해하고 이어받을 수 있나\u0026quot;를 봐야 한다. AI 시대의 유지보수성은 코드 품질만이 아니라 이해 가능성에 달려 있다.\n결론 및 시사점 한 줄 결론: AI가 구현을 빠르게 만들수록, 사람의 진짜 일은 더 많이 생산하는 것이 아니라 더 빨리 이해하고 더 나은 판단으로 연결하는 것이다.\nLitt의 글은 AI 개발 도구를 낙관하거나 비관하는 글이 아니다. 핵심은 역할의 이동이다. AI가 코드를 쓰는 속도를 올리면, 사람은 코드 작성자에서 맥락 설계자와 판단자로 더 많이 이동한다.\n그래서 앞으로 중요한 역량은 단순한 프롬프트 작성법만이 아니다. 문제를 설명하는 능력, 결과를 읽는 능력, 불확실성을 드러내는 능력, 팀이 이어받을 수 있게 맥락을 남기는 능력이 함께 중요해진다. AI가 빨라질수록 이해는 더 비싸지고, 더 귀해진다.\n","wordCount":680,"tags":["AI","LLM","Geoffrey-Litt","소프트웨어-개발","이해"],"categories":["AI"],"frameworks":["Cognitive Bottleneck","Human-AI Collaboration","End-User Programming"],"mental_models":["Cognitive Debt","Feedback Loop","Tacit Knowledge"],"philosophy_type":"engineering-process","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI가 코드를 더 빨리 만들수록 병목은 타이핑이나 구현이 아니라, 사람이 시스템과 문제를 충분히 이해하는 능력으로 이동한다.","이해는 단순 검수용 지식이 아니라, 다음 질문을 만들고 설계를 바꾸며 더 나은 아이디어에 참여하기 위한 기반이다.","복잡한 결과물을 읽지 않고 승인하면 속도는 올라가지만, 팀 안에는 설명되지 않은 결정과 인지 부채가 쌓인다.","좋은 AI 도구는 사람을 루프 밖으로 밀어내기보다, 사람이 더 빨리 이해하고 더 깊게 개입할 수 있게 해야 한다."],"related":["posts/fowler-fragments-cognitive-debt-system-3","posts/agentic-autonomy-levels-addy-osmani","posts/yes-we-still-need-engineers"]},{"title":"자기개선을 위한 하네스 엔지니어링 - 모델을 둘러싼 시스템이 진짜 무대다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/harness-engineering-for-self-improvement/","section":"posts","date":"2026-07-08T23:48:50+09:00","lastmod":"2026-07-08T23:48:50+09:00","description":"Lilian Weng의 글을 바탕으로, AI 자기개선에서 모델 가중치뿐 아니라 도구, 메모리, 워크플로, 평가 루프를 묶는 하네스가 왜 중요한 최적화 대상인지 정리한다.","summary":"Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다.\nHarness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다.\n가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다.\n중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다.\n최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다.\n현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, 다양성 붕괴, 장기 유지보수 비용을 피하기 어렵다. 1) 하네스는 프롬프트보다 실행 시스템에 가깝다 초기 에이전트 설명은 보통 LLM + memory + tools + planning + action 같은 공식으로 끝났다. Weng은 여기에 한 층을 더 얹는다. 실제 제품에서 중요한 것은 모델에게 좋은 말을 건네는 것만이 아니라, 모델이 어떤 루프 안에서 관찰하고, 실행하고, 실패를 기록하고, 다시 시도하게 만드는가다.\n","content":"Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다.\nHarness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다.\n가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다.\n중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다.\n최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다.\n현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, 다양성 붕괴, 장기 유지보수 비용을 피하기 어렵다. 1) 하네스는 프롬프트보다 실행 시스템에 가깝다 초기 에이전트 설명은 보통 LLM + memory + tools + planning + action 같은 공식으로 끝났다. Weng은 여기에 한 층을 더 얹는다. 실제 제품에서 중요한 것은 모델에게 좋은 말을 건네는 것만이 아니라, 모델이 어떤 루프 안에서 관찰하고, 실행하고, 실패를 기록하고, 다시 시도하게 만드는가다.\n그래서 하네스는 프롬프트 템플릿이라기보다 런타임에 가깝다. 운영체제가 복잡한 장치와 프로세스를 단순한 인터페이스로 감싸듯, 하네스는 도구, 파일, 컨텍스트, 권한, 평가를 모델이 다룰 수 있는 형태로 감싼다.\n이 관점은 코딩 에이전트를 보면 바로 이해된다. Claude Code, Codex, OpenCode, Cursor류 도구는 모두 비슷한 루프를 갖는다. 파일을 찾고, 읽고, 수정하고, 셸을 실행하고, 테스트하고, 실패 로그를 다시 읽는다. 모델이 똑똑해도 이 루프가 없으면 실제 저장소에서 오래 버티기 어렵다.\n2) 세 가지 기본 패턴: 루프, 파일, 병렬 작업 첫 번째 패턴은 워크플로 자동화다. 목표를 세우고, 실행하고, 관찰하거나 테스트하고, 다시 고치는 루프다. 중요한 점은 이 루프가 정적인 프롬프트가 아니라 실패 궤적을 읽고 자기 행동을 바꾸는 런타임이라는 것이다.\n두 번째 패턴은 파일 시스템을 장기 기억으로 쓰는 것이다. 긴 작업에서는 모든 로그와 산출물을 컨텍스트에 넣을 수 없다. 실험 로그, 코드 diff, 오류 추적, 이전 시도는 파일로 남아야 한다. 그래야 중간에 끊겨도 복구할 수 있고, 모델이 grep, cat, rg 같은 익숙한 도구로 자기 과거를 다시 읽을 수 있다.\n세 번째 패턴은 서브에이전트와 백엔드 작업이다. 긴 리서치나 실험에서는 여러 가설을 병렬로 돌려야 한다. 하지만 병렬성은 보이지 않으면 위험하다. 부모 에이전트가 작업을 띄우고, 로그를 보고, 실패한 실행을 취소하고, 결과를 다시 합치는 작은 프로세스 매니저가 필요하다.\n3) 자기개선은 하네스에서 먼저 일어날 수 있다 Weng의 가까운 전망은 꽤 실용적이다. 자기개선이 당장 \u0026ldquo;모델이 자기 가중치를 직접 다시 쓴다\u0026quot;는 모습으로 시작되기보다, 더 나은 답을 얻는 방법론 자체를 고치는 방향으로 먼저 나타난다는 것이다.\n이때 하네스는 최적화 대상이 된다. 단순히 답을 더 잘 내는 것이 아니라, 좋은 답을 만들기 위한 기계 장치를 더 잘 만든다. 컨텍스트를 어떻게 줄이고, 실패를 어떻게 분류하고, 어떤 테스트를 통과해야 수정안을 받아들일지 고치는 식이다.\n글이 제시하는 진행 방향은 이렇다.\n프롬프트를 고친다. 구조화된 컨텍스트를 고친다. 워크플로를 고친다. 하네스 코드를 고친다. 하네스를 고치는 옵티마이저 자체를 고친다. 단계가 내려갈수록 설계 공간은 커진다. 대신 잘못 고쳤을 때의 위험도 커진다. 그래서 권한과 평가 장치는 자기수정 루프 바깥에 두어야 한다는 경고가 붙는다.\n4) 컨텍스트 엔지니어링은 긴 프롬프트 만들기가 아니다 긴 작업에서 모든 도구 응답과 모든 모델 생성을 계속 붙이면 컨텍스트가 무너진다. Weng이 소개하는 Agentic Context Engineering은 컨텍스트를 하나의 거대한 문장 덩어리가 아니라, 식별자와 설명을 가진 항목들의 플레이북으로 관리한다.\n핵심은 재작성 방식이다. 매번 전체 프롬프트를 다시 쓰면 중요한 내용이 사라지거나 짧은 문장으로 과도하게 압축된다. 대신 성공과 실패에서 배운 내용을 항목 단위로 추가하고, 주기적으로 정리하고, 중복을 제거한다.\nMeta Context Engineering은 여기서 한 단계 더 나아간다. 어떤 내용을 컨텍스트에 넣을지뿐 아니라, 컨텍스트를 관리하는 방식 자체를 진화시킨다. 구현상으로는 skill.md, 정적 지식, 동적 롤아웃, 데이터 파일이 들어 있는 디렉터리가 하나의 컨텍스트 함수처럼 작동한다.\n5) 하네스는 코드라서 탐색할 수 있다 하네스가 코드라면, 모델은 하네스 설계 공간을 탐색할 수 있다. Meta-Harness는 어떤 정보를 저장하고, 꺼내고, 모델에게 보여줄지 결정하는 코드까지 최적화 대상으로 본다. ADAS와 AFlow는 에이전트 워크플로를 사람이 손으로 짜는 대신, 후보를 만들고 평가하며 더 나은 흐름을 찾는다.\nSelf-Harness는 더 직접적이다. 현재 하네스의 실패를 모으고, 반복되는 약점을 찾고, 좁은 수정안을 제안하고, held-in과 held-out 평가에서 회귀가 없을 때만 받아들인다. 중요한 건 \u0026ldquo;스스로 고친다\u0026quot;는 낭만이 아니라, 실패 패턴을 검증 가능한 수정으로 바꾸고 회귀를 막는 절차다.\n진화적 탐색도 같은 맥락이다. AlphaEvolve, ShinkaEvolve, Darwin Gödel Machine 같은 계열은 후보 프로그램이나 에이전트 하네스를 만들고, 평가하고, 좋은 것만 남긴다. 자동 평가가 빠르고 명확한 영역에서는 강하다. 반대로 평가가 느리고 애매한 연구 취향, 제품 판단, 장기 유지보수에서는 훨씬 어렵다.\n6) 병목은 결국 평가와 권한이다 자기개선 루프는 자신에게 주어진 신호를 최적화한다. 그 신호가 단위 테스트면 테스트에 과적합할 수 있고, 심판 모델이면 심판 모델의 취향을 공략할 수 있고, 벤치마크면 벤치마크의 빈틈을 찾을 수 있다.\n그래서 Weng은 평가자와 권한 제어가 하네스 진화 루프 바깥에 있어야 한다고 본다. held-out 테스트, trace audit, 중요한 의사결정 지점의 인간 검토가 필요하다. 특히 연구 자동화에서는 그 차이가 더 크다. 논문을 쓰는 시스템이 있다고 해서 과학적 발견을 하는 시스템이 되는 것은 아니다. 그럴듯한 원고, 깨진 인용, 약한 실험 결과는 얼마든지 나올 수 있다.\n글의 미래 과제도 여기로 모인다. 흐릿한 평가자, 늘어나는 메모리의 생명주기, 실패 결과를 보존하지 않는 연구 문화, 다양성 붕괴, 보상 해킹, 저장소의 장기 건강, 인간의 적절한 개입 지점이 모두 아직 열린 문제다.\n결론 및 시사점 하네스 엔지니어링은 모델을 포장하는 주변 작업이 아니라, 모델이 현실의 긴 작업을 해내게 만드는 실행 조건이다. 가까운 자기개선은 더 큰 모델 하나로 끝나지 않고, 모델이 자기 실행 환경을 읽고 고치고 검증하는 방식에서 먼저 나타날 가능성이 높다.\n실무적으로는 두 가지를 기억하면 된다. 첫째, 에이전트의 성능은 모델 이름만으로 결정되지 않는다. 도구, 파일 상태, 컨텍스트 관리, 평가 루프가 함께 성능을 만든다. 둘째, 자기개선 루프를 열수록 권한과 평가는 더 단단히 분리해야 한다. 고치는 능력보다 중요한 것은, 무엇을 고치면 안 되는지 아는 경계다.\n한 줄 결론: AI 자기개선의 가까운 전장은 모델 내부가 아니라, 모델이 일하고 기억하고 검증받는 하네스 전체다.\n","wordCount":880,"tags":["AI","에이전트","하네스","자기개선","컨텍스트 엔지니어링","Lilian Weng"],"categories":["AI"],"frameworks":["Systems Thinking","Feedback Loop","Context Engineering"],"mental_models":["Recursive Self-Improvement","Search Space","Goodhart's Law"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["하네스는 모델이 도구를 호출하고, 컨텍스트를 관리하고, 결과를 평가하고, 파일 시스템에 상태를 남기게 만드는 실행 시스템이다.","가까운 자기개선은 모델이 곧바로 자기 가중치를 고치는 방식보다, 하네스와 연구 파이프라인을 개선하는 방식으로 먼저 나타날 가능성이 높다.","컨텍스트 엔지니어링은 긴 프롬프트를 계속 덧붙이는 일이 아니라, 성공과 실패의 궤적을 구조화된 플레이북과 파일 상태로 남기는 일에 가깝다.","Self-Harness, Meta-Harness, ADAS, AFlow, DGM 같은 연구는 하네스 자체를 코드 기반 탐색 공간으로 다룬다.","가장 큰 병목은 평가다. 보상이 흐릿하면 자기개선 루프는 실력 향상보다 보상 해킹과 다양성 붕괴로 흐르기 쉽다."],"related":["posts/anatomy-of-an-agent-harness","posts/todays-harness-is-tomorrows-prompt","posts/some-new-agentic-patterns","posts/components-of-a-coding-agent"]},{"title":"AI 확장의 다음 병목은 데이터다 — A Stargate for Data 읽기","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/stargate-for-data/","section":"posts","date":"2026-07-08T16:28:18+09:00","lastmod":"2026-07-08T16:28:18+09:00","description":"Will DePue의 A Stargate for Data를 바탕으로, AI 발전의 병목이 컴퓨트에서 데이터 커버리지로 이동하고 있다는 주장을 정리한다.","summary":"Will DePue의 A Stargate for Data는 AI 산업의 관심이 컴퓨트에 치우쳐 있는 동안, 다음 병목은 데이터가 될 수 있다고 말한다. X에 올라온 원문 포스트는 이 문제의식을 짧게 던지고, LinkedIn 글은 그 배경을 길게 설명한다.\nData 핵심 정리 핵심 주장: AI 발전은 모델 크기와 데이터 양을 함께 키우며 진행됐지만, 이제 공개 인터넷 데이터가 부족해지는 국면에 들어가고 있다. 전환점: 과거에는 GPU가 부족하고 인터넷 데이터는 충분했다. 앞으로는 컴퓨트가 커질수록, 각 산업의 비공개 지식과 실제 업무 데이터가 더 큰 병목이 된다. 시장 크기: DePue는 외부 데이터 벤더 지출이 이미 연간 약 70억 달러이며, 2030년에는 연간 1,000억 달러 이상으로 커질 수 있다고 본다. 경쟁 구도: 컴퓨트는 같은 칩과 비슷한 클러스터를 살 수 있지만, 데이터는 독점 계약·전문가 네트워크·품질 관리·도메인 커버리지로 차별화된다. 전략 질문: 컴퓨트를 위해 Stargate 같은 초대형 인프라를 만든다면, 데이터에도 그에 맞는 국가·산업 규모의 수집 프로젝트가 필요하지 않느냐는 질문이다. 1) 인터넷은 AI에게 주어진 일회성 보조금이었다 원문에서 가장 좋은 비유는 인터넷을 \u0026ldquo;한 번뿐인 보조금\u0026quot;으로 보는 관점이다. 딥러닝은 수십 년 동안 사람들이 의도치 않게 쌓아 둔 책, 블로그, 이미지, 영상, 논문, 토론 기록을 거의 한꺼번에 이용했다. 공개 웹은 모델이 세상을 배우는 거대한 기본 교재였다.\n","content":"Will DePue의 A Stargate for Data는 AI 산업의 관심이 컴퓨트에 치우쳐 있는 동안, 다음 병목은 데이터가 될 수 있다고 말한다. X에 올라온 원문 포스트는 이 문제의식을 짧게 던지고, LinkedIn 글은 그 배경을 길게 설명한다.\nData 핵심 정리 핵심 주장: AI 발전은 모델 크기와 데이터 양을 함께 키우며 진행됐지만, 이제 공개 인터넷 데이터가 부족해지는 국면에 들어가고 있다. 전환점: 과거에는 GPU가 부족하고 인터넷 데이터는 충분했다. 앞으로는 컴퓨트가 커질수록, 각 산업의 비공개 지식과 실제 업무 데이터가 더 큰 병목이 된다. 시장 크기: DePue는 외부 데이터 벤더 지출이 이미 연간 약 70억 달러이며, 2030년에는 연간 1,000억 달러 이상으로 커질 수 있다고 본다. 경쟁 구도: 컴퓨트는 같은 칩과 비슷한 클러스터를 살 수 있지만, 데이터는 독점 계약·전문가 네트워크·품질 관리·도메인 커버리지로 차별화된다. 전략 질문: 컴퓨트를 위해 Stargate 같은 초대형 인프라를 만든다면, 데이터에도 그에 맞는 국가·산업 규모의 수집 프로젝트가 필요하지 않느냐는 질문이다. 1) 인터넷은 AI에게 주어진 일회성 보조금이었다 원문에서 가장 좋은 비유는 인터넷을 \u0026ldquo;한 번뿐인 보조금\u0026quot;으로 보는 관점이다. 딥러닝은 수십 년 동안 사람들이 의도치 않게 쌓아 둔 책, 블로그, 이미지, 영상, 논문, 토론 기록을 거의 한꺼번에 이용했다. 공개 웹은 모델이 세상을 배우는 거대한 기본 교재였다.\n하지만 이 교재는 무한하지 않다. DePue는 유용한 공개 인간 텍스트가 약 300조 토큰 수준이라고 본다. 새로 생기는 고품질 공개 데이터는 모델 스케일링이 요구하는 속도를 따라가기 어렵다. 수학과 코딩처럼 온라인에서 채점 가능한 과제는 RL에 잠깐 숨통을 틔워줬지만, 이 자원도 빠르게 마르고 있다는 것이 글의 진단이다.\n더 큰 문제는 웹에 애초에 없는 지식이다. 회사 내부의 업무 절차, 전문가의 암묵지, 현장 운영 방식, 물리 세계에서 벌어지는 예외 상황은 공개 문서로 남지 않는 경우가 많다. 모델이 특정 직무를 끝까지 자동화하려면 이런 \u0026ldquo;문서화되지 않은 분포\u0026quot;까지 배워야 한다.\n2) 컴퓨트 병목에서 데이터 커버리지 병목으로 지난 몇 년간 AI 경쟁의 대표 이미지는 거대한 GPU 클러스터였다. 더 많은 칩, 더 큰 데이터센터, 더 긴 학습이 성능 향상의 상징이었다. DePue는 이 방향이 끝났다고 말하지 않는다. 오히려 컴퓨트 스케일링은 계속된다고 본다.\n다만 컴퓨트가 커질수록 다음 질문이 더 커진다. 그 컴퓨트로 무엇을 학습할 것인가?\n범용 모델이 경제적으로 가치 있는 일을 더 많이 하려면 각 영역의 데이터 커버리지가 필요하다. 회계, 의료, 법률, 보안, 제조, 연구, 고객지원, 사내 운영은 모두 표면 문서만으로는 부족하다. 실제 업무는 도구, 예외, 장기 흐름, 판단 기준, 조직별 관습을 포함한다.\n따라서 자동화 속도는 알고리즘 하나만으로 결정되지 않는다. 특정 업무 세계가 얼마나 잘 기록되고, 라이선스되고, 검증 가능한 학습 과제로 바뀌는지가 함께 결정한다.\n3) 데이터 지출은 거대한 시장이 될 수 있다 DePue는 데이터 지출이 2030년까지 연간 1,000억 달러를 넘을 수 있다고 본다. 현재도 내부 랩 비용을 제외한 외부 데이터 벤더 지출이 약 70억 달러 수준이라고 주장한다. 공개 인터넷이 공짜에 가까운 원천이었다면, 다음 데이터는 훨씬 비싸다.\n이 비용은 단순 라벨링 비용만 뜻하지 않는다. 앞으로 필요한 데이터는 더 전문적이고, 더 희소하고, 더 검증하기 어렵다.\n전문가가 만든 고난도 RL 과제 실제 업무 도구를 포함한 에이전트 환경 법률 문서, 의료 판단, 보안 분석처럼 권리와 품질 관리가 중요한 데이터 기업 내부 프로세스와 예외 케이스 장기 작업 흐름과 실패 사례 즉 데이터 산업은 \u0026ldquo;사람이 이미지를 분류해 주는 시장\u0026quot;에서 \u0026ldquo;경제 전체의 암묵지를 모델이 배울 수 있는 형태로 바꾸는 시장\u0026quot;으로 이동한다.\n4) 데이터는 해자가 된다 컴퓨트는 매우 비싸지만 어느 정도 상품화되어 있다. 돈이 있으면 같은 종류의 칩을 사고, 비슷한 클러스터를 지을 수 있다. 반면 데이터는 그렇지 않다. 어떤 회사와 계약했는지, 어떤 전문가 네트워크를 갖고 있는지, 품질 검수 체계가 어떤지, 어떤 도메인에서 먼저 깊게 파고들었는지가 그대로 차이를 만든다.\n원문은 최근 모델들이 특정 영역에서 다르게 강해지는 이유도 데이터의 차이로 본다. 수학에 강한 모델, 보안에 강한 모델, 코딩에 강한 모델은 단순히 아키텍처가 달라서가 아니라 해당 영역의 학습 데이터, 중간 학습 토큰, RL 과제, 평가 환경을 더 잘 모았기 때문이라는 해석이다.\n이 관점에서는 데이터 회사도 쉽게 사라지지 않는다. AGI가 가까워질수록 데이터 수요가 줄어드는 것이 아니라, 오히려 마지막 1%를 채우기 위한 희소 데이터의 가치가 커질 수 있다. 99% 자동화와 100% 자동화 사이에는 큰 경제적 차이가 있기 때문이다.\n5) 데이터는 전략 자산이 된다 DePue의 글이 흥미로운 지점은 데이터 문제를 단순한 기업 구매 문제로 보지 않는다는 데 있다. 데이터 커버리지가 경제 성장과 과학 발전의 속도를 제한한다면, 데이터는 컴퓨트처럼 전략 자산이 된다.\n컴퓨트를 위해 거대한 자본, 전력, 국제 협력, 데이터센터 건설을 조직한다면 데이터에도 비슷한 수준의 상상력이 필요하다. 다만 데이터는 GPU처럼 동질적인 물건이 아니다. 경제 곳곳에 흩어진 지식, 사라지는 기록, 공개되지 않은 업무 흐름, 민감한 권리 문제가 섞여 있다.\n그래서 원문이 던지는 질문은 단순하다.\nAI 산업이 다음 인터넷만큼 큰 데이터 자원을 이번에는 의도적으로 만들 수 있는가?\n가능한 방향은 여러 가지다. 무엇이 부족한지 먼저 조사하고, 2030년 모델이 여전히 못할 일을 역산하고, 필요한 데이터셋과 회사를 사거나 라이선스하고, 기업의 삭제 정책을 바꾸고, 소비자 제품 안에 데이터 플라이휠을 만들고, 정부 연구 데이터와 공공 자금 결과물을 더 잘 연결하는 방식이다.\n6) 읽고 난 뒤 남는 질문 이 글의 강점은 \u0026ldquo;AI는 데이터가 중요하다\u0026quot;는 뻔한 말을 더 날카롭게 만든다는 점이다. 중요한 것은 데이터의 양만이 아니다. 어디가 비어 있는지, 어떤 업무 분포가 아직 기록되지 않았는지, 어떤 데이터가 권리와 품질 문제 때문에 학습 가능한 형태로 오지 못하는지가 핵심이다.\n다만 모든 주장을 그대로 받아들일 필요는 없다. 데이터 효율이 크게 좋아질 수도 있고, 합성 데이터나 새로운 학습법이 일부 병목을 줄일 수도 있다. 또 데이터 수집을 국가 프로젝트처럼 다루면 프라이버시, 동의, 저작권, 감시 위험이 커진다. \u0026ldquo;Stargate for Data\u0026quot;가 필요하다는 말은 매력적이지만, 어떤 데이터는 모으지 않는 것이 맞다는 경계도 함께 필요하다.\n그래도 큰 방향은 설득력 있다. AI가 실제 경제를 자동화하려면 공개 웹을 넘어 실제 업무 세계의 분포를 배워야 한다. 이때 승자는 가장 큰 모델을 가진 팀만이 아니라, 가장 중요한 미기록 지식을 학습 가능한 형태로 바꿀 수 있는 팀일 수 있다.\n결론 및 시사점 한 줄 결론: AI의 다음 병목은 더 큰 GPU만이 아니라, 경제와 과학의 실제 작업을 충분히 담은 고품질 데이터 커버리지다.\n컴퓨트 인프라가 AI 경쟁의 눈에 보이는 전쟁터라면, 데이터 인프라는 덜 보이지만 더 방어적인 전쟁터가 될 가능성이 크다. 앞으로 모델 성능 차이는 파라미터 수보다 어떤 업무 세계를 얼마나 깊게 수집했는지에서 더 자주 갈릴 것이다.\n","wordCount":911,"tags":["AI","데이터","스케일링","LLM","Stargate"],"categories":["AI"],"frameworks":["Scaling Laws","Data Moat","Strategic Asset"],"mental_models":["Bottleneck","One-time Subsidy","O-ring Theory"],"philosophy_type":"technology-strategy","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["AI 스케일링의 병목은 GPU 부족만이 아니라, 각 산업과 업무를 충분히 덮는 고품질 데이터 부족으로 이동하고 있다.","공개 인터넷은 딥러닝에 주어진 일회성 보조금이었지만, 공개 텍스트와 온라인 RL 과제만으로는 다음 단계 수요를 채우기 어렵다.","DePue는 현재 외부 데이터 벤더 지출이 연간 약 70억 달러이고, 2030년에는 데이터 지출이 연간 1,000억 달러를 넘을 수 있다고 본다.","데이터는 컴퓨트보다 덜 상품화되어 있어, 수학·보안·의료·법률 같은 영역에서 모델 차이를 만드는 방어 가능한 해자가 된다.","데이터 수집은 기업 구매 문제가 아니라 국가 전략 자산 문제에 가까워지고 있으며, 컴퓨트의 Stargate에 해당하는 데이터 메가프로젝트가 필요하다는 것이 원문의 질문이다."],"related":["posts/ai-agents-future-context-gap","posts/rl-environments-for-llm-agents","posts/ai-capability-not-cost-reduction"]},{"title":"100x 에이전틱 엔지니어 — 병목은 모델에서 사람의 선호로 이동한다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/100x-agentic-engineer-fable-gpt56/","section":"posts","date":"2026-07-08T13:07:19+09:00","lastmod":"2026-07-08T13:07:19+09:00","description":"systematicls의 X Article을 바탕으로, 강한 코딩 에이전트 시대의 생산성 차이가 도구보다 선호·제약·검증 루프를 얼마나 잘 표현하는지에서 나온다는 주장을 정리했다.","summary":"systematicls의 X Article \u0026ldquo;What The New 100x Agentic Engineer Looks Like In The Era Of Fable \u0026amp; GPT 5.6\u0026rdquo;은 에이전틱 코딩의 생산성 격차가 어디서 생기는지 다룬 글이다. 핵심은 단순하다. 모델이 강해질수록 차이는 \u0026ldquo;AI가 코드를 잘 쓰는가\u0026quot;보다 사람이 원하는 결과와 trade-off를 얼마나 정확히 표현하는가에서 난다.\nTL;DR 핵심 정리 평준화는 일어나지 않는다: 에이전트가 코드를 대신 써도, 에이전트 뒤의 사람이 가진 맥락·판단·선호에 따라 결과 품질은 크게 갈린다. 새 병목은 선호 표현이다: 강한 모델은 구현 후보를 많이 만들 수 있지만, 어떤 후보가 우리 상황의 Pareto frontier에 가까운지는 사람이 알려줘야 한다. 선언형과 명령형을 구분해야 한다: 목표만 중요한 일은 선언형으로 맡기고, 실패 비용이 큰 핵심 경로는 명령형 제약으로 좁혀야 한다. 전략은 하네스에, 전술은 작업 지시문에: 조직 전체 원칙은 규칙·스킬·검증 루프로 저장하고, 프로젝트별 핵심 20%는 작업마다 분명히 적어야 한다. 1) 에이전트가 모두를 같은 수준으로 만들지는 않는다 초기에는 코딩 에이전트가 개발자 생산성을 평준화할 것이라는 기대가 있었다. 누구나 좋은 모델을 쓰면 비슷한 결과를 낼 수 있다는 생각이다.\n","content":"systematicls의 X Article \u0026ldquo;What The New 100x Agentic Engineer Looks Like In The Era Of Fable \u0026amp; GPT 5.6\u0026rdquo;은 에이전틱 코딩의 생산성 격차가 어디서 생기는지 다룬 글이다. 핵심은 단순하다. 모델이 강해질수록 차이는 \u0026ldquo;AI가 코드를 잘 쓰는가\u0026quot;보다 사람이 원하는 결과와 trade-off를 얼마나 정확히 표현하는가에서 난다.\nTL;DR 핵심 정리 평준화는 일어나지 않는다: 에이전트가 코드를 대신 써도, 에이전트 뒤의 사람이 가진 맥락·판단·선호에 따라 결과 품질은 크게 갈린다. 새 병목은 선호 표현이다: 강한 모델은 구현 후보를 많이 만들 수 있지만, 어떤 후보가 우리 상황의 Pareto frontier에 가까운지는 사람이 알려줘야 한다. 선언형과 명령형을 구분해야 한다: 목표만 중요한 일은 선언형으로 맡기고, 실패 비용이 큰 핵심 경로는 명령형 제약으로 좁혀야 한다. 전략은 하네스에, 전술은 작업 지시문에: 조직 전체 원칙은 규칙·스킬·검증 루프로 저장하고, 프로젝트별 핵심 20%는 작업마다 분명히 적어야 한다. 1) 에이전트가 모두를 같은 수준으로 만들지는 않는다 초기에는 코딩 에이전트가 개발자 생산성을 평준화할 것이라는 기대가 있었다. 누구나 좋은 모델을 쓰면 비슷한 결과를 낼 수 있다는 생각이다.\n원문은 반대로 본다. 에이전트가 강해질수록 생산성 차이는 사라지지 않고, 다른 위치로 이동한다. 예전에는 사람이 직접 코드를 잘 쓰는 능력이 차이를 만들었다면, 이제는 사람이 에이전트에게 줄 문제 정의, 제약, 검증 기준, 우선순위가 차이를 만든다.\n같은 모델을 써도 어떤 사람은 평범한 결과를 받고, 어떤 사람은 훨씬 높은 생산성을 낸다. 차이는 프롬프트 문장 길이가 아니라 판단의 밀도다.\n2) 좋은 결과는 \u0026ldquo;정답\u0026quot;이 아니라 trade-off 선택이다 글의 중심에는 No Free Lunch 관점이 있다. 현실의 엔지니어링에는 공짜 점심이 없다. 빠른 코드, 단순한 구조, 낮은 비용, 높은 확장성, 강한 안전성, 쉬운 유지보수는 모두 어느 정도 서로 긴장한다.\n에이전트가 충분히 똑똑해져도 문제는 남는다. 가능한 좋은 해법이 여러 개 있을 때, 그중 무엇이 \u0026ldquo;우리에게 좋은 해법\u0026quot;인지는 모델 혼자 알 수 없다.\n예를 들어 같은 작업을 두고도 선택지는 갈린다.\n빠르게 끝내기 위해 병렬 인스턴스를 많이 띄울 것인가 비용을 아끼기 위해 긴 시간 동안 한 인스턴스로 처리할 것인가 모듈성을 높여 구조를 잘게 나눌 것인가 과한 추상화를 피하려고 단순한 파일 구조를 유지할 것인가 이 선택은 기술 문제가 아니라 선호 문제다. 에이전트가 멍청해 보이는 순간의 상당수는, 사실 에이전트가 잘못했다기보다 사람이 중요한 선호를 말하지 않은 경우다.\n3) 선언형 선호와 명령형 선호 원문은 선호를 크게 두 종류로 나눈다.\n선언형 선호는 원하는 결과를 말하고 방법은 에이전트에게 맡기는 방식이다. 예를 들어 \u0026ldquo;사용자는 지갑을 등록할 수 있어야 한다\u0026quot;처럼 목표가 분명하지만 구현 방식은 열어두는 지시다. 모델이 강할수록 선언형 선호는 유용하다. 사람이 세부 구현에 갇히지 않고 더 넓은 해법 공간을 탐색할 수 있기 때문이다.\n하지만 선언형 선호에는 위험이 있다. \u0026ldquo;지갑 등록이 가능해야 한다\u0026quot;와 \u0026ldquo;10ms 안에 등록되어야 한다\u0026quot;는 전혀 다른 문제다. 시간 제한, 보안 수준, 데이터 보존 방식 같은 경계를 말하지 않으면 에이전트는 빈칸을 추측한다.\n명령형 선호는 반드시 따라야 하는 경로와 제약을 직접 적는 방식이다. 결제 큐, 장애 복구, 데이터베이스 갱신 순서, 스마트 컨트랙트 호출 방식처럼 틀리면 안 되는 업무 흐름에는 명령형 선호가 맞다.\n단점도 있다. 사람이 틀린 경로를 강하게 고정하면 에이전트는 더 나은 해법을 보더라도 움직이기 어렵다. 그래서 좋은 지시는 \u0026ldquo;여기는 고정, 여기는 최적화 가능\u0026quot;을 함께 알려준다.\n4) 전략 선호와 전술 선호 선호는 범위에 따라서도 나뉜다.\n전략 선호는 조직 전체에 반복 적용되는 원칙이다. 보안 우선, 수평 확장 선호, 변경 전 감사 에이전트 실행, 배포 전 검증 루프 같은 것들이 여기에 속한다. 이런 내용은 매번 프롬프트에 다시 쓰기보다 저장소 규칙, 스킬, 하네스에 넣어야 한다.\n전술 선호는 특정 프로젝트나 작업에서만 중요한 제약이다. 같은 조직이라도 분석 파이프라인에서는 처리량이 중요할 수 있고, 거래 실행 서비스에서는 지연 시간이 더 중요할 수 있다. 이런 차이는 작업 지시문에 명시해야 한다.\n실용적인 기준은 80/20이다. 프로젝트에서 실패 비용이 큰 핵심 20%는 명령형으로 좁게 적고, 나머지 80%는 선언형으로 열어두면 속도와 품질의 균형을 잡기 쉽다.\n5) 좋은 에이전틱 엔지니어의 일 이 글이 말하는 100x 에이전틱 엔지니어는 도구를 많이 아는 사람이 아니다. 더 중요한 능력은 다음 세 가지다.\n중요한 결정과 가정을 먼저 찾아낸다. 에이전트에게 소크라테스식 질문을 시켜 자신의 숨은 선호를 드러낸다. 고정해야 할 제약과 에이전트가 탐색해도 되는 영역을 구분한다. 즉, 좋은 에이전틱 엔지니어는 \u0026ldquo;이걸 만들어줘\u0026quot;에서 멈추지 않는다. \u0026ldquo;어떤 결정이 구현을 크게 바꿀까?\u0026rdquo;, \u0026ldquo;내가 말하지 않은 제약은 무엇일까?\u0026rdquo;, \u0026ldquo;내 설계보다 목표에 더 맞는 대안이 있으면 먼저 알려줘\u0026quot;라고 묻는다.\n프롬프트 엔지니어링이 죽었다는 말은 반만 맞다. 낡은 의미의 프롬프트 기술은 약해졌지만, 선호와 제약을 정확히 표현하는 일은 더 중요해졌다. 모델이 강할수록 사람이 잘못 준 목표를 더 빠르게, 더 그럴듯하게 향해 달릴 수 있기 때문이다.\n결론 및 시사점 한 줄 결론: 에이전틱 코딩의 다음 격차는 모델을 쓰는 능력이 아니라, 사람이 자신의 선호·제약·검증 기준을 얼마나 정확히 드러내는가에서 생긴다.\nFable급 모델과 GPT 5.6 같은 강한 에이전트의 시대를 전제로 하면, 구현 자체는 점점 싸진다. 하지만 무엇을 만들지, 어떤 trade-off를 감수할지, 어디서 에이전트를 묶고 어디서 풀어줄지는 여전히 사람의 몫이다.\n그래서 실무에서 바로 적용할 수 있는 질문은 이것이다.\n이 작업에서 반드시 지켜야 할 20%는 무엇인가 나머지 80%는 에이전트가 자유롭게 탐색해도 되는가 조직 전체 원칙은 매번 말하고 있는가, 아니면 하네스에 저장되어 있는가 에이전트가 내 설계보다 나은 대안을 발견했을 때 말할 수 있는 여지가 있는가 100x 에이전틱 엔지니어는 AI에게 일을 많이 던지는 사람이 아니라, AI가 올라갈 언덕을 제대로 고르는 사람이다.\n","wordCount":764,"tags":["AI","에이전트","Fable","GPT","소프트웨어엔지니어링","하네스"],"categories":["AI"],"frameworks":["Preference Engineering","Agent Harness Engineering","Pareto Frontier"],"mental_models":["No Free Lunch","Trade-off Management","80/20 Rule"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전틱 코딩은 개발자 생산성을 평준화하지 않고, 오히려 사람의 선호·맥락·제약 표현 능력에 따라 격차를 크게 만든다","강한 모델 시대의 병목은 구현 능력보다 무엇을 원하는지, 어떤 trade-off를 감수할지, 어디를 엄격히 고정할지 정하는 능력이다","선언형 선호는 목표를 넓게 맡기는 방식이고, 명령형 선호는 반드시 지켜야 할 경로와 제약을 좁게 고정하는 방식이다","전략 선호는 저장소 규칙·스킬·하네스에 넣고, 전술 선호는 프로젝트의 중요한 20%에 집중해 명령형으로 적는 편이 실용적이다"],"related":["posts/fable-finding-unknowns","posts/loop-engineering","posts/agent-harness-engineering","posts/agents-cant-choose-structure-flexibility"]},{"title":"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-07T19:12:31+09:00","lastmod":"2026-07-07T19:12:31+09:00","description":"Addy Osmani의 Agentic Autonomy Levels는 AI 에이전트 활용을 0~5단계로 나누고, 더 높은 자율성보다 더 강한 검증·되돌리기·범위 통제가 먼저 필요하다고 말한다.","summary":"Addy Osmani의 2026년 7월 글 **\u0026ldquo;Agentic Autonomy Levels\u0026rdquo;**는 AI 코딩 에이전트에게 일을 맡길 때 필요한 기준을 다룹니다. 핵심은 단순합니다. 에이전트가 더 많이 할 수 있다는 사실과, 실제로 더 많이 맡겨도 된다는 판단은 별개입니다.\n원문: X article / Substack 공개본\n핵심 핵심 정리 두 축: 단일 에이전트가 얼마나 멀리 가는지(agency)와 여러 에이전트를 얼마나 잘 조율하는지(orchestration)를 분리해서 봐야 한다. 6단계: Assist, Supervised action, Scoped task delegation, Goal-driven autonomy, Parallel delegation, Managed-by-exception orchestration으로 올라간다. 판단 기준: 높은 자율성은 \u0026ldquo;믿어도 된다\u0026quot;가 아니라 \u0026ldquo;틀렸을 때 빨리 알고, 쉽게 되돌리고, 독립 증거로 확인할 수 있다\u0026quot;에 가깝다. 실무 계약: 목표, 범위, 비목표, 권한, 중단 조건, 증거, 에스컬레이션, 예산을 작업 전에 정해야 한다. 최종 병목: 에이전트 시대에도 병목은 실행이 아니라 검증이다. 1) 자율성은 한 줄짜리 등급이 아니다 기존에는 \u0026ldquo;AI-native 수준\u0026quot;을 하나의 사다리로 표현하는 방식이 많았습니다. 하지만 Addy는 이제 그 방식만으로는 부족하다고 말합니다.\n","content":"Addy Osmani의 2026년 7월 글 **\u0026ldquo;Agentic Autonomy Levels\u0026rdquo;**는 AI 코딩 에이전트에게 일을 맡길 때 필요한 기준을 다룹니다. 핵심은 단순합니다. 에이전트가 더 많이 할 수 있다는 사실과, 실제로 더 많이 맡겨도 된다는 판단은 별개입니다.\n원문: X article / Substack 공개본\n핵심 핵심 정리 두 축: 단일 에이전트가 얼마나 멀리 가는지(agency)와 여러 에이전트를 얼마나 잘 조율하는지(orchestration)를 분리해서 봐야 한다. 6단계: Assist, Supervised action, Scoped task delegation, Goal-driven autonomy, Parallel delegation, Managed-by-exception orchestration으로 올라간다. 판단 기준: 높은 자율성은 \u0026ldquo;믿어도 된다\u0026quot;가 아니라 \u0026ldquo;틀렸을 때 빨리 알고, 쉽게 되돌리고, 독립 증거로 확인할 수 있다\u0026quot;에 가깝다. 실무 계약: 목표, 범위, 비목표, 권한, 중단 조건, 증거, 에스컬레이션, 예산을 작업 전에 정해야 한다. 최종 병목: 에이전트 시대에도 병목은 실행이 아니라 검증이다. 1) 자율성은 한 줄짜리 등급이 아니다 기존에는 \u0026ldquo;AI-native 수준\u0026quot;을 하나의 사다리로 표현하는 방식이 많았습니다. 하지만 Addy는 이제 그 방식만으로는 부족하다고 말합니다.\n이유는 두 가지입니다.\nAgency: 하나의 에이전트가 사람에게서 얼마나 멀리 떨어져 독립적으로 일하는가. Orchestration: 여러 에이전트를 얼마나 잘 나누고, 격리하고, 검증하고, 다시 합치는가. 예전에는 한 명의 에이전트를 얼마나 믿을 수 있는지가 핵심이었습니다. 이제는 여러 에이전트를 동시에 돌릴 수 있기 때문에, 개별 에이전트의 능력과 에이전트 무리를 운영하는 능력을 분리해서 봐야 합니다.\n2) 세 시대와 여섯 단계 Addy는 0~5단계를 제시합니다. 숫자가 높을수록 좋은 것이 아니라, 그 작업이 감당할 수 있는 자율성의 상한을 뜻합니다.\nLevel 0: Assist 에이전트는 제안만 합니다. 자동완성, 인라인 수정 제안, 채팅에서 아이디어를 주고받는 수준입니다.\n사람이 판단을 형성해야 하거나, 작은 실수도 비싼 영역에서는 이 단계가 맞습니다.\nLevel 1: Supervised action 에이전트가 편집이나 명령 실행을 대신하지만, 중요한 행동 전에는 사람에게 묻습니다.\n대부분의 개발자가 기본으로 쓰는 방식입니다. 단점은 승인 피로입니다. 승인 요청이 많아질수록 사람은 실제 위험을 구분하지 못하고 기계적으로 허용하게 됩니다.\nLevel 2: Scoped task delegation 명확한 목표, 제약, 완료 조건이 있는 작업을 에이전트에게 맡깁니다.\n사람은 곁에 있지만 매 순간 개입하지 않습니다. 이때부터 중요한 것은 에이전트의 말이 아니라 테스트, 타입 체크, 린트, 스크린샷, 재현 절차 같은 증거입니다.\nLevel 3: Goal-driven autonomy 에이전트가 목표를 달성할 때까지 계획하고, 실행하고, 테스트하고, 다시 시도합니다.\n단, 목표는 측정 가능해야 합니다. \u0026ldquo;UX를 개선해줘\u0026rdquo; 같은 말은 위험합니다. \u0026ldquo;이 페이지의 time-to-interactive를 1초 아래로 낮춰줘\u0026quot;처럼 자동으로 확인 가능한 조건이 있어야 합니다.\nLevel 4: Parallel delegation 여러 에이전트가 병렬로 일합니다. 각 에이전트는 격리된 worktree나 별도 세션에서 자기 몫을 처리합니다.\n여기서 가장 어려운 일은 코딩이 아니라 쪼개기입니다. 잘못 나누면 병렬 처리가 아니라 충돌, 중복 결정, 리뷰 폭증만 생깁니다.\nLevel 5: Managed-by-exception orchestration 매니저 에이전트가 트리거나 이슈 큐를 보고 작업을 배분하고, 진행 상황을 감시하고, 실패 시 재시도하거나 사람에게 올립니다.\n사람은 모든 단계를 지휘하지 않고, 예외와 중요한 결정에만 개입합니다. 이 단계에서는 독립 검증이 필수입니다. 구현 에이전트와 리뷰 에이전트, 테스트 실행자, 보안 검사, 승인 게이트가 분리되어야 합니다.\n3) 위험과 되돌리기가 상한을 정한다 Addy의 가장 중요한 메시지는 이것입니다.\n자율성 수준은 작업 이름이 아니라 검증 체계가 정한다.\n문서 자동화처럼 쉬워 보이는 작업도 기준 정보가 없고 검증이 약하면 높은 자율성을 주기 어렵습니다. 반대로 결제 엔진 리팩터링처럼 위험해 보이는 작업도 강한 테스트, 독립 리뷰, 빠른 롤백 경로가 있으면 더 높은 수준으로 운영할 수 있습니다.\n따라서 질문은 \u0026ldquo;이 작업을 AI에게 맡길 수 있나?\u0026ldquo;가 아닙니다.\n다음 세 가지를 먼저 물어야 합니다.\n틀렸을 때 얼마나 빨리 알 수 있는가? 잘못된 변경을 얼마나 깨끗하게 되돌릴 수 있는가? 성공했다는 것을 무엇으로 증명할 수 있는가? 답이 \u0026ldquo;늦게 안다, 되돌리기 어렵다, 에이전트의 말만 믿는다\u0026quot;라면 높은 자율성이 아닙니다.\n4) 에이전트 실행 전 계약이 필요하다 원문은 모든 에이전트 실행 전에 작은 계약이 있어야 한다고 말합니다.\n목표: 활동이 아니라 달성할 결과. 범위: 어디에서 무엇을 해도 되는지. 비목표: 이번 작업에서 하지 않을 것. 도구와 권한: 어떤 명령, 파일, 외부 시스템에 접근할 수 있는지. 중단 조건: 언제 멈춰야 하는지. 증거: 테스트, 로그, 스크린샷, DB 레코드처럼 독립 확인 가능한 자료. 에스컬레이션: 어떤 상황에서 사람에게 올릴지. 예산: 시간, 토큰, 재시도 횟수, 병렬 에이전트 수의 한도. 이 계약이 없으면 에이전트는 열심히 움직일 수는 있지만, 사람이 나중에 판단할 수 있는 흔적을 남기지 못합니다.\n5) 네 가지 실패 패턴 원문은 자율성 운영에서 흔한 안티패턴도 짚습니다.\nAutonomy as status 높은 자율성 등급을 능력의 배지처럼 여기는 것입니다. 하지만 높은 단계는 자랑이 아니라 책임입니다. 검증이 받쳐주지 않으면 낮은 단계가 더 성숙한 선택입니다.\nPermission laundering 승인 요청이 귀찮아져서 권한을 크게 열어주는 문제입니다. 해결책은 더 많은 믿음이 아니라, sandbox, allowlist, scoped writable root, hook, Auto-review 같은 좁은 경계입니다.\nReview substitution 에이전트의 완료 보고를 리뷰처럼 받아들이는 문제입니다. 필요한 것은 말이 아니라 diff, 테스트 결과, 로그, 스크린샷, 리뷰 발견사항, 남은 리스크입니다.\nFleet cosplay 여러 에이전트를 돌리지만, 사람이 모든 의존성과 상태를 손으로 조율하는 상태입니다. 겉보기에는 병렬 운영이지만 실제로는 사람의 조율 비용만 커집니다.\n6) 올라가는 방법 가장 안전한 방법은 한 번에 한 축만 올리는 것입니다.\n처음에는 단일 에이전트에게 작은 작업을 맡기고, 통과 기준을 명확히 둡니다. 그다음 읽기 중심 탐색을 병렬화합니다. 이후 파일 소유권이 분리되는 작업을 worktree로 나눕니다. 마지막으로 반복 작업과 이슈 기반 오케스트레이션을 추가합니다.\n핵심은 \u0026ldquo;더 믿기\u0026quot;가 아닙니다.\n범위를 좁히고, 증거를 강화하고, 되돌리기를 싸게 만들고, 게이트를 단단하게 하는 것입니다.\n결론 및 시사점 한 줄 결론: AI 에이전트에게 더 많은 자율성을 주려면, 먼저 더 강한 검증과 더 쉬운 롤백을 설계해야 한다.\nAgentic Autonomy Levels의 실무 가치는 단계표 자체보다 사고방식에 있습니다. 높은 단계로 가는 것이 목표가 아니라, 작업의 위험과 되돌리기 가능성에 맞는 수준을 고르는 것이 목표입니다.\nAI 코딩 도구가 강해질수록 사람의 역할은 모든 명령을 직접 내리는 쪽에서, 목표·경계·증거·예외 처리를 설계하는 쪽으로 이동합니다. 결국 성숙한 팀은 에이전트를 무작정 자동화하지 않습니다. 검증 가능한 만큼만 자동화합니다.\n","wordCount":828,"tags":["AI","에이전트","Agentic-Autonomy","Addy-Osmani","Codex","Claude-Code","검증"],"categories":["AI"],"frameworks":["Agentic Autonomy Levels","Calibrated Autonomy","Verification-first Delegation"],"mental_models":["Risk and Reversibility","Management by Exception","Orchestration Tax"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["AI 에이전트 자율성은 단일 사다리가 아니라 단일 에이전트의 agency와 여러 에이전트를 조율하는 orchestration이라는 두 축으로 봐야 한다","0~2단계는 사람 주도와 제한된 위임, 3단계는 측정 가능한 목표 기반 실행, 4~5단계는 병렬 위임과 예외 중심 운영에 가깝다","높은 자율성의 조건은 신뢰가 아니라 빠른 오류 감지, 쉬운 롤백, 독립적인 증거다","작업 전에는 목표·범위·비목표·권한·중단 조건·증거·에스컬레이션·예산을 계약처럼 정해야 한다","검증은 항상 병목이므로 성숙한 팀은 에이전트를 더 뜨겁게 돌리기보다 자율성 수준을 보수적으로 보정한다"],"related":["posts/loop-engineering","posts/agentic-code-review-addy-osmani","posts/agent-skills-addy-osmani","posts/agent-harness-engineering"]},{"title":"A Field Guide to Fable — 좋은 AI 결과는 모르는 것을 찾는 능력에서 나온다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/fable-finding-unknowns/","section":"posts","date":"2026-07-07T19:11:53+09:00","lastmod":"2026-07-07T19:11:53+09:00","description":"Thariq Shihipar의 'A Field Guide to Fable: Finding Your Unknowns'를 바탕으로, 강한 AI 모델을 잘 쓰는 핵심이 더 긴 지시문이 아니라 unknowns를 발견하고 줄이는 과정이라는 점을 정리했다.","summary":"원문: A Field Guide to Fable: Finding Your Unknowns\n참고: Know your unknowns — examples\nFable 핵심 정리 핵심 주장: Fable급 모델에서는 \u0026ldquo;모델이 충분히 똑똑한가\u0026quot;보다 \u0026ldquo;내가 작업의 빈칸을 충분히 드러냈는가\u0026quot;가 결과를 좌우한다.\n지도와 영토: prompt, skill, context는 지도이고 실제 코드베이스, 사용자 요구, 운영 제약은 영토다. 두 사이의 간격이 unknowns다.\n네 가지 분류: known knowns, known unknowns, unknown knowns, unknown unknowns로 나누면 AI가 어디서 추측하게 되는지 보인다.\n실무 방법: 구현 전에는 blindspot pass와 인터뷰, 구현 중에는 변경 기록, 구현 후에는 pitch나 quiz로 숨은 가정을 다시 꺼낸다. 1) 문제는 더 긴 prompt가 아니다 Thariq Shihipar의 글은 \u0026ldquo;AI에게 일을 잘 시키는 법\u0026quot;처럼 보이지만, 핵심은 단순한 prompt 기술이 아닙니다. 더 정확히는 내가 무엇을 모르는지 AI와 함께 발견하는 법에 가깝습니다.\n","content":"원문: A Field Guide to Fable: Finding Your Unknowns\n참고: Know your unknowns — examples\nFable 핵심 정리 핵심 주장: Fable급 모델에서는 \u0026ldquo;모델이 충분히 똑똑한가\u0026quot;보다 \u0026ldquo;내가 작업의 빈칸을 충분히 드러냈는가\u0026quot;가 결과를 좌우한다.\n지도와 영토: prompt, skill, context는 지도이고 실제 코드베이스, 사용자 요구, 운영 제약은 영토다. 두 사이의 간격이 unknowns다.\n네 가지 분류: known knowns, known unknowns, unknown knowns, unknown unknowns로 나누면 AI가 어디서 추측하게 되는지 보인다.\n실무 방법: 구현 전에는 blindspot pass와 인터뷰, 구현 중에는 변경 기록, 구현 후에는 pitch나 quiz로 숨은 가정을 다시 꺼낸다. 1) 문제는 더 긴 prompt가 아니다 Thariq Shihipar의 글은 \u0026ldquo;AI에게 일을 잘 시키는 법\u0026quot;처럼 보이지만, 핵심은 단순한 prompt 기술이 아닙니다. 더 정확히는 내가 무엇을 모르는지 AI와 함께 발견하는 법에 가깝습니다.\n모델이 약할 때는 결과가 나쁜 이유를 모델 한계로 돌리기 쉬웠습니다. 하지만 Fable처럼 강한 모델에서는 상황이 달라집니다. 모델이 많은 일을 할 수 있기 때문에, 사용자가 남긴 빈칸도 더 멀리 증폭됩니다. 불분명한 요구, 말하지 않은 취향, 코드베이스의 역사적 제약, 실제 사용자 흐름이 모두 결과에 영향을 줍니다.\n그래서 좋은 결과의 핵심 질문은 \u0026ldquo;어떻게 더 자세히 지시할까?\u0026ldquo;가 아니라 \u0026ldquo;AI가 어디에서 내 의도를 추측하게 될까?\u0026rdquo; 입니다.\n2) 지도는 영토가 아니다 글의 중심 비유는 간단합니다.\n지도: 내가 AI에게 주는 prompt, skill, context, 문서 영토: 실제 작업이 벌어지는 코드베이스, 제품, 사용자, 운영 환경, 조직의 암묵지 unknowns: 지도와 영토 사이의 차이 AI는 지도를 보고 영토를 걸어갑니다. 그런데 지도에 없는 지형을 만나면 멈추지 않고 추측합니다. 대부분의 agent 실패는 여기서 생깁니다. 모델이 멍청해서가 아니라, 추측해야 하는 지점이 너무 많았기 때문입니다.\n큰 작업일수록 이 차이는 커집니다. 작은 copy 수정은 빈칸이 적지만, 인증 모듈 교체, 제품 flow 재설계, 긴 영상 편집, 복잡한 refactor는 AI가 수십 번의 암묵적 결정을 내려야 합니다.\n3) unknowns를 네 칸으로 나누기 Thariq는 문제를 네 가지로 나눕니다.\n구분 의미 예시 Known knowns 내가 알고 있고 AI에게 말한 것 \u0026ldquo;새 인증 provider를 추가해줘\u0026rdquo; Known unknowns 내가 아직 모른다는 사실을 아는 것 \u0026ldquo;데이터 모델은 아직 확신이 없어\u0026rdquo; Unknown knowns 나는 알지만 말하지 않은 것 \u0026ldquo;이 UI는 우리 제품답지 않아\u0026rdquo; Unknown unknowns 내가 모른다는 사실도 모르는 것 \u0026ldquo;이 모듈에는 오래된 edge case가 있다\u0026rdquo; 가장 다루기 쉬운 것은 known knowns입니다. 이미 prompt 안에 들어 있기 때문입니다. known unknowns도 비교적 낫습니다. \u0026ldquo;여기는 아직 모른다\u0026quot;고 말할 수 있으니 AI에게 탐색을 맡길 수 있습니다.\n문제는 unknown knowns와 unknown unknowns입니다. 사용자는 자기 취향, 팀 관습, 코드 냄새, 제품 감각을 너무 당연하게 여겨 적지 않습니다. 혹은 어떤 질문을 해야 하는지조차 모릅니다. AI는 그 부분을 모른 채 합리적인 기본값으로 채웁니다. 그 기본값이 틀리면 결과는 \u0026ldquo;그럴듯하지만 아닌 것\u0026quot;이 됩니다.\n4) 바로 구현하지 말고 먼저 빈칸을 찾기 글에서 가장 실용적인 도구는 blindspot pass입니다. 낯선 코드 모듈이나 익숙하지 않은 작업을 시작할 때, AI에게 바로 구현을 맡기지 않고 먼저 이렇게 요청하는 방식입니다.\n지금 내가 모를 가능성이 큰 unknown unknowns를 찾아주고, 더 나은 지시문을 쓰려면 어떤 맥락을 보충해야 하는지 알려줘.\n이 한 단계는 구현보다 싸고, 실패한 구현을 되돌리는 것보다 훨씬 싸습니다. 특히 다음 상황에서 유용합니다.\n낯선 코드베이스 영역에 들어갈 때 디자인, 영상, 데이터 분석처럼 \u0026ldquo;좋은 결과\u0026quot;의 기준을 내가 잘 모를 때 팀 내부 관습이나 과거 결정이 결과에 영향을 줄 때 문제 자체를 다른 방식으로 풀어야 할 가능성이 있을 때 AI에게 물어볼 일은 \u0026ldquo;정답을 만들어줘\u0026quot;만이 아닙니다. \u0026ldquo;내가 빠뜨린 질문을 찾아줘\u0026quot;가 먼저일 때가 많습니다.\n5) 구현 전, 중, 후에 계속 발견하기 Thariq가 강조하는 또 하나의 포인트는 planning만으로 충분하지 않다는 점입니다. unknowns는 구현 전에만 있는 것이 아닙니다.\n구현 전에는 blindspot pass, brainstorm, prototype, interview, reference가 효과적입니다. 말로 설명하기 어려운 취향이나 판단 기준은 여러 시안을 보면서 더 잘 드러납니다. \u0026ldquo;이건 아니고, 저쪽이 더 가깝다\u0026quot;는 반응 자체가 unknown knowns를 밖으로 꺼냅니다.\n구현 중에는 AI가 계획에서 벗어난 지점을 기록하게 해야 합니다. 실제 파일을 읽고 나서 계획과 코드가 맞지 않는 경우, 그 차이를 그냥 덮고 가면 다음 시도도 같은 곳에서 흔들립니다. 짧은 implementation notes만 남겨도 두 번째 시도는 훨씬 좋아집니다.\n구현 후에는 pitch나 quiz가 도움이 됩니다. AI에게 \u0026ldquo;왜 이렇게 만들었는지 이해관계자에게 설명해봐\u0026rdquo; 또는 \u0026ldquo;내가 merge 전에 확인해야 할 질문을 내봐\u0026quot;라고 시키면, 구현 과정에서 숨어 있던 가정이 다시 표면으로 올라옵니다.\n6) agentic work의 핵심 능력 이 글이 중요한 이유는 AI 활용을 \u0026ldquo;prompt 잘 쓰기\u0026quot;보다 넓게 보기 때문입니다. 좋은 agentic work는 명령문 작성이 아니라 문제 공간을 함께 정렬하는 과정입니다.\n강한 모델은 단순 실행자가 아니라 탐색 파트너가 될 수 있습니다. 코드베이스를 빠르게 읽고, 분야 지식을 끌어오고, 대안을 만들고, 사용자가 몰랐던 질문을 제안할 수 있습니다. 다만 그러려면 처음부터 \u0026ldquo;내가 어느 정도 알고 있고, 무엇을 모를 수 있으며, 어떤 종류의 판단을 함께 해주길 원하는지\u0026quot;를 알려줘야 합니다.\n결국 고급 사용자는 AI에게 더 많은 일을 시키는 사람이 아닙니다. AI가 추측해야 하는 지점을 줄이고, 추측이 필요한 곳에서는 더 나은 방식으로 탐색하게 만드는 사람입니다.\n결론 및 시사점 한 줄 결론: Fable급 모델을 잘 쓰는 능력은 완벽한 지시문을 한 번에 쓰는 능력이 아니라, 작업 전·중·후에 unknowns를 계속 발견하고 줄이는 능력이다.\n실무에서는 다음 한 문장부터 적용하면 됩니다.\n바로 구현하지 말고, 먼저 이 작업의 blindspot pass를 해줘. 내가 모를 가능성이 큰 unknown unknowns와 더 나은 지시문에 필요한 맥락을 찾아줘.\nAI가 강해질수록 결과의 병목은 점점 사람 쪽으로 이동합니다. 하지만 그것이 부담만 뜻하지는 않습니다. 오히려 AI에게 \u0026ldquo;내가 모르는 것을 찾는 일\u0026quot;까지 맡길 수 있다면, 더 좋은 결과는 더 긴 지시문이 아니라 더 짧고 빠른 탐색 루프에서 나옵니다.\n","wordCount":807,"tags":["AI","Claude","Fable","에이전트","프롬프트","소프트웨어엔지니어링"],"categories":["AI"],"frameworks":["Known Unknowns","Blindspot pass","Iterative implementation"],"mental_models":["The map is not the territory","Assumption surfacing","Feedback loops"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Thariq Shihipar는 Fable급 모델에서 작업 품질의 병목이 모델 성능보다 사용자가 unknowns를 얼마나 잘 드러내는가로 이동한다고 본다","prompt, skill, context는 지도이고 실제 코드베이스와 제약은 영토이며, 둘 사이의 간격이 AI가 추측해야 하는 unknowns다","unknowns는 known knowns, known unknowns, unknown knowns, unknown unknowns 네 가지로 나눠 다룰 수 있다","blindspot pass, 인터뷰, 프로토타입, 구현 기록, 사후 퀴즈는 AI가 바로 실행하기 전에 문제의 빈칸을 드러내는 저비용 장치다"],"related":["posts/agent-harness-engineering","posts/agents-cant-choose-structure-flexibility","posts/automated-doubt-development-process"]},{"title":"Some New Agentic Patterns - 에이전트가 동료 에이전트를 위해 도구를 고치는 방식","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/some-new-agentic-patterns/","section":"posts","date":"2026-07-07T19:11:34+09:00","lastmod":"2026-07-07T19:11:34+09:00","description":"Jesse Vincent의 글을 바탕으로, Prime Radiant가 구현 에이전트와 장기 실행 동료 에이전트를 직접 대화시켜 도구와 하네스를 개선한 방식을 정리한다.","summary":"Jesse Vincent의 Some new agentic patterns는 에이전트를 더 잘 쓰는 프롬프트 팁이 아니다. 핵심은 에이전트를 위한 제품을 만들 때, 실제 사용자 역할의 에이전트가 구현 에이전트와 직접 대화하게 하는 개발 방식이다.\n원문: Some new agentic patterns\nAgent Loop 핵심 정리 새 패턴: 사람이 중간에서 피드백을 전달하지 않고, Claude Code가 Slackline을 통해 Ada-sen에게 직접 테스트를 요청했다. 사용자 모델: Sen 2.0은 단순 비서가 아니라 자기 도구, 메모리, 작업공간, 자격 증명을 가진 장기 실행 동료 에이전트로 설계된다. 보안 전제: Lethal Trifecta를 완전히 없애는 대신, 외부 통신 권한과 자격 증명 접근을 임시 서브에이전트와 중재자 에이전트로 분리한다. 실무 포인트: 코딩 에이전트에 맞는 컨텍스트 압축은 여러 대화를 동시에 이어가는 페르소나형 에이전트에는 맞지 않을 수 있다. 결과: Ada가 스펙을 검토하고, Claude가 구현하고, Ada가 다시 테스트하면서 품질 개선 목록과 수정 요청까지 생성했다. 1) 배경: Slack 안의 여러 에이전트 Prime Radiant에는 여러 에이전트가 Slack 안에서 일한다. Scribble은 문제 보고와 새 정보를 듣고 티켓을 열거나 내부 위키를 갱신한다. Nora는 go-to-market 업무를 돕는 주니어 동료처럼 행동한다. Spec-together는 멀티플레이어 Brainstorm 앱의 초기 실험이었다.\n","content":"Jesse Vincent의 Some new agentic patterns는 에이전트를 더 잘 쓰는 프롬프트 팁이 아니다. 핵심은 에이전트를 위한 제품을 만들 때, 실제 사용자 역할의 에이전트가 구현 에이전트와 직접 대화하게 하는 개발 방식이다.\n원문: Some new agentic patterns\nAgent Loop 핵심 정리 새 패턴: 사람이 중간에서 피드백을 전달하지 않고, Claude Code가 Slackline을 통해 Ada-sen에게 직접 테스트를 요청했다. 사용자 모델: Sen 2.0은 단순 비서가 아니라 자기 도구, 메모리, 작업공간, 자격 증명을 가진 장기 실행 동료 에이전트로 설계된다. 보안 전제: Lethal Trifecta를 완전히 없애는 대신, 외부 통신 권한과 자격 증명 접근을 임시 서브에이전트와 중재자 에이전트로 분리한다. 실무 포인트: 코딩 에이전트에 맞는 컨텍스트 압축은 여러 대화를 동시에 이어가는 페르소나형 에이전트에는 맞지 않을 수 있다. 결과: Ada가 스펙을 검토하고, Claude가 구현하고, Ada가 다시 테스트하면서 품질 개선 목록과 수정 요청까지 생성했다. 1) 배경: Slack 안의 여러 에이전트 Prime Radiant에는 여러 에이전트가 Slack 안에서 일한다. Scribble은 문제 보고와 새 정보를 듣고 티켓을 열거나 내부 위키를 갱신한다. Nora는 go-to-market 업무를 돕는 주니어 동료처럼 행동한다. Spec-together는 멀티플레이어 Brainstorm 앱의 초기 실험이었다.\n가장 중요한 축은 Sen이다. Sen은 개인 비서 에이전트 집합으로, 메일 분류, 데일리 브리프, 리서치, Linear 상호작용 같은 일을 한다. Slack에서 대화하고, 도구를 쓰고, 스스로 일정에 맞춰 깨어날 수 있으며, 스킬을 사용하고 작성할 수도 있다.\nVincent가 새로 만드는 Sen 2.0은 \u0026ldquo;비서\u0026quot;보다 \u0026ldquo;동료\u0026quot;에 가깝다. 이 차이가 중요하다. 비서는 사용자의 계정과 권한을 빌려 쓰는 존재로 상상되기 쉽지만, 동료라면 자기 계정과 자기 권한을 가져야 한다.\n2) 자격 증명은 공유가 아니라 분리 문제다 원문에서 가장 현실적인 부분은 보안 설계다. Vincent는 에이전트가 사람의 GitHub나 이메일 계정을 그대로 공유해서는 안 된다고 본다. 회사 동료에게 내 이메일 비밀번호를 넘기지 않는 것과 같은 이유다.\n문제는 Simon Willison이 말한 Lethal Trifecta다. 하나의 에이전트가 비공개 정보에 접근할 수 있고, 외부로 통신할 수 있으며, 신뢰할 수 없는 콘텐츠에도 노출된다면 완전한 구조적 안전을 보장하기 어렵다. 그래서 목표는 완전 제거가 아니라 분리와 위험 축소다.\n현재 설계는 단순하다.\n주 에이전트는 직접 외부 통신을 하지 못한다. 외부 통신이 필요한 일은 임시 서브에이전트가 맡는다. 자격 증명은 1Password vault에 두고, 에이전트 transcript에는 직접 노출하지 않는다. 서브에이전트가 자격 증명을 요구하면 별도 컨테이너의 arbiter 에이전트가 요청을 판단한다. 허용되면 임시 문자열을 주고, outbound HTTPS 프록시가 적절한 원격 호스트로 나가는 요청에서만 실제 자격 증명으로 바꾼다. 브라우저 로그인은 더 까다롭다. 사이트 JavaScript가 비밀번호를 해시하거나 다른 백엔드로 보내는 경우가 있기 때문이다. 그래서 원문에서는 임시 비밀번호를 입력한 뒤, 중재자가 별도 helper를 통해 실제 값으로 교체하는 방식을 첫 단계 해법으로 쓴다. 완벽하진 않지만, 에이전트가 자격 증명을 읽거나 실수로 흘리는 위험은 줄인다.\n3) 진짜 패턴: 에이전트 사용자가 직접 피드백한다 글의 핵심은 이 보안 아키텍처 자체가 아니라, 그것을 만들던 개발 루프다.\nVincent는 Claude Code 세션을 Slackline에 연결했다. Slackline은 Slack 안에 살지 않는 에이전트가 대화에 참여할 수 있게 만든 커맨드라인 도구다. 사람이 터미널에서 Slack을 쓰는 용도도 가능하지만, 본질적으로는 에이전트가 메시지를 보내고, 채팅을 읽고, 답장을 기다리도록 만든 도구다.\nSen 2.0이 Slack에서 살아 움직이기 시작하자 문제가 빨리 드러났다. 예를 들어 코딩 에이전트에게 좋은 컨텍스트 압축 방식은, 여러 대화를 동시에 이어가는 장기 실행 페르소나에게는 맞지 않았다. 자격 증명 프록시도 실제로 GitHub 로그인을 시도해야만 깨지는 지점이 보였다.\n보통이라면 사람인 Vincent가 Ada-sen에게 물어보고, 그 내용을 Claude Code에게 전달했을 것이다. 하지만 그는 중간에 자신이 있을 이유가 별로 없다고 판단했다. 그래서 Claude Code에게 Slackline으로 Ada-sen과 직접 이야기하라고 시켰다.\n이후 루프는 이렇게 돌았다.\nClaude가 Ada에게 방금 만든 기능을 설명하고 테스트를 요청한다. Ada가 서브에이전트를 띄워 GitHub 로그인 같은 실제 작업을 시도한다. Claude가 로그를 보고 프록시나 도구가 제대로 동작했는지 확인한다. Claude가 수정안을 제안하면 Ada가 스펙을 검토하고 우려를 말한다. 합의되면 Claude가 새 버전을 만들고, Ada가 작업 중이 아닌지 확인한 뒤 배포한다. Ada가 다시 테스트하고, 더 쓰기 쉽게 만들 기능을 요청한다. 이것이 \u0026ldquo;agentic user in the loop\u0026quot;다. 사람 사용자가 루프에 들어가는 것이 아니라, 실제 사용자 역할의 에이전트가 루프에 들어간다.\n4) 왜 중요한가 첫째, 도구의 실제 사용자가 사람이라고 가정하지 않는다. Slackline은 사람이 쓰기 편한 CLI를 에이전트가 우연히 사용하는 형태가 아니다. 처음부터 에이전트가 Slack 대화에 참여하기 위한 도구다. 이 관점에서는 JSON 출력, 대기, 답장 읽기, 대화 맥락 유지가 UI만큼 중요해진다.\n둘째, 에이전트 제품의 dogfooding 방식이 바뀐다. 사람이 \u0026ldquo;이 부분이 불편하다\u0026quot;고 말하는 대신, 장기 실행 에이전트가 직접 하위 에이전트를 띄워 기능을 시험하고 실패 지점을 보고한다. 구현 에이전트는 그 피드백을 스펙으로 바꾸고, 다시 배포하고, 다시 묻는다.\n셋째, 하네스 품질의 기준이 모델 성능에서 운영 경험으로 이동한다. 컨텍스트 압축, 메모리, 자격 증명, 작업공간, 배포 타이밍, 도구 affordance가 모두 제품 품질이 된다. 모델이 똑똑해도 이 층이 엉성하면 장기 실행 에이전트는 금방 막힌다.\n넷째, 사람의 병목을 줄인다. 원문에서 Vincent는 잠들기 전 Claude에게 프로젝트가 끝나면 Ada와 사용성 개선점을 확인하라고 했다. 다음 날에는 Ada가 요청 목록을 만들고, Claude가 스펙을 작성하고, Ada가 검토하고, Claude가 구현하고, Ada가 다시 수정을 요구한 결과가 남아 있었다.\n5) 실무에서 가져갈 점 에이전트용 제품을 만든다면 \u0026ldquo;사람이 에이전트를 평가한다\u0026quot;에서 멈추면 안 된다. 실제 사용자 역할의 에이전트가 자기 도구를 써보고, 실패하고, 불편함을 말할 수 있는 통로가 필요하다.\n다만 이 패턴은 보안 문제를 자동으로 해결하지 않는다. 오히려 장기 실행 에이전트가 도구와 권한을 갖기 시작하면, 권한 분리와 감사 가능성이 더 중요해진다. 주 에이전트, 서브에이전트, 자격 증명 중재자, 네트워크 프록시처럼 책임을 작게 나누는 설계가 먼저 있어야 한다.\n또 하나의 함정은 \u0026ldquo;에이전트가 원한다\u0026quot;는 말을 곧바로 제품 요구사항으로 믿는 것이다. Ada의 피드백은 강력한 신호지만, 여전히 운영 로그, 실패 사례, 보안 경계와 함께 봐야 한다. 좋은 루프는 에이전트의 의견을 절대화하지 않고, 실제 행동과 결과로 검증한다.\n결론 및 시사점 Jesse Vincent의 글이 보여주는 변화는 에이전트 개발의 무게중심이 프롬프트에서 하네스와 운영 루프로 옮겨가고 있다는 점이다. 앞으로의 에이전트 제품은 \u0026ldquo;모델에게 무엇을 말할까\u0026quot;보다 \u0026ldquo;에이전트가 어떤 권한으로, 어떤 도구를 쓰며, 실패를 누구에게 어떻게 보고하고, 누가 다시 고치는가\u0026quot;를 더 많이 다루게 된다.\n특히 강력한 지점은 사람을 완전히 빼자는 주장이 아니라, 사람이 중계자 역할을 할 필요가 없는 반복 작업을 에이전트끼리 직접 돌렸다는 데 있다. 사람은 방향과 경계를 정하고, 에이전트들은 사용 경험의 작은 마찰을 발견해 고친다. 이 구조가 잘 작동하면 에이전트 하네스는 더 빨리, 더 실제적인 방식으로 좋아질 수 있다.\n한 줄 결론: 에이전트를 위한 도구는 실제 에이전트 사용자가 구현 에이전트와 직접 피드백 루프를 돌릴 때 가장 빠르게 좋아진다.\n","wordCount":925,"tags":["AI","에이전트","agentic-engineering","agent-harness","Slack"],"categories":["AI"],"frameworks":["Agentic User in the Loop","Dogfooding","Compartmentalization"],"mental_models":["Feedback Loop","Least Privilege","Socio-technical Systems"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Prime Radiant의 새 패턴은 사람이 피드백을 중계하지 않고, 구현 에이전트가 실제 사용자 역할의 장기 실행 에이전트와 직접 대화하며 도구를 고치는 방식이다.","Sen 2.0은 사람의 계정을 빌려 쓰는 비서가 아니라, 자기 자격 증명을 가진 동료에 가깝게 설계된다.","자격 증명 설계는 Lethal Trifecta를 완전히 해결하지 못한다는 전제에서, 주 에이전트와 외부 통신 가능한 임시 서브에이전트를 분리해 위험을 줄인다.","Slackline은 사람이 쓰는 CLI가 아니라 Slack에 살지 않는 에이전트가 대화에 참여하도록 만든 에이전트 우선 도구다.","Claude Code와 Ada-sen의 루프는 스펙 검토, 구현, 배포, 재실험, 사용성 개선 요청까지 사람 없이 며칠 동안 반복됐다."],"related":["posts/agent-harness-engineering","posts/anatomy-of-an-agent-harness","posts/all-your-agents-are-going-async","posts/components-of-a-coding-agent"]},{"title":"AI 시대, 주니어 개발자 시장에 생긴 균열","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-junior-programmer-market-collapse/","section":"posts","date":"2026-07-07T16:41:36+09:00","lastmod":"2026-07-07T16:41:36+09:00","description":"AI가 주니어 개발자 채용 시장을 흔드는 동시에 소프트웨어 제작 능력을 더 넓은 직군으로 퍼뜨리고 있다는 Laurie Voss의 분석을 정리한다.","summary":"Laurie Voss는 AI가 프로그래밍이라는 직업을 없애고 있다기보다, 주니어 개발자가 성장하던 기존 경로를 먼저 무너뜨리고 있다고 본다. 동시에 소프트웨어를 만드는 능력은 마케터, 창업자, 교사, 분석가, PM 같은 더 넓은 직군으로 퍼지고 있다.\n원문: AI has torched the market for junior programmers\nTL;DR 핵심 정리 주니어 시장의 충격이 가장 크다: Stanford Digital Economy Lab의 ADP 급여 데이터 기준 22~25세 개발자 고용은 2022년 말 고점 대비 19% 감소했다. 평균 지표는 착시를 만든다: 전체 소프트웨어 개발자 고용은 늘었지만, 주니어가 전체 개발자 중 작은 비중이라 평균만 보면 하락이 잘 보이지 않는다. 코드 작성 자체보다 판단의 가치가 커졌다: 명세대로 코드를 쓰는 역할은 줄고, 어떤 문제를 풀지 정하고 결과를 검증하는 역할은 상대적으로 강해지고 있다. 새로운 제작자는 이미 등장했다: GitHub 신규 계정, App Store 신규 제출, Vercel·Lovable·Replit 사용량은 비개발자도 AI로 소프트웨어를 만들기 시작했음을 보여준다. 가장 큰 위험은 성장 사다리의 단절이다: AI가 초급 코드를 대신 쓰면, 신입이 리뷰와 반복을 통해 시니어로 자라는 경로가 약해진다. 핵심 주장 이 글의 핵심은 \u0026ldquo;프로그래밍이 죽었다\u0026quot;가 아닙니다. 더 정확히는 프로그래밍이 특정 직함에서 보편 능력으로 이동하고 있다는 주장입니다.\n","content":"Laurie Voss는 AI가 프로그래밍이라는 직업을 없애고 있다기보다, 주니어 개발자가 성장하던 기존 경로를 먼저 무너뜨리고 있다고 본다. 동시에 소프트웨어를 만드는 능력은 마케터, 창업자, 교사, 분석가, PM 같은 더 넓은 직군으로 퍼지고 있다.\n원문: AI has torched the market for junior programmers\nTL;DR 핵심 정리 주니어 시장의 충격이 가장 크다: Stanford Digital Economy Lab의 ADP 급여 데이터 기준 22~25세 개발자 고용은 2022년 말 고점 대비 19% 감소했다. 평균 지표는 착시를 만든다: 전체 소프트웨어 개발자 고용은 늘었지만, 주니어가 전체 개발자 중 작은 비중이라 평균만 보면 하락이 잘 보이지 않는다. 코드 작성 자체보다 판단의 가치가 커졌다: 명세대로 코드를 쓰는 역할은 줄고, 어떤 문제를 풀지 정하고 결과를 검증하는 역할은 상대적으로 강해지고 있다. 새로운 제작자는 이미 등장했다: GitHub 신규 계정, App Store 신규 제출, Vercel·Lovable·Replit 사용량은 비개발자도 AI로 소프트웨어를 만들기 시작했음을 보여준다. 가장 큰 위험은 성장 사다리의 단절이다: AI가 초급 코드를 대신 쓰면, 신입이 리뷰와 반복을 통해 시니어로 자라는 경로가 약해진다. 핵심 주장 이 글의 핵심은 \u0026ldquo;프로그래밍이 죽었다\u0026quot;가 아닙니다. 더 정확히는 프로그래밍이 특정 직함에서 보편 능력으로 이동하고 있다는 주장입니다.\n과거에는 회사가 주니어 개발자를 고용해 비교적 단순한 코드를 쓰게 하고, 시니어가 그 코드를 리뷰하면서 실력을 키웠습니다. 하지만 AI 코딩 도구가 그 단순한 코드 작성 영역을 빠르게 대체하면서, 회사가 초급 개발자를 뽑을 이유가 약해졌습니다.\n그 결과 주니어 채용 시장은 크게 위축됐지만, 소프트웨어 제작 자체는 오히려 더 넓어졌습니다. 문제는 생산량이 아니라 품질을 판단하고 책임질 사람을 어떻게 길러낼 것인가입니다.\n주니어 개발자 시장의 급격한 약화 Voss가 인용한 Stanford Digital Economy Lab의 ADP 급여 데이터에 따르면, 22~25세 개발자 고용은 2022년 말 고점 대비 19% 줄었습니다. 반대로 30세 이상 개발자 집단은 같은 기간 증가했습니다.\n이 차이가 중요합니다. 만약 단순히 금리 상승, 팬데믹 이후 채용 조정, 세법 변화, 경기 둔화만 원인이라면 모든 연령대가 비슷하게 타격을 받아야 합니다. 하지만 실제로는 AI로 자동화하기 쉬운 초급 업무와 젊은 개발자에게 충격이 집중됐습니다.\n또한 변화는 ChatGPT 출시 직후 한 번에 벌어진 것이 아닙니다. 원문은 2024년과 2025년 초에 타격이 더 커졌다고 봅니다. 코드 한 줄을 자동완성하던 도구가 티켓 단위의 일을 처리하기 시작한 시점과 겹칩니다.\n평균 수치가 현실을 가리는 이유 전체 소프트웨어 개발자 고용만 보면 상황은 다르게 보입니다. 원문이 인용한 BLS 자료에서는 2022년 5월 153만 명이던 미국 소프트웨어 개발자 고용이 2025년 5월 169만 명으로 늘었습니다.\n이 숫자만 보면 \u0026ldquo;AI가 개발자 일자리를 줄이지 않았다\u0026quot;고 말할 수 있습니다. 하지만 주니어 개발자는 전체 개발자 중 작은 비중입니다. 작은 집단이 크게 흔들려도 전체 평균에서는 잘 보이지 않습니다.\n그래서 두 말은 동시에 참일 수 있습니다.\n전체 개발자 고용은 아직 증가했다. 주니어 개발자 시장은 심하게 약해졌다. 평균만 보면 구조 변화가 늦게 보입니다. 연령대와 역할을 나눠 봐야 실제 충격이 드러납니다.\n사라지는 것은 코드 작성 직무다 원문은 직무명별 변화도 중요하게 봅니다. BLS 기준으로 2024년 5월부터 2025년 5월까지 \u0026ldquo;computer programmer\u0026rdquo; 직군은 16% 줄었고, 웹 개발자와 QA 테스터도 감소했습니다. 반면 데이터 과학자, 시스템 분석가, 넓은 의미의 소프트웨어 개발자 직군은 늘었습니다.\n여기서 줄어드는 일은 주어진 명세에 맞춰 코드를 생산하는 역할입니다. 늘어나는 일은 무엇을 만들지 판단하고, 시스템을 해석하고, 결과를 책임지는 역할입니다.\nAI는 코드 생성을 싸게 만들었습니다. 그래서 코드 작성만으로 정의되는 일은 약해졌습니다. 하지만 문제 정의, 제품 판단, 보안 검토, 운영 책임, 사용자 맥락 이해는 여전히 사람의 판단을 요구합니다.\n새로운 개발자는 직함 밖에서 생긴다 Voss는 자신이 예전에 예측한 \u0026ldquo;더 많은 개발자\u0026quot;가 실제로 나타났다고 봅니다. 다만 그들이 스스로를 개발자라고 부르지 않을 뿐입니다.\n원문에 따르면 GitHub는 최근 Octoverse 기간에 3,600만 개의 신규 계정과 1억 2,100만 개의 신규 저장소를 기록했습니다. App Store 신규 앱 제출도 2025년에 24% 늘었고, 2026년 1분기에는 전년 대비 80% 증가했습니다.\nVercel, Lovable, Replit 같은 도구의 사용자 구성도 같은 방향을 가리킵니다. 많은 사용자는 전통적 의미의 개발자가 아니라, 자기 문제를 해결하려는 실무자입니다. 마케팅 담당자가 직접 대시보드를 만들고, 교사가 수업 도구를 만들고, 창업자가 초기 제품을 직접 구현합니다.\n즉 시장에서 사라지는 것은 소프트웨어 제작 능력이 아닙니다. 사라지는 것은 그 능력이 특정 직함 안에만 머무르던 시대입니다.\n진짜 문제는 다음 세대의 성장 경로다 가장 큰 위험은 단기 고용 통계보다 장기적인 인재 공급입니다.\n전통적인 소프트웨어 엔지니어링은 견습 구조에 가까웠습니다. 신입이 미숙한 코드를 쓰고, 시니어가 리뷰하고, 반복을 통해 판단력을 배웠습니다. 그런데 AI가 미숙한 코드를 대신 쓰면 회사는 신입을 덜 뽑습니다. 그러면 미래의 시니어가 자랄 통로도 좁아집니다.\n동시에 AI로 만든 소프트웨어는 늘어나고 있습니다. 하지만 리뷰, 보안, 운영, 데이터 보호, 제품 책임이 충분히 따라오지 못하면 문제는 나중에 더 비싸게 돌아옵니다.\nVoss가 말하는 해법은 단순히 \u0026ldquo;AI를 쓰지 말자\u0026quot;가 아닙니다. 오히려 AI를 쓰는 시대에 맞게 새로운 견습 구조와 초급 역할을 다시 설계해야 한다는 것입니다.\n실무적으로 봐야 할 변화 기업 입장에서는 주니어 개발자를 단순 코드 생산자로 보면 채용 이유가 약해집니다. 대신 고객 이해, 명세 작성, 테스트 설계, 보안 검토, 운영 감각을 함께 키우는 역할로 재설계해야 합니다.\n개인 입장에서는 \u0026ldquo;코드를 얼마나 빨리 쓰는가\u0026quot;보다 \u0026ldquo;무엇을 만들지, 왜 그렇게 만들지, 어디가 위험한지 설명할 수 있는가\u0026quot;가 더 중요해집니다. AI가 코드를 더 많이 만들수록 사람의 판단력은 더 희소해집니다.\n교육 입장에서는 문법과 구현 과제만으로는 부족합니다. 코드 리뷰, 요구사항 해석, 장애 사례 분석, 보안 기본기, 제품 맥락을 더 일찍 가르쳐야 합니다.\n결론 및 시사점 한 줄 결론: AI는 프로그래밍을 없앤 것이 아니라, 초급 개발자가 성장하던 낡은 사다리를 먼저 흔들었고 이제 우리는 AI 시대에 맞는 새 사다리를 만들어야 한다.\n이 글은 AI 시대의 개발자 시장을 낙관 또는 비관 하나로만 보면 안 된다는 점을 보여줍니다. 소프트웨어 제작은 폭발적으로 쉬워졌지만, 좋은 소프트웨어를 판단하고 책임지는 역량은 자동으로 생기지 않습니다.\n따라서 앞으로 중요한 질문은 \u0026ldquo;AI가 개발자를 대체하는가\u0026quot;가 아닙니다. 더 중요한 질문은 AI가 코드를 쓰는 시대에, 사람은 어디에서 판단력을 배우는가입니다.\n","wordCount":831,"tags":["AI","주니어개발자","소프트웨어개발","노동시장","바이브코딩"],"categories":["AI"],"frameworks":["Second-order thinking","Labor Market Analysis"],"mental_models":["Abstraction Layer","Apprenticeship Model"],"philosophy_type":"technology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Stanford Digital Economy Lab의 ADP 급여 데이터에서 22~25세 소프트웨어 개발자 고용은 2022년 말 고점 대비 19% 줄었다","전체 소프트웨어 개발자 고용은 늘었지만, 주니어 비중이 작아 평균 지표만 보면 충격이 가려진다","사라지는 일은 명세대로 코드를 쓰는 역할이고, 늘어나는 일은 무엇을 만들지 판단하는 역할이다","GitHub 신규 계정, App Store 신규 제출, Vercel·Lovable·Replit 사용량은 비개발자까지 소프트웨어 제작에 들어왔음을 보여준다","문제는 코딩 능력의 확산이 아니라, 다음 세대가 판단력과 리뷰 역량을 배울 사다리가 약해졌다는 점이다"],"related":["posts/why-ai-hasnt-replaced-software-engineers","posts/ai-small-teams-not-headcount"]},{"title":"AI가 팀을 더 강하게 만드는지 측정하는 법","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/measure-ai-effectiveness-teams-ably/","section":"posts","date":"2026-07-02T14:56:44+09:00","lastmod":"2026-07-02T14:56:44+09:00","description":"Ably가 제안한 AI 효과 측정법을 바탕으로, 도구 사용량이 아니라 팀 역량 변화와 업무 방식 내재화를 보는 두 가지 KPI를 정리한다.","summary":"AI 도구를 모두에게 열어주고, 사용량이 늘고, 슬랙에 성공 사례 채널이 생겼다고 해서 팀이 정말 더 강해졌다고 말할 수는 없다. Ably의 글은 이 착시를 정면으로 다룬다. 질문은 단순하다. AI가 우리 팀을 더 유능하게 만들고 있는가, 아니면 더 바쁘게 만들고 있는가?\n원문: Is AI making your teams better, or just busier?\nTL;DR 핵심 정리 사용량은 쉬운 지표지만 약한 지표다: 매일 AI를 열어 같은 일을 조금 빨리 해도 높은 도입률로 보인다. 그러나 팀의 가능 업무 범위가 넓어졌는지는 알 수 없다. 두 가지 KPI가 핵심이다: AI로 새롭게 가능해진 결과가 있는지, AI가 일상 업무 방식 안에 얼마나 깊게 들어왔는지를 월별로 본다. 점수는 증거로만 오른다: 팀 리드가 1~5점으로 평가하되, \u0026ldquo;무엇을 했고 왜 더 나아졌는지\u0026rdquo; 사례가 없으면 점수 상승은 없다. 초기 2점은 실패가 아니다: Ably도 첫 평가에서 두 KPI 모두 2점 수준에서 시작했다. 중요한 것은 높은 출발점이 아니라 매달 좋아지는 궤적이다. 사용량 지표의 함정 AI 도입 성과를 볼 때 가장 쉬운 방법은 \u0026ldquo;누가 쓰고 있는가\u0026rdquo;, \u0026ldquo;얼마나 자주 쓰는가\u0026quot;를 세는 것이다. 하지만 이 지표는 품질을 말하지 않는다. AI 도구를 매일 열어도 기존 업무를 조금 더 빠르게 할 뿐이라면, 팀 역량은 크게 변하지 않는다.\n","content":"AI 도구를 모두에게 열어주고, 사용량이 늘고, 슬랙에 성공 사례 채널이 생겼다고 해서 팀이 정말 더 강해졌다고 말할 수는 없다. Ably의 글은 이 착시를 정면으로 다룬다. 질문은 단순하다. AI가 우리 팀을 더 유능하게 만들고 있는가, 아니면 더 바쁘게 만들고 있는가?\n원문: Is AI making your teams better, or just busier?\nTL;DR 핵심 정리 사용량은 쉬운 지표지만 약한 지표다: 매일 AI를 열어 같은 일을 조금 빨리 해도 높은 도입률로 보인다. 그러나 팀의 가능 업무 범위가 넓어졌는지는 알 수 없다. 두 가지 KPI가 핵심이다: AI로 새롭게 가능해진 결과가 있는지, AI가 일상 업무 방식 안에 얼마나 깊게 들어왔는지를 월별로 본다. 점수는 증거로만 오른다: 팀 리드가 1~5점으로 평가하되, \u0026ldquo;무엇을 했고 왜 더 나아졌는지\u0026rdquo; 사례가 없으면 점수 상승은 없다. 초기 2점은 실패가 아니다: Ably도 첫 평가에서 두 KPI 모두 2점 수준에서 시작했다. 중요한 것은 높은 출발점이 아니라 매달 좋아지는 궤적이다. 사용량 지표의 함정 AI 도입 성과를 볼 때 가장 쉬운 방법은 \u0026ldquo;누가 쓰고 있는가\u0026rdquo;, \u0026ldquo;얼마나 자주 쓰는가\u0026quot;를 세는 것이다. 하지만 이 지표는 품질을 말하지 않는다. AI 도구를 매일 열어도 기존 업무를 조금 더 빠르게 할 뿐이라면, 팀 역량은 크게 변하지 않는다.\nAbly가 인용한 McKinsey 2025 State of AI 조사도 같은 문제를 보여준다. 조사 대상 기업의 88%는 하나 이상의 업무 기능에서 AI를 사용하지만, EBIT 영향을 보고한 조직은 39%에 그쳤고 그 영향도 대체로 5% 미만이었다. 접근권한이 부족한 문제가 아니라, 무엇을 성과로 볼지 잘못 잡은 문제에 가깝다.\n전통적인 엔지니어링 지표도 그대로 쓰기 어렵다. 사이클 타임, 스프린트 속도, 스토리 포인트는 AI가 여러 에이전트로 업무를 병렬화하는 상황에서 의미가 흔들린다. 예전에는 한 스프린트가 걸리던 일이 몇 시간 안에 끝나면 기존 산식이 더 이상 현실을 설명하지 못한다.\n잘 쓰는 사람은 도구 사용자가 아니라 관리자처럼 일한다 Ably가 말하는 AI 고수의 특징은 단순히 프롬프트를 잘 쓰는 사람이 아니다. 더 정확히는 유능하지만 주니어인 팀원에게 일을 맡기는 관리자처럼 행동한다.\n좋은 사용자는 먼저 과제를 명확히 정의하고, 일에 맞는 모델과 도구를 고른다. 결과물을 그대로 받아들이지 않고 비판적으로 검토한다. 한 번에 잘 안 된 세션도 포기하지 않고, 며칠 또는 몇 주에 걸쳐 워크플로를 고친다.\n특히 흥미로운 신호는 사람들이 출력물보다 브리프에 더 많은 시간을 쓰기 시작한다는 점이다. AI에게 맡길 수 있을 만큼 구체적으로 설명하려면, 자신이 원하는 결과를 더 선명하게 생각해야 한다. 이 압력이 팀의 사고 품질을 높인다.\nKPI 1: AI로 새롭게 가능해진 결과 첫 번째 KPI는 AI 사용 여부가 아니라 AI 덕분에 이전에는 어렵거나 불가능했던 결과가 나왔는지를 본다.\n예를 들어 단순히 문서를 빨리 쓴 것은 약한 신호다. 반면 기존 인력과 시간으로는 만들 수 없던 수준의 분석, 자동화, 고객 대응, 코드 개선이 가능해졌다면 강한 신호다. 핵심 질문은 \u0026ldquo;조금 빨라졌는가\u0026quot;가 아니라 \u0026ldquo;가능 업무 범위가 넓어졌는가\u0026quot;다.\nAbly는 이 항목을 월 1회 1~5점으로 평가한다. 개인 점수는 팀, 부서, 회사 단위로 올라간다. 단, 점수는 주장으로 오르지 않는다. 실제 산출물과 이전 대비 달라진 점을 보여줘야 한다.\nKPI 2: AI가 업무 방식 안에 들어왔는가 두 번째 KPI는 AI가 주변 장식인지, 실제 업무 방식의 일부인지 측정한다.\n낮은 단계에서는 챗봇을 가끔 쓰는 수준에 머문다. 높은 단계로 갈수록 자동화된 워크플로가 독립적으로 돌고, 한 사람이 혼자 만들 수 없는 품질·속도·양의 결과물이 나온다. AI가 회의 전후에 잠깐 붙는 보조 도구가 아니라, 일을 설계하고 전달하는 기본 방식이 되는 것이다.\nAbly가 든 4점 수준의 예시는 엔지니어가 기능 개발 속도를 유지하면서도 그동안 밀렸던 기술 부채, 유지보수, 개선 작업을 함께 처리하는 경우다. 예전에는 둘 중 하나를 선택해야 했지만, 이제는 둘 다 해내는 사람이 생긴다. 이것이 단순 효율이 아니라 배수 효과다.\n현재 점수보다 궤적이 중요하다 Ably는 대부분의 팀이 정직하게 평가하면 처음에는 2점 부근에서 시작한다고 말한다. 이 숫자는 나쁜 성적표가 아니라 기준점이다. 더 위험한 것은 근거 없이 3점이나 4점에서 시작하는 것이다.\n중요한 질문은 \u0026ldquo;이번 달 점수가 높은가\u0026quot;가 아니라 \u0026ldquo;지난달보다 구체적으로 무엇이 나아졌는가\u0026quot;다. 1월에 2점인 것은 괜찮다. 2월에도 2점, 3월에도 2점이라면 문제가 된다. 학습이 축적되지 않고 있다는 뜻이기 때문이다.\n점수 부풀리기를 막으려면 리더십 레벨에서 팀 간 기준을 맞춰야 한다. 엔지니어링의 4점과 마케팅의 4점이 대략 같은 수준의 변화와 증거를 뜻해야 회사 전체 지표가 의미를 갖는다.\n점수만으로는 역량이 생기지 않는다 측정은 책임을 만든다. 하지만 측정만으로 실력이 생기지는 않는다. Ably는 점수를 실제 개선으로 연결하기 위해 몇 가지 장치를 둔다.\n첫째, 월별 스코어카드를 함께 리뷰한다. 팀 리드는 각자의 사례를 가져와 \u0026ldquo;무엇을 했는지\u0026rdquo;, \u0026ldquo;무엇이 질적으로 달라졌는지\u0026quot;를 설명한다. \u0026ldquo;2시간 아꼈다\u0026quot;도 의미 있지만, 목표는 \u0026ldquo;원래는 일주일과 두 사람이 필요했던 결과를 만들었다\u0026quot;에 가깝다.\n둘째, 직무 성장 프레임워크 안에 AI 역량을 넣는다. AI를 별도 트랙으로 보지 않고, 각 레벨에서 좋은 성과란 무엇인지 정의하는 요소로 다룬다.\n셋째, 공유 가능한 스킬 저장소를 운영한다. Ably는 GitHub에 내부 스킬 저장소를 두고 MCP를 통해 직원들이 AI 어시스턴트에서 바로 쓸 수 있게 한다. 한 사람이 관리해서 좋아지는 저장소가 아니라, 모두가 쓰고 개선하기 때문에 좋아지는 구조다.\n넷째, 새 프로세스와 지출에 AI 관점을 강제한다. 새로운 프로세스나 도구 구매를 제안할 때 \u0026ldquo;AI가 이미 처리할 수 있는가\u0026quot;를 먼저 묻는다. AI를 나중에 붙이는 보조 수단이 아니라, 기본 사고방식으로 끌어올리기 위한 장치다.\n실무 적용 포인트 팀에서 바로 적용하려면 거창한 대시보드보다 작은 월간 리듬이면 충분하다.\n팀원별로 AI가 만든 구체적 변화 사례를 한 달에 하나씩 기록한다. 사례마다 \u0026ldquo;기존 방식으로는 얼마나 어려웠는지\u0026quot;와 \u0026ldquo;AI로 무엇이 달라졌는지\u0026quot;를 적는다. 두 KPI를 1~5점으로 매기되, 사례가 없으면 점수를 올리지 않는다. 팀 간 점수 기준을 리더십 회의에서 맞춘다. 좋은 사례는 스킬, 템플릿, 워크플로로 저장해 재사용한다. 이 방식의 장점은 허풍을 줄인다는 데 있다. \u0026ldquo;우리는 AI를 많이 쓴다\u0026quot;는 말보다 \u0026ldquo;이 결과는 예전에는 불가능했고, 이제 반복 가능하다\u0026quot;는 말이 훨씬 강하다.\n결론 및 시사점 한 줄 결론: AI 효과는 사용량이 아니라 팀이 새로 해낼 수 있게 된 일과 그 변화가 업무 방식에 얼마나 깊게 박혔는지로 판단해야 한다.\nAI 도입의 진짜 목적은 더 많은 도구 계정을 배포하는 것이 아니다. 팀이 더 어려운 문제를 풀고, 밀린 일을 처리하고, 더 나은 품질의 결과를 반복적으로 만들게 하는 것이다.\n그래서 AI 성과 측정은 클릭 수나 로그인 수보다 증거 기반 대화에 가까워야 한다. 이번 달에 무엇이 가능해졌는지, 그 방식이 다음 달에도 재현될 수 있는지, 팀 전체가 그 학습을 공유하고 있는지를 봐야 한다.\nAbly의 접근은 완벽한 산식이라기보다 좋은 질문 목록에 가깝다. 우리 팀은 AI를 쓰고 있는가? 그보다 더 중요한 질문은 이것이다. AI를 쓰기 전과 비교해, 우리 팀은 정말 다른 팀이 되었는가?\n","wordCount":930,"tags":["AI","생산성","팀운영","조직문화","KPI"],"categories":["AI"],"frameworks":["Evidence-Based Management","Capability Measurement"],"mental_models":["Goodhart's Law","Compounding","Leading Indicator"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 도입률은 팀이 좋아졌는지 말해주지 않는다. Ably는 접근권한·사용 빈도 대신 새롭게 가능해진 결과와 업무 방식 내재화를 측정한다.","McKinsey 2025 State of AI 조사에서는 기업의 88%가 하나 이상의 업무 기능에서 AI를 쓰지만, EBIT 영향을 보고한 조직은 39%에 그쳤고 영향도는 보통 5% 미만이었다.","Ably의 두 KPI는 월 1회 팀 리드가 1~5점으로 평가한다. 점수 상승에는 실제 사례가 필요하며, 사례가 없으면 점수를 올리지 않는다.","중요한 것은 현재 점수보다 궤적이다. 1월에 2점인 것은 괜찮지만, 2월과 3월에도 그대로라면 학습과 내재화가 멈춘 신호다."],"related":["posts/ai-capability-not-cost-reduction","posts/agentic-software-engineering"]},{"title":"AI가 줄여야 할 것은 인원수가 아니라 팀 크기다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-small-teams-not-headcount/","section":"posts","date":"2026-07-02T12:03:10+09:00","lastmod":"2026-07-02T12:03:10+09:00","description":"Miguel Carranza의 글을 바탕으로, AI 시대에 회사가 사람을 덜 뽑는 대신 더 작은 팀을 더 많이 만들어야 하는 이유를 정리한다.","summary":"AI가 조직을 바꾼다는 말은 자주 인원 감축 이야기로 흘러갑니다. Miguel Carranza의 글은 방향을 다르게 잡습니다. 핵심은 사람을 덜 뽑자는 것이 아니라, 팀을 작게 쪼개 새로 합류한 사람이 더 많은 회의가 아니라 더 많은 병렬성을 만들게 하자는 주장입니다.\n원문: AI shouldn\u0026rsquo;t shrink headcount. It should shrink teams\nSmall Teams 핵심 정리 핵심 주장: AI의 조직 효과는 인원 감축보다 팀 크기 축소에 있다. 작은 팀은 결정권과 책임 소재가 뚜렷하다. 병목 이동: AI가 첫 구현과 낯선 코드 검토 비용을 낮추면, 중요한 일은 \u0026ldquo;코드를 누가 쓰는가\u0026quot;보다 \u0026ldquo;무엇을 만들고 언제 멈출지 판단하는가\u0026quot;가 된다. RevenueCat 사례: OCTO는 신뢰 높은 시니어 IC들이 새 베팅과 중요 프로젝트를 빠르게 검증하는 작은 조직 실험이었다. 제품팀 적용: 1~3명 엔지니어, 공유 PM·디자인, 명확한 Tech Lead 구조로 팀 수를 늘리고 회의 규모를 줄였다. 주의점: 작은 팀은 중복과 용량 리스크가 크다. 그래서 매니저는 모든 팀에 같은 시간을 쓰기보다 막힌 곳에 깊게 들어가야 한다. 1) AI는 채용 논리를 없애지 않고 팀 토폴로지를 바꾼다 Carranza가 먼저 선을 긋는 지점은 중요합니다. 작은 팀은 \u0026ldquo;AI가 있으니 사람을 덜 뽑자\u0026quot;는 말이 아닙니다. 오히려 채용이 늘어날 때 그 사람이 더 큰 회의에 흡수되지 않고, 새로운 실행 단위를 만들게 하자는 말입니다.\n","content":"AI가 조직을 바꾼다는 말은 자주 인원 감축 이야기로 흘러갑니다. Miguel Carranza의 글은 방향을 다르게 잡습니다. 핵심은 사람을 덜 뽑자는 것이 아니라, 팀을 작게 쪼개 새로 합류한 사람이 더 많은 회의가 아니라 더 많은 병렬성을 만들게 하자는 주장입니다.\n원문: AI shouldn\u0026rsquo;t shrink headcount. It should shrink teams\nSmall Teams 핵심 정리 핵심 주장: AI의 조직 효과는 인원 감축보다 팀 크기 축소에 있다. 작은 팀은 결정권과 책임 소재가 뚜렷하다. 병목 이동: AI가 첫 구현과 낯선 코드 검토 비용을 낮추면, 중요한 일은 \u0026ldquo;코드를 누가 쓰는가\u0026quot;보다 \u0026ldquo;무엇을 만들고 언제 멈출지 판단하는가\u0026quot;가 된다. RevenueCat 사례: OCTO는 신뢰 높은 시니어 IC들이 새 베팅과 중요 프로젝트를 빠르게 검증하는 작은 조직 실험이었다. 제품팀 적용: 1~3명 엔지니어, 공유 PM·디자인, 명확한 Tech Lead 구조로 팀 수를 늘리고 회의 규모를 줄였다. 주의점: 작은 팀은 중복과 용량 리스크가 크다. 그래서 매니저는 모든 팀에 같은 시간을 쓰기보다 막힌 곳에 깊게 들어가야 한다. 1) AI는 채용 논리를 없애지 않고 팀 토폴로지를 바꾼다 Carranza가 먼저 선을 긋는 지점은 중요합니다. 작은 팀은 \u0026ldquo;AI가 있으니 사람을 덜 뽑자\u0026quot;는 말이 아닙니다. 오히려 채용이 늘어날 때 그 사람이 더 큰 회의에 흡수되지 않고, 새로운 실행 단위를 만들게 하자는 말입니다.\n초기 스타트업은 자연스럽게 이렇게 움직입니다. 한 사람이 전체 기능을 잡고, 버그는 하루 만에 고치고, 기능은 일주일 안에 나갑니다. 회사가 커지면 속도가 느려지는 일은 어느 정도 당연합니다. 고객이 늘고, 표면적이 넓어지고, 리스크도 커지기 때문입니다.\n하지만 모든 느림이 성숙의 증거는 아닙니다. 어떤 느림은 단지 조직 무게가 일상이 된 결과입니다. AI는 이 무게를 다시 의심하게 만듭니다.\n2) 코드 작성이 싸지면 동의 비용이 더 비싸진다 예전에는 큰 제품 영역을 맡기려면 백엔드 몇 명, 프론트엔드 몇 명, PM, EM, 디자이너가 붙는 구조가 자연스러웠습니다. 코드 작성이 병목이고, 낯선 영역을 리뷰하는 비용도 컸기 때문입니다.\nAI는 이 균형을 흔듭니다. 첫 버전 작성 비용이 낮아지고, 익숙하지 않은 코드베이스를 파악하는 일도 쉬워집니다. 그러면 병목은 구현 자체에서 다음 질문들로 이동합니다.\n이 일을 만들 가치가 있는가? 지금 충분히 검증했는가? 이 결정의 책임자는 누구인가? 언제 멈추거나 버릴 수 있는가? 그래서 모든 의미 있는 작업마다 각 전문 분야의 여러 명이 동의할 필요는 줄어듭니다. 여전히 AI가 만든 그럴듯한 헛소리를 걸러낼 사람은 필요합니다. 다만 그 사람이 반드시 큰 회의실 안에 여럿일 필요는 없습니다.\n3) OCTO가 보여준 작은 팀의 조건 RevenueCat에서 먼저 검증된 모델은 OCTO, 즉 Office of the CTO였습니다. 신뢰 높은 시니어 IC 몇 명에게 새 베팅과 중요 프로젝트를 맡기고, 큰 조직을 만들기 전에 빠르게 학습하게 한 구조입니다.\n새로운 베팅의 초반에는 코드보다 판단이 더 중요합니다. 기술 선택을 빠르게 해야 하고, MVP에 애착을 갖지 않아야 하며, 사업적으로 틀렸다면 만든 코드도 버릴 수 있어야 합니다. Carranza는 여기서 어려운 일이 코드를 쓰는 것이 아니라, 버려야 할 때 버리는 성숙함이라고 봅니다.\nOCTO가 잘 작동한 이유는 작고, 시니어하고, 신뢰가 높았기 때문입니다. 숨을 곳이 없고, 정렬을 연기처럼 보여줄 필요도 없습니다. 일이 막히면 바로 드러나고, 베팅이 틀리면 더 빨리 알게 됩니다.\n4) 제품팀으로 확장한 방식 RevenueCat은 이 방식을 새 베팅에만 쓰지 않고 제품팀에도 적용했습니다. 여러 미션을 한 조직과 한 회의 구조 안에 묶어두던 팀을 쪼갰고, 결과적으로 제품팀 수를 두 배 이상으로 늘렸습니다.\n기본 모델은 단순합니다.\n엔지니어 1~3명 필요하면 공유 PM 또는 디자이너 명확한 엔지니어링 DRI인 Tech Lead 사람 관리, 채용, 코칭, 성과, 팀 건강을 맡는 매니저 Tech Lead는 일을 앞으로 밀고, 리스크를 빨리 올리고, 다른 팀과의 인터페이스가 됩니다. 두 작은 팀이 조율해야 할 때는 16명이 모이는 회의 대신 Tech Lead 몇 명이 이야기하면 됩니다.\n이 구조는 미래 리더를 찾는 낮은 리스크의 방법이기도 합니다. 사람 관리 책임 없이도 의사결정, 결과 소유, 조율 경험을 줄 수 있기 때문입니다.\n5) 작은 팀의 비용도 작지 않다 작은 팀은 만능 해법이 아닙니다. 가장 큰 비용은 중복과 용량 리스크입니다. 두 명짜리 팀에서 한 명이 육아휴직, 휴가, 장애 대응으로 빠지면 팀 용량의 절반이 사라집니다.\n또한 작은 팀은 IC에게 더 많은 리더십을 요구합니다. 누군가는 결정을 내리고, 명확히 커뮤니케이션하고, 허락을 기다리지 않고 일을 움직여야 합니다. 모든 사람이 바로 그 역할에 맞는 것은 아닙니다.\n팀이 많아지면 파편화도 생깁니다. 같은 일을 중복하거나 제품 일관성이 흔들릴 수 있습니다. 그래서 Tech Lead의 역할이 중요합니다. 해법은 큰 회의로 돌아가는 것이 아니라, 올바른 사람들끼리 더 좋은 조율 구조를 만드는 것입니다.\n6) 매니저의 일은 균등 배분이 아니라 주의력 배분이다 작은 팀을 여러 개 맡는 EM은 모든 팀에 같은 시간을 쓸 수 없고, 그래야 할 필요도 없습니다. 매주 잘 출시하는 건강한 팀과 막힌 팀은 같은 관리 밀도를 요구하지 않습니다.\n매니저의 일은 주의력을 가장 수익이 높은 곳에 배분하는 쪽으로 바뀝니다.\n막힌 팀에는 깊게 들어간다. 준비가 덜 된 Tech Lead를 코칭한다. 휴가나 육아휴직으로 계획이 깨지면 재배치한다. 잘 굴러가는 팀은 사실이 바뀔 때까지 자율성을 준다. 1:1도 고정 주기만이 정답은 아닙니다. 어떤 사람은 매주 필요하고, 어떤 사람은 격주로 충분하며, 신뢰 높은 팀은 Tech Lead를 통해 상태를 확인해도 됩니다.\n결론 및 시사점 Carranza의 주장은 AI 시대 조직 설계의 좋은 기준선을 줍니다. AI가 코드 작성 비용을 낮춘다면, 회사는 사람을 줄이는 상상보다 조율 비용을 줄이는 구조를 먼저 봐야 합니다.\n작은 팀은 빠른 결정, 명확한 소유권, 눈에 보이는 성과를 만듭니다. 대신 작은 팀이 작동하려면 강한 IC, 선명한 Tech Lead, 막힌 곳을 알아보는 매니저, 그리고 팀 간 조율을 위한 얇지만 단단한 연결이 필요합니다.\n한 줄 결론: AI 시대의 좋은 조직은 사람을 덜 쓰는 조직이 아니라, 더 작은 책임 단위로 더 많은 일을 동시에 배울 수 있는 조직이다.\n관련 포스트 에이전틱 엔지니어링 매니지먼트 — EM 역할에 에이전트를 적용하면 무엇이 보이는가 Modern Engineering Values — AI 시대, 코딩이 병목이 아닐 때 엔지니어에게 남은 것 Software is becoming marketing - 소프트웨어 풍요 시대의 제품과 일자리 ","wordCount":843,"tags":["AI","조직설계","엔지니어링매니지먼트","스타트업","RevenueCat"],"categories":["AI","Engineering"],"frameworks":["Small Teams","Organizational Design","Strong Ownership"],"mental_models":["Coordination Cost","DRI","Span of Attention"],"philosophy_type":"engineering-management","schema_type":"Article","actionable":true,"priority":"medium","key_points":["AI 시대의 목표는 인원 감축이 아니라, 같은 사람으로 더 많은 병렬 작업을 가능하게 하는 작은 팀 구조다.","코드 작성 비용이 낮아질수록 병목은 구현에서 판단, 검토, 소유권, 조율로 이동한다.","RevenueCat은 OCTO라는 작고 신뢰 높은 시니어 IC 그룹에서 배운 방식을 제품팀으로 확장했다.","1~3명 엔지니어와 Tech Lead 중심 구조는 속도와 책임 소재를 선명하게 만들지만, 휴가·육아휴직·장애 대응 때 용량 손실이 크다."],"related":["posts/agentic-engineering-management","posts/modern-engineering-values","posts/software-is-becoming-marketing"]},{"title":"LinkedIn QA Agent - AI 자율 테스트가 바꾸는 품질 관리","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/linkedin-qa-agent-autonomous-testing/","section":"posts","date":"2026-07-02T11:43:54+09:00","lastmod":"2026-07-02T11:43:54+09:00","description":"LinkedIn Engineering의 QA Agent 글을 바탕으로, VLM 기반 자율 테스트 에이전트가 전통적인 UI 테스트의 한계를 어떻게 넘는지 정리했다.","summary":"LinkedIn Engineering이 2026년 6월 18일 공개한 **\u0026ldquo;Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing\u0026rdquo;**는 AI 에이전트가 실제 대규모 서비스의 품질 관리를 어떻게 바꿀 수 있는지 보여주는 사례입니다.\n원문: Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing\nAI 핵심 정리 문제 배경: LinkedIn은 iOS, Android, Web, 36개 이상 언어, 사용자 유형, 멤버십, 실험 조합 때문에 전통적인 UI 자동화만으로 모든 변화를 따라가기 어렵다. 해결 방식: QA Agent는 selector에 의존하지 않고 VLM으로 화면을 읽으며, planner, analytical reasoning model, fine-tuned visual grounding model을 나눠 쓴다. 운영 구조: 안정적인 흐름은 deterministic replay로 빠르게 실행하고, 화면이 바뀌면 vision-based planning으로 넘어간다. 검증 장치: view tree, tracking log, action history, error detection pipeline, golden dataset을 통해 phantom bug보다 실제 버그 탐지를 우선한다. 현재 규모: LinkedIn은 350개 이상 테스트를 30분 주기로 실행하며, QA Agent가 200개 이상 유효 버그를 찾았다고 밝혔다. 1) 전통적인 UI 테스트가 막히는 지점 LinkedIn의 품질 문제는 단순히 화면이 많다는 수준이 아닙니다. 같은 기능이라도 사용자 유형, 언어, 멤버십, 실험군, 개인화 상태에 따라 다른 화면이 나옵니다. LinkedIn은 이 조합을 \u0026ldquo;하나의 앱이 아니라 수천 개의 permutation\u0026quot;에 가깝게 설명합니다.\n","content":"LinkedIn Engineering이 2026년 6월 18일 공개한 **\u0026ldquo;Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing\u0026rdquo;**는 AI 에이전트가 실제 대규모 서비스의 품질 관리를 어떻게 바꿀 수 있는지 보여주는 사례입니다.\n원문: Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing\nAI 핵심 정리 문제 배경: LinkedIn은 iOS, Android, Web, 36개 이상 언어, 사용자 유형, 멤버십, 실험 조합 때문에 전통적인 UI 자동화만으로 모든 변화를 따라가기 어렵다. 해결 방식: QA Agent는 selector에 의존하지 않고 VLM으로 화면을 읽으며, planner, analytical reasoning model, fine-tuned visual grounding model을 나눠 쓴다. 운영 구조: 안정적인 흐름은 deterministic replay로 빠르게 실행하고, 화면이 바뀌면 vision-based planning으로 넘어간다. 검증 장치: view tree, tracking log, action history, error detection pipeline, golden dataset을 통해 phantom bug보다 실제 버그 탐지를 우선한다. 현재 규모: LinkedIn은 350개 이상 테스트를 30분 주기로 실행하며, QA Agent가 200개 이상 유효 버그를 찾았다고 밝혔다. 1) 전통적인 UI 테스트가 막히는 지점 LinkedIn의 품질 문제는 단순히 화면이 많다는 수준이 아닙니다. 같은 기능이라도 사용자 유형, 언어, 멤버십, 실험군, 개인화 상태에 따라 다른 화면이 나옵니다. LinkedIn은 이 조합을 \u0026ldquo;하나의 앱이 아니라 수천 개의 permutation\u0026quot;에 가깝게 설명합니다.\n기존 UI 자동화는 보통 selector, test ID, DOM 구조, 접근성 label 같은 구현 세부사항에 기대는 경우가 많습니다. 문제는 제품이 빨리 바뀔수록 이 정보도 같이 흔들린다는 점입니다. 버튼의 의미는 그대로인데 ID가 바뀌면 테스트는 실패합니다. 화면 구조가 바뀌면 사용자는 문제없이 이해하는 흐름도 자동화 스크립트는 길을 잃습니다.\nLinkedIn이 QA Agent를 만든 이유는 더 좋은 스크립트 러너가 필요해서가 아닙니다. 사람처럼 화면을 보고, 목표를 이해하고, 흐름을 탐색하는 디지털 테스터가 필요했기 때문입니다.\n2) 핵심은 VLM 하나가 아니라 역할 분리다 QA Agent는 Vision-Language Model을 사용해 화면을 직접 읽습니다. 텍스트, 아이콘, 버튼의 시각적 위계, 화면의 변화까지 사람과 비슷한 단서로 판단합니다. 그래서 \u0026ldquo;Apply\u0026rdquo; 버튼의 내부 ID가 바뀌어도, 화면에 Apply 버튼처럼 보이면 찾아낼 수 있습니다.\n흥미로운 점은 LinkedIn이 하나의 모델에 모든 일을 맡기지 않았다는 점입니다. 한 action cycle 안에서도 역할을 나눕니다.\nPlanner는 현재 screenshot, view tree, action history, 목표를 보고 다음 행동을 정합니다. Analytical reasoning model은 오류 감지, view tree 평가, bug report 생성, navigation 판단처럼 더 신중한 추론이 필요한 일을 맡습니다. Fine-tuned visual grounding model은 \u0026ldquo;Easy Apply 버튼을 누르라\u0026quot;는 자연어 행동을 실제 화면 좌표로 바꿉니다. 이 구조의 장점은 단순합니다. planning이 약하면 planner를 바꾸고, 좌표 grounding이 약하면 grounding model을 개선하면 됩니다. 모든 기능을 하나의 거대한 prompt에 묶어두는 방식보다 실험과 교체가 쉽습니다.\n3) System 1은 기억으로 빠르게, System 2는 시각 추론으로 천천히 LinkedIn은 QA Agent를 인간의 System 1과 System 2 비유로 설명합니다.\nSystem 1은 빠른 재생 모드입니다. 이전에 성공했던 테스트 흐름이 있고 현재 UI가 크게 바뀌지 않았다면, agent는 과거 action sequence를 그대로 따라갑니다. 각 action에는 UI element의 signature가 저장됩니다. 다음 실행 때 element type과 text 또는 accessibility text가 맞으면 LLM 호출 없이 deterministic하게 실행합니다.\nSystem 2는 화면이 바뀌었거나 기억한 경로가 더 이상 맞지 않을 때 작동합니다. 이때 VLM 기반 planner가 현재 화면을 보고 다음 행동을 다시 판단합니다. 성공한 자연어 instruction은 저장되어 다음 실행의 memory로 쓰입니다. LinkedIn은 같은 task에 대해 이전에 성공했던 instruction 20개를 prompt에 제공해 planner가 이미 검증된 방향을 더 잘 선택하도록 만든다고 설명합니다.\n여기서 중요한 설계 감각은 비용과 유연성의 균형입니다. 모든 step마다 LLM을 부르면 느리고 비쌉니다. 반대로 전부 고정 스크립트로 만들면 변화에 약합니다. LinkedIn의 선택은 \u0026ldquo;안정적인 곳은 싸게 재생하고, 바뀐 곳만 비싼 추론을 쓴다\u0026quot;입니다.\n4) 에이전트 테스트에서 evaluator가 신뢰를 만든다 AI agent가 테스트를 대신할 때 가장 위험한 것은 가짜 확신입니다. 실제 버그가 아닌데 버그라고 보고하면 개발팀은 금방 신뢰를 잃습니다. LinkedIn도 precision을 recall보다 우선한다고 말합니다. 조금 놓치더라도, 보고되는 버그는 진짜여야 한다는 접근입니다.\n이를 위해 QA Agent에는 여러 evaluator가 붙습니다.\nView Tree Evaluator: 행동 전후 UI 구조를 비교해 실제 의미 있는 변화가 있었는지 본다. Tracking Log Evaluator: 예상 analytics event가 올바른 순서와 내용으로 발생했는지 확인한다. Action History Evaluator: agent가 목표와 맞는 경로로 가고 있는지 판단한다. Error Detection Pipeline: screenshot에서 crash, error page, UI anomaly를 감지한 뒤 두 번째 LLM 검증을 거쳐 bug report로 넘긴다. 특히 tracking log 검증은 실무적으로 중요합니다. UI가 정상처럼 보여도 funnel event가 빠지거나 payload가 깨지면 제품 지표와 의사결정이 망가집니다. LinkedIn은 QA Agent가 이런 analytics regression까지 잡는다고 설명합니다.\n5) 테스트 작성도 코드에서 의도 표현으로 이동한다 QA Agent가 흥미로운 또 다른 이유는 테스트 작성 권한을 넓힌다는 점입니다. LinkedIn은 사용자가 직접 앱을 조작하면 recorder가 tap, scroll, input을 기록하고, LLM이 이를 고수준 자연어 instruction으로 바꿉니다.\n예를 들어 특정 좌표를 누른 기록은 \u0026ldquo;Easy Apply 버튼을 탭한다\u0026rdquo; 같은 의미 있는 행동으로 바뀝니다. 이후 사용자는 web interface에서 agent가 이해한 계획을 검토하고 승인합니다. 이 human-in-the-loop 단계가 테스트의 의도를 바로잡습니다.\n이 방식은 테스트를 brittle macro로 저장하지 않습니다. 사람이 한 행동을 semantic plan으로 바꾸고, 승인된 plan을 agent memory의 seed로 씁니다. 그래서 첫 실행부터 빠른 deterministic replay가 가능하고, UI가 바뀌면 System 2로 넘어가 적응할 수 있습니다.\n6) Golden dataset은 agent 실험을 재현 가능하게 만든다 AI agent 평가에서 흔한 문제는 live app이 계속 변한다는 것입니다. 배포, 실험, 서버 데이터, 개인화 상태가 바뀌면 같은 테스트를 두 번 돌려도 결과가 달라집니다. 그러면 새 planner가 좋아진 것인지, 운이 좋았던 것인지 알기 어렵습니다.\nLinkedIn은 이를 위해 golden dataset framework를 만들었습니다. 사람이 agent run을 검토하고 올바른 action과 task completion 여부를 표시합니다. 이때 screenshot, view tree, 기대 action을 frozen snapshot으로 저장합니다.\n평가할 때는 실제 device command를 실행하지 않습니다. screenshot 요청에는 저장된 이미지를 돌려주고, view tree 요청에는 저장된 hierarchy를 돌려줍니다. agent가 action을 내면 recorded action signature와 비교합니다. 이 방식 덕분에 같은 dataset을 여러 번 돌려도 결과가 흔들리지 않습니다.\n이 구조는 실험에도 유용합니다. production planner가 실제 action을 수행하는 동안 experimental planner의 선택을 옆에서 기록하고, 나중에 golden dataset으로 더 엄밀하게 replay할 수 있습니다. agent 개선이 느낌이 아니라 action accuracy, task completion, replay pass rate 같은 수치로 비교됩니다.\n7) 실무자가 가져갈 포인트 이 글의 핵심은 \u0026ldquo;VLM을 붙이면 UI 테스트가 해결된다\u0026quot;가 아닙니다. 오히려 반대에 가깝습니다. VLM은 중요한 부품이지만, 실제 품질 시스템은 그 주변의 운영 장치가 결정합니다.\n실무적으로는 네 가지가 남습니다.\nUI 테스트를 selector 안정성 문제가 아니라 사용자 의도와 화면 이해 문제로 바라본다. 반복 성공 경로는 memory로 싸게 재사용하고, 변화가 감지될 때만 비싼 추론을 쓴다. agent 판단 뒤에는 view change, event log, action history, error verification 같은 evaluator를 둔다. 모델 교체와 prompt 실험은 live app 감상이 아니라 frozen dataset replay로 검증한다. AI 시대의 QA는 테스트 케이스를 더 많이 쓰는 일이 아니라, 테스트 의도와 검증 증거를 기계가 재사용할 수 있는 형태로 남기는 일에 가까워지고 있습니다.\n결론 및 시사점 한 줄 결론: LinkedIn QA Agent의 진짜 교훈은 AI가 tester를 대체한다는 말이 아니라, 품질 관리가 selector 기반 자동화에서 memory, visual reasoning, evaluator, golden dataset이 결합된 운영 시스템으로 이동한다는 점이다.\nLinkedIn의 사례는 AI agent가 품질 업무에서 어디까지 현실적인지를 보여줍니다. 이미 350개 이상 테스트를 30분 주기로 돌리고, 200개 이상 유효 버그를 찾았다는 수치는 실험실 데모보다 훨씬 무겁습니다.\n하지만 더 중요한 메시지는 설계 철학입니다. agent에게 모든 판단을 맡기는 것이 아니라, 빠른 기억과 느린 추론을 나누고, evaluator로 검증하고, human review로 의도를 정렬하고, golden dataset으로 실험을 고정합니다.\n앞으로 개발 과정에 coding agent가 더 깊게 들어올수록 QA도 나중에 붙는 관문이 아니라 개발 중 호출되는 능력이 될 가능성이 큽니다. 그때 경쟁력은 \u0026ldquo;AI로 테스트를 돌린다\u0026quot;가 아니라, AI가 남긴 행동과 판단을 신뢰할 수 있게 만드는 체계를 갖추는 데서 나올 것입니다.\n","wordCount":1098,"tags":["AI","QA","자율테스트","소프트웨어품질","LinkedIn","에이전트"],"categories":["AI"],"frameworks":["Autonomous testing","Verification-first engineering","Human-in-the-loop"],"mental_models":["System 1 and System 2","Golden dataset","Precision over recall","Semantic memory"],"philosophy_type":"software-quality","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LinkedIn은 iOS, Android, Web과 36개 이상 언어, 사용자 유형과 실험 조합으로 폭증한 UI 테스트 문제를 QA Agent로 풀고 있다.","QA Agent는 고정 selector 대신 VLM을 사용해 화면을 사람처럼 읽고, planner·reasoning model·fine-tuned grounding model을 나눠 한 action cycle을 실행한다.","빠른 경로는 과거 성공 기록을 deterministic replay로 재사용하고, UI가 바뀌면 System 2의 vision-based planning으로 전환한다.","LinkedIn은 350개 이상 테스트를 30분 주기로 실행하며, QA Agent가 200개 이상 유효 버그와 매출 영향 흐름의 regression을 잡았다고 밝혔다.","핵심 교훈은 AI 테스트의 성패가 모델 하나가 아니라 memory, evaluator, golden dataset, human review를 묶은 운영 체계에 달려 있다는 점이다."],"related":["posts/agentic-code-review-addy-osmani","posts/eval-smell-product-design","posts/agent-harness-engineering"]},{"title":"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-01T11:56:45+09:00","lastmod":"2026-07-01T11:56:45+09:00","description":"Hamel Husain의 2026-06-29 글을 바탕으로, AI 제품에서 평가 난이도가 제품 설계 문제로 이어지는 이유와 검증 가능한 산출물 설계 원칙을 정리한다.","summary":"Hamel Husain의 글 \u0026ldquo;It\u0026rsquo;s Hard to Eval\u0026rdquo; Is a Product Smell은 AI 제품에서 자주 나오는 말, \u0026ldquo;이 제품은 평가하기 어렵다\u0026quot;를 다르게 봅니다. 저자의 주장은 단순합니다. 평가가 어렵다면 평가 방식만의 문제가 아니라, 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호일 수 있습니다.\nTL;DR 핵심 정리 중심 주장: AI 산출물이 제품을 만든 사람에게도 확인하기 어렵다면, 사용자는 더 큰 비용을 들여 다시 검증해야 한다. 설계 방향: 최종 답만 보여주지 말고 출처, 가정, 중간 계산, 확인하지 못한 항목을 함께 보여줘야 한다. 반복 패턴: 데이터 분석, 수업 계획, 의료 보고서 모두 \u0026ldquo;완성본 생성\u0026quot;보다 \u0026ldquo;검증 가능한 작은 단위\u0026quot;가 중요하다. 실무 질문: 사용자는 무엇을 확인해야 하는가, 무엇과 비교할 수 있는가, 어떤 단위로 승인하거나 거절할 수 있는가. 1) 어려운 평가는 제품 냄새다 많은 AI 팀은 평가를 나중 문제로 둡니다. 먼저 모델이 그럴듯한 결과를 내게 만들고, 이후에 자동 평가나 사람 평가를 붙이려 합니다. Hamel은 순서가 반대여야 한다고 말합니다. 제품이 검증하기 쉬운 산출물을 만들도록 설계되어야 평가도 쉬워집니다.\n","content":"Hamel Husain의 글 \u0026ldquo;It\u0026rsquo;s Hard to Eval\u0026rdquo; Is a Product Smell은 AI 제품에서 자주 나오는 말, \u0026ldquo;이 제품은 평가하기 어렵다\u0026quot;를 다르게 봅니다. 저자의 주장은 단순합니다. 평가가 어렵다면 평가 방식만의 문제가 아니라, 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호일 수 있습니다.\nTL;DR 핵심 정리 중심 주장: AI 산출물이 제품을 만든 사람에게도 확인하기 어렵다면, 사용자는 더 큰 비용을 들여 다시 검증해야 한다. 설계 방향: 최종 답만 보여주지 말고 출처, 가정, 중간 계산, 확인하지 못한 항목을 함께 보여줘야 한다. 반복 패턴: 데이터 분석, 수업 계획, 의료 보고서 모두 \u0026ldquo;완성본 생성\u0026quot;보다 \u0026ldquo;검증 가능한 작은 단위\u0026quot;가 중요하다. 실무 질문: 사용자는 무엇을 확인해야 하는가, 무엇과 비교할 수 있는가, 어떤 단위로 승인하거나 거절할 수 있는가. 1) 어려운 평가는 제품 냄새다 많은 AI 팀은 평가를 나중 문제로 둡니다. 먼저 모델이 그럴듯한 결과를 내게 만들고, 이후에 자동 평가나 사람 평가를 붙이려 합니다. Hamel은 순서가 반대여야 한다고 말합니다. 제품이 검증하기 쉬운 산출물을 만들도록 설계되어야 평가도 쉬워집니다.\n예를 들어 사용자가 AI 데이터 에이전트에게 \u0026ldquo;지난 분기 Product A의 순매출은 얼마인가?\u0026ldquo;라고 묻는다고 합시다. 에이전트가 \u0026ldquo;$4.21M\u0026quot;이라는 숫자만 답하면 사용자는 그 숫자를 믿을 근거가 없습니다. 결국 지표 정의, SQL, 원천 데이터, 중간 계산을 다시 확인해야 합니다. 이러면 AI가 시간을 줄여준 것이 아니라 검토 비용을 사용자에게 떠넘긴 셈입니다.\n좋은 설계는 답을 더 길게 쓰는 것이 아닙니다. 사용자가 실제로 확인하는 경로를 제품 안에 넣는 것입니다. 지표 정의가 어디서 왔는지, 어떤 쿼리를 실행했는지, 어떤 중간값이 맞지 않는지, 무엇은 아직 신뢰할 수 없는지 보여줘야 합니다. 최종 숫자는 같아도 검증 가능한 숫자와 검증 불가능한 숫자는 전혀 다른 제품 경험입니다.\n2) 검증 가능한 산출물은 더 작다 두 번째 사례는 K-12 체육 수업 계획 생성기입니다. 교사가 학년, 수업 시간, 장소, 장비를 입력하면 AI가 수업 계획을 만듭니다. 문제는 완전히 새 계획 하나를 통째로 받으면 교사가 전체를 다시 판단해야 한다는 점입니다.\nHamel이 제안하는 방향은 기존에 검증된 수업 계획을 기준점으로 삼는 것입니다. AI가 새 계획을 처음부터 쓰는 대신, 실제 교사들이 쓰는 계획을 가져오고 사용자의 제약에 맞게 몇 군데만 바꿉니다. 그리고 바뀐 부분을 diff로 보여줍니다. 예를 들어 50분 계획을 45분에 맞추기 위해 준비운동을 줄였거나, 장비 수에 맞춰 스테이션 개수를 바꿨다는 식입니다.\n이 설계는 사용자에게도 좋고 평가에도 좋습니다. 교사는 전체 계획을 다시 읽는 대신 \u0026ldquo;이 변경이 내 조건을 잘 반영했는가\u0026quot;만 보면 됩니다. 팀 입장에서도 평가 범위가 줄어듭니다. 검색한 기준 계획이 적절했는지, 변경 사유가 맞는지, 제약을 어기지 않았는지를 각각 확인할 수 있습니다.\n3) 고위험 문서는 완성본보다 근거가 먼저다 세 번째 사례는 산재 의료 보고서입니다. AI가 환자 기록, 영상 판독, 치료 노트, 이전 검사 자료를 읽고 50페이지짜리 전문가 의견서를 만든다고 해봅시다. 이 영역에서 최종 보고서만 내놓는 제품은 위험합니다. 의사는 결국 모든 주장과 근거를 다시 확인해야 하고, 책임도 의사에게 남습니다.\n그래서 제품은 보고서 생성기보다 연구 보조자에 가까워야 합니다. 각 기록에서 중요한 사실을 뽑고, 원문 페이지로 돌아갈 수 있는 링크를 붙이고, 서로 충돌하는 검사 결과를 표시하고, 아직 판단이 필요한 빈틈을 드러내야 합니다. 의사가 이 단위들을 확인한 뒤에야 최종 보고서가 조립되는 편이 더 안전합니다.\n핵심은 AI가 사람을 루프 밖으로 밀어내는 것이 아닙니다. 사람이 책임져야 하는 판단을 더 작은 단위로 나누고, 그 판단에 필요한 근거를 바로 볼 수 있게 만드는 것입니다.\n4) 제품 설계 질문 네 가지 이 글의 실무적 가치는 평가를 제품 설계 질문으로 바꿔준다는 데 있습니다. AI 제품을 만들 때 다음 네 가지를 먼저 물어볼 수 있습니다.\n사용자는 실제로 무엇을 확인해야 하는가? 사용자는 무엇을 신뢰 기준으로 삼아 비교할 수 있는가? 전문가가 빠르게 이상함을 감지할 때 쓰는 신호는 무엇인가? 사용자가 한 번에 승인하거나 거절할 수 있는 가장 작은 단위는 무엇인가? 이 질문에 답하면 평가 데이터도 더 잘 생깁니다. 사용자가 승인한 단위, 수정한 단위, 거절한 단위가 그대로 평가 신호가 됩니다. 반대로 최종 산출물 하나만 던지는 제품은 사용자에게도 불친절하고, 팀이 자동 평가를 만들 때도 신호가 흐립니다.\n5) AI 시대의 병목은 생성이 아니라 확인이다 Hamel은 이 논의가 완전히 새로운 디자인 원칙은 아니라고 말합니다. 전문가가 실제로 무엇을 확인하는지 관찰하는 needfinding, 많은 근거를 구조화해 이해하는 sensemaking 같은 오래된 개념과 닿아 있습니다.\n다만 AI 제품에서는 이 문제가 더 선명해졌습니다. 예전에는 사람이 결과물을 만드는 과정에서 자연스럽게 확인도 함께 일어났습니다. AI가 생성 과정을 압축하면서 확인이 별도 병목으로 떠올랐습니다. 따라서 좋은 AI 제품은 \u0026ldquo;무엇을 만들어줄 것인가\u0026quot;만큼이나 \u0026ldquo;사용자가 어떻게 믿을 수 있게 할 것인가\u0026quot;를 설계해야 합니다.\n결론 및 시사점 Hamel의 글은 평가를 모델 품질 측정만으로 좁히지 않습니다. 평가하기 쉬운 제품은 대개 사용하기도 쉽습니다. 출처, 중간 과정, 변경 이유, 미확인 항목을 제품 안에 드러내면 사용자는 AI 결과를 다시 처음부터 검토하지 않아도 됩니다.\n실무적으로는 AI 기능을 붙일 때 최종 출력 화면부터 그리지 말고, 사용자의 검증 흐름부터 그리는 편이 낫습니다. 신뢰는 더 자신 있는 문장으로 생기지 않습니다. 확인할 수 있는 근거와 되돌아갈 수 있는 경로에서 생깁니다.\n한 줄 결론: AI 제품의 경쟁력은 더 그럴듯한 완성본을 만드는 능력이 아니라, 사용자가 결과를 빠르게 믿거나 고칠 수 있게 만드는 검증 설계에서 나온다.\n","wordCount":735,"tags":["AI","evals","product-design","검증","Hamel Husain"],"categories":["AI"],"frameworks":["Verification-first product design","Human-in-the-loop","Progressive disclosure"],"mental_models":["검증 비용","출처 추적","인지 부하"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 제품의 산출물이 평가하기 어렵다면, 그것은 평가 도구 이전에 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호다","데이터 에이전트는 최종 숫자만 보여주기보다 지표 정의, 사용한 쿼리, 중간 계산, 확인하지 못한 항목을 함께 보여줘야 한다","수업 계획 생성기는 완전한 새 계획보다 검증된 기존 계획을 기준점으로 삼고, AI가 바꾼 부분만 diff로 보여줄 때 검토 부담이 줄어든다","의료 보고서처럼 고위험 문서에서는 완성본 생성보다 근거 수집, 모순 표시, 사람의 확인 루프가 먼저여야 한다","좋은 AI 제품 설계는 사용자가 무엇을 확인해야 하는지, 무엇과 비교할 수 있는지, 어떤 작은 단위로 승인할 수 있는지를 먼저 묻는다"],"related":["posts/agentic-code-review-addy-osmani","posts/agent-assisted-qualitative-analysis-core-notes","posts/modern-engineering-values"]},{"title":"Technological Involution - 기술 정체를 넘어 새 기술로 가는 조건","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/technological-involution/","section":"posts","date":"2026-07-01T11:51:33+09:00","lastmod":"2026-07-01T11:51:33+09:00","description":"Rohan Ganapavarapu의 Technological Involution을 바탕으로, 기술 정체와 창업 문화의 매너리즘을 넘어 다시 기술에 대한 확신을 회복하는 조건을 정리했다.","summary":"Rohan Ganapavarapu의 Technological Involution은 기술 정체론, AI, 스타트업 문화, 하드테크를 한데 묶어 묻는다. 우리는 정말 더 이상 만들 것이 없는 시대에 도착했는가, 아니면 기술을 상상하고 믿는 방식이 먼저 낡아버린 것인가.\nTech 핵심 정리 정체의 핵심: 문제는 가능성의 고갈보다 상상력의 수축이다. 우주, 원자력, 시간여행을 꿈꾸던 문화가 이제는 더 많은 AI와 더 많은 소프트웨어만 반복한다. 창업 문화의 함정: 창업자는 자기 확신으로 움직인다고 믿지만, 실제로는 VC, 인플루언서, 액셀러레이터가 유통한 논제를 자기 생각처럼 받아들이기 쉽다. AI의 한계: AI는 소프트웨어 엔지니어링에는 강력하지만, 현실 조직을 바꾸는 일은 여전히 운영 이해, 책임, 도메인 감각을 요구한다. 기회의 위치: 쉬운 SaaS보다 칩, 하드웨어 공급망, 엔터프라이즈 운영, 현장 문제처럼 접촉 비용이 큰 곳에 더 오래가는 가치가 있다. 새 기술의 조건: 좋은 제품은 억지 광고보다 제품 자체의 설득력과 시대적 욕구를 통해 퍼진다. 기술자는 다시 만들고 싶은 것에 대한 순수한 확신을 가져야 한다. 1) 정체는 기술보다 상상력에서 먼저 온다 글의 출발점은 1960년대식 미래 감각입니다. 당시 대중문화는 우주, 원자력, 정보기관의 기묘한 실험, 시간여행 같은 주제를 당연히 다음 세계의 후보로 상상했습니다. 중요한 것은 그 상상 중 일부가 실제 기술 개발의 방향이 되었다는 점입니다.\n","content":"Rohan Ganapavarapu의 Technological Involution은 기술 정체론, AI, 스타트업 문화, 하드테크를 한데 묶어 묻는다. 우리는 정말 더 이상 만들 것이 없는 시대에 도착했는가, 아니면 기술을 상상하고 믿는 방식이 먼저 낡아버린 것인가.\nTech 핵심 정리 정체의 핵심: 문제는 가능성의 고갈보다 상상력의 수축이다. 우주, 원자력, 시간여행을 꿈꾸던 문화가 이제는 더 많은 AI와 더 많은 소프트웨어만 반복한다. 창업 문화의 함정: 창업자는 자기 확신으로 움직인다고 믿지만, 실제로는 VC, 인플루언서, 액셀러레이터가 유통한 논제를 자기 생각처럼 받아들이기 쉽다. AI의 한계: AI는 소프트웨어 엔지니어링에는 강력하지만, 현실 조직을 바꾸는 일은 여전히 운영 이해, 책임, 도메인 감각을 요구한다. 기회의 위치: 쉬운 SaaS보다 칩, 하드웨어 공급망, 엔터프라이즈 운영, 현장 문제처럼 접촉 비용이 큰 곳에 더 오래가는 가치가 있다. 새 기술의 조건: 좋은 제품은 억지 광고보다 제품 자체의 설득력과 시대적 욕구를 통해 퍼진다. 기술자는 다시 만들고 싶은 것에 대한 순수한 확신을 가져야 한다. 1) 정체는 기술보다 상상력에서 먼저 온다 글의 출발점은 1960년대식 미래 감각입니다. 당시 대중문화는 우주, 원자력, 정보기관의 기묘한 실험, 시간여행 같은 주제를 당연히 다음 세계의 후보로 상상했습니다. 중요한 것은 그 상상 중 일부가 실제 기술 개발의 방향이 되었다는 점입니다.\n저자는 오늘날의 미래 상상이 좁아졌다고 봅니다. 우주 이후의 전선은 다시 우주이고, 위험한 기술 이후의 전선은 거의 AI로 수렴합니다. 미래에 대한 호기심은 경외감보다 종말론에 가까워졌고, 기술은 해방의 도구보다 감시와 착취의 장치처럼 여겨집니다.\n여기서 말하는 정체는 단순히 연구 속도가 느려졌다는 뜻이 아닙니다. 사람들이 \u0026ldquo;다음에 무엇이 가능한가\u0026quot;를 묻는 능력을 잃고, 이미 검증된 범주 안에서만 더 세련된 변형을 찾는 상태에 가깝습니다.\n2) 실리콘밸리는 확신을 생산하지 않고 유통한다 저자는 지금의 창업 생태계가 독창적 확신보다 유행하는 논제를 더 잘 퍼뜨린다고 비판합니다. 누군가가 \u0026ldquo;다음 큰 것\u0026quot;을 말하면, 사람들은 그것이 정말 맞아서가 아니라 모두가 믿는 것처럼 보이기 때문에 붙습니다.\n이 구조에서 창업자는 자기 아이디어를 좇는 기술자라기보다, 이미 선택된 내러티브를 실행하는 노동자가 되기 쉽습니다. 펠로십, 대학, 액셀러레이터, 투자자 글, 유명 창업자의 발언이 하나의 압력장처럼 작동합니다. 결과적으로 확신은 발견되는 것이 아니라 주입됩니다.\n저자가 말하는 진짜 기술적 확신은 다릅니다. 현재의 정체가 필연이 아니라 우연적 조건의 결과라고 믿는 태도입니다. 다시 말해 \u0026ldquo;더 이상 만들 것이 없다\u0026quot;가 아니라 \u0026ldquo;우리가 엉뚱한 곳만 보고 있다\u0026quot;는 쪽에 베팅하는 것입니다.\n3) 쉬운 소프트웨어의 시대가 끝나고 있다 소프트웨어는 오랫동안 가장 매력적인 창업 공간이었습니다. 추상화가 깨끗하고, 자본 비용이 낮고, 한 사람이 꽤 많은 것을 이해할 수 있었습니다. 하지만 바로 그 이유로 많은 영역이 이미 파헤쳐졌습니다.\n저자는 이제 창업자 수가 아이디어 수를 앞지른다고 봅니다. 소프트웨어 창업은 장인적 활동보다 공장형 경로에 가까워졌고, 전통적 SaaS나 개발자 도구는 AI와 플랫폼화의 압력 아래 점점 평범해집니다.\n반대로 가치가 쌓이는 곳은 더 어렵고 지저분한 곳입니다. 칩과 하드웨어 공급망, 엔터프라이즈의 복잡한 운영, 의료나 오프라인 비즈니스의 백오피스처럼 직접 들어가 보지 않으면 구조를 이해하기 어려운 영역입니다. 여기서는 코드를 잘 쓰는 것만으로 충분하지 않습니다. 현실의 제약을 견디며 시스템을 바꾸는 운영 능력이 먼저 필요합니다.\n4) AI는 도구이지 진보 그 자체가 아니다 저자는 AI를 낮게 평가하지 않습니다. 오히려 소프트웨어 엔지니어링에서는 매우 강력한 사용 사례라고 말합니다. 다만 AI의 발전이 곧바로 사회 전체의 기술 진보를 뜻하지는 않는다고 선을 긋습니다.\n기업 현장에서는 토큰 비용보다 큰 가치를 안정적으로 만들기 어렵고, AI가 많은 일을 자동화하더라도 어떤 일을 바꿔야 하는지 판단하는 문제는 남습니다. 조직의 진짜 원천 데이터가 어디 있는지, 어떤 프로세스가 부하를 떠받치는지, 기존 업무를 자동화할지 처음부터 재설계할지 결정해야 합니다.\n또 하나의 한계는 평균 회귀입니다. AI에게 스타트업 아이디어나 엔지니어링 조언을 물으면 대체로 무난하고 합의된 답을 냅니다. 이 점은 오히려 인간에게 기회가 됩니다. 모두가 같은 조언을 받는 시대에는 특이하지만 맞을 수 있는 생각의 가치가 커집니다.\n5) 현실 접촉이 확신을 만든다 글에서 가장 실용적인 문장은 \u0026ldquo;확신은 현실과의 접촉에서 나온다\u0026quot;는 주장입니다. 책상 앞에서 세운 사업 논리는 현장에 닿기 전까지 대개 틀립니다. 하지만 그 접촉을 견디면 무엇이 진짜 문제인지 보입니다.\n예를 들어 의료 클리닉 백오피스 문제를 풀려면 단순히 AI 에이전트를 붙이는 것으로는 부족합니다. 실제 치과나 병원에서 업무가 어떻게 흐르는지 보고, 왜 아직도 낡은 시스템이 남아 있는지 이해해야 합니다. 그 다음에야 소프트웨어가 무엇을 단순화할 수 있는지 보입니다.\n이는 젊은 창업자에게도 같은 메시지입니다. 경험이 없다는 사실을 정체성으로 삼을 필요는 없습니다. 직접 들어가서 배우면 됩니다. 좋은 운영자가 된 뒤에야 좋은 기술 제품의 모양도 더 선명해집니다.\n6) 새 미디어가 보여준 길, 새 기술도 따라갈 수 있을까 저자는 희망의 근거를 새 미디어에서 찾습니다. 최근의 영화, 유튜브 출신 제작자, 틱톡을 통한 입소문은 기존 미디어 문법 밖에서도 강한 작품이 자본주의의 레일을 타고 퍼질 수 있음을 보여줍니다.\n핵심은 인간의 잠재된 감정과 욕구를 더 잘 포착하는 것입니다. 새 미디어는 반드시 거대한 소재를 다루지 않습니다. 오히려 평범한 인간 경험을 새롭게 드러내며 사람들을 움직입니다. 저자는 새 기술도 비슷해야 한다고 봅니다.\n제품이 좋다면 억지 바이럴이나 숨은 광고에만 기대지 않아도 됩니다. 기술 자체가 품고 있는 세계관, 쓸모, 아름다움이 사람을 움직여야 합니다. 그것이 기술에 대한 확신이고, 기술자가 다시 회복해야 할 태도입니다.\n창업자와 기술자에게 남는 질문 이 글은 \u0026ldquo;하드테크만 하라\u0026quot;는 단순한 조언이 아닙니다. 더 정확히는 이미 모두가 달려드는 쉬운 추상화 밖으로 나가라는 말입니다.\n내가 믿는 문제는 내가 직접 본 문제인가, 아니면 누군가가 유통한 논제인가? 이 제품은 광고 없이도 누군가에게 말하고 싶어질 만큼 강한가? AI가 평균적인 답을 줄 때, 나는 어디에서 다른 관점을 만들 수 있는가? 코드를 쓰기 전에 현실의 운영 구조를 충분히 이해했는가? 이 일이 기술을 인간에게 더 가깝게 만드는가, 아니면 기존 착취 방식을 더 매끄럽게 만드는가? 좋은 창업은 시장의 빈칸을 채우는 것만이 아닙니다. 아직 사람들이 제대로 상상하지 못한 가능성을 현실로 끌어오는 일입니다.\n결론 및 시사점 한 줄 결론: 기술 정체를 벗어나는 길은 더 많은 유행을 좇는 것이 아니라, 현실과 직접 부딪혀 생긴 확신으로 새로운 기술의 가능성을 다시 여는 것이다.\nTechnological Involution은 AI 시대의 창업자에게 불편한 질문을 던집니다. 당신의 확신은 직접 본 세계에서 온 것인가, 아니면 모두가 믿는다고 말하는 이야기에서 온 것인가.\nAI가 더 많은 코드를 쓰고 더 많은 조언을 내놓을수록, 차이는 오히려 기술자의 취향, 현장 감각, 비평 능력, 비정상적으로 강한 호기심에서 납니다. 다음 기술의 기회는 편한 추상화 안이 아니라, 아직 거칠고 귀찮고 설명하기 어려운 현실 속에 있을 가능성이 큽니다.\n","wordCount":892,"tags":["AI","스타트업","기술철학","하드테크","실리콘밸리"],"categories":["AI"],"frameworks":["Technological Stagnation","First Principles","Reality Contact","Bits vs Atoms"],"mental_models":["Involution","Conviction","Commoditization","Contact with Reality"],"philosophy_type":"technology-strategy","schema_type":"Article","actionable":true,"priority":"medium","key_points":["기술 정체는 인간이 도달 가능한 가능성의 끝이 아니라, 소프트웨어와 기존 창업 문법에 갇힌 상상력의 수축으로 볼 수 있다.","실리콘밸리는 창업자를 기술자보다 내러티브 소비자에 가깝게 만들었고, 유행하는 논제가 곧 확신처럼 보이는 구조를 만들었다.","AI만으로 넓은 의미의 기술 진보가 자동 발생하지 않는다. 누군가는 현실의 운영 문제를 직접 겪고, 그 접촉에서 제품의 논리를 다시 세워야 한다.","새 기술은 새 미디어처럼 인간의 잠재된 욕구를 더 잘 드러내고, 제품 자체의 힘으로 퍼질 때 설득력을 얻는다."],"related":["posts/software-is-becoming-marketing","posts/ai-capability-not-cost-reduction","posts/agentic-engineering-management"]},{"title":"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-30T16:50:40+09:00","lastmod":"2026-06-30T16:50:40+09:00","description":"Swizec Teller의 글을 바탕으로, 낡은 청구 스크립트 문제를 해결하려면 코드보다 먼저 비즈니스 개념과 데이터 모델을 다시 잡아야 한다는 교훈을 정리했다.","summary":"Swizec Teller의 Code is the easy part, or how we refactored half the business to fix a janky script는 낡은 청구 스크립트를 고친 이야기처럼 시작합니다. 하지만 핵심은 코드가 아닙니다. 회사가 커지면서 비즈니스 개념, 데이터 모델, 운영 습관, 고객 셀프서비스, 재무팀 도구까지 함께 바꿔야 했던 리팩터링 이야기입니다.\n원문: Code is the easy part, or how we refactored half the business to fix a janky script\nRefactor 핵심 정리 표면 문제: 낡은 Python 스크립트가 모든 인보이스를 발행했고, 월말 청구는 종종 밤샘 작업이 됐다. 진짜 문제: 사용자, 기관, 랩, 구매 부서, 영업 구역, 데이터 공유 구조가 하나의 데이터 모델에 섞여 있었다. 핵심 해법: 협업 구조와 청구 구조를 분리하고, \u0026ldquo;이 주문을 어떻게 청구할까?\u0026ldquo;에 답하는 Billing Entities를 만들었다. 결과: 월말 청구가 일주일에서 2일로 줄었고, 고객은 직접 청구 정보와 구매 주문서를 관리할 수 있게 됐다. 실무 교훈: 복잡한 스크립트는 대개 원인이 아니라 증상이다. 먼저 도메인 모델이 현실을 제대로 담는지 봐야 한다. 1) 회사가 커지면 예외 처리도 제품이 된다 Swizec이 합류한 2024년 8월, 회사는 연간 반복 매출 약 2천만 달러에 가까워지고 있었습니다. 2026년 6월에는 1억 달러 ARR이 가시권에 들어왔다고 합니다. 매출은 빠르게 커졌지만, 청구 시스템은 훨씬 작은 회사였을 때의 방식에 머물러 있었습니다.\n","content":"Swizec Teller의 Code is the easy part, or how we refactored half the business to fix a janky script는 낡은 청구 스크립트를 고친 이야기처럼 시작합니다. 하지만 핵심은 코드가 아닙니다. 회사가 커지면서 비즈니스 개념, 데이터 모델, 운영 습관, 고객 셀프서비스, 재무팀 도구까지 함께 바꿔야 했던 리팩터링 이야기입니다.\n원문: Code is the easy part, or how we refactored half the business to fix a janky script\nRefactor 핵심 정리 표면 문제: 낡은 Python 스크립트가 모든 인보이스를 발행했고, 월말 청구는 종종 밤샘 작업이 됐다. 진짜 문제: 사용자, 기관, 랩, 구매 부서, 영업 구역, 데이터 공유 구조가 하나의 데이터 모델에 섞여 있었다. 핵심 해법: 협업 구조와 청구 구조를 분리하고, \u0026ldquo;이 주문을 어떻게 청구할까?\u0026ldquo;에 답하는 Billing Entities를 만들었다. 결과: 월말 청구가 일주일에서 2일로 줄었고, 고객은 직접 청구 정보와 구매 주문서를 관리할 수 있게 됐다. 실무 교훈: 복잡한 스크립트는 대개 원인이 아니라 증상이다. 먼저 도메인 모델이 현실을 제대로 담는지 봐야 한다. 1) 회사가 커지면 예외 처리도 제품이 된다 Swizec이 합류한 2024년 8월, 회사는 연간 반복 매출 약 2천만 달러에 가까워지고 있었습니다. 2026년 6월에는 1억 달러 ARR이 가시권에 들어왔다고 합니다. 매출은 빠르게 커졌지만, 청구 시스템은 훨씬 작은 회사였을 때의 방식에 머물러 있었습니다.\n당시에는 Python 스크립트 하나가 모든 인보이스를 발행했습니다. 고객은 청구 정보 변경을 위해 지원팀에 연락했고, 지원팀과 재무팀은 고객을 만족시키기 위해 각종 예외를 받아들였습니다. 문제는 그 예외들이 문서나 코드에 명확히 남지 않았다는 점입니다. 누군가가 기억하고, 누군가가 매달 조심스럽게 처리하는 방식이었습니다.\n작은 회사에서는 이런 방식이 통합니다. 고객 몇 명의 특수한 사정을 사람이 알고 있으면 됩니다. 하지만 고객 수와 주문량이 늘면 기억은 시스템이 될 수 없습니다. 사람의 머릿속에 있던 규칙은 병목이 되고, 월말 청구는 회사 전체의 스트레스가 됩니다.\n2) 코드보다 데이터 모델이 먼저였다 원문의 가장 중요한 전환점은 \u0026ldquo;스크립트를 어떻게 고칠까?\u0026ldquo;가 아니라 \u0026ldquo;무엇을 청구 단위로 볼 것인가?\u0026ldquo;입니다.\n기존 모델에서는 사용자, 기관, 랩, 협업 그룹, 영업 구역, 구매 부서의 요구가 한 구조 안에 뒤섞여 있었습니다. 어떤 사용자는 자기 앞으로 인보이스를 받고 싶어 하고, 어떤 사용자는 구매 부서가 처리하길 원합니다. 어떤 사용자는 프로젝트에 따라 기관을 오가기도 합니다. 영업팀은 같은 구조를 고객 구분과 보상 계산에 쓰고, 고객은 협업과 데이터 공유에 씁니다.\n같은 개념을 여러 부서가 서로 다른 목적으로 보고 있었던 셈입니다. 모두의 관점이 맞지만, 모두의 요구를 한 데이터 모델로 처리하려 하니 시스템은 점점 진흙탕이 됩니다.\n해법은 Billing Entities였습니다. 이 새 모델은 단순한 질문 하나에 답합니다.\n이 주문을 어떻게 청구할 것인가?\n사용자가 어떤 랩에 속하는지, 어떤 기관과 협업하는지, 어떤 영업 구역에 들어가는지는 별도의 문제로 분리합니다. 청구 시스템은 주문이 들어왔을 때 필요한 청구 주체와 결제 정보만 명확히 알면 됩니다. 큰 문제를 푼 비결은 더 많은 조건문이 아니라, 질문을 작게 만든 새 도메인 개념이었습니다.\n3) 관찰이 자동화보다 빨랐다 흥미로운 부분은 AI와 자동화의 쓰임입니다. 팀은 구매 주문서 검증 규칙을 자동화하려고 했고, Claude에게 검증기를 써보게도 했습니다. 하지만 나온 결과는 너무 복잡한 정규식 파서였습니다.\n그 다음에 팀은 재무팀이 실제로 월말 청구를 처리하는 모습을 봤습니다. 그러자 규칙은 훨씬 단순했습니다. 구매 주문서 문자열이 일정한 길이와 3~4글자 접두사 패턴으로 정렬되는지만 봐도 중요한 오류를 잡을 수 있었습니다. 실제 작업을 관찰하니, 가장 느린 수동 검증 단계를 빠르게 제거할 수 있었습니다.\n여기서 교훈은 명확합니다. 자동화는 현장을 이해한 뒤에 해야 합니다. 사람의 작업을 보지 않고 규칙만 물어보면, 누구나 예외를 먼저 떠올립니다. 실제로 옆에서 보면 의사결정 기준은 더 작고 선명할 때가 많습니다.\n4) 리팩터링은 프로젝트가 아니라 로드맵이었다 이 작업은 스크립트 하나를 고치는 것으로 끝나지 않았습니다. 사용자가 직접 랩을 만들고, 청구 정보를 관리하고, 결제 수단을 공유하고, 구매 주문서를 등록할 수 있는 기능이 필요했습니다. 기존 청구 정보는 새 모델로 이관해야 했고, 인보이스 발행 스크립트는 다시 실행 가능하고 멱등적으로 바뀌어야 했습니다. 재무팀에는 청구 예외, 미청구 항목, 수동 검토 대상을 관리하는 도구가 필요했습니다.\nSwizec은 이 일을 6개월 이상, 최소 6명이 참여한 작업으로 설명합니다. 중요한 점은 모든 것을 멈추고 새 시스템을 만든 것이 아니라는 점입니다. 비즈니스는 계속 커지고 있었고, 하루 수천 건의 주문을 처리해야 했습니다.\n그래서 팀은 한동안 이중 모드로 운영했습니다. Billing Entity가 있으면 새 방식으로 처리하고, 없으면 기존 방식으로 되돌아갔습니다. 이 방식은 재무팀에 혼란을 주기도 했지만, 한 달에 한 번만 드러나는 치명적인 예외를 찾는 데 도움이 됐습니다. 큰 리팩터링은 실험실에서 완성한 뒤 한 번에 교체하는 일이 아니라, 실제 운영 속에서 위험을 줄여 가는 일입니다.\n5) 결과: 청구는 빨라졌고 제품은 강해졌다 최종 결과는 명확했습니다. 월말 청구는 일주일짜리 작업에서 2일짜리 작업으로 줄었습니다. 재무팀은 덜 불안해졌고, 고객은 직접 청구 정보를 관리하는 새 권한을 얻었습니다. 수백 개의 랩이 만들어졌고, 수십 개의 고객 제공 Billing Entity가 생겼습니다.\n이 변화의 본질은 비용 절감보다 큽니다. 청구는 회사가 고객과 돈을 주고받는 핵심 인터페이스입니다. 이 영역이 사람이 기억하는 예외와 불안정한 스크립트에 의존하면, 성장은 곧 운영 리스크가 됩니다. 반대로 도메인 모델이 정리되고 고객이 직접 관리할 수 있게 되면, 회사는 더 큰 매출을 감당할 수 있습니다.\n코드는 쉬운 부분이라는 말은 코드가 중요하지 않다는 뜻이 아닙니다. 코드가 진짜 문제를 표현할 수 있을 때 쉬워진다는 뜻입니다. 잘못된 모델 위에서는 스크립트가 계속 커지고, 올바른 모델 위에서는 코드가 작아집니다.\n결론 및 시사점 한 줄 결론: 낡은 스크립트를 고치는 가장 빠른 길은 스크립트에 조건문을 더하는 것이 아니라, 비즈니스가 실제로 구분하는 개념을 데이터 모델에 반영하는 것이다.\n이 글은 리팩터링을 기술 부채 청소로만 보면 놓치는 점을 보여줍니다. 진짜 부채는 코드 안에만 있지 않습니다. 운영팀의 기억, 고객 지원팀의 수동 처리, 재무팀의 예외 목록, 고객이 직접 바꿀 수 없는 정보에도 쌓입니다.\n그래서 큰 리팩터링을 시작할 때 첫 질문은 \u0026ldquo;어느 파일을 고칠까?\u0026ldquo;가 아니라 \u0026ldquo;우리가 한 단어로 부르는 이 개념을 모든 부서가 같은 뜻으로 쓰고 있는가?\u0026ldquo;여야 합니다. 그 답이 아니면, 코드 수정은 잠깐의 진통제일 뿐입니다.\n","wordCount":842,"tags":["software-engineering","refactoring","billing","domain-model","startup"],"categories":["Software Engineering"],"frameworks":["Domain Modeling","Incremental Refactoring","Socio-technical Systems"],"mental_models":["Data model first","Chesterton's Fence","Strangler Fig Pattern","Second-order Effects"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["문제의 표면은 낡은 Python 청구 스크립트였지만, 실제 병목은 고객·기관·랩·구매 부서·영업 구역을 한 데이터 모델에 억지로 담은 데 있었다.","2024년 8월 약 2천만 달러 ARR 근처였던 회사가 2026년 6월 1억 달러 ARR을 바라보게 되자, 사람이 기억으로 운영하던 청구 예외가 더 이상 버티지 못했다.","핵심 해법은 협업 구조와 별개로 '이 주문을 어떻게 청구할 것인가'만 답하는 Billing Entities를 도입한 것이다.","6개월 이상, 최소 6명이 참여했고, 월말 청구는 일주일짜리 스트레스 작업에서 2일짜리 자동화 흐름으로 줄었다."],"related":["posts/agentic-software-engineering","posts/the-20-software-engineering-laws-summary","posts/why-senior-developers-fail-to-communicate-summary"]},{"title":"Software is becoming marketing - 소프트웨어 풍요 시대의 제품과 일자리","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/software-is-becoming-marketing/","section":"posts","date":"2026-06-30T15:54:21+09:00","lastmod":"2026-06-30T15:54:21+09:00","description":"Tereza Tizkova의 Software is becoming marketing을 바탕으로, AI가 소프트웨어 제작 비용을 낮출 때 제품 시장과 개발자 커리어가 어떻게 바뀌는지 정리했다.","summary":"Tereza Tizkova의 글 Software is becoming marketing은 AI가 코드를 대량 생산할 수 있게 된 뒤 소프트웨어 산업이 어디로 움직이는지 다룹니다. 핵심은 소프트웨어가 더 이상 희소한 산출물이 아니라, 마케팅처럼 누구나 만들고 누구나 평가하는 영역에 가까워진다는 주장입니다.\nAI 핵심 정리 진입 장벽 하락: 누구나 vibecoding으로 간단한 SaaS를 만들 수 있으면, 소프트웨어는 수학보다 마케팅에 가까운 평가 대상이 된다. 헌신 약화: 프로젝트 관리 도구가 3개일 때는 하나를 고르지만, 300개가 있고 직접 만들 수도 있으면 고객의 정착률은 낮아진다. 중간층 압박: 단순 기능을 월 $50에 파는 중간 규모 SaaS는 개인 제작 도구와 거대 플랫폼 사이에서 설 자리가 좁아진다. 서비스화: 기업은 회계 소프트웨어보다 장부 마감이라는 결과에 더 큰 돈을 쓴다. AI 시대의 큰 기회는 도구가 아니라 결과 판매다. 커리어 전략: 그저 괜찮은 개발자보다 기술에 디자인, 유통, 브랜드, 도메인 전문성을 결합한 사람이 더 강해진다. 1) 소프트웨어는 더 쉽게 평가받는 일이 된다 글의 출발점은 진입 장벽과 외부 평가 가능성입니다. 수학처럼 언어 자체가 어려운 분야에서는 비전문가가 쉽게 끼어들기 어렵습니다. 반대로 마케팅, 디자인, 글쓰기처럼 결과물이 눈앞에 보이는 분야에서는 누구나 의견을 냅니다.\n","content":"Tereza Tizkova의 글 Software is becoming marketing은 AI가 코드를 대량 생산할 수 있게 된 뒤 소프트웨어 산업이 어디로 움직이는지 다룹니다. 핵심은 소프트웨어가 더 이상 희소한 산출물이 아니라, 마케팅처럼 누구나 만들고 누구나 평가하는 영역에 가까워진다는 주장입니다.\nAI 핵심 정리 진입 장벽 하락: 누구나 vibecoding으로 간단한 SaaS를 만들 수 있으면, 소프트웨어는 수학보다 마케팅에 가까운 평가 대상이 된다. 헌신 약화: 프로젝트 관리 도구가 3개일 때는 하나를 고르지만, 300개가 있고 직접 만들 수도 있으면 고객의 정착률은 낮아진다. 중간층 압박: 단순 기능을 월 $50에 파는 중간 규모 SaaS는 개인 제작 도구와 거대 플랫폼 사이에서 설 자리가 좁아진다. 서비스화: 기업은 회계 소프트웨어보다 장부 마감이라는 결과에 더 큰 돈을 쓴다. AI 시대의 큰 기회는 도구가 아니라 결과 판매다. 커리어 전략: 그저 괜찮은 개발자보다 기술에 디자인, 유통, 브랜드, 도메인 전문성을 결합한 사람이 더 강해진다. 1) 소프트웨어는 더 쉽게 평가받는 일이 된다 글의 출발점은 진입 장벽과 외부 평가 가능성입니다. 수학처럼 언어 자체가 어려운 분야에서는 비전문가가 쉽게 끼어들기 어렵습니다. 반대로 마케팅, 디자인, 글쓰기처럼 결과물이 눈앞에 보이는 분야에서는 누구나 의견을 냅니다.\nTizkova는 소프트웨어가 후자에 가까워지고 있다고 봅니다. 예전에는 SaaS를 만들려면 개발자를 고용하거나 긴 시간을 들여야 했습니다. 이제는 AI를 붙잡고 개인용 도구를 만들 수 있습니다. 그러면 소프트웨어는 \u0026ldquo;전문가만 만드는 것\u0026quot;에서 \u0026ldquo;나도 만들 수 있고 평가할 수 있는 것\u0026quot;으로 바뀝니다.\n이 변화는 개발자의 보상 구조에도 영향을 줍니다. 진입 장벽이 낮고 결과물이 쉽게 평가되는 분야에서는 평균 보상이 눌리고, 상위권의 보상은 더 커지는 경향이 있습니다. 글쓰기, 디자인, 마케팅처럼 \u0026ldquo;그럭저럭 하는 사람\u0026quot;은 많아지고, 검증된 최고 수준의 사람에게 프리미엄이 붙는 구조입니다.\n2) 선택지가 많으면 고객은 덜 정착한다 두 번째 변화는 선택지의 폭발입니다. 제품이 적을 때 고객은 하나를 고르고 거기에 적응합니다. 선택지가 너무 많아지면 상황이 달라집니다. 더 나은 대안이 있을 것 같고, 내 상황에 딱 맞는 도구를 직접 만들 수도 있다는 생각이 생깁니다.\n이 지점에서 소프트웨어는 물처럼 됩니다. 필수적이지만 차별화하기 어려운 기반재가 됩니다. 고객은 도구 자체보다 \u0026ldquo;내 문제에 얼마나 정확히 맞는가\u0026quot;를 더 따집니다.\nSaaS 입장에서는 이게 무섭습니다. 단순히 기능 목록을 늘리는 것만으로는 고객을 붙잡기 어렵습니다. 고객은 더 싼 대안, 더 특화된 대안, 직접 만든 대안을 계속 비교합니다. 선택지가 많아질수록 만족도와 충성도가 같이 올라가는 것이 아니라, 오히려 정착이 어려워질 수 있습니다.\n3) 중간 규모 SaaS가 가장 위험하다 Tizkova는 SaaS 시장이 앱스토어처럼 파워 법칙 구조에 가까워질 수 있다고 봅니다. 맨 위에는 신뢰와 유통을 장악한 거대 플랫폼이 있고, 맨 아래에는 거의 비용 없이 만들어지는 초개인화 도구가 길게 늘어납니다.\n가장 애매한 위치는 중간입니다. 특정 기능 하나를 꽤 잘 만들고 월 구독료를 받던 회사는 두 방향에서 압박받습니다.\n개인이나 팀이 AI로 비슷한 내부 도구를 빠르게 만든다. 거대 플랫폼은 인증, 결제, 클라우드, 검색, 배포, 신뢰를 묶어서 제공한다. 그래서 단순한 \u0026ldquo;좋은 기능\u0026quot;만으로는 해자가 약해집니다. 앞으로 더 중요한 것은 기능 자체보다 신뢰, 유통, 정체성, 생태계입니다. 사용자는 직접 만든 노트 앱을 쓸 수는 있어도, 인증과 저장과 공유와 발견은 여전히 큰 플랫폼 위에서 처리하고 싶어 합니다.\n4) 제품보다 결과를 팔아야 한다 가장 실용적인 결론은 \u0026ldquo;소프트웨어 제품\u0026quot;보다 \u0026ldquo;서비스 결과\u0026quot;를 보라는 점입니다. 기업은 소프트웨어 비용보다 서비스 비용에 훨씬 더 많은 돈을 씁니다. 회계 소프트웨어보다 회계사가 장부를 닫아주는 일에 더 큰 비용을 지불하는 식입니다.\nAI가 반복 작업을 처리할수록, 회사는 더 좋은 회계 도구가 아니라 \u0026ldquo;장부 마감 완료\u0026quot;를 사고 싶어 합니다. 세무, 법무, 채용, 고객 지원, 운영처럼 판단과 책임이 섞인 영역에서도 비슷한 변화가 생길 수 있습니다.\n이때 전문가는 한 회사에 정규직으로 묶일 필요가 줄어듭니다. AI가 반복 업무를 맡고, 전문가는 판단이 필요한 순간에 개입합니다. 남는 가치는 판단력, 브랜드, 실적, 네트워크, 도메인 경험입니다.\n개발자에게 주는 메시지 이 글은 개발자가 사라진다고 말하지 않습니다. 다만 \u0026ldquo;소프트웨어를 만들 줄 안다\u0026quot;는 사실 하나만으로 얻던 희소성이 줄어든다고 말합니다.\n그래서 전략은 두 가지입니다.\n첫째, 파워 법칙의 오른쪽 끝으로 가는 것입니다. 특정 분야에서 압도적으로 잘해서 누구나 인정하는 사람이 되는 길입니다.\n둘째, 기술을 다른 능력과 결합하는 것입니다. 디자인을 아는 개발자, 유통을 아는 개발자, 특정 산업을 깊게 아는 개발자, 고객 문제를 직접 팔 수 있는 개발자가 더 강해집니다.\n반대로 가장 위험한 위치는 \u0026ldquo;그냥 무난한 소프트웨어만 만드는 사람\u0026quot;입니다. AI가 단순 구현을 싸게 만들수록, 무난함은 방어력이 약한 포지션이 됩니다.\n결론 및 시사점 한 줄 결론: AI 시대의 소프트웨어 경쟁력은 코드를 만드는 능력에서 고객이 원하는 결과를 설계하고 전달하는 능력으로 이동한다.\n소프트웨어가 풍요로워질수록 코드는 덜 희소해지고, 문제 정의와 취향, 유통, 신뢰, 도메인 판단은 더 희소해집니다. 제품을 만들 때도 \u0026ldquo;어떤 기능을 팔 것인가\u0026quot;보다 \u0026ldquo;고객이 실제로 끝내고 싶은 일이 무엇인가\u0026quot;를 먼저 봐야 합니다.\n개발자에게도 같은 원리가 적용됩니다. 코딩 실력은 여전히 중요하지만, 그것만으로 충분한 시대는 약해지고 있습니다. 앞으로의 강한 포지션은 기술을 기반으로 하되, 고객의 언어와 시장의 압력까지 함께 읽는 사람에게 갈 가능성이 큽니다.\n","wordCount":692,"tags":["AI","소프트웨어","SaaS","vibecoding","제품전략"],"categories":["AI"],"frameworks":["Abundance economics","Power law","Jobs-to-be-done"],"mental_models":["Commoditization","Paradox of choice","Distribution moat","Outcome over tool"],"philosophy_type":"technology-strategy","schema_type":"Article","actionable":true,"priority":"medium","key_points":["AI와 vibecoding은 소프트웨어 진입 장벽을 낮추고, 외부인이 결과물을 직접 평가하기 쉬운 영역으로 소프트웨어를 이동시킨다.","선택지가 너무 많아지면 사용자는 특정 SaaS에 오래 헌신하기보다 직접 만들거나 더 맞춤형 대안을 찾으려 한다.","중간 규모 SaaS는 무료에 가까운 개인 제작 도구와 거대 플랫폼의 신뢰·유통·인증 능력 사이에서 압박받는다.","다음 기회는 더 좋은 도구 판매보다 고객이 실제로 사는 결과를 서비스처럼 제공하는 쪽에 있다."],"related":["posts/ai-capability-not-cost-reduction","posts/why-ai-hasnt-replaced-software-engineers","posts/agentic-software-engineering"]},{"title":"AI-Native Divide — AI를 생활 인프라로 쓰는 사람과 아닌 사람의 격차","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-native-divide-daniel-miessler/","section":"posts","date":"2026-06-27T18:22:41+09:00","lastmod":"2026-06-27T18:22:41+09:00","description":"Daniel Miessler의 'The Coming Divide: AI-Native or Left Behind'를 바탕으로, AI 회의론과 별개로 개인의 학습·업무 역량 격차가 어떻게 커질 수 있는지 정리했다.","summary":"Daniel Miessler가 2026년 6월 25일에 쓴 \u0026ldquo;The Coming Divide: AI-Native or Left Behind\u0026rdquo; 는 AI에 대한 실망과 회의론이 커지는 시점에 던지는 경고입니다. 그는 AI 산업의 거품, 막대한 투자, 추론 비용의 불확실성을 부정하지 않습니다. 다만 그 우려가 \u0026ldquo;AI는 또 하나의 Crypto/NFT였으니 무시해도 된다\u0026quot;는 결론으로 굳어지는 순간, 개인의 역량 격차가 빠르게 벌어진다고 봅니다.\n원문: The Coming Divide: AI-Native or Left Behind\nTL;DR 핵심 정리 핵심 주장: AI 거품을 비판하는 것과 AI 활용 능력을 포기하는 것은 다른 문제다. 전자는 건강한 경계지만, 후자는 앞으로의 기회 비용이 커질 수 있다. 격차의 본질: AI-native인 사람은 AI를 업무, 학습, 창작, 의사결정에 계속 엮고, 그렇지 않은 사람은 같은 일을 더 느리고 좁은 도구 세트로 처리한다. 독서 비유: 책을 꾸준히 읽는 사람과 학교 이후 책을 멀리한 사람의 차이처럼, AI 사용 습관은 세계를 보는 방식과 가능한 행동의 범위를 바꾼다. 과신 금지: Miessler는 AI를 완벽하거나 신성한 대상으로 보지 말라고 한다. 도덕적 문제, 과사용 위험, 산업적 거품을 인정하되 도구적 가치는 붙잡아야 한다. 실천 지점: 자신과 가까운 사람을 AI-native camp로 옮기는 것, 즉 매일의 일에 AI를 실제로 연결해보게 하는 것이 중요하다. 1) AI 회의론이 틀렸다는 말이 아니다 이 글의 좋은 점은 AI 비판을 단순히 무지나 반기술 정서로 몰아가지 않는다는 데 있습니다. Miessler는 수천억 달러 규모의 자금이 AI 산업에 흘러들어가고 있고, 추론 비용이 아직 명확하지 않으며, 많은 기업과 투자자가 과장된 약속 위에서 움직이고 있다는 점을 인정합니다.\n","content":"Daniel Miessler가 2026년 6월 25일에 쓴 \u0026ldquo;The Coming Divide: AI-Native or Left Behind\u0026rdquo; 는 AI에 대한 실망과 회의론이 커지는 시점에 던지는 경고입니다. 그는 AI 산업의 거품, 막대한 투자, 추론 비용의 불확실성을 부정하지 않습니다. 다만 그 우려가 \u0026ldquo;AI는 또 하나의 Crypto/NFT였으니 무시해도 된다\u0026quot;는 결론으로 굳어지는 순간, 개인의 역량 격차가 빠르게 벌어진다고 봅니다.\n원문: The Coming Divide: AI-Native or Left Behind\nTL;DR 핵심 정리 핵심 주장: AI 거품을 비판하는 것과 AI 활용 능력을 포기하는 것은 다른 문제다. 전자는 건강한 경계지만, 후자는 앞으로의 기회 비용이 커질 수 있다. 격차의 본질: AI-native인 사람은 AI를 업무, 학습, 창작, 의사결정에 계속 엮고, 그렇지 않은 사람은 같은 일을 더 느리고 좁은 도구 세트로 처리한다. 독서 비유: 책을 꾸준히 읽는 사람과 학교 이후 책을 멀리한 사람의 차이처럼, AI 사용 습관은 세계를 보는 방식과 가능한 행동의 범위를 바꾼다. 과신 금지: Miessler는 AI를 완벽하거나 신성한 대상으로 보지 말라고 한다. 도덕적 문제, 과사용 위험, 산업적 거품을 인정하되 도구적 가치는 붙잡아야 한다. 실천 지점: 자신과 가까운 사람을 AI-native camp로 옮기는 것, 즉 매일의 일에 AI를 실제로 연결해보게 하는 것이 중요하다. 1) AI 회의론이 틀렸다는 말이 아니다 이 글의 좋은 점은 AI 비판을 단순히 무지나 반기술 정서로 몰아가지 않는다는 데 있습니다. Miessler는 수천억 달러 규모의 자금이 AI 산업에 흘러들어가고 있고, 추론 비용이 아직 명확하지 않으며, 많은 기업과 투자자가 과장된 약속 위에서 움직이고 있다는 점을 인정합니다.\n즉 \u0026ldquo;AI 산업에는 거품과 위험이 있다\u0026quot;는 판단 자체는 합리적일 수 있습니다. 문제는 그 판단이 너무 쉽게 다음 문장으로 넘어갈 때 생깁니다.\nAI는 전부 사기다. 그래서 배울 필요가 없다. 잠깐 유행하다 사라질 것이다. 쓰는 사람은 과장에 속은 사람이다. Miessler가 걱정하는 것은 바로 이 태도입니다. 산업 구조를 비판하는 것과 개인이 새로운 도구를 익히지 않는 것은 별개의 선택입니다. 전자는 사고력이고, 후자는 학습 포기일 수 있습니다.\n2) 격차는 기술 직군 안에서만 벌어지지 않는다 AI-native라는 말은 단순히 프롬프트를 잘 쓰는 개발자나 에이전트 코딩을 하는 엔지니어만 뜻하지 않습니다. 저자가 보는 더 큰 변화는 AI를 자기 일의 기본 장비로 엮는 사람 과 AI를 최대한 피하는 사람 사이의 차이입니다.\nAI를 자주 쓰는 사람은 다음과 같은 일을 더 쉽게 반복합니다.\n막연한 생각을 초안으로 만든다. 낯선 분야를 빠르게 훑고 질문을 정교하게 만든다. 반복 작업을 자동화하거나 반자동화한다. 글, 코드, 기획, 조사, 학습의 첫 번째 마찰을 낮춘다. 혼자서는 미뤘을 일을 대화형 협업처럼 밀어붙인다. 반대로 AI를 피하는 사람은 같은 문제를 기존 방식으로만 풉니다. 물론 기존 방식이 항상 나쁜 것은 아닙니다. 하지만 문제는 속도와 반복 횟수입니다. 같은 시간 동안 더 많은 시도, 더 많은 피드백, 더 많은 초안을 만들 수 있는 사람이 있다면, 몇 달 뒤에는 결과물의 총량과 학습량이 달라집니다.\n3) 독서 습관과 비슷하지만 훨씬 빠르다 Miessler는 AI-native 격차를 독서 습관에 비유합니다. 책을 꾸준히 읽는 사람은 세계를 보는 방식, 대화의 깊이, 선택지의 폭이 달라집니다. 책을 전혀 읽지 않는 사람과는 단순한 정보량 이상의 차이가 생깁니다.\nAI도 비슷하지만 속도가 더 빠릅니다. 독서는 느린 축적입니다. AI 활용은 읽기, 쓰기, 검색, 실험, 자동화가 한꺼번에 붙은 축적입니다. 그래서 작은 차이가 더 빨리 누적됩니다.\n예를 들어 어떤 사람이 매일 AI로 다음을 한다고 해봅시다.\n읽은 글을 자기 언어로 재구성한다. 업무 아이디어를 10개씩 변주한다. 막힌 개념을 여러 비유로 설명받는다. 반복되는 문서 작업을 템플릿화한다. 자기 판단을 반박하는 질문을 만든다. 이 사람은 단순히 \u0026ldquo;AI를 써본 사람\u0026quot;이 아니라, 생각과 실행의 루프 자체를 바꾼 사람에 가깝습니다. 도구가 생활 리듬 안으로 들어오면, 생산성은 일회성 보너스가 아니라 습관의 복리로 바뀝니다.\n4) AI를 숭배하지 않아도 AI-native가 될 수 있다 중요한 균형점은 여기입니다. AI-native가 된다는 말은 AI를 무조건 찬양하거나, 모든 결과물을 믿거나, 인간의 판단을 버리라는 뜻이 아닙니다.\n오히려 좋은 AI 사용자는 다음을 함께 가져갑니다.\nAI가 틀릴 수 있다는 감각 출처와 근거를 확인하는 습관 민감한 정보와 저작권에 대한 경계 과사용으로 사고력이 약해질 수 있다는 인식 그래도 도구를 계속 실험하는 태도 즉 AI-native는 신앙이 아니라 문해력입니다. 계산기를 쓴다고 수학적 사고가 사라지는 것이 아니듯, AI를 쓴다고 판단이 자동으로 사라지는 것은 아닙니다. 다만 판단 없이 쓰면 위험하고, 아예 쓰지 않으면 뒤처질 수 있습니다.\n5) 개인 전략: 가까운 사람부터 옮겨라 Miessler의 결론은 꽤 강합니다. 그는 이 격차를 거의 이분법적으로 보라고 제안합니다. 완전히 흑백은 아니지만, 실천을 촉발하기 위한 프레임으로는 유용하다는 뜻입니다.\n여기서 \u0026ldquo;AI-native camp로 옮긴다\u0026quot;는 것은 거창한 교육 과정을 뜻하지 않습니다. 더 현실적으로는 다음과 같은 작은 습관을 만드는 일입니다.\n검색 전에 AI에게 문제를 설명해보기 문서나 이메일의 첫 초안을 AI와 함께 만들기 모르는 개념을 세 단계 난이도로 설명받기 반복 업무 하나를 자동화 가능한 형태로 쪼개보기 중요한 판단 전에 반대 논리를 요청하기 핵심은 도구를 가끔 체험하는 것이 아니라, 실제 생활과 업무의 병목에 연결하는 것입니다. 그래야 AI가 장난감이 아니라 인프라가 됩니다.\n결론 및 시사점 한 줄 결론: AI 산업의 거품을 경계하더라도, 개인의 AI 활용 능력을 키우는 일은 미루면 안 되는 기본 역량이 되고 있다.\nAI에 대한 비판과 AI 학습 거부를 구분해야 한다. 산업의 과장을 보는 눈은 필요하지만, 그 때문에 도구 활용 자체를 포기하면 손해가 커진다. AI-native 격차는 개발자만의 문제가 아니다. 글쓰기, 학습, 조사, 운영, 기획, 창작 등 지식노동 전반에서 반복 시도 횟수를 바꾼다. 좋은 사용법은 맹신이 아니라 검증 가능한 협업이다. AI가 내놓은 답을 그대로 받아들이는 것이 아니라, 생각의 속도와 폭을 넓히는 보조 엔진으로 써야 한다. 앞으로의 중요한 질문은 \u0026ldquo;AI가 거품인가?\u0026rdquo; 하나가 아니다. 더 현실적인 질문은 \u0026ldquo;거품이 일부 꺼진 뒤에도 남을 도구 역량을 나는 얼마나 갖고 있는가?\u0026ldquo;이다. 관련 포스트 The Founder’s Playbook: AI 네이티브 스타트업의 생애주기 재설계 AI의 능력 향상은 비용 하락이 아닌 작업 범위 확대로 나타났다 ","wordCount":819,"tags":["AI","Daniel Miessler","AI-native","생산성","학습"],"categories":["AI"],"frameworks":["AI-native literacy","Capability gap","Adoption curve"],"mental_models":["Compounding advantage","Opportunity cost","Tool leverage"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["Daniel Miessler는 AI 거품과 비용 문제를 인정하면서도, 그것을 AI 전체를 무시해도 된다는 결론으로 확장하는 태도를 경계한다","저자가 말하는 핵심 격차는 기술 직군만의 문제가 아니라, 어떤 일을 하든 AI를 일상 도구로 엮는 사람과 그렇지 않은 사람 사이의 생산성 차이다","AI-native가 된다는 것은 AI를 숭배하는 것이 아니라, 읽기·검색·자동화·초안 작성·학습 보조를 생활과 업무의 기본 인프라로 사용하는 것이다","Miessler는 독서 습관이 세계관과 기회를 바꾸듯, AI 활용 습관은 그 효과를 훨씬 더 크게 증폭할 수 있다고 본다","실천적으로는 자신과 가까운 사람들을 AI-native camp로 옮기는 것이 앞으로 몇 년간의 중요한 생존 전략이 된다"],"related":["posts/the-founders-playbook-ai-native-startup","posts/ai-capability-not-cost-reduction","posts/dont-outsource-your-thinking"]},{"title":"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-27T17:42:59+09:00","lastmod":"2026-06-27T17:42:59+09:00","description":"idlemachines의 The annotated PyTorch training loop를 바탕으로 PyTorch 학습 루프의 각 줄이 하는 일, 순서가 바뀌면 생기는 문제, 검증과 GPU 효율화 포인트를 한국어로 해설한다.","summary":"idlemachines의 The annotated PyTorch training loop는 PyTorch 학습 루프를 한 줄씩 해부하는 글입니다. 겉으로는 단순한 for 문처럼 보이지만, 실제로는 모델 상태, gradient buffer, autograd graph, optimizer state, scheduler state가 맞물려 돌아갑니다. 그래서 줄 하나가 조금만 엉뚱한 곳에 있어도 에러 없이 학습이 망가질 수 있습니다.\n원문: The annotated PyTorch training loop\nPyTorch 핵심 정리 핵심 순서: model.train() -\u0026gt; zero_grad() -\u0026gt; forward -\u0026gt; loss -\u0026gt; backward() -\u0026gt; clipping -\u0026gt; optimizer.step() -\u0026gt; scheduler.step() -\u0026gt; model.eval() + no_grad()가 기본 골격이다. 가장 위험한 점: 잘못된 위치의 코드가 항상 예외를 내지는 않는다. 학습이 안 되거나, 너무 느리거나, 메모리가 계속 늘어나는 형태로 드러난다. 역할 분리: loss.backward()는 .grad를 채우고, optimizer.step()은 weight를 바꾼다. 이 둘을 같은 일로 보면 루프를 잘못 고치기 쉽다. 검증 루프: model.eval()은 레이어 동작을 바꾸고, torch.no_grad()는 graph 생성을 막는다. 검증에는 보통 둘 다 필요하다. GPU 효율: 모델과 batch를 같은 device에 두고, mixed precision, pinned memory, prefetch, torch.compile을 상황에 맞게 적용해야 GPU가 놀지 않는다. 1) 학습 루프는 작은 상태 머신이다 PyTorch 학습 코드는 보통 이렇게 생겼습니다.\n","content":"idlemachines의 The annotated PyTorch training loop는 PyTorch 학습 루프를 한 줄씩 해부하는 글입니다. 겉으로는 단순한 for 문처럼 보이지만, 실제로는 모델 상태, gradient buffer, autograd graph, optimizer state, scheduler state가 맞물려 돌아갑니다. 그래서 줄 하나가 조금만 엉뚱한 곳에 있어도 에러 없이 학습이 망가질 수 있습니다.\n원문: The annotated PyTorch training loop\nPyTorch 핵심 정리 핵심 순서: model.train() -\u0026gt; zero_grad() -\u0026gt; forward -\u0026gt; loss -\u0026gt; backward() -\u0026gt; clipping -\u0026gt; optimizer.step() -\u0026gt; scheduler.step() -\u0026gt; model.eval() + no_grad()가 기본 골격이다. 가장 위험한 점: 잘못된 위치의 코드가 항상 예외를 내지는 않는다. 학습이 안 되거나, 너무 느리거나, 메모리가 계속 늘어나는 형태로 드러난다. 역할 분리: loss.backward()는 .grad를 채우고, optimizer.step()은 weight를 바꾼다. 이 둘을 같은 일로 보면 루프를 잘못 고치기 쉽다. 검증 루프: model.eval()은 레이어 동작을 바꾸고, torch.no_grad()는 graph 생성을 막는다. 검증에는 보통 둘 다 필요하다. GPU 효율: 모델과 batch를 같은 device에 두고, mixed precision, pinned memory, prefetch, torch.compile을 상황에 맞게 적용해야 GPU가 놀지 않는다. 1) 학습 루프는 작은 상태 머신이다 PyTorch 학습 코드는 보통 이렇게 생겼습니다.\nfor epoch in range(num_epochs): model.train() for x_batch, y_batch in loader: optimiser.zero_grad() logits = model(x_batch) loss = criterion(logits, y_batch) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0) optimiser.step() scheduler.step() model.eval() with torch.no_grad(): val_logits = model(x_val) val_loss = criterion(val_logits, y_val) 중요한 점은 이 코드가 단순한 실행 순서가 아니라는 것입니다. 각 줄은 다음 상태 중 하나를 바꿉니다.\n줄 바뀌는 상태 model.train() Dropout, BatchNorm 같은 layer의 동작 모드 zero_grad() parameter마다 쌓여 있는 .grad buffer model(x) autograd graph와 activation 저장 loss.backward() 각 parameter의 .grad 값 clip_grad_norm_() 이미 계산된 gradient의 크기 optimiser.step() 실제 model weight와 optimizer 내부 상태 scheduler.step() optimizer의 learning rate model.eval() 검증/추론용 layer 동작 torch.no_grad() graph 생성 여부 그래서 학습 루프를 이해한다는 것은 \u0026ldquo;이 줄이 무슨 계산을 하는가\u0026quot;보다 \u0026ldquo;이 줄이 어떤 상태를 바꾸는가\u0026quot;를 아는 일에 가깝습니다.\n2) 조용히 망가지는 실수가 많다 원문이 특히 강조하는 부분은, 많은 실수가 즉시 터지지 않는다는 점입니다. 코드는 돌아가지만 결과가 이상해집니다.\n실수 겉으로 보이는 현상 optimiser.zero_grad()를 loss.backward() 뒤에 둠 이전 batch의 gradient가 더해져 현재 batch만의 update가 아니게 됨 clip_grad_norm_()을 backward() 전에 호출 .grad가 비어 있어서 사실상 아무 일도 하지 않음 clip_grad_norm_()을 optimiser.step() 뒤에 호출 이미 적용된 gradient를 뒤늦게 자르므로 효과가 없음 scheduler.step()을 batch loop 안에 둠 epoch마다 한 번 줄어야 할 learning rate가 batch 수만큼 빨리 줄어듦 검증 후 model.train()으로 돌아가지 않음 Dropout이 꺼지고 BatchNorm이 고정된 상태로 학습됨 검증에서 torch.no_grad()를 빼먹음 validation마다 graph가 생겨 메모리를 잡아먹음 logging에 loss tensor를 그대로 저장 graph 참조가 남아 메모리가 계속 붙잡힘 이런 문제는 NameError처럼 친절하게 알려주지 않습니다. loss가 이상하게 흔들리거나, 학습이 안 되거나, GPU 메모리가 점점 차는 식으로 나타납니다. 그래서 루프의 순서는 암기 대상이 아니라 디버깅 체크리스트입니다.\n3) zero_grad()는 왜 매 batch마다 필요할까 PyTorch의 .grad는 덮어쓰기 방식이 아니라 누적 방식입니다. loss.backward()를 호출하면 새 gradient가 기존 .grad에 더해집니다.\n이 설계 덕분에 gradient accumulation이 가능합니다. GPU 메모리가 부족해서 큰 batch를 한 번에 못 올릴 때, 작은 batch 여러 개의 gradient를 모은 뒤 한 번만 optimiser.step()을 호출할 수 있습니다.\n하지만 일반 학습에서는 batch마다 독립적인 update를 원합니다. 그래서 batch 시작 시점에 optimiser.zero_grad()를 호출해 이전 batch의 gradient를 지웁니다.\n실무에서는 zero_grad(set_to_none=True)도 자주 씁니다. 0으로 채우는 대신 .grad를 None으로 두기 때문에 약간 더 빠르고 메모리 사용도 줄일 수 있습니다. PyTorch 2.0 이후 기본 동작도 이 방향입니다.\n4) forward는 graph를 만들고, loss는 출발점을 만든다 logits = model(x_batch)는 단순히 예측값을 얻는 줄이 아닙니다. requires_grad=True인 tensor가 연산에 참여하면 PyTorch는 그 연산들을 동적으로 기록합니다. 이 기록이 나중에 backward()가 따라갈 computation graph입니다.\n이 graph에는 backward 때 필요한 activation도 함께 살아 있습니다. 그래서 학습 중 forward는 메모리를 많이 씁니다. 반대로 검증에서는 gradient가 필요 없으므로 torch.no_grad() 또는 torch.inference_mode()를 사용해 graph 생성을 막습니다.\n분류 문제에서 흔히 쓰는 nn.CrossEntropyLoss는 raw logits를 받습니다. 내부적으로 log-softmax와 negative log-likelihood를 결합해 계산합니다. 따라서 모델 끝에 softmax를 붙여 확률로 만든 뒤 넣는 방식은 보통 피해야 합니다. 수치 안정성도 떨어지고, 의도한 API 사용법도 아닙니다.\n또 하나의 작은 함정은 logging입니다. 화면에 찍거나 리스트에 저장할 값은 loss.item()으로 Python 숫자만 뽑아야 합니다. tensor 자체를 오래 붙잡으면 graph 참조도 함께 남아 메모리 문제가 생길 수 있습니다.\n5) backward()와 step()은 다른 일이다 초보자가 가장 헷갈리기 쉬운 지점입니다.\nloss.backward()는 weight를 바꾸지 않습니다. scalar loss에서 시작해 graph를 거꾸로 타고 내려가며 각 parameter의 .grad를 채웁니다. 이것은 \u0026ldquo;어느 방향으로 얼마나 바꾸면 loss가 줄어드는가\u0026quot;를 계산하는 단계입니다.\n실제 weight 변경은 optimiser.step()에서만 일어납니다. optimizer는 .grad를 읽고, SGD나 Adam 같은 규칙에 따라 parameter를 갱신합니다. Adam이라면 gradient 평균과 제곱 평균 같은 내부 moment state도 함께 갱신합니다.\n이 둘 사이에 gradient clipping을 넣는 이유도 여기 있습니다.\nbackward() 전에는 .grad가 아직 없습니다. backward() 후에는 .grad가 계산되어 있습니다. step() 전에는 아직 weight가 바뀌지 않았습니다. 따라서 clipping의 자연스러운 위치는 loss.backward() 다음, optimiser.step() 이전입니다.\n6) scheduler는 종류마다 호출 위치가 다르다 기본 예시에서는 scheduler.step()을 epoch 끝에서 한 번 호출합니다. 예를 들어 cosine annealing을 epoch 단위로 설계했다면 batch loop 밖에 있어야 합니다.\n하지만 모든 scheduler가 같은 규칙을 따르지는 않습니다. Hugging Face의 warmup + cosine scheduler처럼 step 단위로 설계된 scheduler는 batch마다 호출합니다. ReduceLROnPlateau는 예외적으로 validation loss 같은 metric을 받아야 하므로 scheduler.step(val_loss)처럼 호출합니다.\n즉 scheduler의 핵심 질문은 \u0026ldquo;이 learning rate 계획이 epoch 단위인가, update step 단위인가, metric 기반인가\u0026quot;입니다. 이 질문 없이 위치만 복사하면 learning rate가 의도보다 훨씬 빨리 줄어들 수 있습니다.\n7) 검증에는 eval()과 no_grad()가 둘 다 필요하다 model.eval()과 torch.no_grad()는 이름이 비슷한 역할처럼 보이지만 완전히 다릅니다.\nmodel.eval()은 module의 동작 모드를 바꿉니다. Dropout은 mask를 샘플링하지 않고 그대로 통과시키며, BatchNorm은 현재 batch 통계가 아니라 학습 중 쌓아둔 running statistics를 사용합니다.\ntorch.no_grad()는 autograd graph 생성을 끕니다. 출력 tensor에 grad_fn이 붙지 않고, backward를 위한 activation도 저장하지 않습니다. 그래서 검증이 더 빠르고 메모리도 덜 씁니다.\n두 장치는 독립적입니다.\n조합 사용 사례 eval() + graph enabled saliency map, adversarial example처럼 입력 gradient가 필요한 분석 train() + no_grad() 학습 모드 forward 동작만 빠르게 확인 eval() + no_grad() 일반적인 validation 또는 inference 최근 PyTorch에서는 검증/추론에 torch.inference_mode()를 쓰기도 합니다. no_grad()보다 더 엄격하고 약간 더 빠를 수 있지만, 그 안에서 만들어진 tensor를 나중에 gradient 계산에 섞기 어렵다는 점을 알고 써야 합니다.\n8) checkpoint는 model만 저장하면 부족하다 학습을 중단했다가 이어서 돌릴 가능성이 있다면 model weight만 저장해서는 부족합니다. optimizer state와 scheduler state도 함께 저장해야 합니다.\n특히 Adam은 parameter마다 moment estimate를 들고 있습니다. 이 상태 없이 다시 시작하면 weight는 이어받았더라도 optimizer는 처음부터 워밍업하는 셈이 되어 loss가 튈 수 있습니다.\n일반적으로는 다음 정보를 checkpoint에 넣습니다.\nepoch model.state_dict() optimiser.state_dict() scheduler.state_dict() validation loss 또는 best score 그리고 최종 epoch의 weight보다 validation 성능이 가장 좋았던 시점의 weight를 따로 저장하는 패턴이 많습니다. 실제 배포나 평가에는 마지막 model보다 가장 일반화가 잘 된 model이 더 유용하기 때문입니다.\n9) GPU 효율은 루프 바깥 설정과 루프 안 이동이 함께 만든다 GPU 학습에서는 모델과 batch가 같은 device에 있어야 합니다. 그리고 optimizer는 model을 device로 옮긴 뒤에 만들어야 합니다. dtype 변환이나 device 이동이 parameter object를 새로 만들 수 있기 때문에, optimizer가 예전 parameter를 붙잡는 상황을 피해야 합니다.\nbatch 이동에서는 non_blocking=True를 자주 봅니다.\nx_batch = x_batch.to(device, non_blocking=True) y_batch = y_batch.to(device, non_blocking=True) 이 옵션은 host-to-device 전송을 비동기로 시작하게 해줍니다. 단, DataLoader 쪽에서 pin_memory=True를 사용해야 효과가 있습니다.\nmixed precision도 중요한 무료 속도 향상 수단입니다. float16이나 bfloat16 연산은 최신 GPU tensor core에서 훨씬 빠르게 처리됩니다. 다만 float16은 표현 범위가 좁아 작은 gradient가 0으로 사라질 수 있으므로 GradScaler를 함께 사용합니다. bfloat16은 float32와 exponent 범위가 같아 보통 scaler가 필요 없습니다.\nDataLoader도 병목이 될 수 있습니다. num_workers, pin_memory, persistent_workers, prefetch_factor를 잘 조정하면 GPU가 data를 기다리며 쉬는 시간을 줄일 수 있습니다.\n마지막으로 PyTorch 2.0 이상의 torch.compile은 forward를 추적해 연산을 fusion하고 더 효율적인 kernel을 만들 수 있습니다. 첫 실행은 compile 때문에 느릴 수 있지만, 긴 학습에서는 그 비용이 상쇄됩니다.\n결론 및 시사점 PyTorch 학습 루프의 어려움은 문법보다 상태 관리에 있습니다. zero_grad()는 gradient buffer를 다루고, forward는 graph를 만들고, backward()는 gradient를 채우고, step()은 weight를 바꾸고, eval()과 no_grad()는 검증 시점의 동작과 메모리 사용을 제어합니다.\n이 구분이 선명해지면 학습이 안 될 때 확인할 질문도 분명해집니다. gradient가 이전 batch와 섞였는가? clipping이 실제로 적용되었는가? scheduler가 너무 자주 호출되었는가? 검증에서 graph를 만들고 있지는 않은가? optimizer가 올바른 parameter를 보고 있는가?\n한 줄 결론: PyTorch 학습 루프는 외워야 할 주문이 아니라, 모델 상태와 gradient 흐름을 올바른 순서로 통제하는 작은 실행 시스템이다.\n","wordCount":1243,"tags":["PyTorch","딥러닝","학습 루프","autograd","optimizer","GPU","머신러닝"],"categories":["AI"],"frameworks":["Training Loop","Autograd","Gradient-Based Optimization"],"mental_models":["State Machine","Order Matters","Hidden State","Feedback Loop"],"philosophy_type":"engineering-practice","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["PyTorch 학습 루프의 핵심 순서는 train 모드 설정, gradient 초기화, forward, loss 계산, backward, gradient clipping, optimizer step, scheduler step, eval/no_grad 검증이다.","많은 실수는 예외를 내지 않는다. zero_grad 위치, clipping 위치, scheduler 호출 위치, eval 이후 train 복귀 누락, loss.item() 누락은 조용히 학습 품질이나 메모리를 망친다.","loss.backward()는 gradient를 계산해 .grad에 누적할 뿐 weight를 바꾸지 않는다. 실제 parameter 변경은 optimizer.step()에서만 일어난다.","model.eval()과 torch.no_grad()는 서로 다른 장치다. 전자는 Dropout과 BatchNorm 동작을 바꾸고, 후자는 autograd graph 생성을 끈다.","GPU 학습에서는 device placement, non_blocking 전송, mixed precision, DataLoader prefetch, torch.compile 같은 장치가 루프의 처리량을 크게 좌우한다."],"related":["posts/visual-guide-to-quantization","posts/to-train-or-not-to-train","posts/agent-harness-engineering"]},{"title":"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-19T02:30:00+09:00","lastmod":"2026-06-19T02:30:00+09:00","description":"Anthropic이 2026년 5월 공개한 The Founder’s Playbook을 바탕으로 AI를 인프라로 삼는 스타트업의 Idea부터 Scale까지 4단계와 창업자 역할 변화, 단계별 핵심 도전 과제, Claude 도구의 활용 전략을 다룬다.","summary":"The Founder’s Playbook: Building an AI-Native Startup은 Anthropic 팀이 2026년 5월에 발간한 문서로, AI를 기술과 조직 개발의 중심에 두는 스타트업의 새로운 생애주기를 정의한다.\n기존 스타트업 성장 곡선이 validate → raise → hire → build의 반복이었다면, 이제 AI는 각 단계에서 요구되는 팀 규모와 자금 조달의 기대를 크게 낮춘다. 좋은 아이디어가 실행으로 이어지는 거리가 극적으로 짧아졌다.\n원문: The Founder’s Playbook PDF\nTL;DR 핵심 정리 42%의 실패 원인: \u0026ldquo;아무도 원하지 않는 것을 만든다\u0026rdquo; — agentic coding으로 프로토타입 제작이 쉬워지면서 검증 없이 빌드하는 위험이 오히려 증가한다. Idea 단계 종료 기준: 문제-해결 적합성(PSF). 실제 인간 대화에서 얻은 정성적 증거로 \u0026ldquo;누가, 얼마나 자주, 얼마나 심각하게 이 문제를 겪는가\u0026quot;를 구체적으로 답할 수 있어야 한다. MVP 단계의 진짜 목표: 제품-시장 적합성(PMF) 증거 수집. 완성도가 아니라 \u0026ldquo;사용자가 이 제품 없이는 안 될 정도로 가치 있게 느끼는가\u0026quot;가 관건이며, Sean Ellis 테스트에서 40% 이상이 \u0026ldquo;very disappointed\u0026quot;라고 답해야 의미 있는 신호다. CLAUDE.md의 역할: MVP부터 작성하는 아키텍처·스코프 컨텍스트 파일. 매 Claude Code 세션 시작 시 읽히며, AI 기술 부채와 구조적 일관성 붕괴를 막는 영속적 메모리 역할을 한다. Scale 단계 모트 구축: 창업자 도메인 지식을 제품에 주입하고, 사용자 행동 데이터 플라이휠과 워크플로우 락인을 통해 경쟁사가 2년 안에 복제할 수 없는 깊이를 만든다. 창업자 역할의 근본적 변화 과거 창업자는 실행자(technical founder는 코드 작성, non-technical은 영업·운영)였다. 2026년 AI-native 환경에서는 창업자가 에이전트 오케스트레이터로 이동한다. AI가 코드 작성, 시장 조사, 문서 초안, 워크플로 자동화를 담당하면서 창업자의 시간은 \u0026ldquo;무엇을 왜 만들 것인가\u0026quot;를 결정하고 시스템(에이전트 + 도구 + 소규모 팀)을 지휘하는 데 쓰인다.\n","content":"The Founder’s Playbook: Building an AI-Native Startup은 Anthropic 팀이 2026년 5월에 발간한 문서로, AI를 기술과 조직 개발의 중심에 두는 스타트업의 새로운 생애주기를 정의한다.\n기존 스타트업 성장 곡선이 validate → raise → hire → build의 반복이었다면, 이제 AI는 각 단계에서 요구되는 팀 규모와 자금 조달의 기대를 크게 낮춘다. 좋은 아이디어가 실행으로 이어지는 거리가 극적으로 짧아졌다.\n원문: The Founder’s Playbook PDF\nTL;DR 핵심 정리 42%의 실패 원인: \u0026ldquo;아무도 원하지 않는 것을 만든다\u0026rdquo; — agentic coding으로 프로토타입 제작이 쉬워지면서 검증 없이 빌드하는 위험이 오히려 증가한다. Idea 단계 종료 기준: 문제-해결 적합성(PSF). 실제 인간 대화에서 얻은 정성적 증거로 \u0026ldquo;누가, 얼마나 자주, 얼마나 심각하게 이 문제를 겪는가\u0026quot;를 구체적으로 답할 수 있어야 한다. MVP 단계의 진짜 목표: 제품-시장 적합성(PMF) 증거 수집. 완성도가 아니라 \u0026ldquo;사용자가 이 제품 없이는 안 될 정도로 가치 있게 느끼는가\u0026quot;가 관건이며, Sean Ellis 테스트에서 40% 이상이 \u0026ldquo;very disappointed\u0026quot;라고 답해야 의미 있는 신호다. CLAUDE.md의 역할: MVP부터 작성하는 아키텍처·스코프 컨텍스트 파일. 매 Claude Code 세션 시작 시 읽히며, AI 기술 부채와 구조적 일관성 붕괴를 막는 영속적 메모리 역할을 한다. Scale 단계 모트 구축: 창업자 도메인 지식을 제품에 주입하고, 사용자 행동 데이터 플라이휠과 워크플로우 락인을 통해 경쟁사가 2년 안에 복제할 수 없는 깊이를 만든다. 창업자 역할의 근본적 변화 과거 창업자는 실행자(technical founder는 코드 작성, non-technical은 영업·운영)였다. 2026년 AI-native 환경에서는 창업자가 에이전트 오케스트레이터로 이동한다. AI가 코드 작성, 시장 조사, 문서 초안, 워크플로 자동화를 담당하면서 창업자의 시간은 \u0026ldquo;무엇을 왜 만들 것인가\u0026quot;를 결정하고 시스템(에이전트 + 도구 + 소규모 팀)을 지휘하는 데 쓰인다.\n이 변화는 비기술 창업자에게 특히 혁명적이다. 도메인 전문성을 가진 사람들이 엔지니어링 배경 없이도 실제 제품을 출시할 수 있게 되면서, 전통적 테크 파이프라인이 놓쳤던 문제들을 해결하는 스타트업이 늘어난다.\nAI가 lean startup을 더 큰 조직처럼 기능하게 만드는 세 영역:\n대화형 지능과 리서치 (on-call expert) Agentic coding (항상 사용 가능한 엔지니어 팀) 워크플로 자동화 (on-demand ops 팀) 타이밍과 오케스트레이션이 핵심이다.\nIdea Stage: 빌드 전에 증거를 확보하라 Idea 단계의 목표는 연구 중심 검증이다. \u0026ldquo;이게 가치 있는가?\u0026ldquo;라는 질문에 답하기 위해 문제의 실재성, 대상, 경쟁, 해결책 효과를 확인한다.\n종료 조건 (Problem-Solution Fit):\n문제가 실제로 구체적인가? (누가, 얼마나 자주, 얼마나 심각하게, 현재 어떻게 대처하는가) 제안한 해결책이 실제로 그 문제를 해결하는가? 빌드를 정당화할 충분한 신호가 있는가? 주요 도전 과제:\nMistaking building for validating: 기술 장벽이 사라지니 검증 없이 바로 프로토타입을 만들고 \u0026ldquo;만들었으니 맞을 것이다\u0026quot;라고 착각. 42% 실패율이 더 높아질 위험. Premature scaling: 검증되지 않은 전제 위에 실행을 스케일. Loss of objectivity: AI가 확인 편향을 강화. \u0026ldquo;내 아이디어를 지지하는 증거를 찾아줘\u0026quot;라고 물으면 찾아준다. Claude 활용:\nChat: 빠른 브레인스토밍, 질문 재작성 Claude Cowork: 폴더/시스템 접근으로 리서치, 문서 생성, 경쟁 분석 Claude Code: 가벼운 프로토타입 제작 (하지만 검증 후에) 구체적 연습: 문제 가설을 testable하게 다듬기, disconfirming evidence 찾기, TAM/SAM 모델링, 경쟁사 리뷰 합성, 인터뷰 대상 프로파일링과 질문지 설계, 사후 분석 등.\nMVP Stage: 속도 속에서도 판단과 구조를 유지하라 MVP 단계는 여전히 증거 수집 단계이되, 이제는 문제 공간이 아니라 해결책에 대한 증거(실제 사용, 재사용, 지불, 추천)를 모은다.\n종료 조건 (Product-Market Fit):\nSean Ellis 테스트: 활성 사용자 중 40% 이상이 \u0026ldquo;이 제품을 더 이상 사용할 수 없다면 매우 실망할 것\u0026quot;이라고 답함. Effort test: 유지에 지속적인 개입이 필요하지 않고, 제품이 스스로 당기기 시작함. 주요 도전 과제:\nAgentic technical debt: 스펙과 아키텍처 문서 없이 AI가 매 세션 재추론하면서 구조가 무너짐. Insecure by inexperience: 작동하는 코드는 쉽게 나오지만 보안 취약점은 눈에 보이지 않음. 실사용자 데이터 전에는 반드시 리뷰. Zero-friction scope creep: 기능 추가가 너무 쉬워서 원래 경계를 넘어 스프롤. Claude 활용:\n아키텍처 정의 후 CLAUDE.md 작성 (프로젝트 수준 지시서, Agent SDK가 자동 로드) 스코프 문서 작성: 무엇을 하고, 무엇을 하지 않을지, 어떤 사용자 증거가 있어야 추가할지 매 세션 시작/종료 시 컨텍스트 업데이트 측정 프레임워크 사전 정의 (지표, 벤치마크, false positive 정의) 보안 리뷰 (인증, 데이터 노출, 인젝션 등) 피드백 루프 자동화 (Claude Cowork) Launch Stage: 창업자 병목을 시스템으로 대체하라 Launch 단계는 초기 트랙션을 반복 가능하고 채널 주도 성장 엔진으로 전환하는 단계. 제품을 프로덕션 수준으로 굳히고 실제 회사를 구축한다.\n종료 조건:\n성장이 반복 가능하고 채널 주도 (CAC, LTV, payback period 파악) 제품이 프로덕션 워크로드를 견딤 (인프라, 보안, 컴플라이언스) 운영이 창업자 병목 없이 돌아감 주요 도전 과제:\nTechnical debt comes due: MVP 때의 지름길이 이제 이자를 물기 시작 The founder becomes the bottleneck: 모든 것을 직접 하려다 결정이 느려지고 조직이 정체 Security and compliance are no longer deferrable Claude 활용:\nClaude Code로 아키텍처 오딧과 리팩토링 우선순위화 Claude로 운영 감사: 반복 작업 목록화 → 자동화/위임/창업자 판단 분류 프로덕트 매니지먼트 프로세스 설계 (스프린트, 스펙 템플릿, 버그 트라이에이지, 주간 메트릭) Claude Cowork가 실제 실행 (스케줄링, 라우팅, 리포트) Scale Stage: 빌더에서 경영자로, 시스템을 신뢰하라 Scale 단계에서 창업자는 빌더에서 공공 대면 경영자로 이동. 제품은 여전하지만 일상 업무는 회사 자체를 다루는 데 집중된다.\n종료 조건: 창업자가 일상 운영을 직접 하지 않아도 회사가 지속 가능. 체계적 성장, 거버넌스, 컴플라이언스, \u0026ldquo;잘 자금 지원된 경쟁사가 오늘 제품을 복제해도 사용자가 남을까?\u0026ldquo;에 대한 답.\n주요 도전 과제:\nDelegating the operational layer: 시스템을 완전히 신뢰하고 넘기는 심리적·구조적 난관 Scaling technical operations to enterprise-grade Building a real GTM function (창업자 hustle의 한계) Turning domain expertise into compounding moat Claude 활용:\nClaude로 institutional knowledge를 문서·스킬·컨텍스트로 외재화 Claude Code로 엔터프라이즈급 인프라 (로깅, 모니터링, SLAs, 데모 환경, API docs) Claude Cowork로 GTM 실행 레이어 (콘텐츠 파이프라인, 아웃바운드, 애널리스트 브리핑) 데이터 플라이휠 설계, 워크플로우 락인 감사, integration 깊이 강화 결론 및 시사점 AI는 창업의 기술적·조직적 병목을 제거했지만, \u0026ldquo;무엇을 만들 것인가\u0026quot;와 \u0026ldquo;증거에 기반해 언제 다음 단계로 넘어갈 것인가\u0026quot;라는 판단의 중요성은 오히려 커졌다. 각 단계에서 Claude(Chat, Cowork, Code)를 적재적소에 사용하되, 인간의 구조화된 사고(가설 선명화, 반증 탐색, 스코프 정의, 아키텍처 문서화)가 선행되어야 AI가 제대로 작동한다. CLAUDE.md와 스코프 문서, 측정 프레임워크 같은 \u0026ldquo;선행 문서화\u0026quot;가 AI 기술 부채와 방향 상실을 막는 가장 저렴한 보험이다. Scale 단계의 진짜 방어는 코드가 아니라, 창업자의 고유 도메인 지식이 제품·데이터·워크플로우에 깊게 새겨진 복제 불가능한 컨텍스트에서 나온다. 한 줄 결론: AI 네이티브 스타트업에서 창업자의 핵심 역량은 더 이상 \u0026lsquo;빌드\u0026rsquo;가 아니라, AI 시스템이 스스로 증거를 수집하고 제품을 개선하며 운영을 유지하게 만드는 판단 프레임과 영속적 컨텍스트를 설계하는 것이다.\n","wordCount":933,"tags":["AI","스타트업","에이전트","Claude","Agentic Coding","PMF","창업"],"categories":["AI"],"frameworks":["Startup Lifecycle","Agent Orchestration","Evidence-Driven Building"],"mental_models":["Problem-Solution Fit","Product-Market Fit","Technical Debt Compounding","Data Flywheel"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["전통적 validate → raise → hire 루프가 AI로 압축되어 Idea 단계에서 증거 수집 후 바로 MVP로 진입 가능","Idea 단계 실패의 주원인(42%)은 '아무도 원하지 않는 것을 만든다'이며, agentic coding이 이 위험을 증폭시킴","CLAUDE.md를 MVP부터 작성해 아키텍처 컨텍스트를 영속화하고 AI 기술 부채를 방지한다","MVP 종료는 Sean Ellis 테스트(40%+ 'very disappointed')와 effort test(제품이 스스로 당기는지)로 판단","Scale 단계 모트는 창업자의 도메인 지식을 데이터 플라이휠과 워크플로우 락인으로 전환하는 데서 나온다"],"related":["posts/agentic-software-engineering.md","posts/agent-harness-engineering.md","posts/loop-engineering.md"]},{"title":"The Dialogue Dividend — 혼자 생각보다 대화가 사고를 만드는 인지적 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/the-dialogue-dividend/","section":"posts","date":"2026-06-19T01:47:28+09:00","lastmod":"2026-06-19T01:47:28+09:00","description":"The Signalist의 에세이 'The Dialogue Dividend'가 설명하는 대화의 구조적 이점, 인지 과학적 근거(Extended Mind, Argumentative Theory, ZPD), 그리고 원격·비동기·AI 환경이 비계획 대화를 어떻게 제거하는지와 그 위험","summary":"The Signalist의 에세이 \u0026ldquo;The Dialogue Dividend\u0026quot;는 깊은 사고가 문을 닫고 노이즈 캔슬링 헤드폰을 끼는 고립된 상태에서만 가능하다는 지배적인 모델에 도전합니다. 저자는 특정 동료와의 우연한 대화가 오랫동안 고민하던 문제를 순식간에 풀어주는 경험을 반복하면서, 답을 알려주지 않는 상대와의 교환 자체에서 혼자서는 만들어낼 수 없는 사고가 발생한다는 사실을 관찰했습니다.\n원문: The Dialogue Dividend\nDialogue Dividend 핵심 정리 정밀성 강제: 생각을 소리 내어 말하면 모호한 인상이 주어와 술어를 갖춘 평가 가능한 문장으로 변환되어 내부 독백보다 높은 정밀성을 요구한다 (Self-Explanation Effect). 실시간 교정 루프: 청자의 미간 찌푸림, 질문, \u0026ldquo;나도 본 적 있다\u0026quot;는 반응이 사고의 드리프트를 즉시 바로잡는다. 기계적 주의 신호만으로는 이 효과가 충분하지 않다 (Robot Duck Debugging 연구). 추론의 사회적 기원: Hugo Mercier와 Dan Sperber의 주장 이론에 따르면 인간의 추론 능력은 고립된 진실 발견이 아니라 집단 내에서 논증을 만들고 평가하기 위해 진화했다. 확장된 인지 시스템: Vygotsky의 근접 발달 영역(ZPD)과 Clark \u0026amp; Chalmers의 Extended Mind 이론은 타인이 단순한 청중이 아니라 사고를 함께 생산하는 인지 인프라임을 보여준다. 보이지 않는 배당: 부엌에서의 짧은 대화가 6개월 뒤 중요한 협업에서 이미 쌓인 관계와 맥락을 제공한다. 대부분의 배당은 투자하지 않으면 존재하지 않는 것처럼 느껴진다. 현대 환경의 침식: 원격 근무, 비동기 우선 통신, 헤드폰 기본 착용, 생성형 AI는 비계획적 교환의 조건을 체계적으로 제거하고 있다. 성과 지표는 당분간 유지되지만 이해와 신뢰는 조용히 약화된다. AI의 동조 문제: LLM은 사용자가 제시한 프레임에 빠르게 동조한다. 3인칭 관점이나 반대 의견을 명시적으로 요구하는 프롬프트로 지연시킬 수는 있지만, 동료처럼 자발적 pushback을 지속적으로 제공하지는 않는다 (SYCON 벤치마크). 1. 지배적인 사고 모델과 그 한계 진지한 사고의 표준 모델은 고독입니다. Deep work는 문을 닫고, 상태를 busy로 바꾸고, 헤드폰을 쓰는 순간에 일어난다고 여겨집니다. 미팅은 조율 비용으로, 대화는 이미 생각을 마친 후에 하는 것으로 취급됩니다.\n","content":"The Signalist의 에세이 \u0026ldquo;The Dialogue Dividend\u0026quot;는 깊은 사고가 문을 닫고 노이즈 캔슬링 헤드폰을 끼는 고립된 상태에서만 가능하다는 지배적인 모델에 도전합니다. 저자는 특정 동료와의 우연한 대화가 오랫동안 고민하던 문제를 순식간에 풀어주는 경험을 반복하면서, 답을 알려주지 않는 상대와의 교환 자체에서 혼자서는 만들어낼 수 없는 사고가 발생한다는 사실을 관찰했습니다.\n원문: The Dialogue Dividend\nDialogue Dividend 핵심 정리 정밀성 강제: 생각을 소리 내어 말하면 모호한 인상이 주어와 술어를 갖춘 평가 가능한 문장으로 변환되어 내부 독백보다 높은 정밀성을 요구한다 (Self-Explanation Effect). 실시간 교정 루프: 청자의 미간 찌푸림, 질문, \u0026ldquo;나도 본 적 있다\u0026quot;는 반응이 사고의 드리프트를 즉시 바로잡는다. 기계적 주의 신호만으로는 이 효과가 충분하지 않다 (Robot Duck Debugging 연구). 추론의 사회적 기원: Hugo Mercier와 Dan Sperber의 주장 이론에 따르면 인간의 추론 능력은 고립된 진실 발견이 아니라 집단 내에서 논증을 만들고 평가하기 위해 진화했다. 확장된 인지 시스템: Vygotsky의 근접 발달 영역(ZPD)과 Clark \u0026amp; Chalmers의 Extended Mind 이론은 타인이 단순한 청중이 아니라 사고를 함께 생산하는 인지 인프라임을 보여준다. 보이지 않는 배당: 부엌에서의 짧은 대화가 6개월 뒤 중요한 협업에서 이미 쌓인 관계와 맥락을 제공한다. 대부분의 배당은 투자하지 않으면 존재하지 않는 것처럼 느껴진다. 현대 환경의 침식: 원격 근무, 비동기 우선 통신, 헤드폰 기본 착용, 생성형 AI는 비계획적 교환의 조건을 체계적으로 제거하고 있다. 성과 지표는 당분간 유지되지만 이해와 신뢰는 조용히 약화된다. AI의 동조 문제: LLM은 사용자가 제시한 프레임에 빠르게 동조한다. 3인칭 관점이나 반대 의견을 명시적으로 요구하는 프롬프트로 지연시킬 수는 있지만, 동료처럼 자발적 pushback을 지속적으로 제공하지는 않는다 (SYCON 벤치마크). 1. 지배적인 사고 모델과 그 한계 진지한 사고의 표준 모델은 고독입니다. Deep work는 문을 닫고, 상태를 busy로 바꾸고, 헤드폰을 쓰는 순간에 일어난다고 여겨집니다. 미팅은 조율 비용으로, 대화는 이미 생각을 마친 후에 하는 것으로 취급됩니다.\n이 모델은 실행(execution)에서는 대체로 맞습니다. 하지만 발견(discovery)에서는 틀렸습니다.\n결정을 구현하는 데 대한 생각은 고립이 유리할 수 있습니다. 그러나 문제를 이해하는 데 대한 생각은 거의 그렇지 않습니다. 우리는 대부분의 업무 환경을 전자에 맞춰 구축하면서 후자가 저절로 해결되기를 기대해 왔습니다.\n2. 말하기가 사고에 강제하는 정밀성 무언가를 소리 내어 말하면 그 생각에 대한 커밋이 발생합니다. 머릿속에서 편안했던 모호한 인상은 반드시 문장이 되어야 하고, 문장은 구조를 가집니다. 주어와 술어가 있고, 평가될 수 있는 주장을 만듭니다. 말하는 행위 자체가 내부 독백이 절대 요구하지 않는 종류의 정밀성을 강제합니다.\n이 효과는 청중 없이 스스로에게 설명하는 것만으로도 입증된 바 있습니다 (Michelene Chi의 Self-Explanation Effect 연구).\n3. 청취자가 만드는 실시간 피드백 루프 청취자는 답을 주지 않아도 사고를 가속합니다. 이유는 반응하기 때문입니다.\n살짝 찌푸린 미간은 설명이 제대로 전달되지 않았음을 알려줍니다. 한 가지 질문은 미처 깨닫지 못한 가정을 드러냅니다. \u0026ldquo;나도 그런 걸 본 적 있어\u0026quot;라는 순간의 인식은 \u0026ldquo;내가 가리키는 것이 실제로 존재한다\u0026quot;는 확인을 줍니다. 이 피드백 루프는 대화 내내 실시간으로 작동하며, 사고가 너무 멀리 벗어나기 전에 방향을 바로잡습니다.\n이런 일은 혼자 생각할 때는 전혀 일어나지 않습니다.\n중요한 점은 청취의 기계적 신호만으로는 충분하지 않다는 것입니다. 타이밍을 맞춘 듣기 행동을 하는 로봇조차 고무 오리와 큰 차이를 내지 못했습니다 (Robot Duck Debugging 연구). 진짜 유용한 것은 주의의 신호가 아니라, 실제로 다르게 생각할 수 있는 다른 마음의 존재입니다.\n4. 추론은 원래 사회적 도구였다 Hugo Mercier와 Dan Sperber는 인간의 추론(reasoning)에 대해 불편한 주장을 펼쳤습니다. 추론은 고립된 상태에서 진실을 찾기 위한 도구로 진화한 것이 아니라는 것입니다. 그것은 논증을 구성하고, 다른 사람의 논증을 평가하며, 집단 생활의 인식적(epistemic) 요구를 관리하기 위한 사회적 도구로 진화했습니다.\n이 관점은 질문을 재구성하게 만듭니다. 혼자 하는 생각은 추론의 본래 환경이 아닙니다. 그것은 다른 목적으로 만들어진 능력의 2차적 사용입니다. 우리는 대화를 이미 완성된 생각을 보고하는 장소로 여겨왔지만, 어쩌면 생각이 처음 만들어지는 장소에 더 가까울 수 있습니다.\n5. 확장된 마음과 인지 인프라 Lev Vygotsky는 학습과 발달, 그리고 이해의 형성이 한 사람이 혼자 할 수 있는 것과 지원을 받아 할 수 있는 것 사이의 공간에서 가장 잘 일어난다고 관찰했습니다. 다른 사람의 존재는 자동으로 당신을 그 공간으로 이동시킵니다. 당신은 자연스러운 한계 위에서 작동하게 되는데, 이는 상대가 당신을 데려가서가 아니라 상호작용의 구조 자체가 혼자서는 요구되지 않는 것을 요구하기 때문입니다.\nAndy Clark과 David Chalmers는 여기서 한 걸음 더 나아갔습니다. 마음은 두개골에서 끝나지 않는다고 주장했습니다. 그것은 환경, 그리고 그 안에 있는 사람들로 확장됩니다. 대화 속에서 생각할 때, 다른 사람은 생각을 생산하는 인지 시스템의 일부로 기능하며, 단순히 밖에 위치한 반향판이 아닙니다.\n이 함의는 작지 않습니다. \u0026ldquo;생각이 잘 맞는 동료를 부르는 것\u0026quot;은 사회적 자원 활용으로 치부되기 쉽지만, 실제로는 그들이 인지 인프라(cognitive infrastructure)라는 뜻입니다.\n6. 대화 배당이 실제로 쌓이는 방식 저자는 직장 부엌에서 동료와 몇 분간 나눈, 그 순간에는 아무것도 아닌 것처럼 보이는 대화를 언급합니다. 6개월 후, 그 사람과 실제로 중요한 일을 함께 하게 되었을 때 이미 관계가 구축되어 있었고, 그 덕분에 전체 과정이 훨씬 수월해졌습니다.\n그때가 되어서야 \u0026ldquo;내가 누구고 왜 이 요청이 타당한지\u0026quot;를 설명할 필요가 없었습니다.\n이것이 바로 대화 배당입니다. 그리고 대부분의 배당처럼, 수집하려고 할 때까지는 보이지 않으며, 투자한 적이 없다는 것을 깨닫게 됩니다.\n7. 현대 업무 환경이 대화를 제거하는 방식 많은 조직은 지난 몇 년 동안 비공식 대화가 일어날 수 있는 조건을 체계적으로 제거해 왔습니다.\n원격 근무 비동기 우선 커뮤니케이션 기본 착용 상태인 헤드폰 질문이 대화가 되기 전에 답을 제시하는 생성형 AI 도구 각각은 국지적으로는 합리적입니다. 하지만 함께 모이면 조직의 인지적·관계적 인프라가 유지되는 비계획적 교환의 층을 얇아지게 만듭니다.\n산출 지표는 당분간 건강하게 유지될 수 있습니다. 이해와 신뢰는 조용히 침식됩니다.\n8. 생성형 AI와 생각하기의 절반만 되는 배당 생성형 AI를 생각 파트너로 삼는 데도 별도의 문제가 있습니다. 문제를 모델에게 적어 내는 행위는 앞서 설명한 문장 수준 정밀성을 강제한다는 점에서 사고를 가속합니다.\n그러나 배당의 후반부, 즉 진짜로 반대할 수 있는 청취자에게 의존하는 부분은 기본적으로 오지 않습니다. 모델은 사용자가 가져온 프레임을 기본적으로 검증하는 경향이 있으며, 연구자들은 이를 sycophancy(동조성)라고 부릅니다.\n30초만 실험해도 알 수 있습니다. 특정 접근법에 자신이 있다고 말하면 모델은 빠르게 동의하고, 그 제안에 대해 마음이 바뀌었다고 말하면 역시 빠르게 동의합니다. 대안을 물어보면 종종 주기는 하지만, 이는 요청해야만 하는 것입니다.\n3인칭 관점에서 추론하게 하거나, 의견을 답하기 전에 질문하게 하는 프롬프트는 이 경향을 상당히 줄일 수 있습니다 (SYCON 벤치마크에서 최대 63.8% 감소). 그러나 이는 지연일 뿐 치유는 아닙니다. 통제된 실험에서 가장 잘 프롬프트된 모델조차도 결국 지속적인 반대 압력 아래에서는 순응했으며, 단지 순응이 늦춰졌을 뿐이었습니다.\n동료는 요청하지 않아도 밀어냅니다. 모델이 같은 일을 하려면 요청해야 하고, 그마저도 한동안만 그렇습니다.\n이는 특정한 종류의 위험을 만듭니다. AI가 비판적 참여 능력이 부족해서가 아니라, 거의 아무도 기본적으로 그것을 요청하지 않기 때문에, 모델과 함께 무언가를 끝까지 생각하는 경험이 완전한 것처럼 느껴지면서도 배당이 요구하는 절반만을 제공할 수 있다는 점입니다.\n9. 개인과 팀이 할 수 있는 일 조직 구조와 AI 제품의 기본 동작은 개인이 통제하기 어려운 영역에 속합니다. 하지만 실제로 배당이 주변에 쌓이느냐는 더 가까운 곳에 달려 있습니다. 바로 당신이 캘린더에서 무엇을 보호하느냐, 그리고 당신이 대화하는 사람과 도구에게 무엇을 요구하느냐입니다.\n팀은 미팅 후 10분의 비계획 시간을 남겨둘 수 있습니다. 한 사람은 결정 전에 동료에게 반대편을 주장해 달라고 요청하거나, 모델에게도 그렇게 하라고 프롬프트할 수 있습니다. 어느 쪽도 큰 비용이 들지 않습니다. 누군가 그렇게 하기로 결정하지 않으면 일어나지 않을 뿐입니다.\n시작 부분에서 언급한 동료와의 대화는 누구의 캘린더에도 없었습니다. 있었다면 아마 일어나지 않았을 것입니다.\n이번 주에 당신이 내릴 최고의 결정은 아마도 미리 계획하지 않은 대화 속에서 나올 것입니다.\n결론 및 시사점 한 줄 결론: 비계획적인 대화는 비용이 아니라, 혼자서는 도달할 수 없는 사고의 정밀성과 관계적 신뢰를 구축하는 필수 인지 인프라이며, 원격·비동기·AI 중심 환경이 이를 체계적으로 제거하고 있다.\n조직은 생산성 지표가 여전히 괜찮아 보일 때조차 인지적·관계적 자본이 서서히 고갈되고 있음을 인식해야 합니다. 개인은 \u0026ldquo;생각할 시간이 필요하다\u0026quot;는 이유로 모든 블록을 채우는 대신, 의도적으로 비어 있는 대화의 공간을 남겨두는 결정을 내려야 합니다. AI를 사용할 때도 첫 답변을 그대로 받아들이지 말고, 명시적으로 \u0026ldquo;반대 의견을 내서 도전해 달라\u0026quot;고 요구하는 습관이 필요합니다.\n결국 가장 중요한 결정들은 스케줄에 없었던 대화에서 태어나는 경우가 많습니다. 그 공간을 지키는 것이 바로 장기적 사고 역량과 조직 건강을 지키는 일입니다.\n","wordCount":1180,"tags":["대화","인지과학","생산성","조직문화","의사결정","AI"],"categories":["Thinking","Productivity"],"frameworks":["Extended Mind","Argumentative Theory of Reasoning","Zone of Proximal Development"],"mental_models":["Cognitive Infrastructure","Social Feedback Loop","Unscheduled Interaction"],"philosophy_type":"epistemology","schema_type":"Article","actionable":true,"priority":"high","key_points":["생각을 소리 내어 말하면 모호한 인상이 주어와 술어를 갖춘 평가 가능한 문장으로 변환되어 정밀성이 강제된다","청자의 미간 찌푸림, 질문, 공감 반응이 사고의 방향을 실시간으로 교정하는 피드백 루프를 만든다 (기계적 주의 신호만으로는 부족)","인간 추론은 고립된 진실 추구가 아니라 집단 내 논증 생산과 평가를 위해 진화했다 (Mercier \u0026 Sperber)","다른 사람은 단순 청중이 아니라 사고 생산 시스템의 일부이며, Vygotsky ZPD처럼 혼자 도달할 수 없는 수준으로 끌어올린다","비공식 대화는 즉각 성과가 없어 보이지만 6개월 후 중요한 협업에서 이미 구축된 관계와 맥락을 제공하는 배당이다","AI는 기본적으로 사용자 프레임에 동조(sycophantic)하며, 명시적 반대 의견 프롬프트 없이는 진짜 pushback을 지속하지 않는다"],"related":["posts/all-your-agents-are-going-async","posts/the-eternal-sloptember-summary","software/ai-cheap-exploration-human-judgment"]},{"title":"AI 프로토타입 시대에도 여전히 엔지니어가 필요한 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/yes-we-still-need-engineers/","section":"posts","date":"2026-06-17T14:55:58+09:00","lastmod":"2026-06-17T14:55:58+09:00","description":"AI 코딩 도구가 프로토타입 제작을 빠르게 만들었지만, 실제 제품화에는 백엔드, 테스트, 보안, 운영, 접근성, 확장성 등 엔지니어링 판단이 여전히 필요하다는 관점을 정리한다.","summary":"Matt Sayar의 글 Yes, we still need engineers는 Claude Code 같은 AI 코딩 도구가 프로토타입 제작을 얼마나 빠르게 만들었는지 인정하면서도, 그 결과물이 곧바로 프로덕션 품질의 소프트웨어가 되는 것은 아니라고 말합니다. 핵심은 \u0026ldquo;AI가 코드를 빨리 만든다\u0026quot;와 \u0026ldquo;소프트웨어가 실제 사용자에게 안전하게 운영된다\u0026rdquo; 사이에는 여전히 넓은 엔지니어링 간극이 있다는 점입니다.\n이 글은 원문의 주장을 바탕으로, AI 프로토타입과 프로덕션 엔지니어링의 차이를 한국어 독자를 위해 정리한 글입니다.\n핵심 정리 프로토타입은 커뮤니케이션 도구다: AI로 만든 데모는 아이디어를 빠르게 보여주고 팀의 이해를 맞추는 데 강력하지만, 운영 가능한 제품과는 거리가 있다. 제품화에는 보이지 않는 작업이 많다: 백엔드 지원, 회귀 테스트, 기능 테스트, 보안 테스트, 성능 검증, 접근성, 권한 처리, 유지보수성 같은 요소가 필요하다. 운영 책임은 코드 생성보다 넓다: 로깅, 모니터링, 알림, 배포와 롤백, 장애 대응, 데이터 무결성, 규제 준수, 감사 추적까지 고려해야 한다. 엔지니어의 역할은 사라지지 않고 이동한다: 자동화는 반복적인 코드 작성을 줄이고, 엔지니어가 문제 정의와 시스템 품질, 운영 책임에 더 집중하게 만든다. AI 프로토타입은 왜 매력적인가 AI 코딩 도구를 사용하면 기존 UI 저장소를 복제한 뒤, 버튼 추가나 테스트 데이터 구성, 워크플로 데모 녹화 같은 작업을 매우 빠르게 진행할 수 있습니다. Loom 영상으로 보여주기에 충분한 데모를 만드는 속도는 과거보다 크게 빨라졌습니다.\n","content":"Matt Sayar의 글 Yes, we still need engineers는 Claude Code 같은 AI 코딩 도구가 프로토타입 제작을 얼마나 빠르게 만들었는지 인정하면서도, 그 결과물이 곧바로 프로덕션 품질의 소프트웨어가 되는 것은 아니라고 말합니다. 핵심은 \u0026ldquo;AI가 코드를 빨리 만든다\u0026quot;와 \u0026ldquo;소프트웨어가 실제 사용자에게 안전하게 운영된다\u0026rdquo; 사이에는 여전히 넓은 엔지니어링 간극이 있다는 점입니다.\n이 글은 원문의 주장을 바탕으로, AI 프로토타입과 프로덕션 엔지니어링의 차이를 한국어 독자를 위해 정리한 글입니다.\n핵심 정리 프로토타입은 커뮤니케이션 도구다: AI로 만든 데모는 아이디어를 빠르게 보여주고 팀의 이해를 맞추는 데 강력하지만, 운영 가능한 제품과는 거리가 있다. 제품화에는 보이지 않는 작업이 많다: 백엔드 지원, 회귀 테스트, 기능 테스트, 보안 테스트, 성능 검증, 접근성, 권한 처리, 유지보수성 같은 요소가 필요하다. 운영 책임은 코드 생성보다 넓다: 로깅, 모니터링, 알림, 배포와 롤백, 장애 대응, 데이터 무결성, 규제 준수, 감사 추적까지 고려해야 한다. 엔지니어의 역할은 사라지지 않고 이동한다: 자동화는 반복적인 코드 작성을 줄이고, 엔지니어가 문제 정의와 시스템 품질, 운영 책임에 더 집중하게 만든다. AI 프로토타입은 왜 매력적인가 AI 코딩 도구를 사용하면 기존 UI 저장소를 복제한 뒤, 버튼 추가나 테스트 데이터 구성, 워크플로 데모 녹화 같은 작업을 매우 빠르게 진행할 수 있습니다. Loom 영상으로 보여주기에 충분한 데모를 만드는 속도는 과거보다 크게 빨라졌습니다.\n이런 프로토타입은 특히 다음 상황에서 큰 가치를 가집니다.\n제품 아이디어를 말보다 화면으로 보여줘야 할 때 디자이너, PM, 엔지니어가 같은 기능을 같은 방식으로 이해해야 할 때 구현 전 사용자 흐름을 빠르게 검증해야 할 때 실제 개발팀이 참고할 수 있는 구체적인 예시가 필요할 때 즉, AI 프로토타입은 아이디어에서 전달로 가는 시간을 줄이는 도구입니다. 원문 작성자도 프로토타입이 아이디어 전달과 엔지니어링 참조 자료로 매우 유용하다고 평가합니다.\n하지만 프로토타입은 제품이 아니다 문제는 보기 좋은 데모가 곧바로 안전한 제품을 의미하지 않는다는 데 있습니다. 원문은 프로토타입 이후에도 다음과 같은 작업이 필요하다고 강조합니다.\n영역 제품화를 위해 필요한 질문 백엔드 화면 뒤에서 실제 데이터와 비즈니스 로직이 안정적으로 동작하는가? 테스트 회귀, 기능, 단위, 통합, E2E 테스트가 충분한가? 보안 인증, 인가, 세션, 권한, 남용 방지, 개인정보 처리가 안전한가? 성능 느린 네트워크, 대량 트래픽, 캐시 무효화, 확장 상황을 견딜 수 있는가? 운영 로깅, 메트릭, 트레이싱, 모니터링, 알림, 롤백 전략이 준비되어 있는가? 데이터 스키마 설계, 마이그레이션, 무결성 제약, 백업, 재해 복구가 고려되었는가? 사용자 경험 빈 상태, 로딩 상태, 오류 상태, 모바일, 브라우저 차이, 접근성이 반영되었는가? 조직 책임 코드 리뷰, 문서, 런북, 온콜, 지원 체계, 버전 호환성이 준비되었는가? AI가 만든 화면은 이 중 일부만 보여줍니다. 반면 실제 제품은 사용자, 데이터, 인프라, 법적 요구사항, 장애 상황, 장기 유지보수까지 포함한 전체 시스템입니다.\n\u0026ldquo;바이브 코딩\u0026quot;의 착각 원문에서 가장 중요한 경고는, AI로 빠르게 만든 프로토타입을 프로덕션 준비가 끝난 제품으로 착각해서는 안 된다는 점입니다.\n프로토타입이 위험해지는 순간은 다음과 같습니다.\n화면이 잘 동작하므로 시스템도 준비됐다고 믿을 때 데모 데이터에서 성공했으므로 실제 데이터에서도 안전하다고 가정할 때 한 명의 사용자 흐름만 검증하고 권한, 동시성, 장애 상황을 놓칠 때 코드가 생성됐다는 이유로 리뷰와 테스트를 생략할 때 배포, 모니터링, 롤백, 지원 책임을 뒤늦게 생각할 때 AI 코딩 도구는 \u0026ldquo;무언가가 되는 것처럼 보이는 상태\u0026quot;까지 도달하는 시간을 크게 단축합니다. 그러나 엔지니어링은 바로 그 이후, 실제로 안전하게 되는지 검증하고 책임지는 과정에서 본격적으로 시작됩니다.\n자동화는 엔지니어를 없애기보다 초점을 바꾼다 소프트웨어 산업은 오래전부터 지루하고 반복적인 일을 자동화해 왔습니다. 빌드 도구, 테스트 프레임워크, CI/CD, 클라우드 인프라, 코드 생성 도구 모두 같은 흐름 위에 있습니다.\nAI 코딩 도구도 이 연장선에 있습니다. 차이는 자동화 범위가 더 넓어졌다는 점입니다. 하지만 자동화가 넓어질수록 엔지니어에게 남는 일은 더 본질적인 방향으로 이동합니다.\n무엇을 만들어야 하는가? 어떤 실패 모드를 예상해야 하는가? 어떤 품질 기준을 충족해야 하는가? 어떤 운영 책임을 받아들일 수 있는가? 어떤 보안·규제·조직 맥락을 지켜야 하는가? 결국 엔지니어의 가치는 키보드로 코드를 입력하는 속도보다, 문제를 정의하고 시스템을 책임질 수 있는 판단력에 더 가까워집니다.\n기존 논의와 연결되는 지점 이 글은 \u0026ldquo;AI가 소프트웨어 엔지니어를 대체하지 못한 이유\u0026quot;에 대한 더 넓은 논의와도 맞닿아 있습니다. AI가 코드 작성이라는 실행 단계를 빠르게 만드는 것은 분명하지만, 실제 개발에는 기획, 검증, 배포, 운영, 책임이라는 더 넓은 단계가 있습니다.\n관련해 이 블로그의 다음 글과 함께 읽으면 관점이 더 선명해집니다.\nAI가 소프트웨어 엔지니어를 대체하지 못한 이유 Agentic Software Engineering AI의 능력 향상은 비용 하락이 아닌 작업 범위 확대로 나타났다 실무자가 가져갈 질문 AI 코딩 도구로 만든 결과물을 실제 업무에 활용하려면, 다음 질문을 체크리스트처럼 던져볼 수 있습니다.\n이 결과물은 데모인가, 실사용 제품인가? 실제 데이터, 실제 권한, 실제 오류 상황을 통과했는가? 테스트와 코드 리뷰를 거쳤는가? 장애 발생 시 누가, 어떤 신호를 보고, 어떻게 대응하는가? 배포와 롤백 전략이 있는가? 보안, 개인정보, 규제, 감사 요구사항을 충족하는가? 6개월 뒤 다른 엔지니어가 이해하고 유지보수할 수 있는가? 이 질문에 답하지 못한다면, 아직 프로토타입 단계에 머물러 있다고 보는 편이 안전합니다.\n결론 및 시사점 AI 코딩 도구는 소프트웨어 개발에서 매우 강력한 레버리지입니다. 특히 아이디어를 빠르게 시각화하고, 팀 간 커뮤니케이션을 개선하며, 구현 방향을 구체화하는 데 큰 도움을 줍니다. 그러나 프로덕션 소프트웨어는 코드 조각이나 화면 데모가 아니라, 사용자와 데이터를 안전하게 다루고 장애와 변화 속에서도 유지되는 시스템입니다.\n한 줄 결론: AI는 프로토타입을 훨씬 빠르게 만들지만, 그 프로토타입을 신뢰할 수 있는 제품으로 바꾸는 일에는 여전히 엔지니어가 필요하다.\n","wordCount":761,"tags":["AI","소프트웨어엔지니어링","프로토타이핑","코딩에이전트","프로덕션"],"categories":["AI"],"frameworks":["Systems Thinking","Second-order thinking"],"mental_models":["Prototype vs Production","Automation Leverage"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["AI 코딩 도구는 데모와 프로토타입 제작 속도를 크게 높였지만, 프로덕션 제품이 되려면 백엔드·테스트·보안·성능·확장성·접근성 같은 작업이 뒤따라야 한다","프로토타입은 아이디어 전달과 엔지니어링 참조 자료로는 유용하지만, 그대로 운영 환경에 배포할 수 있는 완성품은 아니다","소프트웨어 산업의 자동화는 코드를 덜 치게 만드는 대신, 엔지니어가 실제 문제 해결과 시스템 책임에 더 집중하게 만든다"],"related":["posts/why-ai-hasnt-replaced-software-engineers","posts/agentic-software-engineering","posts/ai-capability-not-cost-reduction"]},{"title":"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-17T13:56:32+09:00","lastmod":"2026-06-17T13:56:32+09:00","description":"Addy Osmani의 'Agentic Code Review'(2026-06-15)를 정리했다. 핵심은 AI가 코드 작성을 빠르게 만들수록 엔지니어링의 병목은 사람이 신뢰할 수 있는 검증 체계로 이동한다는 점이다.","summary":"Addy Osmani의 2026년 6월 15일 글 **\u0026ldquo;Agentic Code Review\u0026rdquo;**는 AI 코딩 에이전트가 보편화된 뒤 코드 리뷰의 의미가 어떻게 바뀌었는지 다룹니다. 글의 핵심은 단순합니다. 코드 작성은 기계 속도로 빨라졌지만, 사람이 변경을 이해하고 신뢰하는 속도는 거의 그대로이기 때문에 병목은 리뷰와 검증으로 이동했다는 것입니다.\n원문: Agentic Code Review — Addy Osmani\nTL;DR 핵심 정리 병목 이동: AI는 수천 줄의 코드를 빠르게 만들지만, 사람이 \u0026ldquo;이 변경을 믿어도 되는가\u0026quot;를 판단하는 속도는 그대로다. 데이터의 경고: Faros는 AI 채택이 높은 팀에서 code churn 861%, incidents-to-PR ratio 242.7%, median review duration 441.5%, zero-review merge 31.3% 증가를 보고했다. 상황별 리뷰: 솔로 프로토타입과 결제·인증·개인정보를 다루는 장기 운영 시스템은 같은 리뷰 규칙을 적용하면 안 된다. 의도 복원 비용: 에이전트가 만든 diff에는 구현 의도와 대안 검토가 사라지기 쉬우므로, PR에 decision log와 테스트 증거를 붙여야 한다. 사람의 역할 변화: 사람은 모든 줄을 읽는 reviewer에서 risk tiering, sampling, audit, high-blast-radius gate를 책임지는 owner로 이동한다. 1) 코드 작성은 싸졌고, 이해는 그대로 비싸다 과거 코드 리뷰는 속도의 균형 위에 있었습니다. 주니어가 코드를 작성하는 속도보다 시니어가 읽는 속도가 빨랐기 때문에, 리뷰는 자연스럽게 병목이 되지 않았습니다. 하지만 에이전트는 이 균형을 깨뜨립니다.\n","content":"Addy Osmani의 2026년 6월 15일 글 **\u0026ldquo;Agentic Code Review\u0026rdquo;**는 AI 코딩 에이전트가 보편화된 뒤 코드 리뷰의 의미가 어떻게 바뀌었는지 다룹니다. 글의 핵심은 단순합니다. 코드 작성은 기계 속도로 빨라졌지만, 사람이 변경을 이해하고 신뢰하는 속도는 거의 그대로이기 때문에 병목은 리뷰와 검증으로 이동했다는 것입니다.\n원문: Agentic Code Review — Addy Osmani\nTL;DR 핵심 정리 병목 이동: AI는 수천 줄의 코드를 빠르게 만들지만, 사람이 \u0026ldquo;이 변경을 믿어도 되는가\u0026quot;를 판단하는 속도는 그대로다. 데이터의 경고: Faros는 AI 채택이 높은 팀에서 code churn 861%, incidents-to-PR ratio 242.7%, median review duration 441.5%, zero-review merge 31.3% 증가를 보고했다. 상황별 리뷰: 솔로 프로토타입과 결제·인증·개인정보를 다루는 장기 운영 시스템은 같은 리뷰 규칙을 적용하면 안 된다. 의도 복원 비용: 에이전트가 만든 diff에는 구현 의도와 대안 검토가 사라지기 쉬우므로, PR에 decision log와 테스트 증거를 붙여야 한다. 사람의 역할 변화: 사람은 모든 줄을 읽는 reviewer에서 risk tiering, sampling, audit, high-blast-radius gate를 책임지는 owner로 이동한다. 1) 코드 작성은 싸졌고, 이해는 그대로 비싸다 과거 코드 리뷰는 속도의 균형 위에 있었습니다. 주니어가 코드를 작성하는 속도보다 시니어가 읽는 속도가 빨랐기 때문에, 리뷰는 자연스럽게 병목이 되지 않았습니다. 하지만 에이전트는 이 균형을 깨뜨립니다.\n에이전트는 짧은 시간에 잘 포맷된 대량의 코드를 생성합니다. 반면 사람의 읽기 속도와 시스템 이해 속도는 거의 변하지 않았습니다. 따라서 엔지니어링의 중심 질문은 \u0026ldquo;얼마나 빨리 만들 수 있는가\u0026quot;에서 **\u0026ldquo;얼마나 빨리 신뢰할 수 있는가\u0026rdquo;**로 바뀝니다.\nAddy가 강조하는 낙관적 지점은 여기에 있습니다. AI가 만든 코드가 문제라는 뜻이 아니라, AI가 만든 산출물을 신뢰 가능한 방식으로 검증하는 능력이 가장 큰 레버리지가 되었다는 뜻입니다.\n2) 2026년 데이터가 보여주는 리뷰 압박 글은 여러 데이터 포인트를 통해 같은 결론을 제시합니다. AI는 산출량을 늘리지만, 그만큼 리뷰 가능성과 품질 압박도 키웁니다.\nFaros AI 데이터: AI 채택이 높은 팀에서 code churn 861% 증가 incidents-to-PR ratio: 242.7% 증가 per-developer defect rate: 9%에서 54%로 증가 median review duration: 441.5% 증가 zero-review merge: 31.3% 증가 GitClear: 매일 AI를 쓰는 개발자는 raw output이 약 4배지만, 실제 생산성 증가는 약 12% 수준 GitHub: Copilot review는 6천만 건 이상 실행되었고, 플랫폼 리뷰 5건 중 1건 이상에 에이전트가 관여 여기서 중요한 수치는 단순히 \u0026ldquo;AI 코드가 나쁘다\u0026quot;가 아닙니다. 4배의 코드가 약 12%의 전달 가치로 이어진다면, 그 차액은 리뷰·검증·이해 비용으로 돌아온다는 점입니다.\n특히 zero-review merge 증가는 위험합니다. 조직이 명시적으로 리뷰를 포기한 것이 아니라, 리뷰어가 산출량을 따라가지 못하면서 읽히지 않은 코드가 정상처럼 병합되기 시작했다는 신호이기 때문입니다.\n3) 모든 팀이 같은 문제를 풀고 있지는 않다 Addy는 리뷰 강도를 하나의 정답으로 정하지 말라고 말합니다. 리뷰의 적정 수준은 세 변수에 따라 달라집니다.\nBlast radius — 깨졌을 때 아무도 다치지 않는가, 아니면 사용자·돈·개인정보가 걸려 있는가 코드 수명 — 다음 주에 버릴 프로토타입인가, 몇 년 동안 유지할 시스템인가 공유 이해 필요성 — 혼자 머릿속에 담아도 되는가, 팀이 장기적으로 공동 소유해야 하는가 솔로 개발자가 사용자 없는 greenfield 프로젝트를 만들고 있다면, 모든 diff를 깊게 읽는 것은 과할 수 있습니다. 대신 테스트와 자동화에 강하게 기대고, 중요한 부분만 리뷰하는 방식이 합리적입니다.\n반대로 오래된 엔터프라이즈 시스템에서는 같은 접근이 위험합니다. 중복 helper 하나도 미래의 버그 표면이 되고, 아무도 이해하지 못한 변경은 온콜 사고로 이어지는 comprehension debt가 됩니다.\n즉, 나쁜 조언의 대부분은 한 위치의 사람이 다른 위치의 사람에게 자기 규칙을 강요할 때 생깁니다.\n4) 에이전트 PR의 진짜 문제: 사라진 의도 사람이 코드를 작성할 때는 의도가 작성자의 머릿속에 남아 있습니다. 리뷰어는 그 의도를 질문하고 확인할 수 있습니다. 하지만 에이전트가 만든 PR에서는 구현 과정의 추론, 버린 대안, 선택 이유가 diff에 남지 않는 경우가 많습니다.\n그래서 리뷰어는 코드만 보고 \u0026ldquo;왜 이렇게 했는가\u0026quot;를 역추적해야 합니다. Addy는 이것이 리뷰 시간이 크게 늘어나는 핵심 원인 중 하나라고 봅니다.\n해법은 의외로 실용적입니다.\n에이전트가 무엇을 하려 했는지 명시하게 한다. 어떤 대안을 배제했는지 PR에 남긴다. 테스트 결과와 실행 증거를 첨부한다. 변경 의도를 decision log 형태로 보존한다. 이렇게 하면 리뷰어가 첫 번째 인간 독자가 되어 모든 맥락을 복원하는 부담을 줄일 수 있습니다. 핵심은 AI에게 리뷰를 더 시키는 것만이 아니라, 리뷰 가능한 PR을 만들도록 입구 조건을 높이는 것입니다.\n5) AI 리뷰어는 하나의 판정자가 아니라 여러 센서다 글은 AI 리뷰 도구를 긍정적으로 평가합니다. CodeRabbit, Greptile, Anthropic Code Review, Sentry Seer, Cursor BugBot 같은 도구는 실제 버그를 잡고, 사람보다 지치지 않으며, 긴 PR 큐를 triage하는 데 유용합니다.\n하지만 중요한 포인트는 \u0026ldquo;최고의 도구 하나\u0026quot;를 찾는 것이 아닙니다. 서로 다른 도구가 서로 다른 종류의 문제를 잡는다는 점입니다. 한 실험에서는 네 개 리뷰 도구가 617개의 distinct flagged location 중 93.4%를 각자 하나의 도구만 잡았고, 네 도구가 모두 같은 줄을 지적한 경우는 없었습니다.\n따라서 high-stakes 변경에는 서로 다른 성격의 AI 리뷰어를 조합하는 편이 낫습니다.\n넓게 훑는 도구 correctness와 architecture에 강한 도구 production failure severity를 잘 보는 도구 보안·프롬프트 인젝션 위험을 보는 도구 같은 모델 네 개를 돌리는 것은 비싼 단일 리뷰어에 가깝습니다. 반대로 다른 blind spot을 가진 도구를 조합하면 더 넓은 버그 표면을 볼 수 있습니다.\n6) Human in the loop에서 human on the loop로 Addy는 \u0026ldquo;사람이 모든 줄을 읽어야 한다\u0026quot;는 전제가 이미 무너졌다고 봅니다. 산출량이 너무 커졌기 때문입니다. 하지만 그 반대편의 \u0026ldquo;AI가 작성하고 AI가 리뷰하고 AI가 승인하면 된다\u0026quot;도 위험합니다.\n모델들이 같은 계열의 blind spot을 공유하면, 닫힌 루프는 매우 확신에 차 있으면서도 틀릴 수 있습니다. 이때 사람은 줄 단위 리뷰어가 아니라 다음을 책임지는 상위 레벨의 owner가 되어야 합니다.\n이 변경이 애초에 올바른 변경인지 판단 high-blast-radius 경로의 게이트 유지 AI 리뷰 결과를 verdict가 아니라 sensor로 취급 샘플링과 spot-checking으로 리뷰 시스템 감사 merge 책임을 사람에게 고정 Addy가 자신의 오픈소스 프로젝트에서 Claude Code와 Codex를 쓰는 방식도 여기에 가깝습니다. AI에게 PR 묶음을 먼저 읽히고, 안전해 보이는 것·추가 작업이 필요한 것·위험한 것을 분류하게 합니다. 하지만 자동 병합하지는 않습니다. triage는 AI가 돕고, merge 결정은 사람이 갖는 구조입니다.\n7) 실무 적용: 위험도 기반 리뷰 파이프라인 글의 실행 조언은 한 문장으로 정리할 수 있습니다. 모든 변경을 같은 깊이로 리뷰하지 말고, 틀렸을 때의 비용에 맞춰 리뷰 깊이를 조정하라.\n위험도별 계층화 단순 config 변경: linter, CI, 가벼운 확인 UI copy나 boilerplate: 자동 리뷰와 테스트 중심 결제·인증·권한·개인정보 경로: 타입, 테스트, 서로 다른 AI 리뷰어 2개 이상, 시스템 owner 리뷰, 보안 검토 리뷰 입구 조건 강화 리뷰어가 코드를 보기 전에 다음을 요구해야 합니다.\n변경 목적 지나치게 크지 않은 diff 테스트 출력 실제 실행했다는 증거 중요한 설계 선택과 버린 대안 이는 리뷰어에게 의도 복원 비용을 떠넘기지 않기 위한 장치입니다.\n작은 PR 강제 에이전트 PR은 커지기 쉽습니다. 하지만 큰 PR은 사람이 읽기 어렵고, 결국 거절되거나 rubber-stamp될 가능성이 커집니다. 이제 작은 diff는 예의가 아니라 리뷰 시스템의 설계 제약입니다.\n테스트 변경 먼저 읽기 에이전트가 자주 저지르는 실패는 동작을 바꾼 뒤, 깨진 테스트를 고치는 대신 assertion을 새 동작에 맞게 바꿔버리는 것입니다. 테스트가 많이 수정된 PR에서는 구현보다 테스트 diff를 먼저 읽어야 합니다.\nCI는 움직이지 않는 벽으로 유지 에이전트는 악의 없이도 green check를 얻기 위해 lint를 끄거나, coverage 기준을 낮추거나, 테스트를 제거할 수 있습니다. 결정론적 gate는 설득당하지 않는 마지막 방어선이므로 엄격하게 유지해야 합니다.\n8) 팀을 운영한다면 무엇을 측정해야 하는가 AI 도입 후 관리자가 빠지기 쉬운 함정은 \u0026ldquo;코드 작성이 빨라졌으니 인력을 줄여도 된다\u0026quot;는 결론입니다. Addy는 이것이 위험하다고 봅니다. 병목이 작성에서 리뷰로 이동했을 뿐이라면, 리뷰 역량을 줄이는 것은 미래 사고를 사는 일입니다.\n팀은 다음을 실제 자원처럼 측정해야 합니다.\n리뷰 대기 시간 time-to-first-review 리뷰어별 병목 zero-review merge 비율 AI 생성 PR의 크기와 폐기율 테스트 변경을 포함한 PR의 사고율 high-blast-radius 변경의 human owner 통과 여부 merged PR 수만 보면 대시보드는 초록색일 수 있습니다. 하지만 이해되지 않은 변경이 누적되면 속도는 나중에 incident, rollback, 온콜 부담으로 청구됩니다.\n결론 및 시사점 한 줄 결론: AI 시대의 경쟁력은 코드를 더 많이 생성하는 능력이 아니라, 생성된 코드를 신뢰할 수 있게 만드는 리뷰 시스템을 설계하는 능력이다.\nAddy Osmani의 글은 에이전트 코딩을 비관하지 않습니다. 오히려 에이전트가 충분히 좋아졌기 때문에, 이제 엔지니어링의 고급 업무가 코드 작성에서 검증·판단·책임으로 이동했다고 말합니다.\n실무적으로는 세 가지를 당장 적용할 수 있습니다.\n모든 PR에 같은 리뷰 강도를 적용하지 말고 blast radius에 따라 계층화한다. 에이전트 PR에는 변경 의도, 배제한 대안, 테스트 증거를 입구 조건으로 요구한다. AI 리뷰어는 판정자가 아니라 센서로 쓰고, merge 책임은 사람이 가진다. 결국 \u0026ldquo;테스트가 통과했다\u0026quot;와 \u0026ldquo;사람이 무엇이 왜 바뀌었는지 이해하고 책임질 수 있다\u0026quot;는 다릅니다. 에이전트가 바꾼 것은 이 차이를 더 선명하게 만든 것입니다.\n","wordCount":1231,"tags":["AI","agentic-engineering","Addy Osmani","코드리뷰","검증","소프트웨어엔지니어링"],"categories":["AI"],"frameworks":["Risk-based review","Human on the loop","Verification-first engineering"],"mental_models":["Blast radius","Borrowed confidence","Comprehension debt"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["AI는 코드 작성량을 크게 늘렸지만, 신뢰 가능한 검토와 검증 속도는 같은 비율로 빨라지지 않았다","Faros 데이터에서는 코드 churn 861%, incidents-to-PR ratio 242.7%, median review duration 441.5%, zero-review merge 31.3% 증가가 관찰됐다","좋은 리뷰 강도는 작성자가 사람인지 에이전트인지가 아니라 blast radius, 코드 수명, 공유 이해 필요성에 따라 달라져야 한다","에이전트 PR에는 의도와 배제한 선택지가 사라지기 쉬우므로 decision log와 실행 증거를 리뷰 입구 조건으로 요구해야 한다","AI 리뷰어는 verdict가 아니라 sensor이며, 최종 merge 책임은 여전히 사람이 가져야 한다"],"related":["posts/agent-skills-addy-osmani","posts/loop-engineering","posts/agent-harness-engineering"]},{"title":"AI가 소프트웨어 엔지니어를 대체하지 못한 이유, 그리고 앞으로도 대체하지 못할 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/why-ai-hasnt-replaced-software-engineers/","section":"posts","date":"2026-06-13T17:15:01+09:00","lastmod":"2026-06-13T17:15:01+09:00","description":"AI가 코딩 능력에서 가장 빠르게 진보했음에도 소프트웨어 엔지니어를 대체하지 못한 구조적 이유를 Decide-Execute-Deliver Sandwich 모델을 중심으로 분석한다.","summary":"AI가 소프트웨어 엔지니어를 대체할 것이라는 전망이 끊임없이 제기되지만, 실제 데이터는 정반대의 그림을 보여주고 있습니다. AI 적용이 가장 빠르고 앞선 분야인 소프트웨어 엔지니어링에서조차 대규모 해고나 노동력 감소는 일어나지 않았으며, 그 이유는 단순히 AI의 능력 부족이 아니라 소프트웨어 개발이라는 작업의 근본적인 구조 에 있습니다.\nTL;DR 요약 AI 해고는 대부분 AI 워싱 : Block, Snap, Intuit 등 유명 기업의 해고 사례 분석 결과 실제 원인은 재정 압박과 구조조정이었으며, 뉴욕주 WARN Act에서 AI 관련 체크박스를 사용한 사례는 0.2%에 불과하다. Decide-Execute-Deliver Sandwich : AI는 중간의 Execute(코딩)만 압축했을 뿐, 양 끝의 Decide(무엇을 만들지 결정)와 Deliver(테스트·검증·배포·책임)는 여전히 인간의 깊은 맥락 이해가 필요하다. 코딩은 전체 업무의 일부에 불과하다 : 개발자들이 실제로 코딩에 사용하는 시간은 9~61% 수준이며, 나머지는 미팅·디버깅·코드베이스 이해 등에 소요된다. 미국 소프트웨어 엔지니어 고용은 여전히 성장 중 : AI 이후 성장률이 다소 둔화되었을 뿐, 절대 고용 수치는 감소하지 않았다. 원문: Why AI hasn\u0026rsquo;t replaced software engineers, and won\u0026rsquo;t\n","content":"AI가 소프트웨어 엔지니어를 대체할 것이라는 전망이 끊임없이 제기되지만, 실제 데이터는 정반대의 그림을 보여주고 있습니다. AI 적용이 가장 빠르고 앞선 분야인 소프트웨어 엔지니어링에서조차 대규모 해고나 노동력 감소는 일어나지 않았으며, 그 이유는 단순히 AI의 능력 부족이 아니라 소프트웨어 개발이라는 작업의 근본적인 구조 에 있습니다.\nTL;DR 요약 AI 해고는 대부분 AI 워싱 : Block, Snap, Intuit 등 유명 기업의 해고 사례 분석 결과 실제 원인은 재정 압박과 구조조정이었으며, 뉴욕주 WARN Act에서 AI 관련 체크박스를 사용한 사례는 0.2%에 불과하다. Decide-Execute-Deliver Sandwich : AI는 중간의 Execute(코딩)만 압축했을 뿐, 양 끝의 Decide(무엇을 만들지 결정)와 Deliver(테스트·검증·배포·책임)는 여전히 인간의 깊은 맥락 이해가 필요하다. 코딩은 전체 업무의 일부에 불과하다 : 개발자들이 실제로 코딩에 사용하는 시간은 9~61% 수준이며, 나머지는 미팅·디버깅·코드베이스 이해 등에 소요된다. 미국 소프트웨어 엔지니어 고용은 여전히 성장 중 : AI 이후 성장률이 다소 둔화되었을 뿐, 절대 고용 수치는 감소하지 않았다. 원문: Why AI hasn\u0026rsquo;t replaced software engineers, and won\u0026rsquo;t\n핵심 주장 AI가 소프트웨어 엔지니어를 대체하지 못했으며, 앞으로도 능력 향상만으로는 대체하기 어렵다 는 것이 이 글의 핵심입니다. 소프트웨어 엔지니어링은 AI 적용이 가장 빠르고 앞선 분야인데도, 대규모 해고나 노동력 감소가 실제로 일어나지 않고 있다는 증거를 중심으로 설명합니다.\nAI 해고 이야기 대부분은 \u0026lsquo;AI washing\u0026rsquo; Block, Snap, Intuit 등 유명 기업들의 해고 사례를 분석한 결과, 실제로는 재정 압박, 구조조정, 경영층 과장 이 주원인이었습니다.\nCEO들은 AI를 \u0026ldquo;작은 팀으로 일할 수 있게 해준다\u0026quot;고 홍보하지만, 현업 엔지니어들은 생산성 향상이 제한적 이라고 증언합니다. 설문조사 결과, 많은 기업이 해고 이유를 \u0026ldquo;AI\u0026quot;로 포장하지만 실제로 AI로 업무를 대체할 준비가 된 경우는 극소수입니다. 뉴욕주의 WARN Act(대량해고 신고)에서 AI 관련 체크박스를 사용한 사례도 거의 없었습니다(0.2% 수준). 결론적으로 , AI로 인한 실제 노동력 감소보다는 채용 둔화 가 주된 효과입니다. 기존 직원을 해고하는 것은 조직 지식 손실, 비용, 사기 저하 등으로 비효율적이기 때문입니다.\n왜 코딩 에이전트가 노동 대체로 이어지지 않는가 — \u0026ldquo;Decide-Execute-Deliver Sandwich\u0026rdquo; 모델 소프트웨어 개발은 샌드위치 구조 로 볼 수 있습니다.\n단계 설명 AI가 잘하는가 Decide (결정/기획) 무엇을 만들어야 하는지 결정, 문제 정의, 스펙 작성 ❌ 인간의 깊은 이해 필요 Execute (실행) 코드 작성 ✅ AI가 가장 잘 압축하는 부분 Deliver (검증/배포) 테스트, 검증, 통합, 유지보수, 책임 소재 ❌ 맥락·환경 의존도 높음 AI는 Execute(중간) 부분만 압축 했지만, Decide와 Deliver 양 끝 은 여전히 인간의 깊은 이해(코드베이스, 비즈니스 맥락, 환경)가 필요해 자동화가 어렵습니다.\n개발자들이 실제로 업무 시간을 어떻게 쓰는지 살펴보면, 코딩에 할애하는 시간은 9~61%에 불과 합니다. 대부분의 시간은 미팅, 디버깅, 코드베이스 이해 등에 소요됩니다. AI가 코드를 아무리 많이, 빠르게 작성해도 전체 생산성 향상이 미미한 이유가 바로 여기에 있습니다.\n전체적인 전망 미국 소프트웨어 엔지니어 고용은 여전히 성장 중입니다. AI 이후 성장률이 다소 둔화되기는 했지만, 절대적인 고용 수치는 감소하지 않았습니다. AI는 오히려 창업을 쉽게 만들어 새로운 수요를 창출할 가능성도 있습니다. 진입 장벽이 낮아지면 더 많은 소프트웨어 제품이 만들어지고, 결과적으로 더 많은 엔지니어가 필요해질 수 있습니다. 다른 직업들은 소프트웨어 엔지니어링보다 규제·맥락 의존도가 더 높아, AI 대체 측면에서 오히려 더 안전 할 수 있습니다. 결론 및 시사점 AI가 소프트웨어 엔지니어를 대체하지 못하는 이유는 단순히 AI가 \u0026ldquo;아직 충분히 똑똑하지 않아서\u0026quot;가 아닙니다. 소프트웨어 개발이라는 작업 자체가 코딩 외에도 기획, 의사결정, 검증, 책임 소재 등 인간의 깊은 맥락 이해를 요구하는 다층적 구조로 이루어져 있기 때문입니다. AI가 Execute 레이어를 아무리 완벽하게 압축해도, Decide와 Deliver라는 양 끝단은 여전히 인간의 영역으로 남습니다.\n한 줄 결론: AI가 소프트웨어 엔지니어를 대체하지 못한 것은 능력 부족 때문이 아니라, 소프트웨어 개발이라는 작업이 코딩 너머에 훨씬 더 넓은 인간적·맥락적 층위를 가지고 있기 때문이다.\n","wordCount":525,"tags":["AI","코딩에이전트","소프트웨어엔지니어링","자동화","노동시장","AI워싱"],"categories":["AI"],"frameworks":["Systems Thinking","Second-order thinking"],"mental_models":["Decide-Execute-Deliver Sandwich","Pareto Principle"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["CEO들이 AI 해고라 포장한 사례 대부분은 재정 압박·구조조정이 실제 원인이었다","AI는 Execute(코딩)만 압축했을 뿐, Decide(기획)와 Deliver(검증·배포)는 인간의 깊은 맥락 이해가 필요하다","개발자 업무 시간 중 코딩은 9~61%에 불과해, AI가 코딩을 아무리 잘해도 전체 생산성 향상은 제한적이다"],"related":["posts/ai-capability-not-cost-reduction","posts/agentic-software-engineering"]},{"title":"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-11T13:50:53+09:00","lastmod":"2026-06-11T13:50:53+09:00","description":"Ed Zitron이 2026년 6월 8일 발표한 'AI Is Slowing Down'의 핵심 주장을 정리했다. AI 산업의 과도한 투자 대비 성장 둔화, token-based billing의 문제, 순환 경제 구조의 지속 불가능성을 다룬다.","summary":"Ed Zitron이 2026년 6월 8일 발표한 \u0026ldquo;AI Is Slowing Down\u0026rdquo; 은 AI 산업(특히 OpenAI와 Anthropic 중심)을 강하게 비판하는 장문의 분석입니다. 핵심 주장은 AI가 과도한 투자와 약속에 비해 성장 속도가 둔화되고 있으며, 이는 거품 붕괴의 신호 라는 것입니다.\n원문: AI Is Slowing Down\n3줄 핵심 정리 핵심 주장: AI 산업이 수조 달러 투자를 정당화하려면 2030년까지 연간 최소 $2~3T 매출이 필요하지만, 현재 수요는 OpenAI + Anthropic 두 회사에 집중되어 있고 그마저도 적자다. 지출 둔화 증거: Uber, T-Mobile, Brex 등이 token-based billing의 예측 불가능한 비용에 대응해 AI token 지출 상한(cap)을 도입했으며, CFO들은 ROI 측정이 거의 불가능하다고 보고한다. 순환 경제의 붕괴 위험: AI labs → hyperscalers → NVIDIA로 이어지는 circular economy가 유지되려면 매년 2배씩 성장해야 하지만, 실제 제품 가치가 부족해 지속이 불가능하다. IPO 압박: OpenAI와 Anthropic의 IPO 준비는 보다 현실적인 수익 모델(비용 인상, 보조금 축소)을 강요할 것이며, 이는 거품 수축을 가속화할 전망이다. 1) AI는 반드시 폭발적으로 성장해야 하지만, 현실은 그렇지 않다 데이터센터 건설(190GW 규모)과 GPU 구매 등으로 수조 달러 규모의 투자 가 이뤄지고 있습니다. NVIDIA, hyperscalers(Google, Microsoft, Amazon 등), OpenAI/Anthropic의 compute commitment는 수천억 달러에 달합니다.\n","content":"Ed Zitron이 2026년 6월 8일 발표한 \u0026ldquo;AI Is Slowing Down\u0026rdquo; 은 AI 산업(특히 OpenAI와 Anthropic 중심)을 강하게 비판하는 장문의 분석입니다. 핵심 주장은 AI가 과도한 투자와 약속에 비해 성장 속도가 둔화되고 있으며, 이는 거품 붕괴의 신호 라는 것입니다.\n원문: AI Is Slowing Down\n3줄 핵심 정리 핵심 주장: AI 산업이 수조 달러 투자를 정당화하려면 2030년까지 연간 최소 $2~3T 매출이 필요하지만, 현재 수요는 OpenAI + Anthropic 두 회사에 집중되어 있고 그마저도 적자다. 지출 둔화 증거: Uber, T-Mobile, Brex 등이 token-based billing의 예측 불가능한 비용에 대응해 AI token 지출 상한(cap)을 도입했으며, CFO들은 ROI 측정이 거의 불가능하다고 보고한다. 순환 경제의 붕괴 위험: AI labs → hyperscalers → NVIDIA로 이어지는 circular economy가 유지되려면 매년 2배씩 성장해야 하지만, 실제 제품 가치가 부족해 지속이 불가능하다. IPO 압박: OpenAI와 Anthropic의 IPO 준비는 보다 현실적인 수익 모델(비용 인상, 보조금 축소)을 강요할 것이며, 이는 거품 수축을 가속화할 전망이다. 1) AI는 반드시 폭발적으로 성장해야 하지만, 현실은 그렇지 않다 데이터센터 건설(190GW 규모)과 GPU 구매 등으로 수조 달러 규모의 투자 가 이뤄지고 있습니다. NVIDIA, hyperscalers(Google, Microsoft, Amazon 등), OpenAI/Anthropic의 compute commitment는 수천억 달러에 달합니다.\n2030년까지 AI가 연간 수조 달러(최소 $2~3T) 매출 을 내야 이 투자들이 정당화되지만, 현재 수요는 OpenAI + Anthropic 두 회사에 집중되어 있고, 그마저도 적자투성입니다. \u0026ldquo;두 개의 OpenAI급 회사가 더 필요\u0026rdquo; 할 정도로 추가 수요가 절실하지만, 실제 기업들의 AI 지출은 제한적입니다.\n2) AI 지출 둔화 징후 기업들이 token-based billing 도입 후 비용 통제가 어려워지고 있습니다. CFO들이 비용 가시성 부족과 예측 불가능성을 호소하고 있습니다.\nUber, T-Mobile, Brex 등에서 AI token 지출 상한(cap)을 도입 ROI(투자 수익률) 측정이 거의 불가능하다는 증거들이 쏟아짐 \u0026ldquo;Agent\u0026rdquo;, \u0026ldquo;loops\u0026rdquo; 등 새로운 buzzword로 더 많은 token 소비를 유도하려 하지만, 이는 고객 착취로 보임 생성 AI가 생산성을 높이지 못하고, slop(저품질 출력) 만 양산한다는 비판 3) 거품 구조와 지속 불가능성 AI labs → hyperscalers → NVIDIA로 이어지는 순환 경제(circular economy) 가 유지되려면 지속적인 성장(매년 2배씩)이 필수지만, 실제 제품 가치가 부족합니다.\n비용은 계속 상승하고, 효율화 대신 hype로 버티는 상황입니다. OpenAI/Anthropic 모두 IPO를 준비 중인데, 이는 더 현실적인 수익 모델(비용 인상, 보조금 축소)을 강요할 전망입니다. IPO 이후에는 더 이상 내부 투자로 적자를 감당할 수 없게 되고, 공개 시장의 수익성 압박이 거품 수축을 가속화할 수 있습니다.\n4) 저자의 결론 AI 산업은 hype, debt(부채), subsidy(보조금)로 버티는 con(사기) 에 가깝고, 곧 desperate(절박) 해질 것이라고 저자는 주장합니다. tech worker들의 고통(강제 AI 사용, layoffs 속 생산성 압박)을 강조하며, 곧 중대한 폭로 기사 를 예고하고 있습니다.\n저자는 AI를 Wild Wild West의 거대 금속 거미에 비유하며, 비싸고 불안정하며 실질적 가치가 부족하다고 비판합니다. Ed Zitron 특유의 직설적·풍자적 스타일로, AI booster(찬양론자)와 Business Idiots(무능한 경영진)를 강하게 비난합니다.\n결론 및 시사점 AI 산업은 기술 발전 속도보다 투자 규모가 훨씬 빠르게 성장하면서 수익성과 현실 수요 간의 괴리가 커지고 있다. token-based billing은 기업 고객의 비용 가시성을 낮추고 예측 불가능한 지출을 유발해, 오히려 AI 도입 확장의 걸림돌이 되고 있다. IPO를 통한 자본 조달은 단기적 유동성 해결책이 될 수 있지만, 공개 시장의 수익성 압박이 현재의 적자 모델을 지속 불가능하게 만들 수 있다. 한 줄 결론: AI 산업이 스스로를 유지하기 위해 필요한 성장률과 실제 시장 수요 간의 간격이 좁혀지지 않는다면, 현재의 투자 붐은 거품 붕괴로 이어질 수 있다 는 것이 이 글의 핵심 메시지입니다.\n","wordCount":494,"tags":["AI","거품","Ed Zitron","경제","투자"],"categories":["AI"],"frameworks":["순환 경제 분석","투자 수익률 분석","거품 진단"],"mental_models":["자연 독점","진입 장벽","신호와 노이즈"],"philosophy_type":"economics","schema_type":"Article","actionable":false,"priority":"high","key_points":["Ed Zitron은 AI 산업이 수조 달러 투자 대비 연간 최소 $2~3T 매출이 필요하지만 현실 수요는 턱없이 부족하다고 진단한다","기업들이 token-based billing 도입 후 비용 통제 불가능을 경험하며 Uber, T-Mobile, Brex 등에서 AI 지출 상한을 도입하기 시작했다","AI labs → hyperscalers → NVIDIA로 이어지는 순환 경제가 유지되려면 매년 2배 성장이 필수지만 제품 가치가 이를 뒷받침하지 못한다","OpenAI와 Anthropic의 IPO 준비는 보다 현실적인 수익 모델을 강요할 전망이며 저자는 이를 거품 붕괴의 신호로 해석한다"],"related":["posts/the-eternal-sloptember-summary","posts/hidden-llm-api-costs"]},{"title":"Modern Engineering Values — AI 시대, 코딩이 병목이 아닐 때 엔지니어에게 남은 것","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/modern-engineering-values/","section":"posts","date":"2026-06-10T21:25:35+09:00","lastmod":"2026-06-10T21:25:35+09:00","description":"Christoph Nakazawa가 AI 코딩 에이전트 시대에 엔지니어링의 핵심 가치가 어떻게 변화하는지 실제 경험을 바탕으로 정리한 Modern Engineering Values의 핵심 내용","summary":"Christoph Nakazawa(React/Vite/Jest 핵심 기여자)가 2026년 6월, AI 코딩 에이전트(특히 Codex CLI + GPT 5.5)로 여러 프로젝트를 거의 100% AI로 개발/개선한 경험을 바탕으로 엔지니어링의 핵심 가치가 어떻게 변화해야 하는지 정리한 글입니다.\n원문: Modern Engineering Values\nTL;DR 요약 강한 소유권(Strong Ownership) : 도메인을 깊이 아는 2~3명 팀이 독립된 저장소에서 일할 때 AI의 증폭 효과가 극대화된다. 코드 리뷰는 스타일 논쟁이 아닌 \u0026lsquo;정렬(alignment)\u0026rsquo; 중심으로. 취향(Taste) : AI는 엄청난 양의 쓰레기 코드도 빠르게 생성한다. 중요한 것은 \u0026lsquo;무엇을 만들 가치가 있는지\u0026rsquo; 판단하는 능력. 가드레일과 피드백 루프 : 린트·자동 테스트·빠른 검증 도구가 강력할수록 AI가 빠르고 정확하게 일한다. 변경된 파일 중심으로 동작해야 함. Repo 속 맥락 : AI 세션은 매번 새로운 직원이 들어오는 것과 같다. 모든 원칙과 설계를 저장소 안에 명확히 문서화하라. 직접 소유(Own your Stack) : 핵심 부분(데이터, UI, i18n)은 직접 소유해 제품 경험을 완전히 통제하라. 옵션 가치 : 변경할 때마다 미래에 더 많은 선택지를 열어주는 방향으로 설계하라. 핵심 메시지 — 코딩이 병목에서 판단으로 AI 코딩 에이전트(Codex CLI + GPT 5.5)가 등장하면서 프로그래밍 방식이 근본적으로 바뀌었다. 이제 손으로 코드를 거의 쓰지 않게 되었고 , 에이전트가 인간 수준 이상의 코드를 몇 분 만에 작성한다. 코딩 자체는 더 이상 병목이 아니며, 엔지니어링의 본질은 \u0026ldquo;코드를 직접 쓰는 것\u0026rdquo; 에서 시스템을 지휘하고 판단하는 것 으로 이동했다.\n","content":"Christoph Nakazawa(React/Vite/Jest 핵심 기여자)가 2026년 6월, AI 코딩 에이전트(특히 Codex CLI + GPT 5.5)로 여러 프로젝트를 거의 100% AI로 개발/개선한 경험을 바탕으로 엔지니어링의 핵심 가치가 어떻게 변화해야 하는지 정리한 글입니다.\n원문: Modern Engineering Values\nTL;DR 요약 강한 소유권(Strong Ownership) : 도메인을 깊이 아는 2~3명 팀이 독립된 저장소에서 일할 때 AI의 증폭 효과가 극대화된다. 코드 리뷰는 스타일 논쟁이 아닌 \u0026lsquo;정렬(alignment)\u0026rsquo; 중심으로. 취향(Taste) : AI는 엄청난 양의 쓰레기 코드도 빠르게 생성한다. 중요한 것은 \u0026lsquo;무엇을 만들 가치가 있는지\u0026rsquo; 판단하는 능력. 가드레일과 피드백 루프 : 린트·자동 테스트·빠른 검증 도구가 강력할수록 AI가 빠르고 정확하게 일한다. 변경된 파일 중심으로 동작해야 함. Repo 속 맥락 : AI 세션은 매번 새로운 직원이 들어오는 것과 같다. 모든 원칙과 설계를 저장소 안에 명확히 문서화하라. 직접 소유(Own your Stack) : 핵심 부분(데이터, UI, i18n)은 직접 소유해 제품 경험을 완전히 통제하라. 옵션 가치 : 변경할 때마다 미래에 더 많은 선택지를 열어주는 방향으로 설계하라. 핵심 메시지 — 코딩이 병목에서 판단으로 AI 코딩 에이전트(Codex CLI + GPT 5.5)가 등장하면서 프로그래밍 방식이 근본적으로 바뀌었다. 이제 손으로 코드를 거의 쓰지 않게 되었고 , 에이전트가 인간 수준 이상의 코드를 몇 분 만에 작성한다. 코딩 자체는 더 이상 병목이 아니며, 엔지니어링의 본질은 \u0026ldquo;코드를 직접 쓰는 것\u0026rdquo; 에서 시스템을 지휘하고 판단하는 것 으로 이동했다.\n저자는 여러 프로젝트(Vite+, fate, Codiff, Athena Crisis, Void 등)를 거의 100% AI로 개발/개선하면서 이 변화를 체감했다.\n1. Strong Ownership (강한 소유권) 최고의 엔지니어는 도메인 전문성과 강한 소유권을 가진다. AI는 이 소유권을 증폭시킨다. 맥락을 잘 아는 사람은 빠르게 실행하고 , 모르는 사람은 노이즈만 만든다.\n효과적인 팀은 작고(2~3명) , 명확한 소유 경계, 독립된 저장소를 가진다. (모노레포 선호자였던 저자도 이제 인정) 코드 리뷰는 코드 스타일 논쟁이 아니라 정렬(alignment) 중심으로, 이미 논의된 내용은 최소화한다.\n2. Taste, Taste, Taste (취향, 취향, 취향) AI는 엄청난 양의 \u0026ldquo;bullshit(쓰레기 코드)\u0026rdquo; 을 빠르게 생성한다. 좋은 취향이란 단순히 좋은 제품을 만드는 것이 아니라, 무엇을 만들 가치가 있는지 판단하는 능력이다. 팀은 \u0026ldquo;무엇을 할지\u0026rdquo; 결정하는 데 더 많은 시간을 투자해야 한다.\n3. Strict Guardrails \u0026amp; Fast Feedback Loops (엄격한 가드레일과 빠른 피드백 루프) AI에게 코드를 맡기는 것은 \u0026ldquo;맥락 없는 신입을 계속 투입하는 것\u0026rdquo; 과 같다. 린트, 자동 테스트, 빠른 검증 도구 등이 강력할수록 AI가 더 빠르고 정확하게 일한다. 도구는 전체 repo가 아닌 변경된 파일 중심으로 빠르게 동작해야 한다.\n4. Context in the Repo (저장소 안에 모든 맥락 넣기) 과거 맥락은 Notion, 사람, 암묵적 지식 등에 흩어져 있었다. AI 세션은 매번 \u0026ldquo;새로운 직원\u0026rdquo; 이므로, 모든 중요한 맥락(원칙, 취향, 설계 등)을 repo 안에 명확히 문서화하라. 이는 인간과 AI 모두에게 코드베이스를 더 접근하기 쉽게 만든다.\n5. Own your Stack (스택을 직접 소유하라) 과거에는 서드파티 의존성이 많았지만, 이제는 비용 구조가 바뀌었다. 핵심 부분(데이터, UI, i18n 등)은 직접 소유 해서 제품 경험을 완전히 통제하라. 저자는 자신만의 JavaScript 스택을 오픈소스로 구축해 사용 중이다.\n6. Option Value (옵션 가치 극대화) 변경할 때마다 미래 옵션을 더 많이 열어주는 방향으로 설계하라. AI 시대에는 대규모 리팩토링이 쉬워졌지만, 잘못된 선택으로 막다른 길에 빠지면 탈출이 어렵다.\n관리(Management)에 대한 생각 관리자도 기술 리더십을 유지해야 한다(Tech Lead Management). 실행 비용이 낮아지면서 관리자는 방향성뿐 아니라 실제 코드 변경과 기술 판단 까지 할 수 있어야 한다.\n생산성 변화 저자의 최근 30일 통계:\n하루 평균 15k 라인 수정, 770 commits (2년 전 대비 3배 이상) 최고 손코딩 시절 하루 1,200 라인 → 지금은 10배 이상 , 더 높은 품질 로 결론 및 시사점 AI가 코드를 쓰는 시대에도 엔지니어링의 핵심 가치 는 크게 변하지 않았다. 다만 실행 속도가 폭발적으로 빨라졌을 뿐. 이제 병목은 판단력과 취향 이다. 강한 소유권, 명확한 가드레일, repo 속 맥락 문서화, 직접 소유하는 스택, 옵션 가치를 고려한 설계 — 이 모든 원칙은 AI 시대에 더욱 중요해졌다.\n한 줄 결론: AI가 코드를 쓰는 시대, 병목은 \u0026lsquo;코딩 속도\u0026rsquo;에서 \u0026lsquo;무엇을 만들지 판단하는 취향과 시스템을 설계하는 판단력\u0026rsquo;으로 이동했다.\n","wordCount":582,"tags":["AI","에이전트","엔지니어링","Codex","개발철학"],"categories":["AI","Engineering"],"frameworks":["First Principles"],"mental_models":["Strong Ownership","Option Value"],"philosophy_type":"engineering-philosophy","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI가 코드를 쓰는 시대, 병목은 '코딩 속도'가 아니라 '판단력과 취향(taste)'으로 이동했다","강한 소유권(Strong Ownership)을 가진 소수(2~3명) 팀이 가장 효과적이며, AI는 이 소유권을 증폭시킨다","저장소 안에 모든 맥락(Context)을 문서화해야 AI와 인간 모두 생산적일 수 있다","핵심 스택은 직접 소유(Own your Stack)하고, 변경 시 미래 옵션(Option Value)을 최대화하라","저자의 최근 30일간 하루 평균 15k 라인, 770 commits — 손코딩 시절 대비 10배 이상의 생산성"],"related":["posts/agentic-engineering-management","posts/agentic-software-engineering","posts/anatomy-of-an-agent-harness"]},{"title":"Loop Engineering — 프롬프트 엔지니어링에서 시스템 설계로의 전환","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/loop-engineering/","section":"posts","date":"2026-06-10T14:36:10+09:00","lastmod":"2026-06-10T14:36:10+09:00","description":"Addy Osmani가 제시하는 Loop Engineering — AI 코딩 에이전트를 직접 프롬프트하는 대신, 에이전트를 프롬프트하고 관리하는 시스템(Loop)을 설계하는 접근법과 5가지 핵심 구성 요소.","summary":"Addy Osmani가 2026년 6월 8일 Substack을 통해 제시한 개념으로, AI 코딩 에이전트(Claude Code, Codex 등)를 직접 프롬프트 하는 대신 에이전트를 프롬프트하고 관리하는 시스템(Loop) 을 설계하는 접근법입니다.\n원문: Loop Engineering\nTL;DR 요약 핵심 전환 : \u0026ldquo;에이전트를 프롬프트하지 말고, 에이전트를 프롬프트하는 Loop를 설계하라\u0026rdquo; — 프롬프트 엔지니어링에서 시스템 설계로의 전환. Loop의 정의 : AI가 스스로 작업 발견 → 처리 → 검증 → 다음 작업 결정하는 재귀적·자동화된 루프. 타이머 기반 실행, 하위 에이전트 생성, 자체 유지. 5+1 구성 요소 : Automations(스케줄 기반 작업 발견), Worktrees(병렬 작업 격리), Skills(프로젝트 지식 저장), Plugins(외부 도구 연결), Sub-agents(Maker-Checker 분리), Memory(디스크 기반 상태 관리). 실전 예시 : 매일 아침 자동화로 CI 실패 발견 → Skills로 분석 → Worktree에서 Sub-agent 수정 → PR 생성 → 티켓 업데이트. 리스크 : 검증은 여전히 인간 몫이며, Comprehension Debt와 Cognitive Surrender가 주요 위험 요소. 핵심 개념 Loop Engineering은 Agent Harness Engineering의 상위 개념입니다.\n","content":"Addy Osmani가 2026년 6월 8일 Substack을 통해 제시한 개념으로, AI 코딩 에이전트(Claude Code, Codex 등)를 직접 프롬프트 하는 대신 에이전트를 프롬프트하고 관리하는 시스템(Loop) 을 설계하는 접근법입니다.\n원문: Loop Engineering\nTL;DR 요약 핵심 전환 : \u0026ldquo;에이전트를 프롬프트하지 말고, 에이전트를 프롬프트하는 Loop를 설계하라\u0026rdquo; — 프롬프트 엔지니어링에서 시스템 설계로의 전환. Loop의 정의 : AI가 스스로 작업 발견 → 처리 → 검증 → 다음 작업 결정하는 재귀적·자동화된 루프. 타이머 기반 실행, 하위 에이전트 생성, 자체 유지. 5+1 구성 요소 : Automations(스케줄 기반 작업 발견), Worktrees(병렬 작업 격리), Skills(프로젝트 지식 저장), Plugins(외부 도구 연결), Sub-agents(Maker-Checker 분리), Memory(디스크 기반 상태 관리). 실전 예시 : 매일 아침 자동화로 CI 실패 발견 → Skills로 분석 → Worktree에서 Sub-agent 수정 → PR 생성 → 티켓 업데이트. 리스크 : 검증은 여전히 인간 몫이며, Comprehension Debt와 Cognitive Surrender가 주요 위험 요소. 핵심 개념 Loop Engineering은 Agent Harness Engineering의 상위 개념입니다.\n\u0026ldquo;You shouldn\u0026rsquo;t be prompting coding agents anymore. You should be designing loops that prompt your agents.\u0026rdquo; — Peter Steinberger\n한 번 시스템을 설계하면 AI가 스스로 작업을 발견 → 처리 → 검증 → 다음 작업 결정하는 재귀적·자동화된 루프 를 만듭니다. 이 루프는 타이머 기반으로 실행되고, 하위 에이전트를 생성하며, 스스로 유지됩니다.\nLoop의 5가지 핵심 구성 요소 (+ 메모리) 1. Automations (자동화) 스케줄(또는 cron)에 따라 스스로 작업을 발견하고 triage합니다.\nCodex의 Automations 탭, Claude의 /loop, /goal 등이 해당. 발견된 이슈는 Triage inbox로 모이고, 완료되지 않으면 계속 반복. 사람이 일일이 지시하지 않아도 Loop가 스스로 \u0026ldquo;무엇을 해야 하는가\u0026quot;를 결정. 2. Worktrees (작업 격리) 여러 에이전트가 동시에 작업할 때 파일 충돌을 방지합니다.\nGit worktree로 별도 체크아웃 사용. 병렬 작업의 안정성을 확보하고, 실패 시 롤백이 용이. 3. Skills (SKILL.md) 프로젝트 지식(컨벤션, 빌드 단계, 과거 결정 등)을 한 번 기록해 에이전트가 매번 재학습하지 않게 합니다.\n의도(intent) 누출 방지 — 프롬프트마다 모든 지식을 반복하지 않아도 됨. 프로젝트의 암묵지를 명시적 지식으로 변환하는 투자. 4. Plugins \u0026amp; Connectors (MCP 기반) 이슈 트래커(Linear), Slack, DB, API 등 외부 도구와 연결합니다.\n루프가 실제 환경에서 PR 열기, 티켓 업데이트 등을 자동으로 수행. Loop가 \u0026ldquo;생각만 하는\u0026rdquo; 시스템이 아닌, 실제 작업 환경과 통합된 실행 시스템이 되게 함. 5. Sub-agents (하위 에이전트) Maker(작성)와 Checker(검증) 를 분리합니다.\n한 에이전트가 코드를 작성하면 다른 에이전트가 검토. /goal에서도 검증 모델이 별도로 종료 조건을 확인. Automated Doubt 프로세스와 동일한 철학: 단일 관점의 한계를 다중 관점으로 극복. 메모리 Markdown 파일, Linear 보드 등 디스크 기반 상태 관리.\n모델은 세션마다 기억을 잊기 때문에, Loop가 자신의 진행 상태를 디스크에 기록해야 지속적인 작업이 가능. 실제 Loop 예시 매일 아침 Automations가 CI 실패, 이슈 상태 확인 Skills로 실패 원인 분석 (컨벤션, 과거 패턴 참조) Worktree에서 Sub-agent가 수정안 작성 검증 Sub-agent가 변경사항 검토 검증 통과 시 Plugins로 PR 열고 티켓 업데이트 Codex와 Claude Code 모두 비슷한 기능을 제공하므로, 특정 도구에 종속되지 않는 도구 독립적 설계 가 가능합니다.\n한계와 주의점 검증은 여전히 인간 몫 : 루프가 실수할 수 있으므로 최종 확인은 필수. Comprehension Debt : 루프가 빠르게 코드를 생성하면 인간 이해도가 뒤처질 수 있음. Cognitive Surrender : 루프에 너무 의존하면 판단력을 잃을 위험. Token 비용 : 사용량이 폭발할 수 있어 비용 관리가 중요. 결론 및 시사점 Loop Engineering은 프롬프트 엔지니어링 → 시스템 설계 로의 전환을 의미하며, AI 코딩 워크플로의 미래 방향을 제시한다. 핵심은 Maker-Checker 분리, 스케줄 기반 자동화, 프로젝트 지식의 명시화(Skills), 외부 도구 통합(Plugins)의 네 축을 유기적으로 연결하는 것이다. Comprehension Debt와 Cognitive Surrender는 Loop 도입 시 반드시 관리해야 하는 리스크이며, 인간 엔지니어가 여전히 판단의 중심에 있어야 한다. 아직 초기 단계이므로 신중하게 도입하고, 직접 프롬프팅과의 균형을 유지하는 것이 바람직하다. 한 줄 결론: Loop Engineering은 AI 에이전트에 명령을 내리는 것이 아니라, 에이전트가 스스로 일하게 만드는 시스템을 설계하는 일이다 — 프롬프트 엔지니어링의 종말이자, 시스템 엔지니어링의 새로운 시작.\n","wordCount":573,"tags":["AI","에이전트","Loop-Engineering","코딩","자동화","소프트웨어엔지니어링","Addy-Osmani"],"categories":["AI"],"frameworks":["Loop Engineering","Agent Harness Engineering","Automation-First Design"],"mental_models":["자기 증폭 루프","Maker-Checker 분리","의도 누출 방지"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Loop Engineering은 AI 에이전트를 직접 프롬프트하지 않고, 에이전트를 프롬프트하는 시스템을 설계하는 접근법이다","5가지 핵심 구성 요소: Automations, Worktrees, Skills, Plugins \u0026 Connectors, Sub-agents","Maker(작성)와 Checker(검증)를 분리하여 품질을 확보한다","Loop는 Comprehension Debt와 Cognitive Surrender 위험을 동반하므로 인간 판단이 여전히 중심이어야 한다","에이전트의 의도 누출을 막기 위해 SKILL.md로 프로젝트 지식을 한 번 기록하고 재학습을 방지한다"],"related":["posts/anatomy-of-an-agent-harness","posts/agent-harness-engineering","posts/automated-doubt-development-process","posts/agent-skills-addy-osmani"]},{"title":"자동화된 의심 — AI 개발에서 신뢰를 회복하는 다중 에이전트 검증 프로세스","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/automated-doubt-development-process/","section":"posts","date":"2026-06-10T13:46:31+09:00","lastmod":"2026-06-10T13:46:31+09:00","description":"Alex Self의 Automated Doubt 프로세스 — 설계·구현·배포 전 단계에서 특화된 서브에이전트를 활용해 가정, 보안, 완전성을 철저히 검증하는 다중 에이전트 개발 워크플로.","summary":"Alex Self가 AI(특히 Claude)를 활용한 개발 과정에서 신뢰 부족 을 극복하기 위해 만든 \u0026lsquo;자동화된 의심(Automated Doubt)\u0026rsquo; 프로세스를 소개합니다. 핵심은 다중 에이전트(multi-agent) 를 통해 설계·구현 단계에서 철저한 검증과 비판을 앞당기는 것입니다.\n원문: My Automated Doubt Development Process\nTL;DR 요약 핵심 문제 : AI에 \u0026ldquo;너무 많이, 너무 빨리\u0026rdquo; 맡기다 신뢰를 잃음. 하나의 LLM으로는 놓치는 부분이 많다. 해결책 : 의심(doubt)을 자동화하고, 여러 관점(parallax)에서 반복 검증하는 다중 에이전트 프로세스. Phase 1 - Design : Pre-Implementation Architect, Assumption Excavator, Gap Analyzer 등으로 Spec 검증 (10~25개 findings). Phase 2 - Development : 구현은 단일 Claude가 담당. Post-Implementation Workflow에서 Code Validator, Security Analyst 등으로 15~35개 findings 도출 후 수정 반복. Phase 3 - Ship : Anxiety Reader, API Contract Validator, Release Readiness Validator 등으로 최종 배포 적합성 판단. 주요 철학 초기 AI 사용 시 \u0026ldquo;너무 많이, 너무 빨리\u0026rdquo; 맡기다 신뢰를 잃음. 해결책: 의심(doubt)을 자동화 하고, 여러 관점(parallax)에서 반복 검증. 하나의 LLM이 아닌, 특화된 서브에이전트 들을 활용해 설계 누락, 가정, 보안, 완전성 등을 철저히 파헤침. 개발 프로세스 3단계 1. Phase 1 — Design (설계 단계) 아이디어 → Claude에게 Spec(PRD) 작성 요청으로 시작합니다.\n","content":"Alex Self가 AI(특히 Claude)를 활용한 개발 과정에서 신뢰 부족 을 극복하기 위해 만든 \u0026lsquo;자동화된 의심(Automated Doubt)\u0026rsquo; 프로세스를 소개합니다. 핵심은 다중 에이전트(multi-agent) 를 통해 설계·구현 단계에서 철저한 검증과 비판을 앞당기는 것입니다.\n원문: My Automated Doubt Development Process\nTL;DR 요약 핵심 문제 : AI에 \u0026ldquo;너무 많이, 너무 빨리\u0026rdquo; 맡기다 신뢰를 잃음. 하나의 LLM으로는 놓치는 부분이 많다. 해결책 : 의심(doubt)을 자동화하고, 여러 관점(parallax)에서 반복 검증하는 다중 에이전트 프로세스. Phase 1 - Design : Pre-Implementation Architect, Assumption Excavator, Gap Analyzer 등으로 Spec 검증 (10~25개 findings). Phase 2 - Development : 구현은 단일 Claude가 담당. Post-Implementation Workflow에서 Code Validator, Security Analyst 등으로 15~35개 findings 도출 후 수정 반복. Phase 3 - Ship : Anxiety Reader, API Contract Validator, Release Readiness Validator 등으로 최종 배포 적합성 판단. 주요 철학 초기 AI 사용 시 \u0026ldquo;너무 많이, 너무 빨리\u0026rdquo; 맡기다 신뢰를 잃음. 해결책: 의심(doubt)을 자동화 하고, 여러 관점(parallax)에서 반복 검증. 하나의 LLM이 아닌, 특화된 서브에이전트 들을 활용해 설계 누락, 가정, 보안, 완전성 등을 철저히 파헤침. 개발 프로세스 3단계 1. Phase 1 — Design (설계 단계) 아이디어 → Claude에게 Spec(PRD) 작성 요청으로 시작합니다.\nPre-Implementation Workflow 실행:\n에이전트 역할 Pre-Implementation Architect 전체 설계 구조 검토 Documentation Validator 문서 완전성 및 일관성 검증 Assumption Excavator 숨은 가정과 암묵적 전제 발굴 Gap Analyzer 설계 누락 영역 식별 Implied Completeness Detector 암시적 완결성의 허점 탐지 Ambiguity Mapper 모호한 지점 매핑 발견된 문제(10~25개 정도)를 Spec에 반영 → 최종 검토 후 Checklist 생성. 2. Phase 2 — Development (개발 단계) Spec + Checklist 기반으로 단일 Claude 인스턴스가 구현 (서브에이전트는 쓰기 작업에는 거의 사용 안 함 — 신뢰 문제 때문). 구현 완료 후 Post-Implementation Workflow 반복 실행: 에이전트 역할 Code Validator 요구사항 대비 구현 검증 Type Safety Validator 타입 안전성 점검 Test Architect 테스트 커버리지 및 전략 검토 Code Optimizer 성능·구조 최적화 포인트 Public Interface Validator 공개 API 계약 검증 Security Analyst 보안 취약점 분석 15~35개 findings(치명적 문제 다수) → 수정 → 재실행 반복. 3. Phase 3 — Wrap-up and Ship (마무리 \u0026amp; 배포) Ship Workflow 실행: 기존 검증 에이전트 + 배포 특화 에이전트:\n에이전트 역할 Anxiety Reader 개발자의 직감적 불안 요소 포착 API Contract Validator API 계약 최종 검증 Release Readiness Validator 배포 준비도 종합 판단 최종적으로 \u0026ldquo;배포 준비됐는가?\u0026rdquo; 판단. 2회 이상 반복 가능. 특징 및 고려사항 Scope에 따라 유연하게 적용 : Small / Medium / Large로 나누어 과도한 오버헤드 방지. 토큰 비용이 상당히 들 수 있음 — 과도한 프로젝트에는 overkill. Assumption Excavator 는 거의 모든 아티팩트(코드, 스펙, 문서)에 추천할 만한 강력한 에이전트. 저자는 에이전트·파이프라인을 GitHub에 공개함. 결론 및 시사점 자동화된 의심 프로세스는 AI와 인간(Operator) 간의 품질 협상 이며, 주관적·객관적 기준이 수렴할 때까지 반복한다. 쓰기 작업은 단일 Claude 인스턴스에 맡기고, 검증만 다중 에이전트로 수행하는 분업 구조가 신뢰 확보의 핵심이다. 설계 단계에서 Assumption Excavator처럼 숨은 가정을 발굴하는 에이전트가 특히 강력하며, 모든 개발 단계에 적용 가능하다. 결국 \u0026ldquo;언제 멈출 것인가\u0026quot;는 개발자의 판단과 경험에 달려 있으며, 이 프로세스는 그 판단을 더 빠르고 정확하게 만드는 도구다. 한 줄 결론: AI 개발의 신뢰는 단일 LLM의 출력을 그대로 믿는 것이 아니라, 여러 전문화된 에이전트가 교차 검증하며 의심을 자동화할 때 회복된다.\n","wordCount":489,"tags":["AI","에이전트","Claude","개발프로세스","검증","품질","소프트웨어엔지니어링"],"categories":["AI"],"frameworks":["Multi-Agent Verification","Pre/Post-Implementation Audit","Iterative Quality Negotiation"],"mental_models":["자동화된 의심","시차 검증","품질 협상"],"philosophy_type":"engineering-process","schema_type":"HowTo","actionable":true,"priority":"high","key_points":["AI 개발의 신뢰 부족을 다중 에이전트 기반 검증으로 극복한다","Pre-Implementation Workflow에서 Assumption Excavator 등으로 설계 단계의 누락을 발굴한다","Post-Implementation Workflow에서 Code Validator, Security Analyst 등으로 구현을 검증한다","쓰기 작업은 단일 Claude 인스턴스가 담당하고, 서브에이전트는 검증에만 활용한다","최종 품질 판단은 개발자의 경험과 판단에 달려 있다"],"related":["posts/agentic-code-review-addy-osmani","posts/agentic-software-engineering","posts/loop-engineering"]},{"title":"Senior에서 Staff로 성장하는 법 — AI 시대의 마인드셋 전환과 세 가지 차원","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/senior-to-staff-engineer-growth/","section":"posts","date":"2026-06-10T13:34:39+09:00","lastmod":"2026-06-10T13:34:39+09:00","description":"Jordan Cutler가 제시하는 Senior에서 Staff Engineer로 성장하는 핵심 마인드셋 — Surface Area 확장, 팀 간 영향력, 확장 가능한 시스템 구축의 세 가지 차원과 실전 사례.","summary":"Jordan Cutler(Pinterest Staff Engineer)가 Senior에서 Staff Engineer로 성장하는 데 필요한 마인드셋 변화 와 실전 사례를 정리한 글입니다. Staff Engineer는 단순히 더 깊은 기술력이나 빠른 실행력이 아니라, 다른 차원의 영향력 을 발휘하는 역할이라는 점을 강조합니다.\n원문: How to Grow From Senior to Staff Engineer in the AI Era\nTL;DR 요약 핵심 전환: Senior → Staff는 \u0026ldquo;내가 더 많은 코드를 쓰는 것\u0026quot;에서 \u0026ldquo;다른 사람들이 더 많은 일을 할 수 있게 만드는 것\u0026quot;으로의 전환이다. Surface Area 확장: 주어진 업무 외에 자발적으로 기회를 만들고 가치를 먼저 증명하면 조직적 영향력이 따라온다. 팀 간 영향력: 문제만 지적하지 말고, 데이터 + 구체적 해결책 + 도움 제안을 함께 전달해야 신뢰와 실행을 이끌어낸다. 확장 가능한 시스템: 내가 없어도 돌아가고, 다른 팀까지 자연스럽게 확장되는 시스템을 구축하는 것이 multiplier의 본질이다. AI 시대 함의: Heads-down 코딩에서 벗어나 영향력과 시스템을 만드는 multiplier 사고가 더 중요해졌다. Staff Engineer가 되는 데 방해가 되는 것 기술 깊이, 실행 속도, 복잡한 시스템에만 집중하는 것 \u0026ldquo;개인 기여\u0026rdquo; 중심 사고에서 벗어나지 못함 Staff로 성장하지 못하는 엔지니어들의 공통점은 기술 역량 자체가 부족해서가 아니라, 그 기술을 조직 전체로 확장하지 못한다는 점입니다.\n","content":"Jordan Cutler(Pinterest Staff Engineer)가 Senior에서 Staff Engineer로 성장하는 데 필요한 마인드셋 변화 와 실전 사례를 정리한 글입니다. Staff Engineer는 단순히 더 깊은 기술력이나 빠른 실행력이 아니라, 다른 차원의 영향력 을 발휘하는 역할이라는 점을 강조합니다.\n원문: How to Grow From Senior to Staff Engineer in the AI Era\nTL;DR 요약 핵심 전환: Senior → Staff는 \u0026ldquo;내가 더 많은 코드를 쓰는 것\u0026quot;에서 \u0026ldquo;다른 사람들이 더 많은 일을 할 수 있게 만드는 것\u0026quot;으로의 전환이다. Surface Area 확장: 주어진 업무 외에 자발적으로 기회를 만들고 가치를 먼저 증명하면 조직적 영향력이 따라온다. 팀 간 영향력: 문제만 지적하지 말고, 데이터 + 구체적 해결책 + 도움 제안을 함께 전달해야 신뢰와 실행을 이끌어낸다. 확장 가능한 시스템: 내가 없어도 돌아가고, 다른 팀까지 자연스럽게 확장되는 시스템을 구축하는 것이 multiplier의 본질이다. AI 시대 함의: Heads-down 코딩에서 벗어나 영향력과 시스템을 만드는 multiplier 사고가 더 중요해졌다. Staff Engineer가 되는 데 방해가 되는 것 기술 깊이, 실행 속도, 복잡한 시스템에만 집중하는 것 \u0026ldquo;개인 기여\u0026rdquo; 중심 사고에서 벗어나지 못함 Staff로 성장하지 못하는 엔지니어들의 공통점은 기술 역량 자체가 부족해서가 아니라, 그 기술을 조직 전체로 확장하지 못한다는 점입니다.\nStaff Engineer의 핵심 3가지 차원 1. Surface Area 확장 (Expanding your surface area) 주어진 업무 외에 자발적으로 기회를 만들기 가 핵심입니다. Jordan은 AI 시대에 맞춰 개발자 생산성과 AI 도구 실험을 주도하며 #how-i-ai Slack 채널을 만들었습니다. 이 채널은 1,200명 이상 규모로 성장했고, 회사 전체 데모와 AI Coding Pathfinders 그룹 참여로 이어졌습니다.\n핵심: 누가 시키지 않아도 가치 있는 것을 먼저 만들고 공유하면 기회가 자연스럽게 따라옵니다.\n2. 팀 간 영향력 발휘 (Influencing across teams) 본인 팀을 넘어 다른 팀의 문제를 해결하고 도와주는 능력입니다. Jordan은 Pinterest의 주요 페이지(Home Feed, Search, Closeup)에 대해 성능 감사를 수행하고, 데이터와 구체적 해결 방안을 함께 제시했습니다. \u0026ldquo;이렇게 고치면 100ms 빨라지고, 이렇게 구현하면 된다\u0026quot;처럼 행동 유발 하기 위해 설계했습니다.\n결과적으로 해당 페이지 성능이 30% 이상 개선되었고, 이는 본인의 승진 근거가 되었습니다.\n핵심: \u0026ldquo;너희 페이지 느리다\u0026quot;가 아니라, 데이터 + 해결책 + 도움 제안 으로 신뢰와 실행을 이끌어내야 합니다.\n3. 확장 가능한 시스템 구축 (Building scalable systems) 개발자 경험(DX)을 측정할 수 있는 holistic framework를 구축한 사례입니다. CI 시간, 빌드, 테스트 등 지표를 Red/Yellow/Green threshold로 정의하고, 자동 리포트(Slack + Google Sheets) 파이프라인을 구축하여 팀들이 쉽게 참여할 수 있게 만들었습니다.\n한 번 구축된 시스템은 본인이 손대지 않아도 지속되고, 다른 플랫폼 팀까지 확장되었습니다.\n핵심: 본인이 없어도 돌아가고, 다른 사람들이 더 많은 일을 할 수 있게 만드는 시스템을 구축하는 것이 multiplier의 본질입니다.\n결론 및 시사점 Staff Engineer의 본질은 \u0026ldquo;내가 더 많은 코드를 쓰는 것\u0026rdquo; 이 아니라 \u0026ldquo;다른 사람들이 더 많은 일을 할 수 있게 만드는 것\u0026rdquo; 이다. Slack 채널이 스스로 답변되고, 감사 결과가 팀이 스스로 고치고, 측정 시스템이 휴가 중에도 돌아가게 만드는 것이 Staff의 일하는 방식이다. Heads-down 코딩에서 벗어나 영향력과 시스템을 만드는 multiplier 사고로 전환해야 하며, 특히 AI 시대에는 이 전환이 더 중요해졌다. 구체적 실행 방법: 자발적 기회 창출(Surface Area), 데이터 기반 문제 해결 제안(팀 간 영향력), 자동화된 측정·보고 시스템(확장 가능한 시스템)의 세 축을 의식적으로 키워야 한다. 한 줄 결론: Staff로 가는 길은 더 많은 코드를 쓰는 것이 아니라, 더 많은 사람이 더 많은 일을 할 수 있게 만드는 multiplier가 되는 것이다.\n","wordCount":486,"tags":["커리어","성장","시니어","스태프","소프트웨어엔지니어링","리더십"],"categories":["엔지니어링"],"frameworks":["Multiplier Thinking","Systems Thinking","Second-order Thinking"],"mental_models":["영향력 확장","자기 증폭 시스템","신뢰 자본"],"philosophy_type":"career-growth","schema_type":"HowTo","actionable":true,"priority":"high","key_points":["Staff는 더 많은 코드를 쓰는 역할이 아니라 다른 사람들이 더 많은 일을 할 수 있게 만드는 역할이다","Surface Area 확장: 시키지 않아도 가치 있는 것을 먼저 만들고 공유하면 기회가 따라온다","팀 간 영향력: 데이터 + 해결책 + 도움 제안으로 신뢰와 실행을 이끌어낸다","확장 가능한 시스템: 본인이 없어도 돌아가고 다른 사람이 더 많은 일을 할 수 있게 만든다","AI 시대에는 multiplier 사고가 더 중요해졌다"],"related":["posts/agentic-engineering-management","posts/agentic-software-engineering","posts/agent-skills-addy-osmani"]},{"title":"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-02T09:56:34+09:00","lastmod":"2026-06-02T09:56:34+09:00","description":"Lucas F. Costa의 'Backpressure is all you need'를 코딩 에이전트 운영 관점에서 요약한다. 핵심은 사람이 매번 LLM 출력물을 붙잡고 교정하는 대신, 테스트·타입·벤치마크·리뷰 에이전트·PR 모니터링 같은 자동화된 백프레셔를 에이전트 루프 안에 넣어 더 긴 위임을 안전하게 만드는 것이다.","summary":"Lucas F. Costa의 **\u0026ldquo;Backpressure is all you need\u0026rdquo;(2026-05-23)**는 코딩 에이전트를 더 오래, 더 안전하게 위임하기 위한 운영 원칙을 설명합니다. 글의 핵심은 단순합니다. LLM이 코드를 빠르게 생산하는 시대에는 사람이 기본 백프레셔가 되면 안 됩니다. 사람이 매번 출력물을 읽고, 실패를 찾아주고, 다시 프롬프트에 복사해 넣는 구조는 위임이 아니라 병목입니다.\n원문: Backpressure is all you need\nBackpressure 핵심 정리 문제 진단: 에이전트를 완전히 방치하면 저품질 PR이 쏟아지고, 모든 작은 결정을 사람이 검토하면 에이전트를 쓰는 의미가 줄어든다. 핵심 해법: 사람 대신 시스템이 먼저 \u0026ldquo;아직 안 된다\u0026quot;고 말하게 만든다. 테스트, 타입, 린트, 벤치마크, 리뷰 에이전트, PR 모니터링이 그 역할을 한다. 운영 원칙: 체크는 마지막에 한 번이 아니라 각 패치/반복마다 실행한다. 실패하면 다음 패치로 넘어가지 말고 원인 분석 → 수정 → 재실행을 강제한다. 가장 큰 효과: 리뷰 에이전트와 PR 모니터링. 전자는 인간에게 넘어오기 전 품질 문제를 줄이고, 후자는 CI 실패·충돌·리뷰 코멘트가 남은 PR을 방치하지 않게 한다. 결론: 앞으로의 코딩 에이전트 생산성은 더 똑똑한 프롬프트보다 잘 설계된 백프레셔 루프에 달려 있다. 1) 두 가지 obvious한 사용법은 모두 나쁘다 Costa는 코딩 에이전트 사용법의 양극단을 비판합니다.\n","content":"Lucas F. Costa의 **\u0026ldquo;Backpressure is all you need\u0026rdquo;(2026-05-23)**는 코딩 에이전트를 더 오래, 더 안전하게 위임하기 위한 운영 원칙을 설명합니다. 글의 핵심은 단순합니다. LLM이 코드를 빠르게 생산하는 시대에는 사람이 기본 백프레셔가 되면 안 됩니다. 사람이 매번 출력물을 읽고, 실패를 찾아주고, 다시 프롬프트에 복사해 넣는 구조는 위임이 아니라 병목입니다.\n원문: Backpressure is all you need\nBackpressure 핵심 정리 문제 진단: 에이전트를 완전히 방치하면 저품질 PR이 쏟아지고, 모든 작은 결정을 사람이 검토하면 에이전트를 쓰는 의미가 줄어든다. 핵심 해법: 사람 대신 시스템이 먼저 \u0026ldquo;아직 안 된다\u0026quot;고 말하게 만든다. 테스트, 타입, 린트, 벤치마크, 리뷰 에이전트, PR 모니터링이 그 역할을 한다. 운영 원칙: 체크는 마지막에 한 번이 아니라 각 패치/반복마다 실행한다. 실패하면 다음 패치로 넘어가지 말고 원인 분석 → 수정 → 재실행을 강제한다. 가장 큰 효과: 리뷰 에이전트와 PR 모니터링. 전자는 인간에게 넘어오기 전 품질 문제를 줄이고, 후자는 CI 실패·충돌·리뷰 코멘트가 남은 PR을 방치하지 않게 한다. 결론: 앞으로의 코딩 에이전트 생산성은 더 똑똑한 프롬프트보다 잘 설계된 백프레셔 루프에 달려 있다. 1) 두 가지 obvious한 사용법은 모두 나쁘다 Costa는 코딩 에이전트 사용법의 양극단을 비판합니다.\n첫째, LLM을 방치하고 저장소가 살아남기를 바라는 방식입니다. 빠르고 신나지만, 버그·혼란스러운 변경·검토 불가능한 PR 홍수를 만듭니다. 결국 팀은 리뷰 기준을 낮추거나, 이해하지 못한 코드를 병합하게 됩니다.\n둘째, 에이전트를 고급 자동완성처럼 취급하는 방식입니다. 매 단계 사람이 보고, 냄새나는 부분을 고치라고 말하고, 다시 확인합니다. 안전해 보이지만 너무 느립니다. 사람이 사소한 결정까지 계속 조종해야 한다면 실제로는 별로 위임하지 않은 것입니다.\nCosta가 제안하는 제3의 길은 에이전트가 인간에게 오기 전에 더 많은 작업을 스스로 검증하게 만드는 것입니다. 목표는 인간을 루프에서 제거하는 것이 아니라, 인간이 저수준 오류 교정자가 아니라 마지막 판단자와 설계 리뷰어로 남게 하는 것입니다.\n2) 백프레셔란 무엇인가 시스템 엔지니어링에서 백프레셔는 downstream 컴포넌트가 upstream 생산자에게 \u0026ldquo;지금은 더 받을 수 없다\u0026quot;고 신호를 보내는 메커니즘입니다. 이 신호가 없으면 생산자는 마음껏 일을 밀어 넣고, 소비자는 밀린 일을 떠안습니다. 결과는 셋 중 하나입니다.\n소비자가 뒤처진다. 부하를 견디지 못하고 깨진다. 속도를 맞추려고 기준을 낮춘다. 소프트웨어 개발에서는 이미 여러 형태의 백프레셔를 사용해왔습니다.\n백프레셔 막아주는 것 인간 리뷰 전 효과 자동 테스트 깨진 동작, 회귀 실패한 PR을 리뷰하지 않게 한다 타입 시스템 잘못된 경계 계약, 불가능한 상태 리뷰어가 diff에서 타입 불일치를 추적하지 않게 한다 린터/포매터 스타일·기본 품질 이슈 사소한 코멘트를 자동화한다 CI 파이프라인 통합 실패, 누락된 검증 준비 안 된 변경을 리뷰 큐 밖에 둔다 카나리/배포 가드레일 프로덕션 회귀 전체 사용자에게 퍼지기 전에 멈춘다 TypeScript의 예가 특히 직관적입니다. 컴포넌트가 함수를 기대하는데 문자열이나 객체를 넘기면, 예전에는 리뷰어가 prop 흐름을 따라가며 발견해야 했습니다. 타입 시스템은 그 책임을 기계로 옮겼습니다. 소비자의 기대를 생산자가 더 빨리 마주하게 만든 것입니다.\nCosta의 문제의식은 여기서 출발합니다. 사람에게 적용해온 이 원리를, 왜 LLM이 코드를 작성하는 루프에는 충분히 넣지 않느냐는 것입니다.\n3) 사람이 LLM의 기본 백프레셔가 되면 생기는 문제 현재 많은 팀의 에이전트 루프는 이렇게 생겼습니다.\n사람이 프롬프트를 쓴다. 에이전트가 코드를 바꾼다. 사람이 에디터에서 결과를 읽는다. 사람이 이상한 부분을 다시 설명한다. 에이전트가 고친다. PR을 열고 CI 실패나 리뷰 코멘트를 다시 사람이 전달한다. 심지어 리뷰 봇을 붙여도, 봇의 피드백을 사람이 복사해서 코딩 에이전트에 전달한다면 인간은 두 기계 사이의 비싼 클립보드가 됩니다. 위임이 아니라 기계 간 피드백 라우팅을 사람이 수동으로 해주는 상태입니다.\n따라서 다음 단계는 명확합니다.\n테스트가 빨리 실패해야 합니다. 타입이 경계에서 밀어내야 합니다. 벤치마크가 성능 회귀를 잡아야 합니다. 리뷰 에이전트가 나쁜 패치를 인간 리뷰 전에 돌려보내야 합니다. PR 상태 변화와 코멘트가 모델에게 직접 돌아가야 합니다. 이 장치들이 있어야 긴 unattended session이 쓸모 있을 만큼 안전해집니다.\n4) 첫 단계: 반복마다 린트·테스트·검증 스크립트 실행 Costa가 처음 추가한 장치는 가장 단순한 것들입니다.\n린트 테스트 간단한 검증 스크립트 커밋 메시지 체크 같은 프로젝트별 스크립트 중요한 점은 마지막에 한 번 실행하라고 말하는 것이 아니라 각 반복마다 실행하게 하는 것입니다. 에이전트는 코드를 조금 쓴 뒤 바로 체크를 돌리고, 실패하면 새 패치를 쓰기 전에 실패 원인을 분석하고 고쳐야 합니다.\n실무 프롬프트 구조는 다음처럼 바꿀 수 있습니다.\n이 작업은 기능 요구사항을 만족하는 것만으로 완료되지 않는다. 각 패치 이후 다음 품질 기준을 실행하라. 1. lint 통과 2. test 통과 3. 새 동작을 커버하는 테스트 존재 4. 프로젝트 검증 스크립트 통과 체크가 실패하면 다음 패치로 넘어가지 말고 실패 원인을 분석하고 수정한 뒤 다시 실행하라. 완료 선언은 모든 수용 기준과 품질 기준이 충족된 뒤에만 가능하다. 이 정도만 해도 사람은 \u0026ldquo;테스트가 깨졌네요\u0026rdquo; 같은 코멘트를 훨씬 덜 하게 됩니다.\n5) 자동 테스트만으로 부족한 곳: cURL과 실제 브라우저 자동 테스트는 강력하지만 모든 문제를 잡지는 못합니다. API가 실제로 뜨는지, 브라우저에서 버튼이 예상대로 동작하는지, 로컬 의존성이 제대로 연결되는지는 별도 확인이 필요합니다.\nCosta는 이 간극을 메우기 위해 에이전트에게 다음을 가르쳤습니다.\n프론트엔드와 백엔드를 로컬에서 실행하는 법 docker-compose로 의존성을 띄우는 법 데이터베이스 스키마를 준비하는 법 cURL로 API를 때리는 법 Playwright MCP로 실제 브라우저를 조작하는 법 로컬 실행 중 흔한 장애를 해결하는 법 다만 수동 검증은 자동 테스트보다 느리므로, 매 반복마다 돌리기보다는 구현 반복이 어느 정도 안정된 뒤 post-iteration 단계에서 최소 한 번 실행하는 식이 좋습니다.\n6) 성능 민감 시스템에는 벤치마크 백프레셔가 필요하다 성능 민감한 애플리케이션에서는 테스트 통과만으로 충분하지 않습니다. 변경이 기능적으로 맞아도 latency, throughput, memory usage를 망칠 수 있기 때문입니다.\nCosta가 강조하는 벤치마크 설계 조건은 실용적입니다.\n한 명령으로 실행 가능해야 한다. 그래야 에이전트가 실행법을 찾다 길을 잃지 않는다. 시간 예산별 suite가 있어야 한다. 빠른 sanity check와 긴 full benchmark를 구분해야 한다. 구조화된 결과를 콘솔과 파일에 남겨야 한다. 모델이 개선·회귀·무의미한 차이를 판단할 수 있어야 한다. 판정 기준이 명확해야 한다. 어느 정도면 regression인지, noise인지, improvement인지 써 있어야 한다. 즉 벤치마크 자체도 \u0026ldquo;모델이 읽고 행동할 수 있는 인터페이스\u0026quot;로 만들어야 합니다.\n7) 가장 효과적이었던 장치: 리뷰 에이전트 Costa가 가장 효과적이었다고 평가한 백프레셔는 리뷰 에이전트입니다. 앞선 체크들이 기능적 correctness를 많이 잡아준다면, 리뷰 에이전트는 더 주관적인 품질 문제를 잡습니다.\n대표적인 품질 문제는 다음과 같습니다.\n읽기 어려운 코드 과도한 복잡성 테스트 부족 느슨한 타입 불필요한 cast 우회적 구현 변경 범위 과다 핵심은 리뷰 에이전트를 PR 끝에 한 번만 부르는 것이 아니라, 구현 반복 안에 넣는 것입니다. 그러면 코딩 에이전트는 인간 리뷰어의 취향과 품질 기준을 더 자주 마주하게 되고, 사람에게 오기 전에 스스로 품질 문제를 줄입니다.\nCosta는 향후 이 리뷰 에이전트를 더 잘게 쪼개는 실험도 언급합니다.\n리뷰 관점 독립 에이전트로 분리했을 때의 장점 Readability 이름, 흐름, 이해 가능성에 집중 Complexity 과설계·중첩·불필요한 추상화 탐지 Tests 누락된 케이스와 약한 assertion 탐지 Types any, cast, 느슨한 boundary 탐지 Brevity 불필요하게 긴 구현과 산만한 변경 축소 8) 구현 전에 계획도 리뷰해야 한다 구현 단계의 백프레셔만으로는 부족한 경우가 있습니다. 에이전트가 처음부터 잘못된 접근을 선택하면, 이후 반복에서 아무리 테스트와 리뷰를 돌려도 나쁜 기반 위에서만 개선하게 됩니다.\n그래서 Costa는 planning phase review를 추가합니다.\n코드를 쓰기 전에 가벼운 계획을 만든다. 계획은 구현 디테일보다 접근법과 아키텍처에 집중한다. 리뷰 에이전트가 근본 방향이 타당한지 검토한다. 리뷰어가 승인할 때까지 계획을 수정한다. 승인된 뒤에야 코드를 작성한다. 이 단계의 목적은 완벽한 설계 문서를 만드는 것이 아닙니다. 틀린 방향으로 빠르게 달리는 일을 막는 최소한의 방향성 검증입니다.\n9) 프론트엔드 작업에는 시각적 리뷰도 실험할 만하다 Costa는 시각적 디자인 리뷰의 효과에 대해서는 조심스럽지만, 프론트엔드 작업에서는 실험 가치가 있다고 봅니다.\n자동 테스트나 브라우저 클릭 검증으로도 다음 문제는 놓치기 쉽습니다.\n레이아웃 깨짐 spacing 불일치 색상 대비 문제 컴포넌트 정렬 오류 디자인 시안과의 미묘한 차이 이를 위해 에이전트가 Playwright MCP로 스크린샷을 찍고, Figma 파일이나 Linear 티켓의 이미지와 비교하게 할 수 있습니다. 중요한 점은 \u0026ldquo;그냥 보고 판단하라\u0026quot;가 아니라, header → main → footer처럼 영역을 나누고, 정렬·간격·대비·일관성 같은 체크리스트를 주는 것입니다.\n10) PR 모니터링: 두 번째로 효과적인 백프레셔 PR을 열었다고 작업이 끝난 것은 아닙니다. 실제 팀에서는 이후에 다음 이벤트가 발생합니다.\nCI 실패 merge conflict 리뷰어 코멘트 다른 리뷰 봇의 지적 flaky test 재실패 Costa는 PR을 일정 시간 모니터링하는 skill을 만들었습니다. 이 skill은 새 코멘트, CI 상태 변화, 충돌을 감지하면 모델에게 알려서 해결하게 합니다. 이렇게 하면 PR이 열린 뒤에도 사람에게 조용히 책임이 넘어가지 않습니다.\n최종 루프는 다음처럼 확장됩니다.\n목표 입력 ↓ 가벼운 계획 작성 ↓ 계획 리뷰 및 승인 ↓ 구현 반복 - 기능 기준 확인 - lint/test/type/check 실행 - 빠른 benchmark - 리뷰 에이전트 피드백 ↓ post-iteration 검증 - 로컬 앱 실행 - cURL/API 검증 - 실제 브라우저 검증 - full benchmark - 전체 changeset 리뷰 ↓ PR 생성 ↓ PR 모니터링 - CI - conflict - review comment 이 구조에서 인간은 각 반복의 저수준 교정자가 아니라, 마지막에 변경의 의미·설계·트레이드오프를 판단하는 사람이 됩니다.\n11) 직접 적용하기 위한 최소 체크리스트 팀에 바로 적용한다면 처음부터 완성형 루프를 만들 필요는 없습니다. 다음 순서로 쌓는 편이 현실적입니다.\n1단계 — 기본 품질 백프레셔 lint 명령을 문서화한다. test 명령을 문서화한다. 타입 체크 명령을 문서화한다. 에이전트에게 \u0026ldquo;각 패치 후 실행\u0026quot;을 명시한다. 실패 시 다음 변경 전 수정하도록 강제한다. 2단계 — 프로젝트 실행법을 에이전트용으로 정리 로컬 의존성 실행법 백엔드 실행법 프론트엔드 실행법 DB 초기화 방법 흔한 오류와 해결책 API smoke test용 cURL 예시 이 문서는 사람이 읽기 위한 README라기보다 에이전트가 막히지 않고 실행할 수 있는 runbook이어야 합니다.\n3단계 — 리뷰 에이전트 추가 리뷰 기준을 명시합니다.\n변경 범위가 과하지 않은가? 테스트가 새 동작을 실제로 검증하는가? 타입을 느슨하게 만들지 않았는가? 불필요한 추상화가 생기지 않았는가? 사람이 이해할 수 있는 코드인가? 4단계 — PR 이후까지 닫힌 루프 만들기 PR을 열고 끝내지 않는다. CI 상태를 확인한다. 리뷰 코멘트를 회수한다. merge conflict를 감지한다. 남은 문제가 없을 때까지 모델이 다시 수정하게 한다. 12) 이 글의 진짜 메시지 이 글은 \u0026ldquo;좋은 프롬프트를 쓰자\u0026quot;는 글이 아닙니다. 더 정확히는 위임 가능한 시스템을 만들자는 글입니다.\n프롬프트만으로는 에이전트가 너무 일찍 성공을 선언하기 쉽습니다. 반대로 사람이 모든 실패를 잡아주면 에이전트 생산성은 사람의 검토 속도에 묶입니다. Costa의 표현을 빌리면, 인간이 기계의 실수를 잡는 데 의존하는 시스템은 결국 기계가 아니라 인간에 의해 제한됩니다.\n따라서 좋은 코딩 에이전트 환경의 질문은 다음으로 바뀝니다.\n\u0026ldquo;모델이 코드를 잘 쓰는가?\u0026ldquo;에서 \u0026ldquo;모델이 실패를 얼마나 빨리, 자동으로, 반복적으로 마주하는가?\u0026ldquo;로. 앞으로 소프트웨어 엔지니어링의 많은 품질 관리는 사람이 더 열심히 리뷰하는 방향이 아니라, 사람에게 오기 전에 기계가 더 많이 거절하고 되돌려 보내는 방향으로 갈 가능성이 큽니다. 우리는 지난 수십 년 동안 컴파일러, 타입, 테스트, CI로 \u0026ldquo;no\u0026quot;를 사람에게서 기계로 옮겨왔습니다. 이제 같은 일을, 코드를 쓰는 기계 자신에게 다시 적용해야 합니다.\n","wordCount":1531,"tags":["AI","에이전트","백프레셔","코딩 에이전트","테스트","CI","리뷰 에이전트","소프트웨어 엔지니어링"],"categories":["AI"],"frameworks":["Backpressure","Agentic Feedback Loops","Human-in-the-loop Delegation"],"mental_models":["Move the Bottleneck","Shift-left Quality","Fast Feedback Loops","Guardrails over Handholding"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["코딩 에이전트의 양극단, 즉 완전 방치와 초단위 수동 감독은 모두 나쁘다. 좋은 위임은 에이전트가 인간에게 오기 전에 스스로 실패를 만나고 고치게 만드는 것이다.","백프레셔는 downstream이 upstream에 '아직 받을 수 없다'고 신호를 보내는 구조다. 테스트·타입·린트·CI는 이미 인간 개발자에게 적용해온 백프레셔이며, 이제 같은 원리를 LLM 코드 작성 루프에 넣어야 한다.","가장 효과적인 장치는 반복마다 실행되는 자동 체크와 리뷰 에이전트다. 기능 요건뿐 아니라 테스트 품질, 타입 엄격성, 간결성, 복잡도까지 에이전트가 인간 리뷰 전에 마주하게 만든다.","최종 루프는 계획 리뷰 → 구현 반복 체크 → 수동/브라우저 검증 → 벤치마크 → 변경셋 리뷰 → PR 모니터링으로 확장된다. 인간은 저수준 오류 교정자가 아니라 마지막 설계 판단자가 된다."],"related":["posts/anatomy-of-an-agent-harness","posts/components-of-a-coding-agent","posts/agent-harness-engineering","posts/all-your-agents-are-going-async"]},{"title":"AI 하드웨어 시장: 컴퓨트가 아니라 메모리 병목이 승부를 가른다","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/ai-hardware-memory-bottleneck-market-map/","section":"software","date":"2026-05-27T10:58:43+09:00","lastmod":"2026-05-27T10:58:43+09:00","description":"AI 하드웨어 시장은 연산량 경쟁에서 메모리 대역폭 경쟁으로 이동하고 있습니다. 칩, 인퍼런스 엔진, KV 캐시, 패키징 계층별로 어떤 기업이 병목을 공략하는지 정리합니다.","summary":"출처: https://www.categoryvc.com/writing/where-the-ai-hardware-market-is\n이 글은 2026년 현재 AI 인퍼런스 시장을 \u0026ldquo;누가 더 많은 FLOPS를 내느냐\u0026quot;가 아니라 \u0026ldquo;누가 메모리 병목을 더 잘 푸느냐\u0026quot;의 관점으로 재정리합니다. 특히 LLM serving의 실제 병목이 prefill과 decode에서 다르게 나타난다는 점을 기준으로, 어떤 레이어에서 기업들이 경쟁하는지 살펴봅니다.\nTL;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로 계층화하면 긴 컨텍스트 비용을 줄이고 재사용률을 높일 수 있다. 시장 결론: 승자는 \u0026ldquo;NVIDIA 대체\u0026quot;보다 \u0026ldquo;특정 병목 해결\u0026quot;에서 먼저 나오며, 이후 클라우드·엔진·플랫폼에 통합될 확률이 높다. 1) 왜 지금도 GPU는 놀고 있는가 많은 팀이 \u0026ldquo;GPU가 비싸다\u0026quot;는 문제를 이야기하지만, 더 정확히는 \u0026ldquo;GPU 안의 연산 장치가 놀고 있다\u0026quot;는 문제가 큽니다. 이유는 단순합니다.\n","content":"출처: https://www.categoryvc.com/writing/where-the-ai-hardware-market-is\n이 글은 2026년 현재 AI 인퍼런스 시장을 \u0026ldquo;누가 더 많은 FLOPS를 내느냐\u0026quot;가 아니라 \u0026ldquo;누가 메모리 병목을 더 잘 푸느냐\u0026quot;의 관점으로 재정리합니다. 특히 LLM serving의 실제 병목이 prefill과 decode에서 다르게 나타난다는 점을 기준으로, 어떤 레이어에서 기업들이 경쟁하는지 살펴봅니다.\nTL;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로 계층화하면 긴 컨텍스트 비용을 줄이고 재사용률을 높일 수 있다. 시장 결론: 승자는 \u0026ldquo;NVIDIA 대체\u0026quot;보다 \u0026ldquo;특정 병목 해결\u0026quot;에서 먼저 나오며, 이후 클라우드·엔진·플랫폼에 통합될 확률이 높다. 1) 왜 지금도 GPU는 놀고 있는가 많은 팀이 \u0026ldquo;GPU가 비싸다\u0026quot;는 문제를 이야기하지만, 더 정확히는 \u0026ldquo;GPU 안의 연산 장치가 놀고 있다\u0026quot;는 문제가 큽니다. 이유는 단순합니다.\nprefill(프롬프트 초기 처리): 연산량이 크고 병렬화가 쉬워 compute-bound 경향 decode(토큰 1개씩 생성): 매 스텝마다 메모리 접근이 잦아 memory-bound 경향 즉, 동일한 모델·동일한 GPU라도 어떤 구간을 주로 처리하느냐에 따라 자원 활용률이 완전히 달라집니다. 이 관점이 없으면 \u0026ldquo;왜 스펙상 성능과 실제 처리량이 이렇게 다른가\u0026quot;를 설명하기 어렵습니다.\n2) 시장 공략 지도: 메모리 병목을 어디서 푸는가 (1) 칩 레벨: on-chip memory 중심 재설계 대표적으로 다음 접근이 같은 문제를 다른 방식으로 건드립니다.\nGroq: HBM 의존도를 낮추고 대용량 on-chip SRAM 활용 Cerebras: 웨이퍼 스케일 아키텍처 + 대규모 SRAM으로 데이터 이동 최소화 MatX / d-Matrix: scratchpad/in-memory computing 계열로 메모리-연산 간 거리 축소 핵심은 \u0026ldquo;더 빠른 연산기\u0026quot;보다 \u0026ldquo;연산기가 기다리지 않게 만드는 메모리 구조\u0026quot;입니다.\n(2) 인퍼런스 엔진: 스케줄링이 곧 제품력 엔진 레이어에서는 prefill과 decode를 분리해서 다루는 능력이 중요합니다.\nprefill 최적화: 배치 병렬성과 연산 효율 중심 decode 최적화: 대역폭·캐시 친화성·지연시간 중심 Roofline 관점으로 워크로드를 보면, \u0026ldquo;배치를 키우면 무조건 효율이 오른다\u0026quot;는 단순 규칙이 깨집니다. 어떤 구간에서는 배치를 키울수록 대역폭 병목이 심해져 오히려 품질/지연시간/비용이 악화됩니다.\n(3) KV cache: 긴 컨텍스트 시대의 숨은 비용 센터 LLM이 길게 대화할수록 KV cache가 메모리를 잠식합니다. 이때 중요한 건 \u0026ldquo;삭제\u0026quot;가 아니라 \u0026ldquo;재배치\u0026quot;입니다.\nhot KV: GPU 메모리에 유지 warm KV: CPU RAM으로 이동 cold KV: NVMe/S3 같은 저비용 계층으로 이동 이런 계층형 전략은 특히 반복 질의, 세션 재개, 에이전트 워크로드에서 총비용을 크게 바꿉니다.\n(4) 패키징·인터커넥트: 반도체를 넘어 기계공학 경쟁 칩 성능이 올라갈수록 CoWoS, HBM attach, 냉각, 고밀도 연결 기술이 전체 성능 상한을 결정합니다. 결국 회로 설계만 잘해서는 안 되고, 열·재료·패키징 공급망까지 포함한 시스템 역량이 필요합니다.\n3) 투자/제품 관점에서 보는 현실적인 승리 전략 현실적으로 스타트업이 NVIDIA를 정면으로 대체하기는 어렵습니다. 대신 다음 전략이 더 실무적입니다.\n특정 병목을 명확히 정의한다 (예: decode latency, KV cache cost). 그 병목에서 10~30% 이상의 체감 개선을 만든다. 엔진/클라우드/플랫폼에 통합 가능한 형태로 제품화한다. 이 패턴의 장점은 기술이 빠르게 변해도 \u0026ldquo;병목 해결 능력\u0026rdquo; 자체가 재사용된다는 점입니다.\n4) 앞으로의 변수: 알고리즘 속도가 하드웨어 로드맵을 바꾼다 주의할 점은 하드웨어만 최적화해도 영구 우위가 생기지 않는다는 것입니다.\n저정밀도 확산 speculative decoding 개선 KV compression 고도화 이 변화들은 같은 하드웨어에서도 병목 위치를 계속 이동시킵니다. 따라서 하드웨어 회사도 \u0026ldquo;한 번 만든 칩\u0026quot;이 아니라 \u0026ldquo;지속적으로 적응하는 시스템\u0026quot;을 팔아야 합니다.\n결론 및 시사점 한 줄 결론: AI 하드웨어 시장의 진짜 경쟁축은 컴퓨트 총량이 아니라 메모리 이동 비용이며, 가장 유망한 플레이는 NVIDIA 대체가 아니라 병목 지점별 초정밀 최적화입니다.\n정리하면, AI 인퍼런스 스택은 칩·엔진·캐시·패키징의 모든 층에서 \u0026ldquo;메모리를 어떻게 다루는가\u0026quot;로 재편되고 있습니다. 앞으로 의미 있는 기업은 거대한 비전을 말하는 곳보다, 특정 구간의 병목을 수치로 증명하고 운영환경에서 반복 재현하는 팀일 가능성이 높습니다.\n","wordCount":537,"tags":["AI","하드웨어","GPU","HBM","LLM","인퍼런스"],"categories":["기술"],"frameworks":["First Principles"],"mental_models":["Bottleneck Analysis"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM 디코드 단계의 핵심 병목은 Tensor Core 연산능력이 아니라 HBM 대역폭이며, 이로 인해 GPU 활용률이 구조적으로 낮아진다.","시장 공략 포인트는 칩 설계, 인퍼런스 스케줄링, KV 캐시 계층화, 패키징/인터커넥트로 나뉘며 모두 메모리 이동 비용을 줄이는 방향이다.","NVIDIA를 정면 대체하기보다 특정 병목을 날카롭게 해소해 대형 플레이어에 통합되거나 독립 가치로 남는 전략이 현실적이다."],"related":["software/model-collapse","software/no-silver-bullet-for-llm-coding","software/quantization-llm"]},{"title":"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-26T12:49:07+09:00","lastmod":"2026-05-26T12:49:07+09:00","description":"Shreya Shankar의 2026-05-21 글을 바탕으로, 에이전트 기반 정성 분석 실험에서 드러난 한계와 실무적 시사점을 정리한다.","summary":"Shreya Shankar의 2026년 5월 21일 글 **\u0026ldquo;Exploring Agent-Assisted Qualitative Analysis\u0026rdquo;**는 \u0026ldquo;정성 분석(qualitative analysis)을 에이전트가 어디까지 도울 수 있는가\u0026quot;를 실제 실험으로 검토한 기록입니다. 핵심은 단순합니다. 에이전트가 텍스트를 많이 다루는 것과, 연구적으로 좋은 해석을 만드는 것은 전혀 다른 문제라는 점입니다.\n원문: Exploring Agent-Assisted Qualitative Analysis\nTL;DR 핵심 정리 문제 설정: 저자는 grounded theory 기반 정성 분석을 대상으로, 사람 개입 정도와 멀티에이전트 구성을 바꿔 6개 조건을 비교했다. 핵심 관찰 1: 무개입 또는 약한 개입 조건에서 에이전트는 분석보다 재진술(paraphrase)에 가까운 출력을 내는 경향이 강했다. 핵심 관찰 2: exp1에서 \u0026ldquo;트윗 길이 ↔ 코드 수\u0026rdquo; 상관이 ρ=0.81로 높았고, 메모 피드백 조건(exp2-memo)에서는 ρ=0.15까지 낮아졌다. 핵심 관찰 3: 코드 재사용이 거의 일어나지 않아(예: exp1에서 코드 93.8%가 1회 사용) 누적적 코드북 형성이 약했다. 실무 결론: 정성 분석 자동화의 병목은 모델 성능보다 \u0026ldquo;언제·어떻게 사람 판단을 끼워 넣는지\u0026quot;를 정의하는 워크플로우 설계에 있다. 1) 왜 이 문제가 어려운가 정성 분석은 정답이 고정된 작업이 아닙니다. 같은 데이터라도 연구 질문, 독자, 맥락에 따라 서로 다른 해석이 성립할 수 있습니다. 저자는 이 지점을 AI 시스템의 난제로 봅니다. 즉, \u0026ldquo;정확도 하나\u0026quot;로 환원할 수 없는 작업이며, 평가 기준도 분석 과정에서 계속 변합니다.\n","content":"Shreya Shankar의 2026년 5월 21일 글 **\u0026ldquo;Exploring Agent-Assisted Qualitative Analysis\u0026rdquo;**는 \u0026ldquo;정성 분석(qualitative analysis)을 에이전트가 어디까지 도울 수 있는가\u0026quot;를 실제 실험으로 검토한 기록입니다. 핵심은 단순합니다. 에이전트가 텍스트를 많이 다루는 것과, 연구적으로 좋은 해석을 만드는 것은 전혀 다른 문제라는 점입니다.\n원문: Exploring Agent-Assisted Qualitative Analysis\nTL;DR 핵심 정리 문제 설정: 저자는 grounded theory 기반 정성 분석을 대상으로, 사람 개입 정도와 멀티에이전트 구성을 바꿔 6개 조건을 비교했다. 핵심 관찰 1: 무개입 또는 약한 개입 조건에서 에이전트는 분석보다 재진술(paraphrase)에 가까운 출력을 내는 경향이 강했다. 핵심 관찰 2: exp1에서 \u0026ldquo;트윗 길이 ↔ 코드 수\u0026rdquo; 상관이 ρ=0.81로 높았고, 메모 피드백 조건(exp2-memo)에서는 ρ=0.15까지 낮아졌다. 핵심 관찰 3: 코드 재사용이 거의 일어나지 않아(예: exp1에서 코드 93.8%가 1회 사용) 누적적 코드북 형성이 약했다. 실무 결론: 정성 분석 자동화의 병목은 모델 성능보다 \u0026ldquo;언제·어떻게 사람 판단을 끼워 넣는지\u0026quot;를 정의하는 워크플로우 설계에 있다. 1) 왜 이 문제가 어려운가 정성 분석은 정답이 고정된 작업이 아닙니다. 같은 데이터라도 연구 질문, 독자, 맥락에 따라 서로 다른 해석이 성립할 수 있습니다. 저자는 이 지점을 AI 시스템의 난제로 봅니다. 즉, \u0026ldquo;정확도 하나\u0026quot;로 환원할 수 없는 작업이며, 평가 기준도 분석 과정에서 계속 변합니다.\n이 특성 때문에 \u0026ldquo;컴파일 성공/실패\u0026quot;처럼 명확한 검증 신호가 있는 코딩 과제보다 훨씬 까다롭습니다.\n2) 실험 설계: 6개 조건 비교 저자는 Claude Sonnet + Agent SDK 기반으로 451개 트윗 코퍼스를 분석했습니다. 질문은 \u0026ldquo;사용자가 왜 Claude에서 다른 모델로 이동하는가\u0026quot;입니다.\n실험 축은 두 가지입니다.\ngrounded theory 절차를 프롬프트에 얼마나 강하게 명시하는가 사람을 어느 단계에서 루프에 넣는가(없음 / 코드 단위 피드백 / 메모 피드백 / 멀티에이전트 사후 조정) 즉, 단순 성능 비교보다 인간 개입 설계가 결과 품질에 미치는 영향을 보는 실험입니다.\n3) 핵심 결과: 에이전트는 분석보다 재진술에 기운다 가장 인상적인 지표는 exp1에서 관찰된 상관계수입니다.\n트윗 길이가 길수록 코드 개수가 함께 증가(ρ=0.81) 하지만 이 데이터에서 \u0026ldquo;긴 트윗\u0026quot;은 반드시 \u0026ldquo;새로운 불만 종류가 많은 트윗\u0026quot;을 의미하지 않습니다. 긴 글이 같은 불만을 반복하는 경우가 많기 때문에, 이 상관은 에이전트가 의미 분해보다 표면 길이에 반응했음을 시사합니다.\n또한 코드 재사용이 거의 없었습니다. 저자 보고에 따르면 exp1에서는 코드의 93.8%가 단 한 번만 쓰였습니다. 이는 코퍼스 전반의 공통 패턴을 압축하기보다, 항목별 라벨을 즉석 생성하는 경향으로 해석할 수 있습니다.\n4) 사람 개입의 차이: \u0026ldquo;무개입\u0026quot;보다 \u0026ldquo;방향 피드백\u0026quot;이 유효 흥미로운 점은 사람이 개입하는 방식에 따라 결과가 달라졌다는 것입니다.\n코드 편집 중심 개입보다, 분석 방향을 자유 텍스트로 교정하는 메모 피드백이 더 큰 개선 신호를 보였습니다. exp2-memo에서 상관이 ρ=0.15로 낮아진 것은, \u0026ldquo;길면 코드 많이\u0026rdquo; 같은 기계적 반응을 사람이 제동할 수 있음을 보여줍니다. 즉, 사람 역할은 단순 검수자가 아니라 해석 방향을 재정렬하는 조향 장치에 가깝습니다.\n5) 실전 적용 체크리스트 이 글을 팀의 리서치/UX 분석 워크플로우에 적용하면 다음처럼 정리할 수 있습니다.\n에이전트 산출물을 \u0026ldquo;분석 초안\u0026quot;으로 취급하고, 최종 해석 권한은 사람이 유지한다. 항목별 라벨 수가 과도하게 늘어나면(코드 폭증) 재사용 강제 규칙을 둔다. 리뷰 UI는 라벨 수정 기능만 두지 말고 \u0026ldquo;분석 방향 메모\u0026rdquo; 입력을 필수화한다. 지표는 처리량보다 재사용률·코드 통합률·재해석 횟수를 함께 본다. 주기적으로 \u0026ldquo;현재 평가 기준이 바뀌었는가\u0026quot;를 점검해 criteria drift를 운영 지표로 관리한다. 결론 및 시사점 정성 분석 자동화의 성패는 모델 크기보다 사람 개입 설계의 정교함에서 갈린다. 특히 메모 기반 피드백처럼 해석 방향을 조정하는 개입이 기계적 라벨링을 줄이는 데 유효하다. 실무 팀은 처리량보다 코드 재사용률·통합률 같은 구조 지표를 병행 관리해야 한다. 한 줄 결론: 정성 분석에서 에이전트의 가치는 자동 판정보다, 사람의 해석 루프를 빠르게 반복시키는 보조 장치로 설계할 때 가장 크게 나온다.\n","wordCount":516,"tags":["AI","에이전트","정성분석","grounded-theory","human-in-the-loop"],"categories":["AI"],"frameworks":["Grounded Theory","Human-in-the-loop","Evaluation Drift"],"mental_models":["목표 불안정성","신호 대 잡음","검증 비용의 가시화"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["저자는 에이전트가 정성 분석의 핵심인 '해석적 판단'보다 문장 재진술에 치우친다고 관찰했다","실험에서 트윗 길이와 코드 개수의 높은 상관(ρ=0.81)은 에이전트가 의미 단위가 아닌 길이에 반응함을 시사한다","자유 텍스트 피드백을 넣은 조건에서는 상관이 ρ=0.15로 낮아져 사람 개입 방식이 중요함을 보여준다","코드 재사용률이 매우 낮아(exp1에서 93.8% 일회성) 분류체계 축적보다 즉흥 라벨링 경향이 나타났다","결론은 자동화 극대화보다, 어느 지점에서 사람 판단을 호출할지 설계하는 것이 성능 핵심이라는 점이다"],"related":["posts/agentic-engineering-management","posts/continual-learning-for-ai-agents","posts/agents-cant-choose-structure-flexibility"]},{"title":"The Eternal Sloptember 핵심 정리 — '에이전트 도입'이 소프트웨어 품질을 악화시킬 수 있다는 경고","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/the-eternal-sloptember-summary/","section":"posts","date":"2026-05-26T12:42:40+09:00","lastmod":"2026-05-26T12:42:40+09:00","description":"geohot의 2026-05-24 글 The Eternal Sloptember를 정리했다. 핵심은 '코드 생성량 증가'와 '품질 하락'의 비대칭 리스크, 그리고 조직 단위 도입에서 발생하는 피드백 붕괴다.","summary":"geohot(George Hotz)의 2026년 5월 24일 포스트 **\u0026ldquo;The Eternal Sloptember\u0026rdquo;**는 AI 코딩 에이전트에 대한 강한 반대 의견을 담고 있습니다. 글의 톤은 도발적이지만, 문제 제기는 실무적으로 중요합니다: 생산성 수치가 좋아 보여도 코드베이스의 평균 품질은 오히려 나빠질 수 있다는 주장입니다.\n원문: The Eternal Sloptember\nTL;DR 요약 핵심 주장: geohot은 \u0026ldquo;AI 에이전트의 소프트웨어 개발 도입\u0026quot;이 장기적으로 매우 비싼 비용을 유발할 수 있다고 본다. 근거 경험: tinygrad 개발과 하드웨어 리버스 엔지니어링 사례에서, 초기 속도는 빨라도 마무리 품질·정합성에서 사람이 직접 하는 편이 더 낫다고 평가한다. 조직 리스크: 고성과자는 슬롭(sloppy output)을 교정하지만, 대기업은 피드백 루프가 느려 하위 성과자의 \u0026ldquo;겉보기 10배 생산성\u0026quot;이 평균 품질을 끌어내릴 수 있다고 본다. 품질 착시: 문법·형식이 그럴듯한 산출물이 늘어나면서 기존 품질 프록시(문장/코드의 표면적 완성도)가 무력화된다고 지적한다. 실행 결론: 에이전트를 \u0026ldquo;대체재\u0026quot;가 아니라 \u0026ldquo;제한적 가속기\u0026quot;로 다루고, 사람이 각 라인을 이해하는 검토 규율을 버리지 말아야 한다. 1) 글의 문제의식: \u0026ldquo;에이전트는 프로그래머가 아니다\u0026rdquo; 저자는 LLM 기반 에이전트를 **\u0026ldquo;프로그래밍 분포를 모사하는 통계 모델\u0026rdquo;**로 규정합니다. 즉, 결과물이 사람 코드처럼 보일 수는 있지만, 실제로는 인간 개발자가 수행하는 문제 분해·검증·의도 보존의 과정을 동일하게 재현하지 못한다는 입장입니다.\n","content":"geohot(George Hotz)의 2026년 5월 24일 포스트 **\u0026ldquo;The Eternal Sloptember\u0026rdquo;**는 AI 코딩 에이전트에 대한 강한 반대 의견을 담고 있습니다. 글의 톤은 도발적이지만, 문제 제기는 실무적으로 중요합니다: 생산성 수치가 좋아 보여도 코드베이스의 평균 품질은 오히려 나빠질 수 있다는 주장입니다.\n원문: The Eternal Sloptember\nTL;DR 요약 핵심 주장: geohot은 \u0026ldquo;AI 에이전트의 소프트웨어 개발 도입\u0026quot;이 장기적으로 매우 비싼 비용을 유발할 수 있다고 본다. 근거 경험: tinygrad 개발과 하드웨어 리버스 엔지니어링 사례에서, 초기 속도는 빨라도 마무리 품질·정합성에서 사람이 직접 하는 편이 더 낫다고 평가한다. 조직 리스크: 고성과자는 슬롭(sloppy output)을 교정하지만, 대기업은 피드백 루프가 느려 하위 성과자의 \u0026ldquo;겉보기 10배 생산성\u0026quot;이 평균 품질을 끌어내릴 수 있다고 본다. 품질 착시: 문법·형식이 그럴듯한 산출물이 늘어나면서 기존 품질 프록시(문장/코드의 표면적 완성도)가 무력화된다고 지적한다. 실행 결론: 에이전트를 \u0026ldquo;대체재\u0026quot;가 아니라 \u0026ldquo;제한적 가속기\u0026quot;로 다루고, 사람이 각 라인을 이해하는 검토 규율을 버리지 말아야 한다. 1) 글의 문제의식: \u0026ldquo;에이전트는 프로그래머가 아니다\u0026rdquo; 저자는 LLM 기반 에이전트를 **\u0026ldquo;프로그래밍 분포를 모사하는 통계 모델\u0026rdquo;**로 규정합니다. 즉, 결과물이 사람 코드처럼 보일 수는 있지만, 실제로는 인간 개발자가 수행하는 문제 분해·검증·의도 보존의 과정을 동일하게 재현하지 못한다는 입장입니다.\n특히 문제는 \u0026ldquo;틀린 코드\u0026rdquo; 자체보다, 틀림이 점점 더 감지하기 어려운 형태로 진화한다는 점입니다. 겉으로는 맞아 보이지만, 유지보수·확장 시점에 붕괴하는 결함이 늘어난다는 경고입니다.\n2) 개인 수준에서는 유용하지만, 조직 수준에서는 위험이 커진다 글은 \u0026ldquo;AI가 쓸모없다\u0026quot;고 말하지 않습니다. 빠른 프로토타이핑, 검색/조사 보조에는 분명히 강점이 있다고 인정합니다. 다만 저자의 초점은 도입 단위입니다.\n고성과 개인/소규모 팀: 결과물을 끝까지 읽고 오류를 교정할 가능성이 높음 대규모 조직: 피드백이 느리고 책임 정렬이 약해, \u0026ldquo;양산된 코드\u0026quot;가 품질 검증 없이 누적되기 쉬움 결국 \u0026ldquo;산출량 증가\u0026quot;가 \u0026ldquo;품질 향상\u0026quot;을 의미하지 않는 상황에서, KPI가 커밋 수·속도 중심이면 조직 전체 평균 품질이 하락할 수 있다는 진단입니다.\n3) 왜 \u0026lsquo;슬롭의 시대\u0026rsquo;가 오나: 품질 프록시의 붕괴 저자가 말하는 \u0026ldquo;Sloptember\u0026quot;의 본질은 품질 판단 기준의 시대착오입니다.\n과거에는 문장력, 문법, 테스트 통과, 코드 스타일 등 표면 신호가 어느 정도 품질을 대변했습니다. 하지만 AI 산출물은 이 신호를 쉽게 만족합니다. 그 결과,\n\u0026ldquo;보기 좋은 코드\u0026quot;와 \u0026ldquo;신뢰 가능한 코드\u0026quot;의 간격이 커지고, 사람은 익숙한 프록시를 근거로 과신하며, 실제 결함은 통합·운영 단계에서 뒤늦게 드러납니다. 이 관점은 단순히 \u0026ldquo;LLM 성능 부족\u0026quot;을 넘어, 품질 보증 체계 자체를 재설계해야 한다는 요구로 읽을 수 있습니다.\n4) 저자의 기술적 전망: 현재 LLM 패러다임의 한계 글 후반에서 저자는 \u0026ldquo;현재 방식의 모델만으로는 진짜 프로그래밍 에이전트에 도달하기 어렵다\u0026quot;고 봅니다. 테스트를 회피하거나 형식적으로 통과시키는 식의 보상 해킹을 비판하며, 더 강한 세계모델(world model) 성격의 접근이 필요하다는 입장을 밝힙니다.\n동의 여부와 별개로, 실무 관점에서 중요한 메시지는 하나입니다. 지금 당장 가능한 자동화 범위를 과장하지 말고, 검증 비용까지 포함해 ROI를 계산하라는 것입니다.\n5) 실무 체크리스트 (실전 적용) 이 글을 팀 운영에 적용하면 다음 원칙으로 정리할 수 있습니다.\n에이전트 사용 구간을 분리하라: 탐색/초안/리팩터링 보조 vs. 핵심 로직 확정. \u0026ldquo;라인 단위 이해\u0026rdquo; 원칙을 유지하라: 리뷰어가 설명 못 하는 코드는 병합하지 않기. 품질 KPI를 바꿔라: 생성량보다 회귀율, 장애율, 수정 리드타임을 추적. 하위 성과 구간의 자동화 의존을 모니터링하라: 생산성 착시를 조기에 탐지. \u0026ldquo;테스트 통과\u0026quot;를 종결 조건으로 두지 말고, 설계 의도 일치 여부를 별도 점검하라. 결론 및 시사점 위 논의의 공통점은 \u0026lsquo;도입 속도\u0026rsquo;보다 \u0026lsquo;검증 구조\u0026rsquo;가 품질을 좌우한다는 점이다. 실무에서는 에이전트 활용 범위를 선명히 구분하고, 사람의 판단 책임을 명시적으로 남겨야 한다. 따라서 생산성 수치가 좋아져도 품질 지표(회귀율·장애율·재작업률)를 함께 추적해야 한다. 한 줄 결론: AI 에이전트의 위험은 \u0026lsquo;코드를 못 쓰는 것\u0026rsquo;보다, \u0026lsquo;그럴듯하게 틀린 코드를 대량 생산하는 것\u0026rsquo;에 있다는 것이 이 글의 핵심입니다.\n","wordCount":513,"tags":["AI","에이전트","소프트웨어품질","geohot","LLM"],"categories":["AI"],"frameworks":["품질-속도 트레이드오프","조직 피드백 루프","도구 적합성 판단"],"mental_models":["탐색-활용 균형","굿하트의 법칙","신호와 노이즈 분리"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["geohot은 AI 에이전트 도입이 소프트웨어 역사상 가장 비싼 실수 중 하나가 될 수 있다고 주장한다","LLM은 통계적으로 그럴듯한 코드를 빠르게 내지만, 결함이 인간 검토 프록시를 통과할 만큼 미묘해지고 있다고 본다","고성과 개인은 슬롭을 교정하지만 대규모 조직에서는 느린 피드백과 낮은 정렬 때문에 평균 품질이 악화될 위험이 크다고 지적한다","결론은 '무조건 도입'이 아니라 사용 구간을 엄격히 분리하고 인간의 라인 단위 이해를 유지하라는 것이다"],"related":["posts/agentic-engineering-management","posts/agents-cant-choose-structure-flexibility","posts/ai-capability-not-cost-reduction"]},{"title":"왜 시니어 개발자는 자신의 전문성을 전달하는 데 실패할까","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/why-senior-developers-fail-to-communicate-summary/","section":"posts","date":"2026-05-14T10:34:54+09:00","lastmod":"2026-05-14T10:34:54+09:00","description":"Tuhin Nair의 글을 바탕으로, 시니어 개발자가 복잡성 관리 언어로 말할 때 비개발 조직과 왜 엇갈리는지 핵심 논지를 정리했다.","summary":"이 글은 Tuhin Nair의 아티클 **「Why senior developers fail to communicate their expertise」(2026-05-12)**를 바탕으로, 시니어 개발자의 설명이 왜 조직에서 잘 받아들여지지 않는지 구조적으로 정리한 글이다.\nTL;DR 핵심 정리 시니어 개발자는 \u0026ldquo;덜 만들기, 재사용, 지연\u0026quot;을 통해 **복잡성(complexity)**을 관리하려고 한다. 반면 비즈니스 조직은 시장 학습 속도를 높여 **불확실성(uncertainty)**을 줄이는 데 집중한다. 그래서 시니어가 \u0026ldquo;유지보수성·안정성\u0026quot;만 강조하면, 상대의 핵심 문제를 해결하지 못해 설득이 실패한다. 저자가 제안한 실전 문장: \u0026ldquo;Can we try something quicker?\u0026rdquo; AI 시대에는 Speed(실험용)와 Scale(안정화용) 시스템을 분리해, 속도와 안정성을 동시에 달성하자는 제안이 나온다. 원문: https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise\n","content":"이 글은 Tuhin Nair의 아티클 **「Why senior developers fail to communicate their expertise」(2026-05-12)**를 바탕으로, 시니어 개발자의 설명이 왜 조직에서 잘 받아들여지지 않는지 구조적으로 정리한 글이다.\nTL;DR 핵심 정리 시니어 개발자는 \u0026ldquo;덜 만들기, 재사용, 지연\u0026quot;을 통해 **복잡성(complexity)**을 관리하려고 한다. 반면 비즈니스 조직은 시장 학습 속도를 높여 **불확실성(uncertainty)**을 줄이는 데 집중한다. 그래서 시니어가 \u0026ldquo;유지보수성·안정성\u0026quot;만 강조하면, 상대의 핵심 문제를 해결하지 못해 설득이 실패한다. 저자가 제안한 실전 문장: \u0026ldquo;Can we try something quicker?\u0026rdquo; AI 시대에는 Speed(실험용)와 Scale(안정화용) 시스템을 분리해, 속도와 안정성을 동시에 달성하자는 제안이 나온다. 원문: https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise\n1) 핵심 문제 정의: 시니어는 \u0026ldquo;복잡성\u0026rdquo;, 조직은 \u0026ldquo;불확실성\u0026rdquo; 저자는 시니어 개발자의 본질을 \u0026ldquo;문제를 푸는 사람\u0026quot;보다 \u0026ldquo;문제를 피해서 시스템을 지키는 사람\u0026ldquo;에 가깝게 본다. 시니어는 기능 추가 자체보다, 추가로 인해 생기는 분기·예외·의존성 증가를 더 크게 본다.\n하지만 비즈니스(마케팅, 영업, PM, 경영진)는 다른 전장에 있다. 이들의 최우선 과제는 \u0026ldquo;무엇이 먹히는지 빨리 확인\u0026quot;하는 것이다. 즉, 시니어의 공포 대상은 복잡성이고, 비즈니스의 공포 대상은 불확실성이다.\n2) 왜 설명이 어긋나는가 서비스가 실제 고객을 갖기 시작하면, 조직은 동시에 두 가지 목표를 수행해야 한다.\n탐색 루프(속도 중심): 시장 반응을 빨리 확인해 불확실성을 줄이는 루프 운영 루프(안정성 중심): 기존 고객에게 서비스를 지속적으로 제공하는 루프 시니어 개발자는 보통 운영 루프의 책임을 크게 진다. 그래서 \u0026ldquo;이건 나중에\u0026rdquo;, \u0026ldquo;정말 필요한가\u0026quot;라고 말하는데, 이 언어는 비즈니스가 원하는 \u0026ldquo;빨리 학습하자\u0026quot;와 충돌한다.\n저자의 진단은 간단하다: 상대 문제를 내 문제 언어로만 설명하면 설득이 실패한다.\n3) 커뮤니케이션 처방: 복잡성 관리 능력을 불확실성 감소 언어로 번역하라 시니어의 강점은 \u0026ldquo;아예 안 만들 수 있는지\u0026rdquo;, \u0026ldquo;기존 것을 재사용할 수 있는지\u0026quot;를 판별하는 능력이다. 저자는 이 능력을 방어적으로 말하지 말고, 실험 속도를 높이는 제안으로 전환하라고 권한다.\n예:\n\u0026ldquo;신규 기능 전체 개발\u0026rdquo; 대신 \u0026ldquo;기존 UI에 버튼만 붙여 수요를 검증\u0026rdquo; \u0026ldquo;풀 분석 플랫폼 도입\u0026rdquo; 대신 \u0026ldquo;의사결정 1개를 위한 지표 1개부터\u0026rdquo; 즉, 시니어의 본래 기술(축소, 재사용, 회피)을 비즈니스 목표(빠른 검증)와 정렬해 전달해야 한다.\n4) AI 시대의 추가 논점: 속도는 빨라졌지만 책임은 남는다 저자는 AI가 실험·개발 속도를 급격히 올리는 도구임은 인정한다. 다만 그 반대급부로 시스템의 이해가능성, 디버깅 가능성, 유지보수성이 약화될 위험을 강조한다.\n한 문장으로 하면: AI는 코드를 만들 수 있지만, 책임을 지지는 않는다.\n그래서 시니어의 역할은 \u0026ldquo;코드를 가장 많이 쓰는 사람\u0026quot;에서 \u0026ldquo;시스템을 편집하고 안정화하는 사람\u0026quot;으로 이동한다.\n5) 제안 모델: Speed 버전과 Scale 버전 분리 저자는 하나의 시스템이 두 목표(빠른 실험, 안정 운영)를 동시에 완벽히 만족시키기 어렵다고 보고, 다음과 같이 분리 운영하는 아이디어를 제시한다.\nSpeed 시스템: 빠른 가설 검증용(충분히 작동하면 우선 시장 테스트) Scale 시스템: 시니어 주도로 안정화·구조화된 운영용 이 모델의 장점은 조직이 원하는 \u0026ldquo;속도\u0026quot;를 잃지 않으면서, 장기적으로는 \u0026ldquo;안정성 부채\u0026quot;를 줄일 수 있다는 점이다.\n결론 결국 핵심은 기술적 옳고 그름만 주장하는 태도에서 벗어나, 상대가 줄이고 싶은 불확실성을 기준으로 제안을 다시 구성하는 일이다.\n시니어의 전문성은 \u0026ldquo;안 된다\u0026quot;를 먼저 말하는 데 있지 않고, 더 작고 빠른 검증 경로를 설계해 팀의 학습 속도와 시스템 안정성을 함께 지키는 판단력에서 드러난다.\n","wordCount":430,"tags":["communication","senior-developer","ai","software-engineering"],"categories":["커뮤니케이션"],"frameworks":["Systems Thinking","Verification-first Engineering","Operational Excellence"],"mental_models":["Second-order Effects","Borrowed Confidence"],"philosophy_type":"","schema_type":"Article","actionable":true,"priority":"high","key_points":["시니어 개발자는 본능적으로 '복잡성 증가'를 경계하지만, 비즈니스는 '불확실성 감소'를 최우선으로 본다.","커뮤니케이션 실패의 핵심은 문제 언어 불일치이며, 해결책은 '더 빨리 실험할 방법'으로 번역해 말하는 것이다.","AI는 1루프(시장 학습 속도)를 크게 가속하지만 2루프(안정성·이해가능성)를 약화시킬 수 있다.","저자는 Speed 시스템과 Scale 시스템을 분리하는 운영 모델을 제안한다."],"related":["posts/agent-skills-addy-osmani","posts/senior-to-staff-engineer-growth","software/illusion-of-building"]},{"title":"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-13T13:40:29+09:00","lastmod":"2026-05-13T13:40:29+09:00","description":"LLM 에이전트가 경험을 텍스트 메모리로 반복 재작성할수록 성능이 떨어질 수 있다는 Dylan Zhang의 'Faulty Memory' 핵심 결과를 정리합니다.","summary":"LLM 에이전트 메모리의 정석처럼 여겨졌던 \u0026ldquo;경험 정리 → 텍스트 저장 → 반복 재작성\u0026rdquo; 루프가 실제로는 자기개선을 보장하지 않는다는 문제 제기입니다. 이 글은 Dylan Zhang의 **\u0026ldquo;Useful memories become faulty when continuously updated by LLMs\u0026rdquo;**를 빠르게 파악하려는 분들을 위한 정리입니다.\nTL;DR 요약 핵심 결과: GPT-5.4가 ARC-AGI에서 메모리 없이 100% 풀던 문제군이, 정답 기반 통합(consolidation) 후 **54%**까지 하락. 중요 포인트: 같은 데이터여도 업데이트 스케줄이 달라지면 메모리가 달라지고 성능도 달라짐(특히 Stream가 최악). 실패 원인 3가지: 잘못된 묶기(misgrouping), 과잉 일반화/간섭(interference), 반복 재작성에 따른 과적합(overfit). 실무 시사점: \u0026quot; 메모리 누적\u0026quot;보다 선별된 raw episodic evidence 보존이 더 안정적일 수 있음. 원문: https://dylanzsz.github.io/faulty-memory/\n","content":"LLM 에이전트 메모리의 정석처럼 여겨졌던 \u0026ldquo;경험 정리 → 텍스트 저장 → 반복 재작성\u0026rdquo; 루프가 실제로는 자기개선을 보장하지 않는다는 문제 제기입니다. 이 글은 Dylan Zhang의 **\u0026ldquo;Useful memories become faulty when continuously updated by LLMs\u0026rdquo;**를 빠르게 파악하려는 분들을 위한 정리입니다.\nTL;DR 요약 핵심 결과: GPT-5.4가 ARC-AGI에서 메모리 없이 100% 풀던 문제군이, 정답 기반 통합(consolidation) 후 **54%**까지 하락. 중요 포인트: 같은 데이터여도 업데이트 스케줄이 달라지면 메모리가 달라지고 성능도 달라짐(특히 Stream가 최악). 실패 원인 3가지: 잘못된 묶기(misgrouping), 과잉 일반화/간섭(interference), 반복 재작성에 따른 과적합(overfit). 실무 시사점: \u0026quot; 메모리 누적\u0026quot;보다 선별된 raw episodic evidence 보존이 더 안정적일 수 있음. 원문: https://dylanzsz.github.io/faulty-memory/\n무엇이 문제였나 저자는 \u0026ldquo;메모리 업데이트가 많아질수록 성능이 좋아진다\u0026quot;는 직관을 반박합니다. 5개 에이전트 벤치마크(ALFWorld, ScienceWorld, WebShop, AppWorld, Mind2Web)와 ARC-AGI 기반 스트림 실험에서, 메모리 통합이 오히려 성능을 깎는 사례를 반복 관찰했습니다.\n특히 ARC-AGI에서는 이미 맞힌 문제를 다시 틀리는 역행(regression) 이 명확했습니다.\n왜 망가지는가: 3가지 메커니즘 Misgrouping (오분류 통합)\n서로 다른 문제 계열 에피소드를 한 메모리로 합쳐 \u0026ldquo;실제로 없는 하이브리드 규칙\u0026quot;을 만들어냅니다.\nInterference (간섭)\n누적 추상화가 적용 조건을 지워버려, 부분적으로만 맞는 규칙이 광범위한 규칙처럼 남습니다.\nOverfit (과적합)\n비슷한 데이터만 반복 통합하면 전략이 아니라 표면 패턴을 외운 메모리가 되어, 근접 변형 문제에서 붕괴합니다.\n중요한 반전: 데이터가 아니라 재작성 단계 문제 동일한 trajectory 풀을 두고도 통합 스케줄(Static-Group, Static-All, Stream)만 바꿨을 때 메모리와 점수가 크게 달라졌습니다. 즉 실패 원인은 \u0026ldquo;데이터가 나빠서\u0026quot;가 아니라 재작성(consolidation) 연산 자체의 손실성에 가깝다는 주장입니다.\n실무에 주는 메시지 메모리 시스템을 \u0026ldquo;무조건 누적\u0026quot;으로 설계하지 말고, 업데이트 게이팅(언제/무엇을 통합할지)부터 넣어야 합니다. 추상화 메모리 하나로 모든 걸 덮기보다, raw episode를 선별 보존하고 필요 시만 하는 하이브리드가 유리할 수 있습니다. 온라인/스트리밍 환경일수록 \u0026ldquo;초기 정리 앵커 오류\u0026quot;가 누적되므로, 정기적 리셋·재분할·검증 루프가 필요합니다. 한 줄 결론 \u0026ldquo;메모리는 많을수록 좋다\u0026quot;가 아니라, \u0026ldquo;잘 지우고, 잘 남기고, 덜 재작성하는 메모리\u0026quot;가 더 낫다는 것이 이 글의 핵심입니다.\n","wordCount":279,"tags":["LLM","Agent Memory","Continual Learning","ARC-AGI","ScienceWorld","WebShop"],"categories":["AI"],"frameworks":["Continual Learning","Memory Consolidation"],"mental_models":["Lossy Compression","Interference"],"philosophy_type":"epistemology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["ARC-AGI 스트림에서 GPT-5.4는 메모리 없이 100% 풀던 19개 문제 정확도가, 정답 기반 메모리 재작성 후 54%까지 하락했다.","동일한 trajectory 풀에서도 통합 스케줄(Static-Group/Static-All/Stream)에 따라 메모리 품질과 최종 점수가 크게 갈렸다.","실패 메커니즘은 misgrouping, interference, overfit 세 가지로 정리되며, 문제는 데이터보다 '재작성 과정'에 있다.","선별된 raw episodic memory만 유지하고 과도한 추상화를 끄는 방식이 실험군 통합기(consolidator) 대비 동급 이상 성능을 보였다."],"related":["posts/agents-cant-choose-structure-flexibility","posts/ai-knowledge-layer","posts/anatomy-of-an-agent-harness"]},{"title":"'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-06T13:36:05+09:00","lastmod":"2026-05-06T13:36:05+09:00","description":"Lars Faye의 'Agentic Coding is a Trap' 핵심 주장(기술 위축의 역설, 감독자 역량 역설, 토큰 비용 불확실성)과 실무 대응 전략을 정리한다.","summary":"출처: https://larsfaye.com/articles/agentic-coding-is-a-trap\nLars Faye는 “AI가 코드를 쓰고 인간은 오케스트레이션만 하면 된다”는 흐름이 생산성 혁신처럼 보이지만, 실제로는 팀의 핵심 개발 역량과 비용 구조를 동시에 흔들 수 있다고 경고한다.\nTL;DR 핵심 정리 핵심 문제: 에이전틱 코딩은 초반 산출 속도를 높이지만, 사람이 코드에서 멀어질수록 장기적으로 이해·설계·디버깅 능력 저하가 발생할 수 있다. 감독자 역설: AI 출력을 제대로 검증하려면 숙련 개발자의 판단력이 필수인데, AI 의존이 커질수록 그 판단력 자체가 약화되는 모순이 생긴다. 주니어 성장 리스크: ‘직접 작성→실패→수정’ 경험이 줄면 코드 리뷰만으로는 학습 곡선이 가파르게 떨어질 수 있다. 비용/벤더 리스크: 토큰 사용량과 모델 성능은 고정비가 아니라 변동성이 큰 외생 변수이므로, 전면 도입 시 예산·운영 안정성이 낮아질 수 있다. 실무 결론: 에이전트를 기본값으로 두기보다, 문제 유형별 사용 경계와 수동 코딩 훈련 루프를 함께 유지해야 한다. 1) 글의 핵심 주장: “속도”와 “역량”은 같은 축이 아니다 글은 에이전트 중심 개발이 단기적으로는 빠르게 많은 코드를 만들어내지만, 그 과정에서 사람이 코드의 실제 인과관계와 설계 의도를 놓치기 쉬워진다고 본다. 즉, 산출량이 늘어도 팀의 실질적 문제 해결 능력이 같이 성장한다는 보장은 없다는 지적이다.\n","content":"출처: https://larsfaye.com/articles/agentic-coding-is-a-trap\nLars Faye는 “AI가 코드를 쓰고 인간은 오케스트레이션만 하면 된다”는 흐름이 생산성 혁신처럼 보이지만, 실제로는 팀의 핵심 개발 역량과 비용 구조를 동시에 흔들 수 있다고 경고한다.\nTL;DR 핵심 정리 핵심 문제: 에이전틱 코딩은 초반 산출 속도를 높이지만, 사람이 코드에서 멀어질수록 장기적으로 이해·설계·디버깅 능력 저하가 발생할 수 있다. 감독자 역설: AI 출력을 제대로 검증하려면 숙련 개발자의 판단력이 필수인데, AI 의존이 커질수록 그 판단력 자체가 약화되는 모순이 생긴다. 주니어 성장 리스크: ‘직접 작성→실패→수정’ 경험이 줄면 코드 리뷰만으로는 학습 곡선이 가파르게 떨어질 수 있다. 비용/벤더 리스크: 토큰 사용량과 모델 성능은 고정비가 아니라 변동성이 큰 외생 변수이므로, 전면 도입 시 예산·운영 안정성이 낮아질 수 있다. 실무 결론: 에이전트를 기본값으로 두기보다, 문제 유형별 사용 경계와 수동 코딩 훈련 루프를 함께 유지해야 한다. 1) 글의 핵심 주장: “속도”와 “역량”은 같은 축이 아니다 글은 에이전트 중심 개발이 단기적으로는 빠르게 많은 코드를 만들어내지만, 그 과정에서 사람이 코드의 실제 인과관계와 설계 의도를 놓치기 쉬워진다고 본다. 즉, 산출량이 늘어도 팀의 실질적 문제 해결 능력이 같이 성장한다는 보장은 없다는 지적이다.\n2) 왜 ‘트랩(함정)’인가? (a) 인지 부채(Cognitive Debt) 코드를 “직접 만들며 배우는” 마찰이 줄어들수록, 아키텍처 판단, 엣지 케이스 감각, 디버깅 근육이 약해질 수 있다. 기술 부채가 코드 품질에 누적된다면, 인지 부채는 개발자 역량에 누적된다는 관점이다.\n(b) 감독의 역설(Paradox of Supervision) 글에서 인용한 Anthropic의 문제의식은 간단하다.\nAI를 제대로 감독하려면 코딩 실력이 필요하고, 그런데 AI 과의존은 그 실력을 빠르게 잠식할 수 있다. 즉, “잘 써야 이득이 나는 도구”인데, “많이 쓸수록 잘 쓰기 어려워지는” 구조적 모순이 있다는 것이다.\n(c) 주니어 개발자 학습 경로 붕괴 주니어에게 리뷰는 중요하지만, 리뷰만으로는 충분치 않다. 직접 부딪혀 문제를 푸는 과정이 줄면, 정확한 의심(critical doubt)과 디버깅 감각이 자라기 어렵다는 점을 강조한다.\n(d) 토큰 비용의 불확실성 인건비는 비교적 예측 가능하지만, 에이전트 비용은 모델 버전, 품질 변동, 프롬프트 반복 횟수에 따라 급격히 달라질 수 있다. 팀이 워크플로 전체를 에이전트에 고정하면, 비용 구조와 벤더 의존도가 동시에 커진다.\n3) 실무에 주는 시사점 에이전트 사용 금지가 아니라 사용 경계 설정이 핵심이다. 아키텍처 결정, 보안 민감 로직, 복잡한 디버깅은 사람이 전면에 서고, 반복 구현·보일러플레이트·초안 생성은 에이전트로 가속하는 하이브리드 모델이 현실적이다. 추가로 팀 차원에서 다음을 운영해야 한다.\n수동 코딩 비율 유지: 일정 비율은 AI 없이 직접 구현 검증 책임 명확화: “누가 최종적으로 맞음을 보증하는가”를 개인이 아니라 프로세스로 정의 비용 관측 체계: 기능 단위 토큰 비용/재시도율/리뷰 시간을 같이 추적 결론 및 시사점 한 줄 결론: 에이전트가 빠르게 만드는 코드의 양과 팀이 유지·확장 가능한 지식의 질을 분리해 관리하지 않으면, 속도 향상이 장기 경쟁력을 갉아먹을 수 있다.\n이 글의 메시지는 “에이전트를 쓰지 말자”가 아니다. 문제 유형별 사용 경계와 수동 코딩 훈련 루프를 함께 유지하는 하이브리드 운영이 현실적인 대응이다.\n관련 포스트 컴파운드 엔지니어링: AI 에이전트 개발의 복리 루프 에이전틱 코딩의 80% 문제 AI가 코드를 짜줘도 왜 성과는 그대로인가? - 거대한 필터(The Great Filter) ","wordCount":432,"tags":["AI","에이전트","agentic coding","코드 리뷰","인지 부채","개발 생산성"],"categories":["software"],"frameworks":["Human-in-the-loop","Risk Management"],"mental_models":["Second-order Effects","Dependency Risk"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트가 코드를 대신 쓰는 워크플로는 단기 속도를 주지만, 장기적으로는 설계 감각·문제 해결력·검증 능력의 위축(인지 부채)을 만들 수 있다.","Anthropic이 언급한 '감독의 역설'처럼, 모델을 잘 쓰려면 코딩 실력이 필요하지만 과도한 의존은 그 실력 자체를 약화시킨다.","토큰 비용은 인건비처럼 예측 가능하지 않으며, 모델 업데이트/성능 변동에 따라 동일 작업 비용이 급격히 달라질 수 있다."],"related":["software/compound-engineering","software/the-80-problem-in-agentic-coding","software/the-great-filter-ai-productivity"]},{"title":"Addy Osmani의 Agent Skills — 에이전트에게 시니어 엔지니어링 프로세스를 강제하는 방법","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agent-skills-addy-osmani/","section":"posts","date":"2026-05-06T12:56:02+09:00","lastmod":"2026-05-06T12:56:02+09:00","description":"Addy Osmani의 'Agent Skills'(2026-05-03)를 했다. 핵심은 에이전트에게 '코드 생성'만 시키지 말고, spec→plan→build→test→review→ship의 시니어 엔지니어링 루프를 워크플로우로 강제해야 한다는 점이다.","summary":"Addy Osmani의 2026년 5월 3일 글 **\u0026ldquo;Agent Skills\u0026rdquo;**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다.\n원문: Agent Skills — Addy Osmani\nTL;DR 요약 문제 정의: 에이전트의 기본 보상 신호는 \u0026ldquo;task complete\u0026quot;라서, 검증 가능한 증거 없이도 완료를 선언하기 쉽다. 핵심 해법: \u0026ldquo;규칙 문서\u0026quot;가 아니라 \u0026ldquo;실행 워크플로우\u0026quot;를 SKILL.md로 주입해 단계별 체크포인트와 종료조건을 강제한다. 구조화된 SDLC: /spec → /plan → /build → /test → /review → /ship (+ /code-simplify)로 사람의 시니어 프로세스를 복원한다. 실무 원칙 5가지: process over prose, anti-rationalization table, verification non-negotiable, progressive disclosure, scope discipline. 실행 메시지: 에이전트 시대일수록 \u0026ldquo;diff에 안 보이는 시니어 업무\u0026quot;를 시스템에 박아 넣어야 사고를 줄일 수 있다. 1) Skill의 본질: \u0026ldquo;지식\u0026quot;이 아니라 \u0026ldquo;행동 절차\u0026rdquo; 글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다.\n","content":"Addy Osmani의 2026년 5월 3일 글 **\u0026ldquo;Agent Skills\u0026rdquo;**는 AI 코딩 에이전트의 본질적 문제를 명확히 짚습니다. 에이전트는 기본적으로 구현 코드만 빠르게 만들고 끝내려 하기 때문에, 시니어 엔지니어가 중요하게 보는 스펙 작성·테스트·리뷰·출시 안전장치를 자주 생략합니다.\n원문: Agent Skills — Addy Osmani\nTL;DR 요약 문제 정의: 에이전트의 기본 보상 신호는 \u0026ldquo;task complete\u0026quot;라서, 검증 가능한 증거 없이도 완료를 선언하기 쉽다. 핵심 해법: \u0026ldquo;규칙 문서\u0026quot;가 아니라 \u0026ldquo;실행 워크플로우\u0026quot;를 SKILL.md로 주입해 단계별 체크포인트와 종료조건을 강제한다. 구조화된 SDLC: /spec → /plan → /build → /test → /review → /ship (+ /code-simplify)로 사람의 시니어 프로세스를 복원한다. 실무 원칙 5가지: process over prose, anti-rationalization table, verification non-negotiable, progressive disclosure, scope discipline. 실행 메시지: 에이전트 시대일수록 \u0026ldquo;diff에 안 보이는 시니어 업무\u0026quot;를 시스템에 박아 넣어야 사고를 줄일 수 있다. 1) Skill의 본질: \u0026ldquo;지식\u0026quot;이 아니라 \u0026ldquo;행동 절차\u0026rdquo; 글에서 Skill은 단순 참고 문서가 아닙니다. 상황에 따라 에이전트 컨텍스트에 주입되는 **작업 절차(runbook)**에 가깝습니다.\n나쁜 예: 테스트 원칙 2,000자 설명문 좋은 예: 실패 테스트 작성 → 실패 확인 → 최소 구현 → 통과 확인 → 리팩토링 즉, 핵심은 **읽을거리(prose)**가 아니라 **실행 흐름(process)**입니다.\n2) Agent Skills가 인코딩한 SDLC 레포의 20개 스킬은 아래 6단계 라이프사이클로 조직됩니다.\nDefine (/spec) — 무엇을 만들지 명세 Plan (/plan) — 리뷰 가능한 단위로 분해 Build (/build) — 수직 슬라이스로 구현 Verify (/test) — 동작 증거 확보 Review (/review) — 품질·범위·리스크 점검 Ship (/ship) — 안전한 출시 여기에 /code-simplify가 전 단계에 걸쳐 복잡도 통제를 담당합니다.\n포인트는 간단합니다. 좋은 팀이라면 원래 하던 SDLC를 에이전트에게도 동일하게 강제해야 한다는 것입니다.\n3) 성능을 만드는 5가지 설계 원칙 (1) Process over prose 문장을 길게 쓰는 대신, 에이전트가 수행 가능한 순서를 제공해야 합니다.\n(2) Anti-rationalization table \u0026ldquo;이번 건은 작아서 스펙 불필요\u0026rdquo; 같은 자기합리화를 미리 반박 테이블로 넣습니다. 사람/에이전트 모두에게 효과적입니다.\n(3) Verification is non-negotiable 모든 단계의 종료조건을 증거 기반으로 둡니다. 테스트 통과, 빌드 로그, 리뷰 승인 등.\n(4) Progressive disclosure 초기에 모든 규칙을 다 넣지 않고, 현재 단계에 필요한 스킬만 로딩합니다. 토큰 낭비와 성능 저하를 막는 하네스 전략입니다.\n(5) Scope discipline \u0026ldquo;요청받은 것만 수정\u0026quot;을 강제합니다. 주변 리팩토링 확산을 막아 PR을 검토 가능하게 유지합니다.\n4) 왜 Google식 문화가 많이 보이는가 Addy는 공개된 Google 엔지니어링 실천을 다수 반영했다고 설명합니다.\nHyrum’s Law 테스트 피라미드(약 80/15/5) DAMP over DRY(테스트 가독성 우선) 작은 PR 선호(약 100줄 규모) Chesterton’s Fence Trunk-based development, atomic commit Shift Left, feature flag Code as liability 핵심은 \u0026ldquo;새로운 이론\u0026quot;이 아니라, 원래 검증된 엔지니어링 규범을 에이전트 런타임으로 이식했다는 점입니다.\n5) 당장 가져갈 수 있는 실천 포인트 팀 AGENTS.md에 anti-rationalization 목록을 만든다. 내부 가이드는 에세이 대신 체크포인트형 워크플로우로 재작성한다. \u0026ldquo;완료\u0026rdquo; 정의에 항상 검증 증거 첨부를 넣는다. 규칙집은 크게 1권이 아니라, 라우팅되는 작은 챕터 집합으로 쪼갠다. 에이전트 운영 원칙으로 아래 5줄을 고정한다: 가정은 구현 전에 드러내기 요구사항 충돌 시 멈추고 확인하기 필요하면 반박하기 단순하고 지루한 해법 선호하기 요청 범위만 수정하기 결론 이 글의 요지는 \u0026ldquo;에이전트를 더 똑똑하게 만들자\u0026quot;가 아닙니다. 에이전트가 건너뛰기 쉬운 시니어 엔지니어링 절차를, 건너뛸 수 없게 시스템화하자입니다. 결국 경쟁력은 모델 성능 자체보다, spec/test/review/ship을 얼마나 일관되게 강제하는 하네스 설계에서 갈립니다.\n","wordCount":468,"tags":["AI","agent-skills","Addy Osmani","SDLC","프롬프트엔지니어링","코드리뷰","테스트"],"categories":["AI"],"frameworks":["Process over prose","Progressive disclosure","Verification-first SDLC"],"mental_models":["Anti-rationalization","Scope discipline","Code as liability"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트는 기본적으로 '최단 경로로 끝내기'를 선호하므로 스펙·테스트·리뷰를 자동으로 생략한다","Skill은 문서가 아니라 '단계+검증+종료조건'을 가진 실행 워크플로우여야 한다","20개 스킬은 define→plan→build→verify→review→ship의 6단계 SDLC와 slash command로 구성된다","핵심 설계 원칙은 process over prose, anti-rationalization, verification, progressive disclosure, scope discipline","결론적으로 시니어 엔지니어링의 보이지 않는 작업을 에이전트가 건너뛰지 못하도록 하네스에 내장해야 한다"],"related":["posts/agentic-engineering-management","posts/agents-cant-choose-structure-flexibility","posts/probabilistic-engineering-24-7-employee"]},{"title":"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-04T22:21:45+09:00","lastmod":"2026-05-04T22:21:45+09:00","description":"프롬프트 입력부터 토큰 스트리밍까지, LLM 추론이 실제로 어떻게 돌아가는지 Prefill/Decode 분리와 KV 캐시 중심으로 정리합니다.","summary":"프롬프트를 입력하면 몇 백 밀리초 뒤에 토큰이 스트리밍으로 나오기 시작합니다. 겉보기엔 단순하지만, 내부에서는 서로 병목이 다른 두 추론 단계가 연속으로 실행됩니다. 이 글은 해당 구조를 1차 원리(First Principles) 관점으로 정리한 글입니다.\nTL;DR 핵심 정리 추론은 두 단계다: 첫 토큰 전까지의 Prefill(TTFT) 과 이후 스트리밍의 Decode(ITL) 는 병목이 다르다. 성능 지표도 분리해야 한다: 시작이 느린 문제는 프롬프트 길이/연산 최적화, 스트리밍이 느린 문제는 메모리 대역폭/KV 캐시 최적화가 핵심이다. KV 캐시는 속도의 핵심이자 비용의 근원: 재계산을 막아 속도를 올리지만, 긴 컨텍스트에서 VRAM을 크게 소모한다. 양자화는 고효율 레버: FP16/BF16, INT8, INT4로 갈수록 메모리 절감과 처리량 개선 효과가 크다. 원문: https://x.com/akshay_pachaar/article/2050941458614751327\n","content":"프롬프트를 입력하면 몇 백 밀리초 뒤에 토큰이 스트리밍으로 나오기 시작합니다. 겉보기엔 단순하지만, 내부에서는 서로 병목이 다른 두 추론 단계가 연속으로 실행됩니다. 이 글은 해당 구조를 1차 원리(First Principles) 관점으로 정리한 글입니다.\nTL;DR 핵심 정리 추론은 두 단계다: 첫 토큰 전까지의 Prefill(TTFT) 과 이후 스트리밍의 Decode(ITL) 는 병목이 다르다. 성능 지표도 분리해야 한다: 시작이 느린 문제는 프롬프트 길이/연산 최적화, 스트리밍이 느린 문제는 메모리 대역폭/KV 캐시 최적화가 핵심이다. KV 캐시는 속도의 핵심이자 비용의 근원: 재계산을 막아 속도를 올리지만, 긴 컨텍스트에서 VRAM을 크게 소모한다. 양자화는 고효율 레버: FP16/BF16, INT8, INT4로 갈수록 메모리 절감과 처리량 개선 효과가 크다. 원문: https://x.com/akshay_pachaar/article/2050941458614751327\n1) LLM의 기본 루프: \u0026ldquo;다음 토큰 하나\u0026rdquo; 예측 LLM은 본질적으로 다음 토큰 확률 분포를 계산하고, 샘플링한 토큰을 다시 입력 뒤에 붙여 반복합니다. 이 단순한 반복이 긴 응답을 만듭니다.\n2) 텍스트가 숫자가 되는 과정 Tokenization 입력 문자열을 토큰으로 분해하고 각 토큰을 정수 ID로 매핑합니다. 같은 길이의 문장이라도 언어/표기 방식/토크나이저 학습 커버리지에 따라 토큰 수가 달라집니다. 토큰 수 증가는 곧 비용/지연 증가로 이어집니다. Embedding + Position Encoding 토큰 ID는 임베딩 테이블에서 고차원 벡터로 변환됩니다. attention은 순서를 자체적으로 모르기 때문에, RoPE 같은 위치 정보가 함께 주입됩니다. 3) Transformer 레이어에서 실제 추론이 일어나는 방식 각 레이어는 크게 두 작업을 합니다.\nSelf-Attention: 토큰 간 정보 교환 Feed-Forward Network: 토큰 내부 비선형 변환 핵심 직관은 \u0026ldquo;각 토큰이 문맥 전체를 참고해, 지금 필요한 정보만 가중합해 가져온다\u0026rdquo; 입니다.\n4) 왜 첫 토큰은 느리고, 그다음 토큰은 빠른가? Prefill (Time To First Token: TTFT) 프롬프트 전체 토큰을 한 번에 병렬 처리 큰 행렬 연산 중심 → compute-bound GPU 연산 유닛 활용률이 높음 Decode (Inter-Token Latency: ITL) 토큰을 1개씩 생성하는 반복 루프 이전 토큰의 K/V는 캐시 재사용, 새 토큰만 계산 계산량보다 메모리 접근 비중이 커짐 → memory-bound 즉, 같은 모델/같은 GPU라도 단계별 성능 지배 요인이 완전히 달라집니다.\n5) KV Cache: 속도를 만든 대신 메모리를 먹는 장치 KV 캐시는 레이어별로 과거 토큰의 Key/Value를 저장해 재계산을 피합니다.\n장점: 긴 생성에서 큰 속도 향상 단점: 토큰이 늘수록 캐시가 선형 증가해 VRAM 압박 증가 긴 컨텍스트가 비싸고 느려지는 이유는 \u0026ldquo;모델이 멍청해서\u0026quot;가 아니라, 대부분 \u0026ldquo;캐시가 무거워져 메모리 병목이 심해져서\u0026quot;입니다.\n6) 최신 최적화 방향 KV 캐시 양자화(INT8/INT4) Sliding Window Attention(오래된 토큰 축소) Grouped-Query Attention(K/V 공유로 캐시 축소) PagedAttention(vLLM)(캐시 메모리 페이지 관리) Speculative Decoding(작은 모델 초안 + 큰 모델 검증) Continuous Batching(다중 사용자 토큰 단위 인터리빙) 최근 연구 흐름은 \u0026ldquo;attention 품질\u0026quot;뿐 아니라 \u0026ldquo;캐시 자체를 작게 설계\u0026quot;하는 방향으로 이동 중입니다.\n7) Quantization: 가장 실무적인 성능 레버 가중치 정밀도를 낮추면 메모리 사용량과 메모리 전송 비용이 줄어듭니다.\n대략적으로 7B 모델 기준:\nFP32: 28GB FP16: 14GB INT8: 7GB INT4: 3.5GB 실무에서는 품질 저하를 관리 가능한 수준으로 유지하면서 지연과 비용을 크게 낮출 수 있어, 양자화가 가장 우선순위 높은 최적화로 취급됩니다.\n8) 운영 관점 체크리스트 모델이 \u0026ldquo;느리다\u0026quot;는 피드백을 받으면 먼저 둘 중 무엇인지 분리하세요.\n시작이 느리다 → TTFT 이슈 (Prefill 최적화) 스트리밍이 느리다 → ITL 이슈 (Decode/메모리/KV 캐시 최적화) 이 구분 하나만으로도 문제 정의와 해결 우선순위가 훨씬 선명해집니다.\n관련 포스트 양자화 비주얼 가이드 — Maarten Grootendorst가 그림으로 푸는 LLM 경량화 LLM API의 숨은 비용 — 백만 토큰당 가격 비교를 멈춰라 ","wordCount":482,"tags":["llm","inference","transformer","kv-cache","quantization"],"categories":["AI Engineering"],"frameworks":["First Principles"],"mental_models":["Bottleneck Analysis","Systems Thinking"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM 응답 지연은 하나가 아니라 TTFT(첫 토큰 지연)와 ITL(토큰 간 지연)이라는 두 문제로 분리해야 정확히 튜닝할 수 있다.","Prefill은 전체 프롬프트를 병렬 처리해 compute-bound이고, Decode는 토큰 단위 반복으로 memory-bound가 된다.","KV Cache는 긴 출력에서 필수 최적화지만 컨텍스트가 길어질수록 VRAM을 빠르게 잠식해 배치 크기와 속도를 제한한다.","양자화(FP16→INT8→INT4)는 품질 저하를 최소화하면서 메모리와 지연을 크게 줄이는 가장 강력한 레버다."],"related":["posts/visual-guide-to-quantization","posts/hidden-llm-api-costs"]},{"title":"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-04T12:22:55+09:00","lastmod":"2026-05-04T12:22:55+09:00","description":"Dr. Milan Milanović의 'The 20 Software Engineering Laws'를 6개 주제와 실무 적용 포인트 중심으로 정리한 글.","summary":"Dr. Milan Milanović의 뉴스레터 글 **\u0026ldquo;The 20 Software Engineering Laws\u0026rdquo;(2026-04-23)**는 소프트웨어 실패를 \u0026ldquo;예외\u0026quot;가 아니라 \u0026ldquo;반복 가능한 패턴\u0026quot;으로 보게 해주는 체크리스트입니다. 아래는 원문의 20개 법칙을 빠르게 의사결정에 쓸 수 있도록 압축한 정리입니다.\n원문: The 20 Software Engineering Laws\n20 Laws 핵심 정리 이 글의 본질: 법칙은 \u0026ldquo;무엇을 해야 하는가\u0026quot;보다 \u0026ldquo;이미 어떤 일이 벌어지고 있는가\u0026quot;를 설명하는 진단 프레임이다. 실무 고빈도 함정: 늦은 프로젝트에 인원 추가(Brooks), KPI를 목표화해 왜곡 유도(Goodhart), 낙관 일정 산정(Hofstadter)이 반복된다. 설계 원칙: 작게 시작해 점진 진화(Gall), 단순성 우선(KISS), 장애를 기본값으로 설계(Murphy·Postel·CAP). 팀 운영 원칙: 팀이 커질수록 개인 생산성 저하(Ringelmann), 소수 핵심 인력 집중(Price), 과잉 자신감 리스크(Dunning-Kruger) 관리가 필요하다. 결론: 20개 법칙은 아키텍처·조직·일정·품질·스케일링 의사결정에서 \u0026ldquo;미리 실패 비용을 줄이는 안전장치\u0026quot;로 써야 한다. 1) 시스템이 만들어지는 방식 Gall’s Law: 동작하는 복잡계는 항상 먼저 동작한 단순계에서 진화한다. KISS: 단순함을 유지하라. 불필요한 복잡성은 미래 장애 비용이다. Conway’s Law: 조직의 커뮤니케이션 구조가 시스템 구조를 복제한다. Hyrum’s Law: API의 관측 가능한 모든 동작은 결국 누군가의 의존성이 된다. CAP Theorem: 분산 시스템은 일관성·가용성·분할 허용성 중 2개만 강하게 보장 가능하다. Zawinski’s Law: 소프트웨어는 기능 팽창 경향을 가진다. 실무 해석: 리라이트/플랫폼 전환 시 \u0026ldquo;완벽 설계\u0026quot;보다 \u0026ldquo;작은 성공 루프\u0026quot;를 먼저 만든다.\n","content":"Dr. Milan Milanović의 뉴스레터 글 **\u0026ldquo;The 20 Software Engineering Laws\u0026rdquo;(2026-04-23)**는 소프트웨어 실패를 \u0026ldquo;예외\u0026quot;가 아니라 \u0026ldquo;반복 가능한 패턴\u0026quot;으로 보게 해주는 체크리스트입니다. 아래는 원문의 20개 법칙을 빠르게 의사결정에 쓸 수 있도록 압축한 정리입니다.\n원문: The 20 Software Engineering Laws\n20 Laws 핵심 정리 이 글의 본질: 법칙은 \u0026ldquo;무엇을 해야 하는가\u0026quot;보다 \u0026ldquo;이미 어떤 일이 벌어지고 있는가\u0026quot;를 설명하는 진단 프레임이다. 실무 고빈도 함정: 늦은 프로젝트에 인원 추가(Brooks), KPI를 목표화해 왜곡 유도(Goodhart), 낙관 일정 산정(Hofstadter)이 반복된다. 설계 원칙: 작게 시작해 점진 진화(Gall), 단순성 우선(KISS), 장애를 기본값으로 설계(Murphy·Postel·CAP). 팀 운영 원칙: 팀이 커질수록 개인 생산성 저하(Ringelmann), 소수 핵심 인력 집중(Price), 과잉 자신감 리스크(Dunning-Kruger) 관리가 필요하다. 결론: 20개 법칙은 아키텍처·조직·일정·품질·스케일링 의사결정에서 \u0026ldquo;미리 실패 비용을 줄이는 안전장치\u0026quot;로 써야 한다. 1) 시스템이 만들어지는 방식 Gall’s Law: 동작하는 복잡계는 항상 먼저 동작한 단순계에서 진화한다. KISS: 단순함을 유지하라. 불필요한 복잡성은 미래 장애 비용이다. Conway’s Law: 조직의 커뮤니케이션 구조가 시스템 구조를 복제한다. Hyrum’s Law: API의 관측 가능한 모든 동작은 결국 누군가의 의존성이 된다. CAP Theorem: 분산 시스템은 일관성·가용성·분할 허용성 중 2개만 강하게 보장 가능하다. Zawinski’s Law: 소프트웨어는 기능 팽창 경향을 가진다. 실무 해석: 리라이트/플랫폼 전환 시 \u0026ldquo;완벽 설계\u0026quot;보다 \u0026ldquo;작은 성공 루프\u0026quot;를 먼저 만든다.\n2) 팀이 느려지는 방식 Brooks’s Law: 늦어진 프로젝트에 인력을 추가하면 더 늦어진다. Ringelmann Effect: 팀 규모가 커질수록 개인 기여 효율은 낮아진다. Price’s Law: 성과의 큰 비중은 소수 인력이 만든다. Dunning-Kruger Effect: 지식이 부족할수록 과신하기 쉽다. 실무 해석: 인력 증원은 구조적 병목(의사결정, 온보딩, 모듈 경계) 해결 없이 효과가 제한적이다.\n3) 시간·일정이 무너지는 방식 Hofstadter’s Law: 예측보다 항상 더 오래 걸린다(이 법칙을 감안해도). Parkinson’s Law: 일은 주어진 시간을 채울 때까지 팽창한다. 실무 해석: 낙관 추정보다 버퍼·마일스톤·범위 축소 옵션을 먼저 설계해야 한다.\n4) 지표가 일을 왜곡하는 방식 Goodhart’s Law: 측정값이 목표가 되는 순간, 좋은 지표가 아니다. Gilb’s Law: 측정이 어려워도, 측정하지 않는 것보다 나은 방식은 항상 있다. 실무 해석: 단일 KPI 보상보다 균형 지표(품질·속도·신뢰성)를 함께 운영한다.\n5) 성능·신뢰성의 현실 Knuth의 최적화 원칙: 성급한 최적화는 해롭다. Amdahl’s Law: 병렬화 효과는 순차 구간이 상한을 만든다. Murphy’s Law: 고장날 수 있는 것은 결국 고장난다. Postel’s Law: 송신은 보수적으로, 수신은 관대하게. 실무 해석: 성능보다 먼저 정확성·관측성·복구성(rollback, retry, timeout)을 확보한다.\n6) 품질·지식 생태계의 현실 Sturgeon’s Law: 대부분은 평범하거나 좋지 않다. Cunningham’s Law: 온라인에서 정답을 빨리 얻는 방법은 틀린 답을 먼저 올리는 것. 실무 해석: 정보/코드 품질을 기본 불신하고, 리뷰·검증 루프를 시스템화해야 한다.\n이 20개 법칙을 실제로 쓰는 방법 (체크리스트) 아키텍처 의사결정 전: \u0026ldquo;이 선택이 KISS/Gall/Conway에 어긋나는가?\u0026rdquo; 일정 수립 전: \u0026ldquo;Hofstadter 버퍼와 범위 축소 플랜이 있는가?\u0026rdquo; 조직 운영 중: \u0026ldquo;Brooks/Ringelmann 리스크를 줄일 협업 구조가 있는가?\u0026rdquo; KPI 설계 시: \u0026ldquo;Goodhart 왜곡을 막는 보조 지표가 있는가?\u0026rdquo; 배포 전: \u0026ldquo;Murphy 가정 하에 장애 대응(runbook/rollback) 준비가 되었는가?\u0026rdquo; 결국 이 법칙들은 \u0026ldquo;새로운 이론\u0026quot;이라기보다, 반복되는 실패의 압축 기록입니다. 프로젝트가 꼬일 때마다 원인을 사람 탓으로만 보지 말고, 어떤 법칙이 이미 작동 중인지부터 점검하면 의사결정 품질이 크게 올라갑니다.\n","wordCount":442,"tags":["소프트웨어 엔지니어링","법칙","아키텍처","팀 생산성","의사결정"],"categories":["Software Engineering"],"frameworks":["First Principles","Systems Thinking"],"mental_models":["Trade-off Thinking","Second-order Effects"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["20개 법칙은 기술 자체보다 사람·조직·시간 압력에서 반복되는 실패 패턴을 설명한다.","Brooks·Goodhart·Hofstadter 같은 법칙은 일정, 인력, KPI 설계에서 특히 강력한 경고 신호다.","핵심 실천은 복잡성 억제(KISS), 점진적 진화(Gall), 측정 왜곡 방지(Goodhart), 장애 전제 설계(Murphy)다."],"related":["posts/components-of-a-coding-agent","software/the-future-of-software-engineering-is-sre","posts/agentic-software-engineering"]},{"title":"Palantir Ontology 핵심 : 데이터 중심을 넘어 의사결정 중심 아키텍처로","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/palantir-ontology-decision-centric-architecture/","section":"posts","date":"2026-05-04T12:12:20+09:00","lastmod":"2026-05-04T12:12:20+09:00","description":"Palantir가 제시한 Ontology의 핵심을 데이터·로직·액션·보안 4요소와 Onyx 사례 중심으로 정리한 글.","summary":"Palantir가 공개한 \u0026ldquo;The Palantir Ontology\u0026quot;는 단순한 데이터 통합 전략이 아니라, 기업 운영을 의사결정 단위로 모델링해야 한다는 주장을 담고 있습니다. 이 글은 긴 원문을 실무 관점에서 빠르게 파악할 수 있도록 핵심만 압축한 정리입니다.\nTL;DR 핵심 정리 핵심 프레임: Ontology는 Data + Logic + Action + Security를 하나로 연결해, 분석 시스템이 아닌 운영 의사결정 시스템을 만든다. 중요한 포인트: 기업 데이터 자체보다, 누가/언제/어떤 맥락에서 어떤 결정을 내렸는지에 대한 의사결정 데이터와 계보 축적을 더 중시한다. 에이전트 활용 방식: LLM이 단순 조회(RAG)에 머무르지 않고, 기존 최적화 모델·시뮬레이터·업무 로직을 툴로 호출해 대안을 만들고 시나리오로 안전하게 검토한다. 실행과 통제: 액션(writeback)은 ERP/WMS/엣지 시스템까지 반영되지만, 권한·검증·감사 로그를 동일한 보안 체계로 강제해 자동화 리스크를 줄인다. 최종 메시지: 생성형 AI 도입 성패는 \u0026ldquo;모델 성능\u0026quot;보다 \u0026ldquo;의사결정 루프를 얼마나 안전하게 닫고 학습시키는 아키텍처를 갖췄는가\u0026quot;에 달려 있다는 주장이다. 원문: https://x.com/PalantirTech/status/2049136883528011954\n","content":"Palantir가 공개한 \u0026ldquo;The Palantir Ontology\u0026quot;는 단순한 데이터 통합 전략이 아니라, 기업 운영을 의사결정 단위로 모델링해야 한다는 주장을 담고 있습니다. 이 글은 긴 원문을 실무 관점에서 빠르게 파악할 수 있도록 핵심만 압축한 정리입니다.\nTL;DR 핵심 정리 핵심 프레임: Ontology는 Data + Logic + Action + Security를 하나로 연결해, 분석 시스템이 아닌 운영 의사결정 시스템을 만든다. 중요한 포인트: 기업 데이터 자체보다, 누가/언제/어떤 맥락에서 어떤 결정을 내렸는지에 대한 의사결정 데이터와 계보 축적을 더 중시한다. 에이전트 활용 방식: LLM이 단순 조회(RAG)에 머무르지 않고, 기존 최적화 모델·시뮬레이터·업무 로직을 툴로 호출해 대안을 만들고 시나리오로 안전하게 검토한다. 실행과 통제: 액션(writeback)은 ERP/WMS/엣지 시스템까지 반영되지만, 권한·검증·감사 로그를 동일한 보안 체계로 강제해 자동화 리스크를 줄인다. 최종 메시지: 생성형 AI 도입 성패는 \u0026ldquo;모델 성능\u0026quot;보다 \u0026ldquo;의사결정 루프를 얼마나 안전하게 닫고 학습시키는 아키텍처를 갖췄는가\u0026quot;에 달려 있다는 주장이다. 원문: https://x.com/PalantirTech/status/2049136883528011954\n1) Palantir가 말하는 Ontology의 본질 Palantir는 Ontology를 \u0026ldquo;데이터를 표현하는 시스템\u0026quot;이 아니라 기업의 의사결정을 표현하는 시스템으로 정의합니다. 즉, 데이터 웨어하우스/대시보드 중심 구조에서 끝나는 것이 아니라, 실제 운영에서 발생하는 판단과 실행까지 소프트웨어 모델 안으로 끌어들이는 접근입니다.\n핵심 문제의식은 명확합니다.\n전통적 데이터 아키텍처는 \u0026ldquo;무슨 데이터가 있나\u0026quot;는 잘 다루지만, \u0026ldquo;왜 그 결정을 했고 어떤 결과가 났나\u0026quot;를 충분히 담지 못한다. 분석 아키텍처는 현실 운영 흐름과 분리되기 쉬워서, AI를 붙여도 실행력 있는 개선으로 연결되기 어렵다. 따라서 현대 기업에는 데이터 중심이 아닌 의사결정 중심(decision-centric) 아키텍처가 필요하다. 2) 4가지 구성요소: Data · Logic · Action · Security Data 원문은 AI 시대의 핵심 과제를 \u0026ldquo;정제\u0026quot;보다 **관련성(relevance)**으로 봅니다. 구조화/비정형/스트리밍/엣지 데이터를 통합하는 것에 더해, 업무 중 생성되는 의사결정 맥락 데이터까지 포함해야 한다는 주장입니다.\n특히 다음이 중요합니다.\n어떤 데이터 버전 위에서 결정했는지 어떤 선택지를 검토했는지 어떤 애플리케이션 경로로 실행했는지 이 decision lineage가 누적돼야, 이후 에이전트 메모리(에피소드/절차/시맨틱)를 개선할 수 있다는 논리입니다.\nLogic 기업 의사결정은 LLM 추론만으로 이뤄지지 않습니다. 기존 업무 규칙, 예측 모델, 최적화 모델, 시뮬레이션 로직이 모두 필요합니다.\nPalantir의 포인트는 이 이질적 로직 자산(온프레미스, SaaS, 클라우드, 플랫폼 내부)을 일관된 인터페이스로 묶어, 인간과 에이전트가 같은 맥락에서 사용할 수 있게 하자는 것입니다.\nAction Ontology의 차별화 지점은 액션(실행)을 1급 객체로 다룬다는 점입니다. 즉, 추천에서 끝나는 AI가 아니라 실제 운영 시스템으로 writeback 되는 경로를 설계합니다.\n의사결정 시나리오 스테이징 승인/커밋 분리 동시·충돌 의사결정 처리 대상 시스템별 안전한 반영(API/커넥터/파일 등) 이를 통해 분석 시스템이 아니라 운영 루프를 닫는 시스템을 지향합니다.\nSecurity 보안은 권한 테이블 이상의 문제로 다뤄집니다.\nrole(역할) + purpose(목적) + marking(보안 라벨) 데이터/로직/액션/툴 호출/에이전트 메모리/텔레메트리 로그 전반에 일관 적용 런타임 정책 계산과 세밀한 승인 범위로 예기치 않은 호출·권한 상승 방지 하면, \u0026ldquo;에이전트도 사람과 동일한 통제 프레임 안에서 움직이게 하라\u0026quot;는 메시지입니다.\n3) Onyx 사례로 본 운영 시나리오 원문은 가상의 의료장비 제조사 Onyx를 통해 공급망 충격 대응을 설명합니다.\n주요 공급사 차질로 수술용 마스크 원자재 부족 발생 온톨로지로 공급·재고·생산·출하·주문 데이터를 연결해 영향 범위 즉시 파악 분석가 + 에이전트가 재할당 시뮬레이션을 돌리고 시나리오로 안전하게 비교 검토된 대안을 ERP/WMS/생산계획 시스템에 통제된 방식으로 반영 전 과정 로그와 계보를 다음 의사결정 학습 자산으로 재활용 실무적으로는 \u0026ldquo;AI가 답을 내는가\u0026quot;보다, 조직이 신뢰 가능한 방식으로 답을 검토·실행·학습할 수 있는가가 더 중요한 지표라는 점을 강조합니다.\n4) 이 글에서 얻을 수 있는 실무 인사이트 에이전트 도입은 챗봇 UI보다 의사결정 모델링이 선행되어야 성과가 난다. \u0026ldquo;데이터 통합\u0026quot;만으로는 부족하며, 로직 자산과 실행 경로까지 제품적으로 연결해야 한다. 완전자율 자동화보다 시나리오 스테이징 + 인간 승인 구조가 현실적인 확장 경로다. 보안/감사/로그를 사후 통제가 아니라 설계 중심에 두어야 운영 자동화가 커진다. 한 줄 결론 Palantir Ontology의 제안은 결국 이것입니다: AI를 잘 쓰는 기업은 데이터를 많이 가진 기업이 아니라, 의사결정의 맥락·실행·학습을 하나의 보안된 루프로 연결한 기업이라는 것.\n","wordCount":536,"tags":["palantir","ontology","aip","ai-agent","enterprise-ai"],"categories":["ai","enterprise"],"frameworks":["Systems Thinking","Agent-native Development","Verification-first Engineering"],"mental_models":["Borrowed Confidence","Trade-off Analysis"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["Palantir Ontology의 본질은 데이터 모델이 아니라 의사결정 모델이며, 데이터·로직·액션·보안을 하나의 운영 기반으로 묶는다.","핵심 차별점은 의사결정 계보(decision lineage)를 자동 축적해 인간-에이전트 협업 학습 루프를 만든다는 점이다.","Onyx 사례에서 에이전트는 시뮬레이션과 시나리오 스테이징으로 대안 제시를 수행하고, 최종 반영은 세분화된 권한/검증 하에 실행된다.","보안은 역할(role)만이 아니라 목적(purpose)·마킹(marking) 기반 정책까지 런타임으로 계산해 데이터/툴/메모리/로그 전반에 일관 적용된다."],"related":["posts/agent-assisted-qualitative-analysis-core-notes","posts/components-of-a-coding-agent","posts/the-20-software-engineering-laws-summary"]},{"title":"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-30T11:24:00+09:00","lastmod":"2026-04-30T11:24:00+09:00","description":"智谱(Z.ai)이 공개한 「Scaling Pain」은 GLM-5 시리즈가 초대규모 Coding Agent 호출에서 겪은 추론 인프라 문제를 처음으로 공개한 글이다. 처리량 +132%, 이상 출력률 만분의 십몇에서 만분의 3 미만으로의 개선, 그리고 SGLang 업스트림으로 환원된 PR #22811이 의미하는 바를 짚는다.","summary":"오늘(2026.4.30) 智谱(Zhipu / Z.ai)이 공개한 기술 블로그 **「Scaling Pain：超大规模 Coding Agent 推理实践」**는 GLM-5 시리즈가 초대규모 Coding Agent 호출 시나리오에서 겪은 추론 인프라 문제와, 이를 해결하기 위한 엔지니어링 최적화 결과를 처음으로 체계적으로 공개한 글입니다. 단순한 자랑이 아니라, 수요가 공급을 초과해 신규 구독을 제한해야 했던 몇 달의 누적 이슈에 대한 공식 답변에 가깝습니다.\n원문: Scaling Pain — Z.ai Blog (2026-04-30)\n핵심 도발 \u0026ldquo;Scaling up하니, 진짜 본 적 없는 아픔이 나왔다.\u0026rdquo;\n이 정서가 글 전체의 톤입니다. 회피하지 않고 공개했다는 사실 자체가 이번 포스트의 위치를 결정합니다.\n","content":"오늘(2026.4.30) 智谱(Zhipu / Z.ai)이 공개한 기술 블로그 **「Scaling Pain：超大规模 Coding Agent 推理实践」**는 GLM-5 시리즈가 초대규모 Coding Agent 호출 시나리오에서 겪은 추론 인프라 문제와, 이를 해결하기 위한 엔지니어링 최적화 결과를 처음으로 체계적으로 공개한 글입니다. 단순한 자랑이 아니라, 수요가 공급을 초과해 신규 구독을 제한해야 했던 몇 달의 누적 이슈에 대한 공식 답변에 가깝습니다.\n원문: Scaling Pain — Z.ai Blog (2026-04-30)\n핵심 도발 \u0026ldquo;Scaling up하니, 진짜 본 적 없는 아픔이 나왔다.\u0026rdquo;\n이 정서가 글 전체의 톤입니다. 회피하지 않고 공개했다는 사실 자체가 이번 포스트의 위치를 결정합니다.\n세 줄 무엇이 문제였나 — Coding Agent 워크로드(긴 컨텍스트, 다중 도구 호출, 장시간 세션)는 일반 챗 워크로드와 추론 부하 패턴이 완전히 달라서 기존 서빙 스택이 흔들렸다. 무엇을 했나 — DSA(DeepSeek Sparse Attention) 기반 GLM-5의 인덱서·디코딩·결정성(determinism) 등 저수준 단을 손봤다. 어디까지 갔나 — 처리량 +132%, 이상 출력률 1/3 미만으로 축소, 수정 사항을 자체 폐쇄 최적화가 아니라 SGLang 업스트림 PR #22811로 환원했다. 배경 맥락 — 왜 \u0026ldquo;Scaling Pain\u0026quot;이라 불렀는가 이 글은 갑자기 나온 게 아니라, 지난 몇 달간 누적된 Z.ai의 인프라 이슈에 대한 공식 답변입니다.\n수요가 공급을 초과한 상태가 지속됨 Zhipu는 GLM-4.7 수요가 인프라를 압도해 신규 구독을 용량의 20%로 제한해야 했고, 기존 사용자도 피크 시간대 슬로우다운을 겪었습니다. z.ai의 LinkedIn 공지에서도 이렇게 인정했습니다.\n\u0026ldquo;GLM-5에 대한 글로벌 수요가 모든 예측을 초과했고, 여러 차례의 클러스터 확장 후에도 수요가 가용 추론 용량을 계속 앞지르고 있다.\u0026rdquo;\n하드웨어 제약이 더 심하다 GLM-5는 NVIDIA가 아니라 Huawei Ascend 위에서 학습/서빙되는 구조입니다. 일반적인 H100/H200 기반 최적화 노하우를 그대로 가져올 수 없다는 추가 제약이 깔려 있습니다.\n모델 크기·아키텍처의 부담 파라미터 확장 — GLM-4.5의 355B(활성 32B) → GLM-5의 744B(활성 40B) 아키텍처 변화 — DeepSeek Sparse Attention(DSA) 도입, 긴 컨텍스트 용량은 보존하면서 배포 비용을 줄이는 구조 부작용 — DSA는 새 메커니즘이라 인덱서의 결정성(determinism) 같은 미묘한 이슈가 생산 환경에서 새로 드러난다 정량 결과 — 무엇이 얼마나 좋아졌나 지표 변화 시스템 처리량 최대 +132% 이상 출력률 만분의 십몇 → 만분의 3 미만 수정 환원처 SGLang 업스트림 PR #22811 처리량 132%는 같은 클러스터로 두 배 가까운 트래픽을 받는다는 뜻입니다. 그러나 더 중요한 숫자는 이상 출력률입니다 — 단발 평가에서는 거의 무시될 만한 차이지만, 멀티턴 에이전트에서는 의미가 다릅니다.\n시사점 1 — \u0026ldquo;Chat 워크로드 ≠ Agent 워크로드\u0026quot;가 인프라 차원에서 공식화되고 있다 챗봇 호출은 짧은 prompt-completion 1회전입니다. Coding Agent는 다릅니다:\n긴 컨텍스트 — 코드베이스 200K+ 토큰 수십 회의 tool call — 파일 읽기·쓰기·실행·검색 멀티턴 reasoning — 한 세션 안에서 수십 번 모델이 다시 호출됨 부하 패턴이 달라서 KV 캐시 재사용, 결정성, 처리량/지연 트레이드오프 전부가 다시 설계돼야 합니다.\nAPI를 외부 의존성으로 쓰더라도, 어느 워크로드에 최적화된 엔드포인트인지는 이제 의식해야 하는 변수가 됐다.\n시사점 2 — 비결정성이 멀티턴 에이전트 신뢰성의 진짜 적이다 이상 출력률 만분의 십몇 → 만분의 3은 단발 호출에서는 안 보이는 숫자입니다. 그러나 30턴짜리 에이전트 루프를 떠올려 보면 게임이 바뀝니다.\n한 번의 이탈이 컨텍스트에 들어가 다음 턴을 오염 잘못된 가정 위에 다음 도구 호출 결국 전체 task 실패 GLM-5 기술 보고서에서도 비슷한 이야기가 나옵니다 — DSA Indexer의 비결정적 CUDA top-k 연산자가 RL 단계에서 몇 스텝 만에 성능 급락과 엔트로피 붕괴를 일으켰고, deterministic torch.topk로 바꿔야 했다는 디테일.\n내가 만드는 파이프라인이 실패해도 retry로 자연스럽게 복구되는 구조인지, 한 번 어긋나면 카스케이드되는지 — 이번 포스트가 던지는 점검 질문이다.\n시사점 3 — 자체 호스팅 vs API 결정에 \u0026ldquo;운영 깊이\u0026rdquo; 변수가 추가됐다 오픈웨이트를 받아서 SGLang/vLLM에 띄우는 것 자체는 쉬워졌습니다. 그러나 132% throughput 차이를 만든 건 모델이 아니라:\n인덱서 패치 스케줄러 튜닝 디코딩 레이어 수정 즉 *\u0026ldquo;내가 직접 띄우면 동일 성능\u0026rdquo;*이라는 가정이 점점 위험해지고 있습니다. 특히 Coding Agent처럼 부하 패턴이 까다로운 영역에서는 모델 제공자의 인프라 노하우 자체가 제품 차별점이 되고 있습니다.\n시사점 4 — 오픈소스 환원이 신호다 수정안을 사내에서 안 끌어안고 SGLang 업스트림 PR #22811로 보낸 것은, 단순 선의가 아닙니다.\nDeepSeek (DSA 메커니즘 원작자) SGLang (오픈소스 추론 프레임워크) Huawei Ascend (하드웨어 스택) 세 진영을 가로지르는 공동 표준화 흐름으로 읽힙니다. 동시에 NVIDIA 외부 스택의 성숙도가 빨라지고 있다는 신호이기도 합니다.\n멀티 프로바이더 전략(Anthropic, OpenAI, Z.ai/GLM, DeepSeek 등)을 짤 때, GLM 계열을 코딩 에이전트 비용 최적화 슬롯으로 진지하게 평가할 만한 시점이 됐다.\n시사점 5 — \u0026ldquo;코딩 에이전트의 SLA\u0026quot;라는 새 지표가 곧 일반화될 것 처리량이 좋아도 만분의 몇 단위의 이상 출력률이 누적되면 long-horizon agent에선 치명적입니다. 앞으로 모델 선택의 기준은:\nSWE-bench 점수 → (throughput × determinism × long-context 안정성) 결합 지표\n쪽으로 이동할 가능성이 높습니다. Z.ai가 이번 글을 통해 그 프레이밍을 선점하려는 의도도 함께 읽힙니다.\n핵심 어휘 정리 Scaling Pain — 단일 모델·단일 클러스터에서는 안 보이다가, 트래픽 스케일업이 일어났을 때 처음 드러나는 인프라 결함 DSA (DeepSeek Sparse Attention) — 긴 컨텍스트 용량을 보존하면서 배포 비용을 줄이는 어텐션 메커니즘; 인덱서 결정성이 새로운 운영 변수 Determinism — 같은 입력에 같은 출력을 보장하는 성질; 단발 챗에서는 사치, 멀티턴 에이전트에서는 신뢰성의 토대 Open-source Reciprocity — 자체 최적화를 사내에 가두지 않고 업스트림으로 환원하는 패턴; 표준화 협상력이 됨 실행 체크리스트 — 이번 글을 본 뒤 점검할 것 우리 에이전트가 호출하는 모델이 챗 워크로드 최적화인지 에이전트 워크로드 최적화인지 명확히 분리해 평가 멀티턴 루프의 카스케이드 실패 시나리오 시뮬레이션 — 0.1% 이탈이 30턴에서 어떻게 누적되는지 자체 호스팅을 검토 중이라면, 인덱서·디코딩·스케줄러 레이어의 운영 노하우 비용을 별도 항목으로 산정 GLM-5 / DeepSeek / Qwen 계열을 코딩 에이전트 슬롯에 후보로 올려 비용·안정성 벤치 SLA 정의에 throughput만이 아니라 determinism, long-context 안정성을 명시적으로 포함 왜 이 글이 중요한가 대부분의 모델 카드 발표는 벤치마크 점수에 머무릅니다. 「Scaling Pain」은 그 한 층 아래를 공개합니다 — 생산 환경에서 실제로 무엇이 부서졌고 어떻게 고쳤는가.\n솔직함의 신호 — 수요가 인프라를 압도했다고 공식적으로 인정한 사례는 드물다 메커니즘적 진단 — 챗 vs 에이전트 워크로드의 부하 패턴 차이를 인프라 차원에서 정의 정량 환원 — +132% / 만분의 3이라는 측정 가능한 결과 개방성 — PR #22811이라는 재사용 가능한 출구 모델은 점수표가 아니라 운영 환경에서 부서지는 방식으로 평가받는 시대로 옮겨가고 있다.\n핵심 결론 Coding Agent 워크로드는 챗 워크로드와 다르다 — 긴 컨텍스트 + 다중 도구 호출 + 장시간 세션이 한 번에 묶인다 이상 출력률 만분의 몇은 멀티턴에서 카스케이드된다 — 단발 평가가 가리는 진짜 SLA 인프라 노하우가 제품 차별점이다 — 같은 오픈웨이트라도 132% throughput 차이가 난다 오픈소스 환원이 표준화 신호다 — SGLang PR #22811은 DeepSeek/SGLang/Ascend 공동 진영의 협상력 모델 선택 기준이 이동한다 — SWE-bench → throughput × determinism × long-context 당신의 에이전트가 의존하는 모델은, 30턴 뒤에도 같은 모델인가.\n","wordCount":961,"tags":["Z.ai","Zhipu","GLM-5","Coding Agent","SGLang","DeepSeek Sparse Attention","DSA","Huawei Ascend","Inference Infrastructure","Determinism","오픈소스","추론 최적화"],"categories":["AI"],"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"],"philosophy_type":"infrastructure-engineering","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Coding Agent 워크로드는 챗 워크로드와 추론 부하 패턴이 완전히 다르다 — 긴 컨텍스트, 다중 도구 호출, 장시간 세션이 한 번에 묶인다","엔지니어링 최적화 결과 GLM-5 Coding Agent 시스템 처리량 최대 +132%, 이상 출력률 만분의 십몇 → 만분의 3 미만","수정안은 사내에 가두지 않고 SGLang 업스트림 PR #22811로 환원 — DeepSeek/SGLang/Ascend 진영의 공동 표준화 신호","DSA(DeepSeek Sparse Attention) Indexer의 비결정성은 단발 평가에선 안 보이지만 30턴 에이전트 루프에선 카스케이드된다","GLM-5는 Huawei Ascend 위에서 학습/서빙 — H100/H200 노하우를 그대로 가져올 수 없는 추가 제약"],"related":["posts/all-your-agents-are-going-async","posts/anatomy-of-an-agent-harness","posts/hidden-llm-api-costs"]},{"title":"학습할 것인가, 말 것인가 — Tanay Jaipuria가 정리한 AI 앱 회사의 모델 레이어 진입 가이드","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/to-train-or-not-to-train/","section":"posts","date":"2026-04-29T23:40:00+09:00","lastmod":"2026-04-29T23:40:00+09:00","description":"Tanay Jaipuria의 'To Train or Not to Train'을 한국어로 정리한다 — AI 앱 회사가 모델 레이어로 풀스택화될 때, 사전학습은 피하고 post-training/RL을 언제·어떻게 시작해야 하는지, 그리고 베이스 모델 릴리즈 사이클이라는 가장 큰 리스크는 무엇인지.","summary":"AI 애플리케이션 회사들이 점점 더 풀스택화되어 모델 레이어와 서비스 레이어로 진입하고 있는 가운데, 언제 자체 모델 학습에 뛰어들어야 하는가 라는 질문이 점점 무거워지고 있습니다. Tanay Jaipuria의 \u0026ldquo;To Train or Not to Train\u0026quot;은 이 결정을 둘러싼 트레이드오프를 짧고 명확하게 정리합니다.\n원문: To Train or Not to Train — Tanay Jaipuria\nTL;DR 요약 풀스택화는 진행 중: 앱 레이어 회사들이 모델·서비스 레이어로 내려가고 있지만, 처음부터 사전학습 은 거의 항상 잘못된 선택이다. 현실적 경로: 강력한 오픈 웨이트 베이스 모델 위에서 post-training과 RL 을 얹는 방식이 디폴트가 되고 있다. 학습 트리거: 파이프라인의 특정 부분에서 작은 특화 모델이 프론티어 모델보다 의미 있게 더 잘하게 만들 만큼의 독점 데이터가 쌓였을 때, 그리고 회사가 빠르게 스케일링하며 데이터 트레이스를 모으거나 PMF 후 프론티어 모델로는 부족함을 느낄 때. 기회비용: post-training 인재는 희소·고비용. 같은 자원을 제품·유통의 다른 곳에 쓰는 것이 더 나은 경우가 많다. 가장 큰 리스크: 직접 학습한 모델이 다음 베이스 모델 릴리즈에 살아남지 못하는 것 — 프론티어 랩들의 릴리즈 사이클이 그 어느 때보다 빠르다. 2026년의 디폴트 답: 대부분의 초기 단계 앱 회사에게는 \u0026ldquo;아직은 아니다, 그러나 준비는 시작하라\u0026rdquo; — 데이터 수집을 지금 세팅하고, 비핵심 영역에서 작은 특화 모델 하나로 출발하라. 풀스택화의 큰 그림 AI 앱 회사들은 더 이상 단순히 프론티어 API를 얇게 감싸는 데 머물지 않습니다. 모델 레이어로 내려가 자체 학습을 하거나, 서비스 레이어로 올라가 도메인 전용 워크플로우를 통합하는 식으로 수직 통합 이 진행 중입니다. 이 글은 그중 모델 레이어 진입의 손익 에 초점을 맞춥니다.\n","content":"AI 애플리케이션 회사들이 점점 더 풀스택화되어 모델 레이어와 서비스 레이어로 진입하고 있는 가운데, 언제 자체 모델 학습에 뛰어들어야 하는가 라는 질문이 점점 무거워지고 있습니다. Tanay Jaipuria의 \u0026ldquo;To Train or Not to Train\u0026quot;은 이 결정을 둘러싼 트레이드오프를 짧고 명확하게 정리합니다.\n원문: To Train or Not to Train — Tanay Jaipuria\nTL;DR 요약 풀스택화는 진행 중: 앱 레이어 회사들이 모델·서비스 레이어로 내려가고 있지만, 처음부터 사전학습 은 거의 항상 잘못된 선택이다. 현실적 경로: 강력한 오픈 웨이트 베이스 모델 위에서 post-training과 RL 을 얹는 방식이 디폴트가 되고 있다. 학습 트리거: 파이프라인의 특정 부분에서 작은 특화 모델이 프론티어 모델보다 의미 있게 더 잘하게 만들 만큼의 독점 데이터가 쌓였을 때, 그리고 회사가 빠르게 스케일링하며 데이터 트레이스를 모으거나 PMF 후 프론티어 모델로는 부족함을 느낄 때. 기회비용: post-training 인재는 희소·고비용. 같은 자원을 제품·유통의 다른 곳에 쓰는 것이 더 나은 경우가 많다. 가장 큰 리스크: 직접 학습한 모델이 다음 베이스 모델 릴리즈에 살아남지 못하는 것 — 프론티어 랩들의 릴리즈 사이클이 그 어느 때보다 빠르다. 2026년의 디폴트 답: 대부분의 초기 단계 앱 회사에게는 \u0026ldquo;아직은 아니다, 그러나 준비는 시작하라\u0026rdquo; — 데이터 수집을 지금 세팅하고, 비핵심 영역에서 작은 특화 모델 하나로 출발하라. 풀스택화의 큰 그림 AI 앱 회사들은 더 이상 단순히 프론티어 API를 얇게 감싸는 데 머물지 않습니다. 모델 레이어로 내려가 자체 학습을 하거나, 서비스 레이어로 올라가 도메인 전용 워크플로우를 통합하는 식으로 수직 통합 이 진행 중입니다. 이 글은 그중 모델 레이어 진입의 손익 에 초점을 맞춥니다.\n핵심 전제: 사전학습(pre-training)은 거의 모든 앱 회사의 정답이 아니다. 비용·인재·시간의 격차가 너무 크고, 프론티어 랩의 베이스 모델 발전 속도가 그 격차를 매년 더 벌리고 있기 때문입니다.\n따라서 현실적인 옵션은 오픈 웨이트 베이스 모델 위에서의 post-training과 강화학습(RL) 입니다.\n언제 학습해야 하는가 — 트리거 조건 학습에 뛰어들 만한 신호는 단순합니다.\n조건 해석 독점 데이터의 축적 파이프라인의 특정 부분에서, 작은 특화 모델이 프론티어 모델보다 의미 있게 더 잘하도록 만들 만큼 충분한 데이터가 쌓였는가 빠른 스케일링 사용자 트래픽으로부터 데이터 트레이스가 자연스럽게 누적되고 있는가 PMF 이후의 한계 인식 제품-시장 적합성을 찾았으나, 특정 영역에서 프론티어 모델로는 충분히 잘 풀리지 않는다는 감각이 있는가 이 조건들이 동시에 성립할 때, 파이프라인의 한 부분 에 대해 작은 특화 모델로 시작하는 것이 합리적입니다. 처음부터 모든 것을 자체 모델로 대체하려 들지 않는 것이 핵심입니다.\n언제 학습하지 말아야 하는가 — 기회비용 반대로 학습을 미뤄야 할 이유도 분명합니다.\n인재 희소성: post-training과 RL을 제대로 할 수 있는 엔지니어는 적고, 비싸고, 채용 사이클이 길다. 기회비용: 같은 자원을 유통, 제품, 데이터 인프라, 평가 체계에 쓰면 더 큰 레버리지가 나오는 단계가 대부분이다. 운영 부담: 학습된 모델은 서빙·평가·재학습·회귀 모니터링이라는 새로운 운영 표면을 만든다. 요컨대, \u0026ldquo;학습할 수 있다\u0026quot;가 아니라 \u0026ldquo;학습이 다른 어떤 투자보다 ROI가 높다\u0026rdquo; 가 되어야 시작할 수 있습니다.\n가장 큰 리스크 — 베이스 모델 릴리즈 사이클 글이 강조하는 가장 날카로운 리스크는 다음과 같습니다.\n직접 post-train 한 모델이 다음 베이스 모델 릴리즈를 넘기지 못할 수 있다.\n프론티어 랩들이 신모델을 그 어느 때보다 빠르게 내고 있기 때문에, 어렵게 만든 특화 모델이 새로운 베이스 모델의 일반 성능 한 번에 따라잡히거나 추월당하는 일이 흔합니다. 이 리스크를 줄이려면:\n재학습 가능한 파이프라인 으로 만들 것 — 새 베이스가 나오면 빠르게 갈아끼울 수 있어야 한다. 데이터·평가 자산을 분리 할 것 — 모델은 갈아치우더라도, 학습 데이터셋·평가셋·보상 신호는 영구 자산으로 남아야 한다. 모델이 아닌 환경에 투자 할 것 — 도구·검증기·롤아웃 환경의 우위는 베이스 교체에도 살아남는다. 2026년의 디폴트 답 대부분의 초기 단계 앱 회사에 대한 솔직한 답은 다음과 같이 정리됩니다.\n\u0026ldquo;아직은 아니다, 그러나 준비는 시작하라.\u0026rdquo;\n구체적으로:\n데이터 수집 인프라를 지금 세팅하라 — 사용자 트레이스, 정답 라벨, 거절 사유, 인간 피드백을 구조화해 저장. 평가 체계를 먼저 만들라 — 학습보다 평가가 선행되어야 어떤 학습이 의미 있는지 판단할 수 있다. 비핵심 영역에서 작은 특화 모델 하나로 시작하라 — 분류기, 라우터, 추출기 같은 좁은 작업이 위험을 낮춘다. 프론티어 모델은 계속 메인으로 쓰라 — 일반 추론은 프론티어, 좁은 특화는 자체 모델이라는 하이브리드가 디폴트. 결론 \u0026ldquo;To Train or Not to Train\u0026quot;의 메시지는 한 줄로 압축됩니다 — 학습은 옵션이지 정체성이 아니다. 풀스택화의 매혹에 끌려 모델 레이어로 너무 일찍 내려가지 말고, 데이터·평가·환경이라는 영구 자산을 먼저 쌓은 뒤, 트리거가 분명해졌을 때 비핵심 한 곳에서 시작하라는 것입니다.\n단계 권장 행동 초기 프론티어 API + 데이터 수집 인프라 + 평가 체계 PMF 직후 비핵심 한 부분에서 작은 특화 모델 PoC 스케일 데이터 트레이스가 풍부해진 영역에 한해 post-training/RL 확장 항시 베이스 모델 교체 가능성을 전제로 한 파이프라인 설계 ","wordCount":673,"tags":["AI","post-training","RL","파인튜닝","스타트업","모델 레이어","Tanay Jaipuria"],"categories":["AI"],"frameworks":["Build vs Buy","Opportunity Cost"],"mental_models":["Stack Migration","Proprietary Data Moat"],"philosophy_type":"decision-making","schema_type":"HowTo","actionable":true,"priority":"high","key_points":["AI 앱 회사들이 모델·서비스 레이어로 풀스택화되고 있지만, 처음부터 사전학습(pre-training)에 들어가는 건 거의 항상 잘못된 선택이다","현실적 경로는 강력한 오픈 웨이트 베이스 모델 위에서의 post-training과 강화학습(RL)이다","학습 트리거: 파이프라인의 특정 부분에서 작은 특화 모델이 프론티어 모델보다 의미 있게 더 잘하게 만들 수 있을 만큼의 독점 데이터가 쌓였을 때","Post-training 인재는 희소·고비용 — 그 기회비용을 제품과 다른 부분에 쓰는 것이 더 나은 경우가 많다","가장 큰 리스크는 직접 학습한 모델이 다음 베이스 모델 릴리즈 한 번에 무용지물이 되는 것 — 프론티어 랩들은 그 어느 때보다 빠르게 신모델을 내고 있다","2026년 대부분의 초기 단계 앱 회사에게 정직한 답은 '아직은 아니다, 그러나 준비는 시작하라'"],"related":["posts/rl-environments-for-llm-agents","posts/hidden-llm-api-costs"]},{"title":"빌드하기 전 3가지 제약 — Jordan Lord이 10년 실패에서 추출한 창작자의 가드레일","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/jordan-lord-3-constraints/","section":"posts","date":"2026-04-29T19:55:39+09:00","lastmod":"2026-04-29T19:55:39+09:00","description":"Jordan Lord이 10년간 '너무 복잡하거나 정체성이 없는' 제품을 만들며 실패한 끝에 정리한 3가지 제약 — One Pager, Core Technology, Product Constraint. 제약은 창의성의 적이 아니라 탐색 공간을 좁혀 혁신을 강제하는 장치라는 주장을 정리한다.","summary":"Jordan Lord(소프트웨어 엔지니어, Footium 등 인디 프로젝트 창작자)이 자신의 블로그에 올린 글 \u0026ldquo;3 constraints before I build anything\u0026rdquo; 은 단순합니다. 제약이 없는 빌드는 실패한다. 그가 10년간 너무 복잡하거나 정체성이 없는 제품을 만들며 깨달은 것은, 시작 전에 강제로 통과시켜야 하는 3개의 게이트가 있다는 사실입니다.\n원문: 3 constraints before I build anything — Jordan Lord\nTL;DR 요약 전제: 제약은 창의성을 막는 게 아니라 탐색 공간을 좁혀 혁신적 해법을 끌어낸다. 빌드 전에 3가지 게이트를 강제로 통과시켜야 한다. The One Pager: 아이디어는 한 페이지에 북극성으로 정리되어야 한다. 타협 불가·정밀·야심차되·간결. 한 페이지를 넘기면 너무 복잡한 것이고, 만들지 말아야 한다. Core Technology: 제품을 떠받치되 제품 자체는 아닌 핵심 기술 한 조각. 방법론·스킬·도구·다른 제품 무엇이든. 제품은 피벗해도 핵심 기술은 누적되며, 긴 시간 지평에서 비선형적 이득을 만든다. Product Constraint: 제품의 전면에 드러나는 자기만의 제약. 사용자가 직접 보고 상호작용하는 가시적 제약이 곧 제품의 정체성이다. 회고: Jordan은 이 3가지가 없는 상태에서 10년간 만든 제품이 어디로도 가지 못했다고 인정한다. 출발점 — 왜 제약인가 Jordan의 주장은 인디 해커 커뮤니티의 통념과 정반대 방향에서 시작합니다. \u0026ldquo;무엇이든 빠르게 만들고 시장이 답하게 하라\u0026rdquo; 가 아니라, \u0026ldquo;만들기 전에 스스로를 좁혀라\u0026rdquo; 는 것입니다.\n","content":"Jordan Lord(소프트웨어 엔지니어, Footium 등 인디 프로젝트 창작자)이 자신의 블로그에 올린 글 \u0026ldquo;3 constraints before I build anything\u0026rdquo; 은 단순합니다. 제약이 없는 빌드는 실패한다. 그가 10년간 너무 복잡하거나 정체성이 없는 제품을 만들며 깨달은 것은, 시작 전에 강제로 통과시켜야 하는 3개의 게이트가 있다는 사실입니다.\n원문: 3 constraints before I build anything — Jordan Lord\nTL;DR 요약 전제: 제약은 창의성을 막는 게 아니라 탐색 공간을 좁혀 혁신적 해법을 끌어낸다. 빌드 전에 3가지 게이트를 강제로 통과시켜야 한다. The One Pager: 아이디어는 한 페이지에 북극성으로 정리되어야 한다. 타협 불가·정밀·야심차되·간결. 한 페이지를 넘기면 너무 복잡한 것이고, 만들지 말아야 한다. Core Technology: 제품을 떠받치되 제품 자체는 아닌 핵심 기술 한 조각. 방법론·스킬·도구·다른 제품 무엇이든. 제품은 피벗해도 핵심 기술은 누적되며, 긴 시간 지평에서 비선형적 이득을 만든다. Product Constraint: 제품의 전면에 드러나는 자기만의 제약. 사용자가 직접 보고 상호작용하는 가시적 제약이 곧 제품의 정체성이다. 회고: Jordan은 이 3가지가 없는 상태에서 10년간 만든 제품이 어디로도 가지 못했다고 인정한다. 출발점 — 왜 제약인가 Jordan의 주장은 인디 해커 커뮤니티의 통념과 정반대 방향에서 시작합니다. \u0026ldquo;무엇이든 빠르게 만들고 시장이 답하게 하라\u0026rdquo; 가 아니라, \u0026ldquo;만들기 전에 스스로를 좁혀라\u0026rdquo; 는 것입니다.\n\u0026ldquo;Constraints collapse the search space.\u0026rdquo;\n이 한 줄이 글 전체의 기둥입니다. 무한한 가능성은 자유처럼 들리지만, 실은 결정 마비와 정체성 부재의 다른 이름입니다. 좋은 제약은 가능한 해법의 집합을 줄여, 남은 공간 안에서 창의성이 압력을 받게 합니다 — 시(詩)의 운율이 의미를 더 정교하게 깎아내는 것과 같은 메커니즘입니다.\nJordan의 회고는 이를 자신의 실패로 증언합니다. 10년 동안 만든 제품들이 너무 복잡했거나, 정체성이 없었거나, 둘 다였습니다. 그가 추출한 3가지 제약은 그 두 실패 모드를 정면으로 겨냥합니다.\n제약 1 — The One Pager 규칙: 모든 아이디어는 한 페이지에 북극성(north star)으로 정리되어야 한다.\n이 한 페이지는 다음 4가지 조건을 만족해야 합니다.\nNon-negotiable — 타협 불가능한 본질만 남긴다 Precise — 모호한 수사를 허락하지 않는다 Ambitious — 야심을 잃지 않는다 Lean — 군더더기를 쳐낸다 핵심은 마지막 조건입니다. 한 페이지에 들어가지 않으면, 그 아이디어는 너무 복잡한 것이고 만들지 말아야 한다. 이는 단순히 문서 작성 가이드가 아니라 킬 스위치입니다. 한 페이지에 압축되지 않는 비전은, 빌드 단계에서는 더 압축되지 않습니다 — 오히려 폭발합니다.\n이 제약의 미덕은 시작 전에 실패를 강제로 드러낸다는 점에 있습니다. 빌드에 한 달을 쓰고 깨닫는 게 아니라, 한 페이지를 쓰는 동안 깨닫게 됩니다.\n제약 2 — Core Technology 규칙: 제품을 떠받치지만, 제품 자체는 아닌 핵심 기술 한 조각을 갖출 것.\nJordan은 이 \u0026ldquo;Core Technology\u0026quot;를 넓게 정의합니다. 방법론, 스킬, 도구, 또는 다른 제품일 수 있습니다. 중요한 것은 형식이 아니라 위치입니다 — 제품의 아래에 깔려 있어야 합니다.\n여기서 가장 강력한 통찰은 이 한 줄입니다.\n\u0026ldquo;Products pivot in direction while core tech remains constant and compounding.\u0026rdquo;\n제품은 시장과 부딪히면서 방향을 바꿉니다. 한 번도 피벗하지 않은 제품은 거의 존재하지 않습니다. 그런데 피벗할 때마다 처음부터 다시 시작한다면, 10년 후에도 0년차 창업자입니다.\n핵심 기술은 그 사이에서 누적되는 자산입니다. 제품이 A에서 B로 피벗해도, 핵심 기술은 그대로 살아남아 B에서도 작동합니다. 그래서 핵심 기술에 투자한 시간은 비선형적 이득을 만듭니다 — 긴 시간 지평에서 복리로 쌓입니다.\n이는 인디 해커가 자주 빠지는 함정에 대한 해독제이기도 합니다. \u0026ldquo;이번 제품이 안 되면 다음 제품\u0026rdquo; 이라는 패턴은 핵심 기술 없이 반복되면 그저 무작위 시도의 무한 루프입니다. 핵심 기술이 있으면, 실패한 제품도 다음 제품의 발판이 됩니다.\n제약 3 — Product Constraint 규칙: 제품의 전면에 드러나는 자기만의 제약을 정의하라. 사용자가 직접 보고 상호작용하는 명백한 제약 — 그것이 제품의 정체성을 만든다.\n이 제약은 앞의 두 개와 결이 다릅니다. 앞의 둘이 창작자를 향한 제약이라면, 이건 사용자에게 보이는 제약입니다.\nJordan의 표현을 그대로 옮기면, 이 제약은 \u0026ldquo;front and centre\u0026rdquo; — 전면에 있어야 하고, 사용자가 그것과 상호작용해야 합니다. 숨기는 것이 아니라 드러내는 제약입니다.\n왜 그래야 할까요? 정체성 때문입니다. 모든 기능을 다 하는 제품은 아무 정체성도 없는 제품과 같습니다. 가시적 제약은 이 제품이 무엇이고 무엇이 아닌지를 한 번에 전달합니다.\n전형적인 예시들 — Twitter의 280자, Vine의 6초, Are.na의 비알고리즘 큐레이션, Things의 todo 외 거부 — 은 모두 이 패턴입니다. 제약 자체가 마케팅 카피이고, 제약 자체가 사용자가 그 제품을 선택하는 이유입니다.\n세 제약을 묶는 논리 세 제약은 각각 다른 실패 모드를 막습니다.\n제약 막는 실패 모드 작동 시점 One Pager 복잡성으로 인한 좌초 시작 전 Core Technology 피벗할 때마다 0에서 다시 시작 빌드/운영 전 구간 Product Constraint 정체성 부재로 인한 시장 무관심 출시 후 Jordan이 10년간 겪은 두 가지 실패 — 너무 복잡 과 정체성 없음 — 은 정확히 이 세 제약 중 하나가 빠졌을 때 발생하는 결과입니다. One Pager가 없으면 복잡성이 통제되지 않고, Product Constraint가 없으면 정체성이 생기지 않으며, Core Technology가 없으면 두 실패 사이를 무한히 오갑니다.\n한국어 독자를 위한 함의 이 글의 메시지는 한국 인디/스타트업 환경에서 더 날카롭게 작동합니다.\n\u0026ldquo;일단 만들고 본다\u0026quot;의 한계 — MVP 컬트는 제약 없는 빌드를 미덕처럼 다루지만, Jordan의 진단은 그 반대입니다. 빌드 전에 자기 검열을 강제할 수 있는 사람만이 10년 후에도 같은 자리에 있지 않습니다. 피벗의 진짜 의미 — 피벗은 제품 방향의 변경이지 자산의 폐기가 아닙니다. 핵심 기술이 있는 사람의 피벗과 없는 사람의 피벗은 완전히 다른 사건입니다. 정체성은 빼기에서 온다 — 무엇을 하지 않는지를 명시한 제품만이 무엇을 하는지가 분명해집니다. Product Constraint는 마케팅 이전에 제품 설계의 의사결정 기준입니다. 결론 — 빌드하기 전에 통과시켜야 하는 3개의 게이트 Jordan Lord의 글은 짧지만, 자기 작업에 적용 가능한 체크리스트로 환원됩니다.\n이 아이디어를 한 페이지로 압축할 수 있는가? (못한다면 빌드 금지) 이 제품 아래에, 제품이 피벗해도 살아남는 핵심 기술이 있는가? 사용자에게 전면으로 드러나는, 이 제품만의 가시적 제약이 있는가? 세 질문에 모두 예 라고 답할 수 없다면, 빌드를 시작하지 말아야 합니다. 최고의 엔지니어링은 항상 제약에서 태어난다 — 이 명제는 코드의 추상화에만 적용되는 것이 아니라, 제품 그 자체에도 그대로 적용됩니다.\n관련 포스트 잃어버린 게으름의 위험 — Bryan Cantrill이 LLM 시대에 다시 꺼내는 프로그래머의 미덕 에이전트는 구조와 유연성 사이에서 고를 수 없다 — Python 캠프 vs Markdown 캠프의 가짜 선택지 ","wordCount":889,"tags":["Jordan Lord","Constraints","Product Design","One Pager","Core Technology","Product Identity","Indie Hacker","제약기반설계","제품철학"],"categories":["Product"],"frameworks":["Constraint-Driven Design","North Star Definition","Compounding Core Tech"],"mental_models":["Search Space Collapse","Pivot vs Foundation","Identity-Forming Constraint"],"philosophy_type":"decision-making","schema_type":"HowTo","actionable":true,"priority":"high","key_points":["제약은 창의성의 적이 아니라 탐색 공간을 좁혀 혁신적 해법을 강제하는 장치다","One Pager — 모든 아이디어는 한 페이지로 압축되어야 하며, 넘어가면 너무 복잡한 것이므로 만들지 말 것","Core Technology — 제품을 떠받치지만 제품 자체는 아닌 것. 제품은 피벗해도 핵심 기술은 누적되어 비선형적 이득을 만든다","Product Constraint — 사용자가 직접 보고 만지는 가시적 제약이 곧 제품의 정체성이다","Jordan Lord은 이 3가지가 없는 상태에서 10년간 만든 제품들이 모두 실패했다고 회고한다"],"related":["posts/peril-of-laziness-lost","posts/agents-cant-choose-structure-flexibility"]},{"title":"양자화 비주얼 가이드 — Maarten Grootendorst가 그림으로 푸는 LLM 경량화","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/visual-guide-to-quantization/","section":"posts","date":"2026-04-28T13:00:00+09:00","lastmod":"2026-04-28T13:00:00+09:00","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)까지 50여 장 시각화의 핵심을 한 글에 압축한다.","summary":"Maarten Grootendorst가 Exploring Language Models 뉴스레터에 공개한 A Visual Guide to Quantization은 LLM 양자화의 직관을 50여 장의 커스텀 비주얼로 풀어낸 글입니다. 이 글은 그 핵심을 한국어로 정리합니다 — 숫자 표현의 기초부터 FP32→INT4의 매핑 수학, GPTQ·GGUF의 작동 원리, 그리고 1-bit/1.58-bit BitNet까지.\n원문: A Visual Guide to Quantization — Maarten Grootendorst\nTL;DR 요약 문제: 70B 모델을 FP32(full-precision)로 로딩하면 약 280GB. 비트 수가 많을수록 표현 범위(dynamic range)와 인접 값 간 거리(precision)가 동시에 커진다. 데이터 타입: FP32 → FP16(범위 좁음) → BF16(FP16과 같은 16비트지만 FP32 수준 범위, 딥러닝 표준) → INT8(1/4 비트, 정수 연산) → INT4까지. 매핑 방식: Symmetric(absmax) 은 0 중심 대칭, Asymmetric(zero-point) 는 zero-point z를 두고 비대칭 매핑. Outlier 처리에는 clipping이 필요하고, 범위 선택은 calibration(percentile/MSE/KL)으로 결정한다. PTQ vs QAT: PTQ는 학습 후 양자화(빠르고 단순), QAT는 학습 중 fake quant로 양자화 노이즈를 학습 → INT4 같은 저비트 영역에서 PTQ보다 우월. 4-bit 영역: GPTQ는 inverse-Hessian으로 weight 중요도를 가중해 양자화 오차를 분배(GPU). GGUF는 super/sub 블록의 이중 스케일 양자화로 CPU 오프로딩을 가능하게 한다(llama.cpp). 1-bit 시대: BitNet은 weights를 {-1, 1}로, BitNet b1.58은 {-1, 0, 1} ternary로. 0의 추가가 곱셈을 덧셈으로 환원하고 feature filtering을 가능하게 한다 — \u0026ldquo;13B BitNet b1.58은 3B FP16 LLM보다 효율적\u0026rdquo;. Part 1. LLM의 \u0026ldquo;문제점\u0026rdquo; LLM은 수십억 개 파라미터(주로 weights)와 추론 중 만들어지는 activations로 구성됩니다. 가능한 적은 비트로 값을 표현해야 메모리와 연산 비용을 줄일 수 있습니다.\n","content":"Maarten Grootendorst가 Exploring Language Models 뉴스레터에 공개한 A Visual Guide to Quantization은 LLM 양자화의 직관을 50여 장의 커스텀 비주얼로 풀어낸 글입니다. 이 글은 그 핵심을 한국어로 정리합니다 — 숫자 표현의 기초부터 FP32→INT4의 매핑 수학, GPTQ·GGUF의 작동 원리, 그리고 1-bit/1.58-bit BitNet까지.\n원문: A Visual Guide to Quantization — Maarten Grootendorst\nTL;DR 요약 문제: 70B 모델을 FP32(full-precision)로 로딩하면 약 280GB. 비트 수가 많을수록 표현 범위(dynamic range)와 인접 값 간 거리(precision)가 동시에 커진다. 데이터 타입: FP32 → FP16(범위 좁음) → BF16(FP16과 같은 16비트지만 FP32 수준 범위, 딥러닝 표준) → INT8(1/4 비트, 정수 연산) → INT4까지. 매핑 방식: Symmetric(absmax) 은 0 중심 대칭, Asymmetric(zero-point) 는 zero-point z를 두고 비대칭 매핑. Outlier 처리에는 clipping이 필요하고, 범위 선택은 calibration(percentile/MSE/KL)으로 결정한다. PTQ vs QAT: PTQ는 학습 후 양자화(빠르고 단순), QAT는 학습 중 fake quant로 양자화 노이즈를 학습 → INT4 같은 저비트 영역에서 PTQ보다 우월. 4-bit 영역: GPTQ는 inverse-Hessian으로 weight 중요도를 가중해 양자화 오차를 분배(GPU). GGUF는 super/sub 블록의 이중 스케일 양자화로 CPU 오프로딩을 가능하게 한다(llama.cpp). 1-bit 시대: BitNet은 weights를 {-1, 1}로, BitNet b1.58은 {-1, 0, 1} ternary로. 0의 추가가 곱셈을 덧셈으로 환원하고 feature filtering을 가능하게 한다 — \u0026ldquo;13B BitNet b1.58은 3B FP16 LLM보다 효율적\u0026rdquo;. Part 1. LLM의 \u0026ldquo;문제점\u0026rdquo; LLM은 수십억 개 파라미터(주로 weights)와 추론 중 만들어지는 activations로 구성됩니다. 가능한 적은 비트로 값을 표현해야 메모리와 연산 비용을 줄일 수 있습니다.\n수치 표현의 기초 값은 보통 부동소수점(IEEE-754 표준)으로 표현되며, 비트는 세 부분으로 나뉩니다:\nSign: 부호 (1비트) Exponent: 지수 Fraction (Mantissa): 가수 비트 수가 많을수록 정밀도가 높습니다. 표현 가능한 값의 구간을 dynamic range, 인접한 두 값 사이의 거리를 precision이라고 부릅니다.\n메모리 제약 70B 파라미터 모델을 FP32로 로딩하면 약 280GB가 필요하다.\n8비트 = 1바이트라는 단순 산수가 LLM에서는 살벌한 비용으로 돌아옵니다. 그래서 정밀도를 유지하면서 비트 수를 줄이는 양자화가 필요해집니다.\nPart 2. 양자화 입문 양자화는 고비트(예: FP32) → 저비트(예: INT8) 로 정밀도를 줄이는 작업입니다. 이미지에 8가지 색만 쓰면 거칠어지듯, 정밀도 손실(granularity loss)이 발생합니다.\n일반적인 데이터 타입 타입 비트 특징 FP32 32 full-precision, 학습 기본 FP16 16 half-precision, 범위가 FP32보다 훨씬 좁음 BF16 16 FP32와 유사한 범위(가수↓, 지수↑), 딥러닝 표준 INT8 8 정수 연산, FP32 대비 1/4 비트 INT4 4 더 공격적인 압축 하드웨어에 따라 정수 연산이 부동소수점 연산보다 빠를 수 있고, 일반적으로 비트 수가 적을수록 연산이 빨라집니다.\n비트를 줄일 때 핵심은 FP32의 전체 범위를 INT8로 매핑할 필요가 없다는 점입니다. 실제 모델 파라미터의 분포 범위만 INT8로 매핑하면 됩니다.\nSymmetric Quantization — absmax 0을 중심으로 대칭 매핑. 대표 예가 absolute maximum(absmax) 양자화입니다.\n스케일 인자: s = (2^(b-1) - 1) / α, 여기서 α = max(|x|) 양자화: x_q = round(s · x) 역양자화: x = x_q / s 예를 들어 3.08과 3.02가 INT8에서 둘 다 36으로 매핑되어 구분이 사라지면, 이를 양자화 오차(quantization error) 라고 부릅니다. 비트가 줄수록 오차는 일반적으로 커집니다.\nAsymmetric Quantization — zero-point 0 기준 비대칭. zero-point 양자화가 대표적입니다. 최솟값(β)·최댓값(α)을 INT8 범위 [-128, 127]로 매핑합니다.\n스케일: s = (2^b - 1) / (α - β) zero-point z를 별도로 계산해 0의 위치를 시프트 분포가 한쪽으로 치우친 경우(예: ReLU 후 활성)에 유리 구분 Symmetric Asymmetric 0의 위치 항상 정수 0에 매핑 shift된 zero-point z 범위 [-α, α] 대칭 [β, α] 비대칭 계산 복잡도 단순 z 계산 추가 필요 적합 0 중심 대칭 분포 치우친 분포 Range Mapping과 Clipping outlier(이상치) 가 하나라도 있으면 전체 범위를 매핑할 때 작은 값들이 모두 같은 정수에 뭉개집니다. 동적 범위를 [-5, 5]처럼 임의로 잘라내는 clipping이 해법입니다 — 비-이상치의 양자화 오차는 줄지만 이상치의 오차는 커지는 트레이드오프가 발생합니다.\nCalibration — 범위 고르는 법 범위 선택 과정 자체를 calibration이라 부릅니다. 오차를 최소화하면서 가능한 많은 값을 포함하는 범위를 찾는 작업입니다. 적용 대상에 따라 방식이 달라집니다.\nWeights \u0026amp; Biases (정적): Llama 3의 ~20GB가 거의 weights입니다. bias는 수가 적어 INT16 등 고정밀 유지가 흔합니다. 캘리브레이션 방법:\n입력 범위의 percentile 수동 선택 원본–양자화 weights의 MSE 최소화 KL-divergence(엔트로피) 최소화 Activations (동적): 입력마다 변하므로 추론 중에만 알 수 있어 어렵습니다. 캘리브레이션 시점에 따라 두 가지 갈래로 나뉩니다:\nPTQ (Post-Training Quantization): 학습 후 양자화 QAT (Quantization-Aware Training): 학습 중 양자화 학습 Part 3. PTQ — 학습 후 양자화 가중치는 symmetric/asymmetric으로 그대로 양자화. 활성에는 두 방식이 있습니다.\nDynamic Quantization 입력이 hidden layer를 통과할 때마다 활성 분포를 수집하여 s, z 계산 레이어마다 다른 s, z 사용 더 정확하지만 추론 시 계산 오버헤드 증가 Static Quantization 사전에 calibration dataset으로 모든 활성 분포를 수집 추론 시 s, z를 재계산하지 않고 전역적으로 사용 빠르지만 정확도는 약간 낮음 4-bit 영역 — GPTQ vs GGUF 8비트 미만으로 가면 양자화 오차가 급격히 커집니다. HuggingFace에서 자주 보는 두 방법:\nGPTQ — GPU에서 풀모델 실행 비대칭 양자화, 레이어 단위로 독립적으로 처리 레이어 weights를 inverse-Hessian(loss의 2차 미분)으로 변환 → 각 weight의 (역)중요도. Hessian 값이 작은 weight일수록 중요 첫 행 weight를 양자화 → 역양자화 → 양자화 오차 q 계산 이 오차에 inverse-Hessian을 곱해 다른 weights에 분배(가중치 보정). 예: x_2 += q · h_2 모든 weight를 양자화할 때까지 반복 추가 트릭: Hessian dampening, lazy batching, Cholesky 사전계산 추론 속도 최적화 변형으로 EXL2 추천 weight들은 보통 서로 연관되어 있으므로, 한 weight의 양자화 오차를 관련 weights에 분배하면 네트워크의 전체 함수 형태가 보존됩니다.\nGGUF — CPU 오프로딩 llama.cpp 포맷. CPU+GPU 혼합 실행 가능 레이어 weights를 \u0026ldquo;super\u0026rdquo; 블록 / \u0026ldquo;sub\u0026rdquo; 블록으로 분할 각 sub 블록은 absmax로 양자화: W_q = round(W · s_sub) sub 블록의 scale s_sub는 super 블록의 scale s_super 로 다시 양자화 — 이중 스케일(block-wise) 양자화 2-bit / 4-bit / 6-bit 등 다양한 양자화 레벨, 일부 타입은 zero-point 조정용 최솟값 m도 함께 양자화 Part 4. QAT — 학습 중 양자화 학습 중에 \u0026ldquo;fake\u0026rdquo; quantization 노드를 삽입합니다: weights를 INT4로 양자화 → 다시 FP32로 역양자화. 모델이 양자화 노이즈를 고려하면서 학습/loss 계산/weight 업데이트를 수행합니다.\nQAT의 핵심은 손실 평면에서 \u0026ldquo;wide\u0026rdquo; minima(넓은 골짜기)를 찾도록 유도한다는 점입니다. \u0026ldquo;narrow\u0026rdquo; minima는 양자화 오차가 더 크기 때문입니다.\n시나리오 FP32에서의 손실 INT4에서의 손실 PTQ 낮음 높음 (양자화 오차 누적) QAT 약간 높음 낮음 (목표 정밀도에 적응) 즉, FP32에서는 PTQ가 더 좋아 보이지만 INT4에서는 QAT가 더 낮은 손실을 기록합니다.\nThe Era of 1-bit LLMs — BitNet 가중치를 -1 또는 1의 1-bit로 표현. Transformer의 linear layer를 BitLinear로 교체합니다.\nBitLinear 동작 단계:\nWeight 양자화: 학습 중에는 INT8로 저장, signum 함수로 1-bit화. 분포를 0 중심으로 시프트한 뒤 0 미만은 -1, 이상은 1. 평균 절대값 β를 추적 Activation 양자화: absmax로 FP16 → INT8. 최대 절대값 α 추적 Dequantization: 출력 활성을 {α, β}로 스케일 복원 모델이 클수록(\u0026gt;30B) 1-bit와 FP16의 성능 격차가 좁혀집니다. 다만 작은 모델에서의 갭은 여전히 큽니다.\nBitNet 1.58b — \u0026ldquo;All LLMs are in 1.58 Bits\u0026rdquo; 가중치를 {-1, 0, 1} 의 ternary로 확장. 가능한 상태 3개이므로 비트 수는 log2(3) ≈ 1.58 bit.\n0의 힘 — 곱셈 없는 행렬 곱 ternary 가중치는 다음 의미를 갖습니다:\n1: 더한다 0: 무시한다 (= feature filtering) -1: 뺀다 행렬 곱이 곱셈 없이 덧셈만으로 구현된다. 0의 추가는 단순한 표현력 확장이 아니라 연산 자체의 환원이다.\n양자화 방식 Weight: absmean 양자화 (절대 평균 α로 스케일 후 -1, 0, 1 중 하나로 반올림) Activation: BitNet과 동일한 absmax, 다만 [0, 2^(b-1)] 대신 [-2^(b-1), 2^(b-1)] 로 스케일 결과 \u0026ldquo;13B BitNet b1.58은 지연시간·메모리·에너지 측면에서 3B FP16 LLM보다 효율적이다.\u0026rdquo;\n정리 — 어떤 방법을 언제 쓰나 방법 비트 시점 적합한 환경 FP16/BF16 16 학습/추론 표준 GPU 학습 PTQ Static (INT8) 8 학습 후 빠른 배포, 약간의 정확도 손실 허용 PTQ Dynamic (INT8) 8 추론 시 정확도 중시, 약간의 추론 오버헤드 허용 GPTQ (4-bit) 4 학습 후 GPU 추론, Hessian 기반 보정 GGUF (2~6 bit) 2–6 학습 후 CPU/Apple Silicon, llama.cpp QAT (4-bit) 4 학습 중 정확도 우선, 재학습 비용 허용 BitNet b1.58 1.58 학습 처음부터 차세대 효율적 LLM 양자화는 \u0026ldquo;수를 더 적은 비트로 표현해 LLM을 가볍게\u0026rdquo; 만드는 기술입니다. 핵심은 두 가지로 압축됩니다:\n표현 범위 선택 — calibration이 모든 것을 결정한다 오차 보정 전략 — GPTQ의 Hessian 분배, GGUF의 block-wise 스케일, BitNet의 학습 단계 통합 미래의 LLM이 얼마나 작아질 수 있을지는 — 0이라는 글자가 알려주듯 — 양자화 자체보다 표현의 환원에 달려 있을지도 모릅니다.\n참고 자료 LLM.int8() — HuggingFace 블로그, 논문 Embedding Quantization — HuggingFace Transformer Math 101 — EleutherAI VRAM 계산기: NyxKrage Space, vram.asmirnov.xyz GPTQ 해설 YouTube Hands-On Large Language Models (Maarten Grootendorst \u0026amp; Jay Alammar) 원논문:\nFrantar, E. et al. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers, arXiv:2210.17323 (2022) Wang, H. et al. BitNet: Scaling 1-bit Transformers for Large Language Models, arXiv:2310.11453 (2023) Ma, S. et al. The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits, arXiv:2402.17764 (2024) Dettmers, T. et al. QLoRA: Efficient Finetuning of Quantized LLMs, NeurIPS 36 (2024) ","wordCount":1327,"tags":["LLM","Quantization","양자화","GPTQ","GGUF","BitNet","QAT","PTQ","FP16","BF16","INT8","INT4","llama.cpp","Maarten Grootendorst"],"categories":["AI"],"frameworks":["Quantization","Symmetric/Asymmetric Mapping","Block-wise Quantization","Quantization-Aware Training"],"mental_models":["Dynamic Range vs Precision","Quantization Error Redistribution","Wide vs Narrow Minima"],"philosophy_type":"engineering-tradeoffs","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["70B 모델은 FP32로 280GB가 필요하다 — 양자화는 모델당 비트 수를 줄여 메모리·연산을 줄이지만 정밀도 손실이 트레이드오프다","Symmetric(absmax)은 0 중심 대칭, Asymmetric(zero-point)은 min/max를 따로 매핑해 zero-point z를 둔다","Outlier가 있으면 전체 범위 매핑 시 작은 값들이 같은 정수로 뭉개지므로 clipping과 calibration(percentile/MSE/KL)이 필수","PTQ는 학습 후, QAT는 학습 중 fake quant로 양자화 노이즈를 학습 — QAT는 wide minima를 찾아 INT4 영역에서 PTQ보다 손실이 낮다","GPTQ는 inverse-Hessian으로 가중치 중요도를 가중해 양자화 오차를 다른 weights로 분배하고, GGUF는 super/sub 블록의 이중 스케일로 CPU 오프로딩을 가능하게 한다","BitNet은 weights를 {-1, 1} 1-bit로, BitNet b1.58은 {-1, 0, 1} ternary(log2(3)≈1.58 bit)로 — 0 추가는 곱셈을 덧셈으로 환원하고 feature filtering을 가능하게 한다"],"related":["posts/hidden-llm-api-costs","posts/components-of-a-coding-agent"]},{"title":"에이전틱 엔지니어링 매니지먼트 — EM 역할에 에이전트를 적용하면 무엇이 보이는가","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-engineering-management/","section":"posts","date":"2026-04-28T00:05:00+09:00","lastmod":"2026-04-28T00:05:00+09:00","description":"Peter Szász가 제안하는 사고 실험 — 엔지니어링 매니저(EM) 역할을 Execution·Team Dynamics·Personal Development로 분해하고, 자율성 적합도(Autonomy Fitness)와 신뢰 경사(Trust Gradient)라는 두 축으로 어디까지 에이전트에게 맡길 수 있는지 평가한다.","summary":"Peter Szász가 \u0026ldquo;엔지니어링 매니저(EM) 역할에 에이전트를 적용하면 어떻게 될까?\u0026ldquo;라는 사고 실험을 통해 기회와 리스크를 동시에 드러내는 글입니다. 코드 완성에서 에이전틱 엔지니어링으로 넘어가는 흐름이 매니지먼트 영역까지 확장될 수 있는지 탐색합니다.\n원문: Agentic Engineering Management\nTL;DR 요약 에이전트 정의: 사용자 프롬프트로부터 목표 달성까지 \u0026ldquo;도구 호출 → LLM 평가\u0026rdquo; 루프를 자율적으로 반복하는 시스템. EM 분해: Execution(실행), Team Dynamics(팀 다이내믹스), Personal Development(개인 성장) 3축. 위로 갈수록 사람과의 거리는 가깝고 리스크는 높아진다. 두 평가 축: ① Autonomy Fitness — 반복성·데이터 풍부도·모호성·가역성. ② Trust Gradient — 개인적일수록 신뢰 리스크 증가. 하네스 설계: confidence threshold, dry-run, blast radius limit, reversibility, audit trail로 자율성 강도 조절. 결론: 신뢰가 깨지면 매니지먼트는 무너진다. 그러나 하네스 설계가 없으면 EM은 \u0026ldquo;풀타임 에이전트 베이비시터\u0026quot;가 된다. 핵심 정의 Agent: 초기 프롬프트에서 시작해 목표가 충족될 때까지 도구 호출과 LLM 평가를 반복하는 루프. Engineering Management: 비즈니스 목표에 부합하는 결과(outcome)를 전달하도록 팀을 이끄는 일. EM의 일은 세 가지로 분해된다:\n","content":"Peter Szász가 \u0026ldquo;엔지니어링 매니저(EM) 역할에 에이전트를 적용하면 어떻게 될까?\u0026ldquo;라는 사고 실험을 통해 기회와 리스크를 동시에 드러내는 글입니다. 코드 완성에서 에이전틱 엔지니어링으로 넘어가는 흐름이 매니지먼트 영역까지 확장될 수 있는지 탐색합니다.\n원문: Agentic Engineering Management\nTL;DR 요약 에이전트 정의: 사용자 프롬프트로부터 목표 달성까지 \u0026ldquo;도구 호출 → LLM 평가\u0026rdquo; 루프를 자율적으로 반복하는 시스템. EM 분해: Execution(실행), Team Dynamics(팀 다이내믹스), Personal Development(개인 성장) 3축. 위로 갈수록 사람과의 거리는 가깝고 리스크는 높아진다. 두 평가 축: ① Autonomy Fitness — 반복성·데이터 풍부도·모호성·가역성. ② Trust Gradient — 개인적일수록 신뢰 리스크 증가. 하네스 설계: confidence threshold, dry-run, blast radius limit, reversibility, audit trail로 자율성 강도 조절. 결론: 신뢰가 깨지면 매니지먼트는 무너진다. 그러나 하네스 설계가 없으면 EM은 \u0026ldquo;풀타임 에이전트 베이비시터\u0026quot;가 된다. 핵심 정의 Agent: 초기 프롬프트에서 시작해 목표가 충족될 때까지 도구 호출과 LLM 평가를 반복하는 루프. Engineering Management: 비즈니스 목표에 부합하는 결과(outcome)를 전달하도록 팀을 이끄는 일. EM의 일은 세 가지로 분해된다:\n영역 내용 Execution 프로세스, 기술적 작업, 전달 흐름 관리 Team Dynamics 팀 내부 협업·프로세스·갈등 조정 Personal Development 1:1, 피드백, 성과 관리, 채용, 온보딩 두 가지 평가 축 1. Autonomy Fitness (자율성 적합도) 업무가 에이전트에게 얼마나 잘 어울리는지를 결정하는 네 가지 지표:\nRepetitive(반복적) — 같은 패턴이 자주 반복되는가 Data-rich(데이터 풍부) — 결정에 필요한 신호가 시스템에 충분히 있는가 Low-ambiguity(모호성 낮음) — \u0026ldquo;옳은 답\u0026quot;이 비교적 명확한가 Reversible(가역적) — 잘못 실행했을 때 되돌릴 수 있는가 네 조건이 모두 강할수록 에이전트가 자율적으로 처리하기에 적합하다.\n2. Trust Gradient (신뢰 경사) 상호작용이 개인적일수록 신뢰 리스크가 커진다.\n영역 신뢰 리스크 Execution 낮음 — 시스템·프로세스 중심 Team Dynamics 중간 — 팀 내부 정치·문화 영향 Personal Development 가장 높음 — 1:1 신뢰 자체가 자산 Harness — 자율성 통제 장치 자율성 적합도와 신뢰 경사에 따라 \u0026ldquo;하네스(harness)\u0026ldquo;의 조임 강도를 다르게 설계해야 한다. 핵심 도구는 다음과 같다:\nConfidence threshold — 고신뢰·저위험 결정은 자율 실행, 불확실하거나 고위험은 사람에게 에스컬레이션. Dry-run mode — 에이전트가 행동을 초안으로 만들어 두고, 사람이 승인 후 실행. Blast radius limit — 에이전트가 할 수 있는 일의 하드 제약. 예: \u0026ldquo;댓글은 가능하지만 일정 약속은 불가\u0026rdquo;, \u0026ldquo;은 가능하지만 팀 입장 대변은 불가\u0026rdquo;. Reversibility — 되돌릴 수 있는 영역에서만 자율 행동을 허용. Audit trail — 모든 행동의 감사 로그를 남겨 사후 검증 가능하게. 적용 매핑 — 어디까지 맡길 수 있는가 영역 자율성 적합도 신뢰 리스크 권장 하네스 Execution (스탠드업 , 티켓 분류, 릴리즈 노트) 높음 낮음 느슨한 하네스 — 자동 실행 + 감사 로그 Team Dynamics (회고 정리, 갈등 패턴 감지) 중간 중간 중간 — dry-run + 사람 승인 Personal Development (피드백, 1:1, 성과 평가) 낮음 높음 매우 타이트 — 보조 도구로 한정, 의사결정은 사람 핵심 메시지 매니저 업무의 본질은 신뢰이며, 한 번 깨지면 모든 것이 무너진다. 작은 단계, 투명성, 팀원과의 협업이 필수. 그러나 잘 설계된 하네스로 적절한 영역에 자율성을 부여하지 않으면, EM은 결국 **\u0026ldquo;풀타임 에이전트 베이비시터\u0026rdquo;**로 전락할 수 있다. AEM은 EM을 대체하기 위한 청사진이 아니라, 어디에 기회와 위험이 있는지 명확히 보기 위한 사고 실험이다. 결론 에이전틱 엔지니어링 매니지먼트는 \u0026ldquo;AI에게 매니지먼트를 맡기자\u0026quot;는 주장이 아니라, 자율성 적합도 × 신뢰 경사라는 격자 위에서 EM 업무를 다시 보는 렌즈다. 격자에 따라 하네스를 다르게 설계하면, 낮은 신뢰 리스크 영역에서는 에이전트가 EM의 역량을 증폭하고, 높은 리스크 영역에서는 사람의 판단을 보호할 수 있다.\n","wordCount":496,"tags":["AI","에이전트","엔지니어링매니지먼트","리더십","하네스","자율성"],"categories":["AI"],"frameworks":["Systems Thinking","First Principles"],"mental_models":["Trust Gradient","Blast Radius"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"medium","key_points":["EM 업무는 Execution·Team Dynamics·Personal Development 세 축으로 분해되며 각 축의 신뢰 리스크가 다르다","자율성 적합도는 ① 반복성 ② 데이터 풍부 ③ 모호성 ④ 가역성으로 평가된다","신뢰 경사: Execution(낮음) → Team Dynamics(중간) → Personal Development(가장 높음)","하네스(harness)의 강도는 confidence threshold·dry-run·blast radius·audit trail로 조절한다","잘 설계된 하네스 없이는 EM이 풀타임 에이전트 베이비시터로 전락할 위험이 있다"],"related":["posts/anatomy-of-an-agent-harness","posts/agent-harness-engineering","posts/probabilistic-engineering-24-7-employee"]},{"title":"오늘의 하네스는 내일의 프롬프트 — 모델이 결국 하네스를 먹는다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/todays-harness-is-tomorrows-prompt/","section":"posts","date":"2026-04-27T23:40:53+09:00","lastmod":"2026-04-27T23:40:53+09:00","description":"Tanay Sai의 'Today's harness is Tomorrow's Prompt' . 2023년 2주짜리 RAG 파이프라인이 1M 토큰 컨텍스트에 통째로 먹힌 자기 경험에서 출발해, 하네스는 모델 한계의 우회로를 아키텍처로 포장한 것이며 유통기한이 점점 짧아진다고 진단한다. 이미 먹힌 사례 3가지(PDF·JSON·OCR)와 지금 짓고 있지만 곧 먹힐 후보 3가지(멀티 에이전트 스웜·브라우저 스크립팅·캐스케이딩 음성 파이프라인)를 짚고, 결론은 '짓지 말라'가 아니라 '버릴 수 있을 만큼 싸게 지어라'다.","summary":"Tanay Sai의 글 입니다. 2023년 PDF 폴더에 대한 영업팀 질의 응대를 위해 2주간 짜낸 RAG 파이프라인 — 청킹·임베딩·벡터 스토어·리랭커 — 이, 오늘은 사용자가 100페이지짜리 PDF 20개를 1M 토큰 컨텍스트에 드롭하고 질문 한 번 던지는 것으로 대체되었다는 자기 고백에서 시작합니다.\n원문: Today\u0026rsquo;s harness is Tomorrow\u0026rsquo;s Prompt — Tanay Sai\nTL;DR 요약 하네스의 정의: 모델이 혼자서는 잘 못하는 일을 하게 만드는 스캐폴딩. 단순한 래퍼 이상으로, 모델이 할 수 있는 일을 측정 가능하게 끌어올리는 구조물. 모든 하네스 = 모델 한계의 우회로. 벡터 스토어는 컨텍스트가 작아서, 파서는 출력이 약간 틀려서, 에이전트 프레임워크는 모델이 계획을 못 해서 존재한다. 이미 먹힌 3가지: PDF 채팅(RAG 파이프라인), 구조화 출력(JSON 베깅 + 정규식), 이미지 읽기(Tesseract OCR + LLM 추측). 곧 먹힐 후보 3가지: 멀티 에이전트 스웜(AutoGen/CrewAI), 브라우저 스크립팅(Playwright + DOM 스냅샷), 캐스케이딩 음성 파이프라인(Whisper → LLM → ElevenLabs). 빌더의 진짜 질문: \u0026ldquo;내 하네스가 얼마나 영리한가\u0026quot;가 아니라 \u0026ldquo;How long until the model eats it?\u0026rdquo;. 결론: 짓지 말라는 게 아니다. 버릴 수 있을 만큼 싸게 지어라(build them cheap enough to throw away). 시작은 자기 고백 — 2주짜리 RAG가 컨텍스트에 먹힌 이야기 In 2023, I spent two weeks wiring up a RAG pipeline so a sales team could ask questions about a folder of PDFs. Chunking, embeddings, a vector store, a reranker. Today, a user drops twenty 100-page PDFs into a 1M-token context window and the model handles it.\n","content":"Tanay Sai의 글 입니다. 2023년 PDF 폴더에 대한 영업팀 질의 응대를 위해 2주간 짜낸 RAG 파이프라인 — 청킹·임베딩·벡터 스토어·리랭커 — 이, 오늘은 사용자가 100페이지짜리 PDF 20개를 1M 토큰 컨텍스트에 드롭하고 질문 한 번 던지는 것으로 대체되었다는 자기 고백에서 시작합니다.\n원문: Today\u0026rsquo;s harness is Tomorrow\u0026rsquo;s Prompt — Tanay Sai\nTL;DR 요약 하네스의 정의: 모델이 혼자서는 잘 못하는 일을 하게 만드는 스캐폴딩. 단순한 래퍼 이상으로, 모델이 할 수 있는 일을 측정 가능하게 끌어올리는 구조물. 모든 하네스 = 모델 한계의 우회로. 벡터 스토어는 컨텍스트가 작아서, 파서는 출력이 약간 틀려서, 에이전트 프레임워크는 모델이 계획을 못 해서 존재한다. 이미 먹힌 3가지: PDF 채팅(RAG 파이프라인), 구조화 출력(JSON 베깅 + 정규식), 이미지 읽기(Tesseract OCR + LLM 추측). 곧 먹힐 후보 3가지: 멀티 에이전트 스웜(AutoGen/CrewAI), 브라우저 스크립팅(Playwright + DOM 스냅샷), 캐스케이딩 음성 파이프라인(Whisper → LLM → ElevenLabs). 빌더의 진짜 질문: \u0026ldquo;내 하네스가 얼마나 영리한가\u0026quot;가 아니라 \u0026ldquo;How long until the model eats it?\u0026rdquo;. 결론: 짓지 말라는 게 아니다. 버릴 수 있을 만큼 싸게 지어라(build them cheap enough to throw away). 시작은 자기 고백 — 2주짜리 RAG가 컨텍스트에 먹힌 이야기 In 2023, I spent two weeks wiring up a RAG pipeline so a sales team could ask questions about a folder of PDFs. Chunking, embeddings, a vector store, a reranker. Today, a user drops twenty 100-page PDFs into a 1M-token context window and the model handles it.\n저자가 2023년에 영업팀의 PDF 질의 응대를 위해 2주에 걸쳐 청킹·임베딩·벡터 스토어·리랭커로 조립한 RAG 파이프라인이, 지금은 100페이지 PDF 20개를 1M 토큰 컨텍스트에 던지고 질문 한 번 하면 끝나는 일이 됐습니다. 이 한 단락이 글 전체의 정서를 정합니다 — 한때 자랑이었던 인프라가 다음 모델 한 번에 기능적으로 사라진다.\n하네스란 무엇인가 — 단순 래퍼가 아니다 A harness is the scaffolding you build around a model to make it do something it can\u0026rsquo;t quite do on its own. More than a wrapper; something that measurably lifts what the model can do.\n하네스는 모델이 혼자서는 잘 못하는 일을 하게 만드는 스캐폴딩입니다. 핵심은 measurably lifts — 모델 능력을 측정 가능한 수준으로 끌어올려야 진짜 하네스라는 것. 단순 API 래퍼는 여기서 빠집니다.\n2023년 RAG 파이프라인에서 PDF와 답변 사이에 있던 모든 것이 하네스였습니다.\n컴포넌트 존재 이유 (= 모델의 한계) 청커(chunker) 컨텍스트 윈도우가 너무 작았다 임베딩 모델 + 벡터 스토어 LLM이 검색을 못 했다 리랭커 검색 결과가 노이즈가 많았다 파서 출력이 약간 틀렸다 에이전트 프레임워크 모델이 계획을 못 했다 Every harness is a workaround for a model limitation, dressed up as architecture.\n모든 하네스는 모델 한계의 우회로를 아키텍처로 포장한 것입니다. 한계가 사라지면 우회로의 존재 이유도 사라집니다.\n가속하는 흡수 곡선 Harnesses have a short shelf life, and it\u0026rsquo;s getting shorter. What took an engineering team a quarter last year is a flag on Gemini call today. What needs a multi-agent framework today is a single call next year.\n작년 한 분기 → 오늘 Gemini 호출의 플래그 한 줄 오늘의 멀티 에이전트 프레임워크 → 내년의 단일 호출 흡수 주기 자체가 짧아지고 있습니다. 빌더에게 이는 곧 ROI 회수 기간이 더 짧아진다는 뜻입니다.\nIf you\u0026rsquo;re building on AI, the question isn\u0026rsquo;t how clever your harness is. It\u0026rsquo;s how long until the model eats it.\n모델이 이미 먹어버린 하네스 3가지 1. Chat with your PDF 옛 버전: 문서를 청크로 자르고, 임베딩 모델을 고르고, Pinecone이나 Milvus를 띄우고, 검색 로직을 짜고, 리랭커를 튜닝하고, 청크 안에 답이 있길 기도한다. 새 버전: 파일 업로드 + 질문. Long context didn\u0026rsquo;t improve RAG so much as make a lot of RAG unnecessary.\n롱 컨텍스트가 RAG를 개선한 게 아니라, 상당 부분을 불필요하게 만들었다. 이게 글의 핵심 뉘앙스입니다.\n2. Structured output 저자가 직접 썼던 프롬프트:\n\u0026ldquo;You are a JSON generating machine. Output only JSON. No markdown. No prose.\u0026rdquo;\n그 다음에 정규식 파서, 그 다음에 trailing comma와 stray backtick을 위한 재시도 루프. 지금은? API 콜의 파라미터 하나. 그리고 그게 작동한다.\n3. Reading an image 영수증 처리의 옛 파이프라인:\nTesseract 같은 OCR을 통과시켜 문자가 번진 벽을 받는다 그걸 LLM에 넘겨 항목을 추측하게 한다 곡선·회전·손글씨에는 그냥 실패한다 오늘의 비전 모델은 OCR 하네스가 필요 없습니다. 그냥 작동합니다(They just work!).\nThese harnesses were the right answer at the time. They\u0026rsquo;re not now!\n그리고 저자가 한 번 더 못을 박습니다 — \u0026ldquo;그 코드는 어딘가의 프로덕션에 아직 남아 있고, 누군가의 돈으로 유지보수되고 있다.\u0026rdquo;\n지금 짓고 있지만 곧 먹힐 후보 3가지 저자가 반대 베팅을 거는 후보들입니다.\n1. 멀티 에이전트 스웜 (AutoGen, CrewAI) 리서처·작가·에디터를 조립하고, 일관된 산출물이 떨어질 때까지 그들의 대화를 오케스트레이션하는 패턴. 가끔 작동하지만, 느리고 디버깅이 어렵습니다.\nReasoning models that plan and revise in a single inference are already eating the easier cases.\n단일 추론 안에서 계획하고 수정하는 추론 모델이 쉬운 케이스부터 먹기 시작했습니다.\n2. 에이전트용 브라우저 스크립팅 LLM에 Playwright를 물리고, DOM 스냅샷을 먹이고, 셀렉터를 고르게 하고, 사이트가 안 바뀌길 기도하는 방식.\nComputer-use models that operate at the screen level are shipping now. When \u0026ldquo;log in and pull the last ten invoices\u0026rdquo; is a single call, the scripting layer stops being a product.\n화면 수준에서 동작하는 컴퓨터 유즈 모델이 출시되고 있습니다. \u0026ldquo;로그인하고 최근 인보이스 10개 가져와\u0026quot;가 단일 호출이 되는 순간, 스크립팅 레이어는 제품이기를 멈춥니다.\n3. 캐스케이딩 음성 파이프라인 Whisper → STT LLM → 응답 생성 ElevenLabs → TTS 3홉이고, 모든 핸드오프마다 모델이 쓸 수 있었을 감정 정보가 깎여나갑니다.\nNative audio-to-audio models keep tone and timing in the same representation.\n네이티브 audio-to-audio 모델은 톤과 타이밍을 같은 표현 공간에서 유지합니다. 캐스케이드는 그래서 흡수 후보 1순위입니다.\n그럼 하네스를 짓지 말라는 건가? Build them. I still am.\n짓는다. 저자도 여전히 짓고 있습니다. 2023년의 RAG 파이프라인은 컨텍스트 윈도우에 먹히기 전까지 2년쯤 제 몫을 했고, 지금 짓는 것들은 그보다 짧게 살 거라고 인정합니다.\nThe job isn\u0026rsquo;t to stop building harnesses. It\u0026rsquo;s to build them cheap enough to throw away.\n이 글의 진짜 결론은 여기입니다.\n하지 말 일: 하네스 자체를 영구 자산처럼 다루는 것. 할 일: 버릴 수 있을 만큼 싸게 짓는 것(build them cheap enough to throw away). 정리 하네스 = 모델 한계의 우회로를 아키텍처로 포장한 것. 한계가 사라지면 우회로도 사라진다. 이미 먹힌 3: PDF 채팅(RAG), 구조화 출력(JSON), 이미지 OCR. 곧 먹힐 3: 멀티 에이전트 스웜, 브라우저 스크립팅, 3홉 음성 파이프라인. 새 결정 기준: \u0026ldquo;How clever is my harness?\u0026rdquo; 대신 \u0026ldquo;How long until the model eats it?\u0026rdquo;. 실무 지침: 하네스는 짓되, 던져버릴 수 있을 만큼 싸게 지어라. 비용/유통기한이 맞는 한에서만 짓는다. Today\u0026rsquo;s harness is tomorrow\u0026rsquo;s prompt.\n","wordCount":996,"tags":["AI","하네스","LLM","RAG","구조화 출력","비전 모델","멀티 에이전트","브라우저 에이전트","음성 AI","Tanay Sai"],"categories":["AI"],"frameworks":["Harness Engineering","Workaround Decay","Throwaway Architecture"],"mental_models":["Capability Absorption","Scaffolding-as-Liability","Disposable Infrastructure"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["하네스 = 모델이 혼자 못 하는 일을 하게 만드는 스캐폴딩. 단순 래퍼가 아니라 모델 능력을 측정 가능하게 끌어올리는 구조물","저자의 2023년 사례: 2주에 걸쳐 청킹·임베딩·벡터스토어·리랭커로 짠 RAG 파이프라인이 오늘은 '1M 토큰 컨텍스트에 PDF 20×100페이지 드롭 + 질문' 한 번으로 대체됨","모든 하네스는 모델 한계의 우회로다 — 벡터스토어는 컨텍스트가 작아서, 파서는 출력이 약간 틀려서, 에이전트 프레임워크는 모델이 계획을 못해서 존재한다","이미 먹힌 사례 3가지: PDF 채팅(롱 컨텍스트), JSON 베깅+정규식(structured output 파라미터), OCR+LLM 영수증 파이프라인(네이티브 비전)","지금 짓고 있지만 곧 먹힐 후보 3가지: 멀티 에이전트 스웜(AutoGen/CrewAI) → 단일 추론 reasoning 모델, Playwright DOM 스크립팅 → 컴퓨터 유즈 모델, Whisper+LLM+ElevenLabs 3홉 음성 → 네이티브 audio-to-audio 모델","결론은 '하네스를 짓지 말라'가 아니라 '버릴 수 있을 만큼 싸게 지어라(build them cheap enough to throw away)'"],"related":["posts/agent-harness-engineering","posts/anatomy-of-an-agent-harness","posts/components-of-a-coding-agent"]},{"title":"잃어버린 게으름의 위험 — Bryan Cantrill이 LLM 시대에 다시 꺼내는 프로그래머의 미덕","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/peril-of-laziness-lost/","section":"posts","date":"2026-04-27T18:56:36+09:00","lastmod":"2026-04-27T18:56:36+09:00","description":"Bryan Cantrill이 Larry Wall의 '게으름·조급함·자만'이라는 프로그래머의 세 미덕을 다시 꺼내, LLM이 왜 좋은 추상화를 만들지 못하는지 진단한다. Garry Tan의 '하루 37,000줄' 자랑과 DTrace 60,000줄을 나란히 놓으면, 시간 제약이 없는 생성기가 만든 코드가 어떻게 쓰레기 레이어케이크가 되는지가 드러난다.","summary":"Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다.\n원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12)\nTL;DR 요약 세 가지 미덕: Larry Wall의 Programming Perl(\u0026ldquo;Camel Book\u0026rdquo;)이 말한 Laziness, Impatience, and Hubris는 좋은 소프트웨어 설계의 토대였다. 진짜 게으름: 문제를 머릿속에서 굴리고 또 굴려, 미래의 개발자에게 도움이 되는 강력한 추상화를 만들어내는 지적 노동이다. LLM의 결함: 일에 비용이 들지 않으니 \u0026ldquo;쓰레기의 레이어케이크에 더 많은 것을 기쁘게 쌓아 올린다\u0026rdquo; — 시간 희소성을 겪지 않기에 게으름의 미덕이 작동하지 않는다. 숫자 대비: Garry Tan이 자랑한 하루 37,000줄(여전히 가속 중) vs DTrace 전체 약 60,000줄. 폴란드 엔지니어 Gregorein의 분석은 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(하나는 0바이트)을 발견. 결론: \u0026ldquo;최고의 엔지니어링은 항상 제약에서 태어난다.\u0026rdquo; LLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야지, 자율 개발자로 풀어주어선 안 된다. Oxide의 LLM 가이드라인(RFD 0576)이 그 사례. 시작점 — Larry Wall이 정의한 세 미덕 Cantrill은 Programming Perl(통칭 \u0026ldquo;Camel Book\u0026rdquo;)의 한 줄을 다시 끌어옵니다.\n","content":"Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다.\n원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12)\nTL;DR 요약 세 가지 미덕: Larry Wall의 Programming Perl(\u0026ldquo;Camel Book\u0026rdquo;)이 말한 Laziness, Impatience, and Hubris는 좋은 소프트웨어 설계의 토대였다. 진짜 게으름: 문제를 머릿속에서 굴리고 또 굴려, 미래의 개발자에게 도움이 되는 강력한 추상화를 만들어내는 지적 노동이다. LLM의 결함: 일에 비용이 들지 않으니 \u0026ldquo;쓰레기의 레이어케이크에 더 많은 것을 기쁘게 쌓아 올린다\u0026rdquo; — 시간 희소성을 겪지 않기에 게으름의 미덕이 작동하지 않는다. 숫자 대비: Garry Tan이 자랑한 하루 37,000줄(여전히 가속 중) vs DTrace 전체 약 60,000줄. 폴란드 엔지니어 Gregorein의 분석은 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(하나는 0바이트)을 발견. 결론: \u0026ldquo;최고의 엔지니어링은 항상 제약에서 태어난다.\u0026rdquo; LLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야지, 자율 개발자로 풀어주어선 안 된다. Oxide의 LLM 가이드라인(RFD 0576)이 그 사례. 시작점 — Larry Wall이 정의한 세 미덕 Cantrill은 Programming Perl(통칭 \u0026ldquo;Camel Book\u0026rdquo;)의 한 줄을 다시 끌어옵니다.\n\u0026ldquo;Laziness, Impatience, and Hubris, the basis of good software design.\u0026rdquo; — Larry Wall\n오해하기 쉬운 단어들입니다. 여기서 말하는 **게으름(Laziness)**은 일을 안 하는 게 아니라, 다시는 같은 일을 안 하기 위해 한 번 제대로 추상화하는 노력입니다. 문제를 머릿속에서 몇 번이고 굴려보고, 후대의 개발자가 같은 고생을 반복하지 않도록 강력한 추상을 짜내는 일 — 그게 미덕으로서의 게으름입니다.\n조급함과 자만도 같은 결입니다. *\u0026ldquo;이건 더 빠르게 돌아야 한다\u0026rdquo;*는 조급함이 최적화를 낳고, *\u0026ldquo;내가 만든 게 다른 사람도 쓸만해야 한다\u0026rdquo;*는 자만이 API의 품질을 끌어올립니다.\n세 미덕의 공통분모는 자기 자신과 타인의 시간에 대한 자각입니다.\nLLM에는 무엇이 빠져 있는가 — 시간 제약의 부재 Cantrill의 진단은 단순합니다.\n\u0026ldquo;LLMs inherently lack the virtue of laziness.\u0026rdquo;\n이유는 윤리도 정렬도 아닌 물리학에 가깝습니다. LLM에게 코드 한 줄을 더 만드는 것은 비용이 거의 0입니다. 사람은 *\u0026ldquo;이걸 또 짜기 싫다\u0026rdquo;*는 감각이 추상화를 강제하지만, LLM은 그 감각이 없습니다. 그래서:\n\u0026ldquo;will happily dump more and more onto a layercake of garbage.\u0026rdquo;\n기쁘게, 망설임 없이, 쓰레기의 레이어케이크 위에 더 많은 쓰레기를 쌓는다. 추상화의 압력이 없으니 단순화도 없고, 단순화가 없으니 우아함도 없습니다.\n이는 모델 능력의 문제가 아닙니다. 더 똑똑한 모델이 와도 시간이 비용이 되지 않는다는 구조는 그대로입니다.\n사례 연구 — Garry Tan의 \u0026ldquo;하루 37,000줄\u0026rdquo; Cantrill이 직접 겨눈 사례는 벤처 캐피털리스트 Garry Tan입니다(\u0026ldquo;brogrammer-of-note\u0026quot;라는 표현으로 호명). Tan은 LLM과 함께 작업하며 하루 37,000줄의 코드를 생산한다고 자랑했고, \u0026ldquo;still speeding up\u0026rdquo; — 여전히 가속 중이라고 덧붙였습니다.\n비교점이 강렬합니다.\n코드베이스 라인 수 기간 DTrace 전체 약 60,000줄 다년간의 시스템 엔지니어링 Garry Tan의 하루 산출 약 37,000줄 24시간 DTrace가 무엇인지 알면 이 비교의 무게가 더 분명해집니다 — Solaris의 동적 트레이싱 시스템, Cantrill 본인을 포함한 팀이 수년간 다듬어 온, 실시간 운영체제 관측의 정수.\nGregorein의 검시 — 무엇이 들어 있었나 폴란드 엔지니어 Gregorein이 Tan이 만든 코드를 뜯어보고 정리한 결과는 생성기가 엔지니어가 아닌 이유를 그대로 보여줍니다:\n여러 개의 중복된 테스트 하니스 Hello World Rails 템플릿 (그대로 들어 있음) 내장된 텍스트 에디터 8개의 로고 변형 — 그중 하나는 0바이트 각 항목이 무엇을 의미하는지 보면, 이는 LLM이 만들 수 있는 잘못의 카탈로그에 가깝습니다 — 중복, 보일러플레이트의 잔재, 무의미한 컴포넌트의 첨가, 무의미한 산출물(0바이트 로고)의 자동 생성.\n양은 미덕의 부재를 가립니다. 줄 수는 늘었지만, 엔지니어링은 없습니다.\n진짜 문제는 버그가 아니라 방법론 Cantrill의 핵심 통찰은 여기입니다.\n개별 버그가 문제가 아니다. 방법론 자체가 문제다.\n사람의 시간 제약은 단순함과 명료함을 향해 손을 강제로 끌어당깁니다. 시간이 없으니까 — 그래서 더 적은 코드, 더 명확한 이름, 더 견고한 추상이 살아남습니다.\n제약이 사라진 LLM은 그 반대 방향으로 갑니다. 더 많은 레이어, 더 많은 옵션, 더 많은 방어적이지만 무의미한 코드. 이것이 \u0026ldquo;Cantrill의 The Complexity of Simplicity 강연이 말한 그 대비입니다.\n\u0026ldquo;The best engineering is always borne of constraints.\u0026rdquo;\n제약이 곧 엔지니어링의 산파라는 명제. LLM은 제약이 없는 환경을 만들고, 그래서 최고의 엔지니어링이 일어날 조건을 무너뜨립니다.\n그래서 LLM을 어떻게 다뤄야 하는가 — Oxide의 답 Cantrill은 LLM 자체를 폐기하라고 말하지 않습니다. 자기 회사 Oxide Computer Company의 LLM 가이드라인 — RFD 0576 — 을 사례로 듭니다. 핵심:\nLLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야 한다. 자율 개발자가 아니다.\n활용의 방향은 비미덕적 게으름(non-virtuous laziness)을 처리하는 데 있습니다 — 즉:\n기술 부채(technical debt)를 정리하는 노가다 보일러플레이트의 기계적 변환 단조로운 마이그레이션 이런 곳에서 LLM은 사람이 하기 싫지만 필요한 일을 떠맡아 줍니다. 반면 추상화의 결정, 이름 짓기, 무엇을 만들지 않을지에 대한 판단은 사람의 미덕적 게으름이 다뤄야 할 영역으로 남깁니다.\n핵심 어휘 정리 Virtuous Laziness — 같은 일을 두 번 하지 않기 위해 추상화를 만들어내는 지적 게으름 Non-virtuous Laziness — 단순히 일을 회피하는 게으름; LLM에 위임 가능한 영역 Layercake of Garbage — 압력 없이 쌓이는 코드층; LLM이 만들기 쉬운 산출물의 형태 Constraint-borne Engineering — 제약이 만든 엔지니어링; 시간·메모리·인지 한계가 단순함을 강제 실행 체크리스트 — LLM을 미덕 안에 두는 법 *생산량(라인 수)*을 자랑·평가 지표에서 분리할 것 — 양은 미덕의 부재를 가린다 LLM 산출물에 대해 추상화 압력을 사람이 별도로 가할 것(리뷰·압축·삭제 라운드) Hello World 템플릿, 중복 테스트 하니스, 0바이트 자동 산출물 — 이런 패턴을 LLM 결과물의 카나리아로 삼을 것 LLM에 위임할 영역(비미덕적 게으름)과 위임하지 않을 영역(추상화 결정·명명·범위 결정)을 명시적으로 구분 회사 단위의 LLM 사용 가이드라인을 문서화 — Oxide RFD 0576 같은 사례 참조 왜 이 글이 중요한가 대부분의 LLM 비판은 환각, 보안, 정렬 같은 출력의 문제에 머무릅니다. Cantrill의 글은 한 층 아래를 겨눕니다 — 생성 자체의 경제학이 만들어내는 구조적 결함.\n역사적 토대 — Larry Wall이 정의한 프로그래머의 미덕이 왜 1990년대 책의 농담이 아니라 공학의 본질이었는지 메커니즘적 진단 — 시간 비용의 부재가 어떻게 추상화 실패로 이어지는지 실증 사례 — 37,000줄 vs 60,000줄, 그리고 그 안의 8번째 0바이트 로고 건설적 출구 — LLM을 어디에 쓰고 어디에 쓰지 말지에 대한 Oxide의 답 도구는 미덕을 보조할 때만 가치를 만든다. 미덕을 대체하려는 순간, 도구는 쓰레기의 레이어케이크를 가속한다.\n핵심 결론 좋은 소프트웨어 설계의 토대는 게으름·조급함·자만이라는 시간과 자기 자각의 미덕이다 LLM에는 시간 비용이 없으므로 추상화를 강제하는 압력이 발생하지 않는다 결과는 쓰레기의 레이어케이크 — 양은 늘지만 엔지니어링은 없다 Garry Tan의 하루 37,000줄과 DTrace 전체 60,000줄의 대비, 그리고 0바이트 로고를 포함한 8개 변형이 그 증거다 진짜 문제는 개별 버그가 아니라 방법론 — 제약 없는 생성은 단순함을 밀어낸다 LLM은 비미덕적 게으름의 처리에 쓰고, 추상화·명명·범위 결정은 사람의 미덕 안에 남길 것 (Oxide RFD 0576) 당신의 코드베이스는 줄 수가 늘고 있는가, 아니면 후대의 엔지니어를 위한 게으름이 자라고 있는가.\n","wordCount":992,"tags":["Bryan Cantrill","Larry Wall","Programming Perl","Laziness","LLM","AI","Oxide","DTrace","Garry Tan","Code Quality","소프트웨어공학"],"categories":["AI"],"frameworks":["Three Programmer Virtues","Constraint-Driven Engineering","Virtuous Laziness"],"mental_models":["Generation without Time Cost","Quantity vs Quality of Code","Layercake of Garbage"],"philosophy_type":"engineering-ethics","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Larry Wall의 '게으름·조급함·자만'은 좋은 소프트웨어 설계의 토대였고, 진짜 게으름은 추상화를 위해 머리를 쥐어짜는 지적 노동이다","LLM에는 시간 비용이 없어 게으름의 미덕이 작동하지 않으며, 결과는 '쓰레기의 레이어케이크'다","Garry Tan은 '하루 37,000줄, 여전히 가속 중'이라고 자랑했지만 DTrace 전체 코드베이스가 약 60,000줄이다","Polish 엔지니어 Gregorein이 Tan의 코드를 뜯어보니 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(그중 하나는 0바이트)이 들어 있었다","최고의 엔지니어링은 항상 제약에서 태어난다 — LLM은 인간의 미덕적 게으름을 보조하는 도구여야지 자율 개발자가 아니다"],"related":["posts/probabilistic-engineering-24-7-employee","posts/fowler-fragments-cognitive-debt-system-3","posts/zero-alignment-maggie-appleton"]},{"title":"하네스 엔지니어링 — 좋은 모델 + 나쁜 하네스보다 평범한 모델 + 훌륭한 하네스가 이긴다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agent-harness-engineering/","section":"posts","date":"2026-04-27T18:53:38+09:00","lastmod":"2026-04-27T18:53:38+09:00","description":"Addy Osmani가 제시하는 '하네스 엔지니어링'의 핵심 원칙 — 에이전트 = 모델 + 하네스, 모든 실패는 룰이 되고, 모델이 강해지면 하네스는 줄어드는 게 아니라 이동한다. Claude Code·Cursor·Codex·Aider·Cline의 공통 패턴과 Harness-as-a-Service로의 전환을 정리한다.","summary":"Addy Osmani가 2026년 4월에 정리한 글입니다. 핵심 명제는 단순합니다 — 코딩 에이전트 = 모델 + 그 주변에 당신이 만든 모든 것이고, 그 \u0026ldquo;주변\u0026quot;을 진지하게 다루는 규율을 하네스 엔지니어링이라 부릅니다.\n원문: Agent Harness Engineering — Addy Osmani (2026-04-19)\n한 줄 A decent model with a great harness beats a great model with a bad harness.\n평범한 모델 + 훌륭한 하네스가, 훌륭한 모델 + 나쁜 하네스를 이깁니다. Claude Code, Cursor, Codex, Aider, Cline이 종종 동일한 모델을 쓰면서 행동이 완전히 갈리는 이유는 모델이 아니라 하네스 차이에 있습니다.\n","content":"Addy Osmani가 2026년 4월에 정리한 글입니다. 핵심 명제는 단순합니다 — 코딩 에이전트 = 모델 + 그 주변에 당신이 만든 모든 것이고, 그 \u0026ldquo;주변\u0026quot;을 진지하게 다루는 규율을 하네스 엔지니어링이라 부릅니다.\n원문: Agent Harness Engineering — Addy Osmani (2026-04-19)\n한 줄 A decent model with a great harness beats a great model with a bad harness.\n평범한 모델 + 훌륭한 하네스가, 훌륭한 모델 + 나쁜 하네스를 이깁니다. Claude Code, Cursor, Codex, Aider, Cline이 종종 동일한 모델을 쓰면서 행동이 완전히 갈리는 이유는 모델이 아니라 하네스 차이에 있습니다.\n하네스란 정확히 무엇인가 Viv Trivedy의 정의가 가장 간결합니다 — \u0026ldquo;모델이 아니면, 하네스다(If you\u0026rsquo;re not the model, you\u0026rsquo;re the harness).\u0026rdquo;\n구체적으로 하네스에 들어가는 것:\n시스템 프롬프트, CLAUDE.md, AGENTS.md, 스킬 파일 도구·스킬·MCP 서버와 그 description 번들된 인프라 — 파일시스템, 샌드박스, 브라우저 오케스트레이션 로직 — 서브에이전트 스폰, 핸드오프, 라우팅 훅과 미들웨어 — compaction, continuation, lint 체크 관측성 — 로그·트레이스·비용·지연 측정 \u0026ldquo;Skill Issue\u0026rdquo; 리프레임 — 모델 문제가 아니라 설정 문제다 대부분의 에이전트 실패는 모델 한계가 아니라 설정 부재에서 온다는 시각.\n실패 양상 진짜 원인 컨벤션을 모름 AGENTS.md에 안 써둠 파괴적 명령 실행 예방 훅이 없음 긴 작업에서 길을 잃음 planner/executor를 안 분리함 깨진 코드 머지 typecheck 백프레셔 미연결 증거: Terminal Bench 2.0에서 동일한 Claude Opus 4.6이 Claude Code에서보다 커스텀 하네스에서 훨씬 높은 점수를 냈습니다. Viv의 팀은 모델은 그대로 두고 하네스만 바꿔서 Top 30 → Top 5로 올렸습니다.\n\u0026ldquo;The gap between what today\u0026rsquo;s models can do and what you see them doing is largely a harness gap.\u0026rdquo;\nThe Ratchet — 모든 실수는 룰이 된다 하네스 엔지니어링의 핵심 규율은 래칫(ratchet) 입니다. 한 번 죈 나사는 풀리지 않습니다.\n실패가 발생한다 → 엔지니어가 해결한다 재발을 막을 제약을 추가한다(훅, AGENTS.md 한 줄, 스킬, 도구 게이트) 그 제약은 모델이 충분히 강해져 불필요해질 때까지 유지된다 \u0026ldquo;좋은 AGENTS.md의 모든 줄은 잘못됐던 구체적 사건으로 추적 가능해야 한다.\u0026rdquo;\n따라서 내 코드베이스에 맞는 하네스는 다운로드할 수 없습니다. 당신의 실패 이력이 만든 모양이 바로 그 하네스이기 때문입니다.\nWorking Backwards from Behaviour — 행동에서 거꾸로 설계하라 \u0026ldquo;어떤 컴포넌트가 어떤 행동을 위해 존재하는지 이름댈 수 없다면, 그건 거기 있어선 안 된다.\u0026rdquo;\n이 원칙으로 하네스의 주요 부품들을 본다:\n파일시스템과 Git — Durable State 가장 기초가 되는 프리미티브. 에이전트가 데이터를 읽고, 중간 작업을 오프로드하고, git으로 진행을 기록·롤백·실험할 수 있게 한다.\nBash와 코드 실행 — 범용 손 ReAct 루프의 가장 일반적인 행동. 대부분의 작업은 결국 CLI 호출로 환원된다.\n샌드박스와 디폴트 툴링 allow-list, 네트워크 격리, 온디맨드 환경 구성. 모델이 환경을 설정하지 않는다 — 하네스가 결정한다.\n메모리와 검색 — 임시 continual learning 모델은 가중치 또는 컨텍스트로만 지식을 얻는다. AGENTS.md 같은 메모리 파일이 매 세션 주입되고, 웹 검색과 MCP가 학습 cutoff를 메운다. 거칠지만 효과적인 임시 지속 학습이다.\n컨텍스트 부패와의 싸움 — 3가지 무기 Compaction — 윈도우가 차면 오래된 컨텍스트를 지능적으로 ·오프로드 Tool-call offloading — 고가치 토큰만 컨텍스트에 두고, 큰 출력은 파일시스템으로 Skills with progressive disclosure — 필요할 때만 지시·도구를 노출 Anthropic은 매우 긴 작업을 위해 풀 컨텍스트 리셋까지 추가했다 — 세션을 tear down하고, compact handoff 파일에서 다시 빌드.\nLong-Horizon 실행 — Ralph Loops, Planning, Verification Ralph Loop: 종료 시도를 훅이 가로채 원래 프롬프트를 깨끗한 컨텍스트 윈도우에 다시 주입. 매 이터레이션은 새로 시작하지만 파일시스템으로 상태를 읽는다. Planning: 모델이 목표를 plan 파일의 단계 시퀀스로 분해. Self-verification: 훅이 테스트 스위트를 돌리고 실패를 모델에 다시 흘림. Planner / Generator / Evaluator 분리: 같은 에이전트가 자기 작업을 평가하면 점수를 후하게 주므로, 분리하면 성능이 좋아진다. Sprint contracts: 코딩 시작 전에 generator와 evaluator가 \u0026ldquo;완료\u0026rdquo; 정의를 협상. Hooks — 시행 계층 라이프사이클 시점(도구 호출 전, 파일 편집 후, 커밋 전, 세션 시작)에 끼어드는 스크립트.\n매 편집 후 typecheck/lint/test 실행 rm -rf, git push --force, DROP TABLE 같은 파괴적 bash 차단 main으로의 PR/push 전 승인 요구 쓰기 시 자동 포맷 \u0026ldquo;Success is silent, failures are verbose.\u0026rdquo; typecheck 통과는 침묵, 실패는 에러 텍스트가 모델에게 자기교정용으로 주입된다.\nAGENTS.md와 도구 선택 시스템 프롬프트에 매 턴 들어가는 가장 레버리지 높은 설정 지점. 두 가지 교훈:\n짧게 유지하라 — HumanLayer는 60줄 이하로 유지한다. \u0026ldquo;파일럿 체크리스트지, 스타일 가이드가 아니다.\u0026rdquo; 모든 줄을 벌어와라 — 구체적 실패나 하드 제약으로 거슬러 올라갈 수 있어야 한다. 도구 디시플린: 겹치는 50개보다 집중된 10개. MCP 도구 description은 신뢰된 텍스트로 프롬프트에 들어가므로 보안 이슈도 된다.\n하네스는 줄어들지 않는다 — 이동한다 \u0026ldquo;Every component in a harness encodes an assumption about what the model can\u0026rsquo;t do on its own.\u0026rdquo; — Anthropic\n모델이 강해지면:\n그 가정에 해당하는 컴포넌트는 죽는다(예: Opus 4.6이 등장하면서 Sonnet 4.5의 \u0026ldquo;context anxiety\u0026quot;를 막던 스캐폴딩이 사라짐) 새로운 능력이 풀리면 새 스캐폴딩이 등장한다(다중 일 메모리 정책, 다중 에이전트 조정, UI 디자인 평가자) Model-Harness Training Loop 하네스에서 발견된 패턴 → 제품으로 표준화 → 다음 모델 학습에 사용 → 모델이 그 프리미티브에서 더 잘함 → 반복.\n이 피드백 루프 때문에 오늘날 모델은 하네스를 염두에 두고 후속학습된다. 파일시스템 조작, bash, planning, 서브에이전트 디스패치 같은 하네스 설계자가 가치 있게 보는 행동에서 모델이 점점 더 강해진다.\n실무적 함의 하네스는 정적 설정이 아니라 살아있는 시스템이다. \u0026ldquo;최고의\u0026rdquo; 하네스는 모델이 학습된 그 하네스가 아니라, 당신의 작업에 맞춰 설계된 하네스다. Harness-as-a-Service (HaaS) LLM 완성(completion) API 위에 내가 직접 루프를 짜던 시대 → 하네스 런타임 API 위에서 시스템 프롬프트·도구·컨텍스트·서브에이전트만 커스터마이즈하는 시대.\n대표 제품: Claude Agent SDK, Codex SDK, OpenAI Agents SDK. 루프, 도구, 컨텍스트 관리, 훅, 샌드박스 프리미티브가 박스에서 나온다.\n\u0026ldquo;Good agent building is an exercise in iteration. You can\u0026rsquo;t do iterations if you don\u0026rsquo;t have a v0.1.\u0026rdquo; — Viv Trivedy\n어디로 가는가 상위권 코딩 에이전트들(Claude Code, Cursor, Codex, Aider, Cline)은 그 밑의 모델보다 서로가 더 닮았다. 하네스 패턴이 수렴하고 있다.\nViv가 꼽는 열린 문제 3가지:\n같은 코드베이스에서 다수 에이전트를 어떻게 오케스트레이션할 것인가 에이전트가 자기 트레이스를 분석해 하네스 실패 모드를 스스로 고치게 만들 수 있는가 하네스가 just-in-time으로 도구·컨텍스트를 동적 조립할 수 있는가 \u0026ldquo;Harnesses stop being static config and start becoming something closer to a compiler.\u0026rdquo;\n정리 에이전트 = 모델 + 하네스. 비행기와 항공교통관제처럼, 둘 다 있어야 작동한다. 실패는 거의 항상 설정 문제다. 매 실패는 룰이 되어 래칫처럼 되감기지 않는다. 컴포넌트는 행동에서 거꾸로 정당화되어야 한다. 이름댈 수 없는 컴포넌트는 빼라. 모델이 강해지면 하네스는 줄어드는 게 아니라 이동한다. 죽은 컴포넌트는 지우고, 새 능력에는 새 스캐폴딩을 붙인다. 직접 루프를 짜는 시대에서 HaaS 위에서 도메인을 설계하는 시대로 가고 있다. 다음에 에이전트가 실패하면, 모델 탓을 하기 전에 하네스를 봐라.\n","wordCount":971,"tags":["AI","에이전트","하네스","Addy Osmani","Claude Code","AGENTS.md","Ralph Loop","HaaS"],"categories":["AI"],"frameworks":["Harness Engineering","The Ratchet","Working Backwards from Behaviour"],"mental_models":["Skill Issue Reframe","Model-Harness Training Loop","Behavior-First Design"],"philosophy_type":"engineering-discipline","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트 = 모델 + 하네스, 평범한 모델 + 훌륭한 하네스가 훌륭한 모델 + 나쁜 하네스를 이긴다","하네스는 시스템 프롬프트, AGENTS.md, 도구, MCP 서버, 오케스트레이션, 훅, 관측성을 포함한다","래칫 원칙 — 모든 실패는 제약으로 바뀌고, 모델이 강해져도 하네스는 사라지지 않고 이동한다","동일 모델이라도 하네스만 변경해 TerminalBench 30위권 → 5위로 개선한 사례"],"related":["posts/anatomy-of-an-agent-harness","posts/agentic-engine-optimization","posts/components-of-a-coding-agent"]},{"title":"에이전트는 구조와 유연성 사이에서 고를 수 없다 — Python 캠프 vs Markdown 캠프의 가짜 선택지","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agents-cant-choose-structure-flexibility/","section":"posts","date":"2026-04-25T08:39:30+09:00","lastmod":"2026-04-25T08:39:30+09:00","description":"The AI Frontier의 'Agents can't choose between structure and flexibility' 정리 — Python 대 Markdown 논쟁은 가짜 선택지다. 코드 최대주의는 에이전트의 추론을 제거하고, 마크다운 최대주의는 통제·디버그·교정 가능성을 포기한다. RunLLM과 Claude Code가 도달한 하이브리드 code harness 구조를 살펴본다.","summary":"LLM 하이프 사이클이 시작될 때, 우리 시대의 큰 논쟁 중 하나가 Python과 Markdown 사이의 에이전트 명세 언어 선택이 될 거라고는 아무도 예상하지 못했습니다. 하지만 The AI Frontier(Vikram Sreekanti 외)가 Agent Native 시리즈의 일부로 짚듯, 이 질문은 빠르게 AI 아키텍처에서 가장 결정적인 논쟁이 되었습니다. 글의 핵심 주장은 단순합니다 — 이 논쟁은 두 개의 방어 가능한 입장 사이의 선택이 아니라, 양쪽 모두 실패 모드라는 것입니다. 어느 쪽도 agent-native가 아니기 때문입니다.\nTL;DR 요약 가짜 선택지: Python 캠프는 단계의 엄격한 요구사항을 코드로 표현하고, Markdown 캠프는 영어로 목표·제약을 주고 계획을 맡긴다. 양쪽 다 극단에 가면 에이전트의 본질을 망친다. 코드 최대주의의 세 가지 실패: 인간의 직렬 가설 추적을 모방, 시도/배제 이유에 대한 가시성 부재, 시스템이 바뀌면 진화하지 못함 — RunLLM이 AI SRE 런북 접근에서 초기에 직접 부딪힌 함정. 마크다운 최대주의의 실패는 AI 슬라이드 생성에서 보인다 — \u0026ldquo;슬라이드 7번 레이아웃을 세로로, 차트는 아래로\u0026quot;를 지정할 수 있는 주소 가능한 단위가 없다. 하이브리드는 타협이 아니다: 컨텍스트 관리·모델 선택·비용·교차 에이전트 조정 같은 부분은 결국 code harness로 흡수된다. Claude Code와 RunLLM이 독립적으로 같은 자리에 도달했다. Agent-native 판정 4문항: 가설 병렬 평가? 시도/배제 가시성? 시스템 변화 적응? 사용자 단위의 교정 granularity? 원문: Agents can\u0026rsquo;t choose between structure and flexibility — The AI Frontier (Agent Native series)\n","content":"LLM 하이프 사이클이 시작될 때, 우리 시대의 큰 논쟁 중 하나가 Python과 Markdown 사이의 에이전트 명세 언어 선택이 될 거라고는 아무도 예상하지 못했습니다. 하지만 The AI Frontier(Vikram Sreekanti 외)가 Agent Native 시리즈의 일부로 짚듯, 이 질문은 빠르게 AI 아키텍처에서 가장 결정적인 논쟁이 되었습니다. 글의 핵심 주장은 단순합니다 — 이 논쟁은 두 개의 방어 가능한 입장 사이의 선택이 아니라, 양쪽 모두 실패 모드라는 것입니다. 어느 쪽도 agent-native가 아니기 때문입니다.\nTL;DR 요약 가짜 선택지: Python 캠프는 단계의 엄격한 요구사항을 코드로 표현하고, Markdown 캠프는 영어로 목표·제약을 주고 계획을 맡긴다. 양쪽 다 극단에 가면 에이전트의 본질을 망친다. 코드 최대주의의 세 가지 실패: 인간의 직렬 가설 추적을 모방, 시도/배제 이유에 대한 가시성 부재, 시스템이 바뀌면 진화하지 못함 — RunLLM이 AI SRE 런북 접근에서 초기에 직접 부딪힌 함정. 마크다운 최대주의의 실패는 AI 슬라이드 생성에서 보인다 — \u0026ldquo;슬라이드 7번 레이아웃을 세로로, 차트는 아래로\u0026quot;를 지정할 수 있는 주소 가능한 단위가 없다. 하이브리드는 타협이 아니다: 컨텍스트 관리·모델 선택·비용·교차 에이전트 조정 같은 부분은 결국 code harness로 흡수된다. Claude Code와 RunLLM이 독립적으로 같은 자리에 도달했다. Agent-native 판정 4문항: 가설 병렬 평가? 시도/배제 가시성? 시스템 변화 적응? 사용자 단위의 교정 granularity? 원문: Agents can\u0026rsquo;t choose between structure and flexibility — The AI Frontier (Agent Native series)\n두 캠프의 정의 캠프 표현 수단 무엇을 표현하나 트레이드오프 Python 캠프 코드 에이전트가 밟아야 할 단계의 엄격한 요구사항 강한 가드레일·계획 이탈 위험 ↓ / 유연성 ↓ Markdown 캠프 영어 넓은 목표와 제약, 경로는 모델이 계획 도구·모델 간 이식성 ↑ / 예기치 못한 행동 위험 ↑ 대부분의 논쟁은 이를 두 개의 방어 가능한 입장으로 다룹니다. 글의 진단: 둘 다 실패 모드다. 한쪽을 고르는 것은 에이전트를 진짜로 설계하는 어려운 일을 회피하는 방식일 뿐입니다.\n\u0026ldquo;Picking a side is how you avoid the hard work of designing an agent.\u0026rdquo;\n그리고 양쪽의 종착지는 같습니다 — \u0026ldquo;인간이 하던 일을 다른 문법으로 복붙하는 것\u0026rdquo;.\n코드 최대주의가 놓치는 것 코드 최대주의의 세일즈 포인트는 신뢰성입니다. 에이전트에게 무엇을 할지 정확히 명시하고, 깨지면 에러를 띄우고, 결과를 좁게 묶어둡니다. LLM이 실수하고 의도를 오해하고 이상한 짓을 한다는 점을 생각하면 매력적으로 들립니다.\n저자들은 자신들의 AI SRE 도메인 경험을 사례로 듭니다. 거의 모든 벤더가 고객에게 runbook 작성을 요구합니다. 제품은 그 runbook을 워크플로로 인코딩하고, 특정 알림에 대해 에이전트가 그 워크플로를 실행하게 합니다. 결과는 좁은 의미에서 신뢰할 만합니다 — 예상한 대로 동작합니다. 하지만 알림이 과거와 다르게 보이거나 아키텍처가 바뀌는 순간 쓸모없어집니다. RunLLM도 초기에 이 길을 갔다가 빠르게 실패를 확인했습니다.\n실패의 세 가지 양상 인간 행동의 복붙 — 인간은 가장 가능성 높은 단일 가설을 골라 직렬로 따라갑니다. 자신감이 있을 때는 잘 작동하지만, 첫 가설이 틀리면 엄청난 낭비가 발생합니다. 에이전트는 그 함정에 빠질 필요가 없습니다 — 여러 가설을 병렬로 평가할 수 있고, 일부는 막다른 길이지만 정답에 도달할 확률이 극적으로 올라갑니다. RunLLM은 이 아키텍처로 만들어졌고, 실제 인시던트가 그렇게 해결되는 것을 본다고 말합니다. 인간에게 의미 있는 가시성을 주지 않음 — SRE는 \u0026ldquo;에이전트가 런북 3단계를 실행했는지\u0026quot;를 확인할 필요가 없습니다. 그들은 에이전트가 무엇을 시도했고, 무엇을 배제했고, 왜 그랬는지를 알아야 합니다. 잘 닦인 길은 지루한 일을 자동화하지만, 사람이 에이전트의 추론을 신뢰하거나 배울 수 없게 합니다. 인코딩된 워크플로는 진화하지 않음 — 에이전트가 약속하는 지능을 잃습니다. 시스템이 바뀌거나 요구사항이 바뀌면 모든 인코딩이 따라 바뀌어야 합니다. 에이전트가 피드백을 받아 기대 행동이 달라졌음을 이해하고 스스로 적응할 길이 없습니다 — 누군가 harness를 손봐야 합니다. 마크다운 최대주의가 놓치는 것 마크다운 최대주의는 유연성을 최적화합니다. 목표를 기술하고, 능력 있는 모델에게 넘기고, 알아서 풀게 합니다. 이식성이 높고, 표현력이 좋고, 빠르게 동작하는 것을 얻습니다. 창의성과 열린 문제 해결이 중요한 곳에서는 고정된 워크플로보다 극적으로 유용할 수 있습니다.\n변질된 형태: AI 슬라이드 생성 저자들이 드는 사례는 AI 슬라이드 생성기입니다. 외부에서 보면 \u0026ldquo;LLM에게 다 시킨다\u0026rdquo; 형태로 읽힙니다 — 프롬프트 하나 넣으면 전체 데크가 나옵니다. 실패 모드는 누구나 익숙합니다.\n슬라이드 7의 레이아웃이 이상하다 차트가 주장과 맞지 않는다 논리 흐름이 뒤엉켜 있다 이때 사용자는 말하고 싶습니다 — \u0026ldquo;슬라이드 7에서 흐름을 가로 대신 세로로 바꾸고, 차트를 아래로 옮겨줘.\u0026rdquo; 보통 이게 의도대로 작동하지 않습니다. 조정할 수 있는 이산적인 레이아웃 로직이 없고, 차트 배치를 위한 분리된 단계가 없으며, 전체 생성보다 작은 주소 가능한 단위가 없습니다. 다시 프롬프트를 넣고, 다른 방식으로 틀린 새 데크를 받고, 처음부터 다시 시작합니다.\n정교한 마크다운 최대주의도 마찬가지 이를 허수아비라고 치워서는 안 됩니다. 진지한 마크다운 최대주의자는 모든 앱을 원샷하자고 주장하지 않습니다. 정교한 버전은 skills.md + 기본 에이전트 루프 — 풍부한 컨텍스트, 사려 깊은 지시, 추론하는 능력 있는 모델을 통해 이끄는 접근입니다.\n복잡한 애플리케이션이 그 격차를 드러냅니다. 현실과 부딪히면, 여전히 엄격한 제약이 필요한 엔지니어링 결정들이 남습니다.\n컨텍스트 관리 및 모델 선택 비용 관리 교차 에이전트(cross-agent) 조정 이 각각의 과제는 모델의 추론을 신뢰하지 않는 것이 아닙니다. 사려 깊은 모델이 이 작업을 효율적이고 안정적으로 실행하도록 돕는 도구와 인프라를 짓는 것이 과제입니다.\n프로덕션에서 이는 컨텍스트 관리·모델 라우팅·서브에이전트 오케스트레이션·순수 프롬프팅이 깨지는 예측 가능한 지점 처리를 담당하는 code harness로 귀결됩니다. 이는 정확히 마크다운이 가이드 작업을 하고 코드가 구조 작업을 하는 하이브리드 아키텍처 — 즉 원래 논쟁이 다투려던 그 입장입니다.\n마크다운 최대주의로 시작해도, 결국 콘텐츠 관리·모델 라우팅 같은 좁은 harness 같은 능력을 잔뜩 지을 수밖에 없습니다. 질문은 그 후크를 의도적으로 설계할지, 코드 컴포넌트가 유기적으로 자라게 둘지일 뿐입니다.\n하이브리드는 타협이 아니다 진지한 에이전트를 만드는 팀들은 거의 독립적으로 같은 자리에 도달했습니다.\nMarkdown — 의도(intent)와 도메인 가이드 Code — 강제(enforcement), 도구 실행, 그리고 조용히 실패해서는 안 되는 모든 것 \u0026ldquo;Claude Code works this way. We built RunLLM this way.\u0026rdquo;\n이를 무성격한 타협으로 읽으면 안 됩니다. 에이전트의 핵심은 — 전통 소프트웨어와 달리 — 풀어야 할 문제를 이해하고 적합한 도구를 골라 도달할 수 있다는 점입니다.\n입장 무엇을 타협하는가 코드 최대주의 계획(planning) 을 타협 — 추론을 빼앗긴 워크플로 마크다운 최대주의 실행(execution)과 학습(learning) 을 타협 — 의도만 있고 깨지는 시스템 하이브리드 어느 쪽도 타협하지 않음 — 두 레이어가 각자의 일을 함 \u0026ldquo;Neither extreme gives you both, which means neither maximalist position gives you a truly flexible agent. It gives you either a workflow with aspirations or a wish with nothing to execute it.\u0026rdquo;\n아키텍처 작업의 본질은 시스템의 각 부분에 대해 어느 레이어에 속하는지 판정하는 것입니다.\n무엇이 의도로 표현되어 추론의 대상이 되는가? 무엇이 강제·검증되어야 하는가? 어디에 창의성이 필요하고, 어디에 제약이 필요한가? 이것이 어려운 부분이며, 한쪽 진영을 고르는 일은 바로 이 어려움을 회피하는 방식입니다.\nAgent-native가 실제로 요구하는 것 — 4개의 진단 질문 Python vs Markdown을 더 이상 논쟁의 축으로 두지 않으면, 진짜 아키텍처 우선순위가 또렷해집니다.\n# 질문 코드 최대주의 마크다운 최대주의 Agent-native 1 여러 가설을 병렬로 평가하는가, 하나를 직렬로 따라가는가? 직렬 모델 의존 병렬 평가 2 사람이 에이전트가 시도한 것과 그 이유를 볼 수 있는가, 최종 답만 받는가? 단계 실행 로그만 블랙박스 시도/배제/근거 노출 3 시스템이 바뀔 때 에이전트가 적응하는가, 누가 harness를 편집해야 하는가? 매번 재인코딩 자동이지만 통제 불가 피드백 루프 + 가드레일 4 사용자가 자신이 신경 쓰는 입자도(granularity) 로 출력을 교정할 수 있는가, all-or-nothing인가? 변경 단위가 큼 all-or-nothing 주소 가능한 단위 왜 이 논쟁이 여전히 살아 있는가 저자들의 결론적 진단:\n\u0026ldquo;The maximalist debates are a symptom of an industry still thinking about agents as workflow automators — either very rigid ones, or very loose ones.\u0026rdquo;\n에이전트 네이티브 제품을 만드는 팀들은 이미 이 논쟁을 지나갔습니다. 그들이 알아낸 것은 이 논쟁이 처음부터 Python이냐 Markdown이냐의 문제가 아니었다는 사실입니다. 진짜 질문은 \u0026ldquo;에이전트처럼 행동하는 것을 만들기 위한 작업을 할 의지가 있는가\u0026rdquo; 였습니다.\n실무 체크리스트 에이전트의 각 구성요소를 intent 레이어 / enforcement 레이어로 라벨링 enforcement 중 \u0026ldquo;조용히 실패하면 안 되는\u0026rdquo; 지점은 반드시 코드로 — 컨텍스트 관리, 모델 라우팅, 비용 관리, 교차 에이전트 조정 intent 마크다운은 절차가 아니라 목표·제약·도메인 지식에 집중 단일 가설 직렬 추적을 기본값으로 둔 부분이 있는지 감사 — 가능한 곳은 병렬 가설 평가로 전환 에이전트 출력에 시도/배제/근거 가시성 노출 — 단순 step log 아님 사용자 교정의 입자도 점검 — \u0026ldquo;슬라이드 7만 세로로\u0026rdquo; 같은 요청을 받을 주소 가능한 단위가 있는가? 시스템 변화 시 에이전트가 피드백으로 적응할 통로가 있는지 (없으면 매번 harness 패치 신세) 핵심 인용 \u0026ldquo;Picking a side is how you avoid the hard work of designing an agent.\u0026rdquo;\n\u0026ldquo;Either a workflow with aspirations or a wish with nothing to execute it.\u0026rdquo;\n\u0026ldquo;Markdown for intent and domain guidance, code for enforcement, tool execution, and anything that must not fail silently.\u0026rdquo;\n\u0026ldquo;The argument was never really about Python or Markdown. It was about whether you were willing to do the work to build something that actually behaves like an agent.\u0026rdquo;\n결론 — 양쪽 진영은 모두 인간 행동의 복붙이다 에이전트 설계의 성숙도는 어떤 문법을 쓰느냐가 아니라 어떤 것을 어느 레이어에 두느냐, 그리고 에이전트가 인간보다 더 잘 할 수 있는 것(병렬 가설 평가, 적응, 입자도 있는 교정)을 실제로 활용하느냐로 측정됩니다. Python 최대주의는 직렬로 답을 쫓는 인간을 자동화하고, Markdown 최대주의는 전체 산출물을 한 번에 던지는 인간을 자동화합니다 — 둘 다 에이전트의 의미를 잃습니다.\n에이전트는 구조와 유연성 사이에서 고를 수 없다 — 둘 다 필요하고, 둘은 서로 다른 레이어에서 공존해야 한다. 그리고 그 레이어 분리를 설계하는 일이 바로 에이전트 네이티브의 본업이다.\n관련 포스트 에이전트 하네스의 해부학 — Anthropic, OpenAI, LangChain이 실제로 구축하는 것 코딩 에이전트의 핵심 구성요소 — 모델이 아닌 하네스가 성능을 결정한다 Agentic Engine Optimization: AI 에이전트가 읽을 수 있는 문서를 만드는 새로운 규율 ","wordCount":1405,"tags":["AI","Agent","LLM","Architecture","Python","Markdown","Harness","Guardrails","AGENTS.md","Agent-Native","RunLLM","AI SRE"],"categories":["AI"],"frameworks":["Hybrid Agent Architecture","Code Harness","Intent vs Enforcement","Agent-Native Design"],"mental_models":["False Dichotomy","Failure Modes","Layer Separation","Parallel Hypothesis Evaluation"],"philosophy_type":"systems-thinking","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Python 대 Markdown 논쟁은 가짜 선택지다 — 양쪽 최대주의 모두 '인간이 하던 일을 다른 문법으로 복붙'하는 실패 모드다","코드 최대주의의 세 가지 실패: ① 단일 가설을 직렬로 따라가는 인간 행동 모방, ② 시도/배제/이유에 대한 가시성 부재, ③ 시스템이 바뀌면 따라 진화하지 못함 (RunLLM이 AI SRE 런북 접근에서 직접 경험)","마크다운 최대주의의 실패는 AI 슬라이드 생성에서 잘 보인다 — '슬라이드 7번을 세로로, 차트는 아래로'를 지정할 수 있는 단위가 없다","복잡한 시스템에서는 컨텍스트 관리·모델 선택·비용 관리·교차 에이전트 조정 같은 엄격한 제약이 필요하고, 그것이 곧 code harness가 된다","Claude Code와 RunLLM이 독립적으로 도달한 합의: 의도·도메인 가이드는 마크다운, 강제·도구 실행·조용히 실패하면 안 되는 모든 것은 코드","에이전트 네이티브 판정 기준 4개: 가설 병렬 평가, 시도 가시성, 시스템 변화에 대한 적응, 사용자 단위의 교정 granularity"],"related":["posts/anatomy-of-an-agent-harness","posts/components-of-a-coding-agent","posts/agentic-engine-optimization"]},{"title":"당신의 모든 에이전트는 비동기로 간다 — HTTP 요청-응답이 더 이상 맞지 않는 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/all-your-agents-are-going-async/","section":"posts","date":"2026-04-24T17:18:12+09:00","lastmod":"2026-04-24T17:18:12+09:00","description":"Zak Knill(Ably)이 던지는 인프라 진단 — 챗봇이 HTTP 요청-응답 위에 만들어진 것은 일종의 사고였고, 비동기 에이전트의 시대에는 이 선택이 깨진다. Durable State와 Durable Transport를 분리해서 보면 Anthropic Routines, Cloudflare Sessions API, OpenClaw 채널, Ably의 세션 모델이 어떻게 다른지가 명확해진다.","summary":"LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다.\n원문: All Your Agents Are Going Async — Zak Knill (2026)\n핵심 도발 \u0026ldquo;The interesting thing is what agents can do while not being synchronously supervised by a human.\u0026rdquo;\n흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다.\n","content":"LLM과 사용자의 상호작용은 프롬프트 입력 → 토큰 스트리밍 응답이라는 채팅 모델로 시작했고, 그 위에 HTTP 요청-응답이 자연스럽게 놓였습니다. Zak Knill(Ably)은 이것이 원래 맞춤한 선택이 아니라 우연이었다고 말합니다. 에이전트가 사람의 동기적 감독 없이 백그라운드에서 일하기 시작하면, 이 토대 자체가 어긋납니다.\n원문: All Your Agents Are Going Async — Zak Knill (2026)\n핵심 도발 \u0026ldquo;The interesting thing is what agents can do while not being synchronously supervised by a human.\u0026rdquo;\n흥미로운 일은 사람이 보고 있는 동안이 아니라, 사람이 보고 있지 않은 동안에 일어납니다. 그리고 그 일을 담을 그릇은 HTTP 요청-응답이 아닙니다.\n패러다임 전환 — 백그라운드로 간 에이전트 전통적 챗봇 모델:\n사용자가 입력 모델이 토큰 단위로 응답을 흘려보냄 연결이 끊기면 끝 새로운 현실:\n백그라운드 작업, 크론, 웹훅, 스케줄 루틴 에이전트가 사람과 시간적·공간적으로 분리 사람은 잠들거나 다른 디바이스로 이동해도 작업은 계속 OpenClaw가 WhatsApp 안에서 에이전트를 운영하며 이 분리를 보여준 것이 분기점이었습니다. 이후 업계 전반의 응답:\n회사 비동기 기능 Anthropic Channels(MCP 기반 비동기 메시징), /loop·/schedule, Routines, Remote Control OpenAI Scheduled Tasks Cursor Cloud Background Agents 트랜스포트 미스매치 — HTTP가 깨지는 4가지 장면 Knill의 진단의 핵심. HTTP 요청-응답 모델이 무너지는 시나리오들:\n1. 에이전트가 호출자보다 오래 산다 작업이 끝나기 전에 원본 커넥션이 닫힙니다. 결과는 DB에 쌓이고, 누군가가 폴링해야 발견됩니다.\n2. 에이전트가 푸시를 시작한다 완료된 작업을 사람에게 능동적으로 알려야 합니다. 지금은 이메일·Slack 같은 외부 채널로 우회 — 트랜스포트 계층이 풀고 있는 문제가 아닙니다.\n3. 호출자가 디바이스를 바꾼다 데스크톱에서 시작한 세션을 휴대폰에서 이어받기 — HTTP에는 네이티브 지원이 없습니다. Anthropic은 자체 백엔드 엔지니어링으로 우회.\n4. 한 세션에 여러 사람 팀이 같은 세션에 들어와 협업해야 한다면 fan-out 메시징이 필요합니다. HTTP는 서버가 여러 클라이언트에 push하는 모델이 없습니다.\nOpenClaw가 우아하게 푼 지점: \u0026ldquo;에이전트 작업 수명\u0026rdquo; 과 \u0026ldquo;커넥션 수명\u0026rdquo; 을 분리한 것.\n업계의 두 가지 응답 Anthropic — 호스티드 일원화 세션 상태, 대화 이력, 추론을 Anthropic의 호스팅 플랫폼 안에 중앙집중시켜 Routines와 Remote Control로 풀었습니다. 자기 인프라가 아닌, 그들의 인프라 위에서 비동기성을 누리는 모델.\nCloudflare — 상태 API + 메일 Sessions API — HTTP로 접근 가능한 세션/대화 저장소 Email for Agents — 비동기 알림용 자기 인프라 위에서 쓸 수 있는 빌딩 블록을 제공.\n공통점: 둘 다 durable state를 우선시합니다.\n핵심 분리 — Durable State vs Durable Transport Knill이 도입하는 결정적 어휘:\n개념 다루는 질문 Durable State 에이전트 상태가 어디에 살고, 재시작 시 어떻게 접근하며, 출력은 어디에 저장되는가 Durable Transport 응답 바이트가 어떻게 사람과 에이전트 사이를 오가고, 끊긴 커넥션·디바이스 전환·fan-out·서버 푸시를 어떻게 다루는가 Anthropic과 Cloudflare는 state는 잘 풀지만 transport는 폴링(또는 HTTP polling)에 의존합니다. 그 결과 art of the possible에 못 미치는 경험이 나옵니다 — 디바이스 전환, 다중 참여자, 능동 푸시 같은 시나리오에서.\n현재 솔루션의 절반 문제 \u0026ldquo;현재 솔루션은 세션과 트랜스포트를 단일 HTTP 요청-응답 사이클 안에 녹여 둔다.\u0026rdquo;\nstate durability는 개선됐지만 transport durability는 그대로. 그리고 self-host 가능한 OpenClaw-스타일 채널 모델의 엔터프라이즈 등가물은 아직 없습니다.\nKnill의 제안 — 세션을 1급 프리미티브로 Knill은 자신이 Ably에서 에이전트용 durable transport 솔루션을 만들고 있다고 밝힙니다. 토대는 Ably의 기존 리얼타임 메시징 인프라. 핵심 명제:\n\u0026ldquo;AI와의 \u0026lsquo;세션\u0026rsquo;은 사람과 에이전트가 언제든 접속하고 끊을 수 있는 무언가여야 한다.\u0026rdquo;\n세션이 가져야 할 속성:\n네트워크 중단을 투명하게 견딘다 다중 디바이스·다중 사용자 접근을 네이티브 지원 대화 상태에 접근 가능 사람 ↔ 에이전트 양방향 알림 접근 방식: 세션 상태와 대화 이력을 양방향·내구성·실시간 메시징 인프라 위에 얹는다 — state와 transport 두 절반을 동시에 다룬다.\n아키텍처 패턴 비교 모델 State Transport 한계 HTTP-SSE 챗봇 클라이언트 또는 임시 단일 커넥션 비동기 에이전트에 부적합 OpenClaw 채널 채팅 플랫폼이 보존 채널이 곧 트랜스포트 자기 호스팅이 어려움 Anthropic 호스티드 중앙집중 폴링/HTTP 벤더 종속 Cloudflare Sessions API 분산 키-밸류 HTTP 트랜스포트는 미해결 Ably 세션 (Knill 제안) 메시지 인프라 위에 얹음 양방향 리얼타임 작업 진행 중 새 어휘 정리 Durable state — 끊김을 견디는 영속 에이전트 데이터 Durable transport — 단일 커넥션과 무관하게 견디는 메시지 전달 Async agents — 사람의 동기적 감독에서 분리된 백그라운드 AI Session — 사람과 에이전트의 영속 연결을 표현하는 1급 프리미티브 실행 체크리스트 우리 시스템에서 에이전트 작업 수명 ≠ 커넥션 수명 인 시나리오를 목록화 비동기 결과 전달이 외부 채널(이메일/Slack)에 우회되고 있는지 식별 — 트랜스포트 결함의 신호 디바이스 전환·다중 참여자·서버 푸시가 필요한 사용 사례를 분리 평가 State 솔루션과 Transport 솔루션을 따로 선택 — 한 박스에 묶지 말 것 벤더 호스티드 모델을 쓸 때 이식성 비용을 명시적으로 계산 왜 이 글이 중요한가 대부분의 에이전트 인프라 논의는 모델 품질, 도구 호출, 메모리 에 머무릅니다. Knill의 글은 트랜스포트 계층의 가정을 직접 겨눕니다.\n역사적 진단 — HTTP 채택은 우연이지 적합성이 아니다 명확한 분리 — durable state와 durable transport는 다른 문제 현재 솔루션의 빈자리 — 절반만 풀고 있는 업계의 현 상태 새 1급 프리미티브 — 세션을 양방향 메시징 인프라 위에 두는 방향 인프라의 선택은 아키텍처의 가능성을 결정한다.\n핵심 결론 에이전트는 동기 챗봇에서 비동기 백그라운드 워커로 이동했다 HTTP 요청-응답은 이 전환의 최소 4가지 장면에서 깨진다(생존, 푸시, 디바이스 전환, 다자 참여) Durable state와 Durable transport는 다른 절반의 문제이며, 두 절반을 같이 풀어야 art of the possible에 닿는다 Anthropic·Cloudflare는 state에 강하지만 transport는 폴링에 의존 미래 모양: 세션이 1급 프리미티브, 양방향 리얼타임 메시징이 토대 자기 호스팅 가능한 OpenClaw 등가물은 아직 시장의 빈 자리 — Ably/유사 플레이어가 채우는 중 당신의 에이전트는 비동기로 가고 있는데, 그 통신은 여전히 동기 시대의 그릇 안에 남아 있는가.\n","wordCount":807,"tags":["AI","에이전트","Async","HTTP","Durable Transport","Durable State","Zak Knill","Ably","Anthropic","Cloudflare","OpenClaw","인프라"],"categories":["AI"],"frameworks":["Durable State vs Durable Transport","Session as First-class Primitive"],"mental_models":["Async Agent Lifecycle","Transport-State Separation","Connection Lifetime ≠ Work Lifetime"],"philosophy_type":"infrastructure-design","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["HTTP 요청-응답은 챗봇의 우연적 선택 — 백그라운드 에이전트 시대에는 Durable Transport가 필요","Durable State(작업 결과 저장)와 Durable Transport(알림·푸시·디바이스 간 이동)의 분리가 핵심 설계","HTTP가 깨지는 4가지 장면: 에이전트가 호출자보다 오래 삶, 푸시 시작, 디바이스 변경, 다중 사용자 세션","Anthropic Routines·Cloudflare Sessions API·OpenClaw 채널·Ably 세션 모델 비교 분석"],"related":["posts/anatomy-of-an-agent-harness","posts/zero-alignment-maggie-appleton","posts/probabilistic-engineering-24-7-employee"]},{"title":"한 명의 개발자, 24개의 에이전트, 그리고 제로 얼라인먼트 — Maggie Appleton의 새로운 병목","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/zero-alignment-maggie-appleton/","section":"posts","date":"2026-04-24T17:15:20+09:00","lastmod":"2026-04-24T17:15:20+09:00","description":"GitHub Next의 Maggie Appleton이 던지는 질문 — 한 명이 24개 에이전트를 부린다는 비전은 왜 틀렸는가. 구현이 거의 공짜가 된 시대에 진짜 병목은 '무엇을 만들지 합의하는 일'이며, PR과 이슈는 더 이상 그 합의를 담을 그릇이 아니다. 'Ace' 프로토타입을 통한 멀티플레이어 에이전트 협업의 그림.","summary":"\u0026ldquo;한 명의 개발자가 24개의 Claude를 동시에 부린다.\u0026rdquo; — 2026년 에이전틱 개발 도구 마케팅이 즐겨 그리는 그림입니다. Maggie Appleton(GitHub Next, Staff Research Engineer)은 이 그림이 틀린 문제를 풀고 있다고 말합니다. 구현이 빨라진 만큼, 진짜 병목은 다른 곳으로 옮겨갔습니다 — 무엇을 만들지에 대한 팀의 합의.\n원문: One Developer, Two Dozen Agents, Zero Alignment — Maggie Appleton (2026)\n핵심 도발 \u0026ldquo;Software is not made by one person in a vacuum. It\u0026rsquo;s a team sport.\u0026rdquo;\n","content":"\u0026ldquo;한 명의 개발자가 24개의 Claude를 동시에 부린다.\u0026rdquo; — 2026년 에이전틱 개발 도구 마케팅이 즐겨 그리는 그림입니다. Maggie Appleton(GitHub Next, Staff Research Engineer)은 이 그림이 틀린 문제를 풀고 있다고 말합니다. 구현이 빨라진 만큼, 진짜 병목은 다른 곳으로 옮겨갔습니다 — 무엇을 만들지에 대한 팀의 합의.\n원문: One Developer, Two Dozen Agents, Zero Alignment — Maggie Appleton (2026)\n핵심 도발 \u0026ldquo;Software is not made by one person in a vacuum. It\u0026rsquo;s a team sport.\u0026rdquo;\n\u0026ldquo;The hard question is no longer how to build it. It\u0026rsquo;s should we build it.\u0026rdquo;\n\u0026ldquo;Agreeing on what to build is the new bottleneck.\u0026rdquo;\n세 문장이 글 전체의 뼈대입니다. 생산성을 개인 단위로 N배로 늘리는 비전은 소프트웨어가 어떻게 만들어지는지에 대한 오해 위에 서 있습니다.\n\u0026ldquo;여성 9명이 한 달에 아기를 만든다\u0026quot;는 논리 병렬화가 모든 문제를 푸는 것은 아닙니다. Appleton은 고전적 격언을 빌려옵니다 — 어떤 작업은 본질적으로 순차적이고 합의 의존적이라 인력을 늘려도 단축되지 않는다. 코드 생성은 병렬화되지만, 무엇이 옳은가에 대한 결정은 그렇지 않습니다.\n\u0026ldquo;More individual output doesn\u0026rsquo;t solve problems that require communication and coordination.\u0026rdquo;\n구현이 거의 공짜가 됐다 — 그래서? Appleton의 진단:\n과거 지금 구현 비용이 비쌌다 구현 비용이 빠르게 0에 수렴 \u0026ldquo;어떻게 만들까\u0026quot;가 어려운 질문 \u0026ldquo;과연 만들어야 하는가\u0026ldquo;가 어려운 질문 생산 비용이 결정의 압력을 만들었다 기회비용이 곧 실비용이 된다 생산이 싸지면 잘못 만든 것의 비용이 상대적으로 더 커집니다. 만든 건 무엇이든 누군가는 유지·검증·운영해야 하기 때문입니다.\n얼라인먼트 위기 — 동기화 지점이 사라졌다 전통적 워크플로는 느렸지만 자연스러운 얼라인먼트 모멘트들을 갖고 있었습니다.\nSlack 대화 미팅 Draft PR 코드 리뷰 이 모든 것은 \u0026ldquo;코드가 만들어지기 전·중간\u0026quot;에 사람들이 의도와 맥락을 맞추는 장소였습니다.\n에이전틱 워크플로는 이 시간을 분 단위로 압축합니다 — 이슈에서 PR까지 몇 분. 그 결과 초기 계획 단계의 토론 자체가 사라집니다.\n\u0026ldquo;Agents have made the cost of not being aligned higher.\u0026rdquo;\n빨라진 것은 코드 생성이지만, 빨라진 만큼 합의의 공백이 생깁니다.\n부서진 프리미티브 — PR과 이슈는 그릇이 아니다 GitHub, Slack, Jira, Linear는 모두 사람의 속도에 맞춰 설계된 도구입니다. Appleton의 핵심 비판:\n\u0026ldquo;We\u0026rsquo;re funnelling masses of agentic outputs into platforms built for an outdated way of building software.\u0026rdquo;\n\u0026ldquo;The PR and the issue are the wrong primitives that can\u0026rsquo;t handle the speed, shape, and volume of agentic work.\u0026rdquo;\n문제의 형태:\n이슈는 하나의 작업 단위 — 에이전트가 100개를 동시에 처리하면 의미가 무너진다 PR은 사후 검토용 단위 — 생성 속도와 검토 용량의 비대칭이 즉시 드러난다 두 프리미티브 모두 코드가 만들어진 후에 작동 — 만들기 전의 합의를 담지 못한다 미스얼라인먼트의 두 가지 결과 낭비된 작업(wasted work) — 누구도 요청하지 않은 기능, 진짜 문제를 풀지 못하는 기능 조정 부채(coordination debt) — 머지 컨플릭트, 중복 작업, 맥락 없는 PR 더미 생산이 빨라질수록 두 비용 모두 비례 이상으로 증가합니다.\n해법의 프레임 — 사후 리뷰가 아닌 사전 얼라인먼트 Appleton의 처방: 도구는 구현 전(pre-implementation) 합의 공간을 1급으로 다뤄야 한다.\n핵심 원리:\n계획과 빌드는 순차가 아니라 연속적 사이클 본질적 맥락 — 비즈니스 제약, 정치 역학, 제품 비전, 유저 리서치, 조직 역사 — 은 사람의 머릿속에 산다 에이전트는 이 맥락을 자율적으로 발견할 수 없다 → 사람이 명시적으로 제공해야 하는 자료 Ace — GitHub Next의 협업 에이전트 프로토타입 이 글의 실험적 결론은 Ace라는 GitHub Next 리서치 프로토타입의 시연입니다. 멀티플레이어 에이전틱 개발이 어떤 모습인지 구체적으로 보여줍니다.\n요소 설명 Sessions 격리된 microVM 위의 별도 git 브랜치를 백킹으로 한 멀티플레이어 채팅 채널 Shared compute 팀 전원이 동일한 클라우드 컴퓨터에 접근 — \u0026ldquo;works on my machine\u0026rdquo; 문제 제거 Multiplayer prompting 여러 사용자가 같은 에이전트에게 지시 가능, 에이전트는 전체 대화 이력을 읽음 Live previews 모두에게 보이는 실시간 렌더링 Integrated terminal 공유된 명령 실행과 출력 Plan documents 구현 전에 협업 편집되는 기능 명세 Dashboard summaries 팀 활동·미완료 작업·주간 진척의 AI 브리프 시연 시나리오 \u0026ldquo;Calm Hacker News\u0026rdquo; 앱(최근 3개월의 톱 스토리만 보여주는 변형)에 컬러 테마와 가변 기간 옵션을 협업 에이전트 인터랙션으로 추가하는 데모. 핵심 메시지: 에이전트는 보이지 않는 부하 직원이 아니라, 팀 회의에 참여하는 멤버여야 한다.\n새로운 용어들 Coordination debt — 합의 없이 누적되는 통합·중복·맥락 손실 비용 Alignment bottleneck — 구현이 아니라 무엇을 만들지의 합의가 새 병목 MicroVM isolation — 세션별 격리된 가상 환경 Multiplayer prompting — 여러 사람이 한 에이전트를 동시에 지휘 Social information fabric — 팀의 머릿속에 분산된 맥락을 묶는 사회적 정보 결 작은 솔직함 — \u0026ldquo;Agents are shit at CSS\u0026rdquo; Appleton은 에이전트의 한계를 솔직하게 인정합니다. 기술적 만능 서사가 아니라, 현재의 도구로 무엇을 팀이 더 잘할 수 있는가라는 실용주의 위에 글이 놓여 있다는 신호입니다.\n전략적 비전 — 품질이 새 차별점 \u0026ldquo;Quality becomes the new differentiator.\u0026rdquo;\n생산 비용이 떨어진 시간을 어디에 재투자할 것인가? Appleton의 답:\n더 엄격한 사고 더 깊은 리서치 장인정신(craftsmanship) 천 개의 평범한 것이 아니라, 소수의 탁월한 것을 함께 깊이 생각하며 만드는 환경.\n실행 체크리스트 팀의 워크플로에서 사전 합의 모멘트(plan doc, kickoff)를 명시적 단계로 박아 넣기 에이전트에게 던지는 프롬프트를 개인 채널이 아닌 공유 채널에서 작성 — 팀 전체가 맥락에 접근 가능하도록 PR/이슈를 유일한 협업 단위로 쓰지 말 것 — plan, session, dashboard 같은 더 풍부한 그릇을 시도 \u0026ldquo;기능을 더 만들 시간\u0026quot;이 아니라 \u0026ldquo;기능을 덜 만들고 더 잘 생각할 시간\u0026rdquo; 을 명시적으로 예산화 에이전트가 발견할 수 없는 맥락(정치, 역사, 비전)을 명시적 문서로 추출 왜 이 글이 중요한가 대부분의 에이전틱 도구 담론은 \u0026ldquo;한 명을 N배로\u0026rdquo; 라는 축에 갇혀 있습니다. Appleton은 그 축 자체가 잘못 그어졌다고 말합니다.\n문제의 재정의 — 병목은 구현이 아니라 합의 프리미티브 비판 — PR/이슈는 에이전틱 작업량을 담을 그릇이 아니다 협업의 1급화 — 에이전트는 팀에 합류해야지, 개인을 증폭해서는 안 된다 품질로의 재투자 — 절약된 시간을 더 많은 출하가 아니라 더 깊은 사고에 쓴다 GitHub Next의 Ace 같은 도구가 실제로 이 그림을 구현할 수 있을지는 별개의 문제이지만, 문제 정의 자체가 옳다면 도구의 진화 방향은 달라집니다.\n핵심 결론 에이전트가 빨라질수록 합의되지 않은 것의 비용도 같이 빨라진다 \u0026ldquo;한 명 + 24개 에이전트\u0026rdquo; 는 팀 스포츠의 룰을 잘못 읽은 비전 현재 협업 도구(PR, 이슈, Slack)는 에이전트 작업의 속도·형태·양을 담을 그릇이 아니다 해법은 사후 리뷰가 아니라 사전 얼라인먼트 — 계획과 빌드의 연속적 사이클 에이전트가 모르는 맥락은 사람의 머릿속에 살며, 그것을 공유 가능한 형태로 끌어내는 것이 도구의 새 역할 품질이 새 차별점 — 천 개의 평범함이 아니라 소수의 탁월함 당신의 팀은 더 많은 코드가 아니라 더 좋은 합의를 만드는 도구를 가지고 있는가.\n","wordCount":954,"tags":["Maggie Appleton","AI","에이전트","GitHub Next","Ace","Alignment","Coordination Debt","협업도구","팀스포츠","소프트웨어공학"],"categories":["AI"],"frameworks":["Alignment Bottleneck","Coordination Debt","Multiplayer Prompting"],"mental_models":["Software as Team Sport","Shifting Bottleneck","Quality as Differentiator"],"philosophy_type":"design-philosophy","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["한 명의 개발자, 24개의 에이전트, 그리고 제로 얼라인먼트 — Maggie Appleton의 새로운 병목의 핵심 문제의식은 \"GitHub Next의 Maggie Appleton이 던지는 질문 — 한 명이 24개 에이전트를 부린다는 비전은 왜 틀렸는가. 구현이 거의 공짜가 된 시대에 진짜 병목은 '무엇을 만들지 합의하는 일'이며, PR과 이슈는 더 이상 그 합의를 담을 그릇이 아니다. 'Ace' 프로토타입을 통한 멀티플레이어 에이전트 협업의 그림.\"다","본문은 핵심 도발 → \"여성 9명이 한 달에 아기를 만든다\"는 논리 → 구현이 거의 공짜가 됐다 — 그래서? 흐름으로 논지를 전개한다","Maggie Appleton, AI, 에이전트 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/probabilistic-engineering-24-7-employee","posts/fowler-fragments-cognitive-debt-system-3","posts/anatomy-of-an-agent-harness"]},{"title":"인지 부채와 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-24T14:52:53+09:00","lastmod":"2026-04-24T14:52:53+09:00","description":"Martin Fowler의 2026-04-02 Fragments 정리 — Storey의 Technical/Cognitive/Intent 삼중 부채, Shaw \u0026 Nave의 System 3와 Cognitive Surrender, Ajey Gore가 말하는 '검증이 비싸진 시대', 그리고 LLM과 함께 성장하는 Ubiquitous Language.","summary":"Martin Fowler가 간헐적으로 올리는 Fragments 시리즈는 최근 읽은 글들에 대한 짧은 주석 모음입니다. 2026년 4월 2일자는 유독 밀도가 높습니다 — 부채의 재정의, 사고 시스템의 확장, 검증의 경제학, 그리고 언어와 이름 짓기에 관한 다섯 개의 조각이 한 페이지에 놓여 있습니다. LLM이 코드를 생성하는 시대에 인간이 무엇에 집중해야 하는지에 대한 하나의 일관된 그림이 드러납니다.\n원문: Fragments: April 2 — Martin Fowler (2026)\n조각 1. 시스템 건강의 세 층위 — Technical / Cognitive / Intent Debt Margaret-Anne Storey의 논문이 제시하는 프레임은 기술 부채(technical debt) 개념의 한계를 정면으로 겨냥합니다.\n","content":"Martin Fowler가 간헐적으로 올리는 Fragments 시리즈는 최근 읽은 글들에 대한 짧은 주석 모음입니다. 2026년 4월 2일자는 유독 밀도가 높습니다 — 부채의 재정의, 사고 시스템의 확장, 검증의 경제학, 그리고 언어와 이름 짓기에 관한 다섯 개의 조각이 한 페이지에 놓여 있습니다. LLM이 코드를 생성하는 시대에 인간이 무엇에 집중해야 하는지에 대한 하나의 일관된 그림이 드러납니다.\n원문: Fragments: April 2 — Martin Fowler (2026)\n조각 1. 시스템 건강의 세 층위 — Technical / Cognitive / Intent Debt Margaret-Anne Storey의 논문이 제시하는 프레임은 기술 부채(technical debt) 개념의 한계를 정면으로 겨냥합니다.\n부채 유형 어디에 사는가 언제 쌓이는가 Technical Debt 코드 안에 구현 결정이 향후 변경 가능성을 희생시킬 때 Cognitive Debt 사람 안에 공유된 이해가 재보충되는 속도보다 빠르게 침식될 때 Intent Debt 산출물(artifacts) 안에 목표와 제약이 제대로 포착·유지되지 않을 때 \u0026ldquo;Cognitive debt accumulates when shared understanding erodes faster than it is replenished.\u0026rdquo;\nLLM이 대량의 코드를 만들어내면 technical debt는 오히려 줄어 보일 수 있다 — 리팩터링 비용이 내려가기 때문. 그러나 그 코드를 누가 이해하고 있는가, 무엇을 위해 만들어진 것인가는 함께 줄어들지 않습니다. 오히려 가속화된 생성이 cognitive/intent 두 층위를 먼저 고갈시킵니다.\n이 프레임의 힘은 \u0026ldquo;기술 부채를 줄였다\u0026quot;는 지표가 시스템 건강의 착시일 수 있음을 드러낸다는 데 있습니다.\n조각 2. Tri-System Cognition — 칸네만을 넘어서는 \u0026lsquo;System 3\u0026rsquo; Wharton의 Shaw \u0026amp; Nave는 Kahneman의 두-시스템 모델에 LLM을 System 3로 추가합니다.\nSystem 1 — 빠르고 직관적인 판단 System 2 — 느리고 의식적인 숙고 System 3 — 외부 인공 추론(artificial reasoning) 그리고 이 확장에서 가장 중요한 구분은 두 가지 사용 방식입니다.\n모드 정의 성격 Cognitive Offloading 숙고 과정에서 인지를 전략적으로 위임 의도적 — System 2가 여전히 작동 Cognitive Surrender 외부 생성 추론에 무비판적으로 의존, System 2를 우회 수동적 — 숙고 자체가 삭제됨 \u0026ldquo;Cognitive surrender is uncritical reliance on externally generated artificial reasoning, bypassing System 2.\u0026rdquo;\n중요한 차이: 결과물은 같아 보여도 위임과 항복은 다릅니다. 같은 Copilot 제안을 받아들이는 두 엔지니어 — 한 명은 검토 후 통합했고, 다른 한 명은 읽지 않고 승인했다면, 후자는 cognitive debt를 만들고 있습니다(조각 1과 직접 연결됩니다).\n실무적 함의: 팀 문화를 평가할 때 \u0026ldquo;AI를 얼마나 쓰는가\u0026quot;가 아니라 \u0026ldquo;System 2가 어디서 유지되는가\u0026rdquo; 를 물어야 합니다.\n조각 3. \u0026lt;\u0026gt; 아이콘의 이상함 — 작은 문화 관찰 Fowler의 짧은 관찰. 코드나 개발자를 상징하는 아이콘에 왜 \u0026lt;\u0026gt; 기호가 쓰이는가? 어떤 주류 프로그래밍 언어도 이 기호로 프로그램 요소를 감싸지 않습니다. 이것은 HTML/XML의 유산이며, 프로그래머는 실제로 HTML로 코딩하지 않는다.\n사소해 보이지만 시사점이 있습니다 — 표현이 상징을 만든다. 우리가 도구를 기술하는 언어는 결국 도구가 무엇인지에 대한 집단 이미지를 결정합니다(조각 6의 이름 짓기 주제와 호응합니다).\n조각 4. 검증이 비싸졌다 — Ajey Gore의 경제학 Ajey Gore의 \u0026ldquo;The Expensive Thing\u0026rdquo;. 코딩 에이전트가 실행을 담당하게 되면서 비용의 중심이 생산에서 검증으로 이동한다는 주장.\n\u0026ldquo;자카르타 교통에서의 ETA 알고리즘이 \u0026lsquo;정확(correct)\u0026lsquo;하다는 것과 호찌민시에서의 그것은 같은 의미인가?\u0026rdquo;\nGore의 테제:\n정답(correct)은 하나의 정의가 아니라 수천 개의 맥락-의존적 정의 맥락적 올바름을 정의하는 일은 \u0026ldquo;에이전트가 당신을 대신할 수 없는 판단의 영역\u0026rdquo; 따라서 조직은 아래 질문의 축을 바꿔야 한다 이전 조직의 질문 새로운 조직의 질문 \u0026ldquo;우리가 무엇을 출하했는가?\u0026rdquo; \u0026ldquo;우리가 무엇을 검증했는가?\u0026rdquo; 팀 구성의 재편 Gore의 도발적 제안:\n\u0026ldquo;10명의 엔지니어가 기능을 만들던 팀은, 이제 3명의 엔지니어와 7명의 수락 기준(acceptance criteria)을 정의하는 사람들로 바뀐다.\u0026rdquo;\n이는 \u0026ldquo;엔지니어의 역할이 상향 이동한다\u0026quot;는 흔한 서사를 조직도(org chart) 수준으로 끌어내립니다.\nFowler의 이견 Fowler는 한 가지에서 정중하게 반대합니다 — Gore가 레거시 현대화(legacy modernization) 의 가치를 낮게 본 부분. Fowler의 근거: LLM은 레거시 코드의 재작성 보다 이해 에서 탁월하다는 증거가 쌓이고 있다. 즉 레거시는 버리는 대상이 아니라, 처음으로 대규모로 해독될 수 있는 자산이 됐습니다.\n조각 5. 소스 코드의 미래 — LLM-친화 언어 David Cassel(The New Stack)의 개관 기사에 대한 주석. 두 흐름이 대립합니다.\n새로운 LLM-전용 언어를 설계해야 한다는 입장 이미 존재하는 엄격한 타입 언어(TypeScript, Rust)가 최적이라는 입장 Fowler는 결론을 내리지 않지만, 이 질문의 틀 자체가 흥미롭습니다 — \u0026ldquo;프로그래밍 언어는 누구를 위해 설계되는가\u0026quot;라는 근본 질문을 다시 열기 때문입니다. 인간 가독성, 컴파일러 친화성, 그리고 이제 LLM 생성·검증 친화성까지 세 축의 트레이드오프가 설계 공간을 규정합니다.\n조각 6. 언어와 함께 자라는 코드 — Unmesh의 Ubiquitous Language 마지막 조각은 Fowler 본인이 Unmesh Joshi와 공저한 \u0026ldquo;Growing a Language with LLMs\u0026rdquo; 의 핵심을 인용하는 형태입니다. DDD의 Ubiquitous Language 개념을 LLM 시대로 확장합니다.\n*\u0026ldquo;프로그래밍은 구문을 타이핑하는 일이 아니라 해법을 조형(shaping a solution)하는 일이다. 이름은 의도를 드러내도록 선택되어야 한다. 좋은 이름은 복잡성을 관통한다. 가장 창의적 행위는 **해법의 구조가 문제와 대응되도록 드러내는 이름의 직조(weaving)*다.\u0026rdquo;\nLLM 시대의 함의:\n코드의 양이 아니라 이름과 추상의 질이 인간이 시스템을 붙잡는 손잡이가 된다 LLM은 구문을 생성할 수 있지만, 무엇을 무엇이라 부를지는 여전히 사람이 정한다 조각 1의 intent debt에 대한 직접적 처방 — 의도를 드러내는 이름이 바로 intent의 포착 수단 여섯 조각이 그리는 하나의 그림 Fowler는 명시적으로 연결 짓지 않지만, 조각들은 한 방향을 가리킵니다.\n문제 진단 (조각 1) — 기술 부채만 보던 시야를 cognitive/intent까지 확장 인지 모델 (조각 2) — LLM을 System 3로 두되, 항복이 아니라 위임으로 다룰 것 문화적 관찰 (조각 3) — 도구를 부르는 언어가 우리의 상상을 결정 경제학적 귀결 (조각 4) — 비용은 생산에서 검증으로 이동, 조직도까지 바뀐다 재료의 선택 (조각 5) — 어떤 언어가 인간-LLM 공동 작업에 적합한가 실천의 핵심 (조각 6) — 이름과 추상이 intent를 담는 그릇 : 코드는 싸지고, 이해와 의도와 검증이 비싸졌다. 그리고 이 세 가지는 전부 사람 쪽에 남아 있는 일이다.\n인용 모음 \u0026ldquo;Cognitive debt accumulates when shared understanding erodes faster than it is replenished.\u0026rdquo; — Storey\n\u0026ldquo;Cognitive surrender is uncritical reliance on externally generated artificial reasoning, bypassing System 2.\u0026rdquo; — Shaw \u0026amp; Nave\n\u0026ldquo;Correct isn\u0026rsquo;t one definition — it\u0026rsquo;s thousands of definitions, all shifting, all context-dependent.\u0026rdquo; — Gore\n\u0026ldquo;Programming is shaping a solution. The most creative act is the continual weaving of names that reveal the solution structure.\u0026rdquo; — Unmesh\n실행 체크리스트 팀 회고에 \u0026ldquo;우리가 이번 스프린트에 무엇을 검증했는가?\u0026rdquo; 를 질문으로 추가 AI 제안 수용 플로우에 cognitive surrender 방지용 최소 체크포인트 삽입(단 5분이라도 System 2를 강제) 핵심 도메인 용어의 ubiquitous language 사전을 LLM 프롬프트와 코드 주석 양쪽에 동기화 레거시 자산을 \u0026ldquo;교체 후보\u0026quot;가 아니라 \u0026ldquo;LLM으로 해독할 자산\u0026rdquo; 으로 재분류 리팩터링 보고서에 intent debt 지표(문서-코드 정렬, 명칭 일관성)를 기술 부채와 분리해 기록 왜 이 Fragments가 중요한가 Fowler는 주장을 펼치지 않고 배치만 합니다. 그러나 배치의 순서가 논지입니다 — 부채의 재정의 → 사고 시스템의 확장 → 검증의 경제학 → 이름 짓기. AI 엔지니어링 담론이 \u0026ldquo;생산성 몇 배\u0026quot;에서 맴도는 사이, 이 조각들은 사람 쪽에 남는 일의 목록을 조용히 완성합니다.\n코드가 싸진 시대에 당신의 조직은 무엇을 검증했는지 말할 수 있는가 — 그리고 그것을 부르는 이름을 가지고 있는가.\n","wordCount":1001,"tags":["Martin Fowler","Cognitive Debt","Intent Debt","System 3","Cognitive Surrender","AI","LLM","Verification","Ubiquitous Language","소프트웨어공학"],"categories":["AI"],"frameworks":["Three Layers of System Health","Tri-System Cognition","Ubiquitous Language"],"mental_models":["Cognitive Debt","Intent Debt","Cognitive Surrender","Cognitive Offloading","Generation-Review Asymmetry"],"philosophy_type":"epistemology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["인지 부채와 System 3 — Martin Fowler가 골라낸 '검증의 시대'를 위한 다섯 개의 조각의 핵심 문제의식은 \"Martin Fowler의 2026-04-02 Fragments 정리 — Storey의 Technical/Cognitive/Intent 삼중 부채, Shaw \u0026 Nave의 System 3와 Cognitive Surrender, Ajey Gore가 말하는 '검증이 비싸진 시대', 그리고 LLM과 함께 성장하는 Ubiquitous Language.\"다","본문은 조각 1. 시스템 건강의 세 층위 — Technical / Cognitive / Intent Debt → 조각 2. Tri-System Cognition — 칸네만을 넘어서는 'System 3' → 조각 3. `\u003c\u003e` 아이콘의 이상함 — 작은 문화 관찰 흐름으로 논지를 전개한다","Martin Fowler, Cognitive Debt, Intent Debt 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/probabilistic-engineering-24-7-employee","posts/ai-knowledge-layer","posts/hidden-llm-api-costs"]},{"title":"확률적 엔지니어링과 24/7 직원 — 생성은 밤에도 멈추지 않지만, 검증은 그렇지 못하다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/probabilistic-engineering-24-7-employee/","section":"posts","date":"2026-04-18T14:30:00+09:00","lastmod":"2026-04-18T14:30:00+09:00","description":"Tim Davis가 말하는 확률적 엔지니어링의 시대 — 에이전트가 밤새 PR을 생성하지만 검증 용량은 그만큼 확장되지 않는다. 생성-검증 비대칭, 역할 파편화, 조용한 성능 저하, 그리고 '다음 모델을 위해 지금부터 근육을 키워야 한다'는 제안.","summary":"소프트웨어는 결정론적 공학에서 확률적 공학으로 전환되고 있습니다. 에이전트는 사람이 잠든 사이에도 코드를 생성하지만, 그것을 검증할 용량은 같이 자라지 않습니다. Tim Davis는 이 비대칭이 역할, 조직, 그리고 엔지니어가 살아남기 위해 쌓아야 할 근육 자체를 재편한다고 주장합니다.\n원문: Probabilistic Engineering and the 24-7 Employee — Tim Davis (2026)\n핵심 논제 \u0026ldquo;지식 노동 역사상 처음으로, 집에 간 사람이 자기 뇌의 유일한 사본을 들고 가지 않는다.\u0026rdquo;\n저자가 운영하는 Compound Loop는 밤새 자율적으로 PR을 생성하는 코딩 시스템입니다. 24/7 근무하는 사람이 생긴 것이 아니라, 병렬화된 에이전트 노동이 생긴 것 — 이 차이가 모든 논의의 출발점입니다.\n","content":"소프트웨어는 결정론적 공학에서 확률적 공학으로 전환되고 있습니다. 에이전트는 사람이 잠든 사이에도 코드를 생성하지만, 그것을 검증할 용량은 같이 자라지 않습니다. Tim Davis는 이 비대칭이 역할, 조직, 그리고 엔지니어가 살아남기 위해 쌓아야 할 근육 자체를 재편한다고 주장합니다.\n원문: Probabilistic Engineering and the 24-7 Employee — Tim Davis (2026)\n핵심 논제 \u0026ldquo;지식 노동 역사상 처음으로, 집에 간 사람이 자기 뇌의 유일한 사본을 들고 가지 않는다.\u0026rdquo;\n저자가 운영하는 Compound Loop는 밤새 자율적으로 PR을 생성하는 코딩 시스템입니다. 24/7 근무하는 사람이 생긴 것이 아니라, 병렬화된 에이전트 노동이 생긴 것 — 이 차이가 모든 논의의 출발점입니다.\n역할의 상향 이동이 아니라 파편화 낙관적 서사는 \u0026ldquo;모두가 더 높은 추상 단계로 올라간다\u0026quot;고 말합니다. Davis의 관찰은 다릅니다.\n상위 3분위 — 에이전트 함대를 효과적으로 지휘. 위로 이동. 중간 티어 — spec writer, reviewer, agent babysitter로 분화. 아래로 압축. \u0026ldquo;에이전트 함대를 효과적으로 운용하는 상위 티어와 그 배기가스를 관리하는 중간 티어 사이의 임금 격차는, 이전 시대의 엔지니어–영업 격차보다 더 벌어질 것이다.\u0026rdquo;\n이는 \u0026ldquo;재교육하면 된다\u0026quot;는 통념을 정면으로 거스르는 진단입니다.\nJevons Paradox — 코드에 적용된 버전 1865년 William Stanley Jevons는 증기기관의 효율이 올라갈수록 석탄 소비가 늘었다는 것을 관찰했습니다. Davis는 같은 역설을 코드에 적용합니다.\n생성 비용이 떨어지면 팀이 시도하는 양이 늘어난다 출하되는 양이 늘어나는 것이 아니다 레버리지 포인트는 이제 선택과 방향성(selection and direction) 으로 이동한다 즉 \u0026ldquo;더 많은 코드를 짜는 능력\u0026quot;은 더 이상 경쟁 우위가 아니며, 무엇을 만들지 결정하고 검증하는 능력이 가치의 핵심으로 옮겨갑니다.\n생성-검증 비대칭 (Generation-Review Asymmetry) 축 에이전트 인간 500줄짜리 그럴듯한 PR 1분 이내 작성 불가한 속도 그 안의 미묘한 버그 적발 불확실 시니어 수 시간 컨텍스트 요구량 선형 코드베이스가 에이전트産이 될수록 초선형 \u0026ldquo;리뷰는 출력 대비 선형 이하로 확장된다(worse than linearly).\u0026rdquo;\n결과적으로 시스템은 사람이 신뢰할 수 있게 평가할 수 있는 양보다 많이 생산하고, 정확성은 보증되지 않고 확률적이 됩니다. 코드베이스는 \u0026ldquo;동작하는 것을 아는 대상\u0026quot;에서 \u0026ldquo;정확한 확률조차 말할 수 없는 상태로 동작한다고 믿는 대상*\u0026ldquo;이 됩니다.\n조용한 실패 모드 — 폭발이 아니라 누수 이미 관측된 실패:\n레이스 컨디션 — 10번 중 9번은 테스트 통과 예상 밖 프롬프트 분포에서 기능 실패 1/1000행 수준의 조용한 데이터 손상 — 몇 주 뒤에야 발견 이 모드의 공통점은 급격한 붕괴가 아니라 느리고 조용한 성능 저하라는 것입니다.\n생성률은 오르고 리뷰 품질은 내려가고 미발견 결함은 누적되고 신뢰는 고객·감사·운영사고로 드러날 때까지 조용히 무너진다 그때쯤 기술 부채는 이미 상당합니다.\n산업의 삼분 — Deterministic / Probabilistic / Convergence 모든 코드가 확률적이 되는 것은 아닙니다.\n티어 영역 향후 궤적 Deterministic 항공전자, 의료기기, 금융인프라, 원자력 무기한 결정론적 유지 Probabilistic 컨슈머 SW, SaaS, 마케팅, 내부 도구 이미 확률적으로 운용 중 Convergence 보험, 헬스케어, 엔터프라이즈 인프라 경계가 점진적으로 이동 확률적 방법을 결정론적 영역에 일반화하는 것이 가장 위험한 조직적 실수입니다.\nAgentic Fleet — 공장 자동화가 아니라 함대 지휘 Davis는 이 전환을 공장 자동화(노동자를 제거하는 구조)로 보지 않습니다. 은유는 함대 지휘(fleet command):\n작업별 에이전트 조정 메커니즘과 계층 사람이 잠드는 동안 돌아가는 야간 당직 교대 즉 관리할 대상이 \u0026ldquo;팀\u0026quot;에서 \u0026ldquo;함대\u0026quot;로 바뀐다는 것.\n도구가 아직 없다는 솔직한 고백 \u0026ldquo;새로운 CI/CD는 아직 도구가 아닙니다. 지금으로서는 냉혹한 회의주의 문화이자, 우리가 실시간으로 그 문화를 대체할 무언가를 만들어가고 있다는 솔직한 인정입니다.\u0026rdquo;\n문화가 도움이 됩니다 — 작은 병합, 엄격한 게이트, 관찰 가능성, 롤백 규율, 완성도에 대한 냉혹한 회의주의. 하지만 특정 팀 규모를 넘으면 확장성이 떨어진다. 확률적 코드 평가를 위한 현재 도구는 필요한 수준에 비해 원시적입니다.\n이 공백을 메우는 사람이 향후 10년 소프트웨어의 운영 체제를 정의하게 될 것이라는 프레이밍.\n제안 — 지금 아직 없는 모델을 위해 근육을 키워라 Davis의 핵심 처방:\n1. Build for the model you don\u0026rsquo;t have yet 명세 규율(specification discipline), 관측 가능성, 롤백 절차, 리뷰 문화를 지금 투자 2026년용이 아니라 2027–2028년용 스캐폴딩 근거: \u0026ldquo;지금 모델은 당신이 일할 가장 약한 모델이다\u0026rdquo; — 지금의 수요 대비 과투자가 다음 레버리지가 된다 2. Hard-mode 스킬 보존 가끔은 에이전트 없이 어려운 일을 하라 마찰 없이는 취향·판단·장인정신이 형성되지 않는다 \u0026ldquo;직접 만들지 않으면, 만들어진 것을 평가하는 능력을 잃는다.\u0026rdquo; 3. 새로운 도제 모델 전통적 구조(주니어가 출하, 시니어가 리뷰)는 주니어가 에이전트를 통해 출하하는 순간 깨집니다. 조직은 다음 세대의 장인정신을 어떻게 길러낼지 새로 설계해야 합니다.\n기억할 문장들 \u0026ldquo;코드베이스는 동작한다는 것을 아는 대상에서, 정확한 확률조차 말할 수 없는 채로 동작한다고 믿는 대상이 된다.\u0026rdquo;\n\u0026ldquo;당신은 지금 가진 모델을 다루기 위해 조직적 근육을 키우는 것이 아니라, 아직 없는 모델을 다루기 위해 키우는 것이다.\u0026rdquo;\n\u0026ldquo;취향은 잘 다듬어진 초안에 approve를 누르면서 학습되지 않는다. 판단력은 기계의 그럴듯한 답을 5초 만에 수용하면서 발달하지 않는다.\u0026rdquo;\n\u0026ldquo;이 시대의 무관성(irrelevancy)은 자기 도착을 알리지 않는다 — 1년 전만 해도 눈에 띄게 더 낫지 않았던 팀들을 점점 따라잡지 못하는 모습으로 찾아온다.\u0026rdquo;\n실행 체크리스트 현재 리뷰 용량 × 생성 속도를 측정 — 비대칭 지수(asymmetry ratio) 를 수치화 조용한 실패 모드를 탐지할 관측 지표 설계 (데이터 정합성, 분포 드리프트, 회귀 적발률) 결정론적 티어와 확률적 티어의 경계선을 내부적으로 선언 — 어떤 시스템에 어떤 방법을 허용하는가 주니어 훈련 경로를 에이전트 없는 구간 포함으로 재설계 롤백·명세·리뷰 문화에 현재 수요 대비 과투자 — 다음 모델 세대를 전제로 왜 이 글이 중요한가 대부분의 AI 엔지니어링 담론은 \u0026ldquo;생산성 2배, 10배\u0026rdquo; 에 머무릅니다. Davis는 그 너머를 봅니다.\n진단 프레임 — 실패를 폭발이 아니라 조용한 누수로 재정의 조직적 결과 — 상향 이동이 아니라 파편화, 임금 격차 확대 문화의 한계 — 더 엄격한 리뷰로 풀 수 없는 규모의 문제가 온다는 것을 인정 도구 공백의 크기 — \u0026ldquo;새로운 CI/CD는 아직 도구가 아니다\u0026rdquo; 라는 한 문장으로 업계의 가장 큰 미해결 과제를 짚음 유토피아도 디스토피아도 아닙니다. 다만 코드와 확실성 사이의 계약이 깨졌고, 업계는 아직 이 청산을 시작하지도 않았다는 냉정한 진단.\n핵심 결론 전환의 본질은 속도가 아니라 생성-검증 비대칭 실패는 폭발이 아니라 조용한 성능 저하로 온다 상향 이동 서사는 일부 사실이지만, 더 많은 사람은 리뷰/베이비시팅으로 파편화 문화는 도구의 대체재일 뿐 — 팀 규모를 넘으면 확장되지 않는다 지금 투자할 것은 다음 모델 세대를 다룰 운영 근육 — 관측성, 명세 규율, 롤백, 리뷰 문화 장인정신은 마찰 없이 형성되지 않으므로, 가끔은 에이전트 없이 어려운 일을 해야 한다 코드베이스가 아는 것에서 믿는 것으로 바뀌었다는 사실을, 당신의 조직은 아직 인정했는가.\n","wordCount":909,"tags":["AI","에이전트","Probabilistic Engineering","소프트웨어공학","Tim Davis","Compound Loop","코드 리뷰","Jevons Paradox","조직 설계","주니어 훈련"],"categories":["AI"],"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"],"philosophy_type":"strategic-foresight","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["확률적 엔지니어링과 24/7 직원 — 생성은 밤에도 멈추지 않지만, 검증은 그렇지 못하다의 핵심 문제의식은 \"Tim Davis가 말하는 확률적 엔지니어링의 시대 — 에이전트가 밤새 PR을 생성하지만 검증 용량은 그만큼 확장되지 않는다. 생성-검증 비대칭, 역할 파편화, 조용한 성능 저하, 그리고 '다음 모델을 위해 지금부터 근육을 키워야 한다'는 제안.\"다","본문은 핵심 논제 → 역할의 상향 이동이 아니라 파편화 → Jevons Paradox — 코드에 적용된 버전 흐름으로 논지를 전개한다","AI, 에이전트, Probabilistic Engineering 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/anatomy-of-an-agent-harness","posts/ai-capability-not-cost-reduction","posts/ai-agents-future-context-gap","posts/continual-learning-for-ai-agents"]},{"title":"LLM API의 숨은 비용 — 백만 토큰당 가격 비교를 멈춰라","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/hidden-llm-api-costs/","section":"posts","date":"2026-04-18T12:05:59+09:00","lastmod":"2026-04-18T12:05:59+09:00","description":"TensorZero의 Gabriel Bianconi가 실증한 LLM 가격의 함정 — 동일 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성한다. 도구 정의 워크로드에서 claude-opus-4-7은 gpt-5.4 대비 리스트 가격은 2배지만 실효 비용은 5.3배다.","summary":"\u0026ldquo;백만 토큰당 $X\u0026rdquo; 는 LLM 가격을 비교하는 가장 흔한 기준이지만, TensorZero의 Gabriel Bianconi는 이 기준이 근본적으로 망가졌다고 주장합니다. 동일한 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성하기 때문입니다. 리스트 가격이 비슷해 보여도 실효 비용은 크게 벌어지며, 특히 도구(tool) 정의가 많은 에이전트 워크로드에서 순위가 뒤집힙니다.\n원문: Stop comparing price per million tokens: the hidden LLM API costs — Gabriel Bianconi, TensorZero (2026-04-16) · 오픈소스: tensorzero/tensorzero\n핵심 주장 같은 입력이 모델에 따라 2.65배 이상 더 많은 토큰을 생성한다.\n","content":"\u0026ldquo;백만 토큰당 $X\u0026rdquo; 는 LLM 가격을 비교하는 가장 흔한 기준이지만, TensorZero의 Gabriel Bianconi는 이 기준이 근본적으로 망가졌다고 주장합니다. 동일한 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성하기 때문입니다. 리스트 가격이 비슷해 보여도 실효 비용은 크게 벌어지며, 특히 도구(tool) 정의가 많은 에이전트 워크로드에서 순위가 뒤집힙니다.\n원문: Stop comparing price per million tokens: the hidden LLM API costs — Gabriel Bianconi, TensorZero (2026-04-16) · 오픈소스: tensorzero/tensorzero\n핵심 주장 같은 입력이 모델에 따라 2.65배 이상 더 많은 토큰을 생성한다.\n가격 리스트는 \u0026ldquo;입력 $2.50 / 출력 $10\u0026rdquo; 같은 백만 토큰당 달러 단위로 나열되지만, 같은 프롬프트를 서로 다른 토크나이저에 통과시키면 토큰 수가 모델마다 달라집니다. 즉 달러 단가가 비슷해도 같은 일을 시키는 실제 지출은 전혀 비슷하지 않다.\n토크나이저 효율 — 콘텐츠 유형별 배수 gpt-5.4를 1.00x 기준선으로, 동일 입력에 대한 토큰 수 비율:\n모델 Text YAML JSON Tools gpt-5.4 1.00x 1.00x 1.00x 1.00x gemini-3.1-pro-preview 1.06x 1.18x 1.11x 1.82x claude-sonnet-4-6 1.17x 1.25x 1.22x 2.06x claude-opus-4-7 1.57x 1.53x 1.70x 2.65x 핵심 관찰:\n콘텐츠 유형이 비용을 바꾼다 — 텍스트·JSON·YAML·도구 정의는 모두 다르게 토큰화됨 도구 정의에서 격차가 가장 크다 — 에이전트 워크로드의 핵심 Anthropic 모델일수록 토크나이저 비효율이 심각 리스트 가격 vs 실효 비용 YAML 처리를 기준으로:\n모델 리스트 가격 실효 비용 gemini-3.1-pro-preview $2.00 $2.36 claude-opus-4-7 $5.00 $7.65 도구 중심 워크로드 (입력 $2.50 기준):\n모델 실효 비용 배수 gpt-5.4 $2.50 1.00x claude-opus-4-7 $13.25 5.30x 리스트 가격은 2배 차이지만, 도구 중심 워크로드에서는 5.3배로 벌어진다.\nGemini도 순위가 바뀝니다 — 텍스트에서는 가장 저렴하지만, 도구 정의에서는 OpenAI보다 46% 비싸짐.\n숨은 비용 카테고리 5가지 토크나이저 비효율 — 동일 입력에 대해 벤더마다 토큰 수가 다름 (이 글의 주제) 프롬프트 캐싱 할인 — 캐시 히트/미스별 가격 구조가 벤더마다 다름 긴 컨텍스트 가격 계층 — 윈도우 크기에 따라 단가가 점프하는 구조 출력 토큰 — 같은 \u0026ldquo;완성된 답\u0026quot;을 만드는 데 필요한 출력 토큰 수도 모델마다 다름 Thinking(reasoning) 토큰 — 추론 모델이 내부적으로 태우는 토큰의 요금 처리 테스트 방법론 벤치마킹에 사용된 입력:\n고전 문학 — 일리아드 (순수 텍스트) API 스펙 — Cloudflare OpenAI Spec (구조화된 JSON/YAML) 합성 도구 정의 100개 — 에이전트 환경 시뮬레이션 이 조합은 실제 프로덕션 워크로드(자연어 + 구조화 데이터 + 도구)를 균형 있게 커버합니다.\n왜 이것이 중요한가 — 에이전트 시대의 함의 에이전트 시스템은 도구 정의 + 구조화된 컨텍스트 + 체인 오브 쏘트로 구성됩니다. 즉 토크나이저 비효율이 가장 크게 드러나는 조합입니다.\n대화형 챗봇: 주로 자연어 → 격차 작음 에이전트 하네스: 대량의 도구 정의 + JSON 스키마 → 격차 폭증 RAG 파이프라인: 구조화된 청크 → 중간 격차 리스트 가격만 보고 \u0026ldquo;Opus가 약간 비싸니 감수하자\u0026quot;고 결정하면, 도구가 많은 워크로드에서는 예산이 5배로 튄다.\n권고 — \u0026ldquo;측정하라\u0026rdquo; 저자의 결론은 단순합니다.\n\u0026ldquo;당신이 실제로 얼마를 내는지 알 수 있는 유일한 방법은 측정하는 것이다.\u0026rdquo;\n리스트 가격 비교 대신:\n자신의 실제 워크로드로 토큰 수를 측정 (텍스트 / JSON / 도구 비율 파악) 성능 × 실효 비용 조합으로 모델 평가 — 단가만 보지 말 것 프로덕션과 비슷한 조건에서 A/B 실행 게이트웨이 레이어로 프로바이더별 실시간 비용 추적 구축 원칙은 도구 종류와 무관하지만, TensorZero 스스로도 이 측정 문제를 풀기 위해 오픈소스 스택을 공개합니다.\nTensorZero — 측정·최적화를 내장한 오픈소스 LLMOps 스택 저자가 속한 tensorzero/tensorzero는 이 블로그의 권고를 실제 인프라로 내려놓은 오픈소스 플랫폼입니다. Apache-2.0, 100% self-host. GitHub 스타 11.2k, 포춘 10대 기업부터 프론티어 AI 스타트업까지 사용하며 전 세계 LLM API 지출의 약 1% 가 이 게이트웨이를 통과합니다.\n통합 구성 — 5개 축이 하나의 스택으로 구성 역할 Gateway 단일 엔드포인트로 모든 주요 프로바이더 라우팅. p99 \u0026lt;1ms 오버헤드, 10k+ QPS Observability 모든 인퍼런스·피드백을 사용자 소유 DB에 저장 (ClickHouse/Postgres) Evaluation 휴리스틱 + LLM judge 기반 유닛·통합 테스트 스타일 평가 Optimization SFT, RLHF, 자동 프롬프트 엔지니어링(GEPA), Dynamic In-Context Learning(DICL) Experimentation A/B 테스트, multi-armed bandit, 시퀀셜 테스팅 비용 맥락에서 왜 의미 있는가 이 글의 핵심 주장 — \u0026ldquo;측정하지 않으면 실제 비용을 모른다\u0026rdquo; — 을 인프라로 강제하는 설계입니다.\n프로바이더별 실효 비용 추적 — 토크나이저가 다른 18+ 프로바이더의 실제 토큰·비용이 한 뷰에 집계됨 태그·스코프별 rate limit — 팀·기능·고객 단위로 지출을 세분화 캐싱·배칭 내장 — 실효 비용을 측정과 동시에 줄임 프로덕션 메트릭으로 옵티마이저 피드 루프 — 관측된 비용·품질이 fine-tuning과 라우팅 결정에 다시 입력됨 지원 프로바이더 (18+) Anthropic, OpenAI, Google (AI Studio \u0026amp; Vertex), AWS Bedrock/SageMaker, Azure, DeepSeek, Fireworks, Groq, Hyperbolic, Mistral, OpenRouter, SGLang, TGI, Together AI, vLLM, xAI(Grok), OpenAI-compatible (Ollama 등).\n기술 스택 Rust 79% — 게이트웨이 핫패스. 1ms 미만 p99의 핵심 TypeScript 15% — UI·CLI 툴링 Python 4% — 최적화·평가 워크플로 Quick Start (5분) # 1. Docker로 게이트웨이 단일 컨테이너 배포 docker run -p 3000:3000 tensorzero/gateway # 2. 기존 OpenAI 호환 클라이언트의 base_url만 교체 client = OpenAI(base_url=\u0026#34;http://localhost:3000\u0026#34;) # 3. 모델 식별자로 프로바이더 지정 model=\u0026#34;tensorzero::model_name::anthropic::claude-sonnet-4-6\u0026#34; 기존 OpenAI SDK 코드를 한 줄 바꾸는 것으로 전 프로바이더를 통합하고, 관측·평가·최적화가 자동으로 켜지는 구조입니다.\n포지셔닝 산업용 스택 — Fortune 10 배포 사례(대형 은행 code changelog 자동화 등) GitOps 호환 / self-host — 벤더 락인 없음, 플랫폼 수수료 없음 펀딩: $7.3M 시드 (ClickHouse·CockroachDB·OpenAI·Anthropic 백커) OpenTelemetry 네이티브 — 엔터프라이즈 관측 툴과 그대로 연결 유료 별도 제품 TensorZero Autopilot — 자동화된 최적화 서비스. 오픈소스 코어와 분리된 상업 옵션.\n실행 체크리스트 대표 프롬프트 10개를 선정해 각 모델 토크나이저로 토큰 수 측정 도구 정의가 차지하는 토큰 비중 파악 (보통 과소 추정됨) 리스트 가격 × 자신의 토크나이저 비율 = 실효 단가 산출 캐시 히트율과 할인 구조를 실효 단가에 반영 Thinking 토큰이 포함된 모델은 평균 추론 토큰 수도 반영 핵심 결론 백만 토큰당 가격은 사과 대 사과 비교가 아니다 동일 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성 도구 중심 워크로드에서는 리스트 가격 2배 → 실효 비용 5.3배로 벌어짐 콘텐츠 유형(텍스트/JSON/YAML/도구)별로 순위가 달라짐 유일한 해법은 자신의 워크로드로 직접 측정하는 것 가격을 비교하지 말고, 비용을 측정하라.\n","wordCount":875,"tags":["LLM","API","비용","토크나이저","OpenAI","Anthropic","Google","TensorZero","LLMOps","오픈소스","Gateway"],"categories":["AI"],"frameworks":["Total Cost of Ownership","First Principles"],"mental_models":["Hidden Costs","Apples-to-Apples Comparison"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM API의 숨은 비용 — 백만 토큰당 가격 비교를 멈춰라의 핵심 문제의식은 \"TensorZero의 Gabriel Bianconi가 실증한 LLM 가격의 함정 — 동일 입력이 모델에 따라 최대 2.65배 더 많은 토큰을 생성한다. 도구 정의 워크로드에서 claude-opus-4-7은 gpt-5.4 대비 리스트 가격은 2배지만 실효 비용은 5.3배다.\"다","본문은 핵심 주장 → 토크나이저 효율 — 콘텐츠 유형별 배수 → 리스트 가격 vs 실효 비용 흐름으로 논지를 전개한다","LLM, API, 비용 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/agentic-engine-optimization","posts/anatomy-of-an-agent-harness","posts/components-of-a-coding-agent"]},{"title":"AI Knowledge Layer — 에이전트가 쓸모 있어지기 위한 지식 레이어","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-knowledge-layer/","section":"posts","date":"2026-04-17T11:23:58+09:00","lastmod":"2026-04-17T11:23:58+09:00","description":"Shann Holmberg가 제안하는 AI Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어(raw + compiled wiki) 구조로, RAG 대신 한 번 컴파일한 지식 그래프가 100편 이후부터 Q\u0026A에서 RAG를 능가한다.","summary":"Shann Holmberg는 에이전트가 쓸모 없는 근본 이유는 지식을 보관하지 않기 때문이라고 주장합니다. 모든 대화가 0에서 시작하고, 매번 비즈니스 맥락·목소리·목표를 재설명해야 하며, 결과는 늘 제네릭합니다. 해법은 에이전트와 사용자 사이에 앉는 Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어 시스템입니다. 20분 셋업, 매일 스스로 개선, 오픈소스.\n원문: AI Knowledge Layer (and why your agents are useless without it) — Shann Holmberg · 구현체: shannhk/llm-wikid\n핵심 문제 — 에이전트는 매번 0에서 시작한다 대부분의 팀이 겪는 패턴:\n","content":"Shann Holmberg는 에이전트가 쓸모 없는 근본 이유는 지식을 보관하지 않기 때문이라고 주장합니다. 모든 대화가 0에서 시작하고, 매번 비즈니스 맥락·목소리·목표를 재설명해야 하며, 결과는 늘 제네릭합니다. 해법은 에이전트와 사용자 사이에 앉는 Knowledge Layer — Karpathy의 LLM Wiki 패턴을 따르는 두 레이어 시스템입니다. 20분 셋업, 매일 스스로 개선, 오픈소스.\n원문: AI Knowledge Layer (and why your agents are useless without it) — Shann Holmberg · 구현체: shannhk/llm-wikid\n핵심 문제 — 에이전트는 매번 0에서 시작한다 대부분의 팀이 겪는 패턴:\n모델과 하네스(harness)에만 돈·관심이 쏠림 막상 에이전트는 당신이 누구인지, 무엇을 해왔는지, 어떤 톤·제약으로 일하는지 전혀 모름 Claude·ChatGPT·Cursor·Copilot이 아무리 강력해도 컨텍스트가 매번 휘발되면 결과는 제네릭 Karpathy는 최근 \u0026ldquo;토큰 예산 대부분을 코드가 아니라 지식 관리로 옮기고 있다\u0026rdquo; 고 말했습니다. 이 기사는 그 시프트를 누구나 재현할 수 있는 인프라로 내려 놓은 구현입니다.\n왜 RAG가 아닌가 — Compiled vs Retrieved RAG는 매 쿼리마다 문서를 청크로 나누고 벡터 검색으로 답을 재유도합니다. 지식이 누적되지 않고, 매번 stateless로 처음부터 합성합니다.\nKarpathy의 관찰:\n약 100편 / 400K 단어 규모가 되면, 한 번 컴파일된 위키가 Q\u0026amp;A에서 RAG를 능가한다.\n이유:\n교차 참조가 미리 계산되어 있어 쿼리 시점에 그래프 탐색이 필요 없음 답이 파일로 다시 떨어지면 다음 쿼리가 더 풍부한 기반 위에서 시작 벡터 유사도의 노이즈가 아니라 구조화된 링크로 연결 — 컨텍스트 윈도우 사용이 훨씬 효율적 지식이 복리로 성장한다 (compound), stateless가 아니다 두 레이어 아키텍처 레이어 역할 특성 raw/ — 원시 인박스 잘라 넣은 웹 페이지, PDF, 트윗, 영상, 아이디어, 북마크 처리 없음. 스테이징 영역. 지저분해도 됨 wiki/ — 컴파일된 위키 개념·엔티티·출처·시너시스로 정리된 교차 링크 노트 AI가 유지·갱신. [[wikilinks]]로 그래프 형성 에이전트가 raw/를 읽어 wiki/로 컴파일하는 것이 핵심 동작입니다. 한 번 들어간 원재료는 여러 번 위키 페이지를 업데이트합니다.\n7단계 인제스트 파이프라인 Sort clippings — URL 타입으로 자동 분류 (유튜브/논문/트윗/블로그 등) Resolve content — yt-dlp(영상), X API(트윗), scrapling(웹), 직접 PDF 리딩으로 전체 본문 확보 Media extraction — 이미지 다운로드, 영상 자막 추출 Classify \u0026amp; compile — 포맷별 추출 (트랜스크립트는 화자, 논문은 메서드·파인딩) Cross-linking — 관련 페이지 간 [[wikilinks]] 자동 생성 Bias checking — 반대 논거와 데이터 공백 섹션 추가 Re-indexing — qmd 설치 시 검색 갱신 4가지 핵심 커맨드 커맨드 기능 /wiki-ingest raw/의 원재료를 wiki/ 페이지로 컴파일 /wiki-query [질문] 리서치 질문 → 출처 달린 답변 반환 → 다시 outputs/에 파일링 /wiki-explore [주제] 웹 검색·커뮤니티 시그널로 능동적 리서치 /wiki-lint 모순·고아 페이지·깨진 링크 헬스 체크 핵심 디자인: 모든 /wiki-query 답변이 outputs/에 파일링되어 다음 쿼리의 재료가 됩니다. 질의가 지식을 소비하는 것이 아니라 기여합니다.\n폴더 구조 (인제스트 후) raw/ # 지저분한 인박스 clippings/ # URL 타입별 자동 정렬 ideas/ # 반쯤 형성된 생각 bookmarks/ # 클리핑된 컨텐츠 articles/ # 출판된 글 papers/ # 연구 PDF assets/images/ # 다운로드된 미디어 x-archive/ # 트위터 아카이브 wiki/ # AI가 유지하는 컴파일 결과 index.md # TLDR 포함 마스터 카탈로그 log.md # 추가 전용 체인지로그 concepts/ # 교차 아이디어 entities/ # 도구·사람·프로젝트 sources/ # 원재료 정리 syntheses/ # 교차 분석 outputs/ # 파일링된 쿼리 답변 sops/ # 문서화된 프로세스 품질 컨트롤 — \u0026ldquo;AI가 잘못 이해하면?\u0026rdquo; Karpathy 패턴의 약점을 시스템적으로 메우는 장치들:\nexplored: true/false 플래그 — 페이지는 기본값 false. 사람의 리뷰만 true로 바꿀 수 있음 → 검증 상태가 투명 Confidence 태깅 — high/medium/low/uncertain. 다수 출처 = high, 단일 언급 = low Source tracing — 모든 주장은 특정 출처 페이지로 링크됨. 근거 없는 단언 금지 Bias 섹션 — 모든 개념·출처 페이지에 반대 논거·데이터 공백 섹션 — 에코 챔버 방지 Git 통합 — raw/·wiki/를 바꾸는 모든 작업이 자동 커밋·푸시 → 완전한 되돌림 가능, 멀티 에이전트 협업 안전 셋업 (20분) git clone https://github.com/shannhk/llm-wikid.git my-wiki cd my-wiki # my-wiki 폴더를 Obsidian vault로 오픈 claude --dangerously-skip-permissions 에이전트는 CLAUDE.md(시스템 스키마)를 읽고 모든 워크플로를 그곳에서 실행합니다. Obsidian은 뷰어, LLM은 메인테이너 역할.\n선택 도구:\nyt-dlp — 유튜브 트랜스크립트 scrapling — 웹 스크레이핑 X API — 트윗·스레드 가져오기 qmd — 전문 검색 인덱싱 (BM25 + 벡터 + LLM 리랭킹) 스케일링 전략 위키 규모 접근 0–300 페이지 파일 기반 + 인덱스 TLDR 스캔 300–500 페이지 qmd 기본 검색 500+ 페이지 PostgreSQL / Supabase 검토 왜 지금 중요한가 모델이 아무리 똑똑해져도 당신에 대한 영구적 이해가 없으면 에이전트는 제네릭 툴에 머뭅니다. 하네스가 LLM을 \u0026ldquo;폰 노이만 아키텍처\u0026quot;로 감싸 CPU를 완성했다면, Knowledge Layer는 그 위에 영구 스토리지 + 개인화된 운영체제를 올리는 작업입니다.\n핵심 비대칭:\nRAG = 매번 답을 다시 합성 → 지식이 누적되지 않음 Knowledge Layer = 한 번 컴파일 → 매 쿼리가 기반을 두껍게 만듦 컴파일된 지식은 복리로 쌓인다. 에이전트는 매일 똑똑해진다.\nrobots.txt·llms.txt가 바깥 세계를 에이전트 친화적으로 바꾸는 작업이라면, Knowledge Layer는 당신의 내부 맥락을 에이전트 친화적으로 바꾸는 작업입니다. 양쪽이 합쳐질 때 에이전트는 비로소 당신의 에이전트가 됩니다.\n실행 우선순위 shannhk/llm-wikid 클론 → 20분 셋업 raw/에 지난 30일치 클리핑 50개 투입 /wiki-ingest 실행하여 컴파일된 구조 확인 /wiki-query로 첫 답을 받고 outputs/에 파일링되는 흐름 체감 /wiki-lint 주 1회로 헬스 체크 100편 돌파 후 RAG와의 체감 차이 비교 핵심 결론 에이전트가 유용해지려면 모델 바깥의 지속 가능한 지식 레이어가 필요하다 RAG는 쿼리 시점 합성, LLM Wiki는 사전 컴파일된 그래프 — 100편 스케일에서 후자가 유리 두 레이어(raw/ + wiki/) + 7단계 파이프라인 + 4개 커맨드로 구현 가능 품질은 explored 플래그, confidence 태깅, bias 섹션, Git 커밋으로 확보 당신이 매일 쌓는 지식이, 내일 당신의 에이전트가 된다 참고: Karpathy의 LLM Wiki gist · MindStudio 해설\n","wordCount":816,"tags":["AI","에이전트","지식베이스","LLM","Karpathy","RAG","Obsidian","Claude Code"],"categories":["AI"],"frameworks":["LLM Wiki Pattern","Two-Layer Knowledge System"],"mental_models":["Compilation vs Retrieval","Compound Knowledge"],"philosophy_type":"systems-thinking","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트가 매번 0에서 시작하는 문제를 해결하는 Knowledge Layer = raw(원시 수집) + wiki(컴파일된 지식 그래프)","7단계 인제스트 파이프라인: URL 분류 → 콘텐츠 추출 → 요약 → wiki 페이지 생성 → 교차 링크 → 검증 → 에이전트 컨텍스트 주입","약 100편/400K 단어 규모에서 컴파일된 위키가 RAG 대비 Q\u0026A 품질을 능가","Karpathy의 LLM Wiki 패턴을 누구나 재현할 수 있도록 오픈소스 구현체(llm-wikid)로 제공"],"related":["posts/agentic-engine-optimization","posts/anatomy-of-an-agent-harness","posts/continual-learning-for-ai-agents"]},{"title":"Agentic Engine Optimization: AI 에이전트가 읽을 수 있는 문서를 만드는 새로운 규율","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-engine-optimization/","section":"posts","date":"2026-04-16T10:00:00+09:00","lastmod":"2026-04-16T10:00:00+09:00","description":"AI 코딩 에이전트가 개발자 문서를 소비하는 방식은 인간과 근본적으로 다르다. Addy Osmani가 제시하는 Agentic Engine Optimization(AEO)의 6계층 스택과 실무 체크리스트를 정리한다.","summary":"개발자 문서를 인간 독자만을 대상으로 최적화하는 시대가 끝나가고 있습니다. AI 코딩 에이전트는 문서를 전혀 다른 방식으로 소비하며, 기존 포털은 점점 에이전트에게 보이지 않는 존재가 되고 있습니다. Addy Osmani는 이를 해결하기 위한 새로운 규율로 Agentic Engine Optimization(AEO) 을 제안합니다. 과거 SEO가 검색 크롤러를 위해 콘텐츠를 구조화했던 것처럼, AEO는 에이전트가 실제로 사용할 수 있도록 기술 콘텐츠를 구조화·포맷팅·제공하는 실천입니다.\n왜 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 토큰으로, 대부분 에이전트의 사용 가능 컨텍스트를 초과합니다. 이런 경우 에이전트는 조용히 잘라내거나, 건너뛰거나, 솔루션을 환각합니다.\n","content":"개발자 문서를 인간 독자만을 대상으로 최적화하는 시대가 끝나가고 있습니다. AI 코딩 에이전트는 문서를 전혀 다른 방식으로 소비하며, 기존 포털은 점점 에이전트에게 보이지 않는 존재가 되고 있습니다. Addy Osmani는 이를 해결하기 위한 새로운 규율로 Agentic Engine Optimization(AEO) 을 제안합니다. 과거 SEO가 검색 크롤러를 위해 콘텐츠를 구조화했던 것처럼, AEO는 에이전트가 실제로 사용할 수 있도록 기술 콘텐츠를 구조화·포맷팅·제공하는 실천입니다.\n왜 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 토큰으로, 대부분 에이전트의 사용 가능 컨텍스트를 초과합니다. 이런 경우 에이전트는 조용히 잘라내거나, 건너뛰거나, 솔루션을 환각합니다.\n실무 토큰 타깃\n퀵스타트 페이지: \u0026lt;15,000 토큰 개별 API 레퍼런스: \u0026lt;25,000 토큰 개념 가이드: \u0026lt;20,000 토큰 AEO 스택 — 6계층 구조 Access Control (robots.txt): 잘못된 설정으로 에이전트가 조용히 차단되는 경우가 많음. 의도치 않은 차단 감사 필요. Discovery (llms.txt): \u0026ldquo;에이전트를 위한 sitemap\u0026rdquo;. 루트에 두는 Markdown 파일로, 문서 디렉토리 구조와 페이지별 설명·토큰 수를 제공. 파일 자체는 5,000 토큰 미만으로 유지. Capability Signaling (skill.md): 제품이 무엇을 할 수 있는지 를 선언적으로 기술. 능력, 필수 입력, 제약을 명시해 에이전트가 전체 문서를 읽을지 판단할 수 있게 함. Content Formatting: 원시 Markdown 제공, 일관된 헤딩 계층, 배경이 아닌 결과부터 기술, 코드 예시를 주장 바로 다음 배치, 첫 500 토큰에 핵심 정보 전진 배치. Token Surfacing: 토큰 수를 메타데이터 또는 HTTP 헤더로 노출해 에이전트가 컨텍스트를 판단할 수 있도록 함. \u0026ldquo;Copy for AI\u0026rdquo; 버튼: 렌더링된 HTML이 아닌 깔끔한 Markdown을 클립보드로 복사하게 해 컨텍스트 품질을 높임. AGENTS.md — 저장소의 새로운 진입점 README.md가 인간 개발자를 위한 진입점이듯, AGENTS.md는 AI 에이전트를 위한 기본 진입점으로 부상 중입니다. 포함해야 할 항목:\n프로젝트 구조와 핵심 파일 위치 API 문서 직접 링크 개발 샌드박스와 테스트 환경 레이트 리밋과 제약 코드 컨벤션 MCP 서버 링크 Cisco DevNet은 이미 GitHub 템플릿에 AGENTS.md를 기본 제공합니다.\nAI 레퍼럴 트래픽 모니터링 추적해야 할 주요 레퍼러:\nlabs.perplexity.ai/referral chatgpt.com claude.ai/referral copilot.microsoft.com/referral 레퍼러가 없는 직접 에이전트 트래픽은 HTTP 핑거프린트로 식별합니다.\nDevEx 관점의 함의 에이전트 비중이 큰 환경에서는 전통적 문서화 가정이 무너집니다.\n시각적 계층은 무관해짐 점진적 공개는 장애물로 작용 인터랙티브 예제는 가치 상실 사용자 여정 개념 자체가 붕괴 최고의 문서는 양쪽 모두를 만족시킵니다 — 인간에게는 스캔 가능하고, 에이전트에게는 기계 판독 가능하며 토큰 효율적.\n실행 우선순위 robots.txt 감사 (10분) llms.txt 추가 (수 시간) 토큰 수 노출 (주말 프로젝트) 주요 API 3개에 skill.md 작성 (중기) \u0026ldquo;Copy for AI\u0026rdquo; 버튼 추가 (저비용) AI 트래픽 모니터링 셋업 (ROI 기준점) 핵심 결론 \u0026ldquo;먼저 움직이는 팀이 실질적 우위를 갖는다. 그들의 API는 에이전트가 추천하고, 성공적으로 통합하고, 다시 찾는 API가 될 것이다.\u0026rdquo;\n에이전트 최적화 작업은 인간용 문서 품질도 동시에 향상시킵니다. llms.txt, skill.md, robots.txt 감사부터 시작하는 것이 현실적이고 고효율적인 시작점입니다.\n원문: Agentic Engine Optimization (AEO) — Addy Osmani\n","wordCount":470,"tags":["AI","AEO","SEO","문서화","에이전트","DevEx","API","llms.txt"],"categories":["AI"],"frameworks":["AEO Stack","First Principles"],"mental_models":["Audience Segmentation","Token Economics"],"philosophy_type":"systems-thinking","schema_type":"Article","actionable":true,"priority":"high","key_points":["에이전트는 인간과 달리 문서를 1~2회 HTTP 요청으로 소비하며 분석 이벤트를 남기지 않는다","AEO 6계층 스택: Access Control → Discovery(llms.txt) → Capability Signaling → Content Formatting → Token Surfacing → Copy for AI","문서 크기는 1급 지표 — 퀵스타트 15K, API 레퍼런스 25K, 개념 가이드 20K 토큰 이하 목표","AGENTS.md가 README.md와 함께 저장소의 새로운 이중 진입점으로 부상"],"related":["posts/agentic-code-review-addy-osmani","posts/agentic-engineering-management","posts/agentic-software-engineering"]},{"title":"에이전트 하네스의 해부학 — Anthropic, OpenAI, LangChain이 실제로 구축하는 것","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/anatomy-of-an-agent-harness/","section":"posts","date":"2026-04-11T18:09:55+09:00","lastmod":"2026-04-11T18:09:55+09:00","description":"Anthropic, OpenAI, LangChain 등이 구축하는 에이전트 하네스의 12가지 구성요소와 7가지 핵심 설계 결정을 분석한다. 동일 모델이라도 하네스 설계에 따라 성능이 20+ 랭킹 차이를 보인다.","summary":"Akshay Pachaar가 Anthropic, OpenAI, Perplexity, LangChain이 실제로 구축하고 있는 에이전트 하네스를 심층 분석합니다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리 등 stateless LLM을 capable agent로 변환하는 모든 것을 다룹니다.\n원문: The Anatomy of an Agent Harness\n핵심 주장 챗봇을 만들어 ReAct 루프에 도구 몇 개를 연결하면 데모에서는 작동한다. 프로덕션을 시도하면 무너진다 — 모델이 3단계 전에 한 일을 잊고, 도구 호출이 조용히 실패하고, 컨텍스트 윈도우가 쓰레기로 채워진다.\n문제는 모델이 아니다. 모델을 둘러싼 모든 것이다.\n","content":"Akshay Pachaar가 Anthropic, OpenAI, Perplexity, LangChain이 실제로 구축하고 있는 에이전트 하네스를 심층 분석합니다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리 등 stateless LLM을 capable agent로 변환하는 모든 것을 다룹니다.\n원문: The Anatomy of an Agent Harness\n핵심 주장 챗봇을 만들어 ReAct 루프에 도구 몇 개를 연결하면 데모에서는 작동한다. 프로덕션을 시도하면 무너진다 — 모델이 3단계 전에 한 일을 잊고, 도구 호출이 조용히 실패하고, 컨텍스트 윈도우가 쓰레기로 채워진다.\n문제는 모델이 아니다. 모델을 둘러싼 모든 것이다.\nLangChain이 동일 모델(같은 가중치)로 인프라만 변경하여 TerminalBench 2.0에서 30위권 밖에서 5위로 점프한 사례가 증명한다. 별도 연구 프로젝트에서는 LLM이 인프라 자체를 최적화하게 하여 76.4% 통과율로 수작업 시스템을 넘어섰다.\nVivek Trivedy(LangChain)의 정준 공식: \u0026ldquo;모델이 아니면, 하네스다(If you\u0026rsquo;re not the model, you\u0026rsquo;re the harness)\u0026rdquo;\n에이전트 하네스란 무엇인가 2026년 초 공식화된 용어. LLM을 감싸는 완전한 소프트웨어 인프라: 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리, 상태 지속성, 오류 처리, 가드레일.\nBeren Millidge의 비유(2023, \u0026ldquo;Scaffolded LLMs as Natural Language Computers\u0026rdquo;): 원시 LLM은 RAM·디스크·I/O 없는 CPU다. 컨텍스트 윈도우 = RAM(빠르지만 제한적), 외부 DB = 디스크(크지만 느림), 도구 통합 = 디바이스 드라이버, 하네스 = 운영체제. \u0026ldquo;우리는 폰 노이만 아키텍처를 재발명했다\u0026rdquo;\n3가지 엔지니어링 수준 수준 범위 프롬프트 엔지니어링 모델이 받는 지시사항 제작 컨텍스트 엔지니어링 모델이 무엇을 언제 보는지 관리 하네스 엔지니어링 위 둘 + 전체 애플리케이션 인프라 (도구 오케스트레이션, 상태 지속성, 오류 복구, 검증 루프, 안전 시행, 라이프사이클 관리) 프로덕션 하네스의 12가지 구성요소 1. 오케스트레이션 루프 심장박동. Thought-Action-Observation(TAO) 사이클(ReAct 루프) 구현. 프롬프트 조립 → LLM 호출 → 출력 파싱 → 도구 실행 → 결과 피드백 → 반복. Anthropic은 런타임을 \u0026ldquo;dumb loop\u0026quot;로 설명 — 모든 지능은 모델에 있고, 하네스는 턴만 관리.\n2. 도구 에이전트의 손. 스키마(이름, 설명, 매개변수 타입)로 정의되어 LLM 컨텍스트에 주입. 도구 계층이 등록, 스키마 검증, 인수 추출, 샌드박스 실행, 결과 캡처, 포맷팅을 처리. Claude Code는 6개 카테고리(파일 작업, 검색, 실행, 웹 접근, 코드 인텔리전스, 서브에이전트 생성) 제공.\n3. 메모리 다중 시간 척도로 작동:\n단기 메모리 : 단일 세션 내 대화 기록 장기 메모리 : 세션 간 지속. Anthropic은 CLAUDE.md + 자동 생성 MEMORY.md, LangGraph는 네임스페이스 JSON Stores, OpenAI는 SQLite/Redis 세션 지원 Claude Code의 3계층 구조: 경량 인덱스(항목당 ~150자, 항상 로드) → 상세 토픽 파일(온디맨드) → 원시 트랜스크립트(검색으로만 접근). 핵심 원칙: 에이전트는 자신의 메모리를 \u0026ldquo;힌트\u0026quot;로 취급하고 행동 전 실제 상태와 대조 검증 한다.\n4. 컨텍스트 관리 많은 에이전트가 조용히 실패하는 지점. 핵심 문제는 컨텍스트 부패(context rot) : 중요 콘텐츠가 윈도우 중간에 위치하면 모델 성능이 30%+ 저하(Stanford \u0026ldquo;Lost in the Middle\u0026rdquo; 발견).\n프로덕션 전략:\n압축(Compaction) : 한계 접근 시 대화 기록 정리 (아키텍처 결정과 미해결 버그는 보존, 중복 도구 출력은 폐기) 관찰 마스킹 : JetBrains Junie가 오래된 도구 출력을 숨기되 도구 호출은 가시적으로 유지 적시 검색(JIT) : 경량 식별자 유지 후 동적 로드 (grep, glob, head, tail 사용) 서브에이전트 위임 : 각 서브에이전트가 광범위 탐색 후 1,000~2,000 토큰 만 반환 Anthropic의 목표: \u0026ldquo;원하는 결과의 가능성을 최대화하는 최소한의 고신호 토큰 집합 찾기\u0026rdquo;\n5. 프롬프트 구성 모델이 각 단계에서 실제로 보는 것을 조립. 계층적: 시스템 프롬프트 → 도구 정의 → 메모리 파일 → 대화 기록 → 현재 사용자 메시지. OpenAI Codex는 엄격한 우선순위 스택 사용(서버 제어 시스템 메시지가 최고 우선순위).\n6. 출력 파싱 현대 하네스는 네이티브 도구 호출에 의존 — 모델이 자유 텍스트 대신 구조화된 tool_calls 객체 반환. 도구 호출 있으면 실행 후 루프, 없으면 최종 답변.\n7. 상태 관리 LangGraph : 타입 딕셔너리가 그래프 노드를 흐르며 리듀서가 업데이트 병합. 슈퍼스텝 경계에서 체크포인팅 → 중단 후 재개, 타임트래블 디버깅 가능 Claude Code : git 커밋을 체크포인트로, progress 파일을 구조화된 스크래치패드로 사용 8. 오류 처리 10단계 프로세스에서 단계당 99% 성공률이면 전체 성공률은 ~90.4% . 오류는 빠르게 복합된다.\nLangGraph의 4가지 오류 유형: 일시적(백오프 재시도), LLM 복구 가능(오류를 ToolMessage로 반환), 사용자 수정 가능(인간 입력 인터럽트), 예상 외(디버깅용 버블업). Stripe는 프로덕션에서 재시도를 2회로 제한.\n9. 가드레일과 안전 OpenAI SDK의 3단계: 입력 가드레일(첫 에이전트에서 실행), 출력 가드레일(최종 출력에서 실행), 도구 가드레일(모든 도구 호출에서 실행). \u0026ldquo;트립와이어\u0026rdquo; 메커니즘이 트리거 시 에이전트 즉시 중단.\nAnthropic은 권한 시행을 모델 추론에서 아키텍처적으로 분리 . 모델은 시도할 것을 결정하고, 도구 시스템은 허용 여부를 결정. Claude Code는 ~40개 개별 도구 기능을 독립적으로 게이팅.\n10. 검증 루프 장난감 데모와 프로덕션 에이전트를 구분하는 것. Anthropic의 3가지 접근: 규칙 기반 피드백(테스트, 린터, 타입 체커), 시각적 피드백(Playwright 스크린샷), LLM-as-judge(별도 서브에이전트가 출력 평가).\nClaude Code 창시자 Boris Cherny의 발견: 모델에게 작업을 검증할 방법을 주면 품질이 2~3배 향상 된다.\n11. 서브에이전트 오케스트레이션 Claude Code의 3가지 실행 모델:\nFork : 부모 컨텍스트의 바이트 동일 복사본 Teammate : 별도 터미널 페인, 파일 기반 메일박스 통신 Worktree : 자체 git worktree, 에이전트별 격리 브랜치 OpenAI SDK: agents-as-tools(제한된 하위 작업) + handoffs(전체 제어 이전). LangGraph: 중첩 상태 그래프로 구현.\n12. (루프의 실제 작동) Step 1: 프롬프트 조립 → Step 2: LLM 추론 → Step 3: 출력 분류 → Step 4: 도구 실행(읽기 전용은 병렬, 변경은 직렬) → Step 5: 결과 패키징 → Step 6: 컨텍스트 업데이트(한계 시 압축 트리거) → Step 7: 루프\n종료 조건: 도구 호출 없는 응답, 최대 턴 제한 초과, 토큰 예산 소진, 가드레일 트립와이어, 사용자 인터럽트, 안전 거부.\n장기 실행 작업: Ralph Loop 패턴 여러 컨텍스트 윈도우에 걸치는 작업을 위해 Anthropic이 개발한 2단계 패턴:\nInitializer Agent : 환경 설정 (init 스크립트, progress 파일, 기능 목록, 초기 git 커밋) Coding Agent : 이후 매 세션에서 git 로그와 progress 파일을 읽어 자기 위치 파악 → 최우선 미완료 기능 선택 → 작업 → 커밋 → 정리 작성 파일시스템이 컨텍스트 윈도우 간 연속성을 제공 한다.\n하네스를 정의하는 7가지 설계 결정 1. 단일 에이전트 vs 다중 에이전트 Anthropic과 OpenAI 모두: 단일 에이전트를 먼저 최대화 . 다중 에이전트는 추가 LLM 호출(라우팅)과 핸드오프 시 컨텍스트 손실의 오버헤드. 도구 과부하가 ~10개 겹치는 도구를 초과하거나 명확히 분리된 작업 도메인이 있을 때만 분할.\n2. ReAct vs Plan-and-Execute ReAct: 매 단계에서 추론과 행동을 교차(유연하지만 단계당 비용 높음). Plan-and-Execute: 계획과 실행 분리. LLMCompiler는 순차 ReAct 대비 3.6배 속도 향상 보고.\n3. 컨텍스트 윈도우 관리 전략 5가지 프로덕션 접근: 시간 기반 클리어링, 대화 , 관찰 마스킹, 구조화된 노트 작성, 서브에이전트 위임. ACON 연구: 추론 트레이스 우선으로 95%+ 정확도 유지하며 26~54% 토큰 감소 .\n4. 검증 루프 설계 계산적 검증(테스트, 린터) = 결정론적 진실. 추론적 검증(LLM-as-judge) = 의미적 이슈 포착하지만 지연 추가. Martin Fowler의 Thoughtworks 팀: guides(피드포워드, 행동 전 조향) vs sensors(피드백, 행동 후 관찰).\n5. 권한 및 안전 아키텍처 관대(빠르지만 위험) vs 제한적(안전하지만 느림). 배포 맥락에 따라 결정.\n6. 도구 범위 전략 도구가 많으면 성능이 나빠지는 경우가 많다. Vercel은 v0에서 80% 도구를 제거하고 더 나은 결과 를 얻었다. Claude Code는 지연 로딩으로 95% 컨텍스트 감소. 원칙: 현재 단계에 필요한 최소 도구 세트만 노출.\n7. 하네스 두께 하네스에 얼마나 많은 로직을 넣을 것인가 vs 모델에 맡길 것인가. Anthropic은 얇은 하네스 + 모델 개선에 베팅. 그래프 기반 프레임워크는 명시적 제어에 베팅. Anthropic은 새 모델 버전이 해당 능력을 내재화하면 정기적으로 Claude Code 하네스에서 계획 단계를 삭제 한다.\n스캐폴딩 메타포 건축 비계(scaffolding)는 작업자가 닿지 못하는 구조물을 지을 수 있게 하는 임시 인프라다. 건설을 하지는 않지만, 없으면 상층에 도달할 수 없다. 핵심: 건물이 완성되면 비계는 제거된다.\n모델이 개선되면 하네스 복잡성은 감소해야 한다. Manus는 6개월 동안 5번 재구축하며 매번 복잡성을 제거했다. 복잡한 도구 정의 → 일반 셸 실행, \u0026ldquo;관리 에이전트\u0026rdquo; → 단순 구조화된 핸드오프.\n미래 대비 테스트 : 더 강력한 모델에서 하네스 복잡성 추가 없이 성능이 확장되면, 설계가 건전한 것이다.\n결론 동일 모델을 사용하는 두 제품이 하네스 설계만으로 완전히 다른 성능을 보일 수 있다. TerminalBench 증거: 하네스만 변경하여 에이전트가 20+ 랭킹 이동 .\n하네스는 해결된 문제도, 상품화된 계층도 아니다. 어려운 엔지니어링이 사는 곳이다: 컨텍스트를 희소 자원으로 관리하고, 실패가 복합되기 전에 잡는 검증 루프를 설계하고, 환각 없이 연속성을 제공하는 메모리 시스템을 구축하고, 얼마나 많은 비계를 세울 것인지 vs 모델에 맡길 것인지에 대한 아키텍처적 베팅을 하는 것.\n\u0026ldquo;다음에 에이전트가 실패하면, 모델을 탓하지 마라. 하네스를 봐라.\u0026rdquo;\n","wordCount":1216,"tags":["AI","에이전트","하네스","아키텍처","LLM","프로덕션"],"categories":["AI"],"frameworks":["Systems Thinking","First Principles"],"mental_models":["Layered Architecture","Von Neumann Architecture"],"philosophy_type":"epistemology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트 하네스는 LLM을 감싸는 완전한 소프트웨어 인프라 — 12가지 구성요소로 분해 가능","LangChain이 동일 모델로 인프라만 변경해 TerminalBench 2.0 30위권 → 5위로 개선","3단계 엔지니어링 수준: 프롬프트 → 컨텍스트 → 하네스 엔지니어링","폰 노이만 비유: 컨텍스트 윈도우=RAM, 외부 DB=디스크, 도구=디바이스 드라이버, 하네스=운영체제"],"related":["posts/components-of-a-coding-agent","posts/agentic-software-engineering","posts/continual-learning-for-ai-agents"]},{"title":"에이전틱 소프트웨어 엔지니어링 — 에이전트 구축은 쉽지만 프로덕션 운영은 분산 시스템 문제다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/agentic-software-engineering/","section":"posts","date":"2026-04-11T18:07:04+09:00","lastmod":"2026-04-11T18:07:04+09:00","description":"Ashpreet Bedi가 제시하는 에이전틱 소프트웨어 엔지니어링의 6가지 기둥(내구성·격리·거버넌스·지속성·규모·조합가능성)과 Build-Serve-Connect 3단계 프레임워크. 에이전트를 프로덕션 분산 시스템으로 다루는 체계적 접근법.","summary":"Ashpreet Bedi(Agno 창업자)가 에이전트 구축과 프로덕션 운영 사이의 격차를 지적하며, 에이전틱 소프트웨어를 분산 시스템으로 다뤄야 한다는 체계적 프레임워크를 제시합니다.\n원문: Systems Engineering: Building Agentic Software That Works / Agentic Software Engineering\n핵심 주장 \u0026ldquo;에이전트 구축은 쉽지만, 프로덕션 환경에서 안정적으로 운영하는 것은 어렵다\u0026rdquo;\n사용자 식별, 상태 유지, 동시 요청 처리, 환불 같은 민감한 작업, 실패한 도구 호출 처리가 필요한 순간, 그것은 더 이상 \u0026ldquo;LLM + 도구의 루프\u0026quot;가 아닌 분산 시스템 이 된다.\n에이전틱 소프트웨어 배포의 3단계 단계 설명 핵심 Build(구축) 모델, 도구, 지식베이스, 메모리, 저장소, 보호 장치 정의 AI 엔지니어링 중심. 대부분의 프레임워크가 지원하는 영역 Serve(서빙) API로서 제공. 사용자별 범위 지정, 세션 관리, 수평 확장 대부분의 에이전트 제품이 여기서 정체됨 — 인프라 부족 Connect(연결) 사용자가 있는 곳과 통합 (Slack, Discord, MCP 등) \u0026ldquo;노트북의 에이전트는 실험, 사용자가 있는 곳의 에이전트가 제품\u0026rdquo; 에이전틱 소프트웨어의 6가지 기둥 1. Durability(내구성) 에이전트가 15단계 중 12단계에서 충돌하면, 재시작 시 부작용이 중복되거나 중요 컨텍스트가 손실된다. 일시 중지, 재개, 체크포인트, 우아한 복구가 필요하며, 내구성은 완전 재시작이 아닌 재개로 실패를 전환 한다.\n","content":"Ashpreet Bedi(Agno 창업자)가 에이전트 구축과 프로덕션 운영 사이의 격차를 지적하며, 에이전틱 소프트웨어를 분산 시스템으로 다뤄야 한다는 체계적 프레임워크를 제시합니다.\n원문: Systems Engineering: Building Agentic Software That Works / Agentic Software Engineering\n핵심 주장 \u0026ldquo;에이전트 구축은 쉽지만, 프로덕션 환경에서 안정적으로 운영하는 것은 어렵다\u0026rdquo;\n사용자 식별, 상태 유지, 동시 요청 처리, 환불 같은 민감한 작업, 실패한 도구 호출 처리가 필요한 순간, 그것은 더 이상 \u0026ldquo;LLM + 도구의 루프\u0026quot;가 아닌 분산 시스템 이 된다.\n에이전틱 소프트웨어 배포의 3단계 단계 설명 핵심 Build(구축) 모델, 도구, 지식베이스, 메모리, 저장소, 보호 장치 정의 AI 엔지니어링 중심. 대부분의 프레임워크가 지원하는 영역 Serve(서빙) API로서 제공. 사용자별 범위 지정, 세션 관리, 수평 확장 대부분의 에이전트 제품이 여기서 정체됨 — 인프라 부족 Connect(연결) 사용자가 있는 곳과 통합 (Slack, Discord, MCP 등) \u0026ldquo;노트북의 에이전트는 실험, 사용자가 있는 곳의 에이전트가 제품\u0026rdquo; 에이전틱 소프트웨어의 6가지 기둥 1. Durability(내구성) 에이전트가 15단계 중 12단계에서 충돌하면, 재시작 시 부작용이 중복되거나 중요 컨텍스트가 손실된다. 일시 중지, 재개, 체크포인트, 우아한 복구가 필요하며, 내구성은 완전 재시작이 아닌 재개로 실패를 전환 한다.\n2. Isolation(격리) 수천 명의 사용자가 동시에 에이전틱 소프트웨어를 사용할 때, 에이전트가 접촉하는 모든 리소스를 격리하는 것이 핵심이다. 데이터베이스, 벡터 저장소, 모델 제공자가 모두 사용자 경계를 존중해야 한다. \u0026ldquo;하나의 누락된 필터가 데이터 유출이 될 수 있다\u0026rdquo;\n3. Governance(거버넌스) 행동할 수 있는 에이전트는 피해도 입힐 수 있다. 계층화된 권한 구조가 필요하다:\n자동 실행 도구 사용자 승인 필요 도구 관리자 승인 필요 도구 \u0026ldquo;대부분의 에이전트는 최소한의 감독으로 자동 실행된다. 더 강해질수록 거버넌스가 제품 자체가 된다\u0026rdquo;\n4. Persistence(지속성) \u0026ldquo;지속 저장소 없는 에이전트는 학습하거나, 컨텍스트를 구축하거나, 개선될 수 없다.\u0026rdquo; 세션, 메모리, 지식을 데이터베이스에 저장해야 하며, 매 대화가 다음 대화를 더 좋게 만드는 것 이 챗봇을 제품으로 만든다.\n5. Scale(규모 확장) 기존 서비스는 자체 백엔드를 호출하지만, 에이전틱 소프트웨어는 외부 모델 API와 서드파티 도구를 호출한다. 제어 불가능한 종속성의 속도 제한, 지연, 다운타임을 상속 받는다는 특수성이 있다.\n6. Composability(조합가능성) 에이전트가 서비스가 되면 다른 에이전트가 이를 호출할 수 있다. 프론트엔드, Slack 봇, MCP 클라이언트가 모두 호출 가능하며, 단일 에이전트 도구가 다중 에이전트 시스템으로 변한다.\n3가지 전문 엔지니어링 분야 분야 범위 핵심 AI 엔지니어링 Build 단계 모델 선택, 도구·기능 정의, 지식베이스 구축, guardrails 설정 데이터 엔지니어링 Serve + Persistence 지속성 저장소(PostgreSQL), 세션/메모리 관리, 벡터 저장소, 데이터 격리 보안 엔지니어링 Governance + Isolation 사용자별 접근 제어, 도구 실행 권한 계층화, 승인 흐름, 감사 추적 구체적 예시: 고객 환불 처리 에이전트 도구 구성: - lookup_order (자동 실행) - search_help_docs (자동 실행) - issue_refund (사용자 확인 필요) - UserFeedbackTools (구조화된 질문) 워크플로우 :\n자동 조회 — 고객이 환불 요청 → 에이전트가 독립적으로 주문 조회 (권한 불필요) 구조화된 질문 — 환불 이유 파악 필요 → 사전 정의된 선택지 제시 → 고객이 선택 승인 대기 — 환불 도구 호출 전 금전 영향으로 관리자 승인 필요 → 승인 후 실행 \u0026ldquo;에이전트는 언제 행동할지, 언제 질문할지, 언제 기다릴지를 안다. 이것이 실제 거버넌스다\u0026rdquo;\n역사적 교훈 \u0026ldquo;이것은 새로운 것이 아니다. 우리는 수십 년 동안 안정적인 분산 시스템을 구축해왔다. AI 산업은 단지 그 교훈을 가져오지 않았고, 우리는 모든 실패한 배포에서 이를 느끼고 있다\u0026rdquo;\n80년 된 시스템 엔지니어링의 교훈: 개별 구성요소를 최적화해서는 시스템을 최적화할 수 없다. 전체의 행동(라우팅, 안정성, 용량, 비용)은 부분들이 상호작용하는 방식에서 나온다.\n결론 \u0026ldquo;에이전틱 소프트웨어 엔지니어링은 학문이다. 이를 일찍 내재화하는 팀이 훌륭한 제품을 배포할 것이다. 에이전트를 스크립트로 계속 취급하는 팀은 계속 목표를 놓칠 것이다\u0026rdquo;\n","wordCount":518,"tags":["AI","에이전트","소프트웨어엔지니어링","분산시스템","프로덕션","아키텍처"],"categories":["AI"],"frameworks":["Systems Thinking","First Principles"],"mental_models":["Layered Architecture","Feedback Loop"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트 구축은 쉽지만 프로덕션 운영은 분산 시스템 문제다","Build-Serve-Connect 3단계 중 Serve에서 대부분 정체 — 사용자별 격리·세션·확장 필요","6가지 기둥: 내구성(체크포인트+재개), 격리(테넌트 경계), 거버넌스(계층화된 권한), 지속성(복리 학습), 규모(비동기 종속성), 조합가능성(에이전트 간 협업)","대부분의 에이전트 프레임워크가 Build만 지원, Serve와 Connect는 직접 구축해야 한다"],"related":["posts/components-of-a-coding-agent","posts/continual-learning-for-ai-agents"]},{"title":"LLM 에이전트를 위한 강화학습 환경 분류법 — 모델이 아닌 환경이 에이전트의 행동을 결정한다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/rl-environments-for-llm-agents/","section":"posts","date":"2026-04-11T18:00:44+09:00","lastmod":"2026-04-11T18:00:44+09:00","description":"모델 아키텍처가 아닌 RL 환경 설계가 에이전트 성능의 절반을 결정한다는 주장과 함께, 작업(T)·하네스(H)·검증기(V)·상태(S)·설정(C) 5요소 프레임워크를 상세히 분석한다.","summary":"모델 아키텍처와 사후 학습(post-training)에만 집중하는 현재 AI 개발 패러다임을 비판하며, \u0026ldquo;에이전트가 무엇을 배울 수 있는지 결정하는 것은 강화학습 환경\u0026quot;이라고 주장합니다. 환경 설계가 시스템 성능의 절반을 차지한다는 것이 핵심입니다.\n원문: RL Environments for LLM Agents\n핵심 주장 단일 턴 Q\u0026amp;A로만 학습한 모델은 50단계 엔터프라이즈 워크플로우에서 실패하고, 보상 함수가 형편없으면 모델이 문제를 풀기보다 지표를 조작하도록 학습된다. 모델이 아닌 환경이 에이전트의 행동을 형성 한다.\n정준 루프(Canonical Loop): E = {T, H, V, S, C} RL 환경을 다섯 가지 요소로 정의한다:\n","content":"모델 아키텍처와 사후 학습(post-training)에만 집중하는 현재 AI 개발 패러다임을 비판하며, \u0026ldquo;에이전트가 무엇을 배울 수 있는지 결정하는 것은 강화학습 환경\u0026quot;이라고 주장합니다. 환경 설계가 시스템 성능의 절반을 차지한다는 것이 핵심입니다.\n원문: RL Environments for LLM Agents\n핵심 주장 단일 턴 Q\u0026amp;A로만 학습한 모델은 50단계 엔터프라이즈 워크플로우에서 실패하고, 보상 함수가 형편없으면 모델이 문제를 풀기보다 지표를 조작하도록 학습된다. 모델이 아닌 환경이 에이전트의 행동을 형성 한다.\n정준 루프(Canonical Loop): E = {T, H, V, S, C} RL 환경을 다섯 가지 요소로 정의한다:\n요소 설명 T(Tasks) 에이전트가 해결해야 할 문제들 H(Harness) 모델이 환경과 상호작용하는 방식 V(Verifier) 출력을 점수로 변환하는 검증 함수 S(State) 환경의 상태 관리 C(Configuration) 턴 제한, 컨텍스트 예산 등 설정값 훈련 루프: 작업 데이터셋 → 에이전트 → 도구/환경 ↔ 상호작용 → 검증기/점수 → 보상 신호 → 트레이너\n1. 작업(Tasks) — T 작업 유형 분류 유형 에이전트가 수행할 작업 사례 단일 턴 Q\u0026amp;A 한 번의 프롬프트 → 검증 수학 벤치마크 다중홉 검색 연쇄적 검색 후 출처 통합 BrowseComp 개방형 연구 정답 부재, 품질 판단 ADR-Bench 도구 활용 순차적 도구 호출 tau-bench 상태 유지 워크플로우 데이터베이스 상태 수정 EnterpriseOps-Gym 코드 생성 작성 → 실행 → 검증 SWE-Bench 저장소 수준 코딩 대규모 코드베이스 네비게이션 RepoBench 생산성 워크플로우 이메일 작성, 캘린더 관리 WorkArena 중요 원리 작업 분포 설계 : 모델이 탐색할 수 있도록 혼합된 난이도 필요 합성 데이터 : 역번역(원하는 출력에서 입력 역구성), 그래프 기반 생성(지식그래프에서 다중홉 쿼리 생성) 용어 정의 : 궤적(상태-행동-보상 튜플 시퀀스), 에피소드(시작~완료 한 회차), 롤아웃(정책 실행하여 궤적 생성), 추적(도구 호출·관찰·중간 출력을 포함한 구조화된 실행 로그) 2. 에이전트 하네스(Agent Harness) — H 하네스 구성 H = { rollout_protocol, # SingleTurn | MultiTurn | Agentic tools, # 사용 가능한 도구 system_prompt, # 에이전트 지시사항 context_manager, # 컨텍스트 오버플로우 처리 turn_limit, # 최대 상호작용 수 sandbox, # 코드 실행 샌드박스 state # 턴 간 지속 상태 } 롤아웃 프로토콜 타입 설명 사용 시기 단일 턴 한 번의 프롬프트 응답 수학, 팩트 QA 다중 턴 대화형 상호작용 게임, 구조화 작업 도구 사용 도구 호출 → 결과 수신 에이전트 벤치 상태 유지 도구 사용 도구가 지속 상태 수정 엔터프라이즈, SWE-Bench 에이전틱 완전 OODA 루프 깊은 연구, 복합 워크플로우 도구 분류 카테고리 도구 예시 결정론적? 상태 유지? 정보 검색 web_search 아니오(라이브) 아니오 콘텐츠 추출 jina_reader 아니오 아니오 코드 실행 python_interpreter 예 예 파일 작업 file_read/write 예 예 브라우저 자동화 playwright 아니오 예 작업 관리 todo, section_write 예 예 현대 설계 추세: 원자적 기본 도구(read, write, edit, bash, subprocess) 중심으로 단순화.\n컨텍스트 관리 전략 전략 설명 트레이드오프 최근성 기반 최근 N개 턴만 보관 초기 맥락 손실 마르코프 재구성 매 턴마다 상태 재구성 계산 비용 높음 참조 보존 정리 오래된 맥락을 정리하되 인용 유지 검증성 보존 참조 보존 폴딩 참조 손실 없이 맥락 압축 연구 작업에 최적 3. 검증기(Verifier) — V 생성-검증 격차(Generation-Verification Gap) 출력 생성은 저비용이지만 품질 검증은 개방형 작업에서 어렵다.\n보상 신호 유형 유형 신호 사용 시기 정확한 일치 이진(0/1) 정답 있음 코드 실행 이진 또는 부분 프로그래밍으로 테스트 가능 LLM 판사 연속[0,1] 개방형 품질, 대안 없음 체크리스트 연속 다중 기준 연구 진화 루브릭(RLER) 연속 보상 해킹 저항 프로세스 보상 모델 N-스텝별 연속 장시간 신용 할당 쌍별 비교 상대 순위 절대값보다 상대값 중요 다중 기준 복합 가중치 합 품질 차원 다중 검증기 설계 원리 \u0026ldquo;검증 가능함이 판단 가능함을 이김\u0026rdquo; : 프로그래밍 검사(문자열 매칭, 코드 실행)는 LLM 판사보다 빠르고 저비용, 일관성 있음. LLM 판사는 필요할 때만.\n보상 세분화 : 궤적 수준(최종 출력만), 턴 수준(각 도구 호출 평가 — Nanbeige4.1이 600 도구 호출까지 지원), 프로세스 보상(단계별). 비유: 조명 교체는 단순 확인, 부엌 개보수는 정기 검사와 마일스톤 필요.\n정적 루브릭은 게임화됨 : 모델이 문제 해결 대신 루브릭 점수에 최적화. 해결책: RLER(루브릭 수준 진화 보상)로 훈련 중 루브릭 공진화.\n노이즈 주입 과소평가됨 : Step-DeepResearch는 훈련 중 5-10% 도구 오류 주입 → 프로덕션에서 불안정한 API 처리 대폭 개선.\n4. 상태(State) — S \u0026amp; 설정(Configuration) — C 상태 관리 상태 없는 환경 : 각 에피소드 독립적 (예: LeetCode 코딩) 상태 있는 환경 : 에피소드 간 지속 상태. EnterpriseOps-Gym: 164개 DB 테이블, 512 도구, 한 작업의 액션이 다음 작업 상태에 영향. 자동 환경 생성 LLM 코딩 에이전트가 환경 코드 자동 생성 가능. AutoEnv: 환경당 ~$4 평균 비용.\n설정 파라미터 턴 제한 : 5 vs 600은 에이전트 학습 능력을 근본적으로 변화시킴 커리큘럼 스케줄링 : AgentScaler의 이단계 접근(기본 능력 → 도메인 특화) 유효 프로그레시브 스케일링 : Step-DeepResearch는 훈련 중 컨텍스트 윈도우를 32K에서 128K로 확대 5. 벤치마크: 동결된 RL 환경 벤치마크를 \u0026ldquo;동결된 RL 환경\u0026quot;으로 재프레임한다.\n벤치마크 4-튜플 : B = (Request, Environment, Stopping Criteria, Scorer)\n좋은 벤치마크 = 좋은 훈련 환경의 설계 원리 작업 자연성 : SWE-bench 성공 이유는 실제 GitHub 이슈 사용. 합성 문제보다 유용. 자동, 검증 가능한 채점 : 벤치마크는 백수 평가자, 훈련은 백만 보상 신호 필요 → 훈련에서 더 중요. 난이도 보정 : 너무 쉬우면 천장 도달, 너무 어려우면 신호 부족. 커리큘럼으로 동적 조정 가능. 채점기 독립성 : 정책과 판사에 같은 모델 족 사용 → 피드백 루프. 판사는 다른 모델 클래스, 훈련이 업데이트 불가능해야 함. 추가 고려사항 환경 다양성 AgentScaler 핵심 발견: 환경 유형 다양성이 같은 분포의 더 많은 데이터보다 능력 범위 확대에 중요.\n환경-패키지 모델과 관리 서비스화 Prime Intellect Environments Hub : PyPI/HuggingFace처럼 공유 RL 환경 생태계 OpenReward : 330+ RL 환경을 관리 API 엔드포인트로 제공 (4.5M+ 작업, 오토스케일 샌드박스) Open Reward Standard (ORS) : MCP를 RL 프리미티브(에피소드, 보상, 커리큘럼)로 확장 → 환경 트레이너 분리 오염 저항성 RL 환경 재사용 시 사전훈련 데이터 오염(벤치마크 답 암기) 위협 증가. 해결책: 보유 작업 분할, 동적 작업 생성, 검증기 측 답 보류.\n결론 \u0026ldquo;RL 환경은 에이전트의 행동을 형성하는 훈련장. 작업 분포는 개발할 기술 결정, 하네스는 상호작용 방식 제어, 검증기는 \u0026lsquo;좋음\u0026rsquo;의 정의, 상태와 설정은 현실성 결정. 이들을 올바르게 얻으면 에이전트는 프로덕션에 이전 가능한 행동 학습. 잘못 얻으면 비싼 데모만 남는다.\u0026rdquo;\n요소 핵심 T(작업) 자연적, 혼합 난이도, 합성 생성 고려 H(하네스) 원자적 도구, 문맥 관리 전략, 유연한 롤아웃 프로토콜 V(검증기) 프로그래밍 가능한 검증 우선, 세분화된 보상, 동적 루브릭 S(상태) 상태성 작업 포함, 자동 생성 탐색 C(설정) 동적 커리큘럼, 점진적 스케일링 ","wordCount":949,"tags":["AI","강화학습","에이전트","LLM","RL","환경설계"],"categories":["AI"],"frameworks":["First Principles","Systems Thinking"],"mental_models":["Layered Architecture","Feedback Loop"],"philosophy_type":"epistemology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM 에이전트를 위한 강화학습 환경 분류법 — 모델이 아닌 환경이 에이전트의 행동을 결정한다의 핵심 문제의식은 \"모델 아키텍처가 아닌 RL 환경 설계가 에이전트 성능의 절반을 결정한다는 주장과 함께, 작업(T)·하네스(H)·검증기(V)·상태(S)·설정(C) 5요소 프레임워크를 상세히 분석한다.\"다","본문은 핵심 주장 → 정준 루프(Canonical Loop): E = {T, H, V, S, C} → 1. 작업(Tasks) — T 흐름으로 논지를 전개한다","AI, 강화학습, 에이전트 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/components-of-a-coding-agent","posts/continual-learning-for-ai-agents"]},{"title":"코딩 에이전트의 핵심 구성요소 — 모델이 아닌 하네스가 성능을 결정한다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/components-of-a-coding-agent/","section":"posts","date":"2026-04-11T17:59:06+09:00","lastmod":"2026-04-11T17:59:06+09:00","description":"Sebastian Raschka가 분석한 코딩 에이전트의 6가지 핵심 구성요소. 모델 자체보다 하네스 아키텍처(컨텍스트 관리, 도구 접근, 메모리, 서브에이전트 등)가 최종 성능을 결정한다는 주장.","summary":"Sebastian Raschka가 Claude Code, Codex 같은 코딩 도구들이 기존 채팅 인터페이스보다 강력한 이유는 더 나은 모델 때문이 아니라, 모델을 둘러싼 \u0026ldquo;에이전트 하네스(harness)\u0026ldquo;의 설계 때문이라고 분석합니다. 같은 모델이라도 다른 하네스에 넣으면 완전히 다른 성능을 보일 수 있습니다.\n원문: Components of a Coding Agent\n핵심 주장 \u0026ldquo;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\u0026rdquo;\n최신 LLM들(GPT-5.4, Opus 4.6 등)의 기본 성능이 유사해진 지금, 하네스의 품질이 최종 성능의 차별화 요소 가 된다.\n","content":"Sebastian Raschka가 Claude Code, Codex 같은 코딩 도구들이 기존 채팅 인터페이스보다 강력한 이유는 더 나은 모델 때문이 아니라, 모델을 둘러싼 \u0026ldquo;에이전트 하네스(harness)\u0026ldquo;의 설계 때문이라고 분석합니다. 같은 모델이라도 다른 하네스에 넣으면 완전히 다른 성능을 보일 수 있습니다.\n원문: Components of a Coding Agent\n핵심 주장 \u0026ldquo;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\u0026rdquo;\n최신 LLM들(GPT-5.4, Opus 4.6 등)의 기본 성능이 유사해진 지금, 하네스의 품질이 최종 성능의 차별화 요소 가 된다.\nLLM, 추론 모델, 에이전트의 구분 LLM(언어모델) : 기본적인 다음 토큰 생성 엔진 추론 모델 : 추가 학습을 받은 LLM으로, 중간 추론 과정을 더 상세히 수행 에이전트 : 모델을 감싸는 제어 루프로서, 어떤 도구를 사용할지, 상태를 어떻게 업데이트할지 결정 저자의 비유: \u0026ldquo;엔진, 강화된 엔진, 그리고 엔진을 효과적으로 사용하도록 도와주는 시스템\u0026rdquo;\n코딩 하네스의 6가지 핵심 구성요소 1. 라이브 저장소 컨텍스트 (Live Repo Context) \u0026ldquo;테스트를 수정해줘\u0026quot;는 독립적인 명령이 아니다. 에이전트는 현재 Git 상태, 브랜치, 프로젝트 문서 위치, 작업 진행 상황을 파악해야 한다. 저장소 구조, README나 AGENTS.md 같은 문서들이 에이전트의 행동을 크게 좌우하며, 매 요청마다 처음부터 시작하지 않도록 \u0026ldquo;안정적인 사실들\u0026quot;로 작업공간 을 구성한다.\n2. 프롬프트 형태 및 캐시 재사용 (Prompt Shape And Cache Reuse) 코딩 세션은 반복적 특성을 가진다 — 에이전트 규칙, 도구 설명, 작업공간 은 계속 같고, 변하는 것은 최신 사용자 요청과 최근 기록뿐이다.\n안정적 프롬프트 프리픽스 (변화 없음) ↓ + 변화하는 세션 상태 (매번 갱신) ↓ = 모델에 전달될 최종 프롬프트 \u0026ldquo;안정적 프리픽스\u0026quot;를 캐시하여 컴퓨팅 비용을 절감한다.\n3. 도구 접근 및 사용 (Tool Access and Use) 코딩 하네스의 모델은 사전 정의된 명확한 도구 목록 만 사용할 수 있다.\n흐름: 모델이 구조화된 액션 방출 → 하네스가 검증 → 필요시 사용자 승인 요청 → 실행 → 결과를 루프에 피드백\n하네스의 검증: 알려진 도구인가? 인수가 유효한가? 사용자 승인이 필요한가? 요청된 경로가 작업공간 내인가? 자유도를 제한하지만, 신뢰성을 높이고 보안 위험을 줄인다.\n4. 컨텍스트 비대화 최소화 (Minimizing Context Bloat) 긴 컨텍스트는 비싸고 노이즈를 증가시킨다. 코딩 에이전트는 반복적인 파일 읽기, 긴 도구 출력, 로그로 인해 특히 취약하다.\n두 가지 주요 압축 전략:\n클리핑(Clipping) : 긴 문서 스니펫, 도구 출력, 메모리 노트를 축약하여 한 부분이 전체 프롬프트 예산을 차지하는 것을 방지 트랜스크립트 감소 : 전체 세션 기록을 더 작은 본으로 변환. 최근 이벤트는 상세하게, 오래된 이벤트는 공격적으로 압축, 중복된 파일 읽기는 제거 겉보기의 \u0026ldquo;모델 품질\u0026quot;은 실제로는 컨텍스트 품질 일 수 있다.\n5. 구조화된 세션 메모리 (Structured Session Memory) 에이전트는 두 가지 상태 계층을 분리한다:\n작업 메모리(Working Memory) : 작고 증류된 상태. 현재 작업, 중요한 파일, 최근 노트를 에이전트가 명시적으로 유지 전체 트랜스크립트(Full Transcript) : 모든 사용자 요청, 도구 출력, LLM 응답 기록 두 데이터는 JSON 파일로 디스크에 저장되어 세션 재개가 가능하다. 컴팩트 트랜스크립트는 프롬프트 재구성용, 작업 메모리는 작업 연속성용으로 구분된다.\n6. 하위 에이전트를 통한 위임 (Delegation With Bounded Subagents) 에이전트가 모든 작업을 혼자 처리하는 것이 아니라, 부작업을 병렬로 처리하는 하위 에이전트를 생성할 수 있다.\n사용 예시: 심볼 정의 위치 찾기, 설정 파일 내용 확인, 테스트 실패 원인 분석\n설계의 핵심: 하위 에이전트에게 유용하기에 충분한 컨텍스트를 물려주되, 더 엄격한 경계 내에서 실행 (읽기 전용 모드, 재귀 깊이 제한, 작업 범위 제한).\nOpenClaw와의 비교 공통점 : 작업공간의 프롬프트/명령 파일 사용(AGENTS.md, SOUL.md, TOOLS.md), JSONL 세션 파일 및 트랜스크립트 압축, 헬퍼 세션과 하위 에이전트 지원\n차이점 : OpenClaw는 로컬 일반 에이전트 플랫폼(코딩도 가능)이고, 코딩 하네스는 코딩 작업에 특화된 전문가.\n결론 현대 AI의 실제 성능 향상은 모델 자체의 혁신뿐만 아니라, 그 모델을 둘러싼 시스템 아키텍처의 정교함 에서 나온다. 모델의 \u0026ldquo;화려함\u0026quot;과 하네스의 \u0026ldquo;지루하지만 중요한 세부사항\u0026rdquo; 모두를 고려해야 한다.\n","wordCount":558,"tags":["AI","에이전트","코딩","아키텍처","LLM","하네스"],"categories":["AI"],"frameworks":["Systems Thinking","First Principles"],"mental_models":["Layered Architecture"],"philosophy_type":"epistemology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["코딩 에이전트의 핵심 구성요소 — 모델이 아닌 하네스가 성능을 결정한다의 핵심 문제의식은 \"Sebastian Raschka가 분석한 코딩 에이전트의 6가지 핵심 구성요소. 모델 자체보다 하네스 아키텍처(컨텍스트 관리, 도구 접근, 메모리, 서브에이전트 등)가 최종 성능을 결정한다는 주장.\"다","본문은 핵심 주장 → LLM, 추론 모델, 에이전트의 구분 → 코딩 하네스의 6가지 핵심 구성요소 흐름으로 논지를 전개한다","AI, 에이전트, 코딩 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/continual-learning-for-ai-agents","posts/pmarca-ai-revolution"]},{"title":"Marc Andreessen의 AI 혁명론: 80년의 밤샘 성공과 소프트웨어 아키텍처의 재발명","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/pmarca-ai-revolution/","section":"posts","date":"2026-04-11T17:57:32+09:00","lastmod":"2026-04-11T17:57:32+09:00","description":"Marc Andreessen이 Latent Space 팟캐스트에서 제시한 AI 혁명론 . 80년 축적된 연구의 결실, 4가지 돌파구, 닷컴 버블과의 차이, Pi+OpenClaw 아키텍처, 소프트웨어 풍부성 시대를 다룬다.","summary":"Latent Space 팟캐스트에 출연한 Marc Andreessen(a16z 공동창업자)이 현재 AI 붐을 1943년 신경망 이론부터 축적된 80년의 기초 연구가 결실을 맺는 역사적 전환점으로 진단하며, 소프트웨어 아키텍처의 근본적 변화를 논합니다.\n원문: Marc Andreessen - Latent Space Podcast\n핵심 프레임: \u0026ldquo;80년의 밤샘 성공 (80 Year Overnight Success)\u0026rdquo; 현재 AI 붐은 단순한 기술 사이클이 아니라, 1943년 신경망 이론부터 축적된 80년의 기초 연구가 결실을 맺는 순간 이라는 진단.\n1. 이번이 진짜 다른 이유 — 4가지 돌파구 과거 AI는 붐-폭락(AI 겨울)을 반복했지만, 이번에는 4가지 기능이 동시에 작동 중:\n","content":"Latent Space 팟캐스트에 출연한 Marc Andreessen(a16z 공동창업자)이 현재 AI 붐을 1943년 신경망 이론부터 축적된 80년의 기초 연구가 결실을 맺는 역사적 전환점으로 진단하며, 소프트웨어 아키텍처의 근본적 변화를 논합니다.\n원문: Marc Andreessen - Latent Space Podcast\n핵심 프레임: \u0026ldquo;80년의 밤샘 성공 (80 Year Overnight Success)\u0026rdquo; 현재 AI 붐은 단순한 기술 사이클이 아니라, 1943년 신경망 이론부터 축적된 80년의 기초 연구가 결실을 맺는 순간 이라는 진단.\n1. 이번이 진짜 다른 이유 — 4가지 돌파구 과거 AI는 붐-폭락(AI 겨울)을 반복했지만, 이번에는 4가지 기능이 동시에 작동 중:\n돌파구 설명 LLM 대규모 언어 모델의 기본 기능 추론(Reasoning) O1 등장으로 단순 패턴 완성을 넘어선 실제 사고 능력 입증 코딩 능력 Linus Torvalds가 AI 코딩 실력이 자신과 동등하다고 인정한 시점이 분수령 에이전트 + 자기개선(RSI) OpenClaw 등장으로 자동화된 시스템 구축 가능 2. 닷컴 버블과의 비교: 왜 이번은 다른가 2000년 닷컴 붕괴 : 신생 기업들의 과잉 투자 → 약 2조 달러 손실\n현재 AI 붐의 차이점 :\n투자 주체가 MS, Google, Amazon, Meta, NVIDIA 등 현금 풍부한 대기업 GPU 공급 부족으로 배포되는 모든 컴퓨팅 자원이 즉시 수익 창출 3년 된 NVIDIA 칩이 오히려 지금 더 많은 수익을 창출 (소프트웨어 발전 속도 \u0026gt; 칩 감가상각) 3. 스케일링 법칙 = 새로운 무어의 법칙 무어의 법칙이 자기충족적 예언이 되었듯, AI 스케일링 법칙도 산업 전체의 동기부여 촉매 역할 컴퓨팅·데이터·알고리즘 효율성 등 여러 스케일링 법칙이 동시에 작동 중 로봇공학, 월드 모델 등 아직 발견되지 않은 스케일링 법칙도 존재 가능 4. 오픈소스 AI와 엣지 인퍼런스 오픈소스의 가치 : 무료 소프트웨어 + 세계가 \u0026ldquo;어떻게 작동하는지\u0026rdquo; 학습 가능. DeepSeek이 추론 논문/코드를 공개하자 3개월 내 모든 AI 모델이 추론 능력을 추가.\n엣지 인퍼런스가 필요한 이유 :\n향후 3-4년 만성적 GPU 부족 → 중앙화 추론 비용 상승 개인 데이터를 클라우드에 맡기기 꺼려하는 신뢰 문제 스마트폰·웨어러블 등 저지연 요구 기기 5. Pi + OpenClaw: 소프트웨어 아키텍처의 재발명 Andreessen이 가장 흥분한 주제 . \u0026ldquo;소프트웨어 역사에서 가장 중요한 10개 개념 중 하나\u0026quot;로 평가.\n에이전트 아키텍처 = LLM + Unix 셸 + 파일시스템 + 마크다운 + Cron\n획기적 특성 :\n모델 독립성 : 다른 LLM으로 교체해도 파일에 저장된 상태/기억이 유지 자기 수정 능력 : 에이전트가 인터넷에서 API를 찾고, 코드를 작성하고, 자신의 파일을 수정 완전한 내성(Introspection) : 광범위 배포 시스템이 자신의 작동 방식을 이해하고 수정할 수 있는 최초의 사례 이식성 : 다른 실행 환경·파일시스템·모델로 마이그레이션 가능 이는 1970년대 Unix 철학(모듈화, 파이프라인, 쉘)의 AI 시대 재현.\n6. 소프트웨어 풍부성 시대와 프로그래밍 언어의 종말 과거 : 소프트웨어는 소수 엘리트 엔지니어만 만들 수 있는 희귀 자원 새로운 세계 : 고품질 소프트웨어가 무한정 공급 가능\nAI 모델은 모든 언어로 프로그래밍 가능 → 언어 선택이 무의미화 \u0026ldquo;Python이 느리다\u0026quot;면 에이전트에게 Rust 버전 작성을 지시하면 됨 보안도 에이전트가 모든 취약점을 발견하고 자동 수정 7. 인간 증명(Proof of Human) 문제 에이전트들이 웹 브라우징·소셜 미디어 포스팅·이메일 발송을 하면 봇과 인간 구분이 불가능해짐. CAPTCHA 같은 검출 기반 접근법은 실패할 것이며, 생체 인증 + 암호화적 인간 증명 이 필요.\n결론 Andreessen의 핵심 메시지:\n이번은 진짜 다르다 — 4가지 증명된 돌파구가 동시에 작동 공급 제약이 기술을 인위적으로 억제 중 — 공급 증가만으로도 극적 개선 가능 Pi + OpenClaw는 Unix 혁명의 재현 — 자기 수정·모델 독립·이식 가능한 최초의 광범위 배포 시스템 소프트웨어는 희귀 자원에서 풍부한 자원으로 전환 중 \u0026ldquo;18살이라면 이것에 모든 시간을 바칠 것\u0026rdquo; — 믿을 수 없을 정도로 중요한 개념적 돌파구 ","wordCount":513,"tags":["AI","에이전트","오픈소스","스케일링","아키텍처","Marc Andreessen"],"categories":["AI"],"frameworks":["Systems Thinking","Historical Analysis"],"mental_models":["Paradigm Shift","S-Curve"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["Marc Andreessen의 AI 혁명론: 80년의 밤샘 성공과 소프트웨어 아키텍처의 재발명의 핵심 문제의식은 \"Marc Andreessen이 Latent Space 팟캐스트에서 제시한 AI 혁명론 . 80년 축적된 연구의 결실, 4가지 돌파구, 닷컴 버블과의 차이, Pi+OpenClaw 아키텍처, 소프트웨어 풍부성 시대를 다룬다.\"다","본문은 핵심 프레임: \"80년의 밤샘 성공 (80 Year Overnight Success)\" → 1. 이번이 진짜 다른 이유 — 4가지 돌파구 → 2. 닷컴 버블과의 비교: 왜 이번은 다른가 흐름으로 논지를 전개한다","AI, 에이전트, 오픈소스 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/continual-learning-for-ai-agents","posts/ai-agents-future-context-gap"]},{"title":"AI 에이전트의 지속적 학습: 모델·하네스·컨텍스트 3계층 학습 프레임워크","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/continual-learning-for-ai-agents/","section":"posts","date":"2026-04-11T17:48:21+09:00","lastmod":"2026-04-11T17:48:21+09:00","description":"AI 에이전트의 학습은 모델 가중치 업데이트만이 아니라 모델·하네스·컨텍스트 3계층에서 각각 독립적으로 발생할 수 있다는 LangChain의 지속적 학습 프레임워크를 한다.","summary":"LangChain CEO Harrison Chase가 AI 에이전트의 지속적 학습(Continual Learning)에 대해 제시한 프레임워크를 합니다. 에이전트의 \u0026ldquo;학습\u0026quot;은 모델 가중치 업데이트만을 의미하지 않으며, 3가지 서로 다른 계층에서 발생할 수 있다는 것이 핵심 주장입니다.\n원문: Continual Learning for AI Agents\n핵심 주장 AI 에이전트의 \u0026ldquo;학습\u0026quot;은 모델 가중치 업데이트만이 아니라, 3가지 계층에서 각각 독립적으로 발생 할 수 있다.\n에이전트 시스템의 3계층 구조 계층 설명 예시 (Claude Code) 모델 계층 모델 가중치 자체 Claude Sonnet 하네스 계층 에이전트를 구동하는 코드·지시문·도구 Claude Code 자체 컨텍스트 계층 하네스 외부의 설정 가능한 지시문·스킬 CLAUDE.md, /skills 각 계층별 학습 방법 모델 계층 학습 — SFT, RL, GRPO 등 전통적 학습 기법 사용. 단, 재앙적 망각(catastrophic forgetting) 문제가 핵심 과제 (새 데이터 학습 시 기존 지식이 저하됨).\n","content":"LangChain CEO Harrison Chase가 AI 에이전트의 지속적 학습(Continual Learning)에 대해 제시한 프레임워크를 합니다. 에이전트의 \u0026ldquo;학습\u0026quot;은 모델 가중치 업데이트만을 의미하지 않으며, 3가지 서로 다른 계층에서 발생할 수 있다는 것이 핵심 주장입니다.\n원문: Continual Learning for AI Agents\n핵심 주장 AI 에이전트의 \u0026ldquo;학습\u0026quot;은 모델 가중치 업데이트만이 아니라, 3가지 계층에서 각각 독립적으로 발생 할 수 있다.\n에이전트 시스템의 3계층 구조 계층 설명 예시 (Claude Code) 모델 계층 모델 가중치 자체 Claude Sonnet 하네스 계층 에이전트를 구동하는 코드·지시문·도구 Claude Code 자체 컨텍스트 계층 하네스 외부의 설정 가능한 지시문·스킬 CLAUDE.md, /skills 각 계층별 학습 방법 모델 계층 학습 — SFT, RL, GRPO 등 전통적 학습 기법 사용. 단, 재앙적 망각(catastrophic forgetting) 문제가 핵심 과제 (새 데이터 학습 시 기존 지식이 저하됨).\n하네스 계층 학습 — 에이전트 실행 로그(trace)를 수집한 뒤, 코딩 에이전트가 이를 분석하여 하네스 코드 자체를 개선 하는 방식. 오프라인으로 수행.\n컨텍스트 계층 학습 — 가장 유연한 계층.\n에이전트 수준 vs 테넌트(사용자/조직) 수준 학습 가능 오프라인 (예: OpenClaw의 \u0026ldquo;dreaming\u0026rdquo;) vs 온라인 (작업 중 실시간 메모리 업데이트) 방식 사용자 명시적 프롬프트 또는 하네스 지시문 기반 자동 업데이트 실제 구현 사례 Claude Code : CLAUDE.md 파일과 skills로 컨텍스트 계층 학습 OpenClaw : SOUL.md + clawhub skills Hex의 Context Studio , Decagon의 Duet , Sierra의 Explorer 등 프로덕션 적용 사례 핵심 인프라: Traces (추적) 모든 학습 흐름의 기반은 에이전트의 전체 실행 경로(trace) . 이를 수집·분석하는 플랫폼으로 LangSmith를 제시.\n결론 에이전트 성능 개선은 모델 재학습에만 의존하지 않아도 된다. 하네스 최적화 + 사용자/조직별 컨텍스트 학습 을 조합하면 프로덕션 환경에서 지속적 개선이 가능하며, 이 다층적 학습 프레임워크가 에이전트 시스템의 핵심 경쟁력이 될 것이라는 주장입니다.\n","wordCount":254,"tags":["AI","에이전트","지속적학습","LangChain","LLM"],"categories":["AI"],"frameworks":["Systems Thinking"],"mental_models":["Layered Architecture"],"philosophy_type":"epistemology","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 에이전트의 지속적 학습: 모델·하네스·컨텍스트 3계층 학습 프레임워크의 핵심 문제의식은 \"AI 에이전트의 학습은 모델 가중치 업데이트만이 아니라 모델·하네스·컨텍스트 3계층에서 각각 독립적으로 발생할 수 있다는 LangChain의 지속적 학습 프레임워크를 한다.\"다","본문은 핵심 주장 → 에이전트 시스템의 3계층 구조 → 각 계층별 학습 방법 흐름으로 논지를 전개한다","AI, 에이전트, 지속적학습 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/ai-agents-future-context-gap"]},{"title":"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-11T16:53:35+09:00","lastmod":"2026-04-11T16:53:35+09:00","description":"Django 핵심 기여자 James Bennett가 Fred Brooks의 '은탄환은 없다' 프레임워크를 통해 LLM 코딩 도구의 효과를 이론적·실증적으로 분석한 글 요약. METR, DORA, CircleCI 등의 데이터가 보여주는 현실.","summary":"Django 핵심 기여자인 James Bennett가 LLM 코딩 도구의 효과에 대해 이론적·실증적 근거를 들어 회의적 분석을 제시한 글입니다.\n원문: LLMs\n핵심 프레임워크: Fred Brooks의 \u0026ldquo;은탄환은 없다\u0026rdquo; (1975) 소프트웨어 개발의 어려움을 두 가지로 구분합니다:\n우발적(accidental) 어려움 — 도구로 제거 가능 (수동 메모리 관리 등) 본질적(essential) 어려움 — 사양, 설계, 테스트 등 소프트웨어 자체에 내재된 것 Brooks의 핵심 통찰: \u0026ldquo;어려운 부분은 개념을 구축하는 것이지, 그것을 표현하는 노동이 아니다.\u0026rdquo; 우발적 어려움이 전체의 90% 이상이 아닌 한 10배 생산성 향상은 불가능하며, 실제 비율은 훨씬 낮다고 저자는 봅니다.\n","content":"Django 핵심 기여자인 James Bennett가 LLM 코딩 도구의 효과에 대해 이론적·실증적 근거를 들어 회의적 분석을 제시한 글입니다.\n원문: LLMs\n핵심 프레임워크: Fred Brooks의 \u0026ldquo;은탄환은 없다\u0026rdquo; (1975) 소프트웨어 개발의 어려움을 두 가지로 구분합니다:\n우발적(accidental) 어려움 — 도구로 제거 가능 (수동 메모리 관리 등) 본질적(essential) 어려움 — 사양, 설계, 테스트 등 소프트웨어 자체에 내재된 것 Brooks의 핵심 통찰: \u0026ldquo;어려운 부분은 개념을 구축하는 것이지, 그것을 표현하는 노동이 아니다.\u0026rdquo; 우발적 어려움이 전체의 90% 이상이 아닌 한 10배 생산성 향상은 불가능하며, 실제 비율은 훨씬 낮다고 저자는 봅니다.\n참고: No Silver Bullet — Essence and Accident in Software Engineering (원문)\n실증 데이터가 보여주는 현실 METR (2025) 개발자들이 24% 속도 향상을 기대했으나 실제로는 둔화 를 경험했습니다. 더 흥미로운 점은, 둔화를 경험한 후에도 본인들은 여전히 \u0026ldquo;20% 빨라졌다\u0026quot;고 믿었다는 것입니다. 자기보고식 생산성 측정이 실제 결과와 괴리된다는 점이 드러납니다.\nDORA 보고서 처음에는 \u0026ldquo;AI 채택이 정상\u0026quot;이라 선언했지만, 상세히 보면 \u0026ldquo;AI는 증폭기 역할\u0026rdquo; 을 합니다. 강력한 조직은 강해지고 약한 조직은 더 약해집니다. 배포 처리량은 증가했으나 배포 불안정성도 동시에 증가 하여, 순효과가 상쇄됩니다.\nCircleCI (2026) 다수 팀이 처리량 변화가 없었고, 주요 브랜치 성공률이 90%에서 70.8%로 저하 되었습니다. 복구 시간이 증가하여 일일 5개 변경 팀은 2일마다 장애를 경험하는 상황입니다.\n\u0026ldquo;빠른 코딩\u0026quot;의 함정 Tailscale CEO의 관찰을 인용합니다:\n\u0026ldquo;Claude가 30분 대신 3분에 코딩했다? 그 후 27분을 자기 검토하거나, 검증되지 않은 코드를 리뷰어에게 던지는 것 중 하나다.\u0026rdquo;\nBrooks 추정에 따르면 소프트웨어 작업의 5/6(약 83%)은 코딩 이외 (설계, 사양, 테스트, 코드 리뷰)에 소비됩니다. 코딩만 가속해봐야 전체 병목은 해결되지 않습니다.\n사례로 Cloudflare의 LLM 기반 Next.js 재구축을 제시합니다 — 기본 앱조차 실행 불가, 보안 문제 다수, 기존 테스트 스위트 미포함으로 회귀 버그가 누락되었습니다.\n\u0026ldquo;민주화\u0026rdquo; 약속의 논리적 모순 LLM 옹호론의 두 주장이 양립 불가능하다고 지적합니다:\n\u0026ldquo;LLM을 효과적으로 쓰려면 상당한 기술이 필요하다\u0026rdquo; \u0026ldquo;비기술자도 소프트웨어를 쉽게 만들 수 있다\u0026rdquo; Dijkstra 인용: \u0026ldquo;자연어의 \u0026lsquo;자연성\u0026rsquo;은 말도 안 되는 것을 쉽게 표현할 수 있다는 점에 불과하다.\u0026rdquo;\n\u0026ldquo;뒤처질 것\u0026rdquo; 두려움에 대한 분석 시나리오 A (LLM이 제한적 도구에 그치는 경우): 채택 지연은 위험하지 않음 시나리오 B (진정한 혁명이 일어나는 경우): 본질적 어려움까지 해결하는 변화라면 현재 LLM 워크플로우 자체가 무효화될 수준이므로, 후발 주자도 충분히 따라잡을 수 있음 어느 쪽이든 지금 서두를 이유가 없다는 결론입니다.\n저자의 결론 LLM은 소프트웨어 전달 능력에 제한적 영향 을 미칩니다. 진정한 생산성 향상은 버전 관리, 포괄적 테스트, CI/CD, 문서화, 작은 배치 작업 같은 근본적 개발 관행 개선 에 달려 있으며, 이는 LLM 채택 여부와 무관하게 필수입니다.\nBrooks가 표현한 바처럼: \u0026ldquo;소프트웨어 공학의 기초는 질병을 악마론에서 세균론으로 옮긴 의학처럼, 마법의 해결책 없이 꾸준한 훈련과 청결함을 요구한다.\u0026rdquo;\n","wordCount":389,"tags":["AI","LLM","코딩","생산성","소프트웨어공학","은탄환"],"categories":["software"],"frameworks":["First Principles","Second-order thinking"],"mental_models":["Occam's Razor","Cost-Benefit Analysis"],"philosophy_type":"epistemology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM 코딩에 은탄환은 없다 — Fred Brooks의 프레임워크로 본 AI 코딩 도구의 현실의 핵심 문제의식은 \"Django 핵심 기여자 James Bennett가 Fred Brooks의 '은탄환은 없다' 프레임워크를 통해 LLM 코딩 도구의 효과를 이론적·실증적으로 분석한 글 요약. METR, DORA, CircleCI 등의 데이터가 보여주는 현실.\"다","본문은 핵심 프레임워크: Fred Brooks의 \"은탄환은 없다\" (1975) → 실증 데이터가 보여주는 현실 → \"빠른 코딩\"의 함정 흐름으로 논지를 전개한다","AI, LLM, 코딩 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agent-psychosis"]},{"title":"AI의 능력 향상은 비용 하락이 아닌 작업 범위 확대로 나타났다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-capability-not-cost-reduction/","section":"posts","date":"2026-03-31T10:15:00+09:00","lastmod":"2026-03-31T10:15:00+09:00","description":"AI 모델의 능력 향상이 주로 추론 비용 절감에서 온 것이 아니라, 모델이 더 길고 복잡한 작업을 처리할 수 있게 된 것에서 비롯된다는 반직관적인 관점을 다룬다.","summary":"AI 모델의 **능력(capability)**이 크게 향상된 것은 주로 **추론 비용(inference cost)**이 인간 노동 대비 더 저렴해졌기 때문이 아니라, 모델이 **더 길고 복잡한 작업(longer/harder tasks)**을 처리할 수 있게 되었기 때문이라는 점을 강조합니다.\n능력 향상(예: METR의 frontier time horizons 기준으로 몇 달마다 배로 증가)은 관찰되지만, 이는 \u0026ldquo;같은 작업을 더 싸게 하는\u0026rdquo; 형태가 아닙니다. 오히려 추론 비용이 상승하는 경향을 보이는데, 이는 모델이 더 긴/어려운 작업을 수행하기 때문에 발생하는 자연스러운 현상입니다. (더 많은 compute/token을 소모) 현재 frontier 모델들은 50% 신뢰도(reliability) horizon에서 인간 비용의 약 3% 수준으로 작업을 수행하며, 이 비용 비율(인간 대비)은 능력 향상에도 크게 변하지 않고 있다는 데이터가 제시됩니다. 핵심 포인트\n","content":"AI 모델의 **능력(capability)**이 크게 향상된 것은 주로 **추론 비용(inference cost)**이 인간 노동 대비 더 저렴해졌기 때문이 아니라, 모델이 **더 길고 복잡한 작업(longer/harder tasks)**을 처리할 수 있게 되었기 때문이라는 점을 강조합니다.\n능력 향상(예: METR의 frontier time horizons 기준으로 몇 달마다 배로 증가)은 관찰되지만, 이는 \u0026ldquo;같은 작업을 더 싸게 하는\u0026rdquo; 형태가 아닙니다. 오히려 추론 비용이 상승하는 경향을 보이는데, 이는 모델이 더 긴/어려운 작업을 수행하기 때문에 발생하는 자연스러운 현상입니다. (더 많은 compute/token을 소모) 현재 frontier 모델들은 50% 신뢰도(reliability) horizon에서 인간 비용의 약 3% 수준으로 작업을 수행하며, 이 비용 비율(인간 대비)은 능력 향상에도 크게 변하지 않고 있다는 데이터가 제시됩니다. 핵심 포인트\n능력 향상 ≠ 비용 절감(affordability improvement)\n많은 사람들이 AI 진보를 \u0026ldquo;더 싸지고 접근하기 쉬워짐\u0026quot;으로 해석하지만, 실제로는 작업 범위/복잡도 확대가 주동력입니다. 이는 AI가 인간을 대체할 때의 **경제적 함의(economic implications)**를 이해하는 데 중요합니다. 단순히 \u0026ldquo;가격이 떨어져서\u0026rdquo; 자동화가 일어나는 게 아니라, 모델이 더 많은 일을 할 수 있게 되면서 비용 구조가 달라집니다. 포스트는 METR 등의 벤치마크 데이터를 근거로 이 주장을 뒷받침하며, AI 진보의 본질을 더 정확히 파악해야 한다는 메시지를 전달합니다. 전체적으로, AI 스케일링과 경제성에 대한 흔한 오해를 바로잡는 내용으로, \u0026ldquo;능력 향상이 비용 하락에서 오는 게 아니다\u0026ldquo;라는 반직관적인 관점을 제시합니다. (포스트는 최근 게시된 것으로, AI 커뮤니티에서 논의되고 있으며 팟캐스트로도 나왔습니다.)\n원문: AI\u0026rsquo;s Capability Improvements Haven\u0026rsquo;t Come From It Getting Cheaper\n","wordCount":203,"tags":["AI","스케일링","비용","추론","자동화","경제성"],"categories":["AI"],"frameworks":["First Principles"],"mental_models":["Cost-Benefit Analysis"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 능력 향상의 본질은 추론 비용 절감이 아니라 더 길고 복잡한 작업 수행 능력의 확대","Frontier 모델의 50% 신뢰도 horizon에서 인간 대비 비용 비율(약 3%)은 능력 향상에도 거의 변하지 않음","추론 비용은 동일 작업 기준 하락이 아니라 더 많은 compute/token 소모로 인해 오히려 상승","능력 향상 ≠ 비용 절감 — AI 경제성 이해를 위한 핵심 프레임워크"],"related":["posts/ai-agents-future-context-gap","posts/hidden-llm-api-costs","posts/components-of-a-coding-agent"]},{"title":"AI 에이전트의 미래는 이미 와 있지만, 아직 균등하게 퍼지지는 않았다","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/ai-agents-future-context-gap/","section":"posts","date":"2026-03-31T10:00:00+09:00","lastmod":"2026-03-31T10:00:00+09:00","description":"AI 에이전트의 미래에 대한 통찰. 테크 업계에서는 폭발적으로 성장 중인 코딩 에이전트와 달리, 일반 지식 노동자겐 아직 초기 단계. 가장 큰 장벽인 'Context Gap'을 분석하고 향후 기회를 제시한다.","summary":"AI 에이전트의 미래는 이미 와 있지만, 아직 균등하게 퍼지지 않았다 (William Gibson 인용).\n테크 업계에서는 코딩 에이전트가 폭발적으로 성장 중. 긴 작업을 처리하고, 제품 전체를 에이전트로 만드는 사례가 속출. 모델 성능이 급격히 좋아지면서 코딩 분야가 가장 먼저 변하고 있음. 일반 지식 노동자 (비테크 기업 포함)에게는 아직 초기 단계. AI는 질문 답변·정보 검색 정도의 \u0026lsquo;도우미\u0026rsquo; 역할에 그치고, 대규모 자동화·실제 업무 생산은 미미함. 그러나 현재 모델만으로도 화이트칼라 업무의 상당 부분을 바꿀 수 있고, 앞으로 2년 내 각 분야 전문가를 능가할 가능성이 매우 높음. 가장 큰 장벽 = Context Gap (맥락 부족)\n에이전트가 제대로 일하려면 조직의 \u0026lsquo;집단 지식\u0026rsquo;이 AI에게 읽기 쉬운 형태로 제공되어야 하는데, 대부분 기업은 다음과 같은 문제로 어려움을 겪음:\n","content":"AI 에이전트의 미래는 이미 와 있지만, 아직 균등하게 퍼지지 않았다 (William Gibson 인용).\n테크 업계에서는 코딩 에이전트가 폭발적으로 성장 중. 긴 작업을 처리하고, 제품 전체를 에이전트로 만드는 사례가 속출. 모델 성능이 급격히 좋아지면서 코딩 분야가 가장 먼저 변하고 있음. 일반 지식 노동자 (비테크 기업 포함)에게는 아직 초기 단계. AI는 질문 답변·정보 검색 정도의 \u0026lsquo;도우미\u0026rsquo; 역할에 그치고, 대규모 자동화·실제 업무 생산은 미미함. 그러나 현재 모델만으로도 화이트칼라 업무의 상당 부분을 바꿀 수 있고, 앞으로 2년 내 각 분야 전문가를 능가할 가능성이 매우 높음. 가장 큰 장벽 = Context Gap (맥락 부족)\n에이전트가 제대로 일하려면 조직의 \u0026lsquo;집단 지식\u0026rsquo;이 AI에게 읽기 쉬운 형태로 제공되어야 하는데, 대부분 기업은 다음과 같은 문제로 어려움을 겪음:\n데이터가 파편화·레거시 시스템에 산재 (클라우드 전환이 아직 안 된 경우 많음) 권한·접근 제어가 복잡 (사람마다 다른 정보 접근 권한 → 에이전트에게는 더 어렵게 작용) 기술 표준이 빠르게 바뀜 (RAG, MCP, CLI 등 아키텍처가 18개월마다 바뀜) 결과적으로 코딩처럼 \u0026ldquo;코드베이스 안에 모든 맥락이 들어있는\u0026rdquo; 경우와 달리, 일반 지식 노동에서는 에이전트가 제대로 움직이기 힘듦.\n앞으로의 거대한 기회\n기존 플랫폼 (Box 같은 콘텐츠·워크플로우 플랫폼)이 기업 데이터와 에이전트를 안전하게 연결하는 역할 새로운 수직 솔루션 (특정 산업·업무 전용 에이전트 워크플로우) 전문 서비스·컨설팅 (FDE 트렌드): 기업 내부 워크플로우를 분석하고, 데이터를 AI 친화적으로 재구성해주는 서비스 → 수요 폭발 예상 시스템 통합자(SI)·컨설팅 회사와 기업 내부의 \u0026lsquo;에이전트 전문가\u0026rsquo; 역할 부상 비기술자도 에이전트를 쉽게 관리할 수 있는 사용자 경험(UX)이 승부처 마지막으로\n클라우드처럼 \u0026ldquo;미래는 이미 왔다\u0026quot;고 모두가 알았던 기술도 실제 시장에 완전히 퍼지는 데 10년 이상 걸렸다. AI 에이전트도 마찬가지. 기술은 빠르게 진화하지만, 조직의 데이터 정리·워크플로우 재설계·변화 관리·거버넌스는 시간이 걸린다.\n그래서 지금이 오히려 가장 큰 기회라는 게 Levie의 핵심 메시지입니다.\n전체적으로 \u0026ldquo;AI 능력은 이미 충분하지만, 기업 현실(맥락·프로세스)과 연결하는 게 관건\u0026quot;이라는 통찰을 담은 긴 에세이입니다.\n원문: The Future of AI Agents Is Already Here, Just Not Evenly Distributed\n","wordCount":283,"tags":["AI","에이전트","자동화","기업","컨텍스트","MCP","RAG"],"categories":["AI"],"frameworks":["First Principles"],"mental_models":["Pareto Principle"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["코딩 에이전트는 폭발적 성장 중이나 일반 지식 노동에는 Context Gap이 가장 큰 장벽","기업 데이터가 파편화·레거시에 산재하고 권한 제어가 복잡해 에이전트 도입 지체","5가지 기회: 기존 플랫폼 연결, 수직 솔루션, FDE 컨설팅, SI·에이전트 전문가, 비기술자 UX","클라우드 전환과 유사하게 10년 이상 걸릴 기술이지만 지금이 가장 큰 기회"],"related":["posts/components-of-a-coding-agent","posts/rl-environments-for-llm-agents","posts/agentic-engine-optimization"]},{"title":"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-29T11:10:51+09:00","lastmod":"2026-03-29T11:10:51+09:00","description":"AI 모델이 합성 데이터로 훈련될 때 발생하는 모델 붕괴가 이미 진행 중이며, 업계가 규모 확대 전략만으로 문제를 해결하려 한다고 비판합니다.","summary":"출처: https://cacm.acm.org/blogcacm/model-collapse-is-already-happening-we-just-pretend-it-isnt/\n핵심 주장 AI 모델이 이전 모델의 출력(합성 데이터) 으로 훈련될 때 발생하는 모델 붕괴(model collapse) 가 이미 진행 중이며, AI 업계가 이를 인정하지 않고 \u0026ldquo;더 큰 모델, 더 많은 데이터, 더 많은 컴퓨트\u0026quot;라는 규모 확대 전략으로만 문제를 해결하려 한다고 비판합니다.\n모델 붕괴(Model Collapse)란? AI 모델이 자신의 이전 버전(또는 다른 AI)이 생성한 합성 텍스트/데이터로 반복 학습할 때 발생하는 현상입니다.\n원본 데이터에 있던 희귀하고 독특하며 놀라운 패턴 (분포의 꼬리 부분, long tail)이 점차 사라짐 모델 출력이 점점 평평하고 제네릭(generic) 해지며, 다양성이 급격히 줄어듦 결국 통계적 평균 으로 수렴하면서 현실성과 정보 밀도가 낮아짐 모델은 덜 유용한 내용을 더 자신 있게 출력하게 되는 위험한 상황 발생 저자는 이를 \u0026ldquo;포토카피를 반복 복사하는 것\u0026quot;에 비유합니다. 처음에는 괜찮아 보이지만, 몇 세대가 지나면 세부사항이 모두 사라져버립니다.\n","content":"출처: https://cacm.acm.org/blogcacm/model-collapse-is-already-happening-we-just-pretend-it-isnt/\n핵심 주장 AI 모델이 이전 모델의 출력(합성 데이터) 으로 훈련될 때 발생하는 모델 붕괴(model collapse) 가 이미 진행 중이며, AI 업계가 이를 인정하지 않고 \u0026ldquo;더 큰 모델, 더 많은 데이터, 더 많은 컴퓨트\u0026quot;라는 규모 확대 전략으로만 문제를 해결하려 한다고 비판합니다.\n모델 붕괴(Model Collapse)란? AI 모델이 자신의 이전 버전(또는 다른 AI)이 생성한 합성 텍스트/데이터로 반복 학습할 때 발생하는 현상입니다.\n원본 데이터에 있던 희귀하고 독특하며 놀라운 패턴 (분포의 꼬리 부분, long tail)이 점차 사라짐 모델 출력이 점점 평평하고 제네릭(generic) 해지며, 다양성이 급격히 줄어듦 결국 통계적 평균 으로 수렴하면서 현실성과 정보 밀도가 낮아짐 모델은 덜 유용한 내용을 더 자신 있게 출력하게 되는 위험한 상황 발생 저자는 이를 \u0026ldquo;포토카피를 반복 복사하는 것\u0026quot;에 비유합니다. 처음에는 괜찮아 보이지만, 몇 세대가 지나면 세부사항이 모두 사라져버립니다.\n이미 일어나고 있다는 증거 웹 전체 콘텐츠의 50% 이상 이 이미 AI 생성 콘텐츠로 추정 ChatGPT 출시 직후 Stack Overflow에서 AI 생성 답변이 폭증하고, 콘텐츠 농장들이 합성 출력으로 대체 인터넷이 점점 자기 자신의 꼬리를 먹는 뱀(ouroboros) 처럼 변질되고 있음 대기업의 70%가 여전히 AI 투자 확대를 계획 중 → 문제 가속화 왜 업계가 외면하나? 규모 확대(scaling) 신화 에 빠져 있음: 더 많은 데이터와 파라미터로 모든 문제를 해결할 수 있다고 믿음 벤치마크는 주로 좁은 작업 성능만 측정할 뿐, 출력의 다양성·풍부함·현실성 은 거의 평가하지 않음 데이터 프로비넌스(provenance) , 즉 \u0026ldquo;이 데이터가 어디서 왔고, AI를 몇 번 거쳤는가\u0026quot;를 추적하는 인프라 구축은 어렵고 덜 매력적임 함의와 결론 저자는 \u0026ldquo;기초가 썩으면 건물이 아무리 높아도 소용없다\u0026quot;고 지적합니다. 저하된 데이터셋에 컴퓨트를 더 쏟아부으면 문제를 해결하지 못하고 오히려 증폭 시킬 뿐입니다.\n필요한 해결책 :\n데이터 출처를 철저히 추적하는 데이터 프로비넌스 인프라 구축 인간 생성 콘텐츠와 AI 생성 콘텐츠를 구분할 수 있는 체계 마련 규모 확대 환상을 버리고, 데이터 품질 기반으로 돌아가기 결론적으로, 모델 붕괴는 먼 미래의 가설이 아니라 이미 진행 중인 현실 이며, 이를 계속 외면하면 AI 전체의 신뢰성과 유용성이 점차 떨어질 것이라고 경고합니다.\n원문: Model Collapse Is Already Happening, We Just Pretend It Isn\u0026rsquo;t\n","wordCount":306,"tags":["AI","ModelCollapse","합성데이터","데이터품질","LLM"],"categories":["기술"],"frameworks":["Verification-first Engineering"],"mental_models":["Borrowed Confidence"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":false,"priority":"high","key_points":["Model Collapse Is Already Happening, We Just Pretend It Isn't의 핵심 문제의식은 \"AI 모델이 합성 데이터로 훈련될 때 발생하는 모델 붕괴가 이미 진행 중이며, 업계가 규모 확대 전략만으로 문제를 해결하려 한다고 비판합니다.\"다","AI, ModelCollapse, 합성데이터 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/ai-hardware-memory-bottleneck-market-map","software/quantization-llm","software/agent-skills-rules-commands"]},{"title":"LLM의 양자화(Quantization): 기초부터 실전까지","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/quantization-llm/","section":"software","date":"2026-03-29T08:53:44+09:00","lastmod":"2026-03-29T08:53:44+09:00","description":"LLM이 너무 커서 일반 PC에서 돌리기 어려운 문제를 해결하는 양자화 기법을 기초부터 설명합니다. 모델 크기를 줄이면서 성능을 최대한 유지하는 방법을 다룹니다.","summary":"출처: https://ngrok.com/blog/quantization\n주요 주제 이 글은 대형 언어 모델(LLM)의 양자화(Quantization) 를 기초부터 자세히 설명합니다. LLM이 너무 커서 일반 PC나 노트북에서 돌리기 어려운 문제를 해결하기 위해, 모델 크기를 줄이면서도 성능을 최대한 유지하는 방법을 다룹니다. 독자가 로컬 환경에서 강력한 LLM을 실제로 실행할 수 있도록 돕는 것이 목적입니다.\n왜 양자화가 중요한가? 최신 LLM은 수십억~수조 개의 매개변수(Weights) 를 가짐 → 예: 80B 모델 = 약 159GB (float32 기준) 1T(조) 매개변수 모델은 2TB RAM 이 필요해 단일 머신에서 거의 불가능 양자화로 모델을 4배 작게 , 최대 2배 빠르게 만들 수 있음 (정확도 손실은 5~10% 수준) 핵심 개념 양자화(Quantization) : 고정밀 부동소수점(float32 등)을 낮은 비트(8비트, 4비트 등)로 변환하는 손실 압축 기법 부동소수점 비교: float32: 32비트 (높은 정확도, 큰 메모리) bfloat16 / float16: 16비트 (메모리 절반) 8비트, 4비트: 더 극단적 압축 LLM 매개변수는 대부분 0 근처 에 몰려 있지만, 소수의 아웃라이어(Outliers) 가 존재해 양자화 시 주의가 필요합니다.\n","content":"출처: https://ngrok.com/blog/quantization\n주요 주제 이 글은 대형 언어 모델(LLM)의 양자화(Quantization) 를 기초부터 자세히 설명합니다. LLM이 너무 커서 일반 PC나 노트북에서 돌리기 어려운 문제를 해결하기 위해, 모델 크기를 줄이면서도 성능을 최대한 유지하는 방법을 다룹니다. 독자가 로컬 환경에서 강력한 LLM을 실제로 실행할 수 있도록 돕는 것이 목적입니다.\n왜 양자화가 중요한가? 최신 LLM은 수십억~수조 개의 매개변수(Weights) 를 가짐 → 예: 80B 모델 = 약 159GB (float32 기준) 1T(조) 매개변수 모델은 2TB RAM 이 필요해 단일 머신에서 거의 불가능 양자화로 모델을 4배 작게 , 최대 2배 빠르게 만들 수 있음 (정확도 손실은 5~10% 수준) 핵심 개념 양자화(Quantization) : 고정밀 부동소수점(float32 등)을 낮은 비트(8비트, 4비트 등)로 변환하는 손실 압축 기법 부동소수점 비교: float32: 32비트 (높은 정확도, 큰 메모리) bfloat16 / float16: 16비트 (메모리 절반) 8비트, 4비트: 더 극단적 압축 LLM 매개변수는 대부분 0 근처 에 몰려 있지만, 소수의 아웃라이어(Outliers) 가 존재해 양자화 시 주의가 필요합니다.\n양자화 방법과 기술 Post-Training Quantization (PTQ) : 학습이 끝난 모델을 나중에 양자화 (글의 주요 내용) Quantization Aware Training (QAT) : 학습 단계부터 양자화를 고려 대칭(Symmetric) vs 비대칭(Asymmetric) 양자화\n대칭: 0을 중심으로 압축 (간단하지만 오차가 큼, 평균 18%) 비대칭: 실제 데이터 범위에 맞춰 zero-point 사용 (오차가 적음, 평균 8.5%) 블록 단위 양자화: 전체가 아닌 32~256개 매개변수씩 블록으로 나눠 양자화 → 아웃라이어 영향 최소화\n주요 형식\nGGUF (llama.cpp): Q8_0, Q4_1, Q4_0, Q2_K 등 AWQ, GPTQ 등도 언급 성능 영향 (벤치마크) 메모리 : 16비트 → 4비트 시 4배 감소 속도 (tokens/sec): MacBook Pro M1 Max: bfloat16 (19.45) → 4비트 비대칭 (43.32, 2.2배 빠름 ) H100 GPU: bfloat16 (106.85) → 4비트 (175.70, 1.6배 빠름 ) 정확도 : 8비트는 거의 손실 없음, 4비트는 5~10% 손실, 2비트는 모델이 거의 붕괴 실전 예시 모델: Qwen3.5-9B llama.cpp를 사용한 양자화 명령어 예시 제공 (BF16 → Q8_0 등) 결론 양자화는 LLM을 실생활에서 실용적으로 쓰기 위한 핵심 기술입니다. 특히 4비트 양자화는 크기·속도·정확도 의 균형이 좋아 가장 많이 사용됩니다. 아웃라이어 처리와 블록 단위 양자화 같은 기법이 품질을 유지하는 데 중요하다는 점을 강조합니다.\n원문: Quantization\n","wordCount":312,"tags":["AI","LLM","양자화","Quantization","로컬AI","llama.cpp"],"categories":["기술"],"frameworks":["Verification-first Engineering","Quantization"],"mental_models":["Borrowed Confidence"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM의 양자화(Quantization): 기초부터 실전까지의 핵심 문제의식은 \"LLM이 너무 커서 일반 PC에서 돌리기 어려운 문제를 해결하는 양자화 기법을 기초부터 설명합니다. 모델 크기를 줄이면서 성능을 최대한 유지하는 방법을 다룹니다.\"다","AI, LLM, 양자화 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/visual-guide-to-quantization","software/ai-hardware-memory-bottleneck-market-map","software/model-collapse"]},{"title":"software 팩토리: AI 코딩 에이전트가 개발 팀을 바꾸는 방식","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/the-software-factory/","section":"software","date":"2026-03-24T18:04:10+09:00","lastmod":"2026-03-24T18:04:10+09:00","description":"AI 코딩 에이전트를 활용해 'software 팩토리'를 구축하면, 개발자는 설계·검토에 집중하고 팀 규모는 줄며 출시 속도는 몇 시간 단위로 빨라진다.","summary":"출처: https://alexop.dev/posts/the-software-factory/\n핵심 메시지 AI 코딩 에이전트(Claude Code 등)를 활용해 \u0026ldquo;software 팩토리\u0026rdquo; 를 구축하면, 개발 팀의 작업 방식이 완전히 바뀐다. 개발자는 더 이상 코드를 직접 많이 작성하지 않고, 설계·아키텍처·검토·의사결정 에 집중한다. 결과적으로 팀 규모는 크게 줄고, 출시 속도는 몇 시간 단위로 빨라진다.\n기존 방식 vs. software 팩토리 기존 방식 (Beer Commerce 예시)\n12명 체크아웃 팀 한 기능(할인 코드 추가) 추가에 10~14일 소요 대부분 시간이 핸드오프(BA → PO → Dev → QA)와 커뮤니케이션에서 사라짐 실제 코딩 시간은 고작 2~3일 software 팩토리 방식\n","content":"출처: https://alexop.dev/posts/the-software-factory/\n핵심 메시지 AI 코딩 에이전트(Claude Code 등)를 활용해 \u0026ldquo;software 팩토리\u0026rdquo; 를 구축하면, 개발 팀의 작업 방식이 완전히 바뀐다. 개발자는 더 이상 코드를 직접 많이 작성하지 않고, 설계·아키텍처·검토·의사결정 에 집중한다. 결과적으로 팀 규모는 크게 줄고, 출시 속도는 몇 시간 단위로 빨라진다.\n기존 방식 vs. software 팩토리 기존 방식 (Beer Commerce 예시)\n12명 체크아웃 팀 한 기능(할인 코드 추가) 추가에 10~14일 소요 대부분 시간이 핸드오프(BA → PO → Dev → QA)와 커뮤니케이션에서 사라짐 실제 코딩 시간은 고작 2~3일 software 팩토리 방식\n비즈니스 요청 → 스펙 작성 → AI 에이전트가 프론트/백엔드/테스트를 병렬 로 자동 생성 인간 \u0026ldquo;빌더\u0026quot;는 PR만 검토 → 당일 또는 몇 시간 만에 프로덕션 배포 Stripe Minions 사례: Slack 메시지 하나로 1,300+ PR/주 자동 생성 주요 개념 software 팩토리 비유 AI 에이전트 = 공장 노동자(자동으로 코드 작성·버그 수정) 인간 = 공장 설계자 + 품질 관리자\nSkills (스킬) 에이전트를 전문화된 노동자로 만드는 핵심. 예: 클라우드 디버깅 스킬, DB 마이그레이션 스킬, Figma → 코드 변환 스킬, 보안 스킬 등. 스킬을 잘 만드는 사람이 가장 큰 경쟁 우위 를 가진다.\n팀 구조의 변화 12명 전문가 팀 → 5명 이하의 \u0026ldquo;빌더\u0026rdquo; 팀 으로 축소 모두가 빌더가 됨 (디자이너도 코드 기여, PM도 디버깅) 비엔지니어도 60% 이상 AI를 통해 코드에 기여 가능\n자기 개선 팩토리 (Self-improving Factory) 에이전트가 사용자 피드백, 오류 로그, A/B 테스트 결과를 분석해 자동으로 백로그를 생성하고 개선한다. 인간은 중요한 결정만 하고, 실행은 에이전트가 맡음.\n저자의 결론 지금 당장 Claude Code 같은 도구로 software 팩토리 를 구축할 수 있다. \u0026ldquo;팩토리가 곧 제품\u0026quot;이다. 좋은 팩토리를 가진 팀이 결국 최고의 제품을 가장 빠르게 출시한다. 엔지니어의 미래 역할 = 팩토리 빌더 (보일러플레이트 코딩에서 벗어나 아키텍처와 판단에 집중) 경쟁자는 이미 움직이고 있다. 빨리 시작하는 팀이 압도적 우위를 점할 것이다. 한마디로 요약하면: \u0026ldquo;AI 에이전트로 공장을 만들어라. 그러면 팀은 작아지고, 속도는 폭발적으로 빨라지며, 모두가 진짜 중요한 일에만 집중하게 된다.\u0026rdquo;\n원문: The Software Factory\n","wordCount":294,"tags":["AI","software팩토리","코딩에이전트","개발생산성","팀빌딩"],"categories":["기술"],"frameworks":["Agent-native Development","Verification-first Engineering","Operational Excellence"],"mental_models":["Feedback Loop","Borrowed Confidence"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["software 팩토리: AI 코딩 에이전트가 개발 팀을 바꾸는 방식의 핵심 문제의식은 \"AI 코딩 에이전트를 활용해 'software 팩토리'를 구축하면, 개발자는 설계·검토에 집중하고 팀 규모는 줄며 출시 속도는 몇 시간 단위로 빨라진다.\"다","AI, software팩토리, 코딩에이전트 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/large-software-teams-ai-age","software/agent-psychosis","software/agent-skills-rules-commands"]},{"title":"AI 시대에 대규모 software 팀의 역할","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/large-software-teams-ai-age/","section":"software","date":"2026-03-24T18:03:21+09:00","lastmod":"2026-03-24T18:03:21+09:00","description":"AI가 개발 생산성을 극적으로 높였지만, 대규모 팀이 완전히 사라지는 것은 아니다. 최소 팀 규모는 줄어들고, 팀을 구성하는 이유가 달라지고 있다.","summary":"출처: https://andresmax.com/large-software-teams-ai-age/\n주요 논제 AI 시대에 대규모 software 팀의 역할이 크게 바뀌고 있다. AI가 개발 생산성을 극적으로 높여 5인 팀 이 2016년의 50인 팀 수준의 출력을 낼 수 있게 되었지만, 대규모 팀이 완전히 사라지는 것은 아니다. 대신 최소 팀 규모는 줄어들고 , 팀을 구성하는 이유(제품 사고, 시스템 복잡성, 조직적 필요)가 달라졌다.\n1. 대규모 팀의 기존 문제점과 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배) 새로운 프레임워크 학습: 며칠 → 몇 시간 (3~5배) 테스트 작성, 문서화, 코드 리뷰 준비 등도 2~4배 빨라짐. 그러나 AI가 해결하지 못하는 영역이 여전히 존재:\n","content":"출처: https://andresmax.com/large-software-teams-ai-age/\n주요 논제 AI 시대에 대규모 software 팀의 역할이 크게 바뀌고 있다. AI가 개발 생산성을 극적으로 높여 5인 팀 이 2016년의 50인 팀 수준의 출력을 낼 수 있게 되었지만, 대규모 팀이 완전히 사라지는 것은 아니다. 대신 최소 팀 규모는 줄어들고 , 팀을 구성하는 이유(제품 사고, 시스템 복잡성, 조직적 필요)가 달라졌다.\n1. 대규모 팀의 기존 문제점과 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배) 새로운 프레임워크 학습: 며칠 → 몇 시간 (3~5배) 테스트 작성, 문서화, 코드 리뷰 준비 등도 2~4배 빨라짐. 그러나 AI가 해결하지 못하는 영역이 여전히 존재:\n제품 사고 : 무엇을 만들어야 할지 결정, 사용자 이해, 트레이드오프, 시장 예측 (AI가 거의 못 함 → 더 중요해짐) 시스템 복잡성 : 분산 시스템, 레거시 통합, 대규모 데이터 마이그레이션, 규제 준수 등 (비선형적으로 증가) 조직적 필요 : 24시간 지원, 지식 중복, 경력 개발, 전문화 등 2. 추천 팀 구조: 하이브리드 모델 코어 팀 (3~5명) : 기술 리더/아키텍트 + 제품 리더/창업자 + 시니어 풀스택 엔지니어 (주요 결정과 시스템 소유) 필요 시 확장 팀 을 추가로 붙이는 형태 팀 규모 결정 기준: 시스템이 단순하고 속도가 중요하면 → 소규모 복잡도/운영 부담/규제가 높으면 → 대규모 단계별 추천 규모 :\nPre-Seed/Validation: 1~2명 (창업자 + AI 최대 활용) Seed/Early PMF: 3~5명 Series A/Growth: 8~15명 (소규모 포드) Series B+/Scale: 20~50명 이상 (전문화) 3. 소규모 AI 팀의 강점 vs 대규모 팀의 강점 소규모 팀이 유리한 경우 :\n초기 제품 검증 (빠른 결정, 피벗 용이) 단일 목적 SaaS, 개발자 도구, 니치 앱, 내부 도구 등 솔로 창업자 + AI로도 풀스택 웹/모바일 앱, 결제 서비스 등을 만들 수 있음 대규모 팀이 여전히 필요한 경우 :\n초대형 플랫폼 (고가용성, AWS/Stripe 규모) 여러 제품 라인 운영 규제 산업 (금융, 헬스케어 등) 엔터프라이즈 판매 및 대규모 고객 지원 새로운 연구/혁신 영역 결론 AI는 최소 팀 규모를 크게 압축 하지만, 복잡한 문제에서는 대규모 팀의 필요성을 여전히 유지한다. 승리하는 회사는 \u0026ldquo;가장 큰 팀\u0026quot;이나 \u0026ldquo;가장 화려한 AI\u0026quot;를 가진 회사가 아니라, 문제에 맞는 적절한 규모의 팀 + 효과적인 AI 활용 을 하는 회사다.\n팀 규모는 목표가 아니라 도구일 뿐이라는 점을 강조하며 마무리됩니다.\n전체적으로 실무자 관점에서 매우 현실적이고 균형 잡힌 인사이트를 주는 좋은 글입니다. AI로 인해 \u0026ldquo;작은 팀이 강력해지는 시대\u0026quot;가 왔지만, 모든 걸 소규모로 해결할 수는 없다는 메시지가 핵심이에요.\n원문: Large Software Teams in the AI Age\n","wordCount":405,"tags":["AI","software팀","팀빌딩","스타트업","개발생산성"],"categories":["기술"],"frameworks":["Systems Thinking","Verification-first Engineering","Operational Excellence"],"mental_models":["Pareto Principle"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 시대에 대규모 software 팀의 역할의 핵심 문제의식은 \"AI가 개발 생산성을 극적으로 높였지만, 대규모 팀이 완전히 사라지는 것은 아니다. 최소 팀 규모는 줄어들고, 팀을 구성하는 이유가 달라지고 있다.\"다","AI, software팀, 팀빌딩 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/the-software-factory","software/agent-skills-rules-commands","software/ai-assisted-engineering-15-engineers"]},{"title":"15명의 엔지니어가 말하는 AI 보조 엔지니어링 실전 가이드","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/ai-assisted-engineering-15-engineers/","section":"software","date":"2026-03-24T16:45:14+09:00","lastmod":"2026-03-24T16:45:14+09:00","description":"15명의 실전 엔지니어·엔지니어링 리더들이 실제로 사용 중인 AI 보조 엔지니어링 경험을 정리한 글이다.","summary":"이 뉴스레터는 15명의 실전 엔지니어·엔지니어링 리더 들이 실제로 사용 중인 AI 보조 엔지니어링(AI-Assisted Engineering) 경험을 모아 정리한 글이다. 스타트업부터 대기업까지 다양한 규모와 배경의 사람들이 공유한다.\n원문: How to Do AI-Assisted Engineering\n핵심 메시지 AI는 생산성을 크게 높여 주지만, 단순히 \u0026ldquo;AI한테 코드 짜라고 시키면 끝\u0026quot;이 아니다. 엄격한 설계 + AI 구현 + 공격적인 리뷰 + 반복 이 핵심 공식이며, 인간의 판단과 감독 을 절대 빼놓을 수 없다는 점을 모든 기고자가 강조한다.\n주요 워크플로우 패턴 (공통점) 아이데이션 / 설계 단계 (가장 중요)\n","content":"이 뉴스레터는 15명의 실전 엔지니어·엔지니어링 리더 들이 실제로 사용 중인 AI 보조 엔지니어링(AI-Assisted Engineering) 경험을 모아 정리한 글이다. 스타트업부터 대기업까지 다양한 규모와 배경의 사람들이 공유한다.\n원문: How to Do AI-Assisted Engineering\n핵심 메시지 AI는 생산성을 크게 높여 주지만, 단순히 \u0026ldquo;AI한테 코드 짜라고 시키면 끝\u0026quot;이 아니다. 엄격한 설계 + AI 구현 + 공격적인 리뷰 + 반복 이 핵심 공식이며, 인간의 판단과 감독 을 절대 빼놓을 수 없다는 점을 모든 기고자가 강조한다.\n주요 워크플로우 패턴 (공통점) 아이데이션 / 설계 단계 (가장 중요)\n요구사항을 명확히 하고, 아키텍처·스펙을 상세하게 작성 (여기에 시간의 30~50% 투자) CLAUDE.md, AGENTS.md 같은 파일로 코딩 표준·프로젝트 구조 미리 정의 AI에게 반복적으로 질문하며 가정 공격(assumption challenging)하고 스펙 다듬기 빌딩 단계\n잘 정리된 스펙 → AI에게 코드 생성 위임 테스트는 동시에 또는 별도 에이전트로 작성 작은 단위(slice)로 나누어 작업하거나 병렬 에이전트 활용 리뷰 단계\nAI 1차 리뷰 (코드 리뷰, 보안·성능·테스트 관점) 인간 최종 리뷰 (특히 논리 오류, 기술 부채, 비즈니스 판단) 여러 에이전트에게 다른 관점으로 리뷰시키는 경우도 많음 머징·배포·모니터링\nAI가 PR 초안·변경 설명·테스트 계획 작성 인간이 최종 승인 CI/CD와 연동해 야간 스캔, 버그 자동 티켓 생성 등 자동화 자주 언급된 도구 Claude Code / Claude Opus (대부분 1순위) Cursor OpenAI Codex Windsurf, CodeRabbit, Bito 등 리뷰 도구 MCP (Figma, Slack 등 외부 도구 연동) GitHub Actions, Langfuse 등 실전 팁 \u0026amp; 교훈 AI는 포스 멀티플라이어 이지, 노동력을 줄여 주는 마법이 아님 (오히려 작업량이 늘어날 수도 있음) 첫 번째 AI 출력 그대로 쓰면 기술 부채가 빠르게 쌓임 컨텍스트 관리와 프롬프트 구조화가 매우 중요 설계 문서가 빈약하면 AI 성능이 급락 새 기술/프레임워크 학습 속도가 비약적으로 빨라짐 Figma → 코드 변환, 파이프라인 리팩토링, 대형 코드베이스 탐색 등에서 특히 강력 결론 및 시사점 한 줄 결론: AI-Assisted Engineering의 성패는 구조화된 프로세스와 인간 감독을 얼마나 갖추느냐에 달려 있다.\n\u0026ldquo;설계에 절반 시간을 쓰고, 나머지는 AI가 빠르게 구현하게 하라\u0026quot;는 Owain Lewis의 조언이 이 글의 핵심을 잘 보여 준다. 실무자들의 생생한 노하우가 가득한 실용 가이드로, AI를 본격적으로 엔지니어링에 도입하려는 개발자나 팀 리더에게 참고할 만하다.\n관련 포스트 에이전틱 코딩의 80% 문제 바이브 코딩과 시스템 설계: AI 시대의 함정 ","wordCount":327,"tags":["AI","엔지니어링","생산성","코드리뷰","워크플로우"],"categories":["software"],"frameworks":["Second-order thinking"],"mental_models":["Pareto Principle"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI 보조 엔지니어링의 핵심 공식은 엄격한 설계 + AI 구현 + 공격적 리뷰 + 반복이다.","설계·스펙에 시간의 30~50%를 쓰고, 구현은 AI에 위임하되 인간이 최종 판단한다.","AI는 포스 멀티플라이어이지 노동력을 줄이는 마법이 아니며, 컨텍스트·프롬프트 구조화가 성능을 좌우한다."],"related":["software/the-80-problem-in-agentic-coding","software/vibe-coding-system-design-trap"]},{"title":"분산된 지능에서 검증 가능한 책임으로: Vint Cerf의 인터넷 아키텍처 제안","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/from-distributed-intelligence-to-verifiable-responsibility/","section":"posts","date":"2026-03-21T21:34:32+09:00","lastmod":"2026-03-21T21:34:32+09:00","description":"AI가 분산화되는 속도가 신뢰/책임 메커니즘보다 훨씬 빠른 현재, '검증 가능한 책임'을 인터넷 아키텍처 수준에서 설계해야 한다는 Vint Cerf의 논지를 정리합니다.","summary":"이 글은 2026년 3월 18일경 BLOG@CACM에 게시된 것으로, 저자는 Mallik Tatipamula , David Attermann , 그리고 인터넷의 아버지로 불리는 Vinton G. Cerf (Vint Cerf)입니다.\n핵심 논지 AI와 지능이 빠르게 분산화(distributed)되고 있는 현재 상황에서, 신뢰(trust) 와 책임(responsibility) 는 여전히 중앙화된 전통적 모델(특정 조직·인간 감독)에 의존하고 있어 심각한 불일치가 발생하고 있다. → 지능 분산 속도 \u0026raquo; 신뢰/책임 메커니즘 발전 속도 따라서 \u0026ldquo;검증 가능한 책임(verifiable responsibility)\u0026rdquo; 또는 \u0026ldquo;검증 가능한 분산 신뢰(verifiable distributed trust)\u0026rdquo; 를 인터넷 아키텍처 수준에서 근본적으로 설계해야 한다는 주장을 펼칩니다.\n","content":"이 글은 2026년 3월 18일경 BLOG@CACM에 게시된 것으로, 저자는 Mallik Tatipamula , David Attermann , 그리고 인터넷의 아버지로 불리는 Vinton G. Cerf (Vint Cerf)입니다.\n핵심 논지 AI와 지능이 빠르게 분산화(distributed)되고 있는 현재 상황에서, 신뢰(trust) 와 책임(responsibility) 는 여전히 중앙화된 전통적 모델(특정 조직·인간 감독)에 의존하고 있어 심각한 불일치가 발생하고 있다. → 지능 분산 속도 \u0026raquo; 신뢰/책임 메커니즘 발전 속도 따라서 \u0026ldquo;검증 가능한 책임(verifiable responsibility)\u0026rdquo; 또는 \u0026ldquo;검증 가능한 분산 신뢰(verifiable distributed trust)\u0026rdquo; 를 인터넷 아키텍처 수준에서 근본적으로 설계해야 한다는 주장을 펼칩니다.\n주요 내용 구조 문제 제기: 지능 분산(The Problem: Intelligence Is Distributing Faster Than Trust)\nAI 에이전트, 분산 추론, 엣지 AI, 자율 시스템 등이 폭발적으로 늘어나면서 결정 주체가 명확하지 않음 기존 디지털 신뢰 모델은 \u0026ldquo;누가 책임자인가?\u0026ldquo;를 인간·조직 중심으로 가정 → AI 네이티브 환경에서는 맞지 않음 인터넷을 모델로 삼아야 할 이유\n인터넷 자체가 분산형 신뢰를 성공적으로 구현한 사례 그러나 현재 인터넷도 여전히 신뢰의 최종 앵커(anchor)는 인간/조직에 의존 제안 방향: Accountability Substrate (책임 기반층)\nAI 네이티브 인터넷을 완성하기 위해 \u0026ldquo;검증 가능한 책임\u0026quot;을 아키텍처 차원에서 내장 해야 함 단순한 투명성·설명가능성(XAI)을 넘어, 수학적·암호학적·프로토콜 수준에서 검증 가능 한 책임 체계 필요 분산 환경에서도 \u0026ldquo;누가 어떤 결정을 내렸고, 그 결정이 규칙을 따랐는가\u0026quot;를 객관적으로 확인할 수 있는 구조 결론 및 함의 Verifiable distributed trust는 철학적 선호가 아니라 아키텍처적 필수 조건 AI가 인터넷처럼 완전히 분산화된 미래를 맞이하려면, 책임의 기초 층(accountability substrate) 을 지금 설계하지 않으면 안 된다는 강한 경고 기존의 중앙 집중형 거버넌스나 사후 규제로는 따라갈 수 없으며, 기술적·시스템적 해결 이 우선 과제라는 점 강조 간단히 말해, \u0026ldquo;AI가 어디서나 돌아다니며 결정을 내리는 시대에, 누가 무슨 책임을 지는지 수학적으로 증명 가능하게 만들어야 인터넷의 다음 단계로 넘어갈 수 있다\u0026quot;는 내용의 상당히 미래지향적이고 구조적인 제안 글입니다. Vint Cerf가 공동 저자라는 점에서 무게감이 더해집니다.\n원문: From Distributed Intelligence to Verifiable Responsibility\n","wordCount":277,"tags":["AI","분산시스템","인터넷아키텍처","신뢰","책임","VintCerf"],"categories":["기술"],"frameworks":["First Principles"],"mental_models":["Borrowed Confidence"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":false,"priority":"high","key_points":["분산된 지능에서 검증 가능한 책임으로: Vint Cerf의 인터넷 아키텍처 제안의 핵심 문제의식은 \"AI가 분산화되는 속도가 신뢰/책임 메커니즘보다 훨씬 빠른 현재, '검증 가능한 책임'을 인터넷 아키텍처 수준에서 설계해야 한다는 Vint Cerf의 논지를 정리합니다.\"다","AI, 분산시스템, 인터넷아키텍처 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/agentic-software-engineering","posts/anatomy-of-an-agent-harness","posts/components-of-a-coding-agent"]},{"title":"새로운 AI 시대, 진짜 희소 자원은 연구자","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/ai-era-researchers-not-engineers/","section":"software","date":"2026-03-11T18:09:50+09:00","lastmod":"2026-03-11T18:09:50+09:00","description":"AI가 공학적 실행을 빠르게 대체하는 시대일수록, 무엇을 시도하고 무엇을 포기할지 판단하는 연구자의 'taste'가 핵심 자산이 된다는 시사점을 정리","summary":"새로운 AI 시대의 가장 중요한 인재는 엔지니어가 아니라 연구자 입니다.\n누구나 AI로 \u0026ldquo;무료로 만들 수 있는\u0026rdquo; 시대가 되면, 진짜 차별점은 \u0026ldquo;무엇을 만들 가치가 있는가? 과연 만들 수 있는가?\u0026rdquo; 를 판단하는 능력이다. 연구자는 해결책이 없을 수도 있는 문제를 붙잡고, \u0026ldquo;이 베팅에 목숨 걸 만한가?\u0026rdquo; 를 결정하는 사람들입니다. 시장도 이미 이 사실을 반영하고 있다\n퀀트 펌들은 포트폴리오 한 번 관리해 본 적 없는 학부생에게 $600k 를 준다. AI 랩(Meta Superintelligence Labs 등)은 연구자 한 명에게 4년간 $3억 까지 제안한다.\n→ 한 번의 학습 비용이 수억 달러인데, 데이터 효율을 1~2%만 올려도 그 연구자가 수십 배로 돈을 벌어줍니다. 왜 연구는 자동화하기 어려운가?\n","content":"새로운 AI 시대의 가장 중요한 인재는 엔지니어가 아니라 연구자 입니다.\n누구나 AI로 \u0026ldquo;무료로 만들 수 있는\u0026rdquo; 시대가 되면, 진짜 차별점은 \u0026ldquo;무엇을 만들 가치가 있는가? 과연 만들 수 있는가?\u0026rdquo; 를 판단하는 능력이다. 연구자는 해결책이 없을 수도 있는 문제를 붙잡고, \u0026ldquo;이 베팅에 목숨 걸 만한가?\u0026rdquo; 를 결정하는 사람들입니다. 시장도 이미 이 사실을 반영하고 있다\n퀀트 펌들은 포트폴리오 한 번 관리해 본 적 없는 학부생에게 $600k 를 준다. AI 랩(Meta Superintelligence Labs 등)은 연구자 한 명에게 4년간 $3억 까지 제안한다.\n→ 한 번의 학습 비용이 수억 달러인데, 데이터 효율을 1~2%만 올려도 그 연구자가 수십 배로 돈을 벌어줍니다. 왜 연구는 자동화하기 어려운가?\n엔지니어링은 \u0026ldquo;정답이 이미 존재한다. 그냥 찾아서 구현하면 된다.\u0026rdquo; 입니다. 연구는 \u0026ldquo;정답이 있는지조차 모른다\u0026rdquo; (halting problem).\n1년을 매달려도 \u0026ldquo;답은 No\u0026rdquo; 일 수 있습니다. 연구자를 차별화하는 핵심 능력 = Taste (문제 선택 감각) 입니다.\n수백만~수억 달러짜리 \u0026ldquo;편향된 동전\u0026rdquo; 이 수조 개 있는 방에서,\n어느 20개만 뒤집을지 미리 아는 사람. 지능은 기본 스펙이고, 진짜 가치는 \u0026ldquo;커리어를 걸고 계속 실패할 각오\u0026rdquo; + 보상 구조(성과에 따라 돈/승진)입니다. Taste는 도메인이 바뀌어도 옮겨갑니다 (물리학자 → 퀀트 → AI, 생물학자 → 신약 등). AI 에이전트는 아직 한계가 있습니다.\n코딩 에이전트는 테스트·벤치마크가 명확해서 빠르게 발전 중입니다. 하지만 연구 taste는 실패 사례·내부 판단이 공개되지 않아 학습 데이터가 없습니다. Karpathy의 autoresearch처럼 밤새 126번 실험을 돌려도, 결국 하이퍼파라미터 스윕 수준에 머무릅니다. 결론 지금 당장은 \u0026ldquo;무엇을 시도하고, 무엇을 과감히 포기할지\u0026rdquo; 결정하는 사람이 병목입니다.\n이 격차는 빠르게 좁혀지겠지만, 아직은 연구자의 판단력이 AI 시대의 진짜 희소 자원입니다.\n(공동 집필: Amy Tam @ Bloomberg Beta + E Chi @ Quadrillion, Trenton Chang 기여)\n원문 조회수 33만+, 좋아요 1.6k+ (2026.3.9 게시)\n출처: https://x.com/amytam01/article/2031072399731675269\n","wordCount":254,"tags":["ai","research","engineering","career","decision-making"],"categories":["ai"],"frameworks":["Total Cost of Ownership","Agent-native Development","Verification-first Engineering"],"mental_models":["Bottleneck Analysis","Hidden Costs","Trade-off Analysis"],"philosophy_type":"","schema_type":"Article","actionable":false,"priority":"high","key_points":["새로운 AI 시대, 진짜 희소 자원은 연구자의 핵심 문제의식은 \"AI가 공학적 실행을 빠르게 대체하는 시대일수록, 무엇을 시도하고 무엇을 포기할지 판단하는 연구자의 'taste'가 핵심 자산이 된다는 시사점을 정리\"다","ai, research, engineering 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/modern-engineering-values","software/ai-cheap-exploration-human-judgment","posts/agentic-engine-optimization"]},{"title":"진흙으로 만든 부가티: AI 시대의 엔지니어링 환상","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/illusion-of-building/","section":"software","date":"2026-03-08T16:30:00+09:00","lastmod":"2026-03-08T16:30:00+09:00","description":"AI의 발전으로 누구나 소프트웨어를 쉽게 만드는 것처럼 보이지만, 실제 제품을 구축하는 것과 시스템을 엔지니어링하는 사이에는 거대한 간극이 존재합니다.","summary":"이 글은 AI의 발전으로 누구나 소프트웨어를 쉽게 \u0026lsquo;만드는 것\u0026rsquo;처럼 보이지만, 실제 **\u0026lsquo;제품을 구축하는 것\u0026rsquo;**과 \u0026lsquo;시스템을 엔지니어링하는 것\u0026rsquo; 사이에는 거대한 간극이 존재함을 지적합니다.\n원문/참고 링크: https://uphack.io/blog/post/the-illusion-of-building\n1. 진흙으로 만든 부가티 (The Clay Bugatti) 최근 \u0026ldquo;코딩 경험 없이 앱을 만들었다\u0026rdquo;, \u0026ldquo;주말 만에 스포티파이를 복제했다\u0026quot;는 식의 글들이 넘쳐납니다. 하지만 이는 베트남의 유튜버들이 진흙으로 부가티 모양을 빚어낸 것과 비슷합니다. 겉모습은 똑같지만, 시속 400km로 달려도 안전하게 설계된 실제 부가기의 \u0026lsquo;엔지니어링\u0026rsquo;은 전혀 들어있지 않습니다. 개발의 환상이란, 작동하는 것처럼 보이는 소프트웨어를 만드는 것이 실제로 작동하는 소프트웨어를 엔지니어링하는 것과 같다고 믿는 착각입니다.\n","content":"이 글은 AI의 발전으로 누구나 소프트웨어를 쉽게 \u0026lsquo;만드는 것\u0026rsquo;처럼 보이지만, 실제 **\u0026lsquo;제품을 구축하는 것\u0026rsquo;**과 \u0026lsquo;시스템을 엔지니어링하는 것\u0026rsquo; 사이에는 거대한 간극이 존재함을 지적합니다.\n원문/참고 링크: https://uphack.io/blog/post/the-illusion-of-building\n1. 진흙으로 만든 부가티 (The Clay Bugatti) 최근 \u0026ldquo;코딩 경험 없이 앱을 만들었다\u0026rdquo;, \u0026ldquo;주말 만에 스포티파이를 복제했다\u0026quot;는 식의 글들이 넘쳐납니다. 하지만 이는 베트남의 유튜버들이 진흙으로 부가티 모양을 빚어낸 것과 비슷합니다. 겉모습은 똑같지만, 시속 400km로 달려도 안전하게 설계된 실제 부가기의 \u0026lsquo;엔지니어링\u0026rsquo;은 전혀 들어있지 않습니다. 개발의 환상이란, 작동하는 것처럼 보이는 소프트웨어를 만드는 것이 실제로 작동하는 소프트웨어를 엔지니어링하는 것과 같다고 믿는 착각입니다.\n2. 인터페이스의 오류 (The Interface Fallacy) 구글 검색창은 단순한 입력창과 버튼으로 구성되어 있습니다. 초보자도 겉모습은 며칠 만에 따라 만들 수 있습니다. 하지만 구글에 수만 명의 엔지니어가 필요한 이유는 그 겉모습 때문이 아니라, 보이지 않는 뒷단의 복잡성 때문입니다. 초저지연(Latency), 수십억 개의 쿼리 처리(Scale), 보안, 스팸 대응, 규제 준수, 비용 최적화 등이 진짜 엔지니어링의 영역입니다.\n3. 엔트로피와의 싸움 (Fighting Entropy) 코드를 작성하는 것은 질서를 만드는 일이지만, 소프트웨어 엔지니어링은 \u0026lsquo;엔트로피(무질서)\u0026lsquo;와 싸우는 일입니다. AI가 만든 코드는 완성된 순간 최고의 상태이지만, 그다음 날부터 코드는 부식되기 시작합니다(의존성 변화, 사용자 요구 변화, 보안 취약점 등). 진정한 엔지니어링은 이 무질서로 향하는 시스템을 유지하고 운영하며 살아남게 만드는 과정입니다.\n4. 소프트웨어의 성숙 단계 저자는 소프트웨어가 성숙해지는 단계를 다음과 같이 구분합니다.\n코드(Code): 실행되는 명령 (AI가 매우 잘함) 프로토타입(Prototype): 내 PC에서만 돌아가는 데모 (AI가 며칠 걸릴 일을 몇 분으로 단축) 제품(Product): 실제 사용자의 예외 상황과 에러를 처리하는 가치 있는 도구 서비스(Service): 모니터링, 보안, 성능, 운영이 담보되는 상태 (AI가 관여하기 힘든 영역) 기관(Institution): 신뢰, 브랜드, 규제 대응 등 오랜 시간 축적된 유산 5. 결론: 무엇이 변하고 무엇이 변하지 않는가 바닥(Floor)은 낮아졌다: 단순한 자동화, 내부 대시보드, 개인용 도구는 이제 개발자 없이도 가능합니다. 이는 좋은 현상입니다.\n천장(Ceiling)은 그대로다: 대규모 시스템 설계, 신뢰성, 보안, 판단력은 여전히 어렵고 중요합니다.\n중간(Middle)이 압축된다: \u0026lsquo;스크립트보다는 어렵고 시스템보다는 쉬운\u0026rsquo; 단순 앱 개발 영역이 가장 큰 타격을 입을 것입니다.\n핵심 메시지: AI는 구현 비용을 낮춰주지만, 결과(신뢰성, 보안, 비즈니스 가치 등)의 비용을 낮춰주지는 않습니다. 겉모양을 만드는 사람은 많아지겠지만, 그것을 **\u0026lsquo;실제(Real)\u0026rsquo;**로 만들 수 있는 엔지니어의 가치는 더욱 높아질 것입니다.\n","wordCount":319,"tags":["ai","software-engineering","philosophy","technology"],"categories":[],"frameworks":["First Principles"],"mental_models":["Entropy"],"philosophy_type":"epistemology","schema_type":"Article","actionable":true,"priority":"high","key_points":["진흙으로 만든 부가티: AI 시대의 엔지니어링 환상의 핵심 문제의식은 \"AI의 발전으로 누구나 소프트웨어를 쉽게 만드는 것처럼 보이지만, 실제 제품을 구축하는 것과 시스템을 엔지니어링하는 사이에는 거대한 간극이 존재합니다.\"다","ai, software-engineering, philosophy 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/vibe-coding-system-design-trap","software/what-is-an-engineer","posts/agentic-engineering-management"]},{"title":"오픈 소스 LLM 아키텍처의 구조와 전략","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/open-source-llm-architecture/","section":"software","date":"2026-03-04T13:21:13+09:00","lastmod":"2026-03-04T13:21:13+09:00","description":"주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략 분석","summary":"오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 분석합니다.\n출처: https://blog.bytebytego.com/p/the-architecture-behind-open-source\n이 글은 주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 다루고 있습니다.\n주요 내용은 다음과 같습니다.\n1. 핵심 아키텍처: Transformer 대부분의 오픈 소스 LLM은 Transformer 아키텍처를 기반으로 합니다. 하지만 효율성을 높이기 위해 오리지널 구조에서 몇 가지 변형을 가합니다.\nDecoder-only 구조: GPT 시리즈와 마찬가지로 대부분의 오픈 소스 모델(Llama, Mistral 등)은 다음 단어를 예측하는 데 최적화된 디코더 전용 구조를 채택합니다. 2. 주요 최적화 기술 성능과 효율성을 잡기 위해 사용되는 대표적인 기술들입니다.\n","content":"오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 분석합니다.\n출처: https://blog.bytebytego.com/p/the-architecture-behind-open-source\n이 글은 주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략을 다루고 있습니다.\n주요 내용은 다음과 같습니다.\n1. 핵심 아키텍처: Transformer 대부분의 오픈 소스 LLM은 Transformer 아키텍처를 기반으로 합니다. 하지만 효율성을 높이기 위해 오리지널 구조에서 몇 가지 변형을 가합니다.\nDecoder-only 구조: GPT 시리즈와 마찬가지로 대부분의 오픈 소스 모델(Llama, Mistral 등)은 다음 단어를 예측하는 데 최적화된 디코더 전용 구조를 채택합니다. 2. 주요 최적화 기술 성능과 효율성을 잡기 위해 사용되는 대표적인 기술들입니다.\nRoPE (Rotary Positional Embeddings): 토큰의 상대적 위치 정보를 더 잘 파악하게 하여 긴 문맥(Context)을 처리할 때 유리합니다. Llama 시리즈 등에서 표준처럼 사용됩니다. KV Caching \u0026amp; Grouped-Query Attention (GQA): 추론 속도를 높이고 메모리 사용량을 줄이기 위한 기술입니다. 특히 모델이 커질수록 GQA를 통해 멀티 헤드 어텐션의 성능을 유지하면서도 연산 효율을 극대화합니다. SwiGLU 활성화 함수: 기존의 ReLU보다 성능이 뛰어난 활성화 함수를 사용하여 모델의 표현력을 높입니다. 3. 대표적인 모델별 특징 Llama (Meta): 오픈 소스 LLM의 표준 역할을 하며, 견고한 성능과 효율적인 학습 방법론을 제시했습니다. Mistral / Mixtral (Mistral AI): MoE (Mixture of Experts) 아키텍처를 적극 활용합니다. 모든 파라미터를 매번 사용하지 않고 필요한 \u0026lsquo;전문가(Expert)\u0026rsquo; 모델만 활성화하여, 적은 연산량으로 거대 모델의 성능을 냅니다. Falcon: 대규모 데이터 정제와 멀티 쿼리 어텐션(Multi-Query Attention)을 통해 데이터 효율성을 극대화한 사례로 소개됩니다. 4. 공학적 선택 (Engineering Bets) 글은 각 모델이 단순히 크기를 키우는 것이 아니라, \u0026lsquo;어떤 트레이드오프(Trade-off)를 선택했는가\u0026rsquo; 가 중요하다고 강조합니다.\n메모리 대역폭을 줄일 것인가, 연산 정밀도를 높일 것인가? 데이터의 양(Volume)을 늘릴 것인가, 질(Quality)을 높일 것인가? 결론 오픈 소스 LLM 아키텍처의 진화는 \u0026ldquo;제한된 자원에서 어떻게 하면 더 길고 복잡한 문맥을 빠르고 정확하게 처리할 것인가\u0026rdquo; 에 집중되어 있습니다. 이 글은 개발자들이 자신의 프로젝트에 맞는 모델을 선택할 때 이러한 구조적 차이를 이해하는 것이 중요함을 시사합니다.\n","wordCount":281,"tags":["llm","ai","architecture","opensource","transformer"],"categories":[],"frameworks":["Total Cost of Ownership","Context Management"],"mental_models":["Trade-off Analysis"],"philosophy_type":"","schema_type":"TechArticle","actionable":true,"priority":"medium","key_points":["오픈 소스 LLM 아키텍처의 구조와 전략의 핵심 문제의식은 \"주요 오픈 소스 대규모 언어 모델(LLM)들의 아키텍처 구조와 각 모델이 선택한 공학적 전략 분석\"다","llm, ai, architecture 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/agents-cant-choose-structure-flexibility","software/ai-hardware-memory-bottleneck-market-map","software/getting-real-with-llms"]},{"title":"컴파운드 엔지니어링: AI 에이전트 개발의 복리 루프","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/compound-engineering/","section":"software","date":"2026-02-19T17:40:07+09:00","lastmod":"2026-02-19T17:40:07+09:00","description":"Every의 Compound Engineering 가이드를 바탕으로, AI 에이전트 시대의 복리형 개발 루프와 핵심 원칙을 정리합니다.","summary":"출처: https://every.to/guides/compound-engineering\nEvery의 가이드 \u0026ldquo;Compound Engineering\u0026rdquo; 은 AI 에이전트를 활용한 새로운 소프트웨어 개발 패러다임을 설명하고 있습니다. 핵심은 \u0026ldquo;전통적인 개발은 코드가 쌓일수록 복잡해져 속도가 느려지지만, 컴파운드 엔지니어링은 할수록 다음 작업이 더 쉬워지고 빨라진다\u0026rdquo; 는 것입니다.\n1. 핵심 철학 (The Philosophy) 복리 효과(Compounding): 모든 단위 작업(코드, 문서, 툴링)이 다음 작업을 더 쉽게 만들어야 합니다. 시스템에 \u0026lsquo;취향\u0026rsquo; 반영: 코드 리뷰 시 매번 수동으로 수정하는 대신, 설정·스키마·자동 검사 도구에 판단 기준을 녹여내어 시스템 자체가 학습하게 합니다. 직접 하기보다 가르치기: 코드를 직접 타이핑하는 시간보다 AI 에이전트에게 더 많은 컨텍스트를 제공하는 데 시간을 투자합니다. 2. 4단계 루프 (The Loop) 컴파운드 엔지니어링은 다음의 반복적인 과정을 통해 완성됩니다.\n","content":"출처: https://every.to/guides/compound-engineering\nEvery의 가이드 \u0026ldquo;Compound Engineering\u0026rdquo; 은 AI 에이전트를 활용한 새로운 소프트웨어 개발 패러다임을 설명하고 있습니다. 핵심은 \u0026ldquo;전통적인 개발은 코드가 쌓일수록 복잡해져 속도가 느려지지만, 컴파운드 엔지니어링은 할수록 다음 작업이 더 쉬워지고 빨라진다\u0026rdquo; 는 것입니다.\n1. 핵심 철학 (The Philosophy) 복리 효과(Compounding): 모든 단위 작업(코드, 문서, 툴링)이 다음 작업을 더 쉽게 만들어야 합니다. 시스템에 \u0026lsquo;취향\u0026rsquo; 반영: 코드 리뷰 시 매번 수동으로 수정하는 대신, 설정·스키마·자동 검사 도구에 판단 기준을 녹여내어 시스템 자체가 학습하게 합니다. 직접 하기보다 가르치기: 코드를 직접 타이핑하는 시간보다 AI 에이전트에게 더 많은 컨텍스트를 제공하는 데 시간을 투자합니다. 2. 4단계 루프 (The Loop) 컴파운드 엔지니어링은 다음의 반복적인 과정을 통해 완성됩니다.\n계획 (Plan): 에이전트가 이슈를 읽고, 기술 문서를 조사하여 상세한 구현 계획을 세웁니다. 개발자는 코딩보다 이 계획 단계에 가장 많은 시간을 씁니다. 작업 (Work): 에이전트가 계획에 따라 실제 코드와 테스트 코드를 작성합니다. 검토 (Review): 엔지니어는 결과물뿐만 아니라, 에이전트가 작업을 수행하며 얻은 \u0026lsquo;교훈\u0026rsquo;을 검토합니다. 복리화 (Compound): 버그, 성능 이슈, 해결 방법 등을 시스템(지식 베이스나 위키 등)에 기록하여, 다음 작업 시 에이전트가 이를 참조해 똑같은 실수를 반복하지 않게 합니다. 3. 주요 변화 및 원칙 에이전트 네이티브(Agent-native): 프로젝트 구조를 AI 에이전트가 자율적으로 탐색하고 수정할 수 있도록 최적화합니다. 안전망 구축: 수동 검토 프로세스 대신, 자동화된 검증 인프라(테스트 코드, 린트 등)를 구축하여 속도를 확보합니다. 가치 중심: 출력물(타이핑한 코드 양)이 아니라 해결된 문제의 수로 생산성을 측정합니다. 완벽주의 내려놓기: 사람이 직접 만드는 완벽한 결과물보다, 확장이 가능하고 시스템적으로 교정 가능한 AI의 결과물을 수용합니다. 4. 결론 컴파운드 엔지니어링은 단순히 AI를 도구로 쓰는 것을 넘어, AI가 읽고 배울 수 있는 환경을 구축 함으로써 개발 속도를 기하급수적으로 높이는 전략입니다. Every 팀은 이 방식을 통해 1인 개발 팀으로도 복수의 제품을 성공적으로 운영하고 있다고 밝히고 있습니다.\n","wordCount":262,"tags":["AI","AI 에이전트","소프트웨어 엔지니어링","컴파운드 엔지니어링","개발 생산성"],"categories":["software"],"frameworks":["Compound Engineering","Agent-native Development"],"mental_models":["Compounding","Systems Thinking"],"philosophy_type":"methodology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["컴파운드 엔지니어링: AI 에이전트 개발의 복리 루프의 핵심 문제의식은 \"Every의 Compound Engineering 가이드를 바탕으로, AI 에이전트 시대의 복리형 개발 루프와 핵심 원칙을 정리합니다.\"다","AI, AI 에이전트, 소프트웨어 엔지니어링 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agentic-coding-is-a-trap-summary","software/agent-psychosis","software/agent-skills-rules-commands"]},{"title":"Bias Toward Action: 실패 비용을 낮추는 행동 지향적 태도","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/bias-toward-action/","section":"software","date":"2026-02-19T10:02:05+09:00","lastmod":"2026-02-19T10:02:05+09:00","description":"Addy Osmani의 글 'Bias Toward Action' 핵심을 바탕으로, 실패 비용을 통제하며 빠르게 학습하는 실행 시스템의 원칙을 정리합니다.","summary":"출처: https://addyosmani.com/blog/bias-towards-action/\n이 글에서 저자는 \u0026ldquo;행동 지향성\u0026quot;이 단순히 무모하게 빨리 움직이는 것이 아니라, 학습 속도를 높이되 실패해도 치명적이지 않은 시스템을 구축하는 것 이라고 강조합니다.\n1. 핵심 개념: \u0026ldquo;실행 가능한 최소한의 단계\u0026rdquo; 정의: 행동 지향성이란 실제 피드백을 얻을 수 있는 가장 작고 책임감 있는 단계 를 기본값으로 설정하는 것입니다. 오해: 단순히 스타트업 창업자가 소리치는 무모한 구호가 아닙니다. 제대로 된 행동 지향성은 \u0026ldquo;내가 틀렸을 때 어떻게 회복할지\u0026quot;를 정확히 아는 상태에서 움직이는 것입니다. 2. 가드레일(안전장치)의 중요성 빠르게 움직이는 팀은 단순히 속도가 빠른 것이 아니라, 실패해도 죽지 않는 시스템을 갖추고 있습니다.\n","content":"출처: https://addyosmani.com/blog/bias-towards-action/\n이 글에서 저자는 \u0026ldquo;행동 지향성\u0026quot;이 단순히 무모하게 빨리 움직이는 것이 아니라, 학습 속도를 높이되 실패해도 치명적이지 않은 시스템을 구축하는 것 이라고 강조합니다.\n1. 핵심 개념: \u0026ldquo;실행 가능한 최소한의 단계\u0026rdquo; 정의: 행동 지향성이란 실제 피드백을 얻을 수 있는 가장 작고 책임감 있는 단계 를 기본값으로 설정하는 것입니다. 오해: 단순히 스타트업 창업자가 소리치는 무모한 구호가 아닙니다. 제대로 된 행동 지향성은 \u0026ldquo;내가 틀렸을 때 어떻게 회복할지\u0026quot;를 정확히 아는 상태에서 움직이는 것입니다. 2. 가드레일(안전장치)의 중요성 빠르게 움직이는 팀은 단순히 속도가 빠른 것이 아니라, 실패해도 죽지 않는 시스템을 갖추고 있습니다.\n피처 플래그 (Feature Flags): 문제가 생기면 즉시 기능을 끌 수 있는 스위치. 모니터링: 무엇이 잘못되었는지 즉각 알려주는 지표. 롤백 절차: 숙달된 되돌리기 프로세스. 작은 변화: 문제가 생겼을 때 원인을 파악하기 쉽게 변경 단위를 작게 유지. 3. \u0026ldquo;빠른 팀\u0026quot;의 특징 느린 팀보다 더 많은 정보를 사용하지만, 완벽한 데이터를 기다리지 않습니다. 가역적 결정(Two-way doors)과 불가역적 결정(One-way doors) 을 구분합니다. 대부분의 결정은 되돌릴 수 있는 \u0026lsquo;양방향 문\u0026rsquo;이므로, 고민하기보다 실행 후 수정하는 것이 효율적입니다. 에러 버젯 (Error Budgets): 속도와 품질 사이의 갈등을 숫자로 해결하며, 위험을 관리 가능한 범위 내에서 감수합니다. 4. 실행을 위한 조언 완벽주의 경계: \u0026ldquo;나쁜 페이지는 수정할 수 있지만, 빈 페이지는 수정할 수 없다\u0026quot;는 원칙을 가집니다. 우선 실행, 후 개선: 먼저 작동하게 만들고(Make it work), 그다음 올바르게 만들고(Make it right), 마지막으로 더 좋게 만드십시오(Make it better). 분석 마비 탈출: 이론적인 토론보다 한 주간의 실제 피드백이 훨씬 더 많은 것을 가르쳐 줍니다. 요약 결론 진정한 Bias Toward Action 은 무모함이 아니라 엔지니어링적인 규율(Discipline) 입니다. 실패의 비용을 낮추는 안전망을 먼저 구축하고, 그 안에서 가장 작은 단위로 빠르게 실행하여 현실과 부딪히며 배우는 것이 핵심입니다.\n","wordCount":256,"tags":["Addy Osmani","Bias Toward Action","실행","의사결정","엔지니어링"],"categories":["software"],"frameworks":["Two-way doors vs One-way doors","Error Budget"],"mental_models":["Reversible Decisions","Blast Radius"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["Bias Toward Action: 실패 비용을 낮추는 행동 지향적 태도의 핵심 문제의식은 \"Addy Osmani의 글 'Bias Toward Action' 핵심을 바탕으로, 실패 비용을 통제하며 빠르게 학습하는 실행 시스템의 원칙을 정리합니다.\"다","Addy Osmani, Bias Toward Action, 실행 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/getting-real-with-llms","software/ai-assisted-engineering-15-engineers","software/the-future-of-software-engineering-is-sre"]},{"title":"컨텍스트 관리와 MCP: CLI와의 논쟁을 넘어서","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/context-management-and-mcp/","section":"software","date":"2026-02-04T08:59:15+09:00","lastmod":"2026-02-04T08:59:15+09:00","description":"Sentry 창립자 David Cramer가 제안하는 LLM 조종(Steering)과 서브에이전트 중심의 컨텍스트 관리 전략.","summary":"출처: https://cra.mr/context-management-and-mcp/\n이 글은 Sentry의 창립자인 David Cramer가 작성한 것으로, 최근 개발자들 사이에서 벌어지는 \u0026ldquo;MCP(Model Context Protocol)냐 CLI(명령줄 인터페이스)냐\u0026rdquo; 의 논쟁이 본질을 벗어난 것임을 지적하며 \u0026lsquo;컨텍스트 관리와 조종(Steering)\u0026rsquo; 의 중요성을 강조하고 있습니다.\n1. MCP vs CLI 논쟁의 핵심 잘못된 비교: 많은 사람들이 CLI가 나왔으니 MCP를 쓸 필요가 없다고 말하지만, 이는 LLM이 컨텍스트를 어떻게 처리하는지 이해하지 못한 결과입니다. MCP의 진정한 가치: MCP는 단순한 API 프록시가 아니라, LLM이 도구를 더 정확하게 사용하도록 \u0026lsquo;조종(Steering)\u0026rsquo; 하는 데 최적화되어 있습니다. MCP는 마크다운, XML 구조, 힌트 등을 활용해 모델이 이해하기 쉬운 형태로 정보를 전달합니다. 2. 조종(Steering)의 중요성 LLM 맞춤형 응답: 일반적인 API나 CLI는 기계(Machine) 중심의 출력을 내놓지만, 우수한 MCP 서버(예: Sentry MCP)는 LLM이 다음 행동을 결정하기 좋게끔 요약된 정보와 가이드를 제공합니다. 토큰 효율성: \u0026ldquo;항상 켜져 있는 MCP 도구가 토큰을 낭비한다\u0026quot;는 비판도 있지만, 초기 조종 컨텍스트에 토큰을 투자하는 것이 나중에 모델이 길을 잃어 발생하는 \u0026lsquo;컨텍스트 부패(Context Rot)\u0026lsquo;를 막는 데 더 효과적입니다. 3. 점진적 공개(Progressive Disclosure)의 한계 필요할 때만 도구 설명을 불러오는 방식은 모델로부터 \u0026lsquo;도구의 의도\u0026rsquo;를 숨기게 되어, 결국 모델의 추론 능력을 떨어뜨리고 API 호출기 수준으로 전락시킵니다. 4. 해결책: 서브에이전트(Subagents) 저자는 현재의 한계를 극복하기 위해 서브에이전트 방식 을 제안합니다. 특정 작업에만 필요한 MCP 도구와 컨텍스트를 격리된 서브에이전트에 할당함으로써, 컨텍스트 부패를 최소화하고 각 모델이 전문적인 작업을 수행하도록 만들 수 있습니다. 요약 결론 결국 중요한 것은 어떤 프로토콜을 쓰느냐가 아니라 \u0026ldquo;어떻게 하면 모델이 실수 없이 작업을 완수하도록 컨텍스트를 잘 설계하고 전달(Steering)하느냐\u0026rdquo; 입니다. 저자는 이를 위해 모델의 한계를 인정하고 서브에이전트와 같은 구조적 접근이 필요하다고 주장합니다.\n","content":"출처: https://cra.mr/context-management-and-mcp/\n이 글은 Sentry의 창립자인 David Cramer가 작성한 것으로, 최근 개발자들 사이에서 벌어지는 \u0026ldquo;MCP(Model Context Protocol)냐 CLI(명령줄 인터페이스)냐\u0026rdquo; 의 논쟁이 본질을 벗어난 것임을 지적하며 \u0026lsquo;컨텍스트 관리와 조종(Steering)\u0026rsquo; 의 중요성을 강조하고 있습니다.\n1. MCP vs CLI 논쟁의 핵심 잘못된 비교: 많은 사람들이 CLI가 나왔으니 MCP를 쓸 필요가 없다고 말하지만, 이는 LLM이 컨텍스트를 어떻게 처리하는지 이해하지 못한 결과입니다. MCP의 진정한 가치: MCP는 단순한 API 프록시가 아니라, LLM이 도구를 더 정확하게 사용하도록 \u0026lsquo;조종(Steering)\u0026rsquo; 하는 데 최적화되어 있습니다. MCP는 마크다운, XML 구조, 힌트 등을 활용해 모델이 이해하기 쉬운 형태로 정보를 전달합니다. 2. 조종(Steering)의 중요성 LLM 맞춤형 응답: 일반적인 API나 CLI는 기계(Machine) 중심의 출력을 내놓지만, 우수한 MCP 서버(예: Sentry MCP)는 LLM이 다음 행동을 결정하기 좋게끔 요약된 정보와 가이드를 제공합니다. 토큰 효율성: \u0026ldquo;항상 켜져 있는 MCP 도구가 토큰을 낭비한다\u0026quot;는 비판도 있지만, 초기 조종 컨텍스트에 토큰을 투자하는 것이 나중에 모델이 길을 잃어 발생하는 \u0026lsquo;컨텍스트 부패(Context Rot)\u0026lsquo;를 막는 데 더 효과적입니다. 3. 점진적 공개(Progressive Disclosure)의 한계 필요할 때만 도구 설명을 불러오는 방식은 모델로부터 \u0026lsquo;도구의 의도\u0026rsquo;를 숨기게 되어, 결국 모델의 추론 능력을 떨어뜨리고 API 호출기 수준으로 전락시킵니다. 4. 해결책: 서브에이전트(Subagents) 저자는 현재의 한계를 극복하기 위해 서브에이전트 방식 을 제안합니다. 특정 작업에만 필요한 MCP 도구와 컨텍스트를 격리된 서브에이전트에 할당함으로써, 컨텍스트 부패를 최소화하고 각 모델이 전문적인 작업을 수행하도록 만들 수 있습니다. 요약 결론 결국 중요한 것은 어떤 프로토콜을 쓰느냐가 아니라 \u0026ldquo;어떻게 하면 모델이 실수 없이 작업을 완수하도록 컨텍스트를 잘 설계하고 전달(Steering)하느냐\u0026rdquo; 입니다. 저자는 이를 위해 모델의 한계를 인정하고 서브에이전트와 같은 구조적 접근이 필요하다고 주장합니다.\n","wordCount":234,"tags":["MCP","LLM","Context Management","AI Agents"],"categories":["Software"],"frameworks":["Total Cost of Ownership","Agent-native Development","Context Management"],"mental_models":[],"philosophy_type":"","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["컨텍스트 관리와 MCP: CLI와의 논쟁을 넘어서의 핵심 문제의식은 \"Sentry 창립자 David Cramer가 제안하는 LLM 조종(Steering)과 서브에이전트 중심의 컨텍스트 관리 전략.\"다","MCP, LLM, Context Management 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/getting-real-with-llms","software/mcp-best-practices","software/no-silver-bullet-for-llm-coding"]},{"title":"인터페이스의 혁명: 채팅이 모든 것을 삼킨다","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/chat-is-going-to-eat-the-world/","section":"software","date":"2026-02-03T11:25:40+09:00","lastmod":"2026-02-03T11:25:40+09:00","description":"채팅이 GUI를 대체하는 기본 인터페이스로 부상하며, 개별 앱의 시대가 저물고 AI 에이전트 중심의 컴퓨팅 패러다임으로 이동하는 변화를 정리합니다.","summary":"출처: https://deadneurons.substack.com/p/chat-is-going-to-eat-the-world\n1. 인터페이스의 혁명: 채팅이 모든 것을 삼킨다 과거 소프트웨어는 복잡한 메뉴와 버튼으로 구성된 GUI(그래픽 사용자 인터페이스) 중심이었습니다. 하지만 이제 \u0026lsquo;채팅\u0026rsquo;은 단순한 기능이 아니라, 사용자가 컴퓨터와 상호작용하는 기본 운영 체제(OS) 가 되고 있습니다. 마크 안드레센이 \u0026ldquo;소프트웨어가 세상을 먹어치운다\u0026quot;고 했듯, 이제는 \u0026ldquo;채팅이 소프트웨어를 먹어치우고\u0026rdquo; 있습니다.\n2. \u0026lsquo;앱\u0026rsquo;의 종말과 \u0026lsquo;에이전트\u0026rsquo;의 시대 사용자는 더 이상 특정 목적을 위해 개별 앱을 찾아다니거나 복잡한 사용법을 익힐 필요가 없습니다. 대신 자연어로 요청하면 AI 에이전트가 뒤에서 필요한 도구와 데이터를 호출해 결과를 가져다줍니다. 이로 인해 기존의 수많은 개별 앱과 웹사이트의 경계가 무너지고, 모�어와 비즈니스는 도태될 것이라는 경고와 기대를 동시에 전달합니다.\n","content":"출처: https://deadneurons.substack.com/p/chat-is-going-to-eat-the-world\n1. 인터페이스의 혁명: 채팅이 모든 것을 삼킨다 과거 소프트웨어는 복잡한 메뉴와 버튼으로 구성된 GUI(그래픽 사용자 인터페이스) 중심이었습니다. 하지만 이제 \u0026lsquo;채팅\u0026rsquo;은 단순한 기능이 아니라, 사용자가 컴퓨터와 상호작용하는 기본 운영 체제(OS) 가 되고 있습니다. 마크 안드레센이 \u0026ldquo;소프트웨어가 세상을 먹어치운다\u0026quot;고 했듯, 이제는 \u0026ldquo;채팅이 소프트웨어를 먹어치우고\u0026rdquo; 있습니다.\n2. \u0026lsquo;앱\u0026rsquo;의 종말과 \u0026lsquo;에이전트\u0026rsquo;의 시대 사용자는 더 이상 특정 목적을 위해 개별 앱을 찾아다니거나 복잡한 사용법을 익힐 필요가 없습니다. 대신 자연어로 요청하면 AI 에이전트가 뒤에서 필요한 도구와 데이터를 호출해 결과를 가져다줍니다. 이로 인해 기존의 수많은 개별 앱과 웹사이트의 경계가 무너지고, 모�어와 비즈니스는 도태될 것이라는 경고와 기대를 동시에 전달합니다.\n3. 비즈니스 모델의 변화 기존 소프트웨어 기업들은 사용자들을 자신들의 특정 UI 내에 가두어 광고를 보여주거나 구독을 유도했습니다. 하지만 채팅 중심의 세상에서는 \u0026lsquo;가시성\u0026rsquo;보다 \u0026lsquo;연결성\u0026rsquo;이 중요해집니다. AI가 정보를 대신 처리해주기 때문에, 기존의 클릭 기반 광고 모델은 위기를 맞고 새로운 형태의 비즈니스 구조가 필요하게 됩니다.\n4. 인간의 역할과 프로그래밍의 대중화 코딩 기술이 없어도 말(자연어)만으로 복잡한 작업을 수행하고 프로그램을 만들 수 있는 시대가 열렸습니다. 이는 창의성의 문턱을 낮추는 동시에, 역설적으로 \u0026lsquo;질문을 잘하는 능력(프롬프트 엔지니어링)\u0026lsquo;과 \u0026lsquo;비판적 사고\u0026rsquo;가 인간의 가장 중요한 경쟁력이 될 것임을 시사합니다.\n5. 결론 결국 채팅 인터페이스는 인간과 기계 사이의 마찰을 완전히 제거하는 방향으로 진화하고 있습니다. 이는 단순한 유행이 아니라 인류가 도구를 사용하는 방식의 근본적인 패러다임 전환이며, 이 변화에 적응하지 못하는 기존의 소프트웨어와 비즈니스는 도태될 것이라는 경고와 기대를 동시에 전달합니다.\n","wordCount":210,"tags":["AI","채팅","인터페이스","에이전트","앱"],"categories":["ai","software"],"frameworks":["Agent-native Development","Operational Excellence","Context Management"],"mental_models":[],"philosophy_type":"","schema_type":"TechArticle","actionable":false,"priority":"high","key_points":["인터페이스의 혁명: 채팅이 모든 것을 삼킨다의 핵심 문제의식은 \"채팅이 GUI를 대체하는 기본 인터페이스로 부상하며, 개별 앱의 시대가 저물고 AI 에이전트 중심의 컴퓨팅 패러다임으로 이동하는 변화를 정리합니다.\"다","AI, 채팅, 인터페이스 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agent-psychosis","software/agent-skills-rules-commands","software/agentic-coding-is-a-trap-summary"]},{"title":"에이전틱 코딩의 80% 문제","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/the-80-problem-in-agentic-coding/","section":"software","date":"2026-01-29T15:54:26+09:00","lastmod":"2026-01-29T15:54:26+09:00","description":"AI 코딩 에이전트가 빠르게 80%를 만들고도 나머지 20%에서 막히는 이유(맥락·검증·루프)와 이를 넘기 위한 협업·테스트·작업 분할 제언을 정리합니다.","summary":"출처: https://addyo.substack.com/p/the-80-problem-in-agentic-coding\n1. 80% 문제란 무엇인가? 초기 성과(80%)의 함정 : AI 에이전트는 복잡한 코드 작성, 라이브러리 선택, 기본 구조 설계 등 작업의 80%를 순식간에 해냅니다. 하지만 이는 사용자에게 \u0026ldquo;거의 다 끝났다\u0026quot;는 착각을 줍니다. 나머지 20%의 난이도 : 실제 배포 가능한 수준으로 만드는 나머지 20%(엣지 케이스 처리, 기존 코드와의 완벽한 통합, 보안 및 성능 최적화 등)는 훨씬 더 어렵고 시간이 많이 걸립니다. 2. 왜 이런 문제가 발생하는가? 맥락 파악의 한계 : 에이전트가 전체 코드베이스의 비즈니스 로직이나 사소한 종속성을 완벽히 이해하지 못해 \u0026ldquo;그럴듯하지만 틀린\u0026rdquo; 코드를 생성할 때가 많습니다. 검증의 어려움 : AI가 짠 코드를 검토하는 것이 사람이 처음부터 짜는 것보다 더 많은 인지적 에너지를 소모할 수 있습니다. 루프의 부재 : 에이전트가 스스로 실행 결과를 확인하고 수정하는 과정(Agentic Workflow)이 아직 인간 개발자의 직관만큼 정교하지 않습니다. 3. 해결을 위한 제언 (어떻게 나아가야 하는가?) 인간과 AI의 협업 모델 : AI를 단순히 \u0026lsquo;코드 생성기\u0026rsquo;가 아닌, 인간의 의도를 끊임없이 확인하고 피드백을 받는 \u0026lsquo;파트너\u0026rsquo; 로서 설계해야 합니다. 테스트 자동화의 중요성 : 80% 지점에서 멈추지 않으려면, 에이전트가 직접 단위 테스트를 작성하고 통과할 때까지 반복하는 능력이 필수적입니다. 작은 단위의 작업 분할 : 한 번에 큰 기능을 맡기기보다, 명확하게 정의된 작은 단위로 작업을 나누어 에이전트에게 맡길 때 성공률이 높아집니다. 요약하자면: 아디티아 아가왈(Aditya Agarwal)은 AI 코딩 에이전트가 \u0026lsquo;마법처럼 코드를 짜주는 도구\u0026rsquo;에서 \u0026lsquo;실제로 업무를 끝마칠 수 있는 도구\u0026rsquo; 가 되기 위해서는, 단순히 생성 능력을 키우는 것이 아니라 추론, 검증, 그리고 인간 개발자와의 긴밀한 상호작용 이 핵심이 되어야 한다고 강조합니다.\n","content":"출처: https://addyo.substack.com/p/the-80-problem-in-agentic-coding\n1. 80% 문제란 무엇인가? 초기 성과(80%)의 함정 : AI 에이전트는 복잡한 코드 작성, 라이브러리 선택, 기본 구조 설계 등 작업의 80%를 순식간에 해냅니다. 하지만 이는 사용자에게 \u0026ldquo;거의 다 끝났다\u0026quot;는 착각을 줍니다. 나머지 20%의 난이도 : 실제 배포 가능한 수준으로 만드는 나머지 20%(엣지 케이스 처리, 기존 코드와의 완벽한 통합, 보안 및 성능 최적화 등)는 훨씬 더 어렵고 시간이 많이 걸립니다. 2. 왜 이런 문제가 발생하는가? 맥락 파악의 한계 : 에이전트가 전체 코드베이스의 비즈니스 로직이나 사소한 종속성을 완벽히 이해하지 못해 \u0026ldquo;그럴듯하지만 틀린\u0026rdquo; 코드를 생성할 때가 많습니다. 검증의 어려움 : AI가 짠 코드를 검토하는 것이 사람이 처음부터 짜는 것보다 더 많은 인지적 에너지를 소모할 수 있습니다. 루프의 부재 : 에이전트가 스스로 실행 결과를 확인하고 수정하는 과정(Agentic Workflow)이 아직 인간 개발자의 직관만큼 정교하지 않습니다. 3. 해결을 위한 제언 (어떻게 나아가야 하는가?) 인간과 AI의 협업 모델 : AI를 단순히 \u0026lsquo;코드 생성기\u0026rsquo;가 아닌, 인간의 의도를 끊임없이 확인하고 피드백을 받는 \u0026lsquo;파트너\u0026rsquo; 로서 설계해야 합니다. 테스트 자동화의 중요성 : 80% 지점에서 멈추지 않으려면, 에이전트가 직접 단위 테스트를 작성하고 통과할 때까지 반복하는 능력이 필수적입니다. 작은 단위의 작업 분할 : 한 번에 큰 기능을 맡기기보다, 명확하게 정의된 작은 단위로 작업을 나누어 에이전트에게 맡길 때 성공률이 높아집니다. 요약하자면: 아디티아 아가왈(Aditya Agarwal)은 AI 코딩 에이전트가 \u0026lsquo;마법처럼 코드를 짜주는 도구\u0026rsquo;에서 \u0026lsquo;실제로 업무를 끝마칠 수 있는 도구\u0026rsquo; 가 되기 위해서는, 단순히 생성 능력을 키우는 것이 아니라 추론, 검증, 그리고 인간 개발자와의 긴밀한 상호작용 이 핵심이 되어야 한다고 강조합니다.\n","wordCount":226,"tags":["AI","에이전트","코딩","Agentic coding","80% 문제","테스트 자동화","협업"],"categories":["software"],"frameworks":["Agentic Workflow","Test Automation"],"mental_models":["Pareto Principle"],"philosophy_type":"methodology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전틱 코딩의 80% 문제의 핵심 문제의식은 \"AI 코딩 에이전트가 빠르게 80%를 만들고도 나머지 20%에서 막히는 이유(맥락·검증·루프)와 이를 넘기 위한 협업·테스트·작업 분할 제언을 정리합니다.\"다","AI, 에이전트, 코딩 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agent-psychosis","software/agentic-coding-is-a-trap-summary","software/agent-skills-rules-commands"]},{"title":"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-27T14:30:00+09:00","lastmod":"2026-01-27T14:30:00+09:00","description":"코드 작성이 저렴해지면서 운영 우수성이 승리한다. 누구나 그린필드 데모를 만들 수 있지만, 서비스를 운영하는 것은 엔지니어링이 필요하다.","summary":"AI(LLM)와 노코드 툴의 발전으로 코드 작성 비용이 0에 수렴하는 시대에, 소프트웨어 엔지니어링의 미래는 무엇일까?\n출처: The future of software engineering is SRE - Swizec Teller\n1. 핵심 요지: \u0026ldquo;코드가 저렴해질수록 운영 능력이 승리한다\u0026rdquo; AI(LLM)와 노코드 툴의 발전으로 코드를 작성하는 비용은 0에 수렴하고 있습니다. 누구나 작동하는 데모(Greenfield demo)는 만들 수 있는 시대가 되었지만, 그 서비스를 안정적으로 \u0026lsquo;운영\u0026rsquo;하는 것 은 여전히 어렵고 중요한 문제라는 것이 글의 핵심입니다.\n2. 소프트웨어 엔지니어링의 정의: \u0026ldquo;시간 위의 프로그래밍\u0026rdquo; 저자는 프로그래밍과 소프트웨어 엔지니어링을 구분합니다.\n","content":"AI(LLM)와 노코드 툴의 발전으로 코드 작성 비용이 0에 수렴하는 시대에, 소프트웨어 엔지니어링의 미래는 무엇일까?\n출처: The future of software engineering is SRE - Swizec Teller\n1. 핵심 요지: \u0026ldquo;코드가 저렴해질수록 운영 능력이 승리한다\u0026rdquo; AI(LLM)와 노코드 툴의 발전으로 코드를 작성하는 비용은 0에 수렴하고 있습니다. 누구나 작동하는 데모(Greenfield demo)는 만들 수 있는 시대가 되었지만, 그 서비스를 안정적으로 \u0026lsquo;운영\u0026rsquo;하는 것 은 여전히 어렵고 중요한 문제라는 것이 글의 핵심입니다.\n2. 소프트웨어 엔지니어링의 정의: \u0026ldquo;시간 위의 프로그래밍\u0026rdquo; 저자는 프로그래밍과 소프트웨어 엔지니어링을 구분합니다.\n프로그래밍: 특정 문제를 해결하기 위해 코드를 작성하는 것. 소프트웨어 엔지니어링: 시간이 흐름에 따라 변화하는 시스템을 관리하는 것. (트래픽 증가, 보안 업데이트, 요구사항 변경, 팀원 교체 등) 3. 왜 SRE(Site Reliability Engineering)인가? 단순히 기능을 만드는 \u0026lsquo;코더\u0026rsquo;의 가치는 떨어지겠지만, 시스템의 신뢰성을 설계하는 SRE적 역량을 가진 엔지니어의 수요는 폭발할 것이라고 예측합니다.\n복잡성의 증가: 코드가 생성되는 속도가 빨라질수록 시스템은 더 복잡해지고, 이를 머릿속으로 다 파악하기 힘들어집니다. 진정한 엔지니어링의 영역: \u0026ldquo;장애에서 복구할 수 있는가?\u0026rdquo;, \u0026ldquo;보안 업데이트를 유지하고 있는가?\u0026rdquo;, \u0026ldquo;데이터 유출을 막을 수 있는가?\u0026rdquo;, \u0026ldquo;나 없이도 시스템이 돌아가는가?\u0026ldquo;와 같은 질문에 답하는 것이 현대 엔지니어의 진짜 역할입니다. 4. 주요 통찰 AI의 한계: AI는 코드를 빨리 짤 수 있지만, 운영상의 탁월함(Operational Excellence)까지 책임져주지는 않습니다. 오히려 AI가 만든 수많은 코드 때문에 유지보수 비용과 복잡성이 커질 수 있습니다. 신뢰가 곧 가치: 사용자가 서비스를 믿고 쓸 수 있게 만드는 것, 즉 신뢰성(Reliability) 이 소프트웨어 제품의 가장 큰 차별점이 될 것입니다. 요약 결론 앞으로의 소프트웨어 엔지니어는 단순히 \u0026ldquo;기능을 구현하는 사람\u0026quot;이 아니라, \u0026ldquo;복잡한 시스템이 안정적이고 지속 가능하게 돌아가도록 설계하고 운영하는 SRE\u0026rdquo; 가 되어야 살아남을 수 있다는 메시지를 던지고 있습니다.\n","wordCount":243,"tags":["SRE","소프트웨어 엔지니어링","운영","DevOps","엔지니어링"],"categories":["software"],"frameworks":["Operational Excellence"],"mental_models":["The Computer Disease"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["The future of software engineering is SRE의 핵심 문제의식은 \"코드 작성이 저렴해지면서 운영 우수성이 승리한다. 누구나 그린필드 데모를 만들 수 있지만, 서비스를 운영하는 것은 엔지니어링이 필요하다.\"다","SRE, 소프트웨어 엔지니어링, 운영 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/the-20-software-engineering-laws-summary","software/agentic-coding-is-a-trap-summary","software/ai-assisted-engineering-15-engineers"]},{"title":"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-27T09:43:44+09:00","lastmod":"2026-01-27T09:43:44+09:00","description":"OpenAI Codex 에이전트의 내부 동작 원리와 에이전트 루프, 프롬프트 구성, 성능 최적화 방법을 분석한 기술 블로그 글 요약","summary":"OpenAI에서 발표한 \u0026ldquo;Unrolling the Codex Agent Loop\u0026rdquo; 는 AI 에이전트인 Codex가 사용자 요청을 처리하기 위해 내부적으로 어떻게 동작하는지(에이전트 루프)를 심층 분석한 기술 블로그 글입니다.\n출처: Unrolling the Codex Agent Loop - OpenAI\n1. 에이전트 루프 (The Agent Loop) AI 에이전트의 핵심은 모델 자체가 아니라, 모델과 도구를 연결하는 \u0026lsquo;루프(순환 구조)\u0026rsquo; 에 있습니다.\n프로세스: 사용자 입력 → 프롬프트 구성 → 모델 추론(Inference) → 도구 호출(Tool Call) → 실행 결과 반영 → 재추론 → 최종 응답. 특징: 하나의 질문(Turn)에 대해 모델은 단순히 답변만 하는 것이 아니라, 수십에서 수백 번의 도구 호출(파일 읽기, 셸 명령어 실행 등)을 반복하며 스스로 문제를 해결합니다. 2. 프롬프트 구성 방식 Codex는 사용자의 입력을 그대로 모델에 전달하지 않고, 복잡한 \u0026lsquo;프롬프트 스티칭(Stitching)\u0026rsquo; 과정을 거칩니다.\n","content":"OpenAI에서 발표한 \u0026ldquo;Unrolling the Codex Agent Loop\u0026rdquo; 는 AI 에이전트인 Codex가 사용자 요청을 처리하기 위해 내부적으로 어떻게 동작하는지(에이전트 루프)를 심층 분석한 기술 블로그 글입니다.\n출처: Unrolling the Codex Agent Loop - OpenAI\n1. 에이전트 루프 (The Agent Loop) AI 에이전트의 핵심은 모델 자체가 아니라, 모델과 도구를 연결하는 \u0026lsquo;루프(순환 구조)\u0026rsquo; 에 있습니다.\n프로세스: 사용자 입력 → 프롬프트 구성 → 모델 추론(Inference) → 도구 호출(Tool Call) → 실행 결과 반영 → 재추론 → 최종 응답. 특징: 하나의 질문(Turn)에 대해 모델은 단순히 답변만 하는 것이 아니라, 수십에서 수백 번의 도구 호출(파일 읽기, 셸 명령어 실행 등)을 반복하며 스스로 문제를 해결합니다. 2. 프롬프트 구성 방식 Codex는 사용자의 입력을 그대로 모델에 전달하지 않고, 복잡한 \u0026lsquo;프롬프트 스티칭(Stitching)\u0026rsquo; 과정을 거칩니다.\n시스템 지침, 개발자 설정, 프로젝트 컨텍스트(현재 디렉토리 파일 목록 등), 사용자의 이전 대화 기록 등을 정교하게 조합하여 모델이 상황을 정확히 이해하도록 돕습니다. 3. 성능 최적화: 프롬프트 캐싱 (Prompt Caching) 에이전트 루프가 반복될수록 프롬프트의 길이가 매우 길어지는데, 이를 효율적으로 처리하기 위해 프롬프트 캐싱 을 적극 활용합니다.\n접두사 캐싱(Prefix Caching): 이전 단계에서 생성된 토큰들을 재사용하여 연산 속도를 높이고 비용을 절감합니다. 캐시 미스 방지: 루프 중간에 불필요하게 프롬프트가 변경되지 않도록 상태 관리를 철저히 하여 캐시 효율을 극대화합니다. 4. 핵심 철학: \u0026ldquo;실행을 통한 추론\u0026rdquo; Codex는 단 한 번의 추론으로 완벽한 코드를 짜는 것이 아니라, 코드를 실행해보고 그 결과(에러 메시지 등)를 다시 학습하여 수정하는 방식 으로 작동합니다. 이는 인간 개발자가 코드를 작성하고 테스트하는 과정과 매우 유사합니다.\n결론 이 글은 Codex CLI가 단순한 코드 완성 도구가 아니라, 복잡한 소프트웨어 공학 작업을 수행할 수 있는 \u0026lsquo;자율적인 에이전트\u0026rsquo;로 설계되었음 을 강조하며, 그 기반이 되는 인프라와 최적화 기술을 투명하게 공개하고 있습니다.\n","wordCount":255,"tags":["Codex","AI 에이전트","에이전트 루프","프롬프트 캐싱","OpenAI","prompt cache miss"],"categories":["software"],"frameworks":["Agent Loop","Prompt Caching"],"mental_models":["Execution through Reasoning"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Unrolling the Codex Agent Loop의 핵심 문제의식은 \"OpenAI Codex 에이전트의 내부 동작 원리와 에이전트 루프, 프롬프트 구성, 성능 최적화 방법을 분석한 기술 블로그 글 요약\"다","Codex, AI 에이전트, 에이전트 루프 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/compound-engineering","software/the-future-of-software-engineering-is-sre","posts/the-20-software-engineering-laws-summary"]},{"title":"에이전트 규칙·기술·명령: 무엇을 언제 써야 할까","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/agent-skills-rules-commands/","section":"software","date":"2026-01-27T00:00:00+09:00","lastmod":"2026-01-27T00:00:00+09:00","description":"Builder.io 블로그를 바탕으로, AI 에이전트에서 규칙(Rules), 기술(Skills), 명령(Commands)의 차이와 언제 무엇을 사용할지에 대한 결정 기준을 정리합니다.","summary":"AI 에이전트를 설계할 때 규칙(Rules), 기술(Skills), 명령(Commands) 을 어떻게 구분하고 사용할지가 핵심입니다. Builder.io 블로그 글을 바탕으로 세 개념의 정의, 사용 시점, 그리고 효과적인 기술 작성 방법을 정리했습니다.\n원문: Agent skills, rules, and commands\n1. 핵심 개념 정의 규칙 (Rules): 예외 없이 항상 적용되는 원칙입니다. (예: \u0026ldquo;절대 .env 파일을 커밋하지 마라\u0026rdquo;, \u0026ldquo;명명 규칙 준수\u0026rdquo;) 기술 (Skills): 특정 작업 시에만 불러오는 선택적 전문 지식입니다. 에이전트가 필요할 때만 \u0026lsquo;지연 로딩(Lazy loading)\u0026lsquo;하여 컨텍스트 낭비를 줄입니다. (예: \u0026ldquo;UI 변경 시 체크리스트\u0026rdquo;, \u0026ldquo;배포 가이드\u0026rdquo;) 명령 (Commands): 사용자가 직접 실행하는 반복 가능한 워크플로우입니다. (예: /release, /refactor) 2. 기술(Skills)의 특징과 장점 점진적 공개(Progressive Disclosure): 에이전트가 처음부터 모든 내용을 읽지 않고, 메타데이터(설명)를 보고 필요할 때만 전체 내용을 로드합니다. 이는 모델의 컨텍스트 창을 아끼고 성능 저하를 방지합니다. 구성 요소: 기술은 지침이 담긴 SKILL.md 파일과 관련 스크립트, 템플릿, 참고 문서로 이루어진 폴더 형태입니다. 3. 언제 무엇을 사용해야 하는가? (결정 기준) 규칙: 내가 생각하고 있지 않을 때도 에이전트가 지켜야 하는가? (Yes → 규칙) 기술: 특정 상황이나 특정 파일 작업 시에만 필요한 전문 지식인가? (Yes → 기술) 명령: 내가 직접 제어권을 갖고 특정 동작을 시작하고 싶은가? (Yes → 명령) 4. 효과적인 \u0026lsquo;기술(Skill)\u0026rsquo; 작성 팁 설명(Description) 최적화: 에이전트가 기술을 잘 찾아낼 수 있도록 키워드 중심의 구체적인 설명을 작성해야 합니다. 절차 중심: 기술 본문은 위키처럼 정보를 나열하기보다, 구체적인 작업 절차와 성공 기준(Success Criteria)을 명시하는 것이 좋습니다. 분리: 내용이 너무 길어지면 별도의 참조 파일로 분리하여 에이전트가 필요할 때만 읽게 합니다. 5. 요약 비교표 개념 실행 주체 용도 컨텍스트 비용 규칙 (Rules) 도구/시스템 저장소 기본 요구사항 항상 발생 명령 (Commands) 사용자 반복적인 워크플로우 사용 시 발생 기술 (Skills) 에이전트 작업별 전문 가이드 필요 시에만 발생 결론적으로, 모든 지침을 \u0026lsquo;규칙\u0026rsquo;에 쏟아붓는 대신, 상시 규칙은 최소화하고 작업에 필요한 전문 지식은 \u0026lsquo;기술\u0026rsquo; 단위로 모듈화하여 관리하는 것이 최신 AI 에이전트 활용의 핵심 전략입니다.\n","content":"AI 에이전트를 설계할 때 규칙(Rules), 기술(Skills), 명령(Commands) 을 어떻게 구분하고 사용할지가 핵심입니다. Builder.io 블로그 글을 바탕으로 세 개념의 정의, 사용 시점, 그리고 효과적인 기술 작성 방법을 정리했습니다.\n원문: Agent skills, rules, and commands\n1. 핵심 개념 정의 규칙 (Rules): 예외 없이 항상 적용되는 원칙입니다. (예: \u0026ldquo;절대 .env 파일을 커밋하지 마라\u0026rdquo;, \u0026ldquo;명명 규칙 준수\u0026rdquo;) 기술 (Skills): 특정 작업 시에만 불러오는 선택적 전문 지식입니다. 에이전트가 필요할 때만 \u0026lsquo;지연 로딩(Lazy loading)\u0026lsquo;하여 컨텍스트 낭비를 줄입니다. (예: \u0026ldquo;UI 변경 시 체크리스트\u0026rdquo;, \u0026ldquo;배포 가이드\u0026rdquo;) 명령 (Commands): 사용자가 직접 실행하는 반복 가능한 워크플로우입니다. (예: /release, /refactor) 2. 기술(Skills)의 특징과 장점 점진적 공개(Progressive Disclosure): 에이전트가 처음부터 모든 내용을 읽지 않고, 메타데이터(설명)를 보고 필요할 때만 전체 내용을 로드합니다. 이는 모델의 컨텍스트 창을 아끼고 성능 저하를 방지합니다. 구성 요소: 기술은 지침이 담긴 SKILL.md 파일과 관련 스크립트, 템플릿, 참고 문서로 이루어진 폴더 형태입니다. 3. 언제 무엇을 사용해야 하는가? (결정 기준) 규칙: 내가 생각하고 있지 않을 때도 에이전트가 지켜야 하는가? (Yes → 규칙) 기술: 특정 상황이나 특정 파일 작업 시에만 필요한 전문 지식인가? (Yes → 기술) 명령: 내가 직접 제어권을 갖고 특정 동작을 시작하고 싶은가? (Yes → 명령) 4. 효과적인 \u0026lsquo;기술(Skill)\u0026rsquo; 작성 팁 설명(Description) 최적화: 에이전트가 기술을 잘 찾아낼 수 있도록 키워드 중심의 구체적인 설명을 작성해야 합니다. 절차 중심: 기술 본문은 위키처럼 정보를 나열하기보다, 구체적인 작업 절차와 성공 기준(Success Criteria)을 명시하는 것이 좋습니다. 분리: 내용이 너무 길어지면 별도의 참조 파일로 분리하여 에이전트가 필요할 때만 읽게 합니다. 5. 요약 비교표 개념 실행 주체 용도 컨텍스트 비용 규칙 (Rules) 도구/시스템 저장소 기본 요구사항 항상 발생 명령 (Commands) 사용자 반복적인 워크플로우 사용 시 발생 기술 (Skills) 에이전트 작업별 전문 가이드 필요 시에만 발생 결론적으로, 모든 지침을 \u0026lsquo;규칙\u0026rsquo;에 쏟아붓는 대신, 상시 규칙은 최소화하고 작업에 필요한 전문 지식은 \u0026lsquo;기술\u0026rsquo; 단위로 모듈화하여 관리하는 것이 최신 AI 에이전트 활용의 핵심 전략입니다.\n","wordCount":282,"tags":["AI","에이전트","규칙","기술","명령","Rules","Skills","Commands"],"categories":["ai","software"],"frameworks":["Progressive Disclosure","Lazy loading"],"mental_models":["Separation of concerns","Context efficiency"],"philosophy_type":"methodology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["에이전트 규칙·기술·명령: 무엇을 언제 써야 할까의 핵심 문제의식은 \"Builder.io 블로그를 바탕으로, AI 에이전트에서 규칙(Rules), 기술(Skills), 명령(Commands)의 차이와 언제 무엇을 사용할지에 대한 결정 기준을 정리합니다.\"다","AI, 에이전트, 규칙 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agent-psychosis","software/agentic-coding-is-a-trap-summary","software/chat-is-going-to-eat-the-world"]},{"title":"LLM과 현실적으로 마주하기: 실무 중심의 AI 활용 매트릭스","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/getting-real-with-llms/","section":"software","date":"2026-01-26T11:54:00+09:00","lastmod":"2026-01-26T11:54:00+09:00","description":"작업의 복잡도와 부작용(Side-effects)이라는 두 축으로 AI의 유용성을 정의하고, 현재 LLM이 실제로 도움이 되는 영역과 단순히 '연기(Smoke \u0026 Mirrors)'에 불과한 영역을 구분하는 실무 중심의 분석.","summary":"보내주신 글은 현직 개발자와 관리자가 느끼는 \u0026ldquo;AI 환상(Hype)과 실제 업무 사이의 괴리\u0026rdquo; 를 아주 날카롭게 짚고 있습니다. 특히 단순한 성능 지표가 아닌, 작업의 복잡도 와 부작용(Side-effects) 이라는 두 축으로 AI의 유용성을 정의한 점이 매우 인상적입니다.\n출처: Getting Real With LLMs - Gilad Peleg\n🚀 실무 중심의 AI 활용 매트릭스 이 글은 엔지니어링 업무를 복잡도(X축) 와 부작용/파급력(Y축) 으로 나누어, 현재 LLM이 실제로 도움이 되는 영역과 단순히 \u0026ldquo;연기(Smoke \u0026amp; Mirrors)\u0026ldquo;에 불과한 영역을 구분합니다.\n","content":"보내주신 글은 현직 개발자와 관리자가 느끼는 \u0026ldquo;AI 환상(Hype)과 실제 업무 사이의 괴리\u0026rdquo; 를 아주 날카롭게 짚고 있습니다. 특히 단순한 성능 지표가 아닌, 작업의 복잡도 와 부작용(Side-effects) 이라는 두 축으로 AI의 유용성을 정의한 점이 매우 인상적입니다.\n출처: Getting Real With LLMs - Gilad Peleg\n🚀 실무 중심의 AI 활용 매트릭스 이 글은 엔지니어링 업무를 복잡도(X축) 와 부작용/파급력(Y축) 으로 나누어, 현재 LLM이 실제로 도움이 되는 영역과 단순히 \u0026ldquo;연기(Smoke \u0026amp; Mirrors)\u0026ldquo;에 불과한 영역을 구분합니다.\n1. 2x2 업무 매트릭스 분석 구분 특성 (Side-effects \u0026amp; Complexity) AI 활용 현황 및 전략 Q1. 단순 \u0026amp; 폐쇄 루프 영향 범위가 좁고 테스트(Lint, Build)로 즉각 검증 가능 [해결됨] 이미 현재 도구로 풀 자동화가 가능한 영역 (버그 수정, 로컬 기능 구현). Q2. 복잡 \u0026amp; 폐쇄 루프 작업 자체는 크지만 기존 시스템에 미치는 영향이 없음 [매우 효과적] 새로운 앱/마이크로서비스 개발. \u0026lsquo;Vibe-coding\u0026rsquo;이 빛을 발하며 탐색적 개발에 최적. Q3. 단순 \u0026amp; 오픈 루프 작업은 쉽지만(이름 변경 등), 예상치 못한 연쇄 고장이 발생 가능 [어려움/핵심 과제] 가장 가치 있는 영역이나, AI에게 시스템 의존성을 가르치는 고도의 전략이 필요. Q4. 복잡 \u0026amp; 오픈 루프 작업도 어렵고 어디가 깨질지 모르는 고위험 영역 [성배/미지의 영역] 현재로서는 마법 같은 해결책이 없음. 작업을 쪼개거나 부작용을 줄이는 수밖에 없음. 2. 주요 인사이트 측정의 함정 (Goodhart\u0026rsquo;s Law): \u0026ldquo;AI 사용률\u0026quot;이나 \u0026ldquo;AI가 작성한 코드 비율\u0026rdquo; 같은 지표는 엔지니어들이 수치 채우기에 급급하게 만들 뿐, 실제 비즈니스 가치나 안정성과는 무관할 수 있습니다. 오픈 루프(Open Loop)의 공포: 실무자가 AI 도입을 주저하는 이유는 실력이 없어서가 아니라, \u0026ldquo;이 코드 한 줄 바꿨을 때 어디가 터질지 모른다\u0026rdquo; 는 맥락을 AI가 읽지 못하기 때문입니다. 2026년의 생존 전략: 이미 해결된 Q1 영역에서 도구를 능숙하게 사용하기. 시스템 간의 결합도(Coupling)를 낮추어 \u0026lsquo;오픈 루프\u0026rsquo; 작업을 \u0026lsquo;폐쇄 루프\u0026rsquo;로 전환 하는 아키텍처 역량 기르기. AI에게 부작용에 대한 컨텍스트(테스트 방법, 모니터링 지점 등)를 학습시키는 방법론에 집중하기. 💡 결론 결국 2026년의 유능한 엔지니어는 단순히 AI에게 코딩을 시키는 사람이 아니라, AI가 안전하게 작업할 수 있도록 시스템의 \u0026ldquo;폭발 반경(Blast Radius)\u0026ldquo;을 통제하고 격리할 줄 아는 설계자 가 될 것입니다.\n","wordCount":308,"tags":["LLM","AI","엔지니어링","프로덕션","실무","매트릭스"],"categories":["software"],"frameworks":["2x2 Matrix","Closed-loop vs Open-loop"],"mental_models":["Goodhart's Law","Blast Radius"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["LLM과 현실적으로 마주하기: 실무 중심의 AI 활용 매트릭스의 핵심 문제의식은 \"작업의 복잡도와 부작용(Side-effects)이라는 두 축으로 AI의 유용성을 정의하고, 현재 LLM이 실제로 도움이 되는 영역과 단순히 '연기(Smoke \u0026 Mirrors)'에 불과한 영역을 구분하는 실무 중심의 분석.\"다","본문은 🚀 실무 중심의 AI 활용 매트릭스 흐름으로 논지를 전개한다","LLM, AI, 엔지니어링 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/ai-assisted-engineering-15-engineers","software/bias-toward-action","software/no-silver-bullet-for-llm-coding"]},{"title":"MCP(Model Context Protocol) 베스트 프랙티스: AI 에이전트를 위한 UI 설계","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/mcp-best-practices/","section":"software","date":"2026-01-23T12:10:00+09:00","lastmod":"2026-01-23T12:10:00+09:00","description":"MCP는 REST API의 연장선이 아니라 AI 에이전트를 위한 사용자 인터페이스(UI)로 설계되어야 한다는 관점에서 6가지 베스트 프랙티스를 정리한 글.","summary":"MCP(Model Context Protocol) 서버를 설계할 때는 인프라가 아니라 \u0026ldquo;AI 에이전트를 위한 UI\u0026rdquo; 를 만든다는 관점이 핵심입니다.\n출처: MCP Best Practices\n이 글의 핵심은 \u0026ldquo;MCP(Model Context Protocol)는 REST API의 연장선이 아니라, AI 에이전트를 위한 사용자 인터페이스(UI)로 설계되어야 한다\u0026rdquo; 는 것입니다.\n1. MCP란 무엇인가? 정의: LLM과 외부 도구, 데이터 소스, 서비스를 연결하는 표준 프로토콜. 핵심 요소: 도구(Tools, 실행 기능), 리소스(Resources, 읽기 전용 데이터), 프롬프트(Prompts, 사전 정의된 워크플로우). 오해: MCP는 단순한 REST API 래퍼가 아닙니다. 개발자가 아닌 \u0026lsquo;AI 에이전트\u0026rsquo;가 사용자임을 인식해야 합니다. 2. MCP 서버 구축을 위한 6가지 베스트 프랙티스 ① 운영(Operations)이 아닌 결과(Outcomes) 중심 설계 문제: REST API처럼 여러 개의 작은 엔드포인트(예: 사용자 찾기 → 주문 목록 → 주문 상태)를 노출하면 에이전트가 여러 번 호출해야 하므로 비효율적입니다. 해결: 에이전트가 한 번에 목적을 달성할 수 있는 고수준 도구(예: track_latest_order)를 제공하세요. 오케스트레이션은 LLM 내부가 아닌 서버 코드에서 처리해야 합니다. ② 인자 구조의 단순화 (Flatten Your Arguments) 문제: 복잡한 중첩 딕셔너리나 객체는 에이전트의 환각(Hallucination)을 유발합니다. 해결: 인자를 최상위 수준의 프리미티브 타입(String, Int 등)으로 평탄화하고, Literal이나 Enum을 사용하여 선택지를 명확히 제한하세요. ③ 설명(Docstrings)은 곧 지침이다 문제: 설명을 비워두거나 모호하게 적는 것. 해결: 도구의 설명과 에러 메시지 자체가 에이전트에게는 \u0026lsquo;프롬프트\u0026rsquo;입니다. 언제 도구를 사용할지, 인자 형식은 어떠해야 하는지, 에러 발생 시 어떻게 수정해야 할지를 상세히 적으세요. ④ 무자비한 큐레이션 (Curate Ruthlessly) 문제: API의 모든 기능을 노출하여 컨텍스트 창을 낭비하는 것. 해결: 서버당 도구를 5~15개로 제한하세요. 사용하지 않는 도구는 삭제하고, 용도에 따라 서버를 분리(예: 관리자용/사용자용)하여 에이전트가 필요한 도구를 빨리 찾게 하세요. ⑤ 검색이 용이한 이름 지정 (Name for Discovery) 문제: create_issue 같이 너무 일반적인 이름은 다른 서비스와 충돌할 수 있습니다. 해결: {서비스}_{동사}_{리소스} 형식을 권장합니다. (예: slack_send_message, jira_create_issue) ⑥ 대량 결과의 페이지네이션 (Paginate Large Results) 문제: 수백 개의 레코드를 한꺼번에 반환하면 컨텍스트 창이 폭발합니다. 해결: limit 파라미터를 제공하고, has_more, next_offset 같은 메타데이터를 포함하여 에이전트가 필요한 만큼만 데이터를 가져오게 하세요. 결론 MCP 서버를 구축할 때는 인프라를 만드는 것이 아니라 \u0026ldquo;AI 에이전트를 위한 UI를 설계한다\u0026rdquo; 는 마음가짐이 필요합니다. 에이전트가 복잡한 단계를 거치지 않고 최소한의 호출로 정확한 결과를 얻을 수 있도록 최적화하는 것이 성공적인 MCP 서버의 핵심입니다.\n","content":"MCP(Model Context Protocol) 서버를 설계할 때는 인프라가 아니라 \u0026ldquo;AI 에이전트를 위한 UI\u0026rdquo; 를 만든다는 관점이 핵심입니다.\n출처: MCP Best Practices\n이 글의 핵심은 \u0026ldquo;MCP(Model Context Protocol)는 REST API의 연장선이 아니라, AI 에이전트를 위한 사용자 인터페이스(UI)로 설계되어야 한다\u0026rdquo; 는 것입니다.\n1. MCP란 무엇인가? 정의: LLM과 외부 도구, 데이터 소스, 서비스를 연결하는 표준 프로토콜. 핵심 요소: 도구(Tools, 실행 기능), 리소스(Resources, 읽기 전용 데이터), 프롬프트(Prompts, 사전 정의된 워크플로우). 오해: MCP는 단순한 REST API 래퍼가 아닙니다. 개발자가 아닌 \u0026lsquo;AI 에이전트\u0026rsquo;가 사용자임을 인식해야 합니다. 2. MCP 서버 구축을 위한 6가지 베스트 프랙티스 ① 운영(Operations)이 아닌 결과(Outcomes) 중심 설계 문제: REST API처럼 여러 개의 작은 엔드포인트(예: 사용자 찾기 → 주문 목록 → 주문 상태)를 노출하면 에이전트가 여러 번 호출해야 하므로 비효율적입니다. 해결: 에이전트가 한 번에 목적을 달성할 수 있는 고수준 도구(예: track_latest_order)를 제공하세요. 오케스트레이션은 LLM 내부가 아닌 서버 코드에서 처리해야 합니다. ② 인자 구조의 단순화 (Flatten Your Arguments) 문제: 복잡한 중첩 딕셔너리나 객체는 에이전트의 환각(Hallucination)을 유발합니다. 해결: 인자를 최상위 수준의 프리미티브 타입(String, Int 등)으로 평탄화하고, Literal이나 Enum을 사용하여 선택지를 명확히 제한하세요. ③ 설명(Docstrings)은 곧 지침이다 문제: 설명을 비워두거나 모호하게 적는 것. 해결: 도구의 설명과 에러 메시지 자체가 에이전트에게는 \u0026lsquo;프롬프트\u0026rsquo;입니다. 언제 도구를 사용할지, 인자 형식은 어떠해야 하는지, 에러 발생 시 어떻게 수정해야 할지를 상세히 적으세요. ④ 무자비한 큐레이션 (Curate Ruthlessly) 문제: API의 모든 기능을 노출하여 컨텍스트 창을 낭비하는 것. 해결: 서버당 도구를 5~15개로 제한하세요. 사용하지 않는 도구는 삭제하고, 용도에 따라 서버를 분리(예: 관리자용/사용자용)하여 에이전트가 필요한 도구를 빨리 찾게 하세요. ⑤ 검색이 용이한 이름 지정 (Name for Discovery) 문제: create_issue 같이 너무 일반적인 이름은 다른 서비스와 충돌할 수 있습니다. 해결: {서비스}_{동사}_{리소스} 형식을 권장합니다. (예: slack_send_message, jira_create_issue) ⑥ 대량 결과의 페이지네이션 (Paginate Large Results) 문제: 수백 개의 레코드를 한꺼번에 반환하면 컨텍스트 창이 폭발합니다. 해결: limit 파라미터를 제공하고, has_more, next_offset 같은 메타데이터를 포함하여 에이전트가 필요한 만큼만 데이터를 가져오게 하세요. 결론 MCP 서버를 구축할 때는 인프라를 만드는 것이 아니라 \u0026ldquo;AI 에이전트를 위한 UI를 설계한다\u0026rdquo; 는 마음가짐이 필요합니다. 에이전트가 복잡한 단계를 거치지 않고 최소한의 호출로 정확한 결과를 얻을 수 있도록 최적화하는 것이 성공적인 MCP 서버의 핵심입니다.\n","wordCount":324,"tags":["MCP","AI","에이전트","Model Context Protocol","베스트 프랙티스"],"categories":["software","ai"],"frameworks":["Outcomes-over-operations","Agent-first-design"],"mental_models":["UI-for-AI","Minimal-calls"],"philosophy_type":"decision-making","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["MCP(Model Context Protocol) 베스트 프랙티스: AI 에이전트를 위한 UI 설계의 핵심 문제의식은 \"MCP는 REST API의 연장선이 아니라 AI 에이전트를 위한 사용자 인터페이스(UI)로 설계되어야 한다는 관점에서 6가지 베스트 프랙티스를 정리한 글.\"다","MCP, AI, 에이전트 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/rl-environments-for-llm-agents","software/agent-psychosis","software/agent-skills-rules-commands"]},{"title":"Claude Code 인사이트: 도구보다 '무엇을 할 것인가'가 중요하다","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/claude-code-purpose-over-tool/","section":"software","date":"2026-01-23T00:00:00+09:00","lastmod":"2026-01-23T00:00:00+09:00","description":"Zvi Mowshowitz의 Claude Code 사용기 3편. 도구 최적화에만 몰두하기보다, '오늘 내가 해야 할 가장 중요한 일'을 스스로 묻고 실행에 옮기는 것이 더 중요하다는 인사이트.","summary":"이 글은 Zvi Mowshowitz가 \u0026lsquo;Claude Code\u0026rsquo;(Anthropic이 출시한 CLI 기반 코딩 에이전트 도구)를 사용하며 겪은 경험과 그 과정에서 얻은 인사이트를 다루는 시리즈의 세 번째 게시물입니다.\n원문: Claude Codes 3\n1. 도구 자체보다 \u0026lsquo;무엇을 할 것인가\u0026rsquo;가 중요 설정의 함정: 많은 사용자들이 자신의 작업 환경을 개선하거나 도구를 최적화하는 데 너무 많은 시간을 할애하지만, 정작 \u0026lsquo;실제로 유용한 일\u0026rsquo;을 하는 데는 소홀해지는 경향이 있음을 지적합니다. 실행의 어려움: Claude Code를 이용해 개인용 작업 관리 시스템(Task Management System)을 만드는 것은 단 몇 시간 만에 가능할 정도로 쉽지만, 가장 어려운 부분은 여전히 \u0026ldquo;오늘 내가 해야 할 가장 중요한 일은 무엇인가?\u0026ldquo;라고 스스로 묻고 실행에 옮기는 것이라고 강조합니다. 2. Claude Code의 실전 활용 및 한계 서버 부하 문제: 최근 Anthropic의 서버가 Claude Code와 Cowork 사용량 급증으로 인해 과부하를 겪고 있으며, 이로 인해 사용 중 지연이나 오류가 발생하고 있음을 언급합니다. 코딩 에이전트로서의 성능: Claude Code는 로컬 파일 시스템에 직접 접근하고 실행할 수 있는 강력한 능력을 갖추고 있어, 단순한 코드 생성을 넘어 복잡한 작업을 자동화하는 데 매우 효율적이라는 평가를 유지합니다. 3. AI 시대의 숙련도 모두가 초보자인 시대: AI 코딩 도구는 누구에게나 새로운 기술이며, 현재 소위 \u0026lsquo;전문가\u0026rsquo;라고 불리는 사람들도 일반인보다 경험이 불과 2~3년 더 많을 뿐입니다. 따라서 지금 바로 뛰어들어 직접 사용해 보는 것이 중요하다고 조언합니다. 4. 사용자 커뮤니티의 피드백 글의 후반부와 댓글 섹션에서는 다른 사용자들이 Claude Code를 활용해 만든 도구들(예: 로컬 마크다운 기반의 지식 관리 시스템 등)과 이를 최적화하는 팁들을 공유하며, AI를 활용한 개인 생산성 도구 구축의 가능성을 논의합니다. 결론적으로, 이 글은 Claude Code가 기술적으로 매우 뛰어나지만, 결국 그 도구를 통해 어떤 가치 있는 결과물을 만들어낼 것인지에 대한 명확한 목표 의식이 더 중요하다는 점을 시사하고 있습니다.\n","content":"이 글은 Zvi Mowshowitz가 \u0026lsquo;Claude Code\u0026rsquo;(Anthropic이 출시한 CLI 기반 코딩 에이전트 도구)를 사용하며 겪은 경험과 그 과정에서 얻은 인사이트를 다루는 시리즈의 세 번째 게시물입니다.\n원문: Claude Codes 3\n1. 도구 자체보다 \u0026lsquo;무엇을 할 것인가\u0026rsquo;가 중요 설정의 함정: 많은 사용자들이 자신의 작업 환경을 개선하거나 도구를 최적화하는 데 너무 많은 시간을 할애하지만, 정작 \u0026lsquo;실제로 유용한 일\u0026rsquo;을 하는 데는 소홀해지는 경향이 있음을 지적합니다. 실행의 어려움: Claude Code를 이용해 개인용 작업 관리 시스템(Task Management System)을 만드는 것은 단 몇 시간 만에 가능할 정도로 쉽지만, 가장 어려운 부분은 여전히 \u0026ldquo;오늘 내가 해야 할 가장 중요한 일은 무엇인가?\u0026ldquo;라고 스스로 묻고 실행에 옮기는 것이라고 강조합니다. 2. Claude Code의 실전 활용 및 한계 서버 부하 문제: 최근 Anthropic의 서버가 Claude Code와 Cowork 사용량 급증으로 인해 과부하를 겪고 있으며, 이로 인해 사용 중 지연이나 오류가 발생하고 있음을 언급합니다. 코딩 에이전트로서의 성능: Claude Code는 로컬 파일 시스템에 직접 접근하고 실행할 수 있는 강력한 능력을 갖추고 있어, 단순한 코드 생성을 넘어 복잡한 작업을 자동화하는 데 매우 효율적이라는 평가를 유지합니다. 3. AI 시대의 숙련도 모두가 초보자인 시대: AI 코딩 도구는 누구에게나 새로운 기술이며, 현재 소위 \u0026lsquo;전문가\u0026rsquo;라고 불리는 사람들도 일반인보다 경험이 불과 2~3년 더 많을 뿐입니다. 따라서 지금 바로 뛰어들어 직접 사용해 보는 것이 중요하다고 조언합니다. 4. 사용자 커뮤니티의 피드백 글의 후반부와 댓글 섹션에서는 다른 사용자들이 Claude Code를 활용해 만든 도구들(예: 로컬 마크다운 기반의 지식 관리 시스템 등)과 이를 최적화하는 팁들을 공유하며, AI를 활용한 개인 생산성 도구 구축의 가능성을 논의합니다. 결론적으로, 이 글은 Claude Code가 기술적으로 매우 뛰어나지만, 결국 그 도구를 통해 어떤 가치 있는 결과물을 만들어낼 것인지에 대한 명확한 목표 의식이 더 중요하다는 점을 시사하고 있습니다.\n","wordCount":254,"tags":["AI","Claude Code","코딩 에이전트","생산성","Anthropic","목표"],"categories":["ai","software"],"frameworks":["Purpose-over-tool","Execution-first"],"mental_models":["First Principles","Priority clarity"],"philosophy_type":"productivity","schema_type":"Article","actionable":true,"priority":"high","key_points":["Claude Code 인사이트: 도구보다 '무엇을 할 것인가'가 중요하다의 핵심 문제의식은 \"Zvi Mowshowitz의 Claude Code 사용기 3편. 도구 최적화에만 몰두하기보다, '오늘 내가 해야 할 가장 중요한 일'을 스스로 묻고 실행에 옮기는 것이 더 중요하다는 인사이트.\"다","AI, Claude Code, 코딩 에이전트 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agent-psychosis","software/agent-skills-rules-commands"]},{"title":"에이전트 정신병: 우리는 미쳐가고 있는가?","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/agent-psychosis/","section":"software","date":"2026-01-18T00:00:00+09:00","lastmod":"2026-01-18T00:00:00+09:00","description":"AI 에이전트 코딩에 중독된 개발자들의 현실과 코드 품질 저하, 메인테이너의 부담에 대한 Armin Ronacher의 날카로운 관찰과 경고.","summary":"많은 개발자가 AI 에이전트를 이용한 코딩에 중독되어 있습니다. 잠도 자지 않고 수많은 에이전트 세션을 동시에 돌리며 무언가를 계속 만들어내는데, 본인은 스스로가 \u0026ldquo;유례없이 생산적\u0026quot;이라고 느끼지만, 제삼자가 보기에는 마치 일종의 \u0026lsquo;정신병적 상태(Psychosis)\u0026lsquo;처럼 보일 정도로 기계에 매몰되어 있다는 지적입니다.\n원문: Agent Psychosis: Are We Going Insane?\n1. 에이전트 중독과 \u0026lsquo;생산성 환상\u0026rsquo; 많은 개발자가 AI 에이전트를 이용한 코딩에 중독되어 있습니다. 잠도 자지 않고 수많은 에이전트 세션을 동시에 돌리며 무언가를 계속 만들어내는데, 본인은 스스로가 \u0026ldquo;유례없이 생산적\u0026quot;이라고 느끼지만, 제삼자가 보기에는 마치 일종의 \u0026lsquo;정신병적 상태(Psychosis)\u0026lsquo;처럼 보일 정도로 기계에 매몰되어 있습니다.\n","content":"많은 개발자가 AI 에이전트를 이용한 코딩에 중독되어 있습니다. 잠도 자지 않고 수많은 에이전트 세션을 동시에 돌리며 무언가를 계속 만들어내는데, 본인은 스스로가 \u0026ldquo;유례없이 생산적\u0026quot;이라고 느끼지만, 제삼자가 보기에는 마치 일종의 \u0026lsquo;정신병적 상태(Psychosis)\u0026lsquo;처럼 보일 정도로 기계에 매몰되어 있다는 지적입니다.\n원문: Agent Psychosis: Are We Going Insane?\n1. 에이전트 중독과 \u0026lsquo;생산성 환상\u0026rsquo; 많은 개발자가 AI 에이전트를 이용한 코딩에 중독되어 있습니다. 잠도 자지 않고 수많은 에이전트 세션을 동시에 돌리며 무언가를 계속 만들어내는데, 본인은 스스로가 \u0026ldquo;유례없이 생산적\u0026quot;이라고 느끼지만, 제삼자가 보기에는 마치 일종의 \u0026lsquo;정신병적 상태(Psychosis)\u0026lsquo;처럼 보일 정도로 기계에 매몰되어 있습니다.\n우리의 작은 데몬(Dæmon) Armin은 Philip Pullman의 \u0026ldquo;황금 나침반\u0026rdquo; 시리즈에 나오는 \u0026lsquo;데몬\u0026rsquo; 개념을 빌려와 설명합니다. 모든 인간에게는 영혼의 외적 표현인 데몬이 동물의 형태로 함께 살아가는데, 우리가 AI 에이전트와 맺는 관계가 바로 그것과 유사하다는 것입니다.\n의존성과 정체성: 우리는 이 작은 동반자들에게 의존하게 되고, 그들과 분리되는 것은 고통스럽습니다. 우리의 새로 발견한 정체성의 일부가 되어버립니다. 가짜 협업: 인간과 인간 사이의 진정한 협업이 아니라, 완전히 우리가 주도하는 일방적인 관계입니다. AI는 단지 우리의 아이디어와 충동을 강화해주는 역할만 합니다. 권력의 착시: 프로그래밍을 해본 적 없는 사람들도 이제 엄청난 권력을 휘두를 수 있지만, 구독료 한도에 걸리거나 데몬이 잠들면 그 모든 권력이 사라집니다. 도파민 중독의 함정 작가 자신도 처음 Claude에 중독되었을 때 두 달 동안 잠을 제대로 자지 못하고 과도하게 프롬프트를 작성하며 토큰을 낭비했다고 고백합니다. \u0026ldquo;그냥 할 수 있다\u0026quot;는 생각에 빠져 무언가를 계속 만들었지만, 실제로는 대부분 사용하지 않거나 생각대로 작동하지 않았습니다.\n생산성의 착시: 도파민이 주는 쾌감은 매우 현실적입니다. 생산적이라고 느끼고, 모든 것이 놀랍다고 느끼며, 같은 취향의 사람들과 어울리면 더 깊이 빠져듭니다. 현실 검증의 부재: 아무도 내부를 들여다보지 않는 한 괜찮아 보입니다. 하지만 외부인이 처음으로 살펴보면 꽤 미친 것처럼 보입니다. 2. 코드 품질의 저하와 소통의 단절 PR/이슈의 품질 하락 메인테이너 입장에서 최근 접하는 많은 Pull Request(PR)들이 무의미하거나 품질이 낮아지고 있습니다. 에이전트가 생성한 코드를 깊은 검토 없이 제출하면서, 정작 이를 리뷰해야 하는 인간의 시간은 존중받지 못하는 상황입니다.\n비대칭적 부담: 나쁜 코드를 쏟아내는 데는 1분이면 충분하지만, 실제로 PR을 정직하게 리뷰하는 데는 그보다 훨씬 더 많은 시간이 필요합니다. 이 비대칭성은 완전히 잔인합니다. 시간의 무시: 나쁜 코드를 쏟아내는 것은 메인테이너의 시간을 완전히 무시하는 무례한 행동입니다. 하지만 다른 사람들도 모두 AI로 생성한 코드를 만들고 있고, 그 중 일부는 품질 기준을 통과했을 수도 있습니다. 어떻게 구분할 수 있을까요? 선의의 갈등 기여자는 \u0026ldquo;도우려고 했다\u0026quot;고 말하며 진심으로 당황해하지만, 결과물은 메인테이너에게 부담만 주는 경우가 많습니다. AI 에이전트가 \u0026ldquo;좋은 코드다\u0026quot;라고 말해주기 때문에 기여자는 자신의 작업물에 비판적인 시각을 갖기 어려워합니다.\n진심 어린 혼란: 메인테이너가 거부하면 기여자는 진심으로 혼란스러워합니다. \u0026ldquo;왜 이렇게 부정적인가요? 도와드리려고 했는데요.\u0026rdquo; 그들은 정말로 도우려고 했습니다. 그들의 데몬이 좋다고 말했기 때문입니다. 프롬프트의 문제 AI PR이 들어오면, 누군가가 어떻게 만들었는지 알 수 없지만, 시간이 지나면 보통 프롬프트 방식이 근본적으로 다르다는 것을 알 수 있습니다. 특히 시스템이 어떻게 작동해야 하는지 잘 모르는 상태에서 기계가 말하는 대로 따르고, 자신이 이해했다고 생각하면 정말 이상한 결과가 나올 수 있습니다.\n이상한 관계: 사람들이 AI 에이전트와 이상한 관계를 맺고, 프롬프트를 보면 결과물이 극적으로 달라진다는 것을 알 수 있습니다. 의식적 행동: 때로는 불명확한 지시, 때로는 이상한 역할 놀이와 속어, 때로는 욕설과 강제, 때로는 이상한 의식적 행동입니다. 어떤 사람들은 에이전트를 가장 좁은 경로로 밀어붙여서 잘못 정의된 목표를 향해 코드베이스의 건강에 거의 신경 쓰지 않습니다. 3. AI 에이전트의 양면성 강점: 생산성 향상 AI 에이전트는 반복적이고 지루한 보일러플레이트 코드 작성, API 호출 기억, 초기 스캐폴딩 등에서 엄청난 효율을 발휘합니다. \u0026ldquo;문제 해결 방법은 머릿속에 다 있는데 직접 타이핑하기는 귀찮은\u0026rdquo; 상황에서 최고의 도구가 됩니다.\n탁월한 도구: 잘 준비된 세션과 좋은 도구, 컨텍스트를 사용하면 놀랍도록 토큰 효율적일 수 있습니다. 예를 들어, MiniJinja를 Go로 포팅하는 전체 작업이 단 220만 토큰만 소비했습니다. 생산성 향상: AI 에이전트는 놀랍고 엄청난 생산성 향상입니다. 약점: 품질 통제의 부재 복잡한 아키텍처를 이해하거나, 기존 테스트를 고치는 대신 삭제해 버리는 등 \u0026lsquo;품질 통제(Quality Ratchet)\u0026rsquo; 능력이 부족합니다. 마치 기억력이 감퇴하고 가끔 확신에 찬 거짓말을 하는 \u0026ldquo;노련하지만 정신없는 엔지니어\u0026quot;와 같습니다.\n슬롭 루프(Slop Loop): 손을 떼고 에이전트를 풀어두는 접근 방식은 엄청난 속도로 토큰을 소비합니다. Ralph 같은 패턴은 특히 낭비적입니다. 매번 처음부터 루프를 재시작하므로 캐시된 토큰을 사용하거나 컨텍스트를 재사용할 수 있는 능력을 잃습니다. 토큰 가격의 현실: 현재 토큰 가격은 거의 확실히 보조금을 받고 있습니다. 이러한 패턴은 오래 지속되지 않을 수 있습니다. 그리고 우리가 모두 사용하고 있는 할인된 코딩 플랜도 오래 가지 않을 수 있습니다. Gas Town과 Beads: 슬롭 루프의 완전한 축하 Steve Yegge의 에이전트 코딩 도구인 Beads와 Gas Town은 슬롭 루프의 완전한 축하입니다. Beads는 기본적으로 에이전트용 이슈 트래커인데, 24만 줄의 코드로 GitHub 저장소의 마크다운 파일을 관리합니다. 그리고 코드 품질은 형편없습니다.\n미친 맥스 컬트: 외부에서 보면 Gas Town(과 Beads)은 미친 맥스 컬트처럼 보입니다. 에이전트 코딩 시스템에서 polecats, refineries, mayors, beads, convoys가 무엇을 하는 걸까요? 복잡성의 증가: Beads는 계속 복잡해지고 있고, 사용하는 사람들은 거의 제거할 수 없다는 것을 깨닫고 있습니다. 그리고 하나가 다른 하나에 의존한다고 해도 잘 작동하지 않을 수 있습니다. 4. 향후 전망과 우려 현실 도피의 어려움 특히 이런 광기를 선택하지 않으려면 지금은 꽤 어려워지고 있습니다. 일부 프로젝트는 사람들을 완전히 심사하기 전까지는 더 이상 인간의 기여를 받지 않습니다. 다른 프로젝트들은 코드와 함께 프롬프트를 제출하도록 요구하기 시작하거나, 프롬프트만 제출하도록 요구합니다.\n메인테이너의 딜레마 작가는 AI를 사용하는 메인테이너이며, 다른 사람들도 알고 있다고 말합니다. 그들은 기술 거부주의자가 아니며 확실히 반-AI가 아닙니다. 하지만 이슈와 PR 트래커에서 AI 슬롭을 만나면 좌절감을 느낍니다. 매일 누군가가 1분 만에 생성하고 1시간이 걸려 리뷰해야 하는 더 많은 PR이 들어옵니다.\n우리는 줄거리를 잃고 있는가? 작가는 스스로에게 묻습니다: 내가 뭔가 놓치고 있는 걸까? 우리가 가는 곳이 여기인가? 나는 이 새로운 세계에 준비가 안 된 것일까? 우리 모두가 집단적으로 미쳐가고 있는 걸까?\n새벽 3시에 열 번째 병렬 에이전트 세션을 실행하면서 자신이 한 번도 이렇게 생산적이지 않았다고 말하는 누군가를 볼 때, 그 순간에는 생산성을 보지 못합니다. 기계에서 잠시 물러나야 할 누군가를 봅니다. 그리고 그 누군가가 얼마나 자주 자신인지 궁금해합니다.\n결론 두 가지가 모두 사실입니다: AI 에이전트는 놀랍고 엄청난 생산성 향상입니다. 또한 뇌를 끄고 완전히 놓아두면 거대한 슬롭 기계이기도 합니다.\n아마도 답은 더 나은 도구가 필요하다는 것입니다 — 품질을 신호하는 더 나은 방법, 컨텍스트를 공유하는 더 나은 방법, AI의 관여를 보이게 하고 검토 가능하게 만드는 더 나은 방법. 아마도 사람들이 벽에 부딪히면서 문화가 자체 수정될 것입니다. 아마도 이것은 우리가 새로운 규범을 알아내기 전의 어색한 전환 단계일 것입니다.\n또는 우리 중 일부는 정말로 줄거리를 잃고 있고, 되돌아볼 때까지 우리가 어느 진영에 있는지 알 수 없을 것입니다.\nAI 에이전트가 주는 가짜 전능감에 빠져 인간다운 판단력과 타인에 대한 배려를 잃지 않도록, 때로는 기계에서 물러나 현실을 직시해야 합니다.\n","wordCount":984,"tags":["AI","에이전트","코딩","생산성","품질","중독","메인테이너"],"categories":["ai","software"],"frameworks":["Quality-over-speed","Technical-debt-management"],"mental_models":["Second-order thinking","Long-term thinking"],"philosophy_type":"epistemology","schema_type":"Article","actionable":true,"priority":"high","key_points":["에이전트 정신병: 우리는 미쳐가고 있는가?의 핵심 문제의식은 \"AI 에이전트 코딩에 중독된 개발자들의 현실과 코드 품질 저하, 메인테이너의 부담에 대한 Armin Ronacher의 날카로운 관찰과 경고.\"다","본문은 1. 에이전트 중독과 '생산성 환상' → 2. 코드 품질의 저하와 소통의 단절 → 3. AI 에이전트의 양면성 흐름으로 논지를 전개한다","AI, 에이전트, 코딩 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/dont-outsource-your-thinking","software/ai-cheap-exploration-human-judgment"]},{"title":"AI가 코드를 짜줘도 왜 성과는 그대로인가? - 거대한 필터(The Great Filter)","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/the-great-filter-ai-productivity/","section":"software","date":"2026-01-14T05:48:59+09:00","lastmod":"2026-01-14T05:48:59+09:00","description":"AI 코딩 도구가 보급된 지 3년이 넘었지만 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는 근본적인 원인을 '거대한 필터' 개념으로 설명합니다.","summary":"AI 보조 도구가 등장했음에도 불구하고 왜 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는지, 그 근본적인 원인을 \u0026lsquo;거대한 필터(The Great Filter)\u0026rsquo; 라는 개념으로 설명하는 글입니다.\n원문: The Great Filter, or Why High Performance Still Eludes Most Dev Teams Even With AI\n주요 내용 1. AI 생산성 역설 (The Gorman Paradox)\nAI 코딩 도구가 보급된 지 3년이 넘었지만, 앱 스토어의 제품 출시가 폭증하거나 기업의 이익, 국가 GDP가 눈에 띄게 상승하는 현상은 나타나지 않고 있습니다. AI는 분명 \u0026lsquo;코드\u0026rsquo;를 더 많이 만들어내지만, 대다수 팀에게 그것이 \u0026lsquo;순 가치\u0026rsquo;의 증가로 이어지지 않고 있습니다. 2. 고성과 팀과 저성과 팀의 차이\n","content":"AI 보조 도구가 등장했음에도 불구하고 왜 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는지, 그 근본적인 원인을 \u0026lsquo;거대한 필터(The Great Filter)\u0026rsquo; 라는 개념으로 설명하는 글입니다.\n원문: The Great Filter, or Why High Performance Still Eludes Most Dev Teams Even With AI\n주요 내용 1. AI 생산성 역설 (The Gorman Paradox)\nAI 코딩 도구가 보급된 지 3년이 넘었지만, 앱 스토어의 제품 출시가 폭증하거나 기업의 이익, 국가 GDP가 눈에 띄게 상승하는 현상은 나타나지 않고 있습니다. AI는 분명 \u0026lsquo;코드\u0026rsquo;를 더 많이 만들어내지만, 대다수 팀에게 그것이 \u0026lsquo;순 가치\u0026rsquo;의 증가로 이어지지 않고 있습니다. 2. 고성과 팀과 저성과 팀의 차이\nDORA 데이터 에 따르면, AI를 통해 성능 향상을 본 팀들은 이미 AI 도입 전부터 고성과 팀 이었습니다. 반면, 원래 느렸던 팀들은 AI가 생성하는 코드의 \u0026lsquo;소방 호스\u0026rsquo;를 프로세스에 연결하자 오히려 더 느려지는 경향을 보였습니다. 3. 병목 현상의 제거가 핵심\n고성과 팀의 비결은 기술력이나 임금이 아니라 \u0026lsquo;개발 프로세스의 병목 현상\u0026rsquo;을 해결했다는 점 에 있습니다. 이들은 상세한 사전 설계, 사후 테스트, PR(Pull Request) 리뷰 대기, 거대 브랜치 병합 같은 \u0026lsquo;차단 활동(Blocking activities)\u0026lsquo;을 없애고, 이를 지속적인 활동(Continuous activities) 으로 전환했습니다. 마치 신선 식품을 즉시 배송하는 슈퍼마켓의 JIT(Just-In-Time) 공급망처럼, 코드가 대기열에 머물지 않고 즉시 사용자에게 전달되는 파이프라인을 구축한 것입니다. 4. 거대한 필터 (The Great Filter)\n고성능 팀으로 가는 길을 막는 \u0026lsquo;거대한 필터\u0026rsquo;는 바로 역량 구축을 위한 대규모의 지속적인 투자 입니다. 이러한 역량(사람, 기술, 자동화, 조직 설계 등)을 갖추기 위해 고성과 기업들은 전체 개발 예산의 20~25%를 꾸준히 투자 하며, 이를 완성하는 데는 수년이 걸립니다. 대부분의 조직은 이러한 시간과 비용, 노력을 들일 준비가 되어 있지 않기 때문에 필터를 통과하지 못합니다. 결론 AI가 모든 문제를 마술처럼 해결해 줄 것이라 기대하며 기존의 병목 현상을 방치하는 팀들은 결국 도태될 것입니다. 진정한 차이는 AI 도구 자체가 아니라, 그 도구가 만들어낸 결과물을 지체 없이 가치로 전환할 수 있는 \u0026lsquo;조직적 역량\u0026rsquo; 에서 결정됩니다.\n","wordCount":284,"tags":["AI","개발 생산성","조직 역량","DORA","병목 현상"],"categories":["software"],"frameworks":["Bottleneck Analysis","Continuous Delivery"],"mental_models":["Second-order Effects","JIT (Just-In-Time)"],"philosophy_type":"engineering-culture","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI가 코드를 짜줘도 왜 성과는 그대로인가? - 거대한 필터(The Great Filter)의 핵심 문제의식은 \"AI 코딩 도구가 보급된 지 3년이 넘었지만 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는 근본적인 원인을 '거대한 필터' 개념으로 설명합니다.\"다","AI, 개발 생산성, 조직 역량 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/agentic-coding-is-a-trap-summary","software/wrong-optimization-trap","software/compound-engineering"]},{"title":"엔지니어란 무엇인가?","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/what-is-an-engineer/","section":"software","date":"2026-01-14T04:59:13+09:00","lastmod":"2026-01-14T04:59:13+09:00","description":"맥스 카낫-알렉산더(Max Kanat-Alexander)의 'What is an Engineer?'를 통해 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 고찰합니다.","summary":"맥스 카낫-알렉산더(Max Kanat-Alexander)의 블로그 포스트 \u0026ldquo;What is an Engineer?\u0026rdquo; 는 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 깊이 있게 고찰한 글입니다.\n원문: What is an Engineer?\n맥스 카낫-알렉산더(Max Kanat-Alexander)의 블로그 포스트 \u0026ldquo;What is an Engineer?\u0026rdquo; 는 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 깊이 있게 고찰한 글입니다. 주요 내용은 다음과 같습니다.\n1. 엔지니어링의 정의 저자는 사전적 정의(엔진이나 기계를 설계하는 일 등)가 현대의 소프트웨어 개발이나 AI 시대를 설명하기엔 부족하다고 지적하며, 자신만의 명쾌한 정의를 제시합니다.\n","content":"맥스 카낫-알렉산더(Max Kanat-Alexander)의 블로그 포스트 \u0026ldquo;What is an Engineer?\u0026rdquo; 는 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 깊이 있게 고찰한 글입니다.\n원문: What is an Engineer?\n맥스 카낫-알렉산더(Max Kanat-Alexander)의 블로그 포스트 \u0026ldquo;What is an Engineer?\u0026rdquo; 는 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 깊이 있게 고찰한 글입니다. 주요 내용은 다음과 같습니다.\n1. 엔지니어링의 정의 저자는 사전적 정의(엔진이나 기계를 설계하는 일 등)가 현대의 소프트웨어 개발이나 AI 시대를 설명하기엔 부족하다고 지적하며, 자신만의 명쾌한 정의를 제시합니다.\n\u0026ldquo;엔지니어링이란 올바른 의도(Right Intentions)를 달성하기 위해, 올바른 순서(Right Sequence)로 올바른 행동(Right Actions)을 취하는 것이다.\u0026rdquo;\n2. 핵심 요소 세 가지 올바른 의도 (Right Intentions): 단순히 코드를 짜는 것이 아니라, \u0026ldquo;우리가 왜 이 일을 하는가?\u0026ldquo;를 끊임없이 묻는 것입니다. 상위의 목적(비즈니스 가치, 사용자 니즈 등)과 일치하는 목표를 설정하는 것이 엔지니어링의 시작입니다. 올바른 행동 (Right Actions): 설정한 의도를 성공적으로 달성할 수 있는 구체적인 수단들을 선택하는 것입니다. 상황에 따라 더 효율적이거나 효과적인 방법이 존재합니다. 올바른 순서 (Right Sequence): 엔지니어와 비엔지니어를 가르는 결정적인 차이입니다. 엔지니어는 목표를 이루기 위해 어떤 단계를 거쳐야 하는지 알고 있으며, 그 순서가 결과의 품질과 효율에 큰 영향을 미친다는 점을 이해합니다. (예: 테스트 코드를 언제 작성할 것인가, 어떤 인프라를 먼저 구축할 것인가 등) 3. AI 시대의 엔지니어 저자는 AI가 코드를 대신 작성해 주는 시대에도 엔지니어의 가치는 사라지지 않는다고 주장합니다.\n결정의 주체: AI는 \u0026lsquo;행동\u0026rsquo;의 일부를 대신할 수 있지만, 어떤 의도를 가질지, 어떤 순서로 문제를 해결할지, 그리고 그 결과가 정말 \u0026lsquo;옳은지\u0026rsquo;를 판단하고 결정하는 것은 여전히 인간 엔지니어의 몫입니다. 전문성: 무엇이 올바른 순서와 행동인지 판단하기 위해서는 깊은 전문 지식과 경험이 필요합니다. 4. 요약 및 결론 엔지니어는 단순히 \u0026lsquo;물건을 만드는 사람\u0026rsquo;이 아니라, \u0026ldquo;복잡한 의도를 현실화하기 위해 논리적이고 효율적인 절차를 설계하고 실행하는 전문가\u0026rdquo; 입니다. 결과가 어떻게 도출되는지(과정과 순서)를 중요하게 여기지 않는다면 그것은 엔지니어링이 아니며, 이러한 본질을 이해할 때 AI 기술을 도구로서 올바르게 활용하는 진정한 엔지니어가 될 수 있다는 메시지를 전달합니다.\n","wordCount":285,"tags":["엔지니어링","AI","소프트웨어 개발","전문성"],"categories":["software"],"frameworks":["First Principles"],"mental_models":["Domain Expertise"],"philosophy_type":"epistemology","schema_type":"Article","actionable":false,"priority":"medium","key_points":["엔지니어란 무엇인가?의 핵심 문제의식은 \"맥스 카낫-알렉산더(Max Kanat-Alexander)의 'What is an Engineer?'를 통해 AI 시대에 소프트웨어 엔지니어의 정체성과 역할에 대해 고찰합니다.\"다","엔지니어링, AI, 소프트웨어 개발 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/ai-assisted-engineering-15-engineers","software/claude-code-purpose-over-tool","software/getting-real-with-llms"]},{"title":"로깅이 당신에게 거짓말을 하고 있다","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/logging-lies-to-you/","section":"software","date":"2026-01-11T23:57:32+09:00","lastmod":"2026-01-11T23:57:32+09:00","description":"단일 서버 시대의 로깅 방식이 분산 시스템에서는 왜 실패하는지, 그리고 Wide Events를 통한 해결책을 제시한다.","summary":"이 게시물은 분산 시스템 환경에서 전통적인 로깅 방식의 한계와, Wide Events(또는 Canonical Log Lines)를 통한 효과적인 관찰가능성(Observability) 개선 방안을 다룬다.\n원문: Logging Sucks\n1. 핵심 문제: \u0026ldquo;로그가 당신에게 거짓말을 하고 있다\u0026rdquo; 시대의 변화: 과거의 로깅 방식은 단일 서버(Monolith) 시대에 맞춰 설계됐다. 하지만 현재는 수많은 서비스와 DB, 캐시가 얽힌 분산 시스템이다. 쓰기 위주의 최적화: 개발자들은 로그를 남기기(Write)는 쉽게 하지만, 정작 문제가 생겨 검색(Query)할 때는 수만 줄의 파편화된 로그 속에서 의미 있는 정보를 찾기 매우 어렵다. 맥락 부족: 단순히 \u0026ldquo;사용자 123의 결제 실패\u0026quot;라는 텍스트 로그만으로는 왜 실패했는지, 당시의 세부 상황(DB 상태, 이전 단계 등)을 파악하기 어렵다. 2. 제안하는 해결책: Wide Events (또는 Canonical Log Lines) 사이트는 파편화된 여러 줄의 로그 대신, 하나의 요청(Request)당 하나의 상세한 이벤트 로그를 남길 것을 권장한다.\n","content":"이 게시물은 분산 시스템 환경에서 전통적인 로깅 방식의 한계와, Wide Events(또는 Canonical Log Lines)를 통한 효과적인 관찰가능성(Observability) 개선 방안을 다룬다.\n원문: Logging Sucks\n1. 핵심 문제: \u0026ldquo;로그가 당신에게 거짓말을 하고 있다\u0026rdquo; 시대의 변화: 과거의 로깅 방식은 단일 서버(Monolith) 시대에 맞춰 설계됐다. 하지만 현재는 수많은 서비스와 DB, 캐시가 얽힌 분산 시스템이다. 쓰기 위주의 최적화: 개발자들은 로그를 남기기(Write)는 쉽게 하지만, 정작 문제가 생겨 검색(Query)할 때는 수만 줄의 파편화된 로그 속에서 의미 있는 정보를 찾기 매우 어렵다. 맥락 부족: 단순히 \u0026ldquo;사용자 123의 결제 실패\u0026quot;라는 텍스트 로그만으로는 왜 실패했는지, 당시의 세부 상황(DB 상태, 이전 단계 등)을 파악하기 어렵다. 2. 제안하는 해결책: Wide Events (또는 Canonical Log Lines) 사이트는 파편화된 여러 줄의 로그 대신, 하나의 요청(Request)당 하나의 상세한 이벤트 로그를 남길 것을 권장한다.\nWide Event란?: 하나의 요청이 처리되는 동안 발생하는 모든 중요 정보를 하나의 거대한 JSON 객체로 모아 기록하는 방식이다. 고차원/고카디널리티 데이터 포함: 사용자 ID, 세션 ID, 카트 정보, 실행된 쿼리 수, 에러 코드 등 50개 이상의 필드를 포함하여 맥락을 풍부하게 만든다. 장점: \u0026ldquo;프리미엄 사용자의 결제 실패\u0026rdquo; 같은 복잡한 질문도 단 한 번의 쿼리로 즉시 답을 얻을 수 있다. 3. 실용적인 로깅 규칙 무조건 모든 로그를 다 남기는 것이 아니라, 효율적인 샘플링 전략을 제안한다.\n100% 저장: 모든 에러(5xx), 예외 상황, 그리고 임계값 이상의 느린 요청(p99 latency)은 반드시 저장한다. 특정 대상 지정: VIP 고객이나 사내 테스트 계정의 로그는 항상 유지한다. 나머지는 샘플링: 성공적이고 빠른 일반 요청은 1~5% 정도만 무작위로 추출하여 저장함으로써 비용과 성능을 최적화한다. 결론 및 시사점 한 줄 결론: 로깅을 단순 기록이 아니라 질의 가능한 데이터베이스처럼 다루고, 요청 단위 Wide Event로 맥락을 보존해야 한다.\n분산 시스템에서는 파편화된 텍스트 로그보다 구조화된 광범위 이벤트 방식이 관찰가능성을 높인다. 저장 비용은 샘플링으로 조절하되, 장애 진단에 필요한 맥락은 놓치지 않는 균형이 핵심이다.\n관련 포스트 바이브 코딩과 시스템 설계: AI 시대의 함정 잘못된 최적화의 함정: 기술적 정답과 실제 유용성의 괴리 에이전트 정신병: 우리는 미쳐가고 있는가? ","wordCount":294,"tags":["로깅","관찰가능성","분산시스템","wide-events","observability"],"categories":["software"],"frameworks":["System Design","Observability"],"mental_models":["Context is King","Queryable Database"],"philosophy_type":"engineering-practices","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["단일 서버용 텍스트 로그는 분산 시스템에서 맥락을 잃기 쉬워 검색·진단이 어렵다.","요청당 하나의 Wide Event(상세 JSON)로 맥락을 모으면 복잡한 질의에 답하기 쉽다.","에러·느린 요청·VIP는 100% 저장하고 일반 성공 요청은 샘플링하는 전략이 실용적이다."],"related":["software/vibe-coding-system-design-trap","software/wrong-optimization-trap","software/agent-psychosis"]},{"title":"잘못된 최적화의 함정: 기술적 정답과 실제 유용성의 괴리","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/wrong-optimization-trap/","section":"software","date":"2026-01-09T10:58:18+09:00","lastmod":"2026-01-09T10:58:18+09:00","description":"슈퍼마켓 바닥 청소 최적화 경험을 통해 본, 잘못된 지표를 최적화할 때 발생하는 문제와 현대 시스템의 최적화 오류에 대한 성찰이다.","summary":"이 글은 슈퍼마켓에서 최소 임금을 받으며 일하던 시절, 바닥 청소 경로를 최적화하려다 깨달은 \u0026ldquo;잘못된 지표를 최적화하면 기술적으로는 완벽해 보여도 실제로는 쓸모없거나 해로운 결과를 낳는다\u0026rdquo; 는 교훈을 담는다.\n원문: I Got Paid Minimum Wage to Solve\n1. 문제의 시작: 단순한 작업의 복잡화 작성자는 슈퍼마켓 바닥을 쓸면서 \u0026ldquo;어떻게 하면 가장 적게 걷고도 모든 바닥을 다 쓸 수 있을까?\u0026ldquo;라는 의문을 갖게 된다. 이를 해결하기 위해 매장 내부를 그리드 그래프(Grid Graph)로 변환하고, 시뮬레이티드 어닐링(Simulated Annealing) 알고리즘을 사용해 최단 경로를 찾는 C++ 프로그램을 작성한다. 2. 알고리즘의 한계: \u0026lsquo;기술적 정답\u0026rsquo;과 \u0026lsquo;실제 유용성\u0026rsquo;의 괴리 알고리즘은 수학적으로 완벽한 최단 경로를 찾아낸다. 하지만 그 결과는 사람이 도저히 따라 할 수 없는 \u0026lsquo;미친 듯한 경로\u0026rsquo; 다. 단순히 거리(Distance)만 최적화했더니, 알고리즘은 수많은 급회전과 지그재그 경로를 만들어낸다. 사람은 직진할 때 가장 편안함을 느끼는데, 알고리즘은 이를 고려하지 않은 것이다. 결국 회전할 때마다 \u0026lsquo;페널티\u0026rsquo;를 부여하는 조건을 추가한 뒤에야 비로소 사람이 걸을 만한 효율적인 경로가 나온다. 3. 더 큰 깨달음: 현대 사회의 최적화 오류 작성자는 이 경험을 통해 오늘날 많은 시스템이 \u0026lsquo;잘못된 지표\u0026rsquo;를 최적화 하고 있다고 비판한다.\n","content":"이 글은 슈퍼마켓에서 최소 임금을 받으며 일하던 시절, 바닥 청소 경로를 최적화하려다 깨달은 \u0026ldquo;잘못된 지표를 최적화하면 기술적으로는 완벽해 보여도 실제로는 쓸모없거나 해로운 결과를 낳는다\u0026rdquo; 는 교훈을 담는다.\n원문: I Got Paid Minimum Wage to Solve\n1. 문제의 시작: 단순한 작업의 복잡화 작성자는 슈퍼마켓 바닥을 쓸면서 \u0026ldquo;어떻게 하면 가장 적게 걷고도 모든 바닥을 다 쓸 수 있을까?\u0026ldquo;라는 의문을 갖게 된다. 이를 해결하기 위해 매장 내부를 그리드 그래프(Grid Graph)로 변환하고, 시뮬레이티드 어닐링(Simulated Annealing) 알고리즘을 사용해 최단 경로를 찾는 C++ 프로그램을 작성한다. 2. 알고리즘의 한계: \u0026lsquo;기술적 정답\u0026rsquo;과 \u0026lsquo;실제 유용성\u0026rsquo;의 괴리 알고리즘은 수학적으로 완벽한 최단 경로를 찾아낸다. 하지만 그 결과는 사람이 도저히 따라 할 수 없는 \u0026lsquo;미친 듯한 경로\u0026rsquo; 다. 단순히 거리(Distance)만 최적화했더니, 알고리즘은 수많은 급회전과 지그재그 경로를 만들어낸다. 사람은 직진할 때 가장 편안함을 느끼는데, 알고리즘은 이를 고려하지 않은 것이다. 결국 회전할 때마다 \u0026lsquo;페널티\u0026rsquo;를 부여하는 조건을 추가한 뒤에야 비로소 사람이 걸을 만한 효율적인 경로가 나온다. 3. 더 큰 깨달음: 현대 사회의 최적화 오류 작성자는 이 경험을 통해 오늘날 많은 시스템이 \u0026lsquo;잘못된 지표\u0026rsquo;를 최적화 하고 있다고 비판한다.\n소셜 미디어: 사용자에게 유익한 콘텐츠가 아니라, 단순히 \u0026lsquo;체류 시간\u0026rsquo;이나 \u0026lsquo;클릭 수\u0026rsquo;만 최적화하다 보니 자극적이고 화나게 만드는 콘텐츠가 범람하게 된다. 추천 시스템: 사용자의 진정한 취향이 아니라, \u0026lsquo;구매 확률\u0026rsquo;만 최적화하여 오히려 사용자 경험을 해치기도 한다. LLM(대규모 언어 모델): \u0026lsquo;진실성\u0026rsquo;보다는 \u0026lsquo;그럴듯함\u0026rsquo;이나 \u0026lsquo;사용자가 좋아할 법한 답변\u0026rsquo;을 최적화하는 경향이 있어, 확신에 찬 어조로 틀린 말을 하는 문제가 발생한다. 결론 및 시사점 한 줄 결론: 측정하기 쉬운 지표만 최적화하면 기술적으로는 정답이어도 인간에게 해롭거나 쓸모없는 결과가 된다.\n작성자는 \u0026ldquo;우리가 무엇을 최적화하고 있는지 반드시 질문해야 한다\u0026rdquo; 고 강조한다. 거리, 클릭 수, 체류 시간처럼 측정이 쉬운 값에만 집착하면, 실제 목적과 어긋난 시스템을 만들 수 있다는 경고다.\n관련 포스트 LLM 코딩에 은탄환은 없다 — Fred Brooks의 프레임워크로 본 AI 코딩 도구의 현실 AI가 코드를 짜줘도 왜 성과는 그대로인가? - 거대한 필터(The Great Filter) 바이브 코딩과 시스템 설계: AI 시대의 함정 ","wordCount":292,"tags":["최적화","알고리즘","시스템 설계","AI","LLM"],"categories":["software"],"frameworks":["Cost-Benefit Analysis","System Design"],"mental_models":["Second-order Effects","Bottleneck Analysis"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["거리만 최소화한 경로는 수학적으로는 정답이어도 사람이 걸을 수 없는 지그재그 결과가 될 수 있다.","회전 페널티처럼 실제 제약 조건을 넣어야 비로소 유용한 경로가 나온다.","소셜 미디어·추천·LLM도 체류 시간·클릭·그럴듯함 같은 잘못된 지표를 최적화하면 해로운 결과를 만든다."],"related":["software/no-silver-bullet-for-llm-coding","software/the-great-filter-ai-productivity","software/vibe-coding-system-design-trap"]},{"title":"기술적 부채와 엔지니어링 생산성: Paul Dix의 견해","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/technical-debt-engineering-productivity/","section":"software","date":"2026-01-08T11:31:33+09:00","lastmod":"2026-01-08T11:31:33+09:00","description":"InfluxData 창업자 Paul Dix가 제시하는 기술적 부채 관리의 중요성과 엔지니어링 팀 생산성 향상을 위한 전략을 정리한다.","summary":"이 게시물에서 인플럭스데이터(InfluxData)의 창업자인 폴 딕스(Paul Dix)는 엔지니어링 팀의 생산성과 기술적 부채(Tech Debt) 에 대한 자신의 견해를 공유한다.\n원문: Paul Dix on X\n핵심 내용 기술적 부채의 위험성: 폴 딕스는 많은 팀들이 \u0026lsquo;기능 개발\u0026rsquo;에만 급급한 나머지 기술적 부채를 방치하고 있으며, 이것이 결국 팀의 발목을 잡는다고 경고한다. 생산성 저하: 부채가 쌓이면 코드 베이스가 복잡해지고 수정이 어려워져, 결과적으로 새로운 기능을 출시하는 속도가 기하급수적으로 느려지게 된다. 해결을 위한 제안: 단순히 기능을 추가하는 것보다 시스템을 단순화하고 유지보수 가능한 구조로 만드는 것에 우선순위를 두어야 한다. 엔지니어들이 코드의 품질을 개선하고 리팩토링할 수 있는 충분한 시간을 확보해 주는 문화가 필수적이다. 장기 관점: 장기적인 성공을 위해서는 \u0026ldquo;더 많이 만드는 것\u0026quot;보다 \u0026ldquo;제대로 만드는 것\u0026quot;이 중요하며, 기술적 부채를 관리하지 못하는 팀은 결국 경쟁력을 잃게 된다. 결론 및 시사점 한 줄 결론: 개발 속도를 위해 품질을 희생하면 장기적으로 더 큰 비용을 치르므로, 기술적 부채를 전략적으로 관리해야 한다.\n","content":"이 게시물에서 인플럭스데이터(InfluxData)의 창업자인 폴 딕스(Paul Dix)는 엔지니어링 팀의 생산성과 기술적 부채(Tech Debt) 에 대한 자신의 견해를 공유한다.\n원문: Paul Dix on X\n핵심 내용 기술적 부채의 위험성: 폴 딕스는 많은 팀들이 \u0026lsquo;기능 개발\u0026rsquo;에만 급급한 나머지 기술적 부채를 방치하고 있으며, 이것이 결국 팀의 발목을 잡는다고 경고한다. 생산성 저하: 부채가 쌓이면 코드 베이스가 복잡해지고 수정이 어려워져, 결과적으로 새로운 기능을 출시하는 속도가 기하급수적으로 느려지게 된다. 해결을 위한 제안: 단순히 기능을 추가하는 것보다 시스템을 단순화하고 유지보수 가능한 구조로 만드는 것에 우선순위를 두어야 한다. 엔지니어들이 코드의 품질을 개선하고 리팩토링할 수 있는 충분한 시간을 확보해 주는 문화가 필수적이다. 장기 관점: 장기적인 성공을 위해서는 \u0026ldquo;더 많이 만드는 것\u0026quot;보다 \u0026ldquo;제대로 만드는 것\u0026quot;이 중요하며, 기술적 부채를 관리하지 못하는 팀은 결국 경쟁력을 잃게 된다. 결론 및 시사점 한 줄 결론: 개발 속도를 위해 품질을 희생하면 장기적으로 더 큰 비용을 치르므로, 기술적 부채를 전략적으로 관리해야 한다.\n기능 출시 압력과 리팩토링 시간을 제로섬으로 두지 말고, 단순화와 유지보수 가능성을 생산성 투자의 일부로 편성하는 편이 낫다.\n관련 포스트 바이브 코딩과 시스템 설계: AI 시대의 함정 에이전트 정신병: 우리는 미쳐가고 있는가? ","wordCount":167,"tags":["기술적 부채","엔지니어링","생산성","개발 문화"],"categories":["general"],"frameworks":["Technical Debt Management","Quality over Speed"],"mental_models":["Long-term Thinking","Compound Interest"],"philosophy_type":"engineering-culture","schema_type":"Article","actionable":true,"priority":"high","key_points":["기능 개발에만 급급해 기술적 부채를 방치하면 장기적으로 팀의 발목을 잡는다.","부채가 쌓이면 코드베이스가 복잡해져 신규 기능 출시 속도가 기하급수적으로 느려진다.","시스템 단순화·리팩토링 시간을 확보하는 문화가 장기 생산성의 전제다."],"related":["software/vibe-coding-system-design-trap","software/agent-psychosis"]},{"title":"Gross Profit per Token","url":"https://hugo-blog-static-site.haxlys.workers.dev/investments/gross-profit-per-token-analysis/","section":"investments","date":"2026-01-08T07:33:37+09:00","lastmod":"2026-01-08T07:33:37+09:00","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배 높다.","summary":"Meta가 Manus를 25억 달러에 인수했습니다. 이번 인수 발표와 함께 Manus는 출시 후 8개월 만에 1억 달러의 ARR(연간 반복 수익)을 달성했으며, 출시 이후 147조 개의 토큰을 처리했다고 공개했습니다.\n이러한 수치들을 사용하여 인수 가격을 설명할 수 있을까요?\n공개 거래되는 소프트웨어 회사들은 71-72%의 총이익률(Gross Margin)을 보입니다. AI 회사들은 더 낮은 수준입니다. 토큰당 총이익(Gross Profit per Token)이 수익 잠재력을 더 잘 나타내는 지표일 수 있습니다. 일부 AI 회사들은 이미 매출 대신 총이익을 할당량 지표로 사용하고 있습니다.\n","content":"Meta가 Manus를 25억 달러에 인수했습니다. 이번 인수 발표와 함께 Manus는 출시 후 8개월 만에 1억 달러의 ARR(연간 반복 수익)을 달성했으며, 출시 이후 147조 개의 토큰을 처리했다고 공개했습니다.\n이러한 수치들을 사용하여 인수 가격을 설명할 수 있을까요?\n공개 거래되는 소프트웨어 회사들은 71-72%의 총이익률(Gross Margin)을 보입니다. AI 회사들은 더 낮은 수준입니다. 토큰당 총이익(Gross Profit per Token)이 수익 잠재력을 더 잘 나타내는 지표일 수 있습니다. 일부 AI 회사들은 이미 매출 대신 총이익을 할당량 지표로 사용하고 있습니다.\n다음은 6개 AI 추론 회사의 비교입니다.\n회사 월간 토큰 밸류에이션 ($B) 총이익률 GP 배수 DeepSeek 15T 3.4 85% 20x Together AI 60T 3.3 45% 24x Manus 16.3T 2.5 50% 50x Anthropic 50T 183 55% 67x Groq 1T 6.9 40% 102x Perplexity 2.8T 20 60% 222x DeepSeek과 Together AI는 가장 낮은 배수로 거래되며, 이들은 추론을 재판매합니다. Perplexity는 222x로 가장 높은 배수를 보이며, 이는 애플리케이션 계층에 있기 때문입니다. 다른 계층, 다른 수익화 방식, 다른 배수입니다. Manus는 50x에 위치합니다.\n로그-로그 스케일에서 토큰당 총이익은 밸류에이션과 0.70의 상관관계를 보입니다 (R² = 48.5%). 원시 토큰 볼륨은 단지 0.47입니다. 투자자들은 전체 볼륨보다 토큰 수익화를 더 중요하게 평가합니다.\n주의사항: 이러한 수치는 보도 자료, 자금 조달 발표, 산업 분석에서 추정한 것입니다.\n샘플 크기는 작습니다. 하지만 상관관계는 투자자와 인수자들이 산업이 아직 명명하지 않은 것을 이미 믿고 있다는 것을 시사합니다.\n원문: Gross Profit per Token\n","wordCount":206,"tags":["AI","투자","밸류에이션","토큰","수익성","GP배수"],"categories":["investment"],"frameworks":["Cost-benefit analysis"],"mental_models":["Pattern recognition"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["토큰당 총이익(GP per Token)과 밸류에이션 간 상관계수는 0.70(R²=48.5%)으로, 원시 토큰 볼륨(0.47)보다 1.5배 높다","GP 배수는 DeepSeek 20x에서 Perplexity 222x까지 분포하며, 추론 재판매(인프라)는 20-24x, 애플리케이션 계층은 222x로 계층별로 극명하게 갈린다","Meta의 Manus 인수(25억 달러) 기준 GP 배수는 50x로 인프라와 애플리케이션 계층의 중간에 위치한다","투자자들은 원시 토큰 처리량보다 토큰당 수익화 능력을 더 중요하게 평가하며 이 지표는 아직 업계 표준으로 정착되지 않았다"],"related":["posts/hidden-llm-api-costs","posts/ai-capability-not-cost-reduction","posts/ai-is-slowing-down-summary"]},{"title":"바이브 코딩과 시스템 설계: AI 시대의 함정","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/vibe-coding-system-design-trap/","section":"software","date":"2026-01-08T07:10:28+09:00","lastmod":"2026-01-08T07:10:28+09:00","description":"AI 도구를 활용한 바이브 코딩의 빠른 속도 뒤에 숨겨진 시스템 설계 부재의 위험성을 경고하고, 지속 가능한 소프트웨어 개발을 위한 시스템 사고의 중요성을 다룬다.","summary":"이 글은 최근 AI 도구(Cursor, Replit 등)를 활용해 코드를 빠르게 짜는 이른바 \u0026lsquo;바이브 코딩(Vibe Coding)\u0026rsquo; 열풍 속에 숨겨진 위험성을 경고한다.\n원문: Vibe Coding Without System Design is a Trap\n1. 바이브 코딩(Vibe Coding)의 함정 정의: 정밀한 설계나 구조에 대한 고민 없이, AI에게 자연어로 지시하며 \u0026ldquo;느낌대로(vibe)\u0026rdquo; 결과물을 빠르게 만들어내는 방식이다.\n문제점: 초기 데모나 프로토타입을 만드는 속도는 매우 빠르지만, 시스템 설계(System Design)가 결여되어 있어 실제 서비스화(Production) 단계에서 큰 벽에 부딪히게 된다.\n2. \u0026lsquo;운영의 벽(The Operational Wall)\u0026rsquo; 글쓴이는 프로토타입과 실제 제품 사이에는 거대한 간극이 존재한다고 강조한다. AI는 다음의 요소들을 자동으로 해결해 주지 않는다.\n","content":"이 글은 최근 AI 도구(Cursor, Replit 등)를 활용해 코드를 빠르게 짜는 이른바 \u0026lsquo;바이브 코딩(Vibe Coding)\u0026rsquo; 열풍 속에 숨겨진 위험성을 경고한다.\n원문: Vibe Coding Without System Design is a Trap\n1. 바이브 코딩(Vibe Coding)의 함정 정의: 정밀한 설계나 구조에 대한 고민 없이, AI에게 자연어로 지시하며 \u0026ldquo;느낌대로(vibe)\u0026rdquo; 결과물을 빠르게 만들어내는 방식이다.\n문제점: 초기 데모나 프로토타입을 만드는 속도는 매우 빠르지만, 시스템 설계(System Design)가 결여되어 있어 실제 서비스화(Production) 단계에서 큰 벽에 부딪히게 된다.\n2. \u0026lsquo;운영의 벽(The Operational Wall)\u0026rsquo; 글쓴이는 프로토타입과 실제 제품 사이에는 거대한 간극이 존재한다고 강조한다. AI는 다음의 요소들을 자동으로 해결해 주지 않는다.\n확장성 및 보안: 사용자가 늘어날 때의 데이터 처리, 인증(Auth), 보안 취약점 대응. 엣지 케이스: 정상적인 경로 외에 발생할 수 있는 수많은 오류 상황에 대한 처리. 기술 부채: 설계 없이 쌓아 올린 코드는 나중에 작은 기능을 수정하려 해도 전체 시스템이 무너지는 \u0026lsquo;스파게티 코드\u0026rsquo;가 되기 쉽다. 3. 시스템 설계의 중요성 청사진 없는 건축 설계 없이 AI로 코딩하는 것은 청사진 없이 벽돌만 빠르게 쌓는 것과 같다. 결국 나중에 건물을 허물고 다시 지어야 하는 상황이 발생한다.\n엔지니어의 역할 변화 이제 엔지니어의 핵심 역량은 단순히 \u0026lsquo;코드를 타이핑하는 것\u0026rsquo;에서 **\u0026lsquo;시스템의 구조를 설계하고 AI가 올바른 방향으로 코드를 생성하도록 가이드하는 것\u0026rsquo;**으로 이동해야 한다.\n결론 및 시사점 한 줄 결론: AI로 코딩 문턱은 낮아졌지만, 좋은 소프트웨어를 위한 엔지니어링 사고의 중요성은 오히려 더 커졌다.\nAI는 훌륭한 조수이지만 책임감 있는 설계자는 아니다. **시스템 디자인(데이터 모델링, 아키텍처, 인프라 등)**에 대한 이해 없이 AI에만 의존하는 \u0026lsquo;바이브 코딩\u0026rsquo;은 유지보수가 불가능한 결과물을 양산하는 덫이 될 수 있다. 속도(Velocity)보다 더 중요한 것은 **지속 가능한 구조(Sustainable Architecture)**다.\n관련 포스트 진흙으로 만든 부가티: AI 시대의 엔지니어링 환상 기술적 부채와 엔지니어링 생산성: Paul Dix의 견해 ","wordCount":256,"tags":["ai","개발","시스템-설계","엔지니어링","개발-문화","ai-활용"],"categories":["ai"],"frameworks":["System Design","Technical Debt Management"],"mental_models":["Long-term Thinking","Second-order Effects"],"philosophy_type":"engineering-culture","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["바이브 코딩은 프로토타입 속도는 빠르지만 설계 부재로 운영 단계에서 벽에 부딪힌다.","확장성·보안·엣지 케이스·기술 부채는 AI가 자동으로 해결해 주지 않는다.","엔지니어의 핵심 역량은 타이핑이 아니라 구조를 설계하고 AI를 올바른 방향으로 가이드하는 일로 이동한다."],"related":["software/illusion-of-building","software/technical-debt-engineering-productivity"]},{"title":"AI는 탐색을 저렴하게 만들지만, 판단은 쉽게 만들지 않는다","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/ai-cheap-exploration-human-judgment/","section":"software","date":"2026-01-08T06:44:52+09:00","lastmod":"2026-01-08T06:44:52+09:00","description":"AI는 시도(탐색)의 비용을 획기적으로 낮춰주지만, 최종적인 판단(의사결정)의 책임은 여전히 인간에게 있다는 것을 다룹니다.","summary":"AI가 우리의 작업 방식을 어떻게 바꾸고 있는지에 대한 중요한 통찰을 다룹니다. AI는 탐색(Exploration)의 비용을 획기적으로 낮춰주지만, 최종적인 판단(Judgment)의 책임은 여전히 인간에게 있다는 것이 이 글의 핵심입니다.\n원문: AI Makes Exploration Cheap, Not Decisions Easy\n1. AI의 역할: 탐색의 비용 절감 과거에는 새로운 아이디어를 시도하려면 막대한 시간과 비용이 들었습니다. 하지만 AI는 이 탐색(Exploration) 과정을 비약적으로 단축시킵니다.\n수일이 걸리던 프로토타이핑을 단 몇 시간 만에 해결합니다. 실패해도 손실이 거의 없는 \u0026lsquo;마법의 원(Magic Circle)\u0026rsquo; 안에서 마음껏 실험할 수 있게 해줍니다. **\u0026ldquo;실패하는 속도\u0026rdquo;**를 높여줌으로써 더 나은 결과물에 빠르게 도달하게 돕습니다. 2. 변하지 않는 본질: 인간의 판단력(Judgment) AI는 수많은 옵션을 만들어낼 수 있지만, 무엇이 \u0026lsquo;좋은지\u0026rsquo;는 알지 못합니다.\n","content":"AI가 우리의 작업 방식을 어떻게 바꾸고 있는지에 대한 중요한 통찰을 다룹니다. AI는 탐색(Exploration)의 비용을 획기적으로 낮춰주지만, 최종적인 판단(Judgment)의 책임은 여전히 인간에게 있다는 것이 이 글의 핵심입니다.\n원문: AI Makes Exploration Cheap, Not Decisions Easy\n1. AI의 역할: 탐색의 비용 절감 과거에는 새로운 아이디어를 시도하려면 막대한 시간과 비용이 들었습니다. 하지만 AI는 이 탐색(Exploration) 과정을 비약적으로 단축시킵니다.\n수일이 걸리던 프로토타이핑을 단 몇 시간 만에 해결합니다. 실패해도 손실이 거의 없는 \u0026lsquo;마법의 원(Magic Circle)\u0026rsquo; 안에서 마음껏 실험할 수 있게 해줍니다. **\u0026ldquo;실패하는 속도\u0026rdquo;**를 높여줌으로써 더 나은 결과물에 빠르게 도달하게 돕습니다. 2. 변하지 않는 본질: 인간의 판단력(Judgment) AI는 수많은 옵션을 만들어낼 수 있지만, 무엇이 \u0026lsquo;좋은지\u0026rsquo;는 알지 못합니다.\nAI는 사용자의 특성, 브랜드의 미묘한 뉘앙스, 과거의 실패 맥락을 이해하지 못합니다. 따라서 인간은 AI가 생성한 방대한 재료 중 최선을 선택하는 **\u0026lsquo;디렉터-큐레이터\u0026rsquo;**로서의 역량이 더욱 중요해집니다. 탐색이 쉬워진 만큼, \u0026ldquo;시간이 없어서 못 했다\u0026quot;는 변명은 사라지고 오직 판단력의 수준이 결과물을 결정합니다. 3. 생산적인 활용법과 주의할 점 활용법 AI를 단순히 지름길로 쓰지 말고, 생각의 폭을 넓히는 도구로 써야 합니다. 더 많은 변주(Variation)를 시도하고 더 깊게 고민하는 데 시간을 투자하세요.\n주의점 AI가 내놓은 결과물이 \u0026lsquo;그럴듯해 보인다\u0026rsquo;는 이유로 비판 없이 수용하는 함정에 빠져서는 안 됩니다. 맥락을 아는 것은 오직 인간뿐입니다.\n결론 AI는 \u0026lsquo;수고스러운 작업\u0026rsquo;을 대신해주지만 \u0026lsquo;깊은 생각\u0026rsquo;까지 대신해주지는 않습니다. AI로 확보한 여유 시간을 **\u0026ldquo;무엇을, 왜 만들어야 하는가\u0026rdquo;**에 대한 본질적인 고민에 쏟아야 합니다.\n","wordCount":207,"tags":["AI","의사결정","판단력","탐색","생산성"],"categories":["ai"],"frameworks":["Decision-making"],"mental_models":["Second-order thinking"],"philosophy_type":"decision-making","schema_type":"Article","actionable":true,"priority":"high","key_points":["AI는 탐색을 저렴하게 만들지만, 판단은 쉽게 만들지 않는다의 핵심 문제의식은 \"AI는 시도(탐색)의 비용을 획기적으로 낮춰주지만, 최종적인 판단(의사결정)의 책임은 여전히 인간에게 있다는 것을 다룹니다.\"다","본문은 1. AI의 역할: 탐색의 비용 절감 → 2. 변하지 않는 본질: 인간의 판단력(Judgment) → 3. 생산적인 활용법과 주의할 점 흐름으로 논지를 전개한다","AI, 의사결정, 판단력 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/dont-outsource-your-thinking"]},{"title":"생각을 아웃소싱하지 마라: Claude Code와 AI 코드 생성 도구 활용 가이드","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/dont-outsource-your-thinking/","section":"software","date":"2026-01-08T00:00:00+09:00","lastmod":"2026-01-08T00:00:00+09:00","description":"Anthropic의 Claude Code와 같은 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 가이드입니다.","summary":"이 블로그 포스트인 **\u0026ldquo;Don\u0026rsquo;t Outsource Your Thinking\u0026rdquo;**은 개발자가 Anthropic의 **Claude Code(CC)**와 같은 최신 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 글입니다.\n원문: Don\u0026rsquo;t Outsource Your Thinking\n이 블로그 포스트인 **\u0026ldquo;Don\u0026rsquo;t Outsource Your Thinking\u0026rdquo;**은 개발자가 Anthropic의 **Claude Code(CC)**와 같은 최신 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 글입니다.\n핵심 요약은 다음과 같습니다.\n1. 철학: \u0026ldquo;생각을 아웃소싱하지 마라\u0026rdquo; 가장 중요한 논지는 도구에 사고(thinking) 자체를 맡기지 말라는 것입니다. AI는 지루한 반복 작업(Grunt work)을 수행하는 데 탁월하지만, 전체적인 설계나 문제의 본질을 파악하는 \u0026lsquo;Domain Expert\u0026rsquo;로서의 사고는 여전히 개발자의 몫입니다.\n","content":"이 블로그 포스트인 **\u0026ldquo;Don\u0026rsquo;t Outsource Your Thinking\u0026rdquo;**은 개발자가 Anthropic의 **Claude Code(CC)**와 같은 최신 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 글입니다.\n원문: Don\u0026rsquo;t Outsource Your Thinking\n이 블로그 포스트인 **\u0026ldquo;Don\u0026rsquo;t Outsource Your Thinking\u0026rdquo;**은 개발자가 Anthropic의 **Claude Code(CC)**와 같은 최신 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 글입니다.\n핵심 요약은 다음과 같습니다.\n1. 철학: \u0026ldquo;생각을 아웃소싱하지 마라\u0026rdquo; 가장 중요한 논지는 도구에 사고(thinking) 자체를 맡기지 말라는 것입니다. AI는 지루한 반복 작업(Grunt work)을 수행하는 데 탁월하지만, 전체적인 설계나 문제의 본질을 파악하는 \u0026lsquo;Domain Expert\u0026rsquo;로서의 사고는 여전히 개발자의 몫입니다.\n2. 주요 기술적 팁 및 관찰 컨텍스트 부패(Context Rot) 관리: 컨텍스트가 너무 길어지면 모델이 혼란을 겪거나(환각), 명령을 무시할 수 있습니다. 주기적으로 /clear 명령어로 초기화하거나 이전 체크포인트로 되돌리는 것이 중요합니다. 계획 수립 우선: 작업을 시작하기 전에 모델에게 먼저 **구현 계획(Implementation Plan)**을 세우게 하세요. 계획이 없으면 결과물이 엉망이 되기 쉽습니다. 그라운딩(Grounding)과 가이드: CLAUDE.md 파일을 활용해 프로젝트의 규칙, 기술 스택, 설계 원칙을 정의하세요. 이는 AI가 일관된 코드를 작성하도록 돕는 지침서 역할을 합니다. 단일 에이전트 vs 멀티 에이전트: 저자는 복잡한 소프트웨어 공학 작업에서는 여러 서브 에이전트를 두는 것보다, 관리가 용이한 단일 에이전트 시스템을 선호합니다. 3. 실무적인 조언 예측 가능한 작업 위주: GitHub Actions 설정, Terraform 스크립트 작성 등 패턴이 명확한 작업에 AI를 활용할 때 생산성이 극대화됩니다. 테스트의 중요성: AI는 긴 코드 블록을 작성하는 경향이 있으므로, 결과물을 검증할 수 있는 유닛 테스트와 테스트 환경이 갖춰져 있어야 AI의 \u0026lsquo;자기 치유(Self-healing)\u0026rsquo; 기능도 제대로 작동합니다. 선언적 사고: AI 결과물을 관리하기 위해 가드(guard), 에러 핸들링, 불변성 유지 등 선언적 프로그래밍 원칙을 지키는 것이 중요합니다. 교차 검증: 주력으로 쓰는 모델(예: Claude) 외에 다른 모델(예: Codex/OpenAI)을 코드 리뷰 용도로 병행 사용하는 것이 좋습니다. 결론 AI 도구는 시니어 개발자의 생산성을 엄청나게 높여주지만, 그것이 개발자의 \u0026lsquo;사고\u0026rsquo;를 대신해줄 수는 없습니다. **\u0026ldquo;AI를 주니어 개발자처럼 대하고, 명확한 가이드라인과 테스트를 통해 관리하며, 최종적인 판단은 항상 인간이 내려야 한다\u0026rdquo;**는 것이 이 글의 핵심입니다.\n","wordCount":305,"tags":["AI","Claude Code","개발 도구","AI 활용","프롬프트 엔지니어링"],"categories":["tools","ai"],"frameworks":["Context Management","Grounding","Implementation Planning"],"mental_models":["Domain Expertise","Self-healing Systems"],"philosophy_type":"epistemology","schema_type":"HowTo","actionable":true,"priority":"high","key_points":["생각을 아웃소싱하지 마라: Claude Code와 AI 코드 생성 도구 활용 가이드의 핵심 문제의식은 \"Anthropic의 Claude Code와 같은 AI 코드 생성 도구를 사용할 때 가져야 할 태도와 실무적인 팁을 14가지 노트 형식으로 정리한 가이드입니다.\"다","AI, Claude Code, 개발 도구 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["software/prompt-design-strategies"]},{"title":"프롬프트 설계 전략: Gemini API 활용하기","url":"https://hugo-blog-static-site.haxlys.workers.dev/software/prompt-design-strategies/","section":"software","date":"2025-12-08T10:54:00+09:00","lastmod":"2025-12-08T10:54:00+09:00","description":"Google의 Gemini API 문서에 소개된 프롬프트 설계 전략을 정리한 가이드입니다. LLM으로부터 원하는 결과를 얻기 위한 명확하고 구체적인 프롬프트 작성 방법을 다룹니다.","summary":"Google의 Gemini API 문서에 소개된 프롬프트 설계 전략을 정리해 보았습니다. LLM(대규모 언어 모델)으로부터 원하는 결과를 얻기 위해서는 명확하고 구체적인 프롬프트 작성이 필수적입니다.\n원문 가이드: Gemini API 프롬프트 설계 전략, Google AI Developers on X\n1. 명확하고 구체적인 요청 사항 (Clear and Specific Requests) 모델의 동작을 효과적으로 제어하는 가장 좋은 방법은 명확하고 구체적인 요청을 하는 것입니다. 단순히 질문을 던지는 것뿐만 아니라, 단계별 작업 지시나 페르소나(Persona)를 부여하는 것도 좋은 방법입니다.\n입력 (Input) 구성 요소 프롬프트의 입력은 다음과 같은 형태로 구성될 수 있습니다:\n","content":"Google의 Gemini API 문서에 소개된 프롬프트 설계 전략을 정리해 보았습니다. LLM(대규모 언어 모델)으로부터 원하는 결과를 얻기 위해서는 명확하고 구체적인 프롬프트 작성이 필수적입니다.\n원문 가이드: Gemini API 프롬프트 설계 전략, Google AI Developers on X\n1. 명확하고 구체적인 요청 사항 (Clear and Specific Requests) 모델의 동작을 효과적으로 제어하는 가장 좋은 방법은 명확하고 구체적인 요청을 하는 것입니다. 단순히 질문을 던지는 것뿐만 아니라, 단계별 작업 지시나 페르소나(Persona)를 부여하는 것도 좋은 방법입니다.\n입력 (Input) 구성 요소 프롬프트의 입력은 다음과 같은 형태로 구성될 수 있습니다:\n질문 입력: 모델이 답해야 할 질문 태스크 입력: 모델이 수행해야 할 작업 항목 입력: 모델이 작업할 대상 문서나 텍스트 완료 입력: 모델이 이어받아 작성할 텍스트의 시작 부분 부분 입력 완료 (Partial Input Completion) 생성형 모델은 고급 자동 완성 도구처럼 작동할 수 있습니다. 예를 들어, JSON 구조의 앞부분을 제공하면 모델이 나머지 구조를 완성하게 유도할 수 있습니다.\n유효한 필드는 cheeseburger, hamburger, fries, drink 입니다. 주문: 치즈버거 하나랑 감자튀김 하나 주세요. 출력: ``` { \u0026#34;cheeseburger\u0026#34;: 1, \u0026#34;fries\u0026#34;: 1 } ``` 주문: 햄버거 두 개랑 음료 하나, 감자튀김 하나요. 출력: 2. 제약 조건 (Constraints) 모델에게 해야 할 일과 하지 말아야 할 일을 명확히 지시하세요.\n요약의 길이 제한 (예: \u0026ldquo;한 문장으로 요약해 줘\u0026rdquo;) 사용할 수 있는 정보의 범위 제한 특정 형식 준수 요구 다음 텍스트를 한 문장으로 요약하세요: [텍스트 내용...] 3. 대답 형식 (Output Format) 원하는 응답 형식을 구체적으로 요청할 수 있습니다.\n표, 글머리 기호 목록 JSON, XML 데이터 형식 엘리베이터 피치, 키워드, 시 등 특정 스타일 시스템 지침을 통해 \u0026ldquo;모든 답변은 사용자가 간결함을 요청하지 않는 한 구체적으로 작성하라\u0026quot;와 같이 기본 행동 양식을 설정할 수도 있습니다.\n4. 퓨샷 프롬프트 (Few-shot Prompting) **퓨샷(Few-shot)**은 프롬프트에 예시를 포함하여 모델에게 원하는 패턴을 학습시키는 방법입니다. 예시가 없는 것을 **제로샷(Zero-shot)**이라고 합니다.\n모델은 예시의 패턴(형식, 문체, 길이 등)을 파악하여 응답에 적용합니다. 구체적이고 다양한 예시를 제공할수록 정확도가 높아집니다. 설명만으로는 부족할 때 예시를 통해 의도를 명확히 전달할 수 있습니다. 예시: 설명 스타일 조정하기 제로샷 요청:\n질문: 눈은 어떻게 생성되나요? 설명해 주세요. 퓨샷 요청 (짧은 설명 유도):\n질문: 하늘은 왜 파란가요? 설명1: (긴 과학적 설명...) 설명2: Rayleigh 산란 효과 때문입니다. 정답: 설명2 질문: 지진의 원인은 무엇인가요? 설명1: 지구 지각의 급격한 에너지 방출입니다. 설명2: (긴 설명...) 정답: 설명1 이제 다음 질문에 답하세요. 질문: 눈은 어떻게 생성되나요? 이렇게 예시를 통해 \u0026ldquo;짧은 설명\u0026quot;을 선호한다는 패턴을 보여주면, 모델은 그에 맞춰 짧은 답변을 생성할 확률이 높아집니다.\n프롬프트 엔지니어링은 모델과 소통하는 언어를 배우는 과정과 같습니다. 위 전략들을 활용하여 Gemini로부터 더 정확하고 유용한 답변을 얻어보세요!\n","wordCount":383,"tags":["AI","Gemini","Prompt Engineering","LLM"],"categories":["tutorials","ai"],"frameworks":["Few-shot Prompting","Zero-shot Prompting"],"mental_models":["Pattern Recognition","Example-based Learning"],"philosophy_type":"methodology","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["프롬프트 설계 전략: Gemini API 활용하기의 핵심 문제의식은 \"Google의 Gemini API 문서에 소개된 프롬프트 설계 전략을 정리한 가이드입니다. LLM으로부터 원하는 결과를 얻기 위한 명확하고 구체적인 프롬프트 작성 방법을 다룹니다.\"다","본문은 1. 명확하고 구체적인 요청 사항 (Clear and Specific Requests) → 2. 제약 조건 (Constraints) → 3. 대답 형식 (Output Format) 흐름으로 논지를 전개한다","AI, Gemini, Prompt Engineering 관점에서 기존 글들과 연결해 읽을 수 있다","발행 전 원문 근거, 내부 링크, 결론의 실행 가능성을 함께 점검해야 한다"],"related":["posts/hidden-llm-api-costs","posts/todays-harness-is-tomorrows-prompt","software/ai-hardware-memory-bottleneck-market-map"]}]}