‘다시 해줘’가 반복되면, 문제는 한 번의 답이 아닙니다

AI에게 메일 초안을 부탁했는데 날짜를 빼먹습니다. 고쳐 달라고 하면 이번에는 담당자를 바꿉니다. 회의록에서는 의견을 결정처럼 적어 놓습니다. 그때마다 프롬프트를 조금 더 길게 쓰게 되지만, 다음 주에 비슷한 일을 하면 같은 오류가 다시 나옵니다.

이럴 때 필요한 것은 더 화려한 프롬프트보다 ‘어떤 조건에서 무엇이 틀렸는지’를 남기는 작은 기록입니다. 좋은 프롬프트는 오늘의 결과를 개선할 수 있습니다. 반면 실패 기록은 바뀐 프롬프트, 모델, 자료를 다시 시험할 기준을 만들어 줍니다.

이건 개발자만의 ‘평가’ 이야기가 아닙니다

OpenAI가 안내하는 평가(evaluation)는 사람에 대한 인사평가가 아니라, AI가 내놓은 결과를 정해진 예시로 시험해 보는 일입니다. 같은 예시를 매번 같은 방식으로 넣어 보고, 결과가 기준에 맞는지 확인합니다. AI 모델(GPT·클로드처럼 서로 다른 AI)은 같은 입력에도 결과가 달라질 수 있으므로, 실제 업무의 예시를 모아 두고 자주 비교하라는 취지입니다. 물론 모든 직장인이 개발 도구나 복잡한 테스트 환경을 만들 필요는 없습니다.

일상 업무에서는 스프레드시트 한 장이면 충분합니다. AI가 자주 틀리는 장면을 한 행씩 적어 두었다가, 프롬프트를 바꾸거나 다른 모델을 쓸 때 다시 넣어보면 됩니다. 이 작은 목록이 나만의 ‘골든 세트(golden set)’가 됩니다. 성능을 비교할 때 기준으로 삼는 표준 예시 묶음을 업계에서 그렇게 부릅니다.

실패 기록은 이렇게 시작하면 됩니다

1. 반복되는 업무 하나만 고릅니다. 매주 보내는 메일, 회의록, 보고서 요약처럼 자주 하는 일이어야 합니다.

2. 실제 실패 사례 3~5개를 남깁니다. 개인정보나 회사 기밀은 지우고, 문제가 된 부분과 기대한 결과를 짧게 씁니다.

3. ‘금지할 행동’을 한 줄로 적습니다. 예를 들어 “확인되지 않은 날짜를 만들지 말 것”처럼 명확하게 적습니다.

4. 프롬프트나 모델을 바꾼 뒤 같은 사례로 다시 확인합니다. 한 번 잘 나온 사례보다, 이전에 실패한 사례를 통과하는지가 더 중요합니다.

이 방식은 정답을 자동으로 보장하지 않습니다. 대신 ‘이번에는 좋아 보인다’는 감으로 판단하는 일을 줄여 줍니다. 특히 숫자, 일정, 담당자, 외부 약속처럼 실수 비용이 큰 항목에서는 효과가 큽니다.

기록해야 할 것은 모든 실패가 아닙니다

문장 취향처럼 사람마다 다른 문제까지 전부 목록으로 만들 필요는 없습니다. 반복되고, 비용이 크고, 기대 결과를 비교적 분명하게 적을 수 있는 실패부터 잡으면 됩니다. 한 번만 일어났고 쉽게 고칠 수 있는 실수는 지나가도 괜찮습니다. 반대로 드물게 나오는 예외 상황이라도, 한 번 크게 잘못되면 되돌리기 어려운 일이라면 기록해 둘 값어치가 있습니다.

또 하나 중요한 점은, 이 기록을 AI에게 책임을 떠넘기는 장부로 만들지 않는 것입니다. 기록의 목적은 누가 틀렸는지 가리는 것이 아니라, 다음번 사람이 덜 확인해도 되게 만드는 데 있습니다.

잘 쓴 프롬프트보다, 다시 확인할 수 있는 기준

AI는 계속 바뀝니다. 쓰는 AI도, AI에게 참고하라고 넣어 주는 자료도, 우리가 던지는 질문도 달라집니다. 그래서 한 번 완성한 프롬프트를 ‘정답’으로 보관하기보다, 자주 틀렸던 사례와 확인 기준을 함께 보관하는 편이 오래 갑니다.

내일부터는 AI 결과가 마음에 들지 않을 때 “다시 해줘”만 입력하지 말고, 딱 한 줄만 남겨 보세요. “거래처 메일에서 날짜를 추정했다. 원문에 없는 수치는 비워 둘 것.” 그 한 줄이 다음번 수정 피로를 줄이는 시작이 될 수 있습니다.

출처 및 참고
• OpenAI, Evaluation best practices(영문·개발자용 문서) — 평가를 조기에·반복적으로 수행하고, 업무별 사례를 기록·확장하라는 공식 가이드
• OpenAI, Getting started with datasets (영문·개발자용 문서) 평가에 쓸 예시 묶음을 만들고, 예외 상황을 발견할 때마다 늘려 가라는 안내