RummiArena 2026-04-04 종합 해설

게시 2026/04/04

By BLUEBUG

64 분읽는 시간

Insights Report × 방법론 평가 × 바이브 로그

분석 대상: (1) Claude Code Insights Report (2026-03-04~04-03) / (2) RummiArena 개발 방법론 평가 / (3) 바이브 로그 2026-04-04
관련 저장소: RummiArena GitHub
해설 작성: 2026년 4월 4일
전편 연결: 바이브 로그 04-02(8/13), 04-03(17/17, E2E 362개) 해설에서 이어짐

개요: 이 문서는 무엇의 1개월 결산인가

오늘(4월 4일)은 숫자들이 쏟아지는 날이다. /insights 명령으로 1개월의 데이터가 집계됐고, 그것을 보면서 방법론 평가 문서가 쓰여졌고, 저녁에 바이브 로그가 그 하루를 마감했다. 세 문서는 같은 날 같은 프로젝트를 세 개의 렌즈로 찍은 사진이다.

Insights Report는 정량적 렌즈다. 48세션, 897메시지, 96시간, 110커밋. 숫자가 사실을 말한다.

방법론 평가는 분석적 렌즈다. 이것이 “바이브 코딩인가 아닌가”를 따지고, 무엇이 작동했고 무엇이 작동하지 않았는지를 구조적으로 해부한다. Claude Opus 4.6의 시각에서 쓰여졌다.

바이브 로그는 주관적 렌즈다. 숫자와 분석 뒤에 있는 인간의 경험 — Security 에이전트가 P0 공격 벡터를 발견했을 때의 체감, Gritling이라는 가상 버섯 펫에서 현실의 보안 구멍을 발견했을 때의 아이러니.

이 세 렌즈를 통해 RummiArena가 무엇인지, 그리고 2026년 AI 보조 개발이 어디에 와 있는지를 살펴본다.

1장. Insights Report — 한 달을 숫자로 읽기

1.1 62세션과 48세션: 무엇이 제외됐는가

총 세션은 62개이지만 분석 대상은 48개다. 14개 세션이 제외됐다. 제외된 이유는 주로 rate limit으로 인한 완전 실패 세션이거나, 극히 짧아 패턴 분석이 불가능한 세션들이다.

이 14개의 차이 자체가 데이터다. 1개월 62세션 중 14개(23%)가 완전하게 기록되지 못했다. 그 대부분의 원인은 Insights Report의 “마찰 분석” 섹션에서 “Rate Limit 및 리소스 고갈”로 분류된 항목과 일치한다. 이것은 현재 AI 도구 활용의 구조적 취약점 중 하나다.

1.2 핵심 수치들의 의미

897 메시지 / 48세션 = 세션당 평균 18.7 메시지

이것은 각 세션이 단순한 단방향 명령이 아니라 반복적인 교환으로 이루어졌음을 의미한다. “고쳐줘 → 잘못됐어 → 이렇게 해줘 → 아직도 아니야 → 다시”의 반복. 이것이 Insights Report가 “iterative refinement under pressure(압박 속 반복 정제)”를 지배적 패턴으로 명명한 이유다.

응답 시간 중앙값 44.4초

AI의 응답 시간이 44초라는 것은, 개발자가 응답을 기다리는 동안 다른 일을 할 수 있음을 의미한다. 이것이 병렬 작업의 물리적 기반이다. 에이전트 A에게 분석을 시키고 44초를 기다리는 동안, 에이전트 B에게 코드 수정을 지시할 수 있다. 단순한 비동기 처리가 아니라 인지적 병렬성의 기반이 된다.

110 커밋 / 21 활동 일수 = 일평균 5.2 커밋

매일 5.2번의 의미 있는 코드 변경을 커밋했다. 이것이 의미 있는 이유는 커밋 품질 때문이다. CI/CD 파이프라인이 완성된 뒤에는 모든 커밋이 17개의 자동화 게이트를 통과해야 한다. 그러니 “매일 5.2번의 검증된 코드 변경”이 더 정확한 표현이다.

+18,372 / -1,128 라인

추가된 라인 대비 삭제된 라인의 비율이 약 16:1이다. 이것은 리팩토링보다는 순수한 기능 추가가 주를 이뤘음을 시사한다. 처음부터 거의 없던 상태에서 시작해 매우 빠르게 코드베이스가 성장했다는 것이다. 반면 삭제된 1,128 라인은 버그 수정, 중복 제거, 죽은 코드 정리가 있었음을 보여준다.

1.3 도구 사용 현황: Bash가 1,798회인 이유

도구 사용 통계에서 가장 눈에 띄는 것은 Bash가 1,798회로 압도적 1위라는 점이다. 이것은 Claude Code가 단순히 코드를 쓰는 도구가 아니라, 실제 개발 환경을 조작하는 도구로 쓰였음을 의미한다. 커맨드를 실행하고, 파이프라인을 돌리고, 로그를 확인하고, 파일 권한을 바꾸고, Git 작업을 수행하는 모든 것이 Bash 호출이다.

Read(699회)와 Edit(399회)의 조합도 흥미롭다. Read가 Edit보다 훨씬 많다는 것은, 코드를 쓰기 전에 기존 코드를 먼저 읽고 이해하는 과정이 충분히 이루어졌음을 시사한다. 충분한 맥락 없이 코드를 수정하면 다른 부분을 망가뜨릴 가능성이 높다. Read → Edit의 순서가 지켜진 것이 코드 품질에 기여했을 것이다.

