CLI 레벨 AI 에이전트 자동화 시스템 구축 가이드

게시 2026/01/04 업데이트 2026/01/05

By BLUEBUG

74 분읽는 시간

Claude Code 창시자 Boris Cherny의 Subagent 패턴을 실전에 적용하기

들어가며: 우연한 발견이 만든 혁신

2026년 1월, 한 개발자가 흥미로운 실험을 시작했습니다. Codex와 Claude를 CLI 레벨에서 번갈아 호출하여 한 에이전트는 리뷰만, 다른 에이전트는 개발만 담당하게 하는 것이었죠. 두 AI 간의 커뮤니케이션은 놀랍게도 Git 커밋 메시지를 통해 이루어졌습니다.

이 방식은 언뜻 보기에 단순해 보이지만, 실은 Anthropic의 Claude Code 창시자 Boris Cherny가 2025년 공개한 “Subagent 패턴”과 정확히 같은 원리를 따르고 있었습니다. 더 흥미로운 점은, Git 커밋 메시지를 커뮤니케이션 레이어로 사용한다는 아이디어가 Boris의 원래 방식보다 더 영리하다는 것입니다.

이 문서는 그 개발자의 실험 과정과 인사이트, 그리고 Boris Cherny가 공개한 Claude Code 내부 베스트 프랙티스를 결합하여, 실전에서 바로 활용할 수 있는 CLI 레벨 AI 에이전트 자동화 시스템 구축 방법을 제시합니다.

Chapter 1: 원본 아이디어 - 실험의 시작

최초의 발상

개발자는 간단한 질문에서 시작했습니다. “내가 매번 인터랙티브 모드에서 AI에게 요청을 하는 대신, AI들끼리 알아서 일하게 할 수는 없을까?”

이 질문은 다음과 같은 아이디어로 구체화되었습니다:

핵심 컨셉:

Codex: 리뷰만 담당
Claude: 개발만 담당
커뮤니케이션: Git 커밋 메시지

구현 방식:

API 레벨이 아닌 CLI 레벨에서 호출
이미 돈을 내고 있는 CLI 도구 활용 (Cursor Pro $20, Claude Code $20)
별도의 API 비용 없음

왜 이 방식이 매력적인가?

1. 비용 효율성

기존 API 방식:

  
# 매번 토큰 계산
import anthropic

client = anthropic.Anthropic(api_key="...")
response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=4000,
    messages=[{"role": "user", "content": "코드 리뷰해줘"}]
)
# 비용: 입력 $3/1M 토큰, 출력 $15/1M 토큰
# 복잡한 리뷰 1회 = 약 $0.50
# 하루 10번 = $5
# 월 100번 = $150

CLI 방식:

  
# 이미 구독 중인 도구 활용
codex --effort high "코드 리뷰해줘"
# 비용: 월 $20 고정 (거의 무제한)
# 하루 100번 써도 $20

2. 간편성

개발자는 복잡한 API 호출 코드를 작성할 필요가 없습니다. 이미 최적화된 CLI 도구들이 다음을 자동으로 처리합니다:

컨텍스트 관리 (어떤 파일이 관련있는지)
에러 핸들링 (실패 시 자동 재시도)
토큰 최적화 (불필요한 내용 자동 제거)
출력 포맷팅 (읽기 쉬운 형태로)

3. 제어 가능성

API 기반 도구들은 종종 “블랙박스”처럼 작동합니다. 무엇을 어떻게 하는지 정확히 알기 어렵죠. 하지만 CLI 방식은:

각 단계가 명확함
중간 과정 확인 가능
필요하면 언제든 수동 개입 가능
쉘 스크립트로 커스터마이징 자유로움

초기 기대와 실제

기대했던 것:

“와, 이제 AI가 알아서 다 하겠네!”
“나는 그냥 결과만 확인하면 되겠다”
“개발 속도가 10배는 빨라지겠지?”

실제로 만들면서 느낀 것:

“결국 프롬프트를 어떻게 잘 쓰느냐의 문제네”
“AI가 프롬프트대로 동작을 해주느냐는 여전히 숙제”
"’다시 해봐’를 반복하는 걸 자동화하는 것만으로도 큰 가치”

이 현실적인 인식이 중요합니다. AI 에이전트는 만능이 아닙니다. 하지만 반복적인 작업을 자동화하고, 피드백 루프를 빠르게 돌리는 것만으로도 엄청난 생산성 향상을 가져올 수 있습니다.

Chapter 2: Boris Cherny의 Subagent 패턴

Claude Code 내부에서 실제로 사용하는 방법

Boris Cherny는 2025년 9월부터 10월 사이, 여러 팟캐스트와 Anthropic 공식 블로그를 통해 Claude Code 팀이 내부적으로 사용하는 Subagent 패턴을 공개했습니다. 이는 한 개발자가 독립적으로 발견한 방법과 놀라울 정도로 유사했습니다.

코드 리뷰 워크플로우 - Boris의 실제 사례

Boris Cherny는 Every.to 팟캐스트에서 자신의 코드 리뷰 프로세스를 상세히 공개했습니다:

1단계: 첫 번째 Subagent 그룹 (병렬 실행)

  
# Boris는 동시에 여러 Claude 인스턴스를 실행합니다
# 각자 독립적인 작업 수행

# Subagent 1: 스타일 가이드 체크
claude --context style_guide.md "
이 코드가 우리 스타일 가이드를 따르는지 확인해줘.
위반 사항을 구체적으로 나열해줘.
"

# Subagent 2: 프로젝트 히스토리 분석  
claude --context git_history "
과거 6개월간 비슷한 기능이 어떻게 구현됐는지 분석해줘.
일관성 있는지 확인해줘.
"

# Subagent 3: 명백한 버그 탐지
claude "
이 코드에서 명백한 버그를 찾아줘:
- Null pointer
- Race condition
- Memory leak
- SQL injection
"

각 Subagent는 독립적으로 실행되며, 약 30초 안에 결과를 반환합니다. 만약 이를 순차적으로 실행했다면 1분 30초가 걸렸을 작업이 30초로 단축됩니다.

2단계: 두 번째 Subagent 그룹 (검증 및 챌린지)

첫 번째 그룹이 발견한 이슈들을 모아서, 이번에는 다섯 개의 Subagent가 이를 검증합니다:

  
# 첫 번째 그룹의 결과를 파일로 저장
cat > initial_findings.txt <<EOF
스타일 위반: 15건
히스토리 불일치: 3건
버그 가능성: 8건
EOF

# 두 번째 그룹: 각 발견사항에 대해 반박 시도
for i in {1..5}; do
    claude "
    다음 이슈가 진짜 문제인지 검증해줘:
    $(cat initial_findings.txt)
    
    각 이슈에 대해:
    - 진짜 문제면: CONFIRM
    - 오탐(false positive)이면: REJECT + 이유
    " > validation_$i.txt &
done

wait  # 모든 Subagent 완료 대기

# 결과 집계
# 5개 중 3개 이상이 CONFIRM하면 진짜 이슈로 확정

최종 결과:

Boris는 이렇게 말합니다:

“결과가 정말 훌륭합니다(awesome). 모든 진짜 이슈를 찾아내면서도, 거짓 경보는 하나도 없습니다.”

이 방식의 핵심은 AI가 AI를 검증한다는 점입니다. 한 AI의 판단을 맹신하지 않고, 여러 AI의 교차 검증을 통해 정확도를 높입니다.

Subagent 간 커뮤니케이션 - Scratchpad 방식

Boris는 Anthropic 공식 블로그 “Claude Code Best Practices”에서 Subagent 간 커뮤니케이션 방법을 공개했습니다:

  
# Subagent들에게 각자의 작업 공간 할당

