오늘날 많은 AI 프로젝트들이 멀티 에이전트 시스템 (multi-agent systems)으로 제시되고 있습니다.

한 에이전트는 조사하고, 다른 에이전트는 리스크를 분석합니다. 세 번째 에이전트는 컴플라이언스 (compliance)를 확인하고, 네 번째 에이전트는 권고 사항을 제공합니다.

매우 진보된 것처럼 들립니다.

하지만 은행에서는 에이전트를 더 많이 추가한다고 해서 워크플로우 (workflow)가 자동으로 안전해지는 것은 아닙니다.

은행은 단순히 AI 시스템이 확신에 찬 답변을 내놓았다는 이유만으로 고객 계좌를 동결하거나, 결제를 차단하거나, 규제 보고서를 제출하거나, 거래를 사기로 분류할 수 없습니다.

진정한 질문은 다음과 같습니다:

얼마나 많은 AI 에이전트가 참여하고 있는가?

진정한 질문은 이것입니다:

시스템이 증거를 제시하고, 스스로의 결론에 이의를 제기하며, 결정론적 규칙 (deterministic rules)을 적용하고, 영향력이 큰 결정일 때 인간의 승인을 위해 멈출 수 있는가?

이것이 흥미로운 멀티 에이전트 데모와 기업용 AI 워크플로우 (enterprise-ready AI workflow) 사이의 차이점입니다.

은행 사례: 의심스러운 계좌 이체

은행이 250,000달러 규모의 계좌 이체를 감지했다고 가정해 봅시다.

이 결제는 다음과 같은 이유로 이례적입니다:

• 고객이 이 정도 규모의 이체를 보낸 적이 없음.
• 수취 계좌가 새로운 국가에 있음.
• 거래가 고객의 일반적인 영업 시간 외에 발생함.
• 수취인이 이체 불과 몇 분 전에 추가됨.
• 고객이 최근에 전화번호와 이메일 주소를 변경함.

단순한 AI 챗봇은 다음과 같이 말할지도 모릅니다:

"이 거래는 의심스러워 보입니다. 차단을 고려하십시오."

그것만으로는 충분하지 않습니다.

은행은 다음 사항을 알아야 합니다:

• 어떤 거래 패턴이 우려를 유발했는가?
• 고객이 실제로 알려진 리스크 임계값 (risk threshold)을 위반하고 있는가?
• 제재 (sanctions) 또는 자금세탁방지 (AML) 문제가 있는가?
• 이것이 정당한 비즈니스 결제일 가능성이 있는가?
• 어떤 정책이 적용되는가?
• 결제를 차단해야 하는가, 보류해야 하는가, 아니면 승인해야 하는가?
• 누가 그 결정을 내릴 권한이 있는가?
• 은행이 나중에 감사인, 컴플라이언스 (compliance) 팀 및 고객에게 그 결정을 설명할 수 있는가?

이 지점이 바로 구조화된 멀티 에이전트 설계 (structured multi-agent design)가 중요한 이유입니다.

더 나은 설계: 은행 사기 결정실

하나의 모델이 결정을 내리게 하는 대신, 은행은 특화된 에이전트(agents)를 활용하여 통제된 워크플로우 (workflow)를 구축할 수 있습니다.

거래 알림 (Transaction Alert)
      ↓
사기 탐지 에이전트 (Fraud Detection Agent)
...

각 에이전트는 제한된 책임을 가집니다.

1. 사기 탐지 에이전트 (Fraud Detection Agent)

이 에이전트는 거래 행태를 분석합니다.

다음과 같은 사항을 식별할 수 있습니다:

• 비정상적인 결제 금액
• 새로운 수취인
• 새로운 국가
• 비정상적인 거래 시간
• 갑작스러운 프로필 변경
• 이전의 사기 지표

이 에이전트의 역할은 거래를 동결하는 것이 아닙니다.

이 에이전트의 역할은 구조화된 사기 신호 (fraud signal)를 생성하는 것입니다.