Agent(213회)는 에이전트 팀 투입 횟수다. 이것을 48세션으로 나누면 세션당 약 4.4회의 에이전트 팀 투입이 있었다. 실제로는 하루 20~25회 집중 투입하는 날과 적게 쓰는 날이 섞여 있었을 것이다.

1.4 언어별 파일 수: Markdown이 1위인 의미

파일 수 기준으로 가장 많은 언어가 Markdown(699개)이라는 것이 눈에 띈다. 코드가 아닌 문서가 압도적으로 많다. 이것은 방법론 평가에서 “문서화 규율”을 “잘한 점” 1위로 꼽은 것과 일치한다.

하지만 동시에 방법론 평가가 지적하는 문제이기도 하다. 48세션 중 14개(29%)가 주로 문서화에 사용됐다. 파일 699개의 Markdown이 모두 필요한 것인지, 아니면 일부는 읽히지 않는 형식적 산출물인지는 검토가 필요하다.

TypeScript(158개), YAML(84개), Python(53개), Go(33개)의 순서는 RummiArena의 기술 스택을 반영한다. Go는 파일 수는 적지만 서버의 핵심 비즈니스 로직을 담고 있다. TypeScript는 프론트엔드(Next.js)와 E2E 테스트의 주언어다. YAML은 Kubernetes 설정, Helm 차트, CI/CD 파이프라인 설정을 담는다.

1.5 시간대별 활동 패턴

오후 12 ~ 18시에 전체 메시지의 53%(472개)가 집중됐다. 오전 6 ~ 12시는 159개(18%), 저녁 18 ~ 24시는 195개(22%), 심야 0 ~ 6시는 71개(8%)다.

이 패턴은 캐나다 시간 기준으로 해석하면 더 흥미롭다. 한국 시간으로 오후 12 ~ 18시는 캐나다 동부 시간으로 새벽 2~8시에 해당한다. 즉 한국 개발자가 캐나다 직장에서 퇴근 후, 저녁 시간대에 집중적으로 개발하는 패턴일 수 있다. 혹은 단순히 개발자의 개인적 리듬이 오후에 집중되는 것일 수도 있다.

심야(0~6시) 71개도 무시하기 어렵다. 파이프라인이 새벽에 실패하거나, 생각이 정리되지 않아 새벽에 다시 앉는 경우가 존재했음을 보여준다.

2장. 마찰 분석 — 53건의 실패가 말하는 것

2.1 가장 많은 마찰: “잘못된 접근” 19건

전체 53건의 마찰 중 가장 많은 것이 “잘못된 접근(Wrong Approach)” 19건이다. 이것은 Claude가 기술적으로 잘못된 방향을 선택하거나, 자신의 결정을 여러 번 뒤집은 것이다.

가장 대표적인 예시가 displayName 아키텍처 문제다. Claude가 사용자 표시 이름을 JWT의 name claim에서 가져오는 방식을 반복해서 제안했다. 이것이 왜 잘못됐는지는 간략히 설명하면 다음과 같다. JWT(JSON Web Token)는 인증 토큰으로, 사용자가 로그인할 때 서버가 발급하는 서명된 데이터다. JWT에 name claim을 포함하면 사용자가 자신의 이름을 변경했을 때 JWT를 재발급해야 한다. 게임 서버처럼 실시간 통신이 많은 환경에서 이것은 복잡한 세션 관리 문제를 야기한다. 올바른 방법은 name을 별도의 사용자 프로필 저장소에 보관하고 게임 세션에 필요할 때 조회하는 것이다.

이 잘못된 접근이 여러 세션에 걸쳐 반복됐다는 것은, CLAUDE.md에 아키텍처 제약이 충분히 명시되지 않았음을 의미한다. 에이전트는 매 세션마다 CLAUDE.md를 읽어 컨텍스트를 복원하는데, 그 문서에 “JWT name claim 방식은 사용하지 않는다”는 명시가 없었다면 같은 실수를 반복할 수 있다.

2.2 두 번째 마찰: “요청 오해” 12건

12건의 요청 오해는 Claude가 사용자의 의도를 잘못 파악한 경우다. “MCP push 요청 시 git bash push 사용”이 대표적이다. 사용자가 “MCP를 통해 push해줘”라고 했을 때, Claude가 MCP(Model Context Protocol) 도구 대신 git bash 명령으로 push한 것이다. 이것은 프로젝트 고유의 워크플로우를 에이전트가 충분히 학습하지 못한 결과다.

또 다른 예시인 “일일 마감 절차에서 커맨드/스킬/에이전트 무시”는 더 흥미롭다. 개발자가 /daily-close를 요청하면, 이미 정의된 스킬이나 커맨드가 있음에도 Claude가 그것을 사용하지 않고 처음부터 절차를 재구성하는 경우가 있었다. “프로젝트 규약/도구 무시”가 12건 발생했다는 것은, CLAUDE.md에 “이 프로젝트는 다음 커맨드를 사용한다: /daily-close, /standup…“이라는 명시적 안내가 필요함을 보여준다.

2.3 도구 에러 분포: Command Failed 81건

도구 에러 중 가장 많은 것이 “Command Failed” 81건이다. 이것은 Claude가 실행한 bash 명령이 실패한 것이다. 원인은 다양하다. 파일 경로 오류, 권한 부족, 네트워크 문제, 도구 미설치 등. 이 숫자가 많다는 것은, Claude가 실행할 명령을 미리 검증하지 않고 시도해보는 방식으로 작업했음을 시사한다. 이것이 항상 나쁜 것은 아니다. 빠르게 시도하고 실패에서 배우는 것이 때로 더 효율적이다.

