당신은 꽤 많은 기대를 품고 AI 어시스턴트를 처음 열었습니다. 당신은 "로그인 페이지에 대한 테스트 케이스를 작성해줘"라고 입력했습니다. 약 3초 만에 8개의 테스트 케이스가 돌아왔습니다. 유효한 로그인. 잘못된 비밀번호. 빈 사용자 이름. 빈 비밀번호. 당신이 잠결에도 작성할 수 있을 법한, 당신의 제품에 실제로 중요한 모든 시나리오를 놓치고 있는 그런 종류의 리스트였습니다.

그래서 당신은 도구를 닫으며 생각했습니다. '이건 기초적인 수준에는 괜찮지만, 테스트를 제대로 이해하고 있는 건 아니군.' AI는 과하게 저평가되어 있습니다.

여기 중요한 관점의 전환이 있습니다. AI가 당신을 실망시킨 것이 아닙니다. 당신의 프롬프트(Prompt)가 실패한 것입니다. "로그인 페이지에 대한 테스트 케이스를 작성해줘"는 테스트 브리프(testing brief)가 아닙니다. 그것은 어깨를 으쓱하며 대충 던지는 말입니다. 당신은 유능한 어시스턴트에게 작업할 수 있는 것을 거의 아무것도 주지 않았고, AI는 인터넷이 만들어낼 수 있는 가장 평균적인 답변을 내놓았습니다. 일반적인 프롬프트는 일반적인 답변을 가져옵니다. 테스터의 프롬프트는 테스터의 답변을 가져옵니다.

게으른 요청과 정밀한 요청 사이의 그 간극이 바로 프롬프트 엔지니어링 (Prompt Engineering)입니다. 이것은 코딩도 아니고 마법도 아닙니다. 이것은 당신이 보관할 가치가 있는 무언가를 얻을 수 있는 방식으로, AI에게 당신이 정확히 무엇을 필요로 하는지 말하는 기술입니다. 이 가이드는 수동 테스터(manual testers)를 위한 실용적이고 비기술적인 안내서입니다. 왜 모호한 프롬프트가 쓸모없는 결과물을 만드는지, 효과적인 프롬프트의 구조는 무엇인지, 당신이 매일 실제로 수행하는 업무에 대한 전후(before-and-after) 예시, 그리고 왜 이것이 이력서에 올릴 만한 가치가 있는 기술이 되고 있는지에 대해 다룹니다. 코드는 없습니다. 오직 잘 사용된 단어들뿐입니다.

요약 (THE SHORT ANSWER)
테스트 시 AI로부터 유용한 결과물을 얻는 방법 요약:
• 역할을 부여하세요: 당신의 제품 유형에 맞는 시니어 QA 테스터가 누구인지 알려주세요.
...

왜 "로그인 페이지에 대한 테스트 케이스를 작성해줘"가 유용한 것을 주지 못하는가

AI 모델은 가장 확률이 높은 답변을 제공하도록 구축되었습니다. 당신의 프롬프트가 모호할 때, 가장 확률이 높은 답변은 가장 일반적인 답변, 즉 당신의 제품에 특화된 내용이 전혀 없는, 지금까지 작성된 모든 로그인 테스트의 평균값입니다.

그것이 바로 문제의 핵심을 한 문장으로 요약한 것입니다. 모델은 당신의 애플리케이션을 알지 못합니다. 로그인 시도가 5회 실패하면 계정이 잠긴다는 사실도, 생체 인식 로그인을 지원한다는 점도, 만료된 세션과 관련된 알려진 버그가 있다는 사실도, 혹은 당신의 사용자들이 신호가 한 칸뿐인 기차 안에서 은행 잔고를 확인하며 스트레스를 받는 사람들인지도 알지 못합니다. 모델은 그 어떤 것도 볼 수 없습니다. 따라서 당신이 이러한 정보를 누락하면, AI는 그 공백을 가능한 한 가장 특징 없는 추측으로 채워버립니다.

