메인 콘텐츠로 건너뛰기
팀이 문서를 수동으로 검토하는 데 시간을 소비하고 있다면(필드 확인, 데이터 검증, 이름 심사 등) Omni가 그 작업의 상당 부분을 자동화할 수 있습니다. 이 가이드는 기존 표준 운영 절차(SOP)를 Omni 워크플로우로 전환하는 방법을 안내합니다.

자동화 기회 파악

모든 프로세스가 자동화에 적합한 것은 아닙니다. 수동 검토 프로세스가 Omni에 적합한지 확인할 수 있는 신호를 살펴보세요:
신호중요한 이유
반복적인 확인 작업동일한 검증 단계가 모든 문서에 적용됩니다
일관된 기준승인/거부 결정이 주관적 판단이 아닌 정의된 규칙을 따릅니다
대량 처리팀이 하루/주에 수십 또는 수백 건의 문서를 처리합니다
인적 오류 위험피로나 일관성 부족으로 문제를 놓칠 수 있습니다
구조화된 입력문서가 예측 가능한 형식을 따릅니다 (인보이스, 등록 증명서, 서식 등)

Omni로 자동화할 수 있는 일반적인 프로세스

  • 인보이스 검증 — 금액, 날짜, 벤더 정보, 항목별 합계 확인
  • 벤더 온보딩 — 사업자등록 문서 검증 및 AML 감시 목록 심사
  • 컴플라이언스 서식 검토 — 필수 필드가 존재하고 유효한지 확인
  • 사업자등록 검증 — 기업 정보 추출 및 교차 확인
  • 계약서 검토 — 주요 조건, 날짜, 당사자 정보 확인
  • 직원 문서 확인 — 제출된 자격증, 라이선스 또는 신분증 검증
Omni는 명확하고 문서화 가능한 규칙이 있는 프로세스에서 가장 잘 작동합니다. 검토 프로세스가 주관적 판단이나 문서화할 수 없는 기관 지식에 크게 의존하는 경우, 완전 자동화보다는 부분 자동화가 필요할 수 있습니다.

SOP를 Omni 워크플로우에 매핑하기

다음 다섯 단계를 따라 수동 프로세스를 Omni 워크플로우로 전환하세요.
1

현재 수동 프로세스 문서화

Omni에서 무엇이든 구축하기 전에, 팀이 현재 검토를 어떻게 처리하는지 정확히 기록하세요:
  • 누가 검토를 수행합니까?
  • 어떤 문서를 수신합니까?
  • 각 문서에서 무엇을 확인합니까?
  • 어떤 결정을 내립니까 (승인, 거부, 에스컬레이션)?
  • 검토 후 결과는 어디로 전달됩니까?
이것이 기준선이 됩니다. 이 각 항목을 Omni 구성으로 변환하게 됩니다.
2

입력 문서 식별

검토를 위해 제출되는 모든 문서 유형을 나열하세요. 구체적으로 작성합니다:
  • PDF 인보이스인가요? 스캔된 사업자등록증인가요? 스프레드시트인가요?
  • 케이스당 여러 문서가 있나요, 아니면 하나뿐인가요?
  • 문서 간 교차 참조가 필요한가요?
Omni는 JPG, PNG, PDF, TXT, DOC, DOCX, XLS, XLSX, BMP, TIFF, WEBP, CSV, HTML, MD를 지원합니다. 폴더당 최대 5개 항목까지 가능합니다. 단일 케이스에 5개 이상의 문서가 포함된 경우, 동일한 프로필 내에서 관련 문서를 여러 폴더로 그룹화하세요.
3

승인/거부 기준 정의

팀이 수행하는 각 확인 항목에 대해 정확한 기준을 작성하세요:
  • 문서가 승인되려면 무엇이 필요한가요? (예: “모든 필수 필드가 존재하고 합계가 항목과 일치”)
  • 문서가 거부되는 조건은 무엇인가요? (예: “인보이스 날짜가 미래” 또는 “사업자등록이 만료됨”)
  • 시니어 리뷰어에게 에스컬레이션되는 조건은 무엇인가요? (예: “AML 심사에서 일치 항목 발견” 또는 “핵심 필드를 읽을 수 없음”)
이러한 기준이 Omni 정책의 결정 로직이 됩니다.
4

자연어 정책으로 작성

이전 단계의 확인 항목과 기준을 구조화된 정책 문으로 결합합니다. 번호가 매겨진 단계와 명시적인 언어를 사용하세요.템플릿:
Review the submitted [document type] by performing the following checks:
1. Extract [list of fields] from the document
2. Verify that [specific condition]
3. Check that [another condition]
4. [Additional verification steps]

Decision criteria:
- APPROVE if all checks pass and all required fields are present
- REJECT if [specific failure conditions]
- FLAG for manual review if [ambiguous conditions]
자세한 예시와 모범 사례는 정책 작성 가이드를 참조하세요.
5