하지만 동시에 81번의 명령 실패는 81번의 대기 시간이기도 하다. 실패 → 원인 분석 → 수정 → 재시도의 루프가 81번 반복됐다.

2.4 추정 만족도: Frustrated 9건의 맥락

추정 만족도 분류에서 Frustrated 9건이 있다. 이것이 어떤 맥락에서 발생했는지를 보면 프로젝트의 압박 수준을 가늠할 수 있다.

바이브 로그 04-03에서 “클로드 오늘 진짜 멍청이가 된 것 같음”이라는 표현이 있었다. 이런 표현이 메시지에 담겼을 때 Frustrated로 분류된다. 이것이 9번 있었다는 것은, 약 5.3세션 중 1번 꼴로 깊은 좌절이 있었음을 의미한다.

그러나 전체 22건(Satisfied) + 97건(Likely Satisfied)이라는 배경을 함께 읽어야 한다. 전체의 77%가 대부분 이상 달성됐다. 9건의 Frustrated는 예외적 순간이지, 일상적 경험이 아니었다.

3장. 잘한 점 — 에이전트 팀 오케스트레이션의 구체적 성과

3.1 66 TC 100% PASS: QA 에이전트의 성과

방법론 평가가 “잘한 점” 1위로 꼽은 것은 에이전트 전문화다. 그 구체적 증거 중 하나가 “QA 에이전트 캠페인 66 TC, 100% PASS”다.

TC(Test Case)는 테스트 케이스다. 66개의 테스트 케이스를 설계하고 실행해서 전부 통과했다. 이것이 인상적인 이유는, QA 에이전트가 단순히 기존 테스트를 돌린 것이 아니라 새로운 테스트를 설계했다는 것이다. QA 관점에서 “이 기능에 어떤 엣지 케이스가 있는가?”를 물어보고, 그 케이스들을 테스트로 만들었다.

이 과정에서 개발자 혼자였다면 놓쳤을 케이스들이 포착됐다. 예를 들어 보안 에이전트가 발견한 Rate Limit 미적용 문제처럼, 개발자가 기능 구현에 집중할 때 자연스럽게 보안과 품질의 관점이 뒤로 밀린다. 전문화된 에이전트가 그 시야의 공백을 채우는 것이다.

3.2 E2E 153 → 362개 확장의 실제 과정

Insights Report는 “E2E 테스트 153 → 338 → 362개 확장”이라는 경로를 기록한다. 이것이 선형적으로 늘어난 것이 아님을 주목해야 한다.

153에서 338로의 도약이 한 번, 338에서 362로의 최종 완성이 또 한 번 있었다. 그 사이에 80건의 실패를 0건으로 만드는 과정이 있었고(한 세션에서), 한국어 로컬라이제이션 불일치를 디버깅하는 과정이 있었다.

한국어 로컬라이제이션 불일치는 게임 UI의 텍스트가 영어와 한국어 두 버전 사이에서 일치하지 않아 테스트가 실패하는 케이스다. 예를 들어 테스트가 “게임 시작” 버튼을 찾는데, 실제 UI에는 “Game Start”가 렌더링되는 경우다. 이것은 단순한 번역 버그가 아니라, i18n(국제화) 구현의 일관성 문제다.

3.3 문서화 규율: “일일 마감”의 구체적 내용

Insights Report가 분석한 일일 마감 의식의 구체적 내용은 다음과 같다:

세션 로그 업데이트 → 데일리 로그 업데이트 → 바이브 로그 작성 → MEMORY.md 업데이트 → PLAN.md 업데이트 → git add (test-results 포함) → 커밋 → ALL remotes에 push.

이것이 왜 중요한가? AI 에이전트는 세션 간 기억이 없다. 새 세션을 열면 이전 작업을 모른다. MEMORY.md가 그 기억을 대신한다. 일일 마감이 MEMORY.md를 업데이트하지 않으면, 다음 날 세션을 여는 에이전트는 어제 무엇을 했는지 모른다.

방법론 평가가 “컨텍스트가 코드가 아니라 문서에 살아있다”고 표현한 것이 바로 이것이다. Git 저장소의 코드는 “현재 상태”를 말하지만, MEMORY.md와 바이브 로그와 세션 로그는 “여기에 이르기까지의 과정”을 말한다. 에이전트는 그 과정을 읽어야 현재 상태의 의미를 이해한다.

4장. CLAUDE.md 개선 제안 — 에이전트 메모리의 구조화

Insights Report의 가장 실용적인 섹션은 CLAUDE.md 추가 권장 내용이다. 각 항목이 왜 필요한지를 실제 마찰 데이터와 연결해 설명한다.

4.1 Daily Close Procedure

## Daily Close Procedure
When asked to do 'daily close', 'end of day', or 'session close', always:
1) Update session logs
2) Update daily/vibe logs
3) Update MEMORY.md
4) Update PLAN.md
5) git add ALL files including test-results
6) Commit and push to ALL remotes.

이것이 필요한 이유는 15개 이상의 세션에서 이 절차가 반복됐음에도 Claude가 단계를 누락했기 때문이다. 특히 test-results 디렉토리를 커밋에서 제외하거나, 일부 remote에만 push하는 실수가 5회 이상 발생했다. 자연어 지시(“일일 마감 해줘”)만으로는 에이전트가 정확한 절차를 추론하기 어렵다. 명시적 절차가 필요하다.

4.2 Agent Teams 정의

