현대 소프트웨어 테스팅 아키텍처에서 생성형 AI는 단순한 도구(Tool)를 넘어 테스터의 '생각하는 파트너(Thinking Partner)'로 진화했습니다. 이제 테스터의 역량은 테스트 케이스를 직접 작성하는 기술을 넘어, AI 활용능력 프레임워크가 정의하는 세 가지 상호작용 방식—자동화(Automation), 증강(Augmentation), 그리고 에이전트(Agency)—을 얼마나 능숙하게 오가는가에 따라 결정됩니다. 단순히 테스트 케이스 하나를 생성하는 '자동화'를 넘어, AI와 함께 엣지 케이스를 브레인스토밍하는 '증강', 그리고 특정 보안 가이드라인을 준수하는 AI '에이전트'를 CI/CD 파이프라인에 배치하는 단계로 나아가기 위해 프롬프트 엔지니어링은 테스터가 반드시 익혀야 할 새로운 설계 언어입니다. 프롬프트는 단순한 명령어가 아닌, AI의 출력을 제어하는 구조적 설계물로 정의할 수 있습니다. 특히 시니어 아키텍트는 일관성 있는 결과를 위해 시스템 프롬프트(System Prompt)와 사용자 프롬프트(User Prompt)를 명확히 구분해야 합니다. 시스템 프롬프트는 AI의 전체적인 가이드와 퍼소나를 담당하며, 사용자 프롬프트는 개별 테스트 작업의 컨텍스트와 지시를 담당합니다. 구성 요소 정의 및 역할 아키텍처 설계 전략 (예시) 역할 (Role) AI에게 부여하는 특정 전문 퍼소나 [System] "너는 ISTQB 표준을 준수하는 10년 차 시니어 테스팅 아키텍트야." 제약 조건 (Constraints) 출력 형식, 범위, 비결정론적 행동 제어 [System] "반드시 Gherkin 형식으로 출력하고, 할루시네이션 방지를 위해 근거가 없는 테스트 데이터는 생성하지 마." 컨텍스트 (Context) 테스트 대상 시스템(SUT) 및 도메인 지식 [User] "대상은 MSA 기반의 실시간 금융 결제 모듈이며, ISO 25010 품질 모델을 기준으로 해....
수년간 테스팅 현장을 지키다 보니 참 많은 변화를 목격하게 됩니다. 예전에는 검증해야 할 대상이 명확한 '코드'와 정해진 '기호'의 세계였다면, 최근에는 그 물결의 성격이 근본적으로 변하고 있다는 것을 피부로 느끼곤 합니다. 그래서 한동안 버리다시피 방치한 이 블로그에 잠시 우리가 마주한 이 새로운 기술적 패러다임과, 그 안에서 테스터가 가져야 할 마음가짐에 대해 제 개인적인 생각을 적어보고자 합니다. 누군가에는 도움이 되길 바라는 마음입니다. 우리가 과거에 다루던 SW는 명확한 논리 규칙(Logic rules)을 사용하던 시대였죠. 'A이면 B이다'라는 규칙이 명확했기에, 테스터의 역할도 그 규칙이 잘 지켜지는지 확인하는 데 집중되어 있었습니다. 하지만 이제는 생활의 일부가 되어버린듯한 생성형 AI(Generative AI)는 전혀 다른 차원의 존재입니다. 대규모 데이터셋의 패턴을 학습하여 사람과 유사한 콘텐츠를 만들어내는 생성형 AI는, 규칙이 아니라 '통계적으로 그럴듯함(Statistically plausible)'을 기반으로 답을 내놓습니다. 여기서 중요한 점은 '그럴듯해 보인다'는 것이 반드시 '정확하다'는 의미는 아니라는 사실입니다. 이제 테스터는 단순히 코드의 결함을 찾는 수준을 넘어, 맥락을 파악하고 일관성 있는 응답을 내놓는지, 그 과정에서 논리적 비약은 없는지 살피며 AI와 상호작용해야 합니다. 테스팅의 대상이 '딱딱한 규칙'에서 '유연한 행동'으로 넘어가고 있는 셈이지요. 이런 변화 속에서 제가 강조하고 싶은 개념은 단순히 도구 사용법을 익히는 숙련도가 아니라, 'AI 활용능력(AI Fluency)'입니다. 이는 AI를 단순한 도구가 아니라, 우리의 능력을 확장해 주는 함께 생각하는 파트너(Augmentation)로 바라보는 관점의 전환을 의미합니다. 테스터가 가진 날카로운 도메인 지식과 AI의 생성 능력이 결합...