QA for Beginners
요즘 ChatGPT, Claude, Gemini 같은 AI를 쓰지 않는 사람을 찾기가 오히려 어려워졌다. 그런데 솔직하게 물어보고 싶다.
당신은 AI를 잘 쓰고 있는가?
"잘 쓴다"는 것이 무엇인지에 따라 답이 달라질 것이다. 단순히 질문을 던지고 답을 받는 수준이라면, 대부분은 이미 잘 쓰고 있을지 모른다. 그러나 AI가 내 업무에 실질적으로 기여하게 만드는 수준이라면 이야기가 다르다.
현재 QA 업무에 AI를 도입하면서 FE 성능 테스트와 약전계 테스트 같은 비기능 테스트 자동화, Regression TC 작성, 위키 문서화, 정기 배포 프로세스 자동화를 실무에 적용하고 운용하고 있다. 오늘은 그 과정에서 고민하고 배운 것들을 공유하려 한다.
들어가기 전에, 나보다 AI를 더 잘 다루는 사람들이 세상에는 훨씬 많다. 고로 이하 내용들이 절대적인 정답은 아님을 염두에 두길 바란다.
AI, 특히 LLM(대규모 언어 모델)의 구조를 간단히 설명하면 이렇다. LLM은 다음에 올 단어를 확률적으로 예측하며 문장을 만들어낸다. 이 예측 능력을 기반으로, 기업이나 개발자가 특정 목적에 맞게 파인튜닝하여 우리가 사용하는 AI 서비스가 탄생한다. 그리고 이 구조는 사람의 뇌, 즉 뉴럴 네트워크를 모방하여 설계되었다.
사람을 모방했다는 것은 강점이기도 하지만 동시에 약점이기도 하다.
AI는 기본적으로 사용자를 도우려고 한다. 그러나 AI는 당신을 처음 만난 존재다. 당신이 빨간색 텍스트를 선호하는지, 밑줄을 선호하는지, 보고서를 요약 먼저 써주길 원하는지 뒤에 써주길 원하는지를 모른다. 말의 이면에 어떤 의도가 담겨 있는지, 구체적으로 무엇을 수행해야 하는지를 100% 파악하지 못한다.
더불어 대화가 길어질수록 AI는 점점 잊어버린다. 마치 우리가 2주 전 목요일에 먹은 점심을 금방 떠올리지 못하듯이. 세션이 초기화되거나 콘텍스트가 복잡해지면, AI는 앞서 합의한 내용을 슬그머니 어기거나 이전과 다른 방식으로 작업을 수행하기 시작한다.
그럼에도 AI는 도우려는 성질이 있기 때문에, 모르는 것을 모른다고 하지 않고 그럴듯한 답을 만들어버리기도 한다. 이것이 바로 할루시네이션(Hallucination), AI의 자신 있는 거짓말이다.
AI를 흡사 팀에 새로 합류한 인턴이라고 생각하면 적절한 수준의 지시를 내릴 수 있다. 능력은 있지만 우리 도메인을 아직 모르는 인턴. "이거 좀 정리해 줘"라고 했을 때, 어떤 형식으로, 어느 수준으로, 어떤 관점에서 정리해야 하는지 판단하지 못하는 인턴.
유능한 상사는 인턴에게 어떻게 하겠는가?
깊이 이해하게 만들고, 질문하게 만들고, 단계적으로 보고하게 만든다.
여기서 프롬프트의 역할을 오해하지 말아야 한다.
프롬프트는 "뭐 해줘"가 아니라, 에이전트가 어떻게 생각하고 행동해야 하는지를 정의하는 것이다.
예를 들어 이렇게 말하는 것과,
"이 기능 분석해 줘."
이렇게 말하는 것은 결과물이 완전히 다르다.
"답하기 전에 사고 과정을 단계별로 설명해 줘. 이 폴더를 깊이 읽고, 어떻게 동작하는지 모든 세부사항을 파악한 뒤, 궁금한 점은 편하게 물어봐. 끝나면 research.md에 상세 보고서를 작성해 줘."
"깊이", "모든 세부사항", "사고 과정을 설명해"와 같은 표현들은 단순한 수식어가 아니다. 이는 AI가 표면적 요약에 그치지 않고 구조적 추론과 분석을 수행하도록 유도하는 디스틸레이션(Distillation) 프롬프트다. 답하기 전에 내부 추론 과정을 먼저 정리하게 만들고, 임의로 판단하기 전 사용자에게 질문함으로써 그 결과로 훨씬 정밀한 출력을 끌어낸다. 이 차이가 결과물의 질을 가른다.
또한 AI가 Test Basis(기획서, TC 등)에 없는 내용을 임의로 만들어내지 않도록 명세 없이 추정 금지 원칙을 Rules로 명시하는 것이 중요하다. 할루시네이션의 상당수는 "도우려는 성질" 때문에 발생하기 때문에, 이를 Rule로 강제하지 않으면 AI는 모르는 부분을 그럴듯하게 채워버린다.
좋은 지시 한 번으로 끝나지 않는다. AI와 일하는 구조 자체를 설계해야 한다. 이 구조를 이루는 요소들을 먼저 이해할 필요가 있다.
프롬프트(Prompt)는 에이전트에게 내리는 지시다. 앞서 말했듯, 단순한 요청이 아니라 에이전트의 사고방식과 행동 방식을 정의한다.
Rules는 에이전트가 모든 작업에서 반드시 따라야 할 행동 원칙이다.
"Test Basis 없이 추정하지 말 것"
"기존 TC 형식을 유지할 것"
"승인 전 다음 단계로 넘어가지 말 것"
처럼, 설계자가 정한 기준을 명시한다. 할루시네이션 방지, 산출물 일관성 유지, 독단적 진행 방지 등이 Rules로 강제된다.
Skills는 특정 작업을 수행하는 방법을 정의한 재사용 가능한 지식 모듈이다.
"Playwright로 성능 테스트를 수행하는 방법"
"Confluence 위키를 우리 양식대로 작성하는 방법"
처럼, 반복되는 작업의 절차와 기준을 미리 정리해 둔 것이다. 에이전트는 작업이 주어지면 관련 Skill을 참조하여 일관된 방식으로 수행한다.
MD 파일(Markdown 문서)은 워크플로우 내에서 정보를 주고받고 기록하는 수단이다. 예를 들어 에이전트가 분석을 마치면 research.md에 보고서를 작성하고, 계획을 수립하면 plan.md에 정리하도록 한다. 설계자는 이 문서를 검토하고 승인하거나 피드백을 준다. 구두로 주고받는 대화와 달리, 문서로 남기면 세션이 초기화되어도 맥락을 유지할 수 있기 때문이다.
서브에이전트(Sub-agent)는 메인 에이전트가 대규모 작업을 처리할 때 병렬로 투입하는 하위 에이전트다. 전체 기능에 대한 Regression TC를 한꺼번에 작성해야 한다면, 메인 에이전트가 기능별로 서브에이전트를 분배하여 동시에 작업을 수행하게 한다. 설계자는 이 분배 기준만 정의하면 된다.
MCP(Model Context Protocol)는 에이전트가 외부 도구 및 서비스와 통신하기 위한 표준 규격이다. USB 포트가 제조사에 상관없이 어떤 기기든 연결할 수 있게 해주듯, MCP는 AI 에이전트와 외부 시스템 사이의 공통 인터페이스 역할을 한다. Jira에 티켓을 등록하거나, Confluence에 위키를 작성하거나, GitHub에서 PR을 열거나, Playwright로 브라우저를 제어하는 것, 이 모든 동작이 MCP 서버를 통해 이루어진다. 에이전트에게 "Jira에 이슈 등록해"라고 지시할 수 있는 이유는 Jira MCP 서버가 연결되어 있기 때문이다. 어떤 도구를 연결하느냐가 곧 에이전트가 닿을 수 있는 세계의 범위를 결정한다.
Hook은 에이전트가 특정 동작을 수행하기 직전 또는 직후에 자동으로 실행되는 스크립트다. Rules나 CLAUDE.md가 에이전트에게 건네는 "권고사항"이라면, Hook은 반드시 실행되는 "강제 규칙"이다. 에이전트가 아무리 긴 대화 끝에 맥락을 잃더라도, hook은 빠짐없이 동작한다.
여기서 한 가지 더 짚을 개념이 있다. 에이전트가 CLI 명령을 실행할 때 그 출력값이 고스란히 콘텍스트 윈도우로 들어온다는 사실이다. LLM은 텍스트를 토큰 단위로 처리하는데, cargo test 한 번이 수천 개의 토큰을 쏟아낼 수 있다. 통과한 테스트 목록, 진행 표시줄, 중복 로그... 대부분은 에이전트의 추론에 필요 없는 노이즈다. 200K짜리 콘텍스트 윈도우도 CLI 출력 쓰레기로 금세 차오를 수 있다.
이 문제를 해결하는 도구가 RTK(Rust Token Killer)다. CLI 출력이 에이전트의 콘텍스트에 도달하기 전에 필터링하고 압축하는 프록시로, 공백, 보일러플레이트, 중복 메시지를 걷어내고 핵심 정보만 남긴다. git push 한 줄짜리 결과로 "ok main"만 남기고, 실패한 테스트만 추려서 보여주는 식이다. 실제 측정 기준으로 평균 89%, 최대 92% 수준의 토큰 절감 효과가 보고되고 있다.
Git을 사용해 봤다면 pre-commit, post-commit hook이 낯설지 않을 것이다. Claude Code의 hook도 같은 원리다. PreToolUse는 도구가 실행되기 전에, PostToolUse는 실행이 끝난 후에 개입한다. 즉, RTK를 PreToolUse hook으로 등록해 두면, 에이전트가 실행하는 모든 bash 명령이 자동으로 RTK를 거치게 된다. 에이전트는 이 과정을 인식하지 못한다. 그냥 더 깔끔한 출력을 받을 뿐이다.
결국 Hook과 RTK은 따로 설명되는 개념이 아니다. 토큰은 유한하고, CLI 출력은 토큰을 낭비하며, Hook은 그 사이를 가로막아 RTK가 압축하게 만든다. 워크플로우의 품질을 유지하면서 비용과 세션 수명을 동시에 관리하는 구조다.
그리고 이 요소들이 모여 하나의 워크플로우가 된다. 핵심 흐름은 세 단계다.
조사(Research) → 계획(Plan) → 실행(Execute)
에이전트는 무언가를 바로 만들어내기 전에 먼저 충분히 파악하고, 계획을 세우고, 그 계획을 보고한다. 설계자가 승인하기 전까지는 다음 단계로 임의로 넘어가지 않는다. 작업량이 크다면 서브에이전트를 투입하고, 선택지가 여러 개라면 추천 안을 먼저 제시하게 한다.
구조가 어떻게 작동하는지는 실제 사례를 보면 더 분명하게 이해할 수 있다.
FE 성능 테스트 자동화의 경우, 설계 방향을 정의해 두면 에이전트가 TestRail에 작성된 기존 TC를 분석하고, Playwright MCP Browser로 실제 화면을 직접 탐색하여 주요 테스트 대상을 스스로 선정한다. 시나리오를 작성하고, 그 시나리오대로 동작하는 Playwright 코드를 구현하며, 실행 후 결과를 Confluence 위키로 정리한다. 식별된 이슈는 Jira에 등록된다. 설계자의 역할은 방향을 정의하고, 각 단계의 결과물을 검토하고, 피드백을 주는 것이다.
기획서가 없는 상황에서의 TC 작성도 마찬가지다. Playwright MCP Browser로 테스트 환경의 실제 화면들을 탐색하여 구현된 기능을 역공학적으로 파악하고, 주요 기능과 엣지 케이스를 식별하여 TC를 추출하도록 설계한다. 기획서 없이도 동작하는 이유는 에이전트가 무엇을 해야 하는지가 아니라, 어떻게 생각하고 접근해야 하는지를 Rules와 Skills로 정의해 두었기 때문이다.
정기 배포 프로세스 자동화는 가장 복합적인 사례다. Regression TC 생성 → Jira 티켓 생성 → Confluence 위키 작성 → QA Plan 공유 → TC 및 Jira 종료 처리 → Sign off 공유까지, 일련의 프로세스를 하나의 워크플로우로 연결한다. MCP 도구에 한계가 생기면 REST API를 직접 호출하는 방식으로 우회하도록 예외 처리도 Rules에 정의해 두었다. 위키 접근이 불가한 상황이라면 임의로 진행하는 대신 홀딩하고 상황을 보고하게 한다.
물론 이 워크플로우가 처음부터 완벽하게 돌아가지는 않는다. 초기에는 반드시 캘리브레이션(Calibration) 과정이 필요하다.
캘리브레이션이란, 에이전트의 출력 품질을 기준에 맞게 조율하는 반복적 피드백 과정이다. TC 형식이 기존 산출물과 다르다면 그 자리에서 교정하되, 일회성 지적으로 끝내지 않는다. "앞으로도 이 스타일을 유지해"로 영구화하고, TC 작성 스타일, 코딩 스타일, 위키 양식 등 도메인별 가이드라인을 Rules와 Skills에 반영한다. 한 번 반영된 교훈은 그 이후부터 자동으로 적용된다.
이때 원칙을 추가하는 기준이 중요하다. 물리학의 제1원리처럼, 이 질문을 스스로에게 던져보는 것이 좋다.
"이것마저 빼면 시스템이 돌아가지 않는가?"
통과하지 못하는 원칙은 넣지 않는다. 핵심만 남기고, 중복은 피하고, 기존 원칙은 함부로 삭제하지 않는다. 이렇게 정제된 원칙들이 쌓일수록, 워크플로우는 점차 나의 맥락과 기준에 최적화된 방향으로 진화한다.
워크플로우는 처음부터 완성되는 것이 아니라, 반복을 통해 점진적으로 진화한다. 크게 세 단계로 볼 수 있다.
초기 1~2회는 모든 단계에 직접 개입한다. 에이전트 출력 품질을 캘리브레이션 하고, 교훈을 추출해 Rules와 Skills에 반영하는 것이 주된 역할이다. 3~5회가 되면 Research → Plan 단계의 품질이 안정화된다. Execute 단계에 대한 승인을 점진적으로 위임하기 시작하고, 개입 범위가 좁아진다. 6회 이상이 되면 비로소 완전한 AI Driven 상태에 도달한다. 트리거는 한 줄이면 충분하다.
"A 링크를 참고해서 성능 테스트 수행 후, B 경로 하위에 결과 작성해 줘."
이 한 줄로 설계된 워크플로우 전체가 가동된다. 분석, 계획 수립, 실행, 문서화까지 정해진 구조 위에서 돌아가고, 설계자는 최종 결과물만 검수한다. 즉, 워크플로우가 안정화된 이후로는 반복 작업마다 추가 절감이 발생하므로 사용할수록 투자 대비 효율(ROI)이 높아지는 것이다.
유의할 것은, 캘리브레이션을 충분히 거치지 않은 채로 위임을 서두르면 저품질 또는 내 의도와 부합하지 않는 산출물이 지속적으로 누적된다는 점이다. '좋은' 결과물을 얻고 싶다면 인수인계 과정에 충분히 공을 들이기 바란다.
여기서 가장 중요한 마인드셋 전환이 있다.
이제는 무엇을 잘 다루느냐가 아니라, 어떻게 다룰 것인가를 고민해야 한다.
Playwright를 잘 쓰는 것, TestRail을 잘 쓰는 것, 이것들이 더 이상 핵심 역량이 아닌 시대가 오고 있다. AI는 도구 사용법을 순식간에 습득한다. 반면 "이 테스트를 왜 해야 하는가", "어떤 기준으로 시나리오를 설계해야 하는가", "결과를 어떻게 해석하고 조직에 전달해야 하는가"는 AI가 스스로 답하지 못한다. 이것이 사람의 영역이다. 방향을 설정하고 기준을 세워 결정을 내리는 에이전트들의 CEO이자, 설계자가 되어야 한다.
QA로 비유하자면, 테스트를 직접 전부 수행하는 QA와 테스트 전략을 설계하고 팀을 이끄는 QA는 다르다. AI 시대에 우리가 지향해야 할 방향은 후자다. 도구를 잘 다루는 사람이 아니라, 도구를 어떻게 다룰지 깊이 사고하는 사람.
더 깊이 사고하는 사람만이 살아남는다.
이것이 내가 워크플로우를 설계하고 실무에 적용하며 도달한 결론이다.
지금 당신이 AI에게 일을 시키는 방식을 한번 돌아보길 바란다.
당신은 AI를 사용하고 있는가, 아니면 AI와 일하고 있는가?
그리고 그 일 하는 방식을, 당신이 설계하고 있는가?
그 차이는 생각보다 유의미할 것이다.