# \#mit-license **URL:** https://discuss.pytorch.kr/tag/mit-license/2317.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [AgentCraft: Claude 에이전트 팀의 코딩 작업을 Minecraft 스튜디오에서 지켜보고 병합하는 모드](https://discuss.pytorch.kr/t/agentcraft-claude-minecraft/12101)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 6, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/agentcraft-claude-minecraft/12101 "2026-10-06T03:30:35Z")
핵심 요약 AgentCraft는 Claude 에이전트 여러 개가 실제 git 저장소에서 계획, 구현, 리뷰를 나눠 맡는 과정을 Minecraft: Java Edition 안의 스튜디오 화면으로 보여주는 Fabric 모드와 오케스트레이터입니다. 리드 에이전트가 목표를 작업으로 나누고, 작업자 에이전트는 작업마다 별도의 git 워크트리에서 코드를 고치며, 변경 사항은 사용자가 게임 안의 리뷰 화면에서 Merge 를 눌러야만 내 브랜치에 들어갑니다. 에이전트의 git push 는 명령 필터뿐 아니라 git 설정 수준에서도 막혀 있고, 워크트리 밖 쓰기, 네트워크 접근, 파괴적인 명령은 게임 안의 권한 요청으로 넘어옵니다. Windows 또는 macOS, Java 25, Node 22 이상, Minecraft: Java Edition 정품이 필요하고, 실제 에이전트를 실행하면 Claude API 사용량만큼 비용이 듭니다. 아직 개발용 클라이언트로만 실행되며, 저자는 한 사람이 한 대의 컴퓨터에서 써 본 단계라고 밝히고 있습니다. AgentCraft 소개 코딩 에이전트를 여러 개 동시에 실행하면 사람이 보게 되는 것은 보통 터미널 창 여러 개에 흘러가는 텍스트입니다. 어느 에이전트가 어떤 파일을 읽고 있는지, 누가 막혀 있는지, 누가 내 판단을 기다리는지를 알려면 창을 하나씩 열어 로그를 거슬러 읽어야 합니다. 에이전트가 많아질수록 이 확인 작업이 늘어나고, 결과물을 내 브랜치에 들여도 되는지 판단하는 시점도 놓치기 쉽습니다. 이번에 소개하는 AgentCraft는 이 상황을 Minecraft 안의 사무실 공간으로 바꾸어, Claude 에이전트 팀이 일하는 모습을 걸어 다니며 확인하고 병합 여부를 직접 결정하게 하는 프로젝트입니다. AgentCraft에서 사용자는 콘솔에 목표 하나를 입력합니다. 리드 에이전트가 저장소를 읽고 계획을 세워 작업 카드를 벽에 붙이면, 작업자 에이전트들이 자기 책상으로 걸어가 각자의 git 워크트리(worktree)에서 코드를 작성… --- ## [BrowserSkill: 사람이 사용하던 브라우저 상태 그대로 에이전트에게 사용할 수 있도록 하는 CLI 도구](https://discuss.pytorch.kr/t/browserskill-cli/11936)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 17, 2026, 8:30오전 UTC](https://discuss.pytorch.kr/t/browserskill-cli/11936 "2026-09-17T08:30:37Z")
BrowserSkill 소개 AI 에이전트가 브라우저를 직접 조작하게 하려면 보통 둘 중 하나를 감수해야 합니다. 매번 새 프로필로 로그인부터 다시 하는 헤드리스(headless) 브라우저를 쓰거나, 에이전트가 사용자의 실제 브라우저 창을 그대로 가져가 사람이 다른 작업을 하지 못하게 막는 방식입니다. 로그인이 필요한 사내 도구나 SaaS 관리 화면을 다루는 작업일수록 전자는 매번 인증 절차에 막히고, 후자는 에이전트가 작업하는 동안 정작 사람은 컴퓨터를 비워 둬야 합니다. BrowserSkill은 이미 로그인된 사용자의 실제 브라우저를 별도의 창으로 빌려주어, 로그인 세션은 재사용하면서도 사용자의 작업은 방해하지 않는 CLI 기반 브라우저 자동화 도구입니다. BrowserSkill의 핵심 구조는 bsk라는 명령줄 인터페이스(CLI)와 브라우저 확장(extension)의 조합입니다. 에이전트는 셸 명령으로 bsk를 호출하고, bsk는 로컬 데몬(daemon)을 거쳐 브라우저 확장에 작업을 전달합니다. 이때 실제 조작은 사용자의 평소 창이 아니라 별도로 열리는 "에이전트 창(Agent Window)" 안에서만 일어나며, 에이전트가 사용자의 기존 탭을 건드리려면 명시적으로 탭을 "빌린(borrow)" 뒤 작업이 끝나면 돌려줘야 합니다. Claude Code, Cursor, Codex처럼 셸 명령을 실행할 수 있는 에이전트라면 특정 프레임워크나 모델에 종속되지 않고 bsk CLI로 BrowserSkill을 사용할 수 있습니다. 캡차, 로그인, 확인 대화상자처럼 사람만 처리할 수 있는 단계에 부딪히면 에이전트가 사용자에게 개입을 요청하고, 처리가 끝나면 다시 작업을 이어받는 휴먼인더루프(human-in-the-loop) 동작도 기본으로 제공합니다. macOS(Apple Silicon/Intel), Linux(x64/ARM64), Windows x64를 지원하며, 브라우저는 Chrome과 Microsoft Edge를 지원합니다. BrowserSkill … --- ## [hayamimi: GPU와 클라우드 없이 CPU만으로 실시간 다국어 자막을 만드는 음성 인식 도구](https://discuss.pytorch.kr/t/hayamimi-gpu-cpu/11798)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 7, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/hayamimi-gpu-cpu/11798 "2026-09-07T03:30:19Z")
hayamimi 소개 회의나 방송을 실시간으로 받아 적어야 하는 상황에서 지금 선택할 수 있는 길은 대체로 두 가지입니다. 하나는 클라우드 음성 인식(Speech Recognition, ASR) API를 붙여 분당 요금을 내는 것이고, 다른 하나는 Whisper 계열 모델을 로컬에 올려 GPU에서 실행하는 것입니다. 두 번째 길에서 GPU를 뺄 수 없다는 점이 문제가 됩니다. 노트북과 사무용 데스크톱에는 대개 쓸 만한 GPU가 없고, 그렇다고 CPU에서 Whisper를 실행하면 실시간에 못 미쳐 자막이 말보다 늦게 따라옵니다. 발화가 끝나고 한참 지나서 글자가 표시되는 자막은 회의 중계나 방송 송출에는 쓸 수 없습니다. 이번에 소개할 hayamimi는 이 제약을 모델 한 개의 성능으로 해결하는 대신, 발화마다 언어를 판별해 그 언어 전용 모델로 보내는 라우팅으로 우회하는 프로젝트입니다. 모든 모델은 INT8로 양자화(Quantization)된 ONNX 형태이고 sherpa-onnx 런타임(Runtime)에서 실행되므로, PyTorch도 CUDA도 설치하지 않습니다. 저장소 이름인 早耳(하야미미)는 일본어로 소식을 빨리 듣는 사람을 뜻하는데, 개발자는 이를 설계 목표로 삼았다고 설명하고 있습니다. 말하는 중에 임시 자막이 먼저 표시되고, 말을 멈춘 뒤 약 100밀리초 후에 확정 자막이 확정되는 동작이 그 목표의 구체적인 형태입니다. hayamimi를 사용하기 위해서는 파이썬 3.10 이상과 ffmpeg만 준비하면 되고, 모델 가중치는 저장소에 들어 있지 않아 설치 스크립트가 원 배포처에서 내려받습니다. 개발과 테스트는 Windows 11에서 이뤄졌고 macOS와 Linux는 런타임이 모두 크로스 플랫폼이라 동작할 것으로 보지만 종단 간 CI 검증은 아직 없다고 개발자가 밝혔습니다. 이번 게시물에서는 언어별 라우팅 구조와 두 번 훑기 방식, 그리고 개발자가 같은 음성으로 whisper-large-v3-turbo와 직접 맞붙여 공개한 수치를 정리… --- ## [Sol Advisor: 작업 규모와 위험도에 따라 서브 에이전트 위임 여부를 결정하는 Codex 에이전트 오케스트레이션 플러그인](https://discuss.pytorch.kr/t/sol-advisor-codex/11678)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 1\ **마지막 업데이트:** [8월 21, 2026, 11:30오후 UTC](https://discuss.pytorch.kr/t/sol-advisor-codex/11678 "2026-08-21T23:30:28Z")
Sol Advisor 소개 코딩 에이전트에 서브에이전트를 붙이는 방식이 흔해지면서, 작업을 받으면 일단 여러 개로 쪼개 나눠 주는 구성이 기본값처럼 자리 잡았습니다. 그런데 쪼개는 데도 비용이 듭니다. 명세를 써 주고, 돌아온 결과를 읽고, 그 결과가 정말 맞는지 다시 확인하는 왕복이 생기기 때문입니다. 문제가 한 세션 안에서 끝날 만한 크기였다면 그 왕복이 순수한 낭비이고, 반대로 위험한 변경이었다면 나눠 준 것만으로는 부족해서 독립적인 검토가 따로 필요합니다. 판단해야 하는 것은 "몇 개로 쪼갤까"가 아니라 "이 작업이 위임할 만한 종류인가"입니다. 이번에 소개할 Sol Advisor는 그 판단을 워크플로우의 첫 단계로 정해 둔 OpenAI Codex 전용 플러그인입니다. 작업 도구를 처음 호출하기 전에 어떤 경로로 갈지와 그 이유를 한 번 선언하게 만들고, 선언한 뒤에는 혼자 처리하거나 보조 한 명을 세우거나 독립 검토를 붙이는 네 가지 중 하나로 진행합니다. 기본값은 혼자 처리하는 solo 이고, 보조 에이전트는 기본 최대 한 명입니다. 어느 경로를 골랐든 변경분 전체를 다시 읽고 검증을 다시 실행하는 일은 원래 세션이 맡습니다. 저장소를 만든 Daniel McAteer는 에이전트 엔지니어링을 다루는 Attention Heads 뉴스레터를 함께 운영하고 있습니다. 플러그인은 Codex 마켓플레이스 형식으로 배포되고, 셸 스크립트와 마크다운 스킬 문서, 그리고 보조 에이전트 정의 파일 세 개로 이루어져 있습니다. 사용하려면 최신 Codex CLI 또는 플러그인이 활성화된 ChatGPT 데스크톱 앱, 그리고 jq가 필요합니다. 서브에이전트를 늘리는 방식과 Sol Advisor의 차이 Codex 생태계에는 반대 방향의 접근도 있습니다. Awesome Codex Subagents처럼 역할별로 특화한 서브에이전트를 대량으로 갖춰 두고 필요할 때 골라 쓰는 컬렉션이 그렇고, Claude Code 동적 워크플로우처럼 작업마다 병렬 하네스를 새로 짜는 방식… --- ## [Munder Difflin: 터미널 코딩 에이전트 여러 개를 서로 메시지 주고받는 팀으로 만드는 데스크톱 앱](https://discuss.pytorch.kr/t/munder-difflin/11677)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 21, 2026, 9:00오전 UTC](https://discuss.pytorch.kr/t/munder-difflin/11677 "2026-08-21T09:00:12Z")
Munder Difflin 소개 코딩 에이전트를 하나만 쓸 때는 터미널 윈도우 하나로 충분합니다. 그런데 작업을 나눠 여러 개를 동시에 돌리기 시작하면 사람이 라우터 역할을 하게 됩니다. 여러 터미널 탭을 옮겨 다니며 어느 에이전트가 무엇을 하고 있는지 확인하고, A가 알아낸 내용을 복사해 B에게 붙여 주고, 같은 브랜치를 두 에이전트가 건드려 충돌이 나는지 지켜봐야 합니다. 에이전트가 늘어날수록 그 조율 부담도 같이 늘어나서, 결국 사람이 병목이 됩니다. 이번에 소개할 Munder Difflin은 그 조율을 앱이 맡도록 만든 데스크톱 하네스(Harness)입니다. 이미 설치해 쓰고 있는 터미널 에이전트 명령줄 도구(CLI)를 그대로 감싸서 각각을 하나의 에이전트로 세우고, 그 사이에 우편함과 공유 기억, 그리고 배정을 담당하는 총괄 에이전트를 추가합니다. 사용자는 총괄 에이전트 한 명과만 대화하고, 나머지 배정과 전달은 앱 안에서 일어납니다. 에이전트들은 2D 사무실 화면의 아바타로 표시되어 지금 누가 일하고 있고 누가 누구에게 메시지를 보냈는지 눈으로 확인할 수 있습니다. 기술 구성은 Electron, React, TypeScript 위에 화면용으로 Pixi.js, 터미널 표시에 xterm.js, 실제 프로세스 실행에 node-pty를 쓰는 조합입니다. 지원 대상은 Claude Code, Antigravity(Gemini), OpenAI Codex, xAI Grok, Kimi Code, Qwen, OpenCode, Crush, pi.dev, GitHub Copilot CLI이고 직접 지정한 명령도 에이전트로 세울 수 있습니다. 자체 API 키(BYOK)와 Ollama, LM Studio, vLLM 같은 로컬 모델 서버도 연결할 수 있습니다. 개발자 Chaitanya Giri는 저장소를 아직 작동하는 프로토타입(working prototype) 단계로 표시해 두었습니다. 여러 에이전트를 돌리는 기존 방식과 Munder Difflin의 차이 에… --- ## [Oil Motion: AI 생성 영상을 스크롤과 마우스가 제어하는 웹 애니메이션으로 바꾸는 에이전트 스킬](https://discuss.pytorch.kr/t/oil-motion-ai/11668)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 20, 2026, 11:30오후 UTC](https://discuss.pytorch.kr/t/oil-motion-ai/11668 "2026-08-20T23:30:51Z")
Oil Motion 소개 AI로 만든 영상은 처음부터 끝까지 재생되는 것 말고는 할 수 있는 일이 없습니다. 제품 소개 페이지에서 스크롤을 내릴 때 제품이 단계별로 분해되는 연출을 넣고 싶어도, 생성된 영상을 그대로 삽입하면 사용자가 위로 되돌릴 때 애니메이션은 따라오지 않습니다. 그렇다고 이미지 한 장을 CSS로 움직이고 키우는 방식으로는 관절이 접히고 부품이 서로 가려지고 재질이 바뀌는 변화를 만들 수 없습니다. 결국 프런트엔드 개발자는 영상 생성과 인터랙션 구현 사이 어딘가에서 매번 직접 프레임을 자르고 매핑을 짜게 됩니다. 이번에 소개할 Oil Motion은 그 사이를 메우는 에이전트 스킬(Agent Skill)입니다. 어떤 장면을 만들지 설계하고, AI 영상으로 연속 동작을 생성하고, 프레임을 정리해 웹 자산으로 만들고, 스크롤과 마우스, 드래그, 터치, 기기 방향 같은 입력에 그 자산을 연결하는 데까지를 한 흐름으로 처리합니다. 핵심 발상은 단순합니다. 100프레임짜리 제품 분해 애니메이션이 있을 때 페이지가 30% 스크롤되면 30번째 프레임을, 70% 스크롤되면 70번째 프레임을 보여 주는 식으로 입력 위치를 애니메이션 진행도에 매핑합니다. 마우스와 드래그, 기기 방향도 입력원만 다를 뿐 같은 방식을 씁니다. Oil Motion은 Lin Zhihuang이 MIT 라이선스로 공개했고, Codex와 Claude Code처럼 스킬을 읽어 실행하는 에이전트라면 어디에서든 동작하도록 만들어져 있습니다. 사용자가 직접 실행하는 부분은 거의 없습니다. 무엇을 표현하고 싶은지, 어떤 소재가 있는지, 애니메이션이 무엇을 따라가야 하는지를 말하면 생성과 검사, 압축, 프런트엔드 구현은 에이전트가 맡습니다. 결정적 미디어 파이프라인은 파이썬 스크립트로 되어 있어 Python 3와 Pillow, ffmpeg와 ffprobe가 필요하고, 영상 생성은 외부 API를 호출합니다. 저장소의 문서는 중국어가 기본이지만 영문 README가 별도로 제공됩니다. 기존… --- ## [Wardrobe: 옷 사진에서 옷만 오려내 카탈로그와 착용 컷으로 정리하는 AI 옷장 프로젝트](https://discuss.pytorch.kr/t/wardrobe-ai/11667)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 20, 2026, 9:00오전 UTC](https://discuss.pytorch.kr/t/wardrobe-ai/11667 "2026-08-20T09:00:00Z")
Wardrobe 소개 옷장에 무엇이 있는지 목록으로 만들어 두려고 하면 첫 단계에서 막힙니다. 손에 있는 것은 옷을 입고 찍은 사진이거나 옷걸이에 걸린 채로 찍은 사진인데, 목록에 쓰려면 배경과 착용자를 지우고 옷 하나만 남긴 그림이 필요하기 때문입니다. 사진 한 장에 상의와 하의와 신발이 같이 찍혀 있으면 그 한 장을 세 장으로 쪼개는 일부터 해야 합니다. 이 작업을 손으로 하면 옷 한 벌마다 몇 분씩 걸리고, 그렇게 몇 시간을 쓰고 나면 처음의 의욕이 남아 있지 않습니다. 이번에 소개할 Wardrobe는 이 오려내기 작업을 OpenAI API에 맡기는 로컬 옷장 갤러리입니다. 사진을 넣으면 사진 안의 옷을 한 벌씩 찾아내고, 착용자와 배경을 지운 깨끗한 컷아웃(Cutout)을 만들고, 원하면 그 옷을 입은 착용 컷까지 만들어 냅니다. tandpfun이 공개했고, 원본과 작업 기록, 생성된 이미지, JSON 데이터베이스를 전부 프로젝트 폴더 안의 data/에 남깁니다. 계정을 만들거나 사진을 어딘가에 올려 둘 필요가 없습니다. 다만 검출과 생성은 OpenAI 서버에서 이뤄지므로, 사진 자체는 API 호출로 외부에 전송됩니다. Wardrobe는 React 19와 Vite 6로 만든 단일 페이지 앱에 이미지 처리를 담당하는 Node 스크립트를 얹은 구조입니다. 이미지 리사이즈에는 sharp와 ipx를 쓰고, 화면 쪽에서는 @unpic/react로 반응형 이미지를 그립니다. 실행에는 Node 22 이상이 필요하고, 서버를 따로 두지 않으므로 데이터베이스 설치 과정도 없습니다. 저장소는 MIT 라이선스로 공개되어 있고, 유료 요금제나 관리형 서비스는 따로 없습니다. 비용은 사용자가 자기 OpenAI 키로 부담하는 API 사용료뿐입니다. Wardrobe가 옷 사진을 처리하는 과정 Wardrobe의 처리 과정은 네 단계로 나뉩니다. 먼저 OpenAI Responses API가 사진 한 장에서 옷을 하나씩 검출합니다. 그다음 OpenAI Images AP… --- ## [Cumora: AI 에이전트들과 업무를 나누고 진행 상황을 공유하는 에이전트 팀을 위한 채팅 앱](https://discuss.pytorch.kr/t/cumora-ai/11666)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 20, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/cumora-ai/11666 "2026-08-20T03:30:20Z")
Cumora 소개 팀 협업 도구에 AI를 들이는 방식은 대체로 채팅방 한쪽에 봇을 하나 붙이는 형태였습니다. 사람이 멘션으로 부르면 답하고, 답이 끝나면 그 대화는 거기서 끊깁니다. 그런데 봇을 두 개 이상 연동하면 다른 문제가 생깁니다. 같은 방에 있는 여러 에이전트가 같은 메시지를 각자 읽고 각자 판단하기 때문에, 둘이 같은 순간에 깨어나 같은 내용을 나란히 올리는 충돌이 일어납니다. Cumora 개발팀은 이 상황을 서버가 잡아낼 수 있는 경합 충돌(Race Collision)과 프롬프트로만 다룰 수 있는 판단 오류(Brain Misjudgment) 두 가지로 나눠 정리하고 있습니다. 이번에 소개할 Cumora는 AI 에이전트를 채팅방의 정식 참가자로 두는 크로스 플랫폼 팀 채팅 앱입니다. 에이전트는 사람과 같은 멤버 목록, 같은 DM(Direct Message), 같은 그룹 대화, 같은 칸반 보드와 캘린더를 씁니다. 각 에이전트는 자기 역할과 말투를 정한 페르소나(Persona)와 개인 작업 공간의 기억(Memory)을 유지하고, 호출을 기다리지 않고 스스로 대화를 시작하거나 다른 에이전트에게 DM을 보냅니다. 프로젝트를 공개한 yetone은 에이전트의 두뇌를 두 갈래로 나눠 두었습니다. 하나는 OpenAI Responses API 위에서 도는 관리형 클라우드이고, 다른 하나는 사용자의 맥이나 VPS에서 Claude Code 또는 Codex CLI를 그대로 두뇌로 쓰는 BYOA(Bring Your Own Agent) 방식입니다. Cumora의 코드베이스는 하나의 저장소 안에서 클라이언트와 서버, 에이전트 런타임(Runtime)을 모두 담고 있습니다. 화면은 React 18과 Vite, TypeScript, Tailwind로 만든 단일 컴포넌트 집합 위에 데스크톱과 모바일, 웹, 관리자 셸을 얹는 구조이고, 데스크톱은 Electron, iOS와 안드로이드는 Capacitor 네이티브 셸을 씁니다. 서버는 Express와 ws 기반의 무상태 노… --- ## [phone-harness: Xcode나 WebDriverAgent 없이 AI 에이전트가 실제 아이폰을 조작하는 도구](https://discuss.pytorch.kr/t/phone-harness-xcode-webdriveragent-ai/11644)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 19, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/phone-harness-xcode-webdriveragent-ai/11644 "2026-08-19T03:30:29Z")
phone-harness 소개 아이폰에서만 되는 일이 아직 많습니다. iOS 전용 앱, 사용자의 전화번호에 묶인 2단계 인증, 실제 기기에서만 확인되는 화면 배치 같은 것들입니다. 그런데 AI 에이전트에게 이 일을 맡기려면 준비물이 갑자기 무거워집니다. 실기기 iOS 자동화는 보통 Xcode 프로젝트를 만들어 서명하고 WebDriverAgent 같은 자동화 서버를 기기에 올리는 과정을 거치며, 그마저도 인증서가 만료되면 다시 손봐야 합니다. 에이전트에게 시키고 싶은 일은 "메모 앱을 열고 한 줄 적어 줘" 정도인데, 그 앞에 놓인 설정이 본 작업보다 큽니다. phone-harness는 이 준비물을 통째로 건너뛰는 방향을 택한 도구입니다. macOS Sequoia 이상에서 제공되는 iPhone 미러링 창 하나를 통로로 삼아, 맥에 연결된 실제 아이폰을 AI 에이전트가 직접 조작하게 합니다. 미러링 창은 아이폰 화면을 맥의 창으로 띄우고 맥의 마우스·키보드 입력을 실제 터치로 전달하는데, phone-harness는 여기에 눈과 손을 더합니다. 눈은 창을 캡쳐해 Vision 프레임워크로 글자를 읽는 OCR(광학 문자 인식, Optical Character Recognition)이고, 손은 HID(Human Interface Device) 계층에 직접 이벤트를 넣는 CGEvent입니다. 저장소는 이 구조를 두고 탈옥도, Xcode도, WebDriverAgent도 필요 없다고 밝히고 있습니다. phone-harness는 Python으로 작성되어 있고, 저자는 핵심부를 src/phone\_harness/ 아래 약 500줄 규모로 유지한다고 설명합니다. 미러링 통로 자체가 상태를 갖지 않아서 창 위치와 화면 캡쳐를 호출할 때마다 다시 조회하며, 그래서 백그라운드에 상주하는 데몬이 없고 매 실행이 독립적으로 끝납니다. 부족한 기능은 에이전트가 실행 도중 agent-workspace/agent\_helpers.py에 직접 써 넣도록 열어 두었고, 이 파일은 모든 스크립트… --- ## [Magic Context: 세션을 끊지 않고 프로젝트 지식을 쌓는 코딩 에이전트용 메모리 플러그인](https://discuss.pytorch.kr/t/magic-context/11645)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 18, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/magic-context/11645 "2026-08-18T21:30:43Z")
Magic Context 소개 코딩 에이전트와 오래 작업하면 두 번 손해를 봅니다. 대화가 길어져 컨텍스트 창이 차면 에이전트는 지금까지의 기록을 압축(compaction)하려고 작업을 멈추고, 압축이 끝난 뒤에는 알고 있던 것 일부가 조용히 사라집니다. 그리고 세션을 닫으면 남는 것이 없어서, 다음 작업은 이 프로젝트를 처음 보는 사람으로 다시 시작합니다. Magic Context의 저자는 이 상태를 "anterograde amnesia", 즉 새 기억을 만들지 못하는 전향성 기억상실에 빗대면서, 좋은 개발자를 버그 하나 고칠 때마다 새로 뽑고 내보내지는 않는다고 지적합니다. Magic Context는 이 두 손해를 배경 작업으로 함께 해결하려는 플러그인입니다. 프로젝트는 스스로를 코딩 에이전트의 해마(hippocampus), 곧 기억을 만들고 정리하고 다시 꺼내는 부위라고 소개하며, 두 가지를 약속합니다. 에이전트가 컨텍스트를 관리하려고 멈추는 일이 없고, 알게 된 것을 잊지 않는다는 것입니다. 압축을 걷어내는 방식이 아니라, 압축을 호스트에서 가져와 배경에서 조금씩 처리하는 방식이라는 점이 핵심입니다. 그래서 설치 마법사는 호스트의 내장 압축 기능을 먼저 끕니다. Magic Context는 TypeScript로 작성된 플러그인이고, 지원 대상은 OpenCode와 Pi, Oh My Pi(OMP) 세 가지 호스트입니다. 모든 지속 상태는 로컬 SQLite 데이터베이스 한 개에 담기며, 프로젝트는 이것을 CortexKit라는 더 큰 계획의 한 조각으로 두고 있습니다. 한국어 README가 저장소에 함께 들어 있어서 원문을 한국어로 바로 읽을 수도 있습니다. Magic Context가 컨텍스트를 다루는 방식 Magic Context가 압축 대기를 걷어내는 방법은 압축을 뒤로 미루고 잘게 쪼개는 것입니다. 배경에서 도는 사관(historian)이 오래된 원본 기록을 계층화된 구획(tiered compartment)으로 압축하는데, 각 구획은 시간순 요약… --- ## [hyperresearch: 읽은 자료를 보관해 다음 리서치에 재사용하는 Claude Code용 16단계 조사 파이프라인](https://discuss.pytorch.kr/t/hyperresearch-claude-code-16/11646)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 18, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/hyperresearch-claude-code-16/11646 "2026-08-18T06:30:03Z")
hyperresearch 소개 심층 조사(deep research) 기능을 한 번 써 보면 두 가지가 남습니다. 그럴듯하게 정리된 보고서 하나와, 그 보고서가 정말 근거를 읽고 쓴 것인지 확인할 방법이 없다는 찜찜함입니다. 인용 표기는 있지만 그 문장을 실제로 뒷받침하는지는 알 수 없고, 유료 논문은 초록 1,500자만 읽은 채로 마치 본문을 읽은 것처럼 인용되기도 합니다. 게다가 조사가 끝나면 읽은 자료는 전부 버려지므로, 같은 주제를 다시 조사할 때 처음부터 다시 긁어모아야 합니다. hyperresearch는 이 두 가지를 구조로 막으려는 프로젝트입니다. Claude Code를 심층 조사 에이전트로 바꾸는 파이프라인이고, 하나의 질문을 16단계로 나눠 처리한 뒤 출처 이력이 붙은 보고서를 내놓습니다. 특징은 검증을 사람의 성실성에 맡기지 않고 파이프라인의 게이트로 만들어 둔 점입니다. 인용된 문장과 근거의 결합을 회의적으로 감사하는 단계가 따로 있고, 인용문이 보관된 자료에 그대로 존재하지 않으면 발행이 막힙니다. 프로젝트는 Python으로 작성되어 PyPI에 올라와 있으며, Python 3.11에서 3.13까지를 지원합니다(3.14는 아직 지원하지 않습니다). 실행 자체는 Claude Code의 Skill 도구를 통해 단계별 스킬을 불러들이는 방식이고, 하위 에이전트들은 Anthropic 모델 위에서 돌아갑니다. 저자는 Codex로 옮기고 싶은 사람이 있으면 풀 리퀘스트를 보내 달라고 README에 적어 두었습니다. hyperresearch의 16단계 파이프라인 입구가 되는 스킬은 얇은 라우터입니다. 조사 질의를 확정한 뒤 각 단계를 별도 스킬로 호출하는데, 단계별 절차는 그 단계가 실제로 실행될 때만 컨텍스트에 올라옵니다. 프로젝트는 이것이 긴 파이프라인이 진행 중에 컨텍스트가 상해 단계를 조용히 빠뜨리는 것을 막는 장치라고 설명합니다. 단계와 적용 등급은 다음과 같습니다: # 단계 하는 일 등급 1 Decompose 질… --- ## [DSH Desktop: Node.js 설치 없이 DeepSeek Harness를 실행하는 데스크탑 애플리케이션](https://discuss.pytorch.kr/t/dsh-desktop-node-js-deepseek-harness/11634)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 17, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/dsh-desktop-node-js-deepseek-harness/11634 "2026-08-17T03:30:06Z")
DSH Desktop 소개 코딩 에이전트를 처음 붙잡을 때 시간이 가장 많이 드는 구간은 에이전트 자체가 아니라 그 앞의 준비 과정입니다. DeepSeek AI가 공개한 DeepSeek Harness (:pytorch::kr: DeepSeek Harness: 에이전트 루프까지 설정으로 교체하는 플러그인 구조의 코딩 에이전트)는 명령줄과 웹 UI 양쪽에서 모델과 도구, 세션, 워크플로를 자기 런타임으로 조합할 수 있는 에이전트 하네스(harness)지만, 처음 쓰는 사람에게는 Node.js 설치와 프로필(profile) 준비, 의존성 설치, 포트와 프로세스 수명 관리가 그대로 사용 경험의 일부로 남습니다. 에이전트의 성능을 평가해 보려던 사람이 런타임 환경 설정 단계에서 멈추는 일이 그래서 생깁니다. Anywhere Labs가 공개한 DSH Desktop은 그 준비 과정을 설치 프로그램 하나로 옮긴 macOS·윈도우 데스크톱 앱입니다. 눈에 띄는 선택은 구현 방식 쪽에 있습니다. 이 프로젝트는 업스트림 소스를 포크하거나 고쳐서 전용 셸을 만들지 않고, 창과 트레이, 터미널, 업데이트, 작업 프로필을 담당하는 데스크톱 셸 자체를 하나의 DSH 플러그인으로 만들어 공식 Harness와 같은 런타임에 얹었습니다. 공식 Harness는 고정된 버전 그대로 실행되고, 데스크톱 기능은 공식 플러그인 메커니즘을 통해 그 위에 합성됩니다. 설치 프로그램에는 Electron과 Node 런타임, 고정된 DSH 의존성이 함께 들어갑니다. 앱은 창과 트레이, 단일 인스턴스 잠금, 종료, 로컬 서비스 수명을 직접 관리하고, 사용자는 공식 DSH의 프로필과 플러그인, 세션, 웹 UI를 그대로 씁니다. 에이전트와 모델, 도구, 세션, 웹 클라이언트의 동작은 여전히 업스트림 Harness가 결정합니다. DSH Desktop과 공식 Harness 직접 실행의 차이 DSH Desktop은 Harness를 대체하는 도구가 아니라 실행 방식을 바꾸는 도구입니다. 두 방식이 어느 지… --- ## [Claude of Duty: 단일 프롬프트로 AI 에이전트가 만든 브라우저 FPS 게임 및 품질 검증 하네스](https://discuss.pytorch.kr/t/claude-of-duty-ai-fps/11611)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 14, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/claude-of-duty-ai-fps/11611 "2026-08-14T03:30:03Z")
Claude of Duty 소개 AI 에이전트에게 규모 있는 코드베이스를 맡길 때 먼저 문제가 생기는 쪽은 코드 작성이 아니라 품질 판정입니다. 빌드가 통과하고 화면이 뜨는 지점까지는 에이전트가 스스로 도달합니다. 그런데 "이 정도면 됐다"를 언제, 어떠한 기준으로 선언해야 하는지는 어려운 문제입니다. 이러한 판정 기준이 주관적이면 에이전트를 몇 바퀴 더 돌려도 결과가 나아졌는지 나빠졌는지 말할 수 없고, 루프는 수렴하는 대신 취향 사이를 왕복합니다. Claude of Duty는 품질 판정을 사람의 취향에서 측정 도구로 옮긴 사례입니다. Matt Shumer(@mshumer)가 공개한 이 저장소는 브라우저에서 실행되는 1인칭 슈팅(FPS, First-Person Shooter) 게임으로, Three.js r180과 WebGL2 기반의 11개 서브시스템, 약 55,000줄 규모의 코드로 작성됐습니다. 코드를 쓴 주체는 오케스트레이션 아래 움직인 여러 AI 에이전트들이고, 사람이 넣은 입력은 저장소의 prompt.md 에 그대로 남아 있는 지시문 한 개뿐입니다. 아트 자산은 저장소에 하나도 없습니다. 텍스처와 메시, 애니메이션, 사운드가 전부 로드 시점에 코드로 생성되며, 런타임 의존성은 three 하나입니다. 즉, 이 저장소에서 눈여겨봐야 할 부분은 게임보다는 게임과 함께 커밋된 검증 장치입니다. 저자 스스로 "이 저장소에서 흥미로운 부분은 게임이 아니라 하네스일 것이다" 라고 적었고, 실제로 프레임을 채점하는 적대적 비평가 에이전트, 픽셀 단위로 회귀를 잡는 게이트, 프레임 시간 분포를 보는 프로파일러가 저장소에 들어 있습니다. 본 게시물에서는 이 하네스의 구성과 저자가 기록한 측정값, 그리고 목표에 끝내 도달하지 못한 지점을 정리합니다. Claude of Duty를 만든 지시문 한 개 저장소의 prompt.md 에는 이 코드베이스를 만들어 낸 지시문 전문이 그대로 공개되어 있습니다. I want you to build a first-person … --- ## [thinking-orbs: AI 에이전트가 무엇을 하는 중인지 보여주는 로딩 인디케이터](https://discuss.pytorch.kr/t/thinking-orbs-ai/11616)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 14, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/thinking-orbs-ai/11616 "2026-08-14T00:30:08Z")
thinking-orbs 소개 에이전트를 붙인 화면에서 대기 시간은 예전 웹앱과 성격이 다릅니다. 버튼을 눌러 응답이 오기까지 300밀리초를 기다리는 것과, 에이전트가 저장소를 훑고 도구를 호출하며 수십 초를 쓰는 것은 사용자가 느끼는 종류가 다릅니다. 그런데 화면이 알려 주는 정보는 대개 회전하는 원 하나로 같습니다. 지금 검색하는 중인지, 답을 쓰는 중인지, 아니면 그냥 멈춘 것인지 구분할 단서가 없으면 사용자는 기다림을 고장으로 읽기 시작합니다. thinking-orbs는 그 구분을 로딩 표시 자체에 넣은 React 컴포넌트입니다. 에이전트가 할 수 있는 동작 아홉 가지를 각각 다른 애니메이션으로 손질해 두어서, 같은 점 구체가 탐색할 때와 연결할 때 서로 다르게 움직입니다. 렌더링은 평범한 2D 캔버스 아크만 사용하며 WebGL도, 캔버스나 SVG 필터도 쓰지 않습니다. 개발자는 Chrome과 Safari, Firefox에서 동일하게 동작한다고 밝히고 있습니다. 패키지는 npm 레지스트리에 thinking-orbs 로 올라와 있고, 2026년 8월 13일 확인 시점의 최신 버전은 2026년 8월 11일에 배포된 0.3.1입니다. 런타임 의존성은 없고 React 18 이상을 피어 의존성으로 요구합니다. 본 게시물에서는 아홉 가지 상태의 구성, 크기와 테마를 다루는 방식, 접근성과 성능을 위해 넣은 장치, 그리고 React Native 포트의 검증 방법을 정리합니다. thinking-orbs가 구분하는 아홉 가지 상태 상태는 에이전트가 하고 있을 수 있는 동사 아홉 개로 잡혀 있고, 각각이 별개의 애니메이션입니다. state 프로퍼티에 문자열로 넘기는 형태이며, 개발자가 붙여 둔 움직임 설명이 이름과 짝을 이룹니다. \ {/\* 기울어진 궤도를 도는 입자들 \*/} \ {/\* 점으로 된 구체를 훑는 스캔 자오선 \*/} \ **Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 13, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/h3-c-minimax-h3-c-feat-antirez/11608 "2026-08-13T09:30:02Z") h3.c 소개 영상 생성 모델을 로컬에서 돌려 보려면 대개 대용량 GPU가 있는 장비부터 찾게 됩니다. 가중치가 BF16으로 수십 기가바이트에 이르고, 디노이징 패스를 수십 번 반복해야 짧은 클립 하나가 나오기 때문입니다. 맥에서 시도하더라도 통합 메모리에 모델이 통째로 올라가야 한다는 조건이 먼저 걸립니다. h3.c는 MiniMax의 영상·음향 생성 모델인 H3를 애플 실리콘에서 직접 실행하도록 C와 Metal로 다시 구현한 추론기입니다. 저장소 이름은 h3.c이고 README에서는 h3-metal로 부르며, Redis 개발자로 알려진 antirez(Salvatore Sanfilippo)가 공개했습니다. 프로젝트는 동작하는 수직 슬라이스를 차례로 쌓는 방식으로 만들어지고 있어서, 호스트와 모델 메타데이터 확인, Metal 블록 패리티, 프롬프트 인코딩, 프롬프트에서 영상·음향 생성, 첫 프레임과 끝 프레임 조건화, 순서가 있는 참조 입력이 차례로 완성되었습니다. 현재는 프롬프트에서 영상과 음향을 만드는 경로, 첫·끝 프레임 조건화, 이미지와 영상과 음향을 순서대로 넣는 Ref2VA 참조가 모두 끝에서 끝까지 동작합니다. 진행 중인 작업은 M3 Max와 M5 Max에서의 H3 전용 Metal 성능과 메모리 최적화입니다. h3.c를 쓰기 전에 확인할 모델 가중치 사용 제한 h3.c 자체는 자유롭게 쓸 수 있는 코드지만, 이 도구가 실행하는 MiniMax H3 가중치에는 지역 제한이 걸려 있습니다. MiniMax H3 Community License Agreement는 적용 지역을 "worldwide, excluding the Excluded Territories" 로 정의하고, 제외 지역(Excluded Territories)에 유럽연합과 영국, 대한민국, 미국을 명시합니다. 같은 문서는 제외 지역 안에서 이 저작물과 그 출력물을 사용·복제·수정·배포·전시하는 것이 이 계약으로 허가되지 않는다고 못 박습니다. 배포처인 Hugging Face 모델 카… --- ## [Skill Recorder: Microsoft가 공개한, 화면 녹화를 에이전트 스킬로 바꾸는 도구](https://discuss.pytorch.kr/t/skill-recorder-microsoft/11606)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 13, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/skill-recorder-microsoft/11606 "2026-08-13T06:30:43Z")
Skill Recorder 소개 에이전트에게 반복 업무를 맡기려면 그 업무의 절차를 글로 옮겨 적어야 합니다. 문제는 손에 익은 일일수록 글로 적기 어렵다는 데 있습니다. 스프레드시트를 열고, 거래처 이름을 검색하고, 찾은 내용을 메모 칸에 붙여 넣고, 팀 채널에 요약을 올리는 흐름은 몸이 먼저 움직이는 순서라서 막상 문서로 만들면 창 전환이나 중간 확인 같은 단계가 통째로 빠집니다. 빠진 단계는 그대로 에이전트의 실패 지점이 됩니다. Skill Recorder는 이 순서를 사람이 받아쓰는 대신 실제 작업 한 번을 녹화해 절차로 되짚는 방향을 택한 도구입니다. 화면과 창 전환, 방문한 페이지, 원한다면 음성 설명까지 기록한 다음 GitHub Copilot CLI로 그 기록을 읽어 "무엇을 하려던 작업이었는지" 한 줄과 순서가 매겨진 단계 목록으로 재구성합니다. 저장소는 이 결과물을 "Record yourself doing a task once, then turn it into a skill your AI agent can repeat" 한 문장으로 요약합니다. 재구성된 절차는 두 가지 형태로 저장됩니다. 에이전트가 필요할 때 실행하는 SKILL.md 절차인 스킬(Skill), 그리고 같은 절차를 일정이나 트리거에 걸어 두는 자동화(Automation) 입니다. 둘 다 Electron 기반 데스크톱 앱 안에서 만들어지며, 저장소는 Microsoft가 MIT 라이선스로 공개했습니다. Skill Recorder가 화면 녹화 자동화와 다른 점 화면을 녹화해 업무를 자동화한다는 발상 자체는 오래된 것입니다. 기존 RPA 계열 도구는 대체로 좌표와 클릭을 그대로 기록했다가 같은 자리를 다시 누르는 방식으로 동작했고, 그래서 창 크기가 바뀌거나 버튼 위치가 옮겨지면 쉽게 깨졌습니다. 한 번 녹화한 것이 정확히 그 한 번만 재현된다는 한계도 있었습니다. Skill Recorder는 녹화를 재생 대상이 아니라 해석 대상으로 다룹니다. 저장소가 밝히는 설계 방침은 … --- ## [How to Train Your GPT: LLaMA 3 구조를 밑바닥부터 구현하며 배우는 LLM의 원리와 동작](https://discuss.pytorch.kr/t/how-to-train-your-gpt-llama-3-llm/11599)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 12, 2026, 12:30오후 UTC](https://discuss.pytorch.kr/t/how-to-train-your-gpt-llama-3-llm/11599 "2026-08-12T12:30:35Z")
How to Train Your GPT 소개 언어 모델을 배우려고 자료를 찾다 보면 두 부류로 갈립니다. 한쪽은 라이브러리 호출 몇 줄로 학습을 끝내서 내부에서 무슨 일이 일어나는지 알려주지 않고, 다른 한쪽은 논문 수준의 표기법으로 시작해 선형대수 기초가 없으면 첫 페이지에서 막힙니다. 특히 어텐션(Attention)은 "쿼리와 키의 내적을 구한다"는 설명까지는 따라가도, 왜 \\sqrt{d\_k} 로 나누는지, 인과 마스크가 정확히 어느 시점에 적용되는지를 스스로 설명할 수 있는 상태로 넘어가기가 어렵습니다. How to Train Your GPT는 그 간극을 메우려고 만들어진 학습용 저장소입니다. 12개 장, 7,500줄이 넘는 분량의 대화형 교재와 함께 RoPE, 어텐션, RMSNorm, SwiGLU, KV 캐시, AdamW, 혼합 정밀도 같은 개별 기법을 다루는 28개의 독립 해설 문서가 들어 있습니다. 모든 코드에 그 줄이 무엇을 하는지(WHAT)와 왜 필요한지(WHY)를 함께 주석으로 붙여 두었고, 토크나이저부터 임베딩, 어텐션, 학습 루프, 추론 엔진까지 독자가 직접 작성하도록 구성했습니다. 저자는 저장소 첫머리에서 자신이 완전히 이해하지 못했던 부분, 특히 어텐션을 제대로 알기 위해 이 자료를 만들었다고 밝히고 있습니다. 구현 대상은 GPT-2 시절 구조가 아니라 공개적으로 문서화된 최신 디코더 전용 트랜스포머입니다. LLaMA 3와 Mistral, Qwen 계열이 사용하는 RoPE, RMSNorm, SwiGLU, 사전 정규화(Pre-Norm)를 그대로 따라가며, 사전 지식은 파이썬 기초만 요구합니다. 본 게시물에서는 이 교재가 어떤 순서로 진행되는지, 실제 구현 코드가 어떤 모습인지, 그리고 어떤 환경에서 돌려볼 수 있는지를 정리합니다. 기존 학습 자료와 How to Train Your GPT의 차이 저자는 대부분의 머신러닝 튜토리얼이 두 함정 중 하나에 빠진다고 정리하면서, 이 교재의 위치를 다음처럼 설명합니다. 항목 얕은 … --- ## [Bento: HTML 파일 하나에 편집기까지 담아 AI 에이전트가 직접 수정하는 프레젠테이션 도구](https://discuss.pytorch.kr/t/bento-html-ai/11515)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 5, 2026, 12:30오후 UTC](https://discuss.pytorch.kr/t/bento-html-ai/11515 "2026-08-05T12:30:48Z")
Bento 소개 에이전트에게 발표 자료를 맡기려 할 때 가장 먼저 막히는 것은 파일 형식입니다. .pptx 는 압축된 XML 묶음이라 손으로 고치기 번거롭고, 클라우드 문서 도구는 API 키와 권한 설정을 거쳐야 접근이 열립니다. 그래서 슬라이드를 만들어 주는 도구들은 대개 자체 서비스를 하나 세운 뒤, 그 안에서 생성한 결과를 내보내는 방식을 택해 왔습니다. Bento는 문서와 편집기, 뷰어, 발표 모드를 HTML 파일 하나 에 함께 넣는 방향을 택했습니다. .bento.html 파일을 브라우저로 열면 그 파일 자체가 편집기가 되고, 저장하면 파일이 자기 안의 데이터 블록을 다시 써서 스스로를 갱신합니다. 받는 사람은 아무것도 설치할 필요가 없습니다. 셸 전체가 약 560KB로 압축되어 있고, 문서 데이터는 파일 앞쪽의 평문 JSON 블록에 그대로 남습니다. 이 구조가 AI 도구와 잘 맞는 이유가 여기에 있습니다. 문서가 이진 형식이 아니라 파일 안의 평문 JSON이므로, 파일을 읽고 쓸 수 있는 도구라면 플러그인도 API도 없이 슬라이드를 편집할 수 있습니다. nyblnet 이 2026년 7월 공개했고, bento/slides 는 현재 v1.0.15까지 배포되어 있습니다. Bento를 AI 에이전트와 함께 쓰기 들어가는 길은 두 갈래입니다. 첫째는 파일 시스템에 접근할 수 있는 에이전트가 #bento-doc 블록의 JSON을 그 자리에서 고치는 방식으로, Claude Code와 Cursor, Aider 등이 여기에 해당합니다. Claude Code 사용자를 위해서는 저장소의 플러그인 마켓플레이스로 설치하는 bento-slides 스킬이 준비되어 있고, 이 스킬은 최신 Bento 앱 파일을 직접 내려받는 것까지 처리합니다. /plugin marketplace add nyblnet/bento /plugin install bento-slides@bento 둘째는 파일 접근이 없는 챗봇을 위한 왕복 방식입니다. Save → Copy docume… --- ## [esp32-ai: 파라미터 대부분을 플래시에 두고 ESP32-S3에서 28.9M 언어 모델을 돌리기](https://discuss.pytorch.kr/t/esp32-ai-esp32-s3-28-9m/11519)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 5, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/esp32-ai-esp32-s3-28-9m/11519 "2026-08-05T00:30:18Z")
esp32-ai 소개 마이크로컨트롤러에서 언어 모델을 돌릴 때 모델 크기를 결정하는 것은 연산량이 아니라 빠른 메모리의 양입니다. ESP32-S3에 들어 있는 내부 SRAM은 512KB뿐이고, 토큰마다 수없이 읽히는 값들이 그 안에 들어가야 합니다. 임베딩 표는 보통 파라미터의 대부분을 차지하기 때문에, 표를 어디에 둘 것인가가 곧 모델 크기의 상한이 됩니다. esp32-ai는 그 상한을 메모리 계층으로 우회한 프로젝트입니다. 2,890만 개 파라미터 가운데 2,500만 개를 조회 표(lookup table)로 만들어 느린 플래시에 남겨 두고, 한 토큰을 만들 때 그 표에서 필요한 여섯 줄 정도, 약 450바이트만 꺼내 씁니다. 모델 대부분은 실행을 위해 메모리로 올라오지 않고 플래시에 앉은 채 조금씩 샘플링됩니다. 이 배치를 가능하게 하는 것이 Google이 Gemma 3n에서 제시한 계층별 임베딩(Per-Layer Embeddings, PLE) 입니다. 원래는 휴대폰과 GPU를 염두에 둔 설계인데, esp32-ai는 같은 아이디어를 마이크로컨트롤러의 메모리 배치 위에서 구현했습니다. esp32-ai가 내놓은 수치 항목 값 파라미터 2,890만 개 저장 (그중 2,500만 개는 플래시 조회 표) 칩 ESP32-S3, SRAM 512KB, PSRAM 8MB, 플래시 16MB 속도 종단간 초당 9.88토큰, 토큰당 연산 94.9ms 연결성 없음, 전부 기기 위에서 동작 모델 크기 4비트 양자화 기준 14.9MB esp32-ai의 세 계층 메모리 배치 각 계층에는 그 계층의 읽기 빈도에 맞는 것만 들어갑니다. 저장소는 이 배치를 다음과 같이 정리하고 있습니다. SRAM (빠르고 작음) 활성값과 정규화 가중치, 토큰마다 여러 번 읽힘 PSRAM (중간) 코어와 출력 헤드, 위치마다 한 번 읽힘 FLASH (크고 느림) 2,500만 파라미터 표, 토큰당 약 6줄(450B) … --- ## [QM: 팀원마다 격리된 작업공간을 갖는 슬랙과 웹 기반 멀티플레이어 AI 에이전트](https://discuss.pytorch.kr/t/qm-ai/11511)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 4, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/qm-ai/11511 "2026-08-04T03:30:18Z")
QM 소개 에이전트를 회사 업무에 들이는 일은 보통 봇 계정 하나를 슬랙에 초대하는 것으로 시작합니다. 그 계정이 열 명, 스무 명의 요청을 동시에 받기 시작하면 곤란한 상황이 이어집니다. 누군가 프롬프트를 손보면 다른 사람의 작업 방식이 함께 바뀌고, 한 사람이 연결해 둔 서비스 자격증명을 전원이 공유하게 되며, 지난 대화에서 쌓인 기억이 엉뚱한 사람의 요청에 섞여 들어갑니다. QM 개발팀은 이 지점을 "대부분의 에이전트는 개인 비서처럼 설계되어 있어서, 회사 전체가 쓰도록 만들 수는 있지만 금세 복잡해진다" 라는 문장으로 정리하고 있습니다. QM은 그 복잡도를 스코프(scope) 단위 격리 로 푸는 업무용 멀티플레이어 에이전트 하니스(harness)입니다. 구성원은 각자 격리된 작업공간을 받아 서로 영향을 주지 않고 독립적으로 일하다가, 필요할 때는 슬랙 채널과 그룹 메시지, 프로젝트 안에서 같은 에이전트와 함께 작업합니다. 사람 하나하나와 대화방 하나하나가 자기만의 기억, 파일, 키체인 뷰, 권한, 크론(cron), 웹 앱, 그리고 재사용되는 샌드박스(sandbox)를 따로 가지는 구조입니다. 설계에서 눈에 띄는 또 하나는 하니스와 모델을 고정하지 않았다는 점입니다. Pi, OpenCode, Codex, Claude Code가 모두 동일한 코어를 구동하기 때문에, 한 번 배포한 환경이 특정 공급사에 묶이지 않습니다. 코어는 Node 위에서 TypeScript를 그대로 실행하고 HTTP 처리에 Fastify를 쓰며, 슬랙 플러그인은 Bolt를, 웹 UI는 Vite로 빌드해 Lit으로 렌더링합니다. 저장소는 yc-software 조직이 2026년 7월 말 공개했고, 공식 홈페이지는 qm.ycombinator.com 주소를 쓰고 있으며, 현재 배포판은 v0.1.4입니다. 개인 비서형 에이전트와 QM의 차이 조직에서 에이전트 하나를 공용으로 돌릴 때 생기는 문제와, QM이 같은 상황을 어떻게 다루는지를 나란히 두면 설계 의도가 분명해집니다. 아래 표의… --- ## [darwin-skill: 평가와 회귀 테스트로 에이전트 스킬을 진화시키는 최적화 루프](https://discuss.pytorch.kr/t/darwin-skill/11492)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 3, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/darwin-skill/11492 "2026-08-03T00:30:27Z")
darwin-skill 소개 에이전트 스킬(SKILL.md) 생태계가 빠르게 커지면서 새로운 유지보수 문제가 생겼습니다. Claude Code, Codex, OpenClaw, Trae, CodeBuddy 등 여러 도구가 같은 SKILL.md 형식을 지원하고, 스킬이 10개일 때는 손으로 관리할 수 있지만 60개를 넘어가면 체계가 필요합니다. 게다가 기존의 스킬 검토는 형식이 맞는지, 단계에 번호가 붙었는지, 경로가 유효한지 같은 구조 점검에 머물러서, 형식은 완벽한데 실제 출력은 형편없는 스킬을 걸러내지 못합니다. darwin-skill 은 이 문제를 모델 학습의 방법론으로 푸는 스킬 최적화 시스템으로, Andrej Karpathy의 autoresearch에서 직접 영감을 받아 alchaincyf가 공개했습니다. 자율 실험 루프를 모델 학습에서 스킬 최적화 영역으로 옮긴 것으로, 스킬을 평가하고, 한 가지를 고치고, 테스트로 검증한 뒤, 점수가 오른 변경만 남기고 나머지는 되돌립니다. 저자는 이를 "앞으로만 도는 래칫(a ratchet that only turns forward)" 이라고 부릅니다. 2.0 버전은 Microsoft Research의 두 논문 SkillLens와 SkillOpt를 흡수한 구조적 업그레이드입니다. 평가 루브릭이 9개 차원으로 늘었고, 검증 게이트 설계가 SkillOpt의 validation-gated 프레임워크에 맞춰졌습니다. 본 게시물에서는 darwin-skill의 핵심 루프와 평가 루브릭, 래칫 메커니즘을 정리합니다. autoresearch에서 스킬 최적화로 darwin-skill은 autoresearch의 구성 요소를 스킬 최적화에 그대로 대응시킵니다. autoresearch darwin-skill 이유 program.md darwin-skill의 SKILL.md 평가 기준과 제약 정의 train.py 최적화 대상 SKILL.md 실험당 편집 가능한 단일 자산 val\_bpb 9차원 가중 점수 … --- ## [html-ppt: 테마 36종과 레이아웃 31종을 갖춘 HTML 프레젠테이션 제작 에이전트 스킬](https://discuss.pytorch.kr/t/html-ppt-36-31-html/11470)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 31, 2026, 12:30오후 UTC](https://discuss.pytorch.kr/t/html-ppt-36-31-html/11470 "2026-07-31T12:30:23Z")
html-ppt 소개 html-ppt는 AI 코딩 에이전트가 정적 HTML 슬라이드 덱을 만들 때 참고할 테마와 레이아웃, 애니메이션 카탈로그를 한 벌로 묶어 둔 에이전트 스킬(AgentSkill)입니다. 에이전트에게 발표 자료를 부탁하면 보통 빈 화면에서 슬라이드 구조와 CSS를 매번 새로 지어내는데, 그렇게 만든 결과물은 실행할 때마다 톤이 달라지고 레이아웃도 들쭉날쭉합니다. html-ppt는 그 자리에 미리 검증된 템플릿 파일을 놓아, 에이전트가 새로 디자인하는 대신 고르게 만듭니다. 구조는 토큰 기반 디자인 시스템 하나와 그 위에 얹히는 파일들로 정리되어 있습니다. 색과 반경, 그림자, 폰트 결정은 저장소의 assets/base.css와 현재 테마 파일에 모여 있어서 테마 CSS 링크 한 줄을 바꾸면 덱 전체의 외관이 바뀝니다. 페이지 유형은 레이아웃 파일 하나, 등장 효과는 애니메이션 클래스 하나에 대응합니다. 빌드 단계가 없는 순수 HTML·CSS·JavaScript이며, CDN은 웹폰트와 highlight.js, chart.js에만 선택적으로 쓰입니다. 산출물이 정적 HTML이라는 점 때문에 발표 도구로서의 성격도 달라집니다. 브라우저에서 바로 열리고 키보드로 넘기며, S 키를 누르면 현재 슬라이드와 다음 슬라이드, 발표 원고, 타이머를 담은 발표자 창이 별도로 열립니다. 본 게시물에서는 html-ppt가 제공하는 카탈로그의 구성, 픽셀 단위로 일치하는 미리보기를 만드는 방식, 발표자 모드의 동작, 그리고 설치와 사용 절차를 정리합니다. html-ppt가 제공하는 카탈로그 항목 수량 위치 테마 36 assets/themes/\*.css 전체 덱 템플릿 15 templates/full-decks/\<이름\>/ 단일 페이지 레이아웃 31 templates/single-page/\*.html CSS 애니메이션 27 assets/animations/animations.css Canvas FX 애니메이션 20 assets/a… --- ## [pi-autoresearch: 코딩 에이전트가 지표를 측정하며 스스로 최적화를 반복하는 pi 확장](https://discuss.pytorch.kr/t/pi-autoresearch-pi/11471)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 30, 2026, 11:30오전 UTC](https://discuss.pytorch.kr/t/pi-autoresearch-pi/11471 "2026-07-30T11:30:32Z")
pi-autoresearch 소개 pi-autoresearch는 터미널에서 동작하는 AI 코딩 에이전트 pi에 자율 최적화 루프를 붙여 주는 확장입니다. 아이디어를 하나 적용하고, 벤치마크로 측정하고, 개선된 것은 남기고 나빠진 것은 되돌리고, 이 과정을 사람이 멈추라고 할 때까지 반복하는 흐름을 도구와 워크플로로 제공합니다. 프로젝트는 스스로를 karpathy/autoresearch에서 영향을 받았다고 밝히고 있으며, 최적화 대상이 무엇이든 같은 구조가 적용된다는 점을 전제로 설계되어 있습니다. 이 확장이 겨냥하는 문제는 "무엇을 바꿀지"가 아니라 "바꾼 것이 정말 나아졌는지"입니다. 성능 개선 작업에서 사람이 지치는 지점은 아이디어를 떠올리는 쪽이 아니라, 매번 같은 벤치마크를 돌리고 숫자를 적어 두고 커밋과 되돌리기를 반복하는 쪽입니다. pi-autoresearch는 그 반복을 도구 호출로 만들고, 결과를 프로젝트 안의 파일에 계속 쌓아 에이전트가 문맥을 잃어도 이어서 일할 수 있게 합니다. 측정 대상은 도메인을 가리지 않습니다. 저장소가 예시로 드는 조합은 테스트 실행 시간(초, 낮을수록 좋음), 번들 크기(KB), LLM 학습 지표(val\_bpb), 빌드 시간, Lighthouse 성능 점수입니다. 본 게시물에서는 pi-autoresearch의 루프 구조, 확장과 스킬의 역할 분담, 세션이 재시작을 견디는 방식, 잡음과 실제 개선을 구분하는 신뢰도 점수, 그리고 실험 결과를 검토 가능한 브랜치로 정리하는 절차를 정리합니다. pi-autoresearch의 자율 실험 루프 루프 한 바퀴는 코드 수정에서 시작합니다. 에이전트가 아이디어를 적용하고 커밋한 뒤 run\_experiment로 벤치마크 명령을 실행하면, 도구가 벽시계 시간을 재고 출력을 수집합니다. 그다음 log\_experiment가 결과를 기록하면서 자동으로 커밋하고 위젯과 대시보드를 갱신합니다. 마지막으로 결과를 채택하거나 되돌리고, 곧바로 다음 바퀴로 넘어갑니다. 사람이 끼어들… --- ## [Open Multi-Agent: 목표를 받아 작업 DAG를 실행 시점에 만드는 멀티 에이전트 프레임워크](https://discuss.pytorch.kr/t/open-multi-agent-dag/11472)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 30, 2026, 5:30오전 UTC](https://discuss.pytorch.kr/t/open-multi-agent-dag/11472 "2026-07-30T05:30:53Z")
Open Multi-Agent 소개 Open Multi-Agent(OMA)는 TypeScript 백엔드에 넣어 쓰는 AI 에이전트 오케스트레이션 프레임워크입니다. 가장 큰 특징은 워크플로 그래프를 사람이 미리 그려 두지 않는다는 점입니다. 목표 한 줄을 넘기면 조정자(coordinator)가 실행 시점에 작업 DAG를 만들고, 결정적으로 동작하는 스케줄러가 그 DAG를 팀 전체에 배분해 실행합니다. 프로젝트는 자신의 지향점을 "Describe the goal, not the graph"라는 한 문장으로 요약하고 있습니다. 멀티 에이전트 시스템을 시제품에서 운영 단계로 옮길 때 걸리는 지점은 보통 계획을 세우는 능력이 아니라 그 계획을 통제하고 되짚는 수단입니다. 실행 시점에 계획이 만들어지는 구조는 유연하지만, 계획이 엉뚱한 방향으로 흘러도 막을 방법이 없다면 운영에 쓰기 어렵습니다. OMA는 이 지점에 승인과 제약, 체크포인트 재개, 추적과 평가를 함께 놓아 동적 계획을 명시적 경계 안에 두는 방식을 택했습니다. 실행 환경은 사용자 쪽에 남습니다. 클라우드 모델과 로컬 모델을 섞어 쓸 수 있고, OpenAI 호환 엔드포인트와 AI SDK 제공자도 연결되며, 도구 호출을 텍스트로 내보내는 로컬 모델을 위한 예비 파서도 들어 있습니다. Claude Code와 Gemini CLI, Codex 같은 외부 에이전트도 프로세스 백엔드와 ACP 백엔드를 통해 같은 작업 DAG와 공유 메모리, 예산 안에서 함께 움직입니다. 본 게시물에서는 OMA의 실행 모델, 통제 장치, 관측과 평가 기능, 그리고 설치와 첫 실행 절차를 정리합니다. Open Multi-Agent의 실행 모델 OMA가 제공하는 실행 방식은 세 가지입니다. runTeam()은 목표에서 계획을 세워 팀 전체를 돌리고, runAgent()는 에이전트 하나만 실행하며, runTasks()는 사람이 정의한 파이프라인을 그대로 수행합니다. 아래는 저장소가 제시하는 최소 예시로, 연구자와 분석가 두 역할을 … --- ## [AutoScraper: 예시 하나로 스크래핑 규칙을 학습하는 파이썬 웹 스크래퍼](https://discuss.pytorch.kr/t/autoscraper/11409)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 28, 2026, 11:30오전 UTC](https://discuss.pytorch.kr/t/autoscraper/11409 "2026-07-28T11:30:44Z")
AutoScraper 소개 웹 페이지에서 원하는 데이터를 긁어오려면 보통 CSS 선택자나 XPath를 직접 찾아 코드에 박아야 합니다. 페이지 구조가 조금만 바뀌어도 선택자를 다시 손봐야 하고, 사이트마다 규칙을 새로 작성해야 하는 번거로움이 있습니다. 간단한 목록 하나를 뽑는 데도 개발자가 HTML을 열어 태그 경로를 분석하는 시간이 적지 않게 듭니다. AutoScraper는 이 과정을 뒤집어, 사람이 선택자를 지정하는 대신 원하는 결과의 예시를 주면 스크래핑 규칙을 스스로 학습하는 파이썬 라이브러리입니다. URL이나 HTML 콘텐츠와 함께 뽑고 싶은 값의 목록(wanted\_list) 을 넘기면, AutoScraper가 그 값들이 페이지 어디에 어떤 형태로 있는지 규칙을 찾아내고 비슷한 요소들을 반환합니다. 값은 텍스트, URL, 그 밖의 HTML 태그 값 무엇이든 될 수 있습니다. 한 번 학습한 스크래퍼 객체는 새로운 URL에 그대로 재사용할 수 있습니다. 즉, 예시 페이지 한 번으로 규칙을 만든 뒤 같은 구조의 다른 페이지들에서 동일한 위치의 데이터를 계속 뽑아낼 수 있습니다. 가볍고 빠른 것을 지향하며 파이썬 3과 호환됩니다. AutoScraper의 동작 방식 AutoScraper의 핵심은 "선택자를 쓰지 않고 예시로 학습한다"는 점입니다. 아래 그림은 예시 값 하나가 어떻게 전체 결과 목록으로 이어지는지 보여줍니다. 동작은 크게 두 갈래로 나뉩니다. get\_result\_similar 는 예시와 비슷한 요소를 모두 찾아 반환하고, get\_result\_exact 는 예시와 정확히 같은 위치의 요소를 반환합니다. 예를 들어 목록 페이지에서 제목 하나를 예시로 주면 비슷한 제목 전체를 얻을 수 있고, 상세 페이지에서 특정 값(가격 등) 을 예시로 주면 다른 페이지의 같은 위치 값을 정확히 가져올 수 있습니다. 여러 값을 wanted\_list에 함께 넣으면 get\_result\_exact 가 목록에 넣은 순서 그대로 데이터를 반환합니다. Au… --- ## [OmniRoute: 여러 AI 제공자를 하나의 엔드포인트로 잇는 로컬 게이트웨이](https://discuss.pytorch.kr/t/omniroute-ai/11413)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 28, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/omniroute-ai/11413 "2026-07-28T09:30:22Z")
OmniRoute 소개 여러 개의 대규모 언어 모델(LLM)을 동시에 쓰다 보면 관리해야 할 것이 빠르게 늘어납니다. 제공자마다 SDK와 엔드포인트가 다르고, 구독 요금제는 다 쓰지 못한 채 매달 만료되며, 한도(rate limit)에 걸리면 작업이 중간에 멈춥니다. 게다가 Claude Code, Cursor, Codex 같은 코딩 도구는 저마다 별도의 설정을 요구합니다. 이렇게 흩어진 자격 증명과 설정을 손으로 관리하는 일은 그 자체로 상당한 부담입니다. OmniRoute은 이 문제를 로컬 게이트웨이(gateway) 방식으로 풀어내는 도구입니다. 사용자의 컴퓨터에서 돌아가는 하나의 프록시가 http://localhost:20128/v1 이라는 단일 OpenAI 호환 엔드포인트를 열어 두고, 그 뒤에서 여러 AI 제공자로 요청을 분배합니다. 코딩 도구는 이 엔드포인트 하나만 바라보면 되고, 한 제공자의 한도가 소진되면 OmniRoute가 밀리초 단위로 다음 제공자로 요청을 넘깁니다. OpenAI, Claude(Anthropic), Gemini, Responses API 형식 사이의 변환도 게이트웨이가 처리하므로, 도구가 어떤 API 규격을 쓰든 그대로 연결됩니다. 저장소 기준으로 카탈로그에는 290개 제공자와 500개 이상의 모델이 등록되어 있고, 이 가운데 90개 이상이 무료 티어를 제공하며 40개 이상은 조건 없이 계속 무료입니다. 지원하는 코딩 도구는 33종(CLI 코딩 도구 25종 + CLI 에이전트 8종)이고, 대시보드 UI는 43개 언어로 번역되어 있습니다. TypeScript로 작성된 MIT 라이선스 오픈소스이며, 최신 릴리스는 v3.8.50 계열입니다. 이 게시물에서는 4단계 폴백(fallback) 구조, 무료 티어 집계, 19가지 라우팅 전략, 12개 엔진 토큰 압축 스택, 에이전트 프로토콜, 실행 환경과 설치 방법을 차례로 정리합니다. OmniRoute가 겨냥하는 문제 저자는 README 첫 부분에서 여러 AI 제공자를 손으로… --- ## [opencodex: 어떤 LLM이든 Codex와 Claude Code에서 쓰게 해주는 범용 프록시](https://discuss.pytorch.kr/t/opencodex-llm-codex-claude-code/11408)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 27, 2026, 11:30오전 UTC](https://discuss.pytorch.kr/t/opencodex-llm-codex-claude-code/11408 "2026-07-27T11:30:39Z")
opencodex 소개 OpenAI의 Codex CLI나 Claude Code 같은 코딩 에이전트는 특정 백엔드 API에 맞춰 통신합니다. 그래서 Claude, Gemini, Grok, DeepSeek 같은 다른 모델을 쓰고 싶어도, 도구가 해당 제공자를 공식 지원할 때까지 기다려야 하는 경우가 많습니다. 로컬 모델을 붙이거나 여러 계정을 번갈아 쓰는 것도 도구마다 방식이 달라 손이 많이 갑니다. opencodex는 이 문제를 프록시 계층으로 푸는 도구입니다. Codex의 Responses API 요청을 각 제공자가 이해하는 형식으로 번역해 전달하는 가벼운 로컬 프록시로, 스트리밍, 도구 호출(tool call), 추론 토큰(reasoning token), 이미지가 양방향으로 모두 동작합니다. 덕분에 Codex의 워크플로우는 그대로 두고 뒤에 있는 모델만 바꿀 수 있습니다. opencodex는 Codex뿐 아니라 Claude Code에서도 같은 방식으로 동작하며, Anthropic, Google, xAI, DeepSeek, Kimi, Qwen, GLM, Ollama를 비롯한 여러 제공자를 지원합니다. OpenAI 자신도 대상 제공자 중 하나로 포함됩니다. opencodex의 동작 구조 opencodex의 핵심은 하나의 OpenAI 호환 엔드포인트로 여러 모델을 라우팅하는 통합 프록시 계층이라는 점입니다. 아래 그림은 Codex 클라이언트에서 opencodex를 거쳐 각 제공자로 요청이 흘러가는 구조를 보여줍니다. Codex CLI, 앱, SDK 등 Responses API로 통신하는 클라이언트는 /v1/responses 로 요청을 보내고, opencodex는 이를 받아 Anthropic의 Messages API, Google의 Gemini, 그 외 제공자의 Chat Completions API로 각각 변환해 전달합니다. 이 프록시 계층은 OpenAI 호환 API 표면(surface), 스마트 라우팅과 장애 조치(failover), 사용량 추적… --- ## [memsearch: 여러 AI 코딩 에이전트가 하나의 기억을 공유하는 의미 기반 메모리 계층](https://discuss.pytorch.kr/t/memsearch-ai/11411)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 26, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/memsearch-ai/11411 "2026-07-26T03:30:23Z")
memsearch 소개 AI 코딩 에이전트는 세션이 끝나면 대화 맥락을 대부분 잊어버립니다. 며칠 전 어떤 Redis 이슈를 어떻게 고쳤는지, 왜 특정 라이브러리를 선택했는지 같은 결정의 이유는 대화가 지나가면 함께 사라집니다. 게다가 Claude Code에서 나눈 이야기는 Codex나 다른 에이전트에서는 다시 검색할 수 없어, 같은 프로젝트인데도 도구마다 맥락이 단절됩니다. memsearch는 이 문제를 여러 AI 에이전트가 공유하는 지속적 메모리 계층으로 해결하는 도구입니다. 한 에이전트에서 나눈 대화가 다른 모든 에이전트에서 검색 가능한 컨텍스트가 되며, 별도 설정 없이 플러그인을 설치하는 것만으로 동작합니다. Milvus를 만든 Zilliz가 개발했고, 저장의 근간은 마크다운 파일이며 Milvus는 그 위에 얹히는 검색 색인입니다. memsearch의 설계에서 특징적인 점은 마크다운을 원본(source of truth) 으로 삼는다는 것입니다. 메모리는 사람이 읽고 편집하고 버전 관리할 수 있는 .md 파일이며, Milvus는 이 파일들로부터 파생되어 언제든 다시 만들 수 있는 "그림자 색인(shadow index)" 입니다. 이 구조 덕분에 메모리가 특정 벡터 DB에 갇히지 않고, 원본은 항상 사람이 직접 들여다볼 수 있는 텍스트로 남습니다. memsearch의 아키텍처 memsearch는 에이전트 플러그인, CLI/API, 코어 검색 엔진, 마크다운 원본의 네 계층으로 이루어집니다. 위쪽 그림이 이 계층 구조를 보여줍니다. 아래 그림은 이 계층이 만들어 내는 결과, 즉 여러 에이전트가 하나의 메모리를 공유하는 모습을 정리한 것입니다. 가장 위 계층은 각 에이전트용 플러그인으로, Claude Code, OpenClaw, OpenCode, Codex CLI를 지원합니다. 에이전트 사용자는 플러그인만 설치하면 되고, 에이전트 개발자는 아래의 CLI와 파이썬 API로 자신의 에이전트에 메모리를 붙일 수 있습니다. 코어 엔진은 청킹(chun… --- ## [gigatoken: HuggingFace보다 약 1000배 빠른 GB/s급 LLM 토크나이저](https://discuss.pytorch.kr/t/gigatoken-huggingface-1000-gb-s-llm/11414)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 25, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/gigatoken-huggingface-1000-gb-s-llm/11414 "2026-07-25T09:30:40Z")
gigatoken 소개 대규모 언어 모델을 학습할 때는 수십 기가바이트에서 수 테라바이트에 이르는 텍스트를 토큰으로 변환해야 합니다. 이 토큰화 단계는 GPU 학습만큼 눈에 띄지는 않지만, 데이터가 커질수록 전체 파이프라인에서 무시할 수 없는 시간을 차지합니다. HuggingFace tokenizers나 tiktoken이 이미 멀티스레드 Rust로 구현되어 있는데도, 대용량 코퍼스를 한 번 토큰화하는 데 상당한 시간이 드는 이유입니다. gigatoken은 이 토큰화를 초당 기가바이트(GB/s) 단위로 처리하는 것을 목표로 하는 Rust 기반 토크나이저입니다. 개발자는 이를 "~1000x faster than HuggingFace's tokenizers, drop-in replacement" 라고 소개하며, 언어 모델링을 위한 가장 빠른 토크나이저라고 설명합니다. 다양한 CPU 하드웨어를 지원하고, 널리 쓰이는 대부분의 토크나이저와 호환됩니다. gigatoken이 강조하는 점은 이것이 기존 도구를 완전히 대체하는 별개의 방식이 아니라 드롭인 교체(drop-in replacement) 라는 것입니다. 기존 HuggingFace나 tiktoken 코드에 최소한의 변경만으로 끼워 넣을 수 있고, 더 빠른 속도가 필요하면 gigatoken 고유 API로 전환할 수 있습니다. gigatoken의 처리량 아래 그림은 Apple M4 Max(16 스레드) 에서 12GB 텍스트(owt\_train.txt) 를 GPT-2 토크나이저로 처리했을 때의 처리량을 비교한 것입니다. gigatoken의 막대가 GB/s 단위인 반면, tiktoken과 HuggingFace tokenizers는 MB/s 단위에 머무릅니다. 저장소의 벤치마크는 같은 12GB 코퍼스를 여러 토크나이저와 CPU에서 측정한 수치를 함께 제공합니다. 아래는 AMD EPYC 9565(144 코어) 기준 일부 발췌입니다. 토크나이저 gigatoken HF tokenizers HF 대비 G… --- ## [Hallmark: AI 티가 나지 않는 웹 디자인을 만드는 코딩 에이전트 스킬](https://discuss.pytorch.kr/t/hallmark-ai/11348)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 24, 2026, 1:30오전 UTC](https://discuss.pytorch.kr/t/hallmark-ai/11348 "2026-07-24T01:30:49Z")
Hallmark 소개 LLM 코딩 에이전트에게 웹페이지 디자인을 맡기면 결과물이 서로 비슷해지는 경향이 있습니다. 같은 그라디언트, 같은 카드 레이아웃, 같은 여백과 폰트 조합이 반복되는데, 이는 모델이 학습 과정에서 익숙해진 "분포 안의(on-distribution)" 기본값으로 수렴하기 때문입니다. 브리프가 서로 달라도 완성된 페이지는 결국 같은 템플릿의 색만 바꾼 것처럼 보이는 경우가 많습니다. Hallmark 는 이 문제를 정면으로 겨냥한 디자인 스킬입니다. Claude Code, Cursor, Codex 에서 동작하며, Together AI가 만들었습니다. 브리프에 맞는 매크로구조(macrostructure)를 먼저 고르고, 스무 개의 테마 중 하나를 입힌 뒤, 57개의 슬롭 테스트 게이트와 결과를 내보내기 전 자체 비평(self-critique)을 거쳐 모델이 반사적으로 내놓는 기본값을 거부합니다. 서로 다른 두 브리프로 만든 페이지가 같은 템플릿의 색만 바꾼 결과가 아니라 실제로 다른 사이트처럼 느껴지도록 하는 것이 목표입니다. Hallmark 는 프레임워크나 별도 런타임이 아니라, 에이전트가 읽고 따르는 규칙 모음(스킬)입니다. 규칙 자체는 SKILL.md 와 references/ 에 들어 있고, 결과물은 매크로구조가 CSS 주석에 표시된 자체 완결형 HTML 과 CSS 파일입니다. 아래에서는 Hallmark 가 제공하는 네 가지 동사, 브리프마다 다른 결과를 만드는 방식, 그리고 설치 방법을 정리합니다. Hallmark 의 네 가지 동사 Hallmark 는 작업 성격에 따라 네 개의 동사로 나뉩니다. 만들기(기본) : 아무 인자 없이 호출하면 새 UI 를 만듭니다. 매크로구조를 고르고 규칙 집합을 적용한 뒤, 결과를 돌려주기 전에 슬롭 테스트를 실행합니다. hallmark audit \ : 기존 코드를 안티패턴 기준으로 채점합니다. 지적 목록(punch list)만 내놓고 코드를 직접 수정하지는 않습니다. hal… [다음 페이지](https://discuss.pytorch.kr/tag/mit-license/2317.md?match_all_tags=true&page=1&tags%5B%5D=mit-license)