전체 아티클LLM QA
LLM · Test Case Generation · Model Comparison

LLM 기반 테스트 케이스 생성
파이프라인 구축 과정에서 깨달은 점

동일한 요구사항에서 생성되는 테스트 케이스를 비교하며 모델별 품질 차이, 프롬프트·로직 변경의 영향, 반복 실행 편차와 할루시네이션 사례를 확인했습니다.

기반 모델 비교프롬프트·로직 회귀비결정성·할루시네이션

복수의 무료 제공 LLM과 Claude를 직접 연결해 테스트 케이스 생성 파이프라인을 구축하고, 동일한 요구사항에서 각 모델이 생성하는 결과를 비교했습니다.

이 과정에서 LLM 기능의 품질은 프롬프트만으로 결정되지 않으며, 연결된 모델의 성능과 프롬프트·로직 설계, 비결정성 및 할루시네이션을 함께 고려해야 한다는 점을 확인했습니다.

LLM RESULT REVIEW FLOW 같은 요구사항에서 생성된 결과를 직접 비교하고 반복 확인
INPUT 동일한 요구사항
CONNECTED MODELS 무료 LLM A 무료 LLM B Claude
RESULT REVIEW 생성된 TC 비교
맥락 이해·형식 준수 TC 구체성·완성도 실행별 결과 편차 할루시네이션 사례
QA REVIEW

한 번의 성공 결과가 아니라 모델별 결과와 반복 실행의 차이를 직접 확인

1. 연결된 모델이 결과 품질에 가장 큰 영향을 미쳤다

여러 무료 모델과 Claude에 동일하거나 유사한 요구사항을 전달해 결과를 비교했습니다. 그 결과 모델에 따라 다음 항목에서 차이가 발생했습니다.

  • 요구사항과 맥락을 이해하는 수준
  • 지시사항과 출력 형식을 준수하는 정도
  • 테스트 케이스의 구체성과 완성도
  • 여러 조건을 빠짐없이 반영하는 능력
  • 이전 대화와 결과의 일관성을 유지하는 정도

프롬프트를 구체화하거나 생성 로직을 보완하면 일부 결과를 개선할 수 있었지만, 모델 자체의 이해 및 추론 역량이 충분하지 않은 경우에는 결과 품질을 일정 수준 이상 높이는 데 한계가 있었습니다.

특히 직접 비교한 환경에서는 Claude를 연결했을 때 복합적인 요구사항과 문맥을 상대적으로 더 잘 반영하는 결과를 확인했습니다.

이를 통해 프롬프트 엔지니어링에 앞서 서비스의 목적과 요구 품질에 적합한 모델을 선정하는 것이 중요하며, 기반 모델의 역량이 결과 품질의 상한선을 결정한다는 점을 깨달았습니다.

2. 작은 프롬프트와 로직 변경도 전체 결과에 영향을 미쳤다

프롬프트나 생성 로직을 일부 변경했을 때, 수정하려던 항목뿐 아니라 기존에 정상적으로 생성되던 다른 항목의 결과까지 달라지는 경우가 있었습니다.

예를 들어 기존 테스트 케이스를 참고해 새로운 테스트 케이스를 생성하도록 조건을 추가하자, 참고 정보가 필요한 항목뿐 아니라 나머지 결과의 내용과 품질도 함께 변경되었습니다.

  • 한 항목을 개선하기 위한 조건이 다른 항목의 품질을 떨어뜨림
  • 프롬프트의 순서나 표현에 따라 결과가 달라짐
  • 여러 조건을 함께 전달할 때 조건 간 간섭이 발생함
  • 새로운 로직 추가 후 기존 정상 결과에서 회귀 문제가 발생함

이를 통해 프롬프트나 로직을 변경한 후에는 변경 대상만 확인하는 것이 아니라, 기존 결과를 포함한 전체 결과물을 다시 검증해야 한다는 점을 확인했습니다.

또한 서로 영향을 주기 쉬운 항목은 생성 단계를 분리하거나, 프롬프트에서 각 조건의 적용 범위와 우선순위를 명확히 할 필요가 있었습니다.

3. 비결정성으로 인해 한 번의 성공만으로 품질을 판단할 수 없었다

동일하거나 유사한 입력값과 프롬프트를 사용하더라도 항상 같은 결과가 생성되지는 않았습니다. 여러 차례 좋은 품질의 결과가 나오다가 별도의 변경 없이 요구사항과 다른 결과가 생성되는 경우도 있었습니다.

이러한 비결정성으로 인해 다음과 같은 검증상의 어려움이 있었습니다.

  • 문제가 항상 동일하게 발생하지 않아 재현하기 어려움
  • 한 번의 성공 결과만으로 정상 동작을 판단하기 어려움
  • 프롬프트 수정 효과와 실행별 편차를 구분하기 어려움
  • 정상 결과와 비정상 결과 사이의 품질 차이가 크게 발생함

따라서 LLM 기반 기능은 단일 실행 결과가 아니라 동일한 조건으로 반복 실행했을 때 결과가 허용 가능한 품질 범위 안에서 유지되는지를 확인해야 했습니다.

4. 자연스러운 답변에서도 할루시네이션 사례를 확인했다

LLM이 사실과 다른 내용을 자연스럽고 확신에 찬 형태로 생성하거나, 자신의 답변을 충분히 검토하지 않은 채 사용자의 의견에 동의하는 사례를 확인했습니다.

기존 답변에 문제가 없는데도 사용자가 오류를 지적하면 “맞습니다. 제가 잘못 설명했습니다”라고 답하거나, 사용자가 제시한 잘못된 수정 방향을 그대로 수용해 다른 부분까지 잘못 변경하기도 했습니다.

관련 화면 이미지
사용자의 지적을 검증하지 않고 자신의 답변이 잘못되었다고 인정한 사례
관련 화면 이미지
잘못된 수정 방향을 수용해 다른 부분까지 재검토해야 했던 사례

이를 통해 자연스럽고 확신에 찬 답변도 그대로 신뢰할 수 없으며, 원본 요구사항과 별도의 기준 데이터를 바탕으로 결과를 확인할 필요가 있다는 점을 깨달았습니다.

종합

LLM 기반 테스트 케이스 생성 파이프라인을 구축하며 다음 사항의 중요성을 확인했습니다.

  1. 서비스 목적에 맞는 기반 모델 선정
  2. 모델별 정확성, 문맥 이해도 및 지시 이행 능력 비교
  3. 프롬프트와 로직 변경 이후 전체 결과에 대한 회귀 검증
  4. 동일 조건의 반복 실행을 통한 결과 편차 확인
  5. 할루시네이션 가능성을 고려한 원본 요구사항 기반의 결과 확인

가장 큰 깨달음은 프롬프트와 로직 설계도 중요하지만, 연결된 모델의 역량이 결과물의 기본적인 품질 수준을 가장 크게 좌우한다는 점이었습니다.