## Agent Teams
This project uses 10+ agent teams (PM, AI Engineer, Designer, QA, Frontend,
Backend, Infra, DevOps, Security, Data). When asked to 'run standup',
'activate all agents', or 'project review with all teams', include ALL
agents -- never omit PM, AI Engineer, or Designer.

이것이 필요한 이유는 바이브 로그의 에피소드로 설명된다. “전체 팀 스탠드업 요청 시 PM, AI Engineer, Designer를 반복 누락”. 에이전트 목록이 CLAUDE.md에 명시되지 않으면, Claude는 “팀”의 범위를 매번 다르게 해석한다.

4.3 Decision Making 가이드라인

## Decision Making
Act autonomously on debugging and fixes -- do not ask the user for direction
when you can diagnose and fix issues yourself. When making architectural
decisions, commit to ONE approach and implement it fully. Do not flip-flop
between approaches.

이것이 필요한 이유는 “잘못된 접근 및 결정 번복” 19건의 근본 원인이기 때문이다. displayName 아키텍처를 4번 다르게 접근한 것은, Claude가 한 접근법을 완전히 구현하기 전에 다른 접근법으로 전환했기 때문이다. “하나의 접근법을 선택하고 완전히 구현하라”는 명시적 지시가 있었다면 다를 수 있었다.

4.4 Custom Skills: `/close`와 `/standup`

Insights Report가 제안하는 Custom Skills는 반복적 작업을 자동화하는 스크립트다. /close 스킬은 일일 마감 절차 전체를 하나의 명령으로 실행하고, /standup 스킬은 10명 에이전트의 상태 보고를 정해진 형식으로 수집한다.

이것의 핵심 가치는 “단계 누락 방지”가 아니라 “인지 부하 감소”다. 개발자가 “일일 마감의 8단계를 모두 기억하고 하나씩 지시”하는 대신 “close”라는 한 단어를 입력하면 된다. 이것이 29%의 문서화 세션을 “기능 작업 끝 2분 커맨드”로 압축할 수 있는 방법이다.

5장. 방법론 평가 — “AI 오케스트레이션 개발”이라는 명명

5.1 바이브 코딩의 정의와 이 프로젝트의 위치

방법론 평가는 Andrej Karpathy의 “바이브 코딩” 정의에서 시작한다. 2025년에 그가 명명한 이 개념의 핵심은 “AI에게 원하는 것을 말하고, 결과를 보고, 다시 말하는 것. 코드를 직접 읽지 않는다”는 것이다.

이 프로젝트는 그 정의의 핵심인 “AI에게 위임하고 결과로 판단한다”는 원칙을 공유하지만, 그 위에 엔지니어링 규율 전체 스택을 얹었다. 방법론 평가의 비교표가 이것을 명확히 보여준다:

전형적 바이브 코딩은 코드 리뷰가 없고, 문서화가 없거나 최소이며, 테스트는 수동 확인으로 이루어지고, 기획이 없거나 막연하다.

RummiArena는 Security 에이전트가 리뷰하고, 85 세션 로그 + 22 스크럼 + 13 바이브 로그의 문서 체계가 있으며, 362 E2E + 611 Unit + 17단계 CI가 있고, 헌장, WBS, 리스크, API 설계가 선행된다.

이것을 방법론 평가는 “AI 오케스트레이션 개발(AI-Orchestrated Development)” 이라고 명명한다. 단순히 AI의 도움을 받아 코드를 쓰는 것이 아니라, AI 에이전트들의 팀을 조직하고 운영하는 것이다.

5.2 “기획 먼저”가 속도를 만들었다

방법론 평가에서 가장 반직관적인 주장이 있다. “코드 0줄, 문서 33개였던 날이 가장 생산적인 날이었다.” 2026-03-14 바이브 로그에서 언급된 이 날은 Sprint 1의 설계 집중일이었다.

이것이 왜 반직관적인가? 일반적으로 개발 생산성은 “얼마나 많은 코드를 썼는가”로 측정된다. 그러나 이 프로젝트에서 코드 없는 날의 투자가 이후의 속도를 만들었다. Sprint 1에서 28 SP(Story Point)를 9일에 완료한 것은 API 스펙, DB ERD, 아키텍처 다이어그램이 이미 완성된 상태에서 에이전트들이 구현에만 집중할 수 있었기 때문이다.

에이전트가 “이 API 엔드포인트는 어떤 파라미터를 받아야 하는가?”를 스스로 결정해야 한다면, 그것을 결정하는 과정에서 시간이 소모되고 일관성이 깨진다. 스펙이 있으면 에이전트는 “이 스펙을 코드로 옮기는 것”에만 집중한다. 명확한 스펙 앞에서 AI는 10배 빠르다.

5.3 품질 게이트가 “바이브”를 “엔지니어링”으로 바꾸는 메커니즘

방법론 평가의 핵심 테제 중 하나가 이것이다. “품질 게이트가 AI가 만든 코드의 신뢰성 문제에 대한 구조적 답이다.”

AI가 생성한 코드의 가장 큰 우려는 “동작하는 것 같은데 실은 망가져 있는” 상태다. 이것을 인간이 리뷰해서 잡으려면 막대한 시간이 든다. 그리고 AI 에이전트가 만든 코드를 그 에이전트 자신이 리뷰하면 같은 오류를 반복해서 놓친다.

RummiArena의 해결책은 게이트를 기계적으로 만드는 것이다. 코드 변경 → 17단계 CI 파이프라인 → 362 E2E 테스트 → SonarQube → Trivy. 이 게이트들은 누가 만든 코드인지 묻지 않는다. 기준을 통과하면 초록, 통과하지 못하면 빨간. AI 코드든 사람 코드든 동일하다.

