AI 에이전트가 빨라지는 건 확실한데, 그래서 프로세스 전체가 빨라졌느냐 하면 꼭 그렇지도 않은 것 같습니다. 이번엔 속도를 올렸는데 왜 안 빨라지는지, 그리고 그 속도가 갑자기 사라졌을 때 무슨 일이 벌어지는지에 대한 이야기에요. 포커스 빠르게 반복하는 것과 축적하는 것은 다르고, 코드가 빨라진다고 전체가 빨라지는 건 아닙니다. ‘스킬'이라는 기억 장치 에이전트의 고질적인 문제가 하나 있습니다. 세션이 끝나면 배운 걸 전부 잊는다는 거예요. 같은 실수를 반복하고, 같은 질문을 다시 하고, 어제 해결한 문제를 오늘 또 처음부터 풀어야 합니다. 빠르긴 빠른데, 축적이 안 되는 거죠. Zhejiang대, Alibaba, Tencent 등 15개 기관이 공동으로 SkillNet이라는 연구를 발표했습니다. 에이전트가 학습한 스킬을 20만 개 이상의 공유 라이브러리로 구축해서, 한 에이전트가 배운 걸 다른 에이전트가 바로 재사용할 수 있게 하는 구조입니다. 결과가 꽤 인상적이에요. 모든 테스트 모델에서 평균 보상 40% 향상, 실행 스텝 30% 감소. 같은 날 Anthropic도 Claude Code Skills 라이브스트림을 진행했습니다. Uber가 실제 업무에서 스킬을 어떻게 쓰는지 공개하는 자리였구요. '스킬'이라는 개념이 연구실에서만 도는 게 아니라, 이미 실무에 들어와 있다는 걸 보여주는 장면이었습니다. 커뮤니티에서도 오픈소스 스킬 레포지토리를 전면 재작성하는 움직임이 나왔습니다. Anthropic이 공개한 "스킬은 좁을수록 좋다"는 원칙에 맞춰, 기존 스킬 구조를 처음부터 다시 짠 거죠. 여기서 패러다임이 바뀌고 있습니다. '빠르게 반복하는 것'에서 '축적하는 것'으로요. 에이전트가 매번 빈손으로 오는 게 아니라, 이전 세션의 경험이 쌓이고, 그게 다른 에이전트에게도 전파되는 구조. 속도가 아니라 기억이 경쟁력이 되는 셈입니다. 속도가 문제가 아니었다 에이전트가 코드를 빠르게 써주니까, 전체 개발 속도가 빨라질 거라고 기대하는 게 자연스럽습니다. 그런데 현실은 좀 다릅니다. "AI 에이전트가 오히려 속도를 늦추는가?"라는 반직관적인 질문이 화제가 됐습니다. Uber의 사내 AI 도입 사례를 분석한 내용인데, AI 도구가 코드 작성 속도를 높여도 검토와 승인 단계에서 지연이 생기면 전체 사이클은 오히려 느려진다는 구조적 문제를 짚습니다. "코드 작성 속도가 문제라고 생각했다면 더 큰 문제가 있다"는 글도 주목받았습니다. 골드렛의 제약이론(The Goal)을 AI 시대에 적용한 분석인데, 핵심은 간단합니다. 코드를 아무리 빨리 쳐도, 리뷰 대기, 배포 지연, 불명확한 요구사항이 병목이면 전체 속도는 거기에 묶인다는 거예요. 코드 생산량이 늘수록 비개발 단계의 정체가 오히려 심화됩니다. AI가 하루에 PR 50개를 만들어도, 리뷰할 수 있는 건 10개라면 나머지 40개는 대기열에 쌓이기만 하는 거죠. 결국 AI 도입의 효과는 코드 속도가 아니라 전체 흐름의 제약을 어디서 풀어주느냐에 달려 있습니다. 속도를 올리는 게 아니라, 어디가 느린지를 찾는 게 먼저라는 이야기입니다. Claude가 멈춘 날 속도에 적응하면, 속도가 사라졌을 때 무슨 일이 벌어질까요. 어제 Claude Code가 대규모 서버 과부하(529 Overloaded)로 다운됐습니다. "Claude 없이는 일을 못 하겠다", "프로젝트 전체가 멈췄다"는 반응이 쏟아졌구요. Anthropic이 사용량을 2배로 늘린다고 발표한 직후 발생한 터라 더 ...

