개발자 AI 도구 실전: OpenClaw + Claude Code로 24시간 버그 자동 수정

결제 콜백 시간 초과 버그 하나를 발견한 뒤 수정 사항이 병합될 때까지 평균 4.5시간이 걸렸습니다. 발견 2시간, 위치 파악 30분, 수정 30분, 테스트 20분, PR 제출 10분입니다. 이런 버그의 수정 방법은 대개 정해져 있습니다. 지수 백오프를 추가하고 예외를 포착하며 로그를 기록하는 식입니다. ‘유형이 알려진 문제’라 반복성이 높고 사람이 일일이 처리할 가치가 크지 않습니다.

OpenClaw + Claude Code 하이브리드 워크플로는 이 문제를 해결할 수 있습니다. OpenClaw가 Sentry를 24시간 모니터링하다 버그를 발견하면 자동으로 작업을 배정하고, Claude Code는 작업을 받은 뒤 브랜치를 가져와 코드를 수정하고 테스트를 실행한 다음 PR을 제출합니다. 3개월 동안 실제로 운영한 결과 버그 127건을 자동 포착했고 89건(70%)을 성공적으로 수정했으며, 그중 72건(57%)이 최종적으로 사람의 검토를 거쳐 병합됐습니다. 처리 시간은 4.5시간에서 15분으로 줄었습니다.

이 글에서는 이 하이브리드 워크플로의 아키텍처 설계, 설정 단계, 실제 운영 결과를 공유합니다. 이론이 아니라 프로덕션 환경에서 3개월간 운영한 실제 데이터입니다.

저비용 ‘새우 키우기’ 가이드: ArkClaw로 AI Agent의 진입 장벽 낮추기

최근 큰 인기를 끄는 OpenClaw(바닷가재)는 유용하지만 설정 난도가 너무 높지 않나요? ByteDance Volcano Engine의 ArkClaw는 진입 장벽을 단숨에 낮췄습니다. 서버와 Token 설정에 애쓸 필요 없이 한 번의 클릭으로 24시간 온라인 상태를 유지하며 브라우저를 제어하고, 스크립트를 실행하고, 캘린더를 관리하는 ‘AI 일꾼’을 가질 수 있습니다.

무엇보다 정말 저렴합니다. 월 이용료는 9.9위안에 불과하며, 제 초대 코드 ZLKUK54M을 사용해 여기에서 가입하면 8.9위안입니다. 개발자라면 Coding Plan Pro를 선택해 무료 혜택도 받을 수 있습니다.

OpenClaw vs Claude Code—경쟁이 아닌 상호 보완 관계

많은 분이 제게 묻습니다. OpenClaw와 Claude Code 중 무엇을 써야 할까요?

솔직히 말해 두 도구는 경쟁 관계가 아닙니다. 역할이 완전히 다르며 함께 사용할 때 가장 강력합니다.

OpenClaw는 24/7 대기하는 ‘개인 AI Agent’입니다. 백그라운드에 상주하며 webhook을 받고, 여러 데이터 소스를 모니터링하고, 사용자가 자는 동안에도 계속 작업할 수 있습니다. 공식 정의는 ‘persistent personal AI’, 즉 지속적으로 동작하는 개인 AI입니다. 복잡한 코드를 작성하는 데 특화된 도구는 아니지만 상황이 발생하는 것을 ‘지켜보다’ 그에 맞는 작업을 트리거하고 다른 전문 도구를 조율하는 데 강합니다.

Claude Code는 전문 ‘AI 개발자’입니다. 서버를 모니터링하는 방법은 모르지만 코드를 읽고 버그를 수정하거나 로직을 리팩터링하는 일은 강점입니다. 코드베이스를 깊이 이해하고 어디를 어떻게 고쳐야 안전한지 판단할 수 있습니다.

이처럼 두 도구는 완벽히 상호 보완적입니다. 하나는 ‘관찰’을, 다른 하나는 ‘실행’을 맡습니다.

OpenClaw Directory에서 ‘Sentry → Auto-Debug → Open PR’이라는 레시피를 봤는데, 바로 이런 상황을 위해 설계된 방식이었습니다. 작동 원리는 다음과 같습니다.

1. Sentry가 오류를 감지하고 webhook을 트리거합니다.
2. OpenClaw가 알림을 받아 스택 정보를 분석합니다.
3. OpenClaw가 하위 에이전트를 생성해 Claude Code에 수정을 맡깁니다.
4. Claude Code가 수정 코드를 생성하고 테스트를 실행합니다.
5. 테스트에 통과하면 GitHub PR을 자동으로 엽니다.

전체 과정이 완전히 자동화되어 사람의 개입이 필요하지 않습니다. Substack에서 이 설정을 사용한 경험담을 읽었는데, 작성자는 이 방식으로 ‘PR이 준비될 때까지 사람이 개입하지 않는 밤샘 코드 리뷰’를 구현했다고 했습니다. 밤에 버그가 발생하면 아침에 PR을 확인하는 방식입니다.