이것이 “코드가 돌아간다”에서 “코드가 올바르다”로의 전환을 구조적으로 보장하는 방법이다.

5.4 방법론 평가 매트릭스 해설

방법론 평가는 8개 항목에 각각 별점을 부여한다. 가장 높은 5점을 받은 세 항목이 흥미롭다.

생산성(★★★★★): 108 SP / 13일 = 일 8.3 SP. 이것을 “1인 개발 기준 매우 높음”이라고 평가한다. 소프트웨어 공학에서 SP는 작업의 상대적 난이도와 복잡도를 나타내는 단위다. 일반적으로 숙련된 개발자 팀이 스프린트(2주)에 처리하는 SP는 팀 규모와 역량에 따라 다양하지만, 1인이 일 8.3 SP는 비정상적으로 높은 수치다.

학습 속도(★★★★★): “바이브 로그 + 회고 + 결정 로그. 1인인데 조직 학습이 일어남.” 이 평가가 의미 있는 이유는, 조직 학습이 원래 여럿이 하는 것이기 때문이다. 개인의 학습이 누적되면 개인의 역량이 올라간다. 조직의 학습이 누적되면 조직의 역량이 올라간다. 이 프로젝트에서는 1인의 학습이 문서화를 통해 에이전트 팀 전체의 컨텍스트가 됐다. “조직”이 문서 시스템 안에 살아있는 것이다.

혁신성(★★★★★): “AI 에이전트를 ‘팀’으로 운용하는 구조는 선구적.” 이 평가가 현재의 AI 개발 생태계에서 어떤 위치인지를 이해하려면, 지금까지 AI 도구 활용의 일반적 패턴을 봐야 한다. 대부분의 개발자는 AI를 코드 자동완성(GitHub Copilot)이나 채팅 도우미(ChatGPT)로 쓴다. 일부는 Claude Code처럼 파일 수정과 명령 실행을 위임한다. 그 다음 수준에서 여러 에이전트를 역할별로 분화해 팀처럼 운영하는 것은 아직 보편화되지 않은 접근 방식이다.

5.5 방법론이 증명하지 못한 것들: 미해결 질문

방법론 평가의 가장 정직한 섹션이 “미해결 질문”이다. 성과를 설명하는 것보다 한계를 인정하는 것이 더 어렵다.

에이전트의 기억은 어떻게 스케일하는가? MEMORY.md는 200줄 제한이 있다. 프로젝트가 1년이 되면 이 200줄로 1년치 맥락을 압축해야 한다. 어떤 것을 기억하고 어떤 것을 버릴 것인가? 이 선택이 잘못되면 에이전트는 중요한 과거 결정을 모르는 채로 반복 실수를 한다.

에이전트 간 충돌은 어떻게 해결하는가? 현재 구조에서 에이전트 A(Architect)와 에이전트 B(DevOps)가 서로 다른 기술적 방향을 제안하면, 최종 결정은 항상 개발자(인간)가 내린다. 이 병목이 프로젝트 규모와 복잡도가 커지면 한계가 된다. 에이전트들이 서로 토론하고 합의할 수 있는 구조가 필요한 시점이 올 것이다.

“바이브”는 전달 가능한가? 바이브 로그는 개인적 발견의 기록이다. “ASCII 다이어그램은 ‘읽히고’, Mermaid 다이어그램은 ‘보인다’. AI의 인지 부하가 다르다.” 이런 통찰은 이 개발자가 직접 경험하지 않았으면 발견하기 어렵다. 바이브 로그를 읽는 다른 개발자가 이 통찰을 자신의 것으로 만들 수 있는가? 아니면 본질적으로 개인적인 것인가?

6장. 바이브 로그 2026-04-04 — 숫자 너머의 날

6.1 “열 명의 낯선 동료”

바이브 로그의 제목이 인상적이다. “열 명의 낯선 동료.” 1개월 동안 10명의 에이전트와 일했는데, 그들이 아직도 “낯선” 동료라는 것이다.

이것은 AI 에이전트의 특성에 대한 예리한 관찰이다. 인간 동료는 함께 일할수록 서로를 더 잘 알게 된다. 동료의 장점, 약점, 선호하는 방식, 어떤 상황에서 실수하는지를 경험으로 안다. 에이전트는 매 세션마다 새로 시작한다. 1개월을 함께 일했지만, 다음 세션을 시작하는 에이전트는 그 1개월을 기억하지 못한다. “낯선 동료”라는 표현이 이 본질적 비대칭을 정확히 포착한다.

동시에 이 표현에는 따뜻함이 있다. “낯선”이지만 “동료”다. 낯선 사람이 아니라 낯선 동료. 매 세션마다 새로 시작하지만, 그 경험의 누적이 MEMORY.md에 담겨 “동료성”을 만들어간다.

6.2 “구현과 감사의 동시성”

오늘의 핵심 사건은 Rate Limit 구현과 Security 감사가 동시에 이루어진 것이다. Go Dev가 rate_limiter.go를 작성하는 동안 Security가 같은 코드베이스를 감사했다. 결과적으로 Security가 발견한 것은 단순한 Rate Limit 구현의 버그가 아니라 더 근본적인 공격 벡터였다.

Security 에이전트의 발견: “Claude는 턴당 $0.074입니다. Rate Limit만으로는 충분하지 않아요. 5분이면 하루 API 예산이 다 날아갑니다.”

