포스트

AI 에이전트의 속살을 들여다보다: Rudel과 1,573개의 Claude Code 세션 분석

AI 에이전트의 속살을 들여다보다: Rudel과 1,573개의 Claude Code 세션 분석

obsessiondb/rudel — Claude Code Session Analytics

해커뉴스에 클로드 코드 세션 1,573개를 분석한 글이 올라왔더라. 와, 이 정도면 AI 에이전트들이 진짜 어떻게 일하는지 속을 들여다본 거 아니겠어? 마치 사람의 업무 방식을 스파이캠으로 찍은 느낌이랄까…

AI가 어떤 과정을 거쳐 코드를 짜고 문제를 푸는지 알게 되면, 우리가 프롬프트 던지는 방식도 확 달라질 거야. 결국 AI를 부리는 ‘지휘 능력’이 진짜 중요한 시대가 온다는 걸 다시 한번 깨닫는 거지. 이제 AI가 ‘어떻게’ 일하는지 이해하는 사람이 판을 잡을 거야


프롤로그: 블랙박스 안을 열다

AI 코딩 에이전트가 일상적인 개발 도구로 자리 잡으면서, 개발자들은 이상한 역설에 직면하기 시작했다. 매일 Claude Code를 사용하면서도 “우리 팀이 이 도구를 제대로 쓰고 있는 걸까?”라는 질문에 답할 수 없었던 것이다. 어느 세션이 효율적이었는지, 왜 어떤 세션은 도중에 포기되었는지, 시간이 지남에 따라 우리의 활용 방식이 실제로 개선되고 있는지—이 모든 것이 안갯속에 가려져 있었다.

이 공백을 직접 겪은 팀이 있었다. obsessiondb의 개발자들은 자신들의 Claude Code 세션에 대한 가시성이 전혀 없다는 것을 깨닫고, 직접 분석 레이어를 구축하기로 결심했다. 그렇게 탄생한 것이 Rudel이다. 그리고 그들이 자신의 팀 세션 데이터를 도구에 연결했을 때, 예상치 못했던 놀라운 패턴들이 모습을 드러내기 시작했다.

2026년 3월, 이 프로젝트가 해커뉴스의 “Show HN” 섹션에 공개되면서 AI 개발 커뮤니티에 뜨거운 반응을 일으켰다. 118개의 업보트와 72개의 댓글이 달린 이 스레드는, 단순한 도구 소개를 넘어 AI 에이전트가 실제로 어떻게 작동하는지에 대한 집단 지성의 탐구장이 되었다.


Rudel이란 무엇인가

Rudel은 Claude Code 세션을 수집, 저장, 분석하는 오픈소스 분석 플랫폼이다. GitHub 저장소는 obsessiondb/rudel이라는 이름으로 공개되어 있으며, 6명의 기여자가 참여하고 있다. 로고는 Anthropic의 Claude 로고를 연상시키는 디자인을 사용하고 있으며, 이 도구가 Claude 생태계에 특화되어 있음을 시각적으로 드러낸다.

아키텍처는 세 개의 핵심 레이어로 구성된다. 첫 번째는 개발자의 로컬 환경에 설치되는 CLI 클라이언트다. 이 CLI는 Claude Code 세션이 종료될 때마다 자동으로 세션 데이터를 캡처하여 업로드하며, 개발자의 작업 흐름을 전혀 방해하지 않는다. 두 번째는 수집된 데이터를 저장하고 정규화하는 백엔드 플랫폼이다. 세 번째는 개인과 팀 단위로 세션 데이터를 시각화하고 인사이트를 제공하는 대시보드다.

사용 방법은 놀랄 만큼 간단하다. npm으로 전역 설치 후 브라우저를 통해 인증하고, rudel enable 명령어를 실행하면 해당 프로젝트의 Claude Code 세션이 자동으로 업로드된다. 과거 세션을 한꺼번에 업로드하고 싶다면 rudel upload 명령어를 사용하면 된다. 팀원을 초대하여 조직 단위의 분석도 가능하다.

보안에 민감한 개발자들을 위해 완전한 셀프호스팅 옵션도 제공한다. Docker Compose 파일이 리포지토리에 포함되어 있어 로컬 환경에서 전체 스택을 구동할 수 있다. 다만 Rudel은 세션 트랜스크립트 전체를 수집하므로, 소스 코드, 프롬프트, 도구 출력, 파일 내용, 명령어 출력, URL, 그리고 세션 중 노출된 시크릿까지 포함될 수 있다는 점을 사용 전 반드시 인지해야 한다. 이 점은 해커뉴스 스레드에서도 프라이버시 우려로 활발히 논의되었으며, 팀은 셀프호스팅을 대안으로 안내했다.


