사례 글을 게임 QA 실습 자료로 바꾼 후기

📝 한줄 요약

지피터스에 올라온 「Spec Kit으로 PRD부터 MVP까지 차근차근 만들기」를 클로드코드(Claude Code)에 넣고 "나에게 적용할 게 있는지" 물었습니다. 바이브코딩 글이었는데, 제 업무와 겹쳐 보니 게임 QA 취업반 학생들이 TC를 쓸 때 매번 막히는 지점의 해답 이 들어 있었습니다. 같은 날 학생용 실습 자료(마크다운)와 배포용 HTML 페이지까지 만들었습니다.

바쁘시면 이것만 읽어도 됩니다:

• 원문의 핵심은 AI에게 바로 코드를 시키지 말고 PRD → 명세(성공 조건) → 계획 → 작업 → 구현 → 명세와 화면 비교 순서로 가라는 것입니다.
• 학생 TC를 검토할 때 가장 많이 하던 지적이 "기대 결과가 '~거나'로 적혀 있어 Pass/Fail을 낼 수 없다 "였는데, 원인이 TC가 아니라 명세에 성공 조건이 없어서 라는 걸 이 글로 정리할 수 있었습니다.
• 원문의 "명세에 없으면 '확인 필요'로 표시" 규칙은 QA 실무에서 기획자에게 보내는 질의 와 같습니다.
• 결과물: "명세 → 성공 조건 표 → TC → 실행 → 버그리포트" 실습 자료 + 퀴즈·복사 버튼·체크리스트가 있는 배포용 HTML.

🎯 이런 분들께 도움돼요

• 커뮤니티 글을 읽고 "좋은데, 내 일에는 어떻게 쓰지?"에서 멈추는 분
• QA·테스트·기획을 가르치는 강사, 교사, 멘토
• AI가 써 준 TC나 문서를 학생이 그대로 제출해서 고민인 분

😫 문제 상황 (Before)

게임 QA 취업반 학생들의 TC(테스트 케이스)를 검토하다 보면 비슷한 기대 결과를 자주 만납니다.

"목록이 갱신되거나 보던 위치가 유지됨" "안내가 나오거나 획득이 막힘" "문제가 생기지 않음"

이런 TC는 실행해도 Pass인지 Fail인지 판단할 수 없습니다. 매번 "기대 결과는 하나로 확정하세요"라고 피드백했지만, 학생 입장에서는 무엇을 기준으로 하나를 고르라는 건지 가 빠져 있었습니다. 기획서에 정답이 없으니 학생도 "~거나"로 쓸 수밖에 없었던 거죠.

🛠️ 사용한 도구

• Claude Code (VS Code 확장) : 글 읽기, 내 자료와 비교, 실습 자료·HTML 작성, 문법 검사
• Obsidian : 글 요약 노트, 학생 지도 자료 폴더
• 참고 글 : 지피터스 「Spec Kit으로 PRD부터 MVP까지 차근차근 만들기」 — https://www.gpters.org/nocode/post/spec-kiteuro-prdbuteo-mvpggaji-cageuncageun-mandeulgi-a8dfbCCvluw4qxK

🔧 작업 과정

1단계. 링크 하나 주고 "나에게 적용할 것"만 물었다

[글 링크] 이 내용에서 나에게 적용할 만한 것이 있는지 파악하고 정리해줘.
어디에 저장할지는 네가 제안해주면 좋겠어.

클로드코드는 글을 요약한 뒤, 제 볼트에 있는 기존 작업을 뒤져서 원문과 비교했습니다. 예전 특강에서 만든 앱 기획서·명세서, 웹앱 PRD, 학생 TC 검토 피드백 같은 것들이었죠. 그리고 적용 후보를 넷으로 정리했습니다.

1. 바이브코딩 수업에 "PRD → 성공 조건 → 한 기능씩 확인" 흐름 넣기
2. 게임 QA 지도: 명세 기반 테스트 = TC 설계
3. 내 웹앱 PRD의 범위 줄이기 (핵심 기능 3개 + 제외 목록)
4. PRD 템플릿 만들기

"Spec Kit 도구를 지금 설치하는 것"은 당장 안 해도 되는 것 으로 따로 분리했습니다. 설치 준비가 필요한 데 비해, 단계와 프롬프트만으로도 효과의 대부분을 얻을 수 있다는 이유였습니다.

요약 노트는 외부 글 모음 폴더에 저장했고, 맨 위에 "AI가 자동으로 읽어 만든 초안이니 원문과 대조 전에는 인용하지 말 것"이라는 표시를 달았습니다.

