Trade Compliance AI Agents: Coherent가 금지 거래 확인을 출하 직전에서 영업 첫 단계로 앞당긴 방법

Coherent는 거래 금지 대상 확인을 출하 직전에서 영업 첫 단계로 옮겼습니다. 영업 사원이 Salesforce에서 고객의 무역 상태를 먼저 보게 하자, 금지 거래는 시작하기 전에 멈춥니다. 따라 하려면 에이전트를 만드는 2주보다 먼저, 금지 대상이 지금 공정의 어디에서 늦게 드러나는지부터 그려야 합니다.

요약

Forbes의 공급망 담당 기고가 Steve Banker가 2026년 11월 7일 쓴 기사입니다. Coherent는 광학 소재와 레이저를 만드는 회사입니다. 제조·의료(LASIK)·통신과 데이터센터용 제품을 냅니다. 1971년에 세워졌고 20개국 넘는 곳에서 3만 명 넘게 일하며 지난해 매출은 58억 달러입니다. 생산시설은 14개국에 60곳이고 그 절반가량이 미국에 있습니다. 하이테크 기업이라 수출 통제 부담이 크고, 거래하면 안 되는 상대(denied party, 거래 제한 대상)를 걸러내는 일도 무겁습니다. 문제는 확인 시점이었습니다. 예전에는 영업이 계약을 따내고 제품을 다 만든 뒤 출하 대기 단계에서야 금지 고객임이 드러나는 일이 잦았습니다. Coherent는 무역 컴플라이언스 파트너 Exiger와 함께 거래 제한 정보를 Salesforce CRM에 넣는 AI 에이전트를 만들었습니다. 이제 영업 사원은 잠재 고객에게 연락하기 전에 그 회사의 무역 상태를 확인합니다.

거래 금지 상태를 확인하는 지점을 맨 끝에서 맨 앞으로 옮김. 기사 내용을 새 구도로 그림

결과는 세 갈래입니다. 첫째, 금지 거래를 시작 단계에서 끊어 영업 노력과 생산·물류 비용의 낭비를 막고, 월가에 약속한 매출이 갑자기 빠지는 일도 줄입니다. 둘째, 에이전트를 만들어 CRM에 붙이는 데는 2주 정도면 충분했습니다. 시간은 에이전트가 어디서 어떻게 일할지 이해하는 데 더 들었습니다. 셋째, 무역팀은 인원을 줄이지 않았습니다. 팀 비용은 거의 그대로이고 처리하는 분류·통관 업무는 훨씬 늘었습니다. 최고전략·법무·대외협력책임자 Rob Beard는 경직된 패키지 소프트웨어 대신 회사 워크플로에 맞춰 함께 만드는 파트너를 이유로 꼽고, 토큰 비용을 줄이려 범용 대형 모델 대신 작은 특화 모델을 쓴다고 밝혔습니다. 아래에서 이 구조를 개념별로 풀고, 실제로 돌릴 때 필요한 설계와 일정을 덧붙입니다.

기사가 전한 결과. 처리량 증가 폭은 기사에서 밝히지 않음

핵심 메커니즘

Trade Status in CRM: 영업 사원이 접촉 전에 무역 상태를 본다

핵심은 확인 결과를 영업이 일하는 화면에 두는 것입니다. 거래 제한 대상 스크리닝은 보통 주문 처리나 출하 단계에서 무역팀이 돌립니다. Coherent는 Exiger의 컴플라이언스 지식을 에이전트로 Salesforce에 넣었습니다. 영업 사원은 잠재 고객에게 연락하기 전에 그 회사가 거래 가능한 상대인지 봅니다. 금지 대상이면 영업 자체가 시작되지 않습니다. 영업 주기가 길고 주문 뒤 생산이 따르는 B2B 제조업에 특히 잘 맞습니다. 재고를 바로 내보내는 소매처럼 수주와 출하 사이가 짧으면 이득이 작습니다. 화면에 무엇이 어떤 형식으로 보이는지는 기사에서 밝히지 않았습니다. 가상 예시로, 부품 회사 영업 사원이 신규 고객 레코드를 만들면 바로 옆에 ‘확인 필요’ 표시가 뜨고, 무역팀 판정 전까지 견적 단계로 넘어가지 못하게 할 수 있습니다.

Trade status in CRM의 입력, 처리, 출력

Entity Screening과 Trade Classification: 상대를 식별하고 품목을 분류한다

