스피커 테스트로 오디오 지연을 알 수 있나요?

아니요. 스피커 테스트는 스피커로 톤을 재생해 소리가 나오는지 확인할 뿐입니다. 출력 경로가 작동하는지는 재지만 신호가 입력·출력 체인을 통과하는 데 걸리는 시간은 재지 않습니다. 지연은 기능 테스트가 아니라 타이밍 측정이며 둘은 독립적입니다. 시스템은 치명적인 지연을 보이면서도 모든 재생 검사를 통과할 수 있습니다. 지연을 재려면 알려진 임펄스를 출력으로 보내고 입력에서 돌아오는 신호를 포착해 송신과 수신의 시간 차를 계산하는 왕복 테스트가 필요합니다.

왕복 지연이란 정확히 무엇인가요?

왕복 지연(round-trip latency, 왕복 지연 시간 또는 RTT라고도 함)은 오디오 신호가 입력으로 시스템에 들어와 운영체제와 애플리케이션의 처리를 거쳐 출력으로 나가기까지의 총 시간입니다. 입력 버퍼 지연, 아날로그-디지털 변환 시간, 운영체제 스케줄링 지연, 애플리케이션 처리 지연, 디지털-아날로그 변환 시간, 출력 버퍼 지연이 모두 포함됩니다. 밀리초로 측정되며 마이크에서 스피커까지의 완전한 경로입니다. 브라우저 기반 측정은 공기를 통한 음향 왕복을 잡고 ASIO는 내부 전기 경로를 보고하므로 같은 숫자가 아님에 유의하세요.

측정한 지연이 80밀리초인데, 음악 제작에 나쁜가요?

대부분의 음악 제작에서는 높은 편입니다. 반주나 클릭에 맞춰 녹음하는 연주자는 들리는 메아리 없이 박자를 맞추기 위해 대개 40밀리초 미만의 지연을 선호합니다. 80밀리초라면 연주하는 소리와 들리는 소리 사이의 지연이 명확히 들려 타이트한 타이밍을 유지하기가 매우 어렵습니다. 취미 녹음이나 팟캐스팅에서는 지연이 느껴지지만 종종 참을 만합니다. 녹음 세션 중 라이브 모니터링에는 80밀리초가 대개 사용 불가능한 수준입니다. 개인의 허용 한계는 경험과 장르에 따라 달라진다는 점도 기억하세요.

브라우저로 잰 지연이 전문 오디오 소프트웨어보다 보통 높은 이유는 무엇인가요?

브라우저는 전문 오디오 성능이 아니라 크로스 플랫폼 일관성과 웹 애플리케이션 보안을 위해 설계되었습니다. Reaper나 Ableton 같은 전문 오디오 소프트웨어는 Windows에서 ASIO 드라이버를 사용해 운영체제의 오디오 믹싱 계층을 우회하고 하드웨어에 직접 접근해 흔히 8~15밀리초의 지연을 달성합니다. 브라우저는 운영체제의 공유 오디오 계층을 거쳐야 하므로 믹싱과 스케줄링 오버헤드가 더해지고 저지연 배타 모드에 접근할 수 없습니다. 브라우저가 재는 것은 공유 경로의 최선이며, 대부분의 경우 직접 드라이버 경로보다 본질적으로 높습니다. 다만 격차는 하드웨어, 드라이버 버전, 시스템 구성에 따라 달라집니다.

ASIO 드라이버는 지연을 얼마나 줄여주나요?

Windows에서 기본 WASAPI 공유 모드에서 ASIO나 WASAPI 배타적 모드로 바꾸면 지연이 30~60밀리초에서 8~15밀리초로 줄어드는 것이 일반적입니다. 정확한 감소 폭은 오디오 인터페이스와 드라이버 구현에 따라 달라집니다. ASIO는 애플리케이션에 하드웨어 버퍼에 대한 직접 접근을 주어 Windows 오디오 믹서와 그에 딸린 버퍼링 오버헤드를 우회합니다. 모든 사운드 카드가 ASIO를 지원하지는 않으며, 보급형 온보드 오디오는 보통 지원하지 않습니다. Windows에서 전문 작업을 한다면 ASIO 지원 오디오 인터페이스가 지연 면에서 가장 효과가 큰 업그레이드 중 하나지만, 구매 전에 작업 흐름이 실제로 필요한지 생각해 보세요.