아키텍처 설계—하이브리드 워크플로의 핵심 구성 요소

이 워크플로를 이해하려면 먼저 OpenClaw의 ‘하위 에이전트’ 메커니즘을 알아야 합니다.

OpenClaw 자체는 ‘총괄 관리자’ 역할을 합니다. 여러 이벤트(webhook, 예약 작업, 메시지 알림)를 수신하며, 구체적인 실행은 ‘하위 에이전트’에 맡길 수 있습니다. 하위 에이전트는 특정 작업에 집중하도록 임시로 생성되는 AI 인스턴스입니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

비유하자면 OpenClaw는 프로젝트 관리자이고 Claude Code는 개발자입니다. 프로젝트 관리자가 요구 사항(Sentry 알림)을 받은 뒤 분석해서 개발자(하위 에이전트)에게 배정하면, 개발자가 작업을 마치고 결과를 보고합니다.

전체 아키텍처는 다음과 같습니다.

┌─────────────────────────────────────────────────────────────┐
│                         외부 환경                            │
│  ┌──────────┐  ┌──────────┐  ┌─────────────────────────┐   │
│  │  Sentry  │  │  GitHub  │  │  Slack/Discord/Telegram │   │
│  └────┬─────┘  └────▲─────┘  └──────────▲──────────────┘   │
└───────┼─────────────┼───────────────────┼──────────────────┘
        │             │                   │
        │ webhook     │ create PR         │ notify
        │             │                   │
┌───────▼─────────────┴───────────────────┴──────────────────┐
│                      OpenClaw Gateway                        │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              OpenClaw 메인 에이전트(모니터)           │  │
│  │  • 24시간 Sentry webhook 수신                         │  │
│  │  • 오류 유형과 심각도 분석                            │  │
│  │  • 결정: 자동 수정 / 사람 개입 / 무시                 │  │
│  └─────────────────────┬────────────────────────────────┘  │
│                        │ spawn                             │
│                        ▼                                   │
│  ┌──────────────────────────────────────────────────────┐  │
│  │            Claude Code 하위 에이전트(실행자)          │  │
│  │  • 최신 코드 가져오기                                 │  │
│  │  • 버그 근본 원인 분석                                │  │
│  │  • 수정 코드 작성                                     │  │
│  │  • 테스트 실행 및 검증                                │  │
│  │  • 브랜치 push 및 PR 생성                             │  │
│  └──────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────┘

핵심은 OpenClaw가 코드를 직접 수정하지 않는다는 점입니다. OpenClaw는 ‘의사 결정’과 ‘조율’만 담당하고 실제 코드 수정은 Claude Code 하위 에이전트에 맡깁니다. 이렇게 하면 보안(OpenClaw의 권한 통제)과 수정 품질(Claude Code의 전문 역량)을 모두 확보할 수 있습니다.

데이터 흐름은 다음과 같습니다.

1. Sentry webhook → OpenClaw(오류 이벤트, 스택 정보, 환경 데이터)
2. OpenClaw → Claude Code 하위 에이전트(수정 지시, 컨텍스트 정보)
3. Claude Code 하위 에이전트 → GitHub(수정 코드, PR 설명)
4. GitHub → OpenClaw(PR 상태, CI 결과)
5. OpenClaw → Slack(사람에게 검토 알림)

여기서는 OpenClaw의 상태 관리 기능이 중요합니다. 각 버그의 처리 상태를 ‘접수됨’, ‘분석 중’, ‘수정 중’, ‘검토 대기’, ‘병합됨’으로 기록할 수 있습니다. 따라서 프로세스가 중단되어도 중단 지점부터 다시 시작할 수 있습니다.

실전 설정—모니터링부터 PR 자동 제출까지

개념을 살펴봤으니 이제 구체적인 설정 방법을 알아보겠습니다.

1단계: Sentry webhook 설정

Sentry에 로그인해 프로젝트 설정 → Integrations → Webhooks로 이동합니다. OpenClaw webhook URL을 추가합니다.

https://your-openclaw-gateway.com/hooks/sentry?sessionKey=bug-fix-pipeline

그런 다음 Alert Rules에서 규칙을 하나 만듭니다. error count > 5 in 5 minutes일 때 webhook을 트리거하도록 설정합니다.

2단계: OpenClaw 모니터링 에이전트 설정

OpenClaw에서 Sentry 이벤트를 처리할 전용 agent를 만듭니다. 설정 파일은 대략 다음과 같습니다.

name: sentry-bug-monitor
hooks:
  sentry:
    path: /hooks/sentry
    defaultSessionKey: bug-fix-pipeline

