Standard Agents의 저스틴 슈뢰더는 하나의 거대한 AI 모델에 모든 업무를 맡기기보다, 작은 업무나 특정 비즈니스 프로세스에 특화된 에이전트들을 조합해야 한다고 주장한다. 기업이 원하는 것은 화려한 모델 자체보다 업무에 깊이 통합되어 반복적으로 정확한 결과를 내는 시스템이며, 이를 대규모로 실현하려면 에이전트의 이식성과 호환성을 보장하는 표준이 필요하다는 이야기다.

1. 오래된 공장에서 발견한 오늘의 AI

저스틴 슈뢰더는 자신을 과거에 코드를 많이 작성했고, 그것을 계속 오픈소스로 공개하는 나쁜 습관이 있었던 사람이라고 소개한다. 이번 발표에서는 자신이 속한 Standard Agents의 관심사인 도메인 특화 에이전트를 이야기하겠다고 밝힌다.

먼저 그는 미래를 예측하는 일이 얼마나 어려운지 보여주기 위해, 1899년에 제작된 미래의 파리를 그린 엽서들을 소개한다. 2000년의 세상을 상상한 그림들 가운데는 방향이 완전히 빗나간 것도 있고, 놀라울 정도로 들어맞거나 안타깝게도 정확한 것도 있다. 그의 발표 역시 미래 전망을 담고 있으므로 예측이 틀릴 수 있다는 가벼운 경고다.

이어서 산업혁명 당시의 공장을 보여준다. 당시에는 크고 무겁고 비싼 증기기관 하나를 중심에 두고, 건물 곳곳에 길게 연결한 동력 전달축과 벨트를 통해 각 작업대에 힘을 공급했다. 위험하고 비효율적인 면이 많았지만, 어쨌든 작동하는 방식이었다.

그는 오늘날의 AI 에이전트가 바로 이 단계에 있다고 비유한다.

"우리는 거대한 모델 하나를 모든 것의 중심에 놓고, 사람들이 하는 개별 작업을 그 중앙 시스템에 연결하고 있습니다."

여기서 개별 작업을 연결하는 수단은 스킬이나 MCP 같은 방식일 수 있다. 슈뢰더는 그것들이 나쁘다는 뜻은 아니지만, 현재의 구성이 과거의 중앙 집중식 공장을 닮았다고 말한다. 그가 바라는 모습은 각 작업대에 독립적인 동력원과 작업 공간이 있는 공장이다. 그리고 그에 대응하는 실용적인 해법으로, 한두 가지 작은 작업을 위해 만들어진 도메인 특화 에이전트를 제안한다.

2. 에이전트는 무엇이고, 왜 만들기 어려운가

슈뢰더는 사람마다 에이전트를 다르게 정의할 수 있다며 자신의 정의를 제시한다.

"에이전트는 원하는 목표를 달성하기 위해 모델이 만들어 내는 비결정적인 결과를 사용하는 결정적인 소프트웨어입니다."

쉽게 말해, 에이전트는 상황에 따라 답이 달라질 수 있는 AI 모델의 출력을 받아 정해진 소프트웨어가 도구를 호출하고 다음 행동을 관리하는 시스템이다. 그는 이를 소프트웨어 기반의 제어 시스템으로 이해해도 좋으며, 두 개념을 엄격히 구별하는 데 큰 실익은 없다고 본다.

겉으로 보면 에이전트 구축은 간단하다. 언어 모델에 도구를 호출하게 하고, 그 결과를 다시 모델에 전달하는 과정을 반복하면 된다. 흔히 말하는 에이전트 루프다. 하지만 실제 운영은 훨씬 어렵다.

비동기 작업 중 문제가 생기지 않도록 흐름을 조율해야 하고, 특정 모델 제공사에만 묶이지 않도록 처리해야 한다. 도중에 실패하더라도 중단 지점부터 재개할 수 있는 지속적인 실행 구조도 필요하다. 사용할 수 있는 프로그래밍 도구는 많지만, 이 모든 것을 결합해 실제로 효과적인 에이전트를 만드는 일은 쉽지 않다는 설명이다.

그는 이런 어려움 때문에 "에이전트를 만들지 말고 MCP 서버만 만든 다음 직원들에게 Claude 같은 도구를 제공하자"는 식의 주장이 나온다고 다소 풍자적으로 말한다. 그러나 실리콘밸리 밖의 일반 기업들을 보면 실제로는 많은 곳이 에이전트를 만들고 있다. MCP 서버를 만드는 기업조차도 그 호출 뒤편에 에이전트를 두는 경우가 있다.