샘플레이트가 높으면 지연이 낮아지나요?

직접적으로는 아닙니다. 샘플레이트는 초당 오디오를 몇 번 측정하는지를 정해 주파수 응답과 처리 부담에는 영향을 주지만 버퍼 지연 자체는 정하지 않습니다. 지연의 일차 제어는 버퍼 크기이며, 버퍼가 작을수록 데이터가 쌓이기를 기다리는 시간이 짧아집니다. 다만 같은 버퍼 크기라도 샘플레이트가 높으면 필요한 데이터 처리량이 늘어나 시스템이 따라가지 못하면 버퍼 언더런이 생길 수 있습니다. 실용적인 접근은 워크플로에 맞춰 샘플레이트를 정하고(보통 48kHz) 버퍼 크기를 최소화하는 것입니다.

버퍼 크기는 지연과 안정성에 어떤 영향을 주나요?

버퍼 크기는 처리 전에 메모리에 저장되는 오디오 샘플 수를 정합니다. 버퍼가 작으면 지연이 줄지만 시스템이 다음 데이터 뭉치를 전달할 시간도 줄어 버퍼 언더런, 즉 들리는 클릭, 팝, 드롭아웃 위험이 커집니다. 버퍼가 크면 안정적이지만 지연이 늘어납니다. 최적점은 하드웨어에 따릅니다. 빠른 컴퓨터와 좋은 오디오 인터페이스는 64 또는 128샘플 버퍼를 낮은 지연과 무결점으로 쓸 수 있고, 느린 시스템은 안정을 위해 512 또는 1024샘플이 필요할 수 있습니다.

블루투스 헤드폰의 지연이 유독 높은 이유는 무엇인가요?

