6부 28장. 비용, 속도, 정확도의 균형

2026-04-23Views 6약 10분생성형 AI 활용

6부 28장. 비용, 속도, 정확도의 균형

에이전트를 만들다 보면 어느 순간 아주 익숙한 유혹이 찾아온다.

"더 똑똑한 모델로 바꾸면 되지 않을까?"

물론 때로는 맞는 말이다. 하지만 제품을 운영하는 입장에서는 그다음 질문이 바로 따라와야 한다.

"그래서 사용자는 더 행복해졌나?"

정확도가 조금 올랐는데 응답 시간이 두 배가 되고, 한 번 처리할 때마다 비용이 세 배가 되었다면 그건 성능 향상일 수는 있어도 제품 향상이라고 보기는 어렵다. 반대로 답변이 아주 조금 덜 정교해졌더라도 사용자가 1초 안에 원하는 일을 끝내고, 실패율이 낮아지고, 운영비가 감당 가능해졌다면 그쪽이 더 좋은 설계일 수 있다.¹²

이 장에서 말하는 핵심은 단순하다. 에이전트 시스템은 벤치마크 점수를 최적화하는 것이 아니라, 제품의 목적 함수를 최적화해야 한다는 것이다. 그 목적 함수에는 정확도만 들어 있지 않다. 기다림, 비용, 실패 복구, 사용자 신뢰, 운영 여유까지 함께 들어간다.³⁴

6부 28장. 비용, 속도, 정확도의 균형

왜 이 셋은 늘 함께 움직이는가

속도, 정확도, 비용은 대개 서로 사이좋게 올라가지 않는다. 보통 하나를 올리면 다른 하나가 따라 흔들린다. 더 큰 모델은 대체로 더 정확하지만 더 느리고 더 비싸다. 여러 단계로 더 오래 생각하게 하면 복잡한 문제에서는 성능이 좋아질 수 있지만, 호출 수와 토큰 수가 늘어나면서 지연과 비용도 함께 뛴다.³⁵

이 관계를 너무 추상적으로 생각할 필요는 없다. 일상적인 비유로 보면 쉽다. 택배를 보내는데 당일 특급, 안전 포장, 최저 요금을 동시에 달성하기는 어렵다. 어딘가에서는 선택이 필요하다. 에이전트도 똑같다.

특히 프로덕션 환경에서는 이 셋이 단순한 취향 문제가 아니다. 대화형 고객지원처럼 사용자가 화면 앞에서 기다리는 제품은 몇 초의 차이만으로도 체감 품질이 크게 바뀐다. 반면 계약서 검토나 공급망 계획처럼 시간이 조금 걸려도 되는 업무는 더 긴 추론과 더 높은 정확도를 정당화할 수 있다.²⁶

즉, 좋은 설계란 "무조건 빠른 것"도 아니고 "무조건 정확한 것"도 아니다. 어떤 요청에 얼마만큼의 지연과 비용을 허용할지 먼저 정하고, 그 예산 안에서 가장 높은 성공 확률을 만드는 것이다.²⁷

성능 최적화가 아니라 제품 최적화여야 하는 이유

엔지니어는 종종 시스템 안쪽을 본다. 토큰 수를 줄이고, 병렬성을 높이고, 캐시를 늘리고, 더 강한 모델을 붙인다. 다 중요하다. 하지만 제품은 바깥에서 평가된다. 사용자는 내부 아키텍처를 보지 않는다. 그 사람에게 중요한 것은 세 가지뿐이다.

잘 되느냐, 빨리 되느냐, 믿을 만하냐.

여기서 "잘 된다"는 말도 상황에 따라 뜻이 다르다. 실시간 음성 비서는 약간 덜 완벽해도 빠른 반응이 중요하다. 반대로 환불 승인, 대출 심사, 의료 문서 정리처럼 오류 비용이 큰 작업은 조금 느려도 더 정확하고 더 보수적으로 움직여야 한다.⁴⁶

그래서 제품 최적화는 먼저 업무의 성격을 묻는다.

간단한 분류인가, 복잡한 추론인가.

사용자가 화면 앞에서 기다리는가, 백그라운드 작업인가.

