AI 용어 사전 10편 (2026) — 추론 · 지연 · 처리량, 빠른 응답은 어떻게 만들어지나

AI 용어 사전 10편 (2026) — 추론 · 지연 · 처리량, 빠른 응답은 어떻게 만들어지나

AI가 답을 내놓는 과정인 추론, 기다림의 길이인 지연, 동시에 처리하는 양인 처리량을 ChatGPT·Gemini·Make로 정리했습니다. 빠른 응답이 왜 어려운지 초보가 잡는 개념 가이드입니다.

“이 모델은 추론(inference) 비용이 비싸요” “지연(latency)이 길어서 실시간엔 못 씁니다” “처리량(throughput)을 올려야 동시 사용자를 감당하죠” — AI 도구 소개란, 뉴스 해설, 유튜브 영상 어디서나 이 세 단어가 번갈아 나옵니다. 그런데 세 단어의 차이를 한 줄로 말하지 못하면, “왜 어떤 AI는 답이 빠른데 어떤 건 버벅거리지?”라는 질문에 영영 답할 수 없게 됩니다. “다 서버 문제 아니야?”로 넘기면, 왜 모델이 커질수록 답이 느려지는지, 왜 한꺼번에 많이 돌리면 한 개짜리도 느려지는지, 왜 “실시간 대화”가 기술적으로 어려운 과제인지를 이해할 수 없습니다. 원리를 모르면 빠른 도구를 고르는 눈도, 비용을 가늠하는 눈도 흔들립니다.

요약 (TL;DR): 추론 · 지연 · 처리량 핵심 요약 추론은 학습이 끝난 모델이 입력을 받아 답을 내놓는 과정으로, 공부가 끝난 뒤 시험을 보는 순간에 해당합니다. 지연은 요청을 보낸 뒤 응답이 돌아올 때까지 걸리는 시간이라 첫 글자가 뜨기까지의 멈춤으로 체감되고, 처리량은 단위 시간당 처리하는 요청·작업의 양이라 동시에 100명이 써도 버티는지를 뜻합니다. 지연은 “얼마나 기다려야 하나”, 처리량은 “얼마나 많이 동시에 감당하나”라 서로 다른 축입니다.

이 글은 5분 안에 읽고 AI가 답을 낼 때까지의 시간을 다루는 세 단어 — 추론 · 지연 · 처리량을 정리합니다. 각 단어가 “무엇을 가리키고 왜 체감으로 이어지는가”를 ChatGPT · Gemini · Make 같은 도구 화면과 일상 사례로 짚고, 흔히 빠지는 오해까지 잡습니다. 도구 사용법이 아니라 개념을 먼저 잡는 글입니다.

왜 “빠른 응답은 어떻게 만들어지나”인가? 우리 블로그의 9편 과적합 · 일반화 · 교차검증은 모델이 ‘얼마나 잘하는가’를 다뤘고, 5편 파라미터 · 어텐션 · 스트리밍은 모델이 ‘작동하는’ 뼈대를 보았습니다. 이 글은 그 뒤를 잇습니다 — 잘 만들어진 모델이 실제로 쓰일 때 ‘얼마나 빨리, 얼마나 많이’ 답을 내놓는가, 그리고 왜 “품질 좋은 모델”과 “빠른 응답”이 늘 같이 오지 않는지를 보는 ‘AI 용어 사전’ 시리즈의 열 번째 글입니다.

추론·지연·처리량은 각각 무엇을 가리킬까?

이 섹션에서 배우는 것: 세 단어를 한 줄씩 먼저 훑고, 각각이 내 화면·기다림에서 어떻게 나타나는지 보기.

단어한 줄 정의직관적 의미일상 예시
추론(Inference)학습이 끝난 모델이 입력을 받아 답을 내놓는 과정’공부’가 끝난 뒤 ‘시험 보는 순간‘“질문을 넣자 답이 흘러나온다”
지연(Latency)요청을 보낸 뒤 응답이 돌아올 때까지 걸리는 시간얼마나 기다려야 하나”첫 글자가 뜨기까지의 멈춤”
처리량(Throughput)단위 시간당 처리하는 요청·작업의 양얼마나 많이 동시에 감당하나”동시에 100명이 써도 버티는가”