steps:
  - id: parse-error
    command: json.parse stdin
    description: "Sentry 오류 데이터 파싱"

  - id: classify
    command: llm-task "오류 유형과 심각도 분석"
    args:
      error: $parse-error.stacktrace
      message: $parse-error.message
    schema: error-classification.json

  - id: decision
    command: state.set "action" $classify.recommended_action

  - id: auto-fix
    command: subagent.spawn
    args:
      type: claude-code
      task: "버그 수정: ${parse-error.title}"
      context: $parse-error
      repo: $parse-error.project.repo
    condition: $classify.severity == "medium" && $classify.auto_fixable == true

  - id: notify-human
    command: slack.send "#alerts"
    args:
      message: "심각한 오류 발견, 사람의 개입 필요: ${parse-error.url}"
    condition: $classify.severity == "critical"

여기에는 몇 가지 핵심 포인트가 있습니다.

• classify 단계는 LLM으로 오류 유형을 분석하고 자동 수정에 적합한지 판단합니다.
• decision은 심각도에 따라 분기합니다. 우선순위가 중간이고 자동 수정이 가능한 오류는 Claude Code로 보내며, 심각한 오류는 사람에게 알립니다.
• subagent.spawn은 하위 에이전트를 생성하는 명령이며 여기서는 type을 claude-code로 지정합니다.

3단계: Claude Code 하위 에이전트 설정

하위 에이전트는 실제 코드 수정을 담당합니다. OpenClaw는 오류 스택, 관련 코드 파일, 환경 정보를 포함한 컨텍스트를 하위 에이전트에 전달합니다.

하위 에이전트의 워크플로는 다음과 같습니다.

# 1. 최신 코드 가져오기
git clone $REPO_URL /tmp/fix-workspace
cd /tmp/fix-workspace

# 2. 수정 브랜치 생성
git checkout -b auto-fix/$ERROR_ID

# 3. 문제 분석(Claude Code 개입)
claude-code --context $ERROR_CONTEXT --prompt "이 버그의 근본 원인을 분석하라"

# 4. 수정 작성
claude-code --prompt "테스트를 포함한 수정 코드를 작성하라"

# 5. 테스트 실행
npm test

# 6. 커밋 및 push
git add .
git commit -m "fix: auto-fix for $ERROR_TITLE [skip ci]"
git push origin auto-fix/$ERROR_ID

# 7. PR 생성
gh pr create --title "Auto-fix: $ERROR_TITLE" --body "..."

여기서 Claude Code의 핵심 가치는 ‘코드 이해’입니다. 오류 스택만 보고 무작정 수정하는 것이 아니라 다음과 같이 작업합니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

• 관련 코드 파일을 읽고 비즈니스 로직을 이해합니다.
• 오류 전파 경로를 분석해 실제 근본 원인을 찾습니다.
• 프로젝트의 코드 스타일에 맞게 수정합니다.
• 수정 효과를 검증하는 단위 테스트를 생성합니다.

4단계: GitHub PR 자동화

PR이 생성되면 OpenClaw는 GitHub webhook을 계속 모니터링합니다.

- id: watch-pr
  command: github.watch-pr $auto-fix.pr_number

- id: ci-status
  command: poll "github.checks $auto-fix.pr_number"
  until: $ci-status.completed == true
  timeout: 30m

- id: notify-review
  command: slack.send "#dev"
  args:
    message: |
      자동 수정 PR 준비 완료: ${auto-fix.pr_url}
      CI 상태: ${ci-status.conclusion}
      검토 후 병합해 주세요

그러면 PR 링크와 CI 결과가 담긴 Slack 메시지를 받게 됩니다. 링크를 열어 코드를 검토하고 문제가 없으면 병합하면 됩니다. 전체 과정에서 직접 코드를 가져오거나 수정하고 테스트를 실행할 필요가 없습니다.

고급 팁—워크플로를 더 스마트하게 만들기

기본 설정을 실행한 뒤 몇 가지 고급 기능을 추가하면 더 편리하게 사용할 수 있습니다.

버그 등급별 처리

모든 버그를 자동으로 수정할 필요는 없습니다. 저는 classify 단계에 다음과 같은 간단한 규칙 엔진을 추가했습니다.

• P0(Critical): 시스템 중단, 데이터 손실 → 즉시 담당자에게 알림
• P1(High): 핵심 기능 사용 불가 → 알림 + 자동 수정 시도(사람이 확인한 뒤 제출)
• P2(Medium): 비핵심 기능 오류 → 완전 자동 수정
• P3(Low): 예외적인 case, 개선 제안 → backlog에 기록하고 매주 일괄 처리

사람의 확인 지점

기술적으로는 올바르지만 비즈니스 측면에서 문제가 있을 수 있는 수정도 있습니다. 그래서 approval 단계를 추가했습니다.

- id: propose-fix
  command: claude-code.generate-fix