틀렸을 때 불편한가, 위험한가.

한 건당 몇 원까지 감당 가능한가.

사람 검토가 붙는가, 완전 자동화인가.⁷

이 질문 없이 "최고 성능 모델"부터 고르면 거의 항상 과설계나 과금 폭탄으로 이어진다. 에이전트에서 가장 비싼 실수는 모델이 멍청한 것이 아니라, 쉬운 일에도 늘 최고급 추론을 쓰는 것이다.

먼저 예산을 정하라: latency budget, cost budget, error budget

좋은 설계는 보통 기술 스택보다 예산에서 시작한다. 예산이라고 하면 돈만 떠올리기 쉽지만, 에이전트 시스템에는 적어도 세 가지 예산이 있다.

첫째는 latency budget이다. 이 요청은 사용자가 몇 초까지 기다릴 수 있는가. 단순 질의는 1초 안쪽이 중요할 수 있고, 복잡한 워크플로는 몇 초를 허용할 수 있다. 음성 인터페이스라면 더 엄격하다.⁴

둘째는 cost budget이다. 한 번의 성공한 작업을 만드는 데 얼마까지 쓸 수 있는가. 여기서 중요한 것은 단순 호출당 비용이 아니라 성공 1건당 비용이다. 실패한 재시도, 불필요한 검색, 과도한 반성 루프까지 모두 포함해서 봐야 한다.²⁴

셋째는 error budget이다. 어느 정도의 실수를 자동화가 감수할 수 있는가. 검색 요약에서는 작은 실수가 용인될 수 있지만, 결제 실행이나 권한 변경에서는 작은 실수도 크다. 오류 비용이 높은 곳일수록 더 깊은 추론, 더 강한 검증, 사람 승인, 더 보수적인 fallback이 필요하다.⁶⁷

이 세 가지 예산이 정해지면 설계가 쉬워진다. "가장 좋은 모델이 뭐냐"가 아니라 "이 예산 안에서 어떤 조합이 가장 낫냐"로 질문이 바뀌기 때문이다.

모델 선택: 하나의 왕모델보다 계층이 낫다

많은 팀이 처음에는 한 모델로 모든 문제를 해결하려고 한다. 작을 때는 괜찮다. 하지만 운영으로 가면 요청의 난이도가 제각각이라는 사실이 드러난다. 쉬운 요청, 애매한 요청, 정말 어려운 요청이 한 줄로 섞여 들어온다. 이때 모든 요청을 가장 비싸고 가장 느린 모델로 처리하면 낭비가 심하다.²³

그래서 실무에서는 티어드 모델 전략이 자주 쓰인다. 가벼운 모델은 분류, 라우팅, 간단한 추출, 형식 변환처럼 빠르고 싼 일을 맡는다. 더 큰 모델은 애매한 케이스, 복잡한 추론, 최종 합성처럼 정말 필요한 순간에만 호출한다.³⁸

이 구조의 장점은 단순히 비용 절감이 아니다. 전체 평균 응답 시간을 낮추면서도 어려운 요청의 품질을 지킬 수 있다. 쉬운 요청은 미니 모델이 재빨리 처리하고, 어려운 요청만 큰 모델로 넘기면 된다. 마치 병원 응급실에서 모든 환자를 바로 수술실로 보내지 않는 것과 비슷하다. 먼저 분류하고, 정말 필요한 경우에만 고급 자원을 쓴다.

모델 선택에서 자주 놓치는 점은 정확도 상승 곡선이 선형이 아니라는 것이다. 더 비싼 모델이 언제나 체감 품질을 같은 비율로 올려 주지는 않는다. 어떤 구간에서는 비용 두 배, 속도 두 배를 써도 제품 성과는 거의 안 바뀔 수 있다. 반대로 적절한 라우팅만 잘 붙여도 비용은 줄이고 체감 품질은 유지할 수 있다.³

따라서 모델 선택의 정답은 "최고 모델"이 아니라, 요청 난이도별로 다른 모델을 배치하는 구조인 경우가 많다.²⁷

추론 깊이: 오래 생각하면 다 좋아질까

