Meta는 AI 에이전트 사이클에 대해 뉴스 주간을 살아남을 만한 종류의 문장을 던졌습니다. 바로 그 작업이 "우리가 예상했던 방식으로는 가속화되지 않았다"는 것입니다.

Reuters에 따르면, 이는 Mark Zuckerberg가 내부 타운홀 미팅에서 언급한 내용입니다. 이것이 중요한 이유는 Meta가 단순히 Slack에 챗봇을 덕테이프로 붙여놓는 무작위 스타트업이 아니기 때문입니다. Meta는 에이전트 AI (agentic AI)를 대규모로 구현할 수 있는 자금, 인프라, 인재, 그리고 내부적 압박을 모두 갖춘 몇 안 되는 기업 중 하나입니다. 또한 Reuters는 Meta가 올해 AI 인프라에 무려 1,450억 달러를 지출할 것으로 예상한다고 전했습니다.

따라서 그 정도의 컴퓨팅 자원 (compute)을 보유한 기업이 에이전트 추진이 예상보다 오래 걸리고 있다고 말할 때, 유용한 반응은 "에이전트는 끝났다"가 아닙니다. 그것은 너무 쉽고, 대부분 틀린 판단입니다.

더 나은 반응은 이렇습니다: 좋습니다, 드디어 데모 세금 (demo tax)이 도착했군요.

에이전트 데모는 에이전트 시스템이 아니다

대부분의 에이전트 데모는 깔끔하고 작은 환상을 중심으로 구축됩니다. 사용자가 목표를 요청합니다. 모델이 계획을 세웁니다. 도구 (tools)를 호출합니다. 결과를 확인합니다. 그런 다음 깔끔한 요약과 아마도 약간 거만한 초록색 체크 표시와 함께 작업을 완료합니다.

이러한 패턴은 유용합니다. 저도 지루한 업무를 위해 에이전트를 끊임없이 사용하고 있으며, 에이전트가 소프트웨어의 지루한 업무 중 상당 부분을 차지하게 될 것이라고 생각합니다.

하지만 데모는 해당 시스템이 프로덕션 (production) 환경에서 생존할 수 있는지 여부를 결정하는 부분들을 숨깁니다.

에이전트의 실수는 누가 책임지는가? 에이전트가 무엇을 건드릴 수 있는가? 첫 번째 도구 호출은 성공하고, 두 번째는 부분적으로 성공하며, 세 번째는 오래된 데이터 (stale data)를 반환할 때는 어떤 일이 발생하는가? 다섯 개의 시스템과 세 개의 권한 경계 (permission boundaries)를 가로지르는 결정 경로를 어떻게 디버깅(debug)할 것인가? 에이전트가 확신에 차서 API 호출로 또 다른 한 시간을 낭비하는 대신, 언제 멈춰서 인간에게 물어보게 할 것인가?

그 지점이 바로 마술이 운영 (operations)으로 변하는 지점입니다.

챗봇은 상자 안에서 틀릴 수 있습니다. 하지만 프로덕션 에이전트는 렌치를 들고 있는 상태에서 틀립니다.

Meta의 문제는 업계의 문제이며, 단지 더 크게 들릴 뿐이다

Reuters 보도에 따르면, Zuckerberg는 대규모 인력 감축을 포함한 Meta의 조직 개편이 생각만큼 "깔끔(clean)"하지 않았으며, 새로운 구조에 대한 베팅이 "아직 결실을 보지 못했다(haven't come to fruition yet)"라고 말했습니다. 동일한 보도를 요약한 TechCrunch는 Meta가 올해 초 약 8,000명의 직원을 해고했으며, Agent Transformation이라 불리는 그룹을 포함한 AI 관련 부서로 다른 7,000명을 재배치했다고 언급했습니다.

이것이 에이전트 베팅의 잔혹한 버전입니다. 즉, 빠르게 움직이고, 자동화 중심으로 조직을 재편하며, 그 고통을 정당화할 수 있을 만큼 생산성 곡선이 충분히 빨리 도래할 것이라고 가정하는 것입니다.

어려운 점은 조직도(org chart)가 결정한다고 해서 에이전트가 프로덕션 시스템 (production systems)이 되는 것은 아니라는 사실입니다.