반면에 당신은 그 모든 것을 알고 있습니다. 그 지식이 바로 당신이 제공하는 가치의 전부입니다. 프롬프트 엔지니어링 (Prompt engineering)은 단지 당신의 머릿속에 있는 내용을 프롬프트로 옮겨서, AI가 실제로 활용할 수 있는 무언가를 제공하는 행위일 뿐입니다. 당신이 얻는 결과물의 품질은 당신이 입력하는 정보의 품질에 의해 결정됩니다.

이것은 Katalon의 개인적인 의견이 아닙니다. 이제 이는 테스트 전문직 자체의 표준에 내재되어 있습니다. 2024년, ISTQB는 별도의 전문가 자격증인 '생성형 AI를 활용한 테스트 전문가 인증 (Certified Tester Testing with Generative AI, CT-GenAI)'을 도입했으며, 해당 실라버스 (Syllabus)에는 대규모 언어 모델 (Large Language Models, LLM) 및 리스크 관리 (Risk management)와 더불어 프롬프트 엔지니어링에 관한 전용 섹션이 포함되어 있습니다. 소프트웨어 테스트의 규칙을 만드는 기관이 프롬프트를 어떻게 작성하는지에 관한 내용을 포함하여 자격증을 만들었다는 것은 명확한 신호입니다. 즉, 이것은 단순한 눈속임이 아니라 실제적이고 인정받는 기술이라는 것입니다.

실제로 작동하는 프롬프트의 구조

좋은 테스트 프롬프트는 단순히 길기만 한 것이 아닙니다. 그저 완전할 뿐입니다. 다섯 가지 요소가 모이면 무의미한 답변을 유의미한 보고서로 바꿔줍니다. 이를 Role (역할), Context (맥락), Task (작업), Focus (중점 사항), Format (형식)으로 기억하면 됩니다.

매번 다섯 가지 요소를 모두 사용할 필요는 없지만, Context (맥락)와 Focus (중점 사항)는 테스터의 프롬프트를 다른 사람들의 것과 구분 짓는 두 가지 핵심 요소입니다. Context는 AI가 가질 수 없는 제품 지식입니다. Focus는 버그가 어디에 숨어 있는지에 대한 여러분의 판단입니다. 이것들은 일반적인 사용자가 결코 포함할 생각을 하지 못할 요소들이며, 이것이 바로 프롬프트를 잘 작성하는 테스터가 그렇지 않은 사람보다 훨씬 더 나은 결과물을 얻는 이유입니다.

일반적인 프롬프트 vs 유용한 프롬프트: 동일한 요청, 두 가지 방식

차이점을 느끼는 가장 빠른 방법은 직접 보는 것입니다. 여기 동일한 작업을 두 가지 방식으로 프롬프트한 사례가 있습니다.

약한 프롬프트는 누구나 작성할 수 있는 4개의 해피 패스(Happy-path) 라인을 제공합니다. 반면 강력한 프롬프트는 여러분이 AI에게 어디를 살펴봐야 할지 알려주었기 때문에, 실제 운영 환경(Production)에서 시스템을 무너뜨리는 시나리오를 겨냥한 집중된 테스트 세트를 제공합니다. 동일한 도구, 동일한 3초의 시간. 하지만 가치는 완전히 다릅니다.

강력한 프롬프트에는 기술적인 내용이 전혀 없다는 점에 주목하세요. 코드도, 구문(Syntax)도, 특별한 명령어도 없습니다. 그저 테스터가 팀에 새로 합류한 동료에게 브리핑하듯 기능을 설명하고 리스크를 기술한 것뿐입니다. 주니어 테스터에게 기능을 설명할 수 있다면, 여러분은 강력한 프롬프트를 작성할 수 있습니다.

여러분이 매일 수행하는 업무를 위한 네 가지 프롬프트 엔지니어링 예시

