10월 18일 일요일 Tech Daily

01오늘의 깊이 읽기

비용표가 아니라 실행 경로를 설계하라

토큰 단가 하나로는 추론 경제성을 설명할 수 없다. 업무별 사용량과 결과, 컨텍스트 형태, 지연 요구, 병렬 처리, 검증 병목을 한 계측면에서 봐야 한다.

ai-llm3분

먼저 토큰의 출처와 결과를 연결한다

추론 최적화의 첫 단계는 가격 협상이 아니라 관측 가능성이다. 전사 공용 API 키 하나로는 총액만 보일 뿐 어느 부서의 어떤 업무가 비용을 만들었는지 알 수 없다. 키를 부서·팀·주요 작업별로 분리하면 장시간 컨텍스트를 반복해 읽는 코딩 에이전트와 짧은 판정을 대량 처리하는 자동화를 다른 워크로드로 볼 수 있다. 발표자가 관측한 에이전트 요청에서는 입력 소스 토큰 비중이 약 99%였고, 통신사의 문자 필터처럼 분당 최대 1,000만 건을 처리하는 작업은 개별 응답보다 처리량이 핵심이었다. 같은 토큰 수라도 비용 구조와 필요한 서비스 수준이 다르다는 뜻이다. 여기서 대시보드의 종착점은 사용량 순위가 아니다. 각 키의 지출을 테스트 통과, 처리 완료, 사람이 승인한 산출물처럼 실제 결과와 연결해야 많이 쓴 팀과 잘한 팀을 구분할 수 있다.

평가가 모델 라우팅의 제어면이 된다

모든 요청에 최고급 대화형 모델을 고정하면 작업의 난도를 반영하지 못한다. 먼저 대표 테스트 케이스와 평가 세트를 만들고, 기준 모델의 결과를 통과하는 가장 저렴한 후보를 찾는 편이 낫다. 발표에서는 고객 지원 추론비를 월 25만 달러에서 7,600달러로 낮춘 통신사 사례를 들었지만, 핵심 근거는 모델 이름이 아니라 업무별 평가와 단계적 교체였다. 최종 응답이 문장이어도 실제 과제가 미리 정한 답을 고르는 분류라면 전용 분류기로 옮길 수 있고, 좁고 반복량이 큰 도메인은 작은 맞춤 모델이나 증류를 검토할 수 있다. 에이전트 작업에서는 강한 모델을 계획과 검증에 두고, 파일 수정과 테스트를 반복하는 실행 단계에는 빠르고 싼 모델을 배치하는 식으로 경로를 나눈다. 다만 모델 수를 수십 개로 늘리면 캐시 적중률이 떨어질 수 있으므로 작업 단위 라우팅과 두세 개 모델의 명확한 역할이 더 관리하기 쉽다.

속도·병렬성·용량 뒤에 검증 비용을 붙인다

토큰 생성 속도는 선형 가격 옵션이 아니다. 발표자의 경험칙에서는 속도를 두 배로 올릴 때 비용이 세 배가 될 수 있다. H100 한 장에서 단일 요청이 약 112토큰/초를 내는 사례도 16개 요청을 병렬화하면 요청별 속도는 낮아지지만 총 처리량은 약 10배가 되고 토큰당 비용은 9~10분의 1 수준까지 내려갈 수 있었다. 그러므로 사람이 기다리는 호출에는 속도 프리미엄을 주고, CI/CD나 야간 에이전트에는 낮은 속도와 높은 병렬성을 배정한다. 지속적인 기본 부하는 전용 용량으로 채우고 큰 피크는 공개 클라우드로 넘기는 혼합 구성도 실제 트래픽 모양을 측정한 뒤 결정해야 한다. 마지막 비용 항목은 검토다. 토큰 지출을 10~100배 늘려도 성과 개선이 6~7%에 그친 조직 사례처럼, 테스트와 작은 병합 단위가 없으면 생성 속도가 리뷰 병목으로 바뀐다. 산출물을 공유한 사람이 정확성에 책임지고, 토큰 비용을 유효한 결과 수로 나눠야 추론 경제성이 완성된다.

02한 흐름으로 보기

천 개의 에이전트를 믿기 전에, 경계를 분리하라

대규모 실행의 핵심은 에이전트 수가 아니라 각 작업에 필요한 맥락만 주고, 생성과 검증을 떼며, 행동 가능한 권한과 실행 상태를 격리하고, 모든 전이를 감사할 수 있게 만드는 것이다.

ai-llm4분

컨텍스트와 권한을 잃지 않으면서 대규모 에이전트 실행을 어떻게 분해하고 검증할 것인가?

