아무도 '더 똑똑한 모델'을 원하지 않았다 — 트렌딩 AI 레포 4개로 읽는 개발자의 진짜 수요

이번 달 GitHub 트렌딩에 AI 코딩 관련 레포가 우르르 올라왔다. codegraph(5월 23일 트렌딩 2위, 24시간에 +2,400 스타), Understand-Anything, ECC(16만 스타), pi. 지난 글처럼 네 개를 전부 클론해서 코드를 읽었고, 이번엔 거기에 더해 사람들이 왜 여기에 열광했는지 — 이슈, 토론, HN·Reddit 반응 — 을 따라가 봤다.

흥미로운 게 하나 있었다. 네 개 다 인기를 끈 이유가 “모델이 더 똑똑해져서”가 아니었다. 오히려 codegraph 소개글의 한 줄이 정확했다.

“모델을 더 똑똑하게 만드는 게 아니라, 덜 헤매게 만든다.”

사람들이 원한 건 모델 자체가 아니라 모델 주변이었다. 그리고 그 수요는 세 갈래로 갈렸다 — 덜 헤매게(그라운딩), 한 번만 세팅(재사용), 내가 통제(신뢰). 트렌딩 4개가 정확히 그 세 가지에 하나씩 답하고 있었다.

수요 ① “에이전트가 좀 그만 헤맸으면” — codegraph & Understand-Anything

코딩 에이전트를 써본 사람은 안다. 질문 하나에 에이전트가 한참 grep하고 파일 읽고 import 따라가며 “이 코드가 뭐 하는 곳인지” 파악하는 데 토큰을 태운다. 이걸 discovery phase라 부른다. 토큰당 과금 시대에 이건 그냥 비용이다. codegraph를 써본 한 개발자의 반응이 공감을 샀다.

“딱 이 문제를 겪었다. Explore 에이전트가 공유 심볼 캐시도 없이 같은 파일을 계속 다시 스캔하더라. 에이전트가 grep 하기 전에 참고할 미리 만든 그래프 — 이건 성능이 아니라 진짜 UX 개선이다.”

같은 갈증인데 두 레포가 서로 다른 ‘헤매는 주체’를 겨냥했다.

codegraph — 에이전트가 덜 헤매게

정체. tree-sitter로 코드를 파싱해 함수·클래스·import·호출 관계를 로컬 SQLite 그래프에 넣고, AI 에이전트가 그걸 MCP 서버로 질의한다(codegraph_search·callers·callees·trace·impact 등 10개 도구).

왜 통했나. 효과가 구체적이고 반복 가능했다. VS Code 레포에서 “익스텐션 호스트가 메인 프로세스와 어떻게 통신하나”를 묻자 툴콜이 52번에서 3번으로 줄었다. 7개 실제 코드베이스에서 토큰 ~57%, 툴콜 ~62% 절감(저자 자체 벤치마크라 정확한 퍼센트보다 방향을 보면 된다). 게다가 LLM·임베딩·API 키 없이 100% 로컬 — 코드가 한 줄도 밖으로 안 나간다. tree-sitter가 기계적으로 뽑은 사실이라 환각도 없다.

가장 인상적인 신호는 사람들이 곧바로 더 원했다는 점이다. 이슈에 가장 많이 올라온 요청이 “코드 말고 문서·스펙도 그래프에 넣어달라”였다. 누군가는 며칠 만에 이걸 Kiro용으로 포팅해 “KiroGraph”를 만들었다 — “아이디어가 훌륭해서 그냥 포팅했다.” 수요가 도구를 넘어 “프로젝트 지식 전체의 지도”로 번지고 있다는 뜻이다.

언제 쓰면 좋은가 큰 코드베이스에서 에이전트가 헤매며 토큰을 태우는 게 보일 때. 클로드 코드·Codex·Cursor 어디든 MCP로 꽂고 싶을 때. 코드가 밖으로 나가면 안 되는 사내·보안 환경일 때. 에이전트가 먹는 연료다.

