563. 분리 트랜잭션 버스 (Split Transaction)

핵심 인사이트 (3줄 요약)

1. 본질: 분리 트랜잭션 버스는 하나의 읽기·쓰기 작업을 요청 단계와 응답 단계로 나누고, 응답을 기다리는 동안 버스를 즉시 반납하게 만들어 공유 통로의 유휴 시간을 줄이는 비차단형 버스 운용 방식이다.
2. 가치: 메모리나 원격 노드의 긴 응답 지연을 다른 요청 발행으로 가릴 수 있어, 멀티코어·Non-Uniform Memory Access (NUMA)·System on Chip (SoC) 환경에서 버스 활용률과 메모리 수준 병렬성 둘 다 높인다.
3. 판단 포인트: 분리 트랜잭션의 성패는 tag 수, outstanding request 버퍼, 응답 재정렬 규칙, timeout 정책에 달려 있으므로 단순 버스보다 훨씬 강력하지만 훨씬 더 정교한 제어가 필요하다.

Ⅰ. 개요 및 필요성

분리 트랜잭션 버스는 요청을 보낸 마스터가 데이터가 올 때까지 버스를 붙잡고 있지 않는 구조다. 주소와 명령, 식별자만 먼저 전달하고 버스를 반납한 뒤, 슬레이브가 준비를 마치면 나중에 다시 응답을 실어 보낸다. 따라서 이 구조의 핵심은 "응답이 빨라진다"가 아니라, 응답을 기다리는 시간이 버스를 놀게 만들지 않는다는 데 있다.

이 방식이 필요해진 배경은 Central Processing Unit (CPU)과 메모리, 또는 서로 다른 노드 사이의 속도 차이가 커졌기 때문이다. 예를 들어 버스는 5ns마다 새 요청을 발행할 수 있는데 메모리 응답이 60ns 뒤에나 도착한다면, 전통적인 점유형 버스에서는 55ns가 거의 빈 시간으로 버려진다. 멀티코어가 이 버스를 공유하면 한 코어의 캐시 미스가 다른 코어의 요청까지 같이 묶어 두는 병목이 된다.

그래서 분리 트랜잭션은 기다림을 구조적으로 분해한다. 요청자는 "무엇을 달라"만 먼저 말하고 물러나며, 응답자는 "준비됐을 때 다시 말한다." 이 패턴이 있어야 지연시간이 긴 시스템에서도 여러 요청이 동시에 떠다니는 memory-level parallelism이 가능해진다.

• 📢 섹션 요약 비유: 분리 트랜잭션은 카페에서 주문만 하고 진동벨을 받은 뒤 자리로 가는 방식과 같다. 주문이 나올 때까지 계산대 앞을 막고 서 있지 않으니, 내 대기시간이 다른 손님의 주문 시간까지 빼앗지 않는다.

Ⅱ. 아키텍처 및 핵심 원리

분리 트랜잭션이 성립하려면 요청과 응답을 다시 이어 붙일 장치가 필요하다. 그래서 대부분의 구조는 요청 발행 → tag 부여 → outstanding table 기록 → 응답 수신 → tag match → 완료 처리 순서로 동작한다. 이때 응답은 요청 순서와 다르게 돌아올 수 있으므로, 식별자와 재정렬 로직이 핵심이 된다.

이 그림은 한 요청이 기다리는 동안 다른 요청이 얼마나 앞질러 들어갈 수 있는지를 보여 준다.

┌──────────────────────────────────────────────────────────────────────────────┐
│ Split Transaction 타임라인: 요청과 응답이 시간상 분리되어 버스를 재사용한다 │
├──────────────────────────────────────────────────────────────────────────────┤
│ Time →                                                                      │
│ Bus  : [Req A:t3] [Req B:t7] [Req C:t9] ........ [Resp B:t7] [Resp A:t3]    │
│ A    :    issue ───────────── wait ───────────────────────── capture         │
│ B    :             issue ───── wait ───────── capture                        │
│ C    :                      issue ─────────────── wait ────── capture        │
│ Rule : 응답 순서는 요청 순서와 달라도 tag가 같으면 원래 요청과 결합된다      │
└──────────────────────────────────────────────────────────────────────────────┘