⚠️ 지연과 처리량 수치는 모델 크기, 서버 자원, 한 번에 몇 명이 쓰느냐에 따라 크게 달라집니다. 같은 모델도 쓸 때마다, 환경마다 다르게 측정되므로 한 도구의 고정된 수치처럼 옮겨 쓸 수는 없습니다. 이 글은 2026년 8월 기준의 개념 설명이며, 정확한 측정 기준은 공식 자료에서 확인하세요. 출처: 구글 ML 입문 강좌, 허깅페이스 강좌, 사이킷런 모델 평가 문서

용어 1: 추론(Inference) — “답을 내놓는 순간이 따로 있다?”

이 섹션에서 배우는 것: 추론이 ‘학습이 끝난 모델이 입력을 받아 답을 내는 과정’이라는 것, 그래서 학습과 사용이 다른 단계라는 점.

추론은 AI의 ‘사용’ 단계를 가리키는 단어입니다. 한 줄로 말하면, 학습으로 만들어진 모델이 새로운 입력을 받아들여 답(출력)을 내놓는 과정입니다. 학습이 ‘수억 예시로 규칙을 익히는 공부 시간’이라면, 추론은 ‘그 모델을 들고 시험장에 들어가 답을 쓰는 순간’입니다. 중요한 점은 이 둘이 완전히 다른 단계라는 것입니다 — 학습은 한 번(혹은 가끔) 엄청난 자원을 들여 하고, 추론은 사용자가 쓸 때마다 매번 일어납니다. 그래서 실제 서비스에서는 학습 비용보다 ‘매 요청마다 드는 추론 비용’이 더 큰 몫을 차지하며, 구글 ML 입문 강좌와 허깅페이스 강좌에서 학습과 추론을 구분해 다룹니다.

ChatGPT 홈페이지 화면 chatgpt.com 홈페이지

추론이 왜 중요한지는 챗봇 화면에서 선명합니다. ChatGPT에 질문을 넣으면 글자가 한 글자씩 흘러나오는데, 그 흘러나오는 전체 과정이 바로 추론입니다. 모델은 이미 학습이 끝난 상태로 서버에 올라와 있고, 내 질문을 받아 ‘다음에 올 가장 그럴듯한 글자’를 거듭 계산하며 답을 만들어 냅니다. 이 계산이 매 요청마다 일어나기에, 모델이 클수록 한 번 추론하는 데 자원이 많이 듭니다. 4편에서 다룬 GPT · LLM · 오픈소스에서 모델 크기가 성능과 비용을 동시에 좌우한다는 점을 짚었는데, 바로 그 비용의 대부분이 이 추론 단계에서 발생합니다. 즉 추론은 ‘모델이 실제로 일하는 순간’이며, 여기서 얼마나 빠르고 가볍게 답을 내느냐가 서비스의 체감 품질을 가릅니다.

5분 안에 직접 확인하기

  1. chatgpt.com 에서 질문을 넣고 답이 생성되는 과정을 지켜 보세요. 글자가 흘러나오는 그 과정이 ‘추론’이라는 걸 한 줄로 적어 봅니다.
  2. 같은 질문을 두 번 넣어 보세요. 매번 답을 새로 만들어 내는 과정이 매 요청마다 반복되는 추론이라는 점을 체감합니다.
  3. 짧은 질문과 긴 질문을 각각 넣어 보세요. 답이 길어질수록 추론이 더 오래 반복된다는 사실을 관찰하는 것이 추론이 가리키는 ‘답을 만드는 과정’의 바람직한 직관입니다.

잘 안 되는 경우

  • 모델이 너무 커서 한 번 추론에 자원이 많이 드는 경우: 모델이 클수록 답의 품질은 올라지만, 한 번 답을 낼 때마다 드는 계산량도 커집니다. 그래서 품질 좋은 대형 모델은 느리고 비싸며, 빠른 서비스에는 더 작은 모델이 쓰이기도 합니다.
  • 실시간으로 써야 하는데 추론이 느린 경우: 음성 대화·실시간 번역처럼 ‘지금 바로’ 답이 필요한 곳에서는 추론 속도가 품질보다 결정적일 수 있습니다. 모델이 아무리 똑똑해도 답이 늦으면 쓸모가 없는 상황이 생깁니다.

‘답을 내는 과정’을 알았다면, 그 과정이 ‘얼마나 오래 걸리는가’를 따지는 다음 단어로 넘어갑니다.