이론도 좋지만, 여러분이 이곳에 온 이유는 오늘 오후에 바로 도구에 붙여넣어 사용할 수 있는 것들을 찾기 위해서일 것입니다. 여기 수동 테스터(manual testers)가 끊임없이 수행하는 업무를 위한 네 가지 레시피가 있습니다. 대괄호 [ ]로 표시된 부분은 여러분의 제품에 맞게 수정하여 사용하세요.

가치 있는 테스트 케이스 생성하기

핵심 요령은 요구사항을 입력한 다음, 출력물의 양(volume)보다는 깊이(depth)에 집중하도록 제약을 거는 것입니다.

"여기에 요구사항이 있습니다: [사용자 스토리(user story) 또는 인수 기준(acceptance criteria)을 붙여넣으세요]. 숙련된 테스터로서 행동하세요. 메인 흐름(main flow), 대체 흐름(alternate flows), 그리고 실패 경로(failure paths)를 모두 다루는 테스트 케이스를 생성하세요. 각 케이스에는 전제 조건(Preconditions), 단계(Steps), 그리고 예상 결과(Expected Result)를 포함하세요. 기능이 고장 난 상태에서도 통과될 법한 사소한(trivial) 케이스는 포함하지 마세요."

마지막 문장이 중요합니다. 이 문장은 AI가 "페이지 로딩 확인"과 같은 채우기용 문구에서 벗어나, 실제로 결함(defect)을 잡아낼 수 있는 케이스를 향하도록 유도합니다.

놓칠 수 있는 엣지 케이스(edge cases)를 AI가 찾게 만들기

AI를 최종 케이스를 작성하는 도구가 아니라, 여러분의 사고를 확장하는 역할만을 수행하는 브레인스토밍 파트너로 활용하세요.

"이 기능에 대하여: [설명을 붙여넣으세요]. 일반적인 테스트 계획(test plan)에서 간과하기 쉬운 10가지 엣지 케이스(edge cases)와 경계 조건(boundary conditions)을 나열하세요. 빈 상태(empty states), 최대 길이(maximum lengths), 특수 문자(special characters), 느리거나 끊기는 네트워크(slow or dropped network), 동시 사용자(concurrent users), 그리고 시간대(time zones)를 고려하세요. 각 항목에 대해 왜 그것이 위험한지 설명하는 한 줄을 추가하세요."

여러분은 아마 10개 중 6개 정도만 채택하고 나머지는 눈을 흘기며 넘길 것입니다. 그것은 좋은 결과입니다. 30초 만에 아직 작성하지 않았던 6개의 엣지 케이스를 찾아내는 것은, 그렇지 않았다면 놓쳤을 실질적인 커버리지(coverage)를 확보하는 것입니다.

부정적 시나리오 및 언해피 패스(unhappy-path) 시나리오 생성하기

AI는 기본적으로 해피 패스(happy paths)를 따르는 경향이 있으므로, 명시적으로 그 반대를 요청하세요.

"위에서 설명한 비밀번호 재설정 흐름에 대해, 부정적 테스트 시나리오(negative test scenarios)만 생성하세요. 유효하지 않거나 잘못된 형식의 입력(invalid and malformed inputs), 만료된 재설정 링크, 두 번 사용된 재설정 링크, 불일치하는 확인 필드, 그리고 1분 내에 50번의 재설정을 요청하는 것과 같은 남용 사례(abuse cases)를 포함하세요. 각 시나리오를 Given / When / Then 형식으로 작성하세요."

원하는 카테고리(예: "만료된 링크", "재사용된 링크", "남용 사례")를 명시하는 것이 "잘못된 비밀번호 입력"의 세 가지 변형 대신, 실질적인 힘을 가진 시나리오를 얻는 방법입니다.

지저분한 세션 노트를 깔끔한 버그 리포트로 변환하기

이 방법은 사람들이 가장 열광하는 부분인데, 왜냐하면 여러분이 정말 싫어하는 번거로운 작업을 없애주기 때문입니다. 거친 노트를 붙여넣고 AI가 서식을 작성하게 하되, 한 가지 중요한 가드레일(guardrail)을 설정하세요.

