개념
개인이 잘 쓰는 것과 조직이 잘 쓰는 것은 다르다
지금까지 배운 것들 — 프롬프트 구조, 기법, 검증, 리스크 관리 — 은 대부분 개인이 AI를 잘 쓰는 법 이었다. 그런데 조직 단위로 넘어가면 새로운 문제가 생긴다.
팀원 다섯 명이 각자 챗봇을 쓴다. 프롬프트는 개인 메모에 있고, 품질은 사람마다 다르고, 무엇을 넣었는지는 아무도 모른다. 잘 쓰는 한 사람의 역량이 팀의 역량이 되지 않는다.
이 레슨은 그 간극을 다룬다. 앞 레슨에서 본 섀도우 AI 문제의 구조적 해법이기도 하다. 자격증 실라버스도 이 둘을 마지막 두 챕터로 배치한다 — LLM 기반 테스트 인프라 와 조직 배포·통합 이다.
테스트 인프라의 구성요소
"AI 테스트 인프라"라고 하면 거창하게 들리지만, 뜯어보면 다섯 덩어리다.
┌──────────────────────────────────────────────┐
│ ① 모델 접근 계층 │
│ 어떤 모델을, 어떤 경로로, 누가 쓰는가 │
├──────────────────────────────────────────────┤
│ ② 프롬프트·템플릿 관리 │
│ 팀 표준 프롬프트를 버전 관리한다 │
├──────────────────────────────────────────────┤
│ ③ 컨텍스트 소스 │
│ 요구사항·테스트 케이스·결함 이력 (RAG) │
├──────────────────────────────────────────────┤
│ ④ 오케스트레이션 │
│ 체이닝·에이전트·도구 연결 (MCP) │
├──────────────────────────────────────────────┤
│ ⑤ 평가·로깅 │
│ 골든셋 평가, 사용 기록, 비용 추적 │
└──────────────────────────────────────────────┘②와 ⑤가 개인 사용과 조직 사용을 가르는 지점이다. 프롬프트가 개인 메모에 있으면 팀 자산이 아니고, 평가와 로그가 없으면 나아지고 있는지 알 수 없다. 모듈 18a(레슨 12)에서 만든 골든셋이 여기서 조직 자산이 된다.
RAG를 테스트 자산에 붙이기
③ 컨텍스트 소스에서 가장 값이 큰 것이 RAG(검색 증강 생성) 다. 모듈 18b(레슨 3)에서 RAG 시스템을 검증하는 법을 배웠는데, 여기서는 그것을 우리가 쓰는 이야기다.
일반 챗봇은 우리 제품을 모른다. 그런데 우리 조직에는 이런 자산이 있다.
| 자산 | AI에게 주면 |
|---|---|
| 요구사항·기획 문서 | 우리 도메인 용어로 답한다 |
| 기존 테스트 케이스 | 우리 형식과 상세도를 따른다 |
| 과거 결함 이력 | "이 영역은 예전에 이런 게 터졌다" 를 안다 |
| 릴리즈 노트·장애 보고서 | 반복 패턴을 짚는다 |
| 팀 표준·체크리스트 | 우리 규칙에 맞는 산출물을 낸다 |
세 번째가 특히 강력하다. 과거 결함 이력을 근거로 삼으면 "이 기능 변경 시 함께 봐야 할 영역"을 조직의 경험에 기반해 제안할 수 있다. 모듈 4의 리스크 기반 테스트가 데이터로 뒷받침되는 셈이다.
다만 RAG를 붙이면 검증할 것도 늘어난다. 모듈 18b 레슨 3에서 배운 그대로, 검색 단계와 생성 단계를 나눠 봐야 한다 — 엉뚱한 문서를 찾아온 것과 문서는 맞는데 잘못 요약한 것은 다른 문제다.
에이전트 — 어디까지 맡길 것인가
④ 오케스트레이션의 중심에는 에이전트가 있다. 모듈 18a(레슨 5·6)에서 Agentic Testing을, 레슨 10에서 CUA를 다뤘다. 여기서는 자율성 수준 이라는 축을 하나 더한다.
| 수준 | 성격 | 적합한 작업 |
|---|---|---|
| 자율(autonomous) | 사람 개입 최소, 스스로 판단·실행 | 되돌리기 쉽고 영향이 작은 반복 작업 |
| 반자율(semi-autonomous) | 주기적 사람 확인을 거침 | 중요한 작업의 기본값 |
| 멀티 에이전트 | 역할을 나눈 여러 에이전트가 협업(오케스트레이션) | 복합 작업 — 대신 실패 원인 추적이 어려워진다 |
중요한 작업일수록 반자율이 정답이다. 에이전트도 환각·추론 오류·편향을 그대로 갖기 때문이다(레슨 2·4). 완전 자율을 쓰려면 그 결과를 자동으로 검증할 수단이 있어야 하고, 그게 모듈 18c(레슨 6)의 하네스 다.
정리하면: 자율성을 올리려면 검증을 함께 올려야 한다. 검증 없이 자율성만 올리는 것이 사고의 전형적 경로다.
프롬프트냐 RAG냐 파인튜닝이냐
조직에서 반드시 나오는 질문이다. "우리 데이터로 모델을 학습시키면 되지 않나요?" 판단 기준을 표로 정리한다.
| 프롬프트 개선 | RAG | 파인튜닝 | |
|---|---|---|---|
| 해결하는 문제 | 지시가 불명확 | 모델이 우리 정보를 모름 | 형식·스타일·톤이 안 맞음 |
| 비용 | 매우 낮음 | 중간 | 높음 |
| 최신 정보 반영 | — | 즉시(문서만 갱신) | 재학습 필요 |
| 근거 추적 | 어려움 | 가능(출처 표시) | 불가능 |
| 준비 기간 | 시간 | 일~주 | 주~월 |
| 필요한 것 | — | 문서·검색 | 대량의 고품질 학습 데이터 |
순서는 거의 항상 프롬프트 → RAG → 파인튜닝이다. 그런데 조직에서는 파인튜닝부터 이야기가 나오는 경우가 많다. 이유는 "우리만의 AI"라는 말이 주는 인상 때문이고, 실제로 필요한 경우는 드물다.
파인튜닝이 실제로 답인 경우는 좁다 — 출력 형식·스타일을 강하게 고정해야 하고, 그 예시가 수천 건 있으며, 그 형식이 자주 바뀌지 않을 때. 지식을 넣는 용도로 파인튜닝을 하면 대개 실패한다. 지식은 RAG의 일이다.
그리고 파인튜닝을 하면 모듈 18b 레슨 7·8의 데이터 품질 문제가 통째로 따라온다. 학습 데이터의 레이블 정확성·대표성·중복이 그대로 모델 품질이 된다.
LLMOps — 프롬프트도 코드처럼 다룬다
⑤ 평가·로깅을 체계로 만든 것이 LLMOps 다. 이름은 낯설어도 QA에게는 익숙한 개념들의 조합이다.
| LLMOps 항목 | 우리가 이미 아는 것 |
|---|---|
| 프롬프트 버전 관리 | 코드 형상관리(모듈 9) |
| 평가셋으로 회귀 감지 | 회귀 테스트(모듈 11) |
| 모델·프롬프트 변경 시 재평가 | 변경 영향 분석(모듈 4) |
| 실행 로그·트레이스 수집 | 관측성(모듈 14 레슨 6) |
| 비용·지연 모니터링 | 성능 지표(모듈 16) |
| 품질 임계 미달 시 배포 차단 | 품질 게이트(모듈 14 레슨 4) |
"프롬프트를 코드처럼 다룬다" 는 한 문장이 LLMOps의 절반이다. 프롬프트를 저장소에 두고, 변경 이력을 남기고, 바꿀 때마다 골든셋으로 평가하고, 점수가 떨어지면 되돌린다.
여기서 QA가 자연스럽게 맡을 자리가 보인다. 평가셋을 만들고 유지하는 일, 회귀를 감지하는 일, 게이트 기준을 정하는 일 — 전부 QA가 하던 일의 대상만 바뀐 것이다.
섀도우 AI와 도입 로드맵
앞 레슨에서 섀도우 AI를 봤다. 조직이 모르는 채 쓰이는 AI다. 여기에 대한 대응이 도입 전략 이다.
금지가 답이 아닌 이유는 분명하다 — 금지하면 안 쓰는 게 아니라 숨어서 쓴다. 그러면 통제도 학습도 불가능해진다. 실무적인 순서는 이렇다.
① 실태 파악 누가 무엇을 어떻게 쓰고 있는가 (처벌 아님을 먼저 알린다)
↓
② 승인 경로 제공 쓸 만한 도구를 공식 경로로 열어준다
↓
③ 가이드라인 데이터 등급표, 금지 사항, 검증 의무 (앞 레슨)
↓
④ 파일럿 범위를 좁혀 실제 업무에 적용하고 효과를 측정
↓
⑤ 표준화·확산 프롬프트 자산화, 인프라 구축, 교육
↓
⑥ 측정·개선 골든셋 평가, 비용 추적, 정기 점검②가 ③보다 먼저인 것이 중요하다. 대안 없이 규칙부터 만들면 규칙이 지켜지지 않는다.
④ 파일럿에서 측정할 것도 미리 정해둔다. 모듈 11(레슨 3)의 자동화 ROI 계산과 같은 방식이다 — 절감된 시간, 산출물 품질(골든셋 점수), 실행 비용, 그리고 재작업률(AI 결과를 다시 손본 비율).
모델을 고르는 기준
인프라를 만들 때 "어떤 모델을 쓸 것인가"도 결정해야 한다. 최신 대형 모델이 항상 답은 아니다.
| 기준 | 확인할 것 |
|---|---|
| 작업 난이도 | 분류·형식 변환이면 소형 모델(SLM) 로 충분한 경우가 많다 |
| 데이터 등급 | 민감 데이터면 사설 배포가 필요할 수 있다(앞 레슨) |
| 비용·지연 | 매 커밋 실행이라면 비용과 속도가 지배적 |
| 컨텍스트 길이 | 긴 문서를 다루는가 |
| 멀티모달 | 화면·이미지를 다루는가 |
| 재현성 요구 | 감사·증거가 필요하면 버전 고정이 가능한가 |
마지막 줄이 QA에게 중요하다. 모델이 조용히 업데이트되면 어제와 오늘의 결과가 달라진다. 골든셋 평가를 정기적으로 돌려야 하는 이유가 여기에도 있다 — 우리가 아무것도 안 바꿔도 결과가 변할 수 있다.
역할은 어떻게 바뀌는가
마지막으로 사람 이야기다. AI를 도입한 테스트 조직에서 두 역할이 바뀐다.
테스터 — 테스트 설계·실행 전문가에서 AI 지원 테스트 전문가 로. 테스트 기법 전문성은 그대로 유지하면서, AI가 만든 산출물을 안내하고 검증하는 일이 더해진다. 구체적으로는 산출물 리뷰, 프롬프트 개선, 팀 프롬프트 라이브러리 유지.
테스트 매니저 — AI 기반 테스트 전략 수립, AI 리스크 관리, AI 기반 프로세스의 모니터링·통제가 추가된다. 사람과 AI 역량의 균형을 잡고, 사용 사례별 거버넌스를 세우고, 팀이 전통적 테스팅 역량과 AI 활용 능력을 함께 유지하게 하는 일이다.
눈여겨볼 표현이 하나 있다 — 테스트 매니저는 이제 사람 테스터만이 아니라 AI 에이전트와도 협업을 조율 하게 된다. 사람과 AI가 섞인 팀을 관리하는 새로운 기술이 필요해진다는 뜻이다.
모듈 18a(레슨 10)에서 "자동화 엔지니어는 사라지는가"를 다뤘다. 답은 같다 — 줄어드는 것은 직무가 아니라 작업이다. 다만 그 이동을 개인의 학습에만 맡기면 팀 전체가 따라오지 못한다. 그래서 역량 구축이 도입 계획의 일부여야 한다.
실무에서 왜 필요한가
AI 도입을 개인 역량 문제로 두면 조직에는 잘 쓰는 한 명과 안 쓰는 나머지 가 생긴다. 그 한 명이 퇴사하면 남는 것이 없다. 프롬프트를 자산으로 관리하고 평가 체계를 만드는 일은, 개인의 성과를 조직의 역량으로 바꾸는 작업이다.
그리고 이 영역은 QA가 자연스럽게 주도할 수 있다. LLMOps의 항목들이 전부 QA가 하던 일의 대상만 바뀐 것이기 때문이다 — 평가셋 관리, 회귀 감지, 게이트 기준. 인프라를 만드는 것은 개발이 하더라도, 무엇을 평가할지 정하는 것 은 QA의 일이다.
경력 관점에서도 값이 크다. "AI를 써봤다"에서 한 단계 나아가 "팀의 AI 활용 체계를 만들어봤다" 는 아직 드물고, 리드·매니저 트랙으로 가는 이야깃거리가 된다.