뿡야의 IT 기록

SWIFT에서 Finternet까지, 국제 금융 인프라의 변화

금융 데이터를 빠르게 보내는 일과, 돈의 이전을 최종적으로 확정하는 일은 서로 다른 문제다.

국내에서는 계좌이체를 하면 몇 초 안에 상대방이 돈을 확인하는 경우가 많다. 그런데 해외송금에서는 수취까지 시간이 걸리고 중간 수수료나 환율 때문에 실제 도착 금액을 이해하기 어려울 때가 있다.

인터넷으로 정보는 즉시 전달되는데, 국경을 넘는 돈의 이동은 왜 복잡할까?

국제 금융에서는 메시지 전송 외에도 여러 기관의 장부 갱신, 통화 교환, 유동성 확보, 규제 확인이 연결돼야 한다. 시스템이 서로 연결돼 있다는 사실만으로 이 과정이 모두 동시에 끝나는 것은 아니다.

이번 글에서는 SWIFT와 기존 국제 금융의 구조를 살펴본 뒤, Finternet과 토큰화 기반 인프라가 무엇을 바꾸려는지 정리한다.

1. 메시지 vs 청산 vs 결제

해외송금을 이해하려면 ‘송금 처리’라는 표현 안에 여러 단계가 있다는 점부터 알아야 한다.

표는 개념을 단순화한 것이다. 실제 시스템에서는 일부 단계가 통합되거나 서로 다른 방식으로 구현된다.

특히 결제완결성은 화면에 ‘성공’이라고 표시하는 것보다 넓은 개념이다. 시스템의 규칙과 법적 기반까지 연결된다. 금융시장인프라 원칙도 명확한 결제완결성과 법적 근거를 중요하게 다룬다. CPMI-IOSCO 금융시장인프라 원칙

따라서 다음 상태는 구분해서 봐야 한다.

요청을 접수했다
      ↓
지급 메시지를 전달했다
      ↓
기관 간 의무가 결제됐다
      ↓
수취인이 자금을 이용할 수 있다

모든 거래가 정확히 이 순서로 진행되는 것은 아니지만 각 상태가 가리키는 대상은 다르다.

2. SWIFT는 국제 금융에서 어떤 역할을 할까?

SWIFT는 은행과 금융기관 등이 금융거래 관련 메시지를 안전하고 표준화된 방식으로 교환하는 네트워크다.

기존 SWIFT 메시징의 중심 역할은 지급 지시와 금융정보를 전달하는 것이다. SWIFT 공식 설명도 실제 자금 이전은 은행 등 관련 기관을 통해 이루어진다고 구분한다. SWIFT 공식 소개

가상의 예시로 표현하면 다음과 같다.

한국 기업
   ↓ 지급 요청
한국 은행
   ↓ 금융 메시지 교환
관련 금융기관
   ↓
해외 수취 은행
   ↓
해외 거래처

메시지가 전달되는 동안 관련 기관들은 각자의 계좌와 장부를 갱신하고 필요한 절차를 수행한다. 메시지 경로와 실제 결제 경로가 항상 단순한 일대일 관계인 것도 아니다.

SWIFT는 수취 은행에 지급이 도달한 시점과 최종 고객 계좌에 입금되는 시점 사이에서도 지연이 발생할 수 있다고 설명한다. 따라서 네트워크의 전달 속도와 사용자가 체감하는 전체 소요시간을 구분해야 한다. SWIFT의 지급 처리 설명

이후 살펴보겠지만 SWIFT도 기존 메시징에 더해 공유원장 기반 기능을 개발하고 있다.

3. 해외송금에서는 왜 여러 은행이 등장할까?

모든 은행이 세계의 모든 통화와 지급결제 시스템에 직접 참여하기는 어렵다.

그래서 다른 은행과 관계를 맺고 계좌와 서비스를 이용하는 환거래은행(Correspondent Banking) 구조를 활용한다.

예를 들어 한국 은행이 외국 은행에 보유한 외화 계좌를 통해 지급을 처리할 수 있다.

이때 자주 등장하는 용어가 다음과 같다.

같은 계좌를 어느 은행의 입장에서 보느냐에 따라 표현이 달라질 수 있다.

국경을 넘는 지급은 이런 계좌 관계와 각국의 지급결제 시스템을 조합해 처리된다. BIS도 환거래은행 구조에서 외환 교환, 사전 자금 확보, 시스템 간 상호운용성을 주요 과제로 설명한다. BIS: Payments without borders

유동성을 미리 준비하는 비용

은행이 필요한 통화의 지급을 처리하려면 사용할 수 있는 자금이 있어야 한다.

관련 계좌에 미리 잔액을 확보하면 지급 실패 가능성을 줄일 수 있지만 여러 곳에 자금이 묶이는 비용이 발생한다. 다른 은행이 신용을 제공하는 구조라면 그에 따른 위험도 고려해야 한다. BIS의 국경 간 유동성 설명

빠른 메시징만으로 해결하기 어려운 부분이다.

4. 국제 지급의 지연은 어디서 발생할까?

국제 지급에서는 여러 종류의 마찰이 겹친다.

연방준비제도의 국경 간 지급 설명도 통화, 시간대, 규제 차이와 환거래은행 관계, 유동성 문제를 주요 과제로 다룬다. Federal Reserve: Cross-Border Payments

여기서 IT 관점의 핵심은 여러 기관이 각자 관리하는 상태를 일관되게 맞추는 일이다.

한 기관에서는 처리가 끝났는데 다음 기관에서 정보가 부족할 수 있다. 지급 지시는 유효하지만 결제할 자금이 준비되지 않았을 수도 있다.

이 문제를 개선하는 방향은 다음처럼 나눌 수 있다.

• 기관들이 더 정확한 데이터를 교환하도록 한다.
• 기존 지급 시스템의 연결과 운영 방식을 개선한다.
• 여러 자산과 결제 단계를 함께 처리할 새로운 구조를 만든다.

ISO 20022, 지급 시스템 연계, 토큰화와 공유원장은 각각 이 중 일부를 다룬다.

5. ISO 20022는 금융 메시지의 공통 언어다

ISO 20022는 금융정보를 공통된 의미와 구조로 모델링하고 메시지를 정의하는 국제 표준 체계다.

단순히 파일 확장자를 바꾸는 작업으로 보기보다는, 금융기관이 교환하는 데이터의 의미를 맞추는 기반으로 이해하는 편이 좋다. ISO 20022 공식 FAQ

예를 들어 지급 관련 정보를 구분된 항목으로 다루면 다음 업무를 지원할 수 있다.

• 송금인과 수취인 정보 처리
• 지급 목적과 참조정보 연결
• 자동 대사
• 규제 확인과 예외 처리

하지만 형식이 같다고 데이터 품질까지 보장되지는 않는다. 같은 필드라도 입력 기준과 사용 규칙이 맞아야 한다.

SWIFT의 관련 전환에서는 2025년 11월 22일 CBPR+ 지급지시 메시지의 MT·ISO 20022 공존 기간이 종료됐다. 이를 모든 금융 메시지와 전 세계 시스템이 같은 날 일괄 전환됐다는 의미로 확대해서는 안 된다. SWIFT ISO 20022 구현 안내

이 표준의 역할은 정보를 더 잘 교환하도록 돕는 것이다. 그 자체가 결제 자산이나 새로운 지급 네트워크는 아니다.

6. Finternet은 무엇일까?

Finternet은 여러 금융 생태계를 인터넷처럼 상호 연결하자는 미래 금융 시스템의 비전이다.

Agustín Carstens와 Nandan Nilekani가 2024년 BIS 워킹페이퍼에서 제안했다. 특정 제품이나 이미 전 세계에서 운영되는 단일 네트워크의 이름으로 읽으면 부정확하다. Finternet 원문

구상의 중심에는 사용자가 금융기관과 자산 종류 사이의 장벽을 덜 느끼면서 금융서비스를 이용하도록 하자는 목표가 있다.

이를 위해 원문은 다음 기반을 함께 다룬다.

• 경제, 금융 구조
• 토큰화 등 디지털 기술
• 법률, 규제, 거버넌스
• 상호운용성, 검증 가능성, 보안과 개인정보 보호

즉, 기술적인 연결만으로 완성되는 구상이 아니다.

예를 들어 다른 기관에 있는 자산을 담보로 사용하면서 대출과 결제를 연계하려면, 데이터와 자산 이전뿐 아니라 권리의 유효성, 담보 집행, 참여기관의 책임도 정해져야 한다.

또한 해당 워킹페이퍼의 견해는 저자들의 것이며, BIS나 회원 중앙은행 전체의 공식 입장을 반드시 뜻하지는 않는다. BIS 워킹페이퍼 설명

7. 토큰화는 기존 디지털 장부와 무엇이 다를까?

은행 예금과 증권은 이미 전산 장부로 관리된다.

그렇다면 토큰화가 추가로 제공하려는 기능은 무엇일까?

BIS는 토큰화를 기존 장부에 있는 실물·금융자산에 대한 권리를 프로그래밍 가능한 플랫폼에 기록하는 과정으로 설명한다. 이를 통해 메시지, 대사, 자산 이전을 더 긴밀하게 결합하는 가능성을 제시한다. BIS: 차세대 통화·금융 시스템

예를 들어 증권 거래에서 다음 조건을 연계할 수 있다.

매수자의 지급 준비 확인
          +
매도자의 증권 이전 준비 확인
          ↓
연결된 조건을 충족하면 교환 실행

핵심은 자산을 표현한 데이터와 그 자산에 적용되는 처리 규칙을 같은 흐름으로 다룰 수 있다는 점이다.

다만 토큰을 발행했다는 사실만으로 현실의 권리가 새로 생기는 것은 아니다. 토큰이 어떤 청구권을 나타내며 누가 이행 책임을 지는지 정해져야 한다.

무엇이 토큰화됐는지도 중요하다

이름에 ‘토큰’이 붙었다고 같은 위험과 법적 성격을 갖는 것은 아니다.

8. 통합원장에서는 무엇을 통합하려는 걸까?

Unified Ledger·통합원장은 토큰화된 자금과 자산, 관련 거래 규칙을 함께 처리할 수 있도록 하는 구상이다.

관련된 상태 변경을 조정해 여러 기관의 순차적인 확인과 대사 부담을 줄이려는 목적이 있다.

하지만 ‘통합’이 반드시 전 세계가 하나의 데이터베이스를 공유한다는 뜻은 아니다.

