💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

투자은행(IB) 시스템을 이야기할 때 사람들은 흔히 화려한 트레이딩 화면이나 초저지연 매칭 엔진을 떠올립니다. 하지만 실제로 IB 부문의 시스템은 하나의 긴 파이프라인에 가깝습니다. 딜을 발굴하고, 실사하고, 가격을 매기고, 증권을 발행하고, 거래하고, 마지막에는 돈과 증권을 서로 맞바꾸는 결제(settlement)까지 이어지는 흐름 전체가 시스템으로 구현되어 있습니다.

이 글은 그 전체 흐름을 딜부터 결제까지 하나의 그림으로 이어 붙이는 데 초점을 둡니다. 특히 프론트/미들/백오피스라는 3계층 구조, 주문을 다루는 OMS와 실행을 다루는 EMS, 사전·사후 한도 관리, T+1 결제주기와 중앙청산소(CCP), 그리고 시세·레퍼런스·포지션이라는 데이터 계층까지를 다룹니다. 마지막에는 메인프레임과 배치로 대표되는 레거시를 이벤트 기반·스트리밍으로 현대화하는 방향도 정리합니다.

한 가지 먼저 밝혀 둘 점이 있습니다. 이 글은 일반적인 시스템·아키텍처 교육 자료이며, 투자 자문이나 법률 자문이 아닙니다. 결제주기, 청산 규칙, 보고 의무 같은 세부 사항은 관할 지역(jurisdiction)과 기관마다 다를 수 있습니다(may vary by jurisdiction and firm). 실제 구현이나 규제 적용은 반드시 소속 기관의 준법감시(compliance) 부서와 확인하시기 바랍니다. 이 글에서 제시하는 코드와 스키마는 개념 설명을 위한 예시일 뿐 그대로 운영에 사용하기 위한 것이 아닙니다.

IB 업무 도메인과 전체 흐름

IB의 업무를 크게 보면, 자본을 조달하려는 발행자(issuer) 쪽과 자본을 운용하려는 투자자(investor) 쪽을 연결하는 일입니다. 그 사이에서 은행은 자문하고, 증권을 인수·발행하고, 시장에서 거래를 중개하며, 자기 계정으로도 거래합니다. 이 모든 활동은 결국 "거래(trade)"라는 단위로 수렴하고, 그 거래는 반드시 결제로 마무리됩니다.

전체 흐름을 하나의 라이프사이클로 그리면 다음과 같습니다.

딜 소싱 실사 밸류에이션 발행 트레이딩 세틀먼트

(Sourcing) ──▶ (Due Diligence) ──▶ (Valuation) ──▶ (Issuance) ──▶ (Trading) ──▶ (Settlement)

│ │ │ │ │ │

│ 기회 발굴 │ 재무·법률· │ DCF, 상대가치 │ 프라이싱, │ 주문·실행, │ 매칭, 확인,

│ CRM, 파이프라인 │ 사업 실사 │ 리스크 평가 │ 북빌딩, │ 체결, 포지션 │ 청산, 대금·

│ │ 데이터룸(VDR) │ │ 배정 │ 반영 │ 증권 교환

▼ ▼ ▼ ▼ ▼ ▼

[프론트오피스] ─────────────────────────────────────▶ [미들오피스] ──────▶ [백오피스]

딜/거래 창출 리스크·통제 결제·정산·기록

앞쪽(소싱, 실사, 밸류에이션, 발행)은 자문·인수 업무에 가깝고, 뒤쪽(트레이딩, 세틀먼트)은 자본시장·세컨더리 마켓에 가깝습니다. 하나의 딜이 발행을 거쳐 시장에 나오면, 그때부터는 수많은 거래로 쪼개져 매일같이 트레이딩되고 결제됩니다. 즉 딜은 "한 번" 일어나지만, 그 결과물인 증권의 거래와 결제는 "계속" 일어납니다.

각 단계의 시스템 관점 특징을 정리하면 다음과 같습니다.

| --- | --- | --- | --- |

이 표에서 눈여겨볼 점은, 왼쪽으로 갈수록 저빈도·문서 중심이고 오른쪽으로 갈수록 고빈도·트랜잭션 중심이라는 것입니다. 그래서 시스템 설계의 강조점도 다릅니다. 앞단은 협업과 접근통제가, 뒷단은 정합성과 처리량이 핵심이 됩니다.