{
  "event_type": "FRAUD_SIGNAL",
  "transaction_id": "TXN-784921",
...

이를 통해 다음 단계에서는 LLM (Large Language Model)이 생성한 문단 대신, 검토 가능한 산출물 (artifact)을 전달받게 됩니다.

2. 고객 행동 에이전트 (Customer Behavior Agent)

거래가 의심스러워 보일 수 있지만 여전히 정당할 수 있습니다.

예를 들어, 기업 고객이 유효한 인수 결제를 진행 중이거나 새로운 해외 벤더에게 대금을 지급하고 있을 수 있습니다.

고객 행동 에이전트는 다음을 확인합니다:

• 과거 결제 행태
• 고객 세그먼트 (customer segment)
• 전형적인 결제 범위
• 알려진 비즈니스 관계
• 최근 고객 지원 상호작용
• 고객이 은행에 주요 결제에 대해 알렸는지 여부

이 에이전트는 다음과 같은 반론 (counterpoint)을 생성할 수 있습니다:

{
  "event_type": "CUSTOMER_CONTEXT",
  "transaction_id": "TXN-784921",
...

시스템이 모든 비정상적인 결제를 사기로 취급해서는 안 되기 때문에 이는 매우 중요합니다.

구조화된 반론 (Structured dissent)의 필요성

이제 사기 탐지 에이전트가 결제 차단을 권고한다고 가정해 보겠습니다.

훌륭한 기업용 워크플로우는 단순히 그 권고를 수용해서는 안 됩니다.

다른 역할이 그 권고에 이의를 제기하도록 요구해야 합니다.

예를 들어:

• 사기 탐지 에이전트 (Fraud Agent): “사기 위험 높음.”
• 고객 컨텍스트 에이전트 (Customer Context Agent): “정당한 비즈니스 이벤트에 대한 증거 없음.”
• AML (자금세탁방지) 에이전트: “수취인의 지리적 위험도가 높음.”
• 정책 에이전트 (Policy Agent): “은행의 보유 임계값(hold threshold)에 도달함.”
• 결정 검토자 (Decision Reviewer): “차단 전 인간의 승인 필요.”

이것이 바로 구조화된 반론 (structured dissent)입니다.

이것은 에이전트들이 재미를 위해 논쟁하도록 만드는 것이 아닙니다.

은행이 조치를 취하기 전에 가정을 가시화하는 것에 관한 것입니다.

이해관계가 큰 (high-stakes) 워크플로에서, 의견 불일치는 약점이 아닙니다. 숨겨진 의견 불일치가 진짜 위험입니다.

LLM이 단독으로 최종 결정을 내려서는 안 됩니다

LLM은 워크플로의 많은 부분에서 유용합니다:

• 거래 내역 요약 (Summarizing transaction history)
• 거래가 왜 비정상적으로 보이는지에 대한 설명 (Explaining why a transaction appears unusual)
• 고객 메모 읽기 (Reading customer notes)
• 조사 결과 해석 (Interpreting investigation findings)
• 사례 서술 초안 작성 (Drafting a case narrative)
• 컴플라이언스 검토 요약 생성 (Generating a compliance-review summary)

하지만 LLM이 결정론적 규칙 (deterministic rules)을 제어해서는 안 됩니다.

예를 들어, 다음 사항들은 관리되는 시스템 (governed systems)과 규칙 엔진 (rules engines)에서 제공되어야 합니다:

• 일일 거래 임계값 (Daily transaction thresholds)
• 제재 스크리닝 결과 (Sanctions screening results)
• AML (자금세탁방지) 정책 조건 (AML policy conditions)
• 규제 보고 일정 (Regulatory filing timelines)
• 고객 계좌 제한 (Customer account restrictions)
• 승인 권한 한도 (Approval authority limits)
• 결제 보류 정책 (Payment-hold policies)
• 리스크 점수 계산 (Risk score calculations)

안전한 아키텍처 (architecture)는 다음과 같습니다:

AI Layer
- Investigates (조사)
- Summarizes (요약)
...

이러한 구분은 매우 중요합니다.

AI는 왜 결제가 의심스러운지 설명할 수 있습니다.

규칙 엔진은 은행의 사기 방지 보류 임계값 (fraud-hold threshold)이 초과되었는지 여부를 결정할 수 있습니다.

컴플라이언스 담당자 (compliance officer)는 해당 결제를 실제로 차단해야 할지 결정할 수 있습니다.

증거 패널 (evidence panel)은 챗봇의 답변보다 더 중요합니다

최종 결정은 블랙박스 점수 (black-box score)여서는 안 됩니다.

컴플라이언스 담당자는 다음과 같은 증거 패널을 확인해야 합니다:

Transaction (거래):
TXN-784921

...

이것이 바로 기업용 AI가 생성해야 하는 결과물입니다.

단순한 답변이 아니라,

결정 기록 (decision record)이어야 합니다.

인간의 승인은 아키텍처의 일부입니다

인간의 승인은 사후 고려 사항 (afterthought)으로 추가되어서는 안 됩니다.

은행 업무에서는 일부 조치가 자동화되어야 합니다.

예를 들어:

시스템은 언제 진행하고, 언제 일시 중지하며, 언제 에스컬레이션 (escalate)해야 하는지를 알아야 합니다.

이것은 제약이 아닙니다.

이것이 바로 훌륭한 기업 설계 (enterprise design)입니다.

이것이 데이터 엔지니어링 팀에 의미하는 바

이와 동일한 패턴이 데이터 엔지니어링 (data engineering)에도 직접적으로 적용됩니다.

데이터 엔지니어링 코파일럿 (copilot)은 단순히 소스-대상 매핑 (source-to-target mapping) 문서로부터 SQL이나 YAML을 생성하는 것에 그쳐서는 안 됩니다.

그것은 거버넌스가 적용된 워크플로 (governed workflow)로서 작동해야 합니다.

예를 들어:

STTM / DDL / Source Metadata
          ↓
Metadata Extraction Agent
...

검토자 (reviewer)는 다음과 같은 사항들을 검증해야 합니다:

• 소스 컬럼 (source column)이 존재하는가?
• 대상 데이터 타입 (target data type)이 호환 가능한가?
• 조인 (join)이 매핑에 의해 지원되는가?
• 변환 규칙 (transformation rule)이 문서화되었는가?
• 부호 규칙 (sign rule)이 누락되었는가?
• 파생 지표 (derived metric)가 승인되지 않은 가정을 사용하고 있는가?
• 중복되거나 사용되지 않는 YAML 객체가 있는가?
• 엔지니어가 생성된 결과물을 승인하였는가?

그 후, 생성된 모든 아티팩트 (artifact)에는 추적성 (traceability)이 포함되어야 합니다.

Target Column:
PROFIT_AMT

...

이것이 바로 생성된 코드가 거버넌스가 적용된 엔지니어링 아티팩트 (engineering artifact)가 되는 방식입니다.

기업용 AI를 위한 실무 체크리스트

멀티 에이전트 시스템 (multi-agent system)을 기업용으로 적합하다고 판단하기 전에, 다음을 질문하십시오:

1. 각 에이전트가 명확한 책임을 가지고 있는가?
2. 핸드오프 (handoffs)가 자유 형식의 텍스트가 아닌 구조화되어 있는가?
3. 한 에이전트가 다른 에이전트의 결론에 이의를 제기할 수 있는가?
4. 중요한 계산과 정책 검사 (policy checks)가 결정론적 (deterministic)인가?
5. 모든 권장 사항을 소스 근거 (source evidence)로 추적할 수 있는가?
6. 시스템이 가정 (assumptions)과 신뢰 수준 (confidence levels)을 보여주는가?
7. 불확실성에 대한 명확한 에스컬레이션 경로 (escalation path)가 있는가?
8. 사람이 결정을 승인, 거부 또는 무효화 (override)할 수 있는가?
9. 조직이 나중에 전체 결정 과정을 재구성할 수 있는가?

만약 답변이 '아니오'라면, 그 솔루션은 여전히 유용한 프로토타입 (prototype)일 수는 있습니다.

하지만 높은 이해관계가 걸린 기업용 사용 (high-stakes enterprise use)에는 아직 준비되지 않은 것입니다.

마지막 생각

기업용 AI의 미래는 하나의 지능형 어시스턴트가 모든 결정을 내리는 것이 아닙니다.

또한 에이전트들이 끊임없이 대화하는 집합체도 아닙니다.

미래는 AI가 팀이 더 빠르게 조사하고, 관점을 비교하며, 리스크를 식별하고, 권장 사항을 준비할 수 있도록 돕는, 거버넌스가 적용된 의사결정 시스템 (governed decision system)입니다.

단, 근거는 계속해서 가시적으로 남아 있어야 합니다.

규칙은 계속해서 집행 가능해야 합니다.

이견은 계속해서 허용되어야 합니다.

그리고 사람은 계속해서 책임을 져야 합니다.

그것이 바로 신뢰가 속도만큼이나 중요한 은행, 금융, 데이터 엔지니어링 (data engineering) 및 기타 기업 워크플로우 (enterprise workflows)에서 AI가 유용해지는 방식입니다.

https://dataengineeringcopilot.com

https://github.com/amising6/data-engineering-copilot

https://www.linkedin.com/in/amit-singh-57980030