이 발견이 중요한 이유를 이해하려면 LLM 비용 공격 벡터를 알아야 한다. 악의적 사용자가 게임 서버에 AI 플레이어를 상대로 빠른 속도로 게임을 시작하면, 각 게임 턴마다 Claude API가 호출된다. Rate Limit이 “분당 10 요청”으로 설정되어 있더라도, 그 10 요청이 각각 Claude 호출이면 분당 $0.74(= 10 × $0.074)가 소모된다. 하루 예산을 초과하는 데 5분도 걸리지 않는다.

기존 서버 API의 Rate Limit은 “트래픽 과부하”를 막기 위한 것이었다. LLM이 통합된 서버에서는 추가로 “비용 공격”을 막는 개념이 필요하다. 이것이 2중 방어(쿨다운 + 시간당 한도)를 추가하게 된 배경이다.

이 발견이 “구현 완료 전에” 이루어진 것이 핵심이다. PR이 올라간 후 코드 리뷰에서 발견됐다면, 수정하고 재배포하는 추가 사이클이 필요했다. 구현과 동시에 감사가 이루어졌기 때문에 즉시 설계를 바꿀 수 있었다.

6.3 Gritling과 소스맵 유출 사건: 세상은 연결되어 있다

바이브 로그에서 가장 독특한 에피소드가 이 부분이다. 스크럼에서 Claude Code의 /buddy 기능(Gritling이라는 버섯 펫)을 주제로 이야기하다가, 그 출신인 소스맵 유출 사건을 파헤치다가, 우리 프로젝트의 보안 구멍을 발견했다.

이 연결 고리를 이해하려면 먼저 Claude Code 소스맵 유출 사건을 알아야 한다.

2026년 3월 31일, Anthropic 소스맵 유출 사건

Anthropic의 공식 npm 패키지인 Claude Code v2.1.88에 소스맵 파일(.map)이 포함됐다. 이 파일은 번들된 코드를 원본 소스코드로 역추적하는 디버깅 도구인데, 배포 패키지에 포함되어서는 안 되는 것이었다. 약 512,000줄의 난독화되지 않은 TypeScript가 1,906개 파일에 걸쳐 노출됐다.

Anthropic은 “이것은 인간의 실수로 발생한 릴리즈 패키징 이슈이며 보안 침해가 아니다. 고객 데이터나 자격 증명은 노출되지 않았다”고 확인했다.

유출된 코드 안에 숨겨진 것이 있었다. 터미널 안에 살아있는 다마고치 스타일의 동반자 시스템인 “Buddy”였다. 18개의 펫 종류(오리, 드래곤, 카피바라, 청크 등)와 게임처럼 희귀도 시스템이 있다.

Anthropic은 이것을 4월 1일 만우절 이스터 에그로 공개할 예정이었다. 유출로 인해 당일 레인보우 알림이 /buddy를 입력하라고 했을 때, 많은 개발자들은 이미 소스코드를 봐서 무슨 일이 일어날지 알고 있었다.

각 사용자의 userId 해시에 기반한 결정론적 알고리즘으로 펫이 배정된다. 솔트 값 friend-2026-401은 April 1, 2026을 가리킨다.

개발자는 이 “Gritling”(버섯 buddy의 별명)의 출신 이야기를 팀 스크럼에서 나눴다. 그리고 소스맵 유출이 어떻게 발생했는지를 파악하다가 자신의 프로젝트를 돌아봤다. RummiArena의 ai-adapter(TypeScript로 작성된 AI 통신 레이어)에 tsconfig.build.json에 sourceMap: true 설정이 그대로 있었던 것이다.

소스맵이 true이면 빌드 시 .map 파일이 생성된다. 이 파일이 .dockerignore나 Docker 이미지 빌드 과정에서 제외되지 않으면, 최종 Docker 이미지에 소스맵이 포함된다. 그 이미지가 레지스트리에 push되고 프로덕션에 배포된다면, 공격자가 컨테이너 내부에 접근했을 때 TypeScript 원본 소스를 재구성할 수 있다.

Anthropic이 한 실수를 자신의 프로젝트에서 반복하고 있었다. 그것을 발견한 경로가 “가상 버섯 펫의 출신 이야기”였다. “세상은 연결되어 있다”는 원문의 마무리가 이 맥락에서 읽히면 단순한 수사가 아님을 알 수 있다.

6.4 오늘의 진짜 산출물: 방법의 검증

바이브 로그는 오늘의 숫자들(+9,239줄, +100 테스트, 보안 P0 해결)보다 더 중요한 것을 진짜 산출물로 꼽는다. “10명 동시 투입 → P0 발견 → 즉시 재투입 → 당일 해결이라는 사이클이 작동했다는 경험.”

이것이 왜 더 중요한가? 코드는 낡아진다. 오늘 쓴 9,239줄은 내년에 상당 부분 교체되거나 삭제될 것이다. 하지만 이 사이클이 작동한다는 경험, 그것이 재현 가능한 방법이라는 확신은 다음 프로젝트에서도, 그 다음 프로젝트에서도 쓸 수 있다.

방법론 평가의 최종 평가가 이것을 수렴한다. “108 SP를 13일에 완료한 생산성, 362 E2E + 17단계 CI의 품질 게이트, Sprint 100% 완료율 — 이 숫자들은 인상적이지만, 더 중요한 것은 이것이 재현 가능한 구조라는 점이다.”

7장. 미래 전망: 자율 에이전트로의 진화

7.1 Self-Healing CI/CD Pipeline Agent

