AI는 소프트웨어와 다른 기준으로 시험해야 한다

AI 프로젝트가 운영 환경에서 실패하는 경우는 대개 조직 차원의 문제부터 시작한다. 업무 담당자와 구체적인 사례를 놓고 ‘충분히 잘 작동한다’는 기준을 합의하고, 배포 뒤에도 계속 측정해야 한다.

확률적으로 작동하는 시스템에는 확률에 맞는 합격 기준이 필요하다. 한 번의 실행 결과가 아니라 고객이 승인한 기준 사례 집합(golden set)에서 통과하는 비율을 측정해야 한다. 또한 검색은 생성과 따로, 에이전트는 최종 답변이 아니라 실행 기록으로, 도구 사용은 통합 기능과 함께 평가해야 한다.

결정론과 확률론의 차이

전통적인 소프트웨어 테스트에는 대부분의 엔지니어가 의심할 필요가 없는 가정이 깔려 있다. 시스템은 결정론적으로 작동한다. 같은 입력은 같은 출력을 만든다. 올바른 결과를 정의하고 이를 확인한 뒤 다음 단계로 넘어간다.

AI 시스템은 그렇지 않다. 언어 모델은 입력이 같아도 호출할 때마다 다른 결과를 낼 수 있다. 정답 하나가 있는 것이 아니라 가능한 답변의 분포가 있고, 그중에는 더 나은 답변과 더 나쁜 답변이 있다. 해야 할 일은 그 분포의 특성을 파악하고 어느 정도의 결과를 허용할지 정하는 것이다.

따라서 테스트의 질문도 달라진다. 이제 ‘통과했는가?’가 아니라 ‘필요한 방식으로 작동하는 비율은 얼마인가?’를 물어야 한다.

단 한 번의 테스트로 알 수 있는 것이 적다면 AI의 지속적 통합·지속적 배포(CI/CD) 방식도 다시 생각해야 한다. 정확성이 확률적이라면 합격 기준도 확률적이어야 한다. 제공업체가 기반 모델을 업데이트하면 우리 쪽에서 코드를 한 줄도 바꾸지 않았는데 시스템이 달라질 수 있다. 직접 일으키지 않았고 알아차리지 못할 수도 있는 성능 변화가 생긴다.

그렇다고 전통적인 품질 보증(QA)의 원칙이 틀린 것은 아니다. 일찍, 지속적으로, 운영 환경과 비슷한 조건에서 테스트해야 한다는 원칙은 여전히 유효하다. 달라지는 것은 테스트의 구체적인 방식이다.

소프트웨어 테스트와 AI 테스트의 차이

경영진이 가장 먼저 주목하는 것은 마지막 항목이다. 여러 모델 버전에서 수백 개의 평가 사례를 실행하고 모델이 결과를 채점하게 하면 매번 비용이 든다. 해법은 테스트를 줄이는 것이 아니라 계획적으로 나누는 것이다. 변경할 때마다 작고 빠른 테스트를 돌리고, 출시 전에 전체 테스트를 실행하며, 평가 예산을 담당할 사람을 지정해야 한다.

피라미드는 유지되지만 각 층의 내용은 달라진다

테스트 피라미드는 여전히 유용한 사고 틀이다. 아래에는 빠르고 저렴한 테스트를 많이 두고, 위로 갈수록 느리고 비싼 테스트를 적게 둔다. AI에서도 이 원리는 유지된다. 바뀌는 것은 각 층에 들어가는 테스트의 내용이며, 피라미드 바깥에 별도로 놓이는 중요한 요소도 있다.

단위 테스트는 데이터 처리, 청크 분할 로직, 응답 파싱, 오류 처리처럼 결정론적으로 작동하는 코드를 검사한다. 여기에 AI에 특화된 층으로, 엄선한 기준 사례 집합에서 실행하는 소규모 모델 평가를 둔다. 이 평가는 단위 테스트를 대체하지 않는다. 서로 다른 구성 요소를 서로 다른 방식으로 점검한다.

통합 테스트는 구성 요소가 함께 작동하는지 확인한다. 검색 증강 생성(RAG) 시스템에서는 검색과 생성을 하나의 파이프라인으로 테스트한다. 에이전트 시스템에서는 현실적인 작업 순서에 따라 모델과 도구를 함께 테스트한다. 구성 요소별 테스트는 통과하지만 서로 조정해야 할 때 깨지는 상호작용 문제가 이 단계에서 드러난다.

