콘텐츠로 이동

P1-14.6 AI 서비스가 현실에서 만나는 제약

Section ID: P1-14.6 Version: v2026.07.20

P1-14.5에서는 하네스(harness)를 모델과 도구의 실행을 감싸고, 추적(trace), 로그(log), 평가(evaluation)를 가능하게 하는 실행 환경으로 봤습니다. 이제 질문은 조금 더 현실적인 방향으로 바뀝니다.

모델이 답을 만들 수 있다. 도구도 연결할 수 있다. 실행 과정도 기록할 수 있다.

그렇다면 이 구조를 실제 서비스로 계속 쓸 수 있는가?

AI 서비스는 좋은 답변만으로 완성되지 않습니다. 너무 비싸면 지속할 수 없고, 너무 느리면 사용자가 기다리지 않으며, 실패했을 때 설명하거나 복구할 수 없으면 실제 업무에 넣기 어렵습니다.

여기서는 이 문제를 서비스 제약(service constraints)이라는 관점으로 봅니다. 비용(cost), 지연 시간(latency), 처리량(throughput), 사용량 제한(usage limit), 레이트 리밋(rate limit), 재시도(retry), 배치(batch), 캐싱(caching), 모니터링(monitoring)은 모두 이 제약을 이해하기 위한 기본 단어입니다.

이 절에서는 비용(cost), 지연 시간(latency), 처리량(throughput), 레이트 리밋(rate limit), 재시도(retry), 배치(batch), 캐싱(caching), 운영(operation)을 중심으로 실행이 현실 서비스에서 얼마나 오래, 얼마나 자주, 어떤 비용으로 유지될 수 있는지 봅니다. 14.5의 실행 하네스를 이어받고, 보안과 개인정보는 15장에서 다룹니다.

여기서는 AI 서비스를 실제로 사용할 때 고려해야 하는 제약을 개론 수준에서 설명합니다. 보안 정책과 개인정보 처리는 바로 다음 P1-15.1 편향·안전성·책임, P1-15.2 저작권과 학습 데이터, P1-15.3 보안과 개인정보에서 다시 다룹니다. 여기서는 먼저 좋은 답변이 왜 곧바로 서비스 운영 가능성을 뜻하지 않는가를 닫는 데 집중합니다.

비용, 지연 시간, 처리량, 레이트 리밋, 재시도, 배치, 캐싱, 운영은 서로 다른 서비스 제약 요소입니다. 각 용어의 역할은 다음처럼 구분할 수 있습니다.

용어 아주 짧은 뜻 이 절에서의 역할
비용 한 요청과 운영 전체에 드는 자원 소모 지속 가능성 판단 기준
지연 시간 요청 후 응답까지 걸리는 시간 사용자 대기 경험의 핵심
처리량 일정 시간에 처리할 수 있는 요청량 서비스 규모 판단 기준
레이트 리밋 짧은 시간 안의 호출 제한 설계 조건과 장애 원인
재시도 실패 뒤 다시 실행하는 정책 안정성 회복 수단
배치 나중에 묶어서 처리하는 방식 비실시간 작업의 효율화
캐싱 반복 입력의 일부 결과를 재사용하는 방식 비용과 지연 시간 완화 수단
운영 서비스를 반복해서 유지하고 조정하는 일 관찰과 조정의 관점

여기서는 품질 외에 비용과 지연 시간을 함께 봐야 한다는 구분을 기준선으로 둡니다.

주제 이 절에서 볼 질문
비용(cost) 무엇이 비용을 늘리는가?
지연 시간(latency) 사용자는 어디에서 기다리는가?
처리량(throughput) 동시에 얼마나 많은 요청을 처리할 수 있는가?
제한(limit) 사용량과 호출 횟수는 어디에서 막히는가?
실패 대응 실패했을 때 어떻게 다시 시도하거나 멈출 것인가?
운영 관찰 서비스가 잘 동작하는지 무엇을 봐야 하는가?

보안(security), 개인정보(privacy), 저작권(copyright)은 P1-15에서 별도로 다룹니다. 여기서는 “실제로 계속 쓸 수 있는 구조인가”라는 서비스 관점에 집중합니다.