3. 기업이 에이전트를 만드는 세 가지 이유

슈뢰더는 기업들이 어려움에도 에이전트를 구축하는 이유를 통합, 신뢰, 효과성으로 정리한다.

• 통합: 기존 업무 프로세스와 시스템에 AI가 깊이 연결되기를 원한다.
• 신뢰: 광범위한 권한을 가진 범용 AI가 언제나 적절하게 행동하리라고 믿기 어렵다.
• 효과성: 어떤 기술로 처리했는지보다 일을 매번 제대로 끝내는지가 중요하다.

그는 한 대기업에서 일하는 친구의 말을 통해, 코드 작성 속도만 높인다고 기업의 모든 문제가 해결되는 것은 아니라고 설명한다.

"코드를 냅킨에 손으로 쓴 다음 잘게 찢어 각각 봉투에 넣고 전 세계로 보냈다가 다시 받아서 이어 붙이고 컴퓨터에 입력하더라도, 그 일이 새 기능 출시의 병목은 아닐 거야."

이는 실제 기업에서는 개발 속도 외에도 조직과 업무 절차 등 여러 요소가 출시를 가로막을 수 있다는 뜻이다. 슈뢰더는 AI 사용이 여러 곳으로 퍼졌지만, 많은 기업에서는 여전히 표면적인 수준에 머물러 있다고 본다.

그 예로 냉난방·공조 업체 블루 리지 메커니컬을 든다. 이 회사의 사업은 지역 주민을 대상으로 한 홍보, 잠재 고객 확보와 평가, 고객 온보딩, 매출 예측 등 수많은 개별 프로세스로 이루어진다. 각각은 시작과 끝이 있으며, 길고 짧다는 차이는 있어도 함께 모여 실제 사업을 운영한다.

이런 기업에 기존 절차를 모두 대체할 초강력 AI를 제안하는 것은 위험하게 느껴질 수 있다. 이미 돌아가는 업무 전체를 맡길 이유가 없기 때문이다. 대신 슈뢰더는 차량 정비 관리처럼 범위가 분명한 프로세스 하나에 집중하자고 제안한다. 예를 들어 차량 고장 신고를 받고, 우선순위를 판단하고, 수리를 예약하고, 기록을 갱신한 뒤 차량을 다시 운행에 투입하는 과정이다.

"이 과정을 자동화하고 제대로 작동하도록 만들 수 있다고 말한다면, 그건 기업에 흥미로운 제안이 됩니다."

핵심은 막연히 "AI를 도입한다"가 아니라, 이미 존재하는 구체적인 업무에 AI를 깊이 통합하는 것이다.

4. 범용 스킬보다 믿을 수 있는 전용 에이전트

신뢰 문제를 설명하면서 슈뢰더는 에이전트의 구성 요소를 살펴본다. 기본이 되는 모델 위에는 역할을 지정하는 시스템 프롬프트, 실제로 실행되는 함수, 작은 추론 작업을 위한 하위 프롬프트, 호출 가능한 하위 에이전트 등이 놓일 수 있다.

또 특정 시점에 정해진 방식대로 실행되는 훅, 에이전트가 얼마나 많은 단계를 수행할 수 있는지 정하는 규칙도 있다. 필요에 따라 파일 시스템이나 코드 실행 기능도 더해진다. 이 요소들을 묶어 하나의 에이전트로 볼 수 있다는 설명이다.

그는 Codex처럼 오래 작업을 이어갈 수 있는 도구가 유용한 상황도 있지만, 냉난방 업체가 원하는 것은 끝없이 진행되는 작업이 아니라고 말한다. 기업은 특정 프로세스가 완료되기를 바라며, 에이전트가 통제 범위를 벗어나는 것을 걱정한다.

그가 제시하는 대안은 Gmail 스킬을 가진 범용 에이전트보다 Gmail 전용 에이전트를 두는 것이다. 전용 에이전트는 Gmail과 관련 API를 잘 알지만, 불필요한 다른 도구는 갖지 않는다.

"이메일을 작성하는 김에 트위터도 확인해 달라고 하면, Gmail 에이전트는 '아니요. 그 일을 할 도구가 없어서 할 수 없습니다'라고 답합니다."