정량적으로 보면 outstanding 깊이가 성능을 좌우한다. 버스가 5ns마다 새 요청을 발행할 수 있고 평균 응답 지연이 60ns라면, 버스를 거의 놀리지 않으려면 대략 60 / 5 = 12개 수준의 outstanding 요청을 동시에 유지할 수 있어야 한다. 이 깊이가 부족하면 분리 트랜잭션 구조를 써도 중간에 다시 발행 공백이 생긴다.

또한 분리 트랜잭션은 단순히 버스를 빨라지게 하는 기법이 아니라, Miss Status Holding Register (MSHR) 같은 비차단 캐시 구조와 궁합이 맞다. 캐시도 여러 miss를 동시에 추적할 수 있어야 버스 측의 outstanding 능력을 실제 시스템 성능으로 바꿀 수 있기 때문이다.

• 📢 섹션 요약 비유: 분리 트랜잭션은 택배 송장 시스템과 같다. 상자를 먼저 보내고 송장 번호를 기록해 두면, 나중에 도착 순서가 섞여도 번호만 맞으면 누구 물건인지 정확히 찾아낼 수 있다.

Ⅲ. 비교 및 연결

분리 트랜잭션은 흔히 파이프라인 버스와 같이 언급되지만 둘은 같지 않다. 파이프라인 버스는 주로 주소 단계의 겹침을 뜻하고, 분리 트랜잭션은 요청과 응답의 소유권 자체를 분리한다. 즉 파이프라인은 시작 간격을 줄이는 기술이고, split은 기다림 동안 통로를 비우는 기술이다.

이 개념은 562번의 버스트 전송과도 연결된다. 버스트는 한번 버스를 얻은 뒤 많은 데이터를 실어 나르는 방식이고, split은 응답을 기다리는 동안 다른 요청에게 버스를 내주는 방식이다. 실제 고성능 인터커넥트에서는 "요청은 split, 데이터 응답은 burst" 조합이 흔하다.

현대의 패킷형 인터커넥트도 이 아이디어를 계승한다. Advanced eXtensible Interface (AXI)는 읽기 주소와 읽기 데이터를 채널로 나누고, PCI Express (PCIe)는 Transaction Layer Packet (TLP) 기반으로 요청과 completion을 분리한다. 즉 split transaction bus는 전통적인 공유 버스를 넘어서, 오늘날 packetized interconnect의 선조 같은 개념이다.

• 📢 섹션 요약 비유: 파이프라인 버스가 계산대 줄을 여러 칸으로 나눠 빨리 접수하는 방식이라면, 분리 트랜잭션은 주문 접수와 음식 수령 창구를 완전히 분리하는 방식이다. 접수만 빨라지는 것과, 기다리는 사람 때문에 창구가 막히지 않는 것은 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 split 구조는 메모리 지연이 큰 환경에서 특히 빛난다. 멀티소켓 서버의 NUMA 메모리 접근, CPU와 Graphics Processing Unit (GPU)이 Dynamic Random-Access Memory (DRAM) 컨트롤러를 공유하는 SoC, 캐시 일관성 snoop이 많은 멀티코어 시스템은 응답 지연이 짧지 않다. 이때 버스를 점유형으로 두면 한 요청의 대기가 전체 시스템 정체로 번진다.

반대로 장치 수가 적고 구조가 단순한 마이크로컨트롤러에서는 split이 과한 경우가 많다. tag 비교 로직, outstanding table, 재정렬 버퍼, timeout 관리가 추가되면 면적과 전력이 늘고 검증도 어려워진다. 요청이 거의 직렬로만 발생하는 환경이라면 단순 점유형 버스나 짧은 burst만으로도 충분할 수 있다.

적용 체크리스트

