백엔드 지연 시간 줄이기: 숫자 감각과 기법

왜 숫자 감각이 필요한가

설계를 비교할 때 정확한 값은 필요 없다. 자릿수만 알면 된다. 「Redis를 한 번 더 부르는 것」과 「DB에 한 번 더 쓰는 것」과 「다른 대륙을 한 번 왕복하는 것」은 각각 마이크로초, 밀리초, 수백 밀리초로 단계마다 백~천 배씩 차이 난다. 이 감각이 있으면 어디를 줄여야 하는지 측정 전에도 짐작할 수 있다.

지연은 사용자 경험과 전환율에 바로 이어진다.

지연 시간 자릿수

하드웨어마다 다르므로 대략의 크기로 읽는다. 원형은 Jeff Dean이 정리한 「모든 프로그래머가 알아야 할 지연 시간 숫자」다.

단위는 1ns = 10⁻⁹초, 1µs = 1,000ns, 1ms = 1,000µs다.

flowchart LR
  l1["L1 1ns"] -->|"×100"| ram["RAM 100ns"] -->|"×100"| net["네트워크 10µs"] -->|"×10"| ssd["SSD 100µs"] -->|"×10"| db["DB 커밋 1ms"] -->|"×100"| wan["대륙 간 100ms"]

원형 표

Jeff Dean이 2009년 강연에서 「모두가 알아야 할 숫자」로 내놓고 Peter Norvig의 표를 이어받은 원형은 이렇다. 공개 gist가 지금도 갱신되며, 2026년에는 LLM 행이 더해졌다.

LLM 호출 하나는 같은 데이터센터 왕복보다 수천~수만 배 느리다. 에이전트가 LLM을 순서대로 여러 번 부르면 그 자체가 워터폴이 되므로, 지연을 줄이려면 호출 수를 줄이거나 병렬로 돌리고 프롬프트 캐시를 쓴다.

숫자는 해마다 다르게 변한다

표의 값은 하드웨어 세대에 따라 바뀌지만 모든 칸이 같은 속도로 줄지는 않는다. 연도별로 값을 다시 그려 보는 인터랙티브 버전은 이 차이를 보여 준다.

그래서 대역폭 문제는 시간이 풀어 주지만 지연 문제는 풀어 주지 않는다. 왕복 횟수를 줄이는 설계(배치, 병렬 요청, 사용자 가까이 두기)가 오래 유효하다. 같은 관점이 분산 시스템의 시간과 장애의 「지연은 0이다」라는 착각이다.

봉투 뒷면 계산

숫자를 외우는 목적은 만들어 보기 전에 설계를 비교하는 것이다. 이미지 검색 결과 페이지에 썸네일 30개를 만드는 두 설계를 디스크 탐색 10ms, 디스크 읽기 30MB/s로 어림하면 이렇다.

설계 1: 순서대로 읽어서 즉석에서 256KB 이미지의 썸네일 생성
  30 × 10ms(탐색) + 30 × 256KB ÷ 30MB/s ≈ 560ms
 
설계 2: 30개를 병렬로 읽기
  10ms + 256KB ÷ 30MB/s ≈ 18ms   (편차를 감안하면 실제로는 30~60ms)

여기서 썸네일을 캐시할지, 미리 만들어 둘지 같은 변형을 다시 어림해 가장 유망한 설계를 고른다. 어림이 맞으려면 쓰는 부품(언어 라이브러리, 자료구조, DB, 저장소)의 인터페이스뿐 아니라 구현도 대략 알아야 한다. 감각을 기르는 데는 마이크로벤치마크를 직접 돌려 보는 것이 좋다.

브라우저 쪽 숫자(렌더링 프레임 예산, 체감 한계, CDN 왕복)는 프론트엔드 개발자가 알아야 할 지연 시간 숫자에 있다.

지연을 줄이는 기법

기법은 무엇을 줄이느냐로 나눠 보면 고르기 쉽다.

평균이 아니라 꼬리 지연(p95·p99)을 본다. 요청 하나가 여러 내부 호출로 퍼지면, 그중 가장 느린 하나가 전체 응답 시간을 정한다.

극단적 저지연: 크리티컬 패스에서 일을 줄인다

증권 거래소처럼 마이크로초 단위를 다투는 시스템의 원칙은 하나다. 크리티컬 패스(critical path)에서 일을 덜 한다.

• 크리티컬 패스의 작업 수를 줄인다.
• 각 작업에 드는 시간을 줄인다.
• 네트워크 홉을 줄인다.
• 디스크를 쓰지 않는다.

거래소라면 크리티컬 패스는 「주문이 들어옴 → 필수 리스크 검사 → 체결 → 체결 결과가 나감」뿐이다. 나머지(보고, 정산, 감사 로그)는 모두 경로 밖으로 뺀다.