Gartner는 이미 비용 상승, 불분명한 비즈니스 가치, 또는 취약한 리스크 제어(risk controls)로 인해 2027년 말까지 에이전트형 AI (agentic AI) 프로젝트의 40% 이상이 취소될 것이라고 경고했습니다. 이러한 예측은 평균적인 에이전트 파일럿 (pilot) 프로젝트를 살펴보기 전까지는 가혹하게 들립니다. 많은 프로젝트가 무언가가 '가능함'을 증명하기 위해 구축될 뿐, 그것을 '소유할 가치가 있음'을 증명하기 위해 구축되지 않기 때문입니다.

파일럿은 다음과 같이 질문합니다: 이 에이전트가 작업을 한 번 수행할 수 있는가?

프로덕션은 다른 질문을 던집니다:

• 입력값(inputs)이 엉망일 때도 작업을 수행할 수 있는가?
• 실패했을 때 우리가 이를 인지할 수 있는가?
• 인간이 병목 현상 (bottleneck)이 되지 않으면서 위험한 부분을 검토할 수 있는가?
• 비용이 대체되는 작업보다 저렴한가?
• 전체 워크플로우 (workflow)를 함께 중단시키지 않고 에이전트만 끌 수 있는가?

대부분의 에이전트 프로젝트는 첫 번째 질문에 대한 답을 얻고 그것을 전략이라고 부릅니다.

누락된 계층은 의도적으로 지루하게 설계되어 있다

제대로 작동하는 에이전트 계층 (agent layer)은 화려한 경우가 거의 없습니다. 그것은 권한 (permissions), 큐 (queues), 로그 (logs), 평가 (evals), 롤백 경로 (rollback paths), 그리고 인간의 검토 지점 (human review points)처럼 보입니다.

또한 키노트 (keynote) 버전에서 보여주는 모습보다 훨씬 작아 보입니다.

제가 본 가장 안전한 에이전트 (agents)들은 "디지털 직원 (digital employees)"로 시작하지 않습니다. 그들은 명확한 경계를 가진 좁은 범위의 작업자 (narrow workers)로 시작합니다. 이 지원 스레드들을 요약하되, 답장은 보내지 마세요. 풀 리퀘스트 (pull request)를 작성하되, 머지 (merge)하지는 마세요. 이 인보이스 (invoices)들을 비교하고, 불일치 사항을 표시한 뒤, 임계값 (threshold)을 초과하는 것은 전달하세요. 이 큐 (queue)를 분류하되, 모든 작업 내용을 감사 로그 (audit log)에 기록하세요.

이것은 완전히 자율적인 사무직 직원만큼 흥미롭지는 않습니다. 하지만 개발자가 안심하고 옆에 둘 수 있는 무언가에 훨씬 더 가깝습니다.

제가 신뢰하는 패턴은 네 가지 속성을 가집니다:

1. 입력 (input)이 제한되어 있다.
2. 출력 (output)을 검증하기 쉽다.
3. 폭발 반경 (blast radius)이 작다.
4. 지정된 사람이 워크플로 (workflow)를 소유한다.

이 중 하나라도 누락된다면, 그 에이전트는 아마도 여전히 장난감이나 연구 프로젝트, 혹은 새로운 장애 유형 (incident category)을 만들어내는 매우 비싼 방법일 뿐일 것입니다.

이것이 바로 "에이전트적 (agentic)"이라는 단어가 그토록 혼란스러운 단어가 된 이유입니다. 벤더 (vendors)들은 실제 도구 호출 (tool-calling) 워크플로부터 프롬프트 (prompt)가 더 긴 챗봇에 이르기까지 모든 것에 이 용어를 사용합니다. 가트너 (Gartner)는 이를 "에이전트 워싱 (agent washing)"이라고 불렀으며, 이는 적절한 명칭입니다. 만약 에이전트가 자신이 무엇을 했는지 설명할 수 없고, 제한된 권한 (scoped permissions) 하에서 작동하며, 소유자가 처리할 수 있는 방식으로 실패할 수 없다면, 그것은 프로덕션 자동화 (production automation)가 아닙니다. 그것은 그저 자신감 넘치는 인터페이스 (interface)일 뿐입니다.

컴퓨팅 (Compute)이 판단력을 사지는 않는다

