Skill File과 Local LLM을 사용하여 1인 AI QA 에이전시를 구축한 방법

AI 보조 QA (Quality Assurance) 작업에는 대부분의 도구 관련 논의에서 완전히 생략되는 특정한 실패 모드가 존재하며, 이는 실제 프로젝트를 혼자 수행할 때 가장 먼저 나타납니다.

모든 새로운 채팅 세션은 상태가 없는 (stateless) 방식입니다. 티켓을 붙여넣고, 기능을 설명하고, 심각도 (severity) 로직을 설명하고, 컨텍스트 (context)를 설정하다 보면, AI가 실제로 유용해질 때쯤이면 이미 그 주에만 세 번째로 자신의 방법론을 처음부터 다시 구축하고 있는 자신을 발견하게 됩니다. 이것은 더 나은 프롬프트 (prompt)로 해결할 수 있는 워크플로우 (workflow) 문제가 아닙니다. 이것은 아키텍처 (architecture) 문제이며, 해결책은 바로 스킬 파일 (skill file)입니다.

QAJourney는 qajourney.net/ai-qa-workflow-for-real-projects에서 실제 스킬 파일을 무료 다운로드할 수 있도록 포함하여 이 시스템에 대한 전체적인 분석을 제공합니다. 요약하자면, 스킬 파일은 시스템 프롬프트 (system prompt)로 로드하는 컨텍스트 문서입니다. 여기에는 테스트 표면 계층 (test surface tiers), 3단계 테스트 프레임워크 (three-path testing framework), 버그 보고 형식, 심각도 및 우선순위 로직, Playwright 컨벤션 (conventions), 그리고 AI가 무엇을 호출할 수 있고 무엇을 호출할 수 없는지에 대한 명시적인 정의가 담겨 있습니다. 세션당 한 번만 로드하면 됩니다. 그러면 AI는 백지 상태가 아니라 첫 번째 메시지부터 사용자의 방법론 안에서 작동합니다.

로컬 LLM (Local LLM) 레이어는 다른 문제를 해결합니다. 프리랜서 또는 리테이너 (retainer) 계약 프로젝트에서 티켓에는 실제 제품 로직과 실제 고객 데이터가 포함되어 있습니다. 매 세션마다 이를 클라우드 API (cloud API)로 전송하는 것은 컴플라이언스 (compliance) 문제로 비화하든 아니든 데이터 노출 문제입니다. 동일한 스킬 파일을 시스템 컨텍스트로 사용하여 Ollama를 로컬에서 실행하면 프로젝트 데이터를 기기 내에 유지할 수 있습니다. QA 작업에 필요한 출력 품질을 위해서는 현재 7B에서 14B 규모의 모델로도 충분합니다. 토큰당 한계 비용이 0이라는 점은 이를 세션당 비용을 지불하는 서비스가 아닌 인프라 (infrastructure)로 만들어 줍니다.

워크플로우의 3가지 역할 설정은 다음과 같습니다: 판단 레이어 (judgment layer)로서의 엔지니어, 복잡한 추론과 활성 세션 출력을 위해 스킬 파일이 로드된 클라우드 AI, 그리고 가벼운 작업과 고객 데이터 작업을 위한 로컬 LLM. 스킬 파일은 이 세 가지 모두를 관통하는 불변의 요소입니다.

내재화하는 데 시간이 걸렸던 부분은 다음과 같습니다: AI 개발 팀은 이미 자체적인 QA 레이어 (QA layer)를 운영하고 있다는 점입니다. 모든 변경 사항에 대한 린터 (Linters), 자동으로 실행되는 유닛 테스트 (unit tests), PR (Pull Request)이 열리기 전 에이전트가 생성한 Playwright 스크립트 등이 그것입니다. 리뷰 단계에서 티켓을 확인하는 시점에는 이미 명백한 경로들에 대한 테스트가 완료된 상태입니다. 여러분의 업무는 에이전트의 테스트가 끝나는 지점에서 시작됩니다. 즉, 명세서(spec)에 무엇을 만들라고 되어 있었는지가 아니라, 실제 사용자가 기대할 법한 내용에 비추어 에이전트가 구축한 것을 테스트하는 것입니다. 이 두 가지는 서로 다릅니다.

본문에서 언급된 결제 기능 사례가 이를 가장 명확하게 보여줍니다. 모든 수락 기준 (acceptance criterion)을 통과했습니다. 코드는 기술적으로 정확했습니다. 하지만 결제 내역이 없었고, 정기 결제에 대한 표시도 없었습니다. 해당 화면을 처음 접하는 실제 사용자라면 자신의 돈에 어떤 일이 일어났는지 전혀 알 수 없었을 것입니다. 에이전트는 티켓에 명시된 대로 구축했습니다. 하지만 티켓에는 사용자가 결제 맥락에서 상황을 파악하는 데 무엇이 필요한지는 명시되어 있지 않았습니다. 이것은 코드의 문제가 아닙니다. 제품 로직 (product logic)의 문제이며, 이는 오직 인간이 사용자 의도를 가지고 화면을 읽을 때만 드러납니다.

이러한 검증은 자동화할 수 없습니다. 스킬 파일 (skill file)이 메워주는 커버리지 격차 (coverage gap)도 아닙니다. 스킬 파일은 기계적인 작업을 처리함으로써, 판단 레이어 (judgment layer)가 오직 인간만이 할 수 있는 업무를 수행할 여유를 만들어줍니다. 커버리지 매핑 (coverage mapping), 테스트 케이스 생성 (test case generation), 버그 리포트 스캐폴딩 (bug report scaffolding), 엣지 케이스 확장 (edge case expansion), Playwright 스캐폴드 (Playwright scaffolds) 등은 시스템이 수동 작업보다 더 빠르고 일관되게 처리합니다. 제품을 사용자가 읽는 방식으로 읽는 것: 그것은 여전히 여러분의 몫입니다.

만약 여러분이 어떤 형태든 1인 QA 운영이나 리테이너 계약 (retainer engagement)을 수행하고 있다면, 실질적인 교훈은 다음과 같습니다: 이를 AI에 로드하려고 시도하기 전에 여러분의 방법론 (methodology)을 먼저 글로 적으십시오. 그것을 글로 쓰는 행위 자체가 판단 레이어를 가시화합니다. 무엇이 파일로 전달되고 무엇이 전달되지 않는지를 정확히 보게 될 것이며, 그 두 가지 사이의 간극이 바로 실제 직무 기술서 (job description)가 됩니다.

전체 버전과 라이트 (lite) 버전의 전체 스킬 파일은 해당 포스트에서 무료 다운로드로 제공됩니다.