오늘도 공부

이 글은 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을 함께 활용하는 시대로 넘어오고 있습니다.쉽게 말하면,예전에는..

대부분의 사람들은 AI를 콘텐츠 제작에 이렇게 쓴다.Claude를 연다“생산성에 대한 링크드인 포스트 써줘”라고 입력한다회사 인턴이 쓴 것 같은 평범한 포스트를 받는다로봇처럼 안 들리게 20분 동안 손본다그리고 플랫폼마다 그걸 또 처음부터 반복한다이건 시스템이 아니다.그냥 단계만 더 많은 잡일이다.문제는 AI가 아니다.문제는 네가 AI에게 브랜드, 독자, 말투, 플랫폼 전략, 그리고 이 모든 요소가 어떻게 연결되는지에 대한 맥락을 전혀 주지 않고 있다는 것이다.매번 새 채팅을 시작할 때마다 기억상실에 걸린 천재를 새로 고용하는 셈이다.해결책: 스킬 그래프가 이 문제를 해결한다.신입 직원을 고용한다고 생각해보자.첫날부터 아무 온보딩도 없이, 문서도 없이, 회사가 어떻게 돌아가는지에 대한 맥락도 없이 바로 ..

RAG vs Agentic RAG 정리1. 한 줄 차이RAG사용자의 질문이 들어오면검색 시스템이 관련 문서를 찾아오고그 결과를 LLM에 붙여서 답하게 하는 방식Agentic RAG단순 검색만 하지 않고에이전트가 계획을 세우고, 필요한 도구를 선택하고, 여러 소스를 순차적으로 탐색한 뒤더 능동적으로 답을 만드는 방식2. 기본 RAG 구조이미지 상단의 흐름은 거의 이렇게 보면 됩니다.동작 흐름사용자가 질문 입력서버가 질문을 검색 시스템에 전달Search가 지식 소스에서 관련 정보 가져옴PDFDatabaseDocumentsCodeWeb SearchAPI검색 결과를 서버가 받음서버가 원래 질문 + 검색된 문맥을 합쳐서 LLM에 전달LLM이 최종 답변 생성특징구조가 단순함빠르고 구현이 쉬움질문 1개 → 검색 1번..

AI 코딩 도구를 쓰다 보면, 가장 먼저 부딪히는 문제는 코드 생성 자체가 아닙니다.오히려 “무엇을 어디까지 만들 것인가”를 구조화하지 못한 상태에서 너무 큰 요구사항을 한 번에 던지는 일이 더 큰 문제입니다.예를 들어 “SaaS 플랫폼 하나 만들어줘” 같은 요청은 그럴듯해 보이지만, 실제 구현 단계로 내려가면 인증, 결제, 대시보드, 외부 연동처럼 서로 다른 성격의 하위 문제들이 섞여 있습니다. (GitHub)deep-project는 바로 이 지점을 다룹니다.이 도구는 모호하고 큰 프로젝트 요구사항을 바로 구현하려 하지 않고, 먼저 인터뷰와 분해 과정을 거쳐 “계획 가능한 단위”로 나누는 데 집중합니다. GitHub - piercelamb/deep-project: Claude Code plugin th..

요즘 음성 합성은 더 이상 실험용 기능이 아닙니다. 팟캐스트, 오디오북, 게임 대사, 숏폼 더빙, AI 캐릭터 음성까지 이미 제작 파이프라인의 한 부분이 되었습니다. 문제는 많은 팀이 여전히 클라우드 TTS에 의존하고 있다는 점입니다. 비용은 계속 누적되고, 샘플 음성과 생성 결과가 외부로 오가며, 서비스 제약도 함께 따라옵니다. (GitHub)Voicebox는 이 문제를 다른 방향에서 풀려는 도구입니다. 핵심은 “좋은 음성 합성을 클라우드 API가 아니라 내 장비에서 직접 처리하자”는 접근입니다. 이 글을 끝까지 읽으면 Voicebox가 왜 등장했는지, 기존 방식과 무엇이 다른지, 실제로 어떤 구조로 돌아가며, 어떤 팀에게 유리하고 어디까지는 아직 조심해서 봐야 하는지까지 한 번에 잡을 수 있습니다. ..

터미널 하나를 “작업 공간”으로 바꾸는 가장 실용적인 방법맥으로 개발하다 보면 어느 순간 이런 장면이 반복됩니다.한쪽에서는 서버를 띄우고, 다른 창에서는 로그를 보고, 또 다른 탭에서는 데이터베이스에 붙고, SSH로 원격 서버도 들어가야 합니다. 그런데 맥북을 덮거나 터미널 창을 잘못 닫는 순간 흐름이 끊깁니다.이때 많은 개발자가 결국 정착하는 도구가 tmux입니다. tmux는 하나의 터미널 안에서 여러 프로그램을 실행하고, 작업을 분리했다가 다시 붙을 수 있게 해주는 터미널 멀티플렉서입니다. 공식 위키도 tmux를 “하나의 터미널 안에서 여러 프로그램을 다루고, 분리(detach) 후 다시 재연결(reattach)할 수 있게 해주는 도구”로 설명합니다. (GitHub)이 글에서는 맥 기준으로 tmux가..