(LLM실전) Claude Code 200% 활용: CLI부터 Chrome 제어까지 (feat. QA Arena)

QA-Labs Arena 빌더·2026년 1월 13일

QA Arena

목록 보기

3/6

📢 오픈 베타 테스트 참여 안내
이 프로젝트는 현재 오픈 베타 중입니다.
"내 테스트 코드는 몇 점일까?" 궁금하신 분들은 아래 링크에서 체험해보세요!
👉 QA Arena 바로가기

"AI가 코드 짜주는 세상, 진짜 됩니다."

QA Arena 프로젝트의 435개 커밋 중 95% 이상은 AI와 함께 작성했습니다.

단순히 "이 함수 짜줘"수준이 아닙니다. 배포 자동화, 일일 모니터링 리포트, E2E 테스트 검증, 심지어 EC2 접속부터 롤백까지 AI가 처리합니다.

특히 최근 추가된 Claude Chrome 기능 덕분에 터미널에 갇혀있던 AI가 실제 브라우저를 보며 UI 테스트까지 수행하게 되었습니다.

어떻게 가능했냐고요? Claude Code의 심화 기능인 Skills, Agents, 그리고 Chrome(Beta)을 제대로 엮었기 때문입니다.

🤖 1. Claude Code: 단순한 CLI가 아닙니다

Claude Code는 Anthropic의 CLI 도구지만, 핵심은 "맥락(Context) 관리"와 "도구 확장(Tool Use)"에 있습니다.

VS Code의 Copilot과 가장 큰 차이점은 '내가 시키는 대로 하는 비서'가 아니라, '내가 가르친 대로 움직이는 주니어 개발자'에 가깝다는 점입니다.

💡 핵심 차별점

Project Context: 프로젝트 전체 구조를 이해하고 작업합니다.
Tool Use: 터미널 명령어 실행, 파일 편집, 브라우저 제어(Chrome)가 가능합니다.
Cost Management: 필요한 파일만 읽도록 제어하여 토큰 비용을 아낍니다.

📋 2. CLAUDE.md: "시키기 전에 규칙부터 정하라"

많은 분들이 CLAUDE.md를 단순히 "프로젝트 설명서" 정도로 생각합니다. 하지만 실전에서는 "AI의 행동 강령(Constitution)" 역할을 해야 합니다.

실제 사용 중인 CLAUDE.md (일부)

# QA Labs 개발 가이드

## 🏗️ 아키텍처 원칙 (필독)
- **Layered Architecture**: API → Service → Repository 계층을 엄격히 준수할 것.
- **테스트 우선**: 새로운 기능을 짤 때는 `tests/` 폴더에 실패하는 테스트 케이스를 먼저 만들고 구현할 것.
- **Docker**: 로컬 실행 시 `docker compose up` 외에 별도 가상환경 실행 금지.

## 🚨 Error Handling Protocol
- 500 에러 발생 시: 즉시 로그를 분석하고, 사용자가 아닌 시스템 관리자에게 알림을 보내는 로직을 제안할 것.
- DB 마이그레이션: `alembic` 자동 생성 후 반드시 `--autogenerate` 결과를 인간에게 리뷰 요청할 것 (절대 바로 적용 금지).

## 🛡️ 토큰 절약 (Cost Optimization)
- `node_modules`, `venv`, `target`, `dist` 폴더는 절대 읽지 말 것.
- 로그 파일은 `tail -n 50`으로 마지막 50줄만 읽을 것.

## 개발 워크플로우
- **Task 시작 시**: 사양 문서(docs/specs/) 필수 확인
- **Task 완료 시**: 테스트 실행 → 커밋
- **200줄 이상 변경**: 사용자 확인 요청

왜 효과적인가?

Before (CLAUDE.md 없음)	After (CLAUDE.md 있음)
"EC2에 어떻게 접속해?" 매번 설명	SSM 사용한다는 걸 이미 앎
"Docker 구조가 어떻게 되지?"	Docker-in-Docker 구조 파악됨
Windows/Linux 경로 혼동	로컬=Windows, 서버=Linux 구분

Why? AI가 코드를 짤 때 매번 "Service 계층 분리해줘"라고 말할 필요가 없어집니다. CLAUDE.md에 박제해두면 AI가 알아서 구조를 지킵니다.

🌐 3. Claude Chrome: 터미널 밖으로 나온 AI (Killer Feature) ⭐

최근 업데이트로 Claude Code가 Headless가 아닌 실제 Chrome 창을 띄워서 제어할 수 있게 되었습니다.

