개념
Skill이란 무엇인가
Skill은 AI에게 "이런 종류의 작업은 항상 이 절차와 형식으로 해줘"라고 미리 정의해두는 재사용 가능한 지침 묶음이다. 레슨 1에서 "좋은 프롬프트를 매번 새로 잘 써야 한다"고 배웠는데, Skill은 그 잘 쓴 프롬프트와 절차를 한 번 정의해두고 계속 재사용하는 방법이라고 이해하면 된다.
Skill 없이: 매번 사람이 "테스트 케이스를 이런 형식으로,
이런 기준으로 만들어줘"를 새로 설명해야 한다
Skill 있이: 미리 정의된 절차를 AI가 자동으로 따른다 —
매번 설명을 반복할 필요가 없다QA 업무가 Skill에 잘 맞는 이유
QA 업무 중 상당수는 매번 같은 절차, 같은 형식을 반복한다.
- 테스트 케이스: 항상 "사전조건 → 실행 절차 → 기대 결과" 형식
- 버그 리포트: 항상 "재현 절차 → 실제 결과 → 기대 결과 → 환경 정보" 형식(모듈 6에서 배운 형식)
- 회귀 테스트 체크: 매 릴리즈마다 같은 핵심 시나리오 목록을 확인
이런 반복 작업은 사람마다, 그날 기분마다 결과물의 품질이 들쭉날쭉해지기 쉽다. Skill로 절차를 고정해두면, 누가 시키든 같은 기준의 결과물이 나온다 — 이건 모듈 7에서 배운 "테스트 프로세스 표준화"와 근본적으로 같은 목적을, AI 활용 맥락에서 구현하는 것이다.
Skill로 만들 수 있는 QA 업무 예시
| 업무 | Skill이 담을 내용 |
|---|---|
| 테스트 케이스 작성 | 모듈 3에서 배운 설계 기법(동등분할·경계값 등)을 적용하는 순서, 출력 형식 |
| 버그 리포트 작성 | 모듈 6의 심각도·우선순위 판단 기준, 재현 절차 작성 형식, 비난 없는 표현 |
| 회귀 테스트 체크리스트 | 이번 변경이 영향을 주는 범위를 모듈 2(레슨 5)의 추적성 관점으로 짚어보는 절차 |
| 결함 리포트 중복 확인 | 레슨 2에서 배운 AI 결함 분류·중복 탐지 절차를 매번 같은 기준으로 적용 |
Skill이 대신해주지 않는 것
Skill은 "어떻게 할지"의 절차를 고정해줄 뿐, "무엇이 맞는 답인지"까지 대신 판단해주지 않는다. 예를 들어 버그 리포트 Skill이 형식은 항상 정확하게 만들어줘도, "이게 정말 버그인가, 의도된 동작인가"는 여전히 사람이 판단해야 한다. 이건 이 커리큘럼 전체가 반복해서 강조해온 것과 같다 — AI는 반복 작업을 덜어주는 도구지, QA의 판단을 대신하는 존재가 아니다(모듈 개요의 BYOK 원칙).
다른 사람도 쓸 수 있게 공유하기
Skill은 한 번 잘 만들어두면 팀 전체가 공유해 쓸 수 있다. 신입 QA가 아직 버그 리포트 형식에 익숙하지 않아도, 팀에서 이미 만들어둔 "버그 리포트 Skill"을 쓰면 처음부터 팀 기준에 맞는 리포트를 쓸 수 있다 — 이건 모듈 6에서 배운 "결함 리포트 품질이 팀 신뢰에 영향을 준다"는 문제를, 도구로 미리 막아주는 효과가 있다.
실무에서 왜 필요한가
QA 조직이 커질수록 "사람마다 테스트 케이스 쓰는 방식이 다르다", "버그 리포트 품질이 팀원마다 차이가 크다" 같은 문제가 반복해서 나온다. 이걸 매번 리뷰와 피드백으로 교정하는 데는 시간이 오래 걸린다. Skill로 절차 자체를 표준화해두면, 품질 편차를 리뷰가 아니라 도구 단계에서 줄일 수 있다. 다만 Skill이 만든 결과물도 결국 검증이 필요하다는 점(레슨 1)은 변하지 않는다 — Skill은 "일관된 초안"을 빠르게 만들어주는 도구이지, 검토 과정을 없애주는 도구가 아니다.