반면 여러 스킬과 권한을 가진 범용 에이전트는 요청을 확대 해석해 뜻밖의 조치를 할 수 있다고 그는 농담 섞어 경고한다. 이메일을 확인하는 사이 보안 문제를 발견했다며 예방 조치로 운영 환경을 꺼버리는 식이다. 그는 과장이지만 아주 큰 과장은 아니라고 덧붙인다.

이런 위험을 줄이기 위해 Figma, Gmail, Google Sheets 등에 각각 작은 전용 에이전트를 두고, 그 위에서 오케스트레이터, 즉 총괄 조정자가 작업을 배분하도록 하는 구조를 제안한다. 에이전트들 사이를 MCP로 연결할 수도 있다.

그는 Grok 봇이 내부적으로도 특정 하위 작업에 특화된 작은 에이전트들을 사용한다고 소개하며, 이 접근법이 이미 효과적으로 쓰이고 있다고 주장한다.

5. 새로운 구조가 아니라 오래된 공학 원칙

슈뢰더는 작은 에이전트를 조합하는 발상이 사실 새로운 것이 아니라고 말한다. 소프트웨어 공학에는 이미 관련 원칙들이 있기 때문이다.

• 최소 권한 원칙: 각 구성 요소에 필요한 권한만 준다.
• 관심사의 분리: 서로 다른 책임을 분리해 관리한다.
• 구성을 통한 조합: 거대한 구조에 기능을 몰아넣기보다 필요한 구성 요소를 조합한다.
• 데미터 법칙: 한 구성 요소가 다른 요소의 내부를 지나치게 많이 알거나 의존하지 않도록 한다.

이런 원칙이 에이전트에도 고르게 적용되어야 한다는 것이다.

그는 달 착륙도 비유로 든다. 달에 직접 내려간 사람의 뒤에는 각자 자기 분야를 깊이 이해하는 전문가들로 이루어진 팀이 있었다. 전문가들이 각자의 도구와 정보를 활용하고 지식을 모아 하나의 목표를 달성한 모습이, 여러 특화 에이전트가 협력하는 구조와 닮았다는 설명이다.

다시 공장으로 돌아가면, 각 작업대에 독립적으로 동력을 제공할 수 있게 만든 기술은 전기 모터, 특히 유도 전동기였다. 그는 이것을 개별 에이전트가 각자의 범위에서 독립적으로 일할 수 있는 구조에 빗댄다. 다만 전기 모터만으로 공장 전체가 즉시 바뀐 것은 아니었다는 점은 발표 후반에 다시 짚는다.

6. 효과성은 공개 순위보다 업무 평가에서 나온다

세 번째 이유인 효과성을 설명하면서 슈뢰더는 공개 벤치마크의 한계를 비판한다. 벤치마크 결과를 보면 실제 사용자가 느끼는 성능과 어긋나는 순위가 나오기도 하고, 하나의 점수가 모델의 전반적인 품질을 대표하는 것처럼 받아들여지기도 한다는 것이다.

그는 연구자 디오구의 글을 인용하며, 공개 벤치마크를 무조건 믿어서는 안 된다는 견해를 소개한다.

"벤치마크의 가장 큰 피해자는 바로 그 결과를 가장 필요로 하는 사람들입니다. 직접 모델을 시험하고 능력을 감지해 볼 시간이 없는 사람들이죠."

특히 냉난방 업체 입장에서는 공개 순위보다 자신들의 업무가 제대로 처리되는지가 훨씬 중요하다.

그는 이를 가로등 효과에 비유한다. 술에 취한 사람이 열쇠를 다른 곳에서 잃어버렸는데도 잘 보인다는 이유로 가로등 아래에서 찾는 것처럼, AI를 평가할 때도 정작 필요한 답이 아니라 측정하기 쉬운 곳만 바라볼 수 있다는 이야기다.

도메인 특화 에이전트의 장점은 여기서 분명해진다. 업무 범위가 좁으면 그 업무에 맞는 평가를 만들기가 쉽다. Gmail 전용 에이전트가 메일을 정확하게 확인하는지 시험하는 일은, 수많은 다른 맥락과 도구를 가진 범용 에이전트가 매번 동일한 작업을 정확히 수행하는지 보장하는 것보다 수월하다.

