오늘도 공부

AI 코딩 도구는 점점 똑똑해지고 있습니다. 그런데 막상 실무에서 써보면, “코드를 읽는 것”과 “코드베이스를 이해하는 것”은 전혀 다른 문제라는 걸 금방 깨닫게 됩니다. 파일 몇 개를 요약하는 건 잘해도, 어떤 함수가 어디서 호출되고, 변경이 어디까지 전파되며, 실제 실행 흐름이 어떻게 이어지는지는 놓치기 쉽습니다. GitNexus는 바로 그 간극을 파고든 프로젝트입니다. 서버를 따로 띄우지 않고, 브라우저나 로컬 환경에서 코드베이스를 지식 그래프로 바꿔서 탐색하게 만듭니다. 이 프로젝트가 흥미로운 이유는 단순한 “코드 검색기”가 아니라, AI가 코드를 더 안전하게 다루기 위한 구조적 컨텍스트 레이어를 만들고 있기 때문입니다. (GitHub) GitHub - abhigyanpatwari/GitNexus..

AI 에이전트 시대가 열리면서, 이제 경쟁력은 “얼마나 많은 Tool을 붙였는가”보다 “그 Tool 호출을 사용자가 얼마나 이해할 수 있는가”로 이동하고 있습니다.많은 AI 제품이 Tool 호출 결과를 아직도 텍스트 로그나 JSON 덩어리로 보여줍니다. 모델은 이해할지 몰라도, 사람은 한 번 더 해석해야 합니다. assistant-ui/tool-ui는 바로 이 지점을 정면으로 겨냥합니다. 툴 실행 결과를 승인 카드, 옵션 선택 UI, 차트, 테이블, 터미널, 링크 프리뷰 같은 실제 인터페이스로 바꿔서, AI가 한 일을 사람이 즉시 이해하고 바로 반응할 수 있게 만듭니다. (GitHub)이 프로젝트를 한 문장으로 요약하면 이렇습니다.“AI의 Tool 호출 결과를, 인간 친화적인 UI 컴포넌트로 렌더링하는 ..

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

AI 코딩 에이전트가 좋아졌다고 해서, 바로 팀으로 일도 잘하는 것은 아닙니다.오히려 실무에서는 더 어려운 문제가 남습니다.“어떤 역할로 에이전트를 나눌지”, “어떤 순서로 협업시킬지”, “각 에이전트에게 어떤 스킬을 줘야 할지”, “정말 이 구성이 성능을 높였는지 어떻게 검증할지” 같은 문제입니다. Harness는 바로 이 지점에 들어옵니다. 이 프로젝트는 새로운 에이전트 런타임을 만드는 도구가 아니라, 도메인별 에이전트 팀과 스킬을 설계·생성하는 메타 스킬로 설계되어 있습니다. Claude Code 안에서 “이 프로젝트용 하네스를 만들어줘”라고 말하면, .claude/agents/와 .claude/skills/ 구조를 자동으로 만들어 주는 식입니다. (GitHub) GitHub - revfactor..