추출이 필요한 데이터 정의

각 검토에서 다운스트림 시스템에 필요한 구조화된 데이터를 결정합니다. 이것이 출력 스키마가 됩니다.자문해 보세요:
  • 백엔드 시스템이 어떤 필드를 기대하나요?
  • 추출된 원시 값이 필요한가요, 아니면 승인/거부 결과만 필요한가요?
  • 출력에 결정 사유를 포함해야 하나요?
이러한 요구 사항에 정확히 맞도록 JSON 출력 스키마를 설계하세요.

실제 사례

다음 예시는 수동 검토 프로세스가 Omni 워크플로우로 어떻게 전환되는지 보여줍니다.

예시 1: 인보이스 검토

재무팀 구성원이 각 인보이스 PDF를 열고 수동으로 확인합니다:
  • 벤더명과 인보이스 번호가 존재하는지
  • 인보이스 날짜가 적절한지 (미래가 아니고 90일을 초과하지 않는지)
  • 항목별 금액이 명시된 합계와 일치하는지
  • 세금 계산이 정확한지
  • 시스템에 중복된 인보이스 번호가 없는지
인보이스당 소요 시간: 5-10분. 오류율: ~3% (계산 오류 누락, 중복 간과).
정책:
Verify the submitted invoice document by:
1. Extracting vendor name, invoice number, invoice date, line items, subtotal, tax, and total amount
2. Verifying all required fields are present and non-empty
3. Validating that the invoice date is not in the future and not older than 90 days
4. Checking that the sum of line item amounts equals the stated subtotal
5. Verifying that tax is calculated correctly based on the subtotal
6. Approve if all checks pass; reject if amounts do not match or required fields are missing; flag for manual review if date is borderline
엔진: Text Verifier - Glove (모든 필드 추출 및 검증)출력 스키마:
{
  "invoice": {
    "vendorName": "string",
    "invoiceNumber": "string",
    "invoiceDate": "string",
    "lineItems": ["string"],
    "subtotal": "number",
    "tax": "number",
    "totalAmount": "number"
  },
  "validation": {
    "allFieldsPresent": "boolean",
    "dateValid": "boolean",
    "amountsMatch": "boolean",
    "taxCorrect": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "pending_review | approved | rejected",
    "reasons": ["string"]
  }
}
결과: 검토 시간이 단순한 인보이스의 경우 5-10분에서 수 초로 단축됩니다. 팀은 플래그된 케이스만 수동으로 처리합니다.

예시 2: 벤더 온보딩

새 벤더가 온보딩될 때 컴플라이언스 담당자가:
  • 사업자등록증에서 회사명, 등록번호, 설립일을 검토합니다
  • 대표자의 신분증을 확인합니다
  • AML/제재 데이터베이스에서 대표자 이름을 수동으로 검색합니다
  • 문서 간 기업 정보를 교차 확인합니다
  • 결과를 스프레드시트에 기록합니다
벤더당 소요 시간: 20-30분. 병목: AML 검색이 느리고 수동 조회에서 오류가 발생하기 쉽습니다.
정책:
Verify vendor onboarding documents by:
1. Extracting company name, registration number, incorporation date, and representative name from the business registration certificate
2. Screening the representative's name against AML/sanctions watchlists
3. Cross-validating the representative name between the business registration and any submitted identity documents
4. Checking that the business registration is not expired
5. Approve if no AML matches found, all fields are consistent, and registration is valid; reject if AML screening returns a high-risk match; flag for manual review if AML returns a partial match or fields are inconsistent
엔진: Text Verifier - Glove + AML Search - Person출력 스키마:
{
  "company": {
    "name": "string",
    "registrationNumber": "string",
    "incorporationDate": "string",
    "representativeName": "string"
  },
  "amlScreening": {
    "screened": "boolean",
    "matchFound": "boolean",
    "riskLevel": "string",
    "matchDetails": "string"
  },
  "validation": {
    "fieldsConsistent": "boolean",
    "registrationValid": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "pending_review | approved | rejected",
    "reasons": ["string"]
  }
}
결과: AML 심사가 자동화되어 즉시 처리됩니다. 문제없는 케이스는 자동 승인됩니다. 컴플라이언스 담당자는 플래그된 벤더에만 집중합니다.

예시 3: 컴플라이언스 문서 확인

컴플라이언스 팀이 제출된 규제 문서를 검토합니다:
  • 모든 필수 섹션이 존재하는지 확인합니다 (헤더, 서명, 날짜, 라이선스 번호)
  • 만료일이 미래인지 확인합니다
  • 문서가 올바른 기관에 발행되었는지 확인합니다
  • 참조 번호가 내부 기록과 일치하는지 검증합니다