BIS는 단일 원장부터 서로 연결된 원장까지 여러 구조를 설명하며, 프로그래밍 가능성과 결합 가능성, 데이터·거버넌스의 독립성 사이에서 선택이 필요하다고 본다. BIS: 통합원장 아키텍처

예를 들어 국가별 데이터 보관 요건이 다르면 모든 정보를 한곳에 모으기 어려울 수 있다. 여러 원장을 연결하면 각자의 통제는 유지하기 쉽지만, 원장 사이의 상태를 맞추는 작업이 복잡해진다.

따라서 “원장을 합치면 해결된다”보다 다음 질문이 먼저다.

어떤 상태를 함께 확정해야 하고, 어떤 정보와 통제는 분리해야 할까?

9. 원자적 결제는 무엇을 해결할까?

원자성·Atomicity는 연결된 작업을 모두 실행하거나, 모두 실행하지 않는 방식으로 다루는 성질이다.

외환 거래를 생각하면 의미가 분명해진다.

거래 당사자 A의 통화 지급
             ↕ 조건 연결
거래 당사자 B의 다른 통화 지급

한쪽 지급만 최종 완료되고 반대쪽 지급이 실패하는 위험을 줄이려면 두 이전을 연결해야 한다.

이와 관련된 대표 개념이 다음과 같다.

• PvP·Payment versus Payment: 서로 다른 통화의 지급을 연결
• DvP·Delivery versus Payment: 증권 등의 인도와 대금 지급을 연결

금융시장인프라 원칙도 연결된 의무의 최종 결제가 조건부로 함께 이루어지도록 하는 원칙을 다룬다. 이 접근은 기존 금융시장에서도 사용되며, 토큰화 플랫폼은 이를 구현·확장하는 방법을 연구한다. CPMI-IOSCO 금융시장인프라 원칙

원자성이 있더라도 유동성 부족, 잘못된 지시, 운영 장애까지 사라지는 것은 아니다. 어떤 작업 범위에 원자성을 적용했고, 외부 시스템과 법적 확정까지 어떻게 연결했는지 확인해야 한다.

10. 중앙은행 돈은 왜 계속 등장할까?

은행 계좌의 예금과 은행이 중앙은행에 보유한 준비금은 역할이 다르다.

은행 간 지급에서는 중앙은행 돈이 최종 결제의 기준 자산으로 중요한 역할을 한다. BIS와 중앙은행들의 공동 보고서도 기존의 이층 구조와 중앙은행 결제 자산이 통화에 대한 신뢰를 뒷받침한다고 설명한다. BIS: 기술혁신과 도매 중앙은행 돈

토큰화된 예금과 중앙은행 준비금을 함께 다루려는 프로젝트도 이 구조와 연결된다.

형태와 처리 방식은 바꾸되, 어떤 기관의 부채를 주고받으며 최종적으로 무엇으로 결제하는지 명확하게 하려는 것이다.

일반 사용자가 쓰는 소매형 CBDC와 금융기관 간 결제용 중앙은행 돈도 구분해야 한다. 도매 결제 실험이 곧 모든 국민을 위한 새 지갑 서비스의 도입을 뜻하지는 않는다.

11. 실제로 어디까지 진행됐을까?

Project Agorá: 다중통화 도매 지급 실험

Project Agorá는 BIS와 국제금융협회 IIF가 추진하는 민관 협력 프로젝트다.

토큰화된 상업은행 예금과 중앙은행 준비금을 공유된 프로그래밍 가능 플랫폼에서 결합해 국경 간 도매 지급을 개선할 수 있는지 살핀다.

공식 페이지에 따르면 2026년 7월 통제된 환경에서 실가치 테스트를 수행했다. 금융기관과 중앙은행 28곳이 참여했으며, 총거래 규모는 약 80만 스위스 프랑 상당이었다. 한국은행도 해당 테스트 참여 중앙은행에 포함된다. BIS Project Agorá

이는 실제 가치를 사용한 시험이라는 점에서 의미가 있다. 다만 제한된 참여자와 거래 시나리오에서 수행한 테스트이며, 일반 고객에게 개방된 전 세계 상용 서비스로 해석해서는 안 된다.

또한 24시간 처리를 지향하는 설계와 실제 테스트가 24시간 연속 운영을 입증했는지는 별개의 문제다.

SWIFT 공유원장: 기존 시스템과 연결하는 접근

SWIFT는 2026년 7월 9일, 블록체인 기반 공유원장이 초기 사용을 위한 준비를 마쳤다고 발표했다.

이 구조에서는 은행들이 자체 원장에 발행한 토큰화 예금을 조정하고, 최종 결제는 기존 시스템을 통해 완료하는 방식을 설명한다. SWIFT 공유원장 발표

이후 Standard Chartered와 HSBC도 해당 원장을 활용한 실거래를 발표했다. 설명에 따르면 두 은행 사이 의무를 기록·매칭·상계하고 기존 시스템에서 최종 결제를 수행했다. Standard Chartered 공식 발표

여기서는 공유원장에서 처리했다는 사실과 중앙은행 돈으로 최종 결제가 끝났다는 사실을 구분해야 한다.

Nexus: 기존 즉시지급 시스템을 연결하는 방향

모든 개선이 토큰화 원장을 필요로 하는 것은 아니다.

Project Nexus는 각국의 국내 즉시지급 시스템을 연결해 국경 간 지급을 지원하는 접근이다. BIS Project Nexus

현재 금융 인프라를 개선하는 길에는 메시지 표준화, 기존 시스템 연계, 공유원장 실험이 함께 존재한다.

12. SWIFT와 Finternet을 같은 종류로 비교하면 어려운 이유

지금까지의 내용을 나란히 두면 차이가 보인다.

따라서 “Finternet이 SWIFT를 대체하는가?”라는 질문만으로는 변화의 방향을 충분히 설명하기 어렵다.

SWIFT 같은 기존 참여자가 새로운 원장 기능을 추가할 수도 있고, 새로운 플랫폼이 기존 메시지 표준과 결제 시스템을 사용할 수도 있다.

앞으로 무엇이 바뀌는지는 어떤 업무가 어느 계층으로 이동하는지를 살펴봐야 알 수 있다.

13. 앞선 신원과 AML 주제는 어디에 연결될까?

금융 인프라가 빨라져도 거래 당사자와 권한, 위험을 확인하는 문제는 남는다.

이 표는 역할을 연결한 설명이다. 모든 프로젝트가 해당 기술을 필수로 사용한다는 뜻은 아니다.

새로운 플랫폼에서는 이런 확인을 거래 준비 단계와 연결하는 설계를 시도할 수 있다. Project Agorá도 규제 준수, 결제완결성, 개인정보 보호 같은 법적·운영적 문제를 함께 검토한다. BIS Project Agorá

확인 절차를 자동화하더라도 판단 근거와 책임이 없어지는 것은 아니다. 오히려 거래가 빨라질수록 실행 전 확인과 예외 처리의 중요성이 커진다.

14. 개발자는 어떤 질문으로 인프라를 평가해야 할까?

새로운 금융 기술을 볼 때 처리 속도와 원장 종류 외에도 확인할 항목이 있다.

다음은 시스템을 검토하기 위한 질문이다.

특히 하나의 SUCCESS 상태로 모든 결과를 표현하면 문제가 생기기 쉽다.

메시지 전송에 성공했지만 결제는 대기 중일 수 있다. 고객이 자금을 사용할 수 있어도 은행 간 최종 결제는 나중에 이루어지는 구조일 수 있다.

시스템의 상태 모델은 실제 금융상의 책임과 확정 시점을 반영해야 한다.

국제 금융 인프라의 변화는 정보를 보내는 속도와 함께 서로 다른 기관의 장부·자산·규칙을 얼마나 일관되게 연결하는지에서 평가할 수 있다. Finternet과 관련 실험을 읽을 때도 이 기준을 적용하면, 기술적 가능성과 실제 운영 성과를 구분하기 쉬워진다.

참고 자료

• SWIFT — Who We Are
• ISO 20022 — 공식 FAQ
• BIS — Finternet: The Financial System for the Future
• BIS — The Next-Generation Monetary and Financial System
• BIS — Project Agorá
• BIS — Project Nexus
• CPMI-IOSCO — 금융시장인프라 원칙

AML, KYC, CDD와 금융 범죄 방지의 구조

상대방이 누구인지 확인했다면, 그 사람이 하는 거래도 안전하다고 볼 수 있을까?

은행 앱에서 계좌를 개설하다 보면 여러 질문을 받는다.

직업은 무엇인지, 계좌를 어떤 목적으로 사용하는지, 거래자금은 어디에서 마련했는지 확인한다. 법인 계좌를 만들 때는 회사 정보뿐 아니라 실제 소유자와 거래 담당자의 권한을 묻기도 한다.

이미 신분증을 제출했는데 왜 이런 정보까지 필요한 걸까?

신원이 확인됐다는 사실과 금융거래의 위험이 충분히 파악됐다는 사실은 다르기 때문이다.

앞선 글에서는 개인의 디지털 신원과 기업의 LEI와 vLEI를 살펴봤다. 이번에는 확인한 신원정보가 금융 범죄 방지 과정에서 어떻게 활용되는지 알아본다.

국제 기준은 FATF 권고를, 한국 제도는 금융정보분석원과 관련 법령을 기준으로 설명한다. 금액 기준과 국내 제도 설명은 2026년 10월 22일 확인한 공식 자료를 바탕으로 한다.

1. AML은 금융 범죄 방지 체계의 한 부분이다

AML은 Anti-Money Laundering, 자금세탁방지를 뜻한다.

자금세탁은 일반적으로 불법적인 자금의 출처를 숨겨 합법적인 것처럼 보이게 만드는 과정이다. AML은 이를 예방하고 발견하기 위한 법률, 제도, 내부 통제와 업무 절차를 포함한다.

금융정보분석원도 자금세탁방지제도를 사법제도, 금융제도, 국제협력이 연결되는 종합적인 관리체계로 설명한다. 금융정보분석원: 자금세탁방지제도

함께 등장하는 용어도 구분해 두면 좋다.

이 업무들은 데이터를 공유하고 함께 운영될 수 있지만, 목적과 법적 판단 기준이 모두 같지는 않다.

FATF는 자금세탁, 테러자금조달, 대량살상무기 확산금융에 대응하는 국제 기준을 제시한다. 각국은 이를 자국의 법률과 제도에 맞게 이행한다. 따라서 FATF 문서의 설명과 특정 국가에서 직접 적용되는 의무를 구분해야 한다. FATF Recommendations

2. KYC, CDD, EDD는 어떻게 다를까?

처음 접하면 가장 헷갈리는 용어들이다.