현실 서비스 제약을 읽는 기준

  • AI 서비스의 제약을 비용, 지연 시간, 처리량, 실패 대응으로 나누어 봅니다.
  • 비용(cost)을 토큰(token) 수만이 아니라 모델 선택, 호출 횟수, 도구 사용, 재시도, 평가 실행까지 포함하는 문제로 이해합니다.
  • 지연 시간(latency)을 모델 실행 시간만이 아니라 검색, 도구 호출, 네트워크, 후처리까지 포함한 사용자 대기 시간으로 이해합니다.
  • 레이트 리밋(rate limit), 사용량 제한(usage limit), 재시도(retry)를 서비스 설계의 기본 제약으로 봅니다.
  • 배치(batch), 캐싱(caching), 스트리밍(streaming)을 만능 해법이 아니라 상황별 선택지로 이해합니다.

세 가지 기준

여기서는 기술 구조가 서비스로 이어질 때 무엇이 부딪히는지 정리합니다. 본문을 읽을 때 기준이 되는 세 가지 관점은 다음과 같습니다.

기준 왜 중요한가 이 절에서 필요한 이해 수준
좋은 답변만으로는 서비스가 완성되지 않는다는 점 모델 성능과 운영 가능성을 구분하게 해 줍니다. 품질 외에 비용과 지연 시간도 함께 봐야 한다고 이해합니다.
비용(cost)은 모델 한 번 호출값만이 아니라 전체 흐름에서 생긴다는 점 RAG, 도구 사용, 재시도까지 서비스 비용으로 읽게 해 줍니다. 토큰 수 외에도 검색, 평가, 실패 재시도가 비용을 만든다고 이해합니다.
지연 시간(latency)과 실패 대응도 설계의 일부라는 점 실제 사용자 경험과 운영 안정성을 함께 보게 해 줍니다. 느리거나 자주 실패하면 좋은 모델도 서비스로 쓰기 어렵다고 이해합니다.

좋은 답변만으로는 부족하다

처음에는 모델이 “좋은 답을 하는가”에 먼저 관심이 갑니다. 그러나 서비스로 만들면 질문이 바뀝니다.

학습 단계의 질문 서비스 단계의 질문
답변이 맞는가? 같은 품질을 반복적으로 낼 수 있는가?
설명이 자연스러운가? 사용자가 기다릴 수 있는 시간 안에 응답하는가?
더 똑똑한 모델을 쓰면 되는가? 비용과 지연 시간이 허용 범위 안에 있는가?
도구를 많이 붙이면 좋아지는가? 도구 호출 실패와 권한 문제를 다룰 수 있는가?
로그와 평가를 남기면 충분한가? 로그와 평가 자체가 만드는 비용과 위험을 감당할 수 있는가?

따라서 AI 서비스는 다음 세 가지를 동시에 봐야 합니다.

품질(quality) 비용(cost) 대기 시간과 안정성(latency and reliability)

품질만 높이고 비용과 지연 시간을 무시하면 실험은 될 수 있어도 서비스는 되기 어렵습니다. 반대로 비용만 줄이면 답변 품질이나 안전성이 떨어질 수 있습니다.

비용은 토큰만의 문제가 아니다

LLM 서비스에서 토큰(token)은 비용을 이해하는 중요한 단위입니다. 입력이 길고 출력이 길수록 더 많은 계산이 필요하고, 대체로 비용과 지연 시간도 늘어납니다. 하지만 비용을 토큰 수만으로 이해하면 부족합니다.

비용을 만드는 요소 설명
모델 선택(model choice) 큰 모델은 더 좋은 결과를 낼 수 있지만 비용과 지연 시간이 커질 수 있음
입력 토큰(input tokens) 긴 프롬프트, 긴 문서, 많은 검색 결과가 비용을 늘림
출력 토큰(output tokens) 긴 답변, 긴 코드, 긴 보고서가 비용을 늘림
호출 횟수(request count) 한 요청 안에서 모델을 여러 번 호출하면 비용이 누적됨
도구 호출(tool call) 검색, 데이터베이스, 외부 API 호출이 별도 비용과 시간을 만들 수 있음
재시도(retry) 실패한 요청을 다시 보내면 성공 여부와 별개로 비용이 늘 수 있음
평가 실행(eval run) 품질 검증을 위해 반복 실행하는 평가도 비용을 만듦