단일 에이전트가 긴 작업의 모든 항목과 제약을 한 컨텍스트에 붙잡게 하면 세 가지 문제가 겹친다. 일부 항목을 확인한 뒤 나머지도 괜찮다고 멈추는 태만, 자신이 만든 결과를 스스로 높게 평가하는 편향, 반복 압축 속에서 초기 금지 조건을 잊는 목표 이탈이다. 해법은 단순 팬아웃이 아니다. 리드가 일을 검증 가능한 단위로 나누고, 하위 작업마다 독립 맥락과 제약을 주며, 생성자와 검토자를 분리해야 한다. 동시에 하네스는 모든 기억·도구를 한꺼번에 싣지 않고 현재 작업에 필요한 것만 회수해야 한다. 행동 환경은 업무별 최소 권한으로 격리하고, 세션 예산·중단·재개·이벤트 로그를 외부 제어면으로 둔다. 규모 확장은 컨텍스트 조립, 위임 토폴로지, 실행 샌드박스, 감사 경계를 함께 설계할 때만 운영 능력이 된다.

01
컨텍스트는 용량이 아니라 선별 문제다
메모리 인식형 하네스는 단기 기억과 장기 기억, 파일과 데이터베이스, 요약과 원문 컴팩션을 구분한다. 256,000토큰이 찬 컨텍스트나 더 큰 광고상 한도에서도 정보가 늘수록 정확도가 낮아질 수 있으므로, 스킬 100개를 전부 넣는 대신 설명을 벡터 저장소에 두고 관련 도구와 스킬만 회수한다. 실습은 각각 상위 세 개를 찾고 필요하면 리랭커로 하나를 고르는 구조였다. 루프에도 최대 8회, 회당 60초 같은 상한을 둬 비용과 위험을 제한했다. 이 수치는 보편 규칙이 아니라 문제별 예산이며, 핵심은 기억·검색·도구·루프를 모델 바깥의 조절 가능한 제어면으로 보는 데 있다.
02
위임은 독립 검토와 완료 조건을 가져야 한다
Flows 사례에서 리드 에이전트는 목표를 단계로 나누고 탐색·분류·검토·작성 에이전트를 동적으로 구성한다. 서비스 50개를 점검한다면 각 범위를 독립 작업으로 만들어 누락 여부를 셀 수 있고, 작성과 검토를 다른 컨텍스트에 두면 자기 선호 편향을 줄일 수 있다. 내구성 있는 이벤트 스트림은 도구 호출과 메시지, 하위 에이전트 상태를 보존하며 예산 도달 시 멈추고 증액 뒤 재개하거나 사용자 인터럽트로 방향을 바꿀 수 있게 한다. 다만 최대 1,000개 에이전트를 쓴 운영체제 실험은 약 85시간과 1,000개 커밋 뒤에도 끝나지 않았다. 에이전트 수와 품질의 수익 체감은 정량화되지 않았고, 발표 당시 중첩도 한 단계라는 한계가 있었다.
03
샌드박스는 작업 수명과 상태에 맞춘다
로컬 Docker는 빠른 반복과 선택적 마운트에 유리하지만 노트북 처리량과 상시 이벤트 수신에 한계가 있다. GitHub Actions는 PR·예약 작업마다 깨끗한 일회성 러너를 주지만 GitHub 이벤트와 플랫폼 규격에 묶인다. 장기 실행 VM은 상태와 외부 웹훅을 유지하는 대신 오염된 상태와 여러 에이전트의 권한 혼합을 관리해야 한다. 세션별 Kubernetes Pod는 매번 깨끗한 저장소 사본을 만들고 수천 개로 확장할 수 있지만 CPU·메모리 비용과 결과 영속화를 설계해야 한다. 어느 방식도 완전한 보안 경계는 아니다. 컨테이너 탈출 가능성을 전제로 필요한 저장소·키·도구만 제공하고 세션 종료 뒤 결과를 PR이나 외부 저장소에 남겨야 한다.
04
추론하는 두뇌와 행동하는 손을 떼어 놓는다
대규모 실행에서는 프롬프트 인젝션, 평문 키 노출, 데이터 반출, 요청 범위 초과, 과도한 도구 권한, 가시성 부재를 함께 다뤄야 한다. 제안된 원칙은 선언·격리·감지다. 역할과 도구를 선언하고, 네트워크 목적지와 실행 환경을 제한하며, 내구성 있는 이벤트로 이상 행동을 감지한다. 샌드박스 안에는 실제로 쓸 수 없는 대체 자격 증명만 두고 허용된 호스트로 나가는 egress 시점에 진짜 키를 치환하면 모델이 실제 비밀을 직접 읽는 경로를 줄일 수 있다. 별도 감사 에이전트가 하루나 일주일치 로그를 재검토할 수도 있다. 그러나 경로별 권한이나 조건부 스킵 같은 일부 제어는 플랫폼 기능만으로 끝나지 않으며 애플리케이션 정책으로 보완해야 한다.

실무 순서는 선명하다. 먼저 한 작업의 입력·완료 조건·금지 행동을 정의하고 필요한 기억과 도구만 조립한다. 다음으로 생성과 검증을 독립 단계로 나누고 각 실행에 예산과 중단점을 둔다. 마지막으로 작업 수명에 맞는 샌드박스를 선택해 자격 증명과 네트워크를 최소화하고, 모든 도구 호출과 결과를 되짚을 수 있게 기록한다. 이 경계를 통과하지 못하는 작업은 에이전트를 더 붙일 대상이 아니라 단일 실행으로 축소할 대상이다.