프론트/미들/백오피스 3계층 아키텍처

IB 시스템을 조직 관점에서 자를 때 가장 널리 쓰는 축이 프론트/미들/백오피스입니다. 이 3계층은 물리적 부서 구분이기도 하지만, 동시에 시스템 책임의 경계이기도 합니다.

┌───────────────────────────────────────────────────────────────────┐

│ FRONT OFFICE │

│ 수익을 창출하는 최전선. 딜·거래를 만들어 낸다. │

│ - 딜메이커/뱅커: 소싱, 실사, 밸류에이션, 발행 │

│ - 트레이더/세일즈: 호가, 주문, 실행 │

│ 시스템: CRM, 프라이싱, OMS, EMS, 마켓데이터 단말 │

└───────────────────────────────────────────────────────────────────┘

│ 거래 발생(trade capture)

▼

│ MIDDLE OFFICE │

│ 통제와 검증. 프론트가 만든 거래를 지키고 재단한다. │

│ - 리스크 관리: 시장/신용/유동성 리스크, 한도 감시 │

│ - 거래 검증: trade validation, P&L 산출 │

│ - 컴플라이언스: 규제 점검, 감시 │

│ 시스템: 리스크 엔진, 한도 관리, P&L 시스템 │

│ 검증된 거래(confirmed trade)

▼

│ BACK OFFICE │

│ 기록과 완결. 거래를 실제 돈·증권의 이동으로 마무리한다. │

│ - 세틀먼트: 매칭, 확인, 청산, 결제 │

│ - 회계·정산: 원장 기록, 대사(reconciliation) │

│ - 커스터디: 보관, 코퍼레이트 액션 │

│ 시스템: 세틀먼트 엔진, 원장, 대사 시스템 │

이 3계층의 책임을 비교하면 다음과 같습니다.

| --- | --- | --- | --- |

여기서 중요한 개념이 **한 거래가 세 계층을 통과하며 상태를 바꾼다**는 점입니다. 프론트에서 "체결"된 거래는, 미들에서 "검증"되고, 백에서 "결제"됩니다. 이 흐름을 매끄럽게 이어 주는 것이 이른바 STP(Straight-Through Processing), 즉 사람 개입 없이 거래를 처음부터 끝까지 자동으로 흘려보내는 무결점 처리입니다. STP율이 높을수록 오류와 지연이 줄어듭니다.

OMS와 EMS — 주문관리와 실행관리

프론트오피스 트레이딩의 심장은 두 시스템, OMS와 EMS입니다. 이름이 비슷해 헷갈리기 쉽지만 역할이 분명히 다릅니다.

- OMS(Order Management System, 주문관리시스템)는 "무엇을, 얼마나, 누구를 위해" 주문할지를 관리합니다. 포트폴리오 매니저의 지시를 받아 주문을 생성하고, 사전 한도 점검을 통과시키고, 체결 결과를 포지션과 회계에 반영합니다. 관점이 포트폴리오·컴플라이언스·기록에 있습니다.

- EMS(Execution Management System, 실행관리시스템)는 "어떻게" 주문을 시장에서 실행할지를 관리합니다. 여러 거래소·유동성 풀에 주문을 라우팅하고, 알고리즘(예: VWAP, TWAP)으로 잘게 쪼개 실행하며, 실시간 시세를 보며 체결 품질을 최적화합니다. 관점이 시장·속도·체결 품질에 있습니다.

두 시스템의 관계와 주문 흐름을 그리면 다음과 같습니다.

포트폴리오 매니저

│ 주문 의도(order intent)

▼

┌──────────────┐ 사전 한도 점검 OK ┌──────────────┐

│ OMS │ ─────────────────────▶ │ EMS │

│ 주문 생성 │ │ 스마트 라우팅 │

│ 사전 한도 점검 │ ◀───────────────────── │ 알고리즘 실행 │

│ 포지션 반영 │ 체결 보고(fills) │ 다중 거래소 │

└──────────────┘ └──────┬───────┘

│ │ 주문 라우팅

│ 체결→포지션·회계 ▼

▼ ┌──────────────┐

[미들·백오피스로] │ 거래소 / ECN / │

│ 다크풀 / CCP │

└──────────────┘

많은 기관에서 OMS와 EMS를 하나로 합친 OEMS를 쓰기도 합니다. 둘의 경계는 기관과 벤더에 따라 다를 수 있습니다. 아래 표로 핵심 차이를 정리합니다.

