P6-1.1 검토해야 할 산출물로 보는 생성형 AI 출력¶
Section ID:
P6-1.1Version:v2026.07.23
Part 5에서는 생성 모델이 후보 분포를 만들고, 샘플링을 통해 실제 출력을 고른다는 감각을 잡았습니다. Part 6은 그 감각을 실제 생성형 AI 서비스 경험으로 옮겨 읽는 자리입니다.
생성형 AI(generative AI)는 범주 하나나 숫자 하나만 내놓는 모델과 다르게, 사용자가 읽고 검토하고 수정해야 하는 산출물을 만듭니다. 산출물은 문장, 코드, 이미지 설명, 음성 대본처럼 다양할 수 있지만, Part 6에서는 텍스트 생성형 AI를 대표 경로로 삼습니다.
| 사용 장면 | 모델이 내놓는 것 | 사용자가 해야 하는 일 |
|---|---|---|
| 이 글은 스팸인가? | 스팸, 정상 같은 분류 결과 | 기준에 맞게 분류됐는지 확인한다. |
| 다음 달 수요는 얼마인가? | 수치 예측값 | 오차 범위와 근거 데이터를 확인한다. |
| 고객에게 보낼 답장을 작성해 줘 | 문장 산출물 | 사실, 말투, 근거, 누락, 위험 표현을 함께 검토한다. |
이 차이가 중요합니다. 생성 결과는 그럴듯한 문장처럼 보여도 그대로 믿을 수 있는 결론이 아닙니다. 생성형 AI를 이해한다는 것은 모델이 산출물을 어떻게 만드는지만 보는 일이 아니라, 그 산출물을 어떤 기준으로 검토하고 보강해야 하는지까지 함께 보는 일입니다.
산출물은 한 가지 기준으로만 맞지 않는다¶
분류 결과와 수치 예측도 틀릴 수 있습니다. 다만 출력 형태가 비교적 좁습니다. 스팸인지 아닌지, 예측값이 실제와 얼마나 다른지처럼 확인할 기준을 먼저 세우기 쉽습니다. 생성형 AI 산출물은 다릅니다. 한 문장 안에 사실 설명, 약속, 정책 해석, 말투가 함께 들어갈 수 있어서 무엇을 확인해야 하는지부터 나누어 보아야 합니다.
예를 들어 배송이 늦어져 죄송합니다. 오늘 바로 다시 보내겠습니다.라는 답장이 만들어졌다고 해 봅시다. 문장은 자연스럽지만, 이 문장 안에는 아직 확인해야 할 항목이 남아 있습니다.
| 확인 항목 | 확인 질문 | 그대로 보내면 생길 수 있는 문제 |
|---|---|---|
| 사실 | 실제로 오늘 재발송할 수 있는가? | 약속을 지키지 못해 고객 불만이 커진다. |
| 권한 | 상담원이 재발송을 확정할 권한이 있는가? | 내부 승인 없이 보상 약속을 한 셈이 된다. |
| 누락 | 주문 번호, 배송사, 예상 도착일이 필요한가? | 고객이 다음 행동을 판단할 정보가 부족하다. |
| 말투 | 회사의 응대 기준과 맞는가? | 너무 단정적이거나 사과 범위가 넓어질 수 있다. |
그래서 생성형 AI의 산출물은 읽을 수 있는 문장이라는 이유만으로 충분하지 않습니다. 사용자는 산출물의 자연스러움과 별도로 사실, 권한, 누락, 위험 표현을 확인해야 합니다. 이후 Part 6에서 프롬프트, RAG, 도구 사용, 평가, 운영 기록을 다루는 이유도 여기에 있습니다. 생성 결과를 잘 쓰려면 생성 자체뿐 아니라 검토와 보강 구조를 함께 읽어야 합니다.
사례 및 예시¶
같은 고객 요청을 세 가지 모델 출력으로 바꾸어 보면 차이가 더 선명해집니다.
| 요청 | 출력 형태 | 검토 기준 |
|---|---|---|
이 문의가 환불 요청인가요? | 환불 요청 또는 일반 문의 | 라벨 기준과 예외 조건이 맞는지 확인한다. |
이 고객에게 환불 가능성이 얼마나 높나요? | 0.72 같은 점수 | 점수의 근거 데이터와 임계값을 확인한다. |
이 고객에게 보낼 답장을 써 주세요. | 여러 문장으로 된 답장 초안 | 사실, 정책, 권한, 누락, 말투를 함께 확인한다. |
세 출력은 모두 AI가 만든 결과지만, 독자가 읽어야 하는 방식이 다릅니다. 첫 번째는 기준에 맞는 라벨인지 보면 됩니다. 두 번째는 점수가 어떤 데이터와 기준에서 나왔는지 봅니다. 세 번째는 문장 전체를 읽으면서 여러 기준을 동시에 나누어야 합니다.
여기서 생성형 AI 산출물이 어렵게 느껴지는 이유가 드러납니다. 문장이 자연스러우면 사람은 이미 검토가 끝난 것처럼 느끼기 쉽습니다. 하지만 자연스러운 문장은 검토 결과가 아니라 검토 대상입니다. 문장 안에는 확인된 사실과 아직 확인되지 않은 추정, 모델이 그럴듯하게 이어 붙인 표현, 실제 실행 권한이 필요한 약속이 함께 섞일 수 있습니다.
바로 적용해 보면¶
다음 답장 초안을 세 기준으로 나누어 표시해 보세요.
안녕하세요. 주문하신 상품은 이미 재발송 처리되었고, 내일 오후에 도착할 예정입니다. 불편을 드려 죄송합니다.
| 문장 조각 | 먼저 붙일 검토 기준 | 확인 해설 |
|---|---|---|
이미 재발송 처리되었고 | 사실, 권한 | 실제 재발송 처리 기록이 있는지, 상담원이 이 상태를 확정해도 되는지 확인해야 한다. |
내일 오후에 도착할 예정입니다 | 사실, 근거 | 배송사 추적 정보가 없으면 단정하면 안 된다. |
불편을 드려 죄송합니다 | 말투, 정책 | 사과 표현 자체는 자연스럽지만 회사 응대 기준과 책임 범위에 맞는지 봐야 한다. |
이 작은 분류만 해도 생성 결과를 그대로 쓰기 어려운 이유가 보입니다. 출력이 문장일수록 검토 기준은 좁아지지 않고 넓어집니다.
연습 및 예제¶
다음 세 출력이 있을 때, 사용자가 추가로 확인해야 할 항목을 먼저 떠올려 보세요. 오른쪽 열은 확인 해설입니다.
| 출력 | 추가 확인 항목 |
|---|---|
정상 거래입니다. | 분류 기준과 예외 거래 조건 |
다음 주 판매량은 1,240개입니다. | 예측 오차 범위와 근거 데이터 기간 |
환불은 영업일 기준 3일 안에 처리됩니다. | 실제 환불 정책, 결제 수단별 차이, 고객 주문 상태 |
첫 번째와 두 번째 출력도 검토가 필요하지만, 생성형 AI 산출물은 검토 항목이 더 넓어집니다. 문장 안에 사실, 정책, 권한, 말투가 함께 섞이기 때문입니다.
이 절에서 남길 기준은 분명합니다. 생성형 AI의 출력은 정답 표시가 아니라 검토해야 할 산출물입니다. 그래서 Part 6은 생성 결과가 자연스러운지에서 멈추지 않고, 그 결과를 어떤 근거로 보강하고 어떤 기록으로 다시 확인할지까지 이어집니다.
체크리스트¶
- 생성형 AI의 출력이 분류 결과나 수치 예측과 어떻게 다른지 말할 수 있다.
- 생성 결과가 자연스럽게 보이더라도 검토가 필요한 이유를 설명할 수 있다.
- Part 6이 생성 산출물과 검토 문제에서 시작해야 하는 이유를 말할 수 있다.