'AI를 붙였더니 더 좋아졌다'는 말이 자동으로 참이 되는 시대는 이미 지났습니다. AI 기능이 도구에 통합되는 속도는 빨라졌지만, 그 통합이 실제 개발자 경험을 개선하는지는 별개의 질문입니다. 최근 세 가지 사례—GitHub의 성능 붕괴, Claude Code 슬래시 커맨드 자동화, CodeGraph MCP 비용 실측—는 같은 질문 앞에 서 있습니다. AI를 어떻게 설계하느냐가 DX를 만들기도 하고 무너뜨리기도 한다는 것.
AI 기능을 밀어 넣은 결과: GitHub의 경우
GitHub가 요즘 느리다는 느낌, 착각이 아닙니다. 한 독립 벤치마크(eblog.fly.dev)는 빈 저장소 하나를 로드하는 데 GitHub가 291개 요청, 15MiB 압축 응답, 544,564줄의 코드와 데이터를 내려받는다는 사실을 측정했습니다. 같은 실험에서 Codeberg는 11개 요청, 1MiB로 끝냈습니다. 정상 상태 힙 사용량도 GitHub는 69MiB, rust-lang의 pull request 페이지는 무려 148MiB에 달했습니다. 텍스트 링크 몇 개가 전부인 페이지가 초창기 iPhone 전체 메모리보다 많은 RAM을 씁니다.
PageSpeed 모바일 기준으로 GitHub는 LCP 2.1초, INP 242ms로 FAIL 판정을 받았고, Codeberg는 LCP 1.3초, INP 86ms로 PASS를 받았습니다. Core Web Vitals 기준에서 GitHub는 이미 낙제점입니다. 문제의 뿌리는 명확합니다. GitHub changelog를 보면 "availability first"를 선언한 이후 30일 동안 'copilot'이 59회, 'agent'가 8회 등장하는 반면 'performance'와 'reliability'는 0회입니다. changelog 필터에 copilot 카테고리는 있지만 performance 카테고리는 없습니다. 우선순위가 어디에 있는지 숫자가 말해줍니다.
프로덕트 관점에서 보면 이건 단순한 기술 부채가 아닙니다. Microsoft가 Copilot과 agent 기능을 GitHub 거의 모든 페이지에 밀어 넣고, 그 사용을 비용 보조로 유도한 결과 플랫폼이 스스로에게 분산 서비스 거부 공격을 가한 셈이 됐습니다. AI 기능 통합이 사용자 문제를 해결하기 위한 설계가 아니라, 채택률 지표를 올리기 위한 결정으로 진행될 때 무슨 일이 생기는지를 보여주는 실물 사례입니다.
좁고 명확하게 설계한 AI 자동화: Claude Code 슬래시 커맨드
반대편에는 솔로 스튜디오 운영자가 만든 다섯 개의 Claude Code 슬래시 커맨드가 있습니다(dev.to). 이 커맨드들이 흥미로운 건 기능의 화려함이 아니라 설계 원칙 때문입니다. 하나의 커맨드는 하나의 일만 합니다. 입력은 최대한 좁게 가져갑니다. 실패는 크고 명확하게 알립니다.
/publish는 초안 마크다운을 받아 단어 수 확인, 이미지 업로드, 포스팅까지 처리하고 완료되면 라이브 URL을 출력합니다. 이전에는 40줄짜리 셸 스크립트와 6단계 수동 작업이었고, 토큰 만료 에러는 200줄 curl 출력 어딘가에 묻혀 있었습니다. /qa는 퍼블리시 전에 링크 유효성, 단어 수, 금지 단어, 제목 구조를 검사하는 산문 린터입니다. 첫 주에만 4개 아티클에서 11개 이슈를 잡았고, 그중에는 같은 핸들에 다른 앵커 텍스트를 쓴 링크처럼 눈으로는 잡기 어려운 것들도 있었습니다.
이 사례에서 가장 인상적인 설계 교훈은 'QA 도구가 모든 것을 블락하면 하루 만에 꺼진다'는 부분입니다. 초기에 모든 스타일 이슈를 hard fail로 설정했더니 아무것도 배포할 수 없었습니다. 결국 실제로 품질을 훼손하는 것—깨진 링크, 범위 밖 단어 수, 금지 용어—만 hard fail로 남기고 나머지는 경고로 낮췄습니다. 이 구분이 도구를 실제로 사용하게 만드는 핵심입니다. 좁은 입력, 단일 책임, 명확한 실패—이 세 원칙이 200줄의 불안정한 글루 코드와 매 아티클당 30분의 수동 검수를 대체했습니다.
숫자는 절반만 말한다: CodeGraph MCP 비용 실측
CodeGraph는 tree-sitter + SQLite/FTS5 + MCP로 구성된 코드 검색 도구로, 팀이 자체 공개한 벤치마크에서 비용 35% 절감, 토큰 57% 감소, tool call 71% 감소를 주장했습니다. 한 독립 개발자(dev.to)가 팀의 벤치마크 7개 저장소에 포함되지 않은 Hono(TypeScript, 약 280개 소스 파일)로 40회 실험을 돌렸습니다.
결과는 절반은 재현되고, 절반은 재현되지 않았습니다. Tool call 감소는 -55%(14.0→6.3 평균)로 강하게 재현됐고, 레이턴시도 -20% 개선됐습니다. 그런데 비용은 +6.8%로 오히려 소폭 증가했습니다. 왜 이런 분리가 생겼을까요? CodeGraph는 여러 번의 grep+Read 왕복을 한두 번의 구조적 조회로 대체합니다. 그런데 각 codegraph_context 호출이 반환하는 그래프 컨텍스트 덩어리가 대화 캐시에 실려 매 턴마다 다시 읽힙니다. Hono 정도 크기에서는 이 캐시 페이로드 비용이 절약된 grep 비용과 맞먹어서 달러 기준으로는 본전입니다.
이 실험이 보여주는 건 더 중요한 지점입니다. 설계자가 선택한 저장소로 만든 벤치마크는 designer bias를 피하기 어렵습니다. 실제 운영 환경에서는 저장소 크기, 질문의 형태, 에이전트 동작 방식에 따라 같은 도구가 전혀 다른 비용 곡선을 그립니다. 더불어 이 실험에서 연구자는 MCP 서버가 실제로 연결됐는지 검증하지 않으면 벤치마크 자체가 noise가 된다는 걸 직접 경험했습니다. 첫 패스에서 --mcp 플래그 누락으로 모든 'CodeGraph' 실행이 실은 그냥 grep+Read였고, 숫자는 그럴듯해 보였습니다. 도구가 작동하고 있는지 확인하는 것 자체가 설계의 일부입니다.
세 사례가 가리키는 같은 방향
세 사례는 서로 다른 맥락에서 하나의 원칙을 반복합니다. AI 기능을 얼마나 많이 통합했느냐가 아니라, 어떤 문제를 해결하기 위해 어떤 범위로 설계했느냐가 실제 DX를 결정합니다. GitHub는 AI 버튼을 페이지마다 3~4개씩 올리는 동안 빈 저장소 로드에 22초를 쓰는 도구가 됐습니다. Claude Code 슬래시 커맨드는 '하나의 커맨드, 하나의 일'이라는 좁은 설계로 수동 작업을 실질적으로 제거했습니다. CodeGraph는 tool call을 반으로 줄이지만 비용은 저장소 크기와 질문 형태에 따라 다르게 나타납니다—벤치마크 숫자 하나로 판단하면 절반만 보는 겁니다.
프론트엔드 개발자로서 이 지점이 중요하게 느껴지는 이유는, 우리가 가장 먼저 '이 경험이 사용자에게 진짜 도움이 되는가'를 물어야 하는 위치에 있기 때문입니다. AI 도구를 워크플로우에 통합할 때도 같은 질문이 선행되어야 합니다. 어떤 문제를 해결하는가. 성공을 어떻게 측정하는가. 실패했을 때 어떻게 알 수 있는가. 이 세 질문에 답하지 않고 도구를 붙이는 것은 GitHub가 하고 있는 일과 다르지 않습니다. 설계 없는 통합은 기능이 아니라 부채를 만듭니다.