| 구분 | OMS | EMS |

| --- | --- | --- |

| 핵심 질문 | 무엇을, 얼마나 주문할까 | 어떻게 실행할까 |

| 주된 관점 | 포트폴리오, 컴플라이언스 | 시장, 체결 품질 |

| 대표 기능 | 주문 생성, 사전 한도, 포지션 | 라우팅, 알고리즘, 실시간 시세 |

| 지연 민감도 | 상대적으로 낮음 | 매우 높음 |

| 주 사용자 | PM, 미들오피스 | 트레이더 |

| 데이터 보존 | 장기(감사·기록) | 단기(실행 창) |

OMS 주문 상태 기계

주문은 살아 움직이는 객체입니다. 생성되고, 승인되고, 시장에 나가고, 부분·전량 체결되고, 취소되거나 거부됩니다. 이 상태 전이를 명확한 상태 기계(state machine)로 모델링하는 것이 OMS 설계의 핵심입니다. 아래는 개념을 보여 주는 파이썬 예시입니다.

from enum import Enum

class OrderState(Enum):

NEW = "new" # 생성됨(아직 미검증)

PENDING_RISK = "pending_risk" # 사전 한도 점검 대기

APPROVED = "approved" # 한도 통과, 실행 준비

ROUTED = "routed" # 시장/EMS로 전송됨

PARTIALLY_FILLED = "partially_filled"

FILLED = "filled" # 전량 체결

CANCELLED = "cancelled"

REJECTED = "rejected" # 한도 위반 등으로 거부

허용된 전이만 정의(그 외 전이는 오류)

