_"Automating Playwright with Claude Code" 시리즈의 6부입니다. 4부에서는 하나의 Skill을 구축했고, 5부에서는 왜 많은 Skill을 설치해도 모든 세션이 무거워지지 않는지 배웠습니다. 이 포스트는 이 두 가지를 모두 사용하여 단일 Skill을 실제 테스트 스위트의 더 많은 부분을 커버하는 작고 조직화된 **pack(팩)*으로 성장시킵니다.

하나의 Skill은 유용합니다. 하지만 팩으로 조직화된 몇 가지 관련된 Skill들은 실제로 팀의 온보딩 문서(onboarding docs)의 상당 부분을 대체할 수 있는 것입니다. 이 포스트는 4부의 playwright-form-tester Skill을 가져와서 5부의 점진적 공개(progressive disclosure) 모델을 사용하여 세 개의 Skill로 구성된 팩 — locator policy(로케이터 정책), page object generator(페이지 오브젝트 생성기), 그리고 flaky-test debugger(플래키 테스트 디버거) — 으로 확장합니다. 이를 통해 사용하지 않는 토큰을 소모하지 않도록 합니다.

하나의 거대한 Skill 대신 Skill Pack을 구축해야 하는 이유

• 단일 책임 원칙, 좋은 코드와 동일함. 모든 것을 다루려는 하나의 거대한 Skill보다 관심사(concern)당 하나의 Skill을 두는 것이 정확하게 트리거하기 더 쉽습니다.
• 독립적인 트리거링. locator-policy Skill과 flaky-test-debugger Skill은 완전히 다른 요청에서 실행됩니다. 이들을 하나의 파일로 묶는 것은 절반의 시간 동안 관련 없는 지침을 로드해야 함을 의미합니다.
• 중복이 아닌 공유된 참조. 팩은 세 개의 별도 파일에서 동일한 컨벤션을 반복하는 대신, Skill 전체에 걸쳐 단일 references/ 폴더를 공유할 수 있습니다.
• 팀과 함께 성장함. 새로운 팀원들은 여러분의 locator 컨벤션, page object 스타일, 그리고 flaky-test 분류(triage) 프로세스를 자동으로 습득하게 됩니다. 이는 더 넓은 "Skill pack" 생태계(qaskills.sh와 같은 디렉토리)가 구축된 것과 동일한 개념입니다.

사전 요구 사항 (Prerequisites)

• 본 시리즈의 Part 4 (playwright-form-tester Skill) 및 Part 5 (점진적 공개 (progressive disclosure))를 완료해야 합니다.

• .claude/skills/ 아래에 여러 개의 형제 폴더 (sibling folders)를 생성하는 데 익숙해야 합니다.

목차 (Table of Contents)

1. Pack 계획하기
2. Skill 1: 로케이터 정책 (Locator Policy)
3. Skill 2: 페이지 오브젝트 생성기 (Page Object Generator)
4. Skill 3: Flaky 테스트 디버거 (Flaky Test Debugger)
5. 공통 참조 폴더 공유하기
6. 전체 Pack 검증하기
7. 결론

Step 1: Pack 계획하기

무엇인가를 작성하기 전에, 설명이 중복되지 않도록 어떤 Skill이 어떤 트리거 (trigger)를 소유하는지 매핑하는 것이 도움이 됩니다:

.claude/skills/
├── playwright-form-tester/
├── playwright-locator-policy/
...

Step 2: Skill 1 — 로케이터 정책 (Locator Policy)

이 Skill은 Claude가 취약한 CSS 선택자 (CSS selectors)를 기본값으로 사용하게 두는 대신, 일관된 로케이터 전략을 강제합니다.

---
name: playwright-locator-policy
description: Enforce locator strategy when writing or reviewing Playwright
...

Step 3: Skill 2 — 페이지 오브젝트 생성기 (Page Object Generator)

이 Skill은 페이지 스냅샷을 팀의 컨벤션 (conventions)에 맞는 페이지 오브젝트 (Page Object) 클래스로 변환합니다.

---
name: playwright-page-object-generator
description: Generate or update Playwright Page Object Model classes. Use
...

이 Skill이 2단계에서 locator-policy Skill의 컨벤션을 명시적으로 참조하고 있다는 점에 주목하세요. Pack 내의 Skill들은 전체 정책을 인라인 (inline)으로 반복하지 않고도 서로의 표준에 의존할 수 있습니다.

Step 4: Skill 3 — Flaky 테스트 디버거 (Flaky Test Debugger)

이 Skill은 완전히 다른 트리거를 처리합니다: 작성이 아닌 진단 (diagnosing)입니다.

name: playwright-flaky-test-debugger
description: 간헐적으로 실패하는 Playwright 테스트를 진단합니다. 다음 상황에서 사용하세요
...

3단계의 가드레일 (guardrail)에 주목하세요. 이는 AI 지원 QA 작업의 베스트 프랙티스가 된 "절대 조작하지 말 것"이라는 지침을 반영합니다. 즉, 추측이 아닌 증거를 보고해야 합니다.

5단계: 공통 참조 폴더 공유하기

여러 Skill이 동일한 긴 참조 자료(예: getByRole에 대한 팀의 전체 접근성 이름 규칙)를 필요로 한다면, 이를 중복해서 복사하는 대신 공유된 위치에 한 번만 두세요:

.claude/skills/playwright-shared/references/accessible-naming.md

그런 다음, 동일한 내용을 세 개의 별도 SKILL.md 본문에 붙여넣는 대신, 해당 자료가 필요한 모든 Skill에서 상대 경로를 통해 이를 참조하도록 설정하세요. 5부에서 다룬 점진적 공개 (progressive disclosure) 모델에 따라, 이 파일은 실제 단계에서 호출될 때만 로드되므로, 공유한다고 해서 추가 비용이 발생하지 않습니다.

6단계: 전체 팩 검증하기

Claude Code 세션을 재시작한 다음, 각 트리거를 독립적으로 테스트하세요:

"Remember me" 체크박스에 대한 로케이터 (locator)를 추가해줘.
→ playwright-locator-policy가 실행되어야 함

...

만약 동일한 요청에 대해 두 개의 Skill이 실행되거나, 혹은 아무것도 실행되지 않는다면, 각 Skill의 description 필드를 다시 확인하세요. 5부에서 다루었듯이, 이는 거의 항상 Skill 본문의 버그가 아니라 설명(description)의 문제입니다.

결론

단일 Skill은 반복되는 하나의 대화를 해결합니다. 반면, 각 Skill이 명확하고 중복되지 않는 트리거를 갖도록 계획하고 공통 참조를 공유하는 '팩 (pack)'은, 특정 세션에서 사용하지 않는 Skill에 대한 토큰 비용을 들이지 않으면서도 팀의 온보딩 문서를 실질적으로 대체하기 시작합니다. 다음 포스트에서는 이 전체 팩에 명시적인 가드레일과 인간 검토 게이트 (human-review gates)를 추가하여, 어떤 Skill도 조작된 결과를 검토 없이 배포하지 않도록 만들 것입니다.

여러분은 자신만의 Skill을 팩으로 그룹화해 보셨나요? 어떤 것들이 들어있나요? 댓글로 알려주세요!