QA 엔지니어로서 이건 혁명입니다. 기존에는 AI가 코드는 짜줘도, 그 코드가 화면에 어떻게 렌더링 되는지는 '상상'해야 했습니다. 이제는 '직접 보고' 검증합니다.

🔍 활용 사례 1: 시각적 회귀 테스트 (Visual Regression)
"로그인 페이지의 버튼이 모바일에서 깨지는지 확인해줘"라고 시키면, Claude가 실제로 브라우저를 띄워 확인합니다.

$ claude "모바일 뷰포트에서 로그인 버튼이 가려지는지 확인해."

Claude의 행동:
1. npm run dev 실행
2. Chrome 실행 → localhost:3000 접속
3. 창 크기 조절 (Mobile Viewport)
4. 스크린샷 캡처 및 시각적 분석

🔍 활용 사례 1: E2E 통합테스트 (E2E Inrtegration test)

$ claude 실 환경에서 주요 기능에 대한 통합테스트를 진행해줘

QA Arena 적용기: 런칭 직전, 실제 배포된 사이트에서 회원가입부터 문제 풀이 제출까지의 User Flow를 Claude Chrome에게 시켰습니다. Playwright 스크립트를 짜는 단계를 건너뛰고, AI가 직접 유저처럼 클릭하며 테스트를 수행했습니다.

🛠️ 4. 커스텀 스킬(Skills): 반복 작업 자동화

쉘 스크립트(.sh)와 Claude Skill의 차이는 "지능형 에러 핸들링" 입니다.

스크립트는 에러 나면 죽지만, 스킬은 에러 나면 "고쳐서 다시 시도"합니다.

프로젝트 스킬 구조

.claude/
├── commands/             # 간단한 명령어
│   ├── check-sync.md     # 로컬-EC2 싱크 확인
│   ├── deploy.md         # 빠른 배포
│   └── logs.md           # 통합 로그 확인
│
├── skills/               # 복잡한 워크플로우
│   ├── ec2-deploy/       # 9단계 배포 자동화
│   ├── docker-debug/     # Docker 문제 진단/복구
│   ├── code-review/      # 코드 리뷰 자동화
│   ├── daily-report/     # 일일 모니터링 리포트 ⭐ NEW
│   ├── submission-test/  # E2E 테스트
│   └── pytest-problem-reviewer/
│
└── agents/               # 가상 팀원 시스템 ⭐ NEW
    ├── qa-engineer/      # 테스트 전담
    ├── db-admin/         # DB 관리 전담
    ├── docs-writer/      # 문서화 전담
    └── sre-devops/       # 인프라 전담

🔥 실전 스킬: EC2 SSM 배포 자동화 (`/ec2-deploy`)

# .claude/skills/ec2-deploy.md

## Description
안전하게 프로덕션 배포를 수행합니다. (검증 -> 배포 -> 롤백 준비)

## Steps
1. **Dirty Check**: `git status`가 깨끗한지 확인. 수정 사항 있으면 중단.
2. **Safety Scan**: 코드 내에 하드코딩된 API Key나 Password가 있는지 grep으로 스캔. 발견 시 즉시 중단.
3. **SSH Tunneling**: AWS SSM을 통해 터널링 연결.
4. **Deploy**: `docker compose up -d --build` 실행.
5. **Health Check**: `/health` 엔드포인트가 200 OK를 반환하는지 `curl`로 3회 시도.
   - ❌ 실패 시: 즉시 이전 이미지로 롤백 커맨드 실행 (`docker compose rollback` 등).
   - ✅ 성공 시: 배포 완료 로그 기록.

이 스킬 덕분에 "배포하다가 서버 터지면 어떡하지?"라는 공포에서 해방되었습니다. 에러가 나면 AI가 알아서 롤백하니까요.

### Step 6: EC2 배포

AWS SSM send-command를 통해 EC2에 배포:

```bash
COMMAND_ID=$(aws ssm send-command \
  --instance-ids "i-05b23ecec2bdcd44a" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["cd /home/ssm-user/qa_labs &&
    git rev-parse HEAD > .rollback_point &&
    git pull origin main &&
    docker compose -f docker-compose.prod.yml up -d --build"]' \
  --query 'Command.CommandId' --output text)

📊 5. Daily Report: 아침을 여는 명령어 (/daily-report)

1인 개발자의 가장 큰 적은 '모니터링 시간의 부족함'입니다. 이슈들을 수정해야 할 뿐만 아니라、현황을 토대로 한 기능 개선도 함께 마련해야 합니다. Skill은 이러한 부분을 해결해주었습니다.

실행 명령어

명령	설명
/daily-report	리포트 생성
/daily-report --notify	리포트 + Discord 알림

수집하는 정보:

카테고리	항목
DB 현황	총 사용자, 금일 가입, 총 제출, 금일 제출
문제 통계	문제별 성공/실패/오류 수, 실패율
토큰 사용	AI 코치/힌트/피드백 사용량
오류 현황	발생 시간, 내용, 예상 원인
시스템 리소스	CPU, 메모리, 디스크 사용률
채점 시스템	평균 시간, 타임아웃 수, Worker 상태

실제 출력 예시:

이제 퇴근 후 집에 도착하면 /daily-report를 치는 게 루틴이 되었습니다.

👯 코드 리뷰 자동화 (`/code-review`)

혼자 개발하면 코드 리뷰를 스킵하게 됩니다. 하지만 이 스킬이 있으면? (이건 최근에 런칭한 Plugin을 사용했어요)

## 리뷰 항목

### 코드 품질
- 타입 힌트 사용 여부
- PEP 8/ESLint 스타일 준수
- 복잡도 (너무 긴 함수, 깊은 중첩)

### 보안 검토
- 하드코딩된 비밀번호/API 키
- SQL Injection 가능성
- XSS 취약점

### 성능
- N+1 쿼리 패턴
- 불필요한 반복문

### 테스트 커버리지
- 새 코드에 대한 테스트 존재 여부

출력 예시:

========================================
코드 리뷰 결과
========================================

[보안 검토]
[OK] 민감 정보: 하드코딩된 비밀 없음
[WARN] SQL: raw SQL 사용 발견 (line 45)

[권장 사항]
1. submit_handler 함수 분리 (단일 책임 원칙)
2. line 45의 raw SQL을 ORM 쿼리로 변경

[결론]
[APPROVE] 변경사항 승인됨

배포와 연동:

/ec2-deploy에서 100줄 이상 변경 시 자동으로 /code-review가 호출됩니다. 대규모 변경은 무조건 리뷰를 거치게 되는 거죠.

⚰️ Docker 디버깅 (`/docker-debug`)

컨테이너가 죽었을 때 AI가 알아서 진단합니다.

진단 워크플로우

### Step 1: 컨테이너 상태 확인
docker compose -f docker-compose.prod.yml ps

Step 5: Docker-in-Docker 특수 체크

# Docker 소켓 마운트 확인
docker exec celery_worker ls -la /var/run/docker.sock

# judge 컨테이너가 실행 중인지
docker ps -a | grep judge

자동 복구까지:

문제 유형	자동 수정 명령	위험도
컨테이너 비정상	`docker compose restart {service}`	🟢 낮음
볼륨 권한	`chmod 777 /tmp/qa_arena_judge`	🟢 낮음
네트워크 문제	네트워크 재생성	🟠 중간

위험도가 낮은 건 자동 실행, 높은 건 사용자 확인을 받습니다.

👥 5. Agent 시스템: 가상 팀원을 만들다

Skills만으로는 한계가 있었습니다. 복잡한 작업은 여러 역할이 협업해야 하거든요.
그래서 만든 게 Agent 시스템입니다.

Skills vs Agents 차이

특성	Skills	Agents
컨텍스트	메인 대화 공유	격리된 전용 컨텍스트
도구 접근	전체	역할별 제한
실행 방식	순차 (명령→완료)	독립 세션 (병렬 가능)
용도	단일 작업	지속적 역할 담당

가상 팀원 4명

.claude/agents/
├── qa-engineer/    # QA 엔지니어 (테스트 전담)
├── db-admin/       # DBA (스키마/쿼리 전담)
├── docs-writer/    # 테크니컬 라이터 (문서화 전담)
└── sre-devops/     # SRE (인프라/배포 전담)

QA Engineer Agent

역할

개발자가 기능을 구현하는 동안 백그라운드에서 테스트를 작성

핵심 책임

테스트 케이스 작성 (pytest, Jest, Playwright)
버그 재현 시나리오 생성
회귀 테스트 수행
테스트 커버리지 분석

사용 예시

@qa-engineer "결제 API에 대한 테스트 케이스 작성해줘"
@qa-engineer --background "변경된 코드에 대한 테스트 작성해줘"

Database Admin Agent

역할

비즈니스 로직 없이 데이터 구조에만 집중하여 쿼리 정확도 향상

핵심 책임

스키마 설계 검토, 인덱스 전략
Alembic 마이그레이션 관리
느린 쿼리 분석, 실행 계획 검토
데이터 무결성 검증

안전 규칙

SELECT 쿼리만 직접 실행
DROP/TRUNCATE/DELETE 금지
데이터 수정은 제안만

SRE/DevOps Agent

역할

인프라 설정은 자주 안 건드리므로 별도 Agent로 격리

핵심 책임

배포 워크플로우 실행 (/ec2-deploy 연계)
서비스 상태 확인, 로그 분석
컨테이너 문제 진단 (/docker-debug 연계)
롤백 수행

Docs Writer Agent

역할

개발하는 동안 백그라운드에서 문서 자동 업데이트

변경 감지 → 문서 매핑

변경 파일	업데이트 대상
backend/app/api/*.py	api-reference.md
backend/app/models/*.py	db-schema.md
docker-compose*.yml	infrastructure.md

왜 Agent로 분리했나?

컨텍스트 오염 방지: 인프라 작업 중에 비즈니스 로직이 섞이면 혼란
병렬 실행: 개발하면서 동시에 테스트 작성 가능
권한 제한: 각 Agent가 할 수 있는 행동을 제한 (안전장치)
역할 명확화: "이건 QA가 할 일" 같은 명확한 구분
1인 개발자로서 이러한 역할별 분배는 각각의 전문가를 두고 일하는 듯한 효과를 얻을 수 있었어요.

📊 6. 실제 효과

배포 시간 단축

항목	Before	After
배포 전체	30분	5분
에러 디버깅	1시간+	10분
롤백	패닉	자동

운영 효율

Before 😰	After 😎
`$ ssh ec2` `$ docker ps` `$ docker logs backend` `$ docker logs celery` `$ top` `$ df -h` … (매일 반복) ⏱️ 매일 30분 수동 확인	`$ /daily-report` 📊 DB 현황 🎯 문제별 실패율 🤖 토큰 사용량 🔴 오류 현황 💻 시스템 리소스 ⏱️ 1분 + Discord 알림

코드 품질

항목	Before	After
보안 스캔	가끔 까먹음	매 배포 시 자동
코드 리뷰	혼자라 스킵	100줄 이상 시 자동
테스트	귀찮아서 스킵	Agent가 작성

정신 건강 😇

Before: "배포할 때마다 긴장됨"
After: "그냥 /ec2-deploy 치면 됨"

Before: "서비스 잘 돌아가나...?"
After: "/daily-report --notify" + Discord 알림

💡 7. 실전 활용 팁

Tip 1: 스킬은 작게 시작하라

처음부터 완벽한 스킬을 만들려고 하지 마세요.

1주차: "배포 명령어 3줄" 정도로 시작
2주차: "헬스체크 추가"
3주차: "롤백 로직 추가"
4주차: "코드 리뷰 연동"

저도 처음엔 그냥 git pull && docker compose up이 전부였습니다.

Tip 2: 에러 패턴을 스킬에 녹여라

같은 에러가 2번 나오면, 그건 스킬에 넣을 타이밍입니다.

## 일반적인 문제 패턴

### 패턴 1: 컨테이너 반복 재시작
**원인:** 환경변수 누락, 의존성 미준비
**해결:** .env 파일 확인, depends_on 체크

Tip 3: Agent는 권한을 제한하라

각 Agent에 forbidden_tools를 명시하세요.

# QA Engineer Agent
forbidden_tools:
  - Bash(docker *)      # Docker 조작 금지
  - Bash(git push)      # 푸시 금지
  - Bash(rm -rf)        # 삭제 금지

실수로 위험한 명령이 실행되는 걸 방지합니다.

Tip 4: Daily Report로 하루를 시작하라

# 아침 루틴
/daily-report

# 이상 있으면
/logs --error

# 문제 발견되면
/docker-debug

이 세 단계면 대부분의 운영 이슈를 커버합니다.

⚠️ 8. 주의사항

AI를 너무 믿지 마라

AI도 실수합니다. 특히:

민감 정보 노출: API 키, 비밀번호 커밋 주의
파괴적 명령어: rm -rf, DROP TABLE 같은 건 항상 확인
맥락 손실: 긴 대화에서 초기 지시사항을 까먹을 수 있음

내가 실제로 당한 것

Git 히스토리가 꼬인 적 있음 (다음 편에서 자세히...)
테스트 안 돌리고 커밋한 적 있음
환경변수 실수로 커밋할 뻔함
가이드대로 실행하지 않은 Skill을 실행한 Claude한테 사과를 받음

스킬에 안전장치를 넣어두세요.

## 보안 스캔 (매 배포 시 필수)
```bash
git diff | grep -iE "(password|secret|api_key)" || echo "Clean"

