ISO 8583, 전 세계 결제를 이어주는 공통 언어

2025-07-056

요즘 지갑에서 현금을 꺼내는 일 얼마나 있으신가요? 아마 대부분은 플라스틱 카드 한 장을 꺼내거나 스마트폰을 단말기에 가져다 댈 겁니다. "결제되었습니다"라는 소리와 함께 단 몇 초 만에 끝나는 이 과정.

이렇게 서로 다른 카드사·은행·단말기 사이에서도 결제가 문제없이 이루어지는 건, 공통으로 합의된 규칙이 존재하기 때문입니다. 그리고 그 규칙이 바로 제가 최근 개발 과정에서 자주 마주쳤던 국제 표준 ISO 8583입니다.

이번 글에서는 이 표준이 어떤 역할을 하고, 어떤 방식으로 카드 결제를 가능하게 하는지 정리해 보겠습니다.

잠깐, ISO는 뭐고 8583는 뭘까?

ISO 는 'International Organization for Standardization', 즉 국제표준화기구의 약자입니다. 특정 국가나 단체에 속하지 않은 독립적인 국제기구로, 전 세계적으로 통용될 수 있는 '국제 표준'을 만들고 보급하는 역할을 합니다.

ISO가 없던 시대를 상상해 볼까요? 아마 모든 나라가 각기 다른 나사 규격, 다른 종이 크기를 사용했을 겁니다. A나라에서 만든 볼트를 B나라 너트에는 끼울 수 없고, C나라 프린터에는 D나라 용지가 맞지 않는 비효율이 넘쳐났겠죠. 우리가 일상적으로 사용하는 A4용지(ISO 216), 신용카드 크기 (ISO 7810) 등이 바로 이 ISO가 만든 표준 덕분에 전 세계 어디서나 동일하게 사용될 수 있는 것입니다.

이런 맥락에서 ISO 8583을 다시 보면, 그 의미가 명확해집니다.

  • ISO: 국제표준화기구가 제정한 국제 표준이라는 의미입니다.
  • 8583: 수많은 표준들 중에서 "금융 거래 카드에서 비롯된 메시지"라는 주제에 부여된 고유한 식별 번호입니다. 도서관의 도서 분류 번호처럼 말이죠.

결국 'ISO 8583'은 "전 세계 금융 기관들이 카드 거래 메시지를 주고받을 때 따라야 할 국제 표준 규칙집 제8583호" 라고 이해할 수 있습니다. 그렇다면 금융 분야에서는 왜 이런 통일된 규칙이 필요할까요?

모두가 제멋대로 말한다면? 국제 표준의 탄생

만약 금융 거래에 대한 표준이 없다면 어떨까요? 예를 들어, A 카드사는 카드번호를 메시지 맨 앞에 담아 보낼 수도 있고, B 은행은 거래 금액을 맨 앞에 담아 보내는 식으로 각자 다른 방식을 사용할지도 모릅니다. 단말기는 이 메시지를 받고 심각한 호환성 문제에 부딪히겠죠. "이 숫자가 대체 카드번호야, 금액이야?" 결국 전 세계의 결제 시스템은 서로 데이터를 해석하지 못해 정상적인 통신이 불가능해질 겁니다.

바로 이 문제를 해결하기 위해 ISO 8583이라는 공통의 약속이 만들어진 것입니다. 우리가 해외 여행지에서 한국에서 발급받은 카드로 문제없이 결제할 수 있는 것도 바로 이 덕분입니다.

ISO 8583의 출발점, MTI

ISO 8583 매시지를 열어보면 가장 먼저 MTI(Message Type Indicator) 라는 네 자리 숫자가 등장합니다.

처음에는 단순한 식별 코드라고 생각했지만, 각 자리수마다 명확한 역할이 부여된, 매우 체계적인 시스템이었습니다.

이 네 자리 숫자는 이 메시지가 무슨 목적으로 쓰였는지를 한눈에 알려줍니다.

첫 번째 숫자: 통신 규격의 버전(Version)