"에이전트를 개별 업무나 비즈니스 프로세스로 나누면, 그 프로세스를 훨씬 더 정확하게 평가할 수 있습니다."

7. 모델의 들쭉날쭉한 능력을 비용 절감에 활용하기

슈뢰더는 모델의 성능이 들쭉날쭉하다, 즉 어떤 모델은 특정 작업에 뛰어나지만 다른 작업에는 약할 수 있다는 점도 강조한다. 전체적으로 우수한 모델과 특정 작업에 가장 잘 맞는 모델이 반드시 같지는 않다.

이를 보여주기 위해 그는 Model Zen Garden이라는 작은 프로젝트를 소개한다. 같은 프롬프트를 여러 모델에 주고 작은 3차원 세계를 생성하게 한 뒤 결과를 비교하는 프로젝트다. 과거 웹사이트의 CSS 구현을 비교하던 CSS Zen Garden에서 이름을 가져왔다고 설명한다.

그가 보여준 예에서는 한 모델보다 텐센트의 HY3 모델이 만든 결과가 더 인상적이었다. 풀은 바람에 흔들리고 조명도 자연스럽게 표현됐다. 슈뢰더는 이 모델이 대부분의 다른 작업에는 좋지 않지만 3D 작업에는 놀라울 정도로 뛰어나다고 평가하며, 해당 세계를 생성하는 데 약 60센트가 들었다고 말한다.

"모델이 그 비즈니스 프로세스를 정확하고 합리적인 비용으로 처리했다면, 전체적으로 더 좋은 모델이 있는지는 중요하지 않습니다."

작은 에이전트를 쓰면 각 작업에 맞는 모델을 골라 토큰 사용량과 비용을 줄일 수도 있다. 그는 아직 공개하지 않은 자체적인 소규모 평가에서, 특정 사람에게서 온 이메일을 가져오는 등의 간단한 작업을 분리했을 때 토큰 소비가 크게 감소했다고 주장한다.

또 자신의 비교에서 DeepSeek V4 Flash가 Fable보다 작업당 137배 저렴했다는 수치를 소개한다. 다만 이는 발표자가 제시한 특정 비교의 결과로, 모든 작업에서 같은 비용 차이가 난다는 뜻은 아니다. 그의 요지는 저렴한 모델이 Claude처럼 모든 일을 할 것이라고 기대해서는 안 되지만, 범위가 좁은 작업에는 충분히 잘 맞을 수 있다는 것이다.

8. 공장을 바꾼 것은 모터와 표준의 결합

발표 후반부에서 슈뢰더는 앞서 "전기 모터가 공장을 바꿨다"고 한 설명을 일부 정정한다. 전기 모터는 중요했지만, 처음에는 기존 증기기관을 전기 모터로 바꾸고도 중앙 동력 전달축 구조를 그대로 사용했다는 것이다. 그의 설명에 따르면 이런 방식은 유도 전동기 등장 후에도 약 30년간 이어졌다.

그는 이를 수많은 스킬을 연결한 중앙 모델만 더 나은 모델로 교체하는 것에 비유한다. 어느 정도 효율은 좋아질 수 있지만, 구조 자체가 바뀌는 것은 아니라는 뜻이다.

"중심에 있는 모델을 업그레이드하는 것과 비슷합니다. 작동하고 조금 더 효율적이지만, 모든 것을 혁신한 변화는 아닙니다."

그가 진짜 전환점으로 꼽는 것은 표준화다. 초기에는 전류의 종류, 주파수, 전압, 전류량 등이 통일되지 않아 공장에서 필요한 전기 모터를 직접 만들어야 할 정도로 사용이 비쌌다고 설명한다. 표준이 자리 잡은 뒤에는 개별 작업대에 전기 장치를 훨씬 쉽게 공급할 수 있게 됐다.

예로 미국의 전기 규격을 언급하고, 1910년과 2021년에 만들어진 탁상용 연삭기가 전원 측면에서 사실상 서로 교체 가능하다고 말한다. 시대가 달라도 같은 표준을 활용할 수 있다는 점이 중요하다는 것이다.

슈뢰더는 도메인 특화 에이전트 역시 먼 미래의 이야기가 아니며 이미 관련 변화가 나타나고 있다고 본다. 앞으로는 사용자가 직접 모델을 고르는 도구가 줄어들 수 있다고도 예측한다. 기술 애호가에게는 모델 선택이 흥미롭지만, 대부분의 기업은 모델 이름보다 업무를 제대로 수행하는지에 관심이 있기 때문이다.