Entity screening(상대 기업 식별·대조)은 거래 상대가 누구인지 정확히 찾아 거래 제한 목록과 맞춰 보는 일입니다. Trade classification(품목 분류)은 수출하는 제품이 어떤 통제·관세 분류에 해당하는지 정하는 일입니다. Coherent는 Exiger의 기본 분류 도구와 스크리닝 도구를 씁니다. 예전에는 담당자가 상대 회사를 인터넷에서 찾아보고 Street View로 건물까지 확인했습니다. 지금은 이 수작업이 크게 줄었습니다. 같은 이름의 회사가 많거나 주소가 불분명한 상대가 많을수록 효과가 큽니다. 고객이 잘 알려진 대기업 몇 곳뿐이라면 수작업으로도 버팁니다.

기사가 전한 변화. 도구별 절감 시간은 기사에서 밝히지 않음

Restricted Party List: 무역 상태는 자주 바뀐다

거래 제한 목록은 고정된 명단이 아닙니다. Beard는 회사의 무역 상태가 자주 바뀐다고 말합니다. 기사는 목록에 오른 중국 기업 Huawei를 예로 듭니다. 어제는 거래할 수 있던 상대가 오늘 금지 대상이 될 수 있다는 뜻입니다. 그래서 한 번 확인하고 끝내지 않고, 목록 변경을 계속 따라가는 Exiger 도구에 기댑니다. 이 구조가 있어야 영업 화면의 상태 표시를 믿을 수 있습니다. 목록이 얼마나 자주 갱신되는지는 기사에서 밝히지 않았습니다.

무역 상태는 한 번 확인으로 끝나지 않음. 반영 주기는 기사에서 밝히지 않음

Small Specialized Models: 작은 특화 모델로 토큰 비용을 낮춘다

에이전트는 대형 언어 모델 위에서 돌고, 모델 비용은 연산량에 따른 토큰 단위로 매겨집니다. Beard는 인터넷 규모 데이터로 학습한 범용 모델 대신 Coherent 업무에 맞춘 작은 특화 모델을 쓰면 비용이 내려간다고 설명합니다. 고객 레코드가 만들어질 때마다, 목록이 바뀔 때마다 호출되는 스크리닝처럼 횟수가 많고 범위가 좁은 일에 맞는 선택입니다. 반대로 드물게 쓰고 넓은 판단이 필요한 일에는 범용 모델이 더 맞습니다. 어떤 모델을 썼는지는 기사에서 밝히지 않았습니다.

Rob Beard가 밝힌 모델 선택 이유

Workflow-First Build: 구축보다 워크플로 이해에 시간을 쓴다

에이전트를 만들어 CRM에 붙이는 데는 2주 정도 걸렸습니다. 시간 대부분은 에이전트가 어디서, 어떻게 일할지 이해하는 데 들었습니다. Beard는 전통적인 엔터프라이즈 소프트웨어가 경직돼 있어 회사가 업무를 소프트웨어에 맞춰야 했다고 봅니다. 에이전트는 소프트웨어 스택을 유연하게 만들 수단이라고 말합니다. 그가 Exiger를 고른 이유도 Coherent의 워크플로를 이해하고 거기에 쓸모 있는 제품을 함께 만들려 했다는 점입니다. 벤더가 맞춤 개발에 응하고 회사 안에 워크플로를 설명할 사람이 있을 때 통하는 방식입니다. 둘 중 하나가 없으면 2주 구축도 의미가 없습니다.

기사 내용. 워크플로 파악에 든 정확한 기간은 기사에서 밝히지 않음

Throughput over Headcount: 인원 대신 처리량을 늘린다

Coherent는 무역팀 인원을 줄이지 않았습니다. 회사가 빠르게 크고 있기 때문입니다. 최근 분기(2027 회계연도 1분기) 매출은 데이터센터 수요에 힘입어 전년보다 약 50% 늘었습니다. 무역팀 비용은 거의 그대로이고 처리하는 분류·통관 업무는 훨씬 많아졌습니다. 업무량이 매출과 함께 느는 조직에서는 감원보다 같은 인원으로 더 많이 처리하는 쪽이 이득입니다. 업무량이 줄고 있는 조직이라면 계산이 달라집니다.

기사가 전한 무역팀 변화

통념과 다른 주장

흔히 이렇게 봅니다출하 전 스크리닝에서 금지 고객을 잡아냈다면 컴플라이언스 프로그램이 제대로 작동한 것이다.

