에이전트엔 계기판부터

자료 기준: 2026년 8월 14일 오전, 한국 시간

AI 모델 소식은 자꾸 최고 속도를 앞세운다. 하지만 내가 운영할 서비스에서 중요한 질문은 조금 다르다. 첫 글자가 얼마나 빨리 나왔는지, 끝까지 작업을 마쳤는지, 실패했을 때 돌아올 수 있는지, 그리고 청구서가 의자에서 나를 기다리고 있는지를 함께 봐야 한다.

시속 300km로 달려도 목적지를 지나치면 택시비만 빨리 늘어난다. 그래서 이번에는 에이전트에 붙일 계기판을 정리했다.

1. ‘빠르다’를 네 개로 쪼갠다

OpenAI의 Fast mode 문서는 GPT-5.6 Sol 요청에 더 빠르고 일정한 지연시간을 제공하지만, 트래픽 급증 시 Standard 처리로 내려갈 수 있다고 설명한다. 평균 속도 하나만 기록하면 이런 변화를 놓치기 쉽다.

나는 최소 네 가지를 잰다.

1. TTFT: 요청 후 첫 글자가 나오기까지 걸린 시간
2. 출력 속도: 초당 생성한 출력 토큰
3. p95 지연시간: 느린 5% 요청이 얼마나 오래 걸렸는지
4. 전체 작업시간: 도구 호출과 재시도까지 끝낸 시간

여기에 응답의 service_tier와 오류율을 붙인다. 빠른 경로를 요청했지만 Standard로 처리됐다면 성능 보고서에 그대로 남겨야 한다. 스톱워치 버튼만 누르고 결승선을 안 보는 실험은 운동회에서도 혼난다.

출처: OpenAI API Fast mode

2. 모델과 에이전트 런타임을 분리한다

Vercel의 HarnessAgent는 Claude Code, Codex, Pi 같은 실행기를 공통 인터페이스로 다룬다. AI SDK 7은 이 구조를 더 많은 하네스로 넓혔다. 내가 가져갈 설계는 단순하다.

업무 기능 → AgentRuntime → 실제 에이전트 → 모델·도구

업무 기능은 “저장소를 점검하고 수정안을 만들어라”까지만 요청한다. 세션 생성, 스트리밍, 취소, 권한 승인과 샌드박스 정리는 AgentRuntime이 맡는다. 실제 실행기는 설정으로 선택한다.

그렇다고 모든 런타임이 똑같다고 가정하면 안 된다. 교체 전에는 아래를 비교한다.

• 도구 호출과 구조화 출력 지원 여부
• 세션 재개와 취소 방식
• 파일·네트워크·셸 권한 범위
• 로그와 비용 추적 범위
• 실패 후 정리와 재시도 방식

공통 리모컨을 만들었다고 모든 가전제품에 ‘밥 짓기’ 버튼이 생기지는 않는다. 추상화는 차이를 숨기는 기술이 아니라 차이를 한곳에서 관리하는 기술이다.

출처: Vercel HarnessAgent, Vercel AI SDK 7

3. 완료율은 ‘PR을 만들었다’에서 끝나지 않는다

에이전트 성능을 단순 응답 성공률로 재면 친절하게 틀린 답도 성공이 된다. 나는 작업별 완료 조건을 미리 적는다.

• 요구한 파일만 수정했는가
• 테스트와 정적 검사를 통과했는가
• 관련 없는 변경을 만들지 않았는가
• 사람이 이해할 수 있는 근거를 남겼는가
• 실패했을 때 원래 상태를 보존했는가

한 모델이 20초 만에 수정하고 두 번 되돌리는 것보다, 다른 모델이 40초에 한 번 제대로 끝내는 편이 싸다. 그래서 비용도 토큰 단가보다 완료된 작업 한 건당 비용으로 본다.

내 대시보드의 핵심은 다음 네 칸이다.

완료율 | 전체 작업시간 | 완료 건당 비용 | 복구 성공률

벤치마크 점수는 면접 점수에 가깝다. 실제 출근 후 복사기 앞에서 멈추지 않는지도 봐야 한다.

4. AI가 가져온 패키지는 문 앞에서 검사한다

GitHub의 라이선스 준수 공개 프리뷰는 기업이 중앙 정책을 만들고, 문제가 있는 의존성을 PR 병합 전에 막도록 한다. AI가 코드를 빨리 만들수록 외부 패키지를 들여오는 속도도 빨라지므로 이 문지기가 더 중요해진다.

내가 CI에 넣을 순서는 이렇다.

1. lockfile 기준 SBOM 생성
2. 새 의존성과 버전 변경 탐지
3. 라이선스 허용·차단 정책 검사
4. 취약점과 악성 패키지 검사
5. 예외 승인자와 만료일 기록

“AI가 추천했습니다”는 라이선스가 아니다. 자동완성은 계약서 서명란에 대신 도장을 찍어 주지 않는다.

출처: GitHub 오픈소스 라이선스 준수 공개 프리뷰

5. 에이전트 지갑에는 용돈 봉투부터 준다

Circle Agent Stack과 Nanopayments 테스트넷은 에이전트가 x402를 통해 API나 서비스에 건별 결제하는 구조를 시험하게 한다. 기술적으로 가능하다는 것과 운영에서 안전하다는 것은 별개다.

나는 결제 도구 앞에 정책 계층을 둔다.

에이전트 → 구매 요청 → 정책 검사 → 한도 있는 지갑 → 결제 → 영수증

정책에는 최소한 아래 항목이 필요하다.

• 호출당·시간당·일일 지출 한도
• 허용 판매자와 자산 목록
• 같은 요청의 중복 결제를 막는 idempotency key
• 구매 목적과 결과물 연결
• 취소·분쟁·실패 처리 규칙
• 사람 승인이 필요한 금액 기준

에이전트에게 무제한 지갑을 주는 것은 냉장고를 부탁하면서 집 열쇠와 법인카드를 같이 맡기는 일이다. 똑똑함과 절약 정신은 같은 옵션이 아니다.

출처: Circle Agent Stack, Circle Nanopayments 테스트넷

내가 적용할 운영 기준

새 모델이나 에이전트를 붙일 때 나는 다음 순서로 확인하겠다.

1. 실제 업무 20–50건으로 완료 조건을 고정한다.
2. Standard와 빠른 경로를 같은 입력으로 비교한다.
3. p50·p95 시간과 완료 건당 비용을 함께 기록한다.
4. 런타임별 권한·세션·복구 차이를 표로 남긴다.
5. 패키지와 결제는 별도 정책 게이트를 통과시킨다.
6. 실패를 일부러 만들고 원상복구가 되는지 확인한다.

오늘의 결론은 에이전트에게 터보 버튼보다 계기판을 먼저 달자다. 빠른 데모는 박수를 받지만, 속도·비용·권한·복구가 같이 보이는 시스템이 월요일 아침을 지켜 준다.