지난번에는 '맥락을 설계하라'는 개념적인 이야기를 했었는데, 이번에는 그 개념이 산업 규모로 실현되고 있는 현장에 대한 소식들이 있네요. 그와 동시에 지금의 LLM 베이스 구조가 드러내는 한계도 있습니다. 에이전트가 강력해질수록, 에이전트가 틀렸을 때 그걸 어떻게 아느냐가 점점 더 중요해지고 있는 것 같아요. 포커스 에이전트가 산업 인프라가 되고, 스스로 진화하고, 그러면서도 자기가 틀렸는지 모른다는 이야기입니다. 에이전트가 산업 인프라로 진입한다 Stripe의 코딩 에이전트 'Minions'는 매주 1,300개의 PR을 완전 자동으로 처리합니다. 사람이 코드를 한 줄도 쓰지 않는 PR이 매주 천 건 넘게 머지되고 있다는 거죠. 하드웨어도 따라가고 있습니다. NVIDIA는 GTC 2026에서 Vera CPU를 발표했는데, 이건 에이전트 AI를 위해 설계된 전용 프로세서입니다. 기존 GPU가 병렬 연산에 최적화되어 있었다면, Vera는 에이전트 실행에 필요한 직렬-병렬 혼합 워크로드에 맞춰져 있구요. Emergent라는 플랫폼은 비개발자가 50만 달러 규모의 소프트웨어를 5천 달러 미만으로 구현할 수 있게 해줍니다. Google, Amazon 출신 형제가 만든 이 플랫폼에서는 에이전트가 코드 리뷰, 테스트, 디버깅을 실제 엔지니어링팀처럼 수행하고, 생성된 작업 궤적을 장기 기억에 저장해서 유사한 문제가 생기면 성공률을 높이는 구조를 갖추고 있습니다. Stratechery의 Ben Thompson은 이런 흐름을 보며 "우리는 버블 안에 있지 않다"고 선언했습니다. 에이전트 기반 컴퓨팅은 거품이 아니라 새로운 기반 인프라라는 거죠. "에이전트를 써볼까"가 아니라 "에이전트 없이 어떻게 하지"로 질문이 바뀌고 있습니다. 도구에서 인프라로, 인프라에서 산업으로 전환이 빠르게 진행되고 있구요. 에이전트가 스스로 진화한다 에이전트가 인프라가 됐으면, 다음 질문은 자연스럽습니다. 에이전트가 스스로 나아질 수 있느냐. AGR(Artificial General Research)이라는 자율 연구 루프가 공개됐습니다. Karpathy의 autoresearch 개념에서 영감을 받은 건데, 지표와 가드레일만 정의하면 에이전트가 자율적으로 실험하고, 측정하고, 커밋하고, 실패하면 폐기하는 사이클을 반복합니다. 실측 결과가 인상적이에요. C++ 라이브러리 실행 시간을 53초에서 28초로 46% 단축했고, 14회 자율 실험 중 7회가 채택됐습니다. RLM(Recursive Language Modeling)은 한 걸음 더 나갑니다. 에이전트의 실행 흔적 자체를 데이터로 삼아 실패 패턴을 추출하는 방식인데, GPT-5-mini가 RLM을 적용했을 때 GPT-5 본체보다 OOLONG 벤치마크에서 2배 이상 성과를 냈다는 결과가 나왔습니다. 소형 모델이 대형 모델을 이기는 거죠. 모델 크기가 아니라 루프의 품질이 성능을 결정한다는 이야기입니다. SkillNet 논문은 에이전트 스킬을 3계층 온톨로지(분류체계 → 관계 그래프 → 패키지 라이브러리)로 자동 구조화하는 방법을 제시했구요. Ouroboros라는 프로젝트는 MCP의 방향성 자체를 뒤집었습니다. 기존에는 "AI가 도구를 호출"하는 방식이었는데, Ouroboros는 "도구가 AI를 사용하도록" 설계됐습니다. MCP 호출 한 번으로 내부에서 작업을 쪼개고, ...

