이번 주 AI 도구 및 오픈 소스 모델에서 주목한 다섯 가지 사항

운영 측면에서 저에게는 조금 가벼운 한 주였습니다. 콘텐츠 새로고침, YouTube 분석 업데이트, 그리고 Bluesky 대기열 유지보수 작업이 있었죠. 덕분에 실제로 글을 읽을 수 있는 시간이 더 많아졌습니다. 기억에 남는 다섯 가지 항목을 소개합니다.

1. Claude Code Agent View는 사고 모델(mental model)을 변화시킵니다. Anthropic은 5월 11일에 Claude Code 내부에 Agent View를 출시했습니다. 이는 여러 개의 병렬 Claude Code 세션을 관리하기 위한 통합 대시보드입니다. 세션을 시작하고, 백그라운드로 보내고, 원할 때 결과를 확인하는 식이죠. 이 인터페이스는 개별 세션을 CI 대시보드가 빌드(build)를 처리하는 방식과 유사하게 다룹니다. 저는 그동안 서로 다른 작업 디렉토리를 가진 여러 터미널을 열어 Claude Code를 실행해 왔습니다. 작동은 하지만, 탭 사이의 컨텍스트 스위칭(context-switching) 비용이 빠르게 쌓입니다. 터미널 전환 없이 각 에이전트가 무엇을 하고 있는지 보여주는 UI는 단순한 삶의 질 개선을 넘어, Claude Code를 "스마트 터미널"에서 "오케스트레이션 레이어(orchestration layer)"로 전환시킵니다. 이것이 제가 생각하는 AI 코딩 도구가 나아가는 방향입니다. 문제는 AI와 코드에 대해 유용한 대화를 나눌 수 있느냐가 아닙니다. 별개의 작업 묶음을 대기열에 걸어두고, 잠시 자리를 비웠다가 돌아왔을 때 실행 가능한 결과물을 얻을 수 있느냐입니다. Agent View는 그 질문에 대한 초기 답변입니다.

2. AMD 하드웨어로 학습된 ZAYA1-8B는 공급망의 신호입니다. Zyphra는 5월 6~7일경 Apache 2.0 라이선스로 ZAYA1-8B를 공개했습니다. 이는 전문가 혼합(Mixture-of-Experts, MoE) 아키텍처로, 총 파라미터는 약 8B이며 토큰당 활성 파라미터는 약 760M입니다. 표준적인 MoE 효율성 계산 방식입니다. 표준적이지 않은 점은 전체 학습 과정에 AMD Instinct 하드웨어를 사용했다는 것입니다. 진지한 오픈 웨이트(open-weights) 학습은 거의 예외 없이 NVIDIA H100 또는 A100에서 수행됩니다. Zyphra가 깨끗한 Apache 라이선스를 가진 경쟁력 있는 추론 모델을 AMD에서 엔드 투 엔드(end-to-end)로 학습하여 출시한 것은 "쓸만한 것을 학습하려면 NVIDIA가 필요하다"라는 명제에 대한 구체적인 반례입니다. 이것이 AMD가 대규모로 활용될 만큼 빠르게 추격하고 있다거나, 저의 다음 파인튜닝(fine-tune)이 Instinct 하드웨어에서 더 빠를 것이라는 의미는 아닙니다. 다만 오픈 소스 학습 분야의 GPU 단일 문화(monoculture)에 검증 가능한 균열이 생겼음을 의미합니다.

