AI 기능을 제품에 적용할 때 확인할 것

시연에서 한 번 잘 동작한 결과와 실제 서비스에서 계속 쓰는 기능은 기준이 다릅니다. 실제 사용에서는 예상 밖의 입력이 들어옵니다. 외부 모델이 늦거나 응답하지 않을 수도 있습니다. 비용이 늘거나 결과를 그대로 쓸 수 없는 상황도 생깁니다. 따라서 모델을 고르기 전에 기능의 역할과 멈춰야 할 지점을 먼저 정해야 합니다.

역할과 중단 조건부터 정합니다

문서를 요약한다만으로는 기능 범위를 정할 수 없습니다. 어떤 문서를 다루고 누가 결과를 쓰는지 먼저 적습니다. 금액이나 날짜처럼 바뀌면 안 되는 정보도 정합니다.

초안을 제안하는 기능과 시스템 상태를 바꾸는 기능은 위험이 다릅니다. 모델이 직접 실행할 수 있는 범위는 좁게 둡니다. 영향이 큰 행위는 사람의 확인을 거칩니다.

입력은 필요한 만큼만 보냅니다

입력은 기능에 필요한 항목과 필요하지 않은 항목으로 나눕니다. 개인정보와 비밀정보는 목적이 없다면 보내지 않습니다. 식별자를 대체할 수 있는지 검토하고 원문 전체 대신 필요한 구간만 보낼 수 있는지도 살핍니다.

이 기준은 문서에만 두지 않습니다. 전송 직전 필터와 허용 데이터 목록에 반영합니다. 운영 로그에 남기지 않을 값도 같은 곳에서 정합니다.

실패 사례로 평가 기준을 만듭니다

데모 입력 몇 개로 품질을 판단하면 실제 오류를 놓칩니다. 자주 들어오는 입력뿐 아니라 빈 값과 모호한 요청도 평가 사례에 넣습니다. 서로 충돌하는 지시와 긴 문장도 포함합니다.

문서 요약이라면 금액이나 날짜를 바꾸는 오류를 먼저 막아야 합니다. 분류 기능이라면 잘못된 자동 실행이 보류보다 위험할 수 있습니다. 평균 점수보다 허용할 수 없는 오류를 먼저 정합니다.

사람의 검토가 실제 흐름에 있어야 합니다

사람이 본다고 적는 것만으로는 검토가 작동하지 않습니다. 누가 언제 결과를 보고 무엇을 수정할 수 있는지 화면과 상태에 나타나야 합니다. 거절 뒤에 어디로 돌아가는지도 정합니다.

수정 내역을 개선에 다시 쓸 때는 목적을 따로 정합니다. 개인정보 처리 범위와 보관 기간도 다시 확인합니다.

지연과 비용은 기능의 조건입니다

외부 모델은 느려지거나 실패할 수 있습니다. 시간 초과·사용 한도 초과·정책 거절은 각각 원인이 다릅니다. 다시 시도할 조건과 바로 멈출 조건을 나눕니다.

같은 요청을 여러 번 받아도 결과가 한 번만 반영되도록 요청 식별자를 둡니다. 기능을 잠시 끄고 수동 처리로 전환할 수 있는지도 정합니다. 사용자가 기다리거나 나중에 확인하는 경로도 필요합니다.

기록은 원문보다 결정을 남깁니다

관찰 항목은 품질과 비용뿐 아니라 지연까지 설명해야 합니다. 호출량과 응답 시간만 보면 사용자가 반복해서 수정한 결과를 놓칠 수 있습니다. 반대로 원문을 그대로 로그에 남기면 불필요한 개인정보가 쌓일 수 있습니다.

모델과 프롬프트의 버전을 남기고 평가 세트도 같은 변경 기록에 묶습니다. 문제가 생기면 어느 변경에서 시작됐는지 확인할 수 있습니다.

출시 전 확인할 증거를 모읍니다

출시는 이름난 모델을 붙였다는 사실로 결정하지 않습니다. 평가 결과를 확인하고 중단 조건과 복구 경로가 실제로 작동하는지 점검합니다. 비용 한도와 담당자를 정하고 변경 기록도 남깁니다.

이 증거가 모여야 데모 결과를 실제 제품 기능으로 다룰 수 있습니다.