AI 테스트 데이터, 우리 업무를 제대로 담고 있을까요?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

- 실제로 들어오는 자료의 형식과 상태를 테스트에 담습니다.

- 자주 들어오는 업무와 드물지만 영향이 큰 업무를 구분합니다.

- 개선에 쓴 자료와 마지막 확인용 자료를 나누어 관리합니다.

AI 도입을 준비하다 보면 시연에서 잘 나온 답변을 어디까지 믿어도 될지 고민됩니다. 정리된 문서에서는 원하는 결과가 나와도 현업에는 짧은 메모, 표가 섞인 파일, 설명이 빠진 요청이 함께 들어옵니다. 어떤 자료로 시험했는지 모르면 결과를 우리 업무에 적용하기도 어렵습니다.

자료를 많이 모으는 것만으로 이 고민이 해결되지는 않습니다. 한 부서의 비슷한 문서만 쌓이면 다른 업무에서 생길 문제는 놓칠 수 있습니다. 오늘은 AI 테스트 데이터를 고를 때 실제 업무의 차이를 어떻게 담고, 시험 결과를 어느 범위까지 해석할지 알아보겠습니다.

정리된 문서만으로 시험하고 있지는 않나요?

테스트 자료는 AI가 실제로 받게 될 입력에서 고르는 편이 좋습니다.

직원이 내용을 다듬어 넣을 예정인지, 고객이 보낸 문서를 그대로 처리할 예정인지부터 확인합니다. 시험 때만 문장을 정리하거나 표를 풀어서 전달하면 실제 사용 조건과 달라집니다. 여기서 말하는 테스트 데이터는 AI 모델을 새로 학습시키는 자료가 아니라 업무에 맞게 작동하는지 확인할 입력 묶음입니다.

가령 문의를 분류하는 AI를 만든다고 가정해 보겠습니다.

제목과 요청 사항이 분명한 이메일만 고르면 짧은 채팅 문의나 여러 요청이 섞인 글을 제대로 분류하는지는 알기 어렵습니다.

이메일과 채팅을 구분하고, 글의 길이와 첨부파일 유무처럼 결과에 영향을 줄 만한 차이도 함께 적습니다. 구분 항목을 끝없이 늘리기보다 실제로 다른 처리가 필요한 조건부터 고릅니다.

자료를 수집할 때는 사용 가능한 범위를 함께 확인해야 합니다.

테스트 목적에 맞지 않는 개인정보나 내부 기밀은 제외하고, 바꿔야 하는 값이 있다면 바뀐 부분과 이유를 남깁니다. 내용을 가공하다가 분류에 필요한 단서까지 없애지는 않았는지도 살펴봅니다. 실제 자료를 못 쓰는 경우에는 형식을 본뜬 가상 자료임을 표시하고 현업 자료로 확인할 항목을 따로 남깁니다.

똑똑한개발자팀은 테스트 자료를 고를 때 현업 담당자가 평소 받는 입력과 비교하는 과정이 중요하다고 봅니다. 데이터가 사용자의 맥락을 대표하는지, 수집 과정에서 어떤 가정을 했는지 점검하는 방법은 Google PAIR의 데이터 수집·평가 가이드에서 더 자세히 보실 수 있습니다.

자주 들어오는 일과 놓치면 곤란한 일을 나눕니다

반복 업무의 성능을 확인하려면 자주 들어오는 유형이 충분히 포함돼야 합니다.

다만 빈도만 따라 자료를 고르면 드물게 생기는 중요한 예외가 빠질 수 있습니다. 평소 처리할 업무를 보는 자료 묶음과 예외를 집중해서 확인하는 묶음을 나누면, 각각 무엇을 확인했는지 설명하기가 수월합니다.

문의 분류 예시를 이어가면 일반 사용법 질문은 자주 들어오는 유형으로, 결제 취소와 계정 접근 문제가 한 문장에 섞인 문의는 별도 확인 대상으로 둘 수 있습니다. 이는 설명을 위한 가정이며 모든 서비스에서 같은 항목이 중요하다는 뜻은 아닙니다. 현업 담당자에게 드물어도 잘못 분류하면 후속 처리가 크게 달라지는 문의를 물어보면 후보를 찾는 데 도움이 됩니다.