에이전트 세계에는 "한 번 더 생각해 봐"라는 마법 주문이 있다. 실제로 복잡한 문제에서는 더 많은 추론 단계, 더 많은 도구 확인, 더 많은 자기 검토가 성능을 높여 준다. 하지만 이 방법은 공짜가 아니다. 매 단계마다 토큰이 쌓이고, 컨텍스트가 길어지고, 호출 수가 증가한다. 결국 비용과 지연이 빠르게 늘어난다.²

특히 멀티턴 루프에서는 입력 컨텍스트가 계속 누적되기 때문에, 한 번의 추가 반성이 단순히 한 번의 비용만 더하는 것이 아니다. 뒤의 모든 호출을 더 무겁게 만든다. 그래서 통제 없는 루프는 품질 향상 장치이기도 하지만 동시에 비용 증폭기이기도 하다.²

이때 유용한 개념이 thinking budget, 즉 생각 예산이다. 모든 요청에 깊은 추론을 허용하는 대신, 요청의 난이도와 위험도에 따라 얼마나 오래 생각할지 다르게 배분하는 방식이다.²

예를 들어 배송 조회처럼 구조가 단순한 일은 짧은 경로로 끝낸다. 반면 복잡한 일정 조율이나 여러 시스템을 넘나드는 문제 해결은 더 많은 단계와 검토를 허용한다. 핵심은 "항상 깊게"가 아니라 깊어야 할 때만 깊게다.

또 하나 중요한 원칙은 동적 종료다. 최대 5턴까지 허용한다고 해서 반드시 5턴을 다 써야 하는 것은 아니다. 추가 한 번의 시도가 성공 확률을 거의 올리지 못한다면 그 루프는 멈추는 편이 낫다. 재시도나 자기 반성이 실패를 고치는 경우도 있지만, 어떤 경우에는 같은 실수를 더 비싸게 반복할 뿐이다.²⁹

좋은 에이전트는 생각을 많이 하는 에이전트가 아니라, 필요한 만큼만 생각하는 에이전트다.

병렬성: 시간을 줄이지만 공짜는 아니다

병렬 처리는 에이전트 설계에서 가장 매력적인 카드 중 하나다. 검색 두 개를 동시에 돌리고, 여러 문서를 동시에 요약하고, 서로 독립적인 도구 호출을 한꺼번에 실행하면 전체 대기 시간을 크게 줄일 수 있다.¹⁰¹¹

이런 장점 때문에 병렬 처리는 종종 만능 해결책처럼 보인다. 하지만 실제로는 두 가지 비용이 따라온다.

첫째는 즉시 비용 증가다. 동시에 세 개의 모델 호출을 날리면 체감 지연은 줄어들 수 있어도 비용은 보통 세 배에 가깝게 올라간다. 둘째는 합성 복잡도다. 병렬로 모은 결과를 다시 합쳐야 하는데, 서로 충돌하거나 중복될 수 있다. 결국 마지막 단계에 또 하나의 지능 비용이 필요해진다.¹⁰¹¹

그래서 병렬성은 이런 경우에 특히 유리하다. 서로 독립적인 정보원을 조회할 때, 여러 평가 관점을 동시에 모을 때, 사용자가 기다리는 시간이 아주 중요할 때다. 반대로 앞 단계 결과가 뒤 단계 입력이 되는 순차 작업을 억지로 병렬화하면 오히려 오류와 낭비가 늘어난다.¹⁰

간단히 말하면 이렇다. 병렬성은 지연을 돈으로 사는 기술이다. 그 거래가 가치 있는 상황에서만 써야 한다.

예를 들어 상품 리뷰 분석에서 감정, 장단점, 추천 여부를 따로 뽑는 일은 병렬화가 잘 맞는다. 하지만 환불 정책을 먼저 조회해야만 다음 결정을 내릴 수 있는 워크플로는 순차적 경로가 더 자연스럽다. 구조가 독립적인지 아닌지부터 봐야 한다.

캐싱: 가장 싼 추론은 다시 하지 않는 추론이다

많은 팀이 비용을 줄이려 할 때 먼저 모델을 바꾸거나 프롬프트를 줄인다. 물론 도움이 된다. 하지만 종종 더 큰 효과를 주는 것은 이미 한 일을 다시 하지 않는 것이다.