💬 9. 마치며

Claude Code + 커스텀 Skills + Agent 시스템 조합은 1인 개발자의 생산성을 극대화합니다.

특히 QA 엔지니어처럼 반복적인 검증 작업이 많은 역할에게 유용해요.

"AI가 코드 짜주는 세상"은 이미 왔습니다.
문제는 어떻게 활용하느냐입니다.

정리하면:

기능	용도	핵심 가치
CLAUDE.md	프로젝트 맥락 공유	매번 설명 안 해도 됨
Skills	반복 워크플로우 자동화	배포 30분→5분
Agents	가상 팀원 (병렬 작업)	혼자지만 혼자가 아님
Daily Report	운영 모니터링	서비스 상태 한눈에

다음 편에서는 AI에게 Git을 맡겼다가 생긴 일들... 솔직하게 공유합니다.
제가 먼저 삽질했으니까 여러분은 피하세요 😎

📌 다음 화 예고
Ep 3. (회고) AI 믿고 Git 맡겼다가 생긴 일: 의존의 장단점과 탈출 전략

"커밋 메시지도 AI가 쓰고, 브랜치 관리도 AI가 하고... 어느 날 히스토리가 꼬였습니다."
AI 의존의 함정과 건강한 협업 방법을 이야기합니다.

(1/17 금요일 발행)

