한 줄 요약: 저는 AI 작업을 시작할 때 입력, 결과 검증, 중단 기준을 한 단계로 섞지 않습니다. 결과가 그럴듯해 보여도 입력이 불명확하거나 검증 근거가 부족하면 다음 단계로 넘기지 않습니다.
1. 입력: 시작 전에 범위를 먼저 고정한다
입력 단계에서는 목적, 사용할 자료, 공개하면 안 되는 정보, 완료 조건을 적습니다. 특히 공개 글이나 이미지라면 계정 화면, 내부 경로, 미검증 기능처럼 밖으로 나가면 안 되는 요소를 먼저 제외합니다.
2. 검증: 생성됐다는 사실과 맞다는 사실을 분리한다
파일이 만들어졌거나 화면에 표시됐다고 해서 검증이 끝난 것은 아닙니다. 저는 제목·본문·링크·이미지처럼 독자가 실제로 보게 되는 요소를 다시 읽고, 공개 가능한 기능과 아직 확인하지 못한 기능을 분리합니다.
3. 중단: 애매하면 진행하지 않는다
근거가 없거나, 공개 범위를 확신할 수 없거나, 화면에서 최종 상태를 확인하지 못했다면 완료로 쓰지 않습니다. 이 기준은 속도를 늦추기 위한 규칙이 아니라 같은 오류를 반복하지 않기 위한 장치입니다.
공식 문서는 “잘 됐다”의 기준을 어떻게 정하라고 하나
위의 세 지점은 제 작업 습관이지만, AI 회사들의 공식 개발자 문서도 비슷한 순서를 권합니다. Anthropic의 개발자 문서(테스트와 평가 항목)는 프롬프트를 고치기 전에 성공 기준과 평가를 먼저 정의하라고 안내합니다. 이 문서가 말하는 좋은 성공 기준은 네 가지 조건을 갖춥니다.
| 조건 | 문서의 설명 | 흐린 기준과 또렷한 기준 예 |
|---|---|---|
| 구체적(Specific) | “좋은 성능” 같은 말 대신 목표를 분명히 적습니다. | “좋은 성능” 대신 “감정 분류가 정확할 것” |
| 측정 가능(Measurable) | 숫자 지표를 쓰거나, 주관적 항목은 일관된 척도로 매깁니다. | 문서의 예: 1만 번 시도 중 유해성 판정이 0.1% 미만 |
| 달성 가능(Achievable) | 기존 벤치마크·선행 실험·전문가 지식에 근거하고 현재 모델의 한계 안에서 정합니다. | 사람도 판정하기 어려운 기준을 100%로 걸지 않음 |
| 관련성(Relevant) | 서비스의 목적에 맞춥니다. | 문서의 예: 의료 앱은 출처 정확도가 가벼운 챗봇보다 중요 |
같은 문서는 성공 기준으로 자주 쓰는 항목으로 과제 충실도, 일관성, 관련성과 일관된 흐름, 어조와 문체, 개인정보 보호, 맥락 활용, 지연 시간, 가격을 꼽고, 대부분의 사용 사례에서는 여러 항목을 함께 평가해야 한다고 설명합니다. 제 글의 “형식이 맞는 것과 내용이 맞는 것은 다르다”는 구분이 여기서는 “기준을 여러 개로 쪼개 평가한다”로 나타나는 셈입니다.
채점 방법은 세 갈래로 나뉩니다
Anthropic 문서가 예시로 드는 채점 방식은 코드로 자동 채점하는 방법, 사람이 직접 채점하는 방법, 다른 AI가 채점하는 방법입니다. 문서의 예시를 표로 옮기면 다음과 같습니다.
| 방식 | 문서의 예시 | 잘 맞는 상황 |
|---|---|---|
| 코드: 정확히 일치 | 라벨이 붙은 트윗 1,000건으로 감정 분류 확인 | 정답이 하나로 정해진 과제 |
| 코드: 임베딩 유사도 | 같은 뜻으로 바꿔 물은 FAQ 질문에 비슷한 답이 나오는지 확인 | 표현이 달라도 뜻이 같아야 하는 과제 |
| 코드: ROUGE-L | 기준 요약문과 겹치는 정도로 요약 평가 | 요약처럼 기준 글이 있는 과제 |
| AI 채점: 5단계 척도 | 고객 응대 어조를 1~5점으로 평가 | 공감·전문성 같은 주관적 항목 |
| AI 채점: 예·아니오 | 의료 챗봇 답변에 개인 건강정보가 새는지 확인 | 맥락을 봐야 하는 미묘한 위반 |
문서가 덧붙이는 요령도 제 기준과 겹칩니다. AI로 채점할 때는 결과를 만든 모델과 다른 모델을 채점자로 쓰는 편이 좋고, 채점자에게 “숫자만 출력”이나 “예 또는 아니오만 출력”처럼 형식을 제한해 결과를 읽기 쉽게 만들라고 합니다. 또 시험 문항에는 빈정거림, 섞인 감정, 오타, 장황한 질문, 오해를 부르는 제목처럼 어려운 경우를 일부러 넣으라고 합니다. 설계 원칙으로는 실제 과제의 분포를 닮게 만들 것, 자동 채점이 가능한 형식을 고를 것, 소수의 정교한 수작업 채점보다 다수의 자동 채점 문항을 우선할 것이 제시됩니다.
OpenAI 평가 가이드의 3단계와 비교하면
OpenAI의 평가(Evals) 가이드는 평가를 “신뢰할 수 있는 애플리케이션을 만드는 데 필수적인 요소”로 소개하고, 특히 모델을 올리거나 새 모델을 시험할 때 중요하다고 설명합니다. 절차는 세 단계입니다. 첫째, 과제를 평가로 기술해 기대하는 동작을 앱을 만들기 전에 정합니다. 둘째, 시험 입력으로 평가를 실행해 시험 자료의 각 행에 프롬프트를 적용합니다. 셋째, 결과를 분석하고 프롬프트를 고쳐 다시 실행합니다. 가이드의 용어로 “항목(item)”은 시험 자료의 한 행, “샘플(sample)”은 그 항목에 대해 모델이 만든 출력, “testing_criteria”는 통과 여부를 가르는 채점기를 뜻합니다.
한 가지 알아 둘 점이 있습니다. 가이드 본문에는 이 Evals 플랫폼이 폐지 수순에 있으며 2026년 10월 31일부터 기존 사용자에게 읽기 전용이 되고 2026년 11월 30일에 종료된다고 적혀 있고, 반복 작업에는 Datasets를 대안으로 안내합니다. 도구는 바뀌어도 “기대 동작을 먼저 적고, 시험 자료로 돌리고, 결과를 보고 고친다”는 절차 자체는 그대로 쓸 수 있습니다.
| 이 글의 세 지점 | 공식 문서에서 대응하는 개념 | 이 글에서 해당 개념을 쓰는 방식 |
|---|---|---|
| 입력 | 과제 기술, 시험 자료(OpenAI), 구체적·관련성 있는 기준(Anthropic) | 목적·자료·완료 조건을 시작 전에 적음 |
| 검증 | 채점기(testing_criteria), 코드·AI·사람 채점 | 항목별로 결과를 대조하고 숫자·고유명사를 따로 봄 |
| 중단 | 분석 후 반복, 달성 가능한 기준(Anthropic) | 같은 요청 세 번 반복 시 접근을 바꿈 |
위 대응표는 제가 두 문서의 개념을 이 글의 구조에 맞춰 연결한 것이며, 공식 문서가 “입력·검증·중단”이라는 이름으로 이렇게 묶었다는 뜻은 아닙니다.
작게 시작하는 점검 순서
- 완료 조건을 한 문장으로 씁니다. “잘 정리됨” 대신 “항목 다섯 개가 모두 있고 숫자가 원본과 같음”처럼 셀 수 있는 문장으로 적습니다.
- 어려운 사례를 2~3개 섞습니다. 오타가 있거나 정보가 빠진 입력처럼 일부러 까다로운 자료를 넣어 봅니다.
- 채점 방식을 고릅니다. 정답이 정해져 있으면 일치 여부로, 어조처럼 주관적이면 척도를 정해 사람이 일관되게 봅니다.
- 멈춤 조건을 먼저 적습니다. 몇 번 고쳐도 같은 곳이 틀리면 입력부터 다시 봅니다.
- 한 줄 기록을 남깁니다. 날짜, 사용한 자료의 종류, 달랐던 점 하나면 충분합니다.
이 글의 기준이 맞지 않는 경우
한 번 쓰고 버릴 가벼운 질문에는 이 모든 단계가 과합니다. 틀려도 되돌리기 쉬운 일, 결과를 내가 즉시 눈으로 확인할 수 있는 일이라면 입력을 조금 더 구체적으로 쓰는 정도로 충분합니다. 반대로 결과가 남에게 공개되거나, 금액·날짜·권한처럼 틀리면 곤란한 값이 들어가는 일이라면 세 지점을 따로 두는 쪽이 낫습니다.
확인 자료
기준일: 2026-10-18. 두 문서는 자주 바뀌므로 최신 내용은 원문을 우선하시기 바랍니다.
정리
입력이 명확한지, 결과가 맞는지, 지금 멈춰야 하는지를 따로 보면 AI 작업을 더 안전하게 이어갈 수 있습니다.