OpenAI의 비용 최적화 문서는 비용과 지연 시간이 보통 서로 연결되어 있고, 토큰과 요청을 줄이면 처리도 빨라지는 경향이 있다고 설명합니다. 또한 더 작은 모델 선택, 프롬프트 캐싱(prompt caching), 배치 처리(batch processing) 같은 선택지를 제시합니다. 여기서는 특정 서비스의 가격을 외우기보다, 어떤 설계 선택이 비용을 만드는지 보는 데 초점을 둡니다.

지연 시간은 모델만의 시간이 아니다

지연 시간(latency)은 사용자가 요청을 보낸 뒤 응답을 받기까지 기다리는 시간입니다. AI 서비스에서는 이 시간이 모델 실행(inference)만으로 결정되지 않습니다.

사용자 요청 -> 입력 검증 -> 검색 또는 데이터 조회 -> 모델 호출 -> 도구 호출 -> 다시 모델 호출 -> 후처리 -> 사용자 응답

각 단계가 조금씩 늦어지면 전체 응답은 크게 느려집니다.

지연 시간을 만드는 요소 예
네트워크(network) API 요청과 응답이 오가는 시간
검색(retrieval) 벡터 검색, 데이터베이스 조회, 문서 로딩
모델 실행(model inference) 입력을 처리하고 출력을 생성하는 시간
출력 길이(output length) 긴 답변을 생성할수록 오래 걸릴 수 있음
도구 호출(tool call) 외부 API나 파일 작업이 느릴 수 있음
후처리(post-processing) 형식 검증, 안전성 검사, 저장

스트리밍(streaming)은 사용자가 전체 답변이 끝날 때까지 기다리지 않고 일부 출력을 먼저 볼 수 있게 합니다. 이는 체감 대기 시간을 줄이는 데 도움이 됩니다. 다만 스트리밍이 모든 계산을 없애는 것은 아닙니다. 사용자는 빨리 보기 시작하지만, 전체 작업이 완료되는 시간은 여전히 모델, 도구, 네트워크, 후처리의 영향을 받습니다.

프롬프트 캐싱(prompt caching)도 지연 시간과 비용을 줄이는 선택지가 될 수 있습니다. 특히 매번 반복되는 긴 시스템 지시문이나 공통 문맥이 있을 때, 같은 접두부(prefix)를 재사용하면 효과가 날 수 있습니다. 그러나 캐싱은 입력이 같은 구조로 반복될 때 유리하며, 모든 요청에 자동으로 같은 효과를 보장하지는 않습니다.

제한은 장애가 아니라 설계 조건이다

서비스 제공자는 보통 사용량 제한(usage limit)과 레이트 리밋(rate limit)을 둡니다. 레이트 리밋은 일정 시간 동안 처리할 수 있는 요청 수나 토큰 수의 제한입니다. 사용량 제한은 월별 또는 프로젝트별 사용량 한도처럼 더 넓은 제한일 수 있습니다.

이 제한은 단순한 불편이 아니라 서비스 설계 조건입니다.

제한 설계에서 생기는 질문
요청 수 제한(request limit) 동시에 많은 사용자가 오면 어떻게 할 것인가?
토큰 제한(token limit) 긴 문서와 긴 답변을 어떻게 줄일 것인가?
사용량 한도(usage limit) 예산을 넘기기 전에 어떻게 멈출 것인가?
모델별 제한(model-specific limit) 특정 모델이 막히면 대체 경로가 있는가?
배치 제한(batch limit) 비실시간 작업을 어떻게 따로 처리할 것인가?

OpenAI의 레이트 리밋 문서는 제한이 조직, 프로젝트, 모델 단위로 적용될 수 있고, 응답 헤더를 통해 남은 요청 수나 토큰 수, 초기화 시간을 확인할 수 있음을 설명합니다. 또한 실패한 요청도 제한 계산에 포함될 수 있으므로, 무작정 반복 재시도하면 상황을 더 나쁘게 만들 수 있습니다.

그래서 재시도(retry)는 규칙이 필요합니다. 흔히 쓰이는 방식은 지수 백오프(exponential backoff)와 지터(jitter)입니다. 실패하면 즉시 계속 반복하는 대신, 점점 더 긴 간격을 두고 다시 시도하고, 여러 클라이언트가 동시에 몰리지 않도록 약간의 무작위 지연을 섞습니다.