2단계. 바이브코딩 글이 QA 수업과 만난 지점

제가 고른 건 2번이었습니다.

2번 진행해줘

클로드코드는 먼저 제가 이전에 만들어 둔 TC 양식 (TC ID / 사전조건 / 입력(정상·경계·오류) / 예상 결과 / 심각도)과 학생 TC 검토 피드백 을 다시 읽었습니다. 그리고 둘을 이렇게 이었습니다.

학생들이 "~거나"를 쓰는 진짜 이유가 명세에 성공 조건이 없어서라면, TC를 쓰기 전에 성공 조건 표부터 만들게 하면 됩니다. 모르는 건 지어내지 말고 "확인 필요"에 질문으로 남기고요. 피드백할 때마다 하던 말이 처음으로 한 장의 순서도로 정리됐습니다.

3단계. 학생용 실습 자료

학생 지도 자료 폴더의 다음 번호로 실습 자료가 만들어졌습니다. 구성은 이렇습니다.

1. 왜 이 순서로 하나 : Pass/Fail을 낼 수 없는 기대 결과 예시 3개로 시작
2. 성공 조건 표 : 단정형으로, 숫자로, 모르면 "확인 필요"
3. TC 설계 : 성공 조건 하나에서 정상·경계·오류 입력 뽑기 (동등분할·경계값 분석은 면접 용어로 소개). 여기에 원문의 테스트 체크리스트(빈 입력, 모바일 화면, 콘솔 오류, 누락 기능)를 그대로 가져왔습니다.
4. TC·버그리포트 양식 : "기대 결과에 '또는/거나' 금지", "TC 하나에 확인 하나"
5. 실습 A : 일부러 빈틈을 넣은 연습용 명세(단어 퀴즈 웹앱). "문제는 랜덤으로 나온다", "최고 점수는 저장된다" 같은 문장에 숨은 "확인 필요"를 찾게 했습니다. 같은 문제가 두 번 나와도 되는지, 새로고침하면 최고 점수가 남는지처럼요.
6. 실습 B : 학생이 바이브코딩으로 직접 만든 앱이나 포트폴리오 게임에 적용
7. AI 사용 규칙 : AI는 TC를 써 주는 역할이 아니라 검토하는 역할로만 씁니다.
8. 제출물과 셀프 점검 체크리스트 7개

특히 7번이 마음에 들었습니다. 학생이 AI에게 TC를 통째로 쓰게 하면 역량이 드러나지 않으니, 프롬프트를 이렇게 만들었습니다.

123456내가 쓴 TC를 검토해줘. 고쳐서 다시 써주지 말고, 문제가 있는 TC 번호와 이유만 표로 알려줘.
- 기대 결과에 "또는/거나"가 있어 Pass/Fail을 낼 수 없는 것
- 사전조건과 테스트 단계가 섞인 것
- 한 TC에서 두 가지 이상을 확인하는 것
- 같은 수치나 규칙이 TC끼리 다르게 적힌 것
- 경계값(최소·최대·바로 바깥)이 빠진 기능

학생에게 나눠 줄 자료라서 특정 학생의 이름이나 실제 TC 사례는 넣지 않았고, 모호한 기대 결과 예시도 일반적인 문장으로 바꿔 썼습니다.

4단계. 배포용 HTML 한 장

배포용 html 단일 페이지 만들어줘

마크다운 내용을 그대로 옮기면서, 학생이 직접 손을 움직일 장치를 세 가지 더했습니다.

• 워밍업 퀴즈 : 기대 결과 문장 6개를 보고 "판정 가능 / 판정 불가"를 고르면 이유가 바로 나옵니다. 본론에 들어가기 전에 감을 잡게 하는 용도입니다.
• 프롬프트 복사 버튼 : 명세 정리용과 TC 검토용을 한 번에 복사
• 셀프 점검 체크리스트 + 진행 막대

파일 하나라서 메신저로 보내거나 수업 화면에 바로 띄울 수 있습니다. 마지막에 스크립트 문법 검사와 학생 이름이 섞여 있지 않은지 검색까지 마쳤습니다.

✅ 결과 (After)

적용 전후

흐름 한 장 요약

