심볼로지·정규식 필터링 — BarcodeFilterSettings 완전 가이드

TL;DR

SCANDIT SDK의 필터링 설계는 5계층으로 나뉩니다. 가장 가벼운 심볼로지 활성화/비활성화(1단)에서 시작해 Active Symbol Counts(2단), 복합 코드 옵션(3단), BarcodeFilterSettings 정규식(4단), 앱 콜백 비즈니스 로직(5단)으로 이어집니다. 사전 필터일수록 배터리·CPU 비용이 낮고, 사후 필터일수록 동적 전환이 용이합니다. 한국 물류·의약품 현장의 실전 정규식 패턴과 함께 각 계층의 선택 기준을 정리합니다.

이 가이드가 다루는 핵심 질문은 세 가지입니다. 첫째, 5계층 중 어느 단계에서 필터링하는 것이 가장 효율적인가. 둘째, BarcodeFilterSettings가 시각적 마스킹과 콜백 제외를 동시에 처리한다는 것은 실제로 무엇을 의미하는가. 셋째, 한국 물류·의약품 도메인에서 반복 등장하는 정규식 패턴을 어떻게 적용하는가. 각 질문에 대한 답을 실무 코드와 함께 순서대로 설명합니다.

---

Scandit 필터링 5계층 — 의사결정 트리

SCANDIT SDK는 바코드 인식 파이프라인 전반에 걸쳐 다섯 가지 필터링 지점을 제공합니다. 이를 계층 구조로 파악해 두면 어디서 차단하는 것이 가장 효율적인지, 어떤 상황에서 유연성이 필요한지 빠르게 판단할 수 있습니다.

1단: Symbology Enable/Disable — 인식 시작 전 심볼로지 선택

SymbologySettings.isEnabled를 통해 특정 심볼로지를 활성화하거나 비활성화합니다. SCANDIT SDK는 기본적으로 여러 심볼로지를 동시에 인식할 수 있지만, 사용 환경에 필요하지 않은 심볼로지가 활성화되어 있으면 불필요한 연산이 발생합니다. EAN-13만 처리하는 리테일 POS 시스템이라면 나머지 심볼로지를 모두 비활성화하는 것이 기본입니다.

이 단계는 프레임 처리 파이프라인 최상단에서 동작합니다. 비활성화된 심볼로지에 대해서는 디코딩 시도 자체가 발생하지 않으므로 배터리와 CPU 부담이 가장 작습니다.

SCANDIT SDK가 지원하는 심볼로지는 수십 가지에 달하며, 초기 설정 시 기본 활성화 상태인 심볼로지와 명시적으로 활성화해야 하는 심볼로지가 구분됩니다. 예를 들어 QR코드와 EAN-13은 기본적으로 비활성화 상태이므로 반드시 명시적으로 활성화해야 합니다. 반면 일부 레거시 심볼로지는 기본 활성화되어 있을 수 있습니다. 프로젝트 초기에 필요한 심볼로지 목록을 정리하고 나머지를 모두 명시적으로 비활성화하는 화이트리스트 방식을 권장합니다.

iOS Swift에서는 settings.set(symbology: .ean13UPCA, enabled: true) 형태로, Android Kotlin에서는 settings.enableSymbology(Symbology.EAN13_UPCA, true) 형태로 지정합니다. Web TypeScript와 React Native도 동일한 패턴이며, 플랫폼별 구현 예시는 이 페이지 상단의 코드 샘플 탭에서 확인할 수 있습니다.

2단: Active Symbol Counts — 자릿수 범위 사전 제한

SymbologySettings.activeSymbolCounts는 특정 심볼로지 내에서 처리할 데이터 길이(자릿수)를 지정합니다. 예를 들어 Code 39를 활성화했지만 현장에서 6자리 코드만 유효하다면 activeSymbolCounts = Set([6])으로 설정해 그 외 길이의 코드는 인식 단계에서 폐기합니다.

EAN-13은 항상 13자리로 고정이므로 이 설정이 의미가 없지만, Code 128·Code 39·Code 93처럼 가변 길이를 허용하는 심볼로지에서 특히 유용합니다. Active Symbol Counts는 SymbologySettings 객체 안에 있으므로 심볼로지를 활성화하는 시점에 함께 설정합니다.