"이 거친 세션 노트를 명확한 버그 리포트로 변환해줘: '12MB 프로필 사진 업로드를 시도했는데 스피너(spinner)만 계속 돌고, 새로고침했더니 기존 사진까지 사라졌음, 두 번 발생함.' 다음 형식을 사용해: 제목(Title), 환경(Environment), 재현 단계(Steps to Reproduce), 예상 결과(Expected Result), 실제 결과(Actual Result), 심각도(Severity), 참고 사항(Notes). 만약 누락되었거나 모호한 세부 정보가 있다면, 임의로 지어내지 말고 '확인 필요(Need to confirm)' 항목 아래에 나열해줘."

마지막 지침이 유용한 초안과 위험한 초안을 가르는 차이점입니다. 이 지침이 없다면, AI는 여러분이 관찰하지도 않은 브라우저 버전, 정확한 파일 유형, 재현율 등을 아주 기쁘게 지어낼 것입니다. "지어내지 말고 대신 나에게 물어봐"라는 명령은 출력물의 정직함을 유지하고 여러분이 사실 관계에 대한 통제권을 갖게 해줍니다.

자판기가 아닌 대화처럼 다루기

초보 사용자들이 저지르는 가장 큰 실수는 AI를 자판기처럼 다루는 것입니다. 프롬프트 하나를 넣으면 답변 하나가 나오고, 그것을 받아들이거나 포기하는 식이죠. 진정한 가치를 얻는 테스터들은 AI를 대화처럼 다룹니다.

첫 번째 응답이 일반적(generic)이라면, 포기하거나 혼자서 조용히 다시 작성하지 마세요. 무엇이 잘못되었는지 AI에게 말하고 다시 시도하게 하세요. "이것들은 모두 해피 패스(happy paths)입니다. 실패 시나리오를 알려주세요." "생체 인식 대체(biometric fallback) 케이스를 추가해줘." "그 버그 제목은 모호합니다. 데이터 손실에 대해 구체적으로 작성해줘." 각각의 수정은 비용이 거의 들지 않으며, 두 번째 답변은 거의 항상 첫 번째보다 훨씬 낫습니다. 왜냐하면 여러분이 첫 번째 시도에서 빠뜨렸던 맥락(context)을 방금 제공했기 때문입니다.

정교화(Refinement) 단계야말로 여러분의 테스트 판단력이 진정한 역량을 발휘하는 지점입니다. AI는 빠르게 초안을 작성하지만, 여러분은 실제로 유용한 방향으로 이를 조종해야 합니다. 이러한 주고받는 과정(back-and-forth)이 바로 기술이며, 좋은 테스트에 대해 더 많이 이해할수록 더욱 능숙해지는 부분입니다.

테스트를 위해 AI에게 프롬프트를 작성할 때 저지르는 흔한 실수들