# Subagent A: 개발자 역할
claude "
당신은 개발자입니다.
작업 결과는 dev_scratchpad.md에 작성하세요.
리뷰어의 피드백은 review_scratchpad.md를 읽으세요.
" &

# Subagent B: 리뷰어 역할
claude "
당신은 리뷰어입니다.
개발 결과는 dev_scratchpad.md를 읽으세요.
리뷰 결과는 review_scratchpad.md에 작성하세요.
" &

각 Subagent는:

읽을 파일: 다른 Subagent가 쓴 파일
쓸 파일: 자신의 전용 파일

이렇게 하면 Subagent들이 서로의 작업을 방해하지 않으면서도 협업할 수 있습니다.

Git 커뮤니케이션의 우수성

원래 개발자의 아이디어는 Boris의 Scratchpad 방식보다 한 단계 더 나아갔습니다. Git 커밋 메시지를 커뮤니케이션 레이어로 사용한 것이죠.

왜 Git 커밋이 더 나은가?

Boris 방식 (Scratchpad):

dev_scratchpad.md (개발자가 씀)
review_scratchpad.md (리뷰어가 씀)

장점: 명확한 역할 분리
단점: Git 히스토리와 별개, 수동 관리 필요

Git 커밋 방식:

  
# Claude가 개발 후 커밋
git commit -m "feat: 사용자 로그인 API 구현
- JWT 토큰 발급
- Redis 세션 저장
- 비밀번호 BCrypt 암호화"

# Codex가 최신 커밋 메시지 읽고 리뷰
LAST_COMMIT=$(git log -1 --pretty=%B)
codex "커밋: $LAST_COMMIT 을 리뷰해줘"

# Codex 리뷰 결과도 커밋
git commit -m "review: 보안 이슈 3건 발견
- SQL Injection 가능성 (line 45)
- XSS 취약점 (line 67)
- Rate limiting 없음"

# Claude가 리뷰 커밋 읽고 수정
REVIEW_COMMIT=$(git log -1 --pretty=%B)
claude "리뷰 결과: $REVIEW_COMMIT 를 보고 수정해줘"

이 방식의 장점:

자연스러운 작업 단위
- Git 커밋은 이미 “의미있는 작업 단위”
- 별도로 작업 범위를 정의할 필요 없음
자동 히스토리 추적
- 누가, 언제, 무엇을, 왜 했는지 모두 기록됨
- git log --oneline --grep "review:" 로 모든 리뷰 추적 가능
롤백이 쉬움
- AI가 잘못 수정했다? git revert
- 특정 시점으로 돌아가기? git reset --hard
팀 협업 자연스러움
- 팀원이 “AI가 뭘 했지?” 궁금하면 → git log 보면 됨
- Code Review 플랫폼(GitHub PR)에 자동 통합
비용 효율
- Git은 무료
- Scratchpad 파일 관리 코드 불필요

Chapter 3: 실전에서 발견한 핵심 인사이트

인사이트 1: “결국 프롬프트 품질 문제”

개발자가 시스템을 만들면서 가장 먼저 깨달은 것은 “AI에게 무엇을 어떻게 요청하느냐가 결과의 90%를 결정한다”는 사실이었습니다.

아무리 자동화 시스템을 잘 만들어도, 프롬프트가 엉망이면 결과도 엉망입니다. 마치 훌륭한 요리사에게 “대충 맛있게 해주세요”라고 주문하는 것과 같습니다.

나쁜 프롬프트 예시:

claude "이 코드 고쳐줘"

결과: AI는 무엇을 고쳐야 할지 모름. 랜덤하게 스타일만 바꾸거나, 아예 엉뚱한 부분을 수정.

좋은 프롬프트 예시:

claude "
이 코드의 성능을 개선해줘.

현재 문제:
- N+1 쿼리 발생 (line 23-45)
- 메모리 누수 가능성 (line 67)

목표:
- 쿼리를 JOIN 1개로 통합
- 사용 후 리소스 해제 추가

제약:
- 기존 API 인터페이스 유지
- 하위 호환성 보장
"

결과: AI가 정확히 무엇을 해야 할지 알고, 구체적으로 개선.

Anthropic 내부에서도 같은 고민

Boris Cherny는 Anthropic 공식 블로그에서 이렇게 밝혔습니다:

“Anthropic에서는 CLAUDE.md 파일을 정기적으로 Prompt Improver에 넣어서 개선합니다. 그리고 중요한 지시사항에는 ‘IMPORTANT’나 ‘YOU MUST’ 같은 강조를 추가하여 준수율을 높입니다.”

즉, AI 도구를 만드는 회사조차도 AI에게 제대로 지시하는 것이 어렵다는 뜻입니다.

실전 해결책: CLAUDE.md 진화

개발자는 실패할 때마다 CLAUDE.md에 규칙을 추가하는 전략을 사용했습니다:

  
# CLAUDE.md (버전 1.0 - 첫날)
- Java 8 사용
- Spring Boot 2.x

  
# CLAUDE.md (버전 2.0 - 1주 후)
- Java 8 사용
- Spring Boot 2.x
- IMPORTANT: Oracle 11g 사용 (MySQL 문법 절대 금지)
  - WRONG: LIMIT 10
  - RIGHT: WHERE ROWNUM <= 10

  
# CLAUDE.md (버전 3.0 - 1개월 후)
- Java 8 사용
- Spring Boot 2.x
- IMPORTANT: Oracle 11g 사용
  - WRONG: LIMIT 10
  - RIGHT: WHERE ROWNUM <= 10

- YOU MUST: 모든 API에 예외 처리 필수
  - Bad: throw new Exception()
  - Good: throw new CustomBusinessException()

- NEVER: System.out.println() 사용 금지
  - ALWAYS: logger.debug() 사용

1개월이 지나자 CLAUDE.md는 100줄이 넘었고, AI의 실수는 80% 이상 줄었습니다.

인사이트 2: “CLI 레벨이 API보다 스마트함”

많은 개발자들이 “AI 에이전트 만들기 = API 호출”이라고 생각합니다. 하지만 실제로는 CLI 도구를 활용하는 것이 훨씬 효율적입니다.

API 방식의 현실:

  
import anthropic
import time
import json

client = anthropic.Anthropic(api_key="sk-...")

def ask_claude(prompt, max_retries=3):
    """Claude API 호출 with 재시도 로직"""
    for attempt in range(max_retries):
        try:
            response = client.messages.create(
                model="claude-sonnet-4-5",
                max_tokens=4000,
                messages=[{
                    "role": "user",
                    "content": prompt
                }]
            )
            
            # 토큰 사용량 계산
            input_tokens = response.usage.input_tokens
            output_tokens = response.usage.output_tokens
            cost = (input_tokens * 0.000003 + 
                    output_tokens * 0.000015)
            
            print(f"비용: ${cost:.4f}")
            
            return response.content[0].text
            
        except anthropic.RateLimitError:
            if attempt < max_retries - 1:
                wait_time = 2 ** attempt  # 지수 백오프
                print(f"Rate limit. {wait_time}초 대기...")
                time.sleep(wait_time)
            else:
                raise
                
        except anthropic.APIError as e:
            print(f"API 에러: {e}")
            if attempt < max_retries - 1:
                time.sleep(1)
            else:
                raise

# 컨텍스트 관리도 직접
def get_relevant_files(query):
    """관련 파일 찾기 (직접 구현 필요)"""
    # 이것도 복잡한 로직...
    pass

# 사용
result = ask_claude("코드 리뷰해줘")

이 코드는 100줄이 넘습니다. 그리고:

에러 핸들링 직접 구현
토큰 사용량 추적 직접 구현
비용 계산 직접 구현
컨텍스트 관리 직접 구현
Rate limit 대응 직접 구현