용어 2: 지연(Latency) — “왜 어떤 AI는 빠른데 어떤 건 버벅거리나?”

이 섹션에서 배우는 것: 지연이 ‘요청부터 응답까지 걸리는 시간’이라는 것, 그래서 체감 품질을 좌우하는 가장 직접적인 지표라는 점.

지연은 기다림의 길이를 재는 단어입니다. 한 줄로 말하면, 요청을 보낸 뒤 응답이 돌아올 때까지 걸리는 시간입니다. 챗봇에서 자주 두 가지로 나뉘어 쓰입니다 — 첫 글자가 뜨기까지의 시간(처음 반응이 오는 속도)과, 답 전체가 완성되기까지의 시간입니다. 전자가 짧으면 “바로 반응한다”고 느끼고, 후자가 짧으면 “빨리 끝난다”고 느낍니다. 둘 다 짧아야 빠르다고 체감하며, 어느 하나라 길면 “버벅거린다”로 다가옵니다.

Gemini 홈페이지 화면 gemini.google.com 홈페이지

지연이 왜 이렇게 들쭉날쭉인지는 몇 가지 요인으로 갈라집니다. 모델이 클수록 한 글자를 만드는 데 계산이 많아 지연이 커지고, 답이 길수록 반복 횟수가 늘어 시간이 길어지며, 서버에 몰리는 요청이 많을수록 내 차례가 늦어집니다. Gemini 같은 도구에서 답을 기다릴 때, 그 멈춤의 길이가 바로 지연입니다. 흔히 오해하는 부분이 있습니다 — “빠른 인터넷”만으로 지연이 해결되지 않는다는 것입니다. 모델 자체가 답을 만드는 데 시간이 걸리므로, 회선이 아무리 빨라도 모델의 계산 시간은 줄지 않습니다. 사이킷런 모델 평가 문서에서 성능과 함께 속도·자원을 함께 따지는 이유이며, Anthropic 연구 페이지에서도 응답 속도가 모델 설계의 중요한 축으로 다뤄집니다. 즉 지연은 ‘품질 좋은 모델’과 ‘빠른 응답’이 충돌하는 가장 직접적인 지점입니다.

5분 안에 직접 확인하기

  1. gemini.google.com 에서 질문을 넣고 첫 글자가 뜨기까지의 멈춤을 재어 보세요. 그 시간이 ‘지연’이라는 단어가 가리키는 기다림의 바람직한 직관입니다.
  2. 같은 도구에서 짧은 질문과 긴 질문을 각각 넣어 보세요. 답이 길어질수록 전체 완성까지의 시간이 늘어난다는 걸 관찰합니다.
  3. 다른 챗봇 하나를 더 열어 같은 질문을 넣어 보세요. 모델마다 첫 반응과 완성 속도가 다르다는 점을 적어 보며, 지연이 ‘어떤 모델을 쓰느냐’에 달려 있다는 걸 체감합니다.

잘 안 되는 경우

  • 실시간 대화처럼 ‘지금 바로’가 필요한 경우: 음성 대화·라이브 번역은 지연이 길면 대화 자체가 끊깁니다. 이런 곳에서는 더 작고 빠른 모델을 쓰거나, 답을 미리 만들어 두는 등 지연을 깎는 설계가 필수입니다.
  • 한 번에 많은 요청이 몰리는 경우: 동시 사용자가 늘면 서버가 바빠져 내 차례가 늦어집니다. 모델 하나의 속도가 빨라도, 몰릴 때는 지연이 급격히 커지는 현상이 흔합니다.

기다림의 길이를 재는 눈을 갖췄다면, 마지막은 ‘한꺼번에 얼마나 많이 감당하느냐’를 따지는 단어입니다.

용어 3: 처리량(Throughput) — “동시에 100명이 써도 버틸까?”

이 섹션에서 배우는 것: 처리량이 ‘단위 시간당 처리하는 요청·작업의 양’이라는 것, 그래서 지연과는 또 다른 문제라는 점.

처리량은 감당의 넓이를 재는 단어입니다. 한 줄로 말하면, 단위 시간당 처리할 수 있는 요청이나 작업의 양입니다. 한 사용자의 한 요청이 얼마나 빨리 끝나는가(지연)와, 동시에 얼마나 많은 요청을 감당하는가(처리량)는 다른 문제입니다. 빠르게 답하더라도 한 번에 한 명만 받으면 많은 사람을 감당할 수 없고, 반대로 동시에 많이 받아도 한 개당 느리면 줄이 길어집니다. 서비스 규모를 이야기할 때 “동시 사용자를 얼마나 감당하느냐”가 곧 처리량의 문제입니다.