데이터셋의 규모와 구성

이번 분석의 기반이 된 데이터셋은 Rudel 팀이 3개월에 걸쳐 자신들의 팀 세션을 직접 수집한 것이다. 총 1,573개의 실제 Claude Code 세션으로 구성되어 있으며, 누적 토큰 수는 1,500만 개 이상, 상호작용 횟수는 27만 건을 넘는다.

팀 구성은 4명의 엔지니어, 1명의 데이터/비즈니스 담당자, 1명의 디자인 엔지니어로 이루어졌으며 각 구성원의 세션이 대략 균등하게 분포되어 있다. 작업 유형으로는 대규모 기존 코드베이스(brownfield) 프로젝트가 약 40%, 신규 개발(greenfield) 프로젝트가 약 50%, 비코딩 작업이 나머지 10% 정도를 차지했다.

이 데이터셋이 공개된 최대 규모의 Claude Code 세션 데이터베이스라는 점에서 의의가 있다. 물론 하나의 팀 데이터라는 한계가 있어 외부 감사가 불가능하다는 지적도 나왔지만, 팀은 데이터를 조작했을 가능성이 극히 낮다는 커뮤니티의 신뢰를 받았다. 집계된 정보에 대해서는 구체적인 질문에 답변할 용의가 있다고 제작자가 직접 밝혔다.


분석이 드러낸 다섯 가지 충격적 발견

1. Skills는 거의 사용되지 않았다 — 단 4%

아마도 가장 놀라운 발견이었을 것이다. Claude Code의 Skills 기능은 특정 작업 유형을 위한 맞춤형 지침을 제공하는 강력한 도구다. 팀은 Skills를 설정해 두었음에도 불구하고, 전체 세션 중 단 4%에서만 Skills가 실제로 활성화되었다.

제작자인 keks0r는 이 결과에 대해 흥미로운 설명을 덧붙였다. 4% 사용률은 Skills가 아예 존재하지 않는다는 의미가 아니라, 기대했을 때 사용되지 않았다는 것이다. 즉, Skills 트리거가 예상대로 작동하지 않는 경우가 많았다. 이 문제를 해결하기 위해 팀은 CLAUDE.md 파일을 조정하여 Claude가 Skills를 더 적극적으로 호출하도록 유도했다. 또한 Claude 4.5 모델과 비교했을 때 Claude 4.6에서 Skills 호출 능력이 상당히 개선된 것도 관찰되었다.

해커뉴스 커뮤니티에서는 이에 대한 다양한 대응 방식이 공유되었다. 한 개발자는 Skills를 명시적으로 언급하여 호출하는 방식을 사용한다고 밝혔다. 예를 들어 “/writing-tests some-class.cpp에 대한 테스트를 작성해줘”처럼 Skills 이름을 직접 프롬프트에 포함시키는 것이다. 또 다른 접근법으로는 CLAUDE.md를 최대한 단순하게 유지하고, Skills를 비활성화한 채 Opus 모델을 통해 서브에이전트를 직접 스폰하는 방법도 제안되었다.

2. 세션의 26%는 첫 60초 안에 포기된다

전체 세션의 4분의 1이 시작 직후 버려진다는 사실은 복잡한 해석을 필요로 한다. 단순히 “실패”로 보기 어려운 이유가 있다. 해커뉴스 스레드에서 여러 개발자들이 자신의 경험을 공유했는데, 짧은 세션이 반드시 나쁜 것이 아니라는 점에 많은 이들이 동의했다.

세션을 조기 종료하는 이유는 다양했다. 환경 설정 문제(GitHub 토큰 누락, 필요한 도구가 PATH에 없음 등)를 깨닫고 수정하기 위해 세션을 재시작하는 경우, 간단한 질문에만 답을 구하고 바로 종료하는 경우, AI가 처음 1-2분 동안 잘못된 방향으로 컨텍스트를 채워버릴 때 더 나은 프롬프트로 새로 시작하는 경우가 있었다. 한 개발자는 “AI가 엉뚱한 접근법으로 컨텍스트 창의 40%를 채우고 돌아왔을 때 세션을 죽이고 다른 프롬프트로 새 세션을 시작한다”고 생생하게 묘사했다.