다른 소규모 연구소들이 이를 따르는지 지켜보고 있습니다. 3. Harness 생산성 보고서의 숨겨진 핵심 내용(buried lede): Harness는 5월 13일에 '2026 엔지니어링 탁월성의 상태(The State of Engineering Excellence 2026)'를 발표했습니다. 헤드라인은 다음과 같습니다: 엔지니어링 리더의 89%가 개발자 생산성 향상을 보고했으며, 88%가 AI 코딩 도구를 도입한 이후 만족도가 향상되었다고 답했습니다. 이 헤드라인은 예측 가능한 수준입니다. AI 도구에 관한 모든 벤더 설문조사가 똑같은 말을 합니다. 정말 읽어볼 가치가 있는 부분은 숨겨진 발견 사항입니다: AI가 조직에서 생산성을 추적하는 데 사용하는 측정 프레임워크(measurement frameworks)를 앞질렀다는 점입니다. 기존의 DORA 지표 — 배포 빈도(deployment frequency), 변경 실패율(change failure rate), 평균 복구 시간(MTTR), 리드 타임(lead time) — 는 인간이 처음부터 코드를 작성하는 대신 AI가 생성한 결과물을 검토하고 조종하는 워크플로를 위해 설계되지 않았습니다. 만약 당신이 개발 도구(dev tooling)를 구축하고 있으며 현재 엔지니어링 리더들에게 판매하려고 한다면, "AI가 우리를 더 빠르게 만들었습니다"라는 말은 기본 조건(table stakes)일 뿐입니다. "대신 무엇을 측정해야 하는지, 그리고 이를 팀을 위해 어떻게 시각화할 수 있는지"가 실제로 승부를 걸어볼 만한 제품 전략입니다. 4. ServiceNow Build Agent가 Claude Code 및 Cursor 내에서 GA(General Availability)로 출시됨: ServiceNow는 5월 13일에 Build Agent가 ServiceNow Studio에서 정식 출시(GA)되었으며, 거버넌스 기본 설정(governance defaults on)과 함께 핵심 기술을 Claude Code, Cursor, Windsurf, GitHub Copilot으로 확장했다고 발표했습니다. 개발자들은 자신의 환경을 벗어나지 않고도 자신의 에디터에서 ServiceNow API를 사용하여 빌드할 수 있습니다. 여기서 흥미로운 설계 결정은 '기본 제공되는 거버넌스(governance-by-default)' 선택입니다. 대부분의 IDE 통합은 개발자에게 모든 제어권을 넘기고 IT 부서가 별도로 가드레일(guardrails)을 구성할 것이라고 가정합니다. ServiceNow의 베팅은 기업 구매자들이 플랫폼의 액세스 제어(access controls)와 감사 추적(audit trails)이 도구와 함께 자동으로 따라오기를 원한다는 점입니다. 기능 목록만으로는 판매하기 더 어렵지만, 이 베팅이 적중한다면 더 강력한 해자(moat)가 될 것입니다. 5. 내 파이프라인에서 MCP 서버를 제거했더니 신뢰성이 높아짐: 이것은 개인적인 경험입니다. 이번 주에 내 콘텐츠 파이프라인에서 여러 MCP 서버 연결을 제거했습니다 (커밋 메시지는 "i-removed-mcp-servers-and-my-pipeline-got-more-reliable"였으며, 이것이 거의 모든 것을 설명합니다).

MCP 서버는 실질적인 기능을 추가합니다. 하지만 동시에 네트워크 타임아웃, 예고 없이 원격 API가 변경될 때 발생하는 스키마 드리프트 (Schema drift), 새벽 3시에 조용히 만료되는 인증 토큰과 같은 장애 발생 지점 (Failure surfaces)도 추가합니다. 저의 ETL (Extract, Transform, Load) 프로세스는 cron 스케줄에 따라 무인으로 실행됩니다. 원격 MCP 호출이 중단되면 전체 작업이 중단됩니다. 다음 날 아침 결과를 확인하기 전까지는 항상 알 수 없었습니다. 제가 얻은 교훈은 다음과 같습니다: MCP 통합은 사람이 지켜보고 있으며 장애 발생 시 우아하게 대처할 수 있는 대화형 세션 (Interactive sessions)에는 매우 훌륭합니다. 하지만 예약된 무인 워크플로우 (Unattended workflows)의 경우, 각 외부 의존성은 당신이 깨어 있든 아니든 지불해야 하는 신뢰성 세금 (Reliability tax)과 같습니다. 저는 MCP를 대화형 용도로 유지하고, 프로덕션에 중요한 모든 작업에 대해서는 로컬 폴백 경로 (Local fallback paths)를 구축하고 있습니다. 이는 세 개의 AI 큐레이션 디렉토리 사이트를 운영하는 6개월간의 지속적인 실험의 일부입니다. 여기에 기술적인 주장들은 사실이며, 이 글은 AI의 도움을 받아 작성되었습니다.