Understand-Anything — 사람이 덜 헤매게

정체. 같은 “코드 → 지식 그래프”지만, 결과물이 사람을 위한 것이다. LLM 멀티에이전트 파이프라인이 프로젝트를 훑고 요약해 아키텍처 레이어로 묶고, 인터랙티브 대시보드로 시각화한다.

왜 통했나. 만든 사람의 슬로건이 사람들의 마음을 정확히 짚었다 — “가르치는 그래프 > 그럴싸한 그래프(Graphs that teach > graphs that impress).” 기존 레포 맵 도구들이 “보기엔 멋지지만 이해엔 도움 안 되는 거대한 그래프”였던 데 대한 반작용이었다. 실제로 가장 사랑받은 건 화려한 의존성 그래프가 아니라 비즈니스 로직 뷰(“코드가 실제 업무 흐름 — 도메인·플로우·단계 — 에 어떻게 매핑되나”)와 보는 사람(주니어/PM/파워유저)에 따라 상세도가 달라지는 페르소나 뷰였다. HN에서 만든 사람이 직접 말했다. “엔지니어들이 비즈니스 지식 모드를 제일 좋아한다.”

여기서도 다음 수요가 선명했다. 토론에서 가장 많이 나온 바람은 “팀이 공유하는, 원격에 저장된 그래프” — 각자 다시 생성하지 말고. 온보딩 도구가 “장기 에이전트 메모리 동반자”로 커지길 원하는 목소리였다.

언제 쓰면 좋은가 낯선 코드베이스에 합류해 사람이 구조를 빨리 이해해야 할 때. 팀 온보딩, 레거시 파악, 비기술 이해관계자에게 시스템을 설명할 때. “README 읽고 질문해”보다 나은 소개가 된다.

둘은 경쟁이 아니라 같은 수요의 양면이다. 그리고 양쪽 다 “다음엔 더 많은 지식을, 팀 단위로”를 외치고 있다. 그라운딩이 일회성 도구에서 공유 자산으로 가고 있다는 신호다.

수요 ② “매번 처음부터 세팅하기 싫다” — ECC

ECC(Everything Claude Code)가 16만 스타를 받은 이유는 스킬 개수가 아니었다. 사람들이 가장 많이 말한 건 “빈 설정 문제”였다. Augment Code의 정리가 정확하다.

“도구들은 설정이 거의 없는 채로 출시된다. 그래서 프로젝트마다 똑같은 훅·가드레일·메모리 세팅을 다시 만들게 된다. CLAUDE.md, Cursor 규칙, MCP 설정을 매번 다시 쓰고, 다음 프로젝트에서 또 반복한다.”

ECC는 그 반복에 대한 배터리 포함(batteries-included) 답이다. 2025년 9월 Anthropic 해커톤 우승 설정에서 출발했고(“8시간 만에 클로드 코드로 만든” 그 설정), MIT 레포 하나에 2분 설치, ./install.sh python 식으로 언어별 규칙까지 깔린다.

왜 통했나 — 사람들이 콕 집은 것들.

• AgentShield 보안 스캐너(1,282 테스트, --opus 레드팀/블루팀/감사 파이프라인) — “MCP 설정이나 CLAUDE.md를 프로덕션에 쓴다면 제일 먼저 평가해볼 기능.”
• Instincts(본능)/메모리 — “코딩 세션에서 패턴을 뽑아 신뢰도로 점수 매기고, 재사용 스킬로 묶는다.” 장기 세션의 컨텍스트 유실에 대한 직접적 답.
• 크로스 하네스 이식성 — “백엔드는 클로드 코드, 프런트는 Cursor를 쓰는 팀에 ECC는 단일 설정 소스가 된다.” 누군가 이걸 “AI 코딩 도구의 .editorconfig”라 불렀고, 그 비유가 퍼졌다.