나쁜 재시도: 실패 -> 즉시 재시도 -> 즉시 재시도 -> 즉시 재시도

더 나은 재시도: 실패 -> 잠깐 대기 -> 재시도 -> 더 길게 대기 -> 재시도 -> 중단 또는 사용자 안내

실시간 작업과 배치 작업은 다르다

모든 AI 작업이 즉시 응답해야 하는 것은 아닙니다. 사용자가 대화창에서 기다리는 작업은 실시간(interactive) 작업에 가깝습니다. 반면 대량 문서 분류, 임베딩 생성, 평가 실행, 데이터 보강처럼 나중에 결과를 받아도 되는 작업은 배치(batch) 작업으로 볼 수 있습니다.

작업 유형 특징 예
실시간 작업(interactive work) 사용자가 기다림 챗봇 응답, 코드 보조, 검색 질의
배치 작업(batch work) 나중에 결과를 받아도 됨 문서 일괄 분류, 임베딩 생성, 평가 실행

OpenAI Batch API 문서는 비동기 요청 묶음을 처리하고, 즉시 응답이 필요하지 않은 작업에서 비용 효율과 별도 처리 한도를 활용할 수 있음을 설명합니다. 이 관점은 특정 API 사용법보다 더 일반적인 교훈을 줍니다.

사용자가 지금 기다리는 일인가? 아니면 나중에 처리해도 되는 일인가?

이 질문만 분리해도 서비스 구조가 달라집니다.

운영은 도구 이름이 아니라 반복 사용의 조건이다

여기서 운영(operation)은 DevOps나 MLOps 전체 방법론을 뜻하지 않습니다. 여기서는 더 좁게, “AI 서비스를 반복해서 사용할 수 있게 유지하는 조건”으로 봅니다.

운영 관점에서 최소한 확인해야 할 것은 다음과 같습니다.

관찰할 것 이유
오류율(error rate) 어떤 요청이 자주 실패하는지 확인
지연 시간(latency) 사용자가 기다리는 시간이 늘어나는지 확인
비용(cost) 예산을 초과하거나 특정 기능이 과도하게 비싼지 확인
토큰 사용량(token usage) 입력과 출력이 불필요하게 길어지는지 확인
도구 실패(tool failure) 외부 API, 파일, 데이터베이스 문제가 있는지 확인
품질 지표(quality metric) 모델이나 프롬프트 변경 후 품질이 떨어졌는지 확인

OpenAI의 프로덕션 모범 사례 문서는 모델 모니터링(model monitoring), 데이터와 모델 관리, 재학습, 배포 자동화 같은 항목을 운영 단계의 고려 사항으로 제시합니다. 여기서는 그중 “실행 후에도 계속 관찰하고 조정해야 한다”는 점만 가져옵니다.

작은 서비스에서 먼저 정할 기준

큰 운영 체계를 처음부터 만들 필요는 없습니다. 작은 AI 기능이라도 다음 기준은 먼저 정해 두는 쪽이 안정적입니다.

기준 예시 질문
응답 시간 목표 사용자는 몇 초까지 기다릴 수 있는가?
최대 출력 길이 답변은 어느 정도 길이로 제한할 것인가?
최대 도구 호출 수 한 요청에서 도구를 몇 번까지 호출할 것인가?
재시도 정책 몇 번까지 다시 시도하고 언제 멈출 것인가?
예산 기준 하루 또는 한 달 사용량을 어떻게 감시할 것인가?
실패 안내 실패했을 때 사용자에게 무엇을 말할 것인가?
평가 기준 변경 후 어떤 사례로 품질을 확인할 것인가?

예를 들어 문서 기반 Q&A 기능을 만든다면 다음처럼 시작할 수 있습니다.

응답은 가능하면 5초 안에 시작한다. 검색 문서는 최대 5개까지만 넣는다. 답변은 1차로 800자 이내로 제한한다. 도구 호출은 한 요청에 3회까지 허용한다. 레이트 리밋 오류는 최대 2회 재시도한다. 출처가 없으면 답변하지 않고 확인 필요로 표시한다.

이 값들은 정답이 아닙니다. 서비스의 목적, 사용자, 예산, 위험도에 따라 달라집니다. 중요한 것은 처음부터 기준을 문서화하고, 나중에 trace, log, evaluation으로 조정할 수 있게 만드는 것입니다.

