오늘도 공부

AI를 검색 도구로만 쓰지 말고, 지식이 쌓이는 시스템으로 바꾸는 법솔직히 많은 사람이 아직도 AI를 “똑똑한 검색창”처럼 씁니다.질문 하나 던지고, 답을 받고, 창을 닫습니다.그다음 비슷한 주제가 나오면 또 처음부터 묻습니다.그러면 AI는 다시 자료를 뒤지고, 다시 요약하고, 다시 설명합니다.문제는 이 과정에서 지식이 축적되지 않는다는 것입니다.대화는 끝나면 흩어지고, 생각은 파일로 남지 않고, 연결은 형성되지 않습니다.최근 안드레이 카파시가 공개한 LLM Wiki는 바로 이 문제를 겨냥한 패턴입니다. 이 문서는 특정 앱 소개가 아니라, LLM 에이전트에게 그대로 넘겨서 자기만의 지식 시스템을 만들 수 있게 설계된 “아이디어 파일”에 가깝습니다. (Gist)https://gist.github.com/k..

AI 코딩 에이전트가 넘쳐나는 시대다. 그런데 막상 “에이전트가 내부적으로 어떻게 돌아가는가?”를 이해하려고 코드를 열어보면, 프레임워크 계층과 추상화가 너무 두꺼워 금방 길을 잃는다. mini-coding-agent는 그 반대편에 서 있다. 기능을 과시하기보다, 코딩 에이전트의 뼈대를 눈으로 따라갈 수 있게 만든다. 저장소 설명 그대로 이 프로젝트는 “코딩 에이전트의 핵심 구성요소를 설명하기 위한 최소한의 읽기 쉬운 구현”을 목표로 한다. (GitHub)무엇보다 흥미로운 지점은 이 프로젝트가 “새로운 에이전트 프레임워크”를 내세우지 않는다는 점이다. 대신 로컬 모델 서버인 Ollama를 백엔드로 붙이고, 단일 Python 파일 중심으로 에이전트 루프를 구현해 둔다. 설치 요구사항도 Python 3.10..

Field Theory CLI로 X 북마크를 로컬 DB와 LLM 검색 레이어로 만드는 방법북마크는 저장해둘 때는 분명히 유용해 보인다. 그런데 막상 “예전에 저장해둔 그 글”을 찾으려는 순간, 저장 기능은 기억 보조 장치가 아니라 정보 무덤이 된다.특히 X의 북마크나 Threads의 저장 기능은 모아두기에는 좋지만, 다시 꺼내 쓰기에는 불편하다. 검색은 약하고, 분류는 없고, LLM에 붙여서 내 지식 베이스처럼 다루기도 어렵다. 그래서 결국 개발자는 한 번쯤 이런 생각을 하게 된다.“그냥 내가 로컬에 다 저장하고, 인덱싱해서, SQL로 조회하고, 필요하면 LLM이 읽게 만들면 되지 않을까?”Field Theory CLI는 바로 그 생각을 꽤 현실적인 형태로 구현한 프로젝트다. 그리고 여기서 더 흥미로운 ..

이제는 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가 팀의 개발 프로세스를 따라오게 만드는 법”에 가깝다. ..