// iOS Swift — Code 39, 8자리만 허용
let symSettings = settings.settings(for: .code39)
symSettings.activeSymbolCounts = Set([8])

// Android Kotlin — Code 39, 8자리만 허용
val symSettings = settings.getSymbologySettings(Symbology.CODE39)
symSettings.activeSymbolCounts = setOf(8)

자릿수 범위를 넓게 설정할수록 오인식 가능성이 높아집니다. 현장에서 사용하는 코드 길이가 명확하다면 최소한의 범위만 허용하는 것을 권장합니다.

3단: Composite Types — 1D+2D 합성 코드 처리

GS1 복합 코드(Composite Code)는 1D 선형 심볼로지(EAN-13, Code 128 등)와 2D 컴포넌트(CC-A, CC-B)가 수직으로 결합된 형태입니다. 국내 의약품 라벨과 GS1-128 의약품 표준코드 일부가 이 포맷을 사용합니다.

SCANDIT SDK에서 복합 코드를 인식하려면 compositeType 설정을 명시적으로 활성화해야 합니다. 단순히 EAN-13을 활성화한 것만으로는 복합 컴포넌트를 처리하지 않습니다. 복합 코드가 필요한 경우 BarcodeCaptureSettings의 enabledCompositeTypes 속성을 통해 CompositeType.a, CompositeType.b, CompositeType.c 중 필요한 유형을 지정합니다. CC-A는 최대 56비트, CC-B는 최대 338비트의 데이터를 담을 수 있으며, 국내 의약품 표준코드에서는 주로 CC-A와 CC-B가 사용됩니다.

복합 코드를 불필요하게 활성화하면 인식 속도가 떨어집니다. GS1 의약품 라인처럼 복합 코드가 명확히 필요한 환경에서만 해당 CompositeType을 켜는 것이 원칙입니다. 복합 코드 활성화 여부가 불확실하다면 PoC 단계에서 실제 라벨 샘플로 테스트하고, 비활성화 상태에서도 필요한 데이터가 정상 인식되는지 먼저 확인하는 것이 좋습니다.

4단: BarcodeFilterSettings — 사후 마스킹과 콜백 제외

BarcodeFilterSettings는 인식 파이프라인 후단에서 동작합니다. 디코딩은 이미 완료되었지만 BarcodeCaptureListener 콜백과 오버레이 시각화 이전 단계에서 특정 조건을 만족하는 결과를 걸러냅니다.

제공하는 필터 조건은 세 가지입니다.

excludedSymbologies — 지정한 심볼로지의 인식 결과를 콜백에서 제외합니다. 1단의 심볼로지 비활성화와 달리, 인식은 수행하되 결과만 억제하는 방식입니다. 동일 세션에서 특정 심볼로지를 임시로 무시해야 할 때 유용합니다.

excludedCodesRegex — 정규식 패턴에 일치하는 데이터 문자열을 가진 코드를 제외합니다. 예를 들어 한국 GS1 접두사 880으로 시작하지 않는 EAN-13을 제거하려면 앱 콜백 단에서 정규식 검증을 수행하거나, 반대로 특정 패턴만 제외하려면 excludedCodesRegex를 활용합니다.

excludedSymbolCounts — 특정 자릿수를 가진 코드를 콜백에서 제외합니다. 2단의 activeSymbolCounts와 보완적으로 사용할 수 있습니다.

이 단계의 결과 제외는 단순히 콜백을 억제하는 것에 그치지 않습니다. SCANDIT SDK의 오버레이 렌더링도 함께 마스킹되어, 해당 바코드 위치에 제외 색상 레이어가 표시됩니다. 결과적으로 UI와 비즈니스 로직 양쪽에서 해당 코드는 존재하지 않는 것처럼 처리됩니다.

5단: 앱 콜백 정규식 — 비즈니스 로직 검증

BarcodeCaptureListener.didScan() (또는 플랫폼별 동등 콜백)에서 전달받은 BarcodeCaptureSessions의 newlyRecognizedBarcodes를 순회하며 앱 비즈니스 로직에 맞는 검증을 수행하는 단계입니다.