CLI 방식의 현실:

claude "코드 리뷰해줘"

끝. 단 한 줄입니다.

왜냐하면 Claude CLI는 이미 다음을 자동으로 처리하기 때문입니다:

✅ 에러 발생 시 자동 재시도
✅ 관련 파일 자동 탐지 (컨텍스트 관리)
✅ 토큰 최적화 (불필요한 내용 제거)
✅ 출력 포맷팅 (컬러, 마크다운 렌더링)
✅ 히스토리 관리 (이전 대화 기억)
✅ 비용 걱정 없음 (월 $20 고정)

비용 비교

실제 프로젝트에서 하루 동안 사용한 예시:

API 방식:

아침 9시: 기능 구현 요청 (10,000 토큰) = $0.15
오전 10시: 버그 수정 (8,000 토큰) = $0.12
오전 11시: 코드 리뷰 (15,000 토큰) = $0.22
점심 후 2시: 리팩토링 (20,000 토큰) = $0.30
오후 4시: 테스트 코드 (12,000 토큰) = $0.18
오후 5시: 문서화 (7,000 토큰) = $0.10

일일 총 비용: $1.07
월 비용 (22일): $23.54

CLI 방식 (Claude Code Pro $20):

하루 종일 무제한 사용
월 비용: $20 (고정)

하루에 단 몇 번만 써도 CLI가 이득입니다. 그런데 현실에서는 하루에 수십 번 씁니다.

제어 가능성

API는 종종 블랙박스입니다. 무슨 일이 일어나는지 모릅니다. 하지만 CLI는:

  
# 디버그 모드로 실행
claude --debug "기능 구현해줘"

# 출력:
# [DEBUG] 관련 파일 탐지: 3개
# [DEBUG] - src/main/User.java
# [DEBUG] - src/test/UserTest.java  
# [DEBUG] - config/application.yml
# [DEBUG] 컨텍스트 크기: 45,231 토큰
# [DEBUG] 최적화 후: 12,456 토큰 (72% 감소)
# [DEBUG] 모델: claude-sonnet-4-5
# [DEBUG] 예상 응답 시간: 8초

# ... 실제 작업 ...

# [DEBUG] 완료. 소요 시간: 9.2초

무슨 일이 일어나는지 다 보입니다. 문제가 있으면 정확히 어디서 발생했는지 알 수 있습니다.

인사이트 3: “에이전트 위에 에이전트…”

개발자가 시스템을 만들면서 재미있는 현상을 발견했습니다. 에이전트가 계층적으로 쌓인다는 것이죠.

┌─────────────────────────────────┐
│  당신의 자동화 스크립트           │  ← Layer 4
│  (Claude + Codex 오케스트레이션) │
└─────────────────────────────────┘
           ↓
┌─────────────────────────────────┐
│  Claude Code CLI                │  ← Layer 3
│  (Subagent 시스템 내장)         │
└─────────────────────────────────┘
           ↓
┌─────────────────────────────────┐
│  Claude 4 Subagents             │  ← Layer 2
│  (Explore, Plan, Task, Test)    │
└─────────────────────────────────┘
           ↓
┌─────────────────────────────────┐
│  Claude 4 Base Model            │  ← Layer 1
└─────────────────────────────────┘

이게 왜 중요한가?

각 계층은 추상화 레벨을 높입니다:

Layer 1 (Base Model):

입력: "사용자 로그인 기능"
출력: 코드 조각 (컨텍스트 없음)

Layer 2 (Subagents):

Explore Agent: "프로젝트 구조 파악"
Plan Agent: "구현 계획 수립"
Task Agent: "실제 코드 작성"
Test Agent: "테스트 코드 생성"

Layer 3 (Claude Code CLI):

입력: "로그인 기능 구현해줘"
출력: 완성된 PR (코드 + 테스트 + 문서)

Layer 4 (당신의 자동화):

입력: "로그인 기능"
과정: 
  1. Claude가 구현
  2. Git 커밋
  3. Codex가 리뷰
  4. 이슈 발견 시 Claude가 수정
  5. 재리뷰
  6. 통과 시 PR 자동 생성
출력: 검증된 프로덕션 코드

Anthropic 내부도 같은 구조

Boris Cherny는 팟캐스트에서 이렇게 말했습니다:

“Claude Code의 80-90%는 Claude Code로 만들어졌습니다. 어떤 팀은 90% 이상이 AI가 작성했죠.”

즉, AI가 AI를 만들고, 그 AI가 다시 AI를 만들고… 이런 식입니다.

이게 정상인가?

네, 정상입니다. 소프트웨어 개발은 원래 이렇습니다:

고급 언어 (Python)
  ↓ 컴파일러
중급 언어 (C)
  ↓ 컴파일러
저급 언어 (Assembly)
  ↓ 어셈블러
기계어 (0101...)

AI 에이전트도 마찬가지로 추상화 계층을 쌓는 것뿐입니다. 각 계층은 그 아래 계층의 복잡성을 숨기고, 더 높은 수준의 작업을 가능하게 합니다.

Chapter 4: 실전 구현 가이드

기본 구조 - 최소 실행 가능한 시스템

가장 간단한 형태부터 시작하겠습니다. 복잡한 것은 나중에 추가할 수 있습니다.

Version 1.0: 기본 루프

  
#!/bin/bash
# auto-dev.sh

TASK=$1

if [ -z "$TASK" ]; then
    echo "사용법: ./auto-dev.sh '기능 설명'"
    exit 1
fi

echo "=== Step 1: Claude 개발 ==="
claude "$TASK 기능을 구현해줘.
완료되면 자동으로 git commit 해줘.
커밋 메시지는 Conventional Commits 형식으로.
"

# Claude가 커밋했는지 확인
if [ $? -eq 0 ]; then
    echo "✓ 개발 완료"
    
    # 최신 커밋 메시지 가져오기
    COMMIT_MSG=$(git log -1 --pretty=%B)
    
    echo "=== Step 2: Codex 리뷰 ==="
    codex --effort high "
    다음 커밋을 리뷰해줘:
    $COMMIT_MSG
    
    변경 내용:
    $(git show HEAD)
    
    체크 항목:
    - 보안 취약점
    - 성능 이슈
    - 버그 가능성
    - 코딩 규칙 위반
    
    결과 형식:
    CRITICAL: [이슈들]
    MEDIUM: [이슈들]
    MINOR: [이슈들]
    
    이슈가 없으면: LGTM
    "
    
    # 리뷰 결과 저장
    REVIEW=$(cat /tmp/codex_review.txt)
    
    if echo "$REVIEW" | grep -q "LGTM"; then
        echo "✓ 리뷰 통과!"
        echo "PR을 생성할까요? (y/n)"
        read answer
        if [ "$answer" = "y" ]; then
            gh pr create --title "$COMMIT_MSG" --body "AI 생성 코드
            
리뷰 결과:
$REVIEW"
        fi
    else
        echo "⚠ 이슈 발견"
        echo "$REVIEW"
        
        echo "=== Step 3: Claude 수정 ==="
        claude "
        Codex 리뷰 결과:
        $REVIEW
        
        위 이슈들을 모두 수정해줘.
        수정 후 다시 커밋해줘.
        커밋 메시지: 'fix: address code review issues'
        "
        
        echo "수정 완료. 다시 리뷰할까요? (y/n)"
        read answer
        if [ "$answer" = "y" ]; then
            # 재귀: 스크립트를 다시 실행
            ./auto-dev.sh "review fixes"
        fi
    fi
else
    echo "✗ 개발 실패"
    exit 1
fi

사용 방법:

chmod +x auto-dev.sh
./auto-dev.sh "사용자 로그인 API"