인수 테스트와 종단 간 테스트는 사용자의 관점에서 전체 시스템을 검사한다. AI에서는 고객이 성공으로 합의한 여러 시나리오를 시스템이 처리하는지 확인하는 과정이다. 고객이 승인한 구체적인 입력·출력 사례인 기준 사례 집합을 인수 기준으로 삼는다. 이 단계는 느리고 비교적 비용이 많이 들므로 모든 커밋마다 실행하기보다 출시 전에 실행한다.

운영 모니터링은 테스트 단계가 아니라 출시 주기와 별개로 이어지는 과정이다. 출력 분포가 바뀌고 모델 동작이 진화하며, 사용자의 질의도 테스트 모음이 예상하지 못한 방식으로 달라진다. 모니터링은 피라미드를 대체하지 않는다. 피라미드가 전제한 조건이 더는 성립하지 않는 시점을 알려준다.

어느 한 단계라도 생략하면 보이지 않는 문제가 생긴다. 모든 단계를 감당할 수 있는지가 아니라, 어떤 사각지대를 감수할 것인지가 질문이다.

실제로 문제가 되는 실패 유형

환각이 가장 많은 주목을 받으며, 당연히 점검 대상에 들어간다. 그러나 운영 환경에서는 세 가지 덜 눈에 띄는 실패가 더 큰 피해를 주는 경우가 많다. 아무도 그 문제를 찾고 있지 않기 때문이다.

프롬프트 회귀는 프롬프트를 조금 바꾸거나 제공업체가 모델을 업데이트해 이전에 작동하던 동작이 깨지는 현상이다. 오류는 발생하지 않는다. 시스템은 계속 실행되지만 지난주까지 괜찮았던 사례에 더 나쁜 답을 한다. 프롬프트를 버전별로 관리하고 자동 회귀 테스트를 하지 않으면 사용자가 알아차릴 때까지 아무도 문제를 보지 못한다.

좁은 지표를 쓰면 잘못된 것을 측정하기 때문에 테스트가 통과한다. 형식은 맞고 지연 시간도 기준 안에 있지만, ‘좋은 답변’을 자동으로 확인할 수 있도록 정의하지 않아 답변 품질이 떨어지고 있을 수 있다.

기준선이 없으면 새 버전이 나아졌는지 판단할 때마다 직감과 일부 사례에 의존하게 된다. 팀이 잘못된 결정을 내리는 것이 아니라, 제대로 결정할 데이터가 없는 것이다.

환각은 모델이 그럴듯하지만 거짓인 내용을 말하는 현상이다. 환각을 발견하면 문제는 분명하지만, 대규모로 찾아내는 일이 어렵다.

앞의 세 가지 문제는 피해가 발생한 뒤에야 드러나는 경우가 많다. 환각은 나타나면 보이지만 의도적으로 점검하지 않으면 대규모로 잡아내기 어렵다. 어느 경우든 보호 수단은 절차뿐이다.

AI 테스트 전략에 포함할 항목

운영 환경에 적합한 AI 테스트 전략은 여러 층을 결합해야 한다. 어느 한 층만으로 충분하지 않으며, 각 층은 다른 층이 놓치는 부분을 보완한다.

