이틀 동안 350건. 결과는 -1.11%.

KAIST 연구팀이 오픈클로 에이전트를 써서 주식 자동매매를 돌렸다. 에이전트는 멈추지 않고 작동했다. 오류도 없었다. 그런데 수익이 나지 않았다.

이 결과를 보고 “에이전트 기술이 아직 부족하다”고 읽는다면 틀린 해석이다. 에이전트는 제대로 돌아갔다. 문제는 다른 곳에 있다.

데모 성공 ≠ 운영 성공

emollick이 한 줄로 정리했다.

“using AI well is a management problem, not a technology problem.”

에이전트를 잘 쓰는 건 기술 문제가 아니라 관리 문제다. 이 문장이 자동매매 -1.11%에서 그대로 살아있다.

자동매매 에이전트는 기술적으로 완벽하게 작동했다. 350건을 빠짐없이 처리했다. 그런데 전략이 맞지 않았고, 에이전트는 검증하지 않은 판단을 350번 반복했다.

데모에서는 에이전트가 10번 거래해서 7번 맞으면 성공이다. 운영에서는 그 7번이 언제 맞고 언제 틀리는지, 손실 한 번이 이익 세 번을 날릴 수는 없는지, 전략이 지금 시장 조건에서 유효한지를 전부 설계해야 한다.

이 설계가 없으면 에이전트는 열심히 틀린 일을 반복한다. 빠르게.

단위경제가 보이지 않으면 쓸수록 손해다

같은 KAIST 연구에서 나온 다른 숫자가 있다. 에이전트 하나가 쓰는 전력은 챗봇 단순 질의보다 최대 136배 많다.

에이전트가 “자율적으로” 툴을 호출하고, 검색하고, 데이터를 수집하는 과정이 전부 비용이다. API 호출 수, 컨텍스트 길이, 모델 호출 횟수 — 이것들이 하나씩 청구된다.

데모에서 에이전트를 5번 돌리면 비용이 보이지 않는다. 하루 1,000번 돌리면 보인다. 350건 자동매매가 -1.11%를 기록하면서 컴퓨팅 비용까지 나갔다면, 실제 손실은 -1.11%보다 크다.

“에이전트가 작동하는가”를 묻는 것과 “이 작업에 에이전트를 쓰는 것이 단위경제상 맞는가”를 묻는 것은 완전히 다른 질문이다. 데모는 첫 번째 질문에만 답한다.

PM이 설계해야 하는 세 가지

최근 개발자 커뮤니티에서 이 지점이 반복적으로 나오고 있다. “코딩 실행자가 아니라 맥락을 이해하고, 검증하고, 제품화하는 설계자로 바뀐다”는 말이다.

에이전트 시대 PM은 에이전트가 돌아가는지를 보는 사람이 아니다. 에이전트가 올바른 일을 올바른 비용으로 하는지를 보는 사람이다.

1. 성공 기준 먼저 정의하기

자동매매 에이전트였다면 “350건 처리”가 아니라 “이 조건에서만 거래한다”는 제약이 설계에 들어가야 했다. 에이전트에게 자율성을 주는 것과 아무 기준 없이 돌리는 것은 다르다. 성공 기준이 없으면 에이전트는 목표 없이 바쁘다.

2. 단위 비용 실측하기

에이전트 하나가 실제로 얼마를 쓰는지 숫자로 봐야 한다. 툴 호출 횟수, 토큰 사용량, API 비용. 이 숫자가 보이지 않으면 에이전트를 최적화할 방법이 없다. “에이전트가 작동한다”는 것과 “이 작업에서 쓰는 게 맞다”는 것은 별개다.

3. 검증 게이트 설계하기

에이전트가 실행 전 내린 판단을 사람이 한 번 볼 수 있는 구간을 넣는 것. 전부일 필요는 없다. 고위험 결정, 반복 실패 패턴, 비용이 임계치를 넘는 순간 — 이 시점에 게이트가 있으면 -1.11%는 -0.2%에서 멈출 수 있었다.

에이전트의 자율성은 검증 게이트가 있을 때 더 안전하게 발휘된다.

질문이 바뀌었다

“에이전트가 돌아가는가”는 2024년의 질문이다.

2026년의 질문은 “에이전트가 올바른 일을 올바른 비용으로, 검증 가능한 방식으로 하는가”다.

KAIST 자동매매 -1.11%는 실패 사례가 아니다. 에이전트 기술의 한계를 보여주는 것도 아니다. 데모와 운영 사이의 설계 공백이 어디에 있는지를 정확하게 보여주는 사례다.

그 공백을 채우는 것이 PM의 일이다. 프롬프트를 잘 쓰는 것보다 먼저.

당신의 팀이 운영 중인 에이전트에, 성공 기준과 검증 게이트가 설계되어 있나요?