워크플로우 자동화

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

자동화 기회 파악

모든 프로세스가 자동화에 적합한 것은 아닙니다. 수동 검토 프로세스가 Omni에 적합한지 확인할 수 있는 신호를 살펴보세요:

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

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

인보이스 검증 — 금액, 날짜, 벤더 정보, 항목별 합계 확인
벤더 온보딩 — 사업자등록 문서 검증 및 AML 감시 목록 심사
컴플라이언스 서식 검토 — 필수 필드가 존재하고 유효한지 확인
사업자등록 검증 — 기업 정보 추출 및 교차 확인
계약서 검토 — 주요 조건, 날짜, 당사자 정보 확인
직원 문서 확인 — 제출된 자격증, 라이선스 또는 신분증 검증

Omni는 명확하고 문서화 가능한 규칙이 있는 프로세스에서 가장 잘 작동합니다. 검토 프로세스가 주관적 판단이나 문서화할 수 없는 기관 지식에 크게 의존하는 경우, 완전 자동화보다는 부분 자동화가 필요할 수 있습니다.

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

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

현재 수동 프로세스 문서화

Omni에서 무엇이든 구축하기 전에, 팀이 현재 검토를 어떻게 처리하는지 정확히 기록하세요:

누가 검토를 수행합니까?
어떤 문서를 수신합니까?
각 문서에서 무엇을 확인합니까?
어떤 결정을 내립니까 (승인, 거부, 에스컬레이션)?
검토 후 결과는 어디로 전달됩니까?

이것이 기준선이 됩니다. 이 각 항목을 Omni 구성으로 변환하게 됩니다.

입력 문서 식별

검토를 위해 제출되는 모든 문서 유형을 나열하세요. 구체적으로 작성합니다:

PDF 인보이스인가요? 스캔된 사업자등록증인가요? 스프레드시트인가요?
케이스당 여러 문서가 있나요, 아니면 하나뿐인가요?
문서 간 교차 참조가 필요한가요?

Omni는 JPG, PNG, PDF, TXT, DOC, DOCX, XLS, XLSX, BMP, TIFF, WEBP, CSV, HTML, MD를 지원합니다. 폴더당 최대 5개 항목까지 가능합니다. 단일 케이스에 5개 이상의 문서가 포함된 경우, 동일한 프로필 내에서 관련 문서를 여러 폴더로 그룹화하세요.

승인/거부 기준 정의

팀이 수행하는 각 확인 항목에 대해 정확한 기준을 작성하세요:

문서가 승인되려면 무엇이 필요한가요? (예: “모든 필수 필드가 존재하고 합계가 항목과 일치”)
문서가 거부되는 조건은 무엇인가요? (예: “인보이스 날짜가 미래” 또는 “사업자등록이 만료됨”)
시니어 리뷰어에게 에스컬레이션되는 조건은 무엇인가요? (예: “AML 심사에서 일치 항목 발견” 또는 “핵심 필드를 읽을 수 없음”)

이러한 기준이 Omni 정책의 결정 로직이 됩니다.

자연어 정책으로 작성

이전 단계의 확인 항목과 기준을 구조화된 정책 문으로 결합합니다. 번호가 매겨진 단계와 명시적인 언어를 사용하세요.템플릿:

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]

자세한 예시와 모범 사례는 정책 작성 가이드를 참조하세요.

추출이 필요한 데이터 정의

각 검토에서 다운스트림 시스템에 필요한 구조화된 데이터를 결정합니다. 이것이 출력 스키마가 됩니다.자문해 보세요:

백엔드 시스템이 어떤 필드를 기대하나요?
추출된 원시 값이 필요한가요, 아니면 승인/거부 결과만 필요한가요?
출력에 결정 사유를 포함해야 하나요?

이러한 요구 사항에 정확히 맞도록 JSON 출력 스키마를 설계하세요.

실제 사례

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

예시 1: 인보이스 검토

이전: 수동 프로세스

재무팀 구성원이 각 인보이스 PDF를 열고 수동으로 확인합니다:

벤더명과 인보이스 번호가 존재하는지
인보이스 날짜가 적절한지 (미래가 아니고 90일을 초과하지 않는지)
항목별 금액이 명시된 합계와 일치하는지
세금 계산이 정확한지
시스템에 중복된 인보이스 번호가 없는지

인보이스당 소요 시간: 5-10분. 오류율: ~3% (계산 오류 누락, 중복 간과).

이후: Omni 워크플로우

정책:

Verify the submitted invoice document by:
Extracting vendor name, invoice number, invoice date, line items, subtotal, tax, and total amount
Verifying all required fields are present and non-empty
Validating that the invoice date is not in the future and not older than 90 days
Checking that the sum of line item amounts equals the stated subtotal
Verifying that tax is calculated correctly based on the subtotal
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": "verified | pending_review | rejected",
    "reasons": ["string"]
  }
}

결과: 검토 시간이 단순한 인보이스의 경우 5-10분에서 수 초로 단축됩니다. 팀은 플래그된 케이스만 수동으로 처리합니다.

예시 2: 벤더 온보딩

이전: 수동 프로세스

새 벤더가 온보딩될 때 컴플라이언스 담당자가:

사업자등록증에서 회사명, 등록번호, 설립일을 검토합니다
대표자의 신분증을 확인합니다
AML/제재 데이터베이스에서 대표자 이름을 수동으로 검색합니다
문서 간 기업 정보를 교차 확인합니다
결과를 스프레드시트에 기록합니다