KYC와 CDD의 경계는 자료나 조직마다 겹친다. 금융정보분석원도 고객확인제도를 고객알기정책이라고 설명한다. 두 용어가 언제나 엄격하게 분리된 별도 단계라고 이해할 필요는 없다. 금융정보분석원: 고객확인제도

실무에서는 KYC를 전체 정책이나 고객확인 업무의 이름으로, CDD를 구체적인 확인 의무와 절차를 설명하는 말로 사용하는 경우가 많다.

또한 KYB를 사용한다고 해서 법적 의무가 새로운 이름으로 대체되는 것은 아니다. 기업 고객에 대한 CDD를 설명하는 실무 용어로 읽는 편이 안전하다.

3. 고객확인은 무엇을 확인하는 과정일까?

신분증 확인은 중요한 출발점이다. 하지만 고객확인에는 그보다 넓은 내용이 포함된다.

FATF 권고 10의 핵심을 정리하면 다음과 같다.

1. 고객을 식별하고 신원을 검증한다.
2. 실제 소유자를 파악하고 신원을 검증하기 위한 합리적 조치를 취한다.
3. 거래 관계의 목적과 성격을 이해한다.
4. 거래 관계 동안 지속적으로 주의를 기울이고 거래를 살핀다.

즉, 고객에 대한 이해와 실제 거래를 연결하는 과정이다. FATF 권고 10

한국의 고객확인제도도 신원 확인과 검증, 실제 소유자 확인, 필요한 거래 목적과 자금 원천 확인 등을 다룬다. 실명확인만으로 고객확인이 모두 끝나는 구조는 아니다. 금융정보분석원: 고객확인 내용

가상의 기업 고객을 예로 들면 다음 질문들이 이어진다.

어느 회사인가?
      ↓
누가 회사를 지배하거나 통제하는가?
      ↓
신청자는 회사를 대신할 권한이 있는가?
      ↓
어떤 사업과 거래를 위해 서비스를 사용하는가?
      ↓
실제 거래가 이 설명과 부합하는가?

확인 항목과 증빙의 범위는 고객 유형, 상품, 위험, 적용 법령에 따라 달라진다.

4. 실제 소유자는 대표자와 다를 수 있다

실무에서 말하는 ‘실소유자’는 국내 제도에서 실제 소유자라고 표현한다. 영어로는 Beneficial Owner다.

중심 질문은 다음과 같다.

고객을 최종적으로 소유하거나 지배·통제하는 자연인은 누구인가?

법인 등기상 대표자나 계좌를 개설하러 온 담당자가 반드시 실제 소유자인 것은 아니다.

예를 들어 다음과 같은 구조를 생각할 수 있다.

자연인 A
   ↓
해외 지주회사 B
   ↓
국내 사업회사 C

고객이 C라고 해서 B의 회사 이름을 확인하는 것으로 모든 질문이 해결되지는 않는다. 적용 기준에 따라 상위 소유 및 통제 구조와 자연인을 파악해야 한다.

FATF는 정확하고 최신인 실제 소유자 정보에 접근할 수 있도록 여러 정보원을 결합하는 접근을 강조한다. FATF: 법인의 실제 소유자 지침

지분율만 계산하면 끝날까?

지분은 중요한 판단 근거지만 통제는 다른 방식으로도 발생할 수 있다. FATF 용어집도 소유를 통한 통제 외에 다른 수단을 통한 통제를 다룬다. FATF Glossary

한국 금융정보분석원의 일반 안내는 법인·단체의 경우 25% 이상 지분 소유자 확인을 출발점으로 하고, 확인이 어려운 경우 다른 지배 기준과 대표자 확인으로 이어지는 단계적 절차를 설명한다. 구체적인 적용과 예외는 관련 법령에 따라 확인해야 한다. 금융정보분석원: 실제 소유자 확인

어떤 국가의 지분 기준 하나를 전 세계 공통의 완전한 정의로 사용해서는 안 된다.

5. 위험기반접근법: 모두에게 같은 강도의 확인이 필요할까?

RBA·Risk-Based Approach, 위험기반접근법은 위험에 비례해 조치를 설계하는 접근이다.

고객, 상품, 거래 방식, 지역 등 관련 요소를 평가하고 필요한 확인과 모니터링의 강도를 정한다.

예를 들어 일상적인 국내 거래를 위한 개인 계좌와 복잡한 소유 구조를 가진 기업의 국제 거래는 살펴봐야 할 위험이 다를 수 있다. 이것만으로 어느 한쪽이 불법이라는 뜻은 아니다.

위험이 높으면 추가 정보와 검증, 더 강한 모니터링 등이 필요할 수 있다. 낮은 위험에서는 법과 제도가 허용하는 간소화 조치를 적용할 수 있다. FATF도 비례성과 저위험 영역의 간소화 조치를 강조한다. FATF 위험기반접근법 관련 개정 안내

EDD는 서류를 많이 받는 일일까?

추가 서류의 양보다 어떤 위험을 해소하려는지가 중요하다.

확인 목적에 따라 다음과 같은 조치를 고려할 수 있다.

• 사업과 거래 목적에 대한 추가 설명
• 자금이나 재산 형성 경위에 대한 확인
• 소유 및 통제 구조의 추가 검증
• 필요한 상위 책임자의 승인
• 모니터링 강도와 검토 주기 조정

‘서류를 받았다’와 ‘위험에 관한 의문이 해소됐다’는 다른 상태다.

6. 자금의 원천과 재산의 원천도 다르다

EDD 문서에서는 Source of Funds와 Source of Wealth가 자주 등장한다.

이번 입금이 다른 은행 계좌에서 왔다는 설명만으로 경제적인 자금 원천이 충분히 밝혀졌다고 볼 수는 없다. 어느 계좌에서 이동했는지와 어떤 활동으로 만들어진 돈인지는 서로 다른 질문이다.

FATF의 PEP 지침도 자금의 원천과 재산의 원천을 구분해 다룬다. 확인 범위와 검증 강도는 적용 요건과 위험에 맞춰 정해야 한다. FATF PEP Guidance

7. 제재 대상 확인과 PEP 확인은 같은 일이 아니다

고객 이름을 명단과 비교한다고 해서 모든 스크리닝이 동일한 판단을 하는 것은 아니다.

제재 스크리닝

적용되는 제재나 거래 제한의 대상인지 확인하는 업무다.

한국에서도 특정 개인, 법인, 단체를 금융거래 등에서 제한대상자로 지정하고 관련 거래를 제한하는 제도를 운영한다. 구체적인 제한과 허가 요건은 적용 제도에 따라 판단해야 한다. 금융정보분석원: 금융거래등 제한대상자

PEP 확인

PEP는 Politically Exposed Person, 주요 공적 직무를 맡았거나 맡은 사람 등을 가리킨다.

직무와 영향력이 악용될 가능성에 대응하는 예방적 조치의 대상이지, 범죄자 명단이라는 뜻은 아니다. FATF도 PEP라는 이유만으로 범죄에 연루됐다고 해석해서는 안 된다고 명시한다. 외국, 국내, 국제기구 PEP 등에 대한 구체적 조치도 구분된다. FATF PEP 안내

이름이 같으면 바로 같은 사람일까?

동명이인, 번역과 음역, 약칭 때문에 일치 후보가 생길 수 있다.

서비스에서는 생년월일, 식별정보, 소재지 등 사용 가능한 근거를 대조해 동일인 여부를 검토하도록 설계할 수 있다.

중요한 구분은 다음과 같다.

이름 유사성 발견
        ≠
동일인 확인
        ≠
적용되는 법적 조치 결정

이름 매칭 점수 하나에 최종 판단까지 맡기면 정상 고객에게 불필요한 피해를 줄 수 있다.

8. 거래 모니터링은 고객확인과 어떻게 연결될까?

고객확인으로 거래 목적과 사업을 이해했다면 이후 거래가 그 설명과 부합하는지 살펴볼 수 있다.

예를 들어 고객이 설명한 사업 규모나 거래 상대방과 실제 활동 사이에 큰 차이가 발견됐다고 하자. 시스템은 검토할 신호를 만들 수 있지만 그 차이만으로 범죄가 확정되지는 않는다.

바젤위원회 지침은 최신 CDD 정보와 고객 프로필을 활용해 위험 변화를 파악하고, 비정상 거래 경보를 추가 평가하도록 설명한다. 바젤위원회 AML/CFT 지침

이를 서비스 흐름으로 표현하면 다음과 같다.

고객정보 + 거래정보
         ↓
탐지 규칙, 분석 모델
         ↓
검토 경보 생성
         ↓
관련 정보와 고객 맥락 조사
         ↓
추가 확인, 위험 재평가, 보고 여부 판단

이 흐름은 설명용 예시다. 실제 처리 순서와 조치는 기관 및 법적 요건에 따라 달라진다.

특히 경보, 내부 조사 사건, 외부 보고를 구분해야 한다. 경보가 생성됐다는 이유만으로 자동으로 외부 보고나 거래 제한이 결정되는 것은 아니다.

9. STR과 CTR: 의심을 보고하는가, 현금거래 사실을 보고하는가?

한국 제도에서 자주 혼동하는 두 가지가 있다.

STR: 의심거래보고

금융정보분석원은 불법재산이나 자금세탁행위 등으로 의심되는 합당한 근거가 있는 경우 보고하는 제도로 설명한다.

보고 이후에는 KoFIU가 관련 정보를 종합 및 분석하고 필요한 경우 법집행기관에 정보를 제공하는 과정이 이어진다. 보고 자체와 수사, 기소, 유죄 판단은 다른 단계다. 금융정보분석원: STR

CTR: 고액현금거래보고

공식 안내에 따르면 한국에서는 동일 금융회사에서 동일인 명의로 1거래일 동안 1천만원 이상 현금이 입금되거나 출금되는 경우가 기본적인 보고 기준이다. 실제 적용에는 법령상 합산 방식과 예외 등을 함께 확인해야 한다. 금융정보분석원: CTR

여기서 ‘현금거래’라는 범위가 중요하다. 금융위원회는 이체나 송금이 CTR의 현금거래 대상과는 다르다고 설명한다. 금융위원회 CTR 설명

CTR 기준에 해당하지 않는 거래라도 별도의 의심 근거가 있다면 STR 검토 대상이 될 수 있다. 두 제도를 같은 금액 필터로 구현하면 안 되는 이유다.

10. 고객확인은 가입 이후에도 계속된다

계좌를 개설할 때 확인한 정보가 계속 정확하리라는 보장은 없다.