로이터 (Reuters) 보고서에서 가장 흥미로운 세부 사항은 1,450억 달러라는 숫자가 아닙니다. 그것은 타이밍의 실수입니다.

보도에 따르면 저커버그 (Zuckerberg)는 경영진이 변화의 타이밍을 잘못 계산했다고 말했습니다. 그것이 교훈입니다. Meta가 GPU가 부족하다는 것이 아닙니다. 모델이 쓸모없다는 것도 아닙니다. 실수는 조직의 곡선 (organizational curve)과 기술의 곡선 (technical curve)이 예정대로 만날 것이라고 가정한 것이었습니다.

대개는 그렇지 않습니다.

에이전트는 단순한 모델의 능력 (model capability)이 아닙니다. 그것은 비즈니스 프로세스 내부의 새로운 실패 표면 (failure surface)입니다. 모델은 주변 시스템이 예외적인 경로 (ugly path)를 처리할 준비가 되기 몇 달 전부터 해피 패스 (happy path)를 수행하기에는 충분히 좋을 수 있습니다.

그 격차는 비용이 많이 듭니다. 준비되지 않은 도구들을 중심으로 조직이 재편될 때 사기(morale) 문제를 일으킵니다. 에이전트가 왜 특정 행동을 취했는지 정확히 아무도 말할 수 없을 때 거버넌스 (governance) 문제를 일으킵니다. 재시도(retries), 컨텍스트 (context), 모니터링 (monitoring), 그리고 인간의 검토 (human review) 비용이 원래의 기획안에 포함되어 있지 않았을 때 예산 문제를 일으킵니다.

더 저렴한 교훈은 조직이 그것에 베팅하기 전에 작업의 범위 (scope)를 정하는 것입니다.

에이전트가 좁은 직무를 수행하고 그 결과를 확인할 수 있는 하나의 워크플로우 (workflow)에서 시작하십시오. 개입률 (intervention rate), 오탐 (false positives), 완료된 작업당 비용 (cost per completed task), 그리고 롤백 시간 (rollback time)을 측정하십시오. 이 수치들이 좋아 보인다면 범위를 넓히십시오. 그렇지 않다면 워크플로우를 수정하거나 폐기하십시오.

이는 "인력의 10%를 에이전트로 교체한다"는 말에 비하면 느리게 들릴 것입니다. 하지만 이것이 바로 지루한 자동화 (automation)가 실제 사용자와 접촉하며 살아남는 방식입니다.

승리하는 에이전트는 처음에는 덜 자율적으로 보일 것입니다

저는 여전히 에이전트가 중대한 변화라고 생각합니다. 소프트웨어 작업의 지루한 절반은 반복적이고, 컨텍스트 (context) 의존도가 높으며, 금요일 오후의 인간들이 제대로 처리하기에는 짜증스러운 작업들로 가득 차 있습니다.

하지만 승리하는 시스템은 한동안 실망스러울 정도로 실용적으로 보일 것입니다. 동료보다는 코파일럿 (copilot) 에 가깝고, 자유로운 직원보다는 제약이 있는 러너 (runner) 에 가까울 것입니다. 공상 과학 (science fiction) 보다는 더 많은 로그 (logs)와 승인 게이트 (approval gates)를 가질 것입니다.

그것으로 괜찮습니다.

에이전트의 하이프 격차 (hype gap)는 구축을 멈춰야 할 이유가 아닙니다. 그것은 자율성 (autonomy) 이 시작점인 척하는 것을 멈춰야 할 이유입니다. 자율성은 워크플로우가 그럴만한 가치가 있을 만큼 충분한 엣지 케이스 (edge cases) 를 견뎌낸 후에 얻게 되는 것입니다.

Meta는 인프라 측면에 1,450억 달러를 쓸 수 있습니다. 우리 대부분은 그럴 수 없으며, 그럴 필요도 없습니다. 유용한 버전은 더 작게 시작합니다. 짜증 나는 워크플로우 하나를 선택하고, 에이전트에게 좁은 렌치를 쥐여준 뒤, 그것이 벽을 뚫고 휘둘러지지 않도록 확실히 하는 것입니다.

당신의 스택에서는 어디에 선을 긋겠습니까: 에이전트가 초안을 작성하는 단계, 승인을 거쳐 에이전트가 행동하는 단계, 아니면 에이전트가 단독으로 행동하는 단계입니까?