블루투스 오디오 코덱은 압축과 무선 전송에 상당한 처리 지연을 더합니다. 대부분의 기기에서 기본인 SBC 코덱은 대략 100~180밀리초의 지연을 더하며, 정확한 수치는 코덱, 기기 버퍼링, 링크 품질에 따라 달라집니다(Bluetooth.com: A2DP v1.4 (https://www.bluetooth.com/specifications/)). 더 좋은 aptX Low Latency조차 40~80밀리초에 그칩니다(Qualcomm: aptX Low Latency Whitepaper, 2014 (https://www.qualcomm.com/products/aptx)). 이 지연은 무선 프로토콜에 내재되어 있으며 코덱이 모든 프레임을 압축, 전송, 복원해야 하기 때문입니다. 음악 제작, 게임, 영상 편집 등 타이밍이 중요한 용도에서는 유선 헤드폰이나 스피커가 실용적인 선택입니다.

오디오 루프백 지연 시간 — 재생 테스트가 알려주지 않는 것들

대부분의 오디오 테스트는 소리 재생과 마이크 입력 여부만 확인하며, 정작 왕복 지연, 즉 소리가 마이크로 들어와 처리 후 스피커로 나가기까지 걸리는 시간은 측정하지 못합니다. 이 숫자 하나가 녹음, 영상 통화, 게임 속 입체 음향이 자연스럽게 느껴질지 좌우합니다. 기능과 타이밍은 별개의 축이므로 재생 검사를 모두 통과해도 심각한 지연이 남을 수 있습니다. 이 가이드에서 왕복 지연 측정법과 수치의 의미, 줄이는 방법을 설명합니다.

모든 하드웨어 점검은 같은 방식으로 시작됩니다. 새 스피커를 연결하고 테스트 톤을 재생한 뒤 소리가 나오는지만 확인하면 끝입니다. 마이크를 연결하고 말을 해서 레벨 미터가 움직이는지 보고 끝입니다. 이 두 가지 테스트는 출력 경로와 입력 경로가 작동한다는 사실만 확인해 줄 뿐, 오디오 환경이 실제 작업을 감당할 수 있는지를 실제로 가르는 질문, 즉 소리가 마이크에서 컴퓨터를 거쳐 스피커로 나가기까지 얼마나 걸리는지는 측정하지 못합니다. 그 숫자가 바로 **왕복 지연(round-trip latency)**이며, 시스템이 어떤 작업을 제대로 해낼 수 있는지 조용히 결정합니다.

음악 녹음. 클릭이나 반주 트랙에 맞춰 연주하려면 자신의 소리가 거의 즉시 귀로 돌아와야 합니다. 왕복 약 40밀리초를 넘으면 박자가 흐트러지고 모든 테이크가 늘어지게 느껴지며, 아무리 연습해도 해결되지 않습니다. 다른 기기와 USB 컨트롤러를 공유하는 오디오 인터페이스는 USB 대역폭 경합의 영향을 받을 수 있으며, 이는 버퍼 지연 위에 지연 스파이크를 추가합니다.
대화 나누기. 영상 통화는 오디오 파이프라인이 빠듯하게 유지될 때만 자연스럽습니다. 지연이 과도하면 메아리와 말 겹침, 위성전화처럼 딱딱 끊기는 리듬이 생깁니다.
입체 음향 게임. 위치 기반 사운드는 소리가 화면과 맞물릴 때만 성립합니다. 오디오 경로가 화면보다 늦으면 발소리와 총성이 화면 속 동작에서 분리됩니다. 스피커 테스트와 마이크 테스트는 “작동하는가?”에 답합니다. 루프백 지연 테스트는 “얼마나 빠른가?”에 답합니다. 이 페이지에서는 왕복 지연이 무엇인지, 어디에서 생기는지, 어떻게 줄일 수 있는지 설명합니다. 여기의 수치는 다양한 하드웨어·소프트웨어 구성에서 얻은 일반적인 경험에서 나온 것이므로, Focusrite Scarlett 2i2의 실제 ASIO 구성과 Windows 11 내장 Realtek 코덱은 서로 다른 숫자를 보여줄 것입니다. 결과는 사용 중인 인터페이스, 드라이버, 버퍼 설정에 따라 달라집니다.

톤 테스트는 지연을 측정하지 않습니다

스피커 테스트는 출력 경로로 톤, 스윕 또는 음악 샘플을 재생해 소리가 나오는지 확인합니다. 결과가 합격·불합격으로 갈리는 기능 점검입니다. 케이블이 연결되어 있고, 드라이버가 로드되었고, 음량이 음소거가 아니고, 디지털-아날로그 변환기가 살아 있다는 확인일 뿐입니다. 톤이 들리면 출력 경로는 정상입니다. 이 테스트가 알려줄 수 있는 것은 그게 전부입니다. 마이크 테스트는 입력 방향에 대해 같은 일을 합니다. 하는 말을 캡처해 레벨 미터로 표시하고 마이크, 프리앰프, 아날로그-디지털 변환기가 정상 작동하는지 확인합니다. 이 역시 합격 또는 불합격의 결과입니다. 지연 측정은 완전히 다른 종류의 테스트입니다. 신호가 경로를 통과할 수 있는지를 묻는 대신, 통과하는 데 얼마나 걸리는지를 묻습니다. 절차는 단순합니다. 알려진 신호(임펄스, 클릭, 짧은 버스트)를 출력으로 보내고 입력에서 이를 포착한 다음 송신과 수신 사이의 시간 차를 계산합니다. 이 차이가 밀리초 단위의 왕복 지연입니다. 이 구분이 중요한 이유는 두 측정이 서로 독립적이기 때문입니다. 시스템은 치명적인 지연을 보이면서도 모든 재생 테스트를 통과할 수 있습니다. 블루투스 스피커가 대표적인 예입니다. 톤을 충실하게 재현하므로 스피커 테스트는 성공을 보고하지만, 무선 코덱이 추가하는 100~180밀리초의 지연은 어떤 재생 테스트도 눈치채지 못합니다. 150밀리초 늦게 도착하는 톤도 엄밀히 말하면 재생 중인 것입니다. 그렇기 때문에 “내 스피커 소리가 괜찮으니 오디오 시스템도 괜찮다”는 흔한 가정은 타이밍에 민감한 모든 용도에서 무너집니다. 기능과 타이밍은 별개의 축입니다. 녹음, 통화, 게임용으로 설정을 믿기 전에 재생 테스트로는 구조적으로 만들어낼 수 없는 숫자가 필요합니다.

버퍼가 채워지기를 지켜보세요

왕복 지연은 단일 지연이 아닙니다. 마이크 캡슐부터 스피커 진동판까지 매 단계에서 쌓이는 지연의 합입니다. 경로를 이해하면 내 밀리초가 어디에 숨어 있는지 정확히 알 수 있습니다.

입력 버퍼. 아날로그-디지털 변환기는 끊임없이 샘플링하지만 운영체제는 오디오를 블록 단위로 전달합니다. 드라이버는 데이터를 애플리케이션에 넘기기 전 버퍼가 가득 차기를 기다립니다. 48kHz에서 128샘플 버퍼를 채우는 데 2.7밀리초가 걸리며, 그동안 아무도 오디오를 처리하지 않습니다. 대부분의 시스템은 버퍼 두세 개를 동시에 돌립니다. 애플리케이션이 첫 샘플을 보기까지 대략 5~8밀리초를 예상하면 됩니다.
아날로그-디지털 변환. 변환기가 신호를 샘플링하고 양자화하며 클로킹하는 데 시간이 필요합니다. 소비자용 하드웨어에서는 보통 1~3밀리초가 더해지며, 전용 인터페이스는 더 좋습니다.
운영체제 스케줄링. 오디오 엔진이 타이머에 맞춰 애플리케이션을 깨우며, 깨어나는 시점은 일반적인 스레드 스케줄링의 영향을 받습니다. 공유 모드에서는 운영체제가 시스템의 모든 다른 오디오 소스와 스트림을 믹싱하며 자체 처리 패스를 추가합니다. 이 단계는 플랫폼과 부하에 따라 몇 밀리초에서 20밀리초 이상까지 기여합니다. PipeWire를 쓰는 Linux가 Windows를 앞설 수 있는 지점이자, 시끄러운 데스크톱 환경이 지연을 몰래 불릴 수 있는 지점이 바로 여기입니다.
애플리케이션 처리. 수신 측 소프트웨어(DAW, 이펙트 체인, 브라우저 오디오 그래프)가 블록을 다음 단계로 넘기기 전에 처리합니다. 작지만 전체의 일부입니다.
디지털-아날로그 변환. 2단계의 거울상으로, 처리된 신호가 아날로그 전압으로 바뀌며 1~3밀리초가 더해집니다.
출력 버퍼. 처리된 샘플은 변환기가 재생할 준비가 될 때까지 출력 버퍼에서 기다리며, 입력 쪽과 같은 버퍼 크기 계산이 반복됩니다. 일반적인 구성에서 5~~8밀리초를 더합니다. 단계를 모두 더하면 평범한 컴퓨터의 공유 모드 왕복 지연은 대개 30~~60밀리초 사이에 머무릅니다. 아래의 측정 수치는 특정 하드웨어에서 얻은 예시일 뿐 보편적인 사양이 아닙니다. 128샘플 버퍼의 내장 Realtek ALC897 코덱을 단 공장 출하 상태의 Windows 11 노트북에서 비공식 테스트했을 때 공유 모드 측정값은 이 범위의 상단 근처에 머무는 것이 관찰되었고, 같은 하드웨어에서 ASIO4ALL을 통해 Behringer U-Phoria UM2를 사용하면 약 15밀리초로 떨어졌습니다. 이는 통제된 조건 없이 얻은 단일 장비 관찰로, 여러분의 하드웨어에 대한 보장 값이 아니라 공유 모드와 ASIO 경로 사이의 전형적인 격차를 보여주는 참고점입니다. 어떤 드라이버도 변환 시간 자체를 없애지는 못하지만, 전체를 지배하는 버퍼링과 스케줄링 오버헤드는 극적으로 줄어듭니다.

하나의 숫자, 두 가지 정의

오디오 소프트웨어는 단일 숫자만 내놓는 일이 드뭅니다. 전문 애플리케이션의 설정을 열면 보통 두 개가 보입니다. 마이크에서 애플리케이션까지 걸리는 입력 지연과 애플리케이션에서 스피커까지 걸리는 출력 지연입니다. ASIO 같은 드라이버는 두 값을 따로 보고하며, 마케팅 자료는 더 좋아 보이는 쪽을 인용하곤 합니다. 왕복 지연은 이 둘을 합친 값에 애플리케이션 자체의 처리 시간을 더한 것입니다. 편도 20밀리초를 표방하는 시스템이라면 왕복은 대략 40밀리초입니다. “20ms 지연”이라는 문구를 읽고 그것이 실제 들릴 지연이라고 착각하면 두 배를 틀린 셈이며, 사양 시트에는 편도 수치가 인쇄되는 일이 많기 때문에 이 실수는 흔합니다. 이 구분이 중요한 이유는 우리가 지각하는 것은 항상 왕복이기 때문입니다. 연주자가 자신의 목소리나 악기를 모니터링할 때 소리는 마이크를 떠나 시스템을 통과한 뒤 헤드폰으로 돌아와야 들립니다. 그것이 완전한 경로입니다. 편도 수치는 여정의 절반만 묘사합니다. 논의의 일관성을 위해 이 글의 모든 숫자는 왕복 지연을 가리킵니다. 측정값을 제품 사양이나 벤치마크와 비교할 때는 두 숫자가 같은 종류의 여정을 말하는지 반드시 확인하세요. 왕복 측정값을 편도 사양과 비교하면 시스템이 실제보다 두 배 느려 보입니다.

여러분이 고르기 전에 OS가 먼저 정합니다

같은 마이크, 같은 스피커, 같은 케이블이라도 운영체제에 따라 지연이 크게 달라집니다. 플랫폼마다 오디오를 서로 다른 소프트웨어 스택으로 라우팅하고, 그 스택이 피할 수 없는 변환 시간 위에 얼마나 많은 버퍼링과 스케줄링 오버헤드를 얹을지 결정하기 때문입니다.

Windows: 공유 모드, 배타적 모드, ASIO

Windows는 세 가지 방식으로 하드웨어에 도달하며 각각 지연 프로필이 다릅니다.

WASAPI 공유 모드는 별도로 요청하지 않는 한 모든 애플리케이션이 쓰는 기본 경로입니다(Microsoft Learn: WASAPI Shared Mode, 2023). 모든 오디오가 함께 믹싱되어 보수적인 버퍼링으로 전달됩니다. 일반적인 시스템에서 관찰되는 왕복 지연은 버퍼 크기와 부하에 따라 대개 32~64밀리초 범위이며, 이는 흔한 경험 범위이지 보장 값이 아닙니다. Web Audio, WebRTC, 미디어 재생은 조금씩 다른 경로를 거치지만 모두 이 공유 믹서에서 시작합니다.
WASAPI 배타적 모드 또는 ASIO는 믹서를 우회해 한 애플리케이션에 장치 직접 접근을 허용하며, 일반적인 하드웨어에서 지연을 약 10밀리초 수준으로 낮춥니다(Microsoft Learn: WASAPI Exclusive Mode, 2023). 요청하는 네이티브 애플리케이션은 사용할 수 있지만 브라우저는 불가능합니다.
ASIO는 Windows 오디오 스택을 완전히 우회해 인터페이스 하드웨어와 바로 통신하는 드라이버 프로토콜입니다(Steinberg: ASIO Host and Driver Guide v2.3, 2021). 적절한 인터페이스에서 ASIO는 대개 8~15밀리초를 달성하며, 정확한 수치는 인터페이스, 드라이버 버전, 버퍼 구성에 따라 달라집니다. 브라우저는 사용할 수 없습니다.

macOS: Core Audio

Apple의 Core Audio 프레임워크는 최적화가 잘 되어 있어 네이티브 애플리케이션은 적절한 버퍼 설정만으로 왕복 8~20밀리초를 흔히 달성합니다. 공유 경로가 효율적이라 macOS에서 브라우저로 잰 지연조차 보통 Windows보다 낫습니다. 그래도 브라우저는 배타적 장치 접근을 확보하거나 버퍼를 자기 필요에 맞게 조정할 수 없으므로 네이티브 최솟값 위에 머뭅니다.

Linux: ALSA, PulseAudio, PipeWire

Linux 지연은 움직이는 과녁입니다. 저수준 드라이버 인터페이스인 ALSA는 빠르지만 애플리케이션별 대응이 필요합니다. PulseAudio는 역사적으로 그 위에 상당한 버퍼링 오버헤드를 얹었습니다. 현대적 대체재인 PipeWire는 저지연 오디오를 위해 설계되어 올바르게 구성하면 다른 플랫폼에 필적하거나 앞설 수 있지만, 결과는 배포판과 설정에 따라 크게 갈립니다. 대부분의 구성에서 브라우저는 공유 경로에 갇힙니다. 배타적 모드를 요청할 수 없고, ASIO 드라이버를 불러올 수 없고, 오디오 스레드 우선순위를 올릴 수도 없습니다. 따라서 브라우저 오디오 지연은 일반적으로 플랫폼의 공유 모드 상한, 즉 표준 구성에서 협력적 경로가 낼 수 있는 최선에 가깝습니다. 반면 네이티브 전문 소프트웨어는 하드웨어와 드라이버가 허락하면 그 상한을 벗어나도록 만들어져 있습니다.

60밀리초가 실제로 의미하는 것

밀리초 수치는 하려는 일과 대응시키기 전까지는 아무 의미가 없습니다. 아래 경계는 일반적인 지침이지 전문 인증 기준이 아니며, 실제 적합성은 구체적인 작업, 모니터링 환경, 청취 환경에 따라 달라집니다. 실용 범위를 덮는 네 개의 구역이 있습니다.

20ms 미만 — 훌륭함. 전문 음악 제작이 이 구역에서 편안합니다. 반환 경로가 사실상 즉각적이므로 연주자가 클릭에 맞춰 트래킹하고, 이펙트를 얹어 자기 소리를 모니터링하면서도 박자를 맞출 수 있습니다. 게임 속 입체 음향도 화면에 고정됩니다.
20–60ms — 대부분의 용도에 허용 가능. 팟캐스팅, 영상 통화, 일반 게임, 취미 녹음이 모두 잘 됩니다. 이 범위의 상단에서는 타이트한 음악 트래킹이 힘들어지기 시작합니다. 연주자가 자기 소리의 반환을 살짝 늦게 느끼며, 대략 40밀리초를 넘으면 정밀한 작업이 눈에 띄게 어려워집니다.
60–120ms — 제작에는 문제, 취미 용도에는 허용 가능. 노래방, 음성 채팅, 감상은 괜찮습니다. 반주에 맞춘 녹음은 실제로 어려워지고, 게임에서는 소리가 화면 속 동작에서 떨어지기 시작해 입체 음향이 의존하는 위치 단서를 해칩니다.
120ms 초과 — 불량. 타이밍에 민감한 작업은 사실상 불가능합니다. 통화에는 들리는 메아리가 생기고, 연주는 어긋난 느낌을 주며, 입체 음향은 취미 용도에서조차 틀리게 들립니다. 이 구역은 블루투스 오디오와 잘못 구성된 공유 모드 시스템의 자연스러운 소굴입니다. 구역 경계는 판단에 따라 움직이지만 골격은 믿을 만합니다. 제작은 가장 낮은 숫자를 필요로 하고, 대화는 조금 더 참아주며, 감상은 가장 참아줍니다. 왕복 측정값은 시스템을 정확히 한 구역에 배치하고, 그 배치가 어느 용도는 쾌적하게 느껴지게 하고 어느 용도는 발목을 잡을지 알려줍니다. 이 숫자를 옆에 두세요. 다음 절의 모든 최적화가 참고할 기준점입니다.

세 개의 지렛대: 샘플레이트, 버퍼, 드라이버

경로에서 지연이 어디에 자리 잡는지는 세 가지 제어가 결정하며, 그 효과는 같지 않습니다. 샘플레이트는 파이프라인의 처리량, 즉 초당 오디오를 몇 번 측정하는지를 정할 뿐 지연 자체를 직접 정하지 않습니다. 다만 버퍼가 샘플 단위로 매겨지므로 버퍼 타이밍과 상호작용합니다. 128샘플은 44.1kHz에서 2.9밀리초지만 96kHz에서는 1.3밀리초에 불과해 같은 버퍼 크기라도 샘플레이트에 따라 걸리는 시간이 달라집니다. 문제는 높은 레이트가 초당 더 많은 처리를 요구해서 안정을 위해 버퍼를 도로 올려야 하는 경우가 잦고, 그러면 이득이 상쇄된다는 점입니다. 96 또는 192kHz를 좇으면 대개 스트림을 안정적으로 유지하려고 더 큰 버퍼가 강요되어 이론상 이득이 사라지거나 오히려 느려질 수 있습니다. 샘플레이트는 일차적인 지연 제어 수단이 아니라 워크플로 설정, 보통 48kHz로 다루세요. 48kHz가 비디오 동기 오디오의 사실상 표준이 된 것은 24, 25, 30fps 비디오 프레임 레이트에 깔끔하게 대응하기 때문이며, 전문 오디오-비디오 파이프라인이 기본값을 거기에 두는 이유이기도 합니다. 버퍼 크기가 일차 지연 지렛대입니다. 시스템이 처리하기 전에 얼마나 오디오를 모을지 결정하며, 왕복에 두 번 등장합니다. 입력 쪽 한 번, 출력 쪽 한 번입니다. 버퍼를 절반으로 줄이면 그 몫의 지연도 절반이 되지만, 각 블록을 전달할 시간도 절반이 되어 버퍼 언더런, 즉 클릭, 팝, 드롭아웃의 위험이 커집니다. 48kHz에서 실용적인 매트릭스는 다음과 같습니다.

64샘플 — ASIO나 배타적 모드를 갖춘 유능한 하드웨어에서 왕복 대략 8–12ms. 보급형 인터페이스는 이 크기에서 클릭이 나오는 경우가 많습니다.
128샘플 — 대략 12–20ms. 제작용으로 흔히 말하는 ASIO 스위트 스팟.
256샘플 — 대략 20–35ms. 공유 모드에서 흔히 가장 작은 안정 크기.
512샘플 — 대략 35–60ms. 안전하지만 눈에 띄게 늘어집니다.
1024샘플 — 대략 60–100ms. 지연이 무관한 스트리밍이나 재생 전용. 드라이버가 바닥을 정합니다. ASIO와 배타적 모드는 32~128샘플 버퍼를 허용하고, 공유 모드의 하한은 그보다 높으며, 블루투스 코덱은 버퍼를 논하기도 전에 100밀리초 이상을 얹습니다. 어떤 버퍼 조정도 드라이버의 최솟값을 이길 수 없습니다. 그래서 드라이버가 마지막이 아니라 첫 번째 지렛대입니다.

브라우저는 DAW가 아닙니다

브라우저는 Web Audio API로 왕복 지연을 추정할 수 있습니다(MDN: Web Audio API, 2024). 출력으로 임펄스를 스케줄링하고 마이크 입력에 도착하는 신호를 포착하는 방식입니다. 공유 모드 노트북에서의 전형적인 Web Audio 루프백 측정은 흔히 55–70ms를 보고하는데, 이는 ASIO 수치의 몇 배이며 브라우저의 공유 경로 세금을 보여주는 격차입니다. 측정 시간에는 공기를 통한 음향 경로, 스피커와 마이크 변환기, 에코 캔슬레이션 처리, 시스템 오디오 스택 전체가 포함됩니다. 이것을 **음향 왕복 지연(acoustic round-trip delay)**이라 부르며, 브라우저 기반 통화, 노래방, 브라우저 게임에 해당하는 수치이지만 전문 오디오 소프트웨어가 재는 ASIO 왕복 지연과 동일하지 않습니다. 이 측정은 스피커와 마이크 사이에 실제 음향 경로가 필요하며, 자동 게인 제어, 노이즈 억제, 에코 캔슬레이션이 임펄스 모양을 바꿀 수 있고 마이크 거리, 방의 잔향, 음량 설정도 모두 결과에 영향을 줍니다. 브라우저가 할 수 없는 것은 하드웨어의 최상의 경우에 도달하는 일입니다. 운영체제의 공유 오디오 경로를 써야 하고, 배타적 장치 접근을 확보할 수 없고, ASIO 드라이버를 불러올 수 없으며, 자체 오디오 버퍼 크기나 스레드 우선순위도 제어할 수 없습니다. 따라서 측정값은 하드웨어의 진짜 최솟값이 아니라 플랫폼의 공유 모드 상한을 반영합니다. 그리고 그 상한이야말로 브라우저 작업에 딱 맞는 숫자입니다. 웹 통화, 브라우저 게임, 웹 노래방 등 탭 안에서 돌아가는 모든 것은 세부는 달라도(Web Audio, WebRTC, 미디어 재생) OS 수준에서 브라우저의 오디오 경로를 공유합니다. 브라우저로 잰 숫자가 좋으면 모든 브라우저 용도가 좋게 느껴집니다. 나쁘다면 네이티브 소프트웨어가 구원해 줄 수 있지만, 같은 하드웨어와 구성이라도 브라우저는 대개 네이티브보다 느립니다.

지연을 줄이는 여섯 가지 방법

효과가 큰 순서로 문제를 다루고, 숫자가 견딜 만한 구역에 들어오면 거기서 멈추세요.

먼저 드라이버 모드를 고치세요. Windows에서 오디오 인터페이스의 ASIO 드라이버를 설치하거나 WASAPI 배타적 모드로 전환하세요. 단독으로 가장 큰 지렛대이고 공짜입니다.
버퍼 크기를 줄이세요. 512에서 256, 128, 64샘플로 한 단계씩 내려가며 각 설정을 테스트하고, 클릭이나 팝이 들리면 한 단계 위로 되돌아가 깨끗하게 유지되는 가장 큰 버퍼를 찾으세요.
샘플레이트를 확인하세요. 음악과 영상 작업에는 48kHz를 쓰세요. 96kHz나 192kHz를 좇으면 대개 더 큰 버퍼가 강요되어 결국 더 느려집니다.
경쟁하는 애플리케이션을 닫으세요. 스트리밍, 캡처, 바쁜 브라우저 탭은 오디오 스레드에서 CPU 시간을 가져가 작은 버퍼에서 언더런을 일으킵니다.
오디오 인터페이스를 고려하세요. 전용 하드웨어는 더 나은 변환기, 제대로 된 ASIO 드라이버, 내장 오디오가 미치지 못하는 버퍼 크기를 가져다줍니다.
유선 연결을 선호하세요. 타이밍에 민감한 모든 용도에서 유선 헤드폰은 다른 설정과 무관하게 블루투스보다 100밀리초 이상 앞섭니다. 각 단계는 누적됩니다. 512샘플 공유 모드에서 128샘플 ASIO로 옮기면 시스템이 흔히 50밀리초에서 20밀리초 미만으로 이동합니다. 쓸 수 없는 것과 전문적인 것 사이의 차이입니다.

요약

재생 테스트는 스피커가 작동한다는 것을 확인합니다. 루프백 테스트는 스피커가 시간에 맞춰 작동한다는 것을 확인합니다. 서로 다른 질문이며 답도 다릅니다. 스피커 테스트로 출력 경로를 검증하고 마이크 테스트로 입력 경로를 검증하세요. 참고로 이 사이트는 현재 전용 루프백 지연 측정 도구를 제공하지 않습니다. 위에서 설명한 Web Audio API 접근은 별도의 구현이나 브라우저 콘솔 설정이 필요합니다. 이를 활용해 기기에서 녹음, 대화, 입체 음향이 자연스럽게 느껴질지를 결정하는 음향 왕복 지연을 확인해 보세요. 한 번 측정하고 결과를 보관하세요. 20밀리초 미만이면 전문가급 타이밍입니다. 20~60이면 일상 작업 대부분을 커버합니다. 120을 넘으면 타이밍에 민감한 모든 작업이 당신과 싸울 것이고, 해결은 대개 하드웨어보다 드라이버에서 시작됩니다. 그 수치를 한 번도 측정해 본 적이 없다면, 타이밍에 의존하는 모든 오디오 작업을 추측으로 넘기고 있는 셈입니다.