이 단계는 SDK 레벨 설정이 아닌 순수 앱 코드 영역입니다. 예를 들어 사번 형식 ^[A-Z]{2}\d{6}$을 검증하는 로직은 SDK에 맡기기보다 콜백 내부에서 처리하는 것이 일반적입니다. 형식 검증 실패 시 UI 알림 또는 재스캔 안내 로직을 자연스럽게 연결할 수 있기 때문입니다.

5단은 SDK의 인식·필터 비용을 모두 지불한 뒤 남은 결과에 대한 최종 관문입니다. 이 단계에서 거르는 양이 많다면 4단 이전으로 로직을 끌어올리는 리팩토링을 고려해야 합니다.

---

사전 필터 vs 사후 필터 — 언제 무엇을 쓰는가

필터링 계층을 사전(pre-filtering)과 사후(post-filtering)로 나누면 의사결정이 명확해집니다.

사전 필터 (1단·2단) 는 카메라 프레임 처리 파이프라인 초입에서 동작합니다. 심볼로지 비활성화는 해당 심볼로지의 디코딩 시도 자체를 차단하므로, 처리하지 않을 코드에 대한 연산이 전혀 발생하지 않습니다. 배터리 민감도가 높은 모바일 기기나 저사양 Android 단말기에서 인식 속도와 배터리 수명에 직접적인 영향을 미칩니다.

사전 필터가 적합한 상황은 다음과 같습니다.

• 스캔 대상 심볼로지가 처음부터 명확한 경우 (예: 리테일 POS에서 EAN-13만 처리)
• 앱 세션 전반에 걸쳐 동일한 제약이 유지되는 경우
• 배터리·CPU 최적화가 최우선인 경우

사후 필터 (4단·BarcodeFilterSettings) 는 디코딩이 완료된 이후에 동작합니다. 인식 비용은 발생하지만 세션을 종료하거나 설정 객체를 재생성하지 않고도 런타임에 필터 조건을 변경할 수 있다는 장점이 있습니다.

사후 필터가 적합한 상황은 다음과 같습니다.

• 같은 카메라 세션에서 상황에 따라 필터 조건을 동적으로 교체해야 하는 경우 (예: 작업자가 선택한 창고 구역에 따라 허용 심볼로지 변경)
• 특정 패턴의 코드를 조건부로 마스킹해야 하는 경우
• 인식은 필요하지만 UI와 콜백에서 표시 여부를 분기해야 하는 경우

실무 원칙은 간단합니다. 사전 필터로 최대한 좁히고, 동적 변경이 필요한 부분만 사후 필터로 보완합니다. 두 계층은 배타적이지 않으며 함께 사용하는 것이 일반적입니다.

한 가지 주의할 점은 BarcodeFilterSettings 객체는 BarcodeCaptureSettings에 한 번 할당하면 교체하는 것이 가능하지만, 교체 시점과 카메라 프레임 처리 사이클이 겹치지 않도록 메인 스레드(iOS: main queue, Android: main thread)에서 설정을 변경해야 합니다. 백그라운드 스레드에서 설정을 변경하면 예측 불가능한 동작이 발생할 수 있습니다. 실제 현장에서 작업 모드 전환 버튼을 눌렀을 때 필터 조건이 즉시 반영되지 않는 문제가 보고되는 경우, 대부분 스레드 처리 오류가 원인입니다.

---

BarcodeFilterSettings 깊이 — 시각 마스킹 vs 콜백 제외

SCANDIT 본사 문서에서 상대적으로 가볍게 다루는 부분이 BarcodeFilterSettings의 이중 효과입니다. 이 API를 처음 접하면 단순히 콜백 필터링 도구로만 이해하기 쉬운데, 실제로는 SDK 렌더링 레이어와도 연동됩니다.

BarcodeFilterSettings가 특정 코드를 제외로 판정하면 두 가지 일이 동시에 일어납니다.

첫째, BarcodeCaptureListener 콜백에서 제외됩니다. didScan 이벤트의 newlyRecognizedBarcodes 배열에 해당 코드가 포함되지 않습니다. 앱 비즈니스 로직은 그 코드의 존재를 알 수 없습니다.