기업의 실제 소유자가 바뀔 수 있고 사업 내용이나 거래 목적이 달라질 수도 있다. 또 개인 고객의 거래 양상이 변화할 수도 있다.

따라서 서비스 설계에서는 보통 두 가지 갱신 경로를 함께 고려할 수 있다.

모든 고객에게 같은 주기를 적용해야 한다는 뜻은 아니다. 중요한 변화가 생기면 예정된 검토일 이전에도 대응할 수 있어야 한다.

한국에서는 정보 제공 거부 등으로 고객확인을 할 수 없는 경우 신규 거래 거절이나 기존 거래 종료, 의심거래보고 여부 검토에 관한 규정도 있다. 다만 일시적인 시스템 오류를 곧바로 고객의 정보 제공 거부와 동일하게 처리해서는 안 된다. 특정금융정보법 제5조의2

11. 디지털 신원과 LEI, vLEI는 어디에 도움이 될까?

앞선 두 편과 연결하면 역할이 명확해진다.

FATF의 디지털 신원 지침은 디지털 ID를 고객 식별하거나 검증에 사용할 때 기술, 운영체계, 보증 수준과 위험에 대한 적합성을 평가하도록 다룬다. 또한 지속적인 고객확인을 지원할 가능성도 설명한다. FATF Digital Identity Guidance

따라서 디지털 신원 증명에 성공했다는 이유만으로 고객확인 전체가 끝났다고 처리해서는 안 된다.

기업 식별정보와 역할 자격증명을 활용할 때도 실제 소유자 자료, 상태의 최신성, 거래 목적에 대한 판단을 연결해야 한다.

12. IT 시스템으로 구현하면 무엇이 중요할까?

다음은 AML 시스템을 이해하기 위한 개념적인 구성이다.

고객, 기업, 실제 소유자 정보
                ↓
       신원 검증 및 스크리닝
                ↓
          고객 위험평가
                ↓
     거래 모니터링과 정보 갱신
                ↓
        경보 검토, 사건 관리
                ↓
     필요한 조치, 보고, 증거 보관

운영에서는 이 흐름이 반복되며, 새 정보가 이전 판단을 바꿀 수도 있다.

판단 결과와 근거를 함께 남긴다

‘고위험’이라는 결과만 저장하면 나중에 설명하기 어렵다.

설계 시 다음 정보를 함께 관리하는 것을 고려할 수 있다.

• 평가에 사용한 정보와 확인 시점
• 규칙, 모델, 정책의 버전
• 경보와 판단을 연결하는 근거
• 검토자와 승인자
• 예외 처리 및 재검토 이력

외부 솔루션의 결과 해석

이름 매칭, 신원 검증, 위험평가를 외부 사업자에게 맡길 수 있다. 그래도 결과가 무엇을 의미하고 어떤 한계가 있는지 이해해야 한다.

바젤위원회도 은행이 제3자를 활용하더라도 고객확인과 AML/CFT 준수 책임은 은행에 남는다고 설명한다. 바젤위원회 제3자 활용 지침

AI는 검토를 돕되 근거를 만들어내지 않게

활용 예시로는 자료 추출, 동명이인 검토 보조, 사건 시간순 정리, 조사 문서 초안 작성 등을 생각할 수 있다.

이때 AI가 추론한 내용과 확인된 사실을 구분하고, 원문 자료로 돌아갈 수 있어야 한다. FATF의 신기술 보고서도 효율성뿐 아니라 설명가능성, 데이터 품질과 운영상의 위험을 함께 다룬다. FATF: AML/CFT 신기술의 기회와 과제

경보 수만으로 성과를 판단하지 않는다

많은 경보가 항상 좋은 탐지를 뜻하지는 않는다. 정상 거래를 지나치게 많이 경보로 만들면 검토 역량이 소진될 수 있다.

다음은 운영 지표의 예시다.

이 지표들은 함께 봐야 한다. 보고 건수 증가만으로 범죄 탐지 성과가 높아졌다고 단정할 수도 없다.

신원정보와 거래의 맥락

개인의 신원을 확인하면 누구인지에 대한 정보를 얻는다. 기업 신원을 확인하면 어느 법적 실체이며 담당자가 어떤 역할을 하는지 이해할 수 있다.

금융 범죄 방지에서는 그다음 질문이 이어진다.

이 고객은 왜 서비스를 사용하는가? 실제 거래가 설명과 부합하는가? 새로운 정보가 기존 판단을 바꿔야 하는가?

고객확인 정보는 이런 질문을 판단하기 위한 기준점이 된다. 거래 모니터링에서 발견한 변화는 다시 고객정보와 위험평가를 갱신하는 근거가 된다.

AML 시스템을 설계한다면 신분증 검사 결과를 저장하는 기능과 함께 정보, 위험, 거래, 검토 결과가 서로 갱신되는 구조를 살펴봐야 한다.

참고 자료

• 금융정보분석원 — 자금세탁방지제도
• 금융정보분석원 — 고객확인제도
• 금융정보분석원 — 의심거래보고
• 금융정보분석원 — 고액현금거래보고
• FATF — Recommendations
• FATF — Beneficial Ownership Guidance

거래 상대가 실제로 존재하는 회사라는 사실과, 눈앞의 사람이 그 회사를 대표할 수 있다는 사실은 서로 다른 증명이 필요하다.

새로운 협력사에서 계약서를 보내왔다고 가정해 보자.

회사 이름과 주소가 적혀 있고, 담당자는 회사 이메일을 사용한다. 계약서에는 ‘재무 담당 임원’이라는 직함과 서명도 들어 있다.

이 정보만으로 계약을 진행해도 될까?

먼저 확인할 것이 있다. 같은 이름의 다른 회사는 아닌지, 계약 상대가 본사인지 자회사인지, 서명한 사람이 실제로 그 회사에서 일하는지 살펴봐야 한다. 그 사람이 해당 계약을 체결할 권한을 갖고 있는지도 별개의 문제다.

앞선 디지털 신원 글이 개인의 신원과 자격을 다뤘다면, 이번에는 기업의 신원과 기업을 대신하는 사람의 역할을 살펴본다.

이때 중심이 되는 개념이 LEI와 vLEI다.

1. 기업 신원에서는 무엇을 확인해야 할까?

기업 간 거래에서 필요한 확인을 세 단계로 나누면 이해하기 쉽다.

예를 들어 ‘A그룹 구매 담당자’라는 소개만으로는 충분하지 않다.

A그룹은 브랜드나 기업집단의 이름일 수 있다. 실제 계약 당사자는 특정 국가에 설립된 자회사일 수 있으며, 구매 담당자의 권한에도 금액이나 업무 범위에 따른 제한이 있을 수 있다.

이 글에서 사용하는 ‘기업 신원’은 이런 문제를 설명하기 위한 표현이다. LEI가 식별하는 대상은 기업에만 한정되지 않는 법적 실체인 legal entity이므로, 개인의 실명확인이나 단순한 회사 계정 관리와 구분해서 읽는 것이 좋다.

2. LEI: 세계 여러 시스템에서 같은 법적 실체를 가리키는 식별자

LEI는 Legal Entity Identifier의 약자다.

ISO 17442에 기반한 20자리 영문·숫자 코드이며, 특정 법적 실체를 고유하게 식별한다. 해당 코드에는 공식 명칭, 주소 등 검증된 참조정보가 연결된다. GLEIF의 LEI 설명

GLEIF가 공개한 자체 LEI를 예로 들면 다음과 같다.

506700GE1G29325QX363

이 코드는 비밀번호나 비밀키가 아니다. 누구나 조회할 수 있는 공개 식별자다.

따라서 어떤 사람이 거래 문서에 정확한 LEI를 적었다고 해서 그 기업의 관계자라는 증거가 되지는 않는다. 다른 회사의 공개 식별자를 복사할 수도 있기 때문이다.

LEI의 역할은 기업을 정확히 가리키는 것이고, 그 기업을 대신해 행동하는 사람을 인증하는 것은 추가로 해결해야 할 문제다.

회사 이름만으로는 왜 부족할까?

가상의 기업 이름을 생각해 보자.

한빛테크 주식회사
HANBIT TECH CO., LTD.
Hanbit Technology

같은 회사를 서로 다르게 표기한 것일 수도 있고, 비슷한 이름의 별개 회사일 수도 있다.

기업명이 바뀌거나 국가별 표기 방식이 다르면 이름 비교만으로 데이터를 연결하기 어려워진다. LEI는 이런 상황에서 공통 식별 기준으로 활용할 수 있다.

국가별 사업자·법인 등록 식별자와도 역할이 다르다. LEI는 기존 등록 체계를 없애는 것이 아니라, 해당 실체에 관한 정보를 국제적으로 연결하는 식별 기준으로 이해하면 된다.

3. LEI를 조회하면 어떤 정보를 볼 수 있을까?

LEI 데이터는 대표적으로 Level 1과 Level 2로 구분한다.

Level 1: 누구인가?

Level 1은 법적 실체의 기본 정보다.

공식 명칭과 등록 주소처럼 기업을 구분하는 정보를 제공한다. GLEIF는 이를 ‘Who is who’라는 질문으로 설명한다. GLEIF의 데이터 구분

실제 레코드에는 등록기관 식별정보, 법적 형태, 설립 관할, 실체의 상태, LEI 등록 상태 등도 포함될 수 있다. 구체적인 데이터 구조는 LEI-CDF 문서에서 확인할 수 있다. GLEIF LEI-CDF 문서

Level 2: 어떤 상위 실체와 연결되는가?

Level 2는 ‘Who owns whom’이라는 표현으로 소개되지만, 정확한 범위를 알아야 한다.

주요 대상은 다음 관계다.

• 직접 회계 연결 모기업
• 최상위 회계 연결 모기업

즉, 회계 연결 기준에 따른 상위 실체 정보를 다룬다. 이를 모든 지분 관계나 최종 자연인 실소유자 정보가 담긴 완전한 소유 구조로 해석해서는 안 된다. 보고 예외 등도 고려해야 한다. GLEIF Level 2 설명

AML 업무에서 확인하는 실소유자와 LEI의 상위 실체 정보를 같은 것으로 취급하면 범위를 잘못 이해하게 된다.

4. LEI는 누가 발급하고, 왜 갱신할까?

LEI 발급·갱신 서비스를 제공하는 기관은 LEI Issuer, 또는 Local Operating Unit·LOU라고 부른다.

기업은 발급기관을 통해 등록하고, 기관은 관련 정보를 검증한다. LEI는 매년 갱신하며, 발급·유지 비용과 요금 체계는 발급기관에 따라 달라질 수 있다. GLEIF LEI FAQ