오히려 여러 개발자들은 단일 목적의 짧은 세션을 사용하는 것이 효율적인 전략이라고 강조했다. 컨텍스트를 깨끗하게 유지하는 것이 에이전트를 올바른 방향으로 이끄는 가장 효과적인 방법이라는 것이다. 최신 상태의 AGENTS.md나 CLAUDE.md 파일이 있다면, 새로운 세션이 작은 작업을 빠르게 시작하는 데 전혀 문제가 없다.

3. 작업 유형에 따라 성공률이 크게 달랐다

분석 결과, 세션의 성공률은 작업 유형에 따라 극명하게 갈렸다. 가장 높은 성공률을 기록한 유형은 문서화(documentation) 작업이었다. 반면 가장 낮은 성공률을 보인 것은 리팩토링(refactoring) 이었다.

이 결과는 직관적으로 이해된다. 문서화는 명확한 목표와 결과물이 있고, AI가 생성한 문서는 즉시 평가하기 쉽다. 반면 리팩토링은 코드베이스에 대한 깊은 이해, 다양한 트레이드오프 판단, 예상치 못한 부작용 처리가 필요하여 AI 에이전트가 중간에 좌절하거나 인간의 개입이 더 자주 요구된다.

이는 작업 유형에 따라 AI에게 위임하는 수준과 방식을 달리해야 한다는 실용적인 시사점을 제공한다. 특히 대규모 리팩토링 작업에서는 명확한 성공 기준과 단계적 접근법이 더욱 중요해진다.

4. 에러 캐스케이드는 첫 2분 안에 시작된다

분석에서 드러난 또 하나의 패턴은, 에러가 세션 초반 2분 이내에 연쇄적으로 발생하기 시작할 경우 해당 세션이 결국 포기될 확률이 상당히 높다는 것이다. 다시 말해, 세션의 초기 2분이 세션 전체의 운명을 결정짓는 경향이 있다.

이 패턴은 중요한 실천적 함의를 갖는다. 프롬프트 품질, 초기 컨텍스트 제공 방식, 첫 번째 응답에서 에이전트가 올바른 방향을 잡고 있는지 빠르게 판단하는 능력이 AI 활용의 핵심 역량으로 부상한다는 점이다. “에이전트를 지휘하는 능력”이 실질적으로 가장 중요한 개발자 스킬이 되는 시대가 이미 도래했음을 수치로 확인한 셈이다.

5. ‘좋은 에이전트 세션’의 벤치마크가 존재하지 않는다

아마도 가장 근본적인 발견은 아직 업계에 에이전트 성능의 객관적 기준이 없다는 것이다. 팀은 이 공백을 채우기 위해 기준(benchmark)을 직접 구축하고 있다고 밝혔다. 코드 생성 양이 10배 늘었다고 해서 생산성도 10배가 되는 것은 아니다. Rudel 팀의 개발자 Rafa는 “갑자기 모두가 하루에 수십 개의 세션을 실행하며 10배 더 많은 코드를 만들어냈지만, 반드시 10배 더 생산적이지는 않았다”고 솔직하게 인정했다.

이는 AI 도구의 ROI 측정이 얼마나 어려운지를 잘 보여준다. Rudel은 세션에 소비된 토큰이 적정한지, 세션의 성공률은 어떻게 되는지, 성공적인 세션을 만드는 요인이 무엇인지를 정량적으로 파악할 수 있게 함으로써 이 문제에 접근한다.


커뮤니티가 발굴한 심층 인사이트

해커뉴스 스레드는 단순한 도구 소개를 넘어, AI 에이전트 활용 경험자들의 집단 지식이 응축된 공간이 되었다. 특히 주목할 만한 논의들을 살펴보면 다음과 같다.

컨텍스트 관리의 중요성: 여러 개발자들이 성공적인 세션의 핵심으로 컨텍스트 관리를 꼽았다. /compact 명령어로 히스토리를 압축하거나 /clear로 컨텍스트를 완전히 초기화하는 것이 세션 품질을 크게 좌우한다는 경험이 공유되었다. 특히 /rewind 명령어를 활용해 잘못된 정보를 컨텍스트에서 완전히 제거하는 것이 단순히 “이전 방법은 무시하고 이걸 해줘”라고 말하는 것보다 훨씬 효과적이라는 실용적 팁이 나왔다.