둘째, BarcodeCaptureOverlay의 시각적 마스킹이 적용됩니다. 기본적으로 SCANDIT SDK는 인식된 바코드 위치에 하이라이트 박스를 렌더링합니다. 필터 제외 코드에는 이 하이라이트가 다른 색상(기본값: 붉은 계열)으로 표시되어 사용자에게 "이 코드는 처리되지 않음"을 시각적으로 전달합니다. 마스킹 색상은 BarcodeCaptureOverlay.brushForTrackedBarcode 등을 통해 커스터마이징할 수 있습니다.

코드 샘플에서 각 플랫폼별 filterSettings 적용 방법을 확인할 수 있습니다.

iOS Swift에서는 settings.filterSettings = filter로, Android Kotlin에서는 settings.filterSettings = filter로 동일하게 적용합니다. Web TypeScript에서는 settings.filterSettings = filter이며, React Native에서도 동일한 프로퍼티 이름을 사용합니다. 플랫폼 간 API 일관성을 유지하는 것이 SCANDIT SDK의 설계 원칙 중 하나이기 때문에, 한 플랫폼에서 동작을 이해하면 다른 플랫폼으로 이식이 빠릅니다.

---

Regex 필터링 — 한국 도메인 패턴

현장에서 반복적으로 등장하는 한국 도메인 정규식 패턴을 정리합니다. 이 패턴들은 5단(앱 콜백 정규식)에서 검증 로직으로 활용하거나, 4단(excludedCodesRegex)에서 제외 조건으로 활용합니다. 목적에 따라 활용 계층이 다릅니다.

한국 EAN-13 국산 제품 접두사

GS1 한국(GS1 Korea)이 발급하는 국가 코드는 880입니다. 국내에서 생산된 제품의 EAN-13은 880으로 시작합니다.

^880\d{10}$

총 13자리이며 880 이후 10자리는 GS1 멤버사 코드(5~7자리)·상품 코드·체크 디지트로 구성됩니다. 국산 제품만 처리해야 하는 유통 시스템이라면 콜백 단에서 이 정규식으로 필터링합니다.

국내 대형 택배사 송장번호

국내 대형 택배사의 송장번호는 12자리 숫자로 구성됩니다. 심볼로지는 Code 128 또는 EAN-128 형태로 인쇄되는 것이 일반적입니다.

^\d{12}$

물류 창고 현장에서 송장 바코드만 처리하고 박스에 부착된 다른 상품 코드를 무시하려면, Code 128을 활성화한 뒤 이 정규식을 콜백 검증에 적용합니다. 더 정교하게는 특정 물류사 접두사(예: 63 시작)를 추가해 ^63\d{10}$ 형태로 좁힐 수도 있습니다.

사번·직원 ID 형식

제조 현장이나 입출고 관리 앱에서 사원 카드 QR코드나 바코드를 스캔하는 경우, 사번 형식이 고정되어 있다면 정규식으로 검증합니다.

^[A-Z]{2}\d{6}$

영문 2자리 + 숫자 6자리(예: DC123456) 형식의 사번을 검증하는 예시입니다. 실제 형식은 고객사마다 다르므로 현장 규칙을 반영해 조정합니다.

의약품 GS1 DataMatrix — AI(01) GTIN

식약처 의약품 표준코드에서 GS1 DataMatrix를 사용할 경우, 애플리케이션 식별자(AI) (01)로 시작하는 GTIN-14 구조를 포함합니다. 정규식으로 기초 검증할 때는 다음 패턴을 참고합니다.

^\(01\)\d{14}

괄호 문자 ( 와 ) 는 정규식에서 그룹 연산자이므로 반드시 이스케이프(\(, \))해야 합니다. 실제 데이터에는 AI(01) 뒤에 AI(17)(유효기간), AI(10)(배치번호), AI(21)(일련번호) 등이 이어질 수 있으며, 전체 파싱은 GS1 파서 라이브러리를 활용하는 것이 안전합니다. 정규식은 기초 포맷 확인 용도로만 사용합니다.

한국 국가표준 KAN 코드