캐싱에는 여러 층이 있다. 가장 단순한 것은 응답 캐시다. 완전히 같은 요청, 혹은 거의 같은 요청에 대해 이전 결과를 재사용한다. 그다음은 프롬프트 캐시다. 긴 시스템 지시문이나 공통 컨텍스트를 반복해서 보내야 할 때, 매번 처음부터 처리하지 않게 한다. 또 하나는 워크플로 캐시다. 검색 결과, 문서 임베딩, 중간 요약, 성공한 실행 계획 같은 중간 산출물을 재사용하는 방식이다.²¹²

특히 오케스트레이터-워커 구조처럼 여러 워커가 비슷한 공통 문맥을 공유하는 경우 프롬프트 캐시는 엄청난 차이를 만든다. 긴 규칙과 배경지식을 매번 새로 먹이는 대신, 공통 접두를 재사용하면 지연도 줄고 비용도 크게 줄어든다.²

여기서 한 발 더 나가면 메모리 레이어가 나온다. 단순히 같은 질문의 답을 저장하는 것이 아니라, 과거에 성공했던 계획이나 비슷한 문제의 해결 절차를 기억해 두고 재사용하는 것이다. "이전에 비슷한 요청을 어떻게 해결했지?"를 먼저 묻는 구조다. 잘 맞으면 아주 비싼 계획 수립 단계를 건너뛸 수 있다.²¹²

다만 캐시는 마법이 아니다. 오래된 결과를 그대로 재사용하면 오답을 더 빠르게 내놓을 수 있다. 그래서 캐시에는 TTL, 무효화 규칙, 버전 구분이 필요하다. 가격, 재고, 정책처럼 변하는 정보는 특히 조심해야 한다. 캐시는 비용 절감 장치인 동시에, 잘못 쓰면 오래된 확신을 빠르게 배포하는 장치가 된다.

컨텍스트를 줄이는 것도 최적화다

에이전트의 비용은 모델 이름만으로 결정되지 않는다. 컨텍스트 길이도 큰 영향을 준다. 긴 대화 기록, 불필요한 로그, 같은 파일의 반복 첨부, 쓸모없는 도구 결과가 계속 쌓이면, 매 턴마다 모델은 커진 짐가방을 들고 다시 뛰어야 한다.⁸¹³

그래서 컨텍스트 최적화는 성능 튜닝이 아니라 아키텍처 설계의 일부다. 대표적인 방법이 trim과 compression이다. 지금 작업에 꼭 필요한 것만 남기고 나머지는 잘라내거나, 긴 기록을 짧은 작업 요약으로 압축하는 방식이다.¹³

이 원칙은 생각보다 중요하다. 에이전트가 똑같이 세 번 실수했는데 그 세 번의 실패 기록을 계속 본문에 다 들고 다닌다면, 모델은 실수에서 배우기 전에 비용부터 많이 낸다. 실패는 기억해야 하지만, 토큰 단위의 원본 전사를 늘 들고 다닐 필요는 없다. 핵심 상태와 교훈만 남기면 된다.

결국 컨텍스트 엔지니어링의 목적도 같다. 더 많이 넣는 것이 아니라 지금 필요한 것만 정확히 넣는 것이다.

재시도 정책: 끈기는 미덕이지만, 무지성 재시도는 청구서다

프로덕션 에이전트는 반드시 실패한다. 네트워크가 느려질 수도 있고, 외부 API가 잠시 죽을 수도 있고, 정책 검사 서비스가 지연될 수도 있다. 그래서 재시도는 필요하다. 문제는 대부분의 시스템이 재시도를 너무 쉽게, 너무 많이, 너무 똑같이 한다는 데 있다.⁹¹⁴

좋은 재시도 정책의 첫 원칙은 마감 시간부터 정하는 것이다. 전체 실행이 최대 몇 초까지 허용되는지 정하지 않으면, 재시도는 사용자와 운영자의 의도를 넘어 계속 살아남는다. 먼저 run deadline을 정하고, 그 안에서 단계별 timeout과 재시도 횟수를 배분해야 한다.⁹