가장 첫 번째 숫자는 이 메시지가 어떤 버전의 규격을 따르는지를 명시합니다. 기술은 계속 발전하기 때문에, 과거의 마그네틱 카드 거래만 고려했던 초기 버전과 IC칩 거래 같은 복잡한 데이터를 처리해야 하는 최신 버전은 담을 수 있는 정보의 종류와 구조가 다릅니다.

이 버전 정보를 통해 수신 시스템은 메시지를 어떤 규칙에 따라 해석해야 할지 미리 알 수 있습니다.

  • 0xxx: ISO 8583:1987
  • 1xxx: ISO 8583:1993
  • 2xxx: ISO 8583:2003
  • 8xxx / 9xxx: 국가 또는 개별 기관의 자체 용도

두 번째 숫자: 대화의 주제(Message Class)

두 번째 숫자는 이 메시지의 가장 핵심적인 목적, 즉 '대화의 주제'가 무엇인지를 알려줍니다.

  • 승인(x1xx): 가장 흔한 경우로, "이 카드로 결제해도 되나요?"라고 카드사에 물어보는 단계입니다.
  • 금융 거래(x2xx): 승인 후, "이제 실제로 돈을 이체해 주세요."라고 요청하는 실제 자금 이동 단계입니다.
  • 거래 취소(x4xx): 방금 발생한 거래를 되돌릴 때 사용합니다.
  • 네트워크 관리(x8xx): 실제 결제와는 무관하게, "서버 잘 있니?", "통신 상태 괜찮아?" 와 같이 시스템 간의 연결 상태가 정상인지 확인할 때 사용합니다.

세 번째 숫자: 대화의 흐름 (Message Function)

대화의 주제가 정해졌다면, 이제 그 안에서 어떤 행동을 할 차례인지를 정의합니다.

  • 요청(xx0x)
    • 상대방에게 어떤 처리를 요구하는 메시지입니다.
    • 예: 0800은 네트워크 관리 요청, 0100은 승인 요청
  • 요청에 대한 응답(xx1x)
    • 요청에 대한 결과를 회신하는 메시지입니다.
    • 예: 0810은 네트워크 관리 요청(0800)에 대한 응답
  • 어드바이스(Advice , xx2x)
    • 사후 통지 성격을 가진 메시지입니다.
    • "이 거래가 이미 처리되었으니 참고하세요" 같은 의미로, 요청과는 달리 반드시 응답을 요구하지 않을 수도 있습니다.
    • 예: 오프라인 거래 후 카드사가 매입사에 거래 사실을 통보
  • 어드바이스 응답 (Advice Response, xx3x)
    • 어드바이스에 대해 수신 측이 응답하는 메시지입니다.

네 번째 숫자: 누가 말을 걸었나? (Message Origin)

마지막으로 이 대화를 누가 먼저 시작했는지를 알려줍니다. 보통 가맹점의 단말기 측에서 카드사로 요청을 보내는 경우가 대부분입니다.

  • 매입사/가맹점(xxx0): 단말기 측에서 시작된 메시지입니다.
  • 발급사(xxx2): 카드사 측에서 시작된 메시지입니다.

지금까지 설명한 내용을 표로 간략하게 요약하면 다음과 같습니다.

위치 이름 주요 값 예시
첫 번째 숫자 버전 0 (1987), 1 (1993), 2 (2003)
두 번째 숫자 클래스 1 (승인), 2 (금융), 4 (취소), 8 (관리)
세 번째 숫자 기능 0 (요청), 1 (응답)
네 번째 숫자 발생 위치 0 (매입사), 2 (발급사)

정리하면 MTI 0100은 “1987년 버전, 승인 요청, 가맹점이 시작한 메시지”라는 뜻입니다. 단 네 자리 안에 이렇게 많은 정보가 담겨 있습니다.

메시지의 핵심: 데이터 필드

MTI가 메시지의 성격을 알려주었다면, 이제 본문에는 실제 거래와 관련된 다양한 데이터가 담깁니다. ISO 8583에서는 이러한 요소들을 데이터 필드(Data Elements) 라고 부릅니다

