"Automating Playwright with Claude Code" 시리즈의 7부입니다. 6부에서 우리는 locator policy, page object generator, flaky test debugger라는 세 가지 스킬 팩(Skill pack)을 구축했습니다. 이 포스트에서는 이 세 가지 모두를 신뢰할 수 있게 유지하는 가드레일(guardrails)을 추가하여, 팀원 중 누구도 검증되지 않은 조작된 결과를 배포하지 않도록 합니다.

6부에서 만든 flaky-test-debugger 스킬에는 이미 "추측을 결과로 보고하지 마세요"라는 한 줄의 가드레일 언어가 숨겨져 있었습니다. 이 포스트는 이 아이디어를 명시적이고 체계적으로 만들어 팩 전체에 적용합니다. 왜냐하면 AI 지원 테스트의 가장 큰 위험은 Claude가 가끔 무언가를 틀리는 것이 아니기 때문입니다. 진짜 위험은, 이를 잡아낼 방법을 구축하지 않는 한 틀린 결과가 맞는 결과만큼이나 매우 자신감 있게 보인다는 점입니다.

테스트 자동화 스킬에 가드레일이 중요한 이유

• 조작된 "통과(pass)"는 테스트가 아예 없는 것보다 더 나쁩니다. 실제로 올바른 것을 검증하지 않고 조용히 성공을 보고하는 테스트는 팀에 잘못된 확신을 줍니다.

• AI 에이전트는 자연스럽게 "확실하지 않습니다"라고 말하지 않습니다. 명시적인 지침이 없으면, 스킬(Skill)은 종종 최선의 추측을 내놓고 이를 사실처럼 제시합니다.

• 인간 검토 게이트(Human-review gates)는 신뢰의 부족이 아니라, 신뢰를 얻는 과정입니다. 목표는 모든 곳에서 Claude의 속도를 늦추는 것이 아니라, 잘못된 결정이 큰 비용을 초래하는 몇몇 지점에서 잠시 멈추는 것입니다.

• 이것이 취미용 스킬과 프로덕션용 스킬을 구분하는 지점입니다. 팀 전체가 의존하는 모든 스킬은 조용히 실패하는 것이 아니라, 크게 실패(fail loudly)해야 합니다.

  사전 요구 사항

• 이 시리즈의 6부 (세 가지 스킬 팩)를 완료했을 것.

• 단순히 새 파일을 작성하는 것보다 기존 SKILL.md 파일을 편집하는 것에 익숙할 것.

  목차

1. 방어해야 할 세 가지 실패 모드 (Failure Modes)
2. 1단계: "절대 조작하지 말 것" 규칙
3. 2단계: 증거 기반 보고 (Evidence-Required Reporting)
4. 3단계: 파괴적이거나 모호한 동작에 대한 인간 검토 게이트 (Human-Review Gates)
5. 단계별 가이드: Part 6 팩에 가드레일(Guardrails) 적용하기
6. 가드레일이 실제로 작동하는지 테스트하기
7. 결론

방어해야 할 세 가지 실패 모드 (Failure Modes)

가드레일(Guardrail) 문구를 작성하기 전에, 정확히 무엇을 방어하려 하는지 아는 것이 도움이 됩니다.

1단계: "절대 조작하지 말 것" 규칙

팩(Pack)에 포함된 모든 스킬(Skill)에는 추측하는 것보다 "이를 확인할 수 없습니다"라고 말하는 것이 더 낫다는 명시적인 지침이 있어야 합니다.

## 가드레일 (Guardrails)
- 새로운 `snapshot`이나 트레이스(trace)를 통해 실제로 관찰하지 않은 테스트 결과는 절대 보고하지 마십시오. 최종 단계 이후 스냅샷이 찍히지 않았다면...
...```

팩 내의 모든 스킬에 일관되게 추가된 이 단일 블록만으로도, "확신에 차 있지만 틀린" 위험의 대부분을 자체적으로 차단할 수 있습니다.

## 2단계: 증거 기반 보고 (Evidence-Required Reporting)

단순히 "추측하지 마라"는 것을 넘어, 모든 주장이 구체적인 무언가를 가리키도록 요구하는 것이 도움이 됩니다.

보고 형식 (Reporting format)

• 모든 통과/실패(pass/fail) 주장은 무엇을 확인했는지 인용해야 합니다 (예: "스냅샷을 통해 확인됨: 성공 배너 텍스트가 'Account created'와 일치함").
  ...```

