코딩 도구들이 비슷해지고 있습니다. 벤치마크가 수렴하고, 오픈소스 대안이 쏟아지고, 심지어 모델의 내부 표현까지 같은 공간으로 모이고 있다는 연구가 나왔어요. 그러면 같은 도구를 쓰면 같은 결과가 나올까요. 이번 포커스에서 이야기하고자 합니다. 포커스 도구는 수렴하고 있고, 모델의 뇌 구조마저 닮아가고 있습니다. 차이는 도구 자체가 아니라 도구를 쓰는 방식에서 나옵니다. 코딩 도구, 다 비슷해지고 있다 코딩 도구 시장에서 흥미로운 일이 벌어지고 있습니다. Cursor가 Composer 2를 출시했는데, Claude Opus 4.6의 코딩 벤치마크를 넘어섰습니다. 내부를 까보니 Kimi K2.5에 강화학습을 적용한 모델이었구요. "더 큰 모델이 항상 이기는 게 아니라, 집중된 모델이 이긴다"는 이야기가 설득력을 얻고 있습니다. 같은 시기에 OpenCode라는 오픈소스 AI 코딩 에이전트가 개발자 커뮤니티에서 빠르게 주목받았습니다. Claude, GPT, Gemini를 전부 지원하는 범용 터미널 에이전트인데, Claude Code의 대안으로 떠오르고 있어요. Claude Code 쪽에서도 변화가 큽니다. /init 명령이 전면 개편되고 있는데, 기존처럼 정적으로 초기화하는 게 아니라 에이전트가 사용자를 인터뷰하면서 스킬과 훅 설정을 함께 잡아주는 방식입니다. 에이전트 온보딩 자체를 바꾸려는 시도예요. 이 세 가지를 놓고 보면, 코딩 도구 간의 격차가 줄어들고 있다는 게 보입니다. 특화 모델이 범용 모델을 이기고, 오픈소스가 상용 도구를 따라잡고, 기존 도구도 빠르게 개편되고 있으니까요. 도구 자체로 차별화하기 어려운 시대가 오고 있는 거죠. AI의 뇌를 열어봤더니, 다 같은 생각을 하고 있었다 도구만 수렴하는 게 아닙니다. 도구 안에 있는 모델의 뇌 구조까지 닮아가고 있어요. Columbia University에서 HELIX라는 논문을 발표했습니다. GPT, Gemini, Qwen, Mistral, Cohere를 분석했는데, 서로 다른 데이터로, 다른 구조로, 다른 목적으로 훈련된 모델들의 내부 표현이 사실상 같은 공간으로 수렴한다는 결과가 나왔습니다. CKA(중심 커널 정렬)라는 유사도 지표로 측정했을 때 0.595에서 0.881 사이. "비슷하다"가 아니라 "거의 같다"에 가까운 수준이에요. 비유하자면, 서로 다른 학교를 졸업한 학생들한테 같은 시험을 봤더니 답안지가 거의 같았다는 거죠. 가르친 선생님도 다르고, 교과서도 다르고, 학교 문화도 다른데 말이에요. 이게 단순히 흥미로운 발견에 그치지 않습니다. 실용적인 돌파구가 열려요. 기존에 민감한 데이터를 AI에 보내려면 무거운 암호화가 필요했습니다. 쿼리당 280GB 통신, 60초 레이턴시. 사실상 쓸 수 없는 수준이었죠. HELIX는 모델 간 내부 표현이 같다는 점을 이용해서, 내 데이터를 한 모델로 인코딩하고 다른 모델로 디코딩하는 방식을 만들었습니다. 결과는 쿼리당 1MB 미만, 서브초 레이턴시로 동등한 보안을 달성. 헬스케어, 금융, 법률처럼 데이터를 밖에 못 보내서 AI 도입이 막혀있던 분야에 큰 영향을 줄 수 있는 연구입니다. 도구도 비슷해지고, 그 도구 안의 모델도 같은 방식으로 생각하고 있다면. 그러면 대체 차이는 어디서 나오는 걸까요. 그러면 차이는 어디서 나오나 Andrej Karpathy가 최근 팟캐스트에서 한 말이 여기에 힌트를 줍니다. "2024년 12월을 기점으로 내 직접 코딩 비중이 80%에서 거의 0%로 ...

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에서 흥미로운 글이 주목받고 있습니다. "프레임워크는 에이전트를 어떻게 실행하는지 알려주지만, 어떻게 생각해야 하는지는 알려주지 ...