가장 와닿은 한마디는 이거였다. “6개월 뒤에 내가 직접 만들 걸, 지금 그냥 갖다 쓰는 게 낫다.” 그리고 2.6만 개의 포크 — 이건 구경이 아니라 실제 팀 워크플로에 통합했다는 신호다.

언제 쓰면 좋은가 여러 에이전트를 오가며 설정을 한 벌로 통일하고 싶을 때. 훅·MCP·메모리·보안을 처음부터 짜기 싫고, 잘 차려진 출발점이 필요할 때. 전부 다 쓰기보다 내 워크플로에 맞는 부분을 골라 가져가는 식으로 가장 많이들 쓴다.

ECC가 답한 수요는 결국 “모델을 더 강하게”가 아니라 “에이전트를 프로덕션용으로 설정하기”다. 사람들은 “AI 도구를 한번 써보자”에서 “AI 도구를 운영용으로 세팅하자”로 넘어갔고, ECC는 그 전환의 상징이다.

수요 ③ “내가 뭘 넣는지 보고 통제하고 싶다” — pi

pi는 libGDX·Spine을 만든 Mario Zechner가 만들어 2026년 4월 Earendil에 합류하며 가져온 툴킷이다. 별 개수로 뜬 게 아니라 철학으로 신뢰를 얻었다.

Mario의 핵심 주장은 이렇다. 주류 하네스들은 “UI에 드러나지도 않는 걸 뒤에서 모델 컨텍스트에 집어넣어서” 제대로 된 컨텍스트 엔지니어링을 불가능하게 만든다. pi의 답은 뺄셈을 통한 통제 — 도구는 단 4개(Read·Write·Edit·Bash), 시스템 프롬프트는 1,000토큰 미만. 사람들이 인용하는 그의 문장.

“내가 필요 없으면, 만들지 않는다. 그리고 나는 필요 없는 게 많다.” “모델 컨텍스트에 들어가는 걸 정확히 통제하면 더 나은 출력이 나온다.”

왜 통했나. 신뢰의 증거가 쌓여 있었다. Armin Ronacher(Flask 창시자)가 공개적으로 인정했다 — “pi는 훌륭한 소프트웨어처럼 짜여 있다. 깜빡거리지 않고, 메모리를 많이 먹지 않고, 멋대로 깨지지 않는다. 나는 거의 pi만 쓴다.” HN에선 Mario의 깊이(“몇 년 만에 한 시간씩 붙들고 읽은 블로그”)와 이력이 즉각적인 신뢰가 됐다. 그리고 벤더 락인 거부가 명확하다 — pi-ai는 Anthropic·OpenAI·Google·Bedrock·Mistral 등 여러 제공자를 한 인터페이스로 묶고, 의존성은 정확 버전으로 핀, --ignore-scripts 설치, shrinkwrap까지. 과거 RoboVM이 인수 후 망가진 상처를 겪은 그가 *“pi는 MIT다. 앞으로도 MIT다. 포크 버튼은 늘 작동한다”*고 못 박은 게 사람들의 신뢰를 샀다.

흥미로운 신호 하나 — pi는 한때 일주일에 10만 스타가 치솟은 OpenClaw의 숨은 엔진이었다. 많은 사람이 OpenClaw를 통해 pi를 발견했다.

언제 쓰면 좋은가 에이전트를 직접 만들 때. 여러 LLM을 갈아 끼우는 앱, 자체 코딩 에이전트/TUI를 올릴 때. 무엇보다 “모델에 뭐가 들어가는지 정확히 알고 통제하고 싶은” 사람에게. 공급망 보안이 중요한 조직엔 핀·shrinkwrap 설정이 그대로 참고서가 된다.

세 수요를 관통하는 한 줄

네 개를 코드까지 읽고, 사람들의 반응을 따라가니 같은 문장이 세 번 다른 얼굴로 나타났다.