실행 흐름:

1. Claude가 로그인 API 구현
   ↓
2. Git 커밋: "feat: implement user login API"
   ↓
3. Codex가 커밋 내용 리뷰
   ↓
4-1. LGTM → PR 생성
4-2. 이슈 발견 → Claude가 수정 → 2번으로 돌아감

개선 버전 - 무한 루프 방지

Version 1.0의 문제점: Claude가 수정 → Codex 리뷰 → 이슈 → Claude 수정 → … 끝없이 반복될 수 있음.

Version 2.0: 최대 반복 횟수 제한

  
#!/bin/bash
# auto-dev-v2.sh

MAX_ITERATIONS=3
ITERATION=0

TASK=$1

function dev_cycle() {
    ITERATION=$((ITERATION + 1))
    
    if [ $ITERATION -gt $MAX_ITERATIONS ]; then
        echo "❌ 최대 반복 횟수 초과 ($MAX_ITERATIONS)"
        echo "수동 개입이 필요합니다."
        exit 1
    fi
    
    echo ""
    echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
    echo "  Iteration $ITERATION / $MAX_ITERATIONS"
    echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
    echo ""
    
    if [ $ITERATION -eq 1 ]; then
        # 첫 번째: 새 기능 구현
        echo "=== Claude: 개발 ==="
        claude "$TASK"
    else
        # 두 번째 이후: 이슈 수정
        echo "=== Claude: 이슈 수정 ==="
        claude "
        이전 리뷰 결과:
        $(cat /tmp/last_review.txt)
        
        위 이슈들을 수정해줘.
        "
    fi
    
    if [ $? -ne 0 ]; then
        echo "✗ 개발/수정 실패"
        exit 1
    fi
    
    echo "=== Codex: 리뷰 ==="
    COMMIT_MSG=$(git log -1 --pretty=%B)
    
    codex --effort high "
    커밋: $COMMIT_MSG
    변경사항: $(git diff HEAD~1)
    
    리뷰해줘.
    
    출력 형식:
    CRITICAL: [이슈] 또는 없음
    MEDIUM: [이슈] 또는 없음
    
    이슈가 전혀 없으면: LGTM
    " > /tmp/last_review.txt
    
    REVIEW=$(cat /tmp/last_review.txt)
    
    if echo "$REVIEW" | grep -q "LGTM"; then
        echo ""
        echo "✅ 리뷰 통과! ($ITERATION번 만에 성공)"
        echo ""
        echo "최종 커밋:"
        git log -1 --oneline
        echo ""
        echo "$REVIEW"
        return 0
    else
        echo ""
        echo "⚠ 이슈 발견 (Iteration $ITERATION)"
        echo "$REVIEW"
        echo ""
        
        # 재귀 호출
        dev_cycle
    fi
}

# 실행
dev_cycle

echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "  완료!"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

개선 사항:

✅ 무한 루프 방지 (최대 3번)
✅ 진행 상황 시각화
✅ 각 iteration 결과 기록
✅ 최종 성공 여부 명확히 표시

고급 버전 - Boris Cherny 패턴 적용

Version 3.0: 병렬 리뷰 + Git Worktrees

  
#!/bin/bash
# auto-dev-v3.sh

TASK=$1
MAIN_BRANCH="main"
FEATURE_BRANCH="feature/$(echo $TASK | tr ' ' '-' | tr '[:upper:]' '[:lower:]')"

# 1. Git Worktree 생성
echo "=== 작업 환경 준비 ==="
git worktree add ../worktree-dev $MAIN_BRANCH
cd ../worktree-dev
git checkout -b $FEATURE_BRANCH

# 2. Claude 개발
echo "=== Claude: 개발 ==="
claude "$TASK"

# 3. 병렬 리뷰 (Boris Cherny 방식)
echo "=== Codex: 병렬 리뷰 ==="

COMMIT_MSG=$(git log -1 --pretty=%B)
DIFF=$(git diff HEAD~1)

# 3개 리뷰어를 병렬로 실행
echo "  Reviewer 1: 보안 전문가"
codex --effort high "
당신은 보안 전문가입니다.
커밋: $COMMIT_MSG
변경: $DIFF

보안 이슈만 찾아주세요:
- SQL Injection
- XSS
- CSRF
- 민감정보 노출
- 권한 검증 누락
" > /tmp/review_security.txt &

echo "  Reviewer 2: 성능 전문가"
codex --effort medium "
당신은 성능 전문가입니다.
커밋: $COMMIT_MSG
변경: $DIFF

성능 이슈만 찾아주세요:
- N+1 쿼리
- 불필요한 반복
- 메모리 누수
- 비효율적 알고리즘
" > /tmp/review_performance.txt &

echo "  Reviewer 3: 코드 품질 전문가"
codex --effort medium "
당신은 코드 품질 전문가입니다.
커밋: $COMMIT_MSG
변경: $DIFF

코드 품질 이슈만 찾아주세요:
- 가독성
- 유지보수성
- 테스트 가능성
- 코딩 규칙 위반
" > /tmp/review_quality.txt &

# 모든 리뷰어 완료 대기
wait

echo "  ✓ 모든 리뷰 완료"

# 4. 리뷰 결과 집계
echo "=== 리뷰 결과 ==="

SECURITY=$(cat /tmp/review_security.txt)
PERFORMANCE=$(cat /tmp/review_performance.txt)
QUALITY=$(cat /tmp/review_quality.txt)

echo "보안: $SECURITY"
echo "성능: $PERFORMANCE"
echo "품질: $QUALITY"

# 5. Critical 이슈가 하나라도 있으면 수정
if echo "$SECURITY$PERFORMANCE$QUALITY" | grep -qi "CRITICAL"; then
    echo ""
    echo "⚠ Critical 이슈 발견 - 수정 필요"
    
    claude "
    세 명의 리뷰어 의견:
    
    보안 리뷰:
    $SECURITY
    
    성능 리뷰:
    $PERFORMANCE
    
    품질 리뷰:
    $QUALITY
    
    CRITICAL로 표시된 이슈들만 우선 수정해줘.
    "
else
    echo ""
    echo "✅ Critical 이슈 없음"
    
    # 6. PR 생성
    git push origin $FEATURE_BRANCH
    
    gh pr create \
        --title "$COMMIT_MSG" \
        --body "## 자동 생성 PR

### 리뷰 결과

#### 🔒 보안
$SECURITY

#### ⚡ 성능
$PERFORMANCE

#### 📝 품질
$QUALITY
"
    
    echo ""
    echo "PR 생성 완료!"
fi

# 7. 정리
cd ../원래디렉토리
git worktree remove ../worktree-dev

핵심 개선점:

Git Worktrees로 독립 환경
- 메인 브랜치 영향 없음
- 여러 기능 동시 개발 가능
병렬 리뷰 (Boris 패턴)
- 3명의 전문가가 동시에 리뷰
- 순차 리뷰 대비 3배 빠름
전문화된 리뷰어
- 각자 자기 분야만 집중
- 더 정확한 이슈 발견

실전 팁 - CLAUDE.md 활용

모든 버전에 공통으로 적용해야 할 것:

  
# .claude/CLAUDE.md

## Auto-Review Workflow

### 역할 분담
- **Claude**: 개발만 담당
  - 기능 구현
  - 버그 수정
  - 테스트 코드 작성
  
- **Codex**: 리뷰만 담당
  - 보안 점검
  - 성능 분석
  - 코드 품질 검증

### 커뮤니케이션 규칙
- 모든 작업은 Git 커밋으로 기록
- 커밋 메시지 형식: Conventional Commits
  - feat: 새 기능
  - fix: 버그 수정
  - review: 리뷰 피드백
  - refactor: 리팩토링