둘째 원칙은 오류 분류다. 모든 실패가 재시도 대상은 아니다. 일시적 타임아웃, 429, 일부 5xx 오류는 재시도가 의미 있을 수 있다. 하지만 잘못된 도구 이름, 잘못된 인자 스키마, 권한 부족, 비멱등 쓰기 실패는 같은 요청을 그대로 다시 보내 봐야 달라질 가능성이 작다.⁹¹⁵¹⁶

셋째는 backoff와 jitter다. 실패하자마자 여러 워커가 동시에 재시도하면, 이미 아픈 의존성을 더 세게 두드리는 꼴이 된다. 조금씩 간격을 늘리고, 서로 다른 무작위 지연을 섞어야 한다.⁹¹⁴

넷째는 budgeted retry다. 재시도는 보험이지, 인생 철학이 아니다. 작업당 최대 몇 번, 도구당 얼마의 예산, 전체 시스템에서 어느 정도의 재시도 창을 허용할지 명확해야 한다.⁹¹⁴

에이전트에서는 여기에 한 가지가 더 붙는다. 회복 가능한 실수와 구조적 실수를 구분해야 한다는 점이다. 존재하지 않는 도구를 반복 호출하거나, 영원히 실패할 인자를 들고 같은 API를 두드리는 것은 회복이 아니라 낭비다. 이런 경우에는 재시도가 아니라 즉시 수정 경로, 대체 경로, 혹은 종료가 필요하다.¹⁵

회로 차단기와 fallback: 실패를 빨리 인정하는 용기

특정 도구나 외부 서비스가 계속 실패할 때, 좋은 시스템은 이를 빨리 인정한다. 이것이 circuit breaker의 역할이다. 실패가 일정 기준을 넘으면 그 의존성으로 가는 길을 잠시 닫고, 빠르게 대체 경로로 보내는 것이다.¹⁴

이 패턴이 중요한 이유는 명확하다. 에이전트는 사람보다 성실하다. 그래서 망가진 도구를 사람보다 훨씬 더 열심히 계속 호출할 수 있다. 그리고 그 성실함은 곧 비용과 장애 전파로 바뀐다.

fallback도 마찬가지다. 모든 상황에서 최고 품질을 유지하려고 버티는 것보다, 경우에 따라 더 작은 모델로 내려가거나, 선택적 단계를 생략하거나, 캐시된 결과를 보여 주거나, 사람 검토로 넘기는 편이 전체 제품 경험에는 더 나을 수 있다.¹⁴

중요한 점은 fallback을 "품질 포기"로 보지 않는 것이다. 오히려 제품 관점에서는 아무 답도 못 주는 것보다, 제한된 답을 예측 가능하게 주는 것이 더 낫다. 다만 그 제한이 사용자에게 명확해야 한다. "실시간 요금 조회가 불가해 임시 안내만 제공한다"처럼 말이다.

결국 설계는 라우팅 문제다

지금까지의 내용을 한 줄로 줄이면 거의 항상 라우팅 문제로 귀결된다. 어떤 요청을 어떤 경로로 보낼 것인가.

쉬운 요청은 빠르고 싼 경로.

애매한 요청은 보강된 경로.

복잡하고 위험한 요청은 깊은 추론과 검증 경로.

실패한 요청은 재시도 경로 또는 사람 승인 경로.

이미 풀어 본 요청은 메모리 또는 캐시 경로.²⁷

이 구조가 없으면 시스템은 늘 한 가지 방식으로만 반응한다. 마치 동네 편의점에서 생수 한 병을 사도 정장 입은 세 명이 결재 위원회를 여는 꼴이다. 사용자는 웃을지 몰라도, 운영자는 울게 된다.

좋은 에이전트 제품은 요청을 공평하게 대하지 않는다. 합리적으로 차별한다. 쉬운 일은 가볍게, 어려운 일은 무겁게, 위험한 일은 조심스럽게 다룬다. 그 차등 배분이 곧 제품 최적화다.

세 가지 예시로 보는 균형점

실시간 고객지원 에이전트

