Claude Code의 skills 기능을 처음 알게 되었을 때, 솔직히 말하면 머릿속이 잘 정리되지 않았습니다. 문서를 읽고 나면 "이런 게 가능하다"는 건 알겠는데, 막상 제 일상 업무 어디에 어떻게 끼워 넣어야 할지 감이 잘 잡히지 않았습니다. 머리로는 이해해도 손이 잘 안 움직이는, 그런 상태였습니다.
그러다 이번에 처음으로 제 손으로 skill 하나를 만들어 실제로 굴려 보았고, 그 경험을 통해 skills 라는 도구가 어떻게 실무에 안착하는지 한눈에 보게 되었습니다. 이 글에서는 사내 QA 시트 작성을 자동화한 /qa-sheet skill 을 어떻게 만들었는지, 그리고 그 과정에서 어떻게 하면 기획서·피그마·PR 변경 사항을 모두 활용해 사용자 시나리오에 맞는 테스트 케이스를 뽑아 내게 만들 수 있을지 고민했던 내용을 정리해 보려고 합니다.
📌 자동화하고 싶었던 일: QA 시트 작성
저희 팀은 QA 시트를 구글 공유 드라이브로 관리합니다. 새 기능이 배포되기 전에 기획서, 피그마 디자인, GitHub PR 코드 변경 사항을 한꺼번에 살펴보면서, QA 진행자가 따라갈 수 있는 테스트 케이스를 한 줄 한 줄 만들어 갑니다.
진짜 시간을 잡아먹는 부분은 시트 양식을 채우는 작업이 아니라, 이 세 가지 입력을 머릿속에서 합치고 풀어서 의미 있는 테스트 케이스를 뽑아 내는 과정이었습니다. 기획서가 의도한 사용자 흐름은 무엇인지, 피그마 화면에는 어떤 UI 요소와 빈 상태가 있는지, PR 로 들어간 코드 변경이 실제 사용자 행동에 어떤 차이를 만드는지 — 이 셋을 모두 보고 나서야 'QA 진행자가 실제로 따라가 볼 수 있는 시나리오' 가 정리됩니다. 케이스 하나도 빠뜨리지 않으면서 사용자 입장에서 자연스러운 순서로 풀어내려면 매번 적지 않은 집중력이 필요했습니다.
자동화로 이루고 싶었던 것은 단순한 양식 채우기가 아니었습니다.
기획서·피그마·PR 링크를 함께 넘기면 — 그 셋을 교차해서 읽고, 사용자 시나리오에 맞는 테스트 케이스 목록을 뽑아 내 우리 팀 QA 시트 양식 그대로 채워 주는 것.
📌 첫 시도: mcp-google-sheets MCP 서버
처음에는 자연스럽게 MCP를 떠올렸습니다. 구글 시트를 직접 다루는 건 MCP가 가장 어울리는 케이스니까요. mcp-google-sheets 서버도 이미 공개되어 있었고, "이거 붙이면 끝나겠다"는 마음으로 시작했습니다.
그런데 실제로 붙여 보려고 하니 두 가지 벽에 동시에 부딪혔습니다.
1) 인증 방식이 맞지 않았습니다.
mcp-google-sheets는 서비스 계정 인증만 지원하고 OAuth는 지원하지 않았습니다. 회사 구글 계정으로 인증하려면 OAuth가 필요한데, 그 길이 처음부터 막혀 있었던 셈입니다.
2) 서비스 계정에는 공유 드라이브 권한이 없었습니다.
서비스 계정을 발급받아 인증한다 해도, 그 계정은 회사 공유 드라이브의 멤버가 아닙니다. 즉, 우리 팀 공유 드라이브에 파일을 만들거나 수정할 권한 자체가 없는 셈이었습니다.
두 문제를 어떻게든 우회한다고 해도 한 가지가 더 남아 있었습니다. 셀 색상, 병합, 테두리 같은 스타일 기능이 부족했습니다. 저희 팀의 QA 시트 템플릿은 헤더 행이 노란색, 분류 행이 회색, 헤더 셀은 굵은 폰트와 가운데 정렬이 들어간 식으로 시각적 규약이 꽤 정교합니다. MCP가 제공하는 데이터 입력 API만으로는 이걸 그대로 흉내 낼 수 없었습니다.
MCP는 분명 강력하지만, 모든 환경에 맞춰진 도구는 아니라는 사실을 이번에 처음으로 체감했습니다.
📌 세 가지 선택지를 두고 고민한 시간
이 시점에서 제가 고려한 길은 세 가지였습니다.
a안. 사내 공용 서비스 계정을 만들고 공유 드라이브 멤버로 추가한 뒤, 그 계정으로 credentials를 발급해 MCP에 연결
가장 "정공법"에 가까운 안이었습니다. MCP를 끝까지 쓸 수 있다는 매력이 있었지만, 사내 공용 계정 발급은 개인이 빠르게 결정할 수 있는 일이 아니었습니다. 보안·정책 검토가 필요했고, 어렵게 인증을 통과해도 앞서 말한 스타일 기능 부족이 그대로 남아 있었습니다.
b안. 파이썬 구글 시트 CLI 도구로 시트를 직접 생성·조작
MCP를 우회한다는 점에서 후보였지만, 결국 같은 인증 문제(서비스 계정 / OAuth)에서 자유롭지 않았고, 그걸 풀어도 Claude Code skill 안에 매끄럽게 통합하기에는 결합도가 부담스러웠습니다.
c안. 로컬에 마운트된 공유 드라이브에 스크립트로 직접 xlsx 생성
Google Drive for Desktop을 켜 두면 공유 드라이브가 로컬 파일 시스템에 그대로 마운트됩니다. 다시 말해, 이미 제 본인 OAuth 인증을 통해 접근 가능한 상태라는 뜻입니다. 거기에 openpyxl로 xlsx를 만들어 떨어뜨리면, 마운트 동기화가 알아서 구글 드라이브로 올려 주고 구글 시트로의 변환도 자동으로 처리됩니다.
세 가지 안을 한눈에 정리해 보면 이렇습니다.
| 안 | 인증 | 스타일 재현 | skill 통합 난이도 |
|---|---|---|---|
| a | 사내 정책·승인 필요 | 부족 | 중 |
| b | 동일 인증 이슈 | 일부만 가능 | 높음 |
| c | 사용자 OAuth 그대로 사용 | 100% 자유 | 낮음 |
표를 보고 나서야 처음의 막연한 고민이 정리됐습니다. c안 — 로컬 스크립트로 xlsx 만들기 가 결론이었습니다. 여기까지 도달하면서 한 가지 솔직한 질문에 답이 났습니다.
"굳이 MCP를 써야 할까?" — 지금 환경에서는 답이 "아니다"였습니다.
📌 c안으로 만든 skill의 구조
이렇게 해서 만들어진 게 /qa-sheet skill입니다. SKILL.md 의 frontmatter 부분만 잠깐 보여 드리면 이렇습니다.
---
name: qa-sheet
description: 기획서, PR diff, 피그마 디자인을 분석하여 스타일이 포함된 QA 시트 xlsx 파일을 생성합니다. 고정된 QA 샘플을 few-shot 예시로 참고합니다.
argument-hint: [기획서경로] [PR링크...] [피그마링크]
effort: max
---전체 워크플로우는 일곱 단계로 정리할 수 있습니다.
- 사전 환경 점검 —
gh인증, 공유 드라이브 마운트, Python +openpyxl, 필요한 경우 피그마 MCP 까지 먼저 확인합니다. 여기서 빠진 게 있으면 파일이 마운트되지 않은 로컬에만 조용히 저장되는 "무음 실패"가 생기기 쉬워서, 가장 먼저 막아 둡니다. - QA 샘플 분석 — 사내 기존 QA 시트 두 개를 few-shot 샘플로 두고,
inspect-sample.py라는 보조 스크립트로 셀 배경색·폰트·테두리·병합 영역을 카탈로그로 추출합니다. - 기획서 분석 — 기능 목록과 요구사항을 파악합니다.
- 피그마 디자인 분석 — UI 라벨, 빈 상태, 정확한 화면 구성을 피그마 MCP로 가져옵니다.
- PR diff 분석 —
gh pr diff로 코드 변경을 가져온 뒤, 비개발자 관점으로 풀어서 요약합니다. SKILL.md 안에 "API, 컴포넌트, 렌더링, Redux 같은 용어는 일절 쓰지 않는다"는 규칙을 명시해 두었습니다. - 테스트 케이스 도출 — 이 skill 의 가장 핵심이 되는 단계입니다. 앞 단계에서 모은 기획서의 기능 흐름, 피그마에서 확인한 UI 요소·빈 상태, PR diff 에서 드러난 실제 동작 변화를 교차해 보고, QA 진행자가 그대로 따라갈 수 있는 사용자 시나리오 단위로 테스트 케이스를 만들어 냅니다. 첫 번째 케이스는 항상 로그인 같은 사전 준비로 시작하고, 화면 이동 경로는 메뉴 명까지 정확히 적습니다. 기능 항목을 1대1로 옮겨 적는 식이 아니라, 사용자 입장에서 자연스러운 사용 흐름을 따라가도록 정리하는 것이 포인트입니다.
- xlsx 생성·저장 — openpyxl 로 스타일을 그대로 재현하며, 공유 드라이브 마운트 경로에 바로
wb.save()합니다. 별도의 업로드 단계가 없습니다.
c안의 핵심은 두 군데 코드에서 가장 잘 드러납니다.
공유 드라이브 마운트 경로 자동 탐색 (Bash)
SHARED_QA_ROOT=""
for gd in "$HOME"/Library/CloudStorage/GoogleDrive-*; do
candidate="$gd/공유 드라이브/[레디-개발팀] 개발 QA/QA 진행"
if [ -d "$candidate" ]; then
SHARED_QA_ROOT="$candidate"
break
fi
done마운트 경로는 실행자(팀원)마다 로그인한 구글 계정이 다르기 때문에, SKILL.md 에 절대 경로를 박지 않고 위 스니펫으로 그때그때 찾도록 만들었습니다. SHARED_QA_ROOT 가 비어 있으면 저장 단계로 넘어가지 못하게 안전 장치도 함께 두었습니다.
openpyxl로 샘플 스타일을 그대로 재현 (Python)
from openpyxl.styles import PatternFill, Font, Alignment
ws["B2"] = "일시"
ws["B2"].fill = PatternFill(start_color="F3F3F3", fill_type="solid")
ws["B2"].font = Font(bold=True)
ws["B2"].alignment = Alignment(horizontal="center", vertical="center")
ws.merge_cells("C2:D2")샘플 분석 단계에서 뽑아낸 hex 색상값을 PatternFill에 그대로 넣어 주는 것만으로, 기존 템플릿과 시각적으로 동일한 결과물을 만들 수 있었습니다. 결과 열(H 열)의 Pass / Fail 토글도 DataValidation(type="list") 로 넣어 두면, 구글 시트로 변환됐을 때 드롭다운 칩 UI로 자연스럽게 보입니다. 이런 디테일은 MCP 만으로는 절대 채울 수 없었던 부분입니다.
📌 팀에 공유하기
만든 skill은 GitHub 레포로 정리해 팀원 누구나 가져다 쓸 수 있게 했습니다.
skills 의 좋은 점은 마크다운 한 파일 안에 워크플로우, 규칙, 코드 스니펫이 전부 담긴다는 것입니다. 다른 팀원이 자기 로컬에 클론하고 Google Drive for Desktop만 켜져 있으면, 동일한 명령어로 동일한 결과물을 얻습니다. README나 가이드 문서를 따로 관리하지 않아도 SKILL.md 하나가 그 역할을 대신해 주고, 업데이트가 필요하면 그 한 파일만 고치면 됩니다.
📌 마치며
skills 를 처음 알게 됐을 때 막연했던 이유는, 제 머릿속에서 "도구"와 "내 업무"가 따로 놀고 있었기 때문이었던 것 같습니다. 이번에 직접 만들어 보면서 분명해진 건, skills 는 내 워크플로우를 그대로 형상화하는 그릇이라는 점입니다. 이미 제가 매번 같은 순서로 같은 일을 반복하고 있다면, 그 절차가 곧 skill 후보입니다. 거창한 자동화가 아니어도 됩니다. "내 손이 너무 많이 가는 부분"을 한 번 정리해 두는 정도로도 충분합니다.
그리고 이번 의사결정에서 한 번 더 확인한 건, '멋진 도구'보다 '환경에 맞는 도구'가 먼저라는 점입니다. MCP는 매력적이지만, 저희 팀의 구글 드라이브 권한 구조와 QA 시트 스타일 요구를 동시에 만족시키기엔 무리가 있었습니다. 결과적으로 가장 단순한 c안 — 로컬 마운트된 드라이브에 스크립트로 떨어뜨리기 — 가 가장 잘 맞았고, 만들고 나서부터는 기획서·피그마·PR 을 머릿속에서 합치고 사용자 시나리오로 풀어 내는 데 들어가던 시간이 눈에 띄게 줄었습니다.