### Critical Rules (절대 지켜야 함)

#### 보안
- NEVER: SQL 문자열 직접 조합
- ALWAYS: PreparedStatement 사용
- NEVER: 사용자 입력 직접 출력
- ALWAYS: XSS 필터링

#### 성능
- NEVER: 루프 안에서 DB 쿼리
- ALWAYS: 배치 처리 또는 JOIN
- NEVER: 무한 재귀 가능성
- ALWAYS: 종료 조건 명확히

#### 품질
- NEVER: Magic Number
- ALWAYS: 상수로 정의
- NEVER: 100줄 넘는 메서드
- ALWAYS: 작은 함수로 분리

### 자동화 파이프라인

1. Claude 개발 → Git 커밋
2. Codex 리뷰 → 이슈 파일 생성
3. 이슈 있으면: Claude 수정 → 1번으로
4. 이슈 없으면: PR 자동 생성

### 에러 처리

최대 3번 iteration 후에도 통과 못하면:
- 수동 개입 필요
- 사람이 직접 코드 확인
- 프롬프트 개선 필요할 수 있음

이 CLAUDE.md는 프로젝트 루트에 두면 Claude와 Codex가 자동으로 읽습니다.

Chapter 5: 현실적인 한계와 해결책

한계 1: “AI가 프롬프트를 무시한다”

개발자가 가장 자주 겪는 문제입니다.

실제 사례:

  
# CLAUDE.md에 명시
"IMPORTANT: Oracle 11g 사용
NEVER use MySQL syntax
Example: SELECT * WHERE ROWNUM <= 10"

# 프롬프트
claude "사용자 10명 조회하는 쿼리 만들어줘"

# AI가 생성한 코드 (틀림!)
SELECT * FROM users LIMIT 10;  # MySQL 문법 😱

왜 이런 일이 생길까요?

원인 1: 프롬프트가 너무 일반적

AI의 학습 데이터에는 MySQL 예제가 훨씬 많습니다. Oracle은 상대적으로 적죠. 그래서 명시적으로 강조하지 않으면 더 흔한 MySQL 문법을 선택합니다.

해결책: 프롬프트에 예시 포함

claude "
사용자 10명 조회하는 쿼리를 만들어줘.

데이터베이스: Oracle 11g

올바른 형식:
SELECT * FROM (
    SELECT * FROM users
    ORDER BY created_at DESC
)
WHERE ROWNUM <= 10;

위 형식을 따라서 작성해줘.
"

원인 2: CLAUDE.md가 너무 길다

CLAUDE.md가 500줄이 넘으면, AI가 중요한 부분을 놓칠 수 있습니다.

해결책: 계층적 구조

  
# CLAUDE.md (메인 - 50줄)

## Critical Rules (반드시 읽어야 함)
- Oracle 11g 사용 → 상세: docs/database.md
- 보안 규칙 → 상세: docs/security.md
- 성능 규칙 → 상세: docs/performance.md

  
# docs/database.md (상세 - 200줄)

## Oracle 11g 문법

### 페이징
Bad: LIMIT 10
Good: WHERE ROWNUM <= 10

### 날짜
Bad: DATE_FORMAT()
Good: TO_CHAR()

... 상세한 예제 ...

AI가 메인 파일에서 핵심을 먼저 보고, 필요하면 상세 파일을 참조하게 합니다.

원인 3: “IMPORTANT”가 너무 많다

모든 줄에 “IMPORTANT”를 쓰면, 오히려 효과가 없습니다.

해결책: 3단계 우선순위

  
## 🚨 CRITICAL (절대 위반 금지)
- SQL Injection 방지
- 민감정보 암호화

## ⚠️ IMPORTANT (매우 중요)
- Oracle 11g 문법 사용
- 예외 처리 필수

## 💡 RECOMMENDED (권장)
- 주석 작성
- 테스트 커버리지 80%+

한계 2: “무한 루프에 빠진다”

실제 사례:

Iteration 1:
Claude: 로그인 API 구현 ✓
Codex: SQL Injection 취약점 발견 ✗

Iteration 2:
Claude: PreparedStatement로 수정 ✓
Codex: 이제 Rate Limiting이 없음 ✗

Iteration 3:
Claude: Rate Limiter 추가 ✓
Codex: 이제 에러 메시지가 너무 자세함 (보안 위험) ✗

Iteration 4:
Claude: 에러 메시지 일반화 ✓
Codex: 이제 로깅이 없어서 디버깅 불가 ✗

... 계속 반복 ...

원인: Codex가 매번 새로운 이슈를 찾아냄.

해결책 1: 우선순위 기반 리뷰

  
codex "
커밋: $COMMIT_MSG

리뷰 우선순위:
1. CRITICAL만 찾기 (보안, 데이터 손실)
2. 다른 이슈는 무시

CRITICAL이 없으면: LGTM
"

첫 번째 iteration에서는 CRITICAL만 잡고, 나머지는 나중에.

해결책 2: 체크리스트 방식

  
# 1단계: 보안만
codex --checklist security

# 2단계: 성능만
codex --checklist performance

# 3단계: 품질만
codex --checklist quality

한 번에 하나씩 해결. 모든 걸 동시에 하려고 하면 끝이 없습니다.

해결책 3: 강제 종료

  
MAX_ITERATIONS=3

if [ $ITERATION -gt $MAX_ITERATIONS ]; then
    echo "⚠️ 3번 만에 해결 안됨. 사람 확인 필요."
    
    # 지금까지의 진행 상황 정리
    cat > /tmp/manual_review_needed.md <<EOF
# 수동 검토 필요

## 원래 요청
$TASK

## Iterations
$(git log --oneline -n $MAX_ITERATIONS)

## 마지막 리뷰 이슈
$(cat /tmp/last_review.txt)

## 추천 조치
1. 프롬프트가 명확한지 확인
2. 충돌하는 요구사항 있는지 확인
3. CLAUDE.md 업데이트 필요
EOF
    
    # Slack 알림 (선택)
    curl -X POST $SLACK_WEBHOOK \
        -d "$(cat /tmp/manual_review_needed.md)"
    
    exit 1
fi

한계 3: “비용이 폭발한다”

실제 사례:

첫 주:
- 하루 10번 실행: $0
- Codex effort: medium

둘째 주:
- 하루 50번 실행: $0 (아직 괜찮음)
- Codex effort: high로 변경

셋째 주:
- 하루 100번 실행
- Codex effort: xhigh로 변경
- 💸 청구서: $487 😱

원인: Codex의 effort 설정

medium: 빠르지만 덜 정확
high: 느리지만 더 정확
xhigh: 매우 느리고 매우 정확, 토큰 10배 사용

해결책 1: 단계별 effort

  
# 개발 중: medium (빠른 피드백)
codex --effort medium "간단 체크"

# PR 전: high (꼼꼼한 리뷰)
codex --effort high "전체 리뷰"

# 배포 전: xhigh (Critical만)
codex --effort xhigh "
CRITICAL 이슈만 찾아줘.
- 보안 취약점
- 데이터 손실 가능성
"

해결책 2: 캐싱 활용

  
# 같은 파일 반복 리뷰 방지
HASH=$(git show HEAD | md5sum)

if [ -f "/tmp/review_cache_$HASH" ]; then
    echo "✓ 캐시된 리뷰 결과 사용"
    cat "/tmp/review_cache_$HASH"
    exit 0
fi

# 새로운 리뷰
codex ... > "/tmp/review_cache_$HASH"

해결책 3: 배치 처리

  
# 나쁜 방식: 파일마다 따로 리뷰
for file in *.java; do
    codex "Review $file"  # 10번 API 호출
done