Beard는 이렇게 봅니다출하 직전에 잡아낸 것을 강한 컴플라이언스의 증거로 볼 수 없습니다. 그때는 이미 손실이 났고, 영업 접촉 전에 막아야 합니다.

근거금지 고객이 늦게 드러나면 이미 만든 제품을 내보낼 수 없고 영업·생산·물류가 헛수고가 됩니다. 월가 예상 매출을 놓치고 무역팀 평판도 떨어집니다.

컴플라이언스 성공의 기준이 차단 여부에서 차단 시점으로 바뀜

흔히 이렇게 봅니다기업용 소프트웨어는 검증된 패키지를 사서 업무를 거기에 맞추는 것이 안전하다.

Beard는 이렇게 봅니다패키지는 너무 경직돼 있습니다. 에이전트로 소프트웨어를 회사 워크플로에 맞추고, 그 일을 함께할 파트너를 골라야 합니다.

근거Exiger는 Coherent의 워크플로를 이해하고 업무 단계에 맞춰 제품을 함께 만들었습니다. 구축은 2주 정도였고 시간은 워크플로 이해에 더 들었습니다.

도입 방식이 패키지 적용에서 워크플로 맞춤 공동 개발로 바뀜

저자가 든 사례

출하 대기 중에 드러난 금지 고객

상황: 영업 사원이 거래 제한 대상 회사와 계약을 맺었고 제품 생산까지 끝났습니다.
드러난 일: 출하를 앞둔 스크리닝에서야 금지 대상임이 확인됐습니다. Beard는 이를 모두를 곤란하게 만드는 결과로 봅니다.
결과: 제품을 내보낼 수 없고 영업·생산·물류 노력이 낭비됩니다. 발생 건수와 손실액은 기사에서 밝히지 않았습니다.
연결: Trade Status in CRM이 겨냥한 문제입니다.

기사가 전한 예전 방식. 발생 건수와 손실액은 기사에서 밝히지 않음

Salesforce에 넣은 무역 상태

상황: 금지 대상 확인이 공정 맨 끝에 있었습니다.
한 일: Exiger와 함께 거래 제한 정보를 Salesforce에 넣는 에이전트를 만들었습니다. 구축과 연결에 2주 정도 걸렸습니다.
결과: 영업 사원이 접촉 전에 무역 상태를 보고 금지 거래를 시작 전에 멈춥니다. 목표는 법을 지키는 거래는 하나도 막지 않는 것입니다. 적용 지역과 차단 건수는 기사에서 밝히지 않았습니다.
연결: Trade Status in CRM, Restricted Party List, Workflow-First Build.

적용 범위와 차단 건수는 기사에서 밝히지 않음

인원은 그대로, 처리량은 늘어난 무역팀

상황: 회사가 빠르게 성장하며 분류·통관 업무가 늘었습니다.
한 일: Exiger의 분류·스크리닝 도구로 인터넷 검색과 Street View 확인 같은 수작업을 줄였습니다.
결과: 감원 없이 팀 비용은 거의 그대로 두고 훨씬 많은 분류·통관 업무를 처리합니다. 증가 폭은 기사에서 밝히지 않았습니다.
연결: Entity Screening과 Trade Classification, Throughput over Headcount.

증가 폭은 기사에서 밝히지 않음

기술 디테일: 영업 단계 스크리닝을 실제로 돌리려면

아래 필드명, 기준값, 구성은 실행 제안이자 가상 예시입니다. Exiger나 Salesforce의 실제 기능 이름이 아니며 Coherent의 실제 구조도 아닙니다.

스크리닝을 세 층으로 나눕니다(Trade Status in CRM, Small Specialized Models). 모든 판단을 모델에 맡기면 비용이 고객 수에 비례해 늘고 결과가 흔들립니다. 첫 층은 규칙입니다. 회사 이름을 정규화(법인 형태 표기 제거, 영문 표기 통일)하고 목록과 유사도 점수를 냅니다. 둘째 층은 작은 모델입니다. 점수가 애매한 후보만 넘겨 주소·국가·모회사 정보를 비교하고 근거를 정리하게 합니다. 셋째 층은 CRM 기록입니다. 판정 결과를 고객 레코드에 남기고 영업 단계 진행을 제어합니다. 트리거는 고객 레코드 생성·수정, 그리고 목록 변경 알림 두 가지로 둡니다.