수집한 유형을 표에 적을 때는 자료 수와 선정 이유를 함께 남깁니다.

빈 칸도 기록입니다. 특정 언어의 문의를 확보하지 못했다면 테스트에서 제외됐다는 사실을 결과 옆에 표시합니다. 담당자가 평소 업무에서 해당 유형이 얼마나 나오는지 모른다면 비중을 임의로 채우지 않고 확인이 필요한 항목으로 둡니다.

예외 자료를 의도적으로 많이 넣었다면 전체 성공률을 실제 운영 성능처럼 소개하지 않습니다. 일반 문의와 예외 문의의 결과를 구분해서 보고, 무엇이 부족했는지 해당 유형으로 돌아가 살핍니다. 똑똑한개발자팀은 이때 전체 점수를 높이는 일보다 아직 확인하지 못한 업무를 드러내는 일이 우선이라고 생각합니다. 그래야 적용 가능한 업무와 추가 시험이 필요한 업무를 구분할 근거를 갖출 수 있습니다.

개선에 쓴 자료와 최종 확인용 자료를 구분합니다

같은 자료를 보며 프롬프트를 고치다 보면 그 자료에 맞춘 답변이 좋아질 수 있습니다. 그렇다고 새로운 입력에서도 같은 결과가 나온다고 단정하기는 어렵습니다. 처음 자료를 모을 때 일부를 마지막 확인용으로 따로 보관하면 익숙하지 않은 입력에서도 작동하는지 살필 수 있습니다. 몇 건을 남길지는 업무 유형과 검토 여건에 맞춰 정합니다.

같은 문의를 복사하거나 표현만 조금 바꾼 자료가 양쪽에 들어가면 분리한 의미가 줄어듭니다.

원본이 같은 자료에는 같은 식별자를 남기고, 개선 과정에서 열어본 자료를 최종 확인용에 계속 포함하지 않도록 관리합니다. 마지막 시험의 오류를 보고 다시 수정했다면 다음 확인에서는 새 자료를 보충하는 방식도 정해둡니다.

자료를 나누는 것과 함께 담당자끼리 판정 기준을 합의합니다. 어떤 분류가 맞는지, 입력만으로 판단할 수 없으면 어떤 응답을 기대하는지 적습니다. 담당자끼리 정답이 갈리는 자료는 곧바로 AI의 오답으로 세지 않고 업무 규칙부터 확인합니다. 사람도 합의하지 못한 항목을 채점에 넣으면 결과의 의미를 설명하기 어렵기 때문입니다.

테스트가 끝나면 자료를 수집한 기간, 포함한 업무, 빠진 유형과 가공 여부를 짧게 붙입니다.

자료의 출처와 구성 조건을 기록합니다. 다음 담당자가 결과를 읽을 때 어떤 조건에서 확인한 성능인지 판단할 수 있도록 하기 위한 기록입니다. 자료를 새로 추가한 시험은 이전 시험과 입력 구성이 달라졌다는 점도 함께 알립니다.

업무 분석과 검증 범위를 함께 설계합니다

AI 테스트 자료를 정하는 과정에서는 현업의 입력 방식과 개발팀의 처리 조건을 함께 살펴야 합니다.

예외 자료가 부족한 이유가 수집 경로에 있는지, 업무 규칙이 아직 정해지지 않아서인지에 따라 다음 작업도 달라집니다. 확보한 자료와 빠진 조건을 먼저 정리하면 파일럿에서 확인할 범위를 구체적으로 논의할 수 있습니다.

똑똑한개발자는 업무 분석부터 AX 전략, PoC, 시스템 개발과 운영 개선까지 하나의 팀에서 진행합니다. 현업이 맡길 업무를 정하고 실제 시스템에 연결하는 과정을 함께 설계합니다. 파일럿에서 어떤 입력을 다룰지와 이후 확장 시 추가로 확인할 조건도 같은 업무 맥락에서 논의할 수 있습니다.

실제 업무에 맞는 AI 적용 범위와 검증 방식을 함께 설계하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요. 감사합니다. :)