# 좋은 방식: 한 번에 리뷰
codex "
다음 파일들을 한 번에 리뷰해줘:
$(git diff --name-only HEAD~1)

변경사항:
$(git diff HEAD~1)
"  # 1번 API 호출

Chapter 6: 다음 단계 - 실전 확장

확장 1: GitHub Actions 통합

지금까지는 로컬에서 수동 실행했습니다. 이제 자동화하겠습니다.

  
# .github/workflows/ai-code-review.yml
name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  # 전체 히스토리 필요
      
      - name: Setup Claude Code
        run: |
          curl -O https://install.claude.ai/cli.sh
          sh cli.sh
          echo "$" > ~/.anthropic
      
      - name: Setup Codex
        run: |
          npm install -g @openai/codex-cli
          echo "$" > ~/.openai
      
      - name: Get Changed Files
        id: files
        run: |
          FILES=$(git diff --name-only $ $)
          echo "files=$FILES" >> $GITHUB_OUTPUT
      
      - name: Codex Review
        id: review
        run: |
          DIFF=$(git diff $ $)
          
          codex --effort high "
          PR 제목: $
          
          변경 파일:
          $
          
          전체 변경사항:
          $DIFF
          
          리뷰 결과를 GitHub PR Comment 형식으로 작성해줘.
          " > review_result.md
          
          cat review_result.md >> $GITHUB_STEP_SUMMARY
      
      - name: Post Review Comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('review_result.md', 'utf8');
            
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## 🤖 AI Code Review\n\n${review}`
            });
      
      - name: Auto-fix Minor Issues
        if: contains(steps.review.outputs.result, 'MINOR')
        run: |
          claude "
          Codex 리뷰 결과:
          $(cat review_result.md)
          
          MINOR 이슈들만 자동 수정해줘.
          수정 후 커밋해줘.
          "
          
          git push
      
      - name: Fail on Critical Issues
        if: contains(steps.review.outputs.result, 'CRITICAL')
        run: |
          echo "❌ Critical 이슈 발견. PR을 머지할 수 없습니다."
          exit 1

이제 어떻게 작동하나?

1. 개발자가 PR 생성
   ↓
2. GitHub Actions 자동 시작
   ↓
3. Codex가 PR 리뷰
   ↓
4-1. Critical 이슈: PR 머지 차단
4-2. Minor 이슈: Claude가 자동 수정
4-3. 이슈 없음: ✓ 통과

확장 2: 메트릭 수집 및 분석

얼마나 효과적인지 측정하지 않으면, 개선할 수 없습니다.

  
#!/bin/bash
# auto-dev-metrics.sh

METRICS_FILE="metrics.jsonl"  # JSON Lines 형식

function record_metric() {
    local task=$1
    local iterations=$2
    local duration=$3
    local result=$4
    
    cat >> $METRICS_FILE <<EOF
{"timestamp":"$(date -Iseconds)","task":"$task","iterations":$iterations,"duration_seconds":$duration,"result":"$result"}
EOF
}

# 메인 로직
START_TIME=$(date +%s)
TASK=$1

# ... 기존 auto-dev 로직 ...

END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))

record_metric "$TASK" $ITERATION $DURATION $RESULT

# 통계 출력
echo ""
echo "=== 통계 (최근 30일) ==="

cat $METRICS_FILE | \
jq -s '
  map(select(.timestamp > (now - 30*24*3600 | todate))) |
  {
    total_tasks: length,
    avg_iterations: (map(.iterations) | add / length),
    avg_duration: (map(.duration_seconds) | add / length),
    success_rate: ((map(select(.result == "success")) | length) / length * 100)
  }
'

출력 예시:

  
{
  "total_tasks": 127,
  "avg_iterations": 1.8,
  "avg_duration": 342,
  "success_rate": 94.5
}

월간 리포트 자동 생성:

  
# generate_monthly_report.sh

claude "
$(cat metrics.jsonl | tail -n 1000)

위 데이터를 분석해서 월간 리포트를 작성해줘.

포함 내용:
1. 총 작업 수
2. 평균 iteration 횟수 (목표: 2 이하)
3. 평균 소요 시간 (목표: 5분 이하)
4. 성공률 (목표: 95%+)
5. 가장 많이 발견된 이슈 Top 5
6. 개선 제안

형식: Markdown
" > monthly_report_$(date +%Y%m).md

확장 3: 팀 확산 전략

혼자만 쓰기엔 너무 아깝습니다. 팀 전체로 확산하는 방법:

1주차: 파일럿 (3명)

  
# 팀 공지

## 🚀 AI Auto-Review 파일럿 프로그램

### 참여자
- 김개발 (관심 표명)
- 이코드 (관심 표명)
- 박리뷰 (관심 표명)

### 기간
1주일 (2026.01.06 - 01.12)

### 목표
- 시스템 안정성 검증
- 효과 측정
- 문제점 파악

### 참여 방법
1. 설치: `./setup.sh`
2. 매일 최소 1번 사용
3. 피드백 공유 (Slack #ai-tools)

### 기대 효과
- 개발 속도 30%+ 향상
- 코드 리뷰 시간 50%+ 단축
- 버그 사전 발견

2주차: 효과 측정

  
# 파일럿 참여자 데이터 수집
for user in 김개발 이코드 박리뷰; do
    echo "=== $user ==="
    
    # metrics.jsonl에서 해당 사용자 데이터 추출
    grep "\"user\":\"$user\"" metrics.jsonl | \
    jq -s '{
        작업수: length,
        평균_반복: (map(.iterations) | add / length),
        성공률: ((map(select(.result == "success")) | length) / length * 100)
    }'
done

결과 예시:

김개발:
  작업수: 28
  평균_반복: 1.6
  성공률: 96%
  
이코드:
  작업수: 31
  평균_반복: 2.1
  성공률: 90%
  
박리뷰:
  작업수: 19
  평균_반복: 1.4
  성공률: 100%

3주차: 경영진 보고

  
# AI Auto-Review 파일럿 결과 보고

## Executive Summary
- 참여 인원: 3명
- 기간: 1주
- 총 작업: 78건
- **평균 개발 시간: 45% 단축**
- **버그 사전 발견: 67건**

## ROI 분석
### 투자
- 도구 비용: $60/월 (3명 × $20)
- 교육 시간: 2시간

### 절감
- 개발 시간 절약: 35시간/월
- 시간당 비용 $50 기준: $1,750/월

### ROI
$1,750 / $60 = **29배**

## 제안
파일럿 성공 확인.
전체 개발팀 (15명) 확대 추천.

예상 효과:
- 월 $300 투자 → $8,750 절감
- ROI: 29배 유지 예상

4주차: 전체 확대

  
# 전체 팀 설정 자동화
# setup_team.sh

TEAM_MEMBERS=(
    "김개발"
    "이코드"
    "박리뷰"
    "최신입"
    "정시니어"
    # ... 15명
)

for member in "${TEAM_MEMBERS[@]}"; do
    echo "=== $member 설정 ==="
    
    # 1. CLI 도구 설치
    ssh $member@dev-server "
        curl -O https://install.claude.ai/cli.sh
        sh cli.sh
    "
    
    # 2. 공통 설정 복사
    scp .claude/CLAUDE.md $member@dev-server:~/project/.claude/
    scp auto-dev-v3.sh $member@dev-server:~/bin/
    
    # 3. 개인별 API 키 설정
    # (보안상 각자 직접 입력)
    
    echo "✓ $member 설정 완료"
done

echo ""
echo "=== 팀 전체 준비 완료 ==="
echo "다음 단계: 킥오프 미팅"

Chapter 7: 실제 사용 사례와 교훈

사례 1: 긴급 버그 수정

상황:

금요일 오후 4시
프로덕션 버그 발견
월요일 배포 예정