실행 제안. 가상 예시 구성이며 Coherent의 실제 구조가 아님

판정 결과는 구조화된 기록으로 남깁니다(Restricted Party List). 영업 화면에는 상태 하나만 보이더라도 뒤에는 왜 그렇게 판정했는지가 남아야 감사와 재확인이 됩니다. 고객 레코드마다 아래 같은 기록을 둡니다.

{
  "account_id": "001XX0000ABC",
  "legal_name": "Example Photonics Ltd.",
  "country": "SG",
  "ultimate_parent": "Example Holdings",
  "screening_status": "review",
  "match_candidates": [
    {"list": "restricted_party_list", "entry_name": "Example Photonic Co.", "score": 0.84}
  ],
  "reasons": ["이름 유사", "국가 다름", "모회사 미확인"],
  "list_version": "2026-11-13",
  "checked_at": "2026-11-14T09:12:00+09:00",
  "decided_by": null,
  "model_used": "small-screening-model"
}

점수 구간마다 처리 방식을 정합니다(Trade Status in CRM). 기준값은 처음에 지난 1~2년 스크리닝 결과로 맞추고, 파일럿 동안 오탐과 미탐을 보며 조정합니다. blocked 후보도 자동 확정하지 않고 무역팀이 판정합니다. 법을 지키는 거래를 막지 않으려면 사람이 마지막에 보는 구간이 필요합니다.

가상 예시 기준값. 회사 데이터로 다시 맞춰야 함

모델 호출 횟수를 설계로 줄입니다(Small Specialized Models). 대부분의 고객은 규칙 층에서 clear로 끝납니다. 모델은 review 후보에만 부르고, temperature는 0으로 둬 같은 입력에 같은 근거가 나오게 합니다. 판정 결과는 고객별로 캐시하고, 목록 버전이 바뀌거나 고객 정보가 수정될 때만 다시 계산합니다. 월별로 호출 수, 건당 토큰, review 비율을 대시보드로 봅니다.

실행 제안. 토큰 비용을 줄이는 호출 설계의 가상 예시

실패하는 경우를 미리 정해 둡니다(Restricted Party List, Entity Screening). 흔한 이름 때문에 합법 고객을 막는 오탐, 목록에는 없지만 지분 구조로 묶인 자회사를 놓치는 미탐, 목록이 바뀌었는데 열린 영업 기회를 다시 보지 않는 지연이 대표적입니다. 목록 변경 알림이 오면 진행 중인 영업 기회 전체를 다시 스크리닝하고, 상태가 바뀐 건은 담당 영업 사원과 무역팀에 함께 알립니다.

실행 제안. 가상 예시

현업 실행 디테일: 누가, 언제, 무엇을

역할을 나눕니다(Workflow-First Build). 무역 컴플라이언스팀이 판정 기준과 review 큐를 갖고, 영업 운영팀이 Salesforce 화면과 단계 규칙을 맡습니다. IT는 연결과 비용을, 벤더는 목록 데이터와 맞춤 개발을 맡습니다. 법무 책임자가 스폰서를 맡으면 영업과 무역팀 사이의 우선순위 다툼을 정리하기 쉽습니다. 기사에서는 Beard가 이 역할을 했습니다.

실행 제안. 역할 구분은 가상 예시

시작 전 준비물(출하 대기 중 금지 고객 사례). 지난 12~24개월 동안 수주 뒤에 금지·보류된 거래 목록, 그 거래가 어느 단계에서 걸렸는지, 그때까지 들어간 생산·물류 비용을 모읍니다. 고객 마스터 데이터의 품질(법인명, 주소, 국가, 모회사 기록 비율)도 확인합니다. 지금 무역팀이 상대 확인에 쓰는 검색 방법과 건당 소요 시간을 3~5건 직접 따라가며 기록합니다.

일정은 매핑에 가장 길게 씁니다(Workflow-First Build). 기사에서 구축은 2주 정도였고 시간은 워크플로 이해에 더 들었습니다. 이를 따라 1~3주는 매핑, 4~5주는 구축과 연결, 6~9주는 한 지역 파일럿, 10주에 확대를 판정하는 일정이 현실적입니다.

실행 제안. 구축 2주는 기사 수치, 나머지 기간은 가상 예시

