15.8.1. 프롬프트 엔지니어와 QA 엔지니어 간의 R&R(Role and Responsibilities) 재정립

소프트웨어 공학의 고전적 체계에서 개발자(Developer)와 품질 보증 엔지니어(QA Engineer)의 경계는 명확했다. 개발자가 코드를 짜면, QA는 그 코트를 부수기 위한 엣지 케이스(Edge Case)를 고안했다. 그러나 거대 언어 모델(LLM) 생태계에서 ’프롬프트(Prompt)’는 기능 구현의 매개체인 동시에, 출력 결과를 제어하고 검증하는 평가의 기준선(Oracle) 역할을 겸한다.

결과적으로 시스템 프롬프트를 작성하는 프롬프트 엔지니어(Prompt Engineer)와 테스트를 설계하는 QA 엔지니어의 역할이 충돌하거나, 최악의 경우 양쪽 모두 책임을 회피하는 사각지대가 발생한다. 오라클 시스템 생존율을 높이기 위해서는 이 두 집단 간의 R&R(Role and Responsibilities)을 본질적으로 재정립해야 한다.

1. 하이브리드 책무의 충돌: 프롬프트는 코드인가, 테스트인가?

프롬프트 엔지니어가 작성한 System Prompt는 애플리케이션의 뼈대 로직이다. 반면, LLM-as-a-Judge가 사용하는 Evaluation Prompt는 명백히 테스트 코드의 영역이다.

만약 프롬프트 엔지니어가 두 프롬프트를 모두 작성한다면, 자신이 만든 로직의 취약점을 스스로 가리는 ’확증 편향(Confirmation Bias)’의 덫에 빠지게 된다. 반대로 고전적인 QA 엔지니어에게 LLM 평가를 전담시키면, 모델의 토큰 구조나 Attention 매커니즘을 이해하지 못한 채 표면적인 Regex 검사에 머무를 확률이 높다.

2. R&R 분리 모델 (Separation of Concerns)

따라서 건강한 오라클 생태계를 위해서는 ’창조(Creation)’와 ’검열(Inspection)’의 주체를 공학적으로 격리해야 한다.

graph TD
    subgraph Prompt Engineering Team
        A[도메인 목적에 맞는 System Prompt 개발]
        B[RAG / Agent 로직 프롬프트 최적화]
        C[성능 향상을 위한 Temperature/Top-P 제어]
    end
    
    subgraph AI QA Engineering Team
        D[Golden Dataset (정답지) 구축 및 큐레이션]
        E[채점 전용 LLM-as-a-Judge 프롬프트 작성]
        F[Adversarial Test (레드팀) 엣지 케이스 주입]
    end
    
    A & B & C -->|프러덕션 AI 모델| G(Actual Output 생성)
    D & E & F -->|오라클 시스템| H(Output 검증 및 Score 산출)
    
    G --> H
    
    H -->|결과 피드백| I{품질 회의}
    I -->|Prompt 엔지니어에게| J[Prompt 보완 지시]
    I -->|QA 엔지니어에게| K[Oracle 기준 완화/강화 지시]
    
    style A fill:#e3f2fd,stroke:#2196f3
    style E fill:#f3e5f5,stroke:#9c27b0

프롬프트 엔지니어의 역할: 비즈니스 요구사항을 LLM이 찰떡같이 알아듣도록 구현하는 ’생산성’에 집중한다. 이들은 기능이 어떻게 작동해야 하는지(How it works)를 가장 잘 알며, 애플리케이션의 메인 모델을 담당한다.
AI QA 엔지니어의 역할 (신규 포지션): LLM-as-a-Judge를 통제하는 심판관이다. 이들은 프롬프트 엔지니어가 만든 결과물을 교묘하게 무너뜨리는 레드팀(Red Teaming) 역할을 수행하며, 채점용 프롬프트의 엄격함(Strictness)을 튜닝하는 데 특화되어 있다. 이들은 ’메인 모델’이 아닌 ’평가 모델’의 프로그래머다.

3. 골든 데이터셋(Golden Dataset) 소유권의 이전

R&R의 핵심적인 변화는 골든 데이터셋의 통제권(Ownership)에 있다. 과거에는 개발자가 유닛 테스트의 AssertTrue 값을 직접 적었지만, AI 파이프라인에서는 골든 데이터셋의 승인 권한을 QA와 도메인 전문가(SME)에게 완전히 이양해야 한다.

프롬프트 엔지니어가 임의로 정답지를 갱신하는 것을 CI 파이프라인 단에서 (e.g., 커밋 훅이나 PR Reviewer 지정) 강제적으로 차단해라. 오라클의 기준선(Baseline)은 QA 팀이 비즈니스 요구사항을 근거로 서명(Sign-off)했을 때만 변경될 수 있다.

4. 소결

거대 언어 모델의 결과물은 끝을 알 수 없는 변수들의 총체다. 코드를 짜는 자가 그 코드를 채점하는 자를 겸임하는 구조는 AI 시스템에서 치명적인 도덕적, 공학적 해이를 낳는다. 프롬프트 엔지니어의 파괴적인 창의성과 QA 엔지니어의 보수적인 검증력이 치열하게 맞붙는 긴장 구도(Tension)를 조직도 위에 명문화해라. 견제받지 않는 프롬프트는 환각을 낳고, 챌린지 받지 않는 오라클은 시스템의 목을 조르게 됨을 명심해라.