문서당 소요 시간: 10-15분. 위험: 대량 처리 기간에 만료된 문서가 간혹 통과됩니다.
정책:
Review the submitted compliance document by:
1. Extracting the document type, issuing authority, issue date, expiration date, license number, and entity name
2. Verifying that all required sections are present: header, body, signature block, and dates
3. Checking that the expiration date is in the future
4. Validating that the entity name matches the expected entity
5. Approve if all sections are present, the document is not expired, and entity names match; reject if the document is expired or missing required sections; flag for manual review if the entity name is a partial match
엔진: Text Verifier - Glove (완전성 및 필드 정확성 검증)출력 스키마:
{
  "document": {
    "type": "string",
    "issuingAuthority": "string",
    "issueDate": "string",
    "expirationDate": "string",
    "licenseNumber": "string",
    "entityName": "string"
  },
  "validation": {
    "allSectionsPresent": "boolean",
    "notExpired": "boolean",
    "entityNameMatch": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "pending_review | approved | rejected",
    "reasons": ["string"]
  }
}
결과: 만료된 문서가 자동으로 감지됩니다. 리뷰어는 이름이 부분적으로 일치하거나 섹션이 모호한 엣지 케이스만 처리합니다.

효과적인 출력 스키마 설계

출력 스키마는 각 분석에서 반환받는 구조화된 데이터를 결정합니다. 다운스트림 시스템을 염두에 두고 설계하세요. 모든 출력 스키마에는 다음 세 가지 블록이 포함되어야 합니다:
블록목적예시 필드
추출된 데이터문서에서 추출한 원시 값vendorName, invoiceNumber, registrationDate
검증 결과항목별 승인/거부 및 사유amountsMatch, dateValid, fieldsConsistent
결정최종 판정과 라우팅 상태result, verificationStatus, reasons
결정 블록을 생략하면 원시 검증 결과를 기반으로 자체적인 결정 로직을 작성해야 합니다. 결정 블록을 포함하면 AI 에이전트가 정책 기준에 따라 최종 판단을 내릴 수 있습니다.

verificationStatus 기반 라우팅

각 분석에는 verificationStatus 하나가 올라오며, 값은 approved, pending_review, rejected 중 하나입니다. 이 enum으로 시스템을 분기하세요.
verificationStatus권장 조치
approved자동 승인·시스템 반영
pending_review사람 검토 대기열로 전달(AI 요약·추출 데이터 포함)
rejected정책에 따라 거부·종료 처리
Omni가 검토 팀을 완전히 대체하는 것은 아닙니다. 명확한 건 통과시키고, 애매하거나 실패한 건 적절한 큐로 보냅니다.
각 상태 비율과 수동 판정과의 차이를 추적하세요. pending_review·rejected 비율이 기대와 다르면 정책 문구나 출력 스키마를 조정합니다.

구현 패턴

if verificationStatus == "approved":
    → 자동 승인, 시스템 기록
elif verificationStatus == "pending_review":
    → 검토 큐로 전달(AI 결과 강조)
else:  # rejected
    → 정책에 따른 거부·에스컬레이션
Omni API에서 분석 결과를 가져온 후 백엔드에서 이 로직을 통합하세요.

성과 측정

Omni 워크플로우를 배포한 후 다음 지표를 추적하여 영향을 측정하세요:
지표측정 방법목표
검토 시간 단축케이스당 평균 소요 시간 (도입 전 vs. 후)자동 승인 케이스에서 50-80% 단축
오류율잘못된 결정의 비율 (Omni 결과를 수동 표본 검사와 비교)수동 오류율과 동일하거나 낮음
처리량일/주당 처리된 케이스 수자동 처리로 인한 대폭 증가
에스컬레이션 비율사람 검토로 라우팅된 케이스의 비율정책 개선에 따라 시간이 지나면서 감소해야 함

권장 배포 접근법

1

단일 워크플로우로 파일럿 실행

가장 처리량이 많고 규칙 기반인 검토 프로세스를 선택하세요. 해당 프로세스에 대한 Omni 워크플로우를 생성하고 1-2주 동안 수동 프로세스와 병행 운영합니다.
2

결과 비교

Omni의 결정을 팀의 수동 결정과 비교합니다. 불일치를 찾아 Omni와 사람 리뷰어 중 누가 정확했는지 조사합니다.
3

정책 개선

비교를 바탕으로 정책 문구, 출력 스키마 또는 점수 임계값을 조정합니다. 작은 변경으로도 큰 개선을 이끌어낼 수 있습니다.
4

점진적 확대

정확도가 검증되면 Omni가 프로세스를 전체적으로 처리하도록 합니다. 그런 다음 추가 검토 프로세스의 자동화로 진행합니다.

다음 단계

워크플로우 생성하기

대시보드에서 첫 번째 워크플로우를 구축하는 단계별 가이드입니다.

정책 작성 가이드

효과적인 검증 정책을 작성하기 위한 모범 사례입니다.