멀티 에이전트 오케스트레이션: 생산적인 세션일수록 Task 명령어(서브에이전트를 병렬로 실행)를 자주 활용한 것으로 나타났다. 대규모 리팩토링이나 end-to-end 기능 구현 같은 복잡한 작업에서 이 패턴이 두드러졌다. 한 개발자는 계획 수립 단계에서 Claude와 Codex 에이전트를 병렬로 실행하여 각각의 검토 결과를 통합하는 워크플로우를 소개하기도 했다. 멀티 에이전트 아키텍처가 실험적 사치가 아닌 실용적 도구로 자리 잡았음을 현장의 목소리로 확인한 것이다.

CLAUDE.md의 최적 전략: 흥미로운 논쟁이 벌어졌는데, 지나치게 길고 자주 업데이트되지 않는 CLAUDE.md 파일이 오히려 모델 효율을 저하시킨다는 주장이 제기되었다. 문서화의 양보다 질과 최신성이 중요하며, 때로는 줄이고 단순화하는 것이 더 나은 결과를 낳는다는 것이다. 이에 대해 Rudel 팀은 CLAUDE.md의 상세도와 모델 효율 간의 관계를 분석하는 것을 로드맵에 추가하겠다고 화답했다.

도구 호출의 비일관성: 한 개발자는 도구가 59%의 경우에만 실제로 호출된다는 수치를 언급하며, 훅(hooks)을 통해 컨텍스트를 동적으로 주입하여 워크플로우의 결정론성을 높이는 아이디어를 제시했다. AI 에이전트의 비일관성은 현재 가장 큰 실용적 문제 중 하나로, 도구 호출 신뢰도를 높이는 것이 중요한 연구 과제임을 시사한다.


기술 스택과 아키텍처

Rudel의 기술 스택은 현대적인 웹 애플리케이션의 전형적인 구성을 따른다. Node.js/npm 기반의 CLI 클라이언트, 세션 데이터를 저장하는 백엔드 서비스, 그리고 브라우저 기반 대시보드로 구성된다. 전체 스택을 로컬에서 실행하기 위한 Docker Compose 설정이 리포지토리에 포함되어 있다.

세션 데이터는 Claude Code가 생성하는 JSONL 형식의 트랜스크립트 파일을 기반으로 한다. 이 파일에는 사용자 프롬프트, AI 응답, 도구 호출 내역, 타임스탬프, 그리고 토큰 사용량이 담겨 있다. Rudel은 이 원시 데이터를 파싱하여 세션별, 사용자별, 프로젝트별로 집계된 분석을 제공한다.

OpenAI Codex 세션에 대한 지원도 추가되었지만, 아직 완전히 테스트되지 않은 상태라고 팀이 밝혔다. 세션 업로드는 작동하지만 분석 추출 부분의 품질 보증이 진행 중이다.


프라이버시, 보안, 그리고 신뢰의 문제

해커뉴스 스레드에서 가장 첨예하게 다루어진 주제 중 하나는 바로 프라이버시였다. Claude Code 세션 트랜스크립트는 매우 민감한 정보를 담고 있다. 소스 코드, 사용 중인 API 키, 내부 시스템 구조, 비즈니스 로직이 모두 포함될 수 있기 때문이다.

한 개발자는 “서드파티 서비스에 Claude Code 로그를 그대로 업로드하는 것은 매우 꺼려진다”는 의견을 솔직하게 피력했고, 이는 많은 이들의 공감을 얻었다. Rudel 팀은 이에 대해 투명한 자세를 유지했다. 호스팅된 서비스에 대한 프라이버시 정책을 공개했으며, 완전한 로컬 실행 옵션을 제공함으로써 민감한 환경에서도 사용할 수 있는 길을 열어두었다. 또한 rudel enable은 명령어를 실행한 특정 리포지토리에만 적용되며, 선택적으로 특정 세션만 rudel upload로 업로드할 수 있다는 점도 강조했다.


AI 시대 개발자의 새로운 핵심 역량

이 분석이 제기하는 더 근본적인 질문은 “AI 에이전트를 잘 활용한다는 것이 무엇을 의미하는가”이다. 1,573개의 세션 데이터는 몇 가지 명확한 패턴을 드러낸다.

