에이전트가 돌아간다고 끝나는 게 아니다
KAIST 오픈클로 자동매매 실험 -1.11% — 에이전트는 완벽하게 실행됐지만 돈을 잃었다. 데모 성공과 운영 성공의 기준이 다른 이유, PM이 먼저 설계해야 할 단위경제·검증·멈춤 조건.
KAIST 연구팀이 최근 오픈클로(OpenClaw) 에이전트를 활용해 이틀간 350건의 주식 자동매매를 실행했다. 결과는 -1.11%였다.
에이전트는 완벽하게 돌아갔다. 오류 없이 350번 결정을 내렸고, 주문을 실행했고, 리포트를 생성했다. 단지 돈을 잃었을 뿐이다.
이것이 2026년 에이전트 도입의 핵심 함정이다.
데모의 성공과 운영의 성공은 기준이 다르다
데모는 “돌아가는가”로 판단한다. 오류가 없으면 성공이다. 관객은 박수를 친다.
운영은 다르다. “돈이 남는가”로 판단한다. 잘 돌아가는 에이전트가 오히려 비용을 불태우는 사례가 늘고 있다.
KAIST 연구가 정량화한 숫자가 있다. 에이전트 작업은 챗봇보다 최대 136.5배 더 많은 전력을 소비한다. 하루 데이터센터 기준으로 환산하면 199GWh에 달한다. 툴 호출 한 번마다 연산 비용이 쌓인다. 에이전트가 열심히 일할수록 청구서가 커진다.
자동매매 -1.11%는 수익률 문제가 아니다. 350번의 툴 호출 × 전력 소비 × API 비용을 더하면 실제 손실은 -1.11%보다 훨씬 크다. 에이전트는 완벽하게 운영됐지만, 단위경제는 처음부터 설계되지 않았다.
”AI를 잘 쓰는 건 프롬프트 기술이 아니라 관리 문제다”
와튼 스쿨 Ethan Mollick 교수는 최근 이렇게 썼다.
“using AI well = management problem”
같은 주, 국내 개발자 커뮤니티 벨로그에는 이런 글이 올라왔다. AI 시대 개발자의 역할이 ‘코딩 실행자’에서 ‘맥락·검증·제품화 설계자’로 바뀐다는 것이다.
두 신호가 다른 맥락에서 같은 방향을 가리키고 있다.
에이전트가 실행을 맡으면, 남는 판단은 설계다. 어떤 작업에 에이전트를 붙일 것인가. 한 번 실행에 툴 호출을 몇 번까지 허용할 것인가. 손실이 발생하면 언제 멈출 것인가. 이것들은 모두 프롬프트 문제가 아니라 관리 설계 문제다.
메르카리 엔지니어링 팀이 Claude Code를 도입한 뒤 세운 원칙이 이 흐름을 잘 보여준다. “하네스(권한·훅·샌드박스)는 외부에서 빌리고, 판단 기준은 팀이 직접 쌓는다.” 도구는 빌리고, 기준은 설계한다는 것이다.
PM이 설계해야 할 세 가지
에이전트를 운영에 넣기 전에 먼저 정의해야 할 것이 있다.
첫째, 단위경제 기준. 이 작업을 에이전트로 처리할 때 툴 호출 N번 이내로 끝나야 수익이 남는가? 136배 전력 비용을 감당할 만큼 반복 횟수가 충분한가? 자동매매처럼 단일 실행의 변동성이 크다면, 에이전트 비용 구조 자체가 작동하지 않는다.
둘째, 검증 루프. 에이전트가 “완료”라고 말하는 것과 실제로 완료된 것이 다를 수 있다. KAIST 실험에서 에이전트는 -1.11%를 기록한 뒤 “350건 처리 완료”라는 리포트를 생성했다. 검증 레이어가 없으면, 에이전트의 완료 판정이 곧 팀의 완료 판정이 된다. 결과가 아니라 정확성을 별도로 측정하는 구조가 있어야 한다.
셋째, 멈춤 조건. 데모에는 멈춤 조건이 없다. 끝나면 성공이다. 운영에는 반드시 있어야 한다. 손실이 X%를 넘으면 실행을 중단한다. 툴 호출이 N번을 초과하면 인간 승인을 요청한다. 이 조건을 설계하지 않으면, 에이전트는 열심히 일하면서 비용만 만들어낸다.
이 세 가지를 사전에 정의하지 않은 채 에이전트를 배포하는 것은, 목적지 없이 출발하는 것과 같다. 열심히 달려서 어딘가에 도착하지만, 그곳이 어딘지 알 수 없다.
”돌아간다”는 데모 기준이고, “돈이 남는다”는 운영 기준이다
에이전트 도입을 추진하는 팀 대부분이 지금 데모 기준으로 판단하고 있다. 오류 없이 작동하면 성공이라고 부른다.
운영 기준은 다르다. 같은 비용으로 결과가 반복 생산되는가. 단위경제가 작동하는가. 검증 루프가 있는가. 멈춤 조건이 있는가.
KAIST 자동매매 실험은 AI 에이전트의 실패 사례가 아니다. 오히려 정직한 테스트였다. 두 가지를 동시에 증명했다. 에이전트는 복잡한 작업을 자율적으로 실행할 수 있다. 그리고 그것이 수익으로 연결되려면 설계가 따로 있어야 한다.
에이전트가 코드를 실행하고, 결정을 내리고, 보고서를 만든다. 그 다음 판단은 사람이 한다. AI를 잘 쓰는 건 프롬프트 기술이 아니라 관리 설계다.
당신이 운영 중인 에이전트에 단위경제 기준이 설계되어 있나요? 멈춤 조건은 정해져 있나요?