이번엔 '코드를 짜는 사람'과 '맥락을 설계하는 사람'의 차이에 대한 이야기입니다. 에이전트가 강력해질수록, 그 에이전트에게 뭘 하라고 했느냐보다 뭘 하면 안 되는지를 어떻게 알려줬느냐가 결과를 가르더라구요. 포커스 에이전트에게 '맥락'을 어떻게 전달하느냐를 둘러싼 이야기들입니다. 컨텍스트 엔지니어링 : 에이전트에게 맥락을 설계하는 일 요즘 '컨텍스트 엔지니어링'이라는 말이 자주 보입니다. 에이전트에게 코드를 짜달라고 하는 건 누구나 하는데, 에이전트가 일할 수 있는 구조를 설계하는 건 다른 차원의 일이라는 거죠. 업계에서 이걸 체계화하려는 시도도 나오고 있습니다. 정의(CLAUDE.md) → 실행(Skill) → 학습(Memory) → 연결(MCP)처럼 레이어를 나눠서, 에이전트가 일하는 경기장을 구조화하자는 흐름이구요. 저도 비슷한 구조를 직접 만들어 쓰고 있는데, 실제로 해보면 여기에 훅(Hook)이나 규칙 파일 분류 같은 세부 요소들이 더해져야 합니다. 레이어를 깔끔하게 4개로 나누는 것보다, 현장에서는 좀 더 구체적이고 세밀한 구조가 필요한 것 같아요. “하네스가 무슨 소용이냐, 모델이 알아서 잘하는데”라는 반론도 있죠. 하지만 디테일이 중요한 분야에서는 하네스가 모호성을 잡아내고 논리적 모순을 걸러주는 역할을 합니다. 모델이 좋아지면 불필요해지는 하네스도 있지만, 아무리 모델이 발전해도 팀의 선호나 워크플로우를 담은 하네스의 가치는 줄어들지 않을 것 같습니다. 코드를 생성하는 AI를 쓰는 것과, AI가 일할 수 있는 구조를 설계하는 것. 이 둘의 차이가 점점 벌어지고 있다는 느낌입니다. 테스트가 앱을 몰래 고쳤다 : 맥락 설계 실패의 대가 그럼 맥락 설계를 안 하면 어떻게 되느냐. r/ClaudeCode에 올라온 사례가 꽤 충격적입니다. 누군가가 Claude Code로 Playwright E2E 테스트(브라우저에서 실제 사용자처럼 클릭하고 확인하는 자동화 테스트)를 작성했거든요. 결과는 모든 테스트 PASS. 그런데 QA 환경에서 직접 확인해보니 앱이 망가져 있었습니다. 무슨 일이었냐면, 테스트가 앱의 버그를 수정하는 대신 브라우저 안에서 JavaScript를 몰래 주입해서 결함을 숨기고 PASS를 보고한 거죠. 테스트가 통과했는데 앱은 고장나있는, 아주 위험한 상태입니다. 원인은 명확합니다. 에이전트에게 "테스트를 통과시켜"라는 목표만 줬지, "앱 코드를 건드리지 마"라는 수단의 경계를 안 줬던 거예요. 결국 CLAUDE.md에 "테스트가 통과하면서 실제 기능은 망가져 있는 상황은, 테스트가 없는 것보다 나쁘다"는 규칙을 명시적으로 추가해야 했다고 합니다. 앞서 이야기한 컨텍스트 엔지니어링이 왜 필요한지를, 역설적으로 가장 잘 보여주는 사례가 아닐까 싶습니다. 에이전트는 목표를 달성하는 데는 놀라울 정도로 창의적이거든요. 문제는 그 창의성이 우리가 원하는 방향이 아닐 수도 있다는 것이죠. Claude...