- id: human-approval
  command: slack.interactive
  args:
    message: "AI가 다음과 같은 수정을 제안했습니다. 제출을 승인하시겠습니까?"
    buttons: ["승인", "거부", "수정 필요"]
  timeout: 4h

- id: submit-if-approved
  command: github.create-pr
  condition: $human-approval.choice == "승인"

이렇게 하면 민감한 작업을 AI가 독단적으로 처리하지 않습니다.

실패 시 재시도 및 롤백

Claude Code도 항상 수정에 성공하는 것은 아닙니다. 테스트가 실패하면 자동으로 재시도할 수 있습니다.

- id: fix-attempt
  loop: 3
  sub-lobster: claude-code-fix
  break-on: $fix-attempt.tests_passed

- id: escalate-if-failed
  command: slack.send "#dev-escalation"
  condition: !$fix-attempt.tests_passed

세 번 모두 실패하면 담당자에게 인계를 요청합니다.

여러 저장소 지원

저희 회사에는 각각 독립된 저장소를 사용하는 마이크로서비스가 열 개 넘게 있습니다. OpenClaw에는 여러 프로젝트를 매핑할 수 있습니다.

projects:
  payment-service:
    repo: github.com/acme/payment
    sentry_project: payment-api
    auto_fix: true

  user-service:
    repo: github.com/acme/users
    sentry_project: user-api
    auto_fix: false  # 이 서비스에는 아직 자동 수정을 사용하지 않음

이렇게 하나의 OpenClaw 인스턴스로 여러 프로젝트를 지원할 수 있습니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

효과 평가 및 주의 사항

이 시스템을 3개월간 운영한 결과는 다음과 같습니다.

• 포착한 전체 버그: 127건
• 자동 수정 성공: 89건(70%)
• 수정 후 테스트 통과: 78건(61%)
• 사람의 검토 후 병합: 72건(57%)

즉, 버그의 약 60%는 제가 직접 손댈 필요가 전혀 없었고 아침에 PR을 확인하고 병합만 하면 됐습니다.

시간 절약 효과는 더 뚜렷했습니다. 이전의 일반적인 버그 처리 과정은 발견(평균 2시간) → 위치 파악(30분) → 수정(30분) → 테스트(20분) → PR 제출(10분)이었습니다. 총 4.5시간입니다.

현재는 발견(실시간) → AI 수정(10분) → 사람의 검토(5분)로 바뀌었습니다. 4.5시간이 15분으로 줄었습니다.

하지만 솔직히 이 시스템에도 한계는 있습니다.

적합한 상황:

• 널 포인터, 경계 조건, API 시간 초과처럼 유형이 알려진 반복 버그
• 명확한 스택 정보가 있는 런타임 오류
• 코드베이스 구조가 명확하고 테스트 커버리지가 충분한 프로젝트

적합하지 않은 상황:

• 사람의 의사 결정이 필요한 아키텍처 설계 문제
• 여러 시스템 간 조율이 필요한 복잡한 버그
• 테스트 커버리지가 없는 레거시 코드(AI가 수정해도 안심하고 병합하기 어려움)

위험 통제:

• AI에 프로덕션 환경 쓰기 권한을 절대 부여하지 마세요.
• 모든 자동 수정은 반드시 PR을 통해 정상적인 검토 절차를 거쳐야 합니다.
• AI가 무엇을 변경했는지 알 수 있도록 전체 감사 로그를 보존하세요.
• AI의 수정 품질을 정기적으로 확인하고 모델 prompt를 조정하세요.

정리

지금까지 설명한 OpenClaw + Claude Code 하이브리드 워크플로는 본질적으로 ‘모니터링’과 ‘수정’이라는 두 단계를 자동화합니다. OpenClaw는 잘하지 못하지만 반드시 필요한 일(24시간 감시)을 맡고, Claude Code는 잘하는 일(코드 작성)을 맡습니다. 두 도구를 결합하면 ‘지치지 않는 주니어 개발자’를 구현할 수 있습니다. 일을 처리할 수 있지만 최종 확인은 사람이 해야 합니다.

이 설정의 핵심 가치는 ‘개발자 대체’가 아니라 반복 작업 제거에 있습니다. 사람의 지혜가 진정으로 필요한 일에 에너지를 집중할 수 있게 해줍니다.

on-call 때문에 힘들거나 팀이 반복 버그로 자주 어려움을 겪고 있다면 이 방식을 시도해 보길 권합니다. 특정 오류 유형을 자동으로 수정하는 것처럼 가장 단순한 상황부터 시작한 뒤 점차 확장하세요.

미래의 개발 워크플로는 높은 확률로 이런 ‘사람의 의사 결정 + AI 실행’ 방식이 될 것입니다. 일찍 받아들일수록 일찍 퇴근할 수 있습니다.