전통적 방식 (예상 시간: 3시간):

버그 재현 (30분)
원인 파악 (1시간)
수정 및 테스트 (1시간)
코드 리뷰 요청 (리뷰어 대기...)
리뷰 통과 후 머지 (30분)

총: 3시간 + 리뷰 대기 시간

AI Auto-Review 방식 (실제 시간: 25분):

  
# 1. 버그 설명 (5분)
./auto-dev.sh "
버그: 결제 완료 후 재고 차감 안됨

재현:
1. 상품 구매
2. 결제 완료
3. DB 확인 → stock_count 그대로

예상 원인: 트랜잭션 범위 문제?
"

# 2. Claude가 원인 파악 및 수정 (10분)
# - 트랜잭션 범위 확인
# - PaymentService와 InventoryService 분석
# - @Transactional 위치 수정
# - 테스트 케이스 추가

# 3. Codex 자동 리뷰 (5분)
# - 트랜잭션 경계 확인
# - Race condition 체크
# - 롤백 시나리오 검증

# 4. PR 자동 생성 및 머지 (5분)

총: 25분 (리뷰 대기 없음!)

핵심 교훈:

AI는 24/7 대기. 리뷰어 기다릴 필요 없음.
버그 설명만 잘하면, AI가 원인 파악부터 해결까지.
긴급 상황에 특히 유용.

사례 2: 대규모 리팩토링

상황:

레거시 코드 1,500줄
MyBatis → JPA 전환

도전 과제:

  
// 기존: MyBatis XML (500줄 × 3파일)
<select id="findUserStats">
    SELECT 
        u.user_id,
        u.user_name,
        COUNT(o.order_id) as order_count,
        SUM(o.total_price) as total_spent,
        AVG(r.rating) as avg_rating
    FROM users u
    LEFT JOIN orders o ON u.user_id = o.user_id
    LEFT JOIN reviews r ON u.user_id = r.user_id
    WHERE u.status = 'ACTIVE'
    AND o.created_at >= #{startDate}
    GROUP BY u.user_id, u.user_name
</select>

// 목표: JPA + QueryDSL로 전환

전통적 방식 (예상: 2주):

1주차:
- Entity 설계 (2일)
- Repository 작성 (2일)
- Service 변환 (1일)

2주차:
- 테스트 작성 (2일)
- 버그 수정 (2일)
- 코드 리뷰 (1일)

AI Auto-Review 방식 (실제: 3일):

1일차: 계획 수립

  
claude --mode plan "
MyBatis를 JPA + QueryDSL로 전환하려고 해.

현황:
- UserMapper.xml (500줄)
- OrderMapper.xml (400줄)
- ReviewMapper.xml (300줄)

요구사항:
- 기존 비즈니스 로직 100% 유지
- 성능 저하 없이
- 단계적 전환 (기존 코드와 공존)

전환 계획을 세워줘.
"

# Claude 결과:
Phase 1: User 관련 쿼리 (간단함)
Phase 2: Order 관련 쿼리 (중간)
Phase 3: Review 관련 쿼리 (복잡함)
Phase 4: 통합 테스트 및 성능 비교

2일차: 실제 전환 (병렬 작업)

  
# Git Worktrees로 3개 병렬 작업
git worktree add ../phase1 main
git worktree add ../phase2 main
git worktree add ../phase3 main

# 각 Worktree에서 Claude 실행
cd ../phase1 && ./auto-dev.sh "User 쿼리 JPA 전환" &
cd ../phase2 && ./auto-dev.sh "Order 쿼리 JPA 전환" &
cd ../phase3 && ./auto-dev.sh "Review 쿼리 JPA 전환" &

wait

# 각 Phase별 Codex 리뷰
for phase in phase1 phase2 phase3; do
    cd ../$phase
    codex --effort high "
    MyBatis → JPA 전환 검증:
    1. 쿼리 결과 동일성
    2. 성능 (N+1 쿼리 없는지)
    3. 트랜잭션 경계 올바른지
    "
done

3일차: 통합 및 검증

  
# 모든 Phase 머지
git merge phase1
git merge phase2
git merge phase3

# 통합 테스트
./auto-dev.sh "
세 Phase를 모두 통합했어.
전체 통합 테스트를 작성하고 실행해줘.

비교 항목:
- MyBatis 결과 vs JPA 결과
- 응답 시간
- 메모리 사용량
"

# 성능 비교 리포트 자동 생성
claude "
테스트 결과:
$(cat test_results.json)

비교 리포트를 작성해줘.
- 쿼리별 성능 비교
- 개선/악화된 부분
- 최종 권장사항
"

최종 결과:

기간: 2주 → 3일 (77% 단축)
품질: 수동 전환 시 예상 버그 15건 → 실제 0건
성능: 평균 응답시간 5% 개선 (N+1 쿼리 제거 덕분)

핵심 교훈:

큰 작업도 잘게 나누면 병렬 처리 가능
AI가 단순 변환 작업은 거의 완벽하게 처리
사람은 전략 수립과 최종 검증에 집중

사례 3: 신입 개발자 온보딩

상황:

신입 개발자 입사
회사 코드베이스 20만 줄
첫 PR까지 보통 2주 소요

기존 온보딩 프로세스:

1주차: 코드 읽기, 문서 읽기
- "이 코드는 왜 이렇게 짜여있죠?"
- "문서가 오래되어서 실제 코드와 다릅니다"
- "누구한테 물어봐야 하죠?"

2주차: 간단한 버그 수정 시도
- 코드 수정
- 시니어에게 리뷰 요청
- "이건 이렇게 하면 안됩니다" (다시 수정)
- "우리 회사 규칙은..." (또 수정)

AI Auto-Review 활용 온보딩:

1일차: CLAUDE.md로 규칙 학습

  
# 신입에게 첫 과제
./auto-dev.sh "
간단한 기능을 만들어봐:
사용자 이름 변경 API

요구사항:
- PUT /api/users/{id}/name
- Request: { "name": "새이름" }
- Response: 200 OK

CLAUDE.md를 참고해서 회사 규칙대로 만들어줘.
"

# Claude가 CLAUDE.md 읽고 회사 스타일로 생성:
public class UserController extends BaseController {  // ✓ 회사 규칙
    
    private static final Logger logger = 
        LoggerFactory.getLogger(UserController.class);  // ✓ 로깅 규칙
    
    @PutMapping("/{id}/name")
    public ResponseEntity<?> updateName(
        @PathVariable Long id,
        @Valid @RequestBody NameUpdateRequest request
    ) {
        try {
            userService.updateName(id, request.getName());
            return ResponseEntity.ok().build();
        } catch (UserNotFoundException e) {
            logger.warn("User not found: {}", id);
            return ResponseEntity.notFound().build();  // ✓ 예외 처리 규칙
        } catch (Exception e) {
            logger.error("Failed to update name", e);
            throw new InternalServerException();  // ✓ 회사 예외 클래스
        }
    }
}

# Codex 자동 리뷰:
✓ BaseController 상속 확인
✓ Logger 사용 확인
✓ 예외 처리 확인
✓ 회사 네이밍 규칙 준수

LGTM!

결과:

신입이 첫날부터 회사 규칙에 맞는 코드 작성
시니어 개발자의 리뷰 부담 감소
“이건 이렇게 하면 안됩니다” → AI가 미리 차단

1주차 말:

기존: 아직도 코드 읽는 중...
AI 활용: 이미 PR 5개 머지 완료!

핵심 교훈:

CLAUDE.md = 회사의 암묵지를 명시지로
신입도 첫날부터 생산적
시니어는 전략적 멘토링에 집중

결론: 혼자 발견한 것과 거장의 지혜가 만났을 때