KAN(Korean Article Number)은 EAN-13의 한국 로컬 명칭입니다. 구조는 EAN-13과 동일하며 880 접두사 패턴이 동일하게 적용됩니다. 간혹 내부 시스템에서 KAN 용어를 사용하는 경우에도 SDK 레벨 심볼로지는 EAN-13으로 처리합니다.

---

AI duplicate filter (SDK 8) vs BarcodeFilterSettings.excludedCodesRegex

SDK 8에서 도입된 AI duplicate filter와 BarcodeFilterSettings.excludedCodesRegex는 모두 "특정 코드를 무시한다"는 결과를 만들어내지만, 동작 원리와 적합한 상황이 전혀 다릅니다.

AI duplicate filter는 동일한 바코드가 짧은 시간 내에 반복 인식될 때 중복 콜백을 억제하는 기능입니다. 카메라 프레임은 초당 여러 번 처리되므로, 사용자가 바코드 하나를 스캔하면 같은 코드가 수십 프레임에 걸쳐 인식됩니다. AI duplicate filter는 이 반복 중 첫 번째 인식만 콜백으로 전달하고 일정 시간 동안 동일 코드의 추가 콜백을 억제합니다. 억제 기간은 SDK가 사용자의 스캔 의도를 추론해 동적으로 조정합니다.

SCANDIT SDK 8의 AI 기반 중복 필터링 상세 동작은 Scandit Docs — AI-Powered Barcode Scanning을 참조하시기 바랍니다.

BarcodeFilterSettings.excludedCodesRegex 는 시간 개념이 없습니다. 패턴에 일치하는 코드는 세션 내내, 몇 번을 인식하더라도 항상 제외됩니다. 이것은 특정 코드 패턴 자체를 시스템에서 배제하는 정책적 설정입니다.

기준	AI duplicate filter	excludedCodesRegex
동작 시점	동일 코드 반복 인식 시	패턴 일치 시 항상
시간 감수성	있음 (일정 시간 억제 후 재인식 허용)	없음 (영구 제외)
적합한 상황	연속 스캔 중 중복 방지	특정 패턴 코드 배제
SDK 버전	SDK 8+	SDK 6+

결론적으로 두 기능은 서로 보완적입니다. 일반적인 스캔 앱에서는 AI duplicate filter로 중복을 막고, excludedCodesRegex로 도메인에 맞지 않는 코드 패턴을 제외하는 방식으로 함께 사용합니다.

---

OCR fallback 정규식 (v7.4+)

SCANDIT SDK v7.4부터 제공되는 OCR fallback 기능(SymbologySettings.ocrFallbackRegex)은 바코드 인식에 실패했을 때 해당 프레임 영역의 텍스트를 OCR로 읽어 정규식으로 검증하는 방식입니다.

바코드가 물리적으로 손상되었거나 인쇄 품질이 낮아 디코딩에 실패한 경우, OCR로 동일 위치의 숫자나 문자를 읽은 뒤 형식 검증을 통해 "이것이 우리가 찾는 코드일 가능성이 높다"고 판단하면 해당 텍스트를 결과로 반환합니다.

국내 적용 사례로는 다음이 있습니다.

의약품 일련번호 스캔: 약품 포장재에 인쇄된 GS1 DataMatrix나 식약처 표준코드 바코드가 유통·보관 과정에서 오염·손상된 경우, OCR fallback으로 숫자 일련번호를 읽어 약품 관리 시스템에 입력할 수 있습니다.

노후 단말기 환경: 카메라 해상도가 낮은 구형 Android 단말기에서 미세한 바코드 인식이 불안정한 경우, OCR fallback이 보완책이 됩니다.

ocrFallbackRegex에 지정하는 정규식은 기대하는 텍스트 형식을 정밀하게 정의해야 합니다. 너무 느슨하면 오탐이 늘고, 너무 엄격하면 정상 케이스도 놓칩니다. 의약품 일련번호처럼 형식이 표준화된 경우에 OCR fallback을 활용하는 것이 가장 효과적입니다.

참고로 ocrFallbackRegex는 SymbologySettings 객체에 심볼로지별로 설정하므로, 특정 심볼로지(예: Code 128)에서만 OCR fallback을 활성화하고 나머지에서는 비활성화하는 세밀한 제어가 가능합니다.