이것은 모호한 지침("주의하세요")을 Claude가 응답하기 전에 스스로 대조하여 확인할 수 있는 실질적인 사항으로 바꿔줍니다.

3단계: 파괴적이거나 모호한 동작에 대한 인간 검토 게이트 (Human-Review Gates)

어떤 동작들은 잘못되었을 때 다시 수행하는 비용이 저렴합니다. 하지만 테스트 파일을 삭제하거나, 수정 사항을 강제로 푸시(force-push)하거나, 수십 개의 다른 테스트에서 사용되는 공유 픽스처(fixture)를 수정하는 등의 동작은 그렇지 않습니다. 가드레일은 멈춰서 질문해야 하는 순간을 명시적으로 지정해야 합니다.

## ...하기 전에 멈춰서 질문하십시오
- 새로운 파일을 추가하는 대신, 기존 테스트 파일을 삭제하거나 덮어쓰는 경우.
...```

## 단계별 가이드: Part 6 팩에 가드레일(Guardrails) 적용하기

Part 6에서 다루었던 `playwright-flaky-test-debugger` 스킬에 이를 적용해 보겠습니다. 이 스킬은 이미 프로세스의 3단계에 이러한 개념이 약간 포함되어 있었습니다.

**적용 전 (Part 6 버전):**

3. 이를 뒷받침하는 트레이스(trace)/로그(log)의 구체적인 증거 라인을 포함하여 가장 가능성 높은 원인을 보고하십시오 — 추측을 결과로 보고하지 마십시오.
4. 한 번에 하나의 수정 사항만 제안하십시오; 추측하여 테스트 스펙 전체를 다시 작성하지 마십시오.

**적용 후 (명시적인 가드레일 섹션 추가):**

가드레일 (Guardrails)

• 이를 뒷받침할 구체적인 트레이스(trace)나 로그(log) 라인 없이는 절대 근본 원인을 보고하지 마십시오. 트레이스/로그를 사용할 수 없는 경우, 이를 언급하고 요청하십시오.
  ...```

동일한 패턴을 playwright-locator-policy (여러 테스트에서 사용되는 로케이터(locator)를 교체하기 전에 멈춰서 질문하기)와 playwright-page-object-generator (새 파일을 생성하는 대신 기존 Page Object 파일을 덮어쓰기 전에 멈춰서 질문하기)에도 적용하십시오.

가드레일이 실제로 작동하는지 테스트하기

가드레일은 압박 상황에서 실제로 행동을 변화시킬 때만 유용합니다. 의도적으로 다음과 같이 테스트해 보십시오:

이 테스트가 계속 무작위로 실패합니다. 당신이 최선이라고 생각하는 방식대로 그냥 수정해 주세요.

• 가드레일이 없는 스킬은 추측하여 테스트 전체를 다시 작성할 수 있습니다.
• 위의 가드레일이 적용된 스킬은 대신 먼저 트레이스(trace)/로그(log)를 요청하고, 구체적인 증거를 인용하며, 하나의 타겟팅된 수정 사항을 제안해야 합니다. 즉, 공유된 피스처(fixture)를 건드리기 전에 멈춰야 합니다. 만약 예상한 지점에서 멈추지 않는다면, 가드레일 문구가 일반적인 "주의하십시오"라는 지침보다는 해당 상황에 더 가깝고 구체적이어야 할 가능성이 높습니다.

결론

가드레일(Guardrails)이 없는 스킬 팩(Skill pack)도 여전히 유용할 수는 있지만, 가드레일이 있는 스킬 팩은 모든 결과물을 일일이 감시(babysitting)하지 않고도 팀 전체에 실제로 전달할 수 있는 도구입니다. 이 포스트에서 다룬 "절대 조작하지 말 것(never fabricate)", 증거 요구(evidence-required), 그리고 중단 후 질문(stop-and-ask) 패턴은 추가하기 매우 간단하면서도, 결과물에 대해 신뢰할 수 있는 정도를 극적으로 변화시킵니다. 이것으로 설정부터 도구 선택, 토큰 효율성(token efficiency), 그리고 실제 스킬 팩을 구축하고 강화(hardening)하는 과정에 이르기까지 이번 시리즈의 핵심 메커니즘을 모두 마무리합니다.

스킬(또는 다른 AI 도구)이 잘못된 결과를 확신을 가지고 제시했던 사례를 경험한 적이 있나요? 어떻게 그것을 잡아냈나요? 댓글로 알려주세요!