12345지피터스 글 (바이브코딩)
  → "나에게 적용할 점" 4개 도출, 도구 설치는 보류
  → 그중 "명세 = TC" 연결 선택
  → 학생 실습 자료 (명세 → 성공 조건 → TC → 실행 → 버그리포트)
  → 배포용 HTML

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. "요약해줘"가 아니라 "나에게 적용할 것"을 묻는다. AI가 내 기존 자료를 찾아 비교하면서, 다른 분야의 글이 내 업무와 만나는 지점을 찾아 줍니다. 이번에는 바이브코딩 글이 QA 수업 자료가 됐습니다.
2. 적용 후보를 여러 개 받고 하나만 고른다. 넷을 한꺼번에 하지 않고, 지금 가장 자주 부딪히는 문제(학생 TC 피드백) 하나만 깊게 했습니다.
3. AI가 내가 예전에 만든 양식을 다시 읽게 한다. 새 양식을 만드는 대신 원래 쓰던 TC 양식을 바탕으로 하니, 학생들이 이미 아는 형식과 이어졌습니다.
4. 학생용 AI 프롬프트는 "고쳐 주지 말고 이유만"으로 쓴다. 학습 자료에서 AI는 대신 쓰는 사람이 아니라 검토자로 둬야 합니다.

이렇게 하면 안 돼요

1. 글에 나온 도구부터 설치하지 마세요. 이번 글의 진짜 가치는 도구가 아니라 순서와 프롬프트였습니다.
2. AI가 자동으로 읽어 온 요약을 바로 인용하지 마세요. 원문과 대조하기 전까지는 "초안" 표시를 달아 두는 게 안전합니다.
3. 학생 배포 자료에 실제 학생 사례를 그대로 쓰지 마세요. 문제 유형만 남기고 문장은 일반화해야 합니다.

🌍 다른 업무에 적용한다면?

"성공 조건 → 확인 필요 → 검증"은 테스트 말고도 쓸 데가 많습니다. 학생 포트폴리오 과제를 낼 때 "평가 기준(성공 조건)"을 먼저 함께 쓰게 하거나, 기획 수업에서 기획서마다 "확인 필요 질의 목록"을 붙이게 하는 식입니다. 원문의 원래 용도대로, 학생들이 바이브코딩으로 앱을 만들 때도 같은 표를 먼저 쓰게 하면 "만들기"와 "테스트하기"를 한 수업 안에서 이어서 가르칠 수 있을 것 같습니다.

🚀 앞으로의 계획

• 다음 QA 수업에서 실습 A(연습용 명세)를 실제로 돌려 보고, 학생들이 찾은 "확인 필요"를 모아 예시를 보강하기
• 학생 TC 피드백을 쓸 때 이 자료의 셀프 점검 7개 항목을 기준으로 맞추기
• 남은 적용 후보(바이브코딩 수업 흐름, PRD 템플릿)도 하나씩 진행

📋 재사용 가능한 프롬프트

프롬프트 1: 커뮤니티 글에서 내 업무 적용점 찾기

[글 링크] 이 내용에서 나에게 적용할 만한 것이 있는지 파악하고 정리해줘. - 내 볼트(폴더)에 있는 기존 작업과 비교해서, 어떤 자료에 어떻게 쓸 수 있는지 구체적으로 적어줘. - 적용 후보는 우선순위 순으로, 당장 안 해도 되는 것은 이유와 함께 따로 적어줘. - 저장 위치는 내 폴더 규칙을 보고 제안해줘.

프롬프트 2: 적용 아이디어 → 학생 실습 자료

[적용 아이디어]로 [대상] 학생용 실습 자료를 만들어줘. - 내가 예전에 만든 [양식/피드백 문서]를 먼저 읽고 그 형식을 이어줘. - 연습용 예제는 일부러 빈틈을 넣어서 학생이 직접 찾게 해줘. - 학생이 AI를 쓸 때는 "고쳐 주지 말고 문제와 이유만" 알려주는 검토용 프롬프트를 넣어줘. - 실제 학생 이름이나 사례는 넣지 마.

프롬프트 3: 학생용 TC 검토 (학생 배포용)

내가 쓴 TC를 검토해줘. 고쳐서 다시 써주지 말고, 문제가 있는 TC 번호와 이유만 표로 알려줘. (기대 결과의 "또는/거나", 사전조건·단계 혼재, 한 TC 두 확인, 수치 불일치, 경계값 누락)

[대괄호]는 본인 상황에 맞게 바꿔 쓰시면 됩니다.

출처

• 원문: https://www.gpters.org/nocode/post/review-case-article-changed-aMzUvC804PVK4H4 (2026-10-18 · 공대언니)