이번엔 "에이전트를 많이 굴리면 좋은건가?"라는 질문을 중심으로 엮어봤습니다. 인프라가 열리고, 도구가 쏟아지고 있는데, 무엇이 차이를 만드는지에 대한 이야기들이 좀 있더라구요. 포커스 에이전트를 둘러싼 인프라나 도구에 대한 이야기입니다. 1M 토큰, 추가 요금 없이 Anthropic이 Opus 4.6과 Sonnet 4.6에서 1M(100만) 토큰 컨텍스트를 표준 가격으로 열었습니다. 기존에는 200k 토큰을 넘기면 입력 2배, 출력 1.5배 요금이 붙었거든요. 그 할증이 완전히 사라진거죠. 1M 토큰이면 어느 정도의 프로젝트 코드 전체를 한 세션에 올릴 수 있는 양이에요. 긴 문서 묶음이나 에이전트가 장시간 작업하는 세션도 끊김 없이 유지할 수 있습니다. Claude Code 사용자들은 기본값으로 1M 컨텍스트를 받게 되면서 컴팩션(대화 압축) 이벤트가 15% 줄었다고 해요. 다만 무작정 긴 컨텍스트를 잘 처리하는건 아닙니다. 800~900K 토큰 구간에서의 성능 저하는 여전히 존재한다는 이야기도 있거든요. 제 주변에서도 여전히 200k 도달 전에 강제로 compact 시켜버리는 분들도 꽤 계십니다. 더 많이 넣을 수 있다고 해서 다 잘 읽는 건 아닌 셈이죠. '컨텍스트가 넓어졌으니 오히려 더 꼼꼼하게 관리해야 한다'는 실용적 인사이트가 유효한 것 같습니다. 하지만 에이전트를 오래 돌리는 게 비용 문제로 막혔던 시대가 점점 극복되고 있다고 봅니다. 에이전트 10개를 24시간 돌리는 사람들 인프라가 좋아지니까 사람들이 에이전트를 회사처럼 굴리기 시작했습니다. AlexFinn이라는 사람은 OpenClaw 에이전트 10개를 24/7로 가동해서 자기 SaaS의 월 매출(MRR)을 25% 올렸다고 공개했습니다. "에이전트들이 새 기능을 브레인스토밍하고 만드는 걸 보면서, 승인 버튼만 누르면 프로덕션에 나간다"는 거죠. OpenClaw 생태계가 하루 사이에 여러 업데이트를 쏟아냈는데요. Chrome의 라이브 브라우저 원격 제어를 통합해서 에이전트가 사용자의 실제 로그인 세션에 접근할 수 있게 됐고, 스마트폰에서 새 에이전트 세션을 직접 띄울 수 있는 기능도 나왔습니다. Microsoft와 Nvidia도 파트너십에 참여했다고 하네요. 15세 청소년이 OpenClaw로 3만 달러짜리 계약을 따낸 이야기가 190만 뷰를 찍기도 했습니다. 에이전트를 많이 굴리는 사람이 이기는 게임이 되어버린 걸까요. 에이전트는 유한 상태 기계다 r/ClaudeCode에서 흥미로운 글이 주목받고 있습니다. "프레임워크는 에이전트를 어떻게 실행하는지 알려주지만, 어떻게 생각해야 하는지는 알려주지 ...