Make 홈페이지 화면 make.com 홈페이지

처리량이 결정적인 곳은 한꺼번에 많은 일을 돌려야 하는 자동화입니다. Make 같은 자동화 도구로 수백 개의 작업을 한 번에 돌린다고 해 보세요. 하나하나는 빨라도 동시에 감당하는 양이 적으면 전체가 밀리고, 처리량이 크면 한꺼번에 많은 작업이 흘러갑니다. AI 업무 자동화 3배 (2026)에서 다루듯 자동화의 가치는 ‘한 개의 속도’보다 ‘한꺼번에 얼마나 많이 돌아가느냐’에 달려 있으며, 그것이 처리량의 현실적 의미입니다. 주의할 점은 지연과 처리량이 보통 줄다리기라는 것입니다 — 한 요청에 자원을 몰아붙여 빠르게 답하면(지연↓) 동시에 감당할 수 있는 양은 줄고(처리량↓), 반대로 동시 처리를 늘리면 한 개당 반응이 느려질 수 있습니다. 그래서 실제 서비스는 ‘얼마나 빨리’와 ‘얼마나 많이’ 사이에서 균형을 잡으며, 구독 결정 가이드 (2026)에서 다루는 비용의 상당 부분이 이 처리량을 키우는 데 듭니다. 즉 처리량은 ‘품질 좋은 모델’을 ‘많은 사람에게’ 쓸 수 있게 만드는 관건입니다.

5분 안에 직접 확인하기

  1. make.com 홈페이지를 열어 보세요. 여러 작업을 한 번에 연결해 돌리는 구조를 볼 때, “한 개의 속도”가 아니라 “한꺼번에 얼마나 많이 돌아가느냐”가 처리량이라는 걸 한 줄로 적어 봅니다.
  2. 평소 쓰는 AI 도구에서 사용자가 몰리는 시간대와 한산한 시간대의 반응 속도를 비교해 보세요. 몰릴 때 느려진다면, 그것이 처리량 한계와 닿아 있다는 점을 관찰합니다.
  3. huggingface.co/learn 의 추론·서빙 단원에서 ‘처리량’을 찾아 보세요. 단위 시간당 처리량을 어떻게 재고 키우는지가 정리되어 있어 개념이 또렷해집니다.

잘 안 되는 경우

  • 지연과 처리량이 서로를 끌어내리는 경우: 한 요청을 빠르게(지연↓) 하려 자원을 몰아붙이면 동시 감당량(처리량↓)이 줄고, 반대로 동시 처리를 키우면 한 개당 반응이 느려집니다. 한쪽만 올리면 다른 쪽이 무너지는 줄다리기를 피하기 어렵습니다.
  • 사용량이 예측을 벗어나 급증하는 경우: 처리량을 키우려면 서버 자원을 미리 갖춰야 하지만, 언제 몰릴지 완벽히 예측할 수는 없습니다. 갑작스러운 급증에 대응하지 못하면 지연이 폭증하고 서비스가 무너집니다.

⚠️ 지연과 처리량은 보통 함께 따져야 합니다. 한 개가 빠른 것만으로 ‘많은 사용자를 감당한다’가 되지 않고, 동시 처리량만 커도 ‘한 개가 빠르다’가 되지 않습니다. 두 지표의 균형과 비용은 모델·서버·사용 패턴에 따라 달라지며, 정확한 기준은 각 서비스 공식 문서에서 확인하세요.

세 단어가 이어지는 한 흐름

이 섹션에서 배우는 것: 세 단어가 따로 놀지 않고 ‘답을 내는 과정 → 그 시간 → 동시 감당량’의 한 흐름으로 이어진다는 것.

이 세 단어는 하나의 흐름으로 이어집니다. 학습으로 모델이 만들어지면, 그 모델이 실제로 답을 내놓는 과정이 추론이고, 그 추론 한 번이 걸리는 시간이 지연이며, 단위 시간에 얼마나 많은 추론을 감당하느냐가 처리량입니다. “답을 내는 과정 → 그 시간 → 동시 감당량”의 한 줄로 묶으면, 왜 AI 서비스 개발자가 늘 이 세 단어를 함께 쓰는지가 자리를 잡습니다.

