"Automating Playwright with Claude Code" 시리즈의 파트 3입니다. 놓치셨다면 파트 1: Getting Started with Claude Code and Playwright CLI와 파트 2: Playwright CLI vs MCP를 확인해 보세요.

파트 2에서 우리는 동일한 테스트에 대해 Playwright MCP와 Playwright CLI 사이에 거의 90,000토큰의 차이가 있음을 확인했습니다. 하지만 도구 선택은 하나의 레버일 뿐입니다. Claude Code를 사용하여 더 긴 테스트 작성 세션을 실행하게 되면 — 단 하나의 테스트가 아니라 전체 회귀 테스트 스위트 (regression suite)를 구축하게 되면 — 몇 가지 일상적인 습관이 토큰 비용과 컨텍스트 윈도우 (context window)에 그만큼 큰 차이를 만듭니다. 이 포스트에서는 지속적으로 효과를 발휘하는 습관들을 다룹니다.

테스트 자동화에서 토큰 사용량이 중요한 이유

• 긴 세션은 컨텍스트 제한에 도달합니다. 테스트해야 할 폼 (form)이 15개 이상인 회귀 테스트 스위트는 매 단계마다 불필요한 상태 (state)를 다시 전송할 경우 세션을 실제로 고갈시킬 수 있습니다.
• 비용은 사용량에 따라 증가합니다. 정액제 구독이 아닌 API 가격 정책을 사용하는 경우, 토큰을 많이 사용하는 세션은 직접적으로 더 큰 청구서로 이어집니다.
• 낭비된 토큰은 낭비된 시간을 의미합니다. 세션이 비대해지면 응답 속도가 느려지고, Claude는 어지러운 컨텍스트 속에서 관련 스레드 (thread)를 찾기 위해 더 많은 노력을 기울여야 합니다.
• 좋은 습관은 복리로 작용합니다. 이 팁들 중 어느 것도 단독으로는 극적이지 않지만, 하루 종일 이어지는 테스트 작성 과정에서 함께 쌓이면 훨씬 더 길고 저렴한 세션을 만드는 데 기여합니다.

전제 조건

• Claude Code가 설치 및 설정되어 있어야 합니다 (Playwright CLI 설정도 필요한 경우 파트 1을 참조하세요).
• Claude Code 세션 내에서 슬래시 명령어 (/clear, /compact)를 실행하는 데 익숙해야 합니다.

목차

1. 모든 작업을 타이트하게 범위 지정하기
2. 관련 없는 작업 사이에는 /clear 사용하기
3. 컨텍스트가 무분별하게 커지도록 두는 대신 /compact 사용하기
4. 기본적으로 헤드리스 모드 (Headless Mode) 선호하기
5. 반복적인 작업을 스크립트와 스킬 (Skills)로 밀어넣기
6. CI에서 도구 버전 고정하기
7. 결론

1단계: 모든 작업을 타이트하게 범위 지정하기

가장 큰 레버이자 가장 단순한 방법은 다음과 같습니다: Claude가 무엇을 다뤄야 하는지 구체적으로 지정하는 것입니다.

❌ 앱 전체를 탐색하고 발견하는 모든 것을 테스트하세요.
✅ /login의 로그인 양식을 테스트하세요: 유효한 자격 증명, 빈 비밀번호, 그리고 잘못된 비밀번호 케이스를 포함합니다.

• 광범위하고 개방적인 지침은 Claude가 여러 페이지를 탐색하고, 추가적인 스냅샷 (snapshots)을 찍고, 실제로 테스트할 필요가 없는 경로까지 탐색하도록 유도하며, 이 모든 과정은 토큰 (tokens)을 소모합니다.
• 범위가 지정된 지침은 범위가 지정된 결과를 가져옵니다: Claude는 해당 양식과 정확히 관련된 페이지와 요소들만 다룹니다.
• 만약 더 넓은 탐색을 원한다면, 실제 테스트와 동일한 요청에 묶어서 하지 말고, 별도의 의도적인 단계(예: "먼저 이 페이지의 모든 양식을 나열하세요")로 수행하세요.

2단계: 관련 없는 작업 사이에는 /clear를 사용하세요

/clear

