회의에서 보여 준 AI 데모는 대부분 잘 돌아가요. 준비한 질문, 정리된 자료, 익숙한 사람이 쓰니까요. 그런데 실제 사용자가 들어오면 오타 섞인 질문, 엉뚱한 파일, 생각보다 긴 대화가 쏟아져요. 같은 기능이 데모에서는 매끄럽고 서비스에서는 흔들리는 이유가 여기에 있어요.
이 글은 AI 기능을 실제 서비스에 붙이기 전에 개발팀과 기획자가 함께 정해 두면 좋은 다섯 가지를, Anthropic과 OpenAI의 공식 평가 가이드를 참고해 정리한 체크리스트예요.
1. "잘 된다"의 기준을 먼저 글로 적기
데모를 본 사람마다 "잘 된다"의 뜻이 달라요. 출시 전에 이 기능이 무엇을 해내면 성공인지 문장으로 정해 두세요. OpenAI 평가 가이드도 첫 단계를 목표와 성공 기준 정의로 둬요.
- 답변이 사내 규정 문서에 있는 내용만 근거로 하는가
- 요약이 원문에 없는 숫자를 만들어 내지 않는가
- 정해진 형식(표 · 3줄 요약 등)을 지키는가
2. 테스트 질문을 "많이", 그리고 이상한 것까지
Anthropic 문서는 실제 업무 분포를 닮은 테스트를 만들고, 엣지 케이스(드물지만 꼭 나오는 예외 상황)를 빠뜨리지 말라고 강조해요. 손으로 정성껏 고른 질문 몇 개보다, 자동으로 채점할 수 있는 질문을 많이 두는 편이 낫다고도 해요.
| 넣어 둘 질문 | 예시 |
|---|---|
| 평범한 질문 | 자주 들어오는 문의 그대로 |
| 오타 · 줄임말 | "환불규정머야" |
| 긴 질문 | 배경 설명이 길게 붙은 문의 |
| 답이 없어야 하는 질문 | 자료에 없는 내용을 묻는 경우 |
3. 실패했을 때의 화면부터 설계하기
AI 응답은 늦어질 수도, 형식이 깨질 수도, 아예 실패할 수도 있어요. 그때 사용자가 무엇을 보게 될지 미리 정해 두세요.
- 응답이 일정 시간 안에 오지 않으면 안내 문구와 다시 시도 버튼
- 형식이 깨진 응답은 화면에 그대로 보여 주지 않고 한 번 더 요청
- 끝내 실패하면 사람 담당자나 기존 기능으로 넘어가는 길
4. 무엇을 남길지 정하기: 로그와 피드백
출시 뒤에 품질을 올리려면 어떤 질문에 어떤 답이 나갔는지 볼 수 있어야 해요. OpenAI 가이드도 실제 사용 데이터를 테스트 세트에 계속 더하며 지속적으로 평가하라고 권해요. 다만 개인정보가 섞일 수 있으니, 저장 범위와 보관 기간을 함께 정해야 해요.
- 질문 · 답변 · 사용한 모델 · 응답 시간
- 사용자의 좋아요 / 별로예요 버튼 결과
- 개인정보는 가리거나 저장하지 않기
5. 비용 상한과 입력 자료 기준
AI API는 쓴 만큼 비용이 나와요. 사용자 한 명이 하루에 몇 번까지 쓸 수 있는지, 한 번에 얼마나 긴 문서를 넣을 수 있는지 상한을 정해 두면 예상 못 한 청구서를 막을 수 있어요. 비용 계산 방법은 다음 글(LLM API 비용 어림하기)에서 따로 다뤄요.
입력 자료 기준도 같이 정하세요. 어떤 문서를 AI에 넣어도 되는지, 고객 정보는 어떻게 가릴지 정해 두면 기능을 넓힐 때마다 다시 논의하지 않아도 돼요.
데모는 가능성을 보여 주고, 이 다섯 가지는 그 가능성을 매일 쓰는 기능으로 바꿔 줘요. 출시 일정에 쫓길수록 이 목록부터 한 번 훑어보세요.
참고
- Anthropic, Create strong empirical evaluations: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests
- OpenAI, Evaluation best practices: https://developers.openai.com/api/docs/guides/evaluation-best-practices
웹 · 앱 · 업무 시스템을 만들고 그 위에 필요한 AI를 붙여 운영하는 팀이에요. 회의록 · 계약서 · 기업 분석 AI를 직접 만들어 운영해요.
만든 프로젝트 보기