매핑 때 묻는 질문(Trade Status in CRM). 영업 사원은 고객 레코드를 언제 만드나요? 견적은 어느 단계에서 나가나요? 무역팀은 지금 어느 시점에 스크리닝을 하나요? review 판정에 보통 며칠 걸리나요? 판정이 늦어 영업이 기다린 적이 있나요? 고객 정보에 모회사가 기록돼 있나요? 목록이 바뀌었을 때 지금은 누가 기존 고객을 다시 보나요?

진행 판정 기준(예시). 파일럿 지역에서 수주 뒤에 금지 대상이 드러난 건이 0건인지, review 판정이 1영업일 안에 끝나는 비율이 90% 이상인지, review로 걸렸다가 clear로 풀린 비율이 영업 불만을 부를 수준인지, 영업 사원이 화면 상태를 확인하고 접촉하는 비율이 얼마인지를 봅니다. 세 항목 이상을 넘으면 다른 지역으로 넓힙니다.

AX 적용 제언. 반도체 장비·소재, 디스플레이, 배터리, 방산 부품처럼 수출 통제가 무거운 한국 제조사에 바로 옮길 수 있는 구조입니다. 순서는 영업 CRM의 신규 고객 스크리닝 하나로 시작하고, 효과가 확인되면 같은 판정 기록을 구매 쪽 협력사 확인과 품목 분류로 넓히는 것이 좋습니다. 처음부터 감원을 목표로 걸면 무역팀의 협조를 얻기 어렵습니다. Coherent처럼 같은 인원으로 처리량을 늘리는 것을 성과 지표로 삼고, 경영진에는 늦게 드러난 금지 거래가 사라진 건수와 그로 인해 아낀 생산·물류 비용을 보고하는 것이 설득력이 큽니다.

원문 사례

항목	내용
원문	Forbes, Steve Banker, 2026.11.7
회사	Coherent(NYSE: COHR), 광학 소재·레이저, 1971년 설립
규모	20개국 넘는 곳에서 운영, 직원 3만 명 넘음, 지난해 매출 58억 달러, 2027 회계연도 1분기 매출 전년 대비 약 50% 증가
생산	14개국 60개 생산시설, 절반가량 미국, 광 트랜시버를 자체 화합물 반도체 팹·조립까지 수직 계열화
파트너	Exiger(2023년 12월 Carlyle·Insight Partners가 12억 달러 투자, 소프트웨어 7개 인수 뒤 AI 개발 도구로 단일 플랫폼으로 재구축)
쓰는 도구	Exiger 기본 trade classification, entity screening
바꾼 것	거래 제한 정보를 에이전트로 Salesforce CRM에 넣어 영업 접촉 전 무역 상태 확인
구축 기간	에이전트 구축과 CRM 연결 2주 정도, 워크플로 이해에 더 오래 걸림
모델	범용 대형 모델 대신 작은 특화 모델로 토큰 비용 절감
무역팀	감원 없음, 비용 거의 그대로, 분류·통관 처리량 크게 증가
발언자	Rob Beard, 최고전략·법무·대외협력책임자

핵심 개념

Denied party: 정부가 거래를 금지하거나 제한한 개인·기업. 수출하는 회사는 거래 전에 상대가 여기에 해당하는지 확인해야 합니다.
Restricted parties list: 거래 제한 대상을 모은 명단. 자주 바뀌어 한 번 확인으로 끝나지 않습니다.
Trade classification: 수출 품목이 어떤 통제·관세 분류에 해당하는지 정하는 일.
Entity screening: 거래 상대가 누구인지 식별해 제한 목록과 대조하는 일.
Token: 언어 모델이 글을 처리하는 단위. 모델 사용료가 이 단위로 매겨집니다.
Salesforce CRM: 영업 사원이 고객과 영업 기회를 관리하는 시스템. Coherent는 여기에 무역 상태를 넣었습니다.

내 메모

TODO: 내 생각 추가

원문은 Forbes의 「Coherent Moves Trade Compliance AI Agents To The Front Of The Process」(Steve Banker, 2026.11.7)입니다. Coherent의 Rob Beard 설명과 기사 서술을 바탕으로 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 사례, 원문 사례 표를 AX Review가 다시 정리했습니다. Entity screening, trade classification 같은 용어 풀이와 언제 쓰고 언제 안 쓰는지는 일반적인 설명으로 보탰습니다. 세 층 스크리닝 구성, JSON 예시, 점수 기준값, 모델 호출 설계, 실패 대응, 역할·일정·질문·판정 기준, AX 적용 제언, 인포그래픽은 기사에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.