• 고객과 합의한 기준 사례 집합을 마련한다. 실제 입력 수십 개와 그에 대응하는 예상 출력을 업무 책임자가 승인하도록 한다. 이 집합은 기준선이자 인수 기준이며 회귀 테스트 모음이 된다. 이것이 없으면 다른 모든 층도 비교할 기준이 없다.
• 프롬프트를 버전별로 관리하고 변경할 때마다 자동 평가한다. 프롬프트와 모델 버전을 코드처럼 다룬다. 변경 사항을 검토하고 기준 사례 집합에 대해 평가를 실행해야 사용자가 알아차리기 전에 프롬프트 회귀를 잡을 수 있다.
• 업무에서 중요하게 여기는 것을 반영한 지표를 쓴다. 형식과 지연 시간은 필요하지만 충분하지 않다. 구조와 필수 필드 같은 결정론적 검사, 관련성·완결성·어조를 보는 모델 채점, 표본에 대한 정기적인 사람의 검토를 결합한다. ‘좋은 답변’을 자동으로 확인할 수 없다면 확인할 수 있도록 기준을 정의한다.
• 근거 확인을 수행한다. 자체 데이터에서 답하는 시스템이라면 답변이 검색된 출처로 뒷받침되는지, 인용한 내용이 답변의 주장과 일치하는지, 모를 때 모른다고 밝히는지 확인한다.
• 아키텍처에 맞춰 평가한다. 검색은 생성과 별도로 측정한다. 에이전트는 최종 답변만이 아니라 실행 기록을 평가한다. 도구 사용은 인터페이스만 따로 보는 데 그치지 않고 모델과 함께 테스트한다.
• 기준이 있는 출시 관문을 둔다. 기준 사례 중 어느 비율이 통과해야 하는지, 결과가 기준보다 낮을 때 출시를 막을지, 롤백할지, 상위 단계에 알릴지 미리 합의한다. 아무도 조치하지 않는 임계값은 장식에 불과하다.
• 담당자가 정해진 운영 모니터링을 한다. 실제 출력 표본을 정기적으로 살펴 같은 기준으로 검토하고 시간에 따른 변화를 추적한다. 운영 중인 모델 동작을 책임지고 평가를 계속할 예산도 가진 사람을 특정한다.
• 고객을 대상으로 하는 시스템에는 적대적 테스트를 수행한다. 탈옥, 프롬프트 인젝션, 약속이나 기밀 데이터 추출 시도 등으로 시스템을 의도적으로 깨뜨려 본다. 사용자가 시도할 것이므로 먼저 시험하는 편이 낫다.

시스템 유형에 따라 테스트 전략도 달라진다

일반 언어 모델, 검색 증강 시스템, 에이전트, 외부 서비스 통합은 아키텍처와 실패 유형이 서로 다르다. 테스트 전략은 그 아키텍처에 맞춰야 한다.

검색 증강 시스템에서 가장 흔한 실수는 검색을 측정하기 전에 생성 계층부터 조정하는 것이다. 검색이 올바른 문서를 가져오지 못하면 프롬프트 엔지니어링만으로 정확한 답을 만들 수 없다. 모델이 검색 내용을 받기 전에 검색 파이프라인을 별도 지표로 평가해야 한다. 입력으로 무엇이 들어갔는지 모르면 생성을 제대로 판단할 수 없다.

에이전트는 최종 출력만 테스트하면 오해를 부른다. 에이전트가 잘못된 경로를 거쳐 우연히 올바른 결론에 도달할 수도 있고, 출력에서는 보이지 않는 이유로 실패할 수도 있다. 앞선 세 단계에서 난 오류가 조용히 다음 단계로 이어지는 경우가 그 예다. 에이전트 테스트는 출력 뒤에 있는 판단, 도구 호출, 중간 상태의 순서인 실행 기록을 검사해야 한다. 우연히 가끔 정답을 내는 시스템은 신뢰할 수 없다.

외부 서비스 통합에서는 서로 다른 두 가지를 구분해야 한다. 하나는 스키마, 인증, 오류 처리 등 인터페이스로서 통합 기능이 작동하는지다. 다른 하나는 모델이 통합 기능이 제공하는 것을 이해하고, 언제 호출해야 하는지 판단하며, 반환된 결과를 제대로 해석하는지다. 둘 다 중요하며 어느 쪽도 다른 쪽을 대신하지 못한다.

직관과 달리 모델이 도구를 호출하지 않는 이유는 도구가 고장 나서가 아니라 설명이 모호해 모델이 언제 써야 하는지 모르는 데 있을 수 있다. 통합 기능 자체의 테스트는 모두 통과하지만 기능은 전혀 작동하지 않는 상황이다. 모델과 통합 기능을 함께 테스트해야 이런 문제가 드러난다.

고객과의 검증도 테스트 과정이다

지금까지 다룬 문제는 주로 기술적이다. 여기서부터는 조직의 문제다. 기업 고객에게 AI 시스템을 제공한 경험을 보면, 모델 품질보다 이 문제가 더 많은 프로젝트를 좌초시킨다.

