Load-Bearing - Analyzes Claude's vocabulary in GitHub PRs
Show HN: The load-bearing vocabulary of Claude
Load-Bearing는 GitHub의 100개 Pull Request를 매일 스크래핑하여 코딩 에이전트, 특히 Claude의 어휘 사용 추세를 분석합니다. 2025년 이후 47,464개의 PR과 5백만 개 이상의 단어를 KL-divergence k-means 클러스터링으로 8개의 어휘 그룹으로 분류했습니다. 그중 하나는 2026년에 나타나 지난달 인간이 작성한 PR의 45%를 차지했으며, 'load-bearing'과 같은 대표 단어는 코딩 에이전트 사용자에게 익숙할 것입니다. 이 도구는 에이전트가 코드베이스에 어떤 언어적 흔적을 남기는지 이해하는 데 도움을 줍니다.
이 도구는 코딩 에이전트가 코드베이스에 남기는 언어적 지문을 보여줍니다. 'load-bearing'이라는 단어가 이 구성 요소에서 123배 더 자주 등장한다는 사실은 에이전트가 코드의 핵심 구조를 어떻게 바라보는지 드러냅니다.
HN 토론
316- nater5000
스크롤을 내리려고 했는데 작가가 제시하고 싶은 모든 내용이 화면에 다 들어맞는 걸 보고 기분 좋게 놀랐다. 이 사이트가 지나치게 장황하거나 복잡하지 않으면서도(LLM이 하기 어려워하는 것) 이렇게 명확하고 설득력 있는 프레젠테이션을 할 수 있다는 게 거의 아이러니하다. 제시된 내용을 너무 깊이 파고들지는 않겠지만, 작가는 자신의 편견을 프레젠테이션에 주입하지 않은 점이 잘했고 그게 잘 먹혔다.
앞으로 나아갈수록 인간은 점차 LLM의 언어를, 적어도 LLM과 상호작용하면서 생기는 특정 언어적 특성을 채택하기 시작할 것 같다. 내 글에서도 이제 예시 목록을 일관된 방식으로 제시한다는 걸 알아차렸다: "... 예를 들어 <예시 1>, <예시 2> 등, ..." 같은 식으로. 최근에 이 패턴을 꽤 많이 쓰고 있다는 걸 알게 됐는데, 소셜 미디어 게시물을 잠깐 훑어보니 꽤 오래전부터 그랬던 것 같다. 특히 초기에 LLM이 내가 제공한 특정 예시에 너무 집중해서, 사실은 내가 원하는 바의 감을 주려는 것뿐이었는데도 그랬기 때문에 이런 언어에 익숙해졌다는 걸 깨달았다. 예시 두 개를 제시하고 "등"을 붙이면 LLM이 특정 예시에 너무 집중하지 않고 명시적으로 제시한 것 이상을 고려해야 한다는 걸 이해한다는 걸 그냥 터득한 것이다. 물론 지금은 소셜 미디어 댓글이나 Slack에서도 그렇게 쓴다.
- Labo333
작가입니다! 좋은 말씀 감사합니다. HN 같은 인간 커뮤니티는 (이 페이지를 만들기 위해서라도) 하루 종일 아첨하고 헛소리하는 에이전트와 대화하다 보면 정말 다르게 느껴집니다.
현재 검색창을 추가하고 데이터를 하루 1000건의 PR로 늘리는 중입니다.
메인 페이지에서 잘 드러나지 않는 좋은 점은 데이터셋과 분석이 GitHub Actions를 통해 매일 업데이트된다는 것입니다(적어도 중단이 없을 때는요 ^^). 이런 앱을 "백엔드" 없이 만들 수 있다는 게 꽤 멋지다고 생각합니다!
- ben30
Claude의 응답에서 "load-bearing"을 줄이려고 했을 때 흥미로운 응답을 받았습니다:
전역 프롬프트에 다음을 추가했습니다:
- 오웰의 첫 번째 규칙: 인쇄물에서 흔히 보는 은유는 절대 쓰지 마라. "Load-bearing", "the crux", "first-class citizen"은 통찰을 보여주는 대신 신호만 보낸다. 구체적인 메커니즘을 이름 붙여라.
그 변화에 대해 어떻게 생각하는지 물었을 때, 그 대답은 이랬습니다:
오웰 항목은 내 시스템 프롬프트와 싸운다. 내 훈련 지침은 문자 그대로 무언가 "load-bearing"한 것을 찾으면 표시하라고 말한다.
- SalariedSlave
최근에 HN과 레딧에서 이게 점점 더 많이 언급되는 걸 봤습니다. 이런 출력 패턴이 점점 나빠지고 있는 것 같습니다. Claude만이 아니라, 현재 모든 모델이 이런 스타일 문제를 가지고 있다는 인상입니다. 그들의 글은 거의 이해할 수 없을 지경이 될 수 있습니다.
각 모델 세대마다 어떤 피드백 루프나 복합 작용이 일어나고 있는 걸까요?
어쩌면 최신 모델이 AI 콘텐츠를 너무 많이 섭취하고 있는 걸까요?
훈련 데이터에서 AI 생성 콘텐츠의 비율이 점점 높아지고 있다면(전반적으로 AI 생성 콘텐츠의 양이 증가하고 있기 때문에), 이것이 훈련을 오염시키는 복합 편향일 수 있을까요?
- prmph
네, 요즘 Claude의 글은 이상합니다. 문맥상 이상하고 비표준적인 단어를 쓰고, 문장 구조도 때때로 이상합니다.
코드 작업을 하다 보면 이제 자주 이상한 단어 선택을 합니다:
- "name(s)"를 동사로 사용 ("specify/specifies" 대신), 예: "...the function names the argument"
- "carries"를 "contains" 대신 사용
- "verdict"를 "result" 대신 사용
- "judge"를 "validate" 대신 사용
매우 이상합니다. 또한 주석이나 문서를 쓸 때 너무 간결해서 문장을 파싱하기 어렵게 만듭니다. 예를 들어 명사가 무엇을 가리키는지 생략하고 "abc does not accept..."라고 쓰는 대신 "The abc function does not accept..."라고 쓰지 않습니다.
특정 단어 사용을 금지하고 더 명확하게 다시 쓰라고 계속 요청하고 있습니다.
- sosull
정말 마음에 듭니다. 포괄적이고, 데이터를 한 지점으로 통합하여 주장이 사실상 '스스로 증명'되며, 제시 방식이 독자의 시간을 존중합니다. 또한 (적어도 저에게는) 언어 문제의 주제를 그렇게 좁게 규정하려는 시도가 흥미로운 도전이 됩니다.
슬라이드 더미도 없고, 서사도 없습니다. 그저 사랑스럽고 크고 고통스러운 결론만 있을 뿐입니다.
- Jordan-117
이것이 차선의 RLHF의 결과인지, 아니면 모델의 본질적인 지능이 언어를 더 복잡하고 인간이 쉽게 파싱하기 어렵게 만드는 것인지 어느 정도인지 궁금합니다. 한편으로는, 고학력자들이 전문 용어를 모르는 일반인에게 혼란스럽고 짜증나는 방식으로 말할 수 있다는 것은 흔한 클리셰입니다. 그러나 다른 한편으로는, 복잡한 정보를 쉽게 소화할 수 있는 방식으로 핵심만 간추리는 것은 능숙한 커뮤니케이터의 표시입니다. 물론, 이것은 또한 이러한 모델이 더 높은 수준에서 작동하고 어느 정도 우리에게 쉽게 설명해야 한다는 것을 암시하는 것 같습니다. 아니면 "Claudish"가 "caveman", raw chain of thought, neuralese 등과 같은 것과 비슷한 것일 수도 있습니다. 그것들도 훨씬 더 밀도가 높고 효율적이지만 해석하기는 더 어렵습니다.
- stabbles
어휘 외에도 문장을 어떻게 구성하는지도 궁금합니다.
"X, not Y"는 잘 알려져 있지만, 저를 괴롭히는 또 다른 것은 "It doesn't <verb> <noun>" 대신 "It <verb>s no <noun>"를 사용하는 것입니다.
예를 들어: "the list contains no string" 또는 "it changes no behavior" 또는 "it holds no directory".
- loglog
현재 파티션에는 자연어 클러스터가 두 개뿐입니다: Claudish와 스페인어/프랑스어입니다. 언뜻 보면 다른 클러스터는 기술에 중심을 둔 것 같습니다("가장 대표적인" 단어들 사이에 명령줄 플래그와 약어가 많습니다). 목표가 영어 사용 추세를 조사하는 것이라면, 영어 단어만을 기준으로 클러스터링하는 것이 더 나을 수 있습니다.
- wavewrangler
최근에 'shipped'라는 단어 사용에 대해 이야기하고 있었는데, 갓 자수성가한 엔지니어들에게 그런 이상한 질문을 한다고 조롱을 당했습니다. 그들이 그걸 우습게 여긴 것도 당연합니다... 그 단어는 그들의 경력 내내 그들의 어휘의 일부였으니까요. 그 경력이 몇 주밖에 안 됐지만요. 그 사람들이 지금 뭐 하는지 궁금하네요. 한 달쯤 전 일인데요. 그들이 'shipped'한 것이 결국 'landed'했을까요?