갱신이 중요한 이유는 기업 정보가 계속 바뀌기 때문이다.

주소나 명칭이 변경될 수 있고, 합병이나 조직 재편이 발생할 수도 있다. 식별자가 존재한다는 사실과 연결된 정보가 최근에 검증됐다는 사실은 구분해야 한다.

LAPSED는 회사가 폐업했다는 뜻일까?

아니다.

GLEIF는 Level 1의 LAPSED를 예정된 기간 안에 갱신·재검증되지 않은 상태라고 설명한다. 기업이 비활성 상태라는 뜻은 아니다. GLEIF LEI Search 안내

특히 다음 두 필드를 섞어 읽지 않아야 한다.

서비스에서 LAPSED를 받아들일지는 업무 목적과 적용 요건에 따라 결정해야 한다. 상태 이름 하나만 보고 폐업 여부나 거래 가능 여부를 단정하는 것은 적절하지 않다.

5. vLEI: 기업 식별에 사람의 역할을 연결한다

LEI로 거래 상대 기업을 정확히 찾았다고 해 보자.

그래도 질문이 남는다.

“지금 이 요청을 보낸 사람이 그 기업을 대표할 수 있는가?”

vLEI는 verifiable Legal Entity Identifier다.

기존 LEI에 기반한 조직 신원과 사람의 신원·역할을 암호학적으로 연결해 검증할 수 있도록 하는 체계다. GLEIF는 조직의 LEI, 개인의 신원, 조직 내 역할을 연결하는 구조로 설명한다. GLEIF의 vLEI 설명

비교하면 다음과 같다.

vLEI는 LEI에 첨부파일 하나를 붙이는 정도의 개념이 아니다. 발급기관의 자격, 발급·철회 절차, 키 관리, 자격증명 구조를 포함한다.

GLEIF는 이 신뢰 구조의 출발점인 root of trust 역할을 맡는다. 따라서 분산된 검증 기술을 활용하더라도, 발급자의 책임과 거버넌스가 존재한다. GLEIF의 vLEI 신뢰 구조

6. 조직의 공식 직책과 업무상 역할은 어떻게 구분할까?

vLEI를 이해할 때 중요한 것이 OOR과 ECR이다.

OOR: 공식 조직 역할

OOR은 Official Organizational Role이다.

조직의 공식 역할을 맡은 사람을 표현하는 자격증명이다. 자격을 갖춘 vLEI 발급기관인 QVI·Qualified vLEI Issuer가 관련 검증을 거쳐 발급한다.

공식 프레임워크는 인물의 신원뿐 아니라 암호학적 식별자와 지갑의 통제도 확인하도록 다룬다. 역할 역시 공개 자료나 요구되는 조직 문서 등을 통해 검증하는 절차가 있다. GLEIF OOR Credential Framework

이름과 직함을 입력한 프로필을 그대로 인정하는 구조와는 차이가 있다.

ECR: 업무 맥락의 역할

ECR은 Engagement Context Role이다.

공식 직책 외에 기능적·업무상 맥락의 역할을 표현한다. 예를 들어 특정 업무의 담당자나 연락 창구를 증명하는 활용을 생각할 수 있다.

GLEIF 프레임워크상 ECR은 법적 실체가 직접 발급·철회하거나, QVI가 관련 서비스를 제공할 수 있다. GLEIF 자격증명 프레임워크 안내

정리하면 다음과 같다.

‘임원인가?’와 ‘이번 업무를 담당하도록 지정됐는가?’는 서로 다른 질문이다.

7. 역할을 증명하면 모든 거래를 승인할 수 있을까?

여기서 가장 조심해야 할 부분이 있다.

역할을 확인하는 것과 구체적인 거래를 허용하는 것은 별도의 판단이다.

어떤 사람이 기업의 재무 관련 역할을 갖고 있다고 해도 다음 조건까지 자동으로 충족되는 것은 아니다.

• 모든 금액의 지급을 단독 승인할 수 있는가?
• 이번 계약이 담당 업무 범위에 포함되는가?
• 다른 승인자의 동의도 필요한가?
• 현재 조직의 내부 정책과 법적 제한을 충족하는가?

예를 들어 서비스에서 다음과 같은 정책을 정할 수 있다.

조직과 역할 증명 확인
          ↓
허용된 업무 범위 확인
          ↓
거래 금액 및 추가 승인 조건 확인
          ↓
이번 요청의 실행 허용 여부 결정

이는 이해를 위한 설계 예시이며 vLEI의 표준 처리 순서를 그대로 옮긴 것은 아니다.

역할 자격증명은 이런 판단에 필요한 근거를 제공할 수 있다. 하지만 최종적으로 어떤 행위를 허용할지는 검증 서비스의 정책과 적용되는 법적·계약적 조건에 연결해야 한다.

8. 전자서명이나 인증서와는 무엇이 다를까?

전자서명과 vLEI는 함께 사용할 수 있는 개념이다.

암호학적 서명 검증은 특정 키와 연결된 서명인지, 서명 대상이 변경됐는지 등을 확인하는 데 사용된다. 서명자를 어떤 현실의 신원과 연결하는지는 인증서나 다른 신뢰 체계의 검증이 필요하다.

기업 거래에서는 여기에 다음 질문이 추가된다.

“이 서명자가 어떤 기업에서 어떤 역할로 서명했는가?”

vLEI 체계는 이런 조직·역할 정보를 검증 가능한 형태로 연결하는 데 초점을 둔다.

다만 기존 인증서에도 조직 관련 정보를 담을 수 있다. GLEIF 역시 디지털 인증서에 LEI를 포함하는 방식을 별도로 다룬다. 따라서 기존 인증서는 기업 신원을 전혀 다루지 못하고 vLEI만 가능하다고 설명하면 부정확하다. GLEIF: LEI in Digital Certificates

비교할 때는 기술 이름보다 다음 항목을 확인하는 편이 유용하다.

vLEI를 사용했다는 사실만으로 모든 국가의 법적 서명 요건이 자동 충족되는 것도 아니다.

9. DID·VC와는 어떻게 연결될까?

앞선 디지털 신원 글에서 DID와 VC를 살펴봤다면, vLEI도 비슷한 문맥으로 이해할 수 있다.

다만 검증 가능한 자격증명이라는 일반 개념과 특정 데이터 형식을 구분해야 한다.

vLEI는 KERI와 ACDC 등을 기반으로 하는 기술 체계를 사용한다. GLEIF의 기술 요구사항은 자격증명과 관련 프로토콜의 준수 조건을 정의한다. GLEIF vLEI Technical Requirements

큰 역할만 구분하면 다음과 같다.

따라서 W3C VC를 지원하는 지갑이나 DID를 사용하는 시스템이라고 해서 vLEI를 곧바로 처리할 수 있다고 가정해서는 안 된다.

실제로 지원하는 자격증명 형식, 제출 방식, 검증기, 신뢰 기준을 확인해야 한다.

10. 실제 서비스에서는 어떻게 활용할 수 있을까?

다음은 협력사 등록 서비스를 가정한 설계 예시다. 특정 기업의 실제 도입 사례는 아니다.

1단계: 계약 상대를 식별한다

협력사의 LEI를 받아 공식 명칭과 등록정보를 조회한다. 신청자가 입력한 정보와 비교해 계약 대상이 어느 법적 실체인지 확인한다.

2단계: 담당자의 조직 관계를 확인한다

지원되는 환경이라면 담당자의 vLEI 역할 자격증명을 요청한다. 발급 근거와 유효성을 검증하고, 신청 대상 기업과 일치하는지 확인한다.

3단계: 업무 정책을 적용한다

확인한 역할이 협력사 등록이나 계약 요청에 적합한지 판단한다. 필요한 경우 별도의 승인이나 추가 문서를 요구한다.

4단계: 변경과 철회를 반영한다

담당자가 퇴사하거나 역할이 바뀌었을 때 접근 권한을 갱신한다. 과거에 통과했다는 이유만으로 계속 권한을 유지하지 않도록 한다.

이 구조에서 기대할 수 있는 것은 반복적인 자료 확인의 일부를 기계 검증으로 연결하는 것이다. 실제 시간 단축이나 위험 감소는 연동 범위와 운영 품질에 따라 검증해야 한다.

LEI가 없는 상대방이나 vLEI를 지원하지 않는 조직도 고려해야 한다. 모든 거래처가 참여한다는 전제로만 서비스를 만들면 도입 자체가 어려워질 수 있다.

11. 개발자가 놓치기 쉬운 운영 문제

기업 신원 기능을 구현할 때는 조회 성공과 서명 검증 성공 외에도 살펴볼 것이 많다.

공개된 LEI를 인증 수단으로 사용하지 않기

LEI는 공개 정보다. 입력값이 실제 레코드와 일치하는지는 확인할 수 있어도, 입력한 사람이 해당 기업의 관계자인지는 추가 증거가 필요하다.

최신 상태와 판단 시점을 구분하기

현재 자격의 유효성을 확인하는 문제와, 과거 특정 시점의 행위가 적절했는지 확인하는 문제는 다르다.

감사 기록에는 어떤 증거와 상태를 언제 확인했는지 남기는 설계를 고려할 수 있다.

철회를 서비스 권한에 연결하기

조직에서 역할 자격증명을 철회했어도 서비스가 오래된 결과를 계속 사용하면 의도한 통제가 작동하지 않는다.

캐시와 세션의 유지 기간, 재검증 시점, 장애 발생 시 처리 방침을 정해야 한다.

실패한 검증을 자동 승인하지 않기

네트워크 오류와 실제 자격 문제를 구분하고, 확인할 수 없는 경우에 어떤 추가 절차를 사용할지 정한다.

개인정보를 필요한 범위로 처리하기

조직 식별정보가 공개돼 있다고 해서 사람의 정보와 활동 기록을 제한 없이 저장해도 되는 것은 아니다. 기업 정보와 개인의 역할·행위 기록을 구분해서 다뤄야 한다.

이 목록은 구현을 위한 설계 제안이다. 공식 거버넌스 역시 가용성, 자격증명 유효성, 조직의 관리 책임 등 운영 위험을 별도로 다룬다. GLEIF vLEI Risk Assessment

12. 기업을 식별하는 것에서 기업의 행위를 검증하는 것으로

LEI는 여러 시스템에서 같은 법적 실체를 가리키는 기준을 제공한다. vLEI는 여기에 사람과 조직 역할의 검증을 연결한다.

하지만 기업의 신원, 담당자의 역할, 거래의 허용 여부는 끝까지 구분해야 한다.

