# \#python **URL:** https://discuss.pytorch.kr/tag/python/89.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [humanize: Python 기반의 작업 명세에 따라 Claude Code와 Codex를 실행하며 작업을 수행하는 에이전트 플로우 실행기](https://discuss.pytorch.kr/t/humanize-python-claude-code-codex/12089)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 4, 2026, 1:30오전 UTC](https://discuss.pytorch.kr/t/humanize-python-claude-code-codex/12089 "2026-10-04T01:30:33Z")
핵심 요약 humanize는 Claude Code, Codex 같은 코딩 에이전트 CLI를 직접 대체하지 않고, 사람이 Python으로 작성한 루프(플로우, flow)에 따라 이 CLI들에게 턴을 차례로 맡기며 실행 전체를 기록하는 런타임(runtime)입니다. 한 에이전트를 매 라운드 새 세션으로 반복시키는 ralph\_loop, 작업자와 별도의 검토자를 붙이는 rlar, 세 갈래를 동시에 실행하는 parallel\_flame\_chase 등 14종의 플로우를 문서화해 두었고, 역할마다 다른 CLI와 모델을 지정할 수 있습니다. chat을 뺀 모든 플로우는 시간, 비용, 출력 토큰 중 하나 이상의 예산이 있어야 실행되며, 가장 먼저 소진된 한도가 실행을 멈춥니다. 모든 에이전트는 승인 절차 없이 파일을 고치고 명령을 실행하고 커밋하므로, 개발팀은 실험용 저장소에서 시작하라고 안내합니다. 역할별 권한은 Linux의 Landlock(커널 5.13 이상)과 macOS의 Seatbelt로 강제됩니다. humanize 소개 코딩 에이전트에게 몇 시간짜리 작업을 맡기면 대화가 길어질수록 컨텍스트가 무거워지고, 에이전트가 스스로 "다 했다"고 판단한 시점과 실제로 끝난 시점이 어긋나는 일이 잦습니다. 그래서 같은 프롬프트를 셸 while 루프로 계속 다시 넣는 Ralph 루프나, 한 모델이 만든 결과를 다른 모델에게 검토시키는 방식이 실무에서 쓰여 왔지만, 대개는 스크립트와 플러그인으로 흩어져 있어 비교하거나 다시 실행하기 어렵습니다. 이번에 소개하는 humanize는 이런 루프를 Python 함수로 작성하게 하고, 그 루프를 이미 로그인해 둔 코딩 에이전트 CLI 위에서 실행해 주는 Humanfia 팀의 에이전트 플로우 실행기입니다. humanize에서 작업 방식은 플로우(flow) 라는 Python 코드로 정의됩니다. 플로우는 어떤 역할의 에이전트가 몇 명 필요한지, 각자에게 무엇을 물을지, 언제 멈출지를 선언하고, humanize는 그 선언에 따라 세션을 열고… --- ## [\[A2A 알아보기 2편\] A2A Python SDK: 나의 에이전트를 다른 사람의 에이전트가 호출할 수 있도록 하기 위해 A2A 서버로 공개하기](https://discuss.pytorch.kr/t/a2a-2-a2a-python-sdk-a2a/11893)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 14, 2026, 3:00오전 UTC](https://discuss.pytorch.kr/t/a2a-2-a2a-python-sdk-a2a/11893 "2026-09-14T03:00:58Z")
A2A Python SDK 소개 A2A Python SDK는 파이썬으로 만든 에이전트를 A2A(Agent2Agent) 프로토콜 (:pytorch::kr: \[A2A 알아보기 1편\] A2A 프로토콜: 프레임워크가 서로 달라도 에이전트들끼리 서로 작업을 위임하게 하는 표준 규격)을 따르는 서버로 공개하게 해 주는 공식 라이브러리입니다. 이미 동작하는 에이전트를 가진 팀이 그것을 다른 팀의 에이전트에게 열어 주려고 하면, 할 일이 에이전트 로직 바깥에 몰려 있습니다. 능력을 기술한 문서를 정해진 위치에 올려야 하고, 요청을 받아 태스크로 만들어 상태를 관리해야 하고, 진행 상황을 스트리밍으로 흘려 보내야 합니다. 이 부분을 직접 구현하면 에이전트 자체보다 주변 코드가 더 커집니다. A2A Python SDK는 그 주변부를 맡습니다. 개발자가 채우는 것은 두 가지로, 에이전트가 무엇을 할 수 있는지 적은 AgentCard와 실제 일을 수행하는 AgentExecutor 구현입니다. 나머지는 SDK가 제공하는 요청 핸들러와 라우트 생성 함수가 처리합니다. 라우트는 Starlette나 FastAPI 같은 ASGI(Asynchronous Server Gateway Interface) 프레임워크에 그대로 붙일 수 있어서, 인증과 로깅 같은 기존 미들웨어 구성을 유지한 채 A2A 엔드포인트만 추가할 수 있습니다. 본 게시물은 a2a-samples 저장소의 helloworld 예제를 기준으로 SDK의 구성 요소를 하나씩 짚고, 서버를 띄운 뒤 실제로 오간 JSON까지 확인합니다. 아래에 실린 출력은 모두 a2a-sdk 1.1.0과 Python 3.11에서 직접 실행해 받은 것입니다. A2A Python SDK가 대신 처리하는 것 A2A 서버를 직접 구현한다고 하면 프로토콜 명세에서 옮겨 와야 하는 항목이 적지 않습니다. 에이전트 카드를 잘 알려진 경로로 제공하는 일, 들어온 메시지를 태스크로 바꾸고 식별자를 발급하는 일, 태스크의 상태 전이를 관리하는 일, 스트리밍 이벤… --- ## [OptMem: 데이터베이스도 임베딩도 없이 로그와 이진 트리로 만든 AI 에이전트용 영속 메모리](https://discuss.pytorch.kr/t/optmem-ai/11753)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 30, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/optmem-ai/11753 "2026-08-30T09:30:26Z")
OptMem 소개 코딩 에이전트에게 기억을 붙이는 방법은 대체로 한 방향으로 수렴해 왔습니다. 대화를 잘라 임베딩으로 바꾸고 벡터 데이터베이스에 넣은 뒤, 새 질문이 오면 비슷한 조각을 검색해 프롬프트에 끼워 넣는 방식입니다. 이 구조는 잘 동작하지만 붙이는 비용이 작지 않습니다. 임베딩 모델과 벡터 저장소를 고르고 운영해야 하고, 검색이 무엇을 가져왔는지가 사람 눈에 잘 보이지 않으며, 무엇이 왜 기억되었는지 확인하려면 다시 도구를 하나 더 열어야 합니다. 개인 작업 환경에 붙이기에는 무거운 편입니다. OptMem은 그 반대 방향에서 출발한 프로젝트입니다. 임베딩도 벡터 데이터베이스도 쓰지 않고, 한 줄씩 덧붙이기만 하는 텍스트 기록과 그 위에 얹은 이진 요약 트리(binary merge tree)만으로 에이전트의 영속 기억을 만듭니다. 도구는 의존성 없는 단일 파이썬 파일이고, 에이전트 쪽에 붙는 것은 426개 토큰짜리 프롬프트 한 덩어리뿐입니다. 저자는 Victor Taelin으로, 자신을 증명 언어 Kind와 병렬 런타임(Runtime) HVM의 저자로 소개하고 있으며 Higher Order Company에 속해 있습니다. 핵심 아이디어는 위 그림 한 장에 담겨 있습니다. 아래쪽 줄은 실제로 기록된 기억 하나하나이고, 위로 한 층 올라갈 때마다 인접한 두 개가 하나의 요약으로 합쳐집니다. 그래서 최근 기억은 원문 그대로 남고 오래된 기억일수록 점점 압축된 형태로만 남습니다. 요약본은 캐시일 뿐이고 원문은 LOG.txt에 덧붙이기 전용으로 그대로 남으므로, 필요하면 언제든 아래층으로 내려가 원래 문장을 꺼낼 수 있습니다. OptMem이 기존 방식과 다른 점 벡터 검색 방식과 OptMem은 "무엇을 꺼내 올까"를 정하는 방법이 다릅니다. 벡터 검색은 질문과의 의미적 유사도로 조각을 고르므로, 관련 있어 보이는 것은 잘 찾아오지만 세션 시작 시점에 "지금까지 무슨 일이 있었는가"를 통째로 파악하기는 어렵습니다. OptMem은 반대로 세션 첫 명… --- ## [OpenOPC: 목표 하나로 조직도를 짜고 AI 직원을 채용해 일을 완료하는 멀티 에이전트 런타임 (feat. HKUDS)](https://discuss.pytorch.kr/t/openopc-ai-feat-hkuds/11751)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 29, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/openopc-ai-feat-hkuds/11751 "2026-08-29T02:30:14Z")
OpenOPC 소개 AI 코딩 에이전트에게 "이 기능을 만들어 줘"라고 요청하는 것과 "이 제품을 출시해 줘"라고 요청하는 것 사이에는 큰 차이가 있습니다. 앞의 요청은 한 세션 안에서 끝나지만, 뒤의 요청은 설계와 구현, 검토, 문서화, 배포 준비가 서로를 기다리는 여러 갈래의 작업으로 쪼개집니다. 단일 에이전트에게 긴 작업을 통째로 맡기면 중간에 문맥이 흐려지고, 반대로 사람이 작업을 잘게 나눠 에이전트에게 하나씩 던져 주면 결국 사람이 조율 담당자가 됩니다. 여러 에이전트를 동시에 실행하는 도구는 이미 많지만, 그 에이전트들이 서로에게 일을 넘기고 결과를 검토하며 막히면 사람을 부르는 절차까지 갖춘 경우는 드뭅니다. OpenOPC는 홍콩대학교 데이터 인텔리전스 연구실(Data Intelligence Lab@HKU, HKUDS)이 공개한 멀티 에이전트 런타임으로, 이 조율 문제를 회사 조직이라는 형태로 해결합니다. 목표 하나를 입력하면 그 목표에 필요한 역할과 보고 체계를 담은 조직도를 먼저 그리고, 각 역할에 AI 직원을 배치한 뒤, 작업을 나눠 실행하고 검토하는 과정을 런타임이 직접 관리합니다. 저자들은 이 과정을 자체 구성(Self-Built), 자체 운영(Self-Run), 자체 성장(Self-Grown)이라는 세 축으로 설명하고 있습니다. OpenOPC는 Python 3.10 이상에서 동작하는 파이썬 패키지이며, 터미널에서 쓰는 opc 명령과 브라우저에서 여는 Office UI를 함께 제공합니다. 실행 주체는 자체 런타임(OpenOPC Native)뿐 아니라 Codex, Claude Code, Cursor, OpenCode (:pytorch::kr: Opencode: 다양한 LLM을 사용할 수 있는, 터미널 기반의 오픈소스 AI 코딩 에이전트)와 같은 외부 코딩 에이전트 CLI를 역할별로 지정해 쓸 수 있습니다. 모델은 LiteLLM 및 OpenRouter 호환 엔드포인트를 통해 연결하므로 특정 제공자에 묶이지 않습니다. 기존 방식… --- ## [Sprix SAGE Router: 실행 중인 A2A 에이전트의 실행 경로를 결정하고 호출하는 라우터 (SELF / COLLABORATE / HANDOFF)](https://discuss.pytorch.kr/t/sprix-sage-router-a2a-self-collaborate-handoff/11722)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 28, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/sprix-sage-router-a2a-self-collaborate-handoff/11722 "2026-08-28T00:30:44Z")
Sprix SAGE Router 소개 Agent2Agent(A2A) 프로토콜 (:pytorch::kr: Google, AI 에이전트들간의 협업을 위한 A2A(Agent-to-Agent) 프로토콜 공개)처럼 에이전트끼리 서로를 찾아 대화하게 만드는 규격이 자리를 잡으면서, 이제는 "어떤 에이전트가 존재하는가"는 어렵지 않게 알 수 있게 되었습니다. Agent Card로 능력을 선언하고, 메시지와 작업(Task)과 산출물(Artifact)을 주고받는 절차도 프로토콜이 정해 줍니다. 그런데 실제 운영에서 더 자주 부딪히는 질문은 그다음입니다. 어떤 에이전트가 작업을 이미 절반쯤 진행한 상태에서, 그대로 혼자 끝내는 것이 나은지, 부족한 능력을 채워 줄 동료를 불러야 하는지, 아니면 더 잘하는 에이전트에게 통째로 넘겨야 하는지를 프로토콜은 결정해 주지 않습니다. Sprix SAGE Router는 이 결정을 담당하는 계층으로 설계된 Python 라이브러리입니다. SAGE는 상태 인식 그래프 교환(State-Aware Graph Exchange)의 약자로, 이름 그대로 현재 실행 상태를 판단 재료에 포함시킵니다. 이미 완료된 작업 노드, 지금 배정된 실행자, 누적된 진행률, 실패 이력, 그리고 넘길 때 잃게 되는 맥락의 양까지 하나의 목적 함수(Utility Function)에 넣고, SELF(혼자 계속), COLLABORATE(협업), HANDOFF(인계) 세 경로를 같은 기준으로 비교합니다. 세 경로를 각각 다른 규칙(Heuristic)으로 나눠 판단하지 않는다는 점이 이 프로젝트가 내세우는 핵심 설계입니다. Sprix SAGE Router는 Python 3.10 이상에서 동작하고 런타임(Runtime) 의존성이 없어 git clone 후 바로 실행할 수 있습니다. 저장소는 屿智同行의 A2A 사업부인 Sprix AI가 공개한 알고리즘 연구 산출물이며, 저자들은 프로젝트 상태를 초기 단계의 연구 프리뷰(Research Preview)로 명시하고 있습니다. 프로… --- ## [ai-knowledge-graph: 비정형 텍스트에서 지식 그래프를 뽑아 시각화하는 파이썬 도구](https://discuss.pytorch.kr/t/ai-knowledge-graph/11583)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 11, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/ai-knowledge-graph/11583 "2026-08-11T03:30:32Z")
ai-knowledge-graph 소개 사내 위키나 회의록, 조사 보고서처럼 쌓여만 가는 문서 더미에서 "무엇이 무엇과 어떻게 연결되어 있는가"를 알아내려면 결국 사람이 읽어야 합니다. LLM에게 문서를 통째로 던져 요약을 받는 방법도 있지만, 요약은 다시 문장이라 관계를 눈으로 따라가기 어렵습니다. ai-knowledge-graph 는 그 중간 형태를 만듭니다. 비정형 텍스트를 입력받아 LLM으로 주어-서술어-목적어(Subject-Predicate-Object, SPO) 형태의 트리플을 뽑아내고, 그 관계망을 브라우저에서 돌려볼 수 있는 그래프로 그려 주는 파이썬 도구입니다. 문서에서 트리플을 뽑는 일 자체는 어렵지 않습니다. 문제는 그다음입니다. 문서를 청크로 나눠 처리하면 같은 대상이 청크마다 다른 이름으로 잡히고, 서로 이어져야 할 부분이 끊긴 섬으로 남습니다. ai-knowledge-graph는 이 지점을 추가 패스 로 해결합니다. 1차 추출 뒤에 엔티티 표준화 패스를 돌려 "AI", "artificial intelligence", "AI system" 처럼 같은 개념을 가리키는 표기를 하나로 모으고, 3차 관계 추론 패스에서 끊어진 커뮤니티 사이를 이어 줍니다. 두 패스 모두 설정에서 끌 수 있어서 LLM 호출량을 줄이고 싶으면 1차 추출만 쓸 수도 있습니다. 만든 사람은 Robert McDermott입니다. 특정 모델에 묶여 있지 않다는 점도 특징입니다. OpenAI 호환 API 엔드포인트라면 무엇이든 붙일 수 있어서 Ollama나 LM Studio로 노트북 안에서 끝낼 수도 있고, vLLM이나 LiteLLM을 거쳐 AWS Bedrock, Azure OpenAI, Anthropic 같은 서비스로 보낼 수도 있습니다. 이 글에서는 세 번의 패스가 실제로 무엇을 바꾸는지, 설정과 실행은 어떻게 하는지, 그리고 어떤 상황에 맞고 어떤 상황에는 부족한지를 정리합니다. 단일 추출 방식의 한계와 ai-knowledge-graph의 3단 처리 문서를… --- ## [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… --- ## [Quivr: 어떤 LLM과 파일에도 연결되는 제품 중심의 오픈소스 RAG 프레임워크](https://discuss.pytorch.kr/t/quivr-llm-rag/11403)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 27, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/quivr-llm-rag/11403 "2026-07-27T07:30:08Z")
Quivr 소개 문서를 근거로 답하는 챗봇이나 사내 지식 도우미를 만들려면 검색 증강 생성(RAG, Retrieval-Augmented Generation) 파이프라인을 직접 조립해야 합니다. 파일을 파싱해 청크로 나누고, 임베딩을 만들어 벡터 저장소에 넣고, 질문을 다시 쓰고, 관련 청크를 검색해 LLM 프롬프트에 붙이고, 대화 이력을 관리하는 단계가 모두 필요합니다. 각 단계는 라이브러리 선택과 연결 코드가 뒤따르기 때문에, 정작 만들려던 제품보다 RAG 배관 작업에 시간을 더 쓰게 되는 경우가 많습니다. Quivr는 이 배관을 라이브러리 안으로 감춰, 개발자가 자기 제품에 집중하도록 만드는 것을 목표로 하는 파이썬 RAG 프레임워크입니다. 개발자는 "We take care of the RAG so you can focus on your product" 라는 문구로 Quivr의 지향점을 설명합니다. 저장소의 핵심 패키지인 quivr-core 는 파일을 넣고 질문을 던지는 최소 동작을 몇 줄로 끝낼 수 있게 하며, Quivr.com 서비스의 기반이 되는 엔진이기도 합니다. Quivr는 특정 모델이나 저장소에 묶이지 않는 것을 설계 원칙으로 삼습니다. OpenAI, Anthropic, Mistral 같은 상용 API는 물론 Ollama를 통한 로컬 모델까지 붙일 수 있고, 입력 파일도 PDF, TXT, Markdown 등 형식을 가리지 않으며 직접 파서를 추가할 수도 있습니다. 검색·재순위(reranking)·LLM 호출 같은 단계는 코드가 아니라 YAML 설정 파일의 노드와 엣지로 기술하도록 되어 있어, 파이프라인 구조를 바꾸는 일이 설정값 수정에 가깝습니다. Quivr의 핵심 기능 Quivr가 내세우는 특징은 네 가지로 정리됩니다. 각 기능은 "RAG를 대신 처리한다"는 하나의 목표를 서로 다른 축에서 뒷받침합니다. 의견을 담은 RAG (Opiniated RAG): 개발자는 Quivr의 RAG를 빠르고 효율적으로 동작하도록 특정 방식으로 구성… --- ## [LOTUS: 데이터에 LLM과 에이전트 처리를 대규모로 적용하는 시맨틱 연산자 프레임워크](https://discuss.pytorch.kr/t/lotus-llm/11235)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 13, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/lotus-llm/11235 "2026-07-13T21:30:06Z")
LOTUS 소개 LOTUS는 대규모 데이터셋에 LLM과 에이전트 기반 처리를 빠르고 안정적으로 적용하기 위한 프레임워크입니다. 문서 수천 건에서 특정 필드를 뽑거나, 코드베이스 전체를 훑어 버그를 찾거나, 에이전트 로그를 대량으로 분석하는 작업은 결국 "데이터셋의 모든 레코드에 대해 LLM을 반복 호출하는 일"로 귀결됩니다. 이때 호출을 어떻게 배치하고 어떤 모델을 언제 쓸지 직접 조율하지 않으면 정확도와 비용을 동시에 만족시키기 어렵습니다. LOTUS는 이 문제를 시맨틱 연산자(Semantic Operator)라는 선언적 추상화와 그것을 실행하는 옵티마이저로 풀어냅니다. LOTUS는 스탠퍼드 대학교(Stanford University)와 UC 버클리(UC Berkeley) 연구진이 만들었으며, 시맨틱 연산자의 개념과 최적화 기법은 논문 "Semantic Operators: A Declarative Model for Rich, AI-based Analytics Over Text Data" (arXiv:2407.11418)와 후속 VLDB 논문에서 제시되었습니다. 즉 LOTUS는 단순한 래퍼 라이브러리가 아니라, LLM 기반 데이터 처리를 관계형 데이터베이스의 질의 최적화처럼 다루려는 연구를 코드로 구현한 결과물입니다. 핵심 아이디어는 "무엇을 할지"와 "어떻게 실행할지"를 분리하는 것입니다. 사용자는 자연어 지시와 함께 map, filter, reduce 같은 고수준 연산자로 원하는 처리를 선언하고, LOTUS 옵티마이저가 호출 배칭·모델 캐스케이드·지연 실행(lazy execution) 같은 기법으로 실행 계획을 결정합니다. 본 게시물에서는 LOTUS의 동작 방식, 두 종류의 시맨틱 연산자, 설치와 사용법, 그리고 저자가 공개한 최적화 결과를 정리합니다. LOTUS의 동작 방식 LOTUS의 파이프라인은 네 단계로 요약됩니다. 데이터프레임·SQL·이미지·코드베이스·문서·텍스트 같은 코퍼스(corpus)를 입력으로 받고, 사용자는 이를 시맨틱 연산자로… --- ## [Cairn: 상태 공간 탐색으로 침투 테스트와 CTF를 푸는 범용 AI 문제 해결 엔진](https://discuss.pytorch.kr/t/cairn-ctf-ai/11176)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 11, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/cairn-ctf-ai/11176 "2026-07-11T02:30:58Z")
Cairn 소개 침투 테스트, 취약점 연구, 수학 증명, CTF 문제는 겉보기엔 서로 다른 분야지만 구조가 같습니다. 시작점(원본, target IP나 대상 시스템)이 명확하고, 도착점(셸 획득이나 플래그 획득 같은 목표)도 명확한데, 그 사이를 잇는 경로만 알 수 없다는 점입니다. Cairn은 이런 문제 부류를 풀기 위한 범용 문제 해결 엔진으로, README는 이를 "거의 무한한 상태 공간(state space)을 향한 방향성 탐색"이라고 설명합니다. 정해진 역할이나 워크플로우 없이 시작점과 목표만 주어지면 알려지지 않은 상태 공간을 탐색해 경로를 찾으며, 침투 테스트는 이 엔진이 처음으로 검증받은 도메인일 뿐이라고 소개하고 있습니다. Cairn의 핵심은 블랙보드 아키텍처(Blackboard Architecture)와 명시적인 fact-intent 그래프입니다. 세 가지 요소만으로 그래프가 굴러갑니다. 확인된 객관적 발견을 보드에 기록하는 Fact, 아직 실행하지 않은 탐색 방향을 선언하는 Intent, 언제든 주입할 수 있는 사람의 판단인 Hint입니다. 그래프는 origin에서 goal을 향해 자라나며, 새로운 Fact 하나하나가 디딤돌이 되고 Intent 하나하나가 미지의 영역으로 내딛는 발걸음이 됩니다. Agent Worker는 고정된 역할 없이 그래프의 현재 상태를 관찰(Observe)하고 방향을 잡아(Orient) 다음 Intent를 결정(Decide)한 뒤 실제로 탐색을 실행(Act)하는 OODA 루프를 돌립니다. Worker끼리는 직접 통신하지 않고 오직 공유 보드를 통해서만(Stigmergy) 협업합니다. 이 접근은 2026년 Tencent Cloud Hackathon의 AI 침투 테스트 챌린지 2회차에서 검증되었습니다. 610개 팀, 1,345명이 참가한 이 대회에서 Cairn은 54개 문제를 모두 풀어낸 유일한 팀(AK)이었고 최종 3위에 올랐습니다. README에 따르면 이 시스템은 대회 전 한 번도 테스트된 적이 없었고, 대… --- ## [claude-usage: Claude Code 토큰 사용량과 비용을 확인하는 로컬 대시보드](https://discuss.pytorch.kr/t/claude-usage-claude-code/11174)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 9, 2026, 11:30오후 UTC](https://discuss.pytorch.kr/t/claude-usage-claude-code/11174 "2026-07-09T23:30:35Z")
claude-usage 소개 Claude Code는 API, Pro, Max 요금제와 관계없이 세션마다 토큰 수·모델·프로젝트 정보를 담은 사용 로그를 로컬에 자동으로 남깁니다. 하지만 Anthropic 공식 UI는 이 로그를 세션별로 들여다보거나 비용으로 환산해 보여주지 않기 때문에, 자신이 오늘 얼마나 많은 토큰을 썼는지, Pro나 Max 정액제를 얼마나 소진했는지를 직관적으로 파악하기가 어렵습니다. claude-usage는 이 로컬 로그를 읽어 차트와 비용 추정치로 바꿔주는 대시보드로, 뉴스레터 The Product Compass 제작진이 만들었습니다. 접근 방식은 단순합니다. ~/.claude/projects/에 세션마다 하나씩 쌓이는 JSONL 트랜스크립트를 스캐너가 파싱해 SQLite 데이터베이스에 적재하고, 그 위에 웹 대시보드가 차트를 그립니다. Python 표준 라이브러리(sqlite3, http.server, json, pathlib)만 사용해 서드파티 패키지 없이 동작하며, pip install 이나 가상환경 구성 없이 바로 실행할 수 있습니다. 모든 처리가 로컬에서 끝나므로 사용 로그가 외부로 전송되지 않는다는 점도 특징입니다. Claude Code CLI, VS Code 확장의 Claude Code 사이드바, Claude Code로 라우팅되는 Dispatched Code 세션의 사용량을 모두 추적합니다. 다만 Cowork 세션은 서버 사이드에서 실행되어 로컬에 JSONL 트랜스크립트를 남기지 않으므로 집계 대상에서 제외됩니다. 웹 대시보드 외에 VS Code 확장으로도 제공되어, 에디터를 벗어나지 않고 같은 화면을 사이드바에서 바로 확인할 수 있습니다. claude-usage의 동작 원리 claude-usage의 핵심은 scanner.py와 dashboard.py 두 모듈입니다. Claude Code는 세션마다 하나의 JSONL 파일을 ~/.claude/projects/에 기록하며, assistant 타입 레코드에는 messa… --- ## [gemini-web2api: 웹 채팅 화면을 OpenAI 호환 API로 바꾸는 단일 파일 프록시](https://discuss.pytorch.kr/t/gemini-web2api-openai-api/11075)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 5, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/gemini-web2api-openai-api/11075 "2026-07-05T00:30:58Z")
gemini-web2api 소개 Google Gemini의 공식 API를 쓰려면 Google AI Studio나 Vertex AI에 가입하고 API 키를 발급받아야 하며, 사용량에 따라 과금됩니다. gemini-web2api는 이 과정을 건너뛰고, 브라우저로 접속하는 Gemini 웹 채팅 화면 자체를 OpenAI 호환 REST API처럼 쓸 수 있게 바꿔주는 파이썬 스크립트입니다. /v1/chat/completions, /v1/models 같은 OpenAI 형식 엔드포인트를 그대로 흉내 내기 때문에, OpenAI SDK나 OpenAI 호환을 지원하는 Cherry Studio·ChatBox 같은 클라이언트를 코드 수정 없이 그대로 연결할 수 있습니다. README는 이 프로젝트를 "Google Gemini의 웹 인터페이스를 OpenAI 호환 API로 변환. 무료, 크로스 플랫폼, 단일 파일"이라고 소개합니다. 별도 설치 과정이 복잡하지 않고 httpx 하나만 있으면 실행되는 단일 파이썬 파일로 되어 있어, 로컬에서 빠르게 띄워보고 싶은 개발자에게 접근성이 높습니다. 2026년 5월 공개된 뒤 두 달 만에 GitHub에서 1,900개 이상의 스타를 받았습니다. 이 저장소의 "How It Works" 절은 동작 원리를 숨기지 않고 그대로 밝히고 있습니다. Gemini 웹 앱이 사용하는 것과 동일한 StreamGenerate 엔드포인트로 요청을 보내며, 모델 선택은 요청 페이로드의 특정 필드 값을 Gemini 프런트엔드 자바스크립트의 MODE\_CATEGORY enum에서 가져와 매핑한다고 설명합니다. 즉 Google이 공식적으로 공개한 API가 아니라, 웹 페이지가 내부적으로 쓰는 비공개 프로토콜을 분석해 재현한 것입니다. gemini-web2api의 요청 처리 흐름 클라이언트가 OpenAI 형식으로 /v1/chat/completions에 요청을 보내면, 로컬에서 실행 중인 gemini-web2api 서버가 이를 받아 Gemini 웹이 쓰는 내부 프로… --- ## [AI Marketing Skills: 마케팅과 세일즈 업무를 자동화하는 오픈소스 Claude Code 스킬 모음](https://discuss.pytorch.kr/t/ai-marketing-skills-claude-code/10698)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 15, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/ai-marketing-skills-claude-code/10698 "2026-06-15T07:30:35Z")
AI Marketing Skills 소개 AI 코딩 에이전트에게 마케팅이나 세일즈 업무를 맡길 때, 대개는 잘 쓴 프롬프트 한 장에서 멈추곤 합니다. 그러나 실험을 설계하고 통계로 결과를 판정하거나, 방문자를 자격 있는 리드로 분류하고, 콘텐츠 품질을 일정 기준 이상으로 끌어올리는 일은 프롬프트만으로는 재현하기 어렵습니다. 스크립트와 채점 로직, 자동화 파이프라인이 함께 있어야 매번 같은 품질로 돌아갑니다. AI Marketing Skills는 이런 작업을 위한 오픈소스 Claude Code 스킬 모음입니다. 저자들은 "이것들은 프롬프트가 아니라, Claude Code(또는 다른 AI 코딩 에이전트)에 끼워 바로 실행할 수 있는 스크립트와 채점 알고리즘, 전문가 패널, 자동화 파이프라인을 갖춘 완성형 워크플로" 라고 설명합니다. 그로스 실험부터 세일즈 파이프라인, 콘텐츠 운영, 아웃바운드, SEO, 파이낸스 자동화까지 15개 카테고리로 구성되어 있습니다. 이 스킬들은 마케팅 회사 Single Brain 팀이 만들었으며, 저자들은 실제 매출을 내는 파이프라인에서 검증했다고 밝힙니다. 언어는 Python이고, MIT 라이선스로 공개되어 있습니다. 본 게시물에서는 주요 카테고리와 차별점, Claude Code와 함께 쓰는 방법을 정리합니다. AI Marketing Skills의 스킬 카테고리 AI Marketing Skills는 15개 카테고리로 나뉘며, 각 카테고리는 자체 README와 여러 개의 실행 가능한 스킬을 담고 있습니다. 대표적인 카테고리는 다음과 같습니다. 그로스 엔진(Growth Engine): 스스로 실행·측정·최적화하는 자율 마케팅 실험. 실험 엔진, 페이싱 알림, 주간 스코어카드를 포함합니다. 세일즈 파이프라인(Sales Pipeline): 익명 방문자를 자격 있는 파이프라인으로 전환합니다. RB2B 라우터, 딜 리저렉터(Deal Resurrector), 트리거 프로스펙터, ICP 학습기 등을 제공합니다. 콘텐츠 옵스(Con… --- ## [Yourself.skill: 당신의 기록으로 당신처럼 답하는 AI 페르소나를 만드는 Claude Code 스킬](https://discuss.pytorch.kr/t/yourself-skill-ai-claude-code/10495)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 3, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/yourself-skill-ai-claude-code/10495 "2026-06-03T03:30:39Z")
Yourself.skill 소개 최근 AI 코딩 에이전트 생태계에서는 특정 인물의 말투와 사고방식을 하나의 스킬(Skill)로 "증류(distill)"하려는 시도가 이어지고 있습니다. 떠난 동료를, 헤어진 연인을 대화 기록으로부터 재구성해 AI 페르소나로 만드는 식입니다. Yourself.skill은 그 대상을 타인이 아니라 자기 자신으로 돌려, 가장 많은 대화 상대이자 24시간 함께 있는 사람인 나를 스킬로 만든다는 발상에서 출발합니다. Yourself.skill은 대화 기록과 일기, 사진, 그리고 자기 자신에 대한 설명을 입력으로 받아, 이를 실행 가능한 구조로 분해하는 Claude Code 스킬입니다. 결과물은 두 부분으로 나뉩니다. 하나는 개인의 경험과 기억을 담은 Part A — 셀프 메모리(Self Memory), 다른 하나는 성격과 표현 방식을 정의한 Part B — 페르소나(Persona) 입니다. 이 둘을 합쳐, 나의 입버릇으로 생각하고 나의 논리로 답하는 디지털 복제본을 생성합니다. 이 프로젝트는 AgentSkills 오픈 표준을 따르며 Claude Code와 OpenClaw에서 동작합니다. 저자는 이 도구를 영생의 수단이 아니라 "현재 시점의 나를 마크다운으로 내보내는 포맷 변환" 이자 자기 관찰의 도구로 설명합니다. 본 게시물에서는 Yourself.skill의 두 부분 구조와 응답 흐름, 설치와 사용 방법, 진화 메커니즘을 정리합니다. Yourself.skill의 두 부분 구조 생성된 각 스킬은 셀프 메모리와 페르소나라는 두 부분으로 구성됩니다. 셀프 메모리(Part A) 는 개인의 경험, 핵심 가치관, 습관, 중요한 기억, 관계 패턴, 성장 궤적을 담습니다. 반면 페르소나(Part B) 는 성격을 다섯 개 층으로 나눠 정의하는데, 하드 규칙(hard rules)부터 정체성, 말투, 감정·의사결정 패턴, 대인 행동 순서로 쌓아 올립니다. 두 부분은 역할이 다릅니다. 페르소나가 "어떤 식으로 반응할 사람인가"라는 표현과 태도를 … --- ## [OpenKB: LLM이 문서를 자동으로 위키 형태의 지식 베이스로 컴파일하는 오픈소스 도구](https://discuss.pytorch.kr/t/openkb-llm/10058)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 4\ **마지막 업데이트:** [5월 8, 2026, 1:00오후 UTC](https://discuss.pytorch.kr/t/openkb-llm/10058 "2026-05-08T13:00:57Z")
OpenKB 소개 Andrej Karpathy는 LLM이 문서를 그때그때 검색하는 것을 넘어, 지식을 일종의 위키(wiki)로 지속적으로 컴파일하고 업데이트하는 방식이 훨씬 강력할 것이라고 이야기한 바 있습니다. 전통적인 RAG(Retrieval-Augmented Generation) 방식은 매 쿼리마다 지식을 새로 발견합니다. 이전에 분석한 내용이 축적되지 않고, 여러 문서에 걸친 교차 참조도 자동으로 만들어지지 않으며, 모순도 감지되지 않습니다. OpenKB는 이 아이디어를 실현한 오픈소스 커맨드라인 도구입니다. PDF, Word, Markdown, PowerPoint, HTML, Excel 등 다양한 형식의 문서를 투입하면, LLM이 그 문서들을 요약 페이지, 개념 페이지, 교차 참조가 있는 위키 형태의 지식 베이스로 자동 컴파일합니다. 한 번 컴파일된 지식은 이후 쿼리에서 재발견 없이 바로 활용되며, 새 문서가 추가될 때마다 기존 위키가 풍부해지는 누적 구조를 가집니다. LiteLLM을 통해 OpenAI, Claude, Gemini 등 다양한 LLM 프로바이더를 지원하며, 생성된 위키는 순수 마크다운 파일이라 Obsidian 등 로컬 도구에서도 열 수 있습니다. OpenKB의 특징적인 점은 짧은 문서와 긴 문서를 다르게 처리한다는 것입니다. 짧은 문서는 전체 텍스트를 LLM이 직접 읽지만, 20페이지 이상의 긴 PDF는 PageIndex 트리 인덱싱을 사용해 계층적 요약 트리를 만들고 LLM이 전체 텍스트 대신 트리를 읽습니다. 덕분에 수백 페이지짜리 기술 문서도 정확하게 처리하면서 컨텍스트 창 제한을 우회할 수 있습니다. OpenKB의 아키텍처 OpenKB가 문서를 지식 베이스로 변환하는 과정은 다음과 같이 동작합니다: raw/ # \<- 다양한 문서들이 위치하는 곳 │ │ ├─ 짧은 문서 ──→ markitdown ──→ LLM이 전체 텍스트 읽기 │ │ ├─ 긴… --- ## [Cognee: 지식 그래프와 벡터 검색을 결합하여 AI 에이전트에 장기 기억을 부여하는 오픈소스 지식 엔진](https://discuss.pytorch.kr/t/cognee-ai/9852)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [5월 1, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/cognee-ai/9852 "2026-05-01T03:30:25Z")
Cognee 소개 현대 AI 에이전트와 챗봇이 가진 가장 근본적인 한계 중 하나는 기억의 부재입니다. 대부분의 LLM 기반 시스템은 대화 세션이 종료되면 모든 맥락을 잃어버리며, 다음 세션에서 동일한 정보를 처음부터 다시 학습해야 합니다. 벡터 데이터베이스를 활용한 RAG(Retrieval-Augmented Generation)가 이를 부분적으로 해결하지만, 단순 유사도 검색은 문서 간의 관계와 맥락적 연결을 포착하지 못하는 한계가 있습니다. Cognee는 지식 그래프(Knowledge Graph), 벡터 검색, 인지과학 원리를 결합하여 AI 에이전트에게 진정한 장기 기억(Persistent Memory)을 부여하는 오픈소스 지식 엔진입니다. 단순히 정보를 저장하고 검색하는 것을 넘어, 정보들 간의 관계를 그래프 구조로 표현하고 에이전트의 피드백을 통해 지속적으로 개선되는 동적 메모리 시스템을 제공합니다. Cognee의 핵심 설계 철학은 기억의 4가지 기본 연산인 기억하기(remember), 불러오기(recall), 잊기(forget), 개선하기(improve)를 명확한 API로 추상화하는 것입니다. 이를 통해 개발자는 복잡한 그래프 데이터베이스 쿼리나 벡터 임베딩 파이프라인의 세부 구현 없이도 에이전트에 장기 메모리를 손쉽게 통합할 수 있습니다. Python 3.10~3.13을 지원하며, Neo4j 그래프 데이터베이스와 다양한 벡터 데이터베이스를 백엔드로 활용합니다. Cognee의 주요 특징과 통합 옵션 Cognee는 다양한 멀티모달 데이터 형식(텍스트, PDF, URL, 코드, 이미지 등)을 통합된 파이프라인으로 처리하며, 온톨로지(Ontology) 기반 그라운딩을 통해 도메인 특화 지식 표현도 지원합니다. 에이전트 간 지식 공유(Cross-agent Knowledge Sharing)를 통해 여러 에이전트 인스턴스가 동일한 지식 베이스를 공유하고 협력할 수 있습니다. 주요 통합 환경: Claude Code 플러그인: cognee-… --- ## [Privacy Parser: OpenAI 1.5B 개인정보 보호 모델을 역이용한 PII 구조화 추출 라이브러리](https://discuss.pytorch.kr/t/privacy-parser-openai-1-5b-pii/9925)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 29, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/privacy-parser-openai-1-5b-pii/9925 "2026-04-29T03:30:35Z")
Privacy Parser 소개 OpenAI에서는 최근 텍스트에서 개인 식별 정보(PII, Personally Identifiable Information)를 탐지하고 마스킹하는 Privacy Filter 모델을 공개한 바 있습니다. (관련 글: OpenAI Privacy Filter: 텍스트에서 개인정보를 탐지하고 마스킹하는 양방향 토큰 분류 모델) 이 1.5B 파라미터 모델은 텍스트 내의 이름, 이메일, 전화번호, 주소 등의 민감한 정보를 \ 토큰으로 대체하는 방어(Defense) 도구로 설계되었습니다. 그러나 모든 방어 도구에는 반대편이 존재합니다. 데이터 유출 사고 조사, 포렌식 분석, 개인정보 감사 등의 작업에서는 마스킹이 아닌 추출이 필요합니다. 로그 파일, 데이터베이스 덤프, 유출된 메일함 등에서 어떤 개인정보가 노출되어 있는지 구조화된 형태로 파악해야 할 때, Privacy Filter의 마스킹 출력은 오히려 필요한 정보를 숨겨버립니다. Privacy Parser는 OpenAI Privacy Filter와 동일한 1.5B 모델, 동일한 레이블 분류 체계, 동일한 가중치를 사용하면서 출력 방향을 반전시킨 라이브러리입니다. \ 대신 무엇이, 어디에, 어떤 유형으로 있는지를 구조화된 스팬(span) 형태로 반환합니다. Privacy Filter가 방어(Defense) 도구라면, Privacy Parser는 감사(Audit) 도구입니다. 같은 모델을 사용하므로 Privacy Filter가 탐지할 수 있는 모든 유형의 PII를 동일한 정확도로 추출할 수 있습니다. Privacy Parser는 세 가지 백엔드를 제공합니다. 규칙 기반 PIIParser 는 마이크로초 단위의 초고속 처리가 가능하며 F1 1.000을 달성하지만 사전 정의된 패턴에만 작동합니다. ModelPIIParser 는 1.5B 모델만 사용하며 CPU에서 약 500ms, F1 0.733의 성능을 보입니다. HybridPIIParser 는 모델 추론,… --- ## [Motus: 프레임워크에 종속되지 않는 오픈소스 AI 에이전트 서빙 인프라](https://discuss.pytorch.kr/t/motus-ai/9834)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 23, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/motus-ai/9834 "2026-04-23T09:30:38Z")
Motus 소개 AI 에이전트를 프로토타입에서 프로덕션 환경으로 배포하는 과정에는 다양한 어려움이 따릅니다. 특정 에이전트 프레임워크에 종속되면 공급자 교체나 모델 스위칭 시 대규모 리팩토링이 필요하고, 복잡한 멀티 스텝 작업을 관리하기 위한 태스크 오케스트레이션, 메모리 관리, 가드레일 구현이 각각 분리된 도구로 흩어져 있는 경우가 많습니다. Motus는 이러한 문제를 해결하기 위해 설계된 오픈소스 에이전트 서빙 플랫폼으로, Lithos AI가 개발했습니다. "노 프레임워크(no-framework)" 철학을 채택하여 OpenAI, Anthropic Claude, Google Gemini, OpenRouter 등 다양한 모델 제공자를 단일 인터페이스로 사용할 수 있으며, 에이전트 워크플로우 정의부터 로컬 서빙, 클라우드 배포까지의 전체 파이프라인을 지원합니다. Motus의 핵심 설계 원칙은 데이터 흐름 기반 자동 병렬화(task-graph runtime) 입니다. 개발자가 @agent\_task 데코레이터로 작업을 정의하면, Motus는 데이터 의존성을 분석하여 독립적인 작업들을 명시적인 DAG 정의 없이도 자동으로 병렬 실행합니다. 이를 통해 복잡한 멀티 에이전트 워크플로우를 간결한 Python 코드로 표현할 수 있습니다. 또한 motus serve 명령어 하나로 로컬 HTTP 서버를 띄울 수 있어, 개발 환경에서 빠른 테스트와 반복이 가능합니다. Motus는 인터랙티브 HTML 트레이싱(tracing)과 관찰 가능성(observability) 도구를 내장하고 있어, 에이전트가 어떤 도구를 어떤 순서로 호출했는지 시각적으로 확인할 수 있습니다. MCP(Model Context Protocol) 서버 통합, Docker 샌드박스 실행, 사람이 개입하는 승인 워크플로우(Human-in-the-loop), 입출력 가드레일 등 프로덕션 에이전트에 필요한 요소들을 하나의 패키지로 제공합니다. Motus의 핵심 기능 ReActAgent와 도구 정의: Motus… --- ## [GenericAgent: 3,300줄의 시드 코드에서 시작해 스스로 스킬을 성장시키는 자기 진화형 LLM 에이전트 프레임워크](https://discuss.pytorch.kr/t/genericagent-3-300-llm/9850)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 23, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/genericagent-3-300-llm/9850 "2026-04-23T06:30:29Z")
GenericAgent 소개 자율형 AI 에이전트의 실제 활용 가능성은 오래전부터 논의되어 왔지만, 기존 에이전트 프레임워크들은 수십만 줄에 달하는 복잡한 코드 기반과 수십만 개의 컨텍스트 토큰을 소비하는 무거운 구조로 인해 실용성에 한계가 있었습니다. 복잡한 환경 설정, 과도한 비용, 느린 반응 속도는 실제 개인 사용자나 소규모 팀이 자율 에이전트를 일상 업무에 적용하기 어렵게 만들었습니다. GenericAgent는 이러한 문제를 정면으로 해결하기 위해 탄생한 경량 자기 진화형 에이전트 프레임워크입니다. GenericAgent의 핵심 철학은 "최소한의 코드로 최대한의 능력"입니다. 약 3,300줄의 핵심 코드와 약 100줄의 에이전트 루프로 구성된 이 프레임워크는, 사전에 모든 기능을 코드에 내장하는 대신 실제 작업 수행 과정을 통해 스스로 능력을 성장시킵니다. 작업을 수행하면서 성공적인 실행 경로를 스킬(Skill)로 결정화(crystallize)하여 재사용 가능한 형태로 메모리에 저장하고, 다음에 유사한 작업이 발생했을 때 즉시 활용합니다. 이를 통해 에이전트는 사용할수록 더 강력하고 효율적으로 성장합니다. GenericAgent는 Claude, Gemini, Kimi, MiniMax 등 주요 LLM을 지원하며, 실제 브라우저 자동화(로그인 세션 유지), 터미널 제어, 파일 시스템 접근, 키보드/마우스 입력, 화면 비전, Android ADB 등 9가지 원자적 도구를 통해 시스템 수준의 컴퓨터 제어가 가능합니다. 기술 보고서는 arXiv:2604.17091에 공개되어 있으며, MIT 라이선스로 자유롭게 활용할 수 있습니다. GenericAgent의 자기 진화 메커니즘 GenericAgent의 가장 독창적인 특징은 계층적 메모리 시스템과 자기 진화 루프입니다. 에이전트는 새로운 작업을 만나면 탐색하고 실험하며 스스로 해결책을 찾아냅니다. 이 과정이 성공적으로 완료되면 해당 실행 경로를 재사용 가능한 스킬로 변환하여 메모리에 저장합니다. \[… --- ## [Browser Harness: LLM이 직접 Chrome을 제어하며 부족한 기능을 스스로 구현하는 자기 치유형 브라우저 자동화 프레임워크](https://discuss.pytorch.kr/t/browser-harness-llm-chrome/9821)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 23, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/browser-harness-llm-chrome/9821 "2026-04-23T00:30:26Z")
Browser Harness 소개 브라우저 자동화는 AI 에이전트가 웹 기반 작업을 수행하는 데 필수적인 능력입니다. 그러나 기존 접근법들은 대부분 미리 정의된 도구 집합에 의존합니다. 에이전트가 예상치 못한 UI 요소를 만나거나, 특수한 인터랙션이 필요한 상황이 발생하면 작업을 완료하지 못하고 멈춥니다. Browser Harness는 이 문제를 근본적으로 다르게 접근합니다. LLM이 Chrome DevTools Protocol(CDP)에 직접 웹소켓으로 연결하여 브라우저를 제어하고, 필요한 기능이 없을 때는 helpers.py 파일을 직접 수정하여 스스로 구현합니다. 이것이 Browser Harness를 "자기 치유(Self-Healing)" 프레임워크로 부르는 이유입니다. Browser Harness의 핵심 설계 원칙은 최소주의(Minimalism)입니다. 전체 코드가 약 592줄의 Python으로 구성되어 있습니다. run.py(36줄), helpers.py(195줄), admin.py와 daemon.py(361줄)가 전부입니다. Selenium, Playwright 같은 무거운 프레임워크 없이, Chrome의 CDP WebSocket에 직접 연결하여 가장 낮은 수준에서 브라우저를 제어합니다. ● agent: wants to upload a file │ ● helpers.py → upload\_file() missing │ ● agent edits the harness and writes it helpers.py 192 → 199 lines │ + upload\_file() ✓ file uploaded 이 단순함은 LLM이 코드 전체를 쉽게 이해하고, 필요에 따라 helpers.py를 수정하여 새로운 기능을 추가할 수 있게 합니다. 에이전트는 단순히 도구를 사용하는 것을 넘어, 도구 자체를 개선하는 수준의 자율성을 갖습… --- ## [OpenAI Agents SDK: 멀티 에이전트 워크플로우 구축을 위한 경량 파이썬 프레임워크](https://discuss.pytorch.kr/t/openai-agents-sdk/9778)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 18, 2026, 4:30오전 UTC](https://discuss.pytorch.kr/t/openai-agents-sdk/9778 "2026-04-18T04:30:06Z")
OpenAI Agents SDK 소개 복잡한 AI 에이전트 시스템을 구축하려면 단일 에이전트의 한계를 넘어 여러 에이전트가 협력하는 멀티 에이전트 워크플로우가 필요합니다. 청구 처리는 청구 전문 에이전트가, 환불은 환불 전문 에이전트가 처리하도록 작업을 위임하는 구조, 그리고 사용자 입력이나 에이전트 출력이 안전한지 검증하는 가드레일이 이 모든 과정에 필요합니다. OpenAI는 2025년에 OpenAI Agents SDK(openai-agents-python)를 오픈소스로 공개하여 이러한 멀티 에이전트 워크플로우를 간단하고 직관적으로 구축할 수 있는 경량 프레임워크를 제공합니다. OpenAI Agents SDK는 이전에 실험적으로 공개했던 Swarm 프레임워크의 후속작으로, 프로덕션 환경에서 사용할 수 있도록 안정화되고 기능이 확장된 버전입니다. OpenAI API뿐만 아니라 100개 이상의 다른 LLM 프로바이더와도 함께 사용할 수 있어 특정 모델에 종속되지 않습니다. OpenAI Agents SDK의 핵심 개념 SDK는 9가지 핵심 구성 요소를 중심으로 설계되어 있으며, 각 개념이 명확하게 분리되어 있어 이해하고 조합하기 쉽습니다. 에이전트(Agent)와 도구(Tool) 에이전트(Agent) 는 지시사항(instructions), 도구(tools), 가드레일(guardrails), 핸드오프(handoffs)를 갖춘 LLM입니다. 일반 파이썬 함수를 @function\_tool 데코레이터로 도구로 등록하거나, MCP 서버를 도구로 연결하거나, OpenAI의 호스팅 도구(웹 검색, 코드 해석기 등)를 사용할 수 있습니다. from agents import Agent, function\_tool, Runner import asyncio @function\_tool def get\_weather(city: str) -\> str: """도시의 현재 날씨를 반환합니다.""" # 실제 날씨 API 호출 로직 return f"{city}… --- ## [Mini-Coding-Agent: AI 코딩 에이전트의 6가지 핵심 구성 요소를 설명하는 최소 구현체 (feat. Sebastian Raschka)](https://discuss.pytorch.kr/t/mini-coding-agent-ai-6-feat-sebastian-raschka/9638)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 16, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/mini-coding-agent-ai-6-feat-sebastian-raschka/9638 "2026-04-16T21:30:47Z")
Mini-Coding-Agent 프로젝트 소개 Claude Code, Cursor, Windsurf와 같은 AI 코딩 에이전트(coding agent)들이 어떻게 동작하는지 궁금했던 적이 있으신가요? 이 도구들은 단순히 LLM에게 코드를 물어보는 것을 넘어, 저장소 구조를 파악하고, 파일을 읽고 쓰며, 커맨드를 실행하고, 이전 작업 컨텍스트를 이어받는 복잡한 에이전트 루프(agent loop)를 구현합니다. Mini-Coding-Agent는 이러한 AI 코딩 에이전트의 핵심 구성 요소를 가능한 한 간결하고 읽기 쉬운 Python 코드로 구현한 교육용 프로젝트입니다. 이 프로젝트는 PyTorch 생태계의 ML 교육 자료 및 최근 여러 최신 LLM들의 구조를 시각화한 'LLM 아키텍처 갤러리' 프로젝트로 잘 알려진 Sebastian Raschka가 공개하였으며, 별도의 외부 Python 라이브러리 의존성 없이 표준 라이브러리만으로 동작하는 것이 특징입니다. Mini-Coding-Agent 프로젝트의 의의는 "어떻게 만드는가"보다 "왜 이렇게 설계되었는가"를 이해하는 데 있습니다. 프로덕션 수준의 견고함보다 가독성(readability)을 우선시하여, AI 에이전트를 처음 접하는 개발자도 코드를 읽으면서 각 컴포넌트의 역할과 상호작용을 직관적으로 이해할 수 있습니다. Ollama를 모델 백엔드로 활용하기 때문에 OpenAI API 키 없이도 로컬에서 완전히 실행 가능하며, 기본 모델로는 qwen3.5:4b를 사용합니다. 현재 GitHub 저장소는 474개의 스타와 92개의 포크를 기록 중입니다. Mini-Coding-Agent의 6가지 핵심 구성 요소 Mini-Coding-Agent의 가장 큰 교육적 가치는 AI 코딩 에이전트를 구성하는 6가지 핵심 아키텍처 패턴을 명확하게 분리하여 구현한 점입니다. Sebastian Raschka는 자신의 블로그에서 이 6가지 요소가 실제 코딩 에이전트들이 공통으로 채택하는 설계 원칙임을 설명합니다: 1. … --- ## [reverse-SynthID: Gemini 생성 이미지에 숨겨진 SynthID 워터마크를 스펙트럼 분석으로 탐지하고 제거하는 역공학 연구](https://discuss.pytorch.kr/t/reverse-synthid-gemini-synthid/9734)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 16, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/reverse-synthid-gemini-synthid/9734 "2026-04-16T06:30:42Z")
reverse-SynthID 소개 AI가 생성한 이미지가 급속도로 확산되면서, Google DeepMind는 Gemini 모델로 생성된 이미지에 눈에 보이지 않는 디지털 워터마크를 삽입하는 SynthID 기술을 개발하였습니다. SynthID는 이미지의 픽셀 데이터에 사람의 눈으로는 식별할 수 없는 신호를 심어, AI 생성 여부를 나중에라도 검증할 수 있도록 설계된 기술입니다. 이러한 워터마킹 시스템은 딥페이크 탐지, 저작권 보호, AI 콘텐츠 추적 등 다양한 분야에서 중요한 역할을 합니다. reverse-SynthID는 Alosh Denny가 공개한 연구 프로젝트로, SynthID의 내부 동작 방식을 신호 처리와 스펙트럼 분석 기법으로 역공학하는 것을 목표로 합니다. 이 프로젝트는 SynthID 워터마크를 90%의 정확도로 탐지하는 검출기(detector)를 구현하고, 동시에 높은 시각적 품질을 유지하면서 워터마크를 제거하는 우회(bypass) 기법을 세 단계의 버전으로 발전시켜 공개하였습니다. 이 연구는 AI 워터마킹 기술의 취약점을 분석하고, 향후 더 강력한 워터마킹 시스템 설계에 기여하고자 하는 목적에서 수행되었습니다. 프로젝트의 GitHub 저장소는 2.6k 스타를 기록하며 AI 보안(AI Security) 및 신호 처리 커뮤니티에서 주목을 받고 있습니다. 논문 및 벤치마크 데이터도 함께 공개되어 있으며, 연구 재현성을 위한 기준 이미지 데이터셋을 HuggingFace를 통해 제공하고 있습니다. reverse-SynthID의 핵심 발견: 해상도 의존적 캐리어 주파수 이 연구의 가장 중요한 발견은 SynthID가 이미지 해상도에 따라 다른 절대적 위치에 캐리어 주파수(carrier frequency)를 삽입한다는 것입니다. 워터마크는 고정된 위상(fixed phase values)과 해상도 의존적 캐리어 주파수를 사용하므로, 단일 해상도만을 대상으로 하는 기존의 접근법으로는 효과적인 탐지나 제거가 어렵습니다. reverse-SynthID 팀은 … --- ## [AITune: NVIDIA가 공개한 딥러닝 모델 추론 성능 자동 최적화 파이썬 라이브러리](https://discuss.pytorch.kr/t/aitune-nvidia/9699)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 13, 2026, 9:31오전 UTC](https://discuss.pytorch.kr/t/aitune-nvidia/9699 "2026-04-13T09:31:00Z")
AITune 소개 딥러닝 모델을 프로덕션 환경에 배포할 때 가장 큰 과제 중 하나는 추론 성능 최적화입니다. TensorRT(텐서알티), TorchAO, Torch Inductor 등 다양한 최적화 백엔드가 존재하지만, 각각 다른 API와 설정 방식을 요구하기 때문에 실무에서는 어떤 백엔드를 선택하고 어떻게 적용할지 판단하기가 쉽지 않습니다. NVIDIA의 AI Dynamo 팀이 공개한 AITune은 이러한 복잡성을 단 몇 줄의 코드로 해결해주는 추론 최적화 툴킷(Inference Toolkit)입니다. AITune은 PyTorch 모델 또는 파이프라인에 대해 TensorRT, Torch-TensorRT, TorchAO, Torch Inductor 등 다양한 최적화 백엔드를 통합 API로 제공합니다. 개발자가 어떤 백엔드를 사용하든 동일한 인터페이스로 모델을 검사(Inspect)하고, 최적화 대상 모듈을 선정(Wrap)하며, 튜닝(Tune)을 실행하고, 결과를 저장(Save)할 수 있습니다. NVIDIA GPU에 특화된 설계로, PyTorch 2.7 이상 환경에서 컴퓨터 비전(Computer Vision), 자연어 처리(NLP), 음성 인식, 생성형 AI(Generative AI) 등 다양한 워크로드에 적용할 수 있습니다. 2026년 4월 기준으로, NVIDIA의 AITune 프로젝트는 Apache 2.0 라이선스 하에 GitHub에 공개되어 있으며, NVIDIA의 PyPI 인덱스를 통해 쉽게 설치할 수 있습니다. PyTorch 커뮤니티에서 추론 최적화 파이프라인을 구성하는 데 참고할 만한 실용적인 오픈소스 도구입니다. AITune의 두 가지 동작 모드: JIT(Just-in-Time) 튜닝 vs. AOT(Ahead-of-Time) 튜닝 비교 NVIDIA AITune은 프로젝트의 특성과 개발자의 요구에 따라 선택할 수 있는 사전 컴파일 모드(AOT, Ahead-of-Time) 와 실시간 컴파일 모드(JIT, Just-In-Time) 두 가지 방식을 … --- ## [LightRAG: 지식 그래프 기반의 이중 검색 구조로 GraphRAG보다 빠른 RAG 프레임워크 (feat. EMNLP 2025)](https://discuss.pytorch.kr/t/lightrag-graphrag-rag-feat-emnlp-2025/9612)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 10, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/lightrag-graphrag-rag-feat-emnlp-2025/9612 "2026-04-10T03:30:16Z")
LightRAG 소개 대규모 언어 모델(LLM, Large Language Model)을 기업 내부 문서나 전문 지식과 결합하는 방식으로 검색 증강 생성(RAG, Retrieval-Augmented Generation)이 폭넓게 사용되고 있습니다. 그러나 전통적인 RAG 방식은 문서를 청크(chunk)로 나누어 벡터 데이터베이스에 저장하고, 질의와 유사한 청크를 검색해 LLM에 전달하는 구조로, 개별 청크 간의 연결성이나 문서 전체를 관통하는 개념적 관계를 파악하기 어렵다는 한계가 있습니다. 홍콩 대학교 데이터 사이언스(HKUDS) 연구팀은 이 문제를 해결하기 위해 지식 그래프(Knowledge Graph)와 벡터 검색을 결합한 LightRAG를 개발하였으며, 해당 연구는 EMNLP 2025에 발표되었습니다. LightRAG는 기존 RAG의 청크 검색 방식을 넘어, 문서에서 자동으로 엔티티(entity)와 관계(relation)를 추출하여 지식 그래프를 구성합니다. 이렇게 만들어진 그래프 위에서 질의(query)의 성격에 따라 로컬(local), 글로벌(global), 하이브리드(hybrid) 세 가지 검색 모드를 조합하여 응답의 완결성과 다양성을 높입니다. Microsoft의 GraphRAG와 개념적으로 유사하지만, LightRAG는 구조적 단순성과 처리 속도, 오픈소스 접근성을 강점으로 내세웁니다. LightRAG는 PyPI에서 lightrag-hku 패키지로 제공되며, 웹 UI와 REST API를 포함한 서버 모드, 그리고 Python 라이브러리로 임베드하는 코어 모드 두 가지 방식으로 사용할 수 있습니다. PostgreSQL, MongoDB, Neo4j, OpenSearch 등 다양한 스토리지 백엔드를 지원하며, Docker를 통한 빠른 배포도 가능합니다. 또한, HKUDS 연구팀이 VideoRAG, MiniRAG, RAG-Anything 등의 연관 프로젝트를 지속적으로 개발하면서 활발한 생태계를 형성하고 있습니다. LightRAG vs… --- ## [AI Engineering from Scratch: 선형대수부터 자율 에이전트 스웜까지, 230개 이상의 실습 과정으로 구성된 오픈소스 AI 엔지니어링 커리큘럼](https://discuss.pytorch.kr/t/ai-engineering-from-scratch-230-ai/9336)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [3월 25, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/ai-engineering-from-scratch-230-ai/9336 "2026-03-25T03:30:39Z")
AI Engineering from Scratch 소개 AI 엔지니어링을 제대로 배우고 싶은데 어디서 시작해야 할지 막막한 분들이 많습니다. 시중에는 수많은 AI 관련 강의와 자료들이 있지만, 대부분 특정 분야(NLP 또는 비전 또는 에이전트)에만 집중하거나, Python 하나만 다루거나, 영상 시청과 이론 학습에 그쳐 실제로 무언가를 만들어 본 경험을 쌓기 어렵습니다. AI Engineering from Scratch는 이런 한계를 넘어서기 위해 설계된 오픈소스 커리큘럼입니다. AI Engineering from Scratch는 선형대수와 확률론 같은 수학 기초부터 시작하여, 고전적인 머신러닝, 딥러닝, 자연어 처리, 컴퓨터 비전, 음성 처리, 트랜스포머 아키텍처, 대규모 언어 모델(LLM), 자율 에이전트, 멀티 에이전트 스웜까지 AI 엔지니어링의 전 영역을 20개 단계, 230개 이상의 실습 과정으로 체계적으로 다룹니다. Python만 사용하는 것이 아니라, TypeScript, Rust, Julia까지 다양한 언어를 사용하며, 각 레슨은 단순한 이론 설명에 그치지 않고 직접 동작하는 코드와 노트북, 문서, 그리고 재사용 가능한 결과물(프롬프트, 스킬, 에이전트, MCP 서버)을 생산합니다. rohitg00가 개발 및 공개한 이 프로젝트는 "배우고(Learn it), 만들고(Build it), 다른 사람들을 위해 공유하라(Ship it for others)"라는 모토 아래 운영됩니다. 특히, MIT 라이선스로 오픈소스 공개되어 있어 누구나 무료로 활용하고 기여할 수 있습니다. 다른 AI 강의/교재와의 비교 AI Engineering from Scratch는 기존의 AI 학습 자료들과 여러 면에서 차별화됩니다. 항목 기타 강의/교재 AI Engineering from Scratch 범위 한 분야(NLP 또는 비전 또는 에이전트) 전 영역: 수학, ML, DL, NLP, 비전, 음성, 트랜스포머, LLM, 에이전트, 스웜 언어 P… --- ## [MOSEC: Rust와 Python이 조화를 이루는 고성능 머신러닝 모델 서빙 프레임워크](https://discuss.pytorch.kr/t/mosec-rust-python/7926)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 10, 2025, 6:00오전 UTC](https://discuss.pytorch.kr/t/mosec-rust-python/7926 "2025-10-10T06:00:31Z")
MOSEC 개요 인공지능(ML/DL) 모델은 실험실이나 연구 환경에서는 잘 작동하지만, 실제 서비스로 배포할 때 직면하는 과제들은 매우 복잡합니다. 여러 요청을 동시에 처리하거나, 응답 지연 시간(latency)을 제어하는 등, 주어진 리소스를 어떻게 효율적으로 활용할지에 대한 고민은 물론, 요청이 많아지면서 발생하는 규모의 확장(Scaling)이나 워크로드 특성이 변화할 때의 대응 등과 같이 연구 단계에서 완성된 모델이 안정적으로 온라인 요청을 처리하기 위해서는 다수의 기술적 과제가 뒤따릅니다. 이런 문제들을 해결하기 위해서는, 단순히 “모델을 API로 노출하는 것”을 넘어서는 수준의 시스템 설계가 필요합니다. MOSEC (Model Serving made Efficient in the Cloud) 은 이러한 현실적 제약을 고려해 설계한 오픈소스 모델 서빙 프레임워크입니다. MOSEC은 고성능 모델 서빙을 위해 Rust의 성능과 Python의 사용성을 결합한 오픈소스 프레임워크로, 모델을 손쉽게 API 서비스 형태로 배포할 수 있도록 설계되었습니다. Rust 기반의 비동기 웹 서버와 Python API를 동시에 활용함으로써, 시스템 수준에서는 고속 처리와 안정성을, 개발자 입장에서는 높은 접근성과 생산성을 동시에 제공합니다. MOSEC의 주요 특징은 다음과 같습니다: 고성능 (Rust + 비동기 I/O 기반 웹 계층) 사용성 (Python API 중심 인터페이스) 동적 배칭 (Dynamic Batching) 파이프라인 병렬 처리 (CPU / GPU 혼합 워크로드 분할) 클라우드 친화성 (Kubernetes 배포, graceful shutdown, 메트릭 노출 등) 프레임워크 독립성 (PyTorch, TensorFlow, JAX 등 다양한 모델 지원) 즉, MOSEC은 “학습된 모델 → 실제 서비스 API” 사이의 간극을 메우는 미들웨어 역할을 하며, 특히 고성능을 요구하는 실시간 혹은 준실시간 응답 시스템에서 유용합니다. MOSEC의 구조 및… --- ## [HumanLayer: 3세대 자율형 에이전트를 위한, 사람과 협업하는 SDK](https://discuss.pytorch.kr/t/humanlayer-3-sdk/5814)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [1월 7, 2025, 11:10오후 UTC](https://discuss.pytorch.kr/t/humanlayer-3-sdk/5814 "2025-01-07T23:10:58Z")
HumanLayer 소개 HumanLayer는 LLM을 활용하는 AI 에이전트가 사람들과 더 안전하고 효과적으로 협업할 수 있도록 지원하는 Python 및 TypeScript 기반 툴킷입니다. 대부분의 LLM 기반 에이전트는 자율성을 가지며 작업을 처리하지만, 민감한 작업에서는 오류가 큰 문제로 이어질 수 있습니다. 예를 들어, SQL 데이터베이스 수정, 이메일 전송, 고객 데이터 업데이트와 같은 작업에서는 90%의 정확도로는 충분하지 않습니다. 따라서 HumanLayer는 이러한 고위험 작업에 대해 인간 승인과 사람의 도구화를 통해 신뢰성을 높입니다. 이를 통해 에이전트가 독립적으로 작업을 수행하면서도 중요한 순간에 인간의 검토와 결정을 요청할 수 있도록 설계되었습니다. HumanLayer는 Python, TypeScript, REST API를 지원하며, LangChain, OpenAI, CrewAI 등 다양한 Agent Framework들과 통합할 수 있습니다. 그 외 주요한 HumanLayer의 특징은 다음과 같습니다: @require\_approval 데코레이터: 고위험 함수에 대해 인간 승인을 요구하는 기능을 제공합니다. LLM이 잘못된 결정을 내려도 인간 검토를 통해 안전성을 보장할 수 있습니다. hl.human\_as\_tool(): AI 에이전트가 작업 도중 사람의 도움을 요청하도록 설계된 기능입니다. 예를 들어, 이메일 초안 검토나 문제 해결을 위해 사람의 피드백을 받을 수 있습니다. 멀티채널 통합: Slack, Email, Discord 등 다양한 플랫폼을 통해 사용자와 상호작용할 수 있습니다. 프레임워크 독립성: LangChain, CrewAI와 같은 다양한 AI 프레임워크와 통합되어 사용 가능합니다. HumanLayer와 3세대 자율형 에이전트 HymanLayer는'차세대 AI Agent'인 자율형 에이전트(Autonomous Agents)를 위해 개발 중입니다. 먼저, 기존의 LLM 애플리케이션의 역사를 살… --- ## [\[GN\] 초보자를 위한 AI Python - Andrew Ng 의 무료 강의](https://discuss.pytorch.kr/t/gn-ai-python-andrew-ng/5742)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 2\ **마지막 업데이트:** [1월 4, 2025, 12:47오후 UTC](https://discuss.pytorch.kr/t/gn-ai-python-andrew-ng/5742 "2025-01-04T12:47:39Z")
배우는 내용 Python 프로그래밍 기초 및 데이터를 조작, 분석, 시각화하기 위한 AI 도구 통합 방법 학습 Python을 비즈니스, 마케팅, 저널리즘 등 다양한 분야에 적용하여 실제 문제를 해결하고 효율성을 향상시키는 방법 AI 어시스턴트를 활용하여 코드 디버깅, 개념 설명, 학습 강화 등 소프트웨어 개발 실무와 유사한 환경 체험 강의 소개 Python 프로그래밍의 힘을 활용할 수 있도록 설계되었으며, 소프트웨어 개발자나 AI 엔지니어를 목표로 하지 않는 사람들도 참여 가능 4개의 파트로 구성. 프로그래밍 경험이 없더라도 "Hello, World!" 작성에서부터 실용적인 AI 응용 프로그램 코딩을 바로 시작할 수 있도록 지원 AI 챗봇을 통해 즉각적인 피드백, 질문 응답, 디버깅을 제공받으며 학습 과정에서 지속적으로 도움을 받을 수 있음 Python 기본기를 배우며 변수, 함수, 루프, 데이터 구조 등 필수 프로그래밍 개념 학습 AI를 활용한 맞춤형 레시피 생성기, 스마트 할 일 목록, 여행 일정 계획자 등을 제작하며 데이터 분석 및 시각화 기술 습득 실습 프로젝트 맞춤형 레시피 생성기: AI를 활용하여 재료 기반으로 레시피를 생성하는 도구 개발 스마트 할 일 목록: 할 일 저장 및 우선순위 설정을 포함한 AI 기반 작업 관리 도구 제작 여행 블로그 분석기: 블로그에서 식당 이름 및 인기 메뉴 등 핵심 정보 추출 꿈의 여행 일정 계획자: 다중 도시 여행 계획을 AI로 분석하여 일정 제안 데이터 시각화 프로젝트: matplotlib 등 라이브러리를 활용하여 데이터 시각화 웹 데이터 추출: BeautifulSoup을 사용하여 웹 데이터를 수집 및 처리 실시간 데이터 응용 프로그램: API를 통해 실시간 데이터 가져오기 및 처리 AI를 활용하여 학습 가속화 AI 챗봇을 통합하여 코드 작성, 테스트, 디버깅 지원 AI 도구를 통해 학습 속도 향상, 실습 강화, 맞춤형 피드백 제공 초보자도 단시간에 Python과 AI를 활용한 응용 프로그램 제작 … --- ## [TinyGPT: Python만으로 구현한, GPT 모델 구현 라이브러리](https://discuss.pytorch.kr/t/tinygpt-python-gpt/5181)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 10, 2024, 10:21오후 UTC](https://discuss.pytorch.kr/t/tinygpt-python-gpt/5181 "2024-09-10T22:21:53Z")
TinyGPT 소개 TinyGPT는 GPT 모델을 처음부터 구현하고 학습 및 추론을 수행하는 데 필요한 최소한의 코드를 제공합니다. 외부 라이브러리에 의존하지 않고 순수 Python으로 작성되어 있으며, 코드의 가독성과 이해를 최우선으로 합니다. 이러한 특성 덕분에 학습용으로 매우 적합하며, 딥러닝 모델의 핵심 개념을 배우고자 하는 개발자들에게 좋은 자료가 될 수 있습니다. TinyGPT는 NanoGPT와 유사하게 최소한의 GPT 구현을 목표로 하지만, Tinygrad처럼 라이브러리를 학습 목적으로 구성하여 코드의 이해도를 높이고자 합니다. PyTorch나 MLX와 같은 고도화된 프레임워크와 비교했을 때, 복잡한 최적화 과정을 배제하여 학습자의 이해를 돕는다는 차별점이 있습니다. 주요 특징 순수 Python 구현: TinyGPT는 외부 의존성 없이 순수 파이썬으로 작성되어 있어, 수정하고 이해하기 쉽습니다. 교육적 초점: 복잡한 최적화보다는 가독성과 이해도를 우선시하여 교육용으로 적합합니다. 모듈형 디자인: 학습과 추론의 각 단계를 처리하는 여러 모듈로 구성되어 있습니다. 프로젝트 구조 TinyGPT의 구조는 다음과 같습니다. 상세한 코드는 TinyGPT GitHub 저장소를 복제(clone)한 뒤 살펴보실 수 있습니다: data/: 데이터셋을 다운로드하고 준비하는 스크립트를 포함하고 있습니다. Shakespeare 데이터셋을 위한 스크립트도 포함되어 있습니다. docs/: 프로젝트에 대한 문서가 포함된 디렉토리입니다. examples/: TinyGPT의 다양한 구성 요소를 활용하는 예제 스크립트 모음으로, 다음과 같은 예제 스크립트가 있습니다: gpt.py: GPT 모델을 학습하고 사용하는 기본 예제 입니다. mnist.py: TinyGPT의 신경망 구성 요소를 사용하여 MNIST 데이터셋을 처리하는 예제입니다. src/: 라이브러리의 주요 기능이 구현된 핵심 디렉토리로 다음과 같은 구성 요소를… [다음 페이지](https://discuss.pytorch.kr/tag/python/89.md?match_all_tags=true&page=1&tags%5B%5D=python)