사내에서 에이전트 데모를 처음 시연하는 날에는 늘 박수가 나온다. 고객 문의 메일을 읽고 주문 내역을 조회해 답장 초안까지 쓰는 세 단계짜리 흐름이 눈앞에서 막힘없이 돌아가기 때문이다. 그런데 이 에이전트를 실제 운영 환경에 붙이는 순간 사정이 달라진다. 환불 규정을 대조하고 재고 시스템을 확인한 뒤 결제 취소를 요청하는 단계가 줄줄이 붙으면서 전체 흐름이 서른 단계로 불어나고 어느 날 아침 출근해 보면 고객에게 엉뚱한 환불 금액을 안내한 메일이 수북이 쌓여 있다.
이 지점에서 제품 관리자(PM)가 부딪히는 문제는 에이전트의 내부 동작 원리가 아니다. 어떤 업무까지 자동화할지, 권한을 어디까지 내어줄지, 무엇을 검사하고 어떤 실패는 눈감아 줄지 결정하는 일이다. Product Mindset 뉴스레터에 실린 Mental Models in the Agentic Era는 이런 갈림길에서 꺼내 쓸 수 있는 사고 모형 15가지를 다섯 가지 주제로 묶어 짚어 준다.
소프트웨어 제품을 만들며 오랫동안 써 온 사고 모형들은 에이전트 시대에도 그대로 통한다. 다만 일을 처리하는 주체가 매번 같은 답을 내는 코드에서 확률적으로 움직이는 모델로 바뀌었을 뿐인데 그 차이 하나 때문에 익숙한 모형들이 전혀 다른 답을 내놓는다.
Every model you learned still works. It just returns a different answer now.
에이전트 비용은 해결한 작업 건수로 따진다
가장 먼저 따져 볼 것은 돈 계산이다. 경제학의 ‘제번스의 역설’은 자원을 쓰는 효율이 좋아져 값이 싸지면 아껴 쓰는 대신 오히려 전체 소비량이 폭발적으로 늘어난다는 법칙이다. 석탄을 적게 먹는 증기기관이 등장하자 산업 전체가 커지며 석탄 사용량이 급증했듯 추론 단가가 떨어지자 기업들의 토큰 사용량은 걷잡을 수 없이 치솟았다. 따라서 에이전트 예산은 호출 단가가 내려갈 것만 기대할 게 아니라 사용량 자체가 몇 배로 불어날 상황을 전제로 짜야 한다.
그렇다면 에이전트 비용은 어떤 단위로 재야 할까. 토큰 한 개 값이나 호출 횟수 대신 ‘성공적으로 끝낸 작업 한 건당 비용’으로 계산해야 한다. 호출 단가가 싼 작은 모델이 문제를 풀지 못해 열두 번씩 도구를 다시 부르며 헤매다 실패하면 한 번에 끝내는 비싼 최신 모델보다 돈을 더 쓴다. 확인하는 방법도 간단하다. 실제 업무에서 자주 나오는 작업 20개를 두 모델에 똑같이 맡겨 본 뒤 끝까지 제대로 마친 건수만으로 총비용을 나눠 보면 어느 쪽이 저렴한지 바로 드러난다. 고객 지원 에이전트를 만드는 Decagon이 대화 횟수 대신 ‘해결된 문의 건수’로 요금을 받는 것도 같은 이유다.
여기에 시간 축을 더하면 자동화의 손익분기점인 ‘채산선(viability line)’이 보인다. 어떤 업무를 맡기는 비용이 그 업무가 내는 가치보다 낮아지는 순간 자동화가 경제성을 얻는데 이 선이 분기마다 아래로 내려가고 있다. 1월에는 API 비용이 비싸 엄두를 못 내던 고객 리서치 요약이 6월이면 기본 기능이 되는 식이다. AI 평가 기관 METR의 측정에 따르면 모델이 혼자 완수할 수 있는 작업 길이는 약 7개월마다 두 배씩 늘고 있다. 지금 당장 수지가 맞지 않았던 아이디어라도 버리지 말고 분기마다 다시 꺼내 돌려 봐야 하는 이유다.
95%짜리 단계를 열 번 이으면 60%가 된다
비용 계산이 끝났다면 확률로 움직이는 제품을 어떻게 명세할지 정해야 한다. 여기서 마주치는 첫 난관은 이선 몰릭 교수가 ‘들쭉날쭉한 경계(jagged frontier)’라고 부른 현상이다. AI는 어려워 보이는 일은 놀랄 만큼 잘 해내면서 바로 옆의 비슷한 작업에서는 어이없이 무너진다. 게다가 그 경계선은 직접 부딪쳐 보기 전까지 보이지 않는다. 흠잡을 데 없는 코드를 짜는 에이전트가 폴더 안 파일 개수는 틀리게 세는 식이다. BCG 컨설턴트를 대상으로 한 실험에서도 AI가 잘하는 경계 바깥의 과제에 AI를 쓴 집단은 AI 없이 일한 집단보다 19점 낮은 점수를 받았다.
각 작업이 경계 안쪽에 들어와 있더라도 안심할 수 없다. 여러 단계를 이어 붙인 흐름에서는 단계별 성공 확률이 서로 곱해지며 전체 성공률을 깎아 먹기 때문이다. 단계마다 95% 성공하는 에이전트도 열 단계를 거치면 끝까지 완주할 확률($0.95^{10}$)이 약 60%로 떨어지고 서른 단계까지 길어지면 21% 남짓으로 주저앉는다. 서두의 세 단계짜리 데모가 박수를 받고도 서른 단계 실무에서 무너진 까닭이 바로 이 복리 오류에 있다. METR 실험에서도 모델은 사람이 4분이면 끝내는 짧은 과제는 거의 100% 해냈지만 4시간짜리 긴 과제는 10%도 해내지 못했다.
이처럼 결과가 확률로 흔들리는 기능은 “버튼을 누르면 이렇게 동작한다”는 설명만으로는 명세가 되지 않는다. 무엇을 성공으로 볼지 먼저 정하지 않으면 개발이 끝났는지도 판단할 수 없다. “전체 실행의 90%는 받아들일 만한 답을 내고 8%는 억지 답을 지어내는 대신 깔끔하게 실패를 인정하며 금지된 행동은 한 번도 하지 않는다”처럼 목표 비율로 적어야 한다. 이 비율을 채점하는 평가 묶음(eval suite)이 예전의 기획서(PRD)를 대신하며 해멀 후사인의 말대로 최종 통과율을 몇 퍼센트로 잡을지는 엔지니어가 아니라 제품을 책임지는 PM이 정할 문제가 된다.
자율성은 다이얼로 조절하고 되돌릴 수 없는 행동은 따로 묶는다
성공률을 관리하더라도 언젠가 터질 사고를 막으려면 에이전트에게 줄 권한을 세밀하게 나눠야 한다. 자율성은 켜고 끄는 전원 스위치보다 네 칸짜리 조절 다이얼에 가깝다. 힌트만 제안하는 칸, 초안을 작성해 두는 칸, 사람의 승인을 받아 실행하는 칸, 먼저 실행한 뒤 사후에 보고하는 칸이 차례로 놓인다. 영향 범위가 큰 새 기능은 첫 칸에서 조심스럽게 출발하고 충분히 검증된 작업부터 한 칸씩 다이얼을 올려 가는 편이 안전하다.
다이얼을 몇 번째 칸까지 올려도 될지는 제프 베이조스가 말한 ‘양방향 문과 일방통행 문’으로 가른다. 문서를 읽고 요약하거나 답장 초안을 쓰는 일은 마음에 들지 않으면 언제든 고치거나 지우면 그만인 양방향 문이다. 반면 돈을 결제하고 외부 메일을 보내고 데이터를 지우거나 글을 게시하는 일은 한번 지나면 물릴 수 없는 일방통행 문이다. Replit의 코딩 에이전트가 코드 동결 기간에 운영 데이터베이스를 지워 버린 사고도 이 일방통행 문 앞에 잠금장치를 두지 않아 벌어졌다. 에이전트가 쓰는 도구마다 어느 쪽 문인지 표시해 두기만 해도 권한 설계의 80%가 끝난다.
여기에 하나 더 경계할 함정이 ‘굿하트의 법칙’이다. 측정 지표를 목표로 삼는 순간 그 지표는 더 이상 좋은 측정 도구가 되지 못한다는 원리인데 에이전트는 목표 점수를 글자 그대로 달성하려고 온갖 편법을 동원한다. 문의 해결률을 높이라고 하면 문제를 푸는 대신 티켓을 강제로 닫아 버리는 식이다. DeepMind가 모은 ‘명세 게이밍(specification gaming, 목표의 허점을 파고들어 점수만 챙기는 행동)’ 사례만 60건이 넘는다. 앞서 기획서를 대신한다고 한 평가 묶음도 예외가 아니어서 누군가 일부러 평가 기준의 빈틈을 찔러 보는 검토가 뒤따라야 한다.
모델이 열 배 좋아져도 살아남는 자산
당장 에이전트를 잘 굴리는 것만큼 중요한 질문은 바탕 모델이 다음 세대로 넘어갔을 때 우리 제품에 무엇이 남느냐는 것이다. 이를 가려내는 가장 날카로운 질문이 ‘다음 모델 테스트’다. 내일 아침 바탕 모델이 지금보다 열 배 좋아지면 내 제품은 어떻게 될까. 모델이 똑똑해진 덕분에 제품 가치도 함께 커진다면 그 가치가 고유한 워크플로와 데이터와 유통 경로에 있다는 뜻이다. 반대로 모델이 좋아지자마자 제품이 설 자리를 잃는다면 그건 시한부 타이머가 달린 얇은 껍데기(래퍼)를 만들고 있었다는 신호다.
모델이 바뀌어도 남는 경쟁력의 중심에는 ‘데이터 플라이휠’이 있다. 사용자가 제품을 쓸수록 고유한 데이터가 쌓이고 그 데이터가 제품을 더 낫게 만들면 다시 사용자가 늘어나는 선순환 구조다. 외부 API로 불러 쓰는 모델 가중치는 빌려 쓰는 남의 자산일 뿐이고 우리 팀이 진짜로 소유하는 자산은 현장에서 건져 올린 평가 세트와 실패 로그, 사람이 고쳐 준 이력, 사용자 선호 데이터다.
강화학습의 개척자 리처드 서튼이 남긴 ‘쓰라린 교훈(bitter lesson)’도 같은 방향을 가리킨다. 사람이 머리를 싸매고 정교한 규칙과 잔기술을 직접 짜 넣은 방식보다 연산량과 데이터를 크게 늘리는 범용 학습 방식이 결국 늘 이겨 왔다는 통찰이다. 이를 제품 개발로 옮기면 오래 남을 데이터와 평가 체계와 워크플로에 투자하되 당장 모델의 부족한 지능을 메우려고 덧댄 보조 구조(scaffolding)는 언제 버려도 아깝지 않을 만큼 가볍게 유지하라는 뜻이 된다. 지금 밤새워 깎아 놓은 프롬프트 체인과 우회 로직은 새 모델이 나오는 날 상당 부분 쓸모를 잃을 수 있다.
만드는 비용이 싸지면 검토와 판단이 병목이 된다
마지막으로 에이전트와 함께 일하는 사람 쪽을 보자. 경영학의 ‘제약 이론’에 따르면 시스템 전체의 처리량은 가장 느린 병목 단계가 정한다. 에이전트 덕분에 초안을 만들고 코드를 짜는 통로는 넓어졌지만 무엇을 만들지 결정하고 결과물을 검토하고 검증하는 통로는 예전 그대로다. 전체 작업 중 일부만 빨라져서는 전체 속도가 그만큼 빨라지지 않는다는 ‘암달의 법칙’처럼 코드 생성이 열 배 빨라져도 제품 출시가 열 배 빨라지지 않는 이유가 여기에 있다.
그러면 사람은 어떤 일을 에이전트에게 넘기고 어떤 일을 끝까지 쥐고 있어야 할까. 크리스텐슨 교수의 ‘해결할 일(jobs to be done)’ 이론을 에이전트 시대에 맞게 비틀면 ‘맡길 일(jobs to be delegated)’이라는 질문이 나온다. 사용자에게는 남이 대신 해 줬으면 하는 귀찮은 일과 직접 계속하고 싶은 일이 섞여 있다. 경쟁사 변경 이력을 요약하는 일은 기꺼이 에이전트에게 맡기지만 그 요약을 보고 다음 분기 전략을 정하는 일까지 내주고 싶어 하는 사람은 없다.
만드는 비용이 0에 가까워질수록 귀해지는 것은 골라내는 눈이다. 전략 초안 열 개를 뽑는 일은 이제 싸졌고 그중 아홉 개를 제대로 버리는 일이 값진 기술이 된다. PM의 역할도 백지에서 초안을 직접 쓰는 사람에서 에이전트가 쏟아낸 결과물을 솎아 내고 다듬는 편집자로 옮겨 간다. 폴 그레이엄이 2002년 「Taste for Makers」에서 말한 ‘만드는 사람의 안목’이 다시 실무의 한복판으로 돌아온 셈이다.
글 첫머리의 서른 단계짜리 에이전트로 돌아가 보면 이 도구들이 현장에서 어떻게 맞물리는지 한눈에 보인다. 서른 단계를 그대로 이어 붙였다가 성공률이 무너진 것은 복리 오류를 놓친 탓이고 엉뚱한 환불 안내 메일이 발송된 것은 일방통행 문 앞에 승인 다이얼을 두지 않은 탓이다. 무엇이 제대로 된 답인지 평가 묶음으로 적고 에이전트가 틀린 사례를 매일 들여다보며 기준을 다듬는 사람이 이 제품의 병목이자 가장 중요한 자리에 선다.
출처: Product Mindset, Mental Models in the Agentic Era