사진, 통화 녹음, 신청서 PDF를 함께 보고 “승인할 수 있는가”, “어느 유형으로 분류할 것인가”, “담당자에게 넘겨야 하는가”를 판단해야 하는 업무가 있다. 기존에는 문서에서 값을 추출한 뒤 규칙을 적용하거나, 개별 모델을 조합해 분류하는 방식을 썼을 수 있다.
Gemini Decisions API는 이런 닫힌 선택 문제를 겨냥한 API다. 텍스트, 이미지, 음성, 영상, PDF를 하나의 입력으로 받고, 예·아니오, 선택지, 순서가 있는 점수 평가를 한 요청에서 처리하도록 설계됐다. 최대 1,000개의 독립 질문을 넣을 수 있고, 각 답에는 확률과 신뢰도 점수가 포함된다.
그러나 도입 판단의 출발점은 지원 형식이 많다는 사실이 아니다. 우리 업무에서 같은 자료가 들어왔을 때 같은 기준으로 판정되는지, 틀릴 수 있는 건을 안전하게 멈출 수 있는지, 그리고 그 운영 비용이 현재 체계보다 낮아지는지를 확인해야 한다.
비교 대상은 모델 기능이 아니라 현재의 판정 흐름이다
기존 시스템은 대개 세 부류가 섞여 있다.
첫째는 명시적 규칙이다. 예를 들어 필수 서류가 없으면 보류하고, 특정 값이 기준을 넘으면 담당자 검토로 보내는 방식이다. 규칙은 왜 그런 결과가 나왔는지 설명하기 쉽고, 바꾸려는 조건도 비교적 분명하다. 반면 문서 양식이 달라지거나 사진·음성처럼 정형화되지 않은 자료가 들어오면, 입력을 먼저 구조화해야 한다.
둘째는 단일 목적 분류 모델이다. 특정 이미지 유형, 문서 항목, 음성 구간 등을 분류하도록 만든 모델이 여기에 해당한다. 판정 대상이 좁고 입력 형식이 안정적이면 비교가 수월하다. 다만 여러 자료를 함께 읽고 업무 문맥까지 반영해야 하면, 결과를 합치는 규칙과 예외 처리가 별도로 늘어날 수 있다.
셋째는 생성형 모델에 지시문을 보내고 답변 텍스트를 해석하는 방식이다. 복잡한 맥락을 다루기에는 유연할 수 있지만, 후속 시스템이 텍스트 답변을 다시 파싱해야 하거나 응답 형식이 흔들릴 때 운영 부담이 생긴다.
Gemini Decisions API는 세 번째 방식과 달리 닫힌 선택지의 점수와 확률을 반환하는 데 초점을 둔다. 제품 설명상 후보 선택지를 토큰 단위로 문장 생성하지 않고 점수화하며, 출력 토큰은 과금하지 않는다고 안내한다. 따라서 비교할 질문은 “생성형 AI를 쓸 수 있는가”가 아니라 “현재의 추출, 규칙, 분류, 검토 대기열을 이 API의 질문 구조로 줄일 수 있는가”여야 한다.
품질은 정답률 하나가 아니라 세 가지로 나눠 봐야 한다
요구사항 단계에서 가장 먼저 정할 것은 업무 판정의 단위다. 예를 들어 “이 신청은 승인 가능한가”라는 큰 질문 하나만 두면, 오류 원인을 찾기 어렵다. 대신 필수 자료 존재, 특정 조건 충족, 예외 사유, 다음 처리 경로처럼 후속 행동과 연결되는 질문으로 나눠야 한다.
이때 아래 세 축을 분리해 비교하는 편이 좋다.
| 비교 축 | 확인할 질문 | 기존 규칙·분류 시스템이 유리할 수 있는 조건 | Decisions API를 검토할 조건 |
|---|---|---|---|
| 판정 일관성 | 동일하거나 유사한 입력에서 결과와 처리 경로가 안정적인가 | 기준값과 예외가 명확히 문서화돼 있고 입력이 구조화돼 있을 때 | 여러 형식의 자료를 함께 해석해야 하고, 기존 시스템의 결합 규칙이 복잡할 때 |
| 검증 가능성 | 오류가 났을 때 어느 질문과 어떤 기준이 문제였는지 찾을 수 있는가 | 규칙별 로그와 변경 이력이 이미 충분할 때 | 질문, 선택지, 루브릭을 업무 기준으로 명시하고 결과를 항목별로 기록할 수 있을 때 |
| 보류 처리 | 확신이 낮은 건을 자동 처리에서 뺄 수 있는가 | 위험 조건을 규칙으로 명확히 포착할 수 있을 때 | 답변별 확률을 사용해 검토 대기열을 나눌 수 있을 때 |
| 운영 비용 | 모델 호출 외에 검토, 오류 수정, 기준 변경에 드는 시간이 줄어드는가 | 규칙 변경이 적고 유지 인력이 확보돼 있을 때 | 여러 모델 호출과 결과 통합 단계를 한 요청으로 대체할 가능성이 있을 때 |
특히 신뢰도 점수는 자동 승인 근거가 아니라 검증 대상이다. 선택적 분류에 관한 연구에서도 높은 신뢰도를 보인 오답이나 낮은 신뢰도의 정답이 발생할 수 있으며, 불확실성 추정 자체가 입력 분포에 따라 믿기 어려울 수 있다고 설명한다. 따라서 “신뢰도 0.9 이상이면 자동 처리” 같은 기준을 계약서처럼 먼저 고정하기보다, 과거 자료와 새로 수집한 검토 자료에서 신뢰도 구간별 오판 비율을 확인해야 한다.
업무상 손실이 큰 오류와 담당자가 쉽게 되돌릴 수 있는 오류도 분리해야 한다. 두 오류의 비용이 다르면 같은 신뢰도 임계값을 쓸 이유가 없다. 이 구분은 모델의 정확도 논쟁보다 제품 요구사항에 더 직접적인 영향을 준다.
멀티모달 입력이 이점이 되는 업무와 비용만 늘리는 업무
Gemini Decisions API의 특징 가운데 하나는 여러 형식의 자료를 같은 입력으로 평가할 수 있다는 점이다. 예를 들어 사진과 텍스트 메모, 통화 녹음과 계정 정보, 스캔 문서와 사진을 함께 판단하는 흐름을 구성할 수 있다. 이미지와 영상의 해상도를 조정해 시각 세부 정보와 토큰 비용을 조절하는 기능도 안내돼 있다.
이 기능이 유리한 경우는 판단 근거가 여러 자료에 나뉘어 있고, 사람이 원래 그 자료들을 함께 보는 업무다. 사진만 보고 결론을 내리면 안 되고 문서의 조건이나 음성 설명을 함께 확인해야 하는 경우가 여기에 가깝다.
반대로 입력 중 하나가 판정에 거의 영향을 주지 않거나, 이미 안정적으로 구조화돼 있는 정보를 다시 원본 파일로 넣는다면 비용과 검증 범위만 커질 수 있다. PDF 전체를 보내는 대신 이미 추출된 필수 필드만 쓰는 편이 더 적절한 업무도 있을 수 있다. API가 최대 256K 토큰의 컨텍스트를 받을 수 있다는 기능 설명은, 항상 큰 입력을 보내야 한다는 권고가 아니다.
요구사항 문서에는 각 질문마다 다음을 적어 두는 편이 좋다.
- 판정에 필요한 입력은 무엇인가. 원본 이미지, 발췌 문장, 메타데이터 중 무엇을 써야 하는가.
- 사람이 판단할 때 보는 근거는 무엇인가. 그 근거가 질문 지시문과 선택지 기준에 반영됐는가.
- 자동 처리해도 되는 결과는 무엇인가. 보류 또는 담당자 검토로 보내야 하는 조건은 무엇인가.
- 결과가 바뀌었을 때 누가 확인하는가. 질문 기준 변경과 모델 변경을 어떤 기록으로 구분할 것인가.
이 네 항목이 비어 있으면, 멀티모달 기능은 판정 품질을 높이는 장치가 아니라 “많은 자료를 넣어 본 실험”으로 남기 쉽다.
비용 비교는 API 단가가 아니라 건당 처리 경로로 계산한다
Google은 Gemini Decision 1의 입력 비용을 100만 입력 토큰당 0.10달러로 안내하며, 출력 토큰은 과금하지 않는다고 설명한다. 또한 1회 요청에서 다수의 독립 질문을 함께 평가할 수 있고, 모델 연산 기준 지연 시간은 중앙값 50~100ms, 종단 간 지연 시간은 150~250ms라고 제시한다. 이 수치는 제품이 제시한 조건의 성능·가격 정보이며, 개별 업무 환경의 처리 시간이나 총비용을 보장하지는 않는다.
제품 관리자가 비교해야 할 비용은 호출 단가만이 아니다. 다음 항목을 같은 업무 건에 붙여 비교해야 한다.
- 입력 준비 비용: 파일을 수집하고, 필요한 자료만 고르고, 메타데이터를 결합하는 작업
- 판정 호출 비용: 입력량과 질문 수를 포함한 API 비용
- 보류 건 처리 비용: 낮은 신뢰도나 충돌 결과를 사람이 다시 보는 시간
- 오류 정정 비용: 잘못 처리된 결과를 되돌리고 고객·현업에 설명하는 작업
- 기준 변경 비용: 업무 정책이 바뀔 때 규칙, 질문, 선택지, 검토 절차를 바꾸는 작업
여기서 Decisions API가 이득을 낼 가능성은 여러 질문이 같은 입력을 공유할 때다. 반대로 질문마다 다른 파일을 따로 준비해야 하거나, 결과를 받은 뒤 기존 규칙 엔진에서 다시 대부분을 판정한다면 한 요청에 질문을 묶는 장점이 줄어든다.
초기 비교에서는 전체 업무를 바꾸기보다, 결과가 이미 검토된 사례를 골라 같은 판정 질문을 기존 체계와 API에 각각 적용하는 방식이 적합하다. 이때 승인률만 비교하지 말고, 자동 처리된 건 중 재검토가 필요했던 비율, 보류 건의 양, 담당자가 결과를 이해하고 수정하는 데 걸린 과정까지 함께 기록해야 한다.
도입 결정을 위한 최소 검증 순서
첫 단계에서는 한 업무 흐름을 고른다. 여러 부서의 판정을 한꺼번에 묶기보다, 입력 형식과 최종 행동이 비교적 명확한 흐름이 좋다. 그 다음 현재 시스템의 판정 결과와 담당자 최종 결론이 남아 있는 자료를 분리해 검증용으로 준비한다.
둘째, 질문을 업무 규칙처럼 쓴다. 예·아니오 질문에는 참과 거짓의 기준을, 선택형 질문에는 각 선택지가 성립하는 조건을, 점수형 질문에는 각 단계의 의미를 적는다. “적절한지 판단하라”처럼 포괄적인 문장은 나중에 결과 차이를 해석하기 어렵게 만든다.
셋째, 신뢰도 점수에 따라 어떤 결과를 자동 처리하고 어떤 결과를 보류할지 시험한다. 이때 목표는 보류율을 무조건 낮추는 것이 아니다. 사람이 봐야 할 위험한 건을 놓치지 않으면서, 반복 검토를 얼마나 줄일 수 있는지 확인하는 데 있다.
마지막으로 기준 변경 시나리오를 넣어 본다. 업무 정책, 문서 양식, 선택지 정의가 바뀌었을 때 누가 질문을 수정하고, 이전 결과와 어떻게 비교하며, 문제가 생기면 어느 처리 단계로 되돌릴지 정리한다. 이 과정에서 기존 규칙 시스템이 더 빠르고 설명 가능한 경우도 드러날 수 있다.
Gemini Decisions API는 멀티모달 자료를 닫힌 선택 문제로 다룰 수 있는 후보지만, 그것만으로 기존 체계를 대체할 근거가 되지는 않는다. 먼저 자동화하려는 판정을 작고 검증 가능한 질문으로 쪼개고, 기존 방식과 같은 자료·같은 처리 기준에서 보류율과 재검토 비용까지 비교해 보아야 한다. 그 비교가 가능해진 뒤에야 API 도입은 기능 실험이 아니라 제품 의사결정이 된다.