ALLOWED = {

OrderState.NEW: {OrderState.PENDING_RISK, OrderState.REJECTED},

OrderState.PENDING_RISK: {OrderState.APPROVED, OrderState.REJECTED},

OrderState.APPROVED: {OrderState.ROUTED, OrderState.CANCELLED},

OrderState.ROUTED: {

OrderState.PARTIALLY_FILLED,

OrderState.FILLED,

OrderState.CANCELLED,

OrderState.REJECTED,

OrderState.PARTIALLY_FILLED: {

OrderState.PARTIALLY_FILLED,

OrderState.FILLED,

OrderState.CANCELLED,

}

def transition(current, target):

if target not in ALLOWED.get(current, set()):

raise ValueError(f"invalid transition: {current} -> {target}")

return target

예시: 정상 흐름

state = OrderState.NEW

state = transition(state, OrderState.PENDING_RISK)

state = transition(state, OrderState.APPROVED)

state = transition(state, OrderState.ROUTED)

state = transition(state, OrderState.PARTIALLY_FILLED)

state = transition(state, OrderState.FILLED)

print("최종 상태:", state.value)

이렇게 허용 전이를 명시하면, 예컨대 "이미 결제된 주문을 다시 라우팅"하는 것 같은 불가능한 상태 이동을 코드 레벨에서 막을 수 있습니다. 종착 상태(FILLED, CANCELLED, REJECTED)에서 더 이상 전이가 없다는 점도 중요합니다.

실행·체결 메시지 스키마

주문과 체결은 시스템 사이를 메시지로 오갑니다. 업계 표준은 FIX 프로토콜이지만, 내부 이벤트 버스에서는 JSON 같은 형식으로 표현하기도 합니다. 아래는 체결(execution report) 메시지를 개념적으로 표현한 예시입니다.

{

"message_type": "execution_report",

"order_id": "ORD-2026-0007781",

"client_order_id": "PM-ALPHA-4412",

"exec_id": "EXC-99381",

"symbol": "AAPL",

"side": "buy",

"order_qty": 10000,

"cum_qty": 6000,

"leaves_qty": 4000,

"last_qty": 2000,

"last_price": 231.45,

"avg_price": 231.10,

"currency": "USD",

"exec_type": "partial_fill",

"order_status": "partially_filled",

"venue": "XNAS",

"transact_time": "2026-07-01T14:32:05.123Z",

"settlement_date": "2026-07-02"

}

여기서 cum_qty(누적 체결), leaves_qty(잔량), avg_price(평균 체결가)는 부분 체결을 다룰 때 핵심 필드입니다. settlement_date가 거래일(transact_time)의 다음 영업일로 찍힌 점을 눈여겨보세요. 이것이 바로 뒤에서 다룰 T+1 결제주기입니다.

리스크와 한도 관리

거래가 많아질수록 통제가 없으면 위험이 순식간에 불어납니다. 그래서 미들오피스는 한도(limit)를 걸어 두고, 거래 전과 후에 이를 감시합니다. 이때 사전 한도(pre-trade limit)와 사후 한도(post-trade limit)를 구분하는 것이 중요합니다.

┌──────────────────────────────────────┐

주문 생성 ───▶ │ PRE-TRADE 한도 점검 │

│ - 주문 단위 최대 수량/금액 │

│ - 종목·섹터·통화별 익스포저 한도 │

│ - 신용 한도(카운터파티) │

│ 판정: 통과 → 실행 / 위반 → 거부·경고 │

└──────────────────┬───────────────────┘

│ 통과

▼

실행·체결

│

┌──────────────────▼───────────────────┐

포지션 갱신 ─▶│ POST-TRADE 한도 감시 │

│ - 누적 포지션·VaR·손실 한도 │

│ - 일중/일말 익스포저 │

│ 판정: 초과 → 알림·헤지·강제청산 검토 │

└──────────────────────────────────────┘

- 사전 한도는 주문이 시장에 나가기 전에 막는 "예방적" 통제입니다. 지연에 민감해서 매우 빠르게(보통 밀리초 단위) 판정해야 합니다. 그래서 한도 데이터는 메모리에 캐시해 두고 점검하는 경우가 많습니다.

- 사후 한도는 체결 이후 누적된 포지션·손익을 감시하는 "탐지적" 통제입니다. VaR(Value at Risk) 같은 리스크 지표를 재계산하고, 한도 초과 시 알림을 보내거나 헤지·감축을 검토하게 합니다.

한도 관리에서 흔한 함정은 "한도 이중 계산" 문제입니다. 사전 한도에서 예약(reserve)한 익스포저와 실제 체결 후 반영된 익스포저가 어긋나면, 한도를 실제보다 크거나 작게 인식할 수 있습니다. 그래서 주문 생성 시 한도를 예약하고, 체결·취소·거부 시 정확히 되돌리는 정합성 관리가 필수입니다. 구체적인 한도 종류와 산식은 기관·규정에 따라 다를 수 있습니다.

세틀먼트와 청산 — T+1의 세계

거래가 체결되었다고 끝이 아닙니다. 산 사람은 돈을 내야 하고, 판 사람은 증권을 넘겨야 합니다. 이 "돈과 증권의 실제 교환"이 세틀먼트(settlement)이고, 그 사이에서 채무를 상계·보증하는 과정이 청산(clearing)입니다.

핵심 개념 세 가지를 먼저 정리합니다.

- 결제주기(settlement cycle): 거래일(T)로부터 며칠 뒤에 결제하는지. T+1은 거래일 다음 영업일 결제를 뜻합니다. 여러 시장이 과거의 T+2에서 T+1로 이동해 왔습니다. 다만 상품·시장·관할에 따라 다를 수 있습니다.

- CCP(Central Counterparty, 중앙청산소): 매수자와 매도자 사이에 들어가 각자의 거래상대방이 되어 주는 기관입니다. 이를 통해 "상대방이 이행하지 않으면 어쩌지" 하는 카운터파티 리스크를 CCP가 흡수합니다.

- DVP(Delivery versus Payment, 증권-대금 동시결제): 증권 인도와 대금 지급을 원자적으로 묶어, 한쪽만 이행되는 상황을 막는 원칙입니다. "돈은 받았는데 증권을 못 받는" 사고를 방지합니다.

체결 이후 결제까지의 흐름을 시퀀스로 그리면 다음과 같습니다.

트레이딩 CCP(청산) CSD(예탁결제) 현금결제

(거래 체결) (지급/은행)

│ │ │ │

T │ 체결(match) │ │ │

│────────────────▶│ │ │

│ │ 노벨이션(novation) │ │

│ │ 매수/매도의 상대방 │ │

│ │ 으로 CCP가 개입 │ │

│ │ 네팅(netting)으로 │ │

│ │ 결제 건수 축소 │ │

│ │ │ │

T │ 확인(confirm) │ │ │

│ 및 지시(instruct)│───────────────────▶│ │

│ │ │ 결제 지시 매칭 │

│ │ │ │

T+1│ │ DVP 결제 실행 │ │

│ │ 증권 인도 ◀───────▶│ 대금 지급 │

│ │ │◀───────────────▶│

│ │ │ (동시·원자적) │

▼ ▼ ▼ ▼

포지션 확정 리스크 소멸 보유 이전 자금 이동

T+2에서 T+1로 결제주기가 짧아지는 흐름은 시스템에 상당한 부담을 줍니다. 왜냐하면 "확인·지시·자금준비"를 하루 안에 끝내야 하기 때문입니다. 두 방식의 시스템적 함의를 비교하면 다음과 같습니다.

| 구분 | T+2 (전통) | T+1 (단축) |

| --- | --- | --- |

| 결제 여유 | 이틀 | 하루 |

| 후선 처리 | 야간 배치로도 가능 | 당일 마감·자동화 요구 강화 |

| 오류 정정 | 상대적으로 여유 | 정정 시간 촉박, STP 필수 |

| 자금·증권 준비 | 여유 있음 | 사전 확보·예측 중요 |

| 카운터파티 리스크 | 노출 기간 김 | 노출 기간 짧음(개선) |

| 시스템 요구 | 배치 허용 | 준실시간·이벤트 기반 선호 |

여기서 얻을 교훈은, 결제주기 단축이 단순한 규칙 변경이 아니라 **후선 시스템을 배치에서 준실시간으로 밀어붙이는 압력**이라는 점입니다. 확인이 지연되면 결제 실패(settlement fail)로 이어지고, 이는 비용과 규제 리스크를 낳습니다. 구체적인 결제주기와 청산 규칙은 시장·상품·관할에 따라 다를 수 있으므로 반드시 확인이 필요합니다.

데이터 계층 — 시세, 레퍼런스, 포지션

IB 시스템을 떠받치는 것은 결국 데이터입니다. 데이터는 성격에 따라 크게 세 종류로 나뉘고, 각기 다른 저장·갱신·정합성 요구를 갖습니다.

┌──────────────────────────────────────────────────────────────┐

│ MARKET DATA (시세) │

│ - 실시간 호가·체결·지수. 초당 수천~수백만 틱 │

│ - 특성: 초고빈도, 시계열, 지연 민감 │

│ - 저장: 인메모리·시계열 DB, 스트리밍 │

└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐

│ REFERENCE DATA (레퍼런스) │

│ - 종목 마스터, 발행자, 캘린더, 통화, 등급, 식별자(ISIN 등) │

│ - 특성: 저빈도 변경, 정합성 최우선, 전사 공유 │

│ - 저장: 관계형 마스터 DB, 골든소스 관리(MDM) │

└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐

│ POSITION DATA (포지션) │

│ - 보유 수량, 평균단가, 손익, 익스포저 │

│ - 특성: 거래로 갱신, 대사 필요, 감사 대상 │

│ - 저장: 원장·포지션 스토어, 이벤트 소싱과 상성 좋음 │

└──────────────────────────────────────────────────────────────┘

│

시세 + 레퍼런스 + 포지션 ──▶ 리스크·P&L·한도 산출의 입력

이 세 데이터의 성격을 비교하면 다음과 같습니다.

| --- | --- | --- | --- |

레퍼런스 데이터가 조용하지만 가장 위험합니다. 종목 식별자 하나가 틀리면 그 오류가 프론트부터 백까지 전 시스템으로 번지기 때문입니다. 그래서 "골든소스(golden source)"를 하나 정하고 마스터 데이터 관리(MDM)로 일원화하는 것이 정석입니다.

포지션 테이블 예시

포지션은 대사와 감사의 대상이므로, 스키마를 명확히 잡는 것이 중요합니다. 아래는 개념을 보여 주는 SQL 예시입니다.

CREATE TABLE positions (

position_id BIGINT PRIMARY KEY,

account_id VARCHAR(32) NOT NULL,

instrument_id VARCHAR(32) NOT NULL, -- 레퍼런스 골든소스 참조

quantity DECIMAL(20, 4) NOT NULL, -- 음수면 숏 포지션

avg_cost DECIMAL(20, 6) NOT NULL,

currency CHAR(3) NOT NULL,

market_value DECIMAL(20, 4), -- 시세로 재평가

unrealized_pnl DECIMAL(20, 4),

as_of_date DATE NOT NULL,

last_updated TIMESTAMP NOT NULL,

CONSTRAINT uq_position UNIQUE (account_id, instrument_id, as_of_date)

);

-- 특정 계좌의 당일 포지션 조회

SELECT instrument_id, quantity, avg_cost, market_value, unrealized_pnl

FROM positions

WHERE account_id = 'ACC-ALPHA-01'

AND as_of_date = CURRENT_DATE

ORDER BY market_value DESC;

instrument_id가 레퍼런스 데이터의 골든소스를 가리킨다는 점, 그리고 (account_id, instrument_id, as_of_date) 조합에 유일성 제약을 둔 점이 핵심입니다. 이렇게 하면 같은 계좌·종목·일자에 대해 포지션이 중복 기록되는 사고를 막을 수 있습니다.

규제와 감사

IB 시스템은 규제의 한복판에 있습니다. 거래는 감독당국에 보고되어야 하고, 모든 활동은 사후에 추적·재현할 수 있어야 합니다. 시스템 관점에서 이는 두 가지 요구로 이어집니다.

- 거래 보고(trade reporting): 체결된 거래의 세부 사항을 정해진 시한 안에 규제기관·거래정보저장소에 보고해야 합니다. 보고 형식과 항목은 시장·상품·관할에 따라 다를 수 있습니다.

- 감사 추적(audit trail): 누가, 언제, 무엇을, 왜 했는지를 변경 불가능하게 기록해야 합니다. 주문 하나가 생성되고 체결되고 결제되기까지의 모든 상태 변화를 재현할 수 있어야 합니다.

감사 관점에서 특히 중요한 것이 불변 로그(immutable log)입니다. 상태를 덮어쓰는 대신 모든 변경을 append-only로 쌓아 두면, 언제든 특정 시점의 상태를 되짚어 볼 수 있습니다. 이 발상은 뒤에서 다룰 이벤트 소싱과 자연스럽게 연결됩니다.

[주문 생성]──▶[한도 통과]──▶[라우팅]──▶[부분체결]──▶[전량체결]──▶[결제]

▲ ▲ ▲ ▲ ▲ ▲

└─────────────┴────────────┴──────────┴────────────┴──────────┘

모든 전이가 타임스탬프·행위자와 함께 불변 로그에 기록

→ 언제든 특정 주문의 전체 이력을 재현 가능(감사·규제 대응)

여기서 강조할 점은, 감사 요구가 아키텍처를 규정한다는 것입니다. "나중에 로그를 붙이자"가 아니라, 처음부터 모든 상태 변화를 이벤트로 기록하도록 설계하는 편이 훨씬 안전합니다. 구체적인 보고 의무와 보존 기간은 규정·기관에 따라 다를 수 있으므로 준법 부서와 확인이 필요합니다.

레거시와 현대화

많은 IB 시스템의 뿌리는 수십 년 된 메인프레임과 야간 배치입니다. 이유가 있습니다. 안정적이고, 정확하고, 대량 트랜잭션에 강하기 때문입니다. 하지만 T+1 결제, 실시간 리스크, 이벤트 기반 통합의 시대에는 배치 중심 구조가 병목이 됩니다.

[과거: 배치 중심] [현재: 이벤트 기반]

낮: 거래 캡처(파일에 축적) 거래 발생 즉시

───────────────────── 이벤트 발행(스트리밍)

밤: 야간 배치 실행 │

- 포지션 재계산 ├─▶ 실시간 포지션 갱신

- 리스크 산출 ├─▶ 실시간 리스크·한도

- 결제 지시 생성 ├─▶ 준실시간 결제 지시

───────────────────── └─▶ 즉시 감사 로그

다음날: 결과 확인, 오류 정정 (지연 최소화, STP 강화)

문제: 오류가 다음날에야 발견 이점: 즉시 반영·탐지

결제주기 단축에 취약 결제주기 단축에 적합

배치와 스트리밍의 특성을 비교하면 다음과 같습니다.

| 구분 | 배치(레거시) | 스트리밍(현대화) |

| --- | --- | --- |

| 처리 시점 | 정해진 시각(주로 야간) | 이벤트 발생 즉시 |

| 지연 | 시간 단위 | 초·밀리초 단위 |

| 오류 발견 | 다음 처리 사이클 | 거의 실시간 |

| T+1 적합성 | 촉박·위험 | 적합 |

| 감사 | 스냅샷 중심 | 이벤트 이력 자연 확보 |

| 전환 난도 | 안정적이나 경직 | 초기 복잡, 장기 유연 |

현대화의 방향은 대개 "빅뱅 교체"가 아니라 점진적입니다. 레거시 원장을 그대로 둔 채, 그 앞단에 이벤트 버스를 두고 새로운 소비자를 붙여 나가는 스트랭글러 패턴(strangler pattern)이 흔합니다. 이벤트 소싱을 도입하면 감사 추적과 재현성이 자연스럽게 따라오는 장점도 있습니다. 다만 배치가 나쁘고 스트리밍이 좋다는 이분법은 위험합니다. 야간 정산·대사처럼 배치가 여전히 적합한 영역도 많습니다. 현대화는 목적이 아니라 수단이며, 어떤 부분을 이벤트화할지는 기관 상황에 따라 다를 수 있습니다.

흔한 함정

전체 흐름을 설계할 때 반복적으로 마주치는 함정을 정리합니다.

- 계층 경계 흐리기: 프론트가 결제 로직을, 백이 트레이딩 로직을 떠안으면 책임이 뒤섞여 통제가 무너집니다. 계층 경계는 곧 통제 경계입니다.

- 레퍼런스 데이터 방치: 종목 마스터의 사소한 오류가 전사로 번집니다. 골든소스와 MDM 없이 시작하면 나중에 감당하기 어렵습니다.

- 한도 정합성 누락: 예약과 반영이 어긋나면 한도를 잘못 인식합니다. 체결·취소·거부 시 예약을 정확히 되돌려야 합니다.

- 결제 실패 과소평가: 확인·지시 지연은 결제 실패로 이어지고, 이는 비용과 규제 리스크를 낳습니다. T+1에서는 여유가 없습니다.

- 감사 후행 설계: 로그를 나중에 붙이려 하면 재현이 불가능해집니다. 처음부터 상태 변화를 이벤트로 남기세요.

- 무분별한 현대화: 잘 동작하는 배치를 무리하게 스트리밍으로 바꾸다 안정성을 잃을 수 있습니다. 목적에 맞게 선택하세요.

- 시각 동기화 무시: 여러 시스템의 타임스탬프가 어긋나면 감사·대사가 어긋납니다. 시간 동기화는 사소해 보이지만 중요합니다.

마치며

IB 시스템은 딜을 발굴하는 첫 순간부터 돈과 증권이 오가는 마지막 결제까지, 하나의 긴 파이프라인으로 이어져 있습니다. 프론트오피스가 거래를 만들고, 미들오피스가 지키고, 백오피스가 완결합니다. 그 위를 OMS와 EMS가 흐르는 주문, 사전·사후 한도가 감시하는 리스크, T+1과 CCP가 지탱하는 결제, 그리고 시세·레퍼런스·포지션이라는 데이터가 떠받칩니다.

이 전체 그림을 이해하면, 어느 한 시스템을 손볼 때도 그 변화가 파이프라인 전체에 어떤 파장을 일으키는지 가늠할 수 있습니다. 레거시를 현대화할 때도 "무엇을 왜 바꾸는가"를 계층과 데이터의 관점에서 판단할 수 있습니다.

다시 강조하지만, 이 글은 일반적인 아키텍처 교육 자료입니다. 결제주기, 청산 규칙, 보고 의무 같은 구체적 사항은 관할과 기관에 따라 다를 수 있으니(may vary by jurisdiction and firm), 실제 적용 전에는 반드시 소속 기관의 준법감시 부서 및 관련 전문가와 확인하시기 바랍니다.

참고 자료

- ISO 20022 금융 메시징 표준: https://www.iso20022.org/

- SWIFT (글로벌 금융 메시징): https://www.swift.com/

- DTCC (미국 청산·결제, T+1 자료): https://www.dtcc.com/

- FIX Trading Community (FIX 프로토콜): https://www.fixtrading.org/

- Investopedia — T+1 결제 설명: https://www.investopedia.com/terms/t/t1.asp

- Central counterparty clearing (Wikipedia): https://en.wikipedia.org/wiki/Central_counterparty_clearing

- Apache Kafka 문서(이벤트 스트리밍): https://kafka.apache.org/documentation/

- Martin Fowler — Event Sourcing: https://martinfowler.com/eaaDev/EventSourcing.html

- Delivery versus payment (Wikipedia): https://en.wikipedia.org/wiki/Delivery_versus_payment