• 모든 것을 한꺼번에 요청하기. "내 애플리케이션 전체를 테스트해줘"라고 요청하면 AI는 집중할 곳을 잃게 되고, 여러분은 얕고 산만한 답변을 받게 됩니다. 프롬프트 하나당 하나의 기능, 하나의 명확한 작업만 요청하세요.
• 맥락(context)을 전혀 제공하지 않기. 제품, 규칙, 사용자(user)에 대해 AI에게 알려주지 않으면 AI는 이를 고려할 수 없습니다. 맥락의 부재는 일반적이고 평이한 결과물(generic output)이 나오는 가장 큰 원인입니다.
• 첫 번째 초안을 그대로 수용하기. 첫 번째 답변은 시작점일 뿐, 최종 결과물(deliverable)이 아닙니다. 수정 없이 그대로 사용한다면, 그것은 테스트를 하는 것이 아니라 단순히 전달(forwarding)만 하는 것입니다.
• AI가 세부 사항을 지어내도록 방치하기. 확인 절차가 없다면 AI는 그럴듯하게 들리지만 사실은 허구인 단계, 데이터, 버전, 재현율(reproduction rates)을 꾸며낼 것입니다. 모르는 부분은 채워 넣는 대신 표시(flag)하도록 항상 지시하고, AI가 제공하는 내용을 반드시 검증하세요.
• 형식(format)을 잊기. 수작업으로 다시 형식을 맞춰야 하는 긴 산문 형태의 글은 시간 절약 효과가 거의 없습니다. 표(table), Given/When/Then, 혹은 여러분의 버그 템플릿 등 원하는 출력 형식을 AI에게 정확히 알려주면 즉시 사용 가능한 결과물이 됩니다.
• 여전히 여러분이 검토자(reviewer)라는 사실을 잊기. AI는 제안하고, 여러분은 승인합니다. 자신감 넘치고 형식이 잘 갖춰져 있지만 미묘하게 틀린 테스트 케이스를 생성하는 프롬프트는 테스트 케이스가 아예 없는 것보다 더 위험합니다. 매 순간 여러분의 눈이 마지막 관문입니다.

프롬프팅이 지름길이 아닌 기술인 이유

현재 수동 테스트(manual testing) 분야에는 조용한 두려움이 존재합니다. 'AI가 테스트 케이스를 생성할 수 있다면, 나에게 남은 역할은 무엇인가?'라는 질문입니다. 프롬프트 엔지니어링(Prompt engineering)은 이 질문을 뒤집음으로써 가장 명확한 해답 중 하나를 제시합니다. AI는 프롬프트를 잘 작성할 수 있는 테스터를 대체하는 것이 아니라, 그들의 역량을 배가(multiplies)시킵니다.

이 가이드에서 다룬 모든 좋은 프롬프트가 무엇을 요구했는지 다시 한번 살펴보십시오. 당신의 제품에 어떤 리스크가 중요한지 아는 것. 버그가 실제로 어디에 숨어 있는지 아는 것. 유용한 테스트 케이스와 사소한 테스트 케이스가 어떻게 다른지 아는 것. 일반적인 답변을 식별하고 더 나은 답변을 얻기 위해 어떻게 압박해야 하는지 아는 것. 버그 리포트에 도달하기 전에 꾸며낸 세부 사항을 포착하는 것. 이 중 그 어떤 것도 AI로부터 나오는 것이 아닙니다. 이 모든 것은 당신으로부터 나옵니다. 프롬프트는 단지 당신의 전문성을 도구로 전달하는 파이프일 뿐이며, 테스트 판단력이 없는 사람이 프롬프트를 작성하면 자신감 넘치고 유창해 보이지만 쓸모없는 결과물만을 얻게 됩니다.

이것이 바로 "AI가 존재한다"와 "나는 일상 업무에서 AI를 사용한다" 사이의 가교이며, 이 다리를 건너는 것은 성격적 특성이 아니라 의도적으로 학습 가능한 기술입니다. 업계는 이미 이를 인식하고 있습니다. ISTQB는 프롬프트 엔지니어링 (Prompt Engineering)을 핵심 주제로 하여, 테스트에 생성형 AI (Generative AI)를 사용하는 것에 관한 전문 자격증인 CT-GenAI를 구축했습니다. 이러한 도구들을 잘 다루는 법을 배우는 테스터는 자동화로 인해 대체되지 않습니다. 그들은 "로그인 페이지에 대한 테스트 케이스를 작성해줘"라고 입력했다가 쓰레기 같은 결과물을 받고 포기해 버린 동료보다 조용히 2~3배 더 높은 생산성을 갖게 될 것입니다.

번창할 테스터는 AI를 피하는 사람도, AI를 맹목적으로 신뢰하는 사람도 아닐 것입니다. 그들은 AI에게 올바른 질문을 던지는 법을 배운 사람들일 것입니다.

Katalon AI Assistant에서 이를 실무에 적용하기