※이 기사는 대략적으로 실용적이지 않은 내용입니다. (만들 때는 조금 더 실용적일 것이라 생각했습니다만, 그렇지 않기 때문에 추모의 의미로 작성하고 있습니다.)

Claude Code를 매일 사용하다 보면, 문득 "최근에 좀 똑똑해졌나?"라거나 반대로 "왠지 최근 들어 머리가 나빠진 것 같은데?"라고 느끼는 순간이 있습니다. SNS에서도 "저하되었다", "아니, 전보다 좋아졌다"라는 목소리가 정기적으로 올라옵니다.

하지만 이는 체감일 뿐입니다. 정말로 성능이 변한 것인지, 아니면 기분 탓(자신의 태스크가 어려웠을 뿐)인지, 아무도 객관적인 수치를 가지고 있지 않습니다.

그래서 "Claude Code의 성능 향상·저하를 시계열로 시각화할 수 없을까?"라고 생각한 것이 이번 시도입니다.

처음에 생각한 것은 매우 순수한 발상이었습니다.

"Claude Code에게 매일 같은 코딩 과제를 내고, 결과물을 채점하면 성능의 변화가 수치로서 보일 것이다."

구체적으로는 다음과 같은 것들을 시도했습니다.

• 알고리즘 문제나 리팩터링(Refactoring) 과제 등의 고정 태스크 세트를 준비한다
• 매일(혹은 버전이 바뀔 때마다) 같은 태스크를 풀게 한다
• 그것을 시계열로 플롯(Plot)하여 "성능 트렌드"로 만든다

하지만 실제로 해보니 거의 차이가 나지 않았습니다...

원인으로는 문제가 너무 쉬웠기 때문이라고 생각됩니다.

그렇다면 어려운 문제로 만들면 되겠다고 생각했지만, 실제로 개발할 정도의 난이도를 가진 시험 설계나 그 난이도의 문제를 다양한 관점에서 설계하는 것은 상당히 어렵다고 느꼈습니다.

벤치마크(Benchmark)로 안 된다면, 관점을 바꾸기로 했습니다.

성능 변화는 우선 사용자의 체감으로서 SNS에 나타날 것이라고 생각했습니다. "빨라졌다", "바보가 됐다", "고쳐졌다"와 같은 목소리는 개별적으로는 노이즈일지라도 통계적으로 모으면 경향이 보입니다.

그래서 X(구 Twitter)의 게시물로부터 Claude Code의 "성능 향상 ↔ 저하"를 감성(Sentiment) + 키워드로 수치화하여, 시계열로 시각화하는 대시보드를 만들었습니다.

게시물 1건을 성능 스코어로 변환하는 부분이 이 시스템의 핵심입니다. 사전(Dictionary) 기반과 LLM 기반의 두 가지 방식을 준비하였고, 둘 다 동일한 출력 포맷(전체 Sentiment + 5가지 관점 스코어)으로 맞추어 두었기 때문에, 후속 집계·시각화는 방식을 불문하고 공통으로 동작합니다.

단순한 긍정·부정 판정으로는 "Claude Code의 성능"이라는 문맥을 포착할 수 없습니다. 그래서 성능에 관한 단어를 카테고리·극성·강도를 포함하여 사전화했습니다.

예시

E('폭속', 'speed', 1, 'ja', 2),
E('느려졌다', 'speed', -1, 'ja', 1.5),
E('저하', 'quality', -1, 'ja', 1.5),
...

카테고리는 speed / quality / intelligence / reliability / cost의 5개로 설정하여, "속도는 좋지만 똑똑함은 떨어졌다"와 같이 관점별로 분해해서 볼 수 있도록 했습니다.

처리 흐름은 형태소 분석 → 사전 매칭 → 수식어·부정 조정입니다.

체감에 가깝게 만들기 위한 고안으로서, 강도 수식어 "매우", "엄청", "super" 등으로 인접한 단어의 스코어를 증감시키고 있습니다.

또한, 부정의 반전 "빠르지 "않다"", "저하되지 "않다""와 같은 부정을 인접 토큰만을 따라가며 반전시켜, 떨어진 구절의 부정을 잘못 포착하지 않도록 하고 있습니다.

사전 기반 방식은 무료이며 고속으로 매일 돌릴 수 있다는 것이 강점이지만, 사전에 실려 있지 않은 표현이나 비꼬는 말투, 완곡한 평가는 놓치게 됩니다. 이를 위해 방식 B를 추가했습니다.

사전의 빈틈을 메우기 위해, Claude 스스로 분류하게 하는 방식도 준비했습니다.

const MODEL = process.env.LLM_MODEL || 'claude-opus-4-8';
// 20건씩 배치(Batch), json_schema로 구조화된 출력, effort:low로 비용 최적화

각 게시물을 "전체 Sentiment + 5가지 관점"으로 -1.0 ~ +1.0 사이로 채점하게 합니다. 사전 단어가 없어도 문맥·비꼼·암묵적인 의견을 포착할 수 있는 것이 이점이며, "성능에 대해 언급하지 않은 게시물은 0 근처로 몰아라"라고 시스템 프롬프트(System Prompt)로 지시하고 있습니다.

두 방식 모두 동일한 PostAnalysis 타입을 반환하므로 마지막은 공통 처리입니다. 게시물별 스코어를 **인게이지먼트(Engagement) 가중 평균하여 [-1, +1]의 "성능 인덱스"로 산출하고, 일별로 시계열 플롯합니다. + 쪽으로 치우쳐 있으면 "최근 호평 중", - 쪽이면 "저하 목소리가 우세"라고 한눈에 알 수 있는 구조입니다.

이번 접근 방식을 통해 시험을 수행하는 것보다 더 간단하게 사람들의 목소리로부터 샘플링하여 Claude Code의 성능에 대해 시각화할 수 있게 되었습니다. 하지만 이번 방법도 정량적인 평가가 아니라는 점이나 성능 이외의 게시물도 있기 때문에 데이터 자체에 의문이 남는 접근 방식입니다. 24시간 균등하게 가져오는 것이 아니라 3시간마다 8개 클러스터(총 200건/일, 25건/3시간, 최대 1400건/주)로 나누어 게시물을 수집하고 있지만, 샘플 수로서는 현재 상당히 적은 편입니다.

또한, 특히 심각한 것은 비용 측면입니다. 이 샘플 수로 일주일 분량에 약 2,500엔 정도가 들고 있습니다. 그 대부분이 X API 요금입니다. 제대로 측정하려면 개인적으로는 하루에 1,000건 정도는 가져오고 싶습니다. 그렇게 되면 5배이므로 일주일에 12,500엔, 한 달에 60,000엔... 생각하고 싶지 않네요.

적은 샘플 수이긴 하지만, 시스템으로서 Claude Code의 성능 향상·저하를 시각화하는 메커니즘을 만들 수 있었다는 점은 좋았다고 생각합니다. 다만 솔직히 성능 저하를 감지해도 무엇을 할 수 있느냐고 묻는다면 딱히 할 수 있는 게 없는 것 같기도 해서, 거기에 한 달에 60,000엔을 쓰는 것은 가성비가 나쁘다는 말로는 부족할 정도라고 생각합니다(웃음).

앞으로는 더 가성비 좋은 방법을 모색하여 제2탄을 낼 수 있으면 좋겠습니다!