뿡야의 IT 기록

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

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

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

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

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

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

이때 중심이 되는 개념이 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 검색