한 개발자가 우연히 발견한 아이디어는 알고 보니 Claude Code 창시자 Boris Cherny가 Anthropic 내부에서 이미 사용하고 있던 방법과 놀라울 정도로 유사했습니다.

하지만 그 개발자의 방법에는 Boris보다 한 발 더 나아간 부분이 있었습니다. Git 커밋 메시지를 AI 간 커뮤니케이션 레이어로 사용한 것이죠. 이는 자연스럽고, 추적 가능하며, 팀 협업에도 완벽하게 들어맞는 방법이었습니다.

이 여정에서 배운 핵심 교훈

1. AI 도구는 만능이 아니다

“글케 치면 걍 쉘로 만들어도 되긴 될듯한데” - 맞습니다. 복잡한 AI 시스템이 아니어도, 간단한 쉘 스크립트로 큰 효과를 볼 수 있습니다. 하지만 프로그래밍 언어로 만들면 더 견고하고 확장 가능합니다.

2. 프롬프트 품질이 90%다

아무리 자동화 시스템을 잘 만들어도, AI에게 무엇을 어떻게 요청하느냐가 결과를 결정합니다. CLAUDE.md를 지속적으로 개선하고, 프롬프트에 구체적인 예시를 포함하고, 우선순위를 명확히 하세요.

3. CLI가 API보다 스마트하다

많은 개발자가 “AI 에이전트 = API 호출”이라고 생각하지만, 실제로는 CLI 도구를 활용하는 것이 훨씬 효율적입니다. 비용, 편의성, 제어 가능성 모든 면에서 우수합니다.

4. 에이전트는 계층적으로 쌓인다

Base Model → Subagents → CLI Tool → Your Automation. 이는 소프트웨어 엔지니어링의 자연스러운 추상화 과정입니다.

5. “다시 해봐”를 자동화하는 것만으로도 가치가 크다

완벽한 AI는 없습니다. 하지만 피드백 루프를 빠르게 돌리는 것만으로도 엄청난 생산성 향상을 가져올 수 있습니다.

Boris Cherny가 말한 진짜 가치

“진짜 가치는 자동화 자체가 아닙니다. 사람 리뷰어를 기다릴 필요 없이 10배 빠른 iteration이 가능하다는 것입니다.”

지금 당장 시작하는 법

Step 1: 오늘 (30분)

  
# 1. Claude Code 설치
curl -O https://install.claude.ai/cli.sh
sh cli.sh

# 2. 간단한 테스트
claude "Hello, Claude!"

Step 2: 내일 (1시간)

  
# 1. CLAUDE.md 작성 (최소 버전)
cat > .claude/CLAUDE.md <<EOF
# 프로젝트 규칙

## 기술 스택
- [당신의 기술 스택]

## 절대 규칙
- [절대 하면 안되는 것 3가지]

## 권장 사항
- [권장하는 것 3가지]
EOF

# 2. 첫 자동화 스크립트
wget https://raw.githubusercontent.com/.../auto-dev-v1.sh
chmod +x auto-dev-v1.sh
./auto-dev-v1.sh "간단한 기능"

Step 3: 이번 주 (매일 30분씩)

월: 실패 케이스 수집
화: CLAUDE.md 업데이트
수: 스크립트 개선 (v2)
목: 팀원 1명과 공유
금: 결과 측정 및 회고

Step 4: 다음 달

1주차: 파일럿 (3명)
2주차: 효과 측정
3주차: 경영진 보고
4주차: 팀 전체 확대

마지막 조언

이 시스템을 만드는 과정에서 개발자가 느낀 것:

“오 대단한데 생각했으나 만들다 보니.. 그정도 까진 아닌가? 어찌될지는 아직 모름. 일단 만들어보자”

이 솔직함이 중요합니다. 만능키는 없습니다. 하지만 그렇다고 시도하지 않으면, 결코 알 수 없습니다.

Boris Cherny도 처음에는 “AppleScript로 음악만 바꾸는” 단순한 프로토타입에서 시작했습니다. 그것이 지금은 Anthropic 전체 코드의 80-90%를 생성하는 핵심 도구가 되었습니다.

당신의 간단한 쉘 스크립트도, 언젠가는 팀 전체의 생산성을 4배로 높이는 핵심 인프라가 될 수 있습니다.

일단 만들어보세요.

그리고 계속 개선하세요. AI 에이전트의 진짜 가치는 완벽함이 아니라, 빠른 iteration과 지속적인 학습에 있습니다.

부록: 추가 리소스

Boris Cherny 인터뷰 및 발표

Pragmatic Engineer Podcast (2025년 9월): “How Claude Code is Built”
Every.to Podcast (2025년 10월): “How to Use Claude Code Like the People Who Built It”
Anthropic 공식 블로그: “Claude Code: Best practices for agentic coding”
The Developing Dev Podcast (2025년 12월): “Boris Cherny On How His Career Grew”

기술 문서

Claude Code 공식 문서: https://docs.anthropic.com/claude-code
Subagent 패턴: 공식 블로그의 “Multiple Claudes” 섹션
MCP (Model Context Protocol): https://modelcontextprotocol.io

커뮤니티

Claude Code Discord: 실시간 질문 답변
GitHub Discussions: 사용 사례 공유
Anthropic 웨비나: 월 1회 정기 세션

코드 저장소

예제 스크립트: [이 문서의 모든 스크립트]
CLAUDE.md 템플릿: 다양한 프로젝트 타입별 예시
GitHub Actions 템플릿: CI/CD 통합 예시

작성 일자: 2026-01-04
저자: AI 시대의 개발자들을 위한 실전 가이드
핵심 메시지: 작은 자동화부터 시작하세요. 완벽함보다 빠른 iteration이 중요합니다.

AI, Vibe Coding

AI Codex GitHub claude-code vibe-coding coding-agents subagents-pattern Developer Claude.write

들어가며: 우연한 발견이 만든 혁신

Chapter 1: 원본 아이디어 - 실험의 시작

최초의 발상

왜 이 방식이 매력적인가?

초기 기대와 실제

Chapter 2: Boris Cherny의 Subagent 패턴

Claude Code 내부에서 실제로 사용하는 방법

코드 리뷰 워크플로우 - Boris의 실제 사례

Subagent 간 커뮤니케이션 - Scratchpad 방식

Git 커뮤니케이션의 우수성

Chapter 3: 실전에서 발견한 핵심 인사이트

인사이트 1: “결국 프롬프트 품질 문제”

인사이트 2: “CLI 레벨이 API보다 스마트함”

인사이트 3: “에이전트 위에 에이전트…”

Chapter 4: 실전 구현 가이드

기본 구조 - 최소 실행 가능한 시스템

개선 버전 - 무한 루프 방지

고급 버전 - Boris Cherny 패턴 적용

실전 팁 - CLAUDE.md 활용

Chapter 5: 현실적인 한계와 해결책

한계 1: “AI가 프롬프트를 무시한다”

한계 2: “무한 루프에 빠진다”

한계 3: “비용이 폭발한다”

Chapter 6: 다음 단계 - 실전 확장

확장 1: GitHub Actions 통합

확장 2: 메트릭 수집 및 분석

확장 3: 팀 확산 전략

Chapter 7: 실제 사용 사례와 교훈

사례 1: 긴급 버그 수정

사례 2: 대규모 리팩토링

사례 3: 신입 개발자 온보딩

결론: 혼자 발견한 것과 거장의 지혜가 만났을 때

이 여정에서 배운 핵심 교훈

Boris Cherny가 말한 진짜 가치

지금 당장 시작하는 법

마지막 조언

부록: 추가 리소스

Boris Cherny 인터뷰 및 발표

기술 문서

커뮤니티

코드 저장소

인기 태그