10월 8일 목요일

프로덕션에서 에이전트에게 조사와 행동을 맡기려면 어떤 구조가 모델 호출 바깥에 있어야 하는가?

코드 생성은 텍스트 구조와 테스트 경계가 비교적 분명하지만, 운영 장애는 코드·인프라·로그·메트릭·배포 이력·조직 지식을 함께 다뤄야 한다. 이때 큰 컨텍스트와 강한 모델만 붙이면 탐색이 넓어지는 대신 존재하지 않는 가설에 고정되거나, 상관관계를 원인으로 오해하거나, 위험한 수정까지 실행할 수 있다. 제시된 프로덕션 하네스는 이를 모델 오케스트레이션, 컨텍스트 엔지니어링, 인과 추론, 거버넌스 액션, 학습 시스템, 평가 인프라의 여섯 축으로 분해한다. 핵심은 어느 모델이 답했는지가 아니라 어떤 자료를 어느 단계에서 찾았고, 어떤 경쟁 가설을 버렸으며, 어떤 권한으로 무엇을 했고, 그 결과를 어떻게 다시 평가했는지 재구성할 수 있게 만드는 것이다. 기업 문서 검색 사례도 같은 결론을 보탠다. 검색은 정답을 만드는 장치가 아니라 후보 위치를 알려 주는 나침반이고, 파일 목록·메타데이터·부분 읽기·스크린샷 확인이 근거를 확정한다. 반면 공격 AI 사례는 이 구조의 실패 비용을 극단적으로 보여 준다. 에이전트가 빠를수록 허용 경계와 감사 로그는 사후 기능이 아니라 실행 경로 자체여야 한다.

1. 01

   탐색 경계: 검색과 검증을 분리한다

   약 100~1,000개 파일처럼 작고 반구조화된 저장소라면 grep과 파일 계층 탐색이 빠르고 최신 상태를 그대로 읽는다. 수천~수백만 개의 비정형 문서에서는 키워드·의미·메타데이터 검색으로 후보를 줄이고, 실제 파일의 해당 오프셋과 주변 문맥을 다시 읽어야 한다. 표·차트·스캔은 파싱 텍스트만 믿지 않고 페이지 스크린샷과 레이아웃 충실도를 함께 확인한다. 따라서 컨텍스트 엔지니어링의 지표는 많이 넣은 토큰 수가 아니라 답의 각 주장까지 되짚을 수 있는 근거 경로다.

2. 02

   행동 경계: 최소 권한을 핫 패스에 둔다

   운영 에이전트가 파일·데이터베이스·배포 설정을 바꿀 수 있다면 읽기와 쓰기를 분리하고, 삭제·배포·설정 변경에는 별도 조건과 승인을 둬야 한다. 공격 AI 사례는 하이퍼바이저와 프록시로 실행 환경을 격리하고, 외부 요청과 응답을 분류기로 검사하며, 특정 행동은 결정론적 규칙으로 금지한다. 규칙을 너무 많이 두면 탐색 능력이 사라지고 너무 적게 두면 통제가 무너지므로, 해석할 수 없는 회색 영역은 멈춰서 인간에게 넘기는 경로가 필요하다.

3. 03

   인과 경계: 경쟁 가설과 낮은 신뢰도를 보존한다

   장애 시점과 외부 장애가 겹쳤다는 사실만으로 원인을 확정하지 않는다. 조사 에이전트는 코드·인프라·지식베이스·관측성 데이터에서 사건 순서를 만들고, 선택한 원인뿐 아니라 기각한 가설을 함께 남겨야 한다. 증거 사슬이 끊기면 답을 매끄럽게 완성하는 대신 신뢰도를 낮추고 추가 조사 방향을 제시한다. 공격 검증에서도 CVE 목록보다 실제 원격 코드 실행이나 데이터 접근으로 이어지는 경로를 입증해야 우선순위를 정할 수 있다.

4. 04

   평가 경계: 경로와 결과를 함께 채점한다

   평가는 출시 전 벤치마크 한 번으로 끝나지 않는다. 사용자의 긍정·부정 교정, 에이전트가 해법에 도달한 경로, 숙련 엔지니어 기준의 결과 점수, 자기 신뢰도 보정을 지속적으로 수집해야 한다. 보안 쪽의 20개 완전한 공격 경로 평가에서 공개 가중치와 폐쇄형 모델 모두 최대 8개를 완료했다는 결과는 모델 브랜드보다 과제별 속도·비용·감사 가능성을 함께 보라는 경고다. 조직은 100번째 조사에서 첫 조사처럼 시작하지 않도록 이전 맥락도 학습 자산으로 남겨야 한다.