9. 에이전트에 필요한 표준과 실행 환경

슈뢰더는 에이전트를 대규모로 활용하려면 단순히 에이전트를 많이 만드는 것만으로는 부족하며, 만들고 설치하고 연결하는 방식에 대한 표준이 필요하다고 주장한다. 그가 제안하는 조건은 다음과 같다.

• 도메인 특화: 에이전트가 명확하고 좁은 업무 영역에 집중해야 한다.
• 재현 가능한 실행 환경: 다른 사람이 만든 에이전트를 설치해도 원래와 같은 기능과 환경을 확보할 수 있어야 한다.
• 이식성: npm이나 pip로 패키지를 설치하듯 에이전트도 설치하고 옮길 수 있어야 한다.
• 공급사 독립성: 특정 업체의 독점적인 시스템에만 갇히지 않아야 한다.
• 조합 가능성: 여러 에이전트가 표준화된 방식으로 서로 통신하고 협력할 수 있어야 한다.

여기서 공급사 독립성과 실행 재현성은 구별할 필요가 있다. 특정 공급사의 도구에 종속되지 않는 표준을 지향하되, 검증된 에이전트를 다른 환경에서 실행할 때는 사용한 모델·제공사·양자화 수준 등 주요 조건이 같아야 기대한 성능을 재현할 수 있다는 것이 그의 설명이다.

그는 Standard Agents가 이 문제를 해결하기 위해 작은 팀으로 일하고 있다고 소개한다. 목표는 도메인 특화 에이전트를 만드는 방법을 규정한 오픈소스 명세와, 에이전트를 설치해 실행할 수 있는 런타임을 제공하는 것이다. 장기적으로는 Node나 Python처럼 여러 실행 환경이 경쟁할 수 있는 생태계를 구상한다고 덧붙인다.

10. 질의응답: 모델 선택과 운영 거버넌스

첫 번째 질문은 업무 흐름을 에이전트에 직접 구현하는 것과 모델 자체를 조정하는 것 사이의 균형에 관한 것이었다. 슈뢰더는 업무 로직을 주로 에이전트 쪽에 구현한다고 답한다.

그러면서도 모델은 여전히 중요한 구성 요소라고 강조한다. 개발자는 경험을 통해 어떤 모델이 무엇을 잘하고 못하는지 감을 쌓기 때문에, 특히 작은 모델을 사용할 때는 특정 모델에 맞춰 에이전트를 구축하는 일이 중요하다는 것이다.

"에이전트는 아주 작고 특정 범위에 맞춰져야 하지만, 모델도 그 에이전트의 중요한 일부입니다."

그는 도구에서 모델을 아무렇게나 바꾼 뒤 그대로 데이터를 보내는 방식은 장기적으로 바람직하지 않다고 본다. 모델을 교체하면 기존 동작이 그대로 유지되는지 검증하기 어렵기 때문이다. 대신 모델마다 다른 장단점을 알고 이를 작업에 맞게 활용해야 한다고 답한다.

두 번째 질문은 모델이 계속 바뀌는 상황에서 여러 에이전트를 어떻게 유지보수하고 관리·감독할 것인가에 관한 것이었다. 새로운 대표 모델이 나올 때마다 모두 업그레이드해야 하는지, 다양한 모델이 섞인 에이전트들을 어떻게 통제할지도 질문에 포함됐다.

슈뢰더는 기업의 IT 부서 등이 조직 안에서 실행되는 작은 에이전트들을 모두 확인하고, 각 에이전트의 평가를 관리할 수 있는 운영 플랫폼이 필요하다고 답한다. 새 모델이 나왔을 때는 공개 순위가 아니라 해당 기업의 비즈니스 프로세스에 맞춘 자체 평가를 통해 적합성을 판단해야 한다는 것이다.

다만 새 모델이 나왔다는 이유만으로 무조건 바꿀 필요는 없다고 강조한다.

"지금 모델이 제 일을 제대로 하고 있다면, 모델이 종료될 때까지 그냥 계속 쓰면 됩니다."

그는 반복적으로 올바른 결과를 내는 것이 우선이라는 점을 다시 확인하며 발표를 마친다.