1. 무엇을 파는 발표인가

클라우드플레어에서 개발자 플랫폼을 맡은 제품 부사장이 발표한다. *워커스와 *두러블 오브젝트를 다루는 자리다. 발표 뒤쪽은 자사 에이전트 SDK와 그 위에서 도는 것들을 보이는 데 쓰인다.

먼저 시장 수치가 몇 개 나온다. 지식노동자의 75%가 넘게 일에 AI를 붙여 쓰고, 개발자의 76%가 넘게 개발 과정에 AI를 쓴다고 한다. 에이전트를 들인 회사 가운데 매출이 20% 늘었다는 곳과 고객지원 응답이 90% 빨라졌다는 곳이 있고, 대체로 50~75%의 시간을 아꼈다는 이야기가 나온다.

이 값들은 발표자가 잰 것이 아니다. 인용한 보고서의 값이고 출처를 따로 대지 않는다. 발표자 스스로도 보고서를 뽑은 시점과 지금 사이에 숫자가 더 컸을 것이라고 덧붙인다.

2. 에이전트를 넷으로 자르면

이 발표의 쓸모는 이 자름에 있다. 사람과 만나는 클라이언트가 있고, 다음에 무엇을 할지 정하는 AI가 있고, 그 결정을 실제로 집행하는 워크플로가 있고, 바깥에 손을 대는 툴이 있다.

셋째 자리를 집행부라고 부르는 것이 이 틀의 핵심이다. 정하는 곳과 실행하는 곳을 갈라 놓았다. 무엇이 잘 안 된다고 할 때 넷 중 어디인지부터 말하게 만드는 틀이다.

예로 든 고객관리 에이전트는 이 넷이 길게 늘어선 모양이다. 음성이나 채팅으로 들어와 글로 바뀌고, 캐시와 평가를 맡는 게이트웨이를 지나 모델이 생각하고, 워크플로가 행동을 좇고, 툴이 브라우저와 API와 사내 서비스와 *벡터 데이터베이스에 손을 댄다. 필요하면 그 사이에 사람이 낀다.

3. 사람 승인이 끼어드는 자리

발표에서 가장 구체적인 대목이 신용카드 발급 승인이다. 사용자가 채팅으로 카드를 요청하면 발급 도구를 사람 입력이 필요한 것으로 감싸 두고, 승인 알림을 보낸 뒤 발급을 멈춘다.

어려운 자리는 그 다음이다. 승인이 돌아올 때까지 멈춘 도구 호출이 살아 있어야 하고, 돌아온 승인이 원래 그 에이전트를 찾아가야 한다. 발표자는 이 라우팅을 두러블 오브젝트가 맡는다고 설명한다. 그 사이에 같은 승인이 두 번 오거나 카드가 두 번 나가지 않도록 상태를 확인하는 검사도 든다.

전통적으로는 데이터베이스를 따로 세우고 연결을 관리하고 확장을 감당해야 했다는 것이 여기서 견주는 기준이다. 자사 제품이 그 일을 대신한다는 이야기로 이어진다.

4. MCP를 이루는 네 개념, 그리고 하나

*MCP는 클라이언트와 서버가 주고받는 전통적인 구조를 따르고, 서버 하나에 클라이언트가 여럿 붙을 수 있다.

MCP 서버를 이루는 네 개념

넷째 줄이 이 발표에서 가장 정직한 대목이다. 발표자는 이 발표를 준비하면서 샘플링을 프로덕션에서 쓰는 곳을 본 적이 없다는 결론에 이르렀다고 말한다. 규격에 적혔다고 실제로 쓰이는 것은 아니라는 이야기다.

직접 MCP 서버를 만들 때 까다로운 자리로는 셋을 든다. 전송 프로토콜, OAuth, 그리고 메모리다.

5. 발표가 밝히지 않은 것

인용한 수치의 출처가 없다. 매출 20%와 응답 90%와 시간 50~75%가 어느 조사에서 몇 곳을 대상으로 나온 값인지 나오지 않는다. 발표자가 잰 값이 아니라는 점과 함께 감안해야 한다.

샘플링을 왜 아무도 안 쓰는지는 안 나온다. 못 봤다는 관찰까지만 있고 그 이유가 규격 탓인지 도구 탓인지 필요가 없어서인지가 없다. 관찰 자체가 값진 만큼 이 대목이 비어 있는 것이 아쉽다.

멈춘 도구 호출을 얼마나 오래 살려 두는지도 없다. 승인이 하루 뒤에 와도 되는지, 그동안 무엇이 얼마나 쌓이는지, 승인이 영영 안 오면 어떻게 되는지가 나오지 않는다. 사람이 끼는 워크플로에서 실제로 문제가 되는 자리가 거기다.

발표자가 유효기간을 스스로 짚는 대목은 있다. 인용한 보고서 숫자가 이미 낡았을 것이라고 말한다.