LEI가 있다고 신용도가 보장되지는 않는다. 유효한 역할 자격증명이 있다고 모든 계약을 체결할 수 있는 것도 아니다. 제재 확인, 실소유자 확인, 거래 위험 평가처럼 별도로 수행해야 할 판단도 남는다.

기업 신원 서비스를 설계할 때 필요한 질문은 구체적이다.

어느 조직을 상대하고 있는가? 요청한 사람의 역할을 어떤 근거로 확인했는가? 그 역할로 이번 행위를 허용해도 되는가?

이 세 질문에 대한 증거와 정책을 연결할 때, 기업 신원은 조회용 정보에서 실제 거래를 지원하는 기반으로 확장될 수 있다.

참고 자료

• GLEIF — The Legal Entity Identifier
• GLEIF — Level 2 Data: Who Owns Whom
• GLEIF — How to Use LEI Search
• GLEIF — The Verifiable LEI
• GLEIF — vLEI Ecosystem Governance Framework
• GLEIF LEI 검색

온라인에서 “내가 누구인지”를 증명하는 일은 로그인보다 넓은 문제다.

우리는 온라인에서 여러 종류의 증명을 요구받는다.

서비스에 로그인할 때는 계정의 주인임을 증명한다. 금융 서비스를 이용할 때는 실제 신원을 확인한다. 학생 할인을 받을 때는 재학 여부를, 연령 제한 서비스를 이용할 때는 나이 조건을 충족하는지 증명한다.

모두 비슷해 보이지만 확인하려는 내용은 다르다.

계정을 통제한다는 사실, 현실의 특정 인물이라는 사실, 어떤 자격을 갖췄다는 사실은 각각 별도의 주장이다.

디지털 신원을 이해하려면 이 차이부터 살펴볼 필요가 있다. 이 글에서는 기본 개념을 정리한 뒤 DID, 검증 가능한 자격증명, 디지털 지갑, 유럽의 eIDAS 2.0이 어떻게 연결되는지 알아본다.

1. 디지털 신원이란 무엇일까?

디지털 신원은 온라인 환경에서 어떤 주체를 구분하고, 그 주체에 관한 정보를 표현하는 데 사용된다.

사람을 예로 들면 다음과 같은 정보가 관련될 수 있다.

• 서비스 안에서 사용하는 계정 식별자
• 이름이나 생년월일 같은 속성
• 재학·재직·면허 보유 여부
• 계정과 연결된 인증 수단

모든 서비스가 이 정보를 전부 필요로 하는 것은 아니다.

익명 게시판에서는 같은 계정이 다시 방문했는지만 확인하면 될 수 있다. 반면 면허가 필요한 서비스를 제공한다면 사용자가 유효한 자격을 갖췄는지 확인해야 한다.

NIST의 디지털 신원 지침도 신원확인, 인증, 연합 신원을 구분하고, 서비스의 위험에 맞는 보증 수준을 선택하도록 설명한다. 이 지침은 미국 정부 정보시스템을 주된 대상으로 하지만 개념을 구분하는 데 유용하다. NIST SP 800-63-4

중요한 설계 질문은 다음과 같다.

이 서비스는 사용자의 무엇을, 어느 정도 확실하게 알아야 할까?

2. 식별·신원확인·인증·인가는 서로 다르다

한국어에서는 여러 과정을 모두 ‘인증’이라고 부르는 경우가 많다. 하지만 시스템을 설계할 때는 구분하는 편이 정확하다.

위 표는 개념을 이해하기 위한 구분이다. 실제 제품의 용어와 절차는 다를 수 있다.

신원확인: 증거와 사람을 연결하는 과정

신분증 이미지 한 장을 받았다고 신원확인이 완료되지는 않는다.

신청자가 주장하는 신원을 구분하고, 제출된 증거가 유효한지 확인하며, 신청자가 그 증거의 정당한 소유자인지도 연결해야 한다.

NIST는 이를 resolution, validation, verification으로 나누어 설명한다. 문서가 진짜인지 확인하는 일과 그 문서를 제출한 사람이 실제 주인인지 확인하는 일은 별개다. NIST SP 800-63A-4

인증: 등록된 인증 수단의 통제를 확인하는 과정

로그인 인증에서는 비밀번호, 보안키, 패스키 등 계정에 연결된 인증 수단을 확인한다.

여기서 인증이 강력하더라도, 최초에 계정과 현실의 인물을 연결하는 절차가 약했다면 그 문제가 자동으로 해결되지는 않는다. 반대로 처음 신원을 철저히 확인했어도 로그인 수단이 탈취되면 계정이 악용될 수 있다. NIST SP 800-63B-4

예를 들어 실명확인을 하지 않는 서비스에서 패스키로 계정을 만들 수 있다. 패스키는 안전한 계정 접근을 지원하지만, 그 계정의 실명까지 새로 증명하는 것은 아니다.

인가: 인증 이후에도 남는 판단

직원 계정으로 로그인했다고 모든 회사 문서에 접근할 수 있는 것은 아니다.

직원이라는 사실과 급여 정보를 열람할 권한은 구분해야 한다. 따라서 시스템에는 신원과 인증 결과를 바탕으로 접근 권한을 결정하는 정책이 필요하다.

3. 디지털 신원은 어떻게 전달될까?

신원정보를 다루는 구조는 하나만 존재하지 않는다. 다음 세 가지 방식으로 나누어 보면 이해하기 쉽다.

서비스가 직접 관리하는 방식

서비스가 계정과 인증 수단을 직접 관리한다.

사용자 → 서비스 로그인 → 서비스가 인증

다른 신원 제공자의 인증 결과를 사용하는 방식

사용자가 외부 신원 제공자에서 인증하고, 서비스는 그 결과를 받아들인다.

사용자 → 신원 제공자에서 인증
                    ↓
             서비스가 결과 수신

이런 연합 신원 구조에서 널리 쓰이는 기술이 OpenID Connect, 즉 OIDC다. OIDC는 OAuth 2.0을 기반으로 사용자 인증과 사용자 관련 주장인 클레임을 전달하는 규격이다.

다만 OIDC를 사용한다는 사실만으로 법적 실명이 확인됐다는 뜻은 아니다. 전달된 정보와 신원 제공자의 확인 절차를 함께 봐야 한다. OpenID Connect Core

사용자가 자격증명을 보관하고 제출하는 방식

발급기관이 만든 자격증명을 사용자가 보관하고, 필요한 서비스에 제시한다.

발급기관 → 사용자에게 자격증명 발급
                        ↓
                 사용자가 서비스에 제출

이 구조를 이해하는 데 필요한 개념이 검증 가능한 자격증명과 디지털 지갑이다.

세 방식은 실제 서비스에서 함께 사용될 수도 있다. 지갑으로 자격을 제출한 뒤 서비스 계정에 연결하고, 이후에는 패스키로 로그인하는 구성을 생각할 수 있다.

4. DID는 무엇을 해결할까?

DID는 Decentralized Identifier, 분산 식별자를 뜻한다.

형태는 다음과 같다.

did:example:123456789abcdefghi

설명용 예시이며, 세 부분으로 구성된다.

did : method : method-specific identifier

여기서 메서드는 식별자를 생성하고 해석하는 구체적인 방식을 정한다.

DID는 DID 문서와 연결되며, 문서에는 공개키 등 검증에 필요한 정보나 서비스 엔드포인트가 포함될 수 있다. 이를 통해 식별자와 관련된 암호학적 증명을 확인할 수 있다. W3C DID Core

DID를 만들었다고 실명이 증명되지는 않는다

어떤 사람이 DID를 만들고 관련 키로 서명했다고 가정하자.

그 증명으로 확인할 수 있는 것은 해당 식별자에 연결된 키를 통제한다는 사실이다. 이름, 학위, 재직 여부 같은 현실의 속성은 별도의 근거가 필요하다.

또한 DID 표준은 특정 블록체인을 필수로 요구하지 않는다. 저장·해석·키 변경·복구 방식은 메서드에 따라 달라진다. 식별자의 통제를 분산하는 것과 자격을 판단하는 기관의 역할을 없애는 것도 서로 다른 문제다. W3C DID Core

5. VC는 ‘누가 무엇을 증명했는지’를 표현한다

VC는 Verifiable Credential, 검증 가능한 자격증명이다.

발급기관의 주장을 기계가 처리하고 암호학적으로 검증할 수 있도록 표현한다. 예를 들어 대학은 어떤 사람이 해당 대학의 졸업생이라고 증명할 수 있다.

W3C의 VC 모델에는 세 가지 주요 역할이 있다.

보유자와 자격증명의 대상은 이 예시에서는 같지만, 항상 같아야 하는 것은 아니다. W3C VC Data Model 2.0

서명이 맞아도 내용까지 자동으로 참이 되지는 않는다

누구나 자신이 만든 문서에 서명할 수 있다. 따라서 서명 검증에 성공했다는 사실만으로 그 발급자가 대학이거나 면허 발급 권한을 가진 기관이라고 판단할 수는 없다.

검증자는 발급자를 신뢰할 근거와 해당 자격을 발급할 권한을 확인해야 한다. 적용되는 유효기간·상태 정보와 서비스 정책도 함께 검토해야 한다.

W3C 표준도 검증 가능성이 내부 주장의 진실성을 뜻하지 않는다고 명시한다. 암호학적 검증과 업무상 신뢰 판단이 함께 필요하다. W3C VC의 신뢰 모델

6. 디지털 지갑은 어떤 역할을 할까?

디지털 신원 지갑은 자격증명을 보관하고 제출하는 사용자 인터페이스가 될 수 있다.

학교에서 받은 재학 증명, 기관에서 받은 자격 증명 등을 보관하고, 서비스가 요청한 정보를 확인한 뒤 제출하는 방식이다. 교육·고용 등 다양한 활용 사례가 W3C 문서에도 정리돼 있다. W3C VC Use Cases

단순히 문서 이미지를 저장하는 것보다 중요한 기능은 요청과 제출의 맥락을 처리하는 일이다.

예를 들어 학생 할인 서비스라면 다음 흐름을 설계할 수 있다.

서비스: 학생 자격 증명 요청
           ↓
지갑: 요청 기관과 제출할 정보 표시
           ↓
사용자: 제출 내용 확인
           ↓
지갑: 요청에 맞는 증명 제출
           ↓
서비스: 검증 후 할인 정책 적용

이는 이해를 위한 예시다. 구체적인 절차는 지갑과 자격증명 형식에 따라 달라진다.

자격증명과 제출 프로토콜도 구분해야 한다

