에이전트에 데이터를 물려보면 답은 항상 나온다. 숫자가 하나 찍히고, 해석까지 붙어서 돌아온다. 문제는 그 숫자가 맞는지 확인할 방법이 없다는 것이다. 코드는 테스트가 통과하는지 보면 되고 번역은 원문과 대조하면 되지만, "이 기능이 잔존율을 얼마나 올렸나" 같은 질문에는 채점할 정답지가 없다.
지난 이틀 사이에 나온 세 건이 이 문제를 정면으로 다뤘다. 공통점은 에이전트를 더 똑똑하게 만드는 쪽이 아니라, 에이전트가 무엇을 남기게 할지를 정하는 쪽으로 갔다는 것이다.
절차를 씌운 에이전트와 곧장 물어본 모델은 네 배 다른 답을 냈다
넷플릭스는 관측 인과추론(observational causal inference)용 에이전트 워크플로 oci-agent를 오픈소스로 공개했다. 6월 공개 이후 사내에서 월 100건이 넘는 분석을 돌리고 있고, 8월 18일 InfoQ가 그 구조를 정리했다.
작동 방식은 단순하다. 사람이 분석 계획과 템플릿 노트북을 만들면, actor 에이전트가 명세를 만들어 노트북을 실행하고, critic 에이전트가 결과를 세 등급(not_satisfactory / satisfactory_with_caveats / fully_satisfactory)으로 평가한 뒤 명세 수정안을 제안한다. 공변량 균형 점검, 성향점수 트리밍, 민감도 분석처럼 빠뜨리기 쉬운 단계가 템플릿으로 강제된다.
결과가 눈에 띈다. 한 콘텐츠 잔존율 사례에서 이 워크플로가 낸 추정 효과는, 모델에 곧장 물어 얻은 값의 25%였다. 네 배 차이다. 그리고 어느 쪽이 참인지 판정할 근거는 어디에도 없다. 넷플릭스 스스로 ACIC 데이터셋에서 "경쟁력 있다" 정도로만 표현했고, "정답이 없는 과제에서 에이전트 성능을 어떻게 평가하는가"를 미해결 문제로 남겼다.
그래서 감사 대상이 결론에서 산출물로 내려왔다
넷플릭스가 택한 답은 자동 평가가 아니라 절차 감사(process audit)와 사람의 감독이다. 에이전트는 계획·명세·플롯·노트북을 아티팩트로 남기고, 사람은 그걸 열어보고 다시 실행한다. 검사 대상이 "얼마"라는 숫자에서 "어떻게 얻었나"라는 기록으로 내려앉았다.
같은 날 그라파나가 gcx CLI와 Grafana MCP 서버를 GA로 올린 것도 방향이 같다. 코딩 에이전트가 개발 중에 메트릭·로그·트레이스·SLO를 직접 조회하게 해서, 코드 리뷰 하나에 기대지 않고 운영 데이터를 근거로 붙이자는 것이다. 다만 InfoQ는 같은 기사에서 두 가지를 함께 적었다. 리뷰 에이전트와 습관적인 LGTM 승인은 잘못된 확신을 만든다는 것, 그리고 백엔드 텔레메트리는 프런트엔드 회귀를 잡지 못한다는 것이다. 근거를 붙인다고 사각지대가 사라지지는 않는다.
사람에게 남은 자리는 질문과 가정이다
그랩은 규모로 같은 결론에 도달했다. 슬랙 질의를 받는 Spartan(50개 이상의 스킬과 120개 분석 프레임워크), 데이터 맥락의 수명주기를 관리하는 ContextIQ(인증 테이블·지표 5,000여 개, 맥락 문서 4,000개, 골든 레코드 2,000개), 파이프라인 장애를 분석하는 Scarlet을 붙였다.
- 기계적 분석 업무 비중: 2월 44% → 6월 30%
- SQL 요청 자기해결: 50% → 81%
- 데이터 추출 자기해결: 63% → 90%
- 요청의 85%가 1분 안에 첫 응답
그런데 그랩이 사람에게 남긴 항목이 더 중요하다. 지표 정의, 인과 해석, 비즈니스 가정, 최종 결정이다. 자율성 수준과 에스컬레이션 규칙도 사람이 정한다. 기사에 실린 질문은 이렇다. "에이전트가 데이터 준비와 분석을 다 하면 애널리스트는 무엇을 하는가." 세 사례를 겹쳐 보면 답은 하나로 모인다. 남는 일은 질문을 세우고 가정을 고르고, 나온 산출물을 열어보는 일이다. 그건 자동화의 잔여물이 아니라 원래 가장 어려운 부분이었다.
조녁컴퍼니가 AX 전환 교육에서 반복해 확인하는 지점도 같다. 도구를 켜는 법보다, 에이전트가 낸 숫자를 어떤 기록으로 되짚을지 정하는 훈련이 조직의 성과를 가른다. 사업영역 →