흐름 단계이번 글의 단어하는 일결과가 나타나는 곳
답을 내는 과정추론학습된 모델이 입력을 받아 답을 만듦”질문 넣자 답이 흘러나온다”
그 시간지연요청부터 응답까지 걸리는 시간”첫 글자까지의 멈춤, 완성까지의 기다림”
동시 감당량처리량단위 시간당 감당하는 요청의 양”동시에 많이 써도 버티는가”

이 표를 5편 파라미터 · 어텐션 · 스트리밍과 겹쳐 보면 깊이가 더해집니다. 5편이 모델이 ‘작동하는’ 뼈대를 다뤘다면, 이번 편은 그 뼈대가 ‘얼마나 빨리, 얼마나 많이’ 움직이는가를 다룹니다 — 스트리밍이 답을 조금씩 흘려 보내 지연을 줄여 주는 기술이라면, 처리량은 그 흘림을 동시에 얼마나 많은 사람에게 감당하느냐의 문제입니다. 두 편을 합치면 “왜 품질 좋은 대형 모델이 느리고 비싼지”가 한 그림으로 잡힙니다.

자주 묻는 질문 3가지

Q. 모델이 똑똑할수록 답이 느린가요? 대체로 그런 경향이 있습니다. 모델이 클수록 한 글자를 만드는 데 계산이 많아 지연이 커지고, 추론 비용도 늘어납니다. 그래서 품질과 속도 사이에서 균형을 잡으며, 실시간이 중요한 자리에서는 더 작고 빠른 모델을 쓰기도 합니다. 구글 ML 입문 강좌에서 이 균형을 다룹니다.

Q. 지연과 처리량은 같은 말인가요? 다릅니다. 지연은 ‘한 요청이 얼마나 빨리 끝나는가’이고, 처리량은 ‘동시에 얼마나 많이 감당하는가’입니다. 한 개가 빨라도 동시 감당량이 적으면 많은 사람을 못 쓰게 하고, 반대의 경우도 마찬가지입니다. 둘을 함께 봐야 서비스 품질이 보입니다.

Q. 처리량을 키우면 비용이 많이 드나요? 보통 그렇습니다. 동시에 더 많이 감당하려면 서버 자원을 더 갖춰야 하며, 그것이 서비스 비용의 큰 몫이 됩니다. 그래서 ‘얼마나 빠르게’와 ‘얼마나 많이’ 사이에서 비용을 따지는 일이 중요하며, 허깅페이스 강좌에서 추론·서빙 비용을 함께 다룹니다.

요약

세 단어를 한 문장씩만 기억해도 AI 응답이 다르게 읽힙니다.

  • 추론 → 학습된 모델이 입력을 받아 답을 내는 과정. AI가 ‘실제로 일하는 순간’이며, 매 요청마다 일어난다.
  • 지연 → 요청부터 응답까지 걸리는 시간. 체감 품질을 가장 직접적으로 좌우하는 기다림의 길이.
  • 처리량 → 단위 시간당 감당하는 요청의 양. ‘품질 좋은 모델’을 ‘많은 사람에게’ 쓰게 만드는 관건.

세 단어를 “답을 낸다(추론) → 얼마나 기다리나(지연) → 한꺼번에 얼마나 감당하나(처리량)“의 한 줄로 묶어두면, 다음번에 AI 도구가 “버벅거린다”고 느낄 때 “이게 모델이 커서 느린 건가, 동시에 몰려서 느린 건가?”를 묻게 됩니다. 이번 주에는 한 가지만 해 보세요 — 쓰는 AI 도구에서 답이 느릴 때 “지금 한 개가 느린 건가, 아니면 많이 몰려서 느린 건가?”를 한 줄로 덧붙여 보는 것입니다. 그 작은 질문 하나가 ‘품질 좋은 모델’과 ‘빠른 응답’이 충돌하는 자리를 보는 눈을 키워줍니다. 다음 글에서는 “AI가 스스로 일을 이어가는 힘 — 에이전트 · 도구 사용 · 파이프라인, 자율성이 약속과 위험을 함께 가져오는 까닭”을 이어서 풀 예정입니다.