신규하 블로그

개발 기록 보관소

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 원문 더보기

정말 데이터베이스가 필요할까: JSONL 파일, 메모리 맵, SQLite로 다시 보는 저장 전략

Developer Tools
백엔드 프로젝트를 시작할 때 우리는 거의 반사적으로 데이터베이스부터 고릅니다. PostgreSQL을 붙일지, MySQL을 쓸지, 아니면 SQLite로 시작할지를 고민합니다. 그런데 DB Pro Blog의 이 글은 출발점을 아예 바꿉니다. “정말 데이터베이스가 필요한가?”가 아니라, 어차피 데이터베이스도 결국 파일인데 왜 처음부터 꼭 데이터베이스의 파일을 써야 하느냐 는 질문을 던집니다. 원문 더보기

Graphify는 왜 토큰을 71.5배 아끼나: 지식 그래프로 코드베이스를 먼저 읽는 방식

Developer Tools
LLM에게 큰 코드베이스나 방대한 문서 폴더를 그대로 읽게 하면, 대부분의 비용은 “찾아다니는 데”서 발생합니다. 관련 없는 파일까지 훑고, 다시 grep 하고, 또 읽고, 요약하면서 토큰을 계속 소모합니다. Graphify 는 이 문제를 정면으로 겨냥합니다. 먼저 폴더를 한 번 구조화된 지식 그래프로 바꿔 두고, 이후에는 원문 전체가 아니라 그래프를 중심으로 탐색하게 만드는 방식입니다. YouTube 영상 GitHub 저장소 더보기

GStack의 planning pipeline이 개발 시간을 아끼는 이유: 코딩 전부터 scope를 줄이는 법

Developer Tools
AI 코딩 도구를 쓰다 보면 보통 관심은 구현 속도에 쏠립니다. 얼마나 빨리 코드를 쓰는지, 테스트를 얼마나 자동화하는지, QA를 얼마나 대신해 주는지 같은 부분입니다. 그런데 이 영상은 GStack에서 진짜 사람들이 과소평가하는 부분이 planning workflow 라고 말합니다. 요지는 간단합니다. 코딩 전에 문제 정의와 범위를 제대로 줄이면, 뒤에서 고칠 일을 몇 주 단위로 줄일 수 있다 는 것입니다. YouTube 영상 더보기

AI 에이전트에 역할을 너무 많이 주면 왜 망가질까: PO + Reviewer 구조로 다시 보기

Developer Tools
AI 에이전트를 팀처럼 꾸미는 방식은 꽤 그럴듯해 보입니다. CEO 에이전트가 방향을 잡고, 기획자 에이전트가 플랜을 짜고, 디자이너 에이전트가 UI를 보고, 개발자 에이전트가 코드를 만들고, QA 에이전트가 검수하는 식입니다. 그런데 이 영상은 그 구조가 오히려 AI를 가장 못 쓰는 방법일 수 있다고 말합니다. 핵심 논지는 단순합니다. 인간 조직도는 인간의 한계를 해결하기 위해 생겼지만, AI는 같은 이유로 역할을 나눌 필요가 없다는 것 입니다. YouTube 영상 더보기