AI 시스템을 기업 고객에게 납품할 때 흔히 반복되는 상황이 있다. 팀은 작동하는 무언가를 만들고 시연한다. 고객은 ‘우리가 뜻한 것은 이게 아니다’라고 말한다. 이어지는 대화는 비용이 들고 혼란스러우며 관계를 해칠 때도 있다. 대부분은 예방할 수 있었던 일이다.

근본 원인은 대개 팀이 잘못된 것을 만든 데 있지 않다. ‘올바른 결과’를 확인 가능한 방식으로 정하지 않은 것이 문제다. 문서로 된 요구사항은 언어로 동작을 규정하지만 언어는 모호하다. AI 시스템이 ‘무엇을 해야 하는지’를 설명하는 같은 문장을 읽고도 사람마다 실제 모습에 대해 서로 다른 생각을 할 수 있다.

고객이 결과를 보기 전에 원하는 것을 완전히 명세하리라고 기대하는 것은 AI 시스템의 작동 방식과 구조적으로 맞지 않는다. 이 현실에 맞춰 절차를 설계할 것인지, 계속 예상 밖의 일로 받아들일 것인지가 관건이다.

이를 고려한 절차는 글로 된 설명보다 구체적인 사례를 통해 합의를 쌓는다. 중요한 시연에 앞서 기대치를 조정해 한 번의 나쁜 출력이 시스템에 대한 고객의 인식을 좌우하지 않게 한다. 기술 검토와 업무 검토도 분리한다. 기술 검토에서는 시스템이 측정 가능한 기준에 따라 작동하는지 확인하고, 업무 검토에서는 고객의 실제 업무 흐름에서 가치를 주는지 살핀다. 두 검토에는 서로 다른 대화와 참여자, 준비가 필요하다.

고객이 시스템을 본 뒤 방향을 바꿀 때를 위한 명확한 절차도 마련해야 한다. AI 프로젝트에서는 이런 일이 일어날 가능성이 높다. 고객 기대가 바뀌면 변경 사항을 분류하고 기록해 결정하는 구조화된 절차를 밟을지, 아니면 아무도 충분히 이해하지 못한 피드백을 맞추려 혼란스럽게 대응할지가 중요하다.

‘완료’에 대한 더 현실적인 정의

AI 엔지니어링에서 가장 어려운 변화는 ‘완료’가 안정된 종착점이 아니라고 받아들이는 것이다. 소프트웨어 모듈은 테스트를 마치고 출시하면 누군가 코드를 바꾸기 전까지 완료 상태다. 반면 오늘 잘 작동하는 AI 시스템도 기반 모델이 바뀌거나 입력이 달라지거나 검색 데이터가 오래되면 3개월 뒤 성능이 나빠질 수 있다.

그렇다고 일이 끝나지 않는다는 뜻은 아니다. 일이 다른 형태로 바뀐다는 뜻이다. 배포는 품질 작업의 끝이 아니라 다른 종류의 작업이 시작되는 시점이다. 신뢰할 수 있는 AI 시스템을 만드는 팀은 사용자가 문제를 알리기 전에 성능 저하를 드러내는 모니터링, 운영 중인 모델의 명확한 책임자, 시간이 지나도 ‘시스템이 작동한다’는 말이 무엇을 뜻하는지에 대한 고객과의 공통된 이해를 처음부터 설계한다.

좋은 소프트웨어 엔지니어를 만드는 원칙은 좋은 AI 엔지니어에게도 여전히 유효하다. 일찍 테스트하고, 지속적으로 테스트하며, 만들기 전에 올바른 결과를 정의한다. 변경은 작고 추적 가능하게 유지하고 롤백 계획을 마련한다. 새로 필요한 것은 확률적으로 작동하고 외부 요소에 의존하며 오류 하나 내지 않고도 성능이 저하될 수 있는 시스템에 이 원칙을 적용하는 방식이다.

가장 중요한 변화는 기술이 아니라 인식의 방식에 있다. ‘작동하는가?’ 대신 ‘어떤 조건에서 얼마나 자주 작동하며, 무엇이 달라졌을 때 어떻게 알아차릴 수 있는가?’를 묻는 것이다. 이런 변화를 받아들이는 팀은 오래 견디는 시스템을 만든다. 그렇지 않은 팀은 시연 때는 작동했던 시스템을 계속 출시하게 된다.