문서 형식을 정했다고 안전한 제출 절차까지 완성되는 것은 아니다.

검증 요청의 대상, 제출받을 서비스, 일회성 값인 nonce 등을 적절히 연결해야 과거 응답을 재사용하는 공격 등을 방어할 수 있다. OpenID for Verifiable Presentations는 이런 자격증명 요청·제출을 다루는 프로토콜이다. OpenID4VP 1.0

복사한 파일이나 캡처 화면을 보여주는 것과, 현재 요청에 연결된 증명을 제출하는 것은 다르다.

7. 개인정보를 덜 공개하면서 증명할 수 있을까?

서비스에 필요한 정보가 “특정 연령 이상인가?”라면 전체 생년월일과 주소까지 전달할 필요는 없을 수 있다.

학생 할인도 이름·학번·학과를 모두 수집하기보다 유효한 학생 자격만 확인하는 방향을 고려할 수 있다.

이때 구분해야 할 개념이 있다.

선택적 공개와 조건 충족 증명은 기술적으로 같은 기능이 아니다. 예를 들어 발급기관이 처음부터 ‘특정 연령 이상’이라는 속성을 발급하는 방법과, 생년월일을 숨긴 채 계산 결과를 증명하는 방법은 다르다.

또한 VC나 지갑이라는 이름만으로 이런 기능이 자동 제공되지는 않는다. 사용하는 형식과 암호 기술, 발급·제출 방식에 맞춰 구현해야 한다.

개인정보 보호를 설계할 때는 공개하는 항목뿐 아니라 반복 사용되는 식별자와 제출 메타데이터도 살펴봐야 한다. W3C 역시 데이터 최소화와 정보의 결합을 통한 추적 위험을 다룬다. W3C VC 개인정보 보호 고려사항

8. eIDAS 2.0은 기술을 제도적 신뢰와 연결한다

DID와 VC가 기술적 구성 요소라면, eIDAS 2.0은 전자 신원과 신뢰서비스에 관한 유럽의 법적·제도적 체계다.

일반적으로 eIDAS 2.0이라고 부르는 개정 체계는 기존 eIDAS를 확장하며, 핵심 요소 중 하나로 European Digital Identity Wallet, EUDI Wallet을 도입한다.

목표는 회원국이 제공하는 디지털 신원을 바탕으로 국경을 넘는 공공·민간 서비스 이용과 속성 증명을 지원하는 것이다. EU 집행위원회: EUDI Regulation

하나의 유럽 계정으로 통합하는 구상일까?

EU 집행위원회는 각국의 디지털 신원을 하나로 대체하는 것이 목적은 아니라고 설명한다. 회원국의 신원 체계를 바탕으로 지갑의 기능과 상호운용성을 확장하는 접근이다.

사용자 이용은 자발적이라는 원칙도 중요하다. EU 집행위원회 공식 Q&A

도입 일정은 어떻게 봐야 할까?

2026년 10월 16일 기준, EU 집행위원회는 회원국이 2026년 말까지 지갑을 제공하도록 하는 일정을 안내한다. 이 일정만으로 모든 국가와 민간 서비스가 이미 동일한 수준으로 운영 중이라고 판단해서는 안 된다. EU 공식 도입 일정

또한 DID 구현이나 W3C VC 형식을 사용한다는 사실만으로 eIDAS의 법적 효력이 자동으로 부여되지는 않는다. 기술 규격 준수와 법적 요건 충족은 각각 확인해야 한다.

9. 전체 구조를 한 번에 연결해 보기

지금까지의 개념은 다음처럼 배치할 수 있다.

이 표는 구성 요소의 역할을 구분한 것이다. 모든 디지털 신원 시스템이 DID나 VC를 반드시 사용해야 한다는 뜻은 아니다.

예를 들어 대학이 학생 자격을 발급하는 서비스를 설계한다면 다음 질문이 이어진다.

1. 대학은 어떤 근거로 학생을 확인하는가?
2. 발급받는 지갑을 학생과 어떻게 연결하는가?
3. 할인 서비스는 그 대학을 왜 신뢰하는가?
4. 졸업이나 휴학 이후의 자격 변화를 어떻게 반영하는가?
5. 제출 과정에서 불필요한 개인정보가 노출되지 않는가?
6. 휴대전화를 잃었을 때 어떻게 복구하는가?

형식과 서명이 올바른지만으로 답할 수 없는 문제들이다.

10. 개발자가 실제로 설계해야 하는 부분

디지털 신원 기능을 구현할 때는 다음 세 가지를 먼저 구체화하면 좋다.

무엇을 확인할 것인가?

실명이 필요한지, 같은 계정인지 확인하면 되는지, 특정 자격만 있으면 되는지 정한다.

학생 할인 기능에 금융 서비스와 같은 수준의 정보를 요구해야 하는지는 따로 검토할 문제다.

누구의 증명을 인정할 것인가?

허용할 발급기관과 자격의 범위, 유효기간, 상태 확인 정책을 정한다.

같은 형식의 문서를 읽을 수 있어도 발급기관의 의미와 신뢰 기준이 다르면 상호운용이 완성되지 않는다.

실패와 복구를 어떻게 처리할 것인가?

정상적인 발급·제출 흐름과 함께 운영 시나리오를 설계한다.

• 기기 분실과 인증 수단 변경
• 자격 만료·철회·재발급
• 상태 조회 서비스 장애
• 잘못 발급된 정보의 정정
• 스마트폰 사용이 어려운 사람의 대체 경로

특히 복구 과정이 기존 통제보다 약하면 공격자가 그 경로를 이용할 수 있다. 신원확인과 인증을 설계할 때부터 복구와 예외 처리를 함께 고려해야 한다. NIST 인증 수단 생애주기 지침

디지털 신원 시스템의 품질은 필요한 사실을 얼마나 적절하게 증명하고, 그 증명을 안전하게 사용하며, 문제가 생겼을 때 회복할 수 있는지에서 드러난다.

참고 자료

• NIST — Digital Identity Guidelines
• W3C — Decentralized Identifiers v1.0
• W3C — Verifiable Credentials Data Model v2.0
• OpenID Foundation — OpenID for Verifiable Presentations 1.0
• European Commission — European Digital Identity Regulation

개발과 인프라 관련 글을 읽다 보면 Ops로 끝나는 용어를 자주 만나게 된다.

DevOps를 이해했다고 생각하면 DevSecOps가 등장하고, AI 이야기를 따라가다 보면 AIOps와 AISecOps까지 나온다. 이름만 보면 기존 개념에 단어를 하나씩 붙인 것처럼 느껴진다.

하지만 구분하는 기준은 의외로 명확하다.

어떤 업무를 연결하는지, AI를 어디에 사용하는지, 무엇을 보호하려는지를 보면 된다.

이 글에서는 네 가지 용어를 비교하고, 하나의 서비스를 개발하고 운영하는 상황에서 각각 어떤 역할을 하는지 살펴본다.

1. 먼저 전체 그림부터 보기

여기서 AISecOps는 사용하는 조직과 자료에 따라 의미가 달라질 수 있다. 어떤 곳은 AI 기반 보안 분석을, 다른 곳은 AI 시스템과 에이전트를 안전하게 운영하는 활동을 강조한다.

따라서 이 용어를 접하면 먼저 “AI로 보안을 하는가, AI 자체를 보호하는가?”를 확인하는 편이 좋다. 실제로 AISecOps Interceptor 프로젝트는 실행하는 AI 시스템의 런타임 거버넌스에 초점을 맞춘다. 이는 해당 프로젝트의 정의로 이해해야 한다.

2. DevOps: 개발과 운영이 서비스의 전체 흐름을 함께 책임진다

개발팀이 기능을 완성해 운영팀에 전달했다고 가정해 보자.

개발 환경에서는 잘 동작했는데 실제 서버에서는 오류가 발생한다. 운영팀은 배포 정보를 충분히 전달받지 못했고, 개발팀은 운영 환경을 정확히 모른다.

이런 단절을 줄이기 위해 개발과 운영의 협업을 강조하는 접근이 DevOps다.

DevOps는 도구와 자동화뿐 아니라 팀이 책임을 공유하고 운영 결과를 개발에 반영하는 방식까지 포함한다. CI/CD는 이를 구현하는 대표적인 수단이다. IBM의 DevOps 설명

예를 들어 다음과 같은 흐름을 만들 수 있다.

코드 변경
   ↓
자동 빌드 및 테스트
   ↓
배포 준비
   ↓
서비스 배포
   ↓
운영 상태 확인
   ↓
다음 변경에 반영

이 글의 예시에서 중요한 변화는 “배포가 끝났다”의 기준이다.

파일을 서버에 올리는 것으로 끝내지 않고, 사용자 요청이 정상적으로 처리되는지까지 확인한다. 문제가 생기면 변경 사항을 추적하고 복구할 수 있어야 한다.

DevOps를 도입할 때는 다음 질문이 유용하다.

• 동일한 코드를 같은 방식으로 다시 배포할 수 있는가?
• 어떤 변경이 언제 배포됐는지 추적할 수 있는가?
• 장애가 생겼을 때 개발팀과 운영팀이 같은 정보를 보는가?
• 문제가 있는 배포를 되돌릴 수 있는가?

이 질문에 답하는 과정이 도구의 개수보다 중요하다.

3. DevSecOps: 개발과 운영의 흐름에 보안을 통합한다

배포가 빨라지면 보안 검토 방식도 달라져야 한다.

개발이 모두 끝난 뒤 보안팀이 한 번 검토하는 방식으로는, 자주 변경되는 서비스의 위험을 따라가기 어렵다.

DevSecOps는 설계·개발·테스트·배포·운영 전반에 보안을 통합하고, 개발팀·보안팀·운영팀이 책임을 공유하는 접근이다. IBM의 DevSecOps 설명

예시 파이프라인은 다음처럼 확장할 수 있다.

설계 및 위협 검토
   ↓
코드 작성
   ↓
테스트 + 코드·의존성·비밀정보 검사
   ↓
배포 구성 검토
   ↓
정책에 따른 배포
   ↓
운영 중 탐지 및 취약점 대응

여기서 각 검사는 서로 다른 문제를 찾는다.

이 표는 구현 활동을 이해하기 위한 예시다. 모든 조직이 동일한 도구나 순서로 구성해야 한다는 뜻은 아니다.

또한 스캐너를 연결했다고 보안 문제가 자동으로 해결되지는 않는다. 검사 결과를 누가 검토하고, 어떤 기준으로 수정하며, 예외를 언제 재검토할지까지 정해야 실제 업무가 된다.