첫째, 에이전트와의 인터페이스 능력이 새로운 핵심 역량이 되었다. 초기 2분의 에러 캐스케이드 패턴이 세션 전체의 결과를 예측한다는 사실은, 프롬프트를 어떻게 구성하느냐가 코드 작성 능력만큼 중요해졌음을 의미한다. 명확한 성공 기준을 사전에 정의하고, 올바른 컨텍스트를 제공하며, AI가 잘못된 방향으로 가고 있음을 빠르게 감지하는 능력—이것이 AI 시대 개발자의 새로운 메타스킬이다.

둘째, 팀 수준의 AI 활용 최적화가 중요해졌다. 개인의 세션 효율만이 아니라, 팀 전체에서 어떤 패턴이 성공적인지 공유하고 실패 패턴을 반복하지 않는 것이 생산성에 직접 영향을 미친다. Rudel이 팀원들이 어려움을 겪은 세션을 동료와 공유하고 학습하는 기능을 강조하는 것은 이런 이유에서다.

셋째, 측정하지 않으면 개선할 수 없다. “10배 더 많은 코드 = 10배 생산성”이라는 단순한 등식이 성립하지 않는다는 것을 Rudel 팀 스스로 발견했다. 세션 성공률, 토큰 효율, 작업 유형별 성과를 정량적으로 추적하지 않으면 AI 도구의 실제 가치를 파악하기 어렵다. 특히 AI 도입을 검토하는 팀이나 기업 입장에서 ROI를 실제 데이터로 정당화할 수 있다는 점은 중요한 실용적 이점이다.


한국 개발자와 기업을 위한 시사점

한국의 SI/SM 환경에서 AI 코딩 에이전트 도입을 검토하는 팀들에게 이 분석은 몇 가지 중요한 시사점을 제공한다.

Skills 활용률 4%라는 수치는, 도구를 도입한다고 해서 자동으로 최적으로 활용되는 것이 아님을 명확히 보여준다. 특히 팀 전체가 CLAUDE.md 파일 작성법, Skills 설계 방식, 컨텍스트 관리 전략을 공통으로 학습하고 내재화하는 과정이 필요하다. 도구 도입 이전에 운영 방식의 설계가 선행되어야 한다는 것이다.

리팩토링 세션의 낮은 성공률은, 기술 부채가 누적된 레거시 코드베이스를 다루는 경우가 많은 한국 SI 프로젝트에서 특히 주의가 필요한 부분이다. AI 에이전트에게 대규모 리팩토링을 맡길 때는 보다 작고 명확한 단위로 작업을 분해하는 전략이 효과적이다.

팀 단위 가시성 확보는 AI 도구의 비용 정당화 측면에서도 중요하다. “누가 어떻게 사용하고 있는가”를 데이터로 파악하지 못하면, AI 도구에 대한 투자 결정을 합리적으로 내리기 어렵다. Rudel 같은 분석 레이어는 단순한 편의 도구가 아니라, 조직 수준의 AI 거버넌스를 위한 인프라로 볼 수 있다.


에필로그: 에이전트를 관찰하는 에이전트

Rudel이 흥미로운 이유는 단순히 데이터를 수집하는 것을 넘어서, AI 에이전트의 행동을 관찰하고 그로부터 배우는 메타 레이어를 구현했다는 점이다. 마치 AI가 코드를 쓰는 방식을 다른 시스템이 관찰하고 분석하는 구조다.

이 프로젝트가 드러낸 가장 의미 있는 통찰은 아마도 마지막 발견일 것이다—좋은 에이전트 세션의 기준이 아직 존재하지 않는다는 것. 우리는 AI 에이전트가 코드를 쓰는 속도와 양에 감탄하는 시대에 살고 있지만, 그 품질과 효율을 어떻게 판단해야 하는지는 여전히 개척 중인 영역이다.

AI 에이전트가 어떻게 일하는지를 이해하는 사람이 판을 잡는 시대. Rudel은 그 이해를 위한 창문을 열었다. 그 창문을 통해 보이는 풍경은, 아직 우리가 얼마나 많은 것을 배워야 하는지를 선명하게 보여준다.


참고 자료

  • GitHub 저장소: https://github.com/obsessiondb/rudel
  • 서비스 사이트: https://rudel.ai
  • 해커뉴스 스레드: https://news.ycombinator.com/item?id=47350416

작성일: 2026-03-13

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.