• 서로 관련 없는 작업으로 전환할 때마다 이 명령어를 실행하세요. 예를 들어, 로그인 양식 테스트를 마치고 결제 흐름 (checkout flow)을 시작하는 경우입니다.
• 이 명령어를 사용하지 않으면, Claude의 컨텍스트 (context)에 이전 작업의 스냅샷 기록, 도구 출력 (tool outputs), 대화 턴 (conversation turns)이 계속 누적되며, 이 중 어느 것도 다음 작업과 관련이 없습니다.
• 경험 법칙: 다음에 요청하려는 내용이 방금 마친 작업과 아무런 관련이 없다면, 먼저 정리(clear)하세요.

3단계: 컨텍스트가 제어 없이 커지게 두는 대신 /compact를 사용하세요

/compact

• 이전 컨텍스트가 진정으로 필요한 작업(동일한 기능을 작업 중이지만 단계가 많이 진행된 경우)의 경우, /compact는 대화를 삭제하는 대신 지금까지의 대화를 요약합니다. 이를 통해 모든 가공되지 않은 도구 출력 (raw tool outputs)을 계속 가져가지 않으면서도 연속성을 유지할 수 있습니다.
• 컨텍스트 경고가 나타날 때까지 기다리지 말고, 긴 세션에서는 이 기능을 선제적으로 사용하세요.

4단계: 기본적으로 헤드리스 모드 (Headless Mode)를 선호하세요

• 헤디드 (Headed, 가시적) 브라우저 세션은 활발하게 디버깅 중이며 무슨 일이 일어나고 있는지 보고 싶을 때 유용하지만, 더 많은 탐색적 스크린샷 촬영과 상호작용을 유발하는 경향이 있습니다.
• 흐름을 이미 알고 있는 일상적인 테스트 작성 시에는 헤드리스 모드를 기본으로 사용하고, 실제로 무언가 실패하여 그 이유를 확인해야 할 때만 헤디드 모드로 전환하세요.

5단계: 반복 가능한 작업을 스크립트와 Skill로 밀어넣기

만약 여러 세션에 걸쳐 Claude에게 동일한 단계(예: 매 테스트 전 팀의 표준 로그인 흐름 등)를 반복해서 설명하고 있다면, 이는 매번 새로운 프롬프트(Prompt)로 입력할 것이 아니라 스크립트(Script)나 Skill로 만들어야 한다는 신호입니다.

.claude/skills/playwright-form-tester/SKILL.md

• 스크립트의 *출력값(output)*이 토큰을 소모하는 것이지, 그 출력을 만들어낸 로직이 소모하는 것이 아닙니다. 따라서 결정론적인(deterministic) 단계들은 매번 새로 추론하도록 지시하는 것보다 스크립트로 실행하는 것이 훨씬 저렴합니다.
• Skill은 실제로 관련이 있을 때만 컨텍스트(Context)에 로드되므로, 관련 없는 작업에서 비용을 지불할 필요도 없습니다.
• 이 시리즈의 4부에서 정확히 이 사용 사례를 위한 완전한 Skill 예제를 구축할 예정입니다.

6단계: CI에서 도구 버전 고정하기

npm install -g @playwright/cli@1.2.0

• CI(지속적 통합)에서 @latest를 사용하는 것은 업스트림(upstream) 업데이트가 파이프라인 중간에 동작을 조용히 변경하여 재시도(retry)를 유발할 수 있음을 의미하며, 재시도는 토큰 비용을 두 배로 발생시킵니다.
• CI 설정에서 Playwright CLI와 브라우저 바이너리(browser binaries) 모두에 대해 명시적인 버전을 고정하고, 자동으로 업데이트하기보다는 의도적으로 업그레이드하세요.

결론

이러한 습관들은 하나하나 복잡하지 않지만, 이들이 모이면 회귀 테스트(regression suite) 도중에 동력을 잃어버리는 Claude Code 세션과 하루 종일의 테스트를 여유롭게 완수하는 세션 사이의 차이를 만들어냅니다. 이 시리즈의 마지막 게시물에서는 이러한 아이디어 중 여러 가지를 결합하여 Playwright 폼 테스트를 위한 실제 재사용 가능한 Skill, 즉 이 시리즈 전체를 하나로 묶어주는 SKILL.md 파일을 구축해 보겠습니다.

여러분의 현재 Claude Code 토큰 절약 습관은 무엇인가요? 제가 놓친 것이 있다면 댓글로 알려주세요!