오늘도 공부

이제는 AI 한 명이 아니라, 협업하는 AI 팀을 설계할 때다불과 얼마 전까지만 해도 개발자에게 필요한 AI는 “질문에 잘 답하는 챗봇 하나”였습니다. 그런데 2026년의 흐름은 확실히 다릅니다. 지금 커뮤니티가 주목하는 건 더 똑똑한 단일 모델이 아니라, 역할이 다른 여러 에이전트를 어떻게 조합하고 협력시킬 것인가입니다. dev.to에서 화제가 된 CopilotKit + LangGraph 조합은 바로 이 지점을 겨냥합니다. 하나의 거대한 프롬프트로 모든 걸 해결하려는 대신, 요약 에이전트, 질의응답 에이전트, 코드 생성 에이전트를 분리하고 그래프 형태로 연결해 실서비스에 가까운 구조를 만듭니다. LangGraph는 장기 실행·상태 관리·복구 가능한 워크플로를 위한 오케스트레이션 프레임워크이고, Copi..

AI 코딩 도구를 오래 써본 개발자일수록 어느 순간 비슷한 문제를 겪습니다.모델이 똑똑하지 않아서가 아니라, 너무 많은 터미널 출력이 컨텍스트를 잡아먹기 때문입니다.git status, cargo test, npm install, docker logs 같은 명령은 사람에게도 장황한데, LLM에게는 더 치명적입니다. 중요한 건 실패 원인 한 줄인데, 실제로는 수백 줄의 부가 로그가 같이 들어갑니다. RTK는 바로 그 지점을 찌릅니다. 명령 자체를 바꾸는 것이 아니라, 명령 출력이 LLM에게 전달되기 전에 압축하고 정리하는 프록시 계층을 둬서 세션을 더 길게, 더 싸게, 더 안정적으로 만드는 도구입니다. RTK는 Rust로 작성된 단일 바이너리 CLI이며, 저장소 설명 기준으로 일반적인 개발 명령에서 LLM..

GPT-4급 API 없이도 된다9B 로컬 모델을 멀티스텝 에이전트로 바꾼 10가지 아키텍처 최적화작은 모델은 원래 “말은 그럴듯하게 하지만 끝까지 일을 완수하진 못하는” 경우가 많습니다.특히 로컬 환경에서 돌리는 7B~9B급 모델은 채팅은 가능해도, 파일을 읽고, 툴을 부르고, 중간 결과를 정리하고, 다시 다음 행동을 선택하는 에이전트형 작업으로 들어가면 금방 흔들립니다.그런데 최근 한 실험이 꽤 흥미로운 메시지를 던졌습니다.더 큰 모델로 갈아타지 않고도, 그리고 비싼 API를 붙이지 않고도, 아키텍처를 잘 설계하면 9B 로컬 모델도 실제 작업을 끝내는 에이전트처럼 동작할 수 있다는 겁니다. 작성자는 qwen3.5:9b를 NVIDIA RTX 5070 Ti에서 돌리며, 프롬프트 구조화·툴 출력 압축·메모리..

AI 코딩 도구가 좋아질수록 역설적으로 팀의 개발 방식은 더 산만해진다.누군가는 Claude Code를 쓰고, 누군가는 Cursor를 쓰고, 또 누군가는 Codex나 OpenCode를 쓴다. 문제는 모델 성능이 아니라 프로젝트 맥락이 계속 흩어진다는 것이다. 규칙은 CLAUDE.md에 있고, 작업 문맥은 이슈에 있고, 지난 세션의 결정은 채팅창에 남아 있고, 다음 날 다시 열면 AI는 또 처음부터 설명을 요구한다.Trellis는 바로 이 문제를 겨냥한다. 새로운 에이전트 모델이 아니다. 더 똑똑한 IDE도 아니다. 대신 AI가 프로젝트를 이해하는 방식 자체를 파일과 워크플로로 구조화한다. 한마디로 말하면, “프롬프트를 잘 쓰는 법”이 아니라 “AI가 팀의 개발 프로세스를 따라오게 만드는 법”에 가깝다. ..

AI 코딩 에이전트가 좋아졌다고 해서, 바로 팀으로 일도 잘하는 것은 아닙니다.오히려 실무에서는 더 어려운 문제가 남습니다.“어떤 역할로 에이전트를 나눌지”, “어떤 순서로 협업시킬지”, “각 에이전트에게 어떤 스킬을 줘야 할지”, “정말 이 구성이 성능을 높였는지 어떻게 검증할지” 같은 문제입니다. Harness는 바로 이 지점에 들어옵니다. 이 프로젝트는 새로운 에이전트 런타임을 만드는 도구가 아니라, 도메인별 에이전트 팀과 스킬을 설계·생성하는 메타 스킬로 설계되어 있습니다. Claude Code 안에서 “이 프로젝트용 하네스를 만들어줘”라고 말하면, .claude/agents/와 .claude/skills/ 구조를 자동으로 만들어 주는 식입니다. (GitHub) GitHub - revfactor..