OCR fallback을 활성화할 때는 성능 트레이드오프를 반드시 고려해야 합니다. OCR 처리는 바코드 디코딩보다 연산량이 크므로, 바코드 인식 실패가 자주 발생하는 환경에서 OCR fallback을 전면 활성화하면 전체 처리 속도가 저하될 수 있습니다. 손상된 코드가 산발적으로 등장하는 환경에서 선택적으로 활용하거나, OCR fallback 결과를 별도로 로깅해 실제 활용 빈도를 모니터링한 뒤 유지 여부를 결정하는 것을 권장합니다. 데이터커넥트는 OCR fallback 도입 전후의 스캔 성공률과 처리 지연을 비교 측정하는 A/B 테스트 방식을 고객사에 권장하고 있습니다.

---

DC 한국 사례

물류 창고 — 택배 송장 단일 인식

국내 대형 물류 창고 현장에서 입고 처리 앱을 구축할 때, 작업자가 스캔해야 할 코드는 택배 송장(12자리 Code 128)뿐이었지만 박스 외면에는 제조사 EAN-13, 내용물 QR코드, 물류사 내부 코드 등 다양한 바코드가 혼재했습니다. 데이터커넥트는 1단에서 Code 128만 활성화하고, 5단 콜백에서 ^\d{12}$ 정규식으로 추가 검증해 오인식 없는 단일 코드 처리 환경을 구성했습니다. 별도의 BarcodeFilterSettings 없이도 목표를 달성할 수 있었던 사례입니다.

이 접근 방식의 핵심은 "필요한 것만 켠다"는 화이트리스트 원칙입니다. Code 128 이외 모든 심볼로지를 비활성화하는 것만으로 잘못된 코드가 콜백에 도달하는 경우가 사실상 사라집니다. 정규식 검증은 송장번호 형식이 유효한지 확인하는 안전망 역할이며, 이 두 계층의 조합이 가장 단순하면서도 효율적인 구성입니다.

의약품 라인 — GS1 DataMatrix 단독 인식

의약품 제조 라인의 품질 관리(QC) 시스템에서는 GS1 DataMatrix 코드만 유효하며, 같은 라벨에 EAN-13이 병기되는 경우가 많습니다. 1단에서 DataMatrix만 활성화하고, 3단에서 CompositeType을 필요한 유형으로 설정하며, 4단 BarcodeFilterSettings.excludedCodesRegex에 ^\(01\)\d{14} 패턴이 아닌 코드를 제외하는 방식으로 의약품 GS1 포맷만 처리하도록 구성했습니다. 인식 정확도와 처리 속도 모두 현장 요건을 충족했습니다.

의약품 라인의 경우 식약처 컴플라이언스 요건이 있으므로 오인식은 단순한 UX 문제가 아니라 규제 위반으로 이어질 수 있습니다. 따라서 5단 콜백에서도 GS1 애플리케이션 식별자(AI) 파싱 결과를 검증하는 추가 레이어를 두어 포맷 확인과 데이터 무결성 검증을 이중으로 수행했습니다. 필터링 설계가 단순한 편의 기능이 아닌 규제 대응 수단이 되는 전형적인 사례입니다.

---

자주 묻는 질문

이 섹션은 아래 FAQ 항목의 상세 답변입니다. 요약 답변은 페이지 하단 FAQ 아코디언에서 확인할 수 있습니다.

사전 필터와 사후 필터의 선택 기준에 대해 — 핵심은 "변경 가능성"입니다. 앱의 생애주기 동안 동일한 심볼로지 조합이 유지된다면 사전 필터(1단·2단)만으로 충분합니다. 카메라 세션 내에서 작업 모드 전환이 필요하다면 사후 필터(4단 BarcodeFilterSettings)를 추가합니다. 두 계층 모두 적용하면 배터리 효율과 유연성을 동시에 확보할 수 있습니다.

Active Symbol Counts와 BarcodeFilterSettings의 관계 — 이 두 설정은 서로 다른 파이프라인 위치에서 동작하며 역할도 다릅니다. Active Symbol Counts는 심볼로지 인식 단계에서 자릿수 기준으로 조기 폐기하고, BarcodeFilterSettings는 인식이 완료된 결과를 데이터 패턴 기준으로 제외합니다. 두 설정 모두 적용하면 더 효율적인 파이프라인을 구성할 수 있습니다.