예를 들어 취약점이 발견됐을 때 다음 정보가 있으면 판단하기 쉽다.

• 해당 서비스에서 문제가 되는 기능을 실제로 사용하는가?
• 외부에서 접근할 수 있는가?
• 수정된 버전이 있는가?
• 즉시 수정하기 어렵다면 적용할 완화 조치가 있는가?

DevSecOps는 이런 판단을 개발과 운영 흐름 안에서 지속하는 방식으로 이해하면 된다.

4. AIOps: AI를 활용해 IT 운영 데이터를 분석한다

AIOps는 일반적으로 Artificial Intelligence for IT Operations를 의미한다.

로그, 메트릭, 이벤트 등 운영 데이터를 분석해 중요한 이상 신호를 찾고, 연관된 문제를 묶거나 장애 원인 후보를 좁히는 데 AI와 머신러닝을 활용한다. 생성형 AI가 반드시 필요한 개념은 아니다. IBM의 AIOps 설명

여기서 자주 생기는 혼동이 있다.

AIOps의 기본 의미는 ‘AI 모델을 운영하는 일’이 아니라, ‘IT 운영에 AI를 활용하는 일’이다.

예를 들어 쇼핑몰에서 다음 알림이 동시에 발생했다고 하자.

상품 API 응답 지연
결제 API 타임아웃
DB 연결 대기 증가
일부 애플리케이션의 CPU 사용률 상승

담당자는 각각의 알림을 조사해야 한다. 하지만 모두 하나의 문제에서 파생됐을 수도 있다.

AIOps의 대표적인 활용은 이런 이벤트의 시간과 관계를 분석해, 같은 장애와 관련될 가능성이 높은 신호를 모으는 것이다. AIOps의 이벤트 연관 분석

이 사례에서 운영자가 받고 싶은 결과는 다음과 같다.

관측된 현상:
여러 API에서 같은 시간대에 지연 발생

우선 확인할 대상:
DB 연결 대기 증가

추가 확인:
최근 배포와 연결 설정 변경 여부

이 결과는 조사할 가설이다. AI가 원인을 확정했다고 받아들이기보다는 실제 지표와 변경 이력을 확인해야 한다.

실무에서 시도해 볼 만한 적용 범위는 다음과 같다.

• 반복되는 알림을 묶어 전달하기
• 장애 관련 로그를 찾아 요약하기
• 최근 배포와 이상 발생 시점을 비교하기
• 담당 팀에 조사 자료를 모아 전달하기

처음에는 분석과 추천부터 시작하고, 검증 결과에 따라 자동 조치 범위를 늘리는 구성을 고려할 수 있다.

5. AISecOps: AI로 보안을 운영하는가, AI를 안전하게 운영하는가?

AISecOps를 이해할 때는 두 가지 방향을 나눠 보면 편하다.

이 구분은 이 글에서 혼동을 줄이기 위해 사용하는 설명 방식이다.

5-1. AI를 활용한 보안 운영

첫 번째 방향은 보안 담당자의 분석과 대응에 AI를 활용하는 것이다.

예를 들어 여러 경보를 요약하거나, 의심스러운 활동의 조사 순서를 제안하고, 보안 로그를 조회할 쿼리 작성을 돕는 방식이다.

Microsoft Security Copilot도 사고 대응, 위협 헌팅, 정보 수집, 보안 상태 관리 등을 지원하는 생성형 AI 보안 솔루션으로 설명된다. Microsoft 공식 문서

가상의 계정 침해 조사에서는 다음과 같이 활용할 수 있다.

로그인 및 보안 이벤트 수집
   ↓
AI가 사건의 시간 순서 요약
   ↓
추가 조사 항목 제안
   ↓
담당자가 근거 확인
   ↓
계정 보호 및 대응

AIOps와 데이터 분석 방식이 겹칠 수 있지만, 이 예시의 목표는 보안 사고 조사다.

5-2. AI 시스템 자체의 보안 운영

두 번째 방향은 AI 서비스와 에이전트를 보호하고 통제하는 것이다.

AI 시스템도 일반 소프트웨어와 마찬가지로 접근 통제와 기반 인프라 보안이 필요하다. 여기에 모델, 데이터, 입력과 출력 등 AI와 관련된 위험을 함께 고려해야 한다. NIST도 일반적인 사이버보안 위험과 AI 고유의 위험이 겹친다고 설명한다. NIST의 AI 보안·복원력 설명

특히 에이전트가 외부 도구를 실행하면, 잘못된 판단이 실제 작업으로 이어질 수 있다.

예를 들어 운영 지원 에이전트가 로그를 읽는 권한과 서버 설정을 바꾸는 권한을 모두 가지고 있다고 하자. 외부 입력이나 도구 결과를 잘못 해석하면 의도하지 않은 변경을 시도할 수 있다.

OWASP는 과도한 기능, 권한, 자율성이 결합해 피해를 일으키는 위험을 Excessive Agency로 설명한다. OWASP: Excessive Agency

이런 시스템에서는 다음과 같은 운영 설계를 검토할 수 있다.

• 에이전트에 업무에 필요한 최소 권한만 부여하기
• 읽기 작업과 변경 작업의 권한을 구분하기
• 영향이 큰 작업에는 승인 절차 적용하기
• 도구 호출의 대상과 인자를 실행 전에 검증하기
• 실행 기록과 결과를 남기기
• 작업 횟수·시간·비용에 한도를 설정하기

핵심은 AI의 답변 품질과 함께 실제로 실행할 수 있는 행동의 범위를 관리하는 것이다.

6. 하나의 장애 상황에서 비교해 보기

이제 가상의 쇼핑몰에 결제 기능을 배포했다고 가정해 보자.

DevOps 관점

코드 변경이 테스트와 배포를 거쳐 서비스에 반영된다. 배포 후 결제 성공률과 오류율을 확인하고, 문제가 있으면 복구한다.

관심사는 변경을 전달하고 운영 결과를 반영하는 흐름이다.

DevSecOps 관점

결제 기능의 권한과 데이터 흐름을 검토한다. 코드와 의존성 등을 검사하고, 발견된 위험을 처리한 뒤 배포한다. 운영 중 발견된 취약점도 수정 흐름으로 연결한다.

관심사는 변경 과정과 운영 전반의 보안이다.

AIOps 관점

배포 이후 여러 서비스에서 발생한 알림을 분석한다. 결제 오류와 DB 대기 증가가 함께 발생했다면 관련성을 제시하고 조사할 대상을 좁힌다.

관심사는 운영 데이터에서 문제의 신호를 찾는 일이다.

AI 기반 보안 운영 관점

같은 시간대의 비정상 로그인과 권한 변경을 분석한다. 단순 장애 외에 침해 가능성도 조사한다.

관심사는 위협의 탐지와 조사다.

AI 시스템 보안 운영 관점

조사를 지원하는 에이전트가 어떤 로그를 읽고 어떤 명령을 실행할 수 있는지 통제한다. 결제 서비스 설정을 바꾸는 작업은 별도의 정책으로 검증한다.

관심사는 조사 도구로 사용되는 AI의 행동과 권한이다.

이처럼 하나의 서비스 안에서 여러 접근이 함께 적용될 수 있다.

7. MLOps와 LLMOps는 어디에 해당할까?

AIOps와 함께 자주 등장하는 용어가 MLOps와 LLMOps다.

MLOps는 머신러닝 모델을 실제 환경에서 개발·배포·관리하는 생애주기에 초점을 맞춘다. IBM도 AIOps와 MLOps를 이 기준으로 구분한다. IBM Developer의 Ops 비교

LLMOps는 보통 그중 LLM 기반 시스템의 평가와 운영을 강조할 때 사용한다.

대상을 기준으로 비교하면 이해하기 쉽다.

실제 조직에서는 이 업무들이 겹친다. 추천 모델을 배포하는 팀도 DevSecOps를 적용할 수 있고, LLM 서비스의 장애를 AIOps 도구로 분석할 수도 있다.

8. 우리 팀은 어디서부터 시작하면 좋을까?

도입 방향을 정할 때는 팀에서 반복되는 문제를 먼저 적어 보는 것을 권한다.

이 표는 도입을 위한 제안이다. AI를 적용하기 전에 데이터와 책임 범위가 정리돼 있는지도 함께 살펴봐야 한다.

서비스 이름이 시스템마다 다르고, 변경 이력이 남지 않으며, 담당자 정보도 없다면 AI 분석 결과를 검증하기 어렵다. 에이전트가 어떤 권한으로 작업하는지 모른다면 자동화 범위를 넓히기도 어렵다.

작게 시작하는 방법은 다음과 같다.

1. 반복되는 업무 하나를 선택한다.
2. 필요한 데이터와 담당자를 정한다.
3. 현재 걸리는 시간과 오류를 기록한다.
4. 자동화 또는 AI 보조를 적용한다.
5. 절약한 시간과 잘못된 결과를 함께 평가한다.
6. 검증된 범위부터 확대한다.

“AI를 도입했다”보다 “장애 조사에 필요한 자료를 모으는 시간이 줄었다”처럼 구체적인 결과를 확인하는 편이 유용하다.

9. 성과는 어떤 지표로 확인할까?

이 글에서 제안하는 평가 예시는 다음과 같다.

속도와 정확도를 함께 봐야 한다.

알림을 줄였지만 중요한 장애까지 숨겼다면 개선으로 보기 어렵다. 조사 보고서를 빨리 만들었어도 근거가 틀렸다면 검토 부담이 늘어난다. 에이전트의 작업 성공률이 높아도 허용 범위를 벗어났다면 통제를 다시 살펴봐야 한다.

팀이 원하는 결과를 먼저 정의해야 지표도 의미가 생긴다.

마치며

DevOps는 개발과 운영을 연결하고, DevSecOps는 그 흐름에 보안을 통합한다. AIOps는 운영 데이터를 분석하는 데 AI를 활용한다.

AISecOps는 자료마다 강조점이 다르므로 적용 범위를 확인해야 한다. 이 글에서는 AI를 활용한 보안 운영과 AI 시스템 자체의 보안 운영으로 나누어 살펴봤다.

앞으로 에이전트가 더 많은 도구를 실행하게 되면, 분석 결과를 검토하는 일과 실행 권한을 관리하는 일이 모두 중요해질 것이다.

새로운 용어를 도입할 때 우리 팀이 먼저 답해야 할 질문도 구체적이다.

어떤 업무를 개선하려는가? 어떤 근거로 효과를 확인할 것인가? 자동화에는 어디까지 권한을 줄 것인가?