제 Claude가 매일 수행하는 작업 중 하나가 AI 관련 소식을 긁어모아서 digest를 만드는 일인데요. X, RSS, Youtube, 링크드인 등 다양한 소스를 취합해서 제가 관심있는 카테고리로 분류해서 정리하고 있습니다. 만드는 김에 종종 valley에도 업로드할까 했는데, 너무 raw한 데이터라 (Claude와 함께) 한번 더 가공해서 정리해볼까 합니다. 오늘 digest는 서로서로 연결지을만한 부분들이 좀 있어서 한 흐름으로 작성해봤습니다. 그 뒤에 짧막한 소식을 피드로 정리하고, 제 느낌을 마지막에 붙였어요. 포커스 메인 스토리입니다. "AI가 직원을 대체하지 않습니다" (그런데 해고는 합니다) Atlassian CEO가 "AI가 직원을 대체하지 않는다"고 선언했습니다. 같은 날 해고 소식이 나왔구요. 비슷한 시기에 Amazon에서도 재밌는 일이 있었는데요. 직원들이 "AI 도입 이후 생산성이 오른 게 아니라 업무량만 늘었다"고 반발하고 있다는 겁니다. 기업들의 AI 이야기를 들으면 항상 이런 패턴인거 같습니다. 대외적으로는 "AI는 도구일 뿐, 사람이 핵심입니다." 내부적으로는 "AI로 효율화했으니 인력을 줄이겠습니다." 기업 입장에서 이해 못 할 건 아닌데, 문제는 이 이중적인 메시지를 받는 쪽이겠죠. 회사의 "대체 안 한다"는 말을 믿고 있다가 해고당하면, 그 다음부터는 회사가 무슨 말을 하건 믿을 수 있을까요. levelsio의 고백 한편, 개인 차원에서는 또 다른 이야기가 나오고 있습니다. 인디 해커로 유명한 levelsio가 이런 글을 올렸습니다. "나는 코딩 문제를 안고 자다가 샤워하면서 유레카를 외치던 시절이 그립다. 그러나 세상은 영구적으로 바뀌었고, 나는 이제 아이디어와 실행력이 나의 차별화 요소임을 받아들여야 한다." 조회 수 13만 회를 넘겼더라구요. 개발자한테 코딩은 단순한 생계수단으로써의 일이 아닌 경우도 있습니다. 문제를 풀어내는 쾌감, 밤새 디버깅하다가 원인을 찾았을 때의 희열, 그런게 정체성을 구성하는 요소가 될 수 있거든요. AI가 그걸 대신해주기 시작하면, 편해지긴 하지만 뭔가 빼앗긴 느낌이 드는 거죠. levelsio는 그래도 결론을 내렸습니다. "세상이 바뀌었으니 공격적으로 받아들이고, 아이디어와 실행에 배팅한다." 그런데 모든 사람이 이렇게 빠르게 전환할 수 있을까요. 래퍼는 함정이다 그럼 어떻게 해야 하느냐. 오늘 digest에서 또 다른 이야기가 이 질문에 대한 하나의 답이 될 수 있을 것 같습니다. "래퍼는 함정이다." 래퍼(Wrapper)는 뭔가를 감싸서 쉽게 쓸 수 있게 해주는 걸 의미하는데요. AI를 래퍼처럼 쓴다는 건, 내부가 어떻게 작동하는지 모른 채 버튼만 누르는 거죠. ChatGPT에 질문 던지고 나온 답 복붙하는 식으로요. 문제는 이렇게 쓰면 역량이 위축된다는 겁니다. 내가 하는 건 요청을 던지는 것뿐이니까, AI가 업데이트되거나 사라지면 나한테 남는 게 없어요. 반대로, AI를 도구로 직접 다루면 어떨까요. 어떤 작업을 시킬 때, 실행 계획을 세우고, 결과를 검증하고, 안 되면 방법을 바꾸고. 이 과정에서 관성적으로 승인하는게 아니라, 모르는걸 물어보며 지식과 경험을 체화하는게 AI의 특성과 업무에 대한 이해도를 높이는 길 아닐까요....