고객지원은 보통 지연에 민감하다. 사용자는 채팅창에서 오래 기다리지 않는다. 여기서는 첫 응답 속도가 아주 중요하고, 대부분의 요청은 배송 조회, 환불 규정 안내, 계정 상태 확인처럼 비교적 구조화되어 있다. 따라서 가벼운 모델로 분류와 기본 응답을 처리하고, 필요한 경우에만 더 강한 모델이나 추가 도구 체인을 붙이는 구조가 적합하다. 병렬 검색은 필요한 최소 범위로만 쓰고, 실패 시에는 사람 상담 전환을 빠르게 제공하는 편이 좋다.²⁴

이 경우 최고의 설계는 가장 정확한 답변이 아니라, 짧은 시간 안에 충분히 정확하고 안전한 답변을 안정적으로 주는 설계다.

내부 운영 자동화 에이전트

사내 리포트 생성, 데이터 정리, 문서 초안 작성 같은 내부 업무 자동화는 상대적으로 몇 초의 지연을 더 허용할 수 있다. 대신 비용 규모와 처리량이 중요하다. 여기서는 캐싱, 배치 처리, 중간 결과 재사용, 컨텍스트 압축이 큰 효과를 낸다. 사람이 최종 검토를 하는 경우가 많으므로 완전한 정확도보다 초안 품질과 일관성이 더 중요할 수도 있다.¹²¹³

이 경우 좋은 설계는 직원 시간을 충분히 아껴 주면서도 운영비를 폭발시키지 않는 구조다.

고위험 승인 에이전트

결제, 환불, 계약 변경, 권한 부여처럼 잘못되면 바로 사고가 나는 업무는 속도보다 정확도와 통제가 우선이다. 여기서는 더 강한 모델, 더 깊은 검증, 정책 검사, 사람 승인, 멱등성 키, 보수적인 재시도 정책이 필요하다. 병렬성보다 추적 가능성과 실패 복구가 더 중요해질 수 있다.⁶⁹¹⁴

이 경우 최고의 설계는 빠른 자동화가 아니라 안전한 반자동화일 가능성이 높다.

설계를 위한 실전 체크리스트

제품 관점에서 균형을 잡으려면 다음 질문을 차례로 던져 보면 좋다.

이 요청은 몇 초 안에 끝나야 사용자가 만족하는가.

한 건의 성공을 위해 얼마까지 비용을 써도 되는가.

틀렸을 때의 피해는 얼마나 큰가.

쉬운 요청과 어려운 요청을 구분할 수 있는가.

모든 요청에 가장 비싼 모델을 쓸 이유가 정말 있는가.

병렬화하려는 단계가 정말 독립적인가.

반복 호출 중 재사용 가능한 공통 문맥이나 중간 결과가 있는가.

재시도하려는 오류가 정말 바뀔 수 있는 오류인가.

실패 시 더 작은 모델, 캐시 응답, 사람 승인 같은 fallback이 준비되어 있는가.

이 질문들에 답하지 못한 채 토큰 최적화부터 시작하면, 시스템은 빨라질 수는 있어도 제품은 좋아지지 않을 가능성이 크다.

좋은 균형은 고정값이 아니라 운영 습관이다

마지막으로 꼭 기억할 점이 있다. 비용, 속도, 정확도의 균형은 한 번 정하면 끝나는 상수가 아니다. 모델 가격이 바뀌고, 사용량이 늘고, 사용자 기대치가 바뀌고, 새로운 실패 패턴이 계속 나타난다. 오늘의 최적점은 다음 분기의 최적점과 다를 수 있다.

그래서 좋은 팀은 한 가지 설계를 신앙처럼 붙들지 않는다. 라우팅 기준을 조정하고, thinking budget을 바꾸고, 캐시 적중률을 높이고, 재시도 정책을 손보고, 어떤 단계는 과감히 삭제한다. 최적화란 더 많은 것을 넣는 일이 아니라, 필요 없는 것을 빼고 필요한 곳에만 비싼 자원을 쓰는 일이다.

에이전트 시스템에서 진짜 실력은 최고급 모델을 쓸 수 있느냐가 아니라, 언제 최고급 모델을 쓰지 않아도 되는지를 아는 것에서 드러난다.