신규하 블로그

개발 기록 보관소

Claude Code가 아쉬울 때 붙여볼 7가지 오픈소스: 기억, 워크플로, 팀 운영, 문서화

Developer Tools
Claude Code를 계속 쓰다 보면 어느 순간 비슷한 지점에서 막힙니다. 세션이 끊기면 맥락이 날아가고, 워크플로가 느슨하면 결과가 들쭉날쭉해지고, 여러 에이전트를 굴리기 시작하면 누가 뭘 하는지 추적하기 어려워집니다. 문서가 섞인 프로젝트에서는 입력 정리부터 번거롭고, 자율 에이전트 쪽으로 가면 또 다른 레이어가 필요해집니다. 이번 Threads 포스트가 흥미로운 이유는, 이런 “Claude Code 단독 사용의 빈칸”을 메워 주는 오픈소스 7개를 한 번에 묶어 보여 주기 때문입니다. Threads 원문 더보기

Plane이 흥미로운 이유: Jira 대체를 넘어 셀프호스팅 가능한 프로젝트 관리 플랫폼

Developer Tools
프로젝트 관리 도구 이야기를 할 때 우리는 보통 Jira냐, Linear냐, ClickUp이냐 같은 SaaS 선택지 안에서만 고민합니다. 그런데 Plane 은 질문 자체를 바꿉니다. “어떤 SaaS를 구독할까?”가 아니라, 프로젝트 관리 도구를 우리 팀 인프라 안에 두고 운영할 수는 없을까? 를 묻는 프로젝트입니다. 이번 Threads 포스트가 흥미로운 이유도 바로 그 지점입니다. Jira 대체 정도가 아니라, Linear, Monday, ClickUp까지 통째로 겨냥하는 오픈소스라는 점이 강조됩니다. Threads 원문 더보기

Claude Code를 무료처럼 쓰는 법: Ollama로 로컬·클라우드 모델을 붙이는 구조

Developer Tools
Claude Code is now FREE 라는 제목은 눈길을 끌지만, 정확히 말하면 Claude Code 자체가 갑자기 무료 서비스가 됐다는 뜻은 아닙니다. 이 영상이 보여 주는 건 Claude Code라는 인터페이스와 워크플로를 유지한 채, 실제 모델 백엔드를 Ollama의 로컬 모델이나 무료 클라우드 모델로 바꾸는 방법 입니다. 즉 “Claude 모델을 공짜로 쓴다”보다, “Claude Code 클라이언트를 다른 모델에 연결한다”에 더 가깝습니다. YouTube 영상 더보기

Graphify의 71.5배 절감은 어떻게 읽어야 할까: 벤치마크보다 중요한 실전 이득

Developer Tools
Graphify를 처음 보면 가장 눈에 띄는 숫자는 71.5x fewer tokens 입니다. 이 정도면 거의 판을 바꾸는 수치처럼 들립니다. 그런데 이 영상의 좋은 점은 그 숫자를 그대로 홍보하지 않는다는 데 있습니다. 실제 Claude Code 세션 두 개를 나란히 비교해 보니, 토큰 절감은 7~8% 수준에 가까웠고 대신 답변 품질이 더 나아졌다는 식으로 설명합니다. 즉 Graphify의 진짜 가치는 “무조건 71배 절감”이 아니라, Claude가 매 세션마다 프로젝트를 처음부터 다시 읽는 낭비를 줄이고, 첫 답변부터 더 좋은 방향으로 읽게 만드는 것 에 있습니다. YouTube 영상 더보기

AI 1인 게임 개발에서 진짜 중요한 건 재미보다 완성이다

Developer Tools
AI가 발전하면서 “이제 혼자서도 게임 하나쯤은 금방 만들 수 있겠다”는 기대가 커졌습니다. 실제로 초반 구현 속도만 보면 이 말은 꽤 맞습니다. 프로토타입은 빨리 나오고, 예전 같으면 며칠 걸릴 UI나 시스템 코드도 몇 시간 만에 형태를 잡을 수 있습니다. 그런데 이 영상은 그 다음 장면을 정확히 짚습니다. AI는 1인 게임 개발의 초반 7090%를 엄청 빠르게 밀어주지만, 마지막 1020%를 대신해 주지는 못한다 는 것입니다. YouTube 영상 더보기

LightRAG를 다시 볼 이유: 듀얼 레벨 검색, 그래프 결합, 그리고 서버 제품화

Developer Tools
LightRAG는 이제 단순히 “Graph RAG 오픈소스 하나”로 보기 어려운 프로젝트가 됐습니다. 출발은 Simple and Fast Retrieval-Augmented Generation 이었지만, 현재 저장소를 보면 Web UI, API 서버, 여러 스토리지 백엔드, reranker, citation, tracing, evaluation, 멀티모달 연동까지 붙으면서 사실상 하나의 RAG 플랫폼처럼 진화하고 있습니다. GitHub 저장소 더보기

TurboQuant를 RAG에 가져오면 무엇이 달라지나: 31GB 인덱스를 4GB로 줄이는 방식

Developer Tools
RAG를 실제로 오래 굴려 본 사람이라면, 문제는 모델보다도 벡터 저장소에서 먼저 터지는 경우가 많다는 걸 압니다. 문서 수가 커질수록 임베딩 저장 공간이 커지고, 인덱싱 과정도 무거워지며, 온프레미스 환경에서는 메모리 예산이 곧 설계 제약이 됩니다. 이번 Threads 포스트가 흥미로운 이유는 바로 그 지점을 찌르기 때문입니다. Google Research의 TurboQuant 알고리즘을 RAG 쪽으로 가져온 pyturboquant가 공개됐고, 1,000만 chunk 규모에서 기존 float32 기준 약 31GB가 필요하던 인덱스를 약 4GB 수준으로 줄일 수 있다고 소개합니다. Threads 원문 더보기