• codegraph·Understand-Anything → “모델을 똑똑하게 말고, 덜 헤매게.” (그라운딩)
• ECC → “매번 다시 만들지 말고, 한 번 세팅해서 재사용.” (재사용)
• pi → “뒤에서 뭘 넣는지 모르겠으니, 내가 보고 통제.” (신뢰)

2026년의 개발자들은 더 강한 모델을 달라고 하지 않았다. 모델은 이미 충분히 강하다. 사람들이 진짜 원한 건 그 강한 모델을 길들이는 법 — 무엇을 먹이고(그라운딩), 어떻게 세팅을 물려주고(재사용), 안에 뭐가 들어가는지 어떻게 들여다볼지(신뢰)였다. 프런티어가 모델에서 모델 주변으로 옮겨갔다는 가장 솔직한 증거다.

그래서 다음은 어디로 가는가

수요가 가리키는 방향은 꽤 분명하다.

① 그라운딩은 “공유 자산”이 되고, 결국 플랫폼에 흡수된다. codegraph 사용자들이 곧바로 “문서·스펙도 넣어달라”, Understand-Anything 사용자들이 “팀이 공유하는 그래프”를 원한 게 핵심이다. 코드 지도는 일회성 도구를 넘어 팀이 공유하는 프로젝트 지식 레이어로 가고 있다. “에이전트가 코드베이스를 더듬는다”는 문제가 너무 보편적이라, 이 기능은 머잖아 에이전트·플랫폼이 기본 내장하거나 MCP 표준으로 빨려 들어갈 가능성이 높다.

② “에이전트 설정”이 표준화된다 — .editorconfig의 순간. ECC가 16만 스타를 받은 건 빈 설정 문제가 그만큼 보편적이라는 뜻이다. 지금은 ECC 같은 거대 번들이 그 갈증을 채우지만, .editorconfig·.prettierrc가 그랬듯 에이전트 설정도 결국 가볍고 표준화된 포맷으로 수렴할 것이다. 사람들이 원한 건 “250개 스킬”이 아니라 “내 설정을 한 번 정의해서 모든 도구·프로젝트에 물려주는 법”이었으니까.

③ 통제·투명성이 신뢰의 기준이 된다. 에이전트가 더 자율적으로, 더 많은 코드를 실행할수록 사람들은 *“이게 안에서 뭘 하는지 보이는가”*를 묻기 시작한다. pi가 미니멀·투명·포크 가능으로 신뢰를 산 게 우연이 아니다. 다음 세대 도구의 차별점은 “기능 개수”가 아니라 “내가 이해하고 통제할 수 있는가”가 될 것이다.

마치며

처음엔 “코드를 까서 뭐가 부실한지” 보려 했다. 그런데 사람들이 왜 열광했는지를 따라가 보니, 더 흥미로운 그림이 나왔다. 이 네 개는 결함 목록이 아니라 수요의 지도였다.

블로그 #14에서 에이전트 엔지니어가 진짜 설계하는 건 모델 바깥의 레이어라고 썼다. 이번 트렌딩이 그걸 사용자 쪽에서 똑같이 증명한다. 모델 경쟁은 어느 정도 평준화됐고, 이제 사람들은 그 모델을 길들이는 도구에 별을 준다.

다음 주 트렌딩을 또 보게 될 것이다. 그때 던질 질문은 이거다.

이건 모델을 더 똑똑하게 만드는가, 아니면 우리가 모델을 더 잘 다루게 만드는가? — 요즘 사람들이 별을 주는 쪽은 후자다.

참고 자료

• codegraph (colbymchenry) — MCP-native 코드 지식 그래프
• Understand-Anything (Lum1104) — 코드→인터랙티브 지식 그래프
• ECC / Everything Claude Code (affaan-m) — 멀티 하네스 설정 레이어
• pi (earendil-works) — 에이전트 개발 툴킷
• Mario Zechner — Pi Coding Agent · Armin Ronacher — pi
• 관련 글: Hermes vs OpenClaw — 같은 꿈, 다른 설계 · 에이전트 엔지니어가 진짜 설계하는 것