오늘도 공부

이 저장소는 완성형 프레임워크를 바로 쓰게 하는 대신, 가장 단순한 채팅 루프에서 출발해 도구 호출, 스킬, 세션 저장, 컨텍스트 압축, 이벤트 버스, 멀티 에이전트, 장기 메모리까지 직접 조립해 보게 만드는 튜토리얼형 프로젝트입니다. (GitHub)요즘 AI 에이전트를 다룰 때 가장 답답한 지점은 “잘 돌아가는 데 왜 그렇게 설계됐는지”가 보이지 않는다는 점입니다. 프레임워크는 빠르게 결과를 내주지만, 구조를 이해하지 못하면 비용이 왜 늘었는지, 컨텍스트가 왜 깨졌는지, 왜 특정 상황에서만 불안정한지 판단하기 어렵습니다. 이 저장소는 그 불투명한 중간층을 단계별 코드로 드러냅니다. (GitHub)이 글을 끝까지 읽으면 세 가지가 명확해집니다.첫째, 에이전트가 단순한 LLM 호출이 아니라 세션, 이벤트,..

이 글은 GEOFlow를 이해하기 위해 작성되었습니다.단순히 AI로 글을 생성하는 도구로 보면 이 프로젝트의 핵심을 놓치기 쉽습니다. GEOFlow는 글 생성 자체보다, 콘텐츠 운영의 전체 흐름을 하나의 시스템으로 묶는 것에 더 가깝습니다. 모델 설정, 소재 관리, 작업 실행, 검토, 게시까지를 끊기지 않게 연결하려는 시도입니다. (GitHub)기존의 AI 콘텐츠 운영은 보통 여러 도구에 흩어져 있습니다. 프롬프트는 문서에 따로 저장하고, 제목은 스프레드시트로 관리하고, 생성은 별도 스크립트로 돌리고, 결과는 CMS에 다시 붙여 넣습니다. 이런 구조는 처음에는 빨라 보여도, 작업량이 늘어나면 관리 비용이 급격히 커집니다. GEOFlow는 바로 그 지점을 겨냥합니다. (GitHub)이 글을 끝까지 읽으면 ..

최근 AI 코딩 에이전트는 빠르게 늘어났지만, 실무에서 써보면 금방 한계가 드러납니다. 로컬에서 터미널을 켜 두고 지켜봐야 하고, 중간에 끊기면 다시 상태를 맞춰야 하며, 긴 작업은 요청-응답 수명 안에 가두기 어렵기 때문입니다. (GitHub)Open Agents는 이 문제를 “에이전트를 오래 실행되게 만드는 방법”의 관점에서 다시 설계한 프로젝트입니다. 웹 UI, 워크플로우 기반의 에이전트 실행, 샌드박스 VM, 그리고 GitHub 연동을 한 구조로 묶어, 프롬프트에서 코드 변경과 푸시, PR 생성까지 이어지는 흐름을 만들었습니다. (GitHub)이 글을 끝까지 읽으면 세 가지가 분명해집니다. 왜 기존 AI 코딩 에이전트가 실무에서 피로했는지, Open Agents가 그 문제를 어떤 아키텍처로 풀었는..

이 글은 ralph-orchestrator가 왜 등장했고, 자율 AI 에이전트 워크플로우를 어떻게 더 안정적으로 만들려는지 이해하기 위해 작성되었습니다. 단순히 “에이전트를 계속 돌리는 도구”로 보면 이 프로젝트의 핵심을 놓치게 됩니다. 이 도구가 겨냥하는 문제는 기능 부족이 아니라, 에이전트가 똑똑할수록 오히려 전체 흐름은 더 불안정해질 수 있다는 점입니다. (GitHub)기존 자율 에이전트 방식은 보통 하나의 강한 프롬프트에 많은 책임을 몰아넣습니다. 계획도 세우고, 코드도 짜고, 테스트도 돌리고, 실패 원인도 스스로 해석하게 만듭니다. 처음엔 단순해 보이지만, 작업이 길어질수록 컨텍스트가 비대해지고, 실패 원인이 흐려지고, “됐다고 했는데 실제로는 안 된 상태”가 자주 생깁니다. ralph-orch..

정적인 PSD나 PNG를 가져와서, 복잡한 리깅 작업 없이 빠르게 2D 캐릭터 애니메이션으로 바꾸는 흐름을 설명합니다. 특히 이 도구가 단순한 편집기가 아니라, 레이어 분해된 캐릭터를 실제 애니메이션 파이프라인으로 연결하는 데 초점을 둔 이유를 다룹니다. (GitHub)기존 2D 캐릭터 애니메이션 도구는 크게 두 가지 불편이 있었습니다. 하나는 본 세팅과 파라미터 설계가 무겁다는 점이고, 다른 하나는 AI가 분해해 준 레이어를 실제 애니메이션 가능한 구조로 옮기는 과정이 생각보다 수작업 중심이라는 점입니다. Stretchy Studio는 이 사이를 메우기 위해, 타임라인 중심 편집과 메쉬 변형을 결합하는 방향으로 설계되었습니다. (GitHub)이 글을 끝까지 읽으면 세 가지가 잡힙니다. 왜 이 도구가 기..

“원래는 안 될 것 같은데, 요즘은 됩니다”의 진짜 이유처음 들으면 이상합니다.“27B, 70B, 100B, 심지어 200B가 넘는 모델을고작 16GB VRAM GPU로 돌릴 수 있다.”상식적으로는 말이 안 되는 이야기처럼 보입니다.보통 대형 모델은 모델 전체가 GPU 메모리(VRAM)에 올라가야 실행된다고 알려져 있기 때문입니다.그래서 많은 분들이 이렇게 생각합니다.“아니, 100GB가 넘는 모델이면당연히 VRAM도 그 정도는 있어야 하는 거 아닌가?”네, 최고 속도로 돌리려면 그 말이 맞습니다.하지만 요즘은 꼭 그렇게만 돌리지 않습니다.최근 추론 엔진과 양자화 기술이 발전하면서, 이제는 GPU 메모리만으로 버티는 시대에서 GPU + RAM을 함께 활용하는 시대로 넘어오고 있습니다.쉽게 말하면,예전에는..