한국 송장 정규식 관련 — EAN-13 880 접두사 검증(국산 제품)과 12자리 숫자 송장번호(물류 송장)는 심볼로지 자체가 다를 수 있으므로 정규식 전에 심볼로지 분기를 먼저 확인합니다. 콜백에서 barcode.symbology 값을 체크한 뒤 해당 심볼로지에 맞는 정규식을 적용하는 패턴이 오류를 줄입니다.

BarcodeFilterSettings의 시각 마스킹과 콜백 제외 — SDK 내부 처리 순서상 마스킹과 콜백 제외는 동시에 적용됩니다. 단, 시각 마스킹이 표시되는 색상과 형태는 BarcodeCaptureOverlay 설정으로 조정할 수 있습니다. 필터 제외된 코드를 사용자에게 "읽었지만 처리하지 않음"으로 표시하고 싶다면 별도 색상을 지정하고, 아예 보이지 않게 하려면 마스킹 색상을 투명으로 설정합니다.

AI duplicate filter와 excludedCodesRegex 선택 — 실시간 스캔 피드에서 같은 코드가 반복 콜백되는 문제라면 AI duplicate filter가 정답입니다. 특정 포맷의 코드를 시스템적으로 배제해야 한다면 excludedCodesRegex를 선택합니다. 두 기능은 독립적으로 동작하므로 동시에 적용해도 충돌하지 않습니다.

---

마지막 업데이트

마지막 업데이트: 2026-05-01

이 페이지의 내용은 SCANDIT SDK 8.x 기준으로 작성되었습니다. SDK 버전 업데이트에 따라 API 시그니처나 설정 방법이 변경될 수 있으며, 데이터커넥트는 분기별로 내용을 검토하고 업데이트합니다. SCANDIT SDK 도입 상담 및 현장 PoC 설계가 필요하시면 데이터커넥트 기술팀에 문의하거나 데모를 신청해 주시기 바랍니다.

---

참조 문서: BarcodeFilterSettings API (iOS) · SymbologySettings API (iOS) · Configure Barcode Symbologies · AI-Powered Barcode Scanning

// iOS Swift — BarcodeFilterSettings: 880 prefix EAN-13 제외
let settings = BarcodeCaptureSettings()
// 1단: EAN-13만 활성화
settings.set(symbology: .ean13UPCA, enabled: true)
// 4단: BarcodeFilterSettings로 880 접두사 코드 제외
let filter = BarcodeFilterSettings()
filter.excludedCodesRegex = "^880\\d{10}$"
settings.filterSettings = filter

// Android Kotlin — BarcodeFilterSettings: 880 prefix EAN-13 제외
val settings = BarcodeCaptureSettings()
// 1단: EAN-13만 활성화
settings.enableSymbology(Symbology.EAN13_UPCA, true)
// 4단: BarcodeFilterSettings로 880 접두사 코드 제외
val filter = BarcodeFilterSettings()
filter.excludedCodesRegex = "^880\\d{10}\$"
settings.filterSettings = filter

// Web TypeScript — BarcodeFilterSettings: 880 prefix EAN-13 제외
const settings = await SDCBarcode.BarcodeCaptureSettings.fromJSON({});
// 1단: EAN-13만 활성화
settings.enableSymbology(SDCBarcode.Symbology.EAN13UPCA, true);
// 4단: BarcodeFilterSettings로 880 접두사 코드 제외
const filter = new SDCBarcode.BarcodeFilterSettings();
filter.excludedCodesRegex = /^880\d{10}$/;
settings.filterSettings = filter;

// React Native — BarcodeFilterSettings: 880 prefix EAN-13 제외
const settings = new BarcodeCaptureSettings();
// 1단: EAN-13만 활성화
settings.enableSymbology(Symbology.EAN13UPCA, true);
// 4단: BarcodeFilterSettings로 880 접두사 코드 제외
const filter = new BarcodeFilterSettings();
filter.excludedCodesRegex = '^880\\d{10}$';
settings.filterSettings = filter;