벤더당 소요 시간: 20-30분. 병목: AML 검색이 느리고 수동 조회에서 오류가 발생하기 쉽습니다.

이후: Omni 워크플로우

정책:

Verify vendor onboarding documents by:
Extracting company name, registration number, incorporation date, and representative name from the business registration certificate
Screening the representative's name against AML/sanctions watchlists
Cross-validating the representative name between the business registration and any submitted identity documents
Checking that the business registration is not expired
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": "verified | pending_review | rejected",
    "reasons": ["string"]
  }
}

결과: AML 심사가 자동화되어 즉시 처리됩니다. 문제없는 케이스는 자동 승인됩니다. 컴플라이언스 담당자는 플래그된 벤더에만 집중합니다.

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

이전: 수동 프로세스

컴플라이언스 팀이 제출된 규제 문서를 검토합니다:

모든 필수 섹션이 존재하는지 확인합니다 (헤더, 서명, 날짜, 라이선스 번호)
만료일이 미래인지 확인합니다
문서가 올바른 기관에 발행되었는지 확인합니다
참조 번호가 내부 기록과 일치하는지 검증합니다

문서당 소요 시간: 10-15분. 위험: 대량 처리 기간에 만료된 문서가 간혹 통과됩니다.

이후: Omni 워크플로우

정책:

Review the submitted compliance document by:
Extracting the document type, issuing authority, issue date, expiration date, license number, and entity name
Verifying that all required sections are present: header, body, signature block, and dates
Checking that the expiration date is in the future
Validating that the entity name matches the expected entity
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": "verified | pending_review | rejected",
    "reasons": ["string"]
  }
}

결과: 만료된 문서가 자동으로 감지됩니다. 리뷰어는 이름이 부분적으로 일치하거나 섹션이 모호한 엣지 케이스만 처리합니다.

효과적인 출력 스키마 설계

출력 스키마는 각 분석에서 반환받는 구조화된 데이터를 결정합니다. 다운스트림 시스템을 염두에 두고 설계하세요. 모든 출력 스키마에는 다음 세 가지 블록이 포함되어야 합니다:

블록	목적	예시 필드
추출된 데이터	문서에서 추출한 원시 값	`vendorName`, `invoiceNumber`, `registrationDate`
검증 결과	항목별 승인/거부 및 사유	`amountsMatch`, `dateValid`, `fieldsConsistent`
결정	최종 판정과 라우팅 상태	`result`, `verificationStatus`, `reasons`

결정 블록을 생략하면 원시 검증 결과를 기반으로 자체적인 결정 로직을 작성해야 합니다. 결정 블록을 포함하면 AI 에이전트가 정책 기준에 따라 최종 판단을 내릴 수 있습니다.

`verificationStatus` 기반 라우팅

각 분석 응답 최상위에는 시스템이 산정한 verificationStatus 하나가 올라오며, 값은 verified, pending_review, rejected 중 하나입니다. 이 enum으로 시스템을 분기하세요.

출력 스키마의 결정 블록에 같은 이름의 필드를 정의했다면 그것은 사용자 정의 값이며, 여기서 말하는 시스템 판정과는 별개입니다. 자세한 구분은 GET /analyses/:analysisId를 참조하세요.

verificationStatus	권장 조치
`verified`	자동 승인·시스템 반영
`pending_review`	사람 검토 대기열로 전달(AI 요약·추출 데이터 포함)
`rejected`	정책에 따라 거부·종료 처리

Omni가 검토 팀을 완전히 대체하는 것은 아닙니다. 명확한 건 통과시키고, 애매하거나 실패한 건 적절한 큐로 보냅니다.

각 상태 비율과 수동 판정과의 차이를 추적하세요. pending_review·rejected 비율이 기대와 다르면 정책 문구나 출력 스키마를 조정합니다.

구현 패턴

if verificationStatus == "verified":
    → 자동 승인, 시스템 기록
elif verificationStatus == "pending_review":
    → 검토 큐로 전달(AI 결과 강조)
else:  # rejected
    → 정책에 따른 거부·에스컬레이션

Omni API에서 분석 결과를 가져온 후 백엔드에서 이 로직을 통합하세요.

성과 측정

Omni 워크플로우를 배포한 후 다음 지표를 추적하여 영향을 측정하세요:

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

권장 배포 접근법

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

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

결과 비교

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

정책 개선

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

점진적 확대

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

다음 단계

워크플로우 생성하기

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

정책 작성 가이드

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

시작하기

워크플로우 템플릿 (Coming soon)

자동화 기회 파악

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

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

실제 사례

예시 1: 인보이스 검토

예시 2: 벤더 온보딩

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

효과적인 출력 스키마 설계

`verificationStatus` 기반 라우팅

구현 패턴

성과 측정

권장 배포 접근법

다음 단계

워크플로우 생성하기

정책 작성 가이드

​자동화 기회 파악

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

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

​실제 사례

​예시 1: 인보이스 검토

​예시 2: 벤더 온보딩

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

​효과적인 출력 스키마 설계

​verificationStatus 기반 라우팅

​구현 패턴

​성과 측정

​권장 배포 접근법

​다음 단계

워크플로우 생성하기

정책 작성 가이드

자동화 기회 파악

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

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

실제 사례

예시 1: 인보이스 검토

예시 2: 벤더 온보딩

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

효과적인 출력 스키마 설계

`verificationStatus` 기반 라우팅

구현 패턴

성과 측정

권장 배포 접근법

다음 단계