flowchart LR
  in["주문"] --> om1
  subgraph srv["한 대의 큰 서버 (CPU 코어 고정, 단일 스레드)"]
    om1["주문 관리자"] --> me["매칭 엔진"] --> om2["주문 관리자"] --> res["체결 결과"]
    me --> bus["공유 메모리 이벤트 버스"]
    bus --> sub["리포팅 · 정산 · 감사<br/>(구독만 함)"]
  end

주문 하나의 여정

거래소 안에서 주문은 아래 단계를 거친다. 1~7이 지연 요구가 엄격한 거래 흐름(크리티컬 패스) 이고, 시세 배포와 보고는 그 밖에서 따로 돈다.

flowchart TB
  s1["1. 고객이 증권사 앱으로 주문 → 증권사가 거래소로 전달"] --> s2["2. 클라이언트 게이트웨이: 입력 검증, 레이트 리밋, 인증, 형식 정규화"]
  s2 --> s3["3. 주문 관리자: 리스크 관리자가 정한 규칙으로 리스크 검사"]
  s3 --> s4["4. 주문 관리자: 지갑(계좌)에 주문에 필요한 자금이 있는지 확인"]
  s4 --> s5["5. 매칭 엔진: 호가창에서 맞는 상대 주문을 찾으면<br/>체결 두 건(매수 측, 매도 측)을 만든다"]
  s5 --> s6["6. 시퀀서: 주문과 체결 모두에 순번을 매긴다"]
  s6 --> s7["7. 체결 결과가 역순으로 고객까지 돌아간다"]
  subgraph off["크리티컬 패스 밖"]
    m["시세 흐름: 체결 결과로 캔들·호가 데이터를 만들어 배포"]
    r["보고 흐름: 체결·주문을 모아 정산·규제 보고·감사 기록"]
  end

• 순번을 매기는 이유는 결정성이다. 같은 순서로 다시 넣으면 매칭 엔진이 늘 같은 결과를 내므로, 장애가 나도 기록을 재생해 상태를 그대로 복원하고 대기 서버를 같은 상태로 맞출 수 있다.
• 게이트웨이와 주문 관리자의 검사는 크리티컬 패스 위에 있으므로 최소한으로 둔다. 무거운 검증은 사후 보고 흐름으로 보낸다.

락 없이 단일 스레드로 빠르게 처리하는 발상은 Redis와 이벤트 루프 서버에도 그대로 있다.

조건부 주문: 손절매(stop-loss)는 시세를 구독하다 시장가로 바뀐다

손절매 주문은 「가격이 정해 둔 값(손절가) 이하로 떨어지면 판다」는 조건부 주문이다. 조건이 맞는 순간 시장가 주문(market order)으로 바뀌어 그때의 최우선 호가로 체결된다.

sequenceDiagram
  participant inv as 투자자
  participant eng as 거래 시스템(거래 엔진)
  participant ex as 거래소
  inv->>eng: 손절 주문 등록 (종목, 수량, 손절가)
  Note over eng: 해당 종목의 실시간 시세 구독 → 가격 감시
  Note over eng: 시세 ≤ 손절가 → 시장가 매도 주문 생성
  eng->>ex: 시장가 매도 주문 제출
  Note over ex: 최우선 매수 호가와 즉시 체결
  ex-->>eng: 체결 보고(fill report)
  eng-->>inv: 체결 수량·가격 통지

• 시장가로 바뀌므로 체결 가격은 손절가보다 낮을 수 있다(급락·갭 하락 시 미끄러짐). 가격 하한을 지키려면 지정가로 바뀌는 스톱 리밋(stop-limit) 주문을 쓰지만, 이때는 체결되지 않을 수 있다.
• 조건 감시는 시세 이벤트를 구독하는 별도 구성 요소가 맡고, 조건이 맞으면 일반 주문으로 크리티컬 패스에 들어온다.

정리

• 지연은 자릿수로 기억한다. RAM 100ns, 데이터센터 내 네트워크 µs, SSD 100µs, DB 커밋 1ms, 대륙 간 100ms.
• 기법은 「무엇을 줄이나」로 고른다. 읽는 양(인덱스), 접근 횟수(캐시), 전송량(페이지네이션·압축), 경로 위의 일(비동기), 연결 비용(커넥션 풀), 거리(CDN).
• 평균보다 p99를 본다.
• 가장 빠른 일은 하지 않는 일이다. 응답 전에 꼭 해야 하는 일만 크리티컬 패스에 남긴다.

관련 노트: 프론트엔드 개발자가 알아야 할 지연 시간 숫자, 캐시 전략, 대규모 트래픽에서 서비스를 지키는 설계, 웹 확장성의 구성 요소, 이벤트 루프 서버