도입 순서는 모델 선택보다 실패 경계를 먼저 정의하는 쪽이 안전하다. 조사 단계마다 허용할 데이터와 도구를 정하고, 모든 주장에 원문 근거를 연결하며, 실행은 최소 권한으로 제한하고, 변경 전후의 상태와 에이전트 행동을 재생 가능한 로그로 남긴다. 그 위에서만 모델 라우팅과 자동 액션의 범위를 넓힌다. 프로덕션 준비 여부를 가르는 질문은 ‘답을 생성했는가’가 아니라 ‘근거를 재현하고, 권한을 설명하고, 실패를 멈추고, 다음 실행에서 개선할 수 있는가’다.

생성 속도가 크게 올랐을 때 어떤 측정이 실제 도입 가치와 비용 함정을 구분하는가?

추측 디코딩은 작은 초안 모델이 3~5개 후보 토큰을 만들고 큰 대상 모델이 한 번에 검증해 순차적인 디코드 병목을 줄인다. 대상 모델이 최종 토큰을 승인하므로 정확도 기준은 유지되지만, 초안 모델 가중치와 두 모델의 KV 캐시를 동시에 올릴 메모리가 필요하다. 효과는 코딩·JSON·SQL처럼 다음 토큰 선택지가 좁고 출력이 충분히 긴 작업에서 커진다. 반대로 긴 문서를 먼저 읽는 RAG, 높은 temperature의 창작, 이미 GPU가 높은 동시성으로 포화된 서비스에서는 추가 모델 비용이 이득을 상쇄한다. 초고속 코딩 모드도 비슷하다. 320~340 TPS는 사람의 피드백 루프를 유지하지만, 생성이 빨라지자 브라우저 확인·빌드·Git 같은 도구 시간이 새 병목이 되고 사용량과 비용도 함께 가속됐다. 따라서 속도 배수 하나가 아니라 프리필·디코드·도구·인간 피드백을 분리한 전체 경로를 측정해야 한다.

1. 01

   먼저 프리필과 디코드를 분리한다

   추측 디코딩은 입력을 읽고 KV 캐시를 만드는 프리필을 빠르게 하지 않는다. 긴 문서 입력 뒤 짧게 답하는 시스템은 프리필이 지배하므로 디코드 가속의 체감 이득이 작다. 반대로 출력 토큰이 길고 구조 제약이 강한 작업은 초안 토큰 수용률이 높아 여러 토큰을 한 사이클에 확정할 가능성이 커진다.

2. 02

   메모리와 동시 처리량을 같은 표에 놓는다

   Blackwell 단일 GPU 데모에서는 대상 모델 가중치 약 16GB와 초안 모델 약 2.5GB를 함께 배치했고 구조화된 작업에서 약 1.6배 생성 속도를 기록했다. 그러나 초안 모델은 대상보다 10~50배 작아야 하고 토크나이저도 호환돼야 한다. 수용률, 초당 토큰, 전체 지연, 두 KV 캐시, 배치 크기와 동시 처리량을 함께 비교해야 1.6배가 실제 서비스 이득인지 판단할 수 있다.

3. 03

   사람이 루프에 남는 가치도 비용과 분리해 본다

   Ultrafast 사례에서 일반 약 30 TPS, Fast 약 60 TPS, Ultrafast 320~340 TPS의 차이는 작은 지시를 즉시 반복하는 작업 방식을 만들었다. 하지만 출력 가격은 표준의 6배였고, 100줄 미만 PR 두 개 검토에 600달러 사용량이 들었다. UI 탐색처럼 즉시 보고 방향을 바꾸는 작업에는 맥락 보존 가치가 있었지만, 같은 산출물의 가격만 비교하면 일반 작업에 적용하기 어려웠다.

4. 04

   도입 실험은 업무 단위로 제한한다

   기본 vLLM 구성으로 실제 프롬프트·temperature·출력 길이를 재현하고, 구조화된 생성부터 수용률과 전체 요청 시간을 측정한다. 초고속 모드는 브라우저 조작이나 반복 빌드처럼 토큰보다 느려진 도구 호출을 줄인 별도 하네스로 시험한다. 두 경우 모두 호출당 가격이 아니라 완료된 작업당 비용, 수정 반복 수, 실패율과 최종 품질을 기록해야 한다.

가속 기능의 기본값 승격 조건은 명확하다. 목표 워크로드에서 전체 지연이 줄고, 동시 처리량이 유지되며, 추가 메모리와 사용량을 포함한 작업당 비용이 허용 범위 안에 있어야 한다. 구조화된 생성과 긴급한 인더루프 작업처럼 적합성이 확인된 경로에만 먼저 켜고, 긴 RAG와 창작형 작업, 포화 GPU에는 그대로 확대하지 않는다. 데모 속도는 가설이고 운영 지표가 판정이다.