AI 코딩 에이전트가 점점 똑똑해지면서, 이제 문제는 “에이전트가 코드를 잘 짜는가”가 아니라 “그 에이전트를 팀 안에서 어떻게 운영할 것인가”로 넘어가고 있습니다. 채팅창에서 한 번 요청하고 끝나는 수준이 아니라, 이슈를 받고, 상태를 바꾸고, 댓글을 남기고, 실제 로컬 코드베이스에서 작업까지 수행하는 존재로 다뤄야 하기 때문입니다. Multica는 바로 그 지점을 겨냥합니다. 이 프로젝트는 AI를 보조 도구가 아니라 프로젝트 관리 시스템의 정식 팀원으로 끌어올리려는 시도입니다. (GitHub) multica/README.md at main · multica-ai/multicaContribute to multica-ai/multica development by creating an account on..

LLM이 텍스트를 범용적으로 다루기 시작한 뒤, 개발자들은 자연스럽게 같은 질문을 던지게 됐습니다. “시계열에도 GPT 같은 기반 모델이 가능할까?” TimesFM은 그 질문에 꽤 실용적인 답을 내놓은 프로젝트입니다. 전통적인 예측 모델처럼 데이터셋마다 새로 학습시키는 대신, 이미 사전학습된 시계열 파운데이션 모델을 가져와 바로 예측에 쓰는 흐름을 보여줍니다. (GitHub)이 저장소는 Google Research가 공개한 시계열 예측용 오픈소스 구현체입니다. 최신 공개 버전 기준으로 TimesFM 2.5를 중심으로 하고 있고, PyTorch와 Flax 백엔드를 모두 염두에 둔 구조를 가지며, Hugging Face에서 사전학습 체크포인트를 불러와 추론하는 방식으로 사용됩니다. 저장소 README는 이것..

오디오 생성은 이미지 생성보다 훨씬 까다롭습니다.이미지는 한 번에 2D 공간을 보면 되지만, 오디오는 아주 긴 시간축, 미세한 파형 변화, 장기 구조, 샘플레이트 변환, 텍스트 조건부 생성까지 한꺼번에 해결해야 합니다. 그래서 많은 프로젝트가 특정 태스크 하나에만 집중합니다.그런데 audio-diffusion-pytorch는 조금 다르게 접근합니다.이 프로젝트는 “텍스트로 음악 만들기” 같은 데모용 모델 하나를 내놓는 대신, 오디오 생성 실험에 필요한 공통 부품을 라이브러리 형태로 정리해 둡니다. 무조건 생성기만 있는 것이 아니라, 무조건 생성, 텍스트 조건부 생성, 업샘플링, 보코더, 오토인코더, 인페인팅까지 하나의 PyTorch 인터페이스로 묶어 둔 점이 이 프로젝트의 핵심입니다. (GitHub) ..

AI 코딩 에이전트 시대에 더 무서운 변화는 “새 기능을 빨리 붙이는 것”이 아닙니다.진짜 변화는 오래된 소프트웨어의 설계 한계를 더 이상 존중하지 않아도 된다는 데 있습니다.Cloudflare의 EmDash가 흥미로운 이유가 바로 여기 있습니다. WordPress는 여전히 웹의 거대한 비중을 차지합니다. 2026년 4월 기준 W3Techs 통계에서 WordPress는 전체 웹사이트의 약 43%대, 알려진 CMS 중 약 60% 안팎을 차지합니다. 그런데 그 성공의 대가로, 플러그인과 테마가 코어와 너무 깊게 얽힌 구조도 함께 굳어졌습니다. EmDash는 이 문제를 “운영 잘하자” 수준으로 덮지 않고, 애초에 플러그인이 위험해질 수밖에 없는 실행 모델 자체를 폐기합니다. (W3Techs)이 프로젝트가 왜 ..

@mariozechner/pi-coding-agent가 제공하는 pi CLI는 확장(extensions) 으로 동작을 바꿀 수 있습니다. 서드파티 패키지 pi-subagents 도 “npm 패키지 + package.json의 pi 메타데이터 + ExtensionAPI” 조합으로 구현된 확장입니다.이 문서는 확장이 무엇인지, 파일·패키지 구조, pi-subagents가 하는 방식, SDK에 끼워 넣는 방법까지 한 번에 정리합니다.공식 세부 스펙은 upstream pi-mono 의 extensions.md · packages.md 를 함께 보세요.1. 확장이란 무엇인가TypeScript 모듈 하나(또는 디렉터리의 index.ts)가 기본 내보내기(default export) 로 함수를 내보냅니다.그 함수는 ..