카드 번호, 거래 금액, 승인 번호 등 거의 모든 결제 정보를 담을 수 있도록 최대 128(혹은 그 이상)의 필드가 정의되어 있으며, 상황에 따라 필요한 필드만 선택적으로 사용됩니다.

대표적인 필드는 다음과 같습니다.

  • 필드 1 (Secondary Bitmap Indicator): 추가 비트맵 존재 여부. 값이 세팅되면 필드 65~128이 뒤따른다는 뜻입니다.
  • 필드 2 (Primary Account Number, PAN): 카드 번호입니다.
  • 필드 4 (Amount, Transaction): 실제 거래가 발생한 금액입니다.
  • 필드 11 (System Trace Audit Number, STAN): 요청과 응답을 짝지어주기 위한 거래 고유 번호입니다.
  • 필드 39 (Response Code): "승인(00)", "잔액 부족(51)" 등 거래 결과를 알려주는 응답 코드입니다.
  • 필드 35 (Track 2 Data): 과거에 카드의 뒷면에 있는 검은색 마그네틱 선을 긁을 때 사용되던 데이터가 담기는 공간입니다. 보안에 취약하여 현재는 거의 사용되지 않습니다.
  • 필드 55 (ICC Data): 바로 요즘 우리가 사용하는 IC칩을 단말기에 꽂을 때 사용되는 데이터가 담기는 공간입니다. Track 2 데이터와는 비교할 수 없을 정도로 복잡하고 암호화된 정보를 담고 있어 훨씬 더 안전한 거래를 가능하게 합니다.

이처럼 각 필드는 저마다의 역할과 약속된 길이를 가지고 메시지에 포함됩니다.

위에서 소개한 것은 ISO 8583에서 자주 사용되는 일부 핵심 필드들에 불과합니다. 전체 필드 목록과 상세 설명은 Wikipedia ISO 8583 문서 를 참고하시면 더 깊이 있는 내용을 보실 수 있습니다.

필드 위치 안내서: 비트맵

문제는 모든 거래에서 128개 필드를 다 쓰지 않는다는 점입니다. 어떤 필드가 포함되어 있는지 알려주지 않으면, 수신 시스템은 데이터를 해석할 수 없습니다.

이를 해결하기 위해 ISO 8583은 비트맵(Bitmap) 이라는 방식을 사용합니다. 비트맵은 “이번 메시지에는 어떤 필드가 담겨 있다”를 미리 알려주는 체크리스트 역할을 합니다.

128개의 필드에 대응하는 128자리 이진수를 만들고, 포함된 필드의 자리에만 1을 세팅합니다. 예를 들어 필드 7, 11, 24, 39만 사용한다면 해당 위치만 1로, 나머지는 모두 0으로 표시됩니다.

수신 측은 메시지를 읽을 때 먼저 비트맵을 확인하고, 어떤 필드가 들어 있는지 파악한 뒤 본문 데이터를 해석하게 됩니다. 이 덕분에 메시지를 불필요하게 길게 만들지 않고도 필요한 데이터만 효율적으로 주고받을 수 있습니다

비트와 16진수로 표현되는 구조

앞서 ISO 8583은 최대 128개의 데이터 필드를 정의한다고 했습니다. 따라서 비트맵도 최대 128개의 자리를 표현해야 합니다. 하지만 실제 통신에서는 이를 64비트 단위(8바이트) 로 나누어 관리합니다.

  • 첫 번째 64비트 → 필드 1~64

  • 필드 1이 켜져 있으면 두 번째 64비트(65~128번 필드)가 이어짐

    즉, 항상 128비트를 전송하는 것이 아니라, 필요한 경우에만 확장되는 구조라 훨씬 효율적입니다.

예를 들어, 필드 7·11·24·39가 활성화된 경우 비트맵은 다음과 같은 이진수로 표현됩니다.

00000010 00100000 00000001 00000000
00000010 00000000 00000000 00000000