[Project Info]

Service: https://qa-arena.qalabs.kr
Status: Open Beta (Non-profit Project)
Developer: Ryu Junghyun (QA Engineer)
Feedback: Google Form

📚 참고 자료

QA-Labs Arena 빌더

AI 시대의 테스트 설계. 숨은 버그 탐지율로 실력을 증명합니다.

이전 포스트

(소개) QA 엔지니어의 1인 개발 도전기: 6주 435커밋으로 만든 QA Arena

다음 포스트

(LLM실전) Claude Code 200% 활용: CLI부터 Chrome 제어까지 (feat. QA Arena)

QA Arena

🤖 1. Claude Code: 단순한 CLI가 아닙니다

💡 핵심 차별점

📋 2. CLAUDE.md: "시키기 전에 규칙부터 정하라"

실제 사용 중인 CLAUDE.md (일부)

왜 효과적인가?

🌐 3. Claude Chrome: 터미널 밖으로 나온 AI (Killer Feature) ⭐

🛠️ 4. 커스텀 스킬(Skills): 반복 작업 자동화

프로젝트 스킬 구조

🔥 실전 스킬: EC2 SSM 배포 자동화 (/ec2-deploy)

📊 5. Daily Report: 아침을 여는 명령어 (/daily-report)

👯 코드 리뷰 자동화 (/code-review)

⚰️ Docker 디버깅 (/docker-debug)

진단 워크플로우

Step 5: Docker-in-Docker 특수 체크

👥 5. Agent 시스템: 가상 팀원을 만들다

Skills vs Agents 차이

가상 팀원 4명

QA Engineer Agent

역할

핵심 책임

사용 예시

Database Admin Agent

역할

핵심 책임

안전 규칙

SRE/DevOps Agent

역할

핵심 책임

Docs Writer Agent

역할

변경 감지 → 문서 매핑

왜 Agent로 분리했나?

📊 6. 실제 효과

배포 시간 단축

운영 효율

코드 품질

정신 건강 😇

💡 7. 실전 활용 팁

Tip 1: 스킬은 작게 시작하라

Tip 2: 에러 패턴을 스킬에 녹여라

Tip 3: Agent는 권한을 제한하라

Tip 4: Daily Report로 하루를 시작하라

⚠️ 8. 주의사항

AI를 너무 믿지 마라

내가 실제로 당한 것

💬 9. 마치며

📚 참고 자료

(소개) QA 엔지니어의 1인 개발 도전기: 6주 435커밋으로 만든 QA Arena

AI 믿고 Git 맡겼다가 생긴 일: 의존의 함정과 탈출 전략

0개의 댓글

🔥 실전 스킬: EC2 SSM 배포 자동화 (`/ec2-deploy`)

👯 코드 리뷰 자동화 (`/code-review`)

⚰️ Docker 디버깅 (`/docker-debug`)