1. 최악의 응답 지연을 가리기에 충분한 tag 수와 outstanding 깊이가 있는가?
2. out-of-order 응답을 허용한다면 재정렬과 순서 규칙이 아키텍처적으로 정의되어 있는가?
3. 응답 버퍼 포화, retry, timeout 시 deadlock 없이 후퇴할 경로가 있는가?
4. 읽기 요청뿐 아니라 쓰기 완료, snoop 응답까지 포함해 채널 간 순환 의존성을 점검했는가?
5. 정말로 긴 지연과 높은 동시성이 있는 시스템인지, 아니면 단순 구조에 과잉 설계하고 있는지 판단했는가?

피해야 할 안티패턴

• 응답이 항상 요청 순서대로 돌아온다고 가정하는 설계

• outstanding 요청 수를 무제한처럼 열어 두고 버퍼 고갈을 고려하지 않는 구조

• tag 공간을 너무 작게 잡아 발행 단계에서 자주 막히는 설계

• fence나 read-after-write ordering을 정의하지 않아 드라이버가 가시성 문제를 겪는 인터페이스

• 📢 섹션 요약 비유: split 구조 설계는 식당 진동벨 개수를 정하는 일과 같다. 손님은 많은데 벨이 몇 개 없으면 주문을 더 받고 싶어도 못 받고, 벨은 많은데 주방과 진열대가 감당 못 하면 오히려 혼란만 커진다.

Ⅴ. 기대효과 및 결론

잘 설계된 분리 트랜잭션 버스는 버스 활용률을 크게 높이고, 코어나 장치가 한 번의 느린 응답 때문에 모두 멈추는 상황을 줄여 준다. 그 결과 메모리 수준 병렬성, 멀티코어 확장성, 원격 노드 접근 효율이 함께 향상된다. 특히 지연시간이 긴 시스템에서 "빠른 버스"보다 "안 놀고 있는 버스"가 더 중요할 때가 많다.

하지만 그 대가로 구조는 확실히 복잡해진다. tag 추적, 재정렬, deadlock 회피, Quality of Service (QoS), 오류 복구까지 모두 갖춰야 진짜 split이 된다. 따라서 이 기술은 단순히 성능 욕심으로 넣는 기능이 아니라, 지연시간을 자원 활용 문제로 바꿔 풀어야 할 때 선택하는 구조적 해법이다.

앞으로도 Network-on-Chip (NoC), CXL (Compute Express Link), 고성능 가속기 패브릭에서는 여러 outstanding 요청과 지연 은닉이 핵심이므로 split 사고방식은 계속 중요하다. 기억해야 할 본질은 하나다. 분리 트랜잭션은 응답을 더 빨리 오게 만드는 기술이 아니라, 기다리는 동안 다른 일을 계속하게 만드는 기술이다.

• 📢 섹션 요약 비유: split 버스는 한 사람이 엘리베이터를 붙잡고 친구를 기다리는 대신, 호출 버튼만 누르고 옆으로 비켜 모두가 함께 엘리베이터를 쓰게 만드는 규칙과 같다. 기다림 자체는 남아도, 건물 전체 흐름은 훨씬 좋아진다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

점유형 공유 버스
        │
        ▼
주소 단계 파이프라이닝
        │
        ▼
Tag 기반 Split Transaction
        │
        ▼
AXI · PCIe Completion 기반 패킷형 인터커넥트
        │
        ▼
NoC · CXL 기반 다중 outstanding 패브릭

이 흐름은 공유 버스가 "한 번에 한 일만 하는 통로"에서 출발해, 점차 요청과 응답을 분리하고 패킷화해 대기시간을 구조적으로 숨기는 방향으로 발전했음을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

1. 분리 트랜잭션은 음식을 주문하고 진동벨을 받은 뒤 자리에서 기다리는 것과 같아요.
2. 내가 기다리는 동안 다른 친구들도 카운터에서 계속 주문할 수 있어서 가게가 덜 막혀요.
3. 벨이 울리면 그때 내 음식만 찾아오면 되니까, 기다리는 시간도 낭비가 덜 된답니다.