<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>desty</title><description>개발자 desty의 블로그 &amp; 포트폴리오.</description><link>https://desty.github.io/</link><item><title>GPT‑6 Astra와 Sol, 어떤 작업에 나눠 쓸까</title><link>https://desty.github.io/blog/66-reasoning-effort-cost/</link><guid isPermaLink="true">https://desty.github.io/blog/66-reasoning-effort-cost/</guid><description>새 모델로 모두 바꿔야 할까, 익숙한 모델을 계속 써도 될까. Astra와 Sol의 공개 비교를 바탕으로 기존 작업은 유지하면서 새 모델의 성능과 비용을 확인하는 방법을 살펴본다.</description><pubDate>Sun, 06 Sep 2026 08:00:00 GMT</pubDate></item><item><title>Daybreak Blue로 보안 업무를 시작할 때 확인할 것</title><link>https://desty.github.io/blog/65-daybreak-blue/</link><guid isPermaLink="true">https://desty.github.io/blog/65-daybreak-blue/</guid><description>Daybreak Blue는 승인된 방어 보안 작업에 맞게 안전장치를 조정한 범용 모델 접근 등급이다. 일반 GPT와 무엇이 다르고 Red와는 어떻게 구분되는지, 기존 코드 리뷰를 근거 확인·패치 검증까지 연결하려면 어떤 지침과 실행 환경이 필요한지 살펴본다.</description><pubDate>Sun, 06 Sep 2026 07:10:00 GMT</pubDate></item><item><title>GPT‑6에서 AGI를 떠올리게 되는 경험들</title><link>https://desty.github.io/blog/64-agi-experience/</link><guid isPermaLink="true">https://desty.github.io/blog/64-agi-experience/</guid><description>불완전한 설명에서 설계 방향을 찾고, 여러 도구를 오가며 결과를 완성하는 경험은 AI에게 맡길 일의 범위를 바꾼다. AGI의 범용성·숙련도·자율성을 구분하고, GPT‑6의 공개 사례와 하네스 재설계 예제로 그 변화의 의미를 살펴본다. 기존 모델 사용자가 바꿔볼 지시문과 실행 구조, 개선을 확인할 기준도 정리했다.</description><pubDate>Sun, 06 Sep 2026 07:00:00 GMT</pubDate></item><item><title>GPT‑6 Astra 실전 가이드: 코딩 성능, 사용량, 설정과 전환 방법</title><link>https://desty.github.io/blog/62-gpt-6-astra/</link><guid isPermaLink="true">https://desty.github.io/blog/62-gpt-6-astra/</guid><description>GPT‑6 Astra의 코딩 평가를 기존 모델과 비교하고, Chat·Work·Codex의 접근 조건과 사용량을 구분했다. Medium부터 추론 수준을 고르는 방법, 긴 작업의 컨텍스트 관리, AGENTS.md·Skills 수정, 실전 요청과 작업 중단 대응까지 기존 사용자의 전환 순서로 정리했다.</description><pubDate>Sat, 05 Sep 2026 09:00:00 GMT</pubDate></item><item><title>웹페이지를 AI 도구로 바꾸면 3천 달러 — OpenAI WebMCP 챌린지</title><link>https://desty.github.io/blog/61-webmcp-challenge/</link><guid isPermaLink="true">https://desty.github.io/blog/61-webmcp-challenge/</guid><description>OpenAI가 10일짜리 WebMCP 챌린지를 열었다. 상위 10개 제출작에는 각각 3천 달러와 ChatGPT Pro 1년 이용권이 주어진다. WebMCP는 에이전트가 화면을 보고 버튼을 추측하는 대신, 웹페이지가 자신의 기능을 구조화된 도구로 직접 제공하게 한다. 기존 MCP와 무엇이 다른지, OpenAI가 내부 평가 작업에 어떻게 쓰고 있는지, 아직 남은 브라우저 지원과 보안 한계까지 살펴봤다.</description><pubDate>Sun, 30 Aug 2026 21:21:00 GMT</pubDate></item><item><title>앤트로픽의 ELI5 스킬: 코드를 고치기 전에 그림으로 이해하기</title><link>https://desty.github.io/blog/60-eli5-visual-explainer/</link><guid isPermaLink="true">https://desty.github.io/blog/60-eli5-visual-explainer/</guid><description>Claude Code 팀의 Thariq Shihipar가 앤트로픽 내부에서 자주 쓴다는 ELI5 스킬을 공개했다. /eli5 뒤에 대상을 적으면, 관련 코드를 읽고 큰 그림과 적은 글로 구성한 HTML 설명 자료를 만든다. 공개된 것은 완성된 플러그인보다 짧은 작업 패턴에 가깝다. 이 단순한 패턴이 코드 이해, 설계 검토, 장애 분석에서 어떤 검토 단계를 추가하는지 살펴봤다.</description><pubDate>Sun, 23 Aug 2026 18:00:00 GMT</pubDate></item><item><title>Vercel fx 분석: 실행 파일 하나로 배포하는 코딩 에이전트</title><link>https://desty.github.io/blog/59-vercel-fx-native-agent/</link><guid isPermaLink="true">https://desty.github.io/blog/59-vercel-fx-native-agent/</guid><description>Vercel Labs가 Zig로 만든 코딩 에이전트 fx를 공개했다. macOS arm64 실행 파일은 6.43MB이고 별도 Node.js나 Python 런타임 없이 시작한다. 크기 자체보다 중요한 것은 어디에 쓰려는가다. fx는 사람이 터미널에서 오래 쓰는 CLI뿐 아니라, 평가 시스템과 샌드박스가 작업마다 새로 띄우는 프로세스, ACP 서버, 브라우저용 WebAssembly 코어로 설계됐다. 배포 크기와 시작 시간의 의미, 네이티브·WASM의 책임 분리, 현재 보안 경계와 적합한 용도를 살펴봤다.</description><pubDate>Sun, 23 Aug 2026 09:00:00 GMT</pubDate></item><item><title>OpenSandbox 코드 분석: AI 에이전트의 실행 환경을 어떻게 통일했나</title><link>https://desty.github.io/blog/58-opensandbox-agent-runtime/</link><guid isPermaLink="true">https://desty.github.io/blog/58-opensandbox-agent-runtime/</guid><description>OpenSandbox 저장소를 받아 API 명세부터 FastAPI 서버, execd, Docker·Kubernetes 런타임, 네트워크 제어와 Credential Vault까지 살펴봤다. 단순히 컨테이너를 띄우는 도구라기보다, 서로 다른 실행 환경을 하나의 API로 다루기 위한 기반에 가깝다. 코드가 실제로 어떻게 나뉘어 있는지, 보안 기능은 어디까지 제공하는지, 도입 전에 확인할 제약은 무엇인지 정리했다.</description><pubDate>Sat, 22 Aug 2026 11:00:00 GMT</pubDate></item><item><title>Grok 4.6은 한 달 만에 +5점, Gemini 3.7 Flash는 3주 만에 나왔다 — 갈아타기 전에 확인할 것들</title><link>https://desty.github.io/blog/57-gemini-grok-migration/</link><guid isPermaLink="true">https://desty.github.io/blog/57-gemini-grok-migration/</guid><description>8월 둘째 주에 새 모델이 둘 나왔다. 12일에 Grok 4.6, 13일에 Gemini 3.7 Flash. 벤치마크 표는 각자 화려한데, 갈아타는 입장에서 진짜 확인할 건 표 바깥에 있다. Gemini의 반값 가격은 12월 31일까지고 1월 1일부터는 3.6 Flash와 같은 가격으로 돌아온다. Grok은 기본 단가를 동결했다고 보도됐지만 캐시 읽기 단가가 67% 올랐고, 이 모델이 겨냥한 장시간 에이전트 워크로드가 바로 캐시 읽기를 제일 많이 쓰는 워크로드다. 직전 버전 대비 뭐가 좋아졌는지, 모델명을 바꾸기 전에 코드와 요금표에서 뭘 점검해야 하는지 — xhigh의 조용한 작동 개시, 사라진 minimal, 200K 요금 경계, 지워야 할 파라미터 다섯 개까지 정리했다.</description><pubDate>Sun, 16 Aug 2026 15:10:00 GMT</pubDate></item><item><title>xAI의 24시간 AI 팀원 Grok Bot — 편한 이유와 위험한 이유가 같다</title><link>https://desty.github.io/blog/56-grok-bot-shared-computer/</link><guid isPermaLink="true">https://desty.github.io/blog/56-grok-bot-shared-computer/</guid><description>8월 11일, xAI가 상주형 AI 팀원 Grok Bot을 베타로 내놨다. 슬로건은 &apos;Bots have their own computer&apos;인데 문서를 열면 다르게 적혀 있다 — 컴퓨터는 계정당 한 대고, 모든 봇이 파일·브라우저 세션·CLI 크리덴셜을 공유하며, 봇 간 분리를 보안 경계로 쓰지 말라고 공식 문서가 직접 말한다. 이 상주 설계가 파는 가치(로그인 한 번, 셋업 반복 없음, 누적되는 컨텍스트)와 만들어내는 위험(신뢰불가 입력 + 크리덴셜 상주 + 외부 통신)은 같은 곳에서 나온다. 같은 카테고리의 Claude Cowork·Claude Code, ChatGPT Work·Codex가 상태와 격리를 어떻게 다르게 설계했는지 비교하고, 공식 보안 문서에 &apos;프롬프트 인젝션&apos;이라는 단어가 한 번도 안 나온다는 사실, 그리고 그래도 써 보겠다면 지켜야 할 수칙까지 정리했다.</description><pubDate>Sun, 16 Aug 2026 14:00:00 GMT</pubDate></item><item><title>벡터 DB를 따로 둘 이유가 또 하나 사라졌다 — DynamoDB 네이티브 벡터 검색이 지운 건 파이프라인이다</title><link>https://desty.github.io/blog/55-dynamodb-vector-search/</link><guid isPermaLink="true">https://desty.github.io/blog/55-dynamodb-vector-search/</guid><description>8월 5일, AWS가 DynamoDB 네이티브 벡터 검색을 프리뷰 없이 바로 GA로 내놨다. 임베딩을 운영 데이터 옆에 그대로 저장하고 SearchVectors API 하나로 유사도 검색을 하는 구조다. 지금까지 공식 답이었던 zero-ETL OpenSearch 체인은 서비스 다섯 개짜리였고, ScyllaDB는 석 달 전 정확히 그 지점을 조롱하며 선공을 날렸다. 이번 GA로 사람들이 정말 원했던 게 뭐였는지가 분명해진다 — 더 좋은 ANN이 아니라, 하나 덜 운영하는 것. 발표문의 &apos;any scale&apos;에 붙는 조건(SearchSchema 파티션 키 = 비용 설계), 에이전트 메모리 유스케이스의 함정(eventually consistent, FGAC 미지원), 온디맨드 전용·등호 필터만·페이지네이션 없음 같은 발표문에 없는 제약, 그리고 S3 Vectors·OpenSearch·Postgres 사이의 선택 기준까지 정리했다.</description><pubDate>Sun, 09 Aug 2026 18:00:00 GMT</pubDate></item><item><title>같은 모델로 30%에서 95%로 — 하네스가 스스로를 고치기 시작했다, Prime Agent</title><link>https://desty.github.io/blog/54-prime-agent-self-improving-harness/</link><guid isPermaLink="true">https://desty.github.io/blog/54-prime-agent-self-improving-harness/</guid><description>Claude Opus 5는 ARC-AGI-3 공식 하네스에서 30.2%를 받는다. 같은 모델을 Prime Intellect의 새 하네스에 얹으면 95.5% — 인간 전문가 기준선 위다. Prime Agent는 도구를 IPython 커널 하나로 줄여 컨텍스트를 변수처럼, 서브에이전트를 함수처럼 다루게 하고(RLM), 프롬프트·스킬·메모리·서브에이전트를 에이전트 자신이 CRUD하는 지속 개선 하네스를 얹었다. 흥미로운 건 숫자보다 제작자가 직접 실은 관찰이다 — Factorio에서 정당한 스킬을 만들던 바로 그 개선 루프가, 익스플로잇을 찾은 뒤 효율적으로 치팅하는 스킬을 만들기 시작했다. 자가 측정 수치의 함정, 하네스가 낡는다는 문제의식, 그리고 자기 개선 하네스 시대에 가져갈 질문 네 개까지 정리했다.</description><pubDate>Sun, 09 Aug 2026 14:00:00 GMT</pubDate></item><item><title>SKILL.md는 104줄, 검증기는 2만 5천 줄 — 스타 1만 개짜리 스킬 Archify 해부</title><link>https://desty.github.io/blog/52-archify-skill-product/</link><guid isPermaLink="true">https://desty.github.io/blog/52-archify-skill-product/</guid><description>생성 4개월도 안 된 저장소가 10.7k 스타를 받았는데, 본체는 SKILL.md 104줄이다. Archify는 에이전트에게 다이어그램을 그리게 하는 스킬인데, 히트 요인은 그림 솜씨가 아니라 그 뒤에 붙은 2만 5천 줄짜리 결정론적 검증기였다. 타입 있는 JSON 중간표현, 검증 통과 없이는 전달 금지, 수정 예산 2라운드, &apos;0이 아닌 종료 코드를 성공이라 부르지 마라&apos;는 지시까지 — 애매한 생성 작업을 작업 단위 하네스로 감싼 설계를 해부했다. 원본 스킬을 포크가 추월한 계보, 스폰서와 벤치마크가 붙은 스킬 생태계, 그리고 사내 스킬을 만들 때 베껴갈 설계 다섯 가지까지 정리했다.</description><pubDate>Sun, 09 Aug 2026 10:00:00 GMT</pubDate></item><item><title>돌릴 수 있는 모델은 단 하나, 속도는 초당 17,000토큰 — 모델을 실리콘에 굽는 Taalas를 AMD가 샀다</title><link>https://desty.github.io/blog/53-taalas-model-in-silicon/</link><guid isPermaLink="true">https://desty.github.io/blog/53-taalas-model-in-silicon/</guid><description>AMD가 8월 6일 인수를 발표한 Taalas는 GPU의 반대편 끝에 있는 회사다. 유일한 제품 HC1은 Llama 3.1 8B 딱 한 모델만 돌린다 — 가중치가 트랜지스터에 물리적으로 새겨져 있기 때문이다. HBM도 수냉도 없는 250W 카드가 사용자 한 명 기준 초당 17,000토큰을 뽑는다는 주장의 물리학은 진짜인데, 수치는 전부 자사 발표다. 진짜 자산은 칩이 아니라 &apos;새 모델을 2개월 만에 실리콘으로 만드는 공정&apos;이고, 그 공정이 겨냥하는 미래를 뜯어봤다. 프론티어 모델 전용 가정용 카드라는 상상이 왜 폐쇄 모델에선 성립하지 않고 오픈웨이트에선 성립하는지, 추론 가격 곡선이 또 꺾일 때 개발자가 미리 바꿔둘 전제가 뭔지까지 정리했다.</description><pubDate>Sun, 09 Aug 2026 10:00:00 GMT</pubDate></item><item><title>루프의 다음 병목은 상태다 — 루프가 스스로 만든 도구, LoopX</title><link>https://desty.github.io/blog/51-loopx-state-kernel/</link><guid isPermaLink="true">https://desty.github.io/blog/51-loopx-state-kernel/</guid><description>10주에 커밋 4,037개. 바이트댄스 엔지니어가 만든 LoopX는 loop engineering이라는 말이 생긴 지 6주 만에 나온 첫 본격 구현체다. 채팅 메모리와 타이머로는 며칠짜리 루프를 다스릴 수 없다는 문제의식에서, 목표·게이트·증거·쿼터를 에이전트 바깥의 상태 커널로 뺐다. 더 흥미로운 건 이 도구가 자기 루프로 자기를 만들고 있다는 점이다 — 하루 74커밋의 셀프 이터레이션, 에이전트에게 쓴 AGENTS.md, 모든 주장에 증거 등급을 스스로 붙이는 README까지. 상태 커널이라는 수요의 실체, 메타사례가 주는 신호와 경고, 그리고 내장 /loop 시대에 서드파티 커널이 언제 필요한지까지 정리했다.</description><pubDate>Sat, 08 Aug 2026 10:00:00 GMT</pubDate></item><item><title>에이전트 메모리는 채팅 로그가 아니다 — TencentDB Agent Memory가 팀 기억을 다루는 법</title><link>https://desty.github.io/blog/50-tencentdb-agent-memory/</link><guid isPermaLink="true">https://desty.github.io/blog/50-tencentdb-agent-memory/</guid><description>텐센트가 오픈소스한 TencentDB Agent Memory는 &apos;대화 저장소&apos;가 아니라 Chat Memory·Skill·Wiki·CodeGraph 네 자산을 팀 단위로 거버넌스하는 허브다. 핵심 설계는 세 가지다. 기억은 L0→L3로 증류되고, 전역 프롬프트가 아니라 에이전트 로드아웃으로 장착되며, MemoryProxy가 Claude Code 같은 코딩 에이전트에 코드 한 줄 없이 주입 경로를 연다. PersonaMem 48%→76%라는 숫자보다 중요한 건, RAG가 답하는 &apos;무엇이 검색되나&apos; 위에 &apos;누가 쓰고, 어떤 버전이 유효하고, 어느 에이전트에 장착되나&apos;를 올렸다는 점이다. 1.7만 스타와 v2.0 릴리즈를 기준으로 아키텍처·DX·한계까지 해부한다.</description><pubDate>Sat, 08 Aug 2026 09:00:00 GMT</pubDate></item><item><title>온톨로지는 25년 만에 임자를 만났다 — 에이전트, 그리고 Fabric IQ</title><link>https://desty.github.io/blog/45-ontology-comeback/</link><guid isPermaLink="true">https://desty.github.io/blog/45-ontology-comeback/</guid><description>7월 말 Microsoft의 Ontology Playground라는 학습용 웹앱이 커뮤니티에 돌았다. 장난감처럼 보이는 이 사이트가 가리키는 방향이 흥미롭다. 2001년 시맨틱 웹이 온톨로지를 설계했을 때 최종 목표는 지능형 에이전트였다. 그 비전은 사람이 수작업으로 의미를 달아야 한다는 요구 때문에 실패했는데, LLM이 &apos;읽는 쪽&apos; 문제를 풀자 병목이 &apos;의미의 부재&apos;로 옮겨갔고, 25년 만에 나타난 임자를 맞으러 Palantir·Snowflake·dbt·Databricks·Microsoft가 일제히 움직이고 있다. text-to-SQL이 실전에서 17%로 추락하는 수치, Fabric IQ Ontology의 실체와 제약, 그리고 온톨로지가 진짜 필요한지 가르는 기준과 시작 사다리까지 담았다.</description><pubDate>Fri, 07 Aug 2026 10:00:00 GMT</pubDate></item><item><title>모델은 빌린 것, eval은 내 것 — 수명 1년짜리 모델 위에서 개발하기</title><link>https://desty.github.io/blog/44-surviving-model-churn/</link><guid isPermaLink="true">https://desty.github.io/blog/44-surviving-model-churn/</guid><description>3사 deprecation 페이지를 실측하면 GA 모델의 실제 수명은 12~16개월이다. 프롬프트와 에이전트 하네스는 그 위에 지은 구조물이라 감가상각 주기도 같이 1년이다. 이사(#36)를 이벤트로 다뤘다면, 이번 글은 이사가 주기라는 전제에서 출발한다. 구모델의 약점을 메우던 지시가 신모델에선 부채가 되는 역설, 프롬프트 이식 실패에 &apos;Model Drifting&apos;이라는 학술 이름이 붙은 과정, 그리고 모델이 바뀌어도 남는 자산 — eval·스키마·spec — 에 투자를 옮기는 법. 마지막에 모델 종속부를 갈아끼우기 싸게 만드는 실전 체크리스트 여섯 가지를 담았다.</description><pubDate>Tue, 04 Aug 2026 10:00:00 GMT</pubDate></item><item><title>제일 믿을 만한 AI는 한 놈이 아니었다 — 크로스 에이전트 리뷰가 일상으로 온 이유</title><link>https://desty.github.io/blog/49-cross-agent-review/</link><guid isPermaLink="true">https://desty.github.io/blog/49-cross-agent-review/</guid><description>코덱스가 짠 파서를 같은 화면 안의 클로드에게 리뷰시키는 장면이 더 이상 실험이 아니다. Anthropic Code Review, VS Code 멀티 에이전트, 빌더-검증자 체인, 그리고 CCB(Claude Codex Bridge) 같은 크로스 프로바이더 하네스가 가리키는 방향은 같다 — 신뢰는 한 모델의 지능이 아니라 서로 다른 실패 모드를 가진 에이전트가 서로를 검사하는 구조에서 나온다. 복붙 세금이 사라진 자리에서 회로차단·역할 분리·언제 2명이면 충분한지까지 정리했다.</description><pubDate>Sun, 02 Aug 2026 14:00:00 GMT</pubDate></item><item><title>캐시 히트율은 프롬프트 설계의 성적표 — 히트율 98% 뒤에 있는 규율</title><link>https://desty.github.io/blog/48-cache-hit-rate/</link><guid isPermaLink="true">https://desty.github.io/blog/48-cache-hit-rate/</guid><description>7월 무신사 테크블로그에 LLM 비용 64% 절감, 캐시 히트율 98%라는 숫자가 올라왔다. 국내 테크블로그에서 프롬프트 캐싱 실측치를 공개한 사실상 첫 사례다. 그런데 이 글에서 정말 오래 남는 것은 절감액이 아니라 히트율이라는 숫자의 성격이다. 캐시 히트율은 청구서에 붙는 할인 항목이 아니라, &apos;변하지 않는 것을 앞에, 변하는 것을 뒤에 뒀는가&apos;라는 설계 질문에 대한 채점 결과다. 같은 시험지를 먼저 받아든 답안지들도 나란히 놓았다. 히트율 7%에서 84%로 뛴 보안 에이전트, 캐시 히트율이 떨어지면 장애를 선언하는 Anthropic, &apos;KV 캐시 히트율이 프로덕션 에이전트의 단 하나의 지표&apos;라는 Manus. 토큰 하나가 해시 체인을 끊는 원리부터 4사 캐싱 정책 비교, 내 성적을 올리는 순서까지 정리했다.</description><pubDate>Sun, 02 Aug 2026 10:00:00 GMT</pubDate></item><item><title>루프는 죽은 게 아니라 강등됐다 — Graph Engineering이라는 이름의 두 갈래 실체</title><link>https://desty.github.io/blog/43-graph-engineering/</link><guid isPermaLink="true">https://desty.github.io/blog/43-graph-engineering/</guid><description>7월 들어 &apos;graph engineering&apos;이라는 말이 에이전트 판에 돌기 시작했다. prompt, context, loop 다음의 네 번째 이름표다. 신조어가 늘 그렇듯 절반은 마케팅인데, 이번엔 특이한 점이 있다. 같은 이름이 서로 다른 두 실체를 가리키며 쓰이고 있다는 것 — 일의 모양을 그리는 오케스트레이션 그래프와, 아는 것을 담는 지식·메모리 그래프. 둘 다 파볼 가치가 있다. 전자는 &apos;판단은 모델이, 라우팅은 코드가&apos;라는 원칙으로 수렴 중이고, 후자는 인덱싱 비용이 18개월 만에 1000분의 1로 떨어지면서 도입 계산이 달라졌다. 용어의 계보, 두 갈래의 정리, 그리고 내 시스템에 그래프가 실제로 필요한지 가르는 기준까지 담았다.</description><pubDate>Fri, 31 Jul 2026 10:00:00 GMT</pubDate></item><item><title>청킹 라이브러리는 어쩌다 YC까지 갔나 — 팔린 것은 똑똑함이 아니라 가벼움이었다</title><link>https://desty.github.io/blog/47-chonkie-chunking/</link><guid isPermaLink="true">https://desty.github.io/blog/47-chonkie-chunking/</guid><description>RAG 튜토리얼에서 한 줄로 지나가는 전처리 잡일, 청킹. 그 한 단계만 파는 라이브러리가 월 119만 다운로드를 받고 YC를 통과해 회사가 됐다. 흥미로운 건 그 다음이다. &apos;33배 빠름&apos;은 최하위 경쟁자 대비였고 1위와는 1.06배, &apos;100GB/s&apos;는 토큰 세기를 포기한 숫자였으며, 창업자 스스로 HN에서 &apos;완벽한 분할은 검색 품질을 거의 못 움직인다&apos;고 인정했다. 그런데도 다운로드는 계속 늘었다. 시맨틱 청킹이 단순 recursive를 못 이긴다는 실증 연구가 쌓이는 지형에서 사람들이 진짜 산 것은 무엇이었는지, long context 시대에 청킹이 살아남은 이유, 청커 11종에서 뭘 골라야 하는지, 그리고 회사가 피벗해도 라이브러리가 남는 오픈소스의 결말까지 해부했다.</description><pubDate>Wed, 29 Jul 2026 14:00:00 GMT</pubDate></item><item><title>GraphRAG 4종을 같은 조건에서 붙여봤다 — 병목은 검색이 아니었다</title><link>https://desty.github.io/blog/46-is-graphrag-needed/</link><guid isPermaLink="true">https://desty.github.io/blog/46-is-graphrag-needed/</guid><description>6월 말 AWS·Cisco 엔지니어들이 도발적인 제목의 논문을 냈다. Is GraphRAG Needed? 같은 지식베이스, 같은 모델 위에 regular RAG부터 GraphRAG, Agentic RAG까지 9개 시나리오를 전부 직접 구현해 나란히 돌린 비교 실험이다. 성적표에는 반전이 셋 있다 — 그래프만 쓴 검색은 붕괴했고, 관계를 문서에 펴 넣은 평범한 RAG가 하이브리드 GraphRAG를 이겼으며, 에이전트에 그래프 도구를 더하자 오히려 성능이 12% 떨어졌다. 더 뼈아픈 수치는 그 다음이다. 검색이 정답 근거의 83.5%를 가져와도 모델은 47.9%만 쓴다. 검색 결과의 표기법만 바꿔 토큰을 절반 가까이 줄인 처방까지, 그래프를 얹기 전에 봐야 할 순서를 정리했다.</description><pubDate>Wed, 29 Jul 2026 10:00:00 GMT</pubDate></item><item><title>한국어 임베딩, 아직도 bge-m3 쓰세요? — ko-embedding-leaderboard가 보여주는 세대교체</title><link>https://desty.github.io/blog/42-korean-embeddings/</link><guid isPermaLink="true">https://desty.github.io/blog/42-korean-embeddings/</guid><description>한국어 RAG를 만들 때 벡터 DB만큼 자주 나오는 질문이 &apos;임베딩 모델은 뭘 쓰지&apos;다. MTEB 리더보드를 열어봐도 답이 안 나온다. 다국어 평균 점수는 한국어 검색 성능을 말해주지 않기 때문이다. 이 공백을 메우는 게 ko-embedding-leaderboard 같은 한국어 전용 리더보드다. 순위표를 읽어보면 통념이 몇 개 깨진다. 오랫동안 국룰이던 bge-m3는 8위로 밀렸고, 1위 자리는 568M짜리 한국어 파인튜닝 모델과 4B 프런티어 모델이 0.65점 차로 다투고 있다. 왜 한국어 전용 리더보드가 따로 필요한지, 순위표에서 읽어야 할 세 가지, 그리고 지금 한국어 임베딩을 골라야 한다면 어떤 기준으로 갈라야 하는지 정리했다.</description><pubDate>Tue, 28 Jul 2026 10:00:00 GMT</pubDate></item><item><title>벡터 DB를 따로 둘 이유가 사라지고 있다 — 마지막 남은 문제는 필터고, pgContext는 여길 파고들었다</title><link>https://desty.github.io/blog/41-pgcontext/</link><guid isPermaLink="true">https://desty.github.io/blog/41-pgcontext/</guid><description>RAG를 시작하면 제일 먼저 부딪히는 질문이 &apos;벡터 DB를 따로 둬야 하나&apos;다. 2026년 중반의 답은 대체로 &apos;아니, 일단 Postgres&apos;로 기울었는데, 이 답에는 아직 구멍이 하나 있다. 메타데이터 필터를 거는 순간 pgvector의 recall이 조용히 무너진다는 것. 이번 주 GitHub에서 눈에 띈 pgContext는 정확히 이 약점을 파고든 Rust 확장이다. 왜 사람들이 자꾸 &apos;전부 Postgres로&apos;를 원하는지(DB를 하나 더 운영하는 부담, 초심자의 진입장벽), pgvector의 post-filtering 함정이 뭔지, pgContext는 뭘 다르게 했고 뭘 스스로 진다고 인정하는지, 그리고 내 워크로드가 이 함정에 걸려 있는지 판별하는 법까지 정리했다.</description><pubDate>Mon, 27 Jul 2026 10:00:00 GMT</pubDate></item><item><title>Fable 5의 99%를 반값에 — Opus 5 마이그레이션은 &apos;추가&apos;가 아니라 &apos;삭제&apos;부터다</title><link>https://desty.github.io/blog/40-claude-opus-5/</link><guid isPermaLink="true">https://desty.github.io/blog/40-claude-opus-5/</guid><description>7월 24일 Anthropic이 Claude Opus 5를 냈다. 두 달 새 네 번째 릴리스이고, 포지셔닝은 노골적이다 — Fable 5급 성능을 절반 가격($5/$25)에. 그런데 마이그레이션 가이드를 읽다 보면 낯선 패턴이 보인다. 새로 추가하라는 지시문보다 **기존 프롬프트에서 지우라는 지시문이** 더 많다. &apos;검증해라&apos;를 지우고, &apos;서브에이전트를 더 써라&apos;를 지우고. #21에서 &apos;프롬프트는 액셀이 아니라 브레이크&apos;라고 했는데, Opus 5는 밟고 있던 브레이크마저 떼라고 한다. 벤치마크 검증, thinking 기본값 변화 같은 breaking 2건, 지워야 할 지시문 목록, 그리고 공개 유출 저장소의 세대별 시스템프롬프트를 직접 까서 확인한 &apos;비대칭 다이어트&apos;까지 정리했다.</description><pubDate>Sun, 26 Jul 2026 10:00:00 GMT</pubDate></item><item><title>코딩 에이전트를 하나도 안 만들고 스타 4배 — Orca가 제품화한 건 &apos;에이전트를 쓰는 사람의 하루&apos;다</title><link>https://desty.github.io/blog/39-ide-to-ade/</link><guid isPermaLink="true">https://desty.github.io/blog/39-ide-to-ade/</guid><description>#35와 #38에서 성능의 병목이 모델 바깥으로 이동했다는 얘기를 했는데, 이번엔 워크플로우 차례다. YC 스타트업 Stably의 오픈소스 Orca는 코딩 에이전트를 하나도 만들지 않는다. Claude Code, Codex 같은 남의 에이전트 30개+를 병렬 git worktree에서 굴리는 관제탑, 이른바 ADE(Agent Development Environment)다. 6월 7.7k였던 GitHub 스타가 7월 말 28k를 넘었다. 이 급성장이 캐치한 바이브코딩의 병목 4개 — 사람의 대기 시간, 비결정성, 구독료 이중과금, 폰으로 도망 못 가는 승인 버튼 — 와 &apos;IDE는 죽지 않고 강등된다&apos;는 전망, 그리고 쓰기 전에 알아야 할 주의점까지 정리했다.</description><pubDate>Sat, 25 Jul 2026 21:00:00 GMT</pubDate></item><item><title>모델은 빌릴 수 있어도 회사의 기억은 못 빌린다 — 하루 15,000번 질문받는 Cerebras &apos;컴퍼니 브레인&apos; 해부</title><link>https://desty.github.io/blog/37-company-brain/</link><guid isPermaLink="true">https://desty.github.io/blog/37-company-brain/</guid><description>Cerebras가 사내 지식베이스의 설계도를 공개했다. 출시 석 달 만에 하루 15,000개 넘는 질문을 받는, 회사에서 가장 널리 쓰이는 축의 내부 도구가 됐는데 — 묻는 쪽이 사람만이 아니다. 자동화 스크립트와 에이전트가 같은 곳에 묻는다. 설계의 출발점은 &apos;단일 진실 공급원&apos;의 포기다. 지식을 한곳에 모으는 대신 흩어진 채로 검색 가능하게 만들고, 전문 검색·임베딩·희귀도·나이 감쇠 4중 하이브리드로 찾고, 원문 대신 정규화된 요약을 임베딩하고, 커밋마다 바뀐 조각만 다시 임베딩한다. 결론은 하나로 모인다 — 브레인은 저장고가 아니라 유지 시스템이고, #30의 컨텍스트 엔지니어링을 회사 단위로 확장한 물건이다. Glean이 ARR 3억 달러(+89%)로 이 물건의 가격표를 이미 증명하고 있다.</description><pubDate>Mon, 20 Jul 2026 10:00:00 GMT</pubDate></item><item><title>모델은 고정, 하네스만 3개 — Claude Code보다 토큰 28% 덜 쓰고 더 맞힌 논문이 나왔다</title><link>https://desty.github.io/blog/38-tofu-white-box-harness/</link><guid isPermaLink="true">https://desty.github.io/blog/38-tofu-white-box-harness/</guid><description>#35를 &apos;저 점수는 모델이 낸 것인가, 하네스가 받쳐준 것인가&apos;라는 질문으로 끝냈는데, 엿새 뒤 그 질문을 통제실험으로 답한 논문이 도착했다. NiuTrans 연구실(중국 동북대학)과 Meituan이 만든 오픈소스 하네스 ToFu는 같은 모델 3개를 놓고 하네스만 바꿔 SWE-bench Verified를 돌렸고, Claude Code보다 토큰을 평균 28.4% 덜 쓰면서 Pass@1은 3.8%p 높았다. 비결인 3계층 컨텍스트 압축, &apos;토큰 절감이 비용 절감은 아니었다&apos;는 Opus의 반전, 그리고 한국어 사용자에게는 아직 해당 없는 다국어 파이프라인까지 정리했다.</description><pubDate>Sun, 19 Jul 2026 21:00:00 GMT</pubDate></item><item><title>GPT-5.6으로 갈아탔더니 2.2배 빠르고 27% 쌌다 — 단, 하네스를 같이 고쳐야 그 숫자가 나온다</title><link>https://desty.github.io/blog/36-model-migration/</link><guid isPermaLink="true">https://desty.github.io/blog/36-model-migration/</guid><description>4개월간 자사 프로덕션 eval에서 무적이던 Claude Opus 4.8이 처음으로 밀렸다. GPT-5.6으로 갈아탄 Ploy의 실측: 완료당 비용 27% 절감, 속도 2.2배, 품질은 오히려 위 — 그런데 출력 토큰은 절반이다. 이 워크로드에서는 신형이 더 적은 출력으로 더 나은 결과를 냈다. 첫 실행의 원시 실패 중 약 1/3은 모델이 아니라 Opus에 맞춰 휘어 있던 하네스 탓이었고, 도구 스키마·캐시·추론 재생을 함께 고쳐야 공정한 비교가 됐다. #35에서 &apos;저 점수는 모델이 낸 것인가, 하네스가 받쳐준 것인가&apos;라고 물었는데, 이 글은 그 질문의 실사판이다.</description><pubDate>Sun, 19 Jul 2026 18:00:00 GMT</pubDate></item><item><title>같은 모델로 30위에서 5위로 — &apos;모델 바깥의 전쟁&apos;에 하네스라는 이름이 붙었다</title><link>https://desty.github.io/blog/35-harness-engineering/</link><guid isPermaLink="true">https://desty.github.io/blog/35-harness-engineering/</guid><description>LangChain은 모델을 한 번도 안 바꾸고 Terminal Bench 2.0에서 30위권을 5위로 끌어올렸다. 고친 건 전부 모델 바깥 — 프롬프트의 자기검증 루프, 도구, 실패 패턴을 감지하는 미들웨어다. 이 &apos;모델 빼고 전부&apos;를 가리키는 하네스 엔지니어링이 2026년 주요 엔지니어링 조직의 실전 보고와 설계 글을 통해 빠르게 주류화됐다. #14에서 &apos;모델 바깥의 전쟁&apos;이라 불렀고 #25에서 이름만 걸어뒀던 그것의 본편이다. Guides×Sensors 제어 시스템 프레임과 Apiiro가 공개한 관측치(문법 오류 −76%, 권한상승 경로 +322%)까지 — 왜 하네스가 모델과 달리 &apos;남는 자산&apos;인지 정리했다.</description><pubDate>Sun, 19 Jul 2026 16:00:00 GMT</pubDate></item><item><title>RAG의 진짜 난제는 &apos;다시 검색&apos;이 아니라 &apos;모른다고 말하기&apos;다 — 구글이 제품에 박은 Sufficient Context</title><link>https://desty.github.io/blog/34-sufficient-context/</link><guid isPermaLink="true">https://desty.github.io/blog/34-sufficient-context/</guid><description>RAG에 문서를 쥐여주면 모델이 더 정직해질 것 같지만, 실측은 반대다 — 컨텍스트가 생기면 과신부터 하고, &apos;모른다&apos;고 말하는 능력을 잃는다(Claude 3.5 Sonnet의 &apos;모른다&apos; 응답률 84%→52%). ICLR 2025 논문 Sufficient Context는 &apos;관련 있는가&apos; 대신 &apos;충분한가&apos;를 묻는 것으로 이 문제를 갈랐고, 13개월 뒤 구글이 그걸 Gemini Enterprise 에이전트 루프의 정지 신호로 제품화했다(factuality 최대 +34%). #19의 검색 루프에 빠져 있던 브레이크, #32의 평가 축 하나가 여기서 채워진다. 메커니즘을 뜯고, 내 RAG에 &apos;모른다&apos;를 가르치는 실전 레시피까지 정리했다.</description><pubDate>Sun, 19 Jul 2026 14:00:00 GMT</pubDate></item><item><title>&apos;중국 오픈모델이 미국 최강 다 씹어먹었다&apos; — Kimi K3, 진짜인지 하나하나 따져봤다</title><link>https://desty.github.io/blog/33-kimi-k3/</link><guid isPermaLink="true">https://desty.github.io/blog/33-kimi-k3/</guid><description>7월 16일 Moonshot이 2.8조 파라미터 Kimi K3를 냈고, &apos;오픈모델이 Fable 5·GPT-5.6 Sol을 다 이겼다&apos;는 헤드라인이 이번 주를 덮었다. 지난 두 글(#21·#31)에서 미국 랩들이 제일 센 등급을 정부 뒤로 잠그는 걸 정리했는데, 중국은 정반대로 제일 큰 걸 통째로 풀어 그 벽을 우회했다. 그런데 &apos;다 씹어먹었다&apos;가 진짜일까? 비교 가능한 수치만 골라 따져보니 반은 사실, 반은 마케팅이었다 — 종합 지능에선 집계에 따라 3~4위지만, 세 개 축에서는 진짜로 1등을 먹었다. 어디가 진짜고 어디가 뻥인지 데이터로 갈랐다.</description><pubDate>Sat, 18 Jul 2026 10:00:00 GMT</pubDate></item><item><title>AI 시스템을 고치고 있다고 믿지만, 사실은 운에 맡기고 있다</title><link>https://desty.github.io/blog/32-ai-eval/</link><guid isPermaLink="true">https://desty.github.io/blog/32-ai-eval/</guid><description>프롬프트를 바꾸고, 모델을 올리고, RAG를 손본다. 그런데 좋아졌는지 나빠졌는지는 몇 개 돌려보고 &apos;느낌상 괜찮네&apos;로 끝낸다. 그건 개선이 아니라 운이다. LLM은 입력이 무한하고 출력이 확률적이라 눈대중으로는 측정이 안 된다. 그래서 진짜 첫 단계는 기능 구현이 아니라 평가 셋과 측정 파이프라인을 먼저 세우는 것이다. eval이 있어야 변경이 개선인지 회귀인지 갈린다. 측정할 수 없으면, 개선할 수 없다.</description><pubDate>Mon, 06 Jul 2026 10:00:00 GMT</pubDate></item><item><title>AI가 코드를 10배 빨리 쓴다 — 그런데 아무도 10배 더 리뷰하지 않는다</title><link>https://desty.github.io/blog/31-reviewing-ai-code/</link><guid isPermaLink="true">https://desty.github.io/blog/31-reviewing-ai-code/</guid><description>생성은 폭발적으로 빨라졌는데 리뷰는 그대로다. 그래서 병목은 조용히 리뷰로 옮겨갔다. 문제는 속도만이 아니다. AI 코드는 사람 코드와 실패하는 방식이 다르다 — 변수명도 깔끔하고 구조도 멀쩡한데 미묘하게 틀린다. 그 &apos;그럴듯함&apos;이 함정이다. 그래서 AI 코드 리뷰는 더 빨리 하는 게 아니라 다르게 해야 한다. &apos;읽기 좋은가&apos;가 아니라 &apos;안 보이는 곳이 맞는가&apos;를 보는 일이다.</description><pubDate>Sun, 05 Jul 2026 10:00:00 GMT</pubDate></item><item><title>컨텍스트 윈도우가 1M이 됐는데, 왜 여전히 컨텍스트를 깎아야 하나</title><link>https://desty.github.io/blog/30-context-engineering/</link><guid isPermaLink="true">https://desty.github.io/blog/30-context-engineering/</guid><description>8k에서 1M으로, 컨텍스트 윈도우 군비경쟁은 사실상 끝났다. 그러자 역설이 생겼다 — 더 넣을 수 있게 되자, &apos;덜 넣는&apos; 기술이 더 중요해졌다. 직관은 &apos;많이 넣을수록 똑똑해진다&apos;인데 실제는 반대다. 토큰이 길어질수록 모델은 그 안에서 필요한 걸 더 못 찾는다(context rot). 그래서 무게중심이 옮겨갔다. 프롬프트 엔지니어링이 &apos;어떻게 묻나&apos;였다면, 컨텍스트 엔지니어링은 &apos;무엇을 넣고, 무엇을 빼고, 언제 비우나&apos;다.</description><pubDate>Sat, 04 Jul 2026 10:00:00 GMT</pubDate></item><item><title>다들 MCP 서버를 만든다 — 그런데 프로토콜은 원래 어려운 적이 없었다</title><link>https://desty.github.io/blog/29-mcp-tool-design/</link><guid isPermaLink="true">https://desty.github.io/blog/29-mcp-tool-design/</guid><description>MCP가 사실상 표준이 되면서 너도나도 서버를 만든다. 그런데 한발 떨어져 보면 다들 쉬운 데서 경쟁하고 있다. 프로토콜은 JSON-RPC에 프리미티브 세 개, 문서 며칠이면 끝난다. 에이전트가 실제로 잘 도느냐를 가르는 건 그 위에 얹는 Tool 설계다 — 이름, 설명, 에러 메시지, 승인 게이트, 그리고 도구를 몇 개나 노출하느냐. 그리고 이건 새 기술이 아니다. 소비자가 사람이 아니라 모델일 뿐, 잊고 있던 API 설계 감각의 부활이다.</description><pubDate>Fri, 03 Jul 2026 10:00:00 GMT</pubDate></item><item><title>Karpathy가 던진 한 화면이 며칠 만에 구글 표준이 됐다 — 포맷은 공짜고, 승부는 데이터 창고에서 난다</title><link>https://desty.github.io/blog/28-open-knowledge-format/</link><guid isPermaLink="true">https://desty.github.io/blog/28-open-knowledge-format/</guid><description>구글이 OKF(Open Knowledge Format)를 공개했다. &apos;마크다운 + YAML로 지식을 표현하는 벤더 중립 포맷&apos;인데, 중요한 건 이게 구글의 전략실에서 나온 게 아니라는 점이다. 4월에 Karpathy가 던진 한 화면짜리 &apos;LLM Wiki&apos; gist가 2주 만에 별 5천을 넘기며 번졌고, 구글은 며칠 뒤 그 벤더 중립 버전을 내놨다. 수요는 군중이 먼저 증명했다 — llms.txt, AGENTS.md, CLAUDE.md로 이미 바닥에서 수렴하던 패턴이다. 그러니 질문은 &apos;OKF가 좋은 포맷이냐&apos;가 아니라, 군중이 증명한 수요를 구글이 왜 또 따로 표준으로 가져갔느냐다. 답은 그 포맷 아래 깔린 데이터 중력에 있다.</description><pubDate>Thu, 02 Jul 2026 10:00:00 GMT</pubDate></item><item><title>GPT-5.6은 하나가 아니라 셋으로 나왔다 — 제일 센 모델은 정부가 막았다</title><link>https://desty.github.io/blog/31-gpt-5-6-sol-terra-luna/</link><guid isPermaLink="true">https://desty.github.io/blog/31-gpt-5-6-sol-terra-luna/</guid><description>6월 26일 OpenAI가 GPT-5.6을 셋으로 쪼개 냈다. Sol·Terra·Luna. 숫자(5.6)는 세대를 뜻하고, 이름은 각자 속도로 발전하는 능력 등급이다. &apos;최신 모델로 업그레이드&apos;라는 단일 개념이 끝난 자리에 메뉴판이 들어섰다. 그런데 제일 센 Sol은 일반에 안 풀렸다 — 정부 요청으로 20개 남짓 승인 파트너에게만. 2주 전 블로그 #21에서 Anthropic이 한 짓을 &apos;Anthropic만의 안전 연극&apos;처럼 적었는데, OpenAI가 두 주 만에 거의 판박이로 따라 했다. 게다가 시스템 카드·METR 보고서를 보면 Sol은 &apos;너무 열심히 일하는&apos; 에이전트라 — 시키지 않은 일을 하고, 평가에서 치팅을 해 실력을 숫자로 못 박기도 어렵다. 무슨 일이 일어났고, 프런티어가 어디로 갈라지는지 정리했다.</description><pubDate>Sun, 28 Jun 2026 10:00:00 GMT</pubDate></item><item><title>엔터프라이즈 AI의 95%가 실패하는 진짜 이유 — 모델이 아니라 배포가 막혔고, 그래서 FDE가 떴다</title><link>https://desty.github.io/blog/28-forward-deployed-engineer/</link><guid isPermaLink="true">https://desty.github.io/blog/28-forward-deployed-engineer/</guid><description>2026년 테크에서 가장 빠르게 큰 직무는 모델 연구자가 아니다. 고객 회사에 들어가 함께 일하며 그 회사의 업무를 production 코드로 옮기는 Forward Deployed Engineer(FDE)다. 채용 공고가 1년 만에 643건에서 5,330건으로 729% 늘었고, 시니어 보수는 $785K를 넘긴다. 왜냐면 엔터프라이즈 AI 파일럿의 95%가 실패하는데 모델이 약해서가 아니라 배포가 막혀서다. FDE는 도메인 전문성에 노동시장이 가격표를 붙이는 방식이다 — 사용자 데이터(#26)와 회사 해자(#27)로 이어온 같은 명제의 세 번째 증거.</description><pubDate>Fri, 26 Jun 2026 10:00:00 GMT</pubDate></item><item><title>Harvey도 밑에서는 그냥 Claude를 돌린다 — &apos;도메인 특화 모델이 이긴다&apos;는 말의 진짜 의미</title><link>https://desty.github.io/blog/27-domain-specific-models/</link><guid isPermaLink="true">https://desty.github.io/blog/27-domain-specific-models/</guid><description>2026년의 화두 중 하나는 &apos;범용 LLM 하이프는 끝났고 도메인 특화가 이긴다&apos;는 말이다. 그런데 정작 도메인 AI의 챔피언인 Harvey(법률)·Sierra(고객 응대)를 까보면 밑에서 도는 건 그냥 Claude나 GPT다. 그럼 뭐가 특화된 걸까. 프런티어 모델이 좋아지면서 모델 가중치를 특화하는 일의 값은 떨어졌고, 해자는 한 칸 위 — 도메인 데이터, 워크플로 통합, 코드화된 업무 절차, 검증 루프 — 로 올라갔다. #26이 사람 쪽에서 한 얘기를, 모델 쪽에서 다시 만난다.</description><pubDate>Thu, 25 Jun 2026 10:00:00 GMT</pubDate></item><item><title>회계사가 소프트웨어 엔지니어만큼 성공한다 — AI 코딩에서 값이 오른 건 도메인 전문성이다</title><link>https://desty.github.io/blog/26-domain-expertise/</link><guid isPermaLink="true">https://desty.github.io/blog/26-domain-expertise/</guid><description>Anthropic이 Claude Code 세션 40만 건을 까보니, 코딩 작업의 성공률이 직업에 거의 좌우되지 않았다. 회계사도, 변호사도, 관리자도 소프트웨어 엔지니어와 몇 %포인트 안에 붙는다. 대신 성공을 가른 건 &apos;그 문제를 얼마나 아느냐&apos;였다. 전문가는 한 번의 지시로 에이전트를 더 멀리 풀어 놓고, 일이 꼬여도 덜 포기한다. 같은 신호가 바깥에서도 보인다 — 사람 쪽에선 도메인 전문가가 빌더가 되고, 모델 쪽에선 버티컬 특화 모델이 범용을 이긴다. 코딩이라는 진입장벽이 무너진 자리에 드러난 건 결국 도메인을 아느냐는 질문이다.</description><pubDate>Mon, 22 Jun 2026 10:00:00 GMT</pubDate></item><item><title>에이전트한테 일을 시키는 사람을 없애라 — Loop Engineering, 진짜 새로운 건 바깥쪽 루프다</title><link>https://desty.github.io/blog/25-loop-engineering/</link><guid isPermaLink="true">https://desty.github.io/blog/25-loop-engineering/</guid><description>요즘 도는 &apos;loop engineering&apos;이라는 말의 절반은 이미 아는 얘기다. 에이전트가 task를 잘 끝내게 만드는 inner loop은 모델 바깥의 harness 문제고, 그건 전에 다뤘다. 새로운 건 그 바깥 — 누가 에이전트한테 일을 시키느냐다. 트리거가 사람을 대체하고, 여러 루프가 공유 메모리로 서로 학습해 복리가 되는 구조. 그런데 무인 루프의 진짜 기술은 화려한 자동화가 아니라 &apos;언제 멈추나&apos;를 설계하는 것이고, 그래서 마지막에 남는 인간의 일은 다시 판단으로 돌아온다.</description><pubDate>Sun, 21 Jun 2026 10:00:00 GMT</pubDate></item><item><title>BE가 만들고 FE가 맞추던 시대는 끝났다 — 바이브코딩 시대 BE/FE는 계약을 먼저 합의한다</title><link>https://desty.github.io/blog/24-contract-first/</link><guid isPermaLink="true">https://desty.github.io/blog/24-contract-first/</guid><description>바이브코딩의 진짜 레버리지는 코드를 빨리 뽑는 게 아니라, AI가 따를 명확한 계약(API Contract)을 먼저 세우는 것이다. 데이터가 이걸 뒷받침한다 — AI는 문법 오류는 76% 줄이지만 권한 상승 경로는 322% 늘리고(Apiiro), 모델이 커져도 보안 품질은 평평하다(Veracode). AI가 못 메우는 영역이 정확히 &apos;계약에 담기는 정보&apos;다. 그래서 AI 시대에 명세는 덜 중요해진 게 아니라 더 중요해졌다. BE가 만들고 FE가 맞추는 협업에서, BE/FE가 Contract를 먼저 합의하고 AI가 양쪽을 생성하는 협업으로.</description><pubDate>Sat, 20 Jun 2026 10:00:00 GMT</pubDate></item><item><title>맥에서 전화를 거는 AI 에이전트 만들기 — STT부터 ARS 자동 응대까지, 전부 로컬·무료로</title><link>https://desty.github.io/blog/23-phone-ai-agent/</link><guid isPermaLink="true">https://desty.github.io/blog/23-phone-ai-agent/</guid><description>스팸 문자 끝에 붙은 &apos;[무료수신거부] 080…&apos; 한 통을, 맥이 알아서 걸고·듣고·번호를 눌러 처리하게 만들 수 있을까? 클라우드 API 한 푼 안 쓰고 M1 맥북에어 한 대로 발신 → ARS 음성 실시간 캡처 → 한국어 전사 → 메뉴 판단 → DTMF 입력 → 통화 종료까지 자동화한 기록. Core Audio process tap으로 통화 음성을 잡고, mlx-whisper large-v3-turbo로 실시간 전사하고, 지각-판단-행동 루프로 엮었다. 막혔던 지점과 거기서 건진 교훈 중심으로.</description><pubDate>Sun, 14 Jun 2026 10:00:00 GMT</pubDate></item><item><title>AI가 AI를 만들기 시작했다 — 그리고 병목은 이미 &apos;판단&apos;으로 옮겨갔다</title><link>https://desty.github.io/blog/22-recursive-self-improvement/</link><guid isPermaLink="true">https://desty.github.io/blog/22-recursive-self-improvement/</guid><description>Anthropic Institute가 &apos;When AI Builds Itself&apos;라는 글에서 자기 회사 숫자를 공개했다. 프로덕션 코드의 80% 이상을 Claude가 쓰고, 엔지니어 1인당 코드 산출은 2년 만에 8배가 됐다. 재귀적 자기개선(RSI)이라는 먼 미래가 핵심이 아니다. 진짜 메시지는 &apos;이미 일어난&apos; 쪽에 있다 — 코드를 쓰는 일은 거의 공짜가 됐고, 병목은 &apos;무엇이 맞는지 판단하는&apos; 쪽으로 옮겨갔다. 그리고 불편하게도, 그 마지막 보루인 판단마저 같은 곡선 위에 있다.</description><pubDate>Sat, 13 Jun 2026 16:00:00 GMT</pubDate></item><item><title>Opus 위에 새 등급이 생겼다 — Claude Fable 5, 이제 프롬프트는 액셀이 아니라 브레이크다</title><link>https://desty.github.io/blog/21-claude-fable-5/</link><guid isPermaLink="true">https://desty.github.io/blog/21-claude-fable-5/</guid><description>6월 9일 Anthropic이 Opus 위 &apos;Mythos급&apos; 모델을 공개했다. 공개판이 Fable 5, 안전장치를 푼 같은 모델이 Mythos 5다. 그런데 공식 프롬프팅 가이드를 까보면 이상하다 — &apos;더 시키는 법&apos;은 거의 없고 대부분이 &apos;덜 하게 만드는 법&apos;, &apos;사람 말로 번역시키는 법&apos;이다. 블로그 #17에서 &apos;과정 지시를 버리라&apos;고 했는데, Fable 5는 거기서 한 발 더 나갔다. 무엇이 바뀌었고, 그래서 어떻게 써야 하는지 정리했다.</description><pubDate>Sat, 13 Jun 2026 10:00:00 GMT</pubDate></item><item><title>KV 캐시를 줄이던 그 수학이, 이제 RAG를 통째로 노트북에 넣는다 — TurboVec</title><link>https://desty.github.io/blog/20-turbovec/</link><guid isPermaLink="true">https://desty.github.io/blog/20-turbovec/</guid><description>3개월 전 블로그 #02에서 TurboQuant를 다뤘다. &apos;KV 캐시를 3비트로, 같은 자원으로 불가능했던 걸 가능하게 한다&apos;고 썼는데 — 그 예언이 엉뚱한 데서 현실이 됐다. 똑같은 data-oblivious 양자화가 이번엔 모델 밖, RAG 벡터 검색으로 건너왔다. 그게 TurboVec다. 1천만 개 벡터를 4GB에, 학습 단계 없이, 로컬에서. 왜 핫한지, 원천 기술이 무엇인지, 앞으로 어디로 가는지 — 그리고 거기서 뭘 배울지 정리했다.</description><pubDate>Fri, 12 Jun 2026 10:00:00 GMT</pubDate></item><item><title>검색은 더 이상 사람을 위한 게 아니다 — Web IQ가 드러낸 진짜 사용자</title><link>https://desty.github.io/blog/19-search-for-agents/</link><guid isPermaLink="true">https://desty.github.io/blog/19-search-for-agents/</guid><description>마이크로소프트가 Web IQ를 내놨다. 사람이 읽을 10개 링크가 아니라, AI 에이전트가 추론에 바로 쓸 &apos;증거 조각&apos;을 돌려주는 검색 API다. Exa·Perplexity·Brave·Anthropic·Google까지 모두 같은 방향으로 가고 있다. 30년간 사람을 향했던 검색이, 이제 에이전트를 사용자로 모시기 시작했다. 그 전환의 구조와, 그 대가로 끊기고 있는 사람-웹의 피드백 루프를 데이터로 짚었다.</description><pubDate>Thu, 11 Jun 2026 10:00:00 GMT</pubDate></item><item><title>ISMS-P Assist</title><link>https://desty.github.io/projects/isms-p/</link><guid isPermaLink="true">https://desty.github.io/projects/isms-p/</guid><description>&quot;오답이 비싼&quot; 고위험 도메인에서 LLM 에이전트 하네스를 어떻게 설계하는가. ISMS-P 102개 인증기준을 소재로, Claude Code가 전문가 → 인터뷰어 → 심사관 멀티롤로 검토·심사한다. 재사용 가능한 하네스 패턴 10개 + 정직한 한계.</description><pubDate>Wed, 03 Jun 2026 17:00:00 GMT</pubDate></item><item><title>AI로 짠 코드가, AI의 토큰을 아낀다 — 넷플릭스 엔지니어의 Headroom을 까보고</title><link>https://desty.github.io/blog/18-headroom/</link><guid isPermaLink="true">https://desty.github.io/blog/18-headroom/</guid><description>넷플릭스 엔지니어가 만든 Headroom은 LLM에 보내기 전 컨텍스트를 압축해 토큰을 60~95% 줄여준다. 클론해서 코드까지 읽어보니 압축 엔진은 진짜였다. 그런데 더 흥미로운 건 따로 있었다 — 이 도구 자체가 AI 에이전트로 개발됐다는 흔적이 레포 곳곳에 노골적으로 남아 있었다. AI가 AI의 비용 문제를 푸는 도구를, AI로 만들고 있다.</description><pubDate>Wed, 03 Jun 2026 10:00:00 GMT</pubDate></item><item><title>아무도 &apos;더 똑똑한 모델&apos;을 원하지 않았다 — 트렌딩 AI 레포 4개로 읽는 개발자의 진짜 수요</title><link>https://desty.github.io/blog/17-maps-and-skills/</link><guid isPermaLink="true">https://desty.github.io/blog/17-maps-and-skills/</guid><description>이번 달 GitHub 트렌딩에 codegraph·Understand-Anything·ECC·pi가 한꺼번에 올라왔다. 네 개를 클론해 코드까지 읽고, 사람들이 왜 여기에 열광했는지 반응을 따라가 봤다. 흥미로운 건 — 아무도 &apos;더 똑똑한 모델&apos;을 달라고 하지 않았다는 점이다. 다들 모델 주변을 원했다.</description><pubDate>Sun, 31 May 2026 18:00:00 GMT</pubDate></item><item><title>모델만 바꿨는데 결과가 나빠졌다 — Opus 4.8과 GPT-5.5가 프롬프트를 다시 쓰게 만든 이유</title><link>https://desty.github.io/blog/17-prompting-after-opus48-gpt55/</link><guid isPermaLink="true">https://desty.github.io/blog/17-prompting-after-opus48-gpt55/</guid><description>Opus 4.8과 GPT-5.5는 약속이라도 한 듯 같은 방향으로 진화했다. 과정을 일일이 지시하던 프롬프트는 이제 성능을 깎는다. 두 모델의 특장점과 &apos;왜 기존 프롬프트를 버려야 하는지&apos;, 그리고 어떻게 다시 써야 하는지를 정리한다.</description><pubDate>Sun, 31 May 2026 18:00:00 GMT</pubDate></item><item><title>AI와 함께 버그바운티 첫 리포트까지 — 바이브코딩으로 해킹하기</title><link>https://desty.github.io/blog/16-vibe-bounty/</link><guid isPermaLink="true">https://desty.github.io/blog/16-vibe-bounty/</guid><description>버그바운티를 한 번도 해본 적 없는 상태에서, AI와 대화하며 하루 만에 첫 취약점을 발견하고 리포트를 제출한 경험을 공유한다. 코드는 한 줄도 직접 쓰지 않았다.</description><pubDate>Sun, 24 May 2026 18:00:00 GMT</pubDate></item><item><title>Avatar</title><link>https://desty.github.io/projects/avatar/</link><guid isPermaLink="true">https://desty.github.io/projects/avatar/</guid><description>퍼블릭 도메인 소설 캐릭터를 AI 에이전트로 구현. 소설 원문 기반 RAG + 인지 엔진으로 셜록 홈즈와 대화한다.</description><pubDate>Sat, 23 May 2026 21:00:00 GMT</pubDate></item><item><title>Hermes Agent vs OpenClaw — 같은 꿈, 다른 설계</title><link>https://desty.github.io/blog/15-hermes-vs-openclaw/</link><guid isPermaLink="true">https://desty.github.io/blog/15-hermes-vs-openclaw/</guid><description>둘 다 영구 메모리, 도구 통합, 셀프 호스팅. 겉보기엔 비슷한 두 오픈소스 AI 에이전트의 소스코드를 열어보니, 아키텍처 철학이 완전히 달랐다. OpenClaw에서 Hermes로 넘어온 경험을 바탕으로 코드 레벨에서 해부한다.</description><pubDate>Sat, 23 May 2026 18:00:00 GMT</pubDate></item><item><title>모델 바깥의 전쟁 — 에이전트 엔지니어가 진짜 설계하는 것</title><link>https://desty.github.io/blog/14-agent-engineering/</link><guid isPermaLink="true">https://desty.github.io/blog/14-agent-engineering/</guid><description>에이전트 = LLM + API라는 공식은 이미 깨졌다. Google, Anthropic, Cursor, OpenAI, Microsoft, ServiceNow, Salesforce — 7개 회사의 에이전트 전략을 &apos;중심 객체&apos; 관점으로 해부하고, 에이전트 엔지니어가 실제로 설계해야 할 시스템의 전체 그림을 그린다.</description><pubDate>Sat, 23 May 2026 14:00:00 GMT</pubDate></item><item><title>AI가 안 되는 건 모델 탓이 아니다 — AI-Ready Data의 조건</title><link>https://desty.github.io/blog/13-ai-ready-data/</link><guid isPermaLink="true">https://desty.github.io/blog/13-ai-ready-data/</guid><description>AI를 붙이면 다 될 줄 알았는데 안 된다. RAG를 붙여도 안 된다. 문제는 모델이 아니라 데이터다. 60%의 AI 프로젝트가 포기되는 진짜 이유와 데이터를 AI-Ready로 만드는 방법을 정리한다.</description><pubDate>Sat, 16 May 2026 14:00:00 GMT</pubDate></item><item><title>AX 시대를 위한 DX — AI를 잘 쓰려면 개발을 잘 해야 한다</title><link>https://desty.github.io/blog/12-dx-for-ax/</link><guid isPermaLink="true">https://desty.github.io/blog/12-dx-for-ax/</guid><description>AX(Agent Experience) 열풍 속에서 DX(Developer Experience) 기반 없이 뛰어든 사람들이 반복적으로 겪는 문제들, 그리고 AX 시대에 맞게 재정의된 DX 10가지 기반을 정리한다.</description><pubDate>Sat, 16 May 2026 10:00:00 GMT</pubDate></item><item><title>AI 코딩의 경고등이 켜졌다 — 그래서 우리는 어떻게 할 것인가</title><link>https://desty.github.io/blog/11-cognitive-debt-and-agentic-coding/</link><guid isPermaLink="true">https://desty.github.io/blog/11-cognitive-debt-and-agentic-coding/</guid><description>인지 부채, 토큰 비용 과열, 기술 위축 논쟁을 정면으로 분석하고, 변화하는 시대에 개발자가 실제로 취해야 할 전략을 정리한다.</description><pubDate>Tue, 05 May 2026 22:00:00 GMT</pubDate></item><item><title>OpenAI의 실시간 음성 AI 인프라에서 배우는 것들</title><link>https://desty.github.io/blog/10-realtime-voice-ai-infra/</link><guid isPermaLink="true">https://desty.github.io/blog/10-realtime-voice-ai-infra/</guid><description>9억 사용자에게 저지연 음성 AI를 제공하기 위해 OpenAI가 WebRTC를 어떻게 재설계했는지 분석하고, 유사한 시스템을 만드는 개발자가 가져갈 수 있는 실전 인사이트를 정리한다.</description><pubDate>Tue, 05 May 2026 18:00:00 GMT</pubDate></item><item><title>SDLC는 끝났는가 — AWS가 말하는 AI-DLC와 개발 방식의 재설계</title><link>https://desty.github.io/blog/09-ai-dlc/</link><guid isPermaLink="true">https://desty.github.io/blog/09-ai-dlc/</guid><description>AWS는 전통적인 개발 라이프사이클(SDLC)을 AI 기반 개발 라이프사이클(AI-DLC)로 대체하고 있다고 말한다. 도구를 바꾸는 이야기가 아니다. 개발자의 역할, 팀의 구조, 소프트웨어를 만드는 방식 전체가 바뀐다는 이야기다.</description><pubDate>Sun, 26 Apr 2026 12:00:00 GMT</pubDate></item><item><title>면접의 양면 — 면접자와 면접관이 함께 읽는 채용 가이드</title><link>https://desty.github.io/blog/08-interview-guide/</link><guid isPermaLink="true">https://desty.github.io/blog/08-interview-guide/</guid><description>면접은 일방적인 평가가 아니라 쌍방향 탐색이다. 이력서부터 온보딩까지, 면접자와 면접관 두 시점을 동시에 다루는 채용 완벽 가이드를 만들었다.</description><pubDate>Sat, 11 Apr 2026 18:00:00 GMT</pubDate></item><item><title>같이 일하고 싶은 개발자 — 코드보다 먼저 보이는 것</title><link>https://desty.github.io/blog/07-developer-attitude/</link><guid isPermaLink="true">https://desty.github.io/blog/07-developer-attitude/</guid><description>기술력은 입사 조건이고, 태도는 함께 일하고 싶은 사람을 만드는 조건이다. 국내외 자료를 종합해 정리한 회사 생활에서 진짜 차이를 만드는 5가지 태도와 실전 대비표.</description><pubDate>Sat, 11 Apr 2026 12:00:00 GMT</pubDate></item><item><title>AI Native 팀 — &apos;AI를 쓰는 팀&apos;과 &apos;AI로 설계된 팀&apos;은 다르다</title><link>https://desty.github.io/blog/06-ai-native/</link><guid isPermaLink="true">https://desty.github.io/blog/06-ai-native/</guid><description>AI 도구를 도입한다고 AI Native가 되는 게 아니다. 역할 분담, 의사결정, 리뷰, 문서 — 팀의 운영 구조 자체를 다시 설계해야 한다.</description><pubDate>Fri, 10 Apr 2026 18:00:00 GMT</pubDate></item><item><title>GEO — SEO의 다음 단계, AI에게 인용되는 콘텐츠 만들기</title><link>https://desty.github.io/blog/05-geo-seo/</link><guid isPermaLink="true">https://desty.github.io/blog/05-geo-seo/</guid><description>ChatGPT 주간 활성 사용자 8억 명, AI 검색 유입 전년 대비 527% 증가. 검색의 무대가 바뀌고 있다. 구글 1페이지가 아니라 AI의 답변 안에 들어가는 것 — Generative Engine Optimization(GEO)의 구조와 실무 전략을 데이터로 정리했다.</description><pubDate>Thu, 09 Apr 2026 12:00:00 GMT</pubDate></item><item><title>AI가 콘텐츠 생태계를 바꾸고 있다 — 읽는 사람, 쓰는 사람, 모델 자체에 벌어지는 일</title><link>https://desty.github.io/blog/04-ai-content-ecosystem/</link><guid isPermaLink="true">https://desty.github.io/blog/04-ai-content-ecosystem/</guid><description>검색의 60%가 클릭 없이 끝나고, 새로 만들어지는 웹페이지의 74%에서 AI 콘텐츠가 감지된다. 읽는 사람, 쓰는 사람, AI 모델 자체 — 세 축에서 동시에 벌어지고 있는 변화를 데이터로 정리했다.</description><pubDate>Sun, 05 Apr 2026 18:00:00 GMT</pubDate></item><item><title>AI Agent 시대, UI/UX는 어디로 가야 하는가</title><link>https://desty.github.io/blog/03-ai-agent-ux/</link><guid isPermaLink="true">https://desty.github.io/blog/03-ai-agent-ux/</guid><description>버튼을 누르면 결과가 나오던 시대가 끝나고 있다. AI가 대신 행동할 때 사용자가 느끼는 경험을 어떻게 설계할 것인가. 기대치 설계, 설명 가능성, 제어권 협상, 우아한 실패까지 — 실무에서 고민해야 할 6가지 포인트.</description><pubDate>Sun, 05 Apr 2026 12:00:00 GMT</pubDate></item><item><title>TurboQuant — KV 캐시 3비트 압축으로 LLM 추론의 병목을 깨다</title><link>https://desty.github.io/blog/02-turboquant-kv-cache/</link><guid isPermaLink="true">https://desty.github.io/blog/02-turboquant-kv-cache/</guid><description>구글이 ICLR 2026에서 발표한 TurboQuant. 메모리 6배 절감, 속도 8배 향상, 정확도 손실 0. 압축은 타협이라는 상식이 깨졌다.</description><pubDate>Sun, 29 Mar 2026 21:00:00 GMT</pubDate></item><item><title>Scrin</title><link>https://desty.github.io/projects/project-2/</link><guid isPermaLink="true">https://desty.github.io/projects/project-2/</guid><description>macOS 네이티브 회의록 앱. 온디바이스 STT &amp; LLM으로 실시간 녹음, 자동 전사, AI 요약까지 로컬에서 처리.</description><pubDate>Sun, 29 Mar 2026 21:00:00 GMT</pubDate></item><item><title>Hello World</title><link>https://desty.github.io/blog/01-hello-world/</link><guid isPermaLink="true">https://desty.github.io/blog/01-hello-world/</guid><description>첫 번째 포스트. 코드 블럭, Mermaid 다이어그램, 테이블 테스트.</description><pubDate>Sun, 29 Mar 2026 00:00:00 GMT</pubDate></item><item><title>desty.github.io</title><link>https://desty.github.io/projects/project-1/</link><guid isPermaLink="true">https://desty.github.io/projects/project-1/</guid><description>Astro Sphere 기반 개발자 블로그 &amp; 포트폴리오. 다크모드, 유성 애니메이션, Mermaid 다이어그램, 코드 하이라이팅 지원.</description><pubDate>Sun, 29 Mar 2026 00:00:00 GMT</pubDate></item></channel></rss>