한 요청이 실제로 지나가는 전체 흐름

Chapter 14에서 본 요소들은 실제 요청 하나 안에서 함께 엮입니다. 문서 기반 업무 도우미를 예로 들면, 사용자는 겉으로는 질문 한 번만 던지지만 내부에서는 여러 단계가 이어질 수 있습니다.

사용자 질문 -> 권한 확인 -> 관련 문서 검색 -> 프롬프트 구성 -> 모델 호출 -> 필요하면 도구 호출 -> 결과 검토와 기록 -> 사용자 응답

예를 들어 사용자가 이렇게 요청한다고 해 봅니다.

지난주 회의록에서 결정 사항만 찾아서 일정표 초안을 만들고, 필요한 일정은 캘린더에 추가해 줘.

이 요청은 다음처럼 나눠 읽을 수 있습니다.

단계 내부에서 하는 일 여기서 중요한 제약
권한 확인 사용자가 회의록과 캘린더에 접근할 수 있는지 확인 보안, 개인정보, 승인 조건
검색 회의록 파일과 관련 문단을 찾음 검색 지연 시간, 잘못된 문서 선택 위험
모델 1차 호출 결정 사항과 일정 후보를 추출함 모델 비용, 출력 길이, 해석 오류
도구 호출 캘린더 API에 일정 초안을 등록함 권한, 실패 재시도, 외부 상태 변경
검토와 기록 어떤 문서를 썼고 무엇을 등록했는지 남김 로그 비용, 재현성, 감사 가능성
사용자 응답 등록 결과와 근거를 보여 줌 응답 시간, 설명 가능성

이 흐름에서 Chapter 14의 앞 절들이 각각 어디에 놓이는지도 다시 보입니다.

Chapter 14의 요소 이 요청 안에서 맡는 역할
RAG 회의록과 관련 문서를 찾아 모델 입력에 붙임
도구 사용(tool use) 캘린더 API 호출로 실제 일정을 등록함
에이전트(agent) 검색, 추출, 호출, 보고 단계를 이어 감
MCP 도구와 데이터 연결 방식을 표준화할 수 있음
하네스(harness) 어떤 검색, 호출, 결과가 있었는지 추적하고 평가함
서비스 제약(service constraints) 비용, 지연 시간, 재시도, 승인 조건을 설계 기준으로 만듦

이 종합 사례의 핵심은 좋은 모델 하나가 곧바로 운영 가능한 서비스가 아니라는 점입니다. 실제 서비스는 읽기, 판단, 실행, 검토, 기록, 제약 관리가 한 요청 안에서 함께 움직이는 구조입니다. 그래서 Chapter 14를 다 읽고 남아야 할 최소 감각은 한 요청도 내부에서는 여러 구성요소가 협력하는 워크플로우라는 점입니다.

체크리스트

  • AI 서비스 제약(service constraints)을 비용, 지연 시간, 처리량, 실패 대응으로 나누어 설명할 수 있다.
  • 비용(cost)이 토큰(token) 수뿐 아니라 모델 선택, 호출 횟수, 도구 호출, 재시도, 평가 실행과 연결됨을 설명할 수 있다.
  • 지연 시간(latency)이 모델 실행만이 아니라 검색, 도구 호출, 네트워크, 후처리까지 포함함을 설명할 수 있다.
  • 스트리밍(streaming), 캐싱(caching), 배치(batch)를 상황별 선택지로 설명할 수 있다.
  • 레이트 리밋(rate limit)과 사용량 제한(usage limit)을 장애가 아니라 설계 조건으로 설명할 수 있다.
  • 재시도(retry)에는 지수 백오프(exponential backoff)와 지터(jitter) 같은 정책이 필요함을 설명할 수 있다.
  • 운영(operation)을 특정 도구 이름이 아니라 반복 사용을 위한 관찰과 조정 조건으로 설명할 수 있다.
  • 작은 AI 기능에도 응답 시간, 출력 길이, 도구 호출 수, 재시도, 예산, 실패 안내 기준이 필요함을 설명할 수 있다.
  • 품질, 비용, 지연 시간과 안정성을 함께 설계 조건으로 설명할 수 있다.

출처와 참고 자료