더 야심찬 작업을 Claude에 위임할수록, Claude가 자신의 작업을 검증할 수 있는 것이 점점 더 중요해집니다.
Claude가 스스로 검증을 더 많이 할수록:
- 장시간 실행되는 작업을 더 독립적으로 처리할 수 있으며
- 최종 결과물의 품질이 향상되고
- 목표 달성까지 필요한 왕복 횟수가 줄어듭니다.
검증이 당신에게 의존하면, 코딩 세션은 턴제 게임이 되고, 에이전트의 유용성을 만드는 자율성을 잃게 됩니다.
좋은 소식은 Claude가 이미 타입 오류, 린트 오류, 실패하는 테스트, 런타임 오류와 같은 결정론적 신호에 대해 스스로 검증하고 있다는 점입니다. 모델이 개선될수록 이 기능은 더욱 향상될 것입니다.
Claude가 항상 추론할 수 없는 것은 Claude가 응답한 후, 그리고 나중에 코드를 프로덕션에 병합하기 전에 당신이 실행하는 수동 검사들입니다.
그러한 검사를 더 많이 인코딩할수록 Claude의 첫 응답이 당신이 원하는 최종 결과에 더 가까워집니다.
당신은 감독하는 시간을 덜 들이고, Claude는 당신이 다른 작업을 하는 동안 계속 진행할 수 있습니다.
프로세스를 문서화하세요
시작하기 좋은 곳은 당신이나 팀이 이미 수행하는 작업의 모범 사례를 문서화하는 것입니다.
프론트엔드의 경우 일반적으로: 개발 서버를 실행하고, 브라우저를 열고, 콘솔에서 오류를 확인하고, 사용자처럼 클릭하며 레이아웃 이동이나 느린 탐색과 같은 문제를 살펴보는 것입니다.
모든 도메인에는 고유한 버전이 있습니다. 각 단계마다 Claude가 검증에 사용할 수 있는 도구가 있을 것입니다.
프로세스를 스킬로 인코딩하세요
프로세스가 명확해지면 가능한 한 많이 스킬로 인코딩하세요. skill-creator 플러그인을 설치한 다음 Claude에게 인터뷰를 요청하세요:
1/skill-creator 프론트엔드 변경 사항을 종단 간 검증하는 스킬을 생성하세요. 내 워크플로에 대해 인터뷰해 주세요.
프로세스를 말로 표현하기 어렵다면, 먼저 Claude에게 도메인 모범 사례를 요청하고 종단 간 검증 흐름이 어떻게 생겼는지 보여주도록 하세요.
취향과 판단은 코드화하기 어렵지만, 많은 검사에는 Claude가 측정할 기준이 있습니다: 성능 예산, 접근성 체크리스트, 디자인 시스템 규칙, 좋은 예와 나쁜 예 등.
예를 들어, 프론트엔드 스킬에는 Chrome DevTools MCP 또는 Agent browser.를 통해 성능 추적을 캡처하는 지침이 포함될 수 있습니다.
1---2name: frontend-verify3description: 브라우저에서 프론트엔드 변경 사항을 검증합니다. UI(페이지, 컴포넌트, 타이포그래피, CSS 스타일) 변경이 이루어질 때마다 실행합니다.4---56# 프론트엔드 검증78- 실제 브라우저에서 2단계 검증 과정을 실행합니다.9- 문제를 해결하고 사용자에게 응답하기 전에 다시 검증합니다.1011## 1단계 — 변경 사항이 예상대로 동작하는지 검증12131. 브라우저에서 URL을 엽니다:14 - Claude Code 데스크톱 앱에서는 내장 미리보기를 사용합니다.15 - CLI에서는 Chrome DevTools MCP를 사용합니다.162. 새 요소와 상호작용하여 예상대로 렌더링되고 동작하는지 확인합니다.1718## 2단계 — 변경 사항이 모바일 감사를 통과하는지 검증19201. Chrome DevTools MCP를 통해 새 페이지에서 URL을 엽니다.212. 성능 추적을 실행하고 Core Web Vitals를 감사합니다.
다른 검사는 통과/실패보다는 정성적입니다. 예를 들어 데이터를 과거 기준과 비교하는 것과 같습니다. 이러한 경우 Claude와 함께 출력을 평가하기 위한 루브릭을 설정할 수 있습니다.
두 번째 에이전트로 병합 전 코드 검토
위의 모든 것은 에이전트 루프 내에서 발생합니다. 병합 직전에 두 번째 검증 단계가 있으며, 다른 에이전트에게 검토를 요청할 수 있습니다.
새로운 에이전트는 코드를 작성한 에이전트와 동일한 편향을 가지지 않습니다. 자체 컨텍스트를 가지고 있으며 이전 대화의 영향을 받지 않습니다. 이러한 격리는 검토를 더 정직하게 만들고 첫 번째 에이전트가 놓쳤을 수 있는 것을 찾아냅니다.
수동에서 자동화까지 몇 가지 옵션:
- /review (내장 스킬) - 터미널에서 PR을 빠르게 한 번 읽습니다.
- /code-review (설치 가능한 플러그인) - 여러 하위 에이전트를 병렬로 실행하여 각각 다른 각도에서 diff를 읽고, 신뢰도에 따라 결과를 점수화하며, 결과를 PR에 게시합니다.
- Claude Code Review - 팀 및 엔터프라이즈 요금제를 위해 GitHub를 통해 모든 PR에서 자동으로 실행되는 관리형 서비스입니다.
어느 것을 선택하든, 프로덕션에 병합하기 전에 마지막 방어선을 두는 것이 도움이 됩니다.
종합하기
이제 두 가지 계층이 있습니다:
- Claude가 빌드하는 동안 실행되는 검증
- 코드를 작성하지 않은 에이전트의 병합 전 검토
둘 다 동일한 개발 수명 주기에 속합니다. 현재의 수동 단계를 생각해 보세요: 변경하고, 정리하고, 작동을 확인하고, 커밋하고, PR을 열고, 검토를 받고, CI를 모니터링합니다.
다른 스킬을 호출하는 스킬을 작성하여 모든 단계를 하나의 워크플로로 통합할 수 있습니다. 예를 들어, Claude Code 팀은 기능 작업 시 실행하는 스킬을 가지고 있으며, 여기에는 다음이 포함됩니다:
- diff를 정리하는
/simplify스킬 - 변경 사항이 종단 간 작동하는지 확인하는 사용자 정의
/verify스킬 - diff가 UI에 영향을 준 경우 디자인 검사
- PR을 열고 구독하는 단계
- CI를 모니터링하고 발생하는 실패를 수정하는 스킬
워크플로가 다르게 보일 수 있지만, 피드백 루프를 만들고 스킬을 묶으면 Claude가 더 많은 작업을 종단 간 검증하고 실행할 수 있습니다.