Insights Report가 제안하는 미래 방향 중 첫 번째는 자기 수복 CI/CD 파이프라인이다. 파이프라인이 실패하면 에이전트가 자동으로 로그를 읽고, 원인을 진단하고, 수정을 적용하고, 다시 파이프라인을 트리거하는 루프를 돌린다.

이것이 현재 워크플로우와 어떻게 다른가? 현재는 파이프라인이 실패하면 개발자가 알림을 받고, 로그를 열어 읽고, 원인을 파악하고, 수정 코드를 작성하고, 커밋하고, 파이프라인을 다시 돌린다. 이 과정에서 개발자의 개입이 필수적이다. Self-Healing 에이전트는 이 루프에서 개발자를 제거한다.

물론 한계가 있다. 에이전트가 스스로 해결할 수 없는 근본적인 설계 문제가 있을 수 있다. 에이전트가 잘못된 방향으로 무한 루프를 돌 수 있다. 그래서 “5 fix cycles”라는 제한이 있다. 5번 시도해도 안 되면 에이전트는 멈추고 개발자에게 보고한다.

7.2 병렬 에이전트 팀과 충돌 없는 머지

두 번째 방향은 명시적 에이전트 계약과 공유 컨텍스트 파일을 통한 진정한 병렬 작업이다. 각 에이전트가 담당 디렉토리/파일만 수정하고, 상태를 공유 파일에 기록하며, 작업 완료 전에 테스트를 통과해야 한다는 계약이다.

이것이 현재의 에이전트 팀과 어떻게 다른가? 현재는 에이전트들이 순차적으로 투입되거나, 병렬로 투입되더라도 같은 파일을 동시에 수정할 위험이 있다. 명시적 계약이 있으면 충돌을 예방할 수 있다.

7.3 테스트 주도 자율 버그 수정 루프

세 번째 방향은 테스트 실패 → 원인 파악 → 수정 → 재실행의 루프를 완전 자동화하는 것이다. “80건 실패 → 0건 해결, 153 → 338 E2E 테스트”를 fire-and-forget 방식으로 전환하는 것이다.

이것이 제대로 작동하려면 에이전트가 “cascade failure(연쇄 실패)”를 식별할 수 있어야 한다. 하나의 핵심 버그가 수십 개의 테스트 실패로 이어지는 경우, 에이전트는 수십 개를 각각 고치려 하지 말고 근본 원인 하나를 찾아 고쳐야 한다. 이 진단 능력이 이 루프의 핵심이다.

8장. 기술 심화: Claude Code 소스맵 유출과 빌드 파이프라인 보안

8.1 소스맵이란 무엇인가

소스맵(.map 파일)은 브라우저와 개발 도구가 압축/번들된 코드를 원본 소스코드로 역추적할 수 있게 해주는 파일이다. TypeScript로 작성된 코드를 Webpack이나 esbuild로 빌드하면 읽기 어려운 JavaScript가 된다. 크래시가 발생하면 어떤 TypeScript 파일의 어느 줄에서 문제가 발생했는지 추적하기 어렵다. 소스맵이 이 매핑을 담는다.

소스맵은 개발 환경과 디버깅에 필수적이지만, 배포 패키지에는 포함되어서는 안 된다. 포함되면 누구나 원본 TypeScript 소스코드를 복원할 수 있다. 이것이 Anthropic의 경우 Bun이 기본적으로 소스맵을 생성하는데, 릴리즈 팀에서 .npmignore에 *.map을 추가하거나 package.json의 files 필드를 설정해 배포 아티팩트에서 제외하는 것을 누락했다.

8.2 TypeScript 빌드 설정에서 소스맵 관리

tsconfig.build.json의 sourceMap: true 설정이 문제였다. TypeScript 빌드 설정에서 소스맵은 다음과 같이 제어된다:

tsconfig.json에 "sourceMap": true → 개발 빌드에서 소스맵 생성 (필수)
tsconfig.build.json에 "sourceMap": false → 프로덕션 빌드에서 소스맵 미생성 (권장)

RummiArena의 ai-adapter에서 tsconfig.build.json에 sourceMap: true가 있었다는 것은, 프로덕션 빌드에서도 소스맵이 생성됐다는 의미다. 이 파일이 Docker 이미지에 포함됐다면, 이미지에 접근하는 누구나 원본 TypeScript 소스를 역추적할 수 있었다.

Security 에이전트가 이것을 발견한 것이 “보안 감사가 없었으면 영원히 모를 뻔했다”는 진술의 근거다.

8.3 LLM 비용 공격 벡터와 2중 방어

LLM을 통합한 서버의 Rate Limit은 전통적인 서버의 Rate Limit과 다른 차원의 보호가 필요하다.

전통적 서버: Rate Limit은 “서버 리소스 보호”가 목적. 분당 100 요청을 처리하는 서버라면, 100을 초과하면 429(Too Many Requests)를 반환.

LLM 통합 서버: Rate Limit은 추가로 “API 비용 보호”가 필요. 분당 10 요청 제한이 있어도, 10 요청이 모두 LLM API 호출이면 분당 $0.74(Claude $0.074/turn × 10)가 소모된다.

RummiArena의 해결책인 2중 방어는 다음과 같다:

쿨다운: 각 AI 플레이어의 턴 사이에 최소 대기 시간을 부여. 인간이 생각하고 행동하는 속도보다 빠른 요청을 차단.
시간당 한도: 사용자당, 게임당 시간당 AI 호출 횟수의 절대 한도. 이 한도에 도달하면 AI가 기본 응답(draw 타일)을 반환하도록 폴백.

LLM 인프라에서 전통적인 초당 요청 수 기반의 Rate Limit은 충분하지 않다. LLM은 토큰 기반이고 연산 부하가 매우 가변적이다. 현대 LLM 게이트웨이는 실제 처리된 토큰 수와 연산 부담을 고려한 토큰 인식 Rate Limit을 채택해야 한다.

9장. 방법론 평가가 말하는 더 큰 그림

9.1 “한 명이 열 명을 지휘하는 법을 발명한 것이다”

방법론 평가의 마지막 문장이 이 프로젝트 전체를 요약한다. “한 명이 열 명의 일을 한 것이 아니다. 한 명이 열 명을 지휘하는 법을 발명한 것이다.”

이 구분이 중요한 이유는, 단순히 생산성의 문제가 아니기 때문이다. 열 명의 일을 혼자 하는 것은 과로다. 열 명을 지휘하는 법을 발명하는 것은 시스템 설계다. 전자는 지속 불가능하고, 후자는 확장 가능하다.

CLAUDE.md, 에이전트 역할 정의, 커맨드/스킬 체계, 의식(ritual) 시스템, MEMORY.md 아키텍처 — 이것들이 모두 “지휘 체계”의 구성요소다. 이 체계가 문서화되고 코드화됐기 때문에, 다른 개발자가 이것을 가져가서 자신의 프로젝트에 적용할 수 있다. 재현 가능성이 방법론의 핵심이다.

9.2 AI 코파일럿과 AI 팀원의 차이

방법론 평가는 GitHub Copilot이나 Cursor 같은 “코파일럿”과 이 프로젝트의 AI 에이전트를 구분한다. 코파일럿은 개발자의 속도를 높인다. 팀원은 개발자의 시야를 넓힌다.

이 구분을 이날의 사례로 보면 더 명확하다. Security 에이전트가 발견한 “Claude $0.074/턴, 5분이면 하루 예산 소진” 공격 벡터는 개발자의 속도를 높인 것이 아니다. 개발자가 보지 못했던 위험을 보여준 것이다. 코파일럿은 이것을 못 한다. 코파일럿은 개발자가 이미 생각하는 것을 더 빠르게 쓸 수 있게 해주지만, 개발자가 생각하지 않는 것을 먼저 생각하지는 않는다.

팀원은 다른 관점을 가져온다. Security 에이전트가 “보안 관점”을, QA 에이전트가 “품질 관점”을, Designer 에이전트가 “UX 관점”을 가져온다. 이 관점들이 개발자가 혼자서는 충분히 보지 못하는 것들을 보게 해준다.

9.3 제약이 설계를 강제한다

방법론 평가가 증명한 역설 중 하나가 “제약이 더 나은 아키텍처를 만들었다”는 것이다. 16GB RAM, $5 일일 API 한도, 싱글 노드 K8s라는 제약들이 다음을 강제했다.

RAM 부족은 Stateless 서버를 강제했다. 서버가 상태를 메모리에 보관하지 않고 Redis에 외부화한다. 이것이 이후 수평 확장(Horizontal Scaling)을 가능하게 만드는 아키텍처 결정이다.

API 비용 제한은 모델 비용 비교 실험을 동기부여했다. 결과적으로 DeepSeek($0.001/턴)이라는 GPT($0.025/턴) 대비 25배 저렴한 선택지를 발견했다.

싱글 노드 K8s는 Helm 차트 최적화와 ResourceQuota 정밀 관리를 강제했다. 리소스가 충분하면 대충 설정해도 돌아가지만, 싱글 노드에서는 모든 Pod의 리소스 할당이 정밀해야 한다.

“무한한 리소스는 나쁜 설계를 허용한다.” 이것은 소프트웨어 공학의 오래된 지혜다. 제약이 없으면 최적화의 필요성을 느끼지 못한다.

맺음말: 1개월의 실험이 남긴 것

4월 4일의 세 문서 — Insights Report, 방법론 평가, 바이브 로그 — 는 1개월의 실험을 다른 각도에서 기록한다.

수치로 보면 48세션, 897메시지, 96시간, 110커밋, +18,372라인, 362개 E2E 테스트, 17단계 CI가 됐다.

방법론으로 보면 “AI 오케스트레이션 개발”이라는 이름을 얻었다. 바이브 코딩의 위임 정신과 엔지니어링 규율의 품질 의지가 결합한 새로운 형태다.

경험으로 보면 “열 명의 낯선 동료”와 함께 일한 1개월이었다. 그들은 매 세션마다 새로 태어나고, 좌절하지 않으며, 개발자가 보지 못하는 것을 본다. 그리고 P0 보안 취약점을 발견하는 가장 이상한 경로가 “가상 버섯 펫의 출신 이야기”일 때, 세상은 정말로 연결되어 있다는 것을 느끼게 한다.

내일은 DeepSeek Round 4다. 프롬프트 최적화가 무효율을 55%에서 25%로 줄이는지 확인할 차례다. 숫자가 말해줄 것이다. 방법이 남는다.

이 해설 문서는 Claude Code Insights Report, RummiArena 방법론 평가, 바이브 로그 2026-04-04를 기반으로, Anthropic Claude Code npm 소스맵 유출 사건(2026-03-31), Claude /buddy 기능, LLM 비용 공격 벡터와 Rate Limiting 전략, AI 오케스트레이션 개발론 등 최신 기술 정보를 포함해 작성되었습니다.

AI, RummiArena

AI insights-report CLAUDE.md agent-teams decision-making agent-skills ai-orchestrated-development MEMORY.md claude-code-source-leak source-map Anthropic Buddy self-healing Claude.write