여기서 1로 표시된 위치가 활성화된 필드입니다.

  • 7번째 비트 → 필드 7 (전송 시각)
  • 11번째 비트 → 필드 11 (STAN)
  • 24번째 비트 → 필드 24 (기능 코드)
  • 39번째 비트 → 필드 39 (응답 코드)

다만 실제 통신 원문에서는 이렇게 긴 0과 1을 그대로 사용하지 않고, 사람이 보기 쉽도록 16진수 문자열로 변환합니다. 위의 이진수 비트맵은 다음과 같이 표현됩니다.

0220010002000000

처음 보면 암호처럼 보이지만, 이 16자리 16진수 문자열 안에는 “어떤 필드가 들어 있는지”에 대한 정보가 압축되어 들어 있습니다.

실제 ISO 8583 메시지 해석

이 모든 지식을 바탕으로, 제가 테스트하며 봤던 실제 통신 원문 하나를 해독해 봅시다.

ISO0110080002200100008000000704004209009753001ACS00001

  • ISO0110: 표준에서 정의한 부분이라기보다는, 기관마다 붙이는 헤더 영역입니다. 보통 뒤따를 메시지 길이나 포맷 식별자, 전송 채널 구분 값 등을 담습니다.
  • 0800: 네트워크 관리 요청입니다. (MTI)
  • 0220010000800000: "7, 11, 24, 41번 필드가 있습니다." (Bitmap)
  • 0704004209: (첫 번째 데이터) → 7번 필드: 07월 04일 00시 42분 09초
  • 009753: (두 번째 데이터) → 11번 필드: STAN 9753
  • 301: (세 번째 데이터) → 24번 필드: 기능 코드 301
  • ACS00001: (네 번째 데이터) → 41번 필드: 단말기 ID ACS00001

→ 해석: “단말기 ACS00001이 STAN 9753번으로 서버 상태 확인을 요청합니다.”

ISO 8583, 지금도 쓰일까?

그렇다면 오늘날에도 ISO 8583이 여전히 쓰이고 있을까요? 답은 그렇다입니다. 대부분의 카드 결제망은 여전히 ISO 8583을 기반으로 움직이고 있습니다. 이미 수십 년 동안 전 세계 금융기관과 VAN사, 카드사 인프라가 이 표준 위에 쌓여 있기 때문에, 안정성과 호환성을 고려하면 쉽게 대체하기 어렵습니다.

다만 모든 금융 메시징이 ISO 8583만 쓰이는 건 아닙니다. 해외 송금이나 실시간 계좌 이체와 같은 영역에서는 새로운 표준인 ISO 20022가 빠르게 자리잡고 있고, 일부 핀테크에서는 JSON 기반의 REST API가 도입되기도 합니다.

그럼에도 불구하고 카드 결제 분야에서는 ISO 8583이 여전히 사실상의 표준으로 자리잡고 있습니다. 이미 구축된 인프라와 전 세계적인 호환성 때문에, 새로운 대안과의 전환은 점진적으로만 이뤄질 수밖에 없습니다.

맺으며

단순한 카드 결제 과정 하나에 이렇게나 체계적이고 깊이 있는 약속들이 숨어있다는 사실이 놀라웠습니다. 누군가는 수십 년 전에 컴퓨터와 네트워크의 한계를 고려하며, 어떻게 하면 가장 효율적으로 오류 없이 금융 정보를 교환할 수 있을지 밤새 고민했을 겁니다.

그들의 고민이 담긴 이 'ISO 8583'이라는 표준 덕분에, 우리는 오늘도 전 세계 어디서든 아무런 불편함 없이 카드를 내밀 수 있는 것이겠죠. 우리가 누리는 편리함의 이면에는, 이처럼 보이지 않는 곳에서 세상을 움직이는 수많은 약속과 규칙이 있다는 것을 다시 한번 깨닫게 되는 시간이었습니다. 이런 멋진 시